IRC channel logs
2024-05-13.log
back to list of logs
<Tadhgmister>whats the standard regarding gexps in service configuration? <Tadhgmister>I'm writing a home service for dunst the notification daemon and I'd like to allow the values to use gexps particularly for the script field but I'm realizing my technique doesn't play well with the `serialize-configuration` stuff <freakingpenguin>Anyone here use Guix as a server with a UPS backup? How are you handling automated shutdown? <Tadhgmister>freakingpenguin I appreciate the reference but my primary use case is to run scripts on several classes of notifications using guile functions written into the home config, so your version that just changes the offset and font and has a field to stick more text into the config file is not nearly as useful for me <Tadhgmister>hahahaha, serialize-configuration is itself a gexp. so yes my serializers can absolutely return gexps and it will work correctly <apteryx>what does the 'systems' field of 'guix show something' represent? it seems random <Tadhgmister>isn't that the list of supported systems? like x86_64linux <Tadhgmister>I believe it is a subset of the list displayed by `guix build --list-systems` <Guest32>I have a package definition that uses `(build-system guile-build-system)`. The package it refers to is just a single guile scheme file that defines a module. Does guile-build-system handle this with no further code? <Guest32>I ask because this is my first time packaging & using my own channel. I'm not sure about a lot of things at the moment, sorry for my ignorance. <gnucode>Guest32: no idea, but I say give it a try! <Guest32>gnucode: Oh I forgot to mention I have tried it and I'm getting a build error in ice-9/boot-9. I am trying to rule out reasons why that might be <Guest32>the error is just a string-append that expected a string but got #f, however I'm not sure how that connects to my code/package definitions <efraim>we might want to bump gccgo to gcc-14 since gcc-13 only provides go-1.18 and doesn't have some of the updates to the core golang libraries that ship and I think is already EOL <cbaines>the bordeaux build farm and QA are finally catching up :) <civodul>cbaines: hi! just replied re nss, please push! :-) <efraim>cbaines: I've been using it as part of checking which packages don't build on aarch64 and trying to fix them <civodul>i noticed that this nss problem has another effect: it prevents evaluation of the ‘guix’ jobset to complete, because nss@3.99 fails to build on powerpc64le <civodul>which in turn means that evaluation slots are used for a long time before it eventually times out <civodul>which in turn means that evaluations take much more time than needed, accumulate, etc. <civodul>the po4a-minimal trick will save us :-) <cbaines>it's building on x86_64-linux and hopefully it'll succeed <cbaines>I'm just running guix-build-coordinator build update-priority --tag=issue=70693 --new-priority=1000 on bayfront to try and speed up the nss builds <efraim>if anyone is curious, the debian package I built for guix for powerpc works, I'm using it on my second ppc offload machine. still need to fix the test failure on guile-git before I can ask vagrant to add powerpc as a supported architecture for guix in debian <civodul>cbaines: yep, i need to take a closer look but those patches look like a step in the right direction <KE0VVT>efraim: Ready. :D (It's been a week.) <drakonis>so, a build daemon rewrite in guile i hear <nigko>Hello Guix! How can I preserve my local time-zone inside "guix shell -C" container? This is beacause 'make' uses timestamps of files which I'd like to edit from outside the container. <Tadhgmister>you probably need to propogate `/etc/localtime` to the container <Tadhgmister>I'm not too familiar with `-C` workarounds, this is based on me briefly looking at `guix shell --help` <nigko>Tadhgmister: Thanks! It seems to work. <apteryx>hm, starting nautilus: "Tracker 2 migration: Failed to parse key file data: Le fichier de clés contient la ligne « usage: tracker3 [--version] [--help] » qui n’est ni une paire de valeurs de clé, ni un groupe, ni un commentaire" <ngz>Hmmm, it looks like I have to delete and re-create the "tex-team" branch (it unexpectedly broke XeTeX). Since it already appears on the list of pending branches to merge, is it an issue for QA? I mean, will QA catch the new branch? (I assume so). <cbaines>ngz, yeah, that's fine (and in some ways encouraged) <ngz>cbaines: Great. Thanks. <cbaines>and that is moving much more in the direction of having stateless branches which you'd ideally always delete then re-create <civodul>the load on bayfront is very high again, which slows down the web sites <civodul>we should migrate the builds or the web sites <cbaines>a log file is being compressed, which probably doesn't help <cbaines>that's not going to happen often though <cbaines>I'm also trying to reconfigure the machine, but it's going very slowly <wakyct>it seems that my nm-applet in xfce has crashed, it looks like a common issue but I'm not sure where in Guix land to look to fix it. It's normally run by the desktop session manager I guess? <civodul>cbaines: yeah, everything is terribly slow <wakyct>is the desktop session distinct from shepherd? <civodul>the problem is that it gives a poor image that guix.gnu.org and hpc.guix.info are this slow <civodul>wakyct: i think nm-applet is started by Xfce itself <civodul>it’s definitely not a Shepherd service anyway <wakyct>ouch, .nm-applet-real[1040]: segfault at 30 ip 00007f5df69fb1a0 sp 00007fff0853fed0 error 6 in libglib-2.0.so.0.7800.0[7f5df69f3000+94000] likely on CPU 2 (core 1, socket 0) <cbaines>there was a vim issue on bayfront, but I've killed it and things should speed up <mrvdb>running into "guix pull: error: all build users are currently in use; consider creating additional users and adding them to the `guixbuild' group" Seems odd, I can add the users obviously (there are 10 now), but perhaps something else is going on. Never had this msg before. <Tadhgmister>you have 10 builders busy? are you building lots of stuff in the background? <mrvdb>i'm just issuing guix pull really <Tadhgmister>you could try `sudo herd restart guix-daemon` I don't actually know if that closes build workers but might be worth a try <Tadhgmister>but yeah I haven't heard of that being a typical problem <mrvdb>i suspect it is masking another error, unless those builds spawn real fast and die real fast and I missed them (running guix on top of arch kernel btw, on powerpc64le) <Tadhgmister>ahh, then I wonder if the guix daemon failed to spawn the build daemon or something <mrvdb>repeated runs take it further everytime, starts compiling now (4th run) <apteryx>so, I want to deprecated linux-libre-with-bpf with linux-libre (which has absorbed the configs); which proc should I use? <apteryx>is it (define-deprecated/public-alias linux-libre-with-bpf linux-libre) ? <apteryx>ACTION can never remember which deprecation procedure to use <civodul>apteryx: ‘define-deprecated…’ is for variables, so it’s good to do that <civodul>but for packages, we also want UI hints <podiki>i sent an email last night to guix-devel, but i'll ask here too: do we have any stats/demographics on our users? maybe from substitute downloads? <civodul>and for that, that ‘deprecated-package’ <civodul>in some cases we do both, as in tex.scm <civodul>ACTION has “draft deprecation policy” on his TODO list :-) <thanosapollo>podiki I have no idea but a survey might be cool if someone wants to do that <podiki>yeah, I think we need that, would be helpful data <podiki>(this is for that foss sustainability fund application, I guess they want an idea of how big/diverse a project is) <apteryx>civodul: thanks! I'll be happy to review that eventual draft :-) <apteryx>this should cover both cases (the variable too), no? (define-public linux-libre-with-bpf (deprecated-package "linux-libre-with-bpf" linux-libre)) <apteryx>since the variable is exported with define-public <podiki>civodul: who might I ask about the logs (or just basic numbers from them)? i don't believe i have access to berlin machines <civodul>podiki: you can check the admins listed in hydra/berlin.scm in maintenance.git :-) <civodul>i’m one of them, i can take a look if nobody beats me at it <cbaines>why when running guix system build does "Updating channel 'guix'" appear? <apteryx>is someone using old CD or DVD drives with Guix System? <lilyp>probably not old enough for the question you're about to ask <apteryx>I have two DVD drives myself on my box, but I think they are disconnected internally... I'd need to reboot to answer my own question, which is which group should a user be added to to have access to them <ieure>apteryx, Not sure if Guix is different, but `cdrom' is the correct group name in Debian-derived Linuxen. <ieure>I think those come from udev, so good chance it's the same for Guix. <apteryx>I've managed to cut the kernel build time by 30% <apteryx>by honoring '-jN' in tE install phase <apteryx>at least on a monstrously parallel system <jonsger>apteryx: I have a DVD drive on my Guix System workstation. What do you mean with "old"? <apteryx>did you have to add yourself to the 'cdrom' group[ <jonsger>This is was my user have: (supplementary-groups '("wheel" "netdev" "audio" "video" "kvm" "libvirt")) It does work. I can play movies from DVD via VLC and opening the "drive" via `eject` in terminal... <cmiller>I use my DVD drive as well and never needed to do something for it to actually use it. Though it is no Blu-ray or something new, just plain old DVD drive. <apteryx>jonsger: can you see it from nautilus and mount it without root?