From 7979d77fa8aca002282ad1e4c03e1244aa5d1dd1 Mon Sep 17 00:00:00 2001
From: EuAndreh <eu@euandre.org>
Date: Sun, 30 Mar 2025 17:34:46 -0300
Subject: src/content/blog/: Upgrade 4 files to asciidoc

---
 src/content/blog/2020/08/10/guix-srht.adoc | 87 +++++++++++++++---------------
 1 file changed, 43 insertions(+), 44 deletions(-)

(limited to 'src/content/blog/2020/08/10/guix-srht.adoc')

diff --git a/src/content/blog/2020/08/10/guix-srht.adoc b/src/content/blog/2020/08/10/guix-srht.adoc
index 4d7e8d5..b450da2 100644
--- a/src/content/blog/2020/08/10/guix-srht.adoc
+++ b/src/content/blog/2020/08/10/guix-srht.adoc
@@ -1,30 +1,24 @@
----
-title: Guix inside sourcehut builds.sr.ht CI
-date: 2020-08-10
-updated_at: 2020-08-19
-layout: post
-lang: en
-ref: guix-inside-sourcehut-builds-sr-ht-ci
----
-After the release of the [NixOS images in builds.sr.ht][0] and much
-usage of it, I also started looking at [Guix][1] and
-wondered if I could get it on the awesome builds.sr.ht service.
-
-[0]: https://man.sr.ht/builds.sr.ht/compatibility.md#nixos
-[1]: https://guix.gnu.org/
-
-The Guix manual section on the [binary installation][2] is very thorough, and
-even a [shell installer script][3] is provided, but it is built towards someone
-installing Guix on their personal computer, and relies heavily on interactive
-input.
-
-[2]: https://guix.gnu.org/manual/en/guix.html#Binary-Installation
-[3]: https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
+= Guix inside sourcehut builds.sr.ht CI
+
+:nixos: https://man.sr.ht/builds.sr.ht/compatibility.md#nixos
+:guix: https://guix.gnu.org/
+:binary-inst: https://guix.gnu.org/manual/en/guix.html#Binary-Installation
+:shell-inst: https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
+
+After the release of the {nixos}[NixOS images in builds.sr.ht] and much usage of
+it, I also started looking at {guix}[Guix] and wondered if I could get it on the
+awesome builds.sr.ht service.
+
+The Guix manual section on the {binary-inst}[binary installation] is very
+thorough, and even a {shell-inst}[shell installer script] is provided, but it is
+built towards someone installing Guix on their personal computer, and relies
+heavily on interactive input.
 
 I developed the following set of scripts that I have been using for some time to
-run Guix tasks inside builds.sr.ht jobs. First, `install-guix.sh`:
+run Guix tasks inside builds.sr.ht jobs.  First, `install-guix.sh`:
 
-```shell
+[source,shell]
+----
 #!/usr/bin/env bash
 set -x
 set -Eeuo pipefail
@@ -62,15 +56,18 @@ ln -s /var/guix/profiles/per-user/root/current-guix/bin/guix .
 ln -s /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon .
 
 guix archive --authorize < ~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub
-```
+----
 
-Almost all of it is taken directly from the [binary installation][2] section
-from the manual, with the interactive bits stripped out: after downloading and
-extracting the Guix tarball, we create some symlinks, add guixbuild users and
-authorize the `ci.guix.gnu.org.pub` signing key.
+Almost all of it is taken directly from the {binary-inst}[binary installation]
+section from the manual, with the interactive bits stripped out: after
+downloading and extracting the Guix tarball, we create some symlinks, add
+guixbuild users and authorize the `ci.guix.gnu.org.pub` signing key.
 
-After installing Guix, we perform a `guix pull` to update Guix inside `start-guix.sh`:
-```shell
+After installing Guix, we perform a `guix pull` to update Guix inside
+`start-guix.sh`:
+
+[source,shell]
+----
 #!/usr/bin/env bash
 set -x
 set -Eeuo pipefail
@@ -79,12 +76,13 @@ sudo guix-daemon --build-users-group=guixbuild &
 guix pull
 guix package -u
 guix --version
-```
+----
 
 Then we can put it all together in a sample `.build.yml` configuration file I'm
 using myself:
 
-```yaml
+[source,yaml]
+----
 image: debian/stable
 packages:
   - wget
@@ -103,26 +101,27 @@ tasks:
   - docs: |
       cd ./songbooks/
       guix environment -m build-aux/guix.scm -- make publish-dist
-```
+----
 
 We have to add the `guix-daemon` to `~/.buildenv` so it can be started on every
-following task run. Also, since we used `wget` inside `install-guix.sh`, we had
+following task run.  Also, since we used `wget` inside `install-guix.sh`, we had
 to add it to the images package list.
 
 After the `install-guix` task, you can use Guix to build and test your project,
 or run any `guix environment --ad-hoc my-package -- my script` :)
 
-## Improvements
+== Improvements
+
+:repository: https://git.sr.ht/~sircmpwn/builds.sr.ht
 
 When I originally created this code I had a reason why to have both a `sudo`
 call for `sudo ./scripts/install-guix.sh` and `sudo` usages inside
-`install-guix.sh` itself. I couldn't figure out why (it feels like my past self
-was a bit smarter 😬), but it feels ugly now. If it is truly required I could
-add an explanation for it, or remove this entirely in favor of a more elegant solution.
+`install-guix.sh` itself.  I couldn't figure out why (it feels like my past self
+was a bit smarter 😬), but it feels ugly now.  If it is truly required I could
+add an explanation for it, or remove this entirely in favor of a more elegant
+solution.
 
 I could also contribute the Guix image upstream to builds.sr.ht, but there
-wasn't any build or smoke tests in the original [repository][4], so I wasn't
-inclined to make something that just "works on my machine" or add a maintainence
-burden to the author. I didn't look at it again recently, though.
-
-[4]: https://git.sr.ht/~sircmpwn/builds.sr.ht
+wasn't any build or smoke tests in the original {repository}[repository], so I
+wasn't inclined to make something that just ``works on my machine'' or add a
+maintainence burden to the author.  I didn't look at it again recently, though.
-- 
cgit v1.2.3

