The openSUSE Project participated in this year’s Google Summer of Code along with several mentoring organizations.

Six of the seven accepted projects were successfully completed and mentors of the participating projects helped students improve their programming skills and knowledge of open source over the 10-week program.

Let’s review the contributions!

The first contribution we will cover involves the Uyuni Project. The purpose of the project was converting the JSP code of virtual systems pages to ReactJS. Improving the User Interface of freshly created virtual systems page resulted in a Pull Request 4152 that is listed as work in progress and is nearing completion.

Another contribution focused on improving the IBus themes to make it separate from the current GNOME-Shell theme and GTK theme. This will allow users to customize it with other GNOME-Shell themes and GTK themes. Three community members helped mentor. The student, Songlin Jiang, listed the entire GSoC experience on the Hollow Man’s Blog.

Another student blogging about their experience was Quinn Okabayashi from Swarthmore College. Quinn listed several Pull Requests on his blog while working on the identity management platform written in Rust called Kanidm. Quinn lists the code and details on the My project: integrating Tokio tracing into Kanidm blog.

More Rust code contributions were served up in this year’s GSoC as PRoot was looking to implement a prototype version of PRoot with the Rust language. The project was looking at the most basic features. Daily reports were published and a comprehensive overview can be found on GitHub Gist.

This year Rancher participated in GSoC with openSUSE as the mentoring organization. The mentor and student were focused on building complex logging pipelines by writing Kubernetes custom resource configurations. The goal was to create a tool that would capture a log stream from a running pod and let the users replay it as they desire while correlating those logs with Flow resource specs and highlighting the applied filters. Users could easily understand how the Logging Operator interacts with their application and fine-tune it to their liking. The month of August is filled with excellent contributions from Isala Piyarisi.

Kanidm had another project in this year’s GSoC and the final month of August was several commits from student victorcwai. There were two deliverables for the identity management platform by victorcwai. The first proposed using a Backup code to restore single-device accounts. Authenticated users could generate the Backup code and use it later. When they want to login, they can replace the TOTP/WebAuthn challenge with Backup code. For example, TOTP + password auth will be Backup code + password instead. The second deliverable was integrating the async-std library on OpenSSL and the Rust web framework tide to have an async library of openssl and tide ssl listener with the async-std runtime. A list of the pull requests and an overview of the project were published on victorcwai’s blog.

The openSUSE Project has participated in several GSoC events since 2006 and the project’s mentors have helped more than 60 students become free software developers. The project is always looking for community members who are interested in mentoring for GSoc and can email ddemaio@opensuse.org if they want to help mentor.

My first encounter with a digital camera was around 1996 when my university IT department acquired the Apple Quicktake 100. While the quality of the output was laughable compared to the analog counterparts, the convenience of such a device was clear. It wasn’t too long after that when I got my first digital camera, the Ricoh RDC-5000 which I used to capture the new worlds I vistited. Many devices followed.

Ever since I switched from photo to video as my default media format of capturing places and moments, there have been three major attributes I would seek out of a camera. A nice separation of subjects using shallow depth of field, a dreamy slow motion look using high frame rates and a pleasing image using optical or electronic stabilization.

All of these fields have been getting steady improvements and I always fantasize how my young self would react to seeing footage taken from a tiny little rectangle I carry around in my pocket. It is just incredible that the footage below is hand held and the cameraman is not driving a onewheel or using a gimbal, steadycam or some other aid. Just ninja walking. When do we stop calling these magic bricks phones?

Skate Your Name: Patrik from jimmac on Vimeo. Music arranged on Polyend Tracker.

The device driver for the Canon Pixma TR4540 All-in-one Printer/Scanner does not come bundled with openSUSE, whether you are on Leap or Tumbleweed. It is non available from the official repositories as well, at least I didn't find them, neither on openSUSE Non-OSS or Packman repos.

However, Canon provides the drivers on its website along with an installation script. The tarball containing the the .rpm files and the script can be from its package-archive. At the time that I tested, the driver package was at version 5.70.

Extract the files.

tar xzvf cnijfilter2-5.70-1-rpm.tar.gz

Then, change in to the cnijfilter2-5.70-1-rpm directory and run the installation script as the root user.

cd cnijfilter2-5.70-1-rpm && sudo ./install

Finally, follow the on-screen (CLI) instructions to complete the setup.

That's it! Your Canon Pixma TR4540 setup should be complete & ready to use.

Dear Tumbleweed users and hackers,

