<podiki[m]>lilyp: thanks for the emacs patch number, I forgot I had seen that <podiki[m]>on the native-comp front, is that not something Guix would want for the vanilla emacs package but a variant? <lilyp>I went with safe, minimal changes for now <lilyp>though tbf if native-comp is well-behaved we should probably enable it <luchadoritos>Hello Guix! My system broke recently and I can't exactly figure out why. It seems like key files like "/gnu/store/...-activate.scm.drv" are both empty and live. <lilyp>luchadoritos: do your commands work if you roll back or boot from an earlier generation? <luchadoritos>lilyp: I have tried booting from an earlier generation and the same issues arises. When rolling back using "sudo guix system switch-generation -- -1" I get an error "Wrong type (expecting string): #f" <luchadoritos>I am assuming the error is because the activation file is empty showcased via "cat $activate" <podiki[m]>lilyp: makes sense, then we can do the libgccjit updates for an emacs-native-comp to see (though I've been using it for...as long as it has been available I think) <livoreno>Folks, I'm new to guix so this might be a dumb question, but I want to overwrite xkeyboard-config files to add new layouts. How am I supposed to go about this? I've found the directories but realized they're mounted as read-only, so I imagine there ought to be another path <atka>livoreno: generally you'll declare your keyboard layout in your system configuration <vivien>livoreno, I think I had a similar problem as I wanted to use the “bépo” keyboard layout. It would work out of the box with e.g. GNOME, but the TTYs would default to qwerty. Unfortunately, my solution was to wait a few weeks for linux to include it by default. <wonko-the-sane>livoreno: probably not the answer your looking for as its ugly and hackish, but i just 'mount --bind …' pseudo-clobber the …/xkb/symbols/$FILE im interested in which for me (at least atm) is less punishing than having to a further single minute tweezing or grokking xkb for the rest of my life. but my guix runs in a hvm under xen and my laptop uptime is usually quite a long duration <wonko-the-sane>livoreno: ffs i hate me some xkb it's so crufty and poorly documented. *wonko-the-sane hate hate hate <wonko-the-sane>just for one example if i right now use xkcomp to generate a .xkb file and tell xkbcomp to read it back in it complains that the file it just produced has syntax errors <lilyp>podiki[m]: you would also have to consider all the rebuilds, though perhaps with native-comp people aleady do that? <livoreno>atka, vivien: I'm on a similar boat, except worse in that my layout is a lot more niche than bépo (I use colemak mod-dh wide) <livoreno>So I'll probably try to settle for what wonko-the-sane suggested for now. Thanks, folks. <yarl>Hello, I am reading "2.4.2 Using the Offload Facility". If I understand correctly, this allows to dispatch builds to several guix daemon. What I would like, as I have few machines but not powerful ones, is to be able to build one heavy package, for example llvm, using multiple machines. Is that something possible? I suppose that this offload <yarl>facility won't help. Where should I look to achieve this? I already did something similar using podman (to define and share configurations and data of build hosts) and distcc. Can I avoid podman by defining guix homes for example and set up the guix daemon to use distcc? (There is no distcc package?) Does this seem odd? What would you recommend <jgart[m]>Should the intallation instructions in the manual mention that there is a Debian packaged version of Guix? <jgart[m]>I think it is a pretty convenient piece of information for newcomers wanting to install Guix with a one-liner: `sudo apt install guix` <ZhuAisi[m]>If people use Debian packaged Guix, they can't follow the instructions in manual to setup daemon and etc. <civodul>ZhuAisi[m]: i guess "sudo apt install guix" sets up the daemon for you, right? <jgart[m]>Debian setups up the guix daemon automatically <jgart[m]>The Debian package is also maintained by a veteran Guix contributor: vagrantc_ <jgart[m]>Are there any efforts to fix the `guix shell` experience for golang? <jgart[m]>go libraries are not picked up in a guix shell <jgart[m]>so, I'm not sure how to develop with go using guix currently <civodul>oh, didn't know "guix shell" doesn't work for Go <maddo>howdy, are there any news on gnome 42 for guix? <jgart[m]>I was given a report by a friend that said they were able to get go to pick up the libraries in a shell by also including binutils, glibc, etc...: <jgart[m]>But, I haven't been able to reproduce that. <jgart[m]>maddo: maybe someone is working on it in the core-updates branch? <jgart[m]>Have you looked there to compare with master? <jgart[m]>That's the only way I'd know to check besides searching the mailing lists or irc logs <civodul>jgart[m]: if you have more info, it would be nice to report a bug <civodul>otherwise there likely won't be any effort to fix it :-) <maddo>jgart[m]: checked core-updates and ml, nothing <jgart[m]>maddo: would you like to start working on GNOME 42? <jgart[m]>maybe a few people would like to join you in the efforts <maddo>unfortunately I'm still only a user, and I'm not as confident with my guile-fu to properly contribute to such a huge project (don't think gnome is particularly friendly and easy to port to a systemd-less system) <maddo>however I do want to contribute some of my emacs packages and rewrite how vapoursynth is in guile (basically unusable, since there isn't any plugin in the official repo) <maddo>I created a channel for those <maddo>furthermore vapoursynth ought to be upgraded, APIv4 is considered stable now <maddo>the first thing I'm going to contribute however (soon-ish) if nobody precedes me is the cookbook/refcard <maddo>they're still out of date with guix envirorment etc <maddo>that will probably be a good first issue, so to speak <jgart[m]>maddo: those sound like some great contributions to make <jgart[m]>if you start working on GNOME in a channel ping me and I'd be willing to send patches to help out with updating it or if you have questions <maddo>don't think so, really really don't know much about gnome to do so, only really read that it's a pain on systemd-less distros <jgart[m]>but someone else wrote the service for it <jgart[m]>Where should shepherd services get placed? What directory? <civodul>jgart[m]: the config file for unprivileged users is at ~/.config/shepherd/init.scm <maddo>read the release announcement for shepherd <maddo>I wonder, would guix, as a whole, benefit from fibers like shepherd? <zubbie>new to guix, trying to get x11 forwarding working.. not sure how best to set the option/configuration <zubbie>can someone tell me please where guix stores all the system .scms? <lilyp>guix is already heavily parallelized <lilyp>I don't think fibers would improve build times either, because we need sandboxes for those <jgart[m]>How about for privileged users? Where are shepherd services usually placed by common convention? <lilyp>You specify them in your config.scm? <zubbie>do i set x11 forwarding in /etc/config.scm? <lilyp>x11 forwarding via ssh you mean? should be part of openssh-service-type IIUC <civodul>jgart[m]: like lilyp writes, on Guix System they're in the OS config.scm or in the (gnu services ...) modules <jgart[m]>lilyp: Hi, is that where you add services for your own configs? <civodul>otherwise, Guix Home or Guix System will set up everything as needed <WesterWest[m]>how do build systems which inherit from the gnu build system call different commands? <WesterWest[m]>because gnu build system calls make <stepname> if i understand it corectly <WesterWest[m]>but other build systems simply inherit the phases, how does that work? surely all projects don’t have a makefile <sneek>Welcome back WesterWest[m], you have 1 message! <sneek>WesterWest[m], jpoiret says: each field of a record has a corresponding procedure to access the corresponding value, here it would be `operating-system-user-services` (you can look up the definition of the operating-system record in gnu/system.scm) <zubbie>i see, the config.scm is at /etc/config.scm? where are the gnu service modules? <zubbie>im trying to set a service of openssh-service-type to x11-forwarding? t, would i do that in config.scm? <WesterWest[m]>zubbie: yes, in config.scm where you are adding the openssh-service-type, you pass a configuration to it <robin>zubbie, yes, there's an example in (info "(guix)Networking Services") <zubbie>so do i copy /etc/config.scm to a new file, edit it with that change, then call guix system reconfigure on the new file? <WesterWest[m]>the /etc/config.scm is a file that is not special, it is just the file, you can have the configuration anywhere, the important thing is, that you must provide it to guix system <jaft>Hello, Guix; I was trying to get Blueman to work and saw a few places some people had inquired about the same thing. Following what I found, I installed Blueman, naturally, and added ~(bluetooth-service #:auto-enable? #t)~ and ~(simple-service 'blueman dbus-root-service-type (list blueman))~ as services. <jaft>This got Blueman to run (and I don't seem to have any trouble connecting devices to my bluetooth) but the only thing still not working is clicking "Devices…" on Blueman. <jaft>Any time I do this, I just get back the error "Traceback (most recent call last): File "/gnu/store/xmbnw9y4lg9xdznnkm2rb6982yrs33bv-blueman-2.2.3/lib/python3.9/site-packages/blueman/main/DBusProxies.py", line 52, in call_finish proxy.call_finish(resp) gi.repository.GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying (4)" <lilyp>jaft: instead of blueman you might just want to go with good ol' bluetoothctl ***bjc``` is now known as bjc
<jaft>lilyp: I'd been looking for a GUI, was the thing. Obviously something I can fall back on, if need be. I was figuring people had gotten it working, since there were a few cases of people giving advice on getting it set up. <podiki[m]>lilyp: on the emacs native-comp rebuilds: I believe we can have all the shipped with emacs lisp compiled at build, that does leave extra packages you add to be done on first load (though maybe we could also do that with the emacs-build-system? would be very smooth for users then) <lilyp>podiki[m]: hmm, doing it in combination with a native-comp build system would be the way to go imo ***meo_ is now known as meo
<podiki[m]>sure, that sounds good. I don't know enough about how it works right now, but I think it is probably just running an emacs command on a file to compile it (like byte compile)