Fortunately, Christmas is around the corner and the year 2020 is coming to an end. But the YaST team is not thinking about going on holidays yet. Quite the contrary, we have been working on a broad range of topics as usual. So let’s have a look at some of them.

Polishing the Cockpit Wicked Module

At the end of the sprint, we released a new version of our Cockpit Wicked module. This release does not include big changes but a set of bug fixes and small improvements. Actually, at this point, we have decided to shift our focus from adding features to polishing the module as much as possible.

As part of this new focus, we have asked our usability experts how to build a better user experience. Additionally, we have started the process to make the module available for translation in our Weblate instance to get it properly localized.

On the other hand, the initial research for the Cockpit Transactional Update module is over. We are now working on documenting our requirements to resume the development work soon.

Better Support for tmpfs in the Partitioner

While introducing the new storage stack in SLE 15, we decided to drop support for creating tmpfs entries in the /etc/fstab using AutoYaST. After all, systemd is already taking care of handling such file systems. However, our users want this behavior back and we are now introducing proper handling in YaST for tmpfs file systems.

As a first step, we added support in the partitioner to manage those entries. Please, beware that YaST will only take care the devices listed in /etc/fstab. Any tmpfs file system created by systemd or any other mechanism is out of our scope.

By the way, we already started to work on AutoYaST support, so stay tuned if you are one of those users missing this feature.

Open Discussion: Easy Way to Change Installer Settings

For quite some time, there has been a feature request to allow changing the installer settings at runtime. However, we are still unsure how it should look and which use cases we should cover.

The discussion is still ongoing, but we have opened a GitHub issue to discuss it further. So, if you feel you can help, feel free to join the conversation.

But That’s Not All

As usual, we have been working on many more things. So let’s select a few of them that you might find interesting:

• Fix detection of para-virtualized guests in Kdump (yast-kdump#118.
• Fix the product selection when using the full media (yast-installation#895).
• Move from Travis to GitHub Actions. It is still a work in progress, but the most relevant repositories have already been adapted. Check the yast2 repository if you want to see an example.
• Better detection of Btrfs subvolumes prefix (yast-storage-ng#1168).

What’s next?

We have just started the last sprint of 2020. We will slow down our work around our Cockpit modules because we feel that it is time to listen to others to decide what’s next. But we plan to work on many different things, like the storage layer, LibYUI, the installer reconfiguration feature… So if you are curious about what we can achieve during this sprint, let’s meet here in around two weeks.

Half a dozen openSUSE Tumbleweed snapshots have been released since last week’s blog update for Geekos’ favorite rolling release.

Six packages were updated in the most recent 20201202 snapshot. An updated keyring was signed and obsolete documentation macros were removed in the update of mtools 4.0.26, which is a collection of utilities to access MS-DOS disks from GNU and Unix without mounting them. The timing and password encrypting/decrypting package python-scrypt updated to version 0.8.17 and added additional test vectors from Request for Comments. Another PyPI package python-atpublic updated from version 1.0 to version 2.1.1; the package dropped Python 3.4 and 3.5 and added Python 3.8 and 3.9. Someone was excited because the package also fixed the doctests to run and pass, which was highlighted with an exclamation point in the changelog - congrats. The other packages to update in the snapshot were fcitx-qt5 1.2.5, libmodulemd 2.10.0 and perl-Types-Serialiser 1.01.

The first snapshot to arrive this month was 20201201. Three YaST packages were updated; the update of yast2-installation 4.3.22 fixed the full media product selection during the setup. Fingerprint reader package fprintd provided proper hotplug support and authentication now requires a new print to enroll with the 1.90.4 version. Other packages to update in the snapshot were the gaming library for game controllers libmanette 0.2.6, libyui-qt-pkg 2.48.5 and the real-time web application framework perl-Mojolicious 8.66.

The 20201130 snapshot updated php 7.4.13, which brought several bug fixes including a fix for OpenSSL that had an OCB mode failure. The second update of the Linux Kernel came in the snapshot; the 5.9.11 kernel fixed the arm64 handling of the erratum 1418040 that had prevented a CPU from onlining. The universal messaging library zeromq updated to version 4.3.3 and fixed a Denial-of-Service Common Vulnerabilities and Exposures on CURVE/ZAP-protected servers by unauthenticated clients.

ImageMagick 7.0.10.43 arrived in the largest snapshot of the week - 20201129. The image creator, editor and modifier provided better support for TIFF YCbCr photometric and added support for the FilmLight FL32 image format. The bugfix release for GNOME updated several GNOME 3.38.2 packages including the personal management application evolution, calculator, control center, gnome-desktop, maps and gnome-music, which provided a fix for new songs retrieval when they are added and fixed a playlist sorting crash. Improvements were made to the user manual in the 3.38.1 gedit update. Another text editor, vim, fixed some popup failures in the 8.2.2039 update. Flatpak 1.8.3 made the in-memory summary cache more efficient and fixed an authentication error and authentications that were getting stuck in a loop. Other packages to update in the snapshot were autoyast2 4.3.63, dconf-editor 3.38.2, libostree 2020.8 and vala 0.50.2.

A new major version of Mozilla Firefox arrived in snapshot 20201127. Firefox 83.0 is getting faster and improves page load performance by up to 15 percent, page responsiveness by up to 12 percent, and reduced memory usage by up to 8 percent, according to the project’s release notes. Command-line utility grep 3.6 fixed the GREP_OPTIONS environment variable to no longer affect grep’s behavior. The jhbuild package, which is used to building collections of source packages, updated to version 3.38.0+3. Command line pdf converter qpdf fixed the handful of integer overflows in version 10.0.4 and libX11 bumped up from a 1.6 to 1.7 version because of new Application Programming Interfaces.

Snapshot 20201125, which arrived after last week’s blog was released, brought an update to the 3D graphics package Mesa 20.2.3, the 5.9.10 Linux Kernel, Node.js 14.15.1, Qt 5.15.2 and python-h2.

Members of the openSUSE release team members will share results of openSUSE on arm during two separate online sessions on openSUSE’s Jisti instance Dec. 2.

The first session will be at 10:00 UTC and the second session at 16:00 UTC. Both sessions are expected to cover the same content and reach different time zones globally for those interested in attending.

Overall, there were almost 300 responses submitted. The core team to develop the survey wants to use the results as a baseline for future surveys about arm to help gauge trends about development efforts with openSUSE on arm architecture.

The results did offer some telling answers about the majority of openSUSE use on arm. More than 4 out of 5 responses indicated they used AArch64, Raspberry Pi 3, Raspberry Pi 4, PinePhone and/or Pine64.

The most favored distribution was almost evenly split between openSUSE Tumbleweed and openSUSE Leap. Of those using openSUSE Leap, almost half stated they used Leap for the stability. Almost half also indicated they would be willing to migrate from Leap to openSUSE Tumbleweed if it was as good enough.

A majority of responses indicated they were using ARMv6, ARMv7, or ARMv8 less than a year.

The developers discussed the results today and made some interpretations from the data. One conclusion is that some people might not be aware that openSUSE Tumbleweed has AArch64 images on software.opensuse.org and that some video packages were important to be included in the images. Additionally, there were multiple comments about sound drivers for the Raspberry Pi 4 had not backported to Leap 15.2 and Tumbleweed, but those drivers are expected to arrive the 5.10 kernel, which is the current version of the Linux Kernel mainline.

The intent of the survey was to better understand the arm user base and to determine a path or ARMv7.

The release team wants to share the results about what they learned on the openSUSE Jisti meetup Dec. 2 at 10:00 UTC and at 16:00 UTC. Each session is scheduled for an hour.

I developed warehouse system and use restful as communication method between our software and client software. We let end point of our system to talk each other with API designed.

For simple and small test using Postman or SOAP-UI is enough for me but to when to test this system with massive data via API is quite headache, plus the mock features on Postman limited and not “mocking” enough as I want.

Lucky enough, I am good with unit test (self claimed :satisfied:) so since the system are develop using java, then I use Junit as helper to help me do the automation test. It look nice when test it locally but somehow I still have an issue to remote test using Junit on my Eclipse IDE. It all because the remote server we connnecting is on customer premise and the connection are so bad! :triumph:

As a guy who love the old school trick, I use curl as the best and simple solution to POST the data into system API endpoint and I was right, the server much responsive to handle data.

Here I share how I using curl to POST data to our API endpoint locally (ssh to server and run the command inside). First of all, i will generated json file to use as data driven unit test and send to my server via scp:

$ scp /C/Users/Robbi/Desktop/TEST_CASE/*.json sayaComel@201.22.13.17:/tmp/test

when finished transfer the files, just ssh into server and navigate where the data are stored.

Let see, here I have 212,717 json file that I want this use with API endpoint. (Tips: All filename must are unique and properly sorted, so you can trace if you unit test failed)

$ find . -type f | wc -l
212717

How to POST json data file to API endpoint?

If I want to POST a single data from my file, I just need to send command like this from directory that store my data file:

$ curl -X POST -H "Content-Type: application/json"  -d @TC-00001.json  http://localhost:8182/order

If I want to POST all the data from my file, I simply just need to execute this looping command inside directory that store my data files:

$ for f in TC-*.json; do printf "\nLoad ${f} - " && curl -X POST -H "Content-Type: application/json" --data @${f} http://localhost:8182/order;done

Simple right? As long you can generate json file then you can use this technique todo data driven test your system endpoint :)

This morning, Election Committee member, Ariez Vachha, posted the candidates list on the project's mailing list. The names of the candidates are:

• Axel Braun
• Gertjan Lettink
• Mark Stopka
• Maurizio Galli
• Nathan Wolf
• Neal Gompa

Last night the nominations and applications phase of the election reached an end. We received six applications and the names of the candidates are:

• Axel Braun
• Gertjan Lettink
• Mark Stopka
• Maurizio Galli
• Nathan Wolf
• Neal Gompa

Note that this election is to fill three vacant seats on the openSUSE Board.

All candidates are encouraged to set up their election platform on the openSUSE wiki. The campaign begins now!

Please do not use librsvg 2.40.x; it cannot render recent Adwaita icon themes correctly.

The librsvg 2.40.x series is the last "C only" version of the library; it was deprecated in 2017.

During the port to Rust, I rewrote the path parser to be spec-compliant, and fixed a few cases that the C version did not handle. One of this cases is for compact Arc data.

The SVG path grammar allows one to remove whitespace between numbers if the next number starts with a sign. For example, 23-45 gets parsed as two numbers 23 -45.

In addition, the arguments of the Arc commands have two flags in the middle of a bunch of numbers. The flags can be 0 or 1, and there may be no whitespace between the flags and the next number. For example, A1.98 1.98 0 0015 13.96 gets parsed as A1.98 1.98 0 0 0 15 13.96 — note the two 0 0 flags before the 15.

Librsvg 2.40.x does not parse this correctly. Adwaita-icon-theme-3.36, and possibly earlier versions, uses minimized SVG files with compressed whitespace, and will not render correctly with the C-only version of librsvg.

This is help-contents-symbolic.svg rendered with librsvg 2.40.21:

And this is help-contents-symbolic.svg rendered with librsvg 2.50.2:

This is not the only icon with compact Arc commands; there are many others that will also be mis-rendered in 2.40.x.

I don't know when Adwaita started using SVGs with compressed whitespace; probably it didn't when librsvg 2.40.x was the latest version, or everyone would have noticed mis-rendered icons.

Background: Someone recently filed a bug about memory unsafety in librsvg 2.40.x's path parser, which mysteriously enough only manifests itself in big-endian platforms. I wouldn't be surprised if this had latent bugs on little-endian as well.

Please use at least librsvg 2.48.x; any earlier versions are not supported. Generally I keep an eye on the last two stable release sets (2.48.x and 2.50.x as of this writing), but only commit fixes to the latest stable series (2.50.x currently).