Difference between revisions of "LEAP SOP"
Line 60: | Line 60: | ||
ExclusiveArch: x86_64 aarch64 | ExclusiveArch: x86_64 aarch64 | ||
</source> | </source> | ||
− | * When commenting out a existing line of code, add one more % before any rpm macro otherwise rpmbuild will complain. For instance: | + | * When commenting out a existing line of code, add one more '''%''' before any rpm macro otherwise rpmbuild will complain. For instance: |
<source lang=bash> | <source lang=bash> | ||
# Before commenting out | # Before commenting out | ||
Line 69: | Line 69: | ||
</source> | </source> | ||
− | * Add '''.leap''' after the release version, add '''.leap.1'', '''.leap.2''' ... and so on for further modifications | + | * Add '''.leap''' after the release version, add '''.leap.1''', '''.leap.2''' ... and so on for further modifications |
* Make sure to specify all the changes under the <tt>%changelog</tt> section: | * Make sure to specify all the changes under the <tt>%changelog</tt> section: | ||
Line 91: | Line 91: | ||
==== Particular branded packages ==== | ==== Particular branded packages ==== | ||
− | ; libreport/abrt | + | ; 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 own de-branding patches, and bump the version-release number + ''.leap'' to match the requirements of dependency. | : '''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 own de-branding patches, and bump the version-release number + ''.leap'' to match the requirements of dependency. | ||
− | ; ntp/chrony/ | + | ; ntp / chrony / PackageKit / system-config-date |
− | : These packages contain network time protocol configurations pointing to the NTP pool address: pool.VENDERZONE.ntp.org . By default, they are pointing to pool.centos.ntp.org. Since ntp pool for LEAP hasn't been set up, it is necessary to remove any .VENDERZONE in the spec files | + | : These packages contain network time protocol configurations pointing to the NTP pool address: ''pool.VENDERZONE.ntp.org'' . By default, they are pointing to ''pool.centos.ntp.org''. Since ntp pool for LEAP hasn't been set up, it is necessary to remove any ''.VENDERZONE'' (system-config-date one has a different name) in the spec files instead of just replacing the brand. |
− | ; grub2/shim/shim-signed/system-config-kdump | + | ; grub2 / shim / shim-signed / system-config-kdump |
− | : There is a important variable <tt>efidir</tt> in the patches and specs in these packages. It represents the name of the EFI directory containing all the EFI boot files. Make sure the value of <tt>efidir</tt> '''leap'''. | + | : There is a important variable <tt>efidir</tt> in the patches and specs in these packages. It represents the name of the EFI directory containing all the EFI boot files. Make sure the value of <tt>efidir</tt> changed to '''leap'''. |
− | ; oscap-anaconda-addon/oscap-security-guide | + | ; oscap-anaconda-addon / oscap-security-guide |
: TODO | : TODO | ||
== Build order == | == Build order == | ||
It is safer and more time-efficient to build certain essential packages before any other packages are built, because other packages are very likely to depend on them: | It is safer and more time-efficient to build certain essential packages before any other packages are built, because other packages are very likely to depend on them: | ||
− | * leap-release - the base of | + | * '''leap-release''' - the base of entire distribution |
− | * gcc, glibc, make - basic | + | * '''gcc''', '''glibc''', '''make''', '''binutils''' - basic toolchain |
− | * coreutils - basic tools | + | * '''coreutils''' - basic system tools |
− | * xorg-x11-server - xorg-x11-drv* always require the specific version of xorg-x11-server they are built with | + | * '''xorg-x11-server''' - xorg-x11-drv* always require the specific version of xorg-x11-server they are built with |
− | == Duplicated source | + | == Duplicated source filename == |
− | It is possible that a few packages contain patches or sources having identical names. When installing source rpms to rpmbuild tree (<tt>$HOME/rpmbuild/*</tt>), try to avoid installing too many of them at a time (50+). Wipe the rpmbuild tree after | + | It is possible that a few packages contain patches or sources having identical names. When installing source rpms to rpmbuild tree (<tt>$HOME/rpmbuild/*</tt>), try to avoid installing too many of them at a time (50+). Wipe the rpmbuild tree after finishing modification and build of those packages on Koji. There are a few problematic packages have been discovered: |
− | * | + | * OpenJDK 6 / 7 / 8 packages |
* xorg-x11-drv-dummy and xorg-x11-drv-fbdev | * xorg-x11-drv-dummy and xorg-x11-drv-fbdev | ||
Revision as of 21:01, 27 March 2016
Contents
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 directory 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
- Code compilation error
- Reason: Certain pulled library is too old
- Solution: Try to build all other packages and then rebuild this one
- 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
- 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
- Fail to patch
- Reason: Wrong patches or sources were packed into the source rpm
- Solution: Retrieve the original CentOS src.rpm and repack it again, see also: #Duplicated source file names
Resources
- Previous build of the package
- CentOS AArch64 repo: http://buildlogs.centos.org/centos/7
- Fedora ARM Koji: http://arm.koji.fedoraproject.org
- CentOS git repo (for reverting CentOS changes): http://git.centos.org
- 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
- When commenting out a existing line of code, add one more % before any rpm macro otherwise rpmbuild will complain. For instance:
# Before commenting out
cp %{SOURCE1} $RPM_BUILD_ROOT%{_datadir}/virt-tools
# After
# cp %%{SOURCE1} $RPM_BUILD_ROOT%%{_datadir}/virt-tools
- Add .leap after the release version, add .leap.1, .leap.2 ... and so on for further modifications
- 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 contain 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 contains author name, 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 own de-branding patches, and bump the version-release number + .leap to match the requirements of dependency.
- ntp / chrony / PackageKit / system-config-date
- These packages contain network time protocol configurations pointing to the NTP pool address: pool.VENDERZONE.ntp.org . By default, they are pointing to pool.centos.ntp.org. Since ntp pool for LEAP hasn't been set up, it is necessary to remove any .VENDERZONE (system-config-date one has a different name) in the spec files instead of just replacing the brand.
- grub2 / shim / shim-signed / system-config-kdump
- There is a important variable efidir in the patches and specs in these packages. It represents the name of the EFI directory containing all the EFI boot files. Make sure the value of efidir changed to leap.
- oscap-anaconda-addon / oscap-security-guide
- TODO
Build order
It is safer and more time-efficient to build certain essential packages before any other packages are built, because other packages are very likely to depend on them:
- leap-release - the base of entire distribution
- gcc, glibc, make, binutils - basic toolchain
- coreutils - basic system tools
- xorg-x11-server - xorg-x11-drv* always require the specific version of xorg-x11-server they are built with
Duplicated source filename
It is possible that a few packages contain patches or sources having identical names. When installing source rpms to rpmbuild tree ($HOME/rpmbuild/*), try to avoid installing too many of them at a time (50+). Wipe the rpmbuild tree after finishing modification and build of those packages on Koji. There are a few problematic packages have been discovered:
- OpenJDK 6 / 7 / 8 packages
- xorg-x11-drv-dummy and xorg-x11-drv-fbdev
More coming ...