Before and during FOSDEM 2020, I agreed with the people (developers, supporters, managers) of the UBports Foundation to package the Unity8 Operating Environment for Debian. Since 27th Feb 2020, Unity8 has now become Lomiri.
Recent Uploads to Debian related to Lomiri
Over the past 7-8 weeks the packaging progress has been slowed down due to other projects I am working on in parallel. However, quite a few things have been achieved:
- review forks of unity-api, ubuntu-download-manager and unity-app-launch under the names lomiri-api, lomiri-download-manager, lomiri-app-launch.
- request upstream releases of lomiri-api and lomiri-download-manager
- package and upload lomiri-api to Debian unstable (unfortunately still in Debian's NEW queue)
- package and upload lomiri-download-manager to Debian unstable (dito)
- package (and with 'package' I mean Debian policy compliant packaging) lomiri-app-launch (no upload, yet, as there are some strange unit test failures that need more debugging)
- package and upload qtsystems (under the umbrella of the Debian QT/KDE Maintainers' team) to Debian unstable (pending review in Debian's NEW queue)
- package and upload qtfeedback (under the umbrella of the Debian QT/KDE Maintainers' team) to Debian unstable (pending review in Debian's NEW queue)
- package and (upload) [1] qtpim (under the umbrella of the Debian Qt/KDE Maintainers' team) to Debian unstable (pending review in Debian's NEW queue)
The packages qtsystems, qtfeedback, and qtpim are no official Qt5 components, and so I had to package Git snapshots of them; with all implicit consequences regarding ABI and API compatibilities, possibly Debian-internal library transitions, etc.
Esp. packaging qtsystems was pretty tricky due to a number of failing unit tests when the package had been built in a clean chroot (like it is the case on Debian's buildd infrastructure). I learned a lot about DBus and DBus mocking while working on all those unit tests to finally pass in chrooted builds.
Unfortunately, the Lomiri App Launch component still needs more work due to (finally only) one unit test (jobs-systemd) not always passing. Sometimes, the test gets stucks and then fails after having reached a time out. I'll add it to my list of those unreproducible build failures I have recently seen in several GTest related unit test scenarios. Sigh...
Credits
A great thanks goes to Lisandro Perez Meyer from the Debian KDE/Qt Team for providing an intro and help on Qt Debian packaging and an intro on symbols handling with C++ projects.
Another big thanks goes to Dmitry Shachnev from the Debian KDE/Qt Team for doing a sponsored upload [1] of qtpim (and also a nice package review).
Also a big thanks goes to Marius Gripsgard for his work on forking the first Lomiri components on the UBports upstream side.
Previous Posts about my Debian UBports Team Efforts
References
- [1] Unfortunately, I missed a crucial element of the GPG key update workflow as Debian Developer. My GPG key was about to expire at the end of March 2020. I renewed its expiration date and exported its public key to the public PGP/GPG keyserver. However, for being able to upload packages to Debian, one has to push the public key to Debian's own keyring server. Which I missed. Thus, I won't be able to upload any packages before the end of April myself and will depend on DD colleagues helping out with sponsoring my uploads.