IRC channel logs
2023-12-07.log
back to list of logs
<ieugen>I am getting this on debian while guix package -u : guix package: error: package glibc-locales@2.37 does not support x86_64-linux <ExclamationPoint>can i get a good resource on a nice intro do Guix without being pointed to a single pargraph or the docs? <ExclamationPoint>i would take the docs + ref to sections i should quickly raed to understand the featuers and power of this project <pranshu>Hello, does anyone know a C-h and ielm equal in guix? <pranshu>guix home/system describe don't seem to work as well. <PotentialUser-50>Hello. Are there any guix maintainers online that could help me with a patch series issue? I have submitted a package successfully and decided it was time to try submitting a patch series. I just got an email from "MAILER-DAEMON@mailchannels.net" saying that my message could not be delivered. The message also says "Unrouteable address (in reply to <PotentialUser-50>RCPT TO command)". I assume that I have forgotten to populate a field in my email and need to resubmit, but I don't want to accidentally spam the guix-patches list. <nadia_>this happens when trying to access the file system via icecat on nixos <PotentialUser-50>I have to logoff soon. I guess if I don't see a response email tomorrow I'll just resend the patch series and see if it goes through. <evilsetg>I get an error 'corrupt input while restoring archive from #<closed: file ffff6f609930>' while building nss-certs. I assume this is from a corrupt input download. Is there any way to clear that from the store or should that happen automatically? <lilyp>that looks like an on-download error, so it should attempt to download again <mfg>Hey, i was wondering, why on one of my machines the halt command does not actually power off the system. It seems all programs are stopped. Are there any logs or similar i can look at? <mfg>it's also not the halt i'm used to from other distros (i'm on guix system), where halt -p would work <mfg>the help message is also not to helpful, it says "halt OR power off the system", but there is no way to specify which of these things i want to do <mfg>also: /gnu/store/2s5is3kdgjw5hfga155k5l1s14r6xi7n-shepherd-0.10.2/share/guile/site/3.0/shepherd/scripts/halt.scm seems to suggest that it is supposed to always power off? <Rovanion>On my machine neither halt, shutdown nor reboot does anything. Though that may be the machine being broken. Need to install Debian to verify. <gabber>mfg: what kind of machine is it? this might have to do with architecture or hardware configuration <mfg>It's a relatively new machine, amd64 <civodul>mfg: hi! that sounds like a bug, like shepherd getting stuck before it gets to halt the machine <janneke>civodul: thanks for fixing "glibc-locales@2.35" :) <mfg>civodul: how would i confirm that suspicion? <gabber>might have to do with a faulty (or not 100% complete) device tree -- have you searched the webs for your machine and compared the device tree(s) in use? <civodul>janneke: yw :-) just this morning colleagues told me “hey we had glibc-locales problem yesterday!” <mfg>gabber: no, i haven't done anything like that. I'll do that now <civodul>mfg: it’d be great if you could grab as much info as possible from /var/log/messages etc. <civodul>even better if you can reproduce it with your config in ‘guix system vm’ <mfg>civodul: let me see how far i can get :) <civodul>if you feel adventurous, i can share additional tips :-) <gabber>sorry, i seem to be unable to read: you wrote amd64 not aarch64. forget everything i said with device-tree (device configuration happens in BIOS on your machine) -- so it might be worth checking the settings there <mfg>I tried it with Debian, that works just fine. So i'm now trying to reduce my config for MWE <mfg> i haven't used guix system vm before: do i simply put in the same config as i would use on bare metal or do i need to change things like the bootloader and/or file-systems field to something special? <civodul>mfg: yes, same config, so most likely: guix system vm /run/current-system/configuration.scm <civodul>and then you launch the ‘run-vm.sh’ script it produces <efraim>I've run into the same "doesn't actually shutdown" thing, but normally on other architectures so I was never sure if it was a shepherd thing or an architecture thing <civodul>but then it could be a function of the Shepherd service on one’s config, who knows <efraim>on the unmatched board "shutdown doesn't actually shutdown" is a known bug across distros <efraim>not good, but good that it isn't us specifically :) <oceane>i wonder how affordable it would be, to pre-configure gnu/linux distributions with an erc bouncer? <oceane>because honestly, irc is confusing to beginners, and they don't even know that their public ip address will be shared before connecting <efraim>I've been using quassel on an inexpensive VPS for many years now but it comes with the overhead of maintain the VPS. There's also the irc bouncer through sourcehut which should be zero maintenance <efraim>the make-dynamic-linker-cache phase never actually builds the cache on i586-gnu with no ldconfig <mfg>another thing: i noticed that swaylock-effects is now compiled to use pam modules which leads to the error message that is can't be setuid at the same time, but when it isn't setuid it can't read /etc/passwd to validate passwords. How is this supposed to work? Is there documentation anywhere? <mfg>i didn't even know there is a service for it :| <civodul>for some reason, the thing didn’t Cc: the whole world this time <civodul>so apteryx jpoiret janneke cbaines nckx please consider taking a look! <lilyp>civodul: the link is dead, sadly <efraim>it might take a few minutes to sync with mumi <lilyp>btw. is that a newer one than the one on gnome-team? <efraim>civodul: did you build out to hello on any architectures? I can test it out on some of the others <mfg>civodul: the guix system vm of my current config halts perfectly fine <civodul>efraim: i built coreutils-final on x86_64-linux, that’s all <efraim>ok, i'll check hello on x86_64 and i686 and then start the slower architectures <civodul>mfg: is your root file system cleanly unmounted? <mfg>where would i find that? <civodul>like when ‘halt’ fails to power off the machine, next time you boot, do you see messages about root not being “cleanly unmounted”? <mfg>ah and i wanted to share some contents of /var/log/messages <mfg>civodul: i had an issue with the efi partition once, i guess it does not like it when i just unplug the system <mfg>it didn't came back though <mfg>doesn't look suspicious to me tho <civodul>mfg: could you also paste the pre-shutdown messages? <mfg>civodul: they should be on lines 168-207 or do you mean something else? <civodul>mfg: oh right, i overlooked that, sorry! <mfg>no problem, it's much text :) <civodul>“File system check corrected errors on /dev/nvme0n1p1; continuing” <mfg>jeez, i didn't see that :( <mfg>that's the EFI partition <mfg>now that i spent more time with this it does feel like a hardware thing <pastor>efraim: could we discuss how we can get this package merged? (I believe I overdid it with the dependency chain... Maybe I should have only packaged the immediate rust dependencies.) https://issues.guix.gnu.org/67515 <pastor>I tried to remove the `#:skip-build?` flag whenever possible from the rust packages <efraim>pastor: right now I'm waiting for one of the build farms to catch up to the current rust-team branch on aarch64 so we can merge the branch into master, and then I'll take a look at it. <efraim>currently I'm building rust-1.72 on berlin and bayfront is nearing the threshold to start building patches and branches again <pastor>efraim: sounds good. I was a bit affraid of scaring revisors with such a long patch list. I did address the dependencies in the hope that I would ease the rust-team work-load. <efraim>civodul: I couldn't wait so I started the build for a bunch of architectures and I have berlin building for x86_64, i686 and powerpc64le <janneke>time for someone to update hurd packages... <oceane>hello, how can i install pcscd on guix? <oceane>but i've installed pcsc-lite and ccid, and it tells me that PC/SC isn't available! should i start a service? <lilyp>we have a pcscd-service-type for your OS config.scm <oceane>i'm sorry, but guix system reconfigure throws me an error for pcscd-service-type being associated with unlinked data; i've tried to add an entry similar in syntax to set-xorg-configuration, i.e. (set-pcscd-configuration (pcscd-configuration (pcsc-lite))), but without success <oceane>in the (operating-system (services (append (list (service ...) (service ...) ...)))) <lilyp>The correct syntax should be (services (append (list (service pcscd-service-type)) …)) <lilyp>Note that you need to import (gnu services security-token). <lilyp>use-service-modules simplifies that a little <oceane>i'm reading the guix pdf in public transportation, but i still have a lot to learn! <anthk_>html help would be more readable <oceane>i'm a sociology student so i prefer to read pdf documents when they're available; it's on my phone <oceane>i'm just more familiar with pdfs <civodul>efraim: re llvm-for-mesa on i586-gnu, what did you expect? :-) <efraim>I guess I expected it to just work :) <efraim>I'm doing the compiling on berlin if anyone wants substitutes while building to mesa <anthk_>he made a case on deffending free software even for non programmers; he wrote the Elisp (Emacs editor's programming language) introduction guide <civodul>efraim: keep the load under control :-) <efraim>I mean i set it to build and let it offload as it wants. I'm keeping an eye on aarch64/armhf since they seem to be overloaded and behind <oceane>anthk_: thank you, i'll keep it in my bookmarks for now <attila_lendvai>civodul, hi, have you seen my question/bug about the module (shepherd support) being imported for the GEXP's of services? is that intended? part of the shepherd API? or a bug that needs to be fixed? https://issues.guix.gnu.org/67649 <attila_lendvai>it would be nice to know, because i'd channel my efforts accordingly. <nikolar>is there a way to prevent a package that's used in a guix shell from being gc'd <nikolar>i don't want to install it because it clashes with the native distro package <attila_lendvai>nikolar, i *think* you can create a named profile and while you keep that around it'll prevent the gc... i remember reading something along these lines, but don't take my word for it. <nikolar>so i just install the package in the named profile instead <nikolar>wouldn't that lead to version mismatches though <mfg>civodul: it does not seem to be relevant, that the filesystem gets corrected on boot. If i manually unomount it before issuing halt it also doesn't halt, but then on the next reboot there is no corrected error in the logs. <mfg>civodul: is it somehow possible to get stacktraces from shepherd while doing the halt? or some other information that may give a hint as to where it is stuck? <attila_lendvai>ACTION is adding extensive logging to shepherd to debug this issue that it sometimes doesn't respong to herd requests <ds-ac>mfg: I don't know if it would help, but you can access logs through TTY 12 during shutdown to see what goes on during shutdown. A few months ago I had issues during shutdowns (which magically disappeared after a reconfiguration, so I didn't really invertigate); I could see /gnu/store being mounted and unmounted on a loop on TTY 12, but it did not show up in the logs after a hard reset <efraim>civodul: built to hello on powerpc64le-linux <mfg>ds-ac: sadly i can't see a thing in tty12, there is no message that isn't also in var/log/messages <mfg>what the heck? while being in tty12 pressing the delete key actually seems to have let the system power down? <mfg>let me do that again... <nikolar>does anyone know why i can't cargo add anything <nikolar> [60] SSL peer certificate or SSH remote key was not OK (server certificate verification failed. CAfile: none CRLfile: none) <mfg>ok, pure luck. would have been to funny... <mfg>nikolar: do you have nss-certs in your profile? <mfg>Cafile: none seems not right <mfg>that way you don't trust any certificate <nikolar>i've added pretty much all packages with 'certs' in the name <mfg>are you on guix system or on a foreign distro? <civodul>mfg: unfortunately no; one reason this is hard to debug is because (1) almost all the services have been stopped at this point so you don’t have a shell, and (2) syslogd has been stopped and possibly you don’t get to see the very last messages from shepherd <civodul>if we know root wasn’t cleanly unmounted, then we can at least tell that shepherd hanged before that point <mfg>civodul: root seems to be unmounted just fine, it's the efi partition that seems to not have the dirty bit removed since i power cycle the system. That's where the filesystem correction comes from. Is it possible to influence the order in which shepherd kills services? is it possible to kill syslogd only after everything else is finished gets killed? <efraim>would it work to have the services depend on syslogd then? I'm not sure that would work for file-systems since they'd need to actually write the data somewhere <civodul>processes need to terminate before file systems are unmounted <civodul>the ‘user-processes’ service takes care of that <civodul>you can see it with: sudo herd graph | guix shell xdot -- xdot - <mfg>also i can not find the message "sending all processes the TERM signal" anywhere in the logs which should be written before the wait loop is entered <civodul>yeah, that’s because syslogd is gone at that point <mfg>this should also be in /var/log/messages? <civodul>(eventually we’ll have syslogd facility within shepherd) <civodul>in the meantime, debugging this kind of issue is tricky! <civodul>if you’re daring, you can write files here and there to get a better idea of where things go wrong <civodul>like adding (call-with-output-file "/here-i-am" (const #t)) in a couple of places in the services mentioned above <mfg>well that happens when you use too many keyboards, now i need to change that :D <efraim>that's strange, all I see is ******* <mfg>got me, i had to lookup the logs to decide whether this is a joke or not :D <sarg>civodul , thx for updating emacs-guix. Now it works fine for me <zilti>In Gnu Home, how can I add a directory to the PATH variable? <attila_lendvai>if i call (setenv "PATH" ...) in a service GEXP, and then (system "ls"), then will the system call fork a new shell? and if so, will it inherit the PATH? the error i'm staring at suggests the opposite (command not found) <attila_lendvai>IOW, what is the equivalent of the export shell directive? i guess (setenv ...) is not the equivalent of export PATH=..., right? <civodul>nckx: did we forget to restart the mumi thing? <civodul>attila_lendvai: ‘make-forkexec-constructor’ has an #:environment-variables parameter whose default value is the initial set of environment variables <civodul>which is kinda surprising, because then if you ‘setenv’ in shepherd, the changes are not inherited by newly-spawned processes <civodul>well, processes started by ‘fork+exec-command’ <attila_lendvai>civodul, this is in the service code that prepares the environment before any forkexec calls. so, this is a GEXP running inside shepherd, but calls (system ...) to do some stuff with some coreutils binaries. <attila_lendvai>i should rewrite it to guile eventually. maybe it's a good nudge... <sarg>zilti: u mean guix home? See home-environment-variables-service-type <bdju>is gajim still broken on an up-to-date guix or is it safe to update yet? <graywolf>I am reading the manual and I wonder if I got it right: If I do "guix build --system=aarch64-linux-gnu pkg", it will do native build using qemu (build == host == aarch64-linux-gnu). However with "--target=aarch64-linux-gnu" it will do cross compilation (build = x86_64-linux-gnu; host = aarch64-linux-gnu). <ieugen>no longer using guix clojure-tools since it's not up to date, I get an error and the patch I submitted to fix this was not merged - <graywolf>So for testing native building, I should use --system, and for testing whether package can be cross-compiled, I should use --target. <trnry>I submitted a patch a few weeks ago adding some vim plugins and since then have heard nothing about it. Is that just the normal time to have something reviewed or did I do something wrong in the process? I'm new to doing stuff via git send-mail <ieure>trnry, Seems to be, unfortunately. I had one patchset reviewed and merged pretty quickly, but several more just sitting there. <trnry>Okay thanks. I understand that maintainers only have so much time, I was just worried I didn't do things correctly <graywolf>(but to be fair, the delays are there even if you do send it correctly) <graywolf>I looks to me like you send all the patches in one go, so it created multible issues. 67186 is just the cover letter, first patch is 67187 etc. <trnry>Oh I didn't notice that section of the manual. At this point should I close all of the extra issues that were created and resend those patches to the cover letter issue? <trnry>Do I even have the ability to close the issues created by my patches? <graywolf>You probably can just close the 67187 onward and send the patches to already existing 67186 <trnry>Okay thanks. I'll try to get this cleaned up then <graywolf>I will close them, so you can focus on the 67186 :) <lambdatronic>I created a package for the latest release of matterhorn, which is a TUI client for Mattermost. <lambdatronic>This relies on matterhorn and all of its dependencies being available on hackage (which they are). <lambdatronic>Now I'm trying to build a package for the latest development (unreleased) version of matterhorn. This requires me to use `git-fetch` and `git-reference` in my `origin` field to grab the latest source code on the development branch. <lilyp>Looking pretty normal right now; where's the question? <lambdatronic>The problem I'm running into is that matterhorn depends on two other packages that must also be downloaded as source from a git forge: mattermost-api and mattermost-api-qc. I tried making development packages for both of them, but when they reach the build phase, they actually say that they are building matterhorn (not mattermost-api or mattermost-api-qc as expected) and they crash with the error that they are missing all of the ot <lambdatronic>When I checked their build instructions online, I see that these two packages actually have to be installed as git submodules for the build to work. <lilyp>In that case, you might add them as part of an "unpack after unpack" pattern <ieure>I know many people despise Git; personally, I rather like it. Except for submodules, which are a bad implementation of a terrible idea. <graywolf>ieure: Hm? Why are they bad implementation? I agree that the idea is terrible, but techically they do work fine no? <lambdatronic>So there's the rub. I dug through git-download.scm, and I can see that the `git-reference` record takes an optional `#:recursive?` field. It looks like setting that to #t should make the build task automatically download those two git submodules, but it doesn't appear to be working. <zamfofex>I feel like Git submodules can be useful, but people misuse them. (I agree they are not implemented well, but I mean in principle.) In any case, if they didn’t exist, people would just vendor the dependencies, so it’s not like they enable anything that isn’t otherwise possible. <lambdatronic>Does anyone know anything about the `#:recursive?` field in `git-reference`? Am I using it incorrectly by setting it to `#t`? <lambdatronic>Or is there any other way to pull down the git submodules other than through a `modify-phases` call? <zamfofex>I think you might need to update the hash. <ieure>graywolf, They do not work fine at all. Clone a repo with modules, and the clone is broken until you init and fetch the submodules. Submodules get updated, you pull, your copes don't get updated unless you run another, special command just for them. They are horrible. <lambdatronic>I'm not seeing a hash check error. The `guix build` command just clones the main matterhorn repo, starts up the build process, and then crashes as soon as it realizes it is missing those two submodule dependencies. <graywolf>lambdatronic: Not sure, the field is documented, I would expect it to work. Can you post the package definition you have and the output from the build attempt? <ieure>lambdatronic, So it's impossible to compile either of those -api libraries on their own? They have to be built as part of the submodule? <ieure>Ugh, have to be build as submodules within matterhorn? <lambdatronic>ieure Yes. It's a pain. I tried building them from source independently, but their builds fail because they are missing all of matterhorn in their inputs. <ieure>lambdatronic, Well that's ludicrous, why are they even in their own repos if they don't work outside the matterhorn context? <lilyp>As a rule of thumb, try to avoid #:recursive? whenever possible. The fact that a git repository does use submodules is already an indicator that upstream puts weird shit in it, so you better look carefully at all the stuff you pull in. <ieure>Submodules are pretty much always a degenerate alternative to proper dependency management. <lambdatronic>I'm certainly not disagreeing with anyone here that these submodules are making this project's build a PITA. I'm just looking for any advice on how to proceed. <ieure>lambdatronic, I'm just trying to make sure that you truly have no alternatives. :) <lilyp>lambdatronic: for a practical example of unpack-after-unpack, see ppsspp, which unpackages tests that are given as a submodule <zilti>sarg: I did take a look at this, setting it to "$PATH:~/.local/bin", but I also just noticed that I didn't re-login after `guix home reconfigure`, so thanks nonetheless! <lambdatronic>My `ghc-matterhorn` package on line 696 builds correctly. This uses the latest releases of matterhorn, mattermost-api, mattermost-api-qc, and their (compatible) dependencies on hackage. <lambdatronic>Below this, I worked on the development package and have gotten stuck with this submodule issue. <lambdatronic>You can see my failing `ghc-matterhorn-dev` package on line 1056. <mfg>civodul: i guess, i'll have to wait until shepherd gains syslog functionality. Writing to files does not seem to help me (also i'm unsure what i'm doing so this makes it more difficult) :( <graywolf>lambdatronic: Does that command (guix build --sources ..) work for you? <graywolf>Using submodules with git@.. instead of https:// is next level... <lambdatronic>Hmm...I don't get the same output as you in this case. It looks like your `guix build` command is actually attempting to grab those submodules (with the evil git@ URLs). Mine doesn't even attempt that. <graywolf>Interesting. Are you sure I are trying the same version that is pushed to the repository? Also, what version of guix do you have (guix describe) <graywolf>For you it just build a source succesfuly, but it is missing the submodules, is that correct? <graywolf>geez, pastebin requiring javascript... what amazing age we live in <graywolf>anyway, guix build: warning: failed to load '(lambdatronic geosync)': <lambdatronic>Yeah. That's a WIP package that's not worked out yet. Not really meant to be publicly shared. <graywolf>Can you try to run the guix build -L . --sources ghc-matterhorn but in the way that will actually at least try to do something? :) <graywolf>If you look into /gnu/store/d6wk43vxm1w3nznscggiligbd915jbfb-git-checkout , the submodules are not there, correct? <lambdatronic>Sure. Usually when testing, I just place ghc-matterhorn-dev at the bottom of the ghc-matterhorn.scm file and run `guix build -f ghc-matterhorn.scm`. <graywolf>Yeah sorry, I am out of ideas. I have no idea why we get different results for the same (git-reference) :( <lambdatronic>So as I noted earlier, it looks like the two submodules aren't being downloaded. <lambdatronic>I don't know why you get a different output when building this package than I do, but your output suggests at least that the git@ URLs may need to be fixed with a `substitute*` call. <graywolf>lambdatronic: I somewhat doubt the *have* to be submodules, I would expect it to work as long as the directories exist and have correct content. So maybe take a look at what lilyp suggested. <graywolf>Likely will be easire than this approach. <dariqq>hi, is it possible that the issues page is not updating? <lilyp>we got that question like thrice today, yes it is :) <lilyp>mumi has to catch up with debbugs, which AIUI can sometimes be a very manual process <mfg>efraim: ah i didn't know that one, makes sense that i didn't get it then :D <mfg>efraim: a question regarding your config: do i need to have the screen-locker-service as a system service? this means i also need swaylock in the system profile, right? how about other programs such as sway itself? currently i have everything in my home profile, but screen-locker-service can't be used as a user service, or can it? <elevenkb> hello there, I can't chroot into a broken guix install. [22:29] <elevenkb>If I say chroot /mnt then I get "failed to run command <elevenkb> /gnu/store/...bash-5.1.8/bin/bash" no such file or directory. <elevenkb>If I say chroot /mnt /bin/bash then I get "failed to run command /bin/bash: No such file or directory." <cmiller>I am not sure but it seems that issues.guix.gnu.org interface is not updating anymore. Can someone verify that it still works? <elevenkb>yah, also guix pulls are really slow for me. <elevenkb>cmiller: the latest commit I see on it was published yesterday. <elevenkb>attila_lendvai: I tried those instructions first. <elevenkb>Nevermind about my chrooting. I probably will reinstall from scratch using herd start cow-store /mnt && guix system init config.scm /mnt (effectively). <apteryx>civodul: maybe we should sync master into core-updates to get our tooling to behave the same as on master <apteryx>e.g. the Change-Id: git trailer, perhaps some additions to teams or? <apteryx>civodul: ah, gnu/packages/base.scm (where glibc is defined) is not part of any teams <apteryx>perhaps it should be registered to the core team? <civodul>apteryx: ah, yes! or a separate ‘core-packages’ team? <civodul>also the scope of the ‘bootstrap’ team could include commencement.scm <apteryx>maybe core-packages although we already have such name for a target that checks packages like libreoffice builds, no[/ <apteryx>grepping around, I think that's use to produce NEWS, they are labeled 'important' <apteryx>so a core-packages team may be fine after all :-) <civodul>re merging, i thought about it, but now i’m a bit afraid of merging before this glibc upgrade goes in :-)