https://www.smart ... com/lp/management

This offering sure looks like GNU remotecontrol. Perhaps it is our code.

Autoconf 2.72 has been released, see the release announcement:

https://lists.gnu ... -03/msg00000.html

A major bugfix release. Complete rewrite of the decompressor to
fix hairy section reading bugs in some big files. Fixed many dxf roundtrips.
See https://www.gnu.o ... oftware/libredwg/ and https://github.co ... /blob/0.13.4/NEWS

Here are the compressed sources:
http://ftp.gnu.or ... dwg-0.13.4.tar.gz (21MB)
http://ftp.gnu.or ... dwg-0.13.4.tar.xz (11MB)

Here are the GPG detached signatures[*]:
http://ftp.gnu.or ... 0.13.4.tar.gz.sig
http://ftp.gnu.or ... 0.13.4.tar.xz.sig

Use a mirror for higher download bandwidth:
https://www.gnu.o ... rg/order/ftp.html

Here are more binaries:
https://github.co ... leases/tag/0.13.4

Here are the SHA256 checksums:

cacff5510f46723462e854e15ecfa97cbc7475acb3eb7ae1ca6e4193ecc2267d  libredwg-0.13.4.tar.gz
7e153ea4dac4cbf3dc9c50b9ef7a5604e09cdd4c5520bcf8017877bbe1422cd5  libredwg-0.13.4.tar.xz
cb46bce034296e91cb1a982cd53ec1928b11f4f7f70512dd21513a27959688b5  libredwg-0.13.4-win64.zip

Please ignore the broken Source code (tar.gz, .zip) artefacts. They cannot be deleted.

[*] 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 libredwg-0.13.4.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

gpg --recv-keys B4F63339E65D6414

and rerun the gpg --verify command.

This is to announce hello-2.12.3, a stable release.

GNU hello is a demonstration and model of the GNU coding standards for
hackers, and a simple example for users.

There have been 18 commits by 2 people in the 43 weeks since 2.12.2.

See the NEWS below for a brief summary.

Thanks to everyone who has contributed!
The following people contributed changes to this release:

  Collin Funk (16)
  Reuben Thomas (2)

Collin
 [on behalf of the hello maintainers]
==================================================================

Here is the GNU hello home page:
    https://gnu.org/s/hello/

Here are the compressed sources and a GPG detached signature:
  https://ftpmirror.gnu.org/hello/hello-2.12.3.tar.gz
  https://ftpmirror.gnu.org/hello/hello-2.12.3.tar.gz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

Here are the SHA256 and SHA3-256 checksums:

  SHA256 (hello-2.12.3.tar.gz) = DV9gFUOC/uELEUocNOeF2LH0kgc64tOm97FHaHs2aqA=
  SHA3-256 (hello-2.12.3.tar.gz) = VQz4Y71rvDa2iSh59ZUTHiT0wJmFWKo4VcUvpkRi4Ek=

Verify the base64 SHA256 checksum with 'cksum -a sha256 --check'
from coreutils-9.2 or OpenBSD's cksum since 2007.

Verify the base64 SHA3-256 checksum with 'cksum -a sha3 --check'
from coreutils-9.8.

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 hello-2.12.3.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   rsa4096/8CE6491AE30D7D75 2024-03-11 [SC]
        Key fingerprint = 2371 1855 08D1 317B D578  E5CC 8CE6 491A E30D 7D75
  uid                 [ultimate] Collin Funk <collin.funk1@gmail.com>

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 collin.funk1@gmail.com

  gpg --recv-keys 8CE6491AE30D7D75

  wget -q -O- 'https://savannah.gnu.org/project/release-gpgkeys.php?group=hello&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 hello-2.12.3.tar.gz.sig

This release is based on the hello git repository, available as

  git clone https://https.git.savannah.gnu.org/git/hello.git

with commit 89fff19b23e35f0e97072507685c92aaae3d04c7 tagged as v2.12.3.

For a summary of changes and contributors, see:

  https://gitweb.git.savannah.gnu.org/gitweb/?p=hello.git;a=shortlog;h=v2.12.3