This week has shown that Tumbleweed is indeed back at full speed. We have published new snapshots daily. Of course, that also means we could rely on not receiving broken things that managed to slip through stagings without being noticed. So thanks go mostly to the developers/maintainers who submitted pre-tested things. And openQA of course!
The snapshots were numbered 0826…0901.

The most notable changes during this week included:

• The missing pieces of the GNOME 40.4 update (complete now)
• rpmlint 2.1
• openssl 1.1.1l
• pipewire 0.3.34
• Linux kernel 5.13.13

The staging projects are currently filled with those major changes:

• Mesa 21.2.1
• Mozilla Firefox 91.0.2
• systemd 249.4
• Linux kernel 5.14.0
• KDE Plasma 5.22.5
• KDE Applications 21.08.1
• glibc 2.34: bug tracking remaining failures: boo#1189079
• shadow 4.9: boo#1190145 and boo#1190146

Snapshot releases of openSUSE’s rolling release Tumbleweed have been constantly trickling out to users since last week’s review.

This review will cover the five snapshots made available since August 26. Each of the snapshots delivered about a handful of updated software packages.

Snapshot 20210831 updated bind to version 9.16.20, which fixed a Common Vulnerability and Exposure; CVE-2021-25218 an assertion failure could have allowed an attacker to abused the Path Maximum Transmission Unit Discovery protocol to trick bind into exceeding the interface MTU. The C Library for manipulating module metadata files libmodulemd updated to 2.13.0 and the modulemd-validator enables a user to constrain a document type with a new --type option. The other packages to update in the snapshot were libqmi 1.28.8 and libjpeg-turbo 2.1.1, which fixed a couple regressions affecting AArch64 and arm 32-bit hardware.

Linux Kernel 5.13.13 was one of the two packages updated in the 20210830 snapshot. The Direct Rendering Manager had some fixes in the kernel update and added an AAL output size configuration. The kernel update also had an Advanced Linux Sound Architecture enablement for the 4-speaker output in the Dell XPS 15 9510 laptop. The other package to update in the snapshot was perl-Image-ExifTool, which had a version bump to 12.30.

Two CVEs were addressed in the update of OpenSSL to version 1.1.1l in snapshot 20210828; one of the CVEs fixed an SM2 Decryption Buffer Overflow that could have allowed for the possibility of changing an application’s behaviour or causing an application to crash. Internal latency of ALSA devices can now be configured with the new PipeWire 0.3.34 version and Tumbleweed enabled the usage of libcamera in the audio and video package to allow for some experimental support. Network protocol analyzer Wireshark 3.4.8 provided a handful of fixes; one of the fixes addressed a dissector bug when processing a Bluetooth Handle Value Notification. Other packages updated in the snapshot were libgcrypt 1.9.4, libssh 0.9.6, pkgconf 1.8.0, python-aioitertools 0.8.0 and yast2-installation 4.4.17, which killed a lot of YCP zombies; YCP is the language YaST was originally written in before moving to Ruby.

Sound artists and musicians can use an updated Audacity that came in snapshot 20210827. The 3.0.4 version of Audacity fixed a compatibility issue with GNU Compiler Collection 11; it also provided some crash fixes affected by the use of multiplied envelope points when using Filter Curve EQ or Graphic EQ. A version bump was made to gnome-desktop 40.4. Eight months worth of mobile-broadband-provider-info updates were in the snapshot and the 20210805 version improved services providers in Europe, Africa and the Americas. Other packages to update in the snapshot were three RubyGems packages, ncurses 6.2.20210814 and publicsuffix 20210823.

Snapshot 20210826 wasn’t covered in the last Tumbleweed blog. The snapshot updated libopenmpt 0.5.11, package management library libzypp 17.28.1, USB network protocol usbredir 0.11.0, the file system debugging tool xfsprogs 5.13.0 and yast2-add-on 4.4.1.

"Themes in GNOME" is a complicated topic in technical and social terms. Technically there are a lot of incomplete moving parts; socially there is a lot of missing documentation to be written, a lot of miscommunication and mismatched expectations.

The following is a brief and incomplete, but hopefully encouraging, summary of the status of themes in GNOME. I want to give you an overall picture of the status of things, and more importantly, an idea of how you can help. This is not a problem that can be solved by a small team of platform developers.

I wish to thank Alexander Mikhaylenko for providing most of the knowledge in this post.

Frame of reference

First, I urge you to read Cassidy James Blaede's comprehensive "The Need for a FreeDesktop Dark Style Preference". That gives an excellent, well-researched introduction to the "dark style" problem, the status quo on other platforms, and exploratory plans for GNOME and Elementary from 2019.

Go ahead, read it. It's very good.

