devel

devel@lists.centos.org

9 participants
4635 discussions

04 May '21

I would like permission to use this graphic in a lightning talk describing why I see CentOS Stream as an improvement over CentOS. However, I don't see licensing information available for the graphic. Who can I contact to request that permission? https://access.redhat.com/sites/default/files/images/rhel_8_life_cycle_8_06…

4 4

Board of Director nominations: Take Two
by Rich Bowen 03 May '21

03 May '21

Hi, folks. Well, this is embarrassing. Due to a mixup in the mailing list moderation queue, we have not received any of your board of director nominations (and at least a few of you have mentioned that you sent one!) and we have to ask you to submit them again. This time, we're going to do this via a Google Form, and hopefully avoid the problem that we had last time. That form is here: https://forms.gle/U777HHDTkKgkg6Sa6 As a reminder, if you're considering nominating someone, have a look at the requirements/recommendations document, at https://www.centos.org/about/governance/director-requirements/ , where we discuss what's involved in being a director, and who's eligible. Thanks!

1 0

CentOS Stream 9 Buildsystem is publicly viewable
by Brian Stinson 02 May '21

02 May '21

Hi Folks, There’s been a lot of CentOS Stream 9 activity over the past few weeks that I’d like to share with you. First, if you haven’t noticed already, Stream 9 package sources are publicly available in GitLab: https://gitlab.com/redhat/centos-stream/rpms Second, we’ve been leading up to a very important end-of-April milestone. You can now watch package build activity in the Stream 9 build system: https://kojihub.stream.centos.org We started using these sources in the middle of March to complete our bootstrap round. That was followed almost immediately by a mass rebuild on April 12th to set the architecture baselines to POWER 9 and Z14 for the ppc64le and s390x architectures respectively. If you find your favorite package in GitLab, you can visit the ‘Merge Requests’ tab to see how the Fork/Merge Request/Build workflow works. RHEL maintainers have been using this workflow for a few weeks now as part of regular development. We’ll provide more posts this week to explain how to use the same workflow, and work with maintainers who can evaluate your changes. If your changes are merged into CentOS Stream they can directly affect RHEL 9. ## What you can do now - Sign up for a gitlab.com account: https://gitlab.com/users/sign_up - On Fedora install centpkg-0.6.3-1 from the updates/updates-testing repo - On CentOS Stream 8 install centpkg-0.6.3-1 from the epel/epel-testing repo - Pull package sources from gitlab.com - `centpkg clone -b c9s <pkgname>` gives you a dist-git checkout from gitlab - `centpkg sources` from your checkout pulls source tarballs from the lookaside cache - Download and inspect artifacts and logs for builds already in the build system - Use `centpkg mockbuild` to try local builds of your own ## Plans for upcoming work - Updates to the contributor guide which contains important requirements and guidelines for how to submit changes to CentOS Stream via Merge Request - Availability of the Composes (including install media, cloud images, container images) - Announcements later this week describing upcoming milestones, new services, and when we expect to publish to the mirrors Just a reminder: CentOS Stream 9 is still very early. We’re going to make lots of changes together, and we’re quickly bringing up services to support our long-term goal of having CentOS Stream 9 development continuously targeting the next minor release of RHEL. Currently these packages are subject to RHEL gating tests. We’ll be back with more about how that works, and what we’re doing to increase our ability to run tests directly in CentOS Stream too. Cheers! --Brian

12 22

[ppc64le] Missing advancedvirt-common repo in stream
by Michael Turek 30 Apr '21

30 Apr '21

Hey everyone, Our ppc64le tripleo container build job [0] is broken by the lack of the advancedvirt-common repo outside of x86_64 [1] [2] There was a topic on the ML about this a few weeks ago [3] for what it's worth. Any ideas if we can get this fixed? Thanks! Mike <mjturek> [0] https://ci.centos.org/job/tripleo-upstream-containers-build-master-ppc64le/ [1] http://mirror.centos.org/centos/8-stream/virt/aarch64/ [2] http://mirror.centos.org/centos/8-stream/virt/ppc64le/ [3] https://lists.centos.org/pipermail/centos-devel/2021-April/076754.html

