SUSE is getting a new ISP in Provo - and a new set of external IP addresses. This switch affects also some openSUSE servers that are currently running in the Provo datacenter. Mainly the Provo mirror server of download.opensuse.org, available via http://provo-mirror.opensuse.org/.

All machines that are currently using an IPv4 address starting with 130.57.72.XX will get a new IPv4 address assigned in the 91.193.113.64/27 network. Normally, this should go unnoticed, especially if you are using DNS.

Namely, the following four productive services are affected:

• debuginfod.opensuse.org
• provo-mirror.opensuse.org
• provo-downloadcontent.opensuse.org
• twsnapshot.opensuse.org

The migration will start next Friday, 2020-06-05, 09:00 MDT (click on the link to see the event in your timezone) - we hope to finish it during a few hours.

One hundred development sprints, that’s a nice rounded number… and a good moment to rethink the way we write and publish our reports.

Yes, you read it right. This post will be the last one following our traditional format, assuming something can already be called “traditional” after four and a half years. As we will explain at the end of this post, subsequent reports will look more as a digest with links to information and not that much as a traditional blog post that tries to tell a story.

But the Age of the Digest has not come yet. Let’s close the Age of the Stories with a last blog post covering several topics:

• A better editor for the <partitioning> section of AutoYaST
• Improved YaST support for advanced LVM and Btrfs features
• Ensuring YaST is not left behind in the migration to /usr/etc
• Taking XML processing in YaST to the next level

Many of those topic are clearly oriented into the mid-term future and, as such, it will take some time until they reach stable versions of openSUSE Leap or SUSE Linux Enterprise. Unless told otherwise, the changes described in this post will only be visible in the short term for openSUSE Tumbleweed users.

AutoYaST UI: Improve Editing Drives

Let’s start with an exception to the rule just mentioned. That is, something many users will see soon in their systems, since we plan to release it as a maintenance update for both 15.1 and 15.2 and the corresponding SLE versions.

As part of the initiative to modernize AutoYaST, the user interface for creating or editing the profile’s partitioning section has been finally revamped. That means no more missing storage features such as Bcache, RAIDs, Btrfs multi-device file systems, etc.

Apart from allowing to set every supported attribute by the AutoYaST partitioning section, during the rewrite we tried to keep the module as simple as possible to easy the user interaction, not only distributing the fields to put related stuff together and not having a crammed interface but also avoiding warnings and confirmation popup for each change done.

Of course, there is room for improvement yet, but at least we did the first step getting rid of the complex and broken old UI to start working in a simpler one.

Recognizing LVM Advanced Features

As you know, YaST can be used to configure storage setups combining several technologies like MD RAID, bcache, Btrfs and LVM. Not every single feature of each one of those technologies can be tweaked using YaST, since would lead to a completely unmanegable interface and a hardly predictable behavior.

But even if YaST cannot create certain advanced configurations, it should be able to recognize them, display them in the interface and allow simple modifications.

In the last couple of sprints we have focused in teaching YaST how to deal with advanced LVM features. Now it is able to detect and use LVM RAID, mirror logical volumes and LVM snapshots, both thick and thin ones.

YaST does not allow to create such setups and we don’t plan to support that in a foreseable future. But users that already use those LVM features will now be able to use YaST for some operations and to have a more complete and accurate picture of their storage configuration. In addition, the partial support for such technologies makes easier the upgrade process for systems using them.

Probing Btrfs Snapshot Relations and Two Peculiarities

On a purely technical level, all the additions explained above imply adding new possibilities to the so-called devicegraph which is used by libstorage-ng to represent any system. That included representing the LVM snapshots and the relations between origins and snapshots. That being done, it should be easy enough to go one step further and also recognize and represent those relations for btrfs subvolumes… except for two peculiarities.

The first one is that a btrfs snapshot can be both the child and the snapshot of the same subvolume. Suppose we have a btrfs mounted at /test. First we create a subvolume and then a snapshot of it:

cd /test
btrfs subvolume create origin
btrfs subvolume snapshot origin origin/snapshot

Now “snapshot” is a child of “origin” since it is placed directly under “origin” in the directory structure. In the devicegraph this means we have parallel edges (the gray for the child and the green for the snapshot):

The second peculiarity comes from the freedom of btrfs to rename and move subvolumes. We can move “origin” under “snapshot”:

mv origin/snapshot .
mv origin snapshot

The resulting devicegraph has a cycle:

So far that could not happen and some algorithms assumed that the devicegraph is always a directed acyclic graph (DAG). To remedy those algorithms we let them operate on a filtered devicegraph that hides the snapshot relations. Those filters were also added lately to libstorage-ng for LVM snapshots.

