Dear Tumbleweed users and hackers,

My week is a bit skewed this week: after having have systemd 248 in staging for what felt like an eternity, we could finally finish off the issues identified around it. This was some issues in yast, some regressions seen in systemd itself, and some adjacent issues exposed by sysuser-tools, where we needed to be sure to get the update order in a defined form. Of course, this is just my feeling: more has happened this week. After all, we published a total of 5 snapshots (0625, 0626, 0628, 0629, and 0701).

The most notable changes included:

• systemd 248.3 (updated from 246.13)
• sysuser-tools: accepting a 3rd parameter for the config
• Mesa 21.1.3
• Mozilla Firefox 89.0.2
• Node.JS 16.4.0
• VLC 3.0.16
• OpenSSH: don’t remove /etc/ssh/sshd_config on upgrades (does not restore already removed ones, but protects in the future)
• KDE Plasma 5.22.2.1
• Linux kernel 5.12.13
• SQLite 3.36.0

In the staging projects we currently test:

• Mesa 21.1.4
• libxcrypt 4.4.23: addition of CRYPT_SALT_METHOD_LEGACY; needs a fix in pam
• RPMLint 2.0
• Linux kernel 5.13
• linux-glibc-devel 5.13: breaks llvm and gcc10
• MOTD (mot of the day) handing moves from login.defs to pam_motd: during the transition you might see it in double. When complete, it becomes more flexible though (incl. cockpit having chances to write to /etc/motd.d)
• Rust 1.53
• fmt 8.0.0: breaks ceph

Three openSUSE Tumbleweed snapshots were released so far this week.

There were two bigger snapshots and one smaller one that brought the ClamAV update.

Kicking off the week was snapshot 20210625 that provided updates for the 3D graphic Mesa and Mesa-drivers packages; the updated 21.1.3 versions mostly provided AMD changes and the verison no longer needs a GStreamer Video Acceleration API plugin that inspects environment variables. ImageMagick’s update to version 7.1.0.0 fixed a hang with the SVG parser that would get caught in an infinite loop. Mozilla Firefox 89.0.2 had an update to fix performance and stability regressions with WebRender on Linux and also fixed an occasional hang with WebRender. VLC 3.0.16 fixed an MP4 drop, some regressions with broadcast streams and provided settings improvements. A new major version of the Linux Auditing Framework, audit, updated from version 2.8.5 to 3.0.2 and updated some syscall argument interpretations. PipeWire updated to version 0.3.30+55, which included the update of some Advanced Linux Sound Architecture rules. The update of nodejs16 16.4.0 upgraded dependencies and stabilized the class: AsyncLocalStorage. Other packages to update in the snapshot were GNOME’s video player totem 3.38.1, Flatpak 1.11.2, libstorage-ng 4.4.15 and bind 9.16.18.

Only two packages were updated in snapshot 20210626. ClamAV 0.103.3 fixed scan performance issues and seeks to improve metrics on what versions are being used. Also in the snapshot were updated translations for the libqt5-qttranslations package, which included a Chinese simplified language update for Qt 5.12.

Poppler updated in snapshot 20210628 to version 21.06.1 and fixed rendering of some extended latin1 characters in annotations; it also added an API to get notified if the xref is reconstructed. KDE’s Plasma 5.22.2.1 was a bug fix update that implemented activities window rules for Wayland in KWin and Discover now properly notifies users about updates for Flatpaks. Several of the Qt 5 libraries were updated like ibqt5-qtbase, libqt5-qtconnectivity, libqt5-qtquickcontrols, libqt5-qtscript and more. A patch was committed in the update of the glu to version 9.0.2; this Mesa OpenGL Utility library also had some additional bugfixes. The 3.36.0 version of sqlite made output improvements and the memdb VFS now allows the same in-memory database to be shared among multiple database connections in the same process as long as the database name begins with /. Compression package zchunk updated to version 1.1.16 and fixed a major bug when compressing with a dictionary.

openSUSE.Asia Virtual Summit 2021, Faridabad India

Call For Paper

Theme : USE. SHARE. CONTRIBUTE

It is a pleasure to announce the call for papers for openSUSE.Asia summit 2021. Starting today, the openSUSE.Asia Committee is looking forward to seeing your proposals. The committee is looking for speakers from different avenues of life, representing and advocating Free and Open Source Software. openSUSE.Asia Summits are organized every year to promote the use of free and open source software. It is one of the most appreciated events for the openSUSE community (i.e., both contributors and users) in Asia. This year’s event will be an online event and will prove to be a great platform for enthusiasts and users alike.

Following the last Asia Summit in Bali, the seventh openSUSE.Asia Summit 2021 will be held by openSUSE India Team on August 6th- 8th, 2021. The past Asia Summits received major participation from Indonesia, China, Taiwan, Japan, South Korea, and India. By harnessing the power of the internet, we wish to make this online event a huge success. We hope to see members of the community sharing their most recent knowledge, experiences, and learn about FLOSS technologies surrounding openSUSE.

Topics

openSUSE.Asia Summit 2021 will invite talks relevant to openSUSE and other topics like Cloud, Virtualization, Container, Container Orchestration, Linux desktop environments and applications since openSUSE is a collection of various FLOSS products. The examples of the topics (not limited to) are as the following:

• openSUSE (including Leap, Tumbleweed, Open Build Services, openQA, YaST)
• openSUSE Kubic & MicroOS, Cloud, Virtualization, Container, and Container Orchestration
• Embedded and IoT
• Security (Access/Integrity control, Cryptography, Vulnerability management)
• Desktop environments and applications (e.g. GNOME, KDE, XFCE)
• Office suite, graphic art, multimedia (e.g. LibreOffice, Calligra, GIMP, Inkscape)
• Multilingualization support (e.g. input methods, translation)
• Other software running on openSUSE

Please note that non-technical talks are also welcome. For example:

• Explanations of FLOSS technologies
• Development, Quality Assurance, Translation
• Tips & Tricks, Experience stories (success or fail), Best practice
• Marketing and community management
• Education

Types of sessions

• We are inviting proposals for these 3 types of sessions.
• Workshop (90 min + Q&A)
• Keynote or long talks with presentation (30 min + Q&A)
• Short talk with/without presentation (15 min + Q&A)

Due to a shorter attention span during online sessions, we will keep talks short and engaging.

Schedule

• The deadline of the call for proposals: July 10, 2021
• Notification to speakers: July 22, 2021
• openSUSE.Asia Summit 2021: August 6th- 8th
• Conference Timings: UTC 4.00 to UTC 11.30 (IST 9.30 to IST 17.00)

How to submit your proposal

Please submit your proposal to the following website: https://events.opensuse.org/conferences/oSAS21/

• Your proposal must be written in English and 150–500 words long with an appropriate title.
• You may do your speech in the local language (only Hindi) if you write “Speech in Hindi”
  to the Requirements field. English is the recommended language for slides though.
• Please run spell and grammar checks for your proposal before submission. https://extensions.libreoffice.org/extensions/languagetool https://www.grammarly.com/
• Your biography on your profile page is also a reviewed document. Please do not forget to write your background, country, and your timezone (UTC format)
• You must obey openSUSE Conference code of conduct: https://en.opensuse.org/openSUSE:Conference_code_of_conduct You will receive a forms link after successful submission of proposal for further information requirements.

Guide to write your proposal

Please ensure that your proposal is about and around a topic

For example, if your talk is on security or desktop application, a wholesome
proposal will always start with steps to install the application first.

Please include the reasons as to why your proposal should be the one.

It may contain the following as a reason:

• Need of the application/ technology/ solution
• Future prospects of the proposed solution
• Learnings for the target audience (beginners, contributors)

Only workshop:

• We recommend making a simple timetable with your proposal to structure the use of time during the workshop
• Please state requirements (laptop, internet access, plain sheets, colored markers etc.) beforehand.

Do not hesitate to contact the local team on social media or write to the committee if you are not sure about writing your proposal or preparing your presentation.

Contact Organising committee:

For any enquiries regarding the programme, please contact:

opensuseasia-summit@googlegroups.com

We look forward to see you at openSUSE.Asia Summit 2021 India

It’s time for another of our periodic dispatches from the YaST trenches. But instead of the usual collection of topics, this time we want to focus on a single feature that is finally landing in openSUSE Tumbleweed after a couple of months of development. The fun thing is that, despite all the hard work, it is a pretty unnoticeable feature for most end users.

Managing Local Users is not that Simple

The fact is that historically YaST has not relied on useradd and similar tools to create, modify and delete users and groups. Instead, it used to perform by itself all the changes in the system like creating the home directories, assigning ids or modifying the files /etc/passwd, /etc/groups, etc.

You may think management of users and groups has not changed much in Linux over time. After all, we still use the traditional Unix approach to manage local users. But the reality is that, since the birth of YaST, useradd has changed a lot:

• It was totally rewritten in the jump from (open)SUSE 11 to (open)SUSE 12, the implementation of useradd traditionally available in the package pwdutils was replaced by an alternative one in the package shadow.
• It changed the way the skeleton directories are created, with a more granular approach that copies files from several locations, not only the traditional /etc/skel.
• It added management of subuids and subgids, a feature needed for running rootless containers.
• It changed the location of its configuration, with some attributes removed from /etc/defaults/useradd, either moved to a different file or simply gone.

All those changes were incorporated to useradd and other related tools little by little without having YaST into account, so the behavior of both tools has diverged over the years. That has caused some problems in the past and could cause more in the future. So the YaST team decided it was time to close the gap.

What’s new

Starting with the version of YaST just submitted to Tumbleweed this week, YaST now relies on useradd, groupadd and other shadow tools when creating users and groups during installation and also when using AutoYaST or YaST Firstboot. We also adapted the management of the <user_defaults> section of the AutoYaST profile to make it consistent with recent versions of useradd. The changes in that area imply dropping support for some attributes like <groups>, <no_groups> and <skel>. See the description of this pull request for the rationale and historic background of each change.

As some kind of developer-oriented bonus tracks, it’s also worth noticing that YaST now offers a new object-oriented API to read and manage local users (so-called Y2Users) and makes use of a new mechanism to report errors to the user (Y2Issues, which is in process of adoption in other parts of YaST as well).

What Comes Next

As mentioned, the changes affect the installation process, AutoYaST and YaST Firstboot. But the old code is still in place if you run the interactive YaST module to manage users and groups or the (not exactly fully maintained) command line interface of YaST. We plan to connect those two with the new implementation in the following weeks, so the user experience is fully consistent for all possible usages of (Auto)YaST.

Of course, the new implementation opens the door for deeper changes affecting the YaST user interface or the management of non-local users (LDAP, Samba, NIS…). But to be honest we do not plan to go that far in the mid term. We plan to focus our firepower on other goals, now that the threat caused by the inconsistency in the user management tools is under control.

More News to Come

Of course we have worked in many other areas during the past sprint and we will continue doing so in the future ones. So will be back soon with more news and likely with a more standard post covering several topics. So stay tuned and see you in a couple of weeks!

Dear Tumbleweed users and hackers,

During this week, the updates have not caused any stir in the mailing lists, which is usually a good sign. We have released a total of 5 snapshots (0618, 0620, 0621, 0622, and 0623).

The main changes included in those snapshots were;

• Mutter & gnome-shell 40.2 (some late-bloomers to the GNOME 40.2 update)
• KDE Plasma 5.22.1
• Linux kernel 5.12.12
• Python Sphinx Documentation generator 4.0.2 (updated from 3.5.4)
• Cinnamon Desktop 5.0

So, all in all, it was steadily rolling, without any massive overhaul of the base system. The future looks somewhat similar; these are the main topics currently being tested in the staging areas:

• Mesa 21.1.3
• VLC 3.0.16
• Mozilla Firefox 89.0.2: Fix occasional hangs with Software WebRender
• Linux kernel 5.12.13
• KDE Plasma 5.22.2
• Qt 5.15.5
• systemd 248: openQA found some regression
• sysuser-tools: accepting a 3rd parameter for the config: the upgrade order of packages is important, as this requires systemd 238+ capabilities. Depending on how old the snapshot to be upgraded was, we saw issues in openQA. Things are being worked out and it should be ready together with systemd 248
• RPMLint 2.0

You can order your computer to turn of or reboot, when some tasks are done. Currently only Firefox’s download manager is supported. I wrote also some simple programs to demonstrate, how ProgressUI works, but only Firefox is big application integrated with my tool. Integration needs extra extension to be installed.

In this movie, I download Sintel (open movie) and order ProgressUI to start playing this movie, when download completes.

This project still have some major bugs, but I try to solve them in near future.

You can download ProgresUI from sourceforge.net.

In an alternate universe, we still have 320x240px displays.

Recently, I was trying to learn how the io.Reader interface works in Go and implement my own custom reader. Before implementing a custom Reader let’s understand what they are.

Readers: What are they?

Readers are interfaces or classes that are implemented in various programming languages. Usually, readers take in an input interface that can usually be represented as an array and a length. The reader returns another stream that is usually a cut to the length of the original input. Readers are implemented in various programming languages as following:

• Java: readers are implemented by the interface java.io.Reader that implements read(char[], int, int) and close().
• C++: readers are implemented by the istream where the read function is depicted as follows istream& read (char* s, streamsize n);
• Go: readers are implemented by the io.Reader interface which has Read(p []byte) error.

In the above examples, readers in various programming language do the same thing; they read from the input stream and make a copy of the same into the char / byte array that is provided to the Read function.

Implementing custom Reader in Go

In this example, we will implement a reader that will add the capitalize the characters in the resulting byte array to which we want to copy the result into.

Note: This may or may not be suitable for production but is an example. I have also not seen examples of modifying the string.

Readers in Go need to implement the following language

type Reader interface {
	Read(p []byte) (n int, err error)
}

We will use 2 ways to implement the reader:

• By natively implementing the Read function.
• Using an already existing reader (strings.Reader)

Native implementation of the Read function

package main

import (
	"bytes"
	"fmt"
	"io"
	"log"
	"time"
)

// CapitalizeReader is a reader that implements io.Reader
// It read the bytes from a particular position and returns the number
// of bytes that are read. If an error is thrown, all the errors are thrown
// as it is.
type CapitalizeReader struct {
	b []byte
	i int
}

// Read implements the function for CapitalizeReader.
// p is the []byte where the data is copied to.
// n is the number of bytes that are read and if there is an error it is
// returned along with the bytes that are read.
func (cr *CapitalizeReader) Read(p []byte) (n int, err error) {
	// By default, the size of the
	// if the number of bytes are less than the bytes to be read, then we assign it.
	var l int = len(p)
	if len(cr.b)-cr.i < len(p) {
		l = len(cr.b) - cr.i
	}
	var t []byte = cr.b[cr.i : cr.i+l]
	n = copy(t, cr.b[cr.i:])
	cr.i += n
	t = bytes.ToUpper(t)
	n = copy(p, t)

	// If the bytes read is less than the length of input byte slice, return the number of bytes
	// and io.EOF; it is different from Go's byte reader implementation where it will copy everything
	// and always return 0, io.EOF in the next implementation.
	// Ref: https://golang.org/src/bytes/reader.go?s=1154:1204#L30
	if l < len(p) {
		return n, io.EOF
	}
	return n, nil
}

// NewCapitalizeReader takes in a string and returns a reader.
// Store string as a slice of bytes so that we can read bytes
// and uppercase it on read.
func NewCapitalizeReader(s string) *CapitalizeReader {
	return &CapitalizeReader{b: []byte(s), i: 0}
}

func main() {
	str := "hello world"
	cr := NewCapitalizeReader(str)

	fmt.Println("length of the string: ", str, " is ", len(str))
	var b = make([]byte, 2)

	for {
		time.Sleep(200 * time.Millisecond)
		n, err := cr.Read(b)
		fmt.Println(n, "\t", n, "\t", string(b[:n]))
		if err != nil {
			if err == io.EOF {
				break
			}
			log.Fatal(err)
		}
	}
	bytes.NewReader()
}

Using an already existing reader (strings.Reader)

The below example explains how to use an underlying Reader. Go does this quite often. For example, we have the LimitReader (https://golang.org/pkg/io/#LimitedReader). The LimitReader accepts a Reader and assigns this reader as the underlying reader. Once a set number of bytes are reached, it will return an EOF even if the underlying reader has not reached an EOF. This example uses strings.Reader as the underlying Reader.

package main

import (
	"bufio"
	"bytes"
	"fmt"
	"io"
	"log"
	"strings"
	"unicode"
)

// CapitalizeReader is a reader that implements io.Reader
// The underlying reader is a strings.Reader that is used to 
// read the bytes from a particular position and returns the number 
// of bytes that are read. All the errors are thrown
// as it is. 
type CapitalizeReader struct {
   // sr is the underlying reader to use the reading operations for.
	sr       *strings.Reader
   // offset is the index from where the string is read into the given []byte slice
	offset int64
}

// Read implements the function for CapitalizeReader
// p is the []byte where the data is copied to.
// n is the number of bytes that are read and if there is an error it is 
// returned along with the bytes that are read.
func (cr *CapitalizeReader) Read(p []byte) (n int, err error) {
   // create a new array where modifications will be made
	var t = make([]byte, len(p))
	n, err = cr.sr.ReadAt(t, cr.offset)
    // track the offset by number of bytes that were read
	cr.offset = cr.offset + int64(n)
	t = bytes.ToUpper(t)
    // copy to the provided array only when all the operations are done.
   //  io.Reader interface explicitly specifies that p should not be held by Read.
	copy(p, t)
    return
}

// NewCapitalizedReader takes in a string and returns a reader.
// offset is set to 0 as that is we want to read from.
func NewCapitalizeReader(s string) *CapitalizeReader {
	return &CapitalizeReader{sr: strings.NewReader(s), offset: 0}
}

func main() {
	str := "hello world"
	cr := NewCapitalizeReader(str)

	fmt.Println("length of the string: ", str, " is ", len(str))
	var b = make([]byte, 2)

	for {
		n, err := cr.Read(b)
        // Notice that we read by slice b[:n] even in the case of error
        //  This is because io.EOF can happen we can still have a byte that is read and 
        //  it is easy to miss it out.
		fmt.Println(n, "\t", n, "\t", string(b[:n]))
		if err != nil {
			if err == io.EOF {
               // exit gracefully with in case of io.EOF
				break
			}
           // For all other errors exit with a non-zero exit code.
			log.Fatal(err)
		}
	}
}

Summary

1. Readers have a similar interface in various programming languages.
2. Readers in Go can be implemented natively by implementing the Read(p []byte) (int, eror) method for any struct.
3. Readers in Go can also have a backing or an underlying reader that can be used to implement a new reader. This new reader can be limit or enhance the capability of the underlying reader. An example of this is the LimitReader in Go

Dear Tumbleweed users and hackers,

This week we have seen a steady stream of snapshots being published. A full 6 snapshots made it out onto the mirrors (0611, 0612, 01613, 0614, 0615, and 0616).

The main changes in those snapshot included:

• Mozilla Firefox 89.0
• Linux kernel 5.12.10
• python3x packages no longer provided ‘python’ as a symbol to not confuse the python2 stacks
• KDE Gear 21.04.2
• KDE Frameworks 5.83.0
• GNOME 40.2

This matches pretty much what was promised to come during last week’s review. A few things still take a bit more time, and more things have shown up in the staging areas:

• Linux kernel 5.12.12
• KDE Plasma 5.22.1
• Cinnamon 5.0
• systemd 248

Wait what?

Yes, there are couple of ways for you, the user, the contributor, the amazing human being who wants to improve the software that is used by millions, to write automated tests and have bots doing all the work for you, once you’ve signed a binding contract with the blood of an unicorn, and have obtained api keys for our public https://openqa.opensuse.org instance.

For now I will leave out the details on how to get those, but will rather point you to the #factory irc channel (or dischord), where you can get in touch with current admins, whom will be able to guide you better in the process.

I have the keys

You should get operator keys and they would look like this (more or less):

[openqa.opensuse.org]
key = 45ABCEB4562ACB04
secret = 4BA0003086C4CB95

Now let’s do this

I will assume that you’re using openSUSE Tumbleweed, instructions are similar for Leap, but if you’re looking for something more esoteric, check the bootstraping guide

Bring up a terminal or your favorite package manager, and install openQA-client, it will pull almost everything you will need

zypper in openQA-client

Once we’re here, we’ve gotta clone the git repo from the tests being ran in openqa.opensuse.org, to do that let’s go to a directory; let’s call it Skynet and create it in our user’s home. My user’s home is /home/foursixnine \o/ and use git to clone the test repository: https://github.com/os-autoinst/os-autoinst-distri-opensuse/.

cd $HOME
mkdir Skynet
cd Skynet
git clone https://github.com/os-autoinst/os-autoinst-distri-opensuse/

Now since we already cloned the test distribution, and also got the openQA client installed, all there is to do is:

1 - Hacking & Commiting 2 - Scheduling a test run

At this point we can do #1 fairly easy, but #2 needs a bit of a push (no pun intended), this is where we will need the API keys that we requested, in the beginning.

We will rely for now, on openqa-clone-custom-git-refspec which reads configuration parameters from “$OPENQA_CONFIG/client.conf”, “~/.config/openqa/client.conf” and “/etc/openqa/client.conf” (you can run openqa-cli –help to get more detailed info on this), for now open up your favorite editor and let’s create the directories and files we’ll need

mkdir ~/.config/openqa
$EDITOR ~/.config/openqa/client.conf

And paste the API keys you already have, you you will be able to post and create jobs on the public instance!

Let’s get hacking

This part is pretty straightforward once you’ve looked at $HOME/Skynet/os-autoinst-distri-opensuse.

For this round, let’s say we want to also test chrome, in incognito mode. By looking at chrome’s help we know that the --incognito is a thing

So let’s go to where all the tests are, edit, commit and push our changes

Remember to set up your fork, however if you want to make your life easier use hub you can find it in the repos too!

cd $HOME/Skynet/os-autoinst-distri-opensuse
vim tests/x11/chrome.pm
git commit -m "Message goes here" tests/x11/chrome.pm
git push $REMOTE
openqa-clone-custom-git-refspec \
 https://github.com/foursixnine/os-autoinst-distri-opensuse/tree/test_incognito_in_chrome \
 https://openqa.opensuse.org/tests/1792294 \
 SCHEDULE=tests/installation/bootloader_start,tests/boot/boot_to_desktop,tests/console/consoletest_setup,tests/x11/chrome \
 BUILD=0 \
 TEST=openQA-WORKSHOP-ALL-CAPS

In the end you will end up with an URL https://openqa.opensuse.org/t1793764, and you will get emails from travis if something is going wrong