<darth-cheney>I'm trying to install guix system on a laptop here. Installation from USB drive went off without a hitch, but when I boot up it seems to get stuck at "Please wait while gathering entropy to generate the key pair"
<darth-cheney>Any ideas about what could be causing this / ways to debug?
<roptat>mh, sounds like the ssh service is trying to gather entropy, but something is preventing it from doing so
<roptat>I've never seen that with the guix system before, but maybe you can have some influence on the process by moving the mouse, typing some nonsense, etc
<roptat>maybe you can also access another tty in the meantime
<darth-cheney>hmm should I try to reinstall and not select any of the optional network service options (I think those included Tor and something else)
<darth-cheney>There are some other preceding errors that are beyond the horizon of my knowledge. Some things about ACPI errors and a GC warning about reading /proc/stat
<roptat>mh, so maybe it was not ssh, but whatever is after that, that doesn't print anything and blocks boot
<roptat>unfortunately, I don't know how to help you
<roptat>looks like most people here are asleep now, maybe you'll have more luck asking email@example.com. your first message needs to be moderated by a human, so it can take some time to appear, but following messages will get through immediately
<iyzsong-w>i'll have some time during the 5.1-5.5 holiday.
<tissevert>I've written a simple shell script which I'm not trying to package but simply to run and I get errors calling binaries like sed or wc (both in my PATH, and, most importantly, in the PATH seen from within the execution context of my script — I checked, `which` even resolves those binaries correctly)
<bdju>anyone have thumbnails working in the qt file picker?
<pineapples>bdju: How can I check if they work for me? I can't promise to do it now, but I'll be available here for as long as a few days; feel free to nag me about it, if I forget to do it
<bdju>pineapples: if you don't mind, use qutebrowser and go to some sort of file upload dialog, then browse to a directory with pictures in it from there and see if they show something besides a stock icon
<bdju>I'm using Sway on top of %base-services (not %desktop-services), so it's possible I'm missing something related to thumbnails there. or I need to install some sort of kde stuff maybe
<pineapples>bdju: Alright, sorry about that; I got confused. Anyway, I don't have thumbnails, neither. Images in my ~/Pictures have a placeholder thumbnail, which looks exactly like LibreOffice Writer's icon
<pineapples>bdju: You are welcome! And, hey, thanks for introducing me back to qutebrowser :)
<pineapples>Speaking of which, qutebrowser fails to start under Wayland. I suppose it's, too, missing `qtwayland' from its inputs..
***zap1 is now known as zzappie
<bdju>pineapples: ah, interesting. I think my qutebrowser is running with xwayland. is it supposed to work with actual wayland?
<PotentialUser-81>I would like to inspect some Guix variables in a Guile REPL, e.g. %base-packages & %base-services. How do I go about making them available? I ran "guix repl", and ",use (gnu packages base)" but the REPL says that %base-packages is unbound
<mbakke>PotentialUser-81: those variables are available in the (gnu) module
<PotentialUser-81>Thanks! I just needed to "(use-modules (gnu))". What does the ",use (gnu packages base)" do? I copied that from the manual
<apteryx>yeah for overdrive1 aarch64->armhf is disabled until #43513 is fixed
<apteryx>so that leaves us with only the beagleboards, which are only exposed via wireguard (10.0.0.5 and 10.0.0.6)
<apteryx>what machine are you using for armhf-linux offloading? how do you configure it?
<civodul>i think disabling aarch64->armhf is unnecessary
<civodul>#43513 was about more specific cases (emulated 32-bit builds on 64-bit hardware)
<civodul>but yeah, dunno, it's at least over-conservative
<civodul>i use the overdrive for armhf offloading, it just works
<civodul>problem is that #43513 got stuck after a flood of back-and-forth :-/
<apteryx>I see! Danny's analysis was concluded by 'That means building stuff for ARMv7 on aarch64 is not reliable at all'; I have only surveyed the thread and I'm not sure I understand what's at stake.
<apteryx>I guess if it builds and runs, it's good enough for our purposes.
<civodul>you're cross-building runc, isn't that written in Go?
<civodul>bone-baboon: hi! email NNNfirstname.lastname@example.org, where NNN is the bug number
<civodul>if you use Emacs, try M-x debbugs-gnu, it's very convenient
<bone-baboon>civodul: So for bug#47964 I would email email@example.com? Is there anything specific that needs to be in the subject or body of the email? Thanks for pointing out the Emacs option.
<bone-baboon>For the Emacs option it looks like I need to install an package I will look into in.
<apteryx>civodul: I'll send a patch to add my guix system public export key to overdrive1, as that's required for offloading from home.
<apteryx>in that patch, there'll be hydra/keys/guix/maxim-desktop-export.pub; that key should be authorized by the OSUOSL machine as well. Does that sound OK?
<apteryx>civodul: yeah, I had observed the same (and sent guix-sysadmin about it but I wasn't registered -- I guess it got stuck somewhere). I had commented out the machines in /etc/guix/machines.scm on Berlin for that reason.
<efraim>I tested syncthing compiled for armhf-linux, I tossed it on my powerpc laptop and used qemu-binfmt emulation, like I normally do
<dongcarl>Wondering if people could determine if http://issues.guix.gnu.org/47935 should be added to v1.3.0 blocking? For no-substitute builders on overlayfs (docker, podman), this coreutils is early enough in the dependency graph that it'll stop them from building much of anything useful. I'm happy to contribute the fix!
<civodul>dongcarl: hi! we need a fix for that, but that'll be in core-updates
<lfam>I'm feeling like we need to improve our documentation about the core-updates and staging branches. It seems like people are expecting them to be something besides a mismash of random core packages updates
<lfam>Debian failed terribly in this regard, and I see people all over the net suggesting to use Debian "testing" because they think it's a middle ground between "stable" and "unstable" when it's really like our core-updates branch
<rekado>I think it may just be due to old IPs that we recycled, but I really don’t remember after 60 days uptime
<jlicht>rekado: perhaps I'll just have to bite the bullet and strace it :-)
<davexunit>does anyone successfully run Dr. Racket via Guix?
<davexunit>I tried `guix environment --ad-hoc racket` but drracket doesn't work within
<bone-baboon>lfam: Thank you for helping me figure out the build of webkitgtk. Two other packages I remember having to set `--cores` for while building were mariadb and llvm. Those two packages may also be able to benefit from a similar patch as the webkitgtk one. I do not have the details for mariadb or llvm currently as I was able to get them fixed with help from people in this IRC channel and did not submit an email about them to a
<lfam>bone-baboon: Okay. We'll leave those alone for now, unless we get other bug reports. I think that compiling with a single core is pretty atypical, so I'd rather avoid having to rebuild those packages unless there are bug reports from users
<lfam>We can't change those packages on the master branch, anyways. It would cause too many packages to be rebuilt
<lfam>In general, it's typical to use substitutes, and then among people who build everything from source, it's also typical to use multiple threads
<lfam>So, the set of people who don't use substitutes and only have one thread is very small
<bone-baboon>lfam: The only reason I was trying one thread was because `sudo guix system --no-substitutes reconfigure configuration.scm` was failing. I should have included that in my initial email about webkitgtk failing.
<bone-baboon>nckx: Thanks I think you helped me figure out how to build llvm and I applied the same approach to get mariadb to build. Not sure exactely as I did not keep detail records of the build problems I was having with those two packages. If I remember correctely it was to use `--cores=1 --max-jobs=1` without specifying those the build for those two packages werer failing. These build failures were all happening on a x86_64 comp
<iskarian>Hey, I have a package in kernel-loadable-modules which uses the linux-module-build-system, but how do I make sure the build system uses the same kernel version as the OS? Would I just want to put the package in e.g. a make-package that takes a kernel as an argument etc., or is there a more straightforward way?
<pascallor>Hi! Does anyone know how to get the stumpwm contrib modules to work on guix?
<pascallor>I've installed them (e.g. sbcl-stumpwm-cpu), but I get an error message when loading my stumpwm init file: `Error: Could not load or find module: "cpu"`.
<pascallor>I've searched the whole file system (`find / -ipath "modeline/cpu"`) unsuccessfully.
<pascallor>I did not have stumpwm-contrib in my guix configuration because I thought I did not need it since all the actual modules inherit from it.
<pascallor>Now I tried adding it to the config in case I had to ("error: stumpwm-contrib: unbound variable" "hint: Did you forget a `use-modules' form?") and installing it ("guix install: error: stumpwm-contrib: unknown package").
<iskarian>pascallor: are you looking for sbcl-stumpwm-cpu? It doesn't look like there is a stumpwm-contrib package
<pascallor>I have installed sbcl-stumpwm-cpu, but I have no idea how I can use it. I assume this is just me not knowing guix well enough. The stumpwm init file worked under arch linux.
<pascallor>As for stumpwm-contrib, I saw it in wm.scm and thought that I might have missed it. But I just checked again and it is defined, but not public, so I guess my initial understanding that it was only there as a base for the actual modules was right.
<lfam>"Just to understand: /if/ at any point in time a user is able to afford the effort to build the entire core-updates /or/ staging branch she should be confident the result is state-of-the-art secure. Am I wrong with this assumption?"
<lfam>I just want to make sure that people don't get that impression about these branches
<pascallor>iskarian: Thank you! I did look at it a couple of times but the first time was before I got stumpwm to work and after that when I looked at it I thought I had finished doing all that was written there while my config was still the non-guixified one.
<pascallor>Probably too late for me, not too early for you ;)
<vagrantc>i do find the whole discussion of the misleading commit messages to be strange ... clearly mistakes were made, clearly some people have been a bit too abrasive, but there's way too much tension still :/
<leoprikler>That's a discussion we have to deal with in the foreseeable future. People hold strong and differing opinions about it after all.
<lfam>The discussion could not have been started in a more inappropriate way. There's a lot of good ways to highlight problems and give feedback, but that's a masterclass in how not to do it
<lfam>And yet still, we *all* make mistakes, but the important thing is how we handle them. I'm not satisfied with what's been demonstrated in that regard
<lfam>Yes, that's the solution to use the kernel we offer, linux-libre. You'll have to choose a dongle carefully because linux-libre has very limited support for wifi
<lfam>The other option is to use a custom kernel that includes support for your hardware
<lfam>But, we don't offer advice about that here, sorry
<lfam>Changing the subject, it seems like offloading to aarch64 is not working on berlin.gnu.org
<darth-cheney>Hey guix crew, I was here last night while everyone was sleeping trying to get to thebottom of a guix system install issue. I figured I'd try you all one more time before heading to the mailing list
<s0ngr4m3>ok many thanks. I will test with usb dongle not cheap !
<lfam>Previously I was able to do `guix build /gnu/store/...-foo.drv` and build aarch64 derivations
<darth-cheney>Short of it: new system install, usb boots fine, installation goes without error, but on boot it freezes at `making /gnu/store/<etc etc> the current system`
<lfam>s0ngr4m3: I recommend finding a dongle that uses the ath9k or ath9k-htc drivers
<darth-cheney>Prior to that there are some GC Warnings, one being "Couldn't read /proc/stat"