When I started helping out with Crosswords, JRB taught me a valuable lesson: before implementing a non-trivial feature, or doing a non-trivial change, one should first write a document with the design of the feature. It doesn't have to be anything formal; just an explanation of where you are coming from, the point to which you want to get, and a little technical detail if appropriate. You can then discuss the feature based on the document itself before going down the rabbit hole of actually implementing it.

Over time, these little documents form a high-level technical overview of the thing you are building; a sort of development history with less irrelevant detail than commit logs.

You can see examples of these little documents in the repository for Crosswords.

I started to do this for the things I wanted to implement in Crosswords, but then in librsvg as well and later in at-spi2-core, too. Normally I keep unpublished documents with lots of personal notes on things I want to implement; JRB's tip gave me an excuse to actually make them readable and publish them.

While I was documenting the initial CI for at-spi2-core, and while looking for resources on code coverage setups, I ran into the Firefox Source Tree Documentation and also the Guide to Rustc Development. Both have tours of sections of their respective code bases, they document development procedures — that sort of thing. Perfect!

May I present to you:

• Development guide for librsvg
• Development guide for the accessibility infrastructure

Both documents are generated from text files in their respective repositories. The rendered documents get published from the CI pipeline, at the same time as the API reference guides. Hopefully the documents can be kept up to date right there as one works on the code, instead of being written once and then rotting in a wiki.

This is already yielding fruit. My Outreachy intern for the December 2022 round was able to get started with librsvg's development and I didn't even have to tell them how to get started, because the development guide has a section on setting up a development environment. The Outreachy project for performance tracking in librsvg is also detailed there. The guide for at-spi2-core gives me a place to link to obscure knowledge, as well as to keep reference material for ourselves.

Technical details: both documents are in reStructuredText, and processed with Sphinx, as that seemed well-maintained enough. Using something like mdbook would also work fine.

