openSUSE Tumbleweed – Review of the week 2020/09
Dear Tumbleweed users and hackers,
During this week we released 4 snapshots (0220, 0222, 0224 and 0226) – an average week from that perspective, yet there have been some interesting and well-awaited updates in these snapshots:
- zsh 5.8
- Mesa 19.3.4 & Mesa 20.0
- libcap 2.32
- GNOME 3.34.4
- KDE Plasma 5.18.1
- LLVM 6 has been removed from the repository
- ncurses 6.2
- Linux kernel 5.5.5
- Mozilla Firefox 73.0.1: it will now launch in Wayland mode inside a Wayland session
- MariaDB 10.4.12
Despite all those things happenings, stagings are still – or again – filled up:
- Zypper 1.14.34: beware! This version no longer supports abbreviated command line parameters (e.g
zypper in --no-ris no longer accepted) - KDE Plasma 5.18.2
- Qt 5.15.0 (currently betas being tested)
- Ruby 2.7 – possibly paired with the removal of Ruby 2.6
- GCC 10
- Python 3.8 (unchanged, awaiting the fix for salt)
- Removal of Python 2
- GNU Make 4.3
- RPM: change of database format to ndb
Citrix Workspace on openSUSE Tumbleweed
Please find a 2021 update below and furtherdown a comment from 2024!
Some companies offer their employees to access their corporate computer work space remotely using a remote desktop connection. The company Citrix provides software for such a connection. To connect, the employees need the software Citrix Workspace on their terminal devices. The company provides on their download page also files for Linux including openSUSE. Unfortunately, their version 1912 from 12 December 2019 did not just work on my openSUSE Tumbleweed 64bit computer (and earlier versions I tried neither).
Segmentation Fault and Missing Libraries
First, I tried to install the software package from the vendor.
- I downloaded the SuSE Full Package (Self-Service Support) Citrix Workspace app for Linux (x86_64) in version 1912 from 12 December 2019.
zypper in ICAClient-suse-19.12.0.19-0.x86_64.rpm- I logged into a corporate page, open a connection configuration file (*.ica) and nothing happened. So I assumed the application may have crashed. I downloaded the file and opened it in the terminal to see more.
/usr/lib64/ICAClient/wfica -icaroot /opt/Citrix/ICAClient configuration-file.ica- The app opened shortly and crashed then with the error message
segmentation fault (core dumped)
Then, I tried to install somebody’s own software package. Note that this requires trust or a review of the package.
- I downloaded the ICAClient from https://download.opensuse.org/repositories/home:/enzokiel/openSUSE_15.2_Update/x86_64/ for openSUSE 15.2 Update x86_64 (hence, not Tumbleweed).
- I installed the package despite the missing library
libcrypto.so.1.0.0. - I found the missing library openssl 1.0.0 and installed it.
Afterwards, the application did not segfault any longer. However, it produced an error due to a missing certificate from the GlobalSign Root CA.
- So I went to Firefox, went to the Privacy and Security tab in the Preferences, and clicked on “View Certificates”.
- I exported the GlobalSign Root CA certificate to e.g.
/tmp. There is more than one. Look for the one in the tree GlobalSign nv-sa. - Then, the certificate needs to be put into the certificate folder of Citrix Workspace. For the sofware package I use, this is
/usr/lib64/ICAClient/keystore/cacerts. Navigate in the terminal to this folder and copy the certificate file in it. Then usechown root:root [file.crt]andchmod 444 [file.crt]to adapt file ownership and properties.
Afterwards, Citrix Workspace worked for me. If I have too much time, I will try to use the vendor package and see if I still get the segfault considering that I have now openssl 1.0.0 installed.
Exchanging Data between Citrix Host and Citrix Client
There are two options to get data from your host OS to your Citrix client:
- Clipboard: Copy’n’paste of text from the host to the client is suppoted on Linux. It did not work for me with files.
- Mapping client devices: folders from the host can be mapped in the client as distinct drives. This is very useful to exchange files between host and client. To configure this option, launch from the startmenu “Citrix Receiver (configmgr)”. Alternatively, the tool can be launched from the command line with
/usr/lib64/ICAClient/util/configmgr -icaroot /usr/lib64/ICAClient. In the tool, mappings are configured in the tab file access.
Update 2021
At some point, the setup broke due to an expiring SSL certificate I believe. After some time trying, I ended up with the following easy setup:
- deinstall the outdated version:
zypper rm ICAClient - go to https://www.citrix.com/downloads/workspace-app/linux/workspace-app-for-linux-latest.html and downoad the rpm. In my case it was
ICAClient-suse-21.1.0.14-0.x86_64.rpm - install the rpm with e.g.
zypper install [your folder]/ICAClient-suse-21.1.0.14-0.x86_64.rpm - try to open a file. In my case, I got a “SSL error 61” (see Citrix help)
- I renamed the Citrix cacert storage:
mv /opt/Citrix/ICAClient/keystore/cacerts{,~} - I linked in the system storage:
ln -sv /etc/ssl/certs /opt/Citrix/ICAClient/keystore/cacerts
This did the trick!
References
- https://kenfallon.com/citrix-ssl-error-61-globalsign-root-ca/ with a tip on how to install the missing certificate
- https://docs.citrix.com/en-us/receiver/windows/current-release/optimize/map-client-devices.html with explanations on device mapping for Windows
DRM Plugin crashes after openSUSE Tumbleweed update
A few days ago openSUSE users started complaining about DRM Plugin crashes in Firefox after running a Tumbleweed update.

Netflix requires the DRM plugin in Firefox to be able to play encrypted videos. The plugin would crash due to a bug in Firefox 73. While this bug affected not just openSUSE users, but everyone using Firefox 73, it became apparent to TW users as v73 landed in the Tumbleweed repo.
Mozilla fixed the bug in the 73.0.1 release. I tweeted about that a little more than a week ago.
Yo Mozillians! #Firefox 73.0.1 has been released. Fixes crashes on Windows & Linux.https://t.co/UZsfGf2MgT
— Ish Sookun (@IshSookun) February 18, 2020
Firefox 73.0.01 is now available in the Tumbleweed repo. So, a quick update should fix your Netflix. 😉
Information for package MozillaFirefox:
---------------------------------------
Repository : openSUSE-Tumbleweed-Oss
Name : MozillaFirefox
Version : 73.0.1-1.1
Arch : x86_64
Vendor : openSUSE
Installed Size : 186.7 MiB
Installed : Yes
Status : out-of-date (version 73.0-1.1 installed)
Source package : MozillaFirefox-73.0.1-1.1.src
Summary : Mozilla Firefox Web Browser
Description :
Mozilla Firefox is a standalone web browser, designed for standards
compliance and performance. Its functionality can be enhanced via a
plethora of extensions.
Semantic versioning and containers
Developers are used to express the dependencies of their programs using semantic versioning constraints.
For example a Node.js application relying on left-pad could force only certain
versions of this library to be used by specifying a constraint like
>= 1.1.0 < 1.2.0. This would force npm to install the latest version of the
library that satisfies the constraint.
How does that translates to containers?
Imagine the following scenario: a developer deploys a containerized application
that requires a Redi database. The developer deploys the latest version
of the redis container (eg: redis:4.0.5), ensures his application works fine
and then moves to do other things.
After some weeks a security issue/bug is found inside of Redis and a new patched release takes place. Suddenly the deployed container is outdated. How can the developer be aware a new v4 release of Redis is available? Wouldn’t be even better to have some automated tool taking care of this upgrade?
After some more weeks a new minor release of Redis is released (eg: 4.1.0).
Is it safe to automatically update to a new minor release of Redis, is the
developer application going to work as expected?
Some container images have special tags like v4 or v4.1 and the developer
could just leverage them to kinda pinpoint the redis container to a more
delimited set of versions. However using these tags reduces reproducibility
and debuggability.
Let’s imagine the redis image being deployed is redis:v4.1 and everything is
working as expected. Assume after some time the developer (or some automated tool)
pulls a new version of the redis:v4.1 image and suddenly the application
has some issues. How can the developer understand what really changed?
Wouldn’t it be great to be able to say something like “everything worked fine
with redis:4.1.0 but it broke when I upgraded to redis:4.1.9”?
There are some tools that can be used to find and automatically update old container images: Watchtower and ouroboros. However none of them allows the flexibility I was looking for (in terms of checks), plus they are both tailored to work only against docker.
Because of that, during the 2020 edition of SUSE Hackweek, I spent some time working on a different solution to this use case.
Introducing fresh-container
fresh-container is a tool that can be used to see if a container can be updated to a more recent release.
fresh-container is different compared to Watchtower and ouroboros because it relies on semantic versioning to process container image tags.
Semantic versioning is used to express the version constraints a container version must satisfy. This gives more flexibility, for example take a look at the following scenarios:
- I’m fine with any release of Redis that is part of the v4 code stream:
>= 4.0.0 < 5.0.0 - I’m fine only with patch releases of Redis that belong to the 4.1 code stream:
>= 4.1.0 < 4.2.0 - I’m don’t want any release of Redis after v6:
< 6.0.0
CLI mode
fresh-container can be run as a standalone program:
$ fresh-container check --constraint ">= 1.9.0 < 1.10.0" nginx:1.9.0
The 'docker.io/library/nginx' container image can be upgraded from the '1.9.0' tag to the '1.9.15' one and still satisfy the '>= 1.9.0 < 1.10.0' constraint.Behind the scenes fresh-container will query the container registry hosting the image to gather the list of all the available tags. The tags that do not respect semantic versioning will be ignored and finally the tool will evaluate the constraint provided by the user.
It can also generate computer parsable output by producing a JSON response:
$ fresh-container check -o json --constraint ">= 1.9.0 < 1.10.0" nginx:1.9.0
{
"image": "docker.io/library/nginx",
"constraint": ">= 1.9.0 < 1.10.0",
"current_version": "1.9.0",
"next_version": "1.9.15",
"stale": true
}Server mode
Querying the remote container registries to fetch all the available tags of a container image is an expensive operation. That gets even worse when multiple containers have to be inspected on a regular basis.
The fresh-container binary can operate in a server mode to alleviate this issue:
$ fresh-container serverThis will start a web server offering a simple REST API that can be used to perform queries. The remote tags of the container images are cached inside of an in-memory database to speed up constraint resolution.
It’s possible to run fresh-container check against a fresh-container server
to perform faster queries by using the --server <http://fresh-container-server>
flag.
Kubernetes integration
fresh-container is a tool built to serve one specific use case: your provide some data as input and, as output, it will tell you if the container image can be updated to a more recent version.
It’s main goal is to be leveraged by other tools to build something bigger like fresh-container-operator.
This is a kubernetes operator that, once deployed inside of a kubernetes cluster, will look at all the kubernetes deployments running inside of it and finds the ones having stale containers.
The operator can also automatically update these outdated deployments to use the latest version of the container images that satisfy their requirements.
Usage
How does it work? First of all you have to enrich your deployment definition by adding some ad-hoc annotations.
For each container image used by the deployment you have to specify the semantic versioning constraint that has to be used to evaluate their “freshness”.
Take a look at the following example:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
annotations:
fresh-container.autopilot: "false"
spec:
selector:
matchLabels:
app: nginx
replicas: 1
template:
metadata:
labels:
app: nginx
annotations:
fresh-container.constraint/nginx: ">= 1.9.0 < 1.10.0"
spec:
containers:
- name: nginx
image: nginx:1.9.0
ports:
- containerPort: 80In this case the operator will look at the version of the nginx container
in use and evaluate it against the >= 1.9.0 < 1.10.0 constraint.
Note well: deployments that do not have any
fresh-container.constraint/<container name> will be ignored by the operator.
Find stale deployments
The operator adds the special label fresh-container.hasOutdatedContainers=true
to all the deployments that have one or more stale containers inside of them.
This allows quick searches against all the deployments:
$ kubectl get deployments --all-namespaces -l fresh-container.hasOutdatedContainers=true
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
default nginx-deployment 1/1 1 1 19mWhy is a deployment stale?
The details about the stale containers are added by the operator as annotations of the deployment:
kubectl describe deployments.apps nginx-deployment
Name: nginx-deployment
Namespace: default
CreationTimestamp: Thu, 27 Feb 2020 10:32:55 +0100
Labels: fresh-container.hasOutdatedContainers=true
Annotations: deployment.kubernetes.io/revision: 1
fresh-container.autopilot: false
fresh-container.lastChecked: 2020-02-27T09:45:07Z
fresh-container.nextTag/nginx: 1.9.15For each stale container the operator adds an annotation with
fresh-container.nextTag/<container name> as key and the tag of the most recent
container that satisfies the constraint as value.
In the example above you can see that the nginx container inside of the
deployment can be updated to the 1.9.15 tag while still satisfying the
>= 1.9.0 < 1.10.0 constraint.
Automatic upgrades
The next step is to allow fresh-container-operator to update all the deployments that have stale containers.
This is not done by default, but can be enable on a per-deployment basis
by adding the fresh-container.autopilot=true annotation inside of the
deployment metadata.
What comes next
As I stated in the beginning I created these projects during the 2020 edition of SUSE Hackweek. They are early prototypes that need more love.
I would be happy to hear what you think about them. Feel free to leave a comment below or open an issue on their GitHub projects:
Moving to the new News
In an effort to make contributing to openSUSE easier, openSUSE News has moved from being a Wordpress application to a Jekyll static site developed directly on Github. Now you too can write an article, or a series of articles, by sending pull requests to the openSUSE/news-o-o repository.
How to do it
The repository contains _posts directory, that’s where you will upload your own markdown formatted post, following the structure of other posts in the folder. Additionally, you can upload your images to assets/images directory, and reference them from the post.
After you pull request a post like that, the marketing team will review and, if needed, suggest improvements. A successfully reviewed post will be merged into the repository and published at the date specified by the post itself.
Leap 15.2 Enters Beta Builds Phase
openSUSE Leap 15.2 entered the Beta phase last week and has already released two snapshots with the release of build 581.2 and build 588.2. Leap has a rolling development model until it’s final build, so multiple builds will be released according to the road map until the gold master is released, which is scheduled for May 7.
There are no concrete milestones in the rolling development model. As bugs are fixed and new packages introduced or excluded, snapshots of the latest beta phase builds will be released once they pass openQA testing.
After the gold master is released, the rolling development model will stop and maintenance and security updates will then be released for the new minor version of the Leap 15 series.
The alpha phase has been ongoing for several months now and builds have been released regularly on a rolling basis. The alpha was stable enough to use for demos at FOSDEM, but testing is still needed.
Distro hoppers, hobbyists, users and tech enthusiast can download the current builds and help test the releases at software.opensuse.org/distributions/testing. People testing the beta are encouraged to
Record their Leap Beta testing effort on the following spreadsheet: https://docs.google.com/spreadsheets/d/1AGKijKpKiJCB616-bHVoNQuhWHpQLHPWCb3m1p6gXPc/edit#gid=801313279
Leap Beta testers have an option to receive a T-shirt, so make sure to fill in all the proper information and bug reports to get one.
In the email announcement notifying the community about Leap entering the beta phase, Leap’s new release manager, Luboš Kocman stated the release team is working on a 15.1 upgrade test suite to get decent upgrade test results.
“So any manual upgrade effort would be extremely valuable,” Luboš Kocman wrote.
Kocman also highlighted Windows Subsystem for Linux and said the hard work put in for WSL images has risen it to a first-class citizen in both the Open Build Service and openQA.
Those interested in Beta testing of openSUSE Leap 15.2 WSL images can contact Kocman or the factory mailing list. For more information on WSL, visit https://en.opensuse.org/openSUSE:WSL.
openSUSE Tumbleweed – Review of the week 2020/08
Dear Tumbleweed users and hackers,
After a week of hacking on different stuff and being in the background for Tumbleweed while Oliver took on the role of Release Manager, I am back with you. And we have released three snapshots this week (0214, 0218 and 0219). The gap between 0214 and 0218 was the integration of glibc 2.31. But of course, there was more happening this week. So here comes the list:
- glibc 2.31
- Mozilla Firefox 73.0
- KDE Frameworks 5.67.0
- Linux kernel 5.5.4
- PostgreSQL 12.2
- MicroOS Desktops are available as part of the MicroOS DVD installer
Things you can expect come to a snapshot in the (hopefully not too far) future:
- zsh 5.8 (Snapshot 0220+)
- libcap 2.30 (snapshot 0221+)
- GNOME 3.34.4
- llvm 6 will be removed from the repository
- Linux kernel 5.5.5
- KDE Plasma 5.18.1
- Ruby 2.7 – possibly paired with the removal of Ruby 2.6
- GCC 10
- Python 3.8 (unchanged, awaiting the fix for salt)
- Removal of Python 2
- GNU Make 4.3
- RPM: change of database format to ndb
Plasma, NodeJS, pip, Grep update in Tumbleweed
Three openSUSE Tumbleweed snapshots arrived this week and the snapshots provided a few major version upgrades and several minor updates with newer features.
The latest snapshot was 20200218. This snapshot updated a subpackage for btrfsprogs to version 5.4.1 and fixes the docbook5 builds. The Linux Kernel updated to 5.5.4 and had a few changes for KVM on arm64. The update of glibc 2.31 now supports a feature test macro [_ISOC2X_SOURCE](https://gitlab.com/freedesktop-sdk/mirrors/sourceware/glibc/-/commit/777d75fbc07b98115f4868c3290eb8a5d1f3a5b2) to enable features from the draft ISO C2X standard. Command line utility grep 3.4 fixed some performance bugs and adds a new –no-ignore-case option that causes grep to observe case distinctions, overriding any previous -i (–ignore-case) option. The DBus-activated daemon controlling mobile devices and connections, ModemManager fixed the handling of hexadecimal 0x00 bytes at the end of GSM encoded strings in version 1.12.6. There were several other packages updated in the snapshot. Among the packages to be updated were flatpak 1.6.2, GNOME’s web browser epiphany 3.34.4, email client mutt 1.13.4, strace 5.5, sudo 1.8.31 and whois 5.5.5. With less than a week to go until a rating is finalized, a rating of 92 was initially released for the snapshot, according to the snapshot reviewer.
Snapshot 20200214 updated both Mozilla Firefox and Thunderbird to versions 73.0 and 68.5 respectively. The new major version of the browser addressed six Common Vulnerabilities and Exposures (CVE) that included one bug fix that affected the memory. The new release includes new features that help users view and read website content more easily by enhancing the page zoom feature. The version also added NextDNS as an alternative option for DNS over HTTPS. The Thunderbird email client addressed seven CVEs and added support for client Identity IMAP/SMTP Service Extension and for OAuth 2.0 authentication for POP3 accounts. KDE users had multiple package updates from Plasma Framework 5.67.0; Kirigami removed the header top margin from private ScrollView and properly expanded the fillWidth items in mobile mode. The KTextEditor fixed the drag and copy function, and the framework’s package also fixed a crash in the variable expansion with the use of external tools. The package for the JavaScript runtime environment, nodejs12 updated to version 12.16.0 added a new core module for a WebAssebly System Interface as an experimental feature. The NodeJS version also added Hash.prototype.copy making it possible to clone an internal state of Hash object. Text editor nano 4.8 improved the handling of lock files on start-up. Two other major version updates in the snapshot were python-packaging 20.1 and python-pip 20.0.2; the new pip version switches to a dedicated command-line interface tool for vendoring dependencies and the changelog points out that the wheel cache is not retro-compatible with previous versions and that pip will continue to take advantage of existing legacy cache entries until pip 21.0 is released. Version control tool mercurial 5.3 fixed some bugs and added a new Large File Storage experimental feature. The utilities package for controlling TCP / IP networking and traffic control in Linux, iproute2, updated to version 5.5.0, which added four patches and a new timestamp format. Other packages that updated in the snapshot were babl 0.1.74, ccache 3.7.7 and gegl 0.4.20. The snapshot is currently trending moderately stable at a rating of 80, according to the Tumbleweed snapshot reviewer.
A little more than half a dozen packages were updated in snapshot 20200213. The interactive Python accessibility explorer package accerciser 3.34.4 updated translations and documented a new python-xlib dependency. The update elfutils 0.178 package fixed variable references in specfile and added a RISC-V disassembler. Windows Server 2019 support was added with the update of vm-install 0.10.08. The snapshot recorded a moderately stable rating of 75, according to the Tumbleweed snapshot reviewer.
The previous week’s 20200211 snapshot recorded a rating of 71 and brought KDE’s plasma5-desktop 5.18.0, which will be the version in openSUSE Leap 15.2 when it’s released. The new Plasma 5.18 Long Term Support (LTS) is even more user-friendly and filled with more features. The new Emoji Selector is just two keystrokes away. Hold down the Meta key and press the period (.) and it will pop up. The version also provides a new Night Color feature to relax users eyesight. KDE Applications was also updated in the snapshot. The 19.12.2 version update provided a big release of KDevelop 5.5, which is the Integrated Development Environment (IDE) that makes writing programs in C++, Python and PHP easier. . PHP gets PHP 7.4’s typed properties and support was added for array of type and class constant visibility. In Python, support was added for Python 3.8.
It is time for a war on tabs
We (as a UI shell project) see the limits of our territory as the window, when there is the assumption nowadays that MDI tabbed interfaces are where most significant user activity takes place. Yet interacting with different views/documents within those windows is not standardised, so the user has to remember which app they are using, then select the appropriate actions to:
- recognise the current tab
- switch tabs
- move tabs in the current window or between windows
- notice which tab is being switched to (different switcher UIs, not shown)
- open/close tabs
- be warned when closing a window with multiple tabs
- use keyboard shortcuts to switch tabs
- persist tabs between logins
- share sets of tabs between devices
I'm not saying Plasma needs to become a tabbed window manager, but we can do better, and it is definitely time to declare war on the mess above.
oSLO Conference 🐧
oSLO is short for openSUSE + LibreOffice.
The two projects are celebrating their 15ᵗʰ and 10ᵗʰ anniversary respectively in 2020. To mark the occasion, openSUSE and LibreOffice projects are organizing a joint conference from 13ᵗʰ to 16ᵗʰ October 2020 in Nuremberg, Germany. The conference will take place at Z-bau (Frankenstraße 200). It is the same location where last year's openSUSE Conference was held.
openSUSE and LibreOffice conferences are meant to bring like minded people together to discuss about topics relative to the projects. People can learn, teach and share their passion about the projects.
Last September, openSUSE announced a logo design competition for this co-conference with LibreOffice. Early this month the winner of the competition was announced. Kukuh Syafaat from Indonesia won the hearts of the co-conference organizing team.

The conference is free to attend. Mark you calendar & join the fun!
Call for Papers
The organizing team is currently accepting proposals for sessions. The deadline for submission is 21 July 2020.