fedora

Fedora People
Blog List
RSS 1.0 RSS 2.0 Atom 1.0 FOAF blogroll

Where did 5 Million EPEL-7 systems come from starting in March?

Posted by Stephen Smoogen on May 30, 2024 01:09 AM

ADDENDUM (2024-05-30T01:08+00:00): Multiple Amazon engineers reached out after I posted this and there is work on identifying what is causing this issue. Thank you to all the people who are burning the midnight oil on this.

ORIGINAL ARTICLE:

So starting earlier this year, the Fedora mirror manager mailing list started getting reports about heavier usage from various mirrors. Looking at the traffic reported, it seemed to be a large number of EL-7 systems starting to check in a lot more than in the past. At first I thought it was because various domains were beginning to move their operating systems from EL-7 to a newer release using one of the transition tools like Red Hat LEAPP or Alma ELevate. However, the surge didn't seem to die down, and in fact the Fedora Project mirrors have had regular problems with load due to this surge. 

A couple of weeks ago, I finally had time to look at some graphs I had set up when I was in Fedora Infrastructure and saw this:

Cumulative EPEL releases since 2019

 

Basically the load is an additional 5 million systems starting to query both the Fedora webproxies for mirror data, and then mirrors around the world to get further information. Going through the logs, there seems to be a 'gradual' shift of additional servers starting to ask for content when they had not before. In looking at the logs, it is hard to see what the systems asking for this data are. EL-7 uses yum which doesn't report any user data beyond: 

urlgrabber/3.10 yum/3.4.

That could mean the system is Red Hat Enterprise Linux 7, CentOS Linux 7, or even Amazon Linux 2 (which is sort of based on CentOS 7, but with various changes that using EPEL is probably not advised).

Because there wasn't a countme or any identifiers in the yum code, the older data-analysis program does a 'if I see an ip address 1 time a day, I count it once.. if I see it 1000 times, I count it once.' This had a problem of undercounting for various cloud and other networks behind a NAT router.. so normally maybe only 1 ip address would show up in a class C (/24) network space. What seemed to change is where we might only count one ip address in various networks, we were now seeing every ip address showing up in a Class C network. 

Doing some backtracking of the ip addresses to ASN numbers, I was able to show that the 'top 10' ASNs changed dramatically in March

January 27, 2024
Total  ASN 
1347016 16509_AMAZON-02,
219728 14618_AMAZON-AES,
53500 396982_GOOGLE-CLOUD-PLATFORM,
11205 8560_IONOS-AS
10403 8987_AMAZON
8463 32244_LIQUIDWEB,
8019 54641_IMH-IAD,
7965 8075_MICROSOFT-CORP-MSN-AS-BLOCK,
7889 398101_GO-DADDY-COM-LLC,
7234 394303_BIGSCOOTS,

February 27, 2024
1871463 16509_AMAZON-02,
219545 14618_AMAZON-AES,
51511 396982_GOOGLE-CLOUD-PLATFORM,
11021 8560_IONOS-AS
9016 8987_AMAZON
8208 32244_LIQUIDWEB,
7885 54641_IMH-IAD,
7768 8075_MICROSOFT-CORP-MSN-AS-BLOCK,
7618 398101_GO-DADDY-COM-LLC,
7383 394303_BIGSCOOTS,

March 27, 2024
2604768 16509_AMAZON-02,
276737 14618_AMAZON-AES,
34674 396982_GOOGLE-CLOUD-PLATFORM,
10211 8560_IONOS-AS
9560 135629_WESTCLOUDDATA
8134 8987_AMAZON
7952 54641_IMH-IAD,
7677 32244_LIQUIDWEB,
7445 394303_BIGSCOOTS,
7250 398101_GO-DADDY-COM-LLC,

April 27, 2024
4247068 16509_AMAZON-02,
1807803 14618_AMAZON-AES,
65274 8987_AMAZON
51668 135629_WESTCLOUDDATA
41190 55960_BJ-GUANGHUAN-AP
9799 396982_GOOGLE-CLOUD-PLATFORM,
7662 54641_IMH-IAD,
7561 394303_BIGSCOOTS,
6613 32244_LIQUIDWEB,
6425 8560_IONOS-AS

May 27, 2024
4186230 16509_AMAZON-02,
1775898 14618_AMAZON-AES,
62698 8987_AMAZON
50895 135629_WESTCLOUDDATA
38521 55960_BJ-GUANGHUAN-AP
9059 396982_GOOGLE-CLOUD-PLATFORM,
7613 394303_BIGSCOOTS,
7531 54641_IMH-IAD,
6307 398101_GO-DADDY-COM-LLC,
6222 32244_LIQUIDWEB,

I am not sure what changed in Amazon in March, but it has had a tremendous impact on parts of Fedora Infrastructure and the volunteer mirror systems which use it.

System insights with command-line tools: lscpu and lsusb

Posted by Fedora Magazine on May 29, 2024 08:00 AM

Introduction

Fedora (and other common Linux setups out there) offers you an array of tools for managing, monitoring, and understanding the system. Among these tools are a series of commands that begin with ls (for “list”).

They provide easy insights into various aspects of the system’s hardware and resources. This article series gives you an intro and overview over many of them, starting with the simpler ones. The post will cover lscpu and lsusb.

lscpu – Display CPU information

The lscpu command gathers and displays information about the CPU architecture. It is provided by the util-linux package. The command gathers CPU information from multiple sources like /proc/cpuinfo and architecture-specific libraries (e.g. librtas on PowerPC):

$ lscpu

This command outputs information like the number of CPUs, threads per core, cores per socket, and the CPU family and model.

If asked, it outputs detailed CPU information in JSON format. This provides a structured view that is particularly useful for scripting and automation:

$ lscpu --extended --json

Advanced usage example

With the machine readable JSON output, you can extract information using jq (a powerful command-line tool that allows users to parse, filter, and manipulate JSON data efficiently and worth an article of its own). For example, the following command will extract the current MHz for each CPU:

export LANG=en_US.UTF-8
export LC_ALL="en_US.UTF-8"
lscpu --json --extended \
  | jq '.cpus[] | {cpu: .cpu, mhz: .mhz}'

Let’s look at the single parts of the command:

  • export LANG=en_US.UTF-8 and export LC_ALL=”en_US.UTF-8″ are making sure that the output is not using localized numbers. For example, a German language setting can result in broken JSON output because of the use of commas in place of periods as floating point separators.
  • lscpu –json –extended generates the detailed CPU information in JSON format.
  • jq ‘.cpus[] | will iterate over each entry in the cpus array. The {cpu: .cpu, mhz: .mhz}‘ part constructs a new JSON object for each CPU entry showing the CPU number (cpu) and its current frequency in MHz (mhz).

Example output from a laptop operating in performance mode:

$ lscpu --json --extended \
  | jq '.cpus[] | {cpu: .cpu, mhz: .mhz}'
{
  "cpu": 0,
  "mhz": 3700.0171
}
{
  "cpu": 1,
  "mhz": 3700.2241
}
{
  "cpu": 2,
  "mhz": 3700.1121
}
{
  "cpu": 3,
  "mhz": 3884.2539
}

and later in power saver mode:

$ lscpu --json --extended \
  | jq '.cpus[] | {cpu: .cpu, mhz: .mhz}'
{
  "cpu": 0,
  "mhz": 1200.0580
}
{
  "cpu": 1,
  "mhz": 1200.0070
}
{
  "cpu": 2,
  "mhz": 1200.5450
}
{
  "cpu": 3,
  "mhz": 1200.0010
}

lsusb – Display USB Devices Information

The lsusb command displays detailed information about the USB buses in the system and the devices connected to them. It is provided by the usbutils package and helps users and system administrators easily view the configuration and the devices attached to their USB interfaces:

$ lsusb

This produces a list of all USB buses, devices connected to them, and brief information about each device, such as ID and manufacturer. This is particularly useful for a quick check of what devices are connected to the system and if you need the USB device ID for udev rules or the like.

Usage example and output

For those needing more detailed information about the USB devices, lsusb allows listing more detailed information:

$ lsusb | grep Fibocom
Bus 001 Device 013: ID 2cb7:0210 Fibocom L830-EB-00 LTE WWAN Modem

$ sudo lsusb -d 2cb7:0210 -v
Bus 001 Device 013: ID 2cb7:0210 Fibocom L830-EB-00 LTE WWAN Modem
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 [unknown]
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x2cb7 Fibocom
  idProduct          0x0210 L830-EB-00 LTE WWAN Modem
  bcdDevice            3.33
  iManufacturer           1 FIBOCOM
  iProduct                2 L830-EB-00
  iSerial                 3 004999010640000
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x00a1
    bNumInterfaces          4
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower              100mA
[ more output omitted for readability ]

Using the -v and -t options will tell lsusb to dump the physical USB device hierarchy as a tree including IDs. The following shows a detailed tree of all USB devices (here using a ThinkPad T480S), their types, speeds, and device classes. This is particularly useful for troubleshooting USB device issues:

$ lsusb -t -v
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 001: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        ID 046d:c069 Logitech, Inc. M-U0007 [Corded Mouse M500]
    |__ Port 002: Dev 003, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        ID 046a:c098 CHERRY 
    |__ Port 002: Dev 003, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
        ID 046a:c098 CHERRY 
    |__ Port 003: Dev 004, If 0, Class=Chip/SmartCard, Driver=usbfs, 12M
        ID 058f:9540 Alcor Micro Corp. AU9540 Smartcard Reader
    |__ Port 005: Dev 005, If 0, Class=Video, Driver=uvcvideo, 480M
        ID 5986:2123 Bison Electronics Inc. 
    |__ Port 005: Dev 005, If 1, Class=Video, Driver=uvcvideo, 480M
        ID 5986:2123 Bison Electronics Inc. 
    |__ Port 006: Dev 013, If 0, Class=Communications, Driver=cdc_mbim, 480M
        ID 2cb7:0210 Fibocom L830-EB-00 LTE WWAN Modem
    |__ Port 006: Dev 013, If 1, Class=CDC Data, Driver=cdc_mbim, 480M
        ID 2cb7:0210 Fibocom L830-EB-00 LTE WWAN Modem
    |__ Port 006: Dev 013, If 2, Class=Communications, Driver=cdc_acm, 480M
        ID 2cb7:0210 Fibocom L830-EB-00 LTE WWAN Modem
    |__ Port 006: Dev 013, If 3, Class=CDC Data, Driver=cdc_acm, 480M
        ID 2cb7:0210 Fibocom L830-EB-00 LTE WWAN Modem
    |__ Port 007: Dev 007, If 0, Class=Wireless, Driver=btusb, 12M
        ID 8087:0a2b Intel Corp. Bluetooth wireless interface
    |__ Port 007: Dev 007, If 1, Class=Wireless, Driver=btusb, 12M
        ID 8087:0a2b Intel Corp. Bluetooth wireless interface
    |__ Port 008: Dev 008, If 0, Class=Video, Driver=uvcvideo, 480M
        ID 5986:2115 Bison Electronics Inc. 
    |__ Port 008: Dev 008, If 1, Class=Video, Driver=uvcvideo, 480M
        ID 5986:2115 Bison Electronics Inc. 
    |__ Port 009: Dev 009, If 0, Class=Vendor Specific Class, Driver=[none], 12M
        ID 06cb:009a Synaptics, Inc. Metallica MIS Touch Fingerprint Reader
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    |__ Port 003: Dev 002, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
        ID 0bda:0316 Realtek Semiconductor Corp. Card Reader
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/5p, 480M
        ID 0451:8442 Texas Instruments, Inc. 
        |__ Port 001: Dev 003, If 0, Class=Hub, Driver=hub/7p, 480M
            ID 0424:2137 Microchip Technology, Inc. (formerly SMSC) 
        |__ Port 003: Dev 005, If 0, Class=Hub, Driver=hub/3p, 480M
            ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
            |__ Port 001: Dev 006, If 0, Class=Vendor Specific Class, Driver=r8152, 480M
                ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
        |__ Port 004: Dev 004, If 0, Class=Human Interface Device, Driver=usbhid, 480M
            ID 0451:82ff Texas Instruments, Inc. 
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub

Conclusion

Even though they are simple, both commands offer insights into the system’s configuration and status. Whether you’re troubleshooting, optimizing, or simply curious, these tools provide valuable data that can help you better understand and manage your Linux environment. See you next time when we will have a look at more useful listing and information command line tools and how to use them.

12/22 Élections pour le Conseil, FESCo, Mindshare et le comité EPEL pendant deux jours encore

Posted by Charles-Antoine Couret on May 28, 2024 08:59 PM

Comme le projet Fedora est communautaire, une partie du collège des organisations suivantes doit être renouvelée : Council, FESCo et Mindshare. Et ce sont les contributeurs qui décident. Chaque candidat a bien sûr un programme et un passif qu'ils souhaitent mettre en avant durant leur mandat pour orienter le projet Fedora dans certaines directions. Je vous invite à étudier les propositions des différents candidats pour cela.

J'ai voté

Pour voter, il est nécessaire d'avoir un compte FAS actif et de faire son choix sur le site du scrutin. Vous avez jusqu'au vendredi 23 décembre à 1h heure française pour le faire. Donc n'attendez pas trop.

Par ailleurs, comme pour le choix des fonds d'écran additionnel, vous pouvez récupérer un badge si vous cliquez sur un lien depuis l'interface après avoir participé à un vote.

Je vais profiter de l'occasion pour résumer le rôle de chacun de ces comités afin de clarifier l'aspect décisionnel du projet Fedora mais aussi visualiser le caractère communautaire de celui-ci.

Council

Le Council est ce qu'on pourrait qualifier le grand conseil du projet. C'est donc l'organe décisionnaire le plus élevé de Fedora. Le conseil définit les objectifs à long terme du projet Fedora et participe à l'organisation de celui-ci pour y parvenir. Cela se fait notamment par le biais de discussions ouvertes et transparentes vis à vis de la communauté.

Mais il gère également l'aspect financier. Cela concerne notamment les budgets alloués pour organiser les évènements, produire les goodies, ou des initiatives permettant de remplir les dits objectifs. Ils ont enfin la charge de régler les conflits personnels importants au sein du projet, tout comme les aspects légaux liés à la marque Fedora.

Les rôles au sein du conseil sont complexes.

Ceux avec droit de vote complet

Tout d'abord il y a le FPL (Fedora Project Leader) qui est le dirigeant du conseil et de facto le représentant du projet. Son rôle est lié à la tenue de l'agenda et des discussions du conseil, mais aussi de représenter le projet Fedora dans son ensemble. Il doit également servir à dégager un consensus au cours des débats. Ce rôle est tenu par un employé de Red Hat et est choisi avec le consentement du conseil en question.

Il y a aussi le FCAIC (Fedora Community Action and Impact Coordinator) qui fait le lien entre la communauté et l'entreprise Red Hat pour faciliter et encourager la coopération. Comme pour le FPL, c'est un employé de Red Hat qui occupe cette position avec l'approbation du conseil.

Il y a deux places destinées à la représentation technique et à la représentation plus marketing / ambassadrice du projet. Ces deux places découlent d'une nomination décidée au sein des organes dédiées à ces activités : le FESCo et le Mindshare. Ces places sont communautaires mais ce sont uniquement ces comités qui décident des attributions.

Il reste deux places communautaires totalement ouvertes et dont tout le monde peut soumettre sa candidature ou voter. Cela permet de représenter les autres secteurs d'activité comme la traduction ou la documentation mais aussi la voix communautaire au sens la plus large possible. C'est pour une de ces places que le vote est ouvert cette semaine !

Ceux avec le droit de vote partiel

Un conseiller en diversité est nommé par le FPL avec le soutien du conseil pour favoriser l'intégration au sein du projet des populations le plus souvent discriminées. Son objectif est donc de déterminer les programmes pour régler cette problématique et résoudre les conflits associés qui peuvent se présenter.

Un gestionnaire du programme Fedora qui s'occupe du planning des différentes versions de Fedora. Il s'assure du bon respect des délais, du suivi des fonctionnalités et des cycles de tests. Il fait également office de secrétaire du conseil. C'est un employé de Red Hat qui occupe ce rôle toujours avec l'approbation du conseil.

FESCo

Le FESCo (Fedora Engineering Steering Committee) est un conseil entièrement composé de membres élus et totalement dévoués à l'aspect technique du projet Fedora.

Ils vont donc traiter en particulier les points suivants :

  • Les nouvelles fonctionnalités de la distribution ;
  • Les sponsors pour le rôle d'empaqueteur (ceux qui pourront donc superviser un débutant) ;
  • La création et la gestion des SIGs (Special Interest Group) pour organiser des équipes autour de certaines thématiques ;
  • La procédure d'empaquetage des paquets.

Le responsable de ce groupe est tournant. Les 9 membres sont élus pour un an, sachant que chaque élection renouvelle la moitié du collège. Ici 4 places sont à remplacer.

Mindshare

Mindshare est une évolution du FAmSCo (Fedora Ambassadors Steering Committee) qu'il remplace. Il est l'équivalent du FESCo sur l'aspect plus humain du projet. Pendant que le FESCo se préoccupera beaucoup plus des empaqueteurs, la préoccupation de ce conseil est plutôt l'ambassadeur et les nouveaux contributeurs.

Voici un exemple des thèmes dont il a compétence qui viennent du FAmSCo :

  • Gérer l'accroissement des ambassadeurs à travers le mentoring ;
  • Pousser à la création et au développement des communautés plus locales comme la communauté française par exemple ;
  • Réaliser le suivi des évènements auxquels participent les ambassadeurs ;
  • Accorder les ressources aux différentes communautés ou activités, en fonction des besoin et de l'intérêt ;
  • S'occuper des conflits entre ambassadeurs.

Et ses nouvelles compétences :

  • La communication entre les équipes, notamment entre la technique et le marketing ;
  • Motiver les contributeurs à s'impliquer dans différents groupes de travail ;
  • Gérer l'arrivé de nouveaux contributeurs pour les guider, essayer de favoriser l'inclusion de personnes souvent peu représentées dans Fedora (femmes, personnes non américaines et non européennes, étudiants, etc.) ;
  • Gestion de l'équipe marketing.



Il y a 9 membres pour gérer ce comité. Un gérant, 2 proviennent des ambassadeurs, un du design et web, un de la documentation, un du marketing, un de la commops et les deux derniers sont élus. C'est pour un de ces derniers sièges que le scrutin est ouvert.




Mindshare




Mindshare est une évolution du FAmSCo (Fedora Ambassadors Steering Committee) qu'il remplace. Il est l'équivalent du FESCo sur l'aspect plus humain du projet. Pendant que le FESCo se préoccupera beaucoup plus des empaqueteurs, la préoccupation de ce conseil est plutôt l'ambassadeur et les nouveaux contributeurs.




Voici un exemple des thèmes dont il a compétence qui viennent du FAmSCo :



  • Gérer l'accroissement des ambassadeurs à travers le mentoring ;
    • 

  • Pousser à la création et au développement des communautés plus locales comme la communauté française par exemple ;
    • 

  • Réaliser le suivi des évènements auxquels participent les ambassadeurs ;
    • 

  • Accorder les ressources aux différentes communautés ou activités, en fonction des besoin et de l'intérêt ;
    • 

  • S'occuper des conflits entre ambassadeurs.
    • 

Et ses nouvelles compétences :



  • La communication entre les équipes, notamment entre la technique et le marketing ;
    • 

  • Motiver les contributeurs à s'impliquer dans différents groupes de travail ;
    • 

  • Gérer l'arrivé de nouveaux contributeurs pour les guider, essayer de favoriser l'inclusion de personnes souvent peu représentées dans Fedora (femmes, personnes non américaines et non européennes, étudiants, etc.) ;
    • 

  • Gestion de l'équipe marketing.
    • 




Il y a 9 membres pour gérer ce comité. Un gérant, 2 proviennent des ambassadeurs, un du design et web, un de la documentation, un du marketing, un de la commops et les deux derniers sont élus. C'est pour un de ces derniers sièges que le scrutin est ouvert.




Le comité EPEL




Officiellement dénommé EPEL Steering Committee, ce comité existe depuis 2007 mais est ouvert aux candidatures depuis le printemps 2024. C'est donc la première élection de ce comité cette fois-ci.




L'objectif du comité est d'aider à définir le projet EPEL qui fourni des paquets communautaires depuis Fedora vers CentOS ou RHEL. Cela permet d'avoir des paquets plus diversifiés que Red Hat ne souhaite pas maintenir ou dans des versions plus récentes le tout en se basant sur l'infrastructure de Fedora.




Il y a 4 places d'ouvertes pour cette élection sur les 7 places occupées par le comité. Leur mandat sera de deux ans.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
The $TRANSPORT macro of syslog-ng                            
                          

                            Posted by Peter Czanik
                            
                            on May 28, 2024 10:58 AM
                            
                        

                        

                            
Do you want to know how your log messages arrived to syslog-ng? The new $TRANSPORT macro provides you with part of the answer. It shows you the protocol variant for network sources, or the kind of local source used.


Read more at https://www.syslog-ng.com/community/b/blog/posts/the-transport-macro-of-syslog-ng

<figure><figcaption>
            
syslog-ng logo

        </figcaption>
</figure>

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Week 21 update                            
                          

                            Posted by Ankur Sinha "FranciscoD"
                            
                            on May 28, 2024 09:38 AM
                            
                        

                        

                            







Other stuff


I lost my tabs the other day.
I was tinkering with my Qutebrowser configuration, and I opened the browser but saved the session and quit it before all the tabs had loaded.
This meant that the next time I opened it, all the tabs were completely blank.
Bug?
Not really---I needed to either have waited for the session to load, or I should've quit without saving a partially loaded session.


The silver lining is that I've closed 100 tabs with research papers that I'd had open for the past year but not managed to read.
So, a clear up of sorts.




Returned Sony earbuds


I'd bought myself a set of WF-C700N ear buds some time ago.
I'd seen a few reviews.
They won the What Hi-Fi award in 2023, so they seemed a good buy.


They're very good sound wise for their price, but unfortunately, they turned out to be very buggy.
The right ear bud would just not turn on a lot of the time.
The docs suggested re-initialising them to fix the issue, and while it did fix the issue for a bit, the right earbud would go off again and not turn back on.
I did this a few times, but it became increasingly annoying.
Heading out on my commute only to find that the right earbud had stopped working again was really not fun.
On top of that, I couldn't reliably re-initialise them each time.
Sometimes the reinitialising process wouldn't work.


A search showed me that lots of users were experiencing this, with multiple folks on Reddit confirming the issue and suggesting returning the earbuds.
I persevered and tried various things on my Android phone too, but in the end nothing really fixed the issue.
So, I've returned them too.


I shelled out a bit more and got the top of the line WF-1000XM5 ones now.
They're double the price, and have much better sound quality and a few more features.
So far, so good 🤞.





                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
GNOME will have two Outreachy interns conducting a series of short user research exercises                            
                          

                            Posted by Felipe Borges
                            
                            on May 28, 2024 08:51 AM
                            
                        

                        

                            


We are happy to announce that GNOME is sponsoring two Outreachy  internship projects for the May-August 2024 Outreachy internship round where they will be conducting a series of short user research exercises, using a mix of research methods.


Udo Ijibike and Tamnjong Larry Tabeh will be working with mentors Allan Day and Aryan Kaushik.


Stay tuned to Planet GNOME  for future updates on the progress of this project!



                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
آموزش آپگرید لینوکس فدورا ۳۹ به فدورا ۴۰                            
                          

                            Posted by Fedora fans
                            
                            on May 28, 2024 06:30 AM
                            
                        

                        

                            
fedora-upgrade
fedora-upgrade

با توجه به انتشار نسخه نهایی Linux Fedora 40 پیشنهاد می شود تا کاربرانی که از نسخه های پایین تر استفاده می کنند، سیستم خود را به آخرین نسخه ی پایدار ارتقاء دهند. به همین خاطر در این مطلب قصد داریم تا لینوکس فدورا ۳۹ را به فدورا ۴۰ آپگرید کنیم.




قبل از انجام آپگرید بهتر است که از اطلاعات خود نسخه ی پشتیبان تهیه کنید. در حال حاظر احتمالا باید یک notification بر روی برنامه ی مدیر بسته ی گرافیکی سیستم دریافت کرده باشید که با طی مراحل آن می توانید به صورت گرافیکی سیستم خود را آپگرید کنید.


علاوه بر روش گرافیکی، امکان آپگرید از طریق خط فرمان نیز فراهم می باشد که در این مطلب قصد داریم تا آپگرید را از طریق خط فرمان انجام دهیم. برای شروع کار مطمئن شوید که از آخرین نسخه بسته های نرم افزاری استفاده می کنید. به همین خاطر برای بروز رسانی بسته های نرم افزاری کافیست تا دستور زیر را اجرا کنید:


# dnf upgrade --refresh


نکته اینکه اگر نسخه kernel آپدیت شد یکبار سیستم را reboot کنید.

اکنون پلاگین DNF را نصب کنید:




# dnf install dnf-plugin-system-upgrade




سپس برای دریافت بسته های بروزرسانی فدورا ۴۰ دستور زیر را اجرا کنید:


# dnf system-upgrade download --releasever=40


پس از دانلود موفقیت آمیز بسته های آپگرید، اکنون زمان reboot کردن سیستم می باشد تا فرایند آپگرید آغاز گردد. برای اینکار کافیست تا دستور زیر را اجرا کنید تا سیستم reboot شود:




# dnf system-upgrade reboot




 
The post آموزش آپگرید لینوکس فدورا ۳۹ به فدورا ۴۰ first appeared on طرفداران فدورا.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Malayalam open font design competition 2025 announced                            
                          

                            Posted by Rajeesh K Nambiar
                            
                            on May 28, 2024 04:52 AM
                            
                        

                        

                            
Rachana Institute of Typography, in association with KaChaTaThaPa Foundation and Sayahna Foundation, is launching a Malayalam font design competition for students, professionals, and amateur designers. 





Selected fonts will be published under Open Font License for free use. 





It is not necessary to know details of font technology; skills to design characters would suffice.





Timelines, regulations,  prizes and more details are available at the below URLs.





English: https://sayahna.net/fcomp-en
Malayalam: https://sayahna.net/fcomp-ml





Registration





Interested participants may register at https://sayahna.net/fcomp





Last day for registration is 30th June 2024.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Serverless URL redirects using JavaScript on GitHub Pages                            
                          

                            Posted by Vedran Miletić
                            
                            on May 28, 2024 12:00 AM
                            
                        

                        

                            
Serverless URL redirects using JavaScript on GitHub Pages
As many readers of this blog are already aware, we make great use of GitHub Pages for hosting this website and several others. In particular, after FIDIT's inf2 server was finally decomissioned, Pages was the obvious choice for replacing the remaining services it offered.
Since the number and variety of applications and services hosted on inf2 server grew and diminished organically over time, what remained afterward was a collection of complex, but unrelated link hierarchies that had to be redirected to new locations (remember that Cool URIs don't change).

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

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

                            Posted by Fedora fans
                            
                            on May 27, 2024 11:31 AM
                            
                        

                        

                            
fedora
fedora

به اطلاع می رساند در تاریخ ۲۱ می ۲۰۲۴ پشتیبانی از لینوکس فدورا ۳۸ به پایان رسید. از تاریخ اعلام شده هیچ بسته ی بروزرسانی و امنیتی برای Linux fedora 38 منتشر نخواهد شد. از سوی دیگر، فدورا لینوکس ۳۹ تا تقریباً یک ماه پس از انتشار فدورا لینوکس ۴۱ همچنان به دریافت به‌روز‌رسانی‌ها ادامه خواهد داد.




به کاربران پیشنهاد می شود تا از آخرین نسخه ی فدورا یعنی فدورا ۴۰ استفاده کنند یا اینکه سیستم خود را آپگرید کنند.
The post پایان پشتیبانی از لینوکس فدورا ۳۸ first appeared on طرفداران فدورا.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
کلاستر در کلاستر با vCluster                            
                          

                            Posted by Fedora fans
                            
                            on May 27, 2024 06:30 AM
                            
                        

                        

                            
vcluster
vcluster


vCluster یک ابزار متن‌باز توسعه‌یافته توسط Loft Labs است که امکان ایجاد و مدیریت کلاسترهای مجازی Kubernetes را بر روی یک کلاستر فیزیکی فراهم می‌کند. این ابزار به تیم‌های توسعه و DevOps کمک می‌کند تا با isolation بهتر و استفاده بهینه از منابع، فرآیندهای توسعه، آزمایش و استقرار را بهبود دهند. با استفاده از vCluster، می‌توان چندین کلاستر مجازی را به سرعت ایجاد و حذف کرد، که این کار به صرفه‌جویی در هزینه‌ها و منابع، و همچنین به مدیریت محیط‌های توسعه و آزمایش کمک زیادی می‌کند.




در این مطلب قصد داریم تا vCluster را نصب کنیم و با استفاده از آن بر روی یک کلاستر کوبرنتیز (به عنوان Host) یک کلاستر کوبرنتیز دیگر راه اندازی کنیم.


 


گام ۱: کوبرنتیز کلاستر


در ابتدا ما نیاز به یک کلاستر کوبرنتیز خواهیم داشت که میزبان کلاسترهایی خواهد بود که قصد داریم تا با استفاده از vCluster راه اندازی کنیم. برای راه اندازی این کلاستر کوبرنتیز می توانید از Minikube یا Kind استفاده کنید.

اکنون ما فرض می کنیم که با استفاده از kubectl به یک کوبرنتیز کلاستر دسترسی داریم.


 


گام ۲: نصب vCluster


در این مرحله باید vCluster CLI را نصب کنیم. برای نصب آن بر روی لینوکس کافیست تا دستور زیر را اجرا کنید:


curl -L -o vcluster "https://github.com/loft-sh/vcluster/releases/download/v0.20.0-beta.1/vcluster-linux-amd64" && sudo install -c -m 0755 vcluster /usr/local/bin && rm -f vcluster


نکته اینکه برای دانلود آخرین نسخه ی vCluster می توانید آن را از صفحه GitHub Releases پروژه دانلود کنید:




https://github.com/loft-sh/vcluster/releases




برای بررسی درستی نصب می توانید از دستور زیر استفاده کنید:


 


vcluster --version


 


گام ۳: راه اندازی کوبرنتیز کلاستر با vCluster


اکنون جهت راه اندازی یک کلاستر با vCluster در کلاستر کوبرنتیز میزبان مراحل زیر را باید انجام داد.


 


ساخت یک namespace:




kubectl create namespace myteam




راه اندازی کلاستر مجازی با vCluster:


vcluster create my-vcluster --namespace myteam


 


گام ۴: اتصال به کلاستر مجازی


جهت اتصال به کلاستر مجازی (my-vcluster) کافیست تا دستور زیر را اجرا کنید:


 


vcluster connect my-vcluster --namespace myteam


 


نکته اینکه برای disconnect شدن از کلاستر مجازی می توانید از دستور زیر استفاده کنید:




vcluster disconnect




 


گام ۵: نصب برنامه در کلاستر مجازی


اکنون جهت آزمایش قصد داریم تا nginx را در این کلاستر مجازی (my-vcluster) نصب کنیم. برای اینکار کافیست تا دستورهای زیر را اجرا کنید:


 


kubectl create namespace demo-nginx
kubectl create deployment ngnix-deployment -n demo-nginx --image=nginx -r 2


جهت بررسی دستور زیر را اجرا کنید:




kubectl get pods -n demo-nginx




 


امید است تا از این مطلب استفاده لازم را برده باشید.


 
The post کلاستر در کلاستر با vCluster first appeared on طرفداران فدورا.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Week 21 in Packit                            
                          

                            Posted by Weekly status of Packit Team
                            
                            on May 27, 2024 12:00 AM
                            
                        

                        

                            
Week 21 (May 21st – May 27th)​
  • We have fixed the syncing of ACLs for propose-downtream for CentOS Stream. (packit#2318)

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Episode 430 – Frozen kernel security                            
                          

                            Posted by Josh Bressers
                            
                            on May 27, 2024 12:00 AM
                            
                        

                        

                            
Josh and Kurt talk about a blog post about frozen kernels being more secure. We cover some of the history and how a frozen kernel works and discuss why they would be less secure. A frozen kernel is from when things worked very differently. What sort of changes will we see in the future?





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




Show Notes






                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Not again Red Hat                            
                          

                            Posted by Jens Kuehnel
                            
                            on May 26, 2024 12:23 PM
                            
                        

                        

                            
Update 2024.05.26: I appears the elrepo has found a way to create kmod packages for RHEL9.4 and RHEL8.10. I tested mp3sas, ftsteutates and wireguard from the elrepo-testing repo and it works flawlessly. 





In this video Jeff Geerling accounced that “Corporate Open Source is Dead”. He already dropped support from his really good ansible playbooks. This was because Red Hat only distributes its sources to customers. Another brick in this wall was announced today by the great ELrepo project.





In this blogpost it was announced that RHEL made some changes in the upcoming 8.10 and 9.4 releases of RHEL and this will break some of the kernel modules that were created by elrepo to allow running RHEL with older cards – that are not official supported anymore. The fun thing is not the whole driver that was deprecated, but only some of the supported pci-id where removed.





Especially for home lab users this created a big problem. aacraid, megaraid_sas, mlx4 and mpt3sas are drivers that are used in a lot of home labs everywhere.





Again the overall intention from Red Hat are not the problem. If Red Hat would break support of that in RHEL 10 there would be no problems. It would be interesting to know if this is a unexpected consequence of an patch or a targeted business decision. Yes I know why the support was dropped by Red Hat, but Red Hat is not only forgetting it roots, but again kicked the non-prod users in the curb. Just after they droped Centos and broke there promis there as well. 





At least for my homelab this creates an extra work to do, because my RAID Controller is on the deprecated list. At least AlmaLinux has undo this patch and you don’t even need elrepo to support his older hardware.





I was planning to reinstall the host anyway. I only have to decide to select Fedora or AlmaLinux.  The time to decide that is coming earlier the I hoped.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
I was interviewed on NPR Planet Money                            
                          

                            Posted by Richard W.M. Jones
                            
                            on May 24, 2024 02:45 PM
                            
                        

                        

                            
I was interviewed on NPR Planet Money about my small role in the Jia Tan / xz / ssh backdoor.





NPR journalist Jeff Guo interviewed me for a whole 2 hours, and I was on the program (very edited) for about 4 minutes!  Quite an interesting experience though.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Infra and RelEng Update – Week 21 2024                            
                          

                            Posted by Fedora Community Blog
                            
                            on May 24, 2024 10:00 AM
                            
                        

                        

                            
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. It also contains updates for the CPE (Community Platform Engineering) Team as the CPE initiatives are in most cases tied to I&R work.





We provide you both an infographic and a 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 at the infographic.





Week: 20 May – 24 May 2024








<figure class="wp-block-image size-full">I&R infographic</figure>




Infrastructure & Release Engineering





The purpose of this team is to take care of day-to-day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces, etc.).
List of planned/in-progress issues





Fedora Infra





CentOS Infra including CentOS CI





Release Engineering





CPE Initiatives





EPEL





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, Scientific Linux (SL) and Oracle Linux (OL).





Updates





  • 

  • 

If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on matrix.


The post Infra and RelEng Update – Week 21 2024 appeared first on Fedora Community Blog.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
How to move from Redis to Valkey                            
                          

                            Posted by Fedora Magazine
                            
                            on May 24, 2024 08:00 AM
                            
                        

                        

                            
The Redis move to a new license means it will no longer be considered open source software. This article will explain how to move from Redis to the alternative, Valkey.









Background





A few weeks ago, the company behind Redis published a blog post announcing that future versions of the Redis project were moving from BSD-3 clause, a well-accepted and understood open source license, to dual RSALv2 (Redis Source Available License 2.0) / SSPLv1 (Server Side Public License). The blog post plainly states “we openly acknowledge that this change means Redis is no longer open source under the OSI definition” (and, indeed, Fedora doesn’t allow either of these licenses). 





In response to this change, a number of existing contributors and maintainers of Redis formed Valkey, a new Linux Foundation project. You can think of Valkey as a continuation of open source Redis. It is derived from the same code-base and has many of the same folks making the decisions and contributing. The Valkey project has a technical steering committee that consists of people that work at Alibaba, AWS, Ericsson, Huawei, Google, and Tencent and an even wider array of organizations as contributors.





How do you move?





As a Fedora user, what are you to do if you use Redis and want to move to Valkey? Thankfully, there is the valkey-compat-redis package to handle the transition for you by moving your data and configuration over to Valkey.





In this scenario, you likely already have Redis installed, running, and loaded with data. For the purpose of this post I started with a fresh Fedora 40 installation, added the Redis (7.2.4) package, and started the server.





From here I’m going to take a peek at the current redis server information:





$ redis-cli info server
# Server
redis_version:7.2.4
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:8c22b097984bd350
redis_mode:standalone
...





Note that the server responds with redis_version:7.2.4 , remember this for later.





Since this is a fresh install of Redis, I’m going to write some data to a key so it will be visible later in Valkey. 





$ redis-cli set test_key "written in redis 7.2.4"






Migration and Persistence





Now is a good time to consider your persistence settings. How you persist your data in Redis (and Valkey) is highly configurable. Valid usage patterns run the gamut from no persistence whatsoever all the way to disk writes on every key change.  valkey-compat-redis will cleanly shut down Redis using SIGTERM, but there isn’t any additional magic: if you don’t have persistence set up or you have the Redis configuration (/etc/redis/redis.conf) option shutdown-on-sigterm set to now or force you could lose some or all your data. However, keep in mind that running valkey-compat-redis isn’t functionally different from doing any previous Redis upgrade in this regard





Installing the compat package





With that out of the way, it’s time to move to Valkey!





Install valkey-compat-redis with the allowerasing flag. You need the allowerasing flag so the package manager can remove Redis and put Valkey in its place. 





$ sudo dnf install valkey-compat-redis --allowerasing

...

Installed:
  valkey-7.2.5-5.fc40.x86_64                               valkey-compat-redis-7.2.5-5.fc40.x86_64
Removed:
  redis-7.2.4-3.fc40.x86_64

Complete!





What did this just do? The package takes your existing configuration files and persistence data and moves them to Valkey. Valkey is able to accept these directly with no changes or translation steps. Valkey is fully compatible with the Redis API, protocol, persistence data, ports, and configuration files. 





This is all possible because the current generally available release of Valkey (7.2.5) is, in practical purposes, a name change from Redis 7.2.4. The code changes in Valkey 7.2.5 were about re-branding. This version intentionally introduced no new features or functionality to make sure you can move to Valkey easily.





Starting Valkey





Now that you’ve installed Valkey, you’ll need to start it:





$ sudo systemctl start valkey





Then get the info about the server:





$ redis-cli info server
# Server
redis_version:7.2.4
server_name:valkey
valkey_version:7.2.5
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:b0d9f188ef999bd3
redis_mode:standalone
...





A few things to note in this example:





  • Valkey responds with redis_version:7.2.4 as well as valkey_version:7.2.5 . Some software has specific checks for versions and could break on an unknown response. Retaining redis_version  maintains maximum compatibility while still identifying the server with valkey_version.
    • 




  • Valkey has a binary named valkey-cli but symbolically links redis-cli. This will keep your muscle memory intact until you get used to typing valkey-cli. It does the same for valkey-server and redis-server
    • 

Interacting with Valkey





Now, it’s time to take a look at the data and interact with the server. First get the key that was written in Redis (of course, if you don’t have persistence turned on this won’t work):





$ valkey-cli get test_key
"written in redis 7.2.4"





Just as a proof point, you can write data to the server and get the key back written in Valkey along side the one written in Redis:





$ valkey-cli set from-new-server "valkey-7.2.5"
OK
$ valkey-cli mget test_key from-new-server
1) "written in redis 7.2.4"
2) "valkey-7.2.5"





