Contents

Once most of the features that were planned for SUSE 15 SP2 and openSUSE 15.2 are ready, the team is shifting its focus to SP3 and 15.3. Of course, we are still polishing the releases around the corner, so in the summary of this sprint, you can find a mixture of bug fixes, small features, and preparation for the future work. These topics are:

• NCurses installation in old graphic chips
• Booting from Remote Encrypted devices
• Smarter network configuration in Linuxrc with the new try keyword
• Better support for auto-configured devices in S/390 systems
• Researching about how to improve XML YaST’s parser

Coming Back to Haunt Us: NCurses Installation and Old Graphics Chips

Some months ago (for Leap 15.1 / SLE-15 SP1), we started using fbiterm for all NCurses (text-based) installations. We had always used it for certain languages like Chinese, Japanese, Korean that need special support for their fonts, but since there were font-related problems even for other languages, we are now using it in all cases.

This fixed those font-related problems, but it turns out it brought back another issue that seemed long forgotten: poor performance in text mode for specific graphics chips.

Remember the Matrox G200? It was a good choice for Linux systems back years ago. Back many years ago; that GPU had its 20th anniversary in 2018, so it dates back to 1998 (that was when Windows 98 was new). Its graphics performance was… let’s call it quite okay for a budget card even back then.

Well, it turned out that it is still used today by some rack server manufacturers as on-board graphics. Most on-board graphics these days uses Intel GPUs (and they work great), but not all: some indeed use that old Matrox G200.

We had a business customer inquiring why screen redraws while installing their rack servers were so slow with SLE-15 SP1 compared to SLE-15 GA, and that’s the explanation: Those machines have that Matrox G200 on-board graphics, and it doesn’t seem to have the hardware acceleration that would be good to have for a framebuffer console. And with fbiterm you can now really see the difference.

In that setup, you can observe the NCurses library at work in slow motion: You can see how it partially removes text from the cursor position to the end of the line (leaving part of the screen black) and then redraws content from there. It’s not wrong or buggy, it’s just slow. Unbearably slow, like back then having a very slow (4800 baud) terminal connection (remember those?).

So our recommendation for that kind of hardware is: Better not use a framebuffer console. Just leave the machine in plain text mode with 80x25 with the nomodeset boot parameter, or do an SSH installation.

Those old ghosts keep coming back to haunt us, even from back in the very late MS-DOS days. :smile:

Improve Booting from Remote Encrypted Devices

But not all ghosts are that old. We also got the visit of the spirit of the past sprints. In one of our November posts, we explained you how we had addressed the existing problems booting from remote encrypted devices by adding the _netdev option to the fstab and crypttab files for all network-based file systems.

For some months, it looked like the definitive solution. But recently it was reported that, as much as that option indeed pleases systemd, it confuses dracut when it is used in the root file system. Although they say you cannot make everybody happy, we found that adding that option to all file systems except the root one actually seems to be the right solution for both systemd and dracut. The latter does not get confused anymore and turns out the root file system is the only one for which omitting the option is safe for systemd.

With all that, SLE-15-SP2 (and Leap 15.2) should exhibit a pretty solid behavior for all scenarios involving installation on top network disks, encrypted or not. For more technical details, you can check the corresponding pull request.

Let’s try ifcfg in Linuxrc

Linuxrc is a piece of software responsible for booting the installation media. It offers a friendly interface to set up some basic stuff (e.g., the language) and takes care of initializing the hardware and preparing all the stuff that YaST needs to do its magic.

Alternatively to the good looking interface, it provides a really powerful command line too. If you have not done it before, we recommend you to check the Linuxrc wiki page.

One of the things you can set up using the command line is the network, which is really handy when you want to do an installation from a network source.

ifcfg=eth*=192.168.0.2/24 install=http://192.168.0.1/iso

With these settings, Linuxrc configures the first device that matches the eth*. But what happens if you have multiple network interfaces? Is the configured interface the right one to reach the installation media?

To deal with these situations, we have added a try feature to the ifcfg option:

ifcfg=eth*=try,192.168.0.2/24 install=http://192.168.0.1/iso

In this case, Linuxrc tries to find the device which matches the pattern and makes the installation source reachable.

The try keyword works for static configurations as well as for DHCP. When used with DHCP the difference is that the DHCP setup is done for just one device. Without the try keyword, the DHCP configuration is assigned to all devices which match the device pattern. So, if you use:

ifcfg=eth*=try,dhcp