1 0

Re: [CentOS-devel] Documentation change propsal - "Contributing to CentOS Stream" web page
by Tomas Tomecek 30 Apr '21

30 Apr '21

Hi Michal, thanks for your thorough feedback! More comments inline. On Thu, Apr 29, 2021 at 5:14 PM Michal Schorm <mschorm(a)redhat.com> wrote: > > Hello, > > The "Contributing to CentOS Stream" webpage: > https://wiki.centos.org/Contribute/CentOSStream > is very confusing (at least to me) and lacks a lot of details. It's true the documentation is not finished yet - the CentOS Stream team is planning to provide comprehensive contributor's documentation, the wiki is really just an intro. > Here is my proposal to update / fix / enhance / clarify at least some > of the sections. > > -- > > (1) > Section 1 > Text: "You should always open a bugzilla first" > > The link leads to the most general selection in Bugzilla. > Even in the "All" category, there is no "CentOS" or "CentOS Stream" product. > Let's clarify that the product selected should be "Red Hat Enterprise > Linux *" and provide more accurate link: > https://bugzilla.redhat.com/enter_bug.cgi?classification=Red%20Hat Oh yeah, this is gonna be really handy! I just updated it to point to RHEL 8 and picked CentOS Stream as the version. > (2) > Section 1 > Text: "You should always open a bugzilla first" > > "Should" ? > The process *requires* package maintainers to have the ACKed BZ > referenced in the commit message, otherwise it will be impossible to > merge it. > I haven't heard of any other way, so this should be changed to " *MUST* ". The reason I wrote "should" there is that it may already be a bugzilla opened for the MR. I can see that Rich already changed it to "must" so let's keep it that way because that would incentivize potential contributors to discuss changes first, which is what we really want. > Also, the GitLab offers features such as "Issues" and so on. Will > those be globally disabled to discourage the contributors to file > tickets in the wrong place ? Yes, issues are disabled. Bugzilla is still the official tracker. > (3) > Section 1 > Text: "As with any open source projects, in the end it's up to > maintainers to decide which changes they want to accept and maintain, > so Red Hat maintainers can decline contributions for any reason." > > This sentence is heavily suggesting that only "Red Hat maintainers" > have the power to decide the fate of the contributions. Correct. > Does that mean that there can be no CentOS stream maintainer that is > not a RH employee at the same time ? > If yes, why don't make this clear and say it explicitly ? I'd say it's explicitly stated there already. Please suggest a better wording if you have one in your mind already. > Also if yes, why can't I login to CentOS project using Red Hat > credentials or SSO ? Because the CentOS identity provider is not utilizing Red Hat's SSO - I'd suggest starting a new thread for such a request because that's a big one. Though you can log in to GitLab via https://red.ht/GitLabSSO > If not, the sentence doesn't make much sense. > > (4) > Section 1 > Text: "It's also great to have it in Fedora Linux first as well." > > AFAIK, the OS you are mentioning is named "Fedora" or you can use > "Fedora Operating System" (to distinguish from the Fedora Project that > has a broader portfolio than just the OS). I think the "Fedora Linux" > is not correct. > Correct me if I'm wrong https://communityblog.fedoraproject.org/fedora-is-a-community-fedora-linux-… > Also, shouldn't be the "It's also great to have it in ..." statement > which is "nice-to-have" like, rather something more stressing the fact > that Fedora serves as an upstream for RHEL an in order to avoid future > regressions, it is very important to have the change accepted in the > Fedora first - if possible && if it makes sense. > The Red Hat package maintainers have to do it (the upstreaming of > relevant code to Fedora) anyway as a part of their job. > Also, how would it need to be a part of the upstream project and not > to be in Fedora at the same time ? I mean Fedora (at least Rawhide) > aims to provide the latest upstream versions possible. This is really hard because you have plenty of software that is being built and configured differently for all the distributions: kernel, qemu-kvm, *-release, subscription-manager... I'll reword that statement and will make it more clear. My assumption is there would be a dialogue between the maintainer and the contributor on how to handle specific contributions: I'd say it's perfectly reasonable to ask the contributor to propose the patch upstream or to Fedora Linux first. > (5) > Section 2 > Text: "If you want to contribute to CentOS Stream, you need to have an > account in CentOS FAS." > > Same issue as (3), same questions I ask. > > How comes it that I do not have the account and still I can contribute ? > The statement is most likely false. I agree this piece is slightly outdated because the sources are now placed on two locations: git.centos.org and gitlab.com/redhat/centos-stream I'll update it. > (6) > Section 3 > Text: "Once your account is set up, you can proceed to clone the > respective package repository locally." > > You can't clone the package repository locally without any account at all? > That would be weird for a public Git repos ... > > I'd reformulate the sentence such as "The next step you like to do is > to clone ... " > Also, the actual goal is not to clone the repo, but fork it, so let's > state that fact right away: > "The next step you like to do is to clone a package (project) from one > of the following repositories and fork it" That's a good point, I simplified the section. > (7) > Section 3 > Text: "The package repositories are right now located in two places:" > > Two places, but four list items? :) will update > (8) > Section 3.1 > Text: "You'll be able to see 3 types of branches: > > Not all projects have all 3 types of the branches. > It would be better to say something like "The repository will contain > some of these types of branches:'' > followed by a bullet point list " To me, it already says that. Would this wording work? "Branches in the repositories follow this naming pattern:" > (9) > Section 3.1 > > Also, what about showing some instructions on how to do it? > Do the contributors from the general public know about the "centpkg" > tool or should they work with bare "git" ? I'll mention centpkg though it doesn't have comprehensive documentation out there yet. > If they should know (or even are encouraged to use) "centpkg", provide > the damn instructions. I don't think such language is necessary. > Otherwise, describe if the forking in the web UI is the only way and > how to do it. > > (10) > Section 4.1 > > I bet this is a confusing section, at least for new contributors. > > 1/ Let's begin with the fact that you need the fork in the first place. > 2/ Inside of the fork, you should create a new branch - based on the > branch they want to contribute to, ideally (but necessarily? ... we > might make a "best practice" though) named "bz12345" referencing the > submitted BZ ticket for easy recognition > 3/ commit the changes. > note: each commit must contain an ACKed BZ ticket in order to be > able to be merged to the target branch. > note: there will be different ACK requirements for different > branches in the future (e.g. Y-stream v s Z-stream) > 4/ Push the branch to your fork > 5/ create MR > note: when using "centpkg" as I asked above, the MR URL will be > created during the push > > (11) > Section 4.2 > Text: "you need to execute %prep phase to see it." > > To "see it"? More like to "retrieve it from the cache". > > (12) > Section 4.4 > > What the hell is this about? > We should be talking about a dist-git layout & workflow in this > section, not a RPMbuild layout (which is completely irrelevant here). > There are no "SOURCES" and "SPECS" directories in dist-git. that is > completely wrong, the whole section. There is: https://git.centos.org/rpms/systemd/tree/c8s The main problem with this wiki page is that it was written as contributor's docs for CentOS Stream 8 while it was hosted on git.centos.org and it was never fully updated for Stream 9 and gitlab, hence the confusion. And also as you can see, Stream 8 and Stream 9 dist-git repos look differently. This is where I'm stopping my replies because your language is just way too offensive and I am not interested in this kind of discussion. > 1/ If you want to make just a packaging change, you *likely* only need > to modify just the SPECfile. > 2/ If you want to make justa patch change, you need to add the patch > AND modify the SPECfile too. > > At the end, you add all the modified files, commit them, add the BZ > ticket to the commit message and create MR. > > (13) > Section 4.5 > Text: "4.5. After a pull request is created" > > For a reason I don't know, some people call it "pull requests" (e.g. > in Fedora), some people "merge requests" (e.g. in GitLab). > Anyway, we are working with GitLab, so use it's naming. > > So: "4.5. After a merge request is created" > > Please find all 3 occurrences of the word "pull" on the page and fix them. > > (14) > Section 4.5 > Text: "When you submit a pull request for source-git, automation will > pick up the change and build it " > > Does it not work for the dist-git too? > Why ? > What about mentioning the scratch-build then? ... aww hell, we are > back to the "centpkg" again :) > > (15) > Section 4.5 > Text: "Once your change is accepted, it will be marked with the label > "accepted". Our automation will create a corresponding bugzilla with > the patch attached and then it’s up to the RHEL maintainer to pick it > up, commit and build internally so that it can land back into CentOS > Stream" > > This is most confusing. > > Why won't a maintainer merge it into CentOS first? > Why would he first apply it in the most downstream place? What about > the "upstream first" rule? > > How can a package maintainer mark the MR as "accepted"? > I haven't found such an option anywhere. > > "Our automation will create a corresponding bugzilla with the patch attached" > So ... another BZ ? This time to ... what product ? > Again see (1). > > I personally actually created a MR, but none BZ has been created: > https://gitlab.com/redhat/centos-stream/rpms/mariadb-connector-c/-/merge_re… > > "RHEL maintainer to pick it up, commit and build internally so that it > can land back into CentOS Stream" > That sentence suggests that the RHEL is the upstream for CentOS > stream, but at the same time we are pushing CentOS stream to be > upstream for RHEL. > Get this straight. > > BTW on a webpage: > https://wiki.centos.org/Contribute#CentOS_Stream > the re is a clear statement: > "CentOS Stream is a continuously delivered distribution which is > upstream to the next minor version of Red Hat Enterprise Linux" > > (16) > Section 5 > Text: "it needs to be reviewed and approved by the RHEL maintainer for > the particular component." > > Again - so only RH employees will be able to maintain ? > Why don't have a CentOS FAS access already created ? > Why would anyone else need a CentOS FAS ? > > "maintainer for the particular component" > Also, I believe this is a false statement too. > The current permissions AFAIK allow for any RH employee with the > GitLab account with the "devel" role over gitlab.com/redhat space to > merge the MR. > > (17) > Section 5 > Text: "We are making sure behind the scenes they see your patch." > > Who is making sure? > the RH employees ? > Who are "they" > *the same* RH employees ? :D > > (18) > Section 6 > > Might help to add instructions on how to do it. > > (101) > > Is there not a single documentarist as a part of the CentOS project > who would read through the webpages ? > > > -- > > Michal Schorm > Software Engineer > Core Services - Databases Team > Red Hat > > -- >

1 0

Missing dependencies while rebuilding OpenStack packages on centos8 stream
by Jose Castro Leon 30 Apr '21

30 Apr '21

Hi Cloud SIG, With every OpenStack release (and also with CentOS 8 stream), we have to rebuild some OpenStack packages to be installed at CERN. Those packages carry downstream patches for integration into our environment. While building those, we have observed that there are some packages that are required to build but are not provided in the testing repositories, for example openstack-macros In the past, we were using trunk.rdoproject.org/centos8-wallaby but it seems that those packages are not there. While looking into cbs.centos.org, I saw them on this tag cloud8s-openstack-wallaby-el8-build Would it be possible to have the dependencies available in the testing repo or to have access to that build repository, at least to build the main OpenStack components? Cheers Jose Castro Leon CERN Cloud Infrastructure Team

3 2

CentOS Stream 9 Compose Infrastructure is Available
by Brian Stinson 29 Apr '21

29 Apr '21

Hi again folks, I promised to provide updates as soon as we get new services wired up. I have another one for us. You can now visit https://composes.stream.centos.org/ This is the place where you'll find point-in-time test instances of yum repos, install media, cloud images (coming soon), and other artifacts. For right now we are generating composes for infrastructure purposes and to test out our tooling, but there are a couple of composes that do result in a working installer. Some notes: - RPMs and images are published unsigned in the Test composes right now. We'll be back with an update about signing when that comes online - For now composes are generated Ad-hoc, there is not an automatic schedule yet but that's something that we're working on now that we have the infrastructure ready - We'll soon be including documentation on the different compose types and what they mean, for now we are only generating 'Test' composes. They can be found here: https://composes.stream.centos.org/test - Because things are very early, we are not currently shipping .repo files, we recommend doing fresh installs for testing purposes. Updates from one compose to the next may work but are not tested - Test composes will be cleaned up more frequently than the other upcoming compose types, you can always find a fresh one by using the latest-CentOS-Stream symlink in the test directory Happy testing! --Brian

