GNU Planet!

On the occasion of the Point Zero Forum's Innovation Tour, Evgeny Grin has interviewed Isidor Wallimann who is introducing GNU Taler for the local currency Netzbon in Basel.

When I opened this Savannah project I imported items from the old GNU tasklist document. 20 years later all of the context has been lost (if there ever was any) so now if anyone asks about these tasks it just leads to frustration on everyone's part.

I therefore deleted the original help wanted entries that date back to 2003. If anyone wants to help the GNU project, the best way to do that is to pick one of the FSF's High-Priority projects:

https://www.fsf.org/campaigns/priority-projects

On the occasion of the Point Zero Forum's Innovation Tour, Berna Alp has interviewed Christian Blättler who implemented a system for using GNU Taler for unlikable discounts and subscriptions.

On the occasion of the Point Zero Forum's Innovation Tour, Berna Alp has interviewed Nicola Eigel who implemented a real-time auditor for the GNU Taler exchange with his colleague Cédric Zwahlen.

On the occasion of the Point Zero Forum's Innovation Tour, we have showcased the privacy-preserving GNU Taler payment system along with its various applications and extensions – as well as other payment- and digital identity related projects – that are currently being developed at the Bern University of Applied Sciences and its international partners as part of the NGI TALER EU project. This page includes recordings of the main talks. In the near future, we will also post interviews made with some of the poster presenters (sadly, only about half of the people could be interviewed due to time constraints).

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

Automake 1.17 released. Announcement:
https://lists.gnu.org/archive/html/autotools-announce/2024-07/msg00000.html

The 23rd release of GNU Astronomy Utilities (Gnuastro) is now available. See the full announcement for all the new features in this release and the many bugs that have been found and fixed: https://lists.gnu.org/archive/html/info-gnuastro/2024-07/msg00001.html

In this bachelor thesis Yann Doy presents his implementation of a concept of eKYC (electronic Knwo Your Customer procedure).

After rebuilding all added/modified packages in Trisquel, I have been circling around the elephant in the room: 99% of the binary packages in Trisquel comes from Ubuntu, which to a large extent are built from Debian source packages. Is it possible to rebuild the official binary packages identically? Does anyone make an effort to do so? Does anyone care about going through the differences between the official package and a rebuilt version? Reproducible-build.org‘s effort to track reproducibility bugs in Debian (and other systems) is amazing. However as far as I know, they do not confirm or deny that their rebuilds match the official packages. In fact, typically their rebuilds do not match the official packages, even when they say the package is reproducible, which had me surprised at first. To understand why that happens, compare the buildinfo file for the official coreutils 9.1-1 from Debian bookworm with the buildinfo file for reproducible-build.org’s build and you will see that the SHA256 checksum does not match, but still they declare it as a reproducible package. As far as I can tell of the situation, the purpose of their rebuilds are not to say anything about the official binary build, instead the purpose is to offer a QA service to maintainers by performing two builds of a package and declaring success if both builds match.

I have felt that something is lacking, and months have passed and I haven’t found any project that address the problem I am interested in. During my earlier work I created a project called debdistreproduce which performs rebuilds of the difference between two distributions in a GitLab pipeline, and display diffoscope output for further analysis. A couple of days ago I had the idea of rewriting it to perform rebuilds of a single distribution. A new project debdistrebuild was born and today I’m happy to bless it as version 1.0 and to announces the project! Debdistrebuild has rebuilt the top-50 popcon packages from Debian bullseye, bookworm and trixie, on amd64 and arm64, as well as Ubuntu jammy and noble on amd64, see the summary status page for links. This is intended as a proof of concept, to allow people experiment with the concept of doing GitLab-based package rebuilds and analysis. Compare how Guix has the guix challenge command.

Or I should say debdistrebuild has attempted to rebuild those distributions. The number of identically built packages are fairly low, so I didn’t want to waste resources building the rest of the archive until I understand if the differences are due to consequences of my build environment (plain apt-get build-dep followed by dpkg-buildpackage in a fresh container), or due to some real difference. Summarizing the results, debdistrebuild is able to rebuild 34% of Debian bullseye on amd64, 36% of bookworm on amd64, 32% of bookworm on arm64. The results for trixie and Ubuntu are disappointing, below 10%.

So what causes my rebuilds to be different from the official rebuilds? Some are trivial like the classical problem of varying build paths, resulting in a different NT_GNU_BUILD_ID causing a mismatch. Some are a bit strange, like a subtle difference in one of perl’s headers file. Some are due to embedded version numbers from a build dependency. Several of the build logs and diffoscope outputs doesn’t make sense, likely due to bugs in my build scripts, especially for Ubuntu which appears to strip translations and do other build variations that I don’t do. In general, the classes of reproducibility problems are the expected. Some are assembler differences for GnuPG’s gpgv-static, likely triggered by upload of a new version of gcc after the original package was built. There are at least two ways to resolve that problem: either use the same version of build dependencies that were used to produce the original build, or demand that all packages that are affected by a change in another package are rebuilt centrally until there are no more differences.

The current design of debdistrebuild uses the latest version of a build dependency that is available in the distribution. We call this a “idempotent rebuild“. This is usually not how the binary packages were built originally, they are often built against earlier versions of their build dependency. That is the situation for most binary distributions.

