|
Home > Archive > Debian Developers > May 2005 > Linda warnings
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Roberto C. Sanchez 2005-05-29, 5:53 pm |
| On Sun, May 29, 2005 at 09:45:25PM +1000, Anibal Monsalve Salazar wrote:
> drwxr-xr-x root/root 0 2005-05-29 21:45:04 ./usr/bin/
> -rwxr-xr-x root/root 7784 2005-05-29 21:45:04 ./usr/bin/fan
> -rwxr-xr-x root/root 9108 2005-05-29 21:45:04 ./usr/bin/svpw
> -rwxr-xr-x root/root 8404 2005-05-29 21:45:04 ./usr/bin/tpasswd
> -rwxr-xr-x root/root 14540 2005-05-29 21:45:04 ./usr/bin/dispswitch
> -rwxr-xr-x root/root 5624 2005-05-29 21:45:04 ./usr/bin/tdocked
> -rwxr-xr-x root/root 12976 2005-05-29 21:45:04 ./usr/bin/thotswap
> -rwxr-xr-x root/root 5540 2005-05-29 21:45:04 ./usr/bin/tbacklight
> -rwxr-xr-x root/root 7880 2005-05-29 21:45:04 ./usr/bin/ownerstring
> -rwxr-xr-x root/root 26104 2005-05-29 21:45:04 ./usr/bin/alarm
> -rwxr-xr-x root/root 28696 2005-05-29 21:45:04 ./usr/bin/hotkey
> -rwxr-xr-x root/root 44568 2005-05-29 21:45:04 ./usr/bin/wmtuxtime
> -rwxr-xr-x root/root 62008 2005-05-29 21:45:04 ./usr/bin/tuxtime-conf
> drwxr-xr-x root/root 0 2005-05-29 21:45:03 ./usr/lib/
> drwxr-xr-x root/root 0 2005-05-29 21:45:03 ./usr/lib/menu/
> -rw-r--r-- root/root 1099 2005-05-29 21:44:36 ./usr/lib/menu/toshutils
> drwxr-xr-x root/root 0 2005-05-29 21:45:03 ./etc/
> drwxr-xr-x root/root 0 2005-05-29 21:45:03 ./etc/modutils/
> -rw-r--r-- root/root 32 2005-05-29 21:45:03 ./etc/modutils/toshutils
>
> lintian -i /home/pbuilder/result/toshutils/toshutils_2.0.1-11_i386.changes
>
> linda -i /home/pbuilder/result/toshutils/toshutils_2.0.1-11_i386.changes
> 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.
> 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.
> W: toshutils; The command dispswitch listed in a menu file does not exist.
> The command shown above is referenced in a menu file installed into
> /usr/lib/menu, however, the command does not exist in the package.
> W: toshutils; The command tuxtime-conf listed in a menu file does not exist.
> W: toshutils; The command wmtuxtime listed in a menu file does not exist.
> 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.
When building toshutils, which I am in the process of adopting, on
Anibal's pbuilder, I get the above linda warnings. I asked him and he
suggested that I re-ask these questions on debian-devel. I am
wondering poeple think of the following:
1) The menu warnings. The list of files in /usr/bin shows that
dispswitch, tuxtime-conf, and wmtuxtime are in fact in the package. As
far as xmessage, that is in the xbase-clients package, an indirect
dependency. Lintian also gave the same warning, but I setup an override
to suppress the warning. Is this OK? What about the other files that
it says are not there?
2) Should I do anything about the timestamp warnings on config.guess and
config.sub?
3) I already discussed the warning about depending on automake and
autoconf with Anibal and he seems to think it is justified. Are there
any disagreements?
-Roberto
--
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr
| |
| Hendrik Sattler 2005-05-29, 5:53 pm |
| Roberto C. Sanchez wrote:
> 2) Should I do anything about the timestamp warnings on config.guess and
> config.sub?
You can recreate them with
automake -a -c -f
You should make sure to use the right automake version.
> 3) I already discussed the warning about depending on automake and
> autoconf with Anibal and he seems to think it is justified. Are there
> any disagreements?
You can argue in both directions. Same arguments would probably go for
patchingor creating gettext message catalogs at build time instead of
prior to source packet creation (lots of other things you could argue
with).
Additionally, you need to run automake & autoconf after some patches. Doing
this prior to source package creation also makes the debian diff _much_
bigger and you have to remember to rerun it when reversing a patch.
Build-depending on a specific automake version (e.g. automake-1.7) should
be pretty safe. Additionally, the AC_PREREQ statement in configure.in gives
autoconf a bit more help on the required version.
After all: it's a warning (suggestion) of the linda author(?), not an error
with the debian policy.
HS
| |
| Peter Samuelson 2005-05-29, 5:54 pm |
|
[Roberto C. Sanchez][vbcol=seagreen]
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.
[vbcol=seagreen]
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.)
[vbcol=seagreen]
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.)
| |
| Ralf Treinen 2005-05-29, 5:54 pm |
| On Sun, May 29, 2005 at 01:31:31PM -0500, Peter Samuelson wrote:
>
> [Roberto C. Sanchez]
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roberto C. Sanchez 2005-05-29, 5:54 pm |
| On Sun, May 29, 2005 at 01:31:31PM -0500, Peter Samuelson wrote:
>
> [Roberto C. Sanchez]
>
> 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.
>
> 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.
>
> 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
| |
| Bill Allombert 2005-05-29, 5:54 pm |
| 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 (<ballombe@debian.org>, 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. <ballombe@debian.org>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Eric Dorland 2005-05-29, 5:54 pm |
| * Peter Samuelson (peter@p12n.org) wrote:
>
> [Roberto C. Sanchez]
>
> 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.
>
> 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.)
>
>
> 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 <eric.dorland@mail.mcgill.ca>
ICQ: #61138586, Jabber: hooty@jabber.com
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------
| |
| Eric Dorland 2005-05-29, 5:54 pm |
| * Eric Dorland (eric@debian.org) 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 <eric.dorland@mail.mcgill.ca>
ICQ: #61138586, Jabber: hooty@jabber.com
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------
| |
| Roberto C. Sanchez 2005-05-29, 8:48 pm |
| 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
| |
| Roberto C. Sanchez 2005-05-29, 8:48 pm |
| On Sun, May 29, 2005 at 06:49:22PM -0400, Eric Dorland wrote:
> * Eric Dorland (eric@debian.org) wrote:
>
> 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
| |
| Eric Dorland 2005-05-30, 2:48 am |
| * Roberto C. Sanchez (roberto@familiasanchez.net) wrote:
> On Sun, May 29, 2005 at 06:49:22PM -0400, Eric Dorland wrote:
>
> 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 <eric.dorland@mail.mcgill.ca>
ICQ: #61138586, Jabber: hooty@jabber.com
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------
| |
| Eric Dorland 2005-05-30, 2:48 am |
| * Roberto C. Sanchez (roberto@familiasanchez.net) wrote:
> On Sun, May 29, 2005 at 06:40:26PM -0400, Eric Dorland wrote:
> 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 <eric.dorland@mail.mcgill.ca>
ICQ: #61138586, Jabber: hooty@jabber.com
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------
| |
| Roberto C. Sanchez 2005-05-30, 2:48 am |
| On Sun, May 29, 2005 at 11:03:14PM -0400, Eric Dorland wrote:
> * Roberto C. Sanchez (roberto@familiasanchez.net) wrote:
>
> 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
| |
| Tollef Fog Heen 2005-05-30, 2:48 am |
| * 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Roberto C. Sanchez 2005-05-30, 2:48 am |
| 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
| |
| Eric Dorland 2005-05-30, 2:48 am |
| * Tollef Fog Heen (tfheen@err.no) 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 <eric.dorland@mail.mcgill.ca>
ICQ: #61138586, Jabber: hooty@jabber.com
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------
| |
| Robert Collins 2005-05-30, 2:48 am |
| On Mon, 2005-05-30 at 03:33 -0400, Eric Dorland wrote:
> * Tollef Fog Heen (tfheen@err.no) wrote:
>
>
> 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>.
| |
| Eric Dorland 2005-05-30, 5:52 pm |
| * Robert Collins (robertc@robertcollins.net) wrote:
> On Mon, 2005-05-30 at 03:33 -0400, Eric Dorland wrote:
>
> 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 <eric.dorland@mail.mcgill.ca>
ICQ: #61138586, Jabber: hooty@jabber.com
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------
| |
| Wouter Verhelst 2005-05-30, 5:52 pm |
| On Mon, May 30, 2005 at 10:30:56AM -0400, Eric Dorland wrote:
> * Robert Collins (robertc@robertcollins.net) wrote:
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Eric Dorland 2005-05-30, 5:52 pm |
| * Wouter Verhelst (wouter@debian.org) wrote:
> On Mon, May 30, 2005 at 10:30:56AM -0400, Eric Dorland wrote:
>
> 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/...tainer_002dmode).
Maintainer-mode is also a good solution.
--
Eric Dorland <eric.dorland@mail.mcgill.ca>
ICQ: #61138586, Jabber: hooty@jabber.com
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------
| |
| Philipp Kern 2005-05-30, 5:53 pm |
| -----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
iEYEARECAAYFAkKbcuIACgkQ7Ro5M7LPzdhBVwCe
PCCQ6BnkbAElemgSvROyEGdt
1JMAoIRxeJQG4wr8viOWVSIYZ0Wj+NOC
=L7iY
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Eric Dorland 2005-05-30, 5:53 pm |
| * Philipp Kern (phil@philkern.de) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Eric Dorland wrote:
>
> 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 <eric.dorland@mail.mcgill.ca>
ICQ: #61138586, Jabber: hooty@jabber.com
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------
| |
| Philipp Kern 2005-05-30, 5:53 pm |
| X-Original-Sender: news <news@sea.gmane.org>
X-Original-X-Complaints-To: usenet@sea.gmane.org
Xref: number1.nntp.dca.giganews.com linux.debian.devel:170881
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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Clint Adams 2005-05-30, 8:48 pm |
| > 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|