Re: Building a Docker image for GitLab-CI

Re: Building a Docker image for GitLab-CI

[Suhail]

Ludovic Courtès <ludovic.courtes@inria.fr> writes:

> Initially, I built an image with ‘guix system image -t docker …’ but
> that doesn’t work because then the image’s “entry point” is shepherd,
> but shepherd never returns.

Did you try resetting the entrypoint in .gitlab-ci.yml using the
image:entrypoint keyword? [1]

[1]: <https://docs.gitlab.com/ee/ci/yaml/#imageentrypoint>

-- 
Suhail

This email is not an offer capable of acceptance, does not evidence an
intention to enter into an agreement, has no operative effect until a
definitive agreement is signed in writing by both parties, and that no
party should act in reliance on the email or any representations of the
sender until a definitive agreement is signed in writing by both
parties.

Re: Building a Docker image for GitLab-CI

[Cayetano Santos]

[-- Attachment #1: Type: text/plain, Size: 439 bytes --]


I just setup a toy project, here:

    https://gitlab.com/csantosb/gitlabci

Here, I reproduce the steps to build a docker image using guix system
image, and set te entrypoint to "", as you can see.

Still, a piece in the puzzle is missing, ideas ?

    https://gitlab.com/csantosb/gitlabci/-/jobs/8648358846

--
Cayetano Santos
GnuPG Key:   https://meta.sr.ht/~csantosb.pgp
FingerPrint: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: Building a Docker image for GitLab-CI

[Cayetano Santos]

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]


In the test-entry branch, I’m testing the trick in the guix-on-docker
repository, where the entrypoint is given a guix script.

    https://gitlab.com/csantosb/gitlabci/-/jobs/8648429390

Getting closer ...

--
Cayetano Santos
GnuPG Key:   https://meta.sr.ht/~csantosb.pgp
FingerPrint: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: Building a Docker image for GitLab-CI

[Simon Josefsson via]

[-- Attachment #1: Type: text/plain, Size: 6187 bytes --]

All,

I am trying to get a Guix container usable in GitLab, and thought I'd
share my status.  I have established working networking in the resulting
Guix container, which seems like progress (whoohoo!).  tl;dr:

https://gitlab.com/debdistutils/guix/container/-/jobs/8652014833

The problem seems to be that GitLab (I suppose they use docker?) picks
the wrong container file system from the resulting image.  It doesn't
use the same file system as a local 'podman run', see below.  Could this
be a 'guix pack' OCI container bug/problem?  Maybe 'guix pack' produces
too many blobs and GitLab/docker stops looking after while?  Or the
container configuration is incorrect?  Some bad interaction with 'podman
load -i'?  My OCI-fu is too weak here, help appreciated.

Here is my work:

https://gitlab.com/debdistutils/guix/container/
https://gitlab.com/debdistutils/guix/container/-/blob/main/.gitlab-ci.yml

(The system-* jobs are inspired by Cayetano's work, they aren't
necessary unless there is something wrong with the 'guix pack' approach
below...)

The idea is:

1) First job 'debian-with-guix' creates a Debian trixie container with
Guix and podman, and a 'guix pull'.  This is for caching, it takes 25
minutes to run on a large compute node, using a GitLab-local mirror of
Guix because Savannah access makes it even slower.

https://gitlab.com/debdistutils/guix/container/-/blob/main/debian-with-guix/Containerfile?ref_type=heads

https://gitlab.com/debdistutils/guix/container/-/jobs/8649009536

Output container (quite useful on its own):

registry.gitlab.com/debdistutils/guix/container:debian-with-guix

2) Second job 'pack' uses the 'debian-with-guix' image, runs a 'guix
pack' and creates a container using 'podman' and uploads it into:

registry.gitlab.com/debdistutils/guix/container:pack

I suspect the problem is happening in the 'guix pack' or 'podman load'
commands here.  Output from last successful run:

https://gitlab.com/debdistutils/guix/container/-/jobs/8649183646

3) Third job 'pack-test' tries to use the pack image in a GitLab job, as
a normal GitLab CI/CD build would work.

Job output is here:

https://gitlab.com/debdistutils/guix/container/-/jobs/8652014833

It fails with networking errors just like Ludo's earlier e-mail:

fping: icmp: unknown protocol

What is really weird is this root directory:

Using docker image sha256:57160f1c13ce56799d6e3e83dd97da4c929993ac008404ac38c67317cded25d1 for registry.gitlab.com/debdistutils/guix/container:pack with digest registry.gitlab.com/debdistutils/guix/container@sha256:be1ad3a7af69669cf3d138c6ec2b1201a64294aad33320246212c6689a1e5c9d ...
...
$ ls -la /etc
total 20
drwxr-xr-x 2 0 0 4096 Dec 16 10:15 .
drwxr-xr-x 1 0 0 4096 Dec 16 10:15 ..
-rw-r--r-- 1 0 0   46 Dec 16 10:15 hostname
-rw-r--r-- 1 0 0  283 Dec 16 10:15 hosts
lrwxrwxrwx 1 0 0   12 Dec 16 10:15 mtab -> /proc/mounts
-rw-r--r-- 1 0 0  841 Dec 16 10:15 resolv.conf

There is no /etc/protocols!  No wonder things doesn't work.

However if I run the same container locally, it looks different:

jas@kaka:~/src/guix-container$ podman images|grep pack
registry.gitlab.com/debdistutils/guix/container                   pack                  57160f1c13ce  54 years ago   1.23 GB
jas@kaka:~/src/guix-container$ podman run --entrypoint /bin/bash -it --rm registry.gitlab.com/debdistutils/guix/container:pack
bash-5.1# ls -la /etc
lrwxrwxrwx 1 0 0 55 Jan  1  1970 /etc -> /gnu/store/kcpr09dgqnr8q29d167cjk3wsmgizzkb-profile/etc
bash-5.1# ls -la /etc/
total 92
...
lrwxrwxrwx 1 0 0   70 Jan  1  1970 protocols -> /gnu/store/bfp25w47fxn8z0fdwj45prx2609sx59j-net-base-5.3/etc/protocols
...
bash-5.1# 

What is going on here?  Seems like GitLab docker is finding another
container file system compared to my local podman?  The hashes are the
same, so I should be working on the same file.

Does anyone have docker installed?  What does the equivalent of this
command do with docker?  Does it work like podman or GitLab?

podman run registry.gitlab.com/debdistutils/guix/container:pack ls -l /etc/

Networking seems to be set up fine, except the missing /etc/protocols:

$ ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
17: eth0@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue state UP group default 
    link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.17.0.3/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fd76:5338:4685:1:0:242:ac11:3/64 scope global nodad 
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe11:3/64 scope link tentative 
       valid_lft forever preferred_lft forever
$ ip -4 route
default via 172.17.0.1 dev eth0 
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.3 
$ ip -6 route
fd76:5338:4685:1::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fd76:5338:4685:1::1 dev eth0 metric 1024 pref medium
...
$ fping -c3 -D 130.237.72.201
fping: icmp: unknown protocol

Adding a small /etc/protocols makes networking work:

$ printf 'icmp\t1\tICMP\nipv6-icmp\t58\tIPv6-ICMP\n' > /etc/protocols
$ fping -c3 -D 130.237.72.201
[1734345646.83678] 130.237.72.201 : [0], 64 bytes, 112 ms (112 avg, 0% loss)
[1734345647.83701] 130.237.72.201 : [1], 64 bytes, 111 ms (112 avg, 0% loss)
[1734345648.83694] 130.237.72.201 : [2], 64 bytes, 111 ms (112 avg, 0% loss)
130.237.72.201 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 111/112/112
$ fping -c3 -D gnu.org
[1734345648.90485] gnu.org : [0], 64 bytes, 25.1 ms (25.1 avg, 0% loss)
[1734345649.86358] gnu.org : [1], 64 bytes, 24.2 ms (24.6 avg, 0% loss)
[1734345650.86371] gnu.org : [2], 64 bytes, 24.3 ms (24.5 avg, 0% loss)
gnu.org : xmt/rcv/%loss = 3/3/0%, min/avg/max = 24.2/24.5/25.1

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

Re: Building a Docker image for GitLab-CI

[Andreas Enge]

Hello Simon,

Am Mon, Dec 16, 2024 at 11:42:34AM +0100 schrieb Simon Josefsson via:
> I am trying to get a Guix container usable in GitLab, and thought I'd
> share my status.  I have established working networking in the resulting
> Guix container, which seems like progress (whoohoo!).  tl;dr:

at work we are using gitlab CI to build guix docker containers and run a
node on openshift for the bordeaux build farm:
   https://gitlab.inria.fr/enge/plm-guix
The README.md is completely outdated and serves mainly as a reminder to
myself on how this docker thing works; every time I look at it after a
break of a few months I have forgotten how to use a docker container...

And of course I have already forgotten the details; probably we should
write a little blog post. I will talk about it with my colleague when I
meet him next year ;-)

We also start with a Debian image and use a Dockerfile to install Guix
in it, as described in the Guix manual. Then for CI, we use this fixed
docker image to create a new one every time our repository (with a
channels.scm file and the plmshift.scm OS configuration file) changes.
In our case, this second docker image is the artefact that we then deploy.
We use "docker in docker" to create the images, and if I understood
correctly, this requires some privileges; these may not be given on
gitlab.com, but are available in our self-hosted instance.

