[PATCH] gnu: librewolf: Support Guix icecat browser extensions.

  • Done
  • quality assurance status badge
Details
3 participants
  • Clément Lassieur
  • Hilton Chain
  • Ian Eure
Owner
unassigned
Submitted by
Hilton Chain
Severity
normal
H
H
Hilton Chain wrote on 11 Dec 16:07 +0100
(address . guix-patches@gnu.org)(name . Hilton Chain)(address . hako@ultrarare.space)
fbe13c2e0bd1f1bd9c2f49398ade9d45480774ba.1733929563.git.hako@ultrarare.space
* gnu/packages/patches/librewolf-use-system-wide-dir.patch: New file.
* gnu/local.mk (dist_patch_DATA): Regisiter it.
* gnu/packages/librewolf.scm (make-librewolf-source)[patches]: Add it along with
torbrowser-compare-paths.patch.
(librewolf)[native-search-paths]: Add ICECAT_SYSTEM_DIR.

Change-Id: I8609d25a7e2725ad94ab257d720326639eb06778
---

Reused torbrowser-compare-paths.patch, mind it for future updates. :)

gnu/local.mk | 1 +
gnu/packages/librewolf.scm | 11 +++++-
.../librewolf-use-system-wide-dir.patch | 37 +++++++++++++++++++
3 files changed, 48 insertions(+), 1 deletion(-)
create mode 100644 gnu/packages/patches/librewolf-use-system-wide-dir.patch

Toggle diff (93 lines)
diff --git a/gnu/local.mk b/gnu/local.mk
index 2d85c485f6..0faa3a70a9 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1635,6 +1635,7 @@ dist_patch_DATA = \
%D%/packages/patches/libgpg-error-hurd64.patch \
%D%/packages/patches/libguestfs-syms.patch \
%D%/packages/patches/libobjc2-unbundle-robin-map.patch \
+ %D%/packages/patches/librewolf-use-system-wide-dir.patch \
%D%/packages/patches/libvirt-add-install-prefix.patch \
%D%/packages/patches/libziparchive-add-includes.patch \
%D%/packages/patches/lightdm-arguments-ordering.patch \
diff --git a/gnu/packages/librewolf.scm b/gnu/packages/librewolf.scm
index 5d432cfad8..7ea14c9182 100644
--- a/gnu/packages/librewolf.scm
+++ b/gnu/packages/librewolf.scm
@@ -188,7 +188,11 @@ (define* (make-librewolf-source #:key version firefox-hash librewolf-hash)
(invoke "make" "all")
(copy-file (string-append "librewolf-" #$version
".source.tar.gz")
- #$output))))))))
+ #$output)))))
+ (patches
+ (search-patches
+ "torbrowser-compare-paths.patch"
+ "librewolf-use-system-wide-dir.patch")))))

