GNU Planet!

A minor bugfix release, mostly fixes missing dwg2ps.1

See https://www.gnu.org/software/libredwg/ and https://git.savannah.gnu.org/cgit/libredwg.git/tree/NEWS?h=0.13.3

Here are the compressed sources:
http://ftp.gnu.org/gnu/libredwg/libredwg-0.13.3.tar.gz (20.1MB)
http://ftp.gnu.org/gnu/libredwg/libredwg-0.13.3.tar.xz (10.1MB)

Here are the GPG detached signatures[*]:
http://ftp.gnu.org/gnu/libredwg/libredwg-0.13.3.tar.gz.sig
http://ftp.gnu.org/gnu/libredwg/libredwg-0.13.3.tar.xz.sig

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

Here are more binaries:
https://github.com/LibreDWG/libredwg/releases/tag/0.13.3

Here are the SHA256 checksums:


[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:

gpg --verify libredwg-0.13.3.tar.gz.sig

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

gpg --recv-keys B4F63339E65D6414

and rerun the gpg --verify command.

24 February 2024 Unifont 15.1.05 is now available.  This release adds the 222 CJK Unified Ideographs Extension D glyphs (U+2B740..U+2B81D) and 335 Plane 2 and Plane 3 common Cantonese ideographs, as well as other additions amounting to almost 600 ideograph additions, from Boris Zhang, Yzy32767, and others.

This release also replaces the Hangul blocks outside the Hangul Syllables range with new glyphs from Ho-seok Ee that are now consistent with the style of the Hangul Syllables glyphs.

Other minor changes are also included.  Details are in the ChangeLog file.

This release no longer builds TrueType fonts by default, as announced over the past year.  They have been replaced with their OpenType equivalents.  TrueType fonts can still be built manually by typing "make truetype" in the font directory.

Download this release from GNU server mirrors at:

     https://ftpmirror.gnu.org/unifont/unifont-15.1.05/

or if that fails,

     https://ftp.gnu.org/gnu/unifont/unifont-15.1.05/

or, as a last resort,

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

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

     https://unifoundry.com/pub/unifont/unifont-15.1.05/

Font files are in the subdirectory

     https://unifoundry.com/pub/unifont/unifont-15.1.05/font-builds/

A more detailed description of font changes is available at

      https://unifoundry.com/unifont/index.html

and of utility program changes at

      https://unifoundry.com/unifont/unifont-utilities.html

Information about Hangul modifications is at

      https://unifoundry.com/hangul/index.html

and

      http://unifoundry.com/hangul/hangul-generation.html

Download from https://ftp.gnu.org/gnu/libunistring/libunistring-1.2.tar.gz

This is a stable release.

New in this release:

• The data tables and algorithms have been updated to Unicode version 15.1.0.
• New functions u8_pcpy, u16_pcpy, u32_pcpy, similar to mempcpy.
• New functions uc_indic_conjunct_break_name, uc_indic_conjunct_break_byname, uc_indic_conjunct_break.
• New functions uc_is_property_prepended_concatenation_mark, uc_is_property_id_compat_math_start, uc_is_property_id_compat_math_continue, uc_is_property_ids_unary_operator and new constants UC_PROPERTY_PREPENDED_CONCATENATION_MARK, UC_PROPERTY_ID_COMPAT_MATH_START, UC_PROPERTY_ID_COMPAT_MATH_CONTINUE, UC_PROPERTY_IDS_UNARY_OPERATOR.
• New constant _libunistring_unicode_version.
• The UTF-8 decoder functions, especially u8_mbtouc, are now more Unicode Standard compliant.
• The *printf functions no longer support the %n directive, for security reasons.
• Fixed a bug in the *printf functions: In the %U, %lU, %llU directives, a negative width given as an argument did not trigger left-justification.
• The functions u16_strstr and u32_strstr now operate in worst-case linear time.

Download from https://ftp.gnu.org/pub/gnu/gettext/gettext-0.22.5.tar.gz

This is a bug-fix release.

New in this release:

• The replacements for the printf()/fprintf()/... functions that are provided through <libintl.h> on native Windows and NetBSD now enable GCC's format string analysis (-Wformat).

• Bug fixes:
  • xgettext's processing of Vala files with printf method invocations has been corrected (regression in 0.22).
  • Build fixes on macOS.

We have been invited by NLnet to present the GNU Name System and our efforts to create and publish RFC 9498 .

You can find the recording and slides on the NLnet webinar page . It includes a live demo of our GNS registrar with integrated GNU Taler payments.

The work on GNS was generously funded by NLnet as part of their NGI Search and Discovery and NGI Zero Entrust Programme .

I got a new laptop! It’s a Framework 13 AMD: 8 cores, 2 threads per core, 64 GB RAM, 3:2 2256×1504 matte screen. It kicks my 5-year-old Dell XPS 13 in the pants, and I am so relieved to be back to a matte screen. I just got it up and running with Guix, which though easier than past installation experiences was not without some wrinkles, so here I wanted to share a recipe for what worked for me.

(I swear this isn’t going to become a product review blog, but when I went to post something like this on the Framework forum I got an error saying that new users could only post 2 links. I understand how we got here but hoo, that is a garbage experience!)

Upstream Guix works on the Framework 13 AMD, but only with software rendering and no wifi, and I wasn’t able to install from upstream media. This is mainly because Guix uses a modified kernel and doesn’t include necessary firmware. There is a third-party nonguix repository that defines packages for the vanilla Linux kernel and the linux-firmware collection; we have to use that repo if we want all functionality.

Of course having the firmware be user-hackable would be better, and it would be better if the framework laptop used parts with free firmware. Something for a next revision, hopefully.

As an aside, I think the official Free Software Foundation position on firmware is bad praxis. To recall, the idea is that if a device has embedded software (firmware) that can be updated, but that software is in a form that users can’t modify, then the system as a whole is not free software. This is technically correct but doesn’t logically imply that the right strategy for advancing free software is to forbid firmware blobs; you have a number of potential policy choices and you have to look at their expected results to evaluate which one is most in line with your goals.

Bright lines are useful, of course; I just think that with respect to free software, drawing that line around firmware is not interesting. To illustrate this point, I believe the current FSF position is that if you can run e.g. a USB ethernet adapter without installing non-free firmware, then it is kosher, otherwise it is haram. However many of these devices have firmware; it’s just that you aren’t updating it. So for example the the USB Ethernet adapter I got with my Dell system many years ago has firmware, therefore it has bugs, but I have never updated that firmware because that’s not how we roll. Or, on my old laptop, I never updated the CPU microcode, despite spectre and meltdown and all the rest.

“Firmware, but never updated” reminds me of the wires around some New York neighborhoods that allow orthodox people to leave the house on Sabbath; useful if you are of a given community and enjoy the feeling of belonging, but I think even the faithful would see it as a hack. It is like how Richard Stallman wouldn’t use travel booking web sites because they had non-free JavaScript, but would happily call someone on the telephone to perform the booking for him, using those same sites. In that case, the net effect on the world of this particular bright line is negative: it does not advance free software in the least and only adds overhead. Privileging principle over praxis is generally a losing strategy.

Firstly I had to turn off secure boot in the bios settings; it’s in “security”.

I wasn’t expecting wifi to work out of the box, but for some reason the upstream Guix install media was not able to configure the network via the Ethernet expansion card nor an external USB-C ethernet adapter that I had; stuck at the DHCP phase. So my initial installation attempt failed.

Then I realized that the nonguix repository has installation media, which is the same as upstream but with the vanilla kernel and linux-firmware. So on another machine where I had Guix installed, I added the nonguix channel and built the installation media, via guix system image -t iso9660 nongnu/system/install.scm. That gave me a file that I could write to a USB stick.

Using that installation media, installing was a breeze.

However upon reboot, I found that I had no wifi and I was using software rendering; clearly, installation produced an OS config with the Guix kernel instead of upstream Linux. Happily, at this point the ethernet expansion card was able to work, so connect to wired ethernet, open /etc/config.scm, add the needed lines as described in the operating-system part of the nonguix README, reconfigure, and reboot. Building Linux takes a little less than an hour on this machine.

At that point you have wifi and graphics drivers. I use GNOME, and things seem to work. However the screen defaults to 200% resolution, which makes everything really big. Crisp, pretty, but big. Really you would like something in between? Or that the Framework ships a higher-resolution screen so that 200% would be a good scaling factor; this was the case with my old Dell XPS 13, and it worked well. Anyway with the Framework laptop, I wanted 150% scaling, and it seems these days that the way you have to do this is to use Wayland, which Guix does not yet enable by default.

So you go into config.scm again, and change where it says %desktop-services to be:

Then when you reboot you are in Wayland. Works fine, it seems. But then you have to go and enable an experimental mutter setting; install dconf-editor, run it, search for keys with “mutter” in the name, find the “experimental settings” key, tell it to not use the default setting, then click the box for “scale-monitor-framebuffer”.

Then! You can go into GNOME settings and get 125%, 150%, and so on. Great.

HOWEVER, and I hope this is a transient situation, there is a problem: in GNOME, applications that aren’t native Wayland apps don’t scale nicely. It’s like the app gets rendered to a texture at the original resolution, which then gets scaled up in a blurry way. There aren’t so many of these apps these days as most things have been ported to be Wayland-capable, Firefox included, but Emacs is one of them :( However however! If you install the emacs-pgtk package instead of emacs, it looks better. Not perfect, but good enough. So that’s where I am.

The laptop hangs on reboot due to this bug, but that seems a minor issue at this point. There is an ongoing tracker discussion on the community forum; like other problems in that thread, I hope that this one resolves itself upstream in Linux over time.

I didn’t mention the funniest thing about this laptop: it comes in pieces that you have to put together :) I am not so great with hardware, but I had no problem. The build quality seems pretty good; not a MacBook Air, but then it’s also user-repairable, which is a big strong point. It has these funny extension cards that slot into the chassis, which I have found to be quite amusing.

I haven’t had the machine for long enough but it seems to work fine up to now: suspend, good battery use, not noisy (unless it’s compiling on all 16 threads), graphics, wifi, ethernet, good compilation speed. (I should give compiling LLVM a go; that’s a useful workload.) I don’t have bluetooth or the fingerprint reader working yet; I give it 25% odds that I get around to this during the lifetime of this laptop :)

