Re: libtool pre-1.5b tests fail on 9 debian arches
Oh, to the ode of creating new worms... Robert Millan wrote: 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?). Uhm, if you're testing a new version of libtool against all packages, then what you're doing is pointing out what needs changed to support the new version of libtool. Given that the end user of the source does not have to have any of autotools installed (a GNU Standard requirement), the end user just need to execute ``configure'' for the given package. If configure worked previously, then it should work now given a new verions of libtool is installed. If a configure requires an autotools package be installed then the package isn't following the standard. Standards were created for the purpose of making the process the same and thus everyone knows how to do it standardly. If the package isn't owned by FSF, then so be it. If the package is owned by FSF, then it needs to be forced to follow the standard. 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. But if you're use of libtool isn't standard, then perhaps that is the problem. To require all packages to support the new version of libtool at once is not standard. To require the end user to have autoconf, automake, libtool or other maintainer configuration tools on their systems is not standard. To require the packaged configure script to execute properly without these tools installed is standard, nothing else. 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. And would that get it in shape for everyone else? Why not submit patches that can be reviewed and discussed? [...] 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. Ok, it's open. Now, have the patches been submitted for review? Earnie. -- http://www.mingw.org ___ 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 -- consider this a request. 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, 28 Sep 2003, Robert Millan wrote: Assigning copyright and being given CVS access is not necessarily related: For any substantial updates, copyright is certainly the driving issue. - 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. - 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. 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. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ 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
Re: should libtool check for the correct version of find?
Hello. Matthew Arnison wrote: libtool appears to depend on Unix find. Under Cygwin, an incorrect path can cause the Windows FIND to be used instead. To the untrained eye, (that is, me two days ago) it's not obvious from the output of configure and libtool that this has happened. The only warning I got was this: FIND: Parameter format not correct buried in the make output. The make does not actually fail until about a page later in the transcript when a link fails with a series of undefined reference errors. My suggestion is that libtool should get configure to check for the correct version of find (i.e. Unix find not WINDOWS find) as part of checking the general environment. I feel that configure's job is to check that all the correct tools are in place to do a build, so if libtool is used, then configure/libtool should check which find is being run. [snip] Won't fixing libtool or configure just hide the problem for every other script/program that uses Unixy find out there? FWIW a similar problem exists for DJGPP, a port of GNU tools to DOS/Windows. If DJGPP's bin directory doesn't occur before the Windows ones, then all bets are off. Bye, Rich =] -- Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Official notice to all e-gold users
Dear e-gold account owner! This message was sent to your mailbo because you have an active account. At the end of each month due to our database's maintenance you need to confirm your account's information. To do this please click on the following link to get to the e-gold secure page and re-enter your Account Number and Passphrase. If you don't update your account till the end of the September, it will be freezed. In this case, please mail us. Thank you. https://e-gold.com/acct/login.html ___ 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
