The openSUSE Project is planning to have a 24-hour release party in the openSUSE Bar immediately after the release of openSUSE Leap 15.3.

The virtual release party will have members of the release team, community members and board members in attendance.

Beginning at 12:00 UTC on June 2, the release party will go until 11:59 UTC on June 3. Participants are expected from several countries and people are welcome to attend and meet with openSUSE members.

The event gives people an opportunity to get to know people involved in the project and contributors who help with the release of the openSUSE Leap. distribution. The event also offers the community an opportunity to meet, socialize and casually discuss the release after more than six month of development.

Having a hardware tracker seems a little odd of a choice, but a small Polish company, Polyend has really won me over.

Beautiful things work better and the machine is up there with Elektron boxes. There are more compact machines on the horizon, but over the weekend I was able to sit down outside and lay the basics of a track down. I have later finalized it in a DAW, based on the track stems you can export. Not sitting behind a computer and still arrange electronic music is a great luxury.

So without further ado, here's my weekend track:

openSUSE.Asia Summit 2021 online, Faridabad, India

India was accepted to host the openSUSE.Asia Summit 2020. Due of Covid 19 pandemic we had to cancel the event. As the world has shifted from physical mode to digital made, we with the support of openSUSE.Asia committee members proposed to organize openSUSE.Asia summit 2021 in online mode. We are glad that our proposal is accepted by openSUSE board.

The supporters of openSUSE in India, and of Free/Libre Open Source Software (FLOSS) at large are excited to organize the most awaited openSUSE.Asia Summit event. In this activity, experts, contributors, end users, and technology enthusiasts will gather to share experiences about the development of openSUSE and other things related to FLOSS and have a lot of fun. The venue for the openSUSE.Asia Summit was chosen after being proposed by the Indian community during openSUSE.Asia Summit 2019 in Bali, Indonesia. The Asian committee decided Faridabad as the host of openSUSE.Asia Summit 2021 from August 6 to August 8, 2021, at Manav Rachna International Institute of Research & Studies, Faridabad.
Goals to be achieved in the online openSUSE.Asia Summit 2021 include:

• To promote openSUSE in India.
• To attract new contributors for openSUSE from India and other Asian countries.
• To provide an alternative to the wider community that FLOSS can be a powerful tool for doing their daily job.
• To provide a platform for sharing user and developer experiences.

Pre-announcement

openSUSE.Asia Summit 2021 will immediately open a call for paper for prospective speakers. In addition, a logo competition for the openSUSE.Asia Summit 2021 will also be opened. This would surely be an opportunity for designers in Asia to compete with each other to show their abilities and contribute to this activity. More details about the above information will be informed in the near future through news.opensuse.org.
See you online !!

Dear Tumbleweed users and hackers,

This week felt quite unspectacular, but maybe that’s just for me and because I already know what will expect us next week. And so will you, soon! Anyway, first we look back one week. Tumbleweed has seen 5 published snapshots (0513, 0514, 0515, 0517, and 0519).

The main changes in those snapshots included were:

• Linux kernel 5.12.3
• elfutils 0.184
• sudo 1.9.7
• KDE Gear 21.04.1
• PostgreSQL 13.3
• Switched from go 1.15 to go 1.16

And now, for what we plan on releasing next week:

• NetworkManager-Applet 1.22.0 (snapshot 0520, if all goes well)
• Linux Kernel 5.12.4 (also snapshot 0520, if all goes well)
• Rebuild all of Tumbleweed using GCC 11 (will happen on Tuesday, May 25th)
• UsrMerge: as we already have a full rebuild scheduled, we’ll also flip UsrMerge on. This means the first snapshot published after May 25th will change /bin to be a symlink to /usr/bin. Thanks to Ludwig for having the energy to push this over the finish line! The switch started long ago

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