A recent email thread about “Why isn’t the 5.10 stable kernel listed as supported for 6 years yet!” on the linux-kernel mailing list ended up generating a bunch of direct emails to me asking what could different companies and individuals due to help out. What exactly was I looking for here?

Instead of having to respond to private emails with the same information over and over, I figured it was better to just put it here so that everyone can see what exactly I am expecting with regards to support in order to be able to maintain a kernel for longer than 2 years:

The second session of the openSUSE Project’s meetup regarding the End of the Year Survey Results on Jan. 30 led to some changes with regard to future surveys and contributors are looking to enhance outreach.

View Meeting Minutes

The two-hour meetup took place on openSUSE’s Jitsi instance and several community members around the globe provided input on the results and how to improve the project’s diversity as well as global use.

The group spent time discussing the projects’ weaknesses and strengths based on the survey results and commonly understood areas members hope to improve.

The previous meetup session laid some groundwork with the introduction of monthly web development sprints to address feedback provided by attendees in both sessions. One of the areas mentioned were highlighting communication entry points so new users can be welcomed to the community and introduced to the project’s distributions and tools.

Attendees also discussed how to address users switching to openSUSE from Windows or other Linux distributions like Ubuntu, Debian, CentOS, Arch, etc. The meetup also included a discussion about marketing strategies and ways to increase visibility for the projects’ projects and distributions. A marketing workgroup for the release of openSUSE Leap 15.3 was an idea brought up in the discussion and is moving forward with establishing a team.

Another topic resulted in a decision to extend future EOY surveys to be run for 30 days, which will run from mid-November to mid-December, rather than being open for two weeks like last year’s survey.

The attendees continued the discussion in the openSUSE Bar, which currently doesn’t have it’s opening hours posted.

The main openSUSE repository does not feature the latest version of VirtualBox. To obtain the latest version of the software, one may use VirtualBox's own repo for openSUSE. Details are available on the virtualbox.org project website. However, I am reproducing them here for a quick reference & also to address some quirks that you might encounter if you simply add the repo & install VirtualBox.

Step 1

We add the VirtualBox repository by creating the /etc/zypp/repos.d/virtualbox.repo file with the below content.

[virtualbox]
name=VirtualBox for openSUSE 15.0 - $basearch
enabled=1
autorefresh=1
baseurl=http://download.virtualbox.org/virtualbox/rpm/opensuse/15.0/$basearch
priority=120
gpgcheck=1
gpgkey=https://www.virtualbox.org/download/oracle_vbox.asc
keeppackages=0

VirtualBox does not have a separate repository for Leap 15.1, 15.2, etc. The repo for Leap 15.0 should work just fine.

Step 2

Refresh the repositories and search for the latest version of VirtualBox.

sudo zypper ref && zypper se virtualbox

The output of the command is shown below.

S | Name                           | Summary                                          | Type
--+--------------------------------+--------------------------------------------------+-----------
  | VirtualBox-5.2                 | Oracle VM VirtualBox                             | package
  | VirtualBox-6.0                 | Oracle VM VirtualBox                             | package
  | VirtualBox-6.1                 | Oracle VM VirtualBox                             | package
  | python3-virtualbox             | Python bindings for virtualbox                   | package
  | virtualbox                     | VirtualBox is an Emulator                        | package
  | virtualbox                     | VirtualBox is an Emulator                        | srcpackage
  | virtualbox-devel               | Devel files for virtualbox                       | package
  | virtualbox-guest-desktop-icons | Icons for guest desktop files                    | package
  | virtualbox-guest-source        | Source files for virtualbox guest kernel modules | package
  | virtualbox-guest-tools         | VirtualBox guest tools                           | package
  | virtualbox-guest-x11           | VirtualBox X11 drivers for mouse and video       | package
  | virtualbox-host-source         | Source files for virtualbox host kernel modules  | package
  | virtualbox-kmp                 | Kernel modules for VirtualBox                    | srcpackage
  | virtualbox-kmp-default         | Kernel modules for VirtualBox                    | package
  | virtualbox-kmp-preempt         | Kernel modules for VirtualBox                    | package
  | virtualbox-qt                  | Qt GUI part for virtualbox                       | package
  | virtualbox-vnc                 | VNC desktop sharing                              | package
  | virtualbox-websrv              | WebService GUI part for virtualbox               | package

Step 3

We pick the latest version, in this case VirtualBox 6.1, and install it as follows:

sudo zypper in gcc kernel-default-devel VirtualBox-6.1

Notice that we installed the GCC compiler and the Kernel development files which will be required by VirtualBox to compile and install driver modules into the system kernel. Unless these driver modules are installed we won't be able to create virtual machines or we might create the virtual machines but not be able to start them.

Once all commands have completed successfully, we can run VirtualBox 6.1.

If you would like to expertiment on openSUSE using VirtualBox, you should know that you can grab the openSUSE Leap 15.2, Tumbleweed and MicroOS images for VirtualBox.

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.

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