Explaining how to differentiate bind mounts on btrfs subvolumes

I still can't get over the magic coming out of the minuscule sensor at night.

I wrote an article for Front Page Linux about the wonders of the best webcam application for use on Desktop Linux. Rather than publish it here where a dozen or so people will skip through the front door, I decided to put in someplace that receives a fantastic stream of traffic. This is a great … Continue reading Webcamoid | The Best Webcam App For The Linux Desktop →

Dear Tumbleweed users and hackers,

Apologies for missing the review of the week 2021/05 to be sent out in time. But as you already know from the past, that does not mean the information is being lost. I’ll just give you a review of the last two weeks instead. For Tumbleweed, this means we have seen 8 snapshots being published in those two weeks (0130, 0131, 0202, 0203, 0205, 0208, 0209, and 0210).

The main changes included:

• Mozilla Firefox 85.0
• Rust 1.49.0
• Python 3.8.7
• Bind 9.16.11: changed protection of/against “named” from chroot jail to systemd protection. This obsolete the subpackage named-chrootenv.
• Linux kernel 5.10.12
• Pulseaudio 14.2
• Pipewire 0.3.20: pipewire is growing to become a replacement for PulseAudio
• util-linux 2.36.1
• Mesa 20.3.4
• GCC 11 is now used to provide the base libraries, like libgcc_s1. GCC 10 is still used to compile the distribution
• KDE Applications 20.12.2
• Systemd 246.10

The next snapshot to be published (20210211 or newer, depending on QA results) will be based on glibc 2.33. As is usual with a glibc upgrade, I triggered a full rebuild of the repository. So the next snapshot coming out after today will be big (in bytes)

These changes are currently piled up for future tumbleweed snapshots:

• glibc 2.33 (snapshot 0211+)
• Postfix: change the default database format to lmdb, migrating away from BerkeleyDB
• Linux kernel 5.10.14 and later
• Libreoffice 7.1
• KDE Plasma 5.21: currently 5.20.90 being tested
• openssl 1.1.1i, based on centralized crypto-policies package
• Use GCC 11 as default compiler (Staging:Gcc7; we should finally rename that staging :P)

A minor version update of systemd and KDE’s Applications 20.12.2 were releases in openSUSE Tumbleweed this week.

Several other package were updated over the course of four snapshots like Wireshark, Mesa, ClamAV, Inkscape and GNU Compiler Collection.

Snapshot 20210210 updated just three packages in the last 24 hours. Web caching proxy squid had a 4.14 update that fixed a couple regressions and corrected some Web Cache Communication Protocol Security info. The two other package updates were for PyPI with python-scipy updating to 1.6.0 and python-zope.interface updating to 5.2.0, which added support for Python 3.9.

The open source antivirus package ClamAV updated to version 0.103.1 in snapshot 20210209. The new version 0.103.1 added a new scan option to alert on broken media (graphics) file formats. The feature mitigates the risk of malformed media files intended to exploit vulnerabilities in other software. The version also fixed an issue where the freshclam database validation didn’t work correctly when run in daemon mode on Linux. The patterns-xfce package cleaned up some weak dependencies in its 20210209 update. A simple SSH multi-factor authentication was implemented with the update of the remote desktop client remmina in version 1.4.11; while not finished, a capability to load Python plugins was added. Other packages updated in the snapshot were libp11 0.4.11, video editor pitivi 2021.01, and xfce4-taskmanager 1.4.1.

KDE Applications 20.12.2 arrived in snapshot 20210208. KDE’s file manager Dolphin changed the copy location shortcut so it does not conflict with the Konsole panel. The diagram program umbrello fixed a crash on exit with the widget selected in the diagram, and PDF Okular fixed an unexpected file type being the default upon opening in non-Plasma desktops. The 246.10 version of systemd sends journald logs to kmsg again. A new npm diff command was added with nodejs15 15.8.0 and there was an introduction of an X509Certificate Application Programming Interface. Some patches were added for an update to ncurses and small executable busybox added several new features in its 1.33.0 version, which also fixed unicode characters in the prompt. Other packages updated in the snapshot were libgcrypt 1.9.1, dracut, line-oriented text editor ed 1.17 and search engine library xapian-core 1.4.18.

