<zimoun>rekado: about the manual toc and accent, I do not know the internal of makeinfo and neither if it is possible to read the .tex before the process by pdftex (if I read correctly), the error seems appearing there. Weird! Thanks for working on it. :-)
<divoplade>(I mean, I sent a patch on guix to accept my mkdir-p function)
***catonano_ is now known as catonano
<OriansJ>does anyone know what %base-initrd-modules actually expands into? because I did grep -iR %base-initrd-modules on the source tree and it doesn't really help to understand what exactly it implies
<wleslie>what would it take to have a guix package version-agnostic? so if I wanted to install an arbitrary version of cpython, I could run `guix environment --ad-hoc email@example.com` and have it just work, even though the latest published version is 3.8
<wleslie>sorry, that question is probably a time sink, just blue-sky thinking
<brendyyn>wleslie: its a fine idea. I think what you mean is, say, 3.7 doesnt exist in guix atm but this would generate that by modifying the current one?
<civodul>wleslie: we have updaters ("guix refresh"), and i've been thinking we could have a "package transformation option" that changes a package's version to the latest upstream version
<wleslie>the thing is, I don't usually want the latest versions of things. the great thing imo about nix and guix is I can have an old version of x and a new version of y and that's perfectly acceptable
<dannym>civodul: I mean the progress report is a good thing to have, but can't savannah be configured so that shallow clones from specific commits from git work (i.e. fetching "unadvertised" git objects) ? Then I suspect cloning guix from git won't take so long to clone in the first place.
<dannym>Right now it falls back to cloning the full repository each time
<brendyyn>wleslie: python 3.7.9 has security fix support until 2023-06. I don't see why it couldn't be readded
<civodul>dannym: i don't know how Savannah can be configured, but the problem is that libgit2 doesn't support shallow clones
<dannym>civodul: Then I think extending libgit2 to support them would be the right fix, not papering over it :)
<dannym>Still nice to have progress reports, though
<dannym>It reminds me of Windows 10 devs allegedly making a very fancy copy progress dialog in explorer because explorer was (and is!) so slow that even copying files in the local network made users think Windows crashed. Well, after the progress report, it didn't get faster ;)
<civodul>even with shallow clones progress report would be in order
<abcdw>efraim: I try to do something like http://ix.io/2BAC, but system-disk-image isn't exported and I can't use it directly. Is there another way to accomplish it?
<brendyyn>wleslie: i notice that there are some minor changes to the package definition with 3.7 and 3.8. it may fail to compile if its automatically generated
<wleslie>indeed, it could be like gcc where there are distinct definitions for nearby versions
<brendyyn>strange... i found the commit just before python was updated, but when i use it with time-machine, it still shows python 3.8: guix time-machine 5dc6d5ce9997e4caf66d154f91c3695e02e5386f -- show python
<brendyyn>oh.. #t isn't needed at the end of build phases any more?
<allana`>Hi guix! I am trying to define some environment variables in my system configuration. I have searched through the manual and the guix cookbook and I have not found anyhting. I'm assuming that this is possible. Can anyone share a working example?
<civodul>allana`: hi! you can do that by "extending" environment-service-type
<civodul>for example, add this to your 'services' field: (simple-service 'my-var environment-service-type '(("FOO" . "42")))
<jlicht>mothacehe: a bit of a tangent perhaps, but I recall there being some golang-packages not liking being compiled with the qemu-binfmt service we have; Won't things like that spoil the fun you allude to in the final points of your post?
<jlicht>it could also just be an ancient issue that has long been fixed, I just remember waiting _very long_ for my rpi to compile syncthing, as it couldn't be offloaded to my main desktop /w qemu-binfmt :-)
<mothacehe>jlicht: yes the situation is a little big delicate. Cross-compilation is fast but only works on a subset of packages (linux.scm roughly). Transparent emulation is really slow and have very few substitutes due to CI issues. It also suffers from https://issues.guix.gnu.org/issue/43513.
<mothacehe>nonetheless generating barebones images should now work pretty well :)
<nefix>jlicht: with the (list), I get a match error (regarding #f)
<jlicht>I am currently running into the issue that in the build phase of (gnu-build-system), one of my freshly compiled binaries is run to generate more sources. It complained about missing the so-files, so I setenv LD_LIBRARY_PATH in a phase before build. Now everything works, but now my later `validate-runpath'-phase is failing and every so-file not being found.
<nefix>vits-test: eeeh at least that's my intention
<mothacehe>civodul: thanks, I had the exact same idea writting the article :)
<bhartrihari>Hello, when I run the guix pull command, the connection gets refused by git.savannah.gnu.org. I get the following error: guix pull: error: Git error: failed to connect to git.savannah.gnu.org: Connection refused
<jlicht>nefix: I think you found an undocumented issue in guix-home-manager; default-host has a default-value of #f, but leaving it at #f leads to your issue. Solution for now: add a default-host to your ssh-configuration
<jlicht>nefix: you could open an issue at guix-home-manager or if you're feeling adventurous: try to create a patch ;)
<vits-test>bhartrihari: did U played with firewall recently?
<civodul>but we could perhaps make it a bit longer
<cbaines>This is something I've been thinking about, as with guix.cbaines.net, I just have an ever growing S3 bucket of nars... I want to write a gc equivalent that works with a bunch of nar/narinfo files, rather than a store.
<civodul>so far we don't seem to be having scalability problems in "guix publish"
<civodul>"guix publish" GCs items from its cache periodically
<civodul>based on the chosent TTL and the atime (!) of narinfos
<cbaines>I'm still at the ideas phase, but I'd like to have something which would allow marking some nars as "roots" so they don't get deleted, so you can have more control over what's kept for how long
<cbaines>For ci.guix.gnu.org, you'd probably want to keep substitutes for previous releases around for longer for example
<mothacehe>could we just set infinite TTL on those nar?
<cbaines>From what civodul has said, I think there's just a single TTL, and the atime of the narinfos
<zimoun>hum? I am missing details about what “guix publish” serves compared to what the store is and what the nodes access to (read/write).
<cbaines>zimoun, "guix publish" serves nars/narinfos from /gnu/store . When using Cuirass plus guix-daemon offloading, build dependencies get copied from the "head" node to the build nodes, and then the outputs get copied back.
<zimoun>mothacehe, cbaines: thanks. And where the GC is currently happening? On the “head” or on nodes?
<mothacehe>an email feedback on those tests, like on Linux would be even better :)
<mothacehe>tricky part is that running install tests on every patch isn't realistic I guess
<cbaines>with the coordinator at least, all the builds can have priorities, so the expensive system tests can just have a lower priority
<mbakke>woo, I have a patch to make ungoogled-chromium load extensions from a Guix profile, and a package for uBlock Origin... still need to work out some details wrt extension signing and creating the extension directory in the correct "format".
<zimoun>civodul: does it make sense to try to StarPU-ize the guix-daemon used by the build farm?
<mothacehe>having the drv GC rooted would fix it I guess
<mothacehe>while increasing our space issues probably :(
<divoplade>Hello! There's something I can't explain with cuirass ^.^ I request that my packages be built for some architectures, but look at, for instance: https://ci.divoplade.fr/eval/42 i686-linux succeeded, but the other architectures are "pending"!
<zimoun>civodul: I feel that the coordinator is reinveting the wheel about scheduling over an heterogeneous infra.
<shoxy>Hi, everyone! Does someone know a download link of the uncompressed iso? My hoster can include this iso to my server, so I can install guix there. Of course, I could serve it myself somewhere, but this doesn´t seem like a long-term solution. Thank you very much and also for the beautiful OS ;)
<apteryx>mothacehe: I didn't read back too deeply, but what happens to Cuirass database when the machine reboots (since it's now on a tmpfs, IIUC) ?
<zimoun>cbaines: changing from sqlite to postgres?
<cbaines>zimoun, no, just things like adding new tables, adding new columns, that kind of thing. Sqitch can support multiple "engines", so it works with both Sqlite and PostgreSQL. I have planned to allow using either for the coordinator, but Sqlite is the only one supported so far.
<apteryx>civodul: what was changed recently was the image generation no longer being offloaded, because that'd lead to transferring large (~700 MiB IIRC) images over the network (at least it did for me when using the childhurd service).
<lfam>Also, looking at the CI job for firstname.lastname@example.org, I see that the i686-linux build has failed
<mbakke>apteryx: 700MiB is not that large... offloading a build of 'ungoogled-chromium' to a newly-GC'd node will send over something like 3 GiB, yet I don't think we should disable offloading for that package.
<mbakke>though I suppose it does not change as much as the installation tests.
<zimoun>cbaines: each agent has to run something, right? I mean the “guix-build-coordinator“ should be installed on each agent, right?
<apteryx>mbakke: 700 MiB may not be that large, but if you use childhurd to build stuff you'll want a much bigger image, in which case it may transfer GiBs.
<civodul>apteryx: i use en_US, so i don't know, but we can check in a VM i guess
<mbakke>apteryx: ah yes, transferring a single-use huge ISO image is a bit wasteful
<apteryx>civodul: yeah, en_US is what it defaults to, for anyone it seems :-)
<cbaines>zimoun, yeah, there's one process "guix-build-coordinator" that's the coordinator bit. The agents each run "guix-build-coordinator-agent". Both those scripts are in the guix-build-coordinator package currently.
<apteryx>civodul: Oh perhaps! I was relying on the fact the system would scream at me if I did something obviously wrong in my keyboard-layout definition (I seem to recall it would)
<civodul>i think it screams, but only if the 1st argument is wrong
<mothacehe>apteryx: hurd images are now qcow2 so they don't get as big as the allocated space
<apteryx>OK, that's good! Was it always the case? Perhaps that 700 ish MiB was the actual size of the data
<mbakke>lfam: AIUI the 'no such file or directory' is because qemu-binfmt has been updated and the old 'guile' it was using got garbage-collected, and guix-daemon has not been restarted to get the new binfmt chroot.
<mothacehe>No at some point it was a raw image, barebones hurd images are now around 375MB
<zimoun>cbaines: I am giving a look to the code. Well, to understand all the recent discussions. :-)
<lfam>I see, mbakke. Do you have advice about what I should do here? Should I ignore the result? Wait for the daemon to be restarted?
<apteryx>OK! That's good. I'm still of the opinion that images are best generated locally, for bandwith consideration (you have to transfer the whole contents of it... then generate an equally large image from it and transfer it back over the network). Now that genimage is used it's quite cheap to generate locally too.
<isengaara>For the Online Guix Days I plan do to a talk about porting Guix to PowerPC/Power9 so that I can run the Guix System on an RYF certified Talos II.
<apteryx>civodul: ah! my system config was lacking a `set-xorg-configuration' service; that must be why! I'm validating this.
<PotentialUser-20>Hello folks, I am currently trying to set up the Slim display manager with exwm as window manager. I assume Slim needs a .desktop file to load the window manager, but I don't know where it should go. The guix documentation says to put it in the .guix-profile directory but it seems to be read-only. Any tip ?
<mroh>PotentialUser-20: try installing exwm in the system profile. Slim should find the .desktop file then. read-only is ok, I guess.
<ebn>Hi! Second day on Guix, what is the preferred way to install software, globally installed by adding them as a package to my system-config or just install using guix install? I previously used nix and I had all my software globally installed while having some environments (shells) for different projects, compilers and tooling etc.
<helaoban>hello guix, I'm unable to build some common packages on emulated hardware on my system. For example running 'guix build --system=aarch64-linux ghc' fails with 'while setting up the build environment: executing `/gnu/store/x3gq648qnfnla7nppyfjvj62s2i8y7rl-guile-3.0.2/bin/guile': No such file or directory'.
<helaoban>it looks like it has something to do with not being able to find guile. any tips?
<vits-test>helaoban: today lfam faced that error. Try restart the daemon/reboot (on/the VM?)