Andreas

Re: Building a Docker image for GitLab-CI

[Simon Josefsson via]

[-- Attachment #1: Type: text/plain, Size: 4359 bytes --]

Andreas Enge <andreas@enge.fr> writes:

> Hello Simon,
>
> Am Mon, Dec 16, 2024 at 11:42:34AM +0100 schrieb Simon Josefsson via:
>> I am trying to get a Guix container usable in GitLab, and thought I'd
>> share my status.  I have established working networking in the resulting
>> Guix container, which seems like progress (whoohoo!).  tl;dr:
>
> at work we are using gitlab CI to build guix docker containers and run a
> node on openshift for the bordeaux build farm:
>    https://gitlab.inria.fr/enge/plm-guix
> The README.md is completely outdated and serves mainly as a reminder to
> myself on how this docker thing works; every time I look at it after a
> break of a few months I have forgotten how to use a docker container...
>
> And of course I have already forgotten the details; probably we should
> write a little blog post. I will talk about it with my colleague when I
> meet him next year ;-)
>
> We also start with a Debian image and use a Dockerfile to install Guix
> in it, as described in the Guix manual. Then for CI, we use this fixed
> docker image to create a new one every time our repository (with a
> channels.scm file and the plmshift.scm OS configuration file) changes.
> In our case, this second docker image is the artefact that we then deploy.
> We use "docker in docker" to create the images, and if I understood
> correctly, this requires some privileges; these may not be given on
> gitlab.com, but are available in our self-hosted instance.

Hi Andreas!  This all sounds quite similar to what I'm doing, although
using a different software stack.  I'm reading through your work now,
after actually finishing my work which I've announced here:

https://blog.josefsson.org/2024/12/18/guix-container-images-for-gitlab-ci-cd/
https://gitlab.com/debdistutils/guix/container

Looking into details, it seems you run this command to create the image:

https://gitlab.inria.fr/enge/plm-guix/-/blob/bf87f970c316f20cea2cf80f2511a280b5a71ed8/.gitlab-ci.yml#L44

docker run --privileged -v ./config:/config $CI_REGISTRY_IMAGE/builder:latest sh -c 'cd /config && /guix-daemon.sh guix time-machine -C channels.scm -- system image -t docker plmshift.scm  >/dev/null 2>&1 && cat /gnu/store/*docker-image.tar.gz' > image/docker-image.tar.gz
docker load -i image/docker-image.tar.gz

Your docker file is here:

https://gitlab.inria.fr/enge/plm-guix/-/blob/master/docker/Dockerfile?ref_type=heads

The guix-daemon.sh script is here:

https://gitlab.inria.fr/enge/plm-guix/-/blob/master/docker/guix-daemon.sh?ref_type=heads

Your plmshift.scm file is here:

https://gitlab.inria.fr/enge/plm-guix/-/blob/master/config/plmshift.scm?ref_type=heads

For comparison, I'm creating the image like this:

https://gitlab.com/debdistutils/guix/container/-/blob/main/.gitlab-ci.yml?ref_type=heads#L61

GUIX_PACKS_SLIM: guix bash-minimal coreutils-minimal net-base lndir
GUIX_PACKS_LATEST: $GUIX_PACKS_SLIM git-minimal findutils diffutils gcc-toolchain make automake autoconf tar grep sed gawk m4 gzip xz bzip2 iproute2 inetutils libcap shadow wget nss-certs
...
pack=$(guix pack $GUIX_PACKS --save-provenance -S /bin=bin -S /share=share -f docker --image-tag=guix --max-layers=8 --verbosity=0)
podman load -i $pack

My containerfile is here:

https://gitlab.com/debdistutils/guix/container/-/blob/main/debian-with-guix/Containerfile?ref_type=heads

Some of the stuff you resolve by using guix-daemon.sh and guix system
image on the plmshift.scm I instead push onto the consumer of my work,
as in these instructions:

https://gitlab.com/debdistutils/guix/container#how-to-use

One difference is that you are using your previous image as a basis for
the next one, which means you are using native Guix to build the image,
whereas I'm using Debian+Guix to build the image.  There is no
fundamental reason for this in my approach, so I opened an issue about
it:

https://gitlab.com/debdistutils/guix/container/-/issues/1

One more fundamental issue is that you are using 'guix system image' and
I was inspired by Ludo's e-mail and used 'guix pack'.  My experiments
with system images were that they ended up being larger, but maybe that
can be resolved by removing stuff.  Are there any general thoughts on
which is better to use?  Guix system vs Guix pack?  I kind of like the
idea of adding on top off guix-pack rather than removing from
guix-system.

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

Re: Building a Docker image for GitLab-CI

[Cayetano Santos via]

n<#secure method=pgpmime mode=sign>

Hi Andreas,

  Nice work ! I’ve been playing a bit with it, but failed miserably to
  use your image, as you can see:

    https://gitlab.com/csantosb/gitlabci/-/jobs/8681019372

  This is my dummy yaml file:

    https://gitlab.com/csantosb/gitlabci/-/blob/test-entry/.gitlab-ci.yml

  Do you have an example file on how to use the image ?

Thanks !

--
Cayetano Santos
GnuPG Key:   https://meta.sr.ht/~csantosb.pgp
FingerPrint: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682

Re: Building a Docker image for GitLab-CI

[Ludovic Courtès]

Hi Simon,

Simon Josefsson <simon@josefsson.org> skribis:

> https://gitlab.com/debdistutils/guix/container/-/blob/main/.gitlab-ci.yml

Yay, great that you went this far!

> It fails with networking errors just like Ludo's earlier e-mail:
>
> fping: icmp: unknown protocol
>
> What is really weird is this root directory:
>
> Using docker image sha256:57160f1c13ce56799d6e3e83dd97da4c929993ac008404ac38c67317cded25d1 for registry.gitlab.com/debdistutils/guix/container:pack with digest registry.gitlab.com/debdistutils/guix/container@sha256:be1ad3a7af69669cf3d138c6ec2b1201a64294aad33320246212c6689a1e5c9d ...
> ...
> $ ls -la /etc
> total 20
> drwxr-xr-x 2 0 0 4096 Dec 16 10:15 .
> drwxr-xr-x 1 0 0 4096 Dec 16 10:15 ..
> -rw-r--r-- 1 0 0   46 Dec 16 10:15 hostname
> -rw-r--r-- 1 0 0  283 Dec 16 10:15 hosts
> lrwxrwxrwx 1 0 0   12 Dec 16 10:15 mtab -> /proc/mounts
> -rw-r--r-- 1 0 0  841 Dec 16 10:15 resolv.conf
>
> There is no /etc/protocols!  No wonder things doesn't work.

And that’s in spite of you running ‘guix pack … net-base -S /etc=etc’.

Could it be that something in podman/Docker/GitLab-CI overrides /etc, or
overrides it specifically because it’s a symlink?  I’m not sure where to
look for that.

Ludo’.

Re: Building a Docker image for GitLab-CI

[Simon Josefsson via]

