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.

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.

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.

Announcement

The Kubic Project is proud to announce that Snapshot 20200331 has been released containing Kubernetes 1.18.0.

Release Notes are avaialble HERE.

Upgrade Steps

All newly deployed Kubic clusters will automatically be Kubernetes 1.18.0 from this point.

For existing clusters, please follow our new documentation our wiki HERE

Thanks and have a lot of fun!

The Kubic Team

Dear Tumbleweed users and hackers,

The week started with problems inside the openSUSE Tumbleweed distribution (caught by QA, so no worries) and ended even worse: we have some trouble on openQA since Thursday and many tests are failing. The failures seem more to be related to openQA’s infrastructure though, and not to openSUSE Tumbleweed. Nevertheless, we will not publish new snapshots until QA is stable again. During this week we have thus only released two snapshots: 0326 and 0331 (promised, no joke).

The snapshots contained these updates:

• Kubernetes 1.18.0
• Linux kernel 5.5.13
• Rust 1.41.1
• XFCE 4.14.2

The things being worked on are

• KDE Plasma 5.18.4.1
• Linux kernel 5.6.0
• Systemd 245: homed will not be enabled/offered just yet
• Poppler 0.86.1
• GNOME 3.34.5: last stable version from the 3.34 branch; this supposedly still gets into Leap 15.2 (via SLE). After this, the team can start focusing on GNOME 3.36.x; a maintained mozjs68 package is the main blocker on this path though
• GNU Make 4.3: missing only a fix for daps
• Guile 3.0.2: breaks gnutls’ test suite on i586
• LLVM 10
• Qt 5.15.0 (currently beta2 being tested)
• Ruby 2.7 – possibly paired with the removal of Ruby 2.6
• GCC 10 as the default compiler
• Removal of Python 2: quite some progress done, but not fully there yet

Organizers of the openSUSE + LibreOffice Conference had a meeting this week to discuss various topics surrounding COVID19 and how it may affect the conference and planning for it.

At this point, it is uncertain what restrictions governments may keep in place in the coming months. While October is some months away, there are many aspects we are considering as to how to run the openSUSE + LibreOffice Conference.

Travel restrictions, flights, hotel and venue availability, event capacity and our community members’ ability to attend the conference are all factors we are considering. We hope to make a decision about the conference at the latest by mid-June.

In these difficult times, we want to assure our communities that we are actively engaged in a good outcome for all members, sponsors and interested parties involved with a successful openSUSE + LibreOffice Conference. We are looking at alternatives for the conference like possibly doing a virtual conference and exploring what tools might help us to achieve this should we decide it’s a viable option.

Please remember that the Call for Papers is open and people can submit their talks until July 21 at events.opensuse.org. We are moving forward, assuming the conference will take place as planned from Oct. 13 - 16 and will keep our communities informed of any decisions we make regarding the plans for the conference and any alternatives options like a virtual conference. Stay safe, healthy and strong during these hard times and we hope to see all of you later this year; celebrating together our anniversary under much better circumstances!

While many activities around the world slow down due to the COVID-19 crisis, we are proud to say the YaST development keeps going at full speed. To prove that, we bring you another report about what the YaST Team has been working on during the last couple of weeks.

The releases of openSUSE Leap 15.2 and SUSE Linux Enterprise 15 SP2 are approaching. That implies we invest quite some time fixing bugs found by the testers. Many of them are not specially exciting but we still have enough interesting topics to report about:

• More news about the new Online Search functionality
• Improvements in the user interface to configure NTP
• Progress in the support of Secure Boot for s390 mainframes
• Better reporting in AutoYaST
• Some bugfixes related to the handling of storage devices
• And a bonus: our new tool for mass review of GitHub pull requests

So let’s start!

The Online Search Keeps Improving

This is not the first time our loyal readers learn about the YaST feature to search online for packages within SLE modules and extensions. We initially presented it three reports ago, followed by a review of several usability improvements we had decided to implement on top of that initial version.

But, as usual, SUSE’s QA department did a pretty good job forcing us to go one step further and provided us with useful information about how to improve the functionality. Apart from some minor bugs, they reported that there were important performance problems and that the UX could be improved.

The performance issues were annoying when working with big result sets. In one of our testing machines, it took several seconds to display the found packages after having received the list from the SUSE Customer Center. Moreover, scrolling through the results was rather slow too. Hopefully, those problems are gone now: most of the time is spent in network communication and scrolling works smoothly.

Regarding the UX, we introduced a few changes:

• Now there is a button to make clear how to select/unselect a package for installation. In the text-based interface, it was rather easy to infer that pressing Enter was enough. However, in the graphical alternative, things were not that easy.
• We have added some information about how many packages were found.
• The help texts were extended and improved.

But the Online Search UI is not the only interface that received some love…

The Strange Case of the Multiple NTP Servers

YaST NTP allows to configure a list of NTP servers to use for synchronizing the date and time of the system. But one of our beloved users reported that a certain sequence of steps in the YaST Timezone module could ruin that list, reducing it to only its first entry. That was caused by a lack of consistency between both YaST modules.

YaST Timezone was designed a long time ago to, unlike YaST NTP, display and configure exactly one server. You may be asking, why can NTP be configured from YaST Timezone if there is an specific and more advanced YaST module for that purpose? The answer is that the YaST Timezone dialog is the only one available during installation, where it makes sense to offer the timezone and NTP configuration all together and with simplified options.

