Hi all,
I've written a few notes about my plans to add CardDav support to Ubports in the ubports-dev mailing list:

https://list.ubports.com/pipermail/ubports-dev/2018-March/000005.html

Ciao,
Alberto

Hi all!
I've recently spent some time to rebuild the kernels for a handful of BQ devices; while my initial goal was to just enable the FM radio on them, I made an unhappy discovery along the way: just building the kernel sources that we have in github does not produce the same kernel that we are currently running in our devices — a few options are different.

So, I spent some time finding what the differences are, and tried to change the kernel configurations so that they would match what we are currently running (and yes, in the process I also enabled the FM radio on them ). Now it's time to give them a week or two of testing, and then we can decide whether to push these kernels to all users.

Call for testing

Please download the kernel for your device:

• BQ E4.5: install the kernel from this release.
• BQ E5: install the kernel from this release.
• BQ M10 HD: install the kernel from this build.
• BQ M10 FHD: I don't have this device, please attach the file /proc/config.gz to this thread and I'll make a build for it.

Then, reboot your device to the fastboot mode (POWER + VOL UP, then select "Reboot to bootloader") and run

# Adjust the path as needed
fastboot flash boot /path/to/the/downloaded/boot.img && fastboot reboot

It does not matter what channel you are running on your device.

What to pay attention to

Ideally, you should see no changes. If you observe a degradation of the power consumption, or if something stops working, please report it here.

Why test this?

Because this is the first step we need to take in order to hope to move these devices to 20.04; I'm not saying that if these kernels work we are all happy and ready to go, but this is a prerequisite. So, please, if you have one of these devices, give it a try, and report back (maybe after a week or two).

Thanks in advance

Hi there!
During the past weeks I've been working on a complete rewrite of the media-hub service (the client library is, for the time being, untouched) to port it from a hard to maintain codebase which was using the unmaintained dbus-cpp library and heavy threading, to an event-driven, single-threaded application (if we exclude GStreamer's own threading, of course, but that's well hidden behind GStreamer's APIs) mostly written using Qt classes.

I've tried hard not to change the D-Bus API, and — at least for now — I've kept most of the program logic exactly the same as it was before. I've done my part of testing, and I solved all the issues I've found so far, but given the magnitude of the changes it's likely that I've still left some bugs in there.

So, to those who love risk, I'll be grateful if you'll find some time to test it. There's only one package that needs to be installed, and it's the media-hub_4.6.2*.deb package from the CI page; just make sure to download the correct one for your architecture. To install it, run

sudo mount -o remount,rw /
sudo dpkg -i media-hub_4.6.2*.deb

and then reboot your device. If you encounter issues, please report them replying to this thread or adding a comment to the merge request, providing the ~/.cache/upstart/media-hub.log file and, if possible, also the file bustle.log obtained by keeping the command

busctl --user monitor  core.ubuntu.media.Service > bustle.log

running while reproducing the issue.

Hi all!
I wrote a blog post about my adventures with the Redmi Note 7 Pro FM radio chip, which saw a relatively happy ending. For those interested in technical details (or device porters) it might be an interesting read.

For all the others, the point of my message is that I intend to write a system service to handle FM radio. On the application side, it will be possible to use the QRadioTuner C++ APIs or the QML Radio element. No promise on timelines (I do have a handful of higher priority items on my queue), but it should be coming.

Ciao,
Alberto

Hello everybody

I'm glad to announce that on November 2nd I'll be giving a presentation of Ubports at the 4th Linux Piter conference, which will be held in Saint Petersburg, Russia. The sessions will be recorded, and I'll update this thread with a link to the video, once it gets published (approximately one week after the event).

The audience, as far as I've understand, will for the most part be composed by IT experts which work on different fields than mobile phones, but I still hope that some of them will become curious about our project.

Time will tell

Hi there!
I've been working on a few branches (you can find all the links here) to allow applications which are actively using the location service to continue running in the background, and therefore continue receiving location updates.

If you'd like to help testing this, please run

sudo ubports-qa install xenial_-_locationbg

on your phone, then reboot, and have fun

Please report any issues (including shortning battery life!) by adding a comment to this merge request.

Ciao,
Alberto

Hi all!
Today I uploaded a new version of account-polld in the ubports overlay PPA, which as far as I understand will be used to create the image for the "devel" channel.
account-polld is a background process which is always running in your device, and which gets waken up every 5 minutes to check if you have new notifications from your online services. At the moment, it supports gmail, twitter, google-calendar, caldav and dekko (gmail accounts only). This new version doesn't change anything of that, but takes a few steps towards the plan to allow click packages to install their own account-polld plugins.