you’ll end up with one DHCP configured device (the one that has a working network connection). On the contrary, omitting the try option will configure via DHCP all the devices matching the given pattern.

You can use any of Linuxrc’s network-aware options as criteria for the try option (install, dud, info, and autoyast). However, you cannot explicitly determine which one will be used if more than one is given. It merely depends on which one is used first by Linuxrc.

Better Support for Auto-Configured Devices in S/390 Systems

A few weeks ago, we announced that we had extended Linuxrc and YaST to play nicely with the new I/O device auto-configuration mechanism on zSeries systems. After gathering some feedback from our S/390 experts, we did some adjustments to the current implementation.

On the one hand, the auto-configuration is now optional. Linuxrc offers a new DeviceAutoConfig that allows the user to indicate whether to apply the configuration. The possible values are 0 (no), 1 (yes) and 2 (ask). The last of those values is the default.

On the other hand, QA detected a problem when AutoYaST tried to configure a device that has been already configured. Apart from solving the issue, we invested some time doing cleaning-up part of the yast2-s390 module.

Improving YaST’s XML Parser

XML is an important language in the YaST world. The best example is the so-called control file, which defines many aspects of the installation process. You can check the control file for openSUSE if you are interested.

YaST implements its own XML parser which is adapted to our needs. For instance, it is able to understand an special config:type attribute which serves as a hint about to interpret the content of the XML tag. If you have used AutoYaST, you know what we are talking about.

<initialize config:type="boolean">true</initialize>

However, it has its own set of problems, especially when it comes to error reporting. For that reason, we have started a new initiative to improve our XML parser. There are some discussions which are taking place in the yast-devel mailing list (like YaST XML Parser and Yast XML parser and strictness). Feel free to join and share your point of view.

Conclusions

To plan for the future, the team has started to do some research about the current status of YaST modules and AutoYaST. You might already have read something about them if you are subscribed to the yast-devel mailing list. If you want to share your point of view, you are welcome to the discussion.

In any case, we plan to present our conclusions during the upcoming weeks. So stay safe and tunned!

Dear Tumbleweed users and hackers,

Two short (work) weeks just passed; The long Easter weekend kept me away from writing last weeks report. So I have to catch up now, covering two weeks worth of snapshots. There were 10 snapshots released in those two week (0401, 0402, 0405, 0407, 0408, 0409, 0410, 0411, 0413 and 0414).

The noteworthy changes were:

• Linux kernel 5.6.0 & 5.6.2
• openSSL 1.1.1f
• Mesa 20.0.4
• MozillaFirefox 74.0.1 & 75.0
• KDE Plasma 5.18.4.1
• Poppler 0.86.1
• GNOME 3.34.5
• GCC 9.3.1
• GNU make 4.3
• LLVM 10
• Ruby 2.7 has been added; but no gems are being built yet

Looks like a long list, but it was spread over two weeks. And some of those changes had been brewing for a long time already. The future changes you can expect are:

• Removal of Python2 (VERY SOON!). We will remove all python2-FOO modules, but keep the python2 interpreter, python2-setuptools and python2-pip around. So people who need to can still base their work on that. This is supposedly happening in Week 17
• KDE Frameworks 5.69.0
• Linux kernel 5.6.4
• Systemd 245
• Poppler 0.87 (for once a painfree update?)
• GNOME 3.36
• KDE Applications 20.04 (RC being tested at the moment)
• Guile 3.0.2: breaks gnutls’ test suite on i586
• Qt 5.15.0 (currently beta3 being tested)
• Switch from Ruby 2.6 to 2.7
• GCC 10 as the default compiler

Hi openSUSE Community,

We have been using Redmine as a ticketing system for a very long time. The previous server had Redmine 2.4.5 from 2014 installed on an old SLE 11 SP4 server.

And finally we have successfully migrated to a newer Redmine version. Currently running Redmine 3.4.12 on a brand new server with Leap 15.1.

This is a long awaited step in a long, long journey. Much time was spent fixing broken plugins, configuration and the database to match the new Redmine version. And we have a new theme to make it look fresh.

Thank you to all people who helped this migration run smoothly.

Estu

Since last Thursday, a total of five openSUSE Tumbleweed snapshots were released.

Each snapshot had about between five to 10 packages updated.