This example is pretty simple, but it illustrates a lot. First, because valkey-compat-redis moves your configuration over, it doesn’t need to be the default. No matter how you have configured Redis 7.2.4, valkey-compat-redis moves simple or complex configurations over and Valkey can read them. This means that the same migrations step works even for Cluster or Sentinel.





Second, since Valkey connects in the same way (using the same protocols and default port) your application should work the same. Passing in the same connection information to your application that once pointed at Redis (and now points to Valkey) will yield the same results.





Other Considerations





All of this being said: there are a few things that can’t be illustrated in the above example. You don’t have to use valkey-compat-redis, instead you can just install valkey. If you’ve got Redis on a machine and run:





$ sudo dnf install valkey





You’ll have Valkey installed along side of Redis. You can’t successfully start up both processes using the default configuration. However, changing the configuration file at /etc/valkey/valkey.conf to use a different port would allow you to run Valkey and Redis. Indeed, you could even cluster Valkey and Redis together since they speak the same protocol, enabling more complex migrations. 





The other thing to keep in mind is that Valkey isn’t any more backwards compatible than Redis 7.2.4. Moving from a very old version of Redis to Valkey carries the same breaking changes as moving to Redis 7.2.x. Thankfully, most versions carry minimal breaking changes even between major versions. 





What’s next?





This post has largely focused on what hasn’t changed and why that’s a good thing. The Valkey team intends to add no new features to 7.2.x. Only bug fixes coming as patch releases will occur in the future. All new changes are going in 8.x. While the team is busy planning a full slate of new features that increase performance and usability, they don’t plan to break the API. If you’re interested in helping work on the future of Valkey, be sure to check out valkey-io/valkey and read the CONTRIBUTING.md file to learn more.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
PHP version 8.2.20RC1 and 8.3.8RC1                            
                          

                            Posted by Remi Collet
                            
                            on May 24, 2024 05:42 AM
                            
                        

                        

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



RPMs of PHP version 8.3.8RC1 are available



  • as base packages
	
    • in the remi-modular-test for Fedora 38-40 and Enterprise Linux ≥ 8
      • 
		
    • in the remi-php83-test repository for Enterprise Linux 7
      • 
	
    • 
	
  • as SCL in remi-test repository
    • 

RPMs of PHP version 8.2.20RC1 are available



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

emblem-notice-24.png The Fedora 39, 40, EL-8 and EL-9 packages (modules and SCL) are available for x86_64 and aarch64.
          
emblem-notice-24.pngPHP version 8.1 is now in security mode only, so no more RC will be released.



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



emblem-notice-24.png Announcements:



Parallel installation of version 8.3 as Software Collection:



yum --enablerepo=remi-test install php83



Parallel installation of version 8.2 as Software Collection:



yum --enablerepo=remi-test install php82



Update of system version 8.3 (EL-7) :



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



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



dnf module switch-to php:remi-8.3
dnf --enablerepo=remi-modular-test update php\*



Update of system version 8.2 (EL-7) :



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



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



dnf module switch-to php:remi-8.2
dnf --enablerepo=remi-modular-test update php\*



emblem-notice-24.png Notice:



  • version 8.3.8RC1 is also in Fedora rawhide for QA
    • 
	
  • EL-9 packages are built using RHEL-9.4
    • 
	
  • EL-8 packages are built using RHEL-8.9
    • 
	
  • EL-7 packages are built using RHEL-7.9
    • 
	
  • oci8 extension uses the RPM of the Oracle Instant Client version 21.13 on x86_64 or 19.19 on aarch64
    • 
	
  • intl extension uses libicu 73.2
    • 
	
  • RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
    • 
	
  • versions 8.2.20 and 8.3.8 are planed for June 6th, in 2 weeks.
    • 

Software Collections (php82, php83)









Base packages (php)







                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
SSL: How It Works and Why It Matters                            
                          

                            Posted by Farhaan Bukhsh
                            
                            on May 23, 2024 02:46 PM
                            
                        

                        

                            
How did it start?
I have been curious about what an SSL Certificate is and how it works. This is a newbie's log on the path to understanding a thing or two about how it works.
We casually talk about security and how SSL certificates should be used to...

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Live Migration: setup                            
                          

                            Posted by pjp
                            
                            on May 23, 2024 12:12 PM
                            
                        

                        

                            
While debugging a QEMU live migration related issue, I learned a setup to live migrate a virtual machine (VM) across two host machines. Migration here means to move a VM from one host machine to another. And live migration is, while a VM is running on the source machine, its state is copied to the destination machine, and once this copying is done, VM stops on the source machine and starts running on the destination machine. Applications running inside the VM are suppose to run as before, as if nothing changed.





Migrating a VM from one machine to another would entail moving its disk image and xml files as well. But copying (rsync(1)) files across machines could take long time, depending on file size and network bandwidth.





f39vm.qcow2  107.39G  100%  334.82MB/s  0:05:05
r91vm.qcow2   42.96G  100%  111.88MB/s  0:06:06
r93vm.qcow2   21.48G  100%  242.79MB/s  0:01:24





It is not feasible to stall a VM for such long times during migration. So migration requires that the source and destination machines are connected by a reliable high bandwidth network channel and the VM disk files are accessed on both machines via shared storage system. Accordingly, the source host machine is turned into a NFS server and destination machine is made NFS client:





source)# dnf install nfs-utils
source)# systemctl enable nfs-server
source)# systemctl enable rpcbind
source)# echo '/home/images 10.x.x.0/24(rw)' > /etc/exports
source)# mount -t nfs source.host.machine.com:/home/images/ /mnt/images/

destin)# dnf install nfs-utils
destin)# systemctl enable nfs-server
destin)# systemctl enable rpcbind
destin)# virsh pool-create-as --name=migrate \
    --type=netfs --source-host=source.host.machine.com \
    --source-path='/home/images' --source-format=nfs \
    --target=/mnt/images/





The VM xml configuration file should access the disk image via /mnt/images path as





<disk type='file' device='disk'>
  <source file='/mnt/images/r93vm.qcow2' index='1'/>
</disk>





If the NFS setup is incorrect, migrate command may throw errors like these:





error: Unsafe migration: Migration without shared storage is unsafe





Once NFS server & client setup is done, try to start the VM on both machines to confirm that it is working, before trying the migration. 





source)# virsh start --console r93vm





When VM runs on both machines, we can try the migration between two machines with




# cat migrate-test.sh 
#!/bin/sh

