UBports Q&A 103 on 3 July 2021
The hosts this time were Alfred and Dalton.
Go to devices.ubuntu-touch.io for info about whether your device is supported.
Focal 20.04 development news
Indicator-network is finished and merged for 20.04. Mir 1.8.0 is done too. Rodney is working on ways to install .click packages without root, which we very much need because the old mechanism we used to achieve that will no longer be available. While doing all this we are working on ways to have this content work as an upstream source for others. Rachanan and Mike are currently working on scripts which will make that easier. You can find those in Devscripts in our Gitlab.
Incorporated into our Gitlab we now have ‘epics’ which set out the issues which need to be addressed to make 20.04 happen. In each epic you will see a list of milestones. They are not absolutely comprehensive but you will see a great many of the items we need to work on to reach our goal.
We start with system images for each device and then build that out with an app ecosystem which works nicely with those system builds. Testing comes next and that is where many more of you will be able to help us. We are aiming to support ‘all’ currently supported devices and although we have not met any device roadblocks yet, there is no guarantee that the 20.04 build will work with everything. It is a fairly lightweight style of project management, which has the advantage that Dalton is able to handle it without getting completely weighed down with the task.
We have just seen a couple of interesting updates to OpenStore. It now has a structure in place for the future support of apps which run on the Focal (20.04) build. This is about getting ahead of the game, so we are ready as soon as Focal comes on stream. Many thanks to Brian for his work on that. Aside from that, OpenStore now displays a version history for apps. Not only does it show them but it links to downloads for those older versions.
Jonny has been working on Clickable support ready for 20.04. It will need further modification alongside the ongoing preparations but again the intention is to have it completed by the time we make the formal switch.
If you are looking at those epics but you don’t have a device which runs UT you may be wondering how you might make use of it.
Alfred has been putting together something which you may find interesting. On his new laptop he didn’t have the tools necessary to build and test for UT anymore, as it isn’t running on Linux. However, he also wanted to have access to a set of tools that were easier to use, so he created a thing called the Platform Development Kit. It is basically a collection of bash scripts and parts of qemu. This environment allows you to run and test packages on your machine, in a virtual environment. If you run it on an Intel machine, you are in effect building Intel based packages and running those. When done, they can be built on CI, to provide support for all supported architectures. You can also emulate on demand by using the -a argument, in order to build and test for another architecture. The source code is called into your host directory. What that means is that you can amend code on your host machine but it will automatically mirror into your virtual machine.
This is all in addition to cross-builder and other solutions which we already have. It extends capability substantially and is a lot more user-friendly so it has the potential to assist developers who are interested in UT and want to look at how 20.04 can best be utilized to support it to have a go.
With the options we had until now, we had to have images ready for at least one device before the tools could be used and of course still only for that first device. Now we have a development platform available, long before we ship UT based on 20.04 to any device at all.
A screen was called up to demonstrate the tool, so you really need to follow the video version from 10.56 minutes, to see how it looks. On first run, it will take you automatically through a setup procedure. SSH will be configured and the directories will be created on your host. Once it runs, you will see a small qemu window on your desktop and you will be able to login there. There is a small bug involving lightdm and you will have to stop that before continuing. A lomiri shell can be started from within root. Amazingly, that shell already has wayland support! Mirclient support is there at a preliminary level but there is no hardware support available as yet. Once you have the development work done on your host in the VM it can not only download all the dependencies it needs but also do the build for you. The icing on that cake is that it even incorporates test routines :)
As the network-indicator package is already complete for the 20.04 build, it is possible to call that up within the VM and Alfred showed the interface of that module on the screen.
Just to emphasize, this package of tools is independent of platform, so if you have no UT device but you do have a Mac, from now on you can develop for us! There will be a few bugs in it of course but you are welcome to add those to the Github for the PDK project. It exists in working form on both Linux and Mac at the moment but as Alfred does not have a Windows machine, he will need some assistance from someone who does, in order to get it working on that platform too.
Dalton described the new kit as a quantum leap forward for UT.
Last time round, Dalton described some of the work he has been doing in his mentoring project with Capsia. Up until now, the Greeter has not been able to rotate and that was a pain on tablets, which are generally held in landscape view. In the present setup, the Greeter actually has two different formats, so the first task was to combine the two into a single file. The new solution is still undergoing testing and there has been no pull request but as soon as there is you will have an opportunity to try it out.
One of Alfred’s reasons for the Mac was to have a native ARM device, which will make it much easier for him to build for ARM based UT devices. Alfred maintains several ports and wanted to be able to continue that work using the Mac so he has built Halium 9 support for it. There is just one detail to fix and that is a make file for the kernel repository. Again, if you have a Windows machine and are trying to use WSL for porting but don’t have USB support with that, it is an issue which needs sorting and you are invited to get in touch so that we can explore creating a fix.
Marcus is weeding on Gitlab old reported issues
Marcus has been doing a great job going through old issues on Gitlab and weeding out those that are no longer current. That is a great example of how a burden of work can be lifted from the core team so they can focus on taking the project forward. Where issues are still live, it will be immensely helpful if log-files related to the errors can be attached to the issues. That will give a head start to those who are trying to fix them. You may not be able to help with fixing the code but even with very basic skills you should be able to reproduce a fault and then extract the log-files for it. That will save the developers a lot of time, especially if it is a device specific issue.
Questions
The News section of our Forum is the best place to post questions for the Q&A. YouTube live chat, Telegram and Matrix are other places to post a question.
If you didn't know, the Forum questions get priority.
RUST and Ubuntu Touch
Auri88 said that there is increasing interest in the use of Rust as a programming language, especially for its built-in memory protection mechanisms. Could this language by brought into UT and which components do you think would most benefit from its use? A move to do that would be immensely popular, for both system development and app development. As is often the case though, it can only happen if some developers step forward and pick up that task. We are back to resource issues. Some users have already used Go or Python for building applications, so there is a precedent. Translating the indicators into Rust would be a very interesting project for someone knowledgeable in Rust and would be valuable for UT because they are currently a very mixed bag. You can already use Rust in Clickable so if you want to build an app in Rust there is nothing stopping you.
There has been some talk of Rust support being built into the Linux kernel at some point. That will not happen soon but it would open up a lot of possibilities. If you want to go really low level you could participate in a project around that.
Assisted GPS implementation
Opaijavai asked about GPS in UT and the fact that it is practically impossible to get a fix inside a building. Is there any plan to implement assisted GPS or something similar? On the location-services repository there is a Xenial Edge Wayland branch. In that branch there is a location provider named Ichnaea. That is a plugin for the Mozilla service. It would have to be enabled for Focal but maybe that could be done. Mozilla location doesn’t work well everywhere but it does in some areas. There are some nerves around the solution though because Mozilla has had some legal issues with that service in the past. We don’t have the expertise to analyze what happened there but we would not want to put ourselves in any position of difficulty as a secondary user.
Morph browser alternatives
Twridick asked how it is that Morph browser is built into the OS and cannot be uninstalled? Do other parts of the OS depend on the browser? In future, can we have some alternative?
The other and bigger aspect of this is Morph webapp container. In theory, the whole bundle of Morph an qtwebengine could be packaged up as a click and be updated with each OTA. Admittedly not quite as fast as OpenStore version updates. There are indeed parts of the system that rely on qtwebengine. A solution to that isn’t obvious at the moment. Currently we are running an outdated version of qtwebengine because we don’t have a maintainer who is available to implement the latest versions from the upstream. A limited amount of work has been done to get qtwebengine 5.15 working on UT but we could certainly do with some help to finish the work on that. Backporting is a messy solution because inevitably it falls further and further behind. We are always running to try to catch up.
Implementing the webcontainer in an independent package is also theoretically possible but we really do not want to get into splitting app updates into two parallel architectures because that would be a security nightmare.
Is Anbox a security hole?
Antiform had a question about security. If Anbox becomes well used, does SElinux cover it or apparmor? If not, looks like a big security hole? Although Anbox could in principle run largely unconfined, we would expect it to be treated by apparmor in the same way as any other app. Sensors for example are handled through sensorfw and talk to each other through very tightly defined interfaces.
What can happen through Anbox though is the download of malware which has the potential to compromise the system. Nevertheless, apparmor can still be configured to take care of that situation. There are challenges of course as with anything security related but in principle, apparmor is still an effective counter to Anbox threats.
As an aside on this, the question arrived just a few hours before the live broadcast. That isn’t too much of a problem with straightforward questions but this one deserves a carefully considered response and could have been answered much more effectively with a few days notice.
Can we have Ubuntu Touch party?
Thousandtopics asked whether after the pandemic is over we can have a big UT party somewhere? Second, what about the systemd security exploit which has only just been announced but has been open for the past seven years? Finally, if a country asked UBports to breach the security of UT for them would you create a backdoor for them? We have had events in the past. They are organized by the grass-roots of our community and if you want to do that locally, go ahead by all means and we will promote it.
Should Ubuntu Touch move to BSD?
There are major security flaws found in the linux kernel at a rate of around one a year. So do we move to BSD? No we don’t. All software has bugs. That is the nature of software. Ubuntu and Debian use systemd, so it makes sense for us to use it too. If you wanted to do your own thing and use openrc or S6 you would of course be welcome to make that fork. If you would like to dig around in this issue, the talk called ‘The tragedy of systemd’ is highly recommended.
On the final point, you would have to set your threat analysis way wider. There are all the upstream resources we use, as well as the compiler and the compiler used to build the compiler… If your concern is about a major state actor you have already lost.
Louis asked whether in the second half of the year Lomiri desktop will start to provide a packed version for development purposes on 20.04? Well the new PDK can help towards that, so please make use of it. There is a way to go with Lomiri but the PDK provides an easy way to test interim builds and to contribute to its development. It will be quite a while before it will behave in a stable, predicable way so what better than to handle it inside a VM?
See you next time :-)
