Dear Tumbleweed users and hackers,

During week #4, we have released five snapshots. And this, despite having discarded two snapshots for QA issues. openQA saved our users from crashing chromium inside a KDE/Wayland session for example. The five snapshots released were 0116, 0117, 0118, 0121 and 0122.

The releases contained these updates:

• Mesa 19.3.2
• systemd 244
• Dracut 049+git118: the purge-kernels-service has been removed in favor of being in a separate package, based on zypper commands. That service is as of now not yet auto-enabled though (the zypper call negatively interacts with the PackageKit notification applets, fixes are being prepared)
• Linux kernel 5.4.12 & 5.4.13
• Qt 5.14.0
• Poppler 0.84.0

This was quite a bit of what was reported last week as being in the works. Staging/integration tests are curretnly busy with these changes:

• Python 3.8
• Removal of python 2
• gettext 0.20.1
• libcap 2.30: breaks fakeroot and drpm
• GNU make 4.3: has some major incompatibilities. Observe fallouts at in Staging:O.
• KDE Plasma 5.18 (currently beta being tested)
• Linux kernel 5.4.14+
• netcfg moves a few files from /etc to /usr/etc (services,. protocols): currently, AppArmor is blocking access to those files, so we need some changes there

The Contents

• Partitioner: An Actionable Overview Screen
• Not only Partitioner: Numeric Sorting in Tables
• Improving the NFS Module
• Package Installation:
  • Installation Progress Improvements
  • Doomsday Preparations: Retracted Packages
  • Qt Package Selection Gets Faster

An Actionable Partitioner Overview Screen

Until now, the Partitioner landing screen has been useful to have a big picture of the devices in your system and as a shortcut to jump directly to the device page just with a double click over it. But, do you know what? From yast-storage-ng 4.2.74 on you can work directly with devices from that screen similar as you already do in the more specific pages, through the contextual actions added below the devices list. That means, for example, no more jumps to Hard Disks just to add a new partition nor resize an existing one. Enjoy :wink:

More details: PR 1024

Numeric Sorting in Tables

We have improved the sorting for tables in libyui, the UI library of YaST. So far columns were sorted directly by the text displayed, e.g. the device name or the size in the expert partitioner. For some use-cases this resulted in unexpected ordering, e.g. partitions of a disk were ordered “/dev/sda1”, “/dev/sda10”, “/dev/sda2”, and sizes were ordered “1 GiB”, “2 TiB” and “4 GiB”.

Now it is possible to provide a sort-key for every table entry which is then used instead of the displayed text. This allows the expected ordering and is already implemented for the tables in the expert partitioner as the two pictures below show.

Improving the NFS Module

YaST offers a specific module to configure your NFS shares. Similar to every YaST module, you can run it by executing yast2 nfs in your terminal, or by launching it from the YaST Control Center. But there is another cool way to use the YaST NFS module: opening the Expert Partitioner!

The Expert Partitioner offers a NFS section on the left menu tree where you can do everything that the NFS module provides. Thanks to that, you can configure your NFS shares at the same time you format your partitions!

But that integration needed some improvements after we migrated YaST to the new Storage Stack (a.k.a. storage-ng). Moreover, some bugs were detected when using the NFS module for mounting and unmounting shares, see for example bsc#1006815 and bsc#1151426.

All those bugs were fixed, ww the NFS module behaves as expected in both cases, when running in standalone mode and inside the Expert Partitioner. Note that now the current status of the existing shares is preserved. That is, an unmounted share will continue unmounted after editing it. Unmounted entries are indicated with an asterisk in the list of shares, similar to what the Expert Partitioner does for the rest of unmounted devices. All these improvements will be available for SUSE Linux Enterprise SP1, openSUSE Leap 15.1 and openSUSE Tumbleweed.

Installation Progress Improvements

We got some bug reports about how installation progress reporting works and while we were touching it, we also added a few smaller improvements to the code.

The first change is that nowadays installing from multiple discs almost never happens but still there was always a “Medium 1” column which did not make much sense. So we removed the column and if there is a multi-media source, it will be appended to the name if needed.

The second visible change is a new Unicode character ⌛ (hourglass) during the initial phase of RPM installation until the remaining time can be estimated.

The third change is that now the maximum time is always capped at 2 hours, so even if there are multiple sources and some of them took more then two hours, it always show just “>2:00:00” and even in total it is capped, so it can no longer show something like “>6:00:00”.

The fourth one is that now you can read the release notes without disturbances. Previously you would get switched to the package log tab after each package finished its installation. Now it will redraw only when you go back from the release notes screen.

The fifth one is a fix for showing the remaining packages, where it is shown only for the active source and not for all. So now it shows remaining packages for all repositories.

And last but not least we do a bunch of refactoring, code quality improvements and also adding automatic unit tests to reduce regressions in the future.

Tumbleweed before and now:

SLE before and now:

and new ncurses:

Doomsday Preparations: Retracted Packages

