devel

devel@lists.centos.org

18 participants
4603 discussions

December 2024 News
by Shaun McCance 20 Dec '24

20 Dec '24

Hi all, For your holiday reading, the December newsletter is now available: https://blog.centos.org/2024/12/december-2024-news/ Cheers, Shaun

1 0

December Board Meeting Recap
by Shaun McCance 19 Dec '24

19 Dec '24

The recording of the December CentOS Board meeting is now available. Recording: https://youtu.be/8ficzt0l-xo Minutes: https://hackmd.io/@centosboard/S1ta-46Xkx Recap: https://blog.centos.org/2024/12/centos-board-meeting-recap-december-2024/ The recording has timestamps so you can skip to the parts that interest you. Here are a few highlights of the meeting: * Firefox is not in CentOS Stream 10. We discussed ways of getting web browsers, and documenting them. * The board discussed disabling GitLab Duo on CentOS repositories. * The community architect provided an update on CentOS Connect and the efforts to revamp the web and docs. * The board discussed encouraging SIGs to use GitLab by default. Thanks, Shaun

1 0

CentOS bootc images - Where should they go
by Troy Dawson 08 Dec '24

08 Dec '24

The CentOS Alternative Images SIG has recently been asked about making CentOS bootc images.[1] Investigation is showing that we should be able to. But that leads to the next question. After we build them, where would they go? (A) Initial thoughts are someplace in the CentOS SIG infrastructure. But there currently isn't anything setup for serving containers. It's also not the first place people would look. I was thinking of having them on quay.io. But if we do publish our bootc/container images on quay.io, where? (B) centos:<some-name> ? That would mean that the SIG's would have access to that account. I also don't know what we would have for <some-name>. We would have to have something different for each SIG. (C) centos-sig:<some-name> ? The SIG's would still have to share authentication in some manner. I still don't know what to do for the names. (D) centos-<sig-name>:<some-name> The SIG's would have their own authentication. The sig's would have control of their own naming convention. centos-altimages:stream10-bootc centos-altimages:stream10-bootc-kde centos-isa:stream9-bootc-baseline centos-isa:stream9-bootc-optimized There are some drawbacks for this. Someone would have to know the SIG name to find the image. Possibly other things. I personally am leaning towards (D). But I could be persuaded towards the others. And it's possible I haven't even thought of the correct solution. Ideas / thoughts / comments welcomed and wanted. Troy [1] - https://pagure.io/centos-sig-alt-images/sig/issue/10

6 6

centos-release-nfv-openvswitch broken
by kfox1111＠gmail.com 05 Dec '24

05 Dec '24

$ podman run -it --rm quay.io/centos/centos:stream9 [root@5a60bfec416f /]# yum install -y centos-release-nfv-openvswitch <snip> [root@5a60bfec416f /]# yum list CentOS Stream 9 - NFV OpenvSwitch 916 B/s | 3.0 kB 00:03 Errors during downloading metadata for repository 'centos-nfv-openvswitch': - Downloading successful, but checksum doesn't match. Calculated: a0898eb5ec407553a28821d486e5635b512ea30dd5a170ac76843e8139908887d7773e08d76346e069cebf2e24730648ecdc10595ba5aa6173884fef3d76f4e9(sha512) Expected: 19f066708fc1f00703fa6514d39edebc74fd3aaff9488a2e1fc2599485fdb8775b8af2a912913a2131f6529fe92d60efa1051a4e14fe32eb01d357a1e51c3a86(sha512) Error: Failed to download metadata for repo 'centos-nfv-openvswitch': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried

3 2

Re: devel Digest, Vol 237, Issue 3
by Pierre De Jager 25 Nov '24

25 Nov '24

