GNU Planet - Latest News

GNU Artanis: A secure design of crypto custody with TEE (%2025/%04/%02 %13:%Apr)

FSF Blogs: March GNU Spotlight with Amin Bandali (%2025/%04/%01 %15:%Apr)Eighteen new GNU releases in the last month (as of March 31, 2025):

patch @ Savannah: GNU patch 2.8 released (%2025/%03/%29 %18:%Mar)I am pleased to announce the release of GNU patch 2.8. The project page is at https://savannah.gnu.org/projects/patch The sources can be downloaded from http://ftpmirror.gnu.org/patch/ The sha256sum checksums are: 308a4983ff324521b9b21310bfc2398ca861798f02307c79eb99bb0e0d2bf980 patch-2.8.tar.gz 7f51814e85e780b39704c9b90d264ba3515377994ea18a2fabd5d213e5a862bc patch-2.8.tar.bz2 f87cee69eec2b4fcbf60a396b030ad6aa3415f192aa5f7ee84cad5e11f7f5ae3 patch-2.8.tar.xz This release is also GPG signed. You can download the signature by appending '.sig' to the URL. If the 'gpg --verify' command fails because you don't have the required public key, then run this command to import it: gpg --recv-keys D5BF9FEB0313653A Key fingerprint = 259B 3792 B3D6 D319 212C C4DC D5BF 9FEB 0313 653A NEWS since v2.7.6 (2018-02-03): The --follow-symlinks option now applies to output files as well as input. 'patch' now supports file timestamps after 2038 even on traditional GNU/Linux platforms where time_t defaults to 32 bits. 'patch' no longer creates files with names containing newlines, as encouraged by POSIX.1-2024. Patches can no longer contain NUL ('\0') bytes in diff directive lines. These bytes would otherwise cause unpredictable behavior. Patches can now contain sequences of spaces and tabs around line numbers and in other places where POSIX requires support for these sequences. --enable-gcc-warnings no longer uses expensive static checking. Use --enable-gcc-warnings=expensive if you still want it. Fix undefined or ill-defined behavior in unusual cases, such as very large sizes, possible stack overflow, I/O errors, memory exhaustion, races with other processes, and signals arriving at inopportune moments. Remove old "Plan B" code, designed for machines with 16-bit pointers. Assume C99 or later; previously it assumed C89 or later. Port to current GCC, Autoconf, Gnulib, etc. The following people contributed changes to this release: Andreas Gruenbacher (34) Bruno Haible (5) Collin Funk (2) Eli Schwartz (1) Jean Delvare (2) Jim Meyering (1) Kerin Millar (1) Paul Eggert (166) Petr Vaněk (1) Sam James (1) Takashi Iwai (1) Special thanks to Paul Eggert for doing the vast majority of the work. Regards, Andreas Gruenbacher

FSF Blogs: "Free" filing should be free as in freedom (%2025/%03/%28 %17:%Mar)A modern free society has an obligation to offer electronic tax filing that respects user freedom, and the United States is not excluded from this responsibility.

FSF Blogs: FSD meeting recap 2025-03-21 (%2025/%03/%26 %15:%Mar)Check out the important work our volunteers accomplished at today's Free Software Directory (FSD) IRC meeting.

FSF Events: Free Software Directory meeting on IRC: Friday, March 28, starting at 12:00 EDT (16:00 UTC) (%2025/%03/%25 %19:%Mar)Join the FSF and friends on Friday, March 28 from 12:00 to 15:00 EDT (16:00 to 19:00 UTC) to help improve the Free Software Directory.

FSF Events: Free Software Directory meeting on IRC: Friday, April 4, starting at 12:00 EDT (16:00 UTC) (%2025/%03/%25 %19:%Mar)Join the FSF and friends on Friday, April 4 from 12:00 to 15:00 EDT (16:00 to 19:00 UTC) to help improve the Free Software Directory.

FSF Events: Community meetup in Lviv, Ukraine (%2025/%03/%25 %18:%Mar)Meet, discuss, work together, plan activities, and cooperate

FSF Blogs: Meet Abelujo, a free software solution for managing bookstores (%2025/%03/%25 %18:%Mar)

gnuboot @ Savannah: New GNU Boot 0.1 RC6 release. (%2025/%03/%24 %21:%Mar)This release is meant to fix multiple security issues that are present in the GRUB version we use (2.06+). Users having replaced the GNU Boot picture / logo with untrusted pictures could have been affected if the pictures they used were specially crafted to exploit a vulnerability in GRUB and take full control of the computer. In general it's a good idea to avoid using untrusted pictures in GRUB or other boot software to limit such risks because software can have bugs (a similar issue also happened in a free software UEFI implementation). Users having implemented various user-respecting flavor(s) of secure-boot, either by using GPG signatures and/or by using a GRUB password combined with full disk encryption are also affected as these security vulnerabilities could enable people to bypass secure-boot schemes. In addition there are also security vulnerabilities in file systems, which also enable execution of code. When booting, GRUB has to load files (like the Linux or linux-libre kernel) that are executed anyway. But in some cases, it could still affect users. This could happen when trying to boot from an USB key, and also having another USB key that has a file system that was crafted to take control of the computer. At the time, no known exploits are known by the GNU Boot maintainers. Why it took so long. -------------------- The 18 February, the GRUB maintainer posted some patches on the grub-devel mailing list in order to notify people that there were some security vulnerabilities in GRUB that were fixed, and which commit fixed them. One of the GNU Boot maintainers saw these patches but didn't read the mails and assumed that a new GRUB release was near and decided to wait for it as this would make things easier as GRUB releases are tested in many different situations. However the thread posting these patches also mentioned that a new release would take too much time and that the GRUB contributors and/or maintainers already had a lot to deal with. It took a while to realize the issue: a second GNU Boot maintainer saw the GRUB security vulnerabilities later on, and at this point they realized that nothing had happened yet on GRUB side yet and they looked into the issue. In addition the computer of one of the GNU Boot maintainer broke, which also delayed the review of the GNU Boot patches meant to fix this security issues. These patches also contain fixes for the GNU Boot build system as well to ensure users building GNU Boot themselves really do get an updated GRUB version. As this is a new release candidate, we also need help for reporting on which computers and/or configuration it works or doesn't work, especially because we had to update to an unreleased GRUB version to get the fixes (see below for more details). Other affected distributions? ----------------------------- We started telling the Canoeboot and Libreboot maintainer about the issue to later find out that the issue was fixed since the 18 February, and their users were also notified via a news, so everything is good on that side. For most 100% free distributions, using GRUB from git would be a significant effort in testing and/or in packaging. We notified Trisquel, Parabola and Guix and the ones who responded are not comfortable with updating GRUB to a not-yet released git revision. Though in the case of Parabola nothing prevent adding a new grub-git package that has no known vulnerabilities in addition to the existing grub package, so patches for that are welcome. As for the other distributions, most of them do support secure boot (by supporting UEFI secure boot), but they are probably aware of the issue as (maintainers of) distributions like Debian or Arch Linux either responded to the thread on the GRUB mailing list, or were mentioned as having fixed the issue in that thread. At the time of writing, the affected GRUBs versions seems not to be blacklisted yet by UEFIs, so it also leaves some time to fix the issue, and things like GRUB password can usually be bypassed easily unless people use distributions like GNU Boot or Canoeboot and configure both the hardware and the software to support a secure boot scheme that respect users freedoms. As for PureOS we just notified them in a bug report as they have UEFI secure boot, but in another hand we don't know if they are aware of that (they are based on Debian so it could be inherited from Debian and not something supported/advertised), and because Purism (the company behind PureOS) ships computers with their own secure boot scheme (PureBoot), since it works in a very different way we are not sure if people could be affected or not. References and details ---------------------- This release should fix the following CVEs affecting previous GRUB 2.06: CVE-2025-0690, CVE-2025-0622, CVE-2024-45775, CVE-2024-45777, CVE-2024-45778, CVE-2024-45779, CVE-2024-45781, CVE-2024-45782, CVE-2024-45783, CVE-2025-0624, CVE-2025-0677, CVE-2025-0684, CVE-2025-0685, CVE-2025-0686, CVE-2025-0689, CVE-2025-1125. More details are available in the "[SECURITY PATCH 00/73] GRUB2 vulnerabilities - 2025/02/18" thread From Daniel Kiper (Tuesday, 18 February 2025, archived online at https://lists.gnu.org/archive/html/grub-devel/2025-02/msg00024.html).

FSF News: GNU Head, Stallman's katana, and Internet Hall of Fame medal auctioned off to free software community members (%2025/%03/%24 %20:%Mar)BOSTON, Massachusetts, USA (Monday, March 24, 2025) the Free Software Foundation (FSF) today announced that, among other historical free software artifacts, the GNU Head found a new home through an unprecedented memorabilia auction.

Simon Josefsson: Reproducible Software Releases (%2025/%03/%24 %11:%Mar)Around a year ago I discussed two concerns with software release archives (tarball artifacts) that could be improved to increase confidence in the supply-chain security of software releases. Repeating the goals for simplicity: Release artifacts should be built in a way that can be reproduced by others It should be possible to build a project from source tarball that doesn’t contain any generated or vendor files (e.g., in the style of git-archive). While implementing these ideas for a small project was accomplished within weeks – see my announcement of Libntlm version 1.8 – adressing this in complex projects uncovered concerns with tools that had to be addressed, and things stalled for many months pending that work. I had the notion that these two goals were easy and shouldn’t be hard to accomplish. I still believe that, but have had to realize that improving tooling to support these goals takes time. It seems clear that these concepts are not universally agreed on and implemented generally. I’m now happy to recap some of the work that led to releases of libtasn1 v4.20.0, inetutils v2.6, libidn2 v2.3.8, libidn v1.43. These releases all achieve these goals. I am working on a bunch of more projects to support these ideas too. What have the obstacles so far been to make this happen? It may help others who are in the same process of addressing these concerns to have a high-level introduction to the issues I encountered. Source code for projects above are available and anyone can look at the solutions to learn how the problems are addressed. First let’s look at the problems we need to solve to make “git-archive” style tarballs usable: Version Handling To build usable binaries from a minimal tarballs, it need to know which version number it is. Traditionally this information was stored inside configure.ac in git. However I use gnulib’s git-version-gen to infer the version number from the git tag or git commit instead. The git tag information is not available in a git-archive tarball. My solution to this was to make use of the export-subst feature of the .gitattributes file. I store the file .tarball-version-git in git containing the magic cookie like this: $Format:%(describe)$ With this, git-archive will replace with a useful version identifier on export, see the libtasn1 patch to achieve this. To make use of this information, the git-version-gen script was enhanced to read this information, see the gnulib patch. This is invoked by ./configure to figure out which version number the package is for. Translations We want translations to be included in the minimal source tarball for it to be buildable. Traditionally these files are retrieved by the maintainer from the Translation project when running ./bootstrap, however there are two problems with this. The first one is that there is no strong authentication or versioning information on this data, the tools just download and place whatever wget downloaded into your source tree (printf-style injection attack anyone?). We could improve this (e.g., publish GnuPG signed translations messages with clear versioning), however I did not work on that further. The reason is that I want to support offline builds of packages. Downloading random things from the Internet during builds does not work when building a Debian package, for example. The translation project could solve this by making a monthly tarball with their translations available, for distributors to pick up and provide as a separate package that could be used as a build dependency. However that is not how these tools and projects are designed. Instead I reverted back to storing translations in git, something that I did for most projects back when I was using CVS 20 years ago. Hooking this into ./bootstrap and gettext workflow can be tricky (ideas for improvement most welcome!), but I used a simple approach to store all directly downloaded po/*.po files directly as po/*.po.in and make the ./bootstrap tool move them in place, see the libidn2 commit followed by the actual ‘make update-po’ commit with all the translations where one essential step is: # Prime po/*.po from fall-back copy stored in git. for poin in po/*.po.in; do po=$(echo $poin | sed 's/.in//') test -f $po || cp -v $poin $po done ls po/*.po | sed 's|.*/||; s|\.po$||' &gt; po/LINGUAS Fetching vendor files like gnulib Most build dependencies are in the shape of “You need a C compiler”. However some come in the shape of “source-code files intended to be vendored”, and gnulib is a huge repository of such files. The latter is a problem when building from a minimal git archive. It is possible to consider translation files as a class of vendor files, since they need to be copied verbatim into the project build directory for things to work. The same goes for *.m4 macros from the GNU Autoconf Archive. However I’m not confident that the solution for all vendor files must be the same. For translation files and for Autoconf Archive macros, I have decided to put these files into git and merge them manually occasionally. For gnulib files, in some projects like OATH Toolkit I also store all gnulib files in git which effectively resolve this concern. (Incidentally, the reason for doing so was originally that running ./bootstrap took forever since there is five gnulib instances used, which is no longer the case since gnulib-tool was rewritten in Python.) For most projects, however, I rely on ./bootstrap to fetch a gnulib git clone when building. I like this model, however it doesn’t work offline. One way to resolve this is to make the gnulib git repository available for offline use, and I’ve made some effort to make this happen via a Gnulib Git Bundle and have explained how to implement this approach for Debian packaging. I don’t think that is sufficient as a generic solution though, it is mostly applicable to building old releases that uses old gnulib files. It won’t work when building from CI/CD pipelines, for example, where I have settled to use a crude way of fetching and unpacking a particular gnulib snapshot, see this Libntlm patch. This is much faster than working with git submodules and cloning gnulib during ./bootstrap. Essentially this is doing: GNULIB_REVISION=$(. bootstrap.conf &gt;&amp;2; echo $GNULIB_REVISION) wget -nv https://gitlab.com/libidn/gnulib-mirror/-/archive/$GNULIB_REVISION/gnulib-mirror-$GNULIB_REVISION.tar.gz gzip -cd gnulib-mirror-$GNULIB_REVISION.tar.gz | tar xf - rm -fv gnulib-mirror-$GNULIB_REVISION.tar.gz export GNULIB_SRCDIR=$PWD/gnulib-mirror-$GNULIB_REVISION ./bootstrap --no-git ./configure make Test the git-archive tarball This goes without saying, but if you don’t test that building from a git-archive style tarball works, you are likely to regress at some point. Use CI/CD techniques to continuously test that a minimal git-archive tarball leads to a usable build. Mission Accomplished So that wasn’t hard, was it? You should now be able to publish a minimal git-archive tarball and users should be able to build your project from it. I recommend naming these archives as PROJECT-vX.Y.Z-src.tar.gz replacing PROJECT with your project name and X.Y.Z with your version number. The archive should have only one sub-directory named PROJECT-vX.Y.Z/ containing all the source-code files. This differentiate it against traditional PROJECT-X.Y.Z.tar.gz tarballs in that it embeds the git tag (which typically starts with v) and contains a wildcard-friendly -src substring. Alas there is no consistency around this naming pattern, and GitLab, GitHub, Codeberg etc all seem to use their own slightly incompatible variant. Let’s go on to see what is needed to achieve reproducible “make dist” source tarballs. This is the release artifact that most users use, and they often contain lots of generated files and vendor files. These files are included to make it easy to build for the user. What are the challenges to make these reproducible? Build dependencies causing different generated content The first part is to realize that if you use tool X with version A to generate a file that goes into the tarball, version B of that tool may produce different outputs. This is a generic concern and it cannot be solved. We want our build tools to evolve and produce better outputs over time. What can be addressed is to avoid needless differences. For example, many tools store timestamps and versioning information in the generated files. This causes needless differences, which makes audits harder. I have worked on some of these, like Autoconf Archive timestamps but solving all of these examples will take a long time, and some upstream are reluctant to incorporate these changes. My approach meanwhile is to build things using similar environments, and compare the outputs for differences. I’ve found that the various closely related forks of GNU/Linux distributions are useful for this. Trisquel 11 is based on Ubuntu 22.04, and building my projects using both and comparing the differences only give me the relevant differences to improve. This can be extended to compare AlmaLinux with RockyLinux (for both versions 8 and 9), Devuan 5 against Debian 12, PureOS 10 with Debian 11, and so on. Timestamps Sometimes tools store timestamps in files in a way that is harder to fix. Two notable examples of this are *.po translation files and Texinfo manuals. For translation files, I have resolved this by making sure the files use a predictable POT-Creation-Date timestamp, and I set it to the modification timestamps of the NEWS file in the repository (which I set to the git commit of the latest commit elsewhere) like this: dist-hook: po-CreationDate-to-mtime-NEWS .PHONY: po-CreationDate-to-mtime-NEWS po-CreationDate-to-mtime-NEWS: mtime-NEWS-to-git-HEAD $(AM_V_GEN)for p in $(distdir)/po/*.po $(distdir)/po/$(PACKAGE).pot; do \ if test -f "$$p"; then \ $(SED) -e 's,POT-Creation-Date: .*\\n",POT-Creation-Date: '"$$(env LC_ALL=C TZ=UTC0 stat --format=%y $(srcdir)/NEWS | cut -c1-16,31-)"'\\n",' &lt; $$p &gt; $$p.tmp &amp;&amp; \ if cmp $$p $$p.tmp &gt; /dev/null; then \ rm -f $$p.tmp; \ else \ mv $$p.tmp $$p; \ fi \ fi \ done Similarily, I set a predictable modification time of the texinfo source file like this: dist-hook: mtime-NEWS-to-git-HEAD .PHONY: mtime-NEWS-to-git-HEAD mtime-NEWS-to-git-HEAD: $(AM_V_GEN)if test -e $(srcdir)/.git \ &amp;&amp; command -v git &gt; /dev/null; then \ touch -m -t "$$(git log -1 --format=%cd \ --date=format-local:%Y%m%d%H%M.%S)" $(srcdir)/NEWS; \ fi However I’ve realized that this needs to happen earlier and probably has to be run during ./configure time, because the doc/version.texi file is generated on first build before running ‘make dist‘ and for some reason the file is not rebuilt at release time. The Automake texinfo integration is a bit inflexible about providing hooks to extend the dependency tracking. The method to address these differences isn’t really important, and they change over time depending on preferences. What is important is that the differences are eliminated. ChangeLog Traditionally ChangeLog files were manually prepared, and still is for some projects. I maintain git2cl but recently I’ve settled with gnulib’s gitlog-to-changelog because doing so avoids another build dependency (although the output formatting is different and arguable worse for my git commit style). So the ChangeLog files are generated from git history. This means a shallow clone will not produce the same ChangeLog file depending on how deep it was cloned. For Libntlm I simply disabled use of generated ChangeLog because I wanted to support an even more extreme form of reproducibility: I wanted to be able to reproduce the full “make dist” source archives from a minimal “git-archive” source archive. However for other projects I’ve settled with a middle ground. I realized that for ‘git describe‘ to produce reproducible outputs, the shallow clone needs to include the last release tag. So it felt acceptable to assume that the clone is not minimal, but instead has some but not all of the history. I settled with the following recipe to produce ChangeLog's covering all changes since the last release. dist-hook: gen-ChangeLog .PHONY: gen-ChangeLog gen-ChangeLog: $(AM_V_GEN)if test -e $(srcdir)/.git; then \ LC_ALL=en_US.UTF-8 TZ=UTC0 \ $(top_srcdir)/build-aux/gitlog-to-changelog \ --srcdir=$(srcdir) -- \ v$(PREV_VERSION)~.. &gt; $(distdir)/cl-t &amp;&amp; \ { printf '\n\nSee the source repo for older entries\n' \ &gt;&gt; $(distdir)/cl-t &amp;&amp; \ rm -f $(distdir)/ChangeLog &amp;&amp; \ mv $(distdir)/cl-t $(distdir)/ChangeLog; } \ fi I’m undecided about the usefulness of generated ChangeLog files within ‘make dist‘ archives. Before we have stable and secure archival of git repositories widely implemented, I can see some utility of this in case we lose all copies of the upstream git repositories. I can sympathize with the concept of ChangeLog files died when we started to generate them from git logs: the files no longer serve any purpose, and we can ask people to go look at the git log instead of reading these generated non-source files. Long-term reproducible trusted build environment Distributions comes and goes, and old releases of them goes out of support and often stops working. Which build environment should I chose to build the official release archives? To my knowledge only Guix offers a reliable way to re-create an older build environment (guix gime-machine) that have bootstrappable properties for additional confidence. However I had two difficult problems here. The first one was that I needed Guix container images that were usable in GitLab CI/CD Pipelines, and this side-tracked me for a while. The second one delayed my effort for many months, and I was inclined to give up. Libidn distribute a C# implementation. Some of the C# source code files included in the release tarball are generated. By what? You guess it, by a C# program, with the source code included in the distribution. This means nobody could reproduce the source tarball of Libidn without trusting someone elses C# compiler binaries, which were built from binaries of earlier releases, chaining back into something that nobody ever attempts to build any more and likely fail to build due to bit-rot. I had two basic choices, either remove the C# implementation from Libidn (which may be a good idea for other reasons, since the C and C# are unrelated implementations) or build the source tarball on some binary-only distribution like Trisquel. Neither felt appealing to me, but a late christmas gift of a reproducible Mono came to Guix that resolve this. Embedded images in Texinfo manual For Libidn one section of the manual has an image illustrating some concepts. The PNG, PDF and EPS outputs were generated via fig2dev from a *.fig file (hello 1985!) that I had stored in git. Over time, I had also started to store the generated outputs because of build issues. At some point, it was possible to post-process the PDF outputs with grep to remove some timestamps, however with compression this is no longer possible and actually the grep command I used resulted in a 0-byte output file. So my embedded binaries in git was no longer reproducible. I first set out to fix this by post-processing things properly, however I then realized that the *.fig file is not really easy to work with in a modern world. I wanted to create an image from some text-file description of the image. Eventually, via the Guix manual on guix graph, I came to re-discover the graphviz language and tool called dot (hello 1993!). All well then? Oh no, the PDF output embeds timestamps. Binary editing of PDF’s no longer work through simple grep, remember? I was back where I started, and after some (soul- and web-) searching I discovered that Ghostscript (hello 1988!) pdfmarks could be used to modify things here. Cooperating with automake’s texinfo rules related to make dist proved once again a worthy challenge, and eventually I ended up with a Makefile.am snippet to build images that could be condensed into: info_TEXINFOS = libidn.texi libidn_TEXINFOS += libidn-components.png imagesdir = $(infodir) images_DATA = libidn-components.png EXTRA_DIST += components.dot DISTCLEANFILES = \ libidn-components.eps libidn-components.png libidn-components.pdf libidn-components.eps: $(srcdir)/components.dot $(AM_V_GEN)$(DOT) -Nfontsize=9 -Teps &lt; $&lt; &gt; $@.tmp $(AM_V_at)! grep %%CreationDate $@.tmp $(AM_V_at)mv $@.tmp $@ libidn-components.pdf: $(srcdir)/components.dot $(AM_V_GEN)$(DOT) -Nfontsize=9 -Tpdf &lt; $&lt; &gt; $@.tmp # A simple sed on CreationDate is no longer possible due to compression. # 'exiftool -CreateDate' is alternative to 'gs', but adds ~4kb to file. # Ghostscript add &lt;1kb. Why can't 'dot' avoid setting CreationDate? $(AM_V_at)printf '[ /ModDate ()\n /CreationDate ()\n /DOCINFO pdfmark\n' &gt; pdfmarks $(AM_V_at)$(GS) -q -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=$@.tmp2 $@.tmp pdfmarks $(AM_V_at)rm -f $@.tmp pdfmarks $(AM_V_at)mv $@.tmp2 $@ libidn-components.png: $(srcdir)/components.dot $(AM_V_GEN)$(DOT) -Nfontsize=9 -Tpng &lt; $&lt; &gt; $@.tmp $(AM_V_at)mv $@.tmp $@ pdf-recursive: libidn-components.pdf dvi-recursive: libidn-components.eps ps-recursive: libidn-components.eps info-recursive: $(top_srcdir)/.version libidn-components.png Surely this can be improved, but I’m not yet certain in what way is the best one forward. I like having a text representation as the source of the image. I’m sad that the new image size is ~48kb compared to the old image size of ~1kb. I tried using exiftool -CreateDate as an alternative to GhostScript, but using it to remove the timestamp added ~4kb to the file size and naturally I was appalled by this ignorance of impending doom. Test reproducibility of tarball Again, you need to continuously test the properties you desire. This means building your project twice using different environments and comparing the results. I’ve settled with a small GitLab CI/CD pipeline job that perform bit-by-bit comparison of generated ‘make dist’ archives. It also perform bit-by-bit comparison of generated ‘git-archive’ artifacts. See the Libidn2 .gitlab-ci.yml 0-compare job which essentially is: 0-compare: image: alpine:latest stage: repro needs: [ B-AlmaLinux8, B-AlmaLinux9, B-RockyLinux8, B-RockyLinux9, B-Trisquel11, B-Ubuntu2204, B-PureOS10, B-Debian11, B-Devuan5, B-Debian12, B-gcc, B-clang, B-Guix, R-Guix, R-Debian12, R-Ubuntu2404, S-Trisquel10, S-Ubuntu2004 ] script: - cd out - sha256sum */*.tar.* */*/*.tar.* | sort | grep -- -src.tar. - sha256sum */*.tar.* */*/*.tar.* | sort | grep -v -- -src.tar. - sha256sum */*.tar.* */*/*.tar.* | sort | uniq -c -w64 | sort -rn - sha256sum */*.tar.* */*/*.tar.* | grep -- -src.tar. | sort | uniq -c -w64 | grep -v '^ 1 ' - sha256sum */*.tar.* */*/*.tar.* | grep -v -- -src.tar. | sort | uniq -c -w64 | grep -v '^ 1 ' # Confirm modern git-archive tarball reproducibility - cmp b-almalinux8/src/*.tar.gz b-almalinux9/src/*.tar.gz - cmp b-almalinux8/src/*.tar.gz b-rockylinux8/src/*.tar.gz - cmp b-almalinux8/src/*.tar.gz b-rockylinux9/src/*.tar.gz - cmp b-almalinux8/src/*.tar.gz b-debian12/src/*.tar.gz - cmp b-almalinux8/src/*.tar.gz b-devuan5/src/*.tar.gz - cmp b-almalinux8/src/*.tar.gz r-guix/src/*.tar.gz - cmp b-almalinux8/src/*.tar.gz r-debian12/src/*.tar.gz - cmp b-almalinux8/src/*.tar.gz r-ubuntu2404/src/*v2.*.tar.gz # Confirm old git-archive (export-subst but long git describe) tarball reproducibility - cmp b-trisquel11/src/*.tar.gz b-ubuntu2204/src/*.tar.gz # Confirm really old git-archive (no export-subst) tarball reproducibility - cmp b-debian11/src/*.tar.gz b-pureos10/src/*.tar.gz # Confirm 'make dist' generated tarball reproducibility - cmp b-almalinux8/*.tar.gz b-rockylinux8/*.tar.gz - cmp b-almalinux9/*.tar.gz b-rockylinux9/*.tar.gz - cmp b-pureos10/*.tar.gz b-debian11/*.tar.gz - cmp b-devuan5/*.tar.gz b-debian12/*.tar.gz - cmp b-trisquel11/*.tar.gz b-ubuntu2204/*.tar.gz - cmp b-guix/*.tar.gz r-guix/*.tar.gz # Confirm 'make dist' from git-archive tarball reproducibility - cmp s-trisquel10/*.tar.gz s-ubuntu2004/*.tar.gz Notice that I discovered that ‘git archive’ outputs differ over time too, which is natural but a bit of a nuisance. The output of the job is illuminating in the way that all SHA256 checksums of generated tarballs are included, for example the libidn2 v2.3.8 job log: $ sha256sum */*.tar.* */*/*.tar.* | sort | grep -v -- -src.tar. 368488b6cc8697a0a937b9eb307a014396dd17d3feba3881e6911d549732a293 b-trisquel11/libidn2-2.3.8.tar.gz 368488b6cc8697a0a937b9eb307a014396dd17d3feba3881e6911d549732a293 b-ubuntu2204/libidn2-2.3.8.tar.gz 59db2d045fdc5639c98592d236403daa24d33d7c8db0986686b2a3056dfe0ded b-debian11/libidn2-2.3.8.tar.gz 59db2d045fdc5639c98592d236403daa24d33d7c8db0986686b2a3056dfe0ded b-pureos10/libidn2-2.3.8.tar.gz 5bd521d5ecd75f4b0ab0fc6d95d444944ef44a84cad859c9fb01363d3ce48bb8 s-trisquel10/libidn2-2.3.8.tar.gz 5bd521d5ecd75f4b0ab0fc6d95d444944ef44a84cad859c9fb01363d3ce48bb8 s-ubuntu2004/libidn2-2.3.8.tar.gz 7f1dcdea3772a34b7a9f22d6ae6361cdcbe5513e3b6485d40100b8565c9b961a b-almalinux8/libidn2-2.3.8.tar.gz 7f1dcdea3772a34b7a9f22d6ae6361cdcbe5513e3b6485d40100b8565c9b961a b-rockylinux8/libidn2-2.3.8.tar.gz 8031278157ce43b5813f36cf8dd6baf0d9a7f88324ced796765dcd5cd96ccc06 b-clang/libidn2-2.3.8.tar.gz 8031278157ce43b5813f36cf8dd6baf0d9a7f88324ced796765dcd5cd96ccc06 b-debian12/libidn2-2.3.8.tar.gz 8031278157ce43b5813f36cf8dd6baf0d9a7f88324ced796765dcd5cd96ccc06 b-devuan5/libidn2-2.3.8.tar.gz 8031278157ce43b5813f36cf8dd6baf0d9a7f88324ced796765dcd5cd96ccc06 b-gcc/libidn2-2.3.8.tar.gz 8031278157ce43b5813f36cf8dd6baf0d9a7f88324ced796765dcd5cd96ccc06 r-debian12/libidn2-2.3.8.tar.gz acf5cbb295e0693e4394a56c71600421059f9c9bf45ccf8a7e305c995630b32b r-ubuntu2404/libidn2-2.3.8.tar.gz cbdb75c38100e9267670b916f41878b6dbc35f9c6cbe60d50f458b40df64fcf1 b-almalinux9/libidn2-2.3.8.tar.gz cbdb75c38100e9267670b916f41878b6dbc35f9c6cbe60d50f458b40df64fcf1 b-rockylinux9/libidn2-2.3.8.tar.gz f557911bf6171621e1f72ff35f5b1825bb35b52ed45325dcdee931e5d3c0787a b-guix/libidn2-2.3.8.tar.gz f557911bf6171621e1f72ff35f5b1825bb35b52ed45325dcdee931e5d3c0787a r-guix/libidn2-2.3.8.tar.gz I’m sure I have forgotten or suppressed some challenges (sprinkling LANG=C TZ=UTC0 helps) related to these goals, but my hope is that this discussion of solutions will inspire you to implement these concepts for your software project too. Please share your thoughts and additional insights in a comment below. Enjoy Happy Hacking in the course of practicing this!

parallel @ Savannah: GNU Parallel 20250322 ('Have you said thank you') released (%2025/%03/%23 %12:%Mar)GNU Parallel 20250322 ('Have you said thank you') has been released. It is available for download at: lbry://@GnuParallel:4 Quote of the month: te amo gnu parallel -- Ayleen I. C. @ayleen_ic New in this release: When hitting a --milestone, wait until running jobs are done before starting more jobs. Append 'auto' to --jobs and GNU Parallel will lower the number of jobs if jobs fail and raise it up to the given number if they succeed. --unsafe now treats UFT8 as safe and only warns. Bug fixes and man page updates. News about GNU Parallel: Running programs in parallel https://medium.com/opsops/running-programs-in-parallel-b332b1898c8e Using ‘xargs’ and GNU Parallel for Bulk File Operations https://www.heatware.net/linux/bulk-processing-with-xargs-parallel/ Bashスクリプト高速化のための実践テクニック：並列処理、xargs活用、バックグラウンドジョブの使い方 https://bashdo.com/2025/02/26/bash%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%83%88%E9%AB%98%E9%80%9F%E5%8C%96%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E5%AE%9F%E8%B7%B5%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%EF%BC%9A%E4%B8%A6/ GNU Parallel - For people who live life in the parallel lane. If you like GNU Parallel record a video testimonial: Say who you are, what you use GNU Parallel for, how it helps you, and what you like most about it. Include a command that uses GNU Parallel if you feel like it. About GNU Parallel GNU Parallel is a shell tool for executing jobs in parallel using one or more computers. A job can be a single command or a small script that has to be run for each of the lines in the input. The typical input is a list of files, a list of hosts, a list of users, a list of URLs, or a list of tables. A job can also be a command that reads from a pipe. GNU Parallel can then split the input and pipe it into commands in parallel. If you use xargs and tee today you will find GNU Parallel very easy to use as GNU Parallel is written to have the same options as xargs. If you write loops in shell, you will find GNU Parallel may be able to replace most of the loops and make them run faster by running several jobs in parallel. GNU Parallel can even replace nested loops. GNU Parallel makes sure output from the commands is the same output as you would get had you run the commands sequentially. This makes it possible to use output from GNU Parallel as input for other programs. For example you can run this to convert all jpeg files into png and gif files and have a progress bar: parallel --bar convert {1} {1.}.{2} ::: *.jpg ::: png gif Or you can generate big, medium, and small thumbnails of all jpeg files in sub dirs: find . -name '*.jpg' | parallel convert -geometry {2} {1} {1//}/thumb{2}_{1/} :::: - ::: 50 100 200 You can find more about GNU Parallel at: http://www.gnu.org/s/parallel/ You can install GNU Parallel in just 10 seconds with: $ (wget -O - pi.dk/3 || lynx -source pi.dk/3 || curl pi.dk/3/ || \ fetch -o - http://pi.dk/3 ) &gt; install.sh $ sha1sum install.sh | grep c555f616391c6f7c28bf938044f4ec50 12345678 c555f616 391c6f7c 28bf9380 44f4ec50 $ md5sum install.sh | grep 707275363428aa9e9a136b9a7296dfe4 70727536 3428aa9e 9a136b9a 7296dfe4 $ sha512sum install.sh | grep b24bfe249695e0236f6bc7de85828fe1f08f4259 83320d89 f56698ec 77454856 895edc3e aa16feab 2757966e 5092ef2d 661b8b45 b24bfe24 9695e023 6f6bc7de 85828fe1 f08f4259 6ce5480a 5e1571b2 8b722f21 $ bash install.sh Watch the intro video on http://www.youtube.com/playlist?list=PL284C9FF2488BC6D1 Walk through the tutorial (man parallel_tutorial). Your command line will love you for it. When using programs that use GNU Parallel to process data for publication please cite: O. Tange (2018): GNU Parallel 2018, March 2018, https://doi.org/10.5281/zenodo.1146014. If you like GNU Parallel: Give a demo at your local user group/team/colleagues Post the intro videos on Reddit/Diaspora*/forums/blogs/ Identi.ca/Google+/Twitter/Facebook/Linkedin/mailing lists Get the merchandise https://gnuparallel.threadless.com/designs/gnu-parallel Request or write a review for your favourite blog or magazine Request or build a package for your favourite distribution (if it is not already there) Invite me for your next conference If you use programs that use GNU Parallel for research: Please cite GNU Parallel in you publications (use --citation) If GNU Parallel saves you money: (Have your company) donate to FSF https://my.fsf.org/donate/ About GNU SQL GNU sql aims to give a simple, unified interface for accessing databases through all the different databases' command line clients. So far the focus has been on giving a common way to specify login information (protocol, username, password, hostname, and port number), size (database and table size), and running queries. The database is addressed using a DBURL. If commands are left out you will get that database's interactive shell. When using GNU SQL for a publication please cite: O. Tange (2011): GNU SQL - A Command Line Tool for Accessing Different Databases Using DBURLs, ;login: The USENIX Magazine, April 2011:29-32. About GNU Niceload GNU niceload slows down a program when the computer load average (or other system activity) is above a certain limit. When the limit is reached the program will be suspended for some time. If the limit is a soft limit the program will be allowed to run for short amounts of time before being suspended again. If the limit is a hard limit the program will only be allowed to run when the system is below the limit.

mailutils @ Savannah: GNU mailutils version 3.19 (%2025/%03/%22 %15:%Mar)Version 3.19 of GNU mailutils is available for download. This is a bug-fixing release. Noteworthy changes are: mail: part specifier accepted after any message designator filters: revise buffer requirements when requesting more input/output libproto tests: link using the libtool archives Fix testsuite (mda &amp; mail) to work with arbitrary default mailbox type

gdbm @ Savannah: GDBM version 1.25 (%2025/%03/%22 %14:%Mar)GNU DBM version 1.25 is available for download. New in this release: New function: gdbm_open_ext This function provides a general-purpose interface for opening and creating GDBM files. It combines the possibilities of gdbm_open and gdbm_fd_open and provides detailed control over database file locking. New gdbmtool command: collisions The command prints the collision chains for the current bucket, or for buckets identified by its arguments. Pipelines in gdbmtool The output of a gdbmtool command can be connected to the input of a shell command using the traditional pipeline syntax. Bugfixes Fix a bug in block coalescing code. Other minor fixes.

GNU Artanis: How to make i18n properly (%2025/%03/%22 %14:%Mar)

FSF Blogs: Only one day left to win a piece of free software history in the silent auction (%2025/%03/%20 %14:%Mar)Our first-ever Silent Memorabilia Auction will end tomorrow, March 21, at 15:00 EDT (19:00 UTC). This is your last chance to bid!

Jose E. Marchesi: Homepage for Algol 68 (%2025/%03/%20 %08:%Mar) The Algol 68 programming language got a new homepage: https://www.algol68-lang.org.

FSF Events: Free Software Directory meeting on IRC: Friday, March 21, starting at 12:00 EDT (16:00 UTC) (%2025/%03/%18 %19:%Mar)Join the FSF and friends on Friday, March 21 from 12:00 to 15:00 EDT (16:00 to 19:00 UTC) to help improve the Free Software Directory.

GNUnet News: GNUnet 0.24.0 (%2025/%03/%13 %23:%Mar) GNUnet 0.24.0 released We are pleased to announce the release of GNUnet 0.24.0. GNUnet is an alternative network stack for building secure, decentralized and privacy-preserving distributed applications. Our goal is to replace the old insecure Internet protocol stack. Starting from an application for secure publication of files, it has grown to include all kinds of basic protocol components and applications towards the creation of a GNU internet. This is a new major release. Major versions may break protocol compatibility with the 0.23.0X versions. Please be aware that Git master is thus henceforth (and has been for a while) INCOMPATIBLE with the 0.23.0X GNUnet network, and interactions between old and new peers will result in issues. In terms of usability, users should be aware that there are still a number of known open issues in particular with respect to ease of use, but also some critical privacy issues especially for mobile users. Also, the nascent network is tiny and thus unlikely to provide good anonymity or extensive amounts of interesting information. As a result, the 0.24.0 release is still only suitable for early adopters with some reasonable pain tolerance . After almost a year of testing we believe that the meson build system is stable enough that it can be used as the default build system. In order to reduce maintenance overhead, we are planning to phase out the autotools build until the next major release. Meson shows up to 10x better development build times. It also facilitates building a single libgnunet.so for future requirements of a monolithic build on other platforms such as Android. Download links gnunet-0.24.0.tar.gz ( signature ) gnunet-gtk-0.24.0.tar.gz ( signature ) gnunet-fuse-0.24.0.tar.gz ( signature ) The GPG key used to sign is: 3D11063C10F98D14BD24D1470B0998EF86F59B6A Note that due to mirror synchronization, not all links might be functional early after the release. For direct access try http://ftp.gnu.org/gnu/gnunet/ Changes A detailed list of changes can be found in the git log , the NEWS and the bug tracker . Noteworthy highlights are Build system: After almost a year of testing we believe that the meson build system is stable enough that it can be used as the default build system. In order to reduce maintenance overhead, we are planning to phase out the autotools build until the next major release. Known Issues There are known major design issues in the CORE subsystems which will need to be addressed in the future to achieve acceptable usability, performance and security. There are known moderate implementation limitations in CADET that negatively impact performance. There are known moderate design issues in FS that also impact usability and performance. There are minor implementation limitations in SET that create unnecessary attack surface for availability. The RPS subsystem remains experimental. In addition to this list, you may also want to consult our bug tracker at bugs.gnunet.org which lists about 190 more specific issues. Thanks This release was the work of many people. The following people contributed code and were thus easily identified: Christian Grothoff, Florian Dold, dvn, TheJackiMonster, oec, ch3, and Martin Schanzenbach.

FSF Events: Free Software Directory meeting on IRC: Friday, March 14, starting at 12:00 EDT (16:00 UTC) (%2025/%03/%12 %18:%Mar)Join the FSF and friends on Friday, March 14 from 12:00 to 15:00 EDT (16:00 to 19:00 UTC) to help improve the Free Software Directory.

FSF News: FSF launches pre-bid phase for silent memorabilia auction (%2025/%03/%11 %20:%Mar)BOSTON, Massachusetts, USA (March 11, 2025) -- The Free Software Foundation (FSF) has published the memorabilia items for bidding in the silent auction on the LibrePlanet wiki. Starting March 17, the FSF will unlock items each day for bidding on the LibrePlanet wiki at 12:00 EDT until March 20. Bidding on all items will conclude at 15:00 EDT on March 21, 2025.

poke @ Savannah: GNU poke 4.3 released (%2025/%03/%10 %23:%Mar)I am happy to announce a new release of GNU poke, version 4.3. This is a bugfix release in the 4.x series. See the file NEWS in the distribution tarball for a list of issues fixed in this release. The tarball poke-4.3.tar.gz is now available at https://ftp.gnu.org/gnu/poke/poke-4.3.tar.gz. &gt; GNU poke (http://www.jemarch.net/poke) is an interactive, extensible &gt; editor for binary data. Not limited to editing basic entities such &gt; as bits and bytes, it provides a full-fledged procedural, &gt; interactive programming language designed to describe data &gt; structures and to operate on them. Thanks to the people who contributed with code and/or documentation to this release. Happy poking! Mohammad-Reza Nabipoor

FSF News: Subasta de la Free Software Foundation de dibujos originales de GNU, premios y tecnología histórica (%2025/%03/%03 %20:%Mar)

FSF News: FSF defends user freedom in amicus brief submitted in Neo4j v. Suhy (%2025/%03/%03 %17:%Mar)BOSTON, Massachusetts, USA (March 3, 2025) -- The Free Software Foundation (FSF) announced today it has submitted an amicus brief in the case entitled Neo4j, Inc., et al. v. Suhy, et al., Case No. 24-5538 in the United States Court of Appeals for the Ninth Circuit. The amicus brief addresses various misstatements and baseless assertions regarding the FSF and the GNU Affero General Public License Version 3 (AGPLv3) -- the license at issue in the case -- found in a pleading filed by Neo4j.

www @ Savannah: Richard Stallman Interviewed in Bolzano, Italy (%2025/%03/%02 %20:%Mar)Richard Stallman was interviewed during his visit to the University of Bozen-Bolzano, Italy, in February. Clear questions with short, simply worded answers suitable for students and newcomers to the free software world.

Trisquel GNU/Linux (%2025/%02/%26 %02:%Feb)n/a

gettext @ Savannah: GNU gettext 0.24 released (%2025/%02/%25 %14:%Feb)Download from https://ftp.gnu.org/pub/gnu/gettext/gettext-0.24.tar.gz New in this release: Programming languages support: JavaScript: xgettext now parses recursive JSX expressions correctly. Rust: xgettext now supports Rust. 'msgfmt -c' now verifies the syntax of translations of Rust format strings. A new example 'hello-rust' has been added. C: A new example 'hello-c-http' has been added, showing the use of GNU gettext in a multithreaded web server. C++: A new example 'hello-c++-gnome3' has been added. Ruby: A new example 'hello-ruby' has been added. Improvements for maintainers: When xgettext creates the POT file of a package under Git version control, the 'POT-Creation-Date' in the POT file usually no longer changes gratuitously each time the POT file is regenerated. Caveat maintainers: Building the po/ directory now requires GNU make on specific platforms: macOS, Solaris, AIX.

parallel @ Savannah: GNU Parallel 20250222 ('Grete Tange') released [stable] (%2025/%02/%22 %17:%Feb)GNU Parallel 20250222 ('Grete Tange') has been released. It is available for download at: lbry://@GnuParallel:4 Quote of the month: Use GNU Parallel and thank me later -- pratikbin | NodeOps @pratikbin New in this release: No new features. This is a candidate for a stable release. Bug fixes and man page updates. News about GNU Parallel: Execute programs in parallel https://fekir.info/post/execute-programs-in-parallel/ GNU Parallel を触れてみる https://blog.yamano.dev/posts/3fa121b4c7a971aacf564509a1077fb7/ GNU Parallel is a Time Saver https://ramanenka.dev/gnu-parallel/ GNU Parallel - For people who live life in the parallel lane. If you like GNU Parallel record a video testimonial: Say who you are, what you use GNU Parallel for, how it helps you, and what you like most about it. Include a command that uses GNU Parallel if you feel like it. About GNU Parallel GNU Parallel is a shell tool for executing jobs in parallel using one or more computers. A job can be a single command or a small script that has to be run for each of the lines in the input. The typical input is a list of files, a list of hosts, a list of users, a list of URLs, or a list of tables. A job can also be a command that reads from a pipe. GNU Parallel can then split the input and pipe it into commands in parallel. If you use xargs and tee today you will find GNU Parallel very easy to use as GNU Parallel is written to have the same options as xargs. If you write loops in shell, you will find GNU Parallel may be able to replace most of the loops and make them run faster by running several jobs in parallel. GNU Parallel can even replace nested loops. GNU Parallel makes sure output from the commands is the same output as you would get had you run the commands sequentially. This makes it possible to use output from GNU Parallel as input for other programs. For example you can run this to convert all jpeg files into png and gif files and have a progress bar: parallel --bar convert {1} {1.}.{2} ::: *.jpg ::: png gif Or you can generate big, medium, and small thumbnails of all jpeg files in sub dirs: find . -name '*.jpg' | parallel convert -geometry {2} {1} {1//}/thumb{2}_{1/} :::: - ::: 50 100 200 You can find more about GNU Parallel at: http://www.gnu.org/s/parallel/ You can install GNU Parallel in just 10 seconds with: $ (wget -O - pi.dk/3 || lynx -source pi.dk/3 || curl pi.dk/3/ || \ fetch -o - http://pi.dk/3 ) &gt; install.sh $ sha1sum install.sh | grep c555f616391c6f7c28bf938044f4ec50 12345678 c555f616 391c6f7c 28bf9380 44f4ec50 $ md5sum install.sh | grep 707275363428aa9e9a136b9a7296dfe4 70727536 3428aa9e 9a136b9a 7296dfe4 $ sha512sum install.sh | grep b24bfe249695e0236f6bc7de85828fe1f08f4259 83320d89 f56698ec 77454856 895edc3e aa16feab 2757966e 5092ef2d 661b8b45 b24bfe24 9695e023 6f6bc7de 85828fe1 f08f4259 6ce5480a 5e1571b2 8b722f21 $ bash install.sh Watch the intro video on http://www.youtube.com/playlist?list=PL284C9FF2488BC6D1 Walk through the tutorial (man parallel_tutorial). Your command line will love you for it. When using programs that use GNU Parallel to process data for publication please cite: O. Tange (2018): GNU Parallel 2018, March 2018, https://doi.org/10.5281/zenodo.1146014. If you like GNU Parallel: Give a demo at your local user group/team/colleagues Post the intro videos on Reddit/Diaspora*/forums/blogs/ Identi.ca/Google+/Twitter/Facebook/Linkedin/mailing lists Get the merchandise https://gnuparallel.threadless.com/designs/gnu-parallel Request or write a review for your favourite blog or magazine Request or build a package for your favourite distribution (if it is not already there) Invite me for your next conference If you use programs that use GNU Parallel for research: Please cite GNU Parallel in you publications (use --citation) If GNU Parallel saves you money: (Have your company) donate to FSF https://my.fsf.org/donate/ About GNU SQL GNU sql aims to give a simple, unified interface for accessing databases through all the different databases' command line clients. So far the focus has been on giving a common way to specify login information (protocol, username, password, hostname, and port number), size (database and table size), and running queries. The database is addressed using a DBURL. If commands are left out you will get that database's interactive shell. When using GNU SQL for a publication please cite: O. Tange (2011): GNU SQL - A Command Line Tool for Accessing Different Databases Using DBURLs, ;login: The USENIX Magazine, April 2011:29-32. About GNU Niceload GNU niceload slows down a program when the computer load average (or other system activity) is above a certain limit. When the limit is reached the program will be suspended for some time. If the limit is a soft limit the program will be allowed to run for short amounts of time before being suspended again. If the limit is a hard limit the program will only be allowed to run when the system is below the limit.

remotecontrol @ Savannah: Tado told users it would start charging for its app (%2025/%02/%21 %15:%Feb)https://www.theverge.com/news/615975/tado-smart-thermostat-tests-app-fee

www-zh-cn @ Savannah: Welcome our new member - LS-Shandong (%2025/%02/%18 %00:%Feb)Hi, All: Please join me in welcoming our new member: User Details: ------------- Name: LS-Shandong Login: ls_shandong Email: ls-shandong@outlook.com I wish LS-Shandong a wonderful journey in GNU CTT. Happy Hacking wxie

GNU Artanis: The best practice to port Scheme application to Artanis (%2025/%02/%07 %19:%Feb)

GNU Artanis: Why you should port Scheme application to GNU Artanis (%2025/%02/%07 %19:%Feb)

GNU Artanis: MVC in GNU Artanis (%2025/%02/%07 %19:%Feb)

FSF News: Free Software Foundation auction: Thank you all for joining! (%2025/%02/%04 %21:%Feb)BOSTON, Massachusetts, USA (February 4, 2025) -- The Free Software Foundation (FSF) turns forty this year.

health @ Savannah: Hugo Mendoza Hospital launches GNU Health to transform pediatric health (%2025/%02/%04 %12:%Feb)In a decisive step towards the modernization of healthcare in the country, the Dr. Hugo Mendoza Pediatric Hospital (HPHM) has officially presented its new GNU Health Management System. This digital platform, designed to optimize both medical care and administrative processes, marks a significant advance in the digital transformation of pediatric services in the Dominican Republic. The launch of the innovative system was attended by José Miguel Rodríguez, deputy administrative director of the hospital, who highlighted the importance of digitalization in improving healthcare services. “We are starting a new era in children's health. With GNU Health, doctors will have faster and more efficient access to medical information, which will enable more informed decisions and ensure safer and more timely care,” said Rodríguez during the event. Dhamelisse Then, director of the hospital, highlighted the impact this new tool will have on the quality of the services offered. “The integration of GNU Health not only improves service, but also reinforces our commitment to innovation and excellence in pediatric care. This advance will be fundamental for the lives of thousands of children and their families,” said Then. Tranlated from source: https://cdn.com.do/nacionales/hospital-hugo-mendoza-lanza-innovador-software-para-transformar-la-salud-pediatrica/

gtypist @ Savannah: GNU Typist 2.10.1 released (%2025/%02/%03 %14:%Feb)This is a minor release Changes in 2.10.1: - update the Spanish translation - fix in gtypits.typ, to jump from the global menu to the menus of the individual lessons - small fix to u.typ lesson - remove cmdline.c and cmdline.h files from the git repo; this will only affect those who build from git sources; dependency to gengetopt added to README.git - include the version.sh file, so autoconf can always update project version Addendum: since v2.10, gtypist is saving configuration setting in the file .gtypistrc Sources for this release can be downloaded here: https://ftp.gnu.org/gnu/gtypist/gtypist-2.10.1.tar.gz

diffutils @ Savannah: diffutils-3.11 released [stable] (%2025/%02/%03 %05:%Feb) This is to announce diffutils-3.11, a stable release. Special thanks to Paul Eggert for doing the vast majority of the work and to Bruno Haible for his many changes here and his tons of work tending gnulib. There have been 252 commits by 5 people in the 89 weeks since 3.10. See the NEWS below for a brief summary. Thanks to everyone who has contributed! The following people contributed changes to this release: Bruno Haible (12) Collin Funk (3) Gleb Fotengauer-Malinovskiy (1) Jim Meyering (26) Paul Eggert (210) Jim [on behalf of the diffutils maintainers] ================================================================== Here is the GNU diffutils home page: https://gnu.org/s/diffutils/ Here are the compressed sources: https://ftp.gnu.org/gnu/diffutils/diffutils-3.11.tar.gz (3.3MB) https://ftp.gnu.org/gnu/diffutils/diffutils-3.11.tar.xz (1.9MB) Here are the GPG detached signatures: https://ftp.gnu.org/gnu/diffutils/diffutils-3.11.tar.gz.sig https://ftp.gnu.org/gnu/diffutils/diffutils-3.11.tar.xz.sig Use a mirror for higher download bandwidth: https://www.gnu.org/order/ftp.html Here are the SHA1 and SHA256 checksums: bc8791022b18a34c7ee9c3079e414f843de0e1a9 diffutils-3.11.tar.gz yAo8K/h+JS/n1gW4umv5KNdakLVfO/z3xKTzN+xi/DE= diffutils-3.11.tar.gz 1cf58ac440fc279b363169a17de3662e03bb266d diffutils-3.11.tar.xz pz7wX+N91YX32HBo5KBjl2BBn4EBOL11xh3aofniEx4= diffutils-3.11.tar.xz Verify the base64 SHA256 checksum with cksum -a sha256 --check from coreutils-9.2 or OpenBSD's cksum since 2007. Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify diffutils-3.11.tar.gz.sig The signature should match the fingerprint of the following key: pub rsa4096/0x7FD9FCCB000BEEEE 2010-06-14 [SCEA] Key fingerprint = 155D 3FC5 00C8 3448 6D1E EA67 7FD9 FCCB 000B EEEE uid [ unknown] Jim Meyering &lt;jim@meyering.net&gt; uid [ unknown] Jim Meyering &lt;meyering@fb.com&gt; uid [ unknown] Jim Meyering &lt;meyering@gnu.org&gt; If that command fails because you don't have the required public key, or that public key has expired, try the following commands to retrieve or refresh it, and then rerun the 'gpg --verify' command. gpg --locate-external-key jim@meyering.net gpg --recv-keys 7FD9FCCB000BEEEE wget -q -O- 'https://savannah.gnu.org/project/release-gpgkeys.php?group=diffutils&amp;download=1' | gpg --import - As a last resort to find the key, you can try the official GNU keyring: wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg gpg --keyring gnu-keyring.gpg --verify diffutils-3.11.tar.gz.sig This release is based on the diffutils git repository, available as git clone https://git.savannah.gnu.org/git/diffutils.git with commit 3f326ae3ea7556e35152e13f01a0a4d8b8b4bc70 tagged as v3.11. For a summary of changes and contributors, see: https://git.sv.gnu.org/gitweb/?p=diffutils.git;a=shortlog;h=v3.11 or run this command from a git-cloned diffutils directory: git shortlog v3.10..v3.11 This release was bootstrapped with the following tools: Autoconf 2.72.47-21cb Automake 1.17.0.91 Gnulib 2025-01-31 553ab924d2b68d930fae5d3c6396502a57852d23 NEWS * Noteworthy changes in release 3.11 (2025-02-02) [stable] ** Improvements Programs now quote file names more consistently in diagnostics. For example; "cmp 'none of' /etc/passwd" now might output "cmp: EOF on ‘none of’ which is empty" instead of outputting "cmp: EOF on none of which is empty". In diagnostic messages that traditionally omit quotes and where backward compatibility seems to be important, programs continue to omit quotes unless a file name contains shell metacharacters, in which case programs use shell quoting. For example, although diff continues to output "Only in a: b" as before for most file names, it now outputs "Only in 'a: b': 'c: d'" instead of "Only in a: b: c: d" because the file names 'a: b' and 'c: d' contain spaces. For compatibility with previous practice, diff -c and -u headers continue to quote for C rather than for the shell. diff now outputs more information when symbolic links differ, e.g., "Symbolic links ‘d/f’ -&gt; ‘a’ and ‘e/f’ -&gt; ‘b’ differ", not just "Symbolic links d/f and e/f differ". Special files too, e.g., "Character special files ‘d/f’ (1, 3) and ‘e/f’ (5, 0) differ", not "File d/f is a character special file while file e/f is a character special file". diff's --ignore-case (-i) and --ignore-file-name-case options now support multi-byte characters. For example, they treat Greek capital Δ like small δ when input uses UTF-8. diff now supports multi-byte characters when treating white space. In options like --expand-tabs (-t), --ignore-space-change (-b) and --ignore-tab-expansion (-E), diff now recognizes non-ASCII space characters and counts columns for non-ASCII characters. ** Bug fixes cmp -bl no longer omits "M-" from bytes with the high bit set in single-byte locales like en_US.iso8859-1. This fix causes the behavior to be locale independent, and to be the same as the longstanding behavior in the C locale and in locales using UTF-8. [bug introduced in 2.9] cmp -i N and -n N no longer fail merely because N is enormous. [bug present since "the beginning"] cmp -s no longer mishandles /proc files, for which the Linux kernel reports a zero size even when nonempty. For example, the following shell command now outputs nothing, as it should: cp /proc/cmdline t; cmp -s /proc/cmdline t || echo files differ [bug present since "the beginning"] diff -E no longer mishandles some input lines containing '\a', '\b', '\f', '\r', '\v', or '\0'. [bug present since 2.8] diff -ly no longer mishandles non-ASCII input. [bug#64461 introduced in 2.9] diff - A/B now works correctly when standard input is a directory, by reading a file named B in that directory. [bug present since "the beginning"] diff no longer suffers from race conditions in some cases when comparing files in a mutating file system. [bug present since "the beginning"] ** Release distribute gzip-compressed tarballs once again

gprofng-gui @ Savannah: gprofng-gui 2.0 released (%2025/%01/%28 %16:%Jan)We are happy to announce the release of GNU gprofng-gui, version 2.0. gprofng GUI is a full-fledged graphical interface for the gprofng profiler, which is part of the GNU binutils. The tarball gprofng-gui-2.0.tar.gz is now available at https://ftp.gnu.org/gnu/gprofng-gui/gprofng-gui-2.0.tar.gz. -- Vladimir Mezentsev Jose E. Marchesi 28 January 2025

GNU Guix: Guix User and Contributor Survey 2024: The Results (part 3) (%2025/%01/%28 %13:%Jan)Today we're looking at the results from the Contributor section of the Guix User and Contributor Survey (2024). The goal was to understand how people contribute to Guix and their overall development experience. A great development experience is important because a Free Software project's sustainability depends on happy contributors to continue the work!See Part 1 for insights about Guix adoption, and Part 2 for users overall experience. With over 900 participants there's lots of interesting insights!Contributor communityThe survey defined someone as a Contributor if they sent patches of any form. That includes changes to code, but also other improvements such as documentation and translations. Some Guix contributors have commit access to the Guix repository, but it's a much more extensive group than those with commit rights.Of the survey's 943 full responses, 297 participants classified themselves as current contributors and 58 as previous contributors, so 355 participants were shown this section.The first question was (Q22), How many patches do you estimate you've contributed to Guix in the last year?Table 21: Guix contributors patch estimatesNumber of patchesCountPercentage1 — 5 patches19061%6 — 20 patches6019%21 — 100 patches3612%100+ patches279%None, but I've contributed in the past42N/ANote that the percentages in this table, and throughout the posts, are rounded up to make them easier to refer to.The percentage is the percentage of contributors that sent patches in the last year. That means the 42 participants who were previous contributors have been excluded.Figure 13 shows this visually:Figure 13: Guix contributor estimated patch countAs we can see many contributors send a few patches (61%), perhaps updating a package that they personally care about. At the other end of the scale, there are a few contributors who send a phenomenal number of patches.Active contributorsIt's interesting to investigate the size of Guix's contributor community. While running the survey I did some separate research to find out the total number of contributors. I defined an Active contributor as someone who had sent a patch in the last two years, which was a total of 454 people. I deduplicated by names, but as this is a count by email address there may be some double counting.This research also showed the actual number of patches that were sent by contributors:Table 22: Active contributors by patch countNumber of patchesCountPercentage of Contributors1 — 5 patches18741%6 — 20 patches10222%21 — 100 patches9120%100+ patches7416%Figure 14 shows this:Figure 14: Active Guix contributors by patch countTogether this give us an interesting picture of the contributor community:There's a good community of active contributors to Guix: 300 in the survey data, and 454 from the direct research.A significant percentage of contributors send one, or a few patches. This reflects that packaging in Guix can be easy to get started with.The direct research shows an even distribution of contributors across the different levels of contribution. This demonstrates that there are some contributors who have been working on Guix for a long-time, as well as newer people joining the team. That's great news for the sustainability of the project!There are also some very committed contributors who have created a lot of patches and been contributing to the project for many years. In fact, the top 10 contributors have all contributed over 700 patches each!Types of contributionThe survey also asked contributors (Q23), How do you participate in the development of Guix?Table 23: Types of contributionType of contributionCountPercentageDevelop new code (patches services, modules, etc)31259%Review patches6512%Triage, handle and test bugs6512%Write documentation387%Quality Assurance (QA) and testing234%Organise the project (e.g. mailing lists, infrastructure etc)163%Localise and translate122%Graphical design and User Experience (UX)20.4%Figure 15 shows this as a pie chart (upping my game!):Figure 15: Guix contribution typesOf course, the same person can contribute in multiple areas: as there were 531 responses to this question, from 355 participants, we can see that's happening.Complex projects like Guix need a variety of contributions, not just code. Guix's web site needs visual designers who have great taste, and certainly a better sense of colour than mine! We need documentation writers to provide the variety of articles and how-tos that we've seen users asking for in the comments. The list goes on!Unsurprisingly, Guix is code heavy with 60% of contributors focusing in this area, but it's great to see that there are people contributing across the project. Perhaps there's a role you can play? ... yes, you reading this post!Paid vs unpaid contributionFOSS projects exist on a continuum of paid and unpaid contribution. Many projects are wholly built by volunteers. Equally, there are many large and complex projects where the reality is that they're built by paid developers — after all, everyone needs to eat!To explore this area the survey then asked (Q24), Are you paid to contribute to Guix?The results show:Table 24: Contributor compensationType of compensationCountPercentageI'm an unpaid volunteer32894%I'm partially paid to work on Guix (e.g. part of my employment or a small grant)195%I'm full-time paid to work on Guix10.3%No answer7N/AWe can see this as Figure 16 :Figure 16: Guix developer compensationSome thoughts:Guix is a volunteer driven project.The best way to work on Guix professionally is to find a way to make it part of your employment.For everyone involved in the project the fact that the majority of contributors are doing it in their spare time has to be factored into everything we do, and how we treat each other.Previous contributorsEnsuring contributors continue to be excited and active in the project is important for it's health. Ultimately, fewer developers means less can be done. In volunteer projects there's always natural churn as contributor's lives change. But, fixing any issues that discourages contributors is important for maintaining a healthy project.Question 25 was targeted at the 59 participants who identified themselves as Previous Contributors. It asked, You previously contributed to Guix, but stopped, why did you stop?The detailed results are:Table 25: Previous contributor analysisCategoryCountPercentage of Previous ContributorsExternal circumstances (e.g. other priorities, not enough time, etc)2835%Response to contributions was slow and/or reviews arduous1215%The contribution process (e.g. email and patch flow)1114%Developing in Guix/Guile was too difficult (e.g. REPL/developer tooling)68%Guix speed and performance34%Project co-ordination, decision making and governance23%Lack of appreciation, acknowledgement and/or loneliness23%Negative interactions with other contributors (i.e. conflict)23%Burnt out from contributing to Guix23%Learning Guix internals was too complex (e.g. poor documentation)11%Social pressure of doing reviews and/or turning down contributions11%Other1013%Figure 17 shows this graphically:Figure 17: Reasons for ceasing to contribute to GuixThere were 80 answers from the 59 participants so some participants chose more than one reason.As we can see a change in external circumstances was the biggest reason and to be expected.The next reason was Response to contributions was slow and/or reviews arduous, as we'll see this repeatedly showed-up as the biggest issue.Next was The contribution process (e.g. email and patch flow) which also appears in many comments. Judging by the comments the email and patch flow may be a gateway factor that puts-off potential contributors from starting. There's no way for the survey to determine this as it only covers people that started contributing and then stopped, but the comments are interesting.Future contributionsQ26 asked contributors to grade their likelihood of contributing further, this is essentially a satisfaction score.The question was, If you currently contribute patches to Guix, how likely are you to do so in the future?Table 26: Future contributions scoringCategoryCountPercentageDefinitely not72%Probably not3410%Moderately likely8023%Likely11131%Certain12335%Figure 18 shows this graphically:Figure 18: Contributor satisfactionOut of the audience of current and previous contributors, 355 in total:The 35% of contributors who are 'Certain' they'll contribute is a great sign.The 31% that are 'Likely' shows that there's a good pool of people who could be encouraged to continue to contribute.We had 58 participants who categoried themselves as Previous Contributors and 41 answered this question with definitely or probably not, that's about 12%. That leaves the 80 (23%) who are loosely positive.Improving contributionThe survey then explored areas of friction for contributors. Anything that reduces friction should increase overall satisfaction for existing contributors.The question (Q27) was, What would help you contribute more to the project?Table 27: Contribution improvementsAnswerCountPercentageTimely reviews and actions taken on contributions20320%Better read-eval-print loop (REPL) and debugging12412%Better performance and tuning (e.g. faster guix pull)10210%Better documentation on Guix's internals (e.g. Guix modules)10010%Guidance and mentoring from more experienced contributors10010%Addition of a pull request workflow like GitHub/Gitlab909%Improved documentation on the contribution process778%Nothing, the limitations to contributing are external to the project657%More acknowledgement of contributions404%More collaborative interactions (e.g. sprints)414%Other566%Figure 19 bar chart visualises this:Figure 19: Improvements for contributorsThe 355 contributors selected 933 options for this question, so many of them selected multiple aspects that would help them to contribute more to the project.Conclusions we can draw are:Ensuring there's Timely reviews and actions taken on contributions is the biggest concern for contributors, and as we saw also causes contributors to become demoralised and cease working on the project.The concern over both Debugging and error messages has been a consistent concern from contributors.Interestingly, documentation of Guix's internals is a priority in this list, but in other questions it doesn't appear as a high priority.Comments on improving contributionJumping ahead, the last question of the contributor section (Q30) was a comment box. It asked, Is there anything else that you would do to improve contributing to Guix?The full list of comments from Q27, and Q30 are available and worth reading (or at least scanning!).Looking across all of them I've created some common themes - picking a couple of example comments to avoid repetition:Compensation for developers: there were comments from developers who want to work on Guix professionally, or people offering to donate."[Part of a long comment] ... For me personally it really boils down to the review process. Some patches just hang there for many months without *any* reaction. That is quite discouraging to be honest. So if there would be fund raising, I think it should (for a large part) go to paying someone (maybe even multiple people?) to do code reviews and merge patches. And in general do the "gardening job" on the issue tracker.""I would be happy to contribute to some kind of fund, maybe by a monthly subscription, which would award stipends for experienced guix contributors to work on patch review."Complexity of contribution: where the overall set of steps required to contribute were too complex."For occasional contributions, the threshold is higher than for most projects, in part due to less common tools used in the project (bugtracker for example)""[long comment where the substance is] I'd rather spend my limited time contributing to a 100% free software project than reading 20 webpages on how to use all the CLI tooling."Issues with email-based contribution: concerns about the steps to create a patch, email it and so forth."Difficult; I am not used to the email workflow and since I'm not contributing often it is close to rediscovering everything again which is annoying. There isn't a specific thing that could solve that I guess. apologies if this doesn't say much""The GNU development process with mailing lists and email patches is the most difficult aspect."Issues with speed and capacity of patch reviews: this is the highest priority amongst contributors, so there were many comments about patches not being reviewed, or reviews taking a long time."I really dislike that 70% of my patches don't get reviewed at all, how simple or trivial they may be. I do really test them and dogfood so contributing seems like a waste of time as someone without commit-access.""I already checked "timely reviews/actions", but I want to emphasize how demoralizing my contribution experience was. I was excited about how easy it was to make, test, and submit a patch; I would love to help improve the packaging situation for things that I use. But it's been about a year now since I submitted some patches and have received exactly 0 communication regarding what I submitted. No reviews, no comments, no merge, nothing. Really took the wind out of my sails"Automate patch testing and acceptance: suggestions to speed up the review pipeline by automating."A bias for action. If no one shows interest in a patch, and it's constrained, it should just be landed.""Minimizing the required work needed to keep packages up to date. Most of the best developers in Guix are commiters and all the time they have to spend reviewing package update patches etc. is away from improving Guix's core. They should be able to focus on things like shepherd, bootloader configuration, guix-daemon in guile, distributed substitutes or a more modular system configuration (e.g. letting nginx know of certbot certificates without having to manually pass (ssl-certificate "/etc/...")).*"Adding more committers: comments that more contributors would increase project velocity, and general concerns about how difficult it is to become a committer."Keep manual up to date, I think we need more committers doing reviews and give more love to darker corners.""All the best. The project might need more hands to review incoming patches."Addition of a pull requests workflow: specific comments requesting the addition of a Forge experience."I would use Forgejo (either an instance or at codeberg) to simplify contributions and issue handling. In my humble and personal opinion the forge workflow makes it much easier to get an overview of what is going on and to interact with others on issues and PRs""I think opening a pull request approach would really modernize the way of working and help welcome more people. We could still easily support patches too."Automating package builds and tests: comments relating to automation of building packages as part of the contribution flow."We really need to improve the CICD situation. I see we have so many system tests that could catch issues. Let's make sure each patch has run at least against a couple of those system tests before it is being merged, or even before a reviewer has even looked at. Today a colleague of mine, who is just getting into Guix because I told him had issues with the u-boot-tools package not being built on a substitute server and being broken. Yeah, that can happen, but it happens all the time and it is such a bad experience for new and existing users."Bugtracker improvements: comments about improving the bug tracker."A formal method to count the number of users affected by an issue so that developers know what to prioritize. For example, ubuntu's launchpad has a "bug heat" metric which counts the number of users that report they are affected by the bug."Debugging and error reporting: challenges debugging issues due to difficult error messages in Guix, or underlying Guile weaknesses."The development workflow with Guile. I've recently switched to arei/ares, but I'm still a total newbie on how to effectively develop and navigate. I've used quite some Common Lisp, and I have my own channel with a handful packages, but it takes a long time to develop without the necessary knowledge of both Guile setup and Guix setup.""I just want to reiterate that the debugging process can be painful sometimes. Sometimes guile gives error messages that can be bewildering. As an example, I spent awhile debugging the error message "no value specified for service of type 'myservice'". The problem was that I omitted the default-value field in my service-type, but the error message could have included the default-value field."Runtime performance and resource usage: where it makes the experience of building and testing Guix slow or unusable."Foremost faster guix evals. I forget what I was doing while it runs.""Building guix takes too long time for packagers. It is not clear why everything needs to be compiled when only contributing a package. Why does the documentation need to be built when adding a package?"Practical guides, how-tos and examples: requests for direct instructions or examples, as compared to reference documentation."Improve the documentation on how to contribute. It is currently very hard to follow, some sections are simply in the wrong order, others presuppose the reader wants to evaluate several different alternatives instead of pointing to one simple way of doing things. And steps that though simple are unusual and will seem complicated to most people don't get explained in sufficient detail and examples."FSF association as a constraint: concerns about Free Software and GNU as an organisation constraining practical user freedom."*Drop GNU and drop the hardline stance against discussing any proprietary software. It doesn't have to be supported directly, but at least have a link to Nonguix or something. Or have a feature flag like Nixpkgs. Who cares if the distro is certified by an organization that is pretty much irrelevant, actually giving people agency over their tech is what should be the number one goal.""Guix is one of the GNU projects with the most potential and relevance, but unfortunately it seems association with the FSF is a contributing factor to limited adoption."Not enough FSF: comments that the Guix project was not sufficiently supportive of FSF and/or Richard Stallman."collaborate more with other GNU projects"Commit messages: concerns that the commit message format is repetitious or unneccessary."Encourage or enforce the usage of commit messages that detail why a change is done (and not what is done - which is already visible from the git diff)."Importers and language ecosystem: comments about possible improvements to deal with dynamic language ecosystems (e.g. Javascript and Rust)."Improved build systems and importers. Generally improving management of high-noise ecosystems (Maven, Rust, NPM, …)""Packaging Golang or Rust apps can be difficult and time-consuming because Guix requires all (recursive) dependencies to be packaged in Guix. I often gave up and just re-packaged a precompiled binary from upstream or another distro. It would be much easier if Guix relied on existing language-specific dependency management (e.g., use Cargo.lock files to fix all dependencies) - not perfect from Guix pov, but pragmatic and much more usable.""More flexible package definitions but also more strict filtering of available packages. For example, allow some packages to use the internet in the build path (so you may easily install pip packages like TensorFlow, Flax), but by default do not allow installation of NonFree licenses and network enabled packages. We allow package transformations (--with-commit) which need network access anyway and doesn't verify hashes, I think this can be allowed. The end goal of a package should be to be reproducible from source, but the current goal can be usability, widespread adoption, reliability. This way we can start to use Guix in more scientific experiments and super computers, then the new users can help contribute further."Project communications methods: requests for communications within the project to use modern methods (e.g. Matrix, Discourse, Github)."Having a Discourse instance, so that people can ask questions and others and chime in and the best answers get upvotes. IRC and mailing lists are suboptimal. My success rate of getting ANY reply to my question have been consistently less than 50% regardless of the time of the day, because in IRC it scrolls down and questions go out of focus. Also in IRC the threads of discussion is getting mixed. Keep the IRC, but provide a Discourse instance. I personally even pay for paart of the cost."Repo organisation: ideas to widen the set of contributors by having a community repo (e.g. Arch Linux like)."I would like more packages under Guix, but I am not convinced that adding them all to the Guix channel is the way. I believe a large number of Guix packages should be moved to guix-free or similar channel. The packages in Guix itself should be the minimal ones that come installed in Guix system. The guix-free channel should be part of default-channels.""I feel like channels are a cumbersome alternative to community packages. I previously tried to package a lesser known programming language compiler for Guix but never got replies to my patches to contribute the package. Perhaps there could be a core and community channel with stronger/weaker standards."Project culture: concerns about the project being inward looking, not inclusive and with too much gatekeeping. Most comments in this area were very passionate, and in some cases a bit angry."TODO lists and direction is very helpful. Lists of "good first task" or "very important — need help with" etc, things to motivate others to contribute in. Also helpful if people ACTUALLY become part of the distro and it's not all gate-kept by idiots with attitude. I don't want to invest 1000 man hours to prove myself worthy of maintanership of a package!"Organisational and social improvementsIt's common in FOSS projects to focus on the technical issues, but Free Software is a social endeavour where organisational and social aspects are just as important. Q28 focused on the social and organisational parts of contribution by asking, What organisational and social areas would you prioritise to improve Guix?This was a ranked question where participants had to prioritise their top 3. The rationale for asking it in this way was to achieve prioritisation.It's useful to look at the results in two ways, first the table where participants set their highest priority (Rank 1):Table 28: Rank 1 — Organisational and social improvementsCategory CountPercentageImprove the speed and capacity of the contribution process21363%Project decision making and co-ordination3611%Fund raising227%Request-for-comments (RFC) process for project-wide decision making175%Regular releases (i.e. release management)196%In-person collaboration and sprints82%Promotion and advocacy237%Out of the 355 participants in this section, 338 answered this question and marked their highest priority.Figure 20 shows it as a pie chart:Figure 20: Organisational and social improvements to GNU Guix (Rank 1)This second table shows how each category was prioritied across all positions:Table 29: All Ranks - Organisational and social improvementsCategory Rank 1Rank 2Rank 3Overall priorityProject decison making and co-ordination2131Promotion and advocacy3312Fund raising4523Request-for-comments (RFC) process for project-wide decision making6244Improve the speed and capacity of the contribution process1665Regular releases (i.e. release management)5456In-person collaboration and sprints7777Figure 21 shows this as a stacked bar chart. Each of the categories is the position for a rank (priority), so the smallest overall priority is the most important:Figure 21: Organisational and social improvements to GNU Guix (All Ranks)Looking at these together:It's clear that the highest priority (table 28) is to Improve the speed and capacity of the contribution process, as 63% of participants selected it and nothing else was close to it.I found it quite confusing that it didn't also score highly in the second and third rank questions, which negatively impacts the overall score. This seems to be caused by the question having a significant drop-off in answers: 338 participants set their 'Rank 1', but only 264 set a 'Rank 2' and then 180 set a 'Rank 3'. The conclusion I draw is that for many contributors the sole important organisational improvement is to improve the speed and capacity of the contribution process.Nonetheless, overall Project decision making and co-ordination was the most important social improvement across all ranks, and it was the second most important one for 'Rank 1' — so that's pretty consistent. Other than improving the contribution process this was the next most important item on contributors minds.Promotion and advocacy also seems to be important, though there are very few comments about it in the survey overall. The next most important across all ranks was Fund raising, which does get some comments.Technical improvementsThe partner question was Q29 which asked, What technical areas would you prioritise to improve Guix overall?This was also a ranked question where participants had to prioritise their top 3.Table 30: Rank 1 — Technical improvementsCategory CountPercentageDebugging and error reporting6318%Making the latest version of packages available (package freshness)5014%Automate patch testing and acceptance4212%Runtime performance (speed and memory use)3610%Package reliability (e.g. installs and works)309%Contribution workflow (e.g. Pull Requests)268%More packages (more is better!)237%Improving Guix's modules206%Project infrastructure (e.g. continuous integration)206%Guix System services123%Guix Home services103%Stable releases (e.g. regular tested releases)82%Focused packages (fewer is better!)51%There were 345 answers for the highest priority, 327 for the second rank and 285 for the third rank — so not as significant a drop-off as for the social question. Figure 22 shows this as a bar chart:Figure 22: Technical improvements to GNU Guix (Rank 1)As before I've converted them to priorities in each rank. The smallest overall score is the highest priority:Table 29: All Ranks — Organisational and social improvementsCategory Rank 1Rank 2Rank 3Overall priorityAutomate patch testing and acceptance3211Runtime performance (speed and memory use)4132Debugging and error reporting1473Project infrastructure (e.g. continuous integration)9324Contribution workflow (e.g. Pull Requests)6555Making the latest version of packages avalable (package freshness)2866Package reliability (e.g. installs and works)5747More packages (more is better!)76108Guix Home services111089Improving Guix's modules812910Guix System services1091111Stable releases (e.g. regular tested releases)12111212Focused packages (fewer is better!)13131313Figure 23 shows this as a stacked bar chart.Figure 23: Technical improvements to GNU Guix (All Ranks)Some things that are interesting from this question:For the technical improvements there isn't a single over-riding 'Rank 1' priority (table 30). The first choice, Debugging and error reporting, does come up consistently in comments as a problem for packagers, and across all three ranks it's the third priority.Across all ranks Debugging and error reporting along with Runtime performance (speed and memory) are high priorities. These are probably quite connected as there's lots of comments in the survey about error reporting and slow evaluations making development time-consuming and difficult.It's possible to think of the second and third priorities for 'Rank 1' (table 30) as being connected, since the velocity needed for Making the latest version of packages available would be helped by Automate patch testing and acceptance. We can see from the second table that through all priorities this is the area that contributors care about the most.We asked the same question of all Users (Q21) earlier in the survey. This time the question was for Contributors only and there were a few specific contribution-focused options. It's interesting to see the contrast between contributors and users priorities:For both the contributor (P2) and users (P1) improving the runtime performance was a high priority, so it's pretty consistent.For users making Guix easier to learn was the second highest priority, there wasn't really an equivalent option in the contributor question.Users identified Making the latest versions of packages available (package freshness) as very important and it's also a high priority in the first rank for contributors. However, overall it was middle of the pack for them — with both Project infrastructure (e.g. continuous integration) and Contribution workflow (e.g. Pull Requests) coming higher.Key insights recapThat completes our review of the contributor section! Here are the key insights I draw:The size of the active contributor community (~450) is really exciting. Many developers send a few patches (~60%), while at the other end of the scale there are some who have sent hundreds.Retaining and developing contributors is important for the project's sustainability. About 66% of active developers are likely to contribute again. That's great, how can we encourage that to happen?The key reasons contributors stopped (aside from life changes) was a slow response to contributions and the contribution process (e.g email and patch flow).Improving the capacity and speed of reviews was also the over-riding concern for active contributors by a significant margin. High priority suggestions were automating patch testing and acceptance, along with improving the projects infrastructure (e.g. continuous integration).Technical improvements to the developer experience were improving debugging and error reporting, runtime performance and also providing a more commonly used contribution process (e.g. Pull Requests).Finally, the project is 95% a volunteer one, so we should bear in mind that everyone's contributing to Guix on their personal time! While it's great to see all this fantastic feedback and it's very useful, Guix is a collective of volunteers with the constraints that brings.Getting the DataWe've really squeezed the juice from the lemon over these three posts — but maybe you'd like to dig into the data and do your own analysis? If so head over to the Guix Survey repository where you'll find all the data available to create your own plots!

GNU Guix: Guix User and Contributor Survey 2024: The Results (part 2) (%2025/%01/%24 %12:%Jan)The results from the Guix User and Contributor Survey (2024) are in and we're digging into them in a series of posts! Check out the first post for the details of how users initially adopt Guix, the challenges they find while adopting it and how important it is in their environment. In this part, we're going to cover how use of Guix matures, which parts are the most loved and lots of other details.As a reminder there were 943 full responses to the survey, of this 53% were from users and 32% were from contributors.Guix usageThe middle section of the Survey explored how users relationship with Guix matured, which parts they used and where they struggled. Question 11 asked, Which parts of Guix have you used on top of another Linux distribution?As a reminder a third (36%) of participants adopted Guix by using it as a package manager on top of another GNU/Linux distribution. The detailed results were:Table 10: Hosted Guix usage by capabilityCapabilityUseStoppedNever usedPackage manager and packages (guix package)48%26%24%Dotfiles and home environment management (guix home)17%11%70%Isolated development environments (guix shell)41%18%39%Package my own software projects28%9%61%Deployment tool (guix deploy, guix pack)13%7%78%Guix System (i.e. VM on top of your distro)15%15%68%Note that all the percentages in this table, and throughout the posts are rounded to make them easier to refer to.The next question (Q12) asked participants, Which parts of Guix have you used on top of Guix System?As a reminder, an earlier question (Q5) determined that 46% initially adopted Guix as a GNU/Linux distro in a graphical desktop configuration, and 5% as a GNU/Linux distro in a server configuration. The results:Table 11: Guix System usage by capabilityCapabilityUseStoppedNever usedPackage manager and packages (guix package)64%17%17%Dotfiles and home environment manager (guix home)48%9%41%Isolated development environments (guix shell)36%10%21%Package my own software projects40%9%49%Deployment tool (guix deploy, guix pack)19%8%71%This gives us an interesting picture of how Guix usage develops:From the first table (Table 10) I was very surprised by the way that Guix users manage their packages. It shows that 24% of users that use Guix on top of another Linux distribution don't use `guix package`. Clearly, many of these users have switched to a declarative package management approach using manifests or Guix Home.Guix Home is popular with users of Guix System. It's a relatively new capability in Guix, and there's lots of opportunity to encourage its use on top of another GNU/Linux distribution. It could be a great on-ramp into using Guix generally.Guix Shell is very popular both when used in a hosted set-up and on Guix System. There are requests in other parts of the survey for missing features from Nix Shell, so perhaps those are some ways to increase its popularity.I was really surprised by how many users are packaging their own software projects, about 40% of Guix System users, and almost a third of hosted users.Guix's suite of deployment tools is the least used part of the capabilities. They may not have been utilised by the majority of users yet, but some people find them very useful. There were comments in the survey that these tools drove usage as both a CI and Docker deployment tool.Guix System usageThe survey then asked (Q15), How have you run Guix System?This was a multiple choice question, so in total there were 1508 answers from the 943 participants, consequently we can assume that some users deploy Guix System in multiple configurations:Table 12: Guix System deployment typesDeployment typeCountPercentageGraphical desktop in a VM27529%Graphical desktop on laptop/workstation hardware69173%Server on server hardware22324%Server in a VM (e.g. KVM)16918%Server in a container (e.g. Docker/Singularity)536%Public Cloud (e.g. AWS)576%Other404%In the Other category there were mentions of using it on different SOC boards (e.g. RockPro64), on WSL2 and on different hosting providers (e.g. Digital Ocean, Hetzner).Figure 7 shows the break down as a bar chart:Figure 7: Guix System usageSome thoughts from this question:It's notable that the vast majority of users are using Guix as some form of graphical desktop (whether on their own hardware or in a VM). This could have implications for the priority of both graphical environment packaging and testing.Roughly, a third of users are deploying Guix as a server (445) out of the total (1508). This is a big increase from the initial adoption phase (Q5) where 5% of users were adopting Guix as a server. It seems that users often adopt Guix as a graphical desktop and then as they become more familiar with it they start to use it as a server as well.We can't know how many specific deployments there are as the survey didn't ask how many desktops or servers each user actually deployed. But, the change in the mixture of deployments is interesting. It might be that improving the capabilities, documentation and popularity of the deployment tools (Q15) would also increase the server usage pattern. There are also comments elsewhere in the survey about missing server packages and services. Only a small number of users are using Guix as a containerization system or in the public cloud. These are significant areas for professional development and deployment, so an area of Guix that further development could focus on.ArchitecturesThe survey then asked (Q16), Which architectures do you use Guix on?Again this was multiple choice, there were 1192 answers from 943 completed surveys:Table 13: Guix architectures usageCategoryCountPercentagex86_64 (modern Intel/AMD hardware)92598%IA-32 (32-bit i586 / i686 for older hardware)253%ARM v7 (armhf 32-bit devices, Raspberry Pi 1 - Zero)364%AArch64 (ARM64, Raspberry Pi Zero 2, 3 and above)17719%POWER9 (powerpc64le)152%IA-32 with GNU/Hurd (i586-gnu)141%As we might expect x86_64 is the most popular, but there are quite a few AArch64 users as well. There are various comments in the survey about challenges when using different architectures (e.g substitute availability, cross-compiling challenges), see the linked comments throughout these posts for more.Proprietary driversProprietary drivers is an interesting topic in the Guix community. For Q17 the survey asked, Do you use proprietary drivers in your Linux deployments?The goal was to understand driver usage across all Linux usage, whether when using Guix or another Distribution. As this was a multiple choice question, there were 1275 answers from the 943 participants.Table 14: Proprietary driver usageCategoryCountPercentageNo, I don't use proprietary drivers19120%Yes, I use Nonguix as part of Guix System62266%Yes, I use proprietary drivers on other GNU/Linux distributions46249%Figure 8 shows it as a bar chart:Figure 8: Use of proprietary driversFrom this we can conclusively say that the majority of Guix users do use proprietary drivers. Although hardware that respects Freedom is available, hardware requiring proprietary drivers is sadly the norm.Other applicationsThe next question was (Q18), Do you use other methods and channels to install applications?One of the advantages of Guix is that it's a flexible system where users can create their own packages and share them with the community. Additionally, there are other methods for installing and using applications such as Flatpak. However, we already know that during adoption some users struggle to find the applications that they need. This question explores whether that changes as usage matures.The results were:Table 15: Application sourcesSourceCountPercentageI only use applications from Guix23425%Packages from my host Linux distro35237%Nix service on Guix System12413%Nonguix channel (proprietary apps and games)60764%Guix Science channel12714%My own Guix channel44247%Guix channels provided by other people30332%Flatpak33435%Other11112%Figure 9 shows this visually:Figure 9: Methods and channels used to install applicationsSome thoughts:Overall, we can conclude that the vast majority of users are using applications using multiple different methods as there were 2634 answers in total!607 participants, out of the 943, selected that they use the Nonguix channel, so 64% overall. This is a similar level of usage for applications as drivers. At the other end 234 only use applications from Guix, ~25% of users. This is a great demonstration that Guix attracts a broad range of users — some users who solely use Free Software, as well as those that need or want software that's under a wider set of licenses.A large number of users package and use their own Guix channel, 442 which is 47% — this seems inline with the earlier questions about how Guix is used.There were quite a few different options in the Other category including Distrobox, RDE and guixrus, Docker, Conda, Homebrew, AppImage, Pip and Nix.Overall satisfactionThe survey asked participants (Q19), How satisfied are you with Guix as a Guix user?This is probably the most important question in the entire survey, since happy users will continue to use and contribute to the project.Table 16: Guix user satisfactionCategoryCountPercentageVery dissatisfied313%Dissatisfied778%Neutral18019%Satisfied46349%Very satisfied19220%The bar chart is Figure 10:Figure 10: Guix user satisfaction scoreOverall, this is a really good result with 655 of the 943 participants clearly satisfied or very satisfied, ~70%. This is a good number that shows many users have a really great experience with Guix.It also echos what we saw with the adoption satisfaction question.The middle portion who are neutral is bigger that I personally would like to see. This is commonly a group that is not really happy with a product, but for various reasons don't want to say so. There's definitely some areas the project can work on to help users to continue enjoying using Guix.At the other end of the scale the very dissatisfied and Dissatisfied are 108, so 11%. We've seen some of the challenges in earlier questions, and the next question explores these further.Limiters of satisfactionFor Q20 the survey asked, Which areas limit your satisfaction with Guix?The detailed results:Table 17: Guix user satisfaction limitersCategoryCountPercentageDifficulties with Guix tools user experience19220%Difficulties using declarative configuration15717%Missing or incomplete services (whether Guix Home or Guix System)37440%Overall Linux complexity (i.e. not specific to Guix)9210%Hardware drivers not included31233%Guix runtime performance (e.g. guix pull)44948%Reference documentation (i.e. the manual)19521%Shortage of informal guides, examples and videos36939%Error messages and debugging37239%Nothing, it's perfect!404%Other21323%As a visual graph:Figure 11: Guix user satisfaction challengesThe first thing to note is that there were 2765 entries from our 943 survey completions, so users have challenges in multiple categories.About 48% of participants have issues with Guix's runtime performance. It's the biggest issue that users face and shows up in other survey data and comments.The second biggest challenge is with missing or incomplete services, where 39% of participants struggle with this.The shortage of informal guides, examples and videos is the next biggest challenge, this also came through in the adoption question (Q7).Tied with it is the difficulty of understanding error messages and debugging. We didn't ask about this in the adoption question (Q7), but there are comments throughout the survey where users struggle with debugging due to poor error messages.The fifth biggest problem is that hardware drivers that users need are not included, with 33% of users hitting this problem.There were also 213 comments in the Other category, the full list of comments is available. As before I've grouped the comments — at this point we're starting to see consistency in the grouping so to avoid a lot of repetition I've only put in one example from each one:Complexity of maintenance: where the overall experience of using Guix was too time-consuming and complex."Time/complexity of managing declarative configuration, handling problems that occur due to package updates/conflicts, creating custom packages and keeping them updated"Learning curve: where learning Guix's unique approach was too difficult."I really love the idea, but it's extremely difficult to use, especially for beginners"Lack of drivers within the distribution: issues where users couldn't use their hardware."Guix is unusable without nonguix / proprietary drivers"Proprietary software: missing proprietary software that was required."Limitations in FHS emulation for proprietary programs"Efficiency and resource usage: where overall resource usage made the experience slow or unusable."cicd and other infrastructure (global mirrors)"Missing packages and services: where Guix didn't have a package or service the user needed."Some buggy services, which are hard to patch without knowledge and proper documentation"Out of date packages: issues where Guix's packages were not up-to-date."Many packages are severely out of date, some break often during routine upgrades (build failures), many things missing and have sat on the Guix Wishlist for years"Quality and reliability: general issues of quality and reliability that undermined the users belief that Guix was ready for use."master is often broken and patches for these issues get ignored so I have to use a temporary fork of the main guix repo with the patches applied"Encrypted boot and disks: issues arising from missing encryption capabilities."Setting up full disk encryption for multiple disks or unusual arrays of disks and then secure boot issues"Practical guides, how-to's and examples: issues where there were no direct instructions or examples, as compared to reference documentation."examples, a show of how a task is done in Debian or OpenSUSE and contrast it with how the task is done in guix would be helpful"Free Software as a constraint: limitations and concerns about Free Software and GNU as an organisation constraining practical user freedom."The hard stance of the GNU project on non-free software makes it hard to find "whats out there""Not enough GNU: limitations and concerns that Guix is not sufficiently supportive of GNU and/or Richard Stallman."I am disappointed that you veered off the course of freedom and added nonguix. Also that you hate on RMS."Language ecosystem issues: problems packaging or using Guix with ecosystems like Docker, Go and Rust."Packaging nightmares won't let us have nice things"Unavailable on Mac OSX: inability to use Guix as it's not available for Mac."No macOS official distribution"Incompatibility with hosting Linux distro: difficulties using Guix on top of another Linux distribution, particularly using graphical programs."Some DEs don't integrate as well as they do on other distros."Error messages: challenges debugging issues due to difficult to use error messages."guix is very-very slow and consumes too much memory and CPU for what it's doing. also error messages are the worst i've seen in my 10 years of programming"Poor contributor experience: comments caused by contributions not being reviewed or other poor experiences."Slow, or sometimes inexistent, feedback for submitted patches and issues"Not all comments fit into a specific theme, I've pulled out some other interesting ones:Shepherd as a constraint: some users love that Guix doesn't use Systemd, but there are some comments worrying about compatibility and migration."I'd like to be able to use systemd. I like that Guix is doing the work so that we break the init system monoculture though. But I'd like systemd to be an alternative. The term service is overloaded which is confusing. I also think that some developer (in-repo) documentation is missing. Specifally regarding packages that need a special boostrapping process such as node or bqn""lack of features comparing to systemd"Reproducibility challenges: reproducing Guix set-ups when using channels or other issues."Guix is pretty perfect, but there are breaking changes between channels, would love for the channel to pin to specific guix commit when building it's packages and have a warning if the commit is outdated by x days""not reproducible due to ~/.config/guix and channels not pinned easily"Releases and stable channel: a few users have concerns about a lack of new releases, or wanting to use a more stable release channel."Some kind of LTS release that I can pin my work to would be great. Maintaining my own channels for work/personal use is good but sometimes guix updates cause things to break so I need to pay attention to keep things working. A more stable release with better probability of substitute hits would be nice.""No new release in over 2 years"Running compiled binaries: situations where the user wants to run a compiled binary that's expecting a 'standard' Linux."Running Software not in channel like: Compilers for embedded systems (avr), proprietary software (matlab)"Architecture issues: there's a few comments about issues using alternative architectures, particularly about substitute availability."Aarch64 seems like it gets less love and x86. Takes time for broken packages to get fixed on aarch64"What should Guix improve?The survey then asked, (Q21) Which areas should Guix's developers improve so you can use Guix more?This question was done as a ranking question where participants had to prioritise their top 3. The rationale for asking it in this way was to achieve clarity over prioritisation.It's useful to look at this in two ways, first the table where participants ranked their highest priority:Table 18: Highest priority ranked improvementsArea — Rank 1CountPercentageMaking the latest versions of packages available (package freshness)14916%Performance and tuning (faster guix pull)11212%Make Guix easier to learn (more docs!)10511%Package reliability (e.g. installs and works)9210%Hardware support (drivers)9110%More packages (more is better!)879%Software developer tooling (guix shell with editors, debuggers, etc)586%Make Guix easier to use576%Guix System services374%Stable releases (e.g. regular tested releases)354%Community and communications334%Guix Home services243%Focused high-quality packages (fewer is better!)152%This second table shows how each element was ranked across all positions, reordered to show the overall prioritisation:Table 19: Highest priority ranked improvementsAreaRank 1Rank 2Rank 3Overall scorePerformance and tuning (faster guix pull)2114Make Guix easier to learn (more docs!)3227Making the latest versions of packages available (package freshness)1438More packages (more is better!)63413Package reliability (e.g. installs and works)45615Hardware support (drivers)56718Software developer tooling (guix shell with editors, debuggers, etc)77519Guix System services910827Make Guix easier to use891128Guix Home services128929Community and communications11121033Stable releases (e.g. regular tested releases10111334Focused high-quality packages (fewer is better!)13131238Some thoughts on what this means:We can see that Performance and tuning (faster guix pull) consistently shows up as an area Guix users would like to see improved.The second highest priority, Make Guix easier to learn (more docs!) is also consistent, as we've seen from other comments the main desire is for more instructions and examples.In third place is, Making the latest versions of packages available (package freshness). It's a little less consistent, notice that it's the highest priority concern for users (Table 18), but drops a little amongst later priorities.Next is More packages (more is better!), and we've seen that missing packages is a limit to adopting or using Guix.The fifth highest priority is Package reliability (e.g. installs and works), this seems to be more important in lower ranks. We've seen lots of comments about packages that have issues, require further configuration or don't integrate well (particularly in a hosted set-up). This one is intriguing as one possibility would be to focus on a smaller set of packages, yet Focused high-quality packages (fewer is better!) consistently came last.The sixth is Hardware support (drivers), again it's less important at later ranks. This one is also interesting as in the adoption questions, and in many of the comments about challenges it's consistently mentioned as a significant challenge. It may be reflecting that users who are using Guix must have solved their driver problems, so it's slightly less important if your machine works!Guix sustainabilityThe next section of the survey was for Contributors, we'll cover that in the third post in the series. After the contribution section Q32 asked all users, How likely are you to financially support the Guix project?As a volunteer project, with no corporate sponsors, the rationale for asking this question is that some aspects of the project (e.g. infrastructure and sponsored work) require finance. The results were:Table 20: Donating to GuixCategoryCountPercentageUnable (e.g. don't have money to do so)28030%Would not (e.g. have the money to do so, but would not)404%Unlikely14515%Moderately likely34136%Very likely13314%No answer40.42%As a graphical bar chart:Figure 12: Financially supporting GuixThe results tell us that about 50% of users would be willing and able to financially contribute to Guix. There's also a significant set of users who are unable to do so, and one of the clear benefits of Free Software is that we can all use it without charge! ❤️ Love Guix!Having asked lots of structured questions and ones about challenges the last question (Q33) was, What do you love about Guix?There were 620 answers, so 65% of the participants wrote something — that's a lot of love for Guix!There were lots of positive comments about how friendly and helpful the Guix community is; the joys of using Scheme/Lisp and Guile; the importance of user-focused Free Software; and the benefits of the declarative approach.All the comments are available to read, and I encourage you to have a scroll through them as they're very uplifting!A few I pulled out:"I enjoy the commitment, patience (!), and friendliness of so many in the community!""Scheme! That Guix fits my preference for declarative, functional and minimalist computing! And it’s friendly and helpful community, of course!""Guix provides reproducibility that I think is invaluable for scientific computing. There are many brilliant community members who spend their time improving Guix and helping other users. Diverse opinions are tolerated on the mailing lists. I like how the project's community and leadership have responded to users who express discontent on the mailing lists -- respectfully and openly, but wary of making radical changes that might jeopardise the project.""Community (people) by far, focus on free software, Scheme, reproducibility, flexibility. Guix is one of the hidden gems of the free software world.""Friendly community, GNU project""I really appreciate everything you do, and I really hope the process for contributors can be modernized with Codeberg or similar forges which is second nature to most developers.""Reproducibility and providing a way for people for being technologically independent and free.""There's many things to love, but most important (and perhaps unloved to a certain extent) is the ability to create Guix channels for any and every purpose. As an effort to package the whole free software world, the community also feels quite diverse, with people and teams often working on vastly different things that somehow come together under one big umbrella.""Guix pack is amazing and allowed me to run some exotic guix packages on foreign systems, and guix system is really cool in general, tons of packages, the best gnu certified distro in general.""Having all my system configuration in one place allow me to remember what changes I did to my system at a glance. I can't imagine going back to a distribution where all the changes I make to a system would need to be done again if I swapped machine.""Freedom! The four software freedoms, plus freedom from side-effects."Key insightsIn this post we've looked at the questions the survey asked participants about their use of Guix. And as a reminder, there were over 900 participants who completed the survey.The main conclusions I draw from this part are:There's a high level of satisfaction amongst Guix users: about 70% were very satisfied or satisfied. This is really positive as happy users are more likely to continue to use Guix, and may become contributors!When used on top of another GNU/Linux distribution (hosted) Guix's package management and development environments capabilities are the most utilised parts. When used as a GNU/Linux distribution package management and home environment are the most used parts.The majority of Guix System users are using it in a graphical desktop configuration, as they become familiar with it they start to use it as a server.There's lots of great feedback on areas where users would like to see improvements. One thing to bear in mind is that as a volunteer project there may not be people with the time or interest to work on these areas — but nonetheless, consistent feedback is useful for Guix's developers.Many users would be happy to donate to Guix to support its mission.If you missed it, the first post in this series covers how users adopt Guix. And, the next post will cover how Contributors interact with the project.

parallel @ Savannah: GNU Parallel 20250122 ('4K-AZ65') released [stable] (%2025/%01/%21 %23:%Jan)GNU Parallel 20250122 ('4K-AZ65') has been released. It is available for download at: lbry://@GnuParallel:4 Quote of the month: GNU Parallel too. It is my map/reduce tool with built in support to retry failed jobs. -- Dhruva @mechanicker.bsky.social New in this release: No new features. This is a candidate for a stable release. Bug fixes and man page updates. News about GNU Parallel: How to Implement Parallelism and Concurrency Control (Queue) in Shell https://www.alibabacloud.com/blog/how-to-implement-parallelism-and-concurrency-control-queue-in-shell_601908?spm=a2c65.11461433.0.0.4ee35355IOL2MZ GNU Parallel - For people who live life in the parallel lane. If you like GNU Parallel record a video testimonial: Say who you are, what you use GNU Parallel for, how it helps you, and what you like most about it. Include a command that uses GNU Parallel if you feel like it. About GNU Parallel GNU Parallel is a shell tool for executing jobs in parallel using one or more computers. A job can be a single command or a small script that has to be run for each of the lines in the input. The typical input is a list of files, a list of hosts, a list of users, a list of URLs, or a list of tables. A job can also be a command that reads from a pipe. GNU Parallel can then split the input and pipe it into commands in parallel. If you use xargs and tee today you will find GNU Parallel very easy to use as GNU Parallel is written to have the same options as xargs. If you write loops in shell, you will find GNU Parallel may be able to replace most of the loops and make them run faster by running several jobs in parallel. GNU Parallel can even replace nested loops. GNU Parallel makes sure output from the commands is the same output as you would get had you run the commands sequentially. This makes it possible to use output from GNU Parallel as input for other programs. For example you can run this to convert all jpeg files into png and gif files and have a progress bar: parallel --bar convert {1} {1.}.{2} ::: *.jpg ::: png gif Or you can generate big, medium, and small thumbnails of all jpeg files in sub dirs: find . -name '*.jpg' | parallel convert -geometry {2} {1} {1//}/thumb{2}_{1/} :::: - ::: 50 100 200 You can find more about GNU Parallel at: http://www.gnu.org/s/parallel/ You can install GNU Parallel in just 10 seconds with: $ (wget -O - pi.dk/3 || lynx -source pi.dk/3 || curl pi.dk/3/ || \ fetch -o - http://pi.dk/3 ) &gt; install.sh $ sha1sum install.sh | grep 883c667e01eed62f975ad28b6d50e22a 12345678 883c667e 01eed62f 975ad28b 6d50e22a $ md5sum install.sh | grep cc21b4c943fd03e93ae1ae49e28573c0 cc21b4c9 43fd03e9 3ae1ae49 e28573c0 $ sha512sum install.sh | grep ec113b49a54e705f86d51e784ebced224fdff3f52 79945d9d 250b42a4 2067bb00 99da012e c113b49a 54e705f8 6d51e784 ebced224 fdff3f52 ca588d64 e75f6033 61bd543f d631f592 2f87ceb2 ab034149 6df84a35 $ bash install.sh Watch the intro video on http://www.youtube.com/playlist?list=PL284C9FF2488BC6D1 Walk through the tutorial (man parallel_tutorial). Your command line will love you for it. When using programs that use GNU Parallel to process data for publication please cite: O. Tange (2018): GNU Parallel 2018, March 2018, https://doi.org/10.5281/zenodo.1146014. If you like GNU Parallel: Give a demo at your local user group/team/colleagues Post the intro videos on Reddit/Diaspora*/forums/blogs/ Identi.ca/Google+/Twitter/Facebook/Linkedin/mailing lists Get the merchandise https://gnuparallel.threadless.com/designs/gnu-parallel Request or write a review for your favourite blog or magazine Request or build a package for your favourite distribution (if it is not already there) Invite me for your next conference If you use programs that use GNU Parallel for research: Please cite GNU Parallel in you publications (use --citation) If GNU Parallel saves you money: (Have your company) donate to FSF https://my.fsf.org/donate/ About GNU SQL GNU sql aims to give a simple, unified interface for accessing databases through all the different databases' command line clients. So far the focus has been on giving a common way to specify login information (protocol, username, password, hostname, and port number), size (database and table size), and running queries. The database is addressed using a DBURL. If commands are left out you will get that database's interactive shell. When using GNU SQL for a publication please cite: O. Tange (2011): GNU SQL - A Command Line Tool for Accessing Different Databases Using DBURLs, ;login: The USENIX Magazine, April 2011:29-32. About GNU Niceload GNU niceload slows down a program when the computer load average (or other system activity) is above a certain limit. When the limit is reached the program will be suspended for some time. If the limit is a soft limit the program will be allowed to run for short amounts of time before being suspended again. If the limit is a hard limit the program will only be allowed to run when the system is below the limit.

GNU Guix: Meet Guix at FOSDEM (%2025/%01/%21 %08:%Jan)Next week will be FOSDEM time for Guix! As in previous years, a sizable delegation of Guix community members will be in Brussels. Right before FOSDEM, about sixty of us will gather on January 30–31 for the now traditional Guix Days!In pure unconference style, we will self-organize and discuss and/or hack on hot topics: drawing lessons from the user &amp; contributor survey, improving the contributor workflow, sustaining our infrastructure, improving governance and processes, writing the build daemon in Guile, optimizing guix pull, Goblinizing the Shepherd… there’s no shortage of topics!This time we’ve definitely reached the maximum capacity of our venue so please do not just show up if you did not register. Next year we’ll have to find a larger venue!As for FOSDEM itself, here’s your agenda if you want to hear about Guix and related projects, be it on-line or on-site.On Saturday, February 1st, in the Open Research track:Guix + Software Heritage: Source Code Archiving to the Rescue of Reproducible Deployment, at noon, where Simon Tournier will talk about the latest developments connecting Guix and the Software Heritage archive.On Sunday, February 2nd, do not miss the amazing Declarative &amp; Minimalistic Computing track! It will feature many Guile- and Guix-adjacent talks, in particular:RDE: Tools for managing reproducible development environments, where Nicolas Grave will present how RDE extends Guix and what nifty features it brings;The Shepherd: Minimalism in PID 1, where I (Ludovic Courtès) will talk about the recently-released Shepherd 1.0 and why I think its design makes it the coolest init system to hack on;Shepherd with Spritely Goblins for Secure System Layer Collaboration, where Juliana Sims of Spritely will present on-going work to port the Shepherd to Goblins in support of distributed and capability-based secure computing.But really, there’s a lot more to see in this track, starting with talks by our Spritely friends on web development with Guile and Hoot by David Thompson, a presentation of the Goblins distributed computing framework by Jessica Tallon, and one on Spritely’s vision by Christine Lemmer-Webber herself (Spritely will be present in other tracks too, check it out!), as well as a talk by Andy Wingo on what may become Guile’s new garbage collector.Also on Sunday, February 2nd, jgart (Jorge Gomez) will be presenting a survey of Immutable Linux distributions at the Distributions track which will include RDE.Good times ahead!Guix Days graphics are copyright © 2024 Luis Felipe López Acevedo, under CC-BY-SA 4.0, available from Luis’ Guix graphics repository.

www @ Savannah: Malware in Proprietary Software - 2024 Catch-up (%2025/%01/%17 %19:%Jan)The initial injustice of proprietary software often leads to further injustices: malicious functionalities. The introduction of unjust techniques in nonfree software, such as back doors, DRM, tethering, and others, has become ever more frequent. Nowadays, it is standard practice. We at the GNU Project show examples of malware that has been introduced in a wide variety of products and dis-services people use everyday, and of companies that make use of these techniques. Here are our latest additions November 2024 Malware In Cars Kia cars were built with a back door that enabled the company's server to locate them and take control of them. The car's owner had access to these controls through the Kia server. This in itself is not objectionable. However, that Kia itself had such control is Orwellian, and ought to be illegal. The icing on the Orwellian cake is that the server had a security fault which allowed absolutely anyone to activate those controls for any Kia car. Many people will be outraged at that security bug, but this was presumably an accident. The fact that Kia had such control over cars after selling them to customers is what outrages us, and that must have been intentional on Kia's part. BMW has retreated from making car owners pay for a subscription to the heated seats feature. Customers rejected it. Bravo for them! Instead BMW plans to require subscriptions for digital services and disservices—things related to the Orwellian tracking done by any “connected” car. Proprietary Addictions Dating apps exploit their users; fundamental features require an expensive subscription, and they are designed to be addictive. Apple's Operating Systems Are Malware A back door in Apple devices, present and abused from at least 2019 until 2023, allowed crackers to have full control over them by sending iMessage texts that installed malware without any action on the user's part. Infections, among other things, gave the intruders access to owners' microphone recordings, photos, location and other personal data. July 2024 Proprietary Obsolescence Spotify sold a music streaming device but they no longer support it. Due to its proprietary nature, it can no longer be updated or even used. Users requested Spotify to make the software that runs on the device libre, and Spotify refused, so these devices are now e-waste. Spotify is now offering refunds to save the purchasers from losing money on these products, but this wouldn't prevent the products from being e-waste, and wouldn't save users from being jerked around by Spotify. This is an example of how software that is not free controls the user instead of the user controlling the software. It is also an important lesson for us to insist the software in a device be libre before we buy it. May 2024 Microsoft's Software is Malware Microsoft is using malware tactics to get users to switch to their web browser, Microsoft Edge, and their search engine, Microsoft Bing. When users launch the Google Chrome browser Microsoft injects a pop up advertisement in the corner of the screen advising users to switch to Bing. Microsoft also imported users Chrome browsing data without their knowledge or consent. April 2024 Malware In Cars GM is spying on drivers who own or rent their cars, and give away detailed driving data to insurance companies through data brokers. These companies then analyze the data, and hike up insurance prices if they think the data denotes “risky driving.” For the car to make this data available to anyone but the owner or renter of the car should be a crime. If the car is owned by a rental company, that company should not have access to it either.

coreutils @ Savannah: coreutils-9.6 released [stable] (%2025/%01/%17 %15:%Jan) This is to announce coreutils-9.6, a stable release. See the NEWS below for a summary of changes. There have been 263 commits by 15 people in the 42 weeks since 9.5. Thanks to everyone who has contributed! The following people contributed changes to this release: Bernhard Voelker (5) Bruce Jerrick (1) Bruno Haible (5) Collin Funk (16) Daniel Hofstetter (1) Evgeny Nizhibitsky (1) Lukáš Zaoral (1) Masatake YAMATO (1) Nikolaos Chatzikonstantinou (1) Nikolay Nechaev (3) Paul Eggert (123) Pádraig Brady (95) Richard Purdie (1) Sam Russell (2) Sylvestre Ledru (7) Pádraig [on behalf of the coreutils maintainers] ================================================================== Here is the GNU coreutils home page: https://gnu.org/s/coreutils/ Here are the compressed sources: https://ftp.gnu.org/gnu/coreutils/coreutils-9.6.tar.gz (15MB) https://ftp.gnu.org/gnu/coreutils/coreutils-9.6.tar.xz (5.9MB) Here are the GPG detached signatures: https://ftp.gnu.org/gnu/coreutils/coreutils-9.6.tar.gz.sig https://ftp.gnu.org/gnu/coreutils/coreutils-9.6.tar.xz.sig Use a mirror for higher download bandwidth: https://www.gnu.org/order/ftp.html Here are the SHA1 and SHA256 checksums: File: coreutils-9.6.tar.gz SHA1 sum: 1da82e96486e0eedbd5257c8190f2cf9fcb71c2e SHA256 sum: 2bec616375002c92c1ed5ead32a092b174fe44c14bc736d32e5961053b821d84 File: coreutils-9.6.tar.xz SHA1 sum: 0ede2895e6089a02b67473b9761abcc18ce8dcb0 SHA256 sum: 7a0124327b398fd9eb1a6abde583389821422c744ffa10734b24f557610d3283 Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify coreutils-9.6.tar.xz.sig The signature should match the fingerprint of the following key: pub rsa4096/0xDF6FD971306037D9 2011-09-23 [SC] Key fingerprint = 6C37 DC12 121A 5006 BC1D B804 DF6F D971 3060 37D9 uid [ultimate] Pádraig Brady &lt;P@draigBrady.com&gt; uid [ultimate] Pádraig Brady &lt;pixelbeat@gnu.org&gt; If that command fails because you don't have the required public key, or that public key has expired, try the following commands to retrieve or refresh it, and then rerun the 'gpg --verify' command. gpg --locate-external-key P@draigBrady.com gpg --recv-keys DF6FD971306037D9 wget -q -O- 'https://savannah.gnu.org/project/release-gpgkeys.php?group=coreutils&amp;download=1' | gpg --import - As a last resort to find the key, you can try the official GNU keyring: wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg gpg --keyring gnu-keyring.gpg --verify coreutils-9.6.tar.xz.sig This release is based on the coreutils git repository, available as git clone https://git.savannah.gnu.org/git/coreutils.git with commit e2a405981ff5441dcfb217797699c94968218aca tagged as v9.6. For a summary of changes and contributors, see: https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=shortlog;h=v9.6 or run this command from a git-cloned coreutils directory: git shortlog v9.5..v9.6 This release was bootstrapped with the following tools: Autoconf 2.72.70-9ff9 Automake 1.16.5 Gnulib 2025-01-17 2481e7a50d6535582856626b53009f419e2e05e2 Bison 3.8.2 NEWS * Noteworthy changes in release 9.6 (2025-01-17) [stable] ** Bug fixes cp fixes support for --update=none-fail, which would have been rejected as an invalid option. [bug introduced in coreutils-9.5] cp,mv --update no longer overrides --interactive or --force. [bug introduced in coreutils-9.3] csplit no longer creates empty files given empty input. [This bug was present in "the beginning".] ls and printf fix shell quoted output in the edge case of escaped first and last characters, and single quotes in the string. [bug introduced in coreutils-8.26] ls -l no longer outputs "Permission denied" errors on NFS which may happen with files without read permission, and which resulted in inaccurate indication of ACLs (missing '+' flag after mode). [bug introduced in coreutils-9.4] ls -l no longer outputs "Not supported" errors on virtiofs. [bug introduced in coreutils-9.4] mv works again with macFUSE file systems. Previously it would have exited with a "Function not implemented" error. [bug introduced in coreutils-8.28] nproc gives more consistent results on systems with more than 1024 CPUs. Previously it would have ignored the affinity mask on such systems. [bug introduced with nproc in coreutils-8.1] numfmt --from=iec-i now works with numbers without a suffix. Previously such numbers were rejected with an error. [bug introduced with numfmt in coreutils-8.21] printf now diagnoses attempts to treat empty strings as numbers, as per POSIX. For example, "printf '%d' ''" now issues a diagnostic and fails instead of silently succeeding. [This bug was present in "the beginning".] pwd no longer outputs an erroneous double slash on systems where the system getcwd() was completely replaced. [bug introduced in coreutils-9.2] 'shuf' generates more-random output when the output is small. [bug introduced in coreutils-8.6] `tail --follow=name` no longer waits indefinitely for watched file names that are moved elsewhere within the same file system. [bug introduced in coreutils-8.24] `tail --follow` without --retry, will consistently exit with failure status where inotify is not used, when all followed files become inaccessible. [This bug was present in "the beginning".] `tail --follow --pid=PID` will now exit when the PID dies, even in the presence of blocking inputs like unopened fifos. [This bug was present in "the beginning".] 'tail -c 4096 /dev/zero' no longer loops forever. [This bug was present in "the beginning".] ** Changes in behavior 'factor' now buffers output more efficiently in some cases. install -C now dereferences symlink sources when comparing, rather than always treating as different and performing the copy. kill -l and -t now list signal 0, as it's a valid signal to send. ls's -f option now simply acts like -aU, instead of also ignoring some earlier options. For example 'ls -fl' and 'ls -lf' are now equivalent because -f no longer ignores an earlier -l. The new behavior is more orthogonal and is compatible with FreeBSD. stat -f -c%T now reports the "fuseblk" file system type as "fuse", given that there is no longer a distinct "ctl" fuse variant file system. ** New Features cksum -a now supports the "crc32b" option, which calculates the CRC of the input as defined by ITU V.42, as used by gzip for example. For performance pclmul instructions are used where supported. ls now supports the --sort=name option, to explicitly select the default operation of sorting by file name. printf now supports indexed arguments, using the POSIX:2024 specified %&lt;i&gt;$ format, where '&lt;i&gt;' is an integer referencing a particular argument, thus allowing repetition or reordering of printf arguments. test supports the POSIX:2024 specified '&lt;' and '&gt;' operators with strings, to compare the string locale collating order. timeout now supports the POSIX:2024 specified -f, and -p short options, corresponding to --foreground, and --preserve-status respectively. ** Improvements cksum -a crc, makes use of AVX2, AVX512, and ARMv8 SIMD extensions for time reductions of up to 40%, 60%, and 80% respectively. 'head -c NUM', 'head -n NUM', 'nl -l NUM', 'nproc --ignore NUM', 'tail -c NUM', 'tail -n NUM', and 'tail --max-unchanged-stats NUM’ no longer fail merely because NUM stands for 2**64 or more. sort operates more efficiently when used on pseudo files with an apparent size of 0, like those in /proc. stat and tail now know about the "bcachefs", and "pidfs" file system types. stat -f -c%T now reports the file system type, and tail -f uses inotify for these file systems. wc now reads a minimum of 256KiB at a time. This was previously 16KiB and increasing to 256KiB was seen to increase wc -l performance by about 10% when reading cached files on modern systems.

GNU Guix: Guix User and Contributor Survey 2024: The Results (part 1) (%2025/%01/%16 %08:%Jan)The results from the Guix User and Contributor Survey (2024) are in! This is the first time the Guix community has run this type of survey, and we're excited to share the results. The goal of the survey was to collect the views of both users and contributors, understanding how people adopt Guix, what they love and they're experiences contributing to the project.There were 943 full responses to the survey, of this 53% were users and 32% were contributors. The table of survey participants is as follows:Table 1: Participant breakdownCategoryCountPercentageUser49652.60Contributor29731.50Previous user929.76Previous contributor586.15First, thank-you to everyone who made the effort to fill out the survey. For a volunteer community project it's fantastic to see over 900 people took part. It's notable that 150 people took the survey who were previous users or contributors — it's really great that people are willing to make this effort to share their experiences — thanks so much!With this many participants we can see the range of view points and experience across our whole community, many of the comments were enlightening and are worth reading. There are links in many of the questions so anyone that's interested can go through them.As the results are extensive I've split them into three separate posts, in this post we'll focus on the first 10 questions of the survey which focused on how users learnt about Guix and their experiences adopting it.User backgrounds and experienceThe survey started by asking participants, How knowledgeable a Linux are you? (Q1).Table 2: Participant's Linux knowledgeCategoryCountPercentageBeginner (e.g. just getting started)182%Explorer (e.g. comfortable installing it and using graphical apps)182%Intermediate (e.g. comfortable with the command-line and configuring many aspects)44547%Advanced (e.g. you correct the Arch Linux Wiki!)24826%Expert (e.g. able to contribute to large Free Software projects!)21222%No answer20.21%Note that all the percentages in this table, and throughout the posts are rounded to make them easier to refer to.Figure 1 shows this graphically:Figure 1: Survey participants GNU/Linux knowledgeThe next question (Q2) was, How long have you been using Guix?Table 3: Guix experienceCategoryCountPercentageLess than 1 year24526%Between 1 and 2 years21823%Between 2 and 4 years23425%More than 4 years16017%I've stopped using Guix839%No answer30.3%Figure 2 shows these results as a bar chart:Figure 2: Survey participants GNU Guix experienceThese two questions already tell us some interesting things about Guix users:Guix users generally have a lot of Linux experience: 50% said they were Intermediates who were "comfortable with the command-line and configuring many aspects". A further 26% said they were Advanced, and 22% said they were experts.Conversely, very few users (~4%) are beginners or exploring Linux users.Many Guix users are new to Guix itself.Guix's user-base is growing! Almost 75% of the user-base are recent converts to Guix, having used it for less than 4 years.It's a similar distribution of users to Nix's. Their 2024 survey showed dramatic growth (~65%) in users from 0-2 years, Guix's is 49%.It's fantastic to see new users are exploring and trying out Guix.Unfortunately, 9% of users are no longer using Guix, but care enough to fill out the survey - so what can be done to help them come back?!Adopting GuixThe next few questions explored how participants adopted Guix. It's important that new users have a great adoption experience so they'll keep using Guix. Conversely, if the initial experience is too difficult, they may simply move onto something else without seeing it's benefits!The first question asked, (Q4) Why were you initially interested in Guix?This question tells us what users had heard about Guix, and what they discovered during their initial investigation. The answers could impact how the project talks about Guix's strengths and capabilities.For this question users could select more than one answer and many did so. The most selected choice was "Declarative configuration" where 82% of participants were interested in Guix because it had this quality. The option "Scheme, Guile, and Lisp are cool" was second, where 72% of the survey's participants were intrigued by Guix because of this aspect. The "Reproducibility" choice came third with 70% interested in this capability. The detailed results were:Table 4: Reason for adopting GuixCategoryCountPercentageReliability and transactions53757%Declarative configuration77282%Reproducibility65870%Reproducible scientific workflows19921%Fresh packages with latest versions20722%Scheme, Guile and Lisp are cool67772%Friendly community25627%FSF certified project (100% Free Software)40443%Alternative architectures (e.g. ARM)9010%GNU Hurd12213%Package management on another Linux distribution31934%As a tool for packaging my own software26728%There were 110 choices of 'Other' where participants could add their own comments, they're all available to read. Looking through them some themes came through:Development environments:"General solution to rvm,pyenv etc""As a Docker replacement for software development"Documentation:"Initial interest in Nix, but hearing about Guix having more pleasant documentation also swayed me towards using Guix instead""Documentation (not exhaustive but well-structured), simplicity of the CLI"Free Software &amp; GNU:"The possibility of releasing the GNU operating system version 1.0"100% free software yes, FSF no (FSFE are fine)""Being a GNU project helped me decide between Guix and Nix."Use for Continuous Integration:"used for CI, replacing docker with free software and user control"Sandboxes and security:"Sandbox environment""Security: containerized environments integrated in the OS."Package definitions:"Writing packages for GNU Guix seemed more intuitive than for Gentoo Linux (Guix's hashes &gt; Gentoo's slots)""Ease of packaging"An alternative to Nix:"Wanted to check out alternatives to Nix. Particularly interested in 1) grafting, 2) measures against ld.so stat storm, 3) performant guix packs without proot""Use Nix a lot, want to explore that design space more"Guile Scheme and Lisp:"One language for everything""Not nixlang""homogeneity of the configuration (one language for everything)"Full source:"Full Source Bootstrap &amp; Strict Policy to compile all software from source""Full source auditability"The next question the survey asked was, Which aspect of Guix did you initially adopt? (Q5). This is users initial entry point into using Guix.The detailed results were:Table 5: Initial aspect of Guix adoptedCategoryCountPercentagePackage manager on top of another Linux distro (guix package)33636%Dotfiles and home environment management on another Linux distro (guix home)414%Isolated development and runtime environments on another Linux distro (guix shell)586%GNU/Linux distro as a graphical desktop (guix system)43446%GNU/Linux distro as a server (guix system)475%As a software build and deployment tool (guix image, guix package or guix deploy)162%Other91%Figure 3 shows this as a bar chart:Figure 3: Guix initial adoption aspectThe summary is that almost 50% of users initially experienced Guix as a GNU/Linux distro: 44% in a graphical desktop configuration and a further 5% in a server configuration. Just over a third of users (36%) initial experience Guix as a package manager on top of another Linux distro. I found this surprising as I'd expected most users to use Guix as a hosted package manager first, what an interesting result! We can also see there's lots of room to develop Guix Home as an adoption path.Adoption challengesAdopting any new technology is difficult and time-consuming, so discovering what elements users find difficult is important. Q7 delved into this by asking, What were the biggest challenges getting started with Guix?The results were:Table 6: Adoption challengesCategoryCountPercentageInstalling Guix as a package manager on a GNU/Linux distribution808%Installing Guix System as a full Linux distribution23625%Level of Linux knowledge needed to use Guix10211%Difficulties with the reference material (i.e. the manual)23625%Shortage of how-to tutorials and videos29732%Shortage of examples (e.g. examples of usage)43146%Inexperience with Lisp syntax and/or Guile Scheme37440%Differences between Guix's approach and other Linux distros32134%It was so long ago I can't possibly remember!445%Other21823%Figure 4 shows this as a bar chart:Figure 4: Guix adoption challengesAs we can see the biggest challenge is a Shortage of examples (e.g examples of usage). And, if we consider shortage of how-to tutorials (32%) to be similar then overall we can see there's a clear need for focused goal-orientated documentation with examples. Inexperience with Lisp syntax and or Guile Scheme and Differences between Guix's approach and other Linux distros both speak to the unique nature of Guix and the approach it takes: perhaps there are implications for how Guix's tooling can make initial adoption as easy as possible.There were 218 comments, which are worth reading through. I've summarised them into broad themes:Conceptual complexity: comments about the overall knowledge required being too much. Examples are:"Understanding the concepts on which guix runs""managing storage space, generations, GC roots, profiles; generally grasping the concepts""Some interesting free software is only available for other distros, it's hard to adapt to a system without file system hierarchy"Lack of drivers: issues caused by drivers not being available. Examples are:"can't really use linux-libre on the machine I installed it on (lack drivers)""Getting an initial installation with working non-free wifi""hiding nonguix"Efficiency: comments regarding overall resource usage making Guix slow or unusable. Example comments are:"The evaluation of Guix is slow and resource-intensive. My laptop was no match for it, I had to change it.""Guix experimentation is still too slow. Make experimenting faster for new users by identifying rate limiting steps and speeding them up""Slow network when download guix substitute"Missing packages and services: issues where Guix doesn't contain a required package or service."missing packages I needed and getting them upstreamed after I packaged them""Unpackaged free software, and nonfree software""Coming from Nix: smaller, less up-to-date package set, substantially fewer home services"Quality and reliability: issues of quality and reliability that made Guix difficult to use. Some comments:"hard time fixing config errors with reports""Broken integration between some components (packages and services)""Basic setup is pretty easy on paper, but in practice sometimes it breaks my system and I need to fiddle with shell profiles and environment variables and installing extra packages to get Guix programs play nice with native programs. And I feel like this kind of breakage isn't acknowledged or addressed enough."Practical guides, how-to's and examples: situations where a lack of direct instructions or examples made Guix difficult to use."Guix-unique bugs and issues that I can't find an answer to online""Lack of docs mostly, common patterns, the fact that's it's a pain the butt to make things works for some ecosystems on the Guix distro (e.g any app written in Golang, Rust, JS,TS..)"Error messages: poor experience caused by error messages that are difficult to understand. Example comments:"Horrible error messages""Difficult guile scheme error messages!!""Hard-to-understand error messages"Configuring on a hosted distribution): issues caused when using Guix on top of another distribution. Some comments:"I found the setting of numerous variables and the comments recommending I do so contradictory and so confusing""SELinux blocked installation of packages: remount""Problems using it on a foreign distro. Guix Home particularly assumes that you are using guix system, I had to tweak the .profile a lot to get it working."Encrypted boot / LUKS: encryption in various forms unavailable or missing certain features:"Very poor support for full disk encryption.""Also using a LUKS encrypted root file-system was a challenge at the time i started Guix"Language ecosystems (e.g. Rust, PHP): issues due to missing packages, or attempts to package, from certain language ecosystems."Missing packages, and the difficulty of packaging rust or npm packages on guix dissuaded me from contributing them"Mac availability: situations where being unavailable on Mac meant Guix could not be adopted."Linux only. nix has macos support too which would help adoption in a team environment.""No MacOS official distribution"Adoption satisfaction scoreThe survey asked (Q6), How satisfied were you with your experience adopting Guix?This question explores the users overall satisfaction with the initial steps of researching, installing and initially using Guix. The question asked the participant to score their satisfaction on one of 5 levels.Table 7: Guix adoption satisfactionCategoryCountPercentageVery Dissatisfied222%Dissatisfied11312%Neutral15416%Satisfied40843%Very Satisfied22624%Can't remember202%See Figure 5 for a visual representation: Figure 5: Guix initial adoption satisfaction bar chartThis is probably the most important question in the entire survey when it comes to growing the number of Guix users. Overall, it's positive with Very Satisfied (24%) and Satisfied (43%) meaning that the majority of users are happy with their initial experience. The comments above show there's lots of room to find small ways to move users initial experience from Satisfied to being overjoyed! Unfortunately, on the other end of the scale 14% of users who were unhappy and the 16% neutral show some of the bigger challenges!Which GNU/Linux distribution do you use Guix on?As we saw earlier just over a third of users (36%) initial adopt Guix as a package manager on top of another GNU/Linux distribution. Question 8 asked, Which GNU/Linux distribution did you use Guix on top of?The results:Table 8: Hosting Linux distributionsCategoryCountPercentageAlpine Linux90.95%Arch Linux818.59%Fedora Linux333.50%Gentoo Linux192.01%NixOS222.33%Ubuntu11111.77%Other17018.03%I errored when creating this question and somehow missed out Debian! Over 117 answers in the 'Other' category said Debian so it's the most popular distribution to use Guix on, Ubuntu is second (111) and then Arch Linux was third (81). There were also plenty of mentions of OpenSUSE, RHEL/CentOS and Void Linux.Why did you stop using Guix?Question 9 was targeted at those that had previously used Guix but had stopped. It asked, You previously used Guix but stopped, why?This was a comment question and we got some fantastic answers. There were 147 comments from participants, which lines up well with the 150 people who took the survey and classed themselves as a 'Previous user' or 'Previous contributor'.This was a free form text answer, the full comment are well worth a read through . As before I've clustered the comments into themes:Complexity of maintenance too high: many commented that the overall experience of using Guix was too time-consuming and complex. A slow configuration feedback loop, inefficiency, and the overall maintenance burden were all concerns. Example comments:"I needed to switch to a distribution that required less of my attention when I started my new job. I switched to NixOS with the intention of going back to Guix at a later date, but I am now reliant on so many parts of the nix ecosystem that I don't think I'll ever actually switch back.""I was doing more work trying to make my setup perfect or fix issues with it rather than working on my other projects. A lot of things with my setup either broke with time or were just not compatible (My setup couldn't handle printing, screen sharing, audio, suspending/hibernation and I just didn't know how to fix all that) and I couldn't deal with it any longer, I simply went back to whatever worked for me earlier."Learning curve too difficult: many aspects of Guix are completely different from how other distributions achieve the same result. In some instances this learning curve was too difficult and/or there was not enough assistance. Example comments:"Mainly the learning curve is huge for a long-time *nix systems user. I knew it would be difficult to adapt, but for each and every little thing I would need to go dig how to fix something. Doing proper power management on my laptop, setting up mail (I've been using Gnus for years, but still...!), compile and test mainline kernels on my laptop, etc. It's awesome to learn all those things, but they all require time. And that's where I had to give up: I wanted a (reliable) system I could use for my day-to-day work, Guix would be great... if I could spend a few weeks only learning it (and Lisp!).""But the problem ends up to be that the whole ecosystem around guix basically assumes super knowledge about what scheme is, how to use it and worse of all deep comfort and will to use emacs as the main interface to it all. It's too high of a hurdle to dedicate when just wanting to write some files, evaluate them, declare some packages, shells, etc. I have zero interest and will to use or learn emacs and putting it so much upfront does a huge disservice to the whole project."Lack of drivers within the distribution: the lack of drivers to enable hardware was the most commented on specific issue. Some examples of those comments:"As a long time Arch user I found it difficult to configure Guix for daily use. I need proprietary video drivers (and possibly other bits to get everything working?) and I don't remember if I ever got those up and running.""I have a lot of respect for the technical side of the project, but the politics of free software absolutism (to the point where we are supposed to tell people to replace perfectly functional hardware in order to use Guix, instead of telling them about Nonguix) and the user hostile email based contribution workflow made me realize Guix would likely never reach critical mass, so my time is best applied elsewhere."Unavailable proprietary software: proprietary software not being available was also mentioned (not quite as much as drivers), often in comments that focused on Guix not being practical as a distribution for professional use. Some specific comments:"Lack of proprietary software, primarily CUDA, MKL, etc.""Although I like FSF license purity, NixOS was much more amenable to get working on various hardware &amp; did not preclude using Nvidia CUDA."Efficiency and resource usage: there were comments about guix pull taking too long, whether this was actually the fault of Guix pull locally or remote servers, the overall experience was mentioned multiple times. Some example comments were:"The core tooling was far too slow (e.g. pulling updates, etc.); Nix is slow, but nowhere near as slow as Guix (was back then, but I'm not aware of the kind of order of magnitude improvements that would have been required). Core functionality was not reliable enough for a server operating system (shepherd, logging, system rollback). Arcane contribution requirements (no provisions for non-Emacs users, e.g. regarding code formatting; baroque and counterproductive changelog and commit factoring requirements); I didn't mind the email/patch based workflow btw""Guix pull is too slow. The guix ci servers are inaccessible from my location, requiring a proxy. Guix System does not have a large enough community to be reliable and universal enough for daily use (in my opinion)"Missing packages and services: there were lots of comments about both missing packages or services and this making it difficult to use Guix. Example comments:"Much of the software I needed wasn't packaged, and it eventually became frustrating. I tried to package what I could, but some things felt extremely difficult, E.g., `jujutsu` `ghc`. However unfortunate it may be, I also rely on various pieces of nonfree software, and Guix was working against me in that regard. I do not like that I have to use nonfree software, but I often have no choice.""Still use to some extent as package manager on foreign distro. For desktop use, waited for usable KDE Plasma packaging, and for laptop, coverage of working builds for ARM. Hoping to return; there is progress on both of these fronts. Size of store and speed of guix pull where also issues (on limited hardware)."Out of date packages: meaning that although there was a package within Guix it was lagging, with particular concern about security implications. Example comments:"Outdated or absent FOSS software (ex: Gnome, KDE, etc)""Too many packages updates were lagging behind, this was raising concerns for me from a security point of view"Quality and reliability: general issues with quality and reliability that undermined the users belief that the project was ready for real use. Examples:"An upgrade broke the system and crippled it from booting. Moved on to other distribution""I like the whole idea of guix. But it feels like it is not really ready."Guix not fully supporting disk encryption: full disk encryption in a variety of forms came up multiple times as a Guix weakness. Examples:"Guix does not support an unencrypted /boot partition. But also does not fully support LUKS2 due to grub.""I love Guix System, but it still misses a few quality-of-life improvements, such as better support for full disk encryption on install (entering two passwords!) and faster servers for South America. I kid you not, it takes me several hours to install a base system with MATE!"Missing guides/how-to's and examples: we've already seen that lack of specific how-to documentation was an issue, there were various comments to that:"Examples were insufficient, documentation expected much more in-depth linux knowledge. I would like to try again using it, as I love the concepts of it and I find that I resonate with the people representing Guix, and while I am on NixOS currently I find some social aspects of the Nix project concerning.""I switched back to NixOS due to more Community support"Free Software as a constraint: Free Software and GNU as an organisation were commented on as a constraint to having a practical, usable system that met user's needs. Note that the next bullet is the reverse of this. Some example comments:"No ease of access to the tools I depend on without jumping through hoops. VSCode, Chrome, Discord, all required flatpaks. Gnome was extremely out of date and didn't work well with flatpaks making it even harder to use them. NVIDIA drivers unavailable. I would have to work entirely around Guix to make it usable for the real world. I can't just convince my friends to stop using Discord. I can't just convince my job to not depend on VSCode extensions. I have spent my time using VSCode Calva for my personal Clojure projects as well. I would have to spend a lot of time creating my own repository and writing guix packages for everything just to make it usable for myself. The GNU should be trying to meet users where they are to help liberate them, instead of creating an alternate reality where user needs are not addressed. This is a non-starter in the year 2024.""Exclusion of all references to non-free software (and no suggested step-by-step easy setup) made a full-featured initial installation untenable."Not enough GNU: there were also some comments that the Guix project was not sufficiently supportive of GNU and/or Richard Stallman:"I am disappointed that you veered off the course of freedom and added nonguix. Also that you hate on RMS.""I stopped using Guix after it ran a campaign against Richard Stallman. I don't plan to return back."Language ecosystem issues: as tools like Docker, and languages like Go and Rust become more important, friction with them is more of an issue for users:"my use case is to package tooling for other distros and use it to build docker images reproducibly for use in CI environments. it does not work for this use case very well. can't run guix daemon inside a container""Lack of packages, stance on 100% reproducibility which makes packaging software with transitive dependencies hard, slow evaluator, obscure communication and collaboration mediums, patches take months to even get a review, cryptic error messages."Nix is more modern or practical: many users seem to have explored Guix as an alternative to Nix. Example comments:"I looked at Guix as an alternative to NixOS, and like its design a lot, but struggle with the 100% free software approach as I need some non-free software (for various reasons, hardware support, required by work, etc.). I'm aware of the non-guix channel which mostly solves this, but having to compile most things myself got too cumbersome for me — I wish there was a more complete substitute server for that channel, or perhaps even a derivation based on guix with a less strict free-software policy more akin to those of NixOS or debian.""There were too many packages missing or so out of date as to be de-facto missing. Using Guix was therefore much harder to use than Nix, where I had more packages (both Free and non-Free) and they were more up to date."Old-fashioned communications: here were some comments about communications within the project being old-fashioned, both from general users and those that had tried to contribute:"There seems to be shortage of packages and slow development. Email or only free software is definitely an hindrance to many people to daily drive guix. It has become hit and miss for me, so staying with nixos as its rich and I can followup on its development easily on git repo, discourse, matrix and all.""The main two reasons are that I find the irc/email/emacs flow very hard to work with and I do not feel safe in the mailing lists."Unavailable on Mac OSX: there were a few comments that in a professional context the fact that Guix isn't available for MacOS made it difficult to use:"Being unavailable on macOS. I have my nix home manager setup on both linux and macOS. Also the lack of a number of packages was a challenge. Like typst, bottom, hugo, tree, ruff, and sd for example. I am interested in becoming a maintainer but I want my setup to also work in macOS."Incompatibility with hosting Linux distro: running Guix on top of another distribution was confusing, particularly for graphical programs:"Guix home breaking Fedora. Troubles with binary applications due to the non-fsh nature.""Setting up the package manager &amp; daemon was confusing. The command "guix pull" felt excessively slow. A lot of packages were not up to date. Breaking the FHS"Poor contributor experience: the patch process itself, slow reviews and inconsistency in response were all mentioned as issues. Examples:"I still use Guix, but am a previous contributor. Important patches (for me) which I submitted were/are ignored, so I’ve stopped contributing.""Perceived Inconsistent patch reviews. I did create couple of patches for guix, I do believe to contribute to project that I use. Sometimes I see patches getting stuck without feedback on them (not necessarily mine), the process to review patches is unclear to me and most likely to most people. Also guix lack automation to help everyone understand what is going on, if patches break rules, if this trivial change could be merged easily, etc. maybe it’s there for you, but I dont see that.""I was passed over for commit access (even though I surpassed the 50 commit requirement) because I could only find 2 people to vouch for me, not 3. Then my patches stopped being merged, and some 2-year-pending patches I sent were closed without good reason. With the way Guix is run and how they treat contributors, it is an insulting/degrading process that I am no longer willing to put myself through."As we can see there are a wide variety of reasons why users stopped using Guix, many of them are similar to the challenges that many users find, but they're even more powerfully felt by these users. It's really useful to have these themes and comments captured, as contributors may be able to pick up some of these issues and work to resolve them!How important is Guix?Focusing back on all users, the next question was, (Q10) How important is Guix in your computing environment?There was a good range of answers:Table 9: Adoption challengesCategoryCountPercentageNot using9710%Tinkering15617%Slightly important14716%Moderately important19421%Important13314%Essential21623%A visual representation:Figure 6: Guix's importance in users computing environmentsThis is an interesting mixture which is probably reflective of many new users, and how Guix is used as a package manager on top of another distribution. Over a third of users consider it to be essential/important where it would be difficult to replace, while the bottom third are tinkering or exploring it.Some thoughtsWe've looked at the first 10 questions of the survey which covered the composition of the Guix community, initial adoption and satisfaction, and challenges that led to users moving away from Guix. The first thing to say is how fantastic the response has been to the survey, it's amazing to have over 900 participants!Some big take-aways:Interest in declarative configuration, reproducibility along with Scheme, Guile and Lisp are bringing in lots of new user - around 50% have been using Guix for less than 2 yearsGuix users are knowledgable Linux users who are comfortable being hands-on with their systemAround 50% of users adopt Guix as a GNU/Linux distribution, 36% as a hosted package manager on top of another Linux distroThe survey produced great feedback from current and previous users on areas where the project can improveAround 67% of users were satisfied (or very satisfied) with their initial adoption experienceGuix is essential or important for over a third of users, part of their environment for the next third, and being explored by the last 27% of usersThe next post will cover more of the survey — which parts of Guix are most used, what sorts of deployments are being used, architectures and drivers details, and how users view contributing to the project financially.

freeipmi @ Savannah: FreeIPMI 1.6.15 released (%2025/%01/%16 %06:%Jan)o In ipmi-config, fix incorrect output of IPv6_Dynamic_Address_Source_Type. o In ipmi-oem, increase precision of Dell cumulative energy output. o Do not advertise options that are only available when special debugging is compiled into FreeIPMI. o Fix build errors with implicit-function-declaration. o libfreeipmi: remove unnecessary / duplicate parameter checks. o Fix gcc 14.x build failures. o Minor documentation updates. https://ftp.gnu.org/gnu/freeipmi/freeipmi-1.6.15.tar.gz

GNUnet News: libgnunetchat 0.5.2 (%2025/%01/%07 %23:%Jan) libgnunetchat 0.5.2 released We are pleased to announce the release of libgnunetchat 0.5.2. This is a minor new release bringing compatibility with the major changes in latest GNUnet release 0.23.0. A few API updates and fixes are included. Additionally the messaging client applications using libgnunetchat got updated to stay compatible. This release will also require your GNUnet to be at least 0.23.0 because of that. Download links libgnunetchat-0.5.2.tar.gz libgnunetchat-0.5.2.tar.gz.sig The GPG key used to sign is: 3D11063C10F98D14BD24D1470B0998EF86F59B6A Note that due to mirror synchronization, not all links may be functional early after the release. For direct access try http://ftp.gnu.org/gnu/gnunet/ Noteworthy changes in 0.5.2 Implement iteration of tags by chat contact Adjust types and API to improve consistency Add more test cases and fix some older test cases Adjust IV derivation for file encryption/decryption key A detailed list of changes can be found in the ChangeLog . Messenger-GTK 0.10.2 This minor release will add optional notification sounds and contact filtering via tags. But mostly the release is intended to reflect changes in libgnunetchat 0.5.2. Download links messenger-gtk-0.10.2.tar.gz messenger-gtk-0.10.2.tar.gz.sig Keep in mind the application is still in development. So there may still be major bugs keeping you from getting a reliable connection. But if you encounter such issue, feel free to consult our bug tracker at bugs.gnunet.org . messenger-cli 0.3.1 This release will apply necessary changes to fix build issues with libgnunetchat 0.5.2. messenger-cli-0.3.1.tar.gz messenger-cli-0.3.1.tar.gz.sig

remotecontrol @ Savannah: Hackers Terrify US Intelligence After Infiltrating Guam (%2025/%01/%03 %22:%Jan)https://www.bloomberg.com/news/features/2025-01-03/chinese-cyber-hackers-terrify-us-intelligence-after-infiltrating-guam

mailutils @ Savannah: GNU Mailutils Version 3.18 (%2025/%01/%03 %16:%Jan)Version 3.18 of GNU Mailutils is available for download. A short summary of changes follows. New debugging shortcut: all Using all in mailutils debug level specification enables all debugging categories. Syntactically, all can be used wherever an actual category name is allowed, thus, e.g., all.!=prot enables all levels except prot in all debugging categories. mail: fix and document interaction between mailutils configuration files and mail command files. In particular, mail variables that correspond to some mailutils configuration settings, now correctly reflect their value. Bugfixes Minor fix in handling of the EHLO command in smtp client. Improve docs. Minor fix in mhn and related tests. mail utility: use the mailer configuration capability.

www-zh-cn @ Savannah: Summary 2024 (%2025/%01/%01 %01:%Jan)Dear GNU CTT: Thank you for your contribution and effort. I am very proud of the performance in 2024 for this team. Here is summary from GNU translation team for 2024. Dear GNU translators! 2024 repeated the general traits of 2023: most active teams kept doing a good job updating the translations, and a few new translations were made. Currently, the total amount of translations is over 3350. General Statistics Most new translations were made by the Chinese (zh-cn) team this year; then the Polish and French teams follow. The Turkish team, although it published no new translations this year, made a notable progress in terms of keeping its translation up-to-date. The table below shows the number and size of newly translated articles in important directories and typical number of outdated GNUNified translations throughout the year. +-team--+-----new-----+--outdated--+ | de | 1 (9.7Ki) * | 124 (61%) | +-------+-------------+------------+ | es | 1 ( 5.2Ki) | 0.5 (0.2%) | +-------+-------------+------------+ | fr | 4 ( 42.0Ki) | 0.5 (0.1%) | +-------+-------------+------------+ | ja | 2 ( 9.9Ki) | 48 ( 34%) | +-------+-------------+------------+ | pl | 6 ( 85.4Ki) | 54 ( 37%) | +-------+-------------+------------+ | ru | 2 ( 20.7Ki) | 0.3 (0.1%) | +-------+-------------+------------+ | sq | 2 ( 17.1Ki) | 2.3 (2.9%) | +-------+-------------+------------+ | tr | 0 ( 0.0Ki) | 0.1 (0.1%) | +-------+-------------+------------+ | zh-cn | 23 ( 543Ki) | 0 &amp; | +-------+-------------+------------+ +-------+-------------+ | total | 39 ( 723Ki) | +-------+-------------+ I wish you all a freer, healthier, and more peaceful 2025. Happy hacking wxie

Jose E. Marchesi: Algol 68 Front-End for GCC (%2025/%01/%01 %00:%Jan) Just posted a WIP series for an Algol 68 front-end for GCC. It is about time to have support for the best programming language ever designed in the best optimizing compiler ever made ;) Thanks to Marcel van der Veer for his awesome parser, that I took the liberty to borrow from Algol 68 Genie. Free Software for the win! WIP patch series in gcc-patches...

gcide @ Savannah: GCIDE version 0.54 (%2024/%12/%31 %12:%Dec)Version 0.54 of GNU Collaborative International Dictionary of Englis is available for download. The dictionary corpus underwent a thorough spell-checking. A number of articles has been fixed or upgraded. All files has been reformatted to limit physical line length to 72 characters. If you are using GNU dico to consult the dictionary, please upgrade to version 2.12.

dico @ Savannah: GNU dico version 2.12 (%2024/%12/%31 %10:%Dec)GNU dico version 2.12 is available for download. This versions provides important improvements in the gcide module: idxgcide skips duplicated headwords. Fixed some gcide entities, introduced missing ones. Fixed Ancient Greek transliteration. New option: "watch" When given this option, the module will watch for modifications in the dictionary corpus files and rebuild the index file when necessary. HTML output HTML output is enabled by the "html" module option. It is produced only after "OPTION MIME" command command. Input conversions The argument to DEFINE or MATCH command can optionally be modified before being used in actual search. This allows, for example, to input search terms in transliteration instead of in the actual script. Conversions are implemented by loadable modules and are associated with individual databases. This version is shipped with the new module greek_kbd, which implements Greek transliteration. Dicoweb Switch to Python 3.11+ with type hints Upgrade Django to version 4.2 Improve desktop and mobile views using HTML5 Implement a dark mode Use Poetry and pyproject.toml Integrate Pylint and Mypy for development Implement various fixes and improvements pcre module now requires libpcre2 Support for obsolescent libpcre has been withdrawn.

GNU Guix: Adding a fully-bootstrapped Mono (%2024/%12/%29 %23:%Dec)We used to have a Mono package. It was introduced on August 8 2016 by commit 763b3d50b6249b43fceda51445bbeb1f5f5fd7d0, at Mono version 4.4.1.0, but it was later discovered in April of 2022 that the release tarball that it was built from included prebuilt binaries. Further research revealed that these binaries were not optional. Due to this, a decision was made to remove the Mono package, carried out on September 1, 2022.We now once again have a Mono package, due to a patch series I submitted on November 29, which after some revisions was committed on December 22. This patch series introduced a full, 17-mono-package sequence that takes us from a mono-1.2.6 built fully from source to mono-6.12.0 built fully from source, using only packages that already have full bootstrap paths. I make no promise that this is the shortest or most optimal path, but it exists and I have verified it works.As I've spent what is probably an unreasonable amount of time working toward this, I thought I'd share some of my thoughts, experiences, and commentary. Sorry in advance if it gets a bit rambly or lecture-ish.PrologueI started down this road because someone I'm working on a project with decided to depend on a C# package that requires C# 12.0 features, and my personal Mono package based on the tarball releases (which include bootstrap binaries) only went up to C# 7.0. This meant that the C# package in question de facto required strictly Microsoft's (er, I mean, "the .NET foundation"'s) .NET implementation — hereafter referred to as "dotnet" — and a very recent version no less. The bootstrapping story with dotnet is very bad; even beginning to untangle it would probably require a relatively modern C# compiler, and something that at least sort of understands MSBuild. And there's not much point to "bootstrapping" dotnet from something that isn't bootstrapped itself. So I figured I may as well start with Mono.HistoryWhile Mono is today probably the most well-known alternative to Microsoft's .NET offerings, it is not the only one. Indeed, in the early 2000s there were at least 2 competing free software implementations: Mono, and DotGNU's Portable.NET (abbreviated pnet). They differed in goals, licenses, and methods: Portable.NET was a GNU project concerned with, among other things, limiting the ability of Microsoft to impose vendor lock-in via its proprietary .NET implementation and software patents. As a GNU project, it used the GPL for its runtime and compiler, and the GPL with a linking exception for its standard library, pnetlib. Mono, on the other hand, used a mix of many copyleft and permissive licenses: X11 for the standard library, GPL for the compiler (later dual-licensed to add an X11 option), and LGPL for the runtime, with GPL and LGPL code also offered "under commercial terms for when the GPL and the LGPL are not suitable". In 2016 after its acquisition by Microsoft, the runtime was relicensed to use the Expat (MIT) license.But perhaps most importantly to us, while Mono opted to write its C# compiler, mcs, in... C#, Portable.NET's runtime and C# compiler were both written in C. Portable.NET along with the entire DotGNU project (except for LibJIT) was decommissioned in 2012, but the source is still available, and it still works fine (with a few modifications for compatibility with newer versions of its dependencies). In September of 2022, Adam Faiz submitted patches to package pnet and pnetlib, along with one of their dependencies named treecc. These packages were based on the last release of Portable.NET, version 0.8.0, released in 2007. I initially used these packages as the basis for my bootstrap efforts, and even managed to get mono-1.2.6 built using them, but later discovered that using a more recent version from git made it much easier. For example, while pnet-0.8.0 can do pointer arithmetic inside unsafe code blocks, it doesn't support the += or -= operators specifically, which requires lots of patching (after all, who would use x = x + y when you could do x += y?). There are many other similar improvements in the git version, so for this patch series I've decided to go with pnet-git.The startAfter building mono-1.2.6, I tried a few later versions, and the third or fourth one would always fail with errors about missing methods. It turns out that the reason for this is that, contrary to what their marketing suggests, C# and Java are not "write once, run everywhere". This is because their compilers rely on the details of the libraries that the program will be run with at compile-time. This is used, for example, to do overload resolution. Suppose, for example, that a certain implementation of the == operator is present in version 1.0 of a library, and then in version 2.0 of a library a more specific implementation is introduced. Now code that is compiled against version 2.0 may instead automatically reference the more-specific implementation, as is in accordance with the rules of C#. But when it is run with version 1.0, it will fail because that implementation doesn't exist. In my case, for some reason the initial mcs and core libraries being built to compile the rest of Mono were being compiled against a 2.0 library and then run with a 1.0 library. It turns out that this was because mcs uses mono's code for producing assemblies (.NET dlls and exes), and mono decides which version to put in an assembly it writes based on "which runtime version" is being used, and that version is decided at startup based on... the version that was put in the assembly it is running. So for example, mono-1.9.1 would produce 2.0 assemblies because mono-1.2.6 produced 2.0 assemblies because pnet produced 2.0 assemblies. So I modified Mono's runtime in mono-1.9.1 to allow for this version to be overridden via environment variable, and set it to v1.1.4322, and things went a lot more smoothly after that.From there on it was mostly the usual trial-and-error process of identifying where things had bitrotted. I made sure to unvendor libgc wherever possible, though eventually by mono-4.9.0 they explicitly dropped support in their configure script for using any libgc other than what was bundled, so at that point I switched to using their homebrewed sgen garbage collector.A concerning developmentOnce I got to mono-2.11.4, though, things took a turn for the interesting: Mono started using git submodules, and the (recursive? #t) clones were all failing. It turns out that this is because their submodules reference github.com using the git:// protocol.This is notable for a few reasons.First, GitHub dropped support for the git:// protocol in 2021, so recursive clones won't work now. This means I have to explicitly list out every submodule, its commit, and its sha256 hash, for every Mono version until they switched to using http or https. mono-2.11.4 has only 4 submodules, but that doesn't last for long: by mono-4.9.0 it has 14 submodules. A significant portion of these patches is just listing these submodules and their hashes. It's a bit annoying.The more concerning reason, though, is why GitHub dropped support for the git:// protocol: it is unencrypted and unauthenticated. This is mitigated somewhat by the use of sha-1 hashes to identify commits in the referenced submodules, putting a significant computational burden on anyone who would try to alter what was fetched corresponding to a given submodule. Significantly more risky, though, is the process of updating submodules that use git:// URLs. It is quite unlikely that a developer is going to independently clone one of the submodules over https, navigate to a desirable commit, copy the sha-1 hash, and manually update the submodule reference's commit. They're far more likely to run cd submodule; git pull; cd ..; git add submodule; git commit ... or an equivalent.Of course, any changes a network man-in-the-middle might try to make here would still be reflected in the commit history, so even if a developer did that, they or any of their fellow committers could spot anything strange or malicious and point it out. Also, the changes couldn't be propagated to others trying to pull them who weren't on a network path containing the MITM because the potentially-malicious commit wouldn't be present in the real submodule's repository. So the transparency of git clearly showing changes to text files, combined with the fact that surely no git hosting platform would just allow arbitrary entities to make whatever commits they want accessible under any arbitrary repository URL, rather mitigate this security issue.This usage of git:// URLs lasted all the way until September 28, 2021, when GitHub's removal of support for it forced the developers to change them to https.Meanwhile, in realityOn November 28, 2016, Mono added a submodule named roslyn-binaries. Unsurprisingly, it included binary blobs for Microsoft's Roslyn compiler (which I believe had been open-sourced shortly prior). From here on, Mono's build system would default to using these binaries for building on little-endian systems (though another compiler could be specified with the --with-csc configure flag). I happen to know that it is extremely unlikely that many Mono developers used this configure flag. I know this because the 5.0 series is an absolute pain in the neck to build from source, because they consistently depend on new C# features before they implement them.To go on a brief tangent: does anyone remember back when youtube-dl was temporarily taken down from GitHub due to the RIAA's DMCA request? Many were unhappy about that. One such unhappy person made news when they made the full contents of youtube-dl's repository available to access through the DMCA request repository. It turns out that there are many actions that one can take on GitHub that will make arbitrary commits available under arbitrary repository URLs.So, in reality, for the span of time from November 28, 2016 to September 28, 2021, anybody sitting on the network path between GitHub and any Mono developer updating the roslyn-binaries submodule could decide on any arbitrary new commit to be used. Of course, merely inspecting the diff for the commit will reveal nothing of use, because the contents are binary blobs. And not only are these blobs those of a compiler, they are the blobs of a compiler that is sure to be used to compile another compiler, which will then be redistributed as an opaque, non-bootstrappable binary blob to be used for compiling other compilers.You would be hard-pressed to find a more fertile breeding ground for Ken Thompson / Trusting Trust attacks. If every agent of the NSA (and whatever other agencies, including those of other countries, had access to the appropriate network traffic) somehow failed to capitalize on 6 years of opportunity to compromise an entire software ecosystem using only a basic MITM of unencrypted traffic, they deserve to be sacked. Whether such an attack actually occurred or not, this is a case study in carelessness and why bootstrappability is so important; discovering all this made me quite worried about having used a Mono version built from blobs previously, and has convinced me that, as time-wasting and tedious as this project has been, it is nevertheless probably an important one.Another note on roslyn-binariesIf you're going to write a self-hosting compiler, the least you can do is keep it self-hosting. Deciding to write a self-hosting compiler is a valid choice, of course, with its own merits and demerits, but there is something bitterly poetic about Mono starting out requiring specifically Microsoft's C# compiler in order to build (Mono did its initial bootstrapping using Microsoft's proprietary csc), achieving independence through self-hosting, being acquired by Microsoft, and thereafter coming crawling back to Microsoft's C# compiler once more before eventually dying.The funny thing is that it's not even necessary. The dependencies on new C# features are all in Mono's standard library (which increasingly borrowed code from Microsoft's corefx library), not in Mono's compiler.More binary submodules?Even before roslyn-binaries, there was binary-reference-assemblies, which contained prebuilt "reference" blobs for the various versions of the standard libraries. These exist, I assume, precisely because of the library incompatibility problems regarding overloading that I mentioned earlier. While later versions of Mono included sources and a build system for producing these reference binaries, mono-4.9.0 and earlier did not. Mono's build system still demanded something to install, though, so I told it to use the real standard library of the input Mono version. When I did get to a Mono version that at least claimed to support regenerating the reference binaries, I found that it didn't work with mcs due to differences in which libraries had to be referenced, so I had to patch it to add a bunch of references determined through trial and error.The xunit-binaries submodule was also added sometime before mono-5.1.0. This dependency makes it impossible to run the full test suite without binary blobs. Presumably for this reason, Debian elects to only run tests within the mono/mini/ and mono/tests/ subdirectories. For my part, I've disabled all tests except for those of mono-6.12.0, the final version, limited to the two aforementioned subdirectories. This is because it would take extra time for the builds, because several of the tests depend on binary blobs bundled into the Mono repository itself (which my thorough cleaning of all dlls and exes from the sources removes), because a large chunk of the tests depend on binary blobs in xunit-binaries in later versions, and because "expect some test failures" is part of the Mono documentation and I don't have the time to figure out for the Mono developers every reason why each of 17 versions of their test suite is broken.The long march through the 5.0sThe 5.0 series was when Microsoft acquired Mono, and it shows. You'll notice I needed to introduce pre- packages for various versions because in several cases a tagged release could not build the following tagged release. For that matter, they couldn't build the pre- package either, but it at least took fewer patches to get them working. The reason for this is that Mono added a dependency on Microsoft's corefx library source code, and it usually started using C# features well before mcs was able to compile them. Because of this, despite taking 8 versions to get from 1.2.6 to 4.9.0, it took another 8 versions to get through the 5.0 series, and 5 of them required nontrivial patching to massage the source into a form compilable by mcs.The final stretchEventually I realized that the dependencies on new features were all coming from corefx, not from Mono's compiler. Consequently, the only reason for this particular bootstrap-hostile ordering of builds is that it happened to be the order the Mono devs committed things. So I just cherry-picked every commit I could find touching mcs/mcs (magit was quite useful for this) and applied it to 5.10.0 to produce what is essentially the 6.12.0 compiler, then used it to jump straight to building 6.12.0.Use of this technique earlier on in the bootstrap process may be of interest to anyone looking to shorten the chain of packages.The finishing touchesMy initial goal was to package dotnet, and I had tried to progress toward that from mono-4.9.0 for a period, but with no success. During that time, though, I did encounter a bug in Mono's xbuild condition parser, which I wrote a patch for, and included in mono-6.12.0.I also discovered that xbuild would wrongly complain about missing references even when the proper assemblies were in MONO_PATH or MONO_GAC_PREFIX, because xbuild would erroneously only consider the path /gnu/store/...mono-6.12.0/lib/mono/gac when looking for global assembly caches, completely ignoring MONO_GAC_PREFIX. So I wrote a patch to fix that, and included it in mono-6.12.0.Having witnessed how much nicer it is to package things that use rpath / runpath than things that use environment variables (like python) and therefore require constant wrapping of executables and use of propagated-inputs, I devised a patch that would extend Mono's per-assembly config files to support a &lt;runpath&gt; element. For example, if you have a file /tmp/dir2/test2.exe, and there is also a file /tmp/dir2/test2.exe.config, and its contents are&lt;?xml version="1.0" encoding="utf-8"?&gt; &lt;configuration&gt; &lt;runpath path="/tmp/dir1"/&gt; &lt;/configuration&gt;and it references test1.dll, it will first look for it at /tmp/dir1/test1.dll. Note that, of course, test1.dll still needs to be accessible to the compiler at compile-time through MONO_PATH or an explicitly-specified path passed on the mcs command line.It is my hope that this feature will be of use to anybody interested in developing a build system.Future workMono had several difficult points in bootstrapping and packaging, but at the end of the day it still met the basic description of a software package: well-defined environment-supplied inputs and sources, a user-supplied install prefix, and files installed under that prefix.The dotnet world is an entirely different beast. The first step of most build systems I have encountered from that realm is downloading an entire toolchain, among other dependencies, as a binary blob. They heavily depend on the exact packages they specify being available exactly where they say to install them. There is no "install", there are no "install directories" to my knowledge. A build that doesn't contact nuget.org is an aberration. I am at a loss how to build these things, much less package them. I badly need help.There are also some portability issues with the current bootstrap path. While Portable.NET can fall back to an interpreter written in C where LibJIT isn't supported, old versions of Mono have no such capability. Strictly speaking, there is some bitrotted code for an interpreter that used to work, but has stopped working by mono-1.2.6. It was left unmaintained until it was eventually removed in 2014, only to be revived in 2017. This poses a dilemma for anybody wanting to bootstrap Mono on a platform that wasn't supported by mono-1.2.6's JIT compiler. There are a number of possible ways to try resolving this, ranging from backporting the new interpreter, to fixing up the old one for every version prior to the new interpreter, to forward-porting the old compiler and class libraries to the new interpreter, etc.The most interesting option, though, in my opinion, would be to port mcs to Portable.NET. This would achieve the intended portability, while also allowing individual builds to be much faster since we're only building mcs, not the runtime and class library each time. It would also allow us to make much bigger version jumps, since, as we discovered earlier, many of the new C# feature dependencies in Mono come from the class library rather than the compiler. Such a shortened bootstrap could also make the bootstrap path more appealing for other distributions to use instead of binaries.Closing thoughts"You wish now that our places had been exchanged. That I had died, and DotGNU had lived?""... Yes. I wish that."Maintenance of Mono was recently transferred over to WineHQ. With that announcement this statement was placed at https://www.mono-project.com:"We want to recognize that the Mono Project was the first .NET implementation on Android, iOS, Linux, and other operating systems. The Mono Project was a trailblazer for the .NET platform across many operating systems. It helped make cross-platform .NET a reality and enabled .NET in many new places and we appreciate the work of those who came before us."I would like to clarify that, according to Miguel de Icaza himself, DotGNU "started working on the system about the same time". According to this DotGNU newsletter, Portable.NET began "in January 2001". While it's unclear exactly when Portable.NET reached various milestones, and the significance of the various milestones varies somewhat (for example, Mono probably does not care that Portable.NET also includes a Java and C compiler), I think that there is cause to dispute the claim that Mono was "the first" .NET implementation on Linux.On a related note, if we haven't looked at the possibility of using Portable.NET in the Java bootstrap process, it may be worth visiting at some point.Thank you to the DotGNU project, for the .NET implementation that made this bootstrap possible, Adam Faiz, for the initial packaging of it that let me jump straight in, the Mono project, for... Mono, and you, for your time.

parallel @ Savannah: GNU Parallel 20241222 ('Bashar') released [stable] (%2024/%12/%24 %00:%Dec)GNU Parallel 20241222 ('Bashar') has been released. It is available for download at: lbry://@GnuParallel:4 Quote of the month: "Do this with gnu parallel" is the Copilot hack of the day -- Chase Clark @chasingmicrobes.bsky.social New in this release: No new features. This is a candidate for a stable release. Bug fixes and man page updates. GNU Parallel - For people who live life in the parallel lane. If you like GNU Parallel record a video testimonial: Say who you are, what you use GNU Parallel for, how it helps you, and what you like most about it. Include a command that uses GNU Parallel if you feel like it. About GNU Parallel GNU Parallel is a shell tool for executing jobs in parallel using one or more computers. A job can be a single command or a small script that has to be run for each of the lines in the input. The typical input is a list of files, a list of hosts, a list of users, a list of URLs, or a list of tables. A job can also be a command that reads from a pipe. GNU Parallel can then split the input and pipe it into commands in parallel. If you use xargs and tee today you will find GNU Parallel very easy to use as GNU Parallel is written to have the same options as xargs. If you write loops in shell, you will find GNU Parallel may be able to replace most of the loops and make them run faster by running several jobs in parallel. GNU Parallel can even replace nested loops. GNU Parallel makes sure output from the commands is the same output as you would get had you run the commands sequentially. This makes it possible to use output from GNU Parallel as input for other programs. For example you can run this to convert all jpeg files into png and gif files and have a progress bar: parallel --bar convert {1} {1.}.{2} ::: *.jpg ::: png gif Or you can generate big, medium, and small thumbnails of all jpeg files in sub dirs: find . -name '*.jpg' | parallel convert -geometry {2} {1} {1//}/thumb{2}_{1/} :::: - ::: 50 100 200 You can find more about GNU Parallel at: http://www.gnu.org/s/parallel/ You can install GNU Parallel in just 10 seconds with: $ (wget -O - pi.dk/3 || lynx -source pi.dk/3 || curl pi.dk/3/ || \ fetch -o - http://pi.dk/3 ) &gt; install.sh $ sha1sum install.sh | grep 883c667e01eed62f975ad28b6d50e22a 12345678 883c667e 01eed62f 975ad28b 6d50e22a $ md5sum install.sh | grep cc21b4c943fd03e93ae1ae49e28573c0 cc21b4c9 43fd03e9 3ae1ae49 e28573c0 $ sha512sum install.sh | grep ec113b49a54e705f86d51e784ebced224fdff3f52 79945d9d 250b42a4 2067bb00 99da012e c113b49a 54e705f8 6d51e784 ebced224 fdff3f52 ca588d64 e75f6033 61bd543f d631f592 2f87ceb2 ab034149 6df84a35 $ bash install.sh Watch the intro video on http://www.youtube.com/playlist?list=PL284C9FF2488BC6D1 Walk through the tutorial (man parallel_tutorial). Your command line will love you for it. When using programs that use GNU Parallel to process data for publication please cite: O. Tange (2018): GNU Parallel 2018, March 2018, https://doi.org/10.5281/zenodo.1146014. If you like GNU Parallel: Give a demo at your local user group/team/colleagues Post the intro videos on Reddit/Diaspora*/forums/blogs/ Identi.ca/Google+/Twitter/Facebook/Linkedin/mailing lists Get the merchandise https://gnuparallel.threadless.com/designs/gnu-parallel Request or write a review for your favourite blog or magazine Request or build a package for your favourite distribution (if it is not already there) Invite me for your next conference If you use programs that use GNU Parallel for research: Please cite GNU Parallel in you publications (use --citation) If GNU Parallel saves you money: (Have your company) donate to FSF https://my.fsf.org/donate/ About GNU SQL GNU sql aims to give a simple, unified interface for accessing databases through all the different databases' command line clients. So far the focus has been on giving a common way to specify login information (protocol, username, password, hostname, and port number), size (database and table size), and running queries. The database is addressed using a DBURL. If commands are left out you will get that database's interactive shell. When using GNU SQL for a publication please cite: O. Tange (2011): GNU SQL - A Command Line Tool for Accessing Different Databases Using DBURLs, ;login: The USENIX Magazine, April 2011:29-32. About GNU Niceload GNU niceload slows down a program when the computer load average (or other system activity) is above a certain limit. When the limit is reached the program will be suspended for some time. If the limit is a soft limit the program will be allowed to run for short amounts of time before being suspended again. If the limit is a hard limit the program will only be allowed to run when the system is below the limit.

gtypist @ Savannah: GNU Typist 2.10 released (%2024/%12/%23 %22:%Dec)This is a major release Changes in 2.10: - new welcome screen - new P lesson series for programmers - fixes for various lessons - new Romanian lessons - expand the S lesson series with a new quotation and a few more passages from Shakespeare - jump over whitespace characters at the beginning of lines in lessons - fix the terminal resize bug - fix a few compilation warnings - add the Romanian translation - updates to a few translations - few updates to the documentation - update the project license to GPL3+ - remove or update the lessons incompatible with the new license - update the KTouch lesson import script - fix warnings from help2man generated manual pages - fix a few comments Sources for this release can be downloaded here: https://ftp.gnu.org/gnu/gtypist/gtypist-2.10.tar.gz

texinfo @ Savannah: Texinfo 7.2 released (%2024/%12/%23 %18:%Dec)We have released version 7.2 of Texinfo, the GNU documentation format. It's available via a mirror (xz is much smaller than gz, but gz is available too just in case): http://ftpmirror.gnu.org/texinfo/texinfo-7.2.tar.xz http://ftpmirror.gnu.org/texinfo/texinfo-7.2.tar.gz Please send any comments to bug-texinfo@gnu.org. Full announcement: https://lists.gnu.org/archive/html/bug-texinfo/2024-12/msg00043.html

Simon Josefsson: Guix Container Images for GitLab CI/CD (%2024/%12/%18 %18:%Dec)I am using GitLab CI/CD pipelines for several upstream projects (libidn, libidn2, gsasl, inetutils, libtasn1, libntlm, …) and a long-time concern for these have been that there is too little testing on GNU Guix. Several attempts have been made, and earlier this year Ludo’ came really close to finish this. My earlier effort to idempotently rebuild Debian recently led me to think about re-bootstrapping Debian. Since Debian is a binary distribution, it re-use earlier binary packages when building new packages. The prospect of re-bootstrapping Debian in a reproducible way by rebuilding all of those packages going back to the beginning of time does not appeal to me. Instead, wouldn’t it be easier to build Debian trixie (or some future release of Debian) from Guix, by creating a small bootstrap sandbox that can start to build Debian packages, and then make sure that the particular Debian release can idempotently rebuild itself in a reproducible way? Then you will eventually end up with a reproducible and re-bootstrapped Debian, which pave the way for a trustworthy release of Trisquel. Fortunately, such an endeavour appears to offer many rabbit holes. Preparing Guix container images for use in GitLab pipelines is one that I jumped into in the last few days, and just came out of. Let’s go directly to the point of this article: here is a GitLab pipeline job that runs in a native Guix container image that builds libksba after installing the libgpg-error dependency from Guix using the pre-built substitutes. test-amd64-latest-wget-configure-make-libksba: image: registry.gitlab.com/debdistutils/guix/container:latest before_script: - lndir /gnu/store/*profile/etc/ /etc - rm -f /etc/group - groupadd --system guixbuild - for i in $(seq -w 1 10); do useradd -g guixbuild -G guixbuild -d /var/empty -s $(command -v nologin) -c "Guix build user $i" --system guixbuilder$i; done - export HOME=/ - export LANG=C.UTF-8 - guix-daemon --disable-chroot --build-users-group=guixbuild &amp; - guix archive --authorize &lt; /share/guix/ci.guix.gnu.org.pub - guix archive --authorize &lt; /share/guix/bordeaux.guix.gnu.org.pub - guix describe - guix package -i libgpg-error - GUIX_PROFILE="//.guix-profile" - . "$GUIX_PROFILE/etc/profile" script: - wget https://www.gnupg.org/ftp/gcrypt/libksba/libksba-1.6.7.tar.bz2 - tar xfa libksba-1.6.7.tar.bz2 - cd libksba-1.6.7 - ./configure - make V=1 - make check VERBOSE=t V=1 You can put that in a .gitlab-ci.yml and push it to GitLab and you will end up with a nice pipeline job output. As you may imagine, there are several things that are sub-optimal in the before_script above that ought to be taken care of by the Guix container image, and I hope to be able to remove as much of the ugliness as possible. However that doesn’t change that these images are useful now, and I wanted to announce this work to allow others to start testing them and possibly offer help. I have started to make use of these images in some projects, see for example the libntlm commit for that. You are welcome to join me in the Guix container images for GitLab CI/CD project! Issues and merge requests are welcome – happy hacking folks!

GNU Taler news: GNU Taler 0.14 released (%2024/%12/%15 %23:%Dec) We are happy to announce the release of GNU Taler v0.14.