<rekado>none of the memcheck tests pass. I'd say the RAM is broken. <troydm>hey all! I'm trying to install guixsd on virtualbox machine, I've booted livecd made config.scm and doing guix system init /mnt/etc/config.scm /mnt however after that it tries to download files into / of livecd apparently instead of /mnt as I keep getting No disk space left on / <vagrantc>there's some sort of cow-mount feature you need to enable to make the /gnu/store write to the installed filesystem <vagrantc>it's documented in the guix installation manual stuff <troydm>I still keep getting it and apparently downloads files to /gnu/store before copying it to /mnt but / has no free space left <bavier>troydm: how "large" is the configuration you're trying to initialize? <troydm>bavier: it's strange I've rebooted the livecd and started installation again and now it seems to be working fine <troydm>and it failed on grub installation step <troydm>something about blocks or blocklist not supported, and now I try to reinstall and it started again from scratch, most frustuating <troydm>it's downloading files it previously should have been downloaded, this is very weird <efraim>There's no dhcp service in %base-services? <efraim>I'm working on pine64 GuixSD support, I need to figure out about the magic boot.ini file, if I need it <efraim>I got the initial, unbootable image almost built, time to work on the kernel config :/ <efraim>Kernel config copied from armbian inserted, time to see if it builds everything ***Gamayun_ is now known as Gamayun
<pch>Hello Guys, have a specific question regarding package installation. Is it possible to install local packages (instead of downloading them from a remote destination)? <pch>Hello Guys, have a specific question regarding package installation. Is it possible to install local packages (instead of downloading them from a remote destination)? <pch>That is, is it possible to specify a local path in the url-fetch field? <snape>If I remember well you can use "file://" syntax <pch>snape: thanks, any examples, links? <snape>I'm looking for them, wait a minute :-) <pch>snape: thanks, take your time :) <pch>snape: so wonderful, many thanks! <rekado>has someone here built a kernel with a different configuration file? <rekado>I’d like to build linux-libre with the purism kernel config and see if that’s any better. <rekado>the PureOS kernel conf is way shorter than ours. Is there a reason why so many settings are explicit in our kernel conf? <efraim1>I'm fighting with the arm64 kernel config right now, right now I've started with Armbian's kernel for the pine64 and can't get ahci.ko <rekado>efraim1: in building a custom kernel do you edit the included config file or start from a known good config from another system? <rekado>I wonder if there are special kernel config settings that *must* be there to make GuixSD work. <rekado>guess I answered my question: the build fails. <efraim>rekado: I started with an assumed good kernel config from Armbian and then edited it to add ahci.ko and other bits we needed, I might go with my other attempt which was 'modules for all the things' <cbaines>rekado, I've got a Librem 13 as well, and I'm running GuixSD on it. We can compare problems if that would help? <efraim>I know that one produces everything needed but it takes 4x as long to build <cbaines>I think I remember reading you're having issues with the backlight, but that seems to work fine for me? <efraim>I tried starting from Debian's but I couldn't figure out their split config system <rekado>cbaines: do you have Librem 13 v2? <cbaines>I think so (it says "Version 2" on the bottom <rekado>okay, that’s the same as mine then <rekado>I get random crashes with any of the GuixSD kernels <rekado>do you use a special kernel configuration? <cbaines>Nope, and luckilly I haven't had any random crashes either <rekado>seconds after starting rsync to install my backed up data it fails <cbaines>I think I remember you saying that memtest was failing, is that the case? <rekado>memtest fails, but that’s not helpful <rekado>the version of memtest that comes with coreboot simply doesn’t support DDR4 RAM <cbaines>hmm, might be useful to try running memtest <rekado>right, but I can’t get any later version of memtest to work <rekado>I prepared a USB stick, put latest memtest there, and hit ESC to boot from it. <rekado>but it only offers me memtest v4, which indicates that legacy BIOS is used; later versions require efi <rekado>cbaines: could you share your GuixSD config, maybe? <rekado>in my config I didn’t specify any EFI things. <rekado>I just booted, repartitioned the disks (just one big disk), set up full disk encryption, and then installed GuixSD. <rekado>I also get crashes with “guix gc --verify”, but none when I build or download packages. <cbaines>I think I tried using EFI, but that didn't work as I think it uses BIOS <cbaines>At least I see something about SeaBIOS when it starts <cbaines>I'll email you my config, as I haven't made it public <cbaines>Going back to memtest though, do you remember if you used memtest86 or memtest86+? <cbaines>You might want to try the other one, and see if you have more luck with that <cbaines>On a slightly related point, I remember back when I was using Debian, that installing the memtest... package would give you a grub entry for booting in to memtest, which was pretty neat <rekado>cbaines: thanks for the config; looks similar enough to mine, except that I don’t have /dev/nvme0n1 (only have a regular SSD) <rekado>that’s the one that’s part of coreboot. In coreboot there is v5.01; I put the latest version (7.x) on a USB drive, but for BIOS it only lets me run version 4. <cbaines>another way of testing the memory would be to use different memory if you have any? <rekado>I went to IT but they don’t have any DDR4 RAM for laptops. <efraim>Debian apparently has a kernel config for arm64ilp32 <cbaines>Well, if you bring yours to FOSDEM, we can always try swapping my RAM in and see if that helps? <rekado>I also wrote purism about this, but they are slow to respond. They will have people at FOSDEM, too, so I hope that something could be done. <rekado>it’s very uncomfortable not to have a working laptop :( <rekado>I have no idea how I’ll give presentations tomorrow. <efraim1>i downloaded the two part debian config, i'll see how that goes <pch>Hello, any ideas/examples about how to specify run time dependencies of the package for e.g. a package having a dependency on a minimum specific version of another package. <cbaines>pch, you've got a couple of different things mixed together there, run time dependencies, and version based dependency resolution <cbaines>taking each one separately, for runtime dependencies, referencing the dependency in the store where it's used, or specifying it as a propagated-input are two approaches that are used <cbaines>as for version based dependency resolution, I don't know of any cases of this happening in the packages in the guix repository <cbaines>(I've played with doing some version based dependency resolution, but the way I was looking at this is generating guix package definitions) <pch>cbaines: what do you mean by you last comment "but the way I was looking at this is generating guix package definitions"? <pch>cbaines: can you explain a bit in detail? <cbaines>Just that by the time you get a guix package definition, there is no uncertainty about the dependency tree, you know all the exact versions <cbaines>I was playing around with taking a dependency resolver, and building guix package definitions with it <pch>Yes, i could understand <pch>but I am looking more into handling run time dependencies, where package creator specifies its dependencies and if the actual installed version is not the same, then the installation atleast fails, or downloads it eventually <cbaines>pch, could you give a concrete/specific example? <pch>cbaines: i want to use guix for our software development where we want to deploy different applications (guix package) on the production platform and it could be that an application has a strict dependency on version of any other application. <cbaines>If you have guix packages for applications, each package will be for a specific version. If you want to use multiple versions of a bit of software, then you'll want to keep around multiple packages. <cbaines>When declaring the inputs (dependencies), if you pick the packages you want (with the versions you want) then it should be ok <cbaines>pch, this is a bit of a mental shift from other systems like Debian, where you have constraints which are solved at installation time <cbaines>that's not how the guix tooling currently works <pch>No, having or managing multiple versions is not the intention. The deployed system should have one and only one application version installed but I just want that at-least i can produce an installation failure if there is a version mismatch <cbaines>pch, ok, perhaps look at the problem from a different angle. Just take two of your applications, how does one find the other when it needs to? Does it use a environment variable, some configuration, an absolute path, ...? <pch>I implemented the same with another package manager (OPKG) which maintains the information about which package is installed with which version <pch>and you can specify installation dependencies during package build like "DEPENDS "xxx-pkg(>=3.1.3)" <cbaines>What I'm trying to get at is that Guix packages don't contain the version constraints for their dependencies. Rather than doing analysis of the constraints at package installation time, with Guix, your better off structuring the packages so that they always use the dependencies you intend <pch>so that means GUIX does not track package versions? <cbaines>So, instead of failing when a dependency is used at an invalid version, build your packages so that they only ever use the dependencies they are built with <cbaines>pch, it does have that information, version is one of the fields in the package record <cbaines>and the inputs (native-inputs, inputs or propagate-inputs) just have the version information as well, but there isn't any way I've seen to record constraints (e.g. A => 1.3) in the package record <pch>yes, i could not find it too, thats why i started with that <cbaines>My suggestion would be to focus on making version mismatches impossible by building packages in a rigerous way <cbaines>This is how many of the packages contained in the guix repository are built <pch>there is a package version field, what is it actually used for? <cbaines>I think if you install a package, say foo, then guix package -i foo will pick the latest version for you <cbaines>you can also specify the version, e.g. guix package -i foo@2 <pch>just comes to my mind that my installation trigger service could fetch this version and could check on it somehow. <pch>I mean before even triggering the package installation <pch>but its a dirty solution <cbaines>In my mind, the cleanest solution is to avoid the version mismatch problem at installation time entirely <cbaines>Guix is pretty awesome as it gives you some really good tools and patterns to make that possible <pch>which tools and patterns? <cbaines>The main pattern is using absolute paths for referencing dependencies <cbaines>So if you have some software that needs to run guile say for some reason, you could run guile from the $PATH, but this might be different, so you can hardcode the full path /gnu/store/fn930...-guile-2.2.3/bin/guile in to your package, and then you'll always use exactly that guile <cbaines>The tooling that supports this is the store, package definitions, and more ... <pch>So, this would implicitly mean (for me) maintaining different version of the same package on the system <cbaines>pch, I'm not quite sure what you're asking? <rekado>there’s a typo: “This can be done [-using ]by setting the LD_LIBRARY_PATH environment variable:” <pch>ok leave it, but i got your point <rekado>civodul: and another: “… but the glibc package in Guix currently ignores [-since ]that file since that could…” <pch>cbaines: many many thanks for this discussion. I clears a lot of doubts for me <atw>pch: you might find this helpful: https://research.swtch.com/version-sat. It contains four traditional assumptions about package management, including "4. Two different versions of a package cannot be installed simultaneously." Guix does away with this assumption :) <rekado>while another laptop is being installed I’d like to prepare my talk for tomorrow <rekado>it doesn’t really have a title other than “Guix@HPC” <civodul>rekado: i'd say 3 points: 1) benefits for developers, 2) benefits for reproducible science, 3) benefits for sysadmins :-) <civodul>maybe "Reproducible software deployment for high-performance computing" (as on the web site) would be a good subtitle <snape>civodul: very interesting, thanks <rekado>they will have had an intro to Nix by that time, so I’ll talk less about functional package management. <rekado>but I can already hear the questions along the lines of “why this and not Nix” <rekado>that’s a good way to structure this <civodul>re "why this and not Nix" → hackability <civodul>that's what makes 'guix pack', hpcguix-web, GWL, etc. possible <civodul>also "first-class packages", with search paths and all that <rekado>I just really don’t like that kind of question because it frames things as competitive and binary ***adam` is now known as adamvy
<pkill9>when `guix pull` is run, does it ever just update the 'recipes' without recompiling the whole new version of guix? <pkill9>and if not, will it ever get to a point where it just updates the recipes without compiling new version of guix? <apteryx_>civodul: I should have time to address your comments of my emacs-realgud patches tonight -- thanks for the review! <rekado>pkill9: what you call “recipes” are really Scheme code. <rekado>pkill9: interpreting them at runtime would be slow, so they are compiled <rekado>guix system init fails because manual-database.drv failed <rekado>the error is zlib-error with args (gzread! -1) <rekado>removing iproute2 from the derivation fixes it. <rekado>ACTION edited the derivation right there, sue me :) <civodul>in current master "guix package -p foo -i iproute2" works <rekado>I “guix pull”ed less than an hour ago <rekado>(actually, I changed the builder, not the derivation, but close enough) <civodul>maybe it's the combination of iproute2 and another package that triggers the bug? <ng0>is there no default for timeout for guix-daemon? my substitutes server is idling on lekha for at least 24 hours.. or at least I think it is just lekha. <civodul>would be nice if you could keep the package set around so we can try to reduce it <civodul>i mean no rush, but just keep the file around <rekado>civodul: it’s my system profile, and that doesn’t change often <civodul>rekado: could you send me examples of GWL workflows, wisp or not, and links or anything useful you may have? :-) <rekado>I still don’t have a working laptop <rekado>(hence no qualms about editing a builder to get a working laptop) <ngz>Hello. I'm trying to build a Python library, but run into an error: "OSError: Could not locate nacl lib, searched for libsodium.so, libsodium.so.23, ...". However libsodium belongs to propagated inputs (as it is the rule in the Python world, IIUC). Does that ring a bell? <rekado>on this laptop my configuration just assumes a BIOS, but grub-install errors out trying to find modinfo.sh <efraim>ng0: mine often hangs at python2-efl, I set the timeout to 1800 <civodul>rekado: you should check how it looks for .so files <ng0>efraim: okay, so there is no default, which is why almost all of the files in maintenance repo have timeouts set? <civodul>rekado: also did you mount /boot/efi in the installation image? <ng0>didn't search the code today <rekado>do I need to repartition and do everything from scratch…? <efraim>ng0: yeah, I forget why it got changed but apparently it was supposed to be that way <efraim>Something about not honoring timeouts because it was hardcoded <ng0>I have another odd issue, but I have to write an email about that.. something which could either be about my setup or Guix <ng0>or one of the 2 firewalls involved <rekado>the manual makes it sound like there’s a choice; but it seems to me that I have no choice but to use EFI-based GRUB <rekado>I’ll try to resize the luks container and the partition, then add one for efi. <efraim>We have grub-hybrid for the install image, which might default to EFI since its there <ng0>efraim: this is timeout, not max-silent-time right <efraim>Oh, right, I'll have to check my config, it might be silent time <efraim>I timed out grafting texlive once and I think the arm builders timed out building an early guile, but I don't remember if it was timeout or max-silent-time <ng0>guix-daemon --help helped <rekado>the laptop say “boot mode is set to: LEGACY” <rekado>doesn’t this mean that non-EFI GRUB should just work? <rekado>can I *force* guix to install the BIOS variant of GRUB? <civodul>rekado: yes, if you use "grub-bootloader", i think <rekado>I do use grub-bootloader, though. <rekado>and still grub-install talks about efi things. <rekado>I rebooted to have the luks partition unmounted, so I can resize it <rekado>just resized the ext4 fs in that container <rekado>next is to resize the luks container <rekado>then to add another one, just in case <davexunit>hmm, I can't use 'guix download' because it can't verify certficates <davexunit>I need to point gnutls at my system certs somehow <davexunit>anyone happen to know off the top of their head? <rekado>civodul: the error was something like “…grub-install: …/efi-x86_64/modinfo.sh not found; add --device or --target” <rekado>davexunit: SSL_CERT_DIR, SSL_CERT_FILE, …? <rekado>our documentation on EFI is somewhat misleading <rekado>“parted /dev/sda set 1 esp on” is only correct if the first partition (“1”) on /dev/sda is an EFI partition. <rekado>if sda2 is to be the EFI partition then this must be “set 2 esp on” <civodul>rekado: yeah the doc is not great here <civodul>rekado: the "modinfo.sh not found" message is with grub-efi-bootloader? <buenouanq>what's confusing about it is between steps it switches from using partition 1 to 2 for no reason <rekado>civodul: no, I get that message with grub-bootloader. <civodul>yes weird, unless partitions are zero-indexed in parted <civodul>my guess is that the 0.14 image boots as EFI, and so grub detects that it's on EFI and wants to do EFI <civodul>so maybe you should just do EFI, after all <rekado>there is a directory /boot/efi, yes <rekado>it would be great if we could improve this <civodul>so yes, create that FAT32 partition with the "esp" flag <rekado>I have made a bunch of … observations installing GuixSD under stress <civodul>previously the image would always boot in "BIOS" mode, which made EFI installations almost impossible <civodul>now it makes non-EFI installations impossible on EFI hardware, it seems <rekado>rebooting is painful, because you lose the progress of “guix pull”. It would be great if we could more easily use a later version of Guix from the target disk. <rekado>it also seems impossible to properly stop the cow-store service. I haven’t been able to unmount the luks container because of that. <efraim1>I think it'd be nice for `guix pull' to basically 'make clean; git pull' and then with some combination of nice and ionice do the compiling <ng0>I made the observation a very long time back that chroot into half-finishied, partly broken installations is essentially impossible.. half-way possible, but should be explored more if we could even do that <efraim1>whoops, 'mcron -d' spiked my CPU usage to 51 and led to a kernel panic <efraim1>maybe in the future it should be 'nice mcron -d' <ng0>I mean ofc the issue with chroot is by design, but to make use of chroot or document steps how to would create a bridge for people used to chroot working <efraim1>cleaning up arm-trusted-firmware isn't going to be fun :/ <ng0>did anyone every experience emacs freezing over ispell starting? <ngz>ng0: I do, particularly when opening tex documents. <ng0>any advice other than disabling ispell? <efraim1>why are there makeflags in the lambda for u-boot's 'install phase? <ng0>I'll disable ispell for now <ng0>need to get this work done <ng0>this might be spoiled by my personal unpushed packages, but we're almost at 7.000 packages :) <ng0>6996 for my personal view <ng0>so probably -80 or so for guix master <ng0>maybe I counted by the output of weather <ngz>BTW, I'm trying to build a Python library, but run into an error: "OSError: Could not locate nacl lib, searched for libsodium.so, libsodium.so.23, ...". However libsodium belongs to propagated inputs (as it is the rule in the Python world, IIUC). Does that ring a bell to anyone? <ng0>someone once upon a time posted 2 pakage count scripts.. the second one says: <ng0>Number of packages: 6934 <ng0>Number of outputs: 7228 <ng0>so maybe I'm more than a bit ahead <rekado>I also can’t install with grub-efi-bootloader <rekado>the problem is that it tries to access lib/grub/x86_64-efi/modinfo.sh <rekado>but the grub package only provides an i386-efi directory <rekado>why does it look for x86_64-efi? <buenouanq>I was having this problem or something similar a couple weeks ago. <ng0>me too.. I just skipped efi after manual creation of the dir didn't fix the issue. <buenouanq>so you either have to MBR it or use grub-efi-bootloader or whatever <buenouanq>weird though, rekado"s problem is the exact opposite of what was happening to me <rekado>when I just take the legacy BIOS grub-install command that is executed by guix system init it fails with the same error. <rekado>it only succeeds when I also append “--target=i386-pc” <rekado>not sure how to fix this with the efi installation <rekado>ACTION patches gnu/bootloader/grub.scm <rekado>YES! GuixSD has been installed and it booted. <rekado>ACTION performs a little victory dance <rekado>ACTION pretends nothing happened <rekado>looks like we need to pass “--target=i386-pc” to the grub-install command. <rekado>I’m happy I again narrowly avoided EFI shenanigans. <efraim1>it looks like sunxi-tools also should have some logic to not cross-build on armhf-linux to arm-linux-gnueabihf <methalo\\>Hello, When I execute 'guix system init /mnt/etc/config.scm /mnt' is it necessary that shepherd be running? <efraim1>from the install image probably, if you're running it from guix on a foreign distro then I don't think so <efraim1>if i want to 'cat file1 file2 > file3' i'm looking at (call-with-output-file "file3" (lambda () (call-with-input-file "file1") (call-with-input-file "file2"))) ? <efraim1>no, i'd have to do something with file[12] after opening it <troydm>so I've installed GuixSD, now I've changed /etc/config.scm, how do I update the configuration? <apteryx_>troydm: there's a nice info manual detailing how to go around this, but essentially you want: 'sudo guix system reconfigure /etc/config.scm'. <troydm>apteryx_: yeah I just did it but now it started downloading packages all over again and I'm like WTF <rekado>troydm: remember that the guix command is per user. The root user’s guix and your regular user’s guix may differ. <rekado>so “sudo guix” uses the root user’s guix <troydm>rekado: I was root, so I just ran guix system reconfigure /etc/config.scm <rekado>if you updated Guix between configuration attempts that would download new packages. <troydm>also why there is no clean and shutdown commands? <rekado>instead of “clean” you can use Ctrl-L <rekado>I don’t know which package normally provides “clean”. <rekado>“shutdown” is achieved through shepherd, so we’re using “halt” instead. <troydm>I need to learn herd as I'm more used to old ways and systemd <troydm>but clean command is must have atleast for me <troydm>as I'm used to it as muscle memory <vagrantc>clean is maybe 25% as efficient as ctrl-l <troydm>vagrantc: yeah but some things can't be changed <vagrantc>ACTION thought the command was "clear" anyways <ng0>what does mcron need to run a file that executes a curl command successfully? could figure it out myself, but some quikc pointers why the cert verification fails even with environment variables exported would be nice <amz3>nobody wants to drink something in bruxelles after 21:00? <amz3>I am not against eating either <apteryx_>ng0: depending on your use case, you might want to use Guile's (web client) module. I had to bump our mcron2 to use Guile 2.2 though for HTTPS support. The patch is on guix-patches <ng0>it's just for a dynamic dns, sending the current IP every n minutes <ng0>ok, thanks. really appreciated since I don't have the time to read much for a while :) <ng0>so on the spirit of quick examples and me being in the process of writing job applications.. how do you insert the secret? my self constructed problem is that my old set of configs is public, while the new set of configs is still a template based prototype.. so the shell file was my way around this. <ng0>looks like an gexp.. <ng0>(greendragon, the server, is in the old set of configs) <ng0>I could simply scp it though and stop making it public for now. <ng0>I can think of some ways.. but how did you solve it? if you even had a similar situation <ng0>oh wait, I think I should look at the gexp more closely.. well next week. <civodul>so what more do we need on core-updates? <apteryx_>ng0: my secret in the job I put as an example is not really secret... it's just unversioned and in another file. <apteryx_>It ends up in world readable /gnu/store, so it's ideal. A little bit bitter might be to leave the job in your home and pass the user to your job. <apteryx_>ng0: the 'other' file called e.g. secrets.scm in included in my config.scm using an include statement. <ngz>I'm trying to build a Python library, but run into an error: "OSError: Could not locate nacl lib, searched for libsodium.so, libsodium.so.23, ...". However libsodium belongs to propagated inputs (as it is the rule in the Python world, IIUC). Any idea on how I could debug this? <civodul>hey ngz, i thought i had replied, but no :-) <civodul>ngz: can you chekc how that python lib looks for libsodium.so? <civodul>i suspect it does that by walking $LD_LIBRARY_PATH or $LIBRARY_PATH, or maybe just /usr/lib & co. <ngz>civodul: The last message is File "/gnu/store/pav9c00s4m9g35cylpiy9zv54vwk37q2-python-libnacl-1.6.1/lib/python3.5/site-packages/libnacl/__init__.py", line 81, in _get_nacl, raise OSError(mesg)... then the error. <ngz>So I assume this comes from libnacl, which cannot find libsodium. Yet, libnacl (which I had to package along the way), has libsodium as a propagated input. <lfam>civodul: I think there are a handful of broken packages, but I expect those to get fixed soon after we merge core-updates into master :) But <https://bugs.gnu.org/30298> should be fixed first <civodul>right, but having libsodium has a propagated input doesn't necessarily help <lfam>Basically, the guix-daemon is broken on foreign distros, AFAICT <ngz>Interestingly, libnacl builds without tests, but fails to build, with the same error, if I activate tests. <ng0>apteryx_: I guess I also have to (use-modules (whereever gnutls went))? because even with gnutls in global profile I get errors about (gnutls) modules not being available <lfam>Off-topic... all the dinner planning messages are making me very jealous! And hungry ;) <apteryx_>ng0: nope, the job as shown is complete except for the secret variable. <ng0>well then something's not working <ng0>is our standard mcron mcron2? <ng0>or fdo we have 2 mcrons? <apteryx_>are you using that mcron2 to run the job? you can find the job with 'guix gc -R /your/current/system-profile' | grep mcron <apteryx_>and then install mcron2 to your user profile and run 'mcron /path/to/your/generated/mcron-job.scm' <ng0>argh.. we have two mcrons <ngz>civodul: In libnacl, there is a _get_nacl() function that tries to locate libsodium. Basically, it first tries ctypes.cdll.LoadLibrary('libsodium.so'), then ctypes.cdll.LoadLibrary('/usr/local/lib/libsodium.so') ... <apteryx_>ng0: this is all just for testing, since I didn't get 'sudo ./pre-inst-env guix system reconfigure my-config.scm' to work for some reason. <ng0>mcron: default: mcron2 <ngz>Humm. I guess I could "fix" this function. <civodul>lfam: just replied to the bug, should be an easy one :-) <civodul>ngz: ok so you need to patch that to use the right absolute file name <ngz>Yes, I'm going to make it return early with the proper path in the store. <ng0>apteryx_: well now weird things are happening which make me doubt the testing computer is still okay <ng0>also, running just mcron with the path to the job didn't work <apteryx_>ng0: can you elaborate on didn't work? it only spits errors every 5 minutes, if any. <ng0>that is on tty1 happening right now (errors / 5 minutes).. login via ssh is doing nothing <ng0>;;; /gnu/store/3n4i2y73lnrvlimz4ywq7m9dqr8q9zjs-mcron-job:1:80: warning: possibly unbound variable `http-get' <ng0>maybe I forgot to include the module in the system file.. but I'm going to bed now <apteryx_>and you have (use-modules (web client)) in your job? <ng0>same like yours, except that I filled in my jobline for 1984 <apteryx_>did you install modified mcron2 using ./pre-inst-env guix package -i mcron2? <ng0>this computer is running from the branch I pushed it to <ng0>saw something in maintenance, but for today I'm stoping