emacs21: FTBFS: timestamp skew issues.

[Debian Bug Importer]

Automatically imported from Debian bug report #297796 http://bugs.debian.org/297796

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #297796 http://bugs.debian.org/297796

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 3 Mar 2005 00:15:06 +0100
From: Kurt Roeckx <email address hidden>
To: <email address hidden>
Subject: Re: emacs21: FTBFS: timestamp skew issues.

Package: emacs21
Version: 21.3+1-9
Severity: serious

Hi,

Your package is failing to build on a few arches because of
timestamp skew issues.

An extract from the buildd logs:
applying patch remote-files-permissions to ./ ... ok.
applying patch fix-x-vs-no-x-diffs to ./ ... ok.
dpatch cat-all >>patch-stampT
mv -f patch-stampT patch-stamp
make[1]: Leaving directory `/build/buildd/emacs21-21.3+1'
mkdir debian/autodiff-old
cp -a `ls | grep -vE 'debian|{arch}'` debian/autodiff-old
cp -a debian/autodiff-old debian/autodiff-new
# rm aclocal.m4 so it doesn't confuse newer autoconfs, but touch it
# so ./Makefile won't be upset if it's not recreated (b/c not needed).
cd debian/autodiff-new && rm -f aclocal.m4 && touch aclocal.m4
cd debian/autodiff-new && aclocal
/bin/bash: aclocal: command not found
make: *** [debian/autofiles.diff] Error 127

The problem is this line in your rules file:
debian/autofiles.diff: debian/patches/*.dpatch
        ${update_debian_autofiles_diff}

This causes timestamp skew issues because the
debian/autofiles.diff file is in the
emacs21_21.3+1-9.diff.gz before the debian/patches/*
so it thinks it needs to rebuild those.

In the emacs21_21.3+1-8.diff.gz file the order of the
files was different so it did not show that problem.

Kurt

[LaMont Jones (lamont)]

Doesn't affect 21.3+1-8ubuntu5 (because autofiles.diff is after
debian/patches)... But should be fixed in the next upload of emacs21, whenever
that is.

[LaMont Jones (lamont)]

And wasn't fixed in 21.3+1-8ubuntu6, which now suffers from this bug. sigh.

[Matt Zimmerman (mdz)]

Severity critical since it FTBFS now

[LaMont Jones (lamont)]

Fixed in 21.3+1-8ubuntu7

[Jérôme Marant (jmarant)]

Quoting Kurt Roeckx <email address hidden>:

> The problem is this line in your rules file:
> debian/autofiles.diff: debian/patches/*.dpatch
> ${update_debian_autofiles_diff}
>
> This causes timestamp skew issues because the
> debian/autofiles.diff file is in the
> emacs21_21.3+1-9.diff.gz before the debian/patches/*
> so it thinks it needs to rebuild those.
>
> In the emacs21_21.3+1-8.diff.gz file the order of the
> files was different so it did not show that problem.

Rob, do you have any idea about how to fix this?

--
Jérôme Marant

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 8 Mar 2005 09:07:56 +0100
From: =?iso-8859-1?b?Suly9G1l?= Marant <email address hidden>
To: Kurt Roeckx <email address hidden>, <email address hidden>
Subject: Re: Bug#297796: emacs21: FTBFS: timestamp skew issues.

Quoting Kurt Roeckx <email address hidden>:

> The problem is this line in your rules file:
> debian/autofiles.diff: debian/patches/*.dpatch
> ${update_debian_autofiles_diff}
>
> This causes timestamp skew issues because the
> debian/autofiles.diff file is in the
> emacs21_21.3+1-9.diff.gz before the debian/patches/*
> so it thinks it needs to rebuild those.
>
> In the emacs21_21.3+1-8.diff.gz file the order of the
> files was different so it did not show that problem.

Rob, do you have any idea about how to fix this?

--
J=E9r=F4me Marant

[Rob Browning (rlb)]

Jérôme Marant <email address hidden> writes:

> Quoting Kurt Roeckx <email address hidden>:
>
>
>> The problem is this line in your rules file:
>> debian/autofiles.diff: debian/patches/*.dpatch
>> ${update_debian_autofiles_diff}
>>
>> This causes timestamp skew issues because the
>> debian/autofiles.diff file is in the
>> emacs21_21.3+1-9.diff.gz before the debian/patches/*
>> so it thinks it needs to rebuild those.
>>
>> In the emacs21_21.3+1-8.diff.gz file the order of the
>> files was different so it did not show that problem.
>
> Rob, do you have any idea about how to fix this?

The only thing I've thought of so far is to change debian/rules to not
rely on timestamps for this file. Instead keep a file of the md5sums
of the *.dpatch files and use that and cmp to determine when to
re-generate. i.e. (in psudeo-make code):

  define update_autofiles_diff_if_needed
    md5sum debian/*.dpatch > debian/tmp-dpatch.md5
    if ! cmp debian/dpatch.md5 debian/tmp-dpatch.md5; \
    then \
      $(update_debian_autofiles_diff); \
      md5sum debian/*.dpatch > debian/dpatch.md5; \
    fi
  endef

Then I'd just have to arrange for this action to be taken at all the
appropriate times. A bit ugly perhaps, but it looks like it might
work.

--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 08 Mar 2005 09:04:46 -0600
From: Rob Browning <email address hidden>
To: <email address hidden>
Cc: <email address hidden>, Kurt Roeckx <email address hidden>
Subject: Re: Bug#297796: emacs21: FTBFS: timestamp skew issues.

J=E9r=F4me Marant <email address hidden> writes:

> Quoting Kurt Roeckx <email address hidden>:
>
>
>> The problem is this line in your rules file:
>> debian/autofiles.diff: debian/patches/*.dpatch
>> ${update_debian_autofiles_diff}
>>
>> This causes timestamp skew issues because the
>> debian/autofiles.diff file is in the
>> emacs21_21.3+1-9.diff.gz before the debian/patches/*
>> so it thinks it needs to rebuild those.
>>
>> In the emacs21_21.3+1-8.diff.gz file the order of the
>> files was different so it did not show that problem.
>
> Rob, do you have any idea about how to fix this?

The only thing I've thought of so far is to change debian/rules to not
rely on timestamps for this file. Instead keep a file of the md5sums
of the *.dpatch files and use that and cmp to determine when to
re-generate. i.e. (in psudeo-make code):

  define update_autofiles_diff_if_needed
    md5sum debian/*.dpatch > debian/tmp-dpatch.md5
    if ! cmp debian/dpatch.md5 debian/tmp-dpatch.md5; \
    then \
      $(update_debian_autofiles_diff); \
      md5sum debian/*.dpatch > debian/dpatch.md5; \
    fi
  endef

Then I'd just have to arrange for this action to be taken at all the
appropriate times. A bit ugly perhaps, but it looks like it might
work.

--=20
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 =3D 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 7=
3A4

[=?iso-8859-1?b?Suly9G1l?= Marant (jerome-marant)]

Quoting Rob Browning <email address hidden>:

> > Rob, do you have any idea about how to fix this?
>
> The only thing I've thought of so far is to change debian/rules to not
> rely on timestamps for this file. Instead keep a file of the md5sums
> of the *.dpatch files and use that and cmp to determine when to
> re-generate. i.e. (in psudeo-make code):
>
> define update_autofiles_diff_if_needed
> md5sum debian/*.dpatch > debian/tmp-dpatch.md5
> if ! cmp debian/dpatch.md5 debian/tmp-dpatch.md5; \
> then \
> $(update_debian_autofiles_diff); \
> md5sum debian/*.dpatch > debian/dpatch.md5; \
> fi
> endef
>
> Then I'd just have to arrange for this action to be taken at all the
> appropriate times. A bit ugly perhaps, but it looks like it might
> work.

To my mind, we should avoid to do this automatically from the makefile
and generate a dpatch manually every we have to regenerate the
configure script.

Currently, the only file which is modified when changing configure.in
is configure, so this should be straightforward.

Cheers,

--
Jérôme Marant

[Rob Browning (rlb)]

Jérôme Marant <email address hidden> writes:

> To my mind, we should avoid to do this automatically from the makefile
> and generate a dpatch manually every we have to regenerate the
> configure script.

We certainly could generate the patch manually, and that would be
simpler, but it would also leave a lot of room for mistakes,
especially when someone else wants to hack on the package. They won't
know that they (may) need to regenerate the autofiles.diff after they
add a new patch or change an existing one.

Whatever we do, we'll still need to make sure the autofiles patch is
the final patch, since any of the other patches might make changes
that affect the autotools behavior.

> Currently, the only file which is modified when changing configure.in
> is configure, so this should be straightforward.

True, though there's no guarantee of that. Some newer version of
autoconf or aclocal could create extra files or pay attention to
source tree elements that older versions didn't. That's the reason
for the current approach:

  - apply all the other patches to a temp tree
  - run the appropriate autofoo on the temp tree
  - diff the temp tree and the original tree

More generally, even though the current autofiles.diff patch for
emacs21 only contains changes to configure, I was hoping to create a
solution that was as automatic as possible, one that could work on any
package using the autotools. A key presumption was that there's no
way to predict what changes a given version of the autotools might
make to the source tree (especially in cases where additional
autotools like automake and libtool are involved).

--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 8 Mar 2005 17:29:04 +0100
From: =?iso-8859-1?b?Suly9G1l?= Marant <email address hidden>
To: Rob Browning <email address hidden>
Cc: <email address hidden>, Kurt Roeckx <email address hidden>
Subject: Re: Bug#297796: emacs21: FTBFS: timestamp skew issues.

Quoting Rob Browning <email address hidden>:

> > Rob, do you have any idea about how to fix this?
>
> The only thing I've thought of so far is to change debian/rules to not
> rely on timestamps for this file. Instead keep a file of the md5sums
> of the *.dpatch files and use that and cmp to determine when to
> re-generate. i.e. (in psudeo-make code):
>
> define update_autofiles_diff_if_needed
> md5sum debian/*.dpatch > debian/tmp-dpatch.md5
> if ! cmp debian/dpatch.md5 debian/tmp-dpatch.md5; \
> then \
> $(update_debian_autofiles_diff); \
> md5sum debian/*.dpatch > debian/dpatch.md5; \
> fi
> endef
>
> Then I'd just have to arrange for this action to be taken at all the
> appropriate times. A bit ugly perhaps, but it looks like it might
> work.

To my mind, we should avoid to do this automatically from the makefile
and generate a dpatch manually every we have to regenerate the
configure script.

Currently, the only file which is modified when changing configure.in
is configure, so this should be straightforward.

Cheers,

--
J=E9r=F4me Marant

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 08 Mar 2005 10:51:22 -0600
From: Rob Browning <email address hidden>
To: =?iso-8859-1?q?J=E9r=F4me_Marant?= <email address hidden>
Cc: <email address hidden>, Kurt Roeckx <email address hidden>
Subject: Re: Bug#297796: emacs21: FTBFS: timestamp skew issues.

J=E9r=F4me Marant <email address hidden> writes:

> To my mind, we should avoid to do this automatically from the makefile
> and generate a dpatch manually every we have to regenerate the
> configure script.

We certainly could generate the patch manually, and that would be
simpler, but it would also leave a lot of room for mistakes,
especially when someone else wants to hack on the package. They won't
know that they (may) need to regenerate the autofiles.diff after they
add a new patch or change an existing one.

Whatever we do, we'll still need to make sure the autofiles patch is
the final patch, since any of the other patches might make changes
that affect the autotools behavior.

> Currently, the only file which is modified when changing configure.in
> is configure, so this should be straightforward.

True, though there's no guarantee of that. Some newer version of
autoconf or aclocal could create extra files or pay attention to
source tree elements that older versions didn't. That's the reason
for the current approach:

  - apply all the other patches to a temp tree
  - run the appropriate autofoo on the temp tree
  - diff the temp tree and the original tree

More generally, even though the current autofiles.diff patch for
emacs21 only contains changes to configure, I was hoping to create a
solution that was as automatic as possible, one that could work on any
package using the autotools. A key presumption was that there's no
way to predict what changes a given version of the autotools might
make to the source tree (especially in cases where additional
autotools like automake and libtool are involved).

--=20
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 =3D 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 7=
3A4

[=?iso-8859-1?b?Suly9G1l?= Marant (jerome-marant)]

Rob Browning <email address hidden> writes:

> Jérôme Marant <email address hidden> writes:
>
>> To my mind, we should avoid to do this automatically from the makefile
>> and generate a dpatch manually every we have to regenerate the
>> configure script.
>
> We certainly could generate the patch manually, and that would be
> simpler, but it would also leave a lot of room for mistakes,
> especially when someone else wants to hack on the package. They won't
> know that they (may) need to regenerate the autofiles.diff after they
> add a new patch or change an existing one.

I don't agree. It only has to be documented. Let's be frank: I
personaly don't like the idea of the voodoo magic which acts in the
shadow and breaks unexpectedly some random day.

> Whatever we do, we'll still need to make sure the autofiles patch is
> the final patch, since any of the other patches might make changes
> that affect the autotools behavior.
>
>> Currently, the only file which is modified when changing configure.in
>> is configure, so this should be straightforward.
>
> True, though there's no guarantee of that. Some newer version of
> autoconf or aclocal could create extra files or pay attention to
> source tree elements that older versions didn't. That's the reason
> for the current approach:
>
> - apply all the other patches to a temp tree
> - run the appropriate autofoo on the temp tree
> - diff the temp tree and the original tree

I don't agree. If new versions of autoconf and aclocal create new files,
those files are automatically added to the dpatch by dpatch-edit-patch
so there isn't any chance to see bad surprises.

IMO, creating a whole copy of the tree and diffing at build-time is
not worth the effort. You have the final word, anyway :P

--
Jérôme Marant

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 08 Mar 2005 22:38:09 +0100
From: =?iso-8859-15?q?J=E9r=F4me_Marant?= <email address hidden>
To: Rob Browning <email address hidden>
Cc: <email address hidden>, Kurt Roeckx <email address hidden>
Subject: Re: Bug#297796: emacs21: FTBFS: timestamp skew issues.

Rob Browning <email address hidden> writes:

> J=E9r=F4me Marant <email address hidden> writes:
>
>> To my mind, we should avoid to do this automatically from the makefile
>> and generate a dpatch manually every we have to regenerate the
>> configure script.
>
> We certainly could generate the patch manually, and that would be
> simpler, but it would also leave a lot of room for mistakes,
> especially when someone else wants to hack on the package. They won't
> know that they (may) need to regenerate the autofiles.diff after they
> add a new patch or change an existing one.

I don't agree. It only has to be documented. Let's be frank: I
personaly don't like the idea of the voodoo magic which acts in the
shadow and breaks unexpectedly some random day.

> Whatever we do, we'll still need to make sure the autofiles patch is
> the final patch, since any of the other patches might make changes
> that affect the autotools behavior.
>
>> Currently, the only file which is modified when changing configure.in
>> is configure, so this should be straightforward.
>
> True, though there's no guarantee of that. Some newer version of
> autoconf or aclocal could create extra files or pay attention to
> source tree elements that older versions didn't. That's the reason
> for the current approach:
>
> - apply all the other patches to a temp tree
> - run the appropriate autofoo on the temp tree
> - diff the temp tree and the original tree

I don't agree. If new versions of autoconf and aclocal create new files,
those files are automatically added to the dpatch by dpatch-edit-patch
so there isn't any chance to see bad surprises.

IMO, creating a whole copy of the tree and diffing at build-time is
not worth the effort. You have the final word, anyway :P

--=20
J=E9r=F4me Marant

[Rob Browning (rlb)]

Jérôme Marant <email address hidden> writes:

> I don't agree. It only has to be documented. Let's be frank: I
> personaly don't like the idea of the voodoo magic which acts in the
> shadow and breaks unexpectedly some random day.

By "voodoo magic" do you mean the old approach, the possible md5
approach, or both?

If you mean the old approach, then I obviously don't see it to be as
cut and dry as you do. To be fair, the only reason the current code
broke is because the relative timestamps for files in the debian diff
are unpredictable, and I didn't think about that. Of course, that
means that *any* files mentioned in the debian patch are potentially
trouble as far as make is concerned. Without this problem, it would
have been quite correct to have autofiles.diff depend on the files
that may influence its contents (i.e. the *.dpatch files).

Of course if you just mean that the .md5 approach would be "voodoo
magic", then I'll agree that it's not completely straightforward.
Though to the extent I've thought it through so far, I haven't come up
with any problems.

In any case, even if we go with the "only update when requested"
dpatch-edit-patch approach that I think you're advocating, I'd still
want a target for it so we can just invoke that when needed,
i.e. something (only very roughly) like this:

  update-autofiles-diff:
          # rm aclocal.m4 so it doesn't confuse newer autoconfs, but touch it
          # so ./Makefile won't be upset if it's not recreated (b/c not needed).
          (dpatch-edit-patch ... autofiles.dpatch
           && cd DPATCHDIR \
           && rm -f aclocal.m4 \
           && touch aclocal.m4 \
           && aclocal \
           && autoconf
           && exit)

(...which is really not that much different than what we're already
doing, but I'll agree that handling everything with dpatch would be a
bit cleaner, and if it works right, then I'm fine with that.)

So it seems like the *only* thing we're in potential disagreement
about is whether we should automatically invoke this target *iff*
there's a solid way to automatically determine when doing so would be
appropriate.

> IMO, creating a whole copy of the tree and diffing at build-time is
> not worth the effort. You have the final word, anyway :P

It's not only not worth the effort, but it should never have happened
under normal circumstances. As I mentioned, the only reason it did in
this case was because I didn't consider the problem presented by the
timestamps of files in the debian diff and so came up with a broken
solution.

The way things were intended to work, the autofiles.diff should only
have been re-built if you changed a relevant file (i.e. *.dpatch), or
if you manually requested a rebuild during "prepare-release".

--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 08 Mar 2005 19:15:10 -0600
From: Rob Browning <email address hidden>
To: =?iso-8859-1?q?J=E9r=F4me_Marant?= <email address hidden>
Cc: <email address hidden>, Kurt Roeckx <email address hidden>
Subject: Re: Bug#297796: emacs21: FTBFS: timestamp skew issues.

J=E9r=F4me Marant <email address hidden> writes:

> I don't agree. It only has to be documented. Let's be frank: I
> personaly don't like the idea of the voodoo magic which acts in the
> shadow and breaks unexpectedly some random day.

By "voodoo magic" do you mean the old approach, the possible md5
approach, or both?

If you mean the old approach, then I obviously don't see it to be as
cut and dry as you do. To be fair, the only reason the current code
broke is because the relative timestamps for files in the debian diff
are unpredictable, and I didn't think about that. Of course, that
means that *any* files mentioned in the debian patch are potentially
trouble as far as make is concerned. Without this problem, it would
have been quite correct to have autofiles.diff depend on the files
that may influence its contents (i.e. the *.dpatch files).

Of course if you just mean that the .md5 approach would be "voodoo
magic", then I'll agree that it's not completely straightforward.
Though to the extent I've thought it through so far, I haven't come up
with any problems.

In any case, even if we go with the "only update when requested"
dpatch-edit-patch approach that I think you're advocating, I'd still
want a target for it so we can just invoke that when needed,
i.e. something (only very roughly) like this:

  update-autofiles-diff:
          # rm aclocal.m4 so it doesn't confuse newer autoconfs, but touch =
it
          # so ./Makefile won't be upset if it's not recreated (b/c not nee=
ded).
          (dpatch-edit-patch ... autofiles.dpatch
           && cd DPATCHDIR \
           && rm -f aclocal.m4 \
           && touch aclocal.m4 \
           && aclocal \
           && autoconf
           && exit)

(...which is really not that much different than what we're already
doing, but I'll agree that handling everything with dpatch would be a
bit cleaner, and if it works right, then I'm fine with that.)

So it seems like the *only* thing we're in potential disagreement
about is whether we should automatically invoke this target *iff*
there's a solid way to automatically determine when doing so would be
appropriate.

> IMO, creating a whole copy of the tree and diffing at build-time is
> not worth the effort. You have the final word, anyway :P

It's not only not worth the effort, but it should never have happened
under normal circumstances. As I mentioned, the only reason it did in
this case was because I didn't consider the problem presented by the
timestamps of files in the debian diff and so came up with a broken
solution.

The way things were intended to work, the autofiles.diff should only
have been re-built if you changed a relevant file (i.e. *.dpatch), or
if you manually requested a rebuild during "prepare-release".

--=20
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 =3D 14...

[Rob Browning (rlb)]

Rob Browning <email address hidden> writes:

> So it seems like the *only* thing we're in potential disagreement
> about is whether we should automatically invoke this target *iff*
> there's a solid way to automatically determine when doing so would be
> appropriate.

Hmm. As a less automagic alternative, perhaps I could just arrange it
so that we just detect when the debian/autofiles.dpatch is out of date
and then print a suitable error message, rather than trying to update
it, i.e.

  $ fakeroot debian/rules binary
  ...
  ERROR: debian/patches/autofiles.dpatch out of date with respect to
  other patches. Please update it via "debian/rules update-autofiles-dpatch"
  and try again.
  $

The test would be handled via md5sum as previously described.

--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 08 Mar 2005 23:07:08 -0600
From: Rob Browning <email address hidden>
To: <email address hidden>
Cc: =?iso-8859-1?q?J=E9r=F4me_Marant?= <email address hidden>,
 Kurt Roeckx <email address hidden>
Subject: Re: Bug#297796: emacs21: FTBFS: timestamp skew issues.

Rob Browning <email address hidden> writes:

> So it seems like the *only* thing we're in potential disagreement
> about is whether we should automatically invoke this target *iff*
> there's a solid way to automatically determine when doing so would be
> appropriate.

Hmm. As a less automagic alternative, perhaps I could just arrange it
so that we just detect when the debian/autofiles.dpatch is out of date
and then print a suitable error message, rather than trying to update
it, i.e.

  $ fakeroot debian/rules binary
  ...
  ERROR: debian/patches/autofiles.dpatch out of date with respect to
  other patches. Please update it via "debian/rules update-autofiles-dpatch"
  and try again.
  $

The test would be handled via md5sum as previously described.

--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

[Jérôme Marant (jmarant)]

Quoting Rob Browning <email address hidden>:

> By "voodoo magic" do you mean the old approach, the possible md5
> approach, or both?

The combination of both.

> If you mean the old approach, then I obviously don't see it to be as
> cut and dry as you do. To be fair, the only reason the current code
> broke is because the relative timestamps for files in the debian diff
> are unpredictable, and I didn't think about that. Of course, that
> means that *any* files mentioned in the debian patch are potentially
> trouble as far as make is concerned. Without this problem, it would
> have been quite correct to have autofiles.diff depend on the files
> that may influence its contents (i.e. the *.dpatch files).
>
> Of course if you just mean that the .md5 approach would be "voodoo
> magic", then I'll agree that it's not completely straightforward.
> Though to the extent I've thought it through so far, I haven't come up
> with any problems.

What I don't understand is why you think that modifying configure.in
and regenerating configure cannot be considered as part of a
regular dpatch. Or maybe am I missing something?

As an example, the amd64 port needs configure.in to be changed. I
can the see the following scenario:
- run dpatch-edit-patch
- apply changes
- run autoconf: this changes "configure"
- exit from dpatch-edit-patch

Why wouldn't this work?

Why is it better to gather all changes to the configure script in
a single separate dpatch rather than spreading all changes along
with the patch it belongs to?

> In any case, even if we go with the "only update when requested"
> dpatch-edit-patch approach that I think you're advocating, I'd still
> want a target for it so we can just invoke that when needed,
> i.e. something (only very roughly) like this:
>
> update-autofiles-diff:
> # rm aclocal.m4 so it doesn't confuse newer autoconfs, but touch it
> # so ./Makefile won't be upset if it's not recreated (b/c not
> needed).
> (dpatch-edit-patch ... autofiles.dpatch
> && cd DPATCHDIR \
> && rm -f aclocal.m4 \
> && touch aclocal.m4 \
> && aclocal \
> && autoconf
> && exit)
>
> (...which is really not that much different than what we're already
> doing, but I'll agree that handling everything with dpatch would be a
> bit cleaner, and if it works right, then I'm fine with that.)

It would be kind of better, yes.

> So it seems like the *only* thing we're in potential disagreement
> about is whether we should automatically invoke this target *iff*
> there's a solid way to automatically determine when doing so would be
> appropriate.

I think so.

> > IMO, creating a whole copy of the tree and diffing at build-time is
> > not worth the effort. You have the final word, anyway :P
>
> It's not only not worth the effort, but it should never have happened
> under normal circumstances. As I mentioned, the only reason it did in
> this case was because I didn't consider the problem presented by the
> timestamps of files in the debian diff and so came up with a broken
> solution.

I almost all cases, changes to 'configure.in' only change 'configure'.
In the remainin...

[Rob Browning (rlb)]

Jérôme Marant <email address hidden> writes:

> What I don't understand is why you think that modifying configure.in
> and regenerating configure cannot be considered as part of a
> regular dpatch. Or maybe am I missing something?
>
> As an example, the amd64 port needs configure.in to be changed. I
> can the see the following scenario:
> - run dpatch-edit-patch
> - apply changes
> - run autoconf: this changes "configure"
> - exit from dpatch-edit-patch
>
> Why wouldn't this work?
>
> Why is it better to gather all changes to the configure script in
> a single separate dpatch rather than spreading all changes along
> with the patch it belongs to?

Because IMO modifications to configure.in (and any other autotools
related files, like Makefile.in for automake enabled packages, for
example) should be made in the .dpatch relevant to the overall change
in question. For example, the mailspool patch required changes to a
number of files in the source tree *and* to configure.in. I think
these configure.in changes should go in mailspool.dpatch, since that's
why they're there.

The changes in autofiles.diff are only supposed to be the result of
"whatever the autools change when run on a fully patched tree", and of
course that's not something you can predict without knowing all the
modifications that all of the .dpatch files have made to configure.in,
to any Makefile.ins (when automake is involved), and to any other
files that the currently installed version of the autotools might pay
attention to.

You could even imagine a foo.dpatch that adds libtool support to a
tree that didn't have it. This is going to cause a bunch of new
files/dirs to appear in the autofiles.diff, and exactly what appears
is going to depend on the version of libtool involved, the libtool
macros used in foo.dpatch, etc.

Also, as I mentioned before, part of the issue here is that I'd really
like to have a solution that's general enough to use with other dpatch
using packages, even ones that also use automake, libtool, etc.

> I almost all cases, changes to 'configure.in' only change 'configure'.
> In the remaining cases, changes only happen in the toplevel of the
> tree.

As suggested above, I don't think it's safe to presume that changes to
configure.in only change configure. Even if that's true now, it might
not be true for future versions of autoconf, and it's certainly not
true for packages where automake is involved. Actually, it might not
even be true in the current emacs21 package since we use aclocal, and
I suppose it's possible that aclocal might change what it writes to
aclocal.m4 (if anything) from version to version.

> I don't think it is unreasonnable to avoid duplicating the whole
> tree, isn't it?

That's what we do all the time when running dpatch-edit-patch, so I'm
not sure why it would be a problem when we're trying to capture an
autofiles.dpatch.

--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 9 Mar 2005 16:43:11 +0100
From: =?iso-8859-1?b?Suly9G1l?= Marant <email address hidden>
To: Rob Browning <email address hidden>, <email address hidden>
Subject: Re: Bug#297796: emacs21: FTBFS: timestamp skew issues.

Quoting Rob Browning <email address hidden>:

> By "voodoo magic" do you mean the old approach, the possible md5
> approach, or both?

The combination of both.

> If you mean the old approach, then I obviously don't see it to be as
> cut and dry as you do. To be fair, the only reason the current code
> broke is because the relative timestamps for files in the debian diff
> are unpredictable, and I didn't think about that. Of course, that
> means that *any* files mentioned in the debian patch are potentially
> trouble as far as make is concerned. Without this problem, it would
> have been quite correct to have autofiles.diff depend on the files
> that may influence its contents (i.e. the *.dpatch files).
>
> Of course if you just mean that the .md5 approach would be "voodoo
> magic", then I'll agree that it's not completely straightforward.
> Though to the extent I've thought it through so far, I haven't come up
> with any problems.

What I don't understand is why you think that modifying configure.in
and regenerating configure cannot be considered as part of a
regular dpatch. Or maybe am I missing something?

As an example, the amd64 port needs configure.in to be changed. I
can the see the following scenario:
- run dpatch-edit-patch
- apply changes
- run autoconf: this changes "configure"
- exit from dpatch-edit-patch

Why wouldn't this work?

Why is it better to gather all changes to the configure script in
a single separate dpatch rather than spreading all changes along
with the patch it belongs to?

> In any case, even if we go with the "only update when requested"
> dpatch-edit-patch approach that I think you're advocating, I'd still
> want a target for it so we can just invoke that when needed,
> i.e. something (only very roughly) like this:
>
> update-autofiles-diff:
> # rm aclocal.m4 so it doesn't confuse newer autoconfs, but to=
uch it
> # so ./Makefile won't be upset if it's not recreated (b/c not
> needed).
> (dpatch-edit-patch ... autofiles.dpatch
> && cd DPATCHDIR \
> && rm -f aclocal.m4 \
> && touch aclocal.m4 \
> && aclocal \
> && autoconf
> && exit)
>
> (...which is really not that much different than what we're already
> doing, but I'll agree that handling everything with dpatch would be a
> bit cleaner, and if it works right, then I'm fine with that.)

It would be kind of better, yes.

> So it seems like the *only* thing we're in potential disagreement
> about is whether we should automatically invoke this target *iff*
> there's a solid way to automatically determine when doing so would be
> appropriate.

I think so.

> > IMO, creating a whole copy of the tree and diffing at build-time is
> > not worth the effort. You have the final word, anyway :P
>
> It's not only not worth the effort, but it should never have happened
> under normal circumstances. As...

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 09 Mar 2005 10:14:40 -0600
From: Rob Browning <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#297796: emacs21: FTBFS: timestamp skew issues.

J=E9r=F4me Marant <email address hidden> writes:

> What I don't understand is why you think that modifying configure.in
> and regenerating configure cannot be considered as part of a
> regular dpatch. Or maybe am I missing something?
>
> As an example, the amd64 port needs configure.in to be changed. I
> can the see the following scenario:
> - run dpatch-edit-patch
> - apply changes
> - run autoconf: this changes "configure"
> - exit from dpatch-edit-patch
>
> Why wouldn't this work?
>
> Why is it better to gather all changes to the configure script in
> a single separate dpatch rather than spreading all changes along
> with the patch it belongs to?

Because IMO modifications to configure.in (and any other autotools
related files, like Makefile.in for automake enabled packages, for
example) should be made in the .dpatch relevant to the overall change
in question. For example, the mailspool patch required changes to a
number of files in the source tree *and* to configure.in. I think
these configure.in changes should go in mailspool.dpatch, since that's
why they're there.

The changes in autofiles.diff are only supposed to be the result of
"whatever the autools change when run on a fully patched tree", and of
course that's not something you can predict without knowing all the
modifications that all of the .dpatch files have made to configure.in,
to any Makefile.ins (when automake is involved), and to any other
files that the currently installed version of the autotools might pay
attention to.

You could even imagine a foo.dpatch that adds libtool support to a
tree that didn't have it. This is going to cause a bunch of new
files/dirs to appear in the autofiles.diff, and exactly what appears
is going to depend on the version of libtool involved, the libtool
macros used in foo.dpatch, etc.

Also, as I mentioned before, part of the issue here is that I'd really
like to have a solution that's general enough to use with other dpatch
using packages, even ones that also use automake, libtool, etc.

> I almost all cases, changes to 'configure.in' only change 'configure'.
> In the remaining cases, changes only happen in the toplevel of the
> tree.

As suggested above, I don't think it's safe to presume that changes to
configure.in only change configure. Even if that's true now, it might
not be true for future versions of autoconf, and it's certainly not
true for packages where automake is involved. Actually, it might not
even be true in the current emacs21 package since we use aclocal, and
I suppose it's possible that aclocal might change what it writes to
aclocal.m4 (if anything) from version to version.

> I don't think it is unreasonnable to avoid duplicating the whole
> tree, isn't it?

That's what we do all the time when running dpatch-edit-patch, so I'm
not sure why it would be a problem when we're trying to capture an
autofiles.dpatch.

--=20
Rob Browning
rlb @defaultvalue.org and @debian.org; previ...

[Rob Browning (rlb)]

Source: emacs21
Source-Version: 21.4a-1

We believe that the bug you reported is fixed in the latest version of
emacs21, which is due to be installed in the Debian FTP archive:

emacs21-bin-common_21.4a-1_i386.deb
  to pool/main/e/emacs21/emacs21-bin-common_21.4a-1_i386.deb
emacs21-common_21.4a-1_all.deb
  to pool/main/e/emacs21/emacs21-common_21.4a-1_all.deb
emacs21-el_21.4a-1_all.deb
  to pool/main/e/emacs21/emacs21-el_21.4a-1_all.deb
emacs21-nox_21.4a-1_i386.deb
  to pool/main/e/emacs21/emacs21-nox_21.4a-1_i386.deb
emacs21_21.4a-1.diff.gz
  to pool/main/e/emacs21/emacs21_21.4a-1.diff.gz
emacs21_21.4a-1.dsc
  to pool/main/e/emacs21/emacs21_21.4a-1.dsc
emacs21_21.4a-1_i386.deb
  to pool/main/e/emacs21/emacs21_21.4a-1_i386.deb
emacs21_21.4a.orig.tar.gz
  to pool/main/e/emacs21/emacs21_21.4a.orig.tar.gz

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Rob Browning <email address hidden> (supplier of updated emacs21 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue, 15 Mar 2005 11:00:04 -0600
Source: emacs21
Binary: emacs21-el emacs21-common emacs21-nox emacs21-bin-common emacs21
Architecture: source all i386
Version: 21.4a-1
Distribution: unstable
Urgency: medium
Maintainer: Rob Browning <email address hidden>
Changed-By: Rob Browning <email address hidden>
Description:
 emacs21 - The GNU Emacs editor
 emacs21-bin-common - The GNU Emacs editor's shared, architecture dependent files
 emacs21-common - The GNU Emacs editor's shared, architecture independent infrastru
 emacs21-el - GNU Emacs LISP (.el) files
 emacs21-nox - The GNU Emacs editor (without X support)
Closes: 248796 291221 294313 296618 297796
Changes:
 emacs21 (21.4a-1) unstable; urgency=medium
 .
   * New upstream release. (closes: #294313) [Jérôme Marant]
     - debian/patches/movemail-pop-fmt-vulnerability.dpatch: removed since
     it has been applied upstream.
 .
   * Apply patch from Romain Francoise <email address hidden> making PCL-CVS
     compliant with recent versions of CVS. (closes: #291221) [Jérôme Marant]
     - debian/patches/pcl-cvs-format.dpatch: new file.
     - debian/00list: updated.
     - debian/control: tightened dependency on dpatch (>= 2.0.9).
 .
   * Add MIME type to desktop file. (closes: #296618) [Jérôme Marant]
     - debian/emacs.desktop: added MimeType entry.
 .
   * Apply patch supporting the AMD64 architecture. This is a slightly
     modified patch derived from the Emacs CVS mainline. Thanks to
     Goswin von Brederlow <email address hidden> and
     amd64 porters. (closes: #248796) [Jérôme Marant]
     - debian/patches/arch-amd64.patch: new file.
     - debian/00list: updated.
 .
   * Hard code leim version in copyright.in for now. wit...

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Thu, 17 Mar 2005 20:47:24 -0500
From: Rob Browning <email address hidden>
To: <email address hidden>
Subject: Bug#297796: fixed in emacs21 21.4a-1

Source: emacs21
Source-Version: 21.4a-1

We believe that the bug you reported is fixed in the latest version of
emacs21, which is due to be installed in the Debian FTP archive:

emacs21-bin-common_21.4a-1_i386.deb
  to pool/main/e/emacs21/emacs21-bin-common_21.4a-1_i386.deb
emacs21-common_21.4a-1_all.deb
  to pool/main/e/emacs21/emacs21-common_21.4a-1_all.deb
emacs21-el_21.4a-1_all.deb
  to pool/main/e/emacs21/emacs21-el_21.4a-1_all.deb
emacs21-nox_21.4a-1_i386.deb
  to pool/main/e/emacs21/emacs21-nox_21.4a-1_i386.deb
emacs21_21.4a-1.diff.gz
  to pool/main/e/emacs21/emacs21_21.4a-1.diff.gz
emacs21_21.4a-1.dsc
  to pool/main/e/emacs21/emacs21_21.4a-1.dsc
emacs21_21.4a-1_i386.deb
  to pool/main/e/emacs21/emacs21_21.4a-1_i386.deb
emacs21_21.4a.orig.tar.gz
  to pool/main/e/emacs21/emacs21_21.4a.orig.tar.gz

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Rob Browning <email address hidden> (supplier of updated emacs21 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue, 15 Mar 2005 11:00:04 -0600
Source: emacs21
Binary: emacs21-el emacs21-common emacs21-nox emacs21-bin-common emacs21
Architecture: source all i386
Version: 21.4a-1
Distribution: unstable
Urgency: medium
Maintainer: Rob Browning <email address hidden>
Changed-By: Rob Browning <email address hidden>
Description:
 emacs21 - The GNU Emacs editor
 emacs21-bin-common - The GNU Emacs editor's shared, architecture dependent files
 emacs21-common - The GNU Emacs editor's shared, architecture independent infrastru
 emacs21-el - GNU Emacs LISP (.el) files
 emacs21-nox - The GNU Emacs editor (without X support)
Closes: 248796 291221 294313 296618 297796
Changes:
 emacs21 (21.4a-1) unstable; urgency=medium
 .
   * New upstream release. (closes: #294313) [Jérôme Marant]
     - debian/patches/movemail-pop-fmt-vulnerability.dpatch: removed since
     it has been applied upstream.
 .
   * Apply patch from Romain Francoise <email address hidden> making PCL-CVS
     compliant with recent versions of CVS. (closes: #291221) [Jérôme Marant]
     - debian/patches/pcl-cvs-format.dpatch: new file.
     - debian/00list: updated.
     - debian/control: tightened dependency on dpatch (>= 2.0.9).
 .
   * Add MIME type to desktop file. (closes: #296618) [Jérôme Marant]
     - debian/emacs.desktop: added MimeType entry.
 .
   * Apply patch supporting the AMD64 architecture. This is a slightly
     modified patch derived from the Emacs CVS mainline. Thanks to
     Goswin von Brederlow <<email address hidden>....