Welcome to Planet openSUSE

This is a feed aggregator that collects what openSUSE contributors are writing in their respective blogs.

To have your blog added to this aggregator, please read the instructions.

18 April, 2019


Three quality openSUSE Tumbleweed snapshot were released since last Thursday with updated packages for Curl, Salt, FFmpeg and more.

Mozilla Firefox had a minor release of version 66.0.3 in the latest Tumbleweed 20190415 snapshot. The browser addressed some performance issues with some HTML5 games and provided a Baidu search plugin for Chinese users and China’s Internet space. The command-line tool for transferring data using various protocols, curl 7.64.1 fixed many bugs and added additional libraries to check for Lightweight Directory Access Protocol (LDAP) support. The update of libvirt 5.2.0 dropped a few patches and added several new features like Storage Pool Capabilities to get a more detailed list XML output for the virConnectGetStoragePoolCapabilites Application Programming Interface (API) and libvirt also enabled firmware autoselection for the open-source emulator QEMU. The newest salt 2019.2.0 package in Tumbleweed enhanced network automation and broadened support for a variety of network operating systems, and features for configuration manipulation or operational command execution. Salt also  added running playbooks to the 2019.2.0 release with the playbooks function and it includes an ansible playbooks state module, which can be used on a targeted host to run ansible playbooks, or used in an orchestration state runner. The snapshot was trending at a 95 rating at the time of publishing this article, according to the Tumbleweed snapshot reviewer.

Snapshot 20190412 was trending at a 94 and that package brought an update to Ceph that added a separate option to config a Secure Sockets Layer (SSL) port. The cifs-utils 6.9 package, which is part of the Samba Project, added fixes for Azure and removed several patches. The libssh2_org 1.8.2 package fixed a misapplied patch that broke its previous version. A few YaST packages had some updates like the yast2-storage-ng 4.2.5 package that allows for a new format for importing/exporting Network File System (NFS) drives.

The 20190411 snapshot started off the week and it posted a moderately stable rating of 89. This snapshot brought the 5.0.7 Linux Kernel and it offered up a mitigation potential for a ptrace system call for PowerPC. There were some bug fixes for codecs, filters and formats in the ffmpeg 4.1.3 update. The JavaScript Bindings for GNOME, gjs 1.56.0, had a significantly large changelog recording info from the previous 1.54.3 version that was in Tumbleweed. The previous logs identified a GNU Compiler Collection 9 bug and added some ESLint rules. The new version was a stable version bump. The python-kiwi  9.17.35 package fixed regressions for the kiwi-repart dracut module. The wget 1.20.3 package fixed the buffer overflow vulnerability found in Common Vulnerabilities and Exposures (CVE)-2019-5953. Text editor vim 8.1.1137 fixed several bugs including a Python test that didn’t wipe out hidden buffer and a space in number column that was on wrong side with ‘rightleft’ set.


The last Code & Coffee meetup I wrote about dates more than a year probably now. I admit I’ve become a lazy blogger. Yesterday, I attended the MSCC Code & Coffee meetup at Mugg & Bean. It reminded me of the good old days of being a frequent meetup attendee and all those geek talks that happened around those Mugg & Bean tables with long hours drinking coffee. JoKi and Mary Jane were already there along with little Liam when I arrived.

17 April, 2019


While there are some users who run syslog-ng as a stand-alone application, the main strength of syslog-ng is central log collection. In this case the central syslog-ng instance is called the server, while the instances sending log messages to the central server are called the clients. There is a (somewhat lesser known) third type of instance called the relay, too. The relay collects log messages via the network and forwards them to one or more remote destinations after processing (but without writing them onto the disk for storage).A relay can be used for many different use cases. We will discuss a few typical examples below.

Note that the syslog-ng application has an open source edition (OSE) and a premium edition (PE). Most of the information below applies to both editions. Some features are only available in syslog-ng PE and some scenarios need additional licenses when implemented using syslog-ng PE.

UDP-only source devices

Typically, most network devices send log messages over UDP only. Even though some of them support TCP-based logging, vendors recommend not to use it (as in many cases the TCP logging implementation is extremely buggy). UDP does not guarantee that all UDP packets will be delivered, so it is a weak point of the system. To ensure at least a best effort level of reliability, it is recommended to deploy a relay on the network, closeto these source devices. With the least possible (and, more importantly, the most reliable) hops between the source and the relay, the risk of losing UDP packets can be minimized. Once the packet arrives at the relay, we can ensure the messages are delivered to the central server in a reliable manner, based on TCP/TLS and ALTP (syslog-ng PE only: Advanced Log Transfer Protocol).

