<marusich>sneek, later tell dftxbs3e we need to rebuild the bootstrap binaries in order to fix the problem with the statically linked guile, right? Do you know how to fix it? Re: rebasing on master, that's fine w/me if it works. Last time, I merged master into wip-ppc64le, so I'd prefer merging, but rebasing is fine too.
<marusich>sneek, later tell narispo neat, it's good to see things being reported in the Guix Data Service. Who's building this? Is somebody running Cuirass on a powerpc64-linux system, or is the build farm using the transparent qemu binfmt trick to emulate the builds for the arch?
<leoprikler>W.r.t. renpy-build-system: That patch only solves part of my problem sadly, the other part is that the game still fails to run since it's meant for an ancient version of Ren'py and there's no source code to go fix it.
<leoprikler>Don't worry, I wouldn't be asking if it wasn't something extremely arcane in the first place 😄️
<marusich>sneek, later tell dftxbs3e I am not actually sure we need to rebuild the powerpc64le-linux bootstrap binaries. What is the problem with the statically linked bootstrap guile? It seems to work when I use it.
<wumpus>i'm trying to get shutdown through 'virsh shutdown', which simulates the ACPI power button, to work in a GUIX VM, is there a simple low-overhead way i'm overlooking to do this? i know acpid exists as a package but there's no service for it, and pulling in the desktop services just for elogind-service seems overkill
<Aurora_v_kosmose>From within the VM, when you send the virsh signal, do you see anything happen in the kernel logs & other system events?
<g_bor[m]>wumpus: i guess you can just pull in elogind service
*Aurora_v_kosmose is wondering if it's just ignored entirely or some option
<alextee[m]>is it ok if my patch includes the removal of extra space at the end of a line somewhere else in the file I'm editing?
<wumpus>Aurora_v_kosmose: i'll check, but what i expect is that the ACPI signal reaches the kernel fine (as it works for other Linux-based VMs like ubuntu), there's just nothing in userspace that triggers a soft shutdown in response
<wumpus>g_bor[m]: yes, just biting the bullet and installing elogind (and whatever it pulls in, some dbus service related things?) would be one option, it seemed overkill to have for a tiny VM, so i was just wondering if this had been considered before
<wumpus>i really want to avoid pulling in 'desktop' stuff like X11 and display managers and fonts, but maybe my worry is ungrounded there
<leoprikler>alextee[m]: it will maybe cause a little stress to the reviewer, but we aim for proper indentation anyway
<leoprikler>you may want to separate the line noise from your actual commit however
<nckx>alextee[m]: Better to keep it separate. If you're thinking ‘well that's not worth a patch...’: there are (surprisingly many) more " $" in .scm files alone.
<nckx>But they're optional; one fix is better than none.
<leoprikler>if it packs a large bunch of rust stuff, that belongs to crates anyway ;D
<pretzel>leoprikler: Thanks for the suggestion. It's a simple patch (approx. 10 loc), but I'd prefer a diff. mdevos: Thanks. I fail to understand how to use such a plain-file as with-patch argument (latter seems to expect a path string not a file-like object).
<leoprikler>It might be easier to use guix' package facility directly rather than through (guix transformations) here.
<cage_>i am trying to install guix stable on a ubuntu (last stable) and it fail to build guile 3.0, someone got the same problem?
<xelxebar>Hrm, I have a (udev-rules-service 'foo foo-rules) entry in my services, but after a reconfigure the rule isn't showing up under the output reported by herd rules udev...
<cbaines>cage_, are you installing through building from source, or using the binary installation?
<sneek>dftxbs3e, marusich says: we need to rebuild the bootstrap binaries in order to fix the problem with the statically linked guile, right? Do you know how to fix it? Re: rebasing on master, that's fine w/me if it works. Last time, I merged master into wip-ppc64le, so I'd prefer merging, but rebasing is fine too.
<dftxbs3e>marusich, oh well yes merging is fine too, I just kind of dislike merge commits aha
<dftxbs3e>marusich, I think we do, I am not sure yet if that guile-static binary is in the bootstrap binaries themselves or built using them (my investigations for this were inconclusive). I am not sure why it contains such a reference and the binary seems not static at all since there's few dynamic libraries listed by ldd.
<dftxbs3e>marusich, I think we could detect this better using the forbidden reference functionality..?
<dftxbs3e>Going to review some patches now, since that how I think I will be most useful as a committer first!
<leoprikler>Rust folks, how do you deal with "the trait bound `anyhow::Error: std::error::Error` is not satisfied"
<hapster>is anyone else having troubles with guix pull?
<hapster>I seem to have a problem with guix-package-cache
*nckx pulls. Could you paste the entire error to paste.debian.net, hapster?
<nckx>& do you use channels in addition to the canonical Guix upstream @ Savannah?
<dftxbs3e>nckx, hello :-D ! I am using "make authenticate" before pushing and it says it can't verify my commit for some reason. "key 148B CB8B D80B FB16 B1DE 0E91 45A8 B1E8 6BCD 10A6 is missing" - Is that my GPG install or..?
<dftxbs3e>(it also fails with ./pre-inst-env make authenticate)
<mbakke>dftxbs3e: try updating your 'keyring' branch
<dftxbs3e>mbakke, okayy!! thank you! I have GNU Guix's official remote named "upstream" instead of "origin" there.
<raghavgururajan>builder for `/gnu/store/mlpp94hpr5difzw9lbzjc2n3a83lrng7-qtsingleapplication-0-53.9568abd.drv' failed to produce output path `/gnu/store/r1rdqiramrj757v0l3j02kl26qi74b54-qtsingleapplication-0-53.9568abd'
<leoprikler>hmm, that means that "make install" or whatever equivalent did exactly nothing
<dftxbs3e>leoprikler, well I think it's mainly because it's the end-user application that defines things like RUSTFLAGS and not libraries themselves, and in GNU Guix we don't currently reproduce libraries since we only package source code right now.
<leoprikler>btw i tried ("rust" ,rust-1.50)("rust:cargo" ,rust-1.50 "cargo") and the same happens
<dftxbs3e>leoprikler, I ran "./pre-inst-env guix build fractal" on your "fractal4" branch, expected hash: 1bm1y4k3czplyf796cxgs4k6lrdhkjb7f52ligml73pakz9s1q26 actual hash: 0aib8385fxdpw79sasfzn6q11sqx3wigkb267if9fb12bagycgpk
<dftxbs3e>leoprikler, tell me when you push something that can reproduce the fractal error :-D
<leoprikler>just add (recursive? #t) to the git-reference of rust-sourceview4-for-fractal
<leoprikler>then you should no longer have the hash mismatch
<dftxbs3e>leoprikler, okay! done! Building fractal now
<dftxbs3e>nckx, leoprikler: what's the policy for copyright lines? when should we add them? is it always at the discretion of the contributor? should we do it for contributors if they didnt (or suggest that they do)? Nobody ever told me to add them since I don't myself.
<nckx>dftxbs3e: re: copyright, for small changes I just follow what the contributor did; for ones that are obviously significant and lack a copyright line I always ask (the name/mail they use for git might not be the one they want recorded there, for whatever reason).
<vagrantc>have mixed feelings about the way guix uses qemu for emulated foreign architecture builds ... having the entire closure of qemu available in the build environment would seem to potentially taint the purity of the build environment
<leoprikler>nckx: not quite. I read this as "if you somehow manage to bootstrap ancient GNAT, you can probably jump to modern GNAT easily", which is an interesting proposal at least (*cough* rust *cough*)
<dftxbs3e>leoprikler, still looking, but will continue tomorrow!
<marusich>dftxbs3e, do you know what the syscall id for clone is on ppc64le? I want to add it to guix/build/syscalls.scm (search for existing string "mips" to find the code I'm looking at), since I think that might be why some guix tests are failing.
<marusich>I am not sure how to find the syscall id, although it seems like it should be trivial........
<vagrantc>apteryx: yeah, the F flag is key to it being amazing :)
<vagrantc>apteryx: i think because the kernel is handling it, it isn't limited by the chroot of the working environment ... but further testing needed to be sure
<brown121407>Hi, Guix! Knowing that we have a "kernel" field in the operating system configuration and that Guix works on at least two kernels (Linux and Hurd) does this mean that we could one day have a GNU/BSD operating system with Guix running on top of a *BSD kernel? Is this possible?
<pkill9>brown121407: i think someone/some people have looked into that, i can't remember what the verdict was
<brown121407>cbaines, does Guix directly depend on glibc? I mean, is it something in glibc that other libcs don't have that makes Guix work?
<vagrantc>so, theoretically possible, though i think guix relies (or at least prefers to have) some linux specific features for the container features used to build packages and such
<cbaines>brown121407, Guix doesn't directly, but most things packaged for Guix directly or indirectly use glibc
<jackhill>What about nscd, is that a glibc feature, and how important is to to Guix to avoid loading conflicting libcs for name and other database lookups?
<nikita`>guix is very glibc specific. i abandoned my explorations of a port to netbsd because it also needs to support the kernel + libc combinationation (more or less). freebsd gets away with some linuxisms in their kernel, but i have no idea if glibc works for them with lots of pretending and patches. doesn't for us, and doesn't for openbsd as far as i can guess
<nikita`>also for anyone suggesting the idea of GNU/BSD combination seems somewhat okay and who doesn't approach this from a Linux perspecitve, please take 5 steps back from the idea and look at what makes BSD BSD and why this is a bad idea.
<rekado>jackhill: nscd is part of glibc. It is indeed used to provide a stable client-server protocol for user names as an alternative to loading plugins that have been built for a different C library.
<milkey>a step in that direction would be getting stuff building on top of musl libc instead of glibc
<rekado>milkey: there’s really no point in doing this without glibc