Halium 7.1 base

Florian updated on some of the devices. Some core devices are moving to a Halium 7.1 base. There are lots of fixes since Android 5. With the update, OnePlusOne finally has auto-focus, zoom and flash. Maybe we can move to providing these upgrades simply by choosing Devel channel. Early builds can be accessed via the forum in the porting section but of course they may contain bugs.

Carddav hackathon

The German community are organising another hackathon, this time on carddav support. Calendar and Contacts synchronisation is a key feature for a phone so we need to get it working properly. The meeting is expected to take place around 13-15 November. Space is limited, so you should book if you want to attend. Ask around in the main groups to find out more.

UBports installer new beta released 

Jan reported that UBports installer 0.5.2-beta has been released. Heimdal support is now included, which enables Samsung support; it can be used to install other operating systems – great for Volla for example;  there are some bug fixes and you can now use the installer behind a proxy. It can also now download archive files, which will assist those on poor connections. Finally there is a new supported device – the Nexus 6P. Unfortunately there is also a new bug in the Windows version of the beta. The installer fails at the last step. Use an older version for now but the next release will provide a fix. We still need testers for that fix, so volunteers please! The next release will also have support for Electron 10, rather than the Electron 5 we were stuck with before. Beyond that, we are working on some modifications which will aid installs on the Raspberry Pi and the Pinebook Pro. We are using Github Actions, which actually is really nice. The installer will soon have the ability (on an experimental basis) to provide automatic user feedback to Open-Cuts. (see below details)

For the future, some planned improvements to the installer are some UI upgrades. Currently the oldest parts of the installer are the UI elements. Some help with that would be very welcome. The intention is also to group the installer into discrete modules, to aid reuse elsewhere and to improve testing and stability. We still do not have a data backup system integrated into the installer. We have wanted one for a long time and now hope to make some progress with that. If you want to get involved with this or any other aspect of installer development, head over to the forum. Message Jan on Telegram if you want to be added to the working group.

We did really well with testing for the installer this time round, including on the Mac build. Big thanks to all who helped out.

UBports Open-Cuts (watch minute: 14:17 - 22:30)

The UBports Open-Cuts link is accessible within the forum and provides a dashboard where you will be able to navigate around a structured feedback system on aspects of the software, including (and beginning with) the installer. If you click to the installer feedback page you will see that it is organized by version. The page will direct you to a test protocol designed for a specific element, so that we can have structured rather than accidental testing. The page also shows how many tests have been carried out in total and shows a summary of their outcome. It is possible for testers to upload log-files here. There are even graphs, so you can see the progress of testing more clearly. There is a lot more detail on the installer pages than elsewhere at the moment, as we are using this module to explore the functioning of this new approach to testing. As we learn from this and it becomes more robust, we can start to extend the same mechanisms to other modules. As explained, the installer will itself be able to populate Open-Cuts fields in real time, subject to consent from the user. As usual, the installer is built from a java-script variant. It uses a Mongoose client for that, which is helpful if you want to get involved but are not very familiar with Java-script. If you are a Mongoose specialist (MongoDB), definitely get in touch!

There is also an opening here for QML programmers, who could start to work on links between apps and this developing system for feedback. They are also very welcome to join our @opencuts group on Telegram.

Halium docs improvements

Alfred brought us up to date with improvements to porting documentation. A lot of people have asked for guidance but it has been rather messy and to be found in various different places. Thanks especially to Ari, we now have revamped our documentation on porting steps. The information is presented in a more structured way and does not focus too much on the finer technical details, so it is much easier to read. It also starts to discuss Halium 9.0, where previously it had been mostly about Halium 7.1. There will soon be an integration of the FAQs on porting.

Halium 9.0 Recovery build

Alfred has been working on a 9.0 side project. He has created a 9.0 Recovery! At the moment it uses Lineage for branding but we are going to switch that. Anyone who wants to help with that graphic update is welcome. If you want to assist, go to UBports on Github and you will find the Recovery page there (halium_bootable_recovery). At the moment, it is only for non-GSI devices. Doing the same for GSI devices will be a whole other task. It will be baked into the standard Halium repository eventually, so porters will get it automatically. Contact Alfred directly or make a PR on Github if you want to help out.

Pixel 3A and 3A XL work

On Pixel 3A or Pixel 3A ‘XL’ work is nearly done on C coded 2.0 enablement. Video playback on the 3A is now working, as well as on any other device that uses that same coding. Google added a ranking system for codecs and that means having to use hardware accelerated decoders only. Again, ping Alfred if you have any issues about this. There is a bug which prevents thumbnails from being created. Odd but being examined currently.

With those changes, we are very close to a first release of UT for the Pixel 3A. GPS needs some work as it doesn’t function right now. Porting activity as a whole has expanded hugely recently. Of course lessons learned from one device are often helpful to others, so the scale of involvement now is driving progress faster. Initramfs has changed in Android, so there is a particular challenge for all of us.

