sig_core/wiki
8
0
Fork 0
Code Issues Pull Requests Actions Projects Releases Activity

Compare commits

base: sig_core:main
Branches Tags
sig_core:main
sig_core:gh-pages
sig_core:update-theme
..
compare: sig_core:update-theme
Branches Tags
sig_core:gh-pages
sig_core:main
sig_core:update-theme

2 Commits
main ... update-the

Author SHA1 Message Date
Neil Hanlon
7716c008e9
fix: only apply gradient when the sidebar is out 2024-02-19 16:54:03 -05:00
Neil Hanlon
b20d3acae8
merge template theme changes 2024-02-14 20:47:19 -05:00
38 changed files with 240 additions and 2654 deletions
Show Stats Expand all files Collapse all files

7
.github/workflows/build.yml vendored
View File

@ -1,3 +1,4 @@
---
name: mkdocs build
on:
push:
@ -10,7 +11,7 @@ jobs:
image: docker.io/rockylinux:9
steps:
- name: Install deps
run: dnf -y install git python3 python3-pip
run: dnf -y upgrade && dnf -y install git python3 python3-pip cairo-devel
- name: setup ssh
env:
@ -29,9 +30,9 @@ jobs:
- name: Install python requirements
run: python3 -m pip install -r requirements.txt
- name: Deploy
env:
env:
GIT_SSH_COMMAND: "ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no"
GIT_AUTHOR_NAME: "Rocky Bot"
GIT_AUTHOR_EMAIL: "auto@rockylinux.org"

1
.gitignore vendored
View File

@ -1 +1,2 @@
site/
.cache

8
Containerfile Normal file
View File

@ -0,0 +1,8 @@
FROM quay.io/rockylinux/rockylinux:9
RUN dnf -y upgrade
RUN dnf install -y git python3 python3-pip cairo-devel
COPY . /wiki
WORKDIR /wiki
RUN pip install -r requirements.txt

9
LICENSE Normal file
View File

@ -0,0 +1,9 @@
MIT License
Copyright (c) <year> <copyright holders>
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

28
README.md
View File

