GNU bug report logs - #43075
Prioritize providing substitutes for security-critical packages with potentially long build times

Previous Next

Full log

Message #47 received at 43075 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: 43075 <at> debbugs.gnu.org, chaosmonk <chaosmonk <at> riseup.net>
Subject: Re: bug#43075: Prioritize providing substitutes for
 security-critical packages with potentially long build times
Date: Fri, 11 Sep 2020 16:45:02 +0200

Hi,

zimoun <zimon.toutoune <at> gmail.com> skribis:

> On Fri, 11 Sep 2020 at 08:56, Ludovic Courtès <ludo <at> gnu.org> wrote:
>
>> > The recent updates of ungoogled-chromium do not mention [security
>> > updates].  Well, I do not know if they are.  So the question would be:
>> > what triggers the special security build?
>>
>> To me the proposal is more about introducing scheduling priorities.  For
>> these packages, it’s indeed safe to assume that every new release brings
>> security fixes.
>
> Why would some packages be prioritized on the build farm than others?
> Based on what?   Which criteria?
> Popularity?  But we do not measure (yet?) how many times a substitute
> is downloaded.
> For example, I do not use ungoogled-chromium so I would prefer that
> the resources of the build farm would be spent on these X packages.
> Bob and Alice, they would prefer these Y packages.  How do we reach a
> consensus?
> And security is one criteria.  But how to detect it is a security fix?
>
> (Aside the issue of ungoogled-chromium about the time limit you
> described; which should be fixed, obviously. :-))

All we’re saying is that for some packages, we should always assume that
new releases bring security fixes.  These are key packages like
Linux-libre, IceCat, ungoogled-chromium, etc.

Furthermore, ungoogled-chromium is practically not buildable on one’s
laptop, and thus it’s even more important to provide substitutes.

For now, the focus should be on improving overall build throughput since
there’s a lot of room for improvement.

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.