Testing with the XL is now urgently needed, to see that everything works the same. Again, volunteers to Alfred please @fredldotme). The two devices are very similar.

During the Q&A, Jan got word that there is work going on to restore the Checkbox app. This was one of the feedback apps.

Sponsors were thanked. 

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.

Hacktoberfest

Matteo asked about Hacktoberfest. It is now opt in only. When we participate actively it takes a lot of our time to make it happen. Dalton generally leads by adding some ‘good first issues’ but our main driver for those is that they should act as a good introduction for beginners to learning the processes we use. For example, they might start to find their way around Clickable, by working on an app. Frankly, everyone is so busy right now that putting some up this month is not going to happen. We are getting a lot done but as a result, some things will fall off the list. What we can do though is to add the ‘accepted’ status to your Hacktoberfest PR, if it is relevant. We will be very happy to provide that tag for any UT work in October.

Volume of work and background animated apps

Ari88 referred back to comments from Dalton in an earlier Q&A to the effect that a lot of resources have to go into looking at commits submitted by the community. Was that stress point mainly due to the then up-coming OTA or is it an ongoing issue? There has not been a huge surge in PRs lately but there is a steady growth, so yes it is an ongoing challenge. What has changed is the volume of work on all kinds of other things, so the pressure in that area is being felt more acutely.

He also asked about Plasma Mobile’s animated background weather app and wondered if we could have something similar? To clarify, Lomiri doesn’t care about the background used by an app, so there is no practical obstacle there. It could be done.

USB PinePhone boot option

Ubuntutoo asked whether it would be possible to boot the PinePhone from an external source such as a USB flash memory? An advantage would be not having to remove the back cover when swapping SD cards. The answer is that there is no absolute technical obstacle but there would have to be unanimity on a solution from every project building an OS for the PinePhone. To illustrate with a desktop, the BIOS runs a mass of code up to the point where the OS itself is launched. An equivalent booting mechanism does not exist for the PinePhone. We use the uboot boot-loader. That has to bring up all the devices it needs, before the OS boot. Every distribution would have to consent to uboot being designed to add any USB storage device at startup. There would have to be agreement too on a standardized way to do that and there would have to be a corresponding boot mechanism installed on the SD card directly, at all times. So it certainly isn’t a straightforward thing to organize. Honestly, there is not much chance of something like that being resolved any time soon.

UT read/write permissions design

Rick asked whether a separate build that has rw rather than read only might be a worthwhile option? It could maybe be the Development channel default? Might doing that attract a new developer base and speed the advance of UT? On the general issue of “Why isn’t UT more like a traditional Linux OS?” , this is something we hear very regularly. That would be fundamentally different though from what UT actually is, so the suggestion is in practice about developing a separate, related but different operating system in parallel. The pressures we are under to develop just one operating system are well known and there is just no way we could take on all that extra work. The update infrastructure for apt alone would be way more than we could handle. Also, an apt update can easily keep the device occupied for 40 minutes. How would you handle battery overload with that happening? Building two separate infrastructures for two distinct operating systems would be massive over-reach. The toll of bug-fixing would at least double, so that would slow development drastically, not speed it up.

Although people sometimes say about UT that they would prefer a ‘real Ubuntu’, even if we developed a more desktop-type parallel OS, the chances are surely very low that it would compare favourably with those projects which are working on that full time?

The reality is that Debian (to take an example) does not have a large surplus of developers that we can ‘borrow’. They too are hurting for contributors. There are not enough developers to go round and poaching from them is not a way forward for us. Dell, Lenovo and HP load Ubuntu and Fedora onto laptops aimed at developers. Entering into that market looks like a highly fanciful proposition. We are way smaller. ‘Being them’ is not a way forward for us.

In terms of philosophy, UT today is closer to Android, iOS and Chrome OS than it was when it was launched by Canonical. We are deliberately moving away from its desktop origins and we don’t have any wish to reverse that. UT is contemporary, not traditional. The traditional market is shrinking all the time.

UT does not start from placing lots of trust on individual developers. Sand-boxing designs out risk.

Our existing developers are anyway not limited by the default read only status. They are able to switch to rw at any time and they do so routinely. Alfred used rw when he was trying his NFC builds. But although he is a developer and knows what he is doing, he switched right back to read only as soon as he was finished because he knows the importance of doing that for stability and security.

UT was always about end users in the mass market. Those are not people who would expect or should have to fix issues with their phones from time to time. It should ‘just work’. Developers break things constantly. That is unavoidable and understood. It is no problem for them because they can hunt around for the fix. With UT, they are also not stuck for a phone. They can just download from the Stable channel and restart, returning everything back to normal. The success of Android and iPhone is based to a large extent on the fact that the user is limited in what they can do with the system. UT is not aimed at the needs of a developer community. That is not our mission. That means making trade-offs but we are comfortable with that.

[Rant ends :-)]