Hi, "Mason Hock" <[email protected]> skribis:
> On Thu Sep 10, 2020 at 1:00 AM PDT, Ludovic Courtès wrote: >> Hi, >> >> chaosmonk <[email protected]> skribis: >> >> > ungoogled-chromium receives frequent security updates, so it is >> > important for users to keep it up-to-date. However, binary >> > substitutes for the latest version are usually not available, and it >> > can take a very long time to build from source, possibly multiple >> > days on low-end hardware. This might tempt or force some users to put >> > off upgrading the package and run an older, vulnerable version until a >> > binary substitute is available or they have a chance to set aside the >> > uptime needed to build from source. >> > >> > I don't know what Guix's CI system looks like or how packages are >> > queued for building, but if there is a way to prioritize builds for >> > certain packages, I propose that substitutes for packages like >> > ungoogled-chromium should be built as soon as possible once there is a >> > new version. Other security-critical packages with potentially long >> > build times that come to mind are icecat and linux-libre. >> >> Thanks for your feedback. Our build farm has often been lagging behind >> lately and that’s something we’ve been working on. The >> ungoogled-chromium package is even more problematic because it takes >> more than ~80 CPU-hours to build, and that often times out with our >> current build farm settings (where we don’t allow builds to take more >> than 6h, IIRC). > > Yes, Chromium's build time is obscene. However, not providing > substitutes for it duplicates that problem to the machines of every Guix > user who uses ungoogled-chromium. In the time that it would take Guix's > build farm to build u-c it could probably build many other packages, but > users are in the exact same situation, so a substitute for u-c is likely > more valuable to them than substitutes for those other packages. If it > is possible to override the 6h timeout value for individual packages, I > think that it would be worth doing so for u-c, and perhaps for Icecat > and Linux-libre as well. Definitely, yes. I just meant to explain why the build farm often lacks u-c substitutes currently, but I agree it must be addressed. Ludo’.