Too many source devices

Depending on the hardware and configuration, an average syslog-ng instance can usually handle the following number of concurrent connections:

1. If the maximum message rate is lower than 200,000 messages per second:

◦ maximum ca. 5,000 TCP connections

◦ maximum ca. 1,000 TLS connections

◦ maximum ca. 1,000 ALTP connections

2. If the message rate is higher than 200,000 messages per second, always contact One Identity.

As a result, if you have more source devices, it is required to deploy a relay machine at least per 5,000 sources and batch up all the logs into a single TCP connection that connects the relay to the server. If TLS or ALTP is used, relays should be deployed per 1,000 source devices.

Collecting logs from remote sites (especially over public WAN)

It is quite common that companies need to collect log messages from geographically remote sites (sometimes in global distance), and sometimes over public WAN. In this case it is recommended to install a relay nodeper each remote site at least. The relay can be the last outgoing hop for all the messages of the remote site, which has several benefits:

  • Maintenance: you only need to change the configuration of the

16 April, 2019


Traditionally, GObject implementations in C are mutable: you instantiate a GObject and then change its state via method calls. Sometimes this is expected and desired; a GtkCheckButton widget certainly can change its internal state from pressed to not pressed, for example.

Other times, objects are mutable while they are being "assembled" or "configured", and only yield a final immutable result until later. This is the case for RsvgHandle from librsvg.

Please bear with me while I write about the history of the RsvgHandle API and why it ended up with different ways of doing the same thing.

The traditional RsvgHandle API

The final purpose of an RsvgHandle is to represent an SVG document loaded in memory. Once it is loaded, the SVG document does not change, as librsvg does not support animation or creating/removing SVG elements; it is a static renderer.

However, before an RsvgHandle achieves its immutable state, it has to be loaded first. Loading can be done in two ways:

  • The historical/deprecated way, using the rsvg_handle_write() and rsvg_handle_close() APIs. Plenty of code in GNOME used this write/close idiom before GLib got a good abstraction for streams; you can see another example in GdkPixbufLoader. The idea is that applications do this:
file = open a file...;
handle = rsvg_handle_new ();

