I was looking forward to updating a package (enchant) with a backported patch from upstream and wanted it to be included in both SLE offerings and openSUSE. I’m used to working within the community from the past, so even though I’m a SUSE employee I wanted to contribute without using anything internal.

I filed a bug and did a request to first get the patch into Tumbleweed via GNOME:Factory. That was easy, but then I looked on how to get the same patch into the stable releases. Since openSUSE and SUSE are now coming closer, I found documentationa about the Jump and mailing lists described some documents for example that there either is or is going to be a new redirector service, and suggestion was to target openSUSE:Jump:15.2 at one point.

Eventually I found out that since 15.3 is when SLE & openSUSE really closes the leap gap, Jump is already history and currently the best target is to use openSUSE:Leap:15.3. I was actually told by someone that it wouldn’t work, but… it did!

In practice my Leap request (I really submitted it to openSUSE:Leap:15.3!) was automatically detected to be about a package that openSUSE inherits from SLE, so the target was switched to SLE 15-SP2 on the fly. Secondly, after some time a person managing these kind of requests copied over my public request to be usable inside SLE process, and then an official SLE 15-SP2 update request was created automatically. It passed QA in the beginning of January, and was made available to 15-SP2 users! Luckily 15-SP3 has no deviation for this package from 15-SP2, so it’s automatically also there, and that means openSUSE Leap 15.3 is going to have the patched package automatically as well.

Finally, also without my manual intervention there was a request to get it to Leap 15.2 as well, finalizing fixing all relevant releases (15.1 is not affected by the bug).

All in all, even though it feels the documentation is a bit lacking and there could be more feedback or clearer visibility on a higher level, the functionality of the process was really good. Now that I know a bit more, I can try to improve the wiki a bit.

The configurable Python-based HPC package manager Spack is now an Official package in openSUSE Tumbleweed, which currently has the 0.16.0 version of Spack.

If you work with scientific software, you probably know about spack.

Spack is a package manager for HPC that allows to install scientific software using provided recipes. You can easily use multiple compilers and compiler versions. And different versions of the same software can coexist peacefully.

Spack is used with environment-modules or lmod to make easier for users to choose the software stack for their projects.

However, how does this work with zypper? Spack is totally independent of zypper. When you install something with the spack provided by the openSUSE package, everything is built and installed locally for the user under the directory ~/spack.

You have the option of building all the libraries required by the spack recipe or to use some of the libraries already installed on your openSUSE system.

While spack can be used directly after a git clone, it was package to give users the possibility of having it better integrated with openSUSE. After installation, spack will look for all the libraries used in your system and will create a file /etc/spack/packages.yaml

This step takes a bit of time, and you have the option of avoiding it if you create a file /etc/spack/no_rpm_trigger in your system before installing spack.

How to use spack

Installing spack is very easy, just type:

# zypper install spack

spack will pull a few packages widely used, however is a good idea to install a few more packages used by the spack recipes:

# zypper install patch pcre2-devel gcc-c++

If everything went fine, just typing spack, you’ll get a list of subcommands. You can get a list of the available spack recipes with:

$ spack list

And building and installing a package is straightforward:

$ spack install fdupes

Output will be something like this:

ana@localhost:~> spack install fdupes
==> Warning: Missing a source id for ncurses@6.1.20180317
[+] /usr (external ncurses-6.1.20180317-c4tkkuqm2rejq5ecbotrezyowmtinhtm)
==> Installing fdupes-2.1.2-erz3orzx7gedujr4nckkgtwgzqruf7cs
==> No binary for fdupes-2.1.2-erz3orzx7gedujr4nckkgtwgzqruf7cs found: installing from source
==> Using cached archive: /var/tmp/ana/spack-cache/_source-cache/archive/cd/cd5cb53b6d898cf20f19b57b81114a5b263cc1149cd0da3104578b083b2837bd.tar.gz
==> fdupes: Executing phase: 'autoreconf'
==> fdupes: Executing phase: 'configure'
==> fdupes: Executing phase: 'build'
==> fdupes: Executing phase: 'install'
[+] /home/ana/spack/packages/linux-opensuse_leap15-skylake/gcc-7.5.0/fdupes-2.1.2-erz3orzx7gedujr4nckkgtwgzqruf7cs

Spack will create and install all the files under ~/spack. There will be two directories:

• modules containing the module files to be used with environment-modules or lmod
• packages containing

Using the module files with lmod requires updating MODULEPATH like this:

$ export MODULEPATH=$MODULEPATH:~/spack/modules/linux-opensuse_leap15-skylake
$ module available

The second command will show the modules available and it should list all the modules produced by spack in addition to the ones already available in the system. Check the exact path after ~spack to be used in your system.

These modules can be only used by the user who created them. There is the possibility of having all the users from the system able to access and use the module files. For this, the user who builds the packages, must be able to write a global spack directory under /usr/lib/spack/. This can only be done if the user belongs to the group spack. You can add the user to this group with the following command:

# usermod -a -G spack <user_login>

then change the setting for install_tree: to the global spack directory in the configuration ~/.spack/config.yaml for this user.

Finally, an important note. Tumbleweed is a rolling release, do not be surprised if a recipe that works perfectly today doesn’t work in two weeks!

This is a first integration of spack in openSUSE. We aim to improve with your feedback and expand its usage in openSUSE in this wiki page.

In an effort to tone down my Facebook posts, I've looked into ways how to leverage the amazing Apostrophe app for writing simple markdown posts.

Due to github integration and general availability I've settled with, sigh, Jekyll, abandoning the even more obscure Middleman. Thanks to toolbox and rvm, the version dependency hell might be manageable, but I'm mainly hoping to just rely on github to do all the heavylifting, while I rely on Apostrophone. We'll see how it goes.

The one downside of my hacky middleman setup is that I will need to manually port those blog posts over as it's a mess. A lot of it is related to image and video links and some rb -> md. Many of the really old posts references images on long gone resources (primates.ximian.com?) and most just have broken links. I've started recovering some of the old gems), but I'm definitely only going to resurrect a few.

The main drive behind this futile attempt to post on a blog is to curate my own photos and articles myself. It is very backwards, but the ad algorithms that control all the social networks really make me mad that people, who actively try to follow someone's work or thoughts, are spoon fed with other things, but what they explicitly selected as of importance to them is sometimes totally hidden. So there, fellow RSS readers, I'm back.

Dear Tumbleweed users and hackers,

This week felt like I was fighting with OBS and openQA, and packages breaking Tumbleweed. This also shows in the number of released snapshots: ‘only’ 3. But there was a huge gap between 0121 (reviewer last week) and 0126 (first published snapshot this week). But I’m sure you all prefer longer gaps, but working snapshots. The longer the gap, the more packages are in there, so the total net change remains the same. This wee, we released 0126, 0127, and 0128.

The main changes included:

• Automake 1.16.3
• findutils 4.8.0
• Linux kernel 5.10.9
• libvirt 7.0.0
• Sudo 1.9.5p2 (CVE-2021-3156)

Plenty of submissions are being tested in the Staging projects – almost all of them are filled. The main upcoming changes will be:

• Mozilla Firefox 85.0
• Linux kernel 5.10.11
• util-linux 2.36.1
• Rust 1.49.0
• More work on python-rpm-macros, used for multiple python flavors (aka python singlespec)
• This will come together with python 3.8.7
• Postfix: change the default database format to lmdb, migrating away from BerkeleyDB (3rd attempt, previous two were reverted)
• Bison 3.7.5
• Firewalld 0.9.3
• Pulseaudio 14.2
• Bind 9.16.11: changed protection of/against “named” from chroot jail to systemd protection. This obsoletes subpackage named-chrootenv.
• KDE Plasma 5.21: currently 5.20.90 being tested
• openssl 1.1.1i, based on centralized crypto-policies package

Simple customization of the the GRUB 2 menu on openSUSE can be quickly done without any additional software.

GRUB stands for GRand Unified Bootloader. It was developed by Erich Boleyn in 1995 under the GNU Project and released under the GPLv3 license. Its current version is 2, that is why it is often written as GRUB 2.

GRUB is a bootloader which is the piece of software that a computer reads when booting up to know the location of the operating system.

In order to change the boot options and Kernel parameters, open YaST and go to System > Boot Loader.

More advanced customization can be done by editing the /etc/default/grub file. However, one needs to proceed with caution as a broken config can prevent your computer from booting up.

The /etc/default/grub is well documented. I suggest that you follow the in-line comments when modifying values, rather than relying on bits and pieces of info from the internet. The first line in the file reminds the user to execute grub2-mkconfig -o /boot/grub2/grub.cfg after making changes to the file. Always remember to run after making changes.

Now, look at the bottom of the file:

# GRUB_INIT_TUNE="480 440 1"
GRUB_BACKGROUND=
GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt
SUSE_BTRFS_SNAPSHOT_BOOTING="true"
GRUB_DISABLE_OS_PROBER="false"
GRUB_ENABLE_CRYPTODISK="n"
GRUB_CMDLINE_XEN_DEFAULT="vga=gfx-1024x768x16"

These are pretty much everything you will need to make a fancy GRUB menu. Note that the above configuration is taken from openSUSE Leap 15.2. If you are using another Linux distribution, they may be different.

You can specify a background image for GRUB. The image must be .png, .tga, .jpg, or .jpeg and it will be scaled if necessary. The image should be in a location where GRUB can read. I suggest you put the image in the /boot/grub2/themes/openSUSE folder for now. You could also add the GRUB_DISTRIBUTOR key to provide a custom name to the distribution, like to say openSUSE Leap is rock-solid!. 😉

