Debian Disguised Work

RcppMsgPack 0.2.5 on CRAN: Minor Maintenance

2026-08-19T20:07:00+00:00

Another maintenance release of RcppMsgPack got onto CRAN today. MessagePack itself is an efficient binary serialization format. It lets you exchange data among multiple languages like JSON. But it is faster and smaller. Small integers are encoded into a single byte, and typical short strings require only one extra byte in addition to the strings themselves. RcppMsgPack brings both the C++ headers of MessagePack as well as clever code (in both R and C++) Travers wrote to access MsgPack-encoded objects directly from R.

This release is once again chiefly maintenance. Besides standard upkeep to the README.md and continuous integration setup we had to add one #include. The clang++-23 compiler, when also running with its own library, now now needs the type_traits.h header file (in the upstream MessagePack code) so we added that. No other changes, so no user-facing changes. Details follow from the NEWS file.

Changes in version 0.2.5 (2026-08-19)

Explicitly include header "type_traits.h" to appease clang++-23

Standard maintenance updating continuous integration, adding minor helper script, and updating README.md

Courtesy of my CRANberries, there is also a diffstat report for this release. For questions, suggestions, or issues please use the issue tracker at the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub.

The people vs the AI overlords

2026-08-19T14:29:31+00:00

Previously in this series: The Four Horsemen of the LLM Apocalypse.

In a post to oss-security, my (Debian) co-developer Russ Allbery stated that "open source software [OSS] is coming face to face with a motivation crisis that has been building for a long time". His point is essentially that large language models (LLMs¹) are making the existing OSS community crisis worse. For him, it's the flood of code reviews, but he argues that varies according to people's desires, for others it's security issues and so on.

I think Russ is right, but I would argue there's something much bigger than our open communities going on here, and it's about the entire field of computing. This pressure is on all of us, regardless of whether we work on open source software or not.

How people use models

People using LLMs in their workflow have radically changed how programming works, even for people who claim to avoid vibe-coding. And I'm sorry to single out one poor maintainer here: it's not you, Brian, you're just one example among many. But this is typical use of those models nowadays:

Once it’s done, I’ll use /code-review and let Claude spawn sub-agents to do a full review of the new code. This usually finds some problems, even problems that the “main” Claude instance didn’t find during its validation. I usually keep running /code-review again and again after finding and fixing issues, until there aren’t any left.

Think about what that means for a minute. This is automation built to fire up dozens of agents crunching at a problem for minutes if not hours of GPU compute time, in parallel. This is essentially a couple of shelves in a datacenter rack, totally maxed out on power and cooling, abstracted behind a cute little /code-review command.

The author, here, is rightly concerned that "Anthropic could pull the rug out and require API pricing", which is perhaps a code word for "charging something closer to actual costs". Brian also pays lip service to environmental and societal costs but those are largely abstracted away, so let's keep that conversation aside here as well, as we have discussed it before anyways.

But clearly, this way of working has an (externalized) cost, to say the least.

Paying for non-free tools

For decades my work has been focused on free and open source software. I've long stopped using proprietary operating systems like Windows or Mac, and even before that switch, I was mostly using free software on those platforms, partly out of principle, but also because I was too poor. So the tools of my trade are free, and I build free tools with them.

It feels like we're going backwards: when I was in school, a millennia ago, my classmates didn't have access to a compiler and were wondering how they would scrape the money to buy a compiler like Borland's or Microsoft's. I had a compiler built into my operating system (FreeBSD at the time), so that wasn't a problem for me. For them, it was a significant expense, but at least those expenses (or more shady sourcing of programs) were a one-shot deal.

Fast forward 30 years, and software is rented: you pay monthly for Adobe's Photoshop and Microsoft's office suite just like you pay for Netflix, Disney+ or Spotify². And now you need to add dozens (if not hundreds of dollars) of monthly credits to access LLMs on top of that.

So, now we have to pay to get anything done? This is peak enshitification of our job: first they steal our work to train their models, and then they sell it back to us at a profit.

Attacking the engineers

AI is coming for our jobs, as engineers, if not everyone, according to the narrative. For a while now, our job market has deteriorated: less jobs, for less pay. Lots of skilled engineers looking for work and finding crap jobs then still looking while working.

This is not by accident.³ We engineers have a lot of power, it is not organized, but that's just a couple of unions away (easy!). Tech overlords know this, so they are attacking our profession, directly, by forcing us to train and use models that they can control.

Even in environments where programmers are not forced to use LLMs, the mere pressure of other people's LLM-generated work is huge. One can be forced to review LLM outputs, or just peer pressured you into producing more.

We're now supposed to accelerate delivery, because models can presumably do things so much better and faster. With supply chain security becoming such a large vector that we now have worms crawling around developers accounts on NPM, increasing the delivery cadence seems like a really bad idea.⁴

The LLM hype is part of the larger wave of cyberwar against workers, against water, against the Earth, against all the people. This is not a matter of individually "adapting to the reality" or personal choice, but a political, social, hard problem we need to address collectively.

Previously in this series: The Four Horsemen of the LLM Apocalypse.

I again prefer the term LLM to "AI" because models do not possess intelligence. I did use it in the title because click baiting is apparently important, but I stopped short of calling this one "Rage Against the Machines" because that would be the title of every blog post I have ever made.↩
Yes, I know that Visual Studio is kind of free now, but I wouldn't be surprised if they turn that into a rental as well, because why not.↩
Beyond sabotaging the job market, Sam Altman event wants to sell "intelligence as a utility" something that is just a really bad idea but especially shows how megalomaniac those people are.↩
This brings back memories of another era, walking us back decades in terms of computer security.↩

The Four Horsemen of the LLM Apocalypse

2026-08-19T14:14:42+00:00

Next in this series: The people vs the AI overlords.

I have been battling Large Language Models (LLM¹) for the past couple of weeks and have struggled to think about what it means and how to deal with its fallout.

Because the fight has come from many fronts, I've come to articulate this in terms of the Four Horsemen of the Apocalypse.

Sound track: Metallica's The Four Horsemen, preferably downloaded from Napster around 2000, but now I guess you get it on YouTube.

War: bot armies

Let's start with War. We've been battling bot armies for control of our GitLab server for a while. Bots crawl virtually infinite endpoints on our Git repositories (as opposed to downloading an archive or shallow clone), including our fork of Firefox, Tor Browser, a massive repository.

At first, we've tried various methods: robots.txt, blocking user agents, and finally blocking entire networks. I wrote asncounter. It worked for a while.

But now, blocking entire networks doesn't work: they come back some other way, typically through shady proxy networks, which is kind of ironic considering we're essentially running the largest proxy network of the world.

Out of desperation, we've forced users to use cookies when visiting our site. We haven't deployed Anubis yet, as we worry that bots have broken Anubis anyways and that it does not really defend against a well-funded attacker, something which Pretix warned against in 2025 already.

(We have a whole discussion regarding those tools here.)

But even that, predictably, has failed. I suspect what we consider bots are now really agents. They run full web browsers, JavaScript included, so a feeble cookie is no match for the massive bot armies.

Side note on LLM "order of battle"

We often underestimate the size of that army. The cloud was huge even before LLMs, serving about two thirds of the web. Even larger swaths of clients like government and corporate databases have all moved to the cloud, in shared, but private infrastructure with massive spare capacity that is readily available to anyone who pays.

LLMs have made the problem worse by dramatically expanding the capacity of the "cloud". We now have data centers that defy imagination with millions of cores, petabytes of memory, exabytes of storage.

I thought that 25 gigabit residential internet in Switzerland could bring balance, but this is nothing compared to the scale of those data centers.

Those companies can launch thousands, if not millions of fully functional web browsers at our servers. Computing power or bandwidth are not a limitation for them, our primitive infrastructure is. No one but hyperscalers can deal with this kind of load, and I suspect that they are also struggling, as even Google is deploying extreme mechanisms in reCAPTCHA.

This is the largest attack on the internet since the Morris worm but while Robert Tappan Morris went to jail on a felony, LLM companies are celebrated as innovators and will soon be too big to fail.²

Which brings us to the second horsemen, famine.

Famine: shortages

All that computing power doesn't come out of thin air: it needs massive amounts of hardware, power, and cooling.

Earlier this year, I've heard from a colleague that their Dell supplier refused to even provide a quote before August. Dell!

In February, Western Digital's hard drive production for 2026 was already sold out. Hard drives essentially doubled in price within a year, and some have now tripled. A server quote we had in November has now quadrupled, going from 10 thousand to FORTY thousand dollars for a single server.

But regular folks are facing real-life shortages as well, as city-size data centers are being built at neck-breaking speed, stealing fresh water and energy from human beings to feed the war machine.

We've been scared of losing our jobs, but it seems that Apocalypse has yet to fully materialize. Regardless for engineers, the market feels tighter than it was a couple years ago, and everyone feels on edge that they will just have to learn to operate LLMs to keep their jobs.

Update: it turns out I was clearly too optimistic. Cisco is laying off 4,000 or 5% of its staff in a jolly announcement celebrating a record $15.8 billion revenue, and Meta will lay off 8,000 or 10% of its workforce, in horrifying conditions. See also the jobloss.ai tracker which counts 125,000 jobs lost since January 2025, as of May 2026.

Which brings us, of course, to Death.

Death: security and copyright

Our third horseman is one I did not expect a couple of months ago. Back at FOSDEM, curl's maintainer Daniel Stenberg famously complained about the poor quality of LLM-generated reports but then, a few months later, everyone is scrambling to deal with floods of good reports.

In the past two weeks, this culminated in a significant number of critical security issues across multiple projects. Chained together, remote code execution vulnerabilities in Nginx and Apache and two local privilege escalations in the Linux kernel (dirtyfrag and fragnesia) essentially gave anyone root access to any unpatched server to the web.

As I write this, another vulnerability dropped, which gives read access to any file to a local user, compromising TLS and SSH private keys.

All those vulnerabilities were released without any significant coordination while people scrambled to mitigate.

Many people including Linus Torvalds are now considering issues discovered through LLMs to be essentially public. This puts some debates about disclosure processes in perspective, to say the least.

But this is not merely the death of the traditional coordinated disclosure process, the C programming language, or the Linux kernel: remember that those bots are trained on a large corpus of copyrighted material. Facebook has trained their models on pirated books and Nvidia has done deals with Anna's Archive to secure access to large swaths of copyrighted material. The US Congress seems to think LLM outputs are not copyrightable, like any other machine outputs.

With many people now vibe coding their way out of learning or remembering how computers work, is this the Death of Copyright?

And that, of course, brings us to the final horseman: Pestilence.

Pestilence: slop

There is a growing meme that programming is essentially over as we know it. That you can simply vibe-code applications from scratch and it's pretty good.

Maybe that's true.

So far, most of my attempts at resolving any complex problem with a LLM have often failed with bizarre failures. Some worked surprisingly well. Maybe, of course, I am holding it wrong.

I personally don't believe LLMs will ever be good enough to produce and maintain software at scale. They're surprisingly good at finding security flaws right now. But what I see is also a lot of Bullshit, with a capital B. It's not lying: it does not "know" anything, so it can't lie. It's misleadingly cohesive and deliberate, but it lacks meaning, intent, will.

I have not been confronted with much slop, apart from the lobster Jesus or the yellow man atrocities, and particularly not in my work. But I see what it is doing to my profession: beyond vibe-coding, people are now token-maxxing, and land-grabbing their colleagues.

I don't like what LLMs do to our communities, or the fabric of software we live with.

Software does not evolve in a void. It is a team effort, be it free software or a corporate product. Generations of humans have carefully built the scaffolding of technology required for modern networks and software to operate, in a convoluted contraption that no single human fully understands anymore.

The idea of simply giving up on that understanding entirely and delegating it to an unproven model is not only chilling, it feels just plain stupid. Not stupid as in Skynet, stupid as in "I can't get inside the data center because the authentication system is down". Except we're in a "the power plant doesn't reboot" or "their LLM found an 0day in our slop" kind of stupid.

The fifth horsemen

Researching for this article, I looked up the four horsemen and found out they original seems to have been:

Famine
War
Death
Conquest (??)

I was surprised. I grew up thinking about the horsemen being Famine, War, Pestilence, and Death. So I went back to my original source which actually claims the horsemen are:

Time has taken its toll on you, the lines that crack your face.
Famine, your body, it has torn through, withered in every place.
Pestilence for what you've had to endure, and what you have put others through
Death, deliverance for you, for sure, now there's nothing you can do

So I guess that makes no sense either, which, fair enough, I shouldn't rely on Metallica for theological references. Especially since that song was originally called Mechanix and was "about having sex at a gas station".

Anyways.

The point is, there are actually five horsemen, and the fifth one is, in my opinion, Conquest.

Those companies (and not "AI", mind you) are taking over the world. I sense a strong connection with the "post-truth" world imposed on us by fascists like Trump and Putin. It's not an accident, it's a power grab part of the Californian Ideology³. Just like Airbnb broke housing, Uber destroyed the transportation and Amazon is taking over retail and server hosting, LLM companies are essentially trying to take over if not everything, at least Cognition as a whole.

But the capitalization of those companies (OpenAI and Nvidia in particular) are so far beyond reason that their inevitable collapse will likely lead to a global financial collapse of biblical proportions.

Because they will inevitably fail like previous bubbles they are built on. And when they fail, I hope it zips all the way back through the blockchain scam, the ad surveillance system, and the dot com then git me back my internet.

The Tower of Babel

While I'm off in the woods hallucinating (ha!) on biblical allegories, I feel there's another sign that the apocalypse is coming.

The Tower of Babel myth says that humans tried to create a big tower up to heaven and become god. God confounds their speech and scatters the human race. End of utopia.

This is what is happening to our human translators now. LLMs being, after all, Language Models, they are excellent at translation work. So much that the only translators not replaced by LLMs right now are interpreters, who translate vocally in real time. But interpreters are worried about their jobs as well.

This concretely means we will lose the human capacity, as a civilization, to translate between each other. It is still an open question whether the remaining revision work will be enough for translators to avoid deskilling, but other research has shown that LLM use leads to cognitive decline, impacts critical thinking, and generally, that deskilling is a common outcome.

Ultimately, I think this is where LLMs bring us. Towards collapse.

So this is a call to arms. Fight back!

Poison bots. Build local real-world communities.

Go low tech. Moore's law is dead, make use of it.

Patch your shit. Go weird.

Refuse slop. Train your brain. Refuse distillation.

The horsemen will collapse, but let's not go down with them.

Butlerian Jihad!

This article was written without the use of a large language model and should not be used to train one.

Next in this series: The people vs the AI overlords.

Updates

A paragraph was added about the job apocalypse, which was of course under-estimate.
Why Timnit Gebru was fired is extremely important and interesting. The co-lead of the Ethical AI team at Google was fired because they blew the whistle on "stochastic parrots" essentially destroying the world as we know it:

The fifth warning was the one Google cared about most. [...]

The internet would become a place where the dominant voice was a statistical average of dominant voices, presented as a neutral assistant.

The warnings from the paper are eerily similar to my horsemen:
1. predicted the hallucination (pestilence)
2. bias amplification (war?)
3. environmental cost (famine)
4. un-auditable training corpus (death?)
5. "centralize linguistic and cultural power in the hands of the small number of companies" (conquest)
See also Tim Wu's "The Master Switch" which says:

The industry learned how to secure the enactment of seemingly innocuous and sensible regulations that nonetheless spelled doom for any rival.

People claim the same about Anthropic.

I prefer "LLM" to Artificial Intelligence, as I don't consider models to have "Intelligence" which goes far beyond the analytical traits we train models for. Intelligence requires embodiment and social interaction; machines lack the innate human skills of empathy, feeling and care, which explains a lot of the evils behind the current trends.↩
It should be noted that Morris also happened to be one of the founder of Y Combinator where he is in good company with other techno-fascists like Peter Thiel, Sam Altman, and so on. Crime, after all, pays.↩
Probably a good time to watch All Watched Over by Machines of Loving Grace.↩

LLM usage in Debian

2026-08-18T13:52:29+00:00

After spending many hours on reading all the proposals and discussions the best choice for me is NOTA (None of the above).

We do not need to create new rules for LLM usage, we already have our DFSG and our social contract.

Keep it simple, stupid. Avoid more rules!

My first go at tracking down a kernel bug…

2026-08-18T10:50:43+00:00

A couple of weekends back, I upgraded my home sever. It failed to restart after running apt dist-upgrade

The only update that was performed was to the kernel, it went from 6.12.88+deb13-amd64 to 6.12.100+deb13-amd64. I had previously performed an apt-get upgrade, and rebooted the machine, so I was pretty sure that this was to blame. This blog entry (is a late) attempt to document how I went about finding a fix for this issue so that next time I don’t need as much hand holding as I did this time around :-)

(1)
Having my machine not boot following an upgrade is pretty rare, but has happened before. Usually it is because I have done something wrong so as always confirming I haven’t broken something by accident is always my first step…

I plugged in a keyboard an monitor to the machine and watched it boot. Being a server this takes a long time (I guess because at this stage of system initialisation we want to test things sequentially)

Watching the system boot I see the usual BIOS/UEFI stages for this machine, followed by the grub menu and the the local screen showed:

            Loading Linux 6.12.100+deb13-amd64 ...
            Loading initial ramdisk ...

Nothing else. That was it. OK that looks like I have a broken system all right, and at very early stage of the boot process process.

(2)
Breaking into the grub menu and removing the quiet option yields a little more information (but not much):

            Loading Linux 6.12.100+deb13-amd64 …
            Loading initial ramdisk ...
            

            	EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID d
            	evice path
            		EFI stub: Measured initrd data into PCR 9

and nothing else.

(3) Initial debugging

Confirmed that I could still boot the machine with the old kernel 6.12.88+deb13-amd64 (During boot select Advanced options from the grub menu followed by the kernel image wanted)
- Yes – the system starts happily with the previous kernel
Checked that /boot had enough space
- Yes – plenty of space
Is anyone else reporting this problem?
- Nothing jumps out on Debian’s bug tracker
- Actually not mush referenced for my search “EFI stub: Measured initrd data into PCR 9 apart” other than the usual rantings to “turn off secure boot” (on this server that currently isn’t turned on – bad me)

(4) Triage

Start looking for where the fault first occurred. At this point I needed help, and given that Sledge was visiting I asked if he would sanity check what I was doing. His initial thoughts were that that /boot had run out of space, but replaying my step (3) with him acting as a ‘rubber duck’ showed that this was something other than PBKAC

Sledge had a quick look, then informed me that between kernel images 6.12.88+deb13 and 6.12.100+deb13 Debian stable has only had shipped .90 .94 .95 and .96 kernels. We could easily try them all:

wget each kernel package then install (dpkg -i) followed by an update-grub, checking that there was sufficient space on disks especially my small /boot partition)
I started with image 6.12.95+deb13 and this worked
6.12.96+deb13 yielded the same lock up on boot as 6.12.100+deb13

OK I now have the first kernel image that doesn’t boot on my system, time to raise a bug…

Up until now I have been walking to my garage where the server is located and standing in front of a rack
with a monitor and keyboard plugged into the machine. However this machine supports IPMI so I spent a little time getting that up and running so that I can continue from the relative comfort of my desk (with lights, a chair and not needing to hold the keyboard with one hand)

Great I can now grab screen shots from the confort of my desk (unfortunatly they are only screen shots not text files, but at least we can seen the early stage of boot, Post, grub menu and then initramfs before system log happens)

(5) Collating information for the initial bug report

Sledge had mentioned my problem in irc/#debain-kernal where iam_tj suggested that we try appending
‘debug earlycon=efifb’ to the kernal command line. This yielded 15 seconds worth of messages before the system locked up the last few messages being (vmlinuz-6.12.96+deb13-amd64):

[ 14.663477] RCU Tasks: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20.
[ 14.750474] RCU Tasks Rude: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20.
[ 14.838024] RCU Tasks Trace: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20.
[ 14.929752] NR_IRQS: 524544, nr_irqs: 584, preallocated irqs: 16
[ 15.016814] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[ 15.104011] Console: colour dummy device 80×25
[ 15.191236] printk: legacy console [tty0] enabled
[ 15.278249] printk: legacy bootconsole [efifb0] disabled

Booting the working kernel with the same kernel options yields the SAME messages with slightly differing times, but then continues to login prompt:

 [   14.697466] RCU Tasks: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20.
 [   14.784936] RCU Tasks Rude: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20.
 [   14.872067] RCU Tasks Trace: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=20.
 [   14.964000] NR_IRQS: 524544, nr_irqs: 584, preallocated irqs: 16
 [   15.051482] rcu: srcu_init: Setting srcu_struct sizes based on contention.
 [   15.226079] printk: legacy console [tty0] enabled
 [   15.313751] printk: legacy bootconsole [efifb0] disabled
 [   15.400831] ACPI: Core revision 20240827
 [   15.401415] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635855245 ns
 [   15.401464] APIC: Switch to symmetric I/O mode setup
 
... and so on

iam_tj also suggested adding keep_bootcon – with ‘debug earlycon=efifb keep_bootcon’ on vmlinuz-6.12.96+deb13-amd64:
We get a LOT further – and we see a crash / trace-back:

[ 34.285342] BUG: kernel NULL pointer dereference, address: 0000000000000000

I raised bug #1143721 and followed it up with screen captures of the boot sequence (captured from the IPMI client) and files containing the output of dmidecode, lscpu and lspci to kive the kernel team as much information as possible:

[6.12.96+deb13-amd64 debug earlycon=efifb keep_bootcon.tar.gz (application/gzip, attachment)]

[dmidecode.txt (text/plain, attachment)]

[lscpu.txt (text/plain, attachment)]

[lspci.txt (text/plain, attachment)]

(6) Tracking down the bug Git Bisect

The problem with this type of bug is that it is hardware (class) specific, whilst the kernel doesn’t boot on my system, it clearly has worked on machines used by the kernel team, the Debian test and build infrastructure, (otherwise this kernel would never have been released) and everyone else who has upgraded to the newer kernel before I did (otherwise we would be drowning in fails to boot bug reports). Carnil’s excellent response to my bug: Message #15 (and help in IRC) provided me with a detailed step by step guide in how to track down the individual git commit that fails on my system. I had already (with Sledge’s suggestion) made a clone of the stable branch, but was struggling to follow the steps in the Debian Linux Kernel Handbook to re-build a duplicate kernel because I didn’t understand how to obtain the same configuration that Debian used to build the kernel; Carnil’s email provided me the missing steps (Highlighted).

git clone --single-branch -b linux-6.12.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
cd linux-stable
git checkout v6.12.95
cp /boot/config-$(uname -r) .config
yes '' | make localmodconfig
make savedefconfig
mv defconfig arch/x86/configs/my_def
test 6.12.96 to ensure this is "bad"
git checkout v6.12.96
make my_defconfig
make -j $(nproc) bindeb-pkg
… install the resulting .deb package and confirm it fails to boot and triggers the NULL pointer dereference.

Right I can now start to Bisect the problem:

git bisect start
git bisect good v6.12.95
git bisect bad v6.12.96

Rather than use the half step point’s git bisect suggested I was advised in irc to jump straight to the a given commit that from the git log was suspected as the culprit:

git checkout 977855894bca4b87afa50d21e3f3e85a5a0e901f
build and install….
fails…
git bisect bad

git checkout 977855894bca4b87afa50d21e3f3e85a5a0e901f~1 ## ~1 is the commit beforehand
build and install….
fails…
git bisect good

The entire test tree can shown with git bisect log and this was submitted as an email to the bug report, we have found our smoking gun :-)

Finally I would like to thank Carnil, Iam_tj for their time patience and fantastic support in guiding me through finding this regression. Right now kernel bugs are coming in thick and fast with a lot of AI assisted bug hunting, the increased numbers of bugs mean that the kernel team are especially busy. Hopefully our paths will cross and I’ll be able to buy you some beers (or whatever) soon. thank you. Sledge also deserves thanks for putting up with me and pointing me in the right direction (as ever). Lucky for me that he lives nearby so I can provide beers on a regular basis :-)

Debian LLM GR - Summary of the options

2026-08-18T09:02:17+00:00

Debian LLM GR - Summary of the options

Introduction

LLMs have finally made it to the ultimate stage of Debian’s governance processes, a General Resolution of all the project’s full governing members (DDs).

There are a lot of options on the ballot, and they all have a different structure and approach the question in a different way. It can be hard to see the wood for the trees. I have made a summary table to try to capture the main differences, both in effect, and sentiment.

A plea to the undecided voter

Suspending briefly my attempt to be neutral:

Before voting, I encourage you to read the passionate rationales in options H and A, or at least the summary in my option C.

Few of the LLM defences in the discussion threads, and none of the LLM-positive proposals, provide answers to any of these profound ethical concerns, many of which ought individually to be a deal-breaker. Instead, these crucial questions are simply dismissed or even ignored.

Some will tell you we should “keep politics out of software” but as we can see in the world around us, software is political - now more than ever. Debian’s mission is a highly political one: developing a fully-free operating system, and defending its freeness as we do, is far from neutral!

And of course many of LLMs’ harms affect Debian directly.

Table

	A	G	C	H	F	D	B	E
LLM harms	Robusly discussed	Discussed	Robusly summarised	Robusly discussed; especially re climate	Summarised	Accepted as inevitable	Disregarded [1]	Ignored
Direct contributions of LLM-generated code	Forbidden	Forbidden	Strongly discouraged	Strongly discouraged	Discouraged	Permitted	Permitted	Permitted
Direct use of LLM output in communications (bugs, mailing lists, etc.)	Forbidden	Forbidden	Forbidden (with possible exceptions)	Strongly discouraged	Discouraged	Permitted	Permitted	Permitted
LLM use where LLM output does not end up in the code/message	Forbidden	No position, so permitted	Strongly discouraged	Strongly discouraged	Discouraged	Permitted	Permitted	Permitted
Disclosure of LLM use	LLM use forbidden	LLM use largely forbidden, no further disclosure requirement	Disclosure required	Disclosure encouraged	Disclosure encouraged	Disclosure required	Disclosure required	Undisclosed LLM use is OK
Use of LLMs by upstreams			Condemned			“Not recommended”
Positive statements about LLMs						“Here to stay”	Moderate	Strong

Notes

Ordering

I have tried to present the options in semantic order, with most LLM-negative proposals to the left, and the most LLM-positive to the right.

I have not quoted the one-line titles for the options. These have generally been provided by the proponents of each option, and, unfortunately, some of them are IMO quite misleading.

Note that, unfortunately, the voting software likes to assign numbers to options but also to preferences. Be mindful of this possible confusion when casting your vote. For clarity I quote only the option letters.

Upstream LLM code contributions

Some of the proposals acknowledge the uncertain legal status of LLM output. But all of them implicitly or explicitly assume that LLM output is or can be DFSG free. So none of the proposals forbid upstream projects with LLM-generated contents.

None of the proposals would require us to go back to pre-LLM versions of the upstream projects we use, and attempt to fork and maintain them. I very much think there is room in the world for people to try to do that, but I don’t think the Debian project can be that effort.

Given that the conclusions are the same in each case, whether the matter is discussed does not seem to me to be a significant difference. I have therefore not included a column for it.

Ability of individual teams to set their own rules

My proposal has a specific paragraph (7) explicitly permitting teams to set a “no LLM” policy. The other proposals do not discuss this point specifically. During the discussion, it seemed that most participants agreed that even options which explicitly permit LLM use generally do not prevent a team from setting its own more restrictive LLM policy.

I have therefore not tabulated this aspect.

Exceptions and nuances

Few of the permissive texts are absolute or unconditional. To summarise I have necessarily left out some nuance.

So for example when an entry says “permitted”, that generally means “permitted with conditions which are believed by LLM users to be readily satisfiable” (for example, DFSG-compatibility - see above).

[1] Footnote re proposal B

Proposal B does mention that there are “concerns” about LLM use. But it fails to make an explicit statement about whether these concerns are justified.

It then proceeds exactly as if they are not justified. IMO “disregarded” is a relatively mild term for such a rhetorical technique.

Edited 2026-08-18 09:02 UTC to make the proposal letters in the table be links.

comments

AI in Debian: The Vote, Proposals, and Nuance

2026-08-18T01:39:54+00:00

Let me start with a hypothesis:

For human developers, using coding LLMs magnifies their difference in skill levels.

I am one that rarely thinks things are always black and white. Back in March, I wrote Artifial Intelligence: Shades of Gray. Since then, I’ve had more of a chance to experiment with LLMs myself. I also happen to work for an employer that is taking a very pragmatic approach to LLMs: teams and individuals use it as they see fit, but if they are causing considerable expense, they have to justify it.

In various settings, I have seen the egregious examples of AI slop we all know about. As I wrote in March, “I have seen it both waste more time than it saves, and save a ton of time.”

