A total of four openSUSE Tumbleweed snapshots have been released since the last update.

Three smaller snapshots, which included a new systemd update, and one large snapshot, which included a bunch of RubyGems updates, provided several upstream packages for rolling release users.

The newest snapshot available for end users was 20210703, which brought just two updated packages. The first package update was made to the data compression library zlib-ng-compat; the update to version 2.0.5 made some minor improvements to small data chunks and fixed an inflate corruption on AArch64. GNU Compiler Collection 11 updated the headbranch and fixed some legacy Fortran code, which is a general-purpose, compiled imperative programming language developed at IBM in the 1950s for numeric computations and scientific computing.

The biggest snapshot was 20210702. The snapshot was mostly filled with RubyGems. Both rubygem-rails 6.0.4 and 5.2.6 were updated. The 6.0.4 version fixed an issue in ActiveSupport::Cache::RedisCacheStore that was not passing options to read_multi, which caused fetch_multi to not work properly. The 4.6.0 rubygem-commander, which bridges terminal related libraries, dropped support for Ruby 2.4 and fixed an error with SortedSet on Ruby 3.0. The patch-level verification package for bundled apps, rubygem-bundler-audit 0.8.0, added several configurations and now supports a --database option for specifying a path to an alternative ruby-advisory-db copy. PipeWire updated to version 0.3.31 and provided some fixes for Advanced Linux Sound Architecture-Library 1.2.5 and Bluetooth now uses a hardware database to disable non-working features on listed devices. GNOME’s IRC app Polari updated to version 40.0, which added Libera.Chat to the predefined networks. Other packages to update in the snapshot were GNOME’s library that is full of GTK+ widgets for mobile phones libhandy 1.2.3, text editor vim 8.2.3075, sendmail 8.17.0.3 and openSUSE’s libstorage-ng 4.4.19 package.

The not so frequently updated systemd package arrived in snapshot 20210701. The move from version to 246.13 to 248.3 brings a new systemd-sysext tool that can be used to merge, unmerge, list, and refresh system extension hierarchies. The new version introduces the concept of system extension images and now allows sysusers configuration files shipped by systemd rpms to be overridden during system installation. The 3.1 sysuser-tools version added dependencies on those greater than or equal to systemd 238 if systemd is installed to sysuser-shadow. YaST jumped a few versions to 4.4.14 and added a RISC-V 64-bit architecture helper. Remote desktop client package remmina 1.4.19 added a process-control to the remmina snapcraft and made some User Interface improvements. Other packages to update in the snapshot were Bluetooth utility package blueberry 1.4.4 and python-gst 1.18.4.

The snapshot that was released just shortly before last week’s update was snapshot 20210629. This snapshot updated four RubyGems packages. These gems included rubygem-virtus 2.0.0, which added a new method and replaced an equalizer with an internal virtus/equalizer, and rubygem-webpacker 5.4.0, which added experimental support for the Yarn 2 package manager. Both rubygem-tzinfo-0 0.3.60 and rubygem-websocket-driver 0.7.5 were also included in the snapshot. KDE package for repetitive strain injury called rsibreak cleaned up the spec file, mirror code and made some translation improvements in the update to 0.12.14; the package helps people take regular breaks from sitting too long in front of a computer.

Here is the 29th individually wrapped fun sized podcast episode Pimiga Return of Makers Corner Podcast with Yannick Linking a TI-86 Calculator with openSUSE openSUSE Corner openSUSE Smiles New architectures for Leap x86_64 ARM 64 Power PC, not big-endian IBM Z and LinuxONE, s390x Architecture list for Tumbleweed x86_32 x86_64 ARM v6 ARM v7 ARM Arch […]

The openSUSE Project has used IRC for real-time chat within the community since it began. And the IRC network used was Freenode, until now.

Due to a variety of recent changes to that network, the openSUSE Project is moving our IRC communications to Libera.Chat.

If you are a current IRC user, register your nick(s) on Libera.Chat and rejoin the #opensuse related channels you previously joined on Freenode. Please take this opportunity to choose a new secure password and make sure you are connecting via SSL. Libera.Chat offers documentation on choosing an IRC client.

Many openSUSE channels have moved over and are already on Libera.Chat. However, less-used channels have not been automatically setup. If you need a specific #opensuse-* IRC channel setup, please file a ticket requesting the channel.

New channels should have the same name as they did on Freenode. For example: #opensuse-factory, #opensuse, and #kubic.

If you would like an openSUSE IRC ‘cloak’ (which obfuscates your client host address and shows ‘opensuse’ instead) and you are an openSUSE Member, please file a ticket requesting the cloak. Please note that cloaks are not foolproof, there are ways for people to still get your IP, but they do make it more difficult for people to obtain your IP.

If you are a Matrix user, then you’ll also see improvements as IRC channels are being bridged in to connect the openSUSE communities on IRC and Matrix together. Additionally, Discord and Telegram are connected to Matrix, making it the unifying point for all real-time chat.

Finally, the openSUSE Project hosted Matrix instance is open for the community to use. You can go to chat.opensuse.org to log into the service using your openSUSE account. From there, you’ll be able to interact with any and all Matrix rooms, especially the openSUSE ones hosted on our server that have IRC bridged into them.

Hi! My name is Songlin Jiang, a junior undergraduate from Lanzhou University, China, majoring in Computer Science and Technology. It’s my first time participating in the Google Summer of Code with openSUSE Project mentors. In this blog, I’m going to introduce you to my work and experience so far.

About IME and IBus

For people unfamiliar with non-Latin languages, IME (Input Method) may be a completely new concept since they will find all the characters present on the keyboard when typing. However, for the majority of people in Asia, typing in their language would be impossible if without IME. For example, if you want to type Chinese, there are thousands of Chinese characters in total, and a keyboard is just too small to put them all onto it. But with the help of IME, you can choose to use pinyin or other kinds of input schemas like Wubi. Then a standard US keyboard will be sufficient for typing all the Chinese characters.

IBus is an input method framework for developing input methods providing unified user interfaces. A lot of popular input methods are based on IBus, and IBus is also the default input method framework on GNOME. Even if you don’t use non-Latin languages, you may also find IBus useful with IBus Typing Booster installed.

My Project: IBus Customize

Since IBus has its front-end based on GTK, and GNOME replace that front-end with its GJS version to make it more unified with GNOME, currently, the IBus theme follows the global GNOME-Shell theme in GNOME and the global GTK theme in other desktop environments, and IBus lacks customization in GNOME since ibus-setup (IBus Preferences command) won’t work on GNOME for the previous reason.

As a result, my project aims to make IBus themes separate from the current GNOME-Shell theme and GTK theme so that users can customize it with other GNOME-Shell themes and GTK themes. And also, making an extension on GNOME providing full customization of appearance, behavior, system tray and input source indicator for IBus.

The project is divided into three parts: Customize IBus, IBus Theme Tools, and IBus Theme Hub. Here is a user guide for using these projects, and I’m going to introduce them to you one by one in the following parts and also my experience of creating these projects.

What is needed by the users?

Since using IME is an inseparable and most important part of many non-Latin speakers’ daily life when using computers, the most important thing is to provide enough customization to adapt to users’ needs. Also, since every operating system provides its own set of IMEs, IMEs should be able to configure in a way where users will find it familiar without changing the current user habits, thus reducing the learning cost if they have just switched from another platform.

Customize IBus

Customize IBus is an extension for GNOME providing full customization for IBus. A list of features supported by this extension can be found here.

The project is initially imported from ibus-tweaker since I have to start from scratch for the whole project, and I have no previous experience of creating a GNOME Shell extension before I applied for the GSoC.

Ibus-tweaker was a great project to start with. By learning and reusing a part of its code, I understood the mechanism behind the IBus GJS front-end, further referring to GJS documents, I finally managed to create a whole new extension providing lot more features.

You can see the evolution of the project from here.

You can find Customize IBus repository here!

IBus Theme Tools

IBus Theme Tools are specialized for extracting IBus related styles (style class names start with candidate-, and some patches so that it can be displayed just as defined) into style sheets from GNOME Shell themes that can be used in Customize IBus extension in GNOME. It also supports changing IBus themes with available GTK themes directly in non-GNOME desktops.

The tool is coded in Python, using tinycss2 as a parser for the GNOME Shell theme stylesheet.

You can find IBus Theme Tools repository here!

IBus Theme Hub

IBus Theme Hub is the collection of themes that can be used by the Customize IBus extension.

Currently, it has the Microsoft IME Themes.

If you have designed a theme for IBus, I welcome you to contribute your IBus theme here!

You can find IBus Theme Hub repository here!

Finally…

I hope you enjoyed this article. If you think my project helps you a lot, don’t forget to share this post with your friends so that everyone can get the best use of my GSoC 2021 project.

How many better ways of working have you uncovered lately?

This past year a lot of people have been forced into an unplanned and unwanted experiment. Many teams have had to figure out how to work in a remote-first way for the first time. 

I was privileged to be working in a team that was already distributed, making the transition for us easier than many found it. But adapting to work without office equipment was still new. 

Going without the offices that we were used to was uncomfortable in many ways. It was particularly difficult for those not privileged enough to have good working environments at home. 

While nobody would wish the challenges of the past year upon anyone, disruption to the way we were used to working, helped us uncover some better ways. Nothing groundbreaking. But some things were driven home.

Like how much easier video discussions are when everyone is fully visible, at the same size on the screen, and close-mic’ed. Better than the hybrid experience when part of the team are using a conference room with shared microphone and camera.

We also learned how bad our open plan office environment was for collaborative working. Compared with the experience of two people pairing over a video chat, each in their own quiet spaces.

We had some resilience because we were already distributed. How much more resilient might we have been, had we been more used to experimenting and adapting the ways we worked, safely.

The opening sentence of the agile manifesto doesn’t seem to be as much discussed as the values & principles. I think it’s arguably the most interesting bit.