In this version, account-polld has been completely rewritten: it has moved from being a monolithic binary written in go to a slimmer Qt/C++ service which runs the plugins as separate processes, on demand. For simplicity, the existing plugins have been reused and are still written in go, but they could be written in any language (they could even be shell scripts!).

Even though this version doesn't offer noticeable changes for the end user, you might be happy to know that the memory footprint of account-polld has decreased, as reported by top. Before:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 3391 phablet   20   0  919520  12764   8896 S   0,0  1,3   0:00.89 account-polld

and after:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 2979 phablet   20   0   60368   6328   5448 S   0,0  0,6   0:00.20 account-polld

It's just a few megabytes (look at the RES column, and keep in mind these are kilobytes), but on embedded devices every byte counts.

Testing!

The new account-polld has been tested and approved while I was still working in Canonical, but things were moving slowly and we never managed to land it. So, it may be that it hides some dragons
I myself use only the gmail plugin, and I've verified that it's working. Notifications for dekko don't appear to be working, but OTOH I haven't seen them with the old account-polld either. If you are on the devel channel or have a writable filesystem (install account-polld and account-polld-plugins-go from the PPA) please give these new packages a try and report any regressions.

Last but not least, the code for these projects is here:

• https://github.com/mardy/account-polld
• https://github.com/mardy/account-polld-plugins-go

@joelandsonja said in Pinephone Rant:

I can't tell you how frustrating it is to see more than 50 other phones on the 'supported devices list' that are leagues ahead of the Pinephone, especially when you consider the fact that the Pinephone was made specifically to support the Linux community and it feels like it's being ignored by the developers.

The problem is that the PinePhone is very different from the other devices we support, so even though it is in many ways the best device we could work on, in practice we have much more experience working on Android-based devices, whereas for the PP we have to redo many things from scratch.

I don't mean to sound so rude, but how long are we expected to wait to see some progress?

Speaking for myself, I can tell you that in the next OTA, if everything goes as planned, two PP-specific bugs will be fixed:

• https://github.com/ubports/media-hub/issues/29
• https://github.com/ubports/ubuntu-system-settings-online-accounts/issues/11

It's a drop in the ocean, I know, but this is just to let you know that we haven't forgotten about it - and I don't even have a PP myself.

Note: the instructions in this post are for expert users only, or for those who don't mind having to reflash their device if something goes wrong.

---

Hi there!
I've lately been working on a native application to watch videos from Youtube and other online services, without ads.

While the application works on the desktop, in Ubuntu Touch it's totally non functional because the media-hub component supports local media files only.

After some hacking on the media-hub and qtubuntu-media I got the videos to play, even though the application is still far from stable.

You can see a video here: https://youtu.be/wTygEsa_Er4

Now I want to have my patches to media-hub reviewed, but first I need to be relatively sure that they don't introduce regressions. The same component is responsible for playing videos and audio files, so both the Media player and the Music app need to be thoroughly tested.

If you'd like to help, please install this PPA in your device, which can be done by running the following command from a terminal in the device:

sudo ubports-qa install xenial_-_remotemedia

This should force the update of the media-hub and qtubuntu-media packages; if that's not happening, another option is to just download the deb files for armhf from here and here and install them manually with dpkg. After doing that, issue the command

initctl restart media-hub

or (better) restart your device, and verify (with the media player and music applications, mainly) that there are no regressions.

You can then install the MiTubo click package and try to play some videos from Youtube (following the steps I did in the video linked before), keeping in mind that this could crash and not working reliably. But what I'm mostly interested in knowing is that existing device functionality is not being broken.

Ciao,
Alberto

Hi there, I just released a VNC client application which I built using clickable + QBS, probably the only build system which I like.

I wrote a blog post to announce it, but while writing the post, I realized that there was some information that a developer could find useful, so I'm copying that here:

Development of a UBports Qt/QML app with QBS

