<solene>hyperola has plans to move to OpenBSD, I'm curious to see how it will go
<dstolfa>nckx: alright, i'll wait to see their response and keep poking around. if things seem fine i'll order one of the dongles and try it out on my laptop when it arrives (approx 1 month from now, hopefully). i'll try building it by adding _Static_assert to everywhere that blobs might be included to see if the compiler hits it or if it really is compiled out
<Bumblehorse>I noticed that my service "swap-/dev/sda1" has been stopped, but when I try to restart it, it says "In procedure swapon: "/dev/sda1": Invalid argument". Does anyone know why this is the case?
<nckx>CONFIG_LOGO=y, CONFIG_LOGO_LINUX_CLUT224=y (which I've replaced with a full-screen Guix logo — what, you thought I was asking because I wanted 4 penguins?)
<projectmoon>If I'm storing my guix configs in a repo or something for backups, the user profiles are separate files from the system config right? Basically I'm wondering how to deploy a system in full, including its user profiles, using guix magic
<projectmoon>Everything I find so far is for the system config only
<civodul>it's not the only one, but a good one in its category
<leoprikler>I agree, that Rust the language is not necessarily Cargo, the build system and package manager, but those two are very much interwoven to the point that Rust without Cargo is next to useless (and certainly not used in practise).
<qyliss>it's about to be in both Linux and Android!
<avalenn>It is not much more interwoven than Python and pip. In practice no one does Python today without pip.
<avalenn>And in Linux, Rust will certainly be used without Cargo.
<leoprikler>I hope you are right about that, but other problems with Rust remain.
<thecatster>Has anyone tried running Cuirass on a Pi cluster? I’m wondering if I could get away with cross-compiling with it, if not I’ll continue to use my big server. Thought it would be cool to offload that many cores but not fast CI/CD to the cluster.
<civodul>thecatster: hi! you could run the core service on a biffy x86 machine and have it offload builds to RPis
<civodul>you could also run Cuirass itself on a Pi, but it may be too slow
<flatwhatson>getting a weird message from guix upgrade: "warning: missing arguments, nothing to do"
<flatwhatson>i think "guix upgrade" with no arguments shouldn't warn?
<thecatster>civodul: That sounds great, I think I’ll try that.
<elb>Hi all, I have installed and updated guix per the directions on guix.gnu.org (I believe) on a debian buster foreign distribution, and I have used guix package to install mutt; my terminal (via debian) is kitty, and mutt reports 'Error opening terminal: xterm-kitty.'. I used guix to install kitty, but I still get the same error. How do I get mutt in guix to find _either_ my foreign distro terminfo _or_ the
<elb>(I'm brand new to this; so far my experience has been: guix is unusably terrible without substituions; guix pull fails and asks me to report a bug report; guix locales and terminfo are both broken without manual intervention)
<balbi>civodul: interesting... guess it would be hard to rely on guix for linux kernel dev, then (?)
<elb>(I don't say this to be harsh, I think guix does something I very much want, which is a stable way to deploy non-distro packages to a variety of machines, but I'm a Unix user and Linux user with 25+ years of experience and several degrees in computer science ,and I'm still finding this ... frustrating)
<elb>civodul: I would expect it to at least be able to update itself even without substitutes; but I think m yreal surprise there was that the instructions say "oh by teh way you might want to install substitutes" in passing, not "you'll need to install substitutes if yo uwant to be able to install the most trivial of packages before the heat death of the universe on your 12-core Xeon with 56 GB of RAM"
<elb>I'm under the impression that `guix pack` would still have this terminfo problem
<elb>and yes, `guix pack` is on my list of things to explore if I get to the "next steps" part of this journey ;-)
<flatwhatson>yes, likewise FONTCONFIG_PATH can be annoying on non-guix systems
<elb>years and years ago I used checkinstall (I think?) for this purpose, but I was never entirely happy with it
<elb>I think I may be able to converge on guix pack plus a script to be dropped into /etc/profile.d or whatever, but that script is feeling a little bit like whack-a-mole right at hte moment, since the _very first package I installed_ ran aground on this ;-)
<civodul>cbaines: "can't use GnuTLS with GC enabled" is a bit strong :-)
<civodul>Guix commit 02d62978f46fcc2793608bb57a2c20a30555dbba catched EAGAIN/EINTR and tries again
<taeaad>Hi, I was just wondering about guix and trying to understand the organisation behind it better. Is it maintained by the GNU Project? And is that the same as the FSF. I know Stallman vs. the World seems to be a thing these days, but I just want to know specifics a bit better.
<civodul>when that happens, it does a bit more work, but it's rather unusual
<civodul>taeaad: hi! the GNU Project is loosely organized; Guix governance is independent of the FSF and RMS in practice, if that's what you're asking
<taeaad>OK, yes, I didn't want to sound political.
<cbaines>civodul, with the Guix Build Coordinator, especially when it's performing multiple builds, it can often be trying to upload a large output, while the GC is firing all the time. I think this changes it from an unusual event to something that simply prevents making non-trivial TLS requests.
<taeaad>It's cool that there is GuixHPC, sounds interesting.
<civodul>cbaines: are there other threads "doing things" while it's uploading?
<civodul>in a single-threaded program there's no GC activity while transfering data over GnuTLS
<civodul>but yeah, in a multi-threaded context there could definitely be something
<civodul>if the GnuTLS patch doesn't land in a timely fashion we can add it locally
<cbaines>civodul, yeah, the model I'm currently using is that one thread takes care of one build. So on a large machine, there can be 32 threads all going at once.
<cbaines>I'm not quite sure what is the biggest causes of garbage, but I wonder if the build logs streaming back (and going to to a void port) lead to garbage
<civodul>yeah, writing to a port typically triggers allocations
<cbaines>anyway, I'm happy that there's a workaround :)
<cbaines>that means I can get on with fixing and improving other things
<rovanion>I'm failing at packaging again. This time its a modern program called Lingot. It seems easy enough, but I can't seem to provide GLIB_COMPILE_RESOURCES to its configure script to put in the Makefile. Atleast that's my read of it. I've pasted my package definition here if anyone want so give it a shot: https://paste.debian.net/1199211/
<nckx>rovanion: That's the way to ask for the glib:bin output (glib is the library, :bin contains the tool you need) in packages for now, until civodul ruins everything by improving it greatly -- again.
<nckx>It really helps if you can share more information than the above, like your work so far & *how* they fail (the log). You can use paste.debian.net for that, pasting multiple lines into IRC isn't ‘done’.
<taeaad>nckx: It may be difficult since you're still in Emacs and everything is in a buffer. So if you want it all in the same Emacs instance, then I guess it can be confusing.
<taeaad>But configuring different networks isn't difficult if you are already an Emacs user.
<nckx>emad-guix: Please share more info... ‘the tests failed’ is not useful, nor is ‘ I'm getting something like : Unexpected critical/warning: failed to create element 'rtpbin', check your installation’. Just paste your current package, and the log (although we can recreate the latter if you give us the former).
*nckx really needs to re-slather their CPU in fresh paste :-/ 99°C building this thing because it's mildly warm out.
<nckx>Unfortunately that log file doesn't seem to contain any shocking news. Disappointingly, GST_PLUGIN_SYSTEM_PATH looks correct...
<apteryx>for Shepherd actions, is the modules field of a service sufficient to have extra Guile module (e.g., (srfi srfi-26)) in scope ?
<nckx>emad-guix: You mean in Guix's packaging of gst-plugins-bad? Not that I'm aware. I'm not an expert on Gstreamer by any means (I once installed it to make the baseball men go, the end) but my understanding was that ‘bad’ did not include ‘straightforwardly non-free’. It's more about patents &c.
<emad-guix>nckx did try to build it? it seems everything is correct but the test issue probably from network config or something like that I'm not sure to be honest
<lfam>There's no network access in the build environment, emad-guix
<nckx>It just has 34 minutes of an rms interview awkwardly spliced in.
<lfam>emad-guix: You could test if this is the problem by going to the failed build directory, sourcing the environment variables file, and then running whatever command is used to start the test suite
<roptat>progress: it uses the right version for maven-jar-plugin (and all other plugins) by default now
<roptat>but build fails in a compilation error: /tmp/guix-build-java-jmh-1.31.drv-0/source/jmh-core/src/main/java/org/openjdk/jmh/runner/options/IntegerValueConverter.java:[70,41] error: incompatible types: Class<CAP#1> cannot be converted to Class<Integer>