Gecko-dev Diary
Starting in August 2023 I'll be upgrading the Sailfish OS browser from Gecko version ESR 78 to ESR 91. This page catalogues my progress.
Latest code changes are in the gecko-dev sailfishos-esr91 branch.
There is an index of all posts in case you want to jump to a particular day.
Click the icon for the Gecko-dev Diary RSS feed.
Gecko
17 Aug 2023 : Day 1 #
So this is Day 1 of my Gecko-dev Diary. It's a developer diary about upgrading the Gecko rendering engine in the Sailfish OS browser from ESR 78 to ESR 91. I've posted a Preamble to give some background in case you've not already read it.
The Sailfish Browser is actually split across multiple repositories:
Initially I'll actually be working in my own gecko-dev and gecko-dev-mirror forks. Although I'll be committing to the mirror, eventually these will all get converted to patches in the gecko-dev repo.
For the first steps I just pulled in the latest ESR78.1 changes to my local machine and checked everything builds. This takes some time. I'm never exactly sure how long it takes to build because there are some frustrating synchronisation issues that we never managed to fix, which means that the build can get stuck and hang. You can never be certain whether the build is still running or has just halted indefinitely.
As a result, to get through a full build it generally needs to be cancelled and restarted multiple times. Gecko supports incremental builds, so it's not as painful as it would be otherwise, but it still makes it hard to determine exactly how long a full build takes. In my estimation it's between five and eight hours on my development machine (14 cores, 16 threads, 32 GiB RAM).
The build works, so my development environment is set up correctly.
Next up I have to find the correct version of the next Extended Support Release from the upstream mirror. ESR91.9 has been neatly tagged; it looks like the latest ESR91 tag, so I'll start with that.
All I have to do initially is update the submodule to point to this tag. But since I don't want to be working with patches just yet, instead I'm going to add commits to the mirror and update the submodule commit to pull them in.
Committing changes to the mirror might sound like a terrible idea, but it will make things a lot easier during development. Instead of creating patches, which are horrible to work with, I'll instead commit my changes and update the submodule. Once things have settled I can turn all the commits into patches using git format-patch.
I created a new branch called FIREFOX_ESR_91_9_X_RELBRANCH_patches where all of my changes can live, and have created a sailfishos-esr91 gecko-dev branch with the submodule pointing to it.
The existing patches won't apply to this new codebase, so the first thing to do is disable them all in the spec file.
And now I just check that the build... well, check that it starts. Without any of the patches it's not going to get very far before it crashes out, but it needs to get some way so I can check the errors and apply any patches that are needed. I'll potentially have to apply them manually.
An important thing to note at this point is that, when building locally, and in order to avoid some confusion caused to the rust toolchain, we're building using the --with git_workaround flag.
However, if the build fails it will leave our local repository in an inconsistent state: the git status of the submodule will be missing. We have to therefore remember to name the .git-disabled folder back to .git if we ever want to do any git operations on the submodule — which we will because we're committing our changes — it's just another thing to bear in mind.
Well, the build starts. It doesn't get very far, but it does start. That's enough for today; tomorrow I'll try to tackle this first build error I'm hitting.
You can read all the other developer diary entries on my Gecko-dev Diary page.
The Sailfish Browser is actually split across multiple repositories:
- gecko-dev: this is the one I'll initially be mostly interested in. It's the wrapper around the upstream gecko code
- gecko-dev mirror: this is just the sailfish mirror that's submoduled into gecko-dev. It's identical to the upstream mozilla repository of the same name.
- sailfish-browser: the main application wrapper for the Sailfish Browser
- qtmozembed: the EmbedLite wrapper for using gecko-dev with Qt
- embedlite-components: integration code (mostly JavaScript) that runs in gecko to support the browser
- sailfish-components-webview: A Silica component for using the engine in other apps
Initially I'll actually be working in my own gecko-dev and gecko-dev-mirror forks. Although I'll be committing to the mirror, eventually these will all get converted to patches in the gecko-dev repo.
For the first steps I just pulled in the latest ESR78.1 changes to my local machine and checked everything builds. This takes some time. I'm never exactly sure how long it takes to build because there are some frustrating synchronisation issues that we never managed to fix, which means that the build can get stuck and hang. You can never be certain whether the build is still running or has just halted indefinitely.
As a result, to get through a full build it generally needs to be cancelled and restarted multiple times. Gecko supports incremental builds, so it's not as painful as it would be otherwise, but it still makes it hard to determine exactly how long a full build takes. In my estimation it's between five and eight hours on my development machine (14 cores, 16 threads, 32 GiB RAM).
The build works, so my development environment is set up correctly.
Next up I have to find the correct version of the next Extended Support Release from the upstream mirror. ESR91.9 has been neatly tagged; it looks like the latest ESR91 tag, so I'll start with that.
All I have to do initially is update the submodule to point to this tag. But since I don't want to be working with patches just yet, instead I'm going to add commits to the mirror and update the submodule commit to pull them in.
Committing changes to the mirror might sound like a terrible idea, but it will make things a lot easier during development. Instead of creating patches, which are horrible to work with, I'll instead commit my changes and update the submodule. Once things have settled I can turn all the commits into patches using git format-patch.
I created a new branch called FIREFOX_ESR_91_9_X_RELBRANCH_patches where all of my changes can live, and have created a sailfishos-esr91 gecko-dev branch with the submodule pointing to it.
The existing patches won't apply to this new codebase, so the first thing to do is disable them all in the spec file.
And now I just check that the build... well, check that it starts. Without any of the patches it's not going to get very far before it crashes out, but it needs to get some way so I can check the errors and apply any patches that are needed. I'll potentially have to apply them manually.
An important thing to note at this point is that, when building locally, and in order to avoid some confusion caused to the rust toolchain, we're building using the --with git_workaround flag.
sfdk build -d -p --with git_workaroundWhat this flag does is rename the .git folder inside the gecko-dev submodule to .git-disabled. When the build is successful we can ignore the consequences of this since it's renamed back again at the end.
However, if the build fails it will leave our local repository in an inconsistent state: the git status of the submodule will be missing. We have to therefore remember to name the .git-disabled folder back to .git if we ever want to do any git operations on the submodule — which we will because we're committing our changes — it's just another thing to bear in mind.
Well, the build starts. It doesn't get very far, but it does start. That's enough for today; tomorrow I'll try to tackle this first build error I'm hitting.
You can read all the other developer diary entries on my Gecko-dev Diary page.
Comments
Uncover Disqus comments