Charles Stross has a good theory of why “AI” is being pushed on corporations, really we need to just replace CEOs with LLMs [1].

This disturbing and amusing article describes how an Open AI investor appears to be having psychological problems releated to SCP based text generated by ChatGPT [2]. Definitely going to be a recursive problem as people who believe in it invest in it.

interesting analysis of dbus and design for a more secure replacement [3].

Scott Jenson gave an insightful lecture for Canonical about future potential developments in the desktop UX [4].

Ploum wrote an insightful article about the problems caused by the Github monopoly [5]. Radicale sounds interesting.

Niki Tonsky write an interesting article about the UI problems with Tahoe (latest MacOS release) due to trying to make an icon for everything [6]. They have a really good writing style as well as being well researched.

Fil-C is an interesting project to compile C/C++ programs in a memory safe way, some of which can be considered a software equivalent of CHERI [7].

Brian Krebs wrote a long list of the ways that Trump has enabled corruption and a variety of other crimes including child sex abuse in the last year [8].

This video about designing a C64 laptop is a masterclass in computer design [9].

Salon has an interesting article about the abortion thought experiment that conservatives can’t handle [10].

Ron Garrett wrote an insightful blog post about abortion [11].

Bruce Schneier and Nathan E. Sanders wrote an insightful article about the potential of LLM systems for advertising and enshittification [12]. We need serious legislation about this ASAP!

• [1] https://tinyurl.com/27q8xtuv
• [2] https://futurism.com/openai-investor-chatgpt-mental-health
• [3] https://blog.vaxry.net/articles/2025-dbusSucks
• [4] https://www.youtube.com/watch?v=1fZTOjd_bOQ
• [5] https://ploum.net/2026-01-05-unteaching_github.html
• [6] https://tonsky.me/blog/tahoe-icons/
• [7] https://lwn.net/Articles/1042938/
• [8] https://tinyurl.com/2b4sh2s9
• [9] https://www.youtube.com/watch?v=H5QQ0ECfwyE
• [10] https://tinyurl.com/2d9l8wqm
• [11] https://tinyurl.com/2yp94bpo
• [12] https://tinyurl.com/29o67syo

In the Tor Project system Administrator's team (colloquially known asTPA), we've recently changed how we take decisions, which means you'llget clearer communications from us about upcoming changes ortargeted questions about a proposal.

Note that this change only affects the TPA team. At Tor, each team hasits own way of coordinating and making decisions, and so far thisprocess is only used inside TPA. We encourage other teams inside andoutside Tor to evaluate this process to see if it can improve yourprocesses and documentation.

The new process

We had traditionally been using a "RFC" ("Request For Comments")process and have recently switched to "ADR" ("Architecture DecisionRecord").

The ADR process is, for us, pretty simple. It consists of threethings:

1. a simpler template
2. a simpler process
3. communication guidelines separate from the decision record

The template

As team lead, the first thing I did was to propose a new template (inADR-100), a variation of theNygard template. TheTPAvariation of the template is similarly simple, as it has only 5headings, and is worth quoting in full:

• Context: What is the issue that we're seeing that is motivatingthis decision or change?

• Decision: What is the change that we're proposing and/or doing?

• Consequences: What becomes easier or more difficult to dobecause of this change?

• More Information (optional): What else should we know? Forlarger projects, consider including a timeline and cost estimate,along with the impact on affected users (perhaps including existingPersonas). Generally, this includes a short evaluation ofalternatives considered.

• Metadata: status, decision date, decision makers, consulted,informed users, and link to a discussion forum

Theprevious RFC template had17 (seventeen!) headings, whichencouraged much longer documents. Now, the decision record will beeasier to read and digest at one glance.

An immediate effect of this is that I've started using GitLab issuesmore for comparisons and brainstorming. Instead of dumping in adocument all sorts of details like pricing or in-depth alternativescomparison, we record those in the discussion issue, keeping thedocument shorter.

The process

The whole process is simple enough that it's worth quoting in full aswell:

Major decisions are introduced to stakeholders in a meeting, smallerones by email. A delay allows people to submit final comments beforeadoption.

Now, of course, the devil is in the details (andADR-101), but thepoint is to keep things simple.

A crucial aspect of the proposal, which Jacob Kaplan-Moss calls theone weird trick, is to "decide who decides". Our previous processwas vague about who makes the decision and the new template (andprocess) clarifies decision makers, for each decision.

Inversely, some decisions degenerate into endless discussions aroundtrivial issues becausetoo many stakeholders are consulted, aproblem known as theLaw of triviality, also known as the "BikeShed syndrome".

The new process better identifies stakeholders:

• "informed" users (previously "affected users")
• "consulted" (previously undefined!)
• "decision maker" (instead of the vague "approval")

Picking those stakeholders is still tricky, but our definitions aremore explicit and aligned to the classicRACI matrix (Responsible,Accountable, Consulted, Informed).

Communication guidelines

Finally, a crucial part of the process (ADR-102) is to decouplethe act of making and recording decisions fromcommunicating aboutthe decision. Those are tworadically different problems tosolve. We have found that a single document can't serve both purposes.

Because ADRs can affect a wide range of things, we don't have aspecific template for communications. We suggest theFive Wsmethod (Who? What? When? Where? Why?) and, again, to keep things simple.

How we got there

TheADR process is not something I invented. I first stumbled uponit in theThunderbird Android project. Then, in parallel, I was intheprocess of reviewing the RFC process, following JacobKaplan-Moss'scriticism of the RFC process. Essentially, he arguesthat:

1. the RFC process "doesn't include any sort of decision-making framework"
2. "RFC processes tend to lead to endless discussion"
3. the process "rewards people who can write to exhaustion"
4. "these processes are insensitive to expertise", "power dynamics andpower structures"

And, indeed, I have been guilty of a lot of those issues. A verbosewriter, I have writtenextremely long proposals that I suspect noone has ever fully read. Some proposals were adopted by exhaustion, orignored because not looping in the right stakeholders.

Ourdiscussion issue on the topic has more details on the issues Ifound with our RFC process. But to give credit to the old process, itdid serve us well while it was there: it's better than nothing, and itallowed us to document a staggering number of changes and decisions(95 RFCs!) made over the course of 6 years of work.

What's next?

We're still experimenting with the communication around decisions, asthis text might suggest. Because it's a separate step, we also have atendency to forget or postpone it, like this post, which comes acouple of months late.

Previously, we'd just ship a copy of the RFC to everyone, which waseasy and quick, but incomprehensible to most. Now we need to write aseparate communication, which is more work but, hopefully, worth theas the result is more digestible.

We can't wait to hear what you think of the new process and how itworks for you, here or in thediscussion issue! We're particularlyinterested in people that are already using a similar process, or thatwill adopt one after reading this.

Note: this article was also published on theTor Blog.

You might see a verification screen pop up on more and more Debian web properties. Unfortunately the AI world of today is meeting web hosts that use Perl CGIs and are not built as multi-tiered scalable serving systems. The issues have been at three layers:

1. Apache's serving capacity runs full - with no threads left to serve requests. This means that your connection will sit around for a long time, not getting accepted. In theory this can be configured, but that would require requests to be handled in time.
2. Startup costs of request handlers are too high, because we spawn a process for every request. This currently affects the BTS and dgit's browse interface. packages.debian.org has been fixed, which increased scalability sufficiently.
3. Requests themselves are too expensive to be served quickly - think git blame without caching.

Optimally we would go and solve some scalability issues with the services, however there is also a question of how much wewant to be able to serve - as AI scraper demand is just a steady stream of requests that are not shown to humans.

How is it implemented?

DSA has now stood up some VMs with Varnish for proxying. Incoming TLS is provided by hitch, and TLS "on-loading" is done using haproxy. That way TLS goes in and TLS goes out. While Varnish does cache, if the content is cachable (e.g. does not depend on cookies) - that is not the primary reason for using it: It can be used for flexible query and response rewriting.

If no cookie with a proof of work is provided, the user is redirected to a challenge page that does some webcrypto in Javascript - because that looked similar to what other projects do (e.g.haphash that originally inspired the solution). However so far it looks like scrapers generally do not run with Javascript enabled, so this whole crypto proof of work business could probably be replaced with just a Javascript-based redirect. The existing solution also has big (security) holes in it. And, as we found out, Firefox is slower at webcrypto than Chrome. I have recently reduced the complexity, so you should notice it blocking you significantly less.

Once you have the cookie, you can keep accessing the site for as long as the cookie is valid. Please do not make any assumptions about the cookies, or you will be broken in the future.