while (file has more data) {
   rsvg_handle_write(handle, a bit of data);

rsvg_handle_close (handle);

// now the handle is fully loaded and immutable

rsvg_handle_render (handle, ...);
file = g_file_new_for_path ("/foo/bar.svg");
stream = g_file_read (file, ...);
handle = rsvg_handle_new ();

rsvg_handle_read_stream_sync (handle, stream, ...);

// now the handle is fully loaded and immutable

rsvg_handle_render (handle, ...);

A bit of history

Let's consider a few of RsvgHandle's functions.


  • rsvg_handle_new()
  • rsvg_handle_new_with_flags()

Configure the handle for loading:

  • rsvg_handle_set_base_uri()
  • rsvg_handle_set_base_gfile()

Deprecated loading API:

  • rsvg_handle_write()
  • rsvg_handle_close()

Streaming API:

  • rsvg_handle_read_stream_sync()

When librsvg first acquired the concept of an RsvgHandle, it just had rsvg_handle_new() with no arguments. About 9 years later, it got rsvg_handle_new_with_flags() to allow more options, but it took another 2 years to actually add some usable flags — the first one was to configure the parsing limits in the underlying calls to libxml2.

About 3 years after RsvgHandle appeared, it got rsvg_handle_set_base_uri() to configure the "base URI" against which relative references in the SVG document get resolved. For example, if you are reading /foo/bar.svg and it contains an element like <image xlink:ref="smiley.png"/>, then librsvg needs to be able to produce the path /foo/smiley.png and that is done relative to the base URI. (The base URI is implicit when reading from a specific SVG file, but it needs to be provided when reading from an arbitrary stream that may not even come from a file.)

Initially RsvgHandle had the write/close APIs, and 8 years later it got the streaming functions once GIO appeared. Eventually the streaming API would be the preferred one, instead of just being a convenience for

12 April, 2019

Michael Meeks: 2019-04-12 Friday

19:41 UTCmember

  • To the Office in the morning for an interview; good to catch up with some of the team there. Back, lunch during TDF BoD call. Mail bits. Poked at some profiling bits.


Dear Tumbleweed users and hackers,

We had a larger gap this week, while the openSUSE Kubic medium (formerly openSUSE Tumbleweed Kubic) was restructured and renamed. Getting all the bits and pieces together to uphold the quality and not break things on the move meant to slow down a little bit. Nevertheless, we published three snapshots this week (0408, 0409 and 0411), containing those changes:

  • Apache 2.4.39
  • KDE Plasma 5.15.4
  • Linux kernel 5.0.6 & 5.0.7
  • Switch of the Plymouth theme to bgrt

Thinks currently being forged in staging areas:

  • linux-glibc-devel 5.0
  • Python2 2.7.16 & Python3 3.7.3
  • Wireshark 3.0: libvirt fails to build against it
  • CMake 3.14.x: libzypp fix ready, zypper pending
  • Qt 5.13
  • KDE Applications 19.04


11 April, 2019

Michael Meeks: 2019-04-11 Thursday

21:00 UTCmember

  • Mail, built TTT using ffmpeg command-line tools like:
    ffmpeg -i "2019-04-10 18-38-22.flv" -ss 0.00 -t 337.79 -c copy a.flv resulting in a much smaller output; hey ho.
  • Appalled by the usability of Apple Enterprise App development: requiring a different Apple id and thus making switching accounts (via needing two factor authentication) a matter of major upheaval on one of your devices each time the account switches; shame.
  • Disappointed to see the growing intolerance of people who hold different opinions: fundamentally sounds like the very definition of bigotry. There is a twisted irony in some modern mis-usage of the word bigot to mean: "person whose views I don't like, and thus whom I can't tolerate". An interesting trend; some suggest that postmodern liberals cannot comprehend the idea that one could simultaneously reject a belief and accept the person who holds it. Perhaps that is a consequence of the polarized ideological echo-chambers people we are all drawn to, and can easily inhabit these days. Does diversity of viewpoint necessarily imply acrimonious conflict: hopefully not - no matter how politically 'useful' such conflicts are presumed to be to whomever stoke them.
  • Sync with Muhammet, out for dinner with J. in the evening - lovely.

10 April, 2019

Michael Meeks: 2019-04-10 Wednesday

21:00 UTCmember

  • Mail chew, S&M call, couple of reference calls. Band Practice. Recorded an internal tea-time-training in pieces and tries to edit it together. OpenShot is determined to either blow up a 100Mb screencast to a 1Gb one or to debauch the quality; shame.


We are very pleased to announce that installing the lightweight and slim desktop environment Xfce in openSUSE Tumbleweed just got faster and hassle-free!

Along with GNOME and KDE Plasma, Xfce can now be conveniently selected from the installer’s main screen, as your desktop environment from both DVD installer and net installer. All this is combined with a carefully picked selection of packages that rounds off our offered system to get you started quickly and easily.

Our Xfce team has invested a lot of work in the past months to optimize the “cute mouse” by focusing on the desktop and the underlying rolling release of Tumbleweed. It features applications that better suit the desktop, as well as new modern themes that make the default experience refreshing and enjoyable.

Finally, there is a relatively new project in the Open Build Service (OBS), which builds automatically and daily development versions of Xfce software from Xfce Git Master branch. Through this repository, openSUSE Xfce packagers and contributors are able to test commits and can spot bugs before official releases.
Xfce users are welcome to test it and contribute to it at X11:xfce:rat. [1]

Going live

Xfce live images are finally here! The live images give you a close look at the Xfce experience in openSUSE, which allows you to test and preview the system features. Ultimately, if you decide so, you can install the system directly from the live environment.

One of the most important steps for us was the recording of the image in openQA and the associated automation of tests. We are happy to announce that the Xfce environment and all official related ISO images are tested in openQA, which helps us provide quality and stability to the systems. [2] [3] [4]

Live images of openSUSE Tumbleweed Xfce are available in both i586 and x86_64 architectures, and are easily accessible on https://software.opensuse.org along with all the other Live images offered by the openSUSE Project [5].
If you end up using those images on USB stick, they will be persistent, so they are also an excellent way to get a portable and bootable drive with all your settings waiting for you the way you set them up yourself.

Willing to join?

Being small but passionate, openSUSE’s Xfce team is always happy to welcome helping hands for testing, bug reporting, package maintaining, documentation and other tasks. But it’s not limited to technical areas! We are constantly looking for ideas and creative developments to discuss, elaborate and implement. openSUSE is a distribution living from its users and their contributions. If you are happily using openSUSE and want to take part in further development, here’s yet another good point to get started. For some more details, check our wiki page [6] or just feel free to reach out to us!

About Xfce

Xfce is a lightweight desktop environment for UNIX-like operating systems. It aims to be fast and low on system resources, while still being visually appealing


With the upcoming releases of openSUSE Leap 15.1 and SLE-15-SP1 approaching, the YaST Team at SUSE is investing a quite significant time in polishing details and fixing small (and not so small) bugs. But fortunately, that still leaves us enough time to also work in our mid term goals.

So welcome to our usual selection of selected bug-fixes (listing them all would be boring) and exciting new stuff. This edition includes:

  • A nice howto for reporting Snapper bugs
  • Tons of fixes for right-to-left languages like Arabic
  • Some adjustments and improvements in the storage area
  • A sneak peak into the future of the yast2-network code
  • Some contributor-oriented content: like our new pull request templates and revamped Docker images for testing

Snapper Bug Reporting Howto

During this sprint we fixed a bug that was causing Snapper to crash under very specific circumstances. The scenario was quite unusual so we had to request quite some information from the reporter of the bug to confirm what was happening. As a nice consequence, in addition to having now a more robust Snapper (one bug killed) you can also enjoy a new page in the openSUSE wiki listing the information you should attach to Bugzilla if you find a bug in Snapper while using (open)SUSE.

Which is also a nice excuse to remind you about the equivalent "Report a YaST bug" page.

YaST around the globe… in all directions

Many of the YaST users and of our blog readers are not native English speakers that surely appreciate the fact that YaST and (open)SUSE in general can be used in several languages. But have you ever thought about the implications of developing a multi-language software? Sure? In all of them? 😉

Human languages are so diverse as the human cultures and there are many details to take into account, from the usage of different alphabets to the various ways of dealing with genre or number (in English the words have just one form for singular and another for plural, but that can be way more complex in other languages). In today’s issue we will take a look to one of our favorite translation issues – languages that are written from right to left, like Arabic.

The installer summary in Arabic

Dealing with text that is a mixture of Latin and Arabic script is complex and sometimes we have to deal with interesting bugs. Fortunately we have our own weapon to fight those bugs. If in Star Wars they have protocol droids like C3PO, in the YaST team we have Martin Vidner, which is the closer human equivalent.

He fixed all the reported bugs and even created a tool to help debugging similar problems in the future. You can find the source code of that tool in Github. There is even a hosted instance of the tool to be used by translators or anyone who is curious.

Now, even complex interfaces like our Partitioner look correct enough in right-to-left languages, so we will not have to send mirrors to all our

Jim Fehlig: Let’s Brew!

03:26 UTCmember


Where to start? There are many blogs on homebrewing from folks with lots of experience so I won’t be providing any earth-shattering information for knowledgeable brewers, but I can provide a perspective from a novice that might be interesting for others considering diving into homebrewing. Along the way perhaps I’ll be lucky enough to also get some feedback and tips from the pros! I’ll first talk briefly about the ingredients used to make beer and then discuss the process of turning those ingredients into the tasty beverage we all love using the Clawhammer BIAB system I discussed in a previous post.

Beer is actually made from a simple list of ingredients: water, barley, hops, and yeast. All are very important to the quality of the final product. Although the ingredient list is simple, the chemical characteristics of water, the types of barley and the degree of malting, the families of hops, and the strains of yeast vary greatly, which accounts for the seemingly endless varieties of beer we see. Some beers include ingredients like fruit, honey, and other sweeteners, but IMO those are for amateurs and kids and will not be considered in this blog post. We’ll save those ingredients for the ice cream and pies!

The beer we are brewing here is a recipe from a good friend and fellow brewer, which he named Baldy Chutes Pale Ale in honor of the famed ski run at Alta Ski area. BTW, in the winters when not brewing or working I can often be spotted at Alta :-). Ok, back to making beer. Let’s review the ingredients: water, malted barley, hops, and yeast. Many brewers say that yeast is the secrete sauce to a beer. I don’t have enough experience to confirm or deny this rumor, but understand its role in the process enough to know it is important. Therefore I make a yeast starter three days before brewing. Being one that likes simplicity, I use a canned yeast starter instead of preparing one traditionally. I buy the bagged yeast, adding it, the yeast starter, and water to a flask and drop in a magnetic stir stick.