Please unsubscribe me On Mon, Nov 25, 2024 at 5:41 PM <devel-request(a)lists.centos.org> wrote: > Send devel mailing list submissions to > devel(a)lists.centos.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > devel-request(a)lists.centos.org > > You can reach the person managing the list at > devel-owner(a)lists.centos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of devel digest..." > > Today's Topics: > > 1. CentOS bootc images - Where should they go (Troy Dawson) > 2. Re: CentOS bootc images - Where should they go (Neal Gompa) > 3. Re: CentOS bootc images - Where should they go (Troy Dawson) > 4. Re: CentOS bootc images - Where should they go (Fabian Arrotin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 25 Nov 2024 07:00:54 -0800 > From: Troy Dawson <tdawson(a)redhat.com> > Subject: [CentOS-devel] CentOS bootc images - Where should they go > To: "The CentOS developers mailing list." <centos-devel(a)centos.org> > Message-ID: > < > CAKndyURTg52b6JwzgjddYDiW-gE9b6-RB30GL7ejz6NxcgBO6w(a)mail.gmail.com> > Content-Type: multipart/alternative; > boundary="00000000000077ac470627be00b8" > > The CentOS Alternative Images SIG has recently been asked about making > CentOS bootc images.[1] > > Investigation is showing that we should be able to. But that leads to the > next question. After we build them, where would they go? > > (A) Initial thoughts are someplace in the CentOS SIG infrastructure. But > there currently isn't anything setup for serving containers. It's also not > the first place people would look. > > I was thinking of having them on quay.io. > But if we do publish our bootc/container images on quay.io, where? > > (B) centos:<some-name> ? > That would mean that the SIG's would have access to that account. > I also don't know what we would have for <some-name>. > We would have to have something different for each SIG. > > (C) centos-sig:<some-name> ? > The SIG's would still have to share authentication in some manner. > I still don't know what to do for the names. > > (D) centos-<sig-name>:<some-name> > The SIG's would have their own authentication. > The sig's would have control of their own naming convention. > centos-altimages:stream10-bootc > centos-altimages:stream10-bootc-kde > centos-isa:stream9-bootc-baseline > centos-isa:stream9-bootc-optimized > There are some drawbacks for this. Someone would have to know the SIG name > to find the image. Possibly other things. > > I personally am leaning towards (D). But I could be persuaded towards the > others. And it's possible I haven't even thought of the correct solution. > > Ideas / thoughts / comments welcomed and wanted. > > Troy > > [1] - https://pagure.io/centos-sig-alt-images/sig/issue/10 >

1 0

2024-11-13 - CentOS Public Board Meeting
by Thomas Oulevey 07 Nov '24

07 Nov '24

Hi Everyone, Our next board meeting will take place at 21:00 UTC next Wednesday `date -d "2024-11-13 21:00 UTC"` If you would like to attend please send me an email to alphacc(a)centosproject.org ( please do not reply to @centos-devel or use another email address) and you will receive a link to a meeting room with a passcode, 1 hour before the meeting takes place. The agenda can be checked at (work in progress) : https://hackmd.io/@centosboard/SJDtP3cZJe As a reminder we will enforce few rules : * Wait to be recognized by the Chair before speaking * Respect the Chair when told your time to speak is over - this will allow us to remain on agenda, and complete the meetings in the allotted time * In the event that there are Board-confidential topics, these will be put at the end of the meeting, in Executive Session, and guests will be asked to leave. We hope to minimize these items, but they do sometimes happen. The most common scenarios in which this may happen are personnel issues, or information that Red Hat wishes to share with the Board, but is not yet public. * Muting of participants, or, in extreme situations, ejection from the meeting, is at the sole discretion of the Chair. * Meetings will be recorded, and published to YouTube (possibly with edits/redaction, as approved by the Directors). Thus, by joining the meeting you consent to have your presence at the meeting, and anything you say during the meeting, made public. I hope some of you can join. thanks, -- Thomas 'alphacc' Oulevey CentOS Board of Directors Secretary alphacc(a)centosproject.org

1 0

[FYI] : all CBS koji builders now reinstalled on el9
by Fabian Arrotin 05 Nov '24

05 Nov '24

