Incidentally, two things are worth noting here IMO:
It’s great to send a heads-up before actually stepping down, with a list of projects up for grabs—as opposed to simply disappearing as is all too common. That’s a much appreciated sign of commitment and humanity.
It’s OK to retire or take a break in free software, we all do eventually; no volunteer should work 365 days a year until they experience burnout.
Surprising amount of procedures in (#guix#gexp) does not handle utf8 input. Combined with #guile 's approach of just replacing the utf8 characters with #?, it is pretty annoying foot gun.
I am putting together a patch, hope I will make it before the core-updates merge, it kinda rebuilds a lot...
Many areas where you can help, with different time commitments and prerequisites: funding & spending, hardware hosting, system administration, and coding.
Video of the interview with #guix founder @civodul is available. A great chat about the #nix deployment model, his interested in #guile and #free software. Lots of interesting chat about motivation in #freesoftware, #gnu and #linux - as well as the Plan9-ification of Guix!!
In « Source Code Archiving to the Rescue of Reproducible Deployment » we describe the #GNU#Guix / @swheritage integration to ensure the reproducibility of scientific environments.
I wonder if there are any #guix maintainers willing to take a look at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70112 . I tried asking in #guix room few times, not much luck. There are already new versions available, and I would prefer not to rebase it (again), testing it is quite annoying due to differences between podman 4 and 5...
I ran an experiment yesterday, and found the package with the largest number of dependencies in #guix using this little command: guix package -A | awk '{print $1}' | parallel 'echo -n {}; echo -n " "; guix size {} 2>/dev/null | tail -n +3 | wc -l' | sort -n -k 2 | tee ~/Documents/sorted_packages.txt. The whole thing took 6 hours to run at about 90% CPU utilisation.
Result: pigx has the most dependencies at 968, with most of the runner ups being scientific analysis tools too. Cool!
I love how #guix allows you to inspect all of the dependencies of a package in detail. Running guix graph foo | xdot - on some package and combing through the massive dependency graph that results is fascinating, but also a little terrifying.
It's a wonder anything works at all.
@khleedril I’m afraid we can’t: sooner or later, the innermost ring starts depending on some outer ring (glibc depending on Python, librsvg on Rust, etc.), and you end up with a single ring.
Coming from Debian to Guix, having "everything" in a single repository is perhaps one of my favorite practical features.
Debian has no "central" location for VCS repositories, every single package defines a custom location, which could be entirely outside of Debian infrastructure, or no proper VCS at all!
Guix having everything in a monorepo enables searching for packages with "git grep" and also cargo-culting, er, borrowing from other packages much more easily.