Yesterday, the UBports core developer team released Ubuntu Touch Focal OTA-1
(In fact, Raoul, Marius and I were in a conference call when Marius froze and said: the PR team already posted the release blog post; the post is out, but we haven't released yet... ahhhh... panic... Shall I?, Marius said, and we said: GO!!! This is why the release occurred in public five hours ahead of schedule. OMG.)
For all the details, please study:
https://ubports.com/blog/ubports-news-1/post/ubuntu-touch-ota-1-focal-re...
Credits
Thanks to all the developers, other contributors and funding providers that helped to reach this massive milestone.
Prologue
For over a year now, Fre(i)e Software GmbH (my company) is involved in Ubuntu Touch development. The development effort currently is handled by a mix of paid and voluntary developers/contributors under the umbrella of the UBports Foundation. We are approaching the official first release of Ubuntu Touch 20.04 with rapid pace.
And, if you are a non-Englisch native speaker, we'd like to ask you for help... Read below.
light+love
Mike (aka sunweaver at debian.org, Mastodon, IRC, etc.)
Internationalization (i18n) of Ubuntu Touch 20.04
The UBports team has moved most of the translation workflows for localizing Ubuntu Touch over to Hosted Weblate:
To contribute to the UBports projects you need to register here:
The localization platform of all UBports / Lomiri components is sponsored by Hosted Weblate via their free hosting plan for Libre and Open Source Projects. Many thanks for providing this service.
Translating Lomiri
The translation components in the Lomiri project have already been set up and are ready for being updated by translators.
What is Ubuntu Touch? (And what does sunweaver have to do with it?)
With Ubuntu Touch, the UBports Foundation offers a truly unique mobile experience - a viable alternative to Android and iOS. The UBports community provides a free and open-source GNU/Linux-based mobile operating system. One that can be installed and used today.
Currently, there is an intensive effort going on lifting Ubuntu Touch from its current Ubuntu 16.04 base up to an Ubuntu 20.04 base. (And very soon after that to an Ubuntu 22.04 base...).
With the Ubuntu Touch 20.04 base the progress bar is already at (I'd say) 89%, but we recently got hit by a drawback.
I am currently involved in the Ubuntu Touch core development team at UBports and on medium short notice our current ARM64 server sponsor has announced to decommission our ARM64 build server that currently powers all the ARM64 and armhf CI builds.
Call for Hardware Sponsoring
So, the UBports core development team is currently desperately looking for a sponsor (or a few sponsors) who can provide us with (datacenter-hosted) ARM-based CPU power. It is important, that also 32-bit ARM builds are possible with the hardware provided.
For testing, I recently ordered a HoneyComb LX2 (by SolidRun) as a possible solution (multi-node in the end), but the board arrived in a non-usable state, it seems. So this also didn't work out as easy as expected.
As the former provider/sponsor is about to pull the plug, this call for help is kind of urgent.
Please get in touch if you can help us out or know people who can.
Thanks!!!
For those, who haven't realized, yet: MATE 1.26 has now been uploaded to Debian and should be available in Debian testing to all happy testers.
During December, me and the whole family, we had been infected with Covid-19. All of us have recovered well, by now. In fact, I was very happy about a proper fever which I haven't had in years. (Fever is a well-known form of cancer prevention / prophylaxis). Drinking a lot (of warm water!), not eating for five days, and additionally following some health practices from the natural healing context supported the recovery process really well.
The MATE 1.26 DEB package preparations had been done while sitting in bed with my hot water bottle in the back and a pot of honeyed thyme tea next to me on the window sill. Things were getting too boring while being sick, so the monotonous wrapping up of +/- 40 desktop environment DEB packages was a welcome change then (and not too complex for the reduced brain activity of mine, either).
Hope, that MATE 1.26 in Debian works well for many Debian users. I also plan to bring MATE 1.26 to bullseye-backports soon (second half of January, probably).
light+love
Mike (aka sunweaver at debian.org)
More as a reminder to myself, but possibly also helpful to other people who want to use Firefox on a tablet running Debian...
Without the below adjustment, finger gestures in Firefox running on a tablet result in image moving, text highlighting, etc. (operations related to copy+paste). Not the intuitively expected behaviour...
If you use e.g. GNOME on Wayland for your tablet and want to enable touch functionalities in Firefox, then switch the whole browser to native Wayland rendering. This line in ~/.profile seems to help:
export MOZ_ENABLE_WAYLAND=1
If you use a desktop environment running on top of X.Org, then make sure you have added the following line to ~/.profile:
export MOZ_USE_XINPUT2=1
Logout/login again and Firefox should be scrollable with 2-finger movements up and down, zooming in and out also works then.
light+love
Mike (aka sunweaver at debian.org)
An interesting mindset overcome by reality...
Also, lintian does not differentiate between between 100.000 and 1.000.000.
W: ayatana-indicator-display: improbable-bug-number-in-closes 1000143
N:
N: The most recent changelog closes a low-numbered bug number. While this is distantly possible, it's more likely a typo or
N: a placeholder value that mistakenly wasn't filled in.
N:
N: Visibility: warning
N: Show-Always: no
N: Check: debian/changelog
N:
N:
¯\_(ツ)_/¯
light+love
Mike
We (Robert Tari, the UBports developers team, myself) are very close to releasing Ayatana Indicators 0.9.x. The work on Ayatana Indicators is currently nearly completed funded by the UBports Foundation and over the past half year, many many changes, improvements and clean-ups have been added to the code.
Ayatana Indicators 0.9.x will be the first release series to be in the development tree of Ubuntu Touch 20.04 (which is currently under very heavy development).
Ayatana Indicators 0.9.x will also be used in various other desktop environments available in upcoming Ubuntu 22.04 LTS, such as Ubuntu MATE, Xubuntu, (optionally in) Ubuntu Budgie (please correct my wording, if you know better), (send me a note, if I forgot your desktop env), etc.
So, to all Ubuntu Touch, Ubuntu MATE, Xubuntu, etc. users. If you not already are a translator of Ayatana Indicators and you are good in English and fluent in at least one other language, please consider helping out with translating or improving translations of Ayatana Indicators.
The translation work needs to be done on Hosted Weblate [1], please sign up for an account (if you haven't done so, yet) and chime in.
Thanks so much for your contributions!
light+love
Mike
https://hosted.weblate.org/projects/ayatana-indicators/
In this blog post, I will cover a few related but also different topics around X2Go - the GNU/Linux based remote computing framework.
Introduction and Catch Up
For those, who haven't come across X2Go, so far... With X2Go [0] you can log into remote GNU/Linux machines graphically and launch headless desktop environments, seamless/published applications or access an already running desktop session (on a local Xserver or running as a headless X2Go desktop session) via X2Go's session shadowing / mirroring feature.
Graphical backend: NXv3
For several years, there was only one graphical backend available in X2Go, the NXv3 software. In NXv3, you have a headless or nested (it can do both) Xserver that has some remote magic built-in and is able to transfer the Xserver's graphical data to a remote client (NX proxy). Over the wire, the NX protocol allows for data compression (JPEG, PNG, etc.) and combines it with bitmap caching, so that the overall result is a fast and responsive desktop experience even on low latency and low bandwidth connections. This especially applies to X desktop environments that use many native X protocol operations for drawing windows and widget onto the screen. The more bitmaps involved (e.g. in applications with client-side rendering of window controls and such), the worse the quality of a session experience.
The current main maintainer of NVv3 (aka nx-libs [1]) is Ulrich Sibiller.
For a customer project, I recently needed to take a closer look at best strategies of deploying Chromium settings to thrillions of client machines in a corporate network.
Unfortunately, the information on how to deploy site-wide Chromium
browser policies are a little scattered over the internet and the
intertwining of Chromium preferences and Chromium policies required
deeper introspection.
Here, I'd like to provide the result of that research, namely a list of references
that has been studied before setting up Chromium policies for the customer's proof-of-concept.
Difference between Preferences and Policies
Chromium can be controlled via preferences (mainly user preferences) and
administratively rolled-out policy files.
The difference between preferences and policies are explained here:
https://www.chromium.org/administrators/configuring-other-preferences
The site-admin (or distro package maintainer) can pre-configure the
user's Chromium experience via a master preferences file
(/etc/chromium/master_preferences). This master preferences file is
the template for the user's preferences file and gets copied over into
the Chromium user profile folder on first browser start.
Note: By studying the recent Chromium code it was found out that
/etc/chromium/master_preferences is the legacy filename of the initial
preferences file. The new filename is
/etc/chromium/initial_preferences. We will continue with
master_preferences here as most Linux distributions still provide the
initial preferences via this file.
Over the past days, I have received tons of positive feedback on my previous blog post about forming the Debian BBB Packaging Team [1]. Feedback arrived via mail, IRC, [matrix] and Mastodon. Awesome. Thanks for sharing your thoughts, folks...
Therefore, here comes a short ...
Heads-Up on the current Ongoings
... around packaging BigBlueButton for Debian:
- While looking at Kurento Media Server, we stumbled over forked portions of code that are not uploadable to Debian as is (kmsjsoncpp, kms-gstreamer). These components would contain old and unmaintained, but also KMS-patched copies of code. Uploading those would violate Debian policy (which in short forbids code duplications in the archive). We are in touch with Kurento upstream and they have removing these forked projects on their development roadmap, although it is unclear when this might be ready for productive use.
- At the same time, we read BBB developer posts that suggested Janus WebRTC as a possible alternative to Kurento Media Server. As our main directive is getting BigBlueButton into Debian, we might drop the Kurento packaging initiative and spend resources on other components (as Janus WebRTC, thanks to Jonas Smedegaard, already is in Debian).
- The coming week (what a great coincidence), BigBlueButton World 2021 [2] will be held online and the schedule promises a lot of interesting talks and speakers. If interested, join up for free registration. Amongst others, Paulo Lanzarin will be speaking about "BigBlueButton’s Media Stack: Overview and the Road Ahead" (12:30 EST(!), June 23rd).
|