The flask is placed on a stir plate that slowly stirs the yeast in the starter to ensure it has oxygen to flourish. I try to keep the concoction at a constant temperature, ideally 68F, but it really at the mercy of the temperature of my office. On the morning of brewing, I place the flask in the refrigerator so the yeast will separate from the starter and settle to the bottom.

Another task I’ve learned to do the night before brewing is filling the boil pot with cold tap water, particularly in the winter months when the water is very cold. This allows raising it to room temperature without using electricity. It saves a few electrons for the conservation-minded folks. One other item to consider the night before brewing, or even before starting your yeast starter, is

Jim Fehlig: BIAB Homebrewing

02:23 UTCmember


Being a beer lover, I always wanted to brew my own beer but lacked time, money, and space required form making my own liquid bread. Over my travels and many places I’ve called home I’ve met several homebrewers and even spent afternoons helping brew batches of beer. While lending a helping hand I quickly realized the equipment needed to make beer from all-grain ingredients was the barrier for me. That all changed last fall when I helped a good fried make a batch of Alaska Amber clone. He had recently invested in a new Brew In A Bag (BIAB) system from Clawhammer Supply and I was immediately impressed with the functionality and usability of the system. I decided that afternoon it was time to start brewing my own beer!  I had found a brew system that provided the balance of simplicity and functionality I was looking for. Along with more free time in my life now that kids are older and more independent, it’s a great time to start a new hobby!

