GNU bug report logs - #72265
[PATCH 0/1] Fix hardware acceleration support for librewolf

Previous Next

Full log

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

From: Ian Eure <ian <at> retrospec.tv>
To: Nikita Domnitskii <nikita <at> domnitskii.me>
Cc: 72265 <at> debbugs.gnu.org
Subject: Re: [PATCH 0/1] Fix hardware acceleration support for librewolf
Date: Sat, 17 Aug 2024 15:20:02 -0700

Hi Nikita,

Nikita Domnitskii <nikita <at> domnitskii.me> writes:

> Ian Eure <ian <at> retrospec.tv> writes:
>
>> Since a lot of system config stuff ends up in there, and Guix 
>> doesn’t
>> have a good way to manage secrets, it feels risky to me to open 
>> it up.
>
> Is it really an issue?  Any program on your system already does 
> that,
> why LW any different?  It's a good enough solution for NixOS/FF 
> not sure
> why we have to do something different here.
>

I think it’s worth considering.  While any program can read the 
store, few of them run the huge volume of untrusted code that a 
web browser does.

That said, I’m okay with this approach.  Ideally, I’d like it to 
be a stopgap solution, but it’s a clear improvement on the current 
situation.  However, there are two changes I’d like to see:

1. Please remove the source patching from `make-librewolf-source' 
and move it into the librewolf package definition. 
`make-librewolf-source' is intended to produce a source tarball 
identical to upstream, and isn’t a good place to be adding 
Guix-specific patches.

2. Use the `substitute*' procedure instead of a patch file.  I 
maintain LibreWolf in my personal channel first, then contribute 
patches to Guix, and the patch file facility doesn’t work outside 
the main Guix repository.  I work this way because I’m not a Guix 
committer, and would like to run the latest version of LibreWolf. 
Guix is often several versions behind due to intractable delays in 
patch review.

With those two changes, your patch has my +1.  Though as noted, I 
cannot commit it, since I don’t have those privileges.


>> The approach in LW is taken directly from the Firefox packages 
>> in 
>> Nonguix -- can you reproduce your problem with that packages?
>
> I can and it never worked for me.  I used to mantain my LW 
> package
> definition[1] where I put neccesary paths to LD_LIBRARY_PATH, 
> but that
> solution very specific to my setup and would not work as a 
> general one.
>

Would you please file a bug report with them?  I’d be interested 
to hear what they have to say on the subject.

Thanks,

 — Ian

Previous Next

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