IRC channel logs
2023-05-15.log
back to list of logs
<gabor>Hello, I have a quick question: How can I remove package transformations so that they don't get applied on update? <Kabouik>Is there a way to resume a build initiated by guix install? My device has been building qtbase for half of the day, and passed the install phase, then was in the check phase, but hard rebooted. I'd like to resume from there without doing the build phase again. <stevenroose>rust-analyzer build is broken for me for quite a while already. but it seems weird, it seems to not use the standard guix way for building rust crates and instead manually vendor all the dependencies, but even then it seems to not find a certain dependency that it needs <Kabouik>I'm having issues with vulkan-loader-sdk since several days. I'm not installing it directly but it's being built as a dependency for the packages I want to install. This is the error: https://0x0.st/HN9C.txt <Kabouik>I'm not sure what is wrong, all checks passed. <Kabouik>Erm well no, 5 failed sorry. Still not sure why. <lilyp>Kabouik: sadly there is no inter-build restart mechanism <muradm>sneek: later tell apteryx, could you please have a look at https://issues.guix.gnu.org/63198. questions before the patch are not important any more. after settings cups package from cups-minimal to cups, it didn't work either, and i could troubleshoot the issue. bottom line is that wether cups or cups-minimal is set, it is impossible to use ipp detection. cups service is a must, so that patch provides it. <muradm>sneek: later tell apteryx, "cups service is a must" = "cups pam service is a must" <TristanCottam[m]>To everyone, I'm currently transitioning from maintaining my own channel to working on the Guix source directly. <TristanCottam[m]>I want to be able to back up my local repository online. How should I proceed? What method should I use to reconcile divergent branches after making changes? <TristanCottam[m]>I asked a couple times already, but couldn't get an answer. Any help would be greatly appreciated! <chomwitt__>in a guix system with no login-session manager how do i halt down the system ? <iyzsong>chomwitt__: run 'halt' or 'reboot' as root or via sudo <chomwitt__>thanks iyzsong , carmenshea[m] . are those shepherd scripts? <carmenshea[m]>chomwitt__: I don't know if they invoke anything todo with shepherd...they're just terminal commands. <chomwitt__>carmenshea[m], i thougth that halting the system could somehow involve shepherd.. in order to kill all services one by one etc... <carmenshea[m]><chomwitt__> "carmenshea, i thougth that..." <- I'm relatively new to Guix, having only had it running since December 2022. Prior to this I've always used a sudo reboot, or a shutdown command from the terminal. I've never really thought about the underlying mechanism for shutting things down. Something to study up on. <chomwitt__>carmenshea[m], i'am more newcomer to guix :-) . I was using my debian-age # shutdown -R now but also hadnot given it too much thought either. But now making my guix+shepherd transition i think i should from the start of that journey have a somehow better understanding of the basics. <chomwitt__>ACTION taking a look at halt.scm script somewhere buried in the gnu store.. <efraim>TristanCottam[m]: In that scenario I'd normally 'git stash' any uncommitted changes I'm not ready to make a git commit for and then use 'git rebase' to rebase my commits on top of the new master and then 'git stash pop' to <efraim>then I back it up by pushing to another git forge <jpoiret>chomwitt__: yes, iirc halt asks shepherd to stop the root service, which is PID1 <jpoiret>everything's working great for me :) <chomwitt__>jpoiret, i was taking a look at the halt.scm and my schmeme novice eye can only understand that the halt.scm script just passes the halt command further down to a socket as a 'power-off' command. <cbaines>civodul, I did see your message regarding the guix-build-coordinator system test <cbaines>I think it works for me, although the build coordinator is known to crash at the moment <cbaines>there's also a segfault in guile-gnutls, but that won't be causing the system test to fail <jpoiret>civodul: btw, I've been told that we should really switch to netdde, I'll try to get it to build at some point. <jpoiret>no you don't need a cross rumpkernel i think, just like you don't need a cross hurd, only cross headers <janneke>but i guess i'm a bit at loss again wrt the all the cross packages that we'd need; adding it to gnumach-headers doesn't work <jpoiret>isn't the rumpkernel just an additional server? <jpoiret>It's like netdde I think, you can just add it on top <janneke>jpoiret: i've no idea, i just tried removing --without-rump and that doesn't fly <janneke>the rumpkernel package is purely a library, so someone would need to "pick it up" <janneke>ACTION tries blondly adding rumpkernel to hurd inputs, then :-) <jpoiret>ah yeah, that won't work i think, let me see how they set it up <janneke>ACTION was inspired by jpoiret's hurd work and would really like to see the hurd running on real iron ;) <jpoiret>janneke: so the rumpdisk subdir has a Makefile with an hardcoded location for where to find the rumpkernel libs I believe, that would need to be patched <jpoiret>I wonder why they don't use standard mechanisms though <chomwitt__>jpoiret, you were right. it stop the root service. I wonded if that counts a gracefull system halt (where each process can stop taking care of not leaving loose ends ) or its more like a brute system halt.. <jpoiret>janneke: oh, actually configure.ac searches for librump using a standard compile test with `-lrump` <jpoiret>you might need some additional patching to the rumpdisk dir's makefile but I guess it shouldn't be too hard <jpoiret>chomwitt__: it is a graceful system halt, when user-processes stops, it asks nicely first <janneke>jpoiret: yeah, it looks like at least RUMPPATH could be set as a makeflag <jpoiret>we should try and build most of these as separate packages <jpoiret>possibly by sending patches upstream to make the process a bit more modular <jpoiret>for example the way libdde_linux26 is being built is by patching the Makefile and adding its subdirectory <jpoiret>and hurd-minimal should be renamed to libihash i believe <janneke>hmm, i don't see any msg about "rump" durig the hurd's configure <janneke>that's weird, configure.ac has AC_CHECK_HEADER([rump/rump.h] ... <civodul>jpoiret: re netdde, sure, though i guess it doesn't matter all that much as long as we're not on the bare metal <efraim>janneke: Debian default (for years now) is to regenerate the configure script everytime a package a built <janneke>efraim: that's great, but why have stale a ./configure in your (upstream) archive? <efraim>no one noticed before, if all the development is being done on debian <jpoiret>let's say upstream's repo is a bit of a mess <jpoiret>civodul: i know some people have been running Hurd on bare metal, so we might want to look into it <jpoiret>also it's unmaintained so more risks in the future <Altadil>Hi, I’m trying to get virt-manager working on Guix System. I added a libvirt-service-type in my os config, with unix-sock-group "libvirt". I also added myself to that libvirt group. Finally, I added libvirt and qemu to the list of system packages. But when launching virt-manager, it says it could not detect a default hypervisor. Does anyone know what I am missing ? I could not find any other requirement in the manual. <janneke>make[2]: *** No rule to make target 'rump/rump.h', needed by 'block-rump.o'. Stop. <janneke>ACTION added "rumpdisk" as directory but is still puzzled about seeing rumpy nothing during configure, <janneke>jpoiret: on the one hand, modularizing could be nice, otoh it might increase the "finding versions of all parts that work together" problem even bigger? <jpoiret>it might, but we could keep all of them synchronized since they come from the same repo <jpoiret>i'm not expecting upstream to do away with the monorepo thing <jpoiret>it's just from a package hygiene perspective on our side <Kabouik_>Thanks lilyp. I'll try again from scratch then, crossing fingers. One thing I tried multiple times and which failed everytime, however, is vulkan-headers-sdk. This doesn't want to install on aarch64. It works, but 5 tests out of 427 fail, and so the whole install fails. Does that deserve an issue? <cbaines>Kabouik_, I think there's already at least a couple of open issues about that <efraim>Kabouik_: vulkan-headers builds for aarch64-linux, the build farm even has substitutes. do you mean cross building it? <efraim>wait, i mispoke, berlin doesn't have a substitute, bordeaux does <Kabouik_>I am not sure efraim. I am not specifically trying to install it, but it is required by some other packages I'm trying to install (among which mpv, ytfzf, yt-dlp, ffmpeg, etc.), and every time the build fails because vulkan-headers-sdk fails at 5 tests. I posted the zcat above, let me find the link again. <efraim>thanks. I'd like to take a look at it if it is causing problems <efraim>is there more than just that? it's a little light on details <Kabouik_>I can get the full zcat if you want, sure. I can also try running an install with a higher verbose level (but Guix is already busy right now, I can do it later). <efraim>it looks like it's vulkan-loader <Kabouik_>Sorry yes, I pulled the name from the top of my head and got it wrong. vulkan-loader-sdk indeed. <drs53>12:05:22 <drs53> just updated to latest kernel 6.2.15 12:07:27 <drs53> when i type emacs into terminal emacs opens but the terminal says don@polaris ~$ emacs /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libc.so.6: version `GLIBC_2.34' not found (required by /gnu/store/8sfnwc672lswqgkf9g5qv7r5247jyipp-libproxy-0.4.17/lib/libproxy.so.1) Failed to load module: /gnu/ <drs53> /gnu/store/qxwp4s2jsy02g96izw9x5s4jjarbj94n-glib-networking-2.72.2/lib/gio/modules/libgiolibproxy. <rekado>drs53: you have a mix of C libraries <Kabouik_>I have this zcat in my /var/log/guix efraim, but it doesn't show the same lines as above: https://0x0.st/HNO0.txt Probably those are different attempts, I'm not sure why the cat is different though. <rekado>drs53: are your user packages up-to-date? <rekado>drs53: guix gc -R on the packages in question will likely show you that they are linked with different versions of glibc. <ennoausberlin82>I asked it before, but got no answer. How can I tell a channel to use packages from another channel. Lets say as inputs for package definitions. I don't get the syntax right <rekado>ennoausberlin82: the .guix-channel file must list the other channel as a dependency <rekado>see 7.8 Declaring Channel Dependencies in the manual <rekado>and how did you upgrade to the new kernel? <rekado>what does “guix gc -R” on your emacs say? <rekado>does it mention glibc 2.33 or something later? <drs53> sudo guix system reconfigure /etc/config.scm <ennoausberlin82>rekado: Thats it. I was playing around with use-modules and failed. I have to reread the manuals from time to time. Thank you! <drs53>guix gc -R emacs and guix gc -R glibc so I the guix upgrade <cbaines>Kabouik_, efraim, ah, I'm getting confused between vulkan-headers and vulkan-loader <drs53>I will return to this after upgrade finishes <efraim>right now I'm building 1.3.231 on aarch64 to see if that compiles <Kabouik_>The confusion is on me cbaines, I did say vulkan-headers-sdk, but it was indeed vulkan-loader-sdk. So what I am seeing is confirmed, right? <Kabouik_>Yeah, I can see the failures for aarch64 on the link you posted (handy, I didn't know Guix had that). <efraim>I'm tempted to limit tests to '(and (%current-system) (target-x86?))' since that seems to be all upstream tests <Kabouik_>efraim some older version and relatively recent version must build indeed, because I remember installing ffmpeg and mpv from Guix on the same aarch64 machine like 2 weeks ago <efraim>I've built them before too. I'll see if I have better luck if I use debian's versions for vulkan-loader and vulkan-header <Kabouik_>Hey that might have been my case actually, because two weeks ago my packages were more a mix og Debian and Guix packages than now, where I'm trying to have everything not shipped with the OS installed by Guix <efraim>I'm trying with them both at sdk-1.3.239.0 <efraim>it worked for x86_64 and i686 so far <efraim>same 5 test failures on aarch64-linux <efraim>still 23 test failures on powerpc64le <Kabouik_>I'm building qtbase too, since days (got hard reboots in the check phase :(), I'm now discovering the perks of using Guix on a mobile system :p <Kabouik_>6.3.2 though, and there's no subsititute for it <attila_lendvai>i'm on a commit that is a couple of days old. there should be a substitute for it. <efraim>still 21 tests failing on armhf-linux <efraim>riscv64-linux hasn't hit the test phase yet <efraim>oh, it's going to be anti-climatic, I've already skipped the tests on riscv64 <janneke>jpoiret: you're right, rumpkernel provides (two?) extra servers <janneke>ACTION misread debian/rules and failed to build them, until now <sneek>Welcome back apteryx, you have 2 messages! <sneek>apteryx, muradm says: could you please have a look at https://issues.guix.gnu.org/63198. questions before the patch are not important any more. after settings cups package from cups-minimal to cups, it didn't work either, and i could troubleshoot the issue. bottom line is that wether cups or cups-minimal is set, it is impossible to use ipp detection. cups service is a must, so that patch provides it. <sneek>apteryx, muradm says: "cups service is a must" = "cups pam service is a must" <apteryx>sneek: later tell muradm re pam support for cups, sounds good, thansk for troubleshooting it <apteryx>lilyp: seems the --add-header-cmd script (teams.scm) worked to notify me on a git send-email? or did you manually CC me? <evilsetg[m]>Is there a way too see which gc root keeps a store item alive? I have a profile in the store that I think came from a guix shell invocation that I cannot get rid of. <efraim>who's in charge of the tex-team branch? <Kabouik_>efraim do you think tests can be dropped for vulkan-loaders-sdk as you suggested above? Are you one of the maintainers for this package? <efraim>Kabouik_: it's more of a joint maintainership. I tried skipping just the 5 failing tests on aarch64, but without a patch I couldn't get more granular than 80 skipped tests <efraim>if someone comes along and can make it better I won't be offended. For now I've skipped the tests on most of the architectures <Kabouik_>But it built fine with that change, right? <efraim>I only tested aarch64-linux and that x86_64 and i686 didn't change <Kabouik_>Meaning if I guix pull and retry, it should work, or is the commit not pushed yet (before approval by others I assume)? <Kabouik_>Nice, I'll try it when qtbase finishes (and fails, I'm afraid), in 10 hours more or less :p <efraim>it didn't break anything currently working <Kabouik_>Thanks a lot for the swift reaction to the issue <jpoiret>apteryx: i've been having the ./etc/teams.scm script spit out its usage every time I git send-email, so I'm assuming it's being invoked with bad arguments, have you experienced the same? <apteryx>I haven't but then I haven't sent many patches that were covered by teams, I think <apteryx>in my artificial tests it seems to work fine; how do you invoke 'git send-email' exactly? <jpoiret>ah, that may be why, it expects either patches or <start> <end>, right? <apteryx>perhaps we should teach teams.scm to be more git refspec aware <apteryx>sneek: later tell muradm I've reviewed the suggested change; I think it needs some more work, to allow for regular PAM auth instead of bypassing it (IIUC) <apteryx>civodul: In a first pass, I wasn't able to figure out what's wrong with the jami tests; everything looks good when invoked by hand <apteryx>different marionette-eval invocations reuse the same global state, correct? that's currently assumed. <apteryx>that it doesn't print any error other than the assertion failed is not very helpful. <apteryx>jpoiret: when it fails, does it block the submission? <bjc>should ‘modify-services’ error out when trying to a service which isn't configured? <bjc>i migrated from %desktop-services a while back to building off of %base-services, and have a few rules that no longer apply <bjc>i wonder how hard it would be to change that behavior. i may have a look at it in a bit <graywolf>Hello, I seem to have a problem with external monitor. xrandr does not show it, however the device is visible under /sys/class/drm. Any idea what might be wrong? I'm not even sure how to debug this :/ <jpoiret>apteryx: no, so that's okay, but I've probably been missing out on some nice CCs <apteryx>jpoiret: it'd be better if it failed; otherwise people are not CC'd, defeating the script puprose <apteryx>I guess the usage should end with exit 1 <andreas-e>Hello! I have problems compiling Guix from source on an aarch64 machine, with a guix pulled on May 10. Configure complains again about something with gcrypt: <civodul>apteryx: d'oh, weird; sounds like we'll have to add pks and sleeps all around? :-) <andreas-e>configure: error: GNU libgcrypt not found; please install it. <jpoiret>andreas-e: is that a fresh checkout? <efraim>by hand or using 'guix shell -D guix' ? <andreas-e>It was from May 10, but I just "guix pull"-ed again. <andreas-e>configure:10900: checking for gcry_md_open in -lgcrypt <andreas-e>configure:10922: g++ -o conftest -g -O2 conftest.cpp -lgcrypt >&5 <andreas-e>ld: /home/andreas/.guix-profile/lib/libgpg-error.so.0: undefined reference to `pthread_mutex_trylock@GLIBC_2.34' <andreas-e>Where could this come from? I do not see glibc@2.34 in Guix. Maybe from Debian. <efraim>the GLIBC_2.34 sounds like a mix of glibc-2.33 and 2.35 <efraim>but it looks like you're installing packages in your profile to try and build guix <civodul>well, you also need to "rm -f config.cache" and "make clean" <andreas-e>Ah, thanks for pointing this out again, civodul. I always forget the isolation. <bjc>it seems like i'll have to transpose the list iteration in modify-services to get it to notice errors <andreas-e>But my user Guix should be new enough to have no traces of glibc@2.33. <andreas-e>And "make clean" does not work without ./configure ;-) <bjc>and there's no tests for ‘modify-services’ either, so i guess i know what i have to do first ;) <apteryx>civodul: it doesn't strike me as a timing issues; bumping the with-retries timeout from 20 to 80 doesn't help <apteryx>it seems like in that environment, (jami-service-available?) aways return #f <andreas-e>civodul: That was it, ./configure goes through, thanks again! <andreas-e>I see python@3.8.5 in the "guix past" channel, but not @3.9. <mirai>what's the reason for separating tests/ and gnu/tests/ ? <andreas-e>It is a channel some researchers set up to reproduce old experiments; I think with software that was not packaged in Guix. <civodul>mirai: gnu/tests is for system tests, which requires heavy infrastructure: building QEMU, spawning a VM, etc. <civodul>whereas tests/ includes unit tests and integration tests <civodul>those can be executed without building anything (or almost) <andreas-e>tex_milan: You should be able to use the time machine to go back to a Guix commit that had python@3.9. <andreas-e>Probably anything before the recent core-updates merge will work. <mirai>civodul: what stops them from being under a subdirectory of tests/ ? <civodul>mirai: another thing: (gnu tests ...) are regular modules that you get with "guix pull", etc. <andreas-e>I just got "killed" (OOM, I suppose) for "guix pull" on a virtual x86_64 machine with 1GB of RAM. Is this expected? <efraim>I'd add swap to get to at least 2GB <andreas-e>The compute-guix-derivation script takes so much memory. Since when does guile behave like C++? ;-) <jpoiret>it's been that way for quite a long time now <attila_lendvai>andreas-e, i'm managing such a small VPS of mine using guix deploy <efraim>there's also the magic channel invocation that only will pull to a commit that has substitutes for 'guix pull' <andreas-e>efraim: But it will still need to compute the guix derivation, no? I think substitutes appear only later. <janneke>jpoiret: just built the hurd with rumpkernel/rumpdisk...now will it boot? <janneke>ACTION added /hurd/pci.arbiter.static and /hurd/rumpdisk.static multiboot server modules, but apparently they don't exist <janneke>ohh, but the non-.static variants do exist! <janneke>i'll try first with the non-static ones before trying to figure out how to build the +.statics <dcunit3d>i'm running into some issues with my user shepherd. i just upgraded. i'm not sure if my environments or imports are correct. i added guile-fibers to my system profile and that seems to get me past a few things, but the shepherd process keeps crashing before it starts. <dcunit3d>i noticed that there's a repl and some logging services now, so i should be able to use those <dcunit3d>but is there anyway to launch it within a process that will catch an error in a debugger? <janneke>oooh, almost? bootstrap script missing symbol 'fs-task' <cage>Hi! Do i need to sign my commit with gpg to submit a patch for a package? <cage>i get this error trying to make a commit: "error: gpg failed to sign the data" <dcunit3d>i keep getting things like misc-error(#f "attempt to suspend fiber within continuation barrier" () #f) <dcunit3d>do you have signing set up on other repos? <janneke>hmm, now hanging on: start: pci.arbiter: <andreas-e>dcunit3d: Patches are signed by the committer when they are committed to the master branch of the official repo, otherwise you just submit your patch to the mailing list (which sends it to debbugs). <cage>andreas-e: I just sent the patch to the mailing list, thank you! <andreas-e>cage: I think the trick is to keep the patch on a different branch from master. <cage>yep, I did just that, but I also had to disable the signing from git configuration (it was set to 'true', for some reasons) <jpoiret>janneke: do we really need the static ones? <jpoiret>you can add the pci-arbiter and acpi translators, I think they were able to start in my case <PotentialUser-71>What is the proper way to add a /etc/sub?id file? Perusing the documentation suggests that (file-union) followed by (plain-file) would work, but I am unsure if that is correct. <jpoiret>you need to extend etc-service-type, there's more info in the docs <lilyp>apteryx: I used the script, but manually squashed the output to one header <janneke>jpoiret: no idea, i just looked at what debian did <janneke>i don't know of any acpi server, tho <apteryx>lilyp: in its latest version (already committed, it should produce just one header) <lilyp>yeah, but teams.scm is slow to updates – it doesn't get rebuilt until your rerun ./configure <PotentialUser-71>is podman functional, or just packaged? i am unsure how many tweaks would be necessary to get it to work <jpoiret>guixfren: there is, but it does require a non-trivial amount of work <guixfren>jpoiret: Yes, I'm aware of that. Was there any more discussion on this? I'd like to look deeper into the idea <janneke>ACTION sends patch series and gives up for now ;) <rekado>awscli fails to look up certificates on foreign distros <rekado>I think it will only respect included certificates. Looks like it’s python-certifi’s fault. <apteryx>TheSkylarverncc[: have you checked with the nouveau people, perhaps in #nouveau on the OFTC IRC server? <apteryx>they may be interested in gathering your hardware information <apteryx>the libre-linux is typically the latest, while Mesa was just recently updated, so is still fresh <lemos[m]>i'm dealing with multiple sources that are dependencies from a package, can i spec a name and a place for them to be placed? <lemos[m]>a nem for the tar, i mean, and a place to unpack the source <janneke>finally found what broke the touchpad on my dell xps-13 <civodul>it's supposed to be fixed by 2e55a4c6b9153fd1db60122cb29cee466693a753, no? <janneke>it was kinda hard to find because all it's all over the interwebs how libinput is this cool new preferred thing..only it doesn't seem to work on my laptop <janneke>so i first tried to configure libinput harder, do'h <civodul>the comment section is, of course, a must! <rekado>“This looks just as useful as Hurd.” — at least one of them gets it! :) <guixfren>guix is an excellent package manager for a foreign distro - probably the best imo <guixfren>Guix system is for niche use cases or Scheme nerds <mirai>I fail to comprehend the fear surrounding turing completeness for init files <mirai>how would a (say INI-like file) stop something like Execute=/bin/clearly-malicious.sh <guixfren>security people have this nice habit of seeing insecurities everywhere, even where they aren't a realistic concern <mirai>it seems to me that whatever crap that makes it to the init file would imply that you already got the access you need to wreck the whole thing <rekado>I love these comments. They are AI-generated satire, right? So realistic! <rekado>ACTION goes back to reading comments on random Youtube videos for intellectual nourishment <janneke>mirai: yeah, it's probably wise not to install unreviewed code downloaded from the interwebs <guixfren>in my opinion since Guix enables me to do that it is inherently insecure <guixfren>TempleOS got security right - no networking whatsoever <janneke>rekado: scary how AI is getting bored just like humans and instead of doing something meaningful it goes to troll comment sections <mirai>yeah, it's a risk since there's no considerations for the “inner demon” risk <guixfren>to be fair setting up an AI to troll a certain forum with logs sounds like a way to generate some funny interactions <guixfren>that thread really reads as if it was GPT - so many statements yet absolutely no substance whatsoever <attila_lendvai>i'm on HEAD, and chromium cannot save files, or open file dialogs for e.g. email attachments. is this something known, or something broken on my side? <attila_lendvai>if i e.g. click "save image..." in the context menu, then nothing happens. <gabber>i'm unable to update one of my systems due to igt-gpu-tools failing to build. this is due to it being unable to find the header file "proc/readproc.h" (which is supposed to come from the package procps). i can see that file in procps package's sources, but somehow it is not copied in the install phase. any ideas on how i can fix that? <gabber>attila_lendvai: maybe some graphics/gtk/something library missing in your profile? <gabber>nvm my thing, i think i figured it out <gabber>oh no, including the relevant header in procps triggers a whole-world rebuild?