The test_rpm is mostly based on the test_deb file.
Details
- Reviewers
• gabriel - Commits
- rMOZILLACENTRALa5ca243d45aa: Bug 1950511 - part 3: add the rpm choice for the mach repackage action r=gabriel
- Bugzilla Bug ID
- 1950511
Diff Detail
- Repository
- rMOZILLACENTRAL mozilla-central
Event Timeline
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. | |
Please update the commit message to use this bug #: https://bugzilla.mozilla.org/show_bug.cgi?id=1950505
| 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. | |
| 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 | |
| python/sites/repackage-rpm.txt | ||
| 2 | I see there's a "vendor-ed" package here. | |
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...
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.