Until next time, happy hacking!

Good evening! Tonight I have a brief and unusual post, which is a product review of an electric cargo bike and its accessories for transporting kids. Let’s see if I can get this finished while I wait for my new laptop to finish installing.

So, I have three young kids (5yo, 3yo, 1yo), and I need to get them places. Before the 3rd was born I would use a bike trailer (Thule Chariot Lite single, bought when there was just one kid) and a bike seat (Thule RideAlong Lite, attached on seat-post). That was fine, though sometimes the thought of lugging their ever-increasing kilograms somewhere would give me pause. Then when the third kid arrived, hoo boy; I got a front-mount Thule Yepp Nexxt 2 Mini, to see if I could do three kids on one me-powered bike, but that was too tight to manage; not enough space to kick my leg over when getting on.

In the end we finally broke down and looked at electric cargo bikes. Of course I had looked at these over the years and always bounced off the price. Initially I had thought a front box-bike would be the thing, but then as kids grew up I realized they wouldn’t be comfortable there, and that a long-tail was probably better for the long term. But holy Christ, they are expensive. Happily, Decathlon came out with an electric longtail which is quite acceptable, and for about half the price of something equivalent from elsewhere.

Funny story: a friend got her bike stolen in the center of Geneva one day; thieves came and took all the bikes on a rack. I guess it was a battery-operated angle grinder; apparently that is the modus operandi these days. She moped a bit but then decided to buy the same bike again, from Decathlon as it happens. While she was at the store she entered a raffle. Then the cops called to say they found her bike – I know right?! Turns out some other bike that was stolen had an Apple AirTag on it, and its owner called the cops to tell them where the bike was, and all of the bikes were recovered. In the meantime my friend’s insurance had paid out for her stolen bike, so she had an extra bike. Then the local Decathlon called to tell her she won the raffle, for some kind of electric bike. When she went to pick it up, it was the electric longtail, for free. Anyway, we got to try hers before deciding to get one too.

