Four openSUSE Tumbleweed snapshots were released so far this week.

The snapshots updated KDE Gear 21.04.1, GTK 4, Btrfs, postgresql, sudo and more.

Snapshot 20210519 updated the postgresql 13.3 package and addressed three Common Vulnerabilities and Exposures; one of those included the mishandling of a target list and another prevented integer overflows in array calculations. Text editor vim 8.2.2850 fixed a few crashes and the 0.15.0 update of the open remote computing solution SPICE provided some behavior changes and compatibility with OpenSSL. Improved rendering and a font settings fallback for Wayland were made with the gtk4 4.2.1 update. GNOME’s Tetris like game quadrapassel has the 40.1 major version, which updated translations and pressing return now restarts a game. Another major version to update in the snapshot was python-incremental 21.3.0, which is PEP 440-compliant.

Multiple fixes were made in the update of KDE Gear 21.04.1 in snapshot 20210517. The KDE Gear 21.04.1 packages updated video editor Kdenlive, which fixed rendering presets; text editor Kate fixed a possible leak; and diagram program umbrello made some cosmetic and error detection improvements. The update also restored compatibility with ffmpeg 3 for ffmpegthumbs. Other packages to update in the snapshot were rubygem-rubocop 1.14.0, urlscan 0.9.6 and re2c 2.1.1, which added GitHub Actions Continuous Integration for Linux, macOS and Windows.

Both Btrfs and sudo updated in the 20210515 snapshot. The 1.9.7 version of sudo fixed a bug introduced in the previous release that caused sudo -V to report a usage error. Sudo now requires autoconf 2.70 or higher to regenerate the configure script. Btrfs updated from version 5.11 to 5.12.1 and fixed missing symbols in libbtrfs for builds; there was also a fix for symlink paths for CI support scripts for the file system. The 0.184 update for elfutils creates an empty 000 permission file in the cache if a query for a file failed with 404. The python-kiwi 9.23.28 package added support for UEFI on Debian-based distros. Other packages to update in the snapshot were shell utility hdparm 9.62, highlight 4.1 and libstorage-ng 4.4.6.

The 20210514 snapshot started off the week and it updated the Linux Kernel to 5.12.3. Multiple bus updates were made and a kernel panic for disk encryption ecryptfs was made. An update of mousepad 0.5.5 for Xfce added various plugin support and added a .desktop file to appear in settings. Xfce also had several critical fixes for xfce4-panel with the 4.16.3 update and thunar 4.16.8 updated translations and fixed an error when opening the Edit menu. Remote desktop client remmina 1.4.16 fixed a data path and a few RubyGems packages were updated.

I avoid fiddling with batteries in the house, so I soldered up a 4S Li-Ion pack in the garden and tested a high speed cruise in the usual spot. Jammed a bit on my elektron boxes and here I present a super long test flight that's now almost watchable.

While focused on the openSUSE Innovator initiative as an openSUSE member and official Intel oneAPI innovator, I tested the RealSenseID device on openSUSE Leap 15.1, 15.2, 15.3 RC and Tumbleweed. With all the work, we made available in the SDB an article on how to install this device on the openSUSE platform. More information can be found at https://en.opensuse.org/SDB:Install_RealSenseID.

Intel RealSense ID combines an active depth sensor with a specialized neural network designed to deliver an intuitive, secure and accurate facial authentication solution that adapts over time. This solution offers user privacy and is activated by user awareness. Built-in anti spoofing technology protects against attacks using photographs, videos or masks.

Intel RealSense ID is a natural solution simplifying secure entry for everyone, everywhere. Supports children to tall adults and designed for Smart Locks, Access Control, PoS, ATMs, and Kiosks in openSUSE (of course).

For more information, visit : https://github.com/IntelRealSense/RealSenseID

Both openSUSE Leap 15.3 and SUSE Enterprise Linux 15 SP3 are already in the oven and almost ready to be tasted. But although they smell delicious, the openSUSE volunteers and the great SUSE QA team never give up in challenging our beloved distributions to find the corner cases that need more polishing. Since we want to make sure each possible problem have a solution or a documented workaround at the release date, the YaST Team invested quite some time during the last sprint investigating and solving some problems related to AutoYaST, system migration, registration and other tricky areas.