The Clawhammer BIAB system includes all the components you need for creating your favorite all-grain beer. It consists of a 10 gallon stainless steel boil pot, a 110 volt heating element (220 volt option available at substantially more cost), a controller for heat and pump, a temperature probe, a 110 volt pump, a plate wort chiller, grain and hop baskets, high temperature, restaurant-grade rubber hose, and all the quick-release fittings and valves needed to connect the system components. The system requires assembly but that was made easy by the helpful videos provided by Clawhammer Supply. That leads me to the only complaint about the system: lack of written documentation. Videos are fine, but I’m old school and generally like to read shit :-).


When deciding on the 110 vs 220 volt system, I read many reviews stating the 110 system was adequate if the boil pot was insulated. Clawhammer even sells an insulation kit for their boil pots. So I opted for the 110 volt element and fabricated my own insulation wrap for the pot with some insulation bought at the local hardware store.

I already mentioned how I liked the Clawhammer system simplicity. You have a boil pot that heats water with an electric element, a large grain basket that fits inside the pot, and a pump to circulate hot water over the grains to extract their all-important sugars. After mashing the grains and boiling the wort, simply insert the wort chiller in the system to cool the wort before transferring to fermentation storage. The system is also relatively mobile, opening the possibility to take it to the Henry’s Lake place for some Idaho brewing! Perhaps this picture of the entire system in action chilling a pale ale wort will help you understand my excitement around this system. In a followup post I’ll describe the steps for creating an all-natural, preservative and additive free beer with the Clawhammer BIAB system. Until then


My virtual Linux Users Group, as it were is the BDLL community. As part of a community challenge we were to live a week in Gnome. In full disclosure, I didn’t quite make it a full week on Gnome. Even though I was told I had to really give it a chance, really get used to the work flow to appreciate it, I tried, I read the documentation and I just could not find it an enjoyable experience for me. So, thanks for stopping by, if that is all you wanted to know, that is the bottom line up front.

Just because my experience in Gnome was not enjoyable, that doesn’t mean yours will be the same. It may work splendidly for you and you may find the work flow a perfect fit for your personal computer usage. I highly recommend that you do give it a try, regardless of my biased opinion.

This test was done on my primary machine, my Dell Latitude E6440. This machine had no trouble with Gnome. I didn’t see any performance issues there were occasional glitches but nothing distracting.


The beauty of openSUSE is the package management but beyond the package manager, the organization and simplicity of installing software. In this case, to install an entire Desktop Environment, Gnome in this case can be done by running this simple command in the terminal:

sudo zypper install -t pattern gnome

In summary, this is what the result of installing the Gnome Desktop from the openSUSE defined pattern.

432 new packages to install.
Overall download size: 177.7 MiB. Already cached: 0 B. After the operation, additional 660.9 MiB will be used.

Truly, not much more storage space was required only 660.9 MiB for the “standard” installation of Gnome.

