<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?
<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
<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?
<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
<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
<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)
<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 email@example.com
<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?
<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
<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?
<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?