devel February 2022

devel@lists.centos.org

27 participants
21 discussions

Few questions on cloud images
by Pino Toscano 06 Jun '23

06 Jun '23

Hello, I have few questions related to the cloud images provides for c8s and c9s, i.e.: - https://cloud.centos.org/centos/8-stream/x86_64/images/ - https://cloud.centos.org/centos/9-stream/x86_64/images/ 1) I see the c9s images are regularly updated, while the c8s images not; is this wanted, or simply a mistake/miss somewhere? If so, will they be kept up-to-date just like the c9s images? 2) are the Vagrant images there officially supported? Let's say you use one, and find a bug; then check on a "classic" installation (baremetal/VM), and the bug isn't there; can users report problems in those cases? 3) would it be possible to have either unversioned or "-latest" symlinks for the latest versions of all the files (i.e. images, checksums, etc)? This way, it will be much easier for users to fetch the latest versions with no need to change URLs frequently. Of course, the assumption is that users of this are always willing to use the latest version. Thanks! -- Pino Toscano

7 14

Proposal: CentOS Public Board Meetings
by Rich Bowen 07 Jan '23

07 Jan '23

In January of 2021, the CentOS Board of Directors opened our monthly meetings to all SIG chairs, in a first step towards more transparent governance. We wanted to see how the larger audience changed the meeting dynamics, if at all, as well as welcoming a broader pool of voices. We are now ready for the second part of this process. Starting in the August meeting, we will be inviting the entire CentOS community to attend these meetings. Due to the nature of the Internet, we won’t be simply publishing the meeting URL, as this often leads to disruptive behavior in meetings, as I am sure many of you have experienced. Rather, in the week before the meeting, we’ll send, to this list, a way to request an invitation to the meeting. In this way, we hope to limit the incidence of such disruptions, while also making the meeting available to anyone who wishes to attend. We will be working on the rules of engagement for these meetings, but they will be, at minimum: * 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/redactions, 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. Because there will seldom be time for Q&A during the meeting itself, we plan to add a post-meeting IRC office hours session for followup questions. This will probably be scheduled for a week after the board meeting, to allow time to publish meeting minutes We welcome your comments about the above proposal, and thank you all for your patience as we implement these changes to our governance process.

8 27

Decommissioning of CentOS Stream 8 source-git branches
by Tomas Tomecek 13 May '22

13 May '22

Hello, we would like to announce our plan to decommission and remove the c8s branches of the CentOS Stream source-git repositories. This also means the removal of any repository from the gitlab.com/redhat/centos-stream/src namespace which is left without a branch. Stream 9 content will not be affected. As you might remember, these are the source-git repositories produced by unpacking the c8s branches from CentOS Stream 8 dist-git, and making the resulting content available at gitlab.com/redhat/centos-stream/src. We took a look at the utilization of this content during 2021, based on the GitLab data and found out that no one from the community has used these repositories to contribute to CentOS Stream 8. The only exception is the kernel repository [1], we will keep that one up. Please let us know if you find these repositories useful or are part of your routine. Our focus for the future is to deliver a consistent source-git workflow for Fedora and CentOS Stream under the umbrella of Fedora source-git SIG [2]. [1] https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-8 [2] https://fedoraproject.org/wiki/SIGs/Source-git Tomas

1 2

CS8 repos / repomd.xml.asc
by Leon Fauster 02 Mar '22

02 Mar '22

Hey. It seems that the mirrors do not have the repomd.xml.asc file. Does the main repo provide it? -- Thanks Leon

5 8

c8 container images - old - ?
by lejeczek 01 Mar '22

01 Mar '22

Hi guys I pulled one yesterday: -> $ podman pull registry.centos.org/centos:latest and it's old EOL centOS 8. Should not there be 'stream' in repos already and EOL ones be removed & gone? (or am I missing something) many thanks, L.

3 3

CentOS SIGs and lookaside cache
by Pierre-Yves Chibon 28 Feb '22

28 Feb '22