One of my questions was, can you jam 3 kids on this thing? In terms of weight, yes: it will take 80 kilos on the back, and our kids total 45 kilos. In terms of space it’s OK, but really for the 1yo you need a bike seat, and even for the 3yo she should really be in a seat unless she’s very awake. The back rack has a frame around it, which does help keep kids on, but it’s not sufficient for a sleepy 3yo.

I was hoping to find a quite narrow kid bike seat so I could put on two seats for the young ones and then jam the oldest in somehow. I started with the Thule Yepp Nexxt 2 Maxi, but the release clamp kinda wants to be where the frame around the back rack is, so it’s not so efficient, and not easy to remove. Also the plastic guards so that kids don’t catch their legs in the back wheel aren’t needed on this particular bike, but they do prevent me from effectively accessing the otherwise well-designed panniers (c’est drôle mais ce ne sont pas des panniers, mais des saccoches).

So, with the Thule rear-mount seat I could get one bike seat for the 1yo and then jam in the 3yo and 5yo. It worked fine.

Then, annoyingly, thieves stole our electric longtail. Apparently insurance will pay out for us too—this is a relatively standard feature in France for the kind of insurance you have to have already for your place of residence—but for the last few weeks we have been without our longtail, and it is terrible. In the end we decided just to buy the same bike again: proof that it is good enough.

