IRC channel logs


back to list of logs

<attila_lendvai>civodul, are there any obstacles in front of the #:rlimits shepherd patch, and the shepherd-for-guix patch? ( or shall i just wait a bit more until they pass through some local testing? my server is happily running with them.
<attila_lendvai>if applied, maybe apply #:rlimits first, and then update the second one to include this patch.
*attila_lendvai goes AFK o/
***planglois_ is now known as planglois
<euandreh>civodul: ack, ty
<civodul>attila_lendvai: sorry i haven't had a chance to look into it yet
***jonsger1 is now known as jonsger
<lfam>New option for Linux 5.17:
<lfam>"This instructs the kernel to include the MS_NOEXEC and MS_NOSUID mount flags when mounting devtmpfs."
<lfam>Y or N?
<lfam>"Notice: If enabled, things like /dev/mem cannot be mmapped with the PROT_EXEC flag. This can break, for example, non-KMS video drivers."
<catt[m]>Does anyone here know about thinkpad motherboards?
<Ribby>Hello guys, everything's going swimming well for the guix on my client side. I do have a bit of quirks, but they might conflict with GNU standards.
<Ribby>The recent GNOME Web / Epiphany web browser onine, is v41.#?
<Ribby>The stable release of guix have v3.34.4. Even the system server says so.
<Ribby>Flatpak is somewhat different. Is it because it is 64 bit? Maybe the later releases are propertiary?
<Ribby>Can you guys look up for linux malware scanners? I know that people claim the encryption is pretty good, but there's a chance for every action. I see clamav/clamtk as potential sources. qube os is said to be good, but requires 64 bit.
<Ribby>I'm suspecting that flatpak is too 64 bit.
<Ribby>You guys have a gui guix apps/software package store or no? It's just the guix system software package server, right?
<Ribby>I personally don't have it, because it just seems limited and might be a lot of work to patch on frontends.
<Ribby>In case someone wants to use flatpak for 32 bit. It's not exactly a solution, but it's research material.
<apteryx>Ribby: no GUI yet, no
<Ribby>I'm trying to compile clamav source code.
<Ribby>It's no problem, like I said, I see it as somewhat limiting on the ubuntu's side.
<apteryx>by the way, there's no 'stable' Guix; the stable Guix is the master branch, it's a rolling distro. v1.3.0 is just the last release, which is getting quite dated now.
<Ribby>Okay, so do I just 'guix pull', 'guix upgrade', and 'guix package -u'?
<apteryx>clamav is already packaged in Guix
<apteryx>Ribby: I believe it's covered in the manual, but in a nutshell, you first 'guix pull', to upgrade Guix itself (which comes with its package definitions), then one or the other :-)
<apteryx>in doubt, run 'info guix'
<Ribby>Okay, thanks.
<Ribby>It appears that I cannot run this program, but the site sure requires dependencies.
<Ribby>I hope it will be good source code compilation exercise/practice.\
***alMalsamo is now known as lumberjack123
<AIM[m]1>I'm making a guix package definition for something that is ready available as a executable file in the git repo release page
<AIM[m]1>It's available as a tar gz
<AIM[m]1>I wanna extract it and copy them over
<AIM[m]1>How do I do that with guix package definition?
<AIM[m]1>I did find like some channels for some other guix package but the thing is that do copy-build-system, auto extract files?
<AIM[m]1>Like if the url fetch is a tar file and I wanna extract it before I start copy does the build system do that automatically?
<mothacehe>hey guix!
<sneek>mothacehe, you have 3 messages!
<sneek>mothacehe, phf-1 says: I've sent a bug report. Trying the other method.
<sneek>mothacehe, phf-1 says: in the blog post it's written `(name "flat")' in the Cuirass doc, it's written: `name: The specification name as a Scheme symbol.' then should it be not `(name 'flat)' ?
<sneek>mothacehe, phf-1 says: I've got cuirass working with the remote build mechanism :)
<jpoiret>hoho, just got an "elogind is already running"
<civodul>Hello Guix!
<phf-1>Hello :)
<civodul>so the "childhurd" test fails but i can't reproduce it outside the test setup
***zimoun` is now known as zimoun_
<attila_lendvai>if i write a guix.scm file for a random project, then does that file need to be GPL with the standard guix header? if so, i guess that doesn't introduce constraints on the licencing of the project itself, right?
<civodul>attila_lendvai: the file is effectively GPL (unless you keep it private) because it "links" with Guix
<zimoun_>I have an issue with Emacs. Using qwerty, I use modifier key to get French accent. I works fine with Emacs but fails with emacsclient. So I have no clue how to debug. Any idea?
*attila_lendvai is adding the header then. thanks!
<civodul>attila_lendvai: you can put a license header of your choosing, as long as it says "GPL"
<civodul>that has no impact on the license of the rest of the project
<civodul>zimoun_: is that with Emacs input methods, like latin-9-prefix, or are you using something else?
<civodul>i use Emacs input methods in Emacs, and Xorg dead keys elsewhere
<zimoun_>civodul: thanks. But why is it working with full emacs and not emacsclient?
<civodul>zimoun_: it depends: is that with Emacs input methods, like latin-9-prefix, or are you using something else?
<zimoun_>no, I do not think. I did C-\ and selected latin-9-prefix. But it is the same behaviour: a kind of box pops up with the accent modifier and then the display is incorrect.
<attila_lendvai>civodul, thanks for the clarification!
<civodul>zimoun_: hmm no idea; if it's just display that's wrong (and not input), then it depends on whether it's an X window or in a terminal, etc.
<zimoun_>civodul: using latin-9-prefix it solves the issue by typing ^e but usually, I type AltGr ' e
<civodul>so via an X keymap, right?
<zimoun_>it works for me since years (2012 I guess). And it works on my desktop. It works with plain emacs. But for a misterious reason, it does not work anynore for emacsclient on my laptop. Weird…
<jpoiret>does emacsclient launch the server, or was it already launched?
<jpoiret>it's possible that emacsclient's startup is done differently than plain emacs
<zimoun_>the server is launched by systemd
<jpoiret>oh that's why then
<jpoiret>100% it's because it's launched without having the proper env variables set or the X display is not configured properly yet
<jpoiret>how is DISPLAY set for it?
<zimoun_>let me check
<zimoun_>jpoiret: no, it is started by my rc.lua from AwesomeWM.
<jpoiret>oh, so it should have the env variables set then
<jpoiret>but it is started non-graphically, right? i remember that causing issues
<zimoun_>I have tried to manually start the same way and it works.
<jpoiret>do you have a snippet of the rc.lua?
<attila_lendvai>it's a pity that latest-repository-commit checks out not the currently checked out branch, but main (i guess the remote default head?) when ref is not specified
<zimoun_>jpoiret: awful.util.spawn_with_shell("source /home/simon/.bashrc && emacs --daemon")
<zimoun_>well, I guess it comes from something from Debian
<jpoiret>would you allow me to nitpick :p?
<jpoiret>.bashrc should be used for setting up the shell itself, not env variables needed by other programs
<zimoun_>the complete config is here
<jpoiret>also, there might be an issue because emacs --daemon is forking, and also apparently it's awful.spawn now (from the awesomewm docs i looked at)
<zimoun_>yeah, I know about bashrc. All the config is done in bash_profile and bashrc calls bash_profile.
<jpoiret>but isn't that an issue? that would mean that bash_profile is sourced twice then, no?
<jpoiret>once on login, inherited by everyone, and once for each shell you spawn
<zimoun_>maybe, but that’s not an issue, I guess. Except for M-x shell. Well, it is not related to my issue about accent.
<zimoun_>I suspect that it comes from Debian and X.
<jpoiret>well it could, since it does modify env variables. but i guess here it should give you the same as a fresh interactive shell
<zimoun_>This config worked since 2018, it still works on Ubuntu and Debian 10. Using “env -i $(which bash) --login --noprofile --norc“ then export DISPLAY=:0, then ‘source /home/simon/.bashrc && emacs --daemon’ and it works as expected.
<zimoun_>So the only remaining point is X and Debian. :-)
<jpoiret>when did it break?
<jpoiret>i'm only finding old-ish issues
<allana>Hi guix! Yesterday I began creating a guix service, and it works. Now I am refining things. One thing that I am trying to figure out is how to make sure that inputs are found. For example, I feel that setting an environment variable for LD_LOAD_PATH to find the /lib of an input to be a dark corner of my attempt, and I am wondering how a situation like this might normall be handled. Does anyone know how this is normally done, and if
<allana>there are any existing examples in guix?
<zimoun_>jpoiret: ah… the issue when you use APT instead of Guix. ;-) It is hard to check and roll-back. So I do not remember… Maybe at some Debian upgrade.
<jpoiret>do you need LD_LOAD_PATH for optional deps allana?
<zimoun_>Well, for now I will start the daemon by hand and I will give another try later. I have work to be done. :-)
<zimoun_>jpoiret: thanks for the help
<jpoiret>you should check for input method things, maybe there's a change to the default that broke it?
<allana>jpoiret: it so happens that I want to support multiple optional deps, but for my current example a single dependency is not optional
<jpoiret>is that dependency an input of the target program?
<jpoiret>you generally shouldn't need to set LD_LOAD_PATH in that case, unless it's only dlopen'd
<jpoiret>what program are we talking about for reference?
<jpoiret>but in any case, you can pass a scheme program to make-forkexec-constructor, that you can write using a g-exp!
<allana>openldap, I'm actually using a variant with other configure flags (--enable-crypt) and an additonal input (libxcrypt -- patch request sent a few days ago), and I am creating a slapd service
<allana>And I am using gexps (I'm a newbie, for sure!), but I wanted to make something a little more elegant. My intention was to search the inputs of "package" (openldap) from the service configuration, and build a path for LD_LIBRARY_PATH for each input that has a /lib
<jpoiret>so you could use (setenv "LD_LOAD_PATH" (string-join (map (lambda (path) (string-append path "/lib")) #$@packages-you-want-to-pass) ":"))
<jpoiret>(yes i did take a long time to write that line)
<allana>Ah, that's almost identical to what I was trying, but probably works
<jpoiret>but really the optional deps shouldn't be in the package inputs, but rather as things in the service configuration
<jpoiret>like, you could have a procedure that takes a configuration and gives you the list of optional packages that are needed for it
<jpoiret>one issue i can see is for inputs that need to be propagated to work, which won't work if you call the executable directly i think
<allana>jpoiret: thanks! got it working.
<acrow>jpoiret: Mistakes have been made. How can I, or can I?, remedy them to allow guix to have a xalan library? I see that there is history regarding this package and I'm not sure what is needed to work with it.
<jpoiret>wdym by "there is history"? a quick search of the mailing lists turned up nothing
<acrow>jpoiret: I'm looking at 32947
<jpoiret>maybe roptat will have some sort of idea, I don't know anything about the state of java in guix
<acrow>There are many good things in here that I was unaware of. Of course I also want to be respectful of the prior work.
<jpoiret>I think it's okay to pick up patches left over by previous contributors, since they're all implicitely GPL licensed as long as they were sent to guix-patches?
<jpoiret>IANAL though
<acrow>jpoiret: which issue should be amended? Maybe close both and start from scratch. I certainly would be happy to just see what I submitted closed for unsuitability and then I would take a fresh, better shot.
<acrow>jpoiret: I don't mean to pick on you. But I suspect you've seen this sort of thing before and I'm curious what you do.
<acrow>jpoiret: what you added was helpful. thank you. I did mistake you for someone involved in the java work. Please excuse me for that.
<f1refly>how do i tell the cargo-build-system not to package optional dependencies for a crate? currently my build fails in phase "package" because an optional input isn't present
<f1refly>would I have to modify the Cargo.toml for that?
<zimoun_>reading the last words are «estimates that the Windows and Mac OS versions will be released “optimistically” by the end of 2019». Indeed, optimistically ;-)
<civodul>zimoun_: i think dongcarl uses Guix to cross-compile to MinGW though
<zimoun_>yes, probably. :-)
<MysteriousSilve4>is it not possible to use `guix shell slock?`
<civodul>MysteriousSilve4: why wouldn't it?
<MysteriousSilve4>`/run/setuid-programs/slock` but `/gnu/store/<hash>-profile/bin/slock` doesn't
<MysteriousSilve4>slock: unable to disable OOM killer. Make sure to suid or sgid slock
<MysteriousSilve4>* `/run/setuid-programs/slock` works but `/gnu/store/<hash>-profile/bin/slock`
<civodul>oh, true!
<civodul>you cannot run setuid binaries via 'guix shell'
<civodul>you could do "guix shell slock -- sudo slock", but, ahem, that's not great
<gnucode>hello you lovely people!
<gnucode>Especially nckx !
<f1refly>good afternoon gnucode :)
<gnucode>f1refly: what up ?
<gnucode>It's morning for me here. :)
<f1refly>I'm trying to figure out why I added include lines to some rust crates
<gnucode>I'm having a weird time getting email to work in emacs, so I'll be hanging out in #emacs for a while.
<gnucode>f1refly: what rust crates are you maintaining?
<gnucode>or trying to package for guix ?
<f1refly>A package fails it's packaging phase because the cargo-build-system seemingly tries to pull in an optional dependency that isn't needed and I don't know how to tell it to refrain from doing so
<f1refly>winit@0.26.1 with the optional mint crate
<f1refly>I figured I might have to either modify the generated Cargo.toml to not include the optional dependency or tell the build system no to package it, but I don't know how
<zimoun_>civodul: re setuid, it is the same for any user profile, no? Not only “gix shell”.
<gnucode>f1refly: hmmm. I have not played with rust much honestly. Or packaged anything for guix. Best of luck!
<civodul>zimoun_: yes!
<f1refly>thank you. I guess I'll try reading the build system's source when I have time for it and figure things out fromt there :)
<zimoun_>civodul: re slock, bah it seems a common issue
<civodul>turns out getting entropy for ssh-keygen when the childhurd boots (VM in a VM) takes a bit of time
<civodul>a bit too much, even
<MysteriousSilve4>'➜ slock notify-send 'hello'' ==> 'slock: execvp notify-send: Permission denied'
<MysteriousSilve4>what does this mean?
<jpoiret>slock can't find notify-send
<civodul>MysteriousSilve4: that 'notify-send' lacks execution rights, i think?
<jpoiret>permission denied can also mean that the file isn't found i think
<jpoiret>ah, no, i'm wrong on that one, it would be ENOENT
<MysteriousSilve4>some commands work, some don't :/
<jpoiret>do you have notify-send available?
<jpoiret>if so, where from?
<jpoiret>does "notify-send 'hello'" work in the shell?
<nckx`>strace seems like the tool for this job.
<civodul>it's the tool for most debugging jobs anyway
<civodul>(with printf as its sole serious competitor)
<MysteriousSilve4>`$ slock` works but `$ strace slock` prints: newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_EMPTY_PATH) = 0... (full message at
<nckx>civodul: It me, without any of the irony.
<jpoiret>setuid bit is ignored when stracing
<nckx>Yeah, strace isn't ‘forwarding’ the setuid privilege, MysteriousSilve4.
<nckx>…as jpoiret just said.
<nckx>You can start slock regularly & then try [sudo] strace -p PID.
<nckx>Plus, also, hullo Guix.
<jpoiret>apparently you can also `sudo strace -u root slock`
<jpoiret>-u lets you strace as someone
<jpoiret>at least, that's what its man page says
<nckx>But is that identical to starting a setuid binary as non-root? I really don't know.
<MysteriousSilve4>^ $(➜ sudo strace -u root slock notify-send 'hello')
<nckx>Yeah, that does not look like the same code path (no ‘Permission denied’ output).
<MysteriousSilve4>nckx: i dont understand, how do i run the latter command while slock is still running?
<jpoiret>does slock lock access to VTs? if not you can just Ctrl+Alt+F1
<MysteriousSilve4>cant switch to vt
<jpoiret>you could run something like `slock ... &; strace -p $!`
<nckx>I dunno… ssh?
<jpoiret>or rather, sudo strace
<MysteriousSilve4>➜ `slock xset &; strace -p $!`
<MysteriousSilve4>strace: attach: ptrace(PTRACE_SEIZE, 13342): Operation not permitted
<MysteriousSilve4>slock: execvp xset: Permission denied
<MysteriousSilve4>strace: Exit of unknown pid 13342 ignored
<nckx>Add jpoiret's sudo.
<nckx>If that doesn't end well, another path (eh) would be to run ‘PATH= slock’ to see if it prints the same message if it really can't find notify-send.
<MysteriousSilve4>'sudo: a password is required': how to add password to sudo's arg?
<nckx>You… don't.
<nckx>It would end up in your bash history and be visible to a lot of tools. Bad.
<jpoiret>hmmm, unless you have some sudo password persistance
<jpoiret>eg on my machine i don't need to type my password for a while after I've used it
<nckx>I don't know Guix's default sudoers configuration, but I can type ‘sudo true’ and happily sudo without prompts for a day.
<nckx>That sudo password message is alien to me. Like, why doesn't it just prompt?
<MysteriousSilve4>➜ sudo `slock xset &; sudo strace -p $!` ==>
<jpoiret>i wouldn't do that, sudo mangles your environment variables most of the time, so you should really try running the slock as vanilla as possible
<jpoiret>damn, you'll need to do `sudo strace -f -p $!` i think, so that strace follows forks
<jpoiret>from the slock code, it looks like it forks
<nckx>(No need for &; — just type & which implies a new statement — but that shouldn't matter.)
<jpoiret>the error happens in the child, but strace doesn't try to trace the forked process
<MysteriousSilve4>➜ `slock xset & sudo strace -f -p $!` ==>
<nckx>And is xset in $PATH?
<nckx>I.e. which xset?
<nckx>Sorry: run ‘which xset’.
<nckx>[pid 14149] execve("/home/anon/.guix-profile/bin/xset", ["xset"], 0x7ffc11e4bdd0 /* 84 vars */) = -1 EACCES (Permission denied)
<nckx>Hypothesis: slock is dropping permissions or otherwise sandboxing itself and can't ‘see’ /home/anon.
<jpoiret>hang on
<jpoiret>this might be libc's weird execvp semantics
<jpoiret>"If the header of a file isn't recognized (the attempted execve(2) failed with the error ENOEXEC), these functions will execute the shell (/bin/sh) with the path of the file as its first argument. (If this attempt fails, no further searching is done.) "
<jpoiret>as well as "If permission is denied for a file (the attempted execve(2) failed with the error EACCES), these functions will continue searching the rest of the search path. If no other file is found, however, they will return with errno set to EACCES. "
<nckx>Mmm, libc esotericism ♥
<nckx>Anyway, I was going to suggest a ‘sudo -u nobody ls /home/nckx/.guix-profile/bin’ as a quick check.
<jpoiret>also, yes, slock does drop permissions as soon as it can
<nckx>Which succeeds here, but my setup is less than vanilla.
<MysteriousSilve4>➜ slock cp \n cp: missing file operand \n Try 'cp --help' for more information.
<MysteriousSilve4>which cp --> /home/anon/.guix-profile/bin/cp
<nckx>which -a cp
<nckx>i.e. there is a ‘fallback’ system cp.
<nckx>Right, so that's the problem.
<jpoiret>but, slock should be dropping to the actual user so permissions shouldn't be a problem
<nckx>No, it drops to nobody, not anon.
<nckx>It can't read /home/anon but finds the /run/current-system cp later, which is why cp works but xset doesn't.
<nckx>jpoiret: Are you saying it's documented to drop to anon, not nobody, and the behaviour we're seeing is wrong?
<jpoiret>ohhh, right, i was wondering where the user var came from
<jpoiret>no you're right it comes from
<jpoiret>it's not an issue in usual distros because /usr/bin is world-readable
<MysteriousSilve4>what is 'nobody'?
<nckx>It's also not an issue if you install notify-send / xset as system packages.
<nckx>MysteriousSilve4: A user account.
<jpoiret>it could be good if slock instead dropped its priviledges to the UID
<nckx>Used by services that shouldn't run as a ‘real’ user. Its use is questionable but let's not get into that now.
<jpoiret>i mean, i don't think there are security holes if you're letting slock run commands as you instead of as nobody (you could even argue that running commands for the user as nobody is pretty stupid)
<jpoiret>ie you wouldn't be able to actually use notify-send in that case i think
<jpoiret>i'd be surprised if `sudo -u nobody notify-send "hello"` works
<nckx>MysteriousSilve4: As an immediate work-around, try adding xset or libnotify (whichever you actually care about) to your system's (packages …) list.
<nckx>It might still not work for the reason jpoiret hypothesises but at least you should get a different error message .
<nckx>jpoiret: Agreed on ‘pretty stupid’, not arguing that 😉
<MysteriousSilve4>Sorry, user anon is not allowed to execute '/home/anon/.guix-profile/bin/notify-send hello' as nobody on guix.
<jpoiret>my personal workaround would be to switch to another screen locker :p
<MysteriousSilve4>or to not use one :p
<jpoiret>or, you could alternatively patch slock's source so that it drops privileges to your user
<jpoiret>with guix it shouldn't be too hard
<MysteriousSilve4>i'll try that
<MysteriousSilve4>leave the group as it is?
<jpoiret>the group shouldn't matter much but you can take your user's group as well
<nckx>TIL that ‘ssh localhost’ first tries (and thankfully fails) to look up, probably because of my ‘search’ line in /etc/resolv.conf. This might be expected but it surprised me.
<jpoiret>tbh, never use localhost specifically for this reason
<jpoiret> is the way to go
<singpolyma>jpoiret: I think you misspelled ::1
<jpoiret>i've never learned IPv6. maybe it's time for that
<nckx>I typed that and then deleted it because too twee.
<nckx>Also, when and when not to [bracket] IPv6 addresses in command lines always confuses me.
<nckx>jpoiret: It's a bit time for that yes.
<nckx>My local ISP has been using IPv6 for a whole *year*. They are so cutting edge.
<MysteriousSilve4>'sudo .guix-profile/bin/slock xset' works but '$ slock' points to an old binary (/run/setuid-programs/slock)
<nckx>WDYM old? Did you remove it from your setuid-programs? Is it not removed when you reconfigure?
<nckx>That's probably a bug if so.
<MysteriousSilve4>idk, i must have done something wrong
<MysteriousSilve4>along with s/anon/nobody/ i added a transparency patch which works with ~/.guix_profile/bin/slock but not with /run/*/slock
<jpoiret>the setuid from /run/setuid-programs/ comes from the package in your system config, that's where you need to apply the patch
<nckx>It sounds like you ‘guix install’d your custom patched version to you user profile. But you need to add it to your *system configuration* (system profile) to affect the setuid version. They are entirely separate, and keeping two copies around will only confuse you & the system.
<nckx>I recommend guix removing slock for that reason.
<MysteriousSilve4>there's no 'slock' in system.scm
<nckx>Was there, once? There must have been. Otherwise, where did the setuid wrapper ever come from.
<dongcarl>zimoun_: Haha yeah I think the reporter misunderstood what I said, but we do use Guix for our macOS and Windows deterministic cross-builds:
*nckx gotta go.
<MysteriousSilve4>it's getting late here, i'll see you guys tomorrow :/
<nckx>Better luck tomorrow, MysteriousSilve4.
<jpoiret>isn't slock like one of the examples in the default configuration?
<nckx>It's part of desktop-services-for-system 🤦
<nckx>That's a bit… opinionated (but then so am I or I wouldn't care).
<zimoun_>dongcarl: awesome! Oh interesting that you do use the same GCC version (7 vs 10). Out of curiosity, why do you need gcc-toolchain-10?
<dongcarl>zimoun_: I think to fix: I guess we coulda added `-mno-outline-atomics` but we were gunna bump to gcc-toolchain-10 one day anyway
<zimoun_>dongcarl: thanks for the explanations. Again out of curiosity, why not bump for linux target too? :-)
<dongcarl>zimoun_: "We can't switch to using a GCC 7+ native toolchain for Linux without patching around glibc build issues (something to look at for a future change)."
<dongcarl>We try to maintain glibc compatibility for our release builds
<dongcarl>Not a thing in Guix-land but relevant for us haha
<zimoun_>heh! Thanks for explaining. Really interesting use case. :-)
<dongcarl>:-) Speaks to Guix's design for being so extensible!
<tho1efx[m]>Anyone have a copy of this talk by Mathieu Othacehe?
<raghavgururajan>Damn! I missed a lot of stuff that has happened on mail lists.
<lfam>New option for Linux 5.17:
<lfam>"This instructs the kernel to include the MS_NOEXEC and MS_NOSUID mount flags when mounting devtmpfs."
<lfam>"Notice: If enabled, things like /dev/mem cannot be mmapped with the PROT_EXEC flag. This can break, for example, non-KMS video drivers."
<lfam>Any thoughts?
<lfam>Will this work for Guix System?
<nckx>‘No sane program should be relying on executing from /dev.’
<nckx>That doesn't answer our question, Linus.
<nckx>lfam: I'll see if it cherry-picks without drama to my kernel, then give it a spin.
<lfam>I can share a patch
<lfam>I'll send it to the list today
<nckx>It's not only 28f0c335dd4a1a4b44b3e6c6402825a93132e1a4?
<lfam>Oh, I meant a "wip: linux-libre: Update to 5.17-rc" patch for Guix
<lfam>But yeah, I think cherry-picking the upstream commit works too
<nckx>It looks self-contained, applied, and is building…
<nckx>IIRC we both use ThinkPads. IWBN if somebody with, say, AMD graphics would test your patches.
<lfam>Yeah, I *only* have computers with integrated Intel graphics, or embedded machines
<lfam>Tbh, it would be nice if anyone would test these patches
<lfam>I almost never get any feedback from the kernel update patches
<lfam>I guess that means they usually work, although as we know, things broke recently
<nckx>I wish I could feasibly test them, but it's just not an option. Sorry.
<lfam>I was actually thinking of buying an AMD Thinkpad, but I'm concerned about if the graphics will "just work" or not:
<lfam>"Integrated AMD Radeon™ Graphics"
<nckx>Picking a nicely contained commit is.
<lfam>That's okay nckx. Of course, I think a lot of people do use the Guix kernels as-is and it would be nice to get some more testing before they are pushed
<AIM[m]1>lfam: I had worst experience with an Acer Laptop with AMD APU
<AIM[m]1>Probably Acer issues? Idk
<AIM[m]1>But yeah
<lfam>Do you know the model number of the laptop?
<AIM[m]1>I don't think discrete has that issue tho
<lfam>I wonder if it was also using "Integrated AMD Radeon™ Graphics"?
<AIM[m]1>lfam: Me?
<lfam>I figure that integrated should work better than discrete
<lfam>Yes, I'm asking you :)
<AIM[m]1>Acer Swift 3
<iung>Got tftpd-hpa to work for root on debian, but not on guix. Same file permissions (nobody:nogroup 0755), "in.tftpd -s /srv/tftp" command. "Connection timed out" on Guix after "tftp localhost -c get foo". What may be the problem?
<lfam>What kind of problems AIM[m]1?
<AIM[m]1>AIM[m]1: Every distro lagged af on that idky
<lfam>I see
<nckx>If ‘integrated’ means what it does for Intel, it means integrated onto the CPU, so the laptop vendor doesn't make any difference at all.
<AIM[m]1>They would just hang while I'm working on stuff
<lfam>I get some tearing during video playback on my laptop but overall it's fine
<lfam>That's a thinkpad with i5
<AIM[m]1>Currently on Thinkpad
<AIM[m]1>Not Librebooted one sadly
<AIM[m]1>I didn't know about them back when I bought it
<lfam>There's not a lot of options for that
<AIM[m]1>I'd bought some coreboot or libreboot thing
<AIM[m]1>There's one hacker shop that flashes custom coreboot onto compatible models and resells them
<nckx>I settled for an ME-cleaned one. Not willing to pay the significant performance price for an even older Librebooted one.
<AIM[m]1>They're FOSS supporter store
<f1refly>coreboot has to suffice
<lfam>I didn't realize that was an option nckx
<lfam>iung: Hm, does it time out immediately, or does it actually wait a while?
<AIM[m]1>AIM[m]1: They just add their custom logo along with the coreboot, that's all they do different
<nckx>X230T (nothing magical about that particular model, I think, but it was the last tablet ♥)
<iung>after a while
<lfam>Ah yes, I knew about the X230
<lfam>It does represent the last of something in the X-series
<iung>I'll test in vm... Don't know where to look.
<AIM[m]1>I've heard T-460 or something was good
<lfam>I use x260, it's a nice machine
<AIM[m]1>AIM[m]1: Idk some software developer using linux that my cousin knows told him that
<lfam>iung: To clarify, Guix is running the tftpd-hpa server?
<AIM[m]1>He did say Thinkpads have premium keyboard
<AIM[m]1>lfam: Wot?
<lfam>People complain about thinkpad keyboards getting worse after the T420 / X220 series, but they are still very good
<lfam>Just not as good
<lfam>And the machines are very durable
<iung>ifam: yes.
<nckx>I should note that I have an aftermarket CPU that about doubles the original performance of the best i7 X230. It's a bit weak otherwise, but still much better than an X200.
<lfam>iung: Can you check if it's the same version as what is provided by Debian? And check if there could be a firewall blocking the connection on Guix?
<nckx>lfam: I put an X220 keyboard on it but I'd say it's not worth the effort for most people.
<lfam>nckx: Wow, you really have a hot-rod
<iung>lfam: same 5.2. I tried connecting to localhost for testing. Haven't set up any firewall..
<nckx>I feel icky boasting about it but tend to forget about it when promoting the X230 today, then think, oh right, that.
<lfam>iung: I wish I had experience with tftp to help you debug it. Does anyone else know their way around this stuff?
<AIM[m]1>So I was thinking why the default startx thing didn't work
<AIM[m]1>Is it coz I'm not running mingetty or agetty
<nckx>Which default startx thingy?
<AIM[m]1>Following a mailing list or soemthing on guix, I found that I had to make my own startx script coz there is a permission error
<nckx>It's always been hard to get (and keep) working on Guix Systems.
<lfam>Are you running another getty, AIM[m]1?
<AIM[m]1>nckx: Sorry, I forgot to mention I run dwm on guix
<nckx>People sometimes point to a mail but it's from 2018 or something.
<AIM[m]1>So I have to run startx?
<AIM[m]1>I have a xinitrc file with all the stuff I run at startx
<nckx>I just mean it's never been well-supported or expected to work, and has always been rather ‘you're on your own, good luck’.
<AIM[m]1>Installed them all and um it works
<AIM[m]1>But I had to make a bash script to do whatever startx does but manually
<AIM[m]1>And yes, I don't have gdm or other dms
<AIM[m]1>Idk I kinda am fond of the tty and terminals
<AIM[m]1>Blinking cursor sparks joy in me
<nckx>That's expected. Even the more Guixy way requires creating your own ‘startx’ wrapper.
<rovanion>Is it possible to see which profile keeps a specific package in the heap?
<AIM[m]1>I c
<AIM[m]1>Can ya explain why?
<rovanion>I want to garbage-collect texlive.
<AIM[m]1>Is it coz I'm missing a service dependency?
<nckx>rovanion: Heap is apt. Maybe ‘guix gc --referrers’?
<lfam>Yes, --referrers and then a little poking around to map the results back to /var/guix/profiles/per-user/rovanion
<nckx>AIM[m]1: It's been far too long (years) since I've used X so I can't give authoritative answers, but no, there isn't some service you need to add ‘to make the startx work’.
<AIM[m]1>I see
<AIM[m]1>Thanks anyways
<nckx>I don't even remember the right keywords to search for, but the last working hack I knew was to make Guix create a startx script that just invoked xorg-start-command.
<nckx>I'm not useful here, sorry.
<nckx>Wayland for the win.
<nckx>(Which I use with a login manager :)
<f1refly>how would I use pipewire instead of pulse? Would I have to replace pulse in %desktop-services?
<iung>Debian starts tftpd for me. My command is not enough. Will read more how it's done.. Couldn't get inetd to work either with this config
<lfam>iung: You might check something like `systemctl status tftpd` and read the service file to understand how it works
***sneek_ is now known as sneek
***julm is now known as Guest1350
<acrow>What package provides makeinfo?
<acrow>the answer is texinfo.
<lfam>Maybe the texinfo package description should mention it?
<acrow>I think that is a good idea. If desired, I would submit a patch for that.
<lfam>I figure you aren't the first person to wonder
<acrow>Well, that sounds like a deep subject. :) No one wants to be the bull in the china shop. Especially if they appreciate the china.
<acrow>Texinfo is identified at
<rovanion>I can't manually find a link in /var/guix/profiles that matches /gnu/store/7yqn4s34wk4dbpq5pd5m8vk4jzvg9gfr-profile, do you happen to have a find-command that can help me?
<acrow>How about cd /var/guix/profile/per-user/<you>; then find . | xargs -- readlink -f | grep 7yqn4s
<acrow>Although I don't understand what would necessitate such a search. Maybe guix package --list-generations would give equivalent actionable information that would help, no?
<mitchell>Hello guix. I am trying to package this archive of info pages for the common lisp. However the unpack phase doesn't seem to be unpacking anything. When i build with -K it leaves behind an empty directory.
<acrow>the copy-build-system may need some help.
<rovanion>acrow: The problem is that I can't find what keeps texlive in the store/heap. Neither `guix package --list-generations` nor the find command takes me closer to an answer. The root profiles doesn't contain bin/pdflatex either :/
<lfam>Did you try --refferers?
<lfam>I mean, --referrers
<acrow>rovanion: if the package is in your profile or a dependency of any of thos packages then the package won't be garbage collected and is available for use. What the same for all users including root, but root isn't special. It is sufficient to have it in your profile without regard to root.
<acrow>g/What /d
***Guest1350 is now known as julm
<acrow>s/thos/those/ too.
<rovanion>acrow: Yes, but I can't find it referenced from any profile that I can find, yet its not gc'd.
***julm is now known as Guest4339
<lfam>To be sure, did you attempt to gc the file in question?
<lfam>`guix gc -D /gnu/store/...-thing`?
<rovanion>Nope, just a generic gc. Will try.
<rovanion>Ah, there we go. That command outputs a link to a gc-root in a development source folder.
<lfam>Great :)
<lfam>So, `guix gc --referrers` didn't list that root?
<rovanion>No, it listed a root in /gnu/store which I couldn't find symlinked from anywhere else.
<lfam>It would be nice to have a commend like `guix gc --why`
<lfam>Or however you want to name it
<rovanion>Why is a good name, its what Debian uses.
<lfam>The question is, "why what?" We'd probably pick a different name since our question is different
<lfam>Since, I think the question is "why is this store item 'alive'?"
<rovanion>So I removed the root, but the link in /gnu/store is still there and I can't kill it :/
<rovanion>why-installed maybe?
<lfam>Having some in the store is not "having it installed" in Guix parlance
<lfam>I mean, having something in the store
<lfam>So, you still can't gc the store item? What does the message say?
<tho1efx[m]>I'm trying to manually install the guix binary on a foreign distro.... (full message at
<rovanion>guix gc: error: cannot delete path `/gnu/store/18sd7aa3kdvwyhgny9448vmg4xvklhgf-texlive-20190410' since it is still alive
<lfam>And what does --referrers say?
<tho1efx[m]> * ~~I'm trying to manually install the guix binary on a foreign distro.... (full message at
<rovanion>lfam: /gnu/store/7yqn4s34wk4dbpq5pd5m8vk4jzvg9gfr-profile
<lfam>And you can't find that linked to from anywhere in /var/guix/gcroots?
<rovanion>lfam: Though you have to use the vocabulary of the user, they are asking "why is this thing still eating up my disk?" and if you use technically correct terms like why-alive then they won't find their way to it without hitting it up on stackoverflow.
<lfam>Sure, it's something to consider carefully
<lfam>Poking around in /gnu/store is not something that's really a normal part of using Guix
<lfam>So, you're already doing something rather advanced
<rovanion>I just want to free up space to store video from my gopro :/
<lfam>I know
<lfam>It's a little hard to follow what you're doing. You are kind of drip-dropping information into the chat without giving a comprehensive explanation
<rovanion>Yeah, sorry.
<lfam>The reasons that a store item are alive are basically these: 1) it's referred to by a profile 2) it's part of an active (currently being built) derivation 3) it's referred to be an active `guix environment` or `guix shell` session
<lfam>There are also manually created "gcroots". But overall, they should be linked to from /var/guix/gcroots unless I misunderstand the feature
<lfam>So, until we have a better tool for exploring this stuff, you kinda have to poke around and evaluate what's going on
<rovanion>Ah, in /var/guix/gcroots/auto is a reference to the manually created gcroot!
<rovanion>There we go! 10GB of garbage!
<rovanion>Thank you for yoru patience lfam!
<lfam>Nice :)
<lfam>That always feels good
*nckx speaking to you from CONFIG_DEVTMPFS_SAFE=y
<nckx>Nothing has of yet asploded.
<nckx>I didn't actually mean to reboot, but here we are. 😊
<lfam>I decided not to send a patch for the final RC release. I'll wait until the real release comes out. It's not totally trivial to adjust the download URLs in the necessary way
<nckx>jpoiret: Something occurred to me over dinner: would using an absolute name like ‘localhost.’ not be safe?
<akonai>trying to set up a shepherd service to start X as the user but my home-shepherd gets "stuck" on it. anyone knows why this could be?
<akonai>here is the service
<akonai>by stuck i mean that it properly launches the service but then doesn't execute any services that depend on it, does't write to the log that it had started and herd * doesn't work
*nckx doesn't.
<nckx>But… so it does launch a rootless X server that works? I'm impressed. I didn't even know that was supported.
<akonai>yes, you can launch X with xinit (plus secret incantation) via xorg-server-service-type
<nckx>I just didn't know it could run as a regular user now.
<nckx>As in, that's new(ish).
<ardon>Does anyone else experience a "File error: Couldn't find a proper 'ls' command" when trying to gain root access via TRAMP inside Emacs in a machine running Guix?
***ec_ is now known as ec
<jab>Hey friends!
<nckx>Hi jab.
<jab>howdy nckx !