Re: Linda warnings
* Eric Dorland [Substituting your fixed sentence in the text below] | I think a build-dependency on automake and autoconf is almost always | a bad idea. It makes the build more unpredictable, which is | generally a bad thing. You should just run automake and/or autoconf | on the unpacked source and ship it in the .diff.gz. An extra 2K | won't hurt. You can argue this for a lot of files. An example is texinfo files which get their headers updated with information in the language of the build locale. Or why should docs be built as part of the build process at all? Or X fonts? Because we want to test for buildability. We want to make it possible to change any part of the program and barring real errors, it should still build. That upstream writes crap configure.in/.ac and Makefile.ams is not an excuse, it's just a bug which should be fixed. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linda warnings
On Mon, May 30, 2005 at 08:14:09AM +0200, Tollef Fog Heen wrote: * Eric Dorland [Substituting your fixed sentence in the text below] | I think a build-dependency on automake and autoconf is almost always | a bad idea. It makes the build more unpredictable, which is | generally a bad thing. You should just run automake and/or autoconf | on the unpacked source and ship it in the .diff.gz. An extra 2K | won't hurt. You can argue this for a lot of files. An example is texinfo files which get their headers updated with information in the language of the build locale. Or why should docs be built as part of the build process at all? Or X fonts? Because we want to test for buildability. We want to make it possible to change any part of the program and barring real errors, it should still build. That upstream writes crap configure.in/.ac and Makefile.ams is not an excuse, it's just a bug which should be fixed. In the case of toshutils, however, the problem is not crappy configure.in or other such files. The problem is that the latest upstream version shipped about 4 years ago. TTBOMK, GTK2 did not even exist back then. toshutils was written to compile against GTK+. Now, a simple patch that updates configure.in to look for libgtk2.0-dev followed by an autoreconf is all that is needed. Having discussed it with folks, the consensus was that I should take that approach, rather than patch and rerelease the upstream source. The reason for that is that I don't want to give the impression that I am taking over upstream maintenance unless that is what I really intend to do. In this case, everything is working out OK with the build requiring autoconf and automake. So, I am not going to worry about it too much. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpC1tACs3MSK.pgp Description: PGP signature
Re: Linda warnings
* Tollef Fog Heen ([EMAIL PROTECTED]) wrote: * Eric Dorland [Substituting your fixed sentence in the text below] | I think a build-dependency on automake and autoconf is almost always | a bad idea. It makes the build more unpredictable, which is | generally a bad thing. You should just run automake and/or autoconf | on the unpacked source and ship it in the .diff.gz. An extra 2K | won't hurt. You can argue this for a lot of files. An example is texinfo files which get their headers updated with information in the language of the build locale. Or why should docs be built as part of the build process at all? Or X fonts? Because we want to test for buildability. We want to make it possible to change any part of the program and barring real errors, it should still build. That upstream writes crap configure.in/.ac and Makefile.ams is not an excuse, it's just a bug which should be fixed. Well I don't disagree. But either we test every auto* using package this way, or we don't. The auto* tools are designed specifically so that they are not build dependencies. So making it a build dependency seems like a kludge. Now if we wanted to make it a general policy to test whether auto* regeneration works then I have less problem with that, but it would be a lot more work, for very little benefit that I can see. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Linda warnings
On Mon, 2005-05-30 at 03:33 -0400, Eric Dorland wrote: * Tollef Fog Heen ([EMAIL PROTECTED]) wrote: Because we want to test for buildability. We want to make it possible to change any part of the program and barring real errors, it should still build. That upstream writes crap configure.in/.ac and Makefile.ams is not an excuse, it's just a bug which should be fixed. Well I don't disagree. But either we test every auto* using package this way, or we don't. The auto* tools are designed specifically so that they are not build dependencies. So making it a build dependency seems like a kludge. Now if we wanted to make it a general policy to test whether auto* regeneration works then I have less problem with that, but it would be a lot more work, for very little benefit that I can see. The auto* tools are only /not/ a build dependency when one does not change the code. They are explicitly a build dependency for developers. We and the buildds do *not count* as end users - we are patching the code in most cases. So either you don't patch the package, or you be willing to require the relevant auto* be installed. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Linda warnings
* Robert Collins ([EMAIL PROTECTED]) wrote: On Mon, 2005-05-30 at 03:33 -0400, Eric Dorland wrote: * Tollef Fog Heen ([EMAIL PROTECTED]) wrote: Because we want to test for buildability. We want to make it possible to change any part of the program and barring real errors, it should still build. That upstream writes crap configure.in/.ac and Makefile.ams is not an excuse, it's just a bug which should be fixed. Well I don't disagree. But either we test every auto* using package this way, or we don't. The auto* tools are designed specifically so that they are not build dependencies. So making it a build dependency seems like a kludge. Now if we wanted to make it a general policy to test whether auto* regeneration works then I have less problem with that, but it would be a lot more work, for very little benefit that I can see. The auto* tools are only /not/ a build dependency when one does not change the code. They are explicitly a build dependency for developers. Yes, they are necessary tools for developers. But nearly ever project I've ever seen ships the files generated from the auto* tools. We and the buildds do *not count* as end users - we are patching the code in most cases. But most packages aren't patching configure.in's and Makefile.am's. And the buildd is not patching the code, the maintainer is. So either you don't patch the package, or you be willing to require the relevant auto* be installed. Or you put the patch in the .diff.gz. I think that's the best option. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Linda warnings
On Mon, May 30, 2005 at 10:30:56AM -0400, Eric Dorland wrote: * Robert Collins ([EMAIL PROTECTED]) wrote: So either you don't patch the package, or you be willing to require the relevant auto* be installed. Or you put the patch in the .diff.gz. I think that's the best option. Uh, it's not as if adding the patch to the .diff.gz doesn't have its own set of problems... see /usr/share/doc/autotools-dev/README.Debian.gz, search for 'timestamp skew' -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linda warnings
* Wouter Verhelst ([EMAIL PROTECTED]) wrote: On Mon, May 30, 2005 at 10:30:56AM -0400, Eric Dorland wrote: * Robert Collins ([EMAIL PROTECTED]) wrote: So either you don't patch the package, or you be willing to require the relevant auto* be installed. Or you put the patch in the .diff.gz. I think that's the best option. Uh, it's not as if adding the patch to the .diff.gz doesn't have its own set of problems... see /usr/share/doc/autotools-dev/README.Debian.gz, search for 'timestamp skew' I did forget that aspect, but of course liberal touch'ing can get you around those problems. Also automake's use of missing tends to make things just work even with timestamp skew (http://sources.redhat.com/automake/automake.html#maintainer_002dmode). Maintainer-mode is also a good solution. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Linda warnings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Dorland wrote: Yes, they are necessary tools for developers. But nearly ever project I've ever seen ships the files generated from the auto* tools. However I feel the use of a build-dependency is a legitimate one if the package is built directly from the upstream's tagged SCM sources and thus contains no Autotools output. Kind regards, Philipp Kern -BEGIN PGP SIGNATURE- Comment: Fingerprint: 1710 7DB1 9A28 42FF B699 7654 ED1A 3933 B2CF CDD8 Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iEYEARECAAYFAkKbcuIACgkQ7Ro5M7LPzdhBVwCePCCQ6BnkbAElemgSvROyEGdt 1JMAoIRxeJQG4wr8viOWVSIYZ0Wj+NOC =L7iY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linda warnings
* Philipp Kern ([EMAIL PROTECTED]) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Dorland wrote: Yes, they are necessary tools for developers. But nearly ever project I've ever seen ships the files generated from the auto* tools. However I feel the use of a build-dependency is a legitimate one if the package is built directly from the upstream's tagged SCM sources and thus contains no Autotools output. Why? Just run auto* on the unpacked tarball and ship them in the .diff.gz? What makes it more legitimate in that case? That the upstream developers didn't run the autotools? They would have, if it were a proper release. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Linda warnings
Eric Dorland wrote: Why? Just run auto* on the unpacked tarball and ship them in the .diff.gz? What makes it more legitimate in that case? That the upstream developers didn't run the autotools? They would have, if it were a proper release. Well, I did not talk about regular snapshots, but about direct exports. Some tools in Debian (like darcs-buildpackage, thank you John for this) make it possible to make such SCM builds. However the Autotools output is not versioned, so not included in the tarball. Could you please state why it is discouraged? I could not find it in the thread. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linda warnings
Well, I did not talk about regular snapshots, but about direct exports. Some tools in Debian (like darcs-buildpackage, thank you John for this) make it possible to make such SCM builds. However the Autotools output is not versioned, so not included in the tarball. It is possible to run autoreconf with both cvs-buildpackage and arch-buildpackage. If darcs-buildpackage can't run a prebuild trigger or target, I'd say that it's deficient. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linda warnings
[Roberto C. Sanchez] W: toshutils; Package Build-Depends on automake* or autoconf. This package Build-Depends on automake* or autoconf. This is almost never a good idea, as the package should run autoconf or automake on the source tree before the source package is built. There's lots of debate about this one. If your package uses horrible macros and kludges to make everything work, you may wish to play it cautious and manually run the same version of autoconf upstream uses. If it doesn't, in my view it's the responsibility of the autoconf maintainer to ensure that what he packages doesn't break arbitrary documented features. The big problem was autoconf 2.13 - 2.5x, but it's easy enough to make sure you run the correct one of those. automake1.x seems reasonable to depend on, since the maintainer has provided multiple versioned packages, so you can reasonably expect the API not to change within a single package. W: toshutils; The file config.guess contains a timestamp line that is less than 2002. The autoconf file shown above contains a timestamp variable that has a year that is less than 2002. This means you need to update your autoconf files, as the current files will make it hard for your package to auto-build. W: toshutils; The file config.sub contains a timestamp line that is less than 2002. Build-depend on autotools-dev, and copy /usr/share/misc/config.guess and config.sub into place at build time. ln -fs also works. It's a very light build dep, so there's not much point in patching the right files into the source diff.gz. (However, note that if you don't want to bloat your diff.gz you may wish to mv the old files out of the way, and mv them back in your 'clean' target.) W: toshutils; The command xmessage -timeout 10 `fan -f` listed in a menu file does not exist. W: toshutils; The command xmessage -timeout 10 `fan -n` listed in a menu file does not exist. W: toshutils; The command xmessage -timeout 10 `fan` listed in a menu file does not exist. Those seem pretty legitimate, although there's an argument to be made that menu should provide a syntax for this type of status display, so individual apps don't have to do it by hand. (Some window managers and desktop environments might have alternative facilities to xmessage, better integrated into their own weltanschauung.) signature.asc Description: Digital signature
Re: Linda warnings
On Sun, May 29, 2005 at 01:31:31PM -0500, Peter Samuelson wrote:
[Roberto C. Sanchez]
W: toshutils; The file config.guess contains a timestamp line that is
less than 2002.
The autoconf file shown above contains a timestamp variable that has a
year that is less than 2002. This means you need to update your
autoconf files, as the current files will make it hard for your
package to auto-build.
W: toshutils; The file config.sub contains a timestamp line that is less
than 2002.
Build-depend on autotools-dev, and copy /usr/share/misc/config.guess
and config.sub into place at build time. ln -fs also works. It's a
very light build dep, so there's not much point in patching the right
files into the source diff.gz. (However, note that if you don't want
to bloat your diff.gz you may wish to mv the old files out of the way,
and mv them back in your 'clean' target.)
If you are using dpatch then consider using a patch like
/usr/share/doc/dpatch/examples/dpatch/01_config.dpatch.gz
which does the updating of config.{guess,sub}.
-Ralf.
--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linda warnings
On Sun, May 29, 2005 at 01:31:31PM -0500, Peter Samuelson wrote: [Roberto C. Sanchez] W: toshutils; Package Build-Depends on automake* or autoconf. This package Build-Depends on automake* or autoconf. This is almost never a good idea, as the package should run autoconf or automake on the source tree before the source package is built. There's lots of debate about this one. If your package uses horrible macros and kludges to make everything work, you may wish to play it cautious and manually run the same version of autoconf upstream uses. If it doesn't, in my view it's the responsibility of the autoconf maintainer to ensure that what he packages doesn't break arbitrary documented features. The big problem was autoconf 2.13 - 2.5x, but it's easy enough to make sure you run the correct one of those. automake1.x seems reasonable to depend on, since the maintainer has provided multiple versioned packages, so you can reasonably expect the API not to change within a single package. The only reason I need to them is to autoreconf. I have incorporated a patch from ALT Linux that sets up thoshutils to use GTK2. It does this by modifying the configure.in to look for GTK2 instead of GTK+. Thus, the need for autoconf and automake. W: toshutils; The file config.guess contains a timestamp line that is less than 2002. The autoconf file shown above contains a timestamp variable that has a year that is less than 2002. This means you need to update your autoconf files, as the current files will make it hard for your package to auto-build. W: toshutils; The file config.sub contains a timestamp line that is less than 2002. Build-depend on autotools-dev, and copy /usr/share/misc/config.guess and config.sub into place at build time. ln -fs also works. It's a very light build dep, so there's not much point in patching the right files into the source diff.gz. (However, note that if you don't want to bloat your diff.gz you may wish to mv the old files out of the way, and mv them back in your 'clean' target.) OK. No problem. W: toshutils; The command xmessage -timeout 10 `fan -f` listed in a menu file does not exist. W: toshutils; The command xmessage -timeout 10 `fan -n` listed in a menu file does not exist. W: toshutils; The command xmessage -timeout 10 `fan` listed in a menu file does not exist. Those seem pretty legitimate, although there's an argument to be made that menu should provide a syntax for this type of status display, so individual apps don't have to do it by hand. (Some window managers and desktop environments might have alternative facilities to xmessage, better integrated into their own weltanschauung.) I agree. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpZfe93NM0CR.pgp Description: PGP signature
Re: Linda warnings
On Sun, May 29, 2005 at 01:31:31PM -0500, Peter Samuelson wrote: Build-depend on autotools-dev, and copy /usr/share/misc/config.guess and config.sub into place at build time. ln -fs also works. It's a very light build dep, so there's not much point in patching the right files into the source diff.gz. (However, note that if you don't want to bloat your diff.gz you may wish to mv the old files out of the way, and mv them back in your 'clean' target.) Personnaly I just patch them this way (and build-dep on autotools-dev). @@ -1,4 +1,10 @@ #! /bin/sh +# autotools-dev hack ([EMAIL PROTECTED], Wed, 14 Nov 2001 10:13:10 +0100) +if [ -x /usr/share/misc/config.guess ]; then + /usr/share/misc/config.guess $@ + exit $? +fi + # Attempt to guess a canonical system name. # Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001 # Free Software Foundation, Inc. This way I get a small, obvious diff. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linda warnings
* Peter Samuelson ([EMAIL PROTECTED]) wrote: [Roberto C. Sanchez] W: toshutils; Package Build-Depends on automake* or autoconf. This package Build-Depends on automake* or autoconf. This is almost never a good idea, as the package should run autoconf or automake on the source tree before the source package is built. There's lots of debate about this one. If your package uses horrible macros and kludges to make everything work, you may wish to play it cautious and manually run the same version of autoconf upstream uses. If it doesn't, in my view it's the responsibility of the autoconf maintainer to ensure that what he packages doesn't break arbitrary documented features. The big problem was autoconf 2.13 - 2.5x, but it's easy enough to make sure you run the correct one of those. automake1.x seems reasonable to depend on, since the maintainer has provided multiple versioned packages, so you can reasonably expect the API not to change within a single package. I don't think a dependency on automake and autoconf are almost always bad ideas. It makes the build more unpredictable, which is generally a bad thing. You should just run automake and/or autoconf on the unpacked source and ship it in the .diff.gz. An extra 2K won't hurt. W: toshutils; The file config.guess contains a timestamp line that is less than 2002. The autoconf file shown above contains a timestamp variable that has a year that is less than 2002. This means you need to update your autoconf files, as the current files will make it hard for your package to auto-build. W: toshutils; The file config.sub contains a timestamp line that is less than 2002. Build-depend on autotools-dev, and copy /usr/share/misc/config.guess and config.sub into place at build time. ln -fs also works. It's a very light build dep, so there's not much point in patching the right files into the source diff.gz. (However, note that if you don't want to bloat your diff.gz you may wish to mv the old files out of the way, and mv them back in your 'clean' target.) W: toshutils; The command xmessage -timeout 10 `fan -f` listed in a menu file does not exist. W: toshutils; The command xmessage -timeout 10 `fan -n` listed in a menu file does not exist. W: toshutils; The command xmessage -timeout 10 `fan` listed in a menu file does not exist. Those seem pretty legitimate, although there's an argument to be made that menu should provide a syntax for this type of status display, so individual apps don't have to do it by hand. (Some window managers and desktop environments might have alternative facilities to xmessage, better integrated into their own weltanschauung.) -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Linda warnings
* Eric Dorland ([EMAIL PROTECTED]) wrote: I don't think a dependency on automake and autoconf are almost always bad ideas. It makes the build more unpredictable, which is generally a bad thing. You should just run automake and/or autoconf on the unpacked source and ship it in the .diff.gz. An extra 2K won't hurt. My English teachers would kill me. That should read: I think a build-dependency on automake and autoconf is almost always a bad idea... -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Linda warnings
On Sun, May 29, 2005 at 06:49:22PM -0400, Eric Dorland wrote: * Eric Dorland ([EMAIL PROTECTED]) wrote: I don't think a dependency on automake and autoconf are almost always bad ideas. It makes the build more unpredictable, which is generally a bad thing. You should just run automake and/or autoconf on the unpacked source and ship it in the .diff.gz. An extra 2K won't hurt. My English teachers would kill me. That should read: I think a build-dependency on automake and autoconf is almost always a bad idea... No problem. Based on the SubIDs in your GPG key, I consider myself fortunate you did not also answer in French :-) (Sorry, I really couldn't resist). -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpRRQWeoK2dR.pgp Description: PGP signature
Re: Linda warnings
* Roberto C. Sanchez ([EMAIL PROTECTED]) wrote: On Sun, May 29, 2005 at 06:49:22PM -0400, Eric Dorland wrote: * Eric Dorland ([EMAIL PROTECTED]) wrote: I don't think a dependency on automake and autoconf are almost always bad ideas. It makes the build more unpredictable, which is generally a bad thing. You should just run automake and/or autoconf on the unpacked source and ship it in the .diff.gz. An extra 2K won't hurt. My English teachers would kill me. That should read: I think a build-dependency on automake and autoconf is almost always a bad idea... No problem. Based on the SubIDs in your GPG key, I consider myself fortunate you did not also answer in French :-) (Sorry, I really couldn't resist). Sadly, English is my first language. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Linda warnings
On Sun, May 29, 2005 at 06:40:26PM -0400, Eric Dorland wrote: I don't think a dependency on automake and autoconf are almost always bad ideas. It makes the build more unpredictable, which is generally a bad thing. You should just run automake and/or autoconf on the unpacked source and ship it in the .diff.gz. An extra 2K won't hurt. I tried that once to see the difference. It went from ~4K to ~61K. Is that OK? In effect, the only thing changed in configure.in is the GTK macro to look for GTK 2 instead of 1.2. I have not had any weirdness buidling on my sarge box or in clean Sarge and Sid chroots. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpO6b7ISHPzI.pgp Description: PGP signature
Re: Linda warnings
* Roberto C. Sanchez ([EMAIL PROTECTED]) wrote: On Sun, May 29, 2005 at 06:40:26PM -0400, Eric Dorland wrote: I don't think a dependency on automake and autoconf are almost always bad ideas. It makes the build more unpredictable, which is generally a bad thing. You should just run automake and/or autoconf on the unpacked source and ship it in the .diff.gz. An extra 2K won't hurt. I tried that once to see the difference. It went from ~4K to ~61K. Is that OK? In effect, the only thing changed in configure.in is the GTK macro to look for GTK 2 instead of 1.2. I have not had any weirdness buidling on my sarge box or in clean Sarge and Sid chroots. That seems somewhat unusual. Which package was this? But really, why quibble over 57K? Is that really a problem we should be worrying about? I've seen it a few times over the years, and they're usually pretty wacky. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Linda warnings
On Sun, May 29, 2005 at 11:03:14PM -0400, Eric Dorland wrote: * Roberto C. Sanchez ([EMAIL PROTECTED]) wrote: On Sun, May 29, 2005 at 06:40:26PM -0400, Eric Dorland wrote: I don't think a dependency on automake and autoconf are almost always bad ideas. It makes the build more unpredictable, which is generally a bad thing. You should just run automake and/or autoconf on the unpacked source and ship it in the .diff.gz. An extra 2K won't hurt. I tried that once to see the difference. It went from ~4K to ~61K. Is that OK? In effect, the only thing changed in configure.in is the GTK macro to look for GTK 2 instead of 1.2. I have not had any weirdness buidling on my sarge box or in clean Sarge and Sid chroots. That seems somewhat unusual. Which package was this? But really, why quibble over 57K? Is that really a problem we should be worrying about? I've seen it a few times over the years, and they're usually pretty wacky. It is toshutils. Personally, I am comfortable with depending on autoconf and automake at build time. If it breaks in future builds, I'll come up with something else. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpSo5yVurPYe.pgp Description: PGP signature