“We are uncovering better ways of developing software by doing it and helping others do it.”

The Agile Manifesto

This brings three questions to mind that might be useful reflection prompts:

1. How many better ways of developing software have you uncovered recently? Have we already found the best ways of developing software? I hope not!
2. Are the people who are developing software in your organisation, the same people who are uncovering better ways of doing it? Or does management tell people how to work?
3. When deciding how to work, are you thinking foremost of what’s easiest for you? or what’s most helpful for others?

We didn’t need a pandemic to try the experiment of no office, but for many folks it was the first time trying that experiment. What if we experimented more? Experimenting with self-selected, smaller, low-risk experiments?

How much has your team changed the way it works lately? Could you be stuck in a local maximum? Are your ways of working best for your team as it is now, or tradition inherited from those who came before, who may have been in a different context?

Every person is different. Every team is different. Transplanting ways of working from one team to another may not yield the best working environment. 

Ways of working often come from “things I’ve seen work before” or your preferences. Why would they be best for this team now? What are you doing to “uncover” what works best for you now?

Uncovering is a great metaphor. Move things around, remove some things, see what you discover! 

Teams often limit themselves by only trying experiments where they believe the outcome will be an improvement. Improvement is then limited by the experience and imagination of those present.

How about trying experiments where you expect the result to be no different? Or where you have no idea what will happen? Or even where you expect the result to be worse?

Here’s some practical experiments you could try in your team to see what you learn:

Try removing something

What activities, ceremonies, processes, and practices do you have? What would happen if you stopped doing one of them? They may seem like purely beneficial things. Even if they are, by trying to remove them you might learn more about their value (or lack thereof) to you. As well as their influence on your behaviour.

• Imagine there’s No Offices (We’ve had this experiment forced upon us lately)
• Imagine there’s No Meetings. Maybe we’d expect more miscommunications and wasted effort. Perhaps worth testing—maybe we’ll understand the value of meetings more clearly by abstaining for a time. Maybe we’d also learn to communicate asynchronously through writing more clearly. 
• Imagine there’s No Estimates. Do you estimate all your upcoming tasks to measure progress? What would happen if you stopped doing it? If you’re required to give estimates what if you estimated everything as one day?
• Imagine there’s No Staging. Do you test your changes in a staging environment for a time before promoting to prod? What if you didn’t? How would you be forced to adapt to mitigate the risks you had been mitigating in staging.
• Imagine there’s No Branches. Do you work independently from others on your team? What if you had to all work on the same branch? How would you adapt?
• Imagine there’s No Backlogs. What if you discarded everything you’re not doing now or next? What would happen? Maybe worth trying.
• Imagine there’s No Managers. Do you know what your manager is doing? What would happen if they were unavailable for a while? How would your team need to adapt?

Removing things might seem risky and likely to make things worse. But what can we know about our resilience if we only do experiments where we think we know the outcomes.

It can be interesting to try removing something and see if we achieve similar outcomes without it.

It can help you understand the real value of the practice or process to your team. Help you understand your team better, and how things normally go right.

Try constraining something

Add an artificial limit on something you do often and see what you learn. Here’s some popular examples.

• Keep tests green at all times
• Implementation code may only be factored out of tests, not written directly. 
• No more than 1 test in a commit
• Deploy every time tests go green
• Only one level of code indentation, or one dot per line
• Only mock types you own
• No fewer than 3 people work on a task if you usually work alone, or no more than 1 person working on a task if you usually work paired.
• No more than n tasks in progress
• Don’t start a new task until previous is in production.
• No changing code owned by another team. 

Try the opposite

What ways of working do you tend to choose? What if you tried the opposite for a time and see what you learn? Try to prove it’s no worse and see what happens.

• Do you always take on the team’s frontend tasks? What if anyone but you took them?
• Work together in pairs? Try working apart individually.
• Work individually? Try working together in pairs.
• Feel we need to plan better? What if we just started without planning, together.
• Hiring to go faster? What if you tried having fewer people involved instead.

Try the extreme 

An idea from extreme programming is to look for what’s working and then try to turn it up to the maximum; turn the dials up to 11. 

A few ideas:

• Pair programming on complicated tasks? Try pairing on boring tasks too.
• Pairing? Try the whole team worked together as an ensemble/mob.
• Deploying daily? Try to deploy hourly.
• Do you declare a production incident when there’s a problem with customer impact? What if every “operational surprise” were treated as an incident.

Reflecting

Only run experiments that your team all consent to. Set a time limit and a reflection point to review. 

Ask yourselves: What was surprising? Are we having more or less fun? What were the upsides? What were the downsides? Are we achieving more or less? 

Make it the default to revert to the previous ways of working. Normalise trying things you don’t expect to work, and reverting. Celebrate learning that something is not right for you. If every experiment becomes a permanent change for your team, then you’re not really experimenting you’re just changing. 

Be bold enough to try things that probably won’t work. You might uncover new insights into your team, your colleagues, and what brings you joy and success at work.

The post Uncovering Better Ways appeared first on Benji's Blog.

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