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.

Slow YaST in Container

We noticed that when running the YaST services manager module in a container then the start of the module is about 3 times slower than running in the host system directly. It takes about a minute to start, that is way much…

Root vs Non-root

This actually does not influence YaST in the end, but it is an interesting difference and might be useful for someone.

If you run this

# time -p ruby -e '10000.times { system("/bin/true") }'
real 2.90
user 2.45
sys 0.54

and if you run the very same command as root

# sudo time -p ruby -e '10000.times { system("/bin/true") }'
real 9.92
user 5.89
sys 4.16

it takes about triple time! :open_mouth:

But in the end it turned out that the reason is that Ruby uses the optimized vfork() system call instead of the traditional fork(). But because of some security implications it should not be used when running as root, in that case Ruby uses the standard (and slower) fork() call. See more details in the Ruby source code.

So in the end it actually is not 3 times slower because running as root, it is the other way round, it is 3 times faster because running as non-root. But because we almost always run YaST as root then we cannot use this trick…

Cheetah vs SCR

Ok, but why is the services manager much slower at start?

In YaST there are also other ways how to run process. You can use the SCR component (legacy from the YCP times) or the Cheetah Ruby gem.

Cheetah

Let’s try how Cheetah works when running as different users:

# time -p ruby -r cheetah -e '10000.times { Cheetah.run("/bin/true") }'
real 17.83
user 10.41
sys 8.73

# sudo time -p ruby -r cheetah -e '10000.times { Cheetah.run("/bin/true") }'
real 15.74
user 9.51
sys 7.47

The numbers are roughly the same, the reason is that Cheetah always uses the less optimal fork() call so there is no difference, it does not matter who runs the script.

Um, maybe we could improve the Cheetah gem to use the vfork() trick as well… :thinking:

SCR

The .target.bash agent in SCR also uses fork so it also does not matter which user uses it.

Benchmarking

The traditional YaST SCR component is implemented in the C++ and the call needs to go through the YaST component system, on the other hand the Cheetah gem uses a native Ruby code. Additionally SCR uses system() call which uses intermediate shell process while Cheetah uses exec() which executes the command directly.

So it would be nice to compare these two options and see how they perform. For that we wrote a small cheetah_vs_scr.rb benchmarking script. It just lists all systemd targets and runs that many times to have more reliable results.

Results

Running the script as root directly in the system:

# ./cheetah_vs_scr.rb
Number of calls: 1000
Cheetah   : 8.84ms per call
SCR       : 22.90ms per call

As you can see, even without any container involved the Cheetah gem is more than twice faster!

So how this changes when running in a container and running the systemctl command in the /mnt chroot?

yast-container # ./cheetah_vs_scr.rb
Number of calls: 1000
Cheetah   : 7.30ms per call
SCR       : 91.78ms per call

As you can see the SCR calls are more than 4 times slower. That corresponds to the slowdown we can see in the services manager. But more interesting is that the Cheetah case is actually slightly faster when running in a container! And if you compare Cheetah with SCR in container then Cheetah is more than 10x faster! Wow!

So in this case the SCR calls are the bottleneck, the container environment should affect the speed in general only slightly. We actually do not know what is the exact reason for this slowdown, probably the extra chrooting… :thinking:

But as we should switch to Cheetah anyway (because it is a clean native Ruby solution) we are not interested in researching this, this slow functionality caused troubles only in one specific case so far.

Notes: It was tested in an openSUSE Leap 15.4 system, it also heavily depends on the hardware, you might get very different numbers for your system.

Summary

If you just execute other programs from an YaST module few times it probably does not matter much which way you use.

But if you call external programs a lot (hundred times or so) then it depends whether you are running as root or non-root. For non-root case it is better to use the Ruby native calls (system or `` backticks). For the root access, as usually in YaST, prefer the Cheetah gem to the YaST SCR.

In our case it means we should update the YaST service manager module to use Cheetah, it should significantly reduce the start delay. And will improve the start also when running in the host system directly.