From noreply at release.debian.org Mon Jan 20 04:40:05 2025 From: noreply at release.debian.org (Debian testing autoremoval watch) Date: Mon, 20 Jan 2025 04:40:05 +0000 Subject: diffoscope is marked for autoremoval from testing Message-ID: diffoscope 285 is marked for autoremoval from testing on 2025-02-18 It (build-)depends on packages with these RC bugs: 1091009: gnumeric: FTBFS: failed tests https://bugs.debian.org/1091009 1091430: pyside2: pyside2 FTBFS with Python 3.13 as default https://bugs.debian.org/1091430 1092080: pyside2: pyside2 ftbfs with Python 3.13 as the default https://bugs.debian.org/1092080 1092529: pyside6: FTBFS: ValueError: 7 failures were not blacklisted and met the criterion 'FAIL! >= 3' https://bugs.debian.org/1092529 For more information on the autoremoval process, including hints to prevent autoremoval can be found on the wiki: https://wiki.debian.org/Autoremoval This mail is generated by: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl Autoremoval data is generated by: https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl From owner at bugs.debian.org Mon Jan 20 10:09:02 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Mon, 20 Jan 2025 10:09:02 +0000 Subject: Processed: Re: diffoscope: crash when processing IDEA CE distributions References: <173736751031.8846.18174111421555497970@copycat> Message-ID: Processing commands for control at bugs.debian.org: > tags 1093484 + pending Bug #1093484 [diffoscope] diffoscope: crash when processing IDEA CE distributions Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 1093484: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093484 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From lamby at debian.org Mon Jan 20 10:05:55 2025 From: lamby at debian.org (Chris Lamb) Date: Mon, 20 Jan 2025 05:05:55 -0500 (EST) Subject: Bug#1093484: diffoscope: crash when processing IDEA CE distributions References: <173727506366.3700439.10565721987476525373.reportbug@inappropriate> Message-ID: <173736751031.8846.18174111421555497970@copycat> tags 1093484 + pending thanks Fixed in Git, pending upload: https://salsa.debian.org/reproducible-builds/diffoscope/commit/9a0faeedabd41019d135d4bdfef233400e4aff20 diffoscope/comparators/zip.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Regards, -- ,''`. : :' : Chris Lamb `. `'` lamby at debian.org / chris-lamb.co.uk `- From owner at bugs.debian.org Mon Jan 20 10:33:03 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Mon, 20 Jan 2025 10:33:03 +0000 Subject: Processed: Re: Bug#1093412: Regression in tests with new faketime References: <26510.9637.765479.645905@chiark.greenend.org.uk> <26507.32671.821362.507648@chiark.greenend.org.uk> Message-ID: Processing control commands: > reassign -1 fakeroot Bug #1093412 [reprotest] Regression in tests with new faketime Bug reassigned from package 'reprotest' to 'fakeroot'. No longer marked as found in versions reprotest/0.7.29. Ignoring request to alter fixed versions of bug #1093412 to the same values previously set > found -1 debian/0.9.10+2024-06-05+gba9ed5b2-0.1 Bug #1093412 [fakeroot] Regression in tests with new faketime The source debian and version 0.9.10+2024-06-05+gba9ed5b2-0.1 do not appear to match any binary packages Marked as found in versions debian/0.9.10+2024-06-05+gba9ed5b2-0.1. > fixed -1 debian/0.9.10+2024-06-05+gba9ed5b2-0.2 Bug #1093412 [fakeroot] Regression in tests with new faketime The source debian and version 0.9.10+2024-06-05+gba9ed5b2-0.2 do not appear to match any binary packages Marked as fixed in versions debian/0.9.10+2024-06-05+gba9ed5b2-0.2. -- 1093412: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093412 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From ijackson at chiark.greenend.org.uk Mon Jan 20 10:29:57 2025 From: ijackson at chiark.greenend.org.uk (Ian Jackson) Date: Mon, 20 Jan 2025 10:29:57 +0000 Subject: Bug#1093412: Regression in tests with new faketime In-Reply-To: References: <26507.32671.821362.507648@chiark.greenend.org.uk> <173730669609.208177.4469364022704502226.reportbug@frontier> <26509.17217.697241.546067@chiark.greenend.org.uk> <26509.21238.598464.529962@chiark.greenend.org.uk> <26507.32671.821362.507648@chiark.greenend.org.uk> Message-ID: <26510.9637.765479.645905@chiark.greenend.org.uk> Control: reassign -1 fakeroot Control: found -1 debian/0.9.10+2024-06-05+gba9ed5b2-0.1 Control: fixed -1 debian/0.9.10+2024-06-05+gba9ed5b2-0.2 James Addison writes ("Re: Bug#1093412: Regression in tests with new faketime"): > Although we want reprotest to intentionally vary[1] the apparent > system clock -- to help discover unwanted dynamic timestamps that > appear in the resulting output -- we do not want it to affect > filesystem timestamps, because those may represent authorship and/or > versioning information. In some cases I think filesystem timestamps > can also affect build processes - e.g. Make target evaluation - but > I'm not sure that that is our primary concern. > > By default, faketime does adjust apparent filesystem timestamps -- and > so we use the NO_FAKE_STAT option[2] to deactivate that behaviour. That makes sense to me. I see that the reprotest autopkgtest is now fixed, after I restored the default to not fake utime. There is still a problem with the gem2deb autopkgtests which looks like UB. I found some UB (#1093599) and am intending to fix it. Thanks for your input! Ian. -- Ian Jackson These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter. From lamby at debian.org Mon Jan 20 11:05:44 2025 From: lamby at debian.org (Chris Lamb) Date: Mon, 20 Jan 2025 11:05:44 +0000 Subject: Bug#1093513: strip-nondeterminism: Claims to normalize `.mo` file when it in fact does not change it In-Reply-To: <61e80515-3b78-4417-b9ff-bc5563b6d80b@thykier.net> References: <61e80515-3b78-4417-b9ff-bc5563b6d80b@thykier.net> <61e80515-3b78-4417-b9ff-bc5563b6d80b@thykier.net> Message-ID: Hi Niels, > I am not sure why this happened because at first glance, the > `gettext.pm` handler does seem to the correct guards in place. As you imply, the "Normalizing da.mo" message is highly misleading: it's printed *before* calling the normalizer in all cases, and simply denotes that we are just about to call into the format-specific code. I'll change it to "Calling normalizer for $filename" shortly. > Nevertheless, it must be returning a truth value, since the message appears. Contrary to what you write here, the normalizer is not returning a truth value for da.mo ? see my previous paragraph. Of course, it is understandable you thought this given the message is, as you write, rather misleading. :) The main question that remains is whether there is anything in da.mo that should be normalized. If there is, then there is an additional bug in the normalizer (and not just the bug in the phrasing of the message). Regards, -- ,''`. : :' : Chris Lamb `. `'` lamby at debian.org ? chris-lamb.co.uk `- From niels at thykier.net Mon Jan 20 11:15:06 2025 From: niels at thykier.net (Niels Thykier) Date: Mon, 20 Jan 2025 12:15:06 +0100 Subject: Bug#1093513: strip-nondeterminism: Claims to normalize `.mo` file when it in fact does not change it In-Reply-To: References: <61e80515-3b78-4417-b9ff-bc5563b6d80b@thykier.net> <61e80515-3b78-4417-b9ff-bc5563b6d80b@thykier.net> Message-ID: <79939d90-63f5-4b4f-8ad0-c60d99dd1722@thykier.net> Chris Lamb: > Hi Niels, > >> I am not sure why this happened because at first glance, the >> `gettext.pm` handler does seem to the correct guards in place. > > As you imply, the "Normalizing da.mo" message is highly misleading: > it's printed *before* calling the normalizer in all cases, and simply > denotes that we are just about to call into the format-specific code. > > I'll change it to "Calling normalizer for $filename" shortly. > >> Nevertheless, it must be returning a truth value, since the message appears. > > Contrary to what you write here, the normalizer is not returning a > truth value for da.mo ? see my previous paragraph. Of course, it is > understandable you thought this given the message is, as you write, > rather misleading. :) > > The main question that remains is whether there is anything in da.mo > that should be normalized. If there is, then there is an additional > bug in the normalizer (and not just the bug in the phrasing of the > message). > > > Regards, > Ok. I was confused because `dh_strip_nondeterminism` has two messages here. One for "Normalizing ... using ..." and one for "Normalized ..." (vs. "Normalizing ..." from `strip-nondeterminism` that matches the "first" case without naming the normalizer). I would like the same behavior from `strip-nondeterminism`, so you can tell which files were actually modified (normalized) like you can with `dh_strip_nondeterminism`). I would see the "Normalized ..." case as being on by default (without needing `--verbose`) and "Normalizing ... [using ...]" or "Calling normalizer for ..." being fine as `--verbose` only. My reason for asking is that in my work on `debputy`, I cannot use `dh_strip_nondeterminism`. Instead, I invoke `strip-nondeterminism` directly and I would like the feature parity of presenting to the user (including in the buildlog) which files were modified. Best regards, Niels -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lamby at debian.org Mon Jan 20 11:17:09 2025 From: lamby at debian.org (Chris Lamb) Date: Mon, 20 Jan 2025 11:17:09 +0000 Subject: Bug#1093513: strip-nondeterminism: Claims to normalize `.mo` file when it in fact does not change it In-Reply-To: <79939d90-63f5-4b4f-8ad0-c60d99dd1722@thykier.net> References: <61e80515-3b78-4417-b9ff-bc5563b6d80b@thykier.net> <79939d90-63f5-4b4f-8ad0-c60d99dd1722@thykier.net> <61e80515-3b78-4417-b9ff-bc5563b6d80b@thykier.net> Message-ID: <552c6400-604a-4847-a92b-2dfd5c91cef6@app.fastmail.com> Niels Thykier wrote: > My reason for asking is that in my work on `debputy`, I cannot use > `dh_strip_nondeterminism`. Instead, I invoke `strip-nondeterminism` > directly and I would like the feature parity of presenting to the user > (including in the buildlog) which files were modified. Totally understand, and I'll make the necessary changes to make this possible. Just to confirm though: is there anything in da.mo that actually needs to be normalized? Is there a bug in gettext.pm as well? Regards, -- ,''`. : :' : Chris Lamb `. `'` lamby at debian.org ? chris-lamb.co.uk `- From niels at thykier.net Mon Jan 20 11:25:06 2025 From: niels at thykier.net (Niels Thykier) Date: Mon, 20 Jan 2025 12:25:06 +0100 Subject: Bug#1093513: strip-nondeterminism: Claims to normalize `.mo` file when it in fact does not change it In-Reply-To: <552c6400-604a-4847-a92b-2dfd5c91cef6@app.fastmail.com> References: <61e80515-3b78-4417-b9ff-bc5563b6d80b@thykier.net> <79939d90-63f5-4b4f-8ad0-c60d99dd1722@thykier.net> <552c6400-604a-4847-a92b-2dfd5c91cef6@app.fastmail.com> <61e80515-3b78-4417-b9ff-bc5563b6d80b@thykier.net> Message-ID: Chris Lamb: > Niels Thykier wrote: > >> My reason for asking is that in my work on `debputy`, I cannot use >> `dh_strip_nondeterminism`. Instead, I invoke `strip-nondeterminism` >> directly and I would like the feature parity of presenting to the user >> (including in the buildlog) which files were modified. > > Totally understand, and I'll make the necessary changes to make this > possible. > > Just to confirm though: is there anything in da.mo that actually > needs to be normalized? Is there a bug in gettext.pm as well? > > > > Regards, > Honestly, I do not know. However, the timestamps in `da.po` were before the `SOURCE_DATE_EPOCH`, so the fact that is unchanged seems entirely reasonable from what little domain knowledge I have on `gettext` related problems. Best regards, Niels -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From ftpmaster at ftp-master.debian.org Tue Jan 21 11:26:45 2025 From: ftpmaster at ftp-master.debian.org (Debian FTP Masters) Date: Tue, 21 Jan 2025 11:26:45 +0000 Subject: Processing of strip-nondeterminism_1.14.1-1_amd64.changes Message-ID: strip-nondeterminism_1.14.1-1_amd64.changes uploaded successfully to localhost along with the files: strip-nondeterminism_1.14.1-1.dsc strip-nondeterminism_1.14.1.orig.tar.bz2 strip-nondeterminism_1.14.1.orig.tar.bz2.asc strip-nondeterminism_1.14.1-1.debian.tar.xz strip-nondeterminism_1.14.1-1_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org) From owner at bugs.debian.org Tue Jan 21 11:27:02 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Tue, 21 Jan 2025 11:27:02 +0000 Subject: Processed: Bug#1093513 marked as pending in strip-nondeterminism References: <678f83e4886a7_3d0104033044@godard.mail> <61e80515-3b78-4417-b9ff-bc5563b6d80b@thykier.net> Message-ID: Processing control commands: > tag -1 pending Bug #1093513 [strip-nondeterminism] strip-nondeterminism: Claims to normalize `.mo` file when it in fact does not change it Added tag(s) pending. -- 1093513: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093513 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From ftpmaster at ftp-master.debian.org Tue Jan 21 11:35:30 2025 From: ftpmaster at ftp-master.debian.org (Debian FTP Masters) Date: Tue, 21 Jan 2025 11:35:30 +0000 Subject: strip-nondeterminism_1.14.1-1_amd64.changes ACCEPTED into unstable Message-ID: Thank you for your contribution to Debian. Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Tue, 21 Jan 2025 11:23:24 +0000 Source: strip-nondeterminism Architecture: source Version: 1.14.1-1 Distribution: unstable Urgency: medium Maintainer: Reproducible builds folks Changed-By: Chris Lamb Closes: 1093513 Changes: strip-nondeterminism (1.14.1-1) unstable; urgency=medium . [ Chris Lamb ] * Clarify the --verbose and non-verbose output of the strip-nondeterminism entry point so we don't imply we are normalizing files when we are not. Thanks, Niels Thykier. (Closes: #1093513) . [ Ed J ] * Use and define a $full_name variable to improve code legibility. Checksums-Sha1: e24382a620bf645303f5fb312a1bdee051efbb88 2806 strip-nondeterminism_1.14.1-1.dsc fd62c71fe46efca27b77ff3c77d3ecbc6ba5ca34 279976 strip-nondeterminism_1.14.1.orig.tar.bz2 abbbd8edfa03217b2f0f8e63ea4f8624d7785858 833 strip-nondeterminism_1.14.1.orig.tar.bz2.asc 8a3f0eacad205c40ab4d55c5294fb1d75d2420ce 33536 strip-nondeterminism_1.14.1-1.debian.tar.xz cd25640f8765f917877edcca27b3e38c76756021 6906 strip-nondeterminism_1.14.1-1_amd64.buildinfo Checksums-Sha256: 694548c51477bf542bbea10f639a0fa51a6c15097847d1c1b3883085b08f996a 2806 strip-nondeterminism_1.14.1-1.dsc 149e5e7585cd1d8e777564d5772fb1afa5ed7be4a049c52ffc3a31de2bc04b93 279976 strip-nondeterminism_1.14.1.orig.tar.bz2 de999cba12fe67b4e4f09bf62039dea5ef56c0152a731c598ccb98d6dc327ce5 833 strip-nondeterminism_1.14.1.orig.tar.bz2.asc 500762a6a39044d777c43c2463b41e3c964c06072d524edafe2421865381978d 33536 strip-nondeterminism_1.14.1-1.debian.tar.xz 13ab82fef89d715a3361d295d858cb6999df9163c05886107a1d8d640ff158ab 6906 strip-nondeterminism_1.14.1-1_amd64.buildinfo Files: 386d82c20ed1132ed9c3e3cde6acb860 2806 devel optional strip-nondeterminism_1.14.1-1.dsc e58cabc741ddd1e812d6e6146c7fd822 279976 devel optional strip-nondeterminism_1.14.1.orig.tar.bz2 0c0748b58450121d19a0b7a63e9d5a3d 833 devel optional strip-nondeterminism_1.14.1.orig.tar.bz2.asc a26b495e07f7ccae37a12f893f6acc8a 33536 devel optional strip-nondeterminism_1.14.1-1.debian.tar.xz 57f40f4177a5977d727e7c3e76a44de6 6906 devel optional strip-nondeterminism_1.14.1-1_amd64.buildinfo -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEwv5L0nHBObhsUz5GHpU+J9QxHlgFAmePhAoACgkQHpU+J9Qx Hlge/hAAurLg+1zgU0lZDMLKa+yYdQPdfIvvSLRnweiJcT7fC2iSAxAZwIIy118c svUBfSvS6Vx7Cjbn/wMERP8nIAsbjImBhxuabmAKEhVr8F/DZBQ93kw1mMSU9hFG lN0YQ7tz8aGe27thvi50Pk1nKBNiyuRiOJIoCTiCOKQ0z0T4KY3RGWG5h9ounkpn eNx7W6XRiy6+JxykXGx8Kaf6NJpxqU2+6lZe1mIsc5KEg4B7FjWo7W5FTJUgumVL n2K1wJge6W5NpPm2jVjLD1crzoUDigOMJTQ45hJhhdnfTnO/duYE1jx2H/n7J+cx 5nIaDod+/v/FR0rGPd7Orbs5pkEP1JVbGk+eeiZ/YUOHlAEcwPGT01z3OO/5cjuU A7UsuR7CrXFApKwiWD4UujzPatJN7Y8j4wEPgN7r0tTLNci5LRorN6U/6FN2+inf gZffpADPBWKnH80vtAO80ac865GLUXXTGRh253d9WF045QY+hdKBac4XlcFyUTqS iGiknRU8N491sHoGgeTo3FDiaoBvzLNhUv5Gx7n9eyf2HjhyeyR4ntCg05xDYMtd sszp8/tUIW/D6gwzzRuQk6koX+qRKowG51GyzSy5cJg+FaZqvxyFNL4MnUdfa/WZ 98TyeU6NgwSCFOVCv+8tejOsh+iUXo31ucUJBlWhMTivma768pI= =2JFo -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From owner at bugs.debian.org Tue Jan 21 11:39:02 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Tue, 21 Jan 2025 11:39:02 +0000 Subject: Bug#1093513: marked as done (strip-nondeterminism: Claims to normalize `.mo` file when it in fact does not change it) References: <61e80515-3b78-4417-b9ff-bc5563b6d80b@thykier.net> Message-ID: Your message dated Tue, 21 Jan 2025 11:35:30 +0000 with message-id and subject line Bug#1093513: fixed in strip-nondeterminism 1.14.1-1 has caused the Debian Bug report #1093513, regarding strip-nondeterminism: Claims to normalize `.mo` file when it in fact does not change it to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner at bugs.debian.org immediately.) -- 1093513: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093513 Debian Bug Tracking System Contact owner at bugs.debian.org with problems -------------- next part -------------- An embedded message was scrubbed... From: Niels Thykier Subject: strip-nondeterminism: Claims to normalize `.mo` file when it in fact does not change it Date: Sun, 19 Jan 2025 13:42:54 +0100 Size: 277308 URL: -------------- next part -------------- An embedded message was scrubbed... From: Debian FTP Masters Subject: Bug#1093513: fixed in strip-nondeterminism 1.14.1-1 Date: Tue, 21 Jan 2025 11:35:30 +0000 Size: 7830 URL: From electricte at jlmsx.net Wed Jan 22 10:33:37 2025 From: electricte at jlmsx.net (Alex) Date: Wed, 22 Jan 2025 11:33:37 +0100 Subject: the evolution of ebikes: past, present, and future Message-ID: <91c50f8dba43f6501bfb5e7e8c932e04@belecke.de> An HTML attachment was scrubbed... URL: From stokito at gmail.com Wed Jan 22 12:24:57 2025 From: stokito at gmail.com (Sergey Ponomarev) Date: Wed, 22 Jan 2025 14:24:57 +0200 Subject: Promote the default reproducible build date Message-ID: The 1980-02-01 was chosen as a default reproducible date in many tools like Gradle and Maven (any others?). Could you mention it on the page https://reproducible-builds.org/docs/timestamps/ We need to put rationale why the date was chosen to be a default. Some other tools like archivers may need a simpler way to generate repo archives without timestamps. For example today I wanted to do this for a tar command and found that this is not so easy to do. Search shows the StackOverflow "How to create a tar file that omits timestamps for its contents?" thread the points to the article official reproducible-builds article "Archive metadata" that proposes the long command: tar --sort=name \ --mtime="@${SOURCE_DATE_EPOCH}" \ --owner=0 --group=0 --numeric-owner \ --pax-option=exthdr.name=%d/PaxHeaders/%f,delete=atime,delete=ctime \ -cf product.tar build I have a few propositions: 1. If the SOURCE_DATE_EPOCH var is empty use 1980-02-01 by default --mtime="@${SOURCE_DATE_EPOCH:-318211200}" 2. Maybe we can propose a patch to the gnu tar to read the SOURCE_DATE_EPOCH env and use it by default? 3. Maybe we can propose a patch to the gnu tar to have a short option --reproducible that will set other options --mtime --owner --group --pax-option to the needed values. We should make this easier to use. Other tools like zip, zstd may also need for same behaviour. From simon at josefsson.org Wed Jan 22 13:09:03 2025 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 22 Jan 2025 14:09:03 +0100 Subject: Promote the default reproducible build date In-Reply-To: (Sergey Ponomarev's message of "Wed, 22 Jan 2025 14:24:57 +0200") References: Message-ID: <87ed0vro5s.fsf@kaka.sjd.se> Sergey Ponomarev writes: > The 1980-02-01 was chosen as a default reproducible date in many tools > like Gradle and Maven (any others?). > Could you mention it on the page > https://reproducible-builds.org/docs/timestamps/ > We need to put rationale why the date was chosen to be a default. > > Some other tools like archivers may need a simpler way to generate > repo archives without timestamps. > For example today I wanted to do this for a tar command and found that > this is not so easy to do. Search shows the StackOverflow "How to > create a tar file that omits timestamps for its contents?" thread the > points to the article official reproducible-builds article "Archive > metadata" that proposes the long command: > > tar --sort=name \ > --mtime="@${SOURCE_DATE_EPOCH}" \ > --owner=0 --group=0 --numeric-owner \ > --pax-option=exthdr.name=%d/PaxHeaders/%f,delete=atime,delete=ctime \ > -cf product.tar build Another useful reference on this is the GNU Tar manual section reproducibility: https://www.gnu.org/software/tar/manual/html_node/Reproducibility.html > I have a few propositions: > 1. If the SOURCE_DATE_EPOCH var is empty use 1980-02-01 by default > --mtime="@${SOURCE_DATE_EPOCH:-318211200}" > 2. Maybe we can propose a patch to the gnu tar to read the > SOURCE_DATE_EPOCH env and use it by default? Please don't push the SOURCE_DATE_EPOCH idiom into upstream code. It is a good idiom that is needed for packaging work. But as a upstream maintainer for a bunch of projects my impression is that patches that involve SOURCE_DATE_EPOCH are the wrong way to resolve underlying reproducability problems. Please report the underlying reproducability problem instead. /Simon > 3. Maybe we can propose a patch to the gnu tar to have a short option > --reproducible that will set other options --mtime --owner --group > --pax-option to the needed values. > > We should make this easier to use. Other tools like zip, zstd may also > need for same behaviour. > > _______________________________________________ > Reproducible-builds mailing list > Reproducible-builds at alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1251 bytes Desc: not available URL: From jay at jp-hosting.net Wed Jan 22 13:33:16 2025 From: jay at jp-hosting.net (James Addison) Date: Wed, 22 Jan 2025 13:33:16 +0000 Subject: Bug#1093768: disorderfs: consider enabling 'hard_remove' FUSE option by default Message-ID: <173755279603.12652.16994805086253929674.reportbug@frontier> Package: disorderfs Version: 0.5.11-4 Severity: minor Tags: upstream Dear Maintainer, As I reported[1] to the rb-general mailing list recently, there is a quirk in the behaviour of FUSE filesystems relating to removal of currently-open files; they are not deleted from the underlying filesystem by default, but instead are renamed to a temporary dotfile name. This can cause unexpected results, such as failures to remove a directory that is expected to be empty. I'd like to suggest that we enable the FUSE 'hard_remove' option by default, which will propagate the removal operation directly to the underlying filesystem. One word of caution, though: There _is_ a note[2] in the FUSE documentation that the option is not recommended, because subsequent operations on unlinked (removed) files will fail. Perhaps that side-effect would produce other, more significant failure cases that are trickier to deal with. I plan to open a merge request on upstream Salsa with a test case to demonstrate the problem, and a modification to enable hard_remove that resolves it. Regards, James [1] - https://lists.reproducible-builds.org/pipermail/rb-general/2025-January/003637.html [2] - http://libfuse.github.io/doxygen/structfuse__config.html#af32ff56fa1131da899756cc352718101 From holger at layer-acht.org Wed Jan 22 13:36:09 2025 From: holger at layer-acht.org (Holger Levsen) Date: Wed, 22 Jan 2025 13:36:09 +0000 Subject: Promote the default reproducible build date In-Reply-To: References: Message-ID: On Wed, Jan 22, 2025 at 02:24:57PM +0200, Sergey Ponomarev wrote: > The 1980-02-01 was chosen as a default reproducible date in many tools > like Gradle and Maven (any others?). > Could you mention it on the page > https://reproducible-builds.org/docs/timestamps/ > We need to put rationale why the date was chosen to be a default. but we did not choose 1980-02-01, you need to ask gradle or maven. we recommend to either use no dates at all, or to use SOURCE_DATE_EPOCH, which is the last modification of the source code, which is a somewhat meaningful date. another common chosen date is 1970-01-01 or rather epoch 0. -- cheers, Holger ??????? ??????? holger@(debian|reproducible-builds|layer-acht).org ??????? OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ??? Fischers Fritz fischt Plastik. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jay at jp-hosting.net Wed Jan 22 13:47:16 2025 From: jay at jp-hosting.net (James Addison) Date: Wed, 22 Jan 2025 13:47:16 +0000 Subject: Bug#1093768: disorderfs: consider enabling 'hard_remove' FUSE option by default References: <173755279603.12652.16994805086253929674.reportbug@frontier> Message-ID: <173755363616.13883.7272635282010591428.reportbug@frontier> Package: disorderfs Followup-For: Bug #1093768 Control: forwarded -1 https://salsa.debian.org/reproducible-builds/disorderfs/-/merge_requests/5 From owner at bugs.debian.org Wed Jan 22 13:51:02 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Wed, 22 Jan 2025 13:51:02 +0000 Subject: Processed: Re: disorderfs: consider enabling 'hard_remove' FUSE option by default References: <173755363616.13883.7272635282010591428.reportbug@frontier> <173755279603.12652.16994805086253929674.reportbug@frontier> Message-ID: Processing control commands: > forwarded -1 https://salsa.debian.org/reproducible-builds/disorderfs/-/merge_requests/5 Bug #1093768 [disorderfs] disorderfs: consider enabling 'hard_remove' FUSE option by default Set Bug forwarded-to-address to 'https://salsa.debian.org/reproducible-builds/disorderfs/-/merge_requests/5'. -- 1093768: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093768 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From stokito at gmail.com Wed Jan 22 15:35:10 2025 From: stokito at gmail.com (Sergey Ponomarev) Date: Wed, 22 Jan 2025 17:35:10 +0200 Subject: Promote the default reproducible build date In-Reply-To: References: Message-ID: ok, sorry, I saw that many people from the repo builds are intersecting with Maven people in discussions so I expected that everyone in context. Maven, following the Gradle now use the static date 1970-01-01 for build timestamp https://github.com/apache/maven/pull/1813 The 1970-01-01 may be threatened as "zero" in some systems. The PkZip format epoch starts on 1980-01-01 and the date also maye have a special meaning. So that the 1980-02-01 was chosen as a safe and easy to remember. The SOURCE_DATE_EPOCH is most of the time unnecessary and makes it even more complicated to compare differences between different versions. We may need to have mtime updated for web assets to avoid caching problems by Last-Modified but in most other cases this is not the case. Using the static reproducible build timestamp also simplifies the build process and reduces dependency on the VCS. So even if the repo build team does not endorse use of the 1980-02-01 it is still worth mentioning it on the Timestamps page. What about making reproducible artifacts in other tools, like tar, zip, zstd? Is there any place tracking adoption of the reproducible build by them? From amospat928 at gmail.com Wed Jan 22 23:43:33 2025 From: amospat928 at gmail.com (Pat Amos) Date: Thu, 23 Jan 2025 00:43:33 +0100 Subject: Request for Product Catalogue and MOQ Message-ID: Hello sir/ma I hope this email finds you well. It?s great to connect with you again! We are very interested in importing your products to Argentina and would like to place an order from your company as soon as possible. To move forward, could you please send us your product catalogue along with the MOQ? Please, kindly reply only to: amospat928 at gmail.com Your prompt response will help us expedite the process, so we can start this exciting partnership. Thanks & Regards? ******* ------------------------------ *Mrs * *Pat Amos* *Sales.Manager-||: Supply Chain* Email: *amospat928 at gmail.com * ****Peenya Industrial Group** is one of the biggest **INTERMEDIATE* * suppliers.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftpmaster at ftp-master.debian.org Fri Jan 24 12:11:23 2025 From: ftpmaster at ftp-master.debian.org (Debian FTP Masters) Date: Fri, 24 Jan 2025 12:11:23 +0000 Subject: Processing of diffoscope_286_amd64.changes Message-ID: diffoscope_286_amd64.changes uploaded successfully to localhost along with the files: diffoscope_286.dsc diffoscope_286.tar.xz diffoscope_286_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org) From ftpmaster at ftp-master.debian.org Fri Jan 24 12:34:46 2025 From: ftpmaster at ftp-master.debian.org (Debian FTP Masters) Date: Fri, 24 Jan 2025 12:34:46 +0000 Subject: diffoscope_286_amd64.changes ACCEPTED into unstable Message-ID: Thank you for your contribution to Debian. Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Fri, 24 Jan 2025 12:07:52 +0000 Source: diffoscope Built-For-Profiles: nocheck Architecture: source Version: 286 Distribution: unstable Urgency: medium Maintainer: Reproducible builds folks Changed-By: Chris Lamb Closes: 1065498 1093484 Changes: diffoscope (286) unstable; urgency=medium . [ Chris Lamb ] * Bug fixes: - When passing files on the command line, don't call specialize(..) before we've checked that the files are identical. In the worst case, this was resulting in spinning up binwalk and extracting two entire filesystem images merely to confirm that they were indeed filesystem images.. before simply concluding that they were identical anyway. - Do not exit with a traceback if paths are inaccessible, either directly, via symbolic links or within a directory. (Closes: #1065498) - Correctly identify changes to only the line-endings of files; don't mark them as "Ordering differences only". - Use the "surrogateescape" mechanism of str.{decode,encode} to avoid a UnicodeDecodeError and crash when decoding zipinfo output that is not valid UTF-8. (Closes: #1093484) * Testsuite changes: - Don't mangle newlines when opening test fixtures; we want them untouched. - Move to assert_diff in test_text.py. * Misc: - Remove unnecessary return value from check_for_ordering_differences in the Difference class. - Drop an unused function in iso9600.py - Inline a call/check of Config().force_details; no need for an additional variable. Checksums-Sha1: c2219796e7beae46ed013ae8084c3a009e098b71 5043 diffoscope_286.dsc 005fff7c68e270889a4899973ca8bf399cacec7f 2463128 diffoscope_286.tar.xz 0b813df64a72ffd81445c95cb7a3da148d60c01c 7615 diffoscope_286_amd64.buildinfo Checksums-Sha256: b38bf74cbc5ff2c044fa27bebeee8488b8e819804f30d58427f482ee5dea8637 5043 diffoscope_286.dsc 2ac2acbe9f86c11af570d39704ddc5035b48b3009bbe060a4399e68ba8c0cbf0 2463128 diffoscope_286.tar.xz 510959be08c0e1613f2d4ee9e18ddfc56e5ccc645f66293ba4083e5ce37c6c6a 7615 diffoscope_286_amd64.buildinfo Files: b0c4d7acd9b92c2515b67ee2df5f0cd5 5043 devel optional diffoscope_286.dsc 7afcf2aaee2c307f1cdf9df155fb9941 2463128 devel optional diffoscope_286.tar.xz 91a2a7542cb5e693a9ff92039ae8d885 7615 devel optional diffoscope_286_amd64.buildinfo -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEwv5L0nHBObhsUz5GHpU+J9QxHlgFAmeTgtMACgkQHpU+J9Qx HlgYoQ//eafAUm9BXpJAq4JgXPcPlsgUlQ0UzGEhzW9tTEAObFOg7BZoKjWvJkJ7 3orX9KdJfJnXEg8Q9VSz3ga5rbJ7xQJaoipRRjKHejUDIHnqgabcRv8dEx4hWCsi Ov2iXeZD4h6a9ryISYiU3moot08Sx5++XEr92rNQXKuoE8W81YcNMNP+FKmS8FI/ qW3BADwy1s4Wnr58OyzMe83k+XSz0wfbVfo+yr6pjwz8WpzOvEw6oaTD/JvTFifc tGiLkvds/JGg4jd+jLOIOdDVxPzvkqhbZBNJtE5+zaKAU3SlBF6Cmp6N0VeI9yr0 v6gbFPPsrUKO4O2OFbo7WGmKkSmldfNejF1/pA/gyCAYxpgw6AkzvzDYBhWRJpkl jC8D5vCcLx7Atb81EPQFVQcpuxi3dI1msrHEQvYfSVjoCUUyxjTAxUzVLLJT7ThD 1vLHG0ZSUpz0ccWDTbgG7Jh0yOyDiA+MNERS/KmX96nXN9Hb5cpA9jtzk5K9Q/Nz 9JcNUGUKdB7ZGRZDqBZMn00jlmMlAGJLiV5jSUi0w1R0neSxHUiL/lgN39XM4H9S Vwv9A2wF9duTtSfd16+uS034veJDboAacwbZwigXVdzfkPbMk6FKiEUN3HrLrtaf sILBK6QYF6Xhj40Pc3YsjqbRleKdN/pJvzs8U3cIi6wXswVFoRY= =LlZI -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From owner at bugs.debian.org Fri Jan 24 12:39:04 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Fri, 24 Jan 2025 12:39:04 +0000 Subject: Bug#1093484: marked as done (diffoscope: crash when processing IDEA CE distributions) References: <173727506366.3700439.10565721987476525373.reportbug@inappropriate> Message-ID: Your message dated Fri, 24 Jan 2025 12:34:46 +0000 with message-id and subject line Bug#1093484: fixed in diffoscope 286 has caused the Debian Bug report #1093484, regarding diffoscope: crash when processing IDEA CE distributions to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner at bugs.debian.org immediately.) -- 1093484: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093484 Debian Bug Tracking System Contact owner at bugs.debian.org with problems -------------- next part -------------- An embedded message was scrubbed... From: =?utf-8?q?Julien_Plissonneau_Duqu=C3=A8ne?= Subject: diffoscope: crash when processing IDEA CE distributions Date: Sun, 19 Jan 2025 08:24:23 +0000 Size: 18169 URL: -------------- next part -------------- An embedded message was scrubbed... From: Debian FTP Masters Subject: Bug#1093484: fixed in diffoscope 286 Date: Fri, 24 Jan 2025 12:34:46 +0000 Size: 8019 URL: From owner at bugs.debian.org Fri Jan 24 12:39:04 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Fri, 24 Jan 2025 12:39:04 +0000 Subject: Bug#1065498: marked as done (diffoscope: Crash on files without read permission) References: Message-ID: Your message dated Fri, 24 Jan 2025 12:34:46 +0000 with message-id and subject line Bug#1065498: fixed in diffoscope 286 has caused the Debian Bug report #1065498, regarding diffoscope: Crash on files without read permission to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner at bugs.debian.org immediately.) -- 1065498: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065498 Debian Bug Tracking System Contact owner at bugs.debian.org with problems -------------- next part -------------- An embedded message was scrubbed... From: rclobus at rclobus.nl Subject: diffoscope: Crash on files without read permission Date: Tue, 05 Mar 2024 14:13:37 +0100 Size: 7708 URL: -------------- next part -------------- An embedded message was scrubbed... From: Debian FTP Masters Subject: Bug#1065498: fixed in diffoscope 286 Date: Fri, 24 Jan 2025 12:34:46 +0000 Size: 7974 URL: