Fedora People

Episode 367 – Open source will never be the same

Posted by Josh Bressers on March 20, 2023 12:00 AM

Josh and Kurt talk about GitHub enforcing sanctions against an open source developer and Docker changing how their registry works. There’s a lot to unpack in this one. There’s a lot of happenings going on in the world of open source. We are seeing governments paying attention to open source like never before, change is coming and everything is going to change.

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

Show Notes

Untitled Post

Posted by Zach Oglesby on March 19, 2023 02:46 AM

I have an iPad that I use as my computer away from home, but it’s not really what I want. I have looked for a good device small that can run Emacs on the good a few times. I installed Linux on a Surface Go 2 but it was not great. I am really hoping that the MNT Pocket Reform fills my needs.

On recharge

Posted by Michel Alexandre Salim on March 19, 2023 12:00 AM
It’s been over 6 years since I started working at Meta (then known as Facebook). Not going to comment here about all the controversies surrounding our products, but as an employee, I have been lucky enough to work on interesting teams that, yes, don’t do anything that give me cause to be sleepless at night. One perk we have (that is no big deal to friends in Europe, but is a big deal in the US) is being able to take 30 calendar days of recharge leave (think of it as a short sabbatical) after each 5 years of employment (together with the 21 work days of PTO a year, this roughly brings us in line with what Europeans get courtesy of employment laws.

Turning an iPad into a Network Bandwidth Monitor Graph + Weather Station

Posted by Jon Chiappetta on March 18, 2023 09:55 PM

I wanted a quick and easy way to visualize and summarize the WAN traffic going through my home network so I wrote what started out as a basic Python script that acts as a simple server/javascript client to query my OpenWRT router for that information. It then uses chart.js to graph and plot the data being returned along with placing little display cards that show me the wind speed, wind direction, cloud graphic, time stamp, and weather summary for the next 5 hours 🙂

I didn’t post the source code for this one as it was more of a highly specialized project that I thought applies for my particular use case and requirements.

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

Cloudflare Graphs – A Big Spike In Traffic – One Time

Posted by Jon Chiappetta on March 18, 2023 09:12 PM

So one evening recently I got an email alert for a big spike in traffic going to this blog. I don’t know why it happened and I don’t see my post view counts getting that high either so it was a strange event. Thankfully Cloudflare’s service was able to handle the total requests being made as I don’t have much visibility on the WordPress side of things. My blog setup here is a bit simplified unfortunately!

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

7.1.1

Posted by Bodhi on March 18, 2023 09:36 AM

Released on 2023-03-18.
This is a minor feature release.

Features

  • The automated tests tab will now display information about queued and running tests (#5139).
  • Copy additional config files for pungi (#5154).

Contributors

The following developers contributed to this release of Bodhi:

  • Adam Williamson
  • Michal Konečný

Friday’s Fedora Facts: 2023-11

Posted by Fedora Community Blog on March 17, 2023 08:09 PM

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

I have weekly office hours most Wednesdays in the morning and afternoon (US/Eastern time). 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
DevOpsDays ChicagoChicago, IL, US9–10 Augcloses 17 Mar
FOSSY call for tracksPortland, OR, US13–16 Julcloses 19 Mar
AkademyThessaloniki, GR15–16 Julycloses 30 Mar
Container DaysHamburg, DE11–13 Sepcloses 31 Mar
All Things OpenRaleigh, NC, US15–17 Octcloses 31 Mar
The Perl and Raku ConferenceToronto, ON, CA11–13 Julcloses 31 Mar
DevConf USBoston, MA, US16–18 Augcloses 3 Apr
Upstreamvirtual7 Juncloses 7 Apr
openSUSE Conference 2023Nürnberg, DE26–28 Maycloses 9 Apr
TechBashMount Pocono, PA, US7–10 Novcloses 11 Apr
Web Weekend KathmanduKathmandu, NP23–24 Sepcloses 21 Apr
DevRelCon LondonLondon, UK7–8 Sepcloses 21 Apr
Cincy DeliverCincinnati, OH, US28 Julcloses 30 Apr
ShipIt ConDublin, IE1 Sepcloses 1 May
React NorwayLarvik, NO16 Juncloses 15 May
Front ConferenceZurich, CH31 Aug–1 Sepcloses 31 May
Inclusive Design 24virtual21 Sepcloses 4 Jun
</figure>

Help wanted

Meetings & events

Releases

<figure class="wp-block-table">
Releaseopen bugs
F364507
F373744
F38 (pre-release)1100
Rawhide7018
</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-setupON_QA
</figure>

Fedora Linux 38

Blockers

<figure class="wp-block-table">
BugComponentStatusBlocker status
2171350fcoe-utilsNEWAccepted (Final)
2177992gnome-calendarVERIFIEDAccepted (Final)
2177995gnome-mapsVERIFIEDAccepted (Final)
2177853gnome-shellPOSTAccepted (Final)
2173891gtk4VERIFIEDAccepted (Final)
2176782kernelNEWAccepted (Final)
2175809mutterVERIFIEDAccepted (Final)
2177982mutterVERIFIEDAccepted (Final)
2176766nautilusVERIFIEDAccepted (Final)
2172956opensshPOSTAccepted (Final)
2174563sddmNEWAccepted (Final)
2113005shimNEWAccepted (Final)
2178172f38-backgroundsVERIFIEDProposed (Final)
2177153gnome-abrtNEWProposed (Final)
2177993gnome-calendarNEWProposed (Final)
2156108ibusMODIFIEDProposed (Final)
2178167mutterPOSTProposed (Final)
2178971xdg-desktop-portal-kdeNEWProposed (Final)
</figure>

Schedule

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

  • 2023-04-04Final freeze begins
  • 2023-04-18 — Final release early target date

Changes

The table below lists Changes status. See the ChangeSet page or Bugzilla for more information.

<figure class="wp-block-table">
StatusCount
ASSIGNED3
MODIFIED1
ON_QA45
CLOSED2
</figure>

Fedora Linux 39

Changes

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

<figure class="wp-block-table">
ProposalTypeStatus
FontAwesome6Self-ContainedFESCo #2968
SPDX License Phase 2System-WideAnnounced
</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: 2023-11 appeared first on Fedora Community Blog.

فدورا لینوکس ۳۸ بتا منتشر شد

Posted by Fedora fans on March 17, 2023 04:04 PM
fedora 38 beta

fedora 38 betaپروژه ی فدورا خبر انتشار نسخه ی Fedora Linux 38 Beta را اعلام کرد و هم اکنون این نسخه در دسترس و قابل استفاده می باشد. انتشار نسخه ی نهایی فدورا لینوکس ۳۸ برای آخر ماه April یعنی نیمه اول اردیبهشت ۱۴۰۲ زمانبندی شده است.

نسخه های فدورا مانند همیشه دارای تغییرات و ویژگی های جدیدی می باشند که برخی از مهمترین تغییرات در فدورا ۳۸ بتا به شرح زیر می باشند.

 

Fedora Workstation

نسخه Fedora 38 Workstation Beta شامل میزکار GNOME 44 می باشد که در حال حاضر به صورت بتا می باشد که انتظار می رود که نسخه نهایی آن در آخر ماه March منتشر شود.

میزکار GNOME 44 شامل تغییرات بسیار بزرگی از جمله lock screen جدید، بخش «background apps» در quick menu و بهبود تنظیمات دسترسی (accessibility settings) می باشد.

 

دیگر بروزرسانی ها

تیم پروژه ی فدورا همیشه در تلاش است تا ویژگی های امنیتی جدید را به سرعت به کاربران ارائه دهد. اکنون بسته ها (Packages) با flag های سختگیرانه تر کامپایلر ساخته می شوند که از سرریز بافر (buffer overflows) محافظت می کنند. مدیر بسته rpm از یک OpenPGP parser مبتنی بر Sequoia به جای پیاده سازی خود استفاده می کند.

مانند همیشه بروزرسانی ها شامل زبان های برنامه نویسی و کتابخانه هایی چون Ruby 3.2, gcc 13, LLVM 16, Golang 1.20, PHP 8.2 می باشد.

 

دانلود فدورا لینوکس ۳۸ بتا

دانلود Fedora 38 Workstation Beta 

دانلود Fedora 38 Server Beta

دانلود Fedora 38 IoT Beta

دانلود Fedora 38 Cloud Beta

دانلود Fedora 38 CoreOS Beta

دانلود Fedora Spins 38 Beta

دانلود Fedora Labs 38 Beta

دانلود Fedora Linux 38 Beta for ARM

 

فدورایی و عصبانی باشید!

 

The post فدورا لینوکس ۳۸ بتا منتشر شد first appeared on طرفداران فدورا.

CPE Weekly update – Week 11

Posted by Fedora Community Blog on March 17, 2023 10:00 AM

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

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

Week: 13 March – 17 March 2023

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

Highlights of the week

Infrastructure & Release Engineering

Goal of this Initiative

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

Update

Fedora Infra

  • got silverblue/kinote setup to sync to quay.io
  • 38 Beta torrents/bitflip/release day work
  • Installed 2 new staging virthosts

CentOS Infra including CentOS CI

Release Engineering

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

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 buildsystem, 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 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.

Updates

  • Bug fixes and UI polish, tying up loose ends
  • Started on docs

Community Design

Goal of this initiative

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

Updates

  • CPE members can file issues / requests to the CDT here.
  • Podman: Completed onboarding system (step by step guide).
  • Fedora Website Revamp almost complete – should be deploying soon.
  • Fedora Design TikTok in the works – planning meeting this week
  • F38 wallpaper touch ups for release
  • New time for Fedora Design meeting TBA
  • F37 Release Party videos edits ongoing

The post CPE Weekly update – Week 11 appeared first on Fedora Community Blog.

Test GitHub projects with GitHub Actions and Testing Farm

Posted by Fedora Magazine on March 17, 2023 08:00 AM

Every project on GitHub that’s destined for Red Hat Enterprise Linux (RHEL), Fedora Linux, CentOS 7, CentOS Stream 8, and CentOS Stream 9, should be tested before its changes are synced into a Git distribution repository (dist-git). It’s important to catch problems before delivering software to customers, and help quality assurance teams catch errors. We should implement Shift Left into our workflows process.

Introduction

Testing Farm is an open-source testing system offered as a service. Testing Farm’s idea is similar to Compile Farms, but with a focus on executing automated tests. Its mission is to provide a reliable and scalable service for executing automated tests from various users, such as Fedora CI, Packit, and others. The entry point for our users is an HTTP-based API. Testing Farm scales across many infrastructures, including private and public clouds. Using the composite testing-farm-as-a-github-action, currently available on the GitHub Marketplace, allows you to test your project efficiently.

GitHub Marketplace and advantages of publishing actions here

GitHub Marketplace is a place where developers can find, among other elements, all published GitHub Actions, in one place. Anyone is authorized to publish an action on the GitHub Marketplace.

An action, in order to be published, must reside in its own GitHub repository.

The advantage of publishing an action on the Marketplace, in addition to publishing it in a public GitHub repository, is the visibility of written actions for other users.

Testing Farm as GitHub Action

Testing-farm-as-a-github-action, shortly TFaGA, is a composite GitHub action, intended to be used from other GitHub Actions. 

Its main purpose is scheduling tests on the Testing Farm infrastructure triggered by an event that occurs in a GitHub repository and, optionally, displaying the results of executed tests.

NOTE:  It is important to have the tested code reviewed by an authorized person, like an owner or member, in order to avoid running malicious code on the Testing Farm infrastructure.

Any kind of test which can be described with a TMT plan, can be executed. The testing environment can be chosen from Fedora Linux, CentOS, including CentOS Stream, or RHEL. We need to test our software as soon as possible.

For whom is testing-farm-as-github-action intended

The TFaGA can be used by developers or maintainers, generally, anyone who wants to test a repository located on GitHub. Anyone who would like to add software to the distributions mentioned above should guarantee that it delivers working software. Customers love software that is working and tested.

Action inputs

TFaGA input is highly configurable but there only two inputs that are without default values and are required to be inserted by the user. These are:

  • api_key – API key for Testing Farm
  • git_url – URL to a repository with TMT plans

NOTE: You can obtain api_key from tft@redhat.com. For more information see the onboarding site.

The minimal example of using the TFaGA (on an already checkouted repository) will look similar to this:

- name: Schedule tests Testing Farm
  uses: sclorg/testing-farm-as-github-action@v1
  with:
      api_key: ${{ secrets.TF_API_KEY }}
      git_url: <URL to a TMT plan>

All other input values are optional and have preassigned default values.

The inputs are divided into logical groups:

  • Testing Farm
    • contains options for configuring the testing farm itself. Configurable items can be the API key, URL to TF’s API, and the scope of the used TF – public, or private
  • TMT metadata
    • contains options for configuring the TMT specification, such as URL for the Git repository with the TMT plan, or regex for selecting the plan.
  • Test environment
    • contains options for configuring the operating system and architecture and where the test would be run. Supported Linux distributions are Fedora Linux, and CentOS, including CentOS Stream, RHEL7, and RHEL8.  Moreover, the secrets and environment variables needed for the test execution can be specified with options belonging to this group.
  • Test artifacts
    • contains settings for additional artifacts to install in the test environment. For more information see Rest API documentation.
  • Miscellaneous
    • contains settings for various miscellaneous options, such as, whether the PR should be updated with test results after finishing the job or what should be written in it.

More information about the inputs can be found in the README.md.

Action outputs

TFaGA action provides, as output, a request_id and a request_url of a scheduled testing farm request. Combining request_url and request_id together, the user obtains a URL address pointing to a log artifactory. Test logs and test results are collected here in text form from the Testing Farm. 

Optionally, if the event which triggers the Testing Farm action is related to a Pull Request, the user can enable a Pull Request status update. Enabling this option ensures that test results are summarized in a graphical form directly in the PR. An example of the graphical output is displayed in the picture below.

<figure class="wp-block-image size-full"><figcaption>Status of tests delivered by Testing Farm as GitHub Action</figcaption></figure>

How to use a Testing Farm as GitHub Action in your repository?

As TFaGA is a composite GitHub action, it is supposed to be embedded in other user-specified GitHub actions.

Example of action, triggered by commenting on a PR

The following example demonstrates, how the TFaGA can be used in a GitHub project. The whole example can be found in sclorg repositories.

NOTE: It is important to check the contents of the tested PR so that no malicious code will be run on the Testing Farm infrastructure. For this reason, only members and owners of the repository should be able to run the tests, as shown in the example below.

The test in this specific example would be triggered with a created comment on a PR by a member or owner of a specific repository. The comment has to include the string ‘[test]’.

name: upstream tests at Testing Farm
on:
	issue_comment:
	  types:
Created
jobs:
	build:
	  name: A job run on explicit user request
	  run-ons: ubuntu-20.04

  if: |
    github.event.issue.pull_request
    && contains(github.event.comment.body, '[test]')
    && contains(fromJson('["OWNER", "MEMBER"]'),        github.event.comment.author_association)

Clone and checkout repository to a proper pull request branch:

- name: Checkout repo
  uses: actions/checkout@v2

The following shows scheduled tests on Testing Farm by the GitHub Action. This will pass to a testing-farm-as-a-github-action an api_key, stored in the repository secrets, the URL to a TMT plan, and the environment variables that are required by the triggered tests. The chosen testing OS is CentOS7.

- name: Schedule tests on external Testing Farm
  uses: sclorg/testing-farm-as-github-action@v1
  with:
      api_key: ${{ secrets.TF_API_KEY }}
      git_url: "https://github.com/sclorg/sclorg-testing-farm"
      variables: "REPO_URL=$GITHUB_SERVER_URL/$GITHUB_REPOSITORY;REPO_NAME=$GITHUB_REPOSITORY;PR_NUMBER=${{ github.event.issue.number }};OS=centos7;TEST_NAME=test"
      compose: "CentOS-7"

Test results are, by default, displayed as a status directly within a Pull Request with GitHub statuses API.

Summary

Why use this GitHub action in your project? It will eliminate caring about testing the infrastructure environment, writing a lot of new GitHub Action workflows, and handling Pull Request statuses. 

When using TFaGA, you get the whole testing infrastructure according to your needs simply by providing a TMT test plan and an API key. The pool of available testing environments is composed of many processor architectures and Linux distributions.

Your tests are triggered simply by an action you specify in the configuration file. Logs and results from test execution are collected, reported, and stored in text form and optionally also transparently displayed in the Pull Request status. 

Your action is only to get the ‘api_key’ from the Testing Farm team and write a simple GitHub workflow to use our GitHub Action.

So let’s test project changes as soon as possible before the project goes out to the customers!

PHP version 8.1.17 and 8.2.4

Posted by Remi Collet on March 16, 2023 02:00 PM

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

RPMs of PHP version 8.1.17 are available in remi-modular repository for Fedora ≥ 36 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...) and in remi-php81 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 8.0.28.

emblem-important-2-24.pngPHP version 7.4 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.2 installation (simplest):

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

or, the old EL-7 way:

yum-config-manager --enable remi-php82
yum update

Parallel installation of version 8.2 as Software Collection

yum install php82

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

And soon in the official updates:

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

  • EL-9 RPMs are build using RHEL-9.1
  • EL-8 RPMs are build using RHEL-8.7
  • 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.8
  • 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 (php80 / php81 / php82)

Which APT repository did a package come from?

Posted by Gary Benson on March 16, 2023 01:18 PM
$ apt policy wget
wget:
  Installed: 1.21.2-2ubuntu1
  Candidate: 1.21.2-2ubuntu1
  Version table:
 *** 1.21.2-2ubuntu1 500
        500 http://gb.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
        100 /var/lib/dpkg/status

Register for Linux App Summit 2023!

Posted by Felipe Borges on March 16, 2023 01:09 PM

LAS 2023 is happening next month and registrations are open!

You can  check the schedule in https://conf.linuxappsummit.org/event/5/timetable/#20230422

We are excited to have you visiting us in Brno, Czech Republic. The conference starts on Friday, April 21st, with a pre-registration social event. Saturday and Sunday are full of interesting talks, panels, workshops, and more!

Python debugger

Posted by Gary Benson on March 16, 2023 10:09 AM

By the way, if you’ve never used Python’s debugger, it really is as simple as adding a call to the built-in function breakpoint() at the point you want it to stop.

NetworkManager: Limiting Bond Subordinate devices by MAC Address

Posted by Dusty Mabe on March 16, 2023 12:00 AM
Someone recently asked me about locking down a bond to specific NIC devices within the machine. Specifically they were concerned with the sometimes unpredictable nature of NIC naming in Linux. While there has been a lot of effort to make NIC naming more predictable, it turns out with the networking configuration stack we are using in Fedora/RHEL (NetworkManager) you don’t even really need to care about the NIC device names if you know the MAC Addresses of the interfaces you want to use.

What Is Fedora Linux Good For?

Posted by Scott Williams (vwbusguy) on March 15, 2023 11:13 PM

What Is Fedora Linux Good For?

Fedora won "Most Memorable Booth" at the So Cal Linux Expo 20x.  I've had multiple people ask me why and if we had some kind of gimmick.  To be fair, we did have excellent swag this year and a great crew of people at the booth, but in my opinion, it was our enthusiastic community of users who made it truly exceptional.

Most Memorable Booth award

This year, instead of asking overly generic questions like "Do you use Fedora?" and "Have you tried Kinoite or Silverblue yet?", I decided to ask "What's something fun or interesting you're doing with Fedora these days?" and the answers very much did not disappoint.

Fedora running on a Microsoft Surface Go tablet

Workstation Adventures

When I asked the person above what they were using Fedora for, they pulled out this Surface Go tablet running on Fedora 37!  It honestly looked amazing!

Gaming was another common use reported for Fedora.  The fact that Steam OS, Proton, and Lutris (who was at the event) have all contributed to the Linux gaming ecosystem has all meant very good things for Fedora as a gaming platform. 

At least one user reported that they are running Fedora on a Lenovo laptop that came with Fedora pre-installed!

At Work

Multiple people advised that they use Fedora to teach others Linux, with one of them saying that they used Fedora in the classroom for this purpose.  Another user said that Fedora is running on their microcontrollers at work.

At Home

Fedora IoT and CoreOS really shined here, especially around Home Lab and Home Automation use cases. 

For Home Automatiom, one user reported that they are running a 5-node Spark cluster with Fedora IoT on Raspberry Pis.  Another made their own digital photo frame powered by Fedora.

For Home Lab users, someone reported using Fedora as a router and DHCP server for their home networking.  Another was using Fedora CoreOS for experimental network testing and for running their own Nextcloud instance.  Another is running a k3s cluster on Fedora to run their own FreeIPA with Fedora Server. 

For Development

If you thought I was adventurous for using Fedora to write a BASIC shell for Linux, one user shared that he was using Fedora to write his own DNS server from scratch in Rust!  Another is using Fedora to write Android apps and test them in VMs.  Another is writing BPF programs focused on securing IoT devices.  And, finally, a user said that they used Fedora to package their own software for the Fedora repos and said he really enjoyed the overal experience of getting it packaged in RPM and the review process.

Conclusion

So what is Fedora good for?  It's hard to find something Fedora isn't good for these days!

Fedora at SoCal Linux Expo 20x

Posted by Scott Williams (vwbusguy) on March 15, 2023 10:32 PM

Fedora at SoCal Linux Expo 20x

The So Cal Linux Expo again returned to Pasadena, CA and Fedora came back as an exhibitor!  I have now attended SCaLE every year since 2010, shortly after I moved to Calfornia.  Since the last SCaLE was in late July, there was less time between them.  As a result, I noticed a few things that contributed to this year's SCaLE being an especially special year: Many larger corporate vendors who were at SCaLE last year didn't come back this year, so it felt like there were more hobbyist and community groups to fill in the space.  At the same time, many who had not been travelling due to COVID returned for the first time in years.  It resulted in SCaLE feeling a bit more geniune this year with a crowd of people who largely knew what Linux and open source are about and were excited to be there.

SCaLE banner

On Thursday, I attended a workshop on Kubebuilder.  The DevOps and Kubernetes events during SCaLE offered some great high quality talks, both in terms of content and presentation style.  In between those events, we snuck back to the Exhibit Hall and got everything setup and ready to go ahead of the opening on Friday.
Fedora banners in an exhibition hall

At the Fedora booth, we had a great crew and excellent swag, but the real highlight was getting to connect with users who shared with us what they are currently doing with Fedora.  Instead of scanning people's badges, we offered a simple form for users to connect with us so we can follow up with them about ways they might want to get more involved.

Fedora sign up sheet

We got to visit with enthusiatic new users, who are doing some exciting things with Fedora on their devices...
Fedora running on a Microsoft Surface Go tablet

As well as reconnect with old, familiar friends.
The one and only Jeff Spaleta

And in some cases, meet new old friends (Ken Thompson and John Maddog Hall):
Scott Williams with Ken ThompsonScott Williams with Jon Maddog Hall

The Fedora talk on Saturday by Brian Monroe was very well attended and gave a live demonstration of the Fedora Jam SIG using a MIDI keyboard.  This was then setup in the back of the Fedora booth (with headphones) so musically inclined people could try it out for themselves!
Brian Monroe giving talk on Linux Pro Audio with Fedora

After a very fun game night, we all arrived fresh on Sunday morning to the news that the Fedora booth had been voted "Most Memorable Booth" by conference participants this year!
Most Memorable Booth award for Fedora at SCaLE

It was a very successful year for Fedora at the So Cal Linux Expo, and we couldn't have done it without such an enthusiastic community user base and an excellent group of Fedora Ambassadors including Perry Rivera, Alex Acosta, Ivan Chavero, Brian Monroe (and always a treat to see Jeff Carlson, who again was on staff with SCaLE this year)!
Fedora Ambassadors around a table in the exhibit hall

How to rebase to Fedora Silverblue 38 Beta

Posted by Fedora Community Blog on March 15, 2023 12:47 PM

Silverblue is an operating system for your desktop built on Fedora Linux. It’s excellent for daily use, development, and container-based workflows. It offers numerous advantages such as being able to roll back in case of any problems. Let’s see the steps to upgrade to the newly released Fedora 38 Beta, and how to revert if anything unforeseen happens.

Before attempting an upgrade to the Fedora 38 Beta, apply any pending upgrades.

Updating using terminal

Because the Fedora 38 Beta is not available in GNOME Software, the whole upgrade must be done through a terminal.

First, check if the 38 branch is available, which should be true now:

$ ostree remote refs fedora

You should see the following line in the output:

fedora:fedora/38/x86_64/silverblue

If you want to pin the current deployment (this deployment will stay as option in GRUB until you remove it), you can do it by running:

# 0 is entry position in rpm-ostree status
$ sudo ostree admin pin 0

To remove the pinned deployment use following command (2 corresponds to the entry position in rpm-ostree status):

$ sudo ostree admin pin --unpin 2

Next, rebase your system to the Fedora 38 branch.

$ rpm-ostree rebase fedora:fedora/38/x86_64/silverblue

Finally, the last thing to do is restart your computer and boot to Fedora Silverblue 38 Beta.

How to revert

If anything bad happens — for instance, if you can’t boot to Fedora Silverblue 38 Beta at all — it’s easy to go back. Pick the previous entry in the GRUB boot menu (you need to press ESC during boot sequence to see the GRUB menu in newer versions of Fedora Silverblue), and your system will start in its previous state. To make this change permanent, use the following command:

$ rpm-ostree rollback

That’s it. Now you know how to rebase to Fedora Silverblue 38 Beta and back. So why not do it today?

FAQ

Because there are similar questions in comments for each blog about rebasing to newer version of Silverblue I will try to answer them in this section.

Question: Can I skip versions during rebase of Fedora? For example from Fedora 36 Silverblue to Fedora 38 Silverblue?

Answer: Although it could be sometimes possible to skip versions during rebase, it is not recommended. You should always update to one version above (37->38 for example) to avoid unnecessary errors.

Question: I have rpm-fusion layered and I got errors during rebase. How should I do the rebase?

Answer: If you have rpm-fusion layered on your Silverblue installation, you should do the following before rebase:

rpm-ostree update --uninstall rpmfusion-free-release --uninstall rpmfusion-nonfree-release --install rpmfusion-free-release --install rpmfusion-nonfree-release

After doing this you can follow the guide in this blog post.

The post How to rebase to Fedora Silverblue 38 Beta appeared first on Fedora Community Blog.

HPC and me

Posted by Peter Czanik on March 14, 2023 02:32 PM

Recently I found that quite a few of my Twitter and Mastodon followers are working in high-performance computing (HPC). At first I was surprised because I’m not a HPC person, even if I love high performance computers. Then I realized that there are quite few overlaps, and one of my best friends is also deeply involved in HPC. My work, logging, is also a fundamental part of HPC environments.

Let’s start with a direct connection to HPC: one of my best friends, Gabor Samu, is working in HPC. He is one of the product managers for one of the leading commercial HPC workload managers: IBM Spectrum LSF Suites. I often interact with his posts both on Twitter and Mastodon.

I love high performance computers and non-x86 architectures. Of course, high performance computers aren’t the exclusive domain of HPC today. Just think of web and database servers, CAD and video editing workstations, AI, and so on. But there is definitely an overlap. Some of the fastest HPC systems are built around non-x86 architectures. You can find many of those on the top500 list. ARM and POWER systems made it even into the top10 list, and occupied the #1 position for years.

The European Union is developing its own CPUs for HPC as part of the European Processor Initiative. Their target is a low power consumption but high performance system. They are working on ARM and RISC-V systems.

It’s not just HPC where non-x86 architectures can show significant performance benefits. For many years, IBM’s POWER9 CPU was the fastest to run syslog-ng. Running syslog-ng on X86 was not even half as fast. Currently my fastest measurement was on an AMD system, but I would not be surprised if I could measure higher syslog-ng message rates on POWER10 or Ampere systems (if I had access).

Logging is a fundamental part of HPC environments. With the scale of HPC systems, and the price of down time, logging is required for being able to isolate / identity issues rapidly. These systems run around the clock and are used to solve grand scale challenges for humanity like vaccine development, weather modeling, or analyzing data from the LHC. Logging gives you here better visibility into the system and makes you able to identify problems very quickly.

One of the most active syslog-ng users, Faxm0dem, is running thousands of syslog-ng instances in France, at CC-IN2P3. If you take a look at the powered by syslog-ng page, you will see that they are not the only ones. I learned at various conferences that there are many more HPC labs where syslog-ng is in use, but unfortunately they are not sharing infrastructure details publicly, only in private discussions.

TL;DR: I’m not surprised any more, if I see new HPC focused followers :-)

<figure><figcaption>

Talos II POWER9 mainboard

</figcaption> </figure>

Sortie de Fedora Linux 38 Beta

Posted by Charles-Antoine Couret on March 14, 2023 02:00 PM

En ce mardi 14 mars, la communauté du Projet Fedora sera ravie d'apprendre la disponibilité de la version Beta de Fedora Linux 38.

Malgré les risques concernant la stabilité d’une version Beta, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora Linux 38 et réduisant du même coup le risque de retard. Les versions en développement manquent de testeurs et de retours pour mener à bien leurs buts.

La version finale est pour le moment fixée pour le 18 ou 25 avril.

Expérience utilisateur

  • Passage à GNOME 44 ;
  • La petite souris Xfce est mise à jour après 4.18 tours de roue ;
  • Le gestionnaire de connexions SDDM (utilisé par KDE par exemple) utilise Wayland par défaut ;
  • L'image Fedora Linux avec le bureau Budgie devient une image Spin officielle ;
  • De même pour l'image Fedora Linux avec le gestionnaire de fenêtre Sway ;
  • L'utilitaire initial-setup n'est plus fourni dans l'image KDE et l'image Kinoite ;
  • Flathub n'est plus filtré par défaut lors de l'installation de Fedora Linux, tous les paquets proposés sont donc accessibles ;
  • Le timer systemd pour l'extinction de la machine passe de 2 minutes à 45 secondes, envoyant un signal SIGABRT si jamais des services n'ont pas réussi à s'arrêter dans ce délai ;
  • Les images Live sont modernisées, abandonnant l'usage important de Kickstarts pour les générer afin d'être plus flexible, notamment en créant automatiquement une partition de sauvegarde si de l'espace libre est détecté sur la clé USB par exemple ;
  • cups-filters passe à la version 2.0b ;
  • Dans le domaine de l'impression le paquet ipp-usb devient une dépendance faible de cups ou de sane-airscan pour proposer la prise en charge des imprimantes USB par défaut sans installations supplémentaires de la part de l'utilisateur ;
  • La distribution LaTeX TeXLive version 2022 est proposée, qui est la dernière version avec une prise en charge longue durée ;
  • L'utilitaire ImageMagick tire profit de sa 7e version.

Gestion du matériel

  • L'installateur Anaconda utilise mdadm au lieu de dmraid pour la prise en charge des stockages RAID reposant sur un firmware ou un BIOS ;
  • L'image LXQt est proposée pour l'architecture aarch64 ;
  • Fourniture d'une image avec Phosh, GNOME Shell pour mobile, à destination des téléphones ou des tablettes pour l'architecture x86_64 et aarch64 ;
  • L'architecture s390x utilise les processeurs de la génération z13 comme base, les plus anciens ne seront plus forcément compatibles ;
  • Les implémentations du serveur X (Xorg et Xwayland) refusent à des clients ayant un boutisme différent du serveur de s'y connecter ;
  • Première partie de la migration vers une image noyau unifiée (donc unifiant noyau, initrd, ligne de commande du noyau et signature) pour les plateformes avec UEFI mais rien ne change par défaut à ce sujet pour les utilisateurs ;
  • L'installateur de l'image IoT récupère celui de CoreOS pour simplifier son installation.

Internationalisation

  • La police par défaut pour la langue thaï et le cambodgien passe à Noto ;
  • Tandis que les polices Noto CJK pour les langues chinoises, japonaises et coréennes utilisent la variante variable au lieu de static comme auparavant ;
  • Mise à jour de libpinyin 2.8.

Administration système

  • Les clés du serveur SSH suppriment la lecture par les utilisateurs du groupe ssh_keys (qui est supprimé) pour rétablir le SUID bit de l'utilitaire ssh-keysign ;
  • RPM utilise Sequoia pour traiter le format OpenPGP au lieu de sa propre implémentation interne ;
  • Le paquet systemd-udev fourni par défaut la règle Link.MACAddressPolicy=none au lieu de Link.MACAddressPolicy=persistent ;
  • Le gestionnaire de paquet Microdnf est mis à jour à sa 5e version.

Développement

  • La mise à niveau de la chaine de compilation GNU est à l’œuvre avec GCC 13.0, binutils 2.39, glibc 2.37 et GDB 12.1 ;
  • Retrait de la prise en charge du langage Guile pour étendre GDB pour laisser la place à Python pour cela ;
  • Pendant que LLVM version 16 débarque ;
  • GNU Make prépare sa version 4.4 ;
  • Le langage Go quant à lui passe à la version 1.20 ;
  • Le langage Ruby expose sa version 3.2 en vitrine ;
  • Le langage PHP évolue vers la version 8.2 ;
  • Le gestionnaire de base de données PostgreSQL met à jour à la version 15 ;
  • Pendant que Haskell GHC (le compilateur Haskell) 9.2 avec sa suite Stackage 20 sont disponibles ;
  • L'écosystème Node.js est repackagé pour autoriser des installations multiples et parallèles, abandonnant l'usage des modules qui était la voie privilégiée ;
  • La bibliothèque pcre est marquée comme obsolète au bénéfice de pcre2, sa suppression totale des dépôts (et de ses dépendances) est à prévoir prochainement ;
  • OpenJDK est compilé pour ressembler plus aux implémentations standards de JDK avec les bibliothèques internes au lieu de celles du système et la compilation avec la bibliothèque libstdc++ liée statiquement ;
  • La boîte à outils pour le développement Web en Python nommé Pyramid bénéficie de la version 2.0 ;
  • Mise à jour de python-packaging version la version 22.0 ;
  • Le paquet python3-toml est considéré comme obsolète avant suppression définitive à venir depuis la prise en charge de cette fonctionnalité dans la bibliothèque standard depuis Python 3.11 ;
  • Le paquet du compilateur FreePascal fpc est subdivisé en trois paquets : fpc pour le compilateur lui même, fpc-ide pour l'environnement de développement en ligne de commande et fpc-units-NOMARCHITECTURE-linux pour la bibliothèque standard précompilée ;
  • Le générateur d'interface SWIG se balance vers la version 4.10.

Projet Fedora

  • La génération des images Fedora IoT reposera sur osbuild ;
  • Les paquets sont compilés avec l'option _FORTIFY_SOURCE=3 au lieu de _FORTIFY_SOURCE=2 pour mieux se protéger contre les buffers overflow dans les logiciels fournis ;
  • Les paquets sont également compilés avec les options -fno-omit-frame-pointer et -mno-omit-leaf-frame-pointer par défaut ;
  • Les paquets qui veulent changer leur option de compilation doivent passer par les macros %_pkg_extra_cflags, %_pkg_extra_cxxflags, %_pkg_extra_fflags et %_pkg_extra_ldflags pour plus de lisibilité et de traçabilité ;
  • rpmautospec (qui emploie les macros %autorelease et %autochangelog) est recommandé pour l'ensemble des paquets par défaut ;
  • Activation de la macro %clamp_mtime_to_source_date_epoch à 1 qui configure mtimes en $SOURCE_DATE_EPOCH pour la compilation reproductible des paquets ;
  • La macro pour gérer les dépendances des modules Perl perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) est supprimée au profit de perl-generators ;
  • Les paquets Python fournissant la métadonnée python3dist(...) = 0 échoueront dans leur construction ;
  • Début de l'usage généralisé des noms de licence provenant du projet SPDX pour la licence des paquets plutôt que des noms du projet Fedora, de manière facultative pour l'instant.

