Skip to content

Instantly share code, notes, and snippets.

@MihaiTabara
Last active May 1, 2019 17:38
Show Gist options
  • Save MihaiTabara/57ad675d19c8418fafde22233af3c1fc to your computer and use it in GitHub Desktop.
Save MihaiTabara/57ad675d19c8418fafde22233af3c1fc to your computer and use it in GitHub Desktop.
Flatpaks leftovers

Leftovers in order to ship Firefox as flatpak for the https://flathub.org/ appstore.

Build fixes in order to get a MVP

  • 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 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
Docker issues
  • the need of --priviledged for the bwrap() 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
Localization issues
  • 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.

Signing

  • likely not needed for now as Flathub will sign this anyway, just as Canonical does for snaps

Publishing

  • 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 be beta?
  • 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 and release, ignore nightly for now

Follow-ups

  • figure out how to automate that from RelEng side to continously publish it to Github.
  • support linux32 as well, along with the linux64
  • update appdata more like Slack does for example - see example here
  • consider localizing in the future the contents of the appdata as well. See example here
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment