<ixmpp>Reinhilde: wait what are you doing here <civodul>apteryx: the on-line manual appears to be building fine now, at last! \o/ <raghavgururajan>> drakonis: should gdm still be the default desktop manager in %desktop-services? <raghavgururajan>lightdm is a good canditate for default, as it is desktop independent. <podiki[m]>I like Stump (common lisp yay), but ran into issue with monitors plugging in/out (which I don't do very often) ***sneek_ is now known as sneek
<Reinhilde>Is there a way to enter an empty value for, say, 'bootloader' in the first path argument of `guix system init', and still have it do the thing? <drakonis>you mean like not installing a bootloader? <ggoes>when / how does guix load its emacs packages? i have emacs-geiser-racket installed for my nonroot guixsd user, but it doesn't seem to get loaded with emacs nor with M-x guix-emacs-autoload-packages <Reinhilde>are errors encountered while executing 'guix system init' on a system other than Guix on-subject for #guix? <Reinhilde>Do I need to un-authorize some or all substitution servers? <Reinhilde>... I don't speak lisp... am I on the wrong system <ggoes>hmm my user's .guix-profile isn't being added to $EMACSLOADPATH it seems; guess that's not automatic <lfam>Going back to that earlier talk about CONFIG_MODPROBE_PATH, I tried booting my Debian system with the work-in-progress Guix config... <lfam>Like... why is all this stuff not working?? <lfam>I'm gonna see what really happens when it's left unset <apteryx>sneek: later tell civodul re on-line manual fix, thank you, you rock! <podiki[m]>(easy?) question: easiest way to replace packages already in guix locally would be to have a git of guix and set that as the guix channel? <lfam>That's the easiest way to do it that works like Guix <lfam>There's a pre-Channels thing called GUIX_PACKGE_PATH that is similar except you don't have to "build" the channel <lfam>I like it because you don't have to build the channel, so it's super fast. But you lose the nice provenance tracking <podiki[m]>wasn't sure if you can easily shadow existing package defs (e.g. local channel that has a different def'n of a package)? <lfam>I think that should work. I'm not sure how Guix chooses which package will win <lfam>If you look at my repo you'll notice I rename the packages that I am making variants of <podiki[m]>yeah, renaming makes sense you can modify package builds to use different input I know <podiki[m]>but I think it would be hairy for lower level dependencies that end up everywhere <lfam>Yeah, it depends on your use case <podiki[m]>it's fun having the whole system to mess with, barely touched packaging in other distros but find guix/scheme makes it very accessible <lfam>The manual chapter Defining Package Variants is similar to Package Transformation Options but explains how to do it in a way that's easier to keep track of <lfam>Agreed, I never was able to deal with packaging until Guix. I came from Debian and still use it as a base <podiki[m]>yes, played with that a bit too and is very helpful <podiki[m]>I've only maybe messed with a few basic pkgbuild changes on Arch, but never actually learned it. but put something in a Lisp and I'm all over it <marusich>Making everything a monorepo makes it easier to discover everything. <marusich>Also yeah, you can use the "package transformation options" or see how it's done internally to make your own modifications, but probably the easiest way to customize packages is to maintain a personal fork. Hopefully customizations can be upstreamed to Guix if they make sense. <zamfofex>Is it possible to declare a modifiable variable within a package? The idea being that when modifying the package to create variants, you could modify that variable and have it affect all its uses. <iskarian>another wonderfully general question: why do I only ever see phases used for patching rather than snippets? <zamfofex>It feels unfortunate to me that there are multiple ways to do a similar thing: “patches”, “snippets” and “phases”. They are each slightly different from each other, and are more convenient for slightly different situations, but it’s unfortunate that there is no unfiied way to solve that kind of problem. <lfam>Snippets are basically just for removing non-free bits from source code <lfam>So that `guix build --source foo` gives the free variant of foo <jackhill>zamfofex: in addition to what lfam said, both patches and snippets are for producing sources that is generally useful in many situations. It would be inapproprate to encode a refernece to a store path using those methods, but that's often nessisary and done during the build in a phase. <jackhill>One could of couse apply patches during the build, but then guix build --source wouldn't "see" them. <jackhill>I don't know if that helps, but maybe more insights will make it seem more ok for there to be the different methods. <jackhill>also, phases aren't just for modifying the source, they're for arbitrary build steps, modifying the code is just one thing that could be done. <jackhill>zamfofex: to your question of modifiable variable, I believe the answer is yes! I don't think I have the best grasp on it to explain clearly, but I think you'd just pass it as a keyword in arguments, and then look for it in appropriate phases of the package <zamfofex>I see. That is all fair, I just feel like there is a lot of overlap, at least sometimes, and that can be a bit confusing. <jackhill>zamfofex: you may want to search for what package-with-python2 does. Or the package with other common lisp procedures <zamfofex>jackhill: About the arguments thing: I see! Thanks for the help, I’ll look into it. <jackhill>zamfofex: cool, happy to (try to) help. Best of luck with your exploration <Kitty[m]>Hmm, I notice the matrix client Element isn't on the default channel yet, couldn't find some others either ; anyone know of any which is? <MysteriousSilver>Hello, I tried writing a package derivation after reading the cookbook. It was a fork of surf so I used the same scheme code as surf. Here's the full scheme file: http://ix.io/3svX Installing it fails and returns the following error: http://ix.io/3svL Any idea why? <jackhill>Kitty[m]: yeah, Element is difficult to package because all the JS dependencies are for a difficult knot to untie. looks like quaternion, emacs-matrix-client, and nheko are available. I can't speak for any of them though. I get on matrix via xmpp and the matrix.org hosted bifrost bridge <jackhill>MysteriousSilver: I guess it's not producing a sneedium file to install (maybe the fork is still using the surf name?). A good way to get debug this is to call guix build with the --keep-failed option. You'll end up with something in /tmp, and then you can cd there to see what files are there, and perhaps adjust the install phase accordingly <jackhill>MysteriousSilver: hrm, I'm afraid I'm out of easy idea. Looking at both your package and surf, I don't see where it is going wrong (and thus not where to fix it). <jackhill>MysteriousSilver: yes, that sounds reasonable (or cd-ing before the cp, or doing it with a (with-directory-excursion …)), but it seems like that cp is being generated by the gtk-or-glib build system, so I don't know why it's getting it wrong ***cadmium.libera.chat sets mode: +o ChanServ
<zamfofex>Does anyone know whether it’s possible to try to build all packages using a different toolchain (e.g. a different C compiler or linker). (Probably in a server, I mean.) <zamfofex>I’m mostly just curious, because I recently decided to package the “mold” linker for Guix, and it appears that coincidentally, someone did something similar, but with Nix to test mold against existing Nix packages and whatnot. <irfus>is it practical to define system configuration and profiles within a channel? or should these be kept separate from package definitions? <sneek>Welcome back irfus, you have 3 messages! <sneek>irfus, podiki[m] says: When you have a chance can you submit an updated full patch for mesa with any fixes needed (libepoxy etc)? <sneek>irfus, podiki[m] says: When you have a chance can you submit an updated full patch for mesa with any fixes needed (libepoxy etc)? <sneek>irfus, podiki[m] says: can you check in on the Mesa patch discussion? <irfus>podiki[m]: hopefully this weekend <irfus>re: updating mesa, does this channel have opinions on whether it is appropriate to build mesa with libglvnd support? <irfus>libglvnd is already packaged in guix. And is completely free. And it seems like a good idea to have vendor neutral calls to video drivers in general. But this is practically useful, as of now, only to users with some nonfree graphics hardware. <irfus>but switching comes with the cost of having to patch and rebuild every package that currently looks to mesa to provide libgl.so and friends <irfus>I know there are at least a couple of mentions of this issue in this channel's archives, but there didn't seem to be a clear position... <zamfofex>That’s interesting. I feel like it’s almost related to the question I asked. I think you want some way to have a different package e.g. “mesa-glvnd”, and be able to specify that you want to substitute the regular mesa by this new package in all dependencies, even if it means you’d have to build them yourself. <zamfofex>Or, err... “dependents”, I mean, I suppose. <Kitty[m]><jackhill "Kitty: yeah, Element is difficul"> wait, there is a matrix.org xmpp bridge? <irfus>zamfofex: yeah, kind of. That is normally possible for a user to do with package transformations. Mesa has so many dependents, however, that it's not practical to expect users to actually be able to do that. <zamfofex>Ah, I see. I suppose that’s not useful in your case, but it effectively answers my question. The ‘--with-input’ option is pretty much exactly what I wanted. <zamfofex>irfus: Maybe it could be useful to be able to have downloadable substitutes for specific useful transformations. <zamfofex>I think if that was possible, that’s solve your issue, no? <rovanion>Is it possible to know when the graft applied on texlive will be removed? <rovanion>Sorry, the answer is obviously no if I just think about it. Guess I'm just venting frustration about having my disk run out of space, running gc, and then having to redownload texlive again. <leoprikler>rovanion maybe core-updates merge, but things can get grafted pretty quickly <leoprikler>wip-ungrafting is another source of graft relief, but won't target big things such as texlive IIUC <leoprikler>guix gc --delete-generations only deletes your root user's generations IIUC <leoprikler>not anyone else's generations and also not system generations <rovanion>Yeah that seems right. If my brain fog clears up later today I'll see if I can construct some meaningful sentance for the manual along the lines of "Note: If you want to garbage collect system generations, look [[here]]." <zamfofex>Hello once again! I was actually able to try out the mold linker through my package against some projects, though it seems it failed to build textinfo for binutils. The error is kinda strange, and I suspect it’s related to my system’s slightly outdated package listings (two weeks or so). I wonder if anyone here could have a quick idea to help me out, if it’s obvious enough. <leoprikler>zamzofex isolating just binutils, what happens if you `guix build binutils` normally? <zamfofex>leoprikler: Is there a way to force a build to happen? I ran it, and it just downloaded a substitute, and now even with ‘--no-substitutes’, it seems to not be building it. <leoprikler>if there's a substitute, then chances are that the package itself is not broken <leoprikler>next, try constructing binutils in a way, that only its own ld is replaced by mold and no other ld <leoprikler>for this you'll have to write an scm file, inherit the package and change the inputs <leoprikler>once you verified that binutils would build, we can go further up the tree to see what's wrong with texlive <zamfofex>Can the ‘ld-wrapper’ input be just changed like that? <zamfofex>Because it’s not an explicit input. Can I just use that “mold-ld” packaged I linked as an input to replace it? <zamfofex>Like, if an input has a ‘/bin/ld’ file, will it replace the implicit ‘ld-wrapper’ input’s own ‘/bin/ld’? ***sneek_ is now known as sneek
<leoprikler>zamzofex: Have a look at package-with-explicit-inputs and the with-input transformer <leoprikler>I think the with-input transformer does exactly what you want it to do, but just for one package <bantuist> /msg NickServ VERIFY REGISTER bantuist keO3py7p6IAXhgBu <pkill9>or do it with some kind of daemon, since xfce can also suspend on lid close *bantuist will be right back and check the logs <raghavgururajan>sneek, later tell bantuist: You could try to send-in a request. Let us know their response. :) <tissevert>just wanted that guix is saving my day, it lets me use ardour on my deeply broken devuan install where I can't install anything anymore <dstolfa>tissevert: i guess the only way to fix it is to end up doing `guix system init` (: <tissevert>on my todo list: I'll use guix system to generate VM image to get something useful and demonstrable to the other members of the family, maybe even something directly bootable on metal from a USB device ? <tissevert>and I won't feel like I'm in a cybercafé all the time <tissevert>(simply noticing btw that I had two profiles ~/.guix-profile and ~/.config/guix/current fighthing, and guix package -i ardour put it in the former while the latter was defined in my .bash_profile, but it's really probably just a setup error from my part when I installed it) <dstolfa>am i correct to assume that emacs-next has --with-native-comp? it feels faster <dstolfa>hmm.. that's odd. loading etags for me is orders of magnitude faster than it is in emacs-27 <dstolfa>i wonder why loading etags is so much faster <dstolfa>MysteriousSilver: yeah, i looked it up when you mentioned it earlier -- you're right that it's not there but i'm just confused what made etags so much faster <leoprikler>emacs-next does not have native-comp afaik, we have other builds for that <fnstudio_>hello, it's that time of the month again... when i ask about my GUIX_PROFILE env var... so, that's set (exported) as "${HOME}/.guix-profile" in my .bash_profile, however... <fnstudio_>when running guix pull, i'm recommended to set that to GUIX_PROFILE="/home/user/.config/guix/current" <fnstudio_>do you know what's the recommended GUIX_PROFILE value? <leoprikler>fnstudio_: GUIX_PROFILE is a meta-variable, it can be anything you want and nothing :P <leoprikler>On Guix System, both /home/user/.config/guix/current and /home/user/.guix-profile will be sourced <fnstudio_>MysteriousSilver: right, I should have mentioned that, it's on top of a foreign distro <fnstudio_>leoprikler: right... let me see if, in my system, either of them is a symbolic link pointing to somewhere else or to the other <leoprikler>the GUIX_PROFILE variable only exists to make the scripts residing in their etc/profile directories expand GUIX_PROFILE rather than the store path. <fnstudio_>yes, right, indeed, they point to /var/guix/profiles/per-user/my-user/current-guix and /var/guix/profiles/per-user/my-user/guix-profile respectively <fnstudio_>ok, thanks, i think i only set GUIX_PROFILE to "${HOME}/.guix-profile" in my .bash_profile and that's it; maybe i should source "/home/user/.config/guix/current/etc/profile" before that? <fnstudio_>might that be a way to silence guix pull - which keeps suggesting i should set my GUIX_PROFILE like that? <fnstudio_>also, here's something else that makes me think i'm doing this wrong, if i launch guix describe i'm not told the number of the generation <roptat>fnstudio_, you should source both <fnstudio_>just guix plus the commit hash (and url and the name of the branch) <fnstudio_>roptat: oh i see... in any specific order? MysteriousSilver's script seems to suggest current should come first? <roptat>GUIX_PROFILE is just a convenient variable, but it doesn't have any meaning <roptat>it's not read by guix at all, so you don't have to export it or anything <roptat>just source the guix pull profile, then your user profile <roptat>the order doesn't matter as long as you don't have guix in your user profile, but to be safe, source the guix pull (current) profile first <fnstudio_>roptat: ok, that's great, i suppose that should (or can) all happen in my .bash_profile? <roptat>nevermind, it adds its stuff at the beginning of the variable, so source the user profile first, then the guix profile <roptat>so you'd set GUIX_PROFILE to the user profile, source the profile file, reset GUIX_PROFILE to the guix pull profile, and source it <fnstudio_>ah! that's why in MysteriousSilver says the order should be with current first but then it sources them in reverse order... <fnstudio_>roptat: great, thanks, when you say the "guix pull profile" is what comes up on my system as "current", is that correct? <fnstudio_>i've applied the changes as suggested and it seems to work perfectly! thanks MysteriousSilver leoprikler roptat <Noisytoot>Shotwell (installed from Guix) says "The camera seems to be empty. No photos/videos found to import" for an SD card that does contain photos/videos <maximed>Noisytoot: what is the directory layout? <maximed>IIUC, cameras have a conventional layout for storage media (something with directories named ‘DCIM’) <maximed>if you give it a (different) layout yourself, it is not unexpected that Shotwell won't recognise it <maximed>though presumably Shotwell has some option for importing photos and videos from arbitrary directories, so you could use that? <Noisytoot>maximed, They are all in DCIM, 2 cameras have used this SD card, one of them puts all photos/videos in DCIM/122MSDCF, and the other one puts photos/videos in directories named DCIM/<3 digit number>___<2 digit number> <pushcx>It affects many phones, not just iphones. You can downgrade or wait a bit for the next version, which has a patch that's expected to fix it. <podiki[m]>irfus: sorry for the duplicate messages, sneek was disappearing on me <podiki[m]>irfus: yes, the libglvnd discussion...I'm not sure either, I was thinking we do Mesa to 21.1.x first without changes to build options, that should just work (at least the dependents I checked), and separate out the libglvnd question to another patch series <lfam>More adventures with CONFIG_MODPROBE_PATH in Linux 5.13 <lfam>How is it supposed to work with LUKS encrypted disks? <lfam>The paths /run/current-system or /sbin or whatever are not available before you unlock the device, but Linux needs to load some modules in order to do that <lfam>I'm not understanding something... <lfam>Is there some other location of `modprobe` in the initrd or something? <lfam>How is this supposed to work? <lfam>I'm going to need testers for this update <lfam>Is there anybody with a Guix System on LUKS that volunteers? <luis-felipe>Hi, do you know the website addresses for GNU España and Free Secure Systems Group? There is a bug about broken links for these in the website. <lfam>luis-felipe: You might ask Jose Marchesi / jemarch <podiki[m]>not sure if I understand the question, but usually initrd will need to include a crypt hook <lfam>At least, it has the dm-crypt module <lfam>To clarify, my initial tests of 5.13 were on Debian, because my fastest machine uses Debian. I wrote the kernel config and then tested it on Debian <lfam>I'm building it now on the Guix System machine. I don't have LUKS on that machine, though <lfam>I'm also asking in #debian-kernel on the OFTC IRC network <lfam>It's weird that it used to work. It's unusual for Linux to break like that <lfam>I might report it upstream as a regression <lfam>I'd appreciate it if people using Guix System with LUKS on x86_64 could test <lfam>You'll need to set (kernel linux-libre-5.13) in your config.scm. This branch does not yet update the default linux-libre package to 5.13 <podiki[m]>I'm on a encrypted linux right now (non-guix) and I use the encrypt hook (with lvm) so maybe that's different? <lfam>You know, I forgot that I'm also using LVM+LUKS on my Debian <lfam>In any case, testing on Guix System is necessary :) <lfam>I know a lot of Guix Hackers use LUKS <lfam>Would you be willing to test that branch? <lfam>I think the worst case is you have to reboot and select the previous Guix System generation from the GRUB menu <thecatster_>Has anyone had issues with SSL certificate invalid when pulling? I can’t seem to update my installation image in order to install Guix <lfam>thecatster_: Hm, is it an older installation that hasn't been updated in a while? <lfam>Like, is it 1.2.0? Or 1.3.0? <thecatster_>I downloaded the installation ISO 4 days ago. I’ve never had this happen in the past when installing <lfam>Like, with the `date` command? <thecatster_>How would I set the correct one? (I usually use timedatectl, and that isn’t here of course) <thecatster_>I have other channels, and I assume they weren’t happy either <lfam>How about fixing the date then? `date +%Y%m%d -s "20210710"` <lfam>I copied and pasted the command from search results... `man date` may also help <lfam>Changing the URL, even just the protocol, makes Guix think it's a totally different repo. Which makes sense; Guix can't know it's the same thing. <thecatster_>I feel dumb now. I didn’t realise `date` can set it as well… guess I should adhere to my policy of rtfm more often <lfam>It's good to read, it's good to ask, it's all good <thecatster_>I just prefer not wasting others’ time if I can help it <lfam>Yeah, but sometimes a lot more time will be wasted by trying to figure things out alone. On the other hand, that solo learning journey can be really valuable. <thecatster_>Absolutely agreed. I’ll concede that a balance can be phenomenal <Noisytoot>What is timedatectl for if date can set the date? <thecatster_>You learn more, don’t waste too much time of yours or others, and can help others learn as well <lfam>I'm not very familiar with it but, yeah, timedatectl is part of systemd. So, an integrated approach to managing time <lfam>We could use something like that in Guix <lfam>It's a matter of debate, for sure <thecatster_>Not one I’m too fond of arguing usually. Doesn’t lead to much benefit. <lfam>We need to implement the solution in the last message for the next release <thecatster_>Allowing for that temporarily would let me quickly fix things <thecatster_>How does one help out with implementing things like that? Do you need to be on some Guix team? <thecatster_>I’d be interested in helping out, but am not sure of how extreme the time commitment is. <lfam>There's no formal process for contributing. You just have to get your ideas / code to the people at <guix-patches@gnu.org> somehow <lfam>Yeah, it's on Savannah. But you don't need a Savannah account to contribute <lfam>You can contribute at any level you like <thecatster_>That’s great. I know some OS teams/language teams aren’t like that <lfam>I'm going to check if there is already a bug ticket about implementing this. I should know... but I forgot <lfam>I doubt there is code for it yet <thecatster_>I’m assuming allowing http instead of https connections should be a simple fix, or is it more elaborate? <lfam>The problem with that is that Guix will consider it to be a different repository, and the code authentication machinery will not provide a "chain of trust" as you change from pulling over HTTPS to HTTP <lfam>Instead, we can disable certificate verification when the --allow-insecure-transport option is passed <lfam>This is still safe. HTTPS is not part of the code-signing security model <lfam>We implemented this strict HTTPS certificate verification before we implemented code-signing, because it was easy and we didn't have anything better <lfam>That's another case where it is safe. We know the hash of the expected file in advance, so the only threat from skipping the verification is eavesdropping <lfam>So, we'd need to add the command-line option to guix/scripts/pull.scm, and have it make the requisite change in whatever code it uses to actually perform the Git pull <lfam>(I'm not sure where that is) <thecatster_>Understood, will try to tackle that when I have some time! (If others don’t first) <zamfofex>leoprikler: Are those documented in the manual somewhere? I’m fine looking through the source, but I wonder if they are documented in some section I’m not loking at. <leoprikler>grep is your friend, but w.r.t. documentation i think no <zamfofex>I feel like it would be helpful to have a webpage with all exported names of each module with a link to the source (in cgit or something) just so it’s easier to find things. <zamfofex>There ought to be some way to do something like that automatically with Scheme/Guile, no? <leoprikler>there is a module called (guix transformations), it's impossible to miss actually <zamfofex>Yeah, I found it! I just feel like it’d be helpful to find solutions when you don’t know exactly what you’re looking for. <leoprikler>As far as search is concerned, I recall that dynamic content on gnu.org is a nono. <zamfofex>It could be generated static content. Like, just a list of the exported names. ***iyzsong- is now known as iyzsong
<bricewge>lfam: About modprobe in Linux 5.13, I don't think that new option is really relevant for us <bricewge>Yes, have a look "cat $(cat /proc/sys/kernel/modprobe)" <bricewge>The modrpobe guix uses is actually a wrapper produced by operating-system <lfam>I'm still building the kernel for Guix System, so I haven't tested it there yet <bricewge>So IFAIU we can't set CONFIG_MODPROBE_PATH at build to to be the same as /proc/sys/kernel/modprobe <lfam>The default value is /sbin/modprobe, and if you set it to the empty string, the kernel cannot load modules <lfam>According to the documentation, that is <bricewge>Instead of what I said later setting it to /run/current-system/profile/bin/modprobe should be sufficient; kmod doens't depend on linux-libre or it's headers <lfam>It's taking forever to build on my Guix System, so I'm about to just build it on the build farm <lfam>Then there will be substitutes and anyone can test it easily <lfam>I still didn't figure out a way to use Linux 5.13 on Debian <lfam>No matter what value I choose, the boot is broken <bricewge>I think you should ask Danny about that option new option he have a broader understanding of kernel modules, but I'm pretty sure setting it /run/current-system/ will do <drakonis>doesnt look like they're providing 5.13 there, its currently at 5.10 on unstable <lfam>I'm not sure where to look <lfam>I meant that I don't where to find experimental packages <drakonis>packages with experimental versions will have a link to them <lfam>Unless it's hidden, I don't see a Linux package in the Kernels section <drakonis>the highest debian offers is indeed 5.10 <jackhill>MysteriousSilver: yay, glad you got it working! <bricewge>Tody I found out, that using nftables-service-type broke the other services using iptables, such as libvirt and docker <bricewge>Declaring iptables-nft package and using it in place in iptables for thoses services fix it <bricewge>But I don't know how to upstream such change, any guidance on how to go about this? <bricewge>Patching the current iptables package to use xtables-nft-multi seems drastic, since it would force every one to get on the nftables train <bricewge>On the other hand having a $package-nft package for each package using iptables seems bloated and wrong <bricewge>And we don't have a USE FLAGS feature like yet <drakonis>that's the nix solution for everything lol <bricewge>Yup, that's how they did it for iptables too <drakonis>basically, they generate packages with small variations like different inputs ***o is now known as niko
<pkill9>lmao I curl'd that link, and I thought curl was throwing the error that is that text <pkill9>was really confused why it was running guile <dstolfa>pkill9: hey that's not a bad idea... `gurl` instead of `curl` for guile-curl <pkill9>thought it was failing to fetch the link due to that nss-certs error *dstolfa just wants a guile curl because why not... didn't even think of `gurl` in that sense before boi came up <dstolfa>Reinhilde: what did you run that caused this failure? <dstolfa>Reinhilde: i have found that -M sometimes breaks things in weird ways, i don't really know why, have you tried without? it shouldn't be relevant but still worth a shot <drakonis>i wonder if its an issue being inherited from the nix daemon <drakonis>the guix daemon is a fork of the nix daemon circa 2012 <drakonis>not sure if having multiple jobs behave strangely has to do with this <Reinhilde>just.. what you said about guixd being a fork of nixd <drakonis>i do suspect that jobs silently breaking things has to do the daemon's implementation at the time <Reinhilde>guix substitute: warning: try `--no-substitutes' if the problem persists <the_tubular>most of the commands I run returns : command not found <the_tubular>And the guix daemon is not started. I don't know how to start it <the_tubular>But the daemon fails to start because of WSL though ... <the_tubular>I was messing with my system.scm, then I lost about all commands I could run