| Message ID | cover.1701186634.git.ian@retrospec.tv |
|---|---|
| Headers | show |
| Series | Add LibreWolf | expand |
I mentioned in #guix that I was working on a package for LibreWolf, and it was requested that I send in patches, so I am. These changes are based on the firefox-esr package in nonguix; I've retained the copyright / authorship notices from there. LibreWolf (https://librewolf.net/) is a fork of Firefox which removes the telemetry and advertising, and bundles uBlock Origin. It doesn't have the redistribution issues that Firefox does, its name/logo are under MPL 2.0 and aren't trademarked. I'm new to Guix, and not remotely a browser development expert, so I don't expect these are ready to be accepted yet, but I believe they're in good enough shape to have a discussion about. Guide to changes in this patchset ================================= icu4c has been updated to 73.1, and the previous version kept as icu4c-71. I encountered consistent failures of the node@10.24.1 test suite with icu4c 73.1, so I kept that on 71.1. icu4c is needed by many packages, so this change is the highest-impact in the patchset. The (gnu packages wasm) module is unchanged from nonguix, except for the file header and module declaration. The (gnu packages librewolf) module is a simplified/adapted version of (nongnu packages firefox). The Firefox Nightly packages have been removed, as there's no LibreWolf equivalent. I also didn't bring over the wayland variant, but I could, if that's desired. I'm not sure why there are specific x11/wayland variants, as the packages for other distros don't seem to need this split. The librewolf package has some functions duplicated from (gnu packages gnuzilla), which probably ought to get factored out and put somewhere, but I'm not sure if they should be in (gnu packages mozilla) or a different module. Guidance would be appreciated here. Ian Eure (5): gnu: icu4c: Update to 73.1. gnu: Add icu4c-71. gnu: node: Switch to icu4c-71. gnu: Add wasm packages. gnu: Add librewolf. gnu/packages/icu4c.scm | 21 +- gnu/packages/librewolf.scm | 560 +++++++++++++++++++++++++++++++++++++ gnu/packages/node.scm | 4 +- gnu/packages/wasm.scm | 273 ++++++++++++++++++ 4 files changed, 854 insertions(+), 4 deletions(-) create mode 100644 gnu/packages/librewolf.scm create mode 100644 gnu/packages/wasm.scm base-commit: 2410a30f6c06d56b5589e0ad685bcdf09bb144bf
Hi! Ian Eure <ian@retrospec.tv> skribis: > I mentioned in #guix that I was working on a package for LibreWolf, and it was requested that I send in patches, so I am. These changes are based on the firefox-esr package in nonguix; I've retained the copyright / authorship notices from there. > > LibreWolf (https://librewolf.net/) is a fork of Firefox which removes the telemetry and advertising, and bundles uBlock Origin. It doesn't have the redistribution issues that Firefox does, its name/logo are under MPL 2.0 and aren't trademarked. > > I'm new to Guix, and not remotely a browser development expert, so I don't expect these are ready to be accepted yet, but I believe they're in good enough shape to have a discussion about. They're working acceptably well for me, though I'm not currently daily driving Guix, so there may be issues I haven't encountered yet. This is much appreciated! People often complain that IceCat is based on too old a version of Firefox, so if we can have LibreWolf (or even Firefox without its problematic bits), that’s great. > The librewolf package has some functions duplicated from (gnu packages gnuzilla), which probably ought to get factored out and put somewhere, but I'm not sure if they should be in (gnu packages mozilla) or a different module. Guidance would be appreciated here. To me that’s the main issue here: these packages are complex, and I wouldn’t want us to end up with two (or more!) copies of these beasts. As the person who made the changes, it would be great if you could pinpoint things that had to be changed compared to ‘icecat’. What phases or flags differ? What phases can be factorized? Thanks for your hard work! Ludo’.
Hi, thank you very much for your comments. Ludovic Courtès <ludo@gnu.org> writes: > Hi! > > Ian Eure <ian@retrospec.tv> skribis: > >> I mentioned in #guix that I was working on a package for >> LibreWolf, >> and it was requested that I send in patches, so I am. These >> changes >> are based on the firefox-esr package in nonguix; I've retained >> the >> copyright / authorship notices from there. >> >> LibreWolf (https://librewolf.net/) is a fork of Firefox which >> removes the telemetry and advertising, and bundles uBlock >> Origin. >> It doesn't have the redistribution issues that Firefox does, >> its >> name/logo are under MPL 2.0 and aren't trademarked. >> >> I'm new to Guix, and not remotely a browser development expert, >> so I >> don't expect these are ready to be accepted yet, but I believe >> they're in good enough shape to have a discussion about. >> They're >> working acceptably well for me, though I'm not currently daily >> driving Guix, so there may be issues I haven't encountered yet. > > This is much appreciated! People often complain that IceCat is > based on > too old a version of Firefox, so if we can have LibreWolf (or > even > Firefox without its problematic bits), that’s great. > IMO, LibreWolf pretty much is Firefox without the problematic bits. It’s been my default browser for several years, and I’m very satisfied with it. >> The librewolf package has some functions duplicated from (gnu >> packages gnuzilla), which probably ought to get factored out >> and put >> somewhere, but I'm not sure if they should be in (gnu packages >> mozilla) or a different module. Guidance would be appreciated >> here. > > To me that’s the main issue here: these packages are complex, > and I > wouldn’t want us to end up with two (or more!) copies of these > beasts. > > As the person who made the changes, it would be great if you > could > pinpoint things that had to be changed compared to ‘icecat’. > What > phases or flags differ? What phases can be factorized? > This work isn’t based on the icecat package, but on the firefox-esr package from nonguix. The duplication I refer to is two small helper functions, `runpath-of' and `runpaths-of-input', totaling nine lines of code; they’re flagged with a comment in the patch. As mentioned in the cover letter, I’m happy to extract these, I just don’t know where they ought to be placed. They’re defined inside a lambda in a gexp, which sounds like it may be challenging to put somewhere accessible to both packages. Skimming the icecat package, not many of the build steps are shared with librewolf, and factoring the commonalities out would IMO result in overly complex, brittle, hard to maintain code that’s worse than the slight duplication between the two packages. If there’s a strong feeling that they must be accounted for, I’ll give it a try, but I don’t believe that it’s the best option. Thanks, — Ian
Hi Ian, Ian Eure <ian@retrospec.tv> skribis: > Ludovic Courtès <ludo@gnu.org> writes: [...] >> This is much appreciated! People often complain that IceCat is >> based on >> too old a version of Firefox, so if we can have LibreWolf (or even >> Firefox without its problematic bits), that’s great. >> > > IMO, LibreWolf pretty much is Firefox without the problematic bits. > It’s been my default browser for several years, and I’m very satisfied > with it. Perfect, then. >> As the person who made the changes, it would be great if you could >> pinpoint things that had to be changed compared to ‘icecat’. What >> phases or flags differ? What phases can be factorized? >> > This work isn’t based on the icecat package, but on the firefox-esr > package from nonguix. The duplication I refer to is two small helper > functions, `runpath-of' and `runpaths-of-input', totaling nine lines > of code; they’re flagged with a comment in the patch. As mentioned in > the cover letter, I’m happy to extract these, I just don’t know where > they ought to be placed. They’re defined inside a lambda in a gexp, > which sounds like it may be challenging to put somewhere accessible to > both packages. > > Skimming the icecat package, not many of the build steps are shared > with librewolf, and factoring the commonalities out would IMO result > in overly complex, brittle, hard to maintain code that’s worse than > the slight duplication between the two packages. If there’s a strong > feeling that they must be accounted for, I’ll give it a try, but I > don’t believe that it’s the best option. Yeah, you’re right that factorizing can be a bad idea when misplaced, so let’s keep it that way. I’ll take a closer look at the patches if nobody beats me at it! Thanks, Ludo’.
Hi Ian,
You can enable --with-system-png flag since libpng-apng >= 1.6.35. These
two icecat flags may be required for addons from gnuzilla.gnu.org:
;; Do not require addons in the global app or system directories to
;; be signed by Mozilla.
"--with-unsigned-addon-scopes=app,system"
"--allow-addon-sideload"
This icecat-minimal flag disables DRM:
;; The --disable-eme option is not available on aarch64.
#$(if (target-aarch64?) "" "--disable-eme")
Librewolf should not link to addons.mozilla.org, using this build phase
from torbrowser:
(add-before 'build 'fix-addons-placeholder
(lambda _
(substitute*
"toolkit/locales/en-US/toolkit/about/aboutAddons.ftl"
(("addons.mozilla.org") "gnuzilla.gnu.org"))))
Cheers,
Herman
Hi Ian and Pierre, Thank you for this! I hope to do a review soon. Meanwhile I have one question for Pierre: is there any reason why your Wasm work was contributed to Nonguix instead of Guix? It looks like it could be used by Icecat. Would you say it is ready to be added to the Guix repo? Thank you, Clément On Tue, Nov 28 2023, Ian Eure wrote: > I mentioned in #guix that I was working on a package for LibreWolf, and it was requested that I send in patches, so I am. These changes are based on the firefox-esr package in nonguix; I've retained the copyright / authorship notices from there. > > LibreWolf (https://librewolf.net/) is a fork of Firefox which removes the telemetry and advertising, and bundles uBlock Origin. It doesn't have the redistribution issues that Firefox does, its name/logo are under MPL 2.0 and aren't trademarked. > > I'm new to Guix, and not remotely a browser development expert, so I don't expect these are ready to be accepted yet, but I believe they're in good enough shape to have a discussion about. They're working acceptably well for me, though I'm not currently daily driving Guix, so there may be issues I haven't encountered yet. > > Guide to changes in this patchset > ================================= > > icu4c has been updated to 73.1, and the previous version kept as icu4c-71. I encountered consistent failures of the node@10.24.1 test suite with icu4c 73.1, so I kept that on 71.1. icu4c is needed by many packages, so this change is the highest-impact in the patchset. > > The (gnu packages wasm) module is unchanged from nonguix, except for the file header and module declaration. > > The (gnu packages librewolf) module is a simplified/adapted version of (nongnu packages firefox). The Firefox Nightly packages have been removed, as there's no LibreWolf equivalent. I also didn't bring over the wayland variant, but I could, if that's desired. I'm not sure why there are specific x11/wayland variants, as the packages for other distros don't seem to need this split. > > The librewolf package has some functions duplicated from (gnu packages gnuzilla), which probably ought to get factored out and put somewhere, but I'm not sure if they should be in (gnu packages mozilla) or a different module. Guidance would be appreciated here. > > Ian Eure (5): > gnu: icu4c: Update to 73.1. > gnu: Add icu4c-71. > gnu: node: Switch to icu4c-71. > gnu: Add wasm packages. > gnu: Add librewolf. > > gnu/packages/icu4c.scm | 21 +- > gnu/packages/librewolf.scm | 560 +++++++++++++++++++++++++++++++++++++ > gnu/packages/node.scm | 4 +- > gnu/packages/wasm.scm | 273 ++++++++++++++++++ > 4 files changed, 854 insertions(+), 4 deletions(-) > create mode 100644 gnu/packages/librewolf.scm > create mode 100644 gnu/packages/wasm.scm > > > base-commit: 2410a30f6c06d56b5589e0ad685bcdf09bb144bf
Herman Rimm <herman@rimm.ee> writes: > Hi Ian, > > You can enable --with-system-png flag since libpng-apng >= > 1.6.35. These > two icecat flags may be required for addons from > gnuzilla.gnu.org: > Thanks, I’ve made this change, along with a few other fixes I found over the last couple weeks. I’ll send an updated patch series, but would like to resolve the issues you raise first, to avoid repeatedly sending the patch series. > This icecat-minimal flag disables DRM: > > ;; The --disable-eme option is not available on aarch64. > #$(if (target-aarch64?) "" "--disable-eme") > LibreWolf disables DRM by default[1], so I don’t believe this flag is necessary. I can confirm that it’s disabled in the browser built from the package definition without this flag. > Librewolf should not link to addons.mozilla.org, using this > build phase > from torbrowser: > What’s the rationale for not using addons.mozilla.org? gnuzilla.gnu.org appears to be broken, it’s serving an Apache default page, as if the vhost isn’t configured. Does the browser request some path within that domain, which does work? I’m not familiar with the mechanism used for this. — Ian [1]: https://librewolf.net/docs/faq/#how-do-i-enable-drm
Ian Eure <ian@retrospec.tv> writes: >> This icecat-minimal flag disables DRM: >> >> ;; The --disable-eme option is not available on aarch64. >> #$(if (target-aarch64?) "" "--disable-eme") >> > > LibreWolf disables DRM by default[1], so I don’t believe this > flag is > necessary. I can confirm that it’s disabled in the browser > built from > the package definition without this flag. > I looked a bit deeper into this. There are actually no EME-related configuration options in Librewolf at all, either to enable or disable it. It’s always disabled. — Ian
On Sun, Jan 28, 2024 at 01:23:40PM -0800, Ian Eure wrote: > > Herman Rimm <herman@rimm.ee> writes: > > > Librewolf should not link to addons.mozilla.org, using this build phase > > from torbrowser: > > > > What’s the rationale for not using addons.mozilla.org? > > gnuzilla.gnu.org appears to be broken, it’s serving an Apache default page, > as if the vhost isn’t configured. Does the browser request some path within > that domain, which does work? I’m not familiar with the mechanism used for > this. Apologies, the URL is: https://gnuzilla.gnu.org/mozzarella/. It is used because addons.mozilla.org contains nonfree extensions, from [1]: A free system distribution must not steer users towards obtaining any nonfree information for practical use, or encourage them to do so. The system should have no repositories for nonfree software and no specific recipes for installation of particular nonfree programs. Nor should the distribution refer to third-party repositories that are not committed to only including free software; even if they only have free software today, that may not be true tomorrow. Programs in the system should not suggest installing nonfree plugins, documentation, and so on. For instance, a free system distribution must not contain browsers that implement EME, the browser functionality designed to load DRM modules. >> LibreWolf disables DRM by default[1], so I don’t believe this flag is >> necessary. I can confirm that it’s disabled in the browser built from >> the package definition without this flag. >> > >I looked a bit deeper into this. There are actually no EME-related >configuration options in Librewolf at all, either to enable or disable it. >It’s always disabled. Interesting, I applied the patch series onto 551d013, built librewolf, removed ~/.librewolf and ~/.mozilla, started librewolf and went to about:config, where 'browser.eme.ui.enabled' has the default value 'true', so I can see and toggle the checkbox for 'play DRM-controlled content' in about:preferences. I don't know why 'browser.eme.ui.enabled' is 'true' by default for me, but I think adding --disable-eme will set the default to 'false', like it is in the icecat-minimal about:config. Looking at the firefox source [2], 'browser.eme.ui.enabled' is set to true if MOZ_WIDEVINE_EME is defined, false otherwise. MOZ_WIDEVINE_EME gets defined by being in MOZ_EME_MODULES, which is set to eme_modules in toolkit/moz.configure where a comment reads: # Widevine is enabled by default in desktop browser builds. When running grep in a Librewolf repo [3] for the aformentioned terms, only the --disable-jxl configure flag is modified in toolkit/ moz.configure, so I don't think the Librewolf developers disable EME. I am not sure though, I don't want to rebuild librewolf with the --disable-eme flag to look for the difference. Cheers, Herman [1]: https://www.gnu.org/distros/free-system-distribution-guidelines.en.html [2]: https://archive.mozilla.org/pub/firefox/releases/123.0b5/source/firefox-123.0b5.source.tar.xz [3]: https://codeberg.org/librewolf/source.git
Herman Rimm <herman@rimm.ee> writes: > On Sun, Jan 28, 2024 at 01:23:40PM -0800, Ian Eure wrote: >> >> Herman Rimm <herman@rimm.ee> writes: >> >> > Librewolf should not link to addons.mozilla.org, using this >> > build phase >> > from torbrowser: >> > >> >> What’s the rationale for not using addons.mozilla.org? >> >> gnuzilla.gnu.org appears to be broken, it’s serving an Apache >> default page, >> as if the vhost isn’t configured. Does the browser request >> some path within >> that domain, which does work? I’m not familiar with the >> mechanism used for >> this. > > Apologies, the URL is: https://gnuzilla.gnu.org/mozzarella/. It > is used > because addons.mozilla.org contains nonfree extensions, from > [1]: > I’ll look into this and see what it takes to adjust. >>> LibreWolf disables DRM by default[1], so I don’t believe this >>> flag is >>> necessary. I can confirm that it’s disabled in the browser >>> built from >>> the package definition without this flag. >>> >> >>I looked a bit deeper into this. There are actually no >>EME-related >>configuration options in Librewolf at all, either to enable or >>disable it. >>It’s always disabled. > > Interesting, I applied the patch series onto 551d013, built > librewolf, > removed ~/.librewolf and ~/.mozilla, started librewolf and went > to > about:config, where 'browser.eme.ui.enabled' has the default > value > 'true', so I can see and toggle the checkbox for 'play > DRM-controlled > content' in about:preferences. I don't know why > 'browser.eme.ui.enabled' > is 'true' by default for me, but I think adding --disable-eme > will set > the default to 'false', like it is in the icecat-minimal > about:config. > I completely misunderstood the various settings and systems at play here, which I believe led us to talk past each other. The summary of the situation, best as I can tell, is this: - EME support: a build setting controlling whether the browser supports *any kind* of encrypted media playback. - Widevine support: one kind of DRM, implemented as an EME plugin. - `browser.eme.ui.enabled' browser preference: controls whether the UI for DRM is visible. Controls visibility *only*. A browser build without EME will still show this if `browser.eme.ui.enabled' is `true' (but the control does nothing). A browser build *with* EME (and one or more DRM plugins) can have this set to `false' and still play DRM’d content. - The checkbox within the EME UI: On browsers built with EME and DRM plugin(s), controls whether that is allowed to be used. On browsers without EME+Widevine, does nothing. The default configuration of a clean install of a stock LibreWolf build is: - The browser is built with EME and Widevine support - The UI to enable DRM is visible. - Within that UI, the checkbox is unchecked (meaning DRM is not enabled). I have rebuilt with --disable-eme and confirmed that even with browser.eme.ui.enabled=true and the "Play DRM-controlled content" box checked, the resulting build cannot play DRM’d streams. This was actually somewhat difficult, since I don’t use or have access to any commercial streaming service, but I found a website which lets you test DRM playback, and used that to compare behavior of a LibreWolf binary obtained from the project with my build. Should anyone else want to verify, or need to do this kind of testing, the site is: https://www.nuevodevel.com/nuevo/showcase/drm > When running grep in a Librewolf repo [3] for the aformentioned > terms, > only the --disable-jxl configure flag is modified in toolkit/ > moz.configure, so I don't think the Librewolf developers disable > EME.I > am not sure though, I don't want to rebuild librewolf with the > --disable-eme flag to look for the difference. > The "source" repo contains patches and orchestration to produce the LibreWolf source tarball. The setting which disables DRM by default is in their settings repo[1], which is a submodule. The likely scenario is that you cloned the repo with the eminently reasonable assumption that this would produce a full copy of its contents, and grepped them. Unfortunately, Git submodules are deeply unreasonable, and do not work this way -- you must perform manual actions to populate or update them, which is very easy to forget, especially if one doesn’t work with them regularly. LibreWolf’s specific wording is "We disable DRM by default," which I believe is accurate, but fails to capture the fullness of the situation, i.e. that DRM support is included, but dormant. So you’re also correct that they don’t disable EME -- the disabling happens above that layer. This was not clear to me in the earlier discussions. I’ve removed EME from the build, and will work on replacing Mozilla’s addons with Mozarella, then send an updated patch series. Separately, I’ve also managed to unbundle libpng, libwebp, and nss; fixed the glxinfo utility program; and eliminated a redundant copy of the main binary. Thanks, — Ian [1]: https://gitlab.com/librewolf-community/settings/-/blob/ba238a9ca6bfd509f31e6eb4a45c14c11b7ef7fe/librewolf.cfg#L258-263
On Tue, Feb 06 2024, Ian Eure wrote: > I’ve removed EME from the build, and will work on replacing Mozilla’s addons > with Mozarella, then send an updated patch series. For this you can just copy what's done in the Tor Browser package, which is a copy of what's done in upstream Icecat. Cheers
Hi Pierre, Pinging on this to see if you saw it / have an answer. Thanks, — Ian Clément Lassieur <clement@lassieur.org> writes: > Hi Ian and Pierre, > > Thank you for this! I hope to do a review soon. Meanwhile I > have one > question for Pierre: is there any reason why your Wasm work was > contributed to Nonguix instead of Guix? It looks like it could > be used > by Icecat. Would you say it is ready to be added to the Guix > repo? > > Thank you, > Clément > > On Tue, Nov 28 2023, Ian Eure wrote: > >> I mentioned in #guix that I was working on a package for >> LibreWolf, and it was requested that I send in patches, so I >> am. These changes are based on the firefox-esr package in >> nonguix; I've retained the copyright / authorship notices from >> there. >> >> LibreWolf (https://librewolf.net/) is a fork of Firefox which >> removes the telemetry and advertising, and bundles uBlock >> Origin. It doesn't have the redistribution issues that Firefox >> does, its name/logo are under MPL 2.0 and aren't trademarked. >> >> I'm new to Guix, and not remotely a browser development expert, >> so I don't expect these are ready to be accepted yet, but I >> believe they're in good enough shape to have a discussion >> about. They're working acceptably well for me, though I'm not >> currently daily driving Guix, so there may be issues I haven't >> encountered yet. >> >> Guide to changes in this patchset >> ================================= >> >> icu4c has been updated to 73.1, and the previous version kept >> as icu4c-71. I encountered consistent failures of the >> node@10.24.1 test suite with icu4c 73.1, so I kept that on >> 71.1. icu4c is needed by many packages, so this change is the >> highest-impact in the patchset. >> >> The (gnu packages wasm) module is unchanged from nonguix, >> except for the file header and module declaration. >> >> The (gnu packages librewolf) module is a simplified/adapted >> version of (nongnu packages firefox). The Firefox Nightly >> packages have been removed, as there's no LibreWolf equivalent. >> I also didn't bring over the wayland variant, but I could, if >> that's desired. I'm not sure why there are specific >> x11/wayland variants, as the packages for other distros don't >> seem to need this split. >> >> The librewolf package has some functions duplicated from (gnu >> packages gnuzilla), which probably ought to get factored out >> and put somewhere, but I'm not sure if they should be in (gnu >> packages mozilla) or a different module. Guidance would be >> appreciated here. >> >> Ian Eure (5): >> gnu: icu4c: Update to 73.1. >> gnu: Add icu4c-71. >> gnu: node: Switch to icu4c-71. >> gnu: Add wasm packages. >> gnu: Add librewolf. >> >> gnu/packages/icu4c.scm | 21 +- >> gnu/packages/librewolf.scm | 560 >> +++++++++++++++++++++++++++++++++++++ >> gnu/packages/node.scm | 4 +- >> gnu/packages/wasm.scm | 273 ++++++++++++++++++ >> 4 files changed, 854 insertions(+), 4 deletions(-) >> create mode 100644 gnu/packages/librewolf.scm >> create mode 100644 gnu/packages/wasm.scm >> >> >> base-commit: 2410a30f6c06d56b5589e0ad685bcdf09bb144bf >
Hello,
I tested the v5 of the patch series, applied on guix master 0547fe862c.
Both patches apply and compile cleanly.
I then launched Librewolf through `./pre-inst-env guix shell librewolf -- librewolf`.
I got an error window with the following error message: "Configuration Error: Failed to read the configuration file. Please contact your system administrator."
and the following error messages in console:
```
JavaScript error: librewolf.cfg, line 545: SyntaxError: missing ) in parenthetical
JavaScript warning: resource://services-settings/Utils.sys.mjs, line 57: unreachable code after return statement
console.error: "formatURLPref: Couldn't get pref: " "startup.homepage_welcome_url.additional"
console.error: "Ignoring protocol handler for mailto without a uriTemplate!"
console.error: ({})
JavaScript error: resource://activity-stream/lib/TelemetryFeed.jsm, line 1066: Error: Failed to load chrome://pocket/content/pktApi.sys.mjs
JavaScript error: resource://gre/modules/PromiseWorker.sys.mjs, line 96: Error: Could not get children of file(/home/romain/.librewolf/rhx67hr4.default/thumbnails) because it does not exist
console.error: "about:home startup cache construction failed:" (new TypeError("sectionOrder is undefined", "resource://activity-stream/data/content/activity-stream.bundle.js", 7802))
console.error: "update.locale" " file doesn't exist in either the application or GRE directories"
console.error: services.settings:
main/search-config Signature failed InvalidSignatureError: Invalid content signature (main/search-config) using 'remote-settings.content-signature.mozilla.org-2024-04-09-14-36-39.chain'
console.error: services.settings:
main/search-config local data was corrupted
console.warn: services.settings: main/search-config Signature verified failed. Retry from scratch
```
After closing the error window, the browser launched properly and could be used to browse the web.
I closed it and launched it again and got the same error window, then the browser started again (same behaviour).
I tried to install an add-on from `about:addons`, I got redirected to https://addons.mozilla.org eventhough gnuzilla.gnu.org is mentioned in the search bar.
The Firefox addons website doesn't recognise Librewolf as a Firefox compatible browser and suggests to install Firefox instead of the addon installation.
I don't know if these issues are related to the guix package, although I have been using Librewolf in NixOS during one year as a daily driver and never ran into these issues.
If you need more testing or details, feel free to ask :)
Have a nice day,
Romain
Hi Romain, This is indeed a bug, I was missing parens around a string-append call, which broke the preferences file. I saw the error you mention, but thought my user preferences were broken in some way by the many short-lived local builds I’ve run. I’ll have a fixed patch soon. Thank you very much for taking the time to try things out and letting me know about this problem. — Ian Romain Garbage <romain.garbage@inria.fr> writes: > Hello, > > I tested the v5 of the patch series, applied on guix master > 0547fe862c. > > Both patches apply and compile cleanly. > > I then launched Librewolf through `./pre-inst-env guix shell > librewolf -- librewolf`. > > I got an error window with the following error message: > "Configuration > Error: Failed to read the configuration file. Please contact > your > system administrator." > > and the following error messages in console: > > ``` > JavaScript error: librewolf.cfg, line 545: SyntaxError: missing > ) in parenthetical > JavaScript warning: resource://services-settings/Utils.sys.mjs, > line 57: unreachable code after return statement > console.error: "formatURLPref: Couldn't get pref: " > "startup.homepage_welcome_url.additional" > console.error: "Ignoring protocol handler for mailto without a > uriTemplate!" > console.error: ({}) > JavaScript error: > resource://activity-stream/lib/TelemetryFeed.jsm, line 1066: > Error: Failed to load chrome://pocket/content/pktApi.sys.mjs > JavaScript error: resource://gre/modules/PromiseWorker.sys.mjs, > line > 96: Error: Could not get children of > file(/home/romain/.librewolf/rhx67hr4.default/thumbnails) > because it > does not exist > console.error: "about:home startup cache construction failed:" > (new > TypeError("sectionOrder is undefined", > "resource://activity-stream/data/content/activity-stream.bundle.js", > 7802)) > console.error: "update.locale" " file doesn't exist in either > the application or GRE directories" > console.error: services.settings: > main/search-config Signature failed InvalidSignatureError: > Invalid > content signature (main/search-config) using > 'remote-settings.content-signature.mozilla.org-2024-04-09-14-36-39.chain' > console.error: services.settings: > main/search-config local data was corrupted > console.warn: services.settings: main/search-config Signature > verified failed. Retry from scratch > ``` > > After closing the error window, the browser launched properly > and could be used to browse the web. > > I closed it and launched it again and got the same error window, > then the browser started again (same behaviour). > > I tried to install an add-on from `about:addons`, I got > redirected to > https://addons.mozilla.org eventhough gnuzilla.gnu.org is > mentioned in > the search bar. > The Firefox addons website doesn't recognise Librewolf as a > Firefox > compatible browser and suggests to install Firefox instead of > the > addon installation. > > I don't know if these issues are related to the guix package, > although > I have been using Librewolf in NixOS during one year as a daily > driver > and never ran into these issues. > > If you need more testing or details, feel free to ask :) > > Have a nice day, > Romain >
Hi Guix team!
It would be great to have one more modern and libre web browser in the
Guix's belt!
I've managed to build and run it successfully by applying patch directly
from QA, thanks Andrew Tropin <andrew@trop.in> for the snippet.
--8<---------------cut here---------------start------------->8---
guix time-machine \
--url='https://git.guix-patches.cbaines.net/git/guix-patches' \
--branch=issue-67512 \
--disable-authentication -- shell librewolf -- librewolf
--8<---------------cut here---------------end--------------->8---
--
Oleg