Fedora People

PHP version 8.2.0 is released!

Posted by Remi Collet on December 08, 2022 12:49 PM

RC7 was GOLD, so version 8.2.0 GA is just released, at planed date.

A great thanks to Perrick Charron, Sergey Panteleev and Ben Ramsey our Release Managers,  to all developers who have contributed to this new  long awaiting version of PHP and thanks to all testers of the RC versions who have allowed us to deliver a good quality version.

RPM are available in the php:remi-8.2 module for Fedora and Enterprise Linux 8 and as Software Collection in the remi-safe repository.

RPM are also available in the remi-php82 repository for  Enterprise Linux 7 (RHEL, CentOS, Alma, Rocky...).

Read the PHP 8.2.0 Release Announcement and its Addendum for new features detailed description.

For memory, this is the result of 6 months of work for me to provide these packages, starting in May for Software Collections of alpha versions, in September for module streams of RC versions, and also a lot of work on extensions to provide a mostly full PHP 8.2 stack.

emblem-notice-24.pngInstallation: read the Repository configuration and choose installation mode, or follow the Configuration Wizard instructions.

Replacement of default PHP by version 8.2 installation (simplest):

Fedora modular or Enterprise Linux 8:

dnf module reset php
dnf module install php:remi-8.2

Enterprise Linux 7:

yum-config-manager --enable remi-php82
yum update php\*

Parallel installation of version 8.2 as Software Collection (x86_64 only, recommended for tests):

yum install php82

emblem-important-2-24.pngTo be noticed :

  • EL9 RPMs are build using RHEL-9.1
  • EL8 RPMs are build using RHEL-8.7
  • EL7 RPMs are build using RHEL-7.9
  • this version will also be the default version in Fedora 38
  • lot of extensions are already available, see the PECL extension RPM status page.

emblem-notice-24.pngInformation, read:

Base packages (php)

Software Collections (php82)

12/7/22 Status Update

Posted by Madeline Peck on December 08, 2022 07:00 AM

Creative Freedom Summit

<figure class=" sqs-block-image-figure intrinsic "> <figcaption class="image-caption-wrapper">

1) First version I very quickly drew up, playing off of the design team’s banner with the gradient. I think I’ll see what this looks like with the characters in full color.

</figcaption> </figure> <figure class=" sqs-block-image-figure intrinsic "> <figcaption class="image-caption-wrapper">

2) Still playing around with the gradients and trying to incorporate all the other colors. The colors weren’t blending enough for me personally and I don’t like the centered layout of the logo and text.

</figcaption> </figure> <figure class=" sqs-block-image-figure intrinsic "> <figcaption class="image-caption-wrapper">

3) This was the first one I was happy with. Added the shapes to try and lean into the playful creative side.

</figcaption> </figure> <figure class=" sqs-block-image-figure intrinsic "> <figcaption class="image-caption-wrapper">

4) Wondered if the textured lines would be better kind of ebbing and flowing around the edges of the banner instead of coming out of the characters.

</figcaption> </figure> <figure class=" sqs-block-image-figure intrinsic "> <figcaption class="image-caption-wrapper">

5) Essentially the dark version of #3. But I figured I’d play around with adding more texture to the green marker, the placement of ‘live’ and the shapes I include.

</figcaption> </figure>

The Creative Freedom Summit in January is going to be recorded on Peertube and as such needs a specific banner for the videos.

Just went into Inkscape with the great logo and type svg designed by Jess Chitas and started playing around. Felt very satisfying and honestly wanted to keep going but figured it might be better to work on something else while people give feedback.

Oskar the Lion!

I don’t think I ever updated on here that the character I designed, to spread the good news of open source ways had their name chosen in a vote! *Drum roll please* they are called Oskar!

Along with the peertube banner I’m working on social media posts that can be formatted for multiple sites and Oskar would be a perfect addition to spice up the graphics! So the half finished svg file has been re opened and I gathered some inspo from the Fedora characters on what other poses/expressions might be helpful. It’s been super satisfying to make the svg file organized with a ton of layers and make Oskar like a digital paper doll. You can even drag their cheery facial expression off and replace it with a different one!

<figure class=" sqs-block-image-figure intrinsic "> </figure>

Miscellaneous etc.

Did some cleaning up in the epic for the Icon design project so Tanu can speed through the tickets. We discussed that she feels confident about being able to finish them all so we brainstormed some push goals if that does turn out to be the case.

Led the Design Team meeting on 12/7. Made sure to spend the first 10-15 minutes triaging one ticket and checking in on one that looked like it needed some attention. I gave feedback on the Anaconda logo redesign and loved seeing Emma’s Fedora cloud web page designs!

Hope everyone has a great week :) I just read this graphic novel Thieves by Lucie Bryon this week and it was so good! I might be biased since I’ve been consuming her art online for awhile. But it was inspiring to see the comic I’ve been seeing snippets of for years on social media, finally in my own hands.

Syslog-ng 101, part 2: Basic concepts

Posted by Peter Czanik on December 07, 2022 02:15 PM

Welcome to the second part of my syslog-ng tutorial series. In this part, we cover some of the basic concepts behind syslog-ng.

Last time we defined syslog-ng as an enhanced logging daemon with a strong focus on portability and high-performance central log collection.

Let us pull this sentence apart, as all words are here for a reason. The original syslog implementation was pretty simple: it collected log messages from applications and sorted them to various files. Syslog-ng enhanced this with message parsing, advanced filtering and many more log sources and destinations. Daemon means that it is an application normally running continuously in the background. Portability means that syslog-ng runs not just on Linux, but also on various BSD and UNIX systems as well. High performance means that syslog-ng is implemented in C and thus it is fast and resource efficient. Depending on the configuration, even a Raspberry Pi can collect tens of thousands of log messages a second.

You can watch the video on YouTube:

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

Or you can read the rest of my blog at: https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-101-part-2-basic-concepts

<figure><figcaption>

syslog-ng logo

</figcaption> </figure>

Making an Orbic Speed RC400L autoboot when USB power is attached

Posted by Matthew Garrett on December 07, 2022 06:33 AM
As I mentioned a couple of weeks ago, I've been trying to hack an Orbic Speed RC400L mobile hotspot so it'll automatically boot when power is attached. When plugged in it would flash a "Welcome" screen and then switch to a display showing the battery charging - it wouldn't show up on USB, and didn't turn on any networking. So, my initial assumption was that the bootloader was making a policy decision not to boot Linux. After getting root (as described in the previous post), I was able to cat /proc/mtd and see that partition 7 was titled "aboot". Aboot is a commonly used Android bootloader, based on Little Kernel - LK provides the hardware interface, aboot is simply an app that runs on top of it. I was able to find the source code for Quectel's aboot, which is intended to run on the same SoC that's in this hotspot, so it was relatively easy to line up a bunch of the Ghidra decompilation with actual source (top tip: find interesting strings in your decompilation and paste them into github search, and see whether you get a repo back).

Unfortunately looking through this showed various cases where bootloader policy decisions were made, but all of them seemed to result in Linux booting. Patching them and flashing the patched loader back to the hotspot didn't change the behaviour. So now I was confused: it seemed like Linux was loading, but there wasn't an obvious point in the boot scripts where it then decided not to do stuff. No boot logs were retained between boots, which made things even more annoying. But then I realised that, well, I have root - I can just do my own logging. I hacked in an additional init script to dump dmesg to /var, powered it down, and then plugged in a USB cable. It booted to the charging screen. I hit the power button and it booted fully, appearing on USB. I adb shelled in, checked the logs, and saw that it had booted twice. So, we were definitely entering Linux before showing the charging screen. But what was the difference?

Diffing the dmesg showed that there was a major distinction on the kernel command line. The kernel command line is data populated by the bootloader and then passed to the kernel - it's how you provide arguments that alter kernel behaviour without having to recompile it, but it's also exposed to userland by the running kernel so it also serves as a way for the bootloader to pass information to the running userland. The boot that resulted in the charging screen had a androidboot.poweronreason=USB argument, the one that booted fully had androidboot.poweronreason=PWRKEY. Searching the filesystem for androidboot.poweronreason showed that the script that configures USB did not enable USB if poweronreason was USB, and the same string also showed up in a bunch of other applications. The bootloader was always booting Linux, but it was telling Linux why it had booted, and if that reason was "USB" then Linux was choosing not to enable USB and not starting the networking stack.

One approach would be to modify every application that parsed this data and make it work even if the power on reason was "USB". That would have been tedious. It seemed easier to modify the bootloader. Looking for that string in Ghidra showed that it was reading a register from the power management controller and then interpreting that to determine the reason it had booted. In effect, it was doing something like:
boot_reason = read_pmic_boot_reason();
switch(boot_reason) {
case 0x10:
  bootparam = strdup("androidboot.poweronreason=PWRKEY");
  break;
case 0x20:
  bootparam = strdup("androidboot.poweronreason=USB");
  break;
default:
  bootparam = strdup("androidboot.poweronreason=Hard_Reset");
}
Changing the 0x20 to 0xff meant that the USB case would never be detected, and it would fall through to the default. All the userland code was happy to accept "Hard_Reset" as a legitimate reason to boot, and now plugging in USB results in the modem booting to a functional state. Woo.

If you want to do this yourself, dump the aboot partition from your device, and search for the hex sequence "03 02 00 0a 20"". Change the final 0x20 to 0xff, copy it back to the device, and write it to mtdblock7. If it doesn't work, feel free to curse me, but I'm almost certainly going to be no use to you whatsoever. Also, please, do not just attempt to mechanically apply this to other hotspots. It's not going to end well.

comment count unavailable comments

Where does Mastodon fit with social media policies?

Posted by Joe Brockmeier on December 07, 2022 02:55 AM
Mastodon is an odd beast. This has been discussed a lot from the user’s point of view, but not so much from the organizational point...

Community Blog monthly summary: November 2022

Posted by Fedora Community Blog on December 06, 2022 08:00 AM

This is the latest in our monthly series summarizing the past month on the Community Blog. Please leave a comment below to let me know what you think.

Stats

In November, we published 14 posts. The site had 8,371 visits from 5,444 unique viewers. 1,971 visits came from search engines, while 1,222 came from Fedora Magazine and 116 came from Distrowatch.

The most read post last month was “Anaconda is getting a new suit” with 2,781 views. The most read post published last month was “Fedora 37 Release Party Brazil” with 136 views.

Badges

Congratulations to Michal for being the fourth person to reach this milestone.

Your content here!

The Community Blog is the place to publish community-facing updates on what you’re working on in Fedora. The process is easy, so submit early and submit often.

The post Community Blog monthly summary: November 2022 appeared first on Fedora Community Blog.

Three great examples of open source product roadmaps

Posted by Justin W. Flory on December 06, 2022 08:00 AM

The post Three great examples of open source product roadmaps appeared first on /home/jwf/.

/home/jwf/ - Free & Open Source, technology, travel, and life reflections

The hand of a person is visible as they are pointing at a whiteboard. The board has "Product roadmap" written on it, with big circles that represent each fiscal quarter of the year. A line from each circle connects to goals or ambitions for the product, like "Launch" or "publish iOS app". The image is subtitled, "Three product roadmap examples." This post is about product roadmaps.

In my daily reading, I came across three product roadmaps from Proton, developers of several open source, privacy-centered products. These include products like Proton Mail, Proton VPN, and Proton Drive. The product roadmaps shared by Proton play a tactical role. They inform consumers and engaged customers about exciting changes yet to come. It gets people excited about the product’s future. Additionally, it builds an engaged user base that is more willing to experiment and try new features.

Product roadmaps are something many projects struggle with. It fits into the communications and outreach umbrella, which unfortunately is typically an underresourced part of many open source products. They are one small part of a larger strategy around openness and transparency. If customers and stakeholders know what to expect, they gain more confidence in the product and company mission. For instance, this is especially true when the company continuously delivers on its roadmaps and meets its ambitions. As a result, delivering on those ambitions leaves a strong impression.

Highlights from Proton product roadmaps

Of particular note, these product roadmaps do the following things well from a messaging point-of-view:

  1. Builds context with previous work delivered in the last year for the product.
  2. Several clearly-defined goals and ambitions for each product are defined and explained. The aspirations for the coming year are spelled out and users can begin to form realistic expectations about what new features to anticipate.
    • Some highly-motivated individuals may use this as an opportunity to make their first contribution to the product, whether in the form of feedback or code.
  3. Strong call-to-action at the end of each article, where Proton defines how people can participate and engage with feedback about the products.

Check out each of the three product roadmaps below and let me know what you think about them in a comment on this post.


Proton Mail & Proton Calendar

[…] we want to provide an update on what’s coming next for Proton Mail and Proton Calendar. As 2022 wraps up and we look into the new year, we want to develop stronger protections against technologies that invade your privacy, improve your reading experience, and make your day more productive through deeper integrations between our products. 

proton.me/blog/proton-mail-calendar-roadmap

Proton VPN

In March, we shared our 2022 roadmap for Proton, including Proton VPN. Now that we’ve reached November, we feel it’s a good time to revisit our progress this year and explain what you can expect from Proton VPN in the near future.

protonvpn.com/blog/proton-vpn-roadmap-spring-2023/

Proton Drive

In September 2022, we were excited to launch Proton Drive and introduce the first standalone Proton Drive paid plans. As with all the services we’ve rolled out over the years, we know the launch is just the first step. The real work is in the continual improvements, advancements, and added features that follow. Building an encrypted file storage service is not easy, particularly one that uses end-to-end encryption on both your files and file metadata like Proton Drive.

Many of you have asked us what is next for Proton Drive, and today, we wanted to share with you a short-term roadmap of what you can expect in the coming quarters. Of course, we also have longer-term roadmaps. We look forward to sharing those and keeping you updated on the latest developments as Proton Drive progresses.

proton.me/blog/proton-drive-roadmap

Photo by Slidebean on Unsplash. Modified by Justin W. Flory.

Link-o-Rama: Banning AI, thinking about failure, goblin mode

Posted by Joe Brockmeier on December 06, 2022 02:58 AM
Today’s been a good, but busy, day. Too busy to finish off that post that’s been lurking, for months, in my drafts but a good...

Where Fedora Linux Could Improve

Posted by TheEvilSkeleton on December 06, 2022 12:00 AM

Disclaimers

  1. I am not employed by Red Hat (yes, I have to say that).
  2. I may sound rude, so I sincerely apologize for that, as I am really critical in some of these topics.
  3. “Fedora Project” is referred to the organization. “Fedora Linux” is referred to Fedora operating systems, like Fedora Workstation, Fedora KDE Plasma Desktop Edition, Fedora Silverblue, and others. “Fedora Linux community” is referred to the Fedora Project/Linux community, such as developers, contributors and users.

Introduction

The Fedora Project is a great organization to gain experience no matter the team you are in. I am currently a part of the Fedora Websites & Apps team improving my technical writing, communication and design skills.

With all the things the Fedora Project does well, there are several places that, in my opinion, need to be improved. I’d like to go over some key areas where we could improve Fedora Linux from a user perspective without breaking the Fedora Project’s core philosophies.

Unification and Uniformity

In my opinion, Fedora Linux suffers from severe inconsistencies, such as website design and distribution naming scheme, which can be quite daunting to learn from an end user perspective.

Standard Styles and Layouts

At the moment, many Fedora Linux pages look inconsistent from one another. Fedora Workstation, Fedora Server and Fedora IoT follow a common style and layout, whereas Fedora Silverblue, Fedora Kinoite and Fedora CoreOS don’t. This means there are a total of four entirely different styles and layouts. This gives the impression that Fedora Silverblue, Fedora Kinoite and Fedora CoreOS are external projects and are barely related to the Fedora Project, rather than official projects endorsed by the Fedora Project.

I believe that we should focus on standardizing by unifying the styles and layouts in a single framework, instead of reinventing the wheel with no standardization in mind. Luckily, Fedora Kinoite and Fedora CoreOS website maintainers are in favor of unifying; hopefully everyone else is on board and we can provide a platform for internal projects.

Naming Convention

Similar to Fedora Linux pages, I believe Fedora Linux lacks a naming convention. For example, Fedora Workstation uses GNOME and uses the traditional Linux desktop paradigm for managing packages. On the other hand, Fedora Silverblue is visually the same as Fedora Workstation, with the main difference that it reinvents the Linux desktop paradigm to solve fundamental issues with the Linux desktop. The name “Fedora Workstation” conveys what it is intended for, whereas “Fedora Silverblue” doesn’t. In reality, “Fedora Silverblue” doesn’t have a clear meaning, and doesn’t even give a hint to users about what it is trying to do or be.

This lack of a naming convention expands with Fedora KDE Plasma Desktop Edition (or Fedora KDE for short) and Fedora Kinoite for Plasma, Fedora Server and CoreOS for server, and others.

Furthermore, with Fedora Silverblue/Kinoite/CoreOS, there is no concept of spins and editions. Despite being fundamentally the same, each is treated as an entirely separate project. For example, Fedora KDE is Fedora Workstation with KDE Plasma instead of GNOME, whereas on the immutable end, Fedora Kinoite is Fedora Silverblue with KDE Plasma. Despite this equivalency, Fedora KDE is a spin, whereas Fedora Kinoite is a whole separate distribution, when it could be a spin instead.

To address this, a category that englobes all immutable distributions would not only improve the naming scheme, it would also be easier for users to reference all immutable distributions without needing to enumerate through them. For example, instead of Fedora Silverblue, it could be Fedora Immutable Workstation, or Fedora Atomic Workstation. For Plasma, it could be Fedora Immutable KDE. To reference all of them, we could call them “Fedora Immutable” or “Fedora Atomic”. This could also help us reintroduce spins and editions.

Only Ship Unfiltered Flathub by Default

Flatpak is pre-installed on Fedora Linux. It comes with a heavily filtered variant of Flathub and comes with Fedora Flatpaks, Fedora’s Flatpak remote.

Typically, distributions that pre-install Flatpak also pre-add an unfiltered Flathub, as it is the de-facto and most popular remote. I am personally completely against pushing Fedora Flatpaks and filtering Flathub, as it is a hostile approach in pushing Flatpak, and is unsustainable.

The Problems With Fedora Flatpaks

Since the very beginning of Fedora Flatpaks’s existence, the Fedora Project pushes it unconditionally, all without putting the effort to convince users and developers for any practical benefits. This is really harmful to Flatpak adoption and to Fedora Linux in general, as users (and even contributors) don’t have useful information regarding Fedora Flatpaks and its benefits. This leaves a distasteful experience with Fedora Flatpaks to users, while believing that this is a problem with Flatpak itself (like myself when I first tried them).

Fedora Flatpaks lacks many contributors and support, as many more developers and organizations are interested in Flathub. Furthermore, there is no support room/channel related for Fedora Flatpaks. In contrast, the Flatpak Matrix room is a shared room for Flatpak and Flathub. So, not only is there no proper support for Fedora Flatpaks, there aren’t enough contributors and developers to sustain Fedora Flatpaks.

10 months ago, I wrote an article at the Fedora Magazine to compare and contrast Fedora Flatpaks and Flathub. In the “Number of applications” section, I checked the amount of applications available in Fedora Flatpaks and Flathub. At that time, Fedora Flatpaks had 86 applications available, whereas Flathub had 1518. Let’s compare the numbers as of writing this article:

$ flatpak remote-ls --app fedora | wc -l
87
$ flatpak remote-ls --app flathub | wc -l
1988

We notice that, 10 months later, Fedora Flatpaks only published one application, whereas the amount of applications in Flathub went from just above 1500 to almost 2000. Fedora Flatpaks was first introduced in late 2018. In the span of 4 years, Fedora Flatpaks still hasn’t reached 100 applications.

Many developers and users do not consider Fedora Flatpaks appealing, myself included. This is dangerous for Flatpak’s future, as Fedora Linux is meant to be appealing for developers. However, developers side with Flathub instead, including those who develop free and open source software. These developers will only publish their applications on Flathub thanks to Flathub’s much wider coverage in support and discoverability.

Personally, I believe that Fedora Flatpaks is very anti-collaborative and hostile on the Fedora Project’s end, especially when the Fedora Project has a long history of collaborating with upstream projects to advance the Linux desktop. With Flathub, we notice that GNOME, KDE, elementary, Endless Foundation, and many other free and open source organizations collaborate for Flathub development and adoption, whereas the Fedora Project is one of the exceptions.

Why Only Flathub Should Be Pushed

We’re not only noticing usability paradigm shifts, we’re also noticing a community paradigm shift, where major communities with different backgrounds and goals agree, develop and adopt the same standard, instead of implementing everything internally and risking worsening fragmentation. Having the Fedora Project involved in Flathub development and adoption and dropping support for Fedora Flatpaks would seriously improve the Linux desktop (and mobile) in the long run.

We have noticed a consistent positive outcome when many communities come together and work on a single standard, notably systemd, freedesktop.org standards or even the infamous Linux kernel. When we all adopt the same standards, the improvements become exponentially larger.

From a legal perspective, Flatpak introduces a method to work around proprietary licenses and codecs, as explained in this video. Everything Flathub develops is entirely free and open source, so this does not go against the philosophy that the Fedora Project preaches. Furthermore, store front-ends, such as GNOME Software and KDE Discover, even have a dedicate section that explains the risks of proprietary software.

Adwaita-Qt

When I first used Qt applications on Fedora Linux on GNOME, many of them were literally unusable, due to styling issues. This is because Fedora Linux comes with Adwaita-Qt, “[a] style to bend Qt applications to look like they belong into GNOME Shell”. Here are some examples of usability issues:

Dolphin Kate Konsole

Initially, I had no good knowledge with Qt, so I thought these were application issues. Since the Fedora Linux community often claims that Fedora Linux provides a “vanilla” experience, the last thing I would expect is it modifying the interface and behavior of applications. Unfortunately, I was wrong – Fedora Linux does not provide a vanilla experience, as it modifies Qt applications on GNOME.

After 30 minutes of fiddling with styling, I finally found the solution: to use Breeze, the default style in Plasma. In my case, I uninstalled Adwaita-Qt from my systems.

The main problem with styling is that it is literally impossible to be as reliable as the most common style (in this case, Breeze). Most developers test Qt applications with Breeze, without testing with other styles. Breeze itself isn’t perfect, but it has the narrowest scope of breakage, but any custom style will always broaden the scope, and thus will increase the chance of breaking user experience. Shipping custom styles by default may make applications appear broken, and may even give the impression to the user that the application is at fault, which initially happened to me, as explained above.

I strongly urge the Fedora Project to stop shipping Adwaita-Qt by default. While I have no problem with custom styles existing, breaking applications by default is harmful to the relationship between application developers, distribution maintainers and users. The best we can do is ship however the developer tested their application, and let users break their system themselves.

Conclusion

Fedora Linux is my favorite Linux distribution, because it does many things right, especially the amount of effort the community is putting to advocate for free and open source software and community involvement. However, it is not perfect. There are areas I certainly disagree with, like pushing Fedora Flatpaks and Adwaita-Qt.

I personally believe that we should push big organizations into collaborating with other organizations and the rest of the community, instead of potentially creating an unsustainable alternative. I also believe that we should protect the user and developer experience by not modifying the visuals of the program, to avoid conflicts and guarantee the best experience to the user.


  • Edit 1: Update Flathub information (Credit to Cassidy James)
  • Edit 2: Correct typos and improve sentences

December 2022

Posted by Weekly status of Packit Team on December 05, 2022 12:51 PM
Week 48 (November 29th – December 5th) # packit propose-downstream now uploads all remote sources (those specified as URLs) and the source specified by spec_source_id (whether remote or not) to lookaside. Previously, only Source0 was uploaded. Source0 is no longer treated specially, but as spec_source_id is Source0 by default, Source0 is still being uploaded by default unless spec_source_id is overriden. (packit#1778) A VM image build can be triggered inside a PR via a comment command /packit vm-image-build (the job needs to be defined in the configuration).

Next Open NeuroFedora meeting: 5 December 1300 UTC

Posted by The NeuroFedora Blog on December 05, 2022 12:20 PM
Photo by William White on Unsplash

Photo by William White on Unsplash.


Please join us at the next regular Open NeuroFedora team meeting on Monday 05 December 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 2022-12-05'

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

We hope to see you there!

CPE Weekly Update – Week 48 2022

Posted by Fedora Community Blog on December 05, 2022 10:29 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: 28th November to 2nd December 2022