2 3

Re: [CentOS-devel] [Dev] Documentation change propsal - "Contributing to CentOS Stream" web page
by Miro Hrončok 29 Apr '21

29 Apr '21

On 29. 04. 21 17:13, Michal Schorm wrote: > (4) > Section 1 > Text: "It's also great to have it in Fedora Linux first as well." > > AFAIK, the OS you are mentioning is named "Fedora" or you can use > "Fedora Operating System" (to distinguish from the Fedora Project that > has a broader portfolio than just the OS). I think the "Fedora Linux" > is not correct. > Correct me if I'm wrong I am afraid that you actually are. See https://fedoraproject.org/wiki/Changes/Fedora_Linux_in_os-release -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

Community Build Service (cbs): deprecating ppc64/armhfp builders
by Fabian Arrotin 27 Apr '21

27 Apr '21

Background story : for some SIGs building for/against 8-stream (and hopefully soon for/against 9-stream), we'd like to upgrade cbs.centos.org to koji 1.23 and all components on CentOS 8-stream. The current setup is based on koji 1.19 on top of CentOS 7 nodes. While we have tested that it works fine for all builds and signing with 8-straem (tracking ticket https://pagure.io/centos-infra/issue/233) we have though a "small" issue that we'd like to announce first here : 8-stream doesn't exist for the following architectures : ppc64 (Big Endian, while ppc64le - Little Endian - exists) and armhfp. I had a quick survey on what is being built/maintained (and so pushed out to mirror CDN) and ppc64/armhfp aren't even used. So it seems that removing ppc64/armhfp support from CBS is the way to go and it wouldn't hurt any SIG. The only SIG that actually builds and ships packages to external mirror is the Infra SIG (so "us"), but we're building pkgs just because we had to maintain that arch ourselves, meaning that if we remove it from cbs, we don't have to maintain infra for ppc64 anymore (for SIG, as pkgs from CentOS 7 distro itself will continue to be built and shipped, but they aren't built on cbs anyway) Opinions ? thoughts ? Depending on feedback (or lack of in this case), I'll announce the maintenance window about cbs.centos.org migration to 8-stream in the next days (normally planned for next week but waiting for some feedback) Kind Regards, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

