devel

devel@lists.centos.org

7 participants
4616 discussions

newer cri-o builds for CentOS 7
by Baptiste Agasse 20 Mar '20

20 Mar '20

Hi all, I try to find a build of cri-o > 1.13 in a repo for CentOS 7. I find some package version that fit this requirement [1] and some builds[2] that are tagged with 'paas7-crio-115-release' but I didn't find any newer version of cri-o than crio-1.11 in origin311 repo [3]. Is there any repo that I'm missing where newer cri-o builds are located ? Have a nice day. Cheers. [1] https://cbs.centos.org/koji/packageinfo?packageID=5695 [2] https://cbs.centos.org/koji/buildinfo?buildID=26497 [3] http://mirror.centos.org/centos-7/7.7.1908/paas/x86_64/openshift-origin311/ -- Baptiste

4 3

Tags structure proposal (and fix) for CBS
by Fabian Arrotin 19 Mar '20

19 Mar '20

When working with Thomas on new signing process, we decided that we'd use Koji/CBS as single source of truth, so new signing process should only query koji/cbs and automatically act when there would be something to do. Creating so a different thread to discuss the koji tags we have. We discovered some inconsistencies and we think that $now would be a good time to fix/move those if needed. The current proposal would be (and most of the existing tags are following that convention) : <sig><dist>-<sig_project>-<sig_project_rel>-<sig_level> If we take an example for Gluster 7 for CentOS 7, built by Storage SIG, that means the following tags : storage7-gluster-7-{candidate,testing,release} The path where new process would automatically push out (to mirror CDN) would be so based on koji tag : mirror.centos.org/{centos,altarch}/<dist>/<sig>/{arch}/<sig_project>-<sig_project_rel>/ Once again, if we take the gluster 7 as an example, that would mean that process would automatically (for -release tag, with three enabled arches), push to those paths (created if needed) : * http://mirror.centos.org/centos/7/storage/x86_64/gluster-7/ * http://mirror.centos.org/altarch/7/storage/aarch64/gluster-7/ * http://mirror.centos.org/altarch/7/storage/ppc64le/gluster-7/ The full path is coming from the koji tag, but we see some issues for some paths/SIGs (like NFV) As we think that it would be good to have confirmations from all SIGs (as they are responsible for content to be pushed out, and also good time to have EOL content removed), we'd eventually "lock" koji tags for which we have *not* received confirmation for final destination path. Other thing we discovered : some SIGs (in the past) have asked for a "common" tag but then have asked (through cbs-content-control) to have content from that common tag to be added in other repo. As we'll *not* use cbs-content-control anymore, the way to deal with this would be : - either we use koji tag inheritance (preferred solution) - or you just "tag-build" yourself when needed from one to the other The advantage of doing this through koji tag inheritance is the following : When you request for some tags, and specify what they would need, nothing else would have to be done and you can just tag-build from -testing to -release to trigger the sign+push to mirrors (while tag-build to -testing first would push unsigned pkgs automatically to buildlogs.centos.org, as usual) Can we ask each SIG Chair to see which projects/releases are still needed and so come back (either in this thread of #centos-devel) Thanks for your collaboration ! -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

2 1

CentOS for IBM LinuxONE / IBM System Z
by FuLong Wang 19 Mar '20

19 Mar '20

