IRC channel logs
2023-05-12.log
back to list of logs
<acrow>I don't see an issue opened yet; but something has gone awry with emacs. Changing to org-mode or ledger-mode triggers a no space on device error while trying to open a /tmp/babel- custom directory. Hmmm... Anyone else see it? or am I an example of a PBK guix error? <acrow>PBK error it appears to be. I am shamed. <mirai>From: bug-guix but reply to jpoiret <Hutzdog>Hey, I'm quite new to Guix (been looking for a freer system than NixOS after finally getting a graphics card which uses mostly free drivers [previous purchases were horrid mistakes I intend to never repeat]) and was running a test of the new version of my config layout (splitting up configuration amongst hardware specific configuration, systemwide <Hutzdog>software, and user specific software) but keep running into ice-9/eval.scm:223:20 errors mentioning the compose-system variable as being unbound (suggesting I put the module which contains it in a use-modules declaration despite me doing so 2 lines earlier). I have no idea how to debug Guix and Guile, and was wondering if anyone sees anything <Hutzdog>glaringly wrong with my configs. The build command is ./scripts/guix-wrapped.sh system build ./out/configs/soyuz.scm (after the first rocket to reach orbit) in the repo https://git.sr.ht/~hutzdog/guix-dotfiles/ (yes, I do still need to add the license headers). <iyzsong>Hutzdog: try 'guix -L' instead of 'GUILE_LOAD_PATH'? I think guix will override it with its own load-path. <Hutzdog>iyzsong: It appears to raise the same error, sadly. It seems to know about the module but not the (use-modules) that uses it <iyzsong>you can debug it with 'guix repl', in it use the module, and to see if 'compose-system' is available <Hutzdog>Hmm, looks like one of the syntax-rules declarations is cusing errors that prevent the module from loading. <Hutzdog>Decided to drop the syntax-rules, and now am debugging my new record based implementation (which I should have used in the first place). <ulfvonbe`>anyone else having tests/pypi.scm failing? Apparently the hashes in the package forms generated by pypi->guix-package differ in 'pypi->guix-package, no wheel'. I think tar is doing something screwy with timestamps again... <ulfvonbe`>... and now I can't get it to fail again. Dang heisenbugs... <Hutzdog>It's 12:30AM and my initial Guix system finally is building (it only has system-wide configuration at present, but it proves that at least 2/3 of my configuration "framework" actually works) <ennoausberlin>Hello. So far I use guix mostly for private development. But two months from now, I will try to implement some kind of process for a bigger team (20+ developers). My main concern is the synchronization of different parts of the project. Do you have any experience here? How often do you push updated package definitions und do you freeze guix main <jpoiret>ennoausberlin: do you want to know how stable Guix is, or rather what's Guix's process to avoid broken builds in general? <janneke>ennoausberlin: what we do is use time-machine and pin on a commit, so that substitutes can be shared <jpoiret>nutcase[m]: you can remove help2man from that `guix shell`, it's not strictly needed. Someone™ probably needs to fix that bug. <ennoausberlin>jpoiret: Guix is usually stable (the core-updates merge didn't cause too many problems for me). It is more how to avoid broken builds. BTW: The more button on the issue tracker gives http 500. <ennoausberlin>jpoiret: time machine looks like the way to go. The --channels option of the time machine command let me specify project specific channels than? <jpoiret>yes,`time-machine` is to `pull` what `shell` is to `package` <jpoiret>well, rather you can also use pull and specify a specific commit in the channels.scm file <jpoiret>but do note that it might make it harder in the end to upgrade <jpoiret>if you're only doing it every few months <ennoausberlin>jpoiret: I will try both ways and decide. The biggest problem is probably to tell the Python guys not to include a lot of dependencies for simple tasks. There is a library for everything in the Python world, but you create dependency hell if you are too careless <jpoiret>nutcase[m]: I can reproduce, i'll try to send a patch for this shortly <jpoiret>in the meantime removing help2man from the shell invocation should be okay <jpoiret>what's everyone's `guix build --derivations qtbase@6` with the latest guix? <jpoiret>the derivation i get is nowhere on CI <cbaines>ci.guix.gnu.org doesn't build with grafts, so if you want to compare derivations, you should probably compute them without grafts locally <jpoiret>yes, that's what I just checked (doesn't change anything weirdly enough) <jpoiret>i get `/gnu/store/z8n528hz0xxslf9bd5qk3jfnzsf21vq5-qtbase-6.3.2.drv` <jpoiret>cbaines: ah, so it's built on bordeaux, great! <cbaines>looks like it, so a substitute should be available <cbaines>(we're assume x86_64-linux of course) <jpoiret>both of these derivations are from the same day <cbaines>given the outputs are the same, what this generally reflects is some change to a fixed output derivation deep in the graph <cbaines>because the fixed output derivation output is unchanged (as it's fixed by definition), this doesn't affect the outputs of dependent derivations <ennoausberlin>jpoiret: There was no substitute for qtbase@6 the last two days. <cbaines>but it does affect the derivations themselves, since they reference other derivations using the name of the derivation <jpoiret>cbaines: ahh, but it does affect the drvs <cbaines>ennoausberlin, there should be substitutes now though, at least for x86_64-linux <sturm>did anyone else lose gnome-terminal from their profile a while back? I have gnome-desktop-service-type installed, but no longer seems to include gnome-terminal <jpoiret>I think gnome-terminal has been replaced by something called Console <sturm>ah, thanks jpoiret. I've been using Console, not really knowing for sure, but happened to install Debian Testing yesterday with a slightly newer Gnome (43) and notice it still uses Gnome Terminal. <jpoiret>Yes, apparently some downstreams didn't like it and kept terminal <jonsger>did core-updates merge change some standard fonts? The fonts used in my UI (e.g. sway or icedove) look slightly differennt then before <jpoiret>it might be the font rendering libraries instead <jonsger>hm dmenu is broken for me, since I rebooted some minutes ago :( <jpoiret>janneke: it's been fixed on HEAD and I think ludo tried to boot it with the newer guile to no avail <jpoiret>oh, I might be wrong on this, thought it was another bug <jpoiret>I'll try to download a Hurd VM and build guile on it <janneke>ACTION tries to revert to guile-3.0.7 for hurd only, but still using 3.0.9 in many places -- grmbl <attila_lendvai>janneke, this way that target-hurd? call happens at module load time. <cbaines>janneke, there's define/system-dependent in commencement.scm which might help <janneke>cbaines: neat...but i have no success trying to use that for guile-3.0 (unbound errors) <wingo>dumb question: given a git repo and a commit hash, is there a simple way to compute the guix hash? <wingo>i used to know the answer ;) <jpoiret>wingo: checkout the repo, then guix hash -rx . <jpoiret>I don't think we can compute the guix hash from the git blobs directly <futurile>jpoiret: congratulations on becoming a committer <jpoiret>civodul: ah, so I guess I just installed Debian/Hurd in a VM for no reason then :( <jpoiret>can't seem to cross compile the current guix package to Hurd, it seems stuck on translating cross-references in the doc <jpoiret>civodul: is cross-compiling guix supposed to be very slow? <Guest85>Bit of an emergency atm. My encrypted Guix install won't boot. <Guest85>It had been running for several weeks and updated a few times. I don't think I was using the stable branch. <Guest85>~2 nights ago the ethernet stopped working... tried multiple eth ports and usb tethering but none worked. <Guest85>I decided to reboot to see if that helped, but both 'sudo halt' or 'sudo reboot' failed saying something like 'root service is not running'... never seen that before. 'su' also failed but it looked like the same error as a failed password. <Guest85>I rebooted and now I cannot get into the cryptroot login screen; after bios it just shows a terminal cursor about 1/3 from the top & left. <Guest85>how do I debug a encrypted drive that cant even login <Guest85>idk if I'm looking at grub or what... just a blank terminal with a cursor. pretty sure grub is after the first cryptroot unlock <cbaines>I'd maybe try booting a live system (e.g. the Guix installer) <cbaines>that'll hopefully give you some more information <Guest85>I'm sure a solution would involve a live system... but no idea what to look for. I'll try to find tools for this. <cbaines>even just seeing if a live system will boot will give you some information <cbaines>then it would be useful to know if it can access the storage devices <Guest85>it should be able to access the unencrypted ones... <civodul>jpoiret: well, "supposed to" is a strong word; it's not a design goal :-) <jpoiret>civodul: I was wondering if there was a good reason for it to be slow but I guess because it's because we can't load the compiled files, for example (guix build po) which is used by the build process <janneke>yeah, there are warnings about .go files being of the wrong type (64bit i guess) <apteryx>(from bug-guix but reply to original author ?) <attila_lendvai>i'm getting a Gateway Time-out from ci.guix.gnu.org while attempting substituting in a build <mirai>apteryx: it used to show X via guix-patches (or bug-guix, etc.) via … <mirai>I still see “Josselin Poiret via Guix-patches via <guix-patches@gnu.org>” for the recent #63461 <chomwitt_>i managed to make X start without using xinit or startx. <chomwitt_>i wonder if i could make a 'service' out of it. 'vanilla-X11-withnologinmanager-custom_xorg_conf' <chomwitt_>i mean i have no idea! but it would be cool. <civodul>jpoiret: yeah, we end up interpreting most of the code i guess <janneke>fwiw, /me just runs (system* "/hurd/mach-defpager") in the gnu.repl and it just hangs <janneke>just like what pk-debugging suggested <civodul>janneke: yes, that was my recollection <civodul>and in kdb we don't see the corresponding task IIRC <janneke>i've copied this guile to the pre-core-updates merge childhurd, and verified that system* works <chomwitt_>it could become a minimal - bulletproof - bare - X setup. <civodul>at the REPL you could try (spawn "/hurd/mach-defpager" '("/hurd/mach-defpager")) just in case <janneke>civodul: spawn also hangs -- same difference :-( <superkamiguru>Has anyone here successfully built and used an aarch64 installation image? I have the iso working in qemu, and can install to an empty qcow2, but once I remove the -cdrom tag from the script I get an error trying to find the bootloader <efraim>I always generate an image for my device and then flash an sdcard or emmc <superkamiguru>So I have generated a working aarch64 vm image following some nice documentation by n8henrie, but the problem is the generated image doesn't have an /etc/config.scm that I can use to reconfigure the image. I thought building the installer and installing to a blank image would work (which it does on the first reboot), but after removing the <cbaines>that I can't really help with, I've used the installer for aarch64 hardware, not a VM <superkamiguru>No problem, I appreciate the reply! Just trying to figure out how to get a working guix environment under qemu on an m1 mac <superkamiguru>cbaines, when you generate an installer image for aarch64, have you received an error regarding a missing logo.txt file? I had to roll back to a pretty old version of guix to get the installer image to build correctly <cbaines>nope, I don't remember any error like that <superkamiguru>Ok, I keep getting that error on newer versions on guix. Thanks for the help btw! <cbaines>feel free to send the commands you're running and the output/error to bug-guix@gnu.org <superkamiguru>Oh awesome, I will make sure to do that. Another question, should I be building the installer image from /gnu/store/...guix-1.4.0/share/guile/site/3.0/gnu/system/install.scm or should I be using a different directory? <cbaines>I usually built it from a guix.git checkout <superkamiguru>Should it matter if I am doing it on guix or a foreign distro? <civodul>apteryx: hey! i looked at system tests recently, and the Jami tests are failing for reasons i didn't understand; could you take a look? <civodul>janneke: does 'spawn' return or not even? <apteryx>jami hasn't changed a bit so I'm guessing something shepherd side <mirai>should stripping be explicitly disabled if the package build system enables it by default? <civodul>janneke: how about (primitive-fork)? does it return? <jpoiret>I'm getting an `start ext2fs: ext2fs: device:hd0s1: panic: get_hypermetadata: bad magic number 0 (should be 0xef53)` personally <ngz>civodul: OOC, what would characterize a successful "tex-team" branch ? <jpoiret>ah, I forgot that you need the `hurd-raw` format :) <jpoiret>well, I should just learn to read, we do have hurd-qcow2! <janneke>scheme@(guile-user)> (primitive-fork) <jpoiret>right, so it's probably the spawn implementation that relies on some features that aren't available yet <civodul>or it's the exec server that's failing somehow? <jpoiret>looks like there's some authentication business going on there, but the auth server isn't up yet <civodul>ngz: it should be relatively current (so rebased on post-rust-team master) and the same success rate as master or close to it <jpoiret>the spawn code seems to be doing much more than just fork + exec <jpoiret>civodul: spawn would return in that case <civodul>wait wait wait, the comment in spawni.c mentions /libexec/spawn-helper <jpoiret>that's just a proposed solution that's not implemented if i read that correctly <ngz>civodul: OK. But do we have to wait for all the builds to complete? ATM, there are only aarch64 builds waiting, but 5k of them. <civodul>do see if good'old fork+exec works better than posix_spawn <civodul>ngz: i'd say we can check x86_64 for breakage (since that's all supposed to be arch-independent), and then wait until aarch64 has caught up a bit, but not entirely <cbaines>ngz, I'd post core-updates we've had two big changes (mesa and rust-team), but at some point we need to pause to wait for the build farms to catch up <cbaines>I'd like to wait now for the build farms to catch up before merging the next big change <ngz>Sure, let's wait. The thing is I have another massive world rebuild coming up, as the next tex-branch. :) <janneke>civodul: no only in the "hurd" package <jpoiret>I'm trying with a bare primitive-fork + exec <jpoiret>if getting the pager to run is the only thing that's preventing us from using spawn <civodul>i don't think we actually have a guile-3.0.7 package <civodul>left as an exercise to the reader ;-) <jpoiret>nope, doesn't get much further. It does go to the boot script but hangs the same <jpoiret>also mach-defpager doesn't appear as a task <civodul>could be that it exited, or that it never started <attila_lendvai>damn, this is biting me again, and i forgot why: guix pull gets the latest commits, but then a `guix system reconfigure` wants to roll back to some old commits... this is as root. any hints? /etc/guix/channels.scm looks fine. <jpoiret>attila_lendvai: what command lines are you using? <jpoiret>you're saying "this is as root". Which user do you pull as? You don't need to ever pull or log-in as root to reconfigure <attila_lendvai>jpoiret, nothing unusual, just a `guix pull` and then a `guix system reconfigure my-config.scm` <attila_lendvai>jpoiret, i'm pulling and reconfiguring as root, because otherwise i get files created by root in my user's home... which reminds me that it's probably due to sudo -s leaking stuff into root <attila_lendvai>yep, it's `sudo -s` vs. `su -` (the latter works as expected, the former uses my non-root user's environment) <attila_lendvai>no idea why it's not biting me on my other machine, where i'm doing the same regularly. maybe i pull often enough with both users not to notice... <attila_lendvai>either way, it would be nice to set up some guards that this doesn't happen when i accidentally use sudo -s. can i do something? <jpoiret>I would rather say the opposite: if you want the new user's login environment, use `sudo -i` <jpoiret>the recommended method is to `guix pull` as your own user then `sudo guix system ...` <janneke>civodul: so yeah, your patch gives us guile-3.0.7 in boot-hurd-system <janneke> (unless (zero? (system* "/hurd/mach-defpager-XXX")) <janneke> (format #t "FAILED...Good luck!\n")) <attila_lendvai>jpoiret, i was trying to do that as suggested, but i got repeated permission denied errors when i wanted to do something with my normal user. after a while i gave up. <janneke>fails gracefully, printing FAILED...Good luck <jpoiret>attila_lendvai: do you use `(current-guix)`? <attila_lendvai>jpoiret, that `sudo guix system ...` creates files into my user's home owned by root <janneke>but trying to spawn the actual "/hurd/mach-defpager" still hangs <jpoiret>janneke, civodul: so basically we can't create any processes ourselves for some reason <attila_lendvai>jpoiret, i don't remember. maybe some compiled .go files in some cache. <janneke>jpoiret: well, primitive-fork works... <janneke>but yeah, something looks pretty broken, and it's not guile-3.0.9 <jpoiret>can you display anything from there? <attila_lendvai>jpoiret, i don't know what's (current-guix), so i think i'm not using it <janneke>jpoiret: sure, i'm instrumenting hurd-boot.scm with PKs <jpoiret>I just tried the old (match (primitive-fork) (0 (begin (display "hello") (exit 0))) (_ #t)) <futurile>has anyone seen a situation that whenever you start a guix shell --container certain binaries will not execute? I've downloaded a binary which I can use in my normal environment, I can use it in a 'guix shell coreutils', but when I do `guix shell --container coreutils` it will no longer execute. All I get it 'sh: ./btm: No such file ore directory' <jpoiret>futurile: you're missing some libraries in the container <jpoiret>No such file or directory can be raised by the dynamic linker when it doesn't find the libraries the executable is linked against <futurile>ah, OK I was expecting something more informative so have been getting twisted up <attila_lendvai>jpoiret, FYI, i couldn't reproduce. i guess i'll try once again using `sudo system reconfigure ...`, maybe i messed up something in my early days. <podiki[m]>I think the matrix bridge is relaying both directions again \o/ <grim`>Hey. Please, could someone give me a hint on how is the RUNPATH python errors fixed? I'm sure something is missing on the derivation I'm making. On which inputs should gtk+ go for the runtime to find it. <grim`>`validating RUNPATH of 1 binaries in "/gnu/store/...-automathemely-1.3/lib"... <grim`>for now I'm just using propagated inputs like so `(propagated-inputs (list gtk+-2))`. <jpoiret>grim`: there's literally an executable file in that repo, it should be rebuilt from source <jpoiret>there's a comment at the top of its source for how to build it <jpoiret>also that repo hasn't seen a new commit in 4 years <grim`>Sorry I'm not in the same page, what are you refering to? The missing .so gtk lib? <grim`>or the automathemely plugin for xfce? <grim`>this is what i was doing for compiling from source from source: paste.debian.net/1280084 <foxfromabyss>succeeds for `use-modules`. Kinda at a loss here and would appreciate getting pointed in a direction <grim`>foxfromabyss: you will need to load the guix modules on the geiser repl <jpoiret>grim`: i was saying there's a precompiled binary, with accompanying c source, straight in the git repo <jpoiret>And that's why you get this problem, if you build it from source it should work <grim`>what is a binary doing there...? Thanks for the hing jpoiret <superkamiguru>I have a guix qcow2 image generated from the "guix system image" command, but noticed that the resulting installation doesn't have an /etc/config.scm file. Is there another spot I should be looking for a relevant config.scm file? <jpoiret>superkamiguru: /run/current-system/configuration.scm <jpoiret> /etc/config.scm is just where people usually put their config, but it's not enforced by guix at all <superkamiguru>jpoiret Thanks! I figured it was stored somewhere but just couldn't find where it was <ekaitz>jpoiret: congrats! you deserve the commit access! good job 