Now that libstorage-ng contains the mechanisms to deal with all these circumstances, we can think about offering advanced Btrfs options in YaST. But that will take some time since it comes with some challenges, with the design of the interface not being exactly the smallest one. Meanwhile, you can play around with this new libstorage-ng feature using the “probe” command included in the package “libstorage-ng-utils”, as long as you enable the experimental feature with the new variable “YAST_BTRFS_SNAPSHOT_RELATIONS”.

YAST_BTRFS_SNAPSHOT_RELATIONS=yes /usr/lib/libstorage-ng/utils/probe --display

Automatic Check for New /usr/etc/ Files

As we have already mentioned in previous reports, more and more parts of the distribution are changing the way they organize their configuration files. Things are moving from single configuration files in /etc to a layered structure that starts at /usr/etc and includes multiple files with different orders of precedence.

The YaST developers need to know when a file location is changed so we could adapt YaST to read and write to the correct location. Otherwise it could easily happen that the YaST changes would be ignored and we would get bug reports later. Therefore we implemented a regular check which scans for all etc configuration files in Tumbleweed and reports new unknown files.

The script is run once a week automatically at Travis. It downloads the repository metadata file which contains a list of files from all packages. It also contains files which are marked as “ghost”, these files are not part of the package but might be created by RPM post-install script or by user. We just compare the found files with a known list.

Some implementation details of that script may be interesting for our more technical readers, since it uncompresses a *.xml.gz file and parses the XML on the fly while downloading. That means it does not need to temporarily save the file to disk or need it loaded whole in memory. That is really important in this case because the unpacked XML is really huge, it has more than 650MB!

Improvements in YaST’s XML Parser

And talking about technical details, you may remember a couple of sprints ago we mentioned we had started a small side project to improve YaST’s XML parser. Now we can report significant progress on that front.

Let’s first clarify that we are not trying to re-invent the wheel by writing just another low-level parser to deal with XML internals. We are relying on existing parsers to rethink the way YaST serializes data into XML and back. All that with the following goals:

• Ensuring consistency of information when data is transformed into XML and then into raw data again, with our previous tools some information got silently lost in translation.
• Report accurate errors if something goes wrong during the mentioned transformation, so we know whether we can trust the result.
• Possibility of validating the XML at an early stage of (Auto)YaST execution.
• Reduce the amount of code we need to maintain.
• Make hand writting of XML easier.

We wrote quite some details about how we are achieving each one of those goals just to realize all that fits better into a separate dedicated blog post. Stay tuned if you are interested in those technical details. If you are not, you may be wondering how all this affects you as a final user. So far, the advantages will be specially noticeable for AutoYaST users. More consistent and shorter XML enables easier editing of the AutoYaST profile. Schema validation allows early warning when the XML is malformed. And the more precise error reporting will prevent silent failures caused by errors in the AutoYaST profile that can lead to subsequent problems in the system.

We keep moving

The future will not only bring a better AutoYaST, more LVM and Btrfs capabilities or a new XML parser. As mentioned at the beginning of this post, we will also change a bit the way we communicate the changes implemented in every YaST development sprint.

We currently invest quite some effort every two weeks putting all the information together in the form of a text that can be read as a consistent and self-contained nice story, and that is not always that easy. We feel time has come to try an alternative approach.

From now on, our sprint reports will consist basically in a curated and organized list of links to pull requests at Github. On one hand, the YaST Team puts a lot of effort into writing comprehensive and didactic descriptions for each pull request. On the other hand, our readers are usually more interested in some particular topics than in others. So we feel such digest will provide a good overview allowing the readers to focus on some topics by checking the descriptions of the corresponding pull requests.

We will still publish those summaries in this blog. And we will continue publishing occasional extra posts dedicated to a single topic, like the one about the revamped XML parser we just mentioned some lines above.

So, see you soon in this blog and in all our usual communication channels… and keep having a lot of fun!

When developing for architectures that are not mainstream, developers often have challenges to get access to current systems that allow to work on a specific software. Especially when asking to fix an issue that shows up only on big endian hardware, the answer I repeatedly get is, that it’s hard to get access to an appropriate machine.

I just recently saw reports that told that the qemu project made substantial progress with supporting more current Mainframe hardware. Thus I thought, how hard could it be to create a virtual machine that allows to develop for s390x on local workstation hardware.

It turned out to be much easier than I thought. First, I did a standard install of tumbleweed for s390x, which went quite easy. But then I remembered that also the OBS supports emulators, and specifically qemu to run virtual machines.

