guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#72265] [PATCH 0/1] Fix hardware acceleration support for librewolf


From: Ian Eure
Subject: [bug#72265] [PATCH 0/1] Fix hardware acceleration support for librewolf
Date: Sat, 17 Aug 2024 15:20:02 -0700
User-agent: mu4e 1.8.13; emacs 28.2

Hi Nikita,

Nikita Domnitskii <nikita@domnitskii.me> writes:

Ian Eure <ian@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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]