#+TITLE: Carbs Linux User Manual #+AUTHOR: Cem Keylan #+TEXINFO_FILENAME: carbslinux.info #+TEXINFO_DIR_CATEGORY: System Administration #+TEXINFO_DIR_TITLE: Carbs Linux: (carbslinux) #+TEXINFO_DIR_DESC: Carbs Linux User Manual #+OPTIONS: html-postamble:nil html-scripts:nil #+BEGIN_COMMENT This is the documentation source for Carbs Linux in Org-mode. The macros below are used for assigning IDs to contribution guidelines. #+END_COMMENT #+MACRO: contid [@@texinfo:@anchor{$1}@@$1] #+MACRO: sectid (eval (format "%s [%s]\n@@texinfo:@anchor{%s}@@\n" $2 $1 $1)) This is the full documentation of [[https://carbslinux.org][Carbs Linux]], from the details of the distribution, installation, to the package manager. It is not yet complete. #+BEGIN_EXPORT ascii You can build and install the 'info' package in order to view this documentation with the info reader. It is divided into sections and easier to read. #+END_EXPORT #+BEGIN_EXPORT texinfo @ifplaintext You can build and install the @command{info} package in order to view this documentation with the info reader. It is divided into sections and easier to read. @end ifplaintext @ifhtml This documentation is also available in the distribution by the @command{carbs-docs} package, which can be read by either running @code{info carbslinux} or reading @file{/usr/share/doc/carbslinux/carbslinux.txt} with your favorite pager. You can install either the @command{info} or @command{texinfo} for doing the first. @end ifhtml #+END_EXPORT * Table of Contents :toc_3_gh:noexport: - [[#copying][Copying]] - [[#installation][Installation]] - [[#preparing-environment][Preparing Environment]] - [[#download][Download]] - [[#signature-verification][Signature verification]] - [[#extracting-the-tarball][Extracting the tarball]] - [[#chroot][Chroot]] - [[#setting-up-repositories][Setting up repositories]] - [[#updating-packages][Updating packages]] - [[#installing-packages][Installing packages]] - [[#essential-software][Essential Software]] - [[#obtaining-the-documentation][Obtaining the documentation]] - [[#system-configuration][System Configuration]] - [[#configuring-hostname][Configuring hostname]] - [[#hosts-file][Hosts file]] - [[#creating-a-user][Creating a user]] - [[#kernel][Kernel]] - [[#obtaining-the-kernel-sources][Obtaining the kernel sources]] - [[#kernel-dependencies][Kernel dependencies]] - [[#building-the-kernel][Building the kernel]] - [[#making-your-system-bootable][Making your system bootable]] - [[#bootloader][Bootloader]] - [[#init-scripts][Init scripts]] - [[#fstab][Fstab]] - [[#post-installation][Post-installation]] - [[#irc][IRC]] - [[#kiss-repositories][KISS repositories]] - [[#software][Software]] - [[#init-system][Init System]] - [[#configuring-init][Configuring Init]] - [[#changing-init-program][Changing Init Program]] - [[#wayland][Wayland]] - [[#enabling-the-wayland-repository][Enabling the Wayland repository]] - [[#switching-from-xorg][Switching from Xorg]] - [[#installing-a-compositor][Installing a Compositor]] - [[#contribution-guidelines][Contribution Guidelines]] - [[#conventions][Conventions]] - [[#shell-conventions][Shell Conventions]] - [[#repository-conventions][Repository Conventions]] - [[#contributing-to-the-community-repository][Contributing to the Community repository]] - [[#sending-patches][Sending Patches]] - [[#git-patches][Git Patches]] - [[#fossil-patches][Fossil Patches]] - [[#gnu-free-documentation-license][GNU Free Documentation License]] * Copying :PROPERTIES: :COPYING: t :END: Copyright \copy 2020-{{{time(%Y)}}} Cem Keylan #+BEGIN_QUOTE Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License." #+END_QUOTE * Installation :PROPERTIES: :DESCRIPTION: Installing Carbs Linux :EXPORT_FILE_NAME: install.txt :EXPORT_TITLE: Carbs Linux Installation Guide :END: #+NAME: pubkey #+begin_src sh :exports none PUBKEY=carbslinux-2023.02.pub #+end_src These are the step-by-step instructions for installing Carbs Linux. It can be acquired as plain-text to be viewed offline with a pager from [[https://carbslinux.org/install.txt]]. #+begin_src sh curl -sL https://carbslinux.org/install.txt | less #+end_src #+TOC: headlines 3 local ** Preparing Environment :PROPERTIES: :DESCRIPTION: Getting ready to chroot :END: To install Carbs Linux, you will need a Live Linux ISO. For that purpose, you can obtain a Gentoo or Void Linux live image. You can follow their instructions to boot and setup your network. You will need the following programs in order to install Carbs Linux: - tar - wget - xz - some form of base utilities (coreutils, sbase, busybox, etc.) Rest of these instructions will assume that you have set all of these up, and will continue on that point. *** Download :PROPERTIES: :DESCRIPTION: Download the root filesystem tarball :END: First, we need to download the rootfs tarball. You can do the following in order to obtain the rootfs. If you are using an i686 machine, replace the =x86_64= with =i686=. We are setting this in a URL variable so that we don't have to write it every time. #+BEGIN_SRC sh URL=https://dl.carbslinux.org/releases/x86_64 wget $URL/carbs-rootfs.tar.xz.sha256 sha256sum -c carbs-rootfs.tar.xz.sha256 #+END_SRC *** Signature verification :PROPERTIES: :DESCRIPTION: Verify the signature of the rootfs tarball :END: It is highly recommended to verify the signature of the tarball. You will need the OpenBSD tool =signify(1)= for this. Many distributions provide a package for it, if you are using a Carbs Linux host, you can also install the package =otools= which provides =signify=. Download the signature first. #+BEGIN_SRC sh wget $URL/carbs-rootfs.tar.xz.sig #+END_SRC The signature file should say something similar to #+begin_src sh :exports results :results verbatim curl -L https://dl.carbslinux.org/releases/x86_64/carbs-rootfs.tar.xz.sig #+end_src #+RESULTS: : untrusted comment: verify with carbslinux-2023.02.pub : RWTe38zmx+iyuKEL5T84MJ5Y24jqenkTtQLJxbaMzOBS/NkGVl5J+Vn2B6vTV/gJK7LYBPS+IOXV5sEf+YLGCMcBYAGHCcP4xQ8= Grab the key (which probably should be the latest one) that is written on the file from [[https://dl.carbslinux.org/keys/]] so you can verify the signature. The latest Signify public key is also available on the [[https://git.carbslinux.org/repository][package repository]], so you can check the validity of the public key from multiple locations, or just copy paste that portion to a file and use that instead. #+begin_src sh :noweb yes <> wget https://dl.carbslinux.org/keys/$PUBKEY #+end_src You can now verify the distribution tarball with signify. #+begin_src sh signify -V -m carbs-rootfs.tar.xz -p $PUBKEY #+end_src If everything went alright, this should output: #+begin_example Signature Verified #+end_example *** Extracting the tarball :PROPERTIES: :DESCRIPTION: Extracting the root filesystem to the desired location :END: You will need to extract the tarball to your desired location. For partitioning, you can follow [[https://wiki.archlinux.org/index.php/Partitioning][this guide]]. This will assume that you will be mounting your root partition to =/mnt=. #+BEGIN_SRC sh mount /dev/sdx1 /mnt tar xf carbs-rootfs.tar.xz -C /mnt #+END_SRC ** Chroot :PROPERTIES: :DESCRIPTION: Going inside your new system :END: Chroot into Carbs Linux by running the chroot helper inside the rootfs! #+BEGIN_SRC sh /mnt/bin/cpt-chroot /mnt #+END_SRC *** Setting up repositories :PROPERTIES: :DESCRIPTION: Basic setup for obtaining repositories :END: Newest tarballs do not come with repositories, so you will need to manually obtain them, and set your =CPT_PATH= environment variable. Carbs Linux repositories can either be obtained by =git= or =rsync=. While rsync repositories are overall faster and smaller, git offers the whole history of the repository and a means to manipulate your repository as you like it. If you want to obtain the git repository, you will need to install =git= itself. The following guide will assume that you put the repositories into =~/repos/= directory, but you can put the repositories into any directory you want. So go ahead and create that directory: #+BEGIN_SRC sh mkdir -p $HOME/repos #+END_SRC **** Obtaining from git Carbs Linux git repositories can be found both from the main server and GitHub (mirror). Here are both their repository links. You can clone any of them. - https://git.carbslinux.org/repository - https://git.sr.ht/~carbslinux/repository #+BEGIN_SRC sh git clone git://git.carbslinux.org/repository $HOME/repos/carbs #+END_SRC **** Obtaining from rsync Carbs Linux rsync repositories live in rsync://carbslinux.org/repo. In order to obtain it, run the following: #+BEGIN_SRC sh rsync -avc rsync://vaylin.carbslinux.org/repo $HOME/repos/carbs #+END_SRC **** Making the package manager use the repositories In your shell's configuration file, or in your =~/.profile= file, add the following lines: #+BEGIN_SRC sh CPT_PATH=$HOME/repos/carbs/core CPT_PATH=$CPT_PATH:$HOME/repos/carbs/extra CPT_PATH=$CPT_PATH:$HOME/repos/carbs/wayland CPT_PATH=$CPT_PATH:$HOME/repos/carbs/community export CPT_PATH #+END_SRC *** Updating packages :PROPERTIES: :DESCRIPTION: Update your system :END: It is good practice to make sure your system is up to date, especially before building new packages. If there is an update for the package manager you will need to update twice. #+BEGIN_SRC sh cpt-update && cpt-update #+END_SRC *** Installing packages :PROPERTIES: :DESCRIPTION: Install new software on your system :END: Since you are operating on a really small base, you might need to build and install new programs to extend the functionality of your system. In order to build and install packages new packages in Carbs, you need to execute the following. "Package" is not actually a package and is given as an example. #+BEGIN_SRC sh cpt-build package cpt-install package #+END_SRC *** Essential Software :PROPERTIES: :DESCRIPTION: Software you might want to include on your system :END: Here is a small list of software that you might want to have on your system as you are setting up. You might want to check the *Software* section in the full documentation to learn more about other packaged software. *BOOTLOADERS* - efibootmgr - grub *FILESYSTEMS* - e2fsprogs - dosfstools - ntfs-3g *NETWORKING* - dhcpcd - wpa_supplicant *TEXT EDITORS* - nano - vim *DOCUMENTATION* - carbs-docs - man-pages - man-pages-posix *** Obtaining the documentation :PROPERTIES: :DESCRIPTION: Install documentation for offline use (optional) :END: All the documentation for Carbs Linux can be found on a single info manual to be viewed offline. You can obtain either =texinfo= or the =info= packages in order to view the documentation. #+BEGIN_SRC sh # Install the documentation. cpt b carbs-docs && cpt i carbs-docs # Install either texinfo or the info package. We will be installing standalone info # as it doesn't need perl. cpt b info && cpt i info # You can then run info and navigate through the documentation. info carbslinux #+END_SRC ** System Configuration :PROPERTIES: :DESCRIPTION: Customizing your system for personal use :END: After you have finished installing some extra packages, you can configure your system to your liking. *** Configuring hostname :PROPERTIES: :DESCRIPTION: Setting up system hostname (recommended) :END: You might want to add a hostname, especially in a networked environment. Your hostname will default to 'carbslinux' unless you set this. #+BEGIN_SRC sh echo your-hostname > /etc/hostname #+END_SRC *** Hosts file :PROPERTIES: :DESCRIPTION: Setting up hosts file for networking (optional) :END: You can edit your /etc/hosts file, which is the static lookup table for host names. By default, there are two entries for localhost which are OKAY. You can replace the 'localhost' part of these entries to your hostname. #+BEGIN_EXAMPLE 127.0.0.1 localhost.localdomain localhost ::1 localhost.localdomain localhost ip6-localhost #+END_EXAMPLE *** Creating a user :PROPERTIES: :DESCRIPTION: Adding a user to your new system :END: Creating a new user is not strictly necessary, but it is highly recommended. Especially for building packages, it is the safest option to create an unprivileged user and using =doas= for doing operations that require =root= privileges. The code block below describes how to create a user (named =foo=), add them to the wheel group, and to give doas permissions to the wheel group #+BEGIN_SRC sh # Create the new user adduser foo # Add the user to the wheel group addgroup foo wheel # Give root permission to the wheel group using doas echo permit persist :wheel >> /etc/doas.conf #+END_SRC You are also advised to take a look at the doas configuration file and the manual page of doas. After you are finished you can switch to the new user by running #+begin_src sh su foo #+end_src ** Kernel :PROPERTIES: :DESCRIPTION: Compiling your own kernel :END: Kernel isn't managed under the main repositories, even though you could package one for your personal use. Here is an [[https://github.com/cemkeylan/kiss-repository/tree/master/personal/linux][example kernel package]], which you will need to reconfigure for your specific setup if you want to make use of it. *** Obtaining the kernel sources :PROPERTIES: :DESCRIPTION: Downloading the Linux source code :END: You can visit the [[https://kernel.org]] website to choose a kernel that you want to install. Though only the latest stable and longterm (LTS) versions are supported. Note that kernel releases are quite rapid, and the version below is likely outdated, so don't run it verbatim. #+BEGIN_SRC sh # Download the kernel and extract it wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.19.4.tar.xz tar xJf linux-5.19.4.tar.xz # Change directory into the kernel sources cd linux-5.19.4 #+END_SRC *NOTE:* If you want to validate the kernel signature, install the =gnupg2= package, and follow the instructions provided at [[https://kernel.org/category/signatures.html]]. *** Kernel dependencies :PROPERTIES: :DESCRIPTION: Requirements for building the kernel :END: In order to compile the kernel you will need to install some dependencies. You will need =libelf=, and =bison= to compile the kernel. If you want to configure using the menu interface you will also need =ncurses=. #+BEGIN_SRC sh # The package manager asks to install if you are building more than one package, # so no need to run 'cpt i ...' cpt b libelf ncurses #+END_SRC In the vanilla kernel sources, you need perl to compile the kernel, but it can be easily patched out. You will need to apply the following patch. Patch was written by [[https://github.com/E5ten][E5ten]]. You will need to obtain and apply the patch in the kernel source directory. #+BEGIN_SRC sh wget https://dl.carbslinux.org/distfiles/kernel-no-perl.patch patch -p1 < kernel-no-perl.patch #+END_SRC *** Building the kernel :PROPERTIES: :DESCRIPTION: Configure and compile the kernel :END: Next step is configuring and building the kernel. You can check Gentoo's [[https://wiki.gentoo.org/wiki/Kernel/Configuration][kernel configuration guide]] to learn more about the matter. Overall, Gentoo Wiki is a good place to learn about configuration according to your hardware. The following will assume a monolithic kernel. #+BEGIN_SRC sh make menuconfig make install -Dm755 $(make -s image_name) /boot/vmlinuz-linux #+END_SRC ** Making your system bootable :PROPERTIES: :DESCRIPTION: Installing bootloader and boot scripts :END: In order to be able to boot your fresh system, wou will need an init-daemon, init-scripts and a bootloader. The init daemon is already provided by busybox, but you can optionally change it. *** Bootloader :PROPERTIES: :DESCRIPTION: Install a bootloader for your system :END: In the main repository, there is efibootmgr and grub to serve as bootloaders. efibootmgr can be used as a standalone bootloader, or can be used to install grub in a UEFI environment. efibootmgr is needed unless you are using a device without UEFI support (or you really want to use BIOS for a reason). **** GRUB BIOS installation #+BEGIN_SRC sh cpt b grub && cpt i grub grub-install --target=i386-pc /dev/sdX grub-mkconfig -o /boot/grub/grub.cfg #+END_SRC **** GRUB UEFI installation #+BEGIN_SRC sh cpt b efibootmgr && cpt i efibootmgr cpt b grub && cpt i grub grub-install --target=x86_64-efi \ --efi-directory=esp \ --bootloader-id=CarbsLinux grub-mkconfig -o /boot/grub/grub.cfg #+END_SRC *** Init scripts :PROPERTIES: :DESCRIPTION: Install init scripts for your system :END: Only thing left to do is installing the init-scripts, and now you are almost ready to boot your system! #+BEGIN_SRC sh cpt b carbs-init && cpt i carbs-init #+END_SRC *** Fstab :PROPERTIES: :DESCRIPTION: Generating fstab :END: You can now manually edit your fstab entry, or you can use the genfstab tool. If you want to use the tool, exit the chroot and run the following: #+BEGIN_SRC sh wget https://github.com/cemkeylan/genfstab/raw/master/genfstab chmod +x genfstab ./genfstab -U /mnt >> /mnt/etc/fstab #+END_SRC ** Post-installation :PROPERTIES: :DESCRIPTION: Post-installation tasks :END: The base installation is now complete, you can now fine tune your system according to your needs. Rest of these instructions are completely optional. You can check the rest of the documentation to learn more about the system. *** IRC :PROPERTIES: :DESCRIPTION: Joining the IRC channel :END: The IRC channel for Carbs Linux is located in =#carbslinux= on [[https://libera.chat][libera.chat]]. You can install the =catgirl= package from the repository, or use a client of your preference to join. Feel free to ask for help, or have a general chat. *** KISS repositories :PROPERTIES: :DESCRIPTION: Acquire kiss repositories :END: There have been recent changes to the =kiss= package manager that breaks compatibility with =cpt=. These changes throw away the entire premise of their "static" packaging system. =cpt= will never implement those changes, so don't expect any KISS package that was changed during or after July 2021 to work with =cpt=. * Software :PROPERTIES: :DESCRIPTION: Details on configuring your system's software :END: The distribution aims to package essential and useful software needed in a practical system. If the repository lacks a package that you use, you may also easily package it yourself or request it to be added to the default repositories over on the IRC channel (=#carbslinux= on [[https://libera.chat][Libera]]). This section goes over the details of some packaged software ** Init System :PROPERTIES: :DESCRIPTION: Configure the init system :END: Carbs Linux init scripts are run by the init daemon (=busybox= by default) on boot and shutdown processes. It also provides its own halting program named shalt. This provides a portable method that doesn't rely on non-POSIX external programs. *** Configuring Init :PROPERTIES: :DESCRIPTION: Ways to configure the init system :END: There are three ways you can change the behaviour of the init system. Those are: - Kernel Command Line - =/etc/init/rc.conf= file - Init Hooks **** Kernel Command Line :PROPERTIES: :DESCRIPTION: Configure init through the boot parameters :END: On GRUB, you can edit the kernel command line parameters, which will be parsed as variables on the init system. Not all of the parameters will be acted upon, but all of them will be set as variables on the init script. For example an example command line, and how it is interpreted. #+BEGIN_EXAMPLE BOOT_IMAGE=/boot/vmlinuz root=/dev/sda2 rw loglevel=3 quiet #+END_EXAMPLE This command line will be parsed to set the following variables: #+BEGIN_EXAMPLE BOOT_IMAGE=/boot/vmlinuz root=/dev/sda2 rw=1 loglevel=3 quiet=1 #+END_EXAMPLE Some of these variables, such as =rw=/=ro=, =loglevel=, and =quiet=, will be used by the init system to change the behaviour of the startup. **** =/etc/init/rc.conf= file :PROPERTIES: :DESCRIPTION: Configure init through the configuration file :END: However, the kernel command line isn't the only place to set your boot parameters. You can specify variables here as well, although note that the kernel command line always gets the priority for these variables since they can be set just before boot. **** Init Hooks :PROPERTIES: :DESCRIPTION: Configure init through hooks :END: Init hooks are for custom personal commands that the user may want to add to alter their boot. These can be used to load kernel modules, modify interfaces, and lot more. Those hooks are added to the =/etc/init= directory with the hook name as the suffix. For example, a boot script will be placed as =/etc/init/my-hook.boot=. Currently, there are 4 hooks that the user can use. - early-boot :: Run after pseudo-filesystems are mounted. - boot :: Run before the boot stage is completed. - pre.shutdown :: Run first when shutting down. - umount :: Run just before filesystems are unmounted. - post.shutdown :: Run just before the system is halted. *** Changing Init Program :PROPERTIES: :DESCRIPTION: Replace the default busybox init with something new :END: By default, Carbs Linux comes preinstalled with =busybox-init=, but this can easily be replaced without any issues. Currently, available init systems are: - =sinit= - =busybox= init - =runit= - =shinit= This example is for runit, but it will work with all init systems packaged in the distribution repositories. See the =cpt-alternatives(1)= manual page for more details. #+BEGIN_SRC sh cpt a runit /usr/bin/init cpt a runit /usr/bin/poweroff cpt a runit /usr/bin/reboot #+END_SRC **** Rebooting after changing init :PROPERTIES: :DESCRIPTION: Ways to reboot after replacing the init system :END: After switching init systems, your running init system may not accept the new poweroff commands. You will need to reboot/poweroff using the running init's utilities for the new utilities to work. These commands are for the init system currently running on your system and not the one you are switching to. | Program | Command | |--------------+------------------| | busybox | =busybox reboot= | | runit | =runit-init 6= | | shinit/sinit | =kill -s INT 1= | ** Wayland :PROPERTIES: :DESCRIPTION: Maintaining a Wayland display system :END: Carbs Linux only supports Wayland displays as of January 2023. If your system makes use of the X.org display system, read the section [[*Switching from Xorg][Switching from Xorg]]. Wayland is a modern display server protocol intended as a replacement for Xorg. Wayland has a much simpler architecture compared to X by its careful design and implementation. Users who want to use a Wayland compositor should follow this section. *** Enabling the Wayland repository :PROPERTIES: :DESCRIPTION: Including the wayland repository in your repository path :END: The =wayland= repository requires packages from =xorg= and =extra= repositories. So you should set your =$CPT_PATH= so that =core= and =extra= repositories precede the =wayland= repository, and the =xorg= repository should come after =wayland=. Here is an example below, where =$REPOSITORY= points to the root of your repository. #+begin_src sh CPT_PATH=$REPOSITORY/core CPT_PATH=$CPT_PATH:$REPOSITORY/extra CPT_PATH=$CPT_PATH:$REPOSITORY/wayland export CPT_PATH #+end_src After you have enabled your repositories, go ahead and install =wayland= and =wayland-protocols= packages. #+begin_src sh cpt-build wayland wayland-protocols #+end_src *** Switching from Xorg :PROPERTIES: :DESCRIPTION: Rebuilding system packages for wayland :END: If you are already an Xorg user, you will need to rebuild some packages so that they support =wayland=. If you don't have an =xorg= system, feel free to skip this step. The packages that need a rebuild are: - =gtk+3= - =gtk4= - =mesa= - =webkit2gtk= For xorg support inside wayland sessions, you need to install the =xwayland= package. *** Installing a Compositor :PROPERTIES: :DESCRIPTION: Getting wayland ready for your system :END: The =wayland= repository currently only contains =sway= as a Wayland compositor, but you can package something else for your own. #+begin_src sh cpt bi sway #+end_src * Contribution Guidelines :PROPERTIES: :DESCRIPTION: Contribute to Carbs Linux :END: Thanks for taking your time to contribute! To maintain stylistic behaviour throughout the repositories, one must adhere to these conventions. Exceptions and changes may occur with good reasoning. ** Conventions :PROPERTIES: :DESCRIPTION: Conventions of the distribution :END: #+TEXINFO: @macro contid{id} #+TEXINFO: [@anchor{\id\}\id\] #+TEXINFO: @end macro #+TEXINFO: @macro sectid{id, sect} #+TEXINFO: @strong{@contid{\id\} \sect\} #+TEXINFO: @end macro - {{{contid(0010)}}} :: Try to keep the file readable. - {{{contid(0011)}}} :: Characters on a line shouldn't exceed 100 characters. - {{{contid(0012)}}} :: Make sure you don't have code commented out during commit. Uncomment them or remove them completely. - {{{contid(0013)}}} :: Do not add comments following the code, add them to the top of the code. It makes it harder to read, and lines longer. Here is an example: #+BEGIN_EXAMPLE # Good way of commenting. your code goes here your code goes here # Avoid this way of commenting. #+END_EXAMPLE *** Shell Conventions :PROPERTIES: :DESCRIPTION: Conventions for shell scripts :END: Shell is central to Carbs Linux projects. Most of the tools and packages are written in POSIX sh. - {{{contid(1010)}}} :: Use 4 spaces for indentation, don't use tabs. - {{{contid(1020)}}} :: Make sure you don't use bash-specific code. - {{{contid(1030)}}} :: Make sure you lint your code with =shellcheck= and if you are new to POSIX sh, use =checkbashisms=. - {{{contid(1040)}}} :: Don't spawn new processes if you don't absolutely need to, especially during string manipulation. - {{{contid(1041)}}} :: Never use a program for text manupilation that isn't defined in the POSIX standard. This includes =gawk= and =perl=. - {{{contid(1042)}}} :: Instead of ~$(basename $file)~, use ~${file##*}~. - {{{contid(1043)}}} :: Instead of ~$(dirname $file)~, use ~${file%/*}~. #+BEGIN_EXAMPLE # This is the same thing as basename /path/to/test.asc .asc $ file=/path/to/test.asc file=${file##*/} file=${file%.asc} $ echo $file test #+END_EXAMPLE - {{{contid(1050)}}} :: Instead of backticks, use ~$(..)~. *** Repository Conventions :PROPERTIES: :DESCRIPTION: Conventions for repository build scripts :END: Repository conventions are important in order to ensure every package resemble themselves. Here are the things to keep in mind: - {{{contid(2010)}}} :: Prefer tarballs over git packages unless there is a sensible reason. Here are some: - Every patch is a new release. (See [[https://github.com/vim/vim][vim]]) - There are no releases. (See [[https://git.suckless.org/sbase][sbase]]) - Following a development branch. - There has been a long time since the latest release, but upstream is far ahead. - {{{contid(2020)}}} :: Prefer sources without a dependency to =automake=. There are usually distribution tarballs that are =autoconf='ed. Don't submit tarballs with an automake dependency unless you are =sure= there is no alternative. - {{{contid(2030)}}} :: Avoid these packages: - dbus :: Usually can be disabled by ~--disable-dbus~. - gettext :: Usually can be disabled by ~--disable-nls~. - {{{contid(2040)}}} :: - Always install a package to the =/usr= prefix. - All binaries should go to =/usr/bin=, not =/usr/sbin= or any other directory. - All libraries should go to =/usr/lib=. - {{{contid(2050)}}} :: All build files on the repository should be a POSIX shell script, and must start with ~#!/bin/sh -e~. The next section is about package templates that should be used in order to ensure stylistic consistency. Note that the option configurations shouldn't be taken literally, they are meant as examples. **** {{{sectid(2210, Make)}}} #+BEGIN_SRC sh #!/bin/sh -e make make DESTDIR="$1" PREFIX=/usr install #+END_SRC **** {{{sectid(2211, Configure/Make)}}} #+BEGIN_SRC sh #!/bin/sh -e ./configure \ --prefix=/usr \ --disable-option \ --enable-option make make DESTDIR="$1" install #+END_SRC **** {{{sectid(2212, Autoconf/Automake)}}} #+TEXINFO: @xref{2020} #+BEGIN_SRC sh #!/bin/sh -e autoreconf -fi ./configure \ --prefix=/usr \ --disable-option \ --enable-option make make DESTDIR="$1" install #+END_SRC **** {{{sectid(2220, Meson)}}} The distribution provides a =cl-meson= wrapper script which sets some common options like installation directories, disables downloading subprojects among other things. This is the preferred method for packages. #+BEGIN_SRC sh #!/bin/sh -e export DESTDIR=$1 cl-meson \ -Doption=false \ -Doption2=true \ . output ninja -C output ninja -C output install #+END_SRC **** {{{sectid(2230, Cmake)}}} #+BEGIN_SRC sh #!/bin/sh -e export DESTDIR=$1 cmake -B build \ -DCMAKE_INSTALL_PREFIX=/usr \ -DCMAKE_BUILD_TYPE=Release \ -DOPTION=ON cmake --build build cmake --install build #+END_SRC **** {{{sectid(2240, Go)}}} #+BEGIN_SRC sh #!/bin/sh -e export GOPATH=$PWD/gopath trap "go clean -modcache" EXIT INT go mod vendor go build install -Dm755 program "$1/usr/bin/program" #+END_SRC **** {{{sectid(2241, Python)}}} #+BEGIN_SRC sh #!/bin/sh -e python setup.py build python setup.py install --prefix=/usr --root="$1" #+END_SRC ** Contributing to the Community repository :PROPERTIES: :DESCRIPTION: Package maintainership and issue reports :END: The community repository is available for any user to submit packages. However, there are certain guidelines that the users are expected to follow before they submit packages. - {{{contid(3000)}}} :: Any submitted package should contain a =meta= file that includes a short description of the package, the maintainer's name and email address, and the license of the package. Below is an example: #+begin_example description: some IRC client with some interesting feature license: MIT maintainer: Your Name #+end_example The order of these are not important. However, make sure to use the license identifiers as defined by [[https://spdx.org/licenses/][SPDX]] when listing the license. - {{{contid(3010)}}} :: The user submitting the package is expected to maintain their packages. This means that they are keeping the packages up-to-date, and responding to issues related to the package. - {{{contid(3020)}}} :: If a maintainer doesn't follow the above expectation for a duration of up to a month, their packages will be orphaned and can be adopted by a new maintainer. Maintainers can also request that their packages be orphaned. If the orphaned packages aren't adopted by a new maintainer in a period of two weeks, these packages will be dropped from the repository. - {{{contid(3030)}}} :: Package submissions and updates should be submitted in the form of patches to the [[https://lists.sr.ht/~carbslinux/carbslinux-devel][~carbslinux/carbslinux-devel]] mailing list. The repository on Github is a read-only mirror, and Pull Requests will *NOT* be accepted. - {{{contid(3031)}}} :: Issues regarding community packages should be submitted to the [[https://lists.sr.ht/~carbslinux/carbslinux-discuss][~carbslinux/carbslinux-discuss]] mailing list. When submitting issues, do not forget to add the maintainer as a recipient. You can easily find the maintainer information by running ~cpt-maintainer ~. ** Sending Patches :PROPERTIES: :DESCRIPTION: Code contribution :END: *** Git Patches There are multiple ways of sending patches with git. Unfortunately, the most popular / official way of doing it requires Perl and some extra Perl libraries that are not packaged in the repository. This section tries to list other options that are just as useful as =git send-email=. **** =git-send-email= with msmtp By default, =git-send-email= uses a Perl SMTP client, but without using it this command doesn't actually need extra Perl libraries, only Perl itself. So, if you are okay with using Perl, the easiest option is to install the =msmtp= package, and change your git configuration to match your msmtp settings. To your =~/.gitconfig=, add the following section: #+begin_example [sendemail] smtpserver = /usr/bin/msmtp smtpserveroption = -a smtpserveroption = your-account-name #+end_example **** =git-imap-send= The =git imap-send= command reads patches in mbox format, and uploads it to your imap server as drafts. You can then use your preferred email-client to edit and send them. This is the option with no dependencies. Check out the manual page =git-imap-send(1)= for more information on setting up. *** Fossil Patches You can create multiple types of "patches" with Fossil. Unlike the common convention in Git, the first two examples here uses uncommitted changes to create a patch (although you could very well create patches of committed changes). The preferred method is by creating a plaintext patch by doing the following: #+begin_src sh fossil diff -i > your-changes.patch #+end_src You can also create a binary patch: #+begin_src sh fossil patch create your-changes.db #+end_src If your patchset is complex, and needs to be splitted in multiple check-ins, you can create a Fossil bundle: #+begin_src sh fossil bundle create --from CHECKIN --to CHECKIN2 patchset.bundle #+end_src After creating the patches, you can simply send them to the mailing list, or upload the patches to the Fossil forum of the relevant repository. * GNU Free Documentation License :PROPERTIES: :APPENDIX: t :DESCRIPTION: Your rights :END: #+INCLUDE: fdl.org