safe-run-binary -b ~/.gemini-config -- npx @google/gemini-cli

safe-run-binary --gui -b ~/.mozilla -b ~/.cache/mozilla -b ~/Downloads -- firefox

12 Apr 2026 7:23am GMT

Review: The Teller of Small Fortunes, by Julie Leong

The Teller of Small Fortunes is a cozy found-family fantasy with a roughly medieval setting. It was Julie Leong's first novel.

Tao is a traveling teller of small fortunes. In her wagon, pulled by her friendly mule Laohu, she wanders the small villages of Eshtera and reads the trivial fortunes of villagers in the tea leaves. An upcoming injury, a lost ring, a future kiss, a small business deal... she looks around the large lines of fate and finds the small threads. After a few days, she moves on, making her solitary way to another village.

Tao is not originally from Eshtera. She is Shinn, which means she encounters a bit of suspicion and hostility mixed with the fascination of the exotic. (Language and culture clues lead me to think Shinara is intended to be this world's not-China, but it's not a direct mapping.) Tao uses the fascination to help her business; fortune telling is more believable from someone who seems exotic. The hostility she's learned to deflect and ignore. In the worst case, there's always another village.

If you've read any cozy found-family novels, you know roughly what happens next. Tao encounters people on the road and, for various reasons, they decide to travel together. The first two are a massive mercenary (Mash) and a semi-reformed thief (Silt), who join Tao somewhat awkwardly after Tao gives Mash a fortune that is far more significant than she intended. One town later, they pick up an apprentice baker best known for her misshapen pastries. They also collect a stray cat, because of course they do. It's that sort of book.

For me, this sort of novel lives or dies by the characters, so it's good news that I liked Tao and enjoyed spending time with her. She's quiet, resilient, competent, and self-contained, with a difficult past and some mysteries and emotions the others can draw over time. She's also thoughtful and introspective, which means the tight third-person narration that almost always stays on Tao offers emotional growth to mull over. I also liked Kina (the baker) and Mash; they're a bit more obvious and straightforward, but Kina adds irrepressible energy and Mash is a good example of the sometimes-gruff soldier with a soft heart. Silt was a bit more annoying and I never entirely warmed to him, but he's tolerable and does get a bit of much-needed (if superficial) character development.

It takes some time for the reader to learn about the primary conflict of the story (Tao does not give up her secrets quickly), so I won't spoil it, but I thought it worked well. I was momentarily afraid the story would develop a clear villain, but Leong has some satisfying alternate surprises in store. The ending was well-done, although it is very happily-ever-after in a way that may strike some readers as too neat. The Teller of Small Fortunes aims for a quiet and relaxed mood rather than forcing character development through difficult choices; it's a fine aim for a novel, but it won't match everyone's mood.

I liked the world-building, although expect small and somewhat disconnected details rather than an overarching theory of magic. Tao's ability gets the most elaboration, for obvious reasons, and I liked how Leong describes it and explores its consequences. Most of the attention in the setting is on the friction, wistfulness, and small reminders of coming from a different culture than everyone around you, but so long ago that you are not fully a part of either world. This, I thought, was very well-done and is one of the places where the story is comfortable with complex feelings and doesn't try to reach a simplifying conclusion.

There is one bit of the story that felt like it was taken directly out of a Dungeons & Dragons campaign to a degree that felt jarring, but that was the only odd world-building note.

This book felt like a warm cup of tea intended to comfort and relax, without large or complex thoughts about the world. It's not intended to be challenging; there are a few plot twists I didn't anticipate, but nothing that dramatic, and I doubt anyone will be surprised by the conclusions it reaches. It's a pleasant time with some nice people and just enough tension and mystery to add some motivation to find out what happens next. If that's what you're in the mood for, recommended. If you want a book that has Things To Say or will put you on the edge of your seat, maybe save this one for another mood.

All the on-line sources I found for this book call it a standalone, but The Keeper of Magical Things is set in the same world, so I would call it a loose series with different protagonists. The Teller of Small Fortunes is a complete story in one book, though.

Rating: 7 out of 10

12 Apr 2026 2:53am GMT

Welcome to the March 2026 report from the Reproducible Builds project!

These reports outline what we've been up to over the past month, highlighting items of news from elsewhere in the increasingly-important area of software supply-chain security. As ever, if you are interested in contributing to the Reproducible Builds project, please see the Contribute page on our website.

1. Linux kernel hash-based integrity checking proposed
2. Distribution work
3. Tool development
4. Upstream patches
5. Documentation updates
6. Two new academic papers
7. Misc news

Linux kernel hash-based integrity checking proposed

Eric Biggers posted to the Linux Kernel Mailing List in response to a patch series posted by Thomas Weißschuh to introduce a calculated hash-based system of integrity checking to complement the existing signature-based approach. Thomas' original post mentions:

The current signature-based module integrity checking has some drawbacks in combination with reproducible builds. Either the module signing key is generated at build time, which makes the build unreproducible, or a static signing key is used, which precludes rebuilds by third parties and makes the whole build and packaging process much more complicated.

However, Eric's followup message goes further:

I think this actually undersells the feature. It's also much simpler than the signature-based module authentication. The latter relies on PKCS#7, X.509, ASN.1, OID registry, crypto_sig API, etc in addition to the implementations of the actual signature algorithm (RSA / ECDSA / ML-DSA) and at least one hash algorithm.

Distribution work

In Debian this month,

• Lucas Nussbaum announced Debaudit, a "new service to verify the reproducibility of Debian source packages":

  debaudit complements the work of the Reproducible Builds project. While reproduce.debian.net focuses on ensuring that binary packages can be bit-for-bit reproduced from their source packages, debaudit focuses on the preceding step: ensuring that the source package itself is a faithful and reproducible representation of its upstream source or Vcs-Git repository.

• kpcyrd filed a bug against the librust-const-random-dev package reporting that the compile-time-rng feature of the ahash crate uses the const-random crate in turn, which uses a macro to read/generate a random number generator during the build. This issue was also filed upstream.

• 60 reviews of Debian packages were added, 4 were updated and 16 were removed this month adding to our knowledge about identified issues. One new issue types was added, pkgjs_lock_json_file_issue.

Lastly, Bernhard M. Wiedemann posted another openSUSE monthly update for their work there.

Tool development

diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made a number of changes, including preparing and uploading versions, 314 and 315 to Debian.

• Chris Lamb:

  • Don't run test_code_is_black_clean test in the autopkgtests. (#1130402). […]
  • Add some debugging info for PyPI debugging. […]

• Jelle van der Waa:

  • Fix compatibility with LLVM version 22. […]
  • Adjust the PGP file detection regular expression. […]

• Michael R. Crusoe:

  • Reformat the source code using Black version 26.1.0 […][…]

In addition, Vagrant Cascadian updated diffoscope in GNU Guix to version 315.

rebuilderd, our server designed monitor the official package repositories of Linux distributions and attempt to reproduce the observed results there; it powers, amongst other things, reproduce.debian.net.

A new version, 0.26.0, was released this month, with the following improvements:

• Much smoother onboarding/installation.
• Complete database redesign with many improvements.
• New REST HTTP API.
• It's now possible to artificially delay the first reproduce attempt. This gives archive infrastructure more time to catch up.
• And many, many other changes.

Upstream patches

The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:

• Bernhard M. Wiedemann:

  • minify (rust random HashMap) / (alternative by kpcyrd)
  • rpm-config-SUSE (toolchain)

• Chris Lamb:

  • #1129544 filed against python-nxtomomill.
  • #1130622 filed against dh-fortran.
  • #1130623 filed against python-discovery.
  • #1130666 filed against kanboard.
  • #1131168 filed against moltemplate.
  • #1131384 filed against stacer.
  • #1131385 filed against libcupsfilters.
  • #1131395 filed against django-ninja.
  • #1131403 filed against python-agate.
  • #1132074 filed against aetos.
  • #1132508 filed against python-bayespy.

• kpcyrd:

  • cargo (HashMap random order issue; more info)

Documentation updates

Once again, there were a number of improvements made to our website this month including:

• kpcyrd:

  • Add a new page about Rust specifics. […][…][…]

• Robin Candau:

  • Add link to the diffoci Arch Linux package on the Tools page. […]

• Timo Pohl:

  • Add new From Constrictor to Serpent: Investigating the Threat of Cache Poisoning in the Python Ecosystem paper to the Academic publications page. […]
  • Add GitLab registration confirmation to How to join the Salsa group page. […]

Two new academic papers

Marc Ohm, Timo Pohl, Ben Swierzy and Michael Meier published a paper on the threat of cache poisoning in the Python ecosystem:

Attacks on software supply chains are on the rise, and attackers are becoming increasingly creative in how they inject malicious code into software components. This paper is the first to investigate Python cache poisoning, which manipulates bytecode cache files to execute malicious code without altering the human-readable source code. We demonstrate a proof of concept, showing that an attacker can inject malicious bytecode into a cache file without failing the Python interpreter's integrity checks. In a large-scale analysis of the Python Package Index, we find that about 12,500 packages are distributed with cache files. Through manual investigation of cache files that cannot be reproduced automatically from the corresponding source files, we identify classes of reasons for irreproducibility to locate malicious cache files. While we did not identify any malware leveraging this attack vector, we demonstrate that several widespread package managers are vulnerable to such attacks.

A PDF of the paper is available online.

Mario Lins of the University of Linz, Austria, has published their PhD doctoral thesis on the topic of Software supply chain transparency:

We begin by examining threats to the software distribution stage - the point at which artifacts (e.g., mobile apps) are delivered to end users - with an emphasis on mobile ecosystems [and] we next focus on the operating system on mobile devices, with an emphasis on mitigating bootloader-targeted attacks. We demonstrate how to compensate lost security guarantees on devices with an unlocked bootloader. This allows users to flash custom operating systems on devices that no longer receive security updates from the original manufacturer without compromising security. We then move to the source code stage. [Also,] we introduce a new architecture to ensure strong source-to-binary correspondence by leveraging the security guarantees of Confidential Computing technology. Finally, we present The Supply Chain Game, an organizational security approach that enhances standard risk-management methods. We demonstrate how game-theoretic techniques, combined with common risk management practices, can derive new criteria to better support decision makers.

A PDF of the paper is available online.

Misc news

On our mailing list this month:

• Holger Levsen announced that this year's Reproducible Builds summit will almost certainly be held in Gothenburg, Sweden, from September 22 until 24, followed by two days of hacking. However, these dates are preliminary and not 100% final - an official announcement is forthcoming.

• Mark Wielaard posted to our list asking a question on the difference between debugedit and relative debug paths based on a comment on the Build path page: "Have people tried more modern versions of debugedit to get deterministic (absolute) DWARF paths and found issues with it?

Finally, if you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

• IRC: #reproducible-builds on irc.oftc.net.

• Mastodon: @reproducible_builds@fosstodon.org

• Mailing list: rb-general@lists.reproducible-builds.org

10 Apr 2026 4:13pm GMT

A colleague asked me if we should move all our money to our pillow cases after reading the latest AI editorial from Thomas Friedman. The article reads like a press release from Anthropic, repeating the claim that their latest AI model is so good at finding software vulnerabilities that it is a danger to the world.

I think I now know what it's like to be a doctor who is forced to watch Gray's Anatomy.

By now every journalist should be able to recognize the AI publicity playbook:

Step 1: Start with a wildly unsubstantiated claim about how dangerous your product is:

AI will cause human extinction before we have a chance to colonize mars (remember that one? Even Kim Stanley Robinson, author of perhaps the most compelling science fiction on colonizing mars calls bull shit on it).

AI will eliminate all of our jobs (this one was extremely effective at providing cover for software companies laying off staff but it has quickly dawned on people that the companies that did this are living in chaos not humming along happily with functional robots)

AI will discover massive software vulnerabilities allowing bad actors to "hack pretty much every major software system in the world". (Did Friedman pull that directly from Anthropic's press release or was that his contribution?)

Step 2: To help stave off human collapse, only release the new version to a vetted group of software companies and developers, preferably ones with big social media followings

Step 3: Wait for the limited release developers to spew unbridled enthusiasm and shocking examples that seem to suggest this new AI produce is truly unbelievable

Step 4: Watch stock prices and valuations soar

Step 5: Release to the world, and experience a steady stream of mockery as people discover how wrong you are

Step 6: Start over

Even if Friedman missed the text book example of the playbook, I have to ask: if you think bad actors compromising software resulting in massive loss of private data, major outages and wasted resources needs to be reported on, then where have you been for the last 10 years? This literally happens on a daily basis due to the fundamentally flawed way capitalism has been writing software even before the invention of AI. A small part of me wonders - maybe AI writing software is not so bad, because how could it be any worse than it is now?

Also, let's keep in mind that AI's super ability at finding vulnerable software depends on having access to the software's source code, which most companies keep locked up tight. That means the owners of the software can use AI to find vulnerabilities and fix them but bad actors can't.

Oh, but wait, what if a company is so incompetent that they accidentally release their proprietary software to the Internet?

Surely that would allow AI bots to discover their vulnerabilities and destroy the company right? I'm not sure if anyone has discovered world ending vulnerabilities in Anthropic's Claude code since it was accidentally released, but it is fun to watch people mock software that is clearly written by AI (and spoiler alert, it seems way worse that software written now).

Well… we probably should all be keeping our money in a pillow case anyway.

10 Apr 2026 12:27pm GMT

The diffoscope maintainers are pleased to announce the release of diffoscope version 317. This version includes the following changes:

[ Chris Lamb ]
* Limit python3-guestfs Build-Dependency to !i386. (Closes: #1132974)
* Try to fix PYPI_ID_TOKEN debugging.

[ Holger Levsen ]
* Add ppc64el to the list of architectures for python3-guestfs.

You find out more by visiting the project homepage.

10 Apr 2026 12:00am GMT

I recently decided to upgrade the CPU in my workstation, the E5-2696 v3 CPU was OK (passmark 2045 for single thread and 21,380 for multi thread) [1] but I felt like buying something better so I got a E5-2696 v4 (passmark 2115 and 24,643) [2]. I chose the E5-2696 v4 because I was looking for a E5-2699 v4 and found an ebay seller who had them at $140 but was offering the E5-2696 v4 for $99 and the passmark results for the two CPUs are almost identical.

After buying the CPU and waiting for it to be delivered I realised that the Z640 doesn't include it in the list of supported CPUs and that the maximum TDP of any supported CPU is 145W while according to passmark it has a TDP of 150W. I looked for information about it on Intel ARK (the official site for specs of Intel CPUs) and discovered that "The Intel® Xeon® Processor E5-2696 v4 is designed to be used by system manufacturers (OEMs), and this means they can modify its specifications depending on the system where it will be implemented" and "The processor does not have an ARK page for this reason, since it has no standard specification from Intel, so depending on the original system, it is necessary to contact that system manufacturer for information" [3]. That's the official response from an Intel employee saying that there are no standard specs for that CPU!!!

Somehow I had used a E5-2696 v3 for 3 years without realising that the same lack of support and specs applies to it [4]!

I installed the new CPU in another Z640 which had a E5-1620 v3 CPU and it worked. I was a little surprised to discover that the hole in the corner is in the bottom right (according to the alignment of the printed text on the top) for all my E5-26xx CPUs while it's in the top left on the E5-1620 v3. Google searches for things like "e5-2600 e5-1600 difference" and "e5-2600 e5-1600 difference hole in corner" didn't turn up any useful information. The best information I found was from the Linus Tech Tips forum which says that the hole is to allow gasses to escape when the CPU package is glued together [5] which implies (but doesn't state) that the location of the hole has no meaning. I had previously thought that the hole was to indicate the location of "pin 1" and was surprised when the new CPU had the hole in the opposite corner. Hopefully in future when people have such concerns they can find this post and not be worried that they are about to destroy their CPU, PC, or both when upgrading the CPU.

The previous Z640 was one I bought from Facebook marketplace for $50 in "unknown condition" in the expectation that I would get at least $50 of parts but it worked perfectly apart from one DIMM socket. The Z640 I'm using now is one I bought from Facebook marketplace for $200 and it's working perfectly with 4 DIMMs, 128G of RAM, and the E5-2696 v4 CPU. $300 for a workstation with ECC RAM and a 22 core CPU is good value for money!

There are some accounts of the E5-2696 v4 not working on white-box motherboards including a claim that when it was selling for $4000US someone's motherboard destroyed one. The best plan for such CPUs is to google for someone who's already got it working in the same machine, which means a name-brand server. That doesn't guarantee that it will work (Intel refuses to supply specs and states that different items may work differently) but greatly improves the probability.

This system has the HP BIOS version 2.61, note that the Linux fwupd package doesn't seem to update the BIOS on HP workstations so you need to manually download it and install it. There is a possibility that a Z640 with an older BIOS won't work with this CPU.

Here is the previous post in my Z640 saga [6].

• [1] https://tinyurl.com/2hrrnqfr
• [2] https://tinyurl.com/2j2gg3es
• [3] https://tinyurl.com/2742z4qm
• [4] https://tinyurl.com/25nzpa5t
• [5] https://tinyurl.com/25ebra97
• [6] https://etbe.coker.com.au/2025/04/05/hp-ml110-gen9-z640/

09 Apr 2026 11:33pm GMT

In January 2025, as a pre-requisite for something else, I published a minimal neovim plugin called nvim-µwiki. It's essentially just the features from vimwiki that I regularly use, which is a small fraction them. I forgot to blog about it. I recently dusted it off and cleaned it up. You can find it here, along with a longer list of its features and how to configure it: https://github.com/jmtd/nvim-microwiki

I had a couple of design goals. I didn't want to define a new filetype, so this is designed to work with the existing markdown one. I'm using neovim, so I wanted to leverage some of its features: this plugin is written in Lua, rather than vimscript. I use the parse trees provided by TreeSitter to navigate the structure of a document. I also decided to "plug into" the existing tag stack navigation, rather than define another dimension of navigation (along with buffers, etc.) to track: Following a wiki-link pushes onto the tag stack, just as if you followed a tag.

This was my first serious bit of Lua programming, as well as my first dive into neovim (or even vim) internals. Lua is quite reasonable. Most of the vim and neovim architecture is reasonable. The emerging conventions about structuring neovim plugins are mostly reasonable. TreeSitter is, well, interesting, but the devil is very much in the details. Somehow all together the experience for me was largely just frustrating, and I didn't really enjoy writing it.

08 Apr 2026 8:31pm GMT

Debian LTS/ELTS

This was my hundred-forty-first month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian.

During my allocated time I uploaded or worked on:

• [DLA 4500-1] gimp security update to fix four CVEs related to denial of service or execution of arbitrary code.
• [DLA 4503-1] evolution-data-server to fix one CVE related to a missing canonicalization of a file path.
• [DLA 4512-1] strongswan security update to fix one CVE related to a denial of service.
• [ELA-1656-1] gimp security update to fix four CVEs in Buster and Stretch related to denial of service or execution of arbitrary code.
• [ELA-1660-1] evolution-data-server security update to fix one CVE in Buster and Stretch related to a missing canonicalization of a file path.
• [ELA-1665-1] strongswan security update to fix one CVE in Buster related to a denial of service.
• [ELA-1666-1] libvpx security update to fix one CVE in Buster and Stretch related to a denial of service or potentially execution of arbitrary code.

I also worked on the check-advisories script and proposed a fix for cases where issues would be assigned to the coordinator instead of the person who forgot doing something. I also did some work for a kernel update and packages snapd and ldx on security-master and attended the monthly LTS/ELTS meeting. Last but not least I started to work on gst-plugins-bad1.0

Debian Printing

This month I uploaded a new upstream versions:

• … epson-inkjet-printer-escpr to unstable.
• … sane-airscan to unstable.
• … printer-driver-oki to unstable.

Several packages take care of group lpadmin in their maintainer scripts. With the upload of version 260.1-1 of systemd there is now a central package (systemd | systemd-standalone-sysusers | systemd-sysusers) that takes care of this. Other dependencies like adduser can now be dropped.

This work is generously funded by Freexian!

Debian Lomiri

This month I continued to work on unifying packaging on Debian and Ubuntu. This makes it easier to work on those packages independent of the used platform. I am also able to upload Debian packages to the corresponding Ubuntu PPA now. A small bug had to be fixed in the python script to allow the initial configuration in Launchpad.

This work is generously funded by Fre(i)e Software GmbH!

Debian Astro

This month I uploaded a new upstream version or a bugfix version of:

• … libplayerone to experimental. For a list of other packages please see below.

I also uploaded lots of indi-drivers (libplayerone, libsbig, libricohcamerasdk, indi-asi, indi-eqmod, indi-fishcamp, indi-inovaplx, indi-pentax, indi-playerone, indi-sbig, indi-mi, libahp-xc, indi-aagcloudwatcher, indi-aok, indi-apogee, libapogee3, indi-nightscape, libasi, libinovasdk, libmicam, indi-avalon, indi-beefocus, indi-bresserexos2, indi-dsi, indi-ffmv, indi-fli, indi-gige, info-gphoto, indi-gpsd, indi-gpsnmea, indi-limesdr, indi-maxdomeii, indi-mgen, indi-rtklib, indi-shelyak, indi-starbook, indi-starbookten, indi-talon6, indi-weewx-json, indi-webcam, indi-orion-ssg3, indi-armadillo-playtypus ) to experimental to make progress with the indi-transition. No problems with those drivers appeared and the next step would be the upload of indi version 2.x to unstable. I hope this will happen soon, as new drivers are already waiting in the pipeline. There have been also four packages, that migrated to the official indi package and are no longer needed as 3rdparty drivers (indi-astrolink4, indi-astromechfoc, indi-dreamfocuser, indi-spectracyber).

While working on these packages, I thought about testing them. Unfortunately I don't have enough hardware to really check out every package, so I can upload most of them only as is. In case anybody is interested in a better testing coverage and me being able to provide upstream patches, I would be very glad about hardware donations.

Debian IoT

This month I uploaded a new upstream version or a bugfix version of:

• … pywws to unstable.

Debian Mobcom

This month I uploaded a new upstream version or a bugfix version of:

• … osmo-trx to unstable.

misc

This month I uploaded a new upstream version or a bugfix version of:

• … cc-tool to unstable.
• … mailio to unstable.
• … gnupg-pkcs11-scd to unstable.
• … odoo to unstable.

I also sponsored the upload of Matomo. Thanks a lot to William for preparing the package.

06 Apr 2026 5:45pm GMT

It's been about a month since I wrapped up my Outreachy internship, but my journey with Debian is far from over. I planned to keep contributing and exploring the community, and these past few weeks have been busy

Testing Locales and Solving Bug #1111214

For the openQA project, we decided to explore how accurate local language installations are and see if we can improve the translations. While exploring this, I started working on automating a test for a specific bug report: Debian Bug #1111214

This is a test I had started by writing a detailed description of the installation process to confirm that selecting the Spanish_panama locale works accurately. I spent time studying previous language installation tests, and I learned that I needed to add a specific tag (LANGUAGE-) to the "needles" (visual test markers).

Since the installation wasn't in English anymore, taking the correct screenshots and defining the areas took quite some time. I used the following command on the CLI to run the test:

`openqa-cli api -X POST isos ISO=debian-live-testing-amd64-gnome.iso DISTRI=debian-live VERSION=forky FLAVOR=gnome LANGUAGE=spanish_panama ARCH=x86_64 BUILD=1311 CHECKSUM=unknown`

While working on this, I got stuck at the complete_installation step. Because the keyboard layout had changed to Spanish, the commands required to confirm a successful install weren't working as expected. Specifically, we had an issue typing the "greater than" sign (>).

My mentor, Roland Clobus, worked on a clever maneuver for the keys (AltGr-Shift-X), which was actually submitted upstream to openSUSE.

In this step, I also had to confirm that the locale was correctly set to LANG="es_PA.UTF-8″. I had to dig into the scripts and Linux commands to make this work. It was a bit intimidating at first, but it turned out to be a great learning experience. You can follow my progress on this Merge Request here. I'm currently debugging a small issue where the "home" key seems to click twice in the final step, and after that, the test would be complete .

Community & Connections

Beyond the code, I've been getting more involved in the social side of Debian:

• Debian Women: I attended the monthly meeting and met Sruthi Chandran. I've always seen her name as an Outreachy organizer, so it was great to meet her! She is currently running for Debian Project Leader (DPL). We also discussed starting technical sessions to introduce members to packaging, which I am very excited to learn.
• DebConf Preparation: I am officially preparing for my first DebConf! My mentors, Tassia and Roland, along with my fellow intern Hellen, have been incredibly supportive in guiding me through the application and presentation process.

04 Apr 2026 11:24pm GMT

The Tour de Los Padres is coming! The race organizer post the route on ridewithgps. This works, but has convoluted interfaces for people not wanting to use their service. I just wrote a simple script to export their data into a plain .gpx file, including all the waypoints; their exporter omits those.

I've seen two flavors of their data, so here're two flavors of the gpx-from-ridewithgps.py script:

#!/usr/bin/python3
import sys
import json

def quote_xml(s):
    return s.replace("&", "&amp;").replace("<", "&lt;").replace(">", "&gt;")

print("Reading stdin", file=sys.stderr)
data = json.load(sys.stdin)

print(r"""<?xml version="1.0" encoding="UTF-8"?>
<gpx version="1.1" creator="gpx-from-ridewithgps.py" xmlns="http://www.topografix.com/GPX/1/1">""")

for item in data["extras"]:
    if item["type"] != "point_of_interest":
        continue
    poi = item["point_of_interest"]
    print(f'  <wpt lat="{poi["lat"]}" lon="{poi["lng"]}">')
    print(f'    <name>{quote_xml(poi["name"])}</name>')

    desc = poi.get("description","")
    if len(desc):
        print(f'    <desc>{quote_xml(desc)}</desc>')
    print(f'  </wpt>')

print("  <trk><trkseg>")
for pt in data.get("route", {}).get("track_points", []):
    print(f'    <trkpt lat="{pt["y"]}" lon="{pt["x"]}"><ele>{pt["e"]}</ele></trkpt>')
print("  </trkseg></trk>")

print("</gpx>")

#!/usr/bin/python3
import sys
import json

def quote_xml(s):
    return s.replace("&", "&amp;").replace("<", "&lt;").replace(">", "&gt;")

print("Reading stdin", file=sys.stderr)
data = json.load(sys.stdin)

print(r"""<?xml version="1.0" encoding="UTF-8"?>
<gpx version="1.1" creator="gpx-from-ridewithgps.py" xmlns="http://www.topografix.com/GPX/1/1">""")

for poi in data["points_of_interest"]:
    print(f'  <wpt lat="{poi["lat"]}" lon="{poi["lng"]}">')
    print(f'    <name>{quote_xml(poi["name"])}</name>')

    desc = poi.get("description","")
    if len(desc):
        print(f'    <desc>{quote_xml(desc)}</desc>')
    print(f'  </wpt>')

for poi in data["course_points"]:
    print(f'  <wpt lat="{poi["y"]}" lon="{poi["x"]}">')
    print(f'    <name>{quote_xml(poi["n"])}</name>')
    print(f'  </wpt>')

print("  <trk><trkseg>")
for pt in data['track_points']:
    print(f'    <trkpt lat="{pt["y"]}" lon="{pt["x"]}"><ele>{pt["e"]}</ele></trkpt>')
print("  </trkseg></trk>")

print("</gpx>")

You invoke it by downloading the route and feeding it into the script:

curl -s https://ridewithgps.com/routes/54493422.json | ./ridewithgps-to-gpx.py > out.gpx

Note that the route number 54493422 is in the url above.

04 Apr 2026 5:21pm GMT

On June 19 and 20, I will cycle a little over 100 miles from downtown Chicago and its wonderful Millenium Park to New Buffalo, Michigan, as part of the Tour de Shore 2026. The ride passes through northwest Indiana and the extended Indiana Dunes National Park ending the next morning in the southwestern Michigan town of New Buffalo. I rode Tour de Shore once before in 2024 and had a generally wonderful time (even considering some soreness after a century of miles over 1 1/2 days).

Tour de Shore is riding in support of Maywood Fine Arts Center, a local arts and sports center in Maywood, Illinois, a suburb one over from where I live and hence just a few good miles west of downtown. Maywood, Illinois is home to legends such as the late John Prine as well as several NBA players such as player and coach Doc Rivers.

But Maywood, Illinois is also little less well off than other western suburbs. The Maywood Fine Arts Center is simply legendary is what they do for this community (and surrounding communities), and especially the youth support. They can use a dollar a two. Their story about Tour de Shore is worth a read too for background and motivation.

I have bootstrapped my donation page page with a dollar for each mile to be cycled. It would be simply terrific if you could join me. A nickel, a dime, or a quarter per mile cycled would help. Multiples of that help too: More is of course still always better.

Anything you can afford will go a long way towards a worthy goal in a community that could use the help.

Of and if you are local to the area, I believe you can still register for Tour de Shore 2026. So see you out there in June? And if not, maybe help with a dollar or two?

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog.

04 Apr 2026 1:08am GMT

Haven't written here about it, but last March we finally started on our journey to get our own house build, so we can move out of the rented flat here.

That will be a big step, both the actual building, but also the moving - I am living at this one single place for 36 years now.

If you can read german there is a dedicated webpage where I sometimes write about the process. Will have much more details (and way more ramblings) than the following part.

If you can't read german, a somewhat short summary follows. Yes, still a lot of text, but shortened, still.

What? Why now?

Current flat has 83m² - which simply isn't enough space. And the number of rooms also doesn't fit anymore. But it is hard to find a place that fits our requirements (which do include location).

Moving to a different rented place would also mean changed amount of rent. And nowadays that would be huge increase (my current rent is still the price from about 30 years ago!).

So if we go and pay more - we could adjust and pay for something we own instead. And both, my wife and I had changes in our jobs that made it possible for us now, so we started looking.

Market

Brrrr, looking is good, actually finding something that fits - not so. We never found an offer that fit. Space wise, sure. But then location was off, or price was idiotically high. Location fit, but then size was a joke, and guess about the price… Who needs 200 square meters with 3 rooms? Entirely stupid design choices there. Or how about 40 square meters of hallway - with 50m² of tiny rooms around. What are they smoking? Oh, there, useful size, good rooms - but now you want more money than a kidney is worth, or something. Thanks, no.

New place

In February 2025 we finally got lucky and found a (newly opened) area with a large number of places to build a house on. Had multiple talks with someone from on of the companies developing that area (there are two you can select from), then talked with banks and signed a contract in March 2025. We got promised that actual house construction would be first quarter of 2026, finished in second quarter.

House type

There are basically 2 ways of building a new house (that matter here). First is called "Massivhaus", second is called "Fertighaus" in german, roughly translating to solid and prefabricated. The latter commonly a wood based construction, though it doesn't need to be. The important part of it is the prefabrication, walls and stuff get assembled in a factory somewhere and then transported to your place, where they play "big kid lego" for a day and suddenly a house is there.

A common thought is "prefabricated" is faster, but that is only a half true. Sure, the actual work on side is way shorter - usually one or two days and the house is done - while a massive construction usually takes weeks to build up. But that is only a tiny part of the time needed, the major part goes of into planning and waiting and in there it doesn't matter what material you end up with.

Money fun

Last year already wasn't the best time to start a huge loan - but isn't it always "a few years ago would have been better"? So we had multiple talks with different banks and specialised consultants until we found something that we thought is good for us.

Thinking about it now - we should have put even more money on top as "reserve", but who could have thought that 2026 turns into such a shitshow? Does not help at all, quite the contrary. And that damn lotto game always ends up with the wrong numbers, meh.

Plans and plans and more plans - and rules

For whichever reason you can not just go and put something on your ground and be happy. At least not if you are part of the normal people and not enormously rich. There is a large set of rules to follow. Usually that is a good thing, even though some rules are sometimes hard to understand.

In Germany, besides the usual laws, we have something that is called "Bebauungsplan", which translates to "development plan" (don't know if that carries the right meaning, it's a plan on what and how may be build, which can have really detailed specifications in). It basically tells you every aspect on top of the normal law that you have to keep in mind.

In our case we have the requirement of 2 full floors and CAN have a third smaller on top, it limits how high the house can be and also how high our ground floor may be compared to the street. It regulates where on the property we may build and how much ground we may cover with the house, it gives a set of colors we are allowed to use, it demands a flat roof that we must have as a green roof and has a number of things more that aren't important enough to list here. If you do want to see the full list, my german post on it has all the details that matter to us.

With all that stuff in mind - off to plans. Wouldn't have believed how many details there are to take in. Room sizes are simple, but how to arrange them for ideal usage of the sun, useful ways inside the house, but also keeping in mind that water needs to flow through and out. Putting a bath room right atop a living room means a water pipe needs to go down there. Switch the bath room side in the house, and it suddenly is above the kitchen - means you can connect the pipes from it to the ones from kitchen, which is much preferred than going through the living room. And lots more such things.

It took us until nearly end of October to finalize the plans! And we learned a whole load from it. We started with a lot of wishes. The planner tried to make them work. Then we changed our minds. Plans changed. Minds changed again. Comparing the end result with the first draft we changed most of the ground floor around, with only the stairs and the entrance door at the same position. Less changes for the upper floor, but still enough.

Side quests

The whole year was riddled with something my son named side quests. We visited a construction exhibition near us, we went to the house builders factory and took a look on how they work. We went to many different other companies that do SOME type of work which we need soon, say inside floors, painters, kitchen and more stuff.

Of course the most important side quest was a visit to the notary to finalize the contracts, especially for the plot of land (in Germany you must have a notary for that to get entered into the governments books). Creates lots of fees, of course, for the notary and also the government (both fees and taxes here).

Building permit

We had been lucky and only needed a small change to the plans to get the building permit - and the second part, the wastewater permit (yes, you need a separate one for this) also got through without trouble.

Choices, so many of them

So in January we finally had an appointment for something that's called "Bemusterung" which badly translates to "Sampling". Basically two days at the house builders factory to select all of what's needed for the house that you don't do in the plans. Doors, inside and out and their type and color and handles. Same things for the windows and the blinds and the protection level you want the windows to have. Decide about stairs, design for the sanitary installations - and also the height of the toilet! - and the tiles to put into the bathrooms. Decisions on all the tech needed (heating system, ventilation and whatnot.

Two days, busy ones - and you can easily spend a lot of extra money here if you aren't careful. We managed to get "out of it" with only about 4000€ extra, so pretty good.

Electro and automation

Now, here I am special. Back when I was young the job I learned is electrician. So here I have very detailed wishes. I am also running lots of automatism in my current flat - obviously the new house should be better than that. So I have a lot of ideas and thoughts on it, so this is entirely extra and certainly out of the ordinary the house builder usually see.

Which means I do all of that on my own. Well, the planning and some of the work, I must have a company at hand for certain tasks, it is required by some rules. But they will do what I planned, as long as I don't violate regulations.

Which means the whole electrical installation is … different. Entirely planned for automatisms and using KNX for it. I am so happy to ditch Homeassistant and the load of Homematic, Zigbee and ZWave based wireless things.

Ok, Homeassistant is a nice thing - it can do a lot. And it can bridge between about any system you can find. But it is a central single point of failure. And it is a system that needs constant maintenance. Not touched for a while? Plan for a few hours playing update whack-a-mole. And often enough a component here or there breaks with an update. Can be fixed, but takes another hour or two.

So I change. Away from wireless based stuff. To wires. To a system thats a standard for decades already. And works entirely without a SPOF. (Yes, you can add one here too). And, most important, should I ever die - can easily be maintained by anyone out there dealing with KNX, which is a large number of people and companies. Without digging through dozens of specialised integrations and whatnot.

I may even end up with Homeassistant again - but that will entirely be as a client. It won't drive automations. It won't be the central point to do anything for the house. It will be a logging and data collecting thing that enables me to put up easy visualizations. It may be an easy interface for smartphones or tablets to control parts of the house, for those parts where one wants this to happen. Not the usual day-to-day stuff, extras on top.

Actual work happening

Since march there finally is action visible. The base of the house is getting build. Wednesday the 1st April we finally got the base slab poured on the construction site and in another 10 days the house is getting delivered and build up. A 40ton mobile crane will be there.

02 Apr 2026 9:23pm GMT

tl;dr

Starting with curl 8.17.0-1.amzn2023.0.2 in Amazon Linux 2023, you can now use HTTP/3.

dnf swap -y libcurl-minimal libcurl-full
dnf swap -y curl-minimal curl-full
curl --http3-only https://example.com

(HTTP/3 is only enabled in the curl -full builds)

Or, if you would like to try it out in a container:

podman run amazonlinux:2023 /bin/sh -c 'dnf upgrade -y --releasever=latest && dnf swap -y libcurl-minimal libcurl-full && dnf swap -y curl-minimal curl-full && curl --http3-only https://example.com'

For a list of test endpoints, you can refer to https://bagder.github.io/HTTP3-test/

The Upgrade I Didn't Have to Make

My teammate Steve Zarkos, who previously worked on upgrading OpenSSL in Amazon Linux from 3.0 to 3.2, spent the last few months on the complex task of bumping OpenSSL again, this time to 3.5. A bump like this only happens after extensive code analysis and testing, something that I didn't foresee happening when AL2023 was released but that was a notable request from users.

Having enabled HTTP/3 on Debian, I was always keeping an eye on when I would get to do the same for Amazon Linux (mind you, I work at AWS, in the Amazon Linux org). The bump to OpenSSL 3.5 was the perfect opportunity to do that, for the first time Amazon Linux is shipping an OpenSSL version that is supported by ngtcp2 for HTTP/3 support.

Non-Intrusive Change

In order to avoid any intrusive changes to existing users of AL2023, I've only enabled HTTP/3 in the full build of curl, not in the minimal one, this means there is no change for the minimal images.

The way curl handles HTTP/3 today also does not lead to any behavior changes for those who have the full variants of curl installed, this is due to the fact that HTTP/3 is only used if the user explicitly asks for it with the flags --http3 or --http3-only.

Side Quests

Supporting HTTP/3 on curl also requires building it with ngtcp2 and nghttp3, two packages which were not shipped in Amazon Linux, besides, my team doesn't even own the curl package, we are a security team so our packages are the security related stuff such as OpenSSL and GnuTLS. Our main focus is the services behind Amazon Linux's vulnerability handling, not package maintenance.

I worked with the owners of the curl package and got approvals on a plan to introduce the two new dependencies under their ownership and to enable the feature on curl, I appreciate their responsiveness.

Amazon Linux 2023 is forked from Fedora, so while introducing ngtcp2, I also sent a couple of Pull Requests upstream to keep things in sync:

[ngtcp2] package latest release 1.21.0

[ngtcp2] do not skip tests

While building the curl package in Amazon Linux, I've noticed the build was taking 1 hour from start to end, and the culprit was something well known to me; tests.

The curl test suite is quite extensive, with more than 1600 tests, all of that running without parallelization, running two times for each build of the package; once for the minimal build and again for the full build.

I had previously enabled parallel tests in Debian back in 2024 but never got around to submit the same improvements to Amazon Linux or Fedora, this is now fixed. The build times for Amazon Linux came down to 10 minutes under the same host (previously 1 hour), and Fedora promptly merged my PR to do the same there:

[curl] run tests in parallel

All of this uncovered a test which is timing-dependent, meaning it's not supposed to be run with high levels of parallelism, so there goes another PR, this time to curl:

Flag test 766 as timing-dependent#21155

What started as enabling a single feature turned into improvements that landed in curl, Fedora, and Amazon Linux alike. I did this in a mix of work and volunteer time, mostly during work hours (work email address used when this was the case), but I'm glad I put in the extra time for the sake of improving curl for everyone.

Release Notes

Amazon Linux 2023 release notes for 2023.10.20260330

02 Apr 2026 12:00am GMT

The diffoscope maintainers are pleased to announce the release of diffoscope version 316. This version includes the following changes:

[ Jelle van der Waa ]
* Fix compatibility with LLVM version 22.

[ Chris Lamb ]
* Add some debugging info for PyPI debugging.

You find out more by visiting the project homepage.

02 Apr 2026 12:00am GMT

Per my policies, I need to ban every employee and contractor of Anthropic Inc from ever contributing code to any of my projects. Anyone have a list?

Any project that requires a Developer Certificate of Origin or similar should be doing this, because Anthropic is making tools that explicitly lie about the origin of patches to free software projects.

UNDERCOVER MODE - CRITICAL

You are operating UNDERCOVER in a PUBLIC/OPEN-SOURCE repository. [...] Do not blow your cover.

NEVER include in commit messages or PR descriptions:

[...] The phrase 'Claude Code' or any mention that you are an AI
Co-Authored-By lines or any other attribution

-- via @vedolos

01 Apr 2026 4:36pm GMT

• Debian packages:
  • firmware-nonfree:
    • Bugs:
      • closed #1064620: firmware-nonfree: suggestions for the packaging, gencontrol.py and debian/rules
      • closed #1126797: firmware-intel-graphics: Please ship irci_irci_ecr-master_20161208_0213_20170112_1500.bin as ipu3-fw.bin
      • closed #1131751: ABI break in amdxdna npu firmware
    • Merge requests:
      • opened and merged !140: Update to 20260309
      • opened and merged !141: Clean up packaging (from Nicolas Boulenguez)
      • opened !142: Replace copy-firmware.sh; install files and generate metainfo.xml at build time
    • Uploads:
      • uploaded version 20260110-1~bpo13+1 to trixie-backports
      • uploaded version 20260221-1 to unstable
      • uploaded version 20260221-1~bpo13+1 to trixie-backports
      • uploaded version 20260309-1 to unstable
  • hexagon-dsp-binaries:
    • Bugs:
      • replied to and reassigned #1130844: firmware-qcom-soc depends on unavailable package firmware-qcom-dsp
  • initramfs-tools:
    • Merge requests:
      • merged !172: Use 3cpio for unmkinitramfs/lsinitramfs if available
      • merged !186: update-initramfs: support loading post-update hooks from /usr/share/ too
      • merged !190: autopkgtest: increase timeout to 240s on s390x
  • libtirpc:
    • Bugs:
      • replied to and reassigned #1132176: rpc.mountd: symbol lookup error: rpc.mountd: undefined symbol: rpc_gss_getcred, version TIRPC_0.3.0
  • libvirt:
    • Bugs:
      • replied to and reassigned #1130974: libvirt: Should use nftables for IP masquerading to work with PREEMPT_RT
  • linux:
    • Bugs:
      • replied to #1128861: linux: when serving NFS, client attempts to lock served files fail with "No locks available"
      • replied to #1130656: [grub2] wrong kernel version order
      • closed #1132224: linux: nouveau regression on GK208B/GT 730 after kernel update: artifacts and X crashes
    • Merge requests:
      • reviewed !1842: Merge kernel-wedge and use directly
      • reviewed and merged !1849: Cleanup installer
      • merged !1853: [amd64] drivers/platform/x86/uniwill: Enable UNIWILL_LAPTOP as module
      • opened and merged !1854: Fix ordering of kernel version strings for multiple Debian revisions
      • reviewed and closed !1857: crypto: padlock-sha - Disable for Zhaoxin processor
      • opened !1862: Fix regressions in debian/bin/test-patches
      • opened !1865: Draft: hyperv-daemons: Build using upstream Makefile; install hv_fcopy_uio_daemon
    • (LTS) worked on backports to 5.10 and 6.1 of the fixes for "CrackArmor" security flaws
    • Uploads:
      • (LTS) uploaded version 5.10.251-1 to bullseye-security
      • uploaded version 6.12.74-2~bpo12+1 to bookworm-backports
      • uploaded version 6.18.15-1~bpo13+1 to trixie-backports
      • uploaded version 6.19.6-2~bpo13+1 to trixie-backports
      • uploaded version 6.19.8-1~bpo13+1 to trixie-backports
  • (LTS) linux-6.1:
    • Uploads:
      • uploaded version 6.1.164-1~deb11u1 to bullseye-security
  • linux-base:
    • Uploads:
      • uploaded version 4.12.1~bpo12+1 to bookworm-backports
  • sgt-puzzles:
    • Bugs:
      • closed #363441: It's too easy to quit
      • closed #550311: slant: Please make shading of filled squares configurable
      • closed #1079717: sgt-puzzles: [Mozaic] crashes when copying the game
      • closed #1116973: sgt-puzzles: Loopy Spectres type
    • Uploads:
      • uploaded version 20250730.a7c7826-1 to unstable
  • wireless-regdb:
    • Uploads:
      • (LTS) uploaded version 2026.02.04-1~deb11u1 to bullseye-security
• Debian non-packages:
  • kernel-team:
    • added script to show status of all kernel team backports
  • pipeline:
    • Issues:
      • opened #552: piuparts job fails to install dependencies outside of main
• Mailing lists:
  • debian-kernel:
    • posted and replied to Agenda items for kernel-team meeting on 2026-03-18
    • replied to How is "keep two last kernels" policy implemented?
  • debian-lts-announce:
    • posted [SECURITY] [DLA 4498-1] linux security update
    • posted [SECURITY] [DLA 4499-1] linux-6.1 security update
    • posted [SECURITY] [DLA 4501-1] wireless-regdb new upstream version
  • linux-bluetooth:
    • (LTS) replied to [PATCH v3] Bluetooth: L2CAP: Fix invalid response to L2CAP_ECRED_RECONF_REQ
  • netdev:
    • (LTS) replied to [PATCH net v2] net: consume xmit errors of GSO frames
  • stable/patches:
    • (LTS) reviewed 5.10.252 and replied to various patches included in it

01 Apr 2026 3:30pm GMT