Packages for Universal Blue projects.
We use this repository as the base for multiple Universal Blue COPRs each one with their own purpose defined on their READMEs.
You can build any package by running our custom builder container, it should fetch the sources and do everything for you.
It mounts mock/
on the current directory so that you can get the resulting RPMs/SRPMs and check the resulting chroots
# You can specify whatever chroot you want to use, usually those that are supported on COPR should work
just build $PATH_TO_SPEC $ARGUMENTS_FOR_MOCK
# This builds devpod on the Fedora version that the builder container is on (F41)
just build ./staging/devpod/devpod.spec
# This builds devpod on the CentOS Stream + EPEL 10 chroot
just build ./staging/devpod/devpod.spec -r epel-10-$(arch)
# You can also compile for other architectures by passing --forcearch if you have qemu-user-static on your host system
just build ./staging/devpod/devpod.spec --forcearch=aarch64
When adding a new package certain guidelines should be followed, usually try to stick to the Fedora Packaging Guidelines
for all packages (with case-by-case exceptions). rpmlint
should always pass (rpkg-based packages are an exception),
they should always be buildable offline once all sources are fetched (so that they can be built on GitHub actions/mock),
and always make sure that Renovate can automatically update your package, we have macros on this repo.
Once merged, your new package will need to be manually added to its corresponding COPR (file in an issue if it hasn't been added in a week or so) and then it should be automatically rebuilt over time.
Make sure your contribution passes linting and the guidelines required by the New Package section. Bump the package accordingly:
- If the package has sources on this repo, bump the
Version:
field; - If it has external sources, bump the spec
Release:
field (you can/should do it viarpmdev-bumpspec
ideally).
Make sure all the PRs are safe, as in they don't have RCE
exploits or any abuse of GitHub actions (or similar). When you are sure of that, put the safe-to-run
tag on the target
pull request and let it run. Sometimes some packages will require the runner to have an online connection and that isn't
implemented yet so you might want to review the commits on your local machine and make sure they build correctly with a network connection.
You can create a testing distrobox by running distrobox create --name testingbox --image ghcr.io/ublue-os/ublue-builder
or by running just build
from the locally cloned fork, it should be exactly the same environment as the GitHub actions use for building.