Matthew Garrett

How Twitter could (somewhat) fix their encrypted DMs

As I wrote in my last post, Twitter's new encrypted DM infrastructure is pretty awful. But the amount of work required to make it somewhat better isn't large.

When Juicebox is used with HSMs, it supports encrypting the communication between the client and the backend. This is handled by generating a unique keypair for each HSM. The public key is provided to the client, while the private key remains within the HSM. Even if you can see the traffic sent to the HSM, it's encrypted using the Noise protocol and so the user's encrypted secret data can't be retrieved.

But this is only useful if you know that the public key corresponds to a private key in the HSM! Right now there's no way to know this, but there's worse - the client doesn't have the public key built into it, it's supplied as a response to an API request made to Twitter's servers. Even if the current keys are associated with the HSMs, Twitter could swap them out with ones that aren't, terminate the encrypted connection at their endpoint, and then fake your query to the HSM and get the encrypted data that way. Worse, this could be done for specific targeted users, without any indication to the user that this has happened, making it almost impossible to detect in general.

This is at least partially fixable. Twitter could prove to a third party that their Juicebox keys were generated in an HSM, and the key material could be moved into clients. This makes attacking individual users more difficult (the backdoor code would need to be shipped in the public client), but can't easily help with the website version[1] even if a framework exists to analyse the clients and verify that the correct public keys are in use.

It's still worse than Signal. Use Signal.

[1] Since they could still just serve backdoored Javascript to specific users. This is, unfortunately, kind of an inherent problem when it comes to web-based clients - we don't have good frameworks to detect whether the site itself is malicious.

comments

05 June, 2025 01:18PM

Twitter's new encrypted DMs aren't better than the old ones

(Edit: Twitter could improve this significantly with very few changes - I wrote about that here. It's unclear why they'd launch without doing that, since it entirely defeats the point of using HSMs)

When Twitter[1] launched encrypted DMs a couple
of years ago, it was the worst kind of end-to-end
encrypted - technically e2ee, but in a way that made it relatively easy for Twitter to inject new encryption keys and get everyone's messages anyway. It was also lacking a whole bunch of features such as "sending pictures", so the entire thing was largely a waste of time. But a couple of days ago, Elon announced the arrival of "XChat", a new encrypted message platform built on Rust with (Bitcoin style) encryption, whole new architecture. Maybe this time they've got it right?

tl;dr - no. Use Signal. Twitter can probably obtain your private keys, and admit that they can MITM you and have full access to your metadata.

