bug#32026: [PATCH 01/10] gnu: Add a 'update-mozilla-locales' helper for maintenance.

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Mark,

Mark H Weaver <mhw@netris.org> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> 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