Scope of Evaluation

For the purpose of this evaluation, I am going to ignore any little hiccups from the Desktop Environment. I am not going to be critical about any little glitches or bugs. I will ignore any rough edges of it, largely because I know this is the openSUSE, somewhat vanilla presentation of Gnome. In order to keep this Gnome experience similar to my time using Fedora with Gnome, I will not install any extensions. I am going to use it the way the developers and architects intend.

Overall Experience

After installation, I rebooted my machine. I wanted to be sure I was starting my Gnome experience from a freshly updated and rebooted system. The familiar SDDM (Default Plasma Display Manager) interface appeared with the familiar menu of options. I initially chose Gnome with Wayland but since I wanted my tools that require X11, I did switch to X for the majority of my time on Gnome.

Gnome felt stable to me. I didn’t have any strange behavior or crashes. It all worked as I expected. The interface is clean and tidy and has the familiar openSUSE look about it. I did notice that the settings I used to

09 April, 2019

Michael Meeks: 2019-04-09 Tuesday

21:00 UTCmember

  • Built ESC proto-agenda, tech mgmt call, admin, mail.

08 April, 2019

Michael Meeks: 2019-04-08 Monday

21:00 UTCmember

  • Mail, admin, partner call, customer calls, interview.

07 April, 2019

Michael Meeks: 2019-04-07 Sunday

21:00 UTCmember

  • All Saints in the morning, shared lunch. Home in the afternoon. Read stories to babes, snoozed, variously.

06 April, 2019

Michael Meeks: 2019-04-06 Saturday

21:00 UTCmember

  • Breakfast with the family; played with a smiley baby E. happily. Drove on to the Thanksgiving service for Gerv. Rather an encouraging service, tea & cake afterwards - met a number of interesting types. Drove home, quick tea, relaxed.

05 April, 2019

Michael Meeks: 2019-04-05 Friday

21:00 UTCmember

  • Took H. N. & E. to Haverhill for their music exams. Good to catch up with David & Nicky - out for a celebratory late breakfast and playground fun afterwards.
  • Triaged mail quickly; poked at profiling. Lunch. Drove to see Rob & Amelia & E. Lovely to spend time together until late.


Dear Tumbleweed users and hackers,

During week 14, we released 3 snapshots (out of 5 tested). The published snapshots were 0401, 0402 and 0403, containing these updates:>

  • Mesa 19.0.1
  • Linux kernel 5.0.5
  • Ruby 2.6.2
  • MozillaFirefox 66.0.2 – fixed compatibility issues with e.g. Office 365
  • Various modules from the GNOME 3.32 stack (not yet GNOME 3.32 itself though)
  • Rust 1.33

Currently staged changes are

  • Re-layout of the openSUSE Kubic medium
  • Linux kernel 5.0.6
  • KDE Applications 19.04 (currently at beta1)
  • Qt 5.13 (also beta 1)
  • gnutls 3.6.7 (break libsoup)
  • Wireshark 3.0.0: still broken libvirt
  • CMake 3.14.x: libzypp fix ready, zypper pending
  • openSSL 1.1.1:waiting for nodejs10 to catch up


04 April, 2019

Michael Meeks: 2019-04-04 Thursday

21:00 UTCmember

  • Sales & Marketing call, mail chew; annoyed by another missed interview; hey ho. Brief interview, ESC call. Kindly helped by av to get my GNOME ssh key / account sorted out: their infrastructure is really pretty. Out for a drink with Russel in the evening.

03 April, 2019

Michael Meeks: 2019-04-03 Wednesday

21:00 UTCmember

  • Mail, interview; bit of hackery - customer call, team call. Worked away at using the Chrome profiler for analysing and rendering Online logs - nicely, though lots left to do:
    Chrome Tracing output

02 April, 2019

Michael Meeks: 2019-04-02 Tuesday

21:00 UTCmember

  • Mail chew, sync with Andras. Pleased to see SUSE's success in the news.

01 April, 2019

Michael Meeks: 2019-04-01 Monday

21:00 UTCmember

  • Mail; admin; status report. Interview, more application triage.

31 March, 2019

Michael Meeks: 2019-03-31 Sunday

21:00 UTCmember

  • All Saints, celbrated Mothering Sunday; played; good to see people. Amused by The Mother's Day Song. Back for lunch, tidied up variously; J. collected babies stories from Burwell House, slugging, pizza tea.

