Hi Mark, Mark H Weaver <[email protected]> writes:
> Hi Maxim, > > Maxim Cournoyer <[email protected]> writes: > >> * gnu/packages/gnuzilla.scm (update-mozilla-locales): New procedure. >> (all-mozilla-locales): Comment how to proceed to update it. > > [...] > >> +(define (update-mozilla-locales changesets.json) >> + "Output a new list of Mozilla locales, to update the ALL-MOZILLA-LOCALES >> +variable defined bellow. It requires guile-json to be installed." >> + ;; To extract the file used as argument, do: >> + ;; tar -xf $(./pre-inst-env guix build \ >> + ;; -e '(@@ (gnu packages gnuzilla) upstream-firefox-source)') \ >> + ;; --strip-components=3 \ >> + ;; --wildcards '*/browser/locales/l10n-changesets.json' >> + (match (call-with-input-file changesets.json json->scm) >> + (((lang ("revision" . revision) platforms pin) ...) >> + (let ((data (reverse (map (lambda (rev lang) >> + `(,(list->string (make-list 40 #\0)) >> + ,(string-take rev 12) ,lang)) >> + revision lang)))) >> + (format #t "~{~s~%~}" data) >> + data)))) > > Thanks very much for this! I didn't know about the > browser/locales/l10n-changesets.json file, and neither does the code in > the upstream 'makeicecat' script, which simply uses "hg clone" to fetch > the latest revisions at the time the 'makeicecat' script is run. Now we > can change that code to use the revisions listed in > 'l10n-changesets.json' instead, and thus eliminate a source of > nondeterminism for non-Guix users of IceCat. > > However, I'd like to propose a different way to make use of this code. > > Instead of adding this new toplevel procedure that must be run manually, > which involves steering the user toward the 'upstream-firefox-source' > variable (which therefore must be promoted to a toplevel binding), all > of which makes me extremely uncomfortable, how about the following: > > I propose adding a check to the code that populates the l10n directory > in 'icecat-source'. That code has access to the unpacked firefox source > directory, and already makes use of '#+all-mozilla-locales'. It's in a > perfect position to check whether '#+all-mozilla-locales' is up-to-date > w.r.t. browser/locales/l10n-changesets.json. > > My suggestion would be this: if '#+all-mozilla-locales' is not > up-to-date, print an error report with the relevant information and > force the derivation to *fail*. > > What do you think? If the idea sounds good to you, would you like to > work on it, or should I? It's a good idea, but I don't think it's worth implementing at this point, given that Mozilla will soon provide us with a strings_all.tar.zst tarball per release, which will include both Firefox and Thunderbird l10n data (it'll be available along the releases tarball) [0]. This will obsolete all this tedious work of keeping hashes up to date. [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1817086 -- Thanks, Maxim