Good Morning Everyone, There are currently two lookaside caches in use around the CentOS project: * One used by CentOS-Stream: https://sources.stream.centos.org/sources it's not browsable, but it uses the structure: `baseurl/pkgname/tarball/hashtype/hash/tarball`. Example: https://sources.stream.centos.org/sources/rpms/kernel/linux-5.14.0-62.el9.t… * One used by CentOS-Linux, CentOS-Stream 8 and the SIGs: https://git.centos.org/sources/ this one is browsable and as you can see uses the structure: `baseurl/pkgname/branch/hash`. Example: https://git.centos.org/sources/kernel/c8s/0c4e10577cfd4b4f8e3d83c0406da8ab0… The rest of this email focuses on this second one. SIGs upload to it using the route: https://git.centos.org/sources/upload.cgi In an email last week [1] was proposed an idea for how SIGs could leverage the centos namespace in gitlab for those who wishes. One of the benefits of using gitlab would be increased flexibility for SIGs and a clear example for this would be the ability to drop the branch structures currently imposed on the git repositories. That structure is imposed because the git repositories are shared between CentOS-Linux, CentOS-Stream and (potentially multiple) SIGs, so that structure ensures groups are not stepping on each other's toes. By moving the SIGs out of these shared repositories, imposing that structure is no longer needed. However, since the lookaside cache relies on branch name, lifting that structure would break the lookaside cache. I have already brought this idea to a few folks to see if the idea was sane. The consensus that emerged is: * Introduce a new upload endpoint next to the existing one, something like: https://git.centos.org/sources/sig_upload.cgi * That new endpoint would upload the sources given using the same structure as the one used for CentOS-Stream, but ensuring that the person uploading is member of at least one SIG. The idea of using `sig_upload.cgi` instead of just replacing `upload.cgi` is the assumption that we want to preserve the current structure used for CentOS-Linux and CentOS-Stream, allowing to find more easily which sources are used where and not impacting the process Red Hat uses to push its releases. Since the structures used by the two upload scripts are different, they will not conflict. What we will end up seeing is something like: sources │ ├── pkg1 │ ├── c7 │ │ ├── hash1 │ │ └── hash2 │ ├── c8 │ │ ├── hash3 │ │ └── hash4 │ ├── tarball1 │ │ └── sha name │ │ └── hash5 │ │ └── tarball1 │ └── tarball2 │ └── sha name │ └── hash6 │ └── tarball2 │ └── pkg2 ├── c8 │ ├── hash7 │ └── hash8 ├── c8s │ ├── hash9 │ └── hash10 ├── tarball3 │ └── sha name │ └── hash11 │ └── tarball3 └── tarball4 └── sha name └── hash12 └── tarball4 and so on On CBS, the script that downloads the sources, will then need to be adjusted to try first the old structure before trying the new one. This may slow down a little bit the builds, but that should be most of the time, at most by a single http request. In this email I'm calling for feedback, do you like the idea? I'm happy to work on making it happen if there is consensus on this :) Looking forward for your thoughts, Pierre [1] https://lists.centos.org/pipermail/centos-devel/2022-February/120216.html

5 11

Using lookaside_upload in combination with the "flat" dist-git layout
by Daan De Meyer 25 Feb '22

25 Feb '22

Hi, Recently there was an announcement that the "flat" layout can now be used by SIGs that want to pull in changes from the Fedora RPM repos directly. I'm trying to switch the hyperscale branches for the systemd RPM to use the "flat" layout but I'm running into issues trying to upload the systemd tarball to the CentOS lookaside cache. I've successfully used the lookaside_upload script from centos-git-common to upload tarballs for use with the rpmbuild metadata layout before, but I'm struggling to get it to work with the "flat" layout. The main issue comes from the fact that in the "flat" layout, the sources file is used which contains a SHA512 hash that's used to find the corresponding tarball in the centos lookaside cache. However, the lookaside_upload script tries to upload tarballs to the lookaside cache using the sha1sum of the tarball as the identifier. This leads to CBS not finding the tarball when trying to do a build. I tried modifying the lookaside_upload script to use sha512sum instead of sha1sum but when doing this, I get a 500 HTTP internal error from the lookaside cache (https://paste.centos.org/view/5e7ef15c). Any other way to upload a tarball under the SHA512 identifier to the lookaside cache? Cheers, Daan De Meyer

