Bug#1064648: allegro5-doc: please make the build reproducible.
Hi Andreas, On Thu, 9 May 2024 at 11:17, Andreas Rönnquist wrote: > > Those fixes was obviously not enough, just see the repro reports. Ok, yep - thanks for checking those. When I check the reports, most of the remaining problems seem to relate to duplicate definitions appearing in the documentation (for example, a definition for "al_color_cmyk" appearing twice). > The strange thing is that it according to the tests does seem to build > reproducible on arm64... Puzzling indeed. I'll have another read through the codebase soon. > One other detail is that on armhf the only change seems to be the > architecture which is included in the ALLEGRO_PKG_HOST_SYSTEM variable. > > Is there some magic like SOURCE_DATE_EPOCH to use that would avoid this > problem in this case? Not as far as I'm aware, no - for SOURCE_DATE_EPOCH, there is a range of possible integer values that are all equally valid, so it's straightforward to select one to make a package build reproducible. Specifiying an arbitrary but static architecture could be at-least challenging, and at-worst misleading or potentially compatibility-breaking. In this kind of situation I'd generally recommend working backwards to figure out whether -- and if so, how -- the nondeterministic value is used. I didn't find any search results for ALLEGRO_PKG_HOST_SYSTEM in Debian codesearch[1], so I'd recommend a reprotest build after removing it to see whether that succeeds (I'll try this soon). Regards, James [1] - https://codesearch.debian.net/search?q=ALLEGRO_PKG_HOST_SYSTEM [2] - https://salsa.debian.org/reproducible-builds/reprotest
Bug#1070208: openttd: cmake licensing concern for openttd 14.0 source package
Source: openttd Version: 14.0-1 Severity: serious Tags: upstream Justification: Policy 12.5 Control: forwarded -1 https://github.com/OpenTTD/OpenTTD/pull/12603 Dear Maintainer, The build scripts for the initial version 14.0 release of OpenTTD include a CMake file that determines whether and how to add compile-time flags to request that libatomic should be linked. The relevant CMake file addition was sourced[1] from the LLVM codebase, which is licensed under a variant of the Apache 2.0 license with some exception clauses added for the LLVM project. This is not yet documented in the source package. I'm reporting this bug with severity 'serious' because I feel that there is a potential licensing concern here; until that is confirmed one way or the other, I've offered what I believe is a possible resolution (adding the LLVM license -- slightly confusingly _also_ referred to as v14, because that is the version of LLVM where it was introduced, despite v18 being LLVM-current), to upstream[2]. To explain my reasoning: On balance I'd prefer opening a serious-severity bug to prevent migration (that could later be reduced in severity) than to allow the package transition while being aware of a potential problem. Thanks, James [1] - https://github.com/OpenTTD/OpenTTD/pull/10513 [2] - https://github.com/OpenTTD/OpenTTD/pull/12603
Bug#1069907: dh_apache2: please output reproducible module package pre/post scripts.
Package: apache2-dev Severity: wishlist User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness Control: affects -1 mod-mono Dear Maintainer, I'm an occasional volunteer contributor to the Reproducible Builds[1] project, and noticed recently that an Apache webserver module, mod-mono, that depends[2] on the dh_apache2 debhelper utility from apache2-dev at build-time, failed an automated Debian reproducibility test[3]. The problem appears to be related to the substitution of a NAMES variable that appears in the templated pre/post scripts evaluated by dh_apache2; the templates[4][5][6] are found in the 'apache2' source package. I don't yet know exactly how the non-deterministic ordering of entries in the NAMES variable occurs; however the replacement parameters[7] in the dh_apache2.in script seem relevant, and tracing the creation of those may help. Producing a value for the NAMES variable deterministically should I believe allow the mod-mono package -- and any other Debian Apache module packages that contain more than one named module -- to build reproducibily, in turn enabling consumers of Debian to reliably rebuild a bit-for-bit identical .deb package from source. Regards, James [1] - https://reproducible-builds.org/ [2] - https://sources.debian.org/src/mod-mono/3.8-3/debian/control/#L9 [3] - https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/diffoscope-results/mod-mono.html [4] - https://sources.debian.org/src/apache2/2.4.58-1/debian/debhelper/postinst-apache2/ [5] - https://sources.debian.org/src/apache2/2.4.58-1/debian/debhelper/postrm-apache2/ [6] - https://sources.debian.org/src/apache2/2.4.58-1/debian/debhelper/prerm-apache2/ [7] - https://sources.debian.org/src/apache2/2.4.58-1/debian/debhelper/dh_apache2.in/#L551
Bug#1069774: sphinx: tests: skip_tests_network.diff patch can be dropped from v7.3.0 onwards.
Source: sphinx Severity: wishlist Dear Maintainer, The Sphinx v7.3.0 release included a pull request[1] to make the test suite behave more consistently when the network conditions (online/offline) vary between test suite evaluations. One of the changes introduced by that is to replace some remote hyperlinks referenced in the 'tests.test_builders.test_build_latex.test_latex_images' test case with hyperlinks to localhost instead. I believe that this should make it possible to drop 'skip_tests_network.diff' from the Debian sphinx patch series. Thank you, James [1] - https://github.com/sphinx-doc/sphinx/pull/12095
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
Ok, that's reasonable. Re: content-negotation: the www FAQ[1] makes me think that, at least currently, it's not worth attempting anything more advanced than language negotiation. Re: file suffixes: after re-reading the Sphinx code and experimenting with a few builds: I'm convinced that the html_file_suffix setting does _not_ help. I couldn't think of a better near-term alternative than using the cron script to adjust the searchindex.js src attribute, similar to the HTML hrefs. I don't really like that, though. And finally, re: other Sphinx-built documentation, I noticed some JavaScript errors for the language chooser in the online HTML developers-reference[2], so I've opened a merge request[3] related to that. It's not directly related here, but I'm mentioning it because the documentation projects share some similarities. [1] - https://www.debian.org/devel/website/desc.en.html#faq [2] - https://www.debian.org/doc/manuals/developers-reference/ [3] - https://salsa.debian.org/debian/developers-reference/-/merge_requests/48
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
On Wed, 17 Apr 2024 at 21:46, Holger Wansing wrote:
> James Addison wrote (Sun, 14 Apr 2024 23:52:03 +0100):
> > The _other_ hyperlinks in the static content are replaced as part of the
> > cronjob[1] - but that doesn't work for items in the searchindex.js file.
> >
> > Fortunately I think there might be a better way to do this. Sphinx itself
> > has
> > an HTML builder option 'html_file_suffix' and I think we could use that
> > instead
> > to define the filenames. That option is respected by the search JavaScript
> > using a template variable[3] in the documentation_options.js file.
>
> I fear I have no idea what to do with these options:
>
> add 'html_file_suffix' in the conf.py: the default value is html here, what
> should I insert here?
A possibility would be to configure it during make, by using something like:
-D html_file_suffix=$*
> in documentation_options.js I have FILE_SUFFIX: '{{ file_suffix }}'; what
> to do with this?
With an html_file_suffix config option, that becomes: FILE_SUFFIX: 'es-ES' (for
example).
> An idea came to mind:
> if we could change the search results, so that they no longer have a file
> extension (say: the link points to 'installing' instead of 'installing.html')
> everything would work fine I guess, since the browser delivers the correct
> language page due to content negotiation according to browser lang settings.
>
>
> I don't know if you thought about such thing, when writing about above html
> build / file suffix options???
> (as already said: I have no clue how the above could change something)
I hadn't considered that approach, but it could make sense since there are
other file formats that we build (text, PDF) and those could also be negotiated
by an HTTP user-agent.
> > We should be careful of other side-effects if making that change, but it
> > would remove a deployment transformation step on the static content, and I
> > think that's beneficial.
> >
> > [1] -
> > https://salsa.debian.org/webmaster-team/cron/-/blob/3462a061d0a67dce3761b0f4d9357c017ad0a50b/parts/7release-notes#L64-70
> >
> > [2] -
> > https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-html_file_suffix
> >
> > [3] -
> > https://github.com/sphinx-doc/sphinx/blob/cf7d2759af0852d67288e58d823d51fe860749ca/sphinx/themes/basic/static/documentation_options.js_t#L6
> >
>
>
> --
> Holger Wansing
> PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
On Wed, 17 Apr 2024 at 19:36, Holger Wansing wrote: > Am 16. April 2024 23:47:05 MESZ schrieb James Addison : > >> I have tried to deal with this by some adaptions in the cronjob - see the > >> first two additions in my patch: change all links to search.html into > >> search.§lang.html, and rename the language-specific searchindex files into > >> searchindex.$lang.js. > >> However, that does not seem to be enough. > > > >When you say it is not enough: could I check what you mean by that? > > I could guess that changings on the Search box are needed, to use > the language-wise correct searchindex. > > But that's too much corrections on the Sphinx-generated result > if you ask me... Some .js files remain static when the source is rebuilt in different languages; however searchindex.js is not one of those files. So it seems that the content to retrieve for it should be negotiated between the client and server too, like the html-suffix files. > And out of my skills, sorry. Identifying and describing the problem is part of the fix; I'll think about it some more but I reckon there's already some relevant information from this discussion to take upstream to Sphinx issue thread(s).
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
On Tue, 16 Apr 2024 at 22:47, James Addison wrote:> > Thanks Holger, > > On Mon, 15 Apr 2024 at 20:43, Holger Wansing wrote: > > > > Hi, > > > > James Addison wrote (Sun, 14 Apr 2024 23:52:03 +0100): > > > From some testing of these: the search results have a problem that they > > > hyperlink to a language-less .html URL, meaning that clicking a result > > > link in > > > the DE-language search results takes the user to a EN-language page. > > > > Yes, good catch. > > However it's even worse: if you view a German page and use the Search > > function, > > the search index for English is used. > > Wait, I'm confused. Not on your site, though. There you have the > per-language > search indices. > > And in fact, when deployed to the debian.org website, requested-language > search > (mapping of the browser language to an appropriate searchindex.*.js > file) could be > (and is already) a better user experience. If you hypothetically send > me a hyperlink > to a policy section auf Deutsch, that's fine, but when I search for > 'configuration' > after reading that, I might want my browser settings to have been respected, > in > terms of what is searched. > > > I have tried to deal with this by some adaptions in the cronjob - see the > > first two additions in my patch: change all links to search.html into > > search.§lang.html, and rename the language-specific searchindex files into > > searchindex.$lang.js. > > However, that does not seem to be enough. > > When you say it is not enough: could I check what you mean by that? > > > > The _other_ hyperlinks in the static content are replaced as part of the > > > cronjob[1] - but that doesn't work for items in the searchindex.js file. > > > > Why is that a problem at all (maybe you know this already): > > since we use content negotiation at Debian website (so the pages are > > delivered in the correct language according to user's browser setting), we > > change the directory structure away from the default how it's build by > > Sphinx: > > after Sphinx' make there are separate directories for every language, > > and they contain everything for that language, including the searchindex.js > > file. And in that structure it works fine. > > On Debian website we put everything in one directory, adding the language > > code into the filename in front of the .html extension. > > While this works fine for static content, it does not for the search > > function here. > > I think this is a reasonable solution; serving the content from a > single directory > is simple and logical because the permissions and content should be the same; > the latter only differs as a result of locale and therefore translation. > > > > Fortunately I think there might be a better way to do this. Sphinx > > > itself has > > > an HTML builder option 'html_file_suffix' and I think we could use that > > > instead > > > to define the filenames. That option is respected by the search > > > JavaScript > > > using a template variable[3] in the documentation_options.js file. > > > > > > We should be careful of other side-effects if making that change, but it > > > would remove a deployment transformation step on the static content, and I > > > think that's beneficial. > > > > I don't understand how that could affect our search function problem, > > but I could give it a try. > > The main change that it would introduce is that the dynamic search results > that > appear in the search results (as gathered by the JavaScript) have > hyperlinks that > include the build-time suffix in the filename. So in the example > above, you have > linked me to a German-language dokumentation page, and when I search from > that page, I find (based on a DE search index) and am linked to (based on DE > file suffixes) Deutsch results; foo.de.html instead of foo.html for example. > > I'm in two minds about this: if my browser settings say that my locale is > en-150 > and I land on a de-DE page, what language should search be performed in, and > what language should the results link to? > > An answer that I find straightforward is that if the page is de-DE -- which > your > hypothetical link to me was -- then because everything on that page _should_ > (with sufficient translation availability) be in German, then I would expect > to > search and be linked to pages accordingly. If you'd linked to a language-less > URL, then that would (a) have been thoughtful if you suspected that I did not > comprehend Deutsch, and (b) a
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
Thanks Holger, On Mon, 15 Apr 2024 at 20:43, Holger Wansing wrote: > > Hi, > > James Addison wrote (Sun, 14 Apr 2024 23:52:03 +0100): > > From some testing of these: the search results have a problem that they > > hyperlink to a language-less .html URL, meaning that clicking a result link > > in > > the DE-language search results takes the user to a EN-language page. > > Yes, good catch. > However it's even worse: if you view a German page and use the Search > function, > the search index for English is used. Wait, I'm confused. Not on your site, though. There you have the per-language search indices. And in fact, when deployed to the debian.org website, requested-language search (mapping of the browser language to an appropriate searchindex.*.js file) could be (and is already) a better user experience. If you hypothetically send me a hyperlink to a policy section auf Deutsch, that's fine, but when I search for 'configuration' after reading that, I might want my browser settings to have been respected, in terms of what is searched. > I have tried to deal with this by some adaptions in the cronjob - see the > first two additions in my patch: change all links to search.html into > search.§lang.html, and rename the language-specific searchindex files into > searchindex.$lang.js. > However, that does not seem to be enough. When you say it is not enough: could I check what you mean by that? > > The _other_ hyperlinks in the static content are replaced as part of the > > cronjob[1] - but that doesn't work for items in the searchindex.js file. > > Why is that a problem at all (maybe you know this already): > since we use content negotiation at Debian website (so the pages are > delivered in the correct language according to user's browser setting), we > change the directory structure away from the default how it's build by Sphinx: > after Sphinx' make there are separate directories for every language, > and they contain everything for that language, including the searchindex.js > file. And in that structure it works fine. > On Debian website we put everything in one directory, adding the language > code into the filename in front of the .html extension. > While this works fine for static content, it does not for the search > function here. I think this is a reasonable solution; serving the content from a single directory is simple and logical because the permissions and content should be the same; the latter only differs as a result of locale and therefore translation. > > Fortunately I think there might be a better way to do this. Sphinx itself > > has > > an HTML builder option 'html_file_suffix' and I think we could use that > > instead > > to define the filenames. That option is respected by the search JavaScript > > using a template variable[3] in the documentation_options.js file. > > > > We should be careful of other side-effects if making that change, but it > > would remove a deployment transformation step on the static content, and I > > think that's beneficial. > > I don't understand how that could affect our search function problem, > but I could give it a try. The main change that it would introduce is that the dynamic search results that appear in the search results (as gathered by the JavaScript) have hyperlinks that include the build-time suffix in the filename. So in the example above, you have linked me to a German-language dokumentation page, and when I search from that page, I find (based on a DE search index) and am linked to (based on DE file suffixes) Deutsch results; foo.de.html instead of foo.html for example. I'm in two minds about this: if my browser settings say that my locale is en-150 and I land on a de-DE page, what language should search be performed in, and what language should the results link to? An answer that I find straightforward is that if the page is de-DE -- which your hypothetical link to me was -- then because everything on that page _should_ (with sufficient translation availability) be in German, then I would expect to search and be linked to pages accordingly. If you'd linked to a language-less URL, then that would (a) have been thoughtful if you suspected that I did not comprehend Deutsch, and (b) also be provided in my default locale, with search and results taking place accordingly, and without any specific locale in the result hyperlinks (because the server will select a resource to serve). Note also: there does _not_ appear to be an equivalent to the 'html_file_suffix' config setting to adjust the search index filename. Regards, James
Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs
Hi Holger, On Sun, 14 Apr 2024 22:40:36 +0200, Holger wrote: > I forgot to mention, that I have pushed a release-notes variant with this theme to > https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.en.html > (English) > > https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.de.html > (German) > > https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.ca.html > (Catalan) >From some testing of these: the search results have a problem that they hyperlink to a language-less .html URL, meaning that clicking a result link in the DE-language search results takes the user to a EN-language page. The _other_ hyperlinks in the static content are replaced as part of the cronjob[1] - but that doesn't work for items in the searchindex.js file. Fortunately I think there might be a better way to do this. Sphinx itself has an HTML builder option 'html_file_suffix' and I think we could use that instead to define the filenames. That option is respected by the search JavaScript using a template variable[3] in the documentation_options.js file. We should be careful of other side-effects if making that change, but it would remove a deployment transformation step on the static content, and I think that's beneficial. [1] - https://salsa.debian.org/webmaster-team/cron/-/blob/3462a061d0a67dce3761b0f4d9357c017ad0a50b/parts/7release-notes#L64-70 [2] - https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-html_file_suffix [3] - https://github.com/sphinx-doc/sphinx/blob/cf7d2759af0852d67288e58d823d51fe860749ca/sphinx/themes/basic/static/documentation_options.js_t#L6
Bug#1053549: Create a Debian theme for documentation based in Sphinx (reStructuredText)
On Sat, 13 Apr 2024 at 06:48, Holger Wansing wrote: > Am 11. April 2024 23:52:52 MESZ schrieb James Addison : > >On Sun, 7 Apr 2024 13:00:43 +0200, Holger wrote: > >> The only thing which is not working currently, is the search functionality, > >> but since that's not theme-specific I guess (please correct me, if I'm > >> wrong), I close this bug. > > > >The theme looks great, and I agree with closing this bug. However, so that > >we don't overlook another potential python3-sphinx bug: could you report the > >problem that you encountered? (I contribute to upstream and may be able to > >help with investigating that) > > It's not a bug in sphinx or something like that. > The issue was in the build process for the website, what lead to some missing > files in the manuals' tree (javascript script files and the searchindex.js). > > Everything fine for now. Ok; thank you! > I'm currently working on switching the Debian release-notes to the new theme, > and that might bring some issues, since the release-notes have translations as > well (this was not the case for the debian-policy). > > So maybe I come back to you in such case, if that's ok? I'm less knowledgeable about the translation logic than the JavaScript search functionality, however yes, feel free to include me on cc for Sphinx bugreports and I'll help if-and-when possible. James
Bug#1053549: Create a Debian theme for documentation based in Sphinx (reStructuredText)
Hi Holger, On Sun, 7 Apr 2024 13:00:43 +0200, Holger wrote: > The only thing which is not working currently, is the search functionality, > but since that's not theme-specific I guess (please correct me, if I'm > wrong), I close this bug. The theme looks great, and I agree with closing this bug. However, so that we don't overlook another potential python3-sphinx bug: could you report the problem that you encountered? (I contribute to upstream and may be able to help with investigating that) Thanks, James
Bug#1031928: [Pkg-mailman-hackers] Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error
Control: reopen -1 Hi Pierre, On Sun, 17 Mar 2024 at 22:14, Pierre-Elliott Bécue wrote: > > Considering the version of django-compressor in bookworm, I think this > bug can be closed. > > [ .. snip .. ] Unfortunately I do not believe that this problem is resolved yet; my understanding is that the issue appears when DEBUG mode is enabled, meaning that compression is _disabled_, and so the dependency on django-compressor is not directly relevant. The problem originates from some non-well-formed HTML in the hyperkitty templates. Regards, James
Bug#1064593: issue with Debian-style html theme for sphinx-based documents
Brilliant - yep, the fonts, CSS and JS now load as expected. Thank you Holger.
Bug#1026877: opari2: please make the build reproducible
Source: opari2 Followup-For: Bug #1026877 Control: forwarded -1 https://salsa.debian.org/debian/opari2/-/commit/1cc9b96544cdf1e8cbc733584b3ff1a4109b89e6 https://salsa.debian.org/debian/opari2/-/commit/15155c97944b7c17bc481ff91261d8191f81ae6f
Bug#1026877: opari2: please make the build reproducible
Source: opari2 Followup-For: Bug #1026877 Control: close -1 2.0.7-2
Bug#1064404: snapd: please make the build reproducible.
Control: forwarded -1 https://salsa.debian.org/debian/snapd/-/merge_requests/8 On Thu, 28 Mar 2024 at 16:15, Zygmunt Krynicki wrote: > > > > > Wiadomość napisana przez James Addison w dniu > > 28.03.2024, o godz. 15:51: > > > > On Thu, 28 Mar 2024 at 12:43, Zygmunt Krynicki wrote: > >> > >> Thank You for pursuing this! Please let me know when you have the patch > >> and I will gladly apply it. > >> > >> Personally I think the simple solution is fine. No need to go overboard. > > > > Ok, agreed - I'll test and then provide a patch to use a fixed offset for > > the > > timezone. > > > > Could you confirm your current preferred timezone to derive that value? > > (the > > selection should be fairly arbitrary, but I'd prefer to ask) > > > Perhaps just UTC? > > ZK Yep, that seems reasonable. Please find a merge request linked, with testing results to confirm the problem and fix in the description.
Bug#1067901: jh_installjavadoc: should not write duplicative doc-base files.
Package: javahelper Version: 0.79 Severity: normal User: reproducible-bui...@lists.alioth.debian.org Usertags: fileordering Control: affects -1 libpixels-java Dear Maintainer, I'm an occasional volunteer contributor to the Reproducible Builds[1] project, and noticed that the 'libpixels-java' package, which build-depends on javahelper (src:javatools) and uses jh_installjavadoc, failed[2] an automated build test on the Reproducible Builds test infrastructure for Debian. In particular, the /usr/share/doc-base/libpixels-java.libpixels-java file varied between a control and experimental package build. The cause seems to relate to logic that writes[3] a '$package.doc-base.javadoc' file into the 'debian' directory during build. In the case of libpixels-java, that template file is written alongside an existing 'debian/doc-base' file[4] contained in the source package. Both of the files then contain an identical doc-id statement[5], and it's unpredictable which of them will be read[6] from the directory by dh_installdocs - it depends on the ordering returned by the filesystem. If it seems like a reasonable solution to you, perhaps jh_installjavadoc could be modified so that it does not write a templated doc-base file for a package when it detects an existing doc-base file that contains the same doc-id? Thank you, James [1] - https://reproducible-builds.org/ [2] - https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/libpixels-java.html [3] - https://sources.debian.org/src/javatools/0.79/jh_installjavadoc/?hl=86#L105-L118 [4] - https://sources.debian.org/src/libpixels-java/2.1.3%2Bsvn.42-3/debian/doc-base/ [5] - https://sources.debian.org/src/libpixels-java/2.1.3%2Bsvn.42-3/debian/doc-base/#L1 [6] - https://sources.debian.org/src/debhelper/13.14.1/dh_installdocs/#L406
Bug#1064404: snapd: please make the build reproducible.
On Thu, 28 Mar 2024 at 12:43, Zygmunt Krynicki wrote: > > Thank You for pursuing this! Please let me know when you have the patch and I > will gladly apply it. > > Personally I think the simple solution is fine. No need to go overboard. Ok, agreed - I'll test and then provide a patch to use a fixed offset for the timezone. Could you confirm your current preferred timezone to derive that value? (the selection should be fairly arbitrary, but I'd prefer to ask)
Bug#1064404: snapd: please make the build reproducible.
Hi Zygmunt, On Sun, 25 Feb 2024 at 12:12, James Addison wrote: > > On Wed, 21 Feb 2024 at 15:52, Zygmunt Krynicki wrote: > > > > > > > Wiadomość napisana przez James Addison w dniu > > > 21.02.2024, o godz. 15:49: > > > > > > Source: snapd > > > Version: 2.61.1-1 > > > Severity: wishlist > > > > > > ... [snip] ... > > > > > > One cause of non-reproducibility for the package appears to be that the > > > snap.8 manual page (compressed as snap.8.gz) contains a timestamp in the > > > header that becomes timezone-localized, meaning that the Debian binary > > > packages > > > built may vary based on the timezone they're built in. > > > > > > Although one way to fix this could be to request and display a UTC > > > timestamp, > > > there's a comment[3] in the debian/rules file that hints at a better > > > solution: > > > from version 1.4.0-2 of golang-go-flags there is in-built support[4] for > > > the > > > SOURCE_DATE_EPOCH variable, a time-in-seconds since the Unix epoch > > > (interpreted > > > in UTC[5]). > > > > > > ... [ snip ] ... > > > > > > Thank you for bringing this to my attention and for offering a patch. I was > > aware of numerous TODOs in the packaging but have not yet managed to come > > up with a solution that would work both upstream and downstream (snapd CI > > system uses a copy of the debian packaging to check that a package can > > indeed be built), so any iteration on this is rather tedious. > > > > ... [ snip ] ... > > > > Thanks, Zygmunt - > https://salsa.debian.org/debian/snapd/-/merge_requests/7 contains a > minimal change that I believe should make the package reproducible on > Debian - it does not alter any build-time dependencies, and does not > affect the rules files for any other distros/releases (the debian-sid > (experimental) rules file in the packaging dir is _not_ updated). > > The change updates the packaging to remove customization of > golangs-go-flags manual-page-generation timestamping. That library > previously lacked support for reproducible build timestamping, that > was subsequently patched[1] into Debian in v1.4.0-2 and merged > upstream[2] into v1.5.0. Thanks for applying the patch - however it seems that there is a snag: although golang-go-flags does correctly read the SOURCE_DATE_EPOCH value, and fixes a build-time documentation-creation-timestamp based on that, the output manual page displays a date that is timezone-localized, and therefore may vary. In particular, if documentation is built from the source package in two different timezones, and particularly when the distance between their latitudes is significant, then a different date may be written to the header of the manual page(s). A straightforward fix could be to configure a static UTC timezone during the construction of documentation. However, there would be a small drawback to that: since the SOURCE_DATE_EPOCH value read by Debian's build processes is taken from the 'debian/changelog' file, using UTC could have the unusual effect of meaning that the date on the documentation differs from the actual current local calendar date when the maintained stamped their changelog entry. An alternative could be to parse the changelog to read the timezone of the most recent changelog entry, and use that during each build. A repeat build elsewhere in the world with the same dependencies (including same tzdata) would then parse the same timezone, localize to where the _maintainer_ was located (not to the current build host timezone), and the output date value should become identical. It's possible that that would be an overcomplicated solution but it could also be more comprehensible to maintainers themselves (thought process: 'my calendar date was X when I finished the packaging for release Y, and that is why date X exactly appears in the corresponding documentation'). I'll continue to consider the implications before offering a follow-up patch. Thank you again, James > ... [ snip ] ... > > [1] - > https://salsa.debian.org/go-team/packages/golang-go-flags/-/commit/3015faf7a972cb074e65f8c210476937698a492b > > [2] - https://github.com/jessevdk/go-flags/pull/285
Bug#1003923: soundkonverter: reproducible-builds: BuildId differences triggered by RPATH
Followup-For: Bug #1003923 Control: forwarded -1 https://salsa.debian.org/qt-kde-team/extras/soundkonverter/-/merge_requests/2 Dear Maintainer, Please find a Debian Salsa merge request, added by this message as the forwarded URL for this bug, that applies the patch from this bugreport and confirms that it reduces buildpath variance for soundkonverter. Two commits in the merge request are particularly relevant: * 099c4dcc4d038727e57b380e219d5512059a9615 - enables build-path variance testing, _without_ the patch applied; the 'reprotest' pipeline fails. * c5d0d82ff446333768b201e729773064c5fe33de - after a few false starts, correctly applies the patch; the 'reprotest' pipeline succeeds. The other commits included in the merge request are me gradually and sometimes mistakenly working towards those checkpoints. Thank you, James
Bug#1066045: maven-bundle-plugin: produces nondeterministic ordering in MANIFEST.MF headers
Followup-For: Bug #1066045 Control: forwarded -1 https://salsa.debian.org/java-team/maven-bundle-plugin/-/merge_requests/1 Control: tags -1 pending This change has recently been uploaded to DELAYED/15 by Mattia from the Reproducible Builds team after I requested that; in addition I'm providing the same change as a merge request on Salsa (adding this as the forwarded-to URL for reference, although in this case the change itself is a backport from upstream).
Bug#1003922: recastnavigation: reproducible-builds: BuildId differences triggered by RPATH
Followup-For: Bug #1003922 Control: tags -1 pending
Bug#1067850: src:kget: possible Salsa-CI reprotest misconfiguration.
Source: kget Severity: wishlist X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath Dear Maintainer, The Salsa CI configuration for kget sets customized[1] command-line options for 'reprotest'[2], a utility used to find package reproducibility problems. Unfortunately, I think that the configured SALSA_CI_REPROTEST_ARGS arguments may be incorrect; the provided arguments _appear_ intended to disable build-path variance, but I believe that they unintentionally disable _all_ forms of reprotest variance testing. Please refer to this Reproducible Builds mailing list thread for more information: https://lists.reproducible-builds.org/pipermail/rb-general/2024-February/003247.html I'd recommend removing the SALSA_CI_REPROTEST_ARGS line entirely -- which in isolation could cause Salsa-CI reprotest to fail, due to a build-path bug reported in #1003914 -- but also then applying the patch from that bugreport to confirm and solve the problem. If that is undesirable, then as an alternative I could suggest configuring: SALSA_CI_REPROTEST_ARGS: '--variations=all,-build_path' (please note that there are _two_ changes in this line; the insertion of 'all' and adjustment of 'build-path' to 'build_path') ...to enable all forms of variation, with the exception of buildpath. Thank you, James [1] - https://salsa.debian.org/qt-kde-team/kde/kget/-/blob/c3b261bd0d740cdd89c8d06e05eb238cb746fe3d/debian/salsa-ci.yml#L7 [2] - https://salsa.debian.org/reproducible-builds/reprotest
Bug#1001870: meshlab: reproducible-builds: BuildId differences triggered by RPATH
Source: meshlab Followup-For: Bug #1001870 Control: tags -1 pending
Bug#1067232: limit diffoscope recursions on packages where diffoscope runs into a timeout
Package: jenkins.debian.org Followup-For: Bug #1067232 X-Debbugs-Cc: hol...@layer-acht.org On Wed, 20 Mar 2024 16:05:30 +, Holger wrote: > or maybe even simpler: first run diffoscope normally, then if that runs into > a timeout, > run with --max-container-depth=3 (or 5). I think this would be acceptable with > only 286 suite/arch/package combinations currently which run into a timeout. That seems like a straightforward way to get started, and without adding much complexity. In reproducible_build.sh it looks like there are some IRC notifications: it could make sense to suppress the retried-diffoscope-results, or emit a noticably different message for those to distinguish them from the initial attempt?
Bug#1064028: libpython3.12-dev: non-C90 headerfile code breaks -Werror=declaration-after-statement
Followup-For: Bug #1064028 Control: tags -1 fixed-upstream Control: forwarded -1 https://github.com/python/cpython/issues/116869 https://github.com/python/cpython/pull/117011
Bug#1066092: koko: please enable blhc-recommended build hardening.
Source: koko Followup-For: Bug #1066092 X-Debbugs-Cc: marco.matti...@hotmail.it Control: tags -1 - fixed pending Control: reassign -1 blhc Control: severity -1 normal Control: merge -1 1043522 Control: tags -1 fixed-upstream Hi Marco, On Sat, 16 Mar 2024 22:50:05 +0100, Marco wrote: > I believe this is not a bug in koko: can you please check the build log > against blhc 0.14 (not yet in Debian)? Background is [1]. Thank you! You're absolutely correct. I rebuilt koko and ran both blhc 0.13 (from Debian) and also blhc 0.14 (from upstream) against the output of the dpkg-buildpackage build logs from that, and the results were: * blhc 0.13 produced the error messages reported here and 8 as exit code. * blhc 0.14 produced no output and 0 as exit code. Reassigning and merging with bug #1043522 - thanks again. James
Bug#1064028: libpython3.12-dev: non-C90 headerfile code breaks -Werror=declaration-after-statement
Followup-For: Bug #1064028 X-Debbugs-Cc: d...@debian.org Control: forwarded -1 https://github.com/python/cpython/issues/116869 It seemed worth forwarding this bugreport upstream, since it may be a quick fix there (initially I felt that it may be worth handling in Debian initially and then forwarding; perhaps not, though). Alternatively we may learn that C90 is no-longer a code style baseline for cpython, and in that case we can adjust accordingly.
Bug#1064028: libpython3.12-dev: non-C90 headerfile code breaks -Werror=declaration-after-statement
Package: libpython3.12-dev Followup-For: Bug #1064028 X-Debbugs-Cc: d...@debian.org Control: reopen -1 Control: found -1 3.12.1-2 Hello, On Sun, 3 Mar 2024 10:35:42 +0100, Matthias wrote: > That was fixed in the upstream 3.12.2 release. The problem does not appear to be resolved; building onboard/1.4.1-5 using the headerfiles from libpython3.12-dev/3.12.2-1 continues to fail. x86_64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -g -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -g -fwrapv -O2 -g -O2 -ffile-prefix-map=/root/onboard-1.4.1=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DMAJOR_VERSION=0 -DMINOR_VERSION=4 -DMICRO_VERSION=0 -I/usr/include/blkid -I/usr/include/cairo -I/usr/include/cloudproviders -I/usr/include/dconf -I/usr/include/freetype2 -I/usr/include/fribidi -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0 -I/usr/include/glib-2.0 -I/usr/include/gtk-3.0 -I/usr/include/harfbuzz -I/usr/include/hunspell -I/usr/include/libmount -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/webp -I/usr/include/x86_64-linux-gnu -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/python3.12 -c Onboard/osk/osk_audio.c -o build/temp.linux-x86_64-cpython-312/Onboard/osk/osk_audio.o -Wsign-compare -Wdeclaration-after-statement -Werror=declaration-after-statement In file included from /usr/include/python3.12/Python.h:44, from Onboard/osk/osk_module.h:25, from Onboard/osk/osk_audio.c:21: /usr/include/python3.12/object.h: In function ‘Py_SIZE’: /usr/include/python3.12/object.h:233:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] 233 | PyVarObject *var_ob = _PyVarObject_CAST(ob); | ^~~ Thanks, James
Bug#1064593: debian-policy: missing static resources for www.debian.org policy page
Package: debian-policy Followup-For: Bug #1064593 X-Debbugs-Cc: hwans...@mailbox.org, stephane.blon...@gmail.com, spwhit...@spwhitton.name Hello, On Tue, 12 Mar 2024 22:53:54 +0100, Holger wrote: > Stéphane Blondon wrote (Mon, 4 Mar 2024 08:29:10 > +0100): > [...snip...] > > The symlink is relative so it could be broken. > > It appears to me that the target for that symlink > (../../../../../sphinx_rtd_theme/static/css/theme.css) is not existing > and therefore we get an empty file. I'm not much of a perlmonger but this might be a problem somewhere in: https://sources.debian.org/src/sphinx/7.2.6-5/debian/dh-sphinxdoc/dh_sphinxdoc/?hl=409#L389-L413 When I modify that code to always follow the 'absolute link' path, I still get relative links to the theme.css file in the debian/ package build dirs. (note: this function also exists in imagemagick-6-doc, so any problem/fix should not forget about that package too) > I did some testing with debuild, and changed debian/rules (line 4) like > > - dh $@ --with sphinxdoc > + dh $@ I don't think we should do this, if at all possible. The dh-sphinxdoc helper seems to handle a bunch of privacy and packaging-related fixups (#781849 for example), and removing it could cause unexpected regressions elsewhere. Regards, James
Bug#1066016: python-rdflib-doc: please make the build reproducible.
Package: python-rdflib-doc Followup-For: Bug #1066016 X-Debbugs-Cc: cru...@debian.org Hi Michael, Thank you for merging and uploading this change. Unfortunately it seems that my suggestion didn't solve the problem (based on inspecting the results of a recent reprotest[1] on Salsa - there's still a '' with randomness in the built documentation). That's my mistake for not testing the patch thoroughly enough. Please let me know how to proceed (for example, whether you'd prefer that I revert the change). This also means that the autodoc config setting may be more limited in solving these kind of problems that I realized; I'll have to check some merge requests that I have open for other packages. Thank you, James [1] - https://salsa.debian.org/python-team/packages/rdflib/-/jobs/5445372
Bug#1037277:
severity -1 wishlist thanks Dear Maintainer, Because Debian builds packages from a fixed build path, neither the 'reprotest' utility in Salsa-CI, nor the Reproducible Builds team's package test infrastructure for Debian[1] currently check for equivalent binary package output from differing source package build paths. This means that your package will pass current reproducibility tests; however we believe that source code and/or build steps still embed the build path into the binary package output, making it more difficult than necessary for independent consumers to check the integrity of binary packages by recompiling them themselves. As a result, this bugreport will remain open and be re-assigned the 'wishlist' severity[2]. For more information about build paths and how they can affect reproducibility, please refer to: https://reproducible-builds.org/docs/build-path/ Thanks, James [1] - https://tests.reproducible-builds.org/debian/reproducible.html [2] - https://www.debian.org/Bugs/Developer#severities
Bug#1066092: koko: please enable blhc-recommended build hardening.
Source: koko Version: 23.08.3+ds.1-2 Severity: wishlist Dear Maintainer, During filing of #1066088, some build failures of the 'blhc'[1] test utility occurred on Salsa-CI[2]. These indicate that some compile-time security hardening flags may not be enabled when the binary package is compiled (the first failure mentioned in the logs relates to missing CPPFLAGS). The Debian Wiki page[3] about package hardening includes some information relating to packages that use CMake, and this could be worth checking for guidance. Thanks, James [1] - https://eriberto.pro.br/blog/2015/09/07/debian-how-to-use-blhc-to-solve-hardening-issues-when-packaging/ [2] - https://salsa.debian.org/jayaddison/koko/-/jobs/5435672 [3] - https://wiki.debian.org/Hardening#Notes_for_packages_using_CMake
Bug#1066088: koko-data: please make the build reproducible.
Package: koko-data
Severity: wishlist
Tags: patch upstream
X-Debbugs-Cc:
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
Dear Maintainer,
I'm an occasional volunteer contributor to the Reproducible Builds[1] project,
and noticed recently that the koko-data package failed some automated Debian
package reproducibility tests[2][3].
It looks like the cause of the non-reproducibility is that a zipfile extracted
by libarchive (as used internally by cmake) during the build is output with a
differing mtime based on the timezone that the build occurs in, since zipfiles
are written with file modification times based on the local system they were
created on. Some discussion of this behaviour can be found[4] on the
libarchive bugtracker.
Please find attached a patch to temporarily use a fixed (UTC) timezone during
the relevant unzip step of the build process; I've confirmed that this results
in a fixed output mtime for the cities1000.txt file when building in different
timezones using dpkg-buildpackage on trixie. I'll also offer this as a merge
request on Salsa.
Thank you,
James
[1] - https://reproducible-builds.org
[2] -
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/diffoscope-results/koko.html
[3] - https://salsa.debian.org/DebianOnMobile-team/koko/-/jobs/5423718
[4] - https://github.com/libarchive/libarchive/issues/945
From: James Addison
Date: Tue, 12 Mar 2024 11:37:43 +
Subject: unzip the cities1000.zip file using a fixed timezone
Zipfiles are not timezone-aware; that is, files are typically written to a zip
archive with modification-times that are determined from the local system time.
.
That means that extracting the same zipfile in two different timezones may
produce different output file modification-times. This occurs when libarchive
(as used by cmake) extracts the cities1000.zip file when building this package.
.
To build the package reproducibly, this patch temporarily configures a fixed
timezone of UTC during extraction of the cities1000.zip zipfile.
.
Ref: https://github.com/libarchive/libarchive/issues/945
---
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -145,7 +145,7 @@ if (NOT EXISTS ${CMAKE_CURRENT_BINARY_DIR}/cities1000.zip)
endif()
execute_process(
-COMMAND ${CMAKE_COMMAND} -E tar -xzf
${CMAKE_CURRENT_BINARY_DIR}/cities1000.zip
+COMMAND env TZ=UTC ${CMAKE_COMMAND} -E tar -xzf
${CMAKE_CURRENT_BINARY_DIR}/cities1000.zip
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
Bug#1066083: gnome-maps: please make the build reproducible
Source: gnome-maps Followup-For: Bug #1066083 X-Debbugs-Cc: la...@debian.org Please note: for some other GNOME appdata.xml files, upstream has preferred to remove dynamic Meson release @date values entirely, which also achieves reproducibility; that approach might be simpler and perhaps more aligned with upstream. Ref: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4077
Bug#1066045: maven-bundle-plugin: produces nondeterministic ordering in MANIFEST.MF headers
Package: libmaven-bundle-plugin-java
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain
Dear Maintainer,
The maven-bundle-plugin utility creates Java .jar archives that contain
non-deterministic contents in the Export-Package, Private-Package and
Include-Resource header fields of the MANIFEST.MF file when listing those files
from the underlying filesystem returns them in differing order.
There is an exisiting report[1] of this problem upstream in the Apache Felix
project, and it has been resolved by a subsequent change[2] to sort the
contents of the relevant field values before they're written to the manifest.
Please find attached a backport of the upstream changeset, which applies
cleanly to the maven-bundle-plugin-3.5.1 sources.
Thank you,
James
[1] - https://issues.apache.org/jira/browse/FELIX-6602
[2] - https://github.com/apache/felix-dev/pull/208
>From d885d99a6a16660f655a4fd18e8a1a39beef0a15 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Herv=C3=A9=20Boutemy?=
Date: Sat, 25 Mar 2023 00:18:11 +0100
Subject: [PATCH] FELIX-6602 sort resources and exported packages
---
.../java/org/apache/felix/bundleplugin/BundlePlugin.java | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/src/main/java/org/apache/felix/bundleplugin/BundlePlugin.java
+++ b/src/main/java/org/apache/felix/bundleplugin/BundlePlugin.java
@@ -1938,6 +1938,7 @@ public class BundlePlugin extends AbstractMojo
scanner.scan();
String[] paths = scanner.getIncludedFiles();
+Arrays.sort( paths );
for ( int i = 0; i < paths.length; i++ )
{
packages.put( analyzer.getPackageRef( getPackageName( paths[i]
) ) );
@@ -2076,7 +2077,9 @@ public class BundlePlugin extends AbstractMojo
scanner.addDefaultExcludes();
scanner.scan();
-List includedFiles = Arrays.asList(
scanner.getIncludedFiles() );
+String[] f = scanner.getIncludedFiles();
+Arrays.sort( f );
+List includedFiles = Arrays.asList( f );
for ( Iterator j = includedFiles.iterator();
j.hasNext(); )
{
--
2.43.0
Bug#1064475: lists.debian.org: missing recent posts in search indices.
Hi Olly, On Sun, 10 Mar 2024 at 20:42, Olly Betts wrote: > > [ ... snip ... ] > There are currently 7 shards in the lists database, but only the first 6 > were listed to be searched. It looks like indexing is working fine, > except it started a new shard and failed to update the list to search. > > I've manually fixed this and now the search above gives me a top result > of: > > Testing removal summary 2024-03-10 (Sunday) Thank you very much! The search results now look much better to me too. Regards, James
Bug#1066017: xonsh-doc: please make the build reproducible.
Followup-For: Bug #1066017 Control: forwarded -1 https://salsa.debian.org/python-team/packages/xonsh/-/merge_requests/3
Bug#1066016: python-rdflib-doc: please make the build reproducible.
Followup-For: Bug #1066016 Control: forwarded -1 https://salsa.debian.org/python-team/packages/rdflib/-/merge_requests/2
Bug#1066014: python-pathos-doc: please make the build reproducible.
Followup-For: Bug #1066014 Control: forwarded -1 https://salsa.debian.org/python-team/packages/pathos/-/merge_requests/1
Bug#1066015: patroni-doc: please make the build reproducible.
Package: patroni-doc Followup-For: Bug #1066015 Control: tags -1 - patch (clearing unintentionally-included patch tag)
Bug#1066017: xonsh-doc: please make the build reproducible.
Package: xonsh-doc Severity: wishlist Tags: patch upstream User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness Dear Maintainer, I'm an occasional volunteer contributor with the Reproducible Builds[1] project, and noticed recently that the xonsh-doc package failed[2] an automated reproducibility test on Debian. >From investigation, it seems that most (but not all) of the cause of non-reproducibility during the test was due to the Sphinx autodoc extension evaluating some of the default Python method values (like xonsh.environ.HOSTNAME[3]) at build-time and including the GeneralSetting object address, which varied, in the documentation. As a workaround, we can enable the 'autodoc_preserve_defaults'[4] configuration setting, meaning that Sphinx will render the method signature defaults using the original source code as-written, instead of evaluating the corresponding values. I'll offer a merge request on Salsa to make that change, and will link that to this bugreport. Thanks, James [1] - https://reproducible-builds.org/ [2] - https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/xonsh.html [3] - https://sources.debian.org/src/xonsh/0.14.4%2Bdfsg-1/docs/conf.py/#L317-L320 https://sources.debian.org/src/xonsh/0.14.4%2Bdfsg-1/xonsh/environ.py/#L873-L877 [4] - https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html#confval-autodoc_preserve_defaults
Bug#1066016: python-rdflib-doc: please make the build reproducible.
Package: python-rdflib-doc Severity: wishlist Tags: patch upstream User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness Dear Maintainer, I'm an occasional volunteer contributor with the Reproducible Builds[1] project, and noticed recently that the python-rdflib-doc package failed[2] an automated reproducibility test on Debian. >From investigation, it seems that most if not all of the cause of non-reproducibility during the test was due to the Sphinx autodoc extension evaluating some of the default Python method values (like rdflib.extras.infixowl.Individual.factoryGraph[3]) at build-time and including theevaluated value, which varied, in the documentation. As a workaround, we can enable the 'autodoc_preserve_defaults'[4] configuration setting, meaning that Sphinx will render the method signature defaults using the original source code as-written, instead of evaluating the corresponding values. I'll offer a merge request on Salsa to make that change, and will link that to this bugreport. Thanks, James [1] - https://reproducible-builds.org/ [2] - https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/diffoscope-results/rdflib.html [3] - https://sources.debian.org/src/rdflib/6.1.1-3/docs/conf.py/#L41 https://sources.debian.org/src/rdflib/6.1.1-3/rdflib/extras/infixowl.py/#L371 [4] - https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html#confval-autodoc_preserve_defaults
Bug#1066015: patroni-doc: please make the build reproducible.
Package: patroni-doc Severity: wishlist Tags: patch upstream User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness Dear Maintainer, I'm an occasional volunteer contributor with the Reproducible Builds[1] project, and noticed recently that the patroni-doc package failed[2] an automated reproducibility test on Debian. >From investigation, it seems that most if not all of the cause of non-reproducibility during the test was due to the Sphinx autodoc extension evaluating some of the default Python method values (like wal_log_hints[3]) at build-time and including the evaluated value, which varied, in the documentation. As a workaround, we can enable the 'autodoc_preserve_defaults'[4] configuration setting, meaning that Sphinx will render the method signature defaults using the original source code as-written, instead of evaluating the corresponding values. Thanks, James [1] - https://reproducible-builds.org/ [2] - https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/diffoscope-results/patroni.html [3] - https://sources.debian.org/src/patroni/3.2.2-2/patroni/postgresql/config.py/#L303 [4] - https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html#confval-autodoc_preserve_defaults
Bug#1066014: python-pathos-doc: please make the build reproducible.
Package: python-pathos-doc Severity: wishlist Tags: patch upstream User: reproducible-bui...@lists.alioth.debian.org Usertags: cpu Dear Maintainer, I'm an occasional volunteer contributor with the Reproducible Builds[1] project, and noticed recently that the python-pathos-doc package failed[2] an automated reproducibility test on Debian. >From investigation, it seems that most if not all of the cause of non-reproducibility during the test was due to the Sphinx autodoc extension evaluating some of the default Python method values (like mp.pool_size[3]) at build-time and including the evaluated value, which varied, in the documentation. As a workaround, we can enable the 'autodoc_preserve_defaults'[4] configuration setting, meaning that Sphinx will render the method signature defaults using the original source code as-written, instead of evaluating the corresponding values. I'll offer a merge request on Salsa to make that change, and will link that to this bugreport. Thanks, James [1] - https://reproducible-builds.org/ [2] - https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/pathos.html [3] - https://sources.debian.org/src/pathos/0.3.2-1/docs/source/pathos.rst/#L55 https://sources.debian.org/src/multiprocess/0.70.16-2/py3.11/multiprocess/pool.py/#L277 [4] - https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html#confval-autodoc_preserve_defaults
Bug#984845: sofia-sip: reproducible builds: Embeds build path in binaries
Source: sofia-sip Followup-For: Bug #984845 X-Debbugs-Cc: vagr...@reproducible-builds.org Control: reopen -1 Control: severity -1 wishlist Dear Maintainer, Because Debian builds packages from a fixed build path, customized build paths are _not_ currently evaluated by the 'reprotest' utility in Salsa-CI, or during package builds on the Reproducible Builds team's package test infrastructure for Debian[1]. This means that this package will pass current reproducibility tests; however we still believe that source code and/or build steps embed the build path into binary package output, making it more difficult that necessary for independent consumers to confirm whether their local compilations produce identical binary artifacts. As a result, this bugreport will remain open and be assigned the 'wishlist' severity[2]. Regards, James [1] - https://tests.reproducible-builds.org/debian/reproducible.html [2] - https://www.debian.org/Bugs/Developer#severities
Bug#984845: sofia-sip: reproducible builds: Embeds build path in binaries
Source: sofia-sip Followup-For: Bug #984845 X-Debbugs-Cc: vagr...@reproducible-builds.org Control: notfixed -1 1.12.11+20110422.1-2.2 On Sun, 10 Mar 2024 13:22:13 +, I wrote: > The sofia-sip package now appears to build reproducibly[1], so I believe that > this bugreport can be closed. An upgrade[2] of debhelper appears to have > solved the causes of build-path-related variance. After re-considering this: I'm not so confident that the debhelper upgrade solved the problem after all; or indeed that the version indicated when I closed the bugreport is fixed. I'll try to confirm exactly what the status is for this package soon.
Bug#985187: ffmpeg: reproducible builds: Embeds build path in binaries generated with cl2c
Source: ffmpeg Followup-For: Bug #985187 X-Debbugs-Cc: vagr...@reproducible-builds.org Control: fixed -1 7:6.1-1 Control: close -1 This package is not yet building reproducibly[1], but the build-path embed correctly identified by this bugreport as a contributing factor has been removed[2] from ffmpeg v6.1 onwards and no longer adds variance to built packages. [1] - https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ffmpeg.html [2] - https://git.ffmpeg.org/gitweb/ffmpeg.git/blobdiff/7cfd7e4af4b1c0f280f0c64a8088d362a2917e79:/tools/cl2c..88e2cca3dbd1f509982778804ba2463058bb729a:/tools/source2c
Bug#984845: sofia-sip: reproducible builds: Embeds build path in binaries
Source: sofia-sip Followup-For: Bug #984845 X-Debbugs-Cc: vagr...@reproducible-builds.org Control: fixed -1 1.12.11+20110422.1-2.2 Control: close -1 The sofia-sip package now appears to build reproducibly[1], so I believe that this bugreport can be closed. An upgrade[2] of debhelper appears to have solved the causes of build-path-related variance. [1] - https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sofia-sip.html [2] - https://salsa.debian.org/pkg-voip-team/sofia-sip/-/commit/4e44c63a722425e074183b20dcfdd17b71b06d36
Bug#1064575: python-pyswarms-doc: please make the build reproducible.
Followup-For: Bug #1064575 Control: forwarded -1 https://salsa.debian.org/science-team/pyswarms/-/merge_requests/2 Adding the suggested patch for this package (providing custom alt text for the relevant animations) as a forwarded-link from this bugreport to Salsa. On Mon, 26 Feb 2024 01:09:59 +, I wrote: > However: I'm not yet sure about the implicit contracts/conventions are between > these components (nbsphinx, docutils), so I may need to investigate/discuss > further. The mentioned additional investigation/discussion can be found at: * nbsphinx: https://github.com/spatialaudio/nbsphinx/pull/438 * docutils: https://sourceforge.net/p/docutils/mailman/message/58746996/ (these are not directly related to the suggested localized fix for python-pyswarms-doc, but are included for context about the root cause)
Bug#1064475: lists.debian.org: missing recent posts in search indices.
Package: lists.debian.org Followup-For: Bug #1064475 X-Debbugs-Cc: c...@debian.org Hi Cord, Running a search for 'python removal' on the 'testing-changes' mailing list, ordered by most-recent-first, currently lacks any results from this year. https://lists.debian.org/cgi-bin/search?P=python+removal=and=Gdebian-testing-changes=0=100=python%09removal=Gdebian-testing-changes%7E.%7E%7E0 The most recent item that appears is: "Testing removal summary 2023-02-04 (Saturday) Debian testing watch" And an example item that I would expect to see included is: https://lists.debian.org/debian-testing-changes/2024/02/msg00054.html Regards, James
Bug#1064891: pytest-repeat: please make the build reproducible
Source: pytest-repeat Followup-For: Bug #1064891 Control: forwarded -1 https://salsa.debian.org/python-team/packages/pytest-repeat/-/commit/3ef7a0e17d6691fd2afbd845ee28d814e3bd0bcf Control: tags -1 - patch Control: tags -1 pending
Bug#1064895: python3-sepolicy: please make the package build reproducible.
Package: python3-sepolicy Followup-For: Bug #1064895 Control: tags -1 pending
Bug#1064894: python3-selinux: please make the package build reproducible.
Package: python3-selinux Followup-For: Bug #1064894 Control: tags -1 pending
Bug#1042955: zzzeeksphinx: please make the output reproducible
Source: zzzeeksphinx Followup-For: Bug #1042955 X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Control: tags -1 fixed-upstream The patch from this bugreport has been forwarded and accepted (with modifications) into the upstream zzzeeksphinx theme, and is included in the v1.5.0 release.
Bug#1065124: python3-matplotlib: produces nondeterministic SVG plot output
Package: python3-matplotlib Severity: minor Tags: upstream Control: forwarded -1 https://github.com/matplotlib/matplotlib/issues/27831 Control: block 1064858 by -1 Dear Maintainer, When a matplotlib plot contains non-rectangular clipping paths, saving the plot in SVG format produces nondeterministic output due to use of Python's built-in 'id(...)' function as input[1] to the generation of id attributes for the corresponding SVG elements. I became aware of this problem during investigation of #1064858 and have reported the issue upstream to matplotlib. Regards, James [1] - https://sources.debian.org/src/matplotlib/3.6.3-1/lib/matplotlib/backends/backend_svg.py/#L622
Bug#1064858: python-astroplan-doc: please make the package build reproducible.
Followup-For: Bug #1064858 On Mon, 26 Feb 2024 21:53:13 +, I wrote: > Merge request opened; it appears that there is one more reproducibiliy issue > remaining in the SVG output from matplotlib: the ID generation scheme for > some clipPath elements varies between builds. Some further investigation of > this is required. The remaining SVG-diagram non-reproducibility problem has been confirmed[1] by upstream matplotlib as a bug - once a fix is available for that (and once that reaches Debian), this should be resolvable. [1] - https://github.com/matplotlib/matplotlib/issues/27831
Bug#1057442: onboard ftbfs with Python 3.12
Followup-For: Bug #1057442 X-Debbugs-Cc: tsu.y...@gmail.com Hi Bo, On Wed, 6 Dec 2023 17:31:52 +0800, Bo wrote: > I think it is okay to remove `-Wdeclaration-after-statement` option > which to support Arch linux build from code comment. FYI: I've reported #1064028 against Python3.12 to suggest fixing the cause of this (the non-C90-compliant code in Python3.12 headers). I'm intentionally not making it a blocker here, because other approaches are possible, but am mentioning it for awareness. Regards, James
Bug#1064648: allegro5-doc: please make the build reproducible.
Followup-For: Bug #1064648 X-Debbugs-Cc: gus...@debian.org Hi Andreas - thanks for investigating! > https://github.com/gusnan/allegro5/commit/e4369e13b1edb96b8ae4821c5363ac7b61002d3e Looks good - I noticed you fixed the typo already :) > https://github.com/gusnan/allegro5/commit/842af9e5d6cd9c8fd0d0d2f8095f872e7bd77cef Yep, also looks good to me. > Nah, my mistake, that didn't seem to fix the reproducibility - The > SOURCE_DATE_EPOCH stuff seems to work, but the other one needs more > work. Huh, strange - what differences do you find? Two doc packages that I built a few moments ago using reprotest here are identical -- although I did have time variance disabled during that test. James
Bug#1064895: python3-sepolicy: please make the package build reproducible.
Package: python3-sepolicy Severity: wishlist Tags: patch Control: forwarded -1 https://salsa.debian.org/selinux-team/selinux-python/-/merge_requests/3 User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath Dear Maintainer, I'm an occasional volunteer contributor to the Reproducible Builds[1] project, and, based on the current contents[2] of the python3-sepolicy package in Debian trixie, particularly the presence of a direct_url.json file, I believe that it would fail a reprotest reproducibility build test on Salsa. The expected cause of difference in the built python3-sepolicy .deb files is a build-path from the reprotest comparison builds; this is written into the Python direct_url.json file. For flit-based Pyton packages we automatically remove[3] that file, and I believe that we can do that safely here too. I've provided a merge request[4] to suggest that change. Thanks, James [1] - https://reproducible-builds.org/ [2] - https://packages.debian.org/trixie/all/python3-sepolicy/filelist [3] - https://salsa.debian.org/python-team/tools/dh-python/-/commit/2ef6ff13748984258d5da000c17d9cdad707b9ae [4] - https://salsa.debian.org/selinux-team/selinux-python/-/merge_requests/3
Bug#1064894: python3-selinux: please make the package build reproducible.
Package: python3-selinux Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath Control: forwarded -1 https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/10 Dear Maintainer, I'm an occasional volunteer contributor to the Reproducible Builds[1] project, and noticed recently that the python3-selinux package failed[2] an automated reprotest reproducibility build test on Salsa. The cause of the differences in the built python3-selinux .deb files is that a build-path from the reprotest comparison builds was included in a Python direct_url.json file. For flit-based Pyton packages we automatically remove[3] that file, and I believe that we can do that safely here too. I've provided a merge request[4] to suggest that change. Thanks, James [1] - https://reproducible-builds.org/ [2] - https://salsa.debian.org/vorlon/libselinux/-/jobs/5317763 [3] - https://salsa.debian.org/python-team/tools/dh-python/-/commit/2ef6ff13748984258d5da000c17d9cdad707b9ae [4] - https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/10
Bug#1064891: pytest-repeat: please make the build reproducible
Source: pytest-repeat Followup-For: Bug #1064891 X-Debbugs-Cc: la...@debian.org Hi Chris, I'd neglected to file a bugreport for this, so my mistake here: I'd provided a merge request[1] to fix this same reproducibility issue. The approach I took was slightly different, removing the PYBUILD_BEFORE_TEST export entirely. Yours is more cautious, and I have to admit that after inspection, my change does also introduce a small change in the package content (the resulting package has no egg-info/entry_points.txt file, although it does have a dist-info/entry_points.txt). I'm OK with either approach. In future I'll try to make sure to file bugreports ahead-of-time to reduce patch-provision race conditions :) Regards, James [1] - https://salsa.debian.org/python-team/packages/pytest-repeat/-/merge_requests/1
Bug#1064858: python-astroplan-doc: please make the package build reproducible.
Followup-For: Bug #1064858 Control: forwarded -1 https://salsa.debian.org/debian-astro-team/astroplan/-/merge_requests/2 Merge request opened; it appears that there is one more reproducibiliy issue remaining in the SVG output from matplotlib: the ID generation scheme for some clipPath elements varies between builds. Some further investigation of this is required.
Bug#1064858: python-astroplan-doc: please make the package build reproducible.
Package: python-astroplan-doc Severity: wishlist User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps randomness Dear Maintainer, I'm an occasional volunteer contributor to the Reproducible Builds[1] project, and noticed recently that the python-astroplan-doc package failed[2] an automated Debian package reproducibility test. There appear to be two causes of non-reproducibility: * Unless instructed otherwise, the Sphinx autodoc extension evaluates the default values of Python method signature arguments. In the case of astroplan, that produces timing information that is relative to the build-time of the project (such as the value of '_current_year_time_range' in the arguments to 'months_observable'[3]). * The astroplan docs include build-time-generated matplotlib diagrams in SVG format. By default, matplotlib uses[4] a randomly-generated UUID4 scheme to add a salt when creating the path IDs in those SVG files, meaning that the resulting documentation varies on each build. I can suggest two corresponding resolutions to make the documentation build reproducibly: * We can use the 'autodoc_preserve_defaults' configuration option[5] in the autodoc extension to include the source code text of each argument default, instead of the build-time values they evaluate to. * We can configure the matplotlib 'svg.hashsalt' option[6]. This can be configured on a per-diagram basis, or globally using a matplotlibrc file. In this case, I recommend the latter because this should mean that we do not have to modify the source package, only the Debian packaging. I'll provide a merge request on Salsa with these suggestions and will link that to the bugreport here. Regards, James [1] - https://reproducible-builds.org [2] - https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/diffoscope-results/astroplan.html [3] - https://salsa.debian.org/debian-astro-team/astroplan/-/blob/ffea5b68f3f4e682b0226a11b24df9c7ef56ff2c/astroplan/constraints.py#L1094-1096 [4] - https://sources.debian.org/src/matplotlib/3.6.3-1/lib/matplotlib/backends/backend_svg.py/#L497-L498 [5] - https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html#confval-autodoc_preserve_defaults [6] - https://matplotlib.org/stable/users/explain/customizing.html?highlight=svg.hashsalt#matplotlibrc-sample
Bug#1064575: python-pyswarms-doc: please make the build reproducible.
Followup-For: Bug #1064575 On Mon, 26 Feb 2024 00:22:44 +, I wrote: > On Sat, 24 Feb 2024 12:33:50 +, I wrote: > > Part of the documentation rendering process - I have not determined exactly > > what yet - adds an 'alt' attribute when it does not exist, and generates a > > randomized hex string to use as the value of the attribute. This causes the > > resulting python-pyswarms-doc package to vary on each build. > > Part of the reason for this appears to be the nbsphinx component; when it > encounters HTML elements, it emits reStructuredText markdown containing > an alt attribute if one was found on the element, and defines an rST > substitution[1] named by a UUID4-generated value converted to hexadecimal. > > Next question: where is that substitution name used when the ':alt:' option > is not found on the image directive? The answer is that the alt attribute/option is created by docutils here: https://sources.debian.org/src/python-docutils/0.20.1%2Bdfsg-3/docutils/parsers/rst/states.py/#L2689-L2690 ...and that is only relevant when an existing alt attribute is _not_ found from the node here: https://sources.debian.org/src/python-docutils/0.20.1%2Bdfsg-3/docutils/writers/_html_base.py/#L1084 The reason I'd like to know this is to determine the feasibility of a fix that would apply across multiple buildsites (not only python-pyswarms-doc). A naive fix idea would be to modify nbsphinx to emit an empty-string alt option in cases where no existing alt attribute was found on the HTML element. However: I'm not yet sure about the implicit contracts/conventions are between these components (nbsphinx, docutils), so I may need to investigate/discuss further.
Bug#1064575: python-pyswarms-doc: please make the build reproducible.
Followup-For: Bug #1064575 On Sat, 24 Feb 2024 12:33:50 +, I wrote: > Part of the documentation rendering process - I have not determined exactly > what yet - adds an 'alt' attribute when it does not exist, and generates a > randomized hex string to use as the value of the attribute. This causes the > resulting python-pyswarms-doc package to vary on each build. Part of the reason for this appears to be the nbsphinx component; when it encounters HTML elements, it emits reStructuredText markdown containing an alt attribute if one was found on the element, and defines an rST substitution[1] named by a UUID4-generated value converted to hexadecimal. Next question: where is that substitution name used when the ':alt:' option is not found on the image directive? [1] - https://sources.debian.org/src/nbsphinx/0.8.11%2Bds-1/src/nbsphinx.py/#L1398-L1399
Bug#1064782: bind9-doc: please output tags in the documentation in deterministic order.
Package: bind9-doc
Version: 1:9.19.21-1
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
Dear Maintainer,
I'm an occasional volunteer contributor to the Reproducible Builds[1] project,
and noticed recently that the bind9-doc package failed[2] an automated Debian
package build test.
>From inspecting the differences in the generated documentation, it appears that
some tag annotations (example[3]) in the source documentation are de-duplicated
in a non-deterministic manner during Sphinx documentation builds.
The cause is that the de-duplication is performed using a non-order-preserving
Python set[4] object, meaning that the resulting output documentation package
can vary at build-time.
Please find attached a patch that implements order-preserving de-duplication
of these tags. I've confirmed that the package compiles with it applied, and
believe that it should produce deterministic tag output in the built package.
Regards,
James
[1] - https://reproducible-builds.org/
[2] -
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/bind9.html
[3] -
https://sources.debian.org/src/bind9/1%3A9.18.19-1~deb12u1/doc/arm/reference.rst/#L5648
[4] - https://docs.python.org/3/library/stdtypes.html#set-types-set-frozenset
diff --git a/doc/arm/_ext/iscconf.py b/doc/arm/_ext/iscconf.py
index b5bd966e2..0b96d7bd3 100644
--- a/doc/arm/_ext/iscconf.py
+++ b/doc/arm/_ext/iscconf.py
@@ -41,12 +41,18 @@ logger = logging.getLogger(__name__)
def split_csv(argument, required):
argument = argument or ""
-outlist = list(filter(len, (s.strip() for s in argument.split(","
-if required and not outlist:
+values = list(filter(len, (s.strip() for s in argument.split(","
+if required and not values:
raise ValueError(
"a non-empty list required; provide at least one value or remove"
" this option"
)
+# Order-preserving de-duplication
+outlist, seen = list(), set()
+for value in values:
+if value not in seen:
+seen.add(value)
+outlist.append(value)
return outlist
@@ -73,10 +79,8 @@ def domain_factory(domainname, domainlabel, todolist,
grammar):
def run(self):
placeholder = todolist("")
-placeholder["isc_filter_tags"] =
set(self.options.get("filter_tags", []))
-placeholder["isc_filter_blocks"] = set(
-self.options.get("filter_blocks", [])
-)
+placeholder["isc_filter_tags"] = self.options.get("filter_tags",
[])
+placeholder["isc_filter_blocks"] =
self.options.get("filter_blocks", [])
return [placeholder]
class ISCConfDomain(Domain):
@@ -127,7 +131,7 @@ def domain_factory(domainname, domainlabel, todolist,
grammar):
@property
def isc_tags(self):
-return set(self.options.get("tags", []))
+return self.options.get("tags", [])
@property
def isc_short(self):
Bug#1064648: allegro5-doc: please make the build reproducible.
Followup-For: Bug #1064648 My apologies - I meant to include a link to the doc-generator comparison function that lacks an equal-popularity sort tiebreaker. It can be found at: https://sources.debian.org/src/allegro5/2%3A5.2.9.1%2Bdfsg-1/docs/scripts/scan_examples.c/#L59-L61
Bug#1064648: allegro5-doc: please make the build reproducible.
Source: allegro5 Version: 2:5.2.9.1+dfsg-1 Severity: wishlist Tags: upstream User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps fileordering Dear Maintainer, I'm an occasional volunteer contributor to the Reproducible Builds[1] project, and noticed recently that your package allegro5-doc failed an automated Debian package build reproducibility test[2]. There appear to be two problems that contribute to the non-reproducibility: * The 'Last updated' message on each page does not use the SOURCE_DATE_EPOCH build timestamp (you can find documentation and C code to use it here[3]). * When sorting example documents to reference alongside functions, the documentation generation code selects the top-three most popular pages to cross-reference, but it does not have a tie-breaker in the case of equally popular pages. This means that the ordering of those examples may vary between builds, depending on the order in which the files are discovered from the filesystem. For the latter case, it might be acceptable to use string comparison of the filenames as a tiebreaker. Regards, James [1] - https://reproducible-builds.org [2] - https://tests.reproducible-builds.org/debian/rb-pkg/trixie/i386/diffoscope-results/allegro5.html [3] - https://reproducible-builds.org/docs/source-date-epoch/
Bug#1064638: python-x2go-doc: please make the build reproducible.
Followup-For: Bug #1064638 Control: forwarded -1 https://salsa.debian.org/debian-remote-team/python-x2go/-/merge_requests/3
Bug#1064638: python-x2go-doc: please make the build reproducible.
Source: python-x2go Version: 0.6.1.4-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath Dear Maintainer, I'm an occasional volunteer contributor with the Reproducible Builds[1] project, and noticed recently that the python-x2go-doc package failed[2] an automated reproducibility test on Debian. >From investigation, it seems that most if not all of the cause of non-reproducibility during the test was due to the Sphinx autodoc extension evaluating some of the default Python method values (like sessions_rootdir[3]) at build-time and including the evaluated value, which varied, in the documentation. Because the value of the parameter is determined at _runtime_ (because Python code is not compiled), this does _not_ indicate any baked-in problem with the python3-x2go package -- but it does create a reproducibility problem for the python-x2go-doc package. As a workaround, we can enable the 'autodoc_preserve_defaults'[4] configuration setting, meaning that Sphinx will render the method signature defaults using the original source code as-written, instead of evaluating the corresponding values. I'll offer a merge request on Salsa to make that change, and will link that to this bugreport. Thanks, James [1] - https://reproducible-builds.org/ [2] - https://tests.reproducible-builds.org/debian/rb-pkg/trixie/arm64/diffoscope-results/python-x2go.html [3] - https://sources.debian.org/src/python-x2go/0.6.1.4-1/x2go/backends/proxy/base.py/#L76 [4] - https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html#confval-autodoc_preserve_defaults
Bug#1064404: snapd: please make the build reproducible.
On Wed, 21 Feb 2024 at 15:52, Zygmunt Krynicki wrote: > > > > Wiadomość napisana przez James Addison w dniu > > 21.02.2024, o godz. 15:49: > > > > Source: snapd > > Version: 2.61.1-1 > > Severity: wishlist > > > > ... [snip] ... > > > > One cause of non-reproducibility for the package appears to be that the > > snap.8 manual page (compressed as snap.8.gz) contains a timestamp in the > > header that becomes timezone-localized, meaning that the Debian binary > > packages > > built may vary based on the timezone they're built in. > > > > Although one way to fix this could be to request and display a UTC > > timestamp, > > there's a comment[3] in the debian/rules file that hints at a better > > solution: > > from version 1.4.0-2 of golang-go-flags there is in-built support[4] for the > > SOURCE_DATE_EPOCH variable, a time-in-seconds since the Unix epoch > > (interpreted > > in UTC[5]). > > > > ... [ snip ] ... > > > Thank you for bringing this to my attention and for offering a patch. I was > aware of numerous TODOs in the packaging but have not yet managed to come up > with a solution that would work both upstream and downstream (snapd CI system > uses a copy of the debian packaging to check that a package can indeed be > built), so any iteration on this is rather tedious. > > In any case that should not be a problem that cannot be solved. I'm looking > forward to your pull request or patches. > Best regards > ZK > Thanks, Zygmunt - https://salsa.debian.org/debian/snapd/-/merge_requests/7 contains a minimal change that I believe should make the package reproducible on Debian - it does not alter any build-time dependencies, and does not affect the rules files for any other distros/releases (the debian-sid (experimental) rules file in the packaging dir is _not_ updated). The change updates the packaging to remove customization of golangs-go-flags manual-page-generation timestamping. That library previously lacked support for reproducible build timestamping, that was subsequently patched[1] into Debian in v1.4.0-2 and merged upstream[2] into v1.5.0. Please let me know whether that approach seems reasonable, or whether a more cautious approach would make sense (perhaps by starting with sid first). Regards, James [1] - https://salsa.debian.org/go-team/packages/golang-go-flags/-/commit/3015faf7a972cb074e65f8c210476937698a492b [2] - https://github.com/jessevdk/go-flags/pull/285
Bug#1064593: debian-policy: missing static resources for www.debian.org policy page
On Sun, 25 Feb 2024 at 08:07, Sean Whitton wrote: > ... > On Sun 25 Feb 2024 at 08:44am +01, Holger Wansing wrote: > > ... > > Am 24. Februar 2024 20:15:41 MEZ schrieb James Addison > > : > >> > >>(this may relate closely to #915583) > >> > >>Some of the web resources referenced by the online[1] copy of the Debian > >>policy > >>manual seem to return HTTP 404 responses at the moment, meaning that the > >>intended Sphinx CSS theming fails to apply. > >> > >>[1] - https://www.debian.org/doc/debian-policy/ > > > > Hmm, locally built it's fine here ... > > ... > The new debian.css is there. So, which file is it that's missing? Thanks for checking - yep, the debian.css file does appear to be fine. The following paths (relative to the policy base) produce HTTP 404 responses: * _static/css/theme.css * _static/jquery.js * _static/sphinx_highlight.js * _static/js/theme.js Regards, James
Bug#1064607: python-vispy-doc: unhandled failures to build documentation can occur
Followup-For: Bug #1064607 Control: tags -1 patch Control: forwarded -1 https://salsa.debian.org/science-team/python-vispy/-/merge_requests/2
Bug#1064607: python-vispy-doc: unhandled failures to build documentation can occur
Source: python-vispy
Version: 0.14.1-2
Severity: important
Dear Maintainer,
In the debian/rules build instructions for python-vispy-doc, the make step[1]
that builds the package documentation (by using a Makefile in the 'doc' dir) is
followed by another command, separated by a semicolon:
HOME=$$(mktemp -d);PYTHONPATH=`pybuild --print {build_dir} -p$$(py3versions
-dv)` HOME=$$HOME xvfb-run make -C doc html;rm -r $$HOME
This means if the (middle) documentation build step fails -- a situation that
would usually and correctly result in a FTBFS -- then the subsequent (rm)
command is evaluated next, and it is the exit code from _that_ latter command
that will determine the success/failure of the make target, and the overall doc
package build.
It may be possible to separate the commands onto separate lines (with care to
make sure that variables are created and access correctly), or less invasively
to use boolean AND (&&) separators instead of semi-colons.
Regards,
James
[1] - https://sources.debian.org/src/python-vispy/0.14.1-2/debian/rules/#L18
Bug#1064593: debian-policy: missing static resources for www.debian.org policy page
Package: debian-policy Version: 4.6.2.1 Severity: normal X-Debbugs-Cc: spwhit...@spwhitton.name, hwans...@mailbox.org, debian-...@lists.debian.org (this may relate closely to #915583) Some of the web resources referenced by the online[1] copy of the Debian policy manual seem to return HTTP 404 responses at the moment, meaning that the intended Sphinx CSS theming fails to apply. [1] - https://www.debian.org/doc/debian-policy/
Bug#1064575: python-pyswarms-doc: please make the build reproducible.
Package: python-pyswarms-doc Severity: wishlist Tags: patch upstream User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness Dear Maintainer, I'm an occasional volunteer contributor to the Reproducible Builds[1] project, and recently noticed that your package failed an automated test for Debian build reproducibility[2] that also appeared in the results of Debian's Salsa-CI reprotest[3]. The cause of the problem relates to two images named ani.gif and ani_h.gif respectively in the options_handler.ipynb documentation tutorial file. In particular, there is an IPython notebook cell[4] declared as type Markdown that presents the images, and notably does _not_ include an explicit HTML 'alt' attribute[5] describing the contents of each image. Part of the documentation rendering process - I have not determined exactly what yet - adds an 'alt' attribute when it does not exist, and generates a randomized hex string to use as the value of the attribute. This causes the resulting python-pyswarms-doc package to vary on each build. Providing a static value for the alt attribute on these two image tags allows the python-pyswarms-doc package to build reproducibly (bit-for-bit identical). I've created a branch on Salsa with a proposed change, and will open that as a merge request against pyswarms.git for your review. Thank you, James [1] - https://reproducible-builds.org [2] - https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/pyswarms.html [3] - https://salsa.debian.org/science-team/pyswarms/-/jobs/5194535 [4] - https://sources.debian.org/src/pyswarms/1.3.0-6/docs/examples/tutorials/options_handler.ipynb/#L230-L249 [5] - https://en.wikipedia.org/wiki/Alt_attribute
Bug#1036828: debian-cd: wrong firmware archives built and published for D-I releases?
Followup-For: Bug #1036828 X-Debbugs-Cc: k...@debian.org On Sat, 24 Feb 2024 11:01:31 +, I wrote: > Should this bug be closed? (the logic to skip the experimental/sid firmware > image build during non-testing builds is in place for both bookworm and > trixie) Nope, it looks like I've misunderstood here. This change is ready, but pending upload (as indicated by the bug tags). (may be worth double-checking that the bugnumber is referenced-as-closed in the changelog, though?)
Bug#1036828: debian-cd: wrong firmware archives built and published for D-I releases?
Followup-For: Bug #1036828 X-Debbugs-Cc: k...@debian.org Hi Cyril, Should this bug be closed? (the logic to skip the experimental/sid firmware image build during non-testing builds is in place for both bookworm and trixie) Regards, James
Bug#1064535: python-fudge: cleanup: Sphinx now supports SOURCE_DATE_EPOCH natively
Source: python-fudge Version: 1.1.1-2 Severity: wishlist User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps Dear Maintainer, I'm an occasional volunteer contributor with the Reproducible Builds[1] project, and noticed that the python-fudge package failed an automated reproducible build test[2] recently. While investigating the cause, I found that the debian/rules file in the python-fudge source package contains some SOURCE_DATE_EPOCH logic that is now natively supported[3] by Sphinx itself. I believe that removing the SPHINX_DATE_EPOCH-related logic from the debian/rules file should be possible, and is likely to address the cause of the reproducibility failure. To assist with confirmation that your package is reproducible, you may optionally enable Debian Salsa's Continuous Integration[4]; this includes a utility called 'reprotest' that will test two maximally-varying builds of your source package and indicate whether the binary packages remain identical (as intended) despite build environment variance. Thank you, James [1] - https://reproducible-builds.org/ [2] - https://tests.reproducible-builds.org/debian/rb-pkg/trixie/arm64/diffoscope-results/python-fudge.html [3] - https://github.com/sphinx-doc/sphinx/pull/1954 [4] - https://salsa.debian.org/salsa-ci-team/pipeline/
Bug#1064519: flask-limiter-docs: please make the build reproducible.
Package: python-flask-limiter-doc Followup-For: Bug #1064519 Control: forwarded -1 https://salsa.debian.org/python-team/packages/flask-limiter/-/merge_requests/2
Bug#1064519: flask-limiter-docs: please make the build reproducible.
Package: python-flask-limiter-doc Version: 3.5.1-1 Severity: wishlist Tags: patch Dear Maintainer, I'm an occasional volunteer contributor to the Reproducible Builds[1] project, and recently noticed that python-flask-limiter-docs package failed to build reproducibly during automated reproducible build testing[2] and also during a reprotest build[3] on Salsa-CI. The origin of the non-reproducibility demonstrated in both of those cases is that a command[4] invoked by the Sphinx-based documentation project markup produces nondeterministic output. In particular, the output involves iteration over a set of HTTP methods associated with a flask (Python web framework) view. The methods are placed[5] on the relevant Python object by the werkzeug Python library, and are stored within an Python set object that is unordered[6]. Because the storage (and therefore retrieval) ordering of the elements in the set is based on Python's object hashing, it is non-deterministic by default and varies at build-time. We can fix this within Debian's packaging by configuring the PYTHONHASHSEED[7] to use a deterministic value. The value of zero (0) appears to be most common within existing debian/rules files, based on codesearch[8]. I'll open a merge request on Salsa to suggest that modification and will link that to the bug here. Regards, James [1] - https://reproducible-builds.org/ [2] - https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/diffoscope-results/flask-limiter.html [3] - https://salsa.debian.org/python-team/packages/flask-limiter/-/jobs/5335790 [4] - https://sources.debian.org/src/flask-limiter/3.5.1-1/doc/source/cli.rst/#L60-L61 [5] - https://sources.debian.org/src/python-werkzeug/3.0.1-2/src/werkzeug/routing/rules.py/#L477 [6] - https://docs.python.org/3.11/library/stdtypes.html#set-types-set-frozenset [7] - https://docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED [8] - https://codesearch.debian.net/search?q=path%3Adebian%2Frules+PYTHONHASHSEED
Bug#1064475: lists.debian.org: missing recent posts in search indices.
Package: lists.debian.org Severity: important Dear Maintainer, Some recent discussion from the Debian mailing lists appears to be missing from the mailing list search engine[1] indices. For example: * Searching for 'Debian'[2] in the debian-devel mailing list, results sorted by date, currently retrieves a most-recent result dated February of Y2023. * A wider search for 'Debian'[3] without specifying an individual mailing list currently retrieves results up to December of Y2023. Could you inspect the indexing hosts/processes to check whether posts are being indexed as expected? Thank you, James [1] - https://lists.debian.org/search.html [2] - https://lists.debian.org/cgi-bin/search?P=debian=Gdebian-devel=0 [3] - https://lists.debian.org/cgi-bin/search?P=debian=0
Bug#1064404: snapd: please make the build reproducible.
Followup-For: Bug #1064404 Control: forwarded -1 https://salsa.debian.org/debian/snapd/-/merge_requests/7 Control: tags -1 patch Control: submitter -1 reproducible-bui...@lists.alioth.debian.org Control: user reproducible-bui...@lists.alioth.debian.org Control: usertag -1 timezone
Bug#1064404: snapd: please make the build reproducible.
Source: snapd Version: 2.61.1-1 Severity: wishlist Dear Maintainer, I'm an occasional volunteer with the Reproducible Builds[1] project, and recently noticed that the snapd package failed automated reproducible build testing[2] on Debian. One cause of non-reproducibility for the package appears to be that the snap.8 manual page (compressed as snap.8.gz) contains a timestamp in the header that becomes timezone-localized, meaning that the Debian binary packages built may vary based on the timezone they're built in. Although one way to fix this could be to request and display a UTC timestamp, there's a comment[3] in the debian/rules file that hints at a better solution: from version 1.4.0-2 of golang-go-flags there is in-built support[4] for the SOURCE_DATE_EPOCH variable, a time-in-seconds since the Unix epoch (interpreted in UTC[5]). That means that it should be possible to generate reproducible manual pages directly by calling the compiled snap binary with the 'help --man' commandline arguments, omitting the sed expression as suggested by the comment. I'll offer a merge request on Salsa to provide that change soon. Regards, James [1] - https://reproducible-builds.org/ [2] - https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/snapd.html [3] - https://sources.debian.org/src/snapd/2.61.1-1/debian/rules/#L281 [4] - https://sources.debian.org/src/golang-go-flags/1.4.0-2/man.go/#L180-L187 [5] - https://pkg.go.dev/time#Unix
Bug#1028125: wrong source-contains-prebuilt-windows-binary for GB18030-encoded text file
Followup-For: Bug #1028125 X-Debbugs-Cc: r...@debian.org Control: reassign -1 file Control: affects -1 lintian This filetype ambiguity seems to be reported by the 'file' command that lintian invokes[1] to identify the file type for source files that it scans. [1] - https://sources.debian.org/src/lintian/2.117.0/lib/Lintian/Index/FileTypes.pm/#L75-L119
Bug#1058959: python-quantities: please removed old suggestion for python3-unittest2
Followup-For: Bug #1058959 X-Debbugs-Cc: alexandre.deti...@gmail.com Control: tags -1 pending
Bug#1029555: lintian: license-problem-font-adobe-copyrighted-fragment-no-credit false positive
Followup-For: Bug #1029555 X-Debbugs-Cc: rol...@debian.org Control: close -1 lintian/2.117.0 Resolved in lintian 2.117.0 as uploaded to unstable (and has migrated to testing / trixie). Refs: - https://salsa.debian.org/lintian/lintian/-/commit/2d5c8528f490edb1339fd0a65b3e503c32b2c366 - https://salsa.debian.org/lintian/lintian/-/blob/69b9209b02ab1a9e2d40d83931541ab6629f9226/debian/changelog#L68-69
Bug#1042955: zzzeeksphinx: please make the output reproducible
Followup-For: Bug #1042955 Control: forwarded -1 https://github.com/sqlalchemyorg/zzzeeksphinx/issues/23
Bug#1064054: qtbase-opensource-src-gles: CVE-2024-25580
Source: qtbase-opensource-src-gles
Followup-For: Bug #1064054
Control: found -1 5.12.2+dfsg-1
Control: tags -1 patch
diff --git a/src/gui/util/qktxhandler.cpp b/src/gui/util/qktxhandler.cpp
index 0d98e97453..6a79e55109 100644
--- a/src/gui/util/qktxhandler.cpp
+++ b/src/gui/util/qktxhandler.cpp
@@ -73,7 +73,7 @@ struct KTXHeader {
quint32 bytesOfKeyValueData;
};
-static const quint32 headerSize = sizeof(KTXHeader);
+static constexpr quint32 qktxh_headerSize = sizeof(KTXHeader);
// Currently unused, declared for future reference
struct KTXKeyValuePairItem {
@@ -103,11 +103,36 @@ struct KTXMipmapLevel {
*/
};
-bool QKtxHandler::canRead(const QByteArray , const QByteArray )
+static bool qAddOverflow(quint32 v1, quint32 v2, quint32 *r) {
+// unsigned additions are well-defined
+*r = v1 + v2;
+return v1 > quint32(v1 + v2);
+}
+
+// Returns the nearest multiple of 4 greater than or equal to 'value'
+static bool nearestMultipleOf4(quint32 value, quint32 *result)
+{
+constexpr quint32 rounding = 4;
+*result = 0;
+if (qAddOverflow(value, rounding - 1, result))
+return true;
+*result &= ~(rounding - 1);
+return false;
+}
+
+// Returns a slice with prechecked bounds
+static QByteArray safeSlice(const QByteArray& array, quint32 start, quint32
length)
{
-Q_UNUSED(suffix)
+quint32 end = 0;
+if (qAddOverflow(start, length, ) || end > quint32(array.length()))
+return {};
+return QByteArray(array.data() + start, length);
+}
-return (qstrncmp(block.constData(), ktxIdentifier, KTX_IDENTIFIER_LENGTH)
== 0);
+bool QKtxHandler::canRead(const QByteArray , const QByteArray )
+{
+Q_UNUSED(suffix);
+return block.startsWith(QByteArray::fromRawData(ktxIdentifier,
KTX_IDENTIFIER_LENGTH));
}
QTextureFileData QKtxHandler::read()
@@ -115,42 +140,97 @@ QTextureFileData QKtxHandler::read()
if (!device())
return QTextureFileData();
-QByteArray buf = device()->readAll();
-const quint32 dataSize = quint32(buf.size());
-if (dataSize < headerSize || !canRead(QByteArray(), buf)) {
-qCDebug(lcQtGuiTextureIO, "Invalid KTX file %s",
logName().constData());
+const QByteArray buf = device()->readAll();
+if (size_t(buf.size()) > std::numeric_limits::max()) {
+qWarning(lcQtGuiTextureIO, "Too big KTX file %s",
logName().constData());
+return QTextureFileData();
+}
+
+if (!canRead(QByteArray(), buf)) {
+qWarning(lcQtGuiTextureIO, "Invalid KTX file %s",
logName().constData());
+return QTextureFileData();
+}
+
+if (buf.size() < qsizetype(qktxh_headerSize)) {
+qWarning(lcQtGuiTextureIO, "Invalid KTX header size in %s",
logName().constData());
return QTextureFileData();
}
-const KTXHeader *header = reinterpret_cast(buf.constData());
-if (!checkHeader(*header)) {
-qCDebug(lcQtGuiTextureIO, "Unsupported KTX file format in %s",
logName().constData());
+KTXHeader header;
+memcpy(, buf.data(), qktxh_headerSize);
+if (!checkHeader(header)) {
+qWarning(lcQtGuiTextureIO, "Unsupported KTX file format in %s",
logName().constData());
return QTextureFileData();
}
QTextureFileData texData;
texData.setData(buf);
-texData.setSize(QSize(decode(header->pixelWidth),
decode(header->pixelHeight)));
-texData.setGLFormat(decode(header->glFormat));
-texData.setGLInternalFormat(decode(header->glInternalFormat));
-texData.setGLBaseInternalFormat(decode(header->glBaseInternalFormat));
-
-texData.setNumLevels(decode(header->numberOfMipmapLevels));
-quint32 offset = headerSize + decode(header->bytesOfKeyValueData);
-const int maxLevels = qMin(texData.numLevels(), 32); // Cap
iterations in case of corrupt file.
-for (int i = 0; i < maxLevels; i++) {
-if (offset + sizeof(KTXMipmapLevel) > dataSize)//
Corrupt file; avoid oob read
-break;
-const KTXMipmapLevel *level = reinterpret_cast(buf.constData() + offset);
-quint32 levelLen = decode(level->imageSize);
-texData.setDataOffset(offset + sizeof(KTXMipmapLevel::imageSize), i);
-texData.setDataLength(levelLen, i);
-offset += sizeof(KTXMipmapLevel::imageSize) + levelLen + (3 -
((levelLen + 3) % 4));
+texData.setSize(QSize(decode(header.pixelWidth),
decode(header.pixelHeight)));
+texData.setGLFormat(decode(header.glFormat));
+texData.setGLInternalFormat(decode(header.glInternalFormat));
+texData.setGLBaseInternalFormat(decode(header.glBaseInternalFormat));
+
+texData.setNumLevels(decode(header.numberOfMipmapLevels));
+
+const quint32 bytesOfKeyValueData = decode(header.bytesOfKeyValueData);
+quint32 headerKeyValueSize;
+if (qAddOverflow(qktxh_headerSize, bytesOfKeyValueData,
)) {
+qWarning(lcQtGuiTextureIO, "Overflow in size of key value data in
header of KTX file %s",
+
Bug#1064053: qtbase-opensource-src: CVE-2024-25580
Source: qtbase-opensource-src
Followup-For: Bug #1064053
Control: found -1
Control: found -1 5.12.2+dfsg-1
Replying to set the earliest version affected from the advisory blogpost[1],
and to (re)attach the patch from the duplicate bugreport.
[1]
https://www.qt.io/blog/security-advisory-potential-buffer-overflow-when-reading-ktx-images
diff --git a/src/gui/util/qktxhandler.cpp b/src/gui/util/qktxhandler.cpp
index 0d98e97453..6a79e55109 100644
--- a/src/gui/util/qktxhandler.cpp
+++ b/src/gui/util/qktxhandler.cpp
@@ -73,7 +73,7 @@ struct KTXHeader {
quint32 bytesOfKeyValueData;
};
-static const quint32 headerSize = sizeof(KTXHeader);
+static constexpr quint32 qktxh_headerSize = sizeof(KTXHeader);
// Currently unused, declared for future reference
struct KTXKeyValuePairItem {
@@ -103,11 +103,36 @@ struct KTXMipmapLevel {
*/
};
-bool QKtxHandler::canRead(const QByteArray , const QByteArray )
+static bool qAddOverflow(quint32 v1, quint32 v2, quint32 *r) {
+// unsigned additions are well-defined
+*r = v1 + v2;
+return v1 > quint32(v1 + v2);
+}
+
+// Returns the nearest multiple of 4 greater than or equal to 'value'
+static bool nearestMultipleOf4(quint32 value, quint32 *result)
+{
+constexpr quint32 rounding = 4;
+*result = 0;
+if (qAddOverflow(value, rounding - 1, result))
+return true;
+*result &= ~(rounding - 1);
+return false;
+}
+
+// Returns a slice with prechecked bounds
+static QByteArray safeSlice(const QByteArray& array, quint32 start, quint32
length)
{
-Q_UNUSED(suffix)
+quint32 end = 0;
+if (qAddOverflow(start, length, ) || end > quint32(array.length()))
+return {};
+return QByteArray(array.data() + start, length);
+}
-return (qstrncmp(block.constData(), ktxIdentifier, KTX_IDENTIFIER_LENGTH)
== 0);
+bool QKtxHandler::canRead(const QByteArray , const QByteArray )
+{
+Q_UNUSED(suffix);
+return block.startsWith(QByteArray::fromRawData(ktxIdentifier,
KTX_IDENTIFIER_LENGTH));
}
QTextureFileData QKtxHandler::read()
@@ -115,42 +140,97 @@ QTextureFileData QKtxHandler::read()
if (!device())
return QTextureFileData();
-QByteArray buf = device()->readAll();
-const quint32 dataSize = quint32(buf.size());
-if (dataSize < headerSize || !canRead(QByteArray(), buf)) {
-qCDebug(lcQtGuiTextureIO, "Invalid KTX file %s",
logName().constData());
+const QByteArray buf = device()->readAll();
+if (size_t(buf.size()) > std::numeric_limits::max()) {
+qWarning(lcQtGuiTextureIO, "Too big KTX file %s",
logName().constData());
+return QTextureFileData();
+}
+
+if (!canRead(QByteArray(), buf)) {
+qWarning(lcQtGuiTextureIO, "Invalid KTX file %s",
logName().constData());
+return QTextureFileData();
+}
+
+if (buf.size() < qsizetype(qktxh_headerSize)) {
+qWarning(lcQtGuiTextureIO, "Invalid KTX header size in %s",
logName().constData());
return QTextureFileData();
}
-const KTXHeader *header = reinterpret_cast(buf.constData());
-if (!checkHeader(*header)) {
-qCDebug(lcQtGuiTextureIO, "Unsupported KTX file format in %s",
logName().constData());
+KTXHeader header;
+memcpy(, buf.data(), qktxh_headerSize);
+if (!checkHeader(header)) {
+qWarning(lcQtGuiTextureIO, "Unsupported KTX file format in %s",
logName().constData());
return QTextureFileData();
}
QTextureFileData texData;
texData.setData(buf);
-texData.setSize(QSize(decode(header->pixelWidth),
decode(header->pixelHeight)));
-texData.setGLFormat(decode(header->glFormat));
-texData.setGLInternalFormat(decode(header->glInternalFormat));
-texData.setGLBaseInternalFormat(decode(header->glBaseInternalFormat));
-
-texData.setNumLevels(decode(header->numberOfMipmapLevels));
-quint32 offset = headerSize + decode(header->bytesOfKeyValueData);
-const int maxLevels = qMin(texData.numLevels(), 32); // Cap
iterations in case of corrupt file.
-for (int i = 0; i < maxLevels; i++) {
-if (offset + sizeof(KTXMipmapLevel) > dataSize)//
Corrupt file; avoid oob read
-break;
-const KTXMipmapLevel *level = reinterpret_cast(buf.constData() + offset);
-quint32 levelLen = decode(level->imageSize);
-texData.setDataOffset(offset + sizeof(KTXMipmapLevel::imageSize), i);
-texData.setDataLength(levelLen, i);
-offset += sizeof(KTXMipmapLevel::imageSize) + levelLen + (3 -
((levelLen + 3) % 4));
+texData.setSize(QSize(decode(header.pixelWidth),
decode(header.pixelHeight)));
+texData.setGLFormat(decode(header.glFormat));
+texData.setGLInternalFormat(decode(header.glInternalFormat));
+texData.setGLBaseInternalFormat(decode(header.glBaseInternalFormat));
+
+texData.setNumLevels(decode(header.numberOfMipmapLevels));
+
+const quint32 bytesOfKeyValueData =
Bug#1064052: qt6-base: CVE-2024-25580
Followup-For: Bug #1064052 Control: fixed -1 6.6.2+dfsg-1
Bug#1064056: qtbase-opensource-src: CVE-2024-25580
Source: qtbase-opensource-src Followup-For: Bug #1064056 Control: forcemerge 1064053 -1 Duplicate of #1064053; force merging this bugreport into that one.
Bug#1064056: qtbase-opensource-src: CVE-2024-25580
Source: qtbase-opensource-src
Version: 5.15.10+dfsg-6
Severity: normal
Tags: patch security
Dear Maintainer,
Security advisory CVE-2024-25580, a buffer overflow affecting KTX image
handling in QT, has been announced[1], and the announcement includes patches
for various versions of QT including the v5.15 branch.
I've confirmed that the patch applies cleanly to qtbase-opensource-src versions
5.15.8+dfsg-11 (bookworm / stable) and 5.15.10+dfsg-6 (trixie / testing), and
have successfully compiled the trixie package.
Please find attached the v5.15 patch from upstream.
( sha256sum 7cc9bf74f696de8ec5386bb80ce7a2fed5aa3870ac0e2c7db4628621c5c1a731 )
Regards,
James
[1] - https://lists.qt-project.org/pipermail/announce/2024-February/000472.html
diff --git a/src/gui/util/qktxhandler.cpp b/src/gui/util/qktxhandler.cpp
index 0d98e97453..6a79e55109 100644
--- a/src/gui/util/qktxhandler.cpp
+++ b/src/gui/util/qktxhandler.cpp
@@ -73,7 +73,7 @@ struct KTXHeader {
quint32 bytesOfKeyValueData;
};
-static const quint32 headerSize = sizeof(KTXHeader);
+static constexpr quint32 qktxh_headerSize = sizeof(KTXHeader);
// Currently unused, declared for future reference
struct KTXKeyValuePairItem {
@@ -103,11 +103,36 @@ struct KTXMipmapLevel {
*/
};
-bool QKtxHandler::canRead(const QByteArray , const QByteArray )
+static bool qAddOverflow(quint32 v1, quint32 v2, quint32 *r) {
+// unsigned additions are well-defined
+*r = v1 + v2;
+return v1 > quint32(v1 + v2);
+}
+
+// Returns the nearest multiple of 4 greater than or equal to 'value'
+static bool nearestMultipleOf4(quint32 value, quint32 *result)
+{
+constexpr quint32 rounding = 4;
+*result = 0;
+if (qAddOverflow(value, rounding - 1, result))
+return true;
+*result &= ~(rounding - 1);
+return false;
+}
+
+// Returns a slice with prechecked bounds
+static QByteArray safeSlice(const QByteArray& array, quint32 start, quint32
length)
{
-Q_UNUSED(suffix)
+quint32 end = 0;
+if (qAddOverflow(start, length, ) || end > quint32(array.length()))
+return {};
+return QByteArray(array.data() + start, length);
+}
-return (qstrncmp(block.constData(), ktxIdentifier, KTX_IDENTIFIER_LENGTH)
== 0);
+bool QKtxHandler::canRead(const QByteArray , const QByteArray )
+{
+Q_UNUSED(suffix);
+return block.startsWith(QByteArray::fromRawData(ktxIdentifier,
KTX_IDENTIFIER_LENGTH));
}
QTextureFileData QKtxHandler::read()
@@ -115,42 +140,97 @@ QTextureFileData QKtxHandler::read()
if (!device())
return QTextureFileData();
-QByteArray buf = device()->readAll();
-const quint32 dataSize = quint32(buf.size());
-if (dataSize < headerSize || !canRead(QByteArray(), buf)) {
-qCDebug(lcQtGuiTextureIO, "Invalid KTX file %s",
logName().constData());
+const QByteArray buf = device()->readAll();
+if (size_t(buf.size()) > std::numeric_limits::max()) {
+qWarning(lcQtGuiTextureIO, "Too big KTX file %s",
logName().constData());
+return QTextureFileData();
+}
+
+if (!canRead(QByteArray(), buf)) {
+qWarning(lcQtGuiTextureIO, "Invalid KTX file %s",
logName().constData());
+return QTextureFileData();
+}
+
+if (buf.size() < qsizetype(qktxh_headerSize)) {
+qWarning(lcQtGuiTextureIO, "Invalid KTX header size in %s",
logName().constData());
return QTextureFileData();
}
-const KTXHeader *header = reinterpret_cast(buf.constData());
-if (!checkHeader(*header)) {
-qCDebug(lcQtGuiTextureIO, "Unsupported KTX file format in %s",
logName().constData());
+KTXHeader header;
+memcpy(, buf.data(), qktxh_headerSize);
+if (!checkHeader(header)) {
+qWarning(lcQtGuiTextureIO, "Unsupported KTX file format in %s",
logName().constData());
return QTextureFileData();
}
QTextureFileData texData;
texData.setData(buf);
-texData.setSize(QSize(decode(header->pixelWidth),
decode(header->pixelHeight)));
-texData.setGLFormat(decode(header->glFormat));
-texData.setGLInternalFormat(decode(header->glInternalFormat));
-texData.setGLBaseInternalFormat(decode(header->glBaseInternalFormat));
-
-texData.setNumLevels(decode(header->numberOfMipmapLevels));
-quint32 offset = headerSize + decode(header->bytesOfKeyValueData);
-const int maxLevels = qMin(texData.numLevels(), 32); // Cap
iterations in case of corrupt file.
-for (int i = 0; i < maxLevels; i++) {
-if (offset + sizeof(KTXMipmapLevel) > dataSize)//
Corrupt file; avoid oob read
-break;
-const KTXMipmapLevel *level = reinterpret_cast(buf.constData() + offset);
-quint32 levelLen = decode(level->imageSize);
-texData.setDataOffset(offset + sizeof(KTXMipmapLevel::imageSize), i);
-texData.setDataLength(levelLen, i);
-offset += sizeof(KTXMipmapLevel::imageSize) + levelLen + (3 -
((levelLen + 3) % 4));
+
Bug#1051551: thunderbird: When deleting a message, the list scrolls up a few messages.
Package: thunderbird Followup-For: Bug #1051551 X-Debbugs-Cc: alx.manpa...@gmail.com, c.schoen...@t-online.de On Sat, 09 Sep 2023 19:16:32 +0200, Alex wrote: > Since some recent version, every time I delete a mail, the list scrolls > up a few messages, and I need to manually scroll down again, every time. I'm not 100% certain, so not setting a forwarded-to on this bug yet, but this sounds a lot like this upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1857766 Does the description on that bugreport match the behaviour you found, Alex? (someone also mentioned a vaguely-similar-sounding issue on debian-user yesterday, which is why I'm taking a brief look)
Bug#1064028: libpython3.12-dev: non-C90 headerfile code breaks -Werror=declaration-after-statement
Package: libpython3.12-dev Version: 3.12.1-2 Severity: minor Tags: upstream newcomer Dear Maintainer, Some of the C code contained within the headerfiles from libpython3.12-dev appears not to be compliant with C90 standards (examples: [1][2]). This contributed to a build failure[3] for the onboard/1.4.1-5 package that is currently part of the python3.12-add[4] transition. Upstream has continued to accept pull requests / patches to update their code to remain C90 compliant over the past few years (example: [5]). Although I'm not initially attaching a patch here, I hope to do so within the next week, unless someone else writes one before I do. Regards, James [1] - https://sources.debian.org/src/python3.12/3.12.2-1/Include/Python.h/ [2] - https://sources.debian.org/src/python3.12/3.12.2-1/Include/cpython/longintrepr.h/ [3] - https://buildd.debian.org/status/fetch.php?pkg=onboard=amd64=1.4.1-5%2Bb8=1706626636=0 [4] - https://release.debian.org/transitions/html/python3.12-add.html [5] - https://github.com/python/cpython/pull/92783
Bug#1060761: lomiri-ui-toolkit: FTBFS with Qt ≥ 5.15.11: error: invalid use of non-static member function ‘QV4::CompiledData::Binding::Type QV4::CompiledData::Binding::type() const’
Source: lomiri-ui-toolkit Followup-For: Bug #1060761 X-Debbugs-Cc: sunwea...@debian.org, mity...@debian.org Hi Mike, Dmitry, Is the second patch here (to disable the failing unit test) likely to be uploaded to unstable in the nearish future? I'm eager to see the results of some build reproducibility improvements in qttools from 5.15.12 (#1059592, #1059631) and this is tagged as a blocker for the relevant qtbase ABI migration. Regards, James
Bug#1063992: gitlab-cli: manual page for python-gitlab has no descriptive content due to an error
Package: gitlab-cli Version: 1:4.3.0-1 Severity: important X-Debbugs-Cc: j...@jp-hosting.net Dear Maintainer, The manual page for the python-gitlab CLI utility in the gitlab-cli binary package contains a Python stacktrace within the 'description' section, instead of the expected help content: DESCRIPTION Traceback (most recent call last): File "/build/reproducible-path/python-gitlab-4.3.0/./debian/gitlab-cli/usr/bin/python-git‐ lab", line 5, in from gitlab.cli import main ModuleNotFoundError: No module named 'gitlab' I cannot replicate this locally; when I build the package using dpkg-buildpackage on my machine, a complete manual page is generated - so the problem could be a buildsystem issue. Regards, James
Bug#1026381: python-django-health-check: please make the build reproducible
Followup-For: Bug #1026381 X-Debbugs-Cc: la...@debian.org, reproducible-b...@lists.alioth.debian.org Control: block -1 1057432 Control: close -1 Based on recent reproducible build testing history[1] of this package, and for Debian versions after the fix for #1057432 became available (excludes both bookworm, and builds prior to 2023-12-04 or so), I'm confident that the package is building reproducibly, so I think we can close this. Adding a bug-blocker relationship for historical tracking purposes and closing this bug. [1] - https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-django-health-check.html
