[FrontPage] [TitleIndex] [WordIndex

This is a read-only archived version of wiki.centos.org

Include: Nothing found for "^== Future SIGs ==$"!

Special Interest Groups

Special Interest Groups (SIG) are smaller groups within the CentOS community that focus on a small set of issues, in order to either create awareness or to focus on development along a specific topic. Each SIG can seek a dedicated section on the wiki, along with an option to display the names of the people involved in that SIG. A mailing list on the CentOS list server can also be setup as well. As proper, and subject to available resources, other resources they might need (eg. a SCM system, web hosting space, admin services, etc.) may be offered.

SIGs, and the process for creating one, are described in more detail in the SIG Guide. Active SIGs hold regular meetings, where you can find out what's happening and how to get involved.

The following SIGs already exist:

0.1. Active SIGs

  • Core - Produces the CentOS Linux Distribution

  • Alternative Architectures - Extend usability base beyond basic architectures (x86_64), including ARM 64-bit and 32-bit, x86 32-bit, Power 8, and so forth.

  • Alternative Images - build and provide alternative iso images for CentOS Stream.

  • Artwork - Improving the user experience with high quality artwork

  • Automotive - Software related to Automotive

  • Cloud - The Cloud SIG will look into issues around running Cloud Infrastructure / Hypervisor for onpremise clouds as well as support other SIGs and projects looking to consume some of the shared resources around on-premise cloud infra

  • Config Management - a Special Interest Group to cover configuration management and system lifecycle management on CentOS.

  • Hyperscale - Enable CentOS Stream deployment on large-scale infrastructures

  • Infrastructure - Coordination of CentOS project infrastructure

  • Kmods - Provide kernel modules currently not available in CentOS Stream.

  • Messaging - Description needed

  • NFV - Network Functions Virtualization (NFV) provides a CentOS-based stack that will serve as a platform for the deployment and testing of virtual network functions (VNFs).

  • Operational Tooling - Logging, monitoring and other operational tool development.

  • Promo - Promotion and Events

  • Public CI - A Public testing and proving infrastructure

  • Software Collections - Tools and packages that allow the build, install, and use multiple versions of software on the same system, without affecting system-wide installed packages.

  • Storage - Deploying CentOS as a storage node

  • Virtualization - Virtualization in and of CentOS

  • CentOS Stream Feature Request - A gate for feature requests that are first developed in CentOS Stream from contributors who wish to request these features to be included in future RHEL releases

0.2. Proposed SIGs

Voice your interest and opinion on the centos-devel@centos.org mailinglist if you wish to get involved in any of these efforts.

  • Documentation - Encourage and manage CentOS documentation (website, wiki, FAQ)

  • Hardening - Deliver a more secure and hardened general purpose kernel and corresponding code

  • VoIP - The voice over IP communities run systems in a way that sometimes don't align with conventional business or hosting policies, we should get a group going with skilled domain experience, so we can better address the needs of that community.

  • Simplified Linux Server - Menu driven installation and configuration for various services.

  • Education - Deliver a pre-contextualised media set for use in Schools, Universities and other education venues

  • ARM, Tilera, Mips, Itanium, S390, Alpha, Sparc port
  • Alternative Desktop - Add additional desktop oriented software and features

  • Hardware compatiblity - Collect information about specific hardware (laptops, devices, printers)

  • RPM Packaging
  • Translation - In charge of translating CentOS (media, website, wiki, flyer)

  • Hosting - Web hosting comes with its own challenges, it would be great to have a specialist group look into the challenges presented there and work on potential solutions from both the provider side and the consumer perspective.

1. Retired/Inactive SIGs

  • Atomic - The AtomicSIG aims to build, deliver and maintain an Atomic Host for CentOS Linux. And help bootstrap tooling around the effort.

  • Cloud Instance - Look into issues around running CentOS Linux Instances in various private and public clouds

  • Xen4CentOS - A Xen 4 (4.4, 4.6, 4.8) implementation for CentOS Linux 6 and CentOS Linux 7. Later absorbed into the Virtualization SIG

  • PaaS - Platform as a Service on CentOS

2. Setting up a new SIG

Anyone can propose to setup a SIG, but needs to get the agreement and participation of a member of the CentOS Governing Board. To request a new Special interest group to be started, here is what needs to be done:

  • Look at the presently functional SIG's and make sure that your effort will not overlap with another team
  • Open a new discussion topic in the CentOS-Devel mailing list, asking for comments
  • One of the CentOS Board members will need to join the effort, once that happens then that Board member can :
    • Request a new mailing list to be created (if needed)
    • Request a wiki section to be setup
    • If the SIG needs a version control system to be setup, that can also be requested (refer to the next section on git repo)
    • Get listed as a SIG on this page

Initiating a SIG git repo + koji process:

  • SIG must be approved by the Board
  • SIG needs to post its proposal to its wiki page
  • Chair should do requesting, alternatively the Board member mentoring the SIG can do the request
  • Chair requests wiki ACLs for all SIG committee members
  • SIG meets with Infra SIG member to discuss how the git repo is going to be setup
  • SIG will need a SIG-specific signing key to live on CentOS Project signing server and/or locally to the builder (process needs some improvement here)
  • Chair or Board mentor need to request a build tag on bugs.centos.org under buildsys component
  • Chair or Board mentor need to request koji targets and tags on bugs.centos.org under buildsys component
  • Chair or Board mentor need to request import of SRPMs to be imported in to git.centos.org RPM store, reqest via bugs.centos.org under buildsys component
  • Chair or Board mentor need to request koji certs for SIG members on bugs.centos.org under buildsys component
  • Chair or Board mentor needs to request a SIG project to be added to bugs.centos.org, or to add a component to another project e.g. CentOS-7

More detailed SIG information may be found in the SIG Guide

3. Requirements

We expect each SIG to meet some basic requirements, these include :

  • The topic for the group must be related to CentOS, or a use scenario for CentOS

  • There must be adequate control and feedback into the CentOS community

  • Generally, all communication as to the work of the SIG should be public, understanding that sometimes a matter may need to be private; in such cases, please consult with the Devteam member out of band of the SIG
  • All code produced within the SIG must be compatible with a FOSS license presently used by CentOS; if a new license is wanted, again, please consult with the Devteam member
  • All documentation produced within the SIG must be compatible with the license of this wiki

  • We would expect teams to be watchful of general CentOS directions from the Devteam

  • At least one member of the SIG, who need not be the lead, needs to be a member of the CentOS Devteam. We are not trying to enforce any moderation, however, we feel that the actions of each SIG using CentOS resources needs to have visibility to the Devteam

4. SIG membership

Normally, the following rules for SIG membership apply:

  • The mailing lists of the SIGs are open, and can be joined freely.
  • SIG members are appointed by the SIG team leader, and may have elevated privileges, like write access to the relevant Wiki section or git repo, depending on the role of the SIG member.
  • The SIG team leader may be asked to be a mailing list moderator; generally however, CentOS mailing lists are not moderated.

5. SIG Reporting

SIGs are expected to report quarterly, with a brief summary of what they've accomplished in the past quarter. A suggested outline for this report is as follows:

  • Membership update (members added, removed. Chair changes.)
  • Releases in the most recent quarter (or most recent release, if none in that quarter)
  • Health report and general activity narrative.
  • Issues for the board to address, if any

The reporting schedule is currently as follows:

Group 1:

Reports January, April, July, October

  • Core
  • Config Management
  • Software Collections
  • Hyperscale
  • kmods
  • Automotive

Group 2:

Reports February, May, August, November

  • Alt Arch
  • Cloud
  • NFV
  • Promo
  • Storage
  • Messaging

Group 3:

Reports March, June, September, December

  • Artwork
  • Cloud Instance
  • OpsTools

  • Public CI
  • Virtualization
  • Infrastructure

Reports are due by end of business on the first Monday in the designated month, and should be sent to the centos-devel mailing list with a subject line of "[REPORT] XYZ SIG", where 'XYZ' is replaced with the name of your SIG. Reports are to be submitted by the SIG chair.

CentOS Properties

0.1. accounts.centos.org

URL: https://accounts.centos.org

Description: ACO is the place to ask for access to the Community Build System.

Technology: accounts.centos.org is an instance of noggin, deployed in front of merged IPA instances for both Fedora and CentOS Projects (so one account is good for both projects)

Contact: The CentOS Infrastructure Team (#centos-devel on freenode) or the centos-devel mailing list.


0.2. git.centos.org

URL: https://git.centos.org

Description: git.c.o is the authoritative repository of package sources that go into CentOS Linux 7. git.c.o also contains repositories for SIG use and sources for other parts of the CentOS Project

Technology: git.c.o is an instance of Pagure

Contact: The CentOS Sysadmin Team - (#centos-devel on Freenode) or the centos-devel mailing list.


0.3. cbs.centos.org

URL: http://cbs.centos.org

Description: The Community Buildsystem is where Special Interest Groups build and manage packages for inclusion in their released repos

Technology: CBS is an instance of the Koji buildsystem

Contact: The CentOS Infrastructure Team (#centos-devel on Libera.chat) or the centos-devel mailing list.


  • Scratch builds on cbs.centos.org currently persist and are not expired, unlike the Fedora Project hosted Koji.
  • All image builds must be run as scratch builds at this time

0.4. mirror.centos.org

mirror.centos.org is where the content produced by SIGs end up to. mirror.centos.org is served by 50+ servers around the world and GeoIP is used to direct the user to a nearby mirror. The mirror.centos.org machines and their bandwidth are donations to CentOS and they are managed by the CentOS infra team.

While that may sound neat (and it is!) there's an even better option for distributing the files to users. All the content on mirror.centos.org is mirrored by 600+ external mirrors, giving better geographical coverage than what is possible with only mirror.centos.org servers. Using the external mirrors frees up some bandwidth from mirror.centos.org servers, which are also used for syncing the content to those external mirrors. You can use the external mirrors by specifying a mirrorlist option in your repository config file. Details about this can be found in the "Building a centos-release-* package" section.

0.5. Devcloud

Describe Properties/Devcloud here.

The SIG Process

Anyone may propose and/or participate in a Special Interest Group, here are some guidelines and tips related to the workings of a SIG.

0.1. Proposal

Creating a new SIG requires participation from a member of the CentOS Governing Board, and a SIG must meet some requirements:

0.1.1. Requirements

  1. The topic must be related to CentOS, or a use scenario for CentOS
  2. There must be adequate control and feedback into the CentOS community
  3. Generally all communication as to the work of the SIG should be public, understanding that sometimes a matter may need to be private. In such cases, please consult with the sponsoring Governing Board member
  4. All code produced within the SIG must be compatible with a FOSS license presently used by CentOS
  5. All documentation produced within the SIG Must be compatible with the license of this wiki
  6. SIGs should be mindful of general CentOS directions from the Governing Board
  7. One member of the SIG should be a member of the Governing Board/Devteam

0.1.2. The Proposal Process

  1. Check to see if the topic of collaboration is already covered by an existing SIG
  2. Post an introductory 'RFC' email to the centos-devel mailing list and ask for comments
  3. Find a CentOS Governing board member to join the effort
  4. The board member will:
    1. Request any initial resources be created
    2. List the SIG on the SpecialInterestGroup page in the wiki

0.2. Acceptance

The sponsoring member of the Governing board will put the proposal at a regularly scheduled board meeting. The Board will, if the proposal is accepted, give its charter to the SIG to begin its work.

SIG founders should stay in close contact with their sponsor through this process to work out any questions arising from the proposal.

0.3. Account Setup

0.3.1. Community Buildsystem

0.4. Building in CBS Prerequisites

To be able to submit tasks/builds to https://cbs.centos.org, you need first :

For all the steps, consider reading the Authentication dedicated wiki page

0.4.1. ci.centos.org Open a Bug
  1. Visit https://pagure.io/

  2. Report an Issue under the centos-infra tracker https://pagure.io/centos-infra/issues/

  3. Include the following information in your report:
    • Your Name
    • The project you are working with
    • Your Desired Username
    • Your Email Address
    • Your gpg pubkey (should be already in ACO normally) Account Approval

Special Interest Group Members: Contact your SIG Chair to comment his/her approval on the bug

Upstream Projects: We will work with you to designate a coordinator to approve new members of your project in ci

0.4.2. Devcloud

0.5. Requesting Resources

0.5.1. Content Signing Key

0.5.2. Mailing Lists

0.5.3. IRC Channels

0.5.4. Bug 'Projects' in tracker

The SIG Sponsor (board member) handles requests for a SIG Project in https://pagure.io/centos-infra/issues/.

The SIG should agree on this at a regularly scheduled meeting and contact the sponsor for next steps.

0.5.5. SIG Bot accounts for CBS

Some SIGs may want to use a bot account for automated builds in CBS from CICO or other infrastructures. Requirements
  1. The account name is the shortname of the sig (cloud, configmanagement, cloudinstance) etc
  2. The email on the account must be deliverable to someone who can change the certificate in the production environment

The account approval process follows the usual sponsorship model. Be sure to notify one of the ACO admins and they will sponsor the account into the appropriate group.

0.5.6. CBS Tags

To request new tags in CBS open a request

Be sure to include the following information:

  • The name of the SIG
  • The SIG project
  • The release string of the project (if any)

Tags in CBS follow the following format: <signame><centos_version>-<project>-<release_string>-{candidate,release,testing}

Example: cloud7-openstack-kilo-testing





Release String:


If the requestor is not the SIG Chair, the Chair should comment on the bug with a +1 or -1 to approve or deny the new tags.

0.6. Daily Workings (Meetings)

Running a SIG Meeting can be much easier with an agenda, and a few snippets for calling out things for the minutes.

0.6.1. Meetbot Commands

We'll use some examples from previous CBS meetings.



Sample usage

#startmeeting <name_of_your_meeting>

Tells centbot to begin a meeting

#startmeeting CBS/Infra


Ends the currently running meeting


#chair <list_of_nicks>

Meetbot chairs can do administrative commands (like #undo, #agreed, #topic). The person who starts the meeting is automatically a chair

#chair alphacc Arrfab kbsingh

#topic <text>

Starts a topic for discussion. This shows up as a section in the Meeting Summary portion of the minutes

#topic Status Updates

#info <some_text>

Adds a line in the Meeting Summary under the currently active topic

#info First Config Management SIG Meeting: Wed Mar 23 16:00:00 UTC 2016 in #centos-devel

#action <nick_of_someone> <todo_item_they_should_do>

Registers a todo item for the named person

#todo bstinson to follow up on the arm64 builder

#agreed <something_the_group_decided>

This announces a decision of the group, reached by either a vote or by lazy consensus

#agreed The meeting time will be 14h00 UTC

0.6.2. Publishing the Minutes

After the meeting is closed, your minutes will show up under: http://www.centos.org/minutes/

Managing Content

0.1. Importing to Version Control

Package sources checked into git.centos.org are in exploded SRPM format. This means that the package working directory should have at least a SPECS/ subdirectory. New Package (from source)

If the package you'd like to build isn't yet on https://git.centos.org, create first a ticket on https://pagure.io/centos-infra/issues to request the git repo for /rpms/<your_package> to be created

Once it will be created, it will be possible for you to push to *specific* branches, based on the following rules: c{7,8}-<sig_name>*

So that means that if I'm member of the sig-core group (in ACO), I'll be able to commit/push to c8-sig-core or c8-sig-core-whatever-I-want branches

Let's use the following example : I need to create a branch for pkg centpkg-minimal, and I'm member of the sig-core SIG group. We have to push two things to git.centos.org :

  • .spec files to build a src.rpm
  • eventually blob (.tar.gz archive) that will need to be pushed to lookaside cache

Warning : to push to lookaside cache you need to have already a local check out from https://git.centos.org/centos-git-common Pushing first to lookaside cache

Let's assume that my pkg centpkg-minimal that I want to build has an archive called centpkg.minimal.tar.gz. To be able to push to lookaside cache, we need the following :

  • a valid TLS cert (also needed to build on cbs.centos.org) obtained through centos-cert util
  • lookaside_upload script in your $PATH (coming from centos-git-common git repo, see above)

This simple script would need some paramters:


You need to call the script like this : ~/bin/lookaside_upload -arguments

        -f : filename/source to upload (required, default:none)
        -n : package name for that source (requred, default:none, example "httpd")
        -b : "branch" where to upload to (required, default:none, example "c7-sig-core")
        -h : display this help

So back to our example, the pkg name is centpkg-minimal, file is centpkg-minimal.tar.gz and I'm member of the sig-core group, and want to build it for c7, so we'll call it like this :

lookaside_upload -f centpkg-minimal.tar.gz -n centpkg-minimal -b c7-sig-core
[+] CentOS Lookaside upload tool -> Checking if file already uploaded
[+] CentOS Lookaside upload tool -> Initialing new upload to lookaside
[+] CentOS Lookaside upload tool -> URL : https://git.centos.org
[+] CentOS Lookaside upload tool -> Source to upload : centpkg-minimal.tar.gz 
[+] CentOS Lookaside upload tool -> Package name: centpkg-minimal
[+] CentOS Lookaside upload tool -> sha1sum: d6616b89617914a0dd0fd5cfa06b0afc7a4541c4
[+] CentOS Lookaside upload tool -> Remote branch: c7-sig-core
[+] CentOS Lookaside upload tool ->  ====== Trying to upload =======

################################################################################################################ 100.0%
File centpkg-minimal.tar.gz size 15178 CHECKSUM d6616b89617914a0dd0fd5cfa06b0afc7a4541c4 stored OK
[+] CentOS Lookaside upload tool -> Validating that source was correctly uploaded ....
[+] CentOS Lookaside upload tool -> [SUCCESS] Source should be available at https://git.centos.org/sources/centpkg-minimal/c7-sig-core/d6616b89617914a0dd0fd5cfa06b0afc7a4541c4

Now that we have uploaded to lookaside cache, we can reference it in our /rpms/centpkg-minimal git repository on git.centos.org, see below Pushing to git.centos.org

We should already have a local checkout of the git repository for the pkg we'd like to work on. In our case, the git repo url is https://git.centos.org/rpms/centpkg-minimal

So the way to git clone/pull over ssh is so ssh://git@git.centos.org/rpms/centpkg-minimal.git :

git clone ssh://git@git.centos.org/rpms/centpkg-minimal.git
Cloning into 'centpkg-minimal'...
remote: Counting objects: 15, done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 15 (delta 2), reused 0 (delta 0)
Receiving objects: 100% (15/15), done.
Resolving deltas: 100% (2/2), done.

Important : You can clone over https, but then it wouldn't let you push back to it, as it needs ssh with key verification and based on group membership for acls

Let's create a new c7-sig-core branch (still based on the assumption that I want to build for c7) :

git checkout -b c7-sig-core

You can now create your SPECS/<pkg_name>.spec and add also other text patches under SOURCES/ We still need also to point to /sources/ for the lookaside cache, so we'll use the value of the hash returned when we successfully uploaded to lookaside cache and we'll write a .<pkg_name>.metadata file in the root dir that will look like this in our example:

d6616b89617914a0dd0fd5cfa06b0afc7a4541c4 SOURCES/centpkg-minimal.tar.gz

Now that we have pointer to lookaside cache, and also .spec, we can push back to git and we should be able to proceed with the "build-from-git" on cbs.centos.org. Let's commit first :

# git add <files> # if needed
git commit -a 
git push origin c7-sig-core # to create the c7-sig-core branch on git.centos.org if not existing yet

0.2. Building In CBS

The current workflow for submitting builds to CBS is to generate a Source RPM in the developer's working directory for submission to the builders. A developer needs an active CBS account and the client tools installed on their workstation (see SIGGuide#CBSAccount). Generating a Source RPM

Still allowed for now and for --scratch builds, but building from git.centos.org is the way to go

[bstinson@localhost new-package]$ rpmbuild --define "%_topdir `pwd`" -bs SPECS/new-package.spec

0.2.1. Short detour to describe Tags and Targets

When building in CBS it helps to understand where to send the sources to start a build, and where the built packages will come out the other end. Definitions
  • Build Target: Specifies the buildroot and destination of a package for submission. This is specified on the /usr/bin/cbs command line to direct the package into the correct place

  • Tag: A place for packages to be grouped together. Built packages can be added to a tag automatically (e.g. just after a build) or manually placed in a tag with the tag-build operation to /usr/bin/cbs Build Targets

Build targets are named according to the CentOS version, SIG, Project, Project Version, and Disttag they represent. Taking cloud7-openstack-kilo-el7 as an example:



CentOS Version








The build target will be assigned when a new set of tags is requested, and a list of current targets can be found at http://cbs.centos.org/koji/buildtargets Tags

When a chairperson requests a new set of build tags, the SIG is encouraged to adopt the default workflow:

[build] -> cloud7-openstack-kilo-candidate -> cloud7-openstack-kilo-testing -> cloud7-openstack-kilo-release

The buildroot for new packages includes repositories from:

  • The CentOS Linux base operating system
  • A collection of the latest builds of every package in the candidate tag.

This allows developers to satisfy dependencies by relying on content in the base OS or by making sure a proper version is tagged in to -candidate (either by building it through the corresponding build target, or by issuing the tag-build command to include an already-existing build). Build!

New Packages:

If your package has not been built before add it to the package list on your destination tags:

[bstinson@localhost new-package]$ cbs add-pkg --owner=bstinson cloud7-openstack-kilo-candidate new-package
[bstinson@localhost new-package]$ cbs add-pkg --owner=bstinson cloud7-openstack-kilo-testing new-package
[bstinson@localhost new-package]$ cbs add-pkg --owner=bstinson cloud7-openstack-kilo-release new-package

Scratch Build:

# Sending a source RPM to a scratch build
[bstinson@localhost new-package]$ cbs build --scratch cloud7-openstack-kilo-el7 SRPMS/new-package-1.0.1-2.el7.src.rpm

Scratch builds will show up in the CBS web interface, and the built RPMS will be downloadable from there, but the package will not be included in any of the CBS tags (or the repos generated from the tags). Scratch builds are used to test functionality before doing a proper tagged build.

Tagged (Normal) Build:

# Sending a source RPM to a build target 
[bstinson@localhost new-package]$ cbs build cloud7-openstack-kilo-el7 SRPMS/new-package-1.0.1-2.el7.src.rpm

Tagged builds will end up in the -candidate tag after it's finished building, and will be available in the buildroot in case other packages depend on it.

/!\ NOTE: There is a restriction in CBS that a package's Name-Version-Release must be globally unique. This means that if anyone else (even from another SIG) has built new-package-1.0.1-2.el7 you must use that build, or build a different version Building from git.centos.org

Instead of building locally a .src.rpm pkg and upload it to CBS to be built, you can submit a build request pointing to git.centos.org (see previous steps about lookaside and git push).

You just have to call cbs build pointing to git+https://git.centos.org/rpms/<pkg_name>.git#<commit_hash>

If you followed our previous example about centpkg-minimal package, we can easily retrieve from our git history the commit hash for the c7-sig-core branch that we just pushed to git.centos.org :

git log|head -n 1
commit ca63b53c8bde1efc91d55548f194dbecbf457cad

So to tell cbs builders to automatically retrieve all from git.centos.org (.spec / patches and lookaside artifact declared in .<pkg_name>.metadata) we can call it like this (based on our example and infrastructure7-el7 being our target for cbs tags, so it depends on your SIG/tags):

cbs build infrastructure7-el7 git+https://git.centos.org/rpms/centpkg-minimal.git#ca63b53c8bde1efc91d55548f194dbecbf457cad Frequent Error Messages
  • FAILED: BuildError: package new-package not in list for tag cloud7-openstack-kilo-candidate

    • Be sure you add the package to the list be sure to add it to the package list: See the New Packages section under the Build step

0.3. Automated Testing in ci.centos.org

Describe SIGGuide/Content/Testing here.

0.4. Releasing to the Mirror Network

There are 2 points in the process where packages can be promoted for wider consumption. Testing content can be distributed to the buildlogs.centos.org content delivery network for developers and CI systems to consume. Release-ready content can be promoted to a SIG-specific directory on mirror.centos.org for consumption by end-users.

As a first step, decide on the final release location of the repo on mirror.centos.org. You can use the same path for buildlogs.centos.org.

0.4.1. Pushing Test Content to Buildlogs

The new signing and push process in place since 2020-03-25 doesn't require anything than just tagging pkgs to -testing repository.

As soon as you will have "tag-built" packages to -testing, that will trigger a distRepo task on koji and also a push to buildlogs.centos.org Assuming that your tag is "cloud7-openstack-train-testing", and that you have three archictectures enabled (x86_64,ppc64le and aarch64) that means that it will appear on

0.4.2. Releasing content to mirror.centos.org Steps to request space on the mirror network

Same process as for -testing, except that current process is getting notification that pkgs are tagged in -release tag, and so would push to mirror.centos.org network (and so external mirrors) and also sign packages with correct SIG GPG key.

It will also push debuginfo pkgs to debuginfo.centos.org and src.rpm packages to vault.centos.org

Worth noting that for CentOS 7 only, x86_64 will be pushed to mirror.centos.org/centos/$path while other arches like ppc64le/ppc64/aarch64 will be pushed to mirror.centos.org/altarch/$path. The $contentdir yum variable can be used in your .repo files to select the branch (centos or altarch).

0.4.3. centos-release Packages

To deliver SIG packages to users, the yum repo files must be available in a package named centos-release-<component>. This centos-release-<component> package will be published in the CentOS Extras repository. That .repo file should also contain the gpg public key that permits signing validation of the downloaded artifacts from mirror nodes.

For example the cloud sig releases OpenStack Rocky using the repo definitions in centos-release-openstack-rocky. Building a centos-release-* package
  1. If you are a new SIG and don't have an assigned SIG gpg key (also with public key listed on https://www.centos.org/keys/#community-driven-project-keys) , you should file a bug report on https://pagure.io/centos-infra/issues/

Once you have received your gpg pub key, you can start composing your centos-release--* sig pkg.

  1. Ask for the centos-release-<SIG> pkg to be created a as repo on https://git.centos.org (for example https://git.centos.org/rpms/centos-release-openstack) : file a request on https://pagure.io/centos-infra/issues/

  2. Set up your content sources in the .repo file. For example, centos-release-openstack-rocky could have this definition for the main repository:
    name=CentOS-7 - OpenStack rocky
    There can also be other repositories defined in the .repo file, for example for testing, debuginfo and sources. See the other centos-release-* packages for examples. The above example uses mirrorlist.centos.org for selecting the closest external mirror. Using mirrors obtained via mirrorlist.centos.org is preferred, because it gives the user the fastest possible mirrors and decreases load from mirror.centos.org servers. The baseurl to CentOS-controlled mirror.centos.org is still available as a commented out backup. Note the use of $contentdir to select either centos or altarch.

    The repo parameter to mirrorlist.centos.org is constructed from the path by dropping the architecture and changing slashes to dashes. For example, files in cloud/x86_64/openstack-rocky can be found from a repository named cloud-openstack-rocky, and files in sclo/x86_64/rh/rh-python36 can be found from sclo-rh-rh-python36. Please make sure you get the path and repo names right in your .repo file. Content on mirror.centos.org is scanned every three hours, and any new repositories will be added automatically to the mirror crawler database.

  3. If this is the first build, add the new centos-release-mycomponent to the Extras tags
    [bstinson@localhost centos-release-mycomponent]$ cbs add-pkg --owner=bstinson core7-extras-common-candidate centos-release-mycomponent
    [bstinson@localhost centos-release-mycomponent]$ cbs add-pkg --owner=bstinson core7-extras-common-testing centos-release-mycomponent
    [bstinson@localhost centos-release-mycomponent]$ cbs add-pkg --owner=bstinson core7-extras-common-release centos-release-mycomponent
  4. Build the package in CBS against the Extras tag
    [bstinson@localhost centos-release-openstack-mycomponent]$ cbs build core7-extras-common-el7.centos centos-release-mycomponent-0.0.1-1.rpm
  5. File a bug to request content to be synced to mirror.centos.org (See SIGGuide#MirrorSpace)

  6. Tag the build to the testing tag
    [bstinson@localhost centos-release-openstack-mycomponent]$ cbs tag-build core7-extras-common-testing centos-release-mycomponent-0.0.1-1
  7. Do a test yum install of a package from the new repo

  8. When ready, tag the build to the release tag
    [bstinson@localhost centos-release-openstack-rocky]$ cbs tag-build core7-extras-common-release centos-release-mycomponent-0.0.1-1 Some Guidelines for centos-release-* packages
  • centos-release-* packages should be built as noarch RPMs

Collaborating with other SIGs

2023-09-11 07:19