if [ $# -lt 2 ]; then
    echo "Usage: $0 <guest> <destination-host>"
    exit 1;
fi

GUEST=$1
DHOST=$2
while true;
do
    ds=$(virsh domstate $GUEST | sed -ne '1p')
    if [ "$ds" == "running" ]; then
        id=$(virsh domid $GUEST | sed -ne '1p')
        echo -n "migrate $GUEST.........$id"
        sleep 3s
        /bin/virsh migrate --verbose --persistent \
            --timeout 3 --timeout-postcopy \
            --live --postcopy  \
            $GUEST  qemu+ssh://$DHOST/system
    fi
    sleep 3s
done
exit 0;





This script live migrates a VM between source and destination machines in an infinite loop using the postcopy method of migration. Next we’ll see more about these migration methods.






                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
New badge: DevConf.cz 2025 Attendee !                            
                          

                            Posted by Fedora Badges
                            
                            on May 23, 2024 07:17 AM
                            
                        

                        

                            
DevConf.cz 2025 AttendeeYou attended the 2025 iteration of DevConf.cz, a yearly open source conference in Czechia!

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
New badge: DevConf.cz 2024 Attendee !                            
                          

                            Posted by Fedora Badges
                            
                            on May 23, 2024 07:15 AM
                            
                        

                        

                            
DevConf.cz 2024 AttendeeYou attended the 2024 iteration of DevConf.cz, a yearly open source conference in Czechia!

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
New badge: Let's have a party (Fedora 40) !                            
                          

                            Posted by Fedora Badges
                            
                            on May 23, 2024 07:09 AM
                            
                        

                        

                            
LetYou attended the F40 Online Release Party!

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Introducing the WebKit Container SDK                            
                          

                            Posted by Patrick Griffis
                            
                            on May 23, 2024 04:00 AM
                            
                        

                        

                            
Developing WebKitGTK and WPE has always had challenges such as the amount of dependencies or it’s fairly complex C++ codebase which not all compiler versions handle well. To help with this we’ve made a new SDK to make it easier.





Current Solutions



There have always been multiple ways to build WebKit and its dependencies on your host however this was never a great developer experience. Only very specific hosts could be “supported”, you often had to build a large number of dependencies, and the end result wasn’t very reproducable for others.



The current solution used by default is a Flatpak based one. This was a big improvement for ease of use and excellent for reproducablity but it introduced many challenges doing development work. As it has a strict sandbox and provides read-only runtimes it was difficult to use complex tooling/IDEs or develop third party libraries in it.



The new SDK tries to take a middle ground between those two alternatives, isolating itself from the host to be somewhat reproducable, yet being a mutable environment to be flexible enough for a wide range of tools and workflows.



The WebKit Container SDK



At the core it is an Ubuntu OCI image with all of the dependencies and tooling needed to work on WebKit. On top of this we added some scripts to run/manage these containers with podman and aid in developing inside of the container. It’s intention is to be as simple as possible and not change traditional development workflows.



You can find the SDK and follow the quickstart guide on our GitHub: https://github.com/Igalia/webkit-container-sdk



The main requirements is that this only works on Linux with podman 4.0+ installed. For example Ubuntu 23.10+.



In the most simple case, once you clone https://github.com/Igalia/webkit-container-sdk.git, using the SDK can be a few commands:



source /your/path/to/webkit-container-sdk/register-sdk-on-host.sh
wkdev-create --create-home
wkdev-enter




From there you can use WebKit’s build scripts (./Tools/Scripts/build-webkit --gtk) or CMake. As mentioned before it is an Ubuntu installation so you can easily install your favorite tools directly like VSCode. We even provide a wkdev-setup-vscode script to automate that.



Advanced Usage



Disposibility



A workflow that some developers may not be familiar with is making use of entirely disposable development environments. Since these are isolated containers you can easily make two. This allows you to do work in parallel that would interfere with eachother while not worrying about it as well as being able to get back to a known good state easily:



wkdev-create --name=playground1
wkdev-create --name=playground2

podman rm playground1 # You would stop first if running.
wkdev-enter --name=playground2




Working on Dependencies



An important part of WebKit development is working on the dependencies of WebKit rather than itself, either for debugging or for new features. This can be difficult or error-prone with previous solutions. In order to make this easier we use a project called JHBuild which isn’t new but works well with containers and is a simple solution to work on our core dependencies.



Here is an example workflow working on GLib:



wkdev-create --name=glib
wkdev-enter --name=glib

# This will clone glib main, build, and install it for us. 
jhbuild build glib

# At this point you could simply test if a bug was fixed in a different versin of glib.
# We can also modify and debug glib directly. All of the projects are cloned into ~/checkout.
cd ~/checkout/glib

# Modify the source however you wish then install your new version.
jhbuild make




Remember that containers are isoated from each other so you can even have two terminals open with different builds of glib. This can also be used to test projects like Epiphany against your build of WebKit if you install it into the JHBUILD_PREFIX.



To Be Continued



In the next blog post I’ll document how to use VSCode inside of the SDK for debugging and development.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Quectel EM05-G (LTE module) with ThinkPad T14 Gen4 on Fedora 39 and 40                            
                          

                            Posted by Andreas Haerter
                            
                            on May 23, 2024 01:46 AM
                            
                        

                        

                            
We recently bought a bunch of Lenovo ThinkPad T14 Gen4 Model 21HDCTO1WW. They were shipped with a Quectel EM05-G WWAN module. To our surprise, ModemManager did not activate the module right away even though the Fedora Linux support for the hardware is known to be good. It turned out that our hardware revision reports with a different USB device ID 2c7c:0313 than previous versions which used 2c7c:030a:


Bus 003 Device 002: ID 2c7c:0313 Quectel Wireless Solutions Co., Ltd. Quectel EM05-G

Therefore, the necessary FCC unlock procedure does not get triggered automatically even though an unlock script for the Quectel EM05-G was already added by Leah Oswald. However, the modem works perfectly fine if you unlock it manually after each reboot:


mmcli -L
sudo mbimcli --device-open-proxy --device="/dev/cdc-wdm0" --quectel-set-radio-state=on

We have opened an upstream issue to fix the problem. If you don’t want to wait so long until a new ModemManager version including the fix arrives on your computer, you can help yourself as follows:


sudo mkdir -p "/etc/ModemManager/fcc-unlock.d/"
sudo chown root:root -R "/etc/ModemManager/"
sudo find "/etc/ModemManager/" -type d -exec chmod 0755 {} +
sudo find "/etc/ModemManager/" -type f -exec chmod 0644 {} +
sudo ln -s -f "/usr/share/ModemManager/fcc-unlock.available.d/2c7c" "/etc/ModemManager/fcc-unlock.d/2c7c:0313"

This creates a symlink to the working FCC unlock script 2c7c for the new USB device ID 2c7c:0313 in your local configuration. Hope that helps.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Please use GPLv3 “or-later” instead of “only”                            
                          

                            Posted by Andreas Haerter
                            
                            on May 23, 2024 12:25 AM
                            
                        

                        

                            
It makes sense to prefer copyleft licenses. The most popular copyleft license is probably the GNU General Public License (GPL), with Version 3 from 2007 being the latest one. When you use the GPLv3, you have to decide if you go for “GPL v3.0 or later” or “GPL v3.0 only”. This is because of Clause 14 “Revised Versions of this License” of the GPLv3.1


The clause addresses how future versions of the license will be handled and state that the Free Software Foundation (FSF) may publish new versions of the GPL, which will be similar in spirit to the current version but may include changes to address new legal and technological issues. This also ensures the protection of Free Software from potential missteps by the Free Software Foundation (FSF) itself as, for example, no one could state a valid GPLv4 without copyleft. Some argue that the GPLv3 is fundamentally different from the GPLv2, but a detailed examination shows this is not the case–it is indeed similar in spirit. Just read it for yourself. For our part, we therefore strongly recommend choosing the “or later” option for our own projects.


Learn from past mistakes
Using GPL-2.0-only in the past created significant compatibility issues with other licenses, hindering the integration and distribution of combined works. For example, software licensed under GPL-2.0-only is incompatible with the Apache-2.0 license, preventing the combination of many codebases even today. And some projects had to spend a lot of time and work to change licensing to achieve better license compatibility and reduce integration barriers. These issues can lead to fragmentation and reduced flexibility in the open-source ecosystem.


GPLv2 showed that this adaptability might be necessary, as sticking to GPL-2.0-only did not provide any significant benefit and led to compatibility problems. Therefore, it makes sense to adopt the “or later” option whenever possible. This approach not only preserves the spirit of the license but also provides a safeguard against potential future challenges, much like a well-prepared contingency plan.


Conclusion
The “or later” clause of GPL-3.0-or-later is crucial as it allows the evolution of the license to keep up with changing circumstances, ensuring ongoing protection and freedom for software users and developers. This clause is like a safety net that allows us to adapt to future changes in the legal and technological landscape and to enable cooperation from various parties in the future. Use it.




  1. 

    It is the same with Clause 9 of GPLv2. ↩︎
    

    2. 


                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
mostly unknown keepalived feature                            
                          

                            Posted by Jens Kuehnel
                            
                            on May 22, 2024 08:15 PM
                            
                        

                        

                            
There are lot of introduction to keepalived. Like Setting up a Linux cluster with Keepalived: Basic configuration | Enable Sysadmin (redhat.com) or Keepalived and high availability: Advanced topics | Enable Sysadmin (redhat.com)





But I recently learned that keepalived has a cool feature that makes writing keepalived much easier (Thanks Spindy). Almost all documentation found on the net shows you that you need two different configuration files. But this is not the case. There is an extension that allows you to rollout the same configuration for all nodes.





When you compare this example from the first links. They use this two configurations:









server1# cat /etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
        state MASTER
        interface eth0
        virtual_router_id 51
        priority 255
        advert_int 1
        authentication {
              auth_type PASS
              auth_pass 12345
        }
        virtual_ipaddress {
              192.168.122.200/24
        }
}









server2# cat /etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
        state BACKUP
        interface eth0
        virtual_router_id 51
        priority 254
        advert_int 1
        authentication {
              auth_type PASS
              auth_pass 12345
        }
        virtual_ipaddress {
              192.168.122.200/24
        }
}









When you look at it its almost the same file – only 2 lines are different, state and priority. Here comes the @format into play. You can rollout this file on both side and it will work the same way as above:





# cat /etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
        @server1 state MASTER
        @server2 state BACKUP
        interface eth0
        virtual_router_id 51
        @server1 priority 255
        @server2 priority 254
        advert_int 1
        authentication {
              auth_type PASS
              auth_pass 12345
        }
        virtual_ipaddress {
              192.168.122.200/24
        }
}





So you can configure lines that are only valid for certain hosts by adding a @HOSTNAME in front. More possibilities are explained in the man page keepalived.conf(5) in the section “Conditional configuration and configuration id”

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
syslog-ng Prometheus exporter                            
                          

                            Posted by Peter Czanik
                            
                            on May 22, 2024 11:08 AM
                            
                        

                        

                            
Prometheus is an open-source monitoring system that collects metrics from your hosts and applications, allowing you to visualize and alert on them. The syslog-ng Prometheus exporter allows you to export syslog-ng statistics, so that Prometheus can collect it.


While an implementation in Go has been available for years on GitHub (for more information, see this blog entry), that solution uses the old syslog-ng statistics interface. And while that Go-based implementation still works, syslog-ng 4.1 introduced a new interface that provides not just more information than the previous statistics interface, but does so in a Prometheus-friendly format. The information available through the new interface has been growing ever since.


The syslog-ng Prometheus exporter is implemented in Python. It also uses the new statistics interface, making new fields automatically available when added.


Read more at https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-prometheus-exporter

<figure><figcaption>
            
syslog-ng logo

        </figcaption>
</figure>

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Upgrade of Copr servers                            
                          

                            Posted by Fedora Infrastructure Status
                            
                            on May 22, 2024 09:00 AM
                            
                        

                        

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


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

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Contribute at the Podman 5.1 and Kernel 6.9 Test Week                            
                          

                            Posted by Fedora Magazine
                            
                            on May 21, 2024 05:06 PM
                            
                        

                        

                            
Fedora test days are events where anyone can help make certain that changes in Fedora work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. This is a perfect way to start contributing to Fedora, if you haven’t in the past.









There are two upcoming test periods in the next two weeks covering two topics:





  • Thursday 23 May, is to test the Podman 5.1 
    • 




  • Sunday 26 May through Monday 03 June, is to test Kernel 6.9
    • 

Podman 5.1 Test Day





Podman is a daemon-less, open source, Linux native tool designed to make it easy to find, run, build, share and deploy applications using Open Containers Initiative (OCI) Containers and Container Images. It provides a command line interface (CLI) familiar to anyone who has used the Docker Container Engine. As part of a recent discussion, the Rawhide Test Day efforts, and Podman Container Engine Team’s collaborative efforts, we will hold a test day for a minor Podman Release.





During this test day, on Thursday 23 May, the focus will be on testing the changes that will be coming in Fedora 41 (Rawhide) as we move ahead with Podman 5.1. This test day is an opportunity for anyone to learn and interact with the Podman Community and container tools in general.





The wiki page helps the testers know and understand the scope of the test day. The Test day app helps the testers submit the results once they have tried the test cases.





Kernel 6.9 Test Week





The kernel team is working on final integration for Linux kernel 6.9. This recently released kernel version will arrive soon in Fedora Linux. As a result, the Fedora Linux kernel and QA teams have organized a test week from Sunday, May 26, 2024 to Monday, June 03, 2024. 





The wiki page contains links to the test images you’ll need to participate. The results can be submitted in the test day app.





How do test days work?





A test day/week is an event where anyone can help make sure changes in Fedora Linux work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed before, this is a perfect way to get started.





To contribute, you only need to be able to download test materials (which include some large files) and then read and follow directions step by step.





Detailed information about all the test days is available on the wiki pages mentioned above. If you’re available on or around the days of the events, please do some testing and report your results. All the test day pages receive some final touches which complete about 24 hrs before the test day begins. We urge you to be patient about resources that are, in most cases, uploaded hours before the test day starts.





Come and test with us to make the upcoming Fedora Linux 41 even better

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Fedora Linux 38 s'en va                            
                          

                            Posted by Charles-Antoine Couret
                            
                            on May 20, 2024 10:00 PM
                            
                        

                        

                            
C'est en ce mardi 21 mai 2024 que la maintenance de Fedora Linux 38 prend fin.




Qu'est-ce que c'est ?




Un mois après la sortie d'une version de Fedora n, ici Fedora Linux 40, la version n-2 (donc Fedora Linux 38) n'est plus maintenue.




Ce mois sert à donner du temps aux utilisateurs pour faire la mise à niveau. Ce qui fait qu'en moyenne une version est officiellement maintenue pendant 13 mois.




En effet, la fin de vie d'une version signifie qu'elle n'aura plus de mises à jour et plus aucun bogue ne sera corrigé. Pour des questions de sécurité, avec des failles non corrigées, il est vivement conseillé aux utilisateurs de Fedora Linux 38 et antérieurs d'effectuer la mise à niveau vers Fedora Linux 40 ou 39.




Que faire ?




Si vous êtes concernés, il est nécessaire de faire la mise à niveau de vos systèmes.
Vous pouvez télécharger des images CD ou USB plus récentes.




Il est également possible de faire la mise à niveau sans réinstaller via DNF ou GNOME Logiciels.




GNOME Logiciels a également dû vous prévenir par une pop-up de la disponibilité de Fedora Linux 40 ou 39. N'hésitez pas à lancer la mise à niveau par ce biais.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Kiwi TCMS 13.3                            
                          

                            Posted by Kiwi TCMS
                            
                            on May 20, 2024 01:15 PM
                            
                        

                        

                            
We're happy to announce Kiwi TCMS version 13.3!


IMPORTANT:
This is a small release which contains several improvements, bug fixes,
internal refactoring and updated translations!


Recommended
upgrade
path:


13.2 -> 13.3



You can explore everything at
https://public.tenant.kiwitcms.org!


---




Upstream container images (x86_64):


kiwitcms/kiwi   latest  c43a47e388ab    675MB





IMPORTANT: version tagged and multi-arch
container images are available only to
subscribers!




Changes since Kiwi TCMS 13.2




Improvements


  • Update Django from 4.2.11 to 4.2.12
    • 

  • Update psycopg from 3.1.18 to 3.1.19
    • 

  • Update PyGithub from 1.58.2 to 2.3.0
    • 

  • Update pygments from 2.17.2 to 2.18.0
    • 

  • Update python-gitlab from 4.4.0 to 4.5.0
    • 

  • Replace more inline style= HTML attributes with CSS classes
    • 





Bug fixes


  • Truncate TestCase.text length for Jira 1-click bug reports to avoid
400, 414 and/or 500 errors! Text will be truncated to 30k chars for automated
POST requests and 6k chars for fallback GET requests to fit inside Jira
limitations
    • 





Refactoring and testing


  • Remove double slash in Jira fallback URL
    • 

  • Stop using the Github(login_or_token) argument b/c it is deprecated
    • 

  • Update selenium from 4.20.0 to 4.21.0
    • 








Kiwi TCMS Enterprise v13.3-mt


  • Based on Kiwi TCMS v13.3
    • 

  • Update kiwitcms-github-app from 1.6.0 to 1.7.0
    • 

  • Update sentry-sdk from 2.0.1 to 2.2.0
    • 

  • Preserve /static/ca.crt file inside the container
    • 





Private container images




