devel February 2022

devel@lists.centos.org

27 participants
22 discussions

forums + portal for {lang}.centos.org sites
by Karanbir Singh 16 Aug '24

16 Aug '24

Hi, Earlier in the evening today Ralph, Fabian and I had a chat about the present state of the language subsites. This email sort of summarises the main issue ( s/w ). We seem to have run into a slight technical hitch with punbb/fluxbb. They dont support LDAP as a backend. And we had decided a few months back that all new rollouts must have ldap backend so we can rollin CentOS-DS / openldap based backend. So we need to look at alternatives, and since the primary focus of these international sites is going be forums : Here is a shortlist ( if there is anything else that people are aware of, please add to this list ) - phpBB - SMF - Fudforum - phorum - fluxbb Requirements: - Must be able to scale ( couple of hundred thousand msgs ) - Must be able to handle ldap auth ( if it cant, whats involved in writing the ldap-auth portion ) - Must address the specific requirements raised by the present www.centos.org forum users ( Can you please fill this section in ? ) - Must support all languages we need ( pure utf8 support would be good ) - Secure - Skin'able Nice to have: - Capable of running multiple instances from a single deployment - responsive community :D Things we will need to do: - Decide on what s/w to use. - Give the ArtWork people enough time to get the look & feel sorted. - Migrate newbb forums from www.centos.org to $system ( hey, english is a language too :D ). - Migrate fr.centos.org into the final s/w - setup {de/es/ja/it/pt_br}.centos.org Actions: Ralph and Fabian are going to work on setting up a test ldap server, once that is online we will then start by installing into our test-vm-farm the various s/w to eval them. If anyone would like to help, please feel free to jump right in. I'll setup a wiki page for this issue, which might be a good place to track progress. -- Karanbir Singh : http://www.karan.org/ : 2522219@icq

22 81

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel February 2022