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

Time flies and another two weeks of YaST development have passed. As in the previous report, we have to mention we invested quite some time learning and experimenting with technologies that will shape the role of YaST in particular and Linux installers in general in the future. But we also had time to fix quite some bugs and to make progress in several features, like:

• Simplified support for hibernation
• Make network forwarding configurable in the installer
• Improved tabs in graphical mode
• Progress in the rewrite of yast2-users, including AutoYaST

Hibernate All Systems!

Funnily enough, the first aspect we want to report about is not a feature we developed, but one we reverted. Back in November we reported a new feature in the installer to propose hibernation only on real hardware (ie. not on virtual machines) and only if the product’s configuration specifies hibernation is desired. Time has proved that the usage of hibernation in real world scenarios goes further than expected back then. For example, hibernation is used on virtual servers deployed on top of some cloud-based infrastructures, as part of a technique to save power and money. The existence of that kind of creative scenarios makes it very hard to predict when hibernation is wanted and when not. So YaST will go back to its previous behavior of proposing hibernation always if the technical conditions are met, no matter which product is being installed or in which environment. The change will be available as an installer self-update for SLE-15-SP3.

Better Default Network Configuration

Despite the hibernation affair, we don’t give up in our attempts to make smart selections in the installer. As you may know, YaST allows to tweak the network configuration during installation. Among many other things, it allows to configure the status of IP forwarding. But we want YaST to propose a correct default value for those settings without requiring user intervention. In the cases of openSUSE MicroOS and SLE Micro that means enabling forwarding by default, since is needed for such systems to work properly. So we made that configurable per product and adjusted the corresponding configuration for those container-based solutions.

Prettier Tabs

Beyond the installer, we also invested some time in something we really wanted to put our hands on - improving the look&feel of the YaST tabs in graphical mode. The description of this pull request includes a good description of the problems (with a link to the original issue in which they were discussed), a technical explanation of the solution and, of course, many screenshots!

New Users Management to Arrive Soon

Last but not least, we continue our small project to rewrite big parts of the users management in YaST. We implemented support for some aspects that were still based on ancient Perl code and we are getting rid of all the legacy parts involved in (auto)installation. If everything goes as expected, next sprint will see the new user management land in the installation process of openSUSE Tumbleweed.

See you soon

We hope you are already enjoying openSUSE Leap 15.3 and ready for the openSUSE Virtual Conference 2021. Meanwhile, we keep working to make YaST a little bit better every day thanks to your feedback. See you around and have a lot of fun!

Recently, I nearly create ProgressUI – tool to setup triggers (condition/action pair) related to task of programs. Currently It’s very simple, because it supports only one kind of action – running external program. User must also type program name and parameters. In future, we would read .desktop files and allow to select from dropdown list (for example). Also, I will add possibility to invoke DBus method and allow to define method name/path/etc. in special files, so user could also select method. Also, I must enhance my set of tools in other ways – for example allowing to send watch fd to daemon, so It could report exit code of application.

In terms related to libgreattao, I added functions, possibility to invoke it and signals. Functions not working properly yet, so doing special thinks like allowing to create multi-level menu is not possible. Signals are templates, but treated in different way – they could been processed multiple times without need to give unique path. It also do not work as expected since it created many not needed entities, but needed for templates. Simplicity is boring.

See: https://www.youtube.com/watch?v=sm04e2N5AcU&t=9s

And yet, I created patron (in patreon.com) page. See: https://www.patreon.com/easylinux?fan_landing=true