If, like me, you are a fan of QBS, you might want to have a look at the source code of CuteVNC (yes, the project was born as "Lomiri VNC", but since it's a generic QtQuick.Controls 2 application, there was no need to tie it to the Lomiri environment); there you can find a QBS module for UBports applications, which can help in filling in the manifest file and deploying other Ubuntu Touch specific files into their proper install location.

You can also see the configuration file to make clickable build a QBS-based project. In my mental task backlog I still have the idea of making clickable support QBS out of the box, but the integration of the two technologies is so easy even now, that I gave this task a quite low priority.

A class for computing viewport transformations

Last but not least, a developer might find useful the generic Scaler class I wrote to compute the viewport transformations: it's a simple, QtGui-only C++ class which takes an input structure with the viewport information, and returns a similar structure containing a QTransform matrix to map item coordinates to coordinates in the source object coordinates (in my case, the source object is the remote screen served by VNC) and some other useful parameters, such as the scale, center offset, and the painted area rectangle.

The class has a 100% line and branch coverage in the unit tests, so I hope I can rely on it.

Hi all!
I got to a point where I'm ready to share the work I've been doing on the FM radio service, because it should be testable already. But please note, this is only for the adventurous ones .

Enabling your device

Unfortunately there is only a handful of devices supported at the moment:

• BQ E4.5: install the kernel from this release.
• BQ E5: install the kernel from this release.
• Xiaomi Redmi Note 7 Pro: should work out of the box, but you might need to reflash it from the installer (ticking the "bootstrap" checkbox) if you flashed it long ago
• Xiaomi Redmi Note 9 Pro: follow these instructions.
• Are you a maintainer of another device port which has hardware support for FM radio? Get in touch!

NOTE: the warning sign () means that there is a concrete risk to break your device if something goes wrong while following the operations to enable the FM radio, so it's a procedure recommended for expert users only.

Installing the FM radio service

If your device appears in the list above and you've followed the instructions to enable the FM radio on it, the next step is to install the fm-radio-service in your Ubuntu Touch device:

1. Download the fm-radio-service and fm-radio-tools packages matching your device's architecture from the latest build.
2. Copy them to your device, make the root partition writable and install them:

   adb push fm-radio-*.deb /home/phablet/
   sudo mount -o remount,rw /
   sudo dpkg -i fm-radio-*.deb
   

3. Start the command-line client:

   fm-radio-client.py
   

4. Make sure your wired earphones are connected.
5. Press 2 for "Open tuner", then Enter.
6. Press 7 for "Start playback", then Enter.
7. You can move to the next or previous station with 5 and 6, and you can change the volume with 4 (values are from 0 to 100)
8. Press 1 to quit the program and stop the radio.

Known issues

• On the BQ phones, the volume is not controllable via the hardware keys. It is probably possible to fix this by writing a pulseaudio module, but before spending time to work on this I'd like to understand how many devices would benefit from this. It's an issue that affects Mediatek-based devices only, and probably not all of them.
• On the Xiaomi devices, radio playback consumes about 10% of the CPU. There should be a way to establish a direct path from the FM radio to the audio device, but so far I haven't been able to find it.

Debugging

If things don't work, please do the following:

1. Quit the client application (press 1, then Enter)
2. Run

   FM_RADIO_SERVICE_TIMEOUT=999 fm-radio-service
   

   on one terminal and leave it running while executing the next step
3. Launch the fm-radio-client.py program again, and repeat the commands to open the tuner and start the playback
4. Attach here (or send them privately to me) the output from the fm-radio-service program you started on step 2 and the syslog (/var/log/syslog)

Feedback

Please let me know how it goes. If I get at least some positive feedback, there's a chance we'll see this in one of the next OTAs. I already have a UI application ready -- ugly, but working.

I've had a similar discussion with Dalton in Telegram, because I'm working on the FM radio service and getting it to work on the BQ devices requires a new kernel for them, and this led to a discussion about what we can do for them.

I'm certainly willing to spend some of my time to keep these devices up, but that might not be enough: from the UBports Foundation point of view, supporting a device means (and here I might even not be aware of all the implications!) having all the CI machinery to generate the images for the updates, not to mention the time spent by humans for bug triaging.

I guess that if we could reduce the involvement of the UBports Foundation to "just" produce a unified armhf rootfs for all these devices, that would be much easier for them, and we could probably expect a relatively high level of quality. But that means that the device maintainer would have to take care of producing the OTA images and diffs, and provide storage for them. GitLab CI can certainly help, but it's clear that the amount of work that would fall on the shoulders of the device maintainer (at least initially) is huge.

Do we have a team of volunteers, who do understand enough of the OTA machinery to setup a similar project, which might or might not be hosted by the UBports Foundation? I'm certainly willing to help, but it's not something I can drive myself. And I don't think we should ask anyone who's actively working in the Foundation to spend time on this.

If we manage to form a group, and find someone willing (and capable) of leading the project, then there's some hope. Otherwise, well, I guess these devices will have to live with Xenial for how long they can.

Hi all!
I've found the github group for ubports and I see that there are a few repositories in there. However, it's not clear to me where the various bits of code are. For instance:

1. How is the image generated? Where can I find the list of debian/click packages preinstalled in the image?
2. Where are the actual packages taken from? Are they taken from some PPA as it was the case for Canonical images, or how?
3. In the community Q&A, it was mentioned that A-GPS support was added; where can I see the change in the code which enabled that?

I hope that these questions will help me and other people who want to contribute

At the moment, the project has identified itself as ubports: this site, the github repos, the patreon page, it's always "ubports".
I think that if we want to move constructively, we should take one step at a time and instead of immediately proposing new names, decide whether we want to keep "ubports" or change. If we decide to change, then we'll have a chance to think of a different name.

As for myself, I'm all for changing. "ubports" is just a nightmare to pronounce, and to most people (even geeks) it means nothing -- the link to Ubuntu is far from being evident. Besides, the "ports" suffix reminds of porting, but the project now has grown into something considerably bigger than that: it's a full O.S. which we'll be maintaining ourselves.

Hi all,
I started working on porting UT to this device (I have the 6/128GB version). Almost nothing is working at the moment, but I got Unity8 working, at last.

I've written a blog post with all the gory details in my blog.

BTW, if you own this device and would like to run UT on it, your best bet is to join this Telegram channel (this is not based on my work).

Ciao,
Alberto

@domubpkm said in Selling a Xiaomi Redmi Note 7 with UT preinstalled:

What is the situation with all alternative OS in Russia ? Can you freely and officially use here UT or any you want ?

I'm not aware of any restrictions, and I've been using UT on my phones for 5 years already.

Hi there!
In the last few days I've been working on a command-line installer for Ubuntu Touch. The goal is not to replace the current graphical installer, but to have a piece of software written in a language (shell scripting) that is familiar to more developers, and that hopefully would be easier to modify.

I've tried to write it in such a way that it should not be hard to embed it into a graphical application; it's not fully ready for that yet, but if someone familiar with the graphical installer source code wants to try embedding the command-line installer, I can support him

At the moment, this is in very early stages:

• it supports only the BQ devices cooler, frieza, krilling and vegetahd
• localization (translations) support needs to be implemented
• need to find a way to package it (I'll most likely create a snap myself, but all contributions for other packaging formats will be welcome)
• need to write a README file explaining how to write device config files

I would appreciate if interested people would try it and report back, but for the time being this is for advanced users only. You need to clone the repository and execute the flasher script from there:

$ ./flasher -h
Usage: flasher [options] [command]

If no command is given, the 'flash' command will be executed by default.

Options:
 -b, --bootstrap          Also flash the vendor firmware (this option is needed
                          if the device is currently running a different OS)
 -c, --channel <channel>  Uses the given channel (default is 'stable')
 -d, --device <dev-id>    Specifies the connected device (default: autodetect)
 -h, --help               Show this help screen
 -q, --quiet              Reduce verbosity level
 -v, --verbose            Increase verbosity level
     --wipe               Erase all user data on the device

If you don't own a BQ device but would still like to try it, the existing files under the device_configs/ directory could serve you as an example; the fact that these files are bash scripts, make it possible for the device maintainer to execute almost any type of operation in there (and it is possible to override the default actions). If you manage to write a working config file for your device, please make sure to submit it with a merge request!

@applee said in Call for testing: background location updates:

Can you tell us more about how to test and how it works ?
Simply because and app is using the location it won't go to sleep after timeout or shutting down the screen, is that it ?

Yes. Replying to both:

@cliffcoggin said in Call for testing: background location updates:

I too am interested in such an application. What advantage does it have over preventing suspension with UT Tweak Tool?

This is not an application, but a set of changes to the OS itself. It mainly consists of two parts:

1. The location service exposes a list of the application ID which are currently receiving location updates
2. Lomiri (new name for unity8) monitors that list, and sets the LifecycleExemption flag on those applications; the flag is removed when the application requests to stop receiving location updates.

So, it is similar to what the UT Tweak tool does, except that this is automatic, and lasts only for as long as the application is using the GPS.

This is just the first iteration: in the future, we would like to have it so that when an app requests access to the GPS, the user is given the choice between granting the permission to receive such updates in the background, or only when in the foreground.

Hi all,
I've written a length e-mail to the development mailing list here.

Your input is very appreciated, either in the ML or as a reply to this forum message.

Ciao,
Alberto

Hi there!
I'm a happy owner of a YI 4K+ action camera, but unfortunately I haven't been able to use the livestreaming feature because it relies on a companion app which is only provided to Android and iOS users. Until today

I've uploaded a YI livestream app in the store which allows you to setup a livestream using any custom rtmp URL. To make things more convenient, I've also integrated it with YouTube, so that you can create YouTube livestream directly from the app. I'll work on doing the same for VK — I myself use Facebook as little as possible, so I won't do the app for it (but if you have time to spare and want to contribute a patch, I won't refuse it!).

A demo video is also available.