Fedora People

CPE Weekly Update – Week 4 2023

Posted by Fedora Community Blog on January 27, 2023 10:00 AM

This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on libera.chat.

We provide you both infographics and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.

Week: 23 – 27 January 2023

<figure class="aligncenter size-full">CPE infographic</figure>

Highlights of the week

Infrastructure & Release Engineering

Goal of this Initiative

Purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible initiatives that CPE might take on.
Planning board


Fedora Infra

  • Got IMA signing actually working (before mass rebuild)
  • Fixed eventsource on pagure.io (the thing that updates tickets in your browser when someone else does an update)
  • Hopefully stablized proxies from a out of files issue.
  • Started in on rhel9 upgrades

CentOS Infra including CentOS CI

Release Engineering

  • Mass rebuild of packages got merged into rawhide
  • Mass rebuild of modules underway

CentOS Stream

Goal of this Initiative

This initiative is working on CentOS Stream/Emerging RHEL to make this new distribution a reality. The goal of this initiative is to prepare the ecosystem for the new CentOS Stream.


  • Getting ready for a talk at CentOS Connect in Brussels next week
  • Working on a new Firefox build for CentOS Stream 8
  • CentOS Stream 8 workflow:
    • Production compose not only builds, but goes to staging now.
    • Container workflow now works (not pushed  to quay/centos yet)


Goal of this initiative

Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL).

EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more.


FMN replacement

Goal of this initiative

FMN (Fedora-Messaging-Notification) is a web application allowing users to create filters on messages sent to (currently) fedmsg and forward these as notifications on to email or IRC.
The goal of the initiative is mainly to add fedora-messaging schemas, create a new UI for a better user experience and create a new service to triage incoming messages to reduce the current message delivery lag problem. Community will profit from speedier notifications based on own preferences (IRC, Matrix, Email), unified fedora project to one message service and human-readable results in Datagrepper.
Also, CPE tech debt will be significantly reduced by dropping the maintenance of fedmsg altogether.


  • Merged part of the work on caching, heading towards the final pieces to be built before deploying to staging
  • From there we will test that this does not bog down internal systems such as dist-git, FAS-JSON, etc
  • Schema work continuing – adding features to apps with fedora-messaging schemas already that are required, adding schemas to apps that dont, etc

Community Design

Goal of this initiative

CPE has few members that are working as part of Community Design Team. This team is working on anything related to design in Fedora Community.


The post CPE Weekly Update – Week 4 2023 appeared first on Fedora Community Blog.

Enable rootless podman on Fedora

Posted by Pablo Iranzo Gómez on January 27, 2023 08:00 AM
With podman we can setup containers for being used for non root users by performing some simple steps: Install required packages dnf -y install slirp4netns fuse-overlayfs crun podman shadow-utils Force the number of user namespaces (might be required on some environments): echo "user.max_user_namespaces=28633" > /etc/sysctl.d/userns.conf sysctl -p /etc/sysctl.d/userns.conf Delegate Allows to define which resources are available1: mkdir -p /etc/systemd/system/user@.service.d cat << EOF > /etc/systemd/system/user@.service.d/delegate.conf [Service] Delegate=cpu cpuset io memory pids EOF To verify it has been done correctly, logout and login with the user and execute:

Using .NET 7 on Fedora Linux

Posted by Fedora Magazine on January 27, 2023 08:00 AM

.NET 7 is now available in Fedora Linux. This article briefly describes what .NET is, some of its recent and interesting features, how to install it, and presents some examples showing how it can be used.

.NET 7

.NET is a platform for building cross platform applications. It allows you to write code in C#, F#, or VB.NET. You can easily develop applications on one platform and deploy and execute them on another platform or architecture.

In particular, you can develop applications on Windows and run them on Fedora Linux instead! This is one less hurdle if you want to move from a proprietary platform to Fedora Linux. It’s also possible to develop on Fedora and deploy to Windows. Please note that in this last scenario, some Windows-specific application types, such as GUI Windows applications, are not available.

.NET 7 includes a number of new and exciting features. It includes a large number of performance enhancements to the runtime and the .NET libraries, better APIs for working with Unix file permissions and tar files, better support for observability via OpenTelemetry, and compiling applications ahead-of-time. For more details about all the new features in .NET 7, see https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-7.

Fedora Linux builds of .NET 7 can even run on the IBM Power (ppc64le) architecture. This is in addition to support for 64-bit ARM/Aarch64 (which Fedora Linux calls aarch64 and .NET calls arm64), IBM Z (s390x) and 64-bit Intel/AMD platforms (which Fedora Linux calls x86_64 and .NET calls x64).

.NET 7 is a Standard Term Support (STS) release, which means upstream will stop maintaining it on May 2024. .NET in Fedora Linux will follow that end date. If you want to use a Long Term Support (LTS) release, please use .NET 6 instead. .NET 6 reaches its end of Life on November 2024. For more details about the .NET lifecycle, see https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core.

If you are looking to set up a development environment for developing .NET applications on Fedora Linux, take a look at https://fedoramagazine.org/set-up-a-net-development-environment/.

