<kitty1>One of my friends that uses nixos keeps talking about nix flakes, I'm kinda struggling to wrap my mind around their description of it, but im quite curious if anyone has attempted anything like that with guix yet?
<kitty1>havent heard anything like that, but might just be missing something
<kitty1>but yeah, even tho im a bit confused they do seem very neat, would be fun to play with on guix some day
<kitty1>probably will spin up a nixos vm some time and mess with it to get a better idea some time here lmao
<podiki[m]>I'm sure there would be interest in making such a thing easy in guix, seems the ingredients are there (add in guix shell and container too)
<acrow>jeko: A nicely done article. It's good to see emacsclient leveraged this way. I'll have to think about the security implications though. I think you intend that your vm be the sandbox and it seems reasonable to me.
<podiki[m]>I don't think you need a full nix vm for this, just nix as a package manager (which guix has)
<podiki[m]>anyway, don't know much about it, but probably others do and can let you know what the equivalent in guix-land is, or what tools could be used to make something similar
<kitty1>yeah, very curious on that if anyone knows, I get a feeling its the latter, and with the tools on guix it looks like it would be relatively simple to someone a bit more familiar to hack something together that has a similiar purpose?
<the_tubular>To contrbiute to guix, do you have to sign the FSF paperworks ?
<kitty1>I cant stop thinking about flakes lmao, like, I dont have enough experience here but it really feels like that wouldnt be hard to hack together, right?
<podiki[m]>I think it is safe to assume any legal paperwork takes a while :)
<the_tubular>Yes kitty1, from my very small understanding it seems it would be of gluing different part of guix togheter
<podiki[m]>kitty1: I think you are right, from what little I understand. a profile with pinned channel commits and then a package definition or scheme file to do the build roughly (in a build container or how packages are built)
<podiki[m]>I think you can even do it with a local channel defining your package and specify the commit of the other channels it depends on?
<podiki[m]>because guix package definition and channel commits will then specify the derivation which is reproducible (up to things that are non-reproducible more generally)
<podiki[m]>anyway, sounds like a good discussion to have, I'm off for now though!
<maximed>What I proposed with ‘This step can be sidestepped by explicitely’, is for now focussing on reconfiguring the system to something up to date, and leaving proper ~/.bash_profile setup for later.
<mmorko>ok i think i understand a bit, but not sure what to do now
<maximed>As I understand it, you want to reconfigure the system, right?
<maximed>If so, you can ignore .profile for now and do ~/.config/guix/current/bin/guix/pull system reconfigure
<abrenon>keep reading it over and over each time I try to do something that might be vaguely similar hoping to get some wisdom
<civodul>zimoun: true, that part i consider easy now :-)
<civodul>lilyp: nice talk! with bits of French, even :-)
<civodul>i agree that we should provide higher-level options for the container tools
<roptat>btw, talking with taiju on mastodon, it became clear some people would like to watch the talks but are not very good at spoken English
<roptat>I'll need some volunteers to help create subtitles after the Guix Days :)
<xelxebar>Hrm. Just guix inited a new system, which completed successfully; however, it fails to boot, with grub complaining about an unknown filesystem.
<sneek>Welcome back xelxebar, you have 2 messages!
<sneek>xelxebar, lfam says: Maybe we can fix your "clock is waaay off" problem by having Guix set the clock to the date of the Guix revision itself if NTP won't make such a big change, and then try NTP again. It might fix some instances of the bug, since the date of the revision-in-use is probably not more than a year old
<sneek>xelxebar, lfam says: It would be great to get some more details about the case where NTP wouldn't fix the time. Like, how wrong does the clock have to be?
<xelxebar>Interesting. How large is your esp partition?
<jpoiret>the issue is that until GRUB is able to find the loadable modules, it's limited to what's compiled in the initial image
<jpoiret>256M total with 41M used (and I have a certain non-free OS's bootloader on there as well)
<jpoiret>the issue is that it's not possible to do it that easily with non-EFI setups, as it requires an extra partition, whereas here you just re-use one you already have
<xelxebar>Makes sense. There's a small bit of chicken-and-egg going on.
<xelxebar>Is luks2 kept in a module because it would make the grub blob too large or something?
<xelxebar>Also, any reason why you do the indirect bind mount and not just directly mount to /boot?
<jpoiret>basically LUKS1 and LUKS2 code are in the same GRUB module (cryptodisk is the name I think), it's just that `grub-install` is able to detect that it should embed it in the binary only when LUKS1 is involved, not LUKS2
<sughosha>Hi #guix! Just now I ran `guix gc -d` and cleared GBs of the store. At last, it is saying "note: currently hard linking saves 4496.69 MiB". Is it saying that still around 4 GiB garbage left? If so, can I clear them too?
<civodul>the above data.guix.gnu.org URL is unreachable for me
<apteryx>rekado_: I've made a patch adding rootflags, which should give us some flexibility to try things at the GRUB level (e.g. to specify a device=/dev/sda3,/dev/sdb3,... option string). Unfortunately it doesn't pass tests yet. The branch is wip-initrd-rootflags.
<cbaines>civodul, the URL seems fine for me, what problem do you see?
<form_feed>I'm getting `guix upgrade: error: profile contains conflicting entries for` for the first time. How to properly handle this? I have already deleted a couple packages but new ones keep popping up. Actually, what's happening?
<cbaines>unusual, maybe try https rather than http (not sure why that would make a difference)
<civodul>cbaines: to debug that, i'd build the thing with -K until i've hit the segfault, and from there i'd run gdb on the core dump
<civodul>now, you need to change the rlimits so that there actually is a core dump
<civodul>so in a build phase, you do: (let ((MiB (* 1024 1024))) (setrlimit 'core (* 300 MiB) (* 500 MiB)))
<sughosha>I need one more help. When I run `guix gc` and then perform upgrade, so many packages (especially so many "rust-...") get download, sometimes also compile locally, which take a day or more sometimes. Is there a way to only remove the previous generations' files and leave all the "native-inputs" of installed packages?
<sughosha>This also hapens if I reconfigure the system.
<jpoiret>do you need to set the rlimit in a build phase because the limits aren't inherited by other namespaces?
<jpoiret>sughosha: I don't think there's an easy way to do so currently
<jpoiret>when i'm tight on store space but need to run guix pull, I usually check the size of store items with ncdu and try removing the bigger ones, then `guix pull`ing, then `guix gc`
<AwesomeAdam54321>sughosha: To delete packages from all previous generations you can do `guix package --delete-generations`
<sughosha>But that doesn't delete files from store, right?
<cbaines>there should be substitutes for that derivation, so you should be able to download them if you run guix build --no-grafts rust
<cbaines>if you run guix build rust, it'll do some grafting locally, but that's usually pretty quick
<sughosha>Ok. Thanks. This would save so much of time for me.
<jpoiret>that should all happen when reconfiguring though, so I don't think the problem is gone
<paul_j>Good afternoon guix! I am working on a channel of my own, but while testing it thermald has stopped building with an error (unrelated to my channel). The werror has resulted from "-Werror=depricated-declarations", and a deprecated function in the thermald source. How do the compiler error settings get made?
<cbaines>civodul, jpoiret I'm building with the setrlimit thing now, and I get this output: Segmentation fault (core dumped)
<cbaines>civodul, jpoiret I think I've got gdb opening the core file now, although I'm not sure the backtrace provides much information, apart from the segfault probably happens in some jit related code https://paste.debian.net/plain/1231401
<cbaines>is there anything specific I should include in a bug report?
<apteryx>haha, I think I've found the problem with wip-initrd-rootflags; the (if root-device ...) condition I touched; I flattened and that's wrong
<apteryx>I should have dropped the 2nd branch of it
<apteryx>or is there a use case of using our initrd without any root file system at all?
<jpoiret>looks like it's erroring while trying to display a backtrace
<jpoiret>although that's not the root cause of the SEGFAULT :p
<jpoiret>i think the people over at #guile will be able to help you help them
<apteryx>civodul: I don't see where changing '--root' to 'root' in the initrd affects the parameters file; it records the root file system as a distinct "root-device"
<civodul>it's a good idea to remove those "--" anyway :-)
<civodul>we can also replace "--repl" with "guix.repl" or "gnu.repl"
<apteryx>perhaps, for consistency! although these don't have their equivalent in Linux so nobody has an expectation on them, and it could be argued that having them prefixed by '--' makes that more obvious
<paul_j>Good afternoon all. I am getting a build failure on thermald. It has been working all morning (I am doing some work on my own channel, and therefore reconfiguring my system repeatedly). The build failure suggests the compiler option -Werror=deprecated-declarations has now been set. However, I see no code changes to the guix repo, nor the thermald repo which could have made this change. Where should I look next?
<apteryx>so the parameters file is used to keep per-generation kernel command-line arguments, that complement what's in grub.cfg?
<jpoiret>paul_j: it's possible that a new gcc version is the culprit, however that issue would have already cropped up 2 months ago
<jpoiret>also, maybe an update to the package brought a new compiler flag into eg the makefile
<paul_j>I don't see any changes to the thermald code in their github repo. The version number certainly hasn't changed, but of course I understand that is not always a good indication of when code changes!
<paul_j>It feels like there is some sort of global change being made somewhere which has caused this.
<paul_j>...but I can't see any changes to the guix repo either which could be responsible (at least not today).
<jpoiret>you could try bisecting the change that caused this issue?
<djeis>So I managed to PXE boot a guix system with an nfs root, with a little bit of bodgery involving busybox's udhcpc, but now I'm trying to mount the store separately from the root fs and I'm running into an error from the getaddrinfo call in gnu/build/file-systems: "Servname not supported for ai_socktype". I'm using a raw IP address for the nfs server, but am I right in there not being a simple way to skip that call? And, are there any suggestions for how
<djeis>to deal with that error? From the searching I've done it feels like something to do with the limits of the initramfs, which wouldn't surprise me given my aforementioned hacks to even get network access there in the first place.
<jpoiret>the function is newly marked as deprecated which is why it fails
<paul_j>That makes sense. So I should have dug around to see where the offending function is defined then.
<abrenon>djeis: what you're attempting is so cool !
<abrenon>so would the store also be mounted from NFS ?
<jpoiret>paul_j: it seems the issue is not resolved upstream, i don't even see one open
<paul_j>Should I post an issue on their github page then?
<jpoiret>well, I don't see anything that would cause -Werror=deprecated... on their side, so it should still be able to compile
<djeis>abrenon: That's the theory. If I get it right I'd like to use a central guix daemon with an nfs-shared store for a bunch of netbooted machines.
<paul_j>So is the compiler setting a guix setting then?
<jpoiret>maybe, i don't really know where this could come from
<djeis>As I said, I already managed to use the grub-efi-netboot bootloader and a PXE server to netboot a standalone root+store. Now I'm trying to have the initramfs mount the same store as my main build daemon but separate from it's root fs.
<djeis>Perhaps I'm insane, but from the success others seem to have using guix in cluster environments I feel like it ought to be doable.
<paul_j>I guess the other question for me is why did it work at all today? I have been running guix pull and system reconfigure successfully several times this morning, but the upower update was made uesterday.
<djeis>And I probably need to correct some of the options for the nfs mount- when doing an nfs mount for the root you have to pass the addr= explicitly yourself since that code wasn't integrated in to the mount root routine in linux-boot.
<djeis>You'll also have to my custom mapped-device hack to run udhcpc.
<djeis>Yea, if it used gethostbyname or getaddrinfo without the "nfs" service arg it'd be fine- just tested in the initramfs emergency repl.
<djeis>And I don't think the code in build/file-systems is actually using the service info.
<philip>Is there a package I can install to get a local copy of the Guix manual as HTML (as oposed to info)?
<djeis>I wonder I can solve this in the short-term with a dedicated root+store on nfs, as I was doing before, but then mount over the dedicated store with the shared one once past the initramfs...
<xelxebar>sneek: later tell lfam, Thanks for the poke. In this case, I was running essentially bare-bones.tmpl, so ntp wasn't even running! IIRC, the ntp-configuration defaults to setting allow-large-adjustment? to #t which apparently corresponds to the -g option of ntpd. The guix man pages don't mention that option, but looking in the sources, it says -g allows adjustments of "up to 68 years in the past or
<mroh>sneek: later tell philip, I don't think there is a package for that (a 'doc' output for guix might be an idea, though), but you can `guix shell -D guix -- make html` in a guix git repo to generate html doc.
<jpoiret>djeis: sorry, I was away for a little while. linux-boot is in dire need of modularity, but that'd require some work
<lilyp>civodul: re racket I'm only doing review on a machine without commit access atm. This shouldn't be an issue, because I'll have more time next week to apply them, but someone else could take over if it falls into my office hours
<lilyp>sneek later tell civodul re racket I'm only doing review on a machine without commit access atm. This shouldn't be an issue, because I'll have more time next week to apply them, but someone else could take over if it falls into my office hours
<vldn>Someone successfully used xtensa-lx106-elf-g++? I made a platformio package (http://ix.io/3PXM) but everytime i run "pio run" it say xtensa-lx106-elf-g++ not found, even if the file exists (downloaded from pio run automatically on first run) in ~/.platformio/packages/toolchain-xtensa/bin, ldd shows this: http://ix.io/3PXZ , so everything seems to be linked.. maybe a 32bit userland is required or
<vldn>something? "file" shows ELF 64 Bit executable ..
<djeis>jpoiret: No worries :) if you (or anyone, really) could think of a better solution to doing initramfs dhcp than my busybox hack that alone would clean up a lot of what I'm doing. Ultimately this nfs store trickery is far from necessary since I can do nfs for the root.
<jpoiret>i think your busybox hack is the way to go for now
<jpoiret>it's just, having to use it through a mapped-device like this is pretty ugly
<jpoiret>you need to setup through DHCP, so you need a DHCP client, seems ok to me
<djeis>Yeah, but I can't think of another way to sneak my own code in to the initrd that doesn't involve me reimplementing base-initrd.
<jpoiret>oh for sure, it's just too bad that it's the only good solution to this
<batalie>is there a list of programs/services guix home import picks up? i guess i could read the code, but i don't have the guix repo cloned on this machine :)
<batalie>mine only picked up bashrc and i think there should be at least 1-2 more..
<apteryx>which procedure is responsible for writing the system/parameters file?
<lifestronaut>I'm trying to install guix, and I'm at the "guix system init <path to config.scm> /mnt" step. I'm getting a large error and I can't figure out how to scroll back in the terminal to see what the error is. How do I scroll through text in the terminal?
<rekado_>no wonder our aarch64 builds largely fail: while setting up the build environment: a `aarch64-linux' is required to build `/gnu/store/0hc7inxqcczb8mq2wcwrcw0vd3i2agkv-llvm-11.0.0.drv', but I am a `x86_64-linux'
<rekado_>looks like the qemu emulation is still set up and isn’t actually working
<djeis>lifestronaut: You need to capture the output of stderr, not stdout.
<lifestronaut>All that trouble to discover I had a parenthesis in the wrong place... ugh
<rekado_>lifestronaut: this sucks… :-/ A well-configured editor can help there, but sometimes it’s just the wrong grouping.
<lifestronaut>It's the nonguix iso, whichi I assume only has whatever is on the guix iso by default
<lifestronaut>I was using nano, but I should have attempted to use emacs
<apteryx>I'm thinking to handle gracefully renaming our kernel arguments, it appears best to bump the version of the boot-parameters record and determine the course of action based on it.
<apteryx>that way when reading old parameters file, we'd be able to say 'ah, so this is for a generation that didn't understand parameter Y' and adjust the grub config output to use the legacy parameter X instead.
<vivien>sneek, later tell civodul my gcrypt ECC problem was because I did not set the rfc6979 flag in the data sexp, and I used "dsa" as a signature type instead of the expected "ecdsa"
<jeko>Hey Guix ! I build my profile using a manifest containing "guile". And I have a package with guile-3.0 in inputs. I my profile it is Guile 3.0.8. When I guix shell my-package I get Guile 3.0.7. which guile package should I put in my inputs to get the same as in my profile ?
<stikonas>I don't know the origin of the term though
<rekado_>hey, I got a rockpro64 board with SATA adapter and just installed a minimal Guix System with u-boot on an SSD.
<rekado_>does anyone know how I can make the board use the u-boot on the SSD?
<FlaminWalrus>How does one compare packages by name? I'm debugging (lset-difference eq? %base-packages '(sudo nvi nano wireless-tools)). Comparing the value of e.g. the sudo symbol by evaluating (%base-packages) and (sudo) in a guile REPL yields different objects. eqv? didn't seem to work either.
<cbaines>FlaminWalrus, maybe compare against the names of the packages, rather than the record
<cbaines>also, package names are strings rather than symbols
<the_tubular>Is there something like docker network for guix container ?
<cbaines>FlaminWalrus, you could also change the other side of lset-difference and use a list of packages, rather than a list of symbols