Tester

Durant le développement d'une nouvelle version de Fedora Linux, comme cette version Beta, quasiment chaque semaine le projet propose des journées de tests. Le but est de tester pendant une journée une fonctionnalité précise comme le noyau, Fedora Silverblue, la mise à niveau, GNOME, l’internationalisation, etc. L'équipe d'assurance qualité élabore et propose une série de tests en général simples à exécuter. Suffit de les suivre et indiquer si le résultat est celui attendu. Dans le cas contraire, un rapport de bogue devra être ouvert pour permettre l'élaboration d'un correctif.

C'est très simple à suivre et requiert souvent peu de temps (15 minutes à une heure maximum) si vous avez une Beta exploitable sous la main.

Les tests à effectuer et les rapports sont à faire via la page suivante. J'annonce régulièrement sur mon blog quand une journée de tests est planifiée.

Si l'aventure vous intéresse, les images sont disponibles par Torrent ou via le site officiel.

Si vous avez déjà Fedora Linux 37 ou 36 sur votre machine, vous pouvez faire une mise à niveau vers la Beta. Cela consiste en une grosse mise à jour, vos applications et données sont préservées.

Nous vous recommandons dans les deux cas de procéder à une sauvegarde de vos données au préalable.

En cas de bogue, n'oubliez pas de relire la documentation pour signaler les anomalies sur le BugZilla ou de contribuer à la traduction sur Weblate. N'oubliez pas de consulter les bogues déjà connus pour Fedora 38.

Bons tests à tous !

Syslog-ng 101, part 11: Enriching log messages

Posted by Peter Czanik on March 14, 2023 01:20 PM

This is the eleventh part of my syslog-ng tutorial. Last time, we learned about message parsing using syslog-ng. Today, we learn about enriching log messages.

You can watch the video on YouTube:

<iframe allowfullscreen="allowfullscreen" src="https://www.youtube.com/embed/tFHyvLgiSyI" style="position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;" title="YouTube Video"></iframe>
and the complete playlist at https://www.youtube.com/playlist?list=PLoBNbOHNb0i5Pags2JY6-6wH2noLaSiTb

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

<figure><figcaption>

syslog-ng logo

</figcaption> </figure>

New badge: Called to Action !

Posted by Fedora Badges on March 14, 2023 12:35 AM
Called to ActionYou are a proud member of the Marketing Team - spreading the word of Fedora throughout the world.

و آتشی که نمیرد همیشه در دل ماست

Posted by Fedora fans on March 13, 2023 10:29 PM
charshanbe-sori

charshanbe-sori
رمز آتش پاکی و روشنگری

سرخی و گرما و شادی پروری

یادگاری از کهن آئین ما

روزگاران خوش و شیرین ما

آری امشب جشن سور و آتش است

جشن رقص شعله‌ های سرکش است

