Bug#1069329: fixed in diffoscope 266
Hi Paul, > Hmm, I still get a hex diff with the test case I posted in the bug: Ah, I foolishly didn't check back with the original test case. The root cause here, if I can call it that, is that we were calling "xz --list --verbose" and not specifying a second "--verbose". This has now been remedied in Git, which will most likely be released on Friday 17th May. I've used your original test case as a literal test fixture, and can confirm it now shows a difference. Given the extra verbose information, I did alas make a related change so that it will not show the "--verbose --verbose" output if there are differences between the files contained within the .xz. Otherwise every single .deb package would show a very lengthy and distracting output. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1069322: diffoscope crashes when trying to compare unreproducible src:dasel build artifacts
Holger Levsen wrote: > I'm not sure how --debug output should survive, but you mean just > running diffoscope with an added --debug option? Ah, yeah. It won't survive from Jenkins' log perspective, huh? Hmm, the --debug output could perhaps to be directed straight to an on-disk file. Given that that should be flushed after every line, that should survive an OOM kill. If not, hmm, I'll have a think. Either way, apologies that I'm not more familiar with all the abstraction layers in our setup and thus which might survive an OOM. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1069322: diffoscope crashes when trying to compare unreproducible src:dasel build artifacts
Holger Levsen wrote: >> Hm, I can't seem to reproduce the crash with these files. In the first >> instance, can you paste a traceback or similar of the crash in >> question? Maybe it is fixable just from that without having to find >> and upload more files, etc. > > I don't have a traceback as the oom-kill also kills the surrounding > processes... Ah, I was hoping that the systemd slice apparatus would be able to contain any traceback, but now that I think of it, being OOM-killed is not quite the same as CPython-level crash (and thus traceback). > https://tests.reproducible-builds.org/debian/artifacts/r00t-me/trixie_i386_dasel_tmp-kqFaQ/ > is maybe working as in crashing for you? Alas, this works for me and does not crash. I suppose the next thing might be to try and run with --debug? That way, we might be able to determine which file, comparator or external tool was being run when diffoscope invoked the ire of the oom-killer. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Reproducible Builds in April 2024
applied any
ameliorating fixes.
[10] https://www.openwall.com/lists/oss-security/2024/04/08/8
[11] https://www.openwall.com/lists/oss-security/
[12] https://www.openwall.com/lists/oss-security/2024/04/20/3
§
Website updates
---
There were a number of improvements made to our website this month,
including Chris Lamb updating the archive page [13] to recommend -X and
unzipping with TZ=UTC [14] and adding Maven, Gradle, JDK and Groovy
examples to the SOURCE_DATE_EPOCH page [15] [16]. In addition Jan
Zerebecki added a new /contribute/opensuse/ [17] page [18] and
Sertonix fixed the automatic RSS feed detection [19][20].
[13] https://reproducible-builds.org/docs/archive/
[14]
https://salsa.debian.org/reproducible-builds/reproducible-website/commit/d15f76b8
[15] https://reproducible-builds.org/docs/source-date-epoch/
[16]
https://salsa.debian.org/reproducible-builds/reproducible-website/commit/bfcbb9a2
[17] https://reproducible-builds.org/contribute/opensuse/
[18]
https://salsa.debian.org/reproducible-builds/reproducible-website/commit/4901c9ae
[19]
https://salsa.debian.org/reproducible-builds/reproducible-website/commit/5f311583
[20]
https://salsa.debian.org/reproducible-builds/reproducible-website/commit/54c80767
§
"Reproducible Builds and Insights from an Independent Verifier for Arch Linux"
--
Joshua Drexel, Esther Hänggi and Iyán Méndez Veiga of the School of
Computer Science and Information Technology, Hochschule Luzern (HSLU) in
Switzerland published a paper this month entitled "Reproducible Builds
and Insights from an Independent Verifier for Arch Linux" [22]. The
paper establishes the context as follows:
> Supply chain attacks have emerged as a prominent cybersecurity threat
> in recent years. Reproducible and bootstrappable builds have the
> potential to reduce such attacks significantly. In combination with
> independent, exhaustive and periodic source code audits, these measures
> can effectively eradicate compromises in the building process. In this
> paper we introduce both concepts, we analyze the achievements over the
> last ten years and explain the remaining challenges.
What is more, the paper aims to:
> … contribute to the reproducible builds effort by setting up a
> rebuilder and verifier instance to test the reproducibility of Arch
> Linux packages. Using the results from this instance, we uncover an
> unnoticed and security-relevant packaging issue affecting 16 packages
> related to Certbot […].
A PDF [23] of the paper is available.
[22] https://doi.org/10.18420/sicherheit2024_016
[23]
https://dl.gi.de/server/api/core/bitstreams/f8685808-2e51-4a53-acc0-2b45fa240e3b/content
§
libntlm now releasing 'minimal source-only tarballs'
Simon Josefsson [25] wrote on his blog this month that, going forward,
the libntlm [26] project will now be releasing what they call "minimal
source-only tarballs [27]":
> The XZUtils incident [28] illustrate that tarballs with files that are
> not included in the git archive offer an opportunity to disguise
> malicious backdoors. [The] risk of hiding malware is not the only
> motivation to publish signed minimal source-only tarballs. With pre-
> generated content in tarballs, there is a risk that GNU/Linux
> distributions [ship] generated files coming from the tarball into the
> binary *.deb or *.rpm package file. Typically the person packaging the
> upstream project never realized that some installed artifacts was
> not re-built[.]
Simon's post [29] goes into further details how this was achieved, and
describes some potential caveats and counters some expected responses as
well. A shorter version can be found in the announcement for the 1.8
release of libntlm [30].
[25] https://blog.josefsson.org/
[26] https://gitlab.com/gsasl/libntlm/
[27]
https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/
[28] https://en.wikipedia.org/wiki/XZ_Utils_backdoor
[29]
https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/
[30] https://lists.nongnu.org/archive/html/libntlm/2024-04/msg0.html
§
Distribution work
-
In Debian this month, Helmut Grohne filed a bug [31] suggesting the
removal of dh-buildinfo, a tool to generate and distribute .buildinfo-
like files within binary packages. Note that this is distinct from the
.buildinfo generation performed by dpkg-genbuildinfo. By contrast, the
entirely optional dh-buildinfo generated a debian/buildinfo file that
would be shipped within binary packages as
/usr/share/doc/package/buildinfo_$arch.gz.
In addition, 21 reviews of Debian pac
Re: Please review the draft for April's report
Chris Lamb wrote: > Please review the draft for April's Reproducible Builds report: This has now been published — thanks to all who contributed. :) If possible, please share the following link: https://reproducible-builds.org/reports/2024-04/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1788877087358476414 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1069322: diffoscope crashes when trying to compare unreproducible src:dasel build artifacts
Holger Levsen wrote: > I'm attaching the crashing artifacts now to this bug report, however minus > the orig.tar.gz files, though I suppose that the .deb files are enough to > crash diffoscope anyway... Hm, I can't seem to reproduce the crash with these files. In the first instance, can you paste a traceback or similar of the crash in question? Maybe it is fixable just from that without having to find and upload more files, etc. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for April's report
Hi all,
Please review the draft for April's Reproducible Builds report:
https://reproducible-builds.org/reports/2024-04/?draft
… or, via the Git repository itself:
https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2024-04.md
I intend to publish it no earlier than:
$ date -d 'Fri, 10 May 2024 10:00:00 +0100'
https://time.is/compare/1000_10_May_2024_in_BST
§
Please feel free and commit/push to drafts directly without the overhead of
sending patches or merge requests. You should make your changes to the
"_reports/2024-04.md" file in the "reproducible-website" repository:
$ git clone https://salsa.debian.org/reproducible-builds/reproducible-website
$ cd reproducible-website
$ sensible-editor _reports/2024-04.md
I am happy to reword and/or rework additions prior to publishing. If you
currently do not have access to the above repository, you can request access
by following the instructions at:
https://reproducible-builds.org/contribute/salsa/
Regards,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1070416: src:diffoscope: unsatisfied build dependency in testing: aapt
Paul Gevers wrote: > Dose [1] is reporting a build issue with your package, it's missing a > build dependency. Obviously your build dependencies shouldn't be > removed from testing, but unfortunately there are multiple scenarios > where that can happen nevertheless. Looks like this happened due to these RC bugs: https://bugs.debian.org/1062206 https://bugs.debian.org/1062110 https://bugs.debian.org/1062209 i.e. it wasn't that aapt was removed or barred from testing for some reason specific to aapt's code or license, etc. It is, as I understand it, not impossible that it might return to testing without further intervention on our part..? Otherwise, we can very cleanly remove this build dependency, even keeping the .arsc file support in diffoscope itself. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1068890: diffoscope: --hard-timeout option
Vagrant Cascadian wrote: > On 2024-04-16, Chris Lamb wrote: >> However, I think this first iteration of --hard-timeout time has a few >> things that would need ironing out first, and potentially make it not >> worth implementing: >> >> (1) You suggest it should start again with "--max-container-depth 3", >> but it would surely need some syntax (or another option?) to control >> that "3" (but for the second time only). > > What about going the other direction ... starting with a very small > value for max-container-depth, and incrementally increasing it, > generating a report (or at least storing sufficient data to generate > one) in between each increment, so you always get some information, but > essentially incrementally increase the resolution? > > Or would that approach just be too inefficient? This is probably a separate required best suited to another issue at this point, but I do like the idea of being able to incrementally increase the resolution over time. Depending on how it worked in practice, there should not be significant overhead in managing this if, say, the commands that could not be run "in time" would have token placeholders internally that rendered to text in the output rather than non-trivial/expensive binary diffs. On the negative side though, I think this would still require a robust way of killing long-running processes as outlined previously. But moreover it would require a HUGE reworking of how diffoscope handles containers and recurses into nested structures in its tree-like style. Indeed, thinking about it, this change would pretty much be exactly the same work needed to make diffoscope run in parallel (!) which hopefully communicates both the scope of the changes that would be needed to achieve this, and that making diffoscope run in parallel also has other benefits.Anyway, mini brain dump over. Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1068890: diffoscope: --hard-timeout option
Holger Levsen wrote: >> (1) You suggest it should start again with "--max-container-depth 3", >> but it would surely need some syntax (or another option?) to control >> that "3" (but for the second time only). > > another option, --second-pass-max-container-depth or some such > >> (2) In fact, its easy to imagine that one would want to restart with >> other restrictions as well: not just --max-container-depth. For >> instance, excluding external commands like readelf and objdump that >> you know to be slow. > > yes, that's a good idea and IMO should be automatically implied for the > 2nd pass or round or try. It's definitely a "good idea" in the sense that I can definitely see someone wanting to achieve that as an end result:) Yet… upon thinking about it a bit, I don't think it is a good idea at all for diffoscope to grow a bunch of new options or hardcoded defaults for a second run. What (1) and (2) show here is that as soon as a user would like to adjust these second pass options in any way, then the whole interface becomes very unwieldy. Not only that, but from the user's point of view it's neither flexible nor transparent as well, especially when compared to "just" running diffoscope twice with different options. There's no "magic" there, if you see what I mean. Can we implement running diffoscope twice on tests.r-b.org manually first and see how that goes? I'm not 100% against the idea of implementing this in diffoscope eventually, but it would make a lot of sense to try out the "manual" version first and gain some real-world experience first. Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1068890: diffoscope: --hard-timeout option
Holger Levsen wrote: > Anyhow, about my --hard-timeout option idea: > > my idea of "--hard-timeout $time" is that diffoscope terminates itself > after $time, no matter what *and* then re-starts itself with > "--max-container-depth 3" Just to say that I am totally on board with the idea of ensuring we get _something_ out of diffoscope on tests.reproducible-builds.org. Way better than 250 timeouts. However, I think this first iteration of --hard-timeout time has a few things that would need ironing out first, and potentially make it not worth implementing: (1) You suggest it should start again with "--max-container-depth 3", but it would surely need some syntax (or another option?) to control that "3" (but for the second time only). (2) In fact, its easy to imagine that one would want to restart with other restrictions as well: not just --max-container-depth. For instance, excluding external commands like readelf and objdump that you know to be slow. (3) The output might need some comment saying "this was re-run with restrictions as we hit a timeout". (4) My gut feel that it would not be all that great to rely on CPython to really properly clear up child processes after a certain amount of time. Although I believe the most reliable top-level description to do this kind of thing inside CPython is to start a watchdog thread that sleeps until the timeout and then tries to kill everything, but my experience of doing anything like this within Python itself is not great, and essentially always needed something at the process level outside of it for it to be reliable. A container would be even more effective, I'm sure. In other words, I think the best way of achieving the result we want is, alas, by doing it outside of diffoscope at the level of the Jenkins. As in, exactly what you describe here: > Else we could also extend the current code for tests.r-b.o/debian, > which currently > just kills diffoscope after 2h, to then run diffoscope > --max-container-depth 3 :) Is that a massive faff? :/ Best wishes, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Reproducible Builds in March 2024
unctional package managers (FPMs) and reproducible builds (R-B) are > technologies and methodologies that are conceptually very different > from the traditional software deployment model, and that have > promising properties for software supply chain security. This thesis > aims to evaluate the impact of FPMs and R-B on the security of the > software supply chain and propose improvements to the FPM model to > further improve trust in the open source supply chain. Full PDF: [15] Julien's paper poses a number of research questions on how the model of distributions such as GNU Guix [16] and NixOS [17] can "be leveraged to further improve the safety of the software supply chain", etc. [13] https://en.wikipedia.org/wiki/HAL_(open_archive [14] https://hal.science/hal-04482192 [15] https://hal.science/hal-04482192/document [16] https://guix.gnu.org/ [17] https://nixos.org/ [18] https://guix.gnu.org/ § Software and source code identification with GNU Guix [18] and reproducible builds -- In a long line of commendably detailed blog posts, Ludovic Courtès, Maxim Cournoyer, Jan Nieuwenhuizen and Simon Tournier have together published two interesting posts on the GNU Guix blog [19] this month. In early March, Ludovic Courtès, Maxim Cournoyer, Jan Nieuwenhuizen and Simon Tournier wrote about software and source code identification [20] and how that might be performed using Guix, rhetorically posing the questions: "What does it take to 'identify software'? How can we tell what software is running on a machine to determine, for example, what security vulnerabilities might affect it?" Later in the month, Ludovic Courtès wrote a solo post describing adventures on the quest for long-term reproducible deployment [21]. Ludovic's post touches on GNU Guix's aim to support "time travel", the ability to reliably (and reproducibly) revert to an earlier point in time, employing the iconic image of Harold Lloyd hanging off the clock in "Safety Last!" (1925) [22] to poetically illustrate both the slapstick nature of current modern technology and the gymnastics required to navigate hazards of our own making. [19] https://guix.gnu.org/en/blog/ [20] https://guix.gnu.org/en/blog/2024/identifying-software/ [21] https://guix.gnu.org/en/blog/2024/adventures-on-the-quest-for-long-term-reproducible-deployment/ [22] https://en.wikipedia.org/wiki/Safety_Last! § Two new Rust-based tools for post-processing determinism Zbigniew Jędrzejewski-Szmek announced "add-determinism" [23], a work-in- progress reimplementation of the Reproducible Builds project's own strip-nondeterminism [24] tool in the Rust programming language [25], intended to be used as a post-processor in RPM-based distributions such as Fedora [26] In addition, Yossi Kreinin [27] published a blog post titled "refix: fast, debuggable, reproducible builds" [28] that describes a tool that post-processes binaries in such a way that they are still debuggable with gdb [29], etc. Yossi post details the motivation and techniques behind the (fast) performance of the tool. [23] https://github.com/keszybz/add-determinism [24] https://salsa.debian.org/reproducible-builds/strip-nondeterminism [25] https://www.rust-lang.org/ [26] https://fedoraproject.org/ [27] https://yosefk.com/ [28] https://yosefk.com/blog/refix-fast-debuggable-reproducible-builds.html [29] https://sourceware.org/gdb/ § Distribution work - In Debian this month, since the testing framework no longer varies the build path [30], James Addison performed a bulk downgrade of the bug severity [31] for issues filed with a level of normal to a new level of wishlist. In addition, 28 reviews of Debian packages were added, 38 were updated and 23 were removed this month adding to ever-growing knowledge about identified issues [32]. As part of this effort, a number of issue types were updated, including Chris Lamb adding a new ocaml_include_directories toolchain issue [33] and James Addison adding a new filesystem_order_in_java_jar_manifest_mf_include_resource issue [34] and updating the random_uuid_in_notebooks_generated_by_nbsphinx to reference a relevant discussion thread [35]. [30] https://reproducible-builds.org/docs/build-path/ [31] https://lists.reproducible-builds.org/pipermail/rb-general/2024-March/003257.html [32] https://tests.reproducible-builds.org/debian/index_issues.html [33] https://salsa.debian.org/reproducible-builds/reproducible-notes/commit/a052c30f [34] https://salsa.debian.org/reproducible-builds/reproducible-notes/commit/cc94c935 [35] https://salsa.debian.org/reproducible-builds/reproducible-notes/commit/55497f89 In addition, Roland Clobus posted his 24
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
Fay Stegerman wrote: > https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/140 Nice; I have applied this locally in Git and will release shortly. :) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Please review the draft for March's report
Chris Lamb wrote: > Please review the draft for March's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2024-03/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1778496263027093713 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
tags 1068705 + pending thanks Fay Stegerman wrote: > The attached patch avoids the crash in this case, FWIW. […] Applied in Git with attribution taken from your email. > I would still recommend catching the error for other cases. Fixed as well. And it adds a nice comment displaying the issue. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
Fay Stegerman wrote:
> Salsa is probably better for figuring out what to do next, but I get
> these mails too :)
Oh, hey! o/
> unzip does seem to extract all the files, though it errors out. Not sure what
> diffoscope should do here. This is definitely a broken ZIP file.
First; great debugging there, thank you. :)
Okay, separate from your suggestion that a bug should be filed against
libscout with its broken zip file, I think that diffoscope should not
traceback and crash on this particular input. We do this elsewhere with
(most) invalid inputs and it makes a lot of sense here as well.
I'll modify diffoscope tomorrow morning to catch the specific
exception being thrown by Python's builtin zipfile module and add a
suitable message as a user-visible 'comment' — again, something we have
plenty of prior art for elsewhere in the codebase. Thanks again.
Best wishes,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
Holger Levsen wrote: > when building libscout 2.3.2-3 on current unstable, the result is also > unreproducible, but diffoscope crashes when analysing the diff. I think this is somewhat related to: https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/362 … which was said to be fixed by Fay in cc3b077f6ef97b4e20036e9823926fe633c7d4d0 that released as diffoscope version 263 on 2024-04-05. However, I can see that the current output of libscout/amd64 on tests.reproducible-builds.org is failing with this very version: Tue Apr 9 12:14:14 UTC 2024 I: diffoscope 263 will be used to compare the two builds: From https://gist.github.com/lamby/e5db96d4d61612485a469b826590192e/raw (saved output for posterity) Will loop Fay in via Salsa presently. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for March's report
Hi all,
Sorry for the delay in getting this out — it was, quite genuinely, a
bumper amount of things that needed condensing, rewriting and
generally getting into readable shape. Anyway, if folks would be so
kind as to review the draft for last months report here:
https://reproducible-builds.org/reports/2024-03/?draft
… or, via the Git repository itself:
https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2024-03.md
I intend to publish it no earlier than:
$ date -d 'Thu, 11 Apr 2024 17:30:00 +0100'
https://time.is/compare/1730_11_Apr_2024_in_BST
§
As ever, please feel free and commit/push to drafts directly without the
overhead of
sending patches or merge requests. You should make your changes to the
"_reports/2024-03.md" file in the "reproducible-website" repository:
$ git clone https://salsa.debian.org/reproducible-builds/reproducible-website
$ cd reproducible-website
$ sensible-editor _reports/2024-03.md
I am happy to reword and/or rework additions prior to publishing. If you
currently do not have access to the above repository, you can request access
by following the instructions at:
https://reproducible-builds.org/contribute/salsa/
Regards,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1066991: easy way to crash diffoscope
tags 1066991 + pending thanks Fixed in Git, pending upload: https://salsa.debian.org/reproducible-builds/diffoscope/commit/1dc8c79e8307f5772a434ecba549bc923fa28582 diffoscope/comparators/rdata.py | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Reproducible Builds in February 2024
challenging and costly to perform manually. > (HAL Portal [18], full PDF [19]) [16] https://inria.hal.science/hal-04441579v2 [17] https://www.inria.fr/en/inria-centre-rennes-university [18] https://inria.hal.science/hal-04441579v2 [19] https://inria.hal.science/hal-04441579/file/msr24.pdf § Mailing list highlights --- From our mailing list [20] this month: * User "cen" posted a query asking "How to verify a package by rebuilding it locally on Debian [21]" which received a followup from Vagrant Cascadian [22]. * James Addison asked "Two questions about build-path reproducibility in Debian [23]" regarding the differences in the testing performed by Debian's GitLab continuous integration (CI) pipeline [24] and the Debian-specific testing performed by the Reproducible Builds project itself [25], and followed this with a separate but related question regarding misconfigured *reprotest* [26] configurations. [20] https://lists.reproducible-builds.org/listinfo/rb-general/ [21] https://lists.reproducible-builds.org/pipermail/rb-general/2024-February/003238.html [22] https://lists.reproducible-builds.org/pipermail/rb-general/2024-February/003240.html [23] https://lists.reproducible-builds.org/pipermail/rb-general/2024-February/003246.html [24] https://salsa.debian.org/salsa-ci-team/pipeline [25] https://tests.reproducible-builds.org/debian/reproducible.html [26] https://salsa.debian.org/reproducible-builds/reprotest § Distribution work - In Debian this month, 5 reviews of Debian packages were added, 22 were updated and 8 were removed this month adding to Debian's knowledge about identified issues [27]. A number of issue types were updated as well. In addition, Roland Clobus posted his 23rd update of the status of reproducible ISO images [28] on our mailing list. In particular, Roland helpfully summarised that "all major desktops build reproducibly with "bullseye", "bookworm", "trixie" and "sid" provided they are built for a second time within the same DAK run (i.e. [within] 6 hours)" and that there will likely be further work at a MiniDebCamp in Hamburg [29]. Furthermore, Roland also responded in- depth [30] to a query about a previous report [31]. [27] https://tests.reproducible-builds.org/debian/index_issues.html [28] https://lists.reproducible-builds.org/pipermail/rb-general/2024-February/003251.html [29] https://wiki.debian.org/DebianEvents/de/2024/MiniDebCampHamburg [30] https://lists.reproducible-builds.org/pipermail/rb-general/2024-February/003233.html [31] https://lists.reproducible-builds.org/pipermail/rb-general/2024-January/003217.html Fedora [32] developer Zbigniew Jędrzejewski-Szmek [33] announced a work- in-progress script called fedora-repro-build [34] that attempts to reproduce an existing package within a koji [35] build environment. Although the projects' README file [36] lists a number of "fields will always or almost always vary" and there is a non-zero list of other known issues [37], this is an excellent first step towards full Fedora reproducibility. [32] https://fedoraproject.org/ [33] https://github.com/keszybz [34] https://github.com/keszybz/fedora-repro-build [35] https://pagure.io/koji/ [36] https://github.com/keszybz/fedora-repro-build#readme [37] https://pagure.io/fedora-reproducible-builds/project/issues?tags=irreproducibility Jelle van der Waa introduced a new linter rule [38] for Arch Linux [39] packages in order to detect cache files leftover by the Sphinx documentation generator [40] which are unreproducible by nature and should not be packaged. At the time of writing, 7 packages in the Arch repository are affected by this. [38] https://gitlab.archlinux.org/pacman/namcap/-/merge_requests/64 [39] https://archlinux.org/ [40] https://www.sphinx-doc.org/en/master/ Elsewhere, Bernhard M. Wiedemann posted another monthly update [41] for his work elsewhere in openSUSE. [41] https://lists.opensuse.org/archives/list/fact...@lists.opensuse.org/thread/I66U56F5R3TR4ZTLYGPSGWINNOLZ7XP4/ § diffoscope -- diffoscope [43] is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made a number of changes such as uploading versions 256, 257 and 258 to Debian and made the following additional changes: * Use a deterministic name instead of trusting gpg's --use-embedded- filenames. Many thanks to Daniel Kahn Gillmor (dkg) for reporting this issue and providing feedback. [44][45] * Don't error-out with a traceback if we encounter struct.unpack- related errors when parsing Python .pyc files. (#1064973). [47] * Don't try and compare rdb_expected_diff on non-GNU systems as %p formatting can vary, especially with respect to MacOS.
Re: Please review the draft for February's report
Chris Lamb wrote: > Please review the draft for February's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2024-02/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1766508612887744550 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for February's report
Hi all, Please review the draft for February's Reproducible Builds report: https://reproducible-builds.org/reports/2024-02/?draft ⦠or, via the Git repository itself: https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2024-02.md I intend to publish it no earlier than: $ date -d 'Sat, 09 Mar 2024 14:15:00 +' https://time.is/compare/1415_09_Mar_2024_in_GMT § Please feel free and commit/push to drafts directly without the overhead of sending patches or merge requests. You should make your changes to the "_reports/2024-02.md" file in the "reproducible-website" repository: $ git clone https://salsa.debian.org/reproducible-builds/reproducible-website $ cd reproducible-website $ sensible-editor _reports/2024-02.md I am happy to reword and/or rework additions prior to publishing. If you currently do not have access to the above repository, you can request access by following the instructions at: https://reproducible-builds.org/contribute/salsa/ Regards, -- o ⬠⬠Chris Lamb o o reproducible-builds.org ð ⬠⬠o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1064973: diffoscope fails with struct.error: unpack requires a buffer of 4 bytes
tags 1064973 + pending thanks Ah, I see the issue now; its to do with empty pyc files. Now properly fixed in Git, pending upload: https://salsa.debian.org/reproducible-builds/diffoscope/commit/c885c24ad4807a0ec20c0cca9572b395812c85d9 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1064973: diffoscope fails with struct.error: unpack requires a buffer of 4 bytes
Zbigniew Jędrzejewski-Szmek wrote:
> File
> "/usr/lib/python3.12/site-packages/diffoscope/comparators/python.py",
> line 74, in parse_pyc
> modtime = time.asctime(time.gmtime(struct.unpack("
> struct.error: unpack requires a buffer of 4 bytes
I'm trying to track this down further so I can fix the underlying
problem. However, I'm having difficulty reproducing locally. In the
first instance, it would be helpful to know exactly which file within
the .rpm is the one (previously) causing the traceback.
Can you run diffoscope --debug so we can see which .pyc file is the
offending one? I think it is "environment.cpython-312.pyc", but it
would be great to get confirmation. Also knowing your exact Python
version (using python3 --version) would be useful withal.
Best wishes,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1064973: diffoscope fails with struct.error: unpack requires a buffer of 4 bytes
tags 1064973 + pending thanks The traceback/error is fixed in Git, pending upload: https://salsa.debian.org/reproducible-builds/diffoscope/commit/466523ac6fbd1437635f8393fb93c37ff59341b3 We should still fix it so the .pyc is actually parsed though. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Reproducible builds in January 2024
o ⬋ ⬊ January 2024 in Reproducible Builds o o ⬊ ⬋ https://reproducible-builds.org/reports/2024-01/ o Welcome to the January 2024 report from the Reproducible Builds project. In these reports we outline the most important things that we have been up to over the past month. If you are interested in contributing to the project, please visit our 'Contribute' [1] page on our website. [1] https://reproducible-builds.org/contribute/ § "How we executed a critical supply chain attack on PyTorch" --- John Stawinski [2] and Adnan Khan [3] published a lengthy blog post detailing how they executed a supply-chain attack [4] against PyTorch [5], a popular machine learning platform "used by titans like Google, Meta, Boeing, and Lockheed Martin": > Our exploit path resulted in the ability to upload malicious PyTorch > releases to GitHub, upload releases to [Amazon Web Services], > potentially add code to the main repository branch, backdoor PyTorch > dependencies – the list goes on. In short, it was bad. Quite bad. The attack pivoted on PyTorch's use of "self-hosted runners [7]" as well as submitting a pull request to address a trivial typo in the project's README file to gain access to repository secrets and API keys that could subsequently be used for malicious purposes. [2] https://johnstawinski.com/ [3] https://adnanthekhan.com/ [4] https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/ [5] https://pytorch.org/ [7] https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners § New Arch Linux forensic filesystem tool --- On our mailing list [8] this month, long-time Reproducible Builds developer kpcyrd announced a new tool [9] designed to forensically analyse Arch Linux [10] filesystem images. Called archlinux-userland-fs-cmp [11], the tool is "supposed to be used from a rescue image (any Linux) with an Arch install mounted to, [for example], /mnt." Crucially, however, "at no point is any file from the mounted filesystem eval'd or otherwise executed. Parsers are written in a memory safe language." More information about the tool can be found on their announcement message [12], as well as on the tool's homepage [13]. A GIF of the tool in action [14] is also available. [8] https://lists.reproducible-builds.org/pipermail/rb-general/ [9] https://lists.reproducible-builds.org/pipermail/rb-general/2024-January/003232.html [10] https://archlinux.org/ [11] https://github.com/kpcyrd/archlinux-userland-fs-cmp [12] https://lists.reproducible-builds.org/pipermail/rb-general/2024-January/003232.html [13] https://github.com/kpcyrd/archlinux-userland-fs-cmp [14] https://asciinema.org/a/MFefYEdvU2O5LlIzseQnyBky5 § Issues with our SOURCE_DATE_EPOCH code? --- Chris Lamb started a thread on our mailing list [15] summarising some potential problems with the source code snippet the Reproducible Builds project has been using to parse the SOURCE_DATE_EPOCH [16] environment variable: > I'm not 100% sure who originally wrote this code, but it was probably > sometime in the ~2015 era, and it must be in a huge number of codebases > by now. > > Anyway, Alejandro Colomar was working on the shadow security tool and > pinged me regarding some potential issues with the code. You can see > this conversation here: [17]. Chris ended his message with a request that those with intimate or low- level knowledge of time_t, C types, overflows and the various parsing libraries in the C standard library (etc.) contribute with further info. [15] https://lists.reproducible-builds.org/pipermail/rb-general/2024-January/003225.html [16] https://reproducible-builds.org/docs/source-date-epoch/ [17] https://github.com/shadow-maint/shadow/commit/cb610d54b47ea2fc3da5a1b7c5a71274ada91371#r136407772 § Distribution updates In Debian this month, Roland Clobus posted another detailed update of the status of reproducible ISO images [18] on our mailing list. In particular, Roland helpfully summarised that "all major desktops build reproducibly with bullseye, bookworm, trixie and sid provided they are built for a second time within the same DAK run (i.e. [within] 6 hours)". Additionally 7 of the 8 bookworm images from the official download link [19] build reproducibly at any later time. In addition to this, three reviews of Debian packages were added, 1
Re: Please review the draft for January's report
Chris Lamb wrote: > Please review the draft for January's Reproducible Builds report: This has now been published — thanks to all who contributed. We didn't know what to do with the FOSDEM stuff (technically February, not January so I will do a separate post tomorrow). Anyway, please share the following link: https://reproducible-builds.org/reports/2024-01/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1755356173442965599 Best wishes, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for January's report
Hey folks,
Please glance over the draft for January's Reproducible Builds report:
https://reproducible-builds.org/reports/2024-01/?draft
… which you can also do via the Git repository itself:
https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2024-01.md
I intend to publish it no earlier than:
$ date -d 'Wed, 07 Feb 2024 14:15:00 -0800'
https://time.is/compare/1415_07_Feb_2024_in_PST
§
Please feel free and commit/push to drafts directly without the overhead of
sending patches or merge requests. You should make your changes to the
"_reports/2024-01.md" file in the "reproducible-website" repository:
$ git clone https://salsa.debian.org/reproducible-builds/reproducible-website
$ cd reproducible-website
$ vi _reports/2024-01.md
I am happy to reword and/or rework additions prior to publishing. If you
currently do not have access to the above repository, you can request access
by following the instructions at:
https://reproducible-builds.org/contribute/salsa/
Best wishes,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Reproducible builds in December 2023
o ⬋ ⬊ December 2023 in Reproducible Builds o o ⬊ ⬋ https://reproducible-builds.org/reports/2023-12/ o Welcome to the December 2023 report from the Reproducible Builds [0] project! In these reports we outline the most important things that we have been up to over the past month. As a rather rapid recap, whilst anyone may inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries (more info: [1]). [0] https://reproducible-builds.org [1] https://reproducible-builds.org/#why-does-it-matter § "Reproducible Builds: Increasing the Integrity of Software Supply Chains" awarded IEEE Software "Best Paper" award - In February 2022, we announced in these reports [2] that a paper written by Chris Lamb [3] and Stefano Zacchiroli [4] was now available in the March/April 2022 issue of IEEE Software [5]. Titled "Reproducible Builds: Increasing the Integrity of Software Supply Chains" [6] (PDF [7]). This month, however, IEEE Software [8] announced that this paper has won their Best Paper award [9] for 2022. [2] https://reproducible-builds.org/reports/2023-02/ [3] https://chris-lamb.co.uk [4] https://upsilon.cc/~zack/ [5] https://ieeexplore.ieee.org/abstract/document/9403390 [6] https://arxiv.org/abs/2104.06020 [7] https://arxiv.org/pdf/2104.06020 [8] https://www.computer.org/csdl/magazine/so [9] https://twitter.com/ieeesoftware/status/1736684911690436868 § Reproducibility to affect package migration policy in Debian In a post summarising the activities of the Debian Release Team [10] at a recent in-person Debian event in Cambridge, UK [11], Paul Gevers announced a change to the way packages are "migrated" into the staging area for the next stable Debian release based on its reproducibility status: > The folks from the Reproducibility Project have come a long way since they started working on it 10 years ago, and we believe it's time for the next step in Debian. Several weeks ago, we enabled a migration policy in our migration software that checks for regression in reproducibility. At this moment, that is presented as just for info, but we intend to change that to delays in the not so distant future. We eventually want all packages to be reproducible. To stimulate maintainers to make their packages reproducible now, we'll soon start to apply a bounty [speedup] for reproducible builds, like we've done with passing autopkgtests [12] for years. We'll reduce the bounty for successful autopkgtests at that moment in time. [10] https://wiki.debian.org/Teams/ReleaseTeam [11] https://wiki.debian.org/DebianEvents/gb/2023/MiniDebConfCambridge [12] https://people.debian.org/~eriberto/README.package-tests.html § Speranza: "Usable, privacy-friendly software signing" - Kelsey Merrill, Karen Sollins, Santiago Torres-Arias and Zachary Newman have developed a new system called Speranza, which is aimed at reassuring software consumers that the product they are getting has not been tampered with and is coming directly from a source they trust. A write-up on TechXplore.com [13] goes into some more details: > "What we have done," explains Sollins, "is to develop, prove correct, and demonstrate the viability of an approach that allows the [software] maintainers to remain anonymous." Preserving anonymity is obviously important, given that almost everyone—software developers included—value their confidentiality. This new approach, Sollins adds, "simultaneously allows [software] users to have confidence that the maintainers are, in fact, legitimate maintainers and, furthermore, that the code being downloaded is, in fact, the correct code of that maintainer." [14] The corresponding paper [15] is published on the arXiv [16] preprint server in various formats, and the announcement has also been covered in MIT News [17]. [13] https://techxplore.com/news/2023-12-boosting-faith-authenticity-source-software.html [14] https://techxplore.com/news/2023-12-boosting-faith-authenticity-source-software.html [15] https://arxiv.org/abs/2305.06463 [16] https://arxiv.org/ [17] https://news.mit.edu/2023/speranza-boosting-faith-authenticity-open-source-software-1211 § Nondeterministic Git bundles Paul Baecher [18] published an interesting blog post on "Reproducible git bundles" [19]. For those who are not familiar with them,
Re: Please review the draft for December's report
Chris Lamb wrote: > Please review the draft for December's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2023-12/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1745532388199764442 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for December's report
Hi all,
Please review the draft for December's Reproducible Builds report:
https://reproducible-builds.org/reports/2023-12/?draft
… or, via the Git repository itself:
https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2023-12.md
I intend to publish it no earlier than:
$ date -d 'Thu, 11 Jan 2024 19:00:00 +'
https://time.is/compare/1900_11_Jan_2024_in_GMT
§
Please feel free and commit/push to drafts directly without the overhead of
sending patches or merge requests. You should make your changes to the
"_reports/2023-12.md" file in the "reproducible-website" repository:
$ git clone https://salsa.debian.org/reproducible-builds/reproducible-website
$ cd reproducible-website
$ sensible-editor _reports/2023-12.md
I am happy to reword and/or rework additions prior to publishing. If you
currently do not have access to the above repository, you can request access
by following the instructions at:
https://reproducible-builds.org/contribute/salsa/
Regards,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Reproducible builds in November 2023
ing language have recently released version 10.5.0, which introduces the inclusion of a composer.lock file, ensuring total reproducibility of the shipped binary file. Further details and the discussion that went into their particular implementation can be found on the associated GitHub pull request [39]. In addition, the presentation "Leveraging Nix in the PHP ecosystem" [40] has been given in late October at the PHP International Conference in Munichby Pol Dellaiera [41]. While the video replay is not yet available, the (reproducible) presentation slides and speaker notes [42] are available. [38] https://phpunit.de/ [39] https://github.com/sebastianbergmann/phpunit/pull/5576 [40] https://phpconference.com/web-development/leveraging-nix-php-ecosystem/ [41] https://github.com/drupol [42] https://github.com/drupol/ipc2023/releases/tag/v23-79efbb4c24ab0d42c73906d16233a79d9659c5ca §§§ ## diffoscope changes diffoscope [43] is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made a number of changes, including: * Improving DOS/MBR extraction by adding support for 7z. [44] * Adding a missing RequiredToolNotFound import. [45] * As a UI/UX improvement, try and avoid printing an extended traceback if diffoscope runs out of memory. [46] * Mark diffoscope as 'stable' on PyPI.org [47]. [48] * Uploading version 252 to Debian unstable. [49] [43] https://diffoscope.org [44] https://salsa.debian.org/reproducible-builds/diffoscope/commit/59b86c1f [45] https://salsa.debian.org/reproducible-builds/diffoscope/commit/64ed5f38 [46] https://salsa.debian.org/reproducible-builds/diffoscope/commit/bb887ddb [47] https://pypi.org/ [48] https://salsa.debian.org/reproducible-builds/diffoscope/commit/e5e8d51e [49] https://tracker.debian.org/news/1479028/accepted-diffoscope-252-source-into-unstable/ §§§ ## Website updates A huge number of notes [50] were added to our website that were taken at our recent Reproducible Builds Summit [51] held between October 31st and November 2nd in Hamburg, Germany. In particular, a big thanks to Arnout Engelen, Bernhard M. Wiedemann, Daan De Meyer, Evangelos Ribeiro Tzaras, Holger Levsen and Orhun Parmaksız. In addition to this, a number of other changes were made, including: * Chris Lamb migrated the website's homepage [52] to a "hero" image [53] [54], improved the documentation related to SOURCE_DATE_EPOCH and CMake [55] [56], added iomart [57] (neé Bytemark) and DigitalOcean [58] to our sponsors page [59] [60] and dropped an unnecessary link on some horizontal navigation buttons [61]. * Holger Levsen also made a large number of notes pages [62] from our 2022 summit in Venice [63] [64], migrated the website's syntax highlighter from Pygments to Rouge [65][66], fixed some grammar on our donate page [67][68][69][70] and did a lot of updates to the Hamburg Summit's general information page [71][72]. [50] https://reproducible-builds.org/events/hamburg2023/agenda/ [51] https://reproducible-builds.org/events/hamburg2023/ [52] https://reproducible-builds.org/ [53] https://www.optimizely.com/optimization-glossary/hero-image/ [54] https://salsa.debian.org/reproducible-builds/reproducible-website/commit/2f50ba8a [55] https://reproducible-builds.org/docs/source-date-epoch/#cmake [56] https://salsa.debian.org/reproducible-builds/reproducible-website/commit/ee0d0e19 [57] https://www.iomart.com/ [58] https://www.digitalocean.com/ [59] https://reproducible-builds.org/who/sponsors/ [60] https://salsa.debian.org/reproducible-builds/reproducible-website/commit/16b73a33 [61] https://salsa.debian.org/reproducible-builds/reproducible-website/commit/25cd328b [62] https://reproducible-builds.org/events/venice2022/agenda/ [63] https://reproducible-builds.org/events/venice2022/ [64] https://salsa.debian.org/reproducible-builds/reproducible-website/commit/65072a36 [65] https://rouge.jneen.net/ [66] https://salsa.debian.org/reproducible-builds/reproducible-website/commit/5d46ea5d [67] https://reproducible-builds.org/donate/ [68] https://salsa.debian.org/reproducible-builds/reproducible-website/commit/0343dfea [69] https://salsa.debian.org/reproducible-builds/reproducible-website/commit/24bf9105 [70] https://salsa.debian.org/reproducible-builds/reproducible-website/commit/31b26b15 [71] https://salsa.debian.org/reproducible-builds/reproducible-website/commit/c8a86c6b [72] https://salsa.debian.org/reproducible-builds/reproducible-website/commit/66691658 §§§ ## Upstream patches The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including: * Bernhard M. Wiedemann:
Re: Please review the draft for November's report
Chris Lamb wrote: > Please review the draft for November's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2023-11/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1732416478958506188 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for November's report
Hi folks,
Me again. Please review the draft for November's Reproducible Builds
report:
https://reproducible-builds.org/reports/2023-11/?draft
… or you can do this via the Git repository directly:
https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2023-11.md
I intend to publish it no earlier than:
$ date -d 'Wed, 06 Dec 2023 13:15:00 +'
https://time.is/compare/1315_06_Dec_2023_in_GMT
§
Please feel free and commit/push to drafts directly without the overhead of
sending patches or merge requests. You should make your changes to the
"_reports/2023-11.md" file in the "reproducible-website" repository:
$ git clone https://salsa.debian.org/reproducible-builds/reproducible-website
$ cd reproducible-website
$ sensible-editor _reports/2023-11.md
I am happy to reword and/or rework additions prior to publishing. If you
currently do not have access to the above repository, you can request access
by following the instructions at:
https://reproducible-builds.org/contribute/salsa/
Best wishes,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: python-ansible-pygments: please make the build reproducible
Stuart Prescott wrote: > I think there's a subtle bug about altering `dirs` while > inside a loop from `os.walk`: I'm quite impressed that you managed to hunt this down — that's very nice work. :) > Which item is not processed in the next iteration by dh_python3 now > depends on the order in which `os.walk` lists the directories. That is > presumably dependent on all manner of things (filesystem? collation? > luck?). It will be dependent entirely on the filesystem being used because `os.walk` merely passes on the underlying filesystem ordering. (The same is true for GNU find as you later query.) Entirely anecdotally, ext4 will be "more orderful", whilst btrfs, possibly due to the way it rebalances its tree data structures, tends to be less so. I raise it only because it can help explain why different folks will get different results locally despite using the same building tools. Building under tmpfs will have different properties as well. Anyway, thank you again. Once this is addressed in dh-python (even as a proposed patch), I'll go through the last few months of bugs that I've filed and see whether they can be closed. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: diffoscope timing out.
Holger Levsen wrote:
> I think there is definitly an UI bug in diffoscope here. If/when diffoscope
> runs out of memory, it should state that clearly and not throw 42 lines of
> traceback at the user.
Good idea. I've added that here:
https://salsa.debian.org/reproducible-builds/diffoscope/commit/bb887ddb6e5763b15d4ed9bb448166901dc7253f
However:
> Note that because of the underlying memory management architecture
> (C’s malloc() function), the interpreter may not always be able to
> completely recover from this situation; it nevertheless raises an
> exception so that a stack traceback can be printed, in case a
> run-away program was the cause.
>
> — https://docs.python.org/2/library/exceptions.html#exceptions.MemoryError
... so this may not work in all situations.
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: diffoscope timing out.
Holger Levsen wrote: > https://jenkins.debian.net/job/reproducible_netbsd/1029/console > contains this, which IMO should not happen and is an issue in > diffoscope: > > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 767, > in main > sys.exit(run_diffoscope(parsed_args)) > ^^^ […] > File "/usr/lib/python3.11/subprocess.py", line 2128, in _communicate > data = os.read(key.fd, 32768) >^^ > MemoryError Yes, diffoscope is running out of memory and this may indeed be a bug in diffoscope. However, how much RAM is diffoscope allowed (or can) use? Best wishes, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: python-ansible-pygments: please make the build reproducible
[[ looping reproducible-bui...@lists.alioth.debian.org in on this issue ]] Stuart Prescott wrote: > Is there something about the r-b setup that would cause these > directories to be created and appear in the package? Hm, you know, I think there must be. In fact, connecting a few dots in my head, that now makes three recent reproducibility bugs that the buildds are not, if you can excuse the expression, reproducing: 1. https://bugs.debian.org/1055919 (this bug) 2. https://bugs.debian.org/1053353 3. https://bugs.debian.org/1000401 I would be more than willing to conclude that this is an issue in tests.reproducible-builds.org setup. However, I am actually seeing these test files when I build locally as well — and my patch consequently fixes the "problem". Moreover, I am not using the same setup as tests.reproducible-builds.org at all. (Can you confirm whether you see them when building locally?) I won't file any more until this has been more generally resolved. Hopefully I haven't been filing similar issues recently (#1055920?) and not realising it. (Has a build-dependency changed and then the buildd chroots are out of sync? Is that even possible? Am I?) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Reproducible Builds in October 2023
ble. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including: * Bernhard M. Wiedemann: * edje_cc [53] (race condition) * elasticsearch [54] (build failure) * erlang-retest [55] (embedded .zip timestamp) * fdo-client [56] (embeds private keys) * fftw3 [57] (random ordering) * gsoap [58] (date issue) * gutenprint [59] (date) * hub/golang [60] (embeds random build path) * Hyprland [61] (filesystem issue) * kitty [62] (sort-related issue, .tar file embeds modification time) * libpinyin [63] (ASLR) * maildir-utils [64] (date embedded in copyright) * mame [65] (order-related issue) * mingw32-binutils [66] & mingw64-binutils [67] (date) * MooseX [68] (date from perl-MooseX-App) * occt [69] (sorting issue) * openblas [70] (embeds CPU count) * OpenRGB [71] (corruption-related issue [72]) * python-numpy [73] (random file names) * python-pandas [74] (FTBFS) * python-quantities [75] (date) * python3-pyside2 [76] (order) * qemu [77] (date and Sphinx issue) * qpid [78] (sorting problem) * rakudo [79] (filesystem ordering issue) * SLOF [80] (date-related issue) * spack [81] (CPU counting issue) * xemacs-packages [82] (date-related issue) * Chris Lamb: * #1053353 [83] filed against dacite [84]. * #1053356 [85] filed against rtpengine [86]. [53] https://git.enlightenment.org/enlightenment/efl/issues/41 [54] https://github.com/elastic/elasticsearch-py/issues/2320 [55] https://build.opensuse.org/request/show/1116208 [56] https://bugzilla.opensuse.org/show_bug.cgi?id=1216293 [57] https://github.com/FFTW/fftw3/issues/337 [58] https://sourceforge.net/p/gsoap2/patches/185/ [59] https://sourceforge.net/p/gimp-print/source/merge-requests/9/ [60] https://github.com/golang/go/issues/63851 [61] https://github.com/hyprwm/Hyprland/pull/3550 [62] https://github.com/kovidgoyal/kitty/pull/6685 [63] https://github.com/libpinyin/libpinyin/issues/162 [64] https://github.com/djcb/mu/pull/2569 [65] https://github.com/mamedev/mame/pull/11651 [66] https://build.opensuse.org/request/show/1116036 [67] https://build.opensuse.org/request/show/1116040 [68] https://github.com/maros/MooseX-App/pull/71 [69] https://build.opensuse.org/request/show/1119524 [70] https://build.opensuse.org/request/show/1118201 [71] https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3675 [72] https://gitlab.com/CalcProgrammer1/OpenRGB/-/merge_requests/2103 [73] https://bugzilla.opensuse.org/show_bug.cgi?id=1216458 [74] https://build.opensuse.org/request/show/1117743 [75] https://build.opensuse.org/request/show/1117898 [76] https://bugreports.qt.io/browse/PYSIDE-2508 [77] https://build.opensuse.org/request/show/1121011 [78] https://github.com/apache/qpid-proton/pull/411 [79] https://github.com/rakudo/rakudo/pull/5426 [80] https://gitlab.com/qemu-project/SLOF/-/merge_requests/1 [81] https://build.opensuse.org/request/show/1118130 [82] https://build.opensuse.org/request/show/1119260 [83] https://bugs.debian.org/1053353 [84] https://tracker.debian.org/pkg/dacite [85] https://bugs.debian.org/1053356 In addition, Chris Lamb fixed an issue in diffoscope [87], where if the equivalent of "file -i" returns "text/plain", fallback to comparing as a text file. This was originally filed as Debian bug #1053668 [88]) by Niels Thykier. [89] This was then uploaded to Debian (and elsewhere) as version 251. [87] https://diffoscope.org [88] https://bugs.debian.org/1053668 [89] https://salsa.debian.org/reproducible-builds/diffoscope/commit/81c68d7b [86] https://tracker.debian.org/pkg/rtpengine §§§ ## Reproducibility testing framework The Reproducible Builds project operates a comprehensive testing framework (available at tests.reproducible-builds.org [90]) in order to check packages and other artifacts for reproducibility. In October, a number of changes were made by Holger Levsen: * Debian-related changes: * Refine the handling of package blacklisting, such as sending blacklisting notifications to the #debian-reproducible-changes IRC channel. [91][92][93] * Install systemd-oomd on all Debian bookworm nodes (re. Debian bug #1052257 [94]). [95] * Detect more cases of failures to delete schroots. [96] * Document various bugs in bookworm which are (currently) being manually worked around. [97] * Node-related changes: * Integrate the new arm64 machines from Codethink [98]. [99][100][101][102][103][104] * Improve various node cleanup routines. [105][106][107][108] * General node maintenance. [109][110][111][112] * Monitoring-related changes: * Remove unused Munin [113] monitoring plugins. [114] * Complain less visibly about "too many" installed kernels. [115] * Misc: * Enhance the firewall handling on Jenkins no
Re: Please review the draft for October's report
Chris Lamb wrote: > Please review the draft for October's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2023-10/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1723268669940113521 Thanks! -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for October's report
Hi all,
Please review the draft for October's Reproducible Builds report:
https://reproducible-builds.org/reports/2023-10/?draft
… or, via the Git repository itself:
https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2023-10.md
I intend to publish it no earlier than:
$ date -d 'Fri, 10 Nov 2023 14:15:00 +'
https://time.is/compare/1415_10_Nov_2023_in_GMT
§
Please feel free and commit/push to drafts directly without the overhead of
sending patches or merge requests. You should make your changes to the
"_reports/2023-10.md" file in the "reproducible-website" repository:
$ git clone https://salsa.debian.org/reproducible-builds/reproducible-website
$ cd reproducible-website
$ sensible-editor _reports/2023-10.md
I am happy to reword and/or rework additions prior to publishing. If you
currently do not have access to the above repository, you can request access
by following the instructions at:
https://reproducible-builds.org/contribute/salsa/
Regards,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: diffoscope timing out.
Jan-Benedict Glaw wrote:
> I cannot help with diffoscope. BUT I changed the NetBSD rb script to
> use two different build pathes which resulted in differences in
> comp.tar.gz.
Oh, good work tracking that down.
> REPROFLAGS+= -fdebug-prefix-map=\$$DESTDIR=
> +REPROFLAGS+= -fmacro-prefix-map=\$$DESTDIR=
For those who are unaware of the difference between -fdebug-prefix-map
and -fmacro-prefix-map, you can read about them in the GCC
documentation here:
https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#index-fmacro-prefix-map
https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-fdebug-prefix-map
Let's hope it solves reproducibility in this package. And, if it does,
that would certainly "solve" the diffoscope timeout issue.
Best wishes,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: diffoscope timing out.
Christos Zoulas wrote:
> For weeks now there is no useful output from diffoscope. Is there anything I
> can do to help debug the issue?
>
> tests.reproducible-builds.org[eeB]
> Wed 1 Nov 23:35:09 UTC 2023 - diffoscope 251 produced no output for
> x86_64-amd64/amd64/binary/sets/comp.tar.xz and was killed after running into
> timeout after 30m...
We'd actually love some help debugging this issue. As you can see from
the list archives, we have indeed been seeing this for a little while:
https://alioth-lists.debian.net/pipermail/reproducible-builds/Week-of-Mon-20230828/thread.html
… as well as some threads in later weeks.
However, are unsure whether this an issue with:
a) The system running tests.reproducible-builds.org (which, I believe,
was upgraded around the time this issue appeared?)
b) The code in diffoscope itself (which is somewhat unlikely, as there
have not been meaningful changes that might cause crashes or
timeouts.)
c) An issue in some tool or utility that diffoscope calls.
d) Some other issue.
However, Holger will likely have the most up-to-date information on
this, even if that is "I have no new information :-("
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1053668: diffoscope: Consider using `file -i` as fallback for unknown file output
Version: 251 FC Stegerman wrote: > I would argue that this is a bug in file(1) as Magdir/communications > uses a "string" test, which is for binary files. If this is a text > file, not a binary format, it should be forcing a text file test by > using "string/t" instead. > > That said, this is likely not the only such bug (I already encountered > one before [1]), so the suggestion below makes sense to me. Yes to both things. This was actually implemented and fixed last week, although I didn't encode the entry in debian/changelog correctly so this bug wasn't closed… so closing it now in BCC. :) Thanks to you both. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Verification Builds and Snapshots For Debian
Dear Vagrant, > In the meantime, I worked on a naive implementation of this, using > debmirror and btrfs snapshots (zfs or xfs are other likely candidates > for filesystem-level snapshots). It is working better than I expected! […] > Currently weighing in at about 550GB, each snapshot of the archive for > amd64+all+source is weighing in under 330GB if I recall correctly... so > that is over a month worth of snapshots for the cost of about two full > snapshots. Obviously, adding more architectures would dramatically > increase the space used (Would probably add arm64, armhf, i386, ppc64el > and riscv64 if I were to do this again). This sounds like great progress. :) Do you have any updates since you posted your message? (Are you snapshotting after each dinstall and labelling them with some timestamp…? Or perhaps you have some other, cleverer, scheme?) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Please review the draft for September's report
Chris Lamb wrote: > Please review the draft for September's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2023-09/ .. and also consider re-tweeting: https://twitter.com/ReproBuilds/status/1712505932544950565 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for September's report
Hi all,
Please review the draft for September's Reproducible Builds report:
https://reproducible-builds.org/reports/2023-09/?draft
… or, via the Git repository itself:
https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2023-09.md
I intend to publish it no earlier than:
$ date -d 'Thu, 12 Oct 2023 17:00:00 +0100'
https://time.is/compare/1700_12_Oct_2023_in_BST
§
Please feel free and commit/push to drafts directly without the overhead of
sending patches or merge requests. You should make your changes to the
"_reports/2023-09.md" file in the "reproducible-website" repository:
$ git clone https://salsa.debian.org/reproducible-builds/reproducible-website
$ cd reproducible-website
$ sensible-editor _reports/2023-09.md
I am happy to reword and/or rework additions prior to publishing. If you
currently do not have access to the above repository, you can request access
by following the instructions at:
https://reproducible-builds.org/contribute/salsa/
Regards,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1053668: diffoscope: Consider using `file -i` as fallback for unknown file output
Niels Thykier wrote: > Digging a bit deeper, it turns out that `file -i` correctly classifies > the changelog as `text/plain; charset=utf-8`. That is, `file` knows it > is text and I suspect `diffoscope` should try `file -i` as well when it > gets an unknown result from `file`. By "unknown result" I assume you mean that diffoscope cannot match the file type with any known comparator. :) Indeed, diffoscope doesn't recognise the bogus "Message Sequence Chart" so it falls back to using a hexdump as you intuited. I've got some WIP code that will treat unknown file types as text if they have a MIME type of text/plain. This avoids the use of hexdump with the examples you sent over at least. Do you think I should be further limiting that conditional to a whitelist of safe encodings, too? (eg. "utf-8" and "us-ascii", etc.) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Please review the draft for August's report
Chris Lamb wrote: > Please review the draft for August's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2023-08/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1700253293497536959 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for August's report
Hi all,
Please review the draft for August's Reproducible Builds report:
https://reproducible-builds.org/reports/2023-08/?draft
… or, via the Git repository itself:
https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2023-08.md
I intend to publish it no earlier than:
$ date -d 'Fri, 08 Sep 2023 20:00:00 -'
https://time.is/compare/2000_08_Sep_2023_in_UTC
§
Please feel free and commit/push to drafts directly without the overhead of
sending patches or merge requests. You should make your changes to the
"_reports/2023-08.md" file in the "reproducible-website" repository:
$ git clone https://salsa.debian.org/reproducible-builds/reproducible-website
$ cd reproducible-website
$ sensible-editor _reports/2023-08.md
I am happy to reword and/or rework additions prior to publishing. If you
currently do not have access to the above repository, you can request access
by following the instructions at:
https://reproducible-builds.org/contribute/salsa/
Regards,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: again, and now for longer (Re: Debian CI builds disabled for the moment)
FC Stegerman wrote: > You're passing --version as a non-option argument: > > diffoscope -- --version > > It worked (and was probably needed) before as the "--" was interpreted > by schroot, not diffoscope. Oh, bravo :) -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: again, and now for longer (Re: Debian CI builds disabled for the moment)
Holger Levsen wrote: > [13:16] < h01ger> https://deb.li/3jDcj / 4f9ccd0 is quite > straighforward, so I'd appreciate a 2nd look :) I would guess it's some quoting issue that's cutting off the argument prematurely; diffoscope's command-line argument parsing is involved, but it's not especially weird. Maybe there's an errant newline, or double quote or some variable is now empty...? Either way, I would recommend replacing the nice sh -c "export […] with nice sh -cx "export ^ … so we can see what it is actually trying to run within the schroot? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: again, and now for longer (Re: Debian CI builds disabled for the moment)
Holger Levsen wrote:
> what has changed in July is that this host was upgraded to bookworm. what
> also has changed is that diffoscope was upgraded (constantly to the sid
> version), though I don't see any relevant changes in changelog.
I can't think of any recent changes to diffoscope that would cause
this either. However, the problem could still "be" diffoscope in that
upgrading to bookworm has meant that the many programs that diffoscope
calls out to have been upgraded as well? Maybe these are much slower
for some reason.
Is there a way to see what diffoscope is up to? (the child process
tree? strace?)
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for July's report
Hi all, Please review the draft for July's Reproducible Builds report: https://reproducible-builds.org/reports/2023-07/?draft ⦠or, via the Git repository itself: https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2023-07.md I intend to publish it no earlier than: $ date -d 'Fri, 04 Aug 2023 14:15:00 +0100' https://time.is/compare/1415_04_Aug_2023_in_BST § Please feel free and commit/push to drafts directly without the overhead of sending patches or merge requests. You should make your changes to the "_reports/2023-07.md" file in the "reproducible-website" repository: $ git clone https://salsa.debian.org/reproducible-builds/reproducible-website $ cd reproducible-website $ sensible-editor _reports/2023-07.md I am happy to reword and/or rework additions prior to publishing. If you currently do not have access to the above repository, you can request access by following the instructions at: https://reproducible-builds.org/contribute/salsa/ Regards, -- o ⬠⬠Chris Lamb o o reproducible-builds.org ð ⬠⬠o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1040916: diffoscope: FTBFS with new android-platform-tools (33.0.3-1)
Danilo Egea Gondolfo wrote: > Some tests from tests/comparators are failing due to differences in the > expected result. I think this is actually a bug elsewhere: $ aapt2 dump resources tests/data/resources1.arsc aapt2: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libandroidfw.so.0: undefined symbol: _Z18ExtractEntryToFileP10ZipArchiveP8ZipEntryi This looks awfully familiar to this bug filed against dexdump: https://bugs.debian.org/1028243 … and may be related to (or even "be") this bug in android-platform-tools: https://bugs.debian.org/1024902 I'll followup to the second bug presently. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Please review the draft for June's report
Chris Lamb wrote: > Please review the draft for June's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2023-06/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1679119806820122627 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for June's report
Hi all,
Please review the draft for June's Reproducible Builds report:
https://reproducible-builds.org/reports/2023-06/?draft
… or, via the Git repository itself:
https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2023-06.md
I intend to publish it no earlier than:
$ date -d 'Wed, 12 Jul 2023 14:15:00 +0100'
https://time.is/compare/1415_12_Jul_2023_in_BST
§
Please feel free and commit/push to drafts directly without the overhead of
sending patches or merge requests. You should make your changes to the
"_reports/2023-06.md" file in the "reproducible-website" repository:
$ git clone https://salsa.debian.org/reproducible-builds/reproducible-website
$ cd reproducible-website
$ sensible-editor _reports/2023-06.md
I am happy to reword and/or rework additions prior to publishing. If you
currently do not have access to the above repository, you can request access
by following the instructions at:
https://reproducible-builds.org/contribute/salsa/
Regards,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: usrmerge testing in our CI
Holger Levsen wrote: > as soon as buildds are merged, varying trixie no longer makes > sense to me in either case […] > so should we stop testing usrmerge variations at all now? Thanks for taking this to the list. For 100% clarity, I understand Holger's "at all" suffix to mean, "shall we disable the usrmerge variation for bookworm as well as trixie?" Assuming that's the correct interpretation, from the perspective of someone patching packages to make them reproducible, it no longer makes sense to prepare patches that address any usrmerge issues. At the very least, they will not be prioritised by package maintainers. I'm less clear about whether we should cease testing bookworm. It doesn't seem right for the CI to claim that various [bookworm] packages are "reproducible in bookworm", when the presence of usrmerge (or lack thereof) in bookworm means that they can still vary. Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1037075: diffoscope: Get's killed trying to diff 2 large images (> 5GB)
forwarded 1037075 https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/342 thanks I've forwarded this "upstream" here: https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/342 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Please review the draft for May's report
Chris Lamb wrote: > Please review the draft for May's Reproducible Builds report: This has now been published — thanks to all who contributed. If you have a moment, please share the following link: https://reproducible-builds.org/reports/2023-05/ … and also consider retweeting: https://twitter.com/ReproBuilds/status/1665775526466969600 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for May's report
Hi all,
Please review the draft for May's Reproducible Builds report:
https://reproducible-builds.org/reports/2023-05/?draft
… or, via the Git repository itself:
https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2023-05.md
I intend to publish it no earlier than:
$ date -d 'Mon, 05 Jun 2023 17:00 -'
https://time.is/compare/1700_05_Jun_2023_in_UTC
§
Please feel free and commit/push to drafts directly without the overhead of
sending patches or merge requests. You should make your changes to the
"_reports/2023-05.md" file in the "reproducible-website" repository:
$ git clone https://salsa.debian.org/reproducible-builds/reproducible-website
$ cd reproducible-website
$ sensible-editor _reports/2023-05.md
I am happy to reword and/or rework additions prior to publishing. If you
currently do not have access to the above repository, you can request access
by following the instructions at:
https://reproducible-builds.org/contribute/salsa/
Regards,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Please review the draft for April's report
Chris Lamb wrote: > Please review the draft for April's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2023-04/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1654938704119726080 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for April's report
Hey folks,
If you have a moment, please review the draft for the Reproducible
Builds report for April:
https://reproducible-builds.org/reports/2023-04/?draft
You can do this via the Git repository itself, too:
https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2023-04.md
I intend to publish it no earlier than:
$ date -d 'Sat, 06 May 2023 18:00:00 -'
https://time.is/compare/1800_06_May_2023_in_UTC
§
Please feel free and commit/push to drafts directly without the
overhead of sending patches or merge requests to me directly. You
should make your changes to the "_reports/2023-04.md" file in the
"reproducible-website" repository:
$ git clone https://salsa.debian.org/reproducible-builds/reproducible-website
$ cd reproducible-website
$ vim _reports/2023-04.md
I am happy to reword and/or rework additions prior to publishing,
though. If you currently do not have access to the above repository,
you can request access by following the instructions at:
https://reproducible-builds.org/contribute/salsa/
Best wishes,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1034504: diffoscope: Wrong binary called for the Procyon Java decompiler
forwarded 1034504 https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/338 thanks I've forwarded this 'upstream' here: https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/338 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1034034: Does not know about Linux kernel module signatures
forwarded 1034034 https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/337 thanks I've forwarded this 'upstream' to Salsa here: https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/337 This is to help us triage, comment and ultimately fix this issue more effectively. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Please review the draft for March's report
Chris Lamb wrote: > Please review the draft for March's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2023-03/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1644283929598337024 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for March's report
Hi all, Please review the draft for March's Reproducible Builds report: https://reproducible-builds.org/reports/2023-03/?draft ⦠or, via the Git repository itself: https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2023-03.md I intend to publish it no earlier than: $ date -d 'Thu, 06 Apr 2023 14:15:00 +0100' https://time.is/compare/1415_06_Apr_2023_in_BST § Please feel free and commit/push to drafts directly without the overhead of sending patches or merge requests. You should make your changes to the "_reports/2023-03.md" file in the "reproducible-website" repository: $ git clone https://salsa.debian.org/reproducible-builds/reproducible-website $ cd reproducible-website $ sensible-editor _reports/2023-03.md I am happy to reword and/or rework additions prior to publishing. If you currently do not have access to the above repository, you can request access by following the instructions at: https://reproducible-builds.org/contribute/salsa/ Regards, -- o ⬠⬠Chris Lamb o o reproducible-builds.org ð ⬠⬠o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Please review the draft for February's report
Chris Lamb wrote: > Please review the draft for February's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2023-02/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1632305660657270786 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for February's report
Hi all, Please review the draft for February's Reproducible Builds report: https://reproducible-builds.org/reports/2023-02/?draft ⦠or, via the Git repository itself: https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2023-02.md I intend to publish it no earlier than: $ date -d 'Sat, 04 Mar 2023 14:15:00 +' https://time.is/compare/1415_04_Mar_2023_in_GMT § Please feel free and commit/push to drafts directly without the overhead of sending patches or merge requests. You should make your changes to the "_reports/2023-02.md" file in the "reproducible-website" repository: $ git clone https://salsa.debian.org/reproducible-builds/reproducible-website $ cd reproducible-website $ sensible-editor _reports/2023-02.md I am happy to reword and/or rework additions prior to publishing. If you currently do not have access to the above repository, you can request access by following the instructions at: https://reproducible-builds.org/contribute/salsa/ Regards, -- o ⬠⬠Chris Lamb o o reproducible-builds.org ð ⬠⬠o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Reproducibility of ocaml...
Hi Stéphane,
> Looking at [3], it seems only unstable is affected. Are you aware of a
> change that could explain that? In particular, I don't understand why
> the bookworm version is reported as reproducible whereas the version is
> the same as unstable.
I appreciate this info is difficult to find (!), but for a bunch of
historical reasons, there are actually a different set of variations
tested when we test sid compared to when we test bookworm. In other
words, the differences between the two builds is not just the package
version and Debian distribution.
We try to canonically document the differences on this page:
https://tests.reproducible-builds.org/debian/index_variations.html
And almost certainly the difference is down to the build path. :) Does
that help? We've had a series of build path variations in the OCaml
stack, so maybe some patch got reverted, or…?
Best wishes,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Please review the draft for January's report
Chris Lamb wrote: > Please review the draft for January's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2023-01/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1622394778850832388 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for January's report
Hi all,
Please review the draft for January's Reproducible Builds report:
https://reproducible-builds.org/reports/2023-01/?draft
… or via the Git repository itself:
https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2023-01.md
I intend to publish it no earlier than:
$ date -d 'Sat, 04 Feb 2023 21:00:00 -'
https://time.is/compare/2100_04_Feb_2023_in_UTC
§
Please feel very free and commit/push to drafts directly, without the
overhead of sending patches or merge requests. You should make your
changes to the "_reports/2023-01.md" file in the
"reproducible-website" repository:
$ git clone https://salsa.debian.org/reproducible-builds/reproducible-website
$ cd reproducible-website
$ vi _reports/2023-01.md
I am happy to reword and/or rework additions prior to publishing
though. If you currently do not have access to the above repository,
you can request access by following the instructions at:
https://reproducible-builds.org/contribute/salsa/
Regards,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1029066: diffoscope: FTBFS if no internet is available (using internet connection during build)
Hi all,
> […]
As Mattia writes on the Salsa bug [0], I now don't think this is a
network issue. In other words, the package FTBFS regardless of whether
you have network access or not.
To make debugging this easier, I've split out the inline Python code
in c341b63a [1], and simply running the new script results in:
$ ping -q -c1 google.com 2>&1 | grep packet
1 packets transmitted, 1 received, 0% packet loss, time 0ms
$ debian/tests/generate-recommends.py
ERROR: Could not find an activated virtualenv (required).
Traceback (most recent call last):
File
"/home/lamby/git/debian/reproducible-builds/diffoscope/debian/tests/generate-recommends.py",
line 7, in
dist = meta.load(".")
^^
File "/usr/lib/python3/dist-packages/pep517/meta.py", line 72, in load
path = Path(build_as_zip(builder))
^
File "/usr/lib/python3/dist-packages/pep517/meta.py", line 59, in
build_as_zip
builder(dest=out_dir)
File "/usr/lib/python3/dist-packages/pep517/meta.py", line 53, in build
env.pip_install(system['requires'])
File "/usr/lib/python3/dist-packages/pep517/envbuild.py", line 103, in
pip_install
check_call(
File "/usr/lib/python3.11/subprocess.py", line 413, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/bin/python3', '-m',
'pip', 'install', '--ignore-installed', '--prefix',
'/tmp/pep517-build-env-jzvg739_', 'setuptools', 'wheel']' returned
non-zero exit status 3.
Regarding when this was introduced, I think a confounding factor is
that this behaviour is reliant on the behaviour of the python3-pep517
package. (Maybe this *was* a network-related issue in the past as
well… but this matters very little now.)
As to a solution, though, I think this is somewhat blocking on Mattia's
expertise in the generation of the Python test recommends. Are we, in
essence, trying to parse the following data in setup.py?
install_requires=[
"python-magic",
"libarchive-c",
],
extras_require={
"distro_detection": ["distro"],
"cmdline": ["argcomplete", "progressbar"],
"comparators": [
"androguard",
"binwalk",
"defusedxml",
"guestfs",
"jsondiff",
"python-debian",
"pypdf",
"pyxattr",
"rpm-python",
"tlsh",
],
},
If so, we don't necessarily have to wholesale move to pyproject.toml;
instead, we could rejig setup.py...?
Chris
[0]
https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/325#note_366185
[1]
https://salsa.debian.org/reproducible-builds/diffoscope/commit/c341b63a4c8cfe56be883b43b4e4faff71fc060e
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Please review the draft for December's report
Chris Lamb wrote: > Please review the draft for December's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2022-12/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1611746159994757121 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for December's report
Hi all,
Please review the draft for December's Reproducible Builds report:
https://reproducible-builds.org/reports/2022-12/?draft
… or, via the Git repository itself:
https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2022-12.md
I intend to publish it no earlier than:
$ date -d 'Sat, 07 Jan 2023 14:15:00 +'
https://time.is/compare/1415_07_Jan_2023_in_GMT
§
Please feel free and commit/push to drafts directly without the overhead of
sending patches or merge requests. You should make your changes to the
"_reports/2022-12.md" file in the "reproducible-website" repository:
$ git clone https://salsa.debian.org/reproducible-builds/reproducible-website
$ cd reproducible-website
$ sensible-editor _reports/2022-12.md
I am happy to reword and/or rework additions prior to publishing. If you
currently do not have access to the above repository, you can request access
by following the instructions at:
https://reproducible-builds.org/contribute/salsa/
Regards,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1026982: [PATCH] disambiguate "package" output message
tags 1026982 + pending thanks Fixed in Git, although I made it helpful on other distros as well: https://salsa.debian.org/reproducible-builds/diffoscope/commit/85bf76f0deb398a89512a4675cfc3be8d4511902 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1026976: Upcoming test suite regression due to changes in file/libmagic
Hi Christoph, Thanks again for the "new version of file in experimental" bugs; very much appreciated. > - a /usr/bin/python3 script executable (binary data) > + Zip archive, with extra data prepended > > Now that looks a bit delicate ... if you think this is something that > should be handled in file/libmagic, let me know. Naturally, as one of the maintainers of strip-nondeterminism, I am inclined to believe that this is a minor regression in file. :) However, this "extra data prepended" doesn't fit well under the rubric of "data". Yes, this "#!/usr/bin/python3\n" shebang is definitely "data" of a kind, but a shebang isn't really data in that way given the special-treatment afforded to it by UNIX systems. Even if this noun was replaced by the more general "bytes", the magic nature of the shebang would still remain… as would the desire to discriminate between pyzip files and other ZIP files with prepended data. Could another — different — string be emitted in the case that these prepended bytes are a shebang? We could potentially look for the file starting with #! and for that to take precedence over this new case. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Heads-up: New upstream version of src:file in experimental
Hi Christoph,
> there hasn't been another upstream version upload of file/libmagic for a
> while, but it was about time. Version 5.43 was released in October, I've
> uploaded it with a cumulative patch into experimental tonight, version
> 1:5.43-3. As your package is one of those that somewhat suffered from
> surprising feature changes of libmagic in the past, I'd like to give you
> an opportunity to test and to prepare for any changes, for better or for
> worse. In case of the latter, use the BTS as usual to report detections
> that could see an improvement.
Thanks very much for this; I've gone ahead and committed a fix for
this here:
https://salsa.debian.org/reproducible-builds/diffoscope/commit/44ebd188adad543ba2a5bd81ed5a7e6436b36784
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Debian NMU Sprints in December, Thursdays 17:00 UTC!
Vagrant Cascadian wrote: > Since the previous sprints were fun and productive, I am planning on > doing NMU sprints every Thursday in December (1st, 8th, 15th, 22nd, > 29th). Sorry for the last-minute notice but I won't be able to make the sprint today (2022-12-22). Happy NMUing... and see you at the next one! Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1026520: reprotest: FTBFS: AttributeError: module 're' has no attribute 'sre_parse'
reassign 1026520 python-rstr merge 1026569 1026520 affects 1026520 diffoscope thanks Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. Quite so. However, I think the problem is elsewhere: >> File "/usr/lib/python3/dist-packages/rstr/xeger.py", line 63, in xeger >> parsed = re.sre_parse.parse(pattern) >> >> AttributeError: module 're' has no attribute 'sre_parse' I believe this is #1026569 in python-rstr. ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Please review the draft for November's report
Chris Lamb wrote: > Please review the draft for November's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2022-11/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1600910286034153472 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for November's report
Hi all,
Please review the draft for November's Reproducible Builds report:
https://reproducible-builds.org/reports/2022-11/?draft
… or, via the Git repository itself:
https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2022-11.md
I intend to publish it no earlier than:
$ date -d 'Thu, 08 Dec 2022 17:00:00 +'
aka.
https://time.is/compare/1700_08_Dec_2022_in_GMT
§
Please feel free and commit/push to drafts directly without the overhead of
sending patches or merge requests. You should make your changes to the
"_reports/2022-11.md" file in the "reproducible-website" repository:
$ git clone https://salsa.debian.org/reproducible-builds/reproducible-website
$ cd reproducible-website
$ sensible-editor _reports/2022-11.md
I am happy to reword and/or rework additions prior to publishing. If you
currently do not have access to the above repository, you can request access
by following the instructions at:
https://reproducible-builds.org/contribute/salsa/
Regards,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Debian NMU Sprints in December, Thursdays 17:00 UTC!
Vagrant Cascadian wrote: > Since the previous sprints were fun and productive, I am planning on > doing NMU sprints every Thursday in December (1st, 8th, 15th, 22nd, > 29th). I'll be there/then on the 8th, 22nd (maybe...) and the 29th. :) Best wishes, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Please review the draft for October's report
Chris Lamb wrote: > Please review the draft for October's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2022-10/ .. and, assuming Twitter hasn't *completely* imploded by the time you read this, also consider retweeting: https://twitter.com/ReproBuilds/status/1591099431986032640 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Debian NMU Sprint Thursday November 17th 17:00 UTC!
Vagrant Cascadian wrote: > […] > Oops! Thursday November 17th! See you there/then! Best wishes, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Debian NMU Sprint Thursday November 16th 17:00 UTC!
Hi Vagrant, > […] Can you clarify whether you meant *Wednesday* November 16th or Thursday November *17th*? :) Chris -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for October's report
Hi all, Please review the draft for October's Reproducible Builds report: https://reproducible-builds.org/reports/2022-10/?draft ⦠or, via the Git repository itself: https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2022-10.md I intend to publish it no earlier than: $ date -d 'Fri, 11 Nov 2022 14:15:00 +' https://time.is/compare/1415_11_Nov_2022_in_GMT § Please feel free and commit/push to drafts directly without the overhead of sending patches or merge requests. You should make your changes to the "_reports/2022-10.md" file in the "reproducible-website" repository: $ git clone https://salsa.debian.org/reproducible-builds/reproducible-website $ cd reproducible-website $ sensible-editor _reports/2022-10.md I am happy to reword and/or rework additions prior to publishing. If you currently do not have access to the above repository, you can request access by following the instructions at: https://reproducible-builds.org/contribute/salsa/ Regards, -- o ⬠⬠Chris Lamb o o reproducible-builds.org ð ⬠⬠o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Debian NMU Sprint Thursday 16:00 UTC!
Hi Vagrant, > Basically, I'm usually up for it any Thursday at that time slot. Two > days might be a bit too soon to schedule (though I would do it if someone > else wanted to!)... > > how about the November 17th and December 1st? 16:00 UTC or 17:00 UTC? I can't do December 1st as I have jury duty (!), but I *can* do November 17th at either 16:00 UTC or 17:00 UTC. Or both. Could you choose your preferred timings and then announce it in a fresh thread? > I did a solo one on October 20th and still got a couple NMUs in: > > msp430mcu_20120406-2.3_source.ftp-master.upload > checkpw_1.02-1.2_source.ftp-master.upload > > And did the legwork that lead to a QA upload the following day: > > madlib_1.3.0-3_source.ftp-master.upload Oh, neat work. :) Best wishes, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Debian NMU Sprint Thursday 16:00 UTC!
Hi Vagrant, > > We are planning on meeting on irc.oftc.net in the #debian-reproducible > > channel at 16:00UTC and going for an hour or two or three. > > It was fun, so we hope to do this roughly every two weeks! > Next one is thus planned for Thursday, October 6th, 16:00 UTC! I enjoyed the sprint on October 6th and found it both fun and productive; can we schedule another one...? Best wishes, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1022209: diffoscope: highlight text-only differences in HTML files
tags 1022209 + pending thanks Fixed in Git, pending upload: https://salsa.debian.org/reproducible-builds/diffoscope/commit/d647eb7554e3bd51ab8fbe18fc84f885fce4f789 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1022146: diffoscope: detect ordering-only differences in XML files
tags 1022146 + pending thanks Fixed in Git, pending upload: https://salsa.debian.org/reproducible-builds/diffoscope/commit/dbf5350fdacf5790ceab4f784ab8fc2f41cfa24c Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1022145: diffoscope: detect ordering-only differences in text files
tags 1022145 + pending thanks Fixed in Git, pending upload: https://salsa.debian.org/reproducible-builds/diffoscope/commit/727b3c9ea54b89465d2308997aa8b4bd25bff07f Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#989626: diffoscope: when comparing fonts with .ttx files, convert the font to .ttx first
forwarded 989626 https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/315 thanks I've forwarded this upstream here: https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/315 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1022210: diffoscope: highlight whitespace-only differences in text data
forwarded 1022210 https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/319 thanks I've forwarded this upstream here: https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/319 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1022209: diffoscope: highlight text-only differences in HTML files
forwarded 1022209 https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/318 thanks I've forwarded this upstream here: https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/318 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1022146: diffoscope: detect ordering-only differences in XML files
forwarded 1022146 https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/317 thanks I've forwarded this upstream here: https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/317 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1022145: diffoscope: detect ordering-only differences in text files
forwarded 1022145 https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/316 thanks I've forwarded this upstream here: https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/316 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Please review the draft for September's report
Chris Lamb wrote: > Please review the draft for September's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2022-09/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1578497371239223296 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Please review the draft for September's report
Hi Richard^WRoland,
> I've pushed 2 corrections:
Thank you for these.
> 2) Precision: The cannonical timestamp is for Debian, not 'an archive'.
> You might want to split this now into two sentences, since the content
> is not related.
Ah, can you go ahead and change this yourself? You can probably do
this better than I can as you have all of the context, after all...
Best wishes,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Please review the draft for September's report
Hi all, Please review the draft for September's Reproducible Builds report: https://reproducible-builds.org/reports/2022-09/?draft ⦠or, via the Git repository itself: https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2022-09.md I intend to publish it no earlier than: $ date -d 'Fri, 07 Oct 2022 14:15:00 -0700' https://time.is/compare/1415_07_Oct_2022_in_PDT § Please feel free and commit/push to drafts directly without the overhead of sending patches or merge requests. You should make your changes to the "_reports/2022-09.md" file in the "reproducible-website" repository: $ git clone https://salsa.debian.org/reproducible-builds/reproducible-website $ cd reproducible-website $ sensible-editor _reports/2022-09.md I am happy to reword and/or rework additions prior to publishing. If you currently do not have access to the above repository, you can request access by following the instructions at: https://reproducible-builds.org/contribute/salsa/ Regards, -- o ⬠⬠Chris Lamb o o reproducible-builds.org ð ⬠⬠o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