The .NET Special Interest Group (DotNetSIG) maintains .NET in Fedora Linux. Please come and join us to improve .NET on Fedora Linux! You can reach us via IRC (#fedora-devel) or mailing lists (dotnet-sig@lists.fedoraproject.org) if you have any feedback, questions, ideas or suggestions.

How to install .NET 7

To build C#, F# or VB.NET code on Fedora Linux, you will need the .NET SDK. If you only want to run existing applications, you will only need the .NET Runtime.

Install the .NET 7 Software Development Kit (SDK) using this command:

sudo dnf install -y dotnet-sdk-7.0

This installs all the dependencies, including a .NET runtime.

If don’t want to install the entire SKD but just want to run .NET 7 applications, you can install either the ASP.NET Core runtime or the .NET runtime using one of the following commands:

sudo dnf install -y aspnetcore-runtime-7.0
sudo dnf install -y dotnet-runtime-7.0

This style of package name applies to all versions of .NET on all versions of Fedora Linux. For example, you can install .NET 6 using the same style of package name:

sudo dnf install -y dotnet-sdk-6.0

To make certain .NET 7 is installed, run dotnet –info to see all the SDKs and Runtimes installed.

License and Telemetry

The .NET packages in Fedora Linux are built from fully Open Source source code. The primary license is MIT. The .NET packages in Fedora Linux do not contain any closed source or proprietary software. The Fedora .NET team builds .NET offline in the Fedora Linux build system and removes all binaries present in the source code repositories before building .NET. This gives us a high degree of confidence that .NET is built from reviewed sources.

The .NET packages in Fedora Linux do not collect any data from users. All telemetry is disabled in the Fedora builds of .NET. No data is collected from anyone running .NET and no data is sent to Microsoft. We run tests to verify this for every build of .NET in Fedora Linux.

“Hello World” in .NET

After installing .NET 7, you can use it to create and run applications. For example, you can use the following steps to create and run the classic “Hello World” application.

Create a new .NET 7 project in the C# language:

dotnet new console -o HelloWorldConsole

This will create a new directory named HelloWorldConsole and create a trivial C# Hello World that prints hello world.

Then, switch to the project directory:

cd HelloWorldConsole

Finally, build and run your the application:

dotnet run

.NET 7 will build your program and run it. You should see a “Hello world” output from your program.

“Hello Web” in .NET

You can also use .NET to create web applications. Lets do that now.

First, create a new web project, in a separate directory (not under our previous project):

dotnet new web -o HelloWorldWeb

This will create a simple Hello-World style application based on .NET’s built-in web (Empty ASP.NET Core) template.

Now, switch to that directory:

cd HelloWorldWeb

Finally, build and run the application:

dotnet run

You should see output like the following that shows the web application is running.

info: Microsoft.Hosting.Lifetime[14]
Now listening on: http://localhost:5105
info: Microsoft.Hosting.Lifetime[0]
Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
Content root path: /home/omajid/temp/HelloWorldWeb

Use a web browser to access the application. You can find the URL in the output at the “Now listening on:” line. In my case that’s http://localhost:5105:

firefox http://localhost:5105

You should see a “Hello World” message in your browser.

<figure class="wp-block-image size-full"></figure>

Using .NET with containers

At this point, you have successfully created, built and run .NET applications locally. What if you want to isolate your application and everything about it? What if you want to run it in a non-Fedora OS? Or deploy it to a public/private/hybrid cloud? You can use containers! Let’s build a container image for running your .NET program and test it out.

First, create a new project:

dotnet new web -o HelloContainer

Then, switch to that project directory:

cd HelloContainer

Then add a Dockerfile that describes how to build a container for our application.

FROM fedora:37
RUN dnf install -y dotnet-sdk-7.0 && dnf clean all
RUN mkdir /HelloContainer/
WORKDIR /HelloContainer/
COPY . /HelloContainer/
RUN dotnet publish -c Release
CMD ["dotnet" , "bin/Release/net7.0/publish/HelloContainer.dll"]

This will start with a default Fedora Linux container, install .NET 7 in it, copy your source code into it and use the .NET in the container to build the application. Finally, it will set things up so that running the container runs your application and exposes it via port 8080.

You can build and run this container directly. However, if you are familiar with Dockerfiles, you might have noticed that it is quite inefficient. It will re-download all dependencies and re-build everything on any change to any source file. It produces a large container image at the end which even contains the full .NET SDK. An option is to use a multi-stage build to make it faster to iterate on the source code. You can also produce a smaller container at the end that contains just your application and .NET dependencies.

Overwrite the Dockerfile with this:

FROM registry.fedoraproject.org/fedora:37 as dotnet-sdk
RUN dnf install -y dotnet-sdk-7.0 && dnf clean all

FROM registry.fedoraproject.org/fedora:37 as aspnetcore-runtime
RUN dnf install -y aspnetcore-runtime-7.0 && dnf clean all

FROM dotnet-sdk as build-env
RUN mkdir /src
COPY *.csproj .
RUN dotnet restore
COPY . .
RUN dotnet publish -c Release -o /publish

FROM aspnetcore-runtime as app
WORKDIR /publish
COPY --from=build-env /publish .
ENTRYPOINT ["dotnet", "HelloContainer.dll"]

Now install podman so you can build and run the Dockerfile:

sudo dnf install -y podman

Build the container image:

podman build -t hello-container .

Now, run the container we just built:

podman run -it -p 8080:8080 hello-container

A note about the arguments. The port is configured with the -p flag so that port 8080 from inside the container is available as port 8080 outside too. This allows you to connect to the application directly. The container is run interactively (-it) so you can see the output and any errors that come up. Running interactively is usually not needed when deploying an application to production.

Finally, connect to the container using a web browse. For example:

firefox http://localhost:8080

You should see a “Hello World” message.

Congratulations! You now have a .NET application running inside a Fedora container!


This was a whirlwind overview of .NET 7 in Fedora Linux and covers building and running an application using plain Fedora RPM packages as well as creating an application for a .NET application using only Fedora Linux.

If you have an interest in using or improving .NET on Fedora Linux, please join us!

Visit us in Brno for Linux App Summit 2023!

Posted by Felipe Borges on January 26, 2023 10:33 AM

We are excited to bring Linux App Summit 2023 to Brno, Czech Republic, from April 21st to 23rd!

This is a conference for the Desktop Linux community, GNOME, and KDE folk to discuss the future of our app ecosystem.

Brno is where me and a few other GNOMies live, and it is a tech hub in central Europe with lots of tech companies, open source communities, and universities. Brno hosted GUACEC in 2013, Akademy in 2014, and the LibreOffice Conference in 2016.

Getting here is easier by flying through the Vienna or Prague airports and taking a train to Brno. There are train and bus options from various other locations such as Berlin, Vienna, Warsaw, Bratislava.  We prepared a page with all you need to know about the trip.

The Call for Proposals is now open until February 18th. Don’t forget to submit your talk proposal on time! linuxappsummit.org/cfp

The Overtone Scale?

Posted by Adam Young on January 26, 2023 03:30 AM

If you look at the overtone series, specifically from the 8th to the 16th, you’lll notice that they fit into an octave and almost, but not quite, make up a major scale.. I’d like to look a little closer at that difference.

If we start on a C, the notes of the series are (almost)

C D E F# G Ab Bb B C

I say almost because they are not actually these notes…these are merely the closest approximations to the notes if you are playing a well-tempered clavier or its descendants. If you are playing something a little more flexible, such as a fretless string instrument like the violin, you can adjust your playing and play exactly these pitches.

The first thing that catches my eye in that series is that the fourth (F) is absent, and is replaced by the tritone (F#). This change alone would convert the scale from a Major to the Lydian Mode. This actually kind of explains how the Lydian mode is so bright: it is a half step closer to the harmonic series.

The other thing that I notice is that it has both the dominant and the major 7th. This change alone would convert the scale from a Major or Mixolydian mode to the Bebop Mixolydian.

If we use all eight notes and split them up into two alternating groups of four we get

C E G Bb and D F# Ab B

The first is the Dominant Seventh chord.

The second is could be written as Dmajor b5 13 but that really is a stretch. Maybe Bmin#13 is closer. Either way, it is a lot of tension.

These would be an interesting choice of chords to use for a four way close voice leading, alternating between them for runs up and down the scale. Or even just as a Lydian bebop scale. It does kind of explain why you can get away with a lot of leeway on a Dom7 chord…most of the intermediate notes are pretty closely relate overtone with to the primary chord tones.

I’m going to play around with it and see what I can do. I am not quite sure how to accompany, as there are several notes that need to be severely detuned to work right; the 11th, 13th, and 14 overtones are all >40 cents from the tempered tuning. We’ll want really flat tritones and the bebop note. We can also go with flat dominant sevenths or even harmonic sevenths. Although that really challenges the rules.

So, if we play on top of a C7 chord, the other overtone notes are the 9th, the Tritone, The #5 and the Major seventh. Not really “out there” from a jazz perspective, but maybe something to be aware of when selecting notes.

How have your social media habits changed since the Twitter takeover?

Posted by Joe Brockmeier on January 26, 2023 01:14 AM

It’s been a few months now since the Twitter Takeover, and Musk’s gutting of the Twitter workforce and various antics. I haven’t deleted my account, but I set it to private and set up shop on Mastodon in mid-November. Curious about what others have done and how your habits have changed (if at all). In the before-times, I’d check Twitter frequently and post and reply quite a few times per day. While a lot of folks I know set up Mastodon / ActivityPub identities, there doesn’t seem to be quite so much activity these days.

Some folks I follow still seem to be active on Twitter, but it seems like a lot of the “microblogging” activity has just stopped altogether. This might just be the circles I travel in, but I’m wondering if the impact will be a lot like Google Reader and RSS.

No, Google Reader didn’t single-handedly kill RSS. It’s still alive and well(ish) but after Reader died RSS seemed much less less vital.

Likewise, Mastodon (etc.) don’t seem to be replacing Twitter for folks who left or curtailed their use. Instead it seems like people are just getting out of the habit altogether.

That’s… not necessarily a bad thing. But I’d love to hear how other people’s social media habits have (or haven’t!) changed since the takeover.

The post How have your social media habits changed since the Twitter takeover? appeared first on Dissociated Press.

Upgrade of Copr servers

Posted by Fedora Infrastructure Status on January 25, 2023 01:00 PM

We're updating copr packages to the new versions which will bring new features and bugfixes.

This outage impacts the copr-frontend and the copr-backend.

Syslog-ng 101, part 5: Sources

Posted by Peter Czanik on January 25, 2023 12:17 PM

This is the fifth part of my syslog-ng tutorial. Last time we had an overview of the syslog-ng configuration and had our first steps working with syslog-ng. Today we learn about syslog-ng source definitions and how to check the syslog-ng version and its enabled features.

You can watch the video on YouTube:

<iframe allowfullscreen="allowfullscreen" src="https://www.youtube.com/embed/6P9PIrKYRKE" style="position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;" title="YouTube Video"></iframe>

Or you can read the rest the tutorial as a blog at: https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-101-part-5-sources


syslog-ng logo

</figcaption> </figure>

Creating slides with Markdown using Marp

Posted by Joe Brockmeier on January 25, 2023 03:31 AM

Need to make a presentation, but don’t like using a GUI app? Take a look at Marp, the Markdown Presentation Ecosystem.

Many folks like to knock slides as a format for conveying information. I don’t dislike slides as a way to convey and present (some) information. But I have never loved using apps like PowerPoint, Google Slides, or LibreOffice Impress. Converting Markdown to slides, though, is a great way for me to knock out a first draft of a presentation.

When I work on work documents, I’ll often revert to Vim + Markdown to do a first draft. The important thing in a first draft is to get the outline in place and then fill out the text. Markdown offers enough formatting that I can do the headings (outline), bullets, minimal formatting, and links without needing to fuss with all the formatting options in a word processor.

After I’m happy enough with a first draft I can run things through Pandoc and then plop that into Google Docs or Word or whatever tool I need to move to the next step.

Marp makes it possible to do the same thing with presentations. ;">Note: Marp produces slides that are images rather than, say, a PPTX file that you can edit in PowerPoint or Google Slides. However, Pandoc will happily take the same Commonmark file Marp uses and generate an editable preso to start from.

It’s not the only game in town for producing slideware outside of a slide app. If you prefer LaTeX, there’s Beamer (for example). But I find LaTeX to be overkill. (You can, if you want, go the Pandoc to Beamer route…) There’s other text to slides tools, too, but Marp has a few things I really like:

  • Simple format but you can produce some nice slides and tweak the layout nicely if you want to do that.
  • Marp-cli has a nice preview mode and even offers a presentation + speaker notes mode that’s good enough for presenting.
  • Cross-platform, your choice of Windows, Linux, or macOS + a VS Code plugin if that’s your tool of choice.
  • Starting with Markdown means it’d be easy to convert a presentation to prose or vice-versa. Converting a Google Slides deck to Google Docs, for example, much less straightforward.
  • Again, because it’s basically Markdown with a few extra formatting tweaks, it should be easy to migrate to another Markdown -> slides tool in the future if needed.
  • Marp is MIT-licensed, which is nice.

Marp is at top of mind for me today because I spent some quality time working on a draft deck today that was slow going in Google Slides. Popping open Vim instead of Google Slides was a productivity booster.

Have a favorite open source text to slides tool? I’m all ears.

The post Creating slides with Markdown using Marp appeared first on Dissociated Press.

Cockpit 284

Posted by Cockpit Project on January 25, 2023 12:00 AM

Cockpit is the modern Linux admin interface. We release regularly.

Here are the release notes from Cockpit 284, cockpit-machines 282, and cockpit-podman 61:

Services: Show logs for user units

The Services page now shows journal logs for user systemd services.

screenshot of show logs for user units

Many thanks to Timothy Johnson for this contribution!

Storage: Set up NBDE

It is possible (and unfortunately likely) that a system is misconfigured and can not mount filesystems during boot that rely on Clevis to unlock them. Cockpit can now fix this when adding a keyserver to a encrypted filesystem.

screenshot of set up a system to use nbde

Machines: Option to forcefully revert a snapshot

There are situations where a snapshot revert involves extra risk and the user should either consider not reverting snapshot, or force it. The few most common cases are:

  • Snapshot that lacks full domain information for reverting configuration. In this case, the user should be sure that snapshot is compatible with the current configuration (if it is not, the domain will likely fail to run).
  • Reverting from a running domain to an active state where a new hypervisor has to be created rather than reusing the existing hypervisor.
  • Snapshot of inactive VM which also has a managed saved state. This requires forceful revert because the snapshot does not contain a memory state and will therefore not replace the existing memory state. This ends up switching a disk underneath a running system and can cause filesystem corruption or crashes due to swap content mismatches when run.

Screenshot from 2023-01-24 15-37-22

Podman: Use container image’s default command

Newly created containers now use the container image’s suggested command by default. Just as before, this command can be changed when creating a container in cockpit-podman. Previously, the command always defaulted to suggest using sh.

Try it out

Cockpit 284, cockpit-machines 282, and cockpit-podman 61 are available now:

Infra & Releng Team in 2022

Posted by Fedora Community Blog on January 24, 2023 08:00 AM

Infra & Releng Team is a sub-team in Red Hat’s Community Platform Engineering (CPE) Team that takes care of Fedora Infrastructure, Fedora Release Engineering, and CentOS Infrastructure. This blog post is a summary of what the team did in 2022. It contains infographics as a quick review. Below that will be more detailed information about what you can see in the infographics.

<figure class="wp-block-image size-full">I&R Summary 2022<figcaption class="wp-element-caption">Infra & Releng 2022 infographics</figcaption></figure>

Closed issues

Infra & Releng Team has 3 main trackers we watch: Fedora Infrastructure, Fedora Release Engineering and CentOS Infrastructure. We closed 1702 issues on these three trackers in 2022.

We tag tickets with “gain” and “trouble” as you can see in the infographics. Not every ticket has gain and trouble, but these are a good indicator of the ticket importance and amount of work it needs. Here is the explanation what “gain” means:

  • Low gain – Only affects few users in community
  • Medium gain – Affects part of the community (for example only affects Fedora CoreOS)
  • High gain – Affects most of the community (for example issues with building pipeline)

The definitions of “trouble” are:

  • Low trouble – This ticket takes less than a day to solve
  • Medium trouble – This ticket takes less than week, but more than a day
  • High trouble – This ticket will take more than one week to finish (some of those tickets could be mini-initiative or initiative)

We closed 191 high gain tickets and 41 high trouble tickets in 2022.

Mini-initiatives & planned tasks

Infra & Releng Team works as a support team for Fedora and CentOS communities, so there isn’t that much planned work. But even with that, we finished 14 planned tasks (some of them are mini-initiatives) in 2022.

A mini-initiave is a task that takes multiple weeks for small team (1-3 people) to finish. Here is the list of mini-initiatives that were finished in 2022 with links to corresponding tickets:

ARC Investigations

Advanced Reconnaissance Crew (ARC) Investigations are done by small team (1-3 people) in the Infra & Releng Team. This small team investigates the options for initiatives before the initiative is even started. The ARC Team documents every investigation they do. In 2022 we finished 8 investigations.

ARC completed these investigations in 2022:

And this is all for 2022. Thanks to all the community members who helped us to make Fedora Infrastructure, CentOS Infrastructure, and Fedora Release Engineering a better place by reporting bugs, helping with issues and giving feedback. We hope to see you all in 2023.

The post Infra & Releng Team in 2022 appeared first on Fedora Community Blog.

Build security with the assumption it will be used against your friends

Posted by Matthew Garrett on January 23, 2023 10:44 AM
Working in information security means building controls, developing technologies that ensure that sensitive material can only be accessed by people that you trust. It also means categorising people into "trustworthy" and "untrustworthy", and trying to come up with a reasonable way to apply that such that people can do their jobs without all your secrets being available to just anyone in the company who wants to sell them to a competitor. It means ensuring that accounts who you consider to be threats shouldn't be able to do any damage, because if someone compromises an internal account you need to be able to shut them down quickly.

And like pretty much any security control, this can be used for both good and bad. The technologies you develop to monitor users to identify compromised accounts can also be used to compromise legitimate users who management don't like. The infrastructure you build to push updates to users can also be used to push browser extensions that interfere with labour organisation efforts. In many cases there's no technical barrier between something you've developed to flag compromised accounts and the same technology being used to flag users who are unhappy with certain aspects of management.

If you're asked to build technology that lets you make this sort of decision, think about whether that's what you want to be doing. Think about who can compel you to use it in ways other than how it was intended. Consider whether that's something you want on your conscience. And then think about whether you can meet those requirements in a different way. If they can simply compel one junior engineer to alter configuration, that's very different to an implementation that requires sign-offs from multiple senior developers. Make sure that all such policy changes have to be clearly documented, including not just who signed off on it but who asked them to. Build infrastructure that creates a record of who decided to fuck over your coworkers, rather than just blaming whoever committed the config update. The blame trail should never terminate in the person who was told to do something or get fired - the blame trail should clearly indicate who ordered them to do that.

But most importantly: build security features as if they'll be used against you.

comment count unavailable comments

Automatic pulling of upstream releases to Fedora

Posted by Packit Team on January 23, 2023 08:23 AM
In the previous year, we automated the Fedora downstream release process in Packit. The first step of the release process, propagating the upstream release to Fedora, is covered by the propose_downstream job. This job updates the sources in Fedora, the spec file, and other needed files and creates pull requests with the changes in the dist-git repository. The downside of this job is that for its execution, users need to install Packit Service GitHub/GitLab app since this job reacts only to GitHub/GitLab release webhooks.

Something I should’ve done a long time ago: Installing Pi-hole

Posted by Joe Brockmeier on January 23, 2023 03:36 AM

Spent some quality Sunday time today refurbishing some older mini PCs that had been gathering dust so I could run a few personal projects. One of the projects I’ve had on my to-do list an embarrassingly long time is to set up Pi-hole for ad blocking / filtering. If I’d known it’d be that easy I’d have done it a long time ago!

I installed Pi-hole on an ancient Core i3 NUC with 8GB of RAM running Debian. It took about two minutes, five if you count reading some documentation and maybe seven minutes if you count logging into the admin interface and quickly setting my laptop and phone to use Pi-hole for testing.

One of the most ad-infested sites that I visit is Imgur. Its app has become nearly unusable due to its ads, and I can literally feel my phone get warmer when browsing the app. After pointing my phone at Pi-hole instead, it’s much more usable. Still a bit of a battery hog, but not nearly as bad as it was prior to setting up Pi-hole.

Looking over the very early stats, I’m seeing about 38% of the queries blocked. 38%! And that’s just using the default block list. I haven’t researched any of the other adlists or made any real customizations yet. The next step is setting it up so all the systems on my home network use pi-hole for DNS, including devices like the Roku.

It’ll be interesting to see how things compare after a week or so of usage, especially after pointing my laptop at the Pi-hole during work hours. That should give a slightly more balanced picture. At least I certainly hope the various sites I need to visit during work hours won’t be rife with calls to sketchy ad networks.

If you’re using Pi-hole and you have any recommendations, I’d love to hear tales of caution or victory with specific ad lists or things to avoid. If you haven’t set up a Pi-hole for home use, it’s simple enough that I can do it – so what are you waiting for?


The post Something I should’ve done a long time ago: Installing Pi-hole appeared first on Dissociated Press.

Episode 359 – The NOTAM outage and other legacy technology

Posted by Josh Bressers on January 23, 2023 12:00 AM

Josh and Kurt talk about the recent FAA NOTAM outage. Keeping legacy things running for long periods of time is really hard to do, this system is no different. It’s also really hard to upgrade many of these due to corner cases and institutional knowledge. There aren’t any great answers here, but we do ask a lot of questions about long running tech.

<audio class="wp-audio-shortcode" controls="controls" id="audio-3044-1" preload="none" style="width: 100%;"><source src="https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_359_The_NOTAM_outage_and_other_legacy_technology.mp3?_=1" type="audio/mpeg">https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_359_The_NOTAM_outage_and_other_legacy_technology.mp3</audio>

Show Notes

Absolute silliness: Hampster Invaders

Posted by Joe Brockmeier on January 22, 2023 02:53 AM

Hampster Invaders screenshot showing lots of hampsters attacking a base ship.You remember Space Invaders? You remember the Hampster Dance? Get ready for Hampster Invaders.

Pretty much what it sounds like on the tin, the hampsters from Hampster Dance are invading and you have to avoid their… droppings. Pretty much your standard Space Invaders clone except there’s no bases to hide behind. So far my top score is somewhere north of 100,000. Not an exceptional score, but I haven’t spent a lot of time on it.

Hampster Invaders features the song and classic Space Invaders sound effects. Sadly you can’t mute one without the other, and as much as I love the song I love it in small doses.

But this is some good, nostalgic fun. I started dropping quarters in Space Invaders in the 70s, and it’s still as much fun as it was then. Space Invaders and its spiritual cousin Astrosmash are still a great way to pass some time.

The main site, vole.wtf, has a number of web games and even “Voleflix” featuring a bunch of public domain movies. This is what the Internet is truly for, just weird fun mashups that let people demonstrate their creativity and fun hacks.




The post Absolute silliness: Hampster Invaders appeared first on Dissociated Press.

New badge: FOSDEM 2023 Attendee !

Posted by Fedora Badges on January 21, 2023 07:06 PM
FOSDEM 2023 AttendeeYou visited the Fedora booth at FOSDEM 2022

New badge: SCaLE 20x Attendee !

Posted by Fedora Badges on January 21, 2023 07:00 PM
SCaLE 20x AttendeeYou visited the Fedora booth at SCaLE 20x!

Johnnycanencrypt 0.13.0 released

Posted by Kushal Das on January 21, 2023 02:23 PM

I just now released v0.13.0 of my johnnycanencrypt project. It is a Python module written in Rust, which provides OpenPGP functionality including allows usage of Yubikey 4/5 as smartcards. From 0.12.0 it is now licensed as LGPL-3.0-or-later.

Major updates in this release (and in the previous one are):

  • Adds enable_otp_usb in rjce.
  • Adds disable_otp_usb in rjce.
  • Changed license to LGPL-3.0-or-later
  • We can now disable OTP for both YubiKey4/5 #131.

For many folks disabling the OTP application in the Yubikey is must, otherwise we all saw random bytes dropping on the shell/document/chat thanks to a touch to the key. I tested the code in both Yubikey 4 and 5. I hope this will work well in the field.

PHP version 8.1.15RC1 and 8.2.2RC1

Posted by Remi Collet on January 21, 2023 07:28 AM

Release Candidate versions are available in testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for a parallel installation, perfect solution for such tests, and also as base packages.

RPM of PHP version 8.2.2RC1 are available

  • as base packages
    • in the remi-php82-test repository for Enterprise Linux 7
    • in the remi-modular-test for Fedora 35-37 and Enterprise Linux ≥ 8
  • as SCL in remi-test repository

RPM of PHP version 8.1.15RC1 are available

  • as base packages
    • in the remi-php81-test repository for Enterprise Linux 7
    • in the remi-modular-test for Fedora 35-37 and Enterprise Linux ≥ 8
  • as SCL in remi-test repository

emblem-notice-24.pngPHP version 8.0 is now in security mode only, so no more RC will be released.

emblem-notice-24.pngInstallation : follow the wizard instructions.

Parallel installation of version 8.2 as Software Collection:

yum --enablerepo=remi-test install php82

Parallel installation of version 8.1 as Software Collection:

yum --enablerepo=remi-test install php81

Update of system version 8.2 (EL-7) :

yum --enablerepo=remi-php82,remi-php82-test update php\*

or, the modular way (Fedora and EL ≥ 8):

dnf module reset php
dnf module enable php:remi-8.2
dnf --enablerepo=remi-modular-test update php\*

Update of system version 8.1 (EL-7) :

yum --enablerepo=remi-php81,remi-php81-test update php\*

or, the modular way (Fedora and EL ≥ 8):

dnf module reset php
dnf module enable php:remi-8.1
dnf --enablerepo=remi-modular-test update php\*

Notice: version 8.2.2RC1 is in Fedora rawhide for QA.

emblem-notice-24.png EL-9 packages are built using RHEL-9.1

emblem-notice-24.png EL-8 packages are built using RHEL-8.7

emblem-notice-24.png EL-7 packages are built using RHEL-7.9

emblem-notice-24.png oci8 extension now uses Oracle Client version 21.8, intl extension now uses libicu 71.1

emblem-notice-24.png RC version is usually the same as the final version (no change accepted after RC, exception for security fix).

emblem-notice-24.png versions 8.1.14 and 8.2.1 are planed for January 5th, in 3 weeks.

Software Collections (php81, php82)

Base packages (php)

Friday’s Fedora Facts: 2023-03

Posted by Fedora Community Blog on January 20, 2023 10:42 PM

Here’s your weekly Fedora report. Read what happened this week and what’s coming up. Your contributions are welcome (see the end of the post)!

The F38 mass rebuild is underway.

I have weekly office hours on Wednesdays in the morning and afternoon (US/Eastern time) in #fedora-meeting-1. Drop by if you have any questions or comments about the schedule, Changes, elections, or anything else. See the upcoming meetings for more information.



<figure class="wp-block-table">
Container Plumbing Daysvirtual22–23 Marcloses 23 Jan
MagnoliaJSJackson, MS, US17–18 Octcloses 31 Jan
jsdayVerona, IT13–14 Aprcloses 31 Jan
ConnectahaOmaha, NE, US24 Aprcloses 31 Jan
Open Source Summit North AmericaVancouver, BC, CA10–12 Maycloses 5 Feb
Write The DocsPortland, OR, US7–9 Maycloses 6 Feb
NewcraftsParis, FR25–26 Maycloses 12 Feb
Open Source NorthSt. Paul, MN, US24 Maycloses 18 Feb
Berlin BuzzwordsBerlin, DE18–20 Juncloses 19 Feb
JSDay IEDublin, IE26 Sepcloses 28 Feb
Scenic City SummitChattanooga, TN, US2 Juncloses 1 Mar
DevOpsDays ChicagoChicago, IL, US9–10 Augcloses 17 Mar
openSUSE Conference 2023Nürnberg, DE26–28 Maycloses 9 Apr
Web Weekend KathmanduKathmandu, NP23–24 Sepcloses 21 Apr

Help wanted

Upcoming test days

Have a test day idea for Fedora Linux 38? The call for test days is open.

Meetings & events


<figure class="wp-block-table">
Releaseopen bugs

Prioritized Bugs

See the Prioritized Bugs documentation for information on the process, including how to nominate bugs.

<figure class="wp-block-table">
Bug IDComponentStatus

Fedora Linux 38


Below are some upcoming schedule dates. See the schedule website for the full schedule.

  • 2023-02-07 — F38 branches from Rawhide
  • 2023-02-07 — F38 Change completion deadline (testable)
  • 2023-02-21 — F38 Change completion deadline (100% complete)


The table below lists proposed Changes. See the ChangeSet page or Bugzilla for information on approved Changes.

<figure class="wp-block-table">
Shorter Shutdown TimerSystem-WideApproved
Rpmautospec by DefaultSystem-WideApproved
Noto Fonts For More LanguagesSystem-WideApproved
GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1)System-WideApproved
FPC repackagingSelf-ContainedApproved
TeXLive2022Self-ContainedFESCo #2935
Noto CJK Variable FontsSelf-ContainedFESCo #2938
Unfiltered FlathubSystem-WideFESCo #2939
IPP-USB as a weak dependency of CUPS and sane-airscanSelf-ContainedFESCo #2942
cups-filters 2.0bSelf-ContainedAnnounced
IoT Simplified InstallerSelf-ContainedAnnounced

Fedora Linux 39


The table below lists proposed Changes. See the ChangeSet page or Bugzilla for information on approved Changes.

<figure class="wp-block-table">
Replace DNF with DNF5System-WideFESCo #2870
Remove pam_consoleSystem-WideAnnounced


Have something you want included? You can file an issue or submit a pull request in the fedora-pgm/pgm_communication repo.

The post Friday’s Fedora Facts: 2023-03 appeared first on Fedora Community Blog.

Fedora Project at FOSDEM 2023

Posted by Fedora Magazine on January 20, 2023 02:00 PM

Fedora Project will be present at FOSDEM 2023. This article describes this gathering and a few of the events on the agenda. I assume if you are reading the Fedora Magazine, you already know what FOSDEM is, but I’ll start with a small intro anyway.


FOSDEM is the biggest event in the known universe for free/libre and open-source developers and enthusiasts.

Many good people from around the world meet and discuss common topics and define the future of F/LOSS. The event is held in Brussels at the beginning of February. Some of us, who are coming from a bit warmer countries, are calling it FrOSDEM, because it’s usually freezing 🙂

Why attend?

If you are a contributor already or you want to start doing good with your skills for the F/LOSS universe, this event is a must. 

I know everyone has their reason for visiting, but I’ll share the most common ones:

  • You meet the people creating and supporting the products that power the Internet that you already use.
  • If you are a contributor already, you have a chance to meet with your team and people using your product.
  • You learn so much new stuff quickly.
  • You enlarge your horizons by looking at something outside your bubble. If you are a fan of Fedora, go and learn more about Security or Javascript.
  • You have a chance to talk to others with the same passion as yours and even become friends for life. A good friend is always a commodity!
  • You achieve your daily steps goal because the ULB campus is enormous, and you will have to move a lot to get to the room you would like to visit.
  • You have a chance to volunteer and help the community if this is what drives you.
  • You attend an event with a great Code of Conduct.

Fedora at FOSDEM 2023

It’s a tradition for the Fedora Project team to be there to present some of our work from the last year and to allow you to share your feedback on what we do well and how we can improve.

Meet, greet, and see our community in action

One of the most extraordinary things at FOSDEM, which I deliberately didn’t mention in the previous section, is the project booths. In almost every building, you will see people behind a branded table, ready to talk to you about their project, its values, and its mission.

<figure class="wp-block-image size-large">People at the Fedora booth looking at something. <figcaption>Image by Francesco Crippa under Attribution 2.0 Generic (CC BY 2.0)</figcaption></figure>

 I have to mention the goodies here, as well. You will return home with many items from your favorite projects. Be sure to continue supporting them further.  

We at Fedora will be happy to welcome you to our booth as well. You can talk to the community members, give us constructive feedback, and see some of the things we prepared.

Our booth location is in building H, alongside the rest of the Linux Distros.

<figure class="wp-block-image size-full">Map of the ULB campus with a mark of the building H, where the Fedora Project booth will be<figcaption>Building H, ULB Campus.</figcaption></figure>

Stop by and say hi in your language! We are looking forward to talking to you!

We want to share what makes our work exceptional

At each FOSDEM we have a good number of talks related to what we do at Fedora. I am listing only some of them to make it enjoyable for you to browse the agenda and discover the rest yourself.

1: Fedora CoreOS – Your Next Multiplayer Homelab Distro

Using Fedora CoreOS in a Selfhosted Homelab to setup a Multiplayer Server


Akashdeep Dhar
 Objective Lead for Fedora Websites & Apps, Fedora Council
 Software Engineer, Red Hat Community Platform Engineering

Sumantro Mukherjee
 Elected Representative, Fedora Council
 Software Quality Engineer, Red Hat


Fedora CoreOS is an essential, monolithic, automatically updating operating system optimized for running containers. It focuses on offering the best container host for executing containerized workloads securely and at scale. We will show a case study of setting up Fedora CoreOS as a self-hosted Homelab distribution for globally accessible (using secure network tunneling) multiplayer servers for video games (namely Minecraft, Valheim, etc.).

When and Where

Saturday, Feb-4 at the Containers devroom from 11:30 to 12:00

2: Creative Freedom Summit Retrospective


Emma Kidney

Part of Red Hat’s Community Platform Engineering team since 2021. 
Designer at Red Hat’s Community Design Team. 

Jess Chitas 

Part of Red Hat’s Community Platform Engineering team.
Creator of Fedora’s mascot – Colúr, and Fedora Brand Guidelines Booklet.


The Creative Freedom Summit is a virtual event focused on promoting Open Source tools, spreading knowledge of how to use them, and connecting creatives across the FOSS ecosystem. The summit’s accomplishments and shortcomings will be examined in light of the event’s first year and potential changes for the following years.

When and Where

Sunday, Feb-5 at the Open Source Design Dev Room from 14:30 to 14:55

Where to find more related talks?

Our wiki page is a good start, but FOSDEM’s schedule catalog is even better. One life hack: select a good 30 min slot, go through all the rooms which might get your attention, and create a personal schedule in your favorite calendar app. Make sure you have a backup plan because some rooms might be fully occupied, and you cannot enter.

I want to interest you in a challenge

If you know more than I do about FOSDEM 2023 and have already prepared your schedule, share a single paragraph comment about your FOSDEM plan and list a few of your favorite talks. You will help the community understand the greatness of the event and find more reasons to make the trip to frosty Brussels.

See you there!

Introducing Kinoite Nightly (and Kinoite Beta)

Posted by Timothée Ravier on January 19, 2023 11:00 PM

As announced during the Fedora Kinoite “Hello World!” talk (slides) last year at the Fedora 35 release party, one of the goals for Fedora Kinoite is to make it easier for everyone to try and test the latest KDE Plasma desktop and Apps, without having packaging, compiler or development knowledge.

We are now much closer to that goal with the introduction of Kinoite Nightly, an unofficial variant of Fedora Kinoite based on stable Fedora plus nightly packages for KDE software (Plasma desktop and a base set of apps).

Alonside Kinoite Nightly, we are also introducing Kinoite Beta, which is also an unofficial variant of Fedora Kinoite, also based on stable Fedora but with KDE Plasma Beta packages. This variant is based on fresh release of KDE Plasma 5.27 Beta.

While the Nightly variant will be built daily and will always be available, the Beta variant will only be built and available during KDE Plasma Beta testing phases.

All of this is only made possible by the very good work of the Fedora KDE SIG members that maintain KDE packages for Fedora, including those nightly packages.

Those variants are built daily and published as a container image hosted in repos on Quay.io:

Pre-release software notice

Warning: This should be obvious but in case it needs to be said: This is pre-release software that may include major bugs. Only use this on systems where you are confident you will be able to rollback and have backups of your collection of favorite cat pictures.

Additionaly for Kinoite Nightly: The functionnality, features, bugs might change at any time and there is no guarantee of compatibility or stability.

If you find bugs, you are welcomed to report them to KDE developers on bugs.kde.org or to the project on GitLab.

How do I try it?

We currently do not have installation ISOs or pre-installed images available. To try it, you can follow those steps:

 1. Install the latest official Fedora Kinoite release.

 2. Update your system to the latest version and reboot:

<figure class="highlight">
$ sudo rpm-ostree update --reboot

 3. Pin your current deployment to make sure that you will be able to rollback if something fails:

<figure class="highlight">
$ sudo ostree admin pin 0

 4. Switch to either Kinoite Nightly or Kinoite Beta:

<figure class="highlight">
# For Kinoite Nightly
$ sudo rpm-ostree rebase --reboot \

# For Kinoite Beta
$ sudo rpm-ostree rebase --reboot \

 5. Test and report bugs!

Kinoite Beta with KDE Plasma 5.27 Beta

Connecting the packages with the sources in Kinoite Nightly

Note: This mostly applies to Kinoite Nightly as Kinoite Beta is made from released Beta sources.

You can figure out exactly which commit is included in the image by looking at the Git short hash included at the end of the package versions (right before -1.fc37.x86_64 which is the revision, major release and architecture):

<figure class="highlight">
$ rpm -qa | grep kf5
$ rpm -qa | grep plasma

Testing an image built on a specific date

As the images are rebuilt daily, you can also fetch a version that was built on a specific date. You can see all builds (tags) in the repos on Quay.io:

To do that, you need to specify the tag referencing the container image to fetch with the rebase command:

<figure class="highlight">
$ sudo rpm-ostree rebase \

This should make it much easier to bissect regressions that impact a lot of components, either in KDE packages themselves or in their dependencies.

You can also diff the list of package between two versions with:

<figure class="highlight">
$ rpm-ostree db diff

Or override a specific package with another version or your own build with custom patches for example:

<figure class="highlight">
$ rpm-ostree override replace plasma-workspace-XYZ.rpm
$ reboot

But what about all the other apps?

Just like Fedora Kinoite, most applications should run just fine as Flatpaks, and we’re working on making most of them available on Flathub (we’re really close now). To be able to test development versions of those apps, you can try them via the Nightly Flatpak repo hosted by KDE.

This single repo might go away or be reworked once we are able to fully move to GitLab CI based builds for Flatpak apps. You’ll be able to get Nightly Flatpak builds for applications directly from the KDE Invent GitLab instance.

See also my post about the future for Flatpak support and integration in KDE.


Feel free to drop by the Fedora KDE channel or to open an issue if you have feedback, suggestions or questions.

OpenSSH client side key management for better privacy and security

Posted by Timothée Ravier on January 19, 2023 11:00 PM

If you have read the ssh whoami.filippo.io post by Filippo Valsorda and the related whoarethey: Determine Who Can Log In to an SSH Server post by Andrew Ayer, you might be wondering if we can do something about it in the OpenSSH client configuration.

In this post I will describe how I use a different key for each server I connect to via SSH and how I make it easy to managed in my OpenSSH client configuration. This mitigates both of the issues mentioned in the posts above. I have been using this configuration without issue for approximately five years now.

Security rationale

A lot of OpenSSH hardening guides focus on configuration recommendations for the OpenSSH server. Since the integration of Wireguard in the Linux kernel and with clients available for all majors platforms, I have been progressively switching all my OpenSSH servers to listening only on a Wireguard interface which thus significantly reduced the pressure for strong sever side OpenSSH hardening. Do not get me wrong: it is still useful and you should still do it but it is no longer a critical priority.

While we generaly do not use OpenSSH to connect to random servers, man in the middle attacks can happen and could redirect the traffic to a malicious host. The general idea is thus to limit the information that the OpenSSH client sends to a remote host by default.

It is also very easy to share the private part of an OpenSSH key pair instead of the public part by mistake, either via the command line with ssh-copy-id or when adding it to a remote host or service. If you only have one key pair, then if you make one mistake, you have to replace your key on all the hosts and services where you used it.

The idea is thus to create a distinct key pair for each server that we are going to connect to in order to be able to easily revoke or discard them if shared by mistake or when access is no longer needed. Posting a private key by mistake will thus only require immediate action for places where this key was used and as I generally only share the key right after I have generated it for a new host, it is essentially unused and I can directly generate a new one.

I generally create a key pair for each “entity” and not strictly each host as this keeps thing more manageable and easier to track while not reducing the security benefit.

And finally, while the public part of an asymetric OpenSSH should be safe to share by design, it also identifies you and that is the idea behind the two posts mentionned at the beginning. We avoid leaking that information if we use different keys for different hosts.

General layout

To enable that setup, we need to disable some options by default for all hosts that we are going to connect to and then explicitely specify for a given host which key we will be using. We will thus use the following layout for the SSH client configuration (usually ~/.ssh/config):

<figure class="highlight">
# Configuration specific for the foo.bar.com host
Host foo.bar.com

# Defaults, must come last
# To be disabled or overriden on a per-host basis like shown above
Host *

See the ssh_config(5) man page for the full details.

Key management

First, we will tell OpenSSH to only use the identity specified for each specific host instead of offering all the keys available to all servers:

<figure class="highlight">
Host *
    IdentitiesOnly yes

Then, instead of generating a single key pair that will be stored in the default location, we will create different keys, one for each entity, and store them in a subfolder:

<figure class="highlight">
$ tree ~/.ssh
├── authorized_keys
├── config
├── keys
│   ├── fedora
│   ├── fedora.pub
│   ├── github
│   ├── github.pub
│   ├── gitlab
│   ├── gitlab.pub
│   ├── home
│   ├── home.pub
│   ├── local
│   ├── local.pub
│   └── ...
└── known_hosts

We can then select the key to use for each server:

<figure class="highlight">
Host github.com
    IdentityFile ~/.ssh/keys/github

General hardening

There are a lot of additionnal options that you can set to further harden your OpenSSH configuration (client and server). I have found the following articles to be useful and I am using a lot of the mentionned options in my personal configuration:


I have found this setup to be relatively low effort and high peace of mind gain, similarly to how a password manager enables you to not think about password at all anymore.

Lazyweb: Matching compatible mini-PCs with RAM / NVMe on hand?

Posted by Joe Brockmeier on January 19, 2023 10:30 AM

I’ve recently upgraded a few laptops and have some NVMe drives and spare RAM on hand. Rather than letting them gather dust or try to sell them online, I’d like to match them with inexpensive mini PCs for use in my home lab.

Suggestions on the best way to backwards-match this?

I’ve tried Googling “mini PC DDR4 3200” (for example) but the results are meh and trying to find a good deal has been frustrating. Haven’t had any luck with pcpartpicker.com either.

I have on hand:

  • 64GB (4 16GB sticks) of DDR4-2400 SODIMM RAM
  • 16GB (2 8GB sticks) of DDR4-3200 SODIMM RAM

Finding RAM to fit systems is easy, but going the other way has been a pain. I’d really like to make use of these. (I have a fair amount of much older RAM that’s just gathered dust over the years and seems like a waste.)

Ideally I’d find something like an inexpensive ($300 or less ideally) NUC or an AMD-based mini PC that I can use as a Kubernetes node or to run test database services. These would run Ubuntu, Debian, or RHEL / a RHEL clone. A dual NIC system would be great.

The NVMe drives are less of a pain to match, but the variance in speeds for RAM makes it a bigger pain. I know you can usually get away with, say, putting DDR4-3200 DIMMs into a system that wants slower RAM, but the other way not so much.

Bonus points for specific systems (with links!) recommendations. I can go spelunking through product sheets (and have) but that’s producing limited returns.

(Also posted this to Ask Metafilter in hopes of getting good responses.)

The post Lazyweb: Matching compatible mini-PCs with RAM / NVMe on hand? appeared first on Dissociated Press.

CPE Weekly Update – Week 3 2023

Posted by Fedora Community Blog on January 19, 2023 10:00 AM

This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on libera.chat.

We provide you both infographics and text version of the weekly report. If you just want to quickly look at what we did, look at the infographic. If you are interested in more in depth details, look below the infographic.

Week: 16th-20th of January 2023

<figure class="wp-block-image size-large"><figcaption class="wp-element-caption">CPE infographic</figcaption></figure>

Highlights of the week

Infrastructure & Release Engineering

Goal of this Initiative

The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible initiatives that CPE might take on.
Planning board


Fedora Infra

  • Accidentally enabled rhbz_mail FAS field in toddlers
    • Sent late announcement with guide how to fix the issue – fortunately this only impacted few users
    • Fixed mail to correspond with this change
  • Got new *.fedoraproject.org cert finally correctly issued (worked with RHIT and digicert)
  • New pagure-dist-git in production (closing several long term tickets). Many thanks to zlopez and lenkaseg
  • All builders updated/rebooted and made ready for mass rebuild
  • Koji hubs updated to 1.31.1
  • Bodhi upgraded to 7.0.1
  • Business as usual, tickets project adjustments, etc.

CentOS Infra including CentOS CI

  • Working on secureboot required infra/tags in kojihub
  • Migrating ns1/ns2.centos.org to rhel8 (internal RH networks: rdu2/iad2)
  • IPA TLS certs monitoring points and renewal process
  • Preparing REDHAT.COM => IPA.REDHAT.COM auth migration for Stream infra (staging env first)

Release Engineering

  • Fedora 38 mass rebuild

CentOS Stream

Goal of this Initiative

This initiative is working on CentOS Stream/Emerging RHEL to make this new distribution a reality. The goal of this initiative is to prepare the ecosystem for the new CentOS Stream.


  • More stream 8 composes, on both the old and new infrastructure. It might not be perfect, but the differences are small, and we’ve had a successful fully complete production compose, with images.


Goal of this initiative

Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL).

EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more.


  • EPEL 9 is up to 13,162 (+158) packages from 4,880 (+52) source packages

FMN replacement

Goal of this initiative

FMN (Fedora-Messaging-Notification) is a web application allowing users to create filters on messages sent to (currently) fedmsg and forward these as notifications on to email or IRC.
The goal of the initiative is mainly to add fedora-messaging schemas, create a new UI for a better user experience and create a new service to triage incoming messages to reduce the current message delivery lag problem. The community will profit from speedier notifications based on own preferences (IRC, Matrix, Email), unified fedora project to one message service and human-readable results in Datagrepper.
Also, CPE tech debt will be significantly reduced by dropping the maintenance of fedmsg altogether.


  • Rework backend caching (ongoing)
  • Messaging schemas (ongoing)

The post CPE Weekly Update – Week 3 2023 appeared first on Fedora Community Blog.

Kernel Module Management testing

Posted by Pablo Iranzo Gómez on January 19, 2023 08:55 AM
Following on the Using Kcli to prepare for OCM testing, we’re going to prepare KMM testing in Hub-Spoke approach. First we need to prepare our .docker/config.json with the contents of our OpenShift pull secret used with Kcli. mkdir -p ~/.docker/ cp openshift_pull.json ~/.docker/config.json Warning advisories Note Semi-scripted version available at automate.sh Warning We’re using pre-release bits of the software, that’s why we need to define a custom catalog for both the Hub and the Spokes.

