IRC channel logs
2024-12-01.log
back to list of logs
<PuercoPop>lilyp: makes sense, thank you. I'll have to use a system service then <iska>I'm trying to build GraalVM 19 with openJDK 18 <iska>But I get this error in mx: <iska>Path in JAVA_HOME is not pointing to a JDK (Java launcher does not exist: [path...] <iska>okay, the java launcher is because I set the envvar wrong. It still needs javac, though <hako>iska: openjdk has a jdk output (as shown in the output of 'guix show openjdk'), so "openjdk:jdk" <unmush>how does one properly modify a package that's so old that its configure scripts say stuff like "Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown-linux' not recognized"? <lilyp>Delete configure and use autoconf/possibly automake for bootstrap? <rekado>I hope that's just because the data service is moving to a new node. <bjoli>Friends, I now have a working install of guix on top of aeon desktop (like fedora silverblue, but opensuse). Everything is a bliss, except that gui applications don't show up in gnome automatically. Is there a way for me to do that without manually adding them? <Rutherther>bjoli: so you mean in the application menu? they should appear if you put your guix profile's share folder to XDG_DATA_DIRS, in something like .profile (you shell's equivalent), ie. "export XDG_DATA_DIRS=$HOME/.guix-profile/share:$XDG_DATA_DIRS" if you are using guix install with default profile <Rutherther>but note that gnome is the one that has to have this environment variable, so after you put it to profile file, you will need at least a relog. I am also not sure how gnome does its caching, so it's a question whether you will have to execute a command to reload the applications if you install a new one <civodul>ACTION embarks on postgresql upgrade on berlin <efraim>ACTION is glad Someone Else™ is taking care of it <efraim>oops, time to see if openmpi-5 actually needs all of its inputs <civodul>‘pg_upgrade’ is running now, i expect it’s gonna take a while <efraim>openmpi@4 has a bunch of logic to build without some of the inputs if they're not supported but openmpi@5 doesn't have it <civodul>but it inherits all those that are not supported everywhere <civodul>not sure why there’s (append ucx) since it’s already a dep of openmpi@4 <efraim>thanks. I'll play with building it a couple of times and see how it goes <efraim>looks like ucm gained riscv64 support at some point, even if the test for support is wrong <civodul>postgres upgrade complete, but new postgres is slow as hell (maybe it’s updating “things” in the background?) <jonsger>civodul: which postgres db are you updating? <civodul>jonsger: that of ci.guix, used by Cuirass <jonsger>is the db running on a different server then the cuirass service? <civodul>so, ENOSPC on ci.guix (Btrfs), even though ‘df -h /gnu/store’ says there’s plenty of free space <civodul>if anyone’s familiar with Btrfs (i’m not), now’s your opportunity to help :-) <efraim>civodul: what were you trying to run? <civodul>but the message comes from guix-daemon <efraim>are you sure it wasn't talking about the other machines? <efraim>I'm running my script to try to clear up some space on the other machines <civodul>seems to be making progress this time <Rutherther>PotentialUser-83: civodul is updating postgres on that server iiuc, so I suppose that's why. You can use bordeaux substitute only for the time being <bdju>has there been any talk about doing a new stable release one of these days? just thought of it because NixOS had a new release <bdju>(I'm just curious and not looking to be put to work, fyi) <unmush>lilyp: no such luck, it has a hand-written configure (gcc-2.5.8) <unmush>I guess what I should ask is "where do I get a newer config.sub" <apteryx>is there a way to have ERC reconnect following system suspend? <apteryx>it seems to stay disconnected, without much visual to let me know about that <efraim>can you put it in a loop to try reconnecting when it disconnects? <apteryx>maybe I could do that; but it puzzles me there's nothing builtin for that use case? weechat was reconnecting just fine <Rutherther>bdju: nixos has release regularly, twice a year, guix doesn't have any regular releases. So even if there was one, and I think there should be one not so long into the future, since there are some vulnerabilities that are in 1.4, it would again be mostly for installation, and you use rolling latest after install <bdju>I also noticed by the dates on the ftp that there were releases every year from 1.0 to 1.4 but then nothing for nearly 2 years now <bdju>but yeah rolling release is a good point <civodul>efraim: the ENOSPC issue is gone; you ran ‘guix gc’ on the build nodes? <efraim>civodul: yeah, I have a script that tries to ssh into all the nodes and run 'guix gc -F 50G' <civodul>so your diagnostic was good, thank you! :-) <civodul>BTW, you could use ‘guix deploy -L modules berlin-nodes.scm -x -- guix gc -F50G’ <efraim>it might be better than my home grown script using parallel <Rutherther>bdju: even if they were regular, it's still problematic, as the releases just stay as is, whereas nixos updates "release" channels, so security updates have a chance to get in nixos <efraim>and mine doesn't stop when it encounters an error <efraim>but I also wouldn't have to figure out which nodes are reachable and which ones arent <Rutherther>civodul: btw what is the postgres used for on it? <civodul>Rutherther: for Cuirass (the CI software) <apteryx>hm, from /var/log/messages on berlin: Dec 1 15:24:39 localhost shepherd[1]: Service guix-publish (PID 69073) terminated with signal 6. <civodul>apteryx: yeah, there’s a problem here <apteryx>should we try a reconfigure/reboot first, then troubleshoot more? <apteryx>it may be in a weird state following libc update, if it hasn't rebooted yet <apteryx>it's been up for a month... probably has it, not sure <apteryx>when did libgc (the garbage collector library used by Guile) change? <apteryx>could we revert it in the meantime to recover a stable substitute server? <civodul>problem is i don’t know when the problem started to appear in ‘guix publish’ <civodul>but yes, let’s list possible workarounds and we’ll see <civodul>i’m trying to get a better understanding of the problem in the meantime <civodul>ACTION tries running ‘guix publish’ with fewer workers <civodul>not any better with 4 workers (instead of 8) <civodul>idea of a quick hack: run ‘guix publish’ manually from pre-libgc@8 time-machine <civodul>apteryx: you want to give that a try? <apteryx>I can poke it tomorrow; it's getting late here :-) <civodul>we need to coordinate on MPI-related things, it’s quite critical <efraim>I definately wouldn't have if i had checked the patches mailing list <efraim>I'd revert my ucx patch, apply your 3, and then re-add my change to supported-systems in ucx <csantosb>apteryx: concerning erc, you have erc-server-auto-reconnect and erc-server-reconnect-timeout <efraim>although we might still need the snippet for powerpc64le <janneke>hmm, when gdm fails to start an X session, shouldn't there be an Xorg.0.log somewhere? <efraim>civodul: I'm currently out of the house and then having dinner soon, go ahead and take care of it <fnat>I'd like to execute a short script before 'loginctl suspend' (and another short script on resume). Any way to do that with elogind/loginctl? I see 'man loginctl' mentions a hook folder, perhaps I should put my script there. Or should I consider writing a little service for this? <civodul>ACTION prepares to push the openmpi/rdma-core/ucx updates <gabber>ACTION managed to get an installer to install the Hurd on my T410 <civodul>efraim: i just checked and ucx’s bistro.h still lists RISC-V, so i’m not sure what to do here <gabber>well, let's see if it succeeds. it's spinning <efraim>civodul: I didn't check if it did with 1.15 <efraim>but I saw it was there in 1.16 and 1.17 <civodul>quite funny to see “bistro” in there <anemofilia>I'm writing a configuration record for system-log shepherd-service, but I have no idea on what would be the proper way to do so <anemofilia>kernel-log-file and max-silent-time have parameters as default values <anemofilia>Should the configuration record set these to #f and inside the gexp, use them only if they are true? Even in that case, what sould be the type signature for these fields? <jmbr>When using nautilus in gnome desktop, bwrap (bubblewrap) doesn't know how to invoke evince-thumbnailer to get thumbnails of PDF files. <jmbr>I did some digging and I could get it to work manually by adding --ro-bind $(dirname $(guix locate evince-thumbnailer | awk '{ print $2 }')) /bin to the bwrap command line but I'd like to have a clean solution in Guix. <anemofilia>Ah, sure I could do (define (idk? x) (or (parameter? x) (not x))) to define the type signature in that case... But #f-as-default-value idea doesn't seem very good <jmbr>I've seen that there's an (add-before 'configure 'patch-bubblewrap ...) line in gnome.scm but I'm not sure how to fix things there neatly. I'd appreciate any pointers you could give me. <Rutherther>jmbr: so what are paths ar eyou putting to the container? the whole store? <jmbr>Rutherther: I'm effectively adding this --ro-bind /gnu/store/ahlcdvf0hpb34s4ajlrqs1wj1yciabna-evince-44.3/bin /bin <Rutherther>jmbr: oh, only that? Then I am surprised it works with some apps, because I would expect that as soon as there is a library involved, it won't work, as it needs the library files that are obviously not there <jmbr>That is what I manually add. The whole command is more involved: /gnu/store/2in84x4civ998hkvyjhifc0nbzp271ys-bubblewrap-0.10.0/bin/bwrap --ro-bind /gnu/store /gnu/store --ro-bind-try /etc/ld.so.cache /etc/ld.so.cache --ro-bind /bin /bin --ro-bind-try /var/cache/fontconfig /var/cache/fontconfig --setenv GST_REGISTRY_1_0 /home/jmbr/.cache/gnome-desktop-thumbnailer/gstreamer-1.0/gstreamer-1.0.registry --bind <jmbr>/home/jmbr/.cache/gnome-desktop-thumbnailer/gstreamer-1.0 /home/jmbr/.cache/gnome-desktop-thumbnailer/gstreamer-1.0 --ro-bind-try /etc/alternatives /etc/alternatives --proc /proc --dev /dev --chdir / --setenv GIO_USE_VFS local --unshare-all --die-with-parent --setenv G_MESSAGES_DEBUG all --ro-bind /gnu/store/5dc5wrzy9fz62a08zvik8pijsm4byx3m-gnome-desktop-44.0 /gnu/store/5dc5wrzy9fz62a08zvik8pijsm4byx3m-gnome-desktop-44.0 --bind <jmbr>/tmp/gnome-desktop-thumbnailer-EBUBX2 /tmp --ro-bind /home/jmbr/tmp/document.pdf /tmp/gnome-desktop-file-to-thumbnail.pdf --seccomp 15 evince-thumbnailer -s 256 file:///tmp/gnome-desktop-file-to-thumbnail.pdf /tmp/gnome-desktop-thumbnailer.png <jmbr>Yes, the evince line I described above was what I manually add to this to make it actually work <jmbr>To be clear, thumbnails don't seem to be working for any file format in Guix under Nautilus. I just did some digging in the case of PDFs because that's what I need the most but images, videos, etc. don't have custom thubmnails either. <anemofilia>Just remembered about define-maybe and maybe-set-value?. I guess it's better now <civodul>12k x86_64-linux builds queued currently <AnXa>Hello, is this a proper channel for a few guix config.scm related questions? <ekaitz>this is the proper channel for any guix question <AnXa>Ok, thank you. I have had this problem where I'm following the guix manual to the letter. And no matter how I define %desktop-services in my (services (append (list ...) (modify-services %desktop-services (delete gdm/sddm/whatever-service)))) it will pull sddm on Lenovo thinkpad x60s but on a VM it might pull gdm. And I'm kind of confused about that. I've managed to resolve it by just not using the <AnXa>%desktop-services instead building my own based on %base-services and that seems to work better. But I'm wondering what is the right and correct and proper way to get (lightdm-service-type) to always appear no matter the environment. Also how to avoid xorg-service defined more than once errors and service display-manager service defined more than once errors. <AnXa>Because the guix guides are kind of vague about this aspect and it seems that lightdm-service has some issues too where it doesn't follow the proper configuration either. <AnXa>also this is like my 5th day in guix. I'm coming from Nix and Gentoo. <ekaitz>AnXa: i'm the worst person in this community to answer this question probably, but by default guix uses gdm for the login management <ekaitz>i think there are some mailing list questions about how to remove it <AnXa>Yeah, I know about the mailing list messages. I went through them already and it didn't solve the issue where sddm was always getting pulled. I think it is related to the fact that X60s is pure 32-bit machine and there is somewhere some clause that puts the sddm in the dependency loop... Oh and just for background information... I've been studying common lisp for the past six months and I though it might be <AnXa>fun to see how guix uses guile scheme and if it could help me learn more about lisp. <ekaitz>common lisp and guile are pretty different beasts <ekaitz>they are like... php and javascript <AnXa>I wouldn't mind sddm but it pulls in Qt and Qt declarative in particular. And Guix package repositories doesn't have updated version precompiled for i386 arch and after like having let the thing compile for 4 hours on X60s I gave up. Also sddm seems to default to wayland and it breaks the graphics on this laptop in such a way that all objects I click flash white blocks in xorg. <ekaitz>in any case i'm not sure about how to help you better with %desktop-services, i'm very bad at configuration <ekaitz>i'm pretty sure there's a workaround around it <AnXa>like I wrote I switched my approach and instead of reducing %desktop-services to have lightdm... I built my own services list on %base-services. and I think I got it. But that's something I wished to avoid since guix manuals guide users to the other thing. <ekaitz>yeah.. you just did it the "hard way" <ekaitz>it's not necessarily bad, i'm looking forward to do that myself too <ekaitz>it's probably that some of the services of %desktop-services is depending on gdm or so on, and it's pulling those <Rutherther>AnXa: so (modify-services %desktop-services (delete sddm-service-type) (delete gdm-service-type)) doesn't achieve the wanted result? <the_tubular>Mind sharing AnxA ? I was also thinking about doing this <AnXa>Rutherther: No it doesn't. <AnXa>It leads to other issues such as display-manager service having been defined twice. <Rutherther>AnXa: so what is the issue if you do that? it's impossible you would still get gdm or sddm from desktop services at that point <Rutherther>btw the login/display manager is the only thing that depends on the architecture (64 bit vs 32 bit), so after solving that there should be no difference between desktop services and base services in this issue where you get different login manager based on arch <AnXa>Rutherther: If I do that on X60s, then the sddm appears anyways. Or I get two kinds of errors where either A. the display-manager service has been defined twice and there is a conflict or B. the xorg-server is defined twice and there is a conflict about that. <Rutherther>AnXa: please send the whole configuration and whole error <AnXa>It's way past that already. <AnXa>But it probably could be reproduced by just doing that install using guix dvd and then letting it generate new config.scm and then just add the modify-services delete sddm-service-type into it. <AnXa>and adding service lightdm-service-type into it. <AnXa>also there was a difference between adding the lightdm-service-type into service list as such and adding it into the set-xorg-configuration list. <AnXa>I currently have it added into set-xorg-configuration list. <Rutherther>AnXa: so you deleted only sddm, or both sddm and gdm? <AnXa>I tried both approaches. <Rutherther>AnXa: you should have either set-xorg-configuration, or lightdm-service-type, not both <AnXa>only deleting sddm, only deleting gdm and then deleting both sddm and gdm. <AnXa>yeah, I know that by now. <AnXa>I mentioned it because it leads to two different kinds of conflicts where the just having it as service lightdm-service-type leads to xorg double configuration conflight. <AnXa>*conflict.... and the other one leads to display-manager defined twice conflict. <AnXa>when desktop-services is at the bottom of the services. <Rutherther>AnXa: that is probably because you defined ligthdm service type and set-xorg-configuration when you've deleted both gdm and sddm service types from desktop services. If it's way past you having the config on hand, I have trouble trusting your statements, since you are just recalling something you do not understand from memory, so I am out, I would be happy to help if you share config and error <AnXa>Yeah, I understand that. Sorry that I just popped here when the issue is largely over. <AnXa>If I do another install and run into it again I'll post the config. <Rutherther>AnXa: btw you can also use guix on another distro, and even build the config (guix system build), make vm (guix system vm) etc., so you don't have to be booted in the installation iso, probably in an environment not so friendly for you <AnXa>Yeah, I know that. It's just that I love to try different distributions. And I find Guix interesting since it's fully free and uses Guile. <AnXa>I've already read that. :) <dariqq>ACTION is still not sure whether to report that to lightdm as well <bjoli>Rutherther: I came back here before going to bed just to say thank you. You saved me a couple of hours of trial and error and i really really appreciate it. I just got my third child and I don't have much time to play with my computer, and whatever not spent configuring stuff I can spend whipping lilypond into making the best bassoon fingering <bjoli>I'll make sure to remember the solutions to whenever I meet someone in my situation <bjoli>Just wanted to have it said. It dawned on me that someone unknown had just solved my problems without asking for anything in return and I didn't even say a proper thanks :) Now, good night! <oriansj>bjoli: that is just the nature of guix; if only a small percentage of people who know how to solve a problem help, most problems will be quickly solved. It is the novel and new problems that take the longest (sometimes years like in the bootstrapping case) but even the most insane problem is solvable with the right people thinking about it.