From: Ian Eure <ian@retrospec.tv>
To: Nikita Domnitskii <nikita@domnitskii.me>
Cc: 72265@debbugs.gnu.org
Subject: [bug#72265] [PATCH 0/1] Fix hardware acceleration support for librewolf
Date: Sat, 17 Aug 2024 15:20:02 -0700 [thread overview]
Message-ID: <874j7i6aqm.fsf@meson> (raw)
In-Reply-To: <87ed7a5etn.fsf@domnitskii.me>
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
prev parent reply other threads:[~2024-08-17 22:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-24 5:44 [bug#72265] [PATCH 0/1] Fix hardware acceleration support for librewolf Nikita Domnitskii via Guix-patches via
2024-07-24 5:44 ` [bug#72265] [PATCH 1/1] gnu: librewolf: Add guix drivers paths to RDD whitelist Nikita Domnitskii via Guix-patches via
2024-07-31 0:12 ` [bug#72265] [PATCH 0/1] Fix hardware acceleration support for librewolf Ian Eure
2024-07-31 5:08 ` Nikita Domnitskii via Guix-patches via
2024-08-17 22:20 ` Ian Eure [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874j7i6aqm.fsf@meson \
--to=ian@retrospec.tv \
--cc=72265@debbugs.gnu.org \
--cc=nikita@domnitskii.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.