;; Define the versions of rust needed to build librewolf, trying to match
;; upstream. See the file taskcluster/ci/toolchain/rust.yml at
@@ -705,6 +709,11 @@ (define-public librewolf
rust-cbindgen-0.26
which
yasm))
+ (native-search-paths
+ (list (search-path-specification
+ (variable "ICECAT_SYSTEM_DIR")
+ (separator #f) ;single entry
+ (files '("lib/icecat")))))
(home-page "https://librewolf.net/")
(synopsis
"Custom version of Firefox, focused on privacy, security and freedom")
diff --git a/gnu/packages/patches/librewolf-use-system-wide-dir.patch b/gnu/packages/patches/librewolf-use-system-wide-dir.patch
new file mode 100644
index 0000000000..c8a4d8cb12
--- /dev/null
+++ b/gnu/packages/patches/librewolf-use-system-wide-dir.patch
@@ -0,0 +1,37 @@
+Replace "/usr/lib/librewolf" (the system-wide directory for extensions and
+native manifests) with "$ICECAT_SYSTEM_DIR".
+
+diff --git a/toolkit/xre/nsXREDirProvider.cpp b/toolkit/xre/nsXREDirProvider.cpp
+index 0cbc825738..5c0bf6ae7f 100644
+--- a/toolkit/xre/nsXREDirProvider.cpp
++++ b/toolkit/xre/nsXREDirProvider.cpp
+@@ -280,25 +280,11 @@ nsresult nsXREDirProvider::GetBackgroundTasksProfilesRootDir(
+ static nsresult GetSystemParentDirectory(nsIFile** aFile) {
+ nsresult rv;
+ nsCOMPtr<nsIFile> localDir;
+-# if defined(XP_MACOSX)
+- rv = GetOSXFolderType(kOnSystemDisk, kApplicationSupportFolderType,
+- getter_AddRefs(localDir));
+- if (NS_SUCCEEDED(rv)) {
+- rv = localDir->AppendNative("LibreWolf"_ns);
+- }
+-# else
+- constexpr auto dirname =
+-# ifdef HAVE_USR_LIB64_DIR
+- "/usr/lib64/librewolf"_ns
+-# elif defined(__OpenBSD__) || defined(__FreeBSD__)
+- "/usr/local/lib/librewolf"_ns
+-# else
+- "/usr/lib/librewolf"_ns
+-# endif
+- ;
+- rv = NS_NewNativeLocalFile(dirname, getter_AddRefs(localDir));
+-# endif
++ const char* systemParentDir = getenv("ICECAT_SYSTEM_DIR");
++ if (!systemParentDir || !*systemParentDir) return NS_ERROR_FAILURE;
+
++ rv = NS_NewNativeLocalFile(nsDependentCString(systemParentDir),
++ getter_AddRefs(localDir));
+ if (NS_SUCCEEDED(rv)) {
+ localDir.forget(aFile);
+ }

base-commit: c2e2b0376b82a503e064fa826d1b153d94bf0b06
prerequisite-patch-id: f132b4af7b85df465998e4f459bf729f8b66f320
prerequisite-patch-id: ecd87e69b7aebebd64256db106ed96dc12f6c12d
prerequisite-patch-id: f27c33b6c7f5dcb37c36551ecde29f1f0c734935
prerequisite-patch-id: fc6ad5af54f75869a657c065c86b262d74a1efff
prerequisite-patch-id: 1665e62d1990a460bc5679bc89d600e94bab407a
prerequisite-patch-id: e1cd1fdc5036bbd74d338df158ae7c348b180cf4
prerequisite-patch-id: bea29848814b393ccd3619f0a744ee36632ac5df
--
2.46.0
C
C
Clément Lassieur wrote on 11 Dec 21:28 +0100
9fa8a43a-1228-4fea-a0a4-4850b7f54ebb@app.fastmail.com
On Wed, Dec 11, 2024, at 4:07 PM, Hilton Chain wrote:
Toggle quote (10 lines)
> * gnu/packages/patches/librewolf-use-system-wide-dir.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Regisiter it.
> * gnu/packages/librewolf.scm (make-librewolf-source)[patches]: Add it along with
> torbrowser-compare-paths.patch.
> (librewolf)[native-search-paths]: Add ICECAT_SYSTEM_DIR.
>
> Change-Id: I8609d25a7e2725ad94ab257d720326639eb06778
> ---
>
> Reused torbrowser-compare-paths.patch, mind it for future updates. :)
Indeed, if I understand well, both files can be merged once Icecat is up to date.

Looks good to me, thank you!
Attachment: file
I
I
Ian Eure wrote on 13 Dec 18:38 +0100
(name . Hilton Chain)(address . hako@ultrarare.space)
87bjxf8oup.fsf@retrospec.tv
Hi Hilton,

The patches look good to me, thank you for taking this on! How to
handle browser extensions is a subject that’s been on my mind
intermittently, so it’s great to see effort in that direction.

I think it might be non-obvious that IceCat packages affect
non-IceCat browsers. I’d really like to have a solid facility for
managing extensions across the different Firefox forks, either
with generic "browser-extension-ublock-origin" packages; or
something similar to the Common Lisp setup, where
implementation-specific package variants can be derived from a
canonical one. I lean somewhat towards the latter approach, since
I think it provides a cleaner way of handling differences across
browsers. Given the different release cadences, I think it makes
sense to abstract over the differences in the build tooling rather
than patching the browsers to get consistent behavior.

To be clear here, these patches don’t have to wait for that; I’m
+1 on pushing as-is. But I think we should have a more explicit
system for handling browser extension packages.

Thanks,
-- Ian

Hilton Chain <hako@ultrarare.space> writes:

Toggle quote (73 lines)
> * gnu/packages/patches/librewolf-use-system-wide-dir.patch: New
> file.
> * gnu/local.mk (dist_patch_DATA): Regisiter it.
> * gnu/packages/librewolf.scm (make-librewolf-source)[patches]:
> Add it along with
> torbrowser-compare-paths.patch.
> (librewolf)[native-search-paths]: Add ICECAT_SYSTEM_DIR.
>
> Change-Id: I8609d25a7e2725ad94ab257d720326639eb06778
> ---
>
> Reused torbrowser-compare-paths.patch, mind it for future
> updates. :)
>
> gnu/local.mk | 1 +
> gnu/packages/librewolf.scm | 11 +++++-
> .../librewolf-use-system-wide-dir.patch | 37
> +++++++++++++++++++
> 3 files changed, 48 insertions(+), 1 deletion(-)
> create mode 100644
> gnu/packages/patches/librewolf-use-system-wide-dir.patch
>
> diff --git a/gnu/local.mk b/gnu/local.mk
> index 2d85c485f6..0faa3a70a9 100644
> --- a/gnu/local.mk
> +++ b/gnu/local.mk
> @@ -1635,6 +1635,7 @@ dist_patch_DATA = \
> %D%/packages/patches/libgpg-error-hurd64.patch \
> %D%/packages/patches/libguestfs-syms.patch \
> %D%/packages/patches/libobjc2-unbundle-robin-map.patch \
> + %D%/packages/patches/librewolf-use-system-wide-dir.patch \
> %D%/packages/patches/libvirt-add-install-prefix.patch \
> %D%/packages/patches/libziparchive-add-includes.patch \
> %D%/packages/patches/lightdm-arguments-ordering.patch \
> diff --git a/gnu/packages/librewolf.scm
> b/gnu/packages/librewolf.scm
> index 5d432cfad8..7ea14c9182 100644
> --- a/gnu/packages/librewolf.scm
> +++ b/gnu/packages/librewolf.scm
> @@ -188,7 +188,11 @@ (define* (make-librewolf-source #:key
> version firefox-hash librewolf-hash)
> (invoke "make" "all")
> (copy-file (string-append "librewolf-" #$version
> ".source.tar.gz")
> - #$output))))))))
> + #$output)))))
> + (patches
> + (search-patches
> + "torbrowser-compare-paths.patch"
> + "librewolf-use-system-wide-dir.patch")))))
>
> ;; Define the versions of rust needed to build librewolf,
> trying to match
> ;; upstream. See the file taskcluster/ci/toolchain/rust.yml at
> @@ -705,6 +709,11 @@ (define-public librewolf
> rust-cbindgen-0.26
> which
> yasm))
> + (native-search-paths
> + (list (search-path-specification
> + (variable "ICECAT_SYSTEM_DIR")
> + (separator #f) ;single entry
> + (files '("lib/icecat")))))
> (home-page "https://librewolf.net/")
> (synopsis
> "Custom version of Firefox, focused on privacy, security
> and freedom")
> diff --git
> a/gnu/packages/patches/librewolf-use-system-wide-dir.patch
> b/gnu/packages/patches/librewolf-use-system-wide-dir.patch
> new file mode 100644
> index 0000000000..c8a4d8cb12
>
C
C
Clément Lassieur wrote on 13 Dec 19:15 +0100
ce1e8538-afa0-4266-b823-d55574238399@app.fastmail.com
Hi Ian,

On Fri, Dec 13, 2024, at 6:38 PM, Ian Eure wrote:
Toggle quote (12 lines)
> The patches look good to me, thank you for taking this on! How to
> handle browser extensions is a subject that’s been on my mind
> intermittently, so it’s great to see effort in that direction.
>
> I think it might be non-obvious that IceCat packages affect
> non-IceCat browsers. I’d really like to have a solid facility for
> managing extensions across the different Firefox forks, either
> with generic "browser-extension-ublock-origin" packages; or
> something similar to the Common Lisp setup, where
> implementation-specific package variants can be derived from a
> canonical one.

I've looked into having variant-specific extensions already
(https://issues.guix.gnu.org/68298),and I came to the conclusion that it
added a lot of complexity for little benefits. Maybe I was wrong and you
thought of a better implementation? Still, I think most of the time users
would want their "system add-ons" to be available on all browsers. When this
is not the case, they can already use 'guix shell' to run a Firefox variant
with a different set of extensions, or use the built-in add-on system.

We can however add clarity where things are unclear.

Cheers,
Clément

Toggle quote (9 lines)
> I lean somewhat towards the latter approach, since
> I think it provides a cleaner way of handling differences across
> browsers. Given the different release cadences, I think it makes
> sense to abstract over the differences in the build tooling rather
> than patching the browsers to get consistent behavior.
>
> To be clear here, these patches don’t have to wait for that; I’m
> +1 on pushing as-is. But I think we should have a more explicit
> system for handling browser extension packages.
Attachment: file
H
H
Hilton Chain wrote 7 days ago
(address . 74790-done@debbugs.gnu.org)
87r065aro0.wl-hako@ultrarare.space
Hi!
I have applied the patch as 396eb759d4a7be6756c1460c52067d320673859f.
On Sat, 14 Dec 2024 02:15:11 +0800,
Clément Lassieur wrote:
Toggle quote (13 lines)
>
> [1 <text/plain; utf-8 (quoted-printable)>]
> Hi Ian,
>
> On Fri, Dec 13, 2024, at 6:38 PM, Ian Eure wrote:
> > The patches look good to me, thank you for taking this on! How to
> > handle browser extensions is a subject that’s been on my mind
> > intermittently, so it’s great to see effort in that direction.
> >
> > I think it might be non-obvious that IceCat packages affect
> > non-IceCat browsers. I’d really like to have a solid facility for
> > managing extensions across the different Firefox forks, either
> > with generic "browser-extension-ublock-origin" packages; or
There're also chromium extensions using same sources but with a different build
process. So to use generic names I think one approach is to use both build
processes in one package and use output names for distinction, but it'll be
harder to find all available extensions, for example currently via
‘guix search "\-icecat$"’.
Toggle quote (13 lines)
> > something similar to the Common Lisp setup, where
> > implementation-specific package variants can be derived from a
> > canonical one.
>
> I've looked into having variant-specific extensions already
> (https://issues.guix.gnu.org/68298), and I came to the conclusion that it
> added a lot of complexity for little benefits. Maybe I was wrong and you
> thought of a better implementation? Still, I think most of the time users
> would want their "system add-ons" to be available on all browsers. When this
> is not the case, they can already use 'guix shell' to run a Firefox variant
> with a different set of extensions, or use the built-in add-on system.
>
> We can however add clarity where things are unclear.
Agree, we can document that extensions are also available for our web browsers,
with name -chromium for ungoogled-chromium and -icecat for Firefox-based ones.
Closed
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 74790@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 74790
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch