The openSUSE Tumbleweed snapshots are rolling out steady during the month or July.

Some big and small snapshots have been released with a few major-versions updates arriving this week.

The most recent snapshot arrive in the last 24 hours was 20220706. The release updated the Linux Kernel to 5.18.9. It had several additions for the Advanced Linux Sound Architecture to include fixing a couple missing beep setups and adding a mute LED quirk for HP Omen laptops. The kernel also enabled configuration for the MLX90614 remote temperature sensor. There were some minor changes in the update of xfce4-settings 4.16.3, which fixed a recursive lock in libX11. Both yast2-network and yast2-schema-default updated to version 4.5.4, which the packages added a missing route element to the networking section.

A major version updated package arriving in the 20220705 snapshot was 7zip 22; the new version has switches for Linux TAR archives and can now can store additional file timestamps with high precision at one nanosecond or a billionth of a second. That’s fast. Another major version to land this week was vim. The text editor received its second update this week to version 9.0.0032, which fixed a couple Common Vulnerabilities and Exposures; one of those was a moderate Integer Overflow reflected in CVE-2022-2285. Mesa 22.1.3 had some X11 performance fixes and a lot of Zink driver fixes. GNOME’s personal information manager evolution updated translations and fixed a crash when printing task lists to pdf in version 3.44.3. An update of firewalld 1.2.0 added a secure version of Kubernetes controller-plane components and added distributed web IPFS services. The audio and video package PipeWire updated to 0.3.53 and the ALSA plugin should now be able to deal with unsupported sample rates and fall back to the nearest supported one. The audio-convert plugin was rewritten, which should make it more maintainable. Other packages to update in the snapshot were pango 1.50.8, harfbuzz 4.4.1, kernel-firmware 20220622, sssd 2.7.3 and more.

GNOME’s sushi updated to the 42.0 version in snapshot 20220704; the updated file previewer enabled WebKit sandboxing for increased security and responsiveness. The previewer also allows right-clicks to show the context menu for GtkSourceView. Both gnome-software and gnome-remote-desktop updated to version 42.3. An incorrect restart notification related to a failed firmware update was fixed and an uninitialized caps lock was fixed respectively. The camera, access and control library libgphoto2 provided updates in version 2.5.30 related to cameras Canon EOS Rebel T8i, Sony DSC-WX220, Nikon Z9, Fuji X-E4 and the GoPro HERO10. The snapshot also had a few Perl, Python and Ruby support libraries updated.

A single package was updated in snapshot 20220703. The update of the adwaita-xfce-icon-theme to a 0.0.2 version added some multimedia and camera icons.

The dependency manager Yarn updated to version 1.22.19 in snapshot 20220702 and added compatibility with web standard WebAuthn on the npm registry. An update of kmod 30 both dropped and added one patch. The update also provides support for the SM3 hash algorithm. The power management tool tlp 1.5.0 has new features for Sony, ASUS and ThinkPads laptops. The package also added radio device support for switching Near-Field Communication (NFC) devices and removed support for wireless-tools, iwconfig. More than a handful of other language package libraries were updated in the snapshot.

The major version update for vim 9 arrived in the 20220701 snapshot. The text editor made fixes for the CTRL-key combinations that caused more problems than it solves. The editor may still access invalid memory after changing terminal size, according to the changelog. Arriving three days after it’s release, KDE’s Plasma 5.25.2 found its way in the snapshot. The desktop environment updated some Qt 5 requirements for KWayland Integration among many other packages for Plasma. The X Window Manager and Wayland Compositor KWin ensured modeset properties were reset properly and fixed broken keyboard navigation while filtering. Plasma Desktop fixed the dbus interface when building the kglobalaccel and there were many other fixes for Plasma users.

openSUSE.Asia Summit 2022

Call For Papers

CFP deadline is extended to Aug 13, Fri. And Notification to speakers: Week of August 22, 2022. Let's submit your proposal.

It is a pleasure to announce the call for papers for openSUSE.Asia summit 2022 Main Track starting today, the openSUSE.Asia 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 and have been appreciated events for the openSUSE community (i.e. both contributors and users) in Asia. Following the last Asia Virtual Summit hosted by India team, the eighth openSUSE.Asia Summit 2022 will be held by openSUSE online volunteer team on Late September. The past Asia Summits received major participation from Indonesia, China mainland, Taiwan, Japan, South Korea, and India.

This year’s event will consist of the two parts: the Asia Summit Main Track and local online/offline parts held in several Asian countries/regions. This call is for the Asia Summit Main Track. The event is going to be completly virtual and use online conference tools. Talks will be live, but you can record video in advance if you want it.

Topics

openSUSE.Asia Summit 2022 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 2 types of sessions.

• 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: August 13, 2022
• Notification to speakers: Week of August 22, 2022
• openSUSE.Asia Summit 2022: Week of September 26 (The local events during the summit will be announced later among each local community. Please stay tuned.)
• Conference Timings:
  • Sep 30 Fri 2022 : 10:00 UTC - 15:00 UTC
  • Oct 1 Sat 2022 : 4:00 UTC - 7:00 UTC
    
    

How to submit your proposal

Please submit your proposal to the event

• Your proposal must be written in English and 150–500 words long with an appropriate title.
• You need to use English both in speech and on slides.
• Please run spell and grammar checks for your proposal before submission. LibreOffice Language tools and Grammarly
• Your biography on your profile page is also a reviewed document. Please do not forget to write your background.
• You must obey 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)

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 2022.

openSUSE.Asia Online Summit 2022 Logo Competition

Today, we will start a logo competition for openSUSE.Asia Summit 2022. A logo is an essential material for the successful summit. As you have seen, the former openSUSE.Asia summits have their unique logos reflecting the communities where the summit took place. Following tradition, we have logo competition to collect great logo for this year’s summit. Notably, this year summit has two parts. One is Asia Summit Main Track with Virtual Online Conference, the other is Local Part which will be held in each local area. This logo is for Asia Summit Main Track. So this logo will represent Asia.

The competition is open now and ends on 23 July 2022. The organizing team will send “Geeko Mystery Box” as an appreciation for the best logo designed.

Deadline: 23 July 2022

Announcement Winner: Week of August 14

The Rules of the contest are as follows:

• The logo should be licensed under CC-BY-SA 4.0 and allow everyone to use the logo without attribution (BY) if your work is used as the logo of openSUSE.Asia Summit 2022. Note that the attribution is going to be shown on the summit website.
• Design must be original and should not include any third party materials conflicting with CC-BY-SA 4.0 with the attribution exception.
• Both monochromes and color formats are essential for submission.
• Submissions must be in SVG format.
• Design should reflect the openSUSE community in Asia.
• The logo should avoid the following things:
  • Brand names or trademarks of any kind.
  • Illustrations that may consider inappropriate, offensive, hateful, tortuous, defamatory, slanderous or libelous.
  • Sexually explicit or provocative images.
  • Violence or weapons.
  • Alcohol, tobacco, or drug use imagery.
  • Discrimination based on race, gender, religion, nationality, disability, sexual orientation or age.
  • Bigotry, racism, hatred or harm against groups or individuals
  • Religious, political, or nationalist imagery.
• The logo should follow “openSUSE Project Trademark Guidelines” published at HERE
• The branding guidelines will be helpful to design your logo (optional)

Please submit your design to opensuseasia-summit@googlegroups.com with the following entries:

• Subject: openSUSE.Asia Summit 2022 Logo Design - [your name]
• Your name and mail address to contact
• A document about philosophy of the design (txt or pdf)
• Vector file of the design with SVG format ONLY.
• Bitmap of design in attachment — image size: 256*256 px at least, PNG format.
• File size less than 512 KB.

The openSUSE.Asia Summit Committee will decide on the logos, subject to the condition, that the logo meets all the requirements. The final decision will be made by openSUSE.Asia Summit Committee and it may not be the highest scored design. We recommend the artist to use Inkscape, a powerful, free and open source vector graphics tool for all kinds of design.

Dear Tumbleweed users and hackers,