vulkan video decoding: anv status update

Posted by Dave Airlie on January 19, 2023 03:53 AM

After hacking the Intel media-driver and ffmpeg I managed to work out how the anv hardware mostly works now for h264 decoding.

I've pushed a branch [1] and a MR[2] to mesa. The basics of h264 decoding are working great on gen9 and compatible hardware. I've tested it on my one Lenovo WhiskeyLake laptop.

I have ported the code to hasvk as well, and once we get moving on this I'll polish that up and check we can h264 decode on IVB/HSW devices.

The one feature I know is missing is status reporting, radv can't support that from what I can work out due to firmware, but anv should be able to so I might dig into that a bit.

[1] https://gitlab.freedesktop.org/airlied/mesa/-/tree/anv-vulkan-video-decode

[2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20782

gnome-info-collect: What we learned

Posted by Allan Day on January 18, 2023 11:12 AM

Last August, we ran a research exercise using a small tool called gnome-info-collect. The tool allowed GNOME users to anonymously send us non-sensitive data about how their systems were configured. The plan was to use that data to inform our design and development decisions. We got a fantastic response to our call for participation, with over 2,500 people uploading their data to the GNOME servers.

We’ve just finished the final parts of the analysis, so it’s time to share what we’ve learned. This post is on the long side, so you might want to get a brew on before you start reading!

Research limitations

The people who provided their data with gnome-info-collect were primarily recruited via GNOME’s media channels, including Discourse and Twitter. This means that the data we collected was on a fairly particular subset of GNOME’s users: namely, people who follow our social media channels, are interested enough to respond to our call for help, and are confident installing and running a command line tool.

The analysis in this post should therefore not be treated as being representative of the entire GNOME user base. This doesn’t mean that it’s invalid – just that it has limited validity to the group we collected data from.

It should also be noted that the data from gnome-info-collect is by no means perfect. We collected information on GNOME systems rather than individual users. While there were some basic measures to avoid double counting, they weren’t foolproof, and there was nothing to stop the same person from submitting multiple reports using different accounts or systems. We also have no way to know if the systems which we got data on were the main desktops used by the reporters.

Who responded?

In total, we received 2,560 responses to gnome-info-collect. Of the 2,560 responses, 43 were removed from the dataset, due to not being GNOME installations, or being a virtual machine.

Distro used

A little over half of the responses came from a Fedora installation. The other main distros were Arch and Ubuntu.

Distro Number of responses % of responses
Fedora 1376 54.69%
Arch 469 18.64%
Ubuntu 267 10.61%
Manjaro 140 5.56%
Other 78 3.10%
EndeavourOS 66 2.62%
Debian 44 1.75%
openSUSE 38 1.51%
Pop! 38 1.51%
Total 2516 100.00%

Hardware manufacturer
The data we got on the hardware manufacturer of each system was poor quality. Many systems didn’t accurately report their manufacturer, and the names were often inconsistently written. Of the manufacturers that we could identify, Lenovo was the most common, with Dell, ASUS, HP, MSI and Gigabyte making up the bulk of the other systems.

Manufacturer Responses % Valid Responses
Lenovo 516 23.54%
Dell 329 15.01%
ASUS 261 11.91%
HP 223 10.17%
MSI 213 9.72%
Gigabyte 211 9.63%
Acer 86 3.92%
Other 353 16.10%
Total valid responses 2192 100.00%

Desktop configuration

We collected data on a number of different aspects of desktop configuration. Each of these areas are relevant to ongoing areas of design and development work.


We collected data on both the “workspaces on primary” and “dynamic workspaces” settings. The former controls whether each workspace is only on the primary display, or whether it spans all displays, and the latter controls whether workspaces are automatically added and removed, or whether there is a fixed number of workspaces.

In both cases, the default setting was used by the vast majority of systems, though the number of systems where the default was changed was not insignificant either. It was more common for people to change workspaces on primary, as opposed to the dynamic workspaces option.

Enabled Disabled % Enabled % Disabled Total
Workspaces on primary 2078 439 82.56% 17.44% 2517
Dynamic workspaces 2262 255 89.87% 10.13% 2517

Sharing features

GNOME’s sharing settings include a variety of features, and we collected information on which ones were enabled. When looking at this, it is important to remember that an enabled feature is not necessarily actively used.

Remote login (SSH login) was enabled more than any other sharing feature, which suggests that the gnome-info-collect respondents were relatively technical users.

Activation of the other features was relatively low, with multimedia sharing being the lowest.

Sharing Feature Systems Enabled % Enabled
Remote login 527 20.95%
Remote desktop 248 9.85%
File sharing 160 6.36%
Multimedia sharing 108 4.29%

Online accounts

Around 55% of the responses had one or more online accounts set up. (Again, an enabled feature is not necessarily used.)

Number of Online Accounts Responses % Responses
0 1115 44.30%
≥1 1402 55.70%
Total responses 2517 100.00%

Google was the most common account type, followed by Nextcloud and Microsoft. Some of the account types had very little usage at all, with Foursquare, Facebook, Media Server, Flickr and Last.fm all being active on less than 1% of systems.

Account type Responses % Responses % Responses With ≥1 Accounts
Google 1056 41.95% 75.32%
Nextcloud 398 15.81% 28.39%
Microsoft 268 10.65% 19.12%
IMAP and SMTP 153 6.08% 10.91%
Fedora 114 4.53% 8.13%
Ubuntu Single Sign-On 70 2.78% 4.99%
Microsoft Exchange 55 2.19% 3.92%
Enterprise Login (Kerberos) 50 1.99% 3.57%
Last.fm 20 0.79% 1.43%
Flickr 15 0.60% 1.07%
Media Server 9 0.36% 0.64%
Facebook 4 0.16% 0.29%
Foursquare 2 0.08% 0.14%


Flatpak and Flathub

Flatpak and Flathub are both important to GNOME’s strategic direction, so it is useful to know the extent of their adoption. This adoption level is also relevant to the design of GNOME’s Software app.

Over 90% of systems had Flatpak installed.

Flatpak status Responses % Responses
Installed 2344 93.13%
Not installed 173 6.87%
Total 2517 100.00%

In total, 2102 systems had Flathub fully enabled, which is 84% of all reporting systems, and 97% of systems which had flatpak installed. (The Flathub filtered status refers to Fedora’s filtered version of Flathub. This contains very few apps, so it is more like having Flathub disabled than having it enabled.)

It would be interesting to analyse Flatpak and Flathub adoption across distros.

Default browser

The default browser data referred to which browser was currently set as the default. It therefore doesn’t give us direct information about how much each browser is used.

The following table gives the results for the nine most popular default browsers. This combined the different versions of each browser, such as nightlies and development versions.

Most distros use Firefox as the default browser, so it’s unsurprising that it came out top of the list. These numbers give an interesting insight into the extent to which users are switching to one of Firefox’s competitors.

Default Browser Responses % Responses
Firefox 1797 73.14%
Google Chrome 286 11.64%
Brave 117 4.76%
Web 49 1.99%
Vivaldi 47 1.91%
LibreWolf 44 1.79%
Chromium 42 1.71%
Junction 38 1.55%
Microsoft Edge 37 1.51%
Total 2457 100.00%

Shell Extensions

gnome-info-collect gathered data on which extensions were enabled on each reporting system. This potentially points to functionality that people feel is missing from GNOME Shell.

Extension usage levels

When analyzing extension usage, we removed any pre-installed extensions from the data, so that data only included extensions that had been manually installed.

The vast majority of systems – some 83% – had at least one enabled extension. Additionally, 40% had between 1 and 5 enabled extensions, meaning that the majority (around 60%) had 5 or less enabled extensions.

At the same time, a substantial minority of systems had a relatively high number of enabled extensions, with around 25% of systems having between 6 and 10.

Number of Manually Enabled Extensions Number of Responses % Responses % Responses With Enabled Extensions
0 421 16.84%
1-5 1058 42.32% 50.89%
6-10 635 25.40% 30.54%
11-18 341 13.64% 16.40%
19+ 45 1.80% 2.16%
Total 2500 100.00% 100.00%

Extension popularity

The data included 588 individual extensions that were enabled. When analysing the popularity of each extension, we grouped the extensions which had similar or identical features. So, for example, “appindicator support” includes all the various status icon extensions as well. The table below shows the 25 most common enabled extension types, after grouping them in this way. Some of the extensions are included as part of GNOME’s classic mode, and we didn’t have a way to filter out those extensions which were enabled due to the classic session.

Extension Enabled Systems % Systems
Appindicator support 1099 43.66%
Gsconnect 672 26.70%
User theme 666 26.46%
Dash to dock / panel 579 23.00%
Sound output chooser 576 22.88%
Blur my shell 530 21.06%
Clipboard manager 510 20.26%
Caffeine 445 17.68%
System monitor 346 13.75%
Just perfection desktop 318 12.63%
Drive menu 310 12.32%
Apps menu 308 12.24%
Place menus 276 10.97%
Openweather 242 9.61%
Bluetooth quick connect 239 9.50%
Night theme switcher 208 8.26%
Tiling assistant 184 7.31%
Launch new instance 180 7.15%
Rounded window corners 158 6.28%
Game mode 146 5.80%
Alphabetical app grid 146 5.80%
Burn my windows 140 5.56%
GNOME UI tune 116 4.61%
Auto move windows 99 3.93%
Desktop icons 98 3.89%
Background logo 2 0.08%

As can be seen, appindicator support was by far the most common extension type, with 44% of all reporting systems having it enabled. Gsconnect, user theme, dash to dock/panel, sound output chooser, blur my shell and clipboard managers were all enabled in over 20% of the responses.

Installed apps

Knowing which apps are installed was one of the most interesting and valuable aspects of the data. It was also one of the most challenging aspects to analyse, and required processing to remove duplicate and spurious entries from the data set. The data set is still by no means perfect, but it is good enough to draw some initial conclusions.

In general, we are interested in which apps get used, which apps people have a strong need for, plus which apps people really like. App installation does not directly indicate any of these things directly, and is a relatively poor indicator for measuring them. We therefore need to be careful when drawing conclusions from this part of the analysis.

Frequency distribution

The frequency distribution of installed apps is really interesting. The total number of installed apps was very high. Even after processing, the data contained over 11,000 unique app names. Within this very large number of installed apps, the 400 most common apps represented 87% of all that were installed. This bulk of popular apps was followed by a very long tail.

The number of apps and the length of the frequency distribution tail has undoubtedly been inflated by issues in the data, and more processing to improve the data quality would be helpful.

Popular apps

After removing the most obvious preinstalled apps from the data, the 20 most common installed apps were as follows:


App Installations % Systems
GIMP 1497 58.48%
VLC 1375 53.71%
Steam 1367 53.40%
htop 1184 46.25%
Dconf Editor 1108 43.28%
Extension Manager 984 38.44%
Inkscape 952 37.19%
Flatseal 942 36.80%
Discord 938 36.64%
Google Chrome 899 35.12%
Web 898 35.08%
Chromium 871 34.02%
Thunderbird 824 32.19%
GParted 795 31.05%
Wine 772 30.16%
OBS Studio 770 30.08%
Visual Studio Code 726 28.36%
Transmission 719 28.09%
Telegram 713 27.85%
Geary 672 26.25%

A longer list of the most common 110 installed apps is available separately.

Note that the removal of preinstalled apps from this lists was extremely rudimentary and the numbers in the list may represent some apps which are preinstalled by some distros.

The most common manually installed apps are a mixed bag of traditional Linux desktop apps, third-party proprietary apps, and newer GNOME apps. Examples of common apps in each of these categories include:

  • Traditional Linux desktop apps: GIMP, VLC, Inkscape, GParted, Transmission
  • Third party apps: Google Chrome, Steam, OBS Studio, NVIDIA Settings
  • Newer GNOME apps: Flatseal, To Do, Bottles, Sound Recorder, Builder


Overall, the data gives some strong hints about which features should be concentrated on by the GNOME project. It also provides evidence about which features shouldn’t be prioritised.

It needs to be remembered that, while we have evidence here about some of the decisions that some GNOME users are making, the data doesn’t give us much insight into why they are making the decisions that they are. For example, it would seem that people are installing the GIMP, but for what purpose? Likewise, while we know that people are enabling some features over others, the data doesn’t tell us how those features are working for them. Do people find online accounts to be useful? The data doesn’t tell us.

We therefore need to be very careful when making decisions based on the data that we have here. However, what we do have is a great basis for followup research which, when combined with these results, could be very powerful indeed.

The app installation picture is complex. On the one hand, it doesn’t look like things have changed very much in the past 10 years, with people continuing to install the GIMP, Wine, and GParted. On the other hand, we have 3rd party apps being widely used in a way that wasn’t possible in the past, and it’s exciting to see the popularity of new GNOME apps like Flatseal, To Do, Bottles, and Fragments.

The data on apps is also some of the most limited. We need data on which apps are being used, not just just which ones are installed. It would also be really helpful to have data on which apps people feel are essential for them, and it would be great to have demographic information as part of the dataset, so we can see whether there are different groups of users who are using different apps.

Methodological lessons

gnome-info-collect was the first data collection exercise of its kind that has been run by the GNOME project, and we learned a lot through the process. I’m hopeful that those lessons will be useful for subsequent research. I have notes on all that, which I’ll share at some point. For now, I just want to touch on some general points.

First, doing small standalone research exercises seems to be a great approach. It allowed us to ask research questions around our current interests, and then generate research questions for followup exercises. This allows an iterative learning process which is strongly connected to our day to day work, and which can combine different research methods to understand the data from different perspectives.

Second, the whole premise of gnome-info-collect was to do a quick and lean initiative. In reality, it turned out to be a lot more work than anticipated! This was largely due to it being the first exercise of its kind, and there not being a preexisting platform for gathering the data. However, I think that we also need to acknowledge that even lean research exercises can be a lot of work, particularly if you want to gather large amounts of data.

Finally, we discovered some major issues with the data that we can get from Linux systems. Perhaps unsurprisingly, there was a lot of inconsistency and a lack of standardisation. This required additional processing at the analysis stage, and makes automated analysis difficult. If we want to routinely collect information from GNOME systems, cleaning up the raw data would be a big help.


I’d like to take this opportunity to thank Vojtěch Staněk for all his work on gnome-info-collect. Vojtěch handled all the technical aspects of gnome-info-collect, from writing the code to processing the data, as well as helping with public outreach. He did a great job!

The gnome-info-collect data doesn’t include directly identifying information, or anything very sensitive. However, there are still privacy concerns around it. We are therefore going to be archiving the data in a restricted location, rather than publishing it in full.

However, if members of the GNOME project have a use for the data, access can be arranged, so just get in touch. We are also currently investigating options for making some of the data available in a way that mitigates any privacy risks.

How to become a Shortwave listener (SWL) with Fedora Linux and Software Defined Radio

Posted by Fedora Magazine on January 18, 2023 08:00 AM

Catching signals from others is how we have started communicating as human beings. It all started, of course, with our vocal cords. Then we moved to smoke signals for long-distance communication. At some point, we discovered radio waves and are still using them for contact. This article will describe how you can tune in using Fedora Linux and an SDR dongle.

My journey

I got interested in radio communication as a hobby when I was a kid, while my local club, LZ2KRS, was still a thing. I was so excited to be able to listen and communicate with people worldwide. It opened a whole new world for me. I was living in a communist country back then and this was a way to escape just for a bit. It also taught me about ethics and technology.  

Year after year my hobby grew and now, in the Internet era with all the cool devices you can use, it’s getting even more exciting. So I want to show you how to do it with Fedora Linux and a hardware dongle.

What is Ham Radio

Amateur Radio (ham radio) is a popular hobby and service that brings people, electronics, and communication together. People use ham radio to talk across town, worldwide, or even into space, without the Internet or cell phones. 

What’s SWLing?

To broadcast with your ham radio or SDR system, you need to obtain a license from a governmental body. But to intercept signals and listen to the open communication between two amateur radio stations, you don’t need one.

The term SWLing comes from the abbreviation of Short Wave Listener, where you listen to stations communicating in the shortwave bands between 3 and 30 MHz. This can be used for long-distance communication using the ionosphere, a layer of the Earth’s atmosphere. 

To get started, you don’t need a license. Still, I recommend getting yourself an SWL sign to identify yourself in a listening contest. These are competitions for categories like who will discover the most connections in a month or who can listen to contacts from each country in the world. 

How to get an SWL Sign?

There are two options:

  • Contact your national radio club and ask them to issue one for you. I got my Czech one, OK1-36568, after a few weeks.
  • Join the Short Wave Amateur Radio Listening community and request a sign there.

You will get more information and help from either of these locations if you get stuck in some fashion! 

QSL Cards

You can also use your sign to send QSL cards via post or electronically. This is a great way to communicate with people worldwide and make friends.

Per Wikipedia, QSL card is a written confirmation of either a two-way radio communication between two amateur radio or citizens band stations; a one-way reception of a signal from an AM radio, FM radio, television, or shortwave broadcasting station; or the reception of a two-way radio communication by a third party listener (in our case). 

A typical QSL card is the same size and made from the same material as a regular postcard; most are sent through snail mail. 

Replace the radio receiver with your Fedora Linux.

The focal point of the ham radio hobby is the radio transmitter/receiver. Most of the time, enthusiasts build their radio from scratch, but this differs from what I will write about here. 


A software-defined radio (SDR) system is a radio communication system that uses software for the modulation and demodulation of radio signals. In other words, a piece of hardware and software takes the place of a radio transmitter/receiver. This helps you discover more in a way that you are familiar with – a User Interface with built-in functions instead of the limited interface of a radio receiver. 

My explanation oversimplifies things, so if you want to go deep and read more about SDR, here is an excellent start.

SDR Set Up under Fedora Linux

Choosing the proper hardware

If you search the Internet for an SDR dongle, you’ll find tons of ideas depending on your budget. In this tutorial, I’ll work with the one I have, which works well under Fedora 37 – it is available from Nooelec.

A note: The dongle covers frequencies from 25MHz to 1750MHz, which doesn’t cover the Short Wave bands. You would need an additional device to listen to them. This is included in the package I linked above. Some other hardware providers offer all-in-one products.

Check if the dongle is visible

Before installing anything, detect whether Fedora Linux recognizes your USB dongle. I hope you didn’t buy a fake one :-). Use the following command to list the USB devices on your system.


