<sneek>civodul, apteryx says: about the hook, it seems quite zippy; haven't measured though.
<sneek>civodul, apteryx says: I'm not sure we can get rid of hooks entirely, just as we can't get rid of search paths or wrappers; it's good to try to minimize them and have them blazing fast or precomputed though, as you had mentioned.
<nckx>jpoiret: <how can we prevent generation mismatch between an initrd and the resumed kernel it sets up> Oh? Could you explain more?
<jpoiret>well if I'm not mistaken, one of the possible paths for hibernation -> resume is to let the initramfs load the resumable image (this is what is done on arch for example), but if the user `guix system reconfigured` in between there could be a mismatch between the system used by the suspended image and the initramfs launched by grub
<jpoiret>(couldn't find yet if the ACPI S4 state has a different path than just cold booting to initramfs and letting it handle the resuming operation)
<jpoiret>the good news is, the suspend/resume features of the kernel have a pretty simple userspace interface via some device, which i could leverage to write a completely custom suspend/resume procedure in the guile initramfs
<jpoiret>and so we could track the system generation associated to a resumable image, along with writing it wherever we would want, possibly with compression (zstd is a good candidate)
<nckx>jpoiret: So what happens in your scenario is you get (kernel n+1 & initramfs n+1) → (kernel n & initramfs n). No mismatch.
<nckx>With → being ‘resumes the hibernation image from swap’.
<jpoiret>yes but that still means that a newer generation is asked to resume an older generation, which might not interact well (ie the resuming mechanism has changed), and is also "breaking the promise" of loading the newer generation
<jpoiret>but on the other hand, discarding an hibernated image could lead to simply data loss
<pinoaffe>hi folks, I just did a `guix pull` and was kinda surprised to see that "yaml.el" was packaged as "emacs-yaml" rather than "emacs-yaml-el" - I think this is inconsistent with how other packages are (re)named in guix
<jpoiret>on a related note: can i use channels with ./pre-inst-env in a simple way? i kinda hijacked GUILE_LOAD_PATH previously with the built channel in the store, but it's not very clean
<nckx>jpoiret: <ie the resuming mechanism has changed> Has this happened in practice? It sounds like a hypothetical problem otherwise, whilst adding real complexity that could lead to real bugs.
<jbv1[m]>Hello guix ! Question: what is your philosophy wrt other package managers like pip or Julia built-in Pkg.jl ? Should a user be able to use them in parallel with Guix ? Or should guix completely overtake package management duties ?
<jpoiret>guix should overtake package management duties surely. you should be able to use those package managers locally though as long as you don't mind them being stateful, and not understanding what guix does (possibly leading to mismatched dependencies)
<jpoiret>if you need a package that isn't in guix, you can most of the time import it with `guix import` though
<vivien>I don’t know if there’s an importer for julia
<zimoun>jbv1[m]: About Julia built-in Pkg.jl, it is probably currently broken.
<jbv1[m]>ok. I ask because I have a patch for the julia-build-system which allows julia Pkg.jl to "see" packages installed with guix and use them instead of trying to install them
<jbv1[m]>btw I think that some packages in julia-jll have unecessary dependencies, as the dependencies that are noted in "Project.toml" do not discriminate between building dependencies and runtime dependencies.
<talos>Hi guix, good day/afternoon/evening whereever y'all are
<jpoiret>mhmmm, guix builds on wsl seem to sigsegv a lot... so it's either: 1) build on wsl but some big packages can't be built 2) build on laptop and just freeze because i forgot to stop my browser beforehand
<vivien>The guix daemon uses some linux-specific stuff to build in containers, I wouldn’t take the risk to use it on wsl.
<nckx>mothacehe is probably the best person to ask.
<nckx>roptat: I think it's correct. One could say (I guess) that we should set LC_ALL globally for ‘reproducibility’ or something, but keeping to close to the command that really needs it is better IMO.
<qzdlns[m]>is anybody programmatically grabbing mailing-list archives from sourcehut? mbsync -> l2md won't grab this uri as an archive (probably because it isn't an archive, but I can't find docus anywhere) -- (uri . https://lists.sr.ht/~abcdw/rde-announce)
<GNUtoo>btw, when running 'lightdm' as root I get '** (lightdm:190: WARNING **: <hour>: Failed to get list of logind seats: GDBus.Error:org.freedesktop.DBUS.Error.ServiceUnknown: The name org.freedesktop.login1 was not provided by any .service files
<user1>do you know about an e-mail provider i can use from tty?
<GNUtoo>And there are several guides, including one for registering
<GNUtoo>Most of them work from a terminal with programs like Mutt, but I'm unsure if they allow registering from the command line
<vivien>I’m starting to appreciate guix home. I made myself a .guile init file that will record the load path, extend it to guile-readline and guile-colorized, load these, and reset the load path. Now I have readline and colorized activated, without having them installed in the guix home, without visible modifications of the load path.
<zap>Anyone running cuirass? How one deals with channels that depend on guile libraries? I have a chanel that imports guile-parted and evaluations fail because parted is not available during build.
<zap>I first thing came to my mind is to wrap the specifications list gexp that is passed to cuirass service config in (with-extensions ... (with-imported-modules ...)) but it doesnt seem to have an effect
<GNUtoo>hmmm pkill gdm + elogind-inhibit doesn't work
<GNUtoo>In Parabola /usr/share/dbus-1/system-services/org.freedesktop.login1.service is part of systemd, so I'll try to find it in Guix
<nckx>Updating the hash leads to a --source with a populated waflib/ directory here.
<thorwil>nckx: i did a git clone without caring about the submodule and generated a hash for that
<thorwil>guess that means i need an argument to git to have the submodule included, then build the hash
<apteryx>rekado_: I think I'm starting to understand the nscd/dns issue
<nckx>So (recursive #t) is an option used during fetching, and it will *result* in a different directory layout than a non-recursive checkout, and this will in turn change the hash. But it is not itself *hashed*: if you already have a directory of the right name that matches the old hash, then you add (recursive #t), Guix will not even bother re-fetching the sources with the new option because it already has the hash you asked it for.
<apteryx>on my system I had disabled IPv6 in network manager (my previous ISP didn't support it well), but my new ISP does support it it seems. And it seems that, even when disabling IPv6 in networkmanager for my main connection (wifi), somehow DNS resolution would still get IPv6 entries, and nscd prefers that.
<apteryx>I'm not sure how the problematic host name got resolved to a *local* IPv6, though: 2607:fad8:4:6::234
<nckx>thorwil: It's like changing the URL of a tarball without changing the hash. The URL isn't the identifier; the hash is.
<apteryx>ping 2607:fad8:4:6::234 -> unkown host, the same as 'ping problematic-host'
<vagrantc>seriously, you shouldn't have to explicitly think about ipv6 ... it's better :)
<apteryx>back to my problem, it gets even better: I've now disconnected from the VPN adding a unreliable DNS server to /etc/resolv.conf. Now host jenkins.jami.net -> 192.168.51.9 (no ipv6). Pinging that ipv4 works. but 'ping jenkins.jami.net' still says unknown host
<roptat>user1, the suggested solution (I don't know if it works, but it's worth a try) is to install the following: guix install xinit xorg-server xf86-input-libinput xf86-video-fbdev xf86-video-nouveau
<roptat>(maybe replace video-nouveau with the one that corresponds to your graphics card)
<roptat>2. create a file, ~/.xinitrc that contains only the line "exec xterm" (for now)
<vagrantc>been a while since i booted this thing: Authenticating channel 'guix', commits 9edb3f6 to 44d0acf (2,141 new commits)...
<thorwil>the old ingen package has a bunch of RUNPATH adjustments, but even with those back in, i get: /gnu/store/lrwkghbnx5b991hw0jagzpyy2ddhbz66-ingen-current-0.0.0-2.b760e11d5/bin/ingen: error: depends on 'libingen-0.so.0', which cannot be found in RUNPATH
<lilyp>speaking about evil, I love me some --verify=content,repair, but how realistic would be a hash collision in some files? :P
<nckx>thorwil: line contains the match of the entire regexp, which in this case is the entire line. Subsequent variables match () groups, in order, so here prefix will contain whatever (.+) matched, and is used to maintain the previous level of indentation.
<nckx>‘Things that are more likely than a SHA-256 collision’ is probably an amusing list.
<nckx>jpoiret: File Systems have their own node, so I'd say go ahead.
<nckx>jpoiret: Aside: I assume this will finally address swap priority & allow for proper striping, and for that I thank you, because that's been on my ‘one day when I'm not doing something else’ list for ages. That day is an elusive little bugger.
<jpoiret>mhmmm true, although maybe i should consider having 2 types (swap-file and swap-partition) vs 1 type to avoid too much repetition in the swapon parameters
<jpoiret>but good idea, i'll add swap priority to that
<lilyp>nckx: just to be on concept, the tracks should all have something collision-esque in them
<nckx>ss2: What I do, which is not generic at all, is take care of each service with special needs (opensmtpd, znc, from memory) in my dehydrated hook. In theory, Guix services could extend the certbot service, which then constructs some kind of hook… Maybe ‘neat’, definitely ‘ugly’…
<lilyp>e.g. "A car crash that kills everyone you know"
<nckx>I had that! But it was more like ‘Everyone you love gets hit by a beemer (And dies) (Sorry)’.
<nckx>Luckily, ‘Guix releasing in time’ is still more likely…
<vagrantc>so, in attempt to cure guix of "This packages" ... i'm trying to write a lintian check ... and trying to write a simple reduced case but there's something i'm not getting about string-contains: https://paste.debian.net/1216311/
<vagrantc>basically string-contains never seems to match ... but ... but ...
<nckx>vagrantc: Oh, I literally just pushed the quick fix. So don't pull & wonder why your linter fails — I hope — to find anything.
<nckx>You just rubber-ducked me (ew) in a way: I was going to say ‘oh, for some reason I always confuse the argument order of string-contains, as well as string-prefix?’ but now I noticed… their argument orders *are* reversed!
<apteryx>networkmanager is weird, it puts a VPN DNS at the top of /etc/resolv.conf, even I told it "just use it for ressources on its network" (which to me sounds like a fallback more than my primary DNS)
<podiki[m]>nckx: so are you saying we could have more staging-type branches to separate out big changes instead of just one core-updates? I feel like we're making work more difficult than it needs to be especially if we have compute power to spare for compiling to easily try out with subs