CVS woes

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

CVS woes

Allin Cottrell
Following up on Stefan Husmann's question the other day: There's
still no access to gnuplot CSV on sourceforge ("waiting for
anoncvs_gnuplot's lock...").

This is not specific to gnuplot: support tickets going back to
2015-11-11 complain of CVS hanging waiting for a lock, for several
projects. I added one for gnuplot 3 days ago. Apparently none of
these tickets has even been read yet, though some more recent
submissions on other topics are already in the "pending" stack. It
seems that CVS comes at the bottom of the list for attention.

Any plans for gnuplot to migrate to git? That seems to be _much_
better supported at sourceforge. I recently converted gretl
(econometrics software on sourceforge) from CVS to git and it has
been trouble-free since. If there's interest I can send my recipe
for the transition. (There are several "how-to"s out there, but
they're not all up to date.)

--
Allin Cottrell
Department of Economics
Wake Forest University

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: CVS woes

Daniel J Sebald
On 11/23/2015 03:46 PM, Allin Cottrell wrote:

> Following up on Stefan Husmann's question the other day: There's
> still no access to gnuplot CSV on sourceforge ("waiting for
> anoncvs_gnuplot's lock...").
>
> This is not specific to gnuplot: support tickets going back to
> 2015-11-11 complain of CVS hanging waiting for a lock, for several
> projects. I added one for gnuplot 3 days ago. Apparently none of
> these tickets has even been read yet, though some more recent
> submissions on other topics are already in the "pending" stack. It
> seems that CVS comes at the bottom of the list for attention.
>
> Any plans for gnuplot to migrate to git? That seems to be _much_
> better supported at sourceforge. I recently converted gretl
> (econometrics software on sourceforge) from CVS to git and it has
> been trouble-free since. If there's interest I can send my recipe
> for the transition. (There are several "how-to"s out there, but
> they're not all up to date.)

One of the requirements is that the git log output would have to be
converted to ChangeLog format using some type of script for development
moving forward.  And it would be good for the existing ChangeLog to
serve as the commit messages for the initial git repository.

Dan

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: CVS woes

Eric S. Raymond
In reply to this post by Allin Cottrell
Allin Cottrell <[hidden email]>:
> Any plans for gnuplot to migrate to git? That seems to be _much_
> better supported at sourceforge. I recently converted gretl
> (econometrics software on sourceforge) from CVS to git and it has
> been trouble-free since. If there's interest I can send my recipe
> for the transition. (There are several "how-to"s out there, but
> they're not all up to date.)

I still lurk on this list because I offered to do a git conversion a
couple years back.  I'm a former GNUPlot contributor and now maintain
cvs-fast-export; I'm the author of one of those how-tos.

The maintainers weren't interested, last time.  We'll see if anything
has changed.  It should; in 2015 still using CVS has gone beyond quaint
and retro into embarrassing, do-you-never-want-to-have-new-contributors
territory.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: CVS woes

Allin Cottrell
In reply to this post by Daniel J Sebald
On Mon, 23 Nov 2015, Daniel J Sebald wrote:

> On 11/23/2015 03:46 PM, Allin Cottrell wrote:
[...]
>> Any plans for gnuplot to migrate to git? That seems to be _much_
>> better supported at sourceforge.
[...]
>
> One of the requirements is that the git log output would have to
> be converted to ChangeLog format using some type of script for
> development moving forward. And it would be good for the existing
> ChangeLog to serve as the commit messages for the initial git
> repository.

This may not be exactly what you're talking about, but currently
available software will translate the entire history of a CVS
repository into the git equivalent -- making for a seamless
transition -- so I don't suppose that handling ChangeLogs would be a
problem.

Allin Cottrell

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: CVS woes

Eric S. Raymond
Allin Cottrell <[hidden email]>:

> On Mon, 23 Nov 2015, Daniel J Sebald wrote:
>
> > On 11/23/2015 03:46 PM, Allin Cottrell wrote:
> [...]
> >> Any plans for gnuplot to migrate to git? That seems to be _much_
> >> better supported at sourceforge.
> [...]
> >
> > One of the requirements is that the git log output would have to
> > be converted to ChangeLog format using some type of script for
> > development moving forward. And it would be good for the existing
> > ChangeLog to serve as the commit messages for the initial git
> > repository.
>
> This may not be exactly what you're talking about, but currently
> available software will translate the entire history of a CVS
> repository into the git equivalent -- making for a seamless
> transition -- so I don't suppose that handling ChangeLogs would be a
> problem.

It depends on what the maintainers actually want.  I speak as an
expert at this kind of conversion; among other things, I moved
groff and NUT from CVS to git.

Unfortunately, the combination of ChangeLogs and CVS comments is actually very
difficult to integrate into a single comment history.

The first step would be mapping the per-file CVS commits to git-style
multi-file commits.  I maintain the best-in-class tools for this -
cvs-fast-export and reposurgeon - and unless your CVS repo has
particularly odd malformations it won't be difficult.

I just ran a test conversion of your SourceForge CVS; took about 5
minutes to do it and correctness-check the result at every tag. There's
some mild hinkiness with an import branch that can probably be
discarded, and three file histories under docs/ps that should probably
be snipped off, but for a conversion of a CVS repo this old that is
barely any cruft at all, and reposurgeon could fix it right up.

It also wouldn't be any real problem, mechanically speaking, to edit
individual change comments to include ChangeLog entries.  The problem is
in figuring what commit each entry should be inserted into.  Their dates
are only recorded to the day, so it isn't usually going to be possible
to mechanically associate a ChangeLog entry with a single commit.  Even
the disambiguation of being able to match against committer names turns
out not to help much.

But the real show-stopper is that, if this project is anything like
typical, a single ChangeLog entry often actually summarizes work from
*multiple* commits.  It may not be clear which ones, since one of
the bedevilling quirks of older CVSes was that commit timestamps were
take *client-side* and tended to be flaky.

You'd have to have some human slog through all ChangeLog entries by
eyeball, applying contextual knowledge and editing ChangeLog entries
into the commit history by hand.  I know of no project that has ever
actually done this.

What everyone ends up doing when they convert is treating ChangeLogs as
historical documents related to but not merged with the commit history.

Now, as for generating ChangeLog entries after conversion.  It can be
done, but it's like mounting an ornamental buggy-whip holder on the
dashboard of a car - quite pointless in practice.  When you have a
proper VCS with multi-file commits, those should *be* your Changelog.
Enough said.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: CVS woes

Daniel J Sebald
On 11/23/2015 08:08 PM, Eric S. Raymond wrote:

> Allin Cottrell<[hidden email]>:
>> On Mon, 23 Nov 2015, Daniel J Sebald wrote:
>>
>>> On 11/23/2015 03:46 PM, Allin Cottrell wrote:
>> [...]
>>>> Any plans for gnuplot to migrate to git? That seems to be _much_
>>>> better supported at sourceforge.
>> [...]
>>>
>>> One of the requirements is that the git log output would have to
>>> be converted to ChangeLog format using some type of script for
>>> development moving forward. And it would be good for the existing
>>> ChangeLog to serve as the commit messages for the initial git
>>> repository.
>>
>> This may not be exactly what you're talking about, but currently
>> available software will translate the entire history of a CVS
>> repository into the git equivalent -- making for a seamless
>> transition -- so I don't suppose that handling ChangeLogs would be a
>> problem.
>
> It depends on what the maintainers actually want.  I speak as an
> expert at this kind of conversion; among other things, I moved
> groff and NUT from CVS to git.
>
> Unfortunately, the combination of ChangeLogs and CVS comments is actually very
> difficult to integrate into a single comment history.
>
> The first step would be mapping the per-file CVS commits to git-style
> multi-file commits.  I maintain the best-in-class tools for this -
> cvs-fast-export and reposurgeon - and unless your CVS repo has
> particularly odd malformations it won't be difficult.
>
> I just ran a test conversion of your SourceForge CVS; took about 5
> minutes to do it and correctness-check the result at every tag. There's
> some mild hinkiness with an import branch that can probably be
> discarded, and three file histories under docs/ps that should probably
> be snipped off, but for a conversion of a CVS repo this old that is
> barely any cruft at all, and reposurgeon could fix it right up.
>
> It also wouldn't be any real problem, mechanically speaking, to edit
> individual change comments to include ChangeLog entries.  The problem is
> in figuring what commit each entry should be inserted into.  Their dates
> are only recorded to the day, so it isn't usually going to be possible
> to mechanically associate a ChangeLog entry with a single commit.  Even
> the disambiguation of being able to match against committer names turns
> out not to help much.
>
> But the real show-stopper is that, if this project is anything like
> typical, a single ChangeLog entry often actually summarizes work from
> *multiple* commits.  It may not be clear which ones, since one of
> the bedevilling quirks of older CVSes was that commit timestamps were
> take *client-side* and tended to be flaky.

Could the documentation be integrated into the git commit history in an
approximate way?  Say, associate all the comments for a particular day
with the last CVS entry for that date?  But it would have to be that the
full Changelog header and date appears in the comment.  So for example,
one commit message might have three Changelog entries listed.  It would
only be an approximate alignment of commit messages and the changelog,
but anyone who would go through the history to manually decipher and
reconstruct things would be faced with an approximate association with
what is in CVS anyway.


> You'd have to have some human slog through all ChangeLog entries by
> eyeball, applying contextual knowledge and editing ChangeLog entries
> into the commit history by hand.  I know of no project that has ever
> actually done this.

I doubt anyone is willing to volunteer to fix the whole history, but
having an approximate alignment of messages would be convenient enough,
I would think.


> What everyone ends up doing when they convert is treating ChangeLogs as
> historical documents related to but not merged with the commit history.

I suppose that wouldn't be too bad, but I don't like the idea of having
a commit message history that is void of any context.  The nice thing is
having a viewer that displays the diffs between versions along with an
overall description of changes.


> Now, as for generating ChangeLog entries after conversion.  It can be
> done, but it's like mounting an ornamental buggy-whip holder on the
> dashboard of a car - quite pointless in practice.  When you have a
> proper VCS with multi-file commits, those should *be* your Changelog.
> Enough said.

The git log is pretty close to Changelog format already.  I would think
some tweaking is all that is needed to make the output very close.  Then
if the original Changelog comments are in the git commit messages, a
"git-to-changelog" conversion would be close to the original changelog
plus new commits.

For those who haven't used git, or mercurial, I think you'd find it a
very helpful tool beyond just the code maintenance portion of it.  I
typically have something like TortoiseHg or gitg open so that it shows
me what all the changes are for my local version of code which just
helps organize things in one's mind, and one can easily pick and choose
the code hunks that should be included in a commit/changeset, etc.
Something I find very clumsy with CVS is generating diffs to post on the
bug tracker or whatnot.  But with git/hg this sort of operation is easy.
  Basically, programming is just a much more fluent thing with a good
version control system.

Dan

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: CVS woes

Daniel J Sebald
On 11/24/2015 01:59 PM, Daniel J Sebald wrote:
> On 11/23/2015 08:08 PM, Eric S. Raymond wrote:

[snip]

>> What everyone ends up doing when they convert is treating ChangeLogs as
>> historical documents related to but not merged with the commit history.
>
> I suppose that wouldn't be too bad, but I don't like the idea of having
> a commit message history that is void of any context.  The nice thing is
> having a viewer that displays the diffs between versions along with an
> overall description of changes.

I forgot to add, saving the ChangeLogs as documents in addition to
distributed within the git history would be fine too.

Dan

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: CVS woes

Plotter-2
In reply to this post by Daniel J Sebald
Thanks for all the attention this is getting. When I hit this about 5
days ago I assumed it was just temporary glitch. It's starting to look
like it may have been an intentional 'feature' to push everyone still
using CVS to stop doing so.

Wasn't there some discussion and a hosting offer from some faculty to
host the archive in a more controlled environment?

BTW is there a recent tarball I can grab from somewhere until this jive
is sorted out?

I foolishly deleted by old copy in order to get a clean download, under
the illusion that sourceforge could be relied upon. We get wiser every
day...


Thanks, Peter.


------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: CVS woes

Mojca Miklavec
On 24 November 2015 at 21:17,  <[hidden email]> wrote:
> Thanks for all the attention this is getting. When I hit this about 5
> days ago I assumed it was just temporary glitch. It's starting to look
> like it may have been an intentional 'feature' to push everyone still
> using CVS to stop doing so.
>
> Wasn't there some discussion and a hosting offer from some faculty to
> host the archive in a more controlled environment?

What kind of archive do you have in mind?

(If the developers would switch to git, every user would have the
complete archive at hand. :)

> BTW is there a recent tarball I can grab from somewhere until this jive
> is sorted out?

You can get an unreliable clone at
    https://github.com/gnuplot/gnuplot
and I have a complete backup of the CVS repository should anyone need
it (but it's about 171 MB, so I'm unable to send it over email).

But it would be sooooo great if the developers would switch to any other VCS.

Mojca

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: CVS woes

Allin Cottrell
In reply to this post by Plotter-2
On Tue, 24 Nov 2015, [hidden email] wrote:

> Thanks for all the attention this is getting. When I hit this about 5
> days ago I assumed it was just temporary glitch. It's starting to look
> like it may have been an intentional 'feature' to push everyone still
> using CVS to stop doing so.

No, surely not intentional. It's just that CVS is low priority (and
they certainly would prefer that projects not use CVS any more).

> Wasn't there some discussion and a hosting offer from some faculty to
> host the archive in a more controlled environment?
>
> BTW is there a recent tarball I can grab from somewhere until this jive
> is sorted out?

The jive is now sorted out; CVS is accessible again.

Allin Cottrell

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: CVS woes

Eric S. Raymond
In reply to this post by Daniel J Sebald
Daniel J Sebald <[hidden email]>:

> >But the real show-stopper is that, if this project is anything like
> >typical, a single ChangeLog entry often actually summarizes work from
> >*multiple* commits.  It may not be clear which ones, since one of
> >the bedevilling quirks of older CVSes was that commit timestamps were
> >take *client-side* and tended to be flaky.
>
> Could the documentation be integrated into the git commit history in an
> approximate way?  Say, associate all the comments for a particular day with
> the last CVS entry for that date?  But it would have to be that the full
> Changelog header and date appears in the comment.  So for example, one
> commit message might have three Changelog entries listed.  It would only be
> an approximate alignment of commit messages and the changelog, but anyone
> who would go through the history to manually decipher and reconstruct things
> would be faced with an approximate association with what is in CVS anyway.

Yes, something like that could be attempted.  The reason it's never been done
is that the implementation would be a swamp of complexity, and the results of
very dubious quality.  

The easiest way I could imagine to do it (all the alternatives would require
a larger volume of custom code) would be to:

(1) Write a Python program that could convert the entire sequence of ChangeLog
into a shelf object keyed by date, with the values being a pair consisting of
a name and the comment text.

(2) Write a custom plugin for reposurgeon that would load the shelf object
produced by the previous program and walk through the commit sequence looking
for where a copy of each item should be inserted.

The heart of the code would be a predicate that takes as arguments the
following:

   * the git commit date
   * the git commit committer ID
   * a ChangeLog entry date
   * a ChangeLog author ID

and returns yes or no according as the entry should or should not be appended
to the comment of the specified commit.

Good luck writing a predicate that produces consistently reasonable results.
Here are some of the complications:

   * ChangeLog entry dates only have resolution to a day

   * The commit dates are unreliable both due to clock skew and unreported
     time-zone offsets (remember CVS commit stamps are taken client side)

   * Git committer IDs may not match ChangeLog committer IDs even if they
     were the same persion. There are just too many ways for email addresses
     and personal names to have variations that are transparent to a human
     but not to a string-matching algorithm.

As an example of the latter, I've often run into situations where a committer
used a correct spelling of his name (featuring, for example, a Latin-1 umlaut)
one context and a plain-ASCII approximtion in the other.

My prediction is that the attempt will not end well.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: CVS woes

Mojca Miklavec
On 24 November 2015 at 23:15, Eric S. Raymond <[hidden email]> wrote:

> Daniel J Sebald <[hidden email]>:
>> >But the real show-stopper is that, if this project is anything like
>> >typical, a single ChangeLog entry often actually summarizes work from
>> >*multiple* commits.  It may not be clear which ones, since one of
>> >the bedevilling quirks of older CVSes was that commit timestamps were
>> >take *client-side* and tended to be flaky.
>>
>> Could the documentation be integrated into the git commit history in an
>> approximate way?  Say, associate all the comments for a particular day with
>> the last CVS entry for that date?  But it would have to be that the full
>> Changelog header and date appears in the comment.  So for example, one
>> commit message might have three Changelog entries listed.  It would only be
>> an approximate alignment of commit messages and the changelog, but anyone
>> who would go through the history to manually decipher and reconstruct things
>> would be faced with an approximate association with what is in CVS anyway.
>
> Yes, something like that could be attempted.  The reason it's never been done
> is that the implementation would be a swamp of complexity, and the results of
> very dubious quality.
>
> The easiest way I could imagine to do it (all the alternatives would require
> a larger volume of custom code) would be to:
>
> (1) Write a Python program that could convert the entire sequence of ChangeLog
> into a shelf object keyed by date, with the values being a pair consisting of
> a name and the comment text.
>
> (2) Write a custom plugin for reposurgeon that would load the shelf object
> produced by the previous program and walk through the commit sequence looking
> for where a copy of each item should be inserted.
>
> The heart of the code would be a predicate that takes as arguments the
> following:
>
>    * the git commit date
>    * the git commit committer ID
>    * a ChangeLog entry date
>    * a ChangeLog author ID
>
> and returns yes or no according as the entry should or should not be appended
> to the comment of the specified commit.
>
> Good luck writing a predicate that produces consistently reasonable results.
> Here are some of the complications:
>
>    * ChangeLog entry dates only have resolution to a day
>
>    * The commit dates are unreliable both due to clock skew and unreported
>      time-zone offsets (remember CVS commit stamps are taken client side)
>
>    * Git committer IDs may not match ChangeLog committer IDs even if they
>      were the same persion. There are just too many ways for email addresses
>      and personal names to have variations that are transparent to a human
>      but not to a string-matching algorithm.
>
> As an example of the latter, I've often run into situations where a committer
> used a correct spelling of his name (featuring, for example, a Latin-1 umlaut)
> one context and a plain-ASCII approximtion in the other.
>
> My prediction is that the attempt will not end well.

Honestly I don't see the reason to attempt this. The Gnuplot's
ChangeLog seems like a manually written document to me, usually citing
the real authors of patches, while the CVS log would mention the
committer.

Unless someone goes through the list semi-manually, I don't see a way
to make this work reliably and I also don't see any reason to do so
now as a prerequisite for the conversion. Anyone can check the old
ChangeLog and then find the relevant release in the git log if needed.

Mojca

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

CVS woes: deps

Plotter-2
In reply to this post by Plotter-2
Hi,


 >>
The jive is now sorted out; CVS is accessible again.
Allin Cottrell
 >>

Thanks for the heads up, good to see this back in action.

I am trying to build on a new x86_64 Fedora installation. After a bit of
poking and encouragement it did get through ./configure --with-qt but
with a rather odd warming:

configure: WARNING: The Qt terminal will use Qt5.

Why is that a warming, is it expected to give problems?

After compiling a fair amount of qt related sfuff, it finally dropped
out with this:


make

....

/usr/lib64/qt5/bin/lrelease qtterminal/po/qtgnuplot_fr.ts -qm
qtgnuplot_fr.qm
make[4]: /usr/lib64/qt5/bin/lrelease: Command not found
Makefile:1282: recipe for target 'qtgnuplot_fr.qm' failed



Is the a missing -devel package that the automake tools failed to test
for, or what? Any suggestions ?

TIA, Peter.


------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: CVS woes: wxt fails

Plotter-2
Hi,

Building current CVS gnuplot on Fedora 23 x68_64, I found I had to
explicitly give the WXDIR to get it to configure wxt terminal:

./configure --prefix=/usr/local --with-qt --with-wx=/usr/libexec/wxGTK3

It still fails half way throught the wxt stuff:

<code>

wxterminal/wxt_gui.cpp:4197:1: warning: ‘virtual void
wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated: use
SetInitialSize() instead. [-Wdeprecated-declarations]
  }
  ^
In file included from /usr/include/wx-3.0/wx/wx.h:38:0,
                  from wxterminal/wxt_gui.h:77,
                  from wxterminal/wxt_gui.cpp:97:
/usr/include/wx-3.0/wx/window.h:1872:13: note: declared here
  inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
              ^
Makefile:926: recipe for target 'wxterminal/wxt_gui.o' failed
make[4]: *** [wxterminal/wxt_gui.o] Error 1

</code>


There is a raft ( hundreds ) of such deprecation warnings that make it
difficult to find the original error.

Is there a way to turn off these warnings so that I can see what is
going wrong?

Thanks, Peter.


------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: CVS woes: wxt fails

Daniel J Sebald
On 11/25/2015 02:39 AM, [hidden email] wrote:

> Hi,
>
> Building current CVS gnuplot on Fedora 23 x68_64, I found I had to
> explicitly give the WXDIR to get it to configure wxt terminal:
>
> ./configure --prefix=/usr/local --with-qt --with-wx=/usr/libexec/wxGTK3
>
> It still fails half way throught the wxt stuff:
>
> <code>
>
> wxterminal/wxt_gui.cpp:4197:1: warning: ‘virtual void
> wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated: use
> SetInitialSize() instead. [-Wdeprecated-declarations]
>    }
>    ^
> In file included from /usr/include/wx-3.0/wx/wx.h:38:0,
>                    from wxterminal/wxt_gui.h:77,
>                    from wxterminal/wxt_gui.cpp:97:
> /usr/include/wx-3.0/wx/window.h:1872:13: note: declared here
>    inline void wxWindowBase::SetInitialBestSize(const wxSize&  size)
>                ^
> Makefile:926: recipe for target 'wxterminal/wxt_gui.o' failed
> make[4]: *** [wxterminal/wxt_gui.o] Error 1
>
> </code>
>
>
> There is a raft ( hundreds ) of such deprecation warnings that make it
> difficult to find the original error.
>
> Is there a way to turn off these warnings so that I can see what is
> going wrong?

Sometimes the warnings and errors go to separate streams, e.g., stdout
vs. stderr.  Try redirecting the output of the compilation to file and
see if there is anything left behind that looks like an error.

Dan

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: CVS woes: deps

Ethan Merritt
In reply to this post by Plotter-2



On Wed, 25 Nov 2015, [hidden email] wrote:

> Hi,
>
>
> >>
> The jive is now sorted out; CVS is accessible again.
> Allin Cottrell
> >>
>
> Thanks for the heads up, good to see this back in action.
>
> I am trying to build on a new x86_64 Fedora installation. After a bit of
> poking and encouragement it did get through ./configure --with-qt but
> with a rather odd warming:
>
> configure: WARNING: The Qt terminal will use Qt5.
>
> Why is that a warming, is it expected to give problems?
>
> After compiling a fair amount of qt related sfuff, it finally dropped
> out with this:
>
>
> make
>
> ....
>
> /usr/lib64/qt5/bin/lrelease qtterminal/po/qtgnuplot_fr.ts -qm
> qtgnuplot_fr.qm
> make[4]: /usr/lib64/qt5/bin/lrelease: Command not found
> Makefile:1282: recipe for target 'qtgnuplot_fr.qm' failed
>
>
>
> Is the a missing -devel package that the automake tools failed to test
> for, or what? Any suggestions ?

qt5 lrelease is in package qttools5

The error should not be fatal, as the only thing not built is the
french and japanese translations of the error messages. Possibly
it will also want the i18n locale support for French and Japanese.

    Ethan

>
> TIA, Peter.
>
>
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
> _______________________________________________
> gnuplot-beta mailing list
> [hidden email]
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>


------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: CVS woes: deps

Plotter-2
On 25/11/15 10:07, Ethan A Merritt wrote:

>
>
>
> On Wed, 25 Nov 2015, [hidden email] wrote:
>
>> Hi,
>>
>>
>> >>
>> The jive is now sorted out; CVS is accessible again.
>> Allin Cottrell
>> >>
>>
>> Thanks for the heads up, good to see this back in action.
>>
>> I am trying to build on a new x86_64 Fedora installation. After a bit of
>> poking and encouragement it did get through ./configure --with-qt but
>> with a rather odd warming:
>>
>> configure: WARNING: The Qt terminal will use Qt5.
>>
>> Why is that a warming, is it expected to give problems?
>>
>> After compiling a fair amount of qt related sfuff, it finally dropped
>> out with this:
>>
>>
>> make
>>
>> ....
>>
>> /usr/lib64/qt5/bin/lrelease qtterminal/po/qtgnuplot_fr.ts -qm
>> qtgnuplot_fr.qm
>> make[4]: /usr/lib64/qt5/bin/lrelease: Command not found
>> Makefile:1282: recipe for target 'qtgnuplot_fr.qm' failed
>>
>>
>>
>> Is the a missing -devel package that the automake tools failed to test
>> for, or what? Any suggestions ?
>
> qt5 lrelease is in package qttools5
>
> The error should not be fatal, as the only thing not built is the
> french and japanese translations of the error messages. Possibly
> it will also want the i18n locale support for French and Japanese.
>
>     Ethan
>
>>
>> TIA, Peter.
>>


Thanks Ethan,

I added qt5-qttools and qt5-qttools-devel packages ( which pulled in a
total of 10 new pkgs ).

after make clean and config it built with qt.

This seems to raise a question about the automake sniffing:
1. Why does it not detect the need for these packages during config

Since I have fr language support configured in by some GUI tool, it may
be correct that failed.

Regards, Peter.



------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: CVS woes: wxt fails

Plotter-2
In reply to this post by Daniel J Sebald
On 25/11/15 09:26, Daniel J Sebald wrote:

> On 11/25/2015 02:39 AM, [hidden email] wrote:
>> Hi,
>>
>> Building current CVS gnuplot on Fedora 23 x68_64, I found I had to
>> explicitly give the WXDIR to get it to configure wxt terminal:
>>
>> ./configure --prefix=/usr/local --with-qt --with-wx=/usr/libexec/wxGTK3
>>
>> It still fails half way throught the wxt stuff:
>>
>> <code>
>>
>> wxterminal/wxt_gui.cpp:4197:1: warning: ‘virtual void
>> wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated: use
>> SetInitialSize() instead. [-Wdeprecated-declarations]
>>    }
>>    ^
>> In file included from /usr/include/wx-3.0/wx/wx.h:38:0,
>>                    from wxterminal/wxt_gui.h:77,
>>                    from wxterminal/wxt_gui.cpp:97:
>> /usr/include/wx-3.0/wx/window.h:1872:13: note: declared here
>>    inline void wxWindowBase::SetInitialBestSize(const wxSize&  size)
>>                ^
>> Makefile:926: recipe for target 'wxterminal/wxt_gui.o' failed
>> make[4]: *** [wxterminal/wxt_gui.o] Error 1
>>
>> </code>
>>
>>
>> There is a raft ( hundreds ) of such deprecation warnings that make it
>> difficult to find the original error.
>>
>> Is there a way to turn off these warnings so that I can see what is
>> going wrong?
>
> Sometimes the warnings and errors go to separate streams, e.g., stdout
> vs. stderr.  Try redirecting the output of the compilation to file and
> see if there is anything left behind that looks like an error.
>
> Dan
>

Ah, good idea Dan.

make 2>stderr.log

redirecting stderr to a file and searching for "error" found this. It
seems it is doing an ungodly mix of gtk2.0 and gtk3.0

============

In file included from /usr/include/gtk-2.0/gdk/gdkscreen.h:32:0,
                  from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:31,
                  from /usr/include/gtk-2.0/gdk/gdk.h:32,
                  from wxterminal/wxt_gui.h:191,
                  from wxterminal/wxt_gui.cpp:97:
/usr/include/gtk-2.0/gdk/gdktypes.h:114:39: error: conflicting
declaration ‘typ$
  typedef struct _GdkDrawable           GdkWindow;
                                        ^
In file included from /usr/include/wx-3.0/wx/wxprec.h:12:0,
                  from wxterminal/wxt_gui.h:75,
                  from wxterminal/wxt_gui.cpp:97:
/usr/include/wx-3.0/wx/defs.h:3412:31: note: previous declaration as
‘typedef s$
      typedef struct _GdkWindow GdkWindow;
                                ^
=============

This is probably since I had to provide it with a WXDIR since it could
not find it on its own.

However the only wx-config on the system is that which I gave it :
/usr/libexec/wxGTK3/wx-config

If I don't give it a WXDIR in configure it configures to build without wxt.

Fedora seems to offer some kind of gtk3-gtk2 compatability lib ,
installing this got a bit further:

Installing:
  compat-wxBase3-gtk2          x86_64     3.0.2-5.1.fc23        fedora
    1.1 M
  compat-wxGTK3-gtk2           x86_64     3.0.2-5.1.fc23        fedora
    5.4 M
  compat-wxGTK3-gtk2-devel     x86_64     3.0.2-5.1.fc23        fedora
    1.3 M
  compat-wxGTK3-gtk2-gl        x86_64     3.0.2-5.1.fc23        fedora
     35 k
  compat-wxGTK3-gtk2-media     x86_64     3.0.2-5.1.fc23        fedora
     56 k

I still need to tell it where to find wx-config otherwise it builds
without wxt

./configure --prefix=/usr/local --without-qt
--with-wx=/usr/libexec/compat-wxGTK3-gtk2/

Now it seems to fail at the linker stage.

/bin/ld: wxterminal/wxt_gui.o: undefined reference to symbol 'XInitThreads'
/usr/lib64/libX11.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[4]: *** [gnuplot] Error 1


I'm a bit included just to give up on wxt and use qt, but from a
development point of view I suppose this should work.

I don't think I'm trying to do anything particularly odd-ball here. Any
suggestions?

Thanks,  Peter.

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: CVS woes: pango

Plotter-2
In reply to this post by Plotter-2
Hi,

I have a sufficiently new version of pango installed :

dnf install pango pango-devel
...

Package pango-1.38.1-1.fc23.x86_64 is already installed, skipping.
Package pango-devel-1.38.1-1.fc23.x86_64 is already installed, skipping.

Yet configure is not finding it .

checking for CAIROPANGO... yes
checking for PANGO_1_10_2... no

I don't think that this has any bearing of the other issues but it does
seem to be another thing that is not working properly on current fedora
23 ( x86_64 LXDE spin ) .

Peter.


------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: CVS woes: wxt fails

Daniel J Sebald
In reply to this post by Plotter-2
On 11/25/2015 07:48 AM, [hidden email] wrote:

> On 25/11/15 09:26, Daniel J Sebald wrote:
>> On 11/25/2015 02:39 AM, [hidden email] wrote:
>>> Hi,
>>>
>>> Building current CVS gnuplot on Fedora 23 x68_64, I found I had to
>>> explicitly give the WXDIR to get it to configure wxt terminal:
>>>
>>> ./configure --prefix=/usr/local --with-qt --with-wx=/usr/libexec/wxGTK3
>>>
>>> It still fails half way throught the wxt stuff:
>>>
>>> <code>
>>>
>>> wxterminal/wxt_gui.cpp:4197:1: warning: ‘virtual void
>>> wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated: use
>>> SetInitialSize() instead. [-Wdeprecated-declarations]
>>> }
>>> ^
>>> In file included from /usr/include/wx-3.0/wx/wx.h:38:0,
>>> from wxterminal/wxt_gui.h:77,
>>> from wxterminal/wxt_gui.cpp:97:
>>> /usr/include/wx-3.0/wx/window.h:1872:13: note: declared here
>>> inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
>>> ^
>>> Makefile:926: recipe for target 'wxterminal/wxt_gui.o' failed
>>> make[4]: *** [wxterminal/wxt_gui.o] Error 1
>>>
>>> </code>
>>>
>>>
>>> There is a raft ( hundreds ) of such deprecation warnings that make it
>>> difficult to find the original error.
>>>
>>> Is there a way to turn off these warnings so that I can see what is
>>> going wrong?
>>
>> Sometimes the warnings and errors go to separate streams, e.g., stdout
>> vs. stderr. Try redirecting the output of the compilation to file and
>> see if there is anything left behind that looks like an error.
>>
>> Dan
>>
>
> Ah, good idea Dan.
>
> make 2>stderr.log
>
> redirecting stderr to a file and searching for "error" found this. It
> seems it is doing an ungodly mix of gtk2.0 and gtk3.0
>
> ============
>
> In file included from /usr/include/gtk-2.0/gdk/gdkscreen.h:32:0,
> from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:31,
> from /usr/include/gtk-2.0/gdk/gdk.h:32,
> from wxterminal/wxt_gui.h:191,
> from wxterminal/wxt_gui.cpp:97:
> /usr/include/gtk-2.0/gdk/gdktypes.h:114:39: error: conflicting
> declaration ‘typ$
> typedef struct _GdkDrawable GdkWindow;
> ^
> In file included from /usr/include/wx-3.0/wx/wxprec.h:12:0,
> from wxterminal/wxt_gui.h:75,
> from wxterminal/wxt_gui.cpp:97:
> /usr/include/wx-3.0/wx/defs.h:3412:31: note: previous declaration as
> ‘typedef s$
> typedef struct _GdkWindow GdkWindow;
> ^
> =============
>
> This is probably since I had to provide it with a WXDIR since it could
> not find it on its own.
>
> However the only wx-config on the system is that which I gave it :
> /usr/libexec/wxGTK3/wx-config
>
> If I don't give it a WXDIR in configure it configures to build without wxt.
>
> Fedora seems to offer some kind of gtk3-gtk2 compatability lib ,
> installing this got a bit further:
>
> Installing:
> compat-wxBase3-gtk2 x86_64 3.0.2-5.1.fc23 fedora 1.1 M
> compat-wxGTK3-gtk2 x86_64 3.0.2-5.1.fc23 fedora 5.4 M
> compat-wxGTK3-gtk2-devel x86_64 3.0.2-5.1.fc23 fedora 1.3 M
> compat-wxGTK3-gtk2-gl x86_64 3.0.2-5.1.fc23 fedora 35 k
> compat-wxGTK3-gtk2-media x86_64 3.0.2-5.1.fc23 fedora 56 k
>
> I still need to tell it where to find wx-config otherwise it builds
> without wxt
>
> ./configure --prefix=/usr/local --without-qt
> --with-wx=/usr/libexec/compat-wxGTK3-gtk2/
>
> Now it seems to fail at the linker stage.
>
> /bin/ld: wxterminal/wxt_gui.o: undefined reference to symbol 'XInitThreads'
> /usr/lib64/libX11.so.6: error adding symbols: DSO missing from command line
> collect2: error: ld returned 1 exit status
> make[4]: *** [gnuplot] Error 1
>
>
> I'm a bit included just to give up on wxt and use qt, but from a
> development point of view I suppose this should work.
>
> I don't think I'm trying to do anything particularly odd-ball here. Any
> suggestions?

No real good ideas here Peter, sorry.  Only that maybe you could look at
the configuration log and search for the first location where gtk2/3
appears and perhaps try to modify things through a flag or removing some
developer library that would cause gnuplot to not use gtk3.

Also, qt is good, but slower on some systems and faster on others.  I
like both qt and wxt, but I've found quite a few odd bugs in each that I
haven't had time to investigate.

Dan

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
12