automake 1.4-p5 is not new enough
Hi, I'm checking files from CVS and generating the autotools stuff using the ./bootstrap script. My first attempt failed with automake 1.4-p6, then I tried again with automake 1.7 and the result is that it works with 1.7 but doesn't with 1.4-p6 or older. So the note in ./bootstrap script should be fixed, it currently says automake1.4-p5 and later are supported: # helps bootstrapping libtool, when checked out from CVS # requires at least GNU autoconf 2.50 and GNU automake1.4-p5 -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool pre-1.5b tests fail on 9 debian arches
On Sat, Sep 27, 2003 at 04:30:15AM +0100, Scott James Remnant wrote: > On Sat, 2003-09-27 at 06:06, Robert Millan wrote: > > It's not the Debian libtool package which is (generaly) used by upstream > > maintainers to update their libtools. My concern is with upstream packages > > using upstream libtool, hence the Debian package is not relevant. > > > Which therefore makes me wonder why you Cc'd the various Debian ports > lists. We've had an unofficial policy for some time now that porters > will request/require package maintainers to use the Debian libtool > package if things break. Which is an oddly insane policy. Updating libtool is a non-trivial task most of the times and not a simple "libtoolize" run as you could pretend, I can give you examples if you like. I'm asking myself why some Debian porters prefer spending hours mass-filing "update libtool" bugs everytime libtool breaks for them, instead of fixing libtool properly in upstream. > We're all VERY well aware that upstream libtool isn't portable across > all Debian architectures, it doesn't work on arm at all -- and until > recently didn't work on mips, mipsel or m68k either! > > This is precisely why Debian's libtool package contains so many > additional patches, so when things do break we can just tell the > maintainers to update the package with the libtool installed on their > system. Great. So if libtool is broken in upstream and breaks for all the non-Debian world we just don't care? Isn't this a violation of the Debian Social Contract? "We will feed back bug-fixes, improvements, user requests, etc. to the \"upstream\" authors of software included in our system." (http://www.debian.org/social_contract) > It can be, but very often patches or mails I've sent are simply > ignored. I'm almost positive the pass_all patch will be rejected, if > it's ever even considered. And yet without that patch, Linux ARM and > libtool won't be friends. > > [...] > > Not to mention the various copyright problems that GNU will care about > ... a fair chunk is my copyright, but some of the patches which have > fixed Debian problems have come from others -- quite a few off the > -patches list which upstream also ignored, and yet they fixed problems. I'm aware of all this. And I can help you if you like. > There's also the problem that Debian may not be able to continue > distributing the upstream libtool tar file at all, because it contains > non-free material (the GNU FDL licensed documentation) -- at which point > I'll simply fork Debian libtool and maintain it by merging every so > often with GNU libtool. So you want to fork a project because it contains non-free components? I've been maintaining Bochs and Plex86 in Debian for quite some time now. They have _always_ come with the non-free VGA BIOS, and I just removed it with every update. Never considered forking for such a reason. > I don't see the distinction between testing with Debian's libtool > package, or the upstream libtool with Debian's patches applied? Nor do I. But you can't ask all developers of packages using libtool to start using either of these instead of the official libtool releases. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool pre-1.5b tests fail on 9 debian arches
On Sat, Sep 27, 2003 at 07:26:20PM +0100, Scott James Remnant wrote: > Updating to any later version of Libtool is the same amount of work, > whether it be the Debian-patched version or not. Most of the time, when > build failures occur, the package upstream is using either an insanely > out of date version anyway and needs updating whatever the case. That implies asking upstream to update their libtool using upstream libtool in first place, then replacing it with debian's libtool. Asides from the time-consuming effort this represents, the following are examples of problems that may (and usualy do) occur: - libtool.m4 is in a non-standard location or even with a different name; go search for it. - aclocal.m4 won't regenerate with your version of aclocal, and the version upstream used is not present in Debian (e.g: 1.7.6) - configure won't regenerate with your version of autoconf, and the version upstream used is not present in Debian (e.g: 2.53) Add here the fact that upstream is not responsive, and you get a whole can of worms. And this is only _one_ package, porters have to port hundreds of them. Of course, this is only for the situation when upstream updates their upstream libtool for you. When you have to update between different versions of libtool, you'll hit incompatibility errors (missing --tag option, anyone?). > The reason porters tell maintainers to use the Debian libtool package > and not the upstream version is simple... They've generally grabbed me > on IRC and we've gone through the build logs, and in some cases our > libtool package has been patched and uploaded first. Agreed. When a broken libtool has already been released, there's not much thing to do other than maintaining all these patches in Debian. > Getting appropriate patches submitted upstream is a difficult task, and > I'm not the only person who believes so, it is something I want to do > and have been trying to do, but it's proving hard work to get replies > half the time! We should start doing that, and I can help. Just requested copyright papers myself (I assume you've already done that). libtool maintainers: Would you consider giving either Scott or me (preferably both) with CVS access? That'd help a lot getting libtool in shape for all architectures without having to maintain such a "debian fork" of libtool. > [...] > If that makes sense? I wasn't intending to infer a new libtool project, > I was trying to indicate we wouldn't be able to use the original > upstream tar file in the package anymore. Yep, it makes sense now. (it's just the same I've been doing for Bochs) > I sent an e-mail over a month ago to open a discussion about this > problem, and it went unanswered. Let's reopen it. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool pre-1.5b tests fail on 9 debian arches
On Sat, Sep 27, 2003 at 08:04:55PM +0100, Scott James Remnant wrote: > > Or an even better one, just from build failures in the last few days ... > upstream placing the contents of libtool.m4 in acinclude.m4, so even > after aclocal runs the old version is still used. > > One thing about maintaining a GNU auto tools package, you certainly see > some brain dead practises by other upstream developers. Do these guys > not read the manuals? :) Many of them don't, and we have to live with that. > > We should start doing that, and I can help. Just requested copyright papers > > myself (I assume you've already done that). > > > > libtool maintainers: Would you consider giving either Scott or me (preferably > > both) with CVS access? That'd help a lot getting libtool in shape for all > > architectures without having to maintain such a "debian fork" of libtool. > > > I brought it up about six months ago (about the same time I sorted > through all the patches), I'm quite willing to undergo the paper signing > -- . Assigning copyright and being given CVS access is not necessarily related: - If you send too many patches for review without having CVS access, then you might consider assigning copyright so that you can send more patches for review. - Sometimes GNU maintainers agree to give you CVS access before the actual paper signing process is complete, provided that you agree not to commit more code of your own than you're allowed to. (this is my current situation with GNU GRUB, for example). Scott: IMO all Debian maintainers of GNU software should do this as part of their maintaining task. Please request assigning copyright for past and future changes to libtool by emailing "[EMAIL PROTECTED]". libtool maintainers: On having CVS access, I myself would agree to apply only non-conflictive patches (such as my GNU/K*BSD stuff) unless otherwise discussed in the list (I believe the same applies to Scott). If you need credentials, I'm member of Debian and have already access to GRUB CVS. Does all this sound ok for you? > > Let's reopen it. > > > Gary, Peter, Bob? Probably the best compromise all round would be to > add something like this to libtool.texi below the current permission > statements: > > [...] When I suggested to reopen it, I thought you were referring to the patch submission issue, not the GFDL stuff. GNU libtool is copyrighted by the FSF and only the FSF may license it under additional terms. It's not something you should discuss with libtool's maintainers, nor something that should be discussed on this list. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool pre-1.5b tests fail on 9 debian arches
On Sun, Sep 28, 2003 at 10:17:34AM -0500, Bob Friesenhahn wrote: > > - If you send too many patches for review without having CVS access, then you > >might consider assigning copyright so that you can send more patches for > >review. > > The FSF guidelines specify allow to 14 lines of *total* contribution > from an author without copyright assignment. It doesn't take many > small patches to reach this level. That's right.. well I always try to assign copyright after my first patch of commited code. > > - Sometimes GNU maintainers agree to give you CVS access before the actual > >paper signing process is complete, provided that you agree not to commit > >more code of your own than you're allowed to. (this is my current situation > >with GNU GRUB, for example). > > I believe that this practice is contrary to the agreement we sign with > the FSF. If word-of-mouth and personal trust was sufficient, then > there would be no need for paper contracts. The SCO/Linux situation > is evidence that these are not minor issues. Uhm.. Perhaps Okuji was confused on this. Well my signed papers for GRUB are fortunately on the way back. I'll make sure this error doesn't happen with me again. > > Scott: IMO all Debian maintainers of GNU software should do this as part of > > their maintaining task. Please request assigning copyright for past and future > > changes to libtool by emailing "[EMAIL PROTECTED]". > > Very good idea. However, always keep in mind that if someone sends a > patch to a person with signed paperwork, then the recipient is not > the author of the patch and the situation has not significantly > improved. I'm well aware of this. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
CVS head requires am-1.8 and ac-2.58
Hi! I just noticed that with latest Gary's commit running the "bootstrap" script from libtool CVS HEAD now requires automake 1.8 and autoconf 2.58. As I already commented on this list, I'm going through the task of testing libtool on a variety of CPUs and asking the Debian port maintainers for help fixing the various problems encountered. Since none of autoconf 2.58 or automake 1.8 are released yet, it's a bit impractical for us to prepare a CVS snapshot for testing and it'd be more convenient if a pre-release tarball was available. Please, could you provide a pre-release tarball with that doesn't require unreleased autotools versions? That'd help much my current testing efforts. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool pre-1.5b tests fail on 9 debian arches
[ CCing to debian maintainer and libtool upstream ] Hi there folks. The libtool upstream maintainers are preparing a new 1.5b release. On their behalf I've recently attempted to test a snapshot from CVS branch-1-5 on all architectures Debian supports (or pretends to support) that I had access to. The results (below) are unfavorable on at least 4 arches, and undetermined on 5 more arches. For any arch that is not marked "ok" below, someone should _urgently_ test and/or fix it before libtool 1.5b is released. For those of you unaware of the insanely detrimental consequences a brokenly released libtool can have for your port, see footnote [5]. For testing libtool branch-1-5, get a CVS snapshot while passing "-r branch-1-5" to the checkout command, and run: export CVSROOT=:pserver:[EMAIL PROTECTED]:/cvsroot/libtool cvs -z9 co -r branch-1-5 libtool ; cd libtool ./bootstrap && ./configure && make && make check host - cpu - test result gluck i386ok voltairepowerpc ok merulo ia6417 tests failed casals mips?? [3] debussy arm ok escher alpha ok raptor s3903 tests failed paerhppa4 tests failed crest m68k?? [3] voresparc ?? [3] ravel [1] amd64 25 tests failed williamsmipsel ?? [2] ?? sh ?? [4] [1] access by request, see w.d.o/ports/amd64/ [2] williams and vaughan are down [3] test fails due to host-related autotools/texinfo/etc stuff [4] no publicly known developer machine available [5] libtool's released code spreads itself to projects using libtool in a way much similar to autoconf or automake. If a libtool release is broken for a particular arch, then all packages that get their libtool updated in upstream will start to fail for that arch, and need individual patching. This is what recently happened to the mips port. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) signature.asc Description: Digital signature ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool pre-1.5b tests fail on 9 debian arches
On Sat, Sep 27, 2003 at 02:36:13AM +0100, Scott James Remnant wrote: > Actually if it was branch-1-5 you were testing, that'd be the new 1.5.0a > (1.5.1) release. 1.5b would be on HEAD (as far as I understand the > esoteric version numbering upstream use) and a pre-release of > libtool 1.6 (which we know Gary wants to get out of the door alongside > Autoconf 2.58 and Automake 1.8). Gary asked me to test branch-1-5, although he didn't put it very clear wether that branch is for 1.5b or 1.5.0a. Gary, please could you clarify? > Use the Debian libtool package, not only do I currently track CVS rather > than use the pure 1.5 release, there are additional Debian patches added > to make it work on some of the architectures. It's not the Debian libtool package which is (generaly) used by upstream maintainers to update their libtools. My concern is with upstream packages using upstream libtool, hence the Debian package is not relevant. > Getting these patches accepted upstream is tricky though, I've sent some > bug fixes through. A few days ago I decided to have a go getting some > of the portability patches (some of which are large) accepted, I mailed > the smallest (yet one of the more far-reaching ones) to -patches; > haven't had any follow-up yet though. My patch sending policy involves pinging them after a week of not responding, then periodicaly pinging them at increased rate. It's quite effective. Could you try merging all the other patches, so that we can reliably test libtool on all of Debian's arches? > FWIW, I've run the same tests on Debian unstable with the Debian libtool > 1.5-2 package. I've also tried to ascertain *why* tests are failing, it > would've been nice if you could've done the same (or perhaps you're > working on that?) Actualy not. I don't have time to do that, nor experience with cpu porting thingies like endianess, alignment or such. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool pre-1.5b tests fail on 9 debian arches
On Tue, Oct 07, 2003 at 04:36:47PM +0100, Gary V. Vaughan wrote: > My apologies for having taken so long to respond to this thread. My > hacking time is short, and the thread was growing faster than I could read > it... :-) No problem. > >>>libtool maintainers: Would you consider giving either Scott or me > >>>(preferably > >>>both) with CVS access? That'd help a lot getting libtool in shape for all > >>>architectures without having to maintain such a "debian fork" of libtool. > > Absolutely. The FSF will inform me when the paperwork is done, Ok. I'll take care about the paperwork. Scott, will you go through this too? > You must also agree not to commit anything for which you do not have > knowledge of the author, and the author has exchanged paperwork with the > FSF, except for very small patches. No problem. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T, Ainulindale (Silmarillion) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