There is also a GUADEC talk about Cassidy's research if you prefer to watch a video.

Two key take-aways from this: First, about this being a preference, not a system-enforced setting:

I’m explicitly using the language “Dark Style Preference” for a reason! As you’ll read further on, it’s important that this is treated as a user “preference,” not an explicit “mode” or strictly-enforced “setting.” It’s also not a “theme” in the sense that it just swaps out some assets, but is a way for the OS to support a user expressing a preference, and apps to respond to that preference.

Second, about the accessibility implications:

Clearly there’s an accessibility and usability angle here. And as with other accessibility efforts, it’s important to not relegate a dark style preference to a buried “Universal Access” or “Accessibility” feature, as that makes it less discoverable, less tested, and less likely to be used by folks who could greatly benefit, but don’t consider themselves “disabled.”

Libadwaita and the rest of the ecosystem

Read the libadwaita roadmap; it is very short, but links to very interesting issues on gitlab.

For example, this merge request is for an API to query the dark style and high-contrast preferences. It has links to pending work in other parts of the platform: libhandy, gsettings schemas, portals so that containerized applications can query those preferences.

As far as I understand it, applications that just use GTK3 or libhandy can opt in to supporting the dark style preference — it is opt-in because doing that unconditionally in GTK/libhandy right now would break existing applications.. If your app uses libadwaita, it is assumed that you have opted into supporting that preference, since libadwaita's widgets already make that assumption, and it is not API-stable yet — so it can make that assumption from the beginning.

There is discussion of the accessibility implications in the design mockups.

CSS parity across implementations

In GNOME we have three implementations of CSS:

• librsvg uses servo's engine for CSS selector matching, and micro-parsers for CSS values based on servo's cssparser.

• GTK has its own CSS parser and processor.

• Gnome-shell uses an embedded version of libcroco for parsing, but it does most of the selector matching and cascading with gnome-shell's own Shell Toolkit code.

None of those implementations supports @media queries nor custom properties with var(). That is, unlike in the web platform, GNOME applications cannot have this in their CSS:

@media (prefers-color-scheme: dark) {
  /* styles for dark style */
}

@media (prefers-color-scheme: light) {
  /* styles for light style */
}

Or even declaring colors in a civilized fashion:

:root {
  --main-bg-color: pink;
}

some_widget {
  background-color: var(--main-bg-color);
}

Or combining the two:

@media (prefers-color-scheme: dark) {
  :root {
    --main-bg-color: /* some nice dark background color */;
    --main-fg-color: /* a contrasty light foreground */;
  }
}

@media (prefers-color-scheme: light) {
  :root {
    --main-bg-color: /* some nice light background color */;
    --main-fg-color: /* a contrasty dark foreground */;
  }
}

some_widget {
  background-color: var(--main-bg-color);
}

Boom. I think this would remove some workarounds we have right now:

• Just like GTK, libadwaita generates four variants of the system's stylesheet using scss (regular, dark, high-contrast, high-contrast-dark). This would be obviated with @media queries for prefers-color-scheme, prefers-contrast, inverted-colors as in the web platform.

• GTK has a custom @define-color keyword, but neither gnome-shell nor librsvg support that. This would be obviated with CSS custom properties - the var() mechanism. (I don't know if some "environmental" stuff would be better done as env(), but none of the three implementations support that, either.)

Accent colors

They are currently implemented with GTK's @define-color, which is not ideal if the colors have to trickle down from GTK to SVG icons, since librsvg doesn't do @define-color - it would rather have var() instead.

Of course, gnome-shell's libcroco doesn't do @define-color either.

Look for @accent_color, @accent_bg_color, @warning_color, etc. in the default stylesheet, or better yet, write documentation!

The default style:

Accent color set to orange (e.g. tweak it in GTK's CSS inspector):

/* Standalone, e.g. the "Page 1" label */
@define-color accent_color @orange_5;

/* background+text pair */
@define-color accent_bg_color @orange_4;
@define-color accent_fg_color white;

Custom widgets

Again, your app's custom stylesheet for its custom widgets can use the colors defined through @define-color from the system's stylesheet.

Recoloring styles

You will be able to do this after it gets merged into the main branch, e.g. recolor everything to sepia:

@define-color headerbar_bg_color #eedcbf;
@define-color headerbar_fg_color #483a22;

@define-color bg_color #f9f3e9;
@define-color fg_color #483a22;

@define-color dark_fill_color shade(#f9f3e9, .95);

@define-color accent_bg_color @orange_4;
@define-color accent_color @orange_5;

Of course shade() is not web-platform CSS, either. We could keep it, or redo it by implementing calc() function for color values.

Recoloring icons

Currently GTK takes some defined colors and creates a chunk of CSS to inject into SVG for icons. This has some problems.

There is also some discussion about standardizing recolorable icons across desktop environments.

How you can help

Implement support for @media queries in our three CSS implementations (librsvg, gnome-shell, GTK). Decide how CSS media features like prefers-color-scheme, prefers-contrast, inverted-colors should interact with the GNOME's themes and accessibility, and decide if we should use them for familiarity with the web platform, or if we need media features with different names.

Implement support for CSS custom properties - var() in our three CSS implementations. Decide if we should replace the current @define-color with that (note that @define-color is only in GTK, but not in librsvg or gnome-shell).

See the libadwaita roadmap and help out!

Port applications to use the proposed APIs for querying the dark style preference. There are a bunch of hacky ways of doing it right now; they need to be migrated to the new system.

Personally I would love help with finishing to port gnome-shell's styles to Rust - this is part of unifying librsvg's and gnome-shell's CSS machinery.

Collecting process accounting logs on Linux with syslog-ng

Process accounting logs are collected into binary log files on Linux. You can turn them into human readable format locally, using various tools. You can also use syslog-ng to read those files.

Lean how syslog-ng can parse those binary logs, create name-value pairs from them and store the results from my latest blog: https://www.syslog-ng.com/community/b/blog/posts/collecting-process-accounting-logs-on-linux-with-syslog-ng

Most people only know that I work in IT. Some even call me a hacker – which I really appreciate :-) However, by university degree I am an environmental engineer (and English - Hungarian translator). Even if I never worked in my field, except for some student jobs, I still follow any news related to the environment closely. This is why I was very happy to learn, that my home city, Budapest, introduced bee pastures in the city.

Bee pastures

So, what are bee pastures? Most people expect that public areas in a city have shortly cut grass. It is convenient for humans, you can walk on it, you can play games on it or bask in the sun. The price is that it needs to be cut regularly and there are no flowers: bees cannot eat there. Bees have an essential role in our ecosystems. Unfortunately, the area where they eat and live is continuously shrinking, due to humans. Establishing bee pastures, areas with the right mix of flowering plants can help the bee population to survive and grow. Establishing bee pastures in selected areas of cities can help in multiple ways. It helps the bees, it looks nice and can also save costs on lawn mowing.

Where it went wrong in Budapest

Turning a grass area into bee pasture does not mean that it does not need maintenance any more. It just means less frequent maintenance. Of course, there are also some properly maintained bee pastures in Budapest. The problem is, that in most cases, in practice it means an area with a “Bee Pasture” sign and completely left alone. In real life I have only seen this problematic version, where behind the “Bee Pasture” sign one could only see overgrown areas, full of highly allergenic plants.

My Facebook post

Facebook is aware, that I like reading about environmental issues. So, one of the posts on my time line was a photo from the UK, which showed bee pastures on the streets and parks of a small town. It looked like what you would expect when someone mentions bee pasture. I shared the photo with a short text: “This is a fantastic idea, and there are places where they do this properly”.

Offending two sides

So, where is the problem? If you read so far, you can see that I support a progressive idea and criticize how it is carried out. The discussion below my post grew into a flame-war. To understand why, here is some background information. The “bee pasture” idea came from the leaders of the city of Budapest, led by a major opposition figure. What does it mean? Anyone supporting the opposition parties support bee pastures, even if in practice it means large fields of allergenic plants. Anyone supporting the governing party considers the bee pasture idea crazy, even where it is implemented properly. My post offended both sides, as I supported an opposition idea, but I criticized how it was implemented.

This post was only shared with my Facebook friends. Still, after a few days my post was reported enough times to be deleted.

How does it come to an IT blog?

You might wonder how this story is related to IT, the primary focus of my blog. It is related. Most of the time I am independent. There are hot debates in IT as well, where I avoid taking a side – at least publicly. If I need to write about the topic publicly for example to inform syslog-ng users in a question, I keep a safe distance from all sides involved. I do not judge who is good, who is bad, just focus on how the given problem affects syslog-ng users. Just to mention a few:

• ElasticSearch vs. OpenSearch – the most frequently used log destination in syslog-ng
• RHEL vs. CentOS Stream vs. CentOS replacements – the most frequently used operating system to run syslog-ng

Taking a side, seeing everything in black and white is easier: less thinking, feeling of belonging. But that’s not how I work in IT or in real life.

You can also make a difference if you have a garden. Make sure that you have some flowering plants in parts of your garden all around the year. And avoid using chemicals as much as possible.