This week, many of us were busy with hack week. Naturally, this took away some resources for regular Tumbleweed work, but I am sure we will see some new things coming out of that week again relatively soon. I tried to keep Tumbleweed rolling this week, which was not that difficult: stagings were never overcrowded, and some snapshots were relatively small changes. And so it comes that we have released 6 snapshots during this week (0624..0629).

The main changes included were:

• openSSL 1.1.1p
• Qt 5.15.5
• GStreamer 1.20.3
• Linux kernel 5.18.6
• Squid 5.6
• glibc: fix hang of rsyslog on shutdown (snapshot 0629)

The staging projects are rather quiet, I expect more to be incoming next week. For now, the most relevant changes in the staging read are:

• Perl 5.36.0
• systemd 251.2: openQA detected issues when combined with SELinux enabled

One thing I wanted to investigate during the Hackweek was trying out whether openSUSE Leap would offer my Raspberry Pi Zero 2 a nice and stable option for motion detection camera recording. I have had RPi 3 Model A+ doing this for a longer time, and a Zero model before that, but the newer RPi Zero 2 has been a bit unstable for so far unknown reason. There are also some unoptimal combinations of too old or too fresh software in the official Raspberry Pi OS releases. You can read more in my hackweek project page

Some of the actions I did over time to change from the system’s default setup:

• For camera support, I needed to install raspberrypi-firmware-extra to get start_x.elf installed, after which I enabled it with start_x=1 in /boot/efi/config.txt
• Added Packman repositories to check fully enabled ffmpeg4.
• Installed motion package, nicely the latest 4.4 was available.
• Configured motion to be near the configuration of my Raspbian installation.
• Played around and probably installed various other packages…
• Updated the 200 packages were available.
• Noticed raspberrypi-firmware-config really owned the config.txt, and the include extraconfig.txt was there for a reason… then found out bsc#1192047 and sighed a bit.

Some notable differences I noted when switching from Raspbian / Raspberry Pi OS to openSUSE Leap 15.4:

• Huge amount of variety in pre-configured images! Enlightement 20, JeOS, minimal X11 (IceWM), GNOME, XFCE, … everything! I chose the minimal X11 as the starting point, since I did not want GUI other than enabling network.
• Booting looks very familiar to openSUSE user, including the boot menu
• No raspi-config or such is included, configuration is done more on the lower level. OTOH I’m used to it by now.
• No MMAL, but V4L2 compatibility works fine
• Other “standard” raspberry tools are missing and uninstallable from default repositories as well, like vcgencmd.
• motion was fresh, but however not compiled with MMAL support. Using /dev/video0 instead.
• ffmpeg is recent enough, but compiled without –enable-omx and –enable-omx-rpi

All in all the first impressions is that openSUSE seems to be well suited for PC like desktop or server use cases in its default configurations. Using more Raspberry Pi specific functionalities may be a bit cumbersome if used to certain tools being available immediately, or the software being compiled with Raspberry Pi specific options. OTOH Raspberry Pi is a lot about hacking so they would not be blockers as such.

I initially had weird network hickups with the wifi, not sure why, so I resorted to wired connectivity for some time. Later on I switched back and wifi seemed fine, possibly thanks to the firmware updates that were installed.

All in all, it requires some hacking but it does work! openSUSE Leap 15.4 as it stands does offer the combination of (so far) stable non-libcamera camera usage (via v4l2 only though), and recent enough ffmpeg. However, the ffmpeg is not compiled with the h264_omx codec possibility for the mkv container which has been my wish. Therefore, it seems that whether using openSUSE or Raspbian, some compiling from sources would be needed to reach the optimal setup.

So far, I’ve studied most of the topics I wanted to study during the Hackweek. However, long term system stability evaluation requires this to be a longer term experiment, so I will leave the system running for now and monitor it.

Five openSUSE Tumbleweed snapshots have been released since last Friday.

The snapshots had a small amount of packages in each release.

The 20220629 snapshot updated OpenSSL to version 1.1.1p. This newer version fixed CVE-2022-2068 affecting the c_rehash script, which was not properly sanitizing the shell metacharacters to prevent command injection. The script, which is distributed by some operating systems in a manner where it is automatically executed, could give an attacker execute arbitrary commands with the privileges of the script. Another package updated in the snapshot was perl-JSON 4.07, which provided some backport updates from 4.10 version. New memory device types, processor upgrades, slot types, processor characteristics and more came in the update of dmidecode 3.4. There were also several table engine updates in the snapshot like ibus-table 1.16.9, ibus-table-chinese 1.8.8 and more.

A single package was updated in snapshot 20220628. The update of mpg123 1.30.0 has a new network backend using external tools/libraries to support HTTPS and the terminal control keys are now case-sensitive.

Two Python Package Index updates were released in 20220626. Missing constructors for UUID for each Bluetooth service were added in the python-qt5 5.15.7 update. The package is a comprehensive set of Python bindings for Qt v5. The other PyPI package update was python-rsa 4.8, which switched to Poetry for dependency and release management and made decryption 2-4x faster by using the Chinese Remainder Theorem when decrypting with a private key.

Text editor vim fixed an invalid memory access when using an expression on the command line in the 8.2.5154 update and some fixes related valgrind became available in the 20220625 snapshot. Caching proxy squid fixed some parser regressions and improved the handling of Gopher responses in version 5.6. The updated open-source printing package cups-filters 1.28.15 had improvements to identify old LaserJets more precisely and switch to Poppler when appropriate. The 5.18.6 Linux Kernel came in the snapshot as well and had several ALSA System on Chip enhancements and fixes. The kernel also had a couple KVM for arm64 changes and handled some GNU Compiler Collection 12 warnings.

Snapshot 20220624 brought an updated dracut version, which stopped leaking shell options and put in a temporary workaround for openSUSE appliance builder kiwi. The gstreamer 1.20.3 made some WebRTC and performance improvements; it also fixed scrambled video playback with hardware-accelerated VA-API decoders on certain Intel hardware. The D-Bus interface for user account query and manipulation, accountsservice, updated from version 0.6.55 to 22.08.8. Other packages to update in the snapshot were Imath 3.1.5, KDE’s amarok and more.

Over the past weeks I have been fixing the test coverage report for at-spi2-core. It has been a bit of an adventure where I had to do these:

• Replace a code coverage tool for another one...
• ... which was easier to modify to produce more accessible HTML reports.
• Figuring out why some of at-spi2-core's modules got 0% coverage.
• Learning to mock DBus services.

What is a code coverage report?

In short — you run your program, or its test suite. You generate a coverage report, and it tells you which lines of code were executed in your program, and which lines weren't.

A coverage report is very useful! It lets one answer some large-scale questions:

• Which code in my project does not get exercised by the tests?

• If there is code that is conditionally-compiled depending on build-time options, am I forgetting to test a particular build configuration?

And small-scale questions:

• Did the test I just added actually cause the code I am interested in to be run?

• Are there tests for all the error paths?

You can also use a coverage report as an exploration tool:

• Run the program by hand and do some things with it. Which code was run through your actions?

I want to be able to do all those things for the accessibility infrastructure: use the report as an exploration tool while I learn how the code works, and use it as a tool to ensure that the tests I add actually test what I want to test.

A snippet of a coverage report

This is a screenshot of the report for at-spi2-core/atspi/atspi-accessible.c:

The leftmost column is the line number in the source file. The second column has the execution count and color-coding for each line: green lines were executed one or more times; red lines were not executed; white lines are not executable.

By looking at that bit of the report, we can start asking questions:

• There is a return -1 for an error condition, which is not executed. Would the calling code actually handle this correctly, since we have no tests for it?

• The last few lines in the function are not executed, since the check before them works as a cache. How can we test those lines, and cause them to be executed? Are they necessary, or is everything handled by the cache above them? How can we test different cache behavior?

First pass: lcov

When I initially added continuous integration infrastructure to at-spi2-core, I copied most of it from libgweather, as Emmanuele Bassi had put in some nice things in it like static code analysis, address-sanitizer, and a code coverage report via lcov.

The initial runs of lcov painted a rather grim picture: test coverage was only at about 30% of the code. However, some modules which are definitely run by the test suite showed up with 0% coverage. This is wrong; those modules definitely have code that gets executed; why isn't it showing up?

Zero coverage

At-spi2-core has some peculiar modules. It does not provide a single program or library that one can just run by hand. Instead, it provides a couple of libraries and a couple of daemons that get used through those libraries, or through raw DBus calls.

In particular, at-spi2-registryd is the registry daemon for accessibility, which multiplexes requests from assitive technologies (ATs) like screen readers into applications. It doesn't even use the session DBus; it registers itself in a separate DBus daemon specific to accessibility, to avoid too much traffic in the main session bus.

at-spi2-registryd gets started up as soon as something requires the accessibility APIs, and remains running until the user's session ends.

However, in the test runner, there is no session. The daemon runs, and gets a SIGTERM from its parent dbus-daemon when it terminates. So, while at-spi2-registryd has no persistent state that it may care about saving, it doesn't exit "cleanly".

And it turns out that gcc's coverage data gets written out only if the program exits cleanly. When you compile with the --coverage option, gcc emits code that turns on the flag in libgcc to write out coverage information when the program ends (libgcc is the compiler-specific runtime helper that gets linked into normal programs compiled with gcc).

It's as if main() had a wrapper:

void main_wrapper(void)
{
    int r = main(argc, argv);

    write_out_coverage_info();

    exit(r);
}

int main(int argc, char **argv) 
{
    /* your program goes here */
}

Of course, if your program terminates prematurely through SIGTERM, the wrapper will not finish running and it will not write out the coverage info.

So, how do we simulate a session in the test runner?

Mocking gnome-session

I recently learned of a fantastic tool, python-dbusmock, which makes it really easy to create mock implementations of DBus interfaces.

There are a couple of places in at-spi2-core that depend on watching the user session's lifetime, and fortunately they only need two things from the gnome-session interfaces:

• Register themselves as a session client.
• Get notified when the session ends so the daemon can exit.

I wrote a mock of these DBus interfaces so that the daemons can register against the fake session manager. Then I made the test runner ask the mock session to tell the daemons to exit when the tests are done.

With that, at-spi2-registryd gets coverage information written out properly.

Obtaining coverage for atk-adaptor

atk-adaptor is a bunch of glue code between atk, the GObject-based library that GTK3 uses to expose accessible interfaces, and libatspi, the hand-written DBus binding to the accessibility interfaces.

The tests for this are very interesting. We want to simulate an application that uses atk to make itself accessible, and to test that e.g. the screen reader can actually interface with them. Instead of creating ATK implementations by hand, there is a helper program that reads XML descriptions of accessible objects, and exposes them via ATK. Each individual test uses a different XML file, and each test spawns the helper program with the XML it needs.

Again, it turns out that the test runner just sent a SIGTERM to the helper program when each test was done. This is fine for running the tests normally, but it prevents code coverage from being written out when the helper program terminates.

So, I installed a gmain signal handler in the helper program, to make it exit cleanly when it gets that SIGTERM. Problem solved!

Missing coverage info for GTK2

The only part of at-spi2-core that doesn't have coverage information yet is the glue code for GTK2. I think this would require running a test program under xvfb so that its libgtk2 can load the module that provides the glue code. I am not sure if this should be tested by at-spi2-core itself, or if that should be the responsibility of GTK2.

Are the coverage reports accessible?

For a sighted person, it is easy to look at a coverage report like the example above and just look for red lines — those that were not executed.

For people who use screen readers, it is not so convenient. I asked around a bit, and Eitan Isaacson gave me some excellent tips on improving the accessibility of lcov and grcov's HTML output.

Lcov is an old tool, and I started using it for at-spi2-core because it is what libgweather already used for its CI. Grcov is a newer tool, mostly by Mozilla people, which they use for Firefox's coverage reports. Grcov is also the tool that librsvg already uses. Since I'd rather baby-sit one tool instead of two, I decided to switch at-spi2-core to use grcov as well and to improve the accessibility of its reports.

