IRC channel logs
2024-04-02.log
back to list of logs
<apteryx>civodul: re wayland, did it break your system? <podiki>ACTION pokes berlin workers with an imaginary, very long, but insubstantial stick <civodul>apteryx: no, because i noticed the news after running ‘guix pull’, which is good :-) <civodul>perhaps the news entry should explain what to do for those who want to stick to Xorg <civodul>anyway i thought i’d try switching to sddm while at it, we’ll see how it goes <bdunahu>Does anyone use guix-emacs? I tried it awhile back on a fresh install--using commands like guix-all-packages just locks up the emacs process without finishing or producing errors, even on an empty config. <civodul>bdunahu: i use it and it works for me, but i’ve also customized it to use my local Guix tree, not sure whether that makes a difference <bdunahu>It might, though though there are no given configurations for the package (other than installing it), which makes me think it doesn't require any specific setup. Maybe this is a bug. <bdunahu>I only have issues with the package-related commands <blum>I'm intrigued by home-mcron. it sounds very useful <blum>anyone have some interesting use cases to share? <lfam>Removing code contributed to libarchive by the 'xz' attacker <jaft`>blum: not particularly interesting but I use it to keep my hard-drive's space down with #~(job '(next-month) "guix gc --delete-generations=3m"); but you're right it can be useful, especially if you're used to automating jobs via CRON, to begin with. <jakef>jaft`: do you know if the delete-generations option to gc applies to system, profile and home generations? <jakef>ah sorry, i just saw it mentions profile only <jaft`>jakef: No apology necessary; I didn't grasp that the command only cleared my default install generations for the longest time. I can't speak to home generations but, like you caught, that command will only clear generations from your default ~guix install~ commands. To clear system generations, you'd want (for a similar command) "guix system delete-generations 3m" (though likely with ~sudo~). <Guest69>I have a guix system where the grub files and the kernel(s) have disappeared from the /boot partition. What is the guix-y way to fix this? Normally I'd install grub and a kernel manually to get booted again but guix normally handles this - any ideas? <jaft`>I haven't checked but I'd wager a guess that ~guix home delete-generations 3m~ would target your home generations. <redacted>I messed up my networking configuration on my server, but I can't `guix system roll-back` without the network. Does guix have earlier generations cached at all, and can I roll back to them? <lfam>Yes, you can select your generation from the GRUB menu at boot <redacted>Hmm, I'm not sure I can get to grub through my VPS provider's web console. <lfam>Try `guix system switch-generation` <redacted>lfam: switching generations tries to fetch substitutes, which fails without the network. I'll let it finish to see what happens though <lfam>Then you can manually adjust the symlink <lfam>Manually adjust the symlink '/var/guix/profiles/system' to point to the desired generation, and reboot <lfam>Guix "profiles" and "generations" is basically a bunch of machinery to manage these symlinks <redacted>That appears to have had no effect. I'm double checking to make sure I did it right. <lfam>Hm, could be the system generations require some manual activation, unlike user profiles <lfam>You could also fix your network in the normal way, and then adjust your declarative configuration <redacted>yeah, it looks like I'll have to figure out why my ip route command aren't working. <redacted>What is the function of /run/current-system? <lfam>It's basically the result of "activating" the system profile. It's been a while and I forgot that this was necessary <lfam>You can't merely swap symlinks to make the systems effective <lfam>But, I don't remember the details well enough to explain it in more detail effectively <wakyct>the binary link downloads OK. Hurd link also seems broken. <zamfofex>wakyct: It happens from time to me, from what I can see. <zjabbar>The new Linux version fixed a color issue with GDM on my computer. Loving life! Thank you to all FOSS maintainers. <jakef>zjabbar: hey me too! GDM background used to be red. fixed now <x4d6165>I'm having trouble getting libcrypto working in sbcl on GuixSD. I have a shell set up with openssl installed but installing, for example, drakma, via quicklisp results in a libcrypto not found error <podiki>x4d6165: perhaps try the guix package? e.g. guix shell sbcl sbcl-drakma should work together <podiki>packages from quicklisp likely won't know where to find libraries <x4d6165>ahh i see, i wonder if there's a way to inform quicklisp of these libraries in the case of unpackaged quicklisp packages <iyzsong>in the guix shell, which has openssl and gcc-toolchain, it setup a LIBRARY_PATH env which contains libcrypto.so. if compile lisp package doesn't look for the library itself without use that env, it will fail. <iyzsong>if the lisp package use some kind of ffi / dlopen, it usually use LD_LIBRARY_PATH <futurile>Morning all - don't forget there's an online patch review / social hanging out session tonight! <mekeor>how can i update all package source hashes of a module in-place? <adanska_>fururile: wheres the details for the meetup? <adanska>futurile: wheres the details for the meetup? <adanska>guess ill give it a pass unfortunately <futurile>adanska: ah sorry about that - timezones suck etc <mekeor>ACTION just wrote an emacs keyboard macro for updating hashes, basd on shell-command-to-string and 'guix download' <Guest26>Hi guix! I'm just playing with guix on a foreign distro (Debian bookworm, guix installed via apt), but have some troubles. Once I run 'guix pull' I receive: https://paste.debian.net/1312775. I remember having running the guix package manager on Debian a few weeks ago, but never became really comfortable with it compared to my guix system at home, <Guest26>so I uninstalled it again and removed /gnu/store as it didn't 'autodeinstall'. Is it possible that remainders from the previous installation interfere here? If so, which places should I look at? <futurile>Guest26: I don't know what the debian package does on 'uninstall' but sounds plausible. You could try doing `guix gc` as root/sudo as that will clean the /gnu/store <Guest26>futurile: thanks -- it seems to be /var/guix! I just uninstalled, removed /gnu/store and /var/guix and reinstalled, now pull seems to work as I know it! <futurile>Guest26: also - a side note - if you install Guix from the debian package AIUI when you do a 'sudo guix pull' you won't land-up with the latest version of the package *unless* you change the daemon location that is being used in the systemd unit <futurile>Guest26: this means your daemon will be a bit behind - I can't find a link about this - but it's a discussion on IRC sometimes <futurile>Guest26: it's because the package (obviously) points to the daemon that's in it AFAIK <Guest26>futurile: good to know. I will check in a minute. I'm not sure about guix on a foreign distro anyway yet, I'd just like to try 'guix deploy' onto a guix qemu machine I have running on this computer here. <Guest26>As it's somewhat stronger than what I have at home :) <futurile>Guest26: yeah, I use Guix as a foreign distro on top of Ubuntu. It works well for me, but you are using 'another' package manager on top so you have to have a clear separation in mind. I basically have 'ubuntu-minimal' / system-utils from Ubuntu. All my 'day-to-day' stuff from Guix. <efraim>auditing crates for yanked packages is not fun <efraim>I think for versions where there is no non-yanked version I might make rust-foo-0.x a deprecated package of rust-foo-0.x.y-yanked with a note that there are no non-yanked versions, and then see if that triggers a warning during build <efraim>oh man, this one is even better. there is no release of partial-io@0.2 at all! yet we have it <futurile>efraim: in the second case did they 'yank' it, how did we get the 0.2? <efraim>I think I'm going to have to go through the git history to see if something got lost when we added newer versions. Normally yanked versions still exist but are marked as yanked <Guest26>futurile: thanks for the info! do you then install packages also prefixed with 'sudo -i'? I'm just wondering, as 'sudo -i pull' will pull everything pulled by a 'normal' 'guix pull'. I have to twist my head a little as on guix system I'm using sudo only to rearrange the system configuration (and it will use the user's guix then anyway)? Are <Guest26>there downsides on leaving the daemon as-is? <futurile>Guest26: a key thing to understand is that you have the store (/gnu/store) and you've got a daemon running (from a systemd unit). You should update the daemon (sudo -i guix pull; restart the daemon), and then for each user you also do guix pull. There's not one 'apt database' - it's a 'per user' listing. <futurile>Guest26: you don't install packages into root - it 'just' has the daemon in it - and the systemd unit refers to it /root/.guix-profile/something <futurile>Guest26: so under normal circumstances I update my daemon (root one) once a week and restart sytemd; then I do guix pull in my user account etc, install any new stuff I want in there <Guest26>futurile: perfect, thanks for the workflow! <h3>jpoiret: How to know if it's on the bugtracker? The mailing list indicate "Open QA Unknown" "pending wishlist tags security close quit" <h3>How to set `ungoogled-chromium`/`icecat` organization policy plug-ins/add-ons in /etc/config.scm? How to know what happened to a patch/bug/commit from Guix mail lists? Like if it was merged somewhere, appeared somewhere, if it was only on that mail exchange? And if it's only on the mails, how to apply them all to have the actual work done to execute it? I try to insert a package into Guix channel to test it with `guix shell` before pushing it but all I get is that the <h3> package is unkown. How to make it known by Guix? <thaenz>h3: To your last question you could maybe use -f flag in guix shell <futurile>h3: if you email help-guix@gnu.org I'll answer your questions there - we actually need more information from you, like how you've set-up your 'channel' <Guest26>idea what could be going wrong here? <janneke>ACTION goes to look if they can produce a patch for reproducible source tarballs <h3>thaenz: Can you explain why shouldn't I load guix.scm and manifest.scm? I've used `GUIX_PACKAGE_PATH=$the_actual_path_where_all_the_other_upstream_guix_packages_are_along_with_the_new_one_I_ve_injected guix shell`. And it seems to considerate about that new package, complaining when the hash into it isn't the right format, but other than that nothing. When you correct that, it stops complaining about the new package but don't seem to acknowledge it neither. Like `$the <h3>_actual_path_where_all_the_other_upstream_guix_packages_are_along_with_the_new_one_I_ve_injected/the_new_package.scm:10:12: avertissement : invalid content hash length`. But dissapear when corrected <h3>futurile: I've already tried mail list. And not only of Guix. Through all my life I've never received any answer whatsoever. Not even negatives ones. It seems to be really for professionnals to discuss about bugs and that's all. But if that mail list is alive and beginner friendly then I'm willing to try <futurile>h3: give it a try plesae - I honestly think it will be easier to help you <Guest26>Is it possible that guix deploy currently ignores (port ...) from the machine-ssh-configuration? <Guest26>Or is there a way to make guix deploy more talkative (my target machine does not notice connection attempts looking at /var/log/messages and /var/log/secure)? adding '--debug=2', or '--verbosity=2' does not yield more information than 'SSH connection to 'localhost' failed: Connection refused'. This is what I get if with 'normal' ssh on a port <civodul>Guest26: hi! it’s definitely supposed to honor ‘port’ <civodul>it cannot be made more talkative but in doubt you could strace it and look for ‘connect’ calls <futurile>Q: anyone know what this error means: guix shell --container --nesting --development guix -> guix shell: warning: could not add current Guix to the profile <civodul>futurile: sounds like ‘--nesting’ is not working as expected <civodul>how did you achieve this? ./pre-inst-env? <civodul>usually that means ‘guix’ cannot determine its own provenance, and thus it cannot add itself to the container’s environment <futurile>hmm it's this set-up I'm trying to automate for the patch review - so I've created an instance on digital ocean using ansible - clearly someting is 'off' <efraim>futurile: I think we have digital ocean as an option for guix-deploy <futurile>freakingpenguin: oh cool - yeah that might be the way to go - cool <bjc>how do you get logs out of the shepherd these days? <bjc>“herd log” doesn't work <bjc>and ‘herd status’ doesn't show anything <Guest97>(formerly Guest26) OK, got it. Setting ~host-name~ to '127.0.0.1' starts the process :) <Guest97>Probably a problem with my Debian host's /etc/hosts which mentions '::1 localhost ip6-localhost ip6-loopback'... <podiki>Berlin still isn't building anything 😞 <podiki>there was some investigation yesterday around db queries as well (previously cuirass got stuck and needed a good vacuum) <podiki>but i don't know what is going on here <podiki>i pushed mesa-updates err updates a day and half go, the evaluation got canceled at some point, restarted it, no builds have been scheduled or done <civodul>podiki: it was ‘cuirass remote-server’ that got stuck because of the bug above (it received bogus messages, probably port scanning over there) <civodul>keep and eye on ‘mesa-updates’ and ping us here if it’s not picked up <ieure>I'm trying to package two Python scripts that depend on pycryptodome, but they can't find the module. These are bare scripts, no pyproject.toml / setup.py, so I'm using copy-build-system. Presumably python-build-system makes some kind of wrapper for this? If anyone can point me at prior art for a similar setup, I'd appreciate it. <ieure>When I run either script, they die with ModuleNotFoundError for the Crypto module, which is part of pycryptodome. <apteryx>civodul: glad the cause of the hang is already documented/understood; thanks for pointing it and restarting remote-server <civodul>apteryx: np, apologies for not noticing the discussion earlier! <civodul>usually, when the build queue remains empty, i first go to cuirass-remote-server.log to see what’s up <podiki>civodul: thanks! Seeing some action from mesa-updates, will keep an eye on <ieure>I assume "something to do with gexps," but it sure feels weird that you have to do it like that. <ieure>If I don't double-quote there, it tries to eval ("./sign.py" "bin/thinkpad-uefi-sign") and blows up. <freakingpenguin`>ieure: Outer quote so host doesn't eval it, second quote so it's quoted in the derivation builder? I think the outer quote could be replaced with a gexp and function identically. <freakingpenguin`>ftest has #:install-plan #~'(("ftest.h" "include/ftest/")), builder for the derivation has (quote (("ftest.h" ...))). <podiki>guix offload: error: preallocating file of 36423 bytes: No space left on device <podiki>(have to run, will check back on mesa-updates builds tonight) <bjc>is anyone using libvirt/virtual-machine-manager? <bjc>i'm getting “Failed to setup UEFI: Did not find any UEFI binary path for arch 'x86_64'”, so can't install anything <bjc>i tried installing ovmf separately, but it didn't work <bjc>this worked a while back, but i guess something changed? <janneke>$ cmp ../x/guix-1.3.0.57398-9c87f.tar.gz . <ieure>janneke, Is it? I get the same behavior on a non-Guix machine, and the cmp(1) man page says "compare two files" -- so I'd expect giving it a file and a directory would be an error. <janneke>ieure: i'd expect the same behavior as diff <janneke>why do i need to type the same file name twice, it's -- well -- a broken ui <janneke>│ │┄ xxd not available in path. Falling back to Python hexlify. <ieure>janneke, cmp {../x,.}/guix-1.3.0.57398-9c87f.tar.gz <janneke>ieure: thanks, that shows me a reason why cmp's ui could have stayed broken for decades <janneke>ACTION pushes some patches to wip-tarball, but alas, for guix there's a lot more to be done <ieure>janneke, The likely reason it doesn't have the feature you desire is that its behavior is defined in the POSIX standard, which explicitly states that it "compares two files" and the arguments are "A pathname of the (first|second) file to be compared." Your desired behavior would make it nonconformant. <janneke>ieure: don't we have POSIXLY_CORRECT for such ridiculous pedantics? <apteryx>but I'm getting 'ERROR: 1. &non-continuable' <apteryx>looks like (search-error? ex) doesn't evaluate to #t as I'd expect <cbaines>more of a #guile thing, but passing #:unwind? #t to with-exception-handler should solve that <efraim>glib-2.78 failed one of the tests on powerpc-linux <cbaines>the non-continuable error is happening because with-exception-handler by default doesn't unwind the stack, but the exception being handled is marked as non-continuable, so you have to unwind the stack <apteryx>interesting, pk shows (search-error? ex) is #t, so I'd expect the computation to return #f, not a &non-continuable error <apteryx>I meant to ask this in #guile though <cbaines>in the situation you describe, the handler will never be evaluated <cbaines>at least that's my understanding of the behaviour <cbaines>I've only really used with-exception-handler with #:unwind? #t <janneke>civodul: pushed some reproducible tarball work to wip-tarball, but for guix this needs more work <efraim>ok, I give up. I just got 180 patches in the past 20 minutes for more rust stuff. Patches now might not be applied in the order I receive them <efraim>does anyone have a 1-liner to count the number of commits by author over a series of commits? <efraim>ok, I might've gone overboard over the past 3 weeks. Apparently in that time I reviewed ~220 patches for rust-team and authored another 730 myself. <apteryx>cbaines: I was hopping to avoid adding srfi-34 to #:modules everytime I want to handle a condition, but with-exception-handler is not exactly succint. <cbaines>apteryx, did it not work with #:unwind? #t ? <lilyp>efraim: Micro-packaging sure helps being productive, right? :) <efraim>its certainly something like that <apteryx>cbaines: I guess I'll get used, but #:unwind? #t is likely to appear every time I use it, along encapsulating the code to protect in a thunk <apteryx>SRFI 34's guard seems a nicer (compact/convenient) API for the common use case. <efraim>on the upside, we have only about 10 crates packaged which have been yanked, and something like 75% are at their latest release, with only like 5% being "far behind" their latest semver-apropriate release <lilyp>not too bad, considering that half of rust is on a critical path <blum>i installed gcc-toolchain but compiling any c program gives "ld: cannot find crt1.o: No such file or directory" <blum>ahh i think i need glibc :^) <blum>hmm still notworkin i'll take a look at gnu hello and see what deps that needs <apteryx>gcc-toolchain should include all you need <blum>hmm problem is only in emacs, just gotta refresh env vars ig <mccd>Heya, I'm having some trouble with building Guix. When running ./configure it's complaining about the lack of acceptable C compiler in path. I ran guix shell -D help2man git strace gcc-toolchain make --pure, but it's still not working. <mccd>I suspect that something is wrong with the path <mccd>Though in my zshrc I have export PATH=/home/marc/.config/guix/current/bin:$PATH and GUIX_PROFILE="/home/marc/.guix-profile" so not sure what more is needed. <cbaines>mccd, do you want the development inputs of help2man, or help2man itself? <mccd>well what I want is to be able to run ./configure in the guix repo without fail <mccd>I think help2man is a build dependency <cbaines>right, so you want help2man, rather than the build dependencies of help2man <cbaines>mccd, I think way guix shell is intended to be used, you would run: guix shell -D guix <cbaines>(as in give me a shell with the development inputs of guix) <mccd>ah yes, now suddenly ./configure worked haha <freakingpenguin`>Is there a downside to setting GUIX_LOCPATH on guix system? I have a home environment I want to deploy on both guix and foreign distributions, figure I'd have the HE install glibc=locales and set GUIX_LOCPATH. <podiki>ERROR: Clock skew detected. File /tmp/guix-build-libmanette-0.2.6.drv-0/build/../libmanette-0.2.6/meson.build has a time stamp 16293162.8206s in the future. <podiki>I'll try to restart later, unless that is some actual build issue? (no updates to any build tools on that branch though) <podiki>something like a 6 month time jump.... <podiki>that's enough of a time jump (if it actually happened) where i would think certificates would not be valid <podiki>but this is in the build process, so not sure what time it is seeing <lfam>I'm not sure if TLS is used with the build nodes <podiki>i just meant if there was an actual time jump, i would have thought something like source fetching would fail on a certificate invalid error <lfam>Not sure how to access those machines. Maybe rekado can check if hydra-guix-128 has a correct-ish date <podiki>how is the build process seeing a time jump on a build file? aren't they all set to 1970? or is that in the writing to store phase? <lfam>IIRC, some aspects of downloading within Guix ignore TLS certificate errors, since they don't affect authenticity. But I don't recall exactly where this is <podiki>if it is that machine then i would guess all the ninja meson builds will fail with that error on it. guess we'll see <lfam>git grep 'verify-certificate? #f' <lfam>I think we should check the clock <podiki>makes sense as the first easy thing to do <podiki>(i don't have access to those machines; and also have to go shortly but will keep an eye out) <lfam>The system date is correct <lfam>I mean, I figured out how to log in <lfam>So, something else is funny <podiki>the libsoup failure is a time difference of over 3 years <podiki>the changes on that branch are cairo, libdrm, mesa, vulkan, sdl2... and current with master as of about 2 days ago <podiki>so no build system changes or anything like that <lfam>Yeah... did some code expire? <lfam>Weird that it would only manifest on this machine, right? Do it seem to be? Are the machines building too? <podiki>not clear from the error what is tripping up, meson i guess? (both are for meson.build) <podiki>from my quick look at new failures on mesa-updates, only those 2 were clock errors <podiki>i built a lot locally, but not everything, and was a day or two ago <podiki>i guess can check one of those builds locally to see if it is a true time bomb? <lfam>Is it going to be too expensive for you to build? <lfam>I could build it "by hand" on a powerful machine <podiki>i can't build until i'm home in a couple of hours, but i should be fine <podiki>i built through mesa, vulkan, some graphical programs before I pushed the other day <podiki>curious! i wonder if it will be some fun (but not too annoying) bug <lfam>I googled the "clock skew" message and it seems to be a common issue with meson. No idea what it means nor am I inclined to learn about it. Why the time should ever matter... <lfam>And people ask why distributions exist :) <podiki>meson is some versions behind too <podiki>let me know if you find anything, or if someone else happens to know <podiki>I gotta run and will try some builds locally when I'm back <podiki>i go ever forward to the future, 1 second every 1 second