<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
Docs

Update

Fedora Infra

  • Openshift clusters (stg and prod) both upgraded to 4.11.
  • Got a new internal cert for bugzilla2fedmsg (it’s a pain, but documented now)
  • Fixed expired certs on the osbs clusters
  • Upgraded staging builders to f37
  • Openshift 3.11 clusters were finally taken down and removed!
  • Update/reboot cycle in progress. Staging was done Monday, a bunch more today and the rest in an outage on Wednesday afternoon.

CentOS Infra including CentOS CI

Release Engineering

  • Fedora 38 changes reviews
  • pagure-distgit release code release 1.13, rpm package in progress

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.

Updates

  • Finished importing modules for c8s, currently importing RPMs
  • Started cleaning up the CentOS Stream Jira board
  • ELN build failures under 30!

EPEL

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 build system, bugzilla instance, updates manager, mirror manager and more.

Updates

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 to email or IRC.
The initiative’s goal 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 their 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.

Updates

  • Working on caching solutions for FASJSON and Datagrepper
  • Message sent when a rule has been updated
  • Bug fixes now that it’s running in staging

The post CPE Weekly Update – Week 48 2022 appeared first on Fedora Community Blog.

First keyboard build for the year end!

Posted by Jon Chiappetta on December 05, 2022 12:48 AM

This was my first mechanical keyboard build and they have made it a pretty smooth process (took me half a day to lube the stabs). This is the KBD67 ANSI hot-swap and I put in a mixture of everything into it. It has holy panda switches for the alphas, halo true switches for all else, and ducky plus drop keycaps. It has a pretty good typing feeling, feedback, and sound to it – it’s a little lower in pitch compared to the Drop Alt’s open top metal frame (I think the plastic and padding underneath help deepen the sound). It’s a great overall keyboard to have as part of the collection! 🙂

  • <figure></figure>
  • <figure></figure>

Episode 352 – Stylometry removes anonymity

Posted by Josh Bressers on December 05, 2022 12:00 AM

Josh and Kurt talk about a new tool that can do Stylometry analysis of Hacker News authors. The availability of such tools makes anonymity much harder on the Internet, but it’s also not unexpected. The amount of power and tooling available now is incredible. We also discuss some of the future challenges we will see from all this technology.

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

Show Notes

One of the best job perks I ever had…

Posted by Joe Brockmeier on December 04, 2022 11:02 PM
It’s been more than 15 years since I worked for Data393 (which doesn’t actually exist anymore…) but I still miss one of the perks of...

Community maintained images for toolbox (and distrobox)

Posted by Timothée Ravier on December 04, 2022 11:00 PM

In this post I will discuss how we made community maintained container images for common Linux distributions available for use with toolbox (and distrobox) and why we can not call them “official”.

What is toolbox (or toolbx)?

But first, let’s start with a bit of context. On image based Linux distributions (such as Fedora Silverblue, Fedora Kinoite, Fedora CoreOS, etc.), it is not practical to install random packages the way you may be used to do on classic package based Linux distributions. You are expected to run applications in containers, either via Flatpak for graphical applications, or via podman for command line ones.

While you can directly manage your own custom container images and environment configurations, it is not useful to have everyone rediscover what to do thus a new tool has been created to make that easier: toolbox (or toolbx) (containers/toolbox on GitHub).

Toolbox lets you easily create a mutable and persistent environments inside containers that are well integrated with your host system.

Why do we need other images?

Toolbox needs a few things to be available in the container image to be able to provide a good user experience and integration with the host system (see details in the Distro support page).

The current version of toolbox only primarily includes support for a Fedora based environment via the fedora-toolbox container image that includes all the required tools. There is also a RHEL 8 image based on UBI available.

If you wanted to use toolbox with another Linux distribution, you had to make your own custom container image and to make sure to include all the required tools.

Introducing toolbx-images

Together with some other folks from the community, we have setup a community maintained repository so that we can share the maintenance of container images designed to be used with toolbox.

The toolbx-images repository is hosted on GitHub and the container images are hosted in the quay.io/toolbx-images org on Quay.io. The full instructions on how to use them are available in the README. The images are rebuilt and updated weekly (at minimum). Everything is public and open on GitHub: the image builds happen via GitHub Action runs.

We now have images for AlmaLinux, Alpine Linux, Arch Linux, CentOS Stream, Debian, openSUSE, RHEL, Rocky Linux and Ubuntu. It’s also really easy to add more.

See also toolbox#1019 for historical details.

What about distrobox?

Distrobox is another tool very similar to toolbox. One of its advantage is that it can directly use any Linux distribution container image as a base. But in order to do that, it needs to setup the environment in the container the first time it is created.

Distrobox is not included in Fedora Silverblue and Fedora Kinoite by default but you can easily install it either by overlaying the RPM package with rpm-ostree (rpm-ostree install distrobox) or by installing it manually in you home directory via the official instructions.

You should be able to directly use the same container images that we are making for toolbox with distrobox to reduce the setup time for each newly created container created. I’ve started a discussion about that in distrobox#544.

Why are those images not official?

To answer that question, we have to answer another one: What makes a container image official?

According to me, a container image is official if it is provided directly by the Linux distribution it is based on, maintained by developers or users of that Linux distribution and hosted on infrastructure validated by that Linux distribution.

Right now, as far as I know, only Fedora is building, maintaining and distributing a container image purposely made for toolbox so there is only one official image.

If you want to have an official image for toolbox for your Linux distribution, then please reach out to your maintainers or developers and suggest or contribute the necessary work.

Conclusion

In the meantime, feel free to join us and help us provide as many community maintained images as possible.

Revue de presse de Fedora 37

Posted by Charles-Antoine Couret on December 03, 2022 02:08 PM

Cela fait depuis Fedora 19 que je publie sur la liste de diffusion de Fedora-fr une revue de presse de chaque sortie d'une nouvelle version. Récapituler quels sites en parle et comment. Je le fais toujours deux semaines après la publication (pour que tout le monde ait le temps d'en parler). Maintenant, place à Fedora Linux 37 !

Bien entendu je passe sous silence mon blog et le forum de fedora-fr.

Sites web d'actualité

Soit 7 sites.

Les vidéos

Soit 1 vidéo.

Bilan

Le nombre de sites parlant de Fedora Linux 37 est en baisse, de même que les vidéos d'annonce.

La semaine de sa sortie, nous avons eu globalement une augmentation de visites par rapport à la semaine d'avant de cet ordre là :

  • Forums : hausse de 19,5% (environ 704 visites en plus)
  • Documentation : hausse d'environ 16,7% (soit environ 380 visites en plus)
  • Le site Fedora-fr : hausse de 52,6% (soit 119 visites en plus)
  • Borsalinux-fr : hausse de 283% (soit 22 visites en plus)

Si vous avez connaissance d'un autre lien, n'hésitez pas à partager !

Rendez-vous pour Fedora Linux 38.

Thessaloniki Fedora 37 Release Party aftermath

Posted by Efstathios Iosifidis on December 03, 2022 01:22 PM
Fedora Logo
The wait is over. Fedora 37 is available to download from the website. A reason to celebrate.

We, at Open Source UoM, organized a Fedora 37 Release Party. These kind of events are organized around the world after the new version of Fedora is released. It is likely that it was the world’s first post-pandemic in-person Fedora 37 Release Party. There was an online Release Party, that showed us the way.

Being an organizer once again, I felt the joy of organizing an event, meet friends and discuss about my favourite topic. The party was attended by Open Source UoM members and students of the University of Macedonia. Fortunately, every promo material I was sent, arrived on time and I gave it as a present to the party animals.
Fedora swag
Fedora swag
Fedora swag
We allocated little time for this event, about 25 minutes. That’s short but initially I had thought it would be enough. It was worth to mention what’s new in this release compared to the previous ones. Some of the atendees were interested in how to become a Fedora contributor, so I pointed out the first steps.
Presenting Fedora
Due to the economic crisis and the pandemic, we contented ourselves with presenting and demonstrating the installation of Fedora 37. Personally, I used to order an awesome cake with Fedora logo on it.

We ended having decided that we have to host another Fedora event to attract more students from the university.

Friday’s Fedora Facts: 2022-48

Posted by Fedora Community Blog on December 02, 2022 03:26 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)!

Fedora Linux 35 will reach end of life on 2022-12-13.

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.

Announcements

  •  Due to a lack of candidates, the Fedora Council election will be delayed by one week. The Mindshare and FESCo elections will continue as scheduled.

CfPs

<figure class="wp-block-table">
ConferenceLocationDateCfP
SCaLE 20xPasadena, CA, US9–12 Marcloses 2 Dec
Config Management CampGhent, BE6–8 Febcloses 4 Dec
#a11yTO CampToronto, ON, CA21 Jancloses 4 Dec
USENIX Symposium on Operating Systems Design and ImplementationBoston, MA, US10–13 Julcloses 6 Dec
ElixirConf EULisbon, PT20–21 Aprcloses 11 Dec
UX ScotlandEdinburgh, GB7–9 Juncloses 12 Dec
FOSDEM: main trackBrussels, BE4–5 Febcloses 15 Dec
NodeJS One AfricaCape Town, ZA8–9 Marcloses 16 Dec
NodeJS One AfricaJohannesburg, ZA13–14 Sepcloses 16 Dec
FOSDEM: Distributions DevroomBrussels, BE5 Febcloses 31 Dec
CypherConMilwaukee, WI, US30–31 Marcloses 31 Dec
JSHeroesCluj-Napoca, RO18–19 Maycloses 31 Dec
USENIX Annual Technical ConferenceBoston, MA, US10–12 Julcloses 5 Jan
Devoxx UKLondon, UK10–12 Maycloses 10 Jan
Scalar ConferenceWarsaw, PL23–24 Marcloses 10 Jan
Hack in ParisParis, FR26–29 Sepcloses 14 Jan
VueConfNew Orleans, LA, US25–26 Maycloses 15 Jan
PyCon ItaliaFlorence, IT25–28 Maycloses 16 Jan
DevConfCape Town & Pretoria, ZA23 & 25 Maycloses 17 Jan
MagnoliaJSJackson, MS, US17–18 Octcloses 31 Jan
Open Source NorthSt. Paul, MN, US24 Maycloses 18 Feb
JSDay IEDublin, IE26 Sepcloses 28 Feb
</figure>

Help wanted

Meetings & events

Releases

<figure class="wp-block-table">
Releaseopen bugs
F353701
F364605
F371848
Rawhide7005
</figure>

Prioritized Bugs

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

<figure class="wp-block-table">
Bug IDComponentStatus
2015490initial-setupASSIGNED
2134824kernelASSIGNED
2149632gtk3NEW
</figure>

Fedora Linux 37

Schedule

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

  • 2022-12-09 — Election voting begins (FESCo and Mindshare)
  • 2022-12-16 — Election voting begins (Council)

Fedora Linux 38

Changes

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

<figure class="wp-block-table">
ProposalTypeStatus
Add -fno-omit-frame-pointer to default compilation flagsSystem-WideRejected
Ostree Native Container (Phase 2, stable)System-WideFESCo #2883
MobilityPhoshImageSelf-ContainedApproved
Perl: Replace versioned MODULE_COMPAT_ requires by macroSystem-WideFESCo #2898
Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCHSystem-WideApproved
Enable bootupd for Fedora Silverblue & KinoiteSelf-ContainedFESCo #2900
Build Fedora Silverblue & Kinoite using rpm-ostree unified core modeSelf-ContainedFESCo #2901
Prevent from building RPM packages providing python3dist(…) = 0Self-ContainedApproved
Remove initial-setup from KDE Spin & KinoiteSelf-ContainedApproved
Remove Guile Support from GDBSelf-ContainedFESCo #2906
LLVM 16System-WideFESCo #2909
Add Fedora Auto Firstboot Services to desktop variantsSystem-WideFESCo #2908
Golang 1.20System-WideAnnounced
Fedora Sway SpinSelf-ContainedAnnounced
libpinyin 2.8Self-ContainedAnnounced
GNU Make version 4.4System-WideAnnounced
</figure>

Fedora Linux 39

Changes

The table below lists proposed Changes.

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

Contributing

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: 2022-48 appeared first on Fedora Community Blog.

Working with Btrfs – Subvolumes

Posted by Fedora Magazine on December 02, 2022 08:05 AM

