Package: guix-patches;
Reported by: Ian Eure <ian <at> retrospec.tv>
Date: Wed, 22 May 2024 14:54:02 UTC
Severity: normal
Tags: patch
Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: Ian Eure <ian <at> retrospec.tv> To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com> Cc: 71121 <at> debbugs.gnu.org Subject: [bug#71121] [PATCH 2/3] gnu: librewolf: Rebuild source tarball Date: Wed, 29 May 2024 18:48:11 -0700
Hi Maxim, Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes: > Hi Ian, > > Ian Eure <ian <at> retrospec.tv> writes: > >> * gnu/packages/librewolf.scm (librewolf): This patch removes an >> intermediate >> step in the build chain. The upstream source tarball is >> created with an >> automated build process, where Firefox sources are fetched, >> patched, and >> repacked. Rather than download the output of that process, as >> the package has >> been, it’s now replicated within the build process, similar to >> how IceCat >> works. > > I think I'd rather keep using a human-prepared and vetted > tarball, to > avoid anything going stale in our local recipe of how it's meant > to be > prepared. > The upstream tarball is built by scripts run under a CI system which triggers when changes are pushed[1], and aren’t human-prepared or vetted in the same way that many release tarballs have tradionally been. This patchset uses the same script as upstream, with modifications to make it reproduceable, as the upstream process isn’t. As noted in the commit messages, IceCat also builds this way[2], including patching the upstream build script[3][4], so this seems like a reasonable & accepted way to build. Though perhaps there’s dissatisfaction with the IceCat build which I wasn’t aware of, being a fairly new contributor. > It's also simpler and less maintenance, and arguably shields > the users better against non-free source code (although I don't > think > there's anything non-free in the Firefox tree, so that point is > more > moot than say, for linux) to use a tarball. > > What do you or others think? > It’s definitely simpler to use the upstream tarball in most cases, which is why I went that direction when I initially packaged LibreWolf. But, since IceCat builds this way, and the xz backdoor was discovered hiding in the non-reproduceable build process, I’ve been intending to update the package to control the full build, rather than trusting an unreproducable external process. I understand that if the build scripts are backdoored, it doesn’t matter whether upstream runs them or Guix does, but I believe that aligning with IceCat and having a reproduceable build directly from the upstream source repo are worthwhile. In the specific case of the 126.0-1 release, owning the whole build process made things easier. Upstream backported a very large Firefox change[5] which updates a bundled dependency to a new version; that dependency doesn’t work with Rust 1.75, which is what’s in Guix. With the Guix build process controlling what patches get applied, I was able to solve the problem by removing one line from the manifest of patches to apply to the Firefox source. If the package builds from the 126.0-1 tarball, it’ll need to ship a 22,000-line patch(!) to back out that change. That may still be necessary, depending on the timing of the rust-team branch merging and the next Firefox release, but at least for now, things are simpler. Ideally, this wolud be solved by unbundling that (and the other) vendored Rust libraries (and that’s something I intend to look into), but I didn’t want to block security fixes on work with unknown-but-probably-large scope -- there will almost definitely be Rust libraries currently not packaged in Guix which need to be addressed. As far as maintenance burden or things getting stale, the risk is that upstream alters their scripts, which requires updates to the Guix patches for them. This doesn’t seem like a major drawback to me, and I’m the one doing the maintenance. :) Overall, I think it’s a reasonable tradeoff for the reproducability we gain. If this approach to building LibreWolf in this patchset is acepted, I’d like to work with upstream to make their build process more flexible, ideally running it unmodified in the Guix build, which would eliminate the risk. Lastly: I noticed that I neglected to update %librewolf-build-id when I sent this patchset in. If my arguments are compelling enough for you, I think it’d make sense to update that when the changes are pushed (it’s a one-line change & the command to print an ID are in the comment above the variable). But, if you’d like a v2 patchset, either just to update that, or to back out the build process change and replace it with a 22kloc patch, I’d be happy to handle it instead. Thank you very much for your thoughts and the time you took to respond. — Ian [1]: https://codeberg.org/librewolf/source/actions/runs/168/jobs/0 [2]: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnuzilla.scm?id=898b5f30f3d485d48275c920da172863da9524c6#n530 [3]: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnuzilla.scm?id=898b5f30f3d485d48275c920da172863da9524c6#n571 [4]: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/icecat-makeicecat.patch [5]: https://codeberg.org/librewolf/source/commit/d292bdd2213a22e5b364339dfee68a27670f1b72
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.