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.

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.

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 server

This 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: 80

In 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           19m

Why 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.15

For 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:

• fresh-container
• fresh-container-operator

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.

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.

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

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.

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

Dear Tumbleweed users and hackers,

At SUSE we had so-called hackweek. Meaning everybody could do something out of their regular tasks and work for a week on something else they wish to invest time on. I used the time to finally get the ‘osc collab’ server back in shape (Migrated from SLE11SP4 to Leap 15.1) – And in turn handed ‘The Tumbleweed Release Manager hat’ over to Oliver Kurz, who expressed an interest in learning about the release Process for Tumbleweed. I think it was an interesting experiment for both of us: for him, to get something different done and for me to get some interesting questions as to why things are the way they are. Obviously, a fresh look from the outside gives some interesting questions and a few things translated in code changes on the tools in use (nothing major, but I’m sure discussions will go on)

As I stepped mostly back this week and handed RM tasks over to Oliver, that also means he will be posting the ‘Review of the week’ to the opensuse­factory mailing list. For my fellow blog users, I will include it here directly for your reference.

What was happening this week and included in the published snapshots:

* KDE Applications 19.12.2
* KDE Plasma 5.18
* Linux Kernel 5.5.1 (which as some times in before posed a problem for owners 
of NVIDIA cards running proprietary drivers when Tumbleweed is too fast and 
drivers are not yet provided by NVIDIA in time for the new kernel version)²

What is still ongoing or in the process in stagings:

* Python 3.8 (salt, still brewing but progressing)
* Removal of python 2 (in multiple packages)
* glibc 2.31 (good progress but not done)
* GNU make 4.3
* libcap 2.30: breaks fakeroot and drpm
* RPM: change of the database format to ndb
* MicroOS Desktop³

Have fun,
Oliver

Planning for the openSUSE + LibreOffice Conference has begun and members of the open-source communities can now register for the conference. The Call for Papers is open and people can submit their talks until July 21.

The following tracks can be selected when submitting talks related to openSUSE:

1. a) openSUSE

2. b) Open Source

3. c) Cloud and Containers

4. d) Embedded.

The following tracks can be selected when submitting talks related to LibreOffice:

1. a) Development, APIs, Extensions, Future Technology

2. b) Quality Assurance

3. c) Localization, Documentation and Native Language Projects

4. d) Appealing Libreoffice: Ease of Use, Design and Accessibility

5. e) Open Document Format, Document Liberation and Interoperability

6. f) Advocating, Promoting, Marketing LibreOffice

Talks can range from easy to difficult and there are 15 minute, 30 minute and 45 minute slots available. Workshops and workgroup sessions are also available and are planned to take place on the first day of the conference.

Both openSUSE and LibreOffice are combining their conferences (openSUSE Conference and LibOcon) in 2020 to celebrate LibreOffice’s 10-year anniversary and openSUSE’s 15-year anniversary. The conference will take place in Nuremberg, Germany, at the Z-Bau from Oct. 13 to 16.

How to submit a proposal

Please submit your proposal to the following website: https://events.opensuse.org/conferences/oSLO

•     Create an account if you don’t already have one.

•     Your proposal must be written in English and be no longer than 500 words.

•     Please run spell and grammar checkers for your proposal before submission.

  • https://extensions.libreoffice.org/extensions/languagetool

  • https://www.grammarly.com/

•     Your biography on your profile page is also a reviewed document. Please do not forget to write your background.

•     You must obey openSUSE Conference code of conduct: https://en.opensuse.org/openSUSE:Conference_code_of_conduct

•     It is recommended that you use the slide deck of what ever organization you choose to represent. The openSUSE slide decks are located at https://github.com/openSUSE/artwork/tree/master/slides and the LibreOffice slide deck is located at https://extensions.libreoffice.org/templates/libreoffice-presentation-templates

Guide to write your proposal

Please write your proposal so that it is related to one or more topics. For example, if your talk is on security or desktop, it is better that it contains how to install that applications or demo on openSUSE. Please clarify what the participants will learn from your talk.

•     The introduction of main technology or software in your talk

•     The main topic of your talk

Only workshop: please write how to use your time and what you need.

•     We recommend writing a simple timetable on your proposal

•     Please write the necessary equipment (laptops, internet access) to the Requirement field

Travel Support

The speakers are eligible to receive sponsorship from either the openSUSE Travel Support Program (TSP) or the LibreOffice’s Travel Policy process. Those who wish to use travel support should request the support well in advance. The last possible date to submit a request from openSUSE’s TSP is Sept. 1.

• Please refer to the following URL for how to apply for travel support:     https://en.opensuse.org/openSUSE:Travel_Support_Program

Visa

For citizens who are not a citizen of a Schengen country in Europe, you may need a formal invitation letter that fully explains the nature of your visit. An overview of visa requirements/exemptions for entry into the Federal Republic of Germany can be found at the Federal Foreign Office website. If you fall into one of the categories requiring an invitation letter, please email ddemaio (@) opensuse.org with the email subject “openSUSE + LibreOffice Conference Visa”.

Other requirements for a visa state you must:

•     Have a valid passport

•     Have enough money for each day of their stay)

•     Be able to demonstrate the purpose of your stay to border officials

•     Pose no threat to public order, national security or international relations