So, I did some tests here.
Helmut, look below:
On Tue, Dec 07, 2021 at 09:20:09PM +0100, Niels Thykier wrote:
> You can either depend on it or do a runtime check for the new function
> to see if the feature is available - whatever floats your boat. :)
I went this way indeed:
--- strip-nondeterm
Chris Lamb:
> Hi Niels,
>
>> I think it would something like this from the debhelper side:
>>
>> https://salsa.debian.org/debian/debhelper/-/merge_requests/58
>>
>> Would that work for you? :)
>
> Indeed it would. Would strip-nondeterminism then simply Depend on the
> version of debhelper this
Hi Niels,
> I think it would something like this from the debhelper side:
>
> https://salsa.debian.org/debian/debhelper/-/merge_requests/58
>
> Would that work for you? :)
Indeed it would. Would strip-nondeterminism then simply Depend on the
version of debhelper this change gets released in? Or
Mattia Rizzolo:
> [...]
>
> Niels: how do you suspect such "infrastructure" to look like? Right now
> dh_strip_nondeterminism is using get_source_date_epoch() from Dh_Lib.pm
> to get the timestamp to use for everything. If you can provide a
> similar function returning a similar value but coming
On Sun, Nov 28, 2021 at 10:38:40AM +0100, Niels Thykier wrote:
> As in, would it be an option for dh_strip_nondeterminism to use the
> changelog date from the original upload inside the files while
> debhelper/dpkg used the changelog date from the binNMU load for the
> external mtimes for files?
I
Control: tags -1 + patch
Hi Chris,
On Wed, Dec 01, 2021 at 01:13:03AM -, Chris Lamb wrote:
> In other words, it's not a lack of interest or an uncaring disregard
> for other parts of Debian (!), something that other mails in this
> thread might have accidentally implied.
I did not mean to
Hi all,
>> As such, I propose that debhelper automatically disables
>> dh_strip_nondeterminism if and only if both relevant conditions are met.
>> What do you think about this?
>
> If we go that route, then the conditional would belong in
> dh_strip_nondeterminism to disable itself.
Just as a bit
Hi Niels,
On Sun, Nov 28, 2021 at 10:38:40AM +0100, Niels Thykier wrote:
> To confirm: The root cause here is that dh_strip_nondeterminism uses the
> binNMU timestamp which differs between each architecture for timestamps
> *inside* the files being modified.
Yes.
> Clarification needed: This is
Helmut Grohne:
> Package: debhelper
> Version: 13.5.2
> Severity: important
> X-Debbugs-Cc: debian-cr...@lists.debian.org,
> rb-gene...@lists.reproducible-builds.org
>
> Hi,
>
> [...]
>
> The situation is that when performing a binNMU, the changelogs are
> created with differing timestamps. [..
Package: debhelper
Version: 13.5.2
Severity: important
X-Debbugs-Cc: debian-cr...@lists.debian.org,
rb-gene...@lists.reproducible-builds.org
Hi,
dh_strip_nondeterminism was automatically enabled on the provision that
it wouldn't break stuff. To a large extend, that's the case.
Unfortunately, the
10 matches
Mail list logo