Hello Everyone, I'm from IBM China Development Team and I'm working on a new initiative that plan to enable a "*minimized*" or "full" CentOS operating system on IBM LinuxONE / IBM System Z (s390x architect). The reason why we start this topic is we are trying to contribute to the RDO community with our OpenStack build on LInuxONE. We have successfully finished the build job for OpenStack Train Version on LinuxONE and passed the basic function verification tests recently. Now, we already have a link for worldwide users & fans to reference for their needs. For "official official" contributing to the RDO community, community admin stated that a TripleO CI env is a must for community release criteria and the OpenStack packages need to be built in the CentOS build system which run on s390x arch. So, we turn to here for help, we know CentOS community ever had releases for s390x arch but for whatever reasons finally stopped for update. We want to take this opportunity to enable it up again and therefore want to know about the overall processes, skills required, hardware requirements, manpowers and duration estimated and which parts need IBM's team's input, etc. Our target is to enable at least a *"minimized" CentOS* (which can support the OpenStack CI work), is there a SIG fit for this purpose? or a "full" CentOS with default feature sets. Could anybody kindly give us some clue to start this journey? Thanks everyone in advance! The Howto of OpenStack Train Installation on IBM LinuxONE had been merged to the RDO official website. https://www.rdoproject.org/install/ -- FuLong Wang fulong.wang(a)cn.ibm.com IBM China Systems Lab, Beijing, China _______________________________________________

5 9

New CBS/SIG signing process
by Fabian Arrotin 16 Mar '20

16 Mar '20

Hi all (especially SIG members/contributors) , As announced by Jim some time ago, we wanted to redesign the current signing process that is in place for https://cbs.centos.org for CentOS 6 and 7 (so quite some years now) The goal is to automate as much as possible the workflow, and working for all releases (yeah for CentOS 8 and Stream) Thomas and myself have worked on the following idea and we're now happy with the results (in our Dev environment) : - when someone builds a pkg, and that it's tagged to -testing, koji sends a notification (through koji callback - https://fedoraproject.org/wiki/Koji/WritingKojiCode#Event_Plugin) to a bus - signing machine listens to the bus, process the tag and push directly to buildlogs - when someone tag-build said pkg to -release, the node signs it with correct gpg key id (from the SIG), push generated repository (including for debuginfo/src.rpm packages) to mirror CDN As we were working on such automation, we also confirm that if one uses "untag-build", the same rule applies : it triggers automatically koji to reprocess the tag/repo and so removes the pkg from mirror (we got some requests for that in the past) The process so would work 24/7, and also have monitoring built-in (so that we can detect - the infra team - when something doesn't work, and so we can still process the tag again) We recently upgraded cbs.centos.org to newer koji version that permits some of the needed operations for this to happen. At this stage, we are just missing the SIG GPG private keys, but we were promised to have those this week. We don't have any ETA yet for the migration to new signing system, but we were thinking about such plan: - deploy and configure (automatically) new signing node (this week) - import GPG keys in the new system and validate that we can sign (when we get those) - changes some flags/parameters on tags on cbs.centos.org (this week) Once we have this in place, we'd like to start validating the signing process but *not* pushing to mirror CDN (yet). Same for the bus : we'd like to process all tags in advance as we'll have to import RPM signatures back in koji/cbs. After full validation, we announce that new system would be fully in place, and kojihub restarted with the notification plugin. From that point, the system would be fully operational and so when SIG members would build/tag pkgs, that would trigger the push (and signing if needed for -release tag) Worth knowing that with the update to some components in the chain, the directory layout will change a little bit (like people are already used to if using Fedora and Epel) : the Packages will be splitted by first letter. Here is an example from our testing : └── storage └── x86_64 └── gluster-7 ├── Packages │ ├── g │ │ ├── glusterfs-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-api-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-api-devel-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-cli-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-client-xlators-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-cloudsync-plugins-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-devel-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-events-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-extra-xlators-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-fuse-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-geo-replication-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-libs-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-rdma-7.2-1.el7.x86_64.rpm │ │ ├── glusterfs-resource-agents-7.2-1.el7.noarch.rpm │ │ ├── glusterfs-server-7.2-1.el7.x86_64.rpm │ │ └── glusterfs-thin-arbiter-7.2-1.el7.x86_64.rpm │ ├── p │ │ └── python2-gluster-7.2-1.el7.x86_64.rpm │ └── u │ ├── userspace-rcu-0.7.16-3.el7.x86_64.rpm │ └── userspace-rcu-devel-0.7.16-3.el7.x86_64.rpm └── repodata ├── 047503df3313d596e14a1a0d097b6c2261b26690000ecd4260d212a6f5e5632d-other.sqlite.bz2 ├── 34c1f5dd954099816d6cce289e52f96e61cc2e6430e13072194e35c063b0e3da-primary.xml.gz ├── 6293e07e4c5a7acc2c610beb5acb84b996329ef3c6d61c03e375f2afc6a71536-filelists.sqlite.bz2 ├── 6f89e8b43fb7e384f86f041c4de84d9afeb15dca981559b15230cb48887095db-other.xml.gz ├── bef236563d185417fbda48e3b4dd1d62714d1af2b7a7d6dc1a7213af5de1aa9b-primary.sqlite.bz2 ├── fb66c148e8e2738bd5d19b88d1b3507b0383aaab0938de3809b399babb1a0b44-filelists.xml.gz ├── repomd.xml └── repomd.xml.asc From a usage perspective that will not change the way pkgs can be consumed, as repodata will always be at the right place, but in the case of SCLs that will mean no subdirectory like before, but instead just same "first letter" name (while repodata will be global) So in the current stage, we'd like to deploy and fully validate the signing setup and we'll announce on this list when we'll fully switch to new system. Also worth noting that with the new system in place, in theory we'll *not* use the old cbs-content-control git repo (as we'll query automatically koji for tags, enabled architectures, etc) so tagging to -testing and -release should trigger automatically the "push to mirrors" step If you have questions, comments, feel free to answer in this thread and/or #centos-devel on irc.freenode.net Kind Regards, Thomas and Fabian -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

8 18

Trimming/Removing EOL SIG content from mirror.centos.org
by Fabian Arrotin 16 Mar '20

16 Mar '20

Hi all SIG members, When working in our "Staging" environment while validating the new signing process (still to be announced when fully in use/prod), we detected some SIGs having multiple variants/versions of their packages. Just one example (already discussed with Niels and Kaleb in #centos-devel but let's just this one a example): Gluster has multiple versions still listed on mirror.centos.org : http://mirror.centos.org/centos/7/storage/x86_64/ As the new process would automatically decide where to push content based on koji/cbs tag name, we found the interesting corner case of gluster312. The CBS tag is storage7-gluster-312-release and so new process would push to centos/7/storage/x86_64/gluster-312/ instead of http://mirror.centos.org/centos/7/storage/x86_64/gluster-3.12/ (see the diff betwen koji/cbs tag and the final path/destination) It seems that only Gluster was impacted for older releases, while it should be good for new releases (tested). But so that brings the following request : can you come with a list of EOL repositories that you'd like us to trim/remove from mirror.centos.org (they'll be archived to vault.centos.org) ? Doing that at the same time as we launch the new signing/push process would be a good idea. Thanks a lot in advance for your collaboration ! -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab

5 9

CPE Weekly:2020-03-14
by Aoife Moloney 14 Mar '20

14 Mar '20

--- title: CPE Weekly status email tags: CPE Weekly, email --- # CPE Weekly: 2020-03-06 Background: The Community Platform Engineering group is the Red Hat team combining IT and release engineering from Fedora and CentOS. Our goal is to keep core servers and services running and maintained, build releases, and other strategic tasks that need more dedicated time than volunteers can give. For better communication, we will be giving weekly reports to the CentOS and Fedora communities about the general tasks and work being done. Also for better communication between our groups we have created #redhat-cpe on Freenode IRC! Please feel free to catch us there, a mail has landed on both the CentOS and Fedora devel lists with context here. ## Fedora Updates * Fedora 32 Beta work is underway * Fedora Minimal Compose is being worked on with a dedicated ODCS backend running being investigated * Check out the Fedora Council video meeting to find out more about our team here https://www.youtube.com/watch?v=QN8HqBeoozo * Take a look at our (work in progress!) project taiga board to see what we're working on now, next, and still to do! https://tree.taiga.io/project/amoloney1-cpe-team-projects/kanban?epic=null * Have a read of one of our teams article in Fedora magazine: https://fedoramagazine.org/fish-a-friendly-interactive-shell ### Data Centre Move * Communishift will be unavailable from 2020-04-13 until 2020-05-08 * Check out our detailed move shedule here https://hackmd.io/R3EkjzVyTG2TYwQvkfzYrA?sync=&type= ### AAA Replacement * OTP & 2FA authentication is now working! * Fedora messaging is also integrated in the project * As always, check out our progress on github here https://github.com/orgs/fedora-infra/projects/6 ### CI/CD * Progress on tagging package history: tests, robustness * Progress on koji plugin to run the rpmautospec * Most work in this repo: https://pagure.io/Fedora-Infra/rpmautospec ### Sustaining Team * Mbbox upgrade work underway with the team looking at operators to deploy and maintain the different services * Infra tickets are starting to be prioritized https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapr… * Looking at the ansible operator https://github.com/fedora-infra/mbbox/issues/5 * Creating mbbox sustaining project https://github.com/fedora-infra/mbbox/projects/1 * Vagrant OpenShift 3.11 for mbbox https://github.com/fedora-infra/mbbox/pull/1 ## Docs ### Misc Updates/Review Requests * PR Reviews needed for the following: * Vagrant Operator SDK for mbbox review https://github.com/fedora-infra/mbbox/pull/9 * Rebase Silverblue to Fedora 32 - multi monitor setup issue https://bugzilla.redhat.com/show_bug.cgi?id=1810070 * Fedora magazine: Article proposals about Silverblue rebase to F32 https://pagure.io/fedora-magazine-proposals/issue/60 https://pagure.io/fedora-magazine-proposals/issue/59 * Packit integration in the-new-hotness https://github.com/packit-service/packit/issues/689 * KeepassXC flatpak issue https://pagure.io/flatpak-module-tools/issue/6 * Jms-messaging-plugin reviews https://github.com/jenkinsci/jms-messaging-plugin/pull/162 * Misc Updates: * Helped firefox maintainer sort out koji auth * Gathered logs for qgis maintainer to debug why builds hang * Checked over rawhide compose after open-h264 repo was enabled by default to make sure no content from it got in. * PR sent to fix f32 media with rawhide kickstarts * Migrated fedora-comps to weblate. * Upgraded koji to 1.20.1 via freeze break * PR's Created this week: * Bodhi 5.2 PR reviews https://github.com/fedora-infra/bodhi/pull/3945 https://github.com/fedora-infra/bodhi/pull/3940 https://github.com/fedora-infra/bodhi/pull/3933 https://github.com/fedora-infra/bodhi/pull/3931 https://github.com/fedora-infra/bodhi/pull/3910 https://github.com/fedora-infra/bodhi/pull/3903 https://github.com/fedora-infra/bodhi/pull/3798 * Infra tickets https://pagure.io/fedora-infrastructure/issue/8684 https://pagure.io/Fedora-Infra/review_stats/issue/2 * Fedmsg-koji-plugin https://pagure.io/koji-fedmsg-plugin/pull-request/12 https://pagure.io/koji-fedmsg-plugin/pull-request/13 * Fedora-messaging https://github.com/fedora-infra/fedora-messaging/pull/163 ## CentOS Updates ### CentOS * CentOS CI uptime is 100% * Kickstarter for CentOS 8 arch ppc64le * Check out the mail thread about dealing with unshipped -devel packages for CentOS Linux & Stream too https://lists.centos.org/pipermail/centos-devel/2020-March/036644.html ### CentOS Stream * Python38 module is running in c8S! * More work being done on the contributor workflow too with help from the Packit Team As always, feedback is welcome, and we will continue to look at ways to improve the delivery and readability of this weekly report. Have a great weekend! Aoife Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford

1 0

Upcoming CentOS events and COVID-19
by Rich Bowen 12 Mar '20

12 Mar '20

TL;DR: We have postponed the upcoming Dojo at Facebook, and are carefully watching the situation to determine any other event participation in the coming months. Due to the developing situation with the Corona virus and COVID-19, we have made the decision to postpone our upcoming CentOS Dojo that was scheduled to occur at Facebook on April 24th. Details of that event are here - https://wiki.centos.org/Events/Dojo/Facebook2020 - and will be updated once a new date has been selected. Other upcoming events are still scheduled to occur, as they are farther out. The next scheduled event will be at CERN on October 23rd, and we will update details as we get closer. Details for that event are available at https://wiki.centos.org/Events/Dojo/CERN2020 and the call for presentations is still open. Our planned booth presence at other upcoming events has been canceled for the foreseeable future, and we will update our event listing at https://wiki.centos.org/Events once the world situation improves and travel is once again feasible. There are several other proposed Dojos in the works at this time, but we are not going to publish any details until the epidemic crisis has passed. Thank you for your patience and understanding, and we'll send updates here once things become clearer. -- Rich Bowen - rbowen(a)redhat.com @CentOSProject // @rbowen 859 351 9166

1 0

CentOS 8 Stream: new python38 module
by Carl George 11 Mar '20

11 Mar '20

Howdy everyone, The CentOS team is pleased to announce that we have added a python38 module to CentOS 8 Stream. This has been published and is currently propagating out to the mirror network. We're hoping to get developer feedback on this module to help demonstrate the value of Stream and identify any potential issues before they make their way into RHEL and regular CentOS. We've listed some notable features below that python38 provides over the existing python36 module. We won't always announce updated Stream packages like this, but we wanted to highlight some of the early successes as we figure out the Stream workflow. Enjoy! * Built-in breakpoint() * https://docs.python.org/3.7/whatsnew/3.7.html#pep-553-built-in-breakpoint * https://realpython.com/python37-new-features/#the-breakpoint-built-in * Data classes * https://docs.python.org/3.7/whatsnew/3.7.html#dataclasses * https://realpython.com/python37-new-features/#data-classes * Overhauled asyncio module * https://docs.python.org/3.7/whatsnew/3.7.html#asyncio * https://realpython.com/python37-new-features/#asyncio-face-lift * Assignment expressions (walrus operator) * https://docs.python.org/3.8/whatsnew/3.8.html#assignment-expressions * https://realpython.com/python38-new-features/#the-walrus-in-the-room-assign… * F-strings support = for debugging * https://docs.python.org/3.8/whatsnew/3.8.html#f-strings-support-for-self-do… * https://realpython.com/python38-new-features/#simpler-debugging-with-f-stri… -- Carl George

1 0

Minutes for CentOS Board of Directors 2020-02-12
by Karsten Wade 11 Mar '20

11 Mar '20

[These are publishing a little late, I got busy and fell behind partially because the agenda/minutes process has multiple steps where blockages occurred. I'll keep working to improve the underlying process to make the production of these agendas and minutes more reliably consistent.] https://blog.centos.org/2020/03/minutes-for-centos-board-of-directors-2020-… On 2020-02-12 the CentOS Board of Directors met and discussed several ongoing efforts across the Project. The opening discussion was around the new work to evolve the project logo and branding identity being conducted in open channels. Overall the Directors really liked the direction the effort is going and were quite pleased with the open nature of the process. What is needed to bring a conclusion and present a final design for the Board’s approval is the completion of the open design discussion and decision process to be conducted in centos-devel. As the Board is working on adding new Directors and improving governance and transparency, there is an open discussion around the possibility of having a face-to-face meeting of the Board in 2020. This ideally would include an additional day of interactions with other project leadership. One idea floated was to conduct this prior to the CentOS Dojo being planned at CERN in October 2020. At the time of this writing, it is unknown if this Dojo will be affected by COVID-19 related or other travel restrictions. On another topic, in addition to the focused resources of the Community Platform Engineering (CPE) team that supports the CentOS Project in technical ways, Karsten gave a brief explanation of how the Community Architects from the Red Hat Open Source Program Office (OSPO) are in support of the project, specifically Rich Bowen on the community side, Brian Exelbierd on the business interaction side, and Karsten Wade on the strategic and visionary side. >From the Brussels Dojo, Karsten gave a report out about how he had a meeting room for one-to-one discussions with community members. These discussions were an invitation to talk about what works and doesn’t work for users and contributors around the project; an open office hours to hear out anything. It also served to help get an idea of how and why people use CentOS as a platform. This work is to help inform the CentOS 2020 open goals discussion now underway. In support of these efforts, the Board came to the following decisions, resolutions, and agreements: 1. Logo redesign 1. AGREED: Board is requesting Tuomas to lead the discussion on centos-devel toward creating the final /branding redesign proposal for the Board to give final approval on. This process should follow an open decision process of inviting participation, hearing out other ideas, and taking and incorporating feedback on the existing design ideas into the final plan. All this can be done over a reasonable time period of four to eight weeks, so that a decision can be reached that has an opportunity to include voices from across the community. 2. Board face-to-face 1. AGREED: Board will watch the travel situation with an eye toward deciding yay/nay on the face-to-face as the June timeframe approaches. 2. ACTION: Board will request RIch Bowen to coordinate with the Board Secretary on plans for adding meetings around the CERN Dojo. 3. Consent items 1. Adopt minutes from 2020-01-08 meeting 2. Noting that Fabian Arrotin has resigned his role as a CentOS Project Director as of October 2019. 4. Rolling (last from 2020-01-08): 1. Any other topics aka What other things do you want on our master initiatives list? 2. Stepping-up our meeting norms 3. Transparency initiatives Present at the meeting: * Ralph Angenendt * Jim Perrin * Mike McLean * Karsten Wade (Secretary) * Johnny Hughes -- Karsten Wade [he/him/his]| Senior Community Architect | @quaid Red Hat Open Source Program Office (OSPO) : @redhatopen https://community.redhat.com | https://next.redhat.com | https://theopensourceway.org gpg: AD0E0C41 | https://red.ht/sig

1 0

Packages dropping out of modules
by Paul Clifford 10 Mar '20

10 Mar '20

Earlier this month this was a report that softhsm was available but not installable in CentOS 8 due to a "No available modular metadata for modular package" error. The solution was to enable the idm:DL1 module, but my understanding is that modular packages shouldn't be visible while their modules are disabled (this seems to be the behaviour in RHEL 8). Looking in http://mirror.centos.org/centos/8/AppStream/x86_64/os/Packages/ there are two versions of softhsm in the AppStream repository: * softhsm-2.4.0-2.module_el8.1.0+253+3b90c921.x86_64.rpm * softhsm-2.4.0-2.module_el8.1.0+265+e1e65be4.x86_64.rpm The repository's modules.yaml file only describes one version of the module, idm:DL1:8010020200121181805:4a0acb9a:x86_64, which owns the newer package. When idm:DL1 is enabled this masks the older softhsm version but when it's disabled (the default) the newer package is removed from view, and with no repository metadata to indicate that the older softhsm is part of a module it effectively becomes an ordinary member of the AppStream repository. So "dnf install softhsm" offers two different package versions based on whether or not idm:DL1 is enabled, instead of failing with "Error: Unable to find a match" when the module is disabled. You can see a similar thing with the go-toolset module. It's enabled by default and disabling it should hide all of its packages. Instead, because a second version has been published (see the two versions of go-toolset, golang, etc at the earlier URL), disabling go-toolset makes the previous versions of all the packages appear as ordinary members of the AppStream repository. I found https://bugs.centos.org/view.php?id=16808 from around the time of the 8.0 release querying the lack of older version data, and have commented on it, but I wanted to confirm that I haven't misunderstood the expected behaviour. For example, if nodejs:12 receives an update and the earlier package versions drop out into the main AppStream repository it seems that this might cause conflicts for someone installing nodejs from a third party repository, even if they've disabled nodejs:12.

6 8

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