[-- Attachment #1: Type: text/plain, Size: 5858 bytes --]

Ludovic Courtès <ludovic.courtes@inria.fr> writes:

>> What is really weird is this root directory:
>>
>> Using docker image
>> sha256:57160f1c13ce56799d6e3e83dd97da4c929993ac008404ac38c67317cded25d1
>> for registry.gitlab.com/debdistutils/guix/container:pack with digest
>> registry.gitlab.com/debdistutils/guix/container@sha256:be1ad3a7af69669cf3d138c6ec2b1201a64294aad33320246212c6689a1e5c9d
>> ...
>> ...
>> $ ls -la /etc
>> total 20
>> drwxr-xr-x 2 0 0 4096 Dec 16 10:15 .
>> drwxr-xr-x 1 0 0 4096 Dec 16 10:15 ..
>> -rw-r--r-- 1 0 0   46 Dec 16 10:15 hostname
>> -rw-r--r-- 1 0 0  283 Dec 16 10:15 hosts
>> lrwxrwxrwx 1 0 0   12 Dec 16 10:15 mtab -> /proc/mounts
>> -rw-r--r-- 1 0 0  841 Dec 16 10:15 resolv.conf
>>
>> There is no /etc/protocols!  No wonder things doesn't work.
>
> And that’s in spite of you running ‘guix pack … net-base -S /etc=etc’.
>
> Could it be that something in podman/Docker/GitLab-CI overrides /etc, or
> overrides it specifically because it’s a symlink?  I’m not sure where to
> look for that.

Yes it seems like a GitLab/docker-specific problem since I don't get the
same /etc when running the generated image locally.

There is this interesting entry in /proc/mounts:

https://gitlab.com/debdistutils/guix/container/-/jobs/8652014833#L343

overlay / overlay rw,relatime,lowerdir=l/ZPVAK6UICUAWUUE4GUD6AYFCEM:l/HI6HL2SJWTZDQHPTA3SGR4PWNE:l/OAJJQ5NKJAJLIAOEWBNLI6WRNC:l/MRDSZ2V6PLTEQGMEDSOPX6FKEY:l/FG4SISAU6TZNHB6CQR5X5GNEJB:l/EZGDP6A5CMVPA5O6IKOOKPDMBE:l/DA5NZCY6NVIGU2X6U5XQQXV54M:l/P4MIVQ3I7VCYFTQ3AG6RCXZVW5:l/FGPCINKKCYRDHZI5BAAU7HEETW:l/MUYJFZRJLR4Z3BNBFRBRTGP4S5:l/UPGZHVDAILBRLLEH6T5RKWIFG7:l/YNTBNOTPU7QRK5K6RD63VSXG5Q:l/XUPHFGGN36OPHNU334M3V7HDXP:l/PVA2QRQE4D5MAKI6BMGVPETNZN:l/VTGADKUDL4KA4HPA2YCCQ2JQNI:l/WZHWY243PTUZTQIZJM26PVSYG4:l/7YLLGUSIRSUFPXIFI57F2UQSFQ:l/ZEOCYJR44JGRBRKGEM4AMWUHQE:l/YXFWBRXLFSBMYDDCTNODGJWWUV:l/NQK5YT5BWDWSTKFRB3KOGVGYLC:l/6CC2D5S3LSZOOKLULC2JJ5BUHG:l/OMQ7M7FSULZ2WHTQPIOIYP7HYQ:l/VRGMNYJNRPOBPP5IZCJR3YV7FP:l/5L2O6RAVRTGGTB7I2YKS6RMX64:l/57QINIJWW7ECMX3DKLCDL5UMUS:l/HTIS4VRXRVO24AWC6AYPQ4LPRG:l/DOTULUURRI6Z4XR2B4LPQTP33T:l/LZYLE6JUKQFJBIAEMBQMQIWZEE:l/2WEGBKQG6D3VAWLXJ5NCZPFGNP:l/QYVPGN6K2A3Y4VVVPKYLR5JVL7:l/IPS4YGXCRZ47O4AOKMZ4TYD2N3:l/2MZU46ZBHYS5IQI4NAVFD3PNYR:l/HW6B6GDN33YB7GBY3LEOW2XXB4:l/FRINUFWGYICMVPLOJULIHQ3XKV:l/HSHVRY3DQIT5LUS3EONQQCKNL3:l/CRUDGYNQRSSDKB4TYALBBVFIL3:l/QJRZZB6NOMXWO46YCAJ4U53VSH:l/BZPO5MYEYX3YFX5NXYR32E6VRM:l/FDWSYXJR7RNKG42AMXGSC6NUQE:l/Z6BTLASGE6ZXGQZUFIHG4QXQLU:l/DWTG7Y6N4DNP5AZLI6MIDZEBHQ:l/TY4DSPRKETTLFE5WB7KFBO2VSM:l/SAE7PNZP6FFK2NVDOQQTZMO2BV:l/ZCL7CRORSVNYVFKNW2WT7TMGFZ:l/KVH3MQTKJ6SH46B2FEHW7UCYGK:l/XMDKZU7KD755BFINQOBKPLKMZQ:l/MFKZPIVLWDKG5PIVI3UQUU3ILT:l/I24GPDX2SRV3Y4YSJDYVKEBDQE:l/W6OZHVZW2NCSQOJEGMP45P2D6W:l/ZD4RI6B4WQ65QO7EMDQZSCZFHS:l/ZS7D35LTVLE6NSGCCY4SQQANE5:l/2ZIJ6PAUHDPBOXR72A6HGU6L4B:l/ZL5XOQ6XMF6ZYQSXVAK7744SX7:l/A3WXIZD22NL62JYHBZVL5K36IK:l/KUDHAVWVBDXKHHQQVF33KDPHF4:l/6O5OF37ORZTEUV2JXNOPO3WNTQ:l/YVGTC6PVMDS2GVOF57TJWCN5DM:l/VYM3JKFOWAY7UIYGU6TPJTZVD5:l/2BT7MWUS2JMZMQXQ3MRLO5AH6I:l/CNZTAOCVMGIFCNP4IF77OQ5MU6:l/KQCUQ7H6EY7U423TWBX6N6QNU7:l/VNZNN2P4U26XHEDRSNIQ656GRE:l/7YG6BVIVDJYCCGLISSU4APAR4S:l/ELR3M2R3NLUI4U2YCKYKG6MWUV:l/PK34AGBR7JY4PUJIVEAO4J7UAK:l/ELIDWT3IMYDRR5L5VTA3REN3LH:l/DK7VEQCTNIWW4BOYCOVXZX2GQY:l/6BCYXFR5B6S3EYCMVCXKQPEP3M:l/GAF6PUKMPKABSXDZCMVE3NM2K5:l/ASVMZMXSKHAVGH5UFXXRFE7TUX:l/25QORLMIGZEEIBQGTV6UBNZEAH:l/FH5SA2MBXXRRAMDYI72FPK7RXU:l/77IRT3TXX3H7XH66YGR7O5AIYK:l/FIQQSP7XQLUH3IWBXF4DZXWTFN:l/NG6ZAASCTOH6SQVUBR2FR6YE4T:l/QAHEWNHBILTWWWJ4QMX4ISWIT4:l/VCSGZSH4SQRVHK4EWSLGFECG2S:l/7FAMLBB6DJW7VWYEOIN6FLBI2E:l/C4ZXSOLVY36PYMTRL2E2YIKTKY:l/NVH5IIZJ5SO422GGMFGNTFCAOA:l/E6EE3L3EB2B36E5A5PL5KF32FL:l/RPXH632CD3Y54UYAMMULLEZOE4:l/662KE3GHNLWZEUTFCRZXOKVA3P:l/3ZDSIX7ZFSLT2FIEYD6TB6GA7R:l/ZS7SJOXF7XF6OFTLVHYMRYZANK:l/F3CEOKDDPOK72QLUWGKHDIJTPG:l/65CFVU5ZFM4XVSTLDO2WGQE3GU:l/3C2OJ5ZVICH5QP733HTS2DHPJM:l/B37PUETDZKC3MUZZX6CT3M6ZEC:l/LTVIXAHIS7O45NFIVNPDVGYMR4:l/GGBS4BWCAD6UMV3755MJ3BQRI5:l/4XGXVIO5QQ2ARZTTG74M4UDK4V:l/X673P4Q5TGPWBLQIXOQ5JXKG2C:l/3K2Q6NGZ5EEIKCFBRMEWWZFWQK:l/ALTG2QI6YZVKXIP4UCRDMQWS5Q:l/P4AE6X6G5GK66GHHRBZ27BTBF3:l/2UEJWLKTB2GNGT2G6UWFZVDFRN:l/OCTYS4BHPFX4HC3OXJJVGABEPX:l/M766VP6Y5QL2OGI6EYO5OEB6H4:l/DNITYWJFFEVGWQPFQ37S57EIB5:l/PQE5T2ER2OKPNC2YNHZEJXVIY6,upperdir=98dac307f50ae5da4c8f2cc5fdf024465f63600e30fc3bb434fca31191e2efdc/diff,workdir=98dac307f50ae5da4c8f2cc5fdf024465f63600e30fc3bb434fca31191e2efdc/work 0 0

Could those entries correspond to blobs generated by 'guix pack'?

Compare

https://gitlab.com/debdistutils/guix/container/-/jobs/8649183646#L130

$ podman load -i /gnu/store/*-docker-pack.tar.gz
Getting image source signatures
Copying blob sha256:26c7e7107d11a712095a4bf12ff26c8f39fb86c347af15ad50bec4d9536a4144
Copying blob sha256:3c21466d0d8255e7a1dfcbc206c891fdf6cdd6241f461cdb038ca6ef7b508bce
...
Copying blob sha256:b6ead463213fb7ec39911848da3b34e404ed184ee48373737c8b2eb2abd0730a
Copying blob sha256:72ca44ded2f166add396cc6a890a5e8a19c182603e4528a9bfef3012ab59b6b5
Copying blob sha256:092becdd45260f6b3d07626b2a39a738cc0a2d5a1c9f4a000cd61e762da8fe1b
Copying blob sha256:5397467e8b6a3b911d0e61f722622b995850be0721121a8e36b26ca7037b2622
Copying blob sha256:e3646d587f1665642b0077dc27a60b3dfed78dc21aa99eca4391b56c754f4aa7
Copying blob sha256:bff8143cb75389795d58b8a9ddbb572496e2e2ea1369a7f025a6b6e15b3a8074
Copying config sha256:57160f1c13ce56799d6e3e83dd97da4c929993ac008404ac38c67317cded25d1
Writing manifest to image destination
Loaded image: localhost/guix-bash-minimal-coreutils-minimal-git:latest

Notice that there are many more 'Copying blob' lines than overlay mounts
above.  Are we just seeing overlayfs mount truncation here?

Is it possible to make 'guix pack' create a merged container instead of
all these layers?

I'll experiment a bit more...

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

Re: Building a Docker image for GitLab-CI

[Ludovic Courtès]

Simon Josefsson <simon@josefsson.org> skribis:

> Yes it seems like a GitLab/docker-specific problem since I don't get the
> same /etc when running the generated image locally.
>
> There is this interesting entry in /proc/mounts:
>
> https://gitlab.com/debdistutils/guix/container/-/jobs/8652014833#L343
>
> overlay / overlay rw,relatime,lowerdir=l/ZPVAK6UICUAWUUE4GUD6AYFCEM:l/HI6HL2SJWTZDQHPTA3SGR4PWNE:l/OAJJQ5NKJAJLIAOEWBNLI6WRNC:l/MRDSZ2V6PLTEQGMEDSOPX6FKEY:l/FG4SISAU6TZNHB6CQR5X5GNEJB:l/EZGDP6A5CMVPA5O6IKOOKPDMBE:l/DA5NZCY6NVIGU2X6U5XQQXV54M:l/P4MIVQ3I7VCYFTQ3AG6RCXZVW5:l/FGPCINKKCYRDHZI5BAAU7HEETW:l/MUYJFZRJLR4Z3BNBFRBRTGP4S5:l/UPGZHVDAILBRLLEH6T5RKWIFG7:l/YNTBNOTPU7QRK5K6RD63VSXG5Q:l/XUPHFGGN36OPHNU334M3V7HDXP:l/PVA2QRQE4D5MAKI6BMGVPETNZN:l/VTGADKUDL4KA4HPA2YCCQ2JQNI:l/WZHWY243PTUZTQIZJM26PVSYG4:l/7YLLGUSIRSUFPXIFI57F2UQSFQ:l/ZEOCYJR44JGRBRKGEM4AMWUHQE:l/YXFWBRXLFSBMYDDCTNODGJWWUV:l/NQK5YT5BWDWSTKFRB3KOGVGYLC:l/6CC2D5S3LSZOOKLULC2JJ5BUHG:l/OMQ7M7FSULZ2WHTQPIOIYP7HYQ:l/VRGMNYJNRPOBPP5IZCJR3YV7FP:l/5L2O6RAVRTGGTB7I2YKS6RMX64:l/57QINIJWW7ECMX3DKLCDL5UMUS:l/HTIS4VRXRVO24AWC6AYPQ4LPRG:l/DOTULUURRI6Z4XR2B4LPQTP33T:l/LZYLE6JUKQFJBIAEMBQMQIWZEE:l/2WEGBKQG6D3VAWLXJ5NCZPFGNP:l/QYVPGN6K2A3Y4VVVPKYLR5JVL7:l/IPS4YGXCRZ47O4AOKMZ4TYD2N3:l/2MZU46ZBHYS5IQI4NAVFD3PNYR:l/HW6B6GDN33YB7GBY3LEOW2XXB4:l/FRINUFWGYICMVPLOJULIHQ3XKV:l/HSHVRY3DQIT5LUS3EONQQCKNL3:l/CRUDGYNQRSSDKB4TYALBBVFIL3:l/QJRZZB6NOMXWO46YCAJ4U53VSH:l/BZPO5MYEYX3YFX5NXYR32E6VRM:l/FDWSYXJR7RNKG42AMXGSC6NUQE:l/Z6BTLASGE6ZXGQZUFIHG4QXQLU:l/DWTG7Y6N4DNP5AZLI6MIDZEBHQ:l/TY4DSPRKETTLFE5WB7KFBO2VSM:l/SAE7PNZP6FFK2NVDOQQTZMO2BV:l/ZCL7CRORSVNYVFKNW2WT7TMGFZ:l/KVH3MQTKJ6SH46B2FEHW7UCYGK:l/XMDKZU7KD755BFINQOBKPLKMZQ:l/MFKZPIVLWDKG5PIVI3UQUU3ILT:l/I24GPDX2SRV3Y4YSJDYVKEBDQE:l/W6OZHVZW2NCSQOJEGMP45P2D6W:l/ZD4RI6B4WQ65QO7EMDQZSCZFHS:l/ZS7D35LTVLE6NSGCCY4SQQANE5:l/2ZIJ6PAUHDPBOXR72A6HGU6L4B:l/ZL5XOQ6XMF6ZYQSXVAK7744SX7:l/A3WXIZD22NL62JYHBZVL5K36IK:l/KUDHAVWVBDXKHHQQVF33KDPHF4:l/6O5OF37ORZTEUV2JXNOPO3WNTQ:l/YVGTC6PVMDS2GVOF57TJWCN5DM:l/VYM3JKFOWAY7UIYGU6TPJTZVD5:l/2BT7MWUS2JMZMQXQ3MRLO5AH6I:l/CNZTAOCVMGIFCNP4IF77OQ5MU6:l/KQCUQ7H6EY7U423TWBX6N6QNU7:l/VNZNN2P4U26XHEDRSNIQ656GRE:l/7YG6BVIVDJYCCGLISSU4APAR4S:l/ELR3M2R3NLUI4U2YCKYKG6MWUV:l/PK34AGBR7JY4PUJIVEAO4J7UAK:l/ELIDWT3IMYDRR5L5VTA3REN3LH:l/DK7VEQCTNIWW4BOYCOVXZX2GQY:l/6BCYXFR5B6S3EYCMVCXKQPEP3M:l/GAF6PUKMPKABSXDZCMVE3NM2K5:l/ASVMZMXSKHAVGH5UFXXRFE7TUX:l/25QORLMIGZEEIBQGTV6UBNZEAH:l/FH5SA2MBXXRRAMDYI72FPK7RXU:l/77IRT3TXX3H7XH66YGR7O5AIYK:l/FIQQSP7XQLUH3IWBXF4DZXWTFN:l/NG6ZAASCTOH6SQVUBR2FR6YE4T:l/QAHEWNHBILTWWWJ4QMX4ISWIT4:l/VCSGZSH4SQRVHK4EWSLGFECG2S:l/7FAMLBB6DJW7VWYEOIN6FLBI2E:l/C4ZXSOLVY36PYMTRL2E2YIKTKY:l/NVH5IIZJ5SO422GGMFGNTFCAOA:l/E6EE3L3EB2B36E5A5PL5KF32FL:l/RPXH632CD3Y54UYAMMULLEZOE4:l/662KE3GHNLWZEUTFCRZXOKVA3P:l/3ZDSIX7ZFSLT2FIEYD6TB6GA7R:l/ZS7SJOXF7XF6OFTLVHYMRYZANK:l/F3CEOKDDPOK72QLUWGKHDIJTPG:l/65CFVU5ZFM4XVSTLDO2WGQE3GU:l/3C2OJ5ZVICH5QP733HTS2DHPJM:l/B37PUETDZKC3MUZZX6CT3M6ZEC:l/LTVIXAHIS7O45NFIVNPDVGYMR4:l/GGBS4BWCAD6UMV3755MJ3BQRI5:l/4XGXVIO5QQ2ARZTTG74M4UDK4V:l/X673P4Q5TGPWBLQIXOQ5JXKG2C:l/3K2Q6NGZ5EEIKCFBRMEWWZFWQK:l/ALTG2QI6YZVKXIP4UCRDMQWS5Q:l/P4AE6X6G5GK66GHHRBZ27BTBF3:l/2UEJWLKTB2GNGT2G6UWFZVDFRN:l/OCTYS4BHPFX4HC3OXJJVGABEPX:l/M766VP6Y5QL2OGI6EYO5OEB6H4:l/DNITYWJFFEVGWQPFQ37S57EIB5:l/PQE5T2ER2OKPNC2YNHZEJXVIY6,upperdir=98dac307f50ae5da4c8f2cc5fdf024465f63600e30fc3bb434fca31191e2efdc/diff,workdir=98dac307f50ae5da4c8f2cc5fdf024465f63600e30fc3bb434fca31191e2efdc/work 0 0
>
> Could those entries correspond to blobs generated by 'guix pack'?

Not directly (the generated image doesn’t mount anything by itself), but
it could correspond to the image layers maybe?

> Is it possible to make 'guix pack' create a merged container instead of
> all these layers?

Maybe you could try different values of ‘guix pack --max-layers=…’?

When ‘--max-layers’ is omitted, the resulting image contains a single
layer AIUI (according to the default value of
‘%docker-image-max-layers’).

Ludo’.

Re: Building a Docker image for GitLab-CI

[Simon Josefsson via]

[-- Attachment #1: Type: text/plain, Size: 4067 bytes --]

I am happy to announce Guix container images:

https://gitlab.com/debdistutils/guix/container/

They are suitable for use in GitLab pipelines.

There are many things to continue discuss and resolve.  However it is
now possible to start a GitLab pipeline job that uses an 'image:'
pointing to a container file that were created by `guix pack` and it has
network access.  Andreas Enge posted a link on how to achieve this with
non-free 'docker' and some custom hosted gitlab runners with extra
permissions, but my variant uses only free software and the images can
be reproduced solely on the GitLab public runners (i.e., no image
uploading from a local laptop).  As far as I know this hasn't been done
before.

Successful example job that runs a Guix environment:

https://gitlab.com/debdistutils/guix/container/-/jobs/8670483694

Start the container like this:

sudo apt-get install podman || guix package -i podman
podman run -it registry.gitlab.com/debdistutils/guix/container:latest

The README mentions a few works that you will appreciate -- can you
suggest ways to resolve these matters?

- `export HOME=/`

- `export CWD=/`

- `guix-daemon --disable-chroot &`

- `GUIX_PROFILE=/root/.config/guix/current; . "$GUIX_PROFILE/etc/profile"`

- guix package -i fails: `guix perform-download: error: refusing to
  run with elevated privileges (UID 0)`

- GitLab pipeline job entrypoints: three possible entry-point usages
  behave somewhat different depending on how `guix pack` was invoked

- Adding `nss-certs` to the `guix pack` command breaks: `(symlink
  "NetLock_Arany_=Class_Gold=_F?tan?s?tv?ny.pem" #) Throw to key
  encoding-error' with args ("scm_to_stringn" "cannot convert wide
  string to output locale" 84 #f #f)'.`

Those things aside, the main problem right now is that I would expect
'guix package -i gcc automake autoconf' to work.  However as you can see
in the `test-amd64-package-install` job things fail to download
seamingly from an intentional privilege check:

guix perform-download: error: refusing to run with elevated privileges (UID 0)

https://gitlab.com/debdistutils/guix/container/-/jobs/8670514009

What is the best way to resolve this?  Ugly insecure workarounds are
acceptable too, I didn't find any --insecure or similar.

It would be nice to publish a couple of different images, one minimal
and one more complete with, say, gcc on it.  Thoughts on what packages
to include and how to name the images?

Doing arm64 images should be straight forward but I get an error running
'guix pull' in the Debian image: https://issues.guix.gnu.org/74925 --
Also I do not know how to push a combined amd64+arm64 image like Debian
do with the 'debian:trixie' image doing the right thing for both amd64
and arm64 under the same name.  Ideas?

Can someone try to use them in some other environments, maybe GitHub
actions or Codeberg Woodpecker?

Finally, you may wonder why things didn't work before.  Some of the
major reasons: 1) --max-layer=100 and 2) -S /etc=etc and 3) Missing
/etc/protocols etc.  GitLab's docker setup doesn't handle many layers,
and it happens to just mount a sub-set of layers (see mount output,
missing a lot of layers).  Which files are put at which layer seems to
vary between `guix pack` runs for some reason, making it really hard to
debug (sometimes things worked partially, sometimes not, depending on
which files ended up visible).  I use --max-layers=8 now.  Re /etc=etc
it seems GitLab's docker setup bind-mounts things below /etc/ and it
cannot handle the root /etc symlink.  A workaround is to use `lndir`
which I use in the `test-amd64-package-install` job.  This is limitation
of GitLab's docker setup: I tried running a `-S /etc=etc` image on my
own GitLab runner based on Trisquel [1] and it worked fine, it mounted
things below the symlinked tree properly.  Could `guix pack` be teached
how to do a lndir-approach for /etc instead of symlink, perhaps?

Happy hacking,
/Simon

[1] https://gitlab.com/debdistutils/debdistreproduce/-/blob/main/gitlab-runner-with-podman-on-trisquel-aramo.md?ref_type=heads

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

Re: Building a Docker image for GitLab-CI

[Ludovic Courtès]

Hi Simon!

Simon Josefsson <simon@josefsson.org> skribis:

> I am happy to announce Guix container images:
>
> https://gitlab.com/debdistutils/guix/container/
>
> They are suitable for use in GitLab pipelines.

Yay!

> - guix package -i fails: `guix perform-download: error: refusing to
>   run with elevated privileges (UID 0)`

Should be fixed by running guix-daemon with
“--build-users-group=whatever” so that downloads run as one of the build
users, not as root.

> - GitLab pipeline job entrypoints: three possible entry-point usages
>   behave somewhat different depending on how `guix pack` was invoked

This image uses Guix installed on Debian though, no?

> - Adding `nss-certs` to the `guix pack` command breaks: `(symlink
>   "NetLock_Arany_=Class_Gold=_F?tan?s?tv?ny.pem" #) Throw to key
>   encoding-error' with args ("scm_to_stringn" "cannot convert wide
>   string to output locale" 84 #f #f)'.`

You need to run guix-daemon in a UTF-8 locale like “C.UTF-8” (which is
supported out-of-the-box).

See also <https://issues.guix.gnu.org/75007>.

> Finally, you may wonder why things didn't work before.  Some of the
> major reasons: 1) --max-layer=100 and 2) -S /etc=etc and 3) Missing
> /etc/protocols etc.  GitLab's docker setup doesn't handle many layers,
> and it happens to just mount a sub-set of layers (see mount output,
> missing a lot of layers).  Which files are put at which layer seems to
> vary between `guix pack` runs for some reason, making it really hard to
> debug (sometimes things worked partially, sometimes not, depending on
> which files ended up visible).  I use --max-layers=8 now.

Interesting.  Did you find points in the code (Docker? GitLab?) about
this subset of layers being mounted?

> Re /etc=etc it seems GitLab's docker setup bind-mounts things below
> /etc/ and it cannot handle the root /etc symlink.  A workaround is to
> use `lndir` which I use in the `test-amd64-package-install` job.  This
> is limitation of GitLab's docker setup: I tried running a `-S
> /etc=etc` image on my own GitLab runner based on Trisquel [1] and it
> worked fine, it mounted things below the symlinked tree properly.
> Could `guix pack` be teached how to do a lndir-approach for /etc
> instead of symlink, perhaps?

It could symlink individual files and make /etc a directory.  (What’s
‘lndir’, if I may ask?)

Thanks for the investigation and all!

Ludo’.

Re: Building a Docker image for GitLab-CI

[Simon Josefsson via]

[-- Attachment #1: Type: text/plain, Size: 7133 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

>> - guix package -i fails: `guix perform-download: error: refusing to
>>   run with elevated privileges (UID 0)`
>
> Should be fixed by running guix-daemon with
> “--build-users-group=whatever” so that downloads run as one of the build
> users, not as root.

Yes, I discovered that too.

>> - GitLab pipeline job entrypoints: three possible entry-point usages
>>   behave somewhat different depending on how `guix pack` was invoked
>
> This image uses Guix installed on Debian though, no?

No - the resulting image is purely from 'guix pack', no Debian in the
final image at all.

I didn't test now but I think Debian images handle all three entrypoint
values, but the 'guix pack' image doesn't.

>> - Adding `nss-certs` to the `guix pack` command breaks: `(symlink
>>   "NetLock_Arany_=Class_Gold=_F?tan?s?tv?ny.pem" #) Throw to key
>>   encoding-error' with args ("scm_to_stringn" "cannot convert wide
>>   string to output locale" 84 #f #f)'.`
>
> You need to run guix-daemon in a UTF-8 locale like “C.UTF-8” (which is
> supported out-of-the-box).
>
> See also <https://issues.guix.gnu.org/75007>.

Thanks - I finally figured this one out in the same way.

>> Finally, you may wonder why things didn't work before.  Some of the
>> major reasons: 1) --max-layer=100 and 2) -S /etc=etc and 3) Missing
>> /etc/protocols etc.  GitLab's docker setup doesn't handle many layers,
>> and it happens to just mount a sub-set of layers (see mount output,
>> missing a lot of layers).  Which files are put at which layer seems to
>> vary between `guix pack` runs for some reason, making it really hard to
>> debug (sometimes things worked partially, sometimes not, depending on
>> which files ended up visible).  I use --max-layers=8 now.
>
> Interesting.  Did you find points in the code (Docker? GitLab?) about
> this subset of layers being mounted?

No, I didn't go down chasing the root cause.  I wonder if maybe it isn't
as simple as some Linux kernel restriction on mount point sizes?  If you
try to load a --max-layer=100 image on GitLab you end up with a
/proc/mounts containing lines like this:

rw,relatime,lowerdir=l/ZPVAK6UICUAWUUE4GUD6AYFCEM:l/HI6HL2SJWTZDQHPTA3SGR4PWNE:l/OAJJQ5NKJAJLIAOEWBNLI6WRNC:l/MRDSZ2V6PLTEQGMEDSOPX6FKEY:l/FG4SISAU6TZNHB6CQR5X5GNEJB:l/EZGDP6A5CMVPA5O6IKOOKPDMBE:l/DA5NZCY6NVIGU2X6U5XQQXV54M:l/P4MIVQ3I7VCYFTQ3AG6RCXZVW5:l/FGPCINKKCYRDHZI5BAAU7HEETW:l/MUYJFZRJLR4Z3BNBFRBRTGP4S5:l/UPGZHVDAILBRLLEH6T5RKWIFG7:l/YNTBNOTPU7QRK5K6RD63VSXG5Q:l/XUPHFGGN36OPHNU334M3V7HDXP:l/PVA2QRQE4D5MAKI6BMGVPETNZN:l/VTGADKUDL4KA4HPA2YCCQ2JQNI:l/WZHWY243PTUZTQIZJM26PVSYG4:l/7YLLGUSIRSUFPXIFI57F2UQSFQ:l/ZEOCYJR44JGRBRKGEM4AMWUHQE:l/YXFWBRXLFSBMYDDCTNODGJWWUV:l/NQK5YT5BWDWSTKFRB3KOGVGYLC:l/6CC2D5S3LSZOOKLULC2JJ5BUHG:l/OMQ7M7FSULZ2WHTQPIOIYP7HYQ:l/VRGMNYJNRPOBPP5IZCJR3YV7FP:l/5L2O6RAVRTGGTB7I2YKS6RMX64:l/57QINIJWW7ECMX3DKLCDL5UMUS:l/HTIS4VRXRVO24AWC6AYPQ4LPRG:l/DOTULUURRI6Z4XR2B4LPQTP33T:l/LZYLE6JUKQFJBIAEMBQMQIWZEE:l/2WEGBKQG6D3VAWLXJ5NCZPFGNP:l/QYVPGN6K2A3Y4VVVPKYLR5JVL7:l/IPS4YGXCRZ47O4AOKMZ4TYD2N3:l/2MZU46ZBHYS5IQI4NAVFD3PNYR:l/HW6B6GDN33YB7GBY3LEOW2XXB4:l/FRINUFWGYICMVPLOJULIHQ3XKV:l/HSHVRY3DQIT5LUS3EONQQCKNL3:l/CRUDGYNQRSSDKB4TYALBBVFIL3:l/QJRZZB6NOMXWO46YCAJ4U53VSH:l/BZPO5MYEYX3YFX5NXYR32E6VRM:l/FDWSYXJR7RNKG42AMXGSC6NUQE:l/Z6BTLASGE6ZXGQZUFIHG4QXQLU:l/DWTG7Y6N4DNP5AZLI6MIDZEBHQ:l/TY4DSPRKETTLFE5WB7KFBO2VSM:l/SAE7PNZP6FFK2NVDOQQTZMO2BV:l/ZCL7CRORSVNYVFKNW2WT7TMGFZ:l/KVH3MQTKJ6SH46B2FEHW7UCYGK:l/XMDKZU7KD755BFINQOBKPLKMZQ:l/MFKZPIVLWDKG5PIVI3UQUU3ILT:l/I24GPDX2SRV3Y4YSJDYVKEBDQE:l/W6OZHVZW2NCSQOJEGMP45P2D6W:l/ZD4RI6B4WQ65QO7EMDQZSCZFHS:l/ZS7D35LTVLE6NSGCCY4SQQANE5:l/2ZIJ6PAUHDPBOXR72A6HGU6L4B:l/ZL5XOQ6XMF6ZYQSXVAK7744SX7:l/A3WXIZD22NL62JYHBZVL5K36IK:l/KUDHAVWVBDXKHHQQVF33KDPHF4:l/6O5OF37ORZTEUV2JXNOPO3WNTQ:l/YVGTC6PVMDS2GVOF57TJWCN5DM:l/VYM3JKFOWAY7UIYGU6TPJTZVD5:l/2BT7MWUS2JMZMQXQ3MRLO5AH6I:l/CNZTAOCVMGIFCNP4IF77OQ5MU6:l/KQCUQ7H6EY7U423TWBX6N6QNU7:l/VNZNN2P4U26XHEDRSNIQ656GRE:l/7YG6BVIVDJYCCGLISSU4APAR4S:l/ELR3M2R3NLUI4U2YCKYKG6MWUV:l/PK34AGBR7JY4PUJIVEAO4J7UAK:l/ELIDWT3IMYDRR5L5VTA3REN3LH:l/DK7VEQCTNIWW4BOYCOVXZX2GQY:l/6BCYXFR5B6S3EYCMVCXKQPEP3M:l/GAF6PUKMPKABSXDZCMVE3NM2K5:l/ASVMZMXSKHAVGH5UFXXRFE7TUX:l/25QORLMIGZEEIBQGTV6UBNZEAH:l/FH5SA2MBXXRRAMDYI72FPK7RXU:l/77IRT3TXX3H7XH66YGR7O5AIYK:l/FIQQSP7XQLUH3IWBXF4DZXWTFN:l/NG6ZAASCTOH6SQVUBR2FR6YE4T:l/QAHEWNHBILTWWWJ4QMX4ISWIT4:l/VCSGZSH4SQRVHK4EWSLGFECG2S:l/7FAMLBB6DJW7VWYEOIN6FLBI2E:l/C4ZXSOLVY36PYMTRL2E2YIKTKY:l/NVH5IIZJ5SO422GGMFGNTFCAOA:l/E6EE3L3EB2B36E5A5PL5KF32FL:l/RPXH632CD3Y54UYAMMULLEZOE4:l/662KE3GHNLWZEUTFCRZXOKVA3P:l/3ZDSIX7ZFSLT2FIEYD6TB6GA7R:l/ZS7SJOXF7XF6OFTLVHYMRYZANK:l/F3CEOKDDPOK72QLUWGKHDIJTPG:l/65CFVU5ZFM4XVSTLDO2WGQE3GU:l/3C2OJ5ZVICH5QP733HTS2DHPJM:l/B37PUETDZKC3MUZZX6CT3M6ZEC:l/LTVIXAHIS7O45NFIVNPDVGYMR4:l/GGBS4BWCAD6UMV3755MJ3BQRI5:l/4XGXVIO5QQ2ARZTTG74M4UDK4V:l/X673P4Q5TGPWBLQIXOQ5JXKG2C:l/3K2Q6NGZ5EEIKCFBRMEWWZFWQK:l/ALTG2QI6YZVKXIP4UCRDMQWS5Q:l/P4AE6X6G5GK66GHHRBZ27BTBF3:l/2UEJWLKTB2GNGT2G6UWFZVDFRN:l/OCTYS4BHPFX4HC3OXJJVGABEPX:l/M766VP6Y5QL2OGI6EYO5OEB6H4:l/DNITYWJFFEVGWQPFQ37S57EIB5:l/PQE5T2ER2OKPNC2YNHZEJXVIY6,upperdir=98dac307f50ae5da4c8f2cc5fdf024465f63600e30fc3bb434fca31191e2efdc/diff,workdir=98dac307f50ae5da4c8f2cc5fdf024465f63600e30fc3bb434fca31191e2efdc/work

That doesn't contain all of the 100 layers (although I didn't double
count..).  Something is truncating those lines.

That would explain why it works for me locally with 'podman': it seems
podman uses much shorter names, like:

rw,relatime,lowerdir=0:1:2:3:4..

instead of those longer strings above.

>> Re /etc=etc it seems GitLab's docker setup bind-mounts things below
>> /etc/ and it cannot handle the root /etc symlink.  A workaround is to
>> use `lndir` which I use in the `test-amd64-package-install` job.  This
>> is limitation of GitLab's docker setup: I tried running a `-S
>> /etc=etc` image on my own GitLab runner based on Trisquel [1] and it
>> worked fine, it mounted things below the symlinked tree properly.
>> Could `guix pack` be teached how to do a lndir-approach for /etc
>> instead of symlink, perhaps?
>
> It could symlink individual files and make /etc a directory.

Is this possible now?  How?

The --symlink is defined like this now:

‘-S SPEC’
     Add the symlinks specified by SPEC to the pack.  This option can
     appear several times.
     SPEC has the form ‘SOURCE=TARGET’, where SOURCE is the symlink that
     will be created and TARGET is the symlink target.
     For instance, ‘-S /opt/gnu/bin=bin’ creates a ‘/opt/gnu/bin’
     symlink pointing to the ‘bin’ sub-directory of the profile.

Could we extend that somehow to support the model of recursively
creating directories, but symlink files within them?

Or a new --symlink-mkdir parameter or similar?

> (What’s ‘lndir’, if I may ask?)

Exactly that :)

One of those ancient tools that still is surprisingly useful:

https://manpages.debian.org/bookworm/xutils-dev/lndir.1.en.html
https://gitlab.freedesktop.org/xorg/util/lndir/-/blob/master/lndir.c

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

Container image entrypoints on Gitlab (was: Re: Building a Docker image for GitLab-CI)

[Simon Josefsson via]

[-- Attachment #1: Type: text/plain, Size: 2722 bytes --]

Simon Josefsson via <help-guix@gnu.org> writes:

> I didn't test now but I think Debian images handle all three entrypoint
> values, but the 'guix pack' image doesn't.

That was not true!  Here the situation:

https://gitlab.com/debdistutils/guix/container/-/pipelines/1600726433

Debian fails on these two GitLab .gitlab-ci.yml variants:

  image:
    name: debian:stable
    entrypoint: ["/bin/sh"]

  image:
    name: debian:stable
    entrypoint: ["/bin/sh", "-c"]

And works on these two variants:

  image:
    name: debian:stable
    entrypoint: [""]

  image: debian:stable

The last one is what I suppose most people want to use.  One shouldn't
have to specify entrypoint's when using GitLab CI/CD images.

My Guix container:latest works on these three variants:

  image:
    name: debian:stable
    entrypoint: ["/bin/sh", "-c"]

  image:
    name: debian:stable
    entrypoint: [""]

  image: debian:stable

And fail on this variant:

  image:
    name: debian:stable
    entrypoint: ["/bin/sh"]

At least we are not worse than Debian here.

However there is another difference, local run of Debian images handle
both these variants:

jas@kaka:~/src/guix-container$ podman run -it --rm debian:trixie-slim
root@f9634c8d6b63:/# 
exit
jas@kaka:~/src/guix-container$ podman run --entrypoint /bin/sh -it --rm debian:trixie-slim
# 
jas@kaka:~/src/guix-container$ 

But my Guix images doesn't:

jas@kaka:~/src/guix-container$ podman run -it --rm registry.gitlab.com/debdistutils/guix/container:latest
Error: no command or entrypoint provided, and no CMD or ENTRYPOINT from image
jas@kaka:~/src/guix-container$ podman run --entrypoint /bin/sh -it --rm registry.gitlab.com/debdistutils/guix/container:latest
sh-5.1# exit
jas@kaka:~/src/guix-container$ 

Presumably because of a missing '--entry-point=/bin/sh' when building
the images using 'guix pack'.  So let's add it!  Yes this now works:

jas@kaka:~/src/guix-container$ podman run -it --rm registry.gitlab.com/debdistutils/guix/container:latest2
sh-5.1# exit
jas@kaka:~/src/guix-container$ podman run --entrypoint /bin/sh -it --rm registry.gitlab.com/debdistutils/guix/container:latest2
sh-5.1# exit
jas@kaka:~/src/guix-container$ 

However this breaks GitLab CI/CD usage:

  image: $CI_REGISTRY_IMAGE:latest2

https://gitlab.com/debdistutils/guix/container/-/jobs/8713593164

Ouch, that is the primary use-case we want to support!

So until someone figures this one out, I've opted that the default
images require --entrypoint when invoked local on laptops with podman
but work without any configuration from GitLab shared runners and normal
.gitlab-ci.yml usage.

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

Re: Container image entrypoints on Gitlab

[Simon Josefsson via]

[-- Attachment #1: Type: text/plain, Size: 2756 bytes --]

I believe the GitLab CI entrypoint behaviour boils down to OCI
configuration, compare Debian's image:

skopeo inspect --config docker://debian:12
...
    "config": {
        "Env": [
            "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
        ],
        "Cmd": [
            "bash"
        ]
    },

The images I generate via 'guix pack':

skopeo inspect --config docker://registry.gitlab.com/debdistutils/guix/container:stage1
...
    "config": {
        "Env": [
            "PATH=/gnu/store/5n0rm83hn6xwf57iwlrn6sfcr5bfjdv3-profile/bin"
        ]
    },

Using `guix pack --entry-point` changes it into:

    "config": {
        "Env": [
            "PATH=/gnu/store/0plsn32m4xzv4i9ixbx02d42nhbw5hx6-profile/bin"
        ],
        "Entrypoint": [
            "/gnu/store/0plsn32m4xzv4i9ixbx02d42nhbw5hx6-profile/bash"
        ]
    },

However if we want the same behaviour as the debian:12 container image,
we want to set "Cmd" instead of "Entrypoint".

I found the code for this in guix/docker.scm and guix/scripts/pack.scm
but making changes this deep down is beyond me right now.  Help?

IMHO the best would be if Guix container images looked like this:

    "config": {
        "Env": [
            "PATH=/gnu/store/5n0rm83hn6xwf57iwlrn6sfcr5bfjdv3-profile/bin"
        ],
        "Cmd": [
            "bash"
        ]
    },

Comparing some other well-known images, fedora:42 has:

    "config": {
        "Env": [
            "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
            "DISTTAG=f42container",
            "FGC=f42",
            "FBR=f42"
        ],
        "Cmd": [
            "/bin/bash"
        ],
        "WorkingDir": "/",
        "Labels": {
            "maintainer": "Clement Verna \u003ccverna@fedoraproject.org\u003e"
        }
    },

AlmaLinux:8 and AlmaLinux:9 has:

    "config": {
        "Env": [
            "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
        ],
        "Cmd": [
            "/bin/bash"
        ],
        "WorkingDir": "/"
    },

Alpine:latest has:

    "config": {
        "Env": [
            "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
        ],
        "Cmd": [
            "/bin/sh"
        ],
        "WorkingDir": "/"
    },

ArchLinux:latest has:

    "config": {
        "Env": [
            "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
            "LANG=C.UTF-8"
        ],
        "Cmd": [
            "/usr/bin/bash"
        ],
        "WorkingDir": "/",

Ubuntu:24.04 has:

    "config": {
        "Env": [
            "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
        ],
        "Cmd": [
            "/bin/bash"
        ],

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

GitLab container /etc symlink problem (was: Re: Building a Docker image for GitLab-CI)

[Simon Josefsson via]

[-- Attachment #1: Type: text/plain, Size: 4001 bytes --]

Simon Josefsson via <help-guix@gnu.org> writes:

>>> Re /etc=etc it seems GitLab's docker setup bind-mounts things below
>>> /etc/ and it cannot handle the root /etc symlink.  A workaround is to
>>> use `lndir` which I use in the `test-amd64-package-install` job.  This
>>> is limitation of GitLab's docker setup: I tried running a `-S
>>> /etc=etc` image on my own GitLab runner based on Trisquel [1] and it
>>> worked fine, it mounted things below the symlinked tree properly.
>>> Could `guix pack` be teached how to do a lndir-approach for /etc
>>> instead of symlink, perhaps?
>>
>> It could symlink individual files and make /etc a directory.
>
> Is this possible now?  How?
>
> The --symlink is defined like this now:
>
> ‘-S SPEC’
>      Add the symlinks specified by SPEC to the pack.  This option can
>      appear several times.
>      SPEC has the form ‘SOURCE=TARGET’, where SOURCE is the symlink that
>      will be created and TARGET is the symlink target.
>      For instance, ‘-S /opt/gnu/bin=bin’ creates a ‘/opt/gnu/bin’
>      symlink pointing to the ‘bin’ sub-directory of the profile.
>
> Could we extend that somehow to support the model of recursively
> creating directories, but symlink files within them?
>
> Or a new --symlink-mkdir parameter or similar?
>
>> (What’s ‘lndir’, if I may ask?)
>
> Exactly that :)

I found out that the lndir approach doesn't work.  The /etc symlinks are
modified by 'guix package -i'.  It only occurs sometimes, probably
depending on if it happens to pull in a new version of 'net-base'.  It
seems 'guix package -i hello' works but 'guix package -i skopeo'
doesn't.

https://gitlab.com/debdistutils/guix/container/-/jobs/8713723100

...
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
61.5 MB will be downloaded
retrying download of '/gnu/store/bfp25w47fxn8z0fdwj45prx2609sx59j-net-base-5.3' with other substitute URLs...
guix substitute: warning: ci.guix.gnu.org: host not found: Servname not supported for ai_socktype
guix substitute: error: failed to find alternative substitute for '/gnu/store/bfp25w47fxn8z0fdwj45prx2609sx59j-net-base-5.3'
substitution of /gnu/store/bfp25w47fxn8z0fdwj45prx2609sx59j-net-base-5.3 failed
guix package: error: some substitutes for the outputs of derivation `/gnu/store/cviappwxgh7ilhprl44x5ya2nypwlcj7-skopeo-1.17.0.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source 

You can see that networking worked initially, but broke down later on.

lrwxrwxrwx 1 root 0   70 Dec 23 18:24 protocols -> /gnu/store/bfp25w47fxn8z0fdwj45prx2609sx59j-net-base-5.3/etc/protocols

After running 'guix package -i skopeo' that symlink is danling:

++ echo '$ ls -ld /gnu/store/*net-base*'
++ ls -ld /gnu/store/bfp25w47fxn8z0fdwj45prx2609sx59j-net-base-5.3.lock /gnu/store/i705faz4w4wnq1frrbbrk2jnhwhsr2k9-net-base-5.3-builder /gnu/store/kaqyk1rn9f4q36h8nc0919wrlam0xl0g-net-base-5.3.drv
-rw------- 1 root 0   0 Dec 23 18:26 /gnu/store/bfp25w47fxn8z0fdwj45prx2609sx59j-net-base-5.3.lock
-r--r--r-- 1 root 0 893 Jan  1  1970 /gnu/store/i705faz4w4wnq1frrbbrk2jnhwhsr2k9-net-base-5.3-builder
-r--r--r-- 1 root 0 990 Jan  1  1970 /gnu/store/kaqyk1rn9f4q36h8nc0919wrlam0xl0g-net-base-5.3.drv
++ echo '$ ls -ld /gnu/store/*profile*'

I've reverted back to this hack:

cp -rL /gnu/store/*profile/etc/* /etc/

Is there a clean solution to this?  Perhaps we could debug further why
GitLab/docker barfs on a /etc symlink.  It is probably related to them
having these mount points:

/dev/sda1 /etc/hostname ext4 rw,nosuid,nodev,relatime,commit=30 0 0
/dev/sda1 /etc/hosts ext4 rw,nosuid,nodev,relatime,commit=30 0 0
/dev/sda1 /etc/resolv.conf ext4 rw,nosuid,nodev,relatime,commit=30 0 0

Maybe -S /etc=etc works if we make sure to remove just those three
files..

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

Re: Building a Docker image for GitLab-CI

[Simon Josefsson via]

[-- Attachment #1: Type: text/plain, Size: 6304 bytes --]

All,

Here are some updates about Guix container images for GitLab pipelines
or local podman usage.  I'm declaring this v1.0.

tl;dr: https://gitlab.com/debdistutils/guix/container

Final images are built from a pure Guix container now.  Everything is
done on public shared GitLab runners in the pipeline, no container
uploads.  Stage0 creates Debian+Guix that builds a pure Guix stage1
which builds the final Stage2 images.  The content of these images
appears to be reproducible, but alas the docker images itself aren't:
https://issues.guix.gnu.org/75090

No need for --disable-chroot in GitLab CI runs.  Local podman usage
ironically requires 'podman --privileged' if you want to avoid
--disable-chroot.  If someone can figure out which --cap-add are
sufficient, that would be nicer over --privileged.  Ultimately I think
'guix-daemon' should handle this, it is a desirable property to be able
to use chroot building inside a container.

I'm using small/medium GitLab runners.  It seems whatever 'guix' is
consuming resources for, it isn't helped by additional CPU nodes, disk,
or RAM.  Network bandwidth is improved by using guix from GitLab instead
of Savannah.  Maybe the bottleneck are the substitution servers?  Or
perhaps single-core CPU speed?  For stage1 [1], 1m52s is spent on 'guix
install skopeo' and 2m44s on 'guix pack'.  For stage2 [2], 1m35s is
spent on 'guix install nss-certs skopeo tar gzip' and 4m30s on 'guix
pack'.  Creating the stage0 debian+guix image is where the 'guix pull'
happens [3], and it takes around 35 minutes (I recall seeing runtimes
down to 25 minutes when I used larger nodes).

The 'latest' image with gcc, automake etc as a development environment
is around 400MB and the 'slim' image with minimal packages only is
183MB.  Does anyone how to optimize 'guix pack' output sizes?  Even the
'slim' image seems to have a lot of duplicated stuff [4].

There is a bunch of small nits, and if someone has ideas about
improvements that would be great!  See list of issues here:
https://gitlab.com/debdistutils/guix/container#known-quirks

Merry Christmas,
/Simon

[1] https://gitlab.com/debdistutils/guix/container/-/jobs/8723179887
[2] https://gitlab.com/debdistutils/guix/container/-/jobs/8723179903
[3] https://gitlab.com/debdistutils/guix/container/-/jobs/8723242065
[4] 'guix pack guix bash-minimal coreutils-minimal net-base' and
    doing cd /gnu/store; ls|sort -k1.33:

gd3s60nav0qhp8lxjj21ffynivwibfl5-avahi-0.8
3jhfhxdf6v5ms10x5zmnl166dh3yhbr1-bash-minimal-5.1.16
x47i4yafqxdav838aykda9c2hhhn9sa4-bash-minimal-5.1.16
87z5k84hxbqs87plgwsl2v6a4j7m3k7h-bash-static-5.1.16
56aq6sdx35f7rsxq8jq9ypafk0dhd3p3-bzip2-1.0.8
59kd6jyvrq8prl9mbnh3g8d22rc1dbwv-bzip2-1.0.8
qy1769103d15zh8gg09wlywfsyblham4-coreutils-minimal-9.1
vdaspmq10c3zmqhp38lfqy812w6r4xg3-curl-8.6.0
af6rfyb76j51g2m981a4r0747pvg3j7c-dbus-1.15.8
dnjwcdxmwma6fl7fvvn3p4frib7f5chl-disarchive-0.6.0
vb1rs3dk181ariczl0zqcmfjncjkrv0f-emacs-subdirs
faxgciaw9wxz8zyxk70f2pa3c5rr8al7-expat-2.5.0
zzpbp6rr43smwxzvzd4qd317z5j7qblj-gcc-11.4.0-lib
hdb3jmxa67zkh4wj0l6w9ga3gj84k1yc-gdbm-1.23
9ri7c2haj2q3f5p6859z64kjvrjyy5n6-git-minimal-2.46.0
zgsphhmliwgmjjv1czmbyjql3gk7ynsx-glib-2.78.0
zvlp3n8iwa1svxmwv4q22pv1pb1c9pjq-glibc-2.39
pxnrbpc30m5qsr8jqx86a9m42mzn25ni-glibc-utf8-locales-2.39
kka705681m1hq98b9jz98vxk9s5qd4ld-gmp-6.3.0
9mkcil1rl450r84hn1hcbny5pi5js8ig-gnutls-3.8.3
7k8b93779dqpwcg2qjdvnf4nl43jv7hf-grep-3.11
mfkz7fvlfpv3ppwbkv0imb19nrf95akf-guile-3.0.9
003k1369b9b35b7vgfzjqrc1iha555i2-guile-avahi-0.4.1
1myi8hwa0a3lf9qw14dkqckhv9ljpzp1-guile-bytestructures-1.0.10
rf9xg52fa4zpn9ywd9w4kczhib4ggfsq-guile-bzip2-0.1.0
2bmrqh4w9pcgns0pi3wwqasrshpmv8hw-guile-gcrypt-0.4.0
kcvbb34cv4p19sg3rmi2rrld03wyvhpb-guile-git-0.9.0
pgjyl3fn4sflk6xy63qd5anrhqwylpgw-guile-gnutls-4.0.0
711y2zrpg0ygxaghy72v8hzwla7mjaqg-guile-json-4.7.3
p7qx1yhxlz61r1hpcgdvdhqq343cryyp-guile-lib-0.2.8
02i9pa0yj18riq7g90bzx0jaxmlxnax4-guile-lzlib-0.3.0
n2jz9qnxf7ainkzsdjyl3d4x078g15lw-guile-lzma-0.1.1
nj1051ag55p7llr1wc0ml6hg08gk1prs-guile-semver-0.1.1
yhzifwp225x81i9d056xa2r11g5w40kd-guile-sqlite3-0.1.3
vhby2mrlf25flwx571bmnllccigb49ml-guile-ssh-0.18.0
7h0khqsyzz3ic8dwyfmbbr5404qkmm98-guile-zlib-0.2.1
i0fm4jrkgz6rxpcscd1sazx62fwhqd58-guile-zstd-0.1.1
pzghsxxfx5dll69ikhckissq3b38542z-guix-1.4.0-29.3032221
0r2fx1lr1h2i3cl1x5fw4s4ly95qspya-gzip-1.13
w9zl48a95kylc7a91rwrrk27v70my968-gzip-1.13
96lahq0x84fiaj341vzx0fw5h18iyq9q-http-parser-2.9.4-1.ec8b5ee
prf6y8cmysfdf6jys86ixcv1kdw4l2lf-info-dir
9vjs14mzxki1q857wc8jfhbfj06gvkcp-libcap-2.64
62xxxmgmpk6zhzdr1ciya6f572y75xkw-libdaemon-0.14
lqgg509yb3f85ck4k6l0qp7a70bz7daa-libevent-2.1.12
s6iqwc5sqjrk76kzslqc1n1wlcvfyqkw-libffi-3.4.4
pr73chdirm3jc2j7npc6hqzmcwjs7l8m-libgc-8.2.4
gfqifdfnfvnbksbm0w87fvq76138i8da-libgcrypt-1.10.1
ni0kk5ff3z8sdglksb3850c9w44a2zaj-libgit2-1.8.3
881qgylidmmx92jdv1wvkzjs858dw9cd-libgpg-error-1.47
7xizylh3gi6sj23nz19q6xhvx2d50wvr-libidn2-2.3.4
jcjm231n2g8mqs0w2pa85hv7l1nfi2qa-libpsl-0.21.1
085636515w3h03dp2fr7w3clsn3p2wj7-libssh-0.10.6
pr8xfc53m3fc6rx8jrfis1xz8jvbb53h-libssh2-1.10.0
b801mrqqcsnhbr34544mlfyanzg3skfx-libtasn1-4.19.0
zpaw3cp2k9jx36yhkpwra3jilfbb1mc7-libunistring-1.1
4775wjc2972kiwfsq710fv5pfzyc5laq-libx11-1.8.7
wxwv020jwxq9gr070vwy3fh8n028gwqg-libxau-1.0.10
y5a0l9a3z214yar8q7mznqqd4pnw0vvp-libxcb-1.15
q1vqb2hfclghbpl1vn094l1rzj12b6qb-libxcrypt-4.4.36
v712yc2mwkc10m1nzgjz3linnvl5i1dh-libxdmcp-1.1.3
40aa02d5xnxpi2w6dhlr4ldf1kir1wz2-lzlib-1.13
b9kfblvwd0xx5jr8zzvz4ypa0936jh6v-mit-krb5-1.20
7rsdf5kcqh0gl88av6nkgvgxg1ywvc5b-ncurses-6.2.20210619
bfp25w47fxn8z0fdwj45prx2609sx59j-net-base-5.3
al613p11xv5w1xmnqn7ykw0x6d4b0539-nettle-3.9.1
8i2kr43jfbqvhpv67hs8kgncj2kk19b6-nghttp2-1.58.0-lib
xc98v8v485rs704wb26mipb0y5npdl1z-openssl-3.0.8
cmzi8a17f44fvb55s77jd7d4r678w093-p11-kit-0.24.1
gwn3p1r5ghlapv9yjad0mk2n23la7j8z-pcre2-10.42
a3lsdsalcmg5wnk67869af7wljprkbam-pkg-config-0.29.2
bwfrm3dmm33lfr69r1h5jy24hj51ii23-profile
dl3665ynrp41ynyw2ay5kfqix93myj5d-readline-8.1.2
81wqxjgqfinrxxh473c89r1n7arxfv3s-sed-4.8
laj6a3z6gjza9f18kyxw1nz5211ghwfs-sqlite-3.39.3
j5zgzgsmbjgywr67r86h1n6s4qiabv5q-tar-1.34
2p8j6npwa2k59d8lbhlqzvffn0437x8l-util-linux-2.37.4-lib
70s4sq1hx1m5rmsg5bcnjxslwc8ppiag-xz-5.4.5
fbaw0sb21gv02qq7gs9wg5y5wlpdgzih-xz-5.4.5
1prv14v6jfnzzg7szm57690b7fr6sx33-zlib-1.3
m05g4pzw906bg2pydbl74vrnvkmi9rbj-zstd-1.5.2-lib

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]