If a maintenance update is released for any of our supported products, it may happen that after its release we realize that it introduces new problems, so we have to unpublish (retract) it.

So far, our maintenance team always managed to find other solutions, but sooner or later it will happen that it takes too long to realize that an update was broken, so users will install it.

For that purpose we introduced a new status retracted for patches and packages. We hope that we will never need it, but if we do, we need it in a hurry — until a better, fixed version of those packages is released.

We added new filters “Retracted Packages” and “Retracted Installed Packages” to the package selection, and the affected versions are colored in red and get a [RETRACTED] marker in the “Versions” tab:

Those lists should always be empty. Also, retracted versions will never automatically be installed. If package versions are retracted, but are already installed, the “Retracted Installed Packages” view will be opened automatically when starting the package selection to make you aware of them. Then you can choose to manually downgrade to a previous version or to wait until a fixed version is available.

In general, don’t worry: We never needed this so far, and we hope that we will never need it. Still, we take precautions for the worst case.

More details: PR 82

Qt Package Selection Gets Faster

This came as a byproduct of the previous item: While working on the new filter views for retracted packages, we found that it could take a long time (10-20 seconds) when switching away from the “All Packages” view, so we started digging deeper to find out why.

We found it strange that clearing the package list on the right side of that dialog was so slow; considerably slower than filling it with all packages. After some investigations, we found that in the course of all those changes for all those Qt versions (since Qt 3.x in mid-2006) some internal housekeeping for those list items was now no longer necessary because later Qt versions took over more and more of those responsibilities, and our own housekeeping now got in the way of that and was considerably slowing it down.

Once we found the cause, the fix was easy: We threw out our own housekeeping code and are now relying on what the Qt widget does, and hey presto, clearing that list now happens instantly instead of taking 10-20 seconds.

More details: PR 82 (“Other Fixes”)

The winner of the openSUSE + LibreOffice Conference logo competition is Kukuh Syafaat from Indonesia.

Kukuh’s “Fresh Community Spirit” was the winning design and was one of 10 designs submitted during the competition. “Mystery Box” will be sent to Kukuh for the winning design.

In 2020, openSUSE and LibreOffice will have a shared conference from October 13 – 16 in Nuremberg, Germany_._

The organizing committee for this year’s joint conference selected the winning design during a meeting on Jan. 20. The logo portrayed an ideal fit for the conference since openSUSE and LibreOffice are combining their community conferences for just one year in 2020 to celebrate LibreOffice’s 10-year anniversary and the openSUSE Project’s 15-year anniversary.

Now that the logo has been announced, fliers and posters can be created to help advertise the event. The conference website will soon be available on events.opensuse.org and the Call for Papers will begin next month.

This openSUSE + LibreOffice Conference logo should not be confused with the LibreOffice 10th anniversary logo announced on the LibreOffice blog.

Literally, btrfs subvolume delete 2.0

If you contribute to an open-source community, there will be an "opportunity" that you will represent the community at a conference. You're expected to staff the booth and talk to people about the software.

For some people, it looks like you are traveling and having fun. I have news for you. It's not like that.
We are going to see some tips on how to survive booth duty.

1. Contact the booth manager

If you're not the booth manager (usually you're not), then you need to contact him/her before you travel. This person is in charge of shipping all the swag to the exhibition-conference hall at the right time, getting everything put together, and taking things down afterward. Usually, this person organizes the shifts at the booth. So you have to check when you can have your break, ask if there is a special "strategy" to promote, etc.

2. Clothes

Make sure with the booth manager if there is a dress code (so you need to carry a suit). If not, then make sure about the same T-shirt. Wear a comfortable top (T-shirt or hoodie) with the project's logo. It's good for the project that when you'll have a break or when you go for a walk to check other booths, you "advertise" the project. There might be people to see the logo and ask you, so you can point them to your booth.
Carry with you another T-shirt just in case of an emergency, so you can change (also carry a deodorant).
Regarding pants, wear also something comfortable. Jeans are fine but if it's summer, then a short is OK.

3. Shoes

Wear comfy shoes. This is the most important tip. You are going to spend a lot of time standing up. Most of the conferences are 2 days long, so you're going to be getting very sore feet. A pair of shoes with cushioned soles are the perfect choice for the situation. If there is a dress code, then be sure to wear high heels during your central presentation and then have a second pair of shoes for your booth duty.

4. Help with setup/breakdown

If you're not an employee of the open-source project company, then usually the company behind the project (or the companies that sponsor your open source project), paid part of your expenses. They expect you to stuff the booth but also to help them set up everything before and break down everything after the conference. Having good "relation" with the booth manager means also helps with these activities. Ask questions like: "Where would you like this?" or "May I carry anything?". Be different from the people who turned up two minutes before the show was due to start and made ill-advised remarks about the sign not being entirely straight on the front desk.

5. Don't over-police the swag

