Manpages

NAME chkupd.cfg - Per package configuration file for krep upstream checks. DESCRIPTION PACKAGEPATH/chkupd.cfg is a per package configuration file for krep upstream checks. It is used to configure the behavior of krep check and update for a specific package. If a configuration file is not found, krep will use the arguments passed to it. SYNTAX chkupd.cfg uses a INI format. There is no default configuration file, but you can create one in the package directory. An example configuration file is below.

NAME jumpstart_dec - Main declaration format of Jumpstart DESCRIPTION Jumpstart decfiles are the main declaration format of Jumpstart. They are basic scripts with specific variables and functions that enable the user to create Jumpstart units such as services, mounts, and timers. DECFILE STRUCTURE Decfiles are simply named [UNITNAME].kg and must be placed inside the /etc/jumpstart directory. It is using Kongue under the hood, see kongue(5). Example Decfile name: "example" description: "Example multi unit with services, mounts, and timers" type: "multi" depends: - "network" depends main: - "example::data" after: - "sound" after_main: - "example::cache" mount data { from "/dev/nvme0n1p2" to "/mnt/data" fstype "ext4" timeout "10s" chmod 755 } mount cache { from "tmpfs" to "/var/cache/example" fstype "tmpfs" extra_args "-o size=512M" } service main { exec "/usr/bin/example-daemon --config /etc/example.conf" } service helper { exec "/usr/bin/example-helper" } timer cleanup { interval 3600 service "example-cleanup" on_missed "skip" } timer sync { interval 86400 service "example-sync" on_missed "run" } SYNTAX AND LANGUAGE FEATURES REQUIRED VARIABLES description: Description of the unit. type: Type of the unit. Valid values are: simple: A basic service that runs a single process. oneshot: A service that runs once and exits. multi: A unit containing multiple sub-units (services, mounts, or timers). timer: A timer that triggers a service at specified intervals. mount: A filesystem mount unit. target: A group of native units. A target has no function block. DEPENDENCY VARIABLES depends: Hard dependencies of your unit. When a target starts (including the boot target), every unit in the depends closure of its members is started too, whether or not it is enabled, and before the units that depend on it. A unit whose dependency is unknown or failed to start is not started and is reported as failed. Starting a single non-target unit with jumpctl start starts only that unit. Can also depend on a specific sub-unit using depends: "unitname::subunitname" depends subunitname: Specify dependencies for a specific sub-unit. Can be modified using: depends subunitname+: "unitname" to add a dependency depends subunitname-: "unitname" to remove a dependency depends subunitname: "unitname" to replace dependencies completely ORDERING VARIABLES after: Start this unit after the specified units when both are started together. Unlike depends, after never pulls a unit in and ignores units that are not present. after subunitname: Specify ordering for a specific sub-unit. Can be modified using: after subunitname+: "unitname" to add an ordering after subunitname-: "unitname" to remove an ordering after subunitname: "unitname" to replace orderings completely OPTIONAL VARIABLES name: Name of the unit. If not specified, defaults to the filename without the .kg extension. REQUIRED FUNCTIONS The required function depends on the unit type:

NAME Kongue - Scripting langauge of Kreato Linux DESCRIPTION Kongue is the main scripting language made for use in Kreato Linux projects. It is inspired by YAML and sh among many other languages. It is currently used by kpkg as the main package format (see kpkg_run(5) for specific details). KONGUE STRUCTURE Kongue scripts don’t have a global file extension, though .kg or .kongue might be used. Example Kongue script global_var_string: "test" global_var_bool: true global_var_array: - "hello" - "test" - "test2" func custom_func { print "This is a test custom function, hello $1" } # Different projects will have different main functions, such as build for kpkg_run(5). This is just an example. main { custom_func "Kreato" # Can run custom functions just like commands print "Test" exec "command -v bash" } SYNTAX AND LANGUAGE FEATURES VARIABLES Variables must be declared at the top of the script. They can be any type (list, string, int, bool, etc.). Variables can be referenced in if statements, for loops, and inside functions. On commands, simple referencing is done via $variable or ${variable}. Complex manipulation (splitting, slicing) works via ${variable.method()} (or variable.method() on a non-command context) (see VARIABLE MANIPULATION below).

NAME kpkg repl - interactive shell for kpkg DESCRIPTION kpkg repl starts an interactive read-eval-print loop (REPL) for kpkg. It provides a powerful environment to inspect package information, modify configurations, and script kpkg operations using the run3 scripting language. The REPL supports session history (persisted to ~/.cache/kpkg/history), multi-line input for function definitions and blocks, and convenient shorthands for common get and set operations. Press Tab to complete REPL commands, run3 statements, dotted get and set invocations, configuration keys, and package names. When several matches are available, press Tab again to display them.