One of the output lines (in the case of Nooelec) should be

Realtek Semiconductor Corp. RTL2838 DVB-T

<figure class="wp-block-image size-full">A screen from Fedora Linux showing the results of the lsusb command listing the Realtek Device we will be using in this exercise. </figure>

Now proceed by installing the software you need

Fedora offers a set of tools and drivers packaged as a group. Even though you would not use all the components in this package from the beginning, I recommend installing it. You’ll have more software to play with.

sudo dnf group install 'Electronic Lab'

I advise you to explore what’s in the group by running this command:

sudo dnf group info 'Electronic Lab'

Now check if you have everything set up correctly by running:


You should see something like this:

<figure class="wp-block-image size-full">A screen from Fedora Linux console showing the results of the previous command listing the device and its properties. </figure>

Do not forget to kill this process because the device will be busy and cannot be used in the next step. A simple Ctrl + c works.


You have the dongle already in your device’s USB port and all the software you need to get started. 

 Now it’s time to intercept your first signal. Start the program called Gqrx. Don’t be alarmed by the strange interface. You’ll get used to it. 

Configure the I/O Device Screen

<figure class="wp-block-image size-full">A screen showing the settings panel of the software Gqrx, for the device we use. </figure>

From the “Device” Dropdown, select the ‘RealtekRTL2838...’