I am not as comfortable with reStructuredText and Sphinx as I am with Markdown, so if anyone has tips for how to make the docs look prettier (in particular, the table of contents in at-spi2-core's guide is terrible), I'd appreciate your comments!

I also have to actually go and turn the Crosswords documents into a book.

(Remember Code Hospitality? Yeah, exactly that.)

Adding clarity to commit messages significantly helps fellow developers, and this short blog will share some best practices for writing quality commit messages for openSUSE and open-source contributions.

Commit messages communicate vital information between team members, and since open-source software is one big team focusing on open collaboration, it’s imperative to communicate context in these messages.

Why?

The “Why?” may be obvious to you now, but it might not be to others; especially those who might not even be involved yet with your code. Well-crafted commit messages help developers remember aspects of a previous commit and help future developers understand what changed and the purpose for the change. 

Commit messages can be considered unstructured and inconsistent, but these messages can make a world of difference with a little time and care. Think about writing commit messages in a way that is straight and to the point; kind of like a drill sergeant giving commands or instructions. Polish your boots. Clean the latrine. Do push ups. Being more specific, think about a parent telling their child what to do and for what reason. Clean the stove because the cooking oil you spilled on it can cause a fire for the next person using it.

Below are some other helpful hints for writing good commit messages.

Important bits:

• Include “Why” in the commit message in addition to “What” (Create a message that provides value)

• Don’t just link to bugtrackers, because these can become unaccessible later (“Nothing endures but change” - Heraclitus, ancient Greek philosopher)

• Bonus points for stylistic consistency

  • Capitalize first letter (Unless that first word is openSUSE) :wink:

  • Use Imperative form (Imperative form isn’t a rude form of expression; it’s detailed and provides clarity, just like the headline of this blog)

  • No trailing dot in summary

  • Limit line length (A good rule is to keep the characters use low; around 50 for the first line)

For those that are interested in more details, there is an extensive amount of helpful hints at https://cbea.ms/git-commit/.

Right in time for the holiday season, we have prepared you a gift for the continuous integration between OBS and SCMs. We are introducing placeholder variables and for your workflows configuration files, a customizable location. Let’s see how this new flexibility helps you in your work. We started off the continuous integration between OBS and GitHub/GitLab in May 2021, then made some improvements in June 2021. We introduced advanced features like reporting filters and support...

It is true, you can indeed play Fortnite on the SteamDeck and it is not so difficult to make happen. It does require a moderately stable Internet connection and of course, like anything online, your results may vary. There are many other guides out there, I know, I have read many of them and decided … Continue reading Fortnite on the SteamDeck →

It is true, you can indeed play Fortnite on the SteamDeck and it is not so difficult to make happen. It does require a moderately stable Internet connection and of course, like anything online, your results may vary. There are many other guides out there, I know, I have read many of them and decided […]

The openSUSE Board Election 2022 ran for 15 days — starting on 1 December until 15 December. Electronic voting in the election ended at 23h59 UTC on 15 December.

In the early hours of Friday 16 December the results were computed and emailed to all voters. The results were also publicly announced on the project's mailing list.

There were 544 eligible voters in the election and 218 voters have cast their votes.

Results

Candidate Name	No. of Votes
Gertjan Lettink	135
Douglas Demaio	130
Neal Gompa	115
Patrick Fitzgerald	97
Chuck Payne	50
Nathan Wolf	47
None of the above	4

Thus, the elected Board members are:

1. Gertjan Lettink
2. Douglas Demaio
3. Neal Gompa

I wish the (re)-elected candidates good luck ahead and thank all the other candidates who stepped up for this election.

Dear Tumbleweed users and hackers,

We’re slowly reaching the end of the year, and some people have less time for openSUSE, as the holiday season is upon us. Others use their free time from work to contribute more time to openSUSE. In any case, we’re not seeing any slowdown just yet and Tumbleweed keeps moving, again with 7 snapshots released during this week (1209…1215).

The main changes in these snapshots are:

• KDE Gear 22.12.0
• KDE Frameworks 5.101.0
• Linux kernel 6.0.12
• Python 3.10.9
• RPM 4.18.0
• systems 252.3
• GNOME Shell & Mutter 43.2
• Xen 4.17.0
• git 2.39.0
• Protobuf 21.11
• strace 6.1
• pipewire 0.3.62
• procps 4.0.2: the default install remains with procps 3 for now. The last tests showed that things like salt did not like procps4, thus we only offer it as an addon for now, and to help identify issues
• pcre2 10.42
• gcc13: first round: we change the libraries (like libgcc, libstdc++, …) to be provided by gcc13.The compiler used is still gcc12

With GCC 13 library switch done, one of the more complex stagings could be checked in, leaving room for all the rest. Currently, we’re testing submissions in these areas:

• Linux kernel 6.1
• Boost 1.81.0: breaks libetonyek and libreoffice
• util-linux 2.38.0
• Ruby 3.2 (currently RC) is being tested to become the default ruby version (switch would happen when ruby 3.2 sees a final release)
• Switch to openSSL 3: tracked in Staging:N, main failures are nodejs18, nodejs19, OpenSSH, mariadb
• Python pytest 7.2.0

Updates for sound, image and system components arrived this week throughout several openSUSE Tumbleweed snapshots, and the arm images are rolling again, according to notes from the project’s release engineering meeting.

For those NVIDIA users, testers with aarch64 servers and NVIDIA cards are wanted. Proprietary drivers are now available for aarch64, which is only for the G06 version.

Snapshot 20221214 might bring a smile to people’s face as the GNOME webcam application cheese updated from the 43 Alpha version to 43.0; the transition to the new version involves removing glibc-debug environment variables and updating translation. Online webcam users will also sound better as both pipewire 0.3.62 and wireplumber 0.4.13 updated in the snapshot. The updated PipeWire version fixed regressions in screen sharing that was caused by a race when activating links and driver nodes. Support for bluetooth offloading was added that allows for the reception, decoding and playback to happen completely in hardware, which required some support found in the WirePlumber update. The git control system updated to version 2.39.0. The minor version expanded git grep checkouts and had some changes for get branch for editing a branch before switching. Other packages to update in the snapshot were strace 6.1, dracut, kdump and more.

A couple GNOME packages were updated in snapshot 20221213. Besides updates to the 43.2 versions of gnome-shell, which had multiple fixes including one to the screencasting User Interface (UI) being erroneously disabled, and mutter, which fixed recalculating the viewport after a windows resize for a display server, the snapshot was filled with an enormous amount of RubyGems. Among those, rubygem-ruby-parser 3.19.2 fixed bug parsing array patterns; rubygem-regexp-parser 2.6.1 fixed the scanning of two negative lookbehind edge cases; rubygem-puma 6.0.0 is dropping Ruby 2.2 and 2.3 support; and rubygem-bootsnap 1.15.0 added a read-only mode for environments where the updated cache would not be persisted. Several other RubyGems were updated in the snapshot as well as a couple Perl packages.

If 20221213 was a RubyGems snapshot, then snapshot 20221212 was a KDE Frameworks snapshot. Frameworks 5.101.0 was made available to rolling release users within 48 hours of its release. The bug fixing released deprecated a few aspects of the KWindowSystem package and moved X11-specific functions to a new KX11Extras class. The KTextEditor fixed a default setting mark when ctrl is pressed. The Kirigami UI framework fixed many memory leaks caused by Qt.createComponent. The action button also fixed broken attached properties due to import changes. A few other behaviors were deprecated with the KIO system library that provides access to files, web sites and other resources. The lightweight display manager lightdm updated for version 1.32.0. The package made use of Python 3 in tests and improved upon methods of determining a Wayland session.

Two GNOME packages were updated in the snapshot. There were updated translations in gnome-characters 43.1 and the package also updated to Unicode 15. Translations came in the update of gnome-remote-desktop 43.2 as well, and it removed a stray line of new code. The arpwatch-ethercodes 20221212 package also updated in the snapshot, but lacked any commit messaging. A Common Vulnerability and Exposure was fixed with the rpm 4.18.0 update. CVE-2021-35938 was fixed and would occur when rpm sets desired permissions and credentials after installing a file. A local unprivileged user could have used the flaw to exchange the original file with a symbolic link to a security-critical file and escalate their privileges on the system. A few other packages were updated in the snapshot.

Just one package was updated in snapshot 20221211. The libass 0.17.0 version, which is a portable subtitle renderer for Advanced Substation Alpha/Substation Alpha subtitle format, fixed various parts related to automatic line breaks. The release had a major feature, which appears to be related to LayoutResX and LayoutResY headers.

Snapshot 20221210 had a Linux Kernel update. The 6.0.12 kernel-source fixed a wifi buffer overflow related to cfg80211 subsystem and fixed error handling. An update of systemd 252.3 dropped a patch and added a few backports. Text editor vim 9.0.1040 had a multitude of changes; it had a fix for when kitty keyboard function keys may not work, and it had a fix for when tests may get stuck in a buffer with a swap file. An update of Xen took care of CVE-2022-33746, which added some pre-emptive checks that were needed. Other packages to update were libpaper 2.0.4, wavpack 5.6.0 and yast2-kdump 4.5.7.

Starting off the week, audacity 3.2.2 was updated in snapshot 20221209. The update fixed a crash when editing some macro parameters, and it no longer quietly discards changes but instead asks if changes should be saved before quitting. The package also fixed some play commands getting stuck in play mode. Another KDE update that landed in the snapshot the day after its upstream release was Gear 22.12. A new feature in the release is a Selection Mode; hit the spacebar or tap the hamburger menu and check the select files and folders checkbox and a light green bar will appear. Text editor Kate added a welcome window when launching and the new window allows for the creation of a new file, an opening of an existing file from a list of recent files, and it offers some documentation. Video production editor Kdenlive improved its integration with other video applications, and users can now send Kdenlive timelines as backgrounds to the vector animation utility Glaxnimate. The yast2-users 4.5.3 version was also updated in the snapshot.

The openSUSE Project will have a workshop on Jan. 10 at 15:30 UTC at meet.opensuse.org/meeting that will focus on increasing mentorship for this year’s Google Summer of Code.

There is a long tradition of the openSUSE Project participating in the GSoC and community members that want to participate as either a mentor or mentee are encouraged to attend.

The workshop gives attendees a chance to generate project ideas and list them on 101.opensuse.org for this year’s application, which is open between Jan. 23 and Feb 7.

The workshop will give mentors, mentees and people who would like to get involved with mentoring enough time to describe several project ideas before the administrators submit the GSoC application.

Participants are encouraged to create an outline of some project ideas before the workshop on the event’s etherpad.

Mentors, mentees and administrators who participated in previous Google Summer of Code programs will attend the workshop.

Welcome to the third part of my syslog-ng tutorial. Today we cover the various syslog-ng editions (open source, commercial and appliance), and where to get them from. The focus of this tutorial series is the Open Source Edition (OSE), but to avoid confusion, I also briefly introduce the other two.

You can watch the video on YouTube:

Or you can read the rest of my blog at: https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-101-part-3-syslog-ng-editions-and-where-to-get-them-from

This is a boring, but important part, do not skip it! :) From the next part the focus will be configuration.