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 p
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 so
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 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 contai
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 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 exampl
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 doin
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 differe
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 m
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 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, sim
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.
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 comp
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 pret
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 configure.i
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 benef
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
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 ins
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, configu
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 Debi
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
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 s
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 cop
Bas Wijnen <[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 se
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 cu
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 technical
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
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".
T
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
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
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 wil
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 im
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
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
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 targe
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?
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 on
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 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), whi
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 w
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
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 h
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
>> di
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 b
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
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
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: outdated-autotoo
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 documentatio
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 sup
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 sta
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
52 matches
Mail list logo
