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. > Right now we’re trying to improve build throughput in general but your > proposal makes sense, of course. > > Thanks, > Ludo’.