Leave the rest untouched for the moment.

If you don’t see your device there, click the “Device Scan” button at the bottom of the screen.

When your device is selected, click “OK” and the dialogue will close.

Configure the frequency screen

Before you start intercepting signals, ensure there is something out there that proves that everything works correctly. Since the dongle covers the FM radio band as well, do this:

  • Locate your favorite radio station’s frequency. Mine is 105MHZ
  • Set it in the Frequency field
  • Select WFM (stereo) in the “Mode” dropdown. If you don’t do this, you will not hear a sound.
<figure class="wp-block-image size-full">A screen from the gqrx software helping us to se the frequency to our favorite FM station.</figure>


And now, you need to start the reception by clicking the “play button” in your main menu. You will see the frequency visualized like this:

<figure class="wp-block-image size-full">A screen from gqrz displaying the signal received.</figure>

If you hear a sound, everything is ready to move to the next step.

If you don’t hear anything, check if everything is set up correctly. You may ask a questions in the comments for this article; I can direct you to the proper forum to solve this.

Feel free to play with some more FM broadcasts. You have the antenna for it in your pack.

Let’s go Short Wave

In the case of the Nooelec, you need to add one more device to the USB dongle and turn it on. Instructions on how to do that are included in the package you receive.  

In short, you plug the “Up Converter” into your USB dongle and make sure the switch is in the “convert” position. Some videos are available on how to do it if you get stuck.

<figure class="wp-block-image size-large"></figure>

You will need an antenna and a good location

Now things get trickier. If you live in an area where you don’t see an open space out your window or other buildings surround your building, you might have trouble catching a Short Wave radio amateur signal. 

Let’s try this to see if it works

Try to be in the open. I usually listen from my terrace, which could be better but works under particular conditions.

Apart from the hardware, you would need a long wire to act as your antenna. Try the antenna that comes with the hardware initially – the telescoping one from Nooelec, but it will catch only powerful signals.

Let’s go back to Gqrx

Now with the converter, you need to make some changes to your device screen:

<figure class="wp-block-image size-full">A screen from gqrx showing how to set up the SDR with the up Converter, You need to add the value of -125Mhz to the LNB LO Field. </figure>

Please note the –125Mhz for the LNB LO field. This is required for the Up Converter to work.

Tune your frequency to 14.100 Mhz and make sure your Mode is USB (standing for Upper sideband) because this is this band’s main demodulation option.

Then go to your FFT Settings screen, use the zoom slider, and set it to see about 100 kHz. In our case, you should have between 14.05 to 14.15 Mhz on your screen.

Also, click the “Enable Band Plan” to see the information about the SW bands you are exploring.

Then hit the play button and start exploring the space between 14.0 and 14.3 Mhz to get any amateur radio transmission.

<figure class="wp-block-image size-large">A screen showing the gqrc signal receiver in work with the setting described in this section.</figure>

When intercepting a transmission, adjust your settings to improve your listening experience. It’s a journey that you have already started.

Most probably, you will hear something like this:

“CQ CQ CQ this is ..(followed by the radio license number spelled with the ham radio phonetic alphabet). 

Listen very carefully, and by the call sign, you will be able to determine the location of the radio amateurs’ country.

You can visit the QRZCQ website to learn more about them and even send them a QSL card confirming their connection.

Keep the momentum going.

Now you have some tools and ideas for starting Short Wave Listening. 

This is the first step of an incredible and exciting journey you can have together with your Fedora Linux OS. 

You will discover the pleasure of building your antenna for the specific band, reading more about how the ionosphere helps, how to be a part of a listening competition, and what those Q-codes mean.


PKCS#11. hardware keystores, and Apple frustrations

Posted by Matthew Garrett on January 18, 2023 05:26 AM
There's a bunch of ways you can store cryptographic keys. The most obvious is to just stick them on disk, but that has the downside that anyone with access to the system could just steal them and do whatever they wanted with them. At the far end of the scale you have Hardware Security Modules (HSMs), hardware devices that are specially designed to self destruct if you try to take them apart and extract the keys, and which will generate an audit trail of every key operation. In between you have things like smartcards, TPMs, Yubikeys, and other platform secure enclaves - devices that don't allow arbitrary access to keys, but which don't offer the same level of assurance as an actual HSM (and are, as a result, orders of magnitude cheaper).

The problem with all of these hardware approaches is that they have entirely different communication mechanisms. The industry realised this wasn't ideal, and in 1994 RSA released version 1 of the PKCS#11 specification. This defines a C interface with a single entry point - C_GetFunctionList. Applications call this and are given a structure containing function pointers, with each entry corresponding to a PKCS#11 function. The application can then simply call the appropriate function pointer to trigger the desired functionality, such as "Tell me how many keys you have" and "Sign this, please". This is both an example of C not just being a programming language and also of you having to shove a bunch of vendor-supplied code into your security critical tooling, but what could possibly go wrong.

