Arch Linux User Repository

This package have several variables to enable/disable features.

##
## The following variables can be customized at build time. Use env or export to change at your wish
##
##   Example: env _microarchitecture=98 use_numa=n use_tracers=n makepkg -sc
##
## Look inside 'choose-gcc-optimization.sh' to choose your microarchitecture
## Valid numbers between: 0 to 99
## Default is: 0 => generic
## Good option if your package is for one machine: 98 (Intel native) or 99 (AMD native)
if [ -z ${_microarchitecture+x} ]; then
  _microarchitecture=0
fi

## Disable NUMA since most users do not have multiple processors. Breaks CUDA/NvEnc.
## Archlinux and Xanmod enable it by default.
## Set variable "use_numa" to: n to disable (possibly increase performance)
##                             y to enable  (stock default)
if [ -z ${use_numa+x} ]; then
  use_numa=y
fi

## Since upstream disabled CONFIG_STACK_TRACER (limits debugging and analyzing of the kernel)
## you can enable them setting this option. Caution, because they have an impact in performance.
## Stock Archlinux has this enabled. 
## Set variable "use_tracers" to: n to disable (possibly increase performance, XanMod default)
##                                y to enable  (Archlinux default)
if [ -z ${use_tracers+x} ]; then
  use_tracers=n
fi

# Unique compiler supported upstream is GCC
## Choose between GCC and CLANG config (default is GCC)
## Use the environment variable "_compiler=clang"
if [ "${_compiler}" = "clang" ]; then
  _compiler_flags="CC=clang HOSTCC=clang LLVM=1 LLVM_IAS=1"
fi

# Choose between the 4 main configs for stable branch. Default x86-64-v1 which use CONFIG_GENERIC_CPU2:
# Possible values: config_x86-64-v1 (default) / config_x86-64-v2 / config_x86-64-v3 / config_x86-64-v4
# This will be overwritten by selecting any option in microarchitecture script
# Source files: https://github.com/xanmod/linux/tree/5.17/CONFIGS/xanmod/gcc
if [ -z ${_config+x} ]; then
  _config=config_x86-64-v1
fi

# Compress modules with ZSTD (to save disk space)
if [ -z ${_compress_modules+x} ]; then
  _compress_modules=n
fi

# Compile ONLY used modules to VASTLY reduce the number of modules built
# and the build time.
#
# To keep track of which modules are needed for your specific system/hardware,
# give module_db script a try: https://aur.archlinux.org/packages/modprobed-db
# This PKGBUILD read the database kept if it exists
#
# More at this wiki page ---> https://wiki.archlinux.org/index.php/Modprobed-db
if [ -z ${_localmodcfg} ]; then
  _localmodcfg=n
fi

# Tweak kernel options prior to a build via nconfig
if [ -z ${_makenconfig} ]; then
  _makenconfig=n
fi

Personally I'm running now xanmod kernel compiled with this:

env _microarchitecture=98 use_tracers=n use_numa=n _localmodcfg=y _compress_modules=y makepkg -sic

Also, you can now create the file myconfig in your local repo to build this package with a custom config or use ${XDG_CONFIG_HOME}/linux-xanmod/myconfig. This file can be a full kernel config or be a script with several entries to add/remove options (you have several examples in PKGBUILD by using scripts/config):

Code involved:

  for _myconfig in "${SRCDEST}/myconfig" "${HOME}/.config/linux-xanmod/myconfig" "${XDG_CONFIG_HOME}/linux-xanmod/myconfig" ; do
    if [ -f "${_myconfig}" ] && [ "$(wc -l <"${_myconfig}")" -gt "0" ]; then
      if grep -q 'scripts/config' "${_myconfig}"; then
        # myconfig is a partial file. Executing as a script
        msg2 "Applying myconfig..."
        bash -x "${_myconfig}"
      else
        # myconfig is a full config file. Replacing default .config
        msg2 "Using user CUSTOM config..."
        cp -f "${_myconfig}" .config
      fi
      echo
      break
    fi
  done

Running makepkg -s with the original PKGBUILD and then running the command that I've wrote beforehand in the linux-xanmod directory should fix the bug.

There seems to be an error in the PKGBUILD file. The patch can't be added to the original linux kernel because the patch has not been decompressed. So here's the things you might want to do to fix this.

xz --decompress patch-5.11.11-xanmod1.xz && ln -s patch-5.11.11-xanmod1 src

This should fix the current bug.

Note: This might be fixed in future versions

I have fixed it by manually extracting the patch .xz file, did i make a mistake earlier on?

it seems to fail patching "patch: **** Can't open patch file ../patch-5.11.11-xanmod1 : No such file or directory ==> ERROR: A failure occurred in prepare(). Aborting... "

i think it has to do with like 100 of the pkgbuild, but im not sure

@dmshimself Just to check, have you specified to makepkg to use multiple threads. E.g. have you added to your makeflags in /etc/makepkg.conf "-j9", if you say have 8 threads

@dmshimself then if you use modprobed-db, you can use -C or -c (this deletes src/ and pkg/ after a compilation success, which is another good practice IMHO). Cheers.

thanks @figue - I'm already using

env _microarchitecture=30 use_numa=n use_tracers=n use_ns=y _localmodcfg=y makepkg -sri

and the use of modprobe.db certainly did reduce my build times when I first started using it a while ago. I'll try out the .git version sometime.

In the meantime, it looks to me as though anyone using this kernel should be encouraged to use the -C option with their makepkg

Thanks everyone; the advice was appreciated

@dmshimself yes, the problem is in this point because it merges all *.patch that you have in src/. So if you really don't want to build from scratch you should remove all patch files from src manually. makepkg will copy all of them again (only the necessary).

But if time compilation is really important for you, I recommend using modprobed.db and compile only the modules you need according to your system.

Another option is to use linux-xanmod-git package. That package uses the latest git master branch, but I usually don't merge any patch.

@figue - yes the -C option is the one I'm trying to avoid using as a complete build from scratch takes a long time on my slow machine. I have lots of other AUR packages installed and when they are updated, none (that I use!) need a -C.

Is there something special about building this package that 'requires' this? Other suggested makepkg flags in the comments for this AUR package don't make a comment on -C as being required, but suggest the 'usual' -sri and similar flags.

@dmshimself as good practice, when a new release is up, use -C flag in makepkg to erase src folder.