Leftovers in order to ship Firefox as flatpak for the https://flathub.org/ appstore.
- to rope in legal + others teams @Mozilla when we generate https://hughsie.github.io/oars/generate.html
- description needs to change - it's terrible ATM - check what we have on Google Play store
- check formatting options for HTML rendering here - https://www.freedesktop.org/software/appstream/docs/
- use https://github.com/flathub/flathub/wiki/AppData-Guidelines
- check license tag (is it MPL-2.0 indeed?) + rope legal into this
- review the fields of the appdata.xml alttogether (summary and such, etc)
- find screenshots with our own Mozilla hosted locations
- Mihai to update appdata.xml with the proper content obtained from legal/Relman/marketing/etc
- trim the $WORKSPACE and simply keep the files where they are. That will make the copy-paste commands of scripts useless, hence cleaner code
- change date to reflect the release date, not the utcnow() that's currently baked in
- check validity and need for default-preferences.js with a Firefox build peer @Mozilla
- switch from json to YAML for the flatpak.json.in
- to reduce the Docker image size if we can (e.g. --no-recommends for ubuntu, multi-stage layers in Docker, etc)
- we need the dbus stuff baked in Dockerfile and sdk there as well for simplicity
- potentially consider mimetypees within the .desktop data
- icon needs to match the app id while the Categories needs to match correctly the Network / WebBrowser
- TIL - the system dialog is turned off (e.g. updates) for Firefox can't write its own files in the container
- s/Firefox/firefox everywhere, including the files naming
- talk to Nick about the final version of the finish-args list
- remove
<strong>
stuff as it's breaking on flatpak
- the need of
--priviledged
for thebwrap()
calls within building the flatpaks - try reproducing work via secomp
- mtabara to talk to wander @ Mozilla to see if we can translate those via Taskcluster
- appdata.xml needs to be localized and baked in the gecko intree
- baking all the locales within the initial tar.gz (with symlinkling the locales to a
before-hyphen
prefix standard done in the flatpak manifest. The flahub client is smart enough to handle the grabbing of a single locale, the default or all of them if needed - more on how libreoffice does it here - make sure the locales are synced with what we ship and ideally come from tree
- langpacks don't work as they should; investigate
- once tarball is done, we need to reenable localization and treat it differently
- once langpacks work, next step is to move them from /extensions to /app/share and let flatpak optimize that (right now we're baking all the langpacks but potentially we could optimize to install for the enduser only the locale that's needed)
- apply Rob's patch + test this: a) inspecting
build()
folder in resulting b) VM to install flatpak and see you actually get a good locale, rather than all of them.
- likely not needed for now as Flathub will sign this anyway, just as Canonical does for snaps
- register Firefox within Flathub via https://github.com/flathub/flathub/wiki/App-Submission
- figure out the best channel to publish to. Should it be
nightly
(if exists?) or should it bebeta
? - publishing means either: a) get the tar.gz, explode it and publish the structure to S3 (rooted entry as opposed to per release so that flathub can talk to it and grab the deltas objects) b) keep the tar.gz and bake the logic within the flahub manager scripts to handle directly the deltas on the fly (as we do for Snap world, we'd publish that in the ~candidates directory)
- don't forget to add those three missing python3 packages for running the publishing bits via flat-manager
- figure out token timestamp and ways to rotate
- setup communication between Flathub and Mozilla for future
- focus on
beta
andrelease
, ignorenightly
for now