devel April 2021

devel@lists.centos.org

47 participants
31 discussions

repomd.xml.asc outdated?
by Leon Fauster 11 Jun '21

11 Jun '21

JFYI: LANG=C yum update --noplugins ... Error: Failed to download metadata for repo 'appstream': repomd.xml GPG signature verification error: Bad GPG signature http://mirror.centos.org/centos-8/8/AppStream/x86_64/os/repodata/ shows repomd.xml 2021-03-16 15:43 repomd.xml.asc 2021-03-03 00:29 -- Leon

5 6

RFC: Stream Kernel SIG Proposal
by redbaronbrowser 19 May '21

19 May '21

There are four main goals of this SIG: First, break down changes in the Stream version 4.18.0 kernel into individual patches. When possible, document the source the patch is from and the purpose of the patch. Moving forward also document which Stream kernel package revision introduced the patch. Second, build CentOS Plus kernel for Stream. Third, package newer LTS kernels during the LTS lifespan. These would be available as alternative kernels for Stream similar to the CentOS Plus kernel. Fourth, work on tools for better delivery of live security patches to be applied via kpatch. The reasoning for this SIG is to improve the openness of kernels available through Stream. Normally a distribution upstream would have access to which patch or commit each addition to the kernel belongs to. The patch name or commit comment would also give information as to the purpose of the patch. Stream's kernel reports to be 4.18.0 but uses a tar that is 110% the size of a true 4.18.0 tar. A breakdown of the additional 10% is not provided. Hence Stream's kernel still functions similar to a downstream rather than providing what is expected for a successful upstream project. This SIG would help close the kernel openness gap by documenting the changes. Stream users would then be in a better position to track down individual patches that cause regressions or bugs. This SIG would also help smooth the adoption of Stream for users that depend on CentOS Plus kernel features. Next, this SIG should help improve feedback to the LTS kernel developers. Tracking LTS kernel changes may also help with documenting some changes in the primary Stream kernel. Lastly, this SIG should help improve kernel security by promoting methods to enable kernel security updates even when a reboot of the system is not possible.

12 42

Making EPEL available in CBS for SIG builds
by Davide Cavalca 13 May '21

13 May '21

Hello, Fabian suggested to post about https://pagure.io/centos-infra/issue/306 so we can have a wider discussion around it. That ticket is specifically for the Hyperscale SIG, but I think this is something that could be generally useful. Within Hyperscale, we have a need to build a few packages that have dependencies coming from EPEL. While we could rebuild those dependencies within the SIG, that seems both wasteful and undesirable, as it would lead to needless deviation and potentially discourage folks from maintaining stuff in EPEL (where it has a chance to benefit the most people). So, our conclusion was that it would be great to just depend directly on EPEL and have it added to our build targets in CBS so we can build against it. One concern with doing this is that EPEL is kind of a moving target. This doesn't really apply to Hyperscale (as we track CentOS Stream), but it could be relevant for SIGs tracking CentOS Linux. Still, this would just be a non-default option for a SIG to add to their build tags, so I don't think this will be much of a problem in practice. From my chat with Fabian I understand this was raised in the past and there had been policy concerns around it. I'd love to get more context around this and see if we can get them addressed. Alternatively, if there are no concerns I'd be happy to entertain suggestions on how to actually do this :) Thanks! Cheers Davide

13 32

Missing build dependencies in CentOS 8 repositories
by František Šumšal 07 May '21

07 May '21

Hello! I'm not sure if this has been already answered somewhere on this list, but I'm curious why the CentOS 8 repositories are missing certain build dependencies (although they're present in RHEL's internal repositories). This makes rebuilding some of the CentOS 8 packages a bit painful. For example, let's try to rebuild util-linux: ``` $ podman run -it --rm centos:8 # rm -f /etc/yum.repos.d/CentOS-Linux-Media.repo # dnf -y install dnf-plugins-core ... # dnf --refresh --enablerepo \* -y builddep util-linux Failed to set locale, defaulting to C.UTF-8 CentOS Linux 8 - AppStream 10 kB/s | 4.3 kB 00:00 CentOS Linux 8 - BaseOS 23 kB/s | 3.9 kB 00:00 CentOS Linux 8 - ContinuousRelease 5.3 kB/s | 3.0 kB 00:00 CentOS Linux 8 - Debuginfo 1.6 MB/s | 27 MB 00:16 CentOS Linux 8 - Devel WARNING! FOR BUILDROOT USE ONLY! 18 kB/s | 13 kB 00:00 CentOS Linux 8 - Extras 8.2 kB/s | 1.5 kB 00:00 CentOS Linux 8 - FastTrack 933 B/s | 257 B 00:00 CentOS Linux 8 - HighAvailability 741 kB/s | 504 kB 00:00 CentOS Linux 8 - Plus 807 kB/s | 596 kB 00:00 CentOS Linux 8 - PowerTools 2.1 MB/s | 2.0 MB 00:00 CentOS Linux 8 - BaseOS - Source 120 kB/s | 384 kB 00:03 CentOS Linux 8 - AppStream - Source 271 kB/s | 991 kB 00:03 CentOS Linux 8 - Extras - Source 2.2 kB/s | 7.8 kB 00:03 CentOS Linux 8 - Plus - Source 1.7 kB/s | 5.0 kB 00:03 Package systemd-239-41.el8_3.x86_64 is already installed. No matching package to install: 'libuser-devel' Not all dependencies satisfied Error: Some packages could not be found. ``` Oh well, looks like we have to rebuild libuser as well: ``` # dnf --enablerepo \* -y builddep libuser Failed to set locale, defaulting to C.UTF-8 Last metadata expiration check: 0:02:14 ago on Tue Apr 13 10:36:39 2021. No matching package to install: 'openldap-servers' Not all dependencies satisfied Error: Some packages could not be found. ``` And apparently openldap, too. I noticed that Davide from FB already come across this issue and filed it in RHBZ[0], where it was confirmed that the dependency is indeed present only in the internal RHEL buildroot repository - and after a quick test they still are: # dnf --enablerepo rhel-buildroot search libuser-devel ... libuser-devel.i686 : Files needed for developing applications which use libuser libuser-devel.x86_64 : Files needed for developing applications which use libuser Is there any reason why they aren't shipped in some CentOS repository or was there any progress to make them available? Thank you! Frantisek [0] https://bugzilla.redhat.com/show_bug.cgi?id=1868430 -- Frantisek Sumsal GPG key ID: 0xFB738CE27B634E4B

15 23

[Infra] - Planned outage : cbs.centos.org
by Fabian Arrotin 04 May '21

04 May '21

Due to a major upgrade, we'll have to take the cbs/koji setup into maintenance window. We're basically upgrading from koji 1.19 running on CentOS 7 to koji 1.23 running on CentOS 8-stream, meaning a parallel reinstallation. Migration is scheduled for """"Tuesday May 4th, 6:00 am UTC time"""". You can convert to local time with `date -d '2021-05-04 06:00 UTC' ` The expected "downtime" is estimated to ~60 minutes , time needed to - backup/restore last postgresql dump , - apply DB schema upgrade[s] - verify service and switch public IP to new kojihub. We've already taken some kojid builders instance down (and reinstalled with 8-stream already) and these will be the first ones to be attached back to kojihub, and so letting you, SIG members, be able to submit builds again asap. The remaining kojid nodes will then be reinstalled with 8-stream too, and enabled back normally on the same day, to be back at "full st[r]eam" :) Thanks for your comprehending and patience. on behalf of the Infra team, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

1 1

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel April 2021