GNU bug report logs - #71121
[PATCH 0/3] Update LibreWolf to 126.0-1 [security fixes]

Previous Next

Full log

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: Sat, 01 Jun 2024 09:30:23 -0700

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> Hi Ian,
>
> Ian Eure <ian <at> retrospec.tv> writes:
>
>> 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.
>
> Perhaps the modifications to make it reproducible could be 
> shared to
> upstream?  We'd benefit all thee users of librewolf this way, 
> not only
> Guix ones.
>

Yes, I plan to work with upstream on this.  The current 
modifications are Guix-specific, but I believe a mechanism which 
allows for both better upstream reproducability and less hacky 
Guix packaging is possible.


>> 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.
>
> The "dissatisfaction", if we can call it that, was about 
> Linux-libre,
> and voiced by some a few years ago, including the project 
> maintainers,
> if I recall correctly.  The idea of linux-libre is to shield 
> users from
> blobs.  In this sense it is valuable that they don't even have 
> to touch
> the pristine blobbed (there are a few array-defined firmwares in 
> the
> tree still, at least one old Apple one IIRC) Linux source, which 
> is
> considered problematic for some from a GNU FSDG perspective.
>

Gotcha.  I agree that these are unlikely to apply here.

Thank you for pushing this, and I’ll try to get commit messages 
closer to the convention in the future.

 — Ian

Previous Next

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