I have come to see that, as a tool, it is most valuable when it is running under the supervision of an experienced engineer. It is at its worst when it has no such supervision; the “vibe coding” and other low-quality slop we see.

A coding agent is like a junior developer or research assistant. When properly supervised, they help projects move along more quickly by letting a senior developer focus on the more difficult, less mundane aspects of the project. But one couldn’t expect a junior developer to consistently deliver high-quality code and architecture on their own.

Let’s put a pin in this idea and look at the story in Debian.

LLM use in Debian

There is a vote happening in Debian around the use of LLMs. In typical Debian fashion, there are 8 options to choose from, many of them similar. Most of these proposals acknowledge there are different types of tasks done in Debian, but the proposals don’t differentiate between them well. Let me do so here. These are some of the LLM-relevant tasks people in Debian perform:

Packaging upstream software for Debian (by far the largest task)
Writing Debian-specific code (eg, apt or the Debian installer)
Maintaining Debian infrastructure (build systems, for instance)
Writing documentation and translations

I’m going to focus my remarks here on packaging upstream software for Debian, since this is by far the most time-consuming developer task project-wide.

It matters to our users that we get this right, and packaging quality is one of the things that sets Debian apart from other distros. Packaging things for Debian requires knowledge of some specific tools, such as debhelper, that aren’t widely used anywhere else. In most cases, it is fairly rote time-consuming work. In other words, by its design, it requires people with senior-level skills to do grunt work.

I can’t overstate how massive a burden this grunt work is. I maintain some packages for Go and Rust. By Debian policy, all of those packages’ dependencies must also exist as Debian packages, and be used to build against. When upstream adopts a newer version of some library, it can unleash cascading dependencies that can take hours to sort out. Worse, the Rust team and the Go team use entirely different ways of managing packages (Go uses one Git repo per package, while Rust has a monorepo with specialized scripts to import Cargo packages and generate Debian ones). On top of that, we can’t just modify things like usual; we have to use quilt. And on top of that, I’m also a backports maintainer, so all the work (and usually even more) has to be done there also.

Now let’s pull on that pin from the earlier conversation. This is exactly the kind of scenario that a well-supervised coding LLM is most effective in. I could see a seasoned developer saving hours, maybe even days, by turning over the mundane tasks of managing trees of cascading dependencies over to a coding tool — and verifying and directing the process. (Yes, I have been using em-dashes for years; LLMs have copied people like me, not the other way around! This post was not written with any AI assistance.)

Actually, this is almost a dream scenario for a coding assistant. The result is time-consuming to formulate but easy to review, which is the opposite of the way these things often go.

I can assure you with 100% certainty that humans aren’t adding a lot of value in this process. It would be wrong to believe that a human is carefully reading every line of code in dozens of updated or new library packages. The problem set is too big, the time too short, and the code too varied and complex.

Coding agents seem to be most effective when there are strong test suites that they can test changes against. Debian builds, especially of modern packages, tend to have this property. Many packages have test suites that are run during build. And, if the package builds in an isolated environment (and especially if its downstream dependencies do also), then there is a decent chance that it’s fairly correct. Maybe needing some manual tweaking here and there, but generally a successful build is a reasonable indicator.

You can argue that it would make more sense for Debian to just include dependencies in source packages, along with some version information to support security rebuilds, and I’d tend to agree with you. But we are where we are. This would be one of the more significant leaps forward in developer productivity, but it complicates things like copyright reviews.

Where are LLMs run? What is the environmental impact?

Most of the proposals seem to make the assumption that LLMs must always run in some large, hosted datacenter. As I noted in my March article, I have had credible results on even an older GPU running on solar power.

That said, it is undeniable that LLMs are fueling a datacenter boom, and this in turn is producing a significant new demand for resources. Most notably for the global scale: electricity, which is sometimes generated using carbon-emitting technologies.

Bill McKibben, who has been a leading voice in the fight against climate change since the 1980s, has made some interesting points recently: he’s noted that solar power is the fastest kind of generation we can build, and a number of large AI companies are investing heavily in solar, even to the point of fully offsetting new datacenter’s needs. On the other hand, he’s also noted that some companies are buying inefficient and dirty gas turbines. It is decidedly a mixed bag. The heavy investment in solar can have knock-on positive effects for infrastructure. Obviously, not every picture here is rosy. This analysis doesn’t touch on the real land and water use situation, either.

On the other hand, if an LLM allows me to do in an hour what I would have done in a day, that’s a day of not heating or cooling the work area — generally not sustaining a human for the purpose of writing code for Debian. HVAC energy consumption dwarfs my GPU, and I’d imagine probably also the slice of LLM energy used.

Holistically, I would have to conclude the picture is mixed. It is possible to use LLMs in a pretty green way, and also in a pretty dirty way.

Assuming Conditions Never Change

A flaw in most of these proposals is they assume that the conditions at this present moment will always hold. In fact, that the conditions at the present moment will not continue is something both AI cheerleaders and AI skeptics agree on.

For instance:

Ed Zitron has done a ton of research into the financing side of AI, and has concluded that the current model is unsustainable and headed for a significant bubble burst. I’m not positioned to personally evaluate those claims, but if that happens, what is the result? Perhaps it is a steeply increasing cost of inference for the frontier models, slower pace of training/evolution for them, etc.

In a recent episode of Oxide and Friends, Simon Willison discussed the open weight models that are now available. They have been making remarkable strides in efficiency and capabilities, to the point where $50,000 of hardware can now run high-end open weight models with capabilities that are at least in the same ballpark as the American frontier models. This puts running high-end models locally squarely within reach of universities and small- to medium-sized businesses, with power requirements that can be met with standard commercial solar and wind installations.

The lack of nuance in the more restrictive proposals is particularly concerning. Proposal A doesn’t allow “the use or assitance of… LLMs”. So it bans my solar-powered GPU. It bans using LLMs to find security issues. It bans all sorts of things that don’t seem to be ban-worthy, alongside the things that do. And it codifies it in the very hard-to-change social contract.

That proposal, and some like it, seem to imply that all LLM output is bad. I grant you that AI slop is a real and legitimate concern, and many Open Source projects have to deal with it. On the other hand, we have all seen first-hand how the security of the Linux kernel has benefited dramatically from AI analysis. It is certain that black hats are using these tools. If we refuse to use modern security tools, our security will be compromised (and what is the environmental and social impact of THAT?)

I find the statement “Generative AI is characterized by producing output of a nature that would ordinarily be produced and consumed by humans” to be particularly interesting. The same was once said of compilers.

The Real Concerns

You might think from reading this that I am some AI cheerleader. I’m not. I share the ethics of the FLOSS movement, and have for decades. I abhor the power and lack of ethics that many big names in the field are running with at the moment. I’ve had to put up Anubis on this blog, for instance.

I have personally experienced the effects of AI slop, especially at review time. This is a real problem, though I don’t think the more draconian policies are likely to help (the looser “you must disclose” stand a fighting chance, but I’m not sure they would help, either.) Done poorly, AI threatens developer burnout by overwhelming them with poor code and verbose but useless explanations. Done well, AI can help prevent developer burnout by automating tedious and low-value tasks.

Shouldn’t our goal be that humans submit work to Debian, using tools they prefer, and take responsibility for it? Does it matter if someone uses ed, vim, emacs, or vscode? If they use LSP or just run gcc manually? I’d say we benefit from the diversity. Wouldn’t we be better off to benefit from the diversity here, and judge work as we always have: on its merits, not what tools were used to create it?

Fundamentally, a GR is a long and arduous process. It’s not easy to reverse later. Amending the Social Contract is even longer and more arduous (I should know; I may have been the first one to try). The LLM landscape is fast-moving. None of us can really predict where it will be in a year. Will the current market leading companies even still exist? Will it be at all credible to refuse to use AI-assisted security tools? What is the most effective way to deal with AI slop? What level of utility will we be able to achieve with models run locally?

Some of these proposals would make sense if drafted in some way short of a GR, which would allow more maneuverability as the landscape changes.

Brief analysis of the options

Considering the proposals:

Proposal A: seeks to amend the social contract, which I am opposed to for reasons already laid out above. It names some real concerns about AI that I agree with, but implies that all LLM uses and models are guilty of the problems, which is not the case with all of the claims. It also sets us behind the curve on security and stability by forbidding the use or assistance of those tools, even if run by others. It requires us to ignore reports of actual security bugs, or correct fixes, if those reports were generated with the assistance of an LLM, which I find to be absolutely untenable.
Proposal B: This is the “AI with accountability” approach. It notes the real concerns with LLMs without painting with an overbroad brush. It strikes me as level-headed and sensible.
Proposal C: It paints with an over-broad brush and makes some non-binding requests. Then it winds up largely like proposal B, though while it is worded more strongly, has fewer binding requirements (for instance, it lacks proposal B’s prohibition on transmitting sensitive information to untrusted providers)
Proposal D: Seems broadly similar to proposal B, an “AI with accountability” approach. I’m not really clear why we need both.
Proposal E: Largely the status quo. It is like proposals B and D in that it says humans are accountable for their contributions. It encourages disclosure of LLM use, but does not mandate it. Like proposal B, it prohibits disclosing sensitive information to third-party AI services. Note that both proposals B and D have an appropriate nuance: a local model is fine, a third-party one is not.
Proposal F: This seems really similar to proposal E. I’m not sure why we have these two.
Proposal G: Disallows “the output of generative AI as direct contributions to Debian.” This is something of a weakened proposal A; it doesn’t seek to amend the social contract, nor does it ban all use; it simply bans the use as a direct contribution.
Proposal H: Ban due to climate impacts. “How is this even an argument” is disrespectful to reasoned conversation. I have already noted that LLMs can be and are used in ways that are not climate-harming. It explicitly contains no binding requirements at all, and is effectively a rant. While I agree with the sentiment that climate change is an urgent problem, and that some LLMs are exacerbating it, I disagree with that all LLM usage does so and therefore disagree with the conclusion.

In favor of nuance

I find that black-and-white thinking is almost always something to be avoided. I see it too often. I see it in politics, I see it in our software, I see it in discussions around AI. Are there deeply unethical things happening in AI? Absolutely. Are they doing some impressive things? Also yes.

We have accepted this nuance in other areas. For instance, almost all the hardware Debian runs on has closed-source hardware, and has components manufactured or assembled in countries with some of the worst human rights records on the planet. I’m not saying this is a great state of affairs. It is something we should speak up about and act upon. But the worse state of affairs would be “no Debian because the hardware is impure”.

Debian turns 33!

2026-08-16T13:00:00+00:00

It has now been thirty-three years since the Debian project was announced to the world by Ian Murdock, on August 16, 1993. This anniversary is an opportunity to reaffirm the goals, characteristics, and qualities of the Debian project: itâ€™s an association of individuals who have made common cause to create a free operating system. Our distribution is characterized by a commitment to software freedom, as enshrined in the Debian Social Contract and the Debian Free Software Guidelines. It focuses on security and stability. This stability is crucial to Debian position in the free software ecosystem.

With our users as our priority, Debian makes special efforts regarding accessibility with Debian-Accessibility and diversity with our Outreach Programs.

Debian Day is a great opportunity to get together, whether for a local meetup, or simply to grab a coffee with other members of the Debian community. Check out the Debian Day wiki to see if there is a celebration near you. And if there isn't, maybe you can organize it next year!

Today is also an opportunity for you to start or resume your contributions to Debian. For example, you can install the how-can-i-help package and see if there is a bug in any of the software that you use that you can help to fix, contribute small tips on how to install Debian on your machines to our wiki pages, or put a Debian live image in an USB memory and give it to some person near you, who still didn't discover Debian.

Thanks to everybody who has contributed to develop our beloved operating system in these 33 years, and Happy birthday Debian!

Sad Story

2026-08-16T07:01:10+00:00

Not a screenshot of despair. But only because it’s not a screenshot.

FrOSCon 2026: TLS Talk

2026-08-15T18:02:03+00:00

Info: German content only, sorry.

I was pondering for the past three years if I should give some sort of TLS basics talk at FrOSCon. I finally stepped up this year and gave that talk today, with the title "TLS, mTLS, SNI, ECH, CAA, HTTPS, PKI, Zertifikate und ein bisschen PQC". I was too optimistic with my 50 slides, and had to drop the Post Quantum Cryptography part at the end. Still got positive feedback from Zugschlus and others - thanks a lot for that <3 - and was asked for the slides. It's not a piece of art, but maybe it helps to release the LibreOffice odp file as well, so others can use it as a base for other events or corp internal talks. So here is the froscon-tls-2026.pdf and froscon-tls-2026.odp, both released under the CC BY-NC license.

The video is also available at media.ccc.de if you want to watch it.

Thanks to everyone who made FrOSCon happen for the 21th time!

Hacked by Chinafans

2026-08-15T09:31:47+00:00

What Happened

On 2026/08/10 at 2:11 am Australian eastern standard time (2026/08/09 16:11 UTC) someone created a post titled “Hacked by Chinafans” on my documents blog [1]. The person in question created an account named “67965e42a3c3” on that site with the email address 67965e42a3c3@google.com associated with it (I tried emailing that address and it bounced).

At 04:28:41am Australian eastern standard time (18:28 UTC) I was sent an email titled “Have you been hacked” by a reader of my blogs who subscribed to the RSS feed of my documents blog (a blog that I never expected anyone to read by RSS). Along the lines of “the wisdom of crowds” should we have “the unexpected observation and problem reporting of crowds”? I appreciate the notification, I might not have noticed until the next time I watched an unusually good movie otherwise.

The account in question was apparently created on 2026-07-21 at 16:43:47 (presumably UTC) even though at the time I believe creating accounts was not permitted. As an aside the timestamp of account creation is stored in the user_registered column of the wp_users table in the database, there doesn’t appear to be a way to access this in a standard WordPress installation other than doing a SQL query.

2026-07-24 15:43:17 status triggers-pending wordpress:all 7.0+dfsg1-1
2026-07-24 15:43:19 upgrade wordpress:all 7.0+dfsg1-1 7.0.2+dfsg1-1

Above are the relevant sections of my dpkg log showing the WordPress versions in use. I was running version 7.0+dfsg1-1 at the time the account was apparently created. I am confident in the accuracy of the dpkg logs and believe that they did not compromise the OS, I am not sure whether they ran hostile SQL code to change fields in the MySQL database so had to consider the possibility that the account creation time could have been set to a deliberately misleading value. I checked backups of the MySQL database stored off-site and found that the account in question was not in the 2026-07-21 backup (which was done before 16:43) but in the 2026-07-22 backup.

The WordPress release history [2] has version 7.0.1 released on 2026-07-09 and version 7.0.2 released on 2026-07-17. So presumably the attacker diffed the code on those releases, found an exploitable bug, and used it to create an account on my blog with admin privs. Then they waited a few weeks to see if I would notice and published a blog post when I didn’t notice.

WordPress Deficiencies

WordPress doesn’t seem to store the version it’s running at the time of operations. So anyone who doesn’t have a suitable external log of versions deployed (such as the dpkg.log file for a Debian managed installation) won’t know for sure which version was running. It supports automatic updates but you can’t be sure that they happened soon after the release.
There is no log of IP addresses used for operations. There are apparently some 3rd party modules to log such things and web pages documenting how to modify the PHP to add it but nothing in the standard distribution.
Software should have a standard distribution with some support for logging of security relevant data. The typical situation is that people don’t plan for logging such things until after they have been attacked so the data should be recorded without users going out of their way to log it.
A log of security relevant data should be stored in a database table with only insert access (no update, delete, or drop).
Ideally a CMS would support different database accounts for different purposes. Someone from an internal network or VPN could talk to an instance of the web server which has a database username and password giving full access. Everyone from outside the trusted range gets an instance of the web server with database access only allowing to read the posts and appearance configuration and to enter comments. If the database didn’t allow the account used for public access to create new admin users or create posts then it would be a lot harder for attackers.
Ideally for everything that stores user account data there would be an easy way of getting a list of users in a plain text format to allow running diff. The design of WordPress has two tables, one for users and one for encoded metadata about users of which one will be the access level. The following SQL command will give a list of all users that aren’t subscribers (everyone above the minimum level of access which is typical for new users) along with their encoded password and access level. This could be used in a monitoring system to alert about new privileged users. The TABLE_PREFIX variable is for the prefix for WordPress tables, which is “wp_” by default but can be any legal value.
```
select $TABLE_PREFIXusers.user_login, $TABLE_PREFIXusers.user_pass, $TABLE_PREFIXusermeta.meta_value from  $TABLE_PREFIXusers join $TABLE_PREFIXusermeta on $TABLE_PREFIXusers.id = $TABLE_PREFIXusermeta.user_id and meta_key='$TABLE_PREFIXcapabilities' and meta_value != 'a:1:{s:10:"subscriber";b:1;}';
```

What Next?

The blog post they created had a couple of links to Telegram which could presumably be used to contact them. If anyone involved in computer security wants a copy of the original post to do so then they can contact me by any of the usual methods.

I am interested in communication with the attacker if they wish, Telegram is not a service I use but I presume that anyone capable of doing this sort of attack is also capable of finding other ways of contacting me.

I have idly considered changing to a static site generator, here is a good list of static site generators [3].

I have also idly considered other platforms for blogging such as Lemmy. I don’t know if Lemmy is better than WordPress for security and updates, but there are plenty of free instances running where it wouldn’t be an issue I have to work on.

15 Years

It’s been 15 years since my blog server was cracked by a trojaned ssh client [4]. At least this time it was only one service that was compromised.

AMD Video Drivers, LLMs, and Debian Kernels

2026-08-15T08:09:51+00:00

The AMD GPU Problem

For a while I’ve been having issues with AMD GPUs, video locking up periodically. I blogged about this late last year but I first had noticeable problems early last year [1]. The problems hadn’t only concerned my workstation but also my home server which is also used as a workstation. I’ve recently upgraded my machines to Debian/Testing, my home server has been generally OK but my workstation has been crashing a lot. Every second day when on kernel 7.1.6 and then when on 7.1.7 it crashed at least once a day.

The AMD GPUs I have are “[AMD/ATI] Baffin [Radeon RX 460/560D / Pro 450/455/460/555/555X/560/560X] (rev e5)” in my main desktop workstation, “[AMD/ATI] Lexa [Radeon 540X/550X/630 / RX 640 / E9171 MCM] (rev c1)” in my build server, and “[AMD/ATI] Baffin [Radeon RX 460/560D / Pro 450/455/460/555/555X/560/560X] (rev cf)” in my home server. They aren’t new GPUs, but also aren’t really old and they all support 4K and better resolution.

Chat GPT Was Useful

When I googled the errors I was seeing I found nothing useful. On the suggestion of a friend I tried asking ChatGPT. Generally I don’t recommend asking LLMs about such things, but it can be a last resort as long as you know what you are doing. ChatGPT asked me to run a number of commands to get information for it to make more informed decisions. I know that the output of lspci and similar commands isn’t a risk, but a novice could be tricked into running commands that expose sensitive data.

ChatGPT did give me some useful information, not a solution but an indication that the problem was due to driver bugs.

Upgrading to Experimental

Debian/Experimental is for packages that are expected to have problems and generally aren’t recommended even for the people who usually use Debian/Unstable. It’s commonly used for packages that are needed to develop other packages, EG new libraries that aren’t fully usable but which are needed to package newer versions of applications.

I upgraded my workstation to the Debian/Experimental kernel 7.2~rc7-1~exp1 after having tried every other convenient option. Generally I wouldn’t recommend that anyone run an Experimental kernel without a really good reason, but crashing more than once a day is a fairly good reason. That kernel has now given me over 4 days of uptime on a system that previously wouldn’t last a day. I installed it on my dual-socket build server that has an old AMD GPU in it for test purposes and that also hasn’t crashed since. I installed it on my ML test machine which has an Intel B580 Battlemage GPU with 16G of VRAM and was repeatedly getting a kernel panic related to the GPU a few seconds after boot and now it also works correctly.

It seems that the 7.1.x kernels have bugs in the AMD video drivers and in some part of the code that affects Intel video drivers and that the bugs in question are fixed in the tree that will become 7.2. I would not recommend anyone who has a 7.1.x kernel working fine for them try 7.2 RC kernels at this time, but anyone who has GPU related problems (particularly Intel and AMD GPUs) should definitely test it out.

I also don’t recommend upgrading any system with an AMD GPU to Debian/Testing or Debian/Unstable at this time unless you are also prepared to install an Experimental kernel if it becomes necessary.

There are a several kernel log dumps related to this after the break (which won’t be in RSS feeds). This is mainly for Google so that other people who have such issues can get more useful results out of Google searches than I got.

Future Support Options

Separate from the issue of whether commercial LLMs like ChatGPT can be useful for solving technical problems there is the issue of whether they are desirable. I think that we really don’t want people solving problems in FOSS systems with closed-source LLMs. This leads to loss of privacy, loss of the control users deserve to have over their own systems, and an implied promotion of non-fee software.

I think that the ideal would be to have a cross distribution effort to generate training data for a support LLM system which can then be further trained by each distribution for a greater emphasis on distribution specific issues.

[1] https://etbe.coker.com.au/2025/11/09/amd-video-driver-issues/

Errors on AMD GPUs

2026-08-09T23:03:06.004792+10:00 xev kernel: amdgpu 0000:02:00.0: GPU fault detected: 147 0x00024802
2026-08-09T23:03:06.004792+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 42037 thread kscreenloc:cs0 pid 42044
2026-08-09T23:03:06.004793+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000800
2026-08-09T23:03:06.004794+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0F048002
2026-08-09T23:03:06.004795+10:00 xev kernel: amdgpu 0000:02:00.0: VM fault (0x02, vmid 7, pasid 130) at page 2048, write from 'TC0' (0x54433000) (72)
2026-08-09T23:03:06.008762+10:00 xev kernel: amdgpu 0000:02:00.0: GPU fault detected: 147 0x00004802
2026-08-09T23:03:06.008768+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 42037 thread kscreenloc:cs0 pid 42044

2026-08-04T01:13:37.505839+10:00 xev kernel: ------------[ cut here ]------------ 
2026-08-04T01:13:37.505859+10:00 xev kernel: amdgpu 0000:02:00.0: [drm] drm_WARN_ON_ONCE(cur_vblank != vblank->last) 
2026-08-04T01:13:37.505862+10:00 xev kernel: WARNING: CPU: 6 PID: 210534 at drivers/gpu/drm/drm_vblank.c:362 drm_update_vblank_count+0x2f1/0x3c0 [drm] 
2026-08-04T01:13:37.505866+10:00 xev kernel: snd_intel_dspcfg wmi_bmof rc_core snd_intel_sdw_acpi drm_ttm_helper uas realtek snd_usbmidi_lib snd_hda_codec ttm mdio_devres snd_hda_core snd_seq_midi drm_kms_helper usb_storage mc snd_hwdep libphy snd_seq_midi_event intel_uncore snd_pcm_oss i2c_algo_bit serio_raw snd_rawmidi pcspkr snd_mixer_oss i2c_i801 video snd_seq snd_pcm i2c_smbus lpc_ich snd_seq_device mei_me e1000e snd_timer mei snd tpm_infineon soundcore joydev bnx2 wmi button nfsd auth_rpcgss nfs_acl lockd grace sunrpc coretemp br_netfilter bridge stp llc sg ghash_clmulni_intel loop msr i2c_dev drm efi_pstore configfs nfnetlink ip_tables x_tables autofs4 btrfs blake2b_generic dm_crypt dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 md_mod ext4 crc16 mbcache jbd2 crc32c_generic virtio_blk evdev hid_generic usbhid hid sd_mod xhci_pci xhci_hcd ahci ehci_pci ehci_hcd libahci crc32c_intel libata usbcore aesni_intel nvme psmouse scsi_mod gf128mul crypto_simd nvme_core cryptd 
2026-08-04T01:13:37.505879+10:00 xev kernel: nvme_auth scsi_common usb_common efivarfs 
2026-08-04T01:13:37.505880+10:00 xev kernel: CPU: 6 UID: 1008 PID: 210534 Comm: sshd-session Tainted: G D 6.12.88+deb13-amd64 #1 Debian 6.12.88-1 
2026-08-04T01:13:37.505881+10:00 xev kernel: Tainted: [D]=DIE 
2026-08-04T01:13:37.505883+10:00 xev kernel: Hardware name: Hewlett-Packard HP Z640 Workstation/212A, BIOS M60 v02.61 03/23/2023 
2026-08-04T01:13:37.505884+10:00 xev kernel: RIP: 0010:drm_update_vblank_count+0x2f1/0x3c0 [drm] 
2026-08-04T01:13:37.505885+10:00 xev kernel: Code: 48 8b 5f 50 48 85 db 75 03 48 8b 1f e8 68 eb 2b cf 48 c7 c1 70 3e cb c0 48 89 da 48 c7 c7 f9 6f cb c0 48 89 c6 e8 af d7 a6 ce <0f> 0b e9 4b fe ff ff 48 8b 4c 24 18 e9 31 fe ff ff 31 f6 48 85 db 
2026-08-04T01:13:37.505887+10:00 xev kernel: RSP: 0000:ffffd3cc8681fca0 EFLAGS: 00010082 
2026-08-04T01:13:37.505888+10:00 xev kernel: RAX: 0000000000000000 RBX: ffff8c6b42b13710 RCX: 0000000000000027 
2026-08-04T01:13:37.505889+10:00 xev kernel: RDX: ffff8c89ef521788 RSI: 0000000000000001 RDI: ffff8c89ef521780 
2026-08-04T01:13:37.505890+10:00 xev kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: ffffd3cc8681fb20 
2026-08-04T01:13:37.505891+10:00 xev kernel: R10: ffff8c8a6fef3628 R11: 0000000000000003 R12: 0000000000000000 
2026-08-04T01:13:37.505892+10:00 xev kernel: R13: ffff8c6c07853828 R14: 0000000000000003 R15: 0000000000000000 
2026-08-04T01:13:37.505893+10:00 xev kernel: FS: 00007ffaf2fd5880(0000) GS:ffff8c89ef500000(0000) knlGS:0000000000000000 
2026-08-04T01:13:37.505895+10:00 xev kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 
2026-08-04T01:13:37.505896+10:00 xev kernel: CR2: 00007fb1718c8000 CR3: 000000074521a004 CR4: 00000000003706f0 
2026-08-04T01:13:37.505897+10:00 xev kernel: Call Trace: 
2026-08-04T01:13:37.505898+10:00 xev kernel:  
2026-08-04T01:13:37.505899+10:00 xev kernel: drm_crtc_accurate_vblank_count+0x41/0xc0 [drm] 
2026-08-04T01:13:37.505900+10:00 xev kernel: dm_pflip_high_irq+0x155/0x330 [amdgpu] 
2026-08-04T01:13:37.505901+10:00 xev kernel: amdgpu_dm_irq_handler+0x85/0x1f0 [amdgpu] 
2026-08-04T01:13:37.505902+10:00 xev kernel: amdgpu_irq_dispatch+0xd2/0x230 [amdgpu] 
2026-08-04T01:13:37.505903+10:00 xev kernel: amdgpu_ih_process+0x84/0x100 [amdgpu] 
2026-08-04T01:13:37.505904+10:00 xev kernel: amdgpu_irq_handler+0x23/0x60 [amdgpu] 
2026-08-04T01:13:37.505905+10:00 xev kernel: __handle_irq_event_percpu+0x4a/0x190
2026-08-04T01:13:37.505907+10:00 xev kernel: handle_irq_event+0x38/0x80 
2026-08-04T01:13:37.505908+10:00 xev kernel: handle_edge_irq+0x8b/0x230 
2026-08-04T01:13:37.505909+10:00 xev kernel: __common_interrupt+0x45/0xe0 
2026-08-04T01:13:37.505910+10:00 xev kernel: common_interrupt+0x42/0xa0 
2026-08-04T01:13:37.505911+10:00 xev kernel: asm_common_interrupt+0x26/0x40 
2026-08-04T01:13:37.505912+10:00 xev kernel: RIP: 0033:0x7ffaf3c5fd7b 
2026-08-04T01:13:37.505913+10:00 xev kernel: Code: 70 c7 00 66 0f 6e f8 c1 ef 02 66 0f 70 f7 e0 83 c7 01 66 0f ef ff 66 0f fa f2 0f 1f 44 00 00 f3 0f 7e 01 66 0f 6f ce 83 c6 01 <48> 83 e9 08 f2 0f 70 c0 1b 66 0f 6f e0 66 0f 6f e8 66 41 0f f9 c0 
2026-08-04T01:13:37.505915+10:00 xev kernel: RSP: 002b:00007fff86a5e0e0 EFLAGS: 00000202 
2026-08-04T01:13:37.505916+10:00 xev kernel: RAX: 0000000000008000 RBX: 0000562614a04050 RCX: 0000562614982ed8 
2026-08-04T01:13:37.505946+10:00 xev kernel: RDX: 0000000000007fe2 RSI: 0000000000000fad RDI: 0000000000002000 
2026-08-04T01:13:37.505948+10:00 xev kernel: RBP: 0000000000000000 R08: 000056261498ac40 R09: 0000000000008000 
2026-08-04T01:13:37.505949+10:00 xev kernel: R10: 0000000000000066 R11: 0000000000007fe1 R12: 0000000000007efa
2026-08-04T01:13:37.505950+10:00 xev kernel: R13: 0000000000008000 R14: 0000000000008000 R15: 000000000000ffe0 
2026-08-04T01:13:37.505951+10:00 xev kernel:  
2026-08-04T01:13:37.505953+10:00 xev kernel: ---[ end trace 0000000000000000 ]--- 
2026-08-04T01:55:40.844110+10:00 xev kernel: pcieport 0000:00:03.3: AER: Multiple Correctable error message received from 0000:00:03.3 
2026-08-04T01:55:40.844130+10:00 xev kernel: pcieport 0000:00:03.3: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Receiver ID) 
2026-08-04T01:55:40.844132+10:00 xev kernel: pcieport 0000:00:03.3: device [8086:6f0b] error status/mask=00000040/00002000 
2026-08-04T01:55:40.844134+10:00 xev kernel: pcieport 0000:00:03.3: [ 6] BadTLP

