<mbkamble>Hi. What is the correct command sequence to shutdown "user shepherd" after completing "guix home reconfigure ...." before doing a desktop session logout. Presently after logout and login, the shepherd process and all sessions under it (eg gpg-agent) from the old session are still active when I login. This there are multiple "user shepherd" and
<mbkamble>user services after several desktop logout and logins.
<mbkamble>Should I just do a kill -9 PROC_ID_OF_USER_SHEPHERD before logout?
<unmatched-paren>I'd have thought they'd target places like Reddit, Discord, possibly Matrix; more popular networks and sites whose residents are perhaps more susceptible to this kind of thing... Apparently not :)
<PotentialUser-50>Hello. Got Guix on my pinephone. Trying to install emacs-next-pgtk, but the whole phone crashes when building. Very new to Guix, but I think it may have something to do with the phone being low-spec. Is there somewhere I can specify the -j2 make flag or equivalent?
<yewscion>mbkamble: Does `herd stop shepherd` not work for this use-case?
<gnucode>sneek: later tell nckx that I have updated my opensmtpd-records patch for a version 2 that includes texinfo documentation. Version 3 of the patch will try to format the code to guix's prefered scheme format.
<ncbfg36>I am having trouble installing guix to LVM volumes in a luks encrypted partition on a system running libreboot firmware. This is the output of running "guix system init /mnt/etc/config.scm /mnt" https://paste.c-net.org/GrievousTrunks and this is my config.scm adapted from bare-bones.scm https://paste.c-net.org/LacedDesign . Looking at search results I'm assuming that i've made some error in my config.scm
<ncbfg36>but i'm struggling to work out what's going on. I've booted installer, opened luks volume, installed lvm2, activated and mounted LVM volumes. Am I missing something obvious here?
<ncbfg36>Since the last mentioned ice-9/boot-9.scm raises wrong type argument have a made an error in the bootloader section?
<ncbfg36>raghavgururajan: thankyou for looking into this. The two sources you mentioned are the ones I referred to when setting up. I will look over your config.scm to try to identify any significant differences. I am new to guix so it's all a bit mysterious to me
<raghavgururajan>ncbfg36: Found it. The syntax for `swap-devices` has changed after those guides were made.
<ncbfg36>I tried commenting out swap-devices completely and I get that error result again
<jpoiret>you'll want (swap-devices (list "/dev/mapper/GUIXVG-swapvol")) for now
<ncbfg36>jpoiret: okay thanks. So now i'm dealing with the original error.
<ncbfg36>I've started with the bare-bones.scm located on the install iso and just added what i need to have the simplest starting point. As far as I can tell the syntax is correct and the brackets are all closed off in the right place.
<jpoiret>ncbfg36: your (file-systems (append (list ... %base-file-systems))) isn't parenthesized properly
<jpoiret>it should be (file-systems (append (list ...) %base-file-systems))
<jpoiret>you should use an editor that highlights pairs of matching parentheses
<ncbfg36>jpoiret: ahhh I thought the final bracket after %base-file-systems))) was supposed to match the leading bracket (file-systems
<sneek>nckx, gnucode says: that I have updated my opensmtpd-records patch for a version 2 that includes texinfo documentation. Version 3 of the patch will try to format the code to guix's prefered scheme format.
<silicius[m]>I found the source of the problem (I think). pymdown-extensions uses hatchling instead of setup.py to build and install, which is not currently present in guix (and most likely it is not supported by pypi too)
<ncbfg36>nckx: Oh I see what you mean. I just found guides online. Need to snap a few pins and solder a wire to make a bridge. Doesn't seem to complicated
<nckx>silicius[m]: I don't understand. I was just trying to reproduce your report and (pypi-uri "pymdown_extensions" "9.4") is perfectly valid.
<dhruvin>Thanks rekado. Is it possible that `guix system image` command may be generating an image with older guix installed in it?
<ncbfg36>raghavgururajan: I hadn't heard of OSboot. The reason I went with T500 (years ago, only just found the time) was reading that it's the last generation that could remove intel ME completely. I'm not super paranoid about it but I thought "why the hell not". The T440p has much more useful specs though.
<nckx>dhruvin: I think the guix is always older, being the 'guix' packaged in the generating guix version (i.e., 'guix show guix' vs. 'guix describe').
<dhruvin>IIUC, when I'm doing `guix system image ...`, I get the `guix show guix` one installed. I need latest guix in that image, so I run `guix pull` inside a vm of that image to install latest guix (which is the `guix describe` one, as you mentioned).
<dhruvin>Am I doing something wrong here? As in is there another way to have latest guix installed with `guix system image ...`? Or some other way to update that old guix to latest in aforementioned image?
<nckx>I do not see anything wrong, this is all expected. I'm not aware of a built-in way to directly use the 'outer' guix as guix inside the image without pulling. I don't know if the versions are sufficiently apart to be responsible for your problem, just pointing out there will always be a difference as it's currently designed.
<dhruvin>Okay. I'll see if the versions are too apart to cause this issue, and if they are, how to package somewhat newer version of guix with `guix system image`. Thanks.
<nckx>dhruvin: There's a script (I forget what it's called, sorry) to update it, because it's a minor pain to recover from botched updates, but code-wise it's a bump like any other.
<jpoiret>there are many issues with trying to provide the current Guix for a system image
<jpoiret>we'd need to keep the sources around in the store somehow
<jpoiret>i've been tinkering with adding posix_spawn (it's nearly ready for prime-time, i'm squashing the failed tests right now) and the different interactions between the guix package and the guix pull guix and their respective build systems have been annoying
<jpoiret>it makes it harder for someone who hasn't stared at that mess for long enough to understand which modifications end up where and when
<jpoiret>i think one of the blockers for a change with how we currently handle guix-in-guix would be to compartimentalize the daemon (and now the extensions also), that way a new commit in guix wouldn't cause guix-daemon and guix-extensions to be rebuilt
<jpoiret>otherwise that'd be wasted CI time, and bad `guix pull` substitution
*dhruvin is looking for that script in guix source
<nckx>It might not be in a separate file. Start with 'guix edit guix', I think there's a comment there. Else where would I have read it...
<jpoiret>civodul: i'm modifying (guix inferior) to use the glibc posix_spawn instead of primitive-fork, and everything seems to work well right now, but I seem to have broken the "&inferior-exception, legacy mode" test and i don't really understand how it's supposed to work right now
<jpoiret>you've written that test, that's why i'm pinging you! it claims that open-inferior-pipe would run "guile" and not "guix repl", but the implementation of open-inferior-pipe says the opposite
<jpoiret>to make matters worse, stracing the test shows that the execl() done by open-bidirectional-pipe errors with ENOENT (because bin/guix doesn't exist in the repo anyways)
<unmatched-paren>(configuration (home-environment ...)) or (configuration (local-file ...)) ; can be replaced with any file-like object
<yewscion>Hello all, I am trying to play a MIDI file on my Guix install, but when I load the FluidR3Mono_GM.sf3 file into timidity the sound is /incredibly/ distorted. Is there something I'm overlooking? I am used to using .sf2 soundfonts, but I'm happy to see a freedom-respecting format exists instead, and if I can get it working I hope to use that going forward.
<morganw>If anyone happens to use Common Lisp, how would I work around this problem when requiring a library? "ASDF could not load esrap because OS-FILE-ERROR(EROFS): Read-only file system."
<tissevert>yewscion: sorry I'm not on my guix system right now but I'm willing to test if I have the problem too, I intend to use guix to make music at some point
<yewscion>tissevert: Awesome, thanks. Let me know if You don't; Could very well be my config.
<yewscion>morganw: I just started SLIME on my Guix after installing cl-asdf and sbcl-esrap, and got T as the return value when I tried (asdf:load-system :esrap). Is there a more complex command You are running, so I can test it?
<morganw>It seems to only break when trying to recompile the library, when I use clisp as the lisp. If I use SBCL then it seems to work.
<morganw>I wonder if clisp is actually "unsupported" outside of bootstrapping because it looks like it is trying to compile paths that have "sbcl" in them.
<morganw>(I presumed that cl-esrap was portable and sbcl-esrap would have been specific, I have both packages installed)
<yewscion>Ahh, that would be unfortunate. I rarely fall back to clisp, but it's good to know it's usable if I need/want it.
<yewscion>morganw: I ran `guix shell --pure clisp clisp-esrap clisp-asdf bash` , then ran clisp. In clisp, I ran `(require "asdf")` and then `(asdf:load-system :esrap)` and it warned about SET being used but otherwise returned normally after compilation.
<yewscion>I can upload the log somewhere, if You think it'd help.
<yewscion>Shot in the dark: You don't have Your `common-lisp` cache dir in guix-home, do You? I can see that causing this problem; I had a similar issue when setting up a emacs with my custom.el file.
<tissevert>unmatched-paren: is there a place for feature request ? opening an issue sounds a bit too much for just a simple idea like that
<tissevert>any pointer as to where to start from to implement such a thing ?
<morganw>yewscion: Thanks, it works for me with your 'guix shell' example too. I do have all of my packages installed with 'guix home', but I haven't specifically done anything with a the cache directory. Is just installing all of these packages with 'guix home' enough to cause a problem?
<tissevert>oh, ok ! thanks ! I'll try and open one describing this idea in the next few days
<nckx>Well, once my overpriced fan & bucket o' thermal paste have finished their grand tour of every continent except the right one, unmatched-paren, I will at least have a look, despite non knowing a thing about Go.
<nckx>I think they are currently on an Arctic cruise.
<yewscion>morganw: Hmm, I don't think guix-home should cause an issue in that case. I added sbcl and sbcl-esrap to the guix shell command above, and I was able to reproduce this error. Seems like a bug to me, but I'm still looking for where the source is. Might be worth making an issue, if You are willing to do so, on issues.guix.gnu.org
<yewscion>IIUC, it seems like the inclusion of both SBCL and CL libs are causing SBCL libs to be prioritized, at least in this case. May be an issue with a load path?
<yewscion>The system-wide equivalent of ~/.config/common-lisp is /etc/common-lisp, and because asdf doesn't have the concept of which implementation it is running on, it loads those files even under clisp, which overrides the registry for asdf in clisp to be that of sbcl.
<morganw>yewscion: Thanks for tracking down the problem. Do you think it is a guix issue or does asdf not provide any mechanism which would allow for more dynamic switching?
<gnucode>nckx: I updated my opensmtpd-records patch to include texinfo documentation. I think the documentation looks somewhat good.
<yewscion>morganw: I would test, but I don't have a machine with another OS handy. That said, I can't remember ever having an issue with this on other OSes, and I've always had both installed... Though of course, I was using quicklisp for that.
<nckx>Thanks gnucode! I'm sure it looks great, I'll take a look when I have my PC back.
<yewscion>I would guess that, because of the generalities introduced by GNU Guix, this is a Guix-centric problem. In most other systems, You would point asdf to different locations based on Your lisp-specific package manager or Your own development process.
<yewscion>It /should/ be fairly straightforward to have each implementation load an implementation-specific directory for their packages in an init file, though I've not done that. I used to specify, for instance, (:tree "Documents/") in my own home directory to add my own asd files to the system; I wonder if You could specify a specific one per each implementation?
<nckx>unmatched-paren: I was kind of curious when I saw your 1st mail what you expected it to do.
<unmatched-paren>nckx: I'm not sure why I expected aerc to download all the messages in the thread and display them (so that i could properly reply) when I replied to the thread
<unmatched-paren>Now awaiting a reply in #aerc regarding how to import a mbox file...
<nckx>Aerc must be magic if it can do the former :)
<reyman>@nckx i repost the comment to say, yay, rm /var/lib/gdm solve the problem for me :)
<nckx>unmatched-paren: Well, I'm still not clear exactly what you expected to happen. Debbugs would send you backdated copies of all previous messages to any thread you reply to whilst unsubscribed? (If that sounds thick, that's just me, not you.)
<nckx>It's not NNTP, not that I've ever used NNTP.
<nckx>I've never heard of a list that worked that way.
<unmatched-paren>nckx: I should look into the internal workings of email. Yet another item for the Things ( Is Hoping To Look Into But Probably Never Will Bother To list :)
<yewscion>morganw: Successfully worked around it with an init file for clisp.
<gnucode>nckx: The code as is, probably needs to tweak it's styling to fit into Guix's style guide. Also, you can definitely port your server to use it, But the code doesn't really work for creating opensmtpd filters. at the moment.
<nckx>There's no standard way for a mail client to fetch mbox archive from a list, although you could write a plugin/script that does it for mailman, or try to make all MLMs use standard URLs, ... That would still be a Web 'side channel' though, in se unrelated to any true e-mail protocols.