or run this command from a git-cloned hello directory:

  git shortlog v2.12.2..v2.12.3

This release was bootstrapped with the following tools:
  Autoconf 2.72
  Automake 1.18.1
  Gnulib 2026-03-16 4e11e3d07a79a49eaa9b155c43801bbc1e5bd86e

NEWS

* Noteworthy changes in release 2.12.3 (2026-03-17) [stable]

The manual no longer mentions the -h and -v short options which were
removed in release 2.11.

Update gnulib for compatibility with glibc-2.43.

GNU hello no longer fails to build with BSD implementations of the
'make' command.  Previously they would be unable to find a target
listed as a dependency of the 'hello' program.

Hello everyone,

We are pleased to announce the release of TeXmacs version 2.1.5

This version uses Qt6 by default, supports very high-definition displays, and introduces new ongoing collaborative editing features. On Windows, TeXmacs is now available on the Microsoft Store. On Linux, we have a new Qt6 AppImage that maximizes compatibility with GNU Linux distributions. On Mac, we have new universal packages.

- Download for Windows: https://www.texma ... d/windows.en.html
- Download for macOS: https://www.texma ... ad/macosx.en.html
- Download for GNU Linux: https://www.texma ... oad/linux.en.html

Happy writing with TeXmacs!

The TeXmacs Team

13 March 2026 Unifont 17.0.04 is now available.  This is a minor release aligned with Unicode 17.0.0.

This release notably includes separate BDF, PCF, and OpenType font files with 28,000+ Unicode T-source Chinese glyphs created by Kusanagi_Sans and Kao Chen-tung (高振東) in font files beginning with "unifont_t".  Many other Chinese glyphs have been added.  Also, font/Makefile has been reorganized for more efficient font file building.  See the ChangeLog file for details.

Download this release from GNU server mirrors at:

     https://ftpmirror ... /unifont-17.0.04/

or if that fails,

     https://ftp.gnu.o ... /unifont-17.0.04/

or, as a last resort,

     ftp://ftp.gnu.org ... /unifont-17.0.04/

These files are also available on the unifoundry.com website:

     https://unifoundr ... /unifont-17.0.04/

Font files are in the subdirectory

     https://unifoundr ... 0.04/font-builds/

A more detailed description of font changes is available at

      https://unifoundr ... nifont/index.html

and of utility program changes at

      https://unifoundr ... nt-utilities.html

Information about Hangul modifications is at

      https://unifoundr ... hangul/index.html

and

      http://unifoundry ... l-generation.html

Enjoy!


Paul Hardy
GNU Unifont Maintainer

I'm very pleased to announce the release of a new version of GNU PSPP.  PSPP is a program for statistical analysis of sampled data.  It is a free replacement for the proprietary program SPSS.

Changes from 2.1.0 to 2.1.1:

• Translation updates.
• Bug fixes in build system and tests.
• No longer mistakenly labeled as a "test release".

Please send PSPP bug reports to bug-gnu-pspp@gnu.org.

I'm very pleased to announce the release of a new version of GNU PSPP.  PSPP is a program for statistical analysis of sampled data.  It is a free replacement for the proprietary program SPSS.

Changes from 2.0.1 to 2.1.0:

• Bug fixes.
• Translation updates.

Please send PSPP bug reports to bug-gnu-pspp@gnu.org.

We have released version 7.3 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):

https://ftpmirror ... exinfo-7.3.tar.xz
https://ftpmirror ... exinfo-7.3.tar.gz

Please send any comments to bug-texinfo@gnu.org.

Full announcement:

https://lists.gnu ... -03/msg00007.html

Fifteen months have passed since our last Guix/Hurd on a Thinkpad X60 post and a lot has happened with respect to the Hurd.

And most of you will have guessed, unless you skipped the title of this post, the rumored x86_64 support has landed in Guix!

Here is a not-so-short overview of our Hurd work over the past 1.5 years:

• The build daemon fails when invoking guix authenticate on the Hurd bug was fixed. This was our most pressing problem as it meant that we could not keep our substitutes up to date. It took 15 comments and 13 weeks to get it resolved. Phew!