The most recent snapshot, 202000414 has a few libraries updated like libgit2 0.28.5, libva 2.7.0 and libva-gl 2.7.0. Several patches and five Common Vulnerabilities and Exposures security fixes were made to the high performance, multi-platform VNC client and serve tigervnc 1.10.1. Midnight Commander (mc) 4.8.24, which is a text-mode full-screen file manager and visual shell, provided new skins and added yabasic (Yet Another BASIC) syntax highlighting. A minor update to plymouth’s 0.9.5 version removed unused kernel-headers and module-init-tools build dependencies and the xfce4-settings 4.14.3 updated translations and modified the display to allow for the use of a proper fallback configuration on “apply” and “toggle off”. The xfwm4 4.14.1 package, which is the window manager for the Xfce environment, fixed hostnames that were not showing initially when running apps remotely and the update fixed a crash with the Graphics Library that involved high CPU usage without a monitor. The snapshot is currently trending stable at a rating of 93, according to the Tumbleweed snapshot reviewer.

A new major version of the Mozilla Firefox browser was released in snapshot 20200413. The new 75.0 version improves the behavior performance on Linux when clicking on the Address Bar and the Search Bar, which now matches other desktop platforms; a single click selects all without primary selection; a double click selects a word; and a triple click selects all with primary selection. Additionally, Firefox is now available in Flatpak and a CVE memory safety bug for Firefox 75 and Firefox ESR 68.7 were fixed. The btrfsprogs package jumped from version 5.4.1 to version 5.6 and supports new hash algorithms in the 5.5 Linux Kernel; the new version also supports LOGICAL_INO_V2 features in logical-resolve. The new option ‘-o’ helps advanced dedupe tools. The libostree 2020.3 library was update in Tumbleweed from it’s previous 2019.6 verion; nine months of updates bring several newer features and fixes like support for making the /sysroot mount pointread-only upon start, and the error-handling around GPG verification was overhauled. Text editor nano 4.9.2 fixed a crash after undoing an at the end of a leading whitespace. The snapshot is currently trending at a moderate 83 rating on the [Tumbleweed snapshot reviewer](https://review.tumbleweed.boombatower.com/).

Snapshot 20200411 is also trending at an 83 rating and provided less than a half dozen updated packages. GNOME’s gnome-weather 3.34.2 package fixed an unknown temperature and cloud conditions bug when using autolocation. The yast2 4.2.81 version retranslated the wizard help button in the ncurses User Interface. Updates were also made to yast2-packager 4.2.61 and yast2-tune 4.2.3.

The ncurses package was update in the 20200410 snapshot; the new version added a configure option and a check for the GNU Compiler Collection -fvisibility=hidden feature. The snapshot also had an update to gcc9 9.3.1. Peripheral Component Interconnect, USB and vendor identifications were updated in the hwdata 0.334 package. Many incremental improvements and bug fixes were made with the update to libvirt 6.2.0. The new libvirt implements a QEMU 5.0 feature allowing for NVDIMM memory support for pSeries guests, which is done by adding a ‘uuid’ element in the memory XML that can either be provided in the XML or, if omitted, generated automatically. Salt 3000 has arrived in Tumbleweed; the new Salt version removes the date versioning, provides new functions to chroot: apply, sls, and highstate. It also updates slot syntax to support parsing dictionary responses and to append text. The snapshot will likely record a moderate 82 rating on the Tumbleweed snapshot reviewer.

Snapshot 20200409 recorded an 82 rating and provided an update to flatpak 1.6.3, which fixed a regression in the progress calculation for applications using extra-data. User space utility strace 5.6 provided several improvements like the ability to silence specific messages using -e quiet/–quiet qualifier (an alias for the -q option), including those that couldn’t be silenced previously (path resolution messages and “superseded by execve”). Another noteworthy package updated in the snapshot was the update to the LLVM Compiler; llvm10 10.0.0 brings new tools like llvm-ifs, llvm-install-name-tool and llvm-reduce.

In the times of Covid-19 and the people staying at home it is an adventure to get the tools to work from home without missing the benefits of face-to-face meetings.

There are a lot of solutions out in the wild. But one promising solution is Jitsi. Until now we used the instances provided by other people.

But now we are able to introduce:

Our own Jitsi instance

It is based on openSUSE Leap 15.1 and uses docker containers to deploy Jitsi. The current security warnings were also considered, furthermore the setup uses secure LDAP and HTTPS.

You need an openSUSE(community) account to login.

A few remarks about meet.opensuse.org:

• It is a 8 CPU VM with 16 GB of RAM
• This is still a “Beta” system
• We don’t know how Jitsi scales
• We will try to keep the downtimes as low as possible

The plan for the future is to package jitsi for openSUSE and to deploy an instance with packages.

If you find bugs or experience any problems please report to admin@opensuse.org or find me on Freenode with the nick lethliel.

I hope you enjoy it and have fun :-)