This article is part of a series of articles that takes a closer look at Btrfs, the default filesystem for Fedora Workstation and Fedora Silverblue since Fedora Linux 33.

In case you missed it, here’s the previous article from the series: https://fedoramagazine.org/working-with-btrfs-general-concepts/

Introduction

Subvolumes allow for the partitioning of a Btrfs filesystem into separate sub-filesystems. This means that you can mount subvolumes from a Btrfs filesystem as if they were independent filesystems. In addition, you can, for example, define the maximum space a subvolume may take up via qgroups (We’ll talk about this in another article in this series), or use subvolumes to specifically include or exclude files from snapshots (We’ll talk about this, too, in another article in this series). Every default Fedora Workstation and Fedora Silverblue installation since Fedora Linux 33 makes use of subvolumes. In this article we will explore how it works.

Below you will find a lot of examples related to subvolumes. If you want to follow along, you must have access to some Btrfs filesystem and root access. You can verify whether your /home/ directory is Btrfs via the following command:

$ findmnt -no FSTYPE /home
btrfs

This command will output the name of the filesystem of your /home/ directory. If it says btrfs, you’re all set. Let’s create a new directory to perform some experiments in:

$ mkdir ~/btrfs-subvolume-test
$ cd ~/btrfs-subvolume-test

In the text below, you will find lots of command outputs in boxes such as shown above. Please keep in mind while reading/comparing command outputs that the box contents are wrapped at the end of the line. This makes it difficult to recognize long lines that are broken across multiple lines for readability. When in doubt, try to resize your browser window and see how the text behaves!

Creating and playing with subvolumes

We can create a Btrfs subvolume with the following command:

$ sudo btrfs subvolume create first
Create subvolume './first'

When we inspect the current directory we will see that it now has a new folder named first. Note the first character d in the output below:

$ ls -l
total 0
drwxr-xr-x. 1 root root 0 Oct 15 18:09 first

We can handle this like any regular folder: We can rename it, move it, create new files and folders inside, etc. Note that the folder belongs to root, so we must be root to do these things.

If it acts like a folder and looks like a folder, how do we know whether it’s a Btrfs subvolume? We can use the btrfs tools to list all subvolumes:

$ sudo btrfs subvolume list .
ID 256 gen 30 top level 5 path home
ID 257 gen 30 top level 5 path root
ID 258 gen 25 top level 257 path root/var/lib/machines
ID 259 gen 29 top level 256 path hartan/btrfs-subvolume-test/first

If you’re on a recent and unmodified Fedora Linux installation you will likely see the same output as above. We will inspect home and root as well as the meaning of all the numbers later. For now, we see that there is a subvolume at the path we specified. We can limit the output to the subvolumes below our current location:

$ sudo btrfs subvolume list -o .
ID 259 gen 29 top level 256 path home/hartan/btrfs-subvolume-test/first

Let’s rename the subvolume:

$ sudo mv first second
$ sudo btrfs subvolume list -o .
ID 259 gen 29 top level 256 path home/hartan/btrfs-subvolume-test/second

We can also nest subvolumes:

$ sudo btrfs subvolume create second/third
Create subvolume 'second/third'
$ sudo btrfs subvolume list .
ID 256 gen 34 top level 5 path home
ID 257 gen 37 top level 5 path root
ID 258 gen 25 top level 257 path root/var/lib/machines
ID 259 gen 37 top level 256 path hartan/btrfs-subvolume-test/second
ID 260 gen 37 top level 259 path hartan/btrfs-subvolume-test/second/third

And we can also remove subvolumes, either like we remove folders:

$ sudo rm -r second/third

or via special Btrfs commands:

$ sudo btrfs subvolume delete second
Delete subvolume (no-commit): '/home/hartan/btrfs-subvolume-test/second'

Handling Btrfs subvolumes like separate filesystems

The introduction mentioned that Btrfs subvolumes act like separate filesystems. This means that we can mount subvolumes and pass some mount options to them. First we will create a small folder structure to get a better understanding of what happens:

$ mkdir -p a a/1 a/1/b
$ sudo btrfs subvolume create a/2
Create subvolume 'a/2'
$ sudo touch a/1/c a/1/b/d a/2/e

Here’s what the structure looks like:

$ tree
.
└── a
    ├── 1
    │   ├── b
    │   │   └── d
    │   └── c
    └── 2
        └── e

4 directories, 3 files

Verify that there is now a new Btrfs subvolume:

$ sudo btrfs subvolume list -o .
ID 261 gen 41 top level 256 path home/hartan/btrfs-subvolume-test/a/2

To mount the subvolume we must know the path of the block device where the Btrfs filesystem subvolume resides. The following command tells us:

$ findmnt -vno SOURCE /home/
/dev/vda3

Now we can mount the subvolume. Make sure you replace the arguments with the values for your PC:

$ sudo mount -o subvol=home/hartan/btrfs-subvolume-test/a/2 /dev/vda3 a/1/b

Observe that we use the -o flag to give additional options to the mount program. In this case we tell it to mount the subvolume with name home/hartan/btrfs-subvolume-test/a/2 from the btrfs filesystem on device /dev/vda3. This is a Btrfs-specific option and isn’t available in other filesystems.

We see that the directory structure has changed:

$ tree
.
└── a
    ├── 1
    │   ├── b
    │   │   └── e
    │   └── c
    └── 2
        └── e

4 directories, 3 files

Note that the file e exists twice now and d is gone. We are now able to access the same Btrfs subvolume by two different paths. All changes we perform in either of the paths are immediately reflected in all other locations:

$ sudo touch a/1/b/x
$ ls -lA a/2
total 0
-rw-r--r--. 1 root root 0 Oct 15 18:14 e
-rw-r--r--. 1 root root 0 Oct 15 18:16 x

Let’s play some more with the mount options. For example we can mount the subvolume as read-only under a/1/b like this (Insert arguments for your PC!):

$ sudo umount a/1/b
$ sudo mount -o subvol=home/hartan/btrfs-subvolume-test/a/2,ro /dev/vda3 a/1/b

We use the same command as above, except that we add ro at the end. Now we can no longer create files via this mount:

$ sudo touch a/1/b/y
touch: cannot touch 'a/1/b/y': Read-only file system

but accessing the subvolume directly still works like before:

$ sudo touch a/2/y
$ tree
.
└── a
    ├── 1
    │   ├── b
    │   │   ├── e
    │   │   ├── x
    │   │   └── y
    │   └── c
    └── 2
        ├── e
        ├── x
        └── y

4 directories, 7 files

Don’t forget to clean up before we move on:

$ sudo rm -rf a
rm: cannot remove 'a/1/b/e': Read-only file system
rm: cannot remove 'a/1/b/x': Read-only file system
rm: cannot remove 'a/1/b/y': Read-only file system

Oh no, what happened? Well, since we mounted the subvolume read-only above, we cannot delete it. A deletion from a filesystems’ perspective is a write operation: To delete a/1/b/e, we remove the directory entry for e from the directory contents of its parent directory, a/1/b in this case. In other words, we must write to a/1/b to tell it that e doesn’t exist any longer. So first we unmount the subvolume again, and then we remove the folder:

$ sudo umount a/1/b
$ sudo rm -rf a
$ tree
.

0 directories, 0 files

Subvolume IDs

Remember the first output of the subvolume list subcommand? That contained a lot of numbers, so let’s see what that is all about. I copied the output here to take another look:

ID 256 gen 30 top level 5 path home
ID 257 gen 30 top level 5 path root
ID 258 gen 25 top level 257 path root/var/lib/machines
ID 259 gen 29 top level 256 path hartan/btrfs-subvolume-test/first

We see there are three columns of numbers, each prefixed with a few letters to describe what they do. The first column of numbers is a subvolumes ID. Subvolume IDs are unique in a Btrfs filesystem and as such uniquely identify subvolumes. This means that the subvolume named home can also be referred to by its ID 256. In the mount command above we wrote:

$ sudo mount -o subvol=hartan/...

Another perfectly legal option is to use subvolume IDs:

$ sudo mount -o subvolid=...

Subvolume IDs start at 256 and increase by 1 for every created subvolume. There is however one exception to this: The filesystem root always has the subvolume name / and the subvolume ID 5. That is right, even the root of a Btrfs filesystem is technically a subvolume. This is just implicitly known, hence it doesn’t show up in the output of btrfs subvolume list. If you mount a Btrfs filesystem without the subvol or subvolid argument, the root subvolume with subvolid=5 is assumed as default. Below we’ll see an example of when one may want to explicitly mount the filesystem root.

The second column of numbers is the generation counter and incremented on every Btrfs transaction. This is mostly an internal counter and won’t be discussed further here.

Finally, the third column of numbers is the subvolume ID of the subvolumes parent. In the output above we see that both subvolume home and root have 5 as their parent subvolume ID. Remember that ID 5 has a special meaning: It is the filesystem root. So we know that home and root are children to the root subvolume. hartan/btrfs-subvolume-test/first on the other hand is a child of the subvolume with ID 256, which in our case is home.

In the next section we have a look at where the subvolumes root and home come from.

Inspecting default subvolumes in Fedora Linux

When you create a new Btrfs filesystem from scratch, there will be no subvolumes in it (Except of course for the root subvolume). So where do the home and root subvolumes in Fedora Linux come from?

These are created by the installer at install time. Traditional installations would often include a separate filesystem partition for the / and /home directories. During boot, these are then appropriately mounted to assemble one full filesystem. But there is an issue with this approach: Unless you use technologies such as lvm, it is very hard to change a partitions size at some point in the future. As a consequence you may end up in a situation where either your / or /home runs out of space, while the respective other partition has lots of unused, free space left.

Since Btrfs subvolumes are all part of the same filesystem, they will share the space that the underlying filesystem offers. Remember when we created the subvolumes above? We never told Btrfs how big they are: A subvolume can take up all the space the filesystem has, by default nothing keeps it from doing so. However, we could dynamically impose size limits via Btrfs qgroups, which can also be modified during runtime (And we’ll see how in a later article in this series).

Another advantage of separating / and /home is that we can take snapshots separately. A subvolume is a boundary for snapshots, and snapshots will never contain the contents of other subvolumes below the subvolume that the snapshot is taken of. More details on snapshots follow in the next article in this series.

Enough of the theory! Let’s see what this is all about. First ensure that your root filesystem is in fact of type Btrfs:

$ findmnt -no FSTYPE /
btrfs

And then get the partition it resides on:

$ findmnt -vno SOURCE /
/dev/vda3

Remember we can mount the filesystem root by its special subvolume ID 5 (Adapt the filesystem partition!):

$ mkdir fedora-rootsubvol
$ sudo mount -o subvolid=5 /dev/vda3 ./fedora-rootsubvol
$ ls fedora-rootsubvol/
home  root

And there are the subvolumes of our Fedora Linux installation! But how does Fedora Linux know that the subvolume root belongs to /, and home belongs to /home?

The file /etc/fstab contains so-called static information about the filesystem. In simple terms, during booting your system reads this file, line by line, and mounts all the filesystems listed there. On my system, the file looks like this:

$ cat /etc/fstab
# [ ... ]
# /etc/fstab
# Created by anaconda on Sat Oct 15 12:01:57 2022
# [ ... ]
#
UUID=5e4e42bb-4f2f-4f0e-895f-d1a46ea47807 /                       btrfs   subvol=root,compress=zstd:1 0 0
UUID=e3a798a8-b8f2-40ca-9da7-5e292a6412aa /boot                   ext4    defaults        1 2
UUID=5e4e42bb-4f2f-4f0e-895f-d1a46ea47807 /home                   btrfs   subvol=home,compress=zstd:1 0 0

(Note that the “UUID” lines above have been wrapped into two lines)

The UUID at the beginning of each line is simply a means to identify disks and filesystem partitions in your system (roughly equivalent to /dev/vda3 as I used above). The second column is the path in the filesystem tree where this filesystem should be mounted. The third column is the filesystem type. We see that the entries for / and /home are of type btrfs, just what we expect! Finally, in the fourth column we see the magic: These are the mount options, and there it says to mount / with the option subvol=root. That is exactly the subvolume we saw in the output of btrfs subvolume list / all the time!

With this information, we can reconstruct the call to mount that creates this filesystem entry:

$ sudo mount -o subvol=root,compress=zstd:1 UUID=5e4e42bb-4f2f-4f0e-895f-d1a46ea47807 /
(again, the line above has been wrapped into two)

And that is how Fedora Linux uses Btrfs subvolumes! If you’re curious as to why Fedora Linux decided to use Btrfs as the default filesystem, refer to the change proposal linked below [1].

More on Btrfs subvolumes

The Btrfs wiki has additional information on subvolumes and most importantly on the mount options that can be applied to Btrfs subvolumes. Some options, like compress can only be applied on a filesystem-wide level and thus affect all subvolumes of a Btrfs filesystem. You can find the entry linked below [2].

If you find it confusing to tell which directories are plain directories and which are subvolumes, you can feel free to adopt a special naming convention for your subvolumes. For example, you could prefix your subvolume names with an “@” to make them easily distinguishable.

Now that you know that subvolumes behave like filesystems, one may ask how best to place a subvolume in a certain location. Say you want a Btrfs subvolume under ~/games, where your home directory (~) is itself a subvolume, how can you achieve that? Given the example above, you may use a command like sudo btrfs subvolume create ~/games. This way, you create so-called nested subvolumes: Inside your subvolume ~, there is now a subvolume games. That is a perfectly fine way to approach this situation.

Another valid solution is to do what Fedora does by default: Create all subvolumes under the root subvolume (i.e. such that their parent subvolume ID is 5), and mount them into the appropriate locations. The Btrfs wiki has an overview of these approaches along with a short discussion about their respective implications on filesystem management [5].

Conclusion

In this article we discovered Btrfs subvolumes, which act like separate Btrfs filesystems inside a Btrfs filesystem. We learned how to create, mount and delete subvolumes. Finally, we explored how Fedora Linux makes use of subvolumes – without us noticing at all.

The next articles in this series will deal with:

  • Snapshots – Going back in time
  • Compression – Transparently saving storage space
  • Qgroups – Limiting your filesystem size
  • RAID – Replace your mdadm configuration

If there are other topics related to Btrfs that you want to know more about, have a look at the Btrfs Wiki [3] and Docs [4]. Don’t forget to check out the first article of this series, if you haven’t already! If you feel that there is something missing from this article series, let us know in the comments below. See you in the next article!

Sources

[1]: https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Benefit_to_Fedora
[2]: https://btrfs.readthedocs.io/en/latest/Subvolumes.html
[3]: https://btrfs.wiki.kernel.org/index.php/Main_Page
[4]: https://btrfs.readthedocs.io/en/latest/Introduction.html
[5]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout

Creating a modifiable gzipped disk image

Posted by Richard W.M. Jones on December 01, 2022 05:04 PM

Dusty Mabe set me a challenge yesterday. He wants to create several compressed disk images that have slightly different content, but are otherwise mostly the same. The disk images are large and compressing them takes a long time (30 minutes each, apparently), so ideally what we’d want to do is compress the disk image just the once and then do the updates on the gzipped image.

Modifying a file which has already been compressed is not usually possible.

However if we make some relatively uncontroversial assumptions and accept a few limitations then we can create a compressed disk image which is modifiable in this way, certainly for gzip and xz (I need to investigate zstd).

Firstly let’s assume we’re using some kind of block-based compression with fixed size blocks. This is true for gzip and xz already. Secondly let’s assume that we want to only modify a single, small partition of the image (Dusty only wants to modify the /boot partition). Lastly we’ll assume that the partition boundaries are aligned to the compression blocks. Since partitions can be placed under control of whoever creates the disk image this last one is pretty easy to arrange.

The trick is to use uncompressed blocks for the part of the input covering the partition you want to modify, and compress the rest of the file normally. Both gzip and xz have an uncompressed block type. (In fact, just about any reasonable compression algorithm works like this – if the input data doesn’t become smaller after trying to compress it, the algorithm will emit the data uncompressed since that takes less space.)

Normal tools won’t let you create files like this, but I wrote one for gzip here, and I’m confident that one could be written for xz (exercise for readers! … or me if we decide to productise this).

I created a normal Fedora 36 image using virt-builder and used guestfish to find the partition boundaries:

$ guestfish --ro -a /var/tmp/fedora-36.img -i part-list /dev/sda
[0] = {
  part_num: 1
  part_start: 1048576
  part_end: 2097151
  part_size: 1048576
}
[1] = {
  part_num: 2
  part_start: 2097152
  part_end: 1075838975
  part_size: 1073741824
}
[2] = {
  part_num: 3
  part_start: 1075838976
  part_end: 6441402367
  part_size: 5365563392
}

We will compress partition #3 while leaving partitions #1 and #2 uncompressed so they can be modified in place later. The tool is a bit crude, but:

$ ./partial-deflate /var/tmp/fedora-36.img /var/tmp/fedora-36.img.gz 0 1075838976 6441402368 

The output is a regular gzip file (albeit rather large because the first 1GB is uncompressed – if I was doing this for real I’d make that boot partition smaller):

$ ll /var/tmp/fedora-36.img*
-rw-r--r--. 1 rjones rjones 6442450944 Nov 30 17:03 /var/tmp/fedora-36.img
-rw-r--r--. 1 rjones rjones 1698849910 Dec  1 16:23 /var/tmp/fedora-36.img.gz
$ zcat /var/tmp/fedora-36.img.gz | md5sum 
57cbd5ebcbe59613378c8aee7ad9e40d  -
$ md5sum /var/tmp/fedora-36.img
57cbd5ebcbe59613378c8aee7ad9e40d  /var/tmp/fedora-36.img

Then I went ahead and modified some known content inside the gzip file (but not compressed). I used a hex editor for this, but you could play around with guestfish + nbdkit-offset-filter for something more supportable:

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

And the result is a gzipped file with the modifications:

$ zcat /var/tmp/fedora-36.img.gz > /var/tmp/fedora-36.img-modified
gzip: /var/tmp/fedora-36.img.gz: invalid compressed data--crc error
$ guestfish --ro -a /var/tmp/fedora-36.img-modified -i cat /boot/mydata.txt 
helloworld------

…and a CRC error. That’s to be expected, as I haven’t yet worked out how to update CRC-32 after making changes, but it should be easy to solve (with brute force if necessary).

Hello Percona!

Posted by Joe Brockmeier on December 01, 2022 02:51 PM
Happy to share that I started a new job this week as Head of Community at Percona! I know it’s traditional to talk about how...

Cockpit 281

Posted by Cockpit Project on December 01, 2022 12:00 AM

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

Here are the release notes from Cockpit 281 and cockpit-machines 279:

Add style switcher

Override your system’s style with Cockpit’s new style switcher. It’s great for the times when you might want a dark Cockpit but your system is in light mode. Or vice versa.

Additionally, some browsers have issues picking up on the correct system dark mode setting, so this lets you manually set the mode you prefer.

You can find the style switcher in the session menu.

Screenshot from 2022-12-01 18-14-22

Machines: Autodetect disk image type in custom path

Cockpit Machines now detects the format of disks added using “custom path”. Raw and qcow formatted disk images are supported. However, qcow2 images with a backing file are currently not supported.

Try it out

Cockpit 281 and cockpit-machines 279 are available now:

Making unphishable 2FA phishable

Posted by Matthew Garrett on November 30, 2022 09:53 PM
One of the huge benefits of WebAuthn is that it makes traditional phishing attacks impossible. An attacker sends you a link to a site that looks legitimate but isn't, and you type in your credentials. With SMS or TOTP-based 2FA, you type in your second factor as well, and the attacker now has both your credentials and a legitimate (if time-limited) second factor token to log in with. WebAuthn prevents this by verifying that the site it's sending the secret to is the one that issued it in the first place - visit an attacker-controlled site and said attacker may get your username and password, but they won't be able to obtain a valid WebAuthn response.

But what if there was a mechanism for an attacker to direct a user to a legitimate login page, resulting in a happy WebAuthn flow, and obtain valid credentials for that user anyway? This seems like the lead-in to someone saying "The Aristocrats", but unfortunately it's (a) real, (b) RFC-defined, and (c) implemented in a whole bunch of places that handle sensitive credentials. The villain of this piece is RFC 8628, and while it exists for good reasons it can be used in a whole bunch of ways that have unfortunate security consequences.

What is the RFC 8628-defined Device Authorization Grant, and why does it exist? Imagine a device that you don't want to type a password into - either it has no input devices at all (eg, some IoT thing) or it's awkward to type a complicated password (eg, a TV with an on-screen keyboard). You want that device to be able to access resources on behalf of a user, so you want to ensure that that user authenticates the device. RFC 8628 describes an approach where the device requests the credentials, and then presents a code to the user (either on screen or over Bluetooth or something), and starts polling an endpoint for a result. The user visits a URL and types in that code (or is given a URL that has the code pre-populated) and is then guided through a standard auth process. The key distinction is that if the user authenticates correctly, the issued credentials are passed back to the device rather than the user - on successful auth, the endpoint the device is polling will return an oauth token.

But what happens if it's not a device that requests the credentials, but an attacker? What if said attacker obfuscates the URL in some way and tricks a user into clicking it? The user will be presented with their legitimate ID provider login screen, and if they're using a WebAuthn token for second factor it'll work correctly (because it's genuinely talking to the real ID provider!). The user will then typically be prompted to approve the request, but in every example I've seen the language used here is very generic and doesn't describe what's going on or ask the user. AWS simply says "An application or device requested authorization using your AWS sign-in" and has a big "Allow" button, giving the user no indication at all that hitting "Allow" may give a third party their credentials.

This isn't novel! Christoph Tafani-Dereeper has an excellent writeup on this topic from last year, which builds on Nestori Syynimaa's earlier work. But whenever I've talked about this, people seem surprised at the consequences. WebAuthn is supposed to protect against phishing attacks, but this approach subverts that protection by presenting the user with a legitimate login page and then handing their credentials to someone else.

RFC 8628 actually recognises this vector and presents a set of mitigations. Unfortunately nobody actually seems to implement these, and most of the mitigations are based around the idea that this flow will only be used for physical devices. Sadly, AWS uses this for initial authentication for the aws-cli tool, so there's no device in that scenario. Another mitigation is that there's a relatively short window where the code is valid, and so sending a link via email is likely to result in it expiring before the user clicks it. An attacker could avoid this by directing the user to a domain under their control that triggers the flow and then redirects the user to the login page, ensuring that the code is only generated after the user has clicked the link.

Can this be avoided? The best way to do so is to ensure that you don't support this token issuance flow anywhere, or if you do then ensure that any tokens issued that way are extremely narrowly scoped. Unfortunately if you're an AWS user, that's probably not viable - this flow is required for the cli tool to perform SSO login, and users are going to end up with broadly scoped tokens as a result. The logs are also not terribly useful.

The infuriating thing is that this isn't necessary for CLI tooling. The reason this approach is taken is that you need a way to get the token to a local process even if the user is doing authentication in a browser. This can be avoided by having the process listen on localhost, and then have the login flow redirect to localhost (including the token) on successful completion. In this scenario the attacker can't get access to the token without having access to the user's machine, and if they have that they probably have access to the token anyway.

There's no real moral here other than "Security is hard". Sorry.

comment count unavailable comments

Update/reboots of servers

Posted by Fedora Infrastructure Status on November 30, 2022 09:00 PM

We will be upgrading and rebooting various servers. Services may be down during the outage window.

Servers were updated and rebooted. A few issues, but everything should be back up and running now. Thanks for your patience!

A cardinal sin of content marketing: Writing what you want the audience to have read

Posted by Joe Brockmeier on November 30, 2022 01:25 PM
No matter who your audience1 may be – admins, developers, decision makers, or anyone else – they’re not obligated to read your content. It’s all...

Syslog-ng 101, part 1: Introduction

Posted by Peter Czanik on November 30, 2022 11:40 AM

Welcome to the first part of my syslog-ng tutorial series. In this part, I give you a quick introduction what to expect from this series and try to define what syslog-ng is.

I plan to release parts of my tutorial around every week. Of course, the Christmas holidays and the upcoming conference season may cause some delays. Each part will be released as a blog accompanied by a video. It is up to you, which version you follow. However, even if you go with the video, it is worth visiting the blog: you will be able to copy and paste configuration samples from there.

You can watch the video on YouTube:

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

Or you can read the rest of my blog at: https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-101-part-1-introduction