That simplicity also makes sense in an installed system for users with a basic configuration. But in systems with an advanced setup, we adapted that dialog to display the list of servers and to not offer any shortcut to adjust that configuration. Instead, the YaST Timezone dialog offers only a “Configure” button that opens the YaST NTP dialog, where the user can fine-tune the NTP configuration at will.

Secure Boot in zSeries Mainframes - Second Round

A couple of reports ago, we presented the initial support for zSeries Secure boot. We have continued improving that feature based on the feedback received from early testers and mainframe specialists.

Now, YaST behavior is better adapted to the characteristics of the system in which it’s been executed. We could go into details about each zSeries model and how YaST behaves based on its hardware configuration. But since an image is worth a thousand words, let’s just illustrate it with this new warning about z15+ requirement displayed when secure boot support is turned on.

The help texts and the information displayed in the installer proposal have also been adapted to better explain the consequences of the possible settings in YaST. Once again, let’s see it with an example image.

But, as you already know, this is not the only part of YaST we are improving step by step, one sprint after the other…

More Sanity Checks in AutoYaST

As part of our continuous effort to improve AutoYaST error handling and reporting capabilities (see this section of the previous report), we have added a new check for multi-devices technologies. Thus in case you are setting up an LVM volume group, a RAID, a Bcache or a multi-device Btrfs filesystem, AutoYaST makes sure that their components are also properly defined in the AutoYaST profile.

For instance, let’s say you want to set up a new LVM volume group but you forget to define which devices are going to act as physical volumes for it. In such a case, the new version of AutoYaST informs about the missing definitions and stops the installation.

In the image below you can see how the error reporting mechanism looks. In this example, it reports the AutoYaST profile contains a new multi-device Btrfs file system, but it does not specify which disks or partitions should be part of that file system.

It’s all About Blocks

As mentioned in the previous section and as all our users know, YaST and AutoYaST can be used to define a software RAID in which several disks or devices are combined for extra performance, extra reliability or a combination of both.

The usual scenario is to combine similar disks. But the RAID technology in Linux is so advanced that it allows to combine disks with different block sizes into the same array. Thanks to a recent bug report, we realized YaST was not handling that situation in the best way. That leaded to a wrong estimation about the final size of the RAID device which, in turn, leaded to possible errors while creating partitions in it.

We have fixed the libstorage-ng code and its documentation, that now offers an accurate description on how the situation is handled in Linux and in our storage library.

Apart from the creation of the RAID itself, the YaST Partitioner also offers some related functionality that is very handy in setups with many disks. For example, the button “Clone Partitions to Other Device” that can be used to replicate the same initial layout in all the disks that are going to be subsequently combined using the RAID technology.

When using such button, the Partitioner tries to only offer destination devices that make sense. That means they have to be as least as big as the source device, they have to have the same topology, etc. But guess what! We found out it didn’t check for the block sizes. That is also fixed now and future versions of the Partitioner will not allow to clone a partition table into another disk with a different block size, something that would lead to failures in most cases.

More Accurate Detection of zFCP devices

And talking about storage devices, recently we got a bug report about AutoYaST not being able to install SUSE on an s390 mainframe. After checking the logs and all the information provided, we found out that the profile was basically wrong as it contained the following definition for a zFCP device:

<listentry>
  <controller_id/>
  <fcp_lun>0x0000000000000000</fcp_lun>
  <wwpn>0x0000000000000000</wwpn>
</listentry>

Apart from the controller_id being missing, fcp_lun and wwpn look wrong too. So the profile is invalid, and there is nothing that AutoYaST can do about it. Done! Well, not that fast: the problem is that the profile was generated by AutoYaST itself.

We discovered that AutoYaST was wrongly identifying an iSCSI device as a zFCP one. So the profile excerpt above corresponds to an iSCSI device which, obviously, does not have any of those attributes.

A simple fix solved the issue and zFCP devices are now properly detected in openSUSE Tumbleweed and in the AutoYaST version that will be shipped with openSUSE Leap 15.2 and SLES-15-SP2.

Beyond YaST: GitHub Review from Command Line

We have reserved some development time also for learning and innovation. This part about reporting result of such a work.

Sometimes we need to do a simple change but in many Git repositories. Sometimes we need to touch all repositories, like when we need to change the CONTRIBUTING.md or some similar file.

Approving several dozens of pull requests in the GitHub web user interface is not easy or convenient so we have created a simple script which can approve the pull requests from the Linux command line. The tool is interactive, for each pull request is displays some details, the diff, the Travis status, etc… and then it asks for approval.

If you approve the request then it will approve it at GitHub with the usual “LGTM” (Looks Good To Me) message. If the request is not approved then you need to manually comment at the GitHub web UI why. Unfortunately there is no easy way for commenting a diff from command line…

For more details see this GitHub repository.

Last words… for now

As you can see, the bodies of the YaST Team members may be confined at home, but our minds are still out there, creating, fine-tuning and delivering software for you. And you can help us by testing the beta versions of openSUSE Leap 15.2 and SUSE Enterprise Linux 15 SP2 or just keeping your openSUSE Tumbleweed up to date and reporting any anomalous situation you find in YaST.

We will be back with more news in approximately two weeks. Meanwhile, have a lot of fun and take care of you and yours.