# GRUB_INIT_TUNE="480 440 1"
GRUB_BACKGROUND=/boot/grub2/themes/openSUSE/blue-background.png
GRUB_DISTRIBUTOR='openSUSE Leap is rock-solid!'
#GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt
SUSE_BTRFS_SNAPSHOT_BOOTING="true"
GRUB_DISABLE_OS_PROBER="false"
GRUB_ENABLE_CRYPTODISK="n"
GRUB_CMDLINE_XEN_DEFAULT="vga=gfx-1024x768x16"

Notice that I commented the GRUB_THEME key to avoid it overwriting the change. Lastly, we run grub2-mkconfig to re-build the GRUB configuration.

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Reboot the machine & we should now see the blue background image that we specified.

You can also edit the openSUSE GRUB theme specified by editing the /boot/grub2/themes/openSUSE/theme.txt file and experiment further with GRUB theming.

The GNU GRUB official manual can help you better understand the theme file format.

Read more on the getting nice background images.

I tweeted about a blog post which I published on opensuse.mu, explaining how I configured the GNOME desktop theme Yaru (by the Ubuntu community) on my openSUSE Tumbleweed machine. The tweet got a lot of reaction, not just for the blog post or cool Yaru theme but also for the nice wallpaper showing penguins using a computer.

I got a question whether the wallpaper was freely available. The answer is yes. The wallpaper was released, among many others, by Digital Ocean in 2016.

You can head to imgur.com now and grab a cool wallpaper for your Linux desktop.

Three openSUSE Tumbleweed snapshots were released since the last update.

Several RubyGems were updated in the first two snapshots of the week and an update to sudo came in the most recent 20210127 snapshot.

A 10-year-old Common Vulnerabilities and Exposures that allowed root-level access was fixed with the update to sudo 1.9.5p2. Patches for CVE-2021-3156 were also backported in maintenance updates for openSUSE Leap. A minor version update of virtualbox to 6.1.18 fixed some nested virtualization hangs when executing symmetric multiprocessing with nested-guests under certain conditions on Intel hosts. An update was made to jhead, which is a command-line tool for displaying and manipulating exif header data in jpeg images; the 3.04 version removed an unnecessary warning with some types of GPS data and fixed a few bugs, including one bug that did not clear exif information when processing images. Some buttons were disabled in the update of yast2-network 4.3.41, which also added basic support for writing the network configuration to the NetworkManager backend.

New features from the update of libvirt 7.0.0 arrived in snapshot 20210126. The new version allows control of the qcow2 metadata cache for qemu. Another qemu improvement was the reporting of guest disks informations in virDomainGetGuestInfo; libvirt is now able to report disks and filesystems from the guest’s perspective using guest agent 5.3.0 or newer. The Linux Kernel 5.10.9 updated in the snapshot as well. A few updates were made for the i915 graphics drivers including allowing a sysadmin to override security mitigations for digital rights management. Skopeo, which is a command line utility for container images and image repositories, updated the vendor of containers and integrated tests for the syncing of the k8s.gcr.io directory. Other packages to arrive in the snapshot wree ncurses, xen, email client mutt 2.0.5 and text rendering library pango 1.48.1. A few RubyGems arrived in the snapshot; rubygem-parser 3.0.0.0, rubygem-rspec 3.10.0 and rubygem-rubocop 1.8.1 were among the RubyGems packages to arrive in this snapshot.

The majority of the gem packages arrived in snapshot 20210121. The entire snapshot was filled with more than 40 plus RubyGems updates. Notable packages to update were Ruby’s logging layer rubygem-fluentd 1.12.0, major version updates of rubygem-webpacker 5.2.1 and rubygem-liquid 5.0.0, and rubygem-js-routes 1.4.14. Only four other packages were updated. Those updates were xapps 2.0.6, gstreamer-devtools 1.18.3, gstreamer-editing-services 1.18.3 and python-gst 1.18.3.

As usual, we keep our infrastructure up-to-date. While this is easy for the base system ('zypper patch', you know? ;-) most of the applications need special handling. Normally, we package them as well in our OBS repositories. But this often means that we need to maintain them on our own. At least: packaging them allows us to track them easily and integrates them in the normal workflow. All we have to do to keep them updated on the production machines is a 'zypper up' (which updates all packages with higher version and/or release number - while a 'zypper patch' only updates packages, which have an official patchinfo with them).

Upgrading Matomo from version 3.14.1 to 4.1.1 was not that easy: simply replacing the files in the package was not enough. Upstream changed so much in the database structure, that the standard calls in the post installation script (which normally update the database as well during package update) were just not enough. As this is (hopefully) a one-time effort, we run some steps manually from the commandline, which took ~20hours. After that, our DB was updated, cleaned up and ready to go again.

Summary: Being an openSUSE hero includes not only being an infrastructure Guru with automation and scripting skills. Often enough, you need some packaging expertise as well. ...and sometimes even this is not enough!