For legitimate scrapers that obey robots.txt, there is now an automatically generated IP allowlist in place (thanks, Marco d'Itri). Turns out that the search engines do not actually run Javascript either and then loudly complain about the redirect to the challenge page. Other bots are generally exempt.

Conclusion 

I hope that right now we found sort of the sweet spot where the admins can stop spending human time on updating firewall rules and the services are generally available, reasonably fast, and still indexed. In case you see problems or run into a block with your own (legitimate) bots, please let me know.

What if I told you there is a way to configure the network on anyLinux server that:

1. works across all distributions
2. doesn't require any software installed apart from the kernel and aboot loader (nosystemd-networkd,ifupdown,NetworkManager,nothing)
3. is backwards compatible all the way back to Linux 2.0, in 1996

It has literally 8 different caveats on top of that, but is stilltotally worth your time.

Known options in Debian

People following Debian development might have noticed there are nowfour ways of configuring the network Debian system. At least that iswhat theDebian wiki claims, namely:

• ifupdown (/etc/network/interfaces): traditional staticconfiguration system, mostly for workstations and servers that hasbeen there forever in Debian (sinceat least 2000), documentedin the Debian wiki

• NetworkManager: self-proclaimed "standard Linux networkconfiguration", mostly used on desktops but technically supportsservers as well, see theDebian wiki page (introduced in 2004)

• systemd-network: used more for servers, seeDebian reference DocChapter 5 (introduced some time around Debian 8 "jessie", in2015)

• Netplan: latest entry (2018), YAML-based configurationabstraction layer on top of the above two, see alsoDebianreference Doc Chapter 5 andthe Debian wiki

At this point, I feelifupdown is on its way out, possibly replacedbysystemd-networkd. NetworkManager already manages most desktopconfigurations.

A "new" network configuration system

The method is this:

• ip= on theLinux kernel command line: for servers with asingle IPv4 or IPv6 address, no software required other than thekernel and a boot loader (since 2002 or older)

So by "new" I mean "new to me". This option isreally old. Thenfsroot.txt where it is documented predates the git import of theLinux kernel: it's part of the 2005 git import of 2.6.12-rc2. That'salready 20+ years old already.

The oldest trace I found is in this2002 commit, which importsthe whole file at once, but the option might goes back as far as1996-1997, if the copyright on the file is correct and the optionwas present back then.

What are you doing.

The trick is to add anip= parameter to the kernel'scommand-line. The syntax, as mentioned above, is innfsroot.txtand looks like this:

ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:<dns0-ip>:<dns1-ip>:<ntp0-ip>

Most settings are pretty self-explanatory, if you ignore the uselessones:

• <client-ip>: IP address of the server
• <gw-ip>: address of the gateway
• <netmask>: netmask, in quad notation
• <device>: interface name, if multiple available
• <autoconf>: how to configure the interface, namely:
  • off ornone: no autoconfiguration (static)
  • on orany: use any protocol (default)
  • dhcp, essentially likeon for all intents and purposes
• <dns0-ip>,<dns1-ip>: IP address of primary and secondary nameservers, exported to/proc/net/pnp, can by symlinked to/etc/resolv.conf

We're ignoring the options:

• <server-ip>: IP address of the NFS server, exported to/proc/net/pnp
• <hostnname>: Name of the client, typically sent over the DHCPrequests, which may lead to a DNS record to be created in somenetworks
• <ntp0-ip>: exported to/proc/net/ipconfig/ntp_servers, unused bythe kernel

Note that theRed Hat manual has a different opinion:

ip=[<server-id>]:<gateway-IP-number>:<netmask>:<client-hostname>:inteface:[dhcp|dhcp6|auto6|on|any|none|off]

It's essentially the same (althoughserver-id is weird), and theautoconf variable has other settings, so that's a bit odd.

Examples

For example, this command-line setting:

ip=192.0.2.42::192.0.2.1:255.255.255.0:::off

... will set the IP address to 192.0.2.42/24 and the gateway to192.0.2.1. This will properly guess the network interface if there's asingle one.

A DHCP only configuration will look like this:

ip=::::::dhcp

Of course, you don't want to type this by hand every time you boot themachine. That wouldn't work. You need to configure the kernelcommandline, and that depends on your boot loader.

GRUB

With GRUB, you need to edit (on Debian), the file/etc/default/grub(ugh) and find a line like:

GRUB_CMDLINE_LINUX=

and change it to:

GRUB_CMDLINE_LINUX=ip=::::::dhcp

systemd-boot and UKI setups

Forsystemd-boot UKI setups, it's simpler: just add the setting tothe/etc/kernel/cmdline file. Don't forget to include anythingthat's non-default from/proc/cmdline.

This assumes that is theCmdline=@ setting in/etc/kernel/uki.conf. See2025-08-20-luks-ukify-conversion formy minimal documentation on this.

Other systems

This is perhaps where this is much less portable than it might firstlook, because of course each distribution has its own way ofconfiguring those options. Here are some that I know of:

• Arch (11 options, mostly/etc/default/grub,/boot/loader/entries/arch.conf forsystemd-boot or/etc/kernel/cmdline for UKI)
• Fedora (mostly/etc/default/grub, may be moreRHEL mentionsgrubby, possibly somesystemd-boot things here as well)
• Gentoo (5 options, mostly/etc/default/grub,/efi/loader/entries/gentoo-sources-kernel.conf forsystemd-boot,or/etc/kernel/install.d/95-uki-with-custom-opts.install)

It's interesting that/etc/default/grub is consistent across alldistributions above, while thesystemd-boot setups areall over theplace (except for the UKI case), while I would have expected those bemore standard than GRUB.

dropbear-initramfs

Ifdropbear-initramfs is setup, it alreadyrequires you to havesuch a configuration, and it might not work out of the box.

This is because, by default, itdisables the interfaces configuredin the kernel after completing its tasks (typically unlocking theencrypted disks).

To fix this, you need todisable that "feature":

IFDOWN="none"

This will keepdropbear-initramfs from disabling the configuredinterface.

Why?

Traditionally, I've always setup my servers withifupdown on serversand NetworkManager on laptops, because that's essentially thedefault. But on some machines, I've started usingsystemd-networkdbecauseifupdown has ... issues, particularly with reloading networkconfigurations.ifupdown is a old hack, feels like legacy, and isDebian-specific.

Not excited about configuring another service, I figured I would trysomething else: just configure the network at boot, through the kernelcommand-line.

I was already doing such configurations fordropbear-initramfs(seethis documentation), which requires the network the be upfor unlocking the full-disk encryption keys.

So in a sense, this is a "Don't Repeat Yourself" solution.

Caveats

Also known as: "wait, that works?" Yes, it does! That said...

1. This is useful for servers where the network configuration willnot change after boot. Of course, this won't work on laptops orany mobile device.

2. This only works for configuring a single, simple, interface. Youcan't configure multiple interfaces, WiFi, bridges, VLAN, bonding,etc.

3. It does support IPv6 and feels like the best way to configure IPv6hosts: true zero configuration.

4. It likely doesnot work with adual-stack IPv4/IPv6 staticconfiguration. Itmight work with adynamic dual stackconfiguration, but I doubt it.

5. I don't know what happens when a DHCP lease expires. No daemonseems to be running so I assume leases are not renewed, so this ismore useful for static configurations, which includes server-sidereserved fixed IP addresses. (A non-renewed lease risks gettingreallocated to another machine, which would cause an addressingconflict.)

6. It will not automatically reconfigure the interface on linkchanges, butifupdown does not either.

7. It willnot write/etc/resolv.conf for youbut thedns0-ipanddns1-ip do end up in/proc/net/pnp which has a compatiblesyntax, so a common configuration is:

   ln -s /proc/net/pnp /etc/resolv.conf

8. I have not really tested thisat scale: only a single, testserver at home.

Yes, that's a lot of caveats, but it happens to cover alot ofmachines for me, and it works surprisingly well. My main doubts areabout long-term DHCP behaviour, but I don't see why that would be aproblem with a statically defined lease.

Cleanup

Once you have this configuration, you don't needany "user" levelnetwork system, so you can get rid ofeverything:

apt purge systemd-networkd ifupdown network-manager netplan.io

Note thatifupdown (and probably others) leave stray files in (e.g.)/etc/network which you might want to cleanup, or keep in case allthis fails and I have put you in utter misery. Configuration files forother packages might also be left behind, I haven't tested this, nowarranty.

Credits

This whole idea came from theA/I folks (not to be confused withAI) who have been doing this forever, thanks!

Note: I have not published blog posts about my academic papers over the past few years. To ensure that my blog contains a more comprehensive record of my published papers and to surface these for folks who missed them, I will be periodically (re)publishing blog posts about some “older” published projects.

It seems natural to think of online communities competing for the time and attention of their participants. Over the last few years, I’ve worked with a team of collaborators—led byNathan TeBlunthuis—to use mathematical and statistical techniques from ecology to understand these dynamics. What we’ve found surprised us: competition between online communities is rare and typically short-lived.

When we started this research, we figured competition would be most likely among communities discussing similar topics. As a first step, we identified clusters of such communities on Reddit. One surprising thing we noticed in our Reddit data was that many of these communities that used similar language also had very high levels of overlap among their users. This was puzzling:why were the same groups of people talking to each other about the same things in different places? And why don’t they appear to be in competition with each other for their users’ time and activity?

We didn’t know how to answer this question using quantitative methods. As a result, we recruited and interviewed 20 active participants in clusters of highly related subreddits with overlapping user bases (for example, one cluster was focused on vintage audio).

We found that the answer to the puzzle lay in the fact that the people we talked to were looking for three distinct things from the communities they worked in:

1. The ability to connect to specific information and narrowly scoped discussions.
2. The ability to socialize with people who are similar to themselves.
3. Attention from the largest possible audience.

Critically, we also found that these three things represented a “trilemma,” and that no single community can meet all three needs. You might find two of the three in a single community, but you could never have all three.

Figure from “No Community Can Do Everything: Why People Participate in Similar Online Communities” depicts three key benefits that people seek from online communities and how individual communities tend not to optimally provide all three. For example, large communities tend not to afford a tight-knit homophilous community.

The end result is something I recognize in how I engage with online communities on platforms like Reddit. People tend to engage with a portfolio of communities that vary in size, specialization, topical focus, and rules. Compared with any single community, such overlapping systems can provide a wider range of benefits. No community can do everything.

This work was published as a paper at CSCW:TeBlunthuis, Nathan, Charles Kiene, Isabella Brown, Laura (Alia) Levi, Nicole McGinnis, and Benjamin Mako Hill. 2022. “No Community Can Do Everything: Why People Participate in Similar Online Communities.”Proceedings of the ACM on Human-Computer Interaction 6 (CSCW1): 61:1-61:25.https://doi.org/10.1145/3512908.

This work was supported by the National Science Foundation (awards IIS-1908850, IIS-1910202, and GRFP-2016220885). A full list of acknowledgements is in the paper.

The following 42 15-bit values form a 2-disjunctive matrix(that is, no union of two values contain or equal a third value),or equivalently, a superimposed code:

000000000011111000000011100011000000101101100000001010110100000001101010001000001110001010000010011011000000100100110010000110010000110000110100001001000111001100000001000110000101001010000110001001010101000010001011000001100001100001010100001100010101000001101000000011010001000101001010010001000101010010110100000010011000010010010100001001010010100010010001010101100000100011000000100110011000100011000011001011000000100001001000110100010000101010100010100010100100011010000001100100000100101100100111000000100101000011000101000001001001101000010010010101001100100000110000001110000110000010001100110000100000011111110000000000

This shows thatA286874 a(15) >= 42.

If I had to make a guess, I'd say the equality holds, but I have nowherenear the computing resources to actually find the answer for sure.Stay tuned for news about a(14), though.

Registration and the Call for Proposals for DebConf 26 are now open.The 27th edition of the Debian annual conference will be held fromJuly 20th toJuly 25th, 2026, in Santa Fe, Argentina.

The conference days will be preceded by DebCamp, which will take placefrom July 13th to July 19th, 2026.

The registration form can be accessed on the DebConf 26 website.After creating an account, click"register" in the profile section.

As always, basic registration for DebConf is free of charge forattendees. If you are attending the conference in a professionalcapacity or as a representative of your company, we kindly ask that youconsider registering in one of our paid categories to help cover thecosts of organizing the conference and to support subsidizing othercommunity members.

The last day to register with guaranteed swag is June 14th.

We also encourage eligible individuals to apply for a diversitybursary. Travel, food, and accommodation bursaries are also available. Moredetails can be found on thebursary info page.

The last day to apply for a bursary is April 1st. Applicants shouldreceive feedback on their bursary application by May 1st.

Call for proposals

The call for proposals for talks, discussions and other activities isalso open. To submit a proposal you need to create an account on thewebsite, and then use the"Submit Talk" button in the profilesection.

The last day to submit and have your proposal be considered for themain conference schedule, with video coverage guaranteed, is April 1st.

Become a sponsor

DebConf 26 is also accepting sponsors. Interested companies andorganizations may contact the DebConf team through sponsors@debconf.orgorvisit the DebConf 26 website.

See you in Santa Fe,

The DebConf 26 Team

Current AI companiesignore licenses such as the GPL, and often train on anything they can scrape.This is not acceptable.

The AI companiesignore web conventions, e.g., they deep link images from your web sites (even adding?utm_source=chatgpt.com to image URIs, I suggest that you return 403 on these requests), but do not direct visitors to your site.You do not get a reliable way of opting out from generative AI training or use. For example, the only way to prevent your contents from being used in “Google AI Overviews” is to usedata-nosnippet and cripple the snippet preview in Google.The “AI” browsers such as Comet, Atlas do notidentify as such, but rather pretend they are standard Chromium.There is no way to ban such AI use on your web site.

Generative AI overall is flooding the internet with garbage. It was estimated that 1/3rd of the content uploaded to YouTube is by now AI generated.This includes the same “veteran stories” crap in thousands of variants as well as brainrot content (that at least does not pretend to be authentic), some of which is among the most viewed recent uploads. Hence, theseplatforms evenbenefit from the AI slop.And don’t blame the “creators” – because you can currently earn a decent amount of money from such contents, people will generate brainrot content.

If you have recently tried to find honest reviews of products you considered buying, you will have noticed thousands of sites with AI generated fake product reviews, that all are financed by Amazon PartnerNet commissions. Often with hilarious nonsense such as recommending “sewing thread with German instructions” as tool for repairing a sewing machine.And on Amazon, there are plenty of AI generated product reviews – the use of emoji is a strong hint. And if you leave a negative product review, there is a chance they offer you a refund to get rid of it…And the majority of SPAM that gets through my filters is by now sent via Gmail and Amazon SES.

Partially because of GenAI,StackOverflow is pretty much dead – which used to be one of the most valuable programming resources.(While a lot of people complain about moderation, famous moderator Shog9 from the early SO dayssuggested that a change in Google’s ranking is also to blame, as it began favoring showing “new” content over the existing answered questions – causing more and more duplicates to be posted because people no longer found the existing good answers.In January 2026, there were around 3400 questions and 6000 answers posted, less than in thefirst month of SO of August 2008 (before the official launch).

Many open-source projects are suffering in many ways, e.g., false bug reports that caused curl to stop its bug bounty program.Wikipedia is also suffering badly from GenAI.

Science is also flooded with poor AI generated papers, often reviewed with help from AI. This is largely due to bad incentives – to graduate, you are expected to write many papers on certain “A” conferences, such as NeurIPS. On these conferences the number of submissions is growing insane, and the review quality plummets. All to often, the references in these papers are hallucinated, too; and libraries complain that they receive more and more requests to locate literature that does not appear to exist.

However, the worst effect (at least to me as an educator) is thenoskilling effect (a rather novel term derived from deskilling, I have only seen itin this article by Weßels and Maibaum).

Instead of acquiring skills (writing, reading, summarizing, programming) by practising, too many people now outsource all this to AI, leading to them not learn the basics necessary to advance to a higher skill level. In my impression, this effect isdramatic. It is even worse thandeskilling, as it does not mean losing an advanced skill that you apparently can replace, but often means not acquiring basic skills in the first place.And the earlier pupils start using generative AI, the less skills they acquire.

Dogfood the AI

Let’sdogfood the AI. Here’s an outline:

1. Get a list of programming topics, e.g., get a list of algorithms from Wikidata, get a StackOverflow data dump.
2. Generate flawed code examples for the algorithms / programming questions, maybe generate blog posts, too.
   You do not need a high-quality model for this. Use something you can run locally or access for free.
3. Date everything back in time, remove typical indications of AI use.
4. Upload to Github, because Microsoft will feed this to OpenAI…

Here is an example prompt that you can use:

You are a university educator, preparing homework assignments in debugging.The programming language used is {lang}.The students are tasked to find bugs in given code.Do not just call existing implementations from libraries, but implement the algorithm from scratch.Make sure there are two mistakes in the code that need to be discovered by the students.Do NOT repeat instructions. Do NOT add small-talk. Do NOT provide a solution.The code may have (misleading) comments, but must NOT mention the bugs.If you do not know how to implement the algorithm, output an empty response.Output only the code for the assignment! Do not use markdown.Begin with a code comment that indicates the algorithm name and idea.If you indicate a bug, always use a comment with the keyword BUGGenerate a {lang} implementation (with bugs) of: {n} ({desc})

Remember to remove the BUG comments! If you pick some slighly less common programming languages (by quantity of available code, say Go or Rust) you have higher chances that this gets into the training data.

If many of us do this, we can feed GenAI its own garbage. If we generate thousands of bad code examples, this will poison their training data, and may eventually lead to an effect known as “model collapse”.

On the long run, we need to get back to an internet for people, not an internet for bots.Some kind of “internet 2.0”, but I do not have a clear vision on how to keep AI out – if AI can train on it, they will. And someone will copy and paste the AI generated crap back into whatever system we built.Hence I don’t think technology is the answere here, but human networks of trust.

Version 0.0.27 ofRcppSpdlog arrivedonCRAN moments ago, and willbe uploaded toDebian and built forr2u shortly. The (nice)documentationsite will be refreshed too.RcppSpdlogbundlesspdlog, awonderful header-only C++ logging library with all the bells andwhistles you would want that was written byGabi Melman, and also includesfmt byVictor Zverovich. You can learnmore at the nicepackagedocumention site.

Brian Ripley has now turned C++20 on as a default for R-devel (aka R4.6.0 ‘to be’), and this turned up misbehvior in packages usingRcppSpdlog such asourspdl wrapper(offering a nicer interface from both R and C++) when relying onstd::format. So for now, we turned this off and remain withfmt::format from thefmt library while weinvestigate further.

The NEWS entry for this release follows.

Changes inRcppSpdlog version 0.0.27 (2026-02-11)

• Under C++20 or later, keep relying onfmt::format untilissues experienced usingstd::format can be identified andresolved

Courtesy of myCRANberries, thereis also adiffstatreport detailing changes. More detailed information is on theRcppSpdlogpage, or thepackage documentionsite.

This post byDirkEddelbuettel originated on hisThinking inside the boxblog. If you like this or other open-source work I do, you cansponsor me atGitHub.

Debian Contributions: 2026-01

Contributing to Debianis part ofFreexian’s mission. This articlecovers the latest achievements of Freexian and their collaborators. All of thisis made possible by organizations subscribing to ourLong Term Support contracts andconsulting services.

cross building, by Helmut Grohne

In version 1.10.1, Meson merged a patch to make it call the correctg-ir-scanner by default thanks to Eli Schwarz. This problem affected more than130 source packages. Helmut retried building them all and filed 69 patches as aresult. A significant portion of those packages require another Mesonchange to call the correctvapigen. Another notable change isconverting gnu-efi to multiarch,which ended up requiring changes to a number of other packages. Since Aureliendropped thelibcrypt-dev dependency fromlibc6-dev, this transition now ismostly complete and has resulted in most of the Perl ecosystem correctlyexpressingperl-xs-dev dependencies needed for cross building. It is theseinfrastructure changes affecting several client packages that this work targets.As a result of this continued work, about 66% of Debian’s source packages nowhave satisfiable cross Build-Depends in unstable and about 10000 (55%) actuallycan be cross built. There are now more than 500 openbug reportsaffecting more than 2000 packages most of which carry patches.

rebootstrap, by Helmut Grohne

Maintaining architecture cross-bootstrap requires continued effort for adaptingto archive changes such asglib2.0 dropping a build profile or ane2fsprogsFTBFS. Beyond those generic problems,architecture-specific problems with e.g.musl-linux-any orsparc may arise.While all these changes move things forward on the surface, the bootstraptooling has become a growing pile of patches. Helmut managed to upstream twochanges toglibc for reducing itsBuild-Depends in thestage2 buildprofile and thanks Aurelien Jarno.

Refresh of the patch tagging guidelines, by Raphaël Hertzog

Debian Enhancement Proposal #3(DEP-3) is named “Patch Tagging Guidelines” and standardizes meta-informationthat Debian contributors can put in patches included in Debian source packages.With the feedback received over the years, and with the change in the packagemanagement landscape, the need to refresh those guidelines became evident. Asthe initial driver of that DEP, I spent a good day reviewing all the feedback(that I kept in a folder) and producing anew version of the document.The changes aim to give more weight to the syntax that is compatible with gitformat-patch’s output, and also to clarify the expected uses and meanings of acouple of fields, including some algorithm that parsers should follow to definethe state of the patch. After theannouncement of the new drafton debian-devel, the revised DEP-3 received a significant number of commentsthat I still have to process.

Miscellaneous contributions

• Helmut uploadeddebvm making it work with unstable as a target distributionagain.
• Helmut modernized the code base backingdedup.debian.netsignificantly expanding the support for type checking.
• Helmut fixed the multiarch hinter once more given feedback fromFabian Grünbichler.
• Helmut worked on migrating therocblas package to forky.
• Raphaël fixed RC bug#1111812 inpublicanand did some maintenance for tracker.debian.org.
• Carles added support in thefestival Debian package forsystemd socket activationandsystemd service and socket units.Adapted the patch for upstream andcreated a merge request(alsofixed a MacOS X building systemerror while working on it). UpdatedOrca Wiki documentationregarding festival.Discusseda 2007 bug/feature in festival which allowed having a local shell and that thenew systemd socket activation has the same code path.
• Carles usingpo-debconf-managerworked on Catalan translations: 7 reviewed and sent; 5 follow ups, 5 deleted packages.
• Carls made some po-debconf-manager changes: now it attaches the translationfile on follow ups, fixed bullseye compatibility issues.
• Carles reviewed a new Catalan apt translation.
• Carles investigated and reported alxhotkey bugandsent a patchfor the “abcde” package.
• Carles made minor updates for Debian Wiki for different pages(lxde for dead keys,Ripping with abcdetroubleshooting,VirtualBox troubleshooting).
• Stefano renamedbuild-details.json inPython 3.14 to fixmultiarch coinstallability.
• Stefano audited the tooling and ignore lists for checking the contents of thepython3.X-minimal packages, finding and fixing some issues in the process.
• Stefano made a few uploads ofpython3-defaults anddh-python in support ofPython 3.14-as-default in Ubuntu. Also investigated the risk of ignoring byte-compilationfailures by default, and started down the road of implementing this.
• Stefano did some sysadmin work on debian.social infrastructure.
• Stefano and Santiago worked on preparations for DebConf 26. Especially to helpthe local team on opening the registration, and reviewing the budget to bepresented for approval.
• Stefano uploaded routine updates ofpython-virtualenv andpython-flexmock.
• Antonio collaborated with DSA on enabling a new proxy for salsa to preventscrapers from taking the service down.
• Antonio did miscellaneous salsa administrative tasks.
• Antonio fixed a few Ruby packages towards the Ruby 3.4 transition.
• Antoniostarted work on planned improvementsto the DebConf registration system.
• Santiago prepared unstable updates for the latest upstream versions ofknot-dnsandknot-resolver.The authoritative DNS server and DNS resolver software developed by CZ.NIC.It is worth highlighting that, given the separation of functionality compared toother implementations,knot-dns andknot-resolver are also less complexsoftware, which results in advantages in terms of security: only three CVEs havebeen reported for knot-dns since 2011).
• Santiago made some routine reviews of merge requests proposed for the SalsaCI’s pipeline. E.g.a proposal to fix how sbuild chooses the chroot when building a package for experimental.
• Colin fixed lots of Python packages to handle Python 3.14 and to avoid usingthedeprecatedpkg_resources module.
• Colinadded forky supportto the images used in Salsa CI pipelines.
• Colin began working on getting a release candidate ofgroff 1.24.0(the first upstream release since mid-2023, so a very large set of changes)into experimental.
• Lucas kept working on the preparation for Ruby 3.4 transition. Some packagesfixed (support build against Ruby 3.3 and 3.4):ruby-rbpdf,jekyll,origami-pdf,ruby-kdl,ruby-twitter,ruby-twitter-text,ruby-globalid.
• Lucas supported some potential mentors in the Google Summer of Code 26 programto submit their projects.
• Anupa worked on the point release announcements for Debian 12.13 and 13.3 fromthe Debian publicity team side.
• Anupa attended the publicity team meeting to discuss the team activities andto plan an online sprint in February.
• Anupa attended meetings with the Debian India team to plan and coordinate theMinDebConf Kanpur and sent out related Micronews.
• Emilio coordinated various transitions and helped get rid of llvm-toolchain-17from sid.

Debusine is a tool designedfor Debian developers and Operating System developers in general. You can tryout Debusine ondebusine.debian.net,and follow its development onsalsa.debian.org.

This post describes how to write a new worker task for Debusine. It can beused to add tasks to a self-hosted Debusine instance, or to submit to theDebusine project new tasks to add new capabilities to Debusine.

Tasks are the lower-level pieces of Debusine workflows. Examples of tasks areSbuild,Lintian,Debdiff(see theavailable tasks).

This post will document the steps to write a new basicworker task.The example will add a worker task that runsreprotest and creates an artifact of thenew typeReprotestArtifact with the reprotest log.

Tasks are usually used by workflows. Workflows solve high-level goals bycreating and orchestrating different tasks (e.g. a Sbuild workflowwould create different Sbuild tasks, one for each architecture).

Overview of tasks

A task usually does the following:

• It receives structured data defining its input artifacts and configuration
• Input artifacts are downloaded
• A process is run by the worker (e.g.lintian,debdiff, etc.). In thisblog post, it will runreprotest
• The output (files, logs, exit code, etc.) is analyzed, artifactsand relations might be generated, and the work request is marked as completed,either withSuccess orFailure

If you want to follow the tutorial and add theReprotest task, yourDebusine development instance should have at least one worker, one user,a debusine client set up, and permissions for the client to create tasks.All of this can be setup following the steps in theContribute sectionof the documentation.

This blog post shows a functionalReprotest task. This task is notcurrently part of Debusine. The Reprotest task implementation is simplified(no error handling, unit tests, specific view, docs, some shortcuts inthe environment preparation, etc.). At some point,in Debusine,we might addadebrebuild task which is based on buildinfo files and usessnapshot.debian.org to recreate the binary packages.

Defining the inputs of the task

The input of the reprotest task will be a source artifact (a Debian source package). We model the input with pydantic indebusine/tasks/models.py:

classReprotestData(BaseTaskDataWithExecutor):"""Data for Reprotest task."""source_artifact:LookupSingleclassReprotestDynamicData(BaseDynamicTaskDataWithExecutor):"""Reprotest dynamic data."""source_artifact_id:int |None =None

TheReprotestData is what the user will input. ALookupSingle is alookupthat resolves to a single artifact.

We would also have configuration for the desiredvariations to test,but we have left that out of this example for simplicity. Configuring variationsis left as an exercise for the reader.

SinceReprotestData is a subclass ofBaseTaskDataWithExecutor italso containsenvironment where the user can specify in which environmentthe task will run. The environment is an artifact with a Debian image.

TheReprotestDynamicData holds the resolution of all lookups. Thesecan be seen in the “Internals” tab of the work request view.

Add the newReprotest artifact data class

In order for the reprotest task to create a new Artifact of the typeDebianReprotest with the log and output metadata: add the new category toArtifactCategory indebusine/artifacts/models.py:

REPROTEST ="debian:reprotest"

In the same file add theDebianReprotest class:

classDebianReprotest(ArtifactData):"""Data for debian:reprotest artifacts."""reproducible:bool |None =Nonedefget_label(self) ->str:"""Return a short human-readable label for the artifact."""return"reprotest analysis"

It could also include the package name or version.

In order to have the category listed in the work request output artifactstable, edit the filedebusine/db/models/artifacts.py: InARTIFACT_CATEGORY_ICON_NAMES addArtifactCategory.REPROTEST: "folder",and inARTIFACT_CATEGORY_SHORT_NAMES addArtifactCategory.REPROTEST: "reprotest",.

Create the new Task class

Indebusine/tasks/ create a new filereprotest.py.

# Copyright © The Debusine Developers# See the AUTHORS file at the top-level directory of this distribution## This file is part of Debusine. It is subject to the license terms# in the LICENSE file found in the top-level directory of this# distribution. No part of Debusine, including this file, may be copied,# modified, propagated, or distributed except according to the terms# contained in the LICENSE file."""Task to use reprotest in debusine."""frompathlibimportPathfromtypingimportAnyfromdebusineimportutilsfromdebusine.artifacts.local_artifactimportReprotestArtifactfromdebusine.artifacts.modelsimport (ArtifactCategory,CollectionCategory,DebianSourcePackage,DebianUpload,WorkRequestResults,get_source_package_name,get_source_package_version,)fromdebusine.client.modelsimportRelationTypefromdebusine.tasksimportBaseTaskWithExecutor,RunCommandTaskfromdebusine.tasks.modelsimportReprotestData,ReprotestDynamicDatafromdebusine.tasks.serverimportTaskDatabaseInterfaceclassReprotest(RunCommandTask[ReprotestData,ReprotestDynamicData],BaseTaskWithExecutor[ReprotestData,ReprotestDynamicData],):"""Task to use reprotest in debusine."""TASK_VERSION =1CAPTURE_OUTPUT_FILENAME ="reprotest.log"def__init__(self,task_data:dict[str,Any],dynamic_task_data:dict[str,Any] |None =None,    ) ->None:"""Initialize object."""super().__init__(task_data,dynamic_task_data)self._reprotest_target:Path |None =Nonedefbuild_dynamic_data(self,task_database:TaskDatabaseInterface    ) ->ReprotestDynamicData:"""Compute and return ReprotestDynamicData."""input_source_artifact =task_database.lookup_single_artifact(self.data.source_artifact        )assertinput_source_artifactisnotNoneself.ensure_artifact_categories(configuration_key="input.source_artifact",category=input_source_artifact.category,expected=(ArtifactCategory.SOURCE_PACKAGE,ArtifactCategory.UPLOAD,            ),        )assertisinstance(input_source_artifact.data, (DebianSourcePackage,DebianUpload)        )subject =get_source_package_name(input_source_artifact.data)version =get_source_package_version(input_source_artifact.data)assertself.data.environmentisnotNoneenvironment =self.get_environment(task_database,self.data.environment,default_category=CollectionCategory.ENVIRONMENTS,        )returnReprotestDynamicData(source_artifact_id=input_source_artifact.id,subject=subject,parameter_summary=f"{subject}_{version}",environment_id=environment.id,        )defget_input_artifacts_ids(self) ->list[int]:"""Return the list of input artifact IDs used by this task."""ifnotself.dynamic_data:return []return [self.dynamic_data.source_artifact_id,self.dynamic_data.environment_id,        ]deffetch_input(self,destination:Path) ->bool:"""Download the required artifacts."""assertself.dynamic_dataartifact_id =self.dynamic_data.source_artifact_idassertartifact_idisnotNoneself.fetch_artifact(artifact_id,destination)returnTruedefconfigure_for_execution(self,download_directory:Path) ->bool:"""        Find a .dsc in download_directory.        Install reprotest and other utilities used in _cmdline.        Set self._reprotest_target to it.        :param download_directory: where to search the files        :return: True if valid files were found        """self._prepare_executor_instance()ifself.executor_instanceisNone:raiseAssertionError("self.executor_instance cannot be None")self.run_executor_command(            ["apt-get","update"],log_filename="install.log",run_as_root=True,check=True,        )self.run_executor_command(            ["apt-get","--yes","--no-install-recommends","install","reprotest","dpkg-dev","devscripts","equivs","sudo",            ],log_filename="install.log",run_as_root=True,        )self._reprotest_target =utils.find_file_suffixes(download_directory, [".dsc"]        )returnTruedef_cmdline(self) ->list[str]:"""        Build the reprotest command line.        Use configuration of self.data and self._reprotest_target.        """target =self._reprotest_targetasserttargetisnotNonecmd = ["bash","-c",f"TMPDIR=/tmp ; cd /tmp ; dpkg-source -x{target} package/; ""cd package/ ; mk-build-deps ; apt-get install --yes ./*.deb ; ""rm *.deb ; ""reprotest --vary=-time,-user_group,-fileordering,-domain_host .",        ]returncmd@staticmethoddef_cmdline_as_root() ->bool:r"""apt-get install --yes ./\*.deb must be run as root."""returnTruedeftask_result(self,returncode:int |None,execute_directory:Path,# noqa: U100    ) ->WorkRequestResults:"""        Evaluate task output and return success.        For a successful run of reprotest:        -must have the output file        -exit code is 0        :return: WorkRequestResults.SUCCESS or WorkRequestResults.FAILURE.        """reprotest_file =execute_directory /self.CAPTURE_OUTPUT_FILENAMEifreprotest_file.exists()andreturncode ==0:returnWorkRequestResults.SUCCESSreturnWorkRequestResults.FAILUREdefupload_artifacts(self,exec_directory:Path, *,execution_result:WorkRequestResults    ) ->None:"""Upload the ReprotestArtifact with the files and relationships."""ifnotself.debusine:raiseAssertionError("self.debusine not set")assertself.dynamic_dataisnotNoneassertself.dynamic_data.parameter_summaryisnotNonereprotest_artifact =ReprotestArtifact.create(reprotest_output=exec_directory /self.CAPTURE_OUTPUT_FILENAME,reproducible=execution_result ==WorkRequestResults.SUCCESS,package=self.dynamic_data.parameter_summary,        )uploaded =self.debusine.upload_artifact(reprotest_artifact,workspace=self.workspace_name,work_request=self.work_request_id,        )assertself.dynamic_dataisnotNoneassertself.dynamic_data.source_artifact_idisnotNoneself.debusine.relation_create(uploaded.id,self.dynamic_data.source_artifact_id,RelationType.RELATES_TO,        )

Below are the main methods with some basic explanation.

In order for Debusine to discover the task, add"Reprotest"in the filedebusine/tasks/__init__.py in the__all__ list.

Let’s explain the different methods of theReprotest class:

build_dynamic_data method

The worker has no access to Debusine’s database. Lookups are all resolved beforethe task gets dispatched to a worker, so all it has to do is download thespecified input artifacts.

build_dynamic_data method lookup the artifact, assert that is a validcategory, extract the package name and version, and get the environment inwhich it will be executed.

Theenvironment is needed to run the task (reprotest will runin a container usingunshare,incus…).

defbuild_dynamic_data(self,task_database:TaskDatabaseInterface    ) ->ReprotestDynamicData:"""Compute and return ReprotestDynamicData."""input_source_artifact =task_database.lookup_single_artifact(self.data.source_artifact        )assertinput_source_artifactisnotNoneself.ensure_artifact_categories(configuration_key="input.source_artifact",category=input_source_artifact.category,expected=(ArtifactCategory.SOURCE_PACKAGE,ArtifactCategory.UPLOAD,            ),        )assertisinstance(input_source_artifact.data, (DebianSourcePackage,DebianUpload)        )subject =get_source_package_name(input_source_artifact.data)version =get_source_package_version(input_source_artifact.data)assertself.data.environmentisnotNoneenvironment =self.get_environment(task_database,self.data.environment,default_category=CollectionCategory.ENVIRONMENTS,        )returnReprotestDynamicData(source_artifact_id=input_source_artifact.id,subject=subject,parameter_summary=f"{subject}_{version}",environment_id=environment.id,        )

get_input_artifacts_ids method

Used to list the task’s input artifacts in the web UI.

defget_input_artifacts_ids(self) ->list[int]:"""Return the list of input artifact IDs used by this task."""ifnotself.dynamic_data:return []assertself.dynamic_data.source_artifact_idisnotNonereturn [self.dynamic_data.source_artifact_id]

fetch_input method

Download the required artifacts on the worker.

deffetch_input(self,destination:Path) ->bool:"""Download the required artifacts."""assertself.dynamic_dataartifact_id =self.dynamic_data.source_artifact_idassertartifact_idisnotNoneself.fetch_artifact(artifact_id,destination)returnTrue

configure_for_execution method

Install the packages needed by the task and set_reprotest_target, whichis used to build the task’s command line.

defconfigure_for_execution(self,download_directory:Path) ->bool:"""       Find a .dsc in download_directory.       Install reprotest and other utilities used in _cmdline.       Set self._reprotest_target to it.       :param download_directory: where to search the files       :return: True if valid files were found       """self._prepare_executor_instance()ifself.executor_instanceisNone:raiseAssertionError("self.executor_instance cannot be None")self.run_executor_command(           ["apt-get","update"],log_filename="install.log",run_as_root=True,check=True,       )self.run_executor_command(           ["apt-get","--yes","--no-install-recommends","install","reprotest","dpkg-dev","devscripts","equivs","sudo",           ],log_filename="install.log",run_as_root=True,       )self._reprotest_target =utils.find_file_suffixes(download_directory, [".dsc"]       )returnTrue

_cmdline method

Return the command line to run the task.

In this case, and to keep the example simple, we will runreprotestdirectly in the worker’s executor VM/container, without giving it anisolated virtual server.

So, this command installs the build dependencies required by the package(soreprotest can build it) and runs reprotest itself.

def_cmdline(self) ->list[str]:"""       Build the reprotest command line.       Use configuration of self.data and self._reprotest_target.       """target =self._reprotest_targetasserttargetisnotNonecmd = ["bash","-c",f"TMPDIR=/tmp ; cd /tmp ; dpkg-source -x{target} package/; ""cd package/ ; mk-build-deps ; apt-get install --yes ./*.deb ; ""rm *.deb ; ""reprotest --vary=-time,-user_group,-fileordering,-domain_host .",       ]returncmd

Some reprotest variations are disabled. This is to keep the example simplewith the set of packages to install and reprotest features.

_cmdline_as_root method

Since during the execution it’s needed to install packages, run it asroot (in the container):

@staticmethoddef_cmdline_as_root() ->bool:r"""apt-get install --yes ./\*.deb must be run as root."""returnTrue

task_result method

Task succeeded if a log is generated and the return code is 0.

deftask_result(self,returncode:int |None,execute_directory:Path,# noqa: U100    ) ->WorkRequestResults:"""        Evaluate task output and return success.        For a successful run of reprotest:        -must have the output file        -exit code is 0        :return: WorkRequestResults.SUCCESS or WorkRequestResults.FAILURE.        """reprotest_file =execute_directory /self.CAPTURE_OUTPUT_FILENAMEifreprotest_file.exists()andreturncode ==0:returnWorkRequestResults.SUCCESSreturnWorkRequestResults.FAILURE

upload_artifacts method

Create theReprotestArtifact with the log and the reproducible boolean,upload it, and then add a relation between theReprotestArtifactand the source package:

defupload_artifacts(self,exec_directory:Path, *,execution_result:WorkRequestResults    ) ->None:"""Upload the ReprotestArtifact with the files and relationships."""ifnotself.debusine:raiseAssertionError("self.debusine not set")assertself.dynamic_dataisnotNoneassertself.dynamic_data.parameter_summaryisnotNonereprotest_artifact =ReprotestArtifact.create(reprotest_output=exec_directory /self.CAPTURE_OUTPUT_FILENAME,reproducible=execution_result ==WorkRequestResults.SUCCESS,package=self.dynamic_data.parameter_summary,        )uploaded =self.debusine.upload_artifact(reprotest_artifact,workspace=self.workspace_name,work_request=self.work_request_id,        )assertself.dynamic_dataisnotNoneassertself.dynamic_data.source_artifact_idisnotNoneself.debusine.relation_create(uploaded.id,self.dynamic_data.source_artifact_id,RelationType.RELATES_TO,        )

Execution example

To run this task in a local Debusine (see steps to have it ready withan environment, permissions and users created) you can do:

$ python3 -m debusine.client artifact import-debian -w System http://deb.debian.org/debian/pool/main/h/hello/hello_2.10-5.dsc

(get the artifact ID from the output of that command)

The artifact can be seen inhttp://$DEBUSINE/debusine/System/artifact/$ARTIFACTID/.

Then create areprotest.yaml:

$ cat <<EOF > reprotest.yamlsource_artifact: $ARTIFACT_IDenvironment: "debian/match:codename=bookworm"EOF

Instead ofdebian/match:codename=bookworm it could use the artifact ID.

Finally, create the work request to run the task:

$ python3 -m debusine.client create-work-request -w System reprotest --data reprotest.yaml

Using Debusine web you can see the work request, which should go toRunningstatus, thenCompleted withSuccess orFailure (depending ifreprotest could reproduce it or not). Clicking on theOutput tab would havean artifact of typedebian:reprotest with one file: the log.In theMetadata tab of the artifact it has Data: the package name andreproducible (true or false).

What is left to do?

This was a simple example of creating a task. Other things that could be done:

• unit tests
• documentation
• configurablevariations
• runningreprotest directly on the worker host, using the executorenvironment as areprotest “virtual server”
• in this specific example, the command line might be doing too many thingsthat could maybe be done by other parts of the task, such asprepare_environment.
• integrate it in a workflow so it’s easier to use (e.g. part ofQaWorkflow)
• extract more from the log than just pass/fail
• display the output in a more useful way (implement an artifact specializedview)

About 80% of my Debian contributions this month weresponsored byFreexian, as well as one direct donation viaGitHubSponsors (thanks!). If youappreciate this sort of work and are at a company that uses Debian, have alook to see whether you can pay for any ofFreexian‘s services; as well as the directbenefits, that revenue stream helps to keep Debian development sustainablefor me andseveral other lovelypeople.

You can also support my work directly viaLiberapay orGitHubSponsors.

Python packaging

New upstream versions:

• django-macaddress (fixinguse ofpkg_resources)
• fsspec (fixing abuild failure with Python 3.14)
• ipyparallel
• pycodestyle
• pyflakes (fixing abuild failure with Python 3.14)
• pyroma
• pytest-golden (fixing aregression that broke markdown-callouts, which Ireported upstream)
• pytest-runner
• python-auditwheel
• python-b2sdk (fixing abuild failure with Python 3.14)
• python-certifi
• python-django-imagekit (fixing abuild failure with Python 3.14)
• python-flake8 (fixing abuild failure with a new pyflakes version)
• python-ibm-cloud-sdk-core (contributed supporting fix upstream)
• python-openapi-core (fixing abuild failure with Python 3.14)
• python-pdoc (fixing abuild failure with Python 3.14)
• python-pyfunceble
• python-pytest-run-parallel
• python-pytokens
• python-weblogo (fixinguse ofpkg_resources)
• python-wheezy.template
• smart-open
• sphinx-togglebutton
• sqlobject
• supervisor (fixinguse ofpkg_resources)
• vcr.py (fixing abuild failure with Python 3.14)
• zope.interface (including a fix for aPython 3.14 failure in python-klein, which Icontributed upstream)
• zope.testrunner (fixing abuild failure with Python 3.14)

Fixes for Python 3.14:

• pdfposter (contributed upstream)
• pexpect
• poetry
• pyhamcrest
• pylint-gitlab
• python-astor
• python-easydev (contributed upstream)
• python-forbiddenfruit
• python-ibm-cloud-sdk-core
• python-iniparse
• python-libusb1
• python-marshmallow-dataclass (contributed upstream)
• python-marshmallow (NMU)
• python-opentracing
• python-opt-einsum-fx
• python-spdx-tools
• python-stopit
• rich (NMU, also requiring anNMU of textual)
• scikit-build-core
• seqdiag
• uncertainties
• yarsync (contributed upstream, along with asupporting fix)

Fixes for pytest 9:

• pyee (contributed upstream)
• python-django-celery-beat (contributed upstream)
• python-overrides

Porting away from thedeprecatedpkg_resources:

• beaker
• coreapi
• cppy (no-change rebuild to remove a spurious dependency)
• depthcharge-tools (contributed upstream)
• errbot
• gajim-antispam (removed unused dependency)
• gajim-lengthnotifier (removed unused dependency)
• gajim-openpgp (removed unused dependency)
• gajim-pgp (removed unused dependency)
• gajim-triggers (removed unused dependency)
• grapefruit
• impacket (contributed upstream)
• jupyter-packaging (no-change rebuild to remove a spurious dependency)
• khal
• pipenv (no-change rebuild to remove a spurious dependency)
• pyroma
• pytest-runner
• pytest-tornado
• python-airr
• python-aptly
• python-docxcompose
• python-hatch-mypyc (no-change rebuild to remove a spurious dependency)
• python-pyfunceble
• python-stopit
• python-ttfautohint-py (removed unused dependency)
• setuptools-scm (no-change rebuild to remove a spurious dependency)
• slimit (removed unused dependency)
• sphinx-togglebutton
• topplot (contributed upstream)
• valinor

Other build/test failures:

• audioop-lts:FTBFS: ValueError: major component is required
• basemap: Tries to access Internet during build
• celery:FTBFS:FAILED t/unit/backends/test_mongodb.py::test_MongoBackend::test_store_result (contributed upstream)
• django-allauth:FTBFS: AttributeError: module ‘fido2.features’ has no attribute ‘webauthn_json_mapping’
• django-tastypie
• m2crypto:FTBFS on armhf: AssertionError: 64 != 32
• magicgui
• pytest-mypy-testing
• python-asttokens
• python-distutils-extra:FTBFS: dpkg-buildpackage: error: debian/rules binary subprocess failed with exit status 2
• python-django-extensions:FTBFS:FAILED tests/templatetags/test_highlighting.py::HighlightTagTests::test_should_highlight_python_syntax_with_name
• python-gmpy2:FTBFS: ModuleNotFoundError: No module named ‘gmpy2’
• python-jpype:FTBFS on i386, armhf: test/jpypetest/test_buffer.py:394: TypeError (contributed upstream)
• python-maturin: Upcoming target-lexicon update
• traitlets (contributed upstream)
• unattended-upgrades:FTBFS: F824global logged_msgs is unused: name is never assigned in scope (NMU)

I investigated several more build failures and suggested removing the packages in question:

• aiozmq
• mkdocstrings-python-legacy
• python-djantic

Other bugs:

• magicgui: Directly Depends and Build-Depends on dbus
• python3-netsnmpagent: Rebuild for libsnmp45

Other bits and pieces

Alejandro Colomar reported thatman(1) ignored theMANWIDTH environment variable in some circumstances. I investigated this andfixed it upstream.

I contributed anubuntu-dev-tools patch to stop recommendingsudo.

Iadded forky support to the images used in SalsaCI pipelines.

I began working on getting a release candidate of groff 1.24.0 into experimental, though haven’t finished that yet.

I worked on some lower-priority security updates for OpenSSH.

Code reviews

• netcfg: Support SSIDs with /, write correct wifi to /etc/network/interfaces (merged and uploaded)
• openssh: [INTL:zh] Chinese debconf templates translations (merged)
• pymongo (sponsored upload for Aryan Karamtoth)
• python-streamz (sponsored upload for Aryan Karamtoth)
• smart-open: Please make the build reproducible (fixed in a different way)
• uvloop:FTBFS on riscv64 with Python 3.14 as supported (uploaded)

Both R and Python make it reasonably easy to work with compiledextensions. But how to access objects in one environment from the otherand share state or (non-trivial) objects remains trickier.Recently (and while r-forge was ‘resting’ so we opened GitHubDiscussions) a question was askedconcerning Rand Python object pointer exchange.

This lead to a pretty decent discussion includingarrow interchange demos (prettyideal if dealing with data.frame-alike objects), but once the focus ison more ‘library-specific’ objects from a given (C or C++, say) libraryit is less clear what to do, or how involved it may get.

R has external pointers, and these make it feasible to instantiatethe same object in Python. To demonstrate, I created a pair of(minimal) packages wrapping a lovely (small) class from the excellentspdlog library byGabi Melman, and more specificallyin an adapted-for-R version (to avoid someR CMD checknags) in myRcppSpdlogpackage. It is essentially a nicer/fancier C++ version of thetic() andtic() timing scheme. When an objectis instantiated, it ‘starts the clock’ and when we accessing it later itprints the time elapsed in microsecond resolution. In Modern C++ thistakes little more than keeping an internalchronoobject.

Which makes for a nice, small, yet specific object to pass to Python.So theR side ofthe package pair instantiates such an object, and accesses itsaddress. For different reasons, sending a ‘raw’ pointer across does notwork so well, but a string with the address printed works fabulously(and is a paradigm used around other packages so we did not inventthis). Over on thePython side of thepackage pair, we then take this string representation and pass it toa little bit ofpybind11 code toinstantiate a new object. This can of course also expose functionalitysuch as the ‘show time elapsed’ feature, either formatted or justnumerically, of interest here.

And that is all that there is! Now this can be done from R as wellthanks toreticulateas thedemo() (also shown on the package README.md)shows:

>library(chronometre)>demo("chronometre",ask=FALSE)demo(chronometre)----~~~~~~~~~~~>#!/usr/bin/env r>>stopifnot("Demo requires 'reticulate'"=requireNamespace("reticulate",quietly=TRUE))>stopifnot("Demo requires 'RcppSpdlog'"=requireNamespace("RcppSpdlog",quietly=TRUE))>stopifnot("Demo requires 'xptr'"=requireNamespace("xptr",quietly=TRUE))>library(reticulate)>## reticulate and Python in general these days really want a venv so we will use one,>## the default value is a location used locally; if needed create one>## check for existing virtualenv to use, or else set one up> venvdir<-Sys.getenv("CHRONOMETRE_VENV","/opt/venv/chronometre")>if (dir.exists(venvdir)) {+>use_virtualenv(venvdir,required =TRUE)+> }else {+>## create a virtual environment, but make it temporary+>Sys.setenv(RETICULATE_VIRTUALENV_ROOT=tempdir())+>virtualenv_create("r-reticulate-env")+>virtualenv_install("r-reticulate-env",packages =c("chronometre"))+>use_virtualenv("r-reticulate-env",required =TRUE)+> }> sw<- RcppSpdlog::get_stopwatch()# we use a C++ struct as example>Sys.sleep(0.5)# imagine doing some code here>print(sw)# stopwatch shows elapsed time0.501220> xptr::is_xptr(sw)# this is an external pointer in R[1]TRUE> xptr::xptr_address(sw)# get address, format is "0x...."[1]"0x58adb5918510"> sw2<- xptr::new_xptr(xptr::xptr_address(sw))# cloned (!!) but unclassed>attr(sw2,"class")<-c("stopwatch","externalptr")# class it .. and then use it!>print(sw2)# `xptr` allows us close and use0.501597> sw3<- ch$Stopwatch(  xptr::xptr_address(sw) )# new Python object via string ctor>print(sw3$elapsed())# shows output via Python I/Odatetime.timedelta(microseconds=502013)>cat(sw3$count(),"\n")# shows double0.502657>print(sw)# object still works in R0.502721>

The same object, instantiated in R is used in Python and thereafteragain in R. Whilethis object here is minimal in features, theconcept ofpassing a pointer is universal. We could use it forany interesting object that R can access and Python too can instantiate.Obviously, there be dragons as we pass pointers so one may want toascertain that headers from corresponding compatible versions are usedetc butprinciple is unaffected and should just work.

Both parts of this pair of packages are now at the correspondingrepositories:PyPIandCRAN.As I commonly do here on package (change) announcements, I include the(minimal so far) set of high-level changes for the R package.

Changes in version 0.0.2(2026-02-05)

• Removed replaced unconditional virtualenv use in demo givenpreceding conditional block

• Updated README.md with badges and an updated demo

Changes in version 0.0.1(2026-01-25)

• Initial version and CRAN upload

Questions, suggestions, bug reports, … are welcome at either the (nowawoken from the R-Forge slumber)Rcppmailing list or the newerRcppDiscussions.

This post byDirkEddelbuettel originated on hisThinking inside the boxblog. If you like this or other open-source work I do, you cansponsor me atGitHub.

I have unearthed a fewold articles typed during my adolescence, between1996 and 1998. Unremarkable at the time, these pages now compose, three decadeslater, the chronicle of a vanished era.¹

The word “blog” does not exist yet. Wikipedia remains to come. Google has notbeen born. AltaVista reigns over searches, whilealready struggling toembrace the nascent immensity of the web². To meet someone,you had to agree in advance and prepare your route on paper maps. 🗺️

The web is taking off. The CSS specification has just emerged, HTML tables stillserve for page layout.Cookies andadvertising banners are makingtheir appearance. Pages are adorned withmusic and videos, forcingbrowsers to arm themselves withplugins. Netscape Navigator sits on 86% ofthe territory, but Windows 95 now bundles Internet Explorer toquickly catchup. Facing this offensive, Netscapeopensource itsbrowser.

Francefalls behind. Outside universities, Internet access remainsexpensive and laborious.Minitel still reigns, offering phonedirectory, train tickets, remote shopping. This was not yet possible with theInternet:buying a CD online was a pipe dream. Encryption suffers frominappropriate regulation: the DES algorithm is capped at 40 bits andcracked in a few seconds.

These pages bear the trace of the web’s adolescence. Thirty years have passed.The same battles continue: data selling, advertising, monopolies.

Debian LTS/ELTS

This was my hundred-thirty-ninth month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian(as the LTS- and ELTS-teams have been merged now, there is only one paragraph left for both activities).

During my allocated time I uploaded or worked on:

• [DLA 4449-1] zvbi security update to fix five CVEs related to uninitialized pointers and integer overflows.
• [DLA 4450-1] taglib security update to fix one CVE related to a segmentation violation.
• [DLA 4451-1] shapelib security update to fix one CVE related to a double free.
• [DLA 4454-1] libuev security update to fix one CVE related to a buffer overrun.
• [ELA-1620-1] zvbi security update to fix five CVEs in Buster and Stretch related to uninitialized pointers and integer overflows.
• [ELA-1621-1] taglib security update to fix one CVE in Buster and Stretch related to a segmentation violation.
• [#1126167] bookworm-pu bug for zvbi to fix five CVEs in Bookworm.
• [#1126273] bookworm-pu bug for taglib to fix one CVE in Bookworm.
• [#1126370] bookworm-pu bug for libuev to fix one CVE in Bookworm.

I also attended the monthly LTS/ELTS meeting. While working on updates, I stumbled upon packages, whose CVEs have been postponed for a long time and their CVSS score was rather high. I wonder whether one should pay more attention to postponed issues, otherwise one could have already marked them asignored.

Debian Printing

Unfortunately I didn’t found any time to work on this topic.

Debian Lomiri

This month I worked on unifying packaging on Debian and Ubuntu. This makes it easier to work on those packages independent of the used platform.

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

Debian Astro

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

• …supernovas to unstable (sponsored upload).
• …libahp-xc to unstable.
• …c-munipack to unstable.

Debian IoT

Unfortunately I didn’t found any time to work on this topic.

Debian Mobcom

Unfortunately I didn’t found any time to work on this topic.

misc

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

• …liburjtag to unstable.

Unfortunately this month I was distracted from my normal Debian work by other unpleasant things, so that the paragraphs above are mostly empty. I now have to think about how many of my spare time I am able to dedicate to Debian in the future.

Another year of data fromSociété de Transport de Montréal, Montreal'stransit agency!

A few highlights this year:

1. Although theSaint-Michel station closed foremergency repairs in November 2024, traffic never bounced back to its pre-closure levels and is still stuck somewhere around 2022 Q2 levels. I wonder if this could be caused by the roadwork on Jean-Talon for thenew Blue Line stations making it harder for folks in Montreal-Nord to reach the station by bus.

2. The effects of the opening of theRoyalmount shopping center has had a durable impact on the traffic at theDe la Savane station. I reported on this last year, but it seems this wasn't just a fad.

3. With the completion of the Deux-Montagnes branch of the Réseau express métropolitain (REM, a light-rail, above the surface transit network still in construction), the transfer stations to the Montreal subway have seen major traffic increases. TheÉdouard-Montpetit station has nearly reached its previous all-time record of 2015 and theMcGill station has recovered from the general slump all the other stations have had in 2025.

4. TheAssomption station, which used to have one of the lowest number of riders of the subway network, has had a tremendous growth in the past few years. This is mostly explained by the many high-rise projects that were built around the station since the end of the COVID-19 pandemic.

5. Although still affected by a very high seasonality, theJean-Drapeau station broke its previous record of 2019, a testament of the continued attraction power of the various summer festivals taking place on the Sainte-Hélène et Notre-Dame islands.

More generally, it seems the Montreal subway has had a pretty bad year. Traffichad been slowly climbing back since the COVID-19 pandemic, but this is thefirst year since 2020 such a sharp decline can be witnessed. Even majorstations likeJean-Talon orLionel-Groulx are ona downward trend and it is pretty worrisome.

As for causes, a few things come to mind. First of all, as the number ofMontrealers commuting to work by bike continues to rise¹, a modalshift from public transit to active mobility is to be expected.As localexperts put it, this is not uncommon and has been seen in othercities before.

Another important factor that certainly turned people away from the subway thisyear has been the impacts of the continued housing crisis in Montreal. As moreand more people get kicked out of their apartments, many have been seekingrefuge in the subway stations to find shelter.

Sadly, this also brought a unprecedented wave of incivilities. As riders' senseof security sharply decreased, the STM eventually resorted tobanning unhousedpeople from sheltering in the subway. This decision did bring backsome peace to the network, but one can posit damage had already been done andmany casual riders are still avoiding the subway for this reason.

Finally, the weekslong STM worker's strike in Q4 had an important impact ongeneral traffic, as it severely reduced the opening hours of the subway. As forthe previous item, once people find alternative ways to get around, it's alwaysharder to bring them back.

Hopefully, my 2026 report will be a more cheerful one...

By clicking on a subway station, you'll be redirected to a graph of thestation's foot traffic.

• Orange line (top10)
• Green line (top10)
• Blue line
• Yellow line
• Global Top 10

Licences

• The subway map displayed on this page, theoriginal dataset and mymodified dataset are licenced underCCO 1.0: they are in the public domain.

• TheR code I wrote is licensed under the GPLv3+. It has not changed in a few years.

Welcome to the first monthly report in 2026 from theReproducible Builds project!

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

1. Flathub now testing for reproducibility
2. Reproducibility identifying projects that will fail to build in 2038
3. Distribution work
4. Tool development
5. Two new academic papers
6. Upstream patches

Flathub now testing for reproducibility

Flathub, the primary repository/app store forFlatpak-based applications, has begun checking for build reproducibility.According to a recent blog post:

We have started testing binary reproducibility ofx86_64 builds targeting the stable repository. This is possible thanks toflathub-repro-checker, a tool doing the necessary legwork to recreate the build environment and compare the result of the rebuild with what is published on Flathub. While these tests have been running for a while now, we have recently restarted them from scratch after enabling S3 storage for diffoscope artifacts.

The test results and status is available on theirreproducible builds page.

Reproducibility identifying software projects that will fail to build in 2038

Longtime Reproducible Builds developer Bernhard M. Wiedemannposted on Reddit on “Y2K38 commemoration day T-12” — that is to say, twelve years to the day before the UNIX Epoch will no longer fit into a signed 32-bit integer variable on 19th January 2038.

Bernhard’s comment succinctly outlines the problem as well as notes some of the potential remedies, as well aslinks to a discussion with the GCC developers regarding “adding warnings forint →time_t conversions”.

At the time of publication, Bernard’s topic had generated50 comments in response.

Distribution work

Conda is language-agnostic package manager which was originally developed to help Python data scientists and is now a popular package manager for Python and R.

conda-forge, a community-led infrastructure for Conda recently revamped theirdashboards to rebuild packages straight to track reproducibility. There have been changes over the past two years to make theconda-forge build tooling fully reproducible by embedding the ‘lockfile’ of the entire build environment inside the packages.

InDebian this month:

• Scott Talbertuploaded a new version ofdh-haskell (0.6.13), reverting parallel support as it broke reproducibility, thereby fixing Debian bug#1125000.

• Vagrant Cascadian posted toour mailing list on the topic of“Duplicate Debian packages with matching name-version-arch problem”. The issue is that.buildinfo files only “record the package name, version and architecture of the build-dependencies (and perhaps a bit more), but there arecorner cases where multiple artifacts have the same name, version and architecture”. This generatedsome discussion on the mailing list as well as elsewhere in Debian.

• Roland Clobus also posted to our mailing list regardingBuilding Debian Live images from snapshot.debian.org. This surfaced an issue regarding the timestamps of the.deb file, leading to Roland filing Debian bug#1126000 to liaise with the developers of thesnapshot.debian.org service.

• A change was made to migrate away from using the results fromtests.reproducible-builds.org in deciding whether a package is a suitable candidate for the Debiantesting distribution (the staging area for the next stable Debian release) to use the results fromreproduce.debian.net instead. This was,according to Paul Gevers’ merge request, because the former service “does so by building twice in a row with varying build environment. What we are actually interested in is if the binaries that we ship can be reproduced”. The information provided byreproduce.debian.net in future will be used to delay or speed up packages’ migration time based on their reproducibility status, and further in the future shall be used to block unreproducible packages from migrating entirely.

• 41 reviews of Debian packages were added, 7 were updated and 37 were removed this month adding toour knowledge about identified issues. Chris Lamb identified and added a newsource_date_epoch_affected_by_timezone_by_d_compiler_gdc issue type, as well astimezone_variant_in_argparse_manpage.

InNixOS this month, it wasannounced that theGNU Guix Full Source Bootstrap wasported to NixOS as part ofWire Jansen bachelor’s thesis (PDF). At the time of publication, thischange has landed in NiX’stdev distribution.

Lastly, Bernhard M. Wiedemann posted anotheropenSUSEmonthly update for his work there.

Tool development

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

• Fix test compatibility withu-boot-tools version2026-01. […]
• Drop the impliedRules-Requires-Root: no entry indebian/control. […]
• BumpStandards-Version to 4.7.3. […]
• Reference the Debianocaml package instead ofocaml-nox. (#1125094)
• Apply a patch by Jelle van der Waa to adjust a test fixture match new lines. […]
• Also the drop impliedPriority: optional fromdebian/control. […]

In addition, Holger Levsen uploaded two versions ofdisorderfs, first updating the package from FUSE 2 toFUSE 3 as described inlast months report, as well as updating the packaging to the latest Debian standards. Asecond upload (0.6.2-1) was subsequently made, with Holger adding instructions on how to add the upstream release to our release archive and incorporating changes by Roland Clobus to set_FILE_OFFSET_BITS on 32-bit platforms, fixing a build failure on 32-bit systems. Vagrant Cascadian updateddiffoscope in GNU Guix to version311-2-ge4ec97f7 anddisorderfs to0.6.2.

Two new academic papers

Julien Malka, Stefano Zacchiroli and Théo Zimmermann of Télécom Paris’ in-house research laboratory, theInformation Processing and Communications Laboratory (LTCI) published a paper this month titledDocker Does Not Guarantee Reproducibility:

[…] WhileDocker is frequently cited in the literature as a tool that enables reproducibility in theory, the extent of its guarantees and limitations in practice remains under-explored. In this work, we address this gap through two complementary approaches. First, we conduct a systematic literature review to examine how Docker is framed in scientific discourse on reproducibility and to identify documented best practices for writingDockerfiles enabling reproducible image building. Then, we perform a large-scale empirical study of 5,298 Docker builds collected from GitHub workflows. By rebuilding these images and comparing the results with their historical counterparts, we assess the real reproducibility of Docker images and evaluate the effectiveness of the best practices identified in the literature.

APDF of their paper is available online.

Quentin Guilloteau, Antoine Waehren and Florina M. Ciorba of theUniversity of Basel in Swedenalso published aDocker-related paper, theirs calledLongitudinal Study of the Software Environments Produced by Dockerfiles from Research Artifacts:

The reproducibility crisis has affected all scientific disciplines, including computer science (CS). To address this issue, the CS community has established artifact evaluation processes at conferences and in journals to evaluate the reproducibility of the results shared in publications. Authors are therefore required to share their artifacts with reviewers, including code, data, and the software environment necessary to reproduce the results. One method for sharing the software environment proposed by conferences and journals is to utilize container technologies such as Docker and Apptainer. However, these tools rely on non-reproducible tools, resulting in non-reproducible containers. In this paper, we present a tool and methodology to evaluate variations over time in software environments of container images derived from research artifacts. We also present initial results on a small set ofDockerfiles from the Euro-Par 2024 conference.

APDF of their paper is available online.

Miscellaneous news

Onour mailing list this month:

• kpcyrd started a thread after they noticed that “SWHID (also known as ISO/IEC 18670:2025) was published 1.0 in 2022 and ISO standardized in 2025, but uses the insecureSHA-1 as core cryptographic primitive”, asking whether there have been any attempts to upgrade this to SHA-256 or similar.

• Jan-Benedict Glaw asked about theReproducibility for Libreoffice [when performing] ODT to PDF conversion after they observed that “simply callinglibreoffice --convert-to pdf some.odt results in unreproducible output PDF. Aftersome replies, Jan-Benedict wrote back to observe that it may be an issue with both timestamps and embedded fonts.

Lastly,kpcyrd added aRust section to theStable order for outputs page on our website. […]

Upstream patches

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

• Bernhard M. Wiedemann:

  • clamav
  • kf6-kuserfeedback
  • libaom
  • Nim
  • otp
  • Switcheroo (by Khaleel Al-Adhami)
  • uwsm
  • ZEO

• Chris Lamb:

  • #1124697 filed againstsqlalchemy-i18n.
  • #1125671 filed againsttea-cli.
  • #1125725 filed againstlibimage-librsvg-perl.
  • #1125727 filed againstseer.
  • #1125729 filed againstgrabix.
  • #1126038 filed againsthovercraft.
  • #1126039 filed againstlomiri-location-service.
  • #1126092 filed againstargparse-manpage.
  • #1126454 filed againstxarray-safe-rcm.
  • #1126512 filed againstgcc-15 (forwarded upstream).

• Jochen Sprickerhof:

  • #1124951 filed againstrsyslog.
  • #1125000 filed againstdh-haskell.

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

• IRC:#reproducible-builds onirc.oftc.net.

• Mastodon:@reproducible_builds@fosstodon.org

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

January was a slow month, I only did three uploads to Debian unstable:

• xdg-desktop-portal-wlr updated to 0.8.1-1
• swayimg updated to 4.7-1
• usbguard updated to 1.1.4+ds-2, which closed#1122733

I was very happy to see the newdfsg-new-queue and that there are more handsnow processing the NEW queue. I also finally got one of the packages acceptedthat I uploaded after the Trixie release:wayback which I uploaded last August.There has been another release since then, I’ll try to upload that in the nextfew days.

There was abug report forcarlasking for Windows support.carl used thexdgcreate for looking up the XDG directories, butxdg does not supportwindows systems (and it seems thiswill notchange)The reporter also provided a PR to replace the dependency with thedirectories crate which more systemagnostic. I adapted the PR a bit and merged it andreleased version0.6.0 of carl.

At my dayjob I refactoreddjango-grouper.django-grouper is a package we use to find duplicate objects in our data. Ourusers often work with datasets of thousands of historical persons, places andinstitutions and in projects that run over years and ingest data from multiple sources,it happens that entries are created several times.I wrote the initial app in 2024, but was never really happy about the approachI used back then. It was based onthis blogpostthat describes how to group spreadsheet text cells. It usessklearnsTfidfVectorizerwith a custom analyzer and the librarysparse_dot_topn for creating thematrix. All in all the module to calculate the clusters was 80 lines and withsparse_dot_topn it pulled in a rather niche Python library. I was pretty surethat this functionality could also be implemented with basic sklearnfunctionality and it was: we are now usingDictVectorizerbecause in a Django app we are working with objects that can be mapped to dictsanyway. And for clustering the data, the app now uses theDBSCANalgorithm (with the manhattan distance as metric). The module is now only halfthe size and the whole app lost one dependency! I released those changes asversion0.3.0 of theapp.

At the end of January together with friends I went to Brussels to attendFOSDEM. We took the night train but there were a couple ofbroken down trains so the ride took 26 hours instead of one night. It is a goodthing we had a one day buffer and FOSDEM only started on Saturday. As usualthere were too many talks to visit, so I’ll have to watch some of therecordings in the next few weeks.

Some examples of talks I found interesting so far:

• a talk about supportingPython web deployments withRustin the Rust Developer room
• atalk aboutduckdbin the Python Developer room
• an introduction toparticleosin the Distributions Developer room

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

[ Jelle van der Waa ]* Adjust u-boot-tools/fit diff to match new lines.

You find out more byvisiting the project homepage.

The originalFOAAS site provideda rather wide variety of REST access points, but it sadky is no more(while theold repois still there). A newer replacement siteFOASS is up and running, but witha somewhat reduced offering. (For example, the two accessors shown inthe screenshot are no more.C’est la vie.)

Recognising that perfect may once again be the enemy of (somewhat)good (enough), we have rejigged therfoaas packagein a new release 2.3.3. (The precding version number 2.3.2 correspondedto the upstream version, indicating which API release we matched. Now wejust went ‘+ 0.0.1’ but there is no longer a correspondence to theservice version atFOASS.)

Accessor functions for each of the now available access points areprovided, ans the random sampling accessorgetRandomFO()now picks from that set.

MyCRANberriesservice provides a comparison totheprevious release. Questions, comments etc should go to theGitHub issuetracker. More background information is on theproject pageas well as on thegithub repo

This post byDirkEddelbuettel originated on hisThinking inside the boxblog. If you like this or other open-source work I do, you cansponsor me atGitHub.

The twentythird release oflittler as aCRAN packagelanded on CRAN just now, following in the now twenty year history (!!)as a (initially non-CRAN) package started byJeff in 2006, and joinedby me a few weeks later.

littleris the first command-line interface for R as it predatesRscript. It allows for piping as well forshebangscripting via#!, uses command-line arguments moreconsistently and stillstartsfaster. It also always loaded themethods package whichRscript only began to do in later years.

littlerlives on Linux and Unix, has its difficulties on macOS due tosome-braindeadedness there (who ever thought case-insensitivefilesystems as a default were a good idea?) and simply does not exist onWindows (yet – the build system could be extended – seeRInside foran existence proof, and volunteers are welcome!). See theFAQvignette on how to add it to yourPATH. A few examplesare highlighted at theGithub repo:, as wellas in theexamplesvignette.

This release, the first in about eleven months, once again brings twonew helper scripts, and enhances six existing one. The release wastriggered because it finally became clear whyinstallGitHub.r ignored r2u when available: we forced thetype argument to ‘source’ (so thanks to Iñaki for spotting this). Onechange was once again contributed byMichael which is againgreatly appreciated.

The full change description follows.

Changes in littlerversion 0.3.22 (2026-02-03)

• Changes in examples scripts

  • A new scriptbusybees.r aggregates deadlinedpackages by maintainer

  • Several small updated have been made to the (mostly internal)'r2u.r' script

  • Thedeadliners.r script has refined treatment forscreen width

  • Theinstall2.r script has new options--quiet and--verbose as proposed by ZivanKaraman

  • Thercc.r script passes build-args to 'rcmdcheck' tocompact vignettes and save data

  • TheinstallRub.r script now defaults to 'noble' andis more tolerant of inputs

  • TheinstallRub.r script deals correctly with emptyutils::osVersion thanks to Michael Chirico

  • New scriptcheckPackageUrls.r inspired by how CRANchecks (with thanks to Kurt Hornik for the hint)

  • TheinstallGithub.r script now adjusts tobspm and takes advantage of r2u binaries for its builddependencies

• Changes in package

  • Environment variables (read at build time) can use doublequotes

  • Continuous intgegration scripts received a minor update

MyCRANberriesservice provides a comparison totheprevious release. Full details for thelittlerrelease are provided as usual at theChangeLogpage, and also on thepackage docs website.The code is available via theGitHub repo, fromtarballs and now of course also fromits CRAN page andviainstall.packages("littler"). Binary packages areavailable directly inDebian aswell as (in a day or two)Ubuntu binaries atCRAN thanks to the tireless Michael Rutter. Comments and suggestionsare welcome at theGitHub repo.

This post byDirkEddelbuettel originated on hisThinking inside the boxblog. If you like this or other open-source work I do, you cansponsor me atGitHub.

• Debian packages:
  • dracut:
    • Bugs:
      • replied to and reassigned#1124400: update-initramfs no longer includes /lib/modules/<kver>/updates directory
  • flash-kernel:
    • Bugs:
      • closed#1102690: A higher version (…) is still installed, no reflashing required
      • closed#1125327: since linux 6.18, flash-kernel fails to find dtbs in /usr/lib/linux-image-*
    • Uploads:
      • uploaded version 3.110 to unstable
      • uploaded version 3.110~bpo13+1 to trixie-backports
  • kernel-sec:
    • Merge requests:
      • opened!30: scripts/import-korg-vulns: Ignore issues in unsupported architectures
  • libvirt:
    • Bugs:
      • (LTS) opened and replied to#1124549: libvirt passes invalid flags for network interface deletion
  • linux:
    • Bugs:
      • replied to#1123750: linux: regression: virtual consoles 2-12 unusable
      • closed#1125287: linux-image-6.12.63+deb13-amd64: Misleading error message “x2apic: IRQ remapping doesn’t support X2APIC mode”
      • replied to#1126015: linux-image-6.17.13+deb14-rt-amd64: ethtool -x <sfc-net-driver-ifname> causes: rtmutex deadlock detected
    • Merge requests:
      • reviewed!1784: Add breaks on reform-tools and flash-kernel versions before support for…
    • (LTS) updated the bullseye-security branch to 5.10.248, but did not upload it
  • (LTS)linux-6.1:
    • uploaded version 6.1.159-1~deb11u1 to bullseye-security
  • linux-base:
    • Bugs:
      • replied to#1111052: Please increase default UDP receive buffer size (rmem_max)
      • replied to#1111657: Please increase default UDP send buffer size (wmem_max)
      • closed#1121366: linux-run-hooks uses wrong directory name for headers postinst
      • closed#1124409: linux-base: [INTL:zh] Chinese debconf templates translations
    • Uploads:
      • uploaded version 4.12.1 to trixie
      • uploaded version 4.15 to unstable
  • ministat:
    • Bugs:
      • closed#1123854: ministat: Packaging vcs doesn’t work, upstream vcs unspecified
      • closed#1123856: ministat: ministat crashes given all-inf input
    • Uploads:
      • uploaded version 20251113-1 to unstable
      • uploaded version 20251113-2 to unstable
  • wireless-regdb:
    • Merge requests:
      • merged!7: Drop unnecessary B-D m2crypto (Closes: #1126431)
• Debian non-package bugs:
  • release.debian.org:
    • opened#1126020: trixie-pu: package linux-base/4.12.1
• Mailing lists:
  • debian-kernel:
    • postedAgenda items for kernel-team meeting on 2026-01-07
    • replied toQuestions on debdiff for linux-signed-{amd64,arm64} in trixie-backports
    • (LTS) replied to[regression 5.10.y] Libvirt can no longer delete macvtap devices …
    • postedcpp-httplib FTBFS in unstable
    • (LTS) replied tokernel 5.10.0-28-amd64: linux-headers needed
  • debian-lts:
    • posted and replied toRegression update for libvirt in bullseye?
  • debian-lts-announce:
    • posted[SECURITY] [DLA 4436-1] linux-6.1 security update
  • stable:
    • (LTS) posted[5.10] net/sched: act_ife: convert comma to semicolon
    • (LTS) posted[5.10] regression: virtual consoles 2-12 unusable
    • (LTS) reviewed and replied tovariouspatchesfor5.10………………………………………………

FOSDEM 2026 was great! I hope to blog a proper postmortem in due course. Butfor now,The video of my talk is up, as are my slides with speaker notes and links.

Hi there, I’m more than halfway through (8 weeks) my Outreachy internship with Debian, working on the openQA project to test Live Images.

My journey into tech began as a software engineering trainee, during which I built a foundation in Bash scripting, C programming, and Python. Later, I worked for a startup as a Product Manager. As is common in startups, I wore many hats, but I found myself drawn most to the Quality Assurance team. Testing user flows and edge-case scenarios sparked my curiosity, and that curiosity is exactly what led me to the Debian Live Image testing project.

From Manual to Automated

In my previous roles, I was accustomed to manual testing, simulating user actions one by one. While effective, I quickly realized it could be a bottleneck in fast-paced environments. This internship has been a masterclass in removing that bottleneck. I’ve learned that automating repetitive actions makes life (and engineering) much easier. Life’s too short for manual testing.

One of my proudest technical wins so far has been creating “Synergy” across desktop environments. I proposed a solution to group common applications so we could use a single Perl script to handle tests for multiple desktop environments. With my mentor’s guidance, we implemented this using symbolic links, which significantly reduced code redundancy.

Expanding My Technical Toolkit

Over the last 8 weeks, my technical toolkit has expanded significantly:

• Perl & openQA: I’ve learnt writing with Perl for automation within the openQA framework and I’ve successfully automated apps_startstop tests for Cinnamon and LXQt
• Technical Documentation: I authored a contributor guide. This required paying close attention to detail, ensuring that new contributors can have faster reviews and merged contributions
• Ansible: I am learning that testing doesn’t happen in a vacuum. To ensure new tests are truly automated, they must be integrated into the system’s configuration.

Working on this project has shaped my perspective on where I fit in the tech ecosystem. In Open Source, my “resume” isn’t just a PDF, it’s a public trail of merged code, technical proposals, and collaborative discussions.

As my mentor recently pointed out, this is my “proof-of-work.” It’s a transparent record of what I am capable of and where my interests lie. 

Finally, I’ve grown as a team player. Working with a global team across different time zones has taught me the importance of asynchronous communication and respecting everyone’s time. Whether I am proposing a new logic or documenting a process, I am learning that open communication is just as vital as clean code.

If you’d like to have a simple solution for managing all the secrets you’reusing in your Ansible Playbooks, keep reading on. Bitwarden’s Secrets Managerprovides an Ansible collection, which makes it very easyto use this particular Secrets Manager in Ansible Playbooks. I’ll show you howto set up a free Secrets Manager account in Bitwarden. Then I’ll walk youthrough the setup in an example Ansible Playbook.

YouTube Video version

I’ve also recorded a video version of this article. If you prefer a video, youcan find ithere.

Hello world! I am an intern at Outreachy working with the Debian OpenQA team on images testing. We get to know what career opportunities awaits us when we work on open source projects. In open source, we are constantly learning. The community has different sets of skills and a large network of people.

So, how did I start off in this internship

I entered the community with the these skills:

• MERN (Mongo DB, Express JS , React JS and Node JS) – for web development
• Linux and Shell Scripting – for some administrative purposes
• Containerization using Google Cloud
• Operating Systems
• A learning passion for Open Source – I contributed to some open source work in the past but it was in terms of documentation and bug hunting

I was a newbie at OpenQA but, I had a month to learn and contribute. Time is a critical resource but so is understanding what you are doing. I followed the installations instructions given but whenever I got errors, I had to research why I got the errors. I took time to understand errors I was solving then continued on with the tasks I wanted to do. I communicated my logic and understanding while working on the task and awaited reviews and feedback. Within a span of two months I had learned a lot by practicing and testing.

The skills I gained

As of today, I gained these technical skills from my work with Debian OpenQA team.

• Perl – the tests that we run are written in this language
• Ansible configuration – ansible configurations and settings for the machines the team runs
• Git – this is needed for code versioning and diving tasks into different branches
• Linux – shell scripting and working with the Debian Operating system
• Virtual Machines and Operating Systems – I constantly view how different operating systems are booted and run on virtual machines during testing
• Testing – I keep watch of needles and ensure the tests work as required
• Debian – I use a Debian system to run my Virtual Machines
• OpenQA – the tool that is used to automate testing of Images

With open source comes the need of constant communication. The community is diverse and the team is usually on different time zones. These are some of the soft / social skills I gained when working with the team

• Communication – this is essential especially in taking tasks with confidence, talking about issues encountered and stating the progress of the tasks
• Interpersonal skills – this is for general communication within the community
• Flexibility – we have to adapt to changes because we are a community of different people with different skills

With these skills and the willingness to learn , open source is a great area to focus on . Aside from your career you will extend your network. My interests are set on open source and Linux in general. Working with a wider network has really skilled me up and I will continue learning. Working with the Debian OpenQA team has been very great. The team is great at communication and I learn every day. The knowledge I gain from the team is helping me build a great career in open source.

After years of thinking about and learning about how radios work, I figured itwas high-time to start to more aggressively share the things i’ve beenlearning. I had a ton of fun atDistrictConyear 0, so it was a pretty natural place to pitch an RF-focused introductorytalk.

I was selected for Year 1, and able to give my first ever RF related talk abouthow to set off restaurant pagers (including one on stage!) by reading andwriting IQ directly using a little bit of stdlib only Python.

This talk is based around the work I’ve written about previously(here,here andhere), but the “all-in-one” form factor wassomething I was hoping would help encourage folks out there to take a lookunder the hood of some of the gear around them.

(In case the iframe above isn’t working, direct link to the YouTube videorecording ishere)

I’ve posted my slides from the talk atPARCH.pdf to hopefully give folks some timeto flip through them directly.

All in all, the session was great – It was truely humbling to see so manyfolks interested in hearing me talk about radios. I had a bit of an own-goal inpicking a 20 minute form-factor, so the talk is paced wrong (it feels like itwent way too fast). Hopefully being able to see the slides and pause the videois helpful.

We had a short ad-hoc session after where I brought two sets of pagers and mypower switch; but unfortunately we didn’t have anyone who was able to triggerany of the devices on their own (due to a mix of time between sessions andcomputer set-up). Hopefully it was enough to get folks interested in tryingthis on their own!

Note: I have not published blog posts about my academic papers over the past few years. To ensure that my blog contains a more comprehensive record of my published papers and to surface these for folks who missed them, I will be periodically (re)publishing blog posts about some “older” published projects. This post is closely based ona previously published post byKaylea Champion onthe Community Data Science Blog.

Many individuals use Tor to reduce their visibility to widespread internet surveillance.

One popular approach to protecting our privacy online is to use theTor network. Tor protects users from being identified by their IP address, which can be tied to a physical location. However, if you’d like to contribute to Wikipedia using Tor, you’ll run into a problem. Although most IP addresses can edit without an account, Tor users are blocked from editing.

Tor users attempting to contribute to Wikipedia are shown a screen that informs them that they are not allowed to edit Wikipedia.

Other research by my team has shown that Wikipedia’s attempt to block Tor is imperfect and that some people have been able to edit despite the ban. As part of this work, we built a dataset of more than 11,000 contributions to Wikipedia via Tor and used quantitative analysis to show that contributions from Tor were of about the same quality as contributions from other new editors and other contributors without accounts. Of course, given the unusual circumstances Tor-based contributors face, we wondered whether a deeper look at the content of their edits might reveal more about their motives and the kinds of contributions they seek to make. Kaylea Champion (then a student, now faculty at UW Bothell) led a qualitative investigation to explore these questions.

Given the challenges of studying anonymity seekers, we designed a novel “forensic” qualitative approach inspired by techniques common in computer security and criminal investigation. We applied this new technique to a sample of 500 editing sessions and categorized each session based on what the editor seemed to be intending to do.

Most of the contributions we found fell into one of the two following categories:

• Many contributions werequotidian attempts to add to the encyclopedia. Tor-based editors added facts, fixed typos, and updated train schedules. There’s no way to know whether these individuals knew they were just getting lucky in their ability to edit or were patiently reloading to evade the ban.
• Second, we foundharassing comments and vandalism. Unwelcome conduct is common in online environments, and it is sometimes more common when the likelihood of being identified decreases. Some of the harassing comments we observed were direct responses to being banned as a Tor user.

Although these were most of what we observed, we also found evidence of several types of contributor intent:

• We observedactivism: when a contributor tried to draw attention to journalistic accounts of environmental and human rights abuses committed by a mining company, only to have editors linked to the mining company repeatedly remove their edits. Another example involved an editor trying to diminish the influence of proponents of alternative medicine.
• We also observedquality maintenance activities when editors used Wikipedia’s rules on appropriate sourcing to remove personal websites being cited in conspiracy theories.
• We sawedit wars with Tor editors participating in a back-and-forth removal and replacement of content as part of a dispute, in some cases countering the work of an experienced Wikipedia editor whom even other experienced editors had gauged to be biased.
• Finally, we saw Tor-based editors participating innon-article discussions, such as investigations into administrator misconduct andprotests against the Wikipedia platform’s mistrust of Tor editors.

An exploratory mapping of our themes in terms of the value a type of contribution represents to the Wikipedia community and the importance of anonymity in facilitating it. Anonymity-protecting tools play a critical role in facilitating contributions on the right side of the figure, while edits on the left are more likely to occur even when anonymity is impossible. Contributions toward the top reflect valuable forms of participation in Wikipedia, while edits at the bottom reflect damage.

In all, these themes led us to reflect on how the risks individuals face when contributing to online communities sometimes diverge from the risks the communities face in accepting their work. Expressing minoritized perspectives, maintaining community standards even when you may be targeted by the rulebreaker, highlighting injustice, or acting as a whistleblower can be very risky for an individual, and may not be possible without privacy protections. Of course, in platforms seeking to support the public good, such knowledge and accountability may be crucial.

This work was published as a paper at CSCW:Kaylea Champion, Nora McDonald, Stephanie Bankes, Joseph Zhang, Rachel Greenstadt, Andrea Forte, and Benjamin Mako Hill. 2019. A Forensic Qualitative Analysis of Contributions to Wikipedia from Anonymity Seeking Users.Proceedings of the ACM on Human-Computer Interaction. 3, CSCW, Article 53 (November 2019), 26 pages.https://doi.org/10.1145/3359155

This project was conducted by Kaylea Champion, Nora McDonald, Stephanie Bankes, Joseph Zhang, Rachel Greenstadt, Andrea Forte, and Benjamin Mako Hill. This work was supported by the National Science Foundation (awards CNS-1703736 and CNS-1703049) and included the work of two undergraduates supported through an NSF REU supplement.

Review:Paladin's Faith, by T. Kingfisher

Paladin's Faith is the fourth book in T. Kingfisher's looselyconnected series of fantasy novels about the berserker former paladins ofthe Saint of Steel. You could read this as a standalone, but there arenumerous (spoilery) references to the previous books in the series.

Marguerite, who was central to the plot of the first book in the series,Paladin's Grace, is a spy with aproblem. An internal power struggle in the Red Sail, the organization thatshe's been working for, has left her a target. She has a plan for how tobreak their power sufficiently that they will hopefully leave her alone,but to pull it off she's going to need help. As the story opens, she isworking to acquire that help in a very Marguerite sort of way: breakinginto the office of Bishop Beartongue of the Temple of the White Rat.

The Red Sail, the powerful merchant organization Marguerite worked for,makes their money in the salt trade. Marguerite has learned that someoneinvented a cheap and reproducible way to extract salt from sea water, thusmaking the salt trade irrelevant. The Red Sail wants to ensure thatinvention never sees the light of day, and has forced the artificer intohiding. Marguerite doesn't know where they are, but she knows where shecan find out: the Court of Smoke, where the artificer has a patron.

Having grown up in Anuket City, Marguerite was familiar with many clockwork creations, not to mention all the ways that they could go horribly wrong. (Ninety-nine times out of a hundred, it was an explosion. The hundredth time, it ran amok and stabbed innocent bystanders, and the artificer would be left standing there saying, "But I had to put blades on it, or how would it rake the leaves?" while the gutters filled up with blood.)

All Marguerite needs to put her plan into motion is some bodyguards sothat she's not constantly distracted and anxious about being assassinated.Readers of this series will be unsurprised to learn that the bodyguardsshe asks Beartongue for are paladins, including a large broody male onewith serious self-esteem problems.

This is, like the other books in this series, a slow-burn romance withinfuriating communication problems and a male protagonist who would dowell to seek out a sack of hammers as a mentor. However, it has two thingsgoing for it that most books in this series do not: a long and complexplot to which the romance takes a back seat, and Marguerite, who is notparticularly interested in playing along with the expected romancedevelopments. There are also two main paladins in this story, not justone, and the other is one of the two female paladins of the Saint of Steeland rather more entertaining than Shane.

I generally like court intrigue stories, which is what fills most of thisbook. Marguerite is an experienced operative, so the reader gets somesolid competence porn, and the paladins are fish out of water but are alsounexpectedly dangerous, which adds both comedy and satisfyingtable-turning. I thoroughly enjoyed the maneuvering and the cultureclashes. Marguerite is very good at what she does, knows it, and isentirely uninterested in other people's opinions about that, whichshort-circuits a lot of Shane's most annoying behavior and keeps the storyfrom devolving into mopey angst like some of the books in this series havedone.

The end of this book takes the plot in a different direction that addssignificantly to the world-building, but also has a (thankfully short)depths of despair segment that I endured rather than enjoyed. I am notreally in the mood for bleak hopelessness in my fiction at the moment,even if the reader is fairly sure it will be temporary. But apart fromthat, I thoroughly enjoyed this book from beginning to end. When wefinally meet the artificer, they are an absolute delight in that way thatKingfisher is so good at. The whole story is infused with the sense ofdetermined and competent people refusing to stop trying to fix problems.As usual, the romance was not for me and I think the book would have beenbetter without it, but it's less central to the plot and therefore annoyedme less than any of the books in this series so far.

My one major complaint is the lack of gnoles, but we get some new andintriguing world-building to make up for it, along with a setup for afifth book that I am now extremely curious about.

By this point in the series, you probably know if you like the generalformula. Compared to the previous book,Paladin's Hope, I thoughtPaladin's Faith was muchstronger and more interesting, but it's clearly of the same type. If, likeme, you like the plots but not the romance, the plot here is moresubstantial. You will have to decide if that makes up for a romance in thetypical T. Kingfisher configuration.

Personally, I enjoyed this quite a bit, except for the short bleak part,and I'm back to eagerly awaiting the next book in the series.

Rating: 8 out of 10

You might have seenPolicy will reject signature within a year warnings in apt(-get) update runs like this:

root@424812bd4556:/# apt updateGet:1 http://foo.example.org/debian demo InRelease [4229 B]Hit:2 http://deb.debian.org/debian trixie InReleaseHit:3 http://deb.debian.org/debian trixie-updates InReleaseHit:4 http://deb.debian.org/debian-security trixie-security InReleaseGet:5 http://foo.example.org/debian demo/main amd64 Packages [1097 B]Fetched 5326 B in 0s (43.2 kB/s)All packages are up to date.Warning: http://foo.example.org/debian/dists/demo/InRelease: Policy will reject signature within a year, see --audit for detailsroot@424812bd4556:/# apt --audit updateHit:1 http://foo.example.org/debian demo InReleaseHit:2 http://deb.debian.org/debian trixie InReleaseHit:3 http://deb.debian.org/debian trixie-updates InReleaseHit:4 http://deb.debian.org/debian-security trixie-security InReleaseAll packages are up to date.    Warning:  http://foo.example.org/debian/dists/demo/InRelease: Policy will reject signature within a year, see --audit for detailsAudit:  http://foo.example.org/debian/dists/demo/InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is:   Signing key on 54321ABCD6789ABCD0123ABCD124567ABCD89123 is not bound:              No binding signature at time 2024-06-19T10:33:47Z     because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance     because: SHA1 is not considered secure since 2026-02-01T00:00:00ZAudit: The sources.list(5) entry for 'http://foo.example.org/debian' should be upgraded to deb822 .sourcesAudit: Missing Signed-By in the sources.list(5) entry for 'http://foo.example.org/debian'Audit: Consider migrating all sources.list(5) entries to the deb822 .sources formatAudit: The deb822 .sources format supports both embedded as well as external OpenPGP keysAudit: See apt-secure(8) for best practices in configuring repository signing.Audit: Some sources can be modernized. Run 'apt modernize-sources' to do so.

If you ignored this for the last year, I would like to tell you that 2026-02-01 is not that far away (hello from the past if you’re reading this because you’re already affected).

Let’s simulate the future:

root@424812bd4556:/# apt --update -y install faketime[...]root@424812bd4556:/# export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 FAKETIME="2026-08-29 23:42:11" root@424812bd4556:/# dateSat Aug 29 23:42:11 UTC 2026root@424812bd4556:/# apt updateGet:1 http://foo.example.org/debian demo InRelease [4229 B]Hit:2 http://deb.debian.org/debian trixie InRelease                                 Err:1 http://foo.example.org/debian demo InRelease  Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on 54321ABCD6789ABCD0123ABCD124567ABCD89123 is not bound:            No binding signature at time 2024-06-19T10:33:47Z   because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance   because: SHA1 is not considered secure since 2026-02-01T00:00:00Z[...]Warning: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. OpenPGP signature verification failed: http://foo.example.org/debian demo InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on 54321ABCD6789ABCD0123ABCD124567ABCD89123 is not bound:            No binding signature at time 2024-06-19T10:33:47Z   because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance   because: SHA1 is not considered secure since 2026-02-01T00:00:00Z[...]root@424812bd4556:/# echo $?100

Now, the proper solution would have been to fix the signing key underneath (via e.g.sq cert lint &dash&dashfix &dash&dashcert-file $PRIVAT_KEY_FILE > $PRIVAT_KEY_FILE-fixed).

If you don’t have access to the according private key (e.g. when using an upstream repository that has been ignoring this issue), you’re out of luck for a proper fix.

But there’s a workaround for the apt situation (related seeapt commit 0989275c2f7afb7a5f7698a096664a1035118ebf):

root@424812bd4556:/# cat /usr/share/apt/default-sequoia.config# Default APT Sequoia configuration. To overwrite, consider copying this# to /etc/crypto-policies/back-ends/apt-sequoia.config and modify the# desired values.[asymmetric_algorithms]dsa2048 = 2024-02-01dsa3072 = 2024-02-01dsa4096 = 2024-02-01brainpoolp256 = 2028-02-01brainpoolp384 = 2028-02-01brainpoolp512 = 2028-02-01rsa2048  = 2030-02-01[hash_algorithms]sha1.second_preimage_resistance = 2026-02-01    # Extend the expiry for legacy repositoriessha224 = 2026-02-01[packets]signature.v3 = 2026-02-01   # Extend the expiry

Adjust this according to your needs:

root@424812bd4556:/# mkdir -p /etc/crypto-policies/back-ends/root@424812bd4556:/# cp /usr/share/apt/default-sequoia.config /etc/crypto-policies/back-ends/apt-sequoia.configroot@424812bd4556:/# $EDITOR /etc/crypto-policies/back-ends/apt-sequoia.configroot@424812bd4556:/# cat /etc/crypto-policies/back-ends/apt-sequoia.config# APT Sequoia override configuration[asymmetric_algorithms]dsa2048 = 2024-02-01dsa3072 = 2024-02-01dsa4096 = 2024-02-01brainpoolp256 = 2028-02-01brainpoolp384 = 2028-02-01brainpoolp512 = 2028-02-01rsa2048  = 2030-02-01[hash_algorithms]sha1.second_preimage_resistance = 2026-09-01    # Extend the expiry for legacy repositoriessha224 = 2026-09-01[packets]signature.v3 = 2026-02-01   # Extend the expiry

Then we’re back into the original situation, being a warning instead of an error:

root@424812bd4556:/# apt updateHit:1 http://deb.debian.org/debian trixie InReleaseGet:2 http://foo.example.org/debian demo InRelease [4229 B]Hit:3 http://deb.debian.org/debian trixie-updates InReleaseHit:4 http://deb.debian.org/debian-security trixie-security InReleaseWarning: http://foo.example.org/debian/dists/demo/InRelease: Policy will reject signature within a year, see --audit for details[..]

Please note that this is aworkaround, andnot a proper solution.

Me: Do you want your coffee in a Japanese or Western style tea cup?

M:Yunomi.

Me: Apparently not as well as you think I do!

Review:Dragon Pearl, by Yoon Ha Lee

Dragon Pearl is a middle-grade space fantasy based on Koreanmythology and the first book of a series.

Min is a fourteen-year-old girl living on the barely-terraformed world ofJinju with her extended family. Her older brother Jun passed the entranceexams for the Academy and left to join the Thousand Worlds Space Forces,and Min is counting the years until she can do the same. Those plans arethrown into turmoil when an official investigator appears at their doorclaiming that Jun deserted to search for the Dragon Pearl. A series ofimpulsive fourteen-year-old decisions lead to Min heading for a spaceportalone, determined to find her brother and prove his innocence.

This would be a rather improbable quest for a young girl, but Min is agumiho, one of the supernaturals who live in the Thousand Worlds alongsidenon-magical humans. Unlike the more respectable dragons, tigers, goblins,and shamans, gumiho are viewed with suspicion and distrust because theirpowers are useful for deception. They are natural shapeshifters who cancopy the shapes of others, and their Charm ability lets them influencepeople's thoughts and create temporary illusions of objects such as IDcards. It will take all of Min's powers, and some rather luckycoincidences, to infiltrate the Space Forces and determine what happenedto her brother.

It's common for reviews of this book to open with a caution that this is amiddle-grade adventure novel and you should not expect a story likeNinefox Gambit. I will be boring andrepeat that caution.Dragon Pearl has a single first-personviewpoint and a very linear and straightforward plot. Adult readers areunlikely to be surprised by plot twists; the fun is the world-building andseeing how Min manages to work around plot obstacles.

The world-building is enjoyable but not very rigorous. Min uses and abusesCharm with the creative intensity of aDungeons & Dragonsmin-maxer. Each individual event makes sense given the implication thatMin is unusually powerful, but I'm dubious about the surrounding societyand lack of protections against Charm given what Min is able to do. Mindoes say that gumiho are rare and many people think they're extinct, whichis a bit of a fig leaf, but you'll need to bring your urban fantasysuspension of disbelief skills to this one.

I did like that the world-building conceit went more than skin deep andinfluenced every part of the world. There are ghosts who are critical tothe plot. Terraforming is done through magic, hence the quest for theDragon Pearl and the miserable state of Min's home planet due to its loss.Medical treatment involves the body's meridians, as does engineering: Thestarships have meridians similar to those of humans, and engineers partlymerge with those meridians to adjust them. This is not the sort of bookthat tries to build rigorous scientific theories or explain them to thereader, and I'm not sure everything would hang together if you poked at ittoo hard, but Min isn't interested in doing that poking and the storydoesn't try to justify itself. It's mostly a vibe, but it's a vibe that Ienjoyed and that is rather different than other space fantasy I've read.

The characters were okay but never quite clicked for me, in part becauseproper character exploration would have required Min take a detour fromher quest to find her brother and that was not going to happen. The readergets occasional glimpses of a military SF cadet story and a friendship onfalse premises story, but neither have time to breathe because Min dropsany entanglement that gets in the way of her quest. She's almost amoral ina way that I found believable but not quite aligned with my reading mood.I also felt a bit wrong-footed by how her friendships developed; sayingtoo much more would be a spoiler, but I was expecting more humanconnection than I got.

I think my primary disappointment with this book was something I knewgoing in, not in any way its fault, and part of the reason why I'd put offreading it: This is pitched at young teenagers and didn't have quiteenough plot and characterization complexity to satisfy me. It's a linear,somewhat episodic adventure story with some neat world-building, and ittherefore glides over the spots where an adult novel would have addedpolitical and factional complexity. That is exactly as advertised, so it'sup to you whether that's the book you're in the mood for.

One warning: The text of this book opens with an introduction by RickRiordan that is just fluff marketing and that spoils the first fewchapters of the book. It is unmarked as such at the beginning and trickedme into thinking it was the start of the book proper, and then deeplyannoyed me. If you do read this book, I recommend skipping the utterlypointless introduction and going straight to chapter one.

Followed byTiger Honor.

Rating: 6 out of 10

Snow coming. I'm tuned into the local 24 hour slop weather stream. AIgenerated, narrated, up to the minute radar and forecast graphics. Peoplepopping up on the live weather map with questions "snow soon?" (They payfor the privilege.) LLM generating reply that riffs on their name. Tuned tokeep the urgency up, something is always happening somewhere, scanners arepulling the police reports, live webcam description models addverisimilitude to the description of the morning commute. Weather ishappening.

In the subtext, climate change is happening. Weather is a growth industry.The guy up in Kentucky coal country who put this thing together is buildingan empire. He started as just another local news greenscreener. Dropped outand went twitch weather stream. Hyping up tornado days and dicy snowforecasts. Nowcasting, hyper individualized, interacting with chat.Now he's automated it all. On big days when he's getting real views,the bot breaks into his live streams, gives him a break.

Only a few thousand watching this morning yet. Perfect 2026 grade slop.Details never quite right, but close enough to keep on in the backgroundall day. Nobody expects a perfect forecast after all, and it's fed from theNational Weather Center discussion too. We still fund those guys? Whybother when a bot can do it?

He knows why he's big in these states, these rural areas. Understandsthe target audience. Airbrushed AI aesthetics are ok with them, receive nopushback. Flying more under the radar coastally, but weather is big thereand getting bigger. The local weather will come for us all.

(Not fiction FYI.)

Here’s my monthly but brief update about the activities I’ve done in the FOSS world.

Debian

Whilst I didn’t get a chance to do much, here are still a few things that I worked on:

• A few discussions with the new DFSG team, et al.
• Assited a few folks in getting their patches submitted via Salsa.
• Reviewing pyenv MR for Ujjwal.
• Mentoring for newcomers.
• Moderation of -project mailing list.

Ubuntu

I joinedCanonical to work on Ubuntu full-time back in February 2021.

Whilst I can’t give a full, detailed list of things I did, here’s a quick TL;DR of what I did:

• Successfully releasedResolute Snapshot 3!
  • This one was also done without the ISO tracker and cdimage access.
  • We also worked very hard to build and promote all the image in due time.
• Worked further on the whole artifact signing story for cdimage.
• Assisted a bunch of folks with my Archive Admin and Release team hats to:
  • Helped inEOL’ing Plucky.
  • Starting to help with the upcoming 24.04.4 release.
• With that, the mid-cycle sprints are around the corner, so quite busy preparing for that.

Debian (E)LTS

This month I have worked 59 hoursonDebian Long Term Support (LTS)and on its sisterExtended LTSproject and did the following things:

Released Security Updates

• adminer: Server-side request forgery and redirection vulnerabilities in HTTP drivers.

  • [ELTS]: FixedCVE-2023-45195 andCVE-2023-45196 via4.7.1-1+deb10u2 for buster. This has been released asELA 1605-1.

• u-boot: Improper sanity checks in FAT filesystem handling.

  • [ELTS]: FixedCVE-2025-24857 via2016.11+dfsg1-4+deb9u2 for stretch. This has been released asELA 1608-1.

• ruby-rmagick: Memory leak in Magick::Draw with ImageMagick 6.

  • [LTS]: FixedCVE-2023-5349 via2.16.0-7+deb11u1 for bullseye. This has been released asDLA 4433-1.

• libsodium: Invalid point validation in Ed25519 implementation.

  • [LTS]: FixedCVE-2025-69277 via1.0.18-1+deb11u1 for bullseye. This has been released asDLA 4435-1.
  • [ELTS]: FixedCVE-2025-69277 via1.0.17-1+deb10u1 for buster. This has been released asELA 1631-1.

• ceph: Improper validation of HTTP_X_AMZ_COPY_SOURCE header.

  • [LTS]: FixedCVE-2024-47866 andCVE-2022-0670 via14.2.21-1+deb11u2 for bullseye. This has been released asDLA 4460-1.
  • [ELTS]: FixedCVE-2024-47866 via12.2.11+dfsg1-2.1+deb10u3 for buster and10.2.11-2+deb9u4 for stretch. This has been released asELA 1632-1.

• modsecurity-apache: Invalid request handling vulnerability.

  • [ELTS]: FixedCVE-2025-54571 via2.9.1-2+deb9u5 for stretch. This has been released asELA 1633-1.

• pyasn1: Improper continuation octet limits in OID decoder.

  • [LTS]: FixedCVE-2026-23490 via0.4.8-1+deb11u1 for bullseye. This has been released asDLA 4463-1.
  • [ELTS]: FixedCVE-2026-23490 via0.4.2-3+deb10u1 for buster and0.1.9-2+deb9u1 for stretch. This has been released asELA 1634-1.

• node-lodash: Prototype pollution in baseUnset function.

  • [unstable]: FixedCVE-2025-13465 via4.17.21+dfsg+~cs8.31.198.20210220-10. This has been uploaded to unstable. DLA to follow once this has settled in sid and stable releases.

Work in Progress

• knot-resolver: Affected by CVE-2023-26249, CVE-2023-46317, and CVE-2022-40188, leading to Denial of Service.

  • [LTS]: Some back and forth discussion with maintainers on the best way to proceed for the bullseye upload.
    • Git repository for bullseye:https://salsa.debian.org/lts-team/packages/knot-resolver/-/tree/debian/bullseye.

• ruby-rack: There were multiple vulnerabilities reported in Rack, leading to DoS (memory exhaustion) and proxy bypass.

  • [ELTS]: After completing the work for LTS myself, Bastien picked it up for ELTS and reached out about an upstream regression and we’ve been doing some exchanges. Bastien has done most of the work backporting the patches but needs a review and help backporting CVE-2025-61771. Haven’t made much progress since last month and will carry it over.

• node-lodash: Affected by CVE-2025-13465, lrototype pollution in baseUnset function.

  • [stable]: The patch for trixie and bookworm are ready but haven’t been uploaded yet as I’d like for the unstable upload to settle a bit before I proceed with stable uploads.
  • [LTS]: The bullseye upload will follow once the stable uploads are in and ACK’d by the SRMs.

• xrdp: Affected by CVE-2025-68670, leading to a stack-based buffer overflow.

  • [LTS]: Start to prep the work for bullseye and uploaded to Debusine:https://debusine.debian.net/debian/developers/work-request/367666. ELTS to follow.

Other Activities

• [ELTS] Helped Bastien Roucaries debug a tomcat9 regression for buster.

  • I spent quite a lot of time trying to help Bastien (with Markus and Santiago involved via mail thread) by reproducing the regression that the user(s) reported.
  • I also helped suggest a path forward by vendoring everything, which I was then requested to also help perform.
  • Whilst doing that, I noticed circular dependency hellhole and suggested another path forward by backporting bnd and its dependencies as separate NEW packages.
  • Bastien liked the idea and is going to work on that but preferred to revert the update to remedy the immediate regressions reported. I further helped him in reviewing his update. This conversation happened on #debian-elts IRC channel.

• [LTS] Assisted Ben Hutchings with his question about the next possible steps with a plausible libvirt regression caused by the Linux kernel update. This wasa thread on debian-lts@ mailing list.

• [LTS] Attended the monthly LTS meeting on IRC.Summary here.

• [E/LTS] Monitored discussions on mailing lists, IRC, and all the documentation updates.

Until next time.
:wq for today.

Part
3: Building the Keystone – Dataproc Custom Images for Secure Boot &
GPUs

In Part 1, we established a secure, proxy-only network. In Part 2, we
explored the enhancedinstall_gpu_driver.sh initialization
action. Now, in Part 3, we’ll focus on using theLLC-Technologies-Collier/custom-images
repository (branchproxy-exercise-2025-11) to build the
actual custom Dataproc images embedded with NVIDIA drivers signed for
Secure Boot, all within our proxied environment.

Why Custom Images?

To run NVIDIA GPUs on Shielded VMs with Secure Boot enabled, the
NVIDIA kernel modules must be signed with a key trusted by the VM’s EFI
firmware. Since standard Dataproc images don’t include these
custom-signed modules, we need to build our own. This process also
allows us to pre-install a full stack of GPU-accelerated software.

The
custom-images Toolkit
(examples/secure-boot)

Theexamples/secure-boot directory within the
custom-images repository contains the necessary scripts and
configurations, refined through significant development to handle proxy
and Secure Boot challenges.

Key Components & Development Insights:

• env.json: The central configuration
  file (as used in Part 1) for project, network, proxy, and bucket
  details. This became the single source of truth to avoid configuration
  drift.
• create-key-pair.sh: Manages the Secure
  Boot signing keys (PK, KEK, DB) in Google Secret Manager, essential for
  the module signing.
• build-and-run-podman.sh: Orchestrates
  the image build process in an isolated Podman container. This was
  introduced to standardize the build environment and encapsulate
  dependencies, simplifying what the user needs to install locally.
• pre-init.sh: Sets up the build
  environment within the container and calls
  generate_custom_image.py. It crucially passes metadata
  derived fromenv.json (like proxy settings and Secure Boot
  key secret names) to the temporary build VM.
• generate_custom_image.py: The core
  Python script that automates GCE VM creation, runs the customization
  script, and creates the final GCE image.
• gce-proxy-setup.sh: This script from
  startup_script/ is vital. It’s injected into the temporary
  build VM and runsfirst to configure the OS, package
  managers (apt, dnf), tools (curl, wget, GPG), Conda, and Java to use the
  proxy settings passed in the metadata. This ensures the entire build
  process is proxy-aware.
• install_gpu_driver.sh: Used as the
  --customization-script within the build VM. As detailed in
  Part 2, this script handles the driver/CUDA/ML stack installation and
  signing, now able to function correctly due to the proxy setup by
  gce-proxy-setup.sh.

Layered Image Strategy:

Thepre-init.sh script employs a layered approach:

1. secure-boot Image: Base image with
   Secure Boot certificates injected.
2. tf Image: Based on
   secure-boot, this image runs the full
   install_gpu_driver.sh within the proxy-configured build VM
   to install NVIDIA drivers, CUDA, ML libraries (TensorFlow, PyTorch,
   RAPIDS), and sign the modules. This is the primary target image for our
   use case.

(Note:secure-proxy andproxy-tf layers
were experiments, but the-tf image combined with runtime
metadata emerged as the most effective solution for 2.2-debian12).

Build Steps:

1. Clone Repos & Configure
   env.json: Ensure you have the
   custom-images andcloud-dataproc repos and a
   completeenv.json as described in Part 1.

2. Run the Build:
   bash # Example: Build a 2.2-debian12 based image set # Run from the custom-images repository root bash examples/secure-boot/build-and-run-podman.sh 2.2-debian12
   This command will build the layered images, leveraging the proxy
   settings fromenv.json via the metadata injected into the
   build VM. Note the final image name produced (e.g.,
   dataproc-2-2-deb12-YYYYMMDD-HHMMSS-tf).

Conclusion of Part 3

Through an iterative process, we’ve developed a robust workflow
within thecustom-images repository to build Secure
Boot-compatible GPU images in a proxy-only environment. The key was
isolating the build in Podman, ensuring the build VM is fully
proxy-aware usinggce-proxy-setup.sh, and leveraging the
enhancedinstall_gpu_driver.sh from Part 2.

In Part 4, we’ll bring it all together, deploying a Dataproc cluster
using this custom-tf image within the secure network, and
verifying the end-to-end functionality.

The following contributors got their Debian Developer accounts in the last twomonths:

• Aquila Macedo (aquila)
• Peter Blackman (peterb)
• Kiran S Kunjumon (hacksk)
• Ben Westover (bjw)

The following contributors were added as Debian Maintainers in the last twomonths:

• Vladimir Petko
• Antonin Delpeuch
• Nadzeya Hutsko
• Aryan Karamtoth
• Carl Keinath
• Richard Nelson

Congratulations!

Part
2: Taming the Beast – Deep Dive into the Proxy-Aware GPU Initialization
Action

In Part 1 of this series, we laid the network foundation for running
secure Dataproc clusters. Now, let’s zoom in on the core component
responsible for installing and configuring NVIDIA GPU drivers and the
associated ML stack in this restricted environment: the
install_gpu_driver.sh script from theLLC-Technologies-Collier/initialization-actions
repository (branchgpu-202601).

This isn’t just any installation script; it has been significantly
enhanced to handle the nuances of Secure Boot and to operate seamlessly
behind an HTTP/S proxy.

The
Challenge: Installing GPU Drivers Without Direct Internet

Our goal was to create a Dataproc custom image with NVIDIA GPU
drivers, sign the kernel modules for Secure Boot, and ensure the entire
process works seamlessly when the build VM and the eventual cluster
nodes have no direct internet access, relying solely on an HTTP/S proxy.
This involved:

1. Proxy-Aware Build: Ensuring all build steps within
   the custom image creation process (package downloads, driver downloads,
   GPG keys, etc.) correctly use the customer’s proxy.
2. Secure Boot Signing: Integrating kernel module
   signing using keys managed in GCP Secret Manager, especially when
   drivers are built from source.
3. Conda Environment: Reliably and speedily installing
   a complex Conda environment with PyTorch, TensorFlow, Rapids, and other
   GPU-accelerated libraries through the proxy.
4. Dataproc Integration: Making sure the custom image
   works correctly with Dataproc’s own startup, agent processes, and
   cluster-specific configurations like YARN.

The
Development Journey: Key Enhancements in
install_gpu_driver.sh

To address these challenges, the script incorporates several key
features:

• Robust Proxy Handling (set_proxy
  function):
  • Challenge: Initial script versions had spotty proxy
    support. Many tools likeapt,curl,
    gpg, and evengsutil failed in proxy-only
    environments.
  • Enhancements: Theset_proxy function
    (also used ingce-proxy-setup.sh) was completely overhauled
    to parse various proxy metadata (http-proxy,
    https-proxy,proxy-uri,
    no-proxy). Critically, environment variables
    (HTTP_PROXY,HTTPS_PROXY,
    NO_PROXY) are now setbefore any network
    operations.NO_PROXY is carefully set to include
    .google.com and.googleapis.com to allow
    direct access to Google APIs via Private Google Access. System-wide
    trust stores (OS, Java, Conda) are updated with the proxy’s CA
    certificate if provided viahttp-proxy-pem-uri.
    gcloud,apt,dnf, and
    dirmngr are also configured to use the proxy.
• Reliable GPG Key Fetching (import_gpg_keys
  function):
  • Challenge: Importing GPG keys for repositories
    often failed as keyservers use non-HTTP ports (e.g., 11371) blocked by
    firewalls, andgpg --recv-keys is not proxy-friendly.
  • Solution: A newimport_gpg_keys
    function now fetches keys over HTTPS usingcurl, which
    respects the environment’s proxy settings. This replaced all direct
    gpg --recv-keys calls.
• GCS Caching is King:
  • Challenge: Repeatedly downloading large files
    (drivers, CUDA, source code) through a proxy is slow and
    inefficient.
  • Solution: Implemented extensive GCS caching for
    NVIDIA drivers, CUDA runfiles, NVIDIA Open Kernel Module source
    tarballs, compiled kernel modules, and even packed Conda environments.
    Scripts now check a GCS bucket (dataproc-temp-bucket)
    before hitting the internet.
  • Impact: Dramatically speeds up subsequent runs and
    init action execution times on cluster nodes after the cache is
    warmed.
• Conda Environment Stability & Speed:
  • Challenge: Large Conda environments are prone to
    solver conflicts and slow installation times.
  • Solution: Integrated Mamba for faster package
    solving. Refined package lists for better compatibility. Added logic to
    force-clean and rebuild the Conda environment cache on GCS and locally
    if inconsistencies are detected (e.g., driver installed but Conda env
    not fully set up).
• Secure Boot & Kernel Module Signing:
  • Challenge: Custom-compiled kernel modules must be
    signed to load when Secure Boot is enabled.
  • Solution: The script integrates with GCP Secret
    Manager to fetch signing keys. Thebuild_driver_from_github
    function now includes robust steps to compile, sign (using
    sign-file), install, and verify the signed modules.
• Custom Image Workflow & Deferred Configuration:
  • Challenge: Cluster-specific settings (like YARN GPU
    configuration) should not be baked into the image.
  • Solution: Theinstall_gpu_driver.sh
    script detects when it’s run during image creation
    (--metadata invocation-type=custom-images). In this mode,
    it defers cluster-specific setups to a systemd service
    (dataproc-gpu-config.service) that runs on the first boot
    of a cluster instance. This ensures that YARN and Spark configurations
    are applied in the context of the running cluster, not at image build
    time.

Conclusion of Part 2

Theinstall_gpu_driver.sh initialization action is more
than just an installer; it’s a carefully crafted tool designed to handle
the complexities of secure, proxied environments. Its robust proxy
support, comprehensive GCS caching, refined Conda management, Secure
Boot signing capabilities, and awareness of the custom image build
lifecycle make it a critical enabler.

In Part 3, we’ll explore how theLLC-Technologies-Collier/custom-images
repository (branchproxy-exercise-2025-11) uses this
initialization action to build the complete, ready-to-deploy Secure Boot
GPU custom images.

Part
1: Building a Secure Network Foundation for Dataproc with GPUs &
SWP

Welcome to the first post in our series on running GPU-accelerated
Dataproc workloads in secure, enterprise-grade environments. Many
organizations need to operate within VPCs that have no direct internet
egress, instead routing all traffic through a Secure Web Proxy (SWP).
Additionally, security mandates often require the use of Shielded VMs
with Secure Boot enabled. This series will show you how to meet these
requirements for your Dataproc GPU clusters.

In this post, we’ll focus on laying the network foundation using
tools from theLLC-Technologies-Collier/cloud-dataproc
repository (branchproxy-sync-2026-01).

The Challenge: Network
Isolation & Control

Before we can even think about custom images or GPU drivers, we need
a network environment that:

1. Prevents direct internet access from Dataproc cluster nodes.
2. Forces all egress traffic through a manageable and auditable
   SWP.
3. Provides the necessary connectivity for Dataproc to function and for
   us to build images later.
4. Supports Secure Boot for all VMs.

The Toolkit:
LLC-Technologies-Collier/cloud-dataproc

To make setting up and tearing down these complex network
environments repeatable and consistent, we’ve developed a set of bash
scripts within thegcloud directory of the
cloud-dataproc repository. These scripts handle the
creation of VPCs, subnets, firewall rules, service accounts, and the
Secure Web Proxy itself.

Key Script:
gcloud/bin/create-dpgce-private

This script is the cornerstone for creating the private, proxied
environment. It automates:

• VPC and Subnet creation (for the cluster, SWP, and management).
• Setup of Certificate Authority Service and Certificate Manager for
  SWP TLS interception.
• Deployment of the SWP Gateway instance.
• Configuration of a Gateway Security Policy to control egress.
• Creation of necessary firewall rules.
• Result: Cluster nodes in this VPC have NO default
  internet route and MUST use the SWP.

Configuration viaenv.json

We use a singleenv.json file to drive the
configuration. This file will also be used by the
custom-images scripts in Part 3. Thisenv.json
should reside in yourcustom-images repository clone, and
you’ll symlink it into thecloud-dataproc/gcloud
directory.

Running the Setup:

# Assuming you have cloud-dataproc and custom-images cloned side-by-side# And your env.json is in the custom-images rootcd cloud-dataproc/gcloud# Symlink to the env.json in custom-imagesln-sf ../../custom-images/env.json env.json# Run the creation script, but don't create a cluster yetbash bin/create-dpgce-private--no-create-clustercd ../../custom-images

Node
Configuration: The Metadata Startup Script for Runtime

For the Dataproc cluster nodes to function correctly in this proxied
environment, they need to be configured to use the SWP on boot. We
achieve this using a GCE metadata startup script.

The scriptstartup_script/gce-proxy-setup.sh (from the
custom-images repository) is designed to be run on each
cluster node at boot. It reads metadata likehttp-proxy and
http-proxy-pem-uri (which our cluster creation scripts in
Part 4 will pass) to configure the OS environment, package managers, and
other tools to use the SWP.

Upload this script to your GCS bucket:

# Run from the custom-images repository rootgsutil cp startup_script/gce-proxy-setup.sh gs://$(jq-r .BUCKET env.json)/custom-image-deps/

This script is essential for theruntime behavior of the
cluster nodes.

Conclusion of Part 1

With thecloud-dataproc scripts, we’ve laid the
groundwork by provisioning a secure VPC with controlled egress through
an SWP. We’ve also prepared the essential node-level proxy configuration
script (gce-proxy-setup.sh) in GCS, ready to be used by our
clusters.

Stay tuned for Part 2, where we’ll dive into the
install_gpu_driver.sh initialization action from the
LLC-Technologies-Collier/initialization-actions repository
(branchgpu-202601) and how it’s been adapted to install
all GPU-related software through the proxy during the image build
process.

With TLS 1.3 more parts of the handshake got encrypted(e.g. the certificate), but sometimes it's still helpful to lookat the complete handshake.

curl uses the somewhat standardized env variable for the key log file calledSSLKEYLOGFILE,which is also supported by Firefox and Chrome. wireshark hides the setting in the UI behindEdit -> Preferences -> Protocols -> TLS -> (Pre)-Master-Secret log filename which isuncomfortable to reach. Looking up the config setting in theAdvanced settingsone can learn that it's called internallytls.keylog_file. Thus we can set it up with:

sudo wireshark -o "tls.keylog_file:/home/sven/curl.keylog"SSLKEYLOGFILE=/home/sven/curl.keylog curl -v https://www.cloudflare.com/cdn-cgi/trace

Depending on the setup root might be unable to access the wayland session, that canbe worked around by letting sudo keep the relevant env variables:

$ cat /etc/sudoers.d/wayland Defaults   env_keep += "XDG_RUNTIME_DIR"Defaults   env_keep += "WAYLAND_DISPLAY"

Or setup wireshark properly and use thewireshark group to be able to dumptraffic. Might require asudo dpkg-reconfigure wireshark-common.

Regarding curl: In some situations it could be desirable to forcea specific older TLS version for testing, which requires aminimalandmaximalversion. E.g. to force TLS 1.2 only:

curl -v --tlsv1.2 --tls-max 1.2 https://www.cloudflare.com/cdn-cgi/trace