1 1

[Storage-SIG] cephadm is not last version
by Luis Domingues 21 Feb '22

21 Feb '22

Hello, We are currently testing deploying clusters using CentOS Storage SIG. And while almost all packages are available on last version (16.2.7), we notice that cephadm was only on 16.2.5. Is any reason for that? Thanks, Luis Domingues Proton AG

4 4

Announcing possibility for SIGs to use "flat layout" on git.centos.org
by Fabian Arrotin 21 Feb '22

21 Feb '22

Recently, a thread (see https://lists.centos.org/pipermail/centos-devel/2022-January/120171.html) was started onn this list to discuss the possibility to let SIGs pushing to git in a "flat layout" style instead "rpmbuild layout" style on git.centos.org. As you know, since the beginning of git.centos.org, Red Hat pushed (as is still pushing, no change in sight for that part) in each /rpms/<package_name> git project in the "rpmbuild layout" style (so with SPECS/<pkg_name>.spec , eventually SOURCES/*) That's what SIGs have been using for years now, and it's how it's also documented in the SIG guide (see https://sigs.centos.org/guide/git/) Some SIGs wanted to bring "flat layout" style support so that they can just import existing branch from Fedora/Epel directly on git.centos.org without a need to change the dist-git layout, so get_sources.sh (from https://git.centos.org/centos-git-common) was recently modified to detect in which format the git repo is laid out and so how to retrieve sources from https://git.centos.org/sources. This request was all tracked in ticket https://pagure.io/centos-infra/issue/659 The needed new centpkg-minimal (https://cbs.centos.org/koji/packageinfo?packageID=8196) was built/pushed "live" today on cbs.centos.org , as some --scratch builds were tested with automotive SIG to confirm that it was working fine. We'll just add a simple note on the SIG Guide to mention that it's now possible to use the "flat layout" style (like Fedora/Epel) on git.centos.org for SIGs willing to use that layout. -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

1 0

Linux Engineering update
by Josh Boyer 16 Feb '22

16 Feb '22

Hi All, I wanted to take a moment to thank the CentOS Stream contributor community and give an update on where we're at from the Red Hat Linux Engineering side. The contributions coming in for CentOS Stream, particularly Stream 9, have been fantastic. This is the kind of feedback loop we are trying to build, and the willingness to jump in headfirst from the community even though we still have some bumpy spots in workflow and guidance is much appreciated. We've seen: - package rebases - compose adjustments - bug fixes - subpackage additions and more from the community. While not all of them were accepted into CentOS Stream, overall it's been great. As we march towards spring, the Linux Engineering team is going to be focusing on finishing up the releases of Red Hat Enterprise Linux 8.6 and 9.0. Thankfully, the continuous development model of CentOS Stream means that it won't stop and community contributions should keep on going. With that being said, what each Linux Eng team needs to do varies widely and it may result in some slower or intermittent responses to contributions for the next few months. If someone doesn't respond quickly or asks to defer a contribution, please have a little patience. We'll get to it eventually. Lastly, I wanted to give some forward-looking contribution advice. CentOS Stream 9 has seen quite a bit of flux since we made it available. This has been quite helpful to shape the Red Hat Enterprise Linux 9 Beta, and what will be the RHEL 9 GA. After RHEL 9 GA, things will solidify more into what one would normally expect from an Enterprise Linux operating system. Package versions will settle, rebases will be less common, and our Linux Eng maintainers will need to evaluate CentOS Stream 9 contributions fully against the standards we have for RHEL. For contributions that are just outside of those standards in some way, we have a variety of other avenues within the CentOS project. Several CentOS SIGs are active today, building additional content on top of CentOS Stream. We also have associated projects like EPEL. If you have a contribution and you're not quite sure if it's something CentOS Stream can accommodate, please reach out to the Feature Request SIG [1]. They're there to help you navigate the best place for a contribution, and to help shephard along where they can. Thank you so much for the success we've had to date. It's far from perfect, but building out a new project is fun in and of itself. josh [1] https://wiki.centos.org/SpecialInterestGroup/StreamFeatureRequest

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel February 2022