Blogs
Recently, Raphael Hertzog published ideas [1] about how to make Debian more attractive for big enterprises. One missing key stone here is the possibility to sign up for an enterprise support subscription scheme. Another question tackles how to provide such a support scheme within Debian, without disturbing the current flow of how Debian is developed these days.
And, there are likely more questions to asks, riddles to solve, and hurdles to overcome.
We want to discuss this topic, brainstorm on it, collect new ideas and also hear your concerns on a public channel. Over the past weeks there already have been mail exchanges off-list.
We want to reboot this privately started discussion now in public (as that's where it belongs) starting +/- at the end of the coming week via the currently quite inactive Debian mailing list 'debian-enterprise' [2]. Please join the discussion (and the mailing list) [3] if interested in this topic.
light & love
Mike (aka sunweaver)
[1] https://raphaelhertzog.com/2021/03/30/challenging-times-for-freexian-1/
(also read parts 2-4)
[2] debian-enterprise@lists.debian.org
[3] https://lists.debian.org/debian-enterprise
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. Since 27th Feb 2020, Unity8 has now become Lomiri.
Things got delayed a little recently as my main developer contact on the upstream side was on sick leave for a while. Fortunately, he has now fully recovered and work is getting back on track.
Last week I received the official notice: There is now a German company named "Fre(i)e Software GmbH" registered with the German Trade Register.
Founding a New Company
Over the past months I have put my energy into founding a new company. As a freelancing IT consultant I started facing the limitation of other companies having strict policies that forbid the cooperation with one person businesses (Personengesellschaften).
Thus, the requirement for setting up a GmbH business came onto my agenda. I will move some of my business activities into this new company, starting next year.
Policy Ideas
The "Fre(i)e Software GmbH" will be a platform to facilitate the growth and spreading of Free Software on this planet.
Here are some first ideas for company policies:
The idea is to bring together teams of developers and consultants that provide the highest expertise in FLOSS. Everything this company will do, will finally (or already during the development cycles) be published under some sorf of a free software / content license (for software, ideally a copyleft license). Staff members will work and live across Europe, freelancers may possibly live in any country where German businesses may do business with. Ideally, staff members and freelancers work on projects that they can identify themselves with, projects that they love. Software development and software design is an art. In the company we will honour this.
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. Since 27th Feb 2020, Unity8 has now become Lomiri.
Recent Uploads to Debian related to Lomiri
Over the past 4 months I worked on the following bits and pieces regarding Lomiri in Debian:
- Work on lomiri-app-launch (Debian packaging, upstream work, upload to Debian)
- Fork lomiri-url-dispatcher from url-dispatcher (upstream work)
- Upload lomiri-url-dispatcher to Debian
- Fork out suru-icon-theme and make it its own upstream project
- Package and upload suru-icon-theme to Debian
- First glance at lomiri-ui-toolkit (currently FTBFS, needs to be revisited)
- Update of Mir (1.7.0 -> 1.8.0) in Debian
- Fix net-cpp FTBFS in Debian
- Fix FTBFS in gsettings-qt.
- Fix FTBFS in mir (support of binary-only and arch-indep-only builds)
- Coordinate with Marius Gripsgard and Robert Tari on shift over from Ubuntu Indicator to Ayatana Indicators
- Upload ayatana-indicator-* (and libraries) to Debian (new upstream releases)
- Package and upload to Debian: qmenumodel (still in Debian's NEW queue)
- Package and upload to Debian: ayatana-indicator-sound
- Symbol-Updates (various packages) for non-standard architectures
- Fix FTBFS of qtpim-opensource-src in Debian since Qt5.14 had landed in unstable
- Fix FTBFS on non-standard architectures of qtsystems, qtpim and qtfeedback
- Fix wlcs in Debian (for non-standard architectures), more Symbol-Updates (esp.
In August 2020, I have worked on the Debian LTS project for 16 hours (of 8 hours planned, plus another 8 hours that I carried over from July).
For ELTS, I have worked for another 8 hours (of 8 hours planned).
LTS Work
- LTS frontdesk: triage wireshark, yubico-piv-tool, trousers, software-properties, qt4-x11, qtbase-opensource-src, openexr, netty and netty-3.9
- upload to stretch-security: libvncserver 0.9.11+dfsg-1.3~deb9u5 (fixing 9 CVEs, DLA-2347-1 [1])
- upload to stretch-security: php-horde-core 2.27.6+debian1-2+deb9u1 (1 CVE, DLA-2348 [2])
- upload to stretch-security: php-horde 5.2.13+debian0-1+deb9u3 (fixing 1 CVE, DLA-2349-1 [3])
- upload to stretch-security: php-horde-kronolith 4.2.19-1+deb9u1 (fixing 1 CVE, DLA-2350-1 [4])
- upload to stretch-security: php-horde-kronolith 4.2.19-1+deb9u2 (fixing 1 more CVE, DLA-2351-1 [5])
- upload to stretch-security: php-horde-gollem 3.0.10-1+deb9u2 (fixing 1 CVE, DLA-2352-1 [6])
- upload to stretch-security: freerdp 1.1.0~git20140921.1.440916e+dfsg1-13+deb9u4 (fixing 14 CVEs, DLA-2356-1 [7])
- prepare salsa MRs for gnome-shell (for gnome-shell in stretch [8] and buster [9])
ELTS Work
- Look into open CVEs for Samba in Debian jessie ELTS.
In July 2020, I was originally assigned 8h of work on Debian LTS as a paid contributor, but holiday season overwhelmed me and I did not do any LTS work, at all.
The assigned hours from July I have taken with me into August 2020.
light+love,
Mike
At DebConf 17 in Montreal, I gave a talk about Ayatana Indicators [1] and the project's goal to continue the — by then already dropped out of maintenance — Ubuntu Indicators in a separate upstream project, detached from Ubuntu and its Ubuntu'isms.
Stalling
The whole Ayatana Indicators project received a bit of a show stopper by the fact that the IDO (Indicator Display Object) rendering was not working in vanilla GTK-3 without a certain patch [2] that only Ubuntu has in their GTK-3 package. Addressing GTK developers upstream some years back (after GTK 3.22 had already gone into long term maintenance mode) and asking for a late patch acceptance did not work out (as already assumed). Ayatana Indicators stalled at a level of 90% actually working fine, but those nice and shiny special widgets, like the calendar widget, the audio volume slider widgets, switch widgets, etc. could not be rendered appropriately in GTK based desktop environments (e.g. via MATE Indicator Applet) on other distros than Ubuntu.
I never really had the guts to sit down without a defined ending and find a patch / solution to this nasty problem. Ayatana Indicators stalled as a whole. I kept it alive and defended its code base against various GLib and what-not deprecations and kept it in Debian, but the software was actually partially broken / dysfunctional.
Taking the Dog for a Walk and then It Became all Light+Love
Several days back, I received a mail from Robert Tari [3]. I was outside on a hike with our dog and thought, ah well, let's check emails...
In June 2020, I have worked on the Debian LTS project for 8 hours (of 8 hours planned).
LTS Work
- frontdesk: CVE bug triaging for Debian jessie LTS: mailman, alpine, python3.4, redis, pound, pcre3, ngircd, mutt, lynis, libvncserver, cinder, bison, batik.
- upload to jessie-security: libvncserver (DLA-2264-1 [1], 9 CVEs)
- upload to jessie-security: mailman (DLA-2265-1 [2], 1 CVE)
- upload to jessie-security: mutt (DLA-2268-1 [3] and DLA-2268-2 [4]), 2 CVEs)
Other security related work for Debian
- make sure all security fixes for php-horde-* are also in Debian unstable
- upload freerdp2 2.1.2+dfsg-1 to unstable (9 CVEs)
References
In May 2020, I have worked on the Debian LTS project for 14.5 hours (of 14.5 hours planned).
LTS Work
- Frontdesk: CVE bug triaging for Debian jessie LTS: exim4, cups, log4net, apt, openconnect, libexif, json-c, tomcat8, and graphicsmagick.
- review and sponsor upload to jessie-security: libexif (DLA-2214-1 [1], 5 CVEs)
- review and sponsor upload to jessie-security: libexif (DLA-2222-1 [2], 4 CVEs)
- upload to jessie-security: json-c (DLA-2228-1 [3] and DLA-2228-2 [4], 1 CVE)
- upload to jessie-security: php-horde-gollem (DLA-2228-1 [5], 1 CVE)
- upload to jessie-security: php-horde (DLA-2280-1) [6], 1 CVE)
- start looking into the current FreeRDP (v1.1) and FreeRDP (v2) CVE hell...
Other security related work for Debian
- review and sponsor uploads of libexif to stretch, buster and unstable (8 CVE fixes for stretch, 5 CVE fixes for buster) [7]
- revisit long overdue uploads of ssvnc to stretch and buster (4 CVE fixes each) [8]
- upload php-horde-gollem to stretch and buster (1 CVE fix each) [9]
- upload php-horde to stretch and buster (1 CVE fix each) [10]
Credits
- Many thanks to Hugh McMaster for handling all the libexif security upload preparations himself. This was really good work.
TL;DR; For those (admins) of you who run GNU/Linux on staff computers: How do you organize your graphical remote support in your company? Get in touch, share your expertise and experiences.
Researching on FLOSS based Linux Desktops
When bringing GNU/Linux desktops to a generic folk of productive office users on a large scale, graphical remote support is a key feature when organizing helpdesk support teams' workflows.
In a research project that I am currently involved in, we investigate the different available remote support technologies (VNC screen mirroring, ScreenCasts, etc.) and the available frameworks that allow one to provide a remote support infrastructure 100% on-premise.
In this research project we intend to find FLOSS solutions for everything required for providing a large scale GNU/Linux desktop to end users, but we likely will have to recommend non-free solutions, if a FLOSS approach is not available for certain demands. Depending on the resulting costs, bringing forth a new software solution instead of dumping big money in subscription contracts for non-free software is seen as a possible alternative.
As a member of the X2Go upstream team and maintainer of several remote desktop related tools and frameworks in Debian, I'd consider myself as sort of in-the-topic. The available (as FLOSS) underlying technologies for plumbing a remote support framework are pretty much clear (x11vnc, recent pipewire-related approaches in Wayland compositors, browser-based screencasting).
|