There are other electric longtails out there. If you can afford it, a pedal motor will be better than the hub motor on the Decathlon model. But if you are willing to accept less than the best, I think the Decathlon bike is quite good for what it is and I am looking forward to picking up the new bike tomorrow. It fits the kids, easily adjusts between different rider heights, and is a real joy to be on as a family. It lets me go places I wouldn’t think of going without the ability to just chuck everybody on the bike and zip away.

As far as bike seats go, I am going to try a new seat, to see if I can avoid the leg covers and to see if it’s more narrow. Ping me on the Mastodon if you want a follow-up. Thoughts welcome below for things that have worked for you. Until next time, happy cycling!

A minor bugfix release, fixes error: cannot find input file: `test/xmlsuite/Makefile.in'

See https://www.gnu.org/software/libredwg/ and https://git.savannah.gnu.org/cgit/libredwg.git/tree/NEWS?h=0.13.2

Here are the compressed sources:
http://ftp.gnu.org/gnu/libredwg/libredwg-0.13.2.tar.gz (20.1MB)
http://ftp.gnu.org/gnu/libredwg/libredwg-0.13.2.tar.xz (10.1MB)

Here are the GPG detached signatures[*]:
http://ftp.gnu.org/gnu/libredwg/libredwg-0.13.2.tar.gz.sig
http://ftp.gnu.org/gnu/libredwg/libredwg-0.13.2.tar.xz.sig

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

Here are more binaries:
https://github.com/LibreDWG/libredwg/releases/tag/0.13.2

Here are the SHA256 checksums:

7c517bc58267fb97ae063568969b16b248b74cb0bfe4a8232eec4f751d9468ff  libredwg-0.13.2.tar.gz
9ab76010a6536ebf86df50f4973cb6cb2fc8aa2677084b8d22ac8320052d9329  libredwg-0.13.2.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 libredwg-0.13.2.tar.gz.sig

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

gpg --recv-keys B4F63339E65D6414

and rerun the gpg --verify command.

Guix contributors and users got together in Brussels to explore Guix's status, chat about new ideas and spend some time together enjoying Belgian beer! Here's a recap of what was discussed.

The first day kicked off with an update on the project's health, given by Efraim Flashner representing the project's Maintainer collective. Efraim relayed that the project is doing well, with lots of exciting new features coming into the archive and new users taking part. It was really cool listening to all the new capabilities - thank-you to all our volunteer contributors who are making Guix better! Efraim noted that the introduction of Teams has improved collaboration - equally, that there's plenty of areas we can improve. For example, concern remains over the "bus factor" in key areas like infrastructure. There's also a desire to release more often as this provides an updated installer and lets us talk about new capabilities.

Christopher Baines gave a general talk about the QA infrastructure and the ongoing work to develop automated builds. Chris showed a diagram of the way the services interact which shows how complex it is. Increasing automation is very valuable for users and contributors, as it removes tedious and unpleasant drudgery!

Then, Julien Lepiller, representing the Guix Foundation, told us about the work it does. Julien also brought some great stickers! The Guix Foundation is a non-profit association that can receive donations, host activities and support the Guix project. Did you know that it's simple and easy to join? Anyone can do so by simply filling in the form and paying the 10 Euro membership fee. Contact the Guix Foundation if you'd like to know more.

The rest of the day was taken up with small groups discussing topics:

• Goblins, Hoot and Guix: Christine Lemmer-Webber gave an introduction to the Spritely Institute's mission to create decentralized networks and community infrastructure that respects user freedom and security. There was a lot of interesting discussion about how the network capabilities could be used in Guix, for example enabling distributed build infrastructure.

• Infrastructure: There was a working session on how the projects infrastructure works and can be improved. Christopher Baines has been putting lots of effort into the QA and build infrastructure.

• Guix Home: Gábor Boskovits coordinated a session on Guix Home. It was exciting to think about how Guix Home introduces the "Guix way" in a completely different way from packages. This could introduce a whole new audience to the project. There was interest in improving the overall experience so it can be used with other distributions (e.g. Fedora, Arch Linux, Debian and Ubuntu).

• Release management: Julien Lepiller led us through a discussion of release management, explaining the ways that all the parts fit together. The most important part that has to be done is testing the installation image which is a manual process.

The second day's sessions:

• Funding: A big group discussed funding for the project. Funding is important because it determines many aspects of what the group can achieve. Guix is a global project so there are pools of money in the United States and Europe (France). Andreas Enge and Julien Lepiller represented the group that handle finance, giving answers on the practical elements. Listening to their description of this difficult and involved work, I was struck how grateful we all are that they're willing to do it!

• Governance: Guix is a living project that continues to grow and evolve. The governance discussion concerned how the project continues to chart a clear direction, make good decisions and bring both current and new users on the journey. There was reflection on the need for accountability and quick decision making, without onerous bureaurcacy, while also acknowledging that everyone is a volunteer. There was a lot of interest in how groups can join together, perhaps using approaches like Sociocracy.

  Simon Tournier has been working on an RFC process, which the project will use to discuss major changes and make decisions. Further discussion is taking place on the development mailing-list if you'd like to take part.

• Alternative Architectures: The Guix team continues to work on alternative architectures. Efraim had his 32-bit PowerPC (Powerbook G4) with him, and there's continued work on PowerPC64, ARM64 and RISC-V 64. The big goal is a complete source bootscrap across all architectures.

• Hurd: Janneke Nieuwenhuizen led a discussion around GNU Hurd, which is a microkernel-based architecture. Activity has increased in the last couple of years, and there's support for SMP and 64-bit (x86) is work in progress. There's lots of ideas and excitement about getting Guix to work on Hurd.

• Guix CLI improvements: Jonathan coordinated a discussion about the state of the Guix CLI. A consistent, self-explaining and intuitive experience is important for our users. There are 39 top-level commands, that cover all the functionality from package management through to environment and system creation! Various improvements were discussed, such as making extensions available and improving documentation about the REPL work-flow.

Guix Days 2024 took place just before FOSDEM 2024. FOSDEM was a fantastic two days of interesting talks and conversations. If you'd like to watch the GUIX-related talks the videos are being put online:

• Making reproducible and publishable large-scale HPC experiments by Philippe Swartvagher.

• Scheme in the Browser with Guile Hoot and WebAssembly by Robin Templeton.

• RISC-V Bootstrapping in Guix and Live-Bootstrap by Ekaitz Zarraga.

• Self-hosting and autonomy using guix-forge by Arun Isaac.

• Spritely, Guile, Guix: a unified vision for user security by Christine Lemmer-Webber.

• Supporting architecture psABIs with GNU Guix by Efraim Flashner.

There's lots happening in Guix and many ways to get involved. We're a small and friendly project that values user freedom and a welcoming community. If this recap has inspired your interest, take a look at the raw notes and join us!

A minor bugfix release, but broken.
error: cannot find input file: `test/xmlsuite/Makefile.in'
You can safely patch the test/xmlsuite error away.