But we also found time to work on more blog-friendly topics like:

• Improvements in the AutoYaST functionality to configure questions during the installation
• Better handling of path names in Arabic and other right-to-left languages
• Progress in the refactoring of YaST Users
• Possibility of installing with neither NetworkManager or wicked

Let’s dive into the details.

One of the many features offered by AutoYaST is the possibility of specifying a so-called ask-list, which lets the user decide the values of some parts of the AutoYaST profile during the installation. That allows to fine-tune the level of flexibility and interactivity, with a process that is highly automated but still customizable on the fly. During this sprint we basically rewrote the whole feature to make it more robust and powerful, while still being fully backwards-compatible. See more details in the corresponding pull request including technical details, before-and-after screenshots and a link to the official documentation that explains how to use this reworked feature.

And talking about before-and-after screenshots, let’s see if you can spot the differences in the following image.

Exactly. In the upper part, the right-to-left orientation of the Arabic writing mangles the mount points and the device names, moving the initial slash of paths like /dev/vda to the end. This is just one of the many interesting software development problems you don’t normally think about, but that makes life as a YaST developer a constant learning experience. If you want to know more about Unicode directional formatting characters and how we solved the problem, check this pull request at the yast2-storage-ng repository.

And talking about challenges and learning, sure you remember we are in the middle of a whole rewrite of the YaST mechanisms to manage local users. We already have a new version of the installer that works perfectly using the new code, including the creation of brand new users and also importing them from a previous installation. We are now integrating that new code into AutoYaST and we will be ready soon to discuss the best procedure and timing to introduce the revamped yast2-users into openSUSE Tumbleweed in a way that it brings all the benefits of the rewrite to our users without any disruptive change in the surface.

Last but not least, we would like to mention a new feature we already submitted to the Tumbleweed installer in search for feedback from you, our beloved users. :wink: In a nutshell, it offers the possibility to install the distribution without NetworkManager or wicked, for those users that want to manually configure an alternative network manager (like systemd-networkd) or that simply want a network-less operating system. Please check the corresponding pull request and reach out to us to tell us what do you think. Remember you can do that at the yast-devel and factory mailing lists at openSUSE, at the #yast channel at Freenode IRC or directly commenting on GitHub.

While waiting for your input, we will keep working in polishing the upcoming releases and bringing new features into Tumbleweed. Stay safe and have a lot of fun!

Nate Finch had a nice blog post on error flags recently, and it caused me to think about error handling in my own greenfield Go project at work.

Much of the Go software I write follows a common pattern: an HTTP JSON API fronting some business logic, backed by a data store of some sort. When an error occurs, I typically want to present a context-aware HTTP status code and an a JSON payload containing an error message. I want to avoid 400 Bad Request and 500 Internal Server Errors whenever possible, and I also don’t want to expose internal implementation details or inadvertently leak information to API consumers.

I’d like to share the pattern I’ve settled on for this type of application.

An API-safe error interface

First, I define a new interface that will be used throughout the application for exposing “safe” errors through the API:

package app

type APIError interface {
    // APIError returns an HTTP status code and an API-safe error message.
    APIError() (int, string)
}

Common sentinel errors

In practice, most of the time there are a limited set of errors that I want to return through the API. Things like a 401 Unauthorized for a missing or invalid API token, or a 404 Not Found when referring to a resource that doesn’t exist in the data store. For these I create a create a private struct that implements APIError:

type sentinelAPIError struct {
    status int
    msg    string
}

func (e sentinelAPIError) Error() string {
    return e.msg
}

func (e sentinelAPIError) APIError() (int, string) {
    return e.status, e.msg
}

And then I publicly define common sentinel errors:

var (
    ErrAuth      = &sentinelAPIError{status: http.StatusUnauthorized, msg: "invalid token"}
    ErrNotFound  = &sentinelAPIError{status: http.StatusNotFound, msg: "not found"}
    ErrDuplicate = &sentinelAPIError{status: http.StatusBadRequest, msg: "duplicate"}
)

Wrapping sentinels

The sentinel errors provide a good foundation for reporting basic information through the API, but how can I associate real errors with them? ErrNoRows from the database/sql package is never going to implement my APIError interface, but I can leverage the error wrapping functionality introduced in Go 1.13.

