flypig.co.uk

When I wrote my diary entry yesterday I spent the first couple of paragraphs talking about Autumn. I've previously mentioned how the transition between seasons is the most exciting time of year for me. It occured to me this morning that this project is moving through its own transition right now: from Stage 1 to Stage 2.

This was always planned as being a three-stage project. As I wrote way back in the preamble to these diaries, the three stages were intended to look like this:

1. Apply a minimal set of changes and patches to get ESR 91 to build.
2. Apply any remaining patches where possible and other changes to get it to run and render.
3. Handle the Sailfish OS specific integrations.

It was already about a week ago on Day 45 that I declared Stage 1 to be complete. Yesterday I talked about tackling the render pipeline as being one of the next things I'd planned to work on. But right now we're sort-of sitting in between the transition from Stage 1 to Stage 2.

This has taken the form of me writing out a load of issues to the sailfish-browser bug-tracker as I did yesterday. And it's continuing today with me setting up various projects on OBS. For those that don't know, OBS is the Open Build Service provided by Jolla and used by Sailfish OS, which is essentially the Sailfish OS continuous delivery service. All of the packages that make up Sailfish OS are built on OBS. Jolla make a Community OBS available which members of the community like me can submit their own software to, so that it can be built against the Sailfish OS packages.

That includes building updated versions of the existing packages, which is what I plan to set up today if I can.

There are various glitches that may prevent this from working. For example, I'll need to create packages for everything that I've changed, even changes to the build tooling. I'm not sure whether it's going to be possible to have the build-tooling built on the system then used by the system. Probably not, but maybe I can work around that. The remote OBS isn't configured quite the same way as my local build system, so that may also cause problems. Finally I've only ever built the aarch64 version of Gecko. Building for other targets (arm32 and i486) is also likely to introduce problems that until now I've not had to worry about.

The following are the packages I'll likely need to add to the project:

1. nspr, 4.35.0
2. xulrunner-qt5, 91.9.1
3. qtmozembed-qt5, 1.53.25
4. embedlite-components-qt5, 1.24.34
5. sailfish-components-webview, 1.5.17
6. sailfish-browser, 2.2.61
7. mapplauncherd-booster-browser, 0.2.1

The following have updated versions, but because these have already been merged in I'm hoping I won't need to add these to the OBS project. That should become clearer after OBS has attempted a full build:

1. icu, 0.19.0
2. rust-cbindgen, 0.19.0
3. gcc, 8.3.0-7 (patched)

As things stand I've added these to a gecko-esr91 project I've set up on OBS and things are building away. OBS claims it can't build qtmozembed because xulrunner is the incorrect version, but I'm hoping that will be resolved once xulrunner has been successfully built. As I write this the xulrunner (gecko-dev) package is stil marked as blocked, but hopefully that's just because it's waiting for a runner to become available.

So that's it. I'm up-to-date with my untechnical debt. I can't put it off any longer: I'm going to have to have a go at tackling the rendering pipeline issue.

I've assigned myself the issue. No turning back.

We're now in Stage 2.

If you'd like to read more about all this gecko stuff, do take a look at my full Gecko Dev Diary.