Bill Allombert <[EMAIL PROTECTED]> writes:
> On Fri, Nov 10, 2006 at 10:48:15AM -0800, Russ Allbery wrote:
>> As previously discussed, it's very difficult to comply with this
>> directive as written if one is following the autotools-dev
>> recommendations for how to regenerate the various autotool
Moving this discussion into the bug, since I'm not going to have a chance
to work on wording any time soon and I want to remember what we talked
about at that point.
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> In all of the following discussion, no one has ever said
> anything about *
Hi,
FYI, Alexander Wirt started rebuilding the archive testing for packages
which have not a proper working clean target.
Expect results in a few days. (Within 90min already 4 packages popped
up).
Greetings
Martin
--
[EMAIL PROTECTED] /root]# man real-life
No manual entry for real-life
--
To
On Sat, Nov 11, 2006 at 10:55:57PM -0600, Manoj Srivastava wrote:
> What you are saying, in essence, is that we have not been
> treating autoconf transitions with the care we devote to other
> transitions; and as a result people have started shipping
> intermediate files.
>
> Wh
On Sat, Nov 11, 2006 at 09:50:24PM -0800, Steve Langasek wrote:
>>> We frown on autogenerated debian/control's for similar
>>> reasons, right?
>> Yes, but we don't frown upon autogenerated .o files.
> Uh... we don't?
No, we even ship this huge "gcc" thing whose primary goal is to autogenerate
.o
On Sat, 11 Nov 2006 22:55:57 -0600, Manoj Srivastava <[EMAIL PROTECTED]> said:
>>> On Sat, 11 Nov 2006 13:52:06 +, Stephen Gran
>>> <[EMAIL PROTECTED]> said:
>>>
>>> > It would be nice if we could support all sorts of forms of
>>> > rebuilds, but in practice, what we tend to take seriously i
On Sat, Nov 11, 2006 at 10:55:57PM -0600, Manoj Srivastava wrote:
> > I'm not arguing for being opaque, or eliding real problems in favor
> > of a fast release. I am just mentioning in passing that redoing
> > your build system on the fly mid-build can be expected to have a few
> > hiccups. We fr
>> On Sat, 11 Nov 2006 13:52:06 +, Stephen Gran <[EMAIL PROTECTED]>
>> said:
>>
>> > It would be nice if we could support all sorts of forms of
>> > rebuilds, but in practice, what we tend to take seriously is the
>> > sort of FTBFS bugs that will affect the autobuilders. Since they
>> > bui
["Followup-To:" header set to gmane.linux.debian.devel.general.]
On 2006-11-11, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> In all of the following discussion, no one has ever said
> anything about *WHY* policy states that clean must undo what build
> does. Unless we are clear on the r
This one time, at band camp, Manoj Srivastava said:
> Hi,
>
>
> In all of the following discussion, no one has ever said
> anything about *WHY* policy states that clean must undo what build
> does. Unless we are clear on the rationale for dictum, trying to
> resolve the issue is like
On Sat, Nov 11, 2006 at 01:52:06PM +, Stephen Gran wrote:
> I can imagine an argument for removing all of the intermediate files
> (Makefile.in, configure, etc) in the clean target and rerunning the
> autotools stuff from the build target. This would provide a relatively
> small diff (provide
Hi,
In all of the following discussion, no one has ever said
anything about *WHY* policy states that clean must undo what build
does. Unless we are clear on the rationale for dictum, trying to
resolve the issue is like playing blind man's bluff.
There are several reasons for
On Sat, 11 Nov 2006 08:04:48 +0100, Bart Martens <[EMAIL PROTECTED]> said:
>On Fri, 10 Nov 2006 10:48:15 -0800, Russ Allbery <[EMAIL PROTECTED]> said:
>> Certainly, though, being unable to build a package twice is a bug
>> that should be reported against that package. (I actually don't
>> kno
On Fri, Nov 10, 2006 at 10:48:15AM -0800, Russ Allbery wrote:
> Stephen Gran <[EMAIL PROTECTED]> writes:
> As previously discussed, it's very difficult to comply with this directive
> as written if one is following the autotools-dev recommendations for how
> to regenerate the various autotools file
This one time, at band camp, Russ Allbery said:
> Stephen Gran <[EMAIL PROTECTED]> writes:
> > This one time, at band camp, Russ Allbery said:
>
> >> As previously discussed, it's very difficult to comply with this
> >> directive as written if one is following the autotools-dev
> >> recommendation
Hi Martin,
I agree with Russ that before putting too much weight on this directive
we should think about how to handle overwritten generated files.
According to current policy files like config.guess and config.sub must
be restored by "clean". Some of the packages I maintain violate that,
and I c
Stephen Gran <[EMAIL PROTECTED]> writes:
> This one time, at band camp, Russ Allbery said:
>> As previously discussed, it's very difficult to comply with this
>> directive as written if one is following the autotools-dev
>> recommendations for how to regenerate the various autotools files.
>> Befo
This one time, at band camp, Russ Allbery said:
> Stephen Gran <[EMAIL PROTECTED]> writes:
>
> > 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 run o
* Martin Zobel-Helas ([EMAIL PROTECTED]) [061110 22:41]:
> On Fri Nov 10, 2006 at 10:48:15 -0800, Russ Allbery wrote:
> >
> > Certainly, though, being unable to build a package twice is a bug that
> > should be reported against that package. (I actually don't know if any of
> > my packages have t
On Fri Nov 10, 2006 at 10:48:15 -0800, Russ Allbery wrote:
>
> Certainly, though, being unable to build a package twice is a bug that
> should be reported against that package. (I actually don't know if any of
> my packages have this problem; some of them have so many build
> dependencies that I
Stephen Gran <[EMAIL PROTECTED]> writes:
> 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 run of a binary target.
> We already have this rule, and it is a
This one time, at band camp, Kurt Roeckx said:
> On Fri, Nov 10, 2006 at 04:11:22PM +0100, Martin Zobel-Helas wrote:
> >
> > during the last months i had to review several packages. Quite a number
> > of packages were not buildable two times (eg. "unrepresentable changes
> > to source"). Most of t
On Fri, Nov 10, 2006 at 04:11:22PM +0100, Martin Zobel-Helas wrote:
> Package: debian-policy
> Severity: important
>
>
> Hi,
>
> during the last months i had to review several packages. Quite a number
> of packages were not buildable two times (eg. "unrepresentable changes
> to source"). Most of
On Fri, 10 Nov 2006 16:11:22 +0100, Martin Zobel-Helas <[EMAIL PROTECTED]>
said:
> Package: debian-policy Severity: important
> Hi,
> during the last months i had to review several packages. Quite a
> number of packages were not buildable two times
> (eg. "unrepresentable changes to source").
Package: debian-policy
Severity: important
Hi,
during the last months i had to review several packages. Quite a number
of packages were not buildable two times (eg. "unrepresentable changes
to source"). Most of these packages used svn-buildpackage or
cvs-buildpackage. This bug is quite annoying
25 matches
Mail list logo