See https://www.gnu.org/software/libredwg/ and https://git.savannah.gnu.org/cgit/libredwg.git/tree/NEWS?h=0.13.1

Here are the compressed sources:
http://ftp.gnu.org/gnu/libredwg/libredwg-0.13.1.tar.gz (17.4MB)
http://ftp.gnu.org/gnu/libredwg/libredwg-0.13.1.tar.xz (9MB)

Here are the GPG detached signatures[*]:
http://ftp.gnu.org/gnu/libredwg/libredwg-0.13.1.tar.gz.sig
http://ftp.gnu.org/gnu/libredwg/libredwg-0.13.1.tar.xz.sig

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

Here are more binaries:
https://github.com/LibreDWG/libredwg/releases/tag/0.13.1

Here are the SHA256 checksums:

4f0a8920a0d500c5df02ea4cddad0665397642ed39852bc401580a253ac5b911  libredwg-0.13.1.tar.gz
33bca643ec730143d252f6ddd2bb1d69062416f3a94b05b9e90eb8ccdbe149a4  libredwg-0.13.1.tar.xz
34fa0603fc8a0c4d9550096420a807457a3be34f99042568f2264f426e922f9c  libredwg-0.13.1-win32.zip
89d67be07fd08a88adfe1870587ffa3fe8a121eebb915c92d01b7ab95bc4e572  libredwg-0.13.1-win64.zip

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:

gpg --verify libredwg-0.13.1.tar.gz.sig

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

gpg --recv-keys B4F63339E65D6414

and rerun the gpg --verify command.

GNU lightning is a library to aid in making portable programs
that compile assembly code at run time.

Development:
http://git.savannah.gnu.org/cgit/lightning.git

Download release:
ftp://ftp.gnu.org/gnu/lightning/lightning-2.2.3.tar.gz

  GNU Lightning 2.2.3 main new features:

• PowerPC port now optimize for a variable stack frame size and only create a stack frame if a non leaf function.
• New callee test to ensure register values saved on the stack are not corrupted when calling a jit or C function. While no problem was found in any port, the new test was added to make sure there were no failures.
• Add back the jit_hmul interface, from Lightning 1.x. There are special cases where it is desirable to only know the high part of a multiplication.
• Correct wrong implementation of zero right shift with two registers output.
• Add new pre and post increment for load and store instructions.
• Several minor bug fixes.

Can now also read and write all DWG formats pre-R13.
See https://www.gnu.org/software/libredwg/ and https://github.com/LibreDWG/libredwg/blob/0.13/NEWS
Now we'll finish work on encode support for r2004+.

Here are the compressed sources:
http://ftp.gnu.org/gnu/libredwg/libredwg-0.13.tar.gz (17.4MB)
http://ftp.gnu.org/gnu/libredwg/libredwg-0.13.tar.xz (9MB)

Here are the GPG detached signatures[*]:
http://ftp.gnu.org/gnu/libredwg/libredwg-0.13.tar.gz.sig
http://ftp.gnu.org/gnu/libredwg/libredwg-0.13.tar.xz.sig

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

Here are more binaries:
https://github.com/LibreDWG/libredwg/releases/tag/0.13

Here are the SHA256 checksums:

9682b0c5e6d91720666118059c67bf614e407a49b1a3c13312fe6a6c8f41d9cf  libredwg-0.13.tar.gz
dd906f59d71b26c13fd2420f50fc50bea666fd54acc764d8c344f7f89d5ab94e  libredwg-0.13.tar.xz
cc5df6456cdc7d0c9ebcd2eb798b81a80aab6b3a8f5417d4598262f3d2120886  libredwg-0.13-win32.zip
34774d2cd1c87f00a1d647f6c172ff92d02bab4ebe586badd883772fb746218b  libredwg-0.13-win64.zip


[*] Use a .sig file to verify that the coresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:

gpg --verify libredwg-0.13.tar.gz.sig

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

gpg --recv-keys B4F63339E65D6414

and rerun the gpg --verify command.

The 22st 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-02/msg00000.html