@ -1,14 +1,36 @@
# Release Engineering (SIG/Core) Wiki
# SIG/Core Wiki
[![mkdocs build](https://github.com/rocky-linux/sig-core-wiki/actions/workflows/gh.yml/badge.svg)](https://github.com/rocky-linux/sig-core-wiki/actions/workflows/gh.yml)
This is the wiki repository for SIG/Core.
https://sig-core.rocky.page
## Building
## Continuous Integration / Continuous Deployment
To test the appearance of this wiki, give it a try:
Actions Runner executes workflow to publish to https://REPLACEME.rocky.page on push to main.
## Building Locally
In order to build this wiki locally, a docker-compose configuration and container file are supplied which when invoked, will launch mkdocs' development server in a container bound to port 8000 and will live-reload when changes are made to the wiki files.
To run the containers on your system, invoke podman or docker compose like so:
```
podman-compose -f docker-compose.yml up -d
```
The container will build and then launch itself. Afterwards, you should be able to view the wiki content at http://localhost:8000.
The compose file accepts a build argument if you need to run it on a different port. For example, to bind to port 8080 on your local machine:
```
podman-compose -f docker-compose --build-arg PORT=8080 up -d
```
## Project layout
mkdocs.yml # The configuration file.
README.md # This file.
docs/
index.md # The documentation homepage.
... # Other markdown pages, images and other files.

13
docker-compose.yml Normal file
View File

@ -0,0 +1,13 @@
---
version: '3'
services:
wiki:
build:
context: .
dockerfile: Containerfile
command: ["mkdocs", "serve", "-w", "/wiki", "--dev-addr", "0.0.0.0:${PORT:-8000}"]
volumes:
- .:/wiki:z,rw
ports:
- "${PORT:-8000}:8000"

1
docs/.pages
View File

@ -5,5 +5,4 @@ nav:
- ... | what_we_do.md
- Documentation: documentation
- SOP: sop
- Events: events
...

33
docs/assets/extra.css Normal file
View File

@ -0,0 +1,33 @@
:root {
@media screen and (max-width: 76.234375em) {
.md-nav__title[for="__drawer"] {
background: linear-gradient(135deg, #10b981 0%, #1055b9 100%);
}
}
}
[data-md-color-scheme="resf"] {
--md-accent-fg-color: #0e7391;
--md-primary-fg-color--dark: #107fa1;
--md-primary-fg-color--light: #FFFFFF;
--md-primary-fg-color: #107fa1;
--md-typeset-a-color: #107fa1;
}
[data-md-color-scheme="resf-dark"] {
color-scheme: dark;
--md-default-fg-color: #FFFFFF;
--md-default-bg-color: rgb(30, 33, 41);
--md-primary-fg-color: #107fa1;
--md-primary-bg-color: #FFFFFF;
--md-primary-fg-color--dark: #107fa1;
--md-accent-fg-color: #0e7391;
--md-default-fg-color--light: rgba(226, 228, 233, 0.56);
--md-typeset-table-color: rgba(240, 241, 244, 0.12);
--md-typeset-color: rgba(226, 228, 233, 0.82);
--md-typeset-a-color: #107fa1;
}

BIN
docs/assets/resf-icon-w-bg.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 381 KiB

BIN
docs/assets/resf-icon.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.3 MiB

63
docs/assets/resf-white.svg Normal file
View File

@ -0,0 +1,63 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
width="44.450001mm"
height="44.450001mm"
viewBox="0 0 44.450001 44.450001"
version="1.1"
id="svg1"
inkscape:version="1.3.2 (091e20ef0f, 2023-11-25)"
sodipodi:docname="resf-white.svg"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns="http://www.w3.org/2000/svg"
xmlns:svg="http://www.w3.org/2000/svg">
<sodipodi:namedview
id="namedview1"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:showpageshadow="2"
inkscape:pageopacity="0.0"
inkscape:pagecheckerboard="0"
inkscape:deskcolor="#d1d1d1"
inkscape:document-units="mm"
inkscape:zoom="1.624662"
inkscape:cx="105.86818"
inkscape:cy="665.36917"
inkscape:window-width="1440"
inkscape:window-height="3356"
inkscape:window-x="0"
inkscape:window-y="52"
inkscape:window-maximized="1"
inkscape:current-layer="layer1" />
<defs
id="defs1" />
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1"
transform="translate(-2.5796834,-3.8748417)">
<path
d="M 2.5796834,3.8748417 H 47.029686 V 31.39389 l -6.87626,-6.876256 -5.13556,5.135562 -10.27113,-10.271125 -5.13556,5.135298 -10.2710976,-10.271045 -6.760395,6.760289 z"
fill="#ffffff"
id="path3"
style="stroke-width:0.264583" />
<path
d="m 40.153426,32.220977 -16.10386,16.103865 h 22.98012 v -9.227609 z"
fill="#ffffff"
id="path4"
style="stroke-width:0.264583" />
<path
d="M 24.746736,27.085415 31.166056,33.505 16.346271,48.324842 H 3.5072594 Z"
fill="#ffffff"
id="path5"
style="stroke-width:0.264583" />
<path
d="m 9.3400784,21.949588 -6.760395,6.760633 V 41.549127 L 15.759558,28.369173 Z"
fill="#ffffff"
id="path6"
style="stroke-width:0.264583" />
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 2.0 KiB

2
docs/documentation/.pages
View File

@ -1,8 +1,6 @@
---
nav:
- ... | index.md
- Guidelines: guidelines
- Package Patching: patching
- Composing Releases: compose
- Empanadas: empanadas.md
- Peridot: peridot.md

6
docs/documentation/empanadas.md
View File

@ -89,13 +89,13 @@ Note that for each of these commands, it is fully expected you are running
```
# Syncs all repositoryes for the "9" release
% poetry run sync-from-peridot --release 9 --clean-old-packages
% poetry run sync_from_peridot --release 9 --clean-old-packages
# Syncs only the BaseOS repository without syncing sources
% poetry run sync-from-peridot --release 9 --clean-old-packages --repo BaseOS --ignore-source
% poetry run sync_from_peridot --release 9 --clean-old-packages --repo BaseOS --ignore-source
# Syncs only AppStream for ppc64le
% poetry run sync-from-peridot --release 9 --clean-old-packages --repo AppStream --arch ppc64le
% poetry run sync_from_peridot --release 9 --clean-old-packages --repo AppStream --arch ppc64le
```
{% include "resources_bottom.md" %}

4
docs/documentation/guidelines/.pages
View File

@ -1,4 +0,0 @@
---
nav:
- ... | index.md
- ... | rocky_logos_guidelines.md

9
docs/documentation/guidelines/index.md
View File

@ -1,9 +0,0 @@
---
title: Guidelines
---
This section is primarily for documentation and useful information as it
pertains to guidelines for various packages or asset usage.
**Release Engineering has the final "go/no-go" decision on submissions, assets,
images, and the general structure of the release of Rocky Linux.**

239
docs/documentation/guidelines/rocky_logos_guidelines.md
View File

@ -1,239 +0,0 @@
---
title: Rocky Logos Package Guidelines
---
This page goes over the basic guidelines for the rocky-logos package, which produces assets for anaconda, wallpapers, and other assets for the distribution.
**Release Engineering has the final "go/no-go" decision on submissios/assets/images in the package.**
## Rocky Logo Assets
In various parts of the package, the Rocky logo will need to exist in multiple forms:
* Green variant
* White variant
This can be in the form of `PNG`, `JPG`, or `SVG` files.
### anaconda
All anaconda image assets will be in `PNG` form. Backgrounds should be transparent with the exception of `rnotes` if applicable.
### Backgrounds
See [Backgrounds Section](#Backgrounds/Wallpapers)
### fedora
`SVG` format of logo assets as `fedora_logo` (color) and `fedora_logo_darkbackground` (white), and a default as `fedora_logo`.
### firstboot
First boot assets. This is generally the sidebar (like the anaconda installer) and a workstation icon. `PNG` format.
### icons/hicolor
Rocky icons will appear here in different resolutions and must be in `PNG` or `SVG` format:
* 16x16/apps: `PNG`, `system-logo-icon`, `fedora-logo-icon`
* 22x22/apps: `PNG`, `system-logo-icon`, `fedora-logo-icon`
* 24x24/apps: `PNG`, `system-logo-icon`, `fedora-logo-icon`
* 32x32/apps: `PNG`, `system-logo-icon`, `fedora-logo-icon`
* 36x36/apps: `PNG`, `system-logo-icon`, `fedora-logo-icon`
* 48x48/apps: `PNG`, `system-logo-icon`, `fedora-logo-icon`
* 96x96/apps: `PNG`, `system-logo-icon`, `fedora-logo-icon`
* 256x256/apps: `PNG`, `system-logo-icon`, `fedora-logo-icon`
* scalable/apps: `SVG`, `fedora-logo-icon`, `org.fedoraproject.AnacondaInstaller.svg`, `start-here.svg`, `xfce4_xicon1.svg`
* symbolic/apps: `SVG`, `org.fedoraproject.AnacondaInstaller-symbolic`
### ipa
IPA specific assets, usually text. They are generally `PNG` or `JPG`:
* `header-logo.png` - Text
* `login-screen-background.jpg` - No text
* `login-screen-logo.png` - Logo + Text
* `product-name.png` - Text
### pixmaps
`PNG` format, these are usually assets used within GNOME, GDM, and other desktop environments.
### plymouth/charge
Typically unchanged and is for the plymouth loading screen
### svg
`SVG` format of logo assets as `fedora_logo` (color) and `fedora_logo_darkbackground` (white)
`color` file dictates background color if applicable
### testpage
`index.html` for httpd/nginx/etc
## Backgrounds/Wallpapers
### Structure
Wallpapers appear in `PNG` format with a backing `XML` file to list out all available resolutions if applicable, as well as defaults.
A defaults file looks at every other `XML` that is a default background provided by the backgrounds package and default options if applicable.
```
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE wallpapers SYSTEM "gnome-wp-list.dtd">
<wallpapers>
<wallpaper deleted="false">
<name>Rocky Linux 9 Default Background - Placeholder Mesh</name>
<filename>/usr/share/backgrounds/rocky-default-1-mesh.xml</filename>
<options>zoom</options>
<author>Louis Abel</author>
<email>label@rockylinux.org</email>
<license>CC-BY-SA 4.0</license>
</wallpaper>
<wallpaper deleted="false">
<name>Rocky Linux 9 Default Background - Placeholder Target</name>
<filename>/usr/share/backgrounds/rocky-default-1-target.xml</filename>
<options>zoom</options>
<author>Louis Abel</author>
<email>label@rockylinux.org</email>
<license>CC-BY-SA 4.0</license>
</wallpaper>
</wallpapers>
```
The wallpaper itself will list every applicable variant of that background if applicable.
```
<background>
<starttime>
<year>2021</year>
<month>10</month>
<day>29</day>
<hour>19</hour>
<minute>21</minute>
<second>19</second>
</starttime>
<static>
<duration>10000000000.0</duration>
<file>
<!-- Wide 16:9 -->
<size width="1920" height="1080">/usr/share/backgrounds/rocky-default-1-mesh-16-9.png</size>
<!-- Wide 16:10 -->
<size width="1920" height="1200">/usr/share/backgrounds/rocky-default-1-mesh-16-10.png</size>
<!-- Standard 4:3 -->
<size width="2048" height="1536">/usr/share/backgrounds/rocky-default-1-mesh-4-3.png</size>
<!-- Normalish 5:4 -->
<size width="1280" height="1024">/usr/share/backgrounds/rocky-default-1-mesh-5-4.png</size>
</file>
</static>
</background>
```
Day/Night Wallpapers have a similar configuration.
```
<background>
<starttime>
<year>2022</year>
<month>01</month>
<day>01</day>
<hour>8</hour>
<minute>00</minute>
<second>00</second>
</starttime>
<!-- This animation will start at 8 AM. -->
<!-- We start with day at 8 AM. It will remain up for 10 hours. -->
<static>
<duration>36000.0</duration>
<file>/usr/share/backgrounds/rocky-default-1-mesh-day.png</file>
</static>
<!-- Day ended and starts to transition to night at 6 PM. The transition lasts for 2 hours, ending at 8 PM. -->
<transition type="overlay">
<duration>7200.0</duration>
<from>/usr/share/backgrounds/rocky-default-1-mesh-day.png</from>
<to>/usr/share/backgrounds/rocky-default-1-mesh-night.png</to>
</transition>
<!-- It's 8 PM, we're showing the night till 6 AM. -->
<static>
<duration>36000.0</duration>
<file>/usr/share/backgrounds/rocky-default-1-mesh-night.png</file>
</static>
<!-- It's 6 AM, and we're starting to transition to day. Transition completes at 8 AM. -->
<transition type="overlay">
<duration>7200.0</duration>
<from>/usr/share/backgrounds/rocky-default-1-mesh-night.png</from>
<to>/usr/share/backgrounds/rocky-default-1-mesh-day.png</to>
</transition>
</background>
```
### Guidelines
This section goes over the general guidelines for the main backgrounds included in the distribution, including content and resolutions.
#### General Theme
Each Rocky release has a codename, and thus is the general theme. Examples.
* Rocky 8: `Green Obsidian` - Submissions only to extras
* Rocky 9: `Blue Onyx` - This should be generally a blue theme/color scheme. Submissions only to extras.
* Rocky 10: `Red Quartz` - This should be generally a red-like theme/color scheme
#### Required Resolutions for Normal Submissions
We request a high resolution to make things simpler for users to choose which they'd like and how they want it to display on their system (e.g. "wide", "center", others).
* Resolution must **not** fall below: 3072x3072
* Example resolutions: 4800x3600, 4096x3072, 3440x3440
#### Content Guidelines
* **Allowed**:
* Anything related to nature, mountains, rocks, and the like (generally fitting into the "rocky" idea)
* Anything related to the release codename (eg. Blue Onyx)
* Anything minimalist/abstract is allowed
* References to the release number (like 9, and so on) are allowed
* Complementary colors should be allowed in the image within reason
* Contrasting colors should be allowed in the image within reason
* Photography + Manipulation should be allowed within reason - Random photos from image searches will not be accepted
* **Highly Encouraged**: [Day](https://github.com/fedoradesign/backgrounds/blob/main/default/f40-01-day.png) and [Night](https://github.com/fedoradesign/backgrounds/blob/main/default/f40-01-night.png) versions of wallpapers
* **Discouraged**:
* Avoid using the Rocky logo, unless it fits with an abstract/minimalist idea for the background
* Plain backdrops with the rocky logo are *not* permitted
* **Prohibited**:
* Any AI generated artwork
### Extras Package
If a wallpaper does not make it to the main package, is simply Rocky inspired, or was simply submitted as an "extra" background, it has the opportunity to be placed into the rocky-backgrounds-extras package. The requirements are more relaxed for the extra backgrounds.
#### Minimum Resolutions for Extra Backgrounds
For general submissions, we request a high resolution to make things simpler, that way the user is able to choose a wallpaper without having to choose "the right one" for their monitor size. This requirement is more relaxed for the extra backgrounds package. If a submitter wishes not to use the highest resolution but opts to make multiple resolutions instead, they should use the below list as a general guideline:
* **Minimum Required Resolutions**:
* 16:9 (1920x1080)
* 16:10 (1920x1200)
* 5:4 (2048x1536)
* 4:3 (1280x1024)
* **Additional (encouraged) allowed resolutions**:
* 3440x1440
* 2560x1600
* 2560x1440
* 2560x1080
* 1800x1440
* Portrait mode versions of the above are optional
The placeholders in [this commit](https://github.com/rocky-linux/rocky-logos/tree/962a836f70a131faa541a4f8f73a4a3fddfc3dbf/backgrounds) shows an example of using the minimum resolutions.

5
docs/documentation/patching/.pages
View File

@ -1,5 +0,0 @@
---
nav:
- ... | index.md
- Package Changes: changes.md
- Patching Guide: patching.md

15
docs/documentation/patching/changes.md
View File

@ -1,15 +0,0 @@
---
title: Rocky Linux Package Changes
---
In Rocky Linux, some packages can be patched or even self-managed. Below is a table of each package that we may modify to address branding or self-management. Click the appropriate Rocky Linux version that is of interest to you.
{% include "mod_table.md" %}
### Terminology
| Term | Definition |
|--------------|------------------------------------------------------------------------------------|
| Self-managed | A package that Release Engineering manages rather than using srpmproc to patch |
| Patch | A patch done either in the source code or the spec file |
| Branding | A branding patch done to ensure Rocky Linux assets are in use rather than upstream |

66
docs/documentation/patching/debrand_info.md
View File

@ -1,66 +0,0 @@
---
title: Debranding Information
---
This page goes over the methodology and some packages that require changes to their material for acceptance in Rocky Linux. Usually this means there is some text or images in the package that reference upstream trademarks, and these must be swapped out before we can distribute them.
CentOS had a wiki page at one point where it was documented, but it wasn't always up to date. For example, the package **nginx** did not appear on their list, and still had RHEL branding in the CentOS repos. As a result, this forced us to do a deeper investigation into what needs to be changed or altered.
There are a few ways we've determined some of the changes:
* Packages don't build because ID is not `centos`, `rhel`, or `fedora`
* Packages have `?centos` tags in the SPEC file to differentiate from Fedora or RHEL
* Some packages in git.centos.org have an automatic debranding message - This won't be as helpful for 9 and beyond
* RHEL assets were appearing in the installed package(s)
When we need to make changes, it can possibly be one or more of these things:
* URL's should change from Red Hat to a Rocky page (if applicable)
* URL's that are being patched to be Red Hat should be removed (systemd in 8 is an example of this)
* `?centos` is changed to `?rocky`, but this isn't always consistent or sufficient
* Assets need to be changed
* Exceptions come when there is a file being requested from the logos package - We generally have symlinks to deal with this
* Some patches must be made to the source code or spec file
* Packages are built against an "override" release package that uses `ID="rhel"` in `/etc/os-release` to force a build to pose as RHEL (older versions of dotnet and chrony are an example of this)
Current patches (for staging) are [here](https://git.rockylinux.org/staging/patch).
## Packages that need debranding changes:
There is a metadata file that helps track this information for us. It can be located [here](https://git.rockylinux.org/rocky/metadata/-/blob/main/patch.yml) and is separated by section and branch.
In essence, the file goes over these sections:
* `build_patch` -> Packages that may have needed patches to build properly in our environment
* `dnt` or **D**o **N**ot **T**ouch -> These should not be modified or changed
* `custom` -> Custom packages not provided by upstream but can be useful in obsoleting packages or providing some functionality
* `plus` -> Packages that are modified versions of what's in the base or built by normal means but not shipped by Red Hat
* `previous` -> Packages that may have been patched before for debranding or building - They are left as a reference
* `provides` -> Common provides for release, logos, and other rocky/system specific packages
* `override_required` -> Requires an "override" release package to build properly
* `spec_change_only` -> Requires only spec changes to remove functionality that is RHEL specific
* `debrand` -> Packages that are changed/patched to either remove Red Hat references, replace them, or add Rocky Linux as a supported distribution
* Some of these packages will always need to be changed, on a minor or major release schedule.
* Some are potentially upstreamed so then they are no longer patched by us (sos is an example)
* Some packages may still need modification, even if upstreamed (anaconda is an example)
## Packages that need to become other packages:
There is a metadata file that tracks this for us. It can be located [here](https://git.rockylinux.org/rocky/metadata/-/blob/main/patch.yml). The section in particular is called `provides`.
This is for example, `redhat-logos` or `system-logos` is provided or "becomes" `rocky-logos`.
## Packages that Exist in RHEL, but do not exist in most derivatives
For sake of complete information, here is a list of packages that are in RHEL, but may not exist in derivatives. We do not need to worry about these packages:
- insights-client
- Red_Hat_Enterprise_Linux-Release_Notes-8-*
- redhat-access-gui
- redhat-bookmarks
- rhc
- rhc-worker-playbook
- subscription-manager-migration
- subscription-manager-migration-data

44
docs/documentation/patching/index.md
View File

@ -1,44 +0,0 @@
---
title: Rocky Linux Package Patching
---
In Rocky Linux, some packages are patched either for build issues or removing Red Hat references. Some packages are completely self-managed by Release Engineering. Some packages have Red Hat or CentOS assets that cannot be shipped (for obvious reasons). Performing these types of changes are necessary for Rocky Linux to exist.
## What is Debranding?
Debranding is for the case of removing Red Hat or CentOS assets from a package and either A) Using Rocky Linux or RESF assets or B) Forcing the use of generic assets. The former is the most common and the latter happens once in a blue moon. A debrand can come in the following forms:
* Changing "Red Hat" to "Rocky"
* Changing "RHEL" or "Red Hat Enterprise Linux" to "Rocky Linux"
* Changing some "Red Hat" or "RHEL" wording to be agnostic, such as "Enterprise Linux"
* Changing bug tracker URL's to our project's specific bug tracker site
* Replacing appropriate assets (e.g. the logos packages)
The most obvious example would be httpd or nginx. While these rely on `rocky-logos-httpd` for specific pages, some assets are also replaced. This is particularly obvious with the test pages with distribution specific information.
## How are packages "debranded"?
Debrands are done using the `srpmproc` utility. The utility source code is [here](https://github.com/rocky-linux/srpmproc).
## What are "self-managed" packages?
Rocky Linux may have packages that are self-managed. Self-managed packages are packages that Red Hat may ship themselves, but it's simply easier for Release Engineering to manage them, thus reducing srpmproc headaches.
## What are "build issues"?
Some packages have to be patched, either a source code patch or a spec file change, to address a build issue. A build issue can come in multiple forms:
* Failing tests that should not fail in normal circumstances
* OOM issues for heavy packages
* Build issues where a package cannot be built properly in a container
These do not happen often. These types of changes do not affect the compatibility of the packages to our upstream.
## What type of other changes can be done?
There are very rare cases where Red Hat completely disables a package from being built or even being provided. In these very rare cases, if there is user demand, we may ensure these packages are built or provided in some way. A very common example is `openldap-servers`, which is no longer built by default. There are a couple of packages that for some reason also *rely* on openldap-server's existence. As a result, we enable this and provide it in our `plus` repository.
## Can I get a list of changes?
Of course, head to the [changes](changes.md) page for a list of known and documented changes that we make to our packages.

213
docs/documentation/patching/patching.md
View File

@ -1,213 +0,0 @@
---
title: Rocky Linux Patching Guide
---
!!! note
This page is kept here as a historical reference and may be out of date.
This explains how to debrand/patch a package for the Rocky Linux distribution.
## General Instructions
- First, identify the files in the package that need to be changed. They could be text files, image files, or others. You can identify the file(s) by digging into git.centos.org/rpms/PACKAGE/
- Develop replacements for these files, but with Rocky branding placed instead. Diff/patch files may be needed as well for certain types of text, depends on the content being replaced.
- Replacement files go under https://git.rockylinux.org/patch/PACKAGE/ROCKY/_supporting/
- Config file (specifying how to apply the patches) goes in https://git.rockylinux.org/patch/PACKAGE/ROCKY/CFG/*.cfg
- Note: Use spaces, not tabs.
- When srpmproc goes to import the package to Rocky, it will see the work done in https://git.rockylinux.org/patch/PACKAGE , and apply the stored patches by reading the config file(s) under ROCKY/CFG/*.cfg
## The Patch Config Language
Patching uses simple proto3 config files. The general format is:
```
Action {
file: "OriginalFile"
with_file: "ROCKY/_supporting/RockyReplaceFile"
}
```
A simple example to replace a file:
```
replace {
file: "redhatlogo.png"
with_file: "ROCKY/_supporting/rockylogo.png"
}
```
The file "redhatlogo.png" would be located in under SOURCES/ in the project's Git repository (and SRPM).
## Patch configuration options
* `add`: Adds a file to the sources using the `file` or `lookaside` directive
* `delete`: Deletes a file from the sources using the `file` directive
* `replace`: Replaces a file from the sources using the `file` and `with_file` directives
* `patch`: Performs a patch based on the diff provided in the `file` directive (generated using `git diff`)
* `spec_change`: Allows for spec files to be modified
* `search_and_replace`: Performs a search and replace on a given text for the spec file using the `any/starts_with/ends_with` (true|false), `find` (string to find), `replace` (replacement string), and `n` (integar, `-1` for any) directives.
* `file`: A file can be added to the spec file using the `name` directive to define the file name, the `type` directive (such as `patch`) and then an `add` option that is `true` or `false`
* When `patch` is used, the following options are available:
* `add_to_prep` (true|false)
* `n_path: N` can be specified to add `%patchX -pN` lines into `%prep` assuming the rpm does not use `%autosetup`
* `append`: Appends to a given `field`, such as `Release` with a `value` directive
* `changelog`: Modifies the change log using `author_name`, `author_email`, and `message` directives
Patch configuration structure:
```
.
└── ROCKY
├── CFG
└── _supporting
```
## Case Study: Nginx
**(note: all example data here is currently in the staging/ area of Rocky Linux Git. We will update it when the projects are moved to the production area)**
Let's go over an example debrand, featuring the Nginx web server package.
The source repository is located here: **https://git.centos.org/rpms/nginx**
If we browse one of the c8-* branches, we see under SOURCES/ that there is definitely some content that needs to be debranded:
```
404.html
50x.html
index.html
poweredby.png (binary file in dist-git, referred to in .nginx.metadata)
```
These files all refer to Red Hat inc., and must be replaced before they make it to Rocky Linux.
**1: Come up with the patches:** Each of these files has a Rocky Linux counterpart, and they must be created. **Some of this should be done by the Design Team, especially logo work (#Design on chat)**
**2: Commit patches to the matching patch/PROJECT Git repository** : For example, Nginx patches are located here: **https://git.rockylinux.org/staging/patch/nginx** (staging/ prefix is currently used until our production repos are set up)
**3: Develop a matching config file:** Our example Nginx has this here: **https://git.rockylinux.org/staging/patch/nginx/-/blob/main/ROCKY/CFG/pages.cfg**
It looks like this:
```
replace {
file: "index.html"
with_file: "ROCKY/_supporting/index.html"
}
replace {
file: "404.html"
with_file: "ROCKY/_supporting/404.html"
}
replace {
file: "50x.html"
with_file: "ROCKY/_supporting/50x.html"
}
replace {
file: "poweredby.png"
with_file: "ROCKY/_supporting/poweredby.png"
}
```
**4: Test the import:** Now, when the upstream is imported, we can check the main Rocky **nginx** repository and ensure our updates were successful: **https://git.rockylinux.org/staging/rpms/nginx/** (again, staging/ group is used only for now)
**5: You're Done!** Great! Now do the next one... ;-)
## More Debrand Config Language
The Nginx example showed just the **replace** directive, but there are several more available. They are **add**, **patch**, and **delete.**
Here they are, with examples:
```
# Add a file to the project (file is added to SOURCES/ folder )
add {
file: "ROCKY/_supporting/add_me.txt"
}
# Apply a .patch file (generated using the Linux "patch" utility)
patch {
file: "ROCKY/_supporting/002-test-html.patch"
}
# Delete a file from the source project
delete {
file: "SOURCES/dontneed.txt"
}
```
And the .patch file example looks like this:
```
diff --git a/SOURCES/test.html b/SOURCES/test.html
index 8d91ffd..3f76c3b 100644
--- a/SOURCES/test.html
+++ b/SOURCES/test.html
@@ -1,6 +1,6 @@
<!DOCTYPE html>
<html>
<body>
- <h1>Replace me</h1>
+ <h1>Replace I did!</h1>
</body>
</html>
```
It also supports spec file changes, as it may be necessary. For example, from the anaconda debrand patch repo.
```
add {
file: "ROCKY/_supporting/0002-Rocky-disable-cdn-radiobutton.patch"
}
spec_change {
# Adds a Patch line with the file name as listed above
file {
name: "0002-Rocky-disable-cdn-radiobutton.patch"
type: Patch
add: true
}
# Appends to the end of a field's line, in this case the Release field gets .rocky
append {
field: "Release"
value: ".rocky"
}
# Adds to the change log properly
changelog {
author_name: "Mustafa Gezen"
author_email: "mustafa@rockylinux.org"
message: "Disable CDN and add .rocky to Release"
}
}
```
At the end, the spec file should be changed.
```
Summary: Graphical system installer
Name: anaconda
Version: 33.16.3.26
# Our .rocky appears here
Release: 2%{?dist}.rocky
-- snip --
Patch1: 0001-network-do-not-crash-on-infiniband-devices-activated.patch
# Look, our patch was added!
# Luckily this RPM uses %autosetup, so no %patch lines
Patch2: 0002-Rocky-disable-cdn-radiobutton.patch
-- snip --
# And below the added changelog
%changelog
* Thu Feb 25 2021 Mustafa Gezen <mustafa@rockylinux.org> - 33.16.3.26-2
- Disable CDN and add .rocky to Release
* Thu Oct 22 2020 Radek Vykydal <rvykydal@redhat.com> - 33.16.3.26-2
- network: do not crash on infiniband devices activated in initramfs
(rvykydal)
Resolves: rhbz#1890261
```

19
docs/documentation/references/empanadas_config.md
View File

@ -104,22 +104,6 @@ required: False
description: For future use with icicle.
### gpg_key
type: List
required: False
description: List of GPG keys for a given repository
### repo_gpg_key
type: List
required: False
description: List of GPG keys for a given repository. Use this if the signing key for the repo is different from packages.
### allowed_arches
type: list
@ -628,6 +612,9 @@ ISO images if applicable.
git_repo: 'https://git.rockylinux.org/staging/src/rocky-release.git'
git_raw_path: 'https://git.rockylinux.org/staging/src/rocky-release/-/raw/r9/'
branch: 'r9'
gpg:
stable: 'SOURCES/RPM-GPG-KEY-Rocky-9'
testing: 'SOURCES/RPM-GPG-KEY-Rocky-9-Testing'
list:
- 'SOURCES/Contributors'
- 'SOURCES/COMMUNITY-CHARTER'

33
docs/events/meeting-notes/2024-03-18.md
View File

@ -1,33 +0,0 @@
---
title: Release Engineering (SIG/Core) Meeting 2024-03-18
---
## Attendees
* Louis Abel
* Mustafa Gezen
* Sherif Nagy
* Neil Hanlon
* Pablo Greco
* Taylor Goodwill
* Skip Grube
## Old Business
* Ticket opened to track current packages not yet built for Rocky Linux 10
To fill.
## New Business
* RISCV...
To fill.
## Open Floor
To fill.
## Action Items
To fill.

151
docs/include/mod_table.md
View File

@ -1,151 +0,0 @@
=== "Rocky Linux 8"
| Package Name | Change Type | Comment |
|-----------------------|-----------------|-----------------------------------------------------|
| shim-unsigned-x64 | Self-managed | Secure Boot |
| shim-unsigned-aarch64 | Self-managed | Secure Boot |
| shim | Self-managed | Secure Boot |
| fwupd | Patch | Secure Boot |
| grub2 | Patch | Secure Boot |
| kernel | Patch, Branding | Secure Boot |
| kernel-rt | Patch, Branding | Secure Boot |
| rocky-release | Self-managed | Required for Rocky Linux to be itself |
| rocky-logos | Self-managed | Required for Rocky Linux assets |
| rocky-indexhtml | Self-managed | Required for Rocky Linux default index |
| rocky-bookmarks | Self-managed | Required for Rocky Linux default browser bookmarks |
| abrt | Patch | Add Rocky Support |
| anaconda | Patch, Branding | Turn off Red Hat specific options |
| anaconda-user-help | Patch, Branding | Ensure documenation references Rocky Linux |
| cockpit-composer | Patch, Branding | Replace RHEL with Enterprise Linux |
| cloud-init | Patch | Ensure the managed user is cloud-user like upstream |
| crash | Patch | Replace Red Hat with Rocky |
| dhcp | Patch | Change bug tracker URL |
| dnf | Patch | Change bug tracker URL |
| dotnet | Branding | Add Rocky Support |
| dotnet3.0 | Branding | Add Rocky Support |
| firefox | Patch | Replace Red Hat settings with Rocky Linux settings |
| gcc | Patch | Change bug tracker URL |
| gdb | Patch | Replace Red Hat with Rocky Linux |
| gnome-boxes | Patch | Add Rocky Support |
| gnome-settings-daemon | Patch | Remove subscription manager patch |
| initial-setup | Branding | Replace Red Hat with Rocky Linux |
| java-1.8.0-openjdk* | Patch | Ensure portables are buildable on all releases |
| java-11-openjdk* | Patch | Ensure portables are buildable on all releases |
| java-17-openjdk* | Patch | Ensure portables are buildable on all releases |
| java-21-openjdk* | Patch | Ensure portables are buildable on all releases |
| libdnf | Patch | Change bug tracker URL |
| libguestfs | Patch | Add Rocky Support |
| libreoffice | Branding | Remove Red Hat branding to generic branding |
| libreport | Patch | Ensure Rocky Bug Tracker (mantis) is supported |
| lorax-templates-rocky | Self-managed | Replacement for lorax-templates-rhel |
| nginx | Branding | Replace Red Hat with Rocky Linux |
| openscap | Patch | Ensure Rocky Linux is supported as a derivative |
| osbuild | Patch | Ensure Rocky Linux is supported |
| osbuild-composer | Patch | Ensure Rocky Linux is supported |
| oscap-anaconda-addon | Branding | Replace "Red Hat" with "Rocky" |
| PackageKit | Patch | Change support URL's to Rocky Linux wiki |
| pcs | Branding | Replace "Red Hat" logo |
| plymouth | Branding | Replace "Red Hat Enterprise Linux" |
| python2 | Patch | Add Rocky Support |
| python3 | Patch | Add Rocky Support |
| python-pip | Patch | Add Rocky Support |
| redhat-rpm-config | Patch | Add Rocky Support |
| scap-security-guide | Patch | Ensure Rocky Linux is supported as a derivative |
| subscription-manager* | Patch | Remove Red Hat references |
| systemd | Patch | Change support URL's to Rocky Linux |
| thunderbird | Patch | Replace Red Hat settings with Rocky Linux settings |
| toolbox | Patch | Ensure Rocky Linux image is the default |
| WALinuxAgent | Patch | Ensure Rocky Linux is supported |
=== "Rocky Linux 9"
| Package Name | Change Type | Comment |
|-----------------------|-----------------|---------------------------------------------------------|
| shim-unsigned-x64 | Self-managed | Secure Boot |
| shim-unsigned-aarch64 | Self-managed | Secure Boot |
| shim | Self-managed | Secure Boot |
| fwupd | Patch | Secure Boot |
| grub2 | Patch | Secure Boot |
| kernel | Patch, Branding | Secure Boot |
| kernel-rt | Patch, Branding | Secure Boot |
| rocky-release | Self-managed | Required for Rocky Linux to be itself |
| rocky-logos | Self-managed | Required for Rocky Linux assets |
| rocky-indexhtml | Self-managed | Required for Rocky Linux default index |
| rocky-bookmarks | Self-managed | Required for Rocky Linux default browser bookmarks |
| anaconda | Patch, Branding | Turn off Red Hat specific options |
| anaconda-user-help | Patch, Branding | Ensure documenation references Rocky Linux |
| cloud-init | Patch | Ensure the managed user is cloud-user like upstream |
| cockpit-composer | Branding | Replace RHEL with Enterprise Linux |
| crash | Patch | Replace Red Hat with Rocky |
| dhcp | Patch | Change bug tracker URL |
| dnf | Patch | Change bug tracker URL |
| firefox | Patch | Replace Red Hat settings with Rocky Linux settings |
| gcc | Patch | Change bug tracker URL |
| gdb | Patch | Replace Red Hat with Rocky Linux |
| gnome-settings-daemon | Patch | Remove subscription manager patch |
| initial-setup | Branding | Replace Red Hat with Rocky Linux |
| java-1.8.0-openjdk* | Patch | Ensure portables are buildable on all releases |
| java-11-openjdk* | Patch | Ensure portables are buildable on all releases |
| java-17-openjdk* | Patch | Ensure portables are buildable on all releases |
| java-21-openjdk* | Patch | Ensure portables are buildable on all releases |
| libdnf | Patch | Change bug tracker URL |
| libreoffice | Branding | Remove Red Hat branding to generic branding |
| libreport | Patch | Ensure Rocky Bug Tracker (mantis) is supported |
| lorax-templates-rocky | Self-managed | Replacement for lorax-templates-rhel |
| nginx | Branding | Replace Red Hat with Rocky Linux |
| openldap | Patch | Ensure openldap-servers is available in plus repo |
| openscap | Patch | Ensure Rocky Linux is supported as a derivative |
| osbuild | Patch | Ensure Rocky Linux is supported |
| osbuild-composer | Patch | Ensure Rocky Linux is supported |
| PackageKit | Patch | Change support URL's to Rocky Linux wiki |
| python-pip | Patch | Add Rocky Support |
| redhat-rpm-config | Patch | Add Rocky Support |
| rust | Patch | Ensure that aarch64 and s390x can build rust (OOM) |
| scap-security-guide | Patch | Ensure Rocky Linux is supported as a derivative |
| subscription-manager* | Patch | Remove Red Hat references |
| systemd | Patch | Change support URL's to Rocky Linux |
| thunderbird | Patch | Replace Red Hat settings with Rocky Linux settings |
| toolbox | Patch | Ensure Rocky Linux image is the default |
| WALinuxAgent | Patch | Ensure Rocky Linux is supported |
=== "Rocky Linux 10"
| Package Name | Change Type | Comment |
|-----------------------|-----------------|-------------------------------------------------------------|
| shim-unsigned-x64 | Self-managed | Secure Boot |
| shim-unsigned-aarch64 | Self-managed | Secure Boot |
| shim | Self-managed | Secure Boot |
| fwupd-efi | Patch | Secure Boot |
| grub2 | Patch | Secure Boot |
| kernel | Patch, Branding | Secure Boot and Branding |
| kernel-rt | Patch, Branding | Secure Boot and Branding |
| rocky-release | Self-managed | Required for Rocky Linux to be itself |
| rocky-logos | Self-managed | Required for Rocky Linux assets |
| rocky-indexhtml | Self-managed | Required for Rocky Linux default index |
| rocky-bookmarks | Self-managed | Required for Rocky Linux default browser bookmarks |
| anaconda | Patch, Branding | Turn off Red Hat specific options |
| anaconda-user-help | Patch, Branding | Ensure documenation references Rocky Linux |
| cloud-init | Patch | Ensure the managed user is cloud-user like upstream |
| cockpit-composer | Branding | Replace RHEL with Enterprise Linux |
| crash | Patch | Replace Red Hat with Rocky |
| dnf | Patch | Change bug tracker URL |
| firefox | Patch | Replace Red Hat settings with Rocky Linux settings |
| gcc | Patch | Change bug tracker URL |
| gdb | Patch | Replace Red Hat with Rocky Linux |
| java-17-openjdk* | Patch | Ensure portables are buildable on all releases |
| java-21-openjdk* | Patch | Ensure portables are buildable on all releases |
| libdnf | Patch | Change bug tracker URL |
| lorax-templates-rocky | Self-managed | Replacement for lorax-templates-rhel |
| nginx | Branding | Replace Red Hat with Rocky Linux |
| openldap | Patch | Ensure openldap-servers is built and available in plus repo |
| openscap | Patch | Ensure Rocky Linux is supported as a derivative |
| osbuild | Patch | Ensure Rocky Linux is supported |
| osbuild-composer | Patch | Ensure Rocky Linux is supported |
| PackageKit | Patch | Change support URL's to Rocky Linux wiki |
| redhat-rpm-config | Patch | Add Rocky Support |
| rust | Patch | Ensure that aarch64 and s390x can build rust (OOM) |
| scap-security-guide | Patch | Ensure Rocky Linux is supported as a derivative |
| subscription-manager* | Patch | Remove Red Hat references |
| systemd | Patch | Change support URL's to Rocky Linux |
| thunderbird | Patch | Replace Red Hat settings with Rocky Linux settings |
| toolbox | Patch | Ensure Rocky Linux image is the default |

19
docs/index.md
View File

@ -1,24 +1,16 @@
---
title: Release Engineering (SIG/Core)
title: SIG/Core
---
# Release Engineering (SIG/Core) Wiki
# SIG/Core Wiki
## About
The Rocky Linux Release Engineering Team (also known as SIG/Core) dedicates themselves to the development, building, management, production, and release of Rocky Linux. This group combines development and infrastructure in a single, cohesive unit of individuals that ultimately make the distribution happen.
The "SIG/Core" reference name is not a strict Special Interest Group (as defined by [the Rocky Linux wiki](https://wiki.rockylinux.org/special_interest_groups/)).
The general goals (or "interests") is:
* To ensure Rocky Linux is built and released in a complete and functional manner
* To ensure proper collaboration and development of the Peridot Build System
* To ensure all users, developers, and Special Interest Groups are have a solid, stable platform to build upon
The Rocky Linux Core Special Interest Group (SIG/Core) dedicates themselves to the development, building, management, production, and release of Rocky Linux for the Enterprise Linux community and the many users around the world. This group is a mixture of core Rocky Linux developers and infrastructure and the members of this group are also members of other groups within the Rocky Linux community (such as SIG/AltArch) as well as the Enterprise Linux community as a whole.
## Mission
Release Engineering strives to ensure a stable distribution is developed, built, tested, and provided to the community from the RESF as a compatible derivative of Red Hat Enterprise Linux. To achieve this goal, some of the things we do are:
SIG/Core strives to ensure a stable distribution is developed, built, tested, and provided to the community from the RESF as a compatible derivative of Red Hat Enterprise Linux. To achieve this goal, some of the things we do are:
* Ensuring a quality and fully compatible release product
* Developing and iterating on the build systems and architecture
@ -31,12 +23,13 @@ See the [What We Do](what_we_do.md) page for a more detailed explanation of our
## Getting In Touch / Contributing
There are various ways to get in touch with Release Engineering and provide help, assistance, or even just ideas that can benefit us or the entire community.
There are various ways to get in touch with SIG/Core and provide help, assistance, or even just ideas that can benefit us or the entire community.
* Chat
* Mattermost: [~development](https://chat.rockylinux.org/rocky-linux/channels/development) on Mattermost
* IRC: #rockylinux and #rockylinux-devel on [libera.chat](https://libera.chat)
* Matrix: [Rocky Linux General / Support](https://matrix.to/#/#rockylinux-support:matrix.org) and [Rocky Linux Development](https://matrix.to/#/#rockylinux-development:matrix.org)
* [RESF SIG/Core Issue Tracker](https://git.resf.org/sig_core/meta/issues)
* [Mail List](https://lists.resf.org/mailman3/lists/rocky.lists.resf.org/)

5
docs/legacy/.pages
View File

@ -1,5 +0,0 @@
---
nav:
- ... | index.md
- Koji Tagging: koji_tagging.md
- Debrand List: debrand_list.md

83
docs/legacy/debrand_list.md
View File

@ -1,83 +0,0 @@
---
title: Rocky Debrand Packages List
---
This is a list of packages that require changes to their material for acceptance in Rocky Linux. Usually this means there is some text or images in the package that reference upstream trademarks, and these must be swapped out before we can distribute them.
The first items in this list are referenced from the excellent CentOS release notes here: https://wiki.centos.org/Manuals/ReleaseNotes/CentOS8.1905#Packages_modified_by_CentOS
It is assumed that we will have to modify these same packages. It is also assumed that these changed packages might not necessarily be debranding.
However, this list is incomplete. For example, the package **Nginx** does not appear on the list, and still has RHEL branding in the CentOS repos. We will need to investigate the rest of the package set and find any more packages like this that we must modify.
One way to find said changes is to look for `?centos` tags in the SPEC file, while also looking at the manual debranding if there was any for the `c8` branches.
There will be cases where a search and replace for `?centos` to `?rocky` will be sufficient.
Current patches (for staging) are [here](https://git.rockylinux.org/staging/patch).
## Packages that need debranding changes:
| Package | Notes | Work Status |
|:--------|--------------|-------------------------|
| abrt | See [here](https://git.rockylinux.org/staging/patch/abrt) | **DONE** |
| anaconda | See [here](https://git.rockylinux.org/staging/patch/anaconda) | **DONE** |
| apache-commons-net | AppStream module with elevating branch names | NO CHANGES REQUIRED |
| ~~basesystem~~ | (does not require debranding, it is a skeleton package) | NO CHANGES REQUIRED |
| cloud-init | See [here](https://git.rockylinux.org/staging/patch/cloud-init) | **DONE** - NEEDS REVIEW IN GITLAB (Rich Alloway) |
| cockpit | See [here](https://git.rockylinux.org/staging/patch/cockpit) | **DONE** |
| ~~compat-glibc~~ | | NOT IN EL 8 |
| dhcp | See [here](https://git.rockylinux.org/staging/patch/dhcp) | **DONE**, NEEDS REVIEW IN GITLAB (Rich Alloway) |
| firefox | See [here](https://git.rockylinux.org/staging/patch/firefox) -- Still requires a distribution.ini ID | **MOSTLY DONE** (Louis) |
| fwupdate | | NOT STARTED |
| glusterfs | Changes don't appear to be required | NO CHANGES REQUIRED |
| gnome-settings-daemon | No changes required for now. | NO CHANGES REQUIRED |
| grub2 | (secureboot patches not done, just debrand) See [here](https://git.rockylinux.org/staging/patch/grub2) | **DONE**, NEEDS REVIEW IN GITLAB AND SECUREBOOT (Rich Alloway) |
| httpd | See [here](https://git.centos.org/rpms/httpd/c/2f74eecf85362e67c403b7b1386a729da3e5c33d?branch=c8-stream-2.4) | **DONE** |
| initial-setup | See [here](https://git.rockylinux.org/staging/patch/initial-setup) | **DONE** |
| ipa | This is a dual change: Logos and ipaplatform. Logos are taken care of in `rocky-logos` and the `ipaplatform` is taken care of here. See [here](https://git.rockylinux.org/staging/patch/ipa) | **DONE** |
| ~~kabi-yum-plugins~~ | | NOT IN EL 8 |
| kernel | See [here](https://git.centos.org/rpms/kernel/c/20287bd53a5c2e87db2470380271b72ac8a1ed59?branch=c8) for a potential example | NOT STARTED |
| ~~kde-settings~~ | | NOT IN EL 8 |
| libreport | See [here](https://git.rockylinux.org/staging/patch/libreport) | **DONE** |
| oscap-anaconda-addon | See [here](https://git.rockylinux.org/staging/patch/oscap-anaconda-addon) | **DONE** Requires install QA |
| PackageKit | See [here](https://git.rockylinux.org/staging/patch/PackageKit) | **DONE** |
| ~~pcs~~ | | NO CHANGES REQUIRED |
| plymouth | See [here](https://git.rockylinux.org/staging/patch/plymouth) | **DONE** |
| ~~redhat-lsb~~ | | NO CHANGES REQUIRED |
| redhat-rpm-config | See [here](https://git.rockylinux.org/staging/patch/redhat-rpm-config) | **DONE** |
| scap-security-guide | QA is likely required to test this package as it is | NO CHANGES REQUIRED, QA REQUIRED |
| shim | | NOT STARTED |
| shim-signed | | NOT STARTED |
| sos | See [here](https://git.rockylinux.org/staging/patch/sos) | **DONE** |
| subscription-manager | See [here](https://git.rockylinux.org/staging/patch/subscription-manager) | **DONE**, NEEDS REVIEW |
| ~~system-config-date~~ | | NOT IN EL8 |
| ~~system-config-kdump~~ | | NOT IN EL8 |
| thunderbird | See [here](https://git.rockylinux.org/staging/patch/thunderbird) | **DONE** |
| ~~xulrunner~~ | | NOT IN EL 8 |
| ~~yum~~ | | NO CHANGES REQUIRED |
| **(end of CentOS list)**
| nginx | Identified changes, in staging | (ALMOST) **DONE** |
## Packages that need to become other packages:
We will want to create our own versions of these packages. The full "lineage" is shown, from RHEL -> CentOS -> Rocky (Where applicable)
| Package | Notes |
|:--------|--------------|
| redhat-indexhtml -> centos-indexhtml -> rocky-indexhtml | [Here](https://git.rockylinux.org/original/rpms/rocky-indexhtml) |
| redhat-logos -> centos-logos -> rocky-logos | [Here](https://git.rockylinux.org/original/rpms/rocky-logos) |
| redhat-release-* -> centos-release -> rocky-release | [Here](https://git.rockylinux.org/original/rpms/rocky-release) |
| centos-backgrounds -> rocky-backgrounds | Provided by [logos](https://git.rockylinux.org/original/rpms/rocky-logos) |
| centos-linux-repos -> rocky-repos | [Here](https://git.rockylinux.org/original/rpms/rocky-repos) |
| centos-obsolete-packages | [Here](https://git.rockylinux.org/original/rpms/rocky-obsolete-packages) |
## Packages that Exist in RHEL, but not in CentOS
For sake of complete information, here is a list of packages that are in RHEL 8, but do not exist in CentOS 8. We do not need to worry about these packages:
- insights-client
- Red_Hat_Enterprise_Linux-Release_Notes-8-*
- redhat-access-gui
- redhat-bookmarks
- subscription-manager-migration
- subscription-manager-migration-data

9
docs/legacy/index.md
View File

@ -1,9 +0,0 @@
---
title: Legacy
---
Legacy documentation comes here.
[Debrand List](debrand_list.md)
[Koji Tagging](koji_tagging.md)

85
docs/legacy/koji_tagging.md
View File

@ -1,85 +0,0 @@
---
title: Koji Tagging Strategy
---
This document covers how the Rocky Linux Release Engineering Team handles the tagging for builds in Koji and how it affects the overall build process.
## Contact Information
| | |
| - | - |
| **Owner** | Release Engineering Team |
| **Email Contact** | releng@rockylinux.org |
| **Mattermost Contacts** | `@label` `@mustafa` `@neil` `@tgo` |
| **Mattermost Channels** | `~Development` |
## What is Koji?
Koji is the build system used for Rocky Linux, as well as CentOS, Fedora, and likely others. Red Hat is likely to use a variant of Koji called "brew" with similar functionality and usage. Koji uses mock, a common RPM building utility, to build RPMs in a chroot environment.
## Architecture of Koji
### Components
Koji comprises of multiple components:
* `koji-hub`, which is the center of all Koji operations. It runs XML-RPC and relies on other components to call it for actions. This piece will also talk to the database and is one component that has write access to the filesystem.
* `kojid`, which is the daemon that runs on the builder nodes. It's responsibility is to talk to the hub for actions in which it can or has to perform, for example, building an RPM or install images. But that is not all that it can do.
* `koji-web` is a set of scripts that provides the web interface that anyone can see at our [koji](https://kojidev.rockylinux.org).
* `koji` is the command line utility that is commonly used - It is a wrapper of the various API commands that can be called. In our environment, it requires a login via kerberos.
* `kojira` is a component that ensures repodata is updated among the build tags.
### Tags
Tags are the most important part of the koji ecosystem. With tags, you can have specific repository build roots for the entire distribution or just a simple subset of builds that should not polute the main build tags (for example, for SIGs where a package or two might be newer (or even older) than what's in BaseOS/AppStream.
Using tags, you can setup what is called "inheritance". So for example. You can have a tag named `dist-rocky8-build` but it happens to inherit `dist-rocky8-updates-build`, which will likely have a newer set of packages than the former. Inheritance, in a way, can be considered setting "dnf priorities" if you've done that before. Another way to look at it is "ordering" and "what comes first".
Targets call tags to send packages to build in, generally.
## Tag Strategy
The question that we get is "what's the difference between a build and an updates-build tag" - It's all about the inheritance. For example, let's take a look at `dist-rocky8-build`
```
dist-rocky8-build
el8
dist-rocky8
build-modules
. . .
```
In this tag, you can see that this build tag inherits el8 packages first, and then the packages in dist-rocky8, and then build-modules. This is where "base" packages start out at, generally and a lot of them won't be updated or even change with the lifecycle of the version.
```
dist-rocky8-updates-build
el8
dist-rocky8-updates
dist-rocky8
dist-rocky8-build
build-modules
```
This one is a bit different. Notice that it inherits el8 first, and then dist-rocky8-updates, which inherits dist-rocky8. And then it also pulls in dist-rocky8-build, the previous tag we were talking about. This tag is where updates for a minor release are sent to.
```
dist-rocky8_4-updates-build
el8_4
dist-rocky8-updates
dist-rocky8
dist-rocky8-build
el8
build-modules
```
Here's a more interesting one. Notice something? It's pretty similar to the last one, but see how it's named el8_4 instead? This is where updates during 8.4 are basically sent to and that's how they get tagged as `.el8_4` on the RPM's. The `el8_4` tag contains a build macros package that instructs the `%dist` tag to be set that way. When 8.5 comes out, we'll basically have the same setup.
At the end of the day, builds that happen in these updates-build tags get dropped in dist-rocky8-updates.
### What about modules?
Modules are a bit tricky. We generally don't touch how MBS does its tags or what's going on there. When builds are being done with the modules, they do end up using the el8 packages in some manner or form. The modules are separated entirely from the main tags though, so they don't polute the main tags. You don't want a situation where say, you build the latest ruby, but something builds off the default version of ruby provided in `el8` and now you're in trouble and get dnf filtering issues.
### How do we determine what is part of a compose?
There are special tags that have a `-compose` suffix. These tags are used as a way to pull down packages for repository building during the pungi process.

25
docs/members.md
View File

@ -2,19 +2,14 @@
title: Members
---
Release Engineering (SIG/Core) is a mix of Development and Infrastructure members to ensure a high quality release of Rocky Linux as well as the uptime of the services provided to the community. The current members of this group are listed in the table below. Some members may also be found in various Special Interest Groups, such as SIG/AltArch and SIG/Kernel.
SIG/Core is a mix of Release Engineering and Infrastructure members to ensure a high quality release of Rocky Linux as well as the uptime of the services provided to the community. The current members of this group are listed in the table below.
| Role | Name | Email | Mattermost Name | IRC Name | Affiliation |
|---------------------------------------------------|---------------------------------|------------------------ |-------------------|--------------------|-------------|
| Release Engineering Co-Lead and Infrastructure | Louis Abel | label@rockylinux.org | @label | Sokel/label/Sombra | Independent |
| Release Engineering Co-Lead | Mustafa Gezen | mustafa@rockylinux.org | @mustafa | mstg | Independent |
| Release Engineering and Development | Skip Grube | skip@rockylinux.org | @skip77 | | CIQ |
| Release Engineering and Development | Sherif Nagy | sherif@rockylinux.org | @sherif | | Independent |
| Release Engineering and Development | Pablo Greco | pgreco@rockylinux.org | @pgreco | pgreco | Independent |
| Infrastructure Lead | Neil Hanlon | neil@resf.org | @neil | neil | CIQ |
| Infrastructure Lead | Taylor Goodwill | tg@resf.org | @tgo | tg | Independent |
!!! note
Some members of Release Engineering may be affiliated with a sponsor of the Rocky Linux project or the Rocky Enterprise Software Foundation, as such they are listed here for transparency.
Independent members are those who are not affiliated with any sponsor of the project or foundation.
| Role | Name | Email | Mattermost Name | IRC Name |
|---------------------------------------------------|---------------------------------|------------------------ |-------------------|--------------------|
| Release Engineering Co-Lead and Infrastructure | Louis Abel | label@rockylinux.org | @nazunalika | Sokel/label/Sombra |
| Release Engineering Co-Lead | Mustafa Gezen | mustafa@rockylinux.org | @mustafa | mstg |
| Release Engineering and Development | Skip Grube | skip@rockylinux.org | @skip77 | |
| Release Engineering and Development | Sherif Nagy | sherif@rockylinux.org | @sherif | |
| Release Engineering and Development | Pablo Greco | pgreco@rockylinux.org | @pgreco | pgreco |
| Infrastructure Lead | Neil Hanlon | neil@resf.org | @neil | neil |
| Infrastructure Lead | Taylor Goodwill | tg@resf.org | @tgo | tg |

7
docs/rpm/index.md
View File

@ -1,7 +0,0 @@
---
title: RPM
---
This section is primarily for documentation and useful information as it
pertains to package building and modularity. Use the menu on the left side to
find the information you're looking for.

1570
docs/rpm/local_module_builds.md
View File

File diff suppressed because it is too large Load Diff

14
docs/sop/sop_compose.md
View File

@ -41,12 +41,12 @@ Each repository or set of repositories are controlled by various comps and pungi
First, the toolkit must be cloned. In the `iso/empanadas` directory, run `poetry install`. You'll then have access to the various commands needed:
* `sync-from-peridot`
* `sync_from_peridot`
* `build-iso`
* `build-iso-extra`
* `pull-unpack-tree`
* `pull-cloud-image`
* `finalize-compose`
* `finalize_compose`
#### Full Compose
@ -54,7 +54,7 @@ To perform a full compose, this order is expected (replacing X with major versio
```
# This creates a brand new directory under /mnt/compose/X and symlinks it to latest-Rocky-X
poertry run sync-from-peridot --release X --hashed --repoclosure --full-run
poertry run sync_from_peridot --release X --hashed --repoclosure --full-run
# On each architecture, this must be ran to generate the lorax images
# !! Use --rc if the image is a release candidate or a beta image
@ -76,7 +76,7 @@ poetry run pull-cloud-image --release X
# This ensures everything is closed out for a release. This copies iso's, images,
# generates metadata, and the like.
# !! DO NOT RUN DURING INCREMENTAL UPDATES !!
poetry run finalize-compose --release X
poetry run finalize_compose --release X
```
#### Incremental Compose
@ -86,7 +86,7 @@ It is possible to simply compose singular repos if you know which ones you want
```
# Set your repos as desired. --arch is also acceptable.
# --ignore-debug and --ignore-source are also acceptable options.
poetry run sync-from-peridot --release X --hashed --clean-old-packages --repo X,Y,Z
poetry run sync_from_peridot --release X --hashed --clean-old-packages --repo X,Y,Z
```
## Syncing Composes
@ -133,10 +133,8 @@ Once the syncs are done, staging must be tested and vetted before being sent to
```
# Set X to whatever release
RLVER=X bash sync-to-prod.delete.sh
bash RLVER=X sync-to-prod.delete.sh
bash sync-file-list-parallel.sh
# Sends data to the vault and masks repodata
RLVER=X bash vault-release-no-repodata.sh
```
During this phase, staging is rsynced with production, the file list is updated, and the full time list is also updated to allow mirrors to know that the repositories have been updated and that they can sync.

28
docs/sop/sop_compose_8.md
View File

@ -6,10 +6,6 @@ This SOP covers how the Rocky Linux Release Engineering Team handles composes an
Please see the other SOP for Rocky Linux 9+ that are managed via empanadas and peridot.
!!! warning
**IF YOU HAVE BUILT ANY MODULES, YOU MUST UPDATE THE YAMLS MANUALLY AT /mnt/compose/8_metadata**
**NOT DOING THIS WILL CAUSE ISSUES FOR COMPOSES AND THE USERS**
## Contact Information
| | |
| - | - |
@ -46,17 +42,6 @@ There is a designated system that takes care of composing repositories. These sy
Each repository or set of repositories are controlled by various pungi configurations. For example, `r8.conf` will control the absolute base of Rocky Linux 8, which imports other git repository data as well as accompanying json or other configuration files.
### Quick Compose
On the designated compose box, there is a script that can do all of the incremental steps.
```
cd /root/cron
bash stable-updates
```
After, it can be synced to production.
### Running a Compose
Inside the `pungi` git repository, the folder `scripts` contain the necessary scripts that are ran to perform a compose. There are different types of composes:
@ -150,4 +135,17 @@ During this phase, staging is rsynced with production, the file list is updated,
**Note**: If multiple releases are being updated, it is important to run the syncs to completion before running the file list parallel script.
## Quicker Composes
On the designated compose box, there is a script that can do all of the incremental steps.
```
cd /root/cron
bash stable-updates
```
The same goes for a full production.
```
bash stable
```

6
docs/sop/sop_compose_sig.md
View File

@ -31,16 +31,16 @@ Each repository or set of repositories are controlled by various comps and pungi
First, the toolkit must be cloned. In the `iso/empanadas` directory, run `poetry install`. You'll then have access to the various commands needed:
* `sync-sig`
* `sync_sig`
To perform a compose of a SIG, it must be defined in the configuration. As an example, here is composing the `core` sig.
```
# This creates a brand new directory under /mnt/compose/X and symlinks it to latest-SIG-Y-X
~/.local/bin/poetry run sync-sig --release 9 --sig core --hashed --clean-old-packages --full-run
~/.local/bin/poetry run sync_sig --release 9 --sig core --hashed --clean-old-packages --full-run
# This assumes the directories already exist and will update in place.
~/.local/bin/poetry run sync-sig --release 9 --sig core --hashed --clean-old-packages
~/.local/bin/poetry run sync_sig --release 9 --sig core --hashed --clean-old-packages
```
## Syncing Composes

9
docs/what_we_do.md
View File

@ -2,19 +2,14 @@
title: What We Do
---
Release Engineering (SIG/Core) was brought together as a combination of varying expertise (development and infrastructure) to try to fill in gaps of knowledge but to also to ensure that the primary goal of having a stable release of Rocky Linux is reached.
SIG/Core (or Release Engineering) was brought together as a combination of varying expertise (development and infrastructure) to try to fill in gaps of knowledge but to also to ensure the primary goal of having a stable release of Rocky Linux is reached.
Some of the things we do in pursuit of our mission goals:
* Continuous preparation for upcoming changes from upstream (Fedora and CentOS Stream)
* Distribution release and maintenance
* Design and collaboration for the Peridot build system
* Design and development work to integrate all components together
* Maintenance of the infrastructure used to build and maintain Rocky Linux (such as ansible roles and playbooks)
* Working with the testing team with images and a platform to test
* Providing resources for Special Interest Groups
* Providing assistance and resources for users within the community to meet their goals
"Why the name SIG/Core?"
While not an actual [Special Interest Group](https://wiki.rockylinux.org/special_interest_groups/), the reality is that Release Engineering is ultimately the "core" of Rocky Linux's production. The idea of "SIG/Core" stemmed from the thought that without this group, Rocky Linux would not exist as it is now, so we are "core" to its existence. The other idea was that SIG/Core would eventually branch out to elsewhere. Where this would go, it is uncertain.
* Providing assistance and resources for users within the community

62
mkdocs.yml
View File

@ -1,46 +1,66 @@
---
# Wiki information
site_name: Release Engineering (SIG/Core) Wiki
site_name: SIG/Core Wiki
site_url: https://sig-core.rocky.page
site_description: >-
The wiki for Rocky Linux Release Engineering (SIG/Core)
The wiki for Rocky Linux Core SIG.
# Repository
repo_url: https://git.resf.org/sig_core/wiki
repo_name: sig_core/wiki
edit_uri: edit/main/docs/
copyright: Copyright &copy; 2022-2024 Rocky Enterprise Software Foundation
extra_css:
- assets/extra.css
# Configuration
theme:
name: material
logo: assets/resf-white.svg
palette:
- media: "(prefers-color-scheme: light)"
scheme: default
primary: teal
accent: teal
scheme: resf
toggle:
icon: material/weather-night
name: Switch to dark mode
- media: "(prefers-color-scheme: dark)"
scheme: slate
primary: teal
accent: teal
scheme: resf-dark
toggle:
icon: material/weather-night
name: Switch to dark mode
logo: assets/icon-white.svg
icon: material/weather-sunny
name: Switch to light mode
highlightjs: true
hljs_languages:
- bash
- perl
- python
- yaml
- perl
features:
- navigation.expand
- navigation.indexes
- navigation.instant
- navigation.sections
- navigation.top
- navigation.tracking
- navigation.path
- search.highlight
- search.suggest
- toc.integrate
#- navigation.tabs
#- navigation.tabs.sticky
#- navigation.top
- content.action.edit
# Plugins
plugins:
- autolinks
- social
- awesome-pages
- git-revision-date-localized:
type: date
- search
- macros:
include_dir: docs/include
# Extensions
markdown_extensions:
- abbr
- admonition
@ -48,7 +68,7 @@ markdown_extensions:
- def_list
- footnotes
- meta
- pymdownx.details # collapsable attributions
- pymdownx.details # this allows collapsible attributions
- pymdownx.emoji:
emoji_index: !!python/name:material.extensions.emoji.twemoji
emoji_generator: !!python/name:material.extensions.emoji.to_svg
@ -57,13 +77,3 @@ markdown_extensions:
alternate_style: true
- toc:
permalink: true
plugins:
- autolinks
- awesome-pages
- git-revision-date
- search
- macros:
include_dir: docs/include
copyright: Copyright &copy; 2024 Rocky Enterprise Software Foundation
...

3
requirements.txt
View File

@ -2,7 +2,8 @@ mkdocs
mkdocs-cinder
mkdocs-autolinks-plugin
mkdocs-awesome-pages-plugin
mkdocs-git-revision-date-plugin
mkdocs-git-revision-date-localized-plugin
mkdocs-macros-plugin
mkdocs-material
mkdocs-windmill
mkdocs-material[imaging]