NAME kpkg runfile - Main package format of kpkg DESCRIPTION kpkg runfiles are the main package format of kpkg. They are basic scripts with specific variables and functions that enable kpkg to build packages. RUNFILE STRUCTURE Runfiles are simply named run3 and must be placed inside the package directory. It is using Kongue under the hood, see kongue(5). Example Runfile name: "test-v3" version: "0.0.1" release: "1" sources: - "https://test.file/source/testfile.tar.gz" - "git::https://github.com/kreatolinux/src::543ee30eda806029fa9ea16a1f9767eda7cab4d1" - "https://test.file/sources/v${version.split('.')[0:2].join('.')}/testfile.tar.gz" depends: - "testpackage1" - "testpackage3" - "testpackage4" depends test2: - "testpackage5" - "testpackage6" no_chkupd: false replaces: - "test-v2" backup: - "etc/test-v3/main.conf" - "etc/test/settings.conf" opt_depends: - "optional-dependency: This is a test optional dependency" - "optional-dependency-2: This is a second optional dependency." build_depends: - "testpackage5" - "testpackage6" - "testpackage10" sha256sum: - "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" - "SKIP" - "ab37404db60460d548e22546a83fda1eb6061cd8b95e37455149f3baf6c5fd38" sha512sum: - "cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e" - "SKIP" - "fce866720603d30cbefe5c0df9c6bacf70cbdb27caef5bcf15f125901cb23a9681ec9f87410a7d2f763af5a89c2b4e43685196ce3b0674868bf81cb3688e47c8" b2sum: - "786a02f742015903c6c6fd852552d272912f4740e15847618a86e217f71f5419d25e1031afee585313896444934eb04b903a685b1448b755d56f701afe9be2ce" - "SKIP" - "64fed8bce19ef14ed2d8434229dc2ec5307e06205610b1859b81b8090ae5ba7001988de896ff4878a15a7b7334e4a06e5889270b2e755fe130f7c80960e66ba2" license: - "GPL-3.0-or-later" description: "Test package" func custom_func { print "This is a test custom function" } prepare { custom_func # We can run custom functions just like commands env TEST=1 exec tar -xvf testfile.tar.gz # Or you can use: # macro extract --autocd=true # to extract all the archives in sources. } build { cd testfile echo "Insert build instructions here" } check { macro test --ninja # exec ninja -C build test } preupgrade { echo "run before upgrade" } preinstall { echo "run before first install" } package { cd testfile macro package --meson } package test2 { cd testfile exec make install_test2 # External commands require exec } postinstall { echo "Insert postinstall instructions here" } postupgrade { echo "run after upgrade" } postremove { echo "Insert postremove instructions here" } SYNTAX AND LANGUAGE FEATURES BUILTIN COMMANDS These are the built-in commands available in the runfile environment in addition to the default Kongue built-in commands (see kongue(5) for those):

NAME kpkg-target - kpkg target format DESCRIPTION kpkg-target is a target format based on the popular target format. It adds additional info that are a part of the base system. kpkg-target is used at various parts of kpkg. SYNTAX kpkg-target is very similar to the target format. It is a line that has 5 parts, seperated by -. An example kpkg target look like this; x86_64-linux-gnu-systemd-openssl First part is for the architecture, second part is for the OS, third part is for the toolchain, fourth part is for the init system, last part is for the TLS library.

NAME kpkg.conf - Configuration file for kpkg DESCRIPTION /etc/kpkg/kpkg.conf is the main configuration file on kpkg. A default one is included when you launch kpkg for the first time. SYNTAX kpkg.conf uses a INI format. The default configuration file currently looks like this; [Options] cc=gcc cxx=g++ ccache=false verticalSummary=false sourceMirror=mirror.krea.to/sources [Repositories] repoDirs=/etc/kpkg/repos/main /etc/kpkg/repos/lockin repoLinks="https://github.com/kreatolinux/kpkg-repo.git::stable https://github.com/kreatolinux/kpkg-repo-lockin.git::stable" binRepos="mirror.krea.to" [Parallelization] threadsUsed="1" [Upgrade] buildByDefault=yes [Logging] level=info timestamp=false colors=true fileLogging=false logFile=/var/log/kpkg.log OPTIONS cc: Set the CC environment variable when the package is building. Defaults to gcc. cxx: Set the CXX environment variable when the package is building. Defaults to g++. ccache: Boolean to enable ccache. Defaults to false. Will only have an effect if ccache is installed. cxxflags: Sets the CXXFLAGS environment variable on build. Defaults to nothing. cflags: Sets the CFLAGS environment variable on build. Defaults to nothing. verticalSummary: Boolean to enable vertical summaries. Defaults to false. sourceMirror: Source code mirror for build command. Will only be used if the main URL fails. Set to false to disable. Defaults to mirror.krea.to/sources. REPOSITORIES repoDirs: Repository directories. Must line up with repoLinks. Seperate by space. repoLinks: Repository links. Must line up with repoDirs. Seperate by space. Has kpkg-repo and kpkg-repo-lockin repositories by default. binRepos: Binary repository links. Is independent from repoDirs/repoLinks. Seperate by space. Will only accept repositories using HTTPS. Repositories also support branches/commits like this;

NAME override.conf - Configuration file for kpkg packages DESCRIPTION Override configs allow you to override package information on a specific package. Override configs reside in /etc/kpkg/override with the package name as the filename. (such as /etc/kpkg/override/bash.conf). SYNTAX override.conf uses an INI format like kpkg.conf(5). A full override.conf file might look something like this; [Flags] extraArguments="--disable-static --prefix=/usr/test" cflags="-march=native" cxxflags="-march=native" [runFile] sources="https://mirror.krea.to/bash.tar.gz" sha256sum="e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" [Mirror] sourceMirror="mirror.krea.to/beta/sources" binaryMirrors="mirror.krea.to/beta" [Other] ccache=false FLAGS extraArguments: Extra arguments for the configuration utility (configure, meson, cmake). Defaults to nothing. cxxflags: Sets the CXXFLAGS environment variable on build. Defaults to whatever set in kpkg.conf(5). cflags: Sets the CFLAGS environment variable on build. Defaults to whatever set in kpkg.conf(5). RUNFILE All runFile variables apply, see kpkg_run(8). Keep in mind that while you can override existing variables, you can’t create new variables that don’t exist on the runFile.

NAME kpkg - package manager SYNOPSIS kpkg [h] [b] [ins] [inf] [r] [upd] [upg] [PACKAGES] [-y] [-o] [-r] [ROOTFS] DESCRIPTION kpkg is a package manager written in Nim. kpkg uses simple build scripts called runfiles, similar to PKGBUILDs found in the pacman package manager. You can learn more about runfiles in kpkg_run(8). COMMANDS h Output help b build package ins install binary package inf get info about a package r remove package

NAME kreastrap.kg - declarative Kongue configuration for krep rootfs DESCRIPTION Rootfs configurations are declarative Kongue documents stored as share/krep/rootfs/arch/ARCH/configs/BUILD_TYPE.kg. The loader accepts only literal scalar and list fields: functions, commands, interpolation, mutation, qualifiers, duplicate fields, and unknown fields are rejected. Only .kg Kongue rootfs configurations are supported. EXAMPLE kongue Edit Run schema_version: "1" build_directory: "/out" package_mode: "binary" use_overlay: "true" arch: "x86_64" os: "linux" libc: "glibc" compiler: "gcc" coreutils: "gnu" init: "systemd" tls_library: "openssl" extra_packages: - "gmake" - "nim" schema_version: "1" build_directory: "/out" package_mode: "binary" use_overlay: "true" arch: "x86_64" os: "linux" libc: "glibc" compiler: "gcc" coreutils: "gnu" init: "systemd" tls_library: "openssl" extra_packages: - "gmake" - "nim" FIELDS schema_version: Schema version; currently 1. build_directory: Rootfs output directory. package_mode: binary to consume published archives or build to build. use_overlay: Whether to copy the selected rootfs overlay. arch: Canonical package architecture, such as x86_64 or aarch64. os: Target OS; currently linux. libc: glibc or musl. compiler: gcc, clang, or no. coreutils: busybox or gnu. GNU membership is defined by the repository group gnu-core, not by this configuration. init: busybox, jumpstart, openrc, runit, or systemd. Systemd profiles require GNU coreutils. tls_library: TLS implementation, normally openssl or libressl. package_roots: Optional explicit resolved package roots. extra_packages: Additional packages installed after core profile roots. STATE Provisioning writes rootfs-state.kg into the root. It records the canonical profile, fingerprint, target, package roots, phase, pending packages, and ready, deferred, provisioning, or failed status. The state is generated atomically; only status: "ready" with phase: "complete" is reusable.

NAME krep - maintain Kreato Linux repositories and build images SYNOPSIS krep check|update [options] krep clean|lint|fmt|convert [options] krep rootfs [options] krep iso **–rootfs=**directory-or-archive **–output=**directory [options] krep disk **–rootfs=**directory-or-archive **–output=**directory [options] krep generate matrix|markdown|manpage [options] DESCRIPTION krep contains the repository maintenance and image-building implementation in its own commands, modules, and data directories. Existing configuration and runfile formats are unchanged. krep replaces the removed chkupd, run3tools, kreastrap, and kreaiso standalone tools. It does not replace kpkg.