30 March, 2019

Michael Meeks: 2019-03-30 Saturday

21:00 UTCmember

  • Breakfast in town at Coffee & Co, to All Saints, good to see the Mother's day posie creation complete.
  • Got to some hackery - while H. practiced the Organ. Home - re-worked Online socket code to use Unix Domain Sockets. Admin with J. in the evening.

29 March, 2019

Michael Meeks: 2019-03-29 Friday

21:00 UTCmember

  • Mail, calls, sync with Florian, TDF BoD call, more calls. Worked through a very large number of CVs of applicants. Men of Faith curry evening, caught up with David McG until late.


Dear Tumbleweed users and hackers,

I’m again spanning two weeks worth of updates sent your way. If you follow all upgrades, you have received a total of 8 snapshots since the last review. Those were snapshots 0315, 0318, 0320, 0321, 0322, 0324, 0325 and 0327. The most noteworthy changes were:

  • KDE Plasma 5.15.3
  • KDE Frameworks 5.56.0
  • Linux kernel 5.0.2 & 5.0.3
  • Bash packaging change: /bin/sh is now update-alternative handled. So far, no other package in openSUSE provides alternatives
  • Mesa 19.0.0
  • Tracker 2.2.1 (there are data migration issues known when coming directly from Tracker 1.4 – this would affect users switching from Leap 42.x to Tumbleweed. Simply resetting the tracker database would be enough)
  • Qt 5.12.2
  • NetworkManager 1.16.0
  • SELinux 2.9
  • Mozilla Firefox 66.0

And despite all those updates, our stagings are not free – and we’re having those updates in the pipeline:

  • Mesa 19.0.1
  • Rust 1.33 (Thunderbird fails to build)
  • CMake 3.14.0: libzypp/zypper ail to build
  • wireshark 3.0: libvirt fails to build
  • Qt 5.13 beta is staged (not meant to be shipped)
  • openSSL 1.1.1 – The blocker is, unchanged, nodejs (despite the move to nodejs10)


It took only 73 sprints to complete all YaST features, and there are none left to do. That’s what you might think after reading this article, because we worked on no features, just bug fixes.

It might be related to an upcoming release of SLE 15 SP1. For its openSUSE sibling we have put together a recap of YaST features in the upcoming openSUSE Leap 15.1 (scheduled for May 2019), since Leap 15.0 (May 2018).

No more locale errors during Kubic runtime

Did you know that an installed Kubic (the certified Kubernetes distribution & container-related technologies built by the openSUSE community) only has the American English locale (en_US) available? That is because it intends to be as small as possible (you can run du -h /usr/share/locale if you are curious enough).

However, YaST allows you to change the language and the keyboard layout at the very beginning of the installation process, which will be persisted as the default locale in the installed system. This is the reason for those locale errors mentioned above. Until now. Because we introduced some changes during this sprint to allow that the chosen language will be used only during the installation in case the product needs it.

So, from now on you can go through the installation of Kubic in your preferred language without those errors in the final system and, of course, preserving the selected keyboard layout. Not bad, huh? 😎

Various Fixes

Repositories for add-ons would be marked as disabled after the installation has finished. We have fixed this bug#1127818.

When registering your SUSE Linux Enterprise with the SUSE Customer Center or its proxy such as the SUSE Subscription Management Tool, a network timeout can occur. Formerly you had to use the Back and Next buttons to try again but we have added a Retry button for that.

When creating a new partition or editing an existing one, the widget for the partition type would list the types in a seemingly random order. We have made this widget more boring.

28 March, 2019

Michael Meeks: 2019-03-28 Thursday

21:00 UTCmember

  • Mail chew, projections, admin. ESC call.

25 March, 2019


Peter T. Linnell

Peter T. Linnell (1963 – 2019)

Peter was widely known as founder of Scribus, the Libre Graphics Meeting and enthusiastic contributor to countless other Free Software projects. For openSUSE he took over responsibility as an active member of our package review team and has served as openSUSE Board member twice, from 2011-2012 and 2014-2016. Peter passed away a week ago after lengthy battle with cancer, he is survived by his wife Pauline and his daughter Stella. His obituary mentions ways to honor his life.

We will always remember Peter as fellow tinkerer, with an boundless passion to understand the inner workings and meanings of software and people. Farewell Peter, you’ll be missed by the openSUSE Community.

Older blog entries ->