quay.io/kiwitcms/version            13.3 (aarch64)          0f9f70835859    20 May 2024     686MB
quay.io/kiwitcms/version            13.3 (x86_64)           c43a47e388ab    20 May 2024     675MB
quay.io/kiwitcms/enterprise         13.3-mt (aarch64)       40d0769bc640    20 May 2024     1.05GB
quay.io/kiwitcms/enterprise         13.3-mt (x86_64)        ea3d8e8999f4    20 May 2024     1.03GB





IMPORTANT: version tagged, multi-arch and Enterprise
container images are available only to
subscribers!






How to upgrade


Backup first!
Then follow the
Upgrading instructions
from our documentation.


Happy testing!


---


If you like what we're doing and how Kiwi TCMS supports various communities
please help us grow!



                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Fedora 40 Release Party in Prague                            
                          

                            Posted by Jiri Eischmann
                            
                            on May 20, 2024 11:08 AM
                            
                        

                        

                            
Last Friday I organized a Fedora 40 release party in Prague. A month ago I got a message from Karel Ziegler of Etnetera Core if we could do a Fedora release party in Prague again. Etnetera Core is a mid-sized company that does custom software development and uses Red Hat technologies. They have a really cool office in Prague which we used as a venue for release parties several times in pre-covid times.





We got a bit unlucky with the date this time. It was really terrible weather in Prague on Friday. It was pouring outside. Moreover the Ice Hockey World Championship is taking place in Prague now and the Czech team played against Austria at the time of the release party. These two things contributed to the less than expected attendance. But in the end roughly 15 people showed up.









<figure class="wp-block-image aligncenter size-large">A round table with Fedora swag.<figcaption class="wp-element-caption">Fedora swag for party attendees.</figcaption></figure>




The talk part was really interesting. In the end it took almost 4 hours because there was a lot of discussion. The first talk was mine, traditionally on Fedora Workstation that switched to a long discussion about Distrobox vs Toolbx. As a result of that Luboš Kocman of SUSE got interested in Ptyxis saying that it’s something they may actually adopt, too.









<figure class="wp-block-image size-large">Lukáš Kotek on stage.<figcaption class="wp-element-caption">Lukáš Kotek talking about his legacy computing machine.</figcaption></figure>




The second talk was delivered by Lukáš Kotek who talked about building a retro-gaming machine based on Fedora and Atomic Pi. Several people asked us to provide his slides online, so here they are:





 





<object aria-label="Embed of kotek-fedora-legacy-computing." class="wp-block-file__embed" data="https://enblog.eischmann.cz/wp-content/uploads/2024/05/kotek-fedora-legacy-computing.pdf" data-wp-bind--hidden="!state.hasPdfPreview" style="width:100%;height:600px" type="application/pdf"></object>kotek-fedora-legacy-computingDownload





The third talk was delivered by Karel Ziegler who spoke on the new release of his favorite desktop environment – Plasma 6. The last talk was supposed to be delivered by Ondřej Kolín, but at the beginning of the party we were not sure if he’d make it because he was travelling from Berlin and was stuck in Friday traffic. The first three talks took so long due to interesting discussions that Ondřej arrived just on time for his talk.





He spoke about his experience building a simple app and distributing it on Flathub. This again started an interesting discussion about new and traditional models of Linux app distribution.





In the middle of the party we were joined by Andre Klapper, a long-time GNOME contributor living in Prague, and Keywan Tonekaboni, a German open source journalist who is currently on his holidays travelling on trains around the Czech Republic. We found out that we were taking the same train to Brno next day, so on Saturday we had another two hours for Linux software topics. 🙂





I’d like to thank the Fedora Project for sponsoring my travel to Prague to organize the event and also big thanks to Etnetera Core for providing just perfect venue for the party and sponsoring refreshment (They even had a beer tap!) and the party cake.









<figure class="wp-block-image aligncenter size-medium">Fedora 40 cake<figcaption class="wp-element-caption">Fedora 40 cake.</figcaption></figure>

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Week 20 update                            
                          

                            Posted by Ankur Sinha "FranciscoD"
                            
                            on May 20, 2024 10:47 AM
                            
                        

                        

                            




Open Source Brain


Open Source Brain (OSB) is a web platform for neuroscientists.
Version 1 was focussed on the sharing and archival of biophysically detailed models, standardised in NeuroML.
There are a number of published models on the platform that one can visualise and study there already:



A screenshot of Open Source Brain version 1.
A screenshot of Open Source Brain version 1.




The newer version, version 2 takes it a step further.
Its goal is to be a cloud based integrated research environment where people can store their data and their code in "workspaces", and work in the cloud, requesting as many resources as they need.
This means that people no longer have to set up their own computers/lab servers---the platform will provide the computing infrastructure and the required tools in a web browser.
OSBv2 also indexes a number of data sources to make it easier for researchers to find data and models, such as:



A screenshot of Open Source Brain version 2.
A screenshot of Open Source Brain version 2.




OSBv2 also integrates a number of web applications for users:


We're working on integrating biosimulations.org as another data source now.
This requires adding an adapter to the back end that understands the biosimulations.org API so that it can use it to pull information from there to index.
An initial version has already been implemented.
We now need to test it.




OSBv2: dev environment


Since OSBv2 is cloud based (currently deployed on Google Cloud), it makes use of containers and Kubernetes (our software partners, MetaCell manage our infrastructure and a majority of the development/maintenance of OSB).
The complete platform is also broken down into a number of services.
To test changes and develop, therefore, one has to run a local deployment.
We've documented the steps in our readme, and I've got a script to automate the various steps.


Of course, it's never that simple.
While my script had worked the last time I had tinkered with OSBv2, it didn't work last week and I spent hours trying to figure out why.
I need to continue with that this week too.








Software Working Group


The Software Working Group is an open community working group about all things software.
It's shared by the International Neuroinformatics Co-ordinating Facility and the Organization for Computational Neuroscience.
The idea is simply to have a community for exchange of ideas related to research/neuroscience software development.
The working group is based on GitHub, and open to anyone at all.


Last week, we had a session on SpikeInterface where Pierre Yger presented the tool to the community.
It was recorded, and the recordings should be on the INCF YouTube channel soon.






Fedora


I worked on a few Neuro SIG packages--updates, Fails to Build From Source (FTBFS) issues, and so on.
Not much to report in detail here.



                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Launch Fedora 40 in Microsoft Azure                            
                          

                            Posted by Fedora Magazine
                            
                            on May 20, 2024 08:00 AM
                            
                        

                        

                            
In Fedora 40, Cloud images for Microsoft Azure are directly available in Azure via its new Community Gallery feature. This article will describe how to use these.









Introduction





Starting in Fedora 39, the Fedora Project began producing Cloud images for Microsoft Azure which could be manually uploaded to an Azure tenant. In Fedora 40, these images are available directly in Azure via its new Community Gallery feature.





To use Microsoft Azure, you will need a Microsoft account. New users get 12 months of several services free, including virtual machines, so you can try everything covered in this article without needing to pay for anything. These virtual machines have 1-2 vCPUs and 1 GiB of RAM, which is enough for development or testing, low traffic web servers, small databases, etc.





Using the web portal





To get started, go to the Community images service in the Azure Portal. Add a filter on Public gallery names and select Fedora’s public gallery name, Fedora-5e266ba4-2250-406d-adad-5d73860d958f.




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




Select a Fedora 40 x64 image in a location near you, then click Create VM.




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




Alternatively, you can go to the The Fedora Project’s Cloud section, click Launch in public cloud, and select the Azure region to jump directly to the Create VM blade.





Configure the VM





Click Create new under the Resource group field. Resource groups are buckets of arbitrary resources (virtual machines, storage accounts, public IP addresses, etc.) which are related. Next, give your virtual machine a name. The name you choose becomes the host name as well as the virtual machine resource name in Azure. After that, you should set the virtual machine size. Click See all sizes and type “B2ats_v2” into the search bar, click on the only result, and click Select at the bottom of your screen.




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




 Finally, click Review + create at the bottom of your screen, and then click Create.





Download the SSH key it generates for you. Afterwards, you will be taken to a page where you can see your resources being created. Once they’ve all completed, click on Go to resource. This will take you to the overview page for your new virtual machine running Fedora 40. Under Essentials you’ll find the public IP address assigned to your instance which you can use to SSH to the virtual machine.




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




Open a terminal, ensure the SSH key you downloaded has proper permissions, and log in to your new machine:





chmod 600 ~/Downloads/<key name>
ssh -i ~/Downloads/<key name> azureuser@<pubic IP address>




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




Finally, if you decide you don’t need the machine anymore, you can clean everything up by deleting the resource group. From the virtual machine overview page, click on the resource group name you created under Essentials, then click Delete resource group and confirm you want to delete it. Everything you created in the resource group is destroyed with it.





Launch a virtual machine via azure-cli





You may prefer to manage your resources from the command line. The downside of the CLI is it doesn’t guide you through all the options available. The upside is that, if you know what you want, it’s much quicker than clicking through all the options available. This section covers using the CLI to create the exact same virtual machine as the first section.





Prerequisites 





Install the Azure command-line interface and log in:





sudo dnf install azure-cli
az login





Find the Image ID





We need the Fedora 40 image ID in Microsoft Azure to launch the virtual machine from the CLI. Each Fedora release has an image definition for each hardware architecture. Each image definition contains one or more image versions. We add new image versions with the latest updates on a regular basis. 





First, list all available image definitions in Fedora’s public gallery:





az sig image-definition list-community --public-gallery-name Fedora-5e266ba4-2250-406d-adad-5d73860d958f --location eastus --query '[].name'





Optionally, you can list the versions available using an image definition’s name:





az sig image-version list-community --public-gallery-name Fedora-5e266ba4-2250-406d-adad-5d73860d958f --gallery-image-definition "Fedora-Cloud-40-x64" --location eastus --query '[?!excludeFromLatest].uniqueId'





Typically, you should use the latest available version of an image definition, which you can reference by replacing the version number in the image version’s uniqueId with latest. For example, the image ID for the latest x86_64 Fedora 40 image is /CommunityGalleries/Fedora-5e266ba4-2250-406d-adad-5d73860d958f/Images/Fedora-Cloud-40-x64/Versions/latest.





Create the VM





Begin by creating the resource group:





az group create --location eastus --resource-group fedora-in-azure





Next, create the virtual machine using the image ID we found:





az vm create --location eastus --name fedora40 --resource-group fedora-in-azure --image /CommunityGalleries/Fedora-5e266ba4-2250-406d-adad-5d73860d958f/Images/Fedora-Cloud-40-x64/Versions/latest --size Standard_B2ats_v2 --security-type TrustedLaunch --generate-ssh-keys





Finally, you can delete everything with:





az group delete --resource-group fedora-in-azure





Conclusion





We have covered the basics for creating Fedora virtual machines in Microsoft Azure. For more in-depth coverage of virtual machine features you can refer to the virtual machine documentation for Azure. The Azure CLI documentation is also available online.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Next Open NeuroFedora meeting: 20 May 1300 UTC                            
                          

                            Posted by The NeuroFedora Blog
                            
                            on May 20, 2024 07:26 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 20 May at 1300 UTC.
The meeting is a public meeting, and open for everyone to attend.
You can join us in the Fedora meeting channel on chat.fedoraproject.org (our Matrix instance).
Note that you can also access this channel from other Matrix home severs, so you do not have to create a Fedora account just to attend the meeting.


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 -d 'Monday, May 20, 2024 13:00 UTC'



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


We hope to see you there!

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Week 20 in Packit                            
                          

                            Posted by Weekly status of Packit Team
                            
                            on May 20, 2024 12:00 AM
                            
                        

                        

                            