One of the lesser-known features of error wrapping is the ability to write a custom Is method on your own types. This is perhaps because the implementation is privately hidden within the errors package, and the package documentation doesn’t give much information about why you’d want to use it. But it’s a perfect fit for these sentinel errors.

First, I define a sentinel-wrapped error type:

type sentinelWrappedError struct {
    error
    sentinel *sentinelAPIError
}

func (e sentinelWrappedError) Is(err error) bool {
    return e.sentinel == err
}

func (e sentinelWrappedError) APIError() (int, string) {
    return e.sentinel.APIError()
}

This associates an error from elsewhere in the application with one of my predefined sentinel errors. A key thing to note here is that sentinelWrappedError embeds the original error, meaning its Error method returns the original error’s message, while implementing APIError with the sentinel’s API-safe message. The Is method allows for comparisons of these wrapping errors with the sentinel errors using errors.Is.

Then I need a public function to do the wrapping:

func WrapError(err error, sentinel *sentinelAPIError) error {
    return sentinelWrappedError{error: err, sentinel: sentinel}
}

(If you wanted to include additional context in the APIError, such as a resource name, this would be a good place to add it.)

When other parts of the application encounter an error, they wrap the error with one of the sentinel errors. For example, the database layer might have its own wrapError function that looks something like this:

package db

import "example.com/app"

func wrapError(err error) error {
    switch {
    case errors.Is(err, sql.ErrNoRows):
        return app.WrapError(err, app.ErrNotFound)
    case isMySQLError(err, codeDuplicate):
        return app.WrapError(err, app.ErrDuplicate)
    default:
        return err
    }
}

Because the wrapper implements Is against the sentinel, you can compare errors to sentinels regardless of what the original error is:

err := db.DoAThing()
switch {
case errors.Is(err, ErrNotFound):
    // do something specific for Not Found errors
case errors.Is(err, ErrDuplicate):
    // do something specific for Duplicate errors
}

Handling errors in the API

The final task is to handle these errors and send them safely back through the API. In my api package, I define a helper function that takes an error and serializes it to JSON:

package api

import "example.com/app"

func JSONHandleError(w http.ResponseWriter, err error) {
    var apiErr app.APIError
    if errors.As(err, &apiErr) {
        status, msg := apiErr.APIError()
        JSONError(w, status, msg)
    } else {
        JSONError(w, http.StatusInternalServerError, "internal error")
    }
}

(The elided JSONError function is the one responsible for setting the HTTP status code and serializing the JSON.)

Note that this function can take any error. If it’s not an APIError, it falls back to returning a 500 Internal Server Error. This makes it safe to pass unwrapped and unexpected errors without additional care.

Because sentinelWrappedError embeds the original error, you can also log any error you encounter and get the original error message. This can aid debugging.

An example

Here’s an example HTTP handler function that generates an error, logs it, and returns it to a caller.

package api

func exampleHandler(w http.ResponseWriter, r *http.Request) {
    // A contrived example that always throws an error.  Imagine this
    // is actually a function that calls into a data store.
    err := app.WrapError(fmt.Errorf("user ID %q not found", "archer"), app.ErrNotFound)
    if err != nil {
        log.Printf("exampleHandler: error fetching user: %v", err)
        JSONHandleError(w, err)
        return
    }

    // Happy path elided...
}

Hitting this endpoint will give you this HTTP response:

HTTP/1.1 404 Not Found
Content-Type: application/json

{"error": "not found"}

And send to your logs:

exampleHandler: error fetching user: user ID "archer" not found

If I had forgotten to call app.WrapError, the response instead would have been:

HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{"error": "internal error"}

But the message to the logs would have been the same.

Impact

Adopting this pattern for error handling has reduced the number of error types and scaffolding in my code – the same problems that Nate experienced before adopting his error flags scheme. It’s centralized the errors I expose to the user, reduced the work to expose appropriate and consistent error codes and messages to API consumers, and has an always-on safe fallback for unexpected errors or programming mistakes. I hope you can take inspiration to improve the error handling in your own code.

Dear Tumbleweed users and hackers,

