The .xpi format is no longer supported.
PR for librewolf/issues#2961
(削除) Fixes: librewolf/issues#2961 (削除ここまで) (not yet)
39033f9344
to 247cf2098e
Note
I likely won't have much time to test this this week, so I would appreciate any help!
@any1here wrote in #73 (comment):
ac_add_options --with-l10n-base=$PWD/lw/l10nand that should be pretty much it.
As I mentioned in #73 (comment), adding this option does not fix the issue...
@doasu wrote in #74 (comment):
@any1here wrote in #73 (comment):
ac_add_options --with-l10n-base=$PWD/lw/l10nand that should be pretty much it.As I mentioned in #73 (comment), adding this option does not fix the issue...
Could you press Ctrl + Shift + J and see if anything gets logged maybe?
247cf2098e
to 75c95a2e96
5c1b2021bb
to 7f473ae416
7f473ae416
to 3a1bc63980
@ -636,4 +615,0 @@
fi
done
}
The override for src_unpack is no longer needed since the xpis have been removed.
The default implementation is to unpack all source files (literally, unpack ${A}), which works for us.
@ -57,4 +56,0 @@
if [[ ${PV} == *_rc* ]] ; then
MOZ_SRC_BASE_URI="https://archive.mozilla.org/pub/${MOZ_PN}/candidates/${MOZ_PV}-candidates/build${PV##*_rc}"
fi
These were only used for fetching xpis for language packs. Dead code should be removed.
@ -648,0 +628,4 @@
for languagepack in *; do
[[ -d "${languagepack}" ]] || continue # not a directory; skip
rm -rf "${languagepack}"
done
I opted to remove all language packs which are not specified by the user's ${L10N} setting.
@TheGreatMcPain do I understand correctly that L10N can map directly to LibreWolf's language codes?
They both seem to use IETF language tags1 2 .
@any1here wrote in #74 (comment):
Could you press Ctrl + Shift + J and see if anything gets logged maybe?
I don't see anything that would suggest missing language packs:
(The multi-process logger doesn't show any more info.)
@doasu wrote in #74 (comment):
@any1here wrote in #74 (comment):
Could you press Ctrl + Shift + J and see if anything gets logged maybe?
I don't see anything that would suggest missing language packs:
(The multi-process logger doesn't show any more info.)
So you currently only have the English locale available?
@any1here wrote in #74 (comment):
So you currently only have the English locale available?
Precisely! It's "English (US)."
@doasu wrote in #74 (comment):
@any1here wrote in #74 (comment):
So you currently only have the English locale available?
Precisely! It's "English (US)."
But the english locale has the correct strings?
@any1here wrote in #74 (comment):
But the english locale has the correct strings?
If you mean LibreWolf strings showing correctly (branding, etc.), then aye, it does.
I was expecting the language packs from /lw/l10n to show up in the LibreWolf Language settings drop-down list, but they don't. 😕
@doasu wrote in #74 (comment):
@any1here wrote in #74 (comment):
But the english locale has the correct strings?
If you mean LibreWolf strings showing correctly (branding, etc.), then aye, it does.
Did you add additional languages to use to L10N?
@any1here wrote in #74 (comment):
Did you add additional languages to use to L10N?
Yes. Here's my L10N USE:
% rg 'l10n' <(tr ' ' '\n' </var/db/pkg/www-client/librewolf-149.0.2_p1/USE)
12:l10n_en-GB
13:l10n_pl
For context, my lw/l10n directory had the following files at the time of building:
% ls -F /var/tmp/portage/www-client/librewolf-149.0.2_p1/work/librewolf-149.0.2-1/lw/l10n
en-GB/ LICENSE pl/ README.md
List of files merged/provided with package: /var/db/pkg/www-client/librewolf-149.0.2_p1/CONTENTS
I'm a little over my head on this issue. I usually just copy what Gentoo's www-client/firefox is doing.
I have only just looked into this, but it looks like the langpacks for www-client/firefox got put into it's own ebuild as www-client/firefox-l10n. I figured we should just copy www-client/firefox-l10n and adapt it to use librewolf's sources.
Sorry I've been neglecting this overlay. Some life stuff was going on.
Looks like www-client/firefox-l10n still just downloads xpi files.
I am gonna try providing the language packs somewhere.
I managed to setup a Gitlab CI in this repository that provides the language pack .xpi files in its package registry.
From here it shouldn't be too hard to modify www-client/firefox-l10n for librewolf.
I can manually install the language packs if I revert this commit and change extensions.langpacks.signatures.required to false.
Haven't been able to get them working via www-client/librewolf-l10n, which I've recently added, even with the changes mentioned above. Maybe I also need to revert this one too?
@TheGreatMcPain wrote in #74 (comment):
I can manually install the language packs if I revert this commit and change
extensions.langpacks.signatures.requiredtofalse.Haven't been able to get them working via
www-client/librewolf-l10n, which I've recently added, even with the changes mentioned above. Maybe I also need to revert this one too?
I wouldn't recommend adding back the ability to install external language packs, since this would allow users to break their installation again.
What prevents using the already patched language packs the source tarball has? Is it because you want to not ship all the language packs?
My original idea was to get as close to what Gentoo's Firefox ebuild is doing, so that maintaining the LibreWolf ebuild was as easy as changing a few lines from the Firefox ebuild, but I see I went a little overboard.
I think I can get it working via ./mach package-multi-locale.
What prevents using the already patched language packs the source tarball has? Is it because you want to not ship all the language packs?
Gentoo's Firefox ebuild allows the user to select what languages they want via Gentoo's L10N useflag. The way the Firefox ebuild does it is through Firefox's language packs.
This is what I've come up with.
--- librewolf-149.0.2_p2-r1.ebuild 2026年04月20日 02:58:30.610680154 -0500
+++ librewolf-149.0.2_p2-r2.ebuild 2026年04月20日 03:01:14.024852970 -0500
@@ -219,6 +219,44 @@
einfo "Using LLVM slot ${LLVM_SLOT} to build" >&2
}
+MOZ_LANGS=(
+ ace ach af ak an ar as ast az be bg bn bn-BD bn-IN bo bqi br brx bs ca cak ca-valencia
+ ckb crh cs csb cy da de dsb el en-CA en-GB en-ZA eo es es-AR es-CL es-ES es-MX et eu fa
+ ff fi fr frp fur fy-NL ga ga-IE gd gl gn gu-IN gv he hi-IN hr hsb hto hu hy-AM hye ia id
+ ilo is it ixl ja ja-JP-mac ka kab kk km kmr kn ko kok ks ku kw lb lg lij lo lt ltg lv mai
+ meh mix mk ml mn mr ms my nb-NO ne-NP nl nn-NO nr nso ny oc or pai pa-IN pbb pl ppl pt-BR
+ pt-PT quy qvi rm ro ru rw sah sat sc scn sco si sk skr sl son sq sr ss st sv-SE sw szl ta
+ ta-LK te tg th tl tn tr trs ts tsz uk ur uz ve vi wo xcl xh zam zh-CN zh-TW zu
+)
+MOZ_LANG_MAP=()
+
+mozilla_set_globals() {
+ # https://bugs.gentoo.org/587334
+ local MOZ_TOO_REGIONALIZED_FOR_L10N=(
+ fy-NL ga-IE gu-IN hi-IN hy-AM nb-NO ne-NP nn-NO pa-IN sv-SE
+ )
+
+ local lang xflag
+ for lang in "${MOZ_LANGS[@]}" ; do
+ # en and en_US are handled internally
+ if [[ ${lang} == en ]] || [[ ${lang} == en-US ]] ; then
+ continue
+ fi
+
+ # strip region subtag if $lang is in the list
+ if has ${lang} "${MOZ_TOO_REGIONALIZED_FOR_L10N[@]}" ; then
+ xflag=${lang%%-*}
+ else
+ xflag=${lang}
+ fi
+
+ MOZ_LANG_MAP+=("l10n_${xflag/[_@]/-} ${lang}")
+
+ IUSE+=" l10n_${xflag/[_@]/-}"
+ done
+}
+mozilla_set_globals
+
moz_clear_vendor_checksums() {
debug-print-function ${FUNCNAME} "$@"
@@ -1168,7 +1206,21 @@
"${BUILD_DIR}"/dist/bin/${PN} \
"${BUILD_DIR}"/dist/bin/plugin-container
- DESTDIR="${D}" ./mach install || die
+ #DESTDIR="${D}" ./mach install || die
+ # ./mach install doesn't install the locale information for some reason.
+ # Use packge-multi-locale instead
+ local mymozlangs=()
+ for lang_tuple in "${MOZ_LANG_MAP[@]}"; do
+ IFS=' ' read -r l10n lang <<< "${lang_tuple}"
+
+ if use "${l10n}"; then
+ mymozlangs+=("${lang}")
+ fi
+ done
+ ./mach package-multi-locale --locale "${mymozlangs[@]}" || die
+
+ dodir "${MOZILLA_FIVE_HOME}" || die
+ cp -r "${BUILD_DIR}"/dist/librewolf/* "${ED}"/"${MOZILLA_FIVE_HOME}" || die
## LibreWolf
# For some reason 'local-settings.js' doesn't get properly packaged.
It seems to be working on my end, but I've attached the new ebuild so that you can test it yourself before I go ahead and commit it.
I'll try it out and let you know if it works on my machine :>
@TheGreatMcPain: It works!
image
Superseded-by: e0706977f4
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?