sunweaver's NET

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).

Today, Fre(i)e Software GmbH has been contracted for packaging Kurento Media Server for Debian. This packaging project will be funded by GUUG e.V. (the German Unix User Group e.V.). A big thanks to the people from GUUG e.V. for making this packaging project possible.

About Kurento Media Server

Kurento is an open source software project providing a platform suitable for creating modular applications with advanced real-time communication capabilities. For knowing more about Kurento, please visit the Kurento project website: https://www.kurento.org.

Kurento is part of FIWARE. For further information on the relationship of FIWARE and Kurento check the Kurento FIWARE Catalog Entry. Kurento is also part of the NUBOMEDIA research initiative.

Kurento Media Server is a WebRTC-compatible server that processes audio and video streams, doing composable pipeline-based processing of media.

About BigBlueButton

As some of you may know, Kurento Media Server is one of the core components of the BigBlueButton software, an ,,Open Source Virtual Classroom Software''.

The context of the KMS funding is - after several other steps - getting the complete software component stack of BigBlueButton (aka BBB) into Debian some day, so that we can provide BBB as native Debian packages. On Debian.

Recently, I bought an Acer Spin 3 Convertible Notebook for the company and provided it to Robert Tari for his daily work on Ayatana Indicators (which currently is funded by the UBports Foundation via my company Fre(i)e Software GmbH).

Some days ago Robert reported back about a sleepless night he spent with that machine... He got stuck with a tricky issue regarding the installation of Manjaro GNU/Linux on that machine, that could be -- at the end -- resolved by a not so well documented trick.

Before anyone else spends another sleepless night on this, we thought we'd better share Robert's solution.

So, the below applies to the Acer Spin 3 series (and probably to other Spin models, perhaps even some other Acer laptops):

Acer Spin 3 Pre-Inst Cheat Codes

Before you even plug in the USB install media:

1. Go to UEFI settings (i.e. BIOS for us elderly people) [F2]
2. Security -> Set Supervisor Password [Enabled]
3. Enter the password you'll use
4. Boot -> Secure Boot -> [Disabled] (you can't disable it without a set supervisor password)
5. Exit -> Exit Saving Changes
6. Restart and go to UEFI settings again [F2]
7. Main -> [Now press CTRL + S] -> VMD Controller -> [Disabled]
8. Exit -> Exit Saving Changes
9. Now plug in the install USB and restart

Esp. the disabling of the VMD Controller is essential.

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.

This is a very short notice that I am not available via Freenode anymore. You can now reach me and the projects I am involved in (#x2go, #arctica, #ayatana-indicators) via the libera.chat IRC network.

Of course, I am also available and hanging out on OFTC IRC for all Debian related topics.

For details on the reasoning, I noticed that I am fully aligned with Antoine Beaupré's statements in his recent blog post on the same matter [1]. A recommended read.

light+love
Mike

[1] https://anarc.at/blog/2021-05-24-leaving-freenode/