flypig.co.uk

Last night I kicked off the build to test the final arrangement of commits and patches that I hoped to convert into a pull request to the gecko-dev repository today. With the patches now stored in the gecko-dev rpm directory it means that the submodule mirror of upstream's gecko-dev source tree can be pulled in entirely unchanged and without any sailfish-specific commits. That's the whole point of the way the repository is structured: we pull in upstream's code without modification, apply our sailfish-specific patches to it and build the result.

This morning the build had finished and finished with a positive result. No glitches in the build process. But that doesn't mean it's built something that works.

But after transferring it over to my phone, installing the packages and running a few tests, I'm convinced that it's just the same as the previous version. So I conclude that I did successfully manage to reorganised the commits without affecting the final result.

At this point I thought I'd be ready to create the final pull request. But as I look through the patches I notice a few things that still need fixing. The first is to do with redundant commits. A couple of patches disable and then re-enable a flag, so they can be removed. There's also a commit that drops build optimisations to O1. I'd like to test it without this change so I've reverted this patch and will drop it entirely if it turns out not to be needed.

I also notice there are a few patches which aren't entirely required to get the browser working, but which do nevertheless provide important background functionality.

In fact, it was the discussion on the forum, particularly between Attah (attah) and Raine (rainemak) that alerted me to the fact that there are patches that haven't been applied but are needed, specifically related to user agent handling:
 

There are six patches like this that spring out as being likely needed, but which as yet aren't included in the build. Five of them apply without incident:

$ git am --3way \
    ../../../gecko-dev-project/gecko-dev/rpm/0059-sailfishos-gecko-Delete-startupCache-if-it-s-stale.patch
$ git am --3way \
    ../../../gecko-dev-project/gecko-dev/rpm/0067-sailfishos-gecko-Hardcode-loopback-address-for-profi.patch
$ git am --3way \
    ../../../gecko-dev-project/gecko-dev/rpm/0068-sailfishos-gecko-Start-using-user-agent-builder.-JB-.patch
$ git am --3way \
    ../../../gecko-dev-project/gecko-dev/rpm/0083-sailfishos-gecko-dev-Disallow-page-zooming-if-the-me.patch
$ git am --3way \
    ../../../gecko-dev-project/gecko-dev/rpm/0086-sailfishos-gecko-Add-preference-to-bypass-CORS-on-ns.patch

The final patch is messy: when I try to apply it, there are conflicts all the way down:

$ git am --3way \
    ../../../gecko-dev-project/gecko-dev/rpm/0061-sailfishos-locale-Get-12-24h-timeformat-setting-from.patch

In spite of this it turns out to be pretty simple to apply the changes manually, which I've now done. Since I did it as part of the git am process the correct description and attribution have already been automatically applied. So finally I can generate new patches from these commits and add them to the build configuration:

$ git format-patch \--start-number 79 -o ../rpm -N --no-signature --zero-commit bd026681f74d

I also received a really helpful message from Matti Viljanen (direc85) giving suggestions for improving the build configuration to force the Rust portions to build with just a single process. The importance of this is that running Rust with multiple processes results in sporadic hangs during the build. That's a real pain because after leaving the build running overnight you don't want to discover in the morning it got stuck after the first hour and didn't make progress beyond that. If the Rust parts can be locked to a single process, it would allow the non-Rust parts (primarily C++ code, which still makes up the majority of the codebase) to run using multiple processes. That'd give us a nice speed-up.

Unfortunately I wasn't able to get the changes to work correctly with my build engine. I suspect it's simply a case of me needing to reinstall the build engine to get a more recent version, but as this is quite a major task, it'll have to wait for now. I'm not as familiar as Matti is with the Rust toolchain in the Sailfish SDK, so I'm going to have to go back and discuss the details with him.

Finally, and this is really important, I received an email from Frajo concerning the libhybris changes. This also relates to the discussion on GitHub between Affe Null (affenull2345), Mal (mlehtima) and Frajo (krnlyng) in relation to getting the build running on Affe's Samsung Galaxy A40 port.

One of the outcomes of that discussion was to expose a further potential issue in libhybris. Once fixed Affe reported that the cover crash described in issue 1051 was no longer occurring. This cover crash has been a thorn in my side for several months now, so I'm really keen to know whether it does actually fix it or not.

Frajo provided me with some new libhybris rpm packages to test out that include these latest changes. Having installed them and tested the browser I find that... yes! The cover change no longer causes the browser to crash. This is good for having the cover working with the browser, but even more important is the fact it also resolves the issue with the email app and other WebView apps crashing when moving in and out of the app.

So I'm super-pleased with all this. I've sadly not had time to get involved in the topic in the forum over the last few days, but it's incredibly exciting to see all of the discussion and am thrilled at the effort people are putting in, not just into finding bugs, but also into resolving them.

Sadly I have to stop for the day today, but since I've made changes to the commits, especially to the optimisation of the build, I need to run a new build overnight from scratch before I can create my pull request. It'll add an extra day, but it's important to check everything is working correctly both at build and run-time after this change. Just one of the many reasons this has been such a slow process! Assuming the build passes, tomorrow morning I'll do a bit more testing of the changes and if all goes well I'll be able to create that pull request.

Tomorrow will be the last diary entry before I take a week off to attend RSECon24. I'm hoping I'll get the pull requests submitted by then, but either way there will still be more diary to write once I'm back in a week's time. So much to do!

If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.