<mbakke>whoops, the Perl upgrade on 'core-updates' broke 'po4a' (a prerequisite for 'guix'), I did not notice because I was working on texlive (a prerequisite of po4a), and the other perl stuff I tested was fine
<cbaines>Maybe it would help to have a more minimal package definition with just enough stuff for the agent though
<fdddd>Would it be possible to install Guix "headlessly" (e.g. over SSH)? I have a machine which I will use as a server, but I don't think graphics can be displayed for the installation on this machine with the Linux Libre kernel. Alternatively, is it possible to get the TTY display to work without graphical drivers? The machine has an AMD Ryzen 2200G APU with integrated graphics so the firmware blobs necessary for AMDGPU are missing afaik.
<jonsger>fdddd: I think basic 2D graphics should work even without the non-free firmware. Maybe you need to fiddle a bit with cmdline (nomodeset)...
<fdddd>Right I will give nomodeset from grub a try. Wasn't sure if this still required firmware etc.
<dftxbs3e>mbakke, hello! it failed with this: objcopy --dump-section=.gnu.attributes=/tmp/guix-build-glibc-cross-powerpc64le-linux-gnu-2.32.drv-0/build/no_ldbl_gnu_attribute.bin.tmp /tmp/guix-build-glibc-cross-powerpc64le-linux-gnu-2.32.drv-0/build/no_ldbl_gnu_attribute.o
<dftxbs3e>objcopy: Unable to recognise the format of the input file `/tmp/guix-build-glibc-cross-powerpc64le-linux-gnu-2.32.drv-0/build/no_ldbl_gnu_attribute.o'
<dftxbs3e>I am thinking binutils (objcopy) isnt up to date enough?
<abcdw>jgart[m], dftxbs3e Fixed yesterday quirk. It were few problems in different places (I had bunch of temporary scm files without namespaces and proper imports declarations in the load-path), but the interpreter complained about unbound varible for some reason.
<civodul>jonsger: i've tried with additional channels as well
<bandali>re savannah: there were a bunch of lingering git processes hogging the git server. killed them, and things should be good again now :-)
<bandali>that server could generally use a bit more memory imho
<dftxbs3e>cbaines, ZFS deduplication on my hypervisor host is taking up lots of RAM. So many things are OOM'ing right now because the hypervisor host is under serious memory pressure.
<cbaines>dftxbs3e, maybe drop the number of parallel builds, 16 is quite a lot
<HappyEnt[m]>Hello! Anybody know how to solve guix in pre-inst-env not finding (gcrypt hash)? The module is definitely in my load-path and I can load it perfectly fine from a repl inside the pre-inst-env. I also tried a pure environment using guile from the source build (In contrast to what I had in my environment)
<ngz>HappyEnt[m]: I don't know, but I would try to ./configure and compile guix again in your case.
<ngz>This is my recipe when ./pre-inst-env starts acting funny.
<HappyEnt[m]>ngz: I tried that, but maybe make clean leaves something over. Now that I think about it I think that was my problem last time I had this same problem. I will try a clean clone! Thank you :)
<dftxbs3e>cbaines, the problem is elsewhere, the VM only has 3GB of RAM allocated currently :P
<dftxbs3e>cbaines, are OOMs going to disturb the system? Or is your code able to detect OOMs and ignore build results?
<cbaines>dftxbs3e, there's not a mechanism currently to spot when builds fail because of resource issues, but don't worry about it, failures will be retried a couple of times
<ngz>Is it fine to update openblas in core-updates?
<dftxbs3e>cbaines, okay, many builds probably failed many times there so I hope it didnt mess everything up
<dftxbs3e>cbaines, I lowered it to 8 parallel-builds as well
<sneek>Welcome back jmarciano, you have 1 message!
<sneek>jmarciano, leoprikler says: Guix (the package manager/OS) deletes files [upon gc] using rm, so nothing is trashed. Applications on Guix, e.g. GNOME, may or may not honor XDG trash, as they do in other distros.
<cbaines>I think to reduce the number of patches, I just marked everything as accepted at some point it the past
<cbaines>zimoun, as for the A/R/T and S/W/F bits, you might see information if you hover your mouse over those bits
<ngz>cbaines: I have a silly question: can patchwork let me know if a patch actually builds?
<cbaines>zimoun, I see Acked by/Reviewed by/Tested by and Success/Warning/Fail
<aecepoglu[m]>I have written a package for an addon for a text editor (Kakoune, which exists in guix) . The plugin itself is a CLI application written in Rust. Should in go in gnu/packages/rust.scm or rust-apps.scm ?
<mbakke>locally I've also made 'intltool' purposefully fail to build, and will remove it from packages as I go (GNOME no longer uses it) :-)
<mbakke>as well as 'python2', but that is more complicated (rust and ghc tests)
<GewaltDisney>lfam, you're welcome. the way it exemplifies what i would call a "politics of demonstration", not only speaking about the ethics of free software but demonstrating its necessetity in practice, if we want to keep to the standards science has set itself; while also demonstrating what becomes possible when workers are treated as owners of their means of production. i dont think i've encountered any technology that had such profound
<GewaltDisney>implications, both in the realm of ideas as well as the social
<apteryx>you can still generate system disk images, vms, etc. but you don't get to configure the current system via a Guix operating system configuration on foreign distros.
<apteryx>experimenting with the following manifest while test driving changes to the emacs-build-system, I notice quite some times is spent before anything gets done, with CPU and disk usage low: https://paste.debian.net/1177415/.