Some shortcut adjustments were made to inkscape in snapshot 20210205; the new 1.0.2 version allows the deactivation of zooming with the middle mouse button click (pressing scroll wheel). New packages inherits from GCC 10 were made to create GCC 11; more interesting features are expected to come in future versions of GCC 11. Some ppc64 patches were removed in the 20.3.4 update of Mesa and Mesa-drivers. Several more PyPI packages were updated in the snapshot that began the week. Some debugging updates were made available to text editor vim with version 8.2.2411 and Wireshark 3.4.3 took care of two Common Vulnerabilities and Exposure. One of the Wireshark CVEs allowed it to consume excessive CPU resources by injecting a malformed packet onto the wire or by convincing someone to read a malformed packet-trace file.

We’re delighted to announce a new project in the openSUSE Project family called openSUSE Step. openSUSE Step is a community effort to rebuild SUSE Linux Enterprise (SLE) from the released SLE sources packages. This is done openly in the openSUSE instance of the Open Build Service (OBS) with the intention to stay fully binary compatible and to be as closely source-compatible as possible with SLE.

Why openSUSE Step?

openSUSE Leap 15.3 inherits its base from SLE 15 SP3. On aarch64, powerpc64, and x86_64, openSUSE directly uses binary packages from the enterprise side. In addition, openSUSE also supports architectures that SLE does not provide, such as armv7hl and 32-bit x86, which is relatively popular with openSUSE users, according to results from a recent community survey. For those, we now build fully compatible binary packages from the published SLE sources in OBS.

openSUSE Step is not intended to be an end user distribution. It does not replace, or provide an alternative to openSUSE Leap. Step is an intermediate building block (“step”) to enable derived community distributions like openSUSE Leap or other community derivatives.

What is currently in openSUSE Step?

There are currently four versions defined and existing in parallel: openSUSE Step 15, 15-SP1, 15-SP2, and 15-SP3. It is hosted under the openSUSE project namespace in OBS and uses the published sources from SLE plus minimal modifications needed for being able to build them from sources while incorporating the published maintenance updates.

openSUSE Step currently covers i586, x86_64, and armv7hl. More architectures, such as RISC-V, can be added based on contributor interest and resource capacities.

How is this related to openSUSE Leap?

With the “Closing the Leap Gap” project moving forward, openSUSE Leap will become a layered cake of binary packages from three different origins:

• The pool of binary packages directly copied from SLE,
• A small set of currently around 50 packages that provide an openSUSE branding overlay to these SLE packages,
• An openSUSE backports overlay, which provides a wealth of applications and libraries that everyone likes to use in openSUSE Leap, and that are not available from SLE

Above: openSUSE Leap with openSUSE Step architecture comparison

openSUSE Step provides an alternative for Leap architectures that have no SLE equivalent like 32-bit architectures. The other two groups of originated packages will be the same like for the other architectures.

In addition to that, openSUSE Step provides everyone access to build log files, and the ability to have “a build validated” project repository of SLE for community customization, which serves as a collaboration space for related projects that would like to derive from SLE package sources.

Leap transitioned to a new way of building Leap releases in the fall of 2020 through a prototype project called Jump. The Jump prototype was used as a proof of concept, but no longer exists; it did prove to work at building a distribution and bringing the code streams of both openSUSE Leap and SLE closer together. The proof of concept was implemented for building the release of Leap 15.3.

How is this related to openSUSE Tumbleweed ?

It is not related. openSUSE Tumbleweed is a rolling release distribution entirely managed and built by the openSUSE community with a strong focus on continuously integrating new tested upstream releases while preserving a high-quality rolling update without major regressions. Tumbleweed is an origin for the next major SLE release. There is no direct general relationship between Tumbleweed and maintained SLE releases.

Does openSUSE Step allow community contributions?

Yes, community contributions are welcome if they improve buildability from sources and do not modify binary compatibility in any way. The mission of the Step distribution is to be fully compatible and for all practical purposes an equivalent drop in for SLE.

For quality validation purposes, Step x86_64 architecture will also be built and tested in openQA, but it will not be delivered into openSUSE Leap.

How can I contact the openSUSE Step team?

The openSUSE Step team is hanging out on Freenode in the #opensuse-step channel. Issues can be reported in GitHub under https://github.com/openSUSE/step/issues.

