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 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 example
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 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,
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
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 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
Russ Allbery [EMAIL PROTECTED] writes:
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
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
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),
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: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
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 sense.
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,
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 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
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,
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 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
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
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
34 matches
Mail list logo
