Name the repo key properly

build/etc/abuild.conf

@@ -23,7 +23,7 @@ REPODEST=/srv/build/alpine/v3.11
 # the APKBUILD's "Contributor:" and "Maintainer:" comments, respectively.
 #PACKAGER="Your Name <your@email.address>"
 #MAINTAINER="$PACKAGER"
-PACKAGER_PRIVKEY="/root/repokey.rsa"
+PACKAGER_PRIVKEY="/root/repo.spotter.cz.rsa"
 
 # what to clean up after a successful build
 CLEANUP="srcdir bldroot pkgdir deps"

build/install-toolchain.sh

@@ -30,7 +30,7 @@ service nginx reload
 sed -i 's/repo\.spotter\.cz/repo.build.vm/' /etc/spoc/spoc.conf
 
 # Supply abuild key
-# echo '/root/repokey.rsa' | abuild-keygen
+# echo '/root/repo.spotter.cz.rsa' | abuild-keygen
 
 # Supply SPOC key
 # openssl ecparam -genkey -name secp384r1 -out /etc/spoc/publish.key

doc/toolchain/abuild.md

@@ -13,7 +13,7 @@ The usage of Abuild, APK package manager and syntax of `APKBUILD` files is best
 
 ## Abuild in a nutshell
 
-Building with abuild requires `alpine-sdk` package installed, `/etc/abuild.conf` configured and an RSA private key created in `/srv/build/repokey.rsa` and subsequently registered by `abuild-keygen` command. All these are taken care of in `install-toolchain.sh` script as part of [Build environment installation](vm-creation).
+Building with abuild requires `alpine-sdk` package installed, `/etc/abuild.conf` configured and an RSA private key created in `/srv/repo.spotter.cz.rsa` and subsequently registered by `abuild-keygen` command. All these are taken care of in `install-toolchain.sh` script as part of [Build environment installation](vm-creation).
 
 Abuild toolchain is intended to be used in automated builds, therefore it requires some dependencies normally not found in other packaging systems. Abuild expects that `APKBUILD` files are a part of git repository and tries to read current commit hash. Then it tries to automatically download, build (compile), strip binaries, find out dependencies, and generally perform a lot of tasks normally useful when you are compiling from sources. Finally it packages the result to one or more subpackages, according to the build recipe. For purposes of LXC packaging, this is mostly useless, which is the reason why we have a [custom package manager](pkgmgr). It is however perfectly suitable for packages installed directly on the basic VM.