On Tue, Feb 19, 2008 at 11:22:04PM +0100, Kurt Roeckx wrote:
On Tue, Feb 19, 2008 at 10:50:23AM +0100, Bas Wijnen wrote:
As a sidestep, I think this target may actually be legally required for
GPL (at least 2 and 3) licenced code. They say
For an executable work, complete source
On Tue, Feb 19, 2008 at 11:00:55PM +, Mark Brown wrote:
It's not just the computing resources required that concern me, it's
also the effort involved in doing it and the disruption that could be
caused, especially if we were to do things like changing autotools
versions underneath the
On Mon, Feb 18, 2008 at 12:39:29PM -0800, Chris Waters wrote:
But honestly, I think our job is to deliver full source and binaries.
I _don't_ think we necessarily have to exercise every bit of the
source (e.g. the .am files) on every build. In fact, my primary
objections to the java example
On Mon, Feb 18, 2008 at 10:14:24PM +, Mark Brown wrote:
Then I still don't understand your statement above. What is the thing
that you prefer to check outside the normal build process?
That we can regenerate the autotools products.
I answered this in another reply. Sorry for not
On Tue, Feb 19, 2008 at 10:50:23AM +0100, Bas Wijnen wrote:
As a sidestep, I think this target may actually be legally required for
GPL (at least 2 and 3) licenced code. They say
For an executable work, complete source code means all the
source code for all modules it contains,
On Tue, Feb 19, 2008 at 10:59:10AM +0100, Bas Wijnen wrote:
If we build separate infrastructure to test it, it would likely also try
to do this for every upload. And preferrably on different (or even all)
architectures we support. So if we make this whole extra check work
right, it isn't
On Sun, Feb 17, 2008, Colin Watson wrote:
This isn't true if you just let the patch be applied by dpkg-source -x,
since the timestamp-handling bug I mentioned earlier was fixed. It might
be true if you use a less capable patching system. ;-)
Eh you and me know I was referring to dpatch,
On Sun, Feb 17, 2008 at 11:55:03PM +0100, Bas Wijnen wrote:
On Sun, Feb 17, 2008 at 09:29:59PM +, Mark Brown wrote:
On Sun, Feb 17, 2008 at 08:08:47PM +0100, Bas Wijnen wrote:
OTOH if the standard Debian build process jumps through unusual hoops
like forcing regeneration of all the
On Mon, Feb 18, 2008 at 12:47:41PM +, Mark Brown wrote:
On Sun, Feb 17, 2008 at 11:55:03PM +0100, Bas Wijnen wrote:
On Sun, Feb 17, 2008 at 09:29:59PM +, Mark Brown wrote:
If you're willing to do things by forcing a particular version in the
general case then this sounds more like
On Sun, Feb 17, 2008 at 08:08:47PM +0100, Bas Wijnen wrote:
Let's compare it with a Java program. Would you consider it acceptable
for the packager to build it, uuencode it, put it in the diff.gz and
from debian/rules just uudecode it, instead of regenerating it?
Well, I see one big
On Mon, Feb 18, 2008 at 05:03:24PM +0100, Bas Wijnen wrote:
On Mon, Feb 18, 2008 at 12:47:41PM +, Mark Brown wrote:
On Sun, Feb 17, 2008 at 11:55:03PM +0100, Bas Wijnen wrote:
No, I don't want to force a version, I want the package to force it.
By forcing a version I mean doing so in
On Mon, Feb 11, 2008 at 10:53:48AM +0100, Bas Wijnen wrote:
This is not true if you simply build the whole package from source.
That is, run autotools during build, remove all generated files,
including Makefile.in, configure, etc, in the clean target.
For some reason many people seem to
Colin Watson [EMAIL PROTECTED] writes:
Rather than incurring the pain of gratuitous full regeneration every
time, we just regenerate it when the user has changed something. Yes,
the user now gets to resolve any problems that might have been
pre-existing, but realistically either the Debian
On Sun, Feb 17, 2008 at 03:07:59PM +, Colin Watson wrote:
On Mon, Feb 11, 2008 at 10:53:48AM +0100, Bas Wijnen wrote:
This is not true if you simply build the whole package from source.
That is, run autotools during build, remove all generated files,
including Makefile.in, configure,
Bas Wijnen [EMAIL PROTECTED] writes:
Autoconf is pretty stable,
This has not been the experience of many of us. I haven't had a lot of
trouble fixing things for newer releases of Autoconf, but I definitely
have seen issues. And the Autoconf 2.13 to 2.50 transition and all the
subsequent
On Sun, Feb 17, 2008 at 11:15:20AM -0800, Russ Allbery wrote:
Bas Wijnen [EMAIL PROTECTED] writes:
Autoconf is pretty stable,
This has not been the experience of many of us. I haven't had a lot of
trouble fixing things for newer releases of Autoconf, but I definitely
have seen issues.
On Sun, Feb 17, 2008, Russ Allbery wrote:
I think we should recommend (but not require) that AM_MAINTAINER_MODE
not be used, and perhaps work to specify an optional debian/rules target
that regenerates the build system in an appropriate way. That seems to
provide the necessary benefits for
On Sun, Feb 17, 2008 at 08:24:43PM +0100, Loïc Minier wrote:
Yes, I second Russ here and would like to add that it's very easy to
trigger the timestamp skews if you simply create a patch for
configure + configure.in/.ac as the files will be sorted as configure
first and then
On Sun, Feb 17, 2008 at 08:08:47PM +0100, Bas Wijnen wrote:
The fact that there exist packages which work properly without
recompiling from source doesn't mean it's a good default. IMO the
default should be to always compile from source. Yes, that means hassle
for the packager; it's pretty
On Sun, Feb 17, 2008 at 09:29:59PM +, Mark Brown wrote:
On Sun, Feb 17, 2008 at 08:08:47PM +0100, Bas Wijnen wrote:
The fact that there exist packages which work properly without
recompiling from source doesn't mean it's a good default. IMO the
default should be to always compile
On Sun, Feb 17, 2008 at 11:55:03PM +0100, Bas Wijnen wrote:
Not at all. If it's optional, it's likely that many packages will not
have it. Also, if the build system doesn't use it by default, it is
likely that many of those targets are never tested and don't actually
work.
We
On Mon, Feb 11, 2008 at 10:53:48AM +0100, Bas Wijnen wrote:
I suggest to mandate remove all generated files in the clean target
(formulated in a way which includes generated by upstream, not only
generated by the build target), which implies rebuild everything in
the build target.
Tell me how
Bas Wijnen [EMAIL PROTECTED] writes:
A workaround could be to not regenerate the files. This is how it is
usually done now. IMO that is incorrect, because the compiler for every
generated file must be in Debian. The current practise of not rerunning
autotools makes this rule technically
On Thu, Feb 14, 2008 at 04:43:52PM -0500, Clint Adams wrote:
On Mon, Feb 11, 2008 at 10:53:48AM +0100, Bas Wijnen wrote:
I suggest to mandate remove all generated files in the clean target
(formulated in a way which includes generated by upstream, not only
generated by the build target),
On Thu, Feb 14, 2008 at 04:02:41PM -0800, Russ Allbery wrote:
Bas Wijnen [EMAIL PROTECTED] writes:
A workaround could be to not regenerate the files. This is how it is
usually done now. IMO that is incorrect, because the compiler for every
generated file must be in Debian. The current
On Thu, Feb 14, 2008 at 04:02:41PM -0800, Russ Allbery wrote:
Note that libtool is an unusual case here and isn't the same as Autoconf
or Automake. The files included in the package (libtool.m4 and ltmain.sh)
are not generated files in the same sense. Running libtoolize basically
just copies
Clint Adams [EMAIL PROTECTED] writes:
On Thu, Feb 14, 2008 at 04:02:41PM -0800, Russ Allbery wrote:
Note that libtool is an unusual case here and isn't the same as
Autoconf or Automake. The files included in the package (libtool.m4
and ltmain.sh) are not generated files in the same sense.
On Mon, Feb 11, 2008 at 03:19:36PM -0800, Russ Allbery wrote:
Bas Wijnen [EMAIL PROTECTED] writes:
On Mon, Feb 11, 2008 at 09:21:29AM -0800, Russ Allbery wrote:
Always re-running autoconf and automake would increase the number of
FTBFS's that we'd need to fix.
Not really.
No,
Bas Wijnen [EMAIL PROTECTED] writes:
I suggest to mandate remove all generated files in the clean target
(formulated in a way which includes generated by upstream, not only
generated by the build target), which implies rebuild everything in
the build target.
[...]
I'd like to hear why this
On Mon, Feb 11, 2008 at 09:21:29AM -0800, Russ Allbery wrote:
Bas Wijnen [EMAIL PROTECTED] writes:
I suggest to mandate remove all generated files in the clean target
(formulated in a way which includes generated by upstream, not only
generated by the build target), which implies rebuild
Bas Wijnen [EMAIL PROTECTED] writes:
On Mon, Feb 11, 2008 at 09:21:29AM -0800, Russ Allbery wrote:
Always re-running autoconf and automake would increase the number of
FTBFS's that we'd need to fix.
Not really.
No, really, I promise it will. :) Each time we upgrade autoconf, it will
break
Am Montag, den 11.02.2008, 14:17 +0100 schrieb Daniel Leidert:
Am Montag, den 11.02.2008, 10:54 +0100 schrieb David Paleino:
Il giorno Mon, 11 Feb 2008 10:53:48 +0100
Bas Wijnen [EMAIL PROTECTED] ha scritto:
I suggest to mandate remove all generated files in the clean target
Il giorno Mon, 11 Feb 2008 14:17:54 +0100
Daniel Leidert [EMAIL PROTECTED] ha scritto:
We simply copy config.sub and config.guess into the build directory for
some years now and I never observed any problem with this.
I'm really wondering why you want to make the situation complicated?
And
On Mon, 11 Feb 2008, Kapil Hari Paranjape wrote:
Note that if the upstream's auto-generated files are deleted during
the clean target, then the source *must* be re-packaged to avoid
needless clutter in the .diff.gz which is of a negative nature.
Not so. Deletions are ignored. Ever tried it?
On Mon, Feb 11, 2008 at 03:19:36PM -0800, Russ Allbery wrote:
Bas Wijnen [EMAIL PROTECTED] writes:
On Mon, Feb 11, 2008 at 09:21:29AM -0800, Russ Allbery wrote:
Always re-running autoconf and automake would increase the number of
FTBFS's that we'd need to fix.
Not really.
No,
Am Montag, den 11.02.2008, 10:54 +0100 schrieb David Paleino:
Il giorno Mon, 11 Feb 2008 10:53:48 +0100
Bas Wijnen [EMAIL PROTECTED] ha scritto:
I suggest to mandate remove all generated files in the clean target
(formulated in a way which includes generated by upstream, not only
On Mon, Feb 11, 2008 at 05:40:58PM +0530, Kapil Hari Paranjape wrote:
On Mon, 11 Feb 2008, Bas Wijnen wrote:
I suggest to mandate remove all generated files in the clean target
(formulated in a way which includes generated by upstream, not only
generated by the build target), which implies
On Mon, 11 Feb 2008, Bas Wijnen wrote:
I suggest to mandate remove all generated files in the clean target
(formulated in a way which includes generated by upstream, not only
generated by the build target), which implies rebuild everything in
the build target.
With the current wording it is
On Mon, Feb 11, 2008 at 02:17:54PM +0100, Daniel Leidert wrote:
Am Montag, den 11.02.2008, 10:54 +0100 schrieb David Paleino:
Il giorno Mon, 11 Feb 2008 10:53:48 +0100
Bas Wijnen [EMAIL PROTECTED] ha scritto:
I suggest to mandate remove all generated files in the clean target
Hello,
On Mon, 11 Feb 2008, Bas Wijnen wrote:
Secondly, when the clean target removes all generated files, they are
ignored when generating the diff.gz, so it doesn't actually clutter it.
It does produce some warnings during make clean, but those are not a
problem IMO.
Oops. I'd forgotten
On Sun, Feb 10, 2008 at 03:48:20PM -0800, Russ Allbery wrote:
Raphael Geissert [EMAIL PROTECTED] writes:
Quoting the Debian Policy, section 4.9 Main building script:
debian/rules[1]
clean
This must undo any effects that the build and binary targets may
have had, except that it
Il giorno Mon, 11 Feb 2008 10:53:48 +0100
Bas Wijnen [EMAIL PROTECTED] ha scritto:
I suggest to mandate remove all generated files in the clean target
(formulated in a way which includes generated by upstream, not only
generated by the build target), which implies rebuild everything in
the
Hi *,
I'm packaging gnome-translate (ITP #292909), and everything builds fine. A
lintian check on the .changes file throws:
E: gnome-translate source: outdated-autotools-helper-file config.guess
2003-07-02
N:
N: The referenced file has a time stamp older than year 2004 and the
N: package does
On Sun, 10 Feb 2008 13:40:07 -0600
Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] wrote:
Build-Depend on autotools-dev, move the ofending files aside and put
the new copy in thier place before running ./configure, copy the
originals back at the end of clean.
Autotools-dev's documentation
On Sun, Feb 10, 2008 at 08:27:52PM +0100, David Paleino wrote:
Hi *,
I'm packaging gnome-translate (ITP #292909), and everything builds fine. A
lintian check on the .changes file throws:
E: gnome-translate source: outdated-autotools-helper-file config.guess
2003-07-02
What am I supposed
On Sun, 10 Feb 2008, David Paleino wrote:
I'm packaging gnome-translate (ITP #292909), and everything builds fine. A
lintian check on the .changes file throws:
E: gnome-translate source: outdated-autotools-helper-file config.guess
2003-07-02
N:
N: The referenced file has a time stamp
On Sun, 10 Feb 2008 23:10:20 +0100
Adam Borowski [EMAIL PROTECTED] wrote:
On Sun, Feb 10, 2008 at 01:40:07PM -0600, Luis Rodrigo Gallardo Cruz wrote:
Build-Depend on autotools-dev, move the ofending files aside and put
the new copy in thier place before running ./configure, copy the
Am Sonntag, den 10.02.2008, 17:30 -0200 schrieb Henrique de Moraes Holschuh:
On Sun, 10 Feb 2008, David Paleino wrote:
I'm packaging gnome-translate (ITP #292909), and everything builds fine. A
lintian check on the .changes file throws:
E: gnome-translate source:
On Sun, Feb 10, 2008 at 01:40:07PM -0600, Luis Rodrigo Gallardo Cruz wrote:
On Sun, Feb 10, 2008 at 08:27:52PM +0100, David Paleino wrote:
E: gnome-translate source: outdated-autotools-helper-file config.guess
2003-07-02
What am I supposed to do? I believe that Build-Depending on
Adam Borowski wrote:
On Sun, Feb 10, 2008 at 01:40:07PM -0600, Luis Rodrigo Gallardo Cruz
wrote:
On Sun, Feb 10, 2008 at 08:27:52PM +0100, David Paleino wrote:
E: gnome-translate source: outdated-autotools-helper-file config.guess
2003-07-02
What am I supposed to do? I believe that
Raphael Geissert [EMAIL PROTECTED] writes:
Quoting the Debian Policy, section 4.9 Main building script: debian/rules[1]
clean
This must undo any effects that the build and binary targets may have had,
except that it should leave alone any output files created in the parent
directory by a
51 matches
Mail list logo
