IRC channel logs


back to list of logs

<blake2b>hiya guix, cybersyn here. decided username blake2b being up for grabs on is too big of an opportunity to pass up :D
<singpolyma>I've had the same nick for so long I don't remember what it feels like to change
<Kolev>Agh! It's building IceCat!
<blake2b>working on my presentation rn, I notified roptat that it would be a bit late. but I'm doing it entirely in the repl with guile-picture-language and tbh it looks great
<blake2b>singpolyma: I fell off IRC some time around 2014. glad to be back though
<singpolyma>blake2b: oh, I don't mostly mean IRC, though I do use my nick here as well if course
<blake2b>when I went to grad school I became extremely offline until I discovered guix about a year ago. so good to know that good corners of the internet still exist
<singpolyma>Internet is so big I bet everyone considers at least one corner of it good 😀
<singpolyma>What were you in grad school for?
<blake2b>not anymore, but I was doing my PhD in philosophy with an emphasis on philosophy of mathematics (set theory & category theory), focusing on formal theories of value, but from the continental tradition. I focused on the status of formalism in ontology and how this impacted the bourgeoning theories of value that continue to inform our present episteme, particularly in the major works of Kant, Hegel, Freud & Badiou. But school threatened
<blake2b>to separate my partner and I in unpredictable was due to covid, which has decimated the humanities. And I've become to obsessed with scheme & guix to imagine finishing any time soon haha
<blake2b>but i'm giving a guix day talk, so wouldn't want to spoil it ;)
<Kolev>I wish Guix had Jellyfin.
<Kolev>Can I run the official Jellyfin container with Podman on Guix?
<sneek>wb rekado!
<droople>As far as I can discern, the only difference between my previous network setup and my guix network setup is that guix uses dhclient and my old setup used dhcpcd
<droople>My old setup never dropped connection. This one drops connection every 2-120 seconds
<droople>what do?
<Kolev>droople: Wanting to install Jellyfin. :(
<droople>jellyfin appears to have docker containers
<Kolev>I can't do mkfs.vfat.
<lilyp>Kolev: you need ntfs-3g in your OS config packages as far as I'm aware
<lilyp>(though perhaps just having it in a guix shell might suffice)
<haugh[m]>Hi Guix! I'm getting ACPI BIOS errors on a system install to an AMD-based Tuxedo Pulse 15.
<haugh[m]>Install went fine but I get kernel panic before I can access a login shell.
<haugh[m]>No DE. Used the 1.3.0 ISO, now on Linux 5.11
<haugh[m]>Any pointers for troubleshooting?
***califax- is now known as califax
<haugh[m]>Attempting to allow for the UEFI bios with `(bootloader grub-efi-bootloader)`
<Kolev>podman: Error: short-name "jellyfin/jellyfin:latest" did not resolve to an alias and no containers-registries.conf(5) was found
<haugh[m]>install failed with grub-efi-bootloader :(
<haugh[m]>yeah I don't think this is a BIOS issue. it's hanging well into the Guix load, around the point where it's screaming aboutMissing Free firmware
<haugh[m]>testing ChanServ
<droople>my ethernet interface doesn't show up in the output of 'ip a' with a fresh install. What do I do about that?
<droople>I just don't know where to start if it doesn't even show up
<the_tubular>Where are the channels stored on guix distribution ?
<the_tubular>Well are they stored somewhere when you guix pull ?
<Michal_Atlas[m]>With home and system they're stored in their respective profiles along with the given commits
<the_tubular>Where is that ?
<Michal_Atlas[m]>* and system at least they're stored
<the_tubular>This is just a file that points to the channels
<the_tubular>I though it would store the entire repository somehwere
<Michal_Atlas[m]>That should be under .cache/guix/checkouts
<Michal_Atlas[m]>And somewhere in the store ofc, when you pull it mentions building some deriv ...-name-of-channel
<the_tubular>Umm, those repository looks "temporary"
<the_tubular>Which one of those 2 should I use ?
<blake2b>(symbol->string "hello")
<the_tubular>Also, does unatneded upgrade also guix-pull ?
<Michal_Atlas[m]><blake2b> "(symbol->string "hello")" <- Hey, thanks for mentioning guile-picture-language, it's so adorable, really looking forward to your talk
<Michal_Atlas[m]><the_tubular> "Also, does unatneded upgrade..." <- "runs `guix system reconfigure` from the latest version of the specified channels" - Manual
<Michal_Atlas[m]>It wouldn't make sense to me to not pull.
<the_tubular>So the doc says it doesn't ...?
<the_tubular>Yeah it wouln't makes sense to me either
<the_tubular>Well maybe they really mean the "latest version of the specified channels"
<Michal_Atlas[m]>It does, it doesn't say "pull" anywhere unfortunately, but implies multiple times that the newest version of the channel is used
<the_tubular>Got it.
<the_tubular>I couldn't make sense of it
<the_tubular>invoke #$(file-append guix "/bin/guix")"time-machine" "-C" #$channels"--" "system" "reconfigure" #$config-file)
<the_tubular>Sorry for the fortmating, but this is it correct ?
<the_tubular>timemachine-C umm
<the_tubular>"Execute COMMAND ARGS... in an older version of Guix."
<the_tubular>So which is it...? Latest or earlier version of guix ?
<the_tubular>Latest or Oldest *
<blake2b> Michal_Atlas: for sure! i'm surprised how good it looks "out of the box"; i had just imagined it would look like Racket's (pict), which I didn't spend much time with but recall it literally being a bit rough/dithered around the edges. the presentation I'm doing with it looks like a less shiny Beamer presentation, with little work. quite excitd about it now (and hope i can spread some of that excitement with this)
<blake2b>now i'm planning to make a guiser-present program now, it will be so easy :)
<blake2b>repl driven keynotes
<Michal_Atlas[m]>* I think it does, it doesn't say "pull" anywhere unfortunately, but implies multiple times that the newest version of the channel is used
<the_tubular>I mean, what I just pasted was code on how it's implemented
<the_tubular>All it does is run guix system reconfigure
<Michal_Atlas[m]><the_tubular> "So which is it...? Latest or..." <- I think the easiest way to see at this point is to just test it 😅, my last unattended upgrade failed, but it does run guix time machine with the given channel file, and then simply just reconfigure.
<Michal_Atlas[m]>Time machine updates channels unless they're pinned
<Michal_Atlas[m]>So that's where the pull happens
<the_tubular>Haaa, nice
<the_tubular>Well today I learned
<the_tubular>Thanks for the explain
<Michal_Atlas[m]>Thank you too, didn't realise all these implications between the commands, learnt a bunch too
<the_tubular>What I'll plan to do is create a unatended-upgrade-user that will guix pull && guix upgrade && guix home reconfigure
<the_tubular>As a user
<the_tubular>I should also add guix home reconfigure to unatended-upgrade
<the_tubular>I'll probably learn a bunch too :P
<Michal_Atlas[m]>That actually makes a lot of sense
<Michal_Atlas[m]>Great idea
<the_tubular>Maybe even guix gc, but I don't understand it enough yet
<the_tubular>Like can i clear what is older than let's say a month ?
<the_tubular>Ehh I guess I could just mess with the cron timer
<jaft>Not trying to spam anything but the logs from yesterday for this channel didn't show the messages I sent so, in case they didn't send properly or something (my internet connection drops periodically, which helps nothing…), I'm just going to post here, a second time.
<jaft>I've been trying to get my Android phone get detected. I'm using GVFS and Thunar; full details are at but the short of it is that I noticed that the 69-libmtp.rules file that Guix installs differed from my Debian machine so I added a udev-rules-service that added all the devices that were in the Debian file and found the
<jaft>device was recognized, now, but trying to click on it or mount it still resulted in the error "No mtp devices found."
<jaft>Someone here recommended trying android-udev-rules so I did; this resulted in the phone not getting recognized, when plugged in, by Thunar, again – but it /was/ able to be recognized as a connected device by adb. So I'm not sure what else to try; any help, of course, is super appreciated!
<jgart>hi guixers! does guile have a syntax for accessing functions from a module that have not been exported?
<jgart>for example common lisp has package::non-exported-symbol:
<vivien>Guile does, ((@@ (module ...) function) args ...)
<jgart>vivien, ((@ (module ...) function) args ...) accesses only exported functions?
<jgart>and ((@@ (module ...) function) args ...) accesses all functions?
<vivien>I think so
<jgart>ah cool
<jgart>that finally makes sense now
<jgart>cl-cookbook and vivien helped me finally understand ((@@ (module ...) function) args ...)
<vivien>jgart, the guile manual says there are limitations to @@ but I can’t find them
<jgart>great! I can't find them less
<rp1>Hi folks! A new version of racket was released a few days ago. Can I help update the version on guix?
<AwesomeAdam54321>rp1: Of course!
<rp1>AwesomeAdam54321: So, where do I start? Open an issue about it?
<AwesomeAdam54321>rp1: Yeah, you can send patches to update the version
<AwesomeAdam54321>You can email the patches to
<rp1>I'm afraid I'm new, so I don't really know what I'm doing. Where would I find the code that builds the current package? Is there some documentation I should go and read before bothering you folks on irc :)
<AwesomeAdam54321>rp1: By doing `guix edit $PACKAGE`, you can read the package definition of PACKAGE that's in the store, which is read-only. the name of the file you're editing is the place the package is defined
<AwesomeAdam54321>So you can git clone the guix repository, find the package definition and update it, and send the patches
<rp1>Once I've edited the definition on my own machine, how do I try to build it?
<AwesomeAdam54321>rp1: `guix build -f $package-definition`
<AwesomeAdam54321>where $package-definition is where your edited definition is stored
<rp1>As in a filename?
<rp1>So I can guix edit $PACKAGE, change the definition, save it wherever with a new filename, and then try building it with -f?
<rp1>So guix build tells me that there's nothing to build and suggests I put the name of a package at the end of the file.
<rp1>I can do that?
<AwesomeAdam54321>oh yeah, I forgot about that part
<rp1>No worries :)
<rp1>I get an error because there is an hash mismatch, which makes sense because I've updated the version from which I'm trying to build. I suppose I can get that from the Racket website
<AwesomeAdam54321>rp1: There's a shortcut where you can do guix download https://path/of/package/to/download
<rp1>And that will tell me the hash?
<AwesomeAdam54321>rp1: yes, it's very useful
<rp1>Oh I see, and now it's in the store, so I won't have to download it again
<rp1>Wow, lots of things. Green colours instead of red colours!
<rp1>It built! So how do I tell guix that I want to use the new one at the command line, rather than the old one?
<rp1>Or does that happen automatically?
<AwesomeAdam54321>rp1: You do guix install
<AwesomeAdam54321>guix install is in charge of changing your user profile to use it after guix build builds it
<AwesomeAdam54321>s/guix install/guix install -f $package-definition
<rp1>Oh I see, thank you!
<kraai>I'd like to package elm-test (see Should the definition go in gnu/packages/elm.scm or gnu/packages/node-xyz.scm?
<AwesomeAdam54321>kraai: I think it should go in gnu/packages/elm.scm
<kraai>AwesomeAdam54321: Thanks!
<gnoo>has there been some update to some font packages so that it makes everything inside weechat bold ?
<gnoo>almost everything except the messages are bold. even the nicks and the 'join/part/quit' indicator
<rp1>AwesomeAdam54321: guix install -f $file says that it doesn't recognise -f. Am I doing something silly?
<gnoo>rp1: guix package -f -i ; but i recommend guix package -L ~/path/to/dir/ -i instead
<gnoo>guix install is 'guix package -i' shortened
<rp1>gnoo: Thanks for that... lots of things are happening again :)
<gnoo>if you put the definitions in a git-repo (in a local directory), you won't need -L. -L is still useful to build before installing
<rp1>-L is setting the directory in which everything should be built?
<gnoo>no, it loads all the files in that directory so you can have multiple files defining packages that depend on each other
<rp1>Got it, I see
<rekado>sneek: hey sneek, have a botsnack!
<gnoo>the latest update also broke alsa somehow :/
<jpoiret>gnoo: how so?
<gnoo>jpoiret: neither mpv nor mpd can output any sound at all
<jpoiret>does pulseaudio work?
<jpoiret>eg can `pactl list` list your outputs?
<jpoiret>sometimes I also `pulseaudio -k` to kill the pulseaudio daemon, sometimes it misbehaves (really need to start working on a pipewire replacement)
<gnoo>ok, sorry, it works now :)
<gnoo>idk what happened to it
<jpoiret>i did have some issues recently with pulseaudio, mpv broke the daemon each time whenever it quit
<gnoo>i don't use pulseaudio, raw alsa has been quite nice :)
<rekado>gnoo: if you’re using raw alsa you may need to configure a mixer in the alsa configuration, so that multiple applications can play sound at the same time.
<gnoo>rekado: I haven't configured much but everything just werks
<gnoo>I have told programs to use alsa explicitly so maybe that helps but beyond that, no configuration
<florhizome[m]>jpoiret: didn’t you say were looking into pipewire?
<jpoiret>i did
<jpoiret>but i haven't yet ported my config to guix home, which is a prerequisite for this
<rekado>gnoo: with alsa it can happen that a program blocks access to alsa and then other programs can’t get a chance to get a word in, as it were.
<florhizome[m]>I’m having a stint back on manjaro so I’ll look to set it up there
<jpoiret>(since a system-wide pipewire isn't a good idea imo)
<jpoiret>pipewire is much easier to setup on a systemd-based distro :p basically works out of the box
<rekado>many people who stick with just alsa use the dmix plugin
<florhizome[m]>it sounds like it should work pretty fine
<rekado>jpoiret: what is needed to set it up?
<rekado>is it dbus-activated?
<jpoiret>yes, I used it myself on Arch because of the better bluetooth support and it was a smoother experience than pulseaudio
<pinoaffe>hi folks, are the guix-days videos available anywhere? (I'm sorry if I'm the umptieth person to ask)
<jpoiret>and fully compatible with pulseaudio libs too
<jpoiret>rekado: no, that's why it's a pain
<jpoiret>and that's why guix home is a requirement
<florhizome[m]>it‘s a User daemon right?
<rekado>jpoiret: is there documentation on how to make it work?
<jpoiret>rde has it working, but I was looking for a more standard setup
<jpoiret>basically, i'd need to make some improvements to Shepherd first
<jpoiret>so that we can have shepherd services passing env variables to each other
<florhizome[m]>It’s not possible to just start it?^^
<rekado>I keep seeing rde, but I have no idea what it is, why I’d want it, and why it’s not just in Guix
<jpoiret>well, it's not blocking though, but the project was to have an "out-of-the-box" xdg-desktop-portal-wlr, which would require those Shepherd improvements
<jpoiret>florhizome[m]: oh it is
<florhizome[m]>I thought I can maybe just start the processes from wayfire Autosparte
<jpoiret>i currently have a sway workspace with 5 open terminal, with pipewire, wireplumber, xdg-desktop-portal-wlr, xdg-desktop-portal and flameshot started
<jpoiret>(just to take screenshots!)
<jpoiret>the wayland desktop stack is ... quite funny
<florhizome[m]>rekado it’s a channel by the guy who developed much of guix home
<florhizome[m]>jpoiret it’s the wlr Stack ;)
<gnoo>rekado: thanks! i'll look into the dmix plugin. although it has been working with mpv, mpd and icecat.
<jpoiret>florhizome[m]: it's also needed for Gnome too
<jpoiret>(if you want to play nice and use the standard APIs that is)
<florhizome[m]>I‘m pretty ok tbh.
<florhizome[m]>These are mostly small utilities.
<jpoiret>yes, but since they're user services it'll need some work to incorporate it into guix proper
<florhizome[m]>yeah bc guix user services haven’t been a thing for long
<florhizome[m]>and bc service development takes some time I guess
<jpoiret>and we need to support things that aren't needed for system-wide services
<jpoiret>like for example, the wayland compositor setting DISPLAY, which needs to be passed to other services
<jpoiret>systemd does it in an icky way, by using dbus-update-activation-environment, which is kind of stateful
<florhizome[m]>i still use that
<jpoiret>if we have a proper service dependency graph, we can simply pass it down
<florhizome[m]>you think the wayland compositor can be a user service?
<jpoiret>the issue is that dbus-update-activation-environment will propagate the env variables to every other service, rather than only the services that need it
<jpoiret>also, it implies that dbus will start the services, even though it should be shepherd :))
<jpoiret>yes, totally!
<florhizome[m]>I‘m the only one that’s kind of nonchalant about env vars huh
<jpoiret>the end-goal would be to be able to "boot into" a guix home generation directly
<jpoiret>and you could select the generation on login, much like with guix system
<jpoiret>env vars lead to many bugs
<florhizome[m]>When they’re missing, too^^
<rekado>re shepherd sharing of env vars: you could have a service that is extended by other services with vars
<florhizome[m]>i don’t really wanna get into that lol.
<jpoiret>oh, that was more for rekado :)
<jpoiret>I don't think it's possible to propagate things up the dependency graph, no?
<jpoiret>note that it's at runtime, so i'm talking pure shepherd services here
<florhizome[m]>To me it felt like, there are a bunch of things that are „desktop services“ and packages in the desktop environment services like gnome that could be handled by user interfaces but probably not all.
<florhizome[m]>how do you manage login/seat etc? Those are system services that need some info about your wayland compositor f.e.
<florhizome[m]>Seemed like you need some interface between system and user services to me
<florhizome[m]>(or the other way around, you need certain system services to start a certain wayland compositor)
<gnoo>you don't need a system service to start a wayland compositor
<gnoo>just `sway' and you're done. you do need seatd as a system service tho.
<gnoo>there's also seatd-run which probably doesn't need seatd running as a system service.
<gnoo>hmm, can normal users install programs that need suid to function
<florhizome[m]>gnoo: I’m being very generic here
<gnoo>i forgot to mention, but i've reduced boot time by about 30 seconds!
<jpoiret>gnoo: you could launch it through a service though
<gnoo>just by recompiling seatd without logind and removing polkit? or something similar dependency in it.
<jpoiret>seatd-run will require elevated privileges to function properly most likely
<gnoo>yes, as i understand, all seat managements need elevated privileges, right?
<jpoiret>florhizome[m]: login/seat have their own APIs which are already used by the current compositors
<jpoiret>no need to interface them
<florhizome[m]>but they need to be there
<jpoiret>gnoo: yes, basically seat managers are just another file permission manager
<jpoiret>florhizome[m]: well yes, but that's your responsibility. If your system doesn't run a seat manager, then most likely you shouldn't try to use something that relies on ti
<jpoiret>seat managers just assign ACLs depending on which seat is active
<florhizome[m]>How does a user know they don’t have a Seat Manager
<jpoiret>well, you do have one, and if you don't you know it
<jpoiret>elogind is a seat manager among other things
<florhizome[m]>because I’m root and user
<gnoo>if you use %base-service-type then you don't have it. you'll need one like seatd-service-type
<florhizome[m]>that‘s not everyone
<jpoiret>then you ask your administrator
<gnoo>if you use %desktop-service-type then it's included
<jpoiret>s/-type/s/ :p
<gnoo>ahh ok, haven't changed that one in a long time
<jpoiret>more interaction between system and home seems like a bad idea, bound to reinvent dbus
<florhizome[m]>If i install a user service that needs some system service, does guix tell me that?
<gnoo>hurd has nice ipc or so i heard
<jpoiret>guix home should be completely independent of guix system: one might run on a foreign distro, or even on mismatching guix versions
<jpoiret>gnoo: right, but i don't think anyone will run hurd on real hardware anytime soon
<jpoiret>i mean, it's technically running, but i wouldn't call it a daily driver
<florhizome[m]>But then it doesn't work.
<gnoo>yeah, it has loooots of cool features tho. it'd be nice to use it
<jpoiret>well, yes! that's to be expected with strictly user managed setups
<jpoiret>i don't think there's anything that could be done about that
<gnoo>like runtime permissions, you can change a processes's permissions to anything at runtime.
<florhizome[m]>Why let users install something knowing that it won't work without even being able to tell them
<jpoiret>you can do so in Linux as well, although much less elegantly
<jpoiret>florhizome[m]: that's the case for 100% of other distributions as well
<florhizome[m]>Other distributions don't run on foreign host systems
<jpoiret>we're just spoiled because guix lets you do a bunch of things as a non-privileged user, so we sometimes forget that everywhere else, you need to elevate to do anything meaningful
<gnoo>florhizome[m]: the package's documentation should tell what services it needs to function properly
<gnoo>accounting for every service and it's possible dependency is hard
<jpoiret>florhizome[m]: right, but if a user does `./configure --prefix=$HOME/test; make; make install` and the program doesn't work because the system is missing some functionality, it'll be the same issue
<florhizome[m]>For example for those user services that need a certain system service you could tie them to guix system
<jpoiret>how would you?
<gnoo>florhizome[m]: well what if the user has that service running on the host distro?
<florhizome[m]>jpoiret yeah that's why there is distros right^^
<jpoiret>you can't make a user's home be a dependency of the system configuration?
<florhizome[m]>I said "tie"
<jpoiret>florhizome[m]: what i meant was that unprivileged users can face these issues as well
<jpoiret>if someone cannot run `sudo apt install elogind` on a traditional distro, then the software they want to compile and use will not work and that'll be it
<florhizome[m]>i didn't say how hard and i did not say the whole home, that's a total escalation
<jpoiret>but i really don't see how a user guix could interact with the guix system meaningfully
<jpoiret>apart from something à la dbus
<florhizome[m]>If we're on guix we just need to check if a certain system service is enabled, right?
<florhizome[m]>We don't need to modify it.
<jpoiret>there's no way to do that from guix home
<florhizome[m]>Then guix home is bugged
<florhizome[m]>For the things you want to do with it.
<jpoiret>you'd need elevated privileges to talk with shepherd, and even then you wouldn't be able to know exactly what service is running
<jpoiret>i think you're jumping the gun here
<jpoiret>guix home does exactly what it advertises (although it's still experimental): it lets you manage your own home declaratively
<florhizome[m]>I just think people are trying to outmax guix home without keeping the limitations in mind
<jpoiret>if we want more interoperability, then i think it's Linux that's to blame, rather than Guix
<jpoiret>Hurd would have nicer properties (although I'm not sure if there's enough introspection for that)
<florhizome[m]>I'm not blaming though
<jpoiret>this is why people are still excited about OS and kernel design, they really do solve things more elegantly than what we currently have
<florhizome[m]>The amount of things designed to surpass user/host barriers for specific things is pretty staggering^^
<jpoiret>yes! and the interface to do so is always underwhelming
<jpoiret>dbus is actually conceptually pretty good, and closer to what Hurd's trying to do for example
<jpoiret>there even was a project to add dbus to the kernel with kdbus some years ago
<jpoiret>the idea was to add an IPC to mainline that could replace Android's own IPC, but as expected Google didn't really take interest since they already had their own
<jpoiret>but the Android IPC is another example
<florhizome[m]>So If a user wants to install a service that depends on some system service shoot them a warning; if this doesn't work and you're on guix you might need some system service; if you're not on guix then we blame Linux :D
<jpoiret>well, if they're not on Guix they could ask their administrator to add the relevant software to the system
<florhizome[m]>That was supposed to be funny yknow
<jpoiret>in both cases it's the same issue: the administrator needs to step in and add the dependencies. I'm not sure that we need to maintain that dependency warning ourselves though, since the issue is common for all distributions
<jpoiret>maybe a warning in the docs rather? saying that such and such software requires x or y
<florhizome[m]>I think you should be able to turn it off in some way or form
<florhizome[m]>hmm is user-shepherd a systemd service on systemd hosts?
<jpoiret>I don't think so, but you can make it
<florhizome[m]>funny idea: if you're on a systemd system based on Debian guix spits out a .deb that adds dependencies to shepherd
<florhizome[m]>So either you or your admin can install it
<florhizome[m]>how does systemd do that? Does it? track dependencies of user services
<jpoiret>i don't think it does
<florhizome[m]>i guess this could become more of a topic since it gets more competition
<jpoiret>it doesn't because of the same reason that we can't, user and process separation
<florhizome[m]>And different service managers on one system become more of a reality
<florhizome[m]>hm but the dbus can, for example?
<florhizome[m]>I guess that's what you meant
<jpoiret>well, dbus can't let you "add missing system dependencies"
<jpoiret>but it lets system and user apps talk to each other
<jpoiret>and user apps can ask system apps to do things for them if they have the proper permissions
<jpoiret>that's what happens with NetworkManager or udisks for example
<florhizome[m]>I'm just talking about checking if a system service is running
<florhizome[m]>not doing much talking
<gnoo>dbus also starts services itself because why won't it
<jpoiret>yeah, that's the main complaint I have with it, it's not just a dbus but can be a whole service manager
<florhizome[m]>for example, if you hand a list at the start of the user session about sensible services that are running that could already do a lot imo.
<florhizome[m]>or that are enabled? i'm just exploring here^^
<gnoo>like herd status ?
<florhizome[m]>like a mechanism where an admin can install configuration options and you can opt into using them by installing the user parts but if the prerequisites haven't been installed you get a message that lets you know that.
<gnoo>there can be multiple ways to start a service, it's better to leave it at the user's choice, no?
<florhizome[m]>gnoo sure, i don't understand the critique?
<gnoo>i mean there's no need to add that to guix home, it sounds like something that'll only work on some very specific cases
<florhizome[m]>gnoo: i mean, that's kind of the thing about guix, that you can use it for mostly anything, surely you can still use things in other ways
<florhizome[m]>And i think guix wants to provide stuff that other distros do, too, or guix users want to use things via guix.
<florhizome[m]>I think i arrive at interesting questions, but i agree if you say that's overcomplicated in some way or form^^
<lilyp>gnoo: No one's forcing you to use (guix home)
<lilyp>I personally don't use it yet either, it has a few pet peeves that irk me too much.
<gnoo>lilyp: i mean, it sounds like slightly harder to make guix home behave like that, and if it does work, that'll only work for very few cases
<ngz>rekado: Hello. So we don't duplicate efforts, I worked on fixing a few Texlive packages: see <>. I'll push them to core-updates soon, unless you want to beat me to it. In particular, you may want to look at the dance in texlive-graphics. In particular, it shows that texlive-hyperref is broken.
<lilyp>behave like what?
<gnoo>lilyp: warn the user when a installed program requires a service that is running but is not yet running
<gnoo>s/running.*/not running/
<lilyp>That's not how init systems work at all
<lilyp>If anything, you could do that for services, e.g. foobar-service requires spam-service, but it is enabled when doing "herd start foobar-service"
<lilyp>s/enabled/disabled/ of course
<lilyp>but *programs* won't get that kind of message unless they talk to herd directly
<gnoo>if your user service requires networking, you can't depend on it because system shepherd and user shepherd don't communicate
<gnoo>it'd be nice to have some communication between them, although it won't work on non-guix distors
<lilyp>hmm having inter-shepherd communication would be nice, but we'd have to think about acl then
<jpoiret>we'd just be reinventing dbus i think
<gnoo>how about read-only way, you can know if a service has been started but not do anything
<lilyp>you could try to route stuff through pkexec, but shepherd *can't* listen on dbus yet
<gnoo>and that's good :)
<lilyp>there's a bug in guile sockets that prevents that from happening
<lilyp>or bad
<jpoiret>ah, the famous null byte in socket name one?
<lilyp>exposing read-only views through dbus would be nice
<lilyp>i think ludo was also interested in using goblins for comm, but goblins are atm very experimental and not fit for use
<lilyp>(at least the guile port)
<lilyp>and now I'll eat
<florhizome[m]>Does my shell configuration in guix home have anything to do with the shells spawned from guix shell?
<jpoiret>shell configuration is just an abstraction over .bashrc and .bash_profile iiuc
<jpoiret>so the usual caveats apply
<jpoiret>ie bashrc affects `guix shell` invocations, whereas .bash_proflie doesn't
<sneek>vldn: wb
<vldn>ty, botsnack sneek :)
<vldn>anyway to convert normal scheme code to wisp syntax? parens => indentation?
<vldn>without rewriting ^^
<vldn>maybe @ArneBab
<ArneBab>vldn: the simplest way ist just prefixing any top-level form with . (dot space) :-) — otherwise there isn’t yet. It’s possible to create such a tool, but different from wisp→scheme, scheme→wisp is an optimization problem (wisp has restrictions that make the conversion to scheme easier: The sublist with colon (:) ends on its line)
<ArneBab>I’ve got some ideas how to do it, but have not realized them yet.
<ArneBab>vldn: but the really simplest way is to just have the scheme in a different file and pre-compile that with guile. Then it can be used from wisp just like a wisp file.
<unmatched-paren>hi guix
<unmatched-paren>so i'm trying to make swaylock setuid
<unmatched-paren>(cons #~(string-append #$swaylock "/bin/swaylock") %setuid-programs)
<jpoiret>no, setuid-programs have a dedicated record type
<unmatched-paren>but apparently using files for setuid-programs is deprecated, and i need to use a (setuid-program) object instead
<unmatched-paren>yes, but i couldn't find anything in the manual about it
<jpoiret>see gnu/system/setuid.scm
<unmatched-paren> "The setuid-programs field of an operating-system declaration contains a list of G-expressions denoting the names of programs to be setuid-root"
<jpoiret>you should always use the devel manual
<jpoiret>it used to be that way but has changed since 1.3
<unmatched-paren>ah, ok, thanks
<unmatched-paren>why do we even have a 'stable' manual when guix is a rolling distro/package manager?
<jpoiret>well, we also have point releases, so people might want to use the manual for it
<jpoiret>but i agree that it's confusing
<unmatched-paren>the releases are really just checkpoints tho
<unmatched-paren>surely it's a really, really bad idea to stay on one, since there's no security backports afaik
<efraim>we've discussed moving the 'stable' manual to the versioned release and the devel manual to the current default manual location but nothing's come of it yet
<lilyp>ArneBab: Isn't all Scheme code technically valid wisp? 😜️
<pkill9>wow my root's guix isntallation is almost a year old
***dgcampea-2 is now known as dgcampea
<jpoiret>well, you don't really need root's guix most of the time
<jpoiret>i don't even have one
<Kolev>podman: Error: short-name "jellyfin/jellyfin:latest" did not resolve to an alias and no containers-registries.conf(5) was foun
<ArneBab>lilyp: yes — but you’ll want to prefix top-level definitions with . to avoid calling the defines :-)
<vldn>@ArneBab maybe using some prettified scheme output for an easier conversion, that's the indention is halfway right and it's mostly about deleting parens and adding some colons :D
<vldn>and a flag for using other guile language implementations like (--language=wisp) for guix system files would be really cool, like guix build --language=wisp or guix system reconfigure --language=wisp
<ArneBab>That would be cool, yes
<ArneBab>There are some edge-cases where you need either one more newline or parenthesized style in wisp. I intentionally chose not to resolve them, because that would have made the structure more complex (it would have required taking symbols within earlier lines into account to understand what indentation means, and while a parser can do that, it’s much harder for humans reading the code).
<pinoaffe>vldn: I think a #lang directive in guile would be a more "clean" solution
<pinoaffe>(or something similar)
<vldn>yeah that's like readable handles things and i find the lisp readable project waaay more unreadable than standard lisp :D
<vldn>true pinoaffe
<vldn>or maybe some suffix detection, like if it's a .w file just render is with wisp?
<vldn>but an #lang flag would take all use cases into account like module picking with -e '(...)' e.g.
<pinoaffe>yeah I'm not a fan of mixing infix notation into a lisp either, but to each their own
<rekado>guile 3.0.8 fails its test suite on aarch64
<Kolev>System won't build.
<Haider>small question. Do any of you know how to install the GLAD extention library in Guix.
<Haider>GLEW is avalable but I prefer to use GLAD if avalable.
<rekado>Kolev: error: syncthing-configuratoin: unbound variable
<Kolev>rekado: Oh... Wow. I feel stupid. Now, there are less errors, something to do with setuid:
<Haider>Nevermind, you generate the glad files using this website
<permcu>Hi, is it possible that guix containers (guix shell --container) can't be nested? I get the error: remounting /gnu/store writable: Operation not permitted
<permcu>If thats the case is there a way around it?
<ngz>Hello again.
<permcu>To clarify: I get the error if I try to start a guix container inside an other guix container.
<singpolyma>I think you can't do most guix operations inside a guix container or vm because the store is already read only in there. Maybe you can have something outside the container you signal with some IPC to start a new one?
<jpoiret>you shouldn't be able to talk to the guix daemon inside the container, no?
<jpoiret>the opposite would seem weird
<jpoiret>in any case, inside the container nothing can be more privileged than whoever entered the container, and since that's you, you can't remount /gnu/store
<jpoiret>now, why would it try to remount the store rw, unless there's a new daemon running inside the container
<lilyp>which format character ignores all spaces after newline?
<jpoiret>i think it's a reader parameter rather than a format character
<jpoiret>lilyp: that's hungry-eol-escapes
<permcu>jpoiret, no you can't if you just nest guix shell. But if you run guix system container and than guix shell inside there is a guix daemon to talk to.
<permcu>Nesting guix shell leads to: guix shell: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory
<lilyp>jpoiret: it's ~@
<permcu>And nesting shell in sytem container leads to: remounting /gnu/store writable: Operation not permitted
<jpoiret>ah, format strings, my bad
<permcu>Which makes sense after some thought and your explanation. Thanks singpolyma and jpoiret.
<jpoiret>i thought it was string reader syntax, sorry
<jpoiret>permcu: well, seems like the guix system container can't add anything to the store
<jpoiret>but that's expected
<permcu>I have defined a guix server os that uses guix shell --container for some service and wanted to test it with guix system --container
<permcu>jpoiret yes it can't add anything and fails creating the profile.
<permcu>Does that mean you can't really test a containerized guix operating-system? At leat not if testing means adding to the store.
<permcu>I really like guix "theoretical" container/virtualization capabilities. But damn everytime I try to use it it shoots me in the foot. At least I learned a lot about linux namespaces;)
<lilyp>permcu: wdym by testing? you can absolutely pre-build all the store items you need
<jpoiret>it's 100% expected behavior, since you're an unprivileged user, you shouldn't be able to add anything to the store
<permcu>lilyp: I wanted to set up a local containerized test-server (from an operating-system declaration with guix system container). This works as expected & veth makes the network possible. But the test-server uses guix shell --container [...] inside a git hook and that fails.
<permcu>Now I have to figure out how to prebuild that or abandon this approach.
<permcu>I think.
<jpoiret>you could try --share=/var/guix/daemon-socket/socket
<jpoiret>but you'd need to remove the guix daemon from the config
<permcu>jpoiret: Thanks. That could work. Breaking isolation, but the store is garbage-collected anyway.
<jpoiret>well, that or you'd have to unshare the store, but I don't think that's supported in any way
<jpoiret>i think the `guix system container` command really expects to already have a working store inside the namespace
<permcu>:D No unsharing is not supported. I read the source some time ago and the whole store is just made available.
<permcu>Just checked it again: %store-mapping in file-systems.scm just maps the host store ro into the container namespace.
<singpolyma>jpoiret: oh that's an interesting idea. I've been playing around with ideas to safely run guix system vm on untrusted scm with the result ending up in host store
<permcu>Prebuilding does not seem to work. Running just guix shell on the host, then starting the system container and running guix shell inside the container also leads to the remounting /gnu/store writable error. This seems to indicate that guix shell always needs a working=writable store.
<permcu>This leaves only jpoiret idea as a viable solution.
<permcu>Thank you. You have been great help in triaging this problem.
<balbi_>would anyone be able to point me to a guix system config.scm example using sway? I just installed my system, but I'm having some difficulty figuring out what I'm missing. For example, C-l doesn't work to clear the terminal, any pagers give me errors that terminal is not fully working, and other oddities
<pinoaffe>balbi_: I think your terminal emulator is the issue
<vagrantc>balbi_: i recall having similar issues with foot ... ironically, i use sakura which is not wayland based and it works fine :)
<balbi_>vagrantc: dang, I'm using foot :)
<vagrantc>i probably should have reported bugs ... :/
<balbi_>works fine on my arch installation, though.
<balbi_>I'll install some other terminal emulator for now
<vagrantc>try another emulator (maybe another wayland one) and see ...
<vagrantc>wonder if foot works fine in other environments on guix system ...
<balbi_>anybody using nonguix too? (sorry if this is not a suitable for the channel) I need some help authenticating nonguix substitute server
<vagrantc>you are correct that it's not appropriate :/
<balbi_>sorry, i'll look for help elsewhere :)
<balbi_>hopefully in the near i'll get myself a fully open laptop
<vagrantc>thanks for understanding :)
<balbi_>happy to comply :)
<atomizedalex>The FSF logic applied to safe injection sites would assert that merely directing an addict to that site is the same as advocating the use of heroin.
<vagrantc>all the same, it is what it is.
<pkal>"safe injection sites"?
<pkal>Hmm, never heard of that before
<atomizedalex>It's an analogy to harm reduction measures to help reduce death and disease from drug addiction, taking into account that addicts cannot simply stop using drugs.
<pinoaffe>atomizedalex: that analogy only holds if safe injection sites also distribute heroin
<atomizedalex>In Portugal, where they are most effective, they do
<pinoaffe>I was under the impression that they don't
<lilyp>atomizedalex: That analogy rests on the assumption that the FSF seeks "harm reduction", which is not really the point, though. What the FSF seeks is complete liberation
<lilyp>the Microsoft OS won't be more free just because you have managed to (fool yourself into thinking you've) disable(d) some telemetry
<atomizedalex>"Complete liberation" through control of software, without regard to broader social relations of production. Complete liberation in which in production people are still accessories to the machinery, in the organization of production the needs and desires of the workers are subordinate to competitive demands, subordinate to management prerogative, subordinate to dynamics of accumulation.
<lilyp>stop there or you might accidentally pick up a hammer, a sickle, or the red flag of functional programming
<atomizedalex>I'm not clear on what you mean by that.
<lilyp>or if you decide to do pick them up, welcome to a new world of infighting, but also a perfect opportunity to hate social democrats 🙂️
<atomizedalex>I see better now what you mean.
<atomizedalex>There is a great deal of resonance between the FSF project and Adorno & Horkehimer, that the means of production are simultaneously the means of destruction when imprisoned within the logic of domination.
<lilyp>I haven't read much Horkheimer, but the negative labour done in wide areas of software development is real.
<htsr[m]>Hi guix! I can't guix pull anymore, it raise an exception: In procedure load-thunk-from-memory: incompatible bytecode version
<vagrantc>htsr[m]: is it a very old commit?
<vagrantc>htsr[m]: ... your current pull generation?
<htsr[m]>The last pull was just a few days ago
<jpoiret>htsr[m]: what are you guix pulling from? is it standard?
<jpoiret>I mean, do you use any channels or anything?
<htsr[m]>I'm using another channel which shouldn't be advertisted here
<jpoiret>i wonder where guix is pulling its compiled bytecode from
<htsr[m]>Can I rollback my guix pull generation?
<jpoiret>of course!
<jpoiret>guix pull --list-generations and guix pull --switch-generation
<rekado>and guix pull --roll-back
<ngz>hmm I don't understand where/when the locations part in simple-texlive-package is actually used.
<ngz>Modifying that list doesn't even trigger a rebuild of the package…
<lilyp>ngz: is that part of the origin? of so, poke the hash
<ngz>There's no hash mismatch if I modify it
<ngz>It seems to be used in svn-multi-fetch, which I am currently reading.
<ngz>The problem I am trying to solve is: sometimes, entries in locations are ignored, and I don't know why.
<florhizome[m]> doesn’t have guix and their questions don’t really seem to be able to distinguish nix or guix from other distros
<florhizome[m]><ngz> "There's no hash mismatch if I..." <- guix will use an origin identified by the hash from the store if it can find it, which means all modifications to origin are irrelevant if a matching hash is found
<florhizome[m]>as far as I understand
<ngz>You're right. I always get caught by this.
<tschilptschilp23>I'm utterly failing at configuring gdm to use wayland. I defined a modification of desktop-services to replace the 'original' one like this: Yet this does not work as expected.
<tschilptschilp23>Does anyone have a hint, what I'm doing wrong?
<rekado>tschilptschilp23: this looks fine. How are you using %my-wayland-desktop-services?
<rekado>(I’m doing the exact same thing to my gdm-service-type)
<tschilptschilp23>rekado: here is how I use it: (without the 'new' version of desktop-services, this works nicely)
<tschilptschilp23>rekado: which reminds me that I could get rid of this adb-part, as I'm unable to to root my phone...
<tschilptschilp23>By 'not working as expected' I mean this:
<tschilptschilp23>I place the definition for %my-wayland-desktop-services above the operating-system part, right after the modules. In case this matters!
<tschilptschilp23>it's guix commit d7e1c5acb3c8282c6a568d97ab164db82e33324f, when pulling I saw that there is a ungoogled-chromium-wayland version available, so I became interested!
<rekado>your error is in (append (list … %my-wayland-desktop-services) #;nothing)
<rekado>it should be (append (list …) %my-wayland-desktop-services)
<jeko>Yo Guixters !
<rekado>I didn’t see it right away, but C-M-q in Emacs indented this services expression correctly.
<rekado>tschilptschilp23: you aren’t using Emacs I guess…?
<rekado>the error message says: you should have provided a service here, but you gave it a list (of services)
<rekado>this is correct, but confusing: it never said that it expected a service (just a ‘struct’), and it didn’t print what it got instead.
<rekado>good example of a bad error message
<rekado>I hope we can improve this
<rekado>(warrants a bug report)
*rekado —> zzzZ
<tschilptschilp23>thanks! I'm trying to figure it out now! Yes, I'm on emacs, writing from it right at the moment...
<tschilptschilp23>rekado: thanks again! It certainly reconfigured, let's see if I still can boot... oh my god -- append it says! I keep messing with the logical blocks...