Jérôme Marant <[EMAIL PROTECTED]> 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
>
Quoting Rob Browning <[EMAIL PROTECTED]>:
> 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
Rob Browning <[EMAIL PROTECTED]> 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 alterna
Jérôme Marant <[EMAIL PROTECTED]> 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
appro
Rob Browning <[EMAIL PROTECTED]> writes:
> Jérôme Marant <[EMAIL PROTECTED]> 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
Jérôme Marant <[EMAIL PROTECTED]> 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 leav
Quoting Rob Browning <[EMAIL PROTECTED]>:
> > 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 determin
Jérôme Marant <[EMAIL PROTECTED]> writes:
> Quoting Kurt Roeckx <[EMAIL PROTECTED]>:
>
>
>> 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/autofi
Quoting Kurt Roeckx <[EMAIL PROTECTED]>:
> 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 be
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 >>p
10 matches
Mail list logo