When updating to the latest etherpad-lite version 1.8.7 (including quite some bug fixes), we also revisuted the currently installed plugins and updated them to their latest version as well, as usual.

To get some impressions about the usage of our Etherpad instance, we also enabled the ether-o-meter plugin now, which is now producing some nice live graphs and statistics here: https://etherpad.opensuse.org/metrics

We also enabled some additional styles now and hope this makes the usage of Etherpad even more fun and productive for you. If you want to have some more modules enabled (or just want to say "hello"), feel free to contact us! Either via an Email to admin@opensuse.org or by reaching out for us at irc.opensuse.org channel #opensuse-admin.

In this blog post we are going to give you the easiest introduction to what needles are and how you can use them. While there are many good talks and documentation on needles out there, it took me longer than it should have to find a easy-to-use and easy-to-understand introduction into this topic alone. This blog post should fill this gap.

It’s time for more development news from the YaST Team. In this occasion, most of the work has gone into improving features already implemented in previous sprints and, thus, presented in former blog posts. That includes:

• Improvements when writing wireless security settings for NetworkManager
• Fixes in the new management of hibernation
• Possibility to tweak the I/O device autoconfiguration in the installed system
• Usability improvements regarding nested items in the table widget
• Better LibYUI packaging including a revamped CMake build system
• Enhancements in the YaST Autoinstallation module regarding partitioning
• Many other improvements and fixes here and there

As you surely remember, in the previous sprint we added support for writing basic NetworkManager configuration during installation. But it was quite limited regarding wireless, so it only was capable to translate WPA-PSAK and open wireless configuration. During this sprint, we enhanced the NetworkManager config writers to support the same wireless setups that are currently supported by wicked (WEP, WPA-EAP…). In addition, some UI problems were found and fixed.

In the previous sprint we also improved the hibernation support by tuning the scenarios in which YaST adds the resume= parameter to the bootloader configuration. While testing that improved behavior, some problems were detected both by ourselves and by the awesome QA team at SUSE. Now all those inconvenients are fixed: the bootloader proposal is properly recalculated when needed, the resume parameter is not longer added for small swap devices and we improved the detection of virtual setups in which traditional hibernation is not wanted.

But not all the features we polished during this sprint are so recent. For several months, we have been describing the different steps in the implementation of support in YaST for I/O devices auto-configuration on s390 mainframes. The latest reference was on our blog post of sprint 105 (time flies!). But we still had one more thing in our TO-DO list and, since we recently had to modify the YaST2 Tune module to remove some obsolete settings, we decided to take the opportunity and also add the I/O device autoconfig checkbox to that module. See details and screenshots at this pull request.

We also improved the usability of our most recent LibYUI feature. In the YaST partitioner, which is so far the only application using the new feature to have nested rows in a table, the [Space] key did not only open or close tree branches in the ncurses text-mode interface. It also sent an “Activated” event (the counterpart of double-clicking an item in the Qt graphical user interface), resulting in a quite confusing behavior. See the fix for more detailed information.

And talking about LibYUI, we also decided it was time to tackle one big problem that we have been dragging for too long. The structure of our development repositories and our over-complicated CMake build environment was making too hard to add new features to LibYUI without risking breakage in the distributions. Every change implied a lot of extra synchronization work, which also was an obstacle for external contributions and maintaners of additional plugins and backends. After several weeks of work, we have now walked the first step out of that mess with the new CMake build system for LibYUI

And there is no YaST Team sprint without some news about AutoYaST. This time we have improved the part of the YaST Autoinstallation module that can be used to create and tweak the <partitioning> section of the AutoYaST profile. Apart from several small fixes (like improved visualization or fixes in the fstopt field), it’s now possible to manage <drive> sections to describe NFS and tmpfs file systems.

As usual, there would be much more to report like usability improvements and speedups in YaST Network, fixes in hwinfo or important updates in the documentation… but we need to go back to coding at some point!

So see you again in a couple of weeks with more news about YaST and, if everything works as expected, some reflections about the long-term future. Stay safe and have a lot of fun!

It is still strange for me to see that Microsoft is building software for Linux. Frankly, they are a bit hit and miss on the quality but I think that might actually be a general Microsoft trait. I am just grateful that they are putting time, effort and resources to Linux. Even if their applications … Continue reading Microsoft Teams on openSUSE →