<figure><figcaption>

syslog-ng logo

</figcaption> </figure>

Reboot copr backend machine

Posted by Fedora Infrastructure Status on November 30, 2022 08:00 AM

We'll just reboot copr-backend into a more powerful machine type.

This outage impacts the copr-backend.

20 blogging and article prompts for tech bloggers

Posted by Joe Brockmeier on November 29, 2022 12:58 PM
Stumped for ideas what to blog about? Not sure what people would want to read that would be worth writing about? Here’s 20 prompts to...

PHP 7.4 is retired

Posted by Remi Collet on November 29, 2022 10:38 AM

One year after PHP 7.3, and as announced, PHP version 7.4.33 was the last official release of PHP 7.4

To keep a secure installation, the upgrade to a maintained version is strongly recommended:

  • PHP 8.0 has security only support and will be maintained until November 2023.
  • PHP 8.1 has active support and will be maintained until November 2023 (2024 for security).
  • PHP 8.2 planed for Dec 6th will have active support and will be maintained until December 2024 (2025 for security).

Read :

However, given the very important number of downloads by the users of my repository the version is still available in remi repository for Enterprise Linux (RHEL, CentOS, Alma, Rocky...) and Fedora and will include the latest security fixes.

Warning : this is a best effort action, depending on my spare time, without any warranty, only to give users more time to migrate. This can only be temporary, and upgrade must be the priority.

You can also watch the sources repository on github.

Write yourself into obsolescence.

Posted by Justin W. Flory on November 29, 2022 08:00 AM

The post Write yourself into obsolescence. appeared first on /home/jwf/.

/home/jwf/ - Free & Open Source, technology, travel, and life reflections

The hands of a person is visible on top of a pad of paper. One hand is pointing to a diagram on the top pad of paper. The other hand holds a thick black marker and is adding a new section to the diagram on the piece of paper. A subtitle appears on the side: "Write yourself into obsolescence."

This thought was pressed into my mind as I looked over all that I had created. Facing the inevitable end of one life chapter as it transitions into a new one, I recognized one possible way to improve our individual impact through documentation. Software and product documentation are classified as technical writing. While they differ in scope, they share a connection to other forms of written works like novels and newspapers; they are collections of a commonly understood, codified language meant to convey a meaning to other humans. The goal of writing yourself into obsolescence is not to create content for content’s sake. The goal is to create information pathways that leave behind a guiding light for those who come after us. The goal is to create some form of media or content that communicates information of value to someone else (even including your future self).

May I continue to hone this practice into an art. 🙏🏻 This is my meditation for the day!

Firewall Redirect Connection State Hook Mod for NGINX Stream Proxy Server

Posted by Jon Chiappetta on November 29, 2022 04:14 AM

So nginx has a stream proxy module that you can use for transparent SSL/TLS relaying/forwarding, however, it is only capable of reading the SNI hostname upon the initial handshake of the connection. In addition, the destination IP address is replaced because of the firewall redirect pointing to the proxy server. I wrote a small modification that can be compiled into nginx which allows you to run a script that can pull the missing destination IP address from a given state connection table in a firewall, for example pfctl or iptables.

Source: https://github.com/stoops/nginx

Reproduction Test:

echo 'test' | nc 8.8.4.4 443

Error Log:

[error]: no host in upstream ":443", client: 192.168.X.Y, server: 0.0.0.0:3129, …

Hook Mod:

<figure class="aligncenter size-large is-resized"></figure>

 

This code mod above will allow you to run a shell script of your choosing if nginx cannot get the hostname or address of a connection requesting to be proxied. You can then look up the destination IP address based on source IP + port combo from the connection state mapping table of the firewall. The result is a much more stable proxying experience for HTTPS connections without needing to wait for the SNI or hostname of the initial handshake!

~

100 day blogging challenge: Let’s get those RSS feeds going again

Posted by Joe Brockmeier on November 28, 2022 04:08 PM
My Mastodon network is picking up nicely. It’s not quite reached the same level or variety of activity from Twitter, but it’s getting there. I...

Upgrade of Copr servers

Posted by Fedora Infrastructure Status on November 28, 2022 01:30 PM

We're updating copr packages to the new versions which will bring new features and bugfixes. We are also upgrading our servers to F37.

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

Episode 351 – Is security or usability a law of the universe?

Posted by Josh Bressers on November 28, 2022 12:00 AM

Josh and Kurt talk about end to end encrypted messages. This has been a popular topic lately due to the Mastodon popularity. Mastodon has a uniquely insecure messaging system, but they aren’t the only one. The eternal debate of can security and usability exist together? We suspect it can’t be, but it’s a very complicated topic.

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

Show Notes

Use SSH to proxy web traffic

Posted by Fabio Alessandro Locati on November 28, 2022 12:00 AM
As discusse in a previous post, I use nebula to create a VPN connection between the various machines I use. Usually what I really care about this setup is the ability of consuming services those machine expose on my nebula network. When I travel, I prefer to proxy my data through my nebula network. This allows me to not have to care about the limitations imposed in those networks, as long as I’m able to open my tunnel.

20 and still Scrobblin’ – Last.fm at 20

Posted by Joe Brockmeier on November 27, 2022 09:37 PM
The first song I ever “scrobbled” was, apparently, “Outdoor Miner” by Wire. That was 2006, several years after Last.fm made its debut. This year the...

PHP version 8.0.26 and 8.1.13

Posted by Remi Collet on November 27, 2022 08:58 AM

RPMs of PHP version 8.1.13 are available in remi-modular repository for Fedora ≥ 35 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...) and in remi-php81 repository for EL 7.

RPMs of PHP version 8.0.26 are available in remi-modular repository for Fedora ≥ 35 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...) and in remi-php80 repository for EL 7.

emblem-notice-24.png The modules for EL-9 are available for x86_64 and aarch64.

emblem-notice-24.pngNo security fix this month, so no update for version 7.4.33.

emblem-important-2-24.pngPHP version 7.3 have reached its end of life and is no longer maintained by the PHP project.

These versions are also available as Software Collections in the remi-safe repository.

Version announcements:

emblem-notice-24.pngInstallation: use the Configuration Wizard and choose your version and installation mode.

Replacement of default PHP by version 8.1 installation (simplest):

dnf module reset php
dnf module enable php:remi-8.1
dnf update php\*

or, the old EL-7 way:

yum-config-manager --enable remi-php81
yum update php\*

Parallel installation of version 8.1 as Software Collection

yum install php81

Replacement of default PHP by version 8.0 installation (simplest):

dnf module reset php
dnf module enable php:remi-8.0
dnf update php\*

or, the old EL-7 way:

yum-config-manager --enable remi-php80
yum update

Parallel installation of version 8.0 as Software Collection

yum install php80

Replacement of default PHP by version 7.4 installation (simplest):

dnf module reset php
dnf module enable php:remi-7.4
dnf update php\*

or, the old EL-7 way:

yum-config-manager --enable remi-php74
yum update

Parallel installation of version 7.4 as Software Collection

yum install php74

And soon in the official updates:

emblem-important-2-24.pngTo be noticed :

  • EL-9 RPMs are build using RHEL-9.0
  • EL-8 RPMs are build using RHEL-8.6
  • EL-7 RPMs are build using RHEL-7.9
  • intl extension now uses libicu71 (version 71.1)
  • mbstring extension (EL builds) now uses oniguruma5php (version 6.9.8, instead of the outdated system library)
  • oci8 extension now uses Oracle Client version 21.7
  • a lot of extensions are also available, see the PHP extensions RPM status (from PECL and other sources) page

emblem-notice-24.pngInformation:

Base packages (php)

Software Collections (php74 / php80 / php81)

Sam’s holiday sweater

Posted by Joe Brockmeier on November 26, 2022 02:39 PM
Update: Sam actually likes his sweater. Or, at least, it chills him out. He’s an anxious cat and gets really anxious when we have a...

Release 7.0.0

Posted by Bodhi on November 26, 2022 02:36 PM

Released on 2022-11-26.
This is a major release that fully enables frozen release state in bodhi-server and adds Kerberos authentication to bodhi-client.

Server upgrade instructions

This release contains database migrations. To apply them, run

$ sudo -u apache /usr/bin/alembic -c /etc/bodhi/alembic.ini upgrade head

