From jspricke at debian.org  Mon Jul 13 16:22:31 2026
From: jspricke at debian.org (Jochen Sprickerhof)
Date: Mon, 13 Jul 2026 17:22:31 +0200
Subject: Bug#1142001: rakudo: patch to make timestamp in metadata reproducible
Message-ID: <178395615105.121616.8329230321469007424.reportbug@fenchel>

Source: rakudo
Version: 2024.09-4
Severity: normal
Tags: patch
X-Debbugs-Cc: reproducible-bugs at lists.alioth.debian.org
User: reproducible-builds at lists.alioth.debian.org
Usertags: randomness

Hi,

Rakudo captures the file timestamp into the metadata when compiling
modules. This is normally fine except fore files that are touched by
debian/patches. Examples:

https://reproduce.debian.net/all/api/v1/builds/176802/artifacts/336780/diffoscope
https://reproduce.debian.net/all/api/v1/builds/180915/artifacts/344761/diffoscope
https://reproduce.debian.net/all/api/v1/builds/180660/artifacts/344452/diffoscope
https://reproduce.debian.net/all/api/v1/builds/177031/artifacts/337508/diffoscope


dpkg can't clamp the timestamp to a specific date as that could break
make, so instead I propose to use $SOURCE_DATE_EPOCH in the metadata
instead. The attached patch implements this.

Once this or an equivalent patch is applied, these packages need at
least a no change upload to get fixed as they are arch:all and can't be
binNMUed:  raku-readline, raku-license-spdx, raku-hash-merge, raku-log.

Note that there is already #1002496 discussing broader changes. As this
seems to be the only problem affecting reproduce.debian.net I opened a
new bug.

Cheers Jochen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Use-SOURCE_DATE_EPOCH-fore-metadata-to-make-it-repro.patch
Type: application/mbox
Size: 2593 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-rakudo-devel/attachments/20260713/1b681b83/attachment.mbox>

From jspricke at debian.org  Mon Jul 13 18:31:03 2026
From: jspricke at debian.org (Jochen Sprickerhof)
Date: Mon, 13 Jul 2026 19:31:03 +0200
Subject: Bug#1142001: rakudo: patch to make timestamp in metadata reproducible
In-Reply-To: <178395615105.121616.8329230321469007424.reportbug@fenchel>
References: <178395615105.121616.8329230321469007424.reportbug@fenchel>
 <178395615105.121616.8329230321469007424.reportbug@fenchel>
Message-ID: <alUg0yb1iclb7AQH@fenchel>

* Jochen Sprickerhof <jspricke at debian.org> [2026-07-13 17:22]:
>Source: rakudo
>Version: 2024.09-4
>Severity: normal
>Tags: patch
>X-Debbugs-Cc: reproducible-bugs at lists.alioth.debian.org
>User: reproducible-builds at lists.alioth.debian.org
>Usertags: randomness
>
>Hi,
>
>Rakudo captures the file timestamp into the metadata when compiling
>modules. This is normally fine except fore files that are touched by
>debian/patches. Examples:
>
>https://reproduce.debian.net/all/api/v1/builds/176802/artifacts/336780/diffoscope
>https://reproduce.debian.net/all/api/v1/builds/180915/artifacts/344761/diffoscope
>https://reproduce.debian.net/all/api/v1/builds/180660/artifacts/344452/diffoscope
>https://reproduce.debian.net/all/api/v1/builds/177031/artifacts/337508/diffoscope
>
>
>dpkg can't clamp the timestamp to a specific date as that could break
>make, so instead I propose to use $SOURCE_DATE_EPOCH in the metadata
>instead. The attached patch implements this.

Guillem proposed to only clamp newer timestamps, alternative patch 
attached.

Obviously there is a third option to drop the time entry as it seems to 
be optionsl. I don't know how it is used, so I leave the decision to the 
maintainer.

Cheers Jochen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Clamp-timestamp-in-metadata-with-SOURCE_DATE_EPOCH.patch
Type: text/x-diff
Size: 2674 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-rakudo-devel/attachments/20260713/ae6e5ed1/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-rakudo-devel/attachments/20260713/ae6e5ed1/attachment.sig>