Instead of using the latest build dependency version, higher reproducability may be achieved by rebuilding using the same version of the build dependencies that were used during the original build. This requires parsing buildinfo files to find the right version of the build dependency to install. We believe doing so will lead to a higher number of reproducibly built packages. However it begs the question: can we rebuild that earlier version of the build dependency? This circles back to really old versions and bootstrappable builds eventually.

While rebuilding old versions would be interesting on its own, we believe that is less helpful for trusting the latest version and improving a binary distribution: it is challenging to publish a new version of some old package that would fix a reproducibility bug in another package when used as a build dependency, and then rebuild the later packages with the modified earlier version. Those earlier packages were already published, and are part of history. It may be that ultimately it will no longer be possible to rebuild some package, because proper source code is missing (for packages using build dependencies that were never part of a release); hardware to build a package could be missing; or that the source code is no longer publicly distributable.

I argue that getting to 100% idempotent rebuilds is an interesting goal on its own, and to reach it we need to start measure idempotent rebuild status.

One could conceivable imagine a way to rebuild modified versions of earlier packages, and then rebuild later packages using the modified earlier packages as build dependencies, for the purpose of achieving higher level of reproducible rebuilds of the last version, and to reach for bootstrappability. However, it may be still be that this is insufficient to achieve idempotent rebuilds of the last versions. Idempotent rebuilds are different from a reproducible build (where we try to reproduce the build using the same inputs), and also to bootstrappable builds (in which all binaries are ultimately built from source code). Consider a cycle where package X influence the content of package Y, which in turn influence the content of package X. These cycles may involve several packages, and it is conceivable that a cycle could be circular and infinite. It may be difficult to identify these chains, and even more difficult to break them up, but this effort help identify where to start looking for them. Rebuilding packages using the same build dependency versions as were used during the original build, or rebuilding packages using a bootsrappable build process, both seem orthogonal to the idempotent rebuild problem.

Our notion of rebuildability appears thus to be complementary to reproducible-builds.org’s definition and bootstrappable.org’s definition. Each to their own devices, and Happy Hacking!

Have you ever wondered how to get a friend or colleague or even a complete stranger hooked up with free software? Here's the ultimate guide.

 When NeXT still existed and the black hardware was a thing, Steve Jobs made the announcement that OPENSTEP would be created and that the object model, not the operating system and not the hardware, was the important thing.

This is a concept that Apple has forgotten.  With it's push towards Apple Silicon and a walled-garden, Apple has committed itself to the same pitfall that NeXT fell into.  NeXT lacked the infrastructure to handle OPENSTEP running on multiple kinds of hardware, but the object model on different OSes was successful... this is evident in OPENSTEP1.1 for Solaris and OPENSTEP for NT.

GNUstep attempts to reach the same goal, but provides the APIs that are available with Cocoa.   The object model IS the important thing and this is why GNUstep is so important.  It breaks the walled garden and makes it possible for users to run their apps and tools on other operating systems.  GNUstep HASN'T forgotten and we believe this is a core concept that Apple has left behind.

GNU direvent version 5.4 is available for download.

New in this version:

Simultaneous execution limits

It is possible to limit number of command instances that are allowed to run simultaneously for a particular watcher.  This is done using
the max-instances statement in watcher section.

Restore the "nowait" default

In previous version, watchers waited for the handler to terminate, unless given the nowait option explicitly.  It is now fixed and nowait is the default, as described in the documentation.

Fix bug in generic to system event translation

Fix sentinel code

In some cases setting the sentinel effectively removed the original watcher.  That happened if the full file name of the original watcher
and its directory part produced the same hash code.

GNU dbm version 1.24 is available for download. New in this version:

New gdbm_load option: --update

The --update (-U) option instructs gdbm_load to update an existing database.

Fix semantics of gdbm_load -r

The --replace (-r) is valid only when used together with --update.

Use getline in gdbmtool shell

New function: gdbm_load_from_file_ext

In contrast to gdbm_load and gdbm_load_from_file, which derive the value of the flag parameter for gdbm_open from the value of their replace argument, this function allows the caller to specify it explicitly. 

Bugfixes

• Fix binary dump format for key and/or data of zero size (see bug 656)
• Fix location tracking and recover command in gdbtool (see bug 566)
• Fix possible buffer underflow in gdbmload.
• Ensure any padding bytes in avail_elem structure are filled with 0. This fixes debian bug 1031276.
• Improve the documentation.

from arch:

After upgrading to openssh-9.8p1, the existing SSH daemon will be unable to accept new connections. When upgrading remote hosts, please make sure to restart the sshd service using systemctl try-restart sshd right after upgrading.

We are evaluating the possibility to automatically apply a restart of the sshd service on upgrade in a future release of the openssh-9.8p1 package.

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

This is a bugfix release in the 4.x series.

See the file NEWS in the distribution tarball for a list of issues
fixed in this release.

The tarball poke-4.2.tar.gz is now available at
https://ftp.gnu.org/gnu/poke/poke-4.2.tar.gz.

    > GNU poke (http://www.jemarch.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.


Thanks to the people who contributed with code and/or documentation to
this release.

Happy poking!

Mohammad-Reza Nabipoor