(Linux distros work around this problem by using p11-kit, which is a daemon that speaks d-bus and loads PKCS#11 modules for you. You can either speak to it directly over d-bus, or for apps that only speak PKCS#11 you can load a module that just transports the PKCS#11 commands over d-bus. This moves the weird vendor C code out of process, and also means you can deal with these modules without having to speak the C ABI, so everyone wins)

One of my work tasks at the moment is helping secure SSH keys, ensuring that they're only issued to appropriate machines and can't be stolen afterwards. For Windows and Linux machines we can stick them in the TPM, but Macs don't have a TPM as such. Instead, there's the Secure Enclave - part of the T2 security chip on x86 Macs, and directly integrated into the M-series SoCs. It doesn't have anywhere near as many features as a TPM, let alone an HSM, but it can generate NIST curve elliptic curve keys and sign things with them and that's good enough. Things are made more complicated by Apple only allowing keys to be used by the app that generated them, so it's hard for applications to generate keys on behalf of each other. This can be mitigated by using CryptoTokenKit, an interface that allows apps to present tokens to the systemwide keychain. Although this is intended for allowing a generic interface for access to such tokens (kind of like PKCS#11), an app can generate its own keys in the Secure Enclave and then expose them to other apps via the keychain through CryptoTokenKit.

Of course, applications then need to know how to communicate with the keychain. Browsers mostly do so, and Apple's version of SSH can to an extent. Unfortunately, that extent is "Retrieve passwords to unlock on-disk keys", which doesn't help in our case. PKCS#11 comes to the rescue here! Apple ship a module called ssh-keychain.dylib, a PKCS#11 module that's intended to allow SSH to use keys that are present in the system keychain. Unfortunately it's not super well maintained - it got broken when Big Sur moved all the system libraries into a cache, but got fixed up a few releases later. Unfortunately every time I tested it with our CryptoTokenKit provider (and also when I retried with SecureEnclaveToken to make sure it wasn't just our code being broken), ssh would tell me "provider /usr/lib/ssh-keychain.dylib returned no slots" which is not especially helpful. Finally I realised that it was actually generating more debug output, but it was being sent to the system debug logs rather than the ssh debug output. Well, when I say "more debug output", I mean "Certificate [<private>]: algorithm is not supported, ignoring it"</private>, which still doesn't tell me all that much. So I stuck it in Ghidra and searched for that string, and the line above it was

iVar2 = __auth_stubs::_objc_msgSend(uVar7,"isEqual:",*(undefined8*)__got::_kSecAttrKeyTypeRSA);

with it immediately failing if the key isn't RSA. Which it isn't, since the Secure Enclave doesn't support RSA. Apple's PKCS#11 module appears incapable of making use of keys generated on Apple's hardware.

There's a couple of ways of dealing with this. The first, which is taken by projects like Secretive, is to implement the SSH agent protocol and have SSH delegate key management to that agent, which can then speak to the keychain. But if you want this to work in all cases you need to implement all the functionality in the existing ssh-agent, and that seems like a bunch of work. The second is to implement a PKCS#11 module, which sounds like less work but probably more mental anguish. I'll figure that out tomorrow.

comment count unavailable comments

X servers no longer allow byte-swapped clients (by default)

Posted by Peter Hutterer on January 17, 2023 10:20 PM

In the beginning, there was the egg. Then fictional people started eating that from different ends, and the terms of "little endians" and "Big Endians" was born.

Computer architectures (mostly) come with one of either byte order: MSB first or LSB first. The two are incompatible of course, and many a bug was introduced trying to convert between the two (or, more common: failing to do so). The two byte orders were termed Big Endian and little endian, because that hilarious naming scheme at least gives us something to laugh about while contemplating throwing it all away and considering a future as, I don't know, a strawberry plant.

Back in the mullet-infested 80s when the X11 protocol was designed both little endian and big endian were common enough. And back then running the X server on a different host than the client was common too - the X terminals back then had less processing power than a smart toilet seat today so the cpu-intensive clients were running on some mainfraime. To avoid overtaxing the poor mainframe already running dozens of clients for multiple users, the job of converting between the two byte orders was punted to the X server. So to this day whenever a client connects, the first byte it sends is a literal "l" or "B" to inform the server of the client's byte order. Where the byte order doesn't match the X server's byte order, the client is a "swapped client" in X server terminology and all 16, 32, and 64-bit values must be "byte-swapped" into the server's byte order. All of those values in all requests, and then again back to the client's byte order in all outgoing replies and events. Forever, till a crash do them part.

If you get one of those wrong, the number is no longer correct. And it's properly wrong too, the difference between 0x1 and 0x01000000 is rather significant. [0] Which has the hilarious side-effect of... well, pretty much anything. But usually it ranges from crashing the server (thus taking all other clients down in commiseration) to leaking random memory locations. The list of security issues affecting the various SProcFoo implementations (X server naming scheme for Swapped Procedure for request Foo) is so long that I'm too lazy to pull out the various security advisories and link to them. Just believe me, ok? *jedi handwave*

These days, encountering a Big Endian host is increasingly niche, letting it run an X client that connects to your local little-endian X server is even more niche [1]. I think the only regular real-world use-case for this is running X clients on an s390x, connecting to your local intel-ish (and thus little endian) workstation. Not something most users do on a regular basis. So right now, the byte-swapping code is mainly a free attack surface that 99% of users never actually use for anything real. So... let's not do that?

I just merged a PR into the X server repo that prohibits byte-swapped clients by default. A Big Endian client connecting to an X server will fail the connection with an error message of "Prohibited client endianess, see the Xserver man page". [2] Thus, a whole class of future security issues avoided - yay!

For the use-cases where you do need to let Big Endian clients connect to your little endian X server, you have two options: start your X server (Xorg, Xwayland, Xnest, ...) with the +byteswappedclients commandline option. Alternatively, and this only applies for Xorg: add Option "AllowByteSwappedClients" "on" to the xorg.conf ServerFlags section. Both of these will change the default back to the original setting. Both are documented in the Xserver(1) and xorg.conf(5) man pages, respectively.

Now, there's a drawback: in the Wayland stack, the compositor is in charge of starting Xwayland which means the compositor needs to expose a way of passing +byteswappedclients to Xwayland. This is compositor-specific, bugs are filed for mutter (merged for GNOME 44), kwin and wlroots. Until those are addressed, you cannot easily change this default (short of changing /usr/bin/Xwayland into a wrapper script that passes the option through).

There's no specific plan yet which X releases this will end up in, primarily because the release cycle for X is...undefined. Probably xserver-23.0 if and when that happens. It'll probably find its way into the xwayland-23.0 release, if and when that happens. Meanwhile, distributions interested in this particular change should consider backporting it to their X server version. This has been accepted as a Fedora 38 change.

[0] Also, it doesn't help that much of the X server's protocol handling code was written with the attitude of "surely the client wouldn't lie about that length value"
[1] little-endian client to Big Endian X server is so rare that it's barely worth talking about. But suffice to say, the exact same applies, just with little and big swapped around.
[2] That message is unceremoniously dumped to stderr, but that bit is unfortunately a libxcb issue.

Anaconda Web UI storage feedback requested!

Posted by Fedora Magazine on January 17, 2023 04:58 PM

As you might know, the Anaconda Web UI preview image has a simple “erase everything” partitioning right now because partitioning is a pretty big and problematic topic. On one hand, Linux guru people want to control everything; on the other hand, we also need to support beginner users. We are also constrained by the capabilities of the existing backend and storage tooling and consistency with the rest of Anaconda. Anaconda team is looking for your storage feedback to help us with design of the Web UI!

In general, partitioning is one of the most complex, problematic, and controversial parts of what Anaconda is doing. Because of that and the great feedback from the last blog, we decided to ask you for feedback again to know where we should focus. We’re looking for feedback from everyone. More answers are better here. We’d like to get input if you’re using Fedora, RHEL, Debian, OpenSUSE, Windows, or Linux, even if it’s just for a week. All these inputs are valuable!

Please help us shape one of the most complex parts of the Anaconda installer!

With just a few minutes of your time filling out the questionnaire, you can help us decide which path we’d like to choose for partitioning.

Questionnaire link: https://redhatdg.co1.qualtrics.com/jfe/form/SV_87bPLycfp1ueko6 

Call for Fedora Linux 38 Test Days

Posted by Fedora Community Blog on January 17, 2023 08:00 AM

It’s time to start thinking about Test Days for Fedora Linux 38. A Test Day is an event aimed getting interested users and developers together to test a specific feature or area of the distribution. You can run a Test Day on just about anything for which it would be useful to do some fairly focused testing in ‘real time’ with a group of testers; it doesn’t have to be code. For instance, we often run Test Days for localization and internationalization topics.

Proposing a Test Day

Anyone who wants to can host their own Test Day, or you can request that the QA group help you out with organization, or a combination of the two. To propose a Test Day, file a ticket in the fedora-qa repo. (See #624 for an example.) For instructions on hosting a Test Day, see the SOP in the wiki.

You can see the schedule in the fedora-qa repo. There are many slots open right now. Consider the development schedule, though, in deciding when you want to run your Test Day. For some topics you may want to avoid the time before the Beta release or the Final Freeze.

We normally aim to schedule Test Days on Thursdays; however, if you want to run a series of related Test Days, it’s often a good idea to do something like Tuesday / Wednesday / Thursday of the same week (this is how we usually run the X Test Week, for instance). If all the Thursday slots fill up but more people want to run Test Days, we will open up Tuesday slots as overflows. And finally, if you really want to run a Test Day in a specific time frame due to the development schedule, but the Thursday slot for that week is full, we can add a slot on another day. We’re flexible! Just put in your ticket the date or time frame you’d like, and we’ll figure it out from there.

Accepted Test Days

If you don’t want to run your own Test Day, but you are willing to help with another, feel free to join one or more of already accepted Test Days (dates to be announced later):

  • GNOME Test Day
  • i18n Test Day
  • Kernel Test Week(s)
  • Upgrade Test Day
  • IoT Test Week
  • Cloud Test Day
  • Fedora CoreOS Test Week

And don’t be afraid, there are a lot of more slots available for your own Test Day!

If you have any questions about the Test Day process, please don’t hesitate to contact me or any member of the Fedora QA team on the test mailing list in #fedora-qa on IRC (#quality on chat.fedoraproject.org).

The post Call for Fedora Linux 38 Test Days appeared first on Fedora Community Blog.

vulkan video decoding: av1 (yes av1) status update

Posted by Dave Airlie on January 17, 2023 07:54 AM

Needless to say h264/5 weren't my real goals in life for video decoding. Lynne and myself decided to see what we could do to drive AV1 decode forward by creating our own extensions called VK_MESA_video_decode_av1. This is a radv only extension so far, and may expose some peculiarities of AMD hardware/firmware.

Lynne's blog entry[1] has all the gory details, so go read that first. (really read it first).

Now that you've read and understood all that, I'll just rant here a bit. Figuring out the DPB management and hw frame ref and curr_pic_idx fields was a bit of a nightmare. I spent a few days hacking up a lot of wrong things before landing on the thing we agreed was the least wrong which was having the ffmpeg code allocate a frame index in the same fashion as the vaapi radeon implementation did. I had another hacky solution that involved overloading the slotIndex value to mean something that wasn't DPB slot index, but it wasn't really any better. I think there may be something about the hw I don't understand so hopefully we can achieve clarity later.

[1] https://lynne.ee/vk_mesa_video_decode_av1.html

libinput and the custom pointer acceleration function

Posted by Peter Hutterer on January 17, 2023 04:47 AM

After 8 months of work by Yinon Burgansky, libinput now has a new pointer acceleration profile: the "custom" profile. This profile allows users to tweak the exact response of their device based on their input speed.

A short primer: the pointer acceleration profile is a function that multiplies the incoming deltas with a given factor F, so that your input delta (x, y) becomes (Fx, Fy). How this is done is specific to the profile, libinput's existing profiles had either a flat factor or an adaptive factor that roughly resembles what Xorg used to have, see the libinput documentation for the details. The adaptive curve however has a fixed behaviour, all a user could do was scale the curve up/down, but not actually adjust the curve.

Input speed to output speed

The new custom filter allows exactly that: it allows a user to configure a completely custom ratio between input speed and output speed. That ratio will then influence the current delta. There is a whole new API to do this but simplified: the profile is defined via a series of points of (x, f(x)) that are linearly interpolated. Each point is defined as input speed in device units/ms to output speed in device units/ms. For example, to provide a flat acceleration equivalent, specify [(0.0, 0.0), (1.0, 1.0)]. With the linear interpolation this is of course a 45-degree function, and any incoming speed will result in the equivalent output speed.

Noteworthy: we are talking about the speed here, not any individual delta. This is not exactly the same as the flat acceleration profile (which merely multiplies the deltas by a constant factor) - it does take the speed of the device into account, i.e. device units moved per ms. For most use-cases this is the same but for particularly slow motion, the speed may be calculated across multiple deltas (e.g. "user moved 1 unit over 21ms"). This avoids some jumpyness at low speeds.

But because the curve is speed-based, it allows for some interesting features too: the curve [(0.0, 1.0), (1.0, 1.0)] is a horizontal function at 1.0. Which means that any input speed results in an output speed of 1 unit/ms. So regardless how fast the user moves the mouse, the output speed is always constant. I'm not immediately sure of a real-world use case for this particular case (some accessibility needs maybe) but I'm sure it's a good prank to play on someone.

Because libinput is written in C, the API is not necessarily immediately obvious but: to configure you pass an array of (what will be) y-values and set the step-size. The curve then becomes: [(0 * step-size, array[0]), (1 * step-size, array[1]), (2 * step-size, array[2]), ...]. There are some limitations on the number of points but they're high enough that they should not matter.

Note that any curve is still device-resolution dependent, so the same curve will not behave the same on two devices with different resolution (DPI). And since the curves uploaded by the user are hand-polished, the speed setting has no effect - we cannot possibly know how a custom curve is supposed to scale. The setting will simply update with the provided value and return that but the behaviour of the device won't change in response.

Motion types

Finally, there's another feature in this PR - the so-called "movement type" which must be set when defining a curve. Right now, we have two types, "fallback" and "motion". The "motion" type applies to, you guessed it, pointer motion. The only other type available is fallback which applies to everything but pointer motion. The idea here is of course that we can apply custom acceleration curves for various different device behaviours - in the future this could be scrolling, gesture motion, etc. And since those will have a different requirements, they can be configure separately.

How to use this?

As usual, the availability of this feature depends on your Wayland compositor and how this is exposed. For the Xorg + xf86-input-libinput case however, the merge request adds a few properties so that you can play with this using the xinput tool:

# Set the flat-equivalent function described above
$ xinput set-prop "devname" "libinput Accel Custom Motion Points" 0.0 1.0
# Set the step, i.e. the above points are on 0 u/ms, 1 u/ms, ...
# Can be skipped, 1.0 is the default anyway
$ xinput set-prop "devname" "libinput Accel Custom Motion Points" 1.0
# Now enable the custom profile
$ xinput set-prop "devname" "libinput Accel Profile Enabled" 0 0 1
The above sets a custom pointer accel for the "motion" type. Setting it for fallback is left as an exercise to the reader (though right now, I think the fallback curve is pretty much only used if there is no motion curve defined).

Happy playing around (and no longer filing bug reports if you don't like the default pointer acceleration ;)


This custom profile will be available in libinput 1.23 and xf86-input-libinput-1.3.0. No release dates have been set yet for either of those.

Build a kiosk with Fedora Silverblue

Posted by Fedora Magazine on January 16, 2023 08:00 AM

This article will describe the process of creating a kiosk or information “station” using Fedora Silverblue.

What is a kiosk

If you’ve had the occasion to visit a museum, you might have used a touchscreen monitor with useful information and insights of the items on display. Or if you’ve attended a public library, you might have used a workstation with a browser or a software aimed to the consultation of the book’s catalog. Or even in public places like train stations or public squares, you might have spotted big screens or televisions where you can see advertisement videos, or interacted with them in order to obtain information and services. These devices are kiosks. They are locked down environments, generally running a full screen application.

Under the hood there is usually a small PC (maybe a fan-less device or a so called industrial PC, capable of staying powered on without issues for long periods of time) or perhaps a Raspberry Pi. Many times they are powered by Linux!

<figure class="wp-block-image size-large"><figcaption>A 10″ Capacitive Touch Display showing the Fedora logo</figcaption></figure>

Why Fedora Silverblue

Fedora Silverblue is a new generation of the desktop operating system. The main benefits of the system are atomic updates and immutability.

Atomic updates means that the update process will complete successfully and if not the operation will be abandoned and the system reverted to the previous state. This prevents situations where some packages are upgraded while others are not. This might occur, for example, due to a power loss in the middle of the update process, leading to an unstable or unbootable system.

In this context, immutability means part of the filesystem is read-only and the system files cannot be modified (at least not in the usual ways, read below). The term has been criticized by several parties: in fact, if you can update the system and install things, the system is actually mutable, so another term should be coined for these kinds of operating systems where there is a clearly defined distinction between the system, the applications and the changes made by the user. However this is not the topic of this article.

You can find more information about Fedora Silverblue in this article: What is Silverblue?

These features make the system more robust and secure. This is an important consideration since a kiosk is usually located in a remote place, accessible to the public (even if hidden inside some box or behind a TV), and difficult to reach in case of malfunctions.

If you have heard about Fedora IoT, you might think that it would be the perfect solution for this kind of operations. However, Fedora IoT, although sharing the same technologies as Fedora Silverblue (immutability, rpm-ostree, etc.), is not designed for and it doesn’t provide a graphical environment. Running headless is the expected use case for Fedora IoT.


GNOME Kiosk is a special GNOME session that “provides a desktop environment suitable for a fixed purpose, or single application deployments like wall displays and point-of-sale systems”. It provides a locked down GNOME session, without activities, dock, top bar, etc.

The required bits are available in the Fedora repository.

How to proceed

As a basic example, we will create a simple slideshow.

First of all let’s install Fedora Silverblue.

The first user created during initial setup becomes the administrator.

Go to Settings. Enable Sharing and enable Remote Login (that is SSH) in order to access the kiosk for remote management.

In Settings, go to Users and add a new user. Let’s call it “kiosk” and assign it a password.

Install GNOME Kiosk

Even though Fedora Silverblue is an immutable system, rpm-ostree still allows you to install packages from the DNF repositories. This is called layering. Read more on How I Customize Fedora Silverblue and Fedora Kinoite.

Open the terminal and issue the following command.

sudo rpm-ostree install gnome-kiosk gnome-kiosk-script-session

To activate the layered packages, you will have to reboot the system.

Automatic login

We have to set the system to automatically log in as the “kiosk” user.

After the reboot, log in as the administrator user. Then go to Settings, Users, select the “kiosk” user, and enable Automatic Login.

<figure class="wp-block-image size-large"></figure>

Then log out (don’t reboot yet).

For reference you can enable automatic login from the command line. To do so, edit the file /etc/gdm/custom.conf, and add the following two lines to the [daemon] section.


Configure the kiosk

At the login screen, select the “kiosk” user.

As a basic example, let’s create a slideshow of images. To do that we will use the GNOME image viewer (Eye of GNOME or eog). This is already installed on Fedora Silverblue as a Flatpak package. (Yes, you can run Flatpak applications from the command line.)

Put some images in the Pictures folder.

In the activities overview, you can find an application called Kiosk Script. Actually Gedit will open it and let you edit the script that will start when you select the Kiosk session at login. For reference, this script is named gnome-kiosk-script and it is located in the home directory under .local/bin.

Read the comments. Pay attention to the last line. If the program that you want to use in the kiosk session exits as soon as it is launched (or it runs in the background), you risk creating an infinite loop that will start a new window each second!

The slideshow script will look like this:


if [ ! "$(pidof eog)" ]
   flatpak run org.gnome.eog -s /home/kiosk/Pictures

sleep 1.0
exec "$0" "$@"

The above example script, will run eog in slideshow mode (indicated by the “-s” option) only if a process called eog isn’t already running. Make certain to take into account that the script can invoke itself in an infinite loop (it is instructed to do so by the last line). Note that if for some reason Eye of GNOME crashes, it will be launched again because of the “if” statement.

Save the script. And the full screen slideshow will start immediately! Don’t worry, you are not yet in the kiosk session. Press the super key and you can still use the dash and the applications overview.


At the login screen click on the gear icon at the bottom right of the login page. Select “Kiosk Script Session (Wayland Display Server)”.

<figure class="wp-block-image size-large"></figure>

Insert the password and the full screen slideshow will start.
You will be in the locked down GNOME session, so you can’t use any application or desktop functions. If needed, you can still switch to a TTY to gain the command line using a combination like CTRL+ALT+F3

For reference, the file containing the user’s default session is /var/lib/AccountsService/users/kiosk


The last step is to reboot the machine.

Other types of kiosk

Other ideas could be:

  • a full screen Firefox session (take a look at the gnome-kiosk-search-appliance RPM package)
  • a video loop
  • your own software specifically crafted for this purpose
  • any application

Further improvements

You might modify the script to show the slideshow only at certain times of the day.

To make the system more robust and secure, you might add a password to GRUB and to the BIOS. You might also disable the TTYs.

Other useful ideas might be to enable automatic updates, and especially to implement greenboot, a health check framework developed for Fedora IoT.

Episode 358 – Furby vs Alexa

Posted by Josh Bressers on January 16, 2023 12:00 AM

Josh and Kurt talk about the Furby source code going public. This is an opportunity to discuss what’s changed in our attitude in devices that record our audio? Our devices today are vastly more powerful and dangerous than a Furby, what does your risk appetite look like?

<audio class="wp-audio-shortcode" controls="controls" id="audio-3039-2" preload="none" style="width: 100%;"><source src="https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_358_Furby_vs_Alexa.mp3?_=2" type="audio/mpeg">https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_358_Furby_vs_Alexa.mp3</audio>

Show Notes

Blogging and microblogging

Posted by Matthew Garrett on January 15, 2023 10:40 PM
Long-term Linux users may remember that Alan Cox used to write an online diary. This was before the concept of a "Weblog" had really become a thing, and there certainly weren't any expectations around what one was used for - while now blogging tends to imply a reasonably long-form piece on a specific topic, Alan was just sitting there noting small life concerns or particular technical details in interesting problems he'd solved that day. For me, that was fascinating. I was trying to figure out how to get into kernel development, and was trying to read as much LKML as I could to figure out how kernel developers did stuff. But when you see discussion on LKML, you're frequently missing the early stages. If an LKML patch is a picture of an owl, I wanted to know how to draw the owl, and most of the conversations about starting in kernel development were very "Draw two circles. Now draw the rest of the owl". Alan's musings gave me insight into the thought processes involved in getting from "Here's the bug" to "Here's the patch" in ways that really wouldn't have worked in a more long-form medium.

For the past decade or so, as I moved away from just doing kernel development and focused more on security work instead, Twitter's filled a similar role for me. I've seen people just dumping their thought process as they work through a problem, helping me come up with effective models for solving similar problems. I've learned that the smartest people in the field will spend hours (if not days) working on an issue before realising that they misread something back at the beginning and that's helped me feel like I'm not unusually bad at any of this. It's helped me learn more about my peers, about my field, and about myself.

Twitter's now under new ownership that appears to think all the worst bits of Twitter were actually the good bits, so I've mostly bailed to the Fediverse instead. There's no intrinsic length limit on posts there - Mastodon defaults to 500 characters per post, but that's configurable per instance. But even at 500 characters, it means there's more room to provide thoughtful context than there is on Twitter, and what I've seen so far is more detailed conversation and higher levels of meaningful engagement. Which is great! Except it also seems to discourage some of the posting style that I found so valuable on Twitter - if your timeline is full of nuanced discourse, it feels kind of rude to just scream "THIS FUCKING PIECE OF SHIT IGNORES THE HIGH ADDRESS BIT ON EVERY OTHER WRITE" even though that's exactly the sort of content I'm there for.

And, yeah, not everything has to be for me. But I worry that as Twitter's relevance fades for the people I'm most interested in, we're replacing it with something that's not equivalent - something that doesn't encourage just dropping 50 characters or so of your current thought process into a space where it can be seen by thousands of people. And I think that's a shame.

comment count unavailable comments

New badge: Fedora Week of Diversity 2023 !

Posted by Fedora Badges on January 15, 2023 02:34 PM
Fedora Week of Diversity 2023You contributed to or participated in the Fedora Week of Diversity 2023!

Yum Extender is very keyboard friendly

Posted by Tim Lauridsen on January 15, 2023 12:26 PM


 It has been a design goal to make Yum Extender NextGen very keyboard friendly, not just having keyboard shortcuts, but also have a effective workflow.

<iframe allowfullscreen="allowfullscreen" class="b-hbp-video b-uploaded" frameborder="0" height="527" mozallowfullscreen="mozallowfullscreen" src="https://www.blogger.com/video.g?token=AD6v5dzka1I_SfatyL-lB55ke9Sd1Jk_Rs0Hzx6pi7XaQ5Q8PXXs63CK8dwg9k690c4O2trmnpdxJpbjRWVWvWNIeA" webkitallowfullscreen="webkitallowfullscreen" width="633"></iframe>

Fedora packages


Development site



Posted by Bodhi on January 14, 2023 09:50 AM

Released on 2023-01-14.
This is a bugfix release.

Bug fixes

  • Fixed template in overrides list page which prevents the display of filters dropdown (#4844).
  • Fixed a possible XSS attack vector in update_form.js (#4845).


The following developers contributed to this release of Bodhi:

  • Mattia Verga

Laws of technology and remote work

Posted by Joe Brockmeier on January 14, 2023 03:11 AM

Some observations on a Friday evening about the realities of home offices and technology.


  • A laptop’s cabling will always be located on the maximally inconvenient side. Especially power cords with bulky connectors.
  • Internet only fails before or during an important teleconference or the most suspenseful part of a movie or show.
    • This is also true of power outages.
  • Hotel internet is most reliable at mid-range hotels. Fleabag hotels and swank resorts have uniformly crappy internet.
  • The most aloof house cat will only want cuddles when you’re trying to focus.
  • The dongle, connector, cord, or other item you know you own and see frequently when unneeded goes into witness protection when it’s wanted. It will resurface when a replacement is obtained.
  • All deliveries and service calls happen while in meetings.
    • UPS and FedEx only ring the doorbell when it’s inconvenient. Otherwise deliveries are made with maximum stealth. Packages requiring signatures will be announced in a whisper from across the street.
  • After troubleshooting a system or application extensively it will turn out that the problem is a faulty cable or coincidental internet glitch. However, you are likely to have introduced a new, unrelated problem in an attempt to fix the symptoms.

Technology: The solution to, and cause of, most of life’s problems!

The post Laws of technology and remote work appeared first on Dissociated Press.

What is ActiveRecord becomes from Rails

Posted by Josef Strzibny on January 14, 2023 12:00 AM

Have you heard about the ActiveRecord becomes method from Rails? Maybe it’ll come handy one day.


The #becomes method can be used on any ActiveRecord model to become a different class instantly.

Here’s how:

class Car

class Honda < Car

# Later

@honda = Honda.new(..)
@i_am_a_car_instance = @honda.becomes(Car)

Any model can become some other model on a whim with the same attributes. But why do we need #become at all?

A typical use-case would be using single table inheritance (STI) while keeping Rails conventions intact.

For example, building forms and rendering partials are derived from the instance class name which would intervene with reusing the parent model routes and partials:

# Use Car's routes
form_for @honda.becomes(Car)

# Use Car's partials
render partial: @honda.becomes(Car)

In short, #becomes helps us to pass the right object without providing the full paths and partials if they don’t match the object at hand.

Friday’s Fedora Facts: 2023-02

Posted by Fedora Community Blog on January 13, 2023 09:00 PM

Here’s your weekly Fedora report. Read what happened this week and what’s coming up. Your contributions are welcome (see the end of the post)!

I have weekly office hours on Wednesdays in the morning and afternoon (US/Eastern time) in #fedora-meeting-1. Drop by if you have any questions or comments about the schedule, Changes, elections, or anything else. See the upcoming meetings for more information.



<figure class="wp-block-table">
Hack in ParisParis, FR26–29 Sepcloses 14 Jan
VueConfNew Orleans, LA, US25–26 Maycloses 15 Jan
JS Day CanariasTenerife, ES25–28 Maycloses 15 Jan
phpdayVerona, IT18–19 Maycloses 15 Jan
PyCon ItaliaFlorence, IT25–28 Maycloses 16 Jan
DevConfCape Town & Pretoria, ZA23 & 25 Maycloses 17 Jan
WASM IOBarcelona, ES23–24 Marcloses 17 Jan
Container Plumbing Daysvirtual22–23 Marcloses 23 Jan
MagnoliaJSJackson, MS, US17–18 Octcloses 31 Jan
jsdayVerona, IT13–14 Aprcloses 31 Jan
ConnectahaOmaha, NE, US24 Aprcloses 31 Jan
Open Source Summit North AmericaVancouver, BC, CA10–12 Maycloses 5 Feb
Write The DocsPortland, OR, US7–9 Maycloses 6 Feb
NewcraftsParis, FR25–26 Maycloses 12 Feb
Open Source NorthSt. Paul, MN, US24 Maycloses 18 Feb
Berlin BuzzwordsBerlin, DE 18–20 Juncloses 19 Feb
JSDay IEDublin, IE26 Sepcloses 28 Feb
Scenic City SummitChattanooga, TN, US2 Juncloses 1 Mar
DevOpsDays ChicagoChicago, IL, US9–10 Augcloses 17 Mar
openSUSE Conference 2023Nürnberg, DE26–28 Maycloses 9 Apr
Web Weekend KathmanduKathmandu, NP23–24 Sepcloses 21 Apr

Help wanted

Upcoming test days

Have a test day idea for Fedora Linux 38? The call for test days is open.

Meetings & events


<figure class="wp-block-table">
Releaseopen bugs

Prioritized Bugs

See the Prioritized Bugs documentation for information on the process, including how to nominate bugs.

<figure class="wp-block-table">
Bug IDComponentStatus

Fedora Linux 38


Below are some upcoming schedule dates. See the schedule website for the full schedule.

  • 2023-01-17 — Deadline for Self-Contained Changes
  • 2023-01-18 — F38 Mass rebuild begins
  • 2023-02-07 — F38 branches from Rawhide


The table below lists proposed Changes. See the ChangeSet page or Bugzilla for information on approved Changes.

<figure class="wp-block-table">
Pyramid 2.0Self-ContainedApproved
Xfce 4.18Self-ContainedApproved
Unified Kernel Support Phase 1System-WideApproved
X Server Prohibits Byte-swapped ClientsSystem-WideApproved
Shorter Shutdown TimerSystem-WideFESCo #2928
Rpmautospec by DefaultSystem-WideFESCo #2930
Noto Fonts For More LanguagesSystem-WideFESCo #2931
GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1)System-WideFESCo #2932
FPC repackagingSelf-ContainedFESCo #2933
TeXLive2022Self-ContainedFESCo #2935
Noto CJK Variable FontsSelf-ContainedAnnounced
Unfiltered FlathubSystem-WideAnnounced
IPP-USB as a weak dependency of CUPS and sane-airscanSelf-ContainedAnnounced

Fedora Linux 39


The table below lists proposed Changes.

<figure class="wp-block-table">
Replace DNF with DNF5System-WideFESCo #2870


Have something you want included? You can file an issue or submit a pull request in the fedora-pgm/pgm_communication repo.

The post Friday’s Fedora Facts: 2023-02 appeared first on Fedora Community Blog.

Next Open NeuroFedora meeting: 16 January 1300 UTC

Posted by The NeuroFedora Blog on January 13, 2023 11:40 AM
Photo by William White on Unsplash

Photo by William White on Unsplash.

Happy new year!!

Please join us at the next regular Open NeuroFedora team meeting on Monday 16 January at 1300 UTC. The meeting is a public meeting, and open for everyone to attend. You can join us over:

You can use this link to convert the meeting time to your local time. Or, you can also use this command in the terminal:

$ date --date='TZ="UTC" 1300 2023-01-16'

The meeting will be chaired by @ankursinha. The agenda for the meeting is:

We hope to see you there!

Looking for mentors with project proposals for Outreachy May-August 2023

Posted by Felipe Borges on January 13, 2023 10:03 AM

Hi folks!

We are interested in sponsoring Outreachy internships projects for the May-August 2023 cohort. Project ideas should be submitted before February 7.

GNOME usually has a few participants in Outreachy, so we are looking to offer projects that are most strategic for GNOME. These include, but are not limited to, projects in the area of privacy, GTK, core experience, core applications, developer experience, and development infrastructure. More information about GNOME’s participation in Outreachy is available at Outreach/Outreachy – GNOME Wiki! .

If you would like to mentor this round, please propose a project idea at our Internship Project Ideas Gitlab project.  Once your project proposal has been reviewed, you will be asked to submit it in the Outreachy website. All project ideas need to be approved by the triage committee (Matthias Clasen, Allan Day, and Sriram Ramkrishna) and coordinators (me and Kristi) .

If you have any questions, please feel free to reply to this thread or you can message us privately at soc-admins@gnome.org.

This is a repost from https://discourse.gnome.org/t/outreachy-due-february-7-call-for-outreachy-mentors-for-may-2023-internships/13506

CPE Weekly Update – Week 2 2023

Posted by Fedora Community Blog on January 13, 2023 10:00 AM

This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on libera.chat.

We provide you both infographics and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.

Week: 09 January – 13 January 2023

<figure class="aligncenter size-full">CPE Infographics</figure>

Highlights of the week

Infrastructure & Release Engineering

Goal of this Initiative

Purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible initiatives that CPE might take on.
Planning board


Fedora Infra

  • Got container pipeline all working before the break in Dec (many thanks to cverna and others who worked on it)
  • Finally fixed proxy09’s ipv6 issues, it’s fully operational now.
  • Pushed fix for collectd selinux denial thats been around for a while.
  • Catching up on requests, etc from break

CentOS Infra including CentOS CI

Release Engineering

  • SCM Request Processor is now live in production, this automates SCM (Source Code Management) requests
  • butane 0.17.0 release signed
  • Pagure-dist-git release is in f36,f37,f38 and epel7 stable epel8 build is incoming

CentOS Stream

Goal of this Initiative

This initiative is working on CentOS Stream/Emerging RHEL to make this new distribution a reality. The goal of this initiative is to prepare the ecosystem for the new CentOS Stream.



    Goal of this initiative

    Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL).

    EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more.


    • EPEL 9 is up to 13,004 (+763) packages from 4,828 (+256) source packages
      • EPEL 9 has officially passed EPEL 8 for number of source packages
    • Filed tickets and patches for uninstallable packages (blosc-bench, poezio)

      FMN replacement

      Goal of this initiative

      FMN (Fedora-Messaging-Notification) is a web application allowing users to create filters on messages sent to (currently) fedmsg and forward these as notifications on to email or IRC.
      The goal of the initiative is mainly to add fedora-messaging schemas, create a new UI for a better user experience and create a new service to triage incoming messages to reduce the current message delivery lag problem. Community will profit from speedier notifications based on own preferences (IRC, Matrix, Email), unified fedora project to one message service and human-readable results in Datagrepper.
      Also, CPE tech debt will be significantly reduced by dropping the maintenance of fedmsg altogether.


      • Planning Call completed yesterday, 10/1
        • 2 priorities identified
          • Caching 
          • Message schemas for any and all apps that interact with FMN standardized

      Community Design

      Goal of this initiative

      CPE has few members that are working as part of Community Design Team. This team is working on anything related to design in Fedora Community.


        The post CPE Weekly Update – Week 2 2023 appeared first on Fedora Community Blog.

        Enable Libvirt rw socket on RHEL9

        Posted by Pablo Iranzo Gómez on January 12, 2023 02:32 PM
        RHEL9 by default uses read-only socket which is not usable by some tools like Kcli… to enable it use: systemctl enable --now libvirtd.socket libvirtd-ro.socket systemctl stop libvirtd.service systemctl enable --now virtproxyd.socket virtproxyd-ro.socket systemctl stop virtproxyd.service