چهارشنبه سوری مبارک

The post و آتشی که نمیرد همیشه در دل ماست first appeared on طرفداران فدورا.

Packit March 2023

Posted by Weekly status of Packit Team on March 13, 2023 02:00 PM
Week 10 (March 7th – March 13th) # Parsing the spec file by RPM is now performed only if really necessary, greatly improving performance in certain scenarios. (specfile#212)

Next Open NeuroFedora meeting: 13 March 1300 UTC

Posted by The NeuroFedora Blog on March 13, 2023 10:55 AM
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 13 March at 1300 UTC. The meeting is a public meeting, and open for everyone to attend. You can join us over:

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

$ date --date='TZ="UTC" 1300 2023-03-13'

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

We hope to see you there!

vulkan video vp9 decode - radv update

Posted by Dave Airlie on March 13, 2023 04:14 AM

While going over the AV1 a few people commented on the lack of VP9 and a few people said it would be an easier place to start etc.

Daniel Almeida at Collabora took a first pass at writing the spec up, and I decided to go ahead and take it to a working demo level.

Lynne was busy, and they'd already said it should take an afternoon, so I decided to have a go at writing the ffmpeg side for it as well as finish off Daniel's radv code.

About 2 mins before I finished for the weekend on Friday, I got a single frame to decode, and this morning I finished off the rest to get at least 2 test videos I downloaded to work.

Branches are at [1] and [2]. There is only 8-bit support so far and I suspect some cleaning up is required.

[1] https://github.com/airlied/FFmpeg/tree/vulkan-vp9-decode

[2] https://gitlab.freedesktop.org/airlied/mesa/-/commits/radv-vulkan-video-decode-mesa-vp9


Episode 366 – Software liability is coming

Posted by Josh Bressers on March 13, 2023 12:00 AM

Josh and Kurt talk about the number of dependencies that is now normal. Keeping track of thousands of dependencies used to be impressive, now it’s normal. In what instances should we know everything about our open source? The days of being able to ignore your software liability is looking like it’s coming to an end.

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

Show Notes

Use * to Seach for the word under the cursor in vim

Posted by Adam Young on March 12, 2023 10:53 PM