Marco

Usually your AppArmor profile would look something like this:

#include <tunables/global>

/usr/lib/colord {
  ...
}

Now if we check if our profile is actually used:

$ ps axZ | grep '^/usr/lib/colord'
/usr/lib/colord (enforce)  4466  ?  Ssl  0:00 /usr/lib/colord

The Z parameter makes ps print the AppArmor profile name, or in the case of selinux the context of the program. /usr/lib/colord (enforce) tells us what AppArmor profile is used and in which mode it is. Another option you can see there is complain. With long binary paths this can become ugly very quickly.

SUSE has sent a proposal to the openSUSE community about bringing the code streams of both SUSE Linux Enterprise and openSUSE Leap closer together. The proposal includes SLE binaries for the community version.

Bringing the code streams closer together to provide full compatibility provides several advantages to the community going forward such as the use of higher-quality code due to the clean-up of spec-files, an improved relationship between the two distributions, easier bug reporting, less code streams to maintain, extensively tested packages and the inclusion of SLE supported architectures like s390x.

“With this change, we can make better use of our resources as one code base converge, so one build target less to consider,” expressed openSUSE board member Axel Braun in an email sent out to the community about the proposal. “Everyone who packages for Leap and for Package Hub will immediately benefit from this.”

The proposal provided a staged approach to implementing the vision. The email listed the following options: • Merge the code bases for the intersection of openSUSE Leap 15.2 and SUSE Linux Enterprise 15 SP2 as much as possible without loss of stability or functionality. (SUSE has actually started merging from Leap into SUSE Linux Enterprise.) • Create an intermediate openSUSE Leap flavor where SLE binaries are used inside (October 2020 time frame) in parallel to classic Leap 15.2. • Build openSUSE Leap 15.3 with SLE binaries included by default (assuming community agreement).

The Leap distribution already shares a significant amount of core source code with SLE. Leap 15.2 will be based on the sources from SLE 15 SP 2, but not the binaries.

The community is likely to discuss the proposal on how to bring the SLE binaries into a to new build setup for Leap and would help to identify any issues that might change processes or workflows. The intermediate project build in OBS is likely to come in May. The build should give openSUSE contributors and developers an opportunity to better understand SUSE’s proposal.

“We have an idea about the setup in build.opensuse.org,” responded Adrian Schröter from the OBS team. “I anticipate to have a first prototype of the build setup in next three weeks. We must keep in mind that this is really an entire new way to develop a distribution.”

The release team has evaluated all the packages and technical implications for integrating the additional SLE packages, so they could provides some clarity to the community on how a technical implementations might work best.

There are about a couple dozen packages that are technically difficult to implement for full compatibility with the enterprise and community distributions.

“It took quite some effort to create a plan acceptable by all involved teams,” explained Leap release manager Lubos Kocman. “Splitting the work across the upcoming two releases seemed to be accepted well at least by involved parties so far. The idea of re-using should generally lower the effort on the Leap side. However, it comes with the price of increased complexity to bring all (the) pieces together.”

Feedback and technical discussions are an important part of any open-source project. The new intermediate project build will introduce the community to the sources and help with the handling of various code parts that are needed to implement schedulers, publishing and other elements of releases should the proposal be accepted by the community.

The release engineering team is interested in feedback from contributors and users once the intermediate project build becomes available.

Feedback is an important part of this process as the project looks to gain more SLE source code, Kocman emphasized.

A road map for the prototype build an proposed release would become available at https://en.opensuse.org/openSUSE:Roadmap.

Frequently Asked Questions about this topic are available at https://en.opensuse.org/Portal:Leap/FAQ/ClosingTheLeapGap.

Over the weekend I was forced to unload all my photos from my phone due to limited storage space. As I went through a nice capture of Builder nighly caught my attention and I couldn’t help but post it on twitter.

Cyberdyne Builder

Obviously posting on twitter meant it was misunderstood immediately and quipped with entitled adjectives. And rather than responding on the wrong platform, I finally have an excuse to post on my blog again. So let’s take a look at the horrible situation we ended up with.

