The individual folders represent our builders.
The individual *.txt
files are so-called routines and package lists that are going to be built at individual times. Resource-consuming packages are likely not put into hourly routines while smaller packages are.
Stable packages are only downloaded if an update is detected, -git
ones are always downloaded but only built if their version changed (down/upgrade doesn't matter).
AUR packages just need their pkgname added.
Non-AUR packages are added as follows: pkgname:https://some.url.git
(this can also be used to force the download of a package that never changes version but is still updated, eg. a package building from git but incorrectly not having the -git
suffix.
Packages that are part of a pkgbase
need their pkgbase
added instead of one of their pkgnames
. Repoctl can't handle such packages yet, therefore one needs to treat it as -git
package. Eg.: pkgbase:https://some.url.git
Where to place newly added packages?
-bin
and all other, quick-to-build packages belong into hourly
routines. Likewise, heavy packages belong in daily
.ufscar-hpc
- it is a big cluster with a lot of processing power. Balancing packages between hourly.1
and hourly.2
routines is a good idea.ufscar-hpc
, eg. ungoogled-chromium
garuda-cluster
handles packages of the Garuda team and also a huge amounf of packages which used to built on dragon-cluster
.garuda-repo
handles packages of the Garuda team and is exclusively managed by team members. Most of the packages built are getting built by the custom garuda
routine. TKG Kernels are also managed by this guy.garuda-cluster
also builds the complete kde-git
stack to a separate chaotic-aur-kde
repository.CatBuilder
is @Edu4rdSHL PC, therefore he is the only one managing the package list.Since its best to keep good track of where packages came from, the established way of formatting the package list:
ufscar-hpc
or garuda-cluster
routines. Take a look at where other maintainers added their stuff and add it accordingly.# Issue 1337
absolutelyrequireddependency # (dep superfancypackage)
superfancypackage
# Nico
everything-git
firedragon
octopi-git
sudo-git
If a package for some reason needs to be built before another one, a "barrier" can be put in place to force every makepkg before the barrier to finish before attempting to build the packages after it:
pkgname=somepackage
the folder would be somepackage
. Likewise, several conditions can trigger actions.prepare
: A script which is being executed after the building chroot has been set up. It can be used to source environment variables or modify other things before compilation starts.$CAUR_PUSH 'source /etc/profile'
. Likewise, package conflicts can be solved, eg. as follows: $CAUR_PUSH 'yes | pacman -S nftables'
(single quotes are important because we want the variables/pipes to evaluate in the guest's runtime and not while interfering)interfere.patch
: a patch file that can be used to fix either multiple files or PKGBUILD if a lot of changes are required. All changes need to be added to this file.PKGBUILD.prepend
: contents of this file are added to the beginning of PKGBUILD.PKGBUILD.append
: contents of this file are added to the end of PKGBUILD. Fixing build()
as is easy as adding the fixed build()
into this file. This can be used for all kinds of fixes. If something needs to be added to an array, this is as easy as makedepend+=(somepackage)
.on-failure.sh
: A script that is being executed if the build fails.on-success.sh
: A script that is being executed if the build succeeds.pkgrel
can be done by downloading the PKGBUILD (chaotic get somepackage
), increasing its pkgrel temporarily (chaotic bump somepackage
) and building it afterward (chaotic mkd somepackage
).chaotic bump
command syncs the incremented pkgrel back to the interfere repo, which means it will be available for all other builders too. This can be useful for mass rebuilds as well, eg. in the case of Python version updates.chaotic get somepackage
chaotic mkd somepackage
chaotic get somepackage
chaotic bump somepackage
chaotic mkd somepackage
git clone someurl.git
chaotic mkd justclonedfolder
chaotic cls somepackage
chaotic si
.log/.lock
files and build directories, keeping the failed logs):chaotic cleanpwd
chaotic mkd
or chaotic routine
can be parallelized by adding -j 10
before the command, eg. chaotic -j 10 routine hourly
- this will save a lot of time, especially when building a lot of -git
packages.makedepends+=(missingdep)
chaotic si
chaotic get somepackage && chaotic mkd somepackage
chaotic get somepackage
pkgrel
of the package: chaotic bump somepackage
chaotic mkd somepackage
ufscar-hpc
user which needs its public key added in authorized_keys
srv/http/repos/chaotic-aur/
need to be set up as follows so nodes can upload their packages:
chmod g+s x86_64 logs
chown -R :chaotic_op x86_64 logs
chmod 775 x86_64 logs
chmod 664 x86_64/* logs/*
chaotic dbb
and adding the packages to database fails due to this, symlink /usr/local/bin/chaotic
to /usr/bin/chaotic
cd /srv/http/repos/chaotic-aur
sudo ln -sfT x86_64/chaotic-mirrorlist-20211231-1-any.pkg.tar.zst chaotic-mirrorlist.pkg.tar.zst
sudo ln -sfT x86_64/chaotic-mirrorlist-20211231-1-any.pkg.tar.zst.sig chaotic-mirrorlist.pkg.tar.zst.sig
config.toml
in /root/.config/repoctl
su -
to ensure settings are presentrepoctl reset
to create a new database with all files addedsrun --cpus-per-task=40 --time=3:00:00 --partition=fast --pty bash -i
cd $(mktemp -d)
cd ~/chaotic/toolbox && git pull --ff-only
chaotic sd; chaotic sp; chaotic si; chaotic lowerstrap
myjobs
# In myjob's output you'll see JOBIDs
cd ~/chaotic/toolbox/slurm-jobs/ufscar-hpc/
tail slurm-${JOBID}.out
scontrol update JobID=562597 StartTime=NOW
cd ~/chaotic/toolbox/slurm-jobs/ufscar-hpc/
scancel ${JOBID}
rm "${JOBID}.out"
ls -1 *.sh
sbatch ${JOB_NAME}.sh
ssh ${CONTROLLER_CN}
~/emergency-cleanup.sh