This might be my new favorite vimism.
The idea that there is a single character shortcut for searching for the character under the cursor is brilliant, and something I will use, quite a bit, in my day to day work. It might be more powerful than tags.

Duct tape in the datacenter

Posted by Jonathan Dieter on March 12, 2023 09:15 PM

When I was growing up, on Thursday nights we would watch the Red Green Show, a comedy show set in very rural Canada. One of the regular segments on the show was the Handyman Corner, where Red Green would build something impressive out of the spare parts and garbage he had sitting around the shop, along with copious amounts of “the Handyman’s secret weapon,” duct tape, to hold everything together. To this day, whenever I see duct tape I think about the Red Green Show.

Lately I’ve had cause to think about duct tape when looking into IT infrastructure issues, some that I’ve had to handle at work, and some that we’ve all gotten to see from the outside. I don’t think I’ve ever actually used physical duct tape on the job, but there’s more than one kind of duct tape.

The thing about duct tape is that it is an incredibly useful tool for holding things together that perhaps were never intended to be connected (the Apollo 13 duct tape and cardboard scene comes to mind here). The problem is when duct tape is used as a core part of the design (as per most of Red Green’s builds).

When working with infrastructure, we may not normally be using physical duct tape, but there are plenty of things we do that correspond with duct tape. At my day job, our infrastructure is built using a GitOps model where server deployments are managed using Ansible playbooks and, more recently, Terraform configuration, all stored in git repositories. We also have development environments where we can test infrastructure and code changes before pushing to production.

The primary advantages of using the GitOps model are documentation and repeatability. Documentation in git comes pretty easily because when changes are made, it’s easy to see what was changed, and (assuming we’ve been disciplined when writing commit messages) why it was changed. Repeatability is there because, If we deploy one server with a specific configuration and need to re-deploy it at a later point, the second deployment will be identical to the first. We don’t need to worry about missing steps because it’s all automatically done when deploying the playbooks.

So what happens when we bypass our processes? When we manually deploy a server? When we manually make a change? Well, that’s our duct tape. It’s sometimes very necessary. If an important service has crashed, the first priority is to get it back up and running, not have a committee discussion. The problem is when duct tape becomes permanent.

We’ve seen far too much of this in the news recently, the main case in point being Twitter. It’s unclear whether the latest outage is due to bypassed processes or whether the infrastructure was brittle to begin with (or, most likely, some combination of both), but, either way, the systems there are breaking down, and it just seems to be getting worse.

So how do you deal with duct tape in the datacenter? Here are some thoughts:

  1. Design your infrastructure to be extensible and your services to be highly available. One of the biggest causes of duct tape maintenance is brittle infrastructure. When there’s an outage, repairs are of the highest urgency, and fixing it now is more important than fixing it correctly. Unfortunately, emergency fixes are like layers of duct tape applied on top of each other, weakening the overall structure.

    Far better to have an infrastructure design where failures have no negative effect beyond letting your team know that something needs to be fixed. Without the urgency, fixes can be planned and implemented correctly. Upper management is happy because customers aren’t affected. You’re happy because the problem is being fixed properly and permanently.

  2. Be disciplined about your processes. When there are urgent tasks or problems, there’s the temptation to skip steps in the process and just apply a bit of duct tape to fix the problem. Sometimes you won’t have a choice, but, if you can avoid it, don’t take the shortcut.

  3. When you have to come up with quick and dirty hacks, ensure that they are done with an eye towards the long-term solution. While the ideal is to always design things properly from the beginning, in the real world, we sometimes have to get something done right now, without worrying about how correct it is.

    The common mistake is to build a quick solution without thinking about how you’ll replace it later. Once the urgency is over, you quickly realize that a proper fix will involve completely changing how your solution works.

    Far better to take a few minutes (or more if possible) to think through what you would want the long term solution to look like, and then assess how best to build the quick solution in a way that the duct tape can be easily replaced later.

  4. Document your duct tape. If you absolutely must make manual changes or break processes, document it. You may not think it’s necessary, but documentation ensures that the duct tape doesn’t get forgotten. There’s nothing worse than trying to fix a massive disaster and realizing that there’s some duct tape hanging around and you don’t know what it’s supposed to be attached to.

    I have been in a couple of situations recently where processes were bypassed (or never created in the first place) when creating a service, and the person responsible for the service has no idea how to manage it. We’ve ended up needing to spend tens of hours reverse engineering the service configuration, compared to a couple of minutes of documentation.

Like duct tape, the ability to make manual infrastructure changes is a useful, even vital, tool. Don’t throw it away just because it can be abused. The key is to ensure that it’s only used when absolutely necessary and that you know where your duct tape is.

Photo Polyken Duct Tape by Markbritton used under the CC BY-SA 3.0 license

New badge: Extra! Extra! VI !

Posted by Fedora Badges on March 12, 2023 04:10 PM
Extra! Extra! VIYou contributed twenty-five articles to Fedora Magazine!

New badge: Extra! Extra! V !

Posted by Fedora Badges on March 12, 2023 04:09 PM
Extra! Extra! VYou contributed twenty articles to Fedora Magazine!

New badge: Extra! Extra! IV !

Posted by Fedora Badges on March 12, 2023 04:07 PM
Extra! Extra! IVYou contributed fifteen articles to Fedora Magazine!

New badge: Extra! Extra! III !

Posted by Fedora Badges on March 12, 2023 04:05 PM
Extra! Extra! IIIYou contributed ten articles to Fedora Magazine!

New badge: Extra! Extra! II !

Posted by Fedora Badges on March 12, 2023 04:03 PM
Extra! Extra! IIYou contributed five articles to Fedora Magazine!

New badge: Early Bird !

Posted by Fedora Badges on March 12, 2023 03:57 PM
Early BirdYou have submitted the first change proposal this release cycle. Early Bird Catches the Worm!

New badge: Community Messenger VIII !

Posted by Fedora Badges on March 12, 2023 03:43 PM
Community Messenger VIIIYou wrote three hundred articles for the Community Blog! You are a real writeaholic! Thank you ever so much.

New badge: Community Messenger VII !

Posted by Fedora Badges on March 12, 2023 03:39 PM
Community Messenger VIIYou wrote two hundred articles for the Community Blog! Awesome work! Keep it coming.

New badge: Community Messenger VI !

Posted by Fedora Badges on March 12, 2023 03:35 PM
Community Messenger VIYou wrote one hundred articles for the Community Blog! Thanks for keeping everyone informed!

New badge: DevConf.us Attendee 2022 !

Posted by Fedora Badges on March 12, 2023 03:09 PM
DevConf.us Attendee 2022You attended the 2022 iteration of DevConf.us, a yearly open source conference in the United States

New badge: Fedora 35 Cloud Test Day !

Posted by Fedora Badges on March 12, 2023 02:49 PM
Fedora 35 Cloud Test DayYou wrangled the clouds for Fedora 35!

New badge: Fedora 37 CoreOS Test Day !

Posted by Fedora Badges on March 12, 2023 02:39 PM
Fedora 37 CoreOS Test DayYou helped solidify the core for Fedora 37!

Everything Curl from Daniel

Posted by Kushal Das on March 12, 2023 01:07 PM

Cover of the book

Everything Curl is a book about everything related to Curl. I read the book before online. But, now I am proud to have a physical copy signed by the author :)

the signature Author signing the book

It was a good evening, along with some amazing fish in dinner and wine and lots of chat about life in general.

7.1.0

Posted by Bodhi on March 11, 2023 02:07 PM

Released on 2023-03-11.
This is a feature release.

