Ludovic Courtès 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 . 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