IRC channel logs


back to list of logs

<roptat>\o/ I managed to update maven
<rekado>roptat: woo!
<roptat>now I need to see if I can still use it to build java-jmh ^^
*Krey_LM went to ask in the forsaken land
<roptat>I had to update a few packages at the same time too, I'll need to check if I can do that independently or not
<vivien>Krey_LM, did you try to reboot? (sorry that’s what I say when someone needs help but I’m not able to help for lack of information or lack of knowledge about the subject)
<Krey_LM>what more info you need? x.x
<Krey_LM>it's visionbook N15G
<vivien>Did audio work before?
<Krey_LM>this system never tasted freedom before
<rekado>zimoun`: 51870 looks good to me.
<jpoiret>do you know if your sound card works on linux? that's the first thing i'd check
<jpoiret>or if there is an outstanding kernel bug
<rekado>I’ll also remove python2-itsdangerous, apply your patches, and then see if there are any missing packages.
<Krey_LM>i don't even know what the hardware is the manufacturer doesn't provide that
<Krey_LM>oh lshw might
<jpoiret>lspci rather
<nckx>Might's well add -vv to lspci which will print a bit more, particularly which driver the kernel thinks applies, if any.
<Krey_LM>lspci output
<Krey_LM>00:0e.0 Multimedia audio controller: Intel Corporation Celeron/Pentium Silver Processor High Definition Audio (rev 03)
<Krey_LM>that should be in linux no?
<zimoun`>rekado: cool! Thanks for reviewing. Feel free to push, I do not have this power. :-)
<roptat>Krey_LM, you're not alone apparently:
<Krey_LM>ehww ubuntu can't i rather be alone
<Krey_LM>... but like continue helping me
<roptat>what can I say, maybe on the newest kernel version, you'll get the driver?
<roptat>from what I read it's very recent and might not be in Linux yet
<roptat>from what I read "let's merge, this should land in the upstream kernel 5.16 at best (still missing the updated codec parts)."
<vivien>There exists USB sound cards (I know because of, I don’t know how well that works, you might find more affordable things like that elsewhere)
<Krey_LM>can't do USB workaround this is a system for a person who expects everything to work
<bbsl>If I need to add inputs to a package that I am "inherit"ing and changing is there a function to append to the existing inputs instead of overwriting them?
<vagrantc>i'm not sure guix is a good default environment for someone who expects everything to work without glitches
<vagrantc>it's a bit more of a DIY environment, which has some very positive things, but plenty of occasional surprises or challenges
<roptat>and in that case, the driver is not released yet, so you'll have to wait at least, can't help you
<Krey_LM>they do what i tell them and will suffer with system that doesn't work perfectly if needed, but i want to avoid them shilling on guix >.>
<roptat>complain to Torvalds :p
<vagrantc>seems like a recipie for trouble :P
<vivien>bbsl, `(("input" ,input) ,@(package-inputs the-package)) should have input and all inputs of the-package
<zimoun`>vagrantc: it depends what you consider as glitches or surprises ;-)
<Krey_LM>why to torvalds
<vagrantc>zimoun`: well, what i said was in a certain context :)
<roptat>(well actually not, but the issue you have, from my understanding, is there's no driver for your card in the kernel)
<roptat>(and there won't be until 5.16, and the latest is 5.15.4)
<zimoun`>yeah :-) And I agree.
<vivien>Krey_LM, also, advertising a system you know to people exposes you to the risk of you being assigned to fix all issues regarding computers in general
<nckx>Krey_LM: Did you try any other free operating system on this machine before?
<nckx>vivien: +++
<bbsl>vivien: ty. forgive me Im not so familiar with the syntax so that went above my head but I tried just adding the input I needed and that seems to have not trampled over the others somehow? though I dont understand how
<roptat>oh no a maven dependent failed in a weird way :/
<Krey_LM>nckx, no just guix
<Krey_LM>vivien, i am not advertising it.. this is a system for a friend
<zimoun`>vagrantc: mimicking The Zen of Python, «Although that way may not be obvious at first unless you're ’ready to invest and get why it is indeed like that’». ;-)
<Krey_LM>just told everyone that i won't talk with them if they don't have a sane devices around me so they got this thing thinking it's great
<zimoun`>rekado: thanks for 51870
<rekado>zimoun`: no problem!
<rekado>uhm, I guess booting Ubuntu, installing Guix, and then doing “guix system init /” doesn’t work any more.
<rekado>because I’de be overwriting /gnu/store
<rekado>no idea how to install Guix System on this thing then
*rekado –> zzzZ
<roptat>ah if I inherit the phases from an unrelated package, that sure won't work...
<vivien>Sorry I will have to sleep
<bbsl>vivien: ok I got what you said above now :) tyvm for the help now I have a working example of something useful :)
<nckx>rekado: Do they have >1 SATA connectors?
<vagrantc>installing guix via the binary tarball rather than the .deb ... maybe the .deb actually would work, as initially as "guix" itself is actually outside of /gnu/store and can't conflict...
<vagrantc>which i've heard of people using the guix.deb packages on ubuntu too
<vagrantc>sneek: later tell rekado did you try installing the guix.deb package, or guix from the binary tarball? i've always ended up installing to Debian one partition, mounting another partition, and then guix system init /otherpartition
<sneek>Got it.
<singpolyma>vagrantc: apt install guix is pretty nice
<nckx>vagrantc: <on ubuntu too> Eh?
<nckx>Isn't Ubuntu just a rebranded Debian with, like, ZFS and Snaps and Wonky Wabbit codenames?
<nckx>I always assumed Guix in Debian would mean Guix in Ubuntu in the next release or so.
<vagrantc>they've pulled it in, it's almost surely in their "community supported" section of the archive
<vagrantc>i imagine it works about as well as on Debian, but never tried it
<vagrantc>that said, i've been working more with guix on Debian lately ... for a long time i felt like an imposter because i maintained the debian package but mostly just used Guix System :)
***yewscion is now known as Guest7232
***yewscion42 is now known as yewscion
<Krey_LM> seems that i have the module for the audio
<Krey_LM> eh? I have the kernel driver so wth!
***lukedashjr is now known as luke-jr
<Krey_LM>ehh howddya get alsa on guix u.u
<cbaines>rekado, I think I used a USB installer when installing Guix on the Honeycomb build machine that I have
<cbaines>I think I might have needed to tweak it to get it to boot though
***xgqtd_ is now known as xgqt
<Krey_LM>$ sudo guix system reconfigure /etc/config.scm
<Krey_LM>guix system: error: duplicate 'asound.conf' entry for /etc
<nckx>Krey_LM: snd_hda_intel is a driver for ALL Intel HDA chips ever made. It does not mean that your new-as-heck chip is supported, mainly because it isn't.
<nckx>Krey_LM: You probably already have alsa-service-type as part of %desktop-services or so.
***xgqt is now known as xgqtd
<nckx>No point in adding it twice.
***xgqtd is now known as xgqt
<nckx>You have no sound because Linux doesn't have a driver for your sound chip yet. End of story.
<Krey_LM>it has the driver loaded
<Krey_LM>and manual says that  i need alsa-service-type
<Krey_LM>where adding it results in the err above
<nckx>No, and no.
<nckx>vagrantc: Thanks! <about as well as on Debian> Is that well?
<zimoun`>apteryx: bah run packages test in parallel is a failure. JULIA_CPU_THREADS does not do much. Basically, it seems depending on how test/runtests.jl deals with “parallelism”. Anyway, I am going to send 3 patches for v2.
<Krey_LM>nckx: see?
<Krey_LM>> driver: snd_hda_intel
<nckx>That's the same link you posted already.
<nckx>Re-read my answer.
<Krey_LM>elaborate your answer then the CPU is intel N4100
<Krey_LM>bcs apparently it works on ubuntu from what my friend told me who seems to have the same CPU
<Krey_LM>so logically i should just need alsa-service-type ? O.o
<Krey_LM>which seems bugged as it output duplicate asound.conf err
<Krey_LM>regardless of asound.conf presence
<nckx>I have already told you that you already have alsa-service-type as part of the default services.
<Krey_LM>not pulseaudio though
<nckx>Pulseaudio is not a system service. It's a user process started ‘on demand’ by clients. I bet ‘pgrep pulseaudio’ will return a running PID.
<Krey_LM>it has pulseaudio-service-type though
<nckx>Uhuh. Doesn't start a daemon.
<Krey_LM>what it does then? seems relevant
<nckx>Are you using %desktop-services?
<Krey_LM>nckx, yes
*Krey_LM doesn't have alsa command
<Krey_LM>maybe alsa not running locally?
<nckx><nckx, yes> OK, then you already have ALSA & Pulseaudio.
<zimoun`>with option -K inside /tmp/guix-build-…/environment-variables it is variables for the build, not the check phase, right?
<nckx>Krey_LM: Your ALSA & Pulseaudio are fine.
<nckx>Stop ‘debugging’ them.
<Krey_LM>what's not fine then
<nckx>According to rop tat, kernel driver support for your card.
<nckx>Which kernel does your friend run, and which CPU do they have?
<nckx>I'm not actually sure that the HDA is tied to the CPU at all. Are you sure that's the case?
<Krey_LM>dunno unable to ask them now
<nckx>It might not be relevant anyway.
<Krey_LM>i needed the hda driver for my notebook for audio to work i think
<Krey_LM>(not this one)
<lfam>Did we get the PCI ID of the sound card?
<roptat>Krey_LM, if you want the alsa commands, you can install alsa-lib, but I really don't think it'll do anything for you
<lfam>`lspci -nn | grep -i audio`
<Krey_LM>$ guix shell pciutils -- lspci -nn | grep -i audio
<Krey_LM>00:0e.0 Multimedia audio controller [0401]: Intel Corporation Celeron/Pentium Silver Processor High Definition Audio [8086:3198] (rev 03)
<lfam>Also, the ALSA tools are provided by the 'alsa-utils' package, not 'alsa-lib'
<roptat>oh oops, my bad
<lfam>I don't know how reputable this site is, but it suggests that this card should have support in 5.14: <>
<lfam>Krey_LM: Do you know if you are using UEFI or not?
<lfam>I would do `guix environment --ad-hoc alsa-utils -- aplay -L`
<lfam>Or simpler, with `aplay -l`
<Krey_LM>seems relevant the article seems to think that it happens when there are two sound cards?
<Krey_LM> and i seem to have sane alsamixer?
*Krey_LM is doing the aplay now
<vagrantc>nckx: there are some quirks ... like having to use "guix shell" to be able to successfully ./pre-inst-env ... which is kind of cool and kind of annoying ... but yeah, guix on debian seems to be working ok-ish. some weird issues crop up with XDG* variables when you have incompatible libraries
<lfam>In alsamixer, you can press F6 to select another sound card, Krey_LM
<Krey_LM>i did that
<lfam>Yeah, it looks like you only have the HDMI audio output
<Krey_LM>it shows pulseaudio by default though
<Krey_LM>checking HDMI
<Krey_LM>cant i dont have microhdmi
<nckx>vagrantc: <having to use> I think that's actually universal and deliberate, unless you explicitly install Guix's numerous guile-* inputs yourself.
<lfam>I'm sure it would work
<nckx>(Now *that* might not work in Debian, I don't know.)
<nckx>(Maybe that's what you meant to begin with.)
<lfam>Krey_LM: This discussion suggests that you may want to be sure to use UEFI: <>
<lfam>HDMI audio / video output worked out of the box for me in Debian
<Krey_LM>how do i do UEFI on guix
<lfam>That I do not know...
<nckx>Krey_LM: Does /sys/firmware/efi exist on your system?
<nckx>The Guix System.
<Krey_LM>$ ls /sys/firmware/efi/
<Krey_LM>config_table  esrt/             fw_vendor  runtime-map/  vars/
<Krey_LM>efivars/      fw_platform_size  runtime    systab
<nckx>Congrats, you are using UEFI.
<Krey_LM>so what now
<lfam>I would reboot and look in the UEFI menu, after reading this post:
<lfam>I guess you should make sure "that all onboard hardware [is] enabled"
<lfam>And maybe those other points too
<lfam>Beyond this, idk
<Krey_LM>> options snd-hda-intel dmic_detect=0
<lfam>I had problems in the past with an Intel sound card on linux
<lfam>I had to wait until linux fixed it
<lfam>Yeah maybe
<Krey_LM>trying the bios
<nckx>Krey_LM: dmic_detect says: deprecated, use snd-intel-dspcfg.dsp_driver option instead
<vagrantc>nckx: there may be other ways to solve the issue, but i actually find "guix shell --development guix ..." makes sure i don't have to manually figure out what i need to run :)
<Krey_LM> snd-intel-dspcfg.dsp_driver=0 ?
<apteryx>Krey_LM: I have this for fixing the sound on my box: "snd_hda_intel.dmic_detect=0"
<nckx>Where dsp_driver:Force the DSP driver for Intel DSP (0=auto, 1=legacy, 2=SST, 3=SOF) (int)
<nckx>Krey_LM: ☝
<nckx>So snd_hda_intel.dmic_detect may stop working in future.
<Krey_LM>what do i put in grub.cfg then!
<Krey_LM> snd-intel-dspcfg.dsp_driver=0 ?
<nckx>=3, I'd say.
<nckx>Er, or, alternatively, I'm an idiot who can't read or tell ‘SOF’ from ‘OFF’. This is also possible.
<nckx>Let me revise that to ‘heck if I know, add snd_hda_intel.dmic_detect=0 and see if it actually helps, then we can think about making it non-deprecated later.’
*apteryx retries a reboot on a core-updates-frozen reconfigured system
*nckx hasn't had any luck with the c-u's yet. ☹
<lfam>This command returns different results for me on different computers:
<lfam>guix time-machine --commit=c70eadeaed9367e45be3797a17d3a34e5f8f67cd -- build --no-grafts krita -d
<lfam>They are both x86_64 computers
<lfam>That's unexpected, right?
<lfam>Seems to reproduce for any package
<lfam>On computer A: /gnu/store/cmp1569pws4357b7aw2p250ahhn7gmfa-krita-4.4.8.drv
<lfam>On computer B: /gnu/store/q96safbj6q1sic9by3hi70j9md7g7xmi-krita-4.4.8.drv
<jackhill>lfam: that does sound unexpected to me. Have you tried to see what's different between the derevation? I'm running it locally here to see what I get.
<lfam>Yes, I can share the two derivations
<lfam>I'll use the derivations of hello because they are smaller
<jackhill>I got /gnu/store/cmp1569pws4357b7aw2p250ahhn7gmfa-krita-4.4.8.drv
<lfam>Can anybody else try it?
<jackhill>I'll try on computer #2
<Krey_LM>didn't work
*Krey_LM gives up for now
<lfam>I wrote an email about it:
<nckx>Krey_LM: In case you missed my last desperate message, here it is again: Let me revise that to ‘heck if I know, add snd_hda_intel.dmic_detect=0 and see if it actually helps, then we can think about making it non-deprecated later.’
*nckx tries lfam's fun game.
<lfam>nckx: Take a guess at what server "b" is
<lfam>And maybe try to reproduce it there
<lfam>Although it's best to type the command in yourself rather than copy and paste it
<nckx>Well they both start with b 😃 One feel's ‘b’er, though (…uggy? surely not), so I'll try it there.
<nckx>lfam: <type> Eh, what?
<lfam>Well, what if it was a trick using tricky unicode glyphs
<lfam>I always feel uncomfortable telling people "just copy this command and run it on $importantcomputer"
*nckx didn't want to cheat by reading the mail.
<lfam>Anyways, we *did* build the right derivation:
<nckx>I can't reproduce the fun part.
<lfam>And I got the right derivation on two other computers
<lfam>That's so interesting
<lfam>So it's just my Guix command on berlin that has a different dependency graph?
<lfam>I think I better nuke my Guix installation
<apteryx>hmm. still couldn't login
<apteryx>the first thing saw was /var/run/slim-vt7.auth does not exist; ratpoison was also listed twice; perhaps something changed w.r.t. .xsession files? I have one that calls ratpoison.
<jackhill>yeah, same here on second computer as well
<apteryx>do you use an .xsession file?
<apteryx>with slim?
<apteryx>finally xorg was complaining that a session was already occupying display 0 or something similar
<nckx>lfam: I don't run unicode locales by default for that reason BTW.
<apteryx>(which would happen if ratpoison was fired twice, I guess?)
<nckx>I explicitly go into ‘Unicode mode’ when something's too annoying without it, so you can still trick me by annoying me with emoji first, then sending me the evil.
<nckx>(Hexchat is always in Unicode mode for obvious reasons 🐠 🐡 🐟 🎣 but not my terminal.)
*apteryx mv .xsession{,.bak} && sudo reboot
<nckx>Y'know, I don't think this is the first time that this has been reported.
<lfam>On the same host?
<nckx>If I had this thing called memory I could answer that.
<nckx>It just rings a bell is all I can say.
<lfam>It's not great
<jackhill> is the only thing I could find about getting different derivations when running the same command
<nckx>I think that was it jackhill.
<nckx>I also hope so ☺
<apteryx>hmm, still failing to login but at least I can debug this over SSH
<apteryx> on[341]: [system] Activating service name='org.freedesktop.login1' requested by ':1.16' (uid=0 pid=324 comm="/gnu/store/ximad0zvg12r4x0x80mvym8hzg0n33jl-shadow") (using servicehelper)
<nckx>uix substitute: error: TLS error in procedure 'write_to_session_record_port': Error in the push function.
<nckx>I vote we get rid of the push function.
<apteryx>Nov 24 21:24:23 localhost dbus-daemon[341]: [system] Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
<lfam>Hm, #50264 is somewhat similar, but also different
<lfam>It's as if the entire graph has diverged, not just this one build
<lfam>No more "guile-builder" scripts on core-updates, huh?
<lfam>They are just called "builder" now?
<apteryx>jackhill: ?
<jackhill>time to change the password (that was only fragment)
<lfam>My issue was caused by GUIX_DOWNLOAD_FALLBACK_TEST
<nckx>lfam: It is minimally reassuring that I can add 4 votes for cmp to jackhill's, and none for q96.
<lfam>It changes fixed-output-derivations
<lfam>I noticed that, despite every derivation having a different name, their output paths were the same
<lfam>I just kept going up the bootstrap chain until I ended up at the xz bootstrap seed derivation
<lfam>That's where the difference lies
<lfam>Or in similar derivations
<lfam>I never realized that derivations with different names could produce the same output path
<apteryx>where does this 'org.freedesktop.login1' dbus service comes from?
<lfam>apteryx: I think elogind
<lfam>The downgrade protector just saved me from pulling from 'core-updates' rather than 'core-updates-frozen'
<jackhill>lfam: it did the same for me earlier today!
<lfam>Safety *is* usability when done right
<ns12>Hi, after I installed git using `guix install git`, `git pull` on the Guix repository fails with "fatal: unable to access '': server certificate verification failed. CAfile: none CRLfile: none". What could be the reason for this?
<apteryx>ns12: info "(guix)Application Setup" -> 2.6.4 X.509 Certificates
<jackhill>ns12: also, did you get any messages about setting environment variables after installing git? GIT_SSL_CAINFO needs to be set. If you do the setup that apteryx described, it will be done automatically, but you'd need to log out in back in, or set it manually until then
<jackhill>sneek: later tell podiki[m] do you have sound with flatpak? I'm getting messages like [190:190:1124/] PcmOpen: default,Connection refused and ALSA lib ../../pulse/pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
<sneek>Got it.
<jackhill>sneek: later tell podiki[m] I only had it in one flatpak app before, but now that I was able to update ☺ it's happening on another app
<sneek>Will do.
<ns12>apteryx: jackhill: Thank you.
<jackhill>ns12: you're welcome
<podiki[m]>jackhill: I have not had sound problems, though haven't updated recently. That message does look familiar, maybe when I hadn't started pulse yet or something?
<sneek>Welcome back podiki[m], you have 2 messages!
<sneek>podiki[m], jackhill says: do you have sound with flatpak? I'm getting messages like [190:190:1124/] PcmOpen: default,Connection refused and ALSA lib ../../pulse/pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
<sneek>podiki[m], jackhill says: I only had it in one flatpak app before, but now that I was able to update ☺ it's happening on another app
<podiki[m]>right now my autostart has a pulseaudio.desktop that does start-pulseaudio-x11
<podiki[m]>updating my profiles and will try updating in flatpak too
<jackhill>podiki[m]: interesting. I tried several times before posting `pkill pulse` and the re-running the flatpak. pulse for me seems to usualy be automatically stared. In this case, I had pavucontrol open, so that was causing it to start. Anyway, I just tried it again, and it started working
<podiki[m]>yeah, I've noticed some slight wonkiness in the past, but I also just run a WM so i figure it is my setup
<podiki[m]>running something that connects to pulse first can ensure it is started, but has been fine for me generally
<jackhill>I'm a sway user, so similar with that. gdm still doesn't work on my primary computer, so I launch it with `dbus-run-session sway` from a vt
<apteryx>jackhill: restarting elogind manually (remotely via SSH) resolved it for me
<apteryx>I guess it starts before the dbus-session service and then somehow the communication fails between them
<jackhill>apteryx: oh, interesting, I'll give that a try the next time I want to reboot. Timing issue makes sense for why it would be different between computers.
<apteryx>and depending on what you have in your services you may or not trigger the race (I have a very slow to start NFS share that seems to delay things by a lot)
<apteryx>yep, it was not related to .xsession or anything else; everything works fine now
<apteryx>I'll try to see what I can do for the elogind service
<podiki[m]>jackhill: same with using `dbus-run-session` in my xinitirc, and then I use dex to run xdg autostart stuff
<podiki[m]>I'm guessing flatpak just complains when it doesn't see pulse (but should start via dbus I would think), but anyway, will keep an eye on it
<apteryx>interesting; I'm pretty sure the rendering changed since the last xorg version I used
<brendyn>why does an i686-linux lib2geom get build even when only using x86_64?
<apteryx>font rendering
<apteryx>I heard wine (for x86_64) requires some i686-linux packages
<apteryx>perhpas that?
<apteryx>well, this may be more to do with fontconfig; anyhow, it's a rather pleasing change
<brendyn>I think you are right about wine
<jackhill>podiki[m]: I see, yeah, something to keep an eye on
<podiki[m]>brendyn: yes, wine on 64 needs wine on i686 and lib2geom currently fails in tests
<brendyn>makes sense. and its been reported
<podiki[m]>guix build wine -s i686-linux --without-tests=plotutils --without-tests=glib-networking --without-tests=lib2geom --without-tests=gtk+@3.24.30 worked earlier for me for the i686 build
<podiki[m]>I think since then glib and plotutils should be fixed, but I haven't tried
<podiki[m]>(but not sure how to build the x86_64 version like that, without defining new packages without tests for i686)
<brendyn>im testing core-updates-frozen. currently im trying to run vm's of my config and example configs but the just boot to a black screen. guix system vm gnu/system/examples/lightweight-desktop.tmpl
<podiki[m]>hopefully the other tests will be fixed in the near future
<apteryx>brendyn: works for me
<apteryx>have you guix pull'd --branch=core-updates-frozen recently?
<brendyn>yes. did you run the vm?
<apoorv569[m]><drakonis> "apoorv569: you're thinking of..." <- hmm?
<awb99_>Is there a plugin for vscode that can beautify my scm code? I am looking for a linter as well. I end up many times with little errors that with some ide support I would catch quickly.
<M6piz7wk[m]>Is there a way to set up guix so that if e.g. i do `wine` and it's not installed it would prompt me to reinvoke the command with `guix shell wine -- wine` ?
<M6piz7wk[m]>... basically like fedora does that, but less stupid
<M6piz7wk[m]>probably though shell manipulating the exit codes 🤔
<apteryx>awb99_: perhaps ask in #guile, but I'd be surprised to learn if Guile had such support on vscode
<awb99_>Thanks apteryx
<awb99_>Is there any command line tool?
<awb99_>That formats or lints the code
<apteryx>there's 'guix lint', and there's also an emacs-based formatter in the tree
<apteryx>etc/indent-code.el in the tree
<apteryx>see info "(guix) Formatting Code" to learn how to use it
<brendyn>how can i theme the grub boot loader so all the text is moved down a bit. i have a bug with my compuer where the top couple 100 rows of pixels are cuttof in the bios/early boot for some reason so i cant read the grub text
<drakonis>apoorv569[m]: pinged incorrectly
<jackhill>apteryx: my problem seems to be something different than elogind. I'm also trying to use GDM under wayland, but I have enough information yet to really report. More investigation is required.
<apteryx>on berlin: X.509 certificate of '' could not be verified
<jgart>what do people think of rewriting /etc/indent-code.el in guile?
<jgart>maybe making it a subcommand of the guix cli
<jgart>guix fmt rust@1.56.1
<jgart>It would be cool to offer newcomers who don't use emacs a non-emacs based tool that's built into guix itself instead of having to install emacs to format guix package code
<abhiseck>When will Gnome40 come to guix? :-)
<jgart>bqv wrote a formatter for himself in guile here that is a subcommand of guix but from a quick look at the code I have a feeling it might be a bit crude compared to indent.el:
<jgart>but that's a good start nonetheless :)
<jgart>abhiseck, get in contact with Raghav Gururajan. He's been leading that effort
<jgart>raghavgururajan, see above
<jackhill>abhiseck: soon (in the next couple of weeks). It's currently on the core-updates-frozen branch which we think we're very close to getting all the problems fixed, and then that work can be made generally available.
<jgart>I personally don't use a Gnome desktop environment but I don't mind helping out when I can to package stuff to help that effort
<jackhill>Core Updates Frozen also hase other great updates in addition to GNOME
<jgart>jackhill, any thoughts on how we can get jpm packaged?
<jackhill>jgart: or maybe something that should be implemented on the guile side as a guild subcommand
<abhiseck>jackhill: Great! nice to hear.
<jgart>jackhill, why would you prefer the formatter to be part of guild cli instead of guix cli?
<jgart>what are the pros?
<jackhill>jgart: re: jpm not really. I've gotten sucked into core-updates-frozen testing :)
<jgart>jackhill, if only packaging jpm for guix were this easy:
<jgart>jackhill, what have you been testing on core-updates-frozen?
<jackhill>jgart: I was just thinking that most of the formatting shouldn't be guix specific is all
<jgart>oh ok
<jgart>makes sense since I think janet has a formatter
<jgart>the formatter should be part of guile
<jgart>instead of guix
<jgart>jackhill, do you use guild in your workflow regularly for anything?
<jackhill>for core updates frozen, first it was just fixing builds of packages I use. Now enough works that I've been able to switch over my profile and reconfigure my system there. We discovered and fixed things (mostly others doing the fixing) that gnome-terminal didn't launch outside of GNOME. Seach for core-updates-frozen in the tracker :)
<jgart>cool, I'll take a look
<apteryx>jgart: I've been toying with the idea of guile-fmt
<jgart>apteryx, cool! that would be awesome to have that tool in our tool box
<jackhill>jgart: not for guix hacking. I guess I could for general guile stuff, but for the small things I've done I've used hall which hides those details from me
<apteryx>it should have the ability to read Emacs' own .dir-locals to parse the config values, perhaps via its elisp support
<jackhill>apteryx: that would indeed be neat
<jgart>I'd prefer to not have to install emacs just to format guix packages
<jgart>but tbh, I usually have emacs installed even though I don't use it often
<brendyn>anyone using packages from nix know how to make fonts work right for non ascii stuff? i have signal-desktop but all the chinese characters are borked
<jackhill>While we're immagining nice things, I'd really like something to pretty-print derivations. emacs-semantic-refactor does an ok job sometimes.
<jgart>brendyn, did you see this wiki yet?
<podiki[m]>brendyn: sorry, don't know, but signal from flatpak works well too (though haven't tried anything with fonts like that)
<brendyn>i was thinking of trying flatpack, but nix seems nicer
<jackhill>emacs-minimal is 205 MiB. Not small, but not huge either
<brendyn>i have noto fonts
<apteryx>jackhill: there's already something for that in emacs-guix
<jackhill>apteryx: oh! I should check that out! I haven't actually used emacs-guix
*jgart more nice things for guix:
<apteryx>I keep it installed mostly for the formatting goodies
<jgart>would be cool to have that integrated into `guix graph`
<jgart>Visualise which gc-roots to delete to free some space in your gnu store
<jgart>jackhill, I usually have emacs-minimal or emacs-no-x installed
<jackhill>yes, that would be handy indeed.
<apteryx>far down my 'worth of fixing' things: better performance for long lines in Emacs; it's a real productivity killer, especially it makes using comint modes like Geiser problematic (chokes on large output)
<apteryx>anoher one: the lack of debuggability in Guile
<apteryx>it won't ever get mainstream if there's no good debugging support
<apteryx>I have yet to see someone using the debugger seriously; the common thing to do is to sprinkle the source with 'pk', which is a bit like adding printf in C. It's understandable, given the Guile debugger rarely allows breaking at some specific line, or quickly looses (understandable) context
<jgart>I have a minimal emacs config that's comfy for whenever I need to open emacs:
<jgart>apteryx, how do you usually debug guile code?
<apteryx>with pk
<jgart>in emacs? with geiser?
<jgart>oh ok
<apteryx>and by evaluating stuff at the REPL
<apteryx>emacs + geiser, or terminal + guix repl when the output brings it down to its knees.
<jgart>what features do you think make it worth using geiser versus just scheme-mode for you?
<apteryx>it's not the same thing; scheme-mode gives you syntax highlighting I think (it's a major mode). geiser is like a well integrated REPL
<apteryx>you can jump from it and back to the source, evaluate things directly in the source, lookup documentation, etc.
<jgart>but scheme-mode offers an integrated repl also, doesn't it?
<jgart>I know scheme-mode doesn't offer documentation
<apteryx>oh, apparently it does; I've never used it!
<apteryx>as with everything core in Emacs, it's probably more spartan than Geiser
<apteryx>well, there are notable exception to that; such as Gnus ^^
<jgart>I think with that merge scheme-mode will be more slightly comfier
<jgart>gnus and org mode I guess since it is part of emacs
<jgart>apteryx, here's another nice guile thing:
<jgart>would be cool to handle guile debugging through the language server protocol
<jgart>then ideally, I can debug guile with it from vis, my daily driving editor
<jackhill>apteryx: yes, the longs lines are a productivity killer. Emacs should be able to handle them, but until then, I've stopped guile from emitting them at the repl:
<apoorv569[m]><drakonis> "apoorv569: pinged incorrectly" <- Oh, ok no problem :D
<civodul>Hello Guix!
<unmatched-paren>Hi Guix
<unmatched-paren>I've been looking into my GNOME issue more and I've found something really weird
<unmatched-paren>It looks like the reconfigure has erased a ton of things from my PATH
<unmatched-paren>I can't run rustc, weechat, etc, even if i reinstall stuff
<unmatched-paren>guix install weechat works, but i can't actually run it
<raghavgururajan>jgart,abhiseck: Actually, apteryx and few others has been leading the effort on gnome-related packages lately. :)
<fcw3>How do I substitute* multiple items on the same line? (substitute* "myfile" (("long\\((.*)\\)" all content) (string-append "int(" content ")"))) only changes the first "long(...)" on each line.
***fcw3 is now known as fcw
<fcw>Is there a way to do global substitution?
<jgart>raghavgururajan, ah ok, wasn't aware but cool! ;)
<mothacehe>hey guix!
<sneek>mothacehe, you have 1 message!
<sneek>mothacehe, jpoiret says: if you're also experiencing the gdm icon issue on c-u-f, i'll reopen the bug on the gnome-shell gitlab as after all my investigations, everything seems to be in place for it to work.
<jpoiret>disregard this, I finally resolved this issue :)
<mothacehe>yeah i saw your patch, good job :)
<jpoiret>for reference, my test process ended up being: start a pure guix shell, and in it, try starting gnome-shell --nested --wayland and reconstructing the needed env vars for it to work
<dportnrj[m]>hello guix.
<dportnrj[m]>$ gpg --keyserver --recv-keys 27D586A4F8900854329FF09F1260E46482E63562
<dportnrj[m]>$ gpg --verify guix-system-vm-image-1.3.0.x86_64-linux.qcow2.sig
<dportnrj[m]>gpg: Note: This key has expired!
<dportnrj[m]>Is it known problem with key expiration?
<zimoun>apteryx: thanks #52078!
<zimoun>now on Berlin «phase `check' succeeded after 2044.2 seconds». Compared to previous 10081.1 seconds (evaluation 1740157). \o/
<florhizome[m]><apteryx> "with pk" <- What does that mean?
<florhizome[m]>I installed guile flycheck but haven't figured it out much
<florhizome[m]>> <> What does that mean?
<florhizome[m]>> I installed guile flycheck but haven't figured it out much
<florhizome[m]>Just having some live syntax checks would do a lot probably
<zimoun>how Julia deals with threading is… unexpected! [ ] The doc is unclear or [ ] I misread it or [ ] they lie. Pick the correct box. ;-)
<florhizome[m]>Also corfu autocompletion is often not that helpful often for me; it also seems to need a repl in the background.
<florhizome[m]>Will take a look at guile lsp jgart :)
<florhizome[m]>Also parinfer vs paredit, any thoughts ?
<jpoiret>guile syntax is whatever you want it to be, so it's kind of hard to validate it
<jgart>florhizome[m], I've mostly dabbled with lispy: see ambrevar's config
<jgart>But tbh I just use modal editing and some other features of vis to manipulate s-exps
<jgart>I'd like to get a guile-language-server working with this:
<jgart>florhizome[m], lispy implements most if not all of paredit and more but has saner keybinds (if you're a vimmer)
<florhizome[m]><apteryx> "anoher one: the lack of debuggab..." <- Oh yes preach... (full message at
<Franciman>Hi, I have a question about rust software packaging. I saw that nix allows, for crates containing a Cargo.lock to not manually specify and package all the dependencies, but rely on the Cargo.lock
<Franciman>to download them and vendor them
<Franciman>does guix do the same?
<Franciman>or I mean, what is the best way to package a rust program and all its dependencies in guix?
<florhizome[m]>jgart: No i don't really have default keybinds yet, that means i'm a bit more comfortable with Emacs but for movement often vim seems nicer.
<florhizome[m]>kinda want to work stuff into Ryu Modal + Hydra with time but haven't found the time
<jgart>Franciman, by packaging the rust program and all its dependencies from what I've seen.
<jgart>I'm starting to work on some rust pkgs now
<Franciman>the idea of leveraging a Cargo.lock seems helpful
<florhizome[m]><jpoiret> "guile syntax is whatever you..." <- but couldn't a program know which definitions apply locally?
<Franciman>so you don't have to repackage the whole carg :P
<jgart>the-way, git-interactive-rebase-tool, aparte, helix (need rust 2021 edition first)
<Franciman>ohh good luck
<jgart>Franciman, have you used `guix import crate ...`?
<jpoiret>florhizome[m]: no unless you run the lisp code (simple answer)
<Franciman>jgart: yes, but it is a bit brittle
<Franciman>and doesn't work with indirect deps
<jpoiret>for example g-exps literally take over the source reader, so it's doubtful any LSP or syntax checker could understand their contents
<jpoiret>also, syntax is literally a lisp procedure that transforms syntax, you could do literally anything in it
<jgart>Franciman, Have you tried `guix import crate ... -r`?
<jpoiret>you could make syntax read files for example
<jpoiret>alright, today is the day i switch to paredit :)
<Franciman>jpoiret: parinfer-rust ?
<jpoiret>i'm pretty biased against rust
<jgart>racket has one
<florhizome[m]><jpoiret> "for example g-exps literally..." <- I think i get helpful autocompletions and can search definitions easily the more abstract stuff would be a lot easier. Maybe that's already somewhere.
<florhizome[m]>Like the describe functionality in emacs for elisp source code.
<florhizome[m]>jgart: i don't really understand in which regard vis is that better then nvim, but probably less featureful? Have you looked if neovim has guile lsp Support, If that's important to you?
<florhizome[m]>Personally i'm just too invested in Emacs rn i guess.
<jpoiret>florhizome[m]: geiser should get you definitions, and maybe autocompletions, but i think it's a pretty hard problem to tackle with lisps in general
<jpoiret>although I've noticed that geiser's jump to definition is pretty lacking with eg macro
<jgart>florhizome[m], the only guile-language-server I know of is the one I linked above
<jgart>So I guess neovim would be using that if it were a thing
<jgart>but I think the guile lsp is pretty experimental at the moment
<florhizome[m]>But i would have to have a Geiser repl for every scheme buffer, right? Ist there a configuration something to automate this?
<florhizome[m]>You don't mean, i can get definitions in the repl, do you^^
<jgart>nvim definitely has more code than vis.
<jgart>florhizome[m], I use emacs also. Here's my suit for those special occasions:
<jpoiret>guile doesn't store definitions locations anywhere. The only thing you can access is in which module they are i think
<jgart>florhizome[m], vis has these nice set operators (union, intersection, difference, complement), and rotation operators for manipulating vim style marks. It also has a little dsl called structural regex from sam:
<jgart>florhizome[m], And, multiple cursors are tightly integrated into the editing experience
<rekado_>dug out another SATA cable; now using a second SSD to use “guix system init” on the aarch64 machines.
<jgart>With the above and the ways they can be composed together I have a lot to work with for editing
<sneek>rekado_, you have 1 message!
<sneek>rekado_, vagrantc says: did you try installing the guix.deb package, or guix from the binary tarball? i've always ended up installing to Debian one partition, mounting another partition, and then guix system init /otherpartition
<jgart>florhizome[m], I also started hacking vis with lisp (fennel):
<rekado_>sneek: later tell vagrantc I haven’t tried the guix.deb; I just use the script at — the key was to use separate partitions for source and target… :)
<sneek>Will do.
<florhizome[m]>jgart ty, although I’m afraid it doesn’t translate into applications asap to me^^
<florhizome[m]>will have a look at those configs though
<florhizome[m]>Probably I should just bookmark aartaka for now
<jgart>florhizome[m], it'll be a time drain for sure. I've spent a lot of time learning vis
<rekado_>so, I got this error now: /gnu/store/y2wfls7sb2mxrgf62wwxy26q2gy189rv-grub-efi-2.06/sbin/grub-install: error: efibootmgr failed to register the boot entry: No such file or directory.
<rekado_>I mounted the root disk at /mnt and the EFI partition at /boot/efi
<rekado_>guix system: error: '/gnu/store/y2wfls7sb2mxrgf62wwxy26q2gy189rv-grub-efi-2.06/sbin/grub-install --boot-directory /mnt/boot --bootloader-id=Guix --efi-directory /boot/efi' exited with status 1
<rekado_>I guess I should mount it at /mnt/boot/efi instead
*rekado_ retries
<florhizome[m]>As I said, I’ll go on with emacs for now anyways.
<florhizome[m]>It does bum me though. And I think to a certain I think degree it’s the elisp part (functionally, asynchronousity)
<florhizome[m]>could we not have an editor in guile without trying to be like emacs ._.
<rekado_>same error. efibootmgr failed to register the boot entry: No such file or directory.
<rekado_>it also prints (twice): EFI variables are not supported on this system.
<jonsger>rekado_: what are you trying to do?
<rekado_>installing Guix System on the honeycomb lx2
<rekado_>maybe I need to change grub-efi-bootloader to u-boot-bootloader…?
<jgart>> could we not have an editor in guile without trying to be like emacs ._.
<jgart>florhizome[m] vis fork replacing lua API with guile API
<jonsger>uff, okay no idea. I only had problems when I updated the EFI firmware on amd64 mainboard. I had to run efibootmgr from a live CD. But thats a completly different topic...
<florhizome[m]><jgart> "florhizome vis fork replacing..." <- If you think that’s it, I’ll try it ;)
<florhizome[m]>but I would want to have gui capabilities at some point and maybe sth like emacs daemon
<florhizome[m]>I guess there is zile but I never heard someone referencing it as a regular usage
<rekado_>switched to u-boot-bootloader and it installed fine. No idea if it will be able to boot.
<rekado_>only one way to find out… :)
<iyzsong>cross fingers :)
<rekado_>Skipping GNU with Linux-Libre-Arm64-Generic 5.14.20 for failure retrieving fdt
<rekado_>nothing at all happens when the microsd card is not in the slot. When it is, it tries to boot Guix System, retrieves the kernel image, but then fails after printing:
<rekado_>Retrieving file: /gnu/store/zcwy8rg66jmfq6yk4hqzs0wam6ylbx2y-linux-libre-arm64-generic-5.14.20/lib/dtbs/fsl-layerscape-lx2160a.dtb
<rekado_>so maybe it needs a special kernel…?
<rekado_>or perhaps a more recent one
<cbaines>rekado_, I think to boot without the microsd card, you probably need to write some firmware to the eMMC
<cbaines>or something else at least (maybe not the eMMC)
<rekado_>okay, I’ll punt on that for now. Will try a more recent kernel.
<rekado_>(once I figure out which of them includes the file)
<rekado_>needs at least 5.15.1
<civodul`>apteryx: i think we should stop big rebuilds like glib-networking or we'll never be done with that branch
<jlicht->If a python package with lots of native magic happening behind the curtain has a segfault while running its tests, does it make sense to give --with-c-toolchain a try, or is this a fools errand? Asking because running the tests takes many hours :-)
<cbaines>rekado_, what issue is leading you to try more recent Linux?
<rekado_>cbaines: when booting the file lib/dtbs/fsl-layerscape-lx2160a.dtb is searched but not found
<rekado_>recent kernels include that file
<cbaines>ah, OK, I think I'm running 5.14.18-gnu
<rekado_>I should note, though, that the official sd-card image includes Ubuntu with Linux 5.4.47-00007-g8edfda9bc
<rekado_>before Linux boots it prints “Retrieving file: /boot/fsl-lx2160a-cex7.dtb”
<rekado_>dtb = device tree blob(?)
<cbaines>I'm not sure I'm checking the right directory, but the kernel I'm using doesn't seem to have that file
<cbaines>I'm using efi rather than uboot though
<cbaines>I think you mentioned you were trying uboot?
<rekado_>I wasn’t able to “guix system init” with the efi bootloader setting
<rekado_>so I switched to u-boot-bootloader; that’s how I got “guix system init” to complete.
<cbaines>I think I got the efi install to work by booting a Guix install image through efi
<cbaines>then doing the install from there
<cbaines>I think since the Ubuntu thing doesn't boot through efi, that causes issues
<rekado_>after booting Ubuntu, I see the following in /boot: “Image” and “fsl-lx2160a-cex7.dtb”.
<rekado_>I have not been able to build an installer for aarch64 and boot that.
<cbaines>I could try building you an installer image if that would help
<cbaines>what problems were you having with the installer?
<cbaines>I've just restarted
<cbaines>haha, the build now says succeeded....
<cbaines>I'd love for it to be possible to build guile in 50 seconds, but I don't think it's actually been built :/
<mothacehe>cbaines: it was probably built elsewhere hence the almost immediate build
<civodul>yeah, is 200, so we're fine
<civodul>rekado_: re -DCMAKE_C_FLAGS=-fcommon in vtk@8, do you know whether that overrides default flags like "-O2 -g"?
<civodul>(i'm asking because it's a pitfall with Autoconf-generated configure scripts)
<civodul>for instance uim-gtk is probably now built without -O2
<civodul>"guix weather glib-networking -s x86_64-linux -s i686-linux -s aarch64-linux -s armhf-linux --substitute-urls= --display-missing" shows that we only have the x86_64 substitute so far :-/
<civodul>(on core-updates-frozen)
<rekado_>civodul: it’s possible. I noticed that with jumpnbump, which required more work.
<mjw>civodul, slightly offtopic, but do you remember how is setup? It redirects to and I am looking to setup something similar for another project.
<jlicht->c-u-f's sanity-check in the python-build-system is such a nifty thing
<rekado_>jlicht-: it’s neat! For python2 I think its heuristics to collect the modules to test are overly sensitive, though.
<jlicht->just another sign python2 needs to be kicked to the curb!
<rekado_>oh, if we wanted to accomplish this with a build phase we could have been more direct :)
<apteryx>I see lots of spurious failures on the CI, like this:
<apteryx>that's automake on aarch64-linux
<vivien>It seems that cuirass web doesn’t respond to HTTP queries on core-updates-frozen, do you have such a problem too?
<vivien>It does not listen to the port
<jlicht->rekado_: sanity-check offers plausible deniability, and a nice burn as well ("python2 dependencies in 2021? Clearly insane!")
<florhizome[m]><jackhill> "apteryx: yes, the longs lines..." <- How would I set this up?
<apteryx>civodul: hi! the ci hasn't caught up yet with glib-networking on i686? uh. It's been 7 hours; something's probably not right.
<apteryx>vivien: I'm getting timeouts often atm from the ci web page
<apteryx>civodul: it's this one
<apteryx>and the previous history shows it was failing on i686, hmm.
<apteryx>Bail out! GLib-Net:ERROR:../glib-networking-2.70.rc/tls/tests/certificate.c:689:test_certificate_not_valid_after: assertion failed (actual_str == EXPECTED_NOT_VALID_AFTER): ("2037-12-31T23:23:23Z" == "2046-07-25T18:13:10Z")
<civodul>apteryx: this test failure is the one i fixed yesterday
<civodul>mjw: we asked the FSF sysadmin, and i think it was bandali who took care of it
<civodul>rekado_: i've pushed a bunch of CFLAGS=-fcommon fixes
<civodul>there are more according to grep, though some of them might be ok (i checked build logs to see whether -O2 was still there)
<rekado_>I always built each package where I added -fcommon
<rekado_>thanks for checking and fixing them!
<mjw>civodul, ok, I hoped we could simply push some .htaccess thing, but asking for human intervention will also work :)
<apteryx>civodul: OK! thanks for fixing it
<apteryx>what are people working on?
<apteryx>zimoun: yay!
<apteryx>florhizome[m]: 'pk' is short for 'peek'; you can call it with (pk 'something) and it will print 'something to stderr and return the value, so you can plug it in the middle of your code without affecting the surrounding
<apteryx>has anyone else noticed the new font rendering on core-updates-frozen? neat, no?
<ekaitz>hi I have a very specific question on library management
<ekaitz>I made a program using and I'm able to compile it with gcc whatever.c -lrec
<apteryx>mothacehe: hi! I'm repeatedly getting gateway timeouts on; is something amiss?
<ekaitz>but if I try to do the same with luajit using ffi.load("rec") it doesn't find the lib
<ekaitz>any idea=
<vivien>apteryx, I have too on my own ci :(
<mothacehe>hey apteryx, no that's something I need to fix. In short, the remote-server fetching queue is more consequent these days due to the GC issues and the SQL query that's behing the /workers page is struggling because there are many builds assigned to each worker.
<mothacehe>i need to rewrite this query
<mothacehe>that said looks like there's another issue on berlin, the GC is over but the remote-server is not picking up the fetch queue
<apteryx>yep, the successful builds count of the last evaluations seems stuck
<apteryx>how do you typically resets cuirass into a working state when this happens?
<mothacehe>these are new issues revealed by the struggling GC, but to fully restart Cuirass, I usually run: sudo herd restart cuirass && sudo -E bash -x ./home/mathieu/ "herd restart cuirass-remote-worker"
<mothacehe>the latest command restarts the remote-worker on all the workers
<apteryx>mothacehe: OK, thanks for the tip; is it something safe to do in the middle of an evaluation? will it pick up from where it was?
<mothacehe>the evaluations are stopped and won't be restarted automatically
<apteryx>OK; so 'restarting evaluation' on web ui following such manual restart of cuirass is needed
<mothacehe>yes exactly, or waiting for a new commit to show up :)
<apteryx>OK! Do you want me to try to reset it, or did you want to troubleshoot it?
<mothacehe>I'am afraid I won't be able to troubleshoot it atm so it would be fine if you could restart it :)
<apteryx>do past evaluations that had pending builds need to be restarted as well?
<apteryx>or just the last one
<mothacehe>great thanks. The remote-server fetch queue is wiped and all the builds that were flagged as "submitted or started" are put back to "scheduled" so that they can be restarted.
<apteryx>sounds good
<apteryx>thanks for the help!
<mothacehe>thanks for taking care of that ;)
<apteryx>hmm, I'm not sure if the bulids have been picked back up, looking at the number of passed builds don't change (I haven't restarted the evaluation yet)
<apteryx>should I try "Retry the evaluation" or even "Restart all builds" ?
<mothacehe>restarting the builds happens at cuirass start and takes a while
<mothacehe>if you choose "Retry the evaluation" it will force a new evaluation
<mothacehe>if you choose "Restart all builds" it will restart all the evaluations builds but it should happen automatically
<mothacehe>you can monitor it in the /var/log/cuirass.log file
<apteryx>OK, I'll try to be patient :-)
<apteryx>seems to be busy clearing the build queue: 2021-11-25T16:34:54 Database worker unresponsive for 5 seconds (db-clear-build-queue).
<mothacehe>yep that's the query that does "update builds set status = scheduled where status = started" basically
<mothacehe>should be faster though, yet another query to profile :p
<gyara>Hello every one, Is there any manual to write fontconfig in guix?
<apteryx>gyara: it should be the same as on any distribution; so you can refer to the documentation of fontconfig itself
<apteryx>one gotcha though: until core-updates-frozen, only the Guix system or user profiles are looked for fonts by fontconfig
<gyara>I have a font config file, but can not make guix home use it
<gyara>simple-service 'font
<gyara> home-files-service-type
<gyara> (list `("config/fontconfig/fonts.conf"
<gyara> ,(plain-file "config/fonts.conf"
<gyara> "font config"))))))
<gyara>I have things like this, but not work
***user____ is now known as unmatched-paren
<unmatched-paren>Hi Guix
<florhizome[m]><apteryx> "florhizome: 'pk' is short for '..." <- Oh, cool.
<florhizome[m]>A bit unrelated:
<florhizome[m]>I would love something to make a build pause after a certain build phase.
<apteryx>mothacehe: is a match-error exception about a job specification something to fear?
<unmatched-paren>Turns out the reconfigure that caused the GNOME issue caused a whole lot of other problems
<apteryx>florhizome[m]: you can, but not from the CLI (in the code, put (error 'stop) in the phase where you want the build stop, then build with 'guix build --keep-failed'
<unmatched-paren>it may be related to my switching to zsh from fish, but i don't know why
<florhizome[m]><apteryx> "one gotcha though: until core-..." <- I think guix Home already uses fontconfig, even in master
<mothacehe>apteryx: yes. I guess it means here that Cuirass is trying to restart builds which specification doesn't exist
<mothacehe>but i'm not sure why
<apteryx>would it throw it in a crash restart loop?
<florhizome[m]>apteryx: Yes, that's what i wanted :)
<florhizome[m]>There are actual a lot of useful Things Missing in the man i reckon
<florhizome[m]>I just found "wrap-program"
<apteryx>not everything is documented (and I think it would be too heavy to attempt to do so); use the source, luke!
<florhizome[m]>what would be the usacase to use Python-wrapper instead of Python?
<apteryx>have a 'python' binary instead of python3 (or python2)
<apteryx>it's just a wrapper script
<mothacehe>apteryx: thanks for the bug report!
<apteryx>ah :-)
<florhizome[m]><apteryx> "not everything is documented (..." <- I would rather have the man document the programming Interface with more detail then documenting each Special service in detail, If you want to Go down there. (Would be more of a wiki/community Thing IMO. In general, using guix as operating system would deserve that room). As long as there are 2 pages for dovecot-service-type at least, i find your argument lacking to not have half a page for
<florhizome[m]>wrap-program or stop
<unmatched-paren>I think i've nearly fixed GNOME, but
<apteryx>florhizome[m]: perhaps the stop trick could go in the Guix Cookbook
<jpoiret>unmatched-paren: on guix, you should not use a non-posix compliant shell
<jpoiret>at least not as a login shell
<jpoiret>many things expect your login shell to be able to source /etc/profile among others
<unmatched-paren>aww :(
<unmatched-paren>i like fish
<jpoiret>you can still use fish for interactive things
<unmatched-paren>i was trying zsh to see if it worked with vis btw
<unmatched-paren>it didn't :)
<apteryx>florhizome[m]: I meant in general, about deeper things in the API, but if you can come up with a well written patch that fits nicely in the current manual, why not :-)
<unmatched-paren>right anyway a couple of things have gotten messed up because old guix
<unmatched-paren>for some reason i was stuck with an old guix for a while
<florhizome[m]><apteryx> "have a 'python' binary instead..." <- I have a program that doesn't seem to find python at runtime, that's why i asked.
<florhizome[m]>So If the source file calls "python" but wants python 3 this wouldn't be a Bad idea?
<unmatched-paren>and now i can't pull
<unmatched-paren>it tries to 'migrate user profiles' but fails because they are already in the (i presume) new location
<unmatched-paren>where's the old location so i can kill it?
<unmatched-paren>jpoiret: how would i use fish as
<unmatched-paren>an interactive shell but not a login shell?
<jpoiret>you could lauch `terminal -c fish` where terminal your terminal program
<florhizome[m]><apteryx> "florhizome: perhaps the stop..." <- Like i said earlier today, i *just* (Wink) want an easy Interface to find definitions.
<florhizome[m]>Are these definitions listed somewhere in the reference index maybe at least ... (Looks)
<florhizome[m]>Seems something geiser should do, though, probably from the repl (yay)
<apteryx>mothacehe: oh: branch: wip-stackage-18.14
<apteryx>perhaps this doesn't exist anymare in the repo
<unmatched-paren>jpoiret: (hopefully) one last thing before i stop annoying you with questions: how would i fix the following:
<unmatched-paren>Migrating profile generations to /var/guix/profiles/per-user/paren..
<unmatched-paren>guix pull: Error: symlink: File exists: /var/guix/profiles/per-user/paren
<apteryx>indeed wip-stackage-18.14 is nowhere to be shown here
<apteryx>I've deleted the corresponding job spce
<unmatched-paren>i'm presuming it's because i was using an old system-wide guix while everything went up in flames
<unmatched-paren>i don't know why
<unmatched-paren>Anyway, my switching to zsh from fish was what caused all the problems
<unmatched-paren>(i think)
<florhizome[m]><apteryx> "florhizome: I meant in general..." <- You mean these are just utility functions, or these are not defined to be used by beginners? I think wrap-program f.e. is not really a low level utility thing and stopping a build in a controlled way sould be quite neat for starters.
<florhizome[m]>" deep" ;)
<mothacehe>apteryx: select id from builds where evaluation in (select id from evaluations where specification not in (select name from specifications)); gives the list of builds which have unexisting specifications
<mothacehe>maybe i should remove them
<apteryx>that'd be a good option, else mark them as 'orphaned' or something in the UI, and ignore them
<apteryx>because a branch may be deleted to be recreated
<apteryx>and we don't want the associated job spec to disappear
<unmatched-paren>should my ~/.guix-profile be a symlink to /var/guix/profiles/per-user/paren?
<crodges>hello all. are there any packaged git forges in guix? I was looking with guix package -s git, and so far I found only gitile that I'm not familiar with (I had in mind gogs/gitea)
<unmatched-paren>because it isn't
<mothacehe>yeah, i'll propose a patch asap that marks specifications as "archived" instead of removing them causing those discrepancies
<mothacehe>removing c-u-f-b-c created similar troubles a few days ago
<apteryx>OK, sounds good
<apteryx>uh, now it happens for branch: "version-1.3.0"
<unmatched-paren>hmm wait it is
<unmatched-paren>i have no idea what is going on here
<unmatched-paren>erm what
<unmatched-paren>readlink .config/guix/current -> /var/guix/profiles/per-user/root/current-guix
<unmatched-paren>my .config/guix/current points to... root's guix?
<unmatched-paren>is it safe to rm the symlink and point it to the correct guix?
<unmatched-paren>i did it and it's fixed \o/
<roptat>unmatched-paren, you probably ran "sudo guix pull" or something
<roptat>that got guix confused
<roptat>running as root, but with $HOME pointing to your user's $HOME would have this effect I think
<unmatched-paren>i don't remember doing that, but it would make sense....
<roptat>I managed to build up to all jmh dependencies and now I'm just dealing with a bunch of version mismatch between what maven expects and what I give it...
<roptat>oh, fixed the issues with the enforcer plugin. now the compiler-plugin is failing to inject one of its dependencies...
<unmatched-paren>and now i can get back to making gnome app packages (finally) :D
<rekado_>civodul: I’m building all this stuff for aarch64 here in an attempt to install Guix System on this machine… I wonder if there’s a good way for me to … make these outputs available on
<rekado_>do I just need to do mutual key authorization and then use ’guix copy’?
<apteryx>rekado_: I guess that would do it, if you don't mind to be personally part of the chain of trust :-). You'd need to reconfigure berlin with your key.
<apteryx>Cuirass seems to be healthy again; it's catching up with master
<apteryx>so it was this wip-stackage branch deletion that threw it off, it seems
<apteryx>mothacehe is reportedly working on a fix so that this gets handled better in the future
<rekado_>apteryx: when the machine is added as a build node would I not have to authorize its signing key on
<apteryx>you would need to do so
<apteryx>at least if it's to be usable for 'guix offload'. I'm not so sure about how it works as a Cuirass worker, but since the remote machines notify the head node for completed builds to be fetched, I guess that'd apply to
<apteryx>in the end all the build artifacts end up on berlin, so their signatures need to be authorized, I believe.
<zimoun>argh, I am puzzled by Julia: «command "julia" "--depwarn=yes" "--procs=1"» then «LoadError: LoadError: On worker 2:» What?! How it possinle to specify one worker and get in my back 2? I definitively miss a point
<rekado_>so, the newly built 5.15.5 kernel has the file /gnu/store/scy3gl2wm99jd9b9q5b8ilwcr0fpy5c6-linux-libre-arm64-honeycomb-5.15.5/lib/dtbs/freescale/fsl-lx2160a-honeycomb.dtb, but when booting I see it looks for /gnu/store/scy3gl2wm99jd9b9q5b8ilwcr0fpy5c6-linux-libre-arm64-honeycomb-5.15.5/lib/dtbs/fsl-layerscape-lx2160a.dtb
<rekado_>can someone explain to me where this expectation comes from?
<rekado_>is this u-boot’s doing?
<rekado_>looks like this might come from extlinux-configuration-file, which sets FDTDIR to $kernel/lib/dtbs
<rekado_>…but irrespective of the directory, there’s a mismatch between the file name in u-boot and the kernel
<rekado_>copied the file to /boot/extlinux with the expected name and changed the extlinux config
<rekado_>and it booted … into bournish because the disk name is not /dev/sdb but /dev/sda
<rekado_>ugly: bournish prompt looks like this: bournish@(#{ g54}#)>
<apteryx>progress, at least :-)
<wigust>hi guix
<apteryx>guix install emacs-elfeed -> In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): "/gnu/store/a8dljzmb4w921bz3pxvfp0d2v7yzw1bb-gdk-pixbuf-2.42.4"
<apteryx>on core-updates-frozen; can someone else confirm?
<vdv>someone packaged moonlight-qt? or is it nonfree because of nvidia gamestreaming compatibility?
<jonsger>does someone around here uses VMs on a Guix without GUI? so e.g. on a server, not inside gnome-boxes or stuff like that...
<rekado_>jonsger: not sure what you mean.
<rekado_>I use the childhurd, which is a VM run with qemu on Guix System.
<rekado_>I also generate VMs with “guix system” and host them with ovirt
<apteryx>uh, gtk still fails on i686 due to a test needing SVG
***potatoalienof13 is now known as supergoll
<roptat>oh no regression, the enforcer-plugin doesn't work anymore... what am I doing T.T
<vdv>and someone updated sway to 1.6+?
<vdv>or hase a custom definition for a more recent version?
<jonsger>rekado_: do you have examples on this ovirt thing?
<rekado_>ovirt is not running on top of Guix System. It’s on top of RHEL.
<rekado_>we’re hosting like that.
<roptat>uh nevermind now it's working
<jonsger>ah okay. My setup is simpler. I have a Guix physical server and a VM, which I run currently inside screen with something like `qemu-system-x86_64 -curses ...` but as soon as I remove the `-curses` things are getting complicated...
***supergoll is now known as potatoalienof13
<apteryx>is it just me, or './pre-inst-env guix install anything' is broken on core-updates-frozen?
<apteryx>it complains about: (expecting struct): "/gnu/store/a8dljzmb4w921bz3pxvfp0d2v7yzw1bb-gdk-pixbuf-2.42.4"
<rekado_>apteryx: same here
<rekado_>I used ./pre-inst-env guix install nudoku to test
<rekado_>commit 20e3dd052d7e4f59273e3646d3533d43c87c30b0?
<rekado_>that must be it. I reverted that commit locally and everything is fine.
<apteryx>oops; thanks for isolating it
<unmatched-paren>i'm trying to build guix to add a package but one of the tests failed (channels.scm)
<unmatched-paren>This one:
<florhizome[m]><vdv> "or hase a custom definition..." <- I have sway-borders (:
<attila_lendvai>so, if i have two binary packages in another repo/channel (that download binary releases of geth and bee, ethereum stuff). i'm planning to write a service for bee, that will obviously need a binary to run. shall i add this service to guix, or that other repo? the rationale for guix is that later on someone may come up with a source based package (i'm actually working on that), and the projects themselves are FSDG compatible..
<apteryx>rekado_: replacing file-append by string-append in that commit fixes it
<attila_lendvai>put another way: would guix accept a service that cannot be run without providing a binary for it somehow else than guix proper, at least for the time being?
<apteryx>attila_lendvai: I'd keep them together outside of guix for now
<apteryx>that should cause less confusion
<rekado_>attila_lendvai: I agree with apteryx here.
<attila_lendvai>i find it much more headache to locally test packages that are in a third-party channel/repo. i'll have to work that out then...
<attila_lendvai>all i can do now is guix build --file=path/to/some.scm and reference the package variable in question at the end of the file
<rekado_>attila_lendvai: you can use GUIX_PACKAGE_PATH
<rekado_>set that variable to the root directory of your extra modules
<rekado_>and then you can use all the Guix commands as usual
<attila_lendvai>rekado_, yay, it works, thank you! i hope it'll help with working on services just as well.
<apteryx>gtk+ unlocked in i686-linux!
<lilyp>victory fanfare!
<rose>I'm having a problem with Guix, my laptop doesn't suspend when I close the lid
<rose>loginctl suspend works fine
<apteryx>how often are the cuirass RSS feeds refreshed?
<apteryx>rose: is it plugged in the wall?
<rose>I tried plugged in and unplugged, neither suspends
<apteryx>strange; mine suspends when unplugged
<apteryx>(otherwise it doesn't)
<rose>It does lock the screen when I close the lid
<rose>How could I start to debug this? Would lid switch events be logged in dmesg?
***Franciman is now known as {Franciman}
<apteryx>it's worth inspecting the file yes
<apteryx>more like /var/log/messages
<jpoiret>rose: is your charger plugged in?
<jpoiret>also, you may need to pass (lid-switch-ignore-inhibited? #f) to elogind-service-type, see
<civodul>zimoun: the julia build i started this morning was interrupted because i got disconnected at some point (it was offloaded)
<roptat>so, not a regression actually, but it's failing weirdly in the test phase, and ran the tests in the build phase
<roptat>no idea why it suddenly wants maven-artifact-3.1.1 when it was fine during the build phase
<roptat>I might have found it, the enforcer parent pom references it, let's fix that
<vdv>whats sway-borders for? :D
<vdv>not enough borders within sway?
<karrq>hello, is it possible to search the list of guix packages in the web? I mean in this page or similar
<apteryx>anyone using elfeed in emacs?
<karrq>roptat: thanks! gonna submit a ddg bang :)
<apteryx>why do we need xkbcomp-intermediate ?
<drakonis>someone check the mailing list real quick
<drakonis>looks like an email by jgart had some issues
<jgart>that was my fault
<jgart>sent it without a subject and messaged everyone directly instead of bcc
<drakonis>was going to ask anyone with moderation privileges to hide it
<jgart>anyways, if you're free Saturday come to the Guix Packaging Meetup
<drakonis>oh i will
<drakonis>but its showing email accounts
<jgart>yup is someone could remove it that will be cool, just let me know here so I can repost the room link
<roptat>succes! \o/ jmh built fine
<drakonis>1.4.0 soon, yeah?
<roptat>drakonis, yeah, after the merge of core-updates-frozen
<drakonis>but when's that
<drakonis>that's the real question
<roptat>you can help by switching to core-updates-frozen and update your profile/system
<roptat>report any failures, or that it worked for you
<drakonis>its not quite the right time for me to be doing that
<roptat>up to you :)
<drakonis>i'm not ready for any suprises
<drakonis>i do have a debian install with guix that i could switch to cuf
<roptat>you can always rollback though
<drakonis>last time i tried there was a lot of things that still needed compiling
<drakonis>so i didnt immediately jump into it
<nckx>jgart: Could you send a request to <help-debbugs at gnu org> for removal/CENSORSHIP of the PII? They don't really like doing it ( and I don't want to be the one to ask every time and become associated with trouble ☺
<nckx>Their point in that bug is valid though: once sent, public e-mail is, well, public, removing it from *our* archives is just pro forma damage control.
*nckx will NOT good morning guix because none of you saw me here, capice… o/
<jgart>sorry, what is PII?
<jgart>but sure I can do that :)
*jgart TIL Personal Identifiable Information (PII)
<jgart>nckx, sent!
<jgart>wow, I never though upgrading python-jedi would be such a headache ha
<roptat>jgart, regarding your email, somehow half your headers got mixed into the body, that's why there was no subject
<nckx>Shart. I'm an idiot and pasted the wrong address. This is what happens when I squeeze things in. I meant to paste <sysadmin at fsf org>, jgart. I apologise for the noise, and will diminish back into my work.
<nckx>But thanks jgart.
<jgart>roptat, ha yes I see the subject now in the original email
<jgart>But I had *two* subject fields in the header so it took the first one (the empy one)
<roptat>or did mailman simply add a subject header because there were none?
<jgart>nckx, ha no worries I'll forward it
<jgart>roptat, there was a subject header in my original email.
<jgart>The problem was that there were *two*
<jgart>and the first one (highest to the top of the file) was empty
<jgart>And I forgot to add the Bcc: header
<jgart>for the emails that followed
<Haider>(Noobie Question) How do I make my own xsession as /usr/share/xsession doesnt exist in guix
<jgart>so, It sent them all under the *To:* header
<jgart>nckx, sent!
<roptat>what's xsession?
<Haider>*Desktop environment*.desktop files
<Haider>for example if you use xfce, xfce.desktop
<roptat>I think it would work if you install it in your user's profile, or the system profile
<roptat>(well, whatever package provides the .desktop file)
<Haider>ok ill try doing stuff
<roptat>although I can't guarantee, I don't think I use one
<roptat>nevermind, I use openbox which provides 3, and I see them from gdm. I simply installed openbox in the system profile
<Haider>ok ill probably just try doing that
<apteryx>civodul: would you have an idea about how to reproduce #52051? I think I need some service to cause a lot of delays, such as an NFS server (I have that on my main desktop, and it takes a long time to scan the directories it serves at boot)
<cjtenny>Hi guix, I'm trying to package Jason Francis' changes for Guile to ac-d-bus, and am trying to debug my build. I have a failing build step with an unhelpful log message, and according to I should be able to inspect a kept build directory if I error, but I don't see any such message with my current guile. Is there another way to inspect
<cjtenny>failed build results?
<cjtenny>s/current guile/current guix/
<apteryx>15% to go for the coverage core-updates-frozen to catch up with that of master
<apteryx>lilyp: I remember you said inkscape could be used to generate svg instead of librsvg; actually nope. inkscape requires svg support from librsvg to do so
<apteryx>you can try building arc-icon-theme on i686-linux to convince yourself of that
<civodul>apteryx: re elogind, not sure what's going on; i've just replied with potential leads
<civodul>if it's timing sensitive, it may be hard to reproduce
<apteryx>it seems to be as the exact same config (with nfs server not really working) in QEMU doesn't trigger it
<apteryx>I wouldn't expect if elogind, coming from systemd, isn't designed to gracefully handle an not yet initialized dbus-session, since their socket activation would ensure it never happens
<apteryx>(thinking out loud)
<civodul>oh fun, i had just come up with a different patch for slang (but yours is better)
<apteryx>ah :-)
<civodul>although it triggers rebuilds on every arch, which isn't great :-)
<apteryx>the package didn't have much dependents... or guix refresh -l lied to me again
<civodul>ah no you're right, that's just 45 packages, so we're good :-)
<apteryx>adwaita-icon-theme cannot be built on non-x86_64 archs
<civodul>apteryx: i think the gdk-pixbuf hook fix is incorrect: 'gdk-pixbuf' can be either a store path or a package, according to the manifest-lookup-package docstring
<civodul>so i think both cases need to be handled
<apteryx>oh, interesting. perhaps that's why I hadn't caught that bug earlier
<civodul>right, it has to be tested with both "guix install" and something like "guix package -m"
<apteryx>so I probably broke 'guix package -m' with the "fix"
<apteryx>civodul: somethnig like this?
<civodul>apteryx: yes i think so
<civodul>though i wonder if the string? case actually works (does the derivation build?)
<civodul>having checked gexp.scm, i think it does
<civodul>there's an ugly special case for when you do #$str and str is a store file name
<civodul>anyway, it comes in handy :-)
<apteryx>the 'guix install' still works but 'guix package -m' breaks, it seems
<apteryx>with an instructive error message: Throw to key `quit' with args `(1)' :-D
<apteryx>ah sorry, it's something else
<apteryx>a package was missing due to using a channel
<apteryx>actually it was working before the fix too.
<apteryx>hmm. I guess it may be helpful in some situations that I can't trigger
*apteryx goes afk for a bite
<cjtenny>for future references, the problem is that keeping failed build dirs has been moved to the -K option, and the hacking guide linked from didn't mention it. easy fix!
<cjtenny>re: my earlier message, sorry for the noise
<rekado_>so, I booted into Guix System on this honeycomb machine
<rekado_>but the wireguard service doesn’t start
<rekado_>here’s the output I get:
<rekado_>does “unknown device type” mean that I built a kernel without wireguard support…?
<rekado_>I have no module named “wireguard” in my kernel’s module directory
<asto>After I successfully installed guix in my virtual box I can reach to gnome SDDM but after I log in a black screen welcomes me with gnome pointer.How can I fix that ?
<rekado_>yup, forgot to add the default config file when defining my kernel
<asto>any ideqs
<M6piz7wk[m]>asto: ideas to what? Ice cream? strawberries are the best~
<M6piz7wk[m]>oh right backlog..
<M6piz7wk[m]><asto> "After I successfully installed..." <- gnome pointer?
<M6piz7wk[m]>> I can reach to gnome SDDM
<M6piz7wk[m]>ehh SDDM is not part of GNOME afaik