Dependency changes

  • Bodhi now uses pymediawiki instead of the unmaintained simplemediawiki to fetch test cases (#4852).

Features

  • bodhi-messages is updated to include additional properties in the message schemas. The additional properties are: app_name, agent_name, and __str__ (#4950).

Bug fixes

  • Retrieving sidetags list for a user not known to Koji caused an exception in bodhi-server (#4994).
  • Added support for bleach >= 6.0.0 (#5003).
  • bodhi-client: do not run koji wait-repo when expiring a buildroot override (#4830).
  • bodhi-client: fix --version option (#4981).
  • Update notes are now capped to a default of 10k characters, the value can be customized in config (#4982).
  • Fixed webUI template where karma and comment icons where misaligned at highly commented discussions (#4986).
  • Fixed the template of the update details page, where the testcases tab was always empty (#5000).
  • The link to the test gating tab in the update page was fixed (#5032).
  • The composer is now safer about not triggering stable composes for frozen releases (#5080).
  • Rawhide updates which are obsoleted before being pushed will now not be pushed to stable to avoid confusion (#5113).
  • Frozen releases didn't show up in filters (#5115).

Contributors

The following developers contributed to this release of Bodhi:

  • Kevin Fenzi
  • Mattia Verga
  • Ryan Lerch

Friday’s Fedora Facts: 2023-10

Posted by Fedora Community Blog on March 10, 2023 10:01 PM

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

The F38 Beta is go for release on the early target date (2023-03-14).

I have weekly office hours most Wednesdays in the morning and afternoon (US/Eastern time). 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
DevConf.CZBrno, Czech Republic16-18 Juncloses 10 Mar
WE23Los Angeles, CA, US26–28 Octcloses 14 Mar
DevOpsDays ChicagoChicago, IL, US9–10 Augcloses 17 Mar
FOSSY call for tracksPortland, OR, US13–16 Julcloses 19 Mar
AkademyThessaloniki, GR15–16 Julycloses 30 Mar
Container DaysHamburg, DE11–13 Sepcloses 31 Mar
All Things OpenRaleigh, NC, US15–17 Octcloses 31 Mar
The Perl and Raku ConferenceToronto, ON, CA11–13 Julcloses 31 Mar
DevConf USBoston, MA, US16–18 Augcloses 3 Apr
Upstreamvirtual7 Juncloses 7 Apr
openSUSE Conference 2023Nürnberg, DE26–28 Maycloses 9 Apr
TechBashMount Pocono, PA, US7–10 Novcloses 11 Apr
Web Weekend KathmanduKathmandu, NP23–24 Sepcloses 21 Apr
ShipIt ConDublin, IE1 Sepcloses 1 May
React NorwayLarvik, NO16 Juncloses 15 May
Inclusive Design 24virtual21 Sepcloses 4 Jun
</figure>

Help wanted

Upcoming test days

Meetings & events

Releases

<figure class="wp-block-table">
Releaseopen bugs
F364517
F373603
F38 (pre-release)1045
Rawhide7046
</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-setupON_QA
</figure>

Fedora Linux 38

Blockers

<figure class="wp-block-table">
BugComponentStatusBlocker status
2171350fcoe-utilsNEWAccepted (Final)
2173891gtk4NEWAccepted (Final)
2174563sddmNEWAccepted (Final)
2165762anacondaON_QAProposed (Final)
2175708gnome-boxesON_QAProposed (Final)
2176166gnome-contactsNEWProposed (Final)
2176038gnome-photosNEWProposed (Final)
2176043gnome-photosNEWProposed (Final)
2176732gnome-photosNEWProposed (Final)
2175809mutterPOSTProposed (Final)
2176766nautilusNEWProposed (Final)
2176782sddmNEWProposed (Final)
2176726totemNEWProposed (Final)
</figure>

Schedule

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

  • 2023-03-14 — F38 Beta early target release date
  • 2023-04-04Final freeze begins

Changes

The table below lists Changes status. See the ChangeSet page or Bugzilla for more information.

<figure class="wp-block-table">
StatusCount
ASSIGNED3
MODIFIED1
ON_QA45
CLOSED2
</figure>

Fedora Linux 39

Changes

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

<figure class="wp-block-table">
ProposalTypeStatus
Modernize Thread Building Blocks for Fedora 39System-WideApproved
MinGW toolchain updateSystem-WideApproved
FontAwesome6Self-ContainedAnnounced
</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: 2023-10 appeared first on Fedora Community Blog.

Announcing Fedora Linux 38 Beta

Posted by Fedora Magazine on March 10, 2023 06:53 PM

The Fedora Project is pleased to announce the immediate availability of Fedora Linux 38 Beta, the next step towards our planned Fedora Linux 38 release at the end of April.

Download this prerelease from our Get Fedora site:

Or, check out one of our popular variants, including KDE Plasma, Xfce, and other desktop environments, as well as images for ARM devices like the Raspberry Pi:

Beta Release Highlights

Fedora Workstation

Fedora 38 Workstation Beta includes GNOME 44. It’s currently in beta, with a final release expected at the end of March. GNOME 44 includes a lot of great improvements, including a new lock screen, a “background apps” section on the quick menu, and improvements to accessibility settings . In addition, enabling third-party repositories now enables an unfiltered view of applications on Flathub. 

Other updates

We always strive to bring new security features to users quickly. Packages are now built with stricter compiler flags that protect against buffer overflows. The rpm package manager uses a Sequoia-based OpenPGP parser instead of its own implementation.

If you’re profiling applications, you’ll appreciate the frame pointers now built into official packages. This makes Fedora Linux a great platform for developers looking to improve Linux application performance.

Of course, there’s the usual update of programming languages and libraries: Ruby 3.2, gcc 13, LLVM 16, Golang 1.20, PHP 8.2, and much more!

Testing needed

Since this is a Beta release, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora QA team via the test mailing list or in the #quality channel on Fedora Chat. As testing progresses, common issues are tracked in the “Common Issues” category on Ask Fedora.

For tips on reporting a bug effectively, read how to file a bug.

What is the Beta Release?

A Beta release is code-complete and bears a very strong resemblance to the final release. If you take the time to download and try out the Beta, you can check and make sure the things that are important to you are working. Every bug you find and report doesn’t just help you, it improves the experience of millions of Fedora Linux users worldwide! Together, we can make Fedora rock-solid. We have a culture of coordinating new features and pushing fixes upstream as much as we can. Your feedback improves not only Fedora Linux, but the Linux ecosystem and free software as a whole.

More information

For more detailed information about what’s new on Fedora Linux 38 Beta release, you can consult the Fedora Linux 38 Change set. It contains more technical information about the new packages and improvements shipped with this release.

CPE Weekly update – Week 10 2023

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

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

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

Week: 06 March – 10 March 2023

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

Highlights of the week

Infrastructure & Release Engineering

Goal of this Initiative

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

Updates

Fedora Infra

  • Got log forwarding setup on our OpenShift clusters, so now we have application logs
  • Worked with IT to decomission 6 servers and add 4 new ones.
  • Progress on moving fedoraplanet from Venus to Pluto

CentOS Infra including CentOS CI

  • reinstalled a bunch of existing centos 7 servers with RHEL9
  • installed new sponsored nodes with RHEL9 (while then moving services/data) and then decommission old servers
  • migrated https://people.centos.org to RHEL9
  • migrating www.centos.org nodes to RHEL9 (different hypervisors)
  • collaborated with RH Storage team for the Netapp filers upgrade (IAD2, and then RDU2 for CentOS Stream infra)

Release Engineering

  • Beta RC 1.3 is available for testing
  • Releng docs updates
  • Ansible changes for retirement of EPEL8-modularity

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

  • For c8s, everything has been prepared for maintainers to build in the Stream Koji
  • Finalizing c8s composes before we can resume publishing
  • Looking into speeding up Content Resolver
  • Resolved issue with check_gitbz not checking the correct branch for 9.2.z/9.3.0

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

Updates

  • Backported multiple CVE fixes for dcmtk across EPEL 8, EPEL 9, and Fedora
    • CVE-2021-41687 rhbz#2106336
    • CVE-2021-41688 rhbz#2106315
    • CVE-2021-41689 rhbz#2106340
    • CVE-2021-41690 rhbz#2106332
    • CVE-2022-2119 rhbz#2173039
    • CVE-2022-2120 rhbz#2173042
    • CVE-2022-2121 rhbz#2173045
    • CVE-2022-43272 rhbz#2150931, rhbz#2150930

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.

Updates

  • Bug fixes
  • UI and performance improvements
  • Wrapping-this-up planning

Community Design

Goal of this initiative

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

Updates

  • CPE members can file issues / requests to the CDT here.
  • Building new UI for new users / onboarding for Podman
  • New meeting time for Fedora Design Team TBA
  • Discussions post for new Fedora Server webpage
  • Video editing for the Fedora Linux 37 release party footage

The post CPE Weekly update – Week 10 2023 appeared first on Fedora Community Blog.

The Fedora Project FOSDEM 23 Experience

Posted by Fedora Magazine on March 10, 2023 08:00 AM
<figure class="wp-block-image size-large"></figure>

A measure of growth is most apparent when scaled across a span of different times and situations. That applies to folks getting to see you after a long time, to vegetation left alone to spread and of course, to communities having their first meetup after a prolonged spell of online-bound interactions. FOSDEM 23 happened to be one of the first times after around three years that community members from across the world met in person with each other in Brussels, Belgium. With new and old faces alike, their time was well spent representing the community, exhibiting to the wider free and open-source communities the good stuff that they have been keeping themselves busy with and most importantly, bonding with their Fedora friends.

This year FOSDEM took place on 4th February ’23 and 5th February ’23 at Université Libre de Bruxelles, Campus du Solbosch, Avenue F. D. Roosevelt 50, 1050 Bruxelles, Belgium. This free event was participated by over 8000 software engineering enthusiasts from across the world, had around 36 lightning talks and around 771 talks spanning 55 designated devrooms. Contributors from our community did not restrict their participation in the event as just attendees but they also enthusiastically volunteered to be stand keepers in the Fedora Project booth, speakers for a variety of talks and lectures, organizers for a set of devrooms and even as ground staff for making FOSDEM 23 a grand success.

Representation in booth

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

Fedora Project had its official booth in Building H of the Université Libre de Bruxelles campus, near the booths belonging to our friends at CentOS Project and GNOME Project. The desks were set up on time with a display showing the FOSDEM 23 attendee badge QR code and an assorted set of Fedora Project swags for taking (like keycaps with the Fedora logo, USB flash drives with Fedora branding, stickers and clips with the branding of Fedora subteams/SIGs/workgroups like NeuroFedora and Workstation, webcam covers with the Fedora logo and much more). We were also thankfully provided with a jar of jelly bears to offer to our booth attendees and a set of stickers from our friends at the AlmaLinux community.

With a designated booth duty schedule planned beforehand by our community members, the booth was constantly looked after by at least three staff members at any point in time and attended to hundreds of booth visitors throughout the course of the event. The booth visitors were excited to interact with our booth staff members, shared their own fun experiences of using Fedora Linux for a purpose of their choice and asked questions about participating in the community. We also teamed up with our friends from CentOS Project to combine our efforts into managing our booths together and moving our resources to/from the FOSDEM locker room. To sum it up, we really appreciate the community’s participation in our official booth.

Speaking about innovation

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

Contributors participating in the Fedora Project community were eager to share what they know about what they have been working and that took place in the form of multiple talks/lectures for a variety of devrooms during FOSDEM 23. Ranging from the latest Fedora Linux remix running on Apple Silicon hardware to improving the experience of video gaming on GNU/Linux distributions, from summing up the helpful outcomes of one of the first open-source creative conferences to building a web-based installer for Fedora Linux, our members were involved in providing a great deal of quality content and were met by wide acclaim from halls filled with enthusiastic attendees.

The delivered talks/lectures were not only useful in letting others know about all the cool things we have been working on but also instrumental in garnering feedback from the wider free and open-source software communities as to how we can do better. The attendees were eager to ask their questions at the end of the respective talks and curious to know about the directions that our projects, activities and developments were headed, thereby helping the speaker establish their network and also, potentially onboarding contributors. The following is the list of talks/lectures associated with the Fedora Project, the links of which can be followed to access the recordings and shared presentation assets.

Helping with devrooms

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

Being a volunteer-driven conference with only a few people working around the year to make it happen, FOSDEM entirely relies on free and open-source enthusiasts to contribute their efforts to organizing and running a variety of devrooms. FOSDEM has set up internet connectivity and projectors to ensure the teams can meet, discuss, hack and publicly showcase their latest developments in the form of lightning talks, news, discussions, talks and lectures. These devrooms cover a wide range of diverse topics, giving all enthusiasts a platform to show what they have been working on, learn what is current in the field of their interest and benefit from the discussions that take place about their topic.

Ranging from language-specific devrooms to those about community governance, contributors participating in the Fedora Project community got involved in not only delivering talks/lectures in these devrooms but also volunteering to make these a grand success. From running a live microphone for attending to popping up questions to flagging flashcards to show speakers how much time they have left, from setting up the wireless microphone for every new speaker coming to the stage to cleaning up everything after the event is wrapped up – FOSDEM appreciates the community participation and we are all about it. Following is a list of devrooms that were helped by Fedora Community members.

Making FOSDEM successful

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

Donning the bright orange FOSDEM volunteer tees are our proud force of FOSDEM ground staff who devote their time to making sure that everything goes smoothly while organizing the conference. From introducing speakers before their talk/lecture begins to running cash registers at the counter selling official FOSDEM tee, from attending to the FOSDEM cloakroom containing booth and devroom assets to providing directions to the lost speakers rushing to their devrooms – needless to mention that FOSDEM would not have been possible without them. Here as well, one of our long-time Fedora Project contributors, Bogomil Shopov volunteered during FOSDEM 23 as their official ground staff.

Other events

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

Beyond FOSDEM 23, the contributors participating in the Fedora Project community participated in a bunch of meetups happening around the same time which further helped enrich the networking opportunities for our members. This not only led to our community spanning far and wide to those of others like OpenSUSE, GNOME etc. but to also learning and adapting from what the other communities do best while collaborating with them. We participated in the day-long CentOS Connect event on 3rd February ’23, Google’s FLOSS Foundations Dinner 2023 on 3rd February ’23, Google’s Mentorship Meetup and Fedora & CentOS Friends Dinner on 4th February ’23, and GitHub’s SustainOSS Meetup on 5th February ’23.

Wonders of NextCloud

Posted by ! Avi Alkalay ¡ on March 10, 2023 12:30 AM
<figure class="wp-block-image size-large"></figure>

CIOs must pay attention to NextCloud.

It is an open source solution that kinda let you run your own Google Drive, own Google Apps, own Dropbox, own iCloud on your own servers and storage.

Has an App Store with hundreds of extensions, vibrant community, supports multiple users with file sharing and pretty advanced collaboration, conference calls, corporate mobile device management, security and encryption, and much more.

They also provide free and mature desktop and mobile apps that let users sync part or whole filesets with their devices for offline use (similar to Dropbox but limitless and with far more features). I’m running it on my family server and my folks (and me) are pretty impressed.

Requirements are just LAMP (Linux, Apache/NGINX, MariaDB and PHP).

In a world increasingly dominated by services on expensive clouds, an open source solution as NextCloud is a refreshing option for the cost-savvy.

make-tiny-image.py: creating tiny initrds for testing QEMU or Linux kernel/userspace behaviour

Posted by Daniel Berrange on March 09, 2023 03:54 PM

As a virtualization developer a significant amount of time is spent in understanding and debugging the behaviour and interaction of QEMU and the guest kernel/userspace code. As such my development machines have a variety of guest OS installations that get booted for various tasks. Some tasks, however, require a repeated cycle of QEMU code changes, or QEMU config changes, followed by guest testing. Waiting for an OS to boot can quickly become a significant time sink affecting productivity and lead to frustration. What is needed is a very low overhead way to accomplish simple testing tasks without an OS getting in the way.

Enter ‘make-tiny-image.py‘ tool for creating minimal initrd images.

If invoked with no arguments, this tool will create an initrd containing nothing more than busybox. The “init” program will be a script that creates a few device nodes, mounts proc/sysfs and then runs the busybox ‘sh’ binary to provide an interactive shell. This is intended to be used as follows

$ ./make-tiny-image.py
tiny-initrd.img
6.0.8-300.fc37.x86_64

$ qemu-system-x86_64 \
    -kernel /boot/vmlinuz-$(uname -r) \
    -initrd tiny-initrd.img \
    -append 'console=ttyS0 quiet' \
    -accel kvm -m 1000 -display none -serial stdio
~ # uname  -a
Linux (none) 6.0.8-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 11 15:09:04 UTC 2022 x86_64 x86_64 x86_64 Linux
~ # uptime
 15:05:42 up 0 min,  load average: 0.00, 0.00, 0.00
~ # free
              total        used        free      shared  buff/cache   available
Mem:         961832       38056      911264        1388       12512      845600
Swap:             0           0           0
~ # df
Filesystem           1K-blocks      Used Available Use% Mounted on
none                    480916         0    480916   0% /dev
~ # ls
bin   dev   init  proc  root  sys   usr
~ # <Ctrl+D>
[   23.841282] reboot: Power down

When I say “low overhead”, just how low are we talking about ? With KVM, it takes less than a second to bring up the shell. Testing with emulation is where this really shines. Booting a full Fedora OS with QEMU emulation is slow enough that you don’t want to do it at all frequently. With this tiny initrd, it’ll take a little under 4 seconds to boot to the interactive shell. Much slower than KVM, but fast enough you’ll be fine repeating this all day long, largely unaffected by the (lack of) speed relative to KVM.

The make-tiny-image.py tool will create the initrd such that it drops you into a shell, but it can be told to run another command instead. This is how I tested the overheads mentioned above

$ ./make-tiny-image.py --run poweroff
tiny-initrd.img
6.0.8-300.fc37.x86_64

$ time qemu-system-x86_64 \
     -kernel /boot/vmlinuz-$(uname -r) \
     -initrd tiny-initrd.img \
     -append 'console=ttyS0 quiet' \
     -m 1000 -display none -serial stdio -accel kvm
[    0.561174] reboot: Power down

real	0m0.828s
user	0m0.613s
sys	0m0.093s
$ time qemu-system-x86_64 \
     -kernel /boot/vmlinuz-$(uname -r) \
     -initrd tiny-initrd.img \
     -append 'console=ttyS0 quiet' \
     -m 1000 -display none -serial stdio -accel tcg
[    2.741983] reboot: Power down

real	0m3.774s
user	0m3.626s
sys	0m0.174s

As a more useful real world example, I wanted to test the effect of changing the QEMU CPU configuration against KVM and QEMU, by comparing at the guest /proc/cpuinfo.

$ ./make-tiny-image.py --run 'cat /proc/cpuinfo'
tiny-initrd.img
6.0.8-300.fc37.x86_64

$ qemu-system-x86_64 \
    -kernel /boot/vmlinuz-$(uname -r) \
    -initrd tiny-initrd.img \
    -append 'console=ttyS0 quiet' \
    -m 1000 -display none -serial stdio -accel tcg -cpu max | grep '^flags'
flags		: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
                  cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss syscall 
                  nx mmxext pdpe1gb rdtscp lm 3dnowext 3dnow rep_good nopl 
                  cpuid extd_apicid pni pclmulqdq monitor ssse3 cx16 sse4_1 
                  sse4_2 movbe popcnt aes xsave rdrand hypervisor lahf_lm 
                  svm cr8_legacy abm sse4a 3dnowprefetch vmmcall fsgsbase 
                  bmi1 smep bmi2 erms mpx adx smap clflushopt clwb xsaveopt 
                  xgetbv1 arat npt vgif umip pku ospke la57

$ qemu-system-x86_64 \
    -kernel /boot/vmlinuz-$(uname -r) \
    -initrd tiny-initrd.img \
    -append 'console=ttyS0 quiet' \
    -m 1000 -display none -serial stdio -accel kvm -cpu max | grep '^flags'
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
                  cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx 
                  pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good 
                  nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx 
                  ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe 
                  popcnt tsc_deadline_timer aes xsave avx f16c rdrand 
                  hypervisor lahf_lm abm 3dnowprefetch cpuid_fault 
                  invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced 
                  tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase 
                  tsc_adjust sgx bmi1 avx2 smep bmi2 erms invpcid mpx 
                  rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 
                  xsaves arat umip sgx_lc md_clear arch_capabilities

NB, with the list of flags above, I’ve manually line wrapped the output for saner presentation in this blog rather than have one giant long line.

These examples have relied on tools provided by busybox, but we’re not limited by that. It is possible to tell it to copy in arbitrary extra binaries from the host OS by just listing their name. If it is a dynamically linked ELF binary, it’ll follow the ELF header dependencies, pulling in any shared libraries needed.

$ ./make-tiny-image.py hwloc-info lstopo-no-graphics
tiny-initrd.img
6.0.8-300.fc37.x86_64
Copy bin /usr/bin/hwloc-info -> /tmp/make-tiny-imagexu_mqd99/bin/hwloc-info
Copy bin /usr/bin/lstopo-no-graphics -> /tmp/make-tiny-imagexu_mqd99/bin/lstopo-no-graphics
Copy lib /lib64/libhwloc.so.15 -> /tmp/make-tiny-imagexu_mqd99/lib64/libhwloc.so.15
Copy lib /lib64/libc.so.6 -> /tmp/make-tiny-imagexu_mqd99/lib64/libc.so.6
Copy lib /lib64/libm.so.6 -> /tmp/make-tiny-imagexu_mqd99/lib64/libm.so.6
Copy lib /lib64/ld-linux-x86-64.so.2 -> /tmp/make-tiny-imagexu_mqd99/lib64/ld-linux-x86-64.so.2
Copy lib /lib64/libtinfo.so.6 -> /tmp/make-tiny-imagexu_mqd99/lib64/libtinfo.so.6

$ qemu-system-x86_64 -kernel /boot/vmlinuz-$(uname -r) -initrd tiny-initrd.img -append 'console=ttyS0 quiet' -m 1000 -display none -serial stdio -accel kvm 
~ # hwloc-info 
depth 0:           1 Machine (type #0)
 depth 1:          1 Package (type #1)
  depth 2:         1 L3Cache (type #6)
   depth 3:        1 L2Cache (type #5)
    depth 4:       1 L1dCache (type #4)
     depth 5:      1 L1iCache (type #9)
      depth 6:     1 Core (type #2)
       depth 7:    1 PU (type #3)
Special depth -3:  1 NUMANode (type #13)
Special depth -4:  1 Bridge (type #14)
Special depth -5:  3 PCIDev (type #15)
Special depth -6:  1 OSDev (type #16)
Special depth -7:  1 Misc (type #17)

~ # lstopo-no-graphics 
Machine (939MB total)
  Package L#0
    NUMANode L#0 (P#0 939MB)
    L3 L#0 (16MB) + L2 L#0 (4096KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0)
  HostBridge
    PCI 00:01.1 (IDE)
      Block "sr0"
    PCI 00:02.0 (VGA)
    PCI 00:03.0 (Ethernet)
  Misc(MemoryModule)

An obvious limitation is that if the binary/library requires certain data files, those will not be present in the initrd. It isn’t attempting to do anything clever like query the corresponding RPM file list and copy those. This tool is meant to be simple and fast and keep out of your way. If certain data files are critical for testing though, the --copy argument can be used. The copied files will be put at the same path inside the initrd as found on the host

$ ./make-tiny-image.py --copy /etc/redhat-release 
tiny-initrd.img
6.0.8-300.fc37.x86_64
Copy extra /etc/redhat-release -> /tmp/make-tiny-imageicj1tvq4/etc/redhat-release

$ qemu-system-x86_64 \
    -kernel /boot/vmlinuz-$(uname -r) \
    -initrd tiny-initrd.img \
    -append 'console=ttyS0 quiet' \
    -m 1000 -display none -serial stdio -accel kvm 
~ # cat /etc/redhat-release 
Fedora release 37 (Thirty Seven)

What if the problem being tested requires using some kernel modules ? That’s covered too with the --kmod argument, which will copy in the modules listed, along with their dependencies and the insmod command itself. As an example of its utility, I used this recently to debug a regression in support for the iTCO watchdog in Linux kernels

$ ./make-tiny-image.py --kmod lpc_ich --kmod iTCO_wdt  --kmod i2c_i801 
tiny-initrd.img
6.0.8-300.fc37.x86_64
Copy kmod /lib/modules/6.0.8-300.fc37.x86_64/kernel/drivers/mfd/lpc_ich.ko.xz -> /tmp/make-tiny-image63td8wbl/lib/modules/lpc_ich.ko.xz
Copy kmod /lib/modules/6.0.8-300.fc37.x86_64/kernel/drivers/watchdog/iTCO_wdt.ko.xz -> /tmp/make-tiny-image63td8wbl/lib/modules/iTCO_wdt.ko.xz
Copy kmod /lib/modules/6.0.8-300.fc37.x86_64/kernel/drivers/watchdog/iTCO_vendor_support.ko.xz -> /tmp/make-tiny-image63td8wbl/lib/modules/iTCO_vendor_support.ko.xz
Copy kmod /lib/modules/6.0.8-300.fc37.x86_64/kernel/drivers/mfd/intel_pmc_bxt.ko.xz -> /tmp/make-tiny-image63td8wbl/lib/modules/intel_pmc_bxt.ko.xz
Copy kmod /lib/modules/6.0.8-300.fc37.x86_64/kernel/drivers/i2c/busses/i2c-i801.ko.xz -> /tmp/make-tiny-image63td8wbl/lib/modules/i2c-i801.ko.xz
Copy kmod /lib/modules/6.0.8-300.fc37.x86_64/kernel/drivers/i2c/i2c-smbus.ko.xz -> /tmp/make-tiny-image63td8wbl/lib/modules/i2c-smbus.ko.xz
Copy bin /usr/sbin/insmod -> /tmp/make-tiny-image63td8wbl/bin/insmod
Copy lib /lib64/libzstd.so.1 -> /tmp/make-tiny-image63td8wbl/lib64/libzstd.so.1
Copy lib /lib64/liblzma.so.5 -> /tmp/make-tiny-image63td8wbl/lib64/liblzma.so.5
Copy lib /lib64/libz.so.1 -> /tmp/make-tiny-image63td8wbl/lib64/libz.so.1
Copy lib /lib64/libcrypto.so.3 -> /tmp/make-tiny-image63td8wbl/lib64/libcrypto.so.3
Copy lib /lib64/libgcc_s.so.1 -> /tmp/make-tiny-image63td8wbl/lib64/libgcc_s.so.1
Copy lib /lib64/libc.so.6 -> /tmp/make-tiny-image63td8wbl/lib64/libc.so.6
Copy lib /lib64/ld-linux-x86-64.so.2 -> /tmp/make-tiny-image63td8wbl/lib64/ld-linux-x86-64.so.2

$ ~/src/virt/qemu/build/qemu-system-x86_64 -kernel /boot/vmlinuz-$(uname -r) -initrd tiny-initrd.img -append 'console=ttyS0 quiet' -m 1000 -display none -serial stdio -accel kvm  -M q35 -global ICH9-LPC.noreboot=false -watchdog-action poweroff -trace ich9* -trace tco*
ich9_cc_read addr=0x3410 val=0x20 len=4
ich9_cc_write addr=0x3410 val=0x0 len=4
ich9_cc_read addr=0x3410 val=0x0 len=4
ich9_cc_read addr=0x3410 val=0x0 len=4
ich9_cc_write addr=0x3410 val=0x20 len=4
ich9_cc_read addr=0x3410 val=0x20 len=4
tco_io_write addr=0x4 val=0x8
tco_io_write addr=0x6 val=0x2
tco_io_write addr=0x6 val=0x4
tco_io_read addr=0x8 val=0x0
tco_io_read addr=0x12 val=0x4
tco_io_write addr=0x12 val=0x32
tco_io_read addr=0x12 val=0x32
tco_io_write addr=0x0 val=0x1
tco_timer_reload ticks=50 (30000 ms)
~ # mknod /dev/watchdog0 c 10 130
~ # cat /dev/watchdog0
tco_io_write addr=0x0 val=0x1
tco_timer_reload ticks=50 (30000 ms)
cat: read error: Invalid argument
[   11.052062] watchdog: watchdog0: watchdog did not stop!
tco_io_write addr=0x0 val=0x1
tco_timer_reload ticks=50 (30000 ms)
~ # tco_timer_expired timeouts_no=0 no_reboot=0/1
tco_timer_reload ticks=50 (30000 ms)
tco_timer_expired timeouts_no=1 no_reboot=0/1
tco_timer_reload ticks=50 (30000 ms)
tco_timer_expired timeouts_no=0 no_reboot=0/1
tco_timer_reload ticks=50 (30000 ms)

The Linux regression had accidentally left the watchdog with the ‘no reboot’ bit set, so it would never trigger the action, which we diagnosed from seeing repeated QEMU trace events for tco_timer_expired after triggering the watchdog in the guest. This was quicky fixed by the Linux maintainers.

In spite of being such a simple and crude script, with many, many, many unhandled edge cases, it has proved remarkably useful at enabling low overhead debugging of QEMU/Linux guest behaviour.

February 2023 Council hackfest summary

Posted by Fedora Community Blog on March 09, 2023 08:00 AM

Last month, the Fedora Council gathered in Frankfurt, Germany for our first in-person meeting since January 2020. It felt great to see folks again, but it wasn’t all fun and games (actually, we didn’t even play games until after we’d wrapped up on the last night). With three years of work to catch up on and a five year strategy to develop, there was a lot to do. If you want the Zodbot form, we logged the minutes. For more detail, read on.

Code of Conduct

Fedora’s Code of Conduct is an important part of our community’s expectations about how we treat each other. Fedora is a welcoming community, and the Code of Conduct ensures it stays that way. I know the community believes in it because we get 20-ish reports every year. Most of these are resolved amicably, but dealing with these reports takes time and emotional energy.

To improve the process and share the load, the Council discussed the creation of a Code of Conduct Committee. That proposal is working through the policy change process right now. You can read the details of the proposal in the Discussion thread and provide your input by Tuesday 21 March.

We also agreed that the Code of Conduct itself is licensed under the Creative Commons Attribution 4.0 license. This allows other communities to freely use and adapt the work we’ve put into developing this. It’s also consistent with the Contributor Covenant, which is the basis of our Code of Conduct.

Council Charter

We also discussed updates to the Council Charter. This is the document that defines the basics of how the Council works. Think of it as Fedora’s constitution. It has served us well for nine years, but there are a few things that need to be updated.

First, we made a few renames. As Justin described in a recent Community Blog post, we renamed the Fedora Community Action and Impact Coordinator role to Fedora Community Architect. Read his post for more details. We also renamed the “Diversity & Inclusion Team Representative” role to “Diversity, Equity, and Inclusion Advisor.” This is partly due to the team changing its name to reflect the evolution of their work and partly because we want this role to be empowered to act, not just to be a conduit to the team.

We also renamed Objectives to Initiatives. As you may recall, these are 12-to-18 month strategic efforts led by the community with support from the Council. The rename doesn’t change anything of substance, but we felt it makes the purpose more clear. What is changing is how we work with Initiatives. From now on, new Initiatives will be assigned an executive sponsor — an existing Council member who can help marshall resources and otherwise provide high-level support.

All of these things are relatively trivial, so we voted on them and now they’re done. But there’s a more significant change that will be coming through the policy change process soon: the elimination of the auxiliary/full member distinction. When the Fedora Board was designing the Fedora Council, there was concern that people in functional roles might overstep the bounds of their role. In practice, this is not a problem we’ve had. It adds complexity and makes some Council members feel “less-than”. It’s a solution in search of a problem, so look for the formal proposal to drop it soon.

Fedora tooling

We spent some time discussing the tooling that the community uses. Source-git has the potential to improve the packager experience, but we’re told the team feels a need for explicit policy approval from the Council. Aleksandra is going to work with the Packit team to open that request.

We’re also in the process of working with GitLab to see if we can get a dedicated, hosted version of their open source project. Many in the community have expressed concerns about using proprietary products to develop Fedora Linux, and we respect that. At the same time, we don’t have a lot of development resources available for Pagure. I’m continuing to work with GitLab to find an option that will serve our needs.

If you know me at all, you know I’m a fan of Discourse. It’s been great as a forum tool and many teams (including the Council) have migrated off of mailing lists as a result. I’d like to see us continue to move away from mailing lists. The Council agreed that we’ll ask the Infrastructure team to stop creating new mailing lists once we have a plan in place. I’d like to start the process of migrating some of the devel list traffic in this order: Change proposals/discussion, FESCo ticket discussion, Introductions, Packaging, Automated messages. I know this will be a big “who moved my cheese?” moment for many of us. That’s why I’m working on a careful, phased plan. I hope when all is said and done, you’ll appreciate the better experience.

Strategy 2028

Discussing our new five year strategy took up the bulk of our time. You can read more about the background and timeline in my Community Blog post from a few weeks ago. In short, we identified 18 objectives to support our guiding star of doubling the number of weekly active contributors. I’m posting some of these objectives to Discussion every week. This is an exciting time in the Fedora Project, and I’m really looking forward to your input on our shared plan.

The post February 2023 Council hackfest summary appeared first on Fedora Community Blog.