flypig.co.uk

I left the build running last night after applying patches 0022 through 0026. I was hoping that might have done the trick and we'd find some rpms in the output directory. No such luck sadly. Here's the error that awaited me this morning:

 0:29.71 Creating config.status
 0:30.69 Traceback (most recent call last):
 0:30.69   File "$PROJECT/gecko-dev/configure.py", line 226, in 
 0:30.69     sys.exit(main(sys.argv))
 0:30.69   File "$PROJECT/gecko-dev/configure.py", line 80, in main
 0:30.70     return config_status(config)
 0:30.70   File "$PROJECT/gecko-dev/configure.py", line 219, in config_status
 0:30.70     from mozbuild.config_status import config_status
 0:30.70   File "$PROJECT/gecko-dev/python/mozbuild/mozbuild/config_status.py",
           line 21, in 
 0:30.70     from mozbuild.frontend.emitter import TreeMetadataEmitter
 0:30.70   File "$PROJECT/gecko-dev/python/mozbuild/mozbuild/frontend/emitter.py",
           line 23, in 
 0:30.70     from .data import (
 0:30.70   File "$PROJECT/gecko-dev/python/mozbuild/mozbuild/frontend/data.py",
           line 20, in 
 0:30.70     from mozbuild.frontend.context import (
 0:30.70   File "$PROJECT/gecko-dev/python/mozbuild/mozbuild/frontend/context.py",
           line 1927
 0:30.70     ),
 0:30.70     ^
 0:30.70 SyntaxError: invalid syntax

That error is coming from one of the files that got patched yesterday. Presumably it's because I performed some of the manual conflict resolution incorrectly.

Checking the code, the error I made is immediately obvious:

    "SDK_FILES": (
        ContextDerivedTypedHierarchicalStringList(Path),
        list,
        """List of files to be installed into the sdk directory.

        ``SDK_FILES`` will copy (or symlink, if the platform supports it)
        the contents of its files to the ``dist/sdk`` directory. Files that
        are destined for a subdirectory can be specified by accessing a field.
        For example, to export ``foo.py`` to the top-level directory and
        ``bar.py`` to the directory ``subdir``, append to
        ``SDK_FILES`` like so::

           SDK_FILES += ['foo.py']
           SDK_FILES.subdir += ['bar.py']
        """.
    ),

In my sleepy haste to get the changes in last night post-midnight, I added a full stop at the end of this entry, rather than a comma. The penultimate line should read:

        """,

I've made the change, fixed up the relevant commit (which happened to be for patch 0025) and set the build running again.

This highlights the difficulty with development at this late stage in the process. Each small error triggers a four-hour rebuild cycle. It's slow, but at least it's not particularly laborious given my laptop is doing all of the work.

In this case the build very quickly fails with a new error:

 3:58.27 ./BaseChars.h.stub
 4:06.04 $PROJECT/gecko-dev/config/rules.mk:1010: *** Missing SDK_LIBRARY_DEST.
         Stop.
 4:06.04 make[3]: *** [$PROJECT/gecko-dev/config/recurse.mk:99: intl/unicharutil/util/export] Error 2

After some digging around, it looks like this error may be related to patch 0027, which I've now applied as well. Off the build goes again.

[...]

The build has now at least got past the point where it was triggering an error previously, so patch 0027 seems to have had a positive effect. I'll have to now come back to this after work to see how it's got on properly.

[...]

It's after work now. The build still failed, but things have improved and the situation is a lot clearer; I think even fixable now.

The command that's failing is the following:

ln -s /home/flypig/Programs/sailfish-sdk/sailfish-sdk/mersdk/targets/SailfishOS-devel-aarch64.default/usr/lib64/xulrunner-qt5-91.9.0/libxul.so \
  /home/deploy/installroot/usr/lib64/xulrunner-qt5-devel-91.9.0/sdk/lib/libxul.so

The error it's generating is this:

ln: failed to create symbolic link '/home/deploy/installroot/usr/lib64/
  xulrunner-qt5-devel-91.9.0/sdk/lib/libxul.so': No such file or directory

I interpret that error as meaning that the command can't find the target destination for the symbolic link. As it happens the it looks like the source is wrong too. In fact, as we can see here, the correct command looks to be the following:

$ ln -s /home/deploy/installroot/usr/lib64/xulrunner-qt5-91.9.1/libxul.so \
  /home/deploy/installroot/usr/lib64/xulrunner-qt5-devel-91.9.1/sdk/lib/libxul.so
$ ls -lh /home/deploy/installroot/usr/lib64/xulrunner-qt5-devel-91.9.1/sdk/lib
total 17M
-rw-r--r-- 1 1001 100000  16M Sep 26 10:17 libmozglue.a
-rw-r--r-- 1 1001 100000 1.1M Sep 26 11:58 libxpcomglue.a
lrwxrwxrwx 1 1001 100000   65 Sep 26 12:38 libxul.so ->
  /home/deploy/installroot/usr/lib64/xulrunner-qt5-91.9.1/libxul.so

There are two errors here. First the version number is incorrect. The spec file is using xulrunner-qt5-devel-91.9.0 whereas it should be xulrunner-qt5-devel-91.9.1. Second it seems the softlink source location has a messed up prefix for reasons I can't yet quite work out.

The reason for the first is really obvious: I've put this at the top of the spec file:

%define greversion    91.9.0

I've now changed that to 91.9.1.

The second isn't immediately obvious, although I have some ideas. I don't have time to look into them properly now though, so I've just kicked off another build after having made the above change. It will be interesting to see where that takes us.

[...] It's only gone and built!

The package names are wrong and there's some unsettling warnings in the console output, but it has built!
 
Although there are some concerning bits, there's also a lot that checks out too. The package contents look sensible in terms of structure, all of the expected files are there and their sizes are appropriate too.

This is very exciting!
 
I'm going to declare Stage 1 as being officially a success (let's not think too hard about Stage 2 or 3 just yet).

For those who like the numbers, the build took 4 hours 43 minutes and 10.13 seconds to reach the rpm packaging stage. The last part isn't measured, but packaging the rpms takes about 20 minutes. That means it takes approximately 5 hours to do a complete build with a single process. It would be faster if I increased the number of processes, but that introduces a danger of the build hanging, so ultimately using more processes can take longer in my experience (because I have to restart the build periodically).

The reason for the incorrect name is that the package is being named from the most recent tag:

$ git describe --tags --abbrev=0
sailfishos/78.15.1+git36

I should be using the no-fix-version configuration option for sfdk.

sfdk config --session --push no-fix-version

I've decided I'm not going to do any more in-depth development today, so I've set the build going again to create a set of rpm packages with the correct version number overnight.

Hopefully in the morning I'll have a collection of usable rpms to try out.

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