As you may know, YaST is not only a control center for (open)SUSE Linux distributions, but it is also the installer. And, in that regard, we think it is a competent installer. However, time goes by, and YaST shows its age in a few aspects.

During summer 2021, the team discussed how YaST should look in the near future. We considered many ideas, but let's focus on these:

• Shortening the installation process.
• Decoupling the user interface from YaST internals.
• Adding a web-based interface. We had WebYaST in the past, but it was not meant to work as installer.

We played around with these ideas (e.g., see $INSTALLER:80 and making openSUSE installer shorter), but we never had a concrete plan.

Fast-forward to December: before the holidays, we decided to resume our research and build a proof of concept of a web-based installer. We created something simple enough that, to be honest, does not even work at all. But after discussing the overall approach at a team meeting in January, we thought it might be a good idea to invest more time into it.

However, before jumping into coding just "something", we want to take our time to define the project in the right way, build a plan and ask for feedback.

It is not just about the user interface​

Providing an alternative web-based interface is just the tip of the iceberg. Before doing that, we need to make many internal changes, like decoupling the user interface code or adding a D-Bus interface.

Fortunately, we already have improved YaST internals in several vital areas (storage, networking, etc.). However, we are not there yet: a lot of work remains to be done.

The diagram below outlines the main components of the idea. Of course, it might change as the project evolves, but it looks good as a starting point.

Benefits​

Following this approach, we can foresee many benefits for YaST. To name a few:

• A better user interface: libYUI has served us well. However, it imposes some limitations that we would love to overcome.
• Reusability: YaST contains a lot of helpful logic that would be available to other tools.
• Better integration: It should be easier to integrate pieces of YaST in your own workflows by providing a D-Bus interface.
• Multi-language: Eventually, using D-Bus might allow us to use other programming languages.
• Contributors: We expect more people to contribute to the project by making the code more accessible and using widely-known technologies.

Q&A​

We expect you have questions, right? So let's try to anticipate some of them.

Are you deprecating the current user interface?​

No. We just want to offer an alternative and somehow simplified interface. Actually, we do not expect the web-based UI to be as powerful as the current one in the short term.

Which modules would get the new interface?​

At this point, we are limiting to the installer. We do not plan to add a web-based interface to any other module.

What about AutoYaST?​

Regarding AutoYaST, the idea is to use the same codebase as the standard installation while keeping the backward compatibility. So you could reuse your AutoYaST profiles with no significant issues.

Are you moving from Ruby to another language?​

No. We just thought that, in the future, it might be possible to reimplement parts of YaST (or write new pieces) in a different language. But we do not plan to replace Ruby in the short term.

When will it be released?​

We do not know yet.

Isn't precisely that what Anaconda developers are doing?​

Mostly yes. We were glad to read their announcement because it somehow validates our point of view about the future. But, of course, Anaconda is in a better position (e.g., it already features a D-Bus interface).

Would you rely on Cockpit?​

We do not know yet, but... why not? Cockpit is a really nice project and we have already released a module for Wicked. So perhaps we could seek some collaboration.

Why is called D-Installer?​

Well, it is just a play on words. We named the repository as "yast/the-installer" and, given that it is a service-based installer, it evolved to d-installer. Of course, not even the name of the project is set in stone, so we are open to better proposals. 😉

Conclusion​

We are in the early stages of an exciting project that should take us to redefine the future of YaST. And, of course, we would love to hear from you. So, please, do not hesitate to contact us if you have any comments or questions.

Have a lot of fun!

There is a new drop-in replacement for Elasticsearch, at least if you don’t mind the limitations and the alpha status. However, it definitely lives up to the promise that it provides an Elasticsearch-compatible API for data ingestion. I tested it with the elasticsearch-http() destination of syslog-ng, and it worked perfectly after I modified the URL in the configuration example I found.

So, what is Zinc? It is a search engine written in Go that provides an Elasticsearch-compatible API for data ingestion. You cannot use Kibana with it, only its own web interface. If you are not into graphs and dashboards, and want to search text messages, then it is perfect. The application itself is a single binary and it does not have any external dependencies. It is lightweight and easy to configure, as practically there are no configuration options at all.

Note: Zinc is still in alpha state. There are no guarantees that later versions will be compatible at any level. Error messages can sometimes be cryptic and you might run into unexpected behavior.

You can read the rest of my blog at https://www.syslog-ng.com/community/b/blog/posts/another-use-for-the-syslog-ng-elasticsearch-http-destination-zinc

The call for papers for openSUSE Conference 2022 is open!

