Bug#1082706: python-sphobjinv: please make the build reproducible
Source: python-sphobjinv Followup-For: Bug #1082706 X-Debbugs-Cc: la...@debian.org Ah; parallel workstreams: I'd noticed this same problem in the RB test results for sphobjinv -- and independently went ahead and wrote a patch[1] (in fact an identical modification) for upstream, which has been accepted. I don't think that that should block applying Chris's patch here to the Debian package to make it reproducible; even so, this is a note to mention that we can hopefully drop that patch when updating to the next upstream version. [1] - https://github.com/bskinn/sphobjinv/pull/299
Bug#1076806: Upload request: meson-python
Hello, I'd like to request an upload of the src:meson-python package, in particular to close bug #1076806, a reproducibility bug related to documentation copyright notices -- the patch there has been committed[1] in Salsa, and also subsequently merged[2] into the upstream codebase. There haven't been any newer releases by upstream since the current version in Debian testing (0.16.0-1), and the only other pending change as far as I can tell is a Standards-Version increment. Also note, to reduce possible ambiguity: this package isn't the meson build system itself, but is a Python PEP517 plugin -- a plugin that allows Python packages to use meson during their own build/setup processes. Thanks! James [1] - https://salsa.debian.org/python-team/packages/meson-python/-/commit/b17dbeae9a9489c1a2e5dcdb4fab4d9c9e5aad1f [2] - https://github.com/mesonbuild/meson-python/pull/652
Bug#787795: grub2: please build rescue ISO and floppy reproducibly
Package: grub2 Followup-For: Bug #787795 Control: forwarded -1 https://salsa.debian.org/grub-team/grub/-/merge_requests/67
Bug#787795: grub2: please build rescue ISO and floppy reproducibly
Package: grub2
Followup-For: Bug #787795
X-Debbugs-Cc: d...@fifthhorseman.net, vagr...@reproducible-builds.org
Control: tags -1 patch
Hi,
On Fri, 05 Jun 2015 02:37:38 -0400, Daniel wrote:
> > However, it won't be completely reproducible until we get a newer
> > version of xorriso in debian so that we can "-alter_date_r c" (see
> > #787793, which blocks this bug).
On Sun, 25 Jul 2021 16:19:46 -0700, Vagrant wrote:
> Since newer versions of xorriso are now in Debian, I tried adding
> "-alter_date_r c" to xorriso calls, but it would seem xorriso doesn't
> support "-alter_date_r c" when used with "-as mkisofs". I'm not sure how
> difficult it would be to convert away from using "-as mkisofs" so that
> "-alter_date_r c" would be supportable...
>From inspecting the grub codebase and the commandline options to both xorriso
and xorrisofs (aka "xorriso -as mkisofs").. although it may in theory be
possible to convert to 'native' xorriso by migrating a lot of the command-line
construction, I think that it might be fragile and unnecessary work, because:
...there is a '--set_all_file_dates' command-line option[1] in xorrisofs that
seems to do what we want here.
There's one other change required in grub-mkrescue alongside this in order to
achieve reproducible builds: we need it to read from the SOURCE_DATE_EPOCH env
var when set (currently grub-mkrescue always uses system clock time).
Please find attached a patch that allows me to rebuild grub-rescue-cdrom.iso
deterministically on my local machine when SOURCE_DATE_EPOCH is set. I'll also
offer this as a merge request on the Salsa repository[2].
Note: the current patch _always_ adds the set_all_file_dates option when
invoking xorriso, regardless of whether the image creation time is read from
the SOURCE_DATE_EPOCH variable or the system clock.
Regards,
James
[1] -
https://manpages.debian.org/bookworm/xorriso/xorrisofs.1.en.html#set_all_file_dates
[2] - https://salsa.debian.org/grub-team/grub/
From: James Addison
Date: Tue, 01 Oct 2024 22:36:39 +0100
Subject: grub2: build rescue ISO reproducibly
Extend the xorriso command-line invocation to configure a specific
timestamp for all files during creation of Grub rescue ISO images.
The timestamp to use is read from the SOURCE_DATE_EPOCH environment
variable when it is set.
Bug-Debian: https://bugs.debian.org/787795
---
--- a/util/grub-mkrescue.c
+++ b/util/grub-mkrescue.c
@@ -576,7 +576,13 @@
{
time_t tim;
struct tm *tmm;
-tim = time (NULL);
+/* https://reproducible-builds.org/docs/source-date-epoch/ */
+char *source_date_epoch;
+/* This assumes that the SOURCE_DATE_EPOCH environment variable will
contain
+ a correct, positive integer in the time_t range */
+if ((source_date_epoch = getenv("SOURCE_DATE_EPOCH")) == NULL ||
+(tim = (time_t)strtoll(source_date_epoch, NULL, 10)) <= 0)
+time(&tim);
tmm = gmtime (&tim);
iso_uuid = xmalloc (55);
grub_snprintf (iso_uuid, 50,
@@ -600,6 +606,19 @@
xorriso_push (uuid_out);
free (uuid_out);
}
+ {
+char *uuid_out = xmalloc (strlen (iso_uuid) + 1);
+char *optr;
+const char *iptr;
+optr = grub_stpcpy (uuid_out, "");
+for (iptr = iso_uuid; *iptr; iptr++)
+ if (*iptr != '-')
+ *optr++ = *iptr;
+*optr = '\0';
+xorriso_push ("--set_all_file_dates");
+xorriso_push (uuid_out);
+free (uuid_out);
+ }
/* build BIOS core.img. */
if (source_dirs[GRUB_INSTALL_PLATFORM_I386_PC])
Bug#1076025: elpa: FTBFS with mpich as default MPI implementation on armel and armhf: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below
Followup-For: Bug #1076025 Control: tags -1 pending
Bug#1064782: bind9-doc: please output tags in the documentation in deterministic order.
Package: bind9-doc Followup-For: Bug #1064782 Control: fixed -1 bind9/9.20.2-1 Control: close -1
Bug#1066083: gnome-maps: please make the build reproducible
Source: gnome-maps Followup-For: Bug #1066083 X-Debbugs-Cc: la...@debian.org Control: fixed -1 gnome-maps/47.0-1 Control: close -1
Bug#1050693: sphinx: unreproducible output if the same function has two entries in the table of contents
Package: python3-sphinx Followup-For: Bug #1050693 X-Debbugs-Cc: rebecca_pal...@zoho.com, mity...@debian.org Control: tags -1 upstream Control: forwarded -1 https://github.com/sphinx-doc/sphinx/issues/6714 Hi Rebecca, Dmitry, I'm _relatively_ confident that this may be the same as an issue[1] reported in the upstream Sphinx issue tracker; the discussion there notes that turning off parallelism provides an effective workaround for this while a fix is pending. I'll set the forwarded address for this bugreport to that one, but please edit that and/or correct me if I'm mistaken! Regards, James [1] - https://github.com/sphinx-doc/sphinx/issues/6714
Bug#1081573: python-lmfit-doc: regression: absence of matplotlib code hyperlinks
Package: python-lmfit-doc Version: 1.2.2-3 Severity: minor X-Debbugs-Cc: ti...@debian.org Dear Maintainer, Some of the code examples in the HTML documentation for python-lmfit-doc provide web hyperlinks to upstream API documentation; numpy and matplotlib objects for example. The matplotlib hyperlinks appear to have mostly or entirely gone missing in version 1.2.2-3 of the package. The 'examples/example_complex_resonator_model.html' is one file where the problem can be readily observed, in the code example that defines a 'plot_ri' function: the method calls on 'plt' should link to matplotlib documentation. The cause may be an upstream bug in Sphinx or one of the extensions that it uses to generate the code snippets, but I felt it is worth reporting here initially. For reference: I noticed this after attempting local builds of lmfit-py in order to uncover any differences arising from the MPLCONFIGDIR environment variable override in the debian/rules file. After comparing the local builds with-and-without that variable: it does not appear to be the cause (in fact: I found the opposite; the hyperlinks appeared when I built with it in place, and were absent in the output after I removed it from the build rules). Regards, James [1] - https://salsa.debian.org/science-team/lmfit-py/-/merge_requests/3
Bug#1064895: python3-sepolicy: please make the package build reproducible.
Package: python3-sepolicy Followup-For: Bug #1064895 Control: fixed -1 3.7-1 Control: close -1 Thank you, Laurent and Russell!
Bug#1080271: podman: please ship the upstream podman-compose.1 manual
Source: libpod Version: 5.2.1 Severity: normal X-Debbugs-Cc: podman-comp...@packages.debian.org, c...@debian.org Control: affects -1 podman-compose Dear Maintainer, In #1054460 a duplicate-file conflict on the podman-compose.1 manual was resolved: the manual was dropped from the podman binary package and the version from podman-compose was retained. However, invoking the default podman 5.2.1 'compose' subcommand produces output referring the user to configuration settings only found in the libpod documentation: $ podman compose help Executing external compose provider "/usr/bin/podman-compose". Please see podman-compose(1) for how to disable this message. ... This tripped me up recently: running 'man -s 1 podman-compose' opened a manual that seemed to be the one instructed, but that didn't describe the relevant compose_warning_logs setting to disable the message. I'd like to request that we ship the upstream libpod manual[1] instead, and optionally that we could retain the podman-compose version of the manual in section 7 (misc). Most installers of podman-compose would be provided with the libpod manual thanks to the Recommends dependency that podman-compose has on libpod. Thanks! James [1] - https://github.com/containers/podman/blob/d0582c9e1e6c80cc08c3f042b91993c853ddcbc6/docs/source/markdown/podman-compose.1.md.in#L16
Bug#1076025: RM: elpa [armel armhf i386] -- ROM; FTBFS on 32-bit architectures
Thanks Graham! With an answer to your question inline below: On Sun, 25 Aug 2024 at 14:02, Graham Inggs wrote: > > Hi James > > On Tue, 20 Aug 2024 at 11:27, James Addison wrote: > > Ok: I can confirm that removing the (OpenMPI-provided) symbols from > > the libelpa19.symbols file resolves the build problem, and that > > subsequent autopkgtests succeeded on an ARM-based host running when I > > ran the binary package build locally within a 32-bit ARM container > > environment. > > To be clear, which autopkgtests did you run? Those of gpaw? > > I've opened a merge request on Salsa with a possible change to do > > that: https://salsa.debian.org/debichem-team/elpa/-/merge_requests/1 I only ran the elpa autopkgtests in this case; in hindsight I should have also confirmed the effect on the dependent package(s). > Merged, thanks. Although I do intend to wait for the mpi-defaults > transition to finish before trying to re-introduce the 32-bit > binaries. Thanks again. I felt that it was worthwhile to offer, but if the resulting maintenance costs add up in future, please feel free to revert it. Also, a self-correction in my terminology that I was thinking about earlier in the week: I don't think I should have said that this was blocking the transition; it arguably delays completion of the transition, but it didn't prevent it from progressing.
Bug#1004184: gcc-11: generate bad code for matplotlib with -O1/-O2 on mips64el
Source: gcc-11 Followup-For: Bug #1004184 Control: fixed -1 gcc-14/14.1.0-1 I haven't yet confirmed that the output of an O1/O2 build is corrected when compiling on MIPS, but the relevant patches have arrived in gcc v14.1 and are packaged in Debian, so I'm updating the tags on this bug to record that.
Bug#1005886: cdimage.debian.org: bookworm net-install CD hangs on "Detecting Network Hardware"
Package: cdimage.debian.org Followup-For: Bug #1005886 X-Debbugs-Cc: powe...@gmail.com Control: tags -1 moreinfo Hi Tony, > The computer is: > Lenovo X1 Carbon Gen 6 > Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz > Intel Dual Band Wireless-AC 8265 (iwlwifi loads fine, during installation) I've a fairly similar laptop here (X1 Yoga, Intel 8260 wifi) that I've used to attempt to replicate this bug using the bookworm 12.6.0 netinst ISO, and similarly a recent daily trixie netinst ISO (from 2024-08-24). I haven't been able to replicate the problem using either of those images; however, if you still encounter it then please do attach the relevant syslog, as Cyril mentioned, so that we can find and fix the problem. I'll note that I know from experience with the Intel 826x chipset that there have been fixes/improvements in the Linux kernel for it recently; it's possible that those may have resolved the problem. It would be nice to confirm exactly what the cause of the bug was, but even if we cannot achieve that, then there there is also value in confirming whether this bug still occurs at all. Note: if you have Secure Boot enabled, and re-test using non-recent ISO images, then you may encounter boot-time errors related to SBAT since the grub version(s) in use in those images are no longer considered trusted. Thanks, James [1] - https://lwn.net/Articles/986844/
Bug#1076025: elpa: FTBFS with mpich as default MPI implementation on armel and armhf: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below
Source: elpa Followup-For: Bug #1076025 Control: forwarded -1 https://salsa.debian.org/debichem-team/elpa/-/merge_requests/1 Control: tags -1 patch
Bug#1064782: bind9-doc: please output tags in the documentation in deterministic order.
Package: bind9-doc Followup-For: Bug #1064782 Control: tags -1 = upstream fixed-upstream
Bug#1064782: bind9-doc: please output tags in the documentation in deterministic order.
Package: bind9-doc Followup-For: Bug #1064782 Control: forwarded -1 https://gitlab.isc.org/isc-projects/bind9/-/issues/4886
Bug#1076025: RM: elpa [armel armhf i386] -- ROM; FTBFS on 32-bit architectures
On Mon, 19 Aug 2024 at 15:16, James Addison wrote: > > On Mon, Aug 19, 2024, 13:57 Graham Inggs wrote: >> >> Hi James >> >> On Mon, 19 Aug 2024 at 12:40, James Addison wrote: >> > Ok, thank you. Could we resolve this by adding libelpa.symbols.arch >> > file(s), minus the openmpi symbols, for the failing architectures? >> >> That might fix the build, but who will take care of the autopkgtests >> and reverse-dependencies? > > > From reading one of the linked bug autopkgtest outputs, none of the tests > passed at all, and that makes me wonder if they ran despite a faulty > binary/program output. > > I began attempting a test build locally but on an x86 (64, I'm not completely > mad) host under qemu but it was abysmally slow, so I'll try again later on an > ARM build host. > > From the git history of the symbols file, I also notice that at one point the > relevant (open)MPI symbols were tagged as optional. Perhaps that, even if it > is an unusual use of the tag, could allow the build to succeed without > creating per-arch files. > > In any case: I'll try to provide some results-based feedback soon (next day > or so, most likely). Ok: I can confirm that removing the (OpenMPI-provided) symbols from the libelpa19.symbols file resolves the build problem, and that subsequent autopkgtests succeeded on an ARM-based host running when I ran the binary package build locally within a 32-bit ARM container environment. However: I'm not sure that my suggestion to create per-architecture symbols is ideal. When trawling through the Debian elpa packaging git history, I found that the OpenMPI-specific entries were previously tagged as optional -- and I think that that might be a more convenient approach. I've opened a merge request on Salsa with a possible change to do that: https://salsa.debian.org/debichem-team/elpa/-/merge_requests/1 Regards, James
Bug#1076025: RM: elpa [armel armhf i386] -- ROM; FTBFS on 32-bit architectures
On Mon, Aug 19, 2024, 13:57 Graham Inggs wrote: > Hi James > > On Mon, 19 Aug 2024 at 12:40, James Addison wrote: > > Ok, thank you. Could we resolve this by adding libelpa.symbols.arch > file(s), minus the openmpi symbols, for the failing architectures? > > That might fix the build, but who will take care of the autopkgtests > and reverse-dependencies? > >From reading one of the linked bug autopkgtest outputs, none of the tests passed at all, and that makes me wonder if they ran despite a faulty binary/program output. I began attempting a test build locally but on an x86 (64, I'm not completely mad) host under qemu but it was abysmally slow, so I'll try again later on an ARM build host. >From the git history of the symbols file, I also notice that at one point the relevant (open)MPI symbols were tagged as optional. Perhaps that, even if it is an unusual use of the tag, could allow the build to succeed without creating per-arch files. In any case: I'll try to provide some results-based feedback soon (next day or so, most likely). >
Bug#1076025: RM: elpa [armel armhf i386] -- ROM; FTBFS on 32-bit architectures
On Mon, Aug 19, 2024, 13:29 Graham Inggs wrote: > Hi James > > On Mon, 19 Aug 2024 at 12:06, James Addison wrote: > > [ ... snip ... ] > > > > From the build logs: the failure seems to be due to the missing > > mpi_fortran_... symbols on 32-bit ARM; but those appear to be openmpi > > symbols -- if the default MPI provider is (or should now be) mpich, > > then should those symbols be removed from the debian/libelpa19.symbols > > file? > > > > ...and, conversely: why are 64-bit builds successfully linking openmpi > > and resolving those symbols, if mpich is meant to be the default? > > > > [ ... snip ... ] > > The default MPI was only changed to mpich on 32-bit architectures, on > 64-bit architectures, it remains openmpi. > > See #1064810: > "OpenMPI 5.0 drops 32-bit support, so we need to move those archs to > MPICH." > Ok, thank you. Could we resolve this by adding libelpa.symbols.arch file(s), minus the openmpi symbols, for the failing architectures? >
Bug#1076025: RM: elpa [armel armhf i386] -- ROM; FTBFS on 32-bit architectures
On Sun, 18 Aug 2024 14:31:26 +, Graham wrote: > I have filed bug #1078978 requesting removal of elpa's binaries on > these architectures, lowering severity. I've been taking a quick look at this while inspecting the status of the python3.12-only transition (as gpaw is one of the few remaining blockers there, and depends on elpa). >From the build logs: the failure seems to be due to the missing mpi_fortran_... symbols on 32-bit ARM; but those appear to be openmpi symbols -- if the default MPI provider is (or should now be) mpich, then should those symbols be removed from the debian/libelpa19.symbols file? ...and, conversely: why are 64-bit builds successfully linking openmpi and resolving those symbols, if mpich is meant to be the default? (it's likely that I don't understand the context, but I wanted to ask to make sure that we're not unnecessarily dropping some supported architectures from elpa)
Bug#1001870: meshlab: reproducible-builds: BuildId differences triggered by RPATH
Source: meshlab Followup-For: Bug #1001870 Control: fixed -1 meshlab/2020.09+dfsg1-3 Control: close -1
Bug#1066083: gnome-maps: please make the build reproducible
Source: gnome-maps Followup-For: Bug #1066083 Control: tags -1 fixed-upstream
Bug#1066083: gnome-maps: please make the build reproducible
Source: gnome-maps Followup-For: Bug #1066083 Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnome-maps/-/issues/729 Process-wise: I think it makes more sense to set the 'forwarded' property on this bug to the upstream issue I've reported, instead of the corresponding merge request. This message adjusts that.
Bug#1066083: gnome-maps: please make the build reproducible
Source: gnome-maps Followup-For: Bug #1066083 X-Debbugs-Cc: la...@debian.org Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnome-maps/-/merge_requests/453 Although a SOURCE_DATE_EPOCH-based approach was suggested in this bugreport, I've independently opened an alternative that removes the dynamic build-date timestamp entirely upstream, with reference to the previously-mentioned merge request in Gnome's GTK that follows the same approach. I'm OK with either approach, but felt that opening an upstream merge request could be worthwhile here.
Bug#1075914: developers-reference: issue with sidebar in singlehtml variant on small screens
NB: Technically, the patch I attached is not the entirety of the git commit referenced in the header line: I omitted the autogenerated/minified theme.js that was included when I offered the change upstream (reasoning(s): it's not the preferred form for modification, and Debian uses the unminified copy in the hosted documentation).
Bug#1075914: developers-reference: issue with sidebar in singlehtml variant on small screens
Source: sphinx-rtd-theme
Followup-For: Bug #1075914
X-Debbugs-Cc: hwans...@mailbox.org
Control: tags -1 patch
> I've considered attaching the event handler to any menu hyperlinks whose href
> attribute starts with a '#' character (CSS queries can
> prefix-match[2]). However,
> currently some singlehtml menu hyperlinks contain the '.html' filename
> part. That
> may change if https://github.com/sphinx-doc/sphinx/pull/12551 is
> merged upstream.
(apologies for my formatting there; I was manually editing within GMail to
try to fit within 80-char limits, but their editor doesn't provide monospaced
text as far as I'm aware.. and somehow I messed that up. reportbug produces
differently-odd output from me; but I do find it easier to use a good text
editor when using it, so.. here I am)
The aforementioned Sphinx pull request has been merged, so from subsequent
versions of Sphinx onwards, it should be possible to reliably detect same-page
hyperlinks -- as needed to fix this event handler -- in the sidebar menu by
checking for anchor hrefs that begin with the '#' (query-string fragment)
character.
I've opened a pull request for that upstream with sphinx-rtd-theme[1] although
I expect that the Sphinx version dependency may be a concern for it.
[1] - https://github.com/readthedocs/sphinx_rtd_theme/pull/1588
commit 2e97557739984dcd026cb86610cbf322ce3e48dd
Author: James Addison
Date: Mon Aug 12 12:50:33 2024 +0100
Attach sidebar-close handler to current-page links
This is intended primarily to resolve a problem with `singlehtml`
documentation projects when viewed on narrow (typically mobile)
displays.
Under those circumstances, the `.current` CSS selector does not
match any sidebar menu elements, because there is no logical notion
of a 'current' page in `singlehtml` -- every item is on the same
page.
Therefore this change proposes an alternative way to identify sidebar
links that are 'current' -- it checks for anchors that have an `href`
beginning with the query-string fragment identifier (`#`).
This is intended to be compatible with both `singlehtml` and `html`
project builds. It depends upon sphinx-doc/sphinx#12551
diff --git a/src/theme.js b/src/theme.js
index db546b4..106c7a0 100644
--- a/src/theme.js
+++ b/src/theme.js
@@ -86,7 +86,7 @@ function ThemeNav () {
})
// Nav menu link click operations
-.on('click', ".wy-menu-vertical .current ul li a", function() {
+.on('click', ".wy-menu-vertical ul li a[href^='#']", function() {
var target = $(this);
// Close menu when you click a link.
$("[data-toggle='wy-nav-shift']").removeClass("shift");
Bug#1078268: pyfai: please make the package build reproducible
On Sun, 11 Aug 2024 at 09:59, James Addison wrote: > [ ... snip ... ] > Thanks, Vagrant - it's possible that I'm splitting hairs, but the randomized > temporary path is created below the working build directory, and the problem > occurs due to the embedding of that complete resulting path (build dir plus > randomized suffix) in the compiled extension files. After re-reading the test results from the tests.reproducible-builds.org test infrastructure: something is incorrect in my analysis here. It is only the randomized part (not the prefix part from the working dir) that appears in the binary output. So, removing the buildpath usertag does seem fine to me after all.
Bug#1059805: clucene-core: please apply LibreOffice patch to alllow not writing random timestamps into generated files, making them unreproducible
Source: clucene-core Followup-For: Bug #1059805 X-Debbugs-Cc: r...@debian.org, t...@libreoffice.org Dear Maintainer, Rene, Thorsten, I have to admit that I have not, and am not likely to, find the time or gain the necessary experience to properly develop and test an alternative to the libreoffice clucene-core patch[1]. As a result, I would like to add my support for proceeding with that original patch in Debian (ignoring my earlier concern about the fact that it adjusts the clucene ABI). In other words: unless someone gathers a sudden burst of enthusiasm to test my possibly-broken 'reproducible-output.patch' proposal[2], please ignore it and prefer the existing, known-working patch instead. Regards, James [1] - https://cgit.freedesktop.org/libreoffice/core/patch/?id=ff071078ee5f13f0e9d430d6783444a631d232a0 [2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059805#35
Bug#1078268: pyfai: please make the package build reproducible
On Fri, 9 Aug 2024 at 21:14, Vagrant Cascadian wrote: > > user reproducible-bui...@lists.alioth.debian.org > usertags 1064748 +randomness -buildpath > thanks > > On 2024-08-09, James Addison wrote: > > Usertags: buildpath cpu > ... > > The first cause of non-determinism is the use of temporary directory paths > > by > > the meson-python build process; the resulting paths are embedded in some of > > the > > extension modules (for example, this[4] CRC32 module) produced in the output > > binary package. > > > > The meson-python build generates and uses a temporary, randomized build > > directory path only when no build-dir setting is already configured. So we > > may > > be able to resolve this problem by choosing an appropriate static build-dir. > > Typically we have used buildpath to mean the build directory that the > build is performed in, which can be worked around by building in the > same path, not randomized temporary files or directories used during the > build. > > I think "randomness" would be a more appropriate usertag here, and have > adjusted appropriately. Thanks, Vagrant - it's possible that I'm splitting hairs, but the randomized temporary path is created below the working build directory, and the problem occurs due to the embedding of that complete resulting path (build dir plus randomized suffix) in the compiled extension files. In other words: if we resolved the randomness, but then varied the build path, I believe the results would again become non-reproducible. Perhaps we could include both tags?
Bug#1078268: [Debian-pan-maintainers] Bug#1078268: pyfai: please make the package build reproducible
On Fri, 9 Aug 2024 at 14:06, PICCA Frederic-Emmanuel wrote: > > > > > The meson-python build generates and uses a temporary, randomized build > > directory path only when no build-dir setting is already configured. So we > > may > > be able to resolve this problem by choosing an appropriate static build-dir. > > why not fixing meson-python directly. This way it is simpler instead of > patching all package whcih are using it. That is true. I don't consider the bug to be the use of a temporary directory, but instead the embedding of build paths. I'll do some more investigation to try to figure out whether that can be resolved within the build toolchain. > > The second non-deterministic output appears to be due to dynamic-evaluation > > of > > a 'threadpoolsize' default argument value for a Python initializer[6], which > > is set to the current host's CPU count. This would generally only be > > relevant > > at runtime, except for the fact that the documentation package, built using > > the Sphinx 'autodoc' extension, renders the evaluated value in the output > > HTML > > docs. That behaviour can be disabled using the > > 'autodoc_preserve_defaults'[7] > > configuration setting. > > Idem here, maybe sophinx should have decent default when it comes to > reproducible build :). It appears my fix here is incomplete or inaccurate, since a subsequent reprotest build has failed -- but it is possible that Sphinx could change the setting's default, provided with enough support and reasoning to do so. I'll investigate the cause of that failure and add more details soon.
Bug#1078268: [Debian-pan-maintainers] Bug#1078268: pyfai: please make the package build reproducible
On Fri, 9 Aug 2024 at 12:42, PICCA Frederic-Emmanuel wrote: > > If you are part of the Debian science just push to the repository. > > It is easyer for me to revert from git, than to remember to check for MR :) OK. I'm not currently - I'll open an MR as the next available alternative. > thanks a lot for these investigation. > > it is very appreciable You're welcome!
Bug#1078268: pyfai: please make the package build reproducible
Source: pyfai Severity: wishlist X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath cpu Dear Maintainer, I'm an occasional volunteer contributor to the Reproducible Builds[1] project, and noticed that the pyFAI package failed a recent automated build reproducibility test[2], as also reported in recent Salsa CI reprotest results[3]. I'm aware of two causes of non-determinism in the build so far: The first cause of non-determinism is the use of temporary directory paths by the meson-python build process; the resulting paths are embedded in some of the extension modules (for example, this[4] CRC32 module) produced in the output binary package. The meson-python build generates and uses a temporary, randomized build directory path only when no build-dir setting is already configured. So we may be able to resolve this problem by choosing an appropriate static build-dir. It appears that the Debian numpy package encountered a similar problem and applied[5] that same style of fix. The second non-deterministic output appears to be due to dynamic-evaluation of a 'threadpoolsize' default argument value for a Python initializer[6], which is set to the current host's CPU count. This would generally only be relevant at runtime, except for the fact that the documentation package, built using the Sphinx 'autodoc' extension, renders the evaluated value in the output HTML docs. That behaviour can be disabled using the 'autodoc_preserve_defaults'[7] configuration setting. I'll prepare patches and corresponding merge requests on Salsa to configure a fixed build-dir for the meson-python build process, and to configure Sphinx autodoc to preserve argument default signatures as they appear (unevaluated) in the source code. Regards, James [1] - https://reproducible-builds.org/ [2] - https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pyfai.html [3] - https://salsa.debian.org/science-team/pyfai/-/jobs/6077934 [4] - https://sources.debian.org/src/pyfai/2024.05-3/src/pyFAI/ext/meson.build/#L106-L107 [5] - https://salsa.debian.org/python-team/packages/numpy/-/commit/ece4cae7ceb221783be5ab56b46b1daf196dbc1f [6] - https://sources.debian.org/src/pyfai/2024.05-3/src/pyFAI/multi_geometry.py/?hl=62#L59-L62 [7] - https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html#confval-autodoc_preserve_defaults
Bug#1064404: snapd: please make the build reproducible.
Followup-For: Bug #1064404 Control: fixed -1 2.62-3 Control: close -1 The snapd package has been building reproducibly since 2.62-4. I'm tagging this bug as resolved from 2.62-3 because the patch here landed in that version. Thank you, Zygmunt!
Bug#119911: RFP: alephone -- marathon engine for related data games
Package: wnpp Followup-For: Bug #119911 Control: reopen -1
Bug#1076341: RFP: cinecred -- Cinecred produces credit sequences for film, TV and animations from spreadsheet input.
Package: wnpp Severity: wishlist X-Debbugs-Cc: j...@jp-hosting.net * Package name: cinecred Version : 1.5.1 Upstream Contact: Felix Mujkanovic * URL : https://cinecred.com/ * License : GPL-3 Programming Lang: Java Description : Cinecred produces credit sequences for film, TV and animations from spreadsheet input. Using a semi-structured spreadsheet format as input, Cinecred renders video files that can contain a mixture of title fade-in/outs and smooth-scrolling grouped role credits, with internationalization support. It is configurable and the website provides an accompanying user guide and informational screencast.
Bug#1075914: developers-reference: issue with sidebar in singlehtml variant on small screens
On Sun, 14 Jul 2024 at 11:58, James Addison wrote: > > On Fri, 12 Jul 2024 at 19:10, James Addison wrote: > > [ ... snip ... ] > > Adding the patch would unnecessarily add the event handler to _all_ menu > > items; > > now it seems to me that that's not what we want. We only need the event > > handler for links that refer to the same '.html' file. But: that is all of > > them in the 'singlehtml' build output. > > I'll have to check whether this works and is supported in most browsers, but > there is a CSS anchor:local-link pseudo-selector[1] that might allow filtering > to exactly these links. In combination with omitting the '.current' filter, > that would achieve the intended logical effect, I think. > > [1] - https://developer.mozilla.org/en-US/docs/Web/CSS/:local-link No, the local-link CSS pseudo-selector doesn't seem suitable: 1. It is not yet supported in many (any?) browsers. 2. As per the current draft CSS Working Group specification[1], the comparison of the hyperlink target URL against the current URL _includes_ the fragment (the part after the '#' symbol after the filename in the URL) in the comparison: [draft quote] "If the hyperlink's target includes a fragment URL, then the fragment URL of the current URL must also match; ..." [end draft quote] I've considered attaching the event handler to any menu hyperlinks whose href attribute starts with a '#' character (CSS queries can prefix-match[2]). However, currently some singlehtml menu hyperlinks contain the '.html' filename part. That may change if https://github.com/sphinx-doc/sphinx/pull/12551 is merged upstream. The next alternative would be to use some JQuery logic to dynamically attach to hyperlinks that are the same-document based on some custom logic. [1] - https://drafts.csswg.org/selectors/#the-local-link-pseudo [2] - https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors#links
Bug#1075914: developers-reference: issue with sidebar in singlehtml variant on small screens
On Fri, 12 Jul 2024 at 19:10, James Addison wrote: > [ ... snip ... ] > Adding the patch would unnecessarily add the event handler to _all_ menu > items; > now it seems to me that that's not what we want. We only need the event > handler for links that refer to the same '.html' file. But: that is all of > them in the 'singlehtml' build output. I'll have to check whether this works and is supported in most browsers, but there is a CSS anchor:local-link pseudo-selector[1] that might allow filtering to exactly these links. In combination with omitting the '.current' filter, that would achieve the intended logical effect, I think. [1] - https://developer.mozilla.org/en-US/docs/Web/CSS/:local-link
Bug#1075914: developers-reference: issue with sidebar in singlehtml variant on small screens
Control: tags -1 - patch My patch seemed too simple; I now think it's somewhat flawed, after learning more about what is going on here. On Wed, 10 Jul 2024 at 23:52, James Addison wrote: > [ ... snip ... ] > > In my opinion we should try to get this into src:sphinx-rtd-theme as a Debian > patch, and also to try to send it upstream. Let's *not* do this yet (explanation follows). I was trying to figure out the logic of the original CSS query: why only add the close-menu event handler to 'current' links in the (multi)HTML build? I think the explanation is that those are -- surprise surprise -- links to the current '.html' file; each link is an anchor, but no inter-webpage navigation is required for them. That means that the browser may _not_ reload the page entirely when following _those_ links in the multi-page HTML build -- and so the event is required to close the menu for accessibility/usability purposes - but only for that subset of hyperlinks. Adding the patch would unnecessarily add the event handler to _all_ menu items; now it seems to me that that's not what we want. We only need the event handler for links that refer to the same '.html' file. But: that is all of them in the 'singlehtml' build output. So, in fact I'm wondering about a different question: should the menu link tree (table of contents) be entirely expanded in 'singlehtml' format? And should the top-level item in the tree have the 'current' CSS class applied to it? Or, alternatively -- should 'sphinx_rtd_theme' somehow figure out that the page is a 'singlehtml' build, and omit '.current' from the CSS query in that case?
Bug#1075914: developers-reference: issue with sidebar in singlehtml variant on small screens
Hi Holger, On Tue, 9 Jul 2024 at 21:30, Holger Wansing wrote: > [ ... snip ... ] > > Your patch works for me (tested on laptop with Firefox in a small window > and on my smartphone). Thank you for testing it! I found that it was annoying to have to scroll all the way to the top of the page again with the fix in place - but I suppose that is a separate problem. > So the point is, how to integrate this in the manual... > > I think you know that this theme.js file is taken from sphinx-rtd-theme-common > package and the manual is just placing a symlink to that file. > So the correct fix long-term would be, to get it fixed in that package (thus > on > sphinx upstream), but how long would that take? > And will it ever happen? Or will upstream not change this, because it > conflicts > with other circumstances? In my opinion we should try to get this into src:sphinx-rtd-theme as a Debian patch, and also to try to send it upstream. Upstream in this case is not Sphinx itself, but the ReadTheDocs project; I've added a comment on the forwarded bugthread to let them know about the patch here, in the hope of offering it to them too, or being told about a better way to fix the same problem. > So, should we fix it for the meantime via a little hack in our Makefile > resp. debian/rules? I'd prefer to patch the 'theme.js' file directly. Although upstream minifies the JavaScript code from that file, we copy it nearly-unmodified: https://sources.debian.org/src/sphinx-rtd-theme/2.0.0%2Bdfsg-1/debian/rules/#L23 > > It would be nice to figure out whether the CSS query worked in the past; > > perhaps this bug is a regression. > > I don't know exactly what you mean by "the CSS query worked". > I can reproduce this issue here on Debian bookworm, which has sphinx > version 5.3.0 included, while the developers-reference package is getting > built on unstable with sphinx version 7.3.x. > I guess, this does not confirm the thesis of a regression? Browsing the code history, that CSS query appears in sphinx_rtd_theme.git (the upstream sources) as far back as v0.1.8 (Y2015) and earlier: https://github.com/readthedocs/sphinx_rtd_theme/blob/b5b633a8415de721b18e79bdf5d72a4973496fec/sphinx_rtd_theme/static/js/theme.js#L16 So although it may not be a recent regression, it's possible that it functioned correctly at the time it was written. If it did, then my suggested patch -- although it may seem to work -- could be a sidetrack. Regards, James
Bug#1075914: developers-reference: issue with sidebar in singlehtml variant on small screens
Followup-For: Bug #1075914
X-Debbugs-Cc: hwans...@mailbox.org
Control: reassign -1 src:sphinx-rtd-theme
Control: affects -1 developers-reference
Control: tags -1 patch
This seems to relate to the Sphinx ReadTheDocs theme, and when I went digging
around in the code there, it seemed that there is already a JavaScript event
handler[1] in 'theme.js' that is intended to close the sidebar menu when a
hyperlink is clicked. It seems that that handler isn't being called.
For multi-page HTML projects, that's generally not a problem because the
browser opens the requested link page and rebuilds the DOM, applies CSS etc
from scratch - and the sidebar is closed by default, so it appears to the user
that the click/navigation closed it.
The root cause seems to be something to do with the CSS select query that is
used to attach the event handler. I'm attaching a patch that resolved the
issue when I tested it locally -- and should be compatible with the Debian
package build.
It would be nice to figure out whether the CSS query worked in the past;
perhaps this bug is a regression.
[1] -
https://sources.debian.org/src/sphinx-rtd-theme/2.0.0%2Bdfsg-1/src/theme.js/#L88-L97
commit c34a308ef0afe4882d27498593028e94c7d58578
Author: James Addison
Date: Tue Jul 9 13:35:16 2024 +0100
JavaScript: attach sidebar close-on-click handler to all menu hyperlinks.
diff --git a/src/theme.js b/src/theme.js
index db546b4..b66a54e 100644
--- a/src/theme.js
+++ b/src/theme.js
@@ -86,7 +86,7 @@ function ThemeNav () {
})
// Nav menu link click operations
-.on('click', ".wy-menu-vertical .current ul li a", function() {
+.on('click', ".wy-menu-vertical ul li a", function() {
var target = $(this);
// Close menu when you click a link.
$("[data-toggle='wy-nav-shift']").removeClass("shift");
Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error
Package: python3-django-hyperkitty Followup-For: Bug #1031928 X-Debbugs-Cc: p...@debian.org Control: forwarded -1 https://gitlab.com/mailman/hyperkitty/-/issues/503 Thanks Pierre-Elliott for opening the bugreport (forwarded) for this upstream.
Bug#998059: sphinx: LANGUAGE environment variable inconsistently affects output of objects.inv
Followup-For: Bug #998059 Control: forwarded -1 https://github.com/sphinx-doc/sphinx/pull/10067 Control: close -1 This variance in Sphinx project 'objects.inv' output files was resolved by a change within Sphinx that added a default config language code. That change stabilized the output of gettext-based translation resource loading, removing variance based on the build host's LANGUAGE environment variable.
Bug#1042955: zzzeeksphinx: please make the output reproducible
Source: zzzeeksphinx Followup-For: Bug #1042955 Control: tags -1 - pending Control: fixed -1 1.5.0-1 Control: close -1 I think this can be closed; the reproducibility fix here was included in the upload of 1.5.0-1 and appears to be working well: mako is building reproducibly. There may be other nondeterminism issue(s) to track down in sqlalchemy but those do not appear to be related to this bug. If I'm mistaken and/or there's another reason to keep this active, please feel free to re-open the bug.
Bug#1029843: Missing symlinks for RPi 4 (to brcmfmac43455-sdio.raspberrypi,4-model-b.txt)
Package: firmware-brcm80211 Followup-For: Bug #1029843 X-Debbugs-Cc: b...@decadent.org.uk, didi.deb...@cknow.org, k...@debian.org, p...@akeo.ie Thanks all for figuring this out and providing fixes - the updated contents of the firmware-brcm80211 20230625-3~exp3 package look good to me.
Bug#1070208: openttd: cmake licensing concern for openttd 14.0 source package
Thank you Matthijs!
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 thoug
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&DEFAULTOP=and&B=Gdebian-testing-changes&SORT=0&HITSPERPAGE=100&xP=python%09removal&xFILTERS=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