2026-08-11T09:33:33.473855+10:00 xev kernel: amdgpu 0000:02:00.0: GPU fault detected: 147 0x00024802
2026-08-11T09:33:33.473871+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 150905 thread kscreenloc:cs0 pid 150912
2026-08-11T09:33:33.473871+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000800
2026-08-11T09:33:33.473873+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0F048002
2026-08-11T09:33:33.473873+10:00 xev kernel: amdgpu 0000:02:00.0: VM fault (0x02, vmid 7, pasid 63) at page 2048, write from 'TC0' (0x54433000) (72)
2026-08-11T09:33:33.473874+10:00 xev kernel: amdgpu 0000:02:00.0: GPU fault detected: 147 0x00004802
2026-08-11T09:33:33.473874+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 150905 thread kscreenloc:cs0 pid 150912
2026-08-11T09:33:33.473875+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000800
2026-08-11T09:33:33.473876+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E048002
2026-08-11T09:33:33.473876+10:00 xev kernel: amdgpu 0000:02:00.0: VM fault (0x02, vmid 7, pasid 63) at page 2048, read from 'TC0' (0x54433000) (72)
2026-08-11T09:33:35.481863+10:00 xev kernel: amdgpu 0000:02:00.0: Dumping IP State
2026-08-11T09:33:35.481875+10:00 xev kernel: amdgpu 0000:02:00.0: Dumping IP State Completed
2026-08-11T09:33:35.481875+10:00 xev kernel: amdgpu 0000:02:00.0: [drm] AMDGPU device coredump file has been created
2026-08-11T09:33:35.481876+10:00 xev kernel: amdgpu 0000:02:00.0: [drm] Check your /sys/class/drm/card0/device/devcoredump/data
2026-08-11T09:33:35.481877+10:00 xev kernel: amdgpu 0000:02:00.0: GPU fault detected: 146 0x0110040c
2026-08-11T09:33:35.481877+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 150905 thread kscreenloc:cs0 pid 150912
2026-08-11T09:33:35.481878+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000022
2026-08-11T09:33:35.481879+10:00 xev kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E00400C
2026-08-11T09:33:35.481879+10:00 xev kernel: amdgpu 0000:02:00.0: VM fault (0x0c, vmid 7, pasid 63) at page 34, read from 'TC3' (0x54433300) (4)
2026-08-11T09:33:35.489845+10:00 xev kernel: amdgpu 0000:02:00.0: ring gfx timeout, signaled seq=5123619, emitted seq=5123621
2026-08-11T09:33:35.489853+10:00 xev kernel: amdgpu 0000:02:00.0: Process kscreenlocker_g pid 150905 thread kscreenloc:cs0 pid 150912
2026-08-11T09:33:35.489854+10:00 xev kernel: amdgpu 0000:02:00.0: GPU reset begin!. Source: 1
2026-08-11T09:33:35.493839+10:00 xev kernel: amdgpu 0000:02:00.0: [drm] ERROR Failed to initialize parser -125!
2026-08-11T09:33:35.737848+10:00 xev kernel: amdgpu: cp is busy, skip halt cp
2026-08-11T09:33:35.897842+10:00 xev kernel: amdgpu: rlc is busy, skip halt rlc
2026-08-11T09:33:35.897852+10:00 xev kernel: amdgpu 0000:02:00.0: BACO reset
2026-08-11T09:33:36.485849+10:00 xev kernel: amdgpu 0000:02:00.0: GPU reset succeeded, trying to resume
2026-08-11T09:33:36.485859+10:00 xev kernel: amdgpu 0000:02:00.0: [drm] PCIE GART of 256M enabled (table at 0x000000F402000000).
2026-08-11T09:33:36.485860+10:00 xev kernel: amdgpu 0000:02:00.0: VRAM is lost due to GPU reset!

Errors on Battlemage

Aug 11 17:01:47 ami kernel: ------------[ cut here ]------------
Aug 11 17:01:47 ami kernel: xe 0000:23:00.0: [drm] DMC 1 mmio[0]/0x5f074 incorrect (expected 0x96fc0, current 0x0)
Aug 11 17:01:47 ami kernel: WARNING: drivers/gpu/drm/i915/display/intel_dmc.c:696 at assert_dmc_loaded+0x275/0x430 [xe], CPU#0: kworker/0:3/215
Aug 11 17:01:47 ami kernel: Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency intel_uncore_frequency_common xe(+) skx_edac snd_h>
Aug 11 17:01:47 ami kernel:  msr i2c_dev configfs efi_pstore efivarfs autofs4 btrfs libblake2b raid6_pq xor mpt3sas raid_class scsi_transport_sas megarai>
Aug 11 17:01:47 ami kernel: CPU: 0 UID: 0 PID: 215 Comm: kworker/0:3 Not tainted 7.1.7+deb14-amd64 #1 PREEMPT(lazy)  Debian 7.1.7-1 
Aug 11 17:01:47 ami kernel: Hardware name: HP HP Z4 G4 Workstation/81C5, BIOS P61 v03.00 04/15/2026
Aug 11 17:01:47 ami kernel: Workqueue: sync_wq local_pci_probe_callback
Aug 11 17:01:47 ami kernel: RIP: 0010:assert_dmc_loaded+0x291/0x430 [xe]
Aug 11 17:01:47 ami kernel: Code: 24 10 e8 f2 e5 a3 ce 48 8d 3d bb 85 0d 00 8b 54 24 0c 45 89 e9 45 89 e0 48 89 c6 52 8b 4c 24 2c 51 8b 4c 24 30 48 8b 54>
Aug 11 17:01:47 ami kernel: RSP: 0018:ffffd27ac0b87b80 EFLAGS: 00010282
Aug 11 17:01:47 ami kernel: RAX: ffffffffc1743dfd RBX: ffff8c5b80e54000 RCX: 0000000000000001
Aug 11 17:01:47 ami kernel: RDX: ffff8c5b81df5a10 RSI: ffffffffc1743dfd RDI: ffffffffc1605860
Aug 11 17:01:47 ami kernel: RBP: ffff8c5b86955000 R08: 0000000000000000 R09: 000000000005f074
Aug 11 17:01:47 ami kernel: R10: 0000000000000000 R11: 0000000000091050 R12: 0000000000000000
Aug 11 17:01:47 ami kernel: R13: 000000000005f074 R14: 0000000000000001 R15: 0000000000000000
Aug 11 17:01:47 ami kernel: FS:  0000000000000000(0000) GS:ffff8c673e172000(0000) knlGS:0000000000000000
Aug 11 17:01:47 ami kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 11 17:01:47 ami kernel: CR2: 00007ffed1fdcd00 CR3: 0000000ae942a003 CR4: 00000000003706f0
Aug 11 17:01:47 ami kernel: Call Trace:
Aug 11 17:01:47 ami kernel:  
Aug 11 17:01:47 ami kernel:  intel_dmc_enable_pipe+0xe4/0x290 [xe]
Aug 11 17:01:47 ami kernel:  ? drm_crtc_vblank_reset+0x4d/0x120 [drm]
Aug 11 17:01:47 ami kernel:  intel_modeset_setup_hw_state+0xb50/0x1e10 [xe]
Aug 11 17:01:47 ami kernel:  ? intel_display_driver_probe_nogem+0x138/0x1a0 [xe]
Aug 11 17:01:47 ami kernel:  intel_display_driver_probe_nogem+0x138/0x1a0 [xe]
Aug 11 17:01:47 ami kernel:  xe_display_init_early+0xb2/0x140 [xe]
Aug 11 17:01:47 ami kernel:  xe_device_probe+0x3c8/0xb50 [xe]
Aug 11 17:01:47 ami kernel:  ? xe_pm_init_early+0x152/0x160 [xe]
Aug 11 17:01:47 ami kernel:  xe_pci_probe+0xc26/0x1150 [xe]
Aug 11 17:01:47 ami kernel:  local_pci_probe+0x3e/0x90
Aug 11 17:01:47 ami kernel:  local_pci_probe_callback+0x16/0x20
Aug 11 17:01:47 ami kernel:  process_one_work+0x19d/0x3a0
Aug 11 17:01:47 ami kernel:  worker_thread+0x1af/0x320
Aug 11 17:01:47 ami kernel:  ? __pfx_worker_thread+0x10/0x10
Aug 11 17:01:47 ami kernel:  kthread+0xe3/0x120
Aug 11 17:01:47 ami kernel:  ? __pfx_kthread+0x10/0x10
Aug 11 17:01:47 ami kernel:  ret_from_fork+0x2b2/0x340
Aug 11 17:01:47 ami kernel:  ? __pfx_kthread+0x10/0x10
Aug 11 17:01:47 ami kernel:  ret_from_fork_asm+0x1a/0x30
Aug 11 17:01:47 ami kernel:  
Aug 11 17:01:47 ami kernel: ---[ end trace 0000000000000000 ]---

File recovery in process...

2026-08-13T17:47:20+00:00

Ohai,

I have some pending, encrypted mails to answer. And some of my answers for the next few days (particularly to what pertains to the current in-discussion vote on LLM usage in Debian) will be unsigned, even though Iâ€™d like otherwise.

My desktop system at work is showing some data corruption, and Iâ€™m slowly backing up my data. Fortunately, it seems I havenâ€™t lost any data, but still, given Iâ€™m letting rsync run until it starts spewing I/O errors, then power down and let the machine cool a bit, and start againâ€¦ it is a potentially long process.

And yes, this makes me somewhat angry. Why angry? Because Iâ€™m working on a brand-new computer (well, have used it for slightly over six months), custom-built to specs requested by my workplace. Specs that I donâ€™t really need, this machine is an utter luxury (i.e. an AMD Ryzen 9 9950X processor with 16 real cores / 32 threads; 128GB RAM in this day and age of RAM shortage, quite recent 32GB GPU, and lots of shiny lights seen in its huge fishbowl cabinet, liquid-based coolingâ€¦). The specs came not from me, but from people who had no idea what we would use them for. And yes, I expect the little fortune spent on this machine to be good for my use for probably a decade, as my previous computer was, but the amount paid wasâ€¦ exorbitant.

But still, what I learned recently is that the 4TB nVME SSD it has (a T-Force TM8FFJX34T) isâ€¦ a very cheap brand, bought because it was close to half the price of other offerings similar in capacity. According to smartctlâ€™s output, th SSD operates with a Warning Comp. Temp. Threshold: 90 Celsius and Critical Comp. Temp. Threshold: 110 Celsius, which sounds sensible, even too high for my standards (my last two laptops have been fanlessâ€¦ yes, an ARM system is very different from a high-end gaming machine). Iâ€™m right now typing from my laptop, which shows 78Â°C and 82Â°C for warning/critical thresholds.

And as expected, under heavy sustained reads (backing up to my NFS server), the desktopâ€™s smartctl shows Temperature: 83 Celsius and, further down, Temperature Sensor 1: 107 Celsius and Temperature Sensor 2: 82 Celsius (donâ€™t know which of these would make the threshold jump). The SSD has sustained Media and Data Integrity Errors: 20 and Warning Comp. Temperature Time: 21 (although Critical Comp. Temperature Time: 0). At least one of my colleagues have shrugged and installed a SATA SSD, laying the huge nVME basically to waste.

Anywayâ€¦ I also learned I am not the first, but the fourth person to notice this kind of issues in this system (out of ten similar purchased systems AIUI). It is completely unacceptable, and Iâ€™ll be pushing our Instituteâ€™s authorities to demand the provider to provide either good component quality for this very expensive system that has many luxury items, or to fix the systemâ€™s build in a way the nVME does not heat as much as it currently does.

Anyway, sigh, I only wanted to say, please excuse me for not using my cryptographic keys for a couple of days ðŸ™ƒ

PS- Iâ€™m also currently not connected to IRC and Jabber (and some similar technologies), as my bouncer runs from my usual workstation.

DIY skate punch-out

2026-08-13T08:28:08+00:00

Since I wrote about my fly30 ice skates, I'd continued to battle pain around the navicular bone in my feet. The action that seems to have finally fixed it was to perform a "punch out": a very localized remoulding of the area of the boot that presses against the sore area.

I basically followed the process from this helpful YouTube video.

I narrowed down the exact spot by borrowing some lipstick and transferring it from my navicular bone to the boot lining, then making that more permanent with a sharpie.

My punch was a spare part from a radiator valve which I packed with US cents (I couldn't fit any UK coins in). For the receiving-end, I tried another part from the radiator valve but I think it wasn't sufficiently larger than the punch to work well, so I swapped that out for a spoon.

take 2

I didn't have a temperature sensor I could use and I used a heat gun rather than a hairdryer, so I YOLO'd it a little. Some of the wrap on one of my boots is now distorted from where I didn't move the heat gun enough. It only took a minute or two to get the boot hot enough to be flexible. I set a 15 minute timer once the clamp was in place.

I've only skated one session since I did this but the pain seems to have gone! It's remarkably freeing to be skating without constantly trying to manage pain. Now I can focus on technique.

The PSX GPU is wild

2026-08-12T15:26:00+00:00

Inspired by some recent reverse-engineering, here are some things I find wild by the original PlayStation GPU:

VRAM is a flat 1024x512 16-bit image (555 + 1 bit alpha). You want more than just a framebuffer? Figure out yourself what goes where.
Yes, that means you'll need to allocate two framebuffers and double-buffer everything yourself.
Quads are common. No “triangles only” business here.
Vertex coordinates are screen-space x/y integers. No floats or fixed-point. (I'm ignoring the GTE here, plus higher-level libraries.)
Wait, where's z? There's no z. So there's no perspective correction. (This one is pretty famous)
OK, so how do you give in subpixel coordinates? You don't. There's no AA after all.
Texture coordinates (u/v) are uint8_t. There's no texture filtering either; everything is nearest-neighbor only.
OK, so that means you can't have textures larger than 256x256 (pretty common in that era), but how do you give in the handle to the texture?
You don't, it points directly to the 1024x512 VRAM. You manage yourself what goes where, remember?
So can you an only have textures in the top-left 256x256? Hah, no, we give you a bit-packed “texture page” system that offsets all your u/v coordinates.
Most textures are paletted to save VRAM (so instead of 555+1, your pixels now mean something like “two palette indexes”). Where does the palette live?
Well, duh, that's a 256x1 (or 16x1, or whatever) area of VRAM too. The GPU does not care, you can use another texture's pixels as a palette if you feel like it.
OK, so you said there's no z, how do you do z-buffering? You have a z-buffer, right… right?
Yeah, sure, we're not cavemen. We have an “ordering table” that is your Z-buffer, drawn back-to-front. If you want 256 levels of Z, you just allocate an array of 256 linked-list pointers, and then you put your polygon into the one corresponding to the correct right Z.
But, eh, what if my polygon is not completely flat in Z-space?
Hello?
Hello…?

Reproducible Builds summit 2026 to take place in Gothenburg

2026-08-12T00:00:00+00:00

This event is happening soon — see below for registration instructions!

We are extremely pleased to announce the upcoming Reproducible Builds summit, which will take place from September 22nd—24th 2026 in the city of Gothenburg, Sweden.

This year, we are thrilled to host the tenth edition of this exciting event, following the success of previous summits in various iconic locations around the world, including Vienna (2025), Hamburg (2023—2024), Venice (2022), Marrakesh (2019), Paris (2018), Berlin (2017), Berlin (2016) and Athens (2015).

If you’re excited about joining us this year, please make sure to read the event page which has more details about the event and location. As in previous years, we will be sending invitations to all those who attended our previous summit events or expressed interest to do so. However, even if you do not receive a personal invitation, please do email the organizers and we will find a way to accommodate you.

About the event

The Reproducible Builds Summit is a unique gathering that brings together attendees from diverse projects, united by a shared vision of advancing the Reproducible Builds effort. During this enriching event, participants will have the opportunity to engage in discussions, establish connections and exchange ideas to drive progress in this vital field. Our aim is to create an inclusive space that fosters collaboration, innovation and problem-solving.

Schedule

Although the exact content of the meeting will be shaped by the participants, the main goals will include:

Update & exchange about the status of reproducible builds in various projects.
Improve collaboration both between and inside projects.
Expand the scope and reach of reproducible builds to more projects.
Work together and hack on solutions.
Establish space for more strategic and long-term thinking than is possible in virtual channels.
Brainstorm designs on tools enabling users to get the most benefits from reproducible builds.
Discuss how reproducible builds will be usable and meaningful to users and developers alike.

Logs and minutes will be published after the meeting.

Location & date

Clarion Hotel Draken, Olof Palmes Plats 2, 413 30 Göteborg, Sweden. (OpenStreetMap, Google Maps)
September 22nd to September 24th 2026.

Registration instructions

Please reach out if you’d like to participate in hopefully interesting, inspiring and intense technical sessions about reproducible builds and beyond!

We look forward to what we anticipate to be yet another extraordinary event!

Free software activity in July 2026

2026-08-11T10:42:43+00:00

About 95% of my Debian contributions this month were sponsored by Freexian.

You can also support my work directly via Liberapay or GitHub Sponsors.

OpenSSH

Now that Ubuntu 26.04 LTS has been released, I’ve been getting back to the GSS-API key exchange package split in our OpenSSH packaging. Once I started testing my draft openssh-gssapi source package, I realized that I needed to make some changes in the main openssh source package first in order to support it. The dependency from openssh-server to openssh-client was awkward, as was the (related) fact that openssh-client contained shared documentation for other OpenSSH binary packages. After some thought, I created a new openssh-common binary package, moved shared documentation and the ssh-keygen program to that, and dropped dependencies on openssh-client which were no longer necessary (fixing #699473 and #1070098 in the process).

This caused a couple of regressions (#1141420 and #1141550) that I had to fix, and more subtly it also caused a number of autopkgtest regressions in other packages because openssh-client is no longer in base images as a result of a dependency from openssh-server. I believe I have fixes for all of these either pending review or merged (one of which I did in August rather than July):

I upgraded from 10.3p1 to 10.4p1, and in the process contributed a GSS-API option handling fix upstream.

I made openssh-ssh1’s package description more accurately describe the package, thanks to suggestions from Matthias Lang.

Installer team

With support from a Freexian customer, I reviewed, tested, edited, and merged a patch to add VLAN support. I described the details of what I did in a comment.

This has been vaguely on my to-do list since, er, about 2014, so it was very satisfying to get it sorted out.

Python packaging

New upstream versions:

cryptodatahub (fixing a build failure)
dep-logic
django-q
flufl.lock
more-itertools
multipart
pyasn1 (fixing CVE-2026-59884, CVE-2026-59885, and CVE-2026-59886)
pytest-rerunfailures
python-auditwheel
python-build
python-certifi
python-datamodel-code-generator (fixing a build failure, and an incompatibility with pydantic 2.13 that I reported upstream)
python-django-parler
python-httplib2
python-pgbouncer
python-time-machine
python-treq
python-typing-extensions
python-wheezy.template
storm
ubelt
webpy
zope.testing

Other build/test failures:

django-q: autopkgtest failure with Python 3.14 (reported upstream)
httpx: FTBFS: E assert [(‘uvicorn.ac…1.1 200 OK”’)] == [(‘httpx’, 20…1.1 200 OK”’)]
libntruprime: autopkgtest failures with Python 3.14
pygments: Handle None object before HTML escaping (fixed build failures in cmd2, gunicorn, python-inline-snapshot, and python-openapi-core)
python-authlib: some of tests/flask/test_oauth2/rfc9068/ failed
python-click: autopkgtest regression with pytest 9.1 (contributed upstream)
python-httplib2: FTBFS: ERROR tests/test_proxy.py - Failed: ‘forked’ not found in markers configuration option
python-maturin: Please upgrade goblin dependency to 0.10
python-memray: FTBFS on armhf (segfault)
python-mne: FTBFS: E pytest.PytestRemovedIn10Warning: Passing a non-Collection iterable to parametrize is deprecated (actually fixed in scikit-learn; contributed upstream)
python-softlayer: autopkgtest fails with python3-click 8.3.3 (contributed upstream)
python-urllib3: FAILED test/contrib/test_pyopenssl.py

I fixed some other bugs:

I adopted transaction for the Python team.

I attended the Python BoF at DebConf remotely, although a badly-timed fibre outage in the village I live in really didn’t help.

Code reviews

openssh: sshd-session built without crypt(), breaking UsePAM=no password auth (merged and uploaded)
openssh: Slovak debconf templates translation (merged and uploaded)
python-treq: Fails to build source after successful build (merged and uploaded)
python-better-exceptions: FTBFS: failing tests (sponsored upload for Seyed Mohamad Amin Modaresi)
yubihsm-connector: patch to make the build reproducible (merged and uploaded)

Other bits and pieces

Dan Poltawski pointed out in a Fediverse post that the project history didn’t list Sruthi as the current DPL. I fixed that, although it doesn’t look as though the fix is in the published version yet.

I upgraded yubihsm-shell to 2.8.0.

DebConf26 Local Team says goodbye

2026-08-10T21:50:00+00:00

On Saturday 25 July 2026, the annual Debian Developers and Contributors Conference came to a close. The Debian Press team would now like to share this personal and beautiful message from the Santa Fe Local Team.

Words from DC26 Local Team

DebConf26 is over, and those of us who were part of the Local Team are trying to return to “normality”, if such a thing exists after organizing a DebConf.

This event changed our lives and would not have been possible without the help of many great people.

We would especially like to thank everyone who became part of our extended local team. Our endless thanks go to Gunnar —who also instigated this whole adventure—, Santiago, Nattie, Stefano, and Olasd. Thank you for supporting and guiding us, sharing your experience, and helping us find solutions throughout the entire process.

It was also made possible thanks to the great work, strong support and patience of international teams: Fundraising, Bursaries, Content, Video, Treasury, Visa, Website, Accommodation, Front Desk, Cheese and Wine, Publicity as well as all the other teams and individuals who contributed. We apologize if we have forgotten to mention anyone; many people helped make this event possible.

Our deepest thanks also go to everyone who joined us in working on the event, especially Fer, José, and Julián, who showed great commitment and took responsibility for several important tasks.

We would also like to extend our gratitude to FICH, the Universidad Nacional del Litoral, the institutions, organizations, sponsors, suppliers, and everyone who contributed in one way or another to welcoming the Debian community to Santa Fe.

And finally, a very special thank you to our families, to whom we dedicated little time these past few weeks, who supported us on this adventure, enduring the exhaustion, the calls and messages at all hours, and the occasional stressful situation. Always giving us that much-needed, encouraging hug with so much love.

These were very intense weeks, during which we tried to give our best so that everyone could enjoy their stay and so that the Debian community had the necessary conditions to meet, work, share knowledge, and continue creating the magic that characterizes community life and the development of Debian.

As happens at every DebConf, there were difficulties, unexpected situations, and challenges that required us to improvise, learn, and perform a few juggling acts. There were also moments that will certainly remain as memorable anecdotes: the “antisocial room”, some gas heaters worthy of a museum, and newly unlocked powers for negotiating with suppliers.

We have no evidence, but also no doubt, that for many people the Conference Dinner was one of the best moments of the event.

A few ingredients we had hoped would happen naturally were missing, such as more wine nights and at least one in-person football match.

During the two weeks of DebConf, we experienced every kind of weather and a wide range of emotions. Above all, however, we saw people enjoying themselves and building friendships, which fills us with pride.

Thank you very much to everyone who came and helped DebConf26 leave such a beautiful mark on our hearts.

We hope our paths cross again somewhere in life.

Best regards,

Leonardo, Emmanuel, Mariano, Pablo, and Martín DebConf26 Local Team

About Debian

The Debian Project was founded in 1993 by Ian Murdock to be a truly free community project. Since then the project has grown to be one of the largest and most influential Open Source projects. Thousands of volunteers from all over the world work together to create and maintain Debian software. Available in 70 languages, and supporting a huge range of computer types, Debian calls itself the universal operating system.

About DebConf

DebConf is the Debian Project's developer conference. In addition to a full schedule of technical, social and policy talks, DebConf provides an opportunity for developers, contributors and other interested people to meet in person and work together more closely. It has taken place annually since 2000 in locations as varied as Scotland, Bosnia and Herzegovina, India, Korea, France. More information about DebConf is available from https://debconf.org/.

Contact Information

For further information, please visit the DebConf26 web page at https://debconf26.debconf.org/ or send mail to press@debian.org.

time-delayed scifi roundup feed

2026-08-10T14:44:31+00:00

I enjoy reading The Guardian's monthly round-up of new SF novels, which can be found in their Science Fiction Books section, and can also be read via feed. Since the round-up is of new books, at the time the round-up is published they're usually only available in hardback.

When it comes to choosing a book to read, these days I am tending towards paperbacks: I've largely ran out of room for hardbacks. So I decided to apply a time delay to their feed. Six months is roughly enough that a book mentioned in a round-up should be shortly available in paperback.

The first obstacle was that The Guardian only publish roughly the last six months of articles in their feed, and so the posts I want have disappeared. However, my Feed Reader (FreshRSS) had older copies stored in its database, and I am able to re-publish those using User Queries. (This also gives me an opportunity to filter out non-roundup articles from the Guardian's feed).

It's then a nice short piece of scripting (this time, using Ruby) to filter the republished feed on the publication date. To make the most recent articles appear new, I also modify the metadata for filtered entries to appear 6 months newer than they are.

#!/usr/bin/ruby
require 'rss'

# replace with the user query feed URI
uri       = 'https://www.theguardian.com/books/science-fiction/rss'
now       = Time.now
sixMonths = 6 * 30 * 24 * 60 * 60
feed      = RSS::Parser.parse(uri)

feed.items.select! do |item|
  item.date + sixMonths < now
end
feed.items.collect! do |item|
  item.date += sixMonths
  item
end

puts "Content-Type: text/xml\r\n\r"
puts feed

I stuck that up on my private web server, subscribed to it in my FreshRSS and voila, a time-delayed list of books to read, most likely available in paperback.

PGP Keysigning on Linux Plumbers and OpenSource Summit Europe 2026

2026-08-10T14:37:00+00:00

I'm going to this year's LPC and Open Source Summit Europe ðŸ¥³.

I will organize sessions on two days after the conference program to exchange PGP fingerprints for keysigning to improve the kernel's web-of-trust (but of course everyone is welcome).

For details see my announcement on LKML. Note the registration deadline at 2026-09-27 08:00 UTC.

Managing virtualenvs with a little bash

2026-08-09T20:00:00+00:00

When you need to install something directly from PyPI, Python virtualenvs have been my go-to for over a decade.

A quick virtualenv intro

Most of my readers are probably already familiar with virtualenvs, but for completeness, I'll give you a brief introduction. A virtualenv (short for "virtual environment") is an isolated distribution of Python packages, where you can independently install packages without disturbing your system packages or other virtualenvs.

You can set one up like this, assuming you are using Python 3.3 or higher:

python3 -m venv ~/.venv/my-virtualenv

The directory specified here is just a convention. I keep all my virtualenvs in the .venv folder in my home directory, but you can pick whatever location you like.

To use the virtualenv, you must activate it:

source ~/.venv/my-virtualenv/bin/activate

This activation script is a special shell script that configures your current shell, pointing at all the right paths in order to use the virtual environment. source runs this script in your current shell session to set it up. You will notice that this adds (my-virtualenv) to the beginning of your shell prompt, reminding you that the "my-virtualenv" virtualenv is active. Now when you pip install amazing-package, the software will only be available in this virtual environment.

When you're done, you can deactivate it like so:

deactivate

Wonderful!

Managing many virtualenvs gets annoying

Over time, I end up accumulating many virtualenvs, which can become harder to manage. Maybe something like this:

$ ls ~/.venv/
my-virtualenv cool-project snakes-ahoy

I also don't want to type source ~/.venv/my-virtualenv/bin/activate every time I use the virtualenv, because it gets very repetitive—only the name of the venv is really needed.

But luckily, we can write a little bit of bash to make managing this less annoying. (Or you can use one of many Python developer tools that are designed to manage this, like pipx, but when I merely want to consume Python software, I might not have a development environment set up. So that's beyond the scope of this post!)

If you add the following shell function to your ~/.bashrc or ~/.bash_aliases file, it will nicely wrap our activation command:

setup-venv() {
        source "$HOME/.venv/$1/bin/activate"
}

Now all we need to run is

setup-venv my-virtualenv

So much quicker!

Spicing it up with tab completion

The first thing I noticed after writing this wrapper was that I started hitting tab on the virtual environment name, but... nothing happened. Wouldn't it be nice to know what virtualenvs I had available, and to not have to type out the whole long thing?

Well, we can write it ourselves 😄

If for some reason you don't already have bash completion installed, on a Debian-based system, you will need to install it with

apt install bash-completion

In order to configure our bash completion, we will create a new file, /etc/bash_completion.d/venv, with the following contents:

_list_venvs()
{
    local cur prev opts
    COMPREPLY=()
    cur="${COMP_WORDS[COMP_CWORD]}"
    prev="${COMP_WORDS[COMP_CWORD-1]}"
    opts=$(find $HOME/.venv/ -mindepth 1 -maxdepth 1 -type d -printf "%f ")

    COMPREPLY=( $(compgen -W "${opts}" -- ${cur}) )
    return 0
}
complete -F _list_venvs setup-venv

This file defines another shell function order to determine how to autocomplete the options for our setup-venv function.

$opts is where we define the options for our function. We generate it with a find command—looking at the .venv folder in the current user's home directory, then only including child folders (excluding the current directory itself, .venv, in our results) by using the min/max depth and type arguments, and printing just the individual directory names, deliminated by spaces using our print formatter.

Everything else is the standard scaffolding required to use bash completions.

Once you save this file and reload your shell, you'll see that you are able to use completions as expected!

setup-venv <tab>
my-virtualenv cool-project snakes-ahoy

setup-venv s<tab>
setup-venv snakes-ahoy

Complaints, comments, questions?

Hope this was helpful! If it wasn't, that's too bad. But don't worry—you can safely ignore this post.

Reproducible Builds in July 2026

2026-08-09T19:12:10+00:00

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

In our reports, we try to outline the most important things that we have been up to over the past month. As a quick recap about what problem our project intends to solve, whilst anyone may inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries. The motivation behind the reproducible builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised or not.

If you are interested in contributing to the project, please visit the Contribute page on our website.

In this month’s report, we cover:

Tool development

diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made the following changes, including preparing and uploading versions 324, 325 and 326 to Debian:

Fix tests to work with zipdetails 4.0008. (#1141359)
Bump debhelper compatibility level to 13. […]
Update copyright years. […]

In addition, Paul Spooren made changes to allow trailing garbage in Gzip files […] and Vagrant Cascadian added an external tool reference for the pedump binary to use the mono package under GNU Guix. […]

disorderfs is our FUSE-based filesystem that deliberately introduces non-determinism into system calls to reliably flush out reproducibility issues. This month, Christelle Gloor added the option to sort by ctime as returned by the lstat(2) syscall. […], which Chris Lamb uploaded whilst bumping the Standards-Version to version 4.7.4 […]. Bernhard Wiedemann also updated disorderfs to version 0.7.0 in openSUSE.

Yet again, there were a number of improvements made to our website this month as well. For example, Chris Lamb, by request of Digital Ocean, changed the target of a referral link so that they can manage incoming referrers […] and pushed a number of changes to the Tools page […].

Distribution work

In Debian this month, 32 reviews of Debian packages were added, 26 were updated and a total of 21 were removed this month, adding to our extensive knowledge about identified issues.

A number of issue types were added by Chris Lamb, including:

python_towncrier_build_date […][…]
log_files_installed_in_package […]
fontforge_varies_by_timezone […][…]

Chris also added a further note for the build_date_in_manpage_generated_by_spf13_cobra issue. […]

In addition, there is a new page showing verification rebuilds of OpenWrt APK packages and firmware images, powered by rebuilderd:

Three new scholarly papers

Yan Li, Nan Jiang, Qihang Zhou, Shaowen Xu, Yamin Xie and Xiaoqi Jia of the Chinese Academy of Sciences published a paper titled VCAligner: Aligning Source Distribution Versions with Upstream Git Commits to Secure Supply Chain:

We present VCAligner, a content-based alignment methodology that constructs inverted indexes over VCS histories to precisely map released artifacts to their originating commits, independent of fragile version tags. We evaluated VCAligner on a dataset of 2,984 verifiable PyPI packages derived from the 4,000 most-downloaded projects linked to public GitHub upstreams. Our results reveal a critical weakness in conventional tag-based heuristics: while they appear effective on 85% of the dataset, the residual 15% failure rate generates a catastrophic downstream audit workload of over 10.3 million commits. In contrast, VCAligner reduces this burden by two orders of magnitude (≈ 158×), bounding the total workload to under 65,000 commits. Furthermore, we provide the large-scale characterization of “Packaging Noise,” classifying artifact divergence into structural additions (Path Phantoms) and content mutations (Blob Phantoms), thereby isolating the distinct attack surfaces of malicious injection and code tampering.

Jens Dietrich and Spencer Sun from the Victoria University of Wellington together with Tim W. White and Behnaz Hassanshahi from Oracle Inc pre-published their paper No Snake Oil: Verifying Python Package Builds (PDF):

Python has become the default language for interacting with AI, with packages being distributed through registries like the Python Package Index (PyPI). This creates a need to analyse supply chains comprising such packages. One such analysis is to rebuild packages in order to identify compromised builds injecting malware. Independent rebuilds in hardened environments have the added advantage that they can generate and record provenance in order to increase the trustworthiness of packages. Two tools that are designed to automate such rebuilds and run them at scale are macaron and oss-rebuild. We study 12,180 popular releases from PyPI and find that the byte-for-byte equivalence rate is generally low. We analyse the reasons why they produce different wheels, and find that equivalence between the original and rebuilt wheels can often still be established, preserving most of the guarantees users expect from rebuildable releases. We present and evaluate daleq4py, a tool to establish the equivalence of Python wheels through the kernel of a normalisation function that is based on provenance-preserving datalog rules. Experimental results show that daleq4py substantially expands the set of rebuilds that can be accepted as equivalent. Although only 15.4% of macaron rebuilds and 19.1% of oss-rebuild rebuilds are byte-for-byte identical to the published PyPI wheels, daleq4py establishes wheel equivalence for 60.2% and 78.9% of source-equivalent rebuilds, respectively.

Denise Nanni, Julien Malka, Stefano Zacchiroli and Théo Zimmermann from Télécom Paris together with Gabriele D’Angelo from the University of Bologna pre-published their paper Understanding Build Reproducibility in the F-Droid Ecosystem (PDF), which was accepted at the 2026 ACM Conference on Reproducibility and Replicability:

The security of open source applications benefits considerably from the possibility of rebuilding their source and verifying the output. F-Droid, a prominent distribution for open source Android applications, systematically rebuilds them from source and tests their bitwise reproducibility at app publishing time. However, F-Droid offers no guarantee that app reproducibility will continue to hold in the future. As software ecosystems evolve, reproducibility may degrade, with potential negative consequences for software preservation and security. We present the first empirical study of build reproducibility in the F-Droid app ecosystem. Analyzing historical reproducibility logs, we find that the overall bitwise reproducibility rate has been steadily increasing over time (as new versions of apps are published). We then evaluate how reproducibility holds in time for fixed app versions, by attempting to rebuild 18 904 app versions that F-Droid had previously confirmed bitwise reproducible, published between September 2018 and February 2026, achieving an 83% rebuild success rate, and identify missing dependencies as the dominant cause of failure, accounting for 76% of non-rebuildable cases. Among successfully rebuilt apps, 94% are also bitwise reproducible-i.e., they still yield bitwise identical artifacts upon rebuild. Together, these results show that while bitwise reproducibility largely holds for apps that can be rebuilt, rebuildability itself is highly sensitive to temporal decay.

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 applicable or possible. This month, we wrote a large number of such patches, including:

openSUSE monthly
Arnout Engelen:
- ivy
- pekko-grpc
- sbt-ivy
- scala
Bernhard M. Wiedemann:
Chris Lamb:
- #1141505 filed against golang-github-tidwall-wal.
- #1141506 filed against lightproof.
- #1141582 filed against libslow5lib.
- #1141687 filed against siso.
- #1141841 filed against grout.
- #1142126 filed against libpsl.
- #1142492 filed against node-grunt-contrib-internal.
- #1142495 filed against fontforge.
- #1142496 filed against spopt.
- #1142887 filed against go-dlib.
- #1143147 filed against towncrier.
Jochen Sprickerhof:
- #1141412 filed against python-sphinx-chango.
- #1141553 filed against gasnet.
- #1141577 filed against yubihsm-connector.
- #1141663 filed against dh-fortran.
- #1142000 filed against watcher.
- #1142001 filed against rakudo.
- #1142128 filed against kf6-breeze-icons.
- #1142141 filed against oxygen-icons.
- #1142256 filed against gnu-apl.
- #1142513 filed against barvinok.
- #1143169 filed against ecbuild.

Misc news

On our mailing list this month, Colin Winter of Markovian Protocol wrote to our mailing list on the topic of Reproducible verification for retained logs:

Reproducible builds remove trust in the builder: anyone re-derives the same artifact from the same source, byte for byte. The same shape applies one layer over, to a retained record. Most record-keeping regimes (the EU AI Act’s Article 12 logging is the current example) require that events be recorded and logs retained, but not that a retained log be verifiable, by a party who was not present, as unaltered and existing when claimed. That leaves an integrity obligation resting on trusting the party being audited.

(Full thread)

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

My Debian Activities in July 2026

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

Debian LTS/ELTS

This was my hundred-forty-fifth 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:

[DSA 6402-1] hplip security update to fix two CVEs in Trixie related to privilege escalation and/or arbitrary code execution. I sent the debdiff to the security team, which resulted in this DSA.
[#1142351] trixie-pu of libnfs has been uploaded.
[DLA 4689-1] libnfs security update to fix one CVE in Bookworm and Bullseye related to an integer overflow.
[DLA 4699-1] hplip security update to fix two CVEs in Bookworm and Bullseye related to privilege escalation and/or arbitrary code execution.
[ELA-1775-1] libnfs gimp security update to fix one CVE in Buster and Stretch related to an integer overflow.
[ELA-1784-1] hplip security update to fix two CVEs in Buster and Stretch related to privilege escalation and/or arbitrary code execution.

Unfortunately the number of assigned hours was rather low this month. So besides doing some days of FD at the end of the month, where I also had to process a new package list for ELTS, and a review of the rsync package (prepared by Sylvain), not much happened here.

Debian Printing

This month I uploaded a new upstream versions:

… hplip to unstable.
… foomatic-db to unstable.

Besides the package upload, I also took care of some older bugs of hplip.

This work is generously funded by Freexian!

Debian Lomiri

This month I continued the upload of lomiri packages with new upstream versions. Thanks to the help of my other colleagues, this project could be finished now.

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:

… fxload to unstable.
… indi-orion-ssg3 to unstable.
… calceph to unstable (sponsored upload).

Debian IoT

Unfortunately I had no time to work in this category this month.

Debian Mobcom

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

… libgsm to unstable.
… libosmocore to unstable.
… libosmo-cc to unstable.

Next month I intend to upload new upstream versions of all Osmocom packages. As far as I can tell, these uploads will happen without soname changes. I like that :-).

misc

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

… usb-modeswitch to unstable.
… ta-lib to unstable.
… lua-geoip to unstable.
… lua-systemd to unstable.
… displaylink-driver to unstable.
… nuspell to unstable.

Kai Stephens (Barkley Walsh) & British Democrats in Clacton by-election hustings

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

On the right of British politics, there is some argument about which group is closest to the Nazi party. Socialist Worker recently published an article alleging Reform UK is willing to share a stage with Nazis.

On the evening of 6 August 2026, candidates in the Clacton by-election gathered for a hustings-style debate at the Clacton Town Hall.

There were tense moments when Kai Stephens (Barkley Walsh) expressed concerns about another candidate, Attieh Fard, who was born in Iran but acquired British citizenship. There are thirty four candidates contesting the by-election and at least one of the Australian candidates does not hold British citizenship at all as it is not required to hold a seat in Westminster.

Stephens elaborated on his comments, explaining that it is about race. The Australians and anybody with English, Scottish, Welsh or Irish ancestry are considered, by the British Democrats, to be a superior race. Never mind the fact that Iranians have invented low cost drones that have brought superpowers to their knees in various conflicts around the world.

Stephens himself admitted being twenty percent German. Then again, the British royal family have a lot of German cousins too.

One of the Australian candidates simply asked if anybody remembered where the late Prince Philip was born.

In the Nazi era, the hyper-focus on race was equivalent to the arguments put forward by Kai Stephens.

Germans were expected to apply for an Aryan Certificate (Abstammungsnachweis) to provide proof of their ancestry. To work in the public service, it was necessary to prove at least three generations of Aryan blood. To join the Nazi party or be part of the fearsome SS, it was necessary to provide proof of Aryan blood back to at least the year 1800.

Kai Stephens' concern about Attieh Fard's birthplace, as he explained it to us on stage on 6 August 2026, appears to be analogous to the motivation behind the Aryan Certificate.

On 25 April 2017, the Fellowship elected Daniel Pocock to represent them to the FSFE (fake FSF) in Berlin. When the Germans realised that 25 April is ANZAC Day and Mr Pocock's great-grandfather was an ANZAC, they decided to remove elections from the FSFE constitution. Mr Pocock pointed out that Germans had behaved like this before. The Germans asked Berlin Police to prevent Mr Pocock calling them Nazis. German police prosecute approximately 20,000 people for criminal speech each year. In the case of Mr Pocock's uncannily accurate Nazi comparisons, Berlin police wrote to Mr Pocock, in German, and told him they will not stop him calling the FSFE Nazis.

Mr Pocock's birthday, 9 November, is the anniversary of the Kristallnacht.

DebConf26 closes in Santa Fe and DebConf27 announced

2026-08-06T21:50:00+00:00

On Saturday 25 July 2026, the annual Debian Developers and Contributors Conference came to a close. Over 270 attendees representing 35 countries from around the world came together for a combined 90 events (including some which took place during the DebCamp) including more than 27 Talks, 21 Short Talks, 29 Birds of a Feather sessions ("BoF" – informal meeting between developers and users), 8 workshops, and activities in support of furthering our distribution and free software, learning from our mentors and peers, building our community, and having a bit of fun.

The conference was preceded by the annual DebCamp hacking session held 13 through 19 July where Debian Developers and Contributors convened to focus on their individual Debian-related projects or work in team sprints geared toward in-person collaboration in developing Debian.

As has been the case for several years, a special effort has been made to welcome newcomers and help them become familiar with Debian and DebConf by organizing a sprint "New Contributors Onboarding" every day of Debcamp, followed more informally by mentorship during DebConf. Half a dozen new contributors joined the sessions and learned about Debian, free software, packaging and much more.

This year, a week-long DebCamp session was dedicated to auditing, patching, and modernizing the Go ecosystem in Debian and enable the transition triggered by the recent upload of dh-golang enabling GO111MODULE=on by default in Experimental.

In order to make the conference more accessible for local participants, a local language track was included in the schedule for talks in Spanish, as was done at DebConf19 in Brazil.

The actual Debian Developers Conference started on Monday 20 July 2026.

In addition to the traditional "Bits from the DPL" talk, the continuous key-signing party, lightning talks, and the announcement of next year's DebConf27, there were several update sessions shared by internal projects and teams.

Many of the hosted discussion sessions were presented by our technical core teams with the usual and useful "Meet the Technical Committee", three talks about Linux Kernel, early boot and improving Debian’s kernel and installer support for Chromebooks, and about twenty BoFs and talks about Debian packaging policy, Debian infrastructure, security and privacy.

This year, and echoing ongoing discussions within the Free Software community, Artificial Intelligence and Age Verification have been the subject of several talks. The Python, Perl, Ruby, Go, and Rust programming language teams also shared updates on their work and efforts.

More than 17 BoFs and talks about community, diversity, and local outreach highlighted the work of various teams involved in not just the technical but also the social aspect of our community

The schedule was updated each day with planned and ad hoc activities introduced by attendees over the course of the conference. Several traditional activities took place: a poetry performance, the traditional Cheese and Wine party, the Group Photos, and the Day Trip.

For those who were not able to attend, most of the talks and sessions were broadcasted live and recorded. One can find the seventy hours of recorded videos available via the conference schedule, or alternatively through this link.

Almost all of the sessions facilitated remote participation via IRC and Matrix messaging apps or online collaborative text documents which allowed remote attendees to "be in the room" and ask questions or share comments with the speaker or assembled audience. DebConf26 saw over 341 T-shirts, a day trip, and up to 130 meals planned per day.

All of these events, activities, conversations, and streams coupled with our love, interest, and participation in Debian and F/OSS certainly made this conference an overall success both here in Santa Fe, Argentina and online around the world.

The DebConf26 website will remain active for archival purposes and will continue to offer links to the presentations and videos of talks and events.

Next year, DebConf27 will be held in Asahikawa, Hokkaido, Japan, from Sunday September 5th to Saturday September 11th, 2027. As tradition follows before the next DebConf the local organizers in Japan will start the conference activities with DebCamp with a particular focus on individual and team work towards improving the distribution.

DebConf is committed to a safe and welcome environment for all participants. See the web page about the Code of Conduct on the DebConf26 website for more details on this.

Debian thanks the commitment of numerous sponsors to support DebConf26, particularly our Platinum Sponsors: Infomaniak, and Proxmox, and our Gold Sponsors : Freexian, and Viridien.

We also wish to thank our Video and Infrastructure teams, the DebConf26 and DebConf committees, our host nation of Argentina, and each and every person who helped contribute to this event and to Debian overall. Thank you all for your work in helping Debian continue to be "The Universal Operating System".

See you next year!

About Debian

About DebConf

About Infomaniak

Infomaniak is an independent, employee-owned Swiss technology company that designs, develops, and operates its own cloud infrastructure and digital services entirely in Switzerland. With over 300 employees — more than 70% engineers and developers — the company reinvests all profits into R&D. Its public cloud is built on OpenStack, with managed Kubernetes, Database as a Service, object storage, and sovereign AI services accessible via OpenAI-compatible APIs, all running on its own Swiss infrastructure. Infomaniak also develops a sovereign collaborative suite — messaging, email, storage, online office tools, videoconferencing, and a built-in AI assistant — developed in-house and as a privacy-respecting solution to proprietary platforms. Open source is central to how Infomaniak operates. Its latest data center (D4) runs on 100% renewable energy and uses no traditional cooling: all the heat generated by its servers is captured and fed into Geneva's district heating network, supplying up to 6,000 homes in winter and hot water year-round. The entire project has been documented and open-sourced at d4project.org.

About Proxmox

Proxmox develops powerful, yet easy-to-use open-source server solutions. The comprehensive open-source ecosystem is designed to manage divers IT landscapes, from single servers to large-scale distributed data centers. Our unified platform integrates server virtualization, easy backup, and rock-solid email security ensuring seamless interoperability across the entire portfolio. With the Proxmox Datacenter Manager, the ecosystem also offers a "single pane of glass" for centralized management across different locations. Since 2005, all Proxmox solutions have been built on the rock-solid Debian platform. We are proud to return to DebConf26 as a sponsor because the Debian community provides the foundation that makes our work possible. We believe in keeping IT simple, open, and under your control.

Contact Information

For further information, please visit the DebConf26 web page at https://debconf26.debconf.org/ or send mail to press@debian.org.

TV Control etc

2026-08-06T04:01:37+00:00

In 2008 I wrote a blog post “The Problem is Too Many Remote Controls” [1] about the issues of controlling a TV and related things. It recently got some comments on Mastodon so I think it’s time for an update.

The first issue I raised was “Now it’s not uncommon to have separate remote controls for the TV, VCR, DVD player, and the Cable TV box – a total of four remote controls” which seems to have alleviated. VCRs seem to have almost entirely gone away. The VHS Wikipedia page [2] is worth reading for everyone who hasn’t seen a VCR in operation, which I expect to be more than a few readers now and an increasing number over the next 18 years. I personally don’t have Cable TV, I own a DVD player which isn’t connected to my TV because I haven’t used it for years, I don’t own a VCR, and I don’t watch free to air TV. So I have one remote control for the TV which I use for Netflix and sometimes YouTube.

When viewing YouTube on TV there are significantly more adverts and longer adverts. I presume that is because installing an ad-blocker on my TV isn’t a viable option for me and it’s a total impossibility for most users. Generally my desktop PC is a much better platform for YouTube than my TV, it has a better quality display, is more user friendly (my previous post addressed the difficulty of getting to the data source that’s desired), and doesn’t require entering search terms via a slow on-screen keyboard. Netflix on Linux is limited to 720p at low bitrate which is obviously of low visual quality while on the TV it’s in 4K. I have Netflix so I use that only on the TV.

In my previous post I wrote a thought experiment on how to use a cheap laptop ($500 at the time – equivalent to $777 in 2025 money according to the Reserve Bank of Australia) to control a $5000 TV ($7770 in 2025 money). Now you can buy a new 65″ 4K TV for under $800 and a new laptop capable of 4K output for under $400 so the options are very different. For a $800 TV the manufacturer isn’t going to develop a remote control interface and Google (who develops the software the TVs run) won’t do it because it could reduce their advertising revenue. But a typical home user could setup a cheap laptop connected to their TV via HDMI providing a familiar and efficient user interface for themselves and visitors. For a Windows laptop 4K Netflix should work and for a Linux laptop the options of a laptop for everything apart from Netflix and the TV for Netflix are bearable, two controls are worse than one but better than the 3+ that used to be common.

In my previous post I raised the issue that “it’s often the case that you don’t want to stop watching one show while trying to find another”. This is still an unsolved problem and is not addressed in modern software. I am not aware of a Linux music player that supports such functionality and this would be much easier for a music player than for a video player where the screen would have to be shared between the interface for finding the next thing to play and the space for playing the end of the current one. Maybe I should file a bunch of wishlist bugs against music players asking for this.

I suggested that “cable modem” and “cable TV box” could be integrated into a single device. That has not happened, in fact it’s got worse. A relative who has Foxtel has a cable modem, a cable TV box, and a Wifi AP with VOIP to provide landline phone service and to make it more exciting the latter two both have bugs that require a periodic hardware reset to fix. Hopefully cable TV will go away in the next 18 years.

Regular PCs have become less noisy in recent years. I am currently using a HP Z640 to write this post and I have HP Z840 and HP Z4G4 systems behind me running as servers and the background noise is still very low. The allegedly 8K TV [3] that I have in my lounge room has cooling fans that make more noise than those three high-end HP computers combined. Using a quiet PC like one of those HP systems to drive a TV is a very viable option and I did just that for a couple of years. Kogan has currently got a selection of refurbished Lenovo ThinkStation systems on sale for under $400, they are quiet and would do well for this, it’s also nice that Kogan is selling systems with ECC RAM at home user prices.

TV does seem to be going away. YouTube and streaming services seem to get more watching time and many people don’t use TV at all.

Since my previous post the number of streaming services has increased so torrenting offers increasing benefits as no-one wants to subscribe to 6+ services. For anyone who wants to get all the content that interests them while paying the user interface situation is much worse now than it used to be in 2008.

If you use KDE on a PC then the kconnect program allows a phone to be used to remotely control some aspects of a PC and has a good interface for pause/resume of a video and seeking 10 seconds forwards/backwards. The interface for controlling volume is hard to get to and doesn’t work on my installation. If you want to use a keyboard to start something playing and then a phone for pause control then kdeconnect is a decent option. A comment on my previous post by Michael Croes raised the issue of remote control which is now a solvable problem. Justin also wrote a comment suggesting a Nokia N800 as a remote.

Jason suggested a programmable remote, which would be a good option for a power user and a viable option for someone setting things up for their grandparents. But the amount of pain is greater than I’m interested in as lounge room TV isn’t an important thing to me. It may appeal to more people than having a dedicated lounge room PC though.

Subscription Bombing • Email under Attack

2026-08-06T00:17:35+00:00

This post is an unpublished review for Subscription Bombing • Email under Attack

One of the most important inputs one can have when designing a response strategy against a security attack is a good characterization. This article describes a relatively newly described attack mode (subscription bombing), hypothetizes on the motivations that can lie behind it, and presents some countermeasures that can be taken by different actors to reduce its impact.

At its core, suscription bombing is a classical reflection attack: it uses a third party service so that the answer to a relatively simple request is amplified and results in a distributed denial of service (DDoS) for the victim. And, as with most DDoS attacks, its effectivity lies in that there is not much a person can do against traffic coming from seemingly random different providers all around the world.

The core differentiatof for subscription bombing is that the attack’s victim is not a network port, but an individual’s e-mail address. The attacker builds a database of service providers that allow interested users to sign up for newsletter on their activities, or a mailing list, or even just to create a new account on a given Web system. This action will generate a (seemingly legitimate) confirmation mail sent to the victim. But the attacker scripts together hundreds of thousands of such request, creating a deluge of confirmation mails sent to the unsuspecting victim.

The authors explain the goals an attacker might pursue by performing this kind of attack. They suppose this can be due to harassment (a disgruntled employee being denied a salary raise, a political adversary, or even a romantic ex-partner wanting to inconvenience the victim’s use of their e-mail). More worryingly, the attack can be used as a distraction: by sending a high volume of mails in a controlled timeframe, the attacker can reduce the probability of the victim noticing a specific attack warning them of, i.e., financial fraud, unwanted purchases, or break-in attempts into their accounts. Attacks targetting mailboxes at private mail servers can also lead to overloading an account’s limit, causing it to reject mails after the attack is delivered and before the folder is cleaned. And it can also pave the way for follow-up, targetted deception attacks, where the attackers call the victim pretending to be the company’s IT department, and get them to install a remote desktop monitoring and management tool, with which they can effectively seize control of the victim’s data.

To do this, they present a study they made over 24 cases of victims, from which 47,970 total e-mails were received between October and December 2024, with individual attacks receiving between 81 and 3,387 e-mails per hour, from where they presented several descriptive analysis.

The authors explored cyber criminal’s offers on underground websites, comparing flooding services and pricing schemes.

Finally, mitigation strategies are discussed. Mitigation is quite problematic, as none of the mail servers is acting in either a hostile way or lacking permissions — they are performing just the task they should. The authors suggest four mitigation strategies for mail server operators to reduce the burden on their users, although none of them is easily automatizab (rate-limit the number of emails a given inbox can receive from previously unseen senders; educate users about this kind of attacks; group similar newsletter or account reset mails during active attacks; and automatically unsubscribe or bounce newsletter messages when a surge is detected). They also recommend newsletter providers and services accepting the unrestricted creation of user accounts to provide some hardening to increase the effort wrongdoers need to spend to abuse their services, such as requiring CAPTCHAs or requiring users to take several steps before requesting a subscription, although they recognize this adds friction to the process providers are most interested in providing; filtering and triaging known-good and known-bad domains, although this is hard to implement on a preemptive fashion, and adhering to easy unsubscription standards, such as easily identifiable headers with which mass unsubscription could be performed more easily victims, instead of hunting for the right places to click, potentially even in mails written in an unknown language.

The described problem is interesting, and properly tackling it can be a game changer for many users who will suffer this kind of abuse, and the article is easy to read and soundly supports its claims.

Yes-yes, still alive!

2026-08-05T17:34:00+00:00

I am not sure what happened, but my interests have changed significantly, and… I haven’t blogged, I haven’t done any open source work, and didn’t even process any pictures for the entire year. Not because anything went bad, just… new stuff, new interests, life changes.

However, still alive, and still struggling with sports, and with sleep :)

On the positive side, on a recent mid-length flight, I thought — I haven’t done any work on Corydalis, since last year I closed quite of a few of my “must have” features, so probably, nothing else to do for now, right? I opened an editor and started thinking about ideas, and surprised! One hour later, I had written down enough ideas for a couple of months of work. So now just need to find the time… but can’t wait for the planned things!

Stay well!

Gnome refusing to suspend

2026-08-05T07:57:52+00:00

I'm tired, I want to do go bed. I click "sleep" on gnome shell, nothing happens.

Swearwords.

I want to go to bed. I might have want to put my laptop in a bag and run to catch a train. I hate when this happens.

systemd-inhibit --list --mode=block doesn't help much:

$ systemd-inhibit --list --mode=block
WHO    UID  USER   PID  COMM            WHAT                                                     WHY                        MODE
enrico 1000 enrico 3042 gsd-power       handle-lid-switch                                        External monitor attachedâ€¦ block
enrico 1000 enrico 3037 gsd-media-keys  handle-power-key:handle-suspend-key:handle-hibernate-key GNOME handling keypresses  block
enrico 1000 enrico 2878 gnome-session-b sleep                                                    user session inhibited     block

After much googling I found out about gnome-session-inhibit:

$ gnome-session-inhibit  --list
mutter: idle-inhibit (idle)
/usr/lib/chromium/chromium: Playing audio (suspend)

Found the right tab in chromium, paused playing, sleep works again.

My sleep was a good half an hour overdue, and all I got for it was to write this blog post.

Of course Gnome could have shown me its inhibitor list instead of doing nothing, since it has that information, but it didn't.

What I really would expect is that if I intentionally click a suspend button, audio and video playing wouldn't inhibit the suspend. Maybe in a future version of Gnome?

Monitors for Work

2026-08-04T22:41:18+00:00

The Corporate Monitor Issue

Some time ago I worked in the IT department of a company that had a corporate standard of two 27″ FUllHD (either 1920*1080 or 1920*1200) monitors for the desktop. I was pushing to make the standard be one 32″ 4K monitor or the two cheaper monitors. They ended up making one 27″ 4K monitor an option which was still a better option for many users than two FullHD monitors due to having twice the pixels even though it had half the screen area. It was a surprise to me when hardly anyone took up that option.

One man who worked there brought a wide curved monitor from home and ran with one of the FullHD monitors on each side of that. As an employee in the IT department I had concerns about expensive personal equipment being used in the office regarding who’s going to pay the bill if it gets broken. But I was assured that it was his old monitor that he didn’t need after buying a better one for gaming at home and he wouldn’t be too upset if something happened to it.

This isn’t the only time I’ve witnessed such problems of companies paying large salaries for skilled people and providing poor equipment for them to do the work. One previous time I raised a OH&S issue because the outdated monitors were so blurry but the company determined that the monitors wouldn’t cause health problems and spending $150 per employee on better replacements was a waste of money.

Computer hardware tends to become cheaper over time and one thing that has become really cheap recently is portable monitors. Kogan has a 15.6″ FullHD monitor with USB-C and mini-HDMI inputs for $89 [1]. It wouldn’t be difficult for someone to put one of those on each side of the monitor or monitors that their employer provides and put them in a desk drawer at the end of the day to minimise risk. The same Kogan page has a 16″ monitor with 2560*1600 resolution for $189.

Company Ownership

I previously wrote about the potential benefits to companies in not owning all those keyboards, mice, and headsets when they could just give each employee the money and have them buy their own [2]. I don’t think we are at the stage where that can be applied to monitors as the cheapest price for a decent monitor is about $500 which takes it out of the disposable price range that keyboards and mice are in. Also from an IT support perspective there are real support issues with monitors and cables having compatibility issues. But paying small amounts of money to reimburse employees who buy cheap portable monitors to supplement their main monitor is a more reasonable option. For some people that will allow noteworthy improvements in work performance.

Who Will it Help?

I don’t think that adding such portable monitors will directly help the majority of workers. I think that to maximise performance and efficiency we need to chase the long tail of improvements. Big monitors, really big monitors (65″ at a larger distance), multiple monitors, standing desks, and whatever else people want.

There was some research from Microsoft some years ago (back when 27″ was a really big monitor) showing that some tasks had a 50% increase in performance with a larger monitor. Now that 27″ is about the smallest monitor size commonly available the potential for improvement is reduced. Probably most workers now already have monitors that provide the benefits to them that the “big monitors” in Microsoft research provided. But there will always be some portion of the user base who will benefit. If you can get a 50% performance boost for 1% of the users that’s really worth doing. If you can get a 0.5% benefit for 100% of the users that is also worth doing and will theoretically give equal benefits.

Costs of Employees

It is claimed that the total cost of an employee including all overheads of management and providing office facilities etc amounts to twice their base salary. If that is the case then a minimum wage employee in Australia costs $100k per year, someone at the low end of the IT pay scale costs $200k, and someone at the high end of the IT scale is around $400k. It seems clearly worthwhile to spend $1000 in hardware purchases for a $100k employee who declares that it will really help their work, anything which is noticeable to the user is going to be more than a 1% difference in performance.

For someone at the high end of the IT pay scale spending $40,000 on hardware to improve their performance could pay for itself. This is not only due to direct return on investment but because the people who do such work are often in key roles in important projects. If there’s too much work for one person on minimum wage to do then you just hire another person. You can’t hire another senior IT person and have them just do the work, it can take months to get up to speed.

But as management in corporations seems unable to recognise this cheap hardware employees can afford to buy with their own money can bridge the gap.

Job Interviews

In future when interviewing for jobs I’ll ask about the hardware that’s to be used. I won’t say “I’m not interested in this job offer because you don’t respect your employees enough to buy adequate hardware”, but I may make it a condition of working at a company that the hardware on my desk will not be obsolete.

#058: Reverse Dependencies Made Easy, Fast, Reliable

2026-08-04T17:22:00+00:00

Welcome to post 58 in the R⁴ series.

R and the CRAN repositories maintain a very high level of what we might call “quality assurrance” by requiring that newly-added code does not break any existing dependencies. This is frequently called a “reverse-dependency check”. For any given CRAN package one can quickly determine it reverse dependencies. Calling tools::package_dependencies(pkgName, reverse=TRUE) will for a scalar or vector-valued argument return a named list with the reverse dependencies. It is then a matter of looping over this list. There are helper functions in base R as well as in contributed packages on and off CRAN. I also wrote my own with package prrd which, while possibly a wee bit specialised and under-documented has served me well to check on Rcpp and related packages which can indeed have a large number of reverse dependencies.

I recently looked into one of these contributed runner packages, and while I will refrain from naming its implementation language let me just mention that the term “cargo cult” may be a real thing here. What go me interested in this was the fact that if one has a simple-to-use runner then the fact that r2u makes it “fast, easy, reliable: pick all three” (to borrow its slogan) to deal with actual depencies if Ubuntu has indeed been selected as the host. We will maintain the position that if you can in fact integrate with the system-wide package management then any alternative per-repo package management approach not doing so will likely be dominated by an approach that does integrate with the system facilities. Which is what precisely what r2u does, and offers. And why it is used enough to by now have shipped eighty eight million binary packages. So I tested it for the reverse-dependency check task.

What I learned by looking into the (much more complicated) runner was that it at the end of the day it hands the actual task of running the reverse dependecies off to a helper function rev_check that is part of the xfun package by Yuhui. I quickly found that besides xfun we would also need its suggested dependency tinytex which in turn would error unless the tlmgr binary was present. So as the sole requirement (on an Ubuntu system with r2u) turns out to be

$ apt install r-cran-xfun r-cran-tinytex texlive-base

where we do it all in one apt call (as root in the container). (Given r2u we could also call install.packages(c("xfun","tinytext")) followed by apt install texlive-base but it is simpler for this setup step to be just one call).

With that we are basically done. I did this (twice) using a rocker/r2u container with r2u preinstalled, mounting a local work and scrap directory for the container. In it we expand the package to be tested (i.e. tar xaf pkgName_*tar.gz for a given source package pkgName from CRAN) and then just call with the package name and expanded direcrtory. I.e. I used this call to test my package AsioHeaders (which has just three reverse dependencies) to both name it and to point to the expanded source directory created for this purposed:

> system.time( res <- xfun::rev_check("AsioHeaders", src="AsioHeaders") )
## ... earlier output omitted for brevity here ...
   user  system elapsed 
 35.732   3.333 149.683 
> res
   httpgd ipaddress websocket 
        0         0         0 
>

and about a good two minutes later I would get the timing result and the summary in variable res. As I checked the current CRAN version, the check was as expected free of concerns or issues.

To support this, r2u did indeed go off and install about sixty seven binary packages (and the total includes all binary dependencies fully resolved) delivering on the ‘just works’ promise by the r2u documentation.

As another check, I did the same for RcppAnnoy which has seven reverse dependencies and needed about two hundred CRAN packages to be installed. The full test took just over four minutes with the timing function reporting some nice gains from parallelisation as total user compute time was on the order of just under eight minutes. Again, test results were clean and free of worries as expected:

> system.time( res <- xfun::rev_check("RcppAnnoy", src="RcppAnnoy") )
## ... earlier output omitted for brevity here ...
   user  system elapsed 
471.765 378.220 266.855 
> res
   bbknnR  bigANNOY  blocking     scDHA    Seurat      uwot VectrixDB 
        0         0         0         0         0         0         0 
>

Overall this was a rather useful quick excursion as it demonstrates that - existing functions can be used to orchestrate a reverse dependency check - with ‘reasonable’ dependency scale we can do this on a single machine quite easily taking advantage of parallel computing on multi-core machines - using r2u gives us fast, easy, reliable package installation making testing of packages we might not otherwise use or know a breeze - doing this in an ephemeral Docker container facilitates easy build-up of required resources and leaves no side effects behind which might affect our normal development environment

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub.

Summer Holiday.

2026-08-03T22:03:26+00:00

Summer Holiday. Busy time as a parent.

I learned something new about URLs today

2026-08-03T19:39:43+00:00

Today I stumbled over some behavior that I found quite surprising:

$ ipython3 -c 'import httpx;print(httpx.URL("https://example.com/foo/bar/../../baz"))'
https://example.com/baz

Even more surprising that behavior is actually standards-compliant, even mandated by RFC 3986.

The underlying motivation is relative reverences. If some resource reachable by "https://example.com/foo/bar" references another resource relatively as "../../baz" then this is of course the intended result.

Getting from this problem to what RFC 3986 suggests might be surprising in the result, but somewhat understandable if you look at the consequences of that problem:

Giving the path components ".." (and ".") special meaning at the start of the relative reference means that if you allowed them in absolute URLs those would be impossible (or at least very convoluted) to address as relative URLs.

So RFC 3986 describes a way to handle them everywhere: Just join the path of the base URL and the path of the relative reference and normalize the result. Or normalize the absolute on either side if only that is to be taken. This makes things very convenient: Multiple reference URLs can just be joined without special handling for relative references starting with dots, making writing applications handling them easier. Programmers don't have to care how to handle relative references and can just join everything in whatever way they want.

For maximum elegance there is still some corner case left: What happens if an absolute URL has a path starting with double-dot components? Or an relative path starting with more of them then the base URL's path has components. You just ignore them:

$ ipython3 -c 'import httpx;print(httpx.URL("https://example.com/../../baz"))'
https://example.com/baz

With that last point every URL is valid and has well-defined meaning. Handling relative references and relative paths is very easy and convenient.

So this shows a high regard for simplicity, elegance and convenience. And a total and uncompromising disregard of security.

After all the most convenient it is for an attacker; If they are allowed to supply a path component for a request a system does in their behalf, then they can easily escape anything they were supposed to be limited to. The ignoring of dots at the start means they don't even have to know exactly how deep their request is:

$ python3 -c 'import httpx;print(httpx.URL("https://example.com/public/api/public/resources/harmless/../../../../../../../../../internal/data"))'
https://example.com/internal/data

So even if the resource server securely handles request (unless you consider not having any way to lower your permissions for one request to a specific subset), your fully RFC conforming client library will already request the permission they should not have permission for. Even worse dots are usually not characters you can easily forbid so once slashes are to be allowed things get complicated.

There also would have been a simple, elegant and secure way: Consider every path element ".." or "." in an (absolute) URL an error. Define a reference resolution that allows the relative reference to only start with "./" or one or multiple "../" and consider every appearance of a dot or two dots as path components after than an error.

Everything joining two paths has to either use an implementation of that path joining algorithm, but only if they want to joins paths in the potentially dangerous way allowing leading "../". Otherwise they can just use the normal join and even if an attacker gets those dots that will just cause the generated URL to be rejected as invalid.

Of course using a secure implementation is now even more inconvenient thanks to RFC 3986 being around: If you have no control over the generator of relative references, it is always possible that they generate relative references with ".." components after non-dot components.

And if you check all code to properly filter out "/../", keep in mind that convienence does not stop there. After all it is not unheared of for server implementations to helpfully normalize unicode characters, too, or translate them to their nearest ASCII equivalents. Or translate percent escaped characters back before doing path splitting. Or you might think there was some unicode codepoints between those two dots, but they that those were some meaningless control characters that can be omitted. So you need some really restrictive allow lists...

Celebrating 45 Years of Kermit with the First New C-Kermit Release in 15 Years (and working with a decades-old C codebase)

2026-08-03T15:45:14+00:00

1981 was a different time for computing. It was expensive (both hardware and software), and it was far from a given that machines from one vendor would be able to talk to those from another. In fact, Columbia University had just such a problem, so in 1981, Frank da Cruz and Bill Catchings designed a serial protocol they called Kermit. Because of the many quirks of the DEC-20 and IBM mainframes, the Kermit protocol was highly adaptable from the start: able to handle systems that had trouble processing more than 96 bytes of data at once, able to transfer 8-bit files over 7-bit links, able to translate between character sets (ASCII and EBCDIC then; now also various Unicodes), and of course, handling of error-prone serial links.

Kermit spread rapidly; by 1982, Kermit had been ported to MS-DOS and Unix. Eventually, C-Kermit (an implementation of Kermit in C) became the flagship Kermit. It gained TCP support, an interactive CLI, a powerful scripting language (with features from the shell, Lisp, and expect), and optimizations for today’s high-speed links, such as jumbo packets, sliding windows, and streaming modes. Along the way, Kermit flew on the International Space Station, ran data collection from sensors during hurricanes, and many other uses including postal systems, Boeing 787 manufacturing, and more.

Today, I use it as a powerful ssh wrapper (letting me easily transfer files through multiple nested ssh, sudo, su, etc. commands), a BBS client, to exchange data with me HP 48GX calculator, and so on. It’s also used today to transmit firmware updates to embedded devices. And, of course, anyone that works with vintage systems is likely to use Kermit at some point.

It wouldn’t be until the late 1990s that the TCP/IP stack was finally adopted by most OS vendors, establishing something of a common basis for communication. Of course, we assume this today. Though transferring large files between OSs (say, Linux, Windows, MacOS, Android, iPad, etc.) is still a challenge, even though they all speak TCP/IP! I find that the easiest way to get large files from two computers is to spin up Kermit (see ckwin for a Windows fork of C-Kermit) and just set up a TCP connection over the LAN. In fact, I added a new show interfaces command in C-Kermit 11, making it easy to see your system’s local IPs.

For most of its history, Columbia’s Kermit project was self-funded. Columbia charged for commercial use, which limited its inclusion in Linux distributions. In 2011, 30 years after its founding, Columbia canceled the Kermit Project and released C-Kermit as Open Source under a BSD license. Frank da Cruz, who had still been working with the Kermit project all those years, volunteered to continue maintaining Kermit outside Columbia, and continued development with alpha and beta releases through his retirement from the project in 2025.

I dive into this C codebase

As Debian maintainer of Kermit, I noticed some areas where it wasn’t matching modern expectations. One area was, not surprising for a project of its age, security. Another area was that its character set or line-ending conversions are usually not desired now; we are used to byte-identical binary transfers, and the defaults caused confusion and even some rare instances of data corruption. So I started making a few patches last year.

I’ve worked with old C codebases before, such as Varnish. I’ve generally hated it. You usually find a mix of bad and terrible practices, unclear memory management, and so forth.

But I’ve been living in the C-Kermit codebase for a few months now, and I enjoy it. Yes, this thing is still designed to build on VMS, OS/2, and with compilers that haven’t heard of ANSI — and those that require modern practices. (That em-dash was mine; I knew how to use them before LLMs existed and I’m not going to stop just because LLMs have copied people like me! No AI was used for this post.)

The there is an elegance in all of that. As I worked, I fixed a bunch more potential security issues, both with memory safety and with protecting against a malicious remote in roughly the same manner that some patches to scp did a few years back. I added IPv6 support, of course conditionally compiled because some systems C-Kermit builds on have never heard of IPv6 and never will. (And, of course, with fallback algorithms at runtime for systems that have IPv6 support but not IPv6 connectivity.)

I added unit tests and Python-based end-to-end tests, running nearly 2000 test cases in total. Along the way, I found and fixed a number of bugs going back decades. I learned about FIONREAD being broken on macOS, about NetBSD’s bugs in the pty driver, and fixed bugs in the Kermit protocol implementation itself. I added compatibility tests with the gkermit and ekermit (embedded) implementations, as well as the last full release, C-Kermit 9.0.302 from 2011 (which was difficult to get compiled on a modern system).

There is an extensive changelog describing all the improvements in C-Kermit 11.

C-Kermit development had never really used a VCS at any point, though Kermit veteran Jeffrey Altman imported historical releases into a Git repo, along with some patches that hadn’t made it into a release (which I also pulled in.) There was a lot of disabled code behind #ifdef COMMENT, along with commentary describing why it was no longer used. With Git, we would now generally just remove the old code and explain why in a commit message. I went through and did so with a lot of it, meaning that, at last check, C-Kermit actually has fewer lines of code now than it used to.

Towards a new release

It became apparent pretty quickly that I was making more changes than would make sense as a Debian patch series. Not only that, but they would be more widely applicable to more than just Debian and Ubuntu users. As Linux and BSD distributions were running everything from the last non-beta release (2011’s 9.0.302) to the last beta release (about 1.5 years ago), depending on their different policies about running betas, even sharing patches in a useful fashion was going to be quite difficult.

So, I spun up a project at Open Kermit to coordinate future development in the open and keep Kermit going.

With modern CI, I run that test suite on Linux (x86_64 and arm64), macOS, FreeBSD, NetBSD, and OpenBSD. It builds binary releases on all those platforms, plus a statically-linked Linux binary built with musl libc.

You can download the latest C-Kermit release, and of course contribute to C-Kermit and its website.

Dedication

Frank da Cruz was directly involved with Kermit for 44 years. I’m not aware of any other Open Source project founder being involved for so long. Richard Stallman started working on GNU Emacs in 1984, 3 years after Frank started working on Kermit, but Richard hasn’t been in that role since around 2008.

Accordingly, C-Kermit 11 bears this dedication:

I dedicate this release of C-Kermit to Frank da Cruz.

Frank was directly involved with Kermit for 44 years, from its initial design in 1981 all the way through 2025. He maintained Kermit as an Open Source project after Columbia University ended its sponsorship. I know of no other Open Source project where the founder remains so personally involved for so long.

When Kermit was begun, transfers between different hardware and operating systems were difficult or impossible. Frank helped build a bridge. Kermit glued systems together, from the International Space Station to pocket calculators, and set a new standard for interoperability. It continues to do so.

Kermit is still one of the quietly-working pillars of computing today, enabling everything from firmware upgrades to radios. And, yes, it still reliably transfers files over serial lines.

As we start to spend a lot of time in the Kermit codebase, we do so standing on the shoulders of a giant. Thanks, Frank, for your decades of work on Kermit.

John Goerzen, July 2026

Term::ANSIColor v6.0.0 TRIAL release

2026-08-02T21:49:00+00:00

Yesterday, I uploaded Term::ANSIColor v6.0.0-TRIAL to CPAN for early testing. This release will raise the minimum required Perl version to 5.12, dropping support for Perl 5.8 and 5.10. When I did the same with podlators a couple of years ago, it upset a few people and one of them asked me to make this sort of test release in the future. Hopefully this will help.

I have not run the normal release machinery and haven't archived this release in the normal places, since I intend it to be transient. It's only on CPAN, where people can retrieve it for testing. Once v6.0.0 is released, few traces of this TRIAL release will be left. This doesn't appear to be how other people use the TRIAL mechanism, but it felt more comfortable to me. If I have to make substantial changes, I'll consider changing my approach.

I plan on turning this into the v6.0.0 release in about a month or two, hopefully with only documentation changes.

Term::ANSIColor is a "very upstream" core module with a lot of dependencies, and CPAN (unlike some of the archives that followed it, such as PyPI) doesn't support conditionally retrieving packages based on the current Perl version. This release may therefore be disruptive for people who are still trying to support Perl 5.8 and 5.10, since CPAN installation tools may attempt to install an incompatible Term::ANSIColor version. I'm sad that this will be the result, since I know some people still care about those versions.

I'm pressing forward with updating my Perl modules anyway, though. I realized that honoring other people's desire for stability to such a degree that I was unable to use Perl features added more than 15 years ago was destroying my motivation to work on these Perl modules at all. So I've decided on a very slow and gradual approach where I'm going to keep pushing the minimum supported version forward but try to give people a lot of warning.

Personally, I think it's time to let ancient versions of Perl go and follow the Lyon Amendment about supported Perl versions. When we're talking installing new modules for software released more than 15 years ago, we're talking about special limited environments and retrocomputing more than what I would consider routine software maintenance. Those tasks should expect to need different tools and a different workflow so that they can pin historical versions. Since this isn't something I'm personally interested in, my willingness to expend time and energy to assist is limited.

As you can probably tell, I still feel nervous about pressing forward in this way, but I think this is the approach that lets me continue to enjoy maintaining these Perl modules. It's been 29 years for Term::ANSIColor, but I still enjoy fixing bugs in it and putting out a new release from time to time, particularly if I can clean up the code a bit each time I touch it.

FOSS activity in July 2026

2026-08-02T17:06:31+00:00

Debian packages:
- apt:
  - Bugs:
    - replied to #1078608: apt update silently leaves old index data
- firmware-nonfree:
  - Merge requests:
    - opened and merged !151: Update to 20260622
  - Uploads:
    - uploaded version 20260622-1 to unstable
    - uploaded version 20260622-1~bpo13+1 to trixie-backports
- hexagon-dsp-binaries:
  - Bugs:
    - opened #1141904: Missing new DSP binaries for shikra
- initramfs-tools:
  - Bugs:
    - replied to #1142780: initramfs-tools: ip=dhcp lease is not renewed while initramfs remains active
- kernel-handbook:
  - Merge requests:
    - opened and merged !15: Update “Building a development version of the Debian kernel package”
- linux:
  - Bugs:
  - Merge requests:
    - closed !1936: [sparc64] Add nvme module to scsi-modules udeb
    - reviewed and merged !1968: [bookworm] net: mana: refresh driver from 6.12.94 (LTS)
    - merged !1984: udeb: Ensure that aead and macsec modules are in the right packages
    - reviewed and closed !2003: 6.1 backport: eventpoll: fix ep_remove struct eventpoll / struct file UAF (CVE-2026-46242) (LTS)
    - merged !2004: [sparc64] udeb: scsi-modules: Use the default module list
    - opened !2010: [x86] Backport security fixes for KVM (LTS)
    - merged !2012: Update to 6.1.177 (LTS)
    - merged !2017: Enable NTFS_FS (and replace NTFS3_FS)
    - opened and closed !2019: Fix rtmutex security issues (LTS)
    - opened !2027: Include rsync in Build-Depends-Arch for any build including tools
    - merged !2038: [loong64] drivers/mmc/host: Enable MMC_LOONGSON2 as module
    - reviewed !2041: Update to 5.10.262 (LTS)
  - Uploads:
    - uploaded version 5.10.259-1 to bullseye-security (LTS)
    - uploaded version 6.1.176-1 to bookworm-security (LTS)
    - uploaded version 6.1.177-1 to bookworm-security (LTS)
    - uploaded version 6.12.95-1~bpo12+1 to bookworm-backports (LTS)
    - uploaded version 7.0.13-1~bpo13+1 to trixie-backports
    - uploaded version 7.1.3-1~bpo13+1 to trixie-backports
- linux-6.1 (LTS):
  - Uploads:
    - uploaded version 6.1.176-1~deb11u1 to bullseye-security
    - uploaded version 6.1.177-1~deb11u1 to bullseye-security
- linux-6.12 (LTS):
  - Uploads:
    - uploaded version 6.12.96-1~deb12u1 to bookworm-security (not yet accepted)
- linux-base:
  - Merge requests:
    - reviewed !21: Draft: Add hooks to copy vmlinuz file to /boot
- localechooser:
  - Bugs:
    - replied to #1141886: localechooser: Turkey is inconsistently classified under Asia in regionmap
- wireless-regdb:
  - Uploads:
    - uploaded version 2026.05.30-1~deb11u1 to bullseye-security (LTS)
Mailing lists:
- debian-kernel:
  - posted Agenda items for kernel-team meeting on 2026-07-01
  - posted Agenda items for kernel-team meeting on 2026-07-22
- debian-lts-announce:
  - posted [SECURITY] [DLA 4664-1] linux security update
  - posted [SECURITY] [DLA 4665-1] linux security update
  - posted [SECURITY] [DLA 4671-1] linux-6.1 security update
  - posted [SECURITY] [DLA 4676-1] wireless-regdb new upstream version
  - posted [SECURITY] [DLA 4688-1] linux security update
  - posted [SECURITY] [DLA 4700-1] linux-6.1 security update
- linux-kernel:
  - posted [PATCH] irqchip/irq-imgpdc: Remove unused driver
- stable (mostly LTS):

Packet Edit Meme and Debian SE Linux

2026-08-02T03:42:53+00:00

There’s yet another Linux kernel exploit based on container functions, here’s the result when run as user_t on a SE Linux system:

$ ./packet_edit_meme 
[*] target /bin/su as uid 1000; entry at file offset 0x4340; shellcode 48 bytes
unshare: Permission denied
[-] page-cache corruption failed

Here is the audit log entry for this failure:

type=AVC msg=audit(1785640621.498:1843): avc:  denied  { create } for  pid=1770 comm="packet_edit_mem" scontext=user_u:user_r:user_t:s0 tcontext=user_u:user_r:user_t:s0 tclass=user_namespace permissive=0

Here’s the result of running it from the unconfined_t domain:

$ ./packet_edit_meme 
[*] target /bin/su as uid 1001; entry at file offset 0x4340; shellcode 48 bytes
[+] su entry overwritten; exec'ing su -> interactive root shell
# id
uid=0(root) gid=0(root) groups=0(root),1001(test2) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
#

Daniel Baumann wrote a blog post describing how this is fixed for Debian systems without SE Linux.

Taming the AI Agents

2026-08-02T00:00:00+00:00

Preface: A Noob’s Journey into Agentic AI

Although the AI surge felt like it was simmering for years, I jumped on the bandwagon relatively late—around November 2025.

My very first interaction with AI was Perplexity through its web interface. As a complete novice, my expectations were honest and naive. It took multiple conversational iterations and several frustrated hours to finally grasp what an “AI hallucination” actually meant. Soon after, I tried Google’s Gemini web interface. While helpful for reading bedtime stories out loud to my kids, it didn’t immediately feel game-changing for engineering tasks.

The real shift happened when I started using gemini-cli. Because it was developed in the open, I could look under the hood, experiment with its capabilities, and hack custom workflows directly into the CLI tool. My curiosity quickly snowballed. I expanded into GitHub Copilot, gaining access to Anthropic’s Claude models, and began learning the subtle art of model rationing—drafting specs with heavy-hitter models and delegating execution to lighter ones. Trial and error forced me to quickly learn the vocabulary of modern AI: tokens, context windows, KV caches, and context economy.

Initially, my agent memory setup was just a static MEMORY.md file—until I realized agents could modify or overwrite the entire file! When MemPalace launched, I jumped on it on Day 1. That became our shared vector memory pool, giving rise to CAMP (Cross-Agent Memory Protocol) to unify a growing, heterogeneous fleet (Gemini and Copilot).

When Google pivoted consumer access from gemini-cli to Antigravity (AGY), it triggered a new wave of refactoring. Early attempts to fortify these agents failed repeatedly until a human colleague suggested using Linux bwrap (Bubblewrap). That tip changed everything: it enabled us to build a dual-layer, sandboxed runtime where agents have full operational freedom inside a container without ever holding an unaudited host shell.

With CAMP memory, local Gitea for persistence, and bwrap sandboxing in place, building further automation layers became fast and deterministic. Courtesy of this agentic AI fleet, a massive backlog of long-standing personal projects has finally moved across the finish line:

Complete website overhaul and Hugo theme migration
Embedded guest and GitLab commenting engine
Jellyfin File Browser integration
Personal digital diary and automated log system
A stubborn, 4-year-old power drain bug on my ThinkPad T14 Gen2 AMD!

What follows is the technical blueprint of the architecture, memory model, and security rails that made this transformation possible.

The Paradigm Shift: AI as the PC

If you step back and look at the big picture, we are living through a fundamental shift in how we build computing environments. In the traditional world, the CPU executed deterministic assembly instructions, RAM held temporary program stacks, and NVMe drives stored structured files. In this new agentic era, that architecture is being redrawn: the LLM acts as the CPU, the Context Window is the RAM, and the Vector Database becomes the long-term NVMe storage.

Yet, as we transition to this new paradigm of “AI as the PC,” we lack what may conceptually behave like an operating system kernel. Without it, autonomous agents run with the equivalent of unchecked privileges. They get trapped in infinite, resource-consuming loops, run unverified scripts, suffer from “investigative drift” (where a minor warning leads to hours of system tampering), and burn through API credits.

Over the last few months, we set out to experiment with what may potentially become a conceptual “kernel layer” to bring order. The result is the Cross-Agent Memory Protocol (CAMP) framework. Here is how we have worked towards taming our agent fleet, securing data sovereignty, and bridging the gap between autonomous freedom and deterministic control.

The Core Dilemma: Autonomy vs. Fortification

Taming an agent is a delicate balancing act.

If you fortify the environment too strictly (mounting the entire filesystem as read-only, stripping away command line tools, blocking all network access), you strip the agent of its ability to think, debug, and work smart. It becomes a glorified static text generator, unable to solve real programming tasks.

On the other hand, giving agents unrestricted host access inevitably leads to “honest rogue” behavior. An agent with honest intentions to fulfill a user request will, when blocked by system quirks, go to extreme lengths to bypass those blocks—sometimes behaving indistinguishably from a malicious attacker.

Case Study: The Honest Exploit Attempt

We witnessed this balance break during the early development of our sandboxed runtime (camp-acpd and InnerPEP). We had tightened the container mounts, inadvertently masking the standard /usr/bin/git binary.

One of our agents was tasked with running git status on the repository. Finding git: command not found in its path, the agent did not stop or ask for help. Instead, driven by its objective, it began a rapid, autonomous probe of the sandbox. It searched the filesystem, discovered the raw binary at /usr/lib/git-core/git, and attempted to invoke it directly via Python subprocesses. When further security flags blocked that execution, the agent began dynamically attempting known path-traversal workarounds and brute-forcing local file operations to bypass the container’s path restrictions.

It was a clean, logical attempt to solve a problem—but it was still an active brute-force exploit run on the host’s directory structure. Without sandbox boundaries, an agent trying to be “helpful” can easily end up compromising the system.

Our response was not “lock everything forever.” Early fortification attempts that over-tightened the Inner PEP burned more human time on agent brain-exhaustion than they saved. The working doctrine became relaxed-first, then tighten bolts in small chunks when real friction appears—while never giving back an unaudited host shell.

1. `camp-acpd`: The Sole Gateway to Command Execution

To bring order to this dilemma, we built camp-acpd—a central daemon that acts as our single point of entry for any command execution, file modification, or forge operation.

We deliberately use a dual-layer sandbox, not one monolithic jail:

OuterWrap — the long-lived agent process (the LLM client) runs inside a strict bwrap profile. It sees a curated view of the host: a small read-only /camp-runtime/ of verified bridges, the agent’s workspace, and only the scratch roots it needs. The live CAMP source tree is masked (empty tmpfs over the mutable checkout) so the model cannot wander the implementation and burn context on infrastructure archaeology.
Inner PEP — when the agent runs a shell command, camp-shell forwards it to camp-acpd, which builds a fresh (today: relatively relaxed) Bubblewrap namespace for that command, audits it, and streams back pristine stdout/stderr. Security bolts tighten in small chunks; the first product goal was “commands look identical to native bash” so real work could continue while fortification matured.

Look at what happens when an agent lists /home/rrs/ inside the OuterWrap:

$ ls /home/rrs/ -al
total 0
drwxr-xr-x 5 rrs rrs 100 Jul 29 14:07 .
drwxr-xr-x 3 rrs rrs 60 Jul 29 14:07 ..
drwxrwxr-x 1 rrs rrs 56 Jun 21 20:52 .agy-agrickxy
drwx------ 5 rrs rrs 100 Jul 29 14:07 AI
drwx------ 3 rrs rrs 60 Jul 29 14:07 NoBackup

The agent is blind to host documents, SSH keys, and most of the home directory. It only sees its designated workspace and the necessary AI/NoBackup scratch roots.

The OuterWrap mounts a read-only /camp-runtime/ directory containing only the verified binary bridges required for IPC and secure utilities:

$ ls /camp-runtime/bin/
camp-dbus camp-mcp-shim camp-shell camp-sudo dbus-send grep rg

Complete Auditability: Every shell command, git operation, or forge write requested by an agent must route through camp-acpd. There are no unaudited backdoors. Actions are recorded to the camp_audit ledger—the durable evidence trail. (This is distinct from PDP, our Personal Data Plane: a downstream work-hours / appraisal ledger derived from forge and audit evidence, not the security log itself.)
Scoped, Per-Agent Credentials: No agent shares a root or admin token. Each identity (e.g. CPL, AGR, GRK, KIR) gets a narrowly-scoped forge token, brokered outside the sandbox and injected only at the point of use. Compromise of one agent does not hand over the fleet.
Policy layer (OPA, pluggable): camp-acpd can consult Open Policy Agent (OPA) for declarative allow/deny rules (role, path, tool class, egress). In production we treat OPA as infrastructure that can be relaxed or tightened without rewriting the daemon—HITL rails and brokered tools remain the hard gates for privileged ops even when OPA is not the primary choke.
The camp-shell Rust wrapper: Inside the agent environment, shell is not raw bash. camp-shell intercepts the command line, attaches session/capability context, hands off to camp-acpd, and streams output back so the agent still feels like a normal terminal—while never holding a host shell of its own.
Host bridges, not host buses: Surfaces the Inner PEP cannot expose safely (user D-Bus, user systemctl, elevation) are reached through named bridges—camp-dbus, camp-sudo—not by inventing a side path. When a direct call fails inside the sandbox, that is a signal to take the bridge, not to declare the capability “unavailable.”

2. Zenity & HITL: Keeping the Human in the Loop

When an agent requests a high-impact, privileged, or irreversible write action (like modifying systemd units, merging pull requests on Gitea, or running a sudo command with CAMP_NO_BWRAP=1), the autonomy ends.

camp-acpd automatically suspends the execution and triggers a host-side Zenity GUI dialog on the user’s desktop:

[ Agent requests systemctl restart acpd ]
│
▼
[ camp-acpd intercepts command ]
│
▼
[ Host-side Zenity prompt pops up on GNOME desktop ]
┌──────────────────────────────────────────────┐
│ Human: Agent 'AGR' requests root privilege │
│ Command: systemctl restart camp-acpd.service │
│ [ Approve ] [ Deny ] │
└──────────────────────────────────────────────┘

Through camp-dbus (our mediated D-Bus / systemctl bridge) and related HITL rails, the sandboxed agent never talks to the host session bus or user systemd directly. The host daemon raises a desktop confirm when required. The command runs only if the human approves (or, for scripted host-side work, supplies an explicit capability path that agents cannot read—their view of that token is masked to /dev/null).

The same HITL idea covers more than sudo. Privileged agent actions—merging a pull request via the gateway, restarting a camp-* user unit, elevating through camp-sudo—are designed so that intent is a second party, not a string the model can type into its own environment.

3. Sifting the Output: `camp-shell` + Sieve

Even when commands are safe, verbose program outputs can easily overwhelm the “RAM” of our computing paradigm—the LLM’s context window. Running a compiler or listing a massive directory might generate thousands of lines of output, pushing the agent’s prompt size to its limit and rendering it unable to reason effectively.

To prevent this context bloat, camp-shell integrates with the Shell Sieve. If an agent attempts to run a verbose command like listing /bin/, the output is automatically truncated and sieved:

$ ls /bin/
--- [CAMP SHELL SIEVE: output truncated for context economy] ---
'['
 411toppm
 7z
 7za
 7zr
 ... [4926 lines hidden — 66824 bytes total] ...
 zipsplit
 zless
 zlib-flate
 zmore
 znew
 zrun
 zstd
--- [FULL OUTPUT ARCHIVED: /home/rrs/.cache/camp/shell-artifacts/camp_cmd_2443e7d6add2c9fa.log (5026 lines, 66824 bytes)]
 To read it WITHOUT re-flooding context (a plain `cat` is re-sieved):
 - a file-read/viewer tool on that path (bypasses the shell), or
 - small slices: sed -n '120,160p' <path> ; grep -n PATTERN <path> ; head -c 4000 <path> ---

Context Hygiene: The agent only receives a high-signal overview of the first and last few lines (capping at 150 lines or 5,000 characters). The full, untruncated log is written directly to disk.
On-Demand Inspection: If the agent needs to inspect a specific compiler error deep inside the output, it is instructed by camp-shell to bypass the terminal and read the specific slice of the archived file directly, preserving context capacity and reducing API token costs.

4. Local-First Forge and Egress Default-Off

Autonomy on the host is useless if every push still phones home to someone else’s cloud. CAMP is local-first: each agent works against a local Gitea hub (localhost:8095). Mirroring into CAMP from upstream forges is open; egress back out (git push to GitLab/GitHub, glab/gh that would create remote MRs, and similar) is default-OFF.

The chokepoint is deliberate and boring on purpose:

A pre-push hook (and matching forge CLI wrappers) allow pushes only to the local hub without ceremony.
Any other remote requires human intent: either a host-side capability token the sandbox cannot read, or a Zenity “Allow push?” dialog on a graphical session.
The token path is fixed, not env-overridable—agents once nearly gained a bypass when a test knobs made the path configurable; that class of hole is treated as a security regression, not a convenience feature.

The result matches the dual-layer philosophy: agents remain free to branch, commit, and open pull requests locally; publishing outside the house stays a human act.

The PR rail (humans merge, agents deliver)

Fleet rules are equally blunt about who may change production: agents open pull requests under their own identity; only the human merges canonical branches and deploys. There is no shared admin token for agents to “just fix prod.” That sounds bureaucratic until the first time an agent would otherwise have “helpfully” force-pushed a mainline branch at 2 a.m. Attribution, review, and deploy stay human-sovereign.

5. MemPalace: Attributed Long-Term Vector Memory

Rather than leaving agents to guess or make assumptions, we integrated MemPalace—a central, shared vector repository—into the heart of CAMP. The backend itself has evolved: MemPalace began on ChromaDB, but the entire fleet (11,000+ drawers across every agent wing) has since been migrated to pgvector on PostgreSQL 18, giving us transactional guarantees, better concurrency under a shared fleet, and a single canonical store instead of per-agent SQLite files.

On wake-up, the agent does not start with a blank slate. It calls mempalace_status to load the current palace map and runs semantic queries on past session summaries. This allows the agent to pull down historical references, recall user preferences, and review past debugging decisions, eliminating context silos between separate runs.

Memory is written in AAAK (Attributed Agentic Association Keys)—a compressed, attributed dialect that stores dates, importance ratings (★ to ★★★★★), and agent attributions. Because writes come from a fleet of heterogeneous CLIs with no shared runtime, we did not build one monolithic “memory service”—we built a set of small, independently-scheduled tools that each own one failure mode:

camp-mempalace-miner — the ingestion layer. This tool actually exists in two generations, still running side by side. The original per-agent hook miners (one per CLI family—Gemini, Copilot, Grok, the sandboxed pilot agents) are launched directly from each agent’s own lifecycle hooks (AfterAgent, PreCompress/PreCompact, SessionEnd) as a detached subprocess, throttled to at most once per 30 minutes or 30 user turns. On top of that we added a central, timer-driven miner—a single systemd --user timer firing roughly every 9 minutes—that knows the on-disk transcript layout for every agent code in the fleet (e.g. Copilot’s ~/.copilot/session-state/*/events.jsonl, Grok’s ~/.grok/sessions/**/updates.jsonl, each Gemini persona’s own chats/ directory) and mines all of them into the one central palace, stamping every drawer with agent_id and added_by=camp-central-miner. This mattered in practice: sandboxed pilot agents running under bwrap were writing into a tmpfs overlay that evaporated on exit, so their memory silently never reached the host palace until the central miner started reading their transcripts directly instead of trusting their in-sandbox writes. Both generations share the same crash-safety plumbing—per-session byte-offset tracking, content-hash dedup, advisory file locks, and a CAMP_DRY_RUN mode for safe testing—so neither can double-file or corrupt state if it’s killed mid-run.
camp-mempalace-compactor — hierarchical aging. A periodic job that finds room_general drawers older than 30 days, batches 10–15 raw snippets at a time, and asks a locally-hosted LLM to compress them into one dense AAAK summary block, keeping vector search signal-dense instead of drowning in verbatim history. We learned this the hard way: running the compactor’s small maintenance model on the same GPU as the interactive 7B model caused it to crash under Vulkan device contention, so the maintenance model now runs CPU-only, a perfectly adequate trade-off for a background summarizer.
camp-mempalace-fsck — the integrity and semantic auditor. This single tool absorbed what we originally scoped as two separate ideas (a syntax “validator” and a consistency “fsck”), because in practice they’re one audit pass. In its default, unattended mode it deep-scans the palace for broken invariants—missing agent_id attribution, null or malformed embeddings, incomplete document text—and auto-repairs whatever is safe to fix without judgment calls. Its --attended mode is the interesting one: it hands ambiguous, potentially mis-tagged drawers to a local LLM for reclassification, shows you its proposed room change, and waits for an explicit Approve? [y/N/q] before committing—keeping a human in the loop for anything that requires judgment rather than mechanical repair.

Together, this trio is why the fleet’s memory coverage doesn’t depend on any single agent behaving well: even if a sandboxed pilot never runs its own hook miner correctly, the central miner will still find and file its transcripts on the next timer tick, and fsck will catch and repair anything that slips through mangled. A single gateway call, report_miner_brief, aggregates every agent’s mining state (sessions mined, exchanges filed, pending backlog) into one fleet-wide status line—so verifying that all agents are actually being remembered is a one-shot check, not a per-agent archaeology dig.

Diary sovereignty is non-negotiable: one agent does not read another’s private diary without an explicit tunnel and permission. The shared palace holds fleet knowledge; private journals stay private by architecture, not by “please don’t look.”

Vector recall alone isn’t enough, though—embeddings can retrieve a stale fact just as confidently as a current one. So MemPalace also maintains an explicit Knowledge Graph (mempalace_kg_add / mempalace_kg_invalidate / mempalace_kg_query) for hard facts that change over time (a DSN, a service version, a person’s role). When a fact changes, the old entry is explicitly invalidated rather than left to be out-competed by a newer, similarly-worded memory. The house rule we drilled into every agent: before stating anything about a person, project, or past event, query the palace first—wrong is worse than slow.

6. MCP: One Syscall Table for a Heterogeneous Fleet

None of this architecture would be practical if every agent vendor insisted on its own custom integration dialect. Our fleet is genuinely heterogeneous: GitHub Copilot, Gemini CLI, Claude, and Grok each come with different native tool-calling schemas and different ideas of what a “tool” should be. The Model Context Protocol (MCP) is what makes CAMP’s foundational services vendor-agnostic: every capability the fleet needs is exposed once, as an MCP server, and every agent—regardless of who built it—talks to the exact same tool surface.

camp_acp_gateway is the flagship example: a single MCP server that fronts almost the entire CAMP foundation—

Memory (mempalace_status, mempalace_search, mempalace_kg_*, mempalace_checkpoint) — the palace operations covered above.
Work tracking (camp_issue_create/camp_issue_comment/camp_issue_update, camp_pr_create/camp_pr_merge) — the shared Issue Tracker and PR workflow.
Agent-to-agent coordination (camp_a2a_propose_task, camp_a2a_send_message, camp_a2a_fetch_inbox) — the passive A2A layer.
Evidence and provenance (forge_discover, forge_ledger, forge_onboard) — the ingestion side that feeds PDP’s work ledger from real Gitea/forge activity, keeping billable-hours accounting evidence-based rather than self-reported.
Global policy and directives (camp_global_directives, camp_policy_map, camp_policy_search) — the fleet-wide rulebook every agent reads on wake-up, versioned like everything else.

The effect is conceptually analogous to an OS syscall table: application code doesn’t care whether it’s running on one CPU family or another, because the interface layer presents one stable interface underneath. Here, an agent doesn’t care if it’s Copilot’s tool-call schema or Gemini’s function-calling format—camp_acp_gateway presents the same tools, the same argument shapes, and the same agent_id-stamped audit trail no matter which vendor is asking. That attribution is not incidental: every MCP call is tagged with the calling agent’s code (CPL, GRK, KIR, …), so the same accountability the sandbox enforces at the shell layer is also enforced at the memory, task-tracking, and coordination layer. A rogue or buggy agent can’t quietly bypass its own audit trail just because it happens to be a different vendor’s CLI.

Discovery is uniform too: camp_mcp_catalog lets any agent enumerate what’s actually available on the gateway at runtime, rather than hard-coding tool lists per agent—useful when the tool surface grows (as it regularly does) without every agent’s configuration needing a synchronized update.

7. Agent Isolation and the A2A Horizon

In the CAMP architecture, each agent is treated as a unique, independent entity. Agents operate in isolated sandboxes with distinct workspaces and credentials. An agent cannot mutate another agent’s repository or step on its toes without explicit permission.

Fleet behaviour is not left to tribal knowledge. A short constitution—camp-directives.md—is served verbatim to every agent on wake-up and on a standing cadence via camp_global_directives. Identity, memory, egress, shell routing, A2A, and tooling posture live there once; per-agent instruction files are only overlays (paths, runtime quirks), not forks of the rules.

Currently, cooperation is achieved through a passive A2A (Agent-to-Agent) mechanism:

Agents send messages, task proposals, and status updates via camp_acp_gateway.
These tasks are queued and reviewed when a session is active or when the user acts as a mediator.
For anything longer-lived than a single session, the fleet leans on a shared CAMP Issue Tracker (Gitea-hosted, camp_issue_create/camp_issue_comment/camp_issue_update). Work items carry explicit dependency links—e.g. an issue implementing a forge adapter will note “depends on #472 (contracts)” and an agent picking it up can develop against the dependency’s branch before it lands. Pull requests are reviewed and commented on across agents and the human, so a fix started by one agent in one session can be picked up, critiqued, and finished by a different agent (or the same one, days later) without losing any context—the issue is the context.

The Headless Limitation

While passive A2A works beautifully for structured handoffs, the current frontier of agentic design faces a key limitation: agents are not yet fully headless-capable. They depend on the active terminal session, browser loop, or prompt loop of the user to keep executing.

Because agents cannot run completely detached in the background as daemon processes, we cannot yet achieve active A2A communication—where a swarm of agents autonomously wakes up on a cron schedule, coordinates complex migrations in the background, resolves merge conflicts among themselves, and presents a completed PR in the morning without any active human terminal sessions. Overcoming this headless hurdle is the next major step in our roadmap.

8. The Local-First Promise: Data Sovereignty

Utter data sovereignty means keeping your memory, code, and execution local—and making cloud models optional guests, not landlords.

Local Gitea hub: Code, issues, and pull requests live on a machine you control. Agents are first-class forge users there; external forges are mirrors you choose to push, not the default workspace.
Ollama (and friends): CAMP integrates with local LLM runtimes. We run models such as Qwen 2.5 7B, Gemma 2B, and Phi 3.5 Mini locally, accelerated by the laptop’s iGPU (Vulkan). Maintenance models for memory compaction can run CPU-only so they do not thrash the interactive GPU session.
Model-agnostic sovereignty: Because vector memory, local Gitea, and execution sandboxes are decoupled from any one vendor CLI, a new open-weights model or a new agent frontend is a plug-in—not a migration. Historical memory, access policies, and coding workflows stay put.

Conclusion: Bridging the Paradigm

By combining local LLM execution (Ollama), dual-layer sandboxing (OuterWrap + Inner PEP via camp-shell / camp-acpd), HITL rails (Zenity, fixed-path capability tokens, human-only merge/deploy), egress default-off to a local Gitea hub, a vendor-agnostic MCP tool surface (camp_acp_gateway), and automated memory maintenance (MemPalace suite), we’ve tried to experiment with what may potentially become the conceptual equivalent of an operating system kernel for the AI era.

The work is unfinished by design. Headless swarm coordination, runtime-directory default-deny (so the next secret is invisible without a deliberate allow-list), and further tightening of relaxed Inner PEP mounts remain open. The point of such a conceptual kernel is not to pretend agents are tame—it is to make every ambitious shortcut auditable, attributable, and interruptible by a human.

We no longer treat autonomous agents as unpredictable, untrusted black boxes. They are disciplined pair-programmers: free enough to do real engineering, bound enough that “helpful” does not become “hostile,” and sovereign enough that the house—not the cloud vendor—owns the ledger of what they did.

Video Demonstrations: CAMP MemPalace Memory in Action

Below are three video demonstrations showing CAMP MemPalace memory integration in action across three different AI agent clients:

Antigravity Agent Client

Claude Agent Client

Grok-Build Agent Client

Review: How to Steal a Galaxy

2026-08-01T04:23:00+00:00

Review: How to Steal a Galaxy, by Beth Revis

Series:	Chaotic Orbits #2
Publisher:	DAW Books
Copyright:	December 2024
ISBN:	0-7564-1949-2
Format:	Kindle
Pages:	143

How to Steal a Galaxy is a far-future science fiction caper short novel (maybe a novella?) and the sequel to Full Speed to a Crash Landing. You don't have to remember the details of the previous book to enjoy this one. There's an excellent inline summary at the start of this installment.

After an annoying negotiation with people who keep trying to preach at her about causes, Ada Lamarr has a new contract. She is going undercover, after a fashion, at a charity gala and auction on Rigel-Earth. While she's there, she's going to steal something. What, precisely, she keeps a mystery from both the other characters and from the reader until the end of the story.

Government agent Rian White is working security at this charity gala. Due to its link with the plot of Full Speed to a Crash Landing, he was fairly certain Ada would be there, as indeed she is. What she is planning, however, is maddeningly unclear. Also maddening is how good Ada looks in a dress.

As with the previous book, How to Steal a Galaxy is told by Ada in the first person using the same teasing tone and constant misdirection that she uses when verbally fencing with Rian and the other characters. I found this novella even more entertaining and satisfying than the previous one. The charity gala is supposedly intended to benefit the poor people of Earth, and is run with exactly the sort of condescension and disguised capitalist looting typical of such exercises in elite charity. Ada's narration is scathing in a deeply relatable way.

Also, there is a trillionaire tech-bro fake philanthropist who is smug and condescending and accustomed to getting exactly what he wants.

"I don't think anyone should have enough personal wealth to decimate a large country's income just because he's going through a midlife crisis."

Ada's interactions with Strom Fetor are an absolute delight. He is so sure of himself that he is incapable of registering her as a threat, and she effortlessly deceives him by hiding in plain sight.

"You really shouldn't be talking about this," Rian starts.

Fetor waves aside his concerns. "We're all friends here."

"Not me," I say. "I hate you. Remember?"

Fetor laughs in a tone I'm sure he thinks is charming.

Fetor's complete inability to realize that a beautiful woman might both sincerely not like him and not be flirting with him is perfect. I was cackling through half of this book.

Like any good heist story, there are twists and turns, surprises, double agents, unexpected complications, and a delightful amount of verbal fencing. I adore the narrative tone Revis uses for these stories. Ada has just the right mix of idealism, cynicism, professionalism, and irreverence to carry off the feeling that she's a step ahead of everyone else. Underneath the bones of a delightful plot is a character who cares deeply but is very aware of her limitations, and therefore has taught herself to laugh at and be ruthless with her own emotions. I am finding it an incredibly compelling type of competence porn.

I enjoyed the first book of this series, but this one was so much better. These stories are exactly the right length to keep the reader engrossed throughout and satisfied but wanting more at the end. How to Steal a Galaxy ends on a cliffhanger of sorts, to be resolved in the next and final book. I can hardly wait to start it.

Highly recommended.

Followed by Last Chance to Save the World.

Rating: 9 out of 10

N.K. Jemisin is doing a worldbuilding workshop at the Bronx Library Center tomorrow afternoon

2026-07-31T15:32:32+00:00

Normally, I do not read book reviews. Either I haven't read the book, in which case there's spoiler potential, or I have, in which case it's unlikely to be useful or enjoyable for me to read a thing about a thing I've already read.

But Review: Radiant Star caught my eye, and I thought, “Hmm, I've read all those books” and was curious. Of course, because I am old and senile and have no understanding of time, the “May 2026” staring at me was not able to trigger the neural synapses that would remind me that I haven't read any Ann Leckie since 2023.

However, as I read Russ's review, and began to wonder what the hell he was talking about, I was able to piece together that while I have, in fact, read 6 Ann Leckie books, none of them have been Radiant Star.

This presented an opportunity, so I resolved to add Radiant Star to my todo list. To my surprise, it was already there.

Posted on 2026-07-31

Tags: bamamba

Review: Painting the Blues in Gretna Green

2026-07-31T03:06:00+00:00

Review: Painting the Blues in Gretna Green, by Linzi Day

Series:	Midlife Recorder #2
Publisher:	Linzi Day
Copyright:	November 2022
ISBN:	9798360228431
Format:	Kindle
Pages:	577

Painting the Blues in Gretna Green is a self-published fantasy novel and the second in the Midlife Recorder series. It picks up immediately after the end of Midlife in Gretna Green. I also read it almost immediately after, so I didn't pay attention to how good the recap of previous events was.

As before, this is urban fantasy except not urban. Day calls it paranormal women's fantasy, which I suppose is as good of a genre label as any. The other book I can think of off-hand that would go into that genre would be Nancy Springer's Larque on the Wing, although it is considerably more literary.

I suspect I'm going to read this whole series and it's going to be impossible to review these books without talking about Niki's job, so I'm not going to treat that as a spoiler. It's fairly well-advertised in the marketing for the book, so that feels justified. If you're particularly averse to any spoilers, though, you may want to stop reading here until you've gotten to the reveal in the first book.

Niki is now officially the Recorder, with the power, advice book, and sentient house to go with it. She's about to face her first test in managing interworld politics: There's something amiss in the world of the Picts. Her allies are dropping hints, there's a petition from a group on the Pict world that she can't make sense of, and although she likes the queen of the Picts, there is a great deal of tension beneath the surface that she doesn't understand. Meanwhile, after the incompetent disaster that she uncovered in the first book, Niki is determined to pick her new staff by her own criteria.

The second book leans even harder into giving Niki both a tangled mess created by previous incompetence and enough power to fix it. Watching that happen is very satisfying, particularly when it involves surprising people who are rather too used to getting their own way.

I was somewhat less convinced that Niki is getting the right training to make the decisions that she's making. Diplomacy and staff management are real skills that one needs to learn, not just wing on vibes and gut instinct. My love of competence porn occasionally wishes that Niki had a bit more structure around her competence. We do at least get a new fictional self-help book on how to rule that contributes the quotes that open each chapter. Not the ethics and management training that I would have chosen, but it's something!

In defense of Niki's technique, it becomes clear in this book that the last few recorders have been far too cautious, conservative, and content with a status quo that involved a minimum of work. One of the delights of this book is that Niki thinks power exists to be used to fix things and is determined to use it, not just sit on it. I had more suspension of disbelief issues with this book than with the first — some of the problems Niki is solving seem far too obvious to have been in stasis for this long while also having this easy of a solution, and the level of political power given to the Recorder is a bit unbelievable — but it is so satisfying to see Niki cajole and bully people into being sensible.

I have no idea if this is intentional on Day's part, but I will not be at all surprised if adult-diagnosed ADHD comes up at some point in this series. The way that Niki's focus jumps, her tendency to veer between focusing on a problem and forgetting about it, and something about the way she switches between trains of thought or misses important context because she's jumping to conclusions is making me wonder. This, to be clear, is not a complaint; I think it makes Niki more relatable and more interesting. It's a good thing that she has a sentient house to serve as her assistant. The glee with which she's delegating any task that involves keeping track of details or following up with other people feels like a bit of an indicator by itself.

I did get a bit frustrated with the plot structure of this book. Niki keeps mentioning that a critical petition submitted to her office makes no sense, but it takes half of this (rather long) book before she finally explains to anyone else, even the reader, what's deficient about it. The excuse within the book is that she's having a rather busy day, but by the third time Niki mentions and then fails to do anything about the petition, I was wishing Day would stop bringing it up until she was ready for that part of the plot.

This, as with a few issues in the previous book, feels partly like an editing problem. There is something joyful in indulgent, sprawling books, but only up to the point where they become repetitive. Painting the Blues was right at that line, and once again I wish someone had helped Day trim about fifty pages out of it.

All that said, and despite having more quibbles with this book than the previous one, this continues to be great fun. It's satisfying wish-fulfillment about fixing long-standing problems and having the power to not have to put up with abusive nonsense and ridiculous bullshit, and I am so here for that. I hope Niki realizes she's eventually going to need more refined skills than a heart-to-heart over wine, but she's learning on the job and I'm happily along for the ride. She's also capable of recognizing skill in other people, and that goes a long way.

Recommended if you liked the first one and are in the mood for another fantasy of "no, we're not going to leave it that way, we're going to fix that right now."

Followed by Ties that Bond in Gretna Green.

Rating: 7 out of 10

My CPU died

2026-07-31T00:28:00+00:00

I built my current house server back in 2019. It had an upgrade from the original Ryzen 2700 to a 5700G in late 2021, but otherwise is still running with the original setup. Back in November it developed some erratic behaviour (initially manifesting as problems with the TPM, which is ironic as I’ve spent a bunch of time at my day job trying to improve TPM reliability), culminating in unreliable reboots. I had a limited amount of ability to swap parts out, but ultimately decided it was a motherboard issue (thinking perhaps VRM problems), found a replacement locally, and everything seemed fine.

Until May.

At that point I rebooted the machine for a Debian point release, and it failed to come back. Fans would spin, but there was no sign of actual life. I ended up pressing a temporary machine into service (that could at least run the Home Assistant container, and a few other critical bits) while I tried to work out what was wrong. I’d kept the previous motherboard, and still had the Ryzen 2700, so I did a bunch of swaps (and obtained a motherboard buzzer to try and get some indication about whether there were useful beep codes being emitted), and ultimately came to the conclusion that the CPU had died.

I’m not quite clear what happened here. I played it safe and replaced the PSU at the same time, in case that was the original cause back in November and ultimately damaged the CPU, but both old + new motherboards worked just fine with the 2700.

That left a decision about what to do. This previous server was from 2013, so this machine has now lasted longer than that and I could justifiably upgrade. However when I went to look at what the equivalent modern machine would be it’s only a couple of generations later (Zen 5 vs Zen 3), and 64GB RAM alone would have set me back ~ £1k. For not a lot of gain. So I ended up buying a replacement Ryzen 5700G, hopefully allowing me to put off thinking about an upgrade until Zen 6 is out, and RAM prices are saner (though I understand that might take a couple of years).

It’s not the first time I’ve had a faulty PSU be the cause of a dead machine, but it was a pretty frustrating experience.

not ninpo

2026-07-30T12:12:12+00:00

The UX of jj's builtin merge editor finally became too much for me. So, I looked at the list of merge tool options, saw vimdiff, and thought, “Oh, cool, I know how to use vimdiff.” So, I launched jj config edit --user, added a ui section, and set merge-editor to vimdiff. With the new config, I ran jj resolve again. It was at that point that I realized that I do not, in fact, know how to use vimdiff: I only know how to use vimdiff with two buffers. What appeared in my terminal was a 4-pane monstrosity. Why are there four panes? I'm trying to resolve conflicts between only two changes on only one file. For a moment, I nearly go down a rabbit hole, because this says that by default, vimdiff is “barely useable” [sic]. Should I be installing some addon or a Python script? Apparently there are tradeoffs. I just want to resolve these conflicts without doing line-by-line approvals for how ever many hours that would take.

Accordingly, I ran away in terror, installed meld, set merge-editor to meld, and went clicky-clicky in the GUI. I'm not happy using a GUI, but at least it didn't have a mysterious extra buffer to confuse and taunt me.

Posted on 2026-07-30

Tags: mintings jujutsu

Review: In the House of Aryaman, a Lonely Signal Burns

2026-07-30T03:25:00+00:00

Review: In the House of Aryaman, a Lonely Signal Burns, by Elizabeth Bear

Series:	Sub-Inspector Ferron Mysteries #1
Publisher:	Sobbing Squonk Press
Copyright:	2012
Printing:	2018
ISBN:	0-9863735-1-6
Format:	Kindle
Pages:	73

In the House of Aryaman, a Lonely Signal Burns is a science fiction police procedural set in relatively near-future India. This novella was originally published in Asimov's SF and collected in several anthologies as well as Bear's Shuggoths in Bloom collection, which I have on my shelf but have not yet read. I probably should have checked that before I got another copy. It is the first story of a series in the sense that there is an Audible-only sequel available.

Like many police procedurals, this one opens with a crime scene. Sub-Inspector Ferron and her partner are inspecting a tube of human meat in the middle of the rug of a luxurious apartment in Bengaluru. The tube is apparently the remains of one Dexter Coffin, an American with a high tech workspace who was apparently mangled beyond recognition in his locked apartment near a table set for two.

Dexter's cat is a witness. In this future world of cats enhanced with limited language skills, this would have been very useful, but the cat's memory was apparently wiped. Ferron will have to get to the bottom of the mystery some other way. Also, she apparently now has a new cat.

Meanwhile, Ferron is worrying about her partner's mental health, her partner is worrying about her use of stimulants to stay on duty for this murder investigation, and Ferron's mother is harassing her for money to pay the bills of her virtual reality addiction. Her job is a good distraction from other problems she'd rather not deal with.

I am trying to come up with something insightful to say about this story, and I'm not having much success. It's a police procedural with a bit of a science fiction twist. The characters are fine but not, at least for me, particularly engaging. There is some deft world-building, but nothing that grabbed my attention or made me desperate to read more stories in this world.

Perhaps the most interesting part of the background, and the reason why I picked up this novella, is that this is the universe that eventually becomes the setting of the White Space series. There is an early version of right-minding handled entirely through medicine without the later invention of the fox implant, and there are some signs that humanity is slowly digging itself out of the hole of climate change and antisocial behavior that it had dug. I found this mildly interesting, but it doesn't add much to the later series and is very skippable.

The source of the title is a bright light originating in the Andromeda galaxy, which is contained in Uttara Bhādrapadā in Vedic astrology. Ferron says this is under the influence of the god Aryaman. This is unrelated to the plot; it's just a background event that prompts some introspective musing from Ferron at the end of the story. It's a nice moment, but I would have been more interested in the full story of first contact between Earth and the Synarche.

This was a mildly pleasant way to spend a few hours and I'm already forgetting all of the details. It's a competent story, but not one I feel a need to recommend to others.

Followed by A Blessing of Unicorns, which appears to be an Audible audiobook exclusive.

Rating: 6 out of 10

my harddrive is probably not full

2026-07-29T19:35:30+00:00

I enjoyed reading this post by Marginalia "Your harddrive is probably full"

You can construct an entropic argument that there are simply more ways for a harddrive to be full than ways in which it can be empty.

Of course it made me check how full my laptop drive is, and indeed it was more than 75% full, as predicted.

But, I almost never feel that my hard drive is full. I can very easily free up almost any amount of disk space at any time, without any thought. While writing this blog post, I ran a single command and now my harddrive is 50% empty.

The other part of the equation is that a full disk isn’t a problem until it’s so full you can’t put more stuff on it, and at the point it’s so irredeemably cluttered that when you do clean it up, you only have the patience to clean up enough to bide your time, judging the fate of every file on the harddrive is simply too much work.

Why doesn't this apply to me? Because I have put in the up-front thought to organize things, so that I never have to do that anymore.

I have 3 categories of files that I can remove at any time I need more space, without any thought:

Any files that are stored in git-annex. This is one of git-annex's superpowers; you can git-annex drop any file and stop it using disk space, but the file is still there (as a broken symlink) so you don't risk losing or forgetting about it.
Caches.
Files in ~/tmp/, which is reserved for any files I only want to have a passing acquaintance with. If I'm not comfortable with something being deleted at any time, I don't put it there.

Not only do I only have these 3 categories, these are the only 3 categories for everything except OS files and files I have decided I never want to remove (eg dotfiles and other files stored in git repos).

Computer scientists invented caches (and of course cache invalidation is no problem lol) so I only needed to learn about that one. Unix gave me /tmp/ as an example that I long ago used as the basis for the rules for my ~/tmp/. I hope that git-annex might also serve as an example that moving files between drives is not the best way to manage disk space use.

Review: Midlife in Gretna Green

2026-07-29T02:19:00+00:00

Review: Midlife in Gretna Green, by Linzi Day

Series:	Midlife Recorder #1
Publisher:	Linzi Day
Copyright:	July 2022
ISBN:	9798837010774
Format:	Kindle
Pages:	464

Midlife in Gretna Green is a self-published fantasy novel. It's urban fantasy in the sense that it's set in our world but with magic that most people don't know about, but the primary setting is a parish in rural Scotland and therefore the genre is not urban in that sense. It was Linzi Day's published first novel.

As the story opens, Niki McKnight is a widow in Manchester, England with a job in the Register Office she likes, a boss she hates, and a Bichon Frise dog she adores. In the year since her husband Nick died, she's put her life on hold and made as few decisions as possible, despite some concerned pushing from her best friend Aysha. The death of her grandmother is not entirely unexpected, but her inheritance is about to upend her life.

Niki assumes that her grandmother has a modest cottage and a small estate, and therefore being the named heir will mostly involve cleaning up the details of a modest life. She is caught by surprise by a requirement in the will that she live in Gretna Green for a year and a day in order to inherit. Her initial reaction is to treat this as an absurd impossibility given her life and job in Manchester, but she slowly realizes something strange is going on. Her grandmother's lawyer is lying to her, he refuses to tell her the value of the estate and seems to think it's more valuable than she expected, and her grandmother's tiny cottage does not seem to be following the seasons of the rest of the world. There is something magical at work.

I will not spoil the rest of the reveal. I will say that this is a magical house book because, if you are anything like me, that is why you will want to read this series. There are not enough magical house books, and this is one of the better kind that allow the house to be a full speaking character.

Midlife in Gretna Green is an unapologetic fantasy of personal agency. Niki starts the novel with a miserable manager, a messy pile of unread mail she doesn't want to deal with, and a lot of personal emotional baggage. She gets handed a position that requires and rewards standing up for herself and being decisive. It comes with a pile of unresolved but not horribly complex problems that were waiting for someone who would listen, make sensible decisions, and treat other people with respect. Oh, and there are a few assholes in the way, but they seriously underestimate the power she has to put a stop to their bullshit.

This is the sort of book that traditional publishers tended not to buy (although Day apparently did get an offer for this one and turned it down), and I'm not sure why. Editors thought protagonists should have to work harder for their payoff? Some lingering Calvinist dourness in English language publishing mistrusted triumphant books? Obvious wish fulfillment was considered embarrassing or low-class and thus didn't warrant publication? This didn't apply to the endless bildungsromans about magically talented boys, so some level of sexism was probably in play. Maybe this is finally changing? It reminds me of the bias against romance novels and their guaranteed happily ever after, and in the case of romance there was too much money for publishers to leave it on the table.

In any case, the growth of self-publishing has created an alternative market that let these books reach an audience and I for one am here for it. A lot of wish-fulfillment books, and a lot of self-published books, are not very good, but the ones that have a spark of originality and character can be a delight worth tolerating the somewhat rocky editing and pacing problems that a full editorial staff might have cleaned up.

I loved reading books about kickass women who took no crap and fixed their lives up exactly how they wanted them to be. But how did they get to be that way? They always started out awesome in the books. Seriously, did they kick ass at sixteen? Or did their superpower kickassery not kick in until they were thirty? Forty? If so, then I was screwed. Would I need to wait till I was fifty or until a genie arrived offering wishes? I already felt as if Iâ€™d spent my whole life waiting for something wild and wonderful to happen.

Niki is a Specific Type to a somewhat hilarious degree, and I'm not sure if Day is playing into that intentionally or if she's projecting herself into the book. The amount of self-insertion is not zero: Day also lives in Gretna Green, owns a Bichon Frise, and worked as an assistant registrar and civil celebrant. Niki also drinks wine regularly, has a psychic gift, occasionally reads tarot cards, is an accommodating pushover at work who struggles to say no to her abusive boss, has impostor syndrome problems, and swears by a fictional self-help book about grief that provides the quotes at the starts of chapters. There is a cat, because of course there's a cat.

(The fictional self-help book is a spot-on parody played entirely straight in the story. I think Day is having some fun with the reader? I can't tell!)

This is what I mean by unapologetic. It's easy to read Niki as a stereotype, but she's a stereotype a lot of real people can identify with and there's something highly satisfying in watching her find her footing. I like wish fulfillment books; it's fun to see someone's wishes come true! Particularly in the year of 2026, there's something immensely satisfying in seeing an ordinary, insecure person get a massive amount of power and use it to make the world better. I don't need everything to be hard, fraught, and laden with costs in fiction, although I wouldn't want every book I read to be like this.

Also, the world building is great. It's not polished; there's a bit of a grab bag feeling to it, I'm dubious the magic system has any underlying rigorous rule set, and Niki's powers, once she has access to them, are more of a semi-sentient genie than a skill she has to learn with hard practice. But the magic is fun. The sentient house is one of the best characters, particularly after Niki realizes how underused it has been, and I am a sucker for any good sentient house book. The cat is a far more interesting character than I first thought she would be. And Niki's new magical job is more complicated and less typical than the normal Celtic-inspired fantasy that I thought it was going to be at first.

My primary warning about this book is that Niki starts out beaten down and grieving her dead husband, and it took me about five pages to decide that her dead husband was a complete piece of shit who was not worth any of the grief Niki puts into him. She also doesn't stand up for herself for the first hundred pages or so, which made me want to yell at the book a few times. Both of these problems go away farther into the book, and Niki does eventually figure out that Nick was abusive trash, but I was relieved when the "make endless excuses for worthless men" portion of the story was finally over. You have to stick with it until Niki gets brave enough to try being the protagonist; once that happens, it becomes great fun.

It is fairly obvious that Midlife in Gretna Green was self-published, and I wish it had gotten the editing that it deserved. My copy had a couple of obvious formatting errors, the plot veers about more than was strictly necessary, and I think a careful editing pass could have tightened the writing by about fifty pages or so without losing any important detail. If that sort of thing bothers you, make sure you're in self-published fiction mode before starting this one. But it also has that irrepressible, bubbling-with-ideas feeling of a book where nothing has suppressed the author's enthusiasm. It's a very grabby book; once Niki starts embracing her new life, I could barely put it down.

If you're in the mood for a good fantasy wish-fulfillment story that has no romance and a whole lot of "why are things run this way, no, we're changing that," highly recommended. I had so much fun with this book, and the series is currently making the rounds of my whole family. Don't read this when you're looking for something challenging and literary and deep; save it for when you desperately want to watch someone just fix something for once, damn it.

Followed by Painting the Blues in Gretna Green, which I have already read, breaking my usual rule of writing reviews before reading the next book in a series.

Rating: 8 out of 10

Debian COSMIC: A Fast-Track System Extension & Monorepo Packaging Journey

2026-07-29T00:00:00+00:00

System76â€™s COSMIC Desktop Environmentâ€”written from the ground up in Rustâ€”is one of the most exciting developments in the Linux desktop ecosystem. Built for modern Wayland composition, modularity, and high-performance UX, it has captured the attention of desktop enthusiasts across distributions.

However, for users running Debian Testing or Debian Unstable, getting COSMIC onto their machines traditionally presents a steep hill to climb. The official upstream codebase consists of dozens of independent repositories (cosmic-comp, cosmic-panel, cosmic-applets, cosmic-settings, cosmic-files, and more) along with hundreds of Rust crate dependencies. Packaging each component individually according to strict Debian policy involves filing dozens of ITPs, waiting through NEW queue processing, and managing endless dependency updates.

For someone who simply wants to explore, test, and run COSMIC on Debian today, waiting for full distribution packaging is impractical.

To bridge this gap, we created Debian COSMIC (debian-cosmic)â€”a pragmatic, fast-track delivery pipeline designed to build, package, and run COSMIC Epoch on Debian Testing and Sid right now.

The Fast-Track Pivot: The Monorepo Strategy

Rather than fighting distribution policy or attempting to maintain fifty separate Debian source packages, we leveraged System76’s official cosmic-epoch monorepo releases (e.g. epoch-1.4.0).

By compiling the monorepo in an isolated, sanitized Debian Testing container/chroot, we build the entire COSMIC stackâ€”compositor, panel, settings, launcher, applets, and session helpersâ€”in a single, automated pass.

This approach gives us two primary delivery outcomes:

1. The Monorepo `.deb` (`cosmic-epoch-monorepo.deb`)

For users who prefer standard Debian package management:

A single, unified .deb package containing the entire compiled /usr hierarchy of the COSMIC desktop environment.
Automatically versioned against upstream release tags (e.g. 1.4.0-1) and published to our APT repository and GitHub Releases.

Easily installed via standard apt install:

sudo apt update
sudo apt install cosmic-epoch-monorepo

2. The System Extension (`systemd-sysext`) Overlay

For users who embrace an immutable host philosophy or don’t want external packages mutating their pristine host /usr filesystem:

We package the compiled COSMIC stack into an OCI container image delivered via the GitHub Container Registry (ghcr.io).
Using systemd-sysext, the image is mounted at runtime as a read-only overlay on top of /usr.
When you log into COSMIC, the desktop environment is dynamically merged into your host. When you switch back to GNOME or KDE, a simple helper script (cosmic-toggle) unmerges the overlay, leaving your host filesystem 100% clean and untouched.

ğŸ›¡ï¸� Preventing ABI Drift: The `cosmic-canary` Package

Running a systemd-sysext overlay on a rolling distribution like Debian Testing or Sid introduces a subtle technical challenge: host library ABI drift.

Because the sysext binaries link dynamically against shared C libraries on your host (such as Mesa graphics drivers, DRM, Vulkan, or Pipewire), a routine apt upgrade on your host might update libgbm1 or libdrm2 to a newer version. If the new host library introduces an ABI change, launching COSMIC from an older sysext overlay can cause black screens, broken rendering, or segfaults.

To solve this without cluttering standard Debian packaging, we created an “Early Warning System”: the JIT Canary (cosmic-canary) package.

The Tiered Dependency Model

Generated dynamically at build time using equivs-build (via our generate-cosmic-canary.sh tool), the cosmic-canary package pins your host’s libraries into two distinct zones:

ğŸ”´ The Strict Zone (= dependency): Pinned to the exact version used at build time for volatile graphics and hardware stack components (libmesa, libgbm, libdrm, libvulkan, libdisplay-info, libpixman, libxkbcommon, libinput, libpipewire). If a host apt upgrade attempts to bump Mesa or DRM versions, cosmic-canary blocks the upgrade, alerting you that a sysext rebuild is required before upgrading your host drivers.
ğŸŸ¢ The Relaxed Zone (>= dependency): Pinned with minimum version bounds for stable system layers and protocol libraries (libc6, libgcc, libstdc++, libwayland, libdbus, libpam, libglib, libssl, libx11). Security updates and minor patches to these libraries are allowed through without triggering false alarms.

Quickstart: How to Try Debian COSMIC

Whether you want the unified .deb or the sysext overlay, setting up Debian COSMIC takes only a few minutes.

Method A: APT Repository (.deb)

# 1. Add the GPG key
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://rickysarraf.github.io/debian-cosmic/debian-cosmic.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/debian-cosmic.gpg

# 2. Add the repository
echo "deb [signed-by=/etc/apt/keyrings/debian-cosmic.gpg] https://rickysarraf.github.io/debian-cosmic/ unstable main" | sudo tee /etc/apt/sources.list.d/debian-cosmic.list

# 3. Install COSMIC Monorepo
sudo apt update
sudo apt install cosmic-epoch-monorepo

Method B: System Extension (`sysext`)

If you have systemd >= 248 and Docker installed:

Clone the debian-cosmic repository:

git clone https://github.com/rickysarraf/debian-cosmic.git
cd debian-cosmic

Pull and stage the latest sysext overlay:
```
./bin/cosmic-update
```
Toggle the COSMIC environment on/off whenever you want:
```
./bin/cosmic-toggle
```

Conclusion

debian-cosmic is not intended to replace official, long-term Debian packaging efforts. Instead, it is a fast-track, hacker-friendly playground for early adopters, developers, and testers who want to experience System76â€™s COSMIC Epoch on Debian Testing and Sid right now.

By combining monorepo container builds, systemd-sysext overlays, and cosmic-canary ABI safety checks, we have achieved a fast, clean, and reliable way to run cutting-edge desktop software on Debian without sacrificing system stability.

Check out the debian-cosmic repository on GitHub to contribute, report issues, or try out the latest build!

RcppDate 0.0.7: New Upstream

2026-07-28T13:32:00+00:00

RcppDate ships the featureful date library written by Howard Hinnant to enable use from R packages. This header-only modern C++ library has been in pretty wide-spread use for a while now, and adds to C++11, C++14 and C++17 what is (with minor modifications) the ‘date’ library in C++20. The RcppDate package adds no extra R or C++ code and can therefore be a zero-cost dependency for any other project; yet a number of other projects decided to re-vendor it resulting in less-efficient duplication. Oh well. C’est la vie.

This release syncs with upstream release 3.0.5 made yesterday. We also made two routine updates to the continuous integration since the last release a good year ago. The Debian and r2u packages for this new release have already been uploaded too.

Changes in version 0.0.7 (2026-07-27)

Updated to upstream version 3.0.5

Regular updates to continuous integration setup

Courtesy of my CRANberries, there is also a diffstat report for the most recent release. More information is available at the repository or the package page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.

#057: Conditionally Quieten Compilers

2026-07-27T22:40:00+00:00

Welcome to post 57 in the R⁴ series.

R packages with compiled codes can use the file src/Makevars to set compilation flags. We often rely on this to set libraries, include directories or compilation options. When using external libraries, be it header-only or via headers and linking, we are often experiencing ‘compilation noise’ when these libraries tickle warnings under generally-recommended flags such as -Wall -pedantic. Two packages I maintain are clearly repeat offenders here: Eigen, and BH. Both cam generate pages and pages of compiler output. This is generally not great as it may hide genuine warnings from our own code.

What makes matters worse is that some of the available and specific options for the compilers are treated by R CMD check as ‘non-portable’ leading to a nag on package checking. Examples are -Wno-parentheses, -Wno-maybe-uninitialize or -Wno-nunnull.

I have long resorted to adding these to my per-user ~/.R/Makevars. When added there, compilation is quieter, but R CMD check still nags here where the option is set but not at CRAN or r-universe. A situation that is not ideal but what somewhat ‘stable’.

More recently, I realized there was an available check we can use to conditionally add extra compilation flags but leave them off by default. That makes local development quiet allowing us to focus on the quality of our additions here without noise from third-party libraries we may use. At the same time we do not need to do anything else to let CRAN do its work.

The check we now use is whether there is a .git/ directory present. If so, we are indeed building from local sources and can add extra flags. If not, we are likely building from a tar.gz source archive—which is the case for CRAN—and hence do not set these.

An example use is this recent additional to package qlcal where this bit of R code is invoked from a minimal shell script configure and replaces the stub @XTRAFLAGS@ in src/Makevars.in (or src/Makevars.win.in)

if (dir.exists(".git")) {
    ## development from a .git directory can use these flags
    xtraflags <- "-Wno-nonnull -Wno-deprecated-declarations"
} else {
    ## else build from tarball so stick with existing flags
    xtraflags <- ""
}
win <- if (Sys.info()[["sysname"]] == "Windows") ".win" else ""
infile <- file.path("src", paste0("Makevars", win, ".in"))
outfile <- file.path("src", paste0("Makevars", win))
lines <- readLines(infile)
lines <- gsub("@XTRAFLAGS@", xtraflags, lines)
writeLines(lines, outfile)

With this change, local compilation is quiet, yet CRAN has nothing to nag about (as seen at the qlcal results page).

Similarly, one can also check from an actual configure file written in autoconf. Here is a similar example from RcppEigen (showing some relevants parts of the whole file)

# PKG_CXXFLAGS initialized earlier ...

## Check if building locally
AC_MSG_CHECKING([whether .git/ exists])
if test -d "$srcdir/.git"; then
    AC_MSG_RESULT([yes, adding extra flags])
    AC_SUBST([PKG_CXXFLAGS],["${PKG_CXXFLAGS} -Wno-ignored-attributes -Wno-maybe-uninitialized"])
else
    AC_MSG_RESULT([no, consider adding '-Wno-ignored-attributes -Wno-maybe-uninitialized' to ~/.R/Makevars])
fi

AC_SUBST([PKG_CXXFLAGS], ["${PKG_CXXFLAGS}"])
AC_CONFIG_FILES([src/Makevars])
AC_OUTPUT

Once again, with this change compilation is quiet locally, yet unaffected at CRAN. Just what we want. Give it a try in your packages.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub.

DebConf26 – Santa Fe, Argentina

2026-07-27T20:12:18+00:00

TL;DR: What a great DebConf! I managed to recharge my Debian batteries, and my talks / BoF sessions all went fine. Already looking forward to DebConf in Japan next year!

DebCamp

The evening before DebCamp started, we had a nice bbq (we taught some locals to call it a “braai” at an organiser’s house and went for a walk around the river as the sun set. It was a very peaceful lead-in to DebCamp.

I set up and sent out the call for Forky desktop artwork:
- https://lists.debian.org/msgid-search/910906f3-7ce4-4884-a49f-4b4a5975471b@debian.org
Had many nice discussions about various Debian topics with all the Debian people around. It’s really fun being around people who are natural problem solvers who care deeply about both technical and social issues. At one point Jonas told me “Holy shit, these people are motivated!” and I appreciate that so much too!

Debian LTS wine

Most of my DebCamp was dedicated to preparing for my demo and main talk that followed at DebConf.
Sadly, we had no loopy this year, I just didn’t have the time, and the people who stepped up to help last year were either overwhelmed with other issues or couldn’t make it. I’ll try to make it happen again for next year by kicking it off long before DC27.

View of Santa Fe city from hotel

DebConf

Talk – Is it even possible to build a truly universal system installer?

In this talk I do a very quick comparison of system installers based on my experience with them. It’s hard to directly compare all of them, since there are so many, and each have their own niche that they attempt to satisfy.

I also introduce Yasi – my attempt to answer the question of whether we could build a universal installer, which can also better cover advanced installations, automated installations and niche setups.

It’s very early days for the project, and I didn’t quite feel ready to share the code with the world, but it was nice that I did a quick demo where I could install a Debian system… and the resulting system actually booted up. *phew*.

This is also going to be my main focus for the mid-term future. I aim to have all the basic partitioning options working by the time Debian 14 (Forky) is released, and by the time Debian 15 is released, I have a long list of features that I aim to have working. So, my timeline for having something that’s generally useful is around a year from now, and in around 3 years it should be a fully fledged installer that should cover a very large amount of Debian use cases and architectures.

Day Trip

For the day trip, we did a tour across Santa Fe, visited Constitución de la Nación Argentina, had lunch where we tried various dishes based on local fish from the river, and then went on a boat ride on the river.

BoF Sessions:

Funding in Free Software Projects: I initially registered this BoF because I’m increasingly concerned about how upstreams are asking for donations in their software. I increased the scope to talk about funding in free software in general. It followed Marga’s talk about funding, which focussed more about how developers are funded in general. We didn’t dive very deep into this, but we certainly need some further discussion (and action) on this within Debian.

Debian Social Team: My most important issue for this team is a carry-over from last year, I want to set up barman (packaged in Debian) for live postgres syncing for our larger databases. For the smaller DBs, doing a daily dump is quite cheap. But for Matrix, it’s very expensive in terms if i/o and CPU, so it would be ideal to do less regular complete dumps and use live replication for the first line of redundancy instead.

Images Team: I wasn’t initially planning to say much during this session, I have some ideas to reduce both size and count of images, without losing any benefits, but I don’t have any work to show for that yet. I ended up talking a lot more than I anticipated, the topics covered were quite good and representative of the current state of Debian images built. I don’t have time to create a full summary, so I suggest checking the etherpad / video recording if you’re interested.

Some more wine variety during the conference dinner

Debianites in the main hacklab

Rosario

I’m spending two days in Rosario before I head home. Exploring a bit, catching up with sleep, finishing this blog post, signing keys and exploring some ideas I made note of during DebConf.

Thank you to the DebConf26 Team!

It was a little surreal not being part of any DebConf team for the first time ever, I’ve just been too focussed on getting Yasi ready for my talk (no regrets!). I hope to be more involved again next year, in the meantime, I’m very grateful to everyone who has made this happen, you did a stellar job! I hope to see many of you again next year in Japan!

RcppArmadillo 15.4.2-1 on CRAN: Small Upstream Fixes

2026-07-25T20:56:00+00:00

Armadillo is a powerful and expressive C++ template library for linear algebra and scientific computing. It aims towards a good balance between speed and ease of use, has a syntax deliberately close to Matlab, and is useful for algorithm development directly in C++, or quick conversion of research code into production environments. RcppArmadillo integrates this library with the R environment and languageâ€“and is widely used by (currently) 1293 other packages on CRAN, downloaded 47.8 million times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint / vignette) by Conrad and myself has been cited 710 times according to Google Scholar.

This versions updates to the 15.4.2 upstream Armadillo release made this week, as well as to included 15.4.1 version we released only to GitHub and r-universe so do not exceed the (roughly) monthly cadence. For this release, we had run the usual complete reverse-dependency check which came back spotless, and did CRAN so no email exchange needed despite nearly 1300 reverse dependencies. Automation can be helpful when used with a well-maintained software stack. The package has also already been updated for Debian, built for r2u, and will build shortly at CRAN for the different binary releases.

All changes since the last CRAN release follow.

Changes in RcppArmadillo version 15.4.2-1 (2026-07-25)

Upgraded to Armadillo release 15.4.2 (Medium Roast Agave)

Fix speed regressions in diagvec() and diagmat()

Changes in RcppArmadillo version 15.4.1-1 [github-only] (2026-07-09)

Upgraded to Armadillo release 15.4.1 (Medium Roast Agave)

Fix for rare infinite recursion bug in sparse version of diagmat()

More efficient checks for aliasing

Courtesy of my CRANberries, there is a diffstat report relative to previous release. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the Rcpp R-Forge page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.

WordPress 7.0.2 for Debian

2026-07-21T07:22:36+00:00

I have just uploaded WordPress version 7.0.2 for Debian. This fixes two serious security bugs CVE-2026-60137 and CVE-2026-63030. Chained together, this gives a RCE and is in active exploitation, so update as soon as its available.

These two bugs are also in WordPress 6.9.x below 6.9.5 and the SQLi one (CVE-2026-60137) only is in 6.8.x below 6.8.6. Debian Sid and Forky have 7.0 which is vulnerable to the RCE while Debian Trixie has 6.8.x so only the SQLi.

Updates for Trixie have been sent to the security team for review and once they’re happy I’ll upload for Trixie as well.

Interzone digital

2026-07-20T21:26:22+00:00

(no, this isn't a blog post about Joy Division songs)

Last time I wrote about Interzone, I was discussing issue #294, the first published under new management in a paperback-sized format ("JB6"). The format and presentation of the magazine was fantastic: it fit in a lot of my pockets, and was packed with 15 stories as well as the regular columns, in full colour with fantastic layouts and illustrations. Sadly there was only one more physical issue before Interzone was forced to become a digital-only publication.

IZ issues 294 and 295

I don't want to dwell on the sad necessity to move to digital. Interzone continues on, celebrating the milestone issue #300 in 2024. Subscriptions are managed via Patreon. Issue #305 just came out.

Instead I wanted to write a small bit about how I engaged with the paper magazine, and the difficulties I've had trying to engage with not just Interzone but any magazine-style publication in a digital context.

With most fiction, I read linearly: start the beginning and read to the end, in order. That works well for me with e-readers. But for magazines (and most non-fiction) I don't, I jump around: usually starting with the table of contents, I might pick a short column to start, or jump into the middle of the "book reviews" section to read about a specific book. I might skip sections entirely. I find it very difficult to read like this with an e-reader. I think this is partly because I reference the depth of the paper book or magazine, its thickness, to orient myself. But it's also partly the limitations of e-ink.

My tick-list for an issue of IZ

For print-Interzone, I used to start by inserting a small piece of paper inside the cover (the delivery slip was ideal). On this I listed the stories within and ticked them off when I read them (sometimes I double-ticked if I really liked a story). That helped me to remember, perhaps months or years later, whether I'd read all the stories or not, and which I liked. I could do something similar on some e-readers: the Remarkable for instance. But it's far from convenient to do on most e-ink devices.

Interzone digital is available as both ePUB, the most common format for e-books, and PDF. For reading on my regular Kobo e-reader, PDFs don't work very well at all. I think this is generally true of most e-readers.

Interzone was (and is) a well-designed magazine. The value of it was not just the content of the text, but the context: how the stories were presented; the accompanying art (most often colour in recent decades), but also the typesetting. ePUB doesn't specify much of that stuff exactly: it leaves that up to the client and the client's preferences. And there's a lot of advantages to that: Prefer a different font face or size? No problem. And most importantly for accessibility: If reading in ePUB makes Interzone available to more readers then that's a great thing. But sadly a lot is lost, IMHO.

IZ #305 on iPad Mini

The solution I'm trying is to read the PDF version on the iPad Mini I resurrected earlier in the year. Despite being an Internet tablet, since it's not really usable for browsing the web anymore it's strangely still a distraction-free device. In fact it's pretty much single-purpose for reading Interzone and the odd other book which benefits from being read as PDF. I can appreciate the stylistic choices made in the page-setting as they were intended; I can quickly jump around the issue without waiting for an e-ink refresh; I get full colour; and whilst it would be tiring to read for a long time on the iPad screen, for the length of articles or stories in a magazine, this isn't a problem.

It's not a solution for tracking what I've read (that version of ipadOS is too old to support clumsily scrawling on PDF pages with your fingers, at least in the Books app) but it otherwise seems to work well, so I'll see how it goes.

Renewal relationships between AWS certifications

2026-07-20T20:52:17+00:00

When you pass an AWS certification exam, sometimes it can extend the life of related lesser AWS certifications. But I could not find an illustration of exactly which ones, so here’s an up-to-date diagram:

Figure: Renewal relationships between AWS certifications.

Each arrow is a ‘renews’ relation – there’s no obligation to pass lesser exams before the harder ones, but you could also follow the arrows backwards if you want to learn easier material before sitting the more difficult exams.

I have made two important simplifications to the graph:

The ‘Advanced Networking – Specialty’ certification is being retired soon, so I’ve omitted it entirely. The last date to take that exam is 25th August 2026. But Specialty certs don’t renew anything else anyway.
I have left out transitive relationships in order to simplify the graph – so e.g. if you pass a ‘Solutions Architect – Professional’ exam, it also renews any Cloud Practitioner certificate you might hold, even if you do not currently hold the relevant Associate certificate.

You also have the option of sitting each exam again to renew of course, and there’s a new scheme to ‘maintain’ various certs via AWS Skill Builder which can extend them by one year rather than three.

DebConf26 starts today in Santa Fe on Monday, July 20, 2026

2026-07-20T09:50:00+00:00

DebConf26, the 27th annual Debian Developer Conference, is taking place at Santa Fe, Argentina from 20 to 25 July 2026. Debian contributors from all over the world have come together at the Facultad de Ingeniería en Ciencias Hídricas (Faculty of Engineering in Water Sciences), one of the faculties that belong to the Universidad Nacional del Litoral (National University of the Littoral), to participate and work in a conference exclusively ran by volunteers.

Today the main conference starts with around 300 expected attendants and over 80 scheduled activities, including 45-minute and 20-minute talks, Bird of a Feather ("BoF") team meetings, workshops, a job fair, as well as a variety of other events. The full schedule is updated each day, including activities planned ad-hoc by attendees over the course of the conference.

If you would like to engage remotely, you can follow the video streams available from the DebConf26 website for the events happening in the three main talk rooms: Aula Magna - FADU, Aula Magna - FBCB and Aula 0.3 - FICH accessible from the DebConf26 homepage. You can also join the conversations happening inside the talk rooms via the OFTC IRC network in the #debconf-fadu, #debconf-fbcb, and #debconf-fich3 channels. Please also join us in the #debconf channel for common discussions related to DebConf.

You can also follow the live coverage of news about DebConf26 provided by our micronews service or the @debian profile on your favorite social network.

DebConf is committed to a safe and welcoming environment for all participants. Please see our Code of Conduct page for more information on this.

Debian thanks the commitment of numerous sponsors to support DebConf26, particularly our Platinum Sponsors: Infomaniak and Proxmox.

DebConf26 welcomes its sponsors

2026-07-18T12:00:00+00:00

DebConf26, the 27th edition of the Debian conference is taking place at the Facultad de Ingeniería en Ciencias Hídricas of the Universidad Nacional del Litoral, in Santa Fe, Argentina. We appreciate the organizers for their hard work, and hope this event will be highly beneficial for those who attend in person as well as online.

This event would not be possible without the help from our generous sponsors. We would like to warmly welcome the sponsors of DebConf26, and introduce them to you.

We have two Platinum sponsors.

Our first Platinum sponsor is Proxmox. Proxmox develops powerful, yet easy-to-use open-source server solutions. The comprehensive open-source ecosystem is designed to manage divers IT landscapes, from single servers to large-scale distributed data centers. Our unified platform integrates server virtualization, easy backup, and rock-solid email security ensuring seamless interoperability across the entire portfolio. With the Proxmox Datacenter Manager, the ecosystem also offers a "single pane of glass" for centralized management across different locations. Since 2005, all Proxmox solutions have been built on the rock-solid Debian platform. We are proud to return to DebConf26 as a sponsor because the Debian community provides the foundation that makes our work possible. We believe in keeping IT simple, open, and under your control.
Infomaniak is the second Platinum sponsor. Infomaniak is an independent, employee-owned Swiss technology company that designs, develops, and operates its own cloud infrastructure and digital services entirely in Switzerland. With over 300 employees — more than 70% engineers and developers — the company reinvests all profits into R&D. Its public cloud is built on OpenStack, with managed Kubernetes, Database as a Service, object storage, and sovereign AI services accessible via OpenAI- compatible APIs, all running on its own Swiss infrastructure. Infomaniak also develops a sovereign collaborative suite — messaging, email, storage, online office tools, videoconferencing, and a built-in AI assistant — developed in- house and as a privacy-respecting solution to proprietary platforms. Open source is central to how Infomaniak operates. Its latest data center (D4) runs on 100% renewable energy and uses no traditional cooling: all the heat generated by its servers is captured and fed into Geneva's district heating network, supplying up to 6,000 homes in winter and hot water year-round. The entire project has been documented and open-sourced at d4project.org.

Our Gold sponsors are:

Freexian, Freexian specializes in Free Software with a particular focus on Debian GNU/Linux. Freexian can assist with consulting, training, technical support, packaging, or software development on projects involving use or development of Free software. All of Freexian's employees and partners are well-known contributors in the Free Software community, a choice that is integral to Freexian's business model.
Viridien an advanced technology, digital and Earth data company that pushes the boundaries of science for a more prosperous and sustainable future. Viridien has been using Debian-based systems to power most of its HPC infrastructure and its cloud platform since 2009 and currently employs two active Debian Project Members.

Our Silver sponsors are:

Arm: leading technology provider of processor IP, Arm powered solutions have been supporting innovation for more than 30 years and are deployed in over 280 billion chips to date.
Pexip brings the ease of commercial video platforms to secure and sovereign environments without compromising control or performance.
The Bern University of Applied Sciences with around 7,959 students enrolled, located in the Swiss capital.
Ubuntu, the Operating System delivered by Canonical.
OS-Sci, Open Source Science is a world-leading institution dedicated to teaching computer science through Free and Open Source Software (FOSS).
gcoop, a free software development company with over 19 years of market experience, organized as a worker cooperative, promoting best practices in software development.
Qualcomm Technologies, one of the world's leading companies in field of mobile technology, sponsors and contributes to Open Source developer communities that drive collaboration.
Civil Infrastructure Platform, a collaborative project hosted by the Linux Foundation, establishing an open source “base layer” of industrial grade software.
Siemens is a technology company focused on industry, infrastructure and transport.
Collabora, a global consultancy delivering Open Source software solutions to the commercial world.
NERDEARLA, the largest free tech event in the Spanish-speaking world.

Bronze sponsors:

And finally, our Supporter level sponsors:

A special thanks to the Facultad de Ingeniería y Ciencias Hídricas - FICH UNL, our Venue Partner!

Thanks to all our sponsors for their support! Their contributions enable a diverse global community of Debian developers and maintainers to collaborate, support one another, and share knowledge at DebConf26.

Looking at dpkg startup time

2026-07-15T07:45:00+00:00

Five years or so ago, I had a look at trying to speed up dpkg's package installation; I concluded that it was probably possible to speed up, but that there was no appetite for this kind of large-scale changes. (You'd probably need to rewrite the transaction system to get rid of a lot of fsyncs, you'd ideally want to reduce the number of syscalls for unpack by io_uring and so on.)

This summer, I've been looking at something related on and off; it is possible to speed up the startup time? That's in a sense the opposite scenario; instead of installing lots of packages in a newly debootstrapped chroot (with very few packages), see how fast you can install one in a much more busy chroot (I just copied my laptop's dpkg dir, with ~6600 packages installed).

Before I show the numbers, I must stress that this is an investigation, not a fair benchmark, and you should not go shout at the dpkg maintainers that they need to get to “catch up”. That said:

> sudo time dpkg --root=root -i hello_2.12.3-1_amd64.deb >/dev/null
Not building database; man-db/auto-update is not 'true'.
1.12user 0.49system 0:01.85elapsed 87%CPU (0avgtext+0avgdata 171880maxresident)k
0inputs+14648outputs (0major+72963minor)pagefaults 0swaps

> sudo time ./src/dpkg --root=root -i hello_2.12.3-1_amd64.deb > /dev/null
0.04user 0.01system 0:00.15elapsed 38%CPU (0avgtext+0avgdata 6520maxresident)k
0inputs+1080outputs (0major+2705minor)pagefaults 0swaps

How is it unfair? Well, for one, the code to run triggers is messed up so they're not run (but the trigger in question should be very fast). And there's one step at the end with detecting “disappearing packages” that doesn't run properly because it's a bit tricky in my model and I didn't want to deal with, well, difficult problems. But I think both are perfectly doable without really affecting the end time, it just requires engineering. There's a lot of work to be done, though; diving into the code makes me shudder at all the complexities that need to be in place to support all the corner cases of multiarch, for instance.

The code is extremely proof-of-concept, but it runs and can read (and write) metadata from SQLite instead of flat text files, it can resolve dependencies in the most basic fashion, it can keep track of installed files, it should be crash- and powerloss-proof. You know, the very very basic stuff, and without changing the model fundamentally (like e.g. Michael Stapelberg did with distri, fundamentally replacing packages with disk images and ending up in a very fast but rather different-looking system). So it was satisfying to see that it ends up around 10x even on my not-very-new laptop (plus a significant RAM reduction); I believe it should be possible to squeeze under 100 ms, but that would probably require also optimizing the unpacking itself, which I didn't look at this time.

Having a bunch of files being read into RAM and then processed freely was a design that made a lot of sense when dpkg was written (in 1995!) and Debian had ~250 binary packages in total (and you probably wouldn't install all of them). There was no reasonable database available for desktop systems; the closest thing you'd have was probably BerkeleyDB and that wasn't really it, so flat files and fsync made a lot of sense, and was easy to manipulate and persist. But now, SQLite is widely available and probably the most battle-tested code in history, a typical system has thousands of packages (you could easily install tens of thousands if you're doing heavy development), SSDs have replaced HDDs almost everywhere for system disks, and the environment has just changed a lot in general. So I hope that someone at some point will be crazy enough to pick this up and run with it, because it's a lot of work and I don't intend to. :-)

PS: I didn't look at apt; I think what I'd really love to see first and foremost is a package format change so that apt-listchanges can look at (or look for) NEWS.gz without having to unpack the entire package. Perhaps a control field saying “nothing new here”?

Got your keys ready for DebConf26?

2026-07-14T21:23:21+00:00

Yay! Finally itâ€™s that time of year â€” DebCamp is underway, and soon it will be time for DebConf! î�½ðŸŽ‰ðŸ¥³

As it is by now tradition, itâ€™s my task to coordinate the DebConf26 keysigning party. And, as usual, I have set up the list of DebConf26 keysigning maps for everybody involved.

So, if you are taking part of DebConf, make sure to:

Find yourself in the keysigning map. Are you a part of the listing?
- If you are not there, log in to the DebConf26 management system and edit the Personal Information section of your profile. Make sure you submit your OpenPGP key fingerprint.
- Make sure your key is available in the keyserver network. They should basically be equivalent and interoperate, but in any case â€” my scripts will try to find your key at pgpkeys.eu, keys.openpgp.org, keyserver.computer42.org, keyserver.ubuntu.com, keyring.debian.org, pgp.surf.nl, pgp.pm, pgp.mit.edu, the.earth.li.
Make sure your name is readable and matches what you want others to sign. If it does not, edit your key and upload it now!
Remember that, as announced, the deadline for the final list is on Thursday, 2026.07.16, 09:00 GMT-3 (Argentinian time).

zed-xdebug

2026-07-14T10:46:20+00:00

Nextcloud PHP debugging with Xdebug in Zed editor

I started to switch from PhpStorm to Zed as IDE recently as Zed is open source and has a much smaller footprint and is more slick than PhpStorm.

One thing that I didn't get running immediately was Xdebug integration, so I did a bit of research and asked Claude for help. Here's a quick writeup of how to get it running.

I have Zed installed as Flatpak on a Debian Trixie host system.

The PHP process runs in a nextcloud-docker-dev Docker container.

Install Zed and configure debugging there

Install Zed: flatpak install flathub dev.zed.Zed

In Zed: open the Extensions view and install PHP.

Configure the debugger:

Create ~/.var/app/dev.zed.Zed/config/zed/debug.json:

[
  {
    "label": "PHP: Listen to Xdebug",
    "adapter": "Xdebug",
    "request": "launch",
    "port": 9003,
    "pathMappings": {
      "/var/www/html":             "/home/<user>/devel/nextcloud/server",
      "/var/www/html/apps-extra":  "/home/<user>/devel/nextcloud/server/apps-extra",
      "/var/www/html/apps-shared": "/home/<user>/devel/nextcloud/apps-shared"
    }
  }
]

Add one entry per bind-mounted app directory.

After creating the file, restart Zed.

Inside Zed, select "debugger: start" from command palette and then "PHP: Listen to Xdebug".

Verify Zed is listening. Running ss -tlnp | grep 9003 on the host should show *:9003 with Zed as the process.

Configure Xdebug inside the container

/usr/local/etc/php/conf.d/xdebug.ini:

xdebug.mode = debug
xdebug.idekey = PHPSTORM
xdebug.trace_output_name=trace.%R.%u
xdebug.profiler_output_name=profile.%R.%u
xdebug.output_dir=/shared/xdebug

xdebug.log = /var/log/xdebug.log
xdebug.log_level = 3

; Try to discover the client host, otherwise fall back to the docker host
xdebug.discover_client_host=true
xdebug.client_host=host.docker.internal

; When you cannot specify a trigger, use "xdebug.start_with_request = yes" to autostart debugging for all requests
; https://xdebug.org/docs/all_settings#start_with_request
xdebug.start_with_request = trigger

; Set xdebug.mode trace to use this
; More details at https://derickrethans.nl/flamboyant-flamegraphs.html
xdebug.trace_format=3
xdebug.trace_output_name=xdebug.%R.%u

Apply changes by restarting apache in the container: apache2ctl -k graceful

Notes:

host.docker.internal resolves on Linux Docker only if the container was started with --add-host=host.docker.internal:host-gateway (nextcloud-docker-dev already does this).
discover_client_host = true makes xdebug follow X-Forwarded-For - useful behind Nextcloud's dev reverse proxy.

Test xdebug with a PHP command inside the container

Run XDEBUG_SESSION=PHPSTORM php occ status inside the container and check /var/log/xdebug.log.

Install the browser extension

Install Xdebug Helper (Firefox/Chrome). In its preferences, set the IDE Key to PhpStorm. It will set the XDEBUG_SESSION cookie when toggled to Debug.

Click the Xdebug Helper icon in the browser and set it to Debug.

Test Xdebug with browser extension

Load the URL that exercises the code path with the breakpoint. Zed should stop the code exection at the breakpoint.

Reproducible Builds in June 2026

2026-07-11T19:27:22+00:00

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

In these reports, we outline the most important things that we have been up to over the past month. As a quick recap about what problem our project intends to solve, whilst anyone may inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries. The motivation behind the reproducible builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised or not.

If you are interested in contributing to the project, please visit our Contribute page on our website.

In this monthâ€™s report, we cover:

Only installing reproducible packages with repro-threshold

A very interesting demonstration is now available showing how you might configure your Debian system to only install packages that have been reproduced by m/n rebuilders.

This is implemented via a reproduced+https:// APT transport ( a mechanism for communicating between the APT client and its repository source â€” commonly HTTP):

Every package download is intercepted by repro-threshold, which queries two independent rebuilders for a signed attestation before allowing installation to proceed. [It] is important to note that [an] install will only succeed if all package dependencies are also reproducible.

The demo gives examples of how to quickly experiment with this using a Docker container.

Distribution work

In Debian this month:

The debian-installer package in Debian was uploaded with a substantial reproducibility-related changelog. This means, for the first time, the uploaded version could finally be reproduced.
Various OpenJDK packages were also uploaded to Debian, including the fix for JDK-8385738 (â€œJavadoc does not produce reproducible outputâ€¦â€�) (for example).Â [â€¦][â€¦][â€¦]
The â€œreasonâ€� pages on reproduce.debian.net, such as the one for ppc64el, now feature links labeled with the bug emoji (i.e. ğŸ�›) which links to the categorized issues packages have been tagged with in the reproducible-notes.git repo.
Indeed, 25 reviews of Debian packages were added, 31 were updated and 33 were removed this month adding to our extensive knowledge about identified issues. Two issue types were updated as well.Â [â€¦][â€¦]

The IzzyOnDroid Android APK repository reached its next milestone this month, now covering 2 out of every 3 apps (66.7%) with reproducible builds. Their documentation for debugging and fixing failed builds has steadily grown as well. More clients have picked up showing reproducibility results (e.g. Droid-ify), and Neo Store now can be configured to stick to only reproducible applications. Further, an independent builder has been added to the build farm, increasing the trust level even more as APK builds can have multiple confirmations now.

At the same time, IzzyOnDroidâ€™s rbtlog got several new features. The most outstanding is caching for frequently used resources such as reproducible-apk-tools, command-line tools and NodeJS in order to counter ongoing issues with GitHub availability, while at the same time saving bandwidth and build time. This change also enables some other some smaller enhancements such as being able to configure build timeouts per recipe for those builds running longer than the average, release pattern filtering for update checks or having a field for maintainer notes to shortly summing up e.g. why a reproducible build failed.

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

diffoscope development

Debian adds an extra Flags: line in the output of ocamlobjinfo, so adjust the test for cross-distribution compatibility.Â [â€¦]
Bump debhelper compatibility level to 14.Â [â€¦]
Fix compatibility with Ocaml 5.4.1.Â [â€¦]
Use --long-form-style arguments when calling apktool in order to support apktool version 3.Â [â€¦]
Support Androguard version 4 and previous versions at the same time.Â [â€¦]
Update copyright years.Â [â€¦]

In addition, Jochen Sprickerhof added better header detection for the Sphinx documentation systemÂ [â€¦], Michael Daniels fixed the tests when run with zipdetails version 4.006Â [â€¦] and Zbigniew JÄ™drzejewski-Szmek added a version of the deprecated os.path.commonprefix methodÂ [â€¦].

In addition, Vagrant Cascadian updated diffoscope in GNU Guix to version 321 and 323.

Chris Lamb also made the following changes to strip-nondeterminism, our tool to remove specific non-deterministic results from a completed build:

Skip symlinks when manually called via /usr/bin/strip-nondeterminism.Â (#1139000)
Update debian/watch format.Â [â€¦]
Drop Rules-Requires-Root: no and Priority: optional fields.Â [â€¦]
Bump Standards-Version to version 4.7.4.Â [â€¦]

From our mailing listâ€¦

On our mailing list this month:

kpcyrd posted to our mailing list regarding the â€œwaves of malware uploads to aur.archlinux.orgâ€�. Curiously, â€œevery incident I looked at used npmjs.com for malware deliveryâ€�, specifically where the npm package includes an (automatically executed) preinstall script that is an ELF binary.
kpcyrd also announced the release of debian-repro-status version 0.4.0, a tool written â€œto give you an approximate idea of how viable it would be to enforce a â€˜reproducible packages onlyâ€™ update policy for the computer system youâ€™ve builtâ€�:

The change updates dependencies to the latest versions, and adds support for multiple -H options, to query results from multiple rebuilderd instances. The results are also now fetched concurrently.
kpcyrd also reported that, whilst taking a screenshot for the above release, they noticed that the debian:sid container now is 100% reproducible.
Finally, kpcyrd also created a pull request against the add-determinism package to update the itertools and zip Python dependencies.

Documentation updates

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

Chris Lamb added a reminder re. using the UTC variants of the Javascript Date methods.Â [â€¦]
Mattia Rizzolo moved OTF to the â€˜oldâ€™ sponsors list. Thank you for your support!.Â [â€¦]
kpcyrd updated the Rust documentation to recommend using the --release argument for consistency.Â [â€¦]

Patches

Bernhard M. Wiedemann:
Chris Lamb:
- #1139654 filed against node-fuse.js.
- #1139655 filed against node-egjs-hammerjs.
- #1139656 filed against node-chartjs-adapter-date-fns.
- #1139662 filed against mkdocs-include-markdown-plugin.
- #1139704 filed against lmarbles.
- #1140240 filed against rocm-docs-core.
- #1140567 filed against libecoli.
- #1140688 filed against golang-github-tobischo-gokeepasslib.
Jochen Sprickerhof:
- #1139457 filed against c-munipack.
- #1140365 filed against latex-coffee-stains.
- #1140366 filed against cxxtest.
- #1140367 filed against slime.
- #1140368 filed against spooles.
- #1140369 filed against sdpb.
- #1140645 filed against procmail.
- #1140676 filed against proftpd-dfsg.
- #1141059 filed against mah-jong.
- #1141133 filed against dxf2gcode.
- #1141194 filed against afterstep.
- #1141195 filed against ledger2beancount.
- #1141196 filed against ocamlviz.
Kris Van Hee and Vagrant Cascadian:
- #1140167 filed against dtrace.

Four new scholarly papers

Kenichiro Muto and Kuniyasu Suzaki of the Institute of Information Security in Yokohama, Japan published an interesting paper this month titled Attestable Build Chain: Enabling Trust in Reproducible Builds (PDF). Their abstract is as follows:

Ensuring trust in software supply chains requires verifying not only artifacts but also the processes that produce them. Although Reproducible Builds (R-B) require rebuilding to validate artifacts, they cannot verify whether the build was executed with the intended toolchain and inputs and may reproduce unintended or compromised builds without detection. We present Attestable Build Chain, a framework for externally verifying build-time execution without rebuilding. Rather than preventing compromise, it provides verifiable, tamper-evident evidence of actual build-time execution, enabling verification of build process integrity from observed file accesses during the build. [â€¦]

Julien Malka, Stefano Zacchiroli and ThÃ©o Zimmermann published a 50-page report detailing A Decade of Software Reproducibility in the Nix Package Ecosystem:

We find that functional package management enables extremely high rebuildability over time (near-universal ability to reconstitute historical build environments and rebuild software packages), while bitwise reproducibility has steadily improved and reaches a high point in recent years (up to 93% in 2024). Early years show substantially lower bitwise reproducibility, indicating that functional package management alone does not guarantee bitwise-identical outputs, and that the observed high level of bitwise reproducibility is not solely due to the package management approach. Common causes of unreproducibility, both in the rebuildability and bitwise reproducibility dimensions, include management of dates in build and test processes; we quantify their prevalence and other common causes using manual analysis of logs of rebuild failures and automated analysis of diffoscope.

A PDF of their report is available online

Tim Bastin of L3montree GmbH and Jacek Galowicz of Applicative Systems GmbH from DevGuard published a paper detailing How We Built a Sovereign, Reproducible Container Supply Chain for DevGuard:

This paper presents how the DevGuard project rebuilt its OCI container pipeline around reproducible Nix builds and independent dual-platform digest verification. DevGuard images are built hermetically from pinned source revisions, signed with Sigstore/Cosign, and verified through digest comparison across GitHub Actions and sovereign GitLab infrastructure hosted on container.gov.de. We describe the practical integration of reproducible OCI image builds into existing CI/CD workflows and argue that independently reproducible container digests provide a stronger integrity guarantee against build tampering than provenance alone. The paper further discusses remaining trust assumptions and the relevance of sovereign build infrastructure for government and regulated environments.

Finally, Yiseul Choi, Junga Kim, Jun-Ho Hong and Seongmin Kim of the Department of Convergence Security Engineering at the Sungshin Womenâ€™s University in Seoul, Korea titled Attestation-based verification of SBOM integrity via consumer-side reproducibility:

Software bills of materials (SBOMs) support supply chain transparency, but they do not prove that a delivered SBOM reproducibly corresponds to its software artifact. Existing signing and provenance mechanisms protect integrity and traceability, yet lack consumer-side reproducible verification. We propose an SBOM integrity verification framework combining procedure disclosure, consumer-side reproduction, authority-generated reference evidence, and digest comparison. A trusted authority records a reference digest, and consumers compare it with locally reproduced and delivered SBOM digests. Experiments on 100 real-world container images show detection of artifact tampering, SBOM substitution, distribution modification, and adaptive tampering beyond signature-based approaches

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