The call for papers is open until April 14. This leaves a less than 90 days to submit a proposal. The dates of the conference are scheduled for June 2 - 4. The organizing team is preparing for a hybrid conference involving both virtual talks and live talks from the Z-Bau in Nuremberg, Germany. Registration for the conference has also begun.

Presentations can be submitted for the following length of time:

• Lightning Talk (10 mins) or Lightning Virtual Talk (10 mins)
• Normal Talk (30 mins) or Normal Virtual Talk (30 mins)
• Long Talk (45 mins) or Long Virtual Talk (45 mins)
• Workshop (1 hour) or Virtual Workshop (1 hour)

The following tracks are listed for the conference:

• Cloud and Containers
• Community
• Embedded Systems and Edge Computing
• New Technologies
• Open Source
• openSUSE

The conference already has two sponsors with Fedora and SUSE. Companies interested in sponsoring the event can view sponsorship information on the project’s wiki page.

Volunteers who would like to help with the planning of the event can join our planning meetings on Tuesdays at 19:00 UTC. Check the notes for details.

The start of an openSUSE survey has begun, and users, open-source contributors and community members are encouraged to take the annual survey.

Last year the community started its end of year survey and discussed the results during a community meeting.

The results and meeting feedback guided changes in the timing and format of the current survey, which is now open for people to take. Some changes were made to the previous year’s questions and the survey will run until Feb. 28.

The survey is expected to provide insights on how people view and interact with the project. The survey will also help the community better understand the growing use of openSUSE distributions and tools.

The survey was expected to start in December of 2021, but due to another survey about community safety and the elections timing of the openSUSE Board, a decision was made to begin the survey in the new year. Please help us by taking the survey.

Dear Tumbleweed users and hackers,

The holidays are over and people are returning to their computers, submitting a lot more than during the last weeks. Out of the 6 snapshots built and tested,5 made it out to the mirrors (0107, 0109, 0110, 0111, and 0112).

The most interesting updates in those snapshots are:

• Linux kernel 5.16.0
• GNOME 41.3
• openSSL 1.1.1m
• python36-FOO modulea re no longer built; The repo still contains ~ 200 python36 packages, but those are mainly due to build failures in python-singlespec packages. You can expect them to vanish over the next few days
• fmt 8.1.1: Restores ABI compatibiliy to fmt 8.0
• fwupd-efi: Re-add fwupdx64.efi.signed symlink (boo#1192206)
• KDE Frameworks 5.90.0
• KDE Plasma 5.23.5
• KDE Gear 21.12.1
• Mozilla Firefox 96.0
• Wayland 1.20.0

The first wave of submissions could be worked off and stagings are looking not that crowded at the moment. The things on the horizon I’m currently aware of are:

• linux-glibc-devel 5.16: syncing up with the kernel
• Ruby 3.1 to be introduced and become the main ruby interpreter. Ruby 2.7 and Ruby 3.0 will disappear at the same time.
• Python 3.6 interpreter will be removed (once all python36-FOO modules are gone)
• Python 3.10 as the distro default interpreter (a bit down the line)
• GCC 12 introduction has started to be as ready as possible for when the upstream release happens.

Most of those items will be some longer-lasting efforts. The list is ordered based on my prediction of how they will land in Tumbleweed.

openSUSE’s rolling release Tumbleweed finished off 2021 with multiple snapshots and 2022 is starting off the same by producing nine snapshots so far this year.

The latest Tumbleweed snapshot, 20220112, updated Mozilla Firefox to major version 96.0 and addressed almost 20 Common Vulnerabilities and Exposures. The browser added a new feature for printing that allows users to choose to print only the odd/even pages.The browser now defaults all cookies to having a SameSite=lax attribute to helps defend against one-click attacks. While gnome-desktop had a version bump to 41.3, gnome-shell 41.3 fixed some crashes, improved window tracking and updated translations. GNOME’s window manager mutter 41.3 fixed a mixed up refresh rate in multi-monitor setups and fixed orientation changes on devices with 90 degree adjustments. Command line utility hdparm 9.63 added a patch and has a new --sanitize-overwrite-passes flag. Other packages to update in the snapshot were rdma-core 38.1, libpipeline 1.5.5, rdma-core 38.1, vim 8.2.4063 and wayland 1.20.0.

The entire KDE stack was updated in snapshot 20220111, which brought KDE Gear 21.12.1, KDE Frameworks 5.90.0 and Plasma 5.23.5. Gear 21.12.1 fixed kalarm that had prevented command line actions from running with bad calendar files. Video editor Kdenlive created some default rules for varying frames-per-second clips that are imported. Frameworks 5.90.0 had some changes for the input/output library KIO; it finished PolKit integration and KIO also fixed hidden NTFS mountpoints when /etc/mtab is a regular file. The update of Kirigami in Frameworks 5.90.0 improved consistency with scrolling in Qt widgets and fixed layered navigation buttons. The update of Plasma 5.25.5 fixed bugs involving fetching Flatpak updates in the software management (Graphical User Interface) Discover. Plasma Desktop fixed some settings and handling of X11 and KDE’s Bluedevil package fixed device type detection for Audio/Video devices. Several other fixes were made in KDE’s stack update. There were several other updated packages in the snapshot, but almost all were Python Package Index. One of the other packages to update supports the work-flow of YaST developers; rubygem-yast-rake 0.2.44 added support for multiple Rubocop versions. The other non-PyPI updates were to music player amarok and perl-IO-Socket-SSL 2.073.

The snapshot 20220110 updated curl to version 7.81.0 and Daniel Stenberg’s video lists 16 of his favorite bug fixes. One of those was the enablement of HAProxy support for hyper backend, which is a separate http backend for curl, and another was providing a tool to warn if too many output arguments were found when specifying a number of urls. PipeWire 0.3.43 improved memory usage, fixed some crashes and provided better compatibility with GStreamer based applications. An update of framework gupnp 1.4.2 fixed a memory leak, deprecated some root component and enhanced documentation. The mtools package, which is a collection of utilities to access MS-DOS disks, updated to 4.0.37 and fixed a missing command error in floppyd_io.c. The home media server package rygel 0.40.3 fixed a deadlock on start-up and the 4.4.6 yast2-security package fixed some SELinux requirement. Several other packages were updated in the snapshot.

Xen had some upstream patches arriving in the 20220109 snapshot. It also added a fix in collecting active Virtual Machine config files in the supportconfig plugin xen-supportconfig. GNOME software updated to version 41.3 in the snapshot and removed various cultural sensitivity badges. An update of aws-cli 1.22.28 updated some requirements in the spec file from setup.py. The dleyna-renderer package, which allows clients to discover and manipulate Digital Media Renderers, and its complementary package dleyna-server, removed error logging in versions 0.7.2. An update of yast2 4.4.34 fixed test failures in Ruby 2.5 that was caused by the fix for Ruby 3.0. Other packages to update in the snapshot were libsoup 3.0.4, libstorage-ng 4.4.72, fmt 8.1.1 and more.

The first update of the week for libstorage-ng arrived in snapshot 20220107, which updated translations from Weblate in Japanese, Catalan and Slovak. An update of openssl 1.1.1m prioritised DANE TLSA issuer certificates over peer certificates. An update of GNU Compiler Collection 11 fixes memory corruption and hwdata 0.355 updated PCI, USB and vendor IDs. Fast compression algorithm package zstd updated to version 1.5.1 and rebalanced compression levels to better match the intended speed/level curve; it also made some minor compression ratio improvements for small data. Another package to update in the snapshot was xapps 2.2.8, which mostly provided translation updates.

Gamers who play Assassin’s Creed Syndicate were likely happy to see Tumbleweed’s 20220106 snapshot; the update of 3D Graphics package Mesa 21.3.3 in the snapshot fixed crashes in the game. Mesa and its drivers package fixed build failure with MSVC as well. The update of ImageMagick 7.1.0.19 addressed a hang and possible DoS for certain SVG constructs. The update also improved adjustments of page offsets when resizing an image. Linux’s read-only file system squashfs updated to version 4.5; it added a new option to throttle the amount of CPU and I/O and mksquashfs now allows a no source directory to be specified. Several patches were removed with the update of kdump 0.9.2 and many more patches were added in preparation for openSUSE Leap 15.4. Other packages to update in the snapshot were fmt 8.1.0, vim 8.2.3995, perl-JSON 4.04 and more.

Librsvg's documentation tooling is pretty ancient. The man page for rsvg-convert is written by hand in troff, and the C library's reference documentation still uses the venerable gtk-doc.

As part of the modernization effort, I have turned the man page into a reStructuredText document, and the C API documentation into gi-docgen. This post describes how I did that.

You can read librsvg's new documentation here.

From man to rst

The man page for rsvg-convert was written in troff, which is pretty cumbersome. The following gunk defines a little paragraph and a table:

.P
You can also specify dimensions as CSS lengths, for example
.B 10px
or \"
.BR 8.5in .
The unit specifiers supported are as follows:
.RS
.TS
tab (@);
l lx.
px@T{
pixels (the unit specifier can be omitted)
T}
in@T{
inches
T}
cm@T{
centimeters
T}
mm@T{
millimeters
T}
pt@T{
points, 1/72 inch
T}
pc@T{
picas, 1/6 inch
T}
.TE

Yeah, nope. We have better tools now like rst2man, which take a reStructuredText document — fancy plain text — and turn it into a troff man page. I just had to use a command line like

pandoc --from=man --to=rst rsvg-convert.1 > rsvg-convert.rst

and then tweak the output a little:

You can also specify dimensions as CSS lengths, for example ``10px`` or
``8.5in``. The unit specifiers supported are as follows:

   == ==========================================
   px pixels (the unit specifier can be omitted)
   in inches
   cm centimeters
   mm millimeters
   pt points, 1/72 inch
   pc picas, 1/6 inch
   == ==========================================

Much better, right?

I've learned that Pandoc is awesome. Pure magic, highly recommended.

I hope to integrate the man page into a prettier user manual for rsvg-convert at some point. It's no longer a trivial program, and its options allow for some interesting combinations that could use some illustrations and generally more detail than a man page.

From gtk-doc to gi-docgen

I highly recommend that you read Emmanuele's initial description of gi-docgen, which includes the history of gtk-doc, a description of its shortcomings, and how gi-docgen is a simpler tool that leverages the fact that GObject Introspection already slurps documentation from source code and so obviates most of gtk-doc already.

Summary of how gi-docgen works:

• The C code has documentation comments in Markdown format, with annotations for GObject Introspection. (Note: librsvg has no C code for the library, so those documentation comments actually live in the .h header files that it installs for the benefit of C programs.)

• The library gets compiled and introspected. In this step, g-ir-scanner(1) extracts annotations and documentation from the source code and puts them in the MyLibrary.gir XML file.

• You write a small configuration file to tell gi-docgen about the structure of your documentation. Unlike gtk-doc, you don't need to write a DocBook skeleton or anything complicated. Stand-alone chapters can be individual Markdown files, and the configuration file just lists them in the order you want them to appear. Gi-docgen automatically includes all the classes, types, functions, etc. from your code into the docs.

• ... it runs very fast. Gtk-doc was always slow due to xsltproc and complicated stylesheets to turn a DocBook document into browsable HTML documentation. Gi-docgen is much leaner.

Doing the conversion

Unlike the mostly automatic pandoc step for the man page, I converted the documentation comments to from DocBook to Markdown by hand. For librsvg this took me a moderately caffeinated afternoon; it's a little fiddly business, but nothing out of this world.

You can look forward to having good error messages from gi-docgen when something goes wrong, unlike gtk-doc, whose errors I always tended to ignore until the last minute because they were so hard to discern and diagnose.

Some hints:

• DocBook hyperlinks that looked like <ulink url="blahblah.html">blah blah</ulink> get turned into [blah blah](blahblah.html) Markdown.

• Gi-docgen allows references to methods like [method@Gtk.Button.set_child] - see the linking documentation for other kinds of links.

• You can get progressively fancy with introspection attributes.

• There is no direct mapping between DocBook's extremely granular semantic markup and Markdown conventions, so for example I'd substitute both <literal>foobar</literal> and <filename>/foo/bar</filename> for `foobar` and `/foo/bar`, respectively (i.e. the text I wanted to show, between backticks, to indicate verbatim text).

Librsvg seemed to include verbatim text blocks in gtk-doc delimited like this:

/**
 * blah_blah():
 *
 * For example:
 *
 * |[
 * verbatim text goes here
 * ]|
 *
 * Etc. etc.
 */

Those can go between ``` triple backticks in Markdown:

/**
 * blah_blah():
 *
 * For example:
 *
 * ```
 * verbatim text goes here
 * ```
 *
 * Etc. etc.
 */

Errors I found

My first manual run of gi-docgen looked like this:

$ gi-docgen check Rsvg-2.0.gir 
INFO: Loading config file: None
INFO: Search paths: ['/home/federico/src/librsvg/gi-docgen/_build', '/home/federico/.local/share/gir-1.0', '/home/federico/.local/share/flatpak/exports/share/gir-1.0', '/var/lib/flatpak/exports/share/gir-1.0', '/usr/local/share/gir-1.0', '/usr/share/gir-1.0']
INFO: Elapsed time 1.601 seconds
WARNING: Symbol 'Rsvg.HandleFlags' at <unknown>:0 is not documented
WARNING: Return value for symbol 'Rsvg.Handle.get_dimensions_sub' is not documented
WARNING: Return value for symbol 'Rsvg.Handle.get_geometry_for_element' is not documented
WARNING: Return value for symbol 'Rsvg.Handle.get_geometry_for_layer' is not documented
WARNING: Return value for symbol 'Rsvg.Handle.get_position_sub' is not documented
WARNING: Return value for symbol 'Rsvg.Handle.render_document' is not documented
WARNING: Return value for symbol 'Rsvg.Handle.render_element' is not documented
WARNING: Return value for symbol 'Rsvg.Handle.render_layer' is not documented
WARNING: Return value for symbol 'Rsvg.Handle.set_stylesheet' is not documented
WARNING: Symbol 'Rsvg.Handle.base-uri' at <unknown>:0 is not documented
WARNING: Symbol 'Rsvg.Handle.dpi-x' at <unknown>:0 is not documented
WARNING: Symbol 'Rsvg.Handle.dpi-y' at <unknown>:0 is not documented
WARNING: Symbol 'Rsvg.cleanup' at include/librsvg/rsvg.h:447 is not documented
WARNING: Symbol 'Rsvg.DEPRECATED_FOR' at include/librsvg/rsvg.h:47 is not documented
WARNING: Parameter 'f' of symbol 'Rsvg.DEPRECATED_FOR' is not documented

The warnings like WARNING: Return value ... is not documented are easy to fix; the comment blocks had their descriptions, but they were missing the Returns: part.

The warnings like WARNING: Symbol 'Rsvg.Handle.base-uri' at <unknown>:0 is not documented are different. Those are GObject properties, which previously were documented like this:

/**
 * RsvgHandle::base-uri:
 *
 * Base URI, to be used to resolve relative references for resources.  See the section
 * "Security and locations of referenced files" for details.
 */

There is a syntax error there! The symbol line should use a single colon between the class name and the property name, e.g. RsvgHandle:base-uri instead of RsvgHandle::base-uri. This one, plus the other properties that showed up as not documented, had the same kind of typo.

The first warning, WARNING: Symbol 'Rsvg.HandleFlags' at <unknown>:0 is not documented, turned out to be that there were two documentation comments with the same title for RsvgHandleFlags, and the second one was empty — and the last one wins. I left a single one with the actual docs.

Writing standalone chapters

Librsvg had a few chapters like doc/foo.xml, doc/bar.xml that were included in the reference documentation; those were a DocBook <chapter> each. I was able to convert them to Markdown with pandoc individually, and then add a Title: heading in the first line of each .md file — that's what gi-docgen uses to build the table of contents in the documentation's starting page.

Title: Overview of Librsvg

# Overview of Librsvg

Librsvg is a library for rendering Scalable Vector Graphics files (SVG).
Blah blah blah blah.

Build scripts

There are plenty of examples for using gi-docgen with meson; you can look at how it is done in gtk.

However, librsvg is still using Autotools! You can steal the following bits:

• configure.ac
• doc/Makefile.am

Publishing the documentation

Gtk-doc assumed that magic happened somewhere in developer.gnome.org to generate the documentation and publish it. Gi-docgen assumes that your project publishes it with Gitlab pages.

Indeed, the new documentation is published there — you can see how it is generated in .gitlab-ci.yml. Note that there are two jobs: the reference job generates gi-docgen's HTML in a public/Rsvg-2.0 directory, and the pages job integrates it with the Rust API documentation and publishes both together.

Linking the docs to the main developer's site

Finally, librsvg's docs are linked from the GNOME Platform Introduction. I submitted a merge request to the developer-www project to update it.

That's all! I hope this is useful for someone who wants to move from gtk-doc to gi-docgen, which is a much more pleasant tool!

Users of openSUSE Leap 15.2 will not be receiving security and maintenance updates as the version is now EOL (end of life) as of Jan. 4, 2022.

EOL ends updates for the operating system minor version. Those who continue to use EOL versions will be exposed to vulnerabilities because these discontinued versions no longer receive security and maintenance updates. This is why users need to upgrade to the newer minor release; openSUSE Leap 15.3!

Users can upgrade from 15.2 to 15.3 by downloading the iso image or following the instructions on how to upgrade found on https://en.opensuse.org/SDB:System_upgrade.

For new installations, download openSUSE Leap 15.3 images at https://get.opensuse.org/leap/. The Leap 15.3 release is supported with security patches and updates and is expected to reach its EOL in November 2022. Leap 15.4 is expected to be released in June 2022, according to the roadmap.

Users interested in changing from the point release version to the rolling version can move to Tumbleweed, which provides large daily and frequent updates of all software in the official repositories.

Download it from here and the best way to do the change is to reinstall your system, so take a backup of your /home directory and any configuration files you want to save ( f.e. /etc /var ).