Features

  • Bodhi client now autenticates using Kerberos by default and falls back to browser-based OIDC mechanism. (#4602).
  • Critical path information can now be read from JSON files (in the form output by the releng critpath.py script), using config options critpath.type = json and critpath.jsonpath (#4755).
  • Frozen releases updates will now be forced into testing before being pushed to stable #4831).
  • The new update form UI will now display a warning when a release is approaching EOL (#4834).
  • Bodhi-push now defaults to push only testing composes for frozen releases (#4478).

Bug fixes

  • Editing a stuck Rawhide side-tag update (usually when gating tests fail) will no more cause builds to be tagged with the release candidate-tag to prevent the automatic update consumer from creating an automatic update and breaking the side-tag update (#4745).
  • Bodhi client will not show the secret in terminal when logging in via browser (#4814).
  • The check_signed_builds sometimes failed to unstuck updates due to the use of a wrong tag (#4819).
  • Updateinfo.xml metadata generation has been changed in order to try to fix errors reported by yum on EPEL (#2487).
  • Releases in frozen state will now be listed in the release page and a warning box will be showed for updates of those releases (#4103).
  • The date_approved property of the Update model is now set when the update is ready to be pushed to stable (#4171).
  • Scenario is now included in request data when waiving test results (#4270).
  • The update page now shows a single combined gating status, instead of listing the result of each separate greenwave query (#4320).
  • Bodhi-client now raises a generic SysExit exception instead of click.exceptions.Abort when a user aborts authentication, so external scripts can avoid importing Click in their code (#4623).

Development improvements

  • Bodhi client now supports configuring OIDC storage path. (#4603).
  • For gating, Bodhi now queries all Greenwave 'decision contexts' together, reducing the number of queries needed. (#4821).
  • References to never used side_tag_active and side_tag_expired update statuses and the Update.side_tag_locked property have been removed (#4823).
  • The date_pushed database column of the Update model has been dropped and replaced by a property, no change should be noticeable to users (#4837).

Contributors

The following developers contributed to this release of Bodhi:

  • Aurélien Bompard
  • Adam Williamson
  • Maxwell G
  • Mattia Verga
  • Matej Focko
  • Tomas Tomecek

CPE Weekly Update – Week 47 2022

Posted by Fedora Community Blog on November 26, 2022 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 with both infographics and text versions 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 at the text version.

Week: 21st to 25th November 2022

<figure class="wp-block-image size-large"></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 (a subset of this team) investigates possible initiatives that CPE might take.
Planning board
Docs

Update

Fedora Infra

CentOS Infra including CentOS CI

Release Engineering

  • Catch up debt in repos, fedora-comps, pungi …
  • F38 changes reviews
  • Rewrite of SOP in progress
  • Business as usual

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.

Updates

  • Sync of Stream 8 modules into the new infra done.
  • Now syncing the other RPM packages. We want to do a test compose in the new system next week.

EPEL

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 a build system, Bugzilla instance, updates manager, mirror manager and more.

Updates

  • EPEL 9 is up to 11,526 (+174) packages from 4,404 (+49) source packages
  • We now have a retirement policy for EPEL packages
  • Proposal for a new workflow and branching structure for EPEL 10
  • Carl attended Supercomputing 22 conference last week and had good conversations about EPEL, CentOS, and RHEL.  Already sponsored a new packager as a result.

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.

More information on the project can be found here.

Updates

The post CPE Weekly Update – Week 47 2022 appeared first on Fedora Community Blog.

Poking a mobile hotspot

Posted by Matthew Garrett on November 26, 2022 07:09 AM
I've been playing with an Orbic Speed, a relatively outdated device that only speaks LTE Cat 4, but the towers I can see from here are, uh, not well provisioned so throughput really isn't a concern (and refurbs are $18, so). As usual I'm pretty terrible at just buying devices and using them for their intended purpose, and in this case it has the irritating behaviour that if there's a power cut and the battery runs out it doesn't boot again when power returns, so here's what I've learned so far.

First, it's clearly running Linux (nmap indicates that, as do the headers from the built-in webserver). The login page for the web interface has some text reading "Open Source Notice" that highlights when you move the mouse over it, but that's it - there's code to make the text light up, but it's not actually a link. There's no exposed license notices at all, although there is a copy on the filesystem that doesn't seem to be reachable from anywhere. The notice tells you to email them to receive source code, but doesn't actually provide an email address.

Still! Let's see what else we can figure out. There's no open ports other than the web server, but there is an update utility that includes some interesting components. First, there's a copy of adb, the Android Debug Bridge. That doesn't mean the device is running Android, it's common for embedded devices from various vendors to use a bunch of Android infrastructure (including the bootloader) while having a non-Android userland on top. But this is still slightly surprising, because the device isn't exposing an adb interface over USB. There's also drivers for various Qualcomm endpoints that are, again, not exposed. Running the utility under Windows while the modem is connected results in the modem rebooting and Windows talking about new hardware being detected, and watching the device manager shows a bunch of COM ports being detected and bound by Qualcomm drivers. So, what's it doing?

Sticking the utility into Ghidra and looking for strings that correspond to the output that the tool conveniently leaves in the logs subdirectory shows that after finding a device it calls vendor_device_send_cmd(). This is implemented in a copy of libusb-win32 that, again, has no offer for source code. But it's also easy to drop that into Ghidra and discover thatn vendor_device_send_cmd() is just a wrapper for usb_control_msg(dev,0xc0,0xa0,0,0,NULL,0,1000);. Sending that from Linux results in the device rebooting and suddenly exposing some more USB endpoints, including a functional adb interface. Although, annoyingly, the rndis interface that enables USB tethering via the modem is now missing.

Unfortunately the adb user is unprivileged, but most files on the system are world-readable. data/logs/atfwd.log is especially interesting. This modem has an application processor built into the modem chipset itself, and while the modem implements the Hayes Command Set there's also a mechanism for userland to register that certain AT commands should be pushed up to userland. These are handled by the atfwd_daemon that runs as root, and conveniently logs everything it's up to. This includes having logged all the communications executed when the update tool was run earlier, so let's dig into that.

The system sends a bunch of AT+SYSCMD= commands, each of which is in the form of echo (stuff) >>/usrdata/sec/chipid. Once that's all done, it sends AT+CHIPID, receives a response of CHIPID:PASS, and then AT+SER=3,1, at which point the modem reboots back into the normal mode - adb is gone, but rndis is back. But the logs also reveal that between the CHIPID request and the response is a security check that involves RSA. The logs on the client side show that the text being written to the chipid file is a single block of base64 encoded data. Decoding it just gives apparently random binary. Heading back to Ghidra shows that atfwd_daemon is reading the chipid file and then decrypting it with an RSA key. The key is obtained by calling a series of functions, each of which returns a long base64-encoded string. Decoding each of these gives 1028 bytes of high entropy data, which is then passed to another function that decrypts it using AES CBC using a key of 000102030405060708090a0b0c0d0e0f and an initialization vector of all 0s. This is somewhat weird, since there's 1028 bytes of data and 128 bit AES works on blocks of 16 bytes. The behaviour of OpenSSL is apparently to just pad the data out to a multiple of 16 bytes, but that implies that we're going to end up with a block of garbage at the end. It turns out not to matter - despite the fact that we decrypt 1028 bytes of input only the first 200 bytes mean anything, with the rest just being garbage. Concatenating all of that together gives us a PKCS#8 private key blob in PEM format. Which means we have not only the private key, but also the public key.

So, what's in the encrypted data, and where did it come from in the first place? It turns out to be a JSON blob that contains the IMEI and the serial number of the modem. This is information that can be read from the modem in the first place, so it's not secret. The modem decrypts it, compares the values in the blob to its own values, and if they match sets a flag indicating that validation has succeeeded. But what encrypted it in the first place? It turns out that the json blob is just POSTed to http://pro.w.ifelman.com/api/encrypt and an encrypted blob returned. Of course, the fact that it's being encrypted on the server with the public key and sent to the modem that decrypted with the private key means that having access to the modem gives us the public key as well, which means we can just encrypt our own blobs.

What does that buy us? Digging through the code shows the only case that it seems to matter is when parsing the AT+SER command. The first argument to this is the serial mode to transition to, and the second is whether this should be a temporary transition or a permanent one. Once parsed, these arguments are passed to /sbin/usb/compositions/switch_usb which just writes the mode out to /usrdata/mode.cfg (if permanent) or /usrdata/mode_tmp.cfg (if temporary). On boot, /data/usb/boot_hsusb_composition reads the number from this file and chooses which USB profile to apply. This requires no special permissions, except if the number is 3 - if so, the RSA verification has to be performed first. This is somewhat strange, since mode 9 gives the same rndis functionality as mode 3, but also still leaves the debug and diagnostic interfaces enabled.

So what's the point of all of this? I'm honestly not sure! It doesn't seem like any sort of effective enforcement mechanism (even ignoring the fact that you can just create your own blobs, if you change the IMEI on the device somehow, you can just POST the new values to the server and get back a new blob), so the best I've been able to come up with is to ensure that there's some mapping between IMEI and serial number before the device can be transitioned into production mode during manufacturing.

But, uh, we can just ignore all of this anyway. Remember that AT+SYSCMD= stuff that was writing the data to /usrdata/sec/chipid in the first place? Anything that's passed to AT+SYSCMD is just executed as root. Which means we can just write a new value (including 3) to /usrdata/mode.cfg in the first place, without needing to jump through any of these hoops. Which also means we can just adb push a shell onto there and then use the AT interface to make it suid root, which avoids needing to figure out how to exploit any of the bugs that are just sitting there given it's running a 3.18.48 kernel.

Anyway, I've now got a modem that's got working USB tethering and also exposes a working adb interface, and I've got root on it. Which let me dump the bootloader and discover that it implements fastboot and has an oem off-mode-charge command which solves the problem I wanted to solve of having the device boot when it gets power again. Unfortunately I still need to get into fastboot mode. I haven't found a way to do it through software (adb reboot bootloader doesn't do anything), but this post suggests it's just a matter of grounding a test pad, at which point I should just be able to run fastboot oem off-mode-charge and it'll be all set. But that's a job for tomorrow.

Edit: Got into fastboot mode and ran fastboot oem off-mode-charge 0 but sadly it doesn't actually do anything, so I guess next is going to involve patching the bootloader binary. Since it's signed with a cert titled "General Use Test Key (for testing only)" it apparently doesn't have secure boot enabled, so this should be easy enough.

comment count unavailable comments

Extremely minimal blogging with WriteFreely

Posted by Joe Brockmeier on November 25, 2022 09:58 PM
Loving the explosion of IndieWeb activity. For fun I decided to try out WriteFreely, a really minimal blog with ActivityPub features. Short summary of WriteFreely...

Friday’s Fedora Facts: 2022-47

Posted by Fedora Community Blog on November 25, 2022 03:13 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)!

Fedora Linux 35 will reach end of life on 2022-12-13.

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.

Announcements

CfPs

<figure class="wp-block-table">
ConferenceLocationDateCfP
SREcon AmericasSanta Clara, CA, US21–23 Marcloses 1 Dec
SCaLE 20xPasadena, CA, US9–12 Marcloses 2 Dec
Config Management CampGhent, BE6–8 Febcloses 4 Dec
#a11yTO CampToronto, ON, CA21 Jancloses 4 Dec
USENIX Symposium on Operating Systems Design and ImplementationBoston, MA, US10–13 Julcloses 6 Dec
ElixirConf EULisbon, PT20–21 Aprcloses 11 Dec
FOSDEM: main trackBrussels, BE4–5 Febcloses 15 Dec
NodeJS One AfricaCape Town, ZA8–9 Marcloses 16 Dec
NodeJS One AfricaJohannesburg, ZA13–14 Sepcloses 16 Dec
FOSDEM: Distributions DevroomBrussels, BE5 Febcloses 31 Dec
CypherConMilwaukee, WI, US30–31 Marcloses 31 Dec
JSHeroesCluj-Napoca, RO18–19 Maycloses 31 Dec
USENIX Annual Technical ConferenceBoston, MA, US10–12 Julcloses 5 Jan
Devoxx UKLondon, UK10–12 Maycloses 10 Jan
Hack in ParisParis, FR26–29 Sepcloses 14 Jan
DevConfCape Town & Pretoria, ZA23 & 25 Maycloses 17 Jan
MagnoliaJSJackson, MS, US17–18 Octcloses 31 Jan
JSDay IEDublin, IE26 Sepcloses 28 Feb
</figure>

Help wanted

Meetings & events

Releases

<figure class="wp-block-table">
Releaseopen bugs
F353972
F364567
F371602
Rawhide6914
</figure>

Prioritized Bugs

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

<figure class="wp-block-table">
Bug IDComponentStatus
2015490initial-setupASSIGNED
</figure>

Fedora Linux 37

Schedule

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

  • 2022-11-16 — Election nominations open
  • 2022-11-30 — Election nominations close
  • 2022-12-09 — Electoin voting begins

Fedora Linux 38

Changes

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

<figure class="wp-block-table">
ProposalTypeStatus
Add -fno-omit-frame-pointer to default compilation flagsSystem-WideFESCo #2817
Ostree Native Container (Phase 2, stable)System-WideFESCo #2883
MobilityPhoshImageSelf-ContainedFESCo #2896
Perl: Replace versioned MODULE_COMPAT_ requires by macroSystem-WideFESCo #2898
Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCHSystem-WideFESCo #2899
Enable bootupd for Fedora Silverblue & KinoiteSelf-ContainedFESCo #2900
Build Fedora Silverblue & Kinoite using rpm-ostree unified core modeSelf-ContainedFESCo #2901
Prevent from building RPM packages providing python3dist(…) = 0Self-ContainedFESCo #2903
Remove initial-setup from KDE Spin & KinoiteSelf-ContainedFESCo #2904
Remove Guile Support from GDBSelf-ContainedAnnounced
LLVM 16System-WideAnnounced
Add Fedora Auto Firstboot Services to desktop variantsSystem-WideAnnounced
</figure>

Fedora Linux 39

Changes

The table below lists proposed Changes.

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

Contributing

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: 2022-47 appeared first on Fedora Community Blog.

[python] Generate ranges from items

Posted by Pablo Iranzo Gómez on November 25, 2022 07:00 AM
Some years ago, I added a script for updating headers for (C) in the python files I was developing for Risu. In this way, the header got the list of authors and years working on the files updated automatically. With the pass of the years, the list started to became a bit too long, so I worked on creating code for getting ranges instead. This is the code I used:

macOS Dark Mode

Posted by Caolán McNamara on November 24, 2022 03:39 PM


For LibreOffice 7.5 I've reworked the theming on macOS to get some support for Dark Mode, as seen above. As a side effect "accent colors" work in Light Mode too.

Link-o-Rama: Stable Diffusion 2.0, Tragic birth of FM radio, story of goth

Posted by Joe Brockmeier on November 24, 2022 03:10 PM
Before I’m in a turkey and carbs coma, thought I’d throw a few links into the void. Stable Diffusion 2.0 is out! Things in the...

Introducing the Community Design Team (Part 1)

Posted by Fedora Community Blog on November 24, 2022 08:00 AM

This is the first part of a two-part blog post series introducing the Community Design Team (CDT) to the Fedora Community. In this post, we’ll introduce you to all of the wonderful team members and the projects they’ve been working on. In Part 2, we’ll explain how you can reach our team, make a request, and work with us!

Many of you have already been collaborating with CDT members for months now on various upstream community projects such as the Fedora Websites Revamp, the new Fedora Brand Book, the Fedora 37 artwork, and Podman’s new Podman Desktop tool. Since we formed the team, we’ve set up regular meetings, chosen our initial project set, and created a space on Fedora’s GitLab to organize our work. Now that we’ve settled in a bit and better understand how we collaborate best, we’d like to formally introduce ourselves to you as a team!

What is the Community Design Team (CDT)?

<figure class="wp-block-media-text__media">CDT logo depicting the letters "CDT" creating a bridge over water</figure>

The Community Design Team (CDT) is dedicated to providing design services to upstream open source projects and communities. Many members of our team are also members of the Community Platform Engineering (CPE) Team. We help upstream open source projects create beautiful, usable software.

What is the difference between the Community Design Team and the Fedora Design Team?

The Community Design Team (CDT) and the Fedora Design Team are closely interlaced and have a strong connection. While the Fedora Design Team focuses on Fedora and Fedora-related projects as a public, community-based team, the Community Design Team not only supports the Fedora community but also works on non-Fedora related projects.

To avoid confusion amongst the Fedora community members, we separated these tasks. Nevertheless, the CDT will also support (and continue to do so!) Fedora Design projects. These Fedora projects allow for passioante volunteers to share their experience, help, and grow within an inclusive open source community based on their available time and contribution.

If you want to know more – we will talk about this more in-depth in part 2 of this blog post.

Design Services

What do we mean by “design services?” Let us give you some examples from areas we have made contributions in over the past few months.

Branding assets for  upstream projects

Our intern Jess Chitas created a full suite of logos and a mascot for Fedora events: Flock, Nest, Hatch, and Colúr the Fedora events mascot, as well as swag designs for these. Jess also created the new Fedora Brand Book. Another example: Mo created upstream project logos for projects in the Containers organization – Podman, Buildah, Skopeo, and the Containers org symbol.

<figure class="is-layout-flex wp-block-gallery-1 wp-block-gallery has-nested-images columns-default is-cropped"> <figure class="wp-block-image size-large">Containers logos: Podman, Podman Desktop, Buildah, Skopeo, crun<figcaption class="wp-element-caption">The Fedora events logos, designed by Jess Chitas</figcaption></figure> <figure class="wp-block-image size-large"><figcaption class="wp-element-caption">Colúr, the Fedora events mascot, designed by Jess Chitas</figcaption></figure> <figure class="wp-block-image size-large"><figcaption class="wp-element-caption">The Containers org project logos designed by Máirín Duffy (except for Podman Desktop, designed by Steven LeMeur)</figcaption></figure> </figure>

User experience (UX) design and UX research services to upstream projects

Intern Gbenga Oti and Máirín (Mo) Duffy are currently in the analysis phase of a qualitative research project for Podman and Podman Desktop. They are learning about how various people in the community use containers and how to improve the tools to provide a better user experience. Gbenga is also putting together a usability test plan to test out new designs she created to revamp some of the preferences panes in Podman Desktop.

<figure class="is-layout-flex wp-block-gallery-3 wp-block-gallery has-nested-images columns-default is-cropped"> <figure class="wp-block-image size-large"><figcaption class="wp-element-caption">WIP mockup of a dashboard concept for Podman Desktop by Máirín Duffy</figcaption></figure> <figure class="wp-block-image size-large"><figcaption class="wp-element-caption">WIP mockup by Gbenga Oti rethinking how Podman VM resources could be presented in Podman Desktop.</figcaption></figure> <figure class="wp-block-image size-large"><figcaption class="wp-element-caption">Screenshot of work-in-progress user research analysis by Gbenga Oti and Máirín Duffy</figcaption></figure> </figure>

Upstream website designs

Emma Kidney (Fedora IoT, Fedora CoreOS, Fedora Cloud) and Ashlyn Knox (Flock + the new Fedora website CMS and new Fedora website front end development) engaged in user research and created design mockups for various Fedora Website Revamp sections. Emma worked with Fedora edition teams to pull together requirements for their respective websites and followed through with mockups. Ashlyn ran a series of usability tests on the new Fedora website CMS she created and updated the design, making it much easier to use, based on her findings.

<figure class="is-layout-flex wp-block-gallery-5 wp-block-gallery has-nested-images columns-default is-cropped"> <figure class="wp-block-image size-large"><figcaption class="wp-element-caption">Screenshot of the test deployment of the Fedora website CMS created by Ashlyn Knox</figcaption></figure> <figure class="wp-block-image size-large"><figcaption class="wp-element-caption">Screenshot from the new Flock redesign mockup designed by Ashlyn Knox</figcaption></figure> <figure class="wp-block-image size-large"><figcaption class="wp-element-caption">Screenshot from the Fedora IoT mockup designed by Emma Kidney</figcaption></figure> </figure>

Promoting a design culture in upstream communities

Madeline Peck led an open, collaborative design process for the Fedora 37 artwork set. She hosted open brainstorming sessions, provided public updates, hosted testing sessions, and invited community participation every step of the way. Madeline is also mentoring a designer for the Fedora Design Team as part of the Outreachy program. This demonstrates how to build a consistent, usable icon set for Fedora’s Matrix channels the open source way.

<figure class="is-layout-flex wp-block-gallery-7 wp-block-gallery has-nested-images columns-default is-cropped"> <figure class="wp-block-image size-large"><figcaption class="wp-element-caption">Mood board for the Fedora 37 wallpaper design</figcaption></figure> <figure class="wp-block-image size-large"><figcaption class="wp-element-caption">By Madeline Peck</figcaption></figure> <figure class="wp-block-image size-large"><figcaption class="wp-element-caption">By Madeline Peck</figcaption></figure> </figure>

Upstream Open Source Projects and Communities

We provide these services (and many more) to open source projects and communities. Which open source projects and communities do we work with?

Fedora and CentOS communities

As does the CPE team, the CDT works with the Fedora and CentOS communities on projects of importance to them. This includes working with various teams under the Fedora and CentOS communities, including the Fedora Mindshare team and the teams under it, as well as individual edition / spin / initiative teams.

Containers / Podman / Podman Desktop communities

The projects these communities produce are tools that are a critical part of Fedora’s conceptual model – we want these tools to succeed to help Fedora succeed. We also believe the inclusive, cross-compatible approach to container technology these tools take means they will be of great benefit to the broader open source community beyond Fedora.

Other strategic open source projects

For example, Mo has been part of a multi-year embedded UX engagement with the ChRIS project. ChRIS is an open source, open science project that uses container technology such as kubernetes to enable medical image processing in the cloud. This project is of strategic importance for many reasons, not the least of which is that it is an applied example of the technologies our team supports. This lets us better understand how it is used in the field and how we can improve it.

In our next blog we can let you know how your community could be considered for future work by the CDT.

Why does the CDT exist? What are its goals?

There are a number of reasons we felt it was important to coordinate a team of designers working on upstream projects connected to CPE:

Better user experience for upstream projects

The open source model of software development often results in downstream projects inheriting decisions that create a less-than-optimal user experience. Downstream projects either create workarounds for these issues, or reinvent (sometimes in a forked, proprietary way) the user experience components to improve it. We believe it is better for designers to be involved at the start, upstream, before it is too late to reverse decisions that may negatively impact the user experience for years to come. User experience is critical to software freedom.

One-stop shopping for upstreams and partners

Instead of hunting across different teams or asking individual contacts for design favors, there is one queue that community members can file a ticket in in order to get help from our group. For the designers, this also means that, as life happens, they have peers that can step in and assist. This helps team members be able to step away for PTO, emergencies, and other extended absences. We also hope this will reduce duplication of effor due to multiple designers working on the same thing without coordination.

Help upstream projects become more friendly & inviting to design contributions

Open source culture is still centers on code contributions by default. We aim to help the upstream projects we work with shift this culture to be more inclusive of non-code contributions, including design contributions. By being visible upstream design contributors, we can set an example. By shifting the way projects track design-related issues and tasks, we can open the door to welcome additional community design contributions.

Introducing the current CDT members!

Jess Chitas created these trading cards for the current members of the CDT community. Here is our current team roster:

  • <figure>Trading card for Máirín Duffy - Sr. Principal Interaction Designer - IRC mizmo - Since 2004 - Likes playing with my daughters, fruit smoothies, road trips, Gaeilge - Dislikes proprietary software, politicians - Preferred Title Ní Dhufaigh</figure>
  • <figure>Trading card for Madeilne Peck - Associate Interactive Designer - IRC mpeck - since 2020 - Likes boba, tacos, lily of the valley, Animal Crossing - Dislikes shrimp, wet socks, green tea, cold cloudy days - Preferred Title Miss</figure>
  • <figure>Trading card for Jess Chitas - UX Intern - IRC jesschitas - since 2022 - Likes Pokemon, FPS games, Graphic Design, Music - Dislikes clowns, the dark, not top-fragging in CS:GO - Preferred Title Silver Elite</figure>
  • <figure>Trading card for Emma Kidney - Associate Software Engineer - IRC ekidney - since 2021 - Likes crochet, coffee, the Office US, tarot cards - Dislikes spiders, fish, raisins, sticky fingers - Preferred Title The Crocheting Cat Lady</figure>
  • <figure>Trading card for Ashlyn Knox - Web Developer - Since 2020 - IRC lilyx - Likes longboarding, blending tea, coding, spatial design, and penguins! - Dislikes Theremin - Preferred Title: 'Cyber Witch'</figure>
  • <figure>Trading Card for Gbenga Oti - UX/UI Intern - Since 2022 - IRC @gbengaoti - Likes Music, Baking, Crocheting, Design - Dislikes Rainy Days - Preferred Title: "The Langauge Connoisseur"</figure>
  • <figure>Trading card for Ellen O'Carroll - Technical Project Manager - Since 2021 - IRC @eocarrol - Likes dogs, the beach, music, good food - Dislikes loud noises, bugs, and bad food - Preferred Title: "Dog Mom"</figure>

Reaching out to the CDT and working with us

In part two, we’ll talk about how you can best reach our team: where we hang out, how you can make a request and generally how to work with us. See you next month!

The post Introducing the Community Design Team (Part 1) appeared first on Fedora Community Blog.

Finalizing rpm-ostree support in Discover

Posted by Timothée Ravier on November 22, 2022 11:00 PM

Initial support for rpm-ostree was added in Discover as part of a Season of KDE 2021 project that was completed by Mariam Fahmy.

Unfortunately, we hit some hard to diagnose issues related to DBus interactions with rpm-ostree so the work was left in limbo for a while and kept disabled in Fedora Kinoite.

I recently picked it up again and implemented a workaround as I could not figure out the root cause of the original issue.

I am pleased to announce that we now have good support for rpm-ostree in Discover! 🎉

This will be available with the Plasma 5.27 release. It will be pushed to Fedora Kinoite 37 once the update is ready and will be available by default in Fedora Kinoite 38.

In the meantime, here are some screenshots of how this will look like!

First, here is the default view in Discover. Notice that we now have an Operating System category.

Default view in Discover

All versions of the system are listed there.

Operating System category

Selecting a deployment will get you more details. You can see that this version is pinned. This means that it will not be automatically cleaned-up by rpm-ostree. Support for pinning and un-pinning versions has not been implemented yet but the status is shown in the interface if you do it via the command line.

Entry detail

If you go into the Update section you will see the available updates.

Available updates

You can “mostly” follow the update progress. I say “mostly” here as we are not fully able to represent the entire progress in Discover yet (due to the DBus interface issues mentioned at the beginning) so the progress is not completely accurate as we do not show download progress.

Update in progress

Once the update is installed, you will be suggested to reboot. rpm-ostree updates are transactional, safe and atomic: they do not change your currently running system and are installed alongside it. Using a system with a pending update is thus perfectly safe. The new version will be used after a reboot.

Ready for reboot

If you look at the Operating System category before you reboot, you will see the new installed version waiting here. You do not need to reboot right away and can wait for a good time for you. If a new version is released, Discover will offer the new version as an update again and you will directly update from the current version to the latest one.

Operating System category before reboot

Once you have rebooted, you can see the new version as active and the previous version as fallback.

Operating System category after reboot

Now let’s see what happens when a new major version of Fedora Kinoite is released. If you have pending or available updates for the current version, then Discover will ask you to update your system first.

New major release with pending update

Same thing in the update view with pending updates.

New major release with pending update (update view)

If you are all up to date, then you can rebase to the next major version.

Rebase to next major version available

Same thing in the update view.

Rebase to next major version available (update view)

Conclusion

I will soon write an updated blog post about how I do KDE development on Fedora Kinoite but in the meantime you can follow the instructions from the Development on Fedora Silverblue and Fedora Kinoite post to build Discover from source.

Please report any issue you may find in the KDE bug tracker with the Discover product and the rpm-ostree Backend component.

I will also soon start a discussion with KDE’s Visual Design Group (VDG) to work on improving the user experience in Discover for this backend.

How I got started with Vim

Posted by Joe Brockmeier on November 22, 2022 06:32 PM
Yesterday I made an offhand comment about the long story of how I got started with Vim, so I figured I’d follow up today with...