Week 20 (May 14th – May 20th)​
  • When running dist-git init command from CLI, you can pass a command to specify the git URL of the project. (packit#2308)
  • We have fixed the incorrect displaying of the time it took for the jobs to run on dashboard. (dashboard#408)

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Episode 429 – The autonomy of open source developers                            
                          

                            Posted by Josh Bressers
                            
                            on May 20, 2024 12:00 AM
                            
                        

                        

                            
Josh and Kurt talk about open source and autonomy. This is even related to some recent return to office news. The conversation weaves between a few threads, but fundamentally there’s some questions about why do people do what they do, especially in the world of open source. This also is a problem we see in security, security people love to tell developers what to do. Developers don’t like being told what to do.




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




Show Notes






                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Elections Voting is now Open!                            
                          

                            Posted by Fedora Community Blog
                            
                            on May 19, 2024 11:01 PM
                            
                        

                        

                            
The voting period has now opened for the Fedora Linux 40 elections cycle. Please read the candidate interviews and cast your votes in our Elections App. Visit our Voting Guide to learn how our voting system works, and voting closes at 23:59:59 UTC on May 30th.









Fedora Mindshare Committee





Fedora Mindshare has one seat open. Below is the candidate that will be elected at the end of the voting period.





Fedora Council





The Fedora Council has two seats open. Below are the candidates eligible for election.





Fedora Engineering Steering Committee (FESCo)





The Fedora Engineering Steering Committee (FESCo) has four seats open. Below are the candidates eligible for election.





EPEL Steering Committee





The EPEL Steering Committee has four seats open. Below are the candidates eligible for election.





The post Elections Voting is now Open! appeared first on Fedora Community Blog.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
EPEL Steering Committee Election: Troy Dawson (tdawson)                            
                          

                            Posted by Fedora Community Blog
                            
                            on May 19, 2024 10:56 PM
                            
                        

                        

                            
This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.









Interview with Troy Dawson





  • FAS ID: tdawson
    • 

Questions





What is your background in EPEL? What have you worked on and what are you doing now?





I started contributing to EPEL 11 years ago with some nodejs packages for OpenShift. I later added rubygems and golang packages as OpenShift changed languages. Later, RHEL 8 did not have KDE, so I added KDE to epel8, and have been maintaining KDE in epel ever since. I have picked up many other packages during the years, but I think my KDE contributions are what I am most known for.





I’ve been the EPEL Steering Committee chair since 2020, taking over from Stephen Smoogen. A lot of changes have happened since then, most of them for the better. I’m not responsible for all the changes, but it’s been wonderful being part of the committee as these changes have come through.





Why are you running for EPEL Steering Committee Member?





EPEL has grown to be part of my professional and personal life. I not only want to contribute to it, but help steer it’s growth and progression. I think as a EPEL Steering Committee member, I can help keep EPEL healthy and thriving.


The post EPEL Steering Committee Election: Troy Dawson (tdawson) appeared first on Fedora Community Blog.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
EPEL Steering Committee Election: Interview with Robby Callicotte (rcallicotte)                            
                          

                            Posted by Fedora Community Blog
                            
                            on May 19, 2024 10:55 PM
                            
                        

                        

                            
This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.









Interview with Robby Callicotte





  • FAS ID: rcallicotte
    • 

Questions





What is your background in EPEL? What have you worked on and what are you doing now?





I’ve been an EPEL user since the mid 2000s and a package maintainer since 2021. I brought Saltstack back into EPEL and added a nifty linter for salt states called salt-lint. I am currently working on building all the dependencies for the upcoming pagure 6 release.





Why are you running for EPEL Steering Committee member?





EPEL packages account for millions of downloads per week and are a vitally important part of the Enterprise Linux ecosystem. I earnestly believe in the project’s mission and am eager to contribute my skills and acumen to its success. I am excited about the opportunity to serve the EPEL community and help shape its future direction.


The post EPEL Steering Committee Election: Interview with Robby Callicotte (rcallicotte) appeared first on Fedora Community Blog.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
EPEL Steering Committee Election: Interview with Neil Hanlon (neil)                            
                          

                            Posted by Fedora Community Blog
                            
                            on May 19, 2024 10:55 PM
                            
                        

                        

                            
This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.









Interview with Neil Hanlon





  • FAS ID: neil
    • 

What is your background in EPEL? What have you worked on and what are you doing now?





I’ve been a consumer of EPEL for more than a decade as I learned Linux and began my career—first in web hosting, then “DevOps”, and eventually being responsible for the network architecture and infrastructure for a large travel company. In the past four years, I helped to found the Rocky Linux project, where I became friends with Pablo Greco who encouraged me to participate in EPEL more actively, and I continue to maintain its various components, which involves significant Fedora and EPEL work as well as contributions to other upstream projects.





For over a year now, I have been a Fedora and EPEL packager and actively participate in EPEL Steering Committee meetings weekly. Most of the packages I maintain or contribute to are related to needs in the Rocky Linux project or are personally useful to me—such as remind, a calendar and alarm program that helps me stay organized, or passwdqc, a powerful password quality and policy enforcement toolkit that is especially useful in managing EL-based FreeIPA environments.





While I enjoy packaging, I find the most rewarding aspect of my work in EPEL to be mentoring and encouraging others to become Fedora and/or EPEL packagers. Growing the community and ecosystem of EL developers is crucial to the longevity of Enterprise Linux as a whole. Expanding the base of EPEL contributors not only strengthens EPEL but also benefits the broader Fedora developer community and can lead to more employer-sponsored contributions to Open Source.





In the coming months, I plan to introduce several cloud and HPC-related packages to Fedora and EPEL. I also aim to finalize a number of packages that are being introduced to Fedora following discussions in the #epel IRC channel, which I hope will bring in new Fedora and EPEL package maintainers.





Why are you running for EPEL Steering Committee member?





I am running for the EPEL Steering Committee to help foster growth and increase activity within Extra Packages for Enterprise Linux (EPEL). EPEL is unique in its commitment to stability and freedom from unnecessary disruptions, mirroring the principles of RHEL. While enabling Fedora packages for Enterprise Linux is a significant goal, EPEL goes further by ensuring that updates and newly introduced packages uphold this stability.





Maintaining packages for EPEL can be daunting for many maintainers, particularly those new to Fedora packaging guidelines, policies, and workflows. This initial hurdle is crucial to understand the different layers of policy between Fedora and EPEL, which make EPEL a unique and valuable project. EPEL has a large user base because of the immense utility it provides, and growing the footprint of EPEL maintainers is crucial for the project’s long-term health.


The post EPEL Steering Committee Election: Interview with Neil Hanlon (neil) appeared first on Fedora Community Blog.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
EPEL Steering Committee Elections: Interview with Kevin Fenzi (kevin)                            
                          

                            Posted by Fedora Community Blog
                            
                            on May 19, 2024 10:54 PM
                            
                        

                        

                            
This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.









Interview with Kevin Fenzi





  • FAS ID: kevin
    • 

Questions





What is your background in EPEL? What have you worked on and what are you doing now?





I’ve been involved in epel since the epel-5/6 days. With epel7 I wrangled a bunch of the work to get things setup, including beta before the rhel release, lots of release engineering work and mirroring/content. I maintain a lot of packages in EPEL, both for others use and to use in Fedora Infrastructure, which heavily uses epel for managing items that are not in rhel proper. I’ve been happy to see epel continue to grow and flourish and these days I tend to just provide some light releng work for epel along with package maint. epel is a wonderful service and I think it really increases the usefulness of rhel and downstreams.





Why are you running for EPEL Steering Committee member?





I think I provide a useful historical perspective on how things were setup and why, along with a release engineering perspective on how changes could be done or might affect composes.


The post EPEL Steering Committee Elections: Interview with Kevin Fenzi (kevin) appeared first on Fedora Community Blog.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
EPEL Steering Committee Election: Interview with Jonathan Wright (jonathanspw)                            
                          

                            Posted by Fedora Community Blog
                            
                            on May 19, 2024 10:53 PM
                            
                        

                        

                            
This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.









Interview with Jonathan Wright





  • FAS ID: jonathanspw
    • 

Questions





What is your background in EPEL? What have you worked on and what are you doing now?





I’ve been working with EPEL since its inception – having been a user of “Enterprise Linux” since CentOS 4. I became a Fedora packager a few years ago with an explicit interest in the EPEL side of things. Little did I know I’d also end up caring greatly about the Fedora side and I came back from the dark side (Arch) and am a Fedora desktop user again.





I’m the infrastructure lead for AlmaLinux and through that have a great care for EPEL and everything it empowers users to do – not just for AlmaLinux but for the EL community at large.





Why are you running for EPEL Steering Committee member?





I feel strongly that I can help steer the direction of EPEL due to my experience in the ecosystem.


The post EPEL Steering Committee Election: Interview with Jonathan Wright (jonathanspw) appeared first on Fedora Community Blog.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
EPEL Steering Committee Election: Interview with Carl George (carlwgeorge)                            
                          

                            Posted by Fedora Community Blog
                            
                            on May 19, 2024 10:52 PM
                            
                        

                        

                            
This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.









Interview with Carl George





Questions





What is your background in EPEL? What have you worked on and what are you doing now?





I got my start in Fedora and EPEL back in 2014. I joined a new team at Rackspace whose primary purpose was to maintain IUS, a third-party package repository for RHEL. Packages in this repository were typically based on Fedora packages. Some of these packages had dependencies in EPEL. We also maintained several other packages in EPEL that were important to our customers. I continued on as a regular EPEL contributor, even after I left Rackspace in 2019 to join the CentOS team at Red Hat. In 2021, I started a new team at Red Hat to specifically focus on EPEL activities.





In 2020 and 2021, I designed and lead the implementation of EPEL Next, an optional repository for EPEL maintainers to perform builds against CentOS Stream when necessary. Also in 2021, I lead the implementation of EPEL 9. This brought some significant improvements over previous EPEL versions. We utilized CentOS Stream 9 to launch EPEL 9 about six months before RHEL 9. This resulted in RHEL 9 having more EPEL packages available at its launch (~5700) than any previous release, helping ensure a positive user and customer experience. If you want to learn more about EPEL Next and EPEL 9, I suggest watching my conference presentation “The Road to EPEL 9“.





Currently I’m leading the implementation of EPEL 10, which will include more improvements over previous EPEL versions. The plan is for EPEL 10 to have minor versions, obsoleting the previous EPEL Next model. This will allow us to better target specific minor versions of RHEL 10, as well as CentOS Stream 10 as the leading minor version. You can learn more about this plan in my conference presentation “EPEL 10 Overview“.





Aside from the hands-on technical work of EPEL architecture and packaging, I have engaged in various other efforts to promote visibility and awareness of EPEL, and to communicate with our users and contributors.





  • Organized the first EPEL survey, which provided valuable feedback to improve packager workflows and the onboarding experience
    • 




  • Started a monthly “EPEL office hours” video call, which is open for anyone to attend to discuss EPEL topics
    • 




  • Presented about EPEL and related topics at conferences
    • 




  • Interviewed about EPEL and related topics on podcasts
    • 

Why are you running for EPEL Steering Committee member?





I have been on the EPEL Steering Committee since I was appointed to it 
in 2020.  As part of implementing elections for the committee, myself 
and other members agreed to “step down” and essentially run for 
re-election.  I have enjoyed my four years serving on the committee, and
 hope to have the opportunity to continue to serve the EPEL community.  I
 am passionate about EPEL and I am committed to continue finding ways to
 improve the EPEL experience for both users and contributors.


The post EPEL Steering Committee Election: Interview with Carl George (carlwgeorge) appeared first on Fedora Community Blog.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
FESCo Elections: Interview with Tom Stellard (tstellar)                            
                          

                            Posted by Fedora Community Blog
                            
                            on May 19, 2024 10:47 PM
                            
                        

                        

                            
This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.









Interview with Tom Stellard





  • FAS ID: tstellar
    • 




  • Matrix Rooms: devel, fedora-ci
    • 

Questions





Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?





I have a background in compilers and toolchains, and I would like to use some of the knowledge I’ve gained over the years of building and troubleshooting applications to help make Fedora better. Specifically, I’m interested in helping packagers avoid making common mistakes through standardized macros and packaging practices and also by increasing the reliance on CI.





How do you currently contribute to Fedora? How does that contribution benefit the community?





I’m currently one of the maintainers of the LLVM packages in Fedora which is a set of 14 packages that provide a C/C++/Fortran compilers as well as a set of reusable compiler libraries that are used for developing other languages and for developer tools, like IDEs.





I’ve also worked on two system wide change requests to help standardize the use of make within Fedora packages. These changes helped to make spec files more consistent across all of Fedora and also made it possible to remove make from the default buildroot.





How do you handle disagreements when working as part of a team?





When I am in a leadership role, like FESCO, and there is a disagreement, the first thing I do is make sure I understand the problem and the potential solutions. This usually requires having a discussion between all interested parties either on a mailing list, chat platform, or video call. Many times disagreements are simply the result of misunderstandings, so getting everyone together to discuss the issue in the same place can lead to a consensus decision and avoid the need for someone in leadership to get involved.





However, if consensus cannot be reached, once I like to try to get some third party opinions from people who have not been directly involved with the discussions. Once I feel comfortable I have enough information and am ready to make a decision, I make sure I am able to explain in writing why the decision was made and then I communicate the decision to all the stakeholders. It’s always important to have a written record of why a decision was made in case it needs to be revisited in the future.





What else should community members know about you or your position





I work for Red Hat on the Platform Tools team. I am the technical lead for our LLVM team and the overall technical lead for the Go/Rust/LLVM compiler group. This means that I work on packaging, bug fixing and upstream feature development for LLVM and work on high-level technical issues common across all 3 compilers.


The post FESCo Elections: Interview with Tom Stellard (tstellar) appeared first on Fedora Community Blog.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
FESCo Elections: Interview with Stephen Gallagher (sgallagh)                            
                          

                            Posted by Fedora Community Blog
                            
                            on May 19, 2024 10:46 PM
                            
                        

                        

                            
This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.









Interview with Stephen Gallagher





Questions





Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?





I’ve been a member of FESCo for many years now, and it’s been a great experience. It gives me the opportunity to see a much wider view of the project than just the pieces I would otherwise contribute to.





As for steering the direction of Fedora, I think I would mostly just continue to do as I have been doing: pushing for Fedora to continue to be both the most advanced and one of the most stable open-source distributions in the world.





How do you currently contribute to Fedora? How does that contribution benefit the community?





Aside from my work on FESCo, I am also acting as the Lead on the Fedora ELN project, which is a prototype of what will eventually be the next major release of Red Hat Enterprise Linux. We recently branched off CentOS Stream 10 from Fedora ELN, so we’re now looking to the future (and CentOS Stream 11!). Performing these activities in the public provides both an opportunity for the community to be involved with the creation of Red Hat Enterprise Linux as well as painting a clear picture of Fedora’s value to Red Hat, our primary sponsor.





Additionally, I have been acting as a primary administrator for the CentOS Stream Gitlab instance and I intend to volunteer my experience to help with the upcoming dist-git migration discussions.





How do you handle disagreements when working as part of a team?





First and foremost, I always strive for consensus. Most disagreements are not fundamental differences between people. Instead, they tend to be more nuanced. My goal (particularly within my FESCo service) is to make sure that everyone’s opinion is heard and considered; I then try to figure out how to meet in the middle.





Of course, not every decision can be resolved with consensus. In the event that a true impasse is reached, that’s the point where I usually advocate for calling a vote and proceeding with the majority opinion. On the whole, I believe that democratic decision-making is the best solution that humanity has come up with for resolving otherwise-insoluble disagreements.





What else should community members know about you or your positions?





Just so it’s very clear, I’m a Red Hat employee. My day-job at Red Hat is to organize and improve the processes we use to kick off development of the next major RHEL release. As such, my stances on FESCo will often represent my opinion of what will make that effort operate more smoothly. So, no matter how entertaining it might be, we’re not going to be replacing the entire contents of /usr/share/icons with the Beefy Miracle icon.


The post FESCo Elections: Interview with Stephen Gallagher (sgallagh) appeared first on Fedora Community Blog.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
FESCo Elections: Interview with Neal Gompa (ngompa)                            
                          

                            Posted by Fedora Community Blog
                            
                            on May 19, 2024 10:45 PM
                            
                        

                        

                            
This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.









Interview with Neal Gompa





  • FAS ID: ngompa
    • 




  • Matrix Rooms: #devel:fedoraproject.org, #asahi:fedoraproject.org, #asahi-devel:fedoraproject.org, #kde:fedoraproject.org, #workstation:fedoraproject.org, #cloud:fedoraproject.org, #kernel:fedoraproject.org #centos-hyperscale:fedoraproject.org, #okd:fedoraproject.org, #budgie:fedoraproject.org, #multimedia:fedoraproject.org, #miracle:fedoraproject.org, #cosmic:fedoraproject.org, #centos-kernel:fedora.im, #admin:opensuse.org, #chat:opensuse.org, #bar:opensuse.org, #obs:opensuse.org, #RedHat:matrix.org, #networkmanager:matrix.org, #rpm:matrix.org, #rpm-ecosystem:matrix.org, #yum:matrix.org, #manatools:matrix.org, #lugaru:matrix.org, #buddiesofbudgie-dev:matrix.org, #PackageKit:matrix.org, #mir-server:matrix.org, #mageia-dev:matrix.org
    • 

(There’s quite a bit more, but I think that sort of covers it. 😉)





Questions





Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?





As a long-time member of the Fedora community as a user and a contributor, I have benefited from the excellent work of many FESCo members before me to ensure Fedora continues to evolve as an amazing platform for innovation. For the past few years, I have had the wonderful privilege of serving as a member of FESCo for the first time, and I enjoyed my time serving to steer Fedora into the future, and I wish to continue to contribute my expertise to help analyze and make good decisions on evolving the Fedora platform.





How do you currently contribute to Fedora? How does that contribution benefit the community?





The bulk of my contributions to Fedora lately are on the desktop side of things. Following on the work I did to improve Fedora’s multimedia capabilities, we now have a SIG that takes care of bringing in and updating multimedia software into Fedora. The successful bring-up of the Fedora Asahi Remix by the Asahi SIG to support Fedora Linux on Apple Silicon Macs has brought notoriety and several new contributors to the community. Most recently, I am mentoring new contributors to support the development of the Fedora Miracle Window Manager and the Fedora COSMIC efforts, including assisting in setting up SIGs and guiding them in the processes to support their work.





Beyond the desktop and more into the clouds, I helped revamp the tooling for creating Fedora Cloud images as well as the base Vagrant and container images to leverage the new KIWI image build tool, which enables both Fedora Cloud contributors and third parties to much more easily build things leveraging Fedora Cloud content. This has led to renewed interest from folks who work in public clouds, and we’ve started seeing contributions from notably Microsoft Azure now.





My hope is that the work I do helps with making the experience using and contributing to Fedora better than it was ever before and that Fedora’s technical leadership in open source draws in more users and contributors.





How do you handle disagreements when working as part of a team?





I attempt to explain my viewpoint and try to build consensus through persuasion and collaboration. If there isn’t a path to consensus as-is, I try to identify the points of disagreement and see if there is a way to compromise to resolve the disagreement. Generally, this ultimately results in a decision that FESCo can act on.





What else should community members know about you or your positions?





To me, the most important thing about Fedora is that we’re a community with a bias for innovation. Our community looks to solve problems and make solutions available as FOSS, and this is something that Fedora uniquely does when many others take the easy path to ship old software or nonfree software everywhere. We work with tens of thousands of projects to deliver an amazing platform in an easily accessible and open fashion, built on FOSS infrastructure and tools. This makes Fedora special to me, and we should continue to hold ourselves to that high standard.





I’m also a big believer in community bonds and collaboration, which is why people tend to find me all over the place. I’m involved in Asahi Linux, CentOS, openSUSE, and several other similar projects in leadership roles as well as a contributor in order to demonstrate my commitment to this philosophy.


The post FESCo Elections: Interview with Neal Gompa (ngompa) appeared first on Fedora Community Blog.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
FESCo Elections: Interview with Michel Lind (salimma)                            
                          

                            Posted by Fedora Community Blog
                            
                            on May 19, 2024 10:44 PM
                            
                        

                        

                            
This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.









Interview with Michel Lind





Questions





Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?





I have been a Fedora contributor since the very beginning – circa 2003-4 – and over the years have contributed on the packaging side, as an Ambassador (I can still remember burning CDs and shipping them via the local post office), and more recently on the policy side with Fedora (starting the Lua SIG) and EPEL (reestablishing the EPEL Packagers SIG, establishing a workflow for escalating stalled EPEL requests).





I am fortunate enough to have a day job at a company (Meta) that heavily uses CentOS Stream and contribute to many core Linux projects, where my main focus is on upstream work – so if the Fedora community entrusts me with this position, I hope to advocate for Change Proposals that advance Fedora’s four foundations (Freedom, Friends, Features, and First) – while accepting that not all Fedora features can be supported in CentOS Stream and RHEL. I feel that having experience in packaging software and working on tooling and workflows across Fedora, EPEL and CentOS Stream gives me a vantage point where I can understand where different parts of the community are coming from.





How do you currently contribute to Fedora? How does that contribution benefit the community?





I am a proven packager (using it to help out with mass rebuilds or to help out fixing major issues) and a packager sponsor, a member of several packaging SIGs (Go, Lua, Python, Rust) and several SIGs that bridge the gaps between Fedora, CentOS Stream, and RHEL (ELN, which is a rebuild of Rawhide with EL macros; EPEL, which provides extra packages for EL distros; and on the CentOS side, the CentOS Hyperscale SIG, which provides faster-moving backports and additional functionalities (typically sourced from Fedora) for use on top of CentOS Stream.





I wrote ebranch to help with branching Fedora packages to EPEL and heavily use it in bootstrapping EPEL 9; a rewrite is in the work to turn it into a suite of related tools for dependency graph management, branching, and inventory tracking.





I have done, and am working on, various Change Proposals.





Oh, and I helped migrate my company’s Linux desktops to Fedora (Flock 2019), FOSDEM 2021










How do you handle disagreements when working as part of a team?





I have been vilified because of where I work; I have learned to accept that people might have very strong opinions on certain issues that they won’t budge on, whether the opinions are (IMHO) justified or not, and still find a way to be civil and collaborate on topics of shared interest.





What else should community members know about you or your positions?





I have been a part of the Fedora community (and before that, a user of Red Hat Linux doing my own rebuilds) for several decades; my involvement predates and outlasts working for several employers (some of them not RPM shops). I am also a Debian Maintainer – and I hope to bring my experience contributing to different distributions to inform FESCo discussions. I dislike NIH (not invented here); ideas should stand on their own merits and it is good to learn from others (both adopting good ideas and avoiding past mistakes).


The post FESCo Elections: Interview with Michel Lind (salimma) appeared first on Fedora Community Blog.

                        

                    

                  

              

            

          

          

            

                  

            

              

                  

                      

                        

                          

                            
Council Election: Interview with Sumantro Mukherjee (sumantrom)                            
                          

                            Posted by Fedora Community Blog
                            
                            on May 19, 2024 10:39 PM
                            
                        

                        

                            
This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 20th May and closes promptly at 23:59:59 UTC on Thursday, 30th May 2024.









Interview with Sumantro Mukherjee





  • Fedora Account: sumantrom
    • 




  • Matrix Rooms: #fedora,#fedora-kde,#fedora-mindshare,#fedora-social,#fedora-social-hour, #fedora-arm,#fedora-devel,#fedora-qa,#fedora-workstation,#fedora-test-days, #fedora-i3,#fedora-badges,#fedora-docs,#fedora-l18n,#fedora-ambassadors)
    • 

Questions





Why are you running for Fedora Council?





I hail from APAC (India) and would like to focus on bringing in more non-US perspectives, which includes bringing in more contributors from diverse backgrounds. Efficient utilization of our brand new design assets which are now in multiple languages (Hindi, for example) to onboard variety of users (general and power-users) to the Fedora community as contributor either to functional sides (QA, packaging..etc) and/or outreach.
In the recent past; the council charter has been expanded to an Executive Sponsor. This role enables people like me to work closely with an upcoming initiative.
In parallel, I am closely working on Blueprints (https://discussion.fedoraproject.org/t/introducing-fedora-change-proposal-blueprints-in-association-with-fedora-qa/115903)
this is a long term effort and will benefit from my connections with people in Council (ie FESCo rep and FESCo at large)





The Fedora Strategy guiding star is that the project is going to double its contributor base by 2028. As a council member, how would you help the project deliver on that goal?





As a council member, I would work closely with teams which will need more attention building pipelines for onboarding, mentoring and retention of contributors. In Fedora QA, I have worked extensively to handle a high influx of contributors and retain them for at least a Release Cycle or two. I have optimized workflows that have been helping Fedora QA to grow optimally without burning out contributors or team members. I could help solve problems and coordinate closely with CommOps and other teams to build data-driven contributor pipelines to help Fedora Project double its contributors by 2028.





How can we best measure Fedora’s success?





However, there is no specific way to measure, BUT.. here’s something I think can define Fedora’s success the best
Fedora Linux’s success is measured by the people who use Fedora.
Fedora Project stands as the reference for the people who want to build an upstream community diverse and strong.
Fedora Project at its core is composed of people who take pride in packaging, testing, designing, translating, blogging, evangelizing and collaborating across the globe.
Fedora project takes pride in being a trendsetter for bringing technologies which impact a large downstream ecosystem and embolden their trust in our four foundations.





What is your opinion on Fedora Editions – what purpose do they serve? Are they achieving this purpose? What would you change?





Fedora Editions are Fedora Project’s flagships. They are exclusively tested and tried by Fedora’s in-house QA team to deliver on the expectations of tens of thousands of users. These platforms serve as building blocks for the Fedora Project to share innovation across multiple downstream ecosystems. Fedora Edition has more room to grow in terms of adoption in CI platforms and pre-installs for Hardware Makers. I would love to drive the adoption of Fedora not only at an organizational level ; but also in schools, universities and next-gen digital influencers.





The Fedora Council is intended to be an active working body. How will you make room for Council work?





As a long-term member, the Council is a body which in the coming days will be working across many facades of the Project, taking bold decisions to make our community
more robust, productive and healthy. Being a long-term member, I support the goals and I’ve prepared my upcoming work cycles such that I have room to spend time
at the Council position.
The aforementioned changes in accordance with 2028 strategy impacts my role in Fedora Project at large and I will always want to be a stakeholder. This will help drive decisions which help the Quality teams day to day operations.


The post Council Election: Interview with Sumantro Mukherjee (sumantrom) appeared first on Fedora Community Blog.

                        

                    

                  

              

            

          

        

      

  

    
© 2016 Red Hat, Inc. and others. Please send any comments or corrections to the websites team.

    
The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community maintained site. Red Hat is not responsible for content.

    
Your words are your own, duh. Nothing here represents Fedora™, Red Hat, Inc, or pretty much anything else. If you think it does then you are badly misled