The extract from the screenshot above looks like a table with three columns (line number, execution count, source code), but it is not a real HTML <table> — it is done with div elements and styling. Something like this:

<div>
  <div class="columns">
    <div class="column">
      line number
    </div>
    <div class="column color-coding-executed">
      execution count
    </div>
    <div class="column color-coding-executed">
      <pre>source code</pre>
    </div>
  </div>
  <!-- repeat the above for each source line -->
</div>

Eitan showed me how to use ARIA tags to actually expose those divs as something that can be navigated as a table:

• Add role="table" aria-label="Coverage report" to the main <div>. This tells web browsers to go into whatever interaction model they use for navigating tables via accessible interfaces. It also gives a label to the table, so that it is easy to find by assistive tools; for example, a screen reader may let you easily navigate to the next table in a document, and you'd like to know what the table is about.

• Add role="row" to each row's div.

• Add role="cell" to an individual cell's div.

• Add an aria-label to cells with the execution count: while the sighted version shows nothing (non-executable lines), or just a red background (lines not executed), or a number with a green background, the screen reader version cannot depend on color coding alone. That aria-label will say "no coverage", or "0", or the actual execution count, respectively.

Time will tell whether this makes reports easier to peruse. I was mainly worried about being able to scan down the source quickly to find lines that were not executed. By using a screen reader's commands for tabular navigation, one can move down in the second column until you reach a "zero". Maybe there is a faster way? Advice is appreciated!

Grcov now includes that patch, yay!

Next steps

I am starting to sanitize the XML interfaces in at-spi2-core, at least in terms of how they are used in the build. Expect an update soon!

We are seeking feedback regarding the release of openSUSE Leap 15.4, which was released to the general public on June 8.

With this survey, what we’re looking from you is both positive and negative feedback related to the availability and individual experience with openSUSE Leap 15.4. Your participation is very valuable for us.

Participating is very simple, this survey consists of only two questions, in this way we’ll try to continue doing what went well and try to address what went wrong. So follow this link to partipate in this survey:

• https://survey.opensuse.org/

The deadline for collecting responses is July 7. Your responses will be then grouped and reviewed and passed to the respective openSUSE teams.

Here you can find the results from previous retrospective.

We care about your privacy, that’s why the record of your survey responses does not contain any identifying information about you, unless a specific survey question explicitly asked for it. Feedback might be adjusted to fit our report.

Thanks a lot for being part of openSUSE community.

Ansible Molecule is a project to help you test your ansible roles. I’m using molecule for automatically testing the ansible roles of geekoops.

So, while hacking on the geekoops roles, molecule test was complaining on my Tumbleweed machine:

Dear Tumbleweed users and hackers,

During this week, we sweat some blood. Not only was it really hot here, but we also had a gap in the snapshots delivered. Turned out that the update to SELinux 3.4 worked in most cases – but not so well with containers. We stopped rolling for a few days to figure out the fixes for that one issue before merging other, large changes. Nevertheless, we still delivered 6 snapshots this week (0616,0617, 0618, 0619, 0622, and 0623).

The major changes delivered in the last week include:

• Linux kernel 5.18.4
• Mozilla Firefox 101.0.1
• KDE Frameworks 5.95.0
• KDE Plasma 5.25.1
• Gimp 2.10.32
• Inkscape 1.2
• LibreOffice 7.3.4RC2
• NetworkManager 1.38.2
• krb5 1.20
• Samba 4.16.2
• SELinux 3.4
• Redis 7.0.2
• Mesa 22.1.2
• Sphinx 5

Ok, looking at that list, it seems to be no wonder it got heated, when combined with the SELinux issues. But it worked out pretty well in the end. The staging projects are currently not overflowing, but a few things are still in the queue:

• systemd 251.2
• Linux kernel 5.18.6
• rpmlint: some work to detect more of the common errors. This will result in a few packages failing to build, but detecting those errors is worth it.

Regarding build failures: in openSUSE:Factory, we currently have 192 build errors reported. Any help in getting those fixed is appreciated.