nazunalika / lazybuilder

Hi there

I'm Louis Abel. I'm originally a System Administrator, turned System Engineer, turned... I'm not sure anymore. I wear a lot of hats these days. Either way, I want to thank you for stopping by!

What do you work on?

I work on too many things to remember or count. The primary things I work on though these days would be:

• Ansible stuff
• My own FreeIPA adventures
• My own Fedora system when it misbehaves
• Some gzdoom builds (when they have releases)
• Maintaining some python and powershell scripts, Windows images (for my own sanity)
• Light maintaining of a wiki with some Enterprise Linux and Fedora stuff

What do you do in your free time?

I work on my music or I go to one of my few go-to games at my disposal, such as StarCraft, Guilty Gear Strive, gzdoom, and Overwatch. If you would like to play StarCraft (brood war/remastered) or Guilty Gear Strive, I am always open! You can find me on the US West regions.

GitHub Stats!

lazybuilder's Issues

[ETI] lazysigner system

What am I trying to solve?
Signing RPMs after builds or mass signing

What are the benefits of this?
RPMs built with lazybuilder are not GPG signed. It would be beneficial for RPMs built with lazybuilder to be signed by a GPG key of the user's choice.

Additional context and information
Package integrity

[ETI] Parallel Builds

What am I trying to solve?
Some builds (in particular, modules) should have the ability to be parallel builds. It's unlikely that a user will have a build system that is only one host for that architecture. We want to try to see if we can solve this in ansible.

What are the benefits of this?
Quicker builds for packages that don't necessarily rely on each other or have to - think for modules where a group (say buildgroup: 0) may have more than one package that can be built in parallel.

Additional context and information
Other build systems are intelligent enough to do this. Are we? Probably not, but let's try.

There should be a way also to make the play "wait" until all other builds are done and successful before moving on to the createrepo state (which only one host should be able to do).

[ETI] Skip package builds that do not match current mock_arch

What am I trying to solve?
There are some modules that have specific arches listed for builds. We need to be able to skip those. There are also packages with specific architectures that are isolated away from others (eg, kernels only build for x86_64, ppc64le, aarch64, s390x)

Optionally, this should add it to a list at /opt/repo/common/{{major}}_{{mock_arch}}_skip

What are the benefits of this?
Prevent pointless ansible failures.

Additional context and information
N/A

[ETI] Basic or Module builds based on what's available in a directory

What am I trying to solve?
There are some cases that instead of providing a list of RPM's (in URL form) to build in a chain, it would be simpler to have them already built and downloaded and available to the builder somewhere in repo_path - Optionally, we can provide the ability to just build the source RPM's and drop them somewhere or just download them somewhere as needed.

For Basic Builds
Chains are all well and good, but we want to provide a way to just provide a directory filled with srpms to build. This is a potential use case for some.

For Modules
There are some module builds that are either difficult or impossible to do in the current state. What we want to do is have the ability to do builds based on srpms that are available in the repo directories and go from there, taking into account that the module YAML is still imported from git. So in essence, the following should happen:

• Module vars are setup by looking at the git repo information and the like
• A directory is provided that has the module's name and version number
• During setup, mock_srpm_path will be built as a list, either by:
  • Checking if there are buildgroup-NUMBER directories and building the list based on that, or...
  • Looking at the build group list in the YAML, doing comparisons, and adding as they're found in found directory
• Module is built like normal

Downloader/srpm builder

We can provide tasks that will allow us to just build source RPM's and drop them somewhere to be built later or just download them to be used elsewhere. We may want the playbook to look for a dictionary type of var, something like this:

build_srpm_list:
  gcc:
    branch: r8
    # Potentially use this to override the location?
    git_url: https://git.rockylinux.org/staging/rpms/gcc.git
    buildorder: 0
  glibc:
    branch: r8
    git_url: https://git.rockylinux.org/staging/rpms/glibc.git
    buildorder: 1
  bash:
    branch: r8
    git_url: https://git.rockylinux.org/staging/rpms/bash.git
    buildorder: 2
  mksh:
    branch: r8
    git_url: https://git.rockylinux.org/staging/rpms/mksh.git
    buildorder: 2
pull_srpm_list:
  kernel:
    url: https://some.url.com/kernel-4.18.0-305.17.1.el8_4.src.rpm
    buildorder: 3

What are the benefits of this?
Makes life easier of some users or provides the ability to "stage" builds.

Additional context and information
Everything above is all we need.

[ETI] Add transmodrify support

What am I trying to solve?
Modules already imported have a YAML already generated, usually by upstream in some form. They are formed by taking the data from the modulemd.src.txt file in SOURCES in a repo. We need to be able to generate a brand new one and reimport into git.

What are the benefits of this?
Some users may want this kind of support.

Additional context and information
N/A

[ETI] Merge Module Repos

What am I trying to solve?
When modules are made, they create singular repos. We need to be able to select modules and combine them in a repo of our choice.

What are the benefits of this?
Reduce manual work.

Additional context and information
N/A

[ETI] Add support for pulp

What am I trying to solve?
Repo creation is simple and is easily solved by using NFS-like mounts on the builders. However, there is a chance users may want pulp support.

What are the benefits of this?
Pulp is a software repository management system.

Additional context and information
N/A at this time

[ETI] Add multi-arch + noarch support

What am I trying to solve?
Some builds should support multi-arch. For example, x86_64 builds typically have accompanying i686 builds in koji. We should emulate something similar. At the same time, other arches should be allowed during build too if applicable.

It should also be possible to detect if a build is going to be "noarch" and check for already built versions of such, as well as putting them in their own repos.

What are the benefits of this?
This helps with some form of consistency across builds.

Additional context and information
n/a

[ETI] lazycomposer system

What am I trying to solve?

There should be a way to compose repositories akin to pungi-koji used in Fedora and CentOS.

What are the benefits of this?

It should allow to compose repositories using one stop tool, similar to how lazybuilder and lazysigner are working.

Additional context and information
Some key pungi configurations should be supported.