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
34 matches
Mail list logo