Sending this ticket for awareness : In the last days, I had time to disable some koji builders (https://cbs.centos.org/koji/hosts) , reinstall/migrate these from el8 to el9, and enable these builders back in the available pool. It finished today [1] and so all builders, all architectures are now running el9.4 . Only the kojihub infra is still running on el8 but that will be migrated later (kojihub itself doesn't have any impact on build infrastructure). The main reason why we updated was to ensure we'd be running a newer kernel for the systemd-nspawn isolation, that was causing troubles when running on top of el8 (kernel 4.18) , especially when relying on likcapi calls from within the chroot'ed build env. For more details and workaround (not needed anymore) that we used to allow building CentOS Stream 10 pkgs for SIGs, see [2] At the same time, what triggered also the reinstall was also the need to re-balance workload across different hardware/chassis [3] : the x86_64 kojid builders are in fact running on some un-warrantied (and older) machines and I wanted to reconfigure similar machines dedicated previously for some other things (including CI / on-premises openshift cluster / etc) to ensure that we'd still have some x86_64 builders running behind https://cbs.centos.org, should we encounter a whole chassis hardware failure . Same for some small services used by koji builders themselves (like small cache/proxy to retrieve external content, like gitlab.com - now spread across two distinct hardware with ucarp and floating ip address[es] for ha purposes) You'll see that we have now more x86_64 builders, and that some tasks (like createrepo, rebuildSRPM, etc) are exclusively targeted on these hosts, freeing some cpu cycles from aarch64/ppc64le/s390x builders, that will be only used for specific rpmbuild tasks. Also worth knowing that I was able (due to decommissioned cores/memory that was used for centos stream 8/centos linux 7) to extend/tune number of cores/available memory on reinstalled aarch64 and ppc64le koji builders, hopefully helping to build faster your SIGs packages for these architectures. Nothing is required from you, SIGs builders, as the whole migration happened transparently , without any downtime, so just enjoy more compute capacity / redundancy for https://cbs.centos.org (and let's hope that we'll not suffer from hardware failure in the future) [1] https://pagure.io/centos-infra/issue/1505 [2] https://pagure.io/centos-infra/issue/1474 [3] https://pagure.io/centos-infra/issue/1528 -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

1 0

Board Nominations Requested
by Shaun McCance 04 Nov '24

04 Nov '24

** Please read this entire email before responding with nominations. ** We have a process, and the process is important. Recently, Brian Exelbierd notified the CentOS board that he will be moving on from his role as Red Hat Liaison. The Red Hat Liaison role is special: it is the only board seat appointed by and speaking for Red Hat. All other board members are at-large and speak for themselves. Brian's role will be backfilled, but until it is, Josh Boyer will step in as the interim Red Hat Liaison. This means that Josh is stepping down from his position as an at-large board member. See Brian's and Josh's emails for more info: https://lists.centos.org/hyperkitty/list/devel@lists.centos.org/thread/QAG4… https://lists.centos.org/hyperkitty/list/devel@lists.centos.org/thread/BCWM… We are asking you, the CentOS community, for nominations for who should fill Josh's seat. Note that the vote on who will fill this seat is held by the board itself, but nominations are open to the entire community. If you would like to nominate someone (or self-nominate), please use this Google form: https://forms.gle/jqYF7v5AUVy6L1Fz6 Please DO NOT send nominations to this list. As this is not a public vote, we don't want to give the impression of a popularity contest with public nominations. We also want to avoid any shaming if someone is nominated and is not seated, or chooses not to accept. I will ensure that each nominee is willing and able to serve, and the board will consider them and select the next director from the list. If you wish to nominate someone, you should consider the list of director requirements and recommendations listed at: https://www.centos.org/about/governance/director-requirements/ Nominations will be open until September 23. Thank you for your thoughtful consideration and participation in this process. -- Shaun, for the CentOS Board of Directors

2 2

CentOS Showcase starting in a few hours
by Troy Dawson 04 Nov '24

04 Nov '24

Don't miss our first CentOS Showcase. https://pretix.eu/centos/showcase-2024-11/ What is it? Just what it sounds like. Various people will be showcasing the awesome the work happening in, and with, the CentOS ecosystem. Schedule: https://cfp.fedoraproject.org/centos-showcase-2024-11/talk/ See you there! Troy

1 0

Introducing Community Linux Engineering (“CLE”)
by Brendan Conoboy 21 Oct '24

21 Oct '24

Hi everybody, The “CPE” name is a commonly used identifier in the Fedora and CentOS communities. Inside Red Hat, it meant a specific set of individuals and roles reporting into common management. We recently had a reorg that brought it and other community roles together. There is a new name for the whole group: Community Linux Engineering. To be clear, no one is changing roles as part of this; all the things Red Hatters did before the reorg and rename remain the same after. This change does bring a question with it: In our docs and conversations, should we just search and replace the CPE name with “CLE”? My answer is a resounding no! The external CPE branding unintentionally contributed to some common misconceptions: - “Red Hat teams are separate from the community.” Red Hatters can, and indeed many do, play key roles in the community Linux space, regardless of team affiliation. - “Community members can’t take part in the same Fedora activities that Red Hat employees can.” The reality is that most activities are or can be open to all. - “There is a ‘Fedora team’ or a ‘CentOS team’ solely responsible for All the Things.” This would be impossible – it’s way too much. We all are part of making these distributions and communities succeed and grow. As this name change takes effect, I hope we can embrace names which reflect what we are doing together, the myriad skills and interests and activities that come together to make something we can all use and enjoy. So while I’m pleased to announce CLE, I hope you’ll promptly forget about the name and instead focus on why you’re here in this community, and find yourself able to pursue your interests as we build amazing things together.

1 0

← Newer
1
2
3
4
5
6
7
...
461
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel