IRC channel logs


back to list of logs

<pflanze>Hi. How does one install the sanitizers (asan ..) for gcc or clang on guix?
<csepp>pflanze: -fsanitize is built into gcc
<spacecadet[m]>I think I found an easter egg, there's a stray line feed character at gnu/services/desktop.scm:1817
<pflanze>csepp, thanks, noticed that in the mean time. Not sure about clang, it fails.
<lilyp>there's a page break there, so...
<spacecadet[m]>oh, I see, didn't know what that was
<blip-foo>Totally stumped getting emacs to work with Geiser....
<blip-foo>I added the directory with my emacs packages to the load path with (add-to-list 'load-path "~/.guix-profile/share/emacs/site-lisp/")
<blip-foo>Not sure how to get them loaded now. I tried (guix-emacs-autoload-packages) but it is only loading them from /run/current-system/profile/share/emacs/site-lisp
<blip-foo>New to Guix and not the savvyiest of Emacs users...
<blip-foo>Any help appreciated
<jgart[m]>blip-foo: there be dragons in geiser-guile
<jgart[m]>blip-foo: My advice would be that it is more headaches than it is worth. Start out simply. What are you trying to achieve? You want to make a Guix package and that requires writing Scheme code? Try using scheme-mode and a REPL.
<blip-foo>Thanks for the advice. I am reading the Little Book series and got used to using Geiser on Pop OS
<blip-foo>it is an amazing environment for hacking
<blip-foo>But Guile is not the only issue. I have no idea how to load *anything*
<blip-foo>I used the standard package management for Emacs and got my dot file figured out about 10 years ago.
<blip-foo>I no longer remember the basics!
<jgart[m]>What are you trying to load?
<jgart[m]>A file that contains Scheme code?
<jgart[m]>1. Get in a REPL.
<blip-foo>I can open my scheme file. But I want to load Emacs packages like paredit so that I don't have to count parentheses
<jgart[m]>2. (load "foo.scm")
<jgart[m]>blip-foo: Just use package.el
<blip-foo>Will give that a try. Thanks!
<jgart[m]>Run the following:
<jgart[m]>M-x package-install
<blip-foo>Oh, meaning going to Melpa?
<jgart[m]>and then type the following:
<jgart[m]>no Melpa is involved in that
<jgart[m]>just elpa and nongnu elpa
<jgart[m]>nongnu elpa if you have a version of Emacs that is great than something that is not ancient
<blip-foo>I guess I was under the impression that I could use Guix to be the one package manager to rule them all....
<blip-foo>Yes, this is what I have been doing for quite a while now.
<jgart[m]>Those two repositories are enabled by default
<blip-foo>I was hoping to use Guix to manage my packages....
<jgart[m]>Cool, you're doing well then
<blip-foo>Thanks--I appreciate you replying to my query
<jgart[m]>What distro are you on that you are trying to use Guix to manage your packages?
<jgart[m]>Guix System?
<blip-foo>I am using Guix as a native system
<jgart[m]>Oh ok
<jgart[m]>So just install all the emacs packages that you want along with emacs-next
<jgart[m]>Then they should just automagically appear in your load-path
<blip-foo>It's super cool how you can configure your system services and have a minimal system that is well managed
<blip-foo>Yes, I thought they would apppear.
<blip-foo>I even added the directory where the packages are installed to load-path and checked to see that the load path has that directory
<jgart[m]>RDE is pretty cool and simple to use for Emacs packages management:
<blip-foo>The good news is that spectacular failures are typically an easy fix...
<jgart[m]>RDE is like spacemacs but for everything including Emacs
<blip-foo>Yes, it's on my list of to-dos but thought I would try the easy path! ;)
<jgart[m]>RDE is the easy path. Just copy my rde.scm and then type the following:
<jgart[m]>guix home reconfigure rde.scm
<jgart[m]>and you're down
<blip-foo>cool--do you have it in a repo?
<blip-foo>is that the repo link?
<jgart[m]>maybe just change this block of code to add your own email instead of mine ;()
<jgart[m]>yes, that is the repo link
<blip-foo>Cool!! I'll give it a spin!
<jgart[m]>try it!
<jgart[m]>guix home reconfigure rde.scm
<blip-foo>Ok thanks so much!
<jgart[m]>no probs
<jgart[m]>Oh you might need to add the rde channel to your channels.scm
<jgart[m]>Do you know how to do that?
<jgart[m]>just add this channel block for rde:
<blip-foo>Yes, I thik I can manage that part
<blip-foo>I added non-guix to get my wifi to work
<jgart[m]>to your ~/.config/guix/channels.scm
<jgart[m]>And then do the following
<jgart[m]>guix pull
<jgart[m]>and then:
<jgart[m]>guix home reconfigure rde.scm
<jgart[m]>and then profit
<jgart[m]>and have a good day
<blip-foo>Thanks--you saved me the search for the RDE channel
<jgart[m]>1+ for adding non-guix to get you wifi to work
<blip-foo>really appreciate the help!
<jgart[m]>no probs
<jgart[m]>glad my TLDR helped
<blip-foo>Oh, getting my printer to work was the hard part
<jgart[m]>just send the pdf to your local library and use their CUPS printer
<jgart[m]>or not
<blip-foo>I had to find a single-line command that added a service to provide dns to local devices
<jgart[m]>I don't own a printer so I don't bother with cups
<blip-foo>Again, thanks a bunch!
<jgart[m]>The only cups in my apartment are for drinking coffee
<jgart[m]>no probs
<jgart[m]>blip-foo: this snippet might also be pedagogical:
<jgart[m]>I stole it from unmatched-paren who probably wrote it by reasoning from first principles/RTFM(L) by I just TLDR'd it
<jgart[m]>blip-foo: BTW, there's a new feature-emacs-denote
<jgart[m]>You can add the feature by adding this line next to the other ones in my config
<jgart[m]>(feature-emacs-denote #denote-directory "~/notes")
<jgart[m]>blip-foo: All your notes will then be put in the notes directory in your HOME folder
<jgart[m]>blip-foo: See this commit for more details:
<Guest28>does vainfo uses all the memory for others as well (and get OOM killed?)
<Guest28>fun, if I use 'sudo vainfo' it seems OK
<Guest28>without sudo it leaks memory
<Guest28>next question: how do I cause va-api aware applications to use it in Guix?  Should I add libva to my user profile?
<Mari[m]>has anyone gotten the distrobox package to work?
<Mari[m]>i keep getting this trying to enter the container
<Mari[m]>Error: OCI runtime error: unable to start container "ca8d2984d0a8e4b0e86dac88adb64099408a725fb39102c62e204dfc07654c5b": crun: cgroups in hybrid mode not supported, drop all controllers from cgroupv2
<Mari[m]>from what i'm finding, it seems to be a systemd thing?
<apoorv569[m]>Just turned my system on and noticed that lightdm is now showing anymore... Just a black screen with a blinking cursor.. like a TTY.
<apoorv569[m]>I edited my config and commented out lightdm section and put (service sddm-service-type)
<apoorv569[m]>Rebooted and it works..
<apoorv569[m]>What could have happened to lightdm?
<bumble[m]>hey everyone guix pull is failing for me this evening with this "hint"... (full message at <>)
<bumble[m]>I checked the log and it contains references to guixrus and python-pycrypto
<bumble[m]>is anyone else encountering this? will the problem be resolved if I wait and retry in a week or so?
<jgart[m]>bumble深く傷を: guixrus 💣️ exploded after the core-updates merge
<jgart[m]>I would disable it for now until we find time to fix it
<bumble[m]>@jgart ok thanks
<jgart[m]>no probs, anytime
<jpoiret>spacecadet[m]: on emacs there's page-break-lines-mode that you can use to nicify them
<jpoiret>Mari[m]: well, it's how we run our elogind I would say, I think we explicitely use cgroupv1 for some (good) reason
<jpoiret>I know some people here have had luck using seatd and some custom config but I haven't looked into it at all
<jpoiret>apoorv569[m]: DMs often leave around cache files in eg. /var that need to be deleted
<jpoiret>it's very annoying
<spacecadet[m]>jpoiret: that explains my confusion then, I still use vim so it just looks like an escape code
<jpoiret>in emacs by default it also looks like it, page-break-lines-mode is a package
<jpoiret>maybe there's an equivalent for vim but I wouldn't bet on it, page breaks look like an old GNU convention
<lilyp>i think some tools like less can use it to navigate but don't quote me on that
<lilyp>emacs certainly can
<spacecadet[m]>neat. doesn't look like there's a vim plugin, at least I know what I'm looking at when I see one now
<jpoiret>I know I can navigate using it but why would I use it over grep?
<lilyp>why spawn a new process when you can simply skip ahead a little in your current one?
<jpoiret>that's a little too economical :p also, I said grep but for this i would just use consult-line
<apoorv569[m]><jpoiret> "apoorv569: DMs often leave..." <- Cache files can cause it to not work or something?
<jpoiret>apoorv569[m]: yes, at least that's what some other users have experienced
<jpoiret>tbh I got a bit sick of all those DMs, they might look nice but they're often huge, just to login
<ArneBab>Thank you for updating Mesa! I could drop 4 patches from my local Guix git checkout.
<apoorv569[m]><jpoiret> "tbh I got a bit sick of all..." <- Can agree. I only use DM because I have multiple WM installed.. It's a bit easy to manage sessions this way.
<apoorv569[m]><jpoiret> "apoorv569: yes, at least that'..." <- Let me try..
<apoorv569[m]>I deleted all files under /var/logs/lightdm/
<apoorv569[m]>But I still don't see lightdm...
<jpoiret>do you have any error messages in /var/log/messages or /var/log/debug?
<jpoiret>I haven't used lightdm at all
<jpoiret>anyone know what could be blocking aarch64 support for ghc?
<efraim>jpoiret: someone to do the work. I have part of a patch but my first run through the test suite took more than 52 hours before I stopped it with more than 200 errors
<mfg[m]>cheese doesn't start, but instead fills my RAM until it gets OOM killed and it uses a single cpu 100%. Does someone else have the same problem?
<mfg[m]>well: [57217.344909] traps: cheese[31170] trap int3 ip:7f5e6d775408 sp:7ffe3aa50d60 error:0 in[7f5e6d735000+9d000]
<jpoiret>efraim: ouch
<jpoiret>great work though! I was just wondering, I don't have any aarch64 machine so I can't really work on it
<efraim>if you change the arm/aarch64 sources for x86_64 sources you can test the implementation to see if it works, then its just testing the last bits on actual hardware.
<efraim>that's what I end up doing for a bunch of different builds anyway
<apoorv569[m]><jpoiret> "do you have any error messages..." <- Let me check.
<jonsger>jpoiret, efraim: maybe we could rent an ARM VM at Hetzner: its like 15€/month. I would be interested as well, as I don't have acccess to proper ARM hardware for building and testing packages...
<apoorv569[m]>jpoiret: Hmm.. `/var/log/messages` has something for lightdm..
<apoorv569[m]>Apr 29 01:57:52 localhost shepherd[1]: Service lightdm conflicts with running services (xorg-server).
<apoorv569[m]>Apr 29 07:33:22 localhost shepherd[1]: [lightdm]
<apoorv569[m]>Apr 29 07:33:22 localhost shepherd[1]: [lightdm] ** (lightdm:1311): WARNING **: 07:33:22.296: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files
<apoorv569[m]>Apr 29 07:33:28 localhost shepherd[1]: [lightdm] (lightdm:1311): GLib-GIO-CRITICAL **: 07:33:28.248: g_dbus_connection_call_sync_internal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
<jpoiret>do you use %desktop-services?
<apoorv569[m]>No.. I am using %base-services but I added some services from %desktop-services manually to my config.
<jpoiret>did you add a system dbus?
<apoorv569[m]>Do I need accountsservice?
<apoorv569[m]>I have this in my config, (service dbus-root-service-type)
<jpoiret>I don't think so
<jpoiret>anything related to dbus?
<jpoiret>in the messages i mean
<apoorv569[m]>Yes, there is some messages related to dbus.. most of general info messages.
<apoorv569[m]>Apr 29 07:33:11 localhost wpa_supplicant[764]: dbus: fill_dict_with_properties dbus_interface=fi.w1.wpa_supplicant1.Interface.P2PDevice dbus_property=P2PDeviceConfig getter failed
<apoorv569[m]>The only errors I see related to dbus are,
<apoorv569[m]>and this,
<apoorv569[m]>Apr 29 07:33:28 localhost shepherd[1]: [lightdm] (lightdm:1311): GLib-GIO-CRITICAL **: 07:33:28.248: g_dbus_connection_call_sync_internal: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
<apoorv569[m]>and bunch of these,
<apoorv569[m]>Apr 29 09:26:17 localhost dbus-daemon[508]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.20" (uid=1000 pid=8223 comm="/gnu/store/gfffw11x0dxlyi54vi9fwaqw6z5a5l9a-wirepl") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.0" (uid=0 pid=509 comm="/gnu/store/bvybr9kgmcl8zhd0069a6jkbqadqhcdg-bluez-")
<evilsetg[m]>Has anybody here tried to build a newer version of alacritty? I tried but it just has so many dependencies that I gave up. It does not work on wayland anymore since I updated. So if anyone has some tips over how build rust projects with bazilion depedencies let me know. I did learn about guix import crate, which does help.
<ChocolettePalett>WiFi cards are often coupled with BlueTooth functionality
<efraim>evilsetg[m]: newer alacritty is available in the rust-teams branch, which I hope to merge soon
<evilsetg[m]>Oh, nice. I'll check that out. Thank you!
<futurile>efraim: hi - is the rust-team branch going to be long-running, reamining after the merge. So should any crate updates I work on be against that branch?
<efraim>futurile: sorry, forgot to write back earlier. In theory the branch is supposed to go away after a merge until it's needed again but I think we'll end up with a few rounds of rust-team before it slows down that much
<efraim>so yeah, working against that branch would be best for crate updates
<futurile>efraim: cool, thanks
<Michal_Atlas[m]>Hi Guix,
<Michal_Atlas[m]>I managed to do an in-place conversion of a Nix install to Guix, not sure that's a planned usecase, but I'm glad it worked with only one or two minor hiccups along the way.
<Grimpper>Hello. Quick question. I'm packaging a python app. Anyone knows who calls `intltool` in the python-build-system?
<Grimpper>This is the error. I don't understand why this is being called. Other python packages does not seem to do it and i cannot find any reference on the sources of what I'm trying to package that references this `build_i18n`
<Grimpper>running build_i18n
<Grimpper> intltool-update -p -g ulauncher
<Grimpper>error: [Errno 2] No such file or directory: 'bin/'
<jpoiret>Grimpper: I think now our python has support for very customizable build systems from packages (some PEP), so the package itself might be doing it
<Grimpper>I see. Thanks jpoiret
<jpoiret>have you found a way around it?
<jpoiret>if it's free software you could link it here so that someone could have a look at it (no guarantees)
<Grimpper>Yeah. It's GPL3 (Ulauncher). The error seemed to be very cryptic it did not meant that it was not finding it was really complaining about missing initltool. Very unhelpful error. Now I'm having problems with the check phase which for now I'm skipping. Here you have my progress incase anyone is interested:
<Grimpper>Excuse the unnecessary includes for now I have it with a bunch of other packages
<Grimpper>Skipping checks it build. On running I get this error. Which seems to be that I'm missing a propagated input:
<Grimpper>`OSError: cannot open shared object file: No such file or directory`
<Grimpper>Seems like a rookie mistake but I'm still learning how to package things =#
<jpoiret>regarding this you can probably patch to refer to the absolute path to the .so file
<jpoiret>you will need to add it as an input
<Grimpper>oh. Very helpful!
<Grimpper>Although jpoiret Is this the guix way of doing it? Like there is not a seach path to update so the libraries are found? Is harcoding the path the best workaround?
<jpoiret>you'll need to use (search-input-file inputs "/lib/") probably
<jpoiret>yes, it's even better than search paths
<jpoiret>the two solutions are hardcoding or using search-paths+propagated-inputs
<jpoiret>hardcoding will let people use ulauncher without bringing the dependency into their profile
<jpoiret>that's what we do whenever possible
<Grimpper>ahh. Ture
<jpoiret>them using a very fragile reference to libx11 is pretty bad, they should've relied on some sort of dynamic configure support for it (don't know python build systems this much though, but should be doable)
<Grimpper>But then all the propagated inputs i'm using for python are not a good idea?
<jpoiret>no, for python they're unfortunately required
<jpoiret>(for now)
<Grimpper>it see :)
<jpoiret>there's no way to tell python that some file should use imports from a specific directory
<Grimpper>isn't the PYTHON_PATH useful for that?
<jpoiret>it could be doable though, there are some low-level ways of hooking into the python import machinery
<jpoiret>yes, but it's not something that is kept *in* a package, it's something that Guix can set-up once it knows all of the packages in a profile
<jpoiret>to contrast, each binary in a package should have an RPATH entry that indicates where the other shared libraries should be found. There's no way to do something similar for python
<Grimpper>Seems problematic
<jpoiret>yes, that's why we have propagated-inputs, it mitigates this issue
<jpoiret>the ideal setup requires quite a lot of cooperation from the language
<Grimpper>regarding the hardcoding approach to libx11. It won't appear on the output of the package, right? The path to it will point to another output on the store?
<jpoiret>yes, when i said hardcode I mean putting the full /gnu/store/..../lib/ path there
<jpoiret>the package will then keep a reference to that other output and that way the dependency is clearly identified as well :)
<Grimpper>And when are guix packages appearing on the output? Like in which case I could get /gnu/store/...-ulauncher/lib/libx11...? (inside the ulauncher)
<Grimpper>I was thinking that this:
<Grimpper>`(inputs      (list       libx11))`
<Grimpper>will get the library in the output
<Grimpper>like. If I put that libx11 input. If the user will not have it build it will built and ready in the store so Ulauncher can use the harcoded reference to it
<jpoiret>Grimpper: Guix analyses all store outputs and detects references to other outputs. When you need an output you will always fetch all references as well
<jpoiret>the closure of an output is defined as all the transitive references of that output
<jpoiret>libx11 itself will not be included *in* the output, but the reference is enough
<Grimpper>Understood. In that case. When things get included on the output?
<jpoiret>Grimpper: you need to install them there
<jpoiret>most build-systems take care of this for you
<jpoiret>basically, in the build environment, most things are done in something like /tmp/guix-build-...../, then installed to /gnu/store/......./
<Grimpper>jpoiret : yeah. I've seen the prefix arguments for the install things. Okay. So only what it's explicitly installed goes there...
<Grimpper>BTW. jpoiret. I got the package working thanks to your guidance!!! I really appreciate you help <3
<jpoiret>no worries. If you want to contribute it to guix you'll probably have to figure out the tests though
<Grimpper>Sounds reasonable. I would like to contribute
<jpoiret>mumi hasn't updated since this morning it seems
<Grimpper>jpoiret : The test build manually but the daemon builder is lacking access to '/etc/os-release' any guix way to do this?
<Grimpper>It also needs access to a home directory to create some temporary files. I've fix it like this. Looks appropriate?
<Grimpper>(add-before 'check 'env-setup
<Grimpper>             (lambda _
<Grimpper>               (setenv "HOME" "/tmp")))
<jpoiret>please use for multiline pastes
<Grimpper>excuse me. I will next time
<jpoiret>for /etc/os-release, I guess you can manually create it with dummy contents in the build environment. For the home directory, you could try to create it and set HOME to point there
<Grimpper>like you mean that it's better to use the specific derivation's temp subdir than freely using /tmp?
<jpoiret>well, inside the build environment, you'd need to create /etc/os-release is what I meant
<jpoiret>the build is completely isolated from the outside and can't access things on the host
<jpoiret>also it's accessing /etc/os-release dynamically because of
<jpoiret>"Module for detecting the display protocol.", needs /etc/os-release, yeah sure ☠️
<jpoiret>I'm not seeing any examples of other packages creating a dummy /etc/os-release for their tests
<Grimpper>`/etc/os-release` is definitely not useful since I can run it fine without it
<jpoiret>but you do have it on the host, guix has been shipping it. It's just not available inside the build environment, and so the tests will fail because they try to use it
<jpoiret>i'm talking about the absolute path `/etc/os-release`, not some `/gnu/store/xxxxx/etc/os-release`
<Grimpper>yeah. On the host its there
<Grimpper>but I mean that it does not provide any info of display
<Grimpper>This are the contents:
<jpoiret>yeah, it's just using it to get some info about the host distro, no idea why
<Grimpper>so maybe I can make it point to a dummy file inside the derivation?
<jpoiret>yes, that's what I would do.
<Grimpper>harcode the path like we did on X11 i mean.
<jpoiret>ah, no, don't hardcode to a path, since you actually do want it to read /etc/os-release
<Grimpper>a path on the output derivation I meant
<jpoiret>but you can add a phase before 'test that creates a file at /etc/os-release with summy dummy contents
<Grimpper>you mean leave it relative?
<Grimpper>when you say `/etc/os-release` you mean `/gnu/store/...-ulauncher/etc/os-release`?
<jpoiret>no, I mean /etc/os-release
<jpoiret>that's an absolute path
<jpoiret>but inside of the build environment, it doesn't affect the host at all
<Grimpper>Understoo. I don't really know how to do that
<Grimpper>okay. No I think i understand
<Grimpper>if I create a file there in a phase it will be in the build daemon and won't appear in the output
<Grimpper>sorry for my naiveness
<jpoiret>yes, it will only exist in that specific build process, and disappear once the build finishes one way or another
<Grimpper>jpoiret, I'm getting permission denied with: (open-file "/etc/os-release" "w"). Shouldn't the build daemon be able to create whatever it wants in its environment?
<pkill9_>this sounds fun
<pkill9_>managing guix machines with AI basically
<Guest28>is someone else having issues with vaapi?  vlc seems  to segfault with it
<Guest28>vlc gives me a segfault with vaapi acceleration:
<Guest28>is it possible to disable vaapi using an environment variable or something?
<Guest28>looks like we have a bug in our va-vdpau-driver, if it's this one:
<jpoiret>pkill9_: it makes me extremely sad to see people trying to use LLMs for anything other than conversation partners
<jpoiret>because that's what they're for, and not for anything else
<pkill9_>oh ok, i don't really know
<jpoiret>it's just a statistical model that outputs what the most likely answer to a question is
<jpoiret>it doesn't "know" about anything
<Guest28>I found the problem about vlc/vaapi crashing
<Guest28>it was a stale mesa cache
<Guest28>'rm -rf /home/gilco/.cache/mesa_shader_cache' fixed it
<Guest28>well, ~/.cache/mesa_shader_cache :-()
<Kabouik>Hey #guix, I have a SSD in an external enclosure with USB3 that my Guix system does not recognize, it's not listed in `lsblk`. My other Linux machines do, and I just used one to format it to ext4 actually. Any ideas what could be wrong?
<Kabouik>It's correctly powered on by the Guix machine, I can see the led.
<Kabouik>Well, it seems another port did it. Weird.
<Kabouik>It only shows as sdb though, not as a partition, so I cannot mount it:
<zacchae[m]>if the build servers get too behind, will they start skipping commits all together?
<Kabouik>Weirdly, the disk finally showed a sdb1 partition, after some minutes plugged in. I find it a bit esoteric though.
<zacchae[m]>Just wondering if I need to guix pull another commit or just wait a few days
<tiriftoj>Hello! Sorry to bother, but Guix is telling me to set the necessary environment variables by sourcing the profile in ~/.guix-profile and ~/.config/guix/current, and to make sure that my shell refers to guix binaries in those paths. But both of the said profiles only add directories in /gnu/store to my PATH, and that is where my shell finds the guix binary, too. Yet the hints never go away, and I am also told to run ‘guix pull’ and ‘guix package -u’
<tiriftoj>even after I’ve already done that. Is this okay, or did something go wrong?
<opunix>hey, does somebody know a simple package example for already built binary files? ... i've tried copy-build-system that did not work now i try to use binary-build-system that does not either, if i call the then the path to the binary that works but with my package definition i always get an validate-runpath error?
<lilyp>tiriftoj: this might be related to the glibc etc. update in which case it will typically go away after rebooting or logging out and back in
<Guest28>the cups authentication loops on me; do I need to be part of the lpadmin group?
<graywolf>When you write your own guile scripts, do you depend on pieces of guix or try to avoid it? Why am I asking: I'm writing a script (few actually), and I'm unsure if I should use (guix records) or (srfi srfi-9). Guix records are imho much nice, but guix is not exactly small as a dependency. On other hand, all scripts will be running on guix machines (at least for now), so it might just not matter. I'm
<graywolf>unsure what to do (from philosophical point of view). What do people here think/do?
<lilyp>depends on whether it's a script for guix (aka an extension) or not
<lilyp>The GNU extensions to SRFI-9 do suffice for most non-guix things
<graywolf>It is not, they technically have no relation to guix except that I'm writing them (and will be using them) on guix machines
<graywolf>For me the most interesting part is the (foo (bar 1) (baz 2)) syntax compared to (make-foo 1 2). Like this it's fine, but having all fields listed without the names gets confusing fairly quickly I think.
<graywolf>(When having 10+ fields, and wanted support for default values for some of them)
<lilyp>I don't think having 10+ fields for stuff in a script is wise
<graywolf>Hm, I wanted to mimic the (operating-system) approach to configuration (so something like (my-config ...) as last expression in a config file).
<graywolf>Is there more idiomatic way to do config files for guile/scheme projects?
<lilyp>have a look at guile-json or sxml
<lilyp>there's also syrup IIRC from the spritely community
<lilyp>more often than not you want to read rather than eval your config files
<lilyp>in which case plain (a)lists make for better data structures than records
<graywolf>Thanks for the tip, will think on it some more
<tiriftoj>lilyp: I did see that in the news, but rebooting or even running ‘guix pull’ followed by ‘guix package -u’ a couple more times didn’t help. :/
<tiriftoj>I did also install a custom glibc-locales packages after the upgrade, if that might in any way be related…
<lilyp>for the record this is about the glibc locales, right?
<tiriftoj>The problem I seem to be having? Doesn’t seem like it. Guix only tells me to ‘consider running 'guix pull' followed by 'guix package -u', and to ‘consider setting the necessary environment variables’, in spite of all of those having been done already. There is no mention of glibc locales, and I’m not sure what might be causing this.
<Guest28>I was able to resolve my CUPS pam authentication issue by specifying cups-minimal as the cups package to use in <cups-configuratoin>
<Guest28>cups (the full variant) is built with PAM support but our cups service doesn't configure PAM, and this prevents authenticating to the CUPS server
<graywolf>tiriftoj: I had the same problem, and it was cause by having bad value in LANG. What value do you have in there?
<tiriftoj>graywolf: en_US.UTF-8
<tiriftoj>I did define my custom glibc locale package to include the ‘en_US’ locale, if that is in any way relevant.
<graywolf>Does guile -c '(setlocale LC_ALL "en_US.UTF-8")' succeed?
<tiriftoj>graywolf: It prints nothing to STDOUT and returns 0.
<graywolf>Yeah, then your problem is different than my was, sorry :/
<tiriftoj>Thank you for trying!
<bjc>somehow a bios update yesterday managed to trash the boot sector (i hope) on my guix system. either that, or it can't deal with hybrid boot setups (i can't use legacy or uefi to boot the system)
<bjc>can i use the installer image to just install a grub-uefi on it somehow?
<lilyp>bjc: assuming you know your way around grub commands and don't mind guix shell you might get things working
<bjc>yeah, i can probably do it, i've messed with grub before for other reasons, but i'm rusty
<bjc>the guix ‘grub-efi-bootloader’ uses a hybrid loader, right? or is it pure uefi?
<bjc>because one of the reasons i'm confused is that, in a pure uefi setup, all i need is a partition with the esp type, formatted fat32, with the .efi files in it. so if it's not being found, that hints that the drive is more corrupted than that
<bjc>maybe i should just poke around. in theory i can rebuild this system from scratch from my system and home definitions. all the data i care about is on a nas anyway
<lilyp>guix' efi bootloader can corrupt the efi nvm
<lilyp>iiuc it keeps growing and growing
<jpoiret>bjc: pure uefi
<jpoiret>It might be the efi boot options which aren't present anymore
<lilyp>until there's no more space available at which point grub will error out
<jpoiret>Yeah but that's a kernel thing, not specifically guix, right?
<bjc>i shouldn't need those, right? guix puts the grub loader in /EFI/boot/bootx64.efi, right?
<graywolf>Not by default
<graywolf>That would be grub-efi-bootloader-removable or something
<bjc>hrm. ok
<graywolf>grub-efi-removable-bootloader is the correct order
<bjc>is there no sane way to, say, pull a disk out of one computer and put it into another one, then?
<bjc>cuz this isn't just a guix problem, but seems baked into uefi
<graywolf>That is what the removable is for. (The /bootx64.efi). That should be auto-discovered. Other files in /efi might or might not work (afaik, I'm nowhere EFI expert)
<graywolf>Technically you can just boot live disk and rename the file&directory on efi partition to bootx64.efi
<bjc>that assumes you always use removable or never have a mobo failure, though
<bjc>yeah, i think that's what i'm going to do. just seems kludgy. like the bios should have an option to scan the disk for loaders and set its nvram
<graywolf>It's not like I like it :) (Hint: I know about the -removable-bootloader because EFI on my machine fails to persist the variables, so my system just plain does not boot unless I use the -removable grub :/ )
<bjc>thanks for the advice everyone. i feel less worried
<jpoiret>You could use an EFI shell to set up everything, they are very lightweight
<jpoiret>Not that I've ever done anything substantial with them, mind you
<bjc>neither have i. and only in the tianocore implementation at that
<bjc>yep, just had to copy the bootloader
<stevenroose>Hello, I think something changes recently to the substiture keys or something because my Guix is refusing to use substitutes and building everything manually. Problem is that I usually update keyrings by reconfiguring but right now that means that I have to manually build the linux kernel which if obviously not ideal.
<stevenroose>There must be a way to manually pull in new keyring info without having to reconfigure my system?
<stevenroose>Or am I trying to get packages too new that don't have substitutes yet?
<moong>Having trouble booting into a guix install on a VPS. Everything seems to have gone ok, kernel loads but then I get "waiting for partition" and it fails to boot. I find it strange because, well grub is loading the kernel off that partition
<jackhill>moong: I wonder if you're missing the kernel module for the block device. Which VPS provider? If it's not clear which one it is, it might be possible to boot one of their supported images and see what it uses :)
<jackhill>stevenroose: I don't believe the keys have changed (and if they do, you should be wary). That's not to say your local guix-daemon has forgotten them for some reason. I'm not sure the best way to troubleshoot, but you might try looking at what's in /etc/guix/acl, and what substitute servers the guix-deamon command invocation has.
<jackhill>for what it's worth, substitutes are working for me from the USA with not key changes
<stevenroose>jackhill: I have 3 keys in that file, starting with C1FD53, 8D156F and 7D6029
<stevenroose>I have been running a lot of guix pull lately because some builds have broken and I'm waiting for fixes to get merged.
<stevenroose>But I haven't done anything exotic, so I can hardly believe the daemon forgot about keys..
<stevenroose>jackhill: guix-daemon has expected substitures: --substitute-urls
<stevenroose>I found an issue for a request to add a cli flag to only install when a substitute is available, but it is still open, so I reckon nothing of the sort exists?
<jackhill>stevenroose: 8D and 7D look like the righ keys to me for the primary build farms
<jackhill>I'm not sure what's next, unfortunately
<jackhill>what's next to try that is
<stevenroose>Maybe reboot, always a good idea
<jackhill>haha, yeah, why not
<stevenroose>no luck, when running reconfigure -v 9 it doesn't mention anything about even trying to look forthe susbsitute..
<TristanCottam[m]>Hi guys, noob question: I've made changes to `guix/build/minetest-build-system`, how can I take them into account when running `sudo guix system reconfigure`?
<stevenroose>And immediatelly starts to build linux 6.2.13
<stevenroose>jackhill: are you using gnu kernel or nongnu?
<TristanCottam[m]>I expected `./pre-inst-env` to do the trick, I can't find anything else in the docs
<moong>jackhill: aha! looks like virtio_scsi is missing
<bjc>TristanCottam[m]: ‘./pre-inst-env guix system reconfigure config.scm’ works for me
<bjc>it's how i've been working for some weeks now while i wait for my patches to get merged
<jackhill>moong: cool, yeah, looks like that's the one I've had to add in the past
<jackhill>`(initrd-modules (cons "virtio_scsi" %base-initrd-modules))` in the operating-system definition in case you didn't know
<stevenroose>is there a way to use the guix cli to test if a package has an available substiture?
<stevenroose>But since I'm having the same issue with both an official guix repo package and a nonguix package, I think the issue is not at the substitute level
<bjc>stevenroose: guix weather package-name
<stevenroose>bjc: thanks! that command isn't listing the nonguix substitute repo for nonguix packages..
<TristanCottam[m]>jpoiret: Could you help me understand what to do by any chance? I'd also love to contribute my work.
<stevenroose>bjc: hmm, the rust package of default repo doesn't have substitutes
<bjc>there were some patches to the rust build rules recently, which may have triggered a rebuild, and it can take some time™ for that to complete
<stevenroose>also says 0% available if I use --substitute-urls manually
<stevenroose>Ok so it's probably a recentness issue :p
<stevenroose>good, then I can wait
<TristanCottam[m]>jpoiret: Woops, seems I'm getting notified by old messages, I thought you were online
<val[m]>Tristan Cottam: the matrix bridge has 4 hours lag
<val[m]>actually it looks like it's backfilling four hours' worth of chat all at once
<TristanCottam[m]>val: Oh, thanks for the tip
<opunix>hey, i have a problem with a custom package i wrote does anybody know how to handle it? unfortunatly i could not find any solution in the manual or searching for it
<mirai>civodul: is there some reason why the field type in define-configuration can be specified with and without parenthesis? i.e. (foo (string) …) and (bar string …) ?
<civodul>mirai: hmm not sure; i'm not the original author tho :-)
<RavenJoad>If I use "guix shell --root=shell" to preserve a root to the store for a project, will Guix continue to use that root later? Or does that just prevent those items from being GC'd from the store?
<graywolf>Hello :) So I've pulled new guix, with glibc 2.35, however when I try to reconfigure my system, guix still tries to build locales-2.33, causing the command to fail. Any tips how to figure out why locales-2.33 is being built and how to make it to stop?
<RavenJoad>Perhaps a different way to achieve the same result is: Can you use "guix shell" (or perhaps another command to achieve the same thing as guix shell) on a profile?
<porcupirate>Hi guix,
<porcupirate>I'm trying to configure a server running guix as a general print server. I'm having a problem described (and solved for systems that aren't configured like guix) here:
<porcupirate>What do I need to add to my system config to achieve this?
<RavenJoad>porcupirate: I think you want location-access-controls and its location-access-control-list.
<RavenJoad> provides a better example of the format than the documentation at (guix) Printing Services.
<ChocolettePalett>It's huge :0
<porcupirate>Thank you
<xelxebar>Think I've been hitting for the last week and a half. Last successful pull is on 04/20 at b82a18c. Since then every guix pull is failing with that "write_wait_fd: unimplemented" error.
<ChocolettePalett>Oh I think I stumbled on this one too in the past
<ChocolettePalett>Yes, on 20.04 exactly I failed to guix system init
<Altadil>Hi, I have a silly noob question : when I add a service to my system config (say, for instance the bluetooth service), does it automatically pull in required packages, or do I need to also add them to the packages field of my config file ?
<rekado>Altadil: depends on the service, but generally services do have references to packages they use.
<rekado>Altadil: many services let you override the package variant they use
<Altadil>Ok, thanks :)
<opunix>ok i still can not build the package for guix with any kind of build-system either copy nor binary ... and using the whole pre-inst-env does not make it any better ... still the same errors maybe i missed something does anybody know how to fix this?
<agnem>Hi, does anyone know how to tell mcron how to treat jobs that run long and overlap their next invocation time? I want to ensure that two jobs don't run at once.
<opunix>agnem: well, i think one solution would be to handle it in your script that is run by creating a PID file and if it still exists the previous job is still running otherwise start
<agnem>opunix: Alright, thank you for the help :)
<minima>hi, can anyone give me a refresher on why guix and guix packages live under
<minima>different "profile variables"? i.e. ~/.guix-profile and ~/.config/guix/current
<minima>my intuition is that you may want to have flexibility in terms of the packages you install with guix while maintaining the guix binary itself at the latest release?
<jpoiret>minima: the main reason is that you need to update guix before being able to update the packages
<jpoiret>so putting them both in the same profile would be very annoying
<minima>oh, because then you'd need to run things twice, i guess?
<jpoiret>yeah, you'd need to update only the guix in the profile, then only the packages
<minima>cool, got it, thanks jpoiret!! v helpful
<jpoiret>also, note that it's not `guix package` that takes care of updating guix, since the process is a bit different. `guix pull` and `guix package` are very different
<jpoiret>you can use guix package to install a guix, but it will always be out of date since the guix package definition in guix is only updated when very necessary
<jpoiret>that's the guix that's used by the daemon, or the one that's installed system-wide by default though
<opunix>is there a tutorial how to add a prebuild binary in a package ... copy-build-system seems not to work
<minima>thanks jpoiret
<jpoiret>opunix: you'll need to patch the elf binaries to add the proper runpaths to them
<jpoiret>but they might just not work on guix
<jpoiret>there's also the possibility of using an FHS container, though it will not package anything, just let you run pre-built binaries
<opunix>jpoiret: for now it is working but only if i just run it with /path/to/binary
<opunix>jpoiret: is there some tutorial for the container ?
<opunix>jpoiret: it would be nice to be able to run the binary because i would like to have it as a service in my home services collection
<minima>jpoiret: you're making a distinction between guix the daemon and guix the command line binary, if i get it correctly; and you're saying that only the command line binary is managed/updated via guix pull?
<jpoiret>there's an introduction at
<opunix>jpoiret: thx ;-)
<jpoiret>minima: yes, and only the one you have as your user if you source .config/guix/current/etc/profile
<jpoiret>the daemon is updated whenever the guix package gets updated in guix, which is different
<jpoiret>but that also includes the system-wide guix that you get before the first `guix pull`. Notably, substitute fetching is done through the internal plumbing command `guix substitute`, which uses the system-wide guix!
<minima>hm got it, i think, and the daemon and the cli binary must also map to different parts of the repository, i suppose?
<minima>repo as in "codebase"
<opunix>jpoiret: just for curiousity if the command /path/to/binary is working ... is there the posibility it is not gonna be possible to package it ?
<jpoiret>the daemon is in nix/, and there isn't really a CLI binary, it's just a wrapper around a guile invocation. The CLI commands are at `guix/scripts/`
<jpoiret>opunix: no, on the contrary it, it's likely it will work
<jpoiret>but you'll need to patch the interpreter, by using patchelf probably
<minima>jpoiret: ok, super, kilo-thanks! :)
<jpoiret>that pastebin is 404 for me
<jpoiret>you can use
<opunix>jpoiret: it always fails at validate-runpath
<jpoiret>it's probably because it refers to some shared binaries that aren't in the runpath of the ELF file. That's what patchelf is also for, you'll need to add the proper RUNPATH with it so that all needed .so files are found
<jpoiret>ah, it's even the validate-runpath code that's failing! but i think what i said still applies, it's just that here the binary doesn't even have a RUNPATH and so the validation code doesn't handle this case
<opunix>jpoiret: it does need only glibc
<opunix>jpoiret: that one might help ;-)
<opunix>jpoiret: as you can see i tried a lot to make it run ... there are some imports that are for sure not neeeded ... so maybe i really missed something
<opunix>jpoiret: where can i set the RUNPATH is it a env var?
<jpoiret>no, it's what patchelf adds itself through the #:patchelf-plan argument
<jpoiret>I guess you could ask in that other channel, since the binary-build-system is theirs (and I don't know too much about it)
<opunix>jpoiret: thx ;-)
<apteryx>our cups service started needing some PAM config to allow users to authenticate, blocking simple things such as adding a printer
<apteryx>should we commit the simple workaround already: use cups-minimal by default which is built without linux-pam hence doesn't exhibit this problem
<TristanCottam[m]>Hi everyone!
<TristanCottam[m]>Can someone help me understand how I can make use of changes made to a build system when running `sudo guix system reconfigure`?
<TristanCottam[m]>I expected `./pre-inst-env` to do the trick, I couldn't find anything else in the docs.
<opunix>jpoiret: i tried now the container version that seems not to work for now ...
<jpoiret>TristanCottam[m]: sudo ./pre-inst-env ... should be enough
<TristanCottam[m]>I'll give it another go, thanks!
<mihi>Hmm. I can spot a pattern. Every first of the month, rollover of the chat logs is not working (since December 2022). Is there some cronjob delayed due to other cronjobs running on the first of the month? :D
<son0p>Hi, after doing pull and then upgrade I can't run guix commands in
<son0p> the terminal because it shows an error ( version
<son0p> `GLIBC_2.34' not found...)
<son0p>however from emacs I can run some guix commands, but if I try to install glibc 2.35, I get an error: ice-9/boot-9.scm:1685:16: In procedure raise-exception: ERROR: 1. &profile-collision-error:
<dcunit3d>if i want to use the extra-special-file service to create a file, how do i get it to `mkdir -p` the intermediate directories?
<jpoiret>son0p: don't try to install glibc manually, you should never have to do that
<jpoiret>do all guix commands fail?
<son0p>jpoiret: I have tried guix pull, guix describe, all fail
<son0p>but in emacs I can query guix profiles, packages etc
<dcunit3d>also, if it fails in making the extra-special-file, it completes the "making '/gnu/store/a1b2...c3d4-system' the current system" step, the "setuid programs" step and begins the "populating /etc..." step, but fails.
<dcunit3d>i'm looking at the `local-file` source. i think my system's alright and i can install, but the /run/current-system link is pointing at the new system.
<dcunit3d>if nothing else, i'm just going to create the directories.
<RavenJoad>If I use "guix shell --root=shell" to preserve a root to the store for a project, which outputs a link to the profile, can I use "guix shell" (or perhaps another command that achieves the same thing as guix shell) on that profile?
<civodul>RavenJoad: hi! yes, you can
<civodul>however, '--root' should rarely be needed with 'guix shell'
<civodul>because 'guix shell' maintains a cache of GC roots
<civodul>so there's usually no gain in using --root
<opunix>does anybody know how to get the go build system running? i tried to generate an scm file with guix import go /path/to/the/repo and it seems like it needs more then just that command to run properly
<RavenJoad>civodul: Good to know. I assume that cache is in /tmp? The reason I ask about making explicit roots is that I am about to travel for a while and do not want a GC after some work elsewhere to delete my development packages.
<civodul>RavenJoad: the cache is in ~/.cache/guix/profiles
<civodul>well yes, traveling is perhaps that one case where you can use --root if you want to be 100% sure :-)
<civodul>(the GC roots under ~/.cache get periodically cleaned up)
<RavenJoad>Good to know. Is there anything I need to do to make a guix shell-like environment if I have the root manually saved?
<Grimpper>Does any one know which package includes the `gbus` command?
<Grimpper>oh. I see is under glib:bin
<Guest5697>hello, sssd package is broken after current pull. due to it I have broken system, even can't run icedove...
<Guest5697>reverting to previous generation doesn't work...
<lilyp>Guest5697: can you give us a commit hash?
<lilyp>I'm currently trying to build it on master+2 unrelated commits
<Guest5697>just run guix pull
<lilyp>okay, it seems to fail reproducibly
<Guest5697>i am trying to revert last two changes to sssd. they seem to be about some xml/pdf, something that looks like messages in the error
<lilyp>i don't think those change anything, they're for the docs
<lilyp>more importantly, there are test failures
<podiki[m]>what is the current on gcc, gcc-toolchain, etc.? libstdc++ used to be in gcc:lib, now where is it?
<Guest5697>lilyp You are right, it didn't help.
<podiki[m]>oh, i guess there's make-libstdc++ directly, never knew
<unmatched-paren>hello, guix
<TristanCottam[m]>Is it possible to use additional channels when using `pre-inst-env`?
<TristanCottam[m]>i.e. the ones I have defined for my user
<kaelyn>TristanCottam[m]: I haven't attempted / figured out how to use defined channels like in channels.scm, but I have successfully used local copies of channels with `pre-inst-env` by passing them using `-L` (e.g. `./pre-inst-env guix build -L ~/src/channel1 -L ~/src/channel2 some-package`)
<TristanCottam[m]>That's what I wanted to avoid, but I guess I'll use that workaround for now, thanks!
<kaelyn>(and if there is a better way, I'd also like to know it!)