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

Dear Tumbleweed users and hackers,

After last week being filled with problems, this week felt like a ‘relaxing one’ – not that there would be fewer changes incoming, but we could focus on those changes instead of cuddling the infrastructure. And so it comes that we managed to publish 5 snapshots during this week (1119, 1121, 1123, 1124, and 1125).

The most interesting changes included:

• GNOME 3.38.1 – it took a while, but at last, it’s there
• KDE Frameworks 5.76.0
• Pango 1.48.0
• Mozilla Thunderbird 78.5.0
• binutils 2.35.1
• pam 1.5.0
• Mesa 20.2.3
• Linux kernel 5.9.10
• Qt 5.15.2

And as usual, Tumbleweed does not stop rolling, and staging areas are currently filled with these changes:

• GNOME 3.38.2
• Linux kernel 5.9.11
• brp-check-suse: a bug fix in how it detected dangling symlinks (it detected them, but did not fail as it was supposed to)
• permissions package: prepares for easier listing, while supporting a full /usr merge
• RPM 4.16: still a few packages build failures
• Ruby 3.0: mainly YaST not ready for that switch
• First experiments with rpmlint 2.0 started in Staging:M
• openssl 3.0: currently alpha 9 in Staging:O

Several HP Printers and Scanners require a non-free software plugin driver to run on Linux distributions. openSUSE does not come bundled with the non-free plugin.

HP provides an automatic installer for HPLIP (HP Linux Imaging and Printing). The installer is known to work on several Linux distributions including SUSE (13.2, 42.1, 42.2, 42.3, 15.0, 15.1, 15.2). Therefore, it should work on openSUSE.

Download the HPLIP installer and run it as follows:

sh hplip-3.20.9.run

Follow the on-screen instructions to complete the setup. Once done, connect your HP Printer/Scanner. It will be automatically detected and installer.

The files downloaded for the setup will be available in a folder with the same name as the HPLIP installation script, i.e in this case hplip-3.20.9.