LEAP SOP

Introduction

This wiki page describes the SOP (Standard Operating Procedure) for releasing LEAP like packaging-related processes. It also includes packaging standards, common fixes, patch resources, and debugging methods.

Package building

Fetching source

Source packages are located under 7.x folder on http://vault.centos.org/. There are several types of repository:

os

Base packages

updates

Package updates

extra

Extra packages such as docker, cockpit, golang, etc.

Source rpms can only be downloaded through yum or curl/wget, since there is no Rsync repository for Centos source rpms.

Determine problem

If a package fails to be built on Koji, there are several possibilities causing it:

• Package name is not added to the pkg list of the tag
• Package only supports the architectures on ExclusiveArch list in the spec file
• Same version of the package already existed on Koji
• Repository of the build-tag is being regenerated or broken
• Package spec contains RHEL or CentOS specific rpm macros
• Missing Dependency
• Package has to be patched in order to be built on AArch64 platform

Common errors and solutions

build.log - Code compilation error

Reason: Certain depended library is too old

Solution: Try to build all other packages and then rebuild this one

build.log - Cannot detect system type

Reason: The software uses outdated config.guess and config.sub to autodetect system type

Solution: Replace both files in the source with the latest online version. See https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html

build.log - Unknown system type

Reason: The software only allows it to be built with kernel 2.6/3.x

Solution: Add 4.x support to the system checking script

BuildError No matching arches were found

Reason: Package only supports the architectures on ExclusiveArch list in the spec file

Solution: Checkout the package on Fedora ARM Koji and CentOS AArch64 repo and determine whether the package is possible to support AArch64 or not

Resources

1. Previous build of the package
2. CentOS AArch64 repo: http://buildlogs.centos.org/centos/7
3. Fedora ARM Koji: http://arm.koji.fedoraproject.org
4. CentOS git repo (for reverting CentOS changes): http://git.centos.org
5. GOOGLE!

Source modification

There a few standards to follow during modification:

• Add comments about any line changes
• Add the word LEAP at the beginning of any comments, for example:

 # LEAP Add AArch64 support
 ExclusiveArch: x86_64 aarch64

• Add .leap after the release version, add .leap.1, .leap.2 ... and so on for further modification

• Make sure to specify all the changes under the %changelog section:

*  Fri Mar 25 2016 Foo Bar <foo.bar@example.com> - 1:1.28.1-1.55.leap
- Add AArch64 support
- Roll in LEAP Branding

Rebranding

The packages that contains the word .centos in their release version are branded packages. In order to properly rebranding those packages for LEAP, here is the checklist:

• Replace the word CentOS or CentOS Linux with LEAP in spec package descriptions and patches (make sure they are branding-related)
• Replace CentOS branding patches with LEAP branding patches
  • If certain patch file contain author names, regenerate the patch with your own name instead of modifying the patch directly
• Replace CentOS links with LEAP links accordingly
• Sometimes Red Hat trademarks and links have to be replaced as well
• Remove CentOS/RHEL certificate files and binaries

Particular branded packages

libreport/abrt

Libreport and abrt are the library and application for automatic bug detection and reporting to RHEL bug tracker servers. Since CentOS added several significant patches to both packages for supporting their own bug tracker, removing those patches can be very complicated process. The best way to solve this problem is retrieving the original RHEL versions from http://git.centos.org, add our old debranding patches, and bump the version-release number + .leap to match the requirements of dependency.

More coming ...