• Installer support for (cross)-installing the Hurd. Also adding developer support for running the installer directly from the source tree; Guix 1.5.0 lets you install the Hurd on bare metal.

• Fix tests in the Shepherd.

• Update hurd to 0.9.git20250420, gnumach to 1.8+git20250304.

• Add support for a cross-built gnumach, allowing the removal of an ugly workaround when cross-building for the Hurd.

• Update rumpkernel to 0-20250111.

• Support for different childhurd types, a.k.a. 64-bit childhurds in da house.

• The syslogd used by default is now from the Shepherd streamio, gnumach, and the Shepherd, to make the kernel log work.

• Update hurd to 0.9.git20251029, gnumach: to 1.8+git20250731.

• Now that the go-team branch has been merged, gccgo now works (native only).

• Fix proc server for zombie processes which caused a shepherd test to fail.

• Fix all the dependencies of the guix package, again:

  • libgit2 tests,
  • dbus, opensp, po4a,

• Resurrect password hashing.

• Installer: Fixes for the Hurd.

• Installer: More clearly mark the Hurd as experimental.

• Installer: Add Hurd x86_64 as an option. This took 15 comments, uncovering and fixing several bugs.

• Add support for x86_64-gnu, aka the 64-bit Hurd. The initial patch set consisted of 31 patches. This patch set took four iterations and 208 messages before its final 58 patches were merged to `core-packages-team'. Janneke writes: "Lo and behold, the 64-bit Hurd boots! Again, thanks to the help from the kind folks over at libera #hurd and their excellent work. Do something like:"

./pre-inst-env guix system image --image-type=hurd64-qcow2 \
  gnu/system/examples/bare-hurd64.tmpl

Pushed a `core-packages-team' with (this one) GCC 14 commit.  Let the
fun begin :)

We had a lot of fun...

• Request for merging "core-packages-team" branch: 247 commits, took 114 comments 8 weeks and 24 iterations with 247 commits from 9 people before presenting the initial merge.

• The actual merge "core-packages-team": 85 more commits to a total of 332, by 17 people and 27 weeks before actual merge. 173 packages with build fixes to relax GCC 14's strictness, 109 package updates to fix build with GCC 14.

• With this all in place we can have ci build a 64-bit hurd image, and

• Report what packages still need to be fixed for that image to build.

• For convenience we added i586-pc-gnu and x86_64-pc-gnu cross toolchains.

Summarizing, building the Guix manifest for the 32-bit Hurd (i586-gnu) should work really well. Sadly, for the 64-bit Hurd (x86_64-gnu) is still a bit problematic as some tests in e.g., openssl, python, cmake, .... hang. This is still under investigation.

What Took You So Long?

We're so glad you asked! Usually, adding a new architecture should just take a couple of commits:

• Add cross-compilation support for the x86_64-pc-gnu target, aka 64-bit Hurd, and then
• Add support for x86_64-gnu, aka the 64-bit Hurd.

pretty neat, right? So, what's the story with the 64-bit Hurd? There are two problems: 64-bit Hurd support was added in GCC 14, while Guix was still at GCC 11. This means we "only" had to

• Update the gcc cross compiler to GCC 14 (one, simple commit), and
• Fix all cross builds (initially "just" 23 commits).

The second step involves building for all architectures and fixing all breakage. Sometimes, fixing one architecture breaks another.

When Guix supported cross-building with GCC 14, and supported the 64-bit Hurd, we could create and boot a 64-bit childhurd. After that, we could start building 64-bit Hurd packages...but only after also

• Use gcc-14, gcc-toolchain-14 on the 64-bit Hurd

This, however does not support offloading. For that, we would need to:

• Update gcc, gcc-toolchain, libgccjit to 14, and

• Make sure that all packages in commencement.scm successfully build natively on x86_64-hurd, which took only some 35 commits.

This can simply be verified by building the hello package:

guix build --system=x86_64-gnu hello

However, GCC 14 is not a regular update: it is waaay more strict with respect to C code compilation. This means that, before actually switching, we had to fix 173 package builds and update another 109 packages to not break all of Guix. This took a total of 17 people and 35 weeks to complete.