The new approach is pretty similar to the old one in that it's based on pretty straightforward and well tested cryptographic primitives, but merely using good cryptography doesn't mean you end up with a good solution. This time they've pivoted away from using the underlying cryptographic primitives directly and into higher level abstractions, which is probably a good thing. They're using Libsodium's boxes for message encryption, which is, well, fine? It doesn't offer forward secrecy (if someone's private key is leaked then all existing messages can be decrypted) so it's a long way from the state of the art for a messaging client (Signal's had forward secrecy for over a decade!), but it's not inherently broken or anything. It is, however, written in C, not Rust[2].

That's about the extent of the good news. Twitter's old implementation involved clients generating keypairs and pushing the public key to Twitter. Each client (a physical device or a browser instance) had its own private key, and messages were simply encrypted to every public key associated with an account. This meant that new devices couldn't decrypt old messages, and also meant there was a maximum number of supported devices and terrible scaling issues and it was pretty bad. The new approach generates a keypair and then stores the private key using the Juicebox protocol. Other devices can then retrieve the private key.

Doesn't this mean Twitter has the private key? Well, no. There's a PIN involved, and the PIN is used to generate an encryption key. The stored copy of the private key is encrypted with that key, so if you don't know the PIN you can't decrypt the key. So we brute force the PIN, right? Juicebox actually protects against that - before the backend will hand over the encrypted key, you have to prove knowledge of the PIN to it (this is done in a clever way that doesn't directly reveal the PIN to the backend). If you ask for the key too many times while providing the wrong PIN, access is locked down.

But this is true only if the Juicebox backend is trustworthy. If the backend is controlled by someone untrustworthy[3] then they're going to be able to obtain the encrypted key material (even if it's in an HSM, they can simply watch what comes out of the HSM when the user authenticates if there's no validation of the HSM's keys). And now all they need is the PIN. Turning the PIN into an encryption key is done using the Argon2id key derivation function, using 32 iterations and a memory cost of 16MB (the Juicebox white paper says 16KB, but (a) that's laughably small and (b) the code says 16 * 1024 in an argument that takes kilobytes), which makes it computationally and moderately memory expensive to generate the encryption key used to decrypt the private key. How expensive? Well, on my (not very fast) laptop, that takes less than 0.2 seconds. How many attempts to I need to crack the PIN? Twitter's chosen to fix that to 4 digits, so a maximum of 10,000. You aren't going to need many machines running in parallel to bring this down to a very small amount of time, at which point private keys can, to a first approximation, be extracted at will.

Juicebox attempts to defend against this by supporting sharding your key over multiple backends, and only requiring a subset of those to recover the original. ~~I can't find any evidence that Twitter's does seem to be making use of this,~~Twitter uses three backends and requires data from at least two, but all the backends used are under x.com so are presumably under Twitter's direct control. Trusting the keystore without needing to trust whoever's hosting it requires a trustworthy communications mechanism between the client and the keystore. If the device you're talking to can prove that it's an HSM that implements the attempt limiting protocol and has no other mechanism to export the data, this can be made to work. Signal makes use of something along these lines using Intel SGX for contact list and settings storage and recovery, and Google and Apple also have documentation about how they handle this in ways that make it difficult for them to obtain backed up key material. Twitter has no documentation of this, and as far as I can tell does nothing to prove that the backend is in any way trustworthy. (Edit to add: The Juicebox API does support authenticated communication between the client and the HSM, but that relies on you having some way to prove that the public key you're presented with corresponds to a private key that only exists in the HSM. Twitter gives you the public key whenever you communicate with them, so even if they've implemented this properly you can't prove they haven't made up a new key and MITMed you the next time you retrieve your key)

On the plus side, Juicebox is written in Rust, so Elon's not 100% wrong. Just mostly wrong.

But ok, at least you've got viable end-to-end encryption even if someone can put in some (not all that much, really) effort to obtain your private key and render it all pointless? Actually no, since you're still relying on the Twitter server to give you the public key of the other party and there's no out of band mechanism to do that or verify the authenticity of that public key at present. Twitter can simply give you a public key where they control the private key, decrypt the message, and then reencrypt it with the intended recipient's key and pass it on. The support page makes it clear that this is a known shortcoming and that it'll be fixed at some point, but they said that about the original encrypted DM support and it never was, so that's probably dependent on whether Elon gets distracted by something else again. And the server knows who and when you're messaging even if they haven't bothered to break your private key, so there's a lot of metadata leakage.

Signal doesn't have these shortcomings. Use Signal.

[1] I'll respect their name change once Elon respects his daughter

[2] There are implementations written in Rust, but Twitter's using the C one with these JNI bindings

[3] Or someone nominally trustworthy but who's been compelled to act against your interests - even if Elon were absolutely committed to protecting all his users, his overarching goals for Twitter require him to have legal presence in multiple jurisdictions that are not necessarily above placing employees in physical danger if there's a perception that they could obtain someone's encryption keys

comments

05 June, 2025 11:02AM

François Marier

Blocking comment spammers on an Ikiwiki blog

Despite comments on my ikiwiki blog being fully moderated, spammers have been increasingly posting link spam comments on my blog. While I used to use the blogspam plugin, the underlying service was likely retired circa 2017 and its public repositories are all archived.

It turns out that there is a relatively simple way to drastically reduce the amount of spam submitted to the moderation queue: ban the datacentre IP addresses that spammers are using.

Looking up AS numbers

It all starts by looking at the IP address of a submitted comment:

From there, we can look it up using whois:

$ whois -r 2a0b:7140:1:1:5054:ff:fe66:85c5

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See https://docs.db.ripe.net/terms-conditions.html

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '2a0b:7140:1::/48'

% Abuse contact for '2a0b:7140:1::/48' is 'abuse@servinga.com'

inet6num:       2a0b:7140:1::/48
netname:        EE-SERVINGA-2022083002
descr:          servinga.com - Estonia
geoloc:         59.4424455 24.7442221
country:        EE
org:            ORG-SG262-RIPE
mnt-domains:    HANNASKE-MNT
admin-c:        CL8090-RIPE
tech-c:         CL8090-RIPE
status:         ASSIGNED
mnt-by:         MNT-SERVINGA
created:        2020-02-18T11:12:49Z
last-modified:  2024-12-04T12:07:26Z
source:         RIPE

% Information related to '2a0b:7140:1::/48AS207408'

route6:         2a0b:7140:1::/48
descr:          servinga.com - Estonia
origin:         AS207408
mnt-by:         MNT-SERVINGA
created:        2020-02-18T11:18:11Z
last-modified:  2024-12-11T23:09:19Z
source:         RIPE

% This query was served by the RIPE Database Query Service version 1.114 (SHETLAND)

The important bit here is this line:

origin:         AS207408

which referts to Autonomous System 207408, owned by a hosting company in Germany called Servinga.

Alternatively, you can use this WHOIS server with much better output:

$ whois -h whois.cymru.com -v 2a0b:7140:1:1:5054:ff:fe66:85c5
AS      | IP                                       | BGP Prefix          | CC | Registry | Allocated  | AS Name
207408  | 2a0b:7140:1:1:5054:ff:fe66:85c5          | 2a0b:7140:1::/48    | DE | ripencc  | 2017-07-11 | SERVINGA-EE, DE

Looking up IP blocks

Autonomous Systems are essentially organizations to which IPv4 and IPv6 blocks have been allocated.

These allocations can be looked up easily on the command line either using a third-party service:

$ curl -sL https://ip.guide/as207408 | jq .routes.v4 >> servinga
$ curl -sL https://ip.guide/as207408 | jq .routes.v6 >> servinga

or a local database downloaded from IPtoASN.

This is what I ended up with in the case of Servinga:

[
  "45.11.183.0/24",
  "80.77.25.0/24",
  "194.76.227.0/24"
]
[
  "2a0b:7140:1::/48"
]

Preventing comment submission

While I do want to eliminate this source of spam, I don't want to block these datacentre IP addresses outright since legitimate users could be using these servers as VPN endpoints or crawlers.

I therefore added the following to my Apache config to restrict the CGI endpoint (used only for write operations such as commenting):

<Location /blog.cgi>
        Include /etc/apache2/spammers.include
        Options +ExecCGI
        AddHandler cgi-script .cgi
</Location>

and then put the following in /etc/apache2/spammers.include:

<RequireAll>
    Require all granted

    # https://ipinfo.io/AS207408
    Require not ip 46.11.183.0/24
    Require not ip 80.77.25.0/24
    Require not ip 194.76.227.0/24
    Require not ip 2a0b:7140:1::/48
</RequireAll>

Finally, I can restart the website and commit my changes:

$ apache2ctl configtest && systemctl restart apache2.service
$ git commit -a -m "Ban all IP blocks from Servinga"

Future improvements

I will likely automate this process in the future, but at the moment my blog can go for a week without a single spam message (down from dozens every day). It's possible that I've already cut off the worst offenders.

I have published the list I am currently using.

04 June, 2025 08:28PM

Gunnar Wolf

The subjective value of privacy • Assessing individuals' calculus of costs and benefits in the context of state surveillance

This post is an unpublished review for The subjective value of privacy • Assessing individuals' calculus of costs and benefits in the context of state surveillance

Internet users, software developers, academics, entrepreneurs – basically everybody is now aware of the importance of considering privacy as a core part of our online experience. User demand, and various national or regional laws, have made privacy a continuously present subject. However, how do regular people –like ourselves, in our many capacities– feel about privacy? Lukas Antoine presents a series of experiments aiming at better understanding how people throughout the world understands privacy, and when is privacy held as more or less important than security in different aspects,

Particularly, privacy is often portrayed as a value set at tension against surveillance, and particularly state surveillance, in the name of security: conventional wisdom presents the idea of privacy calculus. This is, it is often assumed that individuals continuously evaluate the costs and benefits of divulging their personal data, sharing data when they expect a positive net outcome, and denying it otherwise. This framework has been accepted for decades, and the author wishes to challenge it. This book is clearly his doctoral thesis on political sciences, and its contents are as thorough as expected in this kind of product.

The author presents three empirical studies based on cross-survey analysis. The first experiment explores the security justifications for surveillance and how they influence their support. The second one searches whether the stance on surveillance can be made dependent on personal convenience or financial cost. The third study explores whether privacy attitude is context-dependant or can be seen as a stable personality trait. The studies aim to address the shortcomings of published literature in the field, mainly, (a) the lack of comprehensive research on state surveillance, needed or better understanding privacy appreciation, (b) while several studies have tackled the subjective measure of privacy, there is a lack of cross-national studies to explain wide-ranging phenomena, (c) most studies in this regard are based on population-based surveys, which cannot establish causal relationships, (d) a seemingly blind acceptance of the privacy calculus mentioned above, with no strong evidence that it accurately measures people’s motivations for disclosing or withholding their data.

The book is full with theoretical references and does a very good job of explaining the path followed by the author. It is, though, a heavy read, and, for people not coming from the social sciences tradition, leads to the occasional feeling of being lost. The conceptual and theoretical frameworks and presented studies are thorough and clear. The author is honest in explaining when the data points at some of his hypotheses being disproven, while others are confirmed.

The aim of the book is for people digging deep into this topic. Personally, I have authored several works on different aspects of privacy, but this book did get me thinking on many issues I had not previously considered. My only complaint would be that, for the publication as part of its highly prestigious publisher, little attention has been paid to editorial aspects: sub-subsection depth is often excessive and unclear. Also, when publishing monographs based on doctoral works, it is customary to no longer refer to the work as a “thesis” and to soften some of the formal requirements such a work often has, with the aim of producing a more gentle and readable book; this book seems just like the mass-production of an (otherwise very interesting and well made) thesis work.

04 June, 2025 03:40PM

Humanities and big data in Ibero-America • Theory, methodology and practical applications

This post is an unpublished review for Humanities and big data in Ibero-America • Theory, methodology and practical applications

Digital humanities is a young–though established–field. It deals with different expressions in which digital data manipulation techniques can be applied and used to analyze subjects that are identified as belonging to the humanities. Although most often used to analyze different aspects of literature or social network analysis, it can also be applied to other humanistic disciplines or artistic expressions. Digital humanities employs many tools, but those categorized as big data are among the most frequently employed. This book samples different takes on digital humanities, with the particularity that it focuses on Ibero-American uses. It is worth noting that this book is the second in a series of four volumes, published or set to be published between 2022 and 2026. Being the output of a field survey, I perceive this book to be targeted towards fellow Digital Humanists – people interested in applying computational methods to further understand and research topics in the humanities. It is not a technical book in the sense Computer Science people would recognize as such, but several of the presented works do benefit from understanding some technical concepts.

The 12 articles (plus an introduction) that make up this book are organized in three parts:

(1) “Theoretical Framework” presents the ideas and techniques of data science (that make up the tools for handling big data), and explores how data science can contribute to literary analysis, all while noting that many such techniques are usually frowned upon in Latin America as data science “smells neoliberal”;

(2) “Methodological Issues” looks at specific issues through the lens of how they can be applied to big data, with specific attention given to works in Spanish; and

(3) “Practical Applications” analyzes specific Spanish works and communities based on big data techniques.

Several chapters treat a recurring theme: the simultaneous resistance and appropriation of big data by humanists. For example, at least three of the chapters describe the tensions between humanism (“aesthesis”) and cold, number-oriented data analysis (“mathesis”).

The analyzed works of Parts 2 and 3 are interesting and relatively easy to follow.

Some inescapable ideological gleans from several word uses – from the book’s and series’ name, which refers to the Spanish-speaking regions as “Ibero-America”, often seen as Eurocentric, in contrast with the “Latin America” term much more widely used throughout the region.

I will end with some notes about the specific versions of the book I reviewed. I read both an EPUB version and a print copy. The EPUB did not include links for easy navigation to footnotes, that is, the typographical superindexes are not hyperlinked to the location of the notes, so it is very impractical to try to follow them. The print version (unlike the EPUB) did not have an index, that is, the six pages before the introduction are missing from the print copy I received. For a book such as this one, not having an index hampers the ease of reading and referencing.

04 June, 2025 03:40PM

Beyond data poisoning in federated learning

This post is an unpublished review for Beyond data poisoning in federated learning

The current boom of artificial intelligence (AI) is based upon neural networks (NNs). In order for these to be useful, the network has to undergo a machine learning (ML) process: work over a series of inputs, and adjust the inner weights of the connections between neurons so that each of the data samples the network was trained on produces the right set of labels for each item. Federated learning (FL) appeared as a reaction given the data centralization power that traditional ML provides: instead of centrally controlling the whole training data, various different actors analyze disjoint subsets of data, and provide only the results of this analysis, thus increasing privacy while analyzing a large dataset. Finally, given multiple actors are involved in FL, how hard is it for a hostile actor to provide data that will confuse the NN, instead of helping it reach better performance? This kind of attack is termed a poisoning attack, and is the main focus of this paper. The authors set out to research how effective can a hyperdimensional data poisoning attack (HDPA) be to confuse a NN and cause it to misclassify both the items trained on and yet unseen items.

Data used for NN training is usually represented as a large set of orthogonal vectors, each describing a different aspect of the item, allowing for very simple vector arithmetic operations. Thus, NN training is termed as high-dimensional or hyperdimensional. The attack method described by the authors employs cosine similarity, that is, in order to preserve similarity, a target hypervector is reflected over a given dimension, yielding a cosine-similar result that will trick ML models, even if using byzantine-robust defenses.

The paper is clear, though not an easy read. It explains in detail the mathematical operations, following several related although different threat models. The authors present the results of the experimental evaluation of their proposed model, comparing it to several other well-known adversarial attacks for visual recognition tasks, over pre-labeled datasets frequently used as training data, such as MNIST, Fashion-MNIST and CIFAR-10. They show that their method is not only more effective as an attack, but falls within the same time range as other surveyed attacks.

Adversarial attacks are, all in all, an important way to advance any field of knowledge; by publishing this attack, the authors will surely spark other works to detect and prevent this kind of alteration. It is important for AI implementers to understand the nature of this field and be aware of the risks that this work, as well as others cited in it, highlight: ML will train a computer system to recognize a dataset, warts and all; efficient as AI is, if noise is allowed into the training data (particularly adversarially generated noise), the trained model might present impaired performance.

04 June, 2025 03:39PM

Computational modelling of robot personhood and relationality

This post is an unpublished review for Computational modelling of robot personhood and relationality

If humans and robots were to be able to roam around the same spaces, mutually recognizing each other for what they are, how would interaction be? How can we model such interactions in a way that we can reason about and understand the implications of a given behavior? This book aims at answering this question.

The book is split into two very different parts. Chapters 1 through 3 are mostly written with a philosophical angle. It starts by framing the possibility of having sentient androids exist in the same plane as humans, without them trying to pass as us or vice versa. The first chapters look at issues related to personhood, that is, how androids can be treated as valid interaction partners in a society with humans, and how interactions with them can be seen as meaningful. In doing so, several landmarks of the past 40 years in the AI field are reviewed. The issues of the “Significant Concerns” that make up a society and give it coherence and of “Personhood and Relationality”, describing how this permeates from a society into each of the individuals that make it up, the relations between them and the social objects that bring individuals closer together (or farther apart) are introduced and explained.

The second part of the book is written from a very different angle, and the change in pace took me somewhat by surprise. Each subsequent chapter presents a different angle of the “Affinity” system, a model that follows some aspects of human behavior over time and in a given space. Chapter 4 introduces the “Affinity” environment: a 3D simulated environment with simulated physical laws and characteristics, where a number of agents (30-50 is mentioned as usual) interact. Agents have a series of attributes (“value memory”), can adhere to different programs (“narratives”), and gain or lose on some vectors (“economy”). They can sense the world around them with sensors, and can modify the world or signal other agents using effectors.

The last two chapters round out the book, as expected: the first presents a set of results from analyzing a given set of value systems, and the second gives readers the conclusions reached by the author. However, I was expecting more–either having at least a link to download the “Affinity” system and continue exploring it or modifying some of the aspects it models to get it to model a set of agents with different stories and narratives, or extend it to yet unforseen behaviors, or at least have the author present a more complete comparison of results than the evaluation of patterns resulting from a given run. The author is a well-known, prolific author in the field, and I was expecting bigger insights from this book.

Nevertheless, the book is an interesting and fun read, with important insights in both the first and second parts. There is a certain lack of connection between their respective rhythms, and the second part indeed builds on the concepts introduced in the first one. Overall, I enjoyed reading the book despite expecting more.

04 June, 2025 03:39PM

Will be adding yet-to-be-published reviews

Since December 2023, I have been publishing the reviews I write for Computing Reviews as they get published. I will do a slight change now: I will start pushing the reviews to my blog as I write them, and of course, will modify them with the final wording and to link to their place as soon as they are published. I’m doing this because sometimes it takes very long for reviews to be approved, and I want to share them with my blog’s readers!

So, please bear with this a bit: I’ll send a (short!) flood of my latest four pending reviews today.

Some books I have recently read

04 June, 2025 03:24PM

Russell Coker

Trying DeepSeek R1

I saw this document on running DeepSeek R1 [1] and decided to give it a go. I downloaded the llama.cpp source and compiled it and downloaded the 131G of data as described. Running it with the default options gave about 7 CPU cores in use. Changing the --threads parameter to 44 caused it to use 17 CPU cores (changing it to larger numbers like 80 made it drop to 2.5 cores). I used the --n-gpu-layers parameter with the value of 1 as I currently have a GPU with only 6G of RAM (AliExpress is delaying my delivery of a PCIe power adaptor for a better GPU). Running it like this makes the GPU take 12W more power than standby and using 5.5G of VRAM according to nvidia-smi so it is doing a small amount of work, but not much. The documentation refers to the DeepSeek R1 1.58bit model which I’m using as having 61 layers so presumably less than 2% of the work is done on the GPU.

Running like this it takes 2 hours of CPU time (just over 3 minutes of elapsed time at 17 cores) to give 8 words of output. I didn’t let any tests run long enough to give complete output.

The documentation claims that it will run on CPU with 20G of RAM. In my tests it takes between 161G and 195G of RAM to run depending on the number of threads. The documentation describes running on the CPU as “very slow” which presumably means 3 words per minute on a system with a pair of E5-2699A v4 CPUs and 256G of RAM.

When I try to use more than 44 threads I get output like “system_info: n_threads = 200 (n_threads_batch = 200) / 44” and it seems that I only have a few threads actually in use. Apparently there’s some issue with having more threads than the 44 CPU cores in the system.

I was expecting this to go badly and it met my expectations in that regard. But it was interesting to see exactly how it went badly. It seems that if I had a GPU with 24G of VRAM I’d still have 54/61 layers running on the CPU so even the largest of home GPUs probably wouldn’t make much difference.

Maybe if I configured the server to have hyper-threading enabled and 88 HT cores then I could have 88 threads and about 34 CPU cores in use which might help. But even if I got the output speed from 3 to 6 words per minute that still wouldn’t be very usable.

[1] https://unsloth.ai/blog/deepseekr1-dynamic

04 June, 2025 01:02PM by etbe

Ben Hutchings

FOSS activity in May 2025

Debian packages:
- apt:
  - Bugs:
    - replied to #1078608: apt update silently leaves old index data
- cis-tools:
  - Merge requests:
    - opened and merged !1: Initial Debian packaging
- firmware-free:
  - Bugs:
    - replied to #890601: firmware-linux-free uses prebuilt blobs instead of building from source
  - Merge requests:
    - opened !10: Draft: Build CIS files and keyspan_pda firmware from source
- firmware-nonfree:
  - Bugs:
    - closed #1106282: firmware-nonfree: Update stable-bpo to testing version
  - Uploads:
    - uploaded version 20250410-2~bpo12+1 to bookworm-backports
- initramfs-tools:
  - Bugs:
    - closed #980021: initramfs-tools: Upgrading a LVM2 system with separate /usr to buster breaks booting
  - Merge requests:
- ktls-utils:
  - Uploads:
    - uploaded version 1.0.0-1 to unstable
- linux:
  - Bugs:
  - Merge requests:
    - reviewed !1461: Fix some Lintian findings
    - merged !1466: Fix various lintian errors and warnings
    - merged !1471: [arm64] udeb: Add mtk-cmdq-mailbox to kernel-image
    - merged !1488: net/ipv6: Enable IPV6_RPL_LWTUNNEL
    - opened and merged !1489: Fix sh4 build and disable broken flavour
    - opened !1502: Add linux-misc-tools package for bootconfig, ihex2fw, thermometer, and tmon
    - merged !1506: [sparc64/smp] Enable NUMA
    - reviewed !1507: Drop “yama: Disable by default” and use upstream default to restrict ptrace
    - (LTS) opened !1524: Include target Debian release number in ABI name
  - Uploads:
    - (LTS) uploaded version 5.10.237-1 to bullseye-security
- linux-6.1:
  - Uploads:
    - (LTS) uploaded version 6.1.137-1~deb11u1 to bullseye-security
- linux-base:
  - Bugs:
  - Merge requests:
    - opened !14: Add linux-run-hooks command for use by package maintainer scripts
    - opened !15: Clarify that version parameters are not package version strings
    - opened and merged !16: Manual page updates
    - opened and merged !17: linux-sysctl-defaults: Increase vm.max_map_count to 1048576
  - Uploads:
    - uploaded version 4.12 to unstable
- procps:
  - Bugs:
    - replied to #1092550: procps: Addback/Provide example of sysctl.d/*.conf like the old sysctl.conf under /usr/share/doc/
- reform-tools:
  - Bugs:
    - opened and replied to #1104639: Kernel hook installed in wrong directory / missing dependency
- wireless-regdb:
  - Uploads:
    - uploaded version 2025.02.20-1~deb12u1 to bookworm
    - (LTS) uploaded version 2025.02.20-1~deb11u1 to bullseye-security
Debian non-package bugs:
- release.debian.org:
  - replied to #1104052: bookworm-pu: package initramfs-tools/0.142+deb12u2
  - opened #1106559: unblock: linux-base/4.12
  - opened #1106788: unblock: ktls-utils/1.0.0-1
- wnpp:
  - replied to #1072579: ITP: cis-tools – CIS file tools from pcmcia-cs
  - replied to #1105145: ITP: linux-board-support-package-rb3gen2 – Firmware for RB3Gen2
  - replied to #1105839: ITP: ovpn-dkms – OpenVPN data channel offload (ovpn)
Mailing lists:
- debian-devel:
  - posted and replied to Adding Pre-Depends from linux-image packages to linux-base
- debian-events-eu:
  - replied to Debian BSP near Leuven, 26-27 April
- debian-kernel:
  - posted Agenda items for kernel-team meeting on 2025-05-21
- debian-lts:
  - replied to linux-image-6.1-* in Debian Bookworm
- debian-lts-announce:
- debian-release:
  - posted Upstream kernel maintenance lifetime for bookworm and trixie
- initramfs:
  - posted initramfs-tools 0.147 release
  - posted initramfs-tools 0.148 release

01 June, 2025 10:12PM by Ben Hutchings

Antoine Beaupré

Traffic meter per ASN without logs

Have you ever found yourself in the situation where you had no or anonymized logs and still wanted to figure out where your traffic was coming from?

Or you have multiple upstreams and are looking to see if you can save fees by getting into peering agreements with some other party?

Or your site is getting heavy load but you can't pinpoint it on a single IP and you suspect some amoral corporation is training their degenerate AI on your content with a bot army?

(You might be getting onto something there.)

If that rings a bell, read on.

TL;DR:

... or just skip the cruft and install asncounter:

pip install asncounter

Also available in Debian 14 or later, or possibly in Debian 13 backports (soon to be released) if people are interested:

apt install asncounter

Then count whoever is hitting your network with:

awk '{print $2}' /var/log/apache2/*access*.log | asncounter

or:

tail -F /var/log/apache2/*access*.log | awk '{print $2}' | asncounter

or:

tcpdump -q -n | asncounter --input-format=tcpdump --repl

or:

tcpdump -q -i eth0 -n -Q in "tcp and tcp[tcpflags] & tcp-syn != 0 and (port 80 or port 443)" | asncounter --input-format=tcpdump --repl

Read on for why this matters, and why I wrote yet another weird tool (almost) from scratch.

Background and manual work

This is a tool I've been dreaming of for a long, long time. Back in 2006, at Koumbit a colleague had setup TAS ("Traffic Accounting System", "Система учета трафика" in Russian, apparently), a collection of Perl script that would do per-IP accounting. It was pretty cool: it would count bytes per IP addresses and, from that, you could do analysis. But the project died, and it was kind of bespoke.

Fast forward twenty years, and I find myself fighting off bots at the Tor Project (the irony...), with our GitLab suffering pretty bad slowdowns (see issue tpo/tpa/team#41677 for the latest public issue, the juicier one is confidential, unfortunately).

(We did have some issues caused by overloads in CI, as we host, after all, a fork of Firefox, which is a massive repository, but the applications team did sustained, awesome work to fix issues on that side, again and again (see tpo/applications/tor-browser#43121 for the latest, and tpo/applications/tor-browser#43121 for some pretty impressive correlation work, I work with really skilled people). But those issues, I believe were fixed.)

So I had the feeling it was our turn to get hammered by the AI bots. But how do we tell? I could tell something was hammering at the costly /commit/ and (especially costly) /blame/ endpoint. So at first, I pulled out the trusted awk, sort | uniq -c | sort -n | tail pipeline I am sure others have worked out before:

awk '{print $1}' /var/log/nginx/*.log | sort | uniq -c | sort -n | tail -10

For people new to this, that pulls the first field out of web server log files, sort the list, counts the number of unique entries, and sorts that so that the most common entries (or IPs) show up first, then show the top 10.

That, other words, answers the question of "which IP address visits this web server the most?" Based on this, I found a couple of IP addresses that looked like Alibaba. I had already addressed an abuse complaint to them (tpo/tpa/team#42152) but never got a response, so I just blocked their entire network blocks, rather violently:

for cidr in 47.240.0.0/14 47.246.0.0/16 47.244.0.0/15 47.235.0.0/16 47.236.0.0/14; do 
  iptables-legacy -I INPUT -s $cidr -j REJECT
done

That made Ali Baba and his forty thieves (specifically their AL-3 network go away, but our load was still high, and I was still seeing various IPs crawling the costly endpoints. And this time, it was hard to tell who they were: you'll notice all the Alibaba IPs are inside the same 47.0.0.0/8 prefix. Although it's not a /8 itself, it's all inside the same prefix, so it's visually easy to pick it apart, especially for a brain like mine who's stared too long at logs flowing by too fast for their own mental health.

What I had then was different, and I was tired of doing the stupid thing I had been doing for decades at this point. I had recently stumbled upon pyasn recently (in January, according to my notes) and somehow found it again, and thought "I bet I could write a quick script that loops over IPs and counts IPs per ASN".

(Obviously, there are lots of other tools out there for that kind of monitoring. Argos, for example, presumably does this, but it's a kind of a huge stack. You can also get into netflows, but there's serious privacy implications with those. There are also lots of per-IP counters like promacct, but that doesn't scale.

Or maybe someone already had solved this problem and I just wasted a week of my life, who knows. Someone will let me know, I hope, either way.)

ASNs and networks

A quick aside, for people not familiar with how the internet works. People that know about ASNs, BGP announcements and so on can skip.

The internet is the network of networks. It's made of multiple networks that talk to each other. The way this works is there is a Border Gateway Protocol (BGP), a relatively simple TCP-based protocol, that the edge routers of those networks used to announce each other what network they manage. Each of those network is called an Autonomous System (AS) and has an AS number (ASN) to uniquely identify it. Just like IP addresses, ASNs are allocated by IANA and local registries, they're pretty cheap and useful if you like running your own routers, get one.

When you have an ASN, you'll use it to, say, announce to your BGP neighbors "I have 198.51.100.0/24" over here and the others might say "okay, and I have 216.90.108.31/19 over here, and I know of this other ASN over there that has 192.0.2.1/24 too! And gradually, those announcements flood the entire network, and you end up with each BGP having a routing table of the global internet, with a map of which network block, or "prefix" is announced by which ASN.

It's how the internet works, and it's a useful thing to know, because it's what, ultimately, makes an organisation responsible for an IP address. There are "looking glass" tools like the one provided by routeviews.org which allow you to effectively run "trace routes" (but not the same as traceroute, which actively sends probes from your location), type an IP address in that form to fiddle with it. You will end up with an "AS path", the way to get from the looking glass to the announced network. But I digress, and that's kind of out of scope.

Point is, internet is made of networks, networks are autonomous systems (AS) and they have numbers (ASNs), and they announced IP prefixes (or "network blocks") that ultimately tells you who is responsible for traffic on the internet.

Introducing asncounter

So my goal was to get from "lots of IP addresses" to "list of ASNs", possibly also the list of prefixes (because why not). Turns out pyasn makes that really easy. I managed to build a prototype in probably less than an hour, just look at the first version, it's 44 lines (sloccount) of Python, and it works, provided you have already downloaded the required datafiles from routeviews.org. (Obviously, the latest version is longer at close to 1000 lines, but it downloads the data files automatically, and has many more features).

The way the first prototype (and later versions too, mostly) worked is that you feed it a list of IP addresses on standard input, it looks up the ASN and prefix associated with the IP, and increments a counter for those, then print the result.

That showed me something like this:

root@gitlab-02:~/anarcat-scripts# tcpdump -q -i eth0 -n -Q in "(udp or tcp)" | ./asncounter.py --tcpdump                                                                                                                                                                          
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode                                                                
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes                                                             
INFO: collecting IPs from stdin, using datfile ipasn_20250523.1600.dat.gz                                                                
INFO: loading datfile /root/.cache/pyasn/ipasn_20250523.1600.dat.gz...                                                                   
INFO: loading /root/.cache/pyasn/asnames.json                       
ASN     count   AS               
136907  7811    HWCLOUDS-AS-AP HUAWEI CLOUDS, HK                                                                                         
[----]  359     [REDACTED]
[----]  313     [REDACTED]
8075    254     MICROSOFT-CORP-MSN-AS-BLOCK, US
[---]   164     [REDACTED]
[----]  136     [REDACTED]
24940   114     HETZNER-AS, DE  
[----]  98      [REDACTED]
14618   82      AMAZON-AES, US                                                                                                           
[----]  79      [REDACTED]
prefix  count                                         
166.108.192.0/20        1294                                                                                                             
188.239.32.0/20 1056                                          
166.108.224.0/20        970                    
111.119.192.0/20        951              
124.243.128.0/18        667                                         
94.74.80.0/20   651                                                 
111.119.224.0/20        622                                         
111.119.240.0/20        566           
111.119.208.0/20        538                                         
[REDACTED]  313

Even without ratios and a total count (which will come later), it was quite clear that Huawei was doing something big on the server. At that point, it was responsible for a quarter to half of the traffic on our GitLab server or about 5-10 queries per second.

But just looking at the logs, or per IP hit counts, it was really hard to tell. That traffic is really well distributed. If you look more closely at the output above, you'll notice I redacted a couple of entries except major providers, for privacy reasons. But you'll also notice almost nothing is redacted in the prefix list, why? Because all of those networks are Huawei! Their announcements are kind of bonkers: they have hundreds of such prefixes.

Now, clever people in the know will say "of course they do, it's an hyperscaler; just ASN14618 (AMAZON-AES) there is way more announcements, they have 1416 prefixes!" Yes, of course, but they are not generating half of my traffic (at least, not yet). But even then: this also applies to Amazon! This way of counting traffic is way more useful for large scale operations like this, because you group by organisation instead of by server or individual endpoint.

And, ultimately, this is why asncounter matters: it allows you to group your traffic by organisation, the place you can actually negotiate with.

Now, of course, that assumes those are entities you can talk with. I have written to both Alibaba and Huawei, and have yet to receive a response. I assume I never will. In their defence, I wrote in English, perhaps I should have made the effort of translating my message in Chinese, but then again English is the Lingua Franca of the Internet, and I doubt that's actually the issue.

The Huawei and Facebook blocks

Another aside, because this is my blog and I am not looking for a Pullitzer here.

So I blocked Huawei from our GitLab server (and before you tear your shirt open: only our GitLab server, everything else is still accessible to them, including our email server to respond to my complaint). I did so 24h after emailing them, and after examining their user agent (UA) headers. Boy that was fun. In a sample of 268 requests I analyzed, they churned out 246 different UAs.

At first glance, they looked legit, like:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36

Safari on a Mac, so far so good. But when you start digging, you notice some strange things, like here's Safari running on Linux:

Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.457.0 Safari/534.3

Was Safari ported to Linux? I guess that's.. possible?

But here is Safari running on a 15 year old Ubuntu release (10.10):

Mozilla/5.0 (X11; Linux i686) AppleWebKit/534.24 (KHTML, like Gecko) Ubuntu/10.10 Chromium/12.0.702.0 Chrome/12.0.702.0 Safari/534.24

Speaking of old, here's Safari again, but this time running on Windows NT 5.1, AKA Windows XP, released 2001, EOL since 2019:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-CA) AppleWebKit/534.13 (KHTML like Gecko) Chrome/9.0.597.98 Safari/534.13

Really?

Here's Firefox 3.6, released 14 years ago, there were quite a lot of those:

Mozilla/5.0 (Windows; U; Windows NT 6.1; lt; rv:1.9.2) Gecko/20100115 Firefox/3.6

I remember running those old Firefox releases, those were the days.

But to me, those look like entirely fake UAs, deliberately rotated to make it look like legitimate traffic.

In comparison, Facebook seemed a bit more legit, in the sense that they don't fake it. most hits are from:

meta-externalagent/1.1 (+https://developers.facebook.com/docs/sharing/webmasters/crawler)

which, according their documentation:

crawls the web for use cases such as training AI models or improving products by indexing content directly

From what I could tell, it was even respecting our rather liberal robots.txt rules, in that it wasn't crawling the sprawling /blame/ or /commit/ endpoints, explicitly forbidden by robots.txt.

So I've blocked the Facebook bot in robots.txt and, amazingly, it just went away. Good job Facebook, as much as I think you've given the empire to neo-nazis, cause depression and genocide, you know how to run a crawler, thanks.

Huawei was blocked at the web server level, with a friendly 429 status code telling people to contact us (over email) if they need help. And they don't care: they're still hammering the server, from what I can tell, but then again, I didn't block the entire ASN just yet, just the blocks I found crawling the server over a couple hours.

A full asncounter run

So what does a day in asncounter look like? Well, you start with a problem, say you're getting too much traffic and want to see where it's from. First you need to sample it. Typically, you'd do that with tcpdump or tailing a log file:

tail -F /var/log/apache2/*access*.log | awk '{print $2}' | asncounter

If you have lots of traffic or care about your users' privacy, you're not going to log IP addresses, so tcpdump is likely a good option instead:

tcpdump -q -n | asncounter --input-format=tcpdump --repl

If you really get a lot of traffic, you might want to get a subset of that to avoid overwhelming asncounter, it's not fast enough to do multiple gigabit/second, I bet, so here's only incoming SYN IPv4 packets:

tcpdump -q -n -Q in "tcp and tcp[tcpflags] & tcp-syn != 0 and (port 80 or port 443)" | asncounter --input-format=tcpdump --repl

In any case, at this point you're staring at a process, just sitting there. If you passed the --repl or --manhole arguments, you're lucky: you have a Python shell inside the program. Otherwise, send SIGHUP to the thing to have it dump the nice tables out:

pkill -HUP asncounter

Here's an example run:

> awk '{print $2}' /var/log/apache2/*access*.log | asncounter
INFO: using datfile ipasn_20250527.1600.dat.gz
INFO: collecting addresses from <stdin>
INFO: loading datfile /home/anarcat/.cache/pyasn/ipasn_20250527.1600.dat.gz...
INFO: finished reading data
INFO: loading /home/anarcat/.cache/pyasn/asnames.json
count   percent ASN AS
12779   69.33   66496   SAMPLE, CA
3361    18.23   None    None
366 1.99    66497   EXAMPLE, FR
337 1.83    16276   OVH, FR
321 1.74    8075    MICROSOFT-CORP-MSN-AS-BLOCK, US
309 1.68    14061   DIGITALOCEAN-ASN, US
128 0.69    16509   AMAZON-02, US
77  0.42    48090   DMZHOST, GB
56  0.3 136907  HWCLOUDS-AS-AP HUAWEI CLOUDS, HK
53  0.29    17621   CNCGROUP-SH China Unicom Shanghai network, CN
total: 18433
count   percent prefix  ASN AS
12779   69.33   192.0.2.0/24    66496   SAMPLE, CA
3361    18.23   None        
298 1.62    178.128.208.0/20    14061   DIGITALOCEAN-ASN, US
289 1.57    51.222.0.0/16   16276   OVH, FR
272 1.48    2001:DB8::/48   66497   EXAMPLE, FR
235 1.27    172.160.0.0/11  8075    MICROSOFT-CORP-MSN-AS-BLOCK, US
94  0.51    2001:DB8:1::/48 66497   EXAMPLE, FR
72  0.39    47.128.0.0/14   16509   AMAZON-02, US
69  0.37    93.123.109.0/24 48090   DMZHOST, GB
53  0.29    27.115.124.0/24 17621   CNCGROUP-SH China Unicom Shanghai network, CN

Those numbers are actually from my home network, not GitLab. Over there, the battle still rages on, but at least the vampire bots are banging their heads against the solid Nginx wall instead of eating the fragile heart of GitLab. We had a significant improvement in latency thanks to the Facebook and Huawei blocks... Here are the "workhorse request duration stats" for various time ranges, 20h after the block:

range	mean	max	stdev
20h	449ms	958ms	39ms
7d	1.78s	5m	14.9s
30d	2.08s	3.86m	8.86s
6m	901ms	27.3s	2.43s

We went from two seconds mean to 500ms! And look at that standard deviation! 39ms! It was ten seconds before! I doubt we'll keep it that way very long but for now, it feels like I won a battle, and I didn't even have to setup anubis or go-away, although I suspect that will unfortunately come.

Note that asncounter also supports exporting Prometheus metrics, but you should be careful with this, as it can lead to cardinal explosion, especially if you track by prefix (which can be disabled with--no-prefixes`.

Folks interested in more details should read the fine manual for more examples, usage, and discussion. It shows, among other things, how to effectively block lots of networks from Nginx, aggregate multiple prefixes, block entire ASNs, and more!

So there you have it: I now have the tool I wish I had 20 years ago. Hopefully it will stay useful for another 20 years, although I'm not sure we'll have still have internet in 20 years.

I welcome constructive feedback, "oh no you rewrote X", Grafana dashboards, bug reports, pull requests, and "hell yeah" comments. Hacker News, let it rip, I know you can give me another juicy quote for my blog.

This work was done as part of my paid work for the Tor Project, currently in a fundraising drive, give us money if you like what you read.

01 June, 2025 02:22PM

Guido Günther

Free Software Activities May 2025

Another short status update of what happened on my side last month. Larger blocks besides the Phosh 0.47 release are on screen keyboard and cell broadcast improvements, work on separate volume streams, the switch of phoc to wlroots 0.19.0 and effort to make Phosh work on Debian's upcoming stable release (Trixie) out of the box. Trixie will ship with Phosh 0.46, if you want to try out 0.47 you can fetch it from Debian's experimental suite.

See below for details on the above and more:

phosh

Track volume control based on media role priority (MR)
Release 0.47~rc1, 0.47.0

phoc

Release 0.47~rc1, 0.47.0
More signal unlink fixes (MR)
Further polish the wlroots 0.19 switch and undraft (MR)
Start to track wlroots 0.20 dev branch (MR)
Remember output configuration and restore scale,mode,transform for single output configs (MR)

phosh-mobile-settings

Release 0.47~rc1, 0.47.0
CI maintenance (MR, MR, MR)
New alerts panel (MR)
Handle p-o-s to stevia rename (MR)

phosh-osk-stub / stevia

Smoke test completers (MR)
Better use horizontal space in completion bar (MR)
Add emojis to completion bar (MR)
Drop separate emoji data (MR)
Add some keyword completions (MR)
Better handle lots of completions (MR)
Release 0.47~rc1, 0.47.0
Rename to Stevia (MR), (MR)
Release 0.48~alpha1 to ease the rename for distros
Some minor GTK4 preps (MR)

phosh-tour

Release 0.47.0

phosh-osk-data

Check packaging step (MR)

pfs

Release 0.0.3

xdg-desktop-portal-phosh

Release 0.47.0

phrog

Allow systemd to fail to help bootstrapping (MR)

phosh-debs

Skip noinsttest profiles (MR) - no need for these in nightly builds and helps nocheck triggering errors
Work around phrog install failure until fixed upstream (MR)
Switch from osk-stub to stevia (MR)

meta-phosh

Support automatic restart in more projects (MR)
Fix glob for meson checks (MR)

feedbackd

Expand media role MR with volume tracking (MR) - this is basically the same as the Wireplumber MR from below
vibra-pattern: Don't overwrite magnitutde when changing global level (MR)
Update fbcli manpage (MR)
Drop custom script (MR)
Add key-{pressed,released} events (MR)
Release 0.8.2

feedbackd-device-themes

Release 0.8.3
Use stronger button-pressed feedback for google,sargo (MR)

gmobile

Install tests so they can run through ginsttest-runner (MR)
Release 0.3.0, 0.3.1
Small timer cleanups (MR)
Add mcc to iso country code conversion (MR)
Fix manpage subject (MR)

GNOME calls

Fix crash on shutdown (MR)
Drop meson version check (MR)
Backport fixes for 48 (MR)

Debian

phosh: Backport patches from 0.46 stable (MR)
phosh: Upload 0.47~rc1, 0.47.0
gnome-calls: Backport outging SIP call UI fix (MR)
gmobile: Upload 0.3.0 with improved autopkg tests
phoc: Upload 0.47~rc1, 0.47.0
phosh-osk-stub: 0.47.0
release-dom-compoenent: Drop tmp branch (MR)
phosh-tour: Upload 0.47.0
phosh-mobile-settings: Upload 0.47~rc1, 0.47.0
xdg-desktop-portal-phosh: Upload 0.47.0
wlroots: Upload 0.19.0
stevia: Upload 0.48~alpha1
meta-phosh: phosh-full: Depend on xwayland (MR)
feedbackd-device-themes: Upload 0.8.3
feedbackd: Upload 0.8.2
feedbackd-device-themes: Backport key-press fix for google,sargo (MR)

ModemManager

Simplify builds that need updated libqmi/libmbim (MR)
CellBroadcast: Fix QMI channel reading corner cases (MR)
Fix crash in CBM code (caused by unrelated bind-to refactor) (MR)
Handle more data codings and expose CBM's language (MR)

osmo-cbc

api-tool: Allow to set language of cell broadcast message (MR)

gsm-cell-testing

Update docs to use our new MM subproject builds (MR)

mobile-broadband-provider-info

Allow emergency number information (MR)
Allow Cell Broadcast information (MR)
Add .dir-locales.el and make tests easier to parse (MR)

Cellbroadcastd

Add channel handling (MR)
Indicate on DBus whether Cell Broadcasts are supported (MR)
Add ASAN check and fix fallout (MR)

phosh-site

Add a support feature matrix (MR)
New post: OSK completion and correction

pipewire

Simplify header use for projects that use -Wswitch-default (MR)

wireplumber

Add lua script to track suitable volume control when role based policy linking is in use (MR)

python-dbusmock

ModemManager: Add set-channel support (MR)

Bugs

Standardize audio stream roles (MR). Otherwise we'll have a hard time with e.g. WirePlumbers role based policy linking as apps might use all kinds of types.

Reviews

This is not code by me but reviews on other peoples code. The list is (as usual) slightly incomplete. Thanks for the contributions!

gmobile/pp: Ignore buttons on headsets (MR)
p-o-s: Add Arabic translation (MR)
p-o-s: pipe completer examples (MR)
p-o-s: US Dvorak layout (MR)
p-m-s: Use static library for building (MR)
p-m-s: pmos tweaks UI parts (MR)
p-m-s: Notification categories that light up the screen (MR)
gmobile: Border radius for oneplus,enchilada (MR)
m-b-p-i: Telia IOT provider (MR)
phosh-site: Highlight selected footnote (MR)
bluez: Don't start mpris proxy for root user (Patch)
phoc: shortcuts-inhibit: Add support for the keyboard shortcuts inhibit protocol (MR)

Help Development

If you want to support my work see donations.

Comments?

Join the Fediverse thread

01 June, 2025 02:19PM

Junichi Uekawa

June that is.

01 June, 2025 01:14PM by Junichi Uekawa

Paul Wise

FLOSS Activities May 2025

Focus

This month I didn't have any particular focus. I just worked on issues in my info bubble.

Changes

ArchiveBot: link pending page
Debian wiki pages: Hardware/Wanted

Issues

Crash/privacy/security issue in liferea
Usability in glab

Sponsors

All work was done on a volunteer basis.

31 May, 2025 10:11PM

Russell Coker

Links May 2025

Christopher Biggs gave an informative Evrything Open lecture about voice recognition [1]. We need this on Debian phones.

Guido wrote an informative blog post about booting a custom Android kernel on a Pixel 3a [2]. Good work in writing this up, but a pity that Google made the process so difficult.

Interesting to read about an expert being a victim of a phishing attack [3]. It can happen to anyone, everyone has moments when they aren’t concentrating.

Interesting advice on how to leak to a journalist [4].

Brian Krebs wrote an informative article about the ways that Trump is deliberately reducing the cyber security of the US government [5].

Brian Krebs wrote an interesting article about the main smishng groups from China [6].

Louis Rossmann (who is known for high quality YouTube videos about computer repair) made an informative video about a scammy Australian company run by a child sex offender [7].

The Helmover was one of the wildest engineering projects of WW2, an over the horizon guided torpedo that could one-shot a battleship [8].

Interesting blog post about DDoSecrets and the utter failure of the company Telemessages which was used by the US government [9].

Jonathan McDowell wrote an interesting blog post about developing a free software competitor to Alexa etc, the listening hardware costs $13US per node [10].

Noema Magazine published an insightful article about Rewilding the Internet, it has some great ideas [11].

31 May, 2025 01:37PM by etbe

Service Setup Difficulties

Marco wrote a blog post opposing hyperscale systems which included “We want to use an hyperscaler cloud because our developers do not want to operate a scalable and redundant database just means that you need to hire competent developers and/or system administrators.” [1].

I previously wrote a blog post Why Clusters Usually Don’t Work [2] and I believe that all the points there are valid today – and possibly exacerbated by clusters getting less direct use as clustering is increasingly being done by hyperscale providers.

Take a basic need, a MySQL or PostgreSQL database for example. You want it to run and basically do the job and to have good recovery options. You could set it up locally, run backups, test the backups, have a recovery plan for failures, maybe have a hot-spare server if it’s really important, have tests for backups and hot-spare server, etc. Then you could have documentation for this so if the person who set it up isn’t available when there’s a problem they will be able to find out what to do. But the hyperscale option is to just select a database in your provider and have all this just work. If the person who set it up isn’t available for recovery in the event of failure the company can just put out a job advert for “person with experience on cloud company X” and have them just immediately go to work on it.

I don’t like hyperscale providers as they are all monopolistic companies that do anti-competitive actions. Google should be broken up, Android development and the Play Store should be separated from Gmail etc which should be separated from search and adverts, and all of them should be separated from the GCP cloud service. Amazon should be broken up, running the Amazon store should be separated from selling items on the store, which should be separated from running a video on demand platform, and all of them should be separated from the AWS cloud. Microsoft should be broken up, OS development should be separated from application development all of that should be separated from cloud services (Teams and Office 365), and everything else should be separate from the Azure cloud system.

But the cloud providers offer real benefits at small scale. Running a MySQL or PostgreSQL database for local services is easy, it’s a simple apt command to install it and then it basically works. Doing backup and recovery isn’t so easy. One could say “just hire competent people” but if you do hire competent people do you want them running MySQL databases etc or have them just click on the “create mysql database” option on a cloud control panel and then move on to more important things?

The FreedomBox project is a great project for installing and managing home/personal services [3]. But it’s not about running things like database servers, it’s for a high level running mail servers and other things for the user not for the developer.

The Debian packaging of Open Stack looks interesting [4], it’s a complete setup for running your own hyper scale cloud service. For medium and large organisations running Open Stack could be a good approach. But for small organisations it’s cheaper and easier to just use a cloud service to run things.

The issue of when to run things in-house and when to put them in the cloud is very complex. I think that if the organisation is going to spend less money on cloud services than on the salary of one sysadmin then it’s probably best to have things in the cloud. When cloud costs start to exceed the salary of one person who manages systems then having them spend the extra time and effort to run things locally starts making more sense. There is also an opportunity cost in having a good sysadmin work on the backups for all the different systems instead of letting the cloud provider just do it. Another possibility of course is to run things in-house on low end hardware and just deal with the occasional downtime to save money. Knowingly choosing less reliability to save money can be quite reasonable as long as you have considered the options and all the responsible people are involved in the discussion.

The one situation that I strongly oppose is having hyper scale services setup by people who don’t understand them. Running a database server on a cloud service because you don’t want to spend the time managing it is a reasonable choice in many situations. Running a database server on a cloud service because you don’t understand how to setup a database server is never a good choice. While the cloud services are quite resilient there are still ways of breaking the overall system if you don’t understand it. Also while it is quite possible for someone to know how to develop for databases including avoiding SQL injection etc but be unable to setup a database server that’s probably not going to be common, probably if someone can’t set it up (a generally easy task) then they can’t do the hard tasks of making it secure.

30 May, 2025 07:32AM by etbe

Machine Learning Security

I just read an interesting blog post about ML security recommended by Bruce Schneier [1].

This approach of having 2 AI systems where one processes user input and the second performs actions on quarantined data is good and solves some real problems. But I think the bigger issue is the need to do this. Why not have a multi stage approach, instead of a single user input to do everything (the example given is “Can you send Bob the document he requested in our last meeting? Bob’s email and the document he asked for are in the meeting notes file”) you could have “get Bob’s email address from the meeting notes file” followed by “create a new email to that address” and “find the document” etc.

A major problem with many plans for ML systems is that they are based around automating relatively simple tasks. The example of sending an email based on meeting notes is a trivial task that’s done many times a day but for which expressing it verbally isn’t much faster than doing it the usual way. The usual way of doing such things (manually finding the email address from the meeting notes etc) can be accelerated without ML by having a “recent documents” access method that gets the notes, having the email address be a hot link to the email program (IE wordprocessor or note taking program being able to call the MUA), having a “put all data objects of type X into the clipboard (where X can be email address, URL, filename, or whatever), and maybe optimising the MUA UI. The problems that people are talking about solving via ML and treating everything as text to be arbitrarily parsed can in many cases by solved by having the programs dealing with the data know what they have and have support for calling system services accordingly.

The blog post suggests a problem of “user fatigue” from asking the user to confirm all actions, that is a real concern if the system is going to automate everything such that the user gives a verbal description of the problem and then says “yes” many times to confirm it. But if the user is at every step of the way pushing the process “take this email address” “attach this file” it won’t be a series of “yes” operations with a risk of saying “yes” once too often.

I think that one thing that should be investigated is better integration between services to allow working live on data. If in an online meeting someone says “I’ll work on task A please send me an email at the end of the meeting with all issues related to it” then you should be able to click on their email address in the meeting software to bring up the MUA to send a message and then just paste stuff in. The user could then not immediately send the message and clicking on the email address again would bring up the message in progress to allow adding to it (the behaviour of most MUAs of creating a new message for every click on a mailto:// URL is usually not what you desire). In this example you could of course use ALT-TAB or other methods to switch windows to the email, but imagine the situation of having 5 people in the meeting who are to be emailed about different things and that wouldn’t scale.

Another thing for the meeting example is that having a text chat for a video conference is a standard feature now and being able to directly message individuals is available in BBB and probably some other online meeting systems. It shouldn’t be hard to add a feature to BBB and similar programs to have each user receive an email at the end of the meeting with the contents of every DM chat they were involved in and have everyone in the meeting receive an emailed transcript of the public chat.

In conclusion I think that there are real issues with ML security and something like this technology is needed. But for most cases the best option is to just not have ML systems do such things. Also there is significant scope for improving the integration of various existing systems in a non-ML way.

[1] https://simonwillison.net/2025/Apr/11/camel/

30 May, 2025 06:04AM by etbe

Dirk Eddelbuettel

#48: r2u Talk Re-Recorded

Welcome to post 48 in the R⁴ series, and to video 8 in this series.

Last week I had the honour of giving the opening talk at the 11eme Rencontres R at the Université de Mons in Belgium as an invited plenary talk. Big thanks again to Philippe Grosjean and Kathy Huet for the invitation, and for organising a lovely conference.

Being the opening talk, we were still sorting out projector issues when I started so I forgot to set a timer, and consequently ran out of time like a newbie. It occured to me that I could simply re-record the talk in front of my slides just as I do for my STAT 447 students. So I sat down this morning and did this, and the video is now online:

The slides are available as well.

For questions or other feedback, please consider using the r2u GitHub repo issues section.

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

29 May, 2025 08:38PM

RcppDate 0.0.6: New Upstream

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

This release syncs with upstream release 3.0.4 made yesterday which contains a few PRs (including one by us) for the clang++-20 changes some of which we already had in release 0.0.5. We also made a routine update to the continuous integration.

Changes in version 0.0.6 (2025-05-29)

Updated to upstream version 3.0.4

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

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

29 May, 2025 06:52PM

Debian XMPP Team

XMPP/Jabber Debian 13 Trixie News

Debian 13 "Trixie" full freeze has started 2025-05-17, so this is a good time to take a look at some of the features, that this release will bring. Here we will focus on packages related to XMPP, a.k.a. Jabber.

XMPP is a universal communication protocol for instant messaging, push notifications, IoT, WebRTC, and social applications. It has existed since 1999, originally called "Jabber", it has a diverse and active developers community.

Clients

Dino, a modern XMPP client has been upgraded from 0.4.2 to 0.5.0
Dino now uses OMEMO encryption by default. It also supports XEP-0447: Stateless File Sharing for unencrypted file transfers. Users can now see preview images or other file details before downloading the file. Multiple widgets are redesigned to be compatible with mobile devices, e.g. running Mobian.
Gajim, a GTK+-based Jabber client has been upgraded from 1.7.3 to 2.1.1
There are many new features in Gajim, e.g. XEP-0444: Message Reactions, XEP-0461: Message Replies, XEP-0425: Moderated Message Retraction, XEP-0490: Message Displayed Synchronization, voice message recording, migration to GTK 4, and a lot of UI changes.
go-sendxmpp, a CLI tool to send messages to contacts or MUCs: 0.5.6 → 0.14.1
New features are support for sending XEP-0066: Out of Band Data and support for several modern authentication features (XEP-0388: Extensible SASL Profile, XEP-0386: Bind 2, XEP-0484: Fast Authentication Streamlining Tokens). New support of modern SCRAM mechanisms (SCRAM-SHA-1(-PLUS), SCRAM-SHA-256(-PLUS), SCRAM-SHA-515(-PLUS)) and SASL SCRAM Downgrade Protection (XEP-0474: SASL SCRAM Downgrade Protection) improve the security of the login process. Also a lot of bugfixes and smaller improvements found their way to the new version, for details see the changelog.
Kaidan, a simple and user-friendly Jabber/XMPP client is upgraded from 0.8.0 to 0.12.2
Kaidan supports end-to-end encryption via OMEMO 2, Automatic Trust Management and XMPP Providers. It has been migrated to QT 6 and many features have been added: XEP-0444: Message Reactions, XEP-0461: Message Replies, chat pinning, inline audio player, chat list filtering, local message removal, etc.
Libervia is upgraded from 0.9.0~hg3993 to 0.9.0~hg4352
Among other features, it now also contains a gateway to ActivityPub, e.g. to Mastodon.
Poezio, a console based XMPP client as been updated from 0.14 to 0.15.0
Better self-ping support. Use the system CA store by default.
Profanity, a console based XMPP client has been upgraded from 0.13.1 to 0.15.0.
Add support for XEP-0054: vcard-temp, Improve MAM support, show encryption for messages from history and handle alt+enter as newline char.
Psi+, a QT based XMPP client (basic version) has been upgraded from 1.4.554 to 1.4.1456
xmpp-dns, a CLI tool to check XMPP SRV records: 0.3.4 → 0.4.5
It now supports showing connection targets defined by XEP-0156: Discovering Alternative XMPP Connection Methods/XEP-0487: Host Meta 2 - One Method To Rule Them All and testing of XEP-0206: XMPP Over BOSH and Websocket connections. A detailed list of changes can be found in the changelog.

Servers

ejabberd, an extensible realtime platform (XMPP server, MQTT broker, SIP service) has been updated from Version 23.01 to 24.12
Add support for XEP-0425: Moderated Message Retraction, XEP-0402: PEP Native Bookmarks, and XEP-0424 Message Retraction.
Prosŏdy, a lightweight extensible XMPP server has been upgraded from 0.12.3 to 13.0.1
Admins can disable and enable accounts as needed. A new role and permissions framework. Storage and performance improvements.

Libraries

libomemo-c 0.5.0 to 0.5.1
libstrophe, an XMPP library in C has been upgraded from 0.12.2 to 0.14.0
It now supports XEP-0138: Stream Compression and adds various modern SCRAM mechanisms.
omemo-dr, an OMEMO library used by Gajim is now in Debian, in version 1.0.1
python-nbxmpp, a non blocking Jabber/XMPP Python 3 library, upgrade from 4.2.2 to 6.1.1
python-oldmemo, a python-omemo backend for OMEMO 1, 1.0.3 to 1.1.0
python-omemo, a Python 3 implementation of the OMEMO protocol, 1.0.2 to 1.2.0
python-twomemo, a python-omemo backend for OMEMO 2, 1.0.3 to 1.1.0
qxmpp 1.4.0 to 1.10.3
slixmpp-omemo new 1.2.2
slixmpp 1.8.3 to 1.10.0
strophejs, a library for writing XMPP clients has been upgraded from 1.2.14 to 3.1.0

Gateways/Transports

Biboumi, a gateway between XMPP and IRC, upgrades from 9.0 to 9.0+20241124.
Debian 13 Trixie includes Slidge 0.2.12 and Matridge 0.2.3 for the first time! It is a gateway between XMPP and Matrix, with support for many chat features.

Not in Trixie

Spectrum 2, a gateway from XMPP to various other messaging systems, did not make it into Debian 13, because it depends on Swift, which has release critical bugs and therefore cannot be part of a stable release.

29 May, 2025 12:00AM by Debian XMPP Team

Arthur Diniz

Bringing Kubernetes Back to Debian

I’ve been part of the Debian Project since 2019, when I attended DebConf held in Curitiba, Brazil. That event sparked my interest in the community, packaging, and how Debian works as a distribution.

In the early years of my involvement, I contributed to various teams such as the Python, Golang and Cloud teams, packaging dependencies and maintaining various tools. However, I soon felt the need to focus on packaging software I truly enjoyed, tools I was passionate about using and maintaining.

That’s when I turned my attention to Kubernetes within Debian.

A Broken Ecosystem

The Kubernetes packaging situation in Debian had been problematic for some time. Given its large codebase and complex dependency tree, the initial packaging approach involved vendorizing all dependencies. While this allowed a somewhat functional package to be published, it introduced several long-term issues, especially security concerns.

Vendorized packages bundle third-party dependencies directly into the source tarball. When vulnerabilities arise in those dependencies, it becomes difficult for Debian’s security team to patch and rebuild affected packages system-wide. This approach broke Debian’s best practices, and it eventually led to the abandonment of the Kubernetes source package, which had stalled at version 1.20.5.

Due to this abandonment, critical bugs emerged and the package was removed from Debian’s testing channel, as we can see in the package tracker.

New Debian Kubernetes Team

Around this time, I became a Debian Maintainer (DM), with permissions to upload certain packages. I saw an opportunity to both contribute more deeply to Debian and to fix Kubernetes packaging.

In early 2024, just before DebConf Busan in South Korea, I founded the Debian Kubernetes Team. The mission of the team was to repackage Kubernetes in a maintainable, security-conscious, and Debian-compliant way. At DebConf, I shared our progress with the broader community and received great feedback and more visibility, along with people interested in contributing to the team.

Our first tasks was to migrate existing Kubernetes-related tools such as kubectx, kubernetes-split-yaml and kubetail into a dedicated namespace on Salsa, Debian’s GitLab instance.

Many of these tools were stored across different teams (like the Go team), and consolidating them helped us organize development and focus our efforts.

De-vendorizing Kubernetes

Our main goal was to un-vendorize Kubernetes and bring it up-to-date with upstream releases.

This meant:

Removing the vendor directory and all embedded third-party code.
Trimming the build scope to focus solely on building kubectl, Kubernetes’ CLI.
Using Files-Excluded in debian/copyright to cleanly drop unneeded files during source imports.
Rebuilding the dependency tree, ensuring all Go modules were separately packaged in Debian.

We used uscan, a standard Debian packaging tool that fetches upstream tarballs and prepares them accordingly. The Files-Excluded directive in our debian/copyright file instructed uscan to automatically remove unnecessary files during the repackaging process:

$ uscan
Newest version of kubernetes on remote site is 1.32.3, specified download version is 1.32.3
Successfully repacked ../v1.32.3 as ../kubernetes_1.32.3+ds.orig.tar.gz, deleting 30616 files from it.

The results were dramatic. By comparing the original upstream tarball with our repackaged version, we can see that our approach reduced the tarball size by over 75%:

$ du -h upstream-v1.32.3.tar.gz kubernetes_1.32.3+ds.orig.tar.gz
14M	upstream-v1.32.3.tar.gz
3.2M	kubernetes_1.32.3+ds.orig.tar.gz

This significant reduction wasn’t just about saving space. By removing over 30,000 files, we simplified the package, making it more maintainable. Each dependency could now be properly tracked, updated, and patched independently, resolving the security concerns that had plagued the previous packaging approach.

Dependency Graph

To give you an idea of the complexity involved in packaging Kubernetes for Debian, the image below is a dependency graph generated with debtree, visualizing all the Go modules and other dependencies required to build the kubectl binary.

kubectl-depgraph

This web of nodes and edges represents every module and its relationship during the compilation process of kubectl. Each box is a Debian package, and the lines connecting them show how deeply intertwined the ecosystem is. What might look like a mess of blue spaghetti is actually a clear demonstration of the vast and interconnected upstream world that tools like kubectl rely on.

But more importantly, this graph is a testament to the effort that went into making kubectl build entirely using Debian-packaged dependencies only, no vendoring, no downloading from the internet, no proprietary blobs.

Upstream Version 1.32.3 and Beyond

After nearly two years of work, we successfully uploaded version 1.32.3+ds of kubectl to Debian unstable.

kubernetes/-/merge_requests/1

Closed over a dozen long-standing bugs, including:
- Outdated version requests
- Missing shell completions
- VCS (version control system) metadata issues
- (#1055411, #990793, #1009356, #1016441, #1086756, #1047881, #832706, #976428, #994438)

The new package also includes:

Zsh, Fish, and Bash completions installed automatically
Man pages and metadata for improved discoverability
Full integration with kind and docker for testing purposes

Integration Testing with Autopkgtest

To ensure the reliability of kubectl in real-world scenarios, we developed a new autopkgtest suite that runs integration tests using real Kubernetes clusters created via Kind.

Autopkgtest is a Debian tool used to run automated tests on binary packages. These tests are executed after the package is built but before it’s accepted into the Debian archive, helping catch regressions and integration issues early in the packaging pipeline.

Our test workflow validates kubectl by performing the following steps:

Installing Kind and Docker as test dependencies.
Spinning up two local Kubernetes clusters.
Switching between cluster contexts to ensure multi-cluster support.
Deploying and scaling a sample nginx application using kubectl.
Cleaning up the entire test environment to avoid side effects.
debian/tests/kubectl.sh

Popcon: Measuring Adoption

To measure real-world usage, we rely on data from Debian’s popularity contest (popcon), which gives insight into how many users have each binary installed.

popcon-graph popcon-table

Here’s what the data tells us:

kubectl (new binary): Already installed on 2,124 systems.
golang-k8s-kubectl-dev: This is the Go development package (a library), useful for other packages and developers who want to interact with Kubernetes programmatically.
kubernetes-client: The legacy package that kubectl is replacing. We expect this number to decrease in future releases as more systems transition to the new package.

Although the popcon data shows activity for kubectl before the official Debian upload date, it’s important to note that those numbers represent users who had it installed from upstream source-lists, not from the Debian repositories. This distinction underscores a demand that existed even before the package was available in Debian proper, and it validates the importance of bringing it into the archive.

Also worth mentioning: this number is not the real total number of installations, since users can choose not to participate in the popularity contest. So the actual adoption is likely higher than what popcon reflects.

Community and Documentation

The team also maintains a dedicated wiki page which documents:

Maintained tools and packages
Contribution guidelines
Our roadmap for the upcoming Debian releases

https://debian-kubernetes.org

Looking Ahead to Debian 13 (Trixie)

The next stable release of Debian will ship with kubectl version 1.32.3, built from a clean, de-vendorized source. This version includes nearly all the latest upstream features, and will be the first time in years that Debian users can rely on an up-to-date, policy-compliant kubectl directly from the archive.

By comparing with upstream, our Debian package even delivers more out of the box, including shell completions, which the upstream still requires users to generate manually.

In 2025, the Debian Kubernetes team will continue expanding our packaging efforts for the Kubernetes ecosystem.

Our roadmap includes:

kubelet: The primary node agent that runs on each node. This will enable Debian users to create fully functional Kubernetes nodes without relying on external packages.
kubeadm: A tool for creating Kubernetes clusters. With kubeadm in Debian, users will then be able to bootstrap minimum viable clusters directly from the official repositories.
helm: The package manager for Kubernetes that helps manage applications through Kubernetes YAML files defined as charts.
kompose: A conversion tool that helps users familiar with docker-compose move to Kubernetes by translating Docker Compose files into Kubernetes resources.

Final Thoughts

This journey was only possible thanks to the amazing support of the debian-devel-br community and the collective effort of contributors who stepped up to package missing dependencies, fix bugs, and test new versions.

Special thanks to:

Carlos Henrique Melara (@charles)
Guilherme Puida (@puida)
João Pedro Nobrega (@jnpf)
Lucas Kanashiro (@kanashiro)
Matheus Polkorny (@polkorny)
Samuel Henrique (@samueloph)
Sergio Cipriano (@cipriano)
Sergio Durigan Junior (@sergiodj)

I look forward to continuing this work, bringing more Kubernetes tools into Debian and improving the developer experience for everyone.

29 May, 2025 12:00AM

Bringing Kubernetes Back to Debian

I’ve been part of the Debian Project since 2019, when I attended DebConf held in Curitiba, Brazil. That event sparked my interest in the community, packaging, and how Debian works as a distribution.

In the early years of my involvement, I contributed to various teams such as the Python, Golang and Cloud teams, packaging dependencies and maintaining various tools. However, I soon felt the need to focus on packaging software I truly enjoyed, tools I was passionate about using and maintaining.

That’s when I turned my attention to Kubernetes within Debian.

A Broken Ecosystem

The Kubernetes packaging situation in Debian had been problematic for some time. Given its large codebase and complex dependency tree, the initial packaging approach involved vendorizing all dependencies. While this allowed a somewhat functional package to be published, it introduced several long-term issues, especially security concerns.

Vendorized packages bundle third-party dependencies directly into the source tarball. When vulnerabilities arise in those dependencies, it becomes difficult for Debian’s security team to patch and rebuild affected packages system-wide. This approach broke Debian’s best practices, and it eventually led to the abandonment of the Kubernetes source package, which had stalled at version 1.20.5.

Due to this abandonment, critical bugs emerged and the package was removed from Debian’s testing channel, as we can see in the package tracker.

New Debian Kubernetes Team

Around this time, I became a Debian Maintainer (DM), with permissions to upload certain packages. I saw an opportunity to both contribute more deeply to Debian and to fix Kubernetes packaging.

In early 2024, just before DebConf Busan in South Korea, I founded the Debian Kubernetes Team. The mission of the team was to repackage Kubernetes in a maintainable, security-conscious, and Debian-compliant way. At DebConf, I shared our progress with the broader community and received great feedback and more visibility, along with people interested in contributing to the team.

Our first tasks was to migrate existing Kubernetes-related tools such as kubectx, kubernetes-split-yaml and kubetail into a dedicated namespace on Salsa, Debian’s GitLab instance.

Many of these tools were stored across different teams (like the Go team), and consolidating them helped us organize development and focus our efforts.

De-vendorizing Kubernetes

Our main goal was to un-vendorize Kubernetes and bring it up-to-date with upstream releases.

This meant:

Removing the vendor directory and all embedded third-party code.
Trimming the build scope to focus solely on building kubectl, Kubernetes’ CLI.
Using Files-Excluded in debian/copyright to cleanly drop unneeded files during source imports.
Rebuilding the dependency tree, ensuring all Go modules were separately packaged in Debian.

We used uscan, a standard Debian packaging tool that fetches upstream tarballs and prepares them accordingly. The Files-Excluded directive in our debian/copyright file instructed uscan to automatically remove unnecessary files during the repackaging process:

$ uscan
Newest version of kubernetes on remote site is 1.32.3, specified download version is 1.32.3
Successfully repacked ../v1.32.3 as ../kubernetes_1.32.3+ds.orig.tar.gz, deleting 30616 files from it.

The results were dramatic. By comparing the original upstream tarball with our repackaged version, we can see that our approach reduced the tarball size by over 75%:

$ du -h upstream-v1.32.3.tar.gz kubernetes_1.32.3+ds.orig.tar.gz
14M	upstream-v1.32.3.tar.gz
3.2M	kubernetes_1.32.3+ds.orig.tar.gz

This significant reduction wasn’t just about saving space. By removing over 30,000 files, we simplified the package, making it more maintainable. Each dependency could now be properly tracked, updated, and patched independently, resolving the security concerns that had plagued the previous packaging approach.

Dependency Graph

To give you an idea of the complexity involved in packaging Kubernetes for Debian, the image below is a dependency graph generated with debtree, visualizing all the Go modules and other dependencies required to build the kubectl binary.

kubectl-depgraph

This web of nodes and edges represents every module and its relationship during the compilation process of kubectl. Each box is a Debian package, and the lines connecting them show how deeply intertwined the ecosystem is. What might look like a mess of blue spaghetti is actually a clear demonstration of the vast and interconnected upstream world that tools like kubectl rely on.

But more importantly, this graph is a testament to the effort that went into making kubectl build entirely using Debian-packaged dependencies only, no vendoring, no downloading from the internet, no proprietary blobs.

Upstream Version 1.32.3 and Beyond

After nearly two years of work, we successfully uploaded version 1.32.3+ds of kubectl to Debian unstable.

kubernetes/-/merge_requests/1

Closed over a dozen long-standing bugs, including:
- Outdated version requests
- Missing shell completions
- VCS (version control system) metadata issues
- (#1055411, #990793, #1009356, #1016441, #1086756, #1047881, #832706, #976428, #994438)

The new package also includes:

Zsh, Fish, and Bash completions installed automatically
Man pages and metadata for improved discoverability
Full integration with kind and docker for testing purposes

Integration Testing with Autopkgtest

To ensure the reliability of kubectl in real-world scenarios, we developed a new autopkgtest suite that runs integration tests using real Kubernetes clusters created via Kind.

Autopkgtest is a Debian tool used to run automated tests on binary packages. These tests are executed after the package is built but before it’s accepted into the Debian archive, helping catch regressions and integration issues early in the packaging pipeline.

Our test workflow validates kubectl by performing the following steps:

Installing Kind and Docker as test dependencies.
Spinning up two local Kubernetes clusters.
Switching between cluster contexts to ensure multi-cluster support.
Deploying and scaling a sample nginx application using kubectl.
Cleaning up the entire test environment to avoid side effects.
debian/tests/kubectl.sh

Popcon: Measuring Adoption

To measure real-world usage, we rely on data from Debian’s popularity contest (popcon), which gives insight into how many users have each binary installed.

popcon-graph popcon-table

Here’s what the data tells us:

kubectl (new binary): Already installed on 2,124 systems.
golang-k8s-kubectl-dev: This is the Go development package (a library), useful for other packages and developers who want to interact with Kubernetes programmatically.
kubernetes-client: The legacy package that kubectl is replacing. We expect this number to decrease in future releases as more systems transition to the new package.

Although the popcon data shows activity for kubectl before the official Debian upload date, it’s important to note that those numbers represent users who had it installed from upstream source-lists, not from the Debian repositories. This distinction underscores a demand that existed even before the package was available in Debian proper, and it validates the importance of bringing it into the archive.

Also worth mentioning: this number is not the real total number of installations, since users can choose not to participate in the popularity contest. So the actual adoption is likely higher than what popcon reflects.

Community and Documentation

The team also maintains a dedicated wiki page which documents:

Maintained tools and packages
Contribution guidelines
Our roadmap for the upcoming Debian releases

https://debian-kubernetes.org

Looking Ahead to Debian 13 (Trixie)

The next stable release of Debian will ship with kubectl version 1.32.3, built from a clean, de-vendorized source. This version includes nearly all the latest upstream features, and will be the first time in years that Debian users can rely on an up-to-date, policy-compliant kubectl directly from the archive.

By comparing with upstream, our Debian package even delivers more out of the box, including shell completions, which the upstream still requires users to generate manually.

In 2025, the Debian Kubernetes team will continue expanding our packaging efforts for the Kubernetes ecosystem.

Our roadmap includes:

kubelet: The primary node agent that runs on each node. This will enable Debian users to create fully functional Kubernetes nodes without relying on external packages.
kubeadm: A tool for creating Kubernetes clusters. With kubeadm in Debian, users will then be able to bootstrap minimum viable clusters directly from the official repositories.
helm: The package manager for Kubernetes that helps manage applications through Kubernetes YAML files defined as charts.
kompose: A conversion tool that helps users familiar with docker-compose move to Kubernetes by translating Docker Compose files into Kubernetes resources.

Final Thoughts

This journey was only possible thanks to the amazing support of the debian-devel-br community and the collective effort of contributors who stepped up to package missing dependencies, fix bugs, and test new versions.

Special thanks to:

Carlos Henrique Melara (@charles)
Guilherme Puida (@puida)
João Pedro Nobrega (@jnpf)
Lucas Kanashiro (@kanashiro)
Matheus Polkorny (@polkorny)
Samuel Henrique (@samueloph)
Sergio Cipriano (@cipriano)
Sergio Durigan Junior (@sergiodj)

I look forward to continuing this work, bringing more Kubernetes tools into Debian and improving the developer experience for everyone.

29 May, 2025 12:00AM

Clint Adams

Potted meat is viewed differently by different cultures

I've been working on a multi-label email classification model. It's been a frustrating slog, fraught with challenges, including a lack of training data. Labeling emails is labor-intensive and error-prone. Also, I habitually delete certain classes of email immediately after its usefulness has been reduced. I use a CRM-114-based spam filtering system (actually I use two different isntances of the same mailreaver config, but that's another story), which is differently frustrating, but I delete spam when it's detected or when it's trained. Fortunately, there's no shortage of incoming spam, so I can collect enough, but for other, arguably more important labels, they arrive infrequently. So, those labels need to be excluded, or the small sample sizes wreck the training feedback loop. Currently, I have ten active labels, and even though the point of this is not to be a spam filter, “spam” is one of the labels.

Out of curiosity, I decided to compare the performance of my three different models, and to do so on a neutral corpus (in other words, emails that none of them had ever been trained on). I grabbed the full TREC 2007 corpus and ran inference. The results were unexpected in many ways. For example, the Pearson correlation coefficient between my older CRM-114 model and my newer CRM-114 was only about 0.78.

I was even more surprised by how poorly all three performed. Were they overfit to my email? So, I decided to look at the TREC corpus for the first time, and lo and behold, the first spam-labeled email I checked was something I would definitely train all three models with as non-spam, but ham for CRM-114 and an entirely different label for my experimental model.

Posted on 2025-05-28

Tags: ranticore

28 May, 2025 06:32PM

Jonathan Dowland

Linux Mount Namespaces

I've been refreshing myself on the low-level guts of Linux container technology. Here's some notes on mount namespaces.

In the below examples, I will use more than one root shell simultaneously. To disambiguate them, the examples will feature a numbered shell prompt: 1# for the first shell, and 2# for the second.

Preliminaries

Namespaces are normally associated with processes and are removed when the last associated process terminates. To make them persistent, you have to bind-mount the corresponding virtual file from an associated processes's entry in /proc, to another path¹.

The receiving path needs to have its "propogation" property set to "private". Most likely your system's existing mounts are mostly "public". You can check the propogation setting for mounts with

1# findmnt -o+PROPAGATION

We'll create a new directory to hold mount namespaces we create, and set its Propagation to private, via a bind-mount of itself to itself.

1# mkdir /root/mntns
1# mount --bind --make-private /root/mntns /root/mntns

The namespace itself needs to be bind-mounted over a file rather than a directory, so we'll create one.

1# touch /root/mntns/1

Creating and persisting a new mount namespace

1# unshare --mount=/root/mntns/1

We are now 'inside' the new namespace in a new shell process. We'll change the shell prompt to make this clearer

PS1='inside# '

We can make a filesystem change, such as mounting a tmpfs

inside# mount -t tmpfs /mnt /mnt
inside# touch /mnt/hi-there

And observe it is not visible outside that namespace

2# findmnt /mnt
2# stat /mnt/hi-there
stat: cannot statx '/mnt/hi-there': No such file or directory

Back to the namespace shell, we can find an integer identifier for the namespace via the shell processes /proc entry:

inside# readlink /proc/$$/ns/mnt

It will be something like mnt:[4026533646]. From another shell, we can list namespaces and see that it exists:

2# lsns -t mnt
        NS TYPE NPROCS   PID USER             COMMAND
…
4026533646 mnt       1 52525 root             -bash

If we exit the shell that unshare created,

inside# exit

running lsns again should² still list the namespace, albeit with the NPROCS column now reading 0.

2# lsns -t mnt

We can see that a virtual filesystem of type nsfs is mounted at the path we selected when we ran unshare:

2# grep /root/mntns/1 /proc/mounts 
nsfs /root/mntns/1 nsfs rw 0 0

Entering the namespace from another process

This is relatively easy:

1# nsenter --mount=/root/mntns/1
1# stat /mnt/hi-there
  File: /mnt/hi-there
…

References

These were particularly useful in figuring this out:

This feels really weird to me. At least at first. I suppose it fits with the "everything is a file" philosophy.↩
I've found lsns in util-linux 2.38.1 (from 2022-08-04) doesn't list mount namespaces with no associated processes; but 2.41 (from 2025-03-18) does. The fix landed in 2022-11-08. For extra fun, I notice that a namespace can be held persistent with a file descriptor which is unlinked from the filesystem ↩

28 May, 2025 05:53PM

Yves-Alexis Perez

Running autopkgtests locally

As a small addendum to the last post, here are the relevant commands #debci helpfully provided.

First, you need to install the autopkgtest package, obviously:

# apt install autopkgtest

Then you need to create a Debian virtual machine to run the tests (put the sid.raw wherever you prefer):

# autopkgtest-build-qemu sid /tmp/sid.raw

Then you can run the tests themselves, using the just created virtual machine. The autopkgtest command can use the tests from various sources, using the last argument to the command. In my case what was the most helpful was to run the tests from my git clone (which uses gbp) so I could edit the tests directly. So I didn't give anything for testsrc (but . would work as well I guess).

$ autopkgtest -BU --add-apt-release=unstable --pin-packages=unstable=strongswan -- qemu /tmp/sid.raw --ram-size=4096 --cpus=1

Then I could play with the tests themselves, the number of CPU for the Qemu VM, and run everything in a loop.

28 May, 2025 01:12PM by Yves-Alexis (corsac@debian.org)

Bits from Debian

Debian welcomes the 2025 GSOC contributors/students

GSoC logo

We are very excited to announce that Debian has selected nine contributors to work under mentorship on a variety of projects with us during the Google Summer of Code.

Here is a list of the projects and students, along with details of the tasks to be performed.

Project: Quality assurance and continuous integration for biological and medical applications inside Debian

Intern: Harish Chavre

Deliverables of the project: Continuous integration tests for Debian Med applications lacking a test, Quality Assurance review and bug fixing if issues might be uncovered.

Project: Device-specific Tweaks Management

Intern: Mohammed ElDegwi

Deliverables of the project: Analysis and discussion of the current state of device tweaks management in Debian and Mobian. Proposal for a unified, run-time approach. Packaging of this service and tweaks data/configuration for at least one device.

Project: Enhancing Debian packages with ROCm GPU acceleration

Interns: Spaarsh, utk4r-sh

Deliverables of the project: New Debian packages with GPU support. Enhanced GPU support within existing Debian packages. More autopackagetests running on the Debian ROCm CI.

Project: Make Debian for Raspberry Pi Build Again

Interns: Kurva Prashanth

Deliverables of the project: Refreshing the set of daily-built images. Having the set of daily-built images become automatic again—that is, go back to the promise of having it daily-built. Write an Ansible playbook/Chef recipe/Puppet whatsitsname to define a virtual serve and have it build daily. Do the (very basic!) hardware testing on several Raspberry computers. Do note, naturally, this will require having access to the relevant hardware.

Project: Package LLM Inference Libraries

Intern: k1000dai

Deliverables of the project: Eventually I hope we can make vLLM into Debian archive, based on which we can deliver something for LLM inference out-of-the-box. If the amount of work eventually turns to be beyond my expectation, I'm still happy to see how far we can go towards this goal. If the amount of work required for vLLM is less than I expected, we can also look at something else like SGLang, another open source LLM inference library.

Project: Autopkgtests for the rsync package

Intern: puer robustus

Deliverables of the project: Autopkgtests for the rsync package.

Project: Enhancing Salsa CI in Debian

Interns: Aayush (@44yu5h), aquilamacedo

Deliverables of the project: More features, robustness, speed.

Congratulations and welcome to all the contributors!

The Google Summer of Code program is possible in Debian thanks to the efforts of Debian Developers and Debian Contributors that dedicate part of their free time to mentor contributors and outreach tasks.

Join us and help extend Debian! You can follow the contributors' weekly reports on the debian-outreach mailing-list, chat with us on our IRC channel or reach out to the individual projects' team mailing lists.

28 May, 2025 10:04AM by Abhijith PA

Debian Day 2025 - call for celebration

Each year on August the 16th, we celebrate the Debian Project Anniversary.

Several communities around the world join us in celebrating "Debian Day" with local events, parties, or gatherings.

So, how about celebrating the 32nd anniversary of the Debian Project in 2025 in your city? As the 16th of August falls on a Saturday this year, we believe it is great timing to gather people around your event.

We invite you and your local community to organize a Debian Day by hosting an event with talks, workshops, a bug squashing party, or OpenPGP keysigning gathering, etc.

You could also hold a meeting with others in the Debian community in a smaller social setting like a bar/pizzeria/cafeteria/restaurant to celebrate. In other words, any type of celebrating is valid!

Remember to add your city to the Debian Day wiki page

There is a list of Debian Local Groups around the world. If your city is listed, talk to them to organize DebianDay together.

To inspire you and your local community, see some photos from 2023 and 2024

Let's use hashtags #DebianDay #DebianDay2025 on social media.

28 May, 2025 07:30AM by The Debian Publicity Team

Russell Coker

Leaf ZE1

I’ve just got a second hand Nissan LEAF. It’s not nearly as luxurious as the Genesis EV that I test drove [1]. It’s also just over 5 years old so it’s not as slick as the MG4 I test drove [2]. But the going rate for a LEAF of that age is $17,000 vs $35,000 or more for a new MG4 or $130,000+ for a Genesis. At this time the LEAF is the only EV in Australia that’s available on the second hand market in quantity. Apparently the cheapest new EV in Australia is a Great Wall one which is $32,000 and which had a wait list last time I checked, so $17,000 is a decent price if you want an electric car and aren’t interested in paying the price of a new car.

Starting the Car

One thing I don’t like about most recent cars (petrol as well as electric) is that they needlessly break traditions of car design. Inserting a key and turning it clockwise to start a car is a long standing tradition that shouldn’t be broken without a good reason. With the use of traditional keys you know that when a car has the key removed it can’t be operated, there’s no situation of the person with the key walking away and leaving the car driveable and there’s no possibility of the owner driving somewhere without the key and then being unable to start it. To start a LEAF you have to have the key fob device in range, hold down the brake pedal, and then press the power button. To turn on accessories you do the same but without holding down the brake pedal. They also have patterns of pushes, push twice to turn it on, push three times to turn it off. This is all a lot easier with a key where you can just rotate it as many clicks as needed.

The change of car design for the key means that no physical contact is needed to unlock the car. If someone stands by a car fiddling with the door lock it will get noticed which deters certain types of crime. If a potential thief can sit in a nearby car to try attack methods and only walk to the target vehicle once it’s unlocked it makes the crime a lot easier. Even if the electronic key is as secure as a physical key allowing attempts to unlock remotely weakens security. Reports on forums suggest that the electronic key is vulnerable to replay attacks. I guess I just have to hope that as car thieves typically get less than 10% of the value of a car it’s just not worth their effort to steal a $17,000 car. Unlocking doors remotely is a common feature that’s been around for a while but starting a car without a key being physically inserted is a new thing.

Other Features

The headlights turn on automatically when the car thinks that the level of ambient light warrants it. There is an option to override this to turn on lights but no option to force the lights to be off. So if you have your car in the “on” state while parked the headlights will be on even if you are parked and listening to the radio.

The LEAF has a bunch of luxury features which seem a bit ridiculous like seat warmers. It also has a heated steering wheel which has turned out to be a good option for me as I have problems with my hands getting cold. According to the My Nissan LEAF Forum the seat warmer uses a maximum of 50W per seat while the car heater uses a minimum of 250W [3]. So if there are one or two people in the car then significantly less power is used by just heating the seats and also keeping the car air cool reduces window fog.

The Bluetooth audio support works well. I’ve done hands free calls and used it for playing music from my phone. This is the first car I’ve owned with Bluetooth support. It also has line-in which might have had some use in 2019 but is becoming increasingly useless as phones with Bluetooth become more popular. It has support for two devices connecting via Bluetooth at the same time which could be handy if you wanted to watch movies on a laptop or tablet while waiting for someone.

The LEAF has some of the newer safety features, it tracks lane markers and notifies the driver via beeps and vibration if they stray from their lane. It also tries to read speed limit signs and display the last observed speed limit on the dash display. It also has a skid alert which in my experience goes off under hard acceleration when it’s not skidding but doesn’t go off if you lose grip when cornering. The features for detecting changing lanes when close to other cars and for emergency braking when another car is partly in the lane (even if moving out of the lane) don’t seem well tuned for Australian driving, the common trend on Australian roads is lawful-evil to use DND terminology.

Range

My most recent driving was just over 2 hours driving with a distance of a bit over 100Km which took the battery from 62% to 14%. So it looks like I can drive a bit over 200Km at an average speed of 50Km/h. I have been unable to find out the battery size for my car, my model will have either a 40KWh or 62KWh battery. Google results say it should be printed on the B pillar (it’s not) and that it can be deduced from the VIN (it can’t). I’m guessing that my car is the cheaper option which is supposed to do 240Km when new which means that a bit over 200Km at an average speed of 50Km/h when 6yo is about what’s expected. If it has the larger battery designed to do 340Km then doing 200Km in real use would be rather disappointing.

Assuming the battery is 40KWh that means it’s 5Km/KWh or 10KW average for the duration. That means that the 250W or so used by the car heater should only make a about 2% difference to range which is something that a human won’t usually notice. If I was to drive to another state I’d definitely avoid using the heater or airconditioner as an extra 4km could really matter when trying to find a place to charge when you aren’t familiar with the area. It’s also widely reported that the LEAF is less efficient at highway speeds which is an extra difficulty for that.

It seems that the LEAF just isn’t designed for interstate driving in Australia, it would be fine for driving between provinces of the Netherlands as it’s difficult to drive for 200km without leaving that country. Driving 700km to another city in a car with 200km range would mean charging 3 times along the way, that’s 2 hours of charging time when using fast chargers. This isn’t a problem at all as the average household in Australia has 1.8 cars and the battery electric vehicles only comprise 6.3% of the market. So if a household had a LEAF and a Prius they could just use the Prius for interstate driving. A recent Prius could drive from Melbourne to Canberra or Adelaide without refuelling on the way.

If I was driving to another state a couple of times a year I could rent an old fashioned car to do that and still be saving money when compared to buying petrol all the time.

Running Cost

Currently I’m paying about $0.28 per KWh for electricity, it’s reported that the efficiency of charging a LEAF is as low as 83% with the best efficiency when fast charging. I don’t own the fast charge hardware and don’t plan to install it as that would require getting a replacement of the connection to my home from the street, a new switchboard, and other expenses. So I expect I’ll be getting 83% efficiency when charging which means 48KWh for 200KM or 96KWH for the equivalent of a $110 tank of petrol. At $0.28/KWh it will cost $26 for the same amount of driving as $110 of petrol. I also anticipate saving money on service as there’s no need for engine oil changes and all the other maintenance of a petrol engine and regenerative braking will reduce the incidence of brake pad replacement.

I expect to save over $1100 per annum on using electricity instead of petrol even if I pay the full rate. But if I charge my car in the middle of the day when there is over supply and I don’t get paid for feeding electricity from my solar panels into the grid (as is common nowadays) it could be almost free to charge the car and I could save about $1500 on fuel.

Comfort

Electric cars are much quieter than cars with petrol or Diesel engines which is a major luxury feature. This car is also significantly newer than any other car I’ve driven much so it has features like Bluetooth audio which weren’t in other cars I’ve driven. When doing 100Km/h I can hear a lot of noise from the airflow, part of that would be due to the LEAF not having the extreme streamlining features that are associated with Teslas (such as retracting door handles) and part of that would be due to the car being older and the door seals not being as good as they were when new. It’s still a very quiet car with a very smooth ride. It would be nice if they used the quality of seals and soundproofing that VW uses in the Passat but I guess the car would be heavier and have a shorter range if they did that.

This car has less space for the driver than any other car I’ve driven (with the possible exception of a 1989 Ford Laser AKA Mazda 323). The front seats have less space than the Prius. Also the batteries seem to be under the front seats so there’s a bulge in the floor going slightly in front of the front seats when they are moved back which gives less space for the front passenger to move their legs and less space for the driver when sitting in a parked car. There are a selection of electric cars from MG, BYD, and Great Wall that have more space in the front seats, if those cars were on the second hand market I might have made a different choice but a second hand LEAF is the only option for a cheap electric car in Australia now.

The heated steering wheel and heated seats took a bit of getting used to but I have come to appreciate the steering wheel and the heated seats are a good way of extending the range of the car.

Misc Notes

The LEAF is a fun car to drive and being quiet is a luxury feature, it’s no different to other EVs in this regard. It isn’t nearly as fast as a Tesla, but is faster than most cars actually drive on the road.

When I was looking into buying a LEAF from one of the car sales sites I was looking at models less than 5 years old. But the ZR1 series went from 2017 to 2023 so there’s probably not much difference between a 2019 model and a 2021 model but there is a significant price difference. I didn’t deliberately choose a 2019 car, it was what a relative was selling at a time when I needed a new car. But knowing what I know now I’d probably look at that age of LEAF if choosing from the car sales sites.

Problems

When I turn the car off the side mirrors fold in but when I turn it on they usually don’t automatically unfold if I have anything connected to the cigarette lighter power port. This is a well known problem and documented on forums. This is something that Nissan really should have tested before release because phone chargers that connect to the car cigarette lighter port have been common for at least 6 years before my car was manufactured and at least 4 years before the ZE1 model was released.

The built in USB port doesn’t supply enough power to match the power use of a Galaxy Note 9 running Google maps and playing music through Bluetooth. On it’s own this isn’t a big deal but combined with the mirror issue of using a charger in the cigarette lighter port it’s a problem.

The cover over the charging ports doesn’t seem to lock easily enough, I had it come open when doing 100Km/h on a freeway. This wasn’t a big deal but as the cover opens in a suicide-door manner at a higher speed it could have broken off.

The word is that LEAF service in Australia is not done well. Why do you need regular service of an electric car anyway? For petrol and Diesel cars it’s engine oil replacement that makes it necessary to have regular service. Surely you can just drive it until either the brakes squeak or the tires seem worn.

I have been having problems charging, sometimes it will charge from ~20% to 100% in under 24 hours, sometimes in 14+ hours it only gets to 30%.

Conclusion

This is a good car and the going price on them is low. I generally recommend them as long as you aren’t really big and aren’t too worried about the poor security.

It’s a fun car to drive even with a few annoying things like the mirrors not automatically extending on start.

The older ones like this are cheap enough that they should be able to cover the entire purchase cost in 10 years by the savings from not buying petrol even if you don’t drive a lot. With a petrol car I use about 13 tanks of petrol a year so my driving is about half the average for Australia. Some people could cover the purchase price of a second hand leaf in under 5 years.

27 May, 2025 10:24AM by etbe

Daniel Pocock

Prison gate backdrop to baptism by Fr Sean O’Connell, St Paul’s, Coburg

One of Pope Francis' last activities before he passed away was a visit to the Coeli prison in Rome. It reminded me about one of our own prisons in Australia, the prison where I was baptised. After all the falsification of police rumors by rogue Debianists, and the case of the arrested Outreachies, the prison story is a curious twist of the truth.

Here is the main gate of Pentridge prison. The church is in the background at the end of the prison wall:

Pentridge Prison, Coburg, St Paul's Church

The Pope presides over St Peter's basilica in Rome. In Coburg, Australia, we have St Paul's church. Rome also has the Basilica of Saint Paul Outside the Walls, just as St Paul's is outside the walls of Pentridge.

Back in 1967, Ronald Ryan gained notoriety as the last man to hang in Australia. His crime was the murder of a prison guard while escaping from Melbourne's Pentridge Prison. He maintained he was innocent and there was some controversy over who fired the fatal shot.

Ryan's wikipedia page has a detailed description of the prison escape, describing the fatal incident at the intersection of Sydney Road, O'Hea Street and Champ Street.

St Paul's church is mentioned, Ryan's accomplice used a wall for shelter.

Walker went south across Church Street toward the adjacent Roman Catholic church in Sydney Road. Prison officer Bennett had his rifle aimed at Walker and ordered Walker to halt or he would shoot. Walker took cover behind a small wall that bordered the church.

The report goes on to the murder itself in the middle of this well known street.

George Hodson fell to the ground. He had been struck by a single bullet that exited through Hodson's back, about an inch lower than the point of entry in his right chest. Hodson died in the middle of Sydney Road. Warder Robert Paterson, now with a rifle, ran back outside and onto Champ Street.

On 30 March 1966, Ryan and his accomplice Walker were convicted of murder and manslaughter respectively. Their appeals were rejected in June 1966.

On 23 July 1966, shortly after Ryan's trial and appeal had both failed, Fr Sean Patrick O'Connell was ordained a priest at St Patrick's Cathedral, oblivious to the fact he would eventually have a "life sentence", if you could call it that, to occupy the church beside the gates of the prison.

Fr John Brosnan, a Jesuit, was the prison chaplain for 30 years from the 1950s to the 1980s. His work put him in touch with the prisoners, the guards and their respective families. He ran a high profile campaign to spare Ryan from the death penalty. (obituary of Fr Brosnan).

My father had already been living in Coburg prior to the arrival of Fr O'Connell. They knew each other throughout the entire period of forty years that Fr O'Connell served the parish.

Fr Sean O'Connell served brief periods in the parishes of Flemington, Werribee and Clifton Hill. In 1975 he became Assistant Priest for the Coburg parish and in 1979 he was appointed as Parish Priest.

In other words, Fr O'Connell arrived shortly before Fr Brosnan would finish his three decades of chaplaincy service on the other side of the adjacent prison wall.

The long and distinguished service of these men is the thing that really amplifies the sense of shock people feel about the wrongdoing of some among their peers. The priests known for wrongdoing had been moved from parish to parish every two or three years while Fr O'Connell and Fr Brosnan both had decades of service in the same locations.

In 1980, Bob Hawke was elected as the representative for Wills, the federal district enclosing Coburg. On 8 February 1983, Hawke became leader of the Labor Party and in March 1983, he became Prime Minister, holding onto the top job until December 1991. Hawke was not religious, nonetheless, he is widely remembered for his 1987 election promise that within three years, no Australian child will live in poverty.

Nonetheless, Hawke himself didn't live in the working class district of Coburg, he had a large house on the other side of Melbourne in Sandringham. Australia's Prime Minister has an official residence in Canberra, The Lodge and in Sydney, Kirribilli House .

Hawke's father was a Congregational minister but Hawke himself was an atheist. News reports suggest Hawke contemplated becoming a Catholic before his death. Is it possible the influence of Fr O'Connell had a subconscious impact on the former Prime Minister's thinking over the years?

In addition to his role in this very busy parish, Fr O'Connell was a director of Australian Catholic Relief (now Caritas) and the Catholic Immigration Office (CIO) within the Archdiocese.

I was born in the region and baptised right beside the prison at St Paul's church in December 1978.

Daniel Pocock, baptism, St Pauls, Coburg

Pentridge Prison guard tower, St Paul's church, Coburg

In Switzerland, Italian is the official language for one of the 26 cantons, the Canton of Ticino. Around eight percent of the Swiss population speak Italian. In Coburg, fifteen percent speak Italian, yet it is not an official language in any part of Australia. Fr O'Connell is well known for learning Italian and giving ministry to the Italian community.

In this photo from a festival, the procession is walking between the walls of the prison (left and rear of the photo) and the church (right hand side of the photo).

Father Sean O'Connell, St Paul's, Coburg, Italian

On 17 June 1980, Maria James was brutally murdered at a bookshop where she lived about fifty meters from St Mary's, the church in Thornbury, a district adjacent to Coburg. A witness claimed they saw Fr Anthony Bongiorno covered in blood. Fr O'Connell provided an alibi, which police verified through other means, proving that Fr Bongiorno was actually in Coburg on the day of the murder. The crime remains unsolved.

In November 1982, gangland figure Brian Kane asked Father John Brosnan to preside at his eventual funeral. A week later and Kane was shot in the Quarry Hotel, Brunswick. Fr Brosnan described the request from Kane in a news report:

For the prisoners, Fr Brosnan was like a stable family that some of them never had before.

Likewise, Fr O'Connell's 40 years in Coburg gave him the status of a family member for many of those who got to know him over the decades.

Here is a photo of Father O'Connell with students from year 3 and their teacher Miss Keogh in 1985:

Fr Sean O'Connell, St Paul's, Coburg, Miss Keogh

I never attended the school in Coburg. I did year 3 at St Patrick's in Kilmore. St Patrick's primary school is on the opposite side of the road from Assumption College, where Fr Brosnan attended high school himself many years prior.

In 1989, the largest employer in the district, Kodak, contemplated closing their factory. Prime Minister Hawke wasn't going to allow that to happen under his nose and the Government made a deal to keep the factory open. Nonetheless, by 2004, the rise of digital cameras made the factory obsolete and it closed anyway.

In 1992, when Hawke resigned, there was a byelection for the district and the winner was prominent local football personality Phil Cleary running as an independent against the established Labor party. His victory was a major coup. The rise of Cleary hints at the special relationship between sport, politics and religion in Australian society.

In 1996, I moved back to Coburg and for a while we lived in O'Hea Street, one of the places described in the report about Ronald Ryan's prison break.

Daniel Pocock, O'Hea Street, Coburg, Xavier College

Ronald Ryan's wife and daughters lived in Hawthorn, adjacent to Kew. When I tell anybody in Melbourne that I used to cycle from Pentridge to Xavier College on a daily basis it sounds rather odd.

Ronald Ryan, Peter Walker, George Hodson

In 1997, the Virtual Moreland Community Network was established and opened an office at 512 Sydney Road, also adjacent to the churches and the notorious prison. Here is a map:

St Paul's church, school, Virtual moreland, Coburg, Pentridge prison

The prison itself was closed on 1 May 1997. Some of the original heritage listed walls and buildings have been preserved.

Looking through official filings from the Australian Labor Party, I found the Vice President of the Coburg branch, an active member of the Upgrade Upfield Coordinating Committee was at one point living in a house owned by Fr O'Connell on Mackay Street, Coburg. Was it community activism that saved the train or was it the power of faith? It could have been a bit of both.

Nonetheless, it is another hint at the relationships between religion, politics and sport that underpin Australian society.

Fr John Brosnan passed away in 2003. He was given a state funeral in St Patrick's Cathedral (Eulogy for John Brosnan). The St Patrick's Cathedral choir became very well known due to the prosecution of Cardinal George Pell.

The last time I communicated with Fr O'Connell was February 2011. We needed a copy of the baptism certificate before the wedding. The wedding itself was on Palm Sunday, the same day that Adrian von Bidder (Debian) died in Switzerland.

von Bidder's death was discussed like a suicide and given that it happened shortly after other confirmed suicides, it feels like it was part of a suicide cluster on the day of our wedding. So I received the sacrament of baptism meters away from the gates of a notorious prison known for the murder of a prison guard and then at the sacrament of marriage, we had this Debian death that was avoidable and could even be a criminal act of manslaughter under the British definition of the law.

The day of the baptism was the first Sunday of Advent and the wedding, when Adrian von Bidder died, was Palm Sunday.

In 2010 I went to Zurich to work on a contract for UBS. The Kanton told us that we had to pay mandatory church taxes or we could not attend mass or be buried in a Swiss cemetery if we died there. This felt totally inconsistent with everything I had previously learnt about Christianity.

The church tax situation was even more confusing because they demanded that we give money to the church but they were refusing to cover the cost of medical services for Carla after somebody fell on her in a yoga studio.

In September 2012, the Irish immigrant Jill Meagher was last seen in the same street, Sydney Road, on the night of her abduction. The tragic death gained worldwide notoriety. There was significant anger and sadness in the region, amplified by the intense media attention.

At the time, I felt there was significant inconsistency between the manner in which Australian women were marching to support the white, attractive Irish immigrant Jill Meagher while turning a blind eye to the manner in which the government rounds up women from Afghanistan and Iran and puts them into state-sponsored concentration camps.

In 2013, I publicly resigned my membership of the Australian Labor Party due to the abuse of immigrants, comparing it to the scandal in the church.

16 September 2015, researcher Val Noone gave a presentation about the Irish in Coburg. The details were subsequently published in a blog. Fr O'Connell and Michael Laporta are credited as sources.

Father X.____, who I covered previously, moved to an adjacent parish in 2009 and retired in 2016.

Throughout 2016, the Child Abuse Royal Commission conducted a series of public and private hearings about abuse in the Catholic Church. Fr O'Connell is not one of those accused of wrongdoing, quite the opposite, the wrongdoing undermines his legacy. Nonetheless, Fr O'Connell died shortly after the public scandal, just as my father died shortly after Cardinal Pell was sent to prison in 2019.

Fr O'Connell's church and presbytery were surrounded on two sides by very high prison walls. Ironically, after living there for forty years, he may have only discovered at the same time as everybody else the extent to which a small group of his colleagues belonged on the other side.

Fr O'Connell's Golden Jubilee as a priest was 23 July 2016. Four days later, the ABC program 7:30 Report broadcast a mixed bag of accusations that would subsequently be the basis for the prosecution of Cardinal Pell.

On 18 December 2016, Fr O'Connell died at the Austin Hospital. A few days later, on 23 December 2016, his funeral was held as a Pontifical Requiem mass, in other words, the funeral was conducted by the bishop.

Immediately after that, in 2017, I started discovering the evidence about similar scandals in the supply chain of open source software. Between September and October I raised concerns with the organizations responsible for funding, especially Mozilla.

Coincidentally, Australia's Child Abuse Royal Commission handed down their report in December 2017, right in the middle of the period where I had discovered the wrongdoing in open source software.

Rogue Debianists became upset when their blackmail racket was exposed. They began censoring blogs at the end of 2018 and the Debian Christmas lynchings quickly followed.

Paul Tagliamonte from the US Digital Service (White House) stomped on people using metaphors about summary executions:

Subject: Re: Censorship in Debian
Date: Thu, 27 Dec 2018 10:39:19 -0500
From: Paul R. Tagliamonte <paultag@gmail.com>
To: Norbert Preining <norbert@preining.info>
CC: debian-project@lists.debian.org

This entire thread is so cringy, this is likely my last reply.

On Wed, Dec 26, 2018 at 9:31 PM Norbert Preining <norbert@preining.info> wrote:
>
> Paul,
>
> On Wed, 26 Dec 2018, Paul R. Tagliamonte wrote:
> > Please, all, get some perspective and stop with the comparisons to labor
> > camps, targeted killings, prisons and sentences of death. We sound like
>
> You did not understand the meaning of this comparison: The point was
> that the correct agreed upon and legal procedures have not been
> followed. And you deliberately removed this part from your email and
> consideration.

Gulags and military tribunals were both legal. They were not policy or
procedure fouls.
They were not foibles. It was intentional and targeted.

They were ways to murder dissidents. Say what you want about our ability to
self-govern the Debian community, and ways we've messed up, we've never
killed anyone as part of the expulsion process, and the comparisons need to
stop, even if I'm still "missing the point" and people consider what happened
with anti-harassment unfair. A-H is not killing DDs. Stop comparing them to it.

It's a very simple point.

> It is not about the planet, it is about expulsion that did not follow
> the rules. This *can* be consider a libel case due to influences on my
> professional life.
>
> Best
>
> Norbert

Paul

Tagliamonte's comment is wrong: people did die. Frans Pop and Adrian von Bidder both died shortly after the lynching of Sven Luther. Frans Pop wrote his suicide note / resignation email the night before Debian Day. See the full history of the Debian Harassment Culture. On the topic of Debian giving volunteers sentences, here are the gallows constructed to hang Ronald Ryan in D division at Pentridge:

Software in the Public Interest, Inc, a US non-profit, filed accounts for 2022 showing they spent $120,000 on legal fees to hide the fact Adrian von Bidder died, possibly as part of the suicide cluster, on our wedding day. Ironically, the psychology and the legal tactics used to evade liability for the suicides are remarkably similar to the tactics that the church was criticized for.

From baptism at the site of death to $120,000 in Debian kill money ...

Software in the public interest, legal expenses, vendettas

The church reasoned that they had to hide certain crimes by priests to maintain the public perception of the church as infallible. Looking at the lifetime of good work done by men like Fr Brosnan and Fr O'Connell, their reputations have stood the test of time and their legacy would not have been diminished in any way if rogue priests had been managed more competently in the region throughout the same period.

Even if they spend $120 million dollars, the lawyers and judges can not bring back the volunteers who died. It is not easy to hide a death, especially when the Debian logo is on the tombstone, along with the date of our wedding:

Look at the email from Diana von Bidder-Senn, the widow. She was completely in the dark about debian-private and all the problems subsequent to the previous suicide. This is an example of how the public is fooled by the messages that Paul Tagliamonte and others were publishing to whitewash over the truth about Debian harassment culture. Would she have sent an email like this if she had read and understood all the emails about Frans Pop in 2010?

Subject: Re: condolences for Adrian
Date: Mon, 25 Apr 2011 15:02:18 +0200
From: Diana von Bidder <diana@fortytwo.ch>
To: Stefano Zacchiroli <leader@debian.org>

Dear Stefano
Thank you for your wonderful mail! Yes Debian and people were very
important to Adrian. I was glad that he was not only sitting alone in
front of his computer but to know that there are people out there that
estimate him and are his friends even if most of you did not know each
other personally.
The way you describe him (empathy, calm, insight, ... - just the Adrian
I know) assures me on how good friends of Adrian are out there. And I
will always continue to think of this (in a good way!) when continuing
to use debian (which I became quite fond of because of Adrian). 
It's a pity that he couldn't go to Banja Luca anymore which he did so
much look forward to. Anyway, I wish you all the best and hope you
continue your good work.

- Diana

Shortly after Cardinal Pell died, I published a photo of our rowing crew. On 3 April 2023, the man sitting behind me won the National Emergency Medal. The following day, 4 April 2023, the Swiss financial regulator FINMA discretely shut down Parreaux, Thiebaud & Partners, leading to my investigation into the JuristGate scandal.

So I was baptised at the scene of a notorious death connected to the story of capital punishment in Australia and I went on to expose another facet of the corruption in the Swiss legal system. We don't know how many people have committed suicide due to invalid and corrupt judgments, liquidated lawyers, miscarriages of justice and other failings by racist Swiss hillbilly jurists. The suicide victims around Geneva are every bit as dead as George Hodson and Ronald Ryan.

I was granted Swiss citizenship on nothing less than the day of martyrs, an interesting coincidence when you consider the place of the baptism and the crimes I had exposed along the way. Could we say that Frans Pop and Adrian von Bidder were martyrs?.

Rest in peace George Hodson, Ronald Ryan, Fr Sean O'Connell & Fr John Brosnan SJ

Links

Please see the chronological history of how the Debian harassment and abuse culture evolved.

27 May, 2025 09:00AM

Russ Allbery

INN 2.7.3

This is a bug fix and minor feature release over INN 2.7.2, and the upgrade should be painless. You can download the new release from ISC or my personal INN pages. The latter also has links to the full changelog and the other INN documentation.

For the full list of changes, see the INN 2.7.3 NEWS file.

As always, thanks to Julien Ã‰LIE for preparing this release and doing most of the maintenance work on INN!

27 May, 2025 03:24AM

Daniel Pocock

Eulogy for Father John Brosnan by Peter Norden AO

Father John Brosnan SJ passed away in 2003 and he was given a state funeral at St Patrick's Cathedral in Melbourne. Fr Brosnan was one of the most notable priests in Australia's Catholic community due to his campaign against the death penalty and his contact with Ronald Ryan, the last man to hang in Australia.

Peter Norden AO, then Policy Director for Jesuit Social Services gave the eulogy. He makes some interesting comments about Fr Brosnan's philosophy. This is invaluable to our understanding of the flaws in the Code of Conduct (CoC) gaslighting phenomena.

‘I was in prison ……. and you visited me’.

This must be the most succinct description of the pubic life of Father John Brosnan.

As Australian of quite remarkable qualities, who spent thirty years ministering to those on the other side of the walls: The walls of Pentridge Prison, Coburg.

Those thirty years earned Father Brosnan the reputation of being ‘The Knockabout Priest.’

A priest who walked with a dignified and grace-filled presence the corridors of the most notorious prison in recent Australian history.

A pastor who combined Christian compassion and worldly wisdom as he advised and counselled thousands of inmates in their prison cells.

An advocate for human rights and civil liberties who undertook this task with discretion and subtlety and good humour.

A leading opponent of capital punishment, who knew from first hand experience the essential inconsistency of upholding the value of human life, by taking the life of another.

But there was much more to the life of Father John Brosnan than the thirty years he spent ‘in the nick’.

John Brosnan was born on 12 April 1919, at Keilambete, a small town between Terang and Mortlake, in the Western District of Victoria.

He was the third child of four children, the second of three sons, of Jeremiah Joseph Brosnan, a railway fettler, and his wife, Mark Jane, known as Jenny. Jeremiah Brosnan was born in County Kerry, Ireland, and migrated to Australia in 1886.

John Brosnan grew up in the small town of Cudgee, near Warrnambool, with is sister, Mary, present here today, and his brothers, Denis and Jim, both now deceased.

John was educated at Cudgee State School and later at Assumption College, Kilmore.

His early years at Cudgee, he often recalled in later years, growing up largely with Baptist families rather than a Catholic environment, prepared him for later life, where he moved easily in circles outside of the more sheltered Catholic Church network.

He often said that they had discovered ecumenism in Cudgee long before the Second Vatican Council and before it became fashionable!

Young John Brosnan later boarded at Assumption College for four years from the age of fifteen, from 1934-1937. He played one game with the First XVIII of Assumption College, but was carried off with a corkey ten minutes into the first quarter.

Geelong Football Club won the premiership that year in 1937, and his devotion to that other form of religion was well established, even in those days.

Late that evening, young John Brosnan led an enthusiastic celebration march down the main street of Kilmore with fellow students. The Marist Headmaster at the time, Brother Hilary, suggested that it might not have been appropriate for a young man with intentions to join the seminary the following year!

Stopped by people in the street in later years, who began their conversation with: ‘Father, I am not of your faith, but …’, Father Brosnan would interrupt them and say: ‘You mean you don’t follow my beloved Cats?’

Last August, the Geelong Football Club was preparing a public tribute to Father Brosnan, at their last home game, to be played at Colonial Stadium. The tribute was postponed, after Father broke his hip a few weeks before.

Discussing the preparations for this event with the young marketing officer from the club in recent days, I asked him: ‘Do you know who Father Brosnan was?’ He admitted he didn’t. I told him: Father Brosnan was effectively the marketing man for the Geelong Football Club around Australia, before the term ‘marketing’ was even invented!

As a student of Assumption College, young John Brosnan did apply for the seminary, to Bishop Daniel Foley of Ballarat. Many years later, Father Brosnan still remembered the curt letter in reply: ‘Dear Mr Brosnan, we have no vacancies for students for the priesthood in the Diocese of Ballarat. The religious orders are always anxious for suitable candidates.’

His personal and spiritual references from Assumption had been first class, even if his academic achievements were not, and after failing Latin of all subjects in his first year of Matriculation, he repeated the year and was accepted into the Archdiocese of Melbourne by Archbishop Mannix the following year, in 1938.

In 1945, John Brosnan was ordained a priest by Archbishop Mannix, here at Saint Patrick’s Cathedral, at the age of twenty-six.

The next two years he worked in Geelong, as chaplain to the Saint Augustine’s orphanage. Then as assistant priest at Saint Joseph’s Church in Collingwood for two years. Then he was stationed here at Saint Patrick’s Cathedral for a further five years, until his appointment to the position of Chaplain to Pentridge Prison in 1956.

During the years as Assistant Priest here at Saint Patrick’s he came to know and admire deeply Archbishop Mannix. Much of his astute capacity to move so effectively in public life came from the lessons he learned watching and listening to Mannix during those years.

In his biography, Father Brosnan explained the impact that Mannix had on him:

‘Dr Mannix was the only person, man, woman or child, I have known in my life I couldn’t take my eyes off. His every movement was worth watching, his every word worth hearing. I could watch Don Bradman bat, I could watch Reg Hickey or Polly Farmer move on a football field and I could watch Dr Mannix drink his soup! Every movement of the man was worth watching. You realised you were in the presence of greatness.’

When he arrived at Pentridge Prison as Chaplain in 1956, at the age of thirty-five, John Brosnan was both astonished and disturbed to find so many of his former junior football players from the inner-city parishes and from the orphanage at Geelong serving time. Before the psychologists had worked it out, he spoke about ‘kids’ futures being written on their faces before they were born.’ The ten years of priestly ministry before his assignment to Pentridge had prepared Father Brosnan well for his assignment to those sentenced to Her Majesty’s prisons.

His priesthood was one deeply inculturated in the lives of ordinary people. He was as much at home in Hardiman’s Pub, on Flemington racetrack or at the dogs on Monday nights, as he was in the church buildings. But he was always the pastoral man, offering a word of recognition or encouragement when it was most needed.

A man with a big heart for those in real need, offering a generous and practical response when called for. But this was balanced by an honesty and an insight into human behaviour which was hard to parallel: ‘Nurse a mug long enough and he will die in your arms’ was one of his sayings.

His great love of people, his incredible knowledge of family trees, and his memory for names and places, remained with him through to the end. His last thirteen years of ministry after retirement from Pentridge in 1985 were spent in the parishes: firstly, at Glenhuntly, then eleven years as Parish Priest at Holy Redeemer Church in Surrey Hills.

At Glenhuntly, one of his pastoral responsibilities included the care of those who attended the nearby Caulfield Racecourse. At Surrey Hills, his involvement with the local families watching their children progress through primary school was one of his delights. He knew each child by name and would reward many by a little treat at the end of the school day, usually a Mars Bar! Late last year a Year 8 student at Saint Kevin’s College asked me to send his regards to Father Brosnan: ‘Tell him, from the punter.’

But Father Brosnan’s public persona was formed during his thirty years as Chaplain at ‘The College of Knowledge’ in Sydney Road, Coburg.

There were many thousands of people assisted by Father Brosnan’s presence within the walls of Pentridge Prison during those years. When opening a new site for the Brosnan Centre, then in Sydney Road, Brunswick, former Premier John Cain quipped: ‘Father Brosnan worked with a terrible lot of people.’

However, this generous hearted man, with such a wonderful insight into human behaviour, pastored not only to those behind the walls of the prison, but to many thousands of others, in particular their wives, their children and their friends, many of whom could be regarded as victims of crime.

For the first twenty years of his prison ministry, Father Brosnan lived in a little cottage in Abbotsford, provided by the Good Shepherd Sisters. Here a procession of friends and prison acquaintances would visit him after hours, especially on Saturday mornings. Supported in a practical and generous way by the Sisters, Father Brosnan operated one of the then most effective after-care services, from his own residence.

He was pleased to see this early work as the forerunner of the Brosnan Centre established by the Jesuits in 1977, and later named after him, on his retirement from prison ministry in 1985.

In his last ten years as prison chaplain, he lived in a centrally located flats behind the old Saint Vincent’s hospital, provided by the Sisters of Charity. Throughout his working life, he appeared to have just one pair of shoes, one suit, and a sports jacket. What he was given as a gift was generally passed on to someone in need.

Saint Vincent De Paul prison visitors and VACRO, assisting the families of prisoners, were key collaborators in his ministry.

VACRO’s former manager, Matt Derham, used to refer to Father’s ‘old boys association’ as ‘Bros’s menagerie.’

Just as the time with Archbishop Mannix was a formative period in his priestly life, so was his ministry to Ronald Ryan and Ryan’s family. The public campaign against capital punishment with which he was so centrally involved in late 1966 and early 1967, was in one sense a failure.

But Ryan’s last words before his execution, directed to Father Brosnan, tell another story: ‘Never forget, no matter how long you live, you were ordained for me.’

Father Brosnan’s involvement with Ryan was one of the clearest, and certainly the most public, forms of witness he could give to the unconditional love of God.

Many Christian people mistakenly believe that this love must be earned or deserved. Father Brosnan had learned through his own life experience, especially through 30 years of prison ministry, that it is freely given.

It is significant, and a tribute to Father Brosnan’s involvement in the campaign against capital punishment, that Ryan was the last person executed by the State in Australia’s history and that capital punishment has now been removed from the statutes of every State and Territory in this country.

One of the most endearing qualities of John Brosnan was his refusal to sit in judgement on others. When it was suggested that one of his friends had been found to be involved in some form of dubious or illegal activity, ‘so they say’ he would comment.

While traditional in his theological beliefs, he had an enormous pastoral capacity and personal freedom to respond creatively to the circumstances of the person seeking his advice or guidance.

He moved with grace and with dignity across all levels of our society, and was well received by persons of all political persuasions and religious beliefs or ideologies.

The demand for his presence in public forums and as an after-dinner speaker was unbelievable and his capacity for this did not diminish with the years. He was often asked how he survived 30 years in the Nick. He would refer to four ancient documents that were a big help, written by Matthew, Mark, Luke and John. He would also quote words of wisdom from Henry Lawson.

John Brosnan was able to speak on sensitive issues, such as the need for prison reform, in a way that was hard to take offence, even in an entertaining but always respectful manner. Through this means, he was able to help the wider community consider and reflect on the complex issues of crime and punishment.

A notable example was when he was invited by the then Minister for Prisons, Pauline Toner, to join her in addressing an angry crowd of more than a thousand local residents opposed to the construction of Barwon Prison at Lara.

Father Brosnan was, as always, the essence of diplomacy and a builder of bridges between different points of view.

Many people will be affected by the departure of Father John Brosnan: Mary, his sister, the foremost, of course. And the members of Father’s Brosnan’s family.

Throughout this Cathedral today many people, from many different walks of life, will shed a tear as they reflect on the impact that this remarkable priest has had on their lives.

It may have been a quiet word of encouragement at a time of personal crisis. Or a contact made that led to a job opportunity or a decent place to live. Or his presence in court, when it seemed little could be said on one’s behalf. Or a quiet word of advice to a politician or public servant.

This legacy of Father Brosnan will live on in the centre that bears his name: The Brosnan Centre.

But what we will miss most of all is his friendship.

I can just her John Brosnan ask the question, at the pearly gates, with some wonderment:

‘Lord, when did I see you hungry, and feed you; or thirsty and give you drink? When did I see you a stranger and make you welcome; sick or in prison and go to see you/’

And the Lord will answer him:

‘I tell you solemnly, in so far as you did this to one of the least of these brothers or sisters of mine, you did it to me.’

Father John Brosnan, a faith-filled life that brought hope and encouragement where it was most needed.

A life of respectful and committed service, with much to say to our divided world at the present time. Father Brosnan, we thank you!

Please see the Catholic.community site for more interesting stories.

25 May, 2025 06:30PM

Iustin Pop

Corydalis v2025.21.0 - new features!

I just released yesterday a new version of Corydalis (https://demo.corydalis.io, https://github.com/iustin/corydalis). To me personally, itâ€™s a major improvement, since the native (my own) image viewer finally gets zooming, panning, gesture handling, etc. This is table-stakes for an image viewer, but oh well, it took me a long time to implement it, because of multiple things: lack of time, the JS library I was using for gestures was pretty old and unmaintained and it caused more trouble than was helping, etc.

The feature is not perfect, and on the demo site thereâ€™s already a bug since all images are smaller than the screen, and this I didnâ€™t test ğŸ˜…, so double-click to zoom doesnâ€™t work: says â€œAlready at minimum zoomâ€�, but zooming otherwise (+/- on the keyboard, mouse wheel, gesture) works.

End-to-end, the major development for this release was done over around two weeks, which is pretty short: I extensively used Claude Sonnet and Grok to unblock myself. Not to write code per se - although there is code written 1:1 by LLMs, but most of the code is weirdly wrong, and I have to either correct it or just use it as a starter and rewrite most of it. But to discuss and unblock, and learn about new things, the current LLMs are very good at.

And yet, sometimes even what theyâ€™re good at, fails hard. I asked for ideas to simplify a piece of code, and it went nowhere, even if there were significant rewrite possibilities. I spent the brain cycles on it, reverse engineered my own code, then simplified. Iâ€™ll have to write a separate blog post on thisâ€¦

In any case, this (zooming) was the last major feature I was missing. There are image viewer libraries, but most of them slow, compared to the bare-bones (well, now not so much anymore) viewer that I use as main viewer. From now on, it will me minor incremental features, mostly around Exif management/handling, etc. Or, well, internal cleanups: extend test coverage, remove use of JQuery in the frontend, etc., there are tons of things to do.

Fun fact: I managed to discover a Safari iOS bug. Or at least I think itâ€™s a bug, so reported it and curious whatâ€™ll come out of it.

Finally, I still couldnâ€™t fix the GitHub actions bug where the git describe doesnâ€™t see the just pushed tag, sigh, so the demo site still lists Corydalis v2024.12.0-133-g00edf63 as the version ğŸ˜…

25 May, 2025 02:27PM

Bits from Debian

New Debian Developers and Maintainers (March and April 2025)

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

Moritz Schlarb (moschlar)
Sérgio de Almeida Cipriano Júnior (cipriano)
Mario Anthony Limonciello (superm1)

The following contributor was added as Debian Maintainer in the last two months:

Martin-Éric Racine

Congratulations!

24 May, 2025 06:00PM by Jean-Pierre Giraud

Steinar H. Gunderson

Some demoparty stream firsts

A discussion the other day made me remember some of the demoparty stream “first” that I'm still proud of, most of which still haven't been matched:

Live voting user counts during the compo (example, at the bottom). A combination of gamification and deliberate peer pressure; if you see that others are voting, you'll feel compelled to follow their example. (The counter would never go down during a compo, only up, even if people stopped adding new votes. Also deliberate.)
Locking the frame rate to the compo machine throughout the entire chain; in practice, this means that oldschool demos would come in 50 Hz and newschool in 60 Hz, creating a fully VFR stream. A pain during switches, and YouTube messes it up and makes the entire file a bit choppy, but so cool. If always wanted it to do the infamous 50.12 Hz from C64, but never really figured it out.
And last but not least, the “Eurovision” effect. Don't remember which entry was which during voting? No problem, we wget a 10-second sample (the advantage of having software video mixing for the bigscreen!) during the compo, furiously transcode it to something reasonable on an Arm thingie, and then put a loop of all of them together at the end of the compo. (A glimpse of an example)

Oh, and we streamed the street basketball compo, of course. Through a terrible, terrible video chain that made everything choppy. Would do better if I ever did it again :-)

24 May, 2025 02:08PM

Julian Andres Klode

A SomewhatMaxSAT Solver

As you may recall from previous posts and elsewhere I have been busy writing a new solver for APT. Today I want to share some of the latest changes in how to approach solving.

The idea for the solver was that manually installed packages are always protected from removals – in terms of SAT solving, they are facts. Automatically installed packages become optional unit clauses. Optional clauses are solved after manual ones, they don’t partake in normal unit propagation.

This worked fine, say you had

A                                   # install request for A
B                                   # manually installed, keep it
A depends on: conflicts-B | C

Installing A on a system with B installed installed C, as it was not allowed to install the conflicts-B package since B is installed.

However, I also introduced a mode to allow removing manually installed packages, and that’s where it broke down, now instead of B being a fact, our clauses looked like:

A                               # install request for A
A depends on: conflicts-B | C
Optional: B                     # try to keep B installed

As a result, we installed conflicts-B and removed B; the steps the solver takes are:

A is a fact, mark it
A depends on: conflicts-B | C is the strongest clause, try to install conflicts-B
We unit propagate that conflicts-B conflicts with B, so we mark not B
Optional: B is reached, but not satisfiable, ignore it because it’s optional.

This isn’t correct: Just because we allow removing manually installed packages doesn’t mean that we should remove manually installed packages if we don’t need to.

Fixing this turns out to be surprisingly easy. In addition to adding our optional (soft) clauses, let’s first assume all of them!

But to explain how this works, we first need to explain some terminology:

The solver operates on a stack of decisions
“enqueue” means a fact is being added at the current decision level, and enqueued for propagation
“assume” bumps the decision level, and then enqueues the assumed variable
“propagate” looks at all the facts and sees if any clause becomes unit, and then enqueues it
“unit” is when a clause has a single literal left to assign

To illustrate this in pseudo Python code:

We introduce all our facts, and if they conflict, we are unsat:

for fact in facts:
    enqueue(fact)
if not propagate():
    return False

For each optional literal, we register a soft clause and assume it. If the assumption fails, we ignore it. If it succeeds, but propagation fails, we undo the assumption.

for optionalLiteral in optionalLiterals:
    registerClause(SoftClause([optionalLiteral]))
    if assume(optionalLiteral) and not propagate():
        undo()

Finally we enter the main solver loop:

while True:
    if not propagate():
        if not backtrack():
            return False
    elif <all clauses are satisfied>:
        return True
    elif it := find("best unassigned literal satisfying a hard clause"):
        assume(it)
    elif it := find("best literal satisfying a soft clause"):
        assume(it)

The key point to note is that the main loop will undo the assumptions in order; so if you assume A,B,C and B is not possible, we will have also undone C. But since C is also enqueued as a soft clause, we will then later find it again:

Assume A: State=[Assume(A)], Clauses=[SoftClause([A])]
Assume B: State=[Assume(A),Assume(B)], Clauses=[SoftClause([A]),SoftClause([B])]
Assume C: State=[Assume(A),Assume(B),Assume(C)], Clauses=[SoftClause([A]),SoftClause([B]),SoftClause([C])]
Solve finds a conflict, backtracks, and sets not C: State=[Assume(A),Assume(B),not(C)]
Solve finds a conflict, backtracks, and sets not B: State=[Assume(A),not(B)] – C is no longer assumed either
Solve, assume C as it satisfies SoftClause([C]) as next best literal: State=[Assume(A),not(B),Assume(C)]
All clauses are satisfied, solution is A, not B, and C.

This is not (correct) MaxSAT, because we actually do not guarantee that we satisfy as many soft clauses as possible. Consider you have the following clauses:

Optional: A
Optional: B
Optional: C
B Conflicts with A
C Conflicts with A

There are two possible results here:

{A} – If we assume A first, we are unable to satisfy B or C.
{B,C} – If we assume either B or C first, A is unsat.

The question to ponder though is whether we actually need a global maximum or whether a local maximum is satisfactory in practice for a dependency solver If you look at it, a naive MaxSAT solver needs to run the SAT solver 2**n times for n soft clauses, whereas our heuristic only needs n runs.

For dependency solving, it seems we do not seem have a strong need for a global maximum: There are various other preferences between our literals, say priorities; and empirically, from evaluating hundreds of regressions without the initial assumptions, I can say that the assumptions do fix those cases and the result is correct.

Further improvements exist, though, and we can look into them if they are needed, such as:

Use a better heuristic:

If we assume 1 clause and solve, and we cause 2 or more clauses to become unsatisfiable, then that clause is a local minimum and can be skipped. This is a more common heuristical MaxSAT solver. This gives us a better local maximum, but not a global one.

This is more or less what the Smart package manager did, except that in Smart, all packages were optional, and the entire solution was scored. It calculated a basic solution without optimization and then toggled each variable and saw if the score improved.
Implement an actual search for a global maximum:

This involves reading the literature. There are various versions of this, for example:
1. Find unsatisfiable cores and use those to guide relaxation of clauses.
2. A bounds-based search, where we translate sum(satisifed clauses) > k into SAT, and then search in one of the following ways:
  1. from 0 upward
  2. from n downward
  3. perform a binary search on [0, k] satisfied clauses.
  Actually we do not even need to calculate sum constraints into CNF, because we can just add a specialized new type of constraint to our code.

24 May, 2025 10:14AM

Yves-Alexis Perez

strongSwan autopkgtests

For a while, the strongSwan Debian package had an autopktest. The initial version was proposed by Christian Ehrhardt in 2016 (presumably especially for downstream use in Ubuntu) and updated in 2019, but since then not much at least in Debian.

With the metapackage dependencies update in 6.0.0-1 I had to tune a bit the tests dependencies so they wouldn't totally fail, and I noticed the amd64 tests were failing since basically the beginning (the other architectures would pass, but because the tests wouldn't actually run at all since they rely on the isolation-machine restriction which is not available there.

So I tried to fix them, and it actually took me quite a while because I wasn't able to run the tests locally easily and the salsa CI doesn't have the isolation-machine restriction either. And some tests would pass and not other.

With some nice help from #debci, and using my newly received X13G5 I set up an autopkgtest VM and started experimenting. The 6.0.0-4 autopkgtests were failing 19 times over 20 steps, but passing one time. So it looked like a race condition, which we narrowed to the fact that starting the daemons (using invoke-rc.d which calls systemctl) is asynchronous. So depending on the load and maybe the machine, the tests would usually fail but sometime pass.

There's no easy way to make the call synchronous, so as a stopgap I added a small sleep 1 command and it fixed it for now. Tada! strongSwan has now passing autopkgtests in unstable (and testing) amd64. It's not entirely satisfying but still.

Next steps would be to add tests for the new daemon using the swanctl inteface, but that'll be for Forky (Trixie+1).

23 May, 2025 02:49PM by Yves-Alexis (corsac@debian.org)

Sven Hoexter

pflogsumm 1.1.6

Mainly relevant for the few who still run their own mail server and use Postfix + pflogsumm.

Few weeks back Jim contacted me that he's going to pick up work on pflogsumm again, and as first step wanted to release 1.1.6 to incorporate patches from the Debian package. That one is now released. Since we're already in the Trixie freeze the package is in experimental, but as usual should be fine to install manually.

Heads Up - Move to /usr/bin

I took that as an opportunity to move pflogsumm from /usr/sbin to /usr/bin! There was not really a good reason to ever have it in sbin. It's neither a system binary, nor statically linked (like in the very old days), or something that really only makes sense to be used as root. Some out there likely have custom scripts which do not rely on an adjusted PATH variable, those scripts require an update.

23 May, 2025 11:52AM

Dirk Eddelbuettel

RcppArmadillo 14.4.3-1 on CRAN: Small Upstream Bug Fix

armadillo image

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

Conrad released a minor bugfix version yesterday which addresses corner cases with non-finite values in sparse matrices. And despite conference traveling, I managed to wrap this up and ship it to CRAN where it appeared yesterday. The changes since the last CRAN release are summarised below.

Changes in RcppArmadillo version 14.4.3-1 (2025-05-21)

Upgraded to Armadillo release 14.4.3 (Filtered Espresso)

Fix for several corner cases involving handling of non-finite elements by sparse matrices

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

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

22 May, 2025 01:19PM

Bits from Debian

EDF Platinum Sponsor of DebConf25

We are pleased to announce that EDF has committed to sponsor DebConf25 as a Platinum Sponsor.

EDF is a leading global utility company focused on low-carbon power generation. The group uses advanced engineering and scientific computing tools to drive innovation and efficiency in its operations, especially in nuclear power plant design and safety assessment.

Since 2003, the EDF Group has been using Debian as its main scientific computing environment. Debian's focus on stability and reproducibility ensures that EDF's calculations and simulations produce consistent and accurate results.

With this commitment as Platinum Sponsor, EDF is contributing to the annual Debian Developers' Conference, directly supporting the progress of Debian and Free Software. EDF contributes to strengthening the worldwide community that collaborates on Debian projects year-round.

Thank you very much, EDF, for your support of DebConf25!

Become a sponsor too!

DebConf25 will take place from 14th to July 19th 2025 in Brest, France, and will be preceded by DebCamp, from 7th to 13th July 2025.

DebConf25 is accepting sponsors! Interested companies and organizations may contact the DebConf team through sponsors@debconf.org, and visit the DebConf25 website at https://debconf25.debconf.org/sponsors/become-a-sponsor/.

21 May, 2025 12:50AM by Sahil Dhiman

Arturo Borrero González

Wikimedia Cloud VPS: IPv6 support

Cape Town (ZA), Sea Point, Nachtansicht

Dietmar Rabich, Cape Town (ZA), Sea Point, Nachtansicht — 2024 — 1867-70 – 2, CC BY-SA 4.0

This post was originally published in the Wikimedia Tech blog, authored by Arturo Borrero Gonzalez.

Wikimedia Cloud VPS is a service offered by the Wikimedia Foundation, built using OpenStack and managed by the Wikimedia Cloud Services team. It provides cloud computing resources for projects related to the Wikimedia movement, including virtual machines, databases, storage, Kubernetes, and DNS.

A few weeks ago, in April 2025, we were finally able to introduce IPv6 to the cloud virtual network, enhancing the platform’s scalability, security, and future-readiness. This is a major milestone, many years in the making, and serves as an excellent point to take a moment to reflect on the road that got us here. There were definitely a number of challenges that needed to be addressed before we could get into IPv6. This post covers the journey to this implementation.

The Wikimedia Foundation was an early adopter of the OpenStack technology, and the original OpenStack deployment in the organization dates back to 2011. At that time, IPv6 support was still nascent and had limited implementation across various OpenStack components. In 2012, the Wikimedia cloud users formally requested IPv6 support.

When Cloud VPS was originally deployed, we had set up the network following some of the upstream-recommended patterns:

nova-networks as the engine in charge of the software-defined virtual network
using a flat network topology – all virtual machines would share the same network
using a physical VLAN in the datacenter
using Linux bridges to make this physical datacenter VLAN available to virtual machines
using a single virtual router as the edge network gateway, also executing a global egress NAT – barring some exceptions, using what was called “dmz_cidr” mechanism

In order for us to be able to implement IPv6 in a way that aligned with our architectural goals and operational requirements, pretty much all the elements in this list would need to change. First of all, we needed to migrate from nova-networks into Neutron, a migration effort that started in 2017. Neutron was the more modern component to implement software-defined networks in OpenStack. To facilitate this transition, we made the strategic decision to backport certain functionalities from nova-networks into Neutron, specifically the “dmz_cidr” mechanism and some egress NAT capabilities.

Once in Neutron, we started to think about IPv6. In 2018 there was an initial attempt to decide on the network CIDR allocations that Wikimedia Cloud Services would have. This initiative encountered unforeseen challenges and was subsequently put on hold. We focused on removing the previously backported nova-networks patches from Neutron.

Between 2020 and 2021, we initiated another significant network refresh. We were able to introduce the cloudgw project, as part of a larger effort to rework the Cloud VPS edge network. The new edge routers allowed us to drop all the custom backported patches we had in Neutron from the nova-networks era, unblocking further progress. Worth mentioning that the cloudgw router would use nftables as firewalling and NAT engine.

A pivotal decision in 2022 was to expose the OpenStack APIs to the internet, which crucially enabled infrastructure management via OpenTofu. This was key in the IPv6 rollout as will be explained later. Before this, management was limited to Horizon – the OpenStack graphical interface – or the command-line interface accessible only from internal control servers.

Later, in 2023, following the OpenStack project’s announcement of the deprecation of the neutron-linuxbridge-agent, we began to seriously consider migrating to the neutron-openvswitch-agent. This transition would, in turn, simplify the enablement of “tenant networks” – a feature allowing each OpenStack project to define its own isolated network, rather than all virtual machines sharing a single flat network.

Once we replaced neutron-linuxbridge-agent with neutron-openvswitch-agent, we were ready to migrate virtual machines to VXLAN. Demonstrating perseverance, we decided to execute the VXLAN migration in conjunction with the IPv6 rollout.

We prepared and tested several things, including the rework of the edge routing to be based on BGP/OSPF instead of static routing. In 2024 we were ready for the initial attempt to deploy IPv6, which failed for unknown reasons. There was a full network outage and we immediately reverted the changes. This quick rollback was feasible due to our adoption of OpenTofu: deploying IPv6 had been reduced to a single code change within our repository.

We started an investigation, corrected a few issues, and increased our network functional testing coverage before trying again. One of the problems we discovered was that Neutron would enable the “enable_snat” configuration flag for our main router when adding the new external IPv6 address.

Finally, in April 2025, after many years in the making, IPv6 was successfully deployed.

Compared to the network from 2011, we would have:

Neutron as the engine in charge of the software-defined virtual network
Ready to use tenant-networks
Using a VXLAN-based overlay network
Using neutron-openvswitch-agent to provide networking to virtual machines
A modern and robust edge network setup

Over time, the WMCS team has skillfully navigated numerous challenges to ensure our service offerings consistently meet high standards of quality and operational efficiency. Often engaging in multi-year planning strategies, we have enabled ourselves to set and achieve significant milestones.

The successful IPv6 deployment stands as further testament to the team’s dedication and hard work over the years. I believe we can confidently say that the 2025 Cloud VPS represents its most advanced and capable iteration to date.

This post was originally published in the Wikimedia Tech blog, authored by Arturo Borrero Gonzalez.

20 May, 2025 01:00PM

Andrew Cater

Debian 12.11 - testing completed, images being signed and we'll be back for the next point release on ???

All finished and wrapping up. The bug I thought was fixed has been identified on two distinct sets of hardware. There are workarounds: the most sensible is *not* to use i386 without a modeset parameter but to just use amd64 instead. amd64 works on the identical problematic hardware in question - just use 64 bit.

17 May, 2025 06:00PM by Andrew Cater (noreply@blogger.com)

Debian 12.11 testing - and we're nearly there

Almost finished the testing we're going to do at 15:29 UTC. It's all been good - we've found that at least one of the major bug reports from 12.10 is not reproducible now. All good - and many thanks to all testers: Sledge, rattusrattus, egw, smcv (and me).

17 May, 2025 03:31PM by Andrew Cater (noreply@blogger.com)

Debian 12.11 images testing - progress

We're now well under way: Been joined by a Simon McVittie (smcv) and we're almost through testing most of the standard images. Live image testing is being worked through. All good so far without identifying problems other than mistyping :)

17 May, 2025 01:10PM by Andrew Cater (noreply@blogger.com)

John Goerzen

How to Use SSH with FIDO2/U2F Security Keys

For many years now, I’ve been using an old YubiKey along with the free tier of Duo Security to add a second factor to my SSH logins. This is klunky, and has a number of drawbacks (dependency on a cloud service and Internet among them).

I decided it was time to upgrade, so I recently bought a couple of YubiKey 5 series security keys. These support FIDO2/U2F, which make it so much easier to integrate with ssh.

But in researching how to do this, I found a lot of pages online with poor instructions. Either they didn’t explain what was going on very well, or suggested what I came to learn were insecure practices, or — most often — both.

It turns out this whole process is quite easy. But I wanted to understand how it worked.

So, I figured it out, set it up myself, and then put up a new, comprehensive page on my website: https://www.complete.org/easily-using-ssh-with-fido2-u2f-hardware-security-keys/. I hope it helps!

17 May, 2025 12:53PM by John Goerzen

Andrew Cater

20250517 - Debian point release - Bookworm 12.11 today

In Cottenham with Andy and the usual suspects. The point release update files are already on the servers - anyone can do an "apt-get update ; apt-get dist-upgrade" and update any running machine. This machine has just been upgraded and "just worked".

Here to do release testing for the images that we will end up publishing later in the day.

Expecting one more of us to turn up a bit later. Team will be working on IRC on #debian-cd

17 May, 2025 11:51AM by Andrew Cater (noreply@blogger.com)

Michael Prokop

Grml 2025.05 – codename Nudlaug

Debian hard freeze on 2025-05-15? We bring you a new Grml release on top of that! 2025.05 🚀 – codename Nudlaug.

There’s plenty of new stuff, check out our official release announcement for all the details. But I’d like to highlight one feature that I particularly like: SSH service announcement with Avahi. The grml-full flavor ships Avahi, and when you enable SSH, it automatically announces the SSH service on your local network. So when f.e. booting Grml with boot option `ssh=debian`, you should be able to login on your Grml live system with `ssh grml@grml.local` and password ‘debian‘:

% insecssh grml@grml.local
Warning: Permanently added 'grml.local' (ED25519) to the list of known hosts.
grml@grml.local's password: 
Linux grml 6.12.27-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.27-1 (2025-05-06) x86_64
Grml - Linux for geeks

grml@grml ~ %

Hint: grml-zshrc provides that useful shell alias `insecssh`, which is aliased to `ssh -o “StrictHostKeyChecking=no” -o “UserKnownHostsFile=/dev/null”`. Using those options, you aren’t storing the SSH host key of the (temporary) Grml live system (permanently) in your UserKnownHostsFile.

BTW, you can run `avahi-browse -d local _ssh._tcp –resolve -t` to discover the SSH services on your local network. 🤓

Happy Grml-ing!

16 May, 2025 04:42PM by mika

Yves-Alexis Perez

New laptop: Lenovo Thinkpad X13 Gen 5

After more than ten years on my trusted X250, and with a lot of financial help for Debian (which I really thank, more on that later), I finally jumped on a new ThinkPad, an X13 Gen 5.

The migration path was really easy: I'm doing daily backups with borg of the whole filesystems on an encrypted USB drive, so I just had to boot a live USB key on the new laptop, plug the USB drive, create the partitioning (encryption, LVM etc.) and then run borg extract. Since I'm using LABEL in the various fstab I didn't have much to change.

I actually had a small hiccup because my daily backup scripts used ProtectKernelModules and besides preventing loading modules into the running kernel, it also prevents access to /usr/lib/modules. So when restoring I didn't have any modules for the installed kernels. No big deal, I reinstalled the kernel package from the chroot and it did work just fine.

All in all it was pretty smooth.

I've started a similar page as the X250 for the X13G5 but honestly I don't think I'll have to document a lot of stuff because everything basically works out of the box. It's not really a surprise because we went a long way since 2015 and Linux kernels are really tested on a lot of hardware, including laptops these days, and Intel laptops are the most standard stuff you can find. I guess it's still rocky for ARM64 laptops (and especially Apple hardware) but the point was less to do porting work for Debian and rather beeing more efficient for the current stuff I maintain (and sometimes struggle with).

As said above, the laptop has been funded by Debian and I really thank the DPL and the Debian France treasurer for authorizing it and beeing really fast on the reimbursement.

I had already posted a long time ago about hardware funding for Debian developers. It took me quite a while but I finally managed to ask for help because I couldn't afford the hardware at this point and it was becoming problematic. This is not something which should be done lightly (Debian wouldn't have the funds) but this is definitely something which should be done if needed. Don't hesitate to ask your fellow Debian developpers about advice on this.

15 May, 2025 08:19PM by Yves-Alexis (corsac@debian.org)

Jonathan McDowell

Local Voice Assistant Step 3: A Detour into Tensorflow

To build our local voice satellite on a Debian system rather than using the ATOM Echo device we need something that can handle the wake word component; the piece that means we only send audio to the Home Assistant server for processing by whisper.cpp when we’ve detected someone is trying to talk to us.

openWakeWord seems to be one of the better ways to do this, and is well supported. However. It relies on TensorFlow Lite (now LiteRT) which is a complicated mess of machine learning code. tflite-runtime is available from PyPI, but that’s prebuilt and we’re trying to avoid that.

Despite, on initial impressions, it looking quite complicated to deal with building TensorFlow - Bazel is an immediate warning - it turns out to be incredibly simple to build your own .deb:

$ wget -O tensorflow-v2.15.1.tar.gz https://github.com/tensorflow/tensorflow/archive/refs/tags/v2.15.1.tar.gz
…
$ tar -axf tensorflow-v2.15.1.tar.gz
$ cd tensorflow-2.15.1/
$ BUILD_NUM_JOBS=$(nproc) BUILD_DEB=y tensorflow/lite/tools/pip_package/build_pip_package_with_cmake.sh
…
$ find . -name *.deb
./tensorflow/lite/tools/pip_package/gen/tflite_pip/python3-tflite-runtime-dbgsym_2.15.1-1_amd64.deb
./tensorflow/lite/tools/pip_package/gen/tflite_pip/python3-tflite-runtime_2.15.1-1_amd64.deb

This is hiding an awful lot of complexity, however. In particular the number of 3rd party projects that are being downloaded in the background (and compiled, to be fair, rather than using binary artefacts).

We can build the main C++ wrapper .so directly with cmake, allowing us to investigate a bit more:

mkdir tf-build
cd tf-build/
cmake \
    -DCMAKE_C_FLAGS="-I/usr/include/python3.11" \
    -DCMAKE_CXX_FLAGS="-I/usr/include/python3.11" \
    ../tensorflow-2.15.1/tensorflow/lite/
cmake --build . -t _pywrap_tensorflow_interpreter_wrapper
…
[100%] Built target _pywrap_tensorflow_interpreter_wrapper
$ ldd _pywrap_tensorflow_interpreter_wrapper.so
    linux-vdso.so.1 (0x00007ffec9588000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f22d00d0000)
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f22cf600000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f22d00b0000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f22cf81f000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f22d01d1000)

Looking at the output we can see that pthreadpool, FXdiv, FP16 + PSimd are all downloaded, and seem to have ways to point to a local copy. That seems positive.

However, there are even more hidden dependencies, which we can see if we look in the _deps/ subdirectory of the build tree. These don’t appear to be as easy to override, and not all of them have packages already in Debian.

First, the ones that seem to be available: abseil-cpp, cpuinfo, eigen, farmhash, flatbuffers, gemmlowp, ruy + xnnpack

(lots of credit to the Debian Deep Learning Team for these, and in particular Mo Zhou)

Dependencies I couldn’t see existing packages for are: OouraFFT, ml_dtypes & neon2sse.

At this point I just used the package I built with the initial steps above. I live in hope someone will eventually package this properly for Debian, or that I’ll find the time to try and help out, but that’s not going to be today.

I wish upstream developers made it easier to use system copies of their library dependencies. I wish library developers made it easier to build and install system copies of their work. pkgconf is not new tech these days (pkg-config appears to date back to 2000), and has decent support in CMake. I get that there can be issues with incompatibilities even in minor releases, or awkwardness in doing builds of multiple connected projects, but at least give me the option to do so.

14 May, 2025 05:39PM

Sven Hoexter

Disable Firefox DRM Plugin Infobar

... or how I spent my lunch break today.

An increasing amount of news outlets (hello heise.de) start to embed bullshit which requires DRM playback. Since I keep that disabled I now get an infobar that tells me that I need to enable it for this page. Pretty useless and a pain in the back because it takes up screen space. Here's the quick way how to get rid of it:

Go to about:config and turn on toolkit.legacyUserProfileCustomizations.stylesheets.
Go to your Firefox profile folder (e.g. ~/.mozilla/firefox/<random-value>.default/) and mkdir chrome && touch chrome/userChrome.css.

Add the following to your userChrome.css file:

 .infobar[value="drmContentDisabled"] {
   display: none !important;
 }

Restart Firefox and read news again with full screen space.

14 May, 2025 12:06PM

Jonathan Dowland

Orbital

Orbital at NX, Newcastle in 2023

I'm on a bit of an Orbital kick at the moment. Last year they re-issued their 1991 debut album with 43 extra tracks. Later this month they're doing the same for their 1993 sophomore album.

I thought I'd try to narrow down some tracks to recommend. I seem to have settled on roughly 5 in previous posts (for Underworld, The Cure, Coil and Gazelle Twin). This time I've done 6 (I borrowed one from Underworld)

As always it's a hard choice. I've tried to select some tracks I really enjoy that don't often come up on best-of compilation albums. For a more conventional choice of best-of tracks, I recommend the recent-ish 30 something "compilation" (of sorts, previously written about)

The Naked and the Dead (1992)
The Naked and the Dead by Orbital
From an early EP Radiccio, which is being re-issued this month. Digital versions of the re-issue will feature a new recording "Deepest" featuring Tilda Swinton. Sadly this isn't making it onto the pressed version. She performed with them live at Glastonbury 2024. That entire performance was a real pick-me-up during my convolescence, and is recommended.

Anyway I've now written more about a song I haven't recommended than the one I didâ€¦
Remind (1993)
Remind by Orbital
From the Brown Album, I first heard this as the Encore from their "final show", for John Peel, when they split up in 2004. "Remind" wasn't broadcast, but an audience recording was circulated on fan site Loopz. Remarkably, 21 years on, it's still there.

In writing this I discovered that it's a re-working of a remix Orbital did for Meat Beat Manifesto: MindStream (Mind The Bend The Mind)
You Lot (2004)

From the unfairly-maligned "final" Blue album. Featuring a sample of pre-Doctor Who Christoper Eccleston, from another Russell T Davies production, Second Coming.
Beached (2000)
Beached (Long version) by Orbital, Angelo Badalamenti
Co-written by Angelo Badalamenti, it's built around a sample of Badalamenti's score for the movie "The Beach". Orbital's re-work adds some grit to the orchestral instrumentation and opens with a monologue, delivered by Leonardo Di Caprio, sampled from the movie.
Spare Parts Express (1999)
Spare Parts Express by Orbital
Critics had started to be quite unfair to Orbital by this point. The band themselves said that they'd ran out of ideas (pointing at album closer "Style", built around a Stylophone melody, as proof). Their malaise continued right up to the Blue Album, at which point the split up; ostensibly for good, before regrouping 8 years later.

Spare Parts Express is a hatchet job of various bits that they didn't develop into full songs on their own. Despite this I think it works. I love long-form electronica, and this clocks in at 10:07. My favourite segment (06:37) is adjacent to a reference (05:05) to John Baker's theme for the BBC children's program Newsround (sadly they aren't using it today. Here's a rundown of Newsround themes over time)
Attached (1994)
Attached by Orbital
This originally debuted on a Peel session before appearing on the subsequent album Snivilisation a few months later. An album closer, and a good come-down song to close this list.

14 May, 2025 10:41AM

Evgeni Golov

running modified containers with podman

Everybody (who runs containers) knows this situation: you've been running happycontainer:stable for a while and it's been great but now something external changed and you need to adjust the code while there is still no release with the patch.

I've encountered exactly this when our Home-Assistant stopped showing the presence of our cat correctly, but we've also been discussing this at work recently.

Now the most obvious (to me?) solution would be to build a new container, based on the original one, and perform the modifications at build time. Something like this:

FROM happycontainer:stable
RUN curl â€¦ | patch -p1

But that's not interactive, and if you don't have a patch readily available, that's not what you want. (And I'll save you the idea of RUNing sed and friends to alter files!)

You could run vim inside the container, but that requires vim to be installed there in the first place. And a reasonable configuration. Andâ€¦

Well, turns out podman can mount the root fs of a running container.

[root@sai ~]# podman mount homeassistant
/var/lib/containers/storage/overlay/f3ac502d97b5681989dff

And if you're running as non-root, you'll get an error:

[container@sai ~]$ podman mount homeassistant
Error: cannot run command "podman mount" in rootless mode, must execute `podman unshare` first

Luckily the solution is in the error message - use podman unshare

[container@sai ~]$ podman unshare
[root@sai ~]# podman mount homeassistant
/home/container/.local/share/containers/storage/overlay/95d3809d53125e4d40ad05e52efaa5a48e6e61fe9b8a8478416ff44459c7eb31/merged

So in both cases (root and rootless) we get a path, which is the mounted root fs and we can edit things in there as we like.

[root@sai ~]# vi /home/container/.local/share/containers/storage/overlay/95d3809d53125e4d40ad05e52efaa5a48e6e61fe9b8a8478416ff44459c7eb31/merged/usr/src/homeassistant/homeassistant/components/surepetcare/binary_sensor.py

Once done, the container can be unmounted again, and the namespace left

[root@sai ~]# podman umount homeassistant
homeassistant
[root@sai ~]# exit
[container@sai ~]$

At this point we have modified the code inside the container, but the running process is still using the old code. If we restart the container now to restart the process, our changes will be lost.

Instead, we can commit the changes as a new layer and tag the result.

[container@sai ~]$ podman commit homeassistant docker.io/homeassistant/home-assistant:stable

And now, when we restart the container, it will use the new code with our changes ðŸŽ‰

[container@sai ~]$ systemctl --user restart homeassistant

Is this the best workflow you can get? Probably not. Does it work? Hell yeah!

14 May, 2025 08:54AM by evgeni

Ben Hutchings

Report for Debian BSP near Leuven in April 2025

On 26th and 27th April we held a Debian bug-squashing party near Leuven, Belgium. Several longstanding and new Debian contributors gathered to work through some of the highest priority bugs affecting the upcoming release of Debian 13 “trixie”.

We were hosted by the Familia community centre in Tildonk. As this venue currently does not have an Internet connection, we brought a mobile hotspot and a local Debian mirror.

In attendance were:

Debian Developers: Ben Hutchings, Nattie Mayer-Hutchings, Kurt Roeckx, and Geert Stappers
New contributors: Yüce Kürüm, Louis Renuart, Arnout Vandecappelle

The new contributors were variously using Arch, Fedora, and Ubuntu, and the DDs spent some some time setting them up with Debian dvelopment environments.

The bugs we worked on included:

#994510: libunwind8 abuses setcontext() causing SIGSEGV on i386 with glibc >= 2.32: Kurt added a patch, though it seems that a different change is needed.
#1016936: dwz: Unknown debugging section .debug_addr causes some builds to fail: Ben reduced the severity.
#1063664: gcc-13-cross: file conflicts between gnat-13-<triplet> and gnat-{9,10}-<triplet>: Kurt looked at this and questioned the explanation for reopening this bug.
#1060960: libslf4j-java: FTBFS: make: *** [debian/rules:4: build] Error 25: Ben identified that there have been 2 separate test regressions, and added a patch for the first of them.
#1064003: src:cross-toolchain-base: unsatisfied build dependency in testing: linux-source-6.5 (>= 6.5.8): Ben closed this as already fixed.
#1072167: grub-pc-dbg: newly-added symbol file “…” does not provide any symbols: Ben reproduced this and added a patch.
#1076350: Segfault with shared libuv on x86 (CVE-2025-47153): Kurt asked the maintainer for clarification of the status.
#1078608: apt update silently leaves old index data: Ben reproduced this (again), and identified that it may be triggered by PackageKit.
#1089192: golang-golang-x-net: FTBFS: FAIL: TestNumICANNRules: Yüce looked at this and wrote a patch. However, the maintainers took a different approach to fix this.
#1089432: shim: Supporting rootless builds by default: Kurt asked the maintainer for a status update.
#1091668: debian-installer: Explicitly declare requirement for root: Louis and Kurt looked at this. Kurt asked the maintainer for clarification of the status.
#1084066: amdgcn-tools: Please upgrade build-dep to llvm/clang 18 or 19 and #1092643: llvm-toolchain-19: readd gcn targets: Kurt and Arnout looked at these. Arnout added information about the build failure, the relevant upstream changes, and an upstream bug report.
#1095376: refpolicy: FTBFS: make[2]: *** [Rules.modular:230: validate] Segmentation fault: Arnout looked at this and was not able to reproduce it, but noted that it may actually be caused by a bug in swig.
#1093160: rsync: failed verification – update discarded: Ben reduced the severity.
#1099013: emacs-gtk: hangs compositor when used under Wayland: Louis did a lot of work to reproduce this, but the bug was not reproducible.
#1104169: wish: adduser _radvd on new installs and #1104229: wish: add systemd unit: Geert worked on and committed fixes for these bugs.
#1100699: screen: hardcopy and screen-exchange are insecure by default: Yüce and Ben looked at this. Ben started a discussion of what changes would be appropriate to fix it.
#1100981: libmlir-19 fails to coinstall: Arnout and Kurt looked at this, and pointed out an existing MR that should fix it and some other packages that are similarly affected.

13 May, 2025 08:19PM by Ben Hutchings

Reproducible Builds

Reproducible Builds in April 2025

Welcome to our fourth report from the Reproducible Builds project in 2025. These monthly reports outline what we’ve been up to over the past month, and highlight items of news from elsewhere in the increasingly-important area of software supply-chain security. Lastly, if you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website.

Table of contents:

reproduce.debian.net

The last few months have seen the introduction, development and deployment of reproduce.debian.net. In technical terms, this is an instance of rebuilderd, our server designed monitor the official package repositories of Linux distributions and attempt to reproduce the observed results there.

This month, however, we are pleased to announce that reproduce.debian.net now tests all the Debian trixie architectures except s390x and mips64el.

The ppc64el architecture was added through the generous support of Oregon State University Open Source Laboratory (OSUOSL), and we can support the armel architecture thanks to CodeThink.

Fifty Years of Open Source Software Supply Chain Security

Russ Cox has published a must-read article in ACM Queue on Fifty Years of Open Source Software Supply Chain Security. Subtitled, “For decades, software reuse was only a lofty goal. Now it’s very real.”, Russ’ article goes on to outline the history and original goals of software supply-chain security in the US military in the early 1970s, all the way to the XZ Utils backdoor of 2024. Through that lens, Russ explores the problem and how it has changed, and hasn’t changed, over time.

He concludes as follows:

We are all struggling with a massive shift that has happened in the past 10 or 20 years in the software industry. For decades, software reuse was only a lofty goal. Now it’s very real. Modern programming environments such as Go, Node and Rust have made it trivial to reuse work by others, but our instincts about responsible behaviors have not yet adapted to this new reality.

We all have more work to do.

4th CHAINS Software Supply Chain Workshop

Convened as part of the CHAINS research project at the KTH Royal Institute of Technology in Stockholm, Sweden, the 4th CHAINS Software Supply Chain Workshop occurred during April. During the workshop, there were a number of relevant workshops, including:

Signature, Attestations and Reproducible Builds
Does Functional Package Management Enable Reproducible Builds at Scale?
Causes and Mitigations of Unreproducible Builds in Java [paper]
Fixing Breaking Dependency Updates Using LLMs
The caveats of vulnerability analysis
maven-lockfile (Lockfiles for Java and Maven)
observer (Generating SBOMs for C/C++)
dirty-waters (Transparency checks for software supply chains)
A supply chain competition. Martin Schwaighofer, the winner, created a recap video (20m43s).
Finally, 8 posters on dependency introspection, diverse double compilation, dependency management, VEX and SBOM.

The full listing of the agenda is available on the workshop’s website.

Mailing list updates

On our mailing list this month:

Luca DiMaio of Chainguard posted to the list reporting that they had successfully implemented reproducible filesystem images with both ext4 and an EFI system partition. They go on to list the various methods, and the thread generated at least fifteen replies.
David Wheeler announced that the OpenSSF is building a “glossary” of sorts in order that they “consistently use the same meaning for the same term” and, moreover, that they have drafted a definition for ‘reproducible build’. The thread generated a significant number of replies on the definition, leading to a potential update to the Reproducible Build’s own definition.
Lastly, kpcyrd posted to the list with a timely reminder and update on their repro-env” tool. As first reported in our July 2023 report, kpcyrd mentions that:

My initial interest in reproducible builds was “how do I distribute pre-compiled binaries on GitHub without people raising security concerns about them”. I’ve cycled back to this original problem about 5 years later and built a tool that is meant to address this. […]

Canonicalization for Unreproducible Builds in Java

Aman Sharma, Benoit Baudry and Martin Monperrus have published a new scholarly study related to reproducible builds within Java. Titled Canonicalization for Unreproducible Builds in Java, the article’s abstract is as follows:

[…] Achieving reproducibility at scale remains difficult, especially in Java, due to a range of non-deterministic factors and caveats in the build process. In this work, we focus on reproducibility in Java-based software, archetypal of enterprise applications. We introduce a conceptual framework for reproducible builds, we analyze a large dataset from Reproducible Central and we develop a novel taxonomy of six root causes of unreproducibility. We study actionable mitigations: artifact and bytecode canonicalization using OSS-Rebuild and jNorm respectively. Finally, we present Chains-Rebuild, a tool that raises reproducibility success from 9.48% to 26.89% on 12,283 unreproducible artifacts. To sum up, our contributions are the first large-scale taxonomy of build unreproducibility causes in Java, a publicly available dataset of unreproducible builds, and Chains-Rebuild, a canonicalization tool for mitigating unreproducible builds in Java.

A full PDF of their article is available from arXiv.

OSS Rebuild adds new TUI features

OSS Rebuild aims to automate rebuilding upstream language packages (e.g. from PyPI, crates.io and npm registries) and publish signed attestations and build definitions for public use.

OSS Rebuild ships a text-based user interface (TUI) for viewing, launching, and debugging rebuilds. While previously requiring ownership of a full instance of OSS Rebuild’s hosted infrastructure, the TUI now supports a fully local mode of build execution and artifact storage. Thanks to Giacomo Benedetti for his usage feedback and work to extend the local-only development toolkit.

Another feature added to the TUI was an experimental chatbot integration that provides interactive feedback on rebuild failure root causes and suggests fixes.

Distribution roundup

In Debian this month:

Roland Clobus posted another status report on reproducible ISO images on our mailing list this month, with the summary that “all live images build reproducibly from the online Debian archive”.
Debian developer Simon Josefsson published another two reproducibility-related blog posts this month, the first on the topic of Verified Reproducible Tarballs. Simon sardonically challenges the reader as follows: “Do you want a supply-chain challenge for the Easter weekend? Pick some well-known software and try to re-create the official release tarballs from the corresponding Git checkout. Is anyone able to reproduce anything these days?” After that, they also published a blog post on Building Debian in a GitLab Pipeline using their multi-stage rebuild approach.
Roland also posted to our mailing list to highlight that “there is now another tool in Debian that generates reproducible output, equivs”. This is a tool to create trivial Debian packages that might Depend on other packages. As Roland writes, “building the [equivs] package has been reproducible for a while, [but] now the output of the [tool] has become reproducible as well”.
Lastly, 9 reviews of Debian packages were added, 10 were updated and 10 were removed this month adding to our extensive knowledge about identified issues.

The IzzyOnDroid Android APK repository made more progress in April. Thanks to funding by NLnet and Mobifree, the project was also to put more time into their tooling. For instance, developers can now easily run their own verification builder in “less than 5 minutes”. This currently supports Debian-based systems, but support for RPM-based systems is incoming.

The rbuilder_setup tool can now setup the entire framework within less than five minutes. The process is configurable, too, so everything from “just the basics to verify builds” up to a fully-fledged RB environment is also possible.
This tool works on Debian, RedHat and Arch Linux, as well as their derivates. The project has received successful reports from Debian, Ubuntu, Fedora and some Arch Linux derivates so far.
Documentation on how to work with reproducible builds (making apps reproducible, debugging unreproducible packages, etc) is available in the project’s wiki page.
Future work is also in the pipeline, including documentation, guidelines and helpers for debugging.

NixOS defined an Outreachy project for improving build reproducibility. In the application phase, NixOS saw some strong candidates providing contributions, both on the NixOS side and upstream: guider-le-ecit analyzed a libpinyin issue. Tessy James fixed an issue in arandr and helped analyze one in libvlc that led to a proposed upstream fix. Finally, 3pleX fixed an issue which was accepted in upstream kitty, one in upstream maturin, one in upstream python-sip and one in the Nix packaging of python-libbytesize. Sadly, the funding for this internship fell through, so NixOS were forced to abandon their search.

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

diffoscope & strip-nondeterminism

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 a number of versions to Debian:

Use the --walk argument over the potentially dangerous alternative --scan when calling out to zipdetails(1). […]
Correct a longstanding issue where many >-based version tests used in conditional fixtures were broken. This was used to ensure that specific tests were only run when the version on the system was newer than a particular number. Thanks to Colin Watson for the report (Debian bug #1102658) […]
Address a long-hidden issue in the test_versions testsuite as well, where we weren’t actually testing the greater-than comparisons mentioned above, as it was masked by the tests for equality. […]
Update copyright years. […]

In strip-nondeterminism, however, Holger Levsen updated the Continuous Integration (CI) configuration in order to use the standard Debian pipelines via debian/salsa-ci.yml instead of using .gitlab-ci.yml. […]

Website updates

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

Aman Sharma added OSS-Rebuild’s stabilize tool to the Tools page. […][…]
Chris Lamb added a configure.ac (GNU Autotools) example for using SOURCE_DATE_EPOCH. […]. Chris also updated the SOURCE_DATE_EPOCH snippet and move the archive metadata to a more suitable location. […]
Denis Carikli added GNU Boot to our ever-evolving Projects page.

Reproducibility testing framework

The Reproducible Builds project operates a comprehensive testing framework running primarily at tests.reproducible-builds.org in order to check packages and other artifacts for reproducibility. In April, a number of changes were made by Holger Levsen, including:

reproduce.debian.net-related:
- Add armel.reproduce.debian.net to support the armel architecture. […][…]
- Add a new ARM node, codethink05. […][…]
- Add ppc64el.reproduce.debian.net to support testing of the ppc64el architecture. […][…][…]
- Improve the reproduce.debian.net front page. […][…]
- Make various changes to the ppc64el nodes. […][…]9[…][…]
- Make various changes to the arm64 and armhf nodes. […][…][…][…]
- Various changes related to the rebuilderd-worker entry point. […][…][…]
- Create and deploy a pkgsync script. […][…][…][…][…][…][…][…]
- Fix the monitoring of the riscv64 architecture. […][…]
- Make a number of changes related to starting the rebuilderd service. […][…][…][…]
Backup-related:
- Backup the rebuilder databases every week. […][…][…][…]
- Improve the node health checks. […][…]
Misc:
- Re-use existing connections to the SSH proxy node on the riscv64 nodes. […][…]
- Node maintenance. […][…][…]

In addition:

Jochen Sprickerhof fixed the risvc64 host names […] and requested access to all the rebuilderd nodes […].
Mattia Rizzolo updated the self-serve rebuild scheduling tool, replacing the deprecated “SSO”-style authentication with OpenIDC which authenticates against salsa.debian.org. […][…][…]
Roland Clobus updated the configuration for the osuosl3 node to designate 4 workers for bigger builds. […]

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
- lout
- mpiP
- libabigail
- cython
- mpiP
- godot
- gnome-text-editor
- clisp
- rpm
- Fiona
- qtdoc
Chris Hofstaedtler:
- #1104512 filed against command-not-found.
- #1104517 filed against command-not-found.
- #1104535 filed against cc65.
Chris Lamb:
- #1102659 filed against vcsh.
- #1103797 filed against schism.
- #1103798 filed against magic-wormhole-mailbox-server.
- #1103800 filed against openvpn3-client.
James Addison:
- #1102760 filed against apg.
Jochen Sprickerhof:
- #1103288 filed against courier.
- #1103563 filed against cross-toolchain-base.

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

IRC: #reproducible-builds on irc.oftc.net.
Mastodon: @reproducible_builds@fosstodon.org
Mailing list: rb-general@lists.reproducible-builds.org

12 May, 2025 07:00PM

Sergio Durigan Junior

Debian Bug Squashing Party Brazil 2025

With the trixie release approaching, I had the idea back in April to organize a bug squashing party with the Debian Brasil community. I believe the outcome was very positive, and we were able to tackle and fix quite a number of release-critical bugs. This is a brief report of what we did.

A remote BSP

It’s not the first time I organize a BSP: back in 2019, I helped throw another similar party in Toronto. The difference this time is that, because Brazil is a big country and (perhaps most importantly) because I’m not currently living there, the BSP had to be done online.

I’m a fan of social interactions (especially with the Brazilian community), and in my experience we usually can achieve much more when we get together in a physical place, but hey, you gotta do what you gotta do…

Most (if not all) of the folks interested in participating had busy weekdays, so it was decided that we would meet during the weekends and try to work on a few bugs over Jitsi. Nothing stopped people from working on bugs during the week as well, of course.

A tag to rule them all

We used the bsp-2025-04-brazil usertag to mark those bugs that were touched by us. You can see the full list of bugs here, although the current list (as of 2025-05-11) is smaller than the one we had by the end of April. I don’t know what happened; maybe it’s some glitch with the BTS, or maybe someone removed the usertag by mistake.

Stats

In total, we had:

7 participants
37 bugs handled. Of those,
35 bugs fixed

The BSP officially started on 04 April 2025, and ended on 30 April 2025. I was able to attend meetings during two weekends; other people participated more sporadically.

Outcome

As I said above, the Debian Brasil community is great and very engaged in the project. Speaking more specifically about the Debian Brasil Devel group, I can say that We have contributors with strong technical skills, and I really love that we have this inclusive, extremely technical culture where debugging and understanding things is really core to pretty much all our discussions.

We already meet weekly on Thursdays to talk shop and help newcomers, so having a remote BSP with this group seemed like a logical thing to do. I’m really glad to see our results and even happier to hear positive feedback from the community during the last MiniDebConf in MaceiÃ³.

There’s some interest in organizing another BSP, this time face-to-face and during the next DebConf. I’m all for it, as I love fixing bugs and having a great time with friends. If you’re interested in attending, let me know.

Thanks, and until next time.

11 May, 2025 10:00PM

Bits from Debian

Bits from the DPL

Dear Debian community,

This is bits from the DPL for April.

End of 10

I am sure I was speaking in the interest of the whole project when joining the "End of 10" campaign. Here is what I wrote to the initiators:

Hi Joseph and all drivers of the "End of 10" campaign, On behalf of the entire Debian project, I would like to say that we proudly join your great campaign. We stand with you in promoting Free Software, defending users' freedoms, and protecting our planet by avoiding unnecessary hardware waste. Thank you for leading this important initiative.

Andreas Tille Debian Project Leader

I have some goals I would like to share with you for my second term.

Ftpmaster delegation

This splits up into tasks that can be done before and after Trixie release.

Before Trixie:

⁣1. Reducing Barriers to DFSG Compliance Checks

Back in 2002, Debian established a way to distribute cryptographic software in the main archive, whereas such software had previously been restricted to the non-US archive. One result of this arrangement which influences our workflow is that all packages uploaded to the NEW queue must remain on the server that hosts it. This requirement means that members of the ftpmaster team must log in to that specific machine, where they are limited to a restricted set of tools for reviewing uploaded code.

This setup may act as a barrier to participation--particularly for contributors who might otherwise assist with reviewing packages for DFSG compliance. I believe it is time to reassess this limitation and work toward removing such hurdles.

In October last year, we had some initial contact with SPI's legal counsel, who noted that US regulations around cryptography have been relaxed somewhat in recent years (as of 2021). This suggests it may now be possible to revisit and potentially revise the conditions under which we manage cryptographic software in the NEW queue.

I plan to investigate this further. If you have expertise in software or export control law and are interested in helping with this topic, please get in touch with me.

The ultimate goal is to make it easier for more people to contribute to ensuring that code in the NEW queue complies with the DFSG.

⁣2. Discussing Alternatives

My chances to reach out to other distributions remained limited. However, regarding the processing of new software, I learned that OpenSUSE uses a Git-based workflow that requires five "LGTM" approvals from a group of trusted developers. As far as I know, Fedora follows a similar approach.

Inspired by this, a recent community initiative--the Gateway to NEW project--enables peer review of new packages for DFSG compliance before they enter the NEW queue. This effort allows anyone to contribute by reviewing packages and flagging potential issues in advance via Git. I particularly appreciate that the DFSG review is coupled with CI, allowing for both license and technical evaluation.

While this process currently results in some duplication of work--since final reviews are still performed by the ftpmaster team--it offers a valuable opportunity to catch issues early and improve the overall quality of uploads. If the community sees long-term value in this approach, it could serve as a basis for evolving our workflows. Integrating it more closely into DAK could streamline the process, and we've recently seen that merge requests reflecting community suggestions can be accepted promptly.

For now, I would like to gather opinions about how such initiatives could best complement the current NEW processing, and whether greater consensus on trusted peer review could help reduce the burden on the team doing DFSG compliance checks. Submitting packages for review and automated testing before uploading can improve quality and encourage broader participation in safeguarding Debian's Free Software principles.

My explicit thanks go out to the Gateway to NEW team for their valuable and forward-looking contribution to Debian.

⁣3. Documenting Critical Workflows

Past ftpmaster trainees have told me that understanding the full set of ftpmaster workflows can be quite difficult. While there is some useful documentation − thanks in particular to Sean Whitton for his work on documenting NEW processing rules – many other important tasks carried out by the ftpmaster team remain undocumented or only partially so.

Comprehensive and accessible documentation would greatly benefit current and future team members, especially those onboarding or assisting in specific workflows. It would also help ensure continuity and transparency in how critical parts of the archive are managed.

If such documentation already exists and I have simply overlooked it, I would be happy to be corrected. Otherwise, I believe this is an area where we need to improve significantly. Volunteers with a talent for writing technical documentation are warmly invited to contact me--I'd be happy to help establish connections with ftpmaster team members who are willing to share their knowledge so that it can be written down and preserved.

Once Trixie is released (hopefully before DebConf):

⁣4. Split of the Ftpmaster Team into DFSG and Archive Teams

As discussed during the "Meet the ftpteam" BoF at DebConf24, I would like to propose a structural refinement of the current Ftpmaster team by introducing two different delegated teams:

DFSG Team
Archive Team (responsible for DAK maintenance and process tooling, including releases)

(Alternative name suggestions are, of course, welcome.) The primary task of the DFSG team would be the processing of the NEW queue and ensuring that packages comply with the DFSG. The Archive team would focus on maintaining DAK and handling the technical aspects of archive management.

I am aware that, in the recent past, the ftpmaster team has decided not to actively seek new members. While I respect the autonomy of each team, the resulting lack of a recruitment pipeline has led to some friction and concern within the wider community, including myself. As Debian Project Leader, it is my responsibility to ensure the long-term sustainability and resilience of our project, which includes fostering an environment where new contributors can join and existing teams remain effective and well-supported. Therefore, even if the current team does not prioritize recruitment, I will actively seek and encourage new contributors for both teams, with the aim of supporting openness and collaboration.

This proposal is not intended as criticism of the current team's dedication or achievements--on the contrary, I am grateful for the hard work and commitment shown, often under challenging circumstances. My intention is to help address the structural issues that have made onboarding and specialization difficult and to ensure that both teams are well-supported for the future.

I also believe that both teams should regularly inform the Debian community about the policies and procedures they apply. I welcome any suggestions for a more detailed description of the tasks involved, as well as feedback on how best to implement this change in a way that supports collaboration and transparency.

My intention with this proposal is to foster a more open and effective working environment, and I am committed to working with all involved to ensure that any changes are made collaboratively and with respect for the important work already being done.

I'm aware that the ideas outlined above touch on core parts of how Debian operates and involve responsibilities across multiple teams. These are not small changes, and implementing them will require thoughtful discussion and collaboration.

To move this forward, I've registered a dedicated BoF for DebConf. To make the most of that opportunity, I'm looking for volunteers who feel committed to improving our workflows and processes. With your help, we can prepare concrete and sensible proposals in advance--so the limited time of the BoF can be used effectively for decision-making and consensus-building.

In short: I need your help to bring these changes to life. From my experience in my last term, I know that when it truly matters, the Debian community comes together--and I trust that spirit will guide us again.

Please also note: we had a "Call for volunteers" five years ago, and much of what was written there still holds true today. I've been told that the response back then was overwhelming--but that training such a large number of volunteers didn't scale well. This time, I hope we can find a more sustainable approach: training a few dedicated people first, and then enabling them to pass on their knowledge. This will also be a topic at the DebCamp sprint.

Dealing with Dormant Packages

Debian was founded on the principle that each piece of software should be maintained by someone with expertise in it--typically a single, responsible maintainer. This model formed the historical foundation of Debian's packaging system and helped establish high standards of quality and accountability. However, as the project has grown and the number of packages has expanded, this model no longer scales well in all areas. Team maintenance has since emerged as a practical complement, allowing multiple contributors to share responsibility and reduce bottlenecks--depending on each team's internal policy.

While working on the Bug of the Day initiative, I observed a significant number of packages that have not been updated in a long time. In the case of team-maintained packages, addressing this is often straightforward: team uploads can be made, or the team can be asked whether the package should be removed. We've also identified many packages that would fit well under the umbrella of active teams, such as language teams like Debian Perl and Debian Python, or blends like Debian Games and Debian Multimedia. Often, no one has taken action--not because of disagreement, but simply due to inattention or a lack of initiative.

In addition, we've found several packages that probably should be removed entirely. In those cases, we've filed bugs with pre-removal warnings, which can later be escalated to removal requests.

When a package is still formally maintained by an individual, but shows signs of neglect (e.g., no uploads for years, unfixed RC bugs, failing autopkgtests), we currently have three main tools:

The MIA process, which handles inactive or unreachable maintainers.
Package Salvaging, which allows contributors to take over maintenance if conditions are met.
Non-Maintainer Uploads (NMUs), which are limited to specific, well-defined fixes (which do not include things like migration to Salsa).

These mechanisms are important and valuable, but they don't always allow us to react swiftly or comprehensively enough. Our tools for identifying packages that are effectively unmaintained are relatively weak, and the thresholds for taking action are often high.

The Package Salvage team is currently trialing a process we've provisionally called "Intend to NMU" (ITN). The name is admittedly questionable--some have suggested alternatives like "Intent to Orphan"--and discussion about this is ongoing on debian-devel. The mechanism is intended for situations where packages appear inactive but aren't yet formally orphaned, introducing a clear 21-day notice period before NMUs, similar in spirit to the existing ITS process. The discussion has sparked suggestions for expanding NMU rules.

While it is crucial not to undermine the autonomy of maintainers who remain actively involved, we also must not allow a strict interpretation of this autonomy to block needed improvements to obviously neglected packages.

To be clear: I do not propose to change the rights of maintainers who are clearly active and invested in their packages. That model has served us well. However, we must also be honest that, in some cases, maintainers stop contributing--quietly and without transition plans. In those situations, we need more agile and scalable procedures to uphold Debian's high standards.

To that end, I've registered a BoF session for DebConf25 to discuss potential improvements in how we handle dormant packages. These discussions will be prepared during a sprint at DebCamp, where I hope to work with others on concrete ideas.

Among the topics I want to revisit is my proposal from last November on debian-devel, titled "Barriers between packages and other people". While the thread prompted substantial discussion, it understandably didn't lead to consensus. I intend to ensure the various viewpoints are fairly summarised--ideally by someone with a more neutral stance than myself--and, if possible, work toward a formal proposal during the DebCamp sprint to present at the DebConf BoF.

My hope is that we can agree on mechanisms that allow us to act more effectively in situations where formerly very active volunteers have, for whatever reason, moved on. That way, we can protect both Debian's quality and its collaborative spirit.

Building Sustainable Funding for Debian

Debian incurs ongoing expenses to support its infrastructure--particularly hardware maintenance and upgrades--as well as to fund in-person meetings like sprints and mini-DebConfs. These investments are essential to our continued success: they enable productive collaboration and ensure the robustness of the operating system we provide to users and derivative distributions around the world.

While DebConf benefits from generous sponsorship, and we regularly receive donated hardware, there is still considerable room to grow our financial base--especially to support less visible but equally critical activities. One key goal is to establish a more constant and predictable stream of income, helping Debian plan ahead and respond more flexibly to emerging needs.

This presents an excellent opportunity for contributors who may not be involved in packaging or technical development. Many of us in Debian are engineers first--and fundraising is not something we've been trained to do. But just like technical work, building sustainable funding requires expertise and long-term engagement.

If you're someone who's passionate about Free Software and has experience with fundraising, donor outreach, sponsorship acquisition, or nonprofit development strategy, we would deeply value your help. Supporting Debian doesn't have to mean writing code. Helping us build a steady and reliable financial foundation is just as important--and could make a lasting impact.

Kind regards Andreas.

PS: In April I also planted my 5000th tree and while this is off-topic here I'm proud to share this information with my fellow Debian friends.

11 May, 2025 10:00PM by Andreas Tille

Dirk Eddelbuettel

RcppSMC 0.2.8 on CRAN: Maintenance

Release 0.2.8 of our RcppSMC package arrived at CRAN yesterday. RcppSMC provides Rcpp-based bindings to R for the Sequential Monte Carlo Template Classes (SMCTC) by Adam Johansen described in his JSS article. Sequential Monte Carlo is also referred to as Particle Filter in some contexts. The package now also features the Google Summer of Code work by Leah South in 2017, and by Ilya Zarubin in 2021.

This release is somewhat procedural and contains solely maintenance, either for items now highlighted by the R and CRAN package checks, or to package internals. We had made those changes at the GitHub repo over time since the last release two years ago, and it seemed like a good time to get them to CRAN now.

The release is summarized below.

Changes in RcppSMC version 0.2.8 (2025-05-10)

Updated continuous integration script

Updated package metadata now using Authors@R

Corrected use of itemized list in one manual page

Courtesy of my CRANberries, there is also a diffstat report detailing changes. More information is on the RcppSMC page and the repo. Issues and bugreports should go to the GitHub issue tracker.

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

11 May, 2025 04:25PM

Uwe Kleine-König

The Linux kernel's PGP Web of Trust

The Linux kernel's development process makes use of PGP. The most relevant part here is that subsystem maintainers are supposed to use signed tags in their pull requests to Linus Torvalds. As the concept of keyservers is considered broken, Konstantin Ryabitsev maintains a collection of relevant keys in a git repository.

As of today (at commit a0bc65fb27f5033beddf9d1ad97d67c353849be2) there are 602 valid keys tracked in that repository. The requirement for a key to be added there is that there must be at least one trust path from Linus Torvalds' key to this key of length at most 5 within that keyring.

Occasionally it happens that a key loses its trust paths because someone in these paths replaced their key, or keys expired. Currently this affects 2 keys.

However there is a problem on the horizon: GnuPG 2.4.x started to reject third-party key signatures using the SHA-1 hash algorithm. In general that's good, SHA-1 isn't considered secure any more for more than 20 years. This doesn't directly affect the kernel-pgpkeys repo, because the trust path checking doesn't rely on GnuPG trusting the signatures; there is a dedicated tool that parses the keyring contents and currently accepts signatures using SHA-1. Also signatures are not thrown away usually, but there are exceptions: Recently Theodore Ts'o asked to update his certificate. When Konstantin imported the updated certificate GnuPG's "cleaning" was applied which dropped all SHA-1 signatures. So Theodore Ts'o's key lost 168 signatures, among them one by Linus Torvalds on his primary UID.

That made me wonder what would be the effect on the web of trust if all SHA-1 signatures were dropped. Here are the facts:

There are 7976 signatures tracked in the korg-pgpkeys repo that are considered valid, 6045 of them use SHA-1.
Only considering the primary UID Linus Torvalds directly signed 40 public keys, 38 of these using SHA-1. One of the two keys that is still "properly" signed, doesn't sign any other key. So nearly all trust paths go through a single key.
When not considering SHA-1 signatures there are 485 public keys without a trust path from Linus Torvalds of length 5 or less. So today these 485 public keys would not qualify to be added to the pgpkeys git repository. Among the people being dropped are Andrew Morton, Greg Kroah-Hartman, H. Peter Anvin, Ingo Molnar, Junio C Hamano, Konstantin Ryabitsev, Peter Zijlstra, Stephen Rothwell and Thomas Gleixner.
The size of the kernel strong set is reduced from 358 to 94.

If you attend Embedded Recipes 2025 next week, there is an opportunity to improve the situation: Together with Ahmad Fatoum I'm organizing a keysigning session. If you want to participate, send your public key to er2025-keysigning@baylibre.com before 2025-05-12 08:00 UTC.

09 May, 2025 07:29PM

Dirk Eddelbuettel

RcppSpdlog 0.0.22 on CRAN: New Upstream

Version 0.0.22 of RcppSpdlog arrived on CRAN today and has been uploaded to Debian. RcppSpdlog bundles spdlog, a wonderful header-only C++ logging library with all the bells and whistles you would want that was written by Gabi Melman, and also includes fmt by Victor Zverovich. You can learn more at the nice package documention site.

This release updates the code to the version 1.15.3 of spdlog which was released this morning, and includes version 1.12.0 of fmt.

The NEWS entry for this release follows.

Changes in RcppSpdlog version 0.0.22 (2025-05-09)

Upgraded to upstream release spdlog 1.15.3 (including fmt 11.2.0)

Courtesy of my CRANberries, there is also a diffstat report detailing changes. More detailed information is on the RcppSpdlog page, or the package documention site.

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

09 May, 2025 06:55PM

Abhijith PA

Bug squashing party, Kochi

Last weekend, 4 people (3 DDs and 1 soon to be, hopefully in coming months) sit together for a Bug squashing party in Kochi. We fixed lot of things including my broken autopkgtest setup.

BSP-Kochi

It all began from a discussion in #debian-in of not having any BSPs in the past in India. Then twisted in to hosting a BSP by me. I fixed the dates to 3rd & 4th May to get packages migrate naturally to testing with NMUs before the hard freeze on 15th May.

Finding a venue was a huge challenge. Unlike other places, we have very limited options on hackerspaces. We also had some company spaces (if we asked), but we may have to follow their office timings and finding accommodation near by was also a challenge.

Later we decided to go with a rental apartment where could hack all night and sleep. We booked a very bare minimal apartment for 3 nights and 3 days. I updated wiki page and sent announcement.

Not even Wi-Fi was there in the apartment, so we setup everything by ourselves (DebConf style :p ). I short listed some newbie bugs, just in case if newcomers joined the party. But it was only we 4 people and Kathara who joined remotely.

We started from May 2nd night, stacked our cabin with snacks, instant noodles and drinks. Arranged beds, tables and started hacking and having discussions. My autopkgtest-lxc setup was broken. I think its related to #1017753, which got fixed magically and now I started using autopkgtest-podman.

stack

I learned

reportbug tool can use its own SMTP server by default
autoremovals can be extended if we pinged to the bug report.

On last day, we went to a nice restaurant and had food. There was a church festival nearby, so we were able to watch wonderful procession and fireworks at night.

food

All in all we managed to touch 46 bugs of which 35 is now fixed/done and 11 is open, some of this get status done when it reaches testing. It was a fun and productive weekend. More importantly we had fun.

09 May, 2025 04:46PM

Thorsten Alteholz

My Debian Activities in April 2025

Debian LTS

This was my hundred-thirtieth month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian. During my allocated time I uploaded or worked on:

[DLA 4145-1] expat security update of one CVE related to a crash within XML_ResumeParser() because XML_StopParser() can stop/suspend an unstarted parser.
[DLA 4146-1] libxml2 security update to fix two CVEs related to an out-of-bounds memory access in the Python API and a heap-buffer-overflow.
[debdiff] sent libxml2 debdiff to maintainer for update of two CVEs in Bookworm.
[debdiff] sent libxml2 debdiff to maintainer for update of two CVEs in Unstable.

This month I did a week of FD duties. I also started to work on libxmltok. Adrian suggested to also check the CVEs that might affect the embedded version of expat. Unfortunately these are a bunch of CVEs to check and the month ended before the upload. I hope to finish this in May. Last but not least I continued to work on the second batch of fixes for suricata CVEs.

Debian ELTS

This month was the eighty-first ELTS month. During my allocated time I uploaded or worked on:

[ELA-1411-1] expat security update to fix one CVE in Stretch and Buster related to a crash within XML_ResumeParser() because XML_StopParser() can stop/suspend an unstarted parser.
[ELA-1412-1] libxml2 security update to fix two CVEs in Jessie, Stretch and Buster related to an out-of-bounds memory access in the Python API and a heap-buffer-overflow.

This month I did a week of FD duties.
I also started to work on libxmltok. Normally I work on machines running Bullseye or Bookworm. As the Stretch version of libxmltok needs a debhelper version of 5, which is no longer supported on Bullseye, I had to create a separate Buster VM. Yes, Stretch is becoming old. As well as with LTS I need to also check the CVEs that might affect the embedded version of expat.
Last but not least I started to work on the second batch of fixes for suricata CVEs.

Debian Printing

This month I uploaded new packages or new upstream or bugfix versions of:

… brlaser to fix a duplex related bug.
… ptouch-driver
… sane-airscan

This work is generously funded by Freexian!

misc

This month I uploaded new packages or new upstream or bugfix versions of:

bottlerocket was my first upload via debusine. It is a really cool tool and I can only recommend everybody to give it at least a try.
I finally filed an RM bug for siggen. I don’t think that fixing all the gcc-14 issues is really worth the hassle.

I finally filed an RM bug for siggen. I don’t think that fixing all the gcc-14 issues is really worth the hassle.

FTP master

This month I accepted 307 and rejected 55 packages. The overall number of packages that got accepted was 308.

08 May, 2025 12:05PM by alteholz

Feeds

June 05, 2025

June 04, 2025

Looking up AS numbers

Looking up IP blocks

Preventing comment submission

Future improvements

June 01, 2025

TL;DR:

Background and manual work

ASNs and networks

Introducing asncounter

The Huawei and Facebook blocks

A full asncounter run

phosh-mobile-settings

phosh-osk-stub / stevia

phosh-tour

phosh-osk-data

pfs

xdg-desktop-portal-phosh

phrog

phosh-debs

meta-phosh

feedbackd

feedbackd-device-themes

gmobile

GNOME calls

Debian

ModemManager

osmo-cbc

gsm-cell-testing

mobile-broadband-provider-info

Cellbroadcastd

phosh-site

pipewire

wireplumber

python-dbusmock

Bugs

Reviews

Help Development

Comments?

May 31, 2025

Focus

Changes

Issues

Sponsors

May 30, 2025

May 29, 2025

Changes in version 0.0.6 (2025-05-29)

Clients

Servers

Libraries

Gateways/Transports

Not in Trixie

A Broken Ecosystem

New Debian Kubernetes Team

De-vendorizing Kubernetes

Dependency Graph

Upstream Version 1.32.3 and Beyond

Integration Testing with Autopkgtest

Popcon: Measuring Adoption

Community and Documentation

Looking Ahead to Debian 13 (Trixie)

Final Thoughts

A Broken Ecosystem

New Debian Kubernetes Team

De-vendorizing Kubernetes

Dependency Graph

Upstream Version 1.32.3 and Beyond

Integration Testing with Autopkgtest

Popcon: Measuring Adoption

Community and Documentation

Looking Ahead to Debian 13 (Trixie)

Final Thoughts

May 28, 2025

Preliminaries

Creating and persisting a new mount namespace

Entering the namespace from another process

References

May 27, 2025