First, I want to apologize to our Steam users for making their life harder this week than needed. I misjudged an openQA-reported issue as being a Steam packaging bug instead of realizing that it was in fact a Mesa packaging bug. This in turn made some of you receive scary messages from zypper. A bug for this had been filed in Bugzilla of course: https://bugzilla.opensuse.org/show_bug.cgi?id=1185933. A fixed Mesa package will be part of Snapshot 0514.

Other than that, I did not hear/read a lot of complaints regarding the six snapshots released during this week (0506, 0507, 0508, 0510, 0511, and 0512). The main changes included:

• GNOME 40.1
• KDE Plasma 5.21.5
• Mesa 21.1.0
• LibreOffice 7.1.3.2
• QEmu 6.0.0
• Virtualbox 6.1.22
• VLC 3.0.13
• icu 69.1
• Mozilla Firefox 88.0.1
• KDE Frameworks 5.82.0
• Linux kernel 5.12.2, kfence has been disabled. This allows the system to reach idle state easier again
• Python 3.8.10 (security and bug fixes)

The staging areas are currently filled with these major topics:

• NodeJS 15 will be removed
• Linux kernel 5.12.3
• KDE Gear 21.04.1
• Base filesystem layout changes: more base directories will change permission from 755 to 555
• Switch from go 1.15 to go 1.16: most packages fixed, the last failure in Staging:M is cilium
• GCC 11 as default compiler: Move from special-purpose Staging:Gcc7 to Staging:O (incl. openQA test coverage). There are a few more build failures to be addressed.
• UsrMerge: The current state is that we checked in all changes and are planning on actually doing the switch somewhen in the not too far future, likely together with the planned distro-rebuild for GCC 11

There were three openSUSE Tumbleweed snapshots released so far this week.

The snapshots updated Mozilla Thunderbird, Mozilla Firefox, Mesa, KDE Frameworks, glusterfs, php and several other packages.

The most recently released snapshot, 20210511, updated a little more than a handful of packages. There was one package update from KDE Frameworks 5.82.0 with plotting framework kplotting. The 5.12.2 Linux Kernel updated in the snapshot and brought a thermal sensor correction to the x86 thinkpad_acpi module and some fixes for Advanced Linux Sound Architecture USB audio. Another package update in the snapshot was hivex 1.3.20, which is a system for extracting the contents of the Windows Registry; the hivex version fixed a Common Vulnerabilities and Exposures that would allow an attacker to read memory beyond normal bounds or cause the program to crash.

Mesa 21.1.0 and a majority of the KDE Frameworks 5.82.0 packages updated in snapshot 20210510. The Mesa update added some patches and dropped vulkan_intel.h in /usr/include/vulkan/ but a decision was made to keep the directory empty. The update of KDE Frameworks 5.82.0 added new sidebar show and hide Breeze Icons. The KDBusAddons file was relicensed to LGPL-2.0 or later. Many fixes were made in the frameworks update, including a KTextEditor memory corruption fix and a couple fixes for dragging. The update of Mozilla Thunderbird 78.10.1 restored some previous behavior found in the 78.9.0 version. The fetchmail 6.4.19 update now properly reports option parsing errors. Tumbleweed skipped an entire major version of the of cluster file-system capable of scaling to several peta-bytes in its update of glusterfs from version 7.1 to 9.1; the new major version upgrade added support for 5K volumes, improved the rebalance of sparse files and it is now compiled with Link Time Optimization enabled by default. The full-featured implementation of the DNS protocol bind9 9.16.15, fixed a few CVEs including one that could lead to a RUNTIME_CHECK assertion failure. Also updated in the snapshots were ceph 16.2.3.26, chat client pidgin 2.14.4 and terminal multiplexer tmux 3.2.

The 20210508 snapshot updated Mozilla Firefox 88.0.1, which fixed a corruption of videos playing on Twitter or WebRTC calls on some Gen6 Intel graphics chipsets. A CVE involving web render components was also fixed with the open-source browser. An update in php7 7.4.19 reverted a fix that treated everything as PARAM_STR. Google’s library for parsing, formatting and validating international phone numbers libphonenumber updated to version 8.12.22, which updated carrier data and the geocoding data for Germany’s +49 and Mexico’s +52 calling codes. Other packages updated in the snapshot were hwdata 0.347, perl-CGI 4.52 and ibus-table 1.13.0.

A startup bringing personal workspaces in the cloud for students, workers, coders, and creators along with a Linux project for developers, system administrators and users are teaming up to extend the use of a secure desktop from any device, anywhere.

Shells and openSUSE Project have entered into a partnership to expand the use of Shells with the availability of openSUSE distributions on Shells’ private virtual desktop environment powered by cloud computing.

“This is a great way to give an openSUSE distribution a spin - without downloading or installing anything locally,” said Gerald Pfeifer, chairperson of the openSUSE Project. “And it’s a completely new way to use a feature rich, full fledged open source-based environment from your tablet or other device.”

Shells’ CEO Alex Lee couldn’t agree more.

“We’re thrilled with the images that have been created that are now available for our customers to choose from when setting up their Shells virtual desktop,” Lee said. “It’s been a pleasure collaborating with the openSUSE team for the past few months. Both of the openSUSE and Shells tech teams have put in a lot of hard work to drive this project to completion, and it is clearly evident in the end products.

“We are honored by the fact that the group at openSUSE selected this project to work on during their SUSE HackWeek,” Lee added.

Shells has multiple use cases and openSUSE distributions are just one of many other operating systems offered by Shells. With the partnership, openSUSE will be a member of Shells Affiliate Program. The two organizations are working closely on a way to allow users to trial the distribution and its desktop environments. Further extending this partnership, Shells has become an Emerald Sponsor of this year’s openSUSE Conference and Lee will give a keynote on June 18.

Developers can rapidly spin up multiple secure environments that are automatically backed up. Music producers can access production grade programs across devices to collaborate on the next hit.

The use of Shells by educators allows for remote learning on any device, which becomes affordable, less complex for students and the accessibility and learning with the many operating systems and tools add synergy to the classroom. Students across the world can easily access openSUSE distributions on whatever device that is available to them, whether that be at school, the library or at home.

“The openSUSE leadership team has always expressed the fact that it is important to have the right tool for the right job,” Pfeifer said. “openSUSE has a lot of powerful tools. Securely accessing openSUSE and its toolset from anywhere extends the power of the distribution to the device in someone’s pocket, to a smart TV, or VR browser of a user in an instant.”

A key member of the Shells tech team involved with the collaboration is Debian developer and former Purism Chief Technical Officer Zlatan Todoric.

“The Shells and openSUSE collaboration is one of those that we all enjoy in the FLOSS community,” Todoric said, who is currently serving at Shells’ Vice President of Technology. “Sharing knowledge, ideas, and helping each other to benefit the entire community is obviously what it is all about. openSUSE is a well known integrator and has vast experience in desktop and cloud environments, and having them as an option for our Shells cloud computers is a win-win solution for everyone. The collaboration will continue to expand even further as time goes on and I can already tell you that the openSUSE experience on Shells is going to be loved.”

Disclaimer: The initial go-live images are Tumbleweed images that make it easier to adjust as the distro changes. The release team is working toward having an openSUSE Leap image.

Get your openSUSE virtual desktop here.

Media Contacts:

Alex Lee Shells.com alex@shells.com

Douglas DeMaio openSUSE ddemaio@opensuse.org

I just recently discovered one of the hidden gems in the openQA WebUI: Show only failing tests in external results.

Developers of the openSUSE community are looking to utilize armv7l efforts in the context of openSUSE Step to evolve how openSUSE Leap and SUSE Linux Enterprise are developed together.

The Step effort was announced in February to open up and expand architecture enablement for future SUSE Linux Enterprise (SLE) releases.

Step is a community effort to rebuild SLE from the released sources packages in the openSUSE instance of the Open Build Service (OBS) with the intention to stay as compatible as possible with SLE. Just recently the project established armv7l in OBS as a Leap port.

“As the survey’s results showed, Leap still has lots of armv7 users,” said Guillaume Gardet, an arm developer and community contributor. “We listened to that feedback to address the potential use cases of people with armv7 and found a solution.”

Leap ports provide Leap for architectures not supported by SLE, such as 32-bit architectures. Step armv7l together with Backports forms the Leap port for armv7l.

Images can be found at http://download.opensuse.org/ports/armv7hl/distribution/leap/15.3/.