Thanks to Flatpak you now have a way to install a stable and development versions of an app, concurrenly. You can easily tell them apart without resorting to Name suffices in the shell, where the actual name gets horribly truncated due to ellipsization, while still clearly being the same app on a first glimpse.

Stable and Nightly Boxes

There’s plenty of apps already making use of this. So how does an app developer get one? We actually have the tooling for that. If you have an app icon, you can easily generate a nightly variant with zero effort in most cases.

So what was the situation twitter was praising? Let’s count on how many GNOME applications shipped a custom nighly icon. Umm, how about zero?

A pretty picture an artist spends hours on, modelling, texturing, lighting, adjusting for low resolution screens is not a visual framework nor a reasonable thing to ask app developers to do.

Another four openSUSE Tumbleweed snapshots were released this week.

A notable package updated this week is a new major version of gucharmap. Plus several python package updates, nano, mesa, git and Xfce packages also had new minor updates.

The most recent snapshot, 202000331 is trending well with a stable rating of 99 on the Tumbleweed snapshot reviewer. The GNOME Character Map, gucharmap, updated to version 13.0.0, but no changelog was provided. An update for glib2 2.62.6 is expected to be the final release of the stable 2.62.x series; maintenance efforts will be shifted to the newer 2.64.x series. The updated glib2 package fixed SOCKS5 username/password authentication. The 2.34 binutils package added and removed a few patches. GTK3 3.24.16 fixed problems with clipboard handling and fixed a crash in the Wayland input method. The package for creating business diagrams, kdiagram 2.6.2 fixed printing issue. The Linux Kernel updated to 5.5.13. A handful of Advanced Linux Sound Architecture changes were made in the kernel update. The 5.6.x kernel is expected to be released in a Tumbleweed snapshot soon. The libstorage-ng 4.2.71 package simplified combining disks with different block sizes into RAID. The programming language vala 0.46.7 made verious improvements and bug fixes and properly set CodeNode.error when reporting an error. Several xfce4 packages were updated and xfce4-pulseaudio-plugin 0.4.3 fixed various memory leaks and warnings and xterm 353 was updated. The yast2-firewall 4.2.4 packaged was updated and forces a reset of the firewalld API instance after modifying the service state and yast2-storage-ng 4.2.104 extended and improved the Application Programming Interface to get udev names for a block device

The package to improve audio and video under Linux pipewire 0.3.1 switched the license to MIT and added fdupes BuildRequires and pass fdupes macro while removing duplicate files, which came in snapshot 20200326. The 1.1.9 spec-cleaner package drop travis and tox and now uses github actions. Several python arrived in this snapshot. Python-packaging 20.3 fixed a bug that caused a 32-bit OS that runs on a 64-bit ARM CPU (e.g. ARM-v8, aarch64), to report the wrong bitness and python-SQLAlchemy 1.3.15 fixed regression in 1.3.14. The Xfce file manager package, thunar 1.8.14 updated translations and reverted a bug that introduced a regression. The snapshot recorded a stable rating of 99.

A stable rating of 97 was recorded for snapshot 20200325. The snapshot updated ImageMagick to version 7.0.10.2 and fixed another sizing issue with the label coder when pointsize is set. Mesa 20.0.2 provided several fixes for the code base. Bluetooth issues were fixed with the class UUID matches before connecting the profile in the bluez 5.54 package. Git 2.26.0 improved the handling of sparse checkouts. Text editor nano 4.9 made the new paragraph and the succeeding one get the appropriate first-line indent when justifying a selection. The latest stable version of the in-memory database redis 5.0.8 uses the tmpfiles macros instead of calling systemd-tempfiles direct and build wrong macro paths and the sssd 2.2.3 package brought new features like a “soft_ocsp” and “soft_crl” options that were added to make the checks for revoked certificates more flexible if the system is offline.

The 20200324 snapshot recorded a stable 93 rating. The snapshot also had an update for ImageMagick and an updated version of Mozilla Thunderbird 68.6.0. The email client adds a new popup display window when starting up on a new profile. A fix for the linker version script was made in FUSE (Filesystem in Userspace) 3.9.1, which provides a simple interface for userspace programs to export a virtual filesystem to the Linux kernel. The lensfun package jumped from version 0.3.2 to 0.3.95 and provides support for several next cameras and lenses. Other packages updated in the snapshot were mercurial 5.3.1, php7 7.4.4 and zypper 1.14.35.

Systemd 245 is expected to arrive in a snapshot in the coming days.