You can understand that we are excited that the NLnet Foundation has been sponsoring this work!

Installing and Using the 64-bit Hurd

Easiest is to change your 32-bit childhurd definition into 64-bit, by adding

(type 'hurd64-qcow2)

to your hurd-vm-configuration. And if you don't have a hurd-vm-configuration yet?. Easy, in that case just add

(use-service-modules virtualization)
[..]
(hurd-vm-configuration
  (type 'hurd64-qcow2))

into your your hurd-vm-service-type definition[^0]. And if you don't have a hurd-vm-service-type yet? Easy, in that case just add

(use-service-modules virtualization)
[..]
(service hurd-vm-service-type
         (hurd-vm-configuration
           (type 'hurd64-qcow2)))

to your operating system definition. Reconfigure your system and you'd be able to:

(if you don't have a childhurd definition in your ~/.ssh/config you will have to use something like: ssh -p 10022 root@localhost[^1]).

And if you don't have a Guix operating system definition...The 64-bit Hurd is now an option in the installer:

and can be installed in a VM. Make sure to use --machine q35 with qemu.

To build a disk image for a virtual machine, do:

./pre-inst-env guix system image --image-type=hurd64-qcow2 \
    gnu/system/examples/bare-hurd64.tmpl

You may run it like so:

guix shell qemu -- qemu-system-x86_64 -m 2048 -M q35       \
  --enable-kvm                                             \
  --device e1000,netdev=net0                               \
  --netdev user,id=net0,hostfwd=tcp:127.0.0.1:10022-:2222  \
  --snapshot                                               \
  --hda /gnu/store/...-disk-image

(note that the 64-bit Hurd does not seem to show a login prompt)

and use it like:

ssh -p 10022 root@localhost
guix build -e '(@@ (gnu packages commencement) gnu-make-boot0)'

or even, if you build the image with at least --image-size=3G:

guix build hello

RumpNET Support

Upstream has added support for Intel i8254x Gigabit Ethernet using RumpNET.

Damien Zammit wrote:

This adds a working rump driver for /dev/wmX cards, which are Intel i8254x Gigabit Ethernet devices. (See man.netbsd.org for "wm(4)") This should be easily extended to support other NICs by contributing some makefile foo to netbsd/rump.

Example usage[^2]:

settrans -fgap /dev/rumpnet /hurd/rumpnet
settrans -fgap /dev/wm0 /hurd/devnode -M /dev/rumpnet wm0
settrans -fgap /servers/socket/2 /hurd/pfinet -i /dev/wm0
ifup /dev/wm0

With our updated hurd and rumpkernel packages, this should be available in Guix now too. Please let us know if you got it to work! (If you tried and didn't get it to work, we'd also like to know!)

Status

One of the most frequently asked questions is probably: Does X work on the Hurd yet? The canonical answer to that question is: Please read the GNU/Hurd FAQ.

A good summary of the current status was presented by Samuel Thibault in his GNU/Hurd progress at FOSDEM'26, in which he also makes compelling arguments for the Hurd, such as: Freedom from the system administrator and sharing the GNU heritage and values it's no coincidence that Guix also solves a part of that problem, allowing any user to install packages.

Debian GNU/Hurd has been a reality for some years now, reaching 75% of Debian packages being available for the Hurd.

As a comparison, in Guix only about 1.7% (32-bit) and 0.9% (64-bit) of packages are available for the Hurd. These percentages fluctuate a bit but continue to grow (both grew with a couple tenth percent point during the preparation of this blog post), and as always, might grow faster with your help.

So while Guix GNU/Hurd has an exciting future, please be aware that it lacks many packages and services, including Xorg.

If you would simply like to install the Hurd on bare metal running your favorite window manager (e.g.: i3, icewm, etc.) or lightweight desktop environment (Xfce) right now, then installing Debian GNU/Hurd is a good choice. Though we hope to catch up to them soon!

Last October, the 64-bit Hurd was reported to run on bare metal. Now that Guix 1.5.0's installer also lets you install the Hurd on bare metal, we'd be thrilled to year from you if you manage to replicate this!

What's Next?

In an earlier post we tried to answer the question “Why bother with the Hurd anyway?” An obvious question because it is all too easy to get discouraged, to downplay or underestimate the potential social impact of GNU and the Hurd.

Echoing Samuel Thibault's talk we would like to add: because it offers a better:

• Freedom #0: the freedom to run the program as you wish, for any purpose.
• Freedom from the System Administrator.

guix pull is known to work but only by pulling from a local branch doing something like:

mkdir -p src/guix
cd src/guix
git clone https://git.guix.gnu.org/guix.git master
cd master
git branch keyring origin/keyring
guix pull --url=$HOME/src/guix/master

kinda like we did it in the old days.

Other interesting task for Guix include:

• Have guix pull from a non-local URL work on the Hurd,
• Have guix system reconfigure work on the Hurd,
• Figure out WiFi support with NetDDE (and add it to installer!),
• Figure out WiFi support with RumpNET (and add it to installer!),
• An isolated build environment (or better wait for, err, contribute to the Guile build daemon?),
• An installer running the Hurd, and,
• Packages, packages, packages!

We tried to make Hurd development as easy and as pleasant as we could. As you have seen, things start to work pretty nicely and there is still plenty of work to do in Guix. In a way this is “merely packaging” the amazing work of others. Some of the real work that needs to be done and which is being discussed and is in progress right now includes:

• Audio support (this was sponsored by NLnet, thanks!),
• RumpNET,
• SMP,
• Journaling for ext2,
• AArch64,
• RISC-V.

With the exception maybe of adding RumpNET NICs, these tasks look daunting, and indeed that’s a lot of work ahead. But the development environment is certainly an advantage. Take an example: surely anyone who’s hacked on device drivers or file systems before would have loved to be able to GDB into the code, restart it, add breakpoints and so on—that’s exactly the experience that the Hurd offers. As for Guix, it will make it easy to test changes to the micro-kernel and to the Hurd servers, and that too has the potential to speed up development and make it a very nice experience.

SMP support for the 64-bit Hurd

During the preparation of this blog post a patch set fixing SMP for the 64-bit Hurd, (well, gnumach actually) was presented by Damien Zammit. So most probably we'll have 64-bit multiprocessing real soon now! It seems however, that we will need new bootstrap binaries for that.

Join #guix and #hurd on libera.chat or the mailing lists and get involved!

Footnotes

[0]: Note: with an up-to-date guix this is no longer necessary!
Actually, as the 64-bit Hurd uses rumpdisk exclusively, and gnumach by default uses still it builtin IDE drivers, we also need to tell gnumach about that by adding the (kernel-arguments '("noide")).

(use-service-modules virtualization)
[..]
(hurd-vm-configuration
  (type 'hurd64-qcow2)
  (os (operating-system
        (inherit %hurd-vm-operating-system)
        (kernel-arguments '("noide")))))

We expect this to be the the default in the future.

[1]: You may have to override your childhurd's openssh-service definition, something like

(services
 (modify-services (operating-system-user-services %hurd-vm-operating-system)
   (openssh-service-type
    config =>
    (openssh-configuration
     (inherit config)
     (authorized-keys `(("root"
                         ,(local-file "/home/janneke/.ssh/janneke.pub"))))))))

but you can also take inspiration from the bare-hurd64.tmpl template.

[2]: Note that while is comes straight from a commit to the Hurd git repository, this is a Debian-specific recipe, Guix does not have ifup, and per this updated wiki page there's probably extra networking interface configuration needed too (in Debian you're intstructed to -- imperatively -- edit /etc/network/interfaces).

We're pleased to announce the release of GNU MediaGoblin 0.15.0. See the release notes for full details and upgrading instructions.

This is a relatively small release to resolve installation issues on Debian Trixie and Bookworm.

This version has been tested on Debian Bookworm (12), Debian Trixie (13), Ubuntu 22.04, Ubuntu 24.04 and Fedora 43. This release drops support for Debian Bullseye (11) and Ubuntu 20.04.

To join us and help improve MediaGoblin, please visit our getting involved page.