Re: guix pull/guix upgrade often fails over VPN with TLS error message
Thom R Harmon writes: > Just closing the loop on this... > > So, nobody had any advice as to how to troubleshoot this and I stopped > looking for root cause and started looking for a fix of any sort. Turns > out that was to make sure nothing was using /gnu/store and then `rm -rf > /gnu/* /var/guix` and re-install guix. All of the nodes which were > exhibiting this behavior stopped doing so after a re-install. > > My only theory is that there is something I am doing when managing the > guix binary install that will occasionally result in the systems getting > into this state. Perhaps something to do with the TLS libs. I missed this email earlier, but FYI your issue sounds similar to https://issues.guix.gnu.org/71238. A root cause hasn't been identified there either. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Why are custom channels not available to guix repl?
Hi Tomas, > However when I start `guix repl' and try to use modules from those extra > channels, it does not work: I believe you're being hit with https://issues.guix.gnu.org/61343, "modules from channels is not available to "guix repl". As a workaround try ,use (gnu packages). That module has a destructive setter (%package-module-path I believe) that extends the load path. That should resolve your issue. Ideally the issue itself would be resolved of course. I believe a solution has been identified. There was a comment by Ludo regarding program name memoization that's beyond my understanding so I don't know what else needs to be done [1]. [1]: https://issues.guix.gnu.org/61343#12 -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: A Guix Home service to group together various email services
Fabio Natali writes: > Anything that you think I'm doing wrong here? Could it be a limitation > with 'home-msmtp-service-type', which doesn't seem to indicate any > mechanism for extend/compose? Yes, I believe that's your problem. I don't see a reason why home-msmtp-service-type shouldn't support being extended with additional accounts. I think it's worth a bug or (even better) a patch. I'm surprised it's possible to extend a service that doesn't support extensions. In my opinion we should throw an explicit error instead of silently ignoring the extension. I reported this as a bug [1]. > More generally, this way of aggregating services together in > 'my/home-email-service', does it look like a good pattern or should I do > things any differently? I find myself doing something similar in my config, although usually at a smaller scale (not for any particular reason, just how it works out). I think this is a good idea because your service is contained to one logical unit—email—and there's likely no reason you'd want to only include just one of the extensions in an environment. [1]: https://issues.guix.gnu.org/71887 -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Why rust-hyprland and rust-hyprland-macros but not HyprLand?
rust-hyprland is a cargo-input to rust-xremap. I'm sure a patch adding hyprland would be appreciated. :) -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: dhcp-client default gateway with multiple interfaces, race condition?
I managed to find an alternative that seems to work without disabling eth0 entirely or bloating my barebones server with NetworkManager. Connman. The configuration and the routing tables are much more complicated unfortunately, but it works. (Curiously I see a new IP in the routing table that never appeared before and doesn't seem to be related to anything beyond being owned by DigitalOcean. Oh well, at least the default route works.) While the cause of the problem isn't known, I can guess it's somehow related to ISC dhcp-client being EOL'd back in 2022. At some point we should consider deprecating it, particularly if issues like what I encountered become more common. (I also think any replacement should probably avoid being called "dhcp-client". Most other services don't name themselves according to their role, but the software.) -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: dhcp-client default gateway with multiple interfaces, race condition?
Hi Felix!
Felix Lechner writes:
> I believe the 'dhcp-configuration' is not quite sophisticated enough so
> you may have to use the config-file option and include this content:
>
> # Assign this interface an IP address only.
> # (This disables setting the gateway router, DNS, domain, etc.)
> interface "eth1" {
> request subnet-mask, broadcast-address, interface-mtu;
> }
>
> That idea came from here. [1] It could also be enough to use the
> 'nogateway' option as suggested in the link you posted already. [2]
Thanks for helping out! I think the existing code only supports
providing a config file to dhcpd (dhcp server), not dhcp-client (aka
dhclient, dhcp client).
I submitted a patch for specifying a dhclient config file just now in
dhcp-client-configuration [1]. Unfortunately while the patch itself
seems fine, the config file doesn't seem to have an effect in my case.
--8<---cut here---start->8---
# Problem still occurs if we run the command manually like this
$ dhclient -nw -I -pf /var/run/dhclient.pid \
-cf /gnu/store/blah-dhclient.conf
--8<---cut here---end--->8---
Annoyingly that nogateway option I mentioned seems to be a feature of
dhcpcd [2], which has no organizational relationship to dhclient or
dhcpd.
I have confirmed the issue is solved if I manually invoke dhclient,
don't provide a config file, and only specify eth0 as an interface. e.g.
--8<---cut here---start->8---
$ dhclient -nw -I -pf /var/run/dhclient.pid eth0
--8<---cut here---end--->8---
Curiously providing the config file causes the error to appear again
even if eth0 is the only interface provided at the command line.
Presumably the fact that the config file references eth1 is enough for
dhclient to scan it.
For completeness, this is the contents of dhclient.conf:
--8<---cut here---start->8---
# Assign this interface an IP address only.
# (This disables setting the gateway router, DNS, domain, etc.)
interface \"eth1\" {
request subnet-mask, broadcast-address, interface-mtu;
}
--8<---cut here---end--->8---
[1]: https://issues.guix.gnu.org/71561
[2]: https://github.com/NetworkConfiguration/dhcpcd
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
dhcp-client default gateway with multiple interfaces, race condition?
Hi Guix!
I'm having trouble where my virtual private server (VPS) [1] has
incorrect routing information configured. From a recovery console:
--8<---cut here---start->8---
root@droplet-base ~# ip route
default dev eth1
10.108.0.0/20 dev eth1 proto kernel scope link src 10.108.0.2
157.245.0.0/20 dev eth0 proto kernel scope link src
--8<---cut here---end--->8---
>From above, the default gateway isn't pointing towards the
internet-routable gateway (157.245.0.1). If I were to manually run $ ip
route replace default default via 157.245.0.1, I can reach public
addresses again (e.g. $ ping 8.8.8.8).
This error seems to occur randomly on reboot, maybe 4/5 times. My guess
is there is some sort of race condition in the DHCP configuration that
causes eth1 to be set as the default gateway.
I believe I could resolve this by changing dhcp-client-service-type to
--8<---cut here---start->8---
(service dhcp-client-service-type ;make droplet know its own ip
(dhcp-client-configuration
(interfaces '("eth0"
--8<---cut here---end--->8---
i.e. only listen on eth0 and give up on configuring the private IP range
on eth1 entirely. I haven't tested this to confirm yet, but will
shortly.
However, I don't want to remove the private IP range entirely. From what
I read, it may be possible to configure isc-dhcp to set "nogateway" for
a specific interface. However, it looks like this isn't possible in Guix
at present. Is there another method to resolve my issue? Or is my fancy
theory about race-conditions in dhcp configuration inaccurate and
something else is to blame?
Thanks.
[1]:
https://git.sr.ht/~freakingpenguin/rsent/tree/edde39fbb0585db243ac5369548867bbdc765fe8/item/rsent/system/digitalocean.scm
[2]: https://unix.stackexchange.com/a/333610
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Re: Guix system image record with a large root partition
Sergey Trofimov writes: > Building a full-sized disk image seems wasteful, especially for large > partitions. This hasn't been merged, but there was a patch proposed for a resize-fs-service that would resize the partition on boot. https://issues.guix.gnu.org/69090. Maybe worth taking a look at? -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Installing cross-compiled packages alongside a cross-compile toolchain
Hi Christoph!
Christoph Buck writes:
>> (define gcc-cross-aarch64-linux-toolchain
>> (let ((chain (cross-gcc-toolchain "aarch64-linux-gnu")))
>> (package
>> (inherit chain)
>> (native-search-paths
>>(package-search-paths
>> (lookup-package-input chain "gcc-cross-aarch64-linux-gnu"))
>>
>> (packages->manifest `(,gcc-cross-aarch64-linux-toolchain ,libpng))
>>
>> (define* (enable-cross-compilation entry system target)
>> (manifest-entry
>> (inherit entry)
>> (name (string-append (manifest-entry-name entry) "." system
>> (if target
>> (string-append "." target)
>> "")))
>> (item (with-parameters ((%current-system system)
>> (%current-target-system target))
>> (manifest-entry-item entry)))
>> (dependencies (if (not (null? (manifest-entry-dependencies entry)))
>> (map (lambda (dep) (enable-cross-compilation dep
>> system target))
>>(manifest-entry-dependencies entry))
>> '()
>>
>> (define (cross-build-package package)
>> (manifest (list (enable-cross-compilation (package->manifest-entry
>> package) "x86_64-linux" "aarch64-linux-gnu"
>
>> (concatenate-manifests (list (specifications->manifest '("cmake"))
>> (cross-build-package libpng)
>> (packages->manifest
>> `(,gcc-cross-aarch64-linux-toolchain
>
> From my rudimentary understanding of guile, this goes recursively
> through all manifest entries of the wrapped dependency and resets the
> `target` to "aarch64-linux-gnu". And indeed, this seems to work:
>
> Is this the correct way to set this up? Is there a simpler way? It is
> such a common problem and my solution looks rather complicated. Are
> there any insights and tips of people with similiar uses cases?
I also unfortunately don't know of a better solution. I'm not fluent
with how cross-compilation works in Guix, but I think it would be
valuable proposing this (or something like it) as a patch and/or
cookbook entry! It seems too useful to leave hidden away in the mailing
list. (I assume your inspiration was [1], but in my opinion this is
different enough in both context and content to deserve its own
section.)
The closest I can think of is wrapping your Guix software as a package
and using --target, but this is often too much of a barrier to entry
when all you want is a simple development environment. Anything making
cross-compilation easier is a good thing in my eyes.
[1]: https://guix.gnu.org/en/cookbook/en/guix-cookbook.html#Build-Manifest
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Re: Come speak at the Guix Social meetup
Ekaitz Zarraga writes: > I could talk about the bootstrapping in riscv, maybe it's too > technical or idk... > > If you want, I'm open to do it! > > Thanks for organizing these talks, they are very interesting. I'd /definitely/ find that talk interesting! Hope it happens and I can make it. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Installation issue on FrameWork laptop.
Pietro Mele writes:
> I am trying to install GNU Guix System on a new laptop (FrameWork 16, AMD
> Ryzen 7 7840HS).
> I am using this file:
> https://ftpmirror.gnu.org/gnu/guix/guix-system-install-1.4.0.x86_64-linux.iso
>
> At the beginning, I get this warning:
>
> Hardware support warning
> Devices not supported by free software were found on your computer:
> - 1002 15bf
>
> From that code it should correspond to my integrated GPU not being
> recognized. The reason could be that this APU was released after the
> currently available Guix version.
If the official installer runs, I imagine the installed image should at
least be functional enough to enter a terminal and run an update. You
probably do *not* need to do the following, but I'll mention it just in case:
One solution could be to generate a newer installer image instead of
starting on the 1.4.0 release and use this new image for the
installation. Ordinarily you'd be able to do so from
https://guix.gnu.org/en/download/latest/, but Cuirass seems to not
support downloading build outputs from a web browser for one reason or
another.
If you have an existing Linux system, you can install Guix on a foreign
distribution, ensure it's up-to-date via $ guix pull and $ guix
describe, then generate a new installation iso via $ guix system image
-e '(@ (gnu system install) installation-os)' --image-type=iso9660.
Again, probably not necessary.
> The installation process starts, and these are the last logs produced
> before the failure:
>
> ...
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%
> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'...
> 0.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%
> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'...
> 0.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%
> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'...
> 0.0%
> \builder for `/gnu/store/bwy...ilb-slock-1.4.tar.gz.drv' failed to produce
> output path `/gnu/store/la705...dqf-slock-1.4.tar.gz'
> *build of /gnu/store/bwy...ilb-slock-1.4.tar.gz.drv failed*
> View build log at '/var/log/guix/drvs/bw/...tar.gz.drv.gz'.
> building /gnu/store/br3c...CUnit-2.1-3.tar.bz2.drv...
> cannot build derivation `/gnu/store/256d...slock-1.4.tar.gz.drv': 1
> dependencies couldn't be built
> guix system: *error*: build of `/gnu/store/256d...slock-1.4.tar.gz.drv'
> failed
> Command ("guix" "system" "init" "--fallback"" "/mnt/etc/config.scm" "/mnt")
> exited with value 1
Can you post the output of the build log mentioned in those messages? I
assume the ... was added by you and the full path was printed, but if
not you should be able to get the path via $ guix build --log-file slock.
> View build log at '/var/log/guix/drvs/bw/...tar.gz.drv.gz'.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Re: Automated /etc/config.scm
> Sounds lovely, but I would need to construct a continuous integration > subsystem to be to able to use it. Having a CI server on my LAN building my operating systems regularly is very nice. It really speeds up system upgrades. Can recommmend, although it is challenging! > Now I really need to come up with a nice channel / distribution name. The > number of modules in my codebase is about to explode and I can already tell > that renaming them after the fact would be… painful and tedious. Yep, even if you try automation it definitely is painful to refactor! I wish I was a bit more creative with my channel before going "well it's my channel so... my name is fine". :) -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Automated /etc/config.scm
Hi Marek! > I have already built the infrastructure to host my configurations on my home > server. I would like now to ditch the configuration repositories' clones in > the home directories on my computers and rely entirely on the combination of > the system-wide channels (this I have implemented) and the /etc/config.scm > file. > > Is there a way to have 'guix pull' edit the /etc/config.scm file to mirror > the > designated system configuration file? I assume that any module imports are > handled by an existing guix infrastructure, because I had no need to use the > -L switch during reconfigurations for a while. The relevance of the below answer depends on if the contents of /etc/config.scm are tracked in your custom channel. If not, I misunderstood and feel free to disregard. :) If your channel includes the configuration files for the target machines and you are successfully adding those channels to the system, you could take advantage of Guix's -e flag. e.g. --8<---cut here---start->8--- $ guix system reconfigure -e '(@ (my-custom-channel machines this-machine) use-this-system)' --8<---cut here---end--->8--- This would reconfigure your system using the version of 'my-custom-channel' as described by $ guix describe. So run guix pull, then the above command, and you can skip needing to separately update clone of your channel in your home directory. You can even go one step further. When combined with unattended-upgrade-service-type [1] and embeddeding a "self-referential" channels.scm file in your configuration [2] (a channels.scm file that contains it's own repository), your systems would regularly reconfigure themselves using the newest versions of your channel machine configuration files. [1]: https://git.sr.ht/~freakingpenguin/rsent/tree/1b79ec8a91a9546d4cc158590b1d50145e5fe42a/item/rsent/machines/droplets/rampart.scm#L69 [2]: https://git.sr.ht/~freakingpenguin/rsent/tree/1b79ec8a91a9546d4cc158590b1d50145e5fe42a/item/rsent/configs/channel.scm#L13 -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: System image boots but fails to start essential shepherd services
I figured out my issue. It was a result of inheriting qemu-binfmt-service-type from lan-minimal-system. The problem occurs when qemu-binfmt is used with a target platform matching the target system. In my case, qemu-binfmt-service-type was emulating the aarch64 platform which also matched my target system. The issue is recorded at https://issues.guix.gnu.org/61986. IMO, a pseudo-bricked generation is a hefty price to pay for an oversight like this! :) -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
System image boots but fails to start essential shepherd services
Hi Guix!
I'm trying to generate a system image for an Arm SBC, flash the image to
an SD card, and run Guix on that SD card. The image does boot with the
help of an onboard UEFI bootloader, but Shepherd fails to start any
services.
I generated my image with this command:
--8<---cut here---start->8---
guix system image -L . rsent/machines/lan/caustic.scm --system=aarch64-linux
--8<---cut here---end--->8---
This is a minified version of the contents of caustic.scm:
--8<---cut here---start->8---
(define-public caustic-system
(operating-system
;; lan-minimal-system provides a few additional services on top of
%desktop-services
(inherit lan-minimal-system)
(kernel (customize-linux #:name "linux-libre-arm64-generic-guix"
#:linux linux-libre-arm64-generic
;; Enable QEMU support. Realistically this won't
;; be emulating anything, but enable it anyway
;; because lan-minimal-system uses QEMU and
;; won't boot without it due to the
;; file-system/proc/sys/fs/binfmt_misc shepherd
;; requirement.
#:configs '("CONFIG_BINFMT_MISC=m")))
(initrd-modules '()) ;Not needed with arm64-generic. Most of
;%default-initrd-modules are built in.
(file-systems (cons*
(file-system
(mount-point "/boot/efi")
(device (file-system-label "boot"))
(type "vfat"))
(file-system
(device (file-system-label root-label))
(mount-point "/")
(type "ext4"))
%base-file-systems
(define caustic-image-type
(image-type
(name 'caustic-efi)
(constructor (lambda (os)
(image
(inherit efi-disk-image)
(operating-system os)
(platform aarch64-linux)
(volatile-root? #f))
(define caustic-efi-image
(image
(inherit
(os+platform->image caustic-system aarch64-linux
#:type caustic-image-type))
(name 'caustic-efi-image)))
caustic-efi-image
--8<---cut here---end--->8---
I see many messages printed to the console like this (the specific file
being executed changes, but otherwise it's the same).
--8<---cut here---start->8---
[ 15.009930] shepherd[1]: exec of
"/gnu/store/zbsi8bm1vx2c2kpl7jrygdhylgvh6ny3-inetutils-2.3/libexec/syslogd"
failed: Too many levels of symbolic links
--8<---cut here---end--->8---
Before eventually Shepherd gives up:
--8<---cut here---start->8---
[ 46.107131] shepherd[1]: The following services could not be started in the
background: guix-daemon ssh-daemon avahi-daemon ntpd NetworkManager xorg-server
wpa-supplicant upower-daemon pam term-console elogind dbus-system nscd syslogd
console-font-tty6 console-fon
[ 46.107629] t-tty5 console-font-tty4 console-font-tty3 console-font-tty2
console-font-tty1.
--8<---cut here---end--->8---
Has anyone encountered this issue before? What could be causing this?
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Re: How does system-disk-image work with embedded-style boot loaders?
Richard Sent writes: > > Running fdisk on the image produces (emulated build due to > cross-compilation failures): > > gibraltar :( guix$ fdisk -l $(guix system image > gnu/system/images/pinebook-pro.scm --system=aarch64-linux) > Disk > /gnu/store/832w3d7dh2vdfdm2qdv5025w8sfm8zrl-pinebook-pro-barebones-raw-image: > 1.62 GiB, 1741840384 bytes, 3402032 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disklabel type: dos > Disk identifier: 0x > > Device > Boot Start End Sectors Size Id Type > /gnu/store/832w3d7dh2vdfdm2qdv5025w8sfm8zrl-pinebook-pro-barebones-raw-image1 > *18432 3402031 3383600 1.6G 83 Linux > > > I can't figure out where that 18432 offset is coming from. > ... > I may very well be missing something here, particularly with > interpreting the fdisk output. Well, I did figure out one thing. fdisk is giving the offset in sector size, NOT bytes. With a sector size of 512 bytes, the offset in bytes is 18432*512, or 9437184 bytes. This is what we expect. Yay. I still suspect u-boot is overwriting part of the root FS in this particular image. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Pytorch Versions
: warning: possibly unbound variable `python-pytorch2' ice-9/boot-9.scm:1685:16: In procedure raise-exception: error: python-pytorch2: unbound variable Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. --8<---cut here---end--->8--- If this didn't make sense, don't worry. I barely followed what I said and I very easily might have said something wrong. Generally speaking use $ guix repl if you want to ensure you're loading the same modules as $ guix describe. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: How does system-disk-image work with embedded-style boot loaders?
>> 2) install-rockpro64-rk3399-u-boot writes u-boot.itb at (* 16384 512),
>> or 8,388,608, past the 2^20 offset in the image type. (Likely not
>> coincidentally 8,388,608 / 8 = 1,048,576. I don't know what to make of this
>> because it feels weird that bytes are used in one situation while
>> another uses bits.)
>
> Hopefully this is just a bit of confusion, or some of the images are
> broken and nobody noticed!
>
> I would suggest to inspect the partition table of a generated image to
> confirm if there is an empty space or blank/reserved partition(s)
> falling in that range...
Hi Vagrant!
Thanks for the response! I looked at the code again and I did realize I
missed one thing regarding point 2. pinebook-pro-image-type isn't using
a 1,048,576 offset, but a 9,437,184 offset. There's a *9 I missed,
oopsie.
Alas, there's still some confusion. We place the u-boot.itb image at an
offset of 16384*512, or 8,388,608. When building the u-boot image—part
of the output from the u-boot-pinebook-pro-rk3399-2024.01 derivation
built as part of $ guix system image gnu/system/images/pinebook-pro.scm
--system=aarch64-linux—the u-boot.itb file is 1,089,024 bytes long. Our
raw image offset is system offset is 9 * 2^20, or 9,437,184 (AKA 9 MiB).
So that means writing a 1,089,024 byte image to 8,388,608 spills over to
9,477,632. This is beyond the 9 MiB offset, so our u-boot image should
be overwriting the root FS.
Running fdisk on the image produces (emulated build due to
cross-compilation failures):
--8<---cut here---start->8---
gibraltar :( guix$ fdisk -l $(guix system image
gnu/system/images/pinebook-pro.scm --system=aarch64-linux)
Disk
/gnu/store/832w3d7dh2vdfdm2qdv5025w8sfm8zrl-pinebook-pro-barebones-raw-image:
1.62 GiB, 1741840384 bytes, 3402032 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x
Device
Boot Start End Sectors Size Id Type
/gnu/store/832w3d7dh2vdfdm2qdv5025w8sfm8zrl-pinebook-pro-barebones-raw-image1 *
18432 3402031 3383600 1.6G 83 Linux
--8<---cut here---end--->8---
I can't figure out where that 18432 offset is coming from. Also, based
on the genimage configuration used to create this image, I'd expect at
least two partitions:
--8<---cut here---start->8---
;; /gnu/store/2ah9p62crpar2iq2jcni85i4fz4yx9x4-genimage.cfg
image image {
hdimage {
partition-table-type = "mbr"
}
partition GNU-ESP {
partition-type = 0xEF
image =
"/gnu/store/d8irqwcay0w1wm54l1ydrs3kp6vcdd1a-partition.img"
offset = "1048576"
bootable = "false"
}
partition Guix_image {
partition-type = 0x83
image =
"/gnu/store/823mxbjirpcqgjkybkq60vc34p6nc218-partition.img"
offset = "0"
bootable = "true"
}
}
--8<---cut here---end--->8---
I do find it surprisingly we split "generate base image with genimage"
and "copy bootloader into base image" into different steps. From what I
see at https://github.com/pengutronix/genimage genimage is entirely
capable of placing the bootloader itself. Perhaps there is some value in
reworking the direct bootloader installers (mostly u-boot I think?) to
use genimage.
--8<---cut here---start->8---
;; example from README
partition bootloader {
in-partition-table = false
offset = 0
image = "/path/to/bootloader.img"
}
--8<---cut here---end--->8---
If we are indeed deleting part of our Linux partition due to an overly
large u-boot image (perhaps the image grew over time?), having genimage
be in charge of copying both the partition images AND the bootloader
file would presumably catch that error. At least, I assume genimage
performs those kinds of sanity checks.
I may very well be missing something here, particularly with
interpreting the fdisk output. Sorry if I didn't make sense. This stuff
is hard! :)
I haven't even started looking into what, if any, logic is done on the
Guix side for u-boot to find the Linux kernel. Spooky. 👻
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
How does system-disk-image work with embedded-style boot loaders?
Hi Guix!
I'm a bit confused as to how a system image is generated when certain
bootloader types are used. For example, rockpro64-rk3399-u-boot.
In (gnu bootloader u-boot) install-rockpro64-rk3399-u-boot has this
definition:
--8<---cut here---start->8---
(define install-rockpro64-rk3399-u-boot
#~(lambda (bootloader root-index image)
(let ((idb (string-append bootloader "/libexec/idbloader.img"))
(u-boot (string-append bootloader "/libexec/u-boot.itb")))
(write-file-on-device idb (stat:size (stat idb))
image (* 64 512))
(write-file-on-device u-boot (stat:size (stat u-boot))
image (* 16384 512)
--8<---cut here---end--->8---
Which makes sense. The onboard ROM bootlaoder looks for u-boot at a
specific offset in flash and loads that.
However, I don't understand how we "orchestrate" that with the rest of
the system image to avoid a collision.
At the end of system-disk-image in (gnu system image), we have this:
--8<---cut here---start->8---
(let* ((image-name (image-name image))
(name (if image-name
(symbol->string image-name)
name))
(format (image-format image))
(substitutable? (image-substitutable? image))
(builder
(with-imported-modules*
(let ((inputs '#+(list genimage coreutils findutils qemu-minimal))
(bootloader-installer
#+(bootloader-disk-image-installer bootloader))
(out-image (string-append "images/" #$genimage-name)))
(set-path-environment-variable "PATH" '("bin" "sbin") inputs)
(genimage #$(image->genimage-cfg image))
;; Install the bootloader directly on the disk-image.
(when bootloader-installer
(bootloader-installer
#+(bootloader-package bootloader)
#$(root-partition-index image)
out-image))
(convert-disk-image out-image '#$format #$output)
(computed-file name builder
#:local-build? #f ;too I/O-intensive
#:options `(#:substitutable? ,substitutable?)))
--8<---cut here---end--->8---
>From what I can tell this is a 4 step process.
1. Generate a genimage.cfg file via image->genimage-cfg. This does not
appear to take the bootloader into account.
2. Call genimage in (gnu build image) to create the image defined in the
genimage.cfg file.
3. use bootloader-installer to write directly into the image file that
was just created. In this case we write two files at specific offsets.
4. Convert the raw disk image into the desired output format.
How do we avoid "screwing up" the image by writing directly to the
image? What stops genimage from putting important data there that gets
overwritten in step 3? Is it just coincidence? A convention in the image
file to leave a large amount of space at the beginning? Some other
factor? What if another embedded board uses a different offset that
genimage does happen to use?
I'm *guessing* that the answer lies in the image type and
raw-with-offset-disk-image function, but I'd appreciate any
clarification on this! I see that pinebook-pro-image-type, which also
uses Pine64's rk3399 SoC has an offset of 2^20, or 1,048,576. However
1) There isn't a rockpro64-image-type, only a pinebook-pro-image-type.
Why only have one image type but two bootloaders?
2) install-rockpro64-rk3399-u-boot writes u-boot.itb at (* 16384 512),
or 8,388,608, past the 2^20 offset in the image type. (Likely not
coincidentally 8,388,608 / 8 = 1,048,576. I don't know what to make of this
because it feels weird that bytes are used in one situation while
another uses bits.)
Appreciate any clarification on this!
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Re: Cuirass: Could not find repository
Roman Scherer writes: > Hello Guix, > > I'm trying to run a Cuirass server for my channels. I have setup > Cuirass and can build packages in my channels. So far so good. > > What I would like to do next is to build a manifest with my channel > and my modified version of the Guix channel that contains patches that > aren't upstreamed. > Do you have any ideas what the problem could be? > > Thanks, Roman. > If it's of any help, I noticed that when I ran $ guix time-machine -C channels.scm -- describe, where channels.scm contains: --8<---cut here---start->8--- ;; channels listed in "images" specification (list (channel (name 'guix) (url "https://github.com/asahi-guix/guix.git";) (branch "main") (introduction (make-channel-introduction "f802d404b7229704190c821f89afd987be6a6905" (openpgp-fingerprint "D226 A339 D8DF 4481 5DDE 0CA0 3DDA 5252 7D2A C199" (channel (name 'asahi) (branch "main") (url "https://github.com/asahi-guix/channel.git";) (introduction (make-channel-introduction "3eeb493b037bea44f225c4314c5556aa25aff36c" (openpgp-fingerprint "D226 A339 D8DF 4481 5DDE 0CA0 3DDA 5252 7D2A C199") --8<---cut here---end--->8--- I got the following error: --8<---cut here---start->8--- building /gnu/store/29gmxzgpabwlqygcjy1l4wxgjkph5qhi-asahi.drv... /builder for `/gnu/store/29gmxzgpabwlqygcjy1l4wxgjkph5qhi-asahi.drv' failed to produce output path `/gnu/store/mi8c5dgwiznqwyxcsk0pwnm2a4x52m5g-asahi' build of /gnu/store/29gmxzgpabwlqygcjy1l4wxgjkph5qhi-asahi.drv failed View build log at '/var/log/guix/drvs/29/gmxzgpabwlqygcjy1l4wxgjkph5qhi-asahi.drv.gz'. --8<---cut here---end--->8--- And the log: --8<---cut here---start->8--- (repl-version 0 1 1) WARNING: (asahi guix system desktop): imported module (gnu services) overrides core binding `delete' (exception %exception (non-self-quoting 140736755930640 "#<&compound-exception components: (#<&error-location location: #< file: \"/gnu/store/bny0sjiy9cixb8ghhsirlgjkmxf1z001-channel-f020a1a/src/asahi/guix/system/desktop.scm\" line: 96 column: 2>> #<&formatted-message format: \"modify-services: service '~a' not found in service list\\n\" arguments: (sddm)>)>")) --8<---cut here---end--->8--- My guess is that's because %desktop-services only conditionally includes sddm-service-type depending on %current-target-system or %current-system. See (gnu services desktop). And yet %gnome-desktop-services unconditionally deletes it. https://github.com/asahi-guix/channel/blob/main/src/asahi/guix/system/desktop.scm Perhaps that's relevant, perhaps it's not. I could see it potentially causing odd behavior, although I can't see how it connects to the error you observed. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Validating an entire record-type* at value creation
Hi Guix! Does define-record-type* support creating a validator/sanitzer that validates the entire record during creation? I know you can create sanitzers for individual fields (example below from the docstring). --8<---cut here---start->8--- A field can also have an associated \"sanitizer\", which is a procedure that takes a user-supplied field value and returns a \"sanitized\" value for the field: (define-record-type* thing make-thing thing? this-thing (name thing-name (sanitize (lambda (value) (cond ((string? value) value) ((symbol? value) (symbol->string value)) (else (throw 'bad! value))) --8<---cut here---end--->8--- I think it would be valuable to validate fields in relation to each other. For example, verifying that mutually exclusive fields aren't all set to #t. However before I actually open this as a bug or post about it on guix-devel I want to check if such a thing already exists. Or if there's an equivalent method to achieve a similar result that's already used in the code. I imagine in general we don't want too many records that can have mutually exclusive fields. However, (I believe) that already exists in the current code base. For example, the file-system record has both needed-for-boot? and dependencies, but if mount-at-boot? is set dependencies is ignored. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Replication question
Hi Mauritz Mauritz Stenek writes: > Suppose you have these packages in your environment: > >A@old >B >C > > where `A` is pinned to the `old` version, which is not in the latest > channel versions -- as per `guix describe`; the latest versions of > both `B` and `C`, however, are in the latest channel versions but > *not* in the channel versions where `A@old` is defined. > > How, then, is this environment replicable without some hacky > gymnasitcs? > > What am I missing? Your hunch is corect. Without knowing the Guix commit that the environment/profile was built with, you would not be able to reproduce the profile exactly. There's two options I know of: 1. Guix time-machine. e.g. guix time-machine --commit=XXX -- package -m manifest.scm a. This will create a profile containing the exact packages at that moment in time, including A@old. b. All packages will be at whatever version the corresponding Scheme package variable is at for that commit. See (info "(guix) Invoking guix time-machine"). Probably not the best idea to use long term. 2. Inferiors. This provides a mechanism for mixing and matching A@old from commit XXX with packages B and C from commit YYY. See (info "(guix) Inferiors"). a. To my knowledge this won't replace dependencies for B or C if they depend on A@old. B and C would use the "primary" channel's A. You probably could modify B and C to replace A with A@old though. As you saw, A@old doesn't have any fancy logic for "go back to the most recent Guix commit that has A@old". It's just a convenient way to specify which version of package A to install when multiple are packaged. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: hurd-vm-service-type into /etc/config.scm
Hubert, Your issue is in your operating-system services field. In the backtrace: --8<---cut here---start->8--- In procedure append: Wrong type argument in position 2 (expecting empty list) #< type: #8--- You have several services outside of the (list) call, so you're basically running --8<---cut here---start->8--- (append (list (service-1 service-2) service-3 service-4 %desktop-services)) --8<---cut here---end--->8--- Append only takes lists as arguments. %desktop-services is a list, but bluetooth service and hurd-vm service are not. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: add shepherd requirement to an existing service?
If this winds up being something you do frequently, it may be possible
to write a function to modify the service type. See [1] as an example. I
suspect your code would be smaller, something like
--8<---cut here---start->8---
(define (depend-on type new-requirement)
"Returns a @code{service-type} record derived from @var{type} with any
shepherd extensions additionally depending on @var{new-requirement}."
(service-type
(inherit type)
(extensions
(map (lambda (extension)
(let ((target (service-extension-target extension))
(compute (service-extension-compute extension)))
(if (eq? target shepherd-root-service-type)
(service-extension shepherd-root-service-type
(lambda (config)
(map (lambda (service)
(shepherd-service
(inherit service)
(requirement
(cons*
new-requirement
(shepherd-service-requirement
config)
(compute config
extension)))
(service-type-extensions type)
--8<---cut here---end--->8---
This code might not be it exactly, but something similar to this
/should/ work.
[1]
https://git.sr.ht/~freakingpenguin/rsent/tree/master/item/channel/rsent/utils/services.scm
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Re: catch2-3.5.1.drv fails to build with home reconfigure, but succeeds with build
So I was wrong and it turned out to be a mainline bug, but one that was only present on x86 32-bit. Here's the reports: https://gitlab.com/nonguix/nonguix/-/issues/307 https://issues.guix.gnu.org/68429 https://github.com/catchorg/Catch2/issues/2796 -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Help with channel build system and package
Jesse, I expect your issue is you have an extra gexp in build-system/crosstool-ng.scm, line 71. I determined this by: 1. Examining the derivation Guix is trying to build 2. Examining the -builder file mentioned in the derivation 3. Observe that ct-ng-riscv64-unknown-elf-1.26.0-builder wraps (crosstool-ng-build ...) in (gexp). The package still did not build locally on my machine after removing it, but it seems to have progressed to a further stage. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Builder error on package build
Pablo Martinez writes: > builder for > `/gnu/store/x4p1bry8c5lakzjv1bs4jb118dlj2j0g-openfortivpn-webview-1.2.0.drv' > failed to produce output path > `/gnu/store/2r3mk9rh3ycyc905c30bwdj0xvqnpcjg-openfortivpn-webview-1.2.0' > > Here's the https://pastebin.com/vgtKBKAi and here's the > https://pastebin.com/i3LvZ4cp. Hi Pablo! I'm not familiar with qmake, but according to https://stackoverflow.com/a/18158261 QMAKE uses DESTDIR, not PREFIX, for placing installation files. I found that your package built with this configure step replacement: --8<---cut here---start->8--- (replace 'configure (lambda* (#:key outputs #:allow-other-keys) (invoke "qmake" "." (string-append "DESTDIR=" (assoc-ref outputs "out") --8<---cut here---end--->8--- i.e. DESTDIR=, not PREFIX=. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Cuirass custom jobs module syntax?
Hi all,
I'm trying to build operating-system declarations as part of a LAN
substitute server, but I can't seem to get Cuirass's custom build type
working.
My Cuirass specification looks like this:
--8<---cut here---start->8---
(define %rsent-cuirass-specs
#~(list (specification
(name "rsent-systems")
;; TODO: Find out option here to build operating-systems
;; (not images) in rsent channel.
(build '(custom (rsent machines lan gibraltar)))
(channels
(cons #$rsent-channel-gexp
%default-channels)
--8<---cut here---end--->8---
gibraltar has code that looks like
--8<---cut here---start->8---
(define-module (rsent machines lan gibraltar)
;; ...
#:export (cuirass-jobs))
(define* (gibraltar-jobs store systems #:key source commit)
(map (lambda (system)
(let ((name (string->symbol
(string-append "gibraltar." system
(deriviation->job name
(operating-system-derivation
gibraltar-system))
(define (cuirass-jobs store arguments)
"Register Cuirass jobs."
(define systems
(arguments->systems arguments))
;; Turn off grafts. Grafting is meant to happen on the user's machines.
(parameterize ((%graft? #f))
(gibraltar-jobs store systems)))
--8<---cut here---end--->8---
When Cuirass evaluates the specification, this error is printed in the
logs:
--8<---cut here---start->8---
;; building path(s) `/gnu/store/9rpjz153hxfknlmywyipxcz5yaiag8nw-profile'
;; In thread:
;; uncaught throw to %exception: (#<&inferior-exception arguments:
(wrong-type-arg "symbol->string" "Wrong type argument in position ~A (expecting
~A): ~S" (1 "symbol" (rsent machines lan gibraltar)) ((rsent machines lan
gibraltar)))
;; inferior: #
;; stack: ((#f ("ice-9/boot-9.scm" 1779 13))
;;(raise-exception ("ice-9/boot-9.scm" 1682 16))
;;(raise-exception ("ice-9/boot-9.scm" 1684 16))
;;(symbol->string (#f #f #f))
;;(try-module-autoload ("ice-9/boot-9.scm" 3526 15))
;;(#f ("ice-9/boot-9.scm" 3252 13))
;;(#f ("ice-9/threads.scm" 389 8))
;;(resolve-interface ("ice-9/boot-9.scm" 3326 17))
;;(#f ("gnu/ci.scm" 559 27))
;;(map1 ("srfi/srfi-1.scm" 585 17))
;;(append-map ("srfi/srfi-1.scm" 672 15))
;;(map1 ("srfi/srfi-1.scm" 585 17))
;;(append-map ("srfi/srfi-1.scm" 672 15))
;;(cuirass-jobs ("gnu/ci.scm" 499 4))
;;(#f ("ice-9/eval.scm" 158 9))
;;(with-exception-handler ("ice-9/boot-9.scm" 1751 10))
;;(call-with-prompt ("ice-9/boot-9.scm" 723 2))
;;(#f (#f #f #f))
;;(#f ("guix/repl.scm" 98 21))
;;(with-exception-handler ("ice-9/boot-9.scm" 1751 10))
;;(with-exception-handler ("ice-9/boot-9.scm" 1746 15))
;;(#f ("guix/repl.scm" 125 7)))>)
--8<---cut here---end--->8---
I assume it's angry that my list of symbols isn't a symbol, ergo it
can't convert it into a string. However, if I take the code from
guix/ci.scm:555 and run it, the module does resolve successfully.
--8<---cut here---start->8---
;; This runs just fine. Code taken from cuirass-jobs in guix/ci.scm:555
(use-modules
(srfi srfi-1)
(ice-9 match))
(let ((subset '(custom (rsent machines lan gibraltar
(match subset
(('custom . modules)
;; Build custom modules jobs only.
(append-map
(lambda (module)
(let ((proc (module-ref
(resolve-interface module)
'cuirass-jobs)))
proc ;no store for testing, just return proc if found
))
modules
--8<---cut here---end--->8---
Why would (resolve-interface) work with (rsent machines lan gibraltar)
in one setting but not in another? Running Guix pull locally with the
same channel list works just fine, although the hash of the output
profile is different for reasons I don't understand.
Just for funsies I did try double quoting, e.g. '(custom '(rsent
machines lan gibraltar)), but that didn't help.
Appreciate any help or examples on this!
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
(current-module) and gexp, fighting for pretty code
Hi Guix! I have a setup where my operating system configurations are hosted in a custom channel in dedicated modules, and I'm trying to get unattended-upgrade-service working "cleanly" with it. At present, I have an operating system that looks like --8<---cut here---start->8--- (define-module (rsent machines droplets droplet-rampart) ;; ... #:export (droplet-rampart-system)) (define droplet-rampart-system (operating-system (inherit base-system) (services (cons* ;; ... (service unattended-upgrade-service-type (unattended-upgrade-configuration ;; ... (operating-system-expression ;; This way the operating-system itself will update, ;; not just imports #~(@ (rsent machines droplets droplet-rampart) droplet-rampart-system (operating-system-user-services base-system) --8<---cut here---end--->8--- I'm trying to rewrite operating-system-expression to remove the duplicate list of symbols, i.e. '(rsent machines droplets droplet-rampart). I found that --8<---cut here---start->8--- (operating-system-expression #~(module-variable #$(module-name (current-module)) 'droplet-rampart-system)) --8<---cut here---end--->8--- /nearly/ works, but (current-module) refers to (guile-user), not (rsent ...), in the generated unattended-upgrades.scm file. I did find if I wrote --8<---cut here---start->8--- (define module (current-module)) ;; ... #~(module-variable #$(module-name module) 'droplet-rampart-system) --8<---cut here---end--->8--- The correct module name is used. However, this feels inelegant and I'd rather just deal with the (admittedly very minor) module name duplication. Presumably the references ungexp captures are "module independent", for lack of a better phrase, and are evaluated after we already left the module. Ergo, capturing a reference to the current module /function/ is meaningless, since the function will evaluate outside the scope of the module I want to capture. Is there a way I can have the best of both worlds? No module name duplication and no extra variable creation? Some preexisting magical variable I can capture that refers to the module I am currently in? -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Using gexps in wireguard-service-type postup
Clément Lassieur writes:
On 2024-01-28 09:04, Clément Lassieur wrote:
> Hi Richard,
> which would be se same as
>
> (private-key #~(string-append #$sudo "/bin/sudo -u user <(pass ...)"))
Thanks. I made some progress with this, although I wound up hitting
another hurdle with the preshared-key.
When setting private-key, the following works fine:
--8<---cut here---start->8---
(private-key
#~(string-append "<("
#$sudo "/bin/sudo" " -u richard "
#$password-store "/bin/pass ls "
#$wireguard-nickleslan-private-key-key
")"))
--8<---cut here---end--->8---
preshared-key, unfortunately, doesn't follow that same pattern. When
setting preshared keys with the following snippet:
--8<---cut here---start->8---
(wireguard-peer
...
(preshared-key
#~(string-append "<("
#$sudo "/bin/sudo -u richard "
#$password-store "/bin/pass ls "
#$wireguard-nickleslan-preshared-key-key
")")))
--8<---cut here---end--->8---
I wind up with a wireguard.conf file with the following line.
--8<---cut here---start->8---
PostUp =
/gnu/store/4cnl0h79zc599xryr5jh66d7yq643zk4-wireguard-tools-1.0.20210914/bin/wg
set %i private-key
<(/gnu/store/gnybfg31is632dyaivd907f2h0wff80d-sudo-1.9.14p3/bin/sudo -u richard
/gnu/store/ppd5qmx2b5fadjhww65xw09zkjphll6r-password-store-1.7.4/bin/pass ls
System/WireGuard/NicklesBread/private.key) peer
EHoPXGJvQVVpQ6PZ/XQtHx0p5FWEVCS3y2oI2O+Y9zo= preshared-key (string-append <(
/gnu/store/gnybfg31is632dyaivd907f2h0wff80d-sudo-1.9.14p3 /bin/sudo -u richard
/gnu/store/ppd5qmx2b5fadjhww65xw09zkjphll6r-password-store-1.7.4 /bin/pass ls
System/WireGuard/NicklesBread/preshared.key ))
--8<---cut here---end--->8---
Emphasis on how everything after preshared-key is a Lisp sexp, not
evaluated output. I'm guessing this is because in gnu/services/vpn.scm,
the relevant code is
l
--8<---cut here---start->8---
(format #f "PostUp = ~a set %i private-key ~a\
~{ peer ~a preshared-key ~a~}" #$(file-append wireguard "/bin/wg")
#$private-key '#$peer-keys)
--8<---cut here---end--->8---
Peer keys is quoted immediately before the ungexp. I'm curious why that
would be done and how I can get preshared-key set correctly.
I did try changing preshared-key to (preshared-key #~,(...)), but that
didn't accomplish anything besides creating a wireguard.config file with
`preshared-key (unquote (string-append ...))` I assume this is because a
quote (') is used instead of a quasiquote (`).
Is there anything on my end I can do to fix this or does it have to be
resolved in Guix proper?
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Using gexps in wireguard-service-type postup
Hi all,
I'm trying to create a wireguard service, but I've encountered an issue
that I'm pretty sure I can only resolve using gexps and am having
trouble with the syntax (or if it's even possible to use them in this
case).
I want to fetch my private key from password-store when running the
service, and a PostUp command seems the best way of implementing
that. Using the wg-quick manual as a base, I get a naive solution like:
--8<---cut here---start->8---
(define* (get-secret-command key #:optional (user (sudo-user)))
"Returns the shell command needed to read KEY from USER."
(string-append "sudo -u " user " pass ls " key))
(service wireguard-service-type
(wireguard-configuration
...
(post-up (list
;; Returns "wg set wg-nickleslan private-key <(sudo pass
;; ls wireguard-nickleslan-private-key-key)"
(string-append "wg set " interface " private-key <("
(get-secret-command
wireguard-nickleslan-private-key-key) ")")
(string-append "wg set " interface " peer "
wireguard-nickleslan-public-key
" preshared-key <("
(get-secret-command
wireguard-nickleslan-preshared-key-key) ")")
--8<---cut here---end--->8---
Running `sudo herd start wireguard-wg-nickleslan` and checking
`/var/log/messages` shows an pretty unambiguous error, `error: sudo
not found`.
Presumably I need to use the full /gnu/store/...-sudo/bin/sudo path,
which (I think) can be done using gexps and (file-append sudo
"/bin/sudo"). However, I'm not quite sure how to go about it, in part
since I'm moving all the responsibility for key->secret collection to
(get-secret-command), which seems to make things harder.
I /think/ I need to
a) modify (get-secret-command) to return a gexp
b) replace sudo and pass with ungexp'd file-append calls. #$(file-append
...)
c) gexp the (string-append) calls in post-up
d) ungexp the (get-secret-command) calls
This exact process causes a string representation of the gexp to be
printed to the postup command in wg-nicklesbread.conf, e.g. `PostUp =
#`.
I'm /guessing/ this is because post-up is assumed to be a string and not
a gexp, although I can see there is some ungexp-splicing going on so
maybe not? (In gnu/services/vpn.scm:wireguard-configuration-file) I only
really have a vague understanding of gexps in isolation so this is
starting to get a bit over my head. It really feels like there should be
a solution here, but I can't quite parse the vpn.scm code to figure it
out.
I'd appreciate any help on this!
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Re: Make a simple guile script to a package - source local file
Théo Tyburn writes: > Hi again, > > Now I want to package a python script that has some dependencies on > python packages. > > How do I go about packaging it to make the script available from the command > line > without polluting the environment with the dependencies ? I am looking > for a similar effect to running `guix shell python python-a python-b > python-c -- my_script.py` but without re-entering the profile env all > the time. Probably I could achieve this by making a profile and launch > my script from a bash file that sources the profile beforehand, but this > seems tedious. I would like to automate all this, in guile. > Depending on what you mean by polluting or re-entering the profile information all the time this might not be what you want. When I write scripts that rely on specific dependencies I don't want to permanently install, I write the shebang like this: --8<---cut here---start->8--- #!/usr/bin/env -S guix shell ruby ruby-colorize password-store -- ruby --8<---cut here---end--->8--- This relies on /usr/bin/env supporting -S, which to my understanding isn't POSIX but instead a coreutils extension. Pretty sure --container would work here but I've not tried it. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
Re: Guix Shepherd Service Help
On 2024-01-19 10:23, samuel@thewilley.family wrote:
Any help would be nice, I've been smashing my head into the wall for a
few days as I feel this is required for my usage of Emacs. I'm not sure
why anyone would want this, but the relevant channels.scm snippet will
be in the readme.md of the same repository. I'm not entirely sure why
it doesn't work, running the command by hand using sudo just works.
Would somehow "dynamically" creating the yaml with path included work?
I would prefer if there could be preservation of using a yaml that
isn't statically generated.
I can't help you with the service issue, but if you're running Guix
System take a look at `keyboard-layout`. i.e. (keyboard-layout "us"
#:options '("ctrl:nocaps"))
Re: guix.scm and manifest.scm environment
On 2024-01-09 09:45, jgart wrote: Hi Guixers, Are the modules that are automatically pulled in to a guix.scm or manifest.scm documented? Those files are just scheme code but specifications->manifest is available in the global namespace, for example. Note that guix repl manifest.scm will fail due to an unused import. This is special magic when passing a manifest with -m. Their presence seems to be from how load-manifest in environment.scm works. https://www.gnu.org/software/guile/manual/html_node/Loading.html. See that it uses load*, not load, creating a temporary module with the (guix profiles) and (gnu) modules loaded. We can confirm this with (display (module-uses (current-module))) (force-output) at the top of the manifest. Everything in those two modules is in scope. Similarly, since (gnu) re-exports all (gnu ...) public modules (see gnu.scm), the (gnu packages) module is in scope, so we have specifications->manifest. I definitely wouldn't rely on this behavior, but that's my understanding of it. Didn't notice any documentation. Richard Sent
Re: catch2-3.5.1.drv fails to build with home reconfigure, but succeeds with build
On 2024-01-10 18:35, Richard Sent wrote: When reconfiguring my home environment, y8sll1zarpy78qi6fgrz9xrpx99hhn3b-catch2-3.5.1.drv fails to build. I can run $ guix build catch2@3.5.1 just fine, but the derivation has a different checksum from when I'm building with home reconfigure (2bdvrgwwbrgzxlpckmzsgwrakf8j6yic-catch2-3.5.1.drv). My build error log (largely) matches Curaiss's failure for the i686 build (https://ci.guix.gnu.org/build/3220178/log), but I'm on x86_64. I attached the log and the two derivations to this email. Clearly home is adding stuff to the y8sll derviation, but I'm not entirely sure why or how. The only path forward I can see is remove packages from home until it builds again, but having greater insight into what's going on would be a huge help. This problem occurs on multiple machines. Guix version: 3bf2465faa85b8a14b1cedaad43e2c2d0337cf6b Appreciate any help! Richard Sent Update: Traced the problem back to a package outside Guix's channel failing to build when catch2 was upgraded from 3.4.0 to 3.5.1. Issue was opened in the appropriate place.
catch2-3.5.1.drv fails to build with home reconfigure, but succeeds with build
When reconfiguring my home environment,
y8sll1zarpy78qi6fgrz9xrpx99hhn3b-catch2-3.5.1.drv fails to build. I can
run $ guix build catch2@3.5.1 just fine, but the derivation has a
different checksum from when I'm building with home reconfigure
(2bdvrgwwbrgzxlpckmzsgwrakf8j6yic-catch2-3.5.1.drv).
My build error log (largely) matches Curaiss's failure for the i686
build (https://ci.guix.gnu.org/build/3220178/log), but I'm on x86_64.
I attached the log and the two derivations to this email. Clearly home
is adding stuff to the y8sll derviation, but I'm not entirely sure why
or how.
The only path forward I can see is remove packages from home until it
builds again, but having greater insight into what's going on would be a
huge help.
This problem occurs on multiple machines.
Guix version: 3bf2465faa85b8a14b1cedaad43e2c2d0337cf6b
Appreciate any help!
Richard SentDerive([("out","/gnu/store/fjd0s86602rkpcnb5nqg14fii1acgkcn-catch2-3.5.1","","")],[("/gnu/store/0msh2nnjd8s8i2d02jp308vi860a45bv-glibc-2.35.drv",["out","static"]),("/gnu/store/2glj1zmm7fi68xrrnz9h1b5kh83fga4l-catch2-3.5.1-checkout.drv",["out"]),("/gnu/store/2i5yvimla3m7jkzj9xhy0s97ymq1lsdz-ld-wrapper-0.drv",["out"]),("/gnu/store/3m1dqj8vvxll8vvn21y2rcbrc1mig98z-bash-minimal-5.1.16.drv",["out"]),("/gnu/store/49xa73anq8qrjhis332wlg7ihnf8n87k-glibc-utf8-locales-2.35.drv",["out"]),("/gnu/store/4zsr2cgr99i13sbajv74z10kaw72jrnv-make-4.3.drv",["out"]),("/gnu/store/5r1zr3bkxpcqspif1b1cs6sp58kycq8b-python-3.10.7.drv",["out"]),("/gnu/store/7pvpcxxlsy9ld2nqmi4l503wbhbssqnd-bzip2-1.0.8.drv",["out"]),("/gnu/store/870zqwm6ax52wlkrbydzrwd77qnwkn43-patch-2.7.6.drv",["out"]),("/gnu/store/8k5gw4ayns06vkk87h7g6jnvx7pqzbb5-tar-1.34.drv",["out"]),("/gnu/store/ancgzayhh56asy51wsz5cadw3nsqdfwq-findutils-4.9.0.drv",["out"]),("/gnu/store/asy71mnlrws1g4arqx7h679yjh6hq7j1-gcc-11.3.0.drv",["out"]),("/gnu/store/g0jvllpvzwasjhap7yciakv8dnfnfmbf-sed-4.8.drv",["out"]),("/gnu/store/gmsdxi0l0d04fgdlxx2kgpar5l9ps95g-gawk-5.2.1.drv",["out"]),("/gnu/store/h3p7r7q1d725gv7m75l2pv30dny8pg6q-guile-3.0.9.drv",["out"]),("/gnu/store/ip3d7pkdz1d292cqx835jmpp2cpk4zzv-python-wrapper-3.10.7.drv",["out"]),("/gnu/store/jmxj5hj7xq68aj5awzm9jmjx98nb6pvw-gzip-1.12.drv",["out"]),("/gnu/store/k6ncnmg7dvlrd9y6sjk2m4lw1yih1d9r-grep-3.8.drv",["out"]),("/gnu/store/kv11m7sxallj9ynnk7ywxdxqc35083ya-linux-libre-headers-5.15.49.drv",["out"]),("/gnu/store/ldgcbz0111f1iwgm7rys5da0vdbrppgg-file-5.44.drv",["out"]),("/gnu/store/m36ykc481kqg01w5lkrayxqqd1sxkkm7-diffutils-3.8.drv",["out"]),("/gnu/store/mqy55qf54w1l3pm3ia7pscmphp50hax8-module-import-compiled.drv",["out"]),("/gnu/store/sz86qb9ijbfh09kfamr501abz66c6f51-coreutils-9.1.drv",["out"]),("/gnu/store/wrc7q69ldrxv0vmnpxzjv8q1qdld9paj-cmake-minimal-3.24.2.drv",["out"]),("/gnu/store/yskg0k6vbm0s31v0nr6bq3kjk7iga034-xz-5.2.8.drv",["out"]),("/gnu/store/yx51788kbw95rm9my88qql2xbv11alsm-binutils-2.38.drv",["out"])],["/gnu/store/ng2vdl1jj3y5hl5vz7v0p6png4gkp0y3-catch2-3.5.1-builder","/gnu/store/y3bxjld80fwz3r1gz9dx90gk49dqmr1k-module-import"],"i686-linux","/gnu/store/33nvcq7kmv79i1lrf89qq5ill0bmcq7n-guile-3.0.9/bin/guile",["--no-auto-compile","-L","/gnu/store/y3bxjld80fwz3r1gz9dx90gk49dqmr1k-module-import","-C","/gnu/store/0lk1h59vivvn4gys8i1gdh3z9nbgi7ms-module-import-compiled","/gnu/store/ng2vdl1jj3y5hl5vz7v0p6png4gkp0y3-catch2-3.5.1-builder"],[("out","/gnu/store/fjd0s86602rkpcnb5nqg14fii1acgkcn-catch2-3.5.1")])
failed-build-log-catch2-3.5.1.drv.gz
Description: application/gzip
Derive([("out","/gnu/store/cpqk1bmh61qjvs9b244dvzy7ppygp4lr-catch2-3.5.1","","")],[("/gnu/store/3ds56xg6njpw6hnp2w4xpx4psw5mka5q-glibc-2.35.drv",["out"]),("/gnu/store/5bqhdbbl71r9r936w6w8zzqlk41md3wx-glibc-2.35.drv",["out"]),("/gnu/store/67nh3fzviy3q4s8ar8cg0dzhyzgwrwdd-module-import-compiled.drv",["out"]),("/gnu/store/7fsz44vifdc0ws0amnpwnmig3ra6hb53-gcc-11.3.0.drv",["lib"]),("/gnu/store/fchdaawcrxb35llbl7fj7lcsq5asmk4b-guile-2.0.14.drv",["out"]),("/gnu/store/fkxlcpah5hca1gv7789g9vxyp3kfg10h-catch2-3.5.1.drv",["out"]),("/gnu/store/ky030dkfkfr3l8xgdbv45j6bs87988lx-gcc-11.3.0.drv",["lib"]),("/gnu/store/n9kblf5cx4lphrydjr90sp3zfvcdr1pb-glibc-utf8-locales-2.35.drv",["out"])],["/gnu/store/2sb4y2khyj8rls659i7v50d7kmlh6slb-catch2-3.5.1-builder","/gnu/store/a6acf6dds8s9fw7dp5div03rwik0x4x2-module-import"],"x86_64-linux","/gnu/store/4p1l5bdxxbyyqc3wh0d07jv9rp1pdcy7-guile-2.0.14/bin/guile",["--no-auto-compile","-L","/gnu/store/a6acf6dds8s9fw7dp5div03rwik0x4x2-module-import","-C","/gnu/store/yk897hj2p5mdx6hw47s90n8x9pn6s36c-module-import-compiled","/gnu/store/2sb4y2khyj8rls659i7v50d7kmlh6slb-catch2-3.5.1-builder"],[("allowSubstitutes","0"),("guix
properties","((type . graft) (graft (count .
2)))"),("out","/gnu/store/cpqk1bmh61qjvs9b244dvzy7ppygp4lr-catch2-3.5.1"),("preferLocalBuild","1")])
Deferring evaluation of a get-secret procedure so -L doesn't evaluate it unless needed for build
Hi Guix!
Until recently I reconfigured my home & system by setting the
GUILE_LOAD_PATH env var, but I am now trying to transition to using the
-L argument.
I have a configuration repo that's broken down into separate modules,
(mostly) like so:
--8<---cut here---start->8---
lib
└── rsent
├── constants
│ └── wireguard.scm
├── home
│ └── pathfinder.scm
├── system
│ └── pathfinder.scm
└── utils
└── secrets.scm
--8<---cut here---end--->8---
wireguard.scm contains code that fetches secret values
(private+preshared keys) from my password store and defines a service
using that secret value. The code looks something like this:
--8<---cut here---start->8---
(define wireguard-lan-secret-service
(service
(wireguard-configuration
...
(private-key
(plain-file "private.key"
(get-secret*
"System/WireGuard/LAN/private.key"))
--8<---cut here---end--->8---
I've noticed that when I run `guix home reconfigure -L lib
lib/rsent/home/pathfinder.scm`, (get-secret* ...) is still evaluated,
meaning that I'm prompted for a password when I don't need to enter one
(home-environment doesn't support wireguard-service). I don't have this
problem if I run `GUILE_LOAD_PATH=lib guix home reconfigure
lib/rsent/home/pathfinder.scm`, presumably because Guix's -L doesn't
just add to the load path, but also evaluates every file for possible
package definitions.
I suspect I need to replace (plain-file ...) with another option,
perhaps (computed-file), as well as rework (get-secret*) into a gexp.
I'm struggling with the syntax though, so any help in this would be
appreciated. Or if there's a better solution, that would be amazing!
*On another note*, should Guix have another command line flag that
behaves identically to `$ guile -L`? Adds directory to the load path,
but does not do anything else? The distinction between Guile and Guix's
-L isn't emphasized enough in my experience. To a beginner, these two
sound identical.
Guile: -L DIRECTORY add DIRECTORY to the front of the module load
path
Guix:-L, --load-path=DIRprepend DIR to the package module search
path
Apologies for the wall of text, hopefully someone has some thoughts.
Richard
(define-module (rsent utils secrets)
#:use-module (gnu services)
#:use-module (gnu services shepherd)
#:use-module (gnu services docker)
#:use-module (ice-9 popen)
#:use-module (ice-9 rdelim)
#:use-module (guix memoization)
#:export (get-secret*)
#:export (remove-unused-secret-services)
#:export (when-using-secrets)
#:export (secret-service))
(define (sudo-user)
"Returns a @code{string} representing the user the pass commands should run
as. This
is necessary because reconfigure requires sudo to be used, which would run a
sudoless
pass command as root. This causes pass to miss the password store."
(or (getenv "SUDO_USER") (getenv "USER")))
(define (use-secrets)
"Returns #t if secrets should be used."
(not (getenv "RSENT_NO_SECRETS")))
(define-syntax when-using-secrets
(syntax-rules ()
"When macro with a specific test. Must be written as a macro instead of
a function to avoid evaluating b1. b1 would be evaled before being
passed to the function, and trying to cheat with a sexp and (eval)
fails because the function doesn't have visibility to the record
definition fields."
((_ b1 ...)
(if (use-secrets) (begin b1 ...)
(define-syntax secret-service
(syntax-rules ()
"A secret service is a service that is replaced with #
when (use-secrets) is false."
((_ a b c c* ...)
(syntax-error "Too many arguments"))
((_ service-type service-configuration ...)
(when-using-secrets (service service-type service-configuration ...)
(define (get-secret key)
"Returns the associated secret for key. Key should be in the form of a
password-store path."
;; TODO: Throw error if pass fails.
(format #t "~!Fetching secret for ~a... " key)
(let* ((port (open-input-pipe (string-append "sudo -u " (sudo-user) " pass ls
" key)))
(str (read-line port))) ; from (ice-9 rdelim)
(close-pipe port)
(format #t "~!done\n")
str))
;; Memoize because guix seems to call this function twice per secret,
;; with a nontrivial time delay between them. This technically makes
;; it less secure since it leaves the secret in memory after it's
;; used, but the secrets are being written to the store anyway and
;; this particular attack vector would require a high level of access
;; to the machine.
(define get-secret* (memoize get-secret))
(define (remove-unused-secret-services services)
"Wrap the list of services with this when using services that may include
secrets."
(filter (lambda (val)
(not (unspecified? val)))
services))
(define-module (rsent co