2 1

Board of Directors: Nominations sought
by Rich Bowen 26 Apr '21

26 Apr '21

** Please do read the message before responding with your nominations. We have a process, and if you don’t follow the process, it makes everything harder for everyone. ** ** The process is to email centos-board-private(a)centos.org. Read on for more details. ** At the April Board of Directors meeting, we discussed the annual process of re-appointing the Board of Directors, as defined in our Governance documents. At that time, two directors indicated that they wished to step down, to focus on other things in their life and open the seats to new contributors. (Historical note: The last time a director resigned, the Board simply appointed replacements with no public process. We believe that greater transparency is needed in this new chapter of our existence as a project, and are committed to making that happen.) With two resignations, we have 8 Board seats filled. Our governance definition as it currently stands indicates 8 to 11 seats[1], so we’re still covered. However, we have decided to continue to seat 10 directors as part of the new Board. To this end, we come to you, the CentOS Community, for nominations for who should fill those seats. We ask that you send nominations to centos-board-private(a)centos.org and NOT to this list. There are several reasons for this: 1) Our governance indicates that the Board selects the next Board. We do not have any defined notion of project “membership” or a voting class of any kind, other than the Board itself. We do not wish to give any false impression that a public vote will be held on this list. 2) We do not wish for this to devolve into a bikeshed over proposed names. 3) We do not wish for individuals named to assume that they have any particular advantage over other nominees, nor do we wish for anyone to be shamed, embarrassed, or disappointed, if they are named and then not seated on the Board. The Board will collect those nominations, consider them at an upcoming meeting, and select the next Board at that time. We ask, if you wish to nominate someone, to consider the list of director requirements/recommendations listed at https://www.centos.org/about/governance/director-requirements/ Thank you for your participation in this important moment in our project’s history. Rich, for the CentOS Board of Directors [1] https://www.centos.org/about/governance/

2 2

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