I got myself a recent version of qemu-s390 from the Virtualization project:

osc repourls Virtualization
...
su 
cd /etc/zypp/repos.d && \
wget https://download.opensuse.org/repositories/Virtualization/openSUSE_Leap_15.1/Virtualization.repo
zypper install --allow-vendor-change qemu-s390
exit

After this, we are almost done. The next part is to checkout some package from OBS and try to build it:

mkdir ~/obs && cd $_
osc co openSUSE:Factory:zSystems cmsfs
cd openSUSE:Factory:zSystems/cmsfs

Now, you can run the build locally with the ‘osc’ command. You will have to specify the amount of memory you want to give to the resulting virtual machine, in my case here, it is 8GByte:

osc build --vm-type qemu --vm-memory=8192 standard s390x

Building locally is nice, but how about working on that software? That is where the fun begins. Typically you would be able to do a chroot to a local directory when building in a chroot environment. So, lets just do some beginner error and run osc with the chroot command:

osc chroot --vm-type qemu --vm-memory=8192 standard s390x

To my big surprise, that command did not complain. I just opened up a second terminal, and found that in the background some processes were heavily working, and after a while, I was actually placed into a shell.

To double check, I ran ‘cat /proc/cpuinfo’ and yes, I am placed into a s390x virtual machine!

Putting things together: All you have to do, to have a running s390x virtual machine crafted for some specific package with all latest updates is:

1. Get the package source from OBS
2. Run osc chroot

I think that is really great functionality. Thanks to the excellent OBS team that made this work out of the box without much hassle. Great Job!!!

It is with great enthusiasm that I announce the INNOVATORS for openSUSE project, is an initiative to share projects, articles and news about innovative projects on the openSUSE platform developed by the community and public and private companies.

All information on this wiki is related to innovative projects that use augmented reality technology, artificial intelligence, computer vision, robotics, virtual assistants and any and all innovative technology (in all hardware plataforms ).

This initiative search collaborators for the project, the objective is to show the power of the openSUSE platform in innovative projects. To send suggestions, criticisms or be part of the INNOVATORS openSUSE community, send an email to the administrator Alessandro de Oliveira Faria (A.K.A. CABELO) at the email cabelo@opensuse.org.

To inaugurate the openSUSE for INNOVATORS project, we announced the ISOLALERT software created to combat COVID-19 by monitoring social isolation with computer vision. More information HERE

The openSUSE community, contributors and release engineers for the project have entered into the release candidate phase today after the Build “665.2” snapshot was released for the upcoming openSUSE Leap “15.2” version.

In an email to the openSUSE Factory mailing list, Leap release manager Lubos Kocman recommended Beta and RC users using the “zypper dup” command in the terminal prior switching to the General Availability (GA).

The release candidate signals the package freeze for software that will make it into the distribution. Among some of the packages that are expected in the release are KDE’s Plasma “5.18” Long-Term-Support version, GNOME “3.34” and Xfce “4.14”. New package for Artificial Intelligence and data scientist will be in the release. The release will also contain the tiling Wayland compositor Sway, which is a drop-in replacement for the i3 window manager for X”11”. The DNF package manager has been rebased to version “4.2.19”, which brings many fixes and improvements. In addition, a lightweight C implementation of DNF called “Micro DNF” is now included. Pagure, which provides an easy, customizable, lightweight solution for setting up your own full-featured Git repository server, has been updated to version “5.10.0”. A list of some of the packages in Leap “15.2” can be found on the openSUSE Wiki.

During the development stage of Leap versions, contributors, packagers and the release team use a rolling development method that are categorized into phases rather than a single milestone release; snapshots are released with minor version software updates once passing automated testing until the final release of the Gold Master (GM). At that point, the GM becomes available to the public (GA expected on July “2”) and the distribution shifts from a rolling development method into a supported release where it receives maintenance and security updates until its End of Life (EOL). The EOL of openSUSE Leap “15.1” is six months after the release of Leap “15.2”, so users of “15.1” will need to update by the beginning of “2021”.

Kocman listed the following important dates related to the release: June “22”: Translation deadline for packages June “23”: Final package submission deadline June “23”: Translation deadline for infrastructure June “25”: Gold Master followed by a public release the next week on Thursday, July 2.

The last week has produced a total of three openSUSE Tumbleweed snapshots bringing the total amount of snapshots for the month to 18.

All 18 snapshots have recorded a stable rating above 91, according to the Tumbleweed snapshot reviewer. With 14 of them, recording a rating of 99 and the last two snapshots trending at a 99 rating.

The most recent 202000526 snapshot provided the 3.2.4 release of Wireshark. The new version fixed a Common Vulnerabilities and Exposures where it was possible to make Wireshark crash by injecting a malformed packet onto the wire or by convincing someone to read a malformed packet trace file. Linux Kernel 5.6.14 re-established support for RTL8401 chip version. DNS server and client utilities package bind 9.16.3 fixed to security problems and added engine support for OpenSSL Edwards-curve Digital Signature Algorithm implementation. Document viewer evince 3.36.1 updated translations, fixed an incorrect markup in the Czech User Interface and updated the French help image. SSL VPN client package openconnect 8.10 installed a bash completion script and fixed a potential buffer overflow with security communications library GnuTLS. GNOME’s 0.30.10 image organizer shotwell, which was the subject of a recently settled a patient lawsuit, modified web publishing authentication to comply with Google’s requirements.

Snapshot 202000523 updated the rest of KDE ‘s Applications 20.04.1 stack. Among the fixes highlighted for the release are having kio-fish only store passwords in KWallet if the user asked for it, Kdenlive video editor had many stability updates, and fixes were made to the JuK music player that sometimes crashed. DNS resolver package unbound 1.10.1 offered up two security fixes for CVE 2020-12662 and 2020-12663. Perl Compatible Regular Expressions (pcre2) updated to version 10.35 and the Ruby code style checking tool rubygem-rubocop had multiple community contributions in the recent update to version 0.83.0, which added new features, support and fixes.

Application 20.04.1 began updating in Tumbleweed’s 202000523 snapshot where the file manager Dolphin received a crash fix if no Konsole is installed. The ImageMagick package fixed a black line bug when converting gif images in the snapshot. There was added filesystem UUID support in the erofs-utils 1.1 package update. The package for the window manager for the X Window System, icewm, updated to version 1.6.5 and fix for positioning of splash window on multi-head displays. IceWM also provided fixes and updates for both the configure and the cmake build. The Mail Transport Agent, postfix, updated to 3.5.2; the release fixed a bug introduced in postfix 2.2 where a Transport Layer Security (TLS) error for a database client caused a false ‘lost connection’ error for an Simple Mail Transfer Protocol (SMTP) over a TLS session in the same Postfix process. Python3 3.8.3 fix possible memory leak and improved error reporting and sudo 1.9.0 updated the default TLS listener to only be enabled when either the TLS certificate file is explicitly specified in sudo_logsrvd.conf or the default TLS certificate file exists in the file system.

I forgot to write this a few days ago; I hope it is not too late.

The GNOME Foundation's elections for the Board are coming up, and we are looking for candidates. Of the 7 directors, we are replacing 4, and the 3 remaining positions remain for another year. You could be one of those four.

I would like it very much if there were candidates and directors that fall outside the box of "white male programmer"; it is unfortunate that for the current Board we ended up with all dudes. GNOME has a Code of Conduct to make it a good place to be.

Allan Day wrote a review of the Board's activies for the last year. We are moving from a model where the Board does a little bit of everything, to one with a more strategic role — now that the Foundation has full-time employees, they take care of most of the executive work.

The call-for-candidates is open until May 29, so hurry up!

• GNOME Foundation Board of Directors: a Year in Review
• Call for candidates and elections

How often have you scanned a letter, a certificate or whatever and looked for the right way to call $UTILITY to convert it to a PDF that can be shared via internet?

For this very common use case I could not find a tool to make that really easy for the Linux desktop. Given my mission to help making the Linux desktop more common in the small business world (do you know Kraft?) I spent some time starting this little project.

Please welcome PDF Quirk, the desktop app to easily create PDFs out of images from storage or directly from the scanner!

It is just what this screenshot shows: A one page app to pick images from either the harddisk or from a scanner if configured, and save it right away to a multi page PDF file. The only option is to have either monochrome or color scan. No further scan chi-chi, just nice PDFs within seconds.

Of course I did not want to spend too much time and reinvent the wheel. PDF Quirk uses ImageMagicks convert utility and the command line scan client scanimage of the SANE Project in the background. Both are welknown standard commands on Linux, and serve well for this purpose.

Maybe you find PDF Quirk useful and wanna try it. You find it on Github, or packages on the openSUSE Buildservice.

Contributions and comments are very welcome. It is a fun little project!

Sometimes you just need to search using awk or want to use plain bash to search for an exception in a log file, it’s hard to go into google, stack overflow, duck duck go, or any other place to do a search, and find nothing, or at least a solution that fits your needs.

In my case, I wanted to know where a package was generating a conflict for a friend, and ended up scratching my head, because I didn’t want to write yet another domain specific function to use on the test framework of openQA, and I’m very stubborn, I ended up with the following solution

journalctl -k | awk 'BEGIN {print "Error - ",NR; group=0}
/ACPI BIOS Error \(bug\)/,/ACPI Error: AE_NOT_FOUND/{ print group"|", 
	$0; if ($0 ~ /ACPI Error: AE_NOT_FOUND,/ ){ print "EOL"; group++ }; 
}'

This is short for:

• Define $START_PATTERN as /ACPI BIOS Error \(bug\)/, and $END_PATTERN as /ACPI Error: AE_NOT_FOUND/
• Look for $START_PATTERN
• Look for $END_PATTERN
• If you find $END_PATTERN add an EOL marker (that is not needed, since the group variable will be incremented)

And there you go: How to search for exceptions in logs, of course it could be more complicated, because you can have nested cases and whatnot, but for now, this does exactly what I need:

EOL
10| May 20 12:38:36 deimos kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.LPCB.HEC.CHRG], AE_NOT_FOUND (20200110/psargs-330)
10| May 20 12:38:36 deimos kernel: ACPI Error: Aborting method \PNOT due to previous error (AE_NOT_FOUND) (20200110/psparse-529)
10| May 20 12:38:36 deimos kernel: ACPI Error: Aborting method \_SB.AC._PSR due to previous error (AE_NOT_FOUND) (20200110/psparse-529)
10| May 20 12:38:36 deimos kernel: ACPI Error: AE_NOT_FOUND, Error reading AC Adapter state (20200110/ac-115)
EOL
11| May 20 12:39:12 deimos kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.LPCB.HEC.CHRG], AE_NOT_FOUND (20200110/psargs-330)
11| May 20 12:39:12 deimos kernel: ACPI Error: Aborting method \PNOT due to previous error (AE_NOT_FOUND) (20200110/psparse-529)
11| May 20 12:39:12 deimos kernel: ACPI Error: Aborting method \_SB.AC._PSR due to previous error (AE_NOT_FOUND) (20200110/psparse-529)
11| May 20 12:39:12 deimos kernel: ACPI Error: AE_NOT_FOUND, Error reading AC Adapter state (20200110/ac-115)
EOL
12| May 20 13:37:41 deimos kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.LPCB.HEC.CHRG], AE_NOT_FOUND (20200110/psargs-330)
12| May 20 13:37:41 deimos kernel: ACPI Error: Aborting method \PNOT due to previous error (AE_NOT_FOUND) (20200110/psparse-529)
12| May 20 13:37:41 deimos kernel: ACPI Error: Aborting method \_SB.AC._PSR due to previous error (AE_NOT_FOUND) (20200110/psparse-529)
12| May 20 13:37:41 deimos kernel: ACPI Error: AE_NOT_FOUND, Error reading AC Adapter state (20200110/ac-115)
EOL

So I could later write some code that looks per string, separates the string using the pipe | discards the group id, and adds that record to an array of arrays or hashes: [ {group: id, errors: [error string .. error string] ]

SUSECON Digital 2020 starts today and it is free to register and participate in SUSE’s premier annual event. This year features more than 190 sessions and hands-on training from experts.

There are less than a handful of openSUSE related talks. The first openSUSE related talk is about openSUSE Kubic and takes place on May 20 at 14:00 UTC. In the presentation, attendees will receive an update about the last year of openSUSE Kubic development and see a demonstration on deploying Kubernetes with Kubic-control on a Raspberry Pi 4 cluster. Attendees will see how to install new nodes with YOMI, which is the new Salt-based auto installer that was integrated into Kubic.

The next talk is about open-source licenses. The talk will focus on the legal review app used by SUSE lawyers and the openSUSE Community. The app called Cavil was developed as an open source application to verify the use of licenses in open source software that help lawyers to evaluate risk related to software solutions. The talk scheduled for June 3 at 13:00 UTC will explain the ease of use for the lawyers and how the model significantly increases the throughput of the ecosystem.

The last openSUSE related talks centers on openSUSE Leap and SUSE Linux Enterprise. The talk will take place on June 10 at 13:30 UTC. Attendees will learn about the relationship between openSUSE Leap and SUSE Linux Enterprise 15, how it is developed and maintained and how to migrate instances of Leap to SLE.

The event as a whole is a great opportunity for people who are familiar with open-source and openSUSE. People who just want to learn more about the technology free of cost also have a great opportunity to experience the openness of SUSE and the event.