Swag means "give-aways". Usually, swag is a discussion opener. If the visitor is aware of your project, then he/she wants to get stickers for the laptop. Let them get more than one, because they usually get some for people back home, for people who cannot attend the conference, or for LUG members. Experienced marketers realize they'll just need to box everything up at the end and ship it back, so they might as well give as much of it away as possible.

6. Save some swag for the second day

Most conferences have the majority of visitors during the first day. Usually, they get most (sometimes all) of the swag. The project run out of some swag the second day. That's good because, during the breakdown, there are fewer items to ship back to the company's office. But it's bad because the visitors on the second day, won't be able to get some swag. So save some for the second day (Pareto principle: let's say 80% the first day and 20% the second day). If you have some swag left before the breakdown, take a selection of your best swag around to other booths on the floor and see what you can swap. Your project's swag may seem utterly useless to you, but there's a good chance (particularly if your marketing people know their thing) that other people might want it and will be willing to give you some of their swag in return.

7. You need a big suitcase

In other words, you need an empty big suitcase. Why? Because you'll get swag from other projects or even from your project to use back home, to share with other open-source friends-communities who couldn't attend where you've been.

Regarding how to behave at the booth, you can check the video from an openSUSE conference:


And another from my friend Jos:

The information below might fall into the "unsung heroes of openSUSE" category - we think it is clearly worth to be mentioned and getting some applause (not saying that every user should owe the author a beer at the next conference ;-).

• You are searching for a nice font for the next document?
• You want to install such a font directly via 1-click-install once you had a closer look?
• You want to know more about rendering or language information or the character set for a font you want to install?

Just have a look at https://fontinfo.opensuse.org/, which provides all these information for you + some more. Special thanks to Petr Gajdos, who maintains the page and the package with the same name since years.

So, today I got finally so tired of navigating (or explicitly stepping over) all the internal functions in gdb (you know, all the inline functions from STL containers, from Boost, from this pointer wrapper class, that string class) that I finally googled 'gdb skip system functions'. And guess what, it's been there since gdb 7.12, from 3 years ago, and it's almost trivial, just adding something like this to ~/.gdbinit:

skip -gfi /usr/include/*
skip -gfi /usr/include/*/*
skip -gfi /usr/include/*/*/*
skip -gfi /usr/include/*/*/*/*

 I feel so stu^H^H^Hproud for catching up only 3 years late.

These days, I came across spontaneous kiwi image build failures in a private OBS instance.
The images were SLES15-SP1, they had not been touched for quite some time, rebuilds were only triggered due to new packages in the update channel.
The error was grub2-install failing with the error message "not a directory".
Looking at the recent changes in the update repo showed no obvious reason (some python packages that had nothing to do with grub2-install), so I started to investigate...

... 3 days later, after following some detours, I finally found the issue.

grub2-install scans the installation device for filesystems, and probes all known (to grub2) fs types. The probe of "minix_be" fails fatally. Sometimes.

After building my own grub2 package with lots of debug-printf's, I finally found out, that the minix fs detection of grub2 is a little "fragile". It does the following (pseudo code):

• grub_mount_minix(device) || return "not minix fs"
• grub_minix_find_file("/") || fatal_error()

struct grub_minix_sblock         |struct grub_ext2_sblock
{                                |{
  grub_uint16_t inode_cnt;       |  grub_uint32_t total_inodes;
  grub_uint16_t zone_cnt;        |
  grub_uint16_t inode_bmap_size; |  grub_uint32_t total_blocks;
  grub_uint16_t zone_bmap_size;  |
  grub_uint16_t first_data_zone; |  grub_uint32_t reserved_blocks;
  grub_uint16_t log2_zone_size;  |
  grub_uint32_t max_file_size;   |  grub_uint32_t free_blocks;
  grub_uint16_t magic;           |  grub_uint32_t free_inodes;
};

As much as I like playing in the terminal, the jury is still out as to how much I like working with Cisco. To be as objective as possible, I need to tell myself that: 1, I am not familiar with the command set or how they like to do things so I must be open … Continue reading Configuring a Cisco switch from a Linux Terminal with Minicom →

This morning, while browsing the web, I wanted to listen to a Podcast from my laptop, and thought “Hey, can I stream this to our stereo?”. As it turns out, that’s rather easy to achieve, so I thought I’d share it here.
The media devices in our home are connected using Chromecasts, which are small dongles that allow playing media on them, meaning you can play for example a video from your phone on the projector in the living room: very convenient.

I didn’t know if that was easily achievable with audio from my Plasma/Linux laptop and a quick search turned up “pulseaudio-dlna” which adds Chromecast devices on the local networks as output devices.

On my KDE Neon laptop, it’s as easy as installing pulseaudio-dlna from the standard repositories and then starting “pulseaudio-dlna” from the commandline. Then, I can pick an output device from the panel popup and the audio stream changed to my stereo.

$ sudo apt install pulseaudio-dlna
[...]
$ sudo pulseaudio-dlna
[...]
Added the device "Stereo (Chromecast)".
[...]