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.

The following SIGs already exist:

0.1. Active SIGs

  • Core - Produces the CentOS Linux Distribution

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

  • Artwork - Improving the user experience with high quality artwork

  • 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

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

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

  • Infrastructure - Coordination of CentOS project infrustructure

  • 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.

  • PaaS - Platform as a Service on CentOS

  • 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

0.2. SIGs in planning/startup stage

  • Messaging SIG

  • High Performance Computing - Encourage the use of CentOS Linux in HPC and to address the specific needs in HPC deployments, including deployment and management automation.

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

0.3. Future/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.

  • 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)

  • RHEL Beta test-driving - Encourage people to try out RHEL Betas to improve future CentOS
  • 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 SIGs

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

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
  • PaaS
  • Software Collections

Group 2:

Reports February, May, August, November

  • Alt Arch
  • Cloud
  • NFV
  • Promo
  • Storage

Group 3:

Reports March, June, September, December

  • Artwork
  • Cloud Instance
  • OpsTools

  • Public CI
  • Virtualization

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: http://accounts.centos.org

Description: ACO is the place to ask for access to the Community Build System. Right now these accounts are only active for CBS

Technology: accounts.centos.org is an instance of FAS2

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

Notes:

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.

Notes:

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 Freenode) or the centos-devel mailing list.

Notes:

  • 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.3.1.1. Prerequisites

We provide a set of tools in the CentOS-Extras repository for building SIG packages in the Community Build System. If your development workstation is running CentOS 7:

    yum install centos-packager

Many of these tools will become the building blocks for Centpkg (HowTos/Centpkg).

If your workstation is on Fedora (23/24/25) there is a Copr available:

    dnf copr enable bstinson/centos-packager
    dnf install centos-packager

0.3.1.2. Step 1: Signing up for an account (ACO)
  1. Visit the Accounts System

  2. Select 'New Account'
  3. Fill out the form with your information

0.3.1.3. Step 2: Join a Special Interest Group

Your account will not be active in CBS until you are a member of a SIG

  1. After signing in to accounts.centos.org, choose 'Group List' and locate the SIG you are interested in joining. (SIGs are listed under 's', for example, 'sig-cloud'.)
  2. Apply for membership
  3. Speak with your SIG Chair to have your request approved

0.3.1.4. Step 3: Generating your user certificate

Your user certificate bundle comes in the form of 3 files:

Filename

Purpose

~/.centos.cert

PEM file with your X509 Client Certificate and Key

~/.centos-server-ca.cert

The CA Certificate from ACO

~/.centos-upload-ca.cert

The CA Certificate for the lookaside

To generate your certificate you can use the 'centos-cert' tool included in the centos-packager package:

  Usage: centos-cert [OPTIONS] 

Options:
  -h, --help            show this help message and exit
  -u USERNAME, --username=USERNAME
                        ACO Username.
  -n, --new-cert        Generate a new User Certificate.
  -f CERTFILE, --file=CERTFILE
                        User Certificate.
  -v, --verify-cert     Verify Certificate.

If you've signed up with the account name tuser, you can generate your new certificate like this:

    [tuser@myworkstation]$ centos-cert -u tuser -n
    ACO Password: <password_goes_here>

ArtWork/WikiDesign/icon-admonition-idea.png

Attention that centos-cert -u tuser -n will request a new certificate, so that will automatically revoke any other certificate you had in the past. If you need to use cbs/koji on multiple machines, just copy the files mentioned above on the other machine.

0.3.1.5. Step 3.1: Renewing your certificate

/!\ Your user certificate is valid for 6 months. If your certificate expires and you do not renew it after another 4 months, your account will be disabled in accounts.centos.org

To renew your certificate:

    [tuser@myworkstation]$ centos-cert -u tuser -n
    ACO Password: <password_goes_here>

0.3.2. ci.centos.org

0.3.2.1. 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)

0.3.2.2. 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.3.3. Devcloud

0.4. Requesting Resources

0.4.1. Content Signing Key

0.4.2. Mailing Lists

0.4.3. IRC Channels

0.4.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.4.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.

0.4.5.1. 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.4.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

SIG:

Cloud

Project:

Openstack

Release String:

Kilo

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.5. 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.5.1. Meetbot Commands

We'll use some examples from previous CBS meetings.

Command

Description

Sample usage

#startmeeting <name_of_your_meeting>

Tells centbot to begin a meeting

#startmeeting CBS/Infra

#endmeeting

Ends the currently running meeting

#endmeeting

#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.5.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.

0.1.0.1. New Package (from source)

To work on a package that is not already checked into git.centos.org from upstream sources:

# Let's start on a package called new-package by creating the rpm structure
[bstinson@localhost]$ mkdir -p ~/src/rpms/new-package/{SOURCES,SPECS}

[bstinson@localhost]$ cd ~/src/rpms/new-package/

# Write your spec file. Starting from scratch is ok, but rpmdevtools provides a skeleton
[bstinson@localhost new-package]$ rpmdev-newspec -o SPECS/new-package.spec

0.1.0.2. New Package (from existing SRPM)

To work on a package that is not already checked into git.centos.org from an existing Source RPM:

# Let's import new-package-1.0.1-2.el7 from a source RPM into an empty workspace
[bstinson@localhost new-package]$ rpm --define "%_topdir `pwd`" -Uvh ~/Downloads/new-package-1.0.1-2.el7.src.rpm

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).

0.2.0.1. Generating a Source RPM

[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.

0.2.1.1. 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

0.2.1.2. 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:

SIG

cloud

CentOS Version

7

Project

openstack

Version

kilo

Disttag

el7

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

0.2.1.3. 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).

0.2.1.4. 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

0.2.1.5. 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

0.4.2.1. 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.

0.4.3.1. 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:
    [centos-openstack-rocky]
    name=CentOS-7 - OpenStack rocky
    mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=cloud-openstack-rocky
    #baseurl=http://mirror.centos.org/$contentdir/$releasever/cloud/$basearch/openstack-rocky/
    gpgcheck=1
    enabled=1
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Cloud
    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

0.4.3.2. Some Guidelines for centos-release-* packages
  • centos-release-* packages should be built as noarch RPMs

Collaborating with other SIGs

BrianStinson/Testing (last edited 2019-12-09 09:11:19 by anonymous)