Page MenuHomePhabricator

Bug 1950511 - part 3: add the rpm choice for the mach repackage action r=gabriel
ClosedPublic

Authored by alubert on Jan 29 2025, 2:03 PM.
Referenced Files
Unknown Object (File)
Dec 13 2025, 6:23 PM
Unknown Object (File)
Dec 6 2025, 1:48 AM
Unknown Object (File)
Dec 6 2025, 1:15 AM
Unknown Object (File)
Dec 6 2025, 1:15 AM
Unknown Object (File)
Dec 6 2025, 1:10 AM
Unknown Object (File)
Dec 6 2025, 1:09 AM
Unknown Object (File)
Dec 6 2025, 1:08 AM
Unknown Object (File)
Dec 6 2025, 1:07 AM
Subscribers

Details

Summary

The test_rpm is mostly based on the test_deb file.

Diff Detail

Event Timeline

phab-bot changed the visibility from "Custom Policy" to "Public (No Login Required)".
phab-bot changed the edit policy from "Custom Policy" to "Restricted Project (Project)".
phab-bot removed a project: secure-revision.

I was able to build the package locally. LGTM

This revision is now accepted and ready to land.Feb 5 2025, 10:32 PM

This revision requires a Testing Policy Project Tag to be set before landing. Please apply one of testing-approved, testing-exception-unchanged, testing-exception-ui, testing-exception-elsewhere, testing-exception-other. Tip: this Firefox add-on makes it easy!

python/mozbuild/mozbuild/repackaging/rpm.py
90

Instead of modifying this function, you can just not call it in this repackaging.rpm module. It won't affect repackaging.deb

python/mozbuild/mozbuild/repackaging/rpm.py
90

The mv_manpage_files will move two files and one of them is used by both system (the manpage.1.in). If we removed this call, the rpm package will not have the manual page.

This revision now requires changes to proceed.Feb 26 2025, 12:01 AM
alubert updated this revision to Diff 990864.
alubert retitled this revision from Bug 213920 - part 3: add the rpm choice for the mach repackage action r=gabriel to Bug 1950511 - part 3: add the rpm choice for the mach repackage action r=gabriel.
alubert changed the Bugzilla Bug ID from 213920 to 1950511.
This revision is now accepted and ready to land.Mar 3 2025, 4:32 PM
jcristau added a subscriber: jcristau.
jcristau added inline comments.
python/mozbuild/mozbuild/repackaging/desktop_file.py
213 ↗(On Diff #990864)

This looks off. What's 'PKG_EXEC' 'DEB_PKG_NAME'?

Ah, I see you're changing that back in D238575. Can you fix it up so there's not this broken intermediate state?

python/sites/repackage-rpm.txt
2

AIUI this is the same as the repackage-desktop-file site (and only needed because it's calling into that same code); if so you can set virtualenv_name="repackage-desktop-file" in the rpm repackage subcommand instead of creating an identical copy.

This revision now requires changes to proceed.Mar 18 2025, 10:06 AM
python/mozbuild/mozbuild/mach_commands.py
2574

You probably should use the "repackage-desktop-file" virtualenv

2611

Instead of having a repackage-l10n command, can we make this command take in a directory of xpi langpacks and a locales-file and pass those into repackage_rpm?

python/mozbuild/mozbuild/repackaging/rpm.py
170

Mm if the Firefox spec file is supposed to have the langpacks we should use a templating library. We have Jinja vendored in mach so we could import it here to render the .spec

We could use the .jinja file extension (instead of .in) to select which files to render using jinja.

https://searchfox.org/mozilla-central/source/python/sites/mach.txt#58
https://jinja.palletsprojects.com/en/stable/templates/#template-file-extension

python/sites/repackage-rpm.txt
2

I see there's a "vendor-ed" package here.
If we pull the vendored jinja we can add it to the repackage-desktop-file site.

The langpacks will be in the fetches directory (the CI can pass in the directory)

/builds/worker/fetches/ach.langpack.xpi
/builds/worker/fetches/af.langpack.xpi
/builds/worker/fetches/ckb.langpack.xpi
/builds/worker/fetches/zh-TW.langpack.xpi

The locales are the keys in the "locales-file" (browser/locales/l10n-changesets.json)

So if we pass a --input-xpi-dir and a --locales-file we can use the .xpis to create the RPM langpacks

I wonder if there's a better place to get the list of locales needed. Now that I think about it the staging releases only run a small subset of the locales...

The langpacks will be in the fetches directory (the CI can pass in the directory)

/builds/worker/fetches/ach.langpack.xpi
/builds/worker/fetches/af.langpack.xpi
/builds/worker/fetches/ckb.langpack.xpi
/builds/worker/fetches/zh-TW.langpack.xpi

The locales are the keys in the "locales-file" (browser/locales/l10n-changesets.json)

So if we pass a --input-xpi-dir and a --locales-file we can use the .xpis to create the RPM langpacks

I currently working to implement this behavior and in fact, the --locales-file seems useless, since the locale information are available in the manifest.json file in each langpack xpi file (with the langpack_id and the description). Maybe we only need the --input-xpi-dir argument and read each zipfile in this directory to retrieve information (its already done to retrieve the description).

The only behavior I can see with this JSON file, is to check if the platform can be used with the specified architecture.

Also, using the files in the --input-xpi-dir without the JSON file allow to only built the langpack files available in this directory.

I’ve seen also, that the browser/locales/l10n-changesets.json do not contains the en-US codename. I don’t know if its because this langpack is the default one, but if this langpack is available under the /builds/worker/fetches directory, using the --locales-file will not add this package in the spec file automatically.

alubert updated this revision to Diff 1011308.
This revision is now accepted and ready to land.Apr 24 2025, 3:04 PM
gabriel edited the summary of this revision. (Show Details)