Deb.News

Daniel Pocock: Urgent : vérification du bien-être, appelez maintenant l’équipe féminine de football iranienne

Daniel Pocock — 2026-03-08T12:00:00+00:00

Comme cela a été largement médiatisé dans le monde entier, l'équipe féminine de football iranienne est actuellement en tournée en Australie .

Leur dernier match a lieu aujourd'hui, Journée internationale des femmes, après quoi elles seront placées dans un avion pour retourner en Iran .

Lors de leur premier match, ils ont refusé de chanter l'hymne national.

Lors de leur deuxième match, ils ont salué et chanté l'hymne national.

De nombreux experts ont constaté que ce changement de comportement était dû à un contrôle coercitif.

L'État du Queensland a été le premier État australien à légiférer sur le contrôle coercitif. La police a l'obligation de faire respecter la loi. La finale féminine se déroule au Queensland.

L'équipe de sécurité venue d'Iran loge à proximité des femmes dans le même hôtel. Selon la loi du Queensland, il s'agit d'une relation domestique. Les réservations d'hôtel et les accompagnateurs sont organisés pour les femmes. Elles ne peuvent se déplacer seules. Par conséquent, il s'agit d'une forme d'interdépendance domestique et la loi s'applique à chacune d'elles.

Lorsqu'elle est alertée d'une situation familiale, la police a l'obligation d'intervenir. À tout le moins, elle est tenue de vérifier le bien-être des personnes concernées. Elle n'interviendra que si ces personnes le lui demandent.

La télévision d'État iranienne a clairement affirmé que ces femmes étaient des « traîtresses de guerre ». Dans la plupart des cas de répression, les preuves de telles menaces sont dissimulées au public. Dans ce cas précis, les femmes qui s'expriment depuis l'étranger sont menacées de poursuites pénales pour trahison.

En 2013, le gouvernement travailliste australien de l'époque a publié une vidéo humiliant des demandeuses d'asile iraniennes .

J'ai adhéré au Parti travailliste australien (ALP) en 1997 et, lorsque j'ai vu la vidéo humiliant des femmes iraniennes , j'ai immédiatement démissionné. Ma lettre de démission a fuité et a été publiée par Crikey . Vous trouverez ci-dessous une copie intégrale du courriel.

Mon courriel de démission est soudainement devenu une preuve cruciale que le gouvernement australien cherche à dissuader les femmes iraniennes de demander l' asile politique . De ce fait, il est d'autant plus urgent que toute personne concernée contacte la police locale et lui demande de vérifier le bien-être de ces femmes.

Si vous pensez qu'une femme dans le Queensland est en danger de mort immédiat, composez le 000. Ce numéro fonctionne uniquement en Australie et ne doit être utilisé qu'en cas d'urgence.

Pour toute autre demande de vérification de bien-être, vous pouvez vous rendre dans un poste de police local ou appeler la police du Queensland au +61730556206 (à partir du site Web ).

Lorsqu'on s'adresse à la police, il est important de souligner les points suivants :

Les femmes se trouvent actuellement sous la juridiction de la police du Queensland.
Ils seront contraints de quitter le territoire dans les prochaines heures.
Ces femmes sont soumises à un arrangement domestique dans le cadre de leur réservation de voyage de groupe.
Ces femmes sont accompagnées partout où elles vont par un groupe d'hommes.
Leur refus de chanter l'hymne national lors du premier match est un signe qu'ils expriment silencieusement leur mécontentement et demandent de l'aide.
Leur changement de comportement, avec le salut national et le chant de l'hymne lors de leur deuxième match, indique qu'ils étaient soumis à des pressions pour les contraindre à retirer leur plainte, qu'ils avaient formulée par le silence.
Ces femmes ont fait l'objet d'une menace directe, diffusée sur la télévision d'État iranienne, laissant entendre qu'elles seraient persécutées pour trahison.
La vidéo produite par le gouvernement australien en juillet 2013 vise à exercer un contrôle coercitif, en dissuadant les femmes iraniennes d'exercer leurs droits en Australie, sous la menace d'humiliation publique.
Lors de la Coupe du monde féminine de la FIFA organisée en Australie, les autorités fédérales n'ont pas réagi au comportement du président espagnol du football, Luis Rubiales , malgré le fait que ses agissements aient été vus par tous à la télévision nationale. Il a pu prendre un avion et quitter l'Australie sans qu'aucune enquête ni poursuite ne soit engagée.
Il est essentiel que la police du Queensland ouvre un dossier officiel sur le risque encouru par chaque femme du groupe.
Il est essentiel que la police du Queensland effectue un contrôle de bien-être auprès de chaque femme du groupe.

Il n'y a pas si longtemps, en Suisse , j'ai rencontré le patron d'une des fédérations sportives iraniennes lors des Jeux olympiques d'hiver de la jeunesse :

Voici le courriel de démission lorsque le gouvernement du Parti travailliste australien (ALP) a humilié des femmes iraniennes avec une vidéo en juillet 2013 :

Sujet : Politique du Parti travailliste australien, fierté et horreurs du viol
Date : mardi 23 juillet 2013 23:44:17 +0200 (CEST)
De : Daniel Pocock
Réponse à : Travailliste victorien
À : [tous les membres du Parti travailliste victorien]

Il n'y a pas si longtemps, la branche étatique a pris l'initiative d'imprimer
« Fier membre du syndicat » sur les cartes de membre. Quand vous avez vu la vidéo dégradante
Le témoignage d'une réfugiée pauvre et vulnérable a été diffusé dans le monde entier sur
Lundi, la fierté était-elle l'émotion que vous ressentiez dans votre cœur ? Si oui, vous
Inutile de lire la suite.

Je suis membre du Parti travailliste australien (ALP) depuis 15 ans. Je n'ai jamais eu autant honte.
que maintenant, quand j'ai vu les informations concernant notre gouvernement travailliste qui met les réfugiés à l'écart
remis en détention aux mains de ceux qui les avaient violés.
C'est bien pire que les accusations portées contre l'Église catholique.

Le Parti travailliste australien (ALP) est au pouvoir depuis six ans. Il est absurde de penser…
Leurs programmes d'espionnage conjoints américano-australiens peuvent surveiller les déplacements des suspects.
à l'autre bout du monde, au Moyen-Orient, mais ils n'en ont pas conscience.
lorsque des viols ont lieu sous la garde et la protection de notre propre nation
programme de réfugiés. Si votre député n'était pas personnellement au courant de ces choses,
Alors, quel genre de travail fait-il exactement ? Aucun programme de détention n'est prévu.
L'histoire de l'humanité s'est jamais terminée de façon moins tragique.
que ce que nous voyons actuellement.

Si votre député est (ou était) membre du cabinet, la seule question est de savoir comment
Que savaient-ils vraiment et depuis combien de temps nous trompent-ils ?
Le reste du pays n'en a pas parlé. Ils ont fait obstruction aux médias et aux mineurs
Les partis politiques sont tenus responsables de la surveillance de ces camps de concentration afin d'empêcher leur examen approfondi.
chacun d'entre nous dans l'obscurité.

Plusieurs de ces individus sans scrupules prévoient de prendre leur retraite avec une généreuse pension.
La pension sera versée dans quelques semaines seulement, tandis que ces malheureux humains
Les êtres qui se sont placés sous leur protection en portent encore les stigmates.
de l'automutilation et du viol pour le restant de leurs jours. Quel contraste.
Les valeurs syndicales transparaissent.

Lorsque la campagne électorale fédérale débutera officiellement, qui sera en lice ?
Je me sentirai vraiment à l'aise en portant un t-shirt ALP.
Vous vous demandez à quoi ressembleront les prochaines révélations d'abus ?
Devons-nous attendre que M. Assange ou M. Snowden contestent la situation
les excès de notre gouvernement mettent leur propre vie en danger ou font
Avons-nous le courage d'en parler, chacun d'entre nous ?

J'ai commencé à inclure certaines de mes propres observations sur l'Australie
J'ai récemment constaté des problèmes sur mon blog. Vos commentaires sont les bienvenus.
Là-bas ou via votre plateforme sociale préférée. Il est temps de dire à votre
Le député et le monde entier ont compris que les êtres humains ne sont pas un sujet de négociations, de débats,
échanges et viols.

http://danielpocock.com/if-assange-is-a-rapist-what-kind-of-monster-runs-australia

Quand des personnes sont victimes de viol et de maltraitance, ce n'est pas le moment d'être patient ou complaisant.
ou apathiques. Ce n'est pas le moment pour une autre excuse lâche concernant les pendus.
Le parlement ou l'absence de contrôle absolu au Sénat. Si vous êtes venu
Adrian Bayley violant une autre femme dans une ruelle, la manière dont il l'a sauvagement fait
Jill Meagher, pourriez-vous simplement passer votre chemin ? C'est exactement ce que ce parlement attend de nous.
a fait pour les personnes dans le besoin. Si vous êtes vraiment un fier membre du Parti travailliste, vous ne le feriez pas.
pouvoir vivre avec cette honte.

---------------------------------------------

L'employé qui a dénoncé ces viols fait actuellement l'objet de poursuites judiciaires.
pour avoir enfreint une clause de confidentialité de son contrat. Est-ce que le travail
faire le nécessaire pour garantir que les lanceurs d'alerte qui dénoncent les crimes puissent
Vous vous sentez à l'abri des persécutions ?

---------------------------------------------

Vous recevez ce courriel car vous figurez sur une liste de diffusion gérée et diffusée par la section victorienne du Parti travailliste australien (ALP). L'en-tête de réponse est configuré pour que vous puissiez répondre.
Contactez-les directement si vous souhaitez que votre adresse soit retirée de la liste.

Si vous pensez qu'une femme dans le Queensland est en danger de mort immédiat, composez le 000. Ce numéro fonctionne uniquement en Australie et ne doit être utilisé qu'en cas d'urgence.

Pour toute autre demande de vérification de bien-être, vous pouvez vous rendre dans un poste de police local ou appeler la police du Queensland au +61730556206 (à partir du site Web ).

Lors de votre entretien avec la police, il est important de souligner les points énumérés ci-dessus.

Pour en savoir plus sur l'asile politique , cliquez ici .

Daniel Pocock: Urgent: welfare check, call now Iran womenâ€™s football team

Daniel Pocock — 2026-03-08T12:00:00+00:00

As publicised all around the world, the women's football team from Iran is currently touring Australia.

Their final match takes place today, International Women's Day and then they will be placed on a plane back to Iran.

At their first match, they refused to sing the national anthem.

At their second match, they saluted and sung the national anthem.

Experts have widely observed this change in behaviour was due to coercive control.

The state of Queensland was the first state in Australia to introduce laws on coercive control. The police have an obligation to uphold the law. The women's final match is in Queensland.

The security team who came from Iran are living in close proximity to the women in the same hotel. This is a domestic relationship for the purpose of Queensland law. The hotel bookings and travel companions are all organised for the women. They can not go anywhere on their own. Therefore, it is a form of domestic interdependency and the law applies to each woman in this case.

When alerted about a domestic situation, the police have an obligation to act. At the very least, police are obliged to make a welfare check. They will not do so unless people ask them.

State TV in Iran has clearly stated the women are "wartime traitors". In most cases of coercive control, the evidence of such threats is hidden from public view. In this case, there is a threat that women who speak up while outside Iran will be subject to criminal persecution under the laws for treason.

In 2013, Australia's then Labor government published a video humiliating female asylum seekers from Iran.

I joined the ALP in 1997 and when I saw the video humiliating women from Iran I resigned immediately. My resignation was leaked and published by Crikey. A full copy of the email is below.

My resignation email has suddenly become a vital piece of evidence that the Australian government wants to deter women from Iran from making claims for political asylum. On that basis, it is even more urgent for anybody concerned with the matter to contact local police and ask them to make a welfare check on these women.

If you believe there is an urgent and immediate threat to the life of any woman in Queensland then the number to dial is 000. This number only works in Australia and it should only be used for emergencies.

For any other request for a welfare check, you can visit a local police station or call Queensland police on +61730556206 (from the web site).

When speaking to the police, it is important to emphasise these points:

The women are currently in Queensland police jurisdiction
They will be forced to leave the jurisdiction within a few hours
These women are subject to a domestic arrangement by way of their group travel booking.
These women are accompanied by a group of men wherever they go.
Their refusal to sing the national anthem at the first match is a sign they are silently making a complaint and asking for help
Their change of behaviour, saluting and singing the national anthem at their second game, is a sign they were under coercive control to withdraw the complaint they made by way of silence
These women were subject to a direct threat, which was broadcast on Iran's state television, implying the women will be persecuted for treason.
The video produced by the Australian government in July 2013 is intended to have the impact of coercive control, by deterring Iranian women from exercising their rights in Australia, with the threat of public humiliation.
When the FIFA women's world cup was held in Australia, federal authorities failed to act on the behaviour of Spanish football boss Luis Rubiales, despite the fact his behaviour was seen by everybody on national TV. He was able to board a plane and leave Australia without any investigation or prosecution.
It is essential for Queensland police to open an official file on the risk to each woman in the group
It is essential for Queensland police to make a welfare check on each woman in the group

Not so long ago, in Switzerland I met the boss of one of the Iranian sporting federations during youth Winter Olympics:

Here is the email resignation when the ALP government humiliated Iranian women with a video in July 2013:

Subject: ALP Policy, Pride and the horrors of Rape
Date: Tue, 23 Jul 2013 23:44:17 +0200 (CEST)
From: Daniel Pocock 
Reply-To: Victorian Labor 
To: [ all Victorian ALP members ]

Not long ago the state branch took it upon themselves to print
"Proud Labor Member" on the membership cards.  When you saw the degrading video
of a poor, vulnerable, female refugee broadcast around the world on
Monday was pride the emotion that you felt in your heart?  If it was, you
need not bother reading any further.

I've been a member of the ALP for 15 years.  I've never been more ashamed of
that than today when I saw the news about our ALP Government putting refugees
put back into detention in the hands of people who had raped them.
This is far worse than the allegations against the Catholic Church.

The ALP has been in Government for 6 years now.  It is absurd to think
their joint US/Australia spy programs can monitor the movements of suspects
half way around the world in the middle east, but they are not aware
when rapes take place under the care and protection of our own national
refugee program.  If your MP didn't personally know about these things,
then just what kind of a job is he doing?  No program of detention in
the history of mankind has ever ended up in anything less tragic
than what we are seeing now.

If your MP is (or was) a cabinet member, the only question is how
much did they know and for how long have they been deceiving us and the
rest of the nation about it.  They obstructed the media and the minor
parties from scrutinising these concentration camps to try and keep
each and every one of us in the dark.

Several of these shameless people are planning to retire on a hefty
pension in just a few weeks from now while those unfortunate human
beings who came under their protection are suffering with the scars
of self-mutilation and rape for the rest of their lives.  What a contrast.
Labor values shining through.

When the federal election campaign officially kicks off, who is
really going to feel comfortable going out there in an ALP T-shirt
wondering what the next revelations of abuse are going to look like?
Do we have to wait for Mr Assange or Mr Snowden to challenge
the excesses of our Government at risk to their own lives or do
we have the guts to speak up about it, each and every one of us?

I've started including some of my own observations about Australia's
failings on my blog recently.  You are more than welcome to comment
there or through your preferred social platform.  It's time to tell your
MP and the world that human beings are not a subject for deals, debates,
swaps and rapes.

http://danielpocock.com/if-assange-is-a-rapist-what-kind-of-monster-runs-australia

When people are being raped and abused, it's no time to be patient, complacent
or apathetic.  It's no time for another spineless excuse about the hung
parliament or the lack of outright control in the Senate.  If you came
across Adrian Bayley raping another woman in a laneway the way he savaged
Jill Meagher, would you just walk by?  That is exactly what this parliament
has done for people in need.  If you are really a Proud Labor Member you wouldn't
be able to live with this shame.

---------------------------------------------

The worker who blew the whistle on these rapes is currently facing litigation
for breaching a confidentiality clause in his contract.  Is Labor
doing enough to ensure whiste-blowers who speak out about crime can
feel safe from persecution?

---------------------------------------------

You are receiving this email as you are on a list maintained and circulated by the Victorian branch of the ALP.  I've set the reply header so you can reply
directly to them if you want your address removed from the list.

For any other request for a welfare check, you can visit a local police station or call Queensland police on +61730556206 (from the web site).

When speaking to the police, it is important to emphasise the list of points given above.

Dirk Eddelbuettel: RProtoBuf 0.4.26 on CRAN: More Maintenance

Dirk Eddelbuettel — 2026-03-07T12:25:00+00:00

A new maintenance release 0.4.26 of RProtoBuf arrived on CRAN today. RProtoBuf provides R with bindings for the Google Protocol Buffers (“ProtoBuf”) data encoding and serialization library used and released by Google, and deployed very widely in numerous projects as a language and operating-system agnostic protocol. The new release is also already as a binary via r2u.

This release brings an update to aid in an ongoing Rcpp transitions from Rf_error to Rcpp::stop, and includes a few more minor cleanups including one contributed by Michael.

The following section from the NEWS.Rd file has full details.

Changes in RProtoBuf version 0.4.26 (2026-03-06)

Minor cleanup in DESCRIPTION depends and imports

Remove obsolete check for utils::.DollarNames (Michael Chirico in #111)

Replace Rf_error with Rcpp::stop, turn remaining one into (Rf_error) (Dirk in #112)

Update configure test to check for RProtoBuf 3.3.0 or later

Thanks to my CRANberries, there is a diff to the previous release. The RProtoBuf page has copies of the (older) package vignette, the ‘quick’ overview vignette, and the pre-print of our JSS paper. Questions, comments etc should go to the GitHub issue tracker off the GitHub repo.

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

Steinar H. Gunderson: A286874(14) = 28

Steinar H. Gunderson — 2026-03-07T09:54:00+00:00

There's a logic puzzle that goes like this: A king has a thousand bottles of wine, where he knows that one is poisoned. He also has ten disposable servants that could taste the wine, but for whatever reason (the usual explanation is that the poison is slow-working and the feast is nearing), they can only take one sip each, possibly mixed from multiple bottles. How can he identify the bad bottle?

The solution is well-known and not difficult; you give each bottle a number 0..999 and write it out in binary, and use the ones to assign wines to servants. (So there's one servant that drinks a mix of all the odd-numbered wines, and that tells you if the poisoned bottle's number is odd or even. Another servant drinks a mix of bottles 2, 3, 6, 7, 10, 11, etc., and that tells you the second-lowest bit. And so on.) This works because ten servants allow you to test 2^10 = 1024 bottles.

It is also easy to extend this to “at most one bottle is poisoned”; give the wines numbers from 1..1000 instead, follow the same pattern, and if no servant dies, you know the answer is zero. (This allows you to test at most 1023 bottles.)

Now, let's tweak the puzzle: What if there's zero, one or two poisoned bottles? How many bottles can the king test with his ten servants? (If you're looking for a more real-world application of this, replace “poisoned bottles” with “COVID tests” and maybe it starts to sound less arbitrary.) If course, the king can easily test ten bottles by having each servant test exactly one bottle each, but it turns out you can get to 13 by being a bit more clever, for instance:

   0123456789 ← Servant number

 0 0000000111
 1 0000011001
 2 0000101010
 3 0000110100
 4 0001001100
 5 0010010010
 6 0011000001
 7 0100100001
 8 0101000010
 9 0110000100
10 1001010000
11 1010100000
12 1100001000

 ↑ Bottle number

It can be shown (simply by brute force) that no two rows here are a subset of another row, so if you e.g. the “servant death” vector is 0110101110 (servants 1, 2, 4, 6, 7 and 8 die), the only way this could be is if bottle 2 and 9 are poisoned (and none else). Of course, the solution is nonunique, since you could switch around the number of servants or wines and it would stil work. But if you don't allow that kind of permutation, there are only five different solutions for 10 servants and 13 wines.

The maximum number of possible wines to test is recorded in OEIS A286874, and the number of different solutions in A303977. So for A286874, a(10) = 13 and for A303977, a(10) = 5.

We'd like to know what these values for higher values, in particular A286874 (A303977 is a bit more of a curiosity, and also a convenient place to write down all the solutions). I've written before about how we can create fairly good solutions using error-correcting codes (there are also other possible constructions), but optimal turns out to be hard. The only way we know of is some form of brute force. (I used a SAT solver to confirm a(10) and a(11), but it seemed to get entirely stuck on a(12).)

I've also written about my brute-force search of a(12) and a(13), so I'm not going to repeat that, but it turned out that with a bunch of extra optimizations and 210 calendar days of near-continuous calculation, I could confirm that:

A286874 a(14) = 28
A303977 a(14) = 788 (!!)

The latter result is very surprising to me, so it was an interesting find. I would have assumed that with this many solutions, we'd find a(14) = 29.

I don't have enough CPU power to test a(15) or a(16) (do contact me if you have a couple thousand cores to lend out for some months or more), but I'm going to do a search in a given subset of the search space (5-uniform solutions), which is much faster; it won't allow us to fix more elements of either of the sequences, but it's possible that we'll find some new records and thus lower bounds for A286874. Like I already posted, we know that a(15) >= 42. (Someone should also probably go find some bounds for a(17), a(18), etc.—when the sequence was written, the posted known bounds were far ahead of the sequence itself, but my verification has caught up and my approach is not as good in creating solutions heuristically out of thin air.)

Daniel Pocock: Bon Ap : Lieu de naissance des ANZAC, ancêtre de la guerre hybride, lié à un restaurant français

Daniel Pocock — 2026-03-06T23:30:00+00:00

Depuis le début de l'invasion de l'Iran , les reportages et les commentaires sur la guerre n'ont pas manqué. Je ne peux sûrement rien aborder sur mon blog qui n'ait déjà été écrit ailleurs.

En réfléchissant à ce que je ferais pour la journée de l'ANZAC cette année, j'ai ressorti quelques vieux dossiers concernant mon arrière-grand-père, le sergent Robert Ernest Edward Pocock , héros de l'ANZAC . J'ai décidé de parcourir les documents ligne par ligne pour voir s'il y avait quelque chose d'intéressant. Je n'ai pas eu besoin d'aller plus loin que le premier document, son acte de naissance, pour avoir une surprise.

J'ai vu l'adresse du lieu de naissance du sergent Pocock, le 193 Brunswick Street, à Fitzroy, sur son acte de naissance et j'ai décidé de la rechercher sur Internet pour voir ce qu'il en est advenu. En fait, c'est l'un des restaurants français les plus connus de Melbourne, le Bon Ap Petit Bistrot, à Fitzroy. J'ai réalisé un montage photo retraçant le parcours de mon arrière-grand-père, de Bon Ap à la restauration des soldats dans le nord de la France .

Alors que le sergent Pocock travaillait dans l'industrie des munitions, il est intéressant de noter que je me suis orienté vers des projets de cybersécurité modernes , en particulier ceux concernant l'ingénierie sociale .

Beaucoup trop de soldats ne sont jamais rentrés en Australie. Ils ont dû affronter l'ennemi, le froid et, pire encore, la maladie. On retrouve tous ces éléments dans le rapport concernant le sergent Robert Pocock (matricule 10768) du 3e train divisionnaire, 22e compagnie, dans le nord de la France et en Belgique .

En regardant vers le sud, le long de Brunswick Street, depuis la maison natale de Robert Pocock, on aperçoit la flèche de la cathédrale Saint-Patrick. Robert était baptiste. Son deuxième fils, Walter, se maria à l' église catholique . Son petit-fils, John, se maria dans la cathédrale même. L'arrière-arrière-petit-fils de Robert devint membre de la chorale de la cathédrale.

Lisez l'histoire du sergent Robert Ernest Edward Pocock, 10768, 3e train divisionnaire, 22e compagnie, AIF sur ANZAC.site .

Daniel Pocock: Bon Ap: ANZAC birthplace, Grandfather of hybrid warfare linked to French restaurant

Daniel Pocock — 2026-03-06T23:30:00+00:00

Since the invasion of Iran got under way, there has been no shortage of news reports and commentary about warfare. Surely there is nothing I can cover on my blog that hasn't been written somewhere else already?

While contemplating what to do for ANZAC day this year, I took out some of the old files about my great grandfather, the ANZAC hero Sgt Robert Ernest Edward Pocock. I decided to go through the documents line-by-line to see if there was anything interesting. I didn't have to go any further than the first document, his birth certificate, to get a surprise.

I saw the address of Sgt Pocock's birthplace, 193 Brunswick Street, Fitzroy, on his birth certificate and I decided to type it into a search engine to see what is there today. In fact, it is one of Melbourne's most well-known French restaurants, Bon Ap Petit Bistrot, Fitzroy. I put together a series of pictures telling the story of how my great-grand-father went from Bon Ap to feeding the diggers in the north of France.

While Sgt Pocock worked in the munitions industry, it is an interesting coincidence that I've gone into modern day cybersecurity projects, especially those concerning social engineering.

Far too many diggers didn't make it back to Australia. They had to battle the enemy, the cold and worst of all, disease. We see all of these things in the report about Sgt Robert Pocock (10768) of the 3rd Divisional Train, 22 Company in the north of France and Belgium.

Looking south down Brunswick Street from Robert Pocock's birthplace, we see the spire of St Patrick's Cathedral. Robert was a Baptist. His second son, Walter, married in the Catholic Church. His grandson, John, married in the Cathedral itself. Robert's great-great-grandson would become a member of the Cathedral Choir.

Read the story of Sgt Robert Ernest Edward Pocock, 10768, 3rd Divisional Train, 22nd Company, AIF on ANZAC.site.

Thorsten Alteholz: My Debian Activities in February 2026

alteholz — 2026-03-06T18:27:54+00:00

Debian LTS/ELTS

This was my hundred-fortieth 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 4474-1] rlottie security update to fix three CVEs related to boundary checks.
[DLA 4477-1] munge security update to fix one CVE related to a buffer overflow.
[DLA 4483-1] gimp security update to fix four CVEs related to arbitrary code execution.
[DLA 4487-1] gegl security update to fix two CVEs related to heap-based buffer overflow.
[DLA 4489-1] libvpx security update to fix one CVE related to a buffer overflow.
[ELA-1649-1] gimp security update to fix three CVEs in Buster and Stretch related to arbitrary code execution.
[ELA-1650-1] gegl security update to fix two CVEs in Buster and Stretch related to heap-based buffer overflow.

Some CVEs could be marked as not-affected for one or all LTS/ELTS-releases. I also worked on package evolution-data-server and attended the monthly LTS/ELTS meeting.

Debian Printing

This month I uploaded a new upstream versions:

… ipp-usb to unstable.
… brlaser to unstable.
… gutenprint to unstable.

This work is generously funded by Freexian!

Debian Lomiri

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

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

Debian Astro

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

… c-munipack to unstable. This package now contains a version without GTK support. Upstream is working on a port to GTK3 but seems to need some more time to finish this.
… libasi to unstable.
… libdfu-ahp to unstable.
… libfishcamp to unstable.
… libinovasdk to unstable.
… libmicam to unstable.
… siril to unstable (sponsored upload).

Debian IoT

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

… pyicloud to unstable.

Unfortunately development of openoverlayrouter finally stopped, so I had to remove this package from the archive.

Debian Mobcom

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

… libsmpp34 to unstable.

misc

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

… nuspell to unstable.

I also sponsored the upload of some Matomo dependencies. Thanks a lot to William for preparing the packages

Antoine Beaupré: Wallabako retirement and Readeck adoption

Antoine Beaupré — 2026-03-06T16:57:28+00:00

Today I have made the tough decision of retiring the Wallabako project. I have rolled out a final (and trivial) 1.8.0 release which fixes the uninstall procedure and rolls out a bunch of dependency updates.

Why?

The main reason why I'm retiring Wallabako is that I have completely stopped using it. It's not the first time: for a while, I wasn't reading Wallabag articles on my Kobo anymore. But I had started working on it again about four years ago. Wallabako itself is about to turn 10 years old.

This time, I stopped using Wallabako because there's simply something better out there. I have switched away from Wallabag to Readeck!

And I'm also tired of maintaining "modern" software. Most of the recent commits on Wallabako are from renovate-bot. This feels futile and pointless. I guess it must be done at some point, but it also feels we went wrong somewhere there. Maybe Filippo Valsorda is right and one should turn dependabot off.

I did consider porting Wallabako to Readeck for a while, but there's a perfectly fine Koreader plugin that I've been pretty happy to use. I was worried it would be slow (because the Wallabag plugin is slow), but it turns out that Readeck is fast enough that this doesn't matter.

Moving from Wallabag to Readeck

Readeck is pretty fantastic: it's fast, it's lightweight, everything Just Works. All sorts of concerns I had with Wallabag are just gone: questionable authentication, questionable API, weird bugs, mostly gone. I am still looking for multiple tags filtering but I have a much better feeling about Readeck than Wallabag: it's written in Golang and under active development.

In any case, I don't want to throw shade at the Wallabag folks either. They did solve most of the issues I raised with them and even accepted my pull request. They have helped me collect thousands of articles for a long time! It's just time to move on.

The migration from Wallabag was impressively simple. The importer is well-tuned, fast, and just works. I wrote about the import in this issue, but it took about 20 minutes to import essentially all articles, and another 5 hours to refresh all the contents.

There are minor issues with Readeck which I have filed (after asking!):

add justified view for articles (Android app)
more metadata in article display (Android app)
show the number of articles in the label browser
ignore duplicates (Readeck will happily add duplicates, whereas Wallabag at least tries to deduplicate articles -- but often fails)

But overall I'm happy and impressed with the result.

I'm also both happy and sad at letting go of my first (and only, so far) Golang project. I loved writing in Go: it's a clean language, fast to learn, and a beauty to write parallel code in (at the cost of a rather obscure runtime).

It would have been much harder to write this in Python, but my experience in Golang helped me think about how to write more parallel code in Python, which is kind of cool.

The GitLab project will remain publicly accessible, but archived, for the foreseeable future. If you're interested in taking over stewardship for this project, contact me.

Thanks Wallabag folks, it was a great ride!

Russell Coker: Links March 2026

etbe — 2026-03-06T12:23:14+00:00

Krebs has an interesting article about the Kimwolf botnet which uses residential proxy relay services [1].

cory Doctorow wrote an insightful blog post about code being a liability not an asset [2].

Aigars Mahinovs wrote an interesting review of the BMW i4 M50 xDrive and the BMW i5 eDrive40 which seem like very impressive vehicles [3]. I was wondering what BMW would do now that all the features they had in the 90s have been copied by cheaper brands but they have managed to do new and exciting things.

Arstechnica has an interesting article about the recently declassified JUMPSEAT surveillance satellites that ran from 1971 to 1987 [4].

Cory Doctorow wrote an interesting blog post about OgApp which briefly allowed viewing Instagram without ads and the issues of US corporations misusing EU copyright law [5].

ZDNet has an interesting article about new planned developments for the web of trust for Linux kernel coders (and others) [6].

Last month India had a 300 million person strike, we need more large scale strikes against governments that support predatory corporations [7].

Techdirt has an insightful article on the ways the fascism is bad for innovation and a market based economy [8].

The Acknowledgements section from the Scheme Shell (scsh) reference is epic [9].

Vice has an insightful article on research about “do your own research” and how simple Google searches tend to reinforce conspiracy theories [10]. A problem with Google is that it’s most effective if you already know the answer.

Issendai has an interesting and insightful series of blog posts about estranged parents forums which seems a lot like Incel forums in the way they promote abuse [11].

Caitlin Johnstone wrote an interesting article about how “the empire” caused the rebirth of a real counterculture by their attempts to coerce support for Israeli atrocities [12].

Radley Balko wrote an interesting article about “the courage to be decent” concerning the Trump regime’s attempts to scare lawyers into cooperating with them [13].

Terry Tan wrote a useful resource on the API for Google search, this could be good for shell scripts and for 3rd party programs that launch a search [14].

The Proof has an interesting article about eating oysters and mussels as a vegan [15].

All Things Linguistic has an interesting and amusing post about Yoda’s syntax in non-English languages [16].

Ian Jackson: Adopting tag2upload and modernising your Debian packaging

Ian Jackson — 2026-03-05T18:47:55+00:00

Introduction

tag2upload allows authorised Debian contributors to upload to Debian simply by pushing a signed git tag to Debian’s gitlab instance, Salsa.

We have recently announced that tag2upload is, in our opinion, now very stable, and ready for general use by all Debian uploaders.

tag2upload, as part of Debian’s git transition programme, is very flexible - it needs to support a large variety of maintainer practices. And it’s relatively unopinionated, wherever that’s possible. But, during the open beta, various contributors emailed us asking for Debian packaging git workflow advice and recommendations.

This post is an attempt to give some more opinionated answers, and guide you through modernising your workflow.

(This article is aimed squarely at Debian contributors. Much of it will make little sense to Debian outsiders.)

Why

Ease of development

git offers a far superior development experience to patches and tarballs. Moving tasks from a tarballs and patches representation to a normal, git-first, representation, makes everything simpler.

dgit and tag2upload do automatically many things that have to be done manually, or with separate commands, in dput-based upload workflows.

They will also save you from a variety of common mistakes. For example, you cannot accidentally overwrite an NMU, with tag2upload or dgit. These many safety catches mean that our software sometimes complains about things, or needs confirmation, when more primitive tooling just goes ahead. We think this is the right tradeoff: it’s part of the great care we take to avoid our software making messes. Software that has your back is very liberating for the user.

tag2upload makes it possible to upload with very small amounts of data transfer, which is great in slow or unreliable network environments. The other week I did a git-debpush over mobile data while on a train in Switzerland; it completed in seconds.

See the Day-to-day work section below to see how simple your life could be.

Don’t fear a learning burden; instead, start forgetting all that nonsense

Most Debian contributors have spent months or years learning how to work with Debian’s tooling. You may reasonably fear that our software is yet more bizarre, janky, and mistake-prone stuff to learn.

We promise (and our users tell us) that’s not how it is. We have spent a lot of effort on providing a good user experience. Our new git-first tooling, especially dgit and tag2upload, is much simpler to use than source-package-based tooling, despite being more capable.

The idiosyncrasies and bugs of source packages, and of the legacy archive, have been relentlessly worked around and papered over by our thousands of lines of thoroughly-tested defensive code. You too can forget all those confusing details, like our users have! After using our systems for a while you won’t look back.

And, you shouldn’t fear trying it out. dgit and tag2upload are unlikely to make a mess. If something is wrong (or even doubtful), they will typically detect it, and stop. This does mean that starting to use tag2upload or dgit can involve resolving anomalies that previous tooling ignored, or passing additional options to reassure the system about your intentions. So admittedly it isn’t always trivial to get your first push to succeed.

Properly publishing the source code

One of Debian’s foundational principles is that we publish the source code.

Nowadays, the vast majority of us, and of our upstreams, are using git. We are doing this because git makes our life so much easier.

But, without tag2upload or dgit, we aren’t properly publishing our work! Yes, we typically put our git branch on Salsa, and point Vcs-Git at it. However:

The format of git branches on Salsa is not standardised. They might be patches-unapplied, patches-applied, bare debian/, or something even stranger.
There is no guarantee that the DEP-14 debian/1.2.3-7 tag on salsa corresponds precisely to what was actually uploaded. dput-based tooling (such as gbp buildpackage) doesn’t cross-check the .dsc against git.
There is no guarantee that the presence of a DEP-14 tag even means that that version of package is in the archive.

This means that the git repositories on Salsa cannot be used by anyone who needs things that are systematic and always correct. They are OK for expert humans, but they are awkward (even hazardous) for Debian novices, and you cannot use them in automation. The real test is: could you use Vcs-Git and Salsa to build a Debian derivative? You could not.

tag2upload and dgit do solve this problem. When you upload, they:

Make a canonical-form (patches-applied) derivative of your git branch;
Ensure that there is a well-defined correspondence between the git tree and the source package;
Publish both the DEP-14 tag and a canonical-form archive/debian/1.2.3-7 tag to a single central git depository, *.dgit.debian.org;
Record the git information in the Dgit field in .dsc so that clients can tell (using the ftpmaster API) that this was a git-based upload, what the corresponding git objects are, and where to find them.

This dependably conveys your git history to users and downstreams, in a standard, systematic and discoverable way. tag2upload and dgit are the only system which achieves this.

(The client is dgit clone, as advertised in e.g. dgit-user(7). For dput-based uploads, it falls back to importing the source package.)

Adopting tag2upload - the minimal change

tag2upload is a substantial incremental improvement to many existing workflows. git-debpush is a drop-in replacement for building, signing, and uploading the source package.

So, you can just adopt it without completely overhauling your packaging practices. You and your co-maintainers can even mix-and-match tag2upload, dgit, and traditional approaches, for the same package.

Start with the wiki page and git-debpush(1) (ideally from forky aka testing).

You don’t need to do any of the other things recommended in this article.

Overhauling your workflow, using advanced git-first tooling

The rest of this article is a guide to adopting the best and most advanced git-based tooling for Debian packaging.

Assumptions

Your current approach uses the “patches-unapplied” git branch format used with gbp pq and/or quilt, and often used with git-buildpackage. You previously used gbp import-orig.
You are fluent with git, and know how to use Merge Requests on gitlab (Salsa). You have your origin remote set to Salsa.
Your main Debian branch name on Salsa is master. Personally I think we should use main but changing your main branch name is outside the scope of this article.
You have enough familiarity with Debian packaging including concepts like source and binary packages, and NEW review.
Your co-maintainers are also adopting the new approach.

tag2upload and dgit (and git-debrebase) are flexible tools and can help with many other scenarios too, and you can often mix-and-match different approaches. But, explaining every possibility would make this post far too confusing.

Topics and tooling

This article will guide you in adopting:

tag2upload
Patches-applied git branch for your packaging
Either plain git merge or git-debrebase
dgit when a with-binaries uploaded is needed (NEW)
git-based sponsorship
Salsa (gitlab), including Debian Salsa CI

Choosing the git branch format

In Debian we need to be able to modify the upstream-provided source code. Those modifications are the Debian delta. We need to somehow represent it in git.

We recommend storing the delta as git commits to those upstream files, by picking one of the following two approaches.

rationale

Much traditional Debian tooling like quilt and gbp pq uses the “patches-unapplied” branch format, which stores the delta as patch files in debian/patches/, in a git tree full of unmodified upstream files. This is clumsy to work with, and can even be an alarming beartrap for Debian outsiders.

git merge

Option 1: simply use git, directly, including git merge.

Just make changes directly to upstream files on your Debian branch, when necessary. Use plain git merge when merging from upstream.

This is appropriate if your package has no or very few upstream changes. It is a good approach if the Debian maintainers and upstream maintainers work very closely, so that any needed changes for Debian are upstreamed quickly, and any desired behavioural differences can be arranged by configuration controlled from within debian/.

This is the approach documented more fully in our workflow tutorial dgit-maint-merge(7).

git-debrebase

Option 2: Adopt git-debrebase.

git-debrebase helps maintain your delta as linear series of commits (very like a “topic branch” in git terminology). The delta can be reorganised, edited, and rebased. git-debrebase is designed to help you carry a significant and complicated delta series.

The older versions of the Debian delta are preserved in the history. git-debrebase makes extra merges to make a fast-forwarding history out of the successive versions of the delta queue branch.

This is the approach documented more fully in our workflow tutorial dgit-maint-debrebase(7).

Examples of complex packages using this approach include src:xen and src:sbcl.

Determine upstream git and stop using upstream tarballs

We recommend using upstream git, only and directly. You should ignore upstream tarballs completely.

rationale

Many maintainers have been importing upstream tarballs into git, for example by using gbp import-orig. But in reality the upstream tarball is an intermediate build product, not (just) source code. Using tarballs rather than git exposes us to additional supply chain attacks; indeed, the key activation part of the xz backdoor attack was hidden only in the tarball!
git offers better traceability than so-called “pristine” upstream tarballs. (The word “pristine” is even a joke by the author of pristine-tar!)

First, establish which upstream git tag corresponds to the version currently in Debian. From the sake of readability, I’m going to pretend that upstream version is 1.2.3, and that upstream tagged it v1.2.3.

Edit debian/watch to contain something like this:

version=4
opts="mode=git" https://codeberg.org/team/package refs/tags/v(\d\S*)

You may need to adjust the regexp, depending on your upstream’s tag name convention. If debian/watch had a files-excluded, you’ll need to make a filtered version of upstream git.

git-debrebase

From now on we’ll generate our own .orig tarballs directly from git.

rationale

We need some “upstream tarball” for the 3.0 (quilt) source format to work with. It needs to correspond to the git commit we’re using as our upstream. We don’t need or want to use a tarball from upstream for this. The .orig is just needed so a nice legacy Debian source package (.dsc) can be generated.

Probably, the current .orig in the Debian archive, is an upstream tarball, which may be different to the output of git-archive and possibly even have different contents to what’s in git. The legacy archive has trouble with differing .origs for the “same upstream version”.

So we must — until the next upstream release — change our idea of the upstream version number. We’re going to add +git to Debian’s idea of the upstream version. Manually make a tag with that name:

git tag -m "Compatibility tag for orig transition" v1.2.3+git v1.2.3~0
git push origin v1.2.3+git

If you are doing the packaging overhaul at the same time as a new upstream version, you can skip this part.

Convert the git branch

git merge

Prepare a new branch on top of upstream git, containing what we want:

git branch -f old-master         # make a note of the old git representation
git reset --hard v1.2.3          # go back to the real upstream git tag
git checkout old-master :debian  # take debian/* from old-master
git commit -m "Re-import Debian packaging on top of upstream git"
git merge --allow-unrelated-histories -s ours -m "Make fast forward from tarball-based history" old-master
git branch -d old-master         # it's incorporated in our history now

If there are any patches, manually apply them to your main branch with git am, and delete the patch files (git rm -r debian/patches, and commit). (If you’ve chosen this workflow, there should be hardly any patches,)

rationale

These are some pretty nasty git runes, indeed. They’re needed because we want to restart our Debian packaging on top of a possibly quite different notion of what the upstream is.

git-debrebase

Convert the branch to git-debrebase format and rebase onto the upstream git:

git-debrebase -fdiverged convert-from-gbp upstream/1.2.3
git-debrebase -fdiverged -fupstream-not-ff new-upstream 1.2.3+git

If you had patches which patched generated files which are present only in the upstream tarball, and not in upstream git, you will encounter rebase conflicts. You can drop hunks editing those files, since those files are no longer going to be part of your view of the upstream source code at all.

rationale

The force option -fupstream-not-ff will be needed this one time because your existing Debian packaging history is (probably) not based directly on the upstream history. -fdiverged may be needed because git-debrebase might spot that your branch is not based on dgit-ish git history.

Manually make your history fast forward from the git import of your previous upload.

dgit fetch
git show dgit/dgit/sid:debian/changelog
# check that you have the same version number
git merge -s ours --allow-unrelated-histories -m 'Declare fast forward from pre-git-based history' dgit/dgit/sid

Change the source format

Delete any existing debian/source/options and/or debian/source/local-options.

git merge

Change debian/source/format to 1.0. Add debian/source/options containing -sn.

rationale

We are using the “1.0 native” source format. This is the simplest possible source format - just a tarball. We would prefer “3.0 (native)”, which has some advantages, but dpkg-source between 2013 (wheezy) and 2025 (trixie) inclusive unjustifiably rejects this configuration.
You may receive bug reports from over-zealous folks complaining about the use of the 1.0 source format. You should close such reports, with a reference to this article and to #1106402.

git-debrebase

Ensure that debian/source/format contains 3.0 (quilt).

Now you are ready to do a local test build.

Sort out the documentation and metadata

Edit README.source to at least mention dgit-maint-merge(7) or dgit-maint-debrebase(7), and to tell people not to try to edit or create anything in debian/patches/. Consider saying that uploads should be done via dgit or tag2upload.

Check that your Vcs-Git is correct in debian/control. Consider deleting or pruning debian/gbp.conf, since it isn’t used by dgit, tag2upload, or git-debrebase.

git merge

Add a note to debian/changelog about the git packaging change.

git-debrebase

git-debrebase new-upstream will have added a “new upstream version” stanza to debian/changelog. Edit that so that it instead describes the packaging change. (Don’t remove the +git from the upstream version number there!)

Configure Salsa Merge Requests

git-debrebase

In “Settings” / “Merge requests”, change “Squash commits when merging” to “Do not allow”.

rationale

Squashing could destroy your carefully-curated delta queue. It would also disrupt git-debrebase’s git branch structure.

Set up Salsa CI, and use it to block merges of bad changes

Caveat - the tradeoff

gitlab is a giant pile of enterprise crap. It is full of startling bugs, many of which reveal a fundamentally broken design. It is only barely Free Software in practice for Debian (in the sense that we are very reluctant to try to modify it). The constant-churn development approach and open-core business model are serious problems. It’s very slow (and resource-intensive). It can be depressingly unreliable. That Salsa works as well as it does is a testament to the dedication of the Debian Salsa team (and those who support them, including DSA).

However, I have found that despite these problems, Salsa CI is well worth the trouble. Yes, there are frustrating days when work is blocked because gitlab CI is broken and/or one has to keep mashing “Retry”. But, the upside is no longer having to remember to run tests, track which of my multiple dev branches tests have passed on, and so on. Automatic tests on Merge Requests are a great way of reducing maintainer review burden for external contributions, and helping uphold quality norms within a team. They’re a great boon for the lazy solo programmer.

The bottom line is that I absolutely love it when the computer thoroughly checks my work. This is tremendously freeing, precisely at the point when one most needs it — deep in the code. If the price is to occasionally be blocked by a confused (or broken) computer, so be it.

Setup procedure

Create debian/salsa-ci.yml containing

include:
  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml

In your Salsa repository, under “Settings” / “CI/CD”, expand “General Pipelines” and set “CI/CD configuration file” to debian/salsa-ci.yml.

rationale

Your project may have an upstream CI config in .gitlab-ci.yml. But you probably want to run the Debian Salsa CI jobs.
You can add various extra configuration to debian/salsa-ci.yml to customise it. Consult the Salsa CI docs.

git-debrebase

Add to debian/salsa-ci.yml:

.git-debrebase-prepare: &git-debrebase-prepare
  # install the tools we'll need
  - apt-get update
  - apt-get --yes install git-debrebase git-debpush
  # git-debrebase needs git user setup
  - git config user.email "salsa-ci@invalid.invalid"
  - git config user.name "salsa-ci"
  # run git-debrebase make-patches
  # https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/371
  - git-debrebase --force
  - git-debrebase --noop-ok make-patches
  # make an orig tarball using the upstream tag, not a gbp upstream/ tag
  # https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/541
  - git-deborig

.build-definition: &build-definition
  extends: .build-definition-common
  before_script: *git-debrebase-prepare

build source:
  extends: .build-source-only
  before_script: *git-debrebase-prepare

variables:
  # disable shallow cloning of git repository. This is needed for git-debrebase
  GIT_DEPTH: 0

rationale

Unfortunately the Salsa CI pipeline currently lacks proper support for git-debrebase (salsa-ci#371) and has trouble directly using upstream git for orig tarballs (#salsa-ci#541).
These runes were based on those in the Xen package. You should subscribe to the tickets #371 and #541 so that you can replace the clone-and-hack when proper support is merged.

Push this to salsa and make the CI pass.

If you configured the pipeline filename after your last push, you will need to explicitly start the first CI run. That’s in “Pipelines”: press “New pipeline” in the top right. The defaults will very probably be correct.

Block untested pushes, preventing regressions

In your project on Salsa, go into “Settings” / “Repository”. In the section “Branch rules”, use “Add branch rule”. Select the branch master. Set “Allowed to merge” to “Maintainers”. Set “Allowed to push and merge” to “No one”. Leave “Allow force push” disabled.

This means that the only way to land anything on your mainline is via a Merge Request. When you make a Merge Request, gitlab will offer “Set to auto-merge”. Use that.

gitlab won’t normally merge an MR unless CI passes, although you can override this on a per-MR basis if you need to.

(Sometimes, immediately after creating a merge request in gitlab, you will see a plain “Merge” button. This is a bug. Don’t press that. Reload the page so that “Set to auto-merge” appears.)

autopkgtests

Ideally, your package would have meaningful autopkgtests (DEP-8 tests) This makes Salsa CI more useful for you, and also helps detect and defend you against regressions in your dependencies.

The Debian CI docs are a good starting point. In-depth discussion of writing autopkgtests is beyond the scope of this article.

Day-to-day work

With this capable tooling, most tasks are much easier.

Making changes to the package

Make all changes via a Salsa Merge Request. So start by making a branch that will become the MR branch.

On your MR branch you can freely edit every file. This includes upstream files, and files in debian/.

For example, you can:

Make changes with your editor and commit them.
git cherry-pick an upstream commit.
git am a patch from a mailing list or from the Debian Bug System.
git revert an earlier commit, even an upstream one.

When you have a working state of things, tidy up your git branch:

git merge

Use git-rebase to squash/edit/combine/reorder commits.

git-debrebase

Use git-debrebase -i to squash/edit/combine/reorder commits. When you are happy, run git-debrebase conclude.

Do not edit debian/patches/. With git-debrebase, this is purely an output. Edit the upstream files directly instead. To reorganise/maintain the patch queue, use git-debrebase -i to edit the actual commits.

Push the MR branch (topic branch) to Salsa and make a Merge Request.

Set the MR to “auto-merge when all checks pass”. (Or, depending on your team policy, you could ask for an MR Review of course.)

If CI fails, fix up the MR branch, squash/tidy it again, force push the MR branch, and once again set it to auto-merge.

Test build

An informal test build can be done like this:

apt-get build-dep .
dpkg-buildpackage -uc -b

Ideally this will leave git status clean, with no modified or un-ignored untracked files. If it shows untracked files, add them to .gitignore or debian/.gitignore as applicable.

If it dirties the tree, consider trying to make it stop doing that. The easiest way is probably to build out-of-tree, if supported upstream. If this is too difficult, you can leave the messy build arrangements as they are, but you’ll need to be disciplined about always committing, using git clean and git reset, and so on.

For formal binaries builds, including for testing, use dgit sbuild as described below for uploading to NEW.

Uploading to Debian

Start an MR branch for the administrative changes for the release.

Document all the changes you’re going to release, in the debian/changelog.

git merge

gbp dch can help write the changelog for you:

dgit fetch sid
gbp dch --ignore-branch --since=dgit/dgit/sid --git-log=^upstream/main

rationale

--ignore-branch is needed because gbp dch wrongly thinks you ought to be running this on master, but of course you’re running it on your MR branch.
The --git-log=^upstream/main excludes all upstream commits from the listing used to generate the changelog. (I’m assuming you have an upstream remote and that you’re basing your work on their main branch.) If there was a new upstream version, you’ll usually want to write a single line about that, and perhaps summarise anything really important.

(For the first upload after switching to using tag2upload or dgit you need --since=debian/1.2.3-1, where 1.2.3-1 is your previous DEP-14 tag, because dgit/dgit/sid will be a dsc import, not your actual history.)

Change UNRELEASED to the target suite, and finalise the changelog. (Note that dch will insist that you at least save the file in your editor.)

dch -r
git commit -m 'Finalise for upload' debian/changelog

Make an MR of these administrative changes, and merge it. (Either set it to auto-merge and wait for CI, or if you’re in a hurry double-check that it really is just a changelog update so that you can be confident about telling Salsa to “Merge unverified changes”.)

Now you can perform the actual upload:

git checkout master
git pull --ff-only # bring the gitlab-made MR merge commit into your local tree

git merge

git-debpush

git-debrebase

git-debpush --quilt=linear

--quilt=linear is needed only the first time, but it is very important that first time, to tell the system the correct git branch layout.

Uploading a NEW package to Debian

If your package is NEW (completely new source, or has new binary packages) you can’t do a source-only upload. You have to build the source and binary packages locally, and upload those build artifacts.

Happily, given the same git branch you’d tag for tag2upload, and assuming you have sbuild installed and a suitable chroot, dgit can help take care of the build and upload for you:

Prepare the changelog update and merge it, as above. Then:

git-debrebase

Create the orig tarball and launder the git-derebase branch:

git-deborig
git-debrebase quick

rationale

Source package format 3.0 (quilt), which is what I’m recommending here for use with git-debrebase, needs an orig tarball; it would also be needed for 1.0-with-diff.

Build the source and binary packages, locally:

dgit sbuild
dgit push-built

rationale

You don’t have to use dgit sbuild, but it is usually convenient to do so, because unlike sbuild, dgit understands git. Also it works around a gitignore-related defect in dpkg-source.

New upstream version

Find the new upstream version number and corresponding tag. (Let’s suppose it’s 1.2.4.) Check the provenance:

git verify-tag v1.2.4

rationale

Not all upstreams sign their git tags, sadly. Sometimes encouraging them to do so can help. You may need to use some other method(s) to check that you have the right git commit for the release.

git merge

Simply merge the new upstream version and update the changelog:

git merge v1.2.4
dch -v1.2.4-1 'New upstream release.'

git-debrebase

Rebase your delta queue onto the new upstream version:

git debrebase mew-upstream 1.2.4

If there are conflicts between your Debian delta for 1.2.3, and the upstream changes in 1.2.4, this is when you need to resolve them, as part of git merge or git (deb)rebase.

After you’ve completed the merge, test your package and make any further needed changes. When you have it working in a local branch, make a Merge Request, as above.

Sponsorship

git-based sponsorship is super easy! The sponsee can maintain their git branch on Salsa, and do all normal maintenance via gitlab operations.

When the time comes to upload, the sponsee notifies the sponsor that it’s time. The sponsor fetches and checks out the git branch from Salsa, does their checks, as they judge appropriate, and when satisfied runs git-debpush.

As part of the sponsor’s checks, they might want to see all changes since the last upload to Debian:

dgit fetch sid
git diff dgit/dgit/sid..HEAD

Or to see the Debian delta of the proposed upload:

git verify-tag v1.2.3
git diff v1.2.3..HEAD ':!debian'

git-debrebase

Or to show all the delta as a series of commits:

git log -p v1.2.3..HEAD ':!debian'

Don’t look at debian/patches/. It can be absent or out of date.

Incorporating an NMU

Fetch the NMU into your local git, and see what it contains:

dgit fetch sid
git diff master...dgit/dgit/sid

If the NMUer used dgit, then git log dgit/dgit/sid will show you the commits they made.

Normally the best thing to do is to simply merge the NMU, and then do any reverts or rework in followup commits:

git merge dgit/dgit/sid

git-debrebase

You should git-debrebase quick at this stage, to check that the merge went OK and the package still has a lineariseable delta queue.

Then make any followup changes that seem appropriate. Supposing your previous maintainer upload was 1.2.3-7, you can go back and see the NMU diff again with:

git diff debian/1.2.3-7...dgit/dgit/sid

git-debrebase

The actual changes made to upstream files will always show up as diff hunks to those files. diff commands will often also show you changes to debian/patches/. Normally it’s best to filter them out with git diff ... ':!debian/patches'

If you’d prefer to read the changes to the delta queue as an interdiff (diff of diffs), you can do something like

git checkout debian/1.2.3-7
git-debrebase --force make-patches
git diff HEAD...dgit/dgit/sid -- :debian/patches

to diff against a version with debian/patches/ up to date. (The NMU, in dgit/dgit/sid, will necessarily have the patches already up to date.)

DFSG filtering (handling non-free files)

Some upstreams ship non-free files of one kind of another. Often these are just in the tarballs, in which case basing your work on upstream git avoids the problem. But if the files are in upstream’s git trees, you need to filter them out.

This advice is not for (legally or otherwise) dangerous files. If your package contains files that may be illegal, or hazardous, you need much more serious measures. In this case, even pushing the upstream git history to any Debian service, including Salsa, must be avoided. If you suspect this situation you should seek advice, privately and as soon as possible, from dgit-owner@d.o and/or the DFSG team. Thankfully, legally dangerous files are very rare in upstream git repositories, for obvious reasons.

Our approach is to make a filtered git branch, based on the upstream history, with the troublesome files removed. We then treat that as the upstream for all of the rest of our work.

rationale

Yes, this will end up including the non-free files in the git history, on official Debian servers. That’s OK. What’s forbidden is non-free material in the Debianised git tree, or in the source packages.

Initial filtering

git checkout -b upstream-dfsg v1.2.3
git rm nonfree.exe
git commit -m "upstream version 1.2.3 DFSG-cleaned"
git tag -s -m "upstream version 1.2.3 DFSG-cleaned" v1.2.3+ds1
git push origin upstream-dfsg

And now, use 1.2.3+ds1, and the filtered branch upstream-dfsg, as the upstream version, instead of 1.2.3 and upstream/main. Follow the steps for Convert the git branch or New upstream version, as applicable, adding +ds1 into debian/changelog.

If you missed something and need to filter out more a nonfree files, re-use the same upstream-dfsg branch and bump the ds version, eg v1.2.3+ds2.

Subsequent upstream releases

git checkout upstream-dfsg
git merge v1.2.4
git rm additional-nonfree.exe # if any
git commit -m "upstream version 1.2.4 DFSG-cleaned"
git tag -s -m "upstream version 1.2.4 DFSG-cleaned" v1.2.4+ds1
git push origin upstream-dfsg

Removing files by pattern

If the files you need to remove keep changing, you could automate things with a small shell script debian/rm-nonfree containing appropriate git rm commands. If you use git rm -f it will succeed even if the git merge from real upstream has conflicts due to changes to non-free files.

rationale

Ideally uscan, which has a way of representing DFSG filtering patterns in debian/watch, would be able to do this, but sadly the relevant functionality is entangled with uscan’s tarball generation.

Common issues

Tarball contents: If you are switching from upstream tarballs to upstream git, you may find that the git tree is significantly different.
It may be missing files that your current build system relies on. If so, you definitely want to be using git, not the tarball. Those extra files in the tarball are intermediate built products, but in Debian we should be building from the real source! Fixing this may involve some work, though.
gitattributes:
For Reasons the dgit and tag2upload system disregards and disables the use of .gitattributes to modify files as they are checked out.
Normally this doesn’t cause a problem so long as any orig tarballs are generated the same way (as they will be by tag2upload or git-deborig). But if the package or build system relies on them, you may need to institute some workarounds, or, replicate the effect of the gitattributes as commits in git.
git submodules: git submodules are terrible and should never ever be used. But not everyone has got the message, so your upstream may be using them.
If you’re lucky, the code in the submodule isn’t used in which case you can git rm the submodule.

Vincent Bernat: Automatic Prometheus metrics discovery with Docker labels

Vincent Bernat — 2026-03-05T16:40:24+00:00

Akvorado, a network flow collector, relies on Traefik, a reverse HTTP proxy, to expose HTTP endpoints for services implemented in a Docker Compose setup. Docker labels attached to each service define the routing rules. Traefik picks them up automatically when a container starts. Instead of maintaining a static configuration file to collect Prometheus metrics, we can apply the same approach with Grafana Alloy, making its configuration simpler.

Traefik & Docker

Traefik listens for events on the Docker socket. Each service advertises its configuration through labels. For example, here is the Loki service in Akvorado:

services:
  loki:
    # â€¦
    expose:
      - 3100/tcp
    labels:
      - traefik.enable=true
      - traefik.http.routers.loki.rule=PathPrefix(`/loki`)

Once the container is healthy, Traefik creates a router forwarding requests matching /loki to its first exposed port. Colocating Traefik configuration with the service definition is attractive. How do we achieve the same for Prometheus metrics?

Metrics discovery with Alloy

Grafana Alloy, a metrics collector that can scrape Prometheus endpoints, includes a discovery.docker component. Just like Traefik, it connects to the Docker socket.¹ With a few relabeling rules, we can teach it to use Docker labels to locate and scrape metrics.

We define three labels on each service:

metrics.enable set to true enables metrics collection,
metrics.port specifies the port exposing the Prometheus endpoint, and
metrics.path specifies the path to the metrics endpoint.

If there is more than one exposed port, metrics.port is mandatory, otherwise it defaults to the only exposed port. The default value for metrics.path is /metrics. The Loki service from earlier becomes:

services:
  loki:
    # â€¦
    expose:
      - 3100/tcp
    labels:
      - traefik.enable=true
      - traefik.http.routers.loki.rule=PathPrefix(`/loki`)
      - metrics.enable=true
      - metrics.path=/loki/metrics

Alloyâ€™s configuration is split into four parts:

discover containers through the Docker socket,
filter and relabel targets using Docker labels,
scrape the matching endpoints, and
forward the metrics to Prometheus.

Discovering Docker containers

The first building block discovers running containers:

discovery.docker "docker" {
  host             = "unix:///var/run/docker.sock"
  refresh_interval = "30s"
  filter {
    name   = "label"
    values = ["com.docker.compose.project=akvorado"]
  }
}

This connects to the Docker socket and lists containers every 30 seconds.² The filter block restricts discovery to containers belonging to the akvorado project, avoiding interference with unrelated containers on the same host. For each discovered container, Alloy produces a target with labels such as __meta_docker_container_label_metrics_port for the metrics.port Docker label.

Relabeling targets

The relabeling step filters and transforms raw targets from Docker discovery into scrape targets. The first stage keeps only targets with metrics.enable set to true:

discovery.relabel "prometheus" {
  targets = discovery.docker.docker.targets

  // Keep only targets with metrics.enable=true
  rule {
    source_labels = ["__meta_docker_container_label_metrics_enable"]
    regex         = `true`
    action        = "keep"
  }

  // â€¦
}

The second stage overrides the discovered port when we define metrics.port:

// When metrics.port is set, override __address__.
rule {
  source_labels = ["__address__", "__meta_docker_container_label_metrics_port"]
  regex         = `(.+):\d+;(.+)`
  target_label  = "__address__"
  replacement   = "$1:$2"
}

Next, we handle containers in host network mode. When __meta_docker_network_name equals host, the address is rewritten to host.docker.internal instead of localhost:³

// When host networking, override __address__ to host.docker.internal.
rule {
  source_labels = ["__meta_docker_container_label_metrics_port", "__meta_docker_network_name"]
  regex         = `(.+);host`
  target_label  = "__address__"
  replacement   = "host.docker.internal:$1"
}

The next stage derives the job name from the service name, stripping any numbered suffix. The instance label is the address without the port:

rule {
  source_labels = ["__meta_docker_container_label_com_docker_compose_service"]
  regex         = `(.+)(?:-\d+)?`
  target_label  = "job"
}
rule {
  source_labels = ["__address__"]
  regex         = `(.+):\d+`
  target_label  = "instance"
}

If a container defines metrics.path, Alloy uses it as a path. Otherwise, it defaults to /metrics:

rule {
  source_labels = ["__meta_docker_container_label_metrics_path"]
  regex         = `(.+)`
  target_label  = "__metrics_path__"
}
rule {
  source_labels = ["__metrics_path__"]
  regex         = ""
  target_label  = "__metrics_path__"
  replacement   = "/metrics"
}

Scraping and forwarding

With the targets properly relabeled, scraping and forwarding are straightforward:

prometheus.scrape "docker" {
  targets         = discovery.relabel.prometheus.output
  forward_to      = [prometheus.remote_write.default.receiver]
  scrape_interval = "30s"
}

prometheus.remote_write "default" {
  endpoint {
    url = "http://prometheus:9090/api/v1/write"
  }
}

prometheus.scrape periodically fetches metrics from the discovered targets. prometheus.remote_write sends them to Prometheus.

Built-in exporters

Some services do not expose a Prometheus endpoint. Redis and Kafka are common examples. Alloy ships built-in Prometheus exporters that query these services and expose metrics on their behalf.

prometheus.exporter.redis "docker" {
  redis_addr = "redis:6379"
}
discovery.relabel "redis" {
  targets = prometheus.exporter.redis.docker.targets
  rule {
    target_label = "job"
    replacement  = "redis"
  }
}
prometheus.scrape "redis" {
  targets         = discovery.relabel.redis.output
  forward_to      = [prometheus.remote_write.default.receiver]
  scrape_interval = "30s"
}

The same pattern applies to Kafka:

prometheus.exporter.kafka "docker" {
  kafka_uris = ["kafka:9092"]
}
discovery.relabel "kafka" {
  targets = prometheus.exporter.kafka.docker.targets
  rule {
    target_label = "job"
    replacement  = "kafka"
  }
}
prometheus.scrape "kafka" {
  targets         = discovery.relabel.kafka.output
  forward_to      = [prometheus.remote_write.default.receiver]
  scrape_interval = "30s"
}

Each exporter is a separate component with its own relabeling and scrape configuration. The job label is set explicitly since there is no Docker metadata to derive it from.

With this setup, adding metrics to a new service with a Prometheus endpoint is a few-label change in docker-compose.yml, just like adding a Traefik route. Alloy picks it up automatically. You can set up something similar with another discovery method, like discovery.kubernetes, discovery.scaleway, or discovery.http. ðŸ©º

Both Traefik and Alloy require access to the Docker socket, which grants root-level access to the host. A Docker socket proxy mitigates this by exposing only the read-only API endpoints needed for discovery.Â â†©ï¸Ž
Unlike Traefik, which watches for events, Grafana Alloy polls the container list at regular intervalsâ€”a behavior inherited from Prometheus.Â â†©ï¸Ž
The Alloy service needs extra_hosts: ["host.docker.internal:host-gateway"] in its definition.Â â†©ï¸Ž

Dirk Eddelbuettel: RcppGSL 0.3.14 on CRAN: Maintenance

Dirk Eddelbuettel — 2026-03-05T16:05:00+00:00

A new release 0.3.14 of RcppGSL is now on CRAN. The RcppGSL package provides an interface from R to the GNU GSL by relying on the Rcpp package. It has already been uploaded to Debian, and is also already available as a binary via r2u.

This release, the first in over three years, contains mostly maintenance changes. We polished the fastLm example implementation a little more, updated continunous integration as one does over such a long period, adopted the Authors@R convention, switched the (pre-made) pdf vignette to a new driver now provided by Rcpp, updated vignette references and URLs, and updated one call to Rf_error to aid in a Rcpp transition towards using only Rcpp::stop which unwinds error conditions better. (Technically this was a false positive on Rf_error but on the margin worth tickling this release after all this time.)

The NEWS entry follows:

Changes in version 0.3.14 (2026-03-05)

Updated some internals of fastLm example, and regenerated RcppExports.* files

Several updates for continuous integration

Switched to using Authors@R

Replace ::Rf_error with (Rf_error) in old example to aid Rcpp transition to Rcpp::stop (or this pass-through)

Vignette now uses the Rcpp::asis builder for pre-made pdfs

Vignette references have been updated, URLs prefer https and DOIs

Thanks to my CRANberries, there is also a diffstat report for this release. More information is on the RcppGSL page. Questions, comments etc should go to the issue tickets at the GitHub repo.

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

Sean Whitton: Southern Biscuits with British ingredients

Sean Whitton — 2026-03-04T20:47:28+00:00

I miss the US more and more, and have recently been trying to perfect Southern Biscuits using British ingredients. It took me eight or nine tries before I was consistently getting good results. Here is my recipe.

Ingredients

190g plain flour
60g strong white bread flour
4 tsp baking powder
¼ tsp bicarbonate of soda
1 tsp cream of tartar (optional)
1 tsp salt
100g unsalted butter
180ml buttermilk, chilled
- If your buttermilk is thicker than the consistency of ordinary milk, you’ll need around 200ml.
extra buttermilk for brushing

Method

Slice and then chill the butter in the freezer for at least fifteen minutes.
Preheat oven to 220°C with the fan turned off.
Twice sieve together the flours, leaveners and salt. Some salt may not go through the sieve; just tip it back into the bowl.
Cut cold butter slices into the flour with a pastry blender until the mixture resembles coarse crumbs: some small lumps of fat remaining is desirable. In particular, the fine crumbs you are looking for when making British scones are not wanted here. Rubbing in with fingertips just won’t do; biscuits demand keeping things cold even more than shortcrust pastry does.
Make a well in the centre, pour in the buttermilk, and stir with a metal spoon until the dough comes together and pulls away from the sides of the bowl. Avoid overmixing, but I’ve found that so long as the ingredients are cold, you don’t have to be too gentle at this stage and can make sure all the crumbs are mixed in.
Flour your hands, turn dough onto a floured work surface, and pat together into a rectangle. Some suggest dusting the top of the dough with flour, too, here.
Fold the dough in half, then gather any crumbs and pat it back into the same shape. Turn ninety degrees and do the same again, until you have completed a total of eight folds, two in each cardinal direction. The dough should now be a little springy.
Roll to about ½ inch thick.
Cut out biscuits. If using a round cutter, do not twist it, as that seals the edges of the biscuits and so spoils the layering.
Transfer to a baking sheet, placed close together (helps them rise). Flour your thumb and use it to press an indent into the top of each biscuit (helps them rise straight), brush with buttermilk.
Bake until flaky and golden brown: about fifteen minutes.

Gravy

It turns out that the “pepper gravy” that one commonly has with biscuits is just a white/béchamel sauce made with lots of black pepper. I haven’t got a recipe I really like for this yet. Better is a “sausage gravy”; again this has a white sauce as its base, I believe. I have a vegetarian recipe for this to try at some point.

Variations

These biscuits do come out fluffy but not so flaky. For that you can try using lard instead of butter, if you’re not vegetarian (vegetable shortening is hard to find here).
If you don’t have a pastry blender and don’t want to buy one you can try not slicing the butter and instead coarsely grating it into the flour out of the freezer.
An alternative to folding is cutting and piling the layers.
You can try rolling out to 1–1½ inches thick.
Instead of cutting out biscuits you can just slice the whole piece of dough into equal pieces. An advantage of this is that you don’t have to re-roll, which latter also spoils the layering.
Instead of brushing with buttermilk, you can take them out after they’ve started to rise but before they’ve browned, brush them with melted butter and put them back in.

Notes

I’ve had more success with Dale Farm’s buttermilk than Sainsbury’s own. The former is much runnier.
Southern culture calls for biscuits to be made the size of cat’s heads.
Bleached flour is apparently usual in the South, but is illegal(!) here. Apparently bleaching can have some effect on the development of the gluten which would affect the texture.
British plain flour is made from soft wheat and has a lower percentage of protein/gluten, while American all-purpose flour is often(?) made from harder wheat and has more protein. In this recipe I mix plain and strong white flour, in a ratio of 3:1, to emulate American all-purpose flour.

I am not sure why this works best. In the South they have soft wheats too, and lower protein percentages. The famous White Lily flour is 9%. (Apparently you can mix US cake flour and US all-purpose flour in a ratio of 1:1 to achieve that; in the UK, Shipton Mill sell a “soft cake and pastry flour” which has been recommended to me as similar.)

This would suggest that British plain flour ought to be closer to Southern flour than the standard flour available in most of the US. But my experience has been that the biscuits taste better with the plain and strong white 3:1 mix. Possibly Southeners would disprefer them. I got some feedback that good biscuits are about texture and moistness and not flavour.
Baking powder in the US is usually double-acting but ours is always single-acting, so we need double quantities of that.

Sean Whitton: dgit-as-a-service retrospective

Sean Whitton — 2026-03-04T20:45:47+00:00

We recently launched tag2upload, aka cloud dgit or dgit-as-a-service. This was something of a culmination of work I’ve been doing since 2016 towards modernising Debian workflows, so I thought I’d write a short personal retrospective.

When I started contributing to Debian in 2015, I was not impressed with how packages were represented in Git by most package maintainers, and wanted a pure Git workflow. I read a couple of Joey Hess’s blog posts on the matter, a rope ladder to the dgit treehouse and upstream git repositories and made a bug report against dgit hoping to tie some things together.

The results of that early work were the git-deborig(1) program and the dgit-maint-merge(7) tutorial manpage. Starting with Joey’s workflow pointers, I developed a complete, pure Git workflow that I thought would be suitable for all package maintainers in Debian. It was certainly well-suited for my own packages. It took me a while to learn that there are packages for which this workflow is too simple. We now also have the dgit-maint-debrebase(7) workflow which uses git-debrebase, something which wasn’t invented until several years later. Where dgit-maint-merge(7) won’t do, you can use dgit-maint-debrebase(7), and still be doing pretty much pure Git. Here’s a full, recent guide to modernisation.

The next most significant contribution of my own was the push-source subcommand for dgit. dgit push required a preexisting .changes file produced from the working tree. I wanted to make dgit push-source prepare that .changes file for you, but also not use the working tree, instead consulting HEAD. The idea was that you were doing a git push – which doesn’t care about the working tree – direct to the Debian archive, or as close as we could get. I implemented that at DebConf18 in Taiwan, I think, with Ian, and we also did a talk on git-debrebase. We ended up having to change it to look at the working tree in addition to HEAD to make it work as well as possible, but I think that the idea of a command which was like doing a Git push direct to the archive was perhaps foundational for us later wanting to develop tag2upload. Indeed, while tag2upload’s client-side tool git-debpush does look at the working tree, it doesn’t do so in a way that is essential to its operation. tag2upload is dgit push-source-as-a-service.

And finally we come to tag2upload, a system Ian and I designed in 2019 during a two-person sprint at his place in Cambridge, while I was visiting the UK from Arizona. With tag2upload, appropriately authorised Debian package maintainers can upload to Debian with only pure Git operations – namely, making and pushing a signed Git tag to Debian’s GitLab instance. Although we had a solid prototype in 2019, we only finally launched it last month, February 2026. This was mostly due to political delays, but also because we have put in a lot of hours making it better in various ways.

Looking back, one thing that seems notable to me is that the core elements of the pure Git workflows haven’t changed much at all. Working out all the details of dgit-maint-merge(7), designing and writing git-debrebase (Ian’s work), and then working out all the details of dgit-maint-debrebase(7), are the important parts, to me. The rest is mostly just large amounts of compatibility code. git-debrebase and dgit-maint-debrebase(7) are very novel but dgit-maint-merge(7) is mostly just an extrapolation of Joey’s thoughts from 13 years ago. And yet, adoption of these workflows remains low.

People prefer to use what they are used to using, even if the workflows have significant inconveniences. That’s completely understandable; I’m really interested in good workflows, but most other contributors care less about it. But you would expect enough newcomers to have arrived in 13 years that the new workflows would have a higher uptake. That is, packages maintained by contributors that got involved after these workflows became available would be maintained using newer workflows, at least. But the inertia seems to be too strong even for that. Instead, new contributors used to working purely out of Git are told they need to learn Debian’s strange ways of representing things, tarballs and all. It doesn’t have to be that way. We hope that tag2upload will make the pure Git workflows seem more appealing to people.

Jonathan Dowland: More lava lamps

jmtd — 2026-03-04T16:21:23+00:00

Mathmos had a sale on spare Lava lamp bottles around Christmas, so I bought a couple of new-to-me colour combinations.

The lamp I have came with orange wax in purple liquid, which gives a strong red glow in a dark room. I bought blue wax in purple liquid, which I think looks fantastic and works really nicely with my Rob Sheridan print.

The other one I bought was pink in clear, which is nice, but I think the coloured liquids add a lot to the tone of lighting in a room.

Recently, UK vid-blogger Techmoan did some really nice videos about Mathmos lava lamps: Best Lava Lamp? and LAVA LAMPS Giant, Mini & Neo.

Dirk Eddelbuettel: tidyCpp 0.0.9 on CRAN: More (forced) Maintenance

Dirk Eddelbuettel — 2026-03-04T11:54:00+00:00

Another maintenance release of the tidyCpp package arrived on CRAN this morning. The packages offers a clean C++ layer (as well as one small C++ helper class) on top of the C API for R which aims to make use of this robust (if awkward) C API a little easier and more consistent. See the vignette for motivating examples.

This release follows a similar release in November and had its hand forced by rather abrupt and forced overnight changes in R-devel, this time the removal of VECTOR_PTR in [this commit]. The release also contains changes accumulated since the last release (including some kindly contritbuted by Ivan) and those are signs that the R Core team can do more coordinated release management when they try a little harder.

Changes are summarize in the NEWS entry that follows.

Changes in tidyCpp version 0.0.9 (2026-03-03)

Several vignette typos have been corrected (#4 addressing #3)

A badge for r-universe has been added to the README.md

The vignette is now served via GitHub Pages and that version is referenced in the README.

Two entry points reintroduced and redefined using permitted R API function (Ivan Krylov in #5).

Another entry has been removed to match R-devel API changes.

Six new attributes helpers have been added for R 4.6.0 or later.

VECTOR_PTR_RO(x) replaces the removed VECTOR_PTR, a warning or deprecation period would have been nice here.

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

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

Daniel Pocock: Mauvaise foi : Hugo Roy savait que la FSFE se faisait passer pour la FSF devant le tribunal français, ses collègues ont été trompés.

Daniel Pocock — 2026-03-03T13:00:00+00:00

Les avocats ne sont généralement pas responsables des crimes de leurs clients. Si le client ment sous serment et que l'avocat n'est pas au courant du mensonge, ce dernier ne peut être tenu responsable.

Toutefois, dans les cas où l'avocat aide sciemment et volontairement son client à tromper le juge, les conséquences peuvent être extrêmement graves pour lui.

Par exemple, dans certaines affaires récentes, des avocats ont eu recours à l'intelligence artificielle pour rédiger des documents juridiques. Dans ces cas précis, il est évident pour tous que c'est l'avocat, et non le client, qui a pris un raccourci.

Dans le cas des marginaux de la FSFE , on constate que l'avocat français Hugo Roy a effectué un stage auprès d'eux en 2009. En 2011, il a intégré l'Assemblée générale (AG) de la FSFE. L'AG est la liste de diffusion privée où les initiés et les marginaux discutent et complotent contre le reste de la communauté du logiciel libre. Elle est comparable au groupe secret (et divulgué) de debian-private , où les débianistes dissidents se livrent à des actes tels que de fausses accusations de viol .

En mai 2017, la véritable FSF a réitéré sa demande aux marginaux de la FSFE de cesser d'utiliser le nom FSFE en raison de la confusion qu'il engendre.

La demande a été partagée avec tous les membres de la liste de diffusion de GA. Jonas Oberg , le directeur exécutif, nous a indiqué que la véritable FSF avait raison et que les membres de la FSFE n'avaient pas le droit d'utiliser un nom suggérant une affiliation avec la véritable FSF et le Dr Richard Stallman . De fait, ces membres de la FSFE se livrent à une usurpation d'identité , ou à une forme de fraude nigériane, chaque fois qu'ils utilisent le nom FSFE sur un document.

Voici la discussion de mai 2017. Tous les membres de l'Assemblée générale, y compris Hugo Roy , l'ont vue :

Commentaires de Jonas Oberg , le directeur général :

Objet : Re: La FSF nous demande de changer de nom II
Date : mar. 30 mai 2017 15:31:39 +0200
De : Jonas Oberg <jonas@fsfe.org>
À : Bernhard Reiter <bernhard@intevation.de>
CC : ga@fsfeurope.org

Salut Bernhard ,

Je suis globalement d'accord avec vous, mais j'aimerais vous demander une précision sur un point.
cette partie :

Je ne vois pas pourquoi. Nous devrions leur demander de mettre en place la coopération convenue.

Si j'examine honnêtement l'accord-cadre, je crois que c'est
formulé de manière plutôt favorable à la FSF, et beaucoup de ce que nous ferions
J'aimerais voir – par exemple, une prise de décision conjointe sur des questions importantes liées
au logiciel libre – cela ne figure pas réellement dans l'accord, mis à part une intention.
développer une telle voie dans un futur hypothétique.

Et je comprends parfaitement pourquoi la FSF estime que nous sommes en infraction avec la loi.
accord, [ ... extrait ... ]

[ ... extrait ... ]

L'accord-cadre, en l'état, n'est donc pas respecté.
N'importe quel côté. [ ... extrait ... ]

[ ... extrait ... ]

Sincèrement,

--
Jonas Öberg, directeur exécutif
Fondation européenne du logiciel libre | jonas@fsfe.org
Votre soutien nous permet de poursuivre notre travail (fsfe.org/join)

Quelques mois plus tard, lors de la discussion sur le conflit d'intérêts, Hugo Roy a confirmé qu'il était avocat, autorisé à exercer au barreau de Paris et employé par Baker McKenzie :

Objet : Re: conflit d'intérêts
Date : mar. 15 août 2017 08:27:29 +0000
De : Hugo Roy <hugo@fsfe.org>
À : ga@fsfeurope.org

Salut,

-----
En résumé : il faudrait plus de transparence sur ces questions au sein de l’Assemblée générale.
Du moins, et c'est ce que nous avons fait. Donc, pour ceux qui ne le font pas...
Sachez-le : je suis avocat et je conseille des clients qui se trouvent être de grandes entreprises.
Les fournisseurs de logiciels propriétaires également.
-----

Je ne vois rien de mal pour le moment dans la façon dont nous fonctionnons actuellement.
Je gère ça. Ce que je veux dire, c'est qu'aucun problème n'est apparu et que je
Je n'y ai pas vraiment réfléchi. D'ailleurs, (peut-être ai-je aussi analysé la discussion)
(Je vais vite, alors excusez-moi si je me trompe sur certains points, mais je ne pense pas que ce soit le cas.)
Quelqu'un ici a suggéré que toutes les informations divulguées conformément à une
La politique en matière de conflits d'intérêts serait nécessairement publique, voire même élaborée.
public par défaut.

Cependant, ces problèmes n'apparaissent pas toujours explicitement, il arrive parfois
plus pernicieux que cela (sans vouloir sous-entendre aucune malice)
ici).

Je ne serais *pas* à l'aise si je le découvrais par moi-même.
Coïncidence ou pas, qu'un membre de GA soit chez Microsoft, Red Hat ou Facebook ?
membre du personnel.

Je pense qu'il est important qu'au sein du groupe GA, nous ayons certains
visibilité sur ces sujets. Nous sommes un petit groupe et nous devrions connaître chaque élément.
autre. Et cela exige aussi une certaine transparence --- car il s'agit d'un
le fait que nous ne nous connaissons pas tous forcément bien, ne serait-ce que pour le
le fait que certains membres aient adhéré récemment.

Or, quelqu'un a fait remarquer à juste titre que pour ceux qui sont travailleurs indépendants,
Cela serait plus logique si la divulgation des plus gros clients était faite ; mais voilà.
difficilement possible (les gros clients ont tendance à exiger la confidentialité).

Il semblerait que cela me concerne. Je suis avocat et je travaille dans un grand cabinet.
cabinet ( Baker McKenzie ) --- cela ne vous donnera probablement pas d'informations intéressantes
informations à des fins de déclaration de conflit d'intérêts. Cependant, je ne suis pas à
liberté de divulguer mes clients ou ceux du cabinet — bien que je puisse dire que
Ils comprennent notamment de grands éditeurs de logiciels propriétaires, ce qui ne devrait guère être le cas.
Cela peut paraître surprenant ; après tout, je donne des conseils en droit informatique.

Meilleur,
Hugo

Peu après, Hugo Roy s'est activement impliqué dans la désignation d'un autre avocat français pour intenter une action en justice en France contre le ministère de la Défense. Hugo Roy a transmis des informations à cet avocat. Il savait que le nom de la Free Software Foundation Europe figurerait dans les documents judiciaires publics et que le public l'associerait à la véritable FSF et au Dr Richard Stallman . Il semble qu'il n'ait averti ni l'avocat chargé de la procédure, ni l'avocat qui a présenté l'affaire devant le tribunal, de cette usurpation d'identité et du litige en cours.

Objet : Décision d'intenter une action en justice contre l'armée française – Contrat Microsoft
Date : jeu. 26 oct. 2017 17:32:56 +0200
De : Hugo Roy <hugo@fsfe.org>
À : team@lists.fsfe.org

Désolé, je suis pressé.

Avons-nous déjà pris une décision ?
--
Envoyé depuis mon mobile

Objet : Re: Tr: CONTRAT MICROSOFT (Ministre français de la Défense)
Date : Sam., 28 oct. 2017 02:41:49 +0561
De : Hugo Roy <hugo@fsfe.org>
À : Alexis Fitzjean O Cobhthaigh <afoc.avocat@gmail.com>, france@lists.fsfe.org, Matthias Kirschner <mk@fsfe.org>, team@lists.fsfe.org


Salut tout le monde,

J'ai pris contact avec Nexedi et April aujourd'hui, pour m'assurer que le lancement
Cette action n'aurait pas d'effets néfastes sur eux. Tout semble
Très bien --- Alexis, n'hésite pas à donner ton avis.

Meilleur,
Hugo

↪ Matthias Kirschner / 27 octobre 2017 11:57 :
Bonjour Alexis, bonjour Hugo,
>
Comme je viens de le convenir avec Hugo : oui, allez-y. J’ai pleinement confiance.
Je vous en parle. On pourrait régler certains détails la semaine prochaine.
(Je serai de retour mercredi). Au cas où il y aurait quelque chose d'urgent d'ici là,
> veuillez m'appeler).
>
Meilleurs vœux,
> Matthias
>
> * Hugo Roy [2017-10-27 09:06 +0200] :
>> 1) Nous devrions déposer une demande auprès du CADA dès que possible pour tenter d'obtenir
>> les parties effacées du contrat.
>>
>> Il faut faire vite. C'est assez facile et je le ferai *bénévolement*.
Je ne suis pas sûr que ce soit très utile, mais ça vaut le coup d'essayer.
>> déposé dans les deux mois suivant la réception de la réponse du ministère
>> (Pourriez-vous confirmer la date ?)
>>
>> 2) Je pense que nous devrons déposer une plainte devant le tribunal administratif de
>> Paris (*avant le lundi 30 octobre*).
>
> [...]
>
Pour cette partie, je peux baisser mon tarif horaire à 125 $ avant taxes (150 $ taxes incluses).
>> inclus). Et, si nous portons plainte par précaution et que vous choisissez ensuite de
>> Retirez-le une semaine plus tard, je ne facturerai rien.
>
> --
Matthias Kirschner - Président - Free Software Foundation Europe
> Schönhauser Allee 6/7, 10119 Berlin, Allemagne | +49-30-27595290
> Enregistré auprès de l'Amtsgericht Hamburg, VR 17030 | (fsfe.org/join)
> Contact (fsfe.org/about/kirschner) - Blog (k7r.eu/blog.html)
>

Sujet : Tr : Re : Re : Affaire Microsoft
Date : dim. 5 nov. 2017 01:13:04 +0561
De : Hugo Roy <hugo@fsfe.org>
À : team@lists.fsfe.org


Salut tout le monde,

Pour information, voici le mémoire déposé auprès du tribunal de Paris dans l'affaire Microsoft.
Placez tous les dossiers de cas dans le SVN interne.

Meilleur,
Hugo

Sujet : Re: Re: Affaire Microsoft
De : Alexis Fitzjean O Cobhthaigh <afoc.avocat@gmail.com>
Date : 31/10/2017, 12:02
À : Hugo Roy <hugo@fsfe.org>
CC : france@lists.fsfe.org

Bonjour à tous,

La requête a bien été enregistrée, par le tribunal administratif de Paris, sous le n° 1716711.

Je vous mets en pièce jointe un exemplaire, au format PDF, de la requête telle qu'elle a été déposée hier soir.

Je reste naturellement à votre disposition si vous souhaitez que l'on échange, par écrit ou de vive-voix, sur ce dossier.

Alexis

Le 30 octobre 2017 à 22:07, Hugo Roy <hugo@fsfe.org> a écrit :


    La requête a été déposée aujourd'hui. Alexis, tu peux nous envoyer le
    PDF officiel lorsqu'il est prêt ?

    Merci

    PS : garder france@ en copie autant que possible - désolé je n'ai pas eu eu
    le temps du faire aujourd'hui


    ---------- Message transféré ----------
    De : Alexis Fitzjean O Cobhthaigh <afoc.avocat@gmail.com>
    À : Frédéric Couchet <fcouchet@april.org>
    Cc : Hugo Roy <hugo@hugoroy.eu>, Étienne GONNU <egonnu@april.org>
    Date : lundi 30 octobre 2017 10:00:35 +0100
    Objet : Re : Affaire Microsoft
    Bonjour à tous,

    Comme convenu lors de notre discussion vendredi avec Hugo (en copie), vous trouverez en pièce jointe le projet de requête sommaire que je m'apprête à déposer dans la journée pour la FSFE. J'ai fait au mieux dans un délai si réduit, étant précisé que l'argumentation pourra être complétée ultérieurement.

    Vos éventuelles remarques et suggestions sont bien entendues les bienvenues. J'envisage un dépôt dans l'après-midi, en ajoutant quelques modifications et corrections mineures.

    N'hésitez pas à m'appeler à mon cabinet au besoin pour en discuter.

    Bien à vous,

    Alexis FITZJEAN Ó COBHTHAIGH
    Avocat au Barreau de Paris / Avocat au Barreau de Paris
    Chargé d'enseignement à l'Université Paris II Panthéon-Assas
    c/o SCP MARLANGE-de la BURGADE
    5, rue Daunou 75002 PARIS
    afoc.avocat@gmail.com
    Tél : (+33)1.53.63.33.10 Fax : (+33)1.45.48.90.09


    PRIVILÉGIÉ ET CONFIDENTIEL/CONFIDENTIEL

    Ce message contient des informations privilégiées et confidentielles. Si vous n'êtes pas le destinataire désigné, veuillez le détruire sans le lire, le copier ni en divulguer le contenu à quiconque.
    Cet e-mail contient des informations confidentielles protégées par le secret professionnel. S'il ne vous est pas destiné, nous vous remercions de le détruire immédiatement, sans le copier, ni révéler ou transmettre son contenu à qui que ce soit. &ZeroWidthSpace

    Le 28 octobre 2017 à 16:08, Frédéric Couchet <fcouchet@april.org> a écrit :


        Bonjour à vous,

        >>>>> Étienne GONNU <egonnu@april.org> écrit :

            > J'en profite également pour une autre précision: sur quelle liste,
            > ou avec qui, le sujet de l'action de la FSFE a t'il été évoqué via
            > courriel ? Je n'en trouve pas trace dans mon courrielleur.

        pareil, je n'ai aucune trace d'un quelconque échange sur ce sujet, mais
        nous avons pu louper quelque chose :)

        Librement,
        Fred.
        --
        Avril - Promouvoir et défendre le logiciel libre

        https://www.april.org

Objet : Fwd : 1716711 - FSFE vs Ministre des armées (Ministry of Defence) - Mémoire en défense (defence)
Date : jeu. 19 avr. 2018 17:15:07 +0200
De : Hugo Roy <hugo@fsfe.org>
À : team@lists.fsfe.org, legal@lists.fsfe.org
CC : france@lists.fsfe.org

Salut tout le monde,

Petit point sur l'affaire contre Microsoft (tous les documents sont dans le dossier)
SVN interne).

Nous avons reçu la réponse du gouvernement. Il semble qu'ils traitent
Cela fait l'objet d'une attention particulière. Alexis , notre avocate dans cette affaire, est
Nous préparons un projet qui sera partagé avec france@ lundi.
Partagez-le également avec April (et éventuellement d'autres personnes) pour obtenir leurs commentaires.

Vous trouverez ci-joint le courriel d'Alexis à ce sujet, au cas où cela vous intéresserait.
et également la réponse du gouvernement français.

Notre réponse au gouvernement doit être adressée au tribunal de Paris avant
Le 30 avril, ce qui nous laisse (fsfe) un peu moins d'une semaine pour examiner
Le brouillon d'Alexis .

Si vous avez des questions, n'hésitez pas !

Meilleur,
Hugo

Objet : 1716711 - FSFE vs Ministre des armées (Ministry of Defence) - Mémoire en défense (defence)
De : Alexis Fitzjean O Cobhthaigh <afoc.avocat@gmail.com>
Date : 06/04/2018, 18:56
À : Matthias Kirschner <mk@fsfe.org>, france@lists.fsfe.org, Hugo Roy <hugo@fsfe.org>

Bonjour à tous,

Veuillez trouver ci-joint la défense du Ministère. C'est formidable, car nous savons maintenant où nous allons. Sans surprise.

1) Le ministère soutient que la juridiction compétente n'est pas le tribunal administratif de Paris, mais celui de Melun (ville très proche de Paris). Cela n'a pas d'incidence majeure : même si le tribunal compétent est celui de Melun et non celui de Paris, le tribunal de Paris transmettra simplement l'affaire à celui de Melun (aucun risque d'incompétence ou d'irrecevabilité à ce sujet).

2) Sans surprise, le ministère soutient que FSFE n'a pas qualité pour agir car elle n'est pas concurrente de Microsoft. Rien d'étonnant.

3) Le ministère écrit, sur plusieurs pages, que ce contrat est parfaitement normal. Rien de surprenant. Le tribunal devra trancher. Or, d'ordinaire, le ministère ne consacre que six ou sept pages aux affaires simples portées devant le tribunal administratif. Cela confirme donc qu'il y a bien matière à contester, même si la tâche s'annonce ardue. Mon avis : ils sont vraiment mécontents de notre situation.

4) Plus étonnant encore, le ministère demande que le Tribunal condamne la FSFE à 3000 euros de frais de procédure, ce qui est beaucoup pour ce type d'affaire.

Pour l'équipe de France :

C'est intéressant qu'ils aient produit dès à présent car cela va nous permettre de répliquer utilement, plutôt que de produire une nouvelle mémoire "dans le vide".

En résumé, il y a 3 points sur lesquels répondre :
- l'intérêt à agir de la FSFE ;
- le moyen sur l'absence de publicité et de mise en concurrence ;
- le moyen sur l'abus de position dominante.

Ce qui est intéressant c'est que, même s'ils contestent la recevabilité de notre recours, ils ont quand même jugé utile de répondre significativement sur le fond et, surtout, d'ajouter à titre subsidiaire que, si le TA estime notre action recevable ET fondée, il devrait qu'il prenne en compte l'intérêt général pour moduler les effets de la décision qu'il rend. Cela montre bien qu'ils ne sont pas très à l'aise et, à tout le moins, qu'ils nous prennent au sérieux. S'ils étaient sûrs d'eux ils n'auraient pas pris la peine de produire une défense aussi substantielle.

Autre point : demander 3 000 euros de frais de procédure, de la part de l'Etat, devant le TA, contre une ONG, c'est très rare et cela montre bien que ce recours les agace et, peut-être que cela les inquiète aussi.

Enfin, le recours est signé par Claire Legras, qui est la directrice des affaires juridiques du ministère en personne. C'est très rare que ce soit la DAJ qui signe devant le TA, ce qui montre bien qu'ils nous prennent au sérieux.

A titre plus subsidiaire, s'agissant de la communication d'autres documents, le ministère mélange un peu tout. Sa réponse se place sur le terrain des règles applicables aux procédures CADA (les documents demandés doivent être désignés de manière suffisamment précise) et non celles, autonomes, qui régissent les pouvoirs d'instruction du juge administratif (les parties peuvent suggérer des documents mais c'est le juge qui, in fine, décide lequel il demande la production). Je prépare également une réponse sur ce point, en précisant que l'on souhaite la production des notes préparatoires sur lesquelles le ministère a décidé de ne pas utiliser à une procédure d'appel d'offres préalable.

Je vous remercie de me faire part de vos observations d'ici vendredi 13 mars prochain. De sorte que je peux ensuite avoir le temps de les intégrer et de vous envoyer un projet la semaine suivante, pour un dépôt qui doit intervenir, en toute hypothèse, avant le 30 avril (date de la clôture de l'instruction).

Salutations,
Alexis

Alexis FITZJEAN Ó COBHTHAIGH

Avocat au Barreau de Paris / Avocat au Barreau de Paris
Chargé d'enseignement à l'Université Paris II Panthéon-Assas
c/o SCP MARLANGE-de la BURGADE
5, rue Daunou 75002 PARIS
afoc.avocat@gmail.com
Tél : (+33)1.53.63.33.10 Fax : (+33)1.45.48.90.09

En 2019, Hugo Roy a été démis de ses fonctions au sein du groupe dissident FSFE . Ce groupe n'a publié aucune déclaration publique concernant sa démission. A-t-il démissionné suite aux attaques contre ma famille ou à cause de la plainte pour harcèlement sexuel déposée par Galia Mancheva ?

En 2020, un tribunal berlinois a rendu un jugement dans une affaire de harcèlement sexuel . Le nom de la « Free Software Foundation Europe » figure dans les documents juridiques. Une fois de plus, un observateur non averti consultant ces documents pourrait croire, à tort, qu'il s'agit de la véritable FSF et du Dr Richard Stallman .

Le jugement a finalement été rendu contre la Free Software Foundation Europe (FSFE) le jour de l'anniversaire d'Hitler .

Les gens examineront le jugement rendu contre la FSFE et auront l'impression qu'il s'agit d'un jugement contre la véritable FSF et le Dr Richard Stallman .

Par conséquent, nous pouvons conclure hors de tout doute raisonnable que le Tribunal administratif de Melun a été trompé en publiant un jugement sous le nom usurpé par le plaignant.

Lorsque Hugo Roy a mandaté un autre avocat pour présenter les documents au tribunal, sachant que le demandeur n'avait pas le droit d'utiliser ce nom, il savait que le tribunal et le public seraient induits en erreur. Par conséquent, s'il n'a pas averti le tribunal et les autres avocats de ce problème, s'il le leur a dissimulé, il a agi de mauvaise foi et a manqué aux obligations déontologiques des avocats dans leurs interactions avec le tribunal.

Veuillez visionner ma vidéo de campagne de financement participatif et en discuter avec votre communauté dès aujourd'hui .

Ben Hutchings: FOSS activity in February 2026

Ben Hutchings — 2026-03-02T16:28:58+00:00

Debian packages:
- firmware-free:
  - Bugs:
    - closed #890601: firmware-linux-free uses prebuilt blobs instead of building from source
  - Uploads:
    - uploaded version 20241210-3 to unstable
- firmware-nonfree:
  - Bugs:
  - Merge requests:
    - closed !128: Draft: Add Provides: based ABI versioning mechanism
    - merged !134: Update to 20251125
    - reviewed and merged !135: Drop DSP firmware, migrated to hexagon-dsp-binaries source
    - reviewed and merged !136: debian/copyright: correct licence issues
    - opened and closed !137: d/copyright, qcom-soc: Exclude undistributable QDU100 firmware
    - opened and merged !138: Update to 20260110
    - opened and merged !139: Update to 20260221
  - Uploads:
    - uploaded version 20251111-1~bpo13+1 to trixie-backports
    - uploaded version 20251125-1 to unstable
    - uploaded version 20260110-1 to unstable
- hexagon-dsp-binaries:
  - Bugs:
    - opened #1129001: Missing binaries - should this package use XS-Autobuild?
- initramfs-tools:
  - Bugs:
    - closed #1126611: mkinitramfs: failed to determine device for /
  - Merge requests:
    - merged !191: tests fail on arm64 because they call qemu-system-arm64
- iptables:
  - Bugs:
    - replied to #1128561: iptables: virsh net-start no longer works: Failed to run firewall command iptables -w –table filter –list-rules
- ktls-utils:
  - Merge requests:
    - merged !3: d/t/test-common: Move inclusion of extensions when signing the certificate
- libvirt:
  - Bugs:
    - replied to #1124549: libvirt passes invalid flags for network interface deletion
- linux:
  - Bugs:
  - Merge requests:
    - reviewed !1682: Unsplit configs for some kernel architectures
    - reviewed !1821: riscv64 config update for linux 6.19
    - reviewed and merged !1824: db-mok: Remove unused function
    - opened !1831: CI: Update build job to work after another common pipeline change
  - Uploads:
    - (LTS) uploaded version 5.10.249-1 to bullseye-security
    - uploaded version 6.12.63-1~bpo12+1 to bookworm-backports
    - uploaded version 6.12.69-1~bpo12+1 to bookworm-backports
    - uploaded version 6.12.73-1~bpo12+1 to bookworm-backports
    - uploaded version 6.18.12-1~bpo13+1 to trixie-backports
    - uploaded version 6.18.5-1~bpo13+1 to trixie-backports
    - uploaded version 6.18.9-1~bpo13+1 to trixie-backports
  - (LTS) updated the bullseye-security branch to 5.10.251, but did not upload it
- (LTS) linux-6.1:
  - Uploads:
    - uploaded version 6.1.162-1~deb11u1 to bullseye-security
- linux-base:
  - Bugs:
    - closed #1128355: linux-base: indirectly missing perl dependency?
- nfs-utils:
  - Merge requests:
    - reviewed and merged !36: Drop installation of blkmapd and nfs-blkmap.service systemd service
- wireless-regdb:
  - Bugs:
    - replied to and closed #1104022: wireless-regdb: Consider importing setregdomain and udev rule from Fedora
    - closed #1122785: wireless-regdb: Please remove/replace usage of dh_movetousr
    - closed #1126431: wireless-regdb: Unnecessary Build-Depends: python3-m2crypto
  - Uploads:
    - uploaded version 2026.02.04-1 to unstable
    - uploaded version 2026.02.04-1~deb12u1 to bookworm
    - uploaded version 2026.02.04-1~deb13u1 to trixie
  - (LTS) updated the bullseye-security branch to 2026.02.04-1, but did not upload it
Debian non-package bugs:
- release.debian.org:
  - opened #1128507: trixie-pu: package wireless-regdb/2026.02.04-1~deb13u1
  - opened #1128510: bookworm-pu: package wireless-regdb/2026.02.04-1~deb12u1
Mailing lists:
- debian-kernel:
  - posted Agenda items for kernel-team meeting on 2026-02-04
  - posted Agenda items for kernel-team meeting on 2026-02-25
  - (LTS) replied to Discrepancies between Commits list in changelog of debian and upstream linux git repo.
  - (LTS) replied to [Pkg-libvirt-maintainers] Processed: retitle 1124549 to libvirt passes invalid flags for network interface deletion …, tagging 1124549
  - replied to linux 7.0
- debian-lts-announce:
  - posted [SECURITY] [DLA 4475-1] linux security update
  - posted [SECURITY] [DLA 4476-1] linux-6.1 security update
- klibc:
  - replied to [PATCH 1/2] [klibc] explicitly close arm64 syscall stub generator output
  - replied to [PATCH] [klibc] fix arm stub alignment
  - replied to [PATCH] [klibc] remove unneeded syscalls.mk dependencies
- linux-hwmon:
  - replied to [PATCH] hwmon: (max16065) Use READ/WRITE_ONCE to avoid compiler optimization induced race
- linux-wireless:
  - posted [PATCH] wireless-regdb: Fix regulatory.bin signing with new M2Crypto
  - posted [PATCH] wireless-regdb: Replace M2Crypto with cryptography package
- platform-driver-x86:
  - replied to [PATCH] platform/x86: hp-bioscfg: Support allocations of larger data
- stable:
  - (LTS) replied to Please apply commit 9990ddf47d41 (“net: tunnel: make skb_vlan_inet_prepare() return drop reasons”) down to 6.1.y at least
  - (LTS) reviewed and replied to various patches for 5.10 … … …
  - (LTS) posted [PATCH 5.10,5.15] ip6_tunnel: Fix usage of skb_vlan_inet_prepare()
  - replied to [PATCH 6.12 519/567] gpiolib: acpi: Move quirks to a separate file

Norbert Preining: TeX Live 2026 released

Norbert Preining — 2026-03-01T23:02:47+00:00

Get the Champagne ready, we have released the final images of TeX Live 2026.

Nothing spectacularly new in this version, but improvements across that bank, and a new player: `xdvipsk`, an extended dvips with support for more image formats and (with LuaTeX) OpenType and TrueType fonts. Things I was very directly involved in are the PNG inclusion infos via env vars, the nlink changes, and tlmgr updates.

Thanks goes to all the developers, builders, the great CTAN team, and everyone who has contributed to this release! Many thanks in particular to Siep Kroonenberg for her work on TeX Live, especially Windows support, for many years. She has retired and is moving on to other projects. Thanks again Siep, and best wishes!

Finally, here are the changes as listed in the master TeX Live documentation:

Cross-engine changes (except in original TeX and Aleph):

When the “Infinite glue shrinkage” error is ignored (see the 2025 release notes), the word “error” is no longer included in the output, and the message is written only to the log ﬁle. This was a source of minor confusion and false positives.

HiTeX:

Now exclusively uses the UTF-8 input encoding.
OpenType and TrueType fonts are now supported minimally (no ligatures, no math); this will improve in time.
\Uchar and \Ucharcat primitives added.
The LaTeX kernel needs updates for this version, so hilatex is not available for the time being.
Major changes throughout the code base, including the HINT viewers, to implement the above. Use with care!
Cross-engine updates noted above.

LuaTeX:

New luaffi.
Lua bindings for the HarfBuzz subset API.
read_img now looks in a given –output-directory.
Saves and restores pdf->objcompresslevel along with pdf->compress_level.
texlua errors print tracebacks.
set_macro check for removing trailing space improved.
Wrong spacing around display with \matheqdirmode=1 partially ﬁxed.
Restored \mathflattenmode.
Fixes for legacy handling of TrueType fonts.
Experimental extension to ToUnicode for Type 1 fonts.
Maximum size of the destination names table for PDF output raised to 1048576.
Additional value ﬁeld for write nodes (getfield) for unexpanded token tables.
Some unused modes made obsolete.
Cross-engine updates noted above.

MetaPost:

mp_number_to_scaled returns a 64-bit signed integer instead of the system-dependent int. Internally, start on replacing int with int64_t in general.
mp_hard_times ﬁxed.
Fixes for weave.
Help message reorganized and updated for consistency.

pdfTeX:

Don’t complain about PDF minor version ≤2 unless major version = 1.
Don’t erroneously shift fraction denominators or other text if \pdfpageheight is used.
Fix overlapping text in ptmr8r and other fonts.
If the environment variable TEXMF_DEBUG_PNG_COPY is set to 1, report attributes of each PNG image and whether it was copied.
Cross-engine updates noted above.

epTeX, eupTeX:

Cross-engine updates noted above.

XeTeX:

Cross-engine updates noted above.

Dvipdfmx:

Option -o – to send output to stdout reenabled, after being unintentionally disabled for several years.

CWEB:

All CWEB programs work –verbosely by default again.
All CWEB programs no longer fail in case of warning messages.
ctangle produces far less whitespace in preprocessor macros.
ctwill-proofsort supports multiple deﬁnitions for the same identiﬁer.

Upmendex:

Experimental support for Brahmic scripts (Bengali, Gurmukhi, Gujarati, Kannada, Lao, Malayalam, Oriya, Sinhala, Tamil, Telugu).

Kpathsea:

New conﬁguration value texmf_nlink_for_leaf to specify whether the st_nlink=2 check is made to decide whether we’re in a leaf directory; in the default texmf.cnf, the check is now disabled.
The conﬁguration value openin_any no longer has any eﬀect; the interface functions are still compiled into the library, but now consider any ﬁlename to be ok for reading. To the best of anyone’s knowledge, no value but ‘a’ was ever useful (or used).

tlmgr:

Check for backup container creation failure.
In –usermode, do not warn about the texlive-scripts package being missing.

Other programs:

fmtutil, updmap: make self-locating as with tlmgr.
New program xdvipsk, an extended dvips with support for more image formats and (with LuaTeX) OpenType and TrueType fonts. See the article by Sigitas Tolusis in TUGboat, https://tug.org/TUGboat/tb38-2/tb119tolusis.pdf.
Many man pages substantially updated.

Platforms:

See MacTeX note just below.
The i386-linux, aarch64-linux, and armhf-linux binaries are now built on Debian bullseye (initially released 2021).

MacTeX: MacTeX-2026 now supports Big Sur (2020, macOS 11) and higher, on both Intel and Arm. Support for Mojave (2018) and Catalina (2019, macOS 10) has been dropped. It installs:

TeX Live 2026;
Ghostscript-10.06.0;
TeXShop, including a special version supporting Liquid Glass;
LaTeXiT, BibDesk, HintView.

The companion small BasicTeX distribution for Macs (download size about 120MB, https://tug.org/mactex/morepackages.html) now includes all core packages for tagging support, the LaTeX -dev engines for testing, and tex4ht. Those who would like to install this on other platforms can use scheme-small. BasicTeX supports all three main typesetting engines: pdfLaTeX, XeLaTeX, and LuaLaTeX.

That’s all, let the fun begin! And again, thanks to all the developers, builders, the great CTAN team, and everyone who has contributed to this release!

Benjamin Mako Hill: Pronunciation

Benjamin Mako Hill — 2026-03-01T18:51:22+00:00

Had a discussion about how to pronounce the name of Google’s chatbot. Turns out, we were all wrong.

Junichi Uekawa: The next Debconf happens in Japan.

Junichi Uekawa — 2026-03-01T04:16:01+00:00

The next Debconf happens in Japan. Great news. Feels like we came a long way, but I didn't personally do much, I just made the first moves.

Mike Gabriel: Debian Lomiri Tablets 2025-2027 - Project Report (Q3/2025)

sunweaver — 2026-02-28T18:36:37+00:00

Debian Lomiri for Debian 13 (previous project)

In our previous project around Debian and Lomiri (lasting until July 2025), we achieved to get Lomiri 0.5.0 (and with it another 130 packages) into Debian (with two minor exceptions [1]) just in time for the Debian 13 release in August 2025.

Debian Lomiri for Debian 14

At DebConf in Brest, a follow-up project has been designed between the project sponsor and Fre(i)e Software GmbH [2]. The new project (on paper) started on 1st August 2025 and project duration was agreed on to be 2 years, allowing our company to work with an equivalent of ~5 FTE on Lomiri targetting the Debian 14 release some time in the second half of 2027 (an assumed date, let's see what happens).

Ongoing work would be covered from day one of the new project and once all contract details had been properly put on paper end of September, Fre(i)e Software GmbH started hiring a new team of software developers and (future) Debian maintainers. (More of that new team in our next Q4/2025 report).

The ongoing work of Q3/2025 was basically Guido Berhörster and myself working on Morph Browser Qt6 (mostly Guido together with Bhushan from MiraLab [3]) and package maintenance in Debian (mostly me).

Morph Browser Qt6

The first milestone we could reach with the Qt6 porting of Morph Browser [4] and related components (LUITK aka lomiri-ui-toolkit (big chunk! [5]), lomiri-content-hub, lomiri-download-manager and a few other components) was reached on 21st Sep 2025 with an upload of Morph Browser 1.2.0~git20250813.1ca2aa7+dfsg-1~exp1 to Debian experimental and the Lomiri PPA [6]).

Preparation of Debian 13 Updates (still pending)

In background, various Lomiri updates for Debian 13 have been prepared during Q3/2025 (with a huge patchset), but publishing those to Debian 13 are still pending as tests are still not satisfying.

[1] lomiri-push-service and nuntium
[2] https://freiesoftware.gmbh
[3] https://miralab.one/
[4] https://gitlab.com/ubports/development/core/morph-browser/-/merge_reques... et al.
[5] https://gitlab.com/ubports/development/core/lomiri-ui-toolkit/-/merge_re... et al.
[6] https://launchpad.net/~lomiri

Dirk Eddelbuettel: x13binary 1.1.61.2 on CRAN: Micro Maintenance

Dirk Eddelbuettel — 2026-02-27T12:34:00+00:00

The x13binary team is happy to share the availability of Release 1.1.61.2 of the x13binary package providing the X-13ARIMA-SEATS program by the US Census Bureau which arrived on CRAN earlier today, and has already been built for r2u.

This release responds to a CRAN request to display the compiler version when building. x13binary, just like three other packages there, creates and ships a local binary it interfaces with. So our build was a little outside of R CMD INSTALL ... but now signals build versions like R does. We also modernized and simplified our continuous intgegration script based on r-ci.

Courtesy of my CRANberries, there is also a diffstat report for this release showing changes to the previous release.

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.

Joachim Breitner: Vibe-coding a debugger for a DSL

Joachim Breitner — 2026-02-25T10:53:30+00:00

Earlier this week a colleague of mine, Emilio Jesús Gallego Arias, shared a demo of something he built as an experiment, and I felt the desire to share this and add a bit of reflection. (Not keen on watching a 5 min video? Read on below.)

What was that?

So what did you just see (or skipped watching)? You could see Emilio’s screen, running VSCode and editing a Lean file. He designed a small programming language that he embedded into Lean, including an evaluator. So far, so standard, but a few things stick out already:

Using Lean’s very extensible syntax this embedding is rather elegant and pretty.
Furthermore, he can run this DSL code right there, in the source code, using commands like #eval. This is a bit like the interpreter found in Haskell or Python, but without needing a separate process, or like using a Jupyter notebook, but without the stateful cell management.

This is already a nice demonstration of Lean’s abilities and strength, as we know them. But what blew my mind the first time was what happened next: He had a visual debugger that allowed him to debug his DSL program. It appeared on the right, in Lean’s “Info View”, where various Lean tools can hook into, show information and allow the user to interact.

But it did not stop there, and my mind was blown a second time: Emilio opened VSCode’s „Debugger“ pane on the left, and was able to properly use VSCode’s full-fledged debugger frontend for his own little embedded programming language! Complete with highlighting the executed line, with the ability to set breakpoints there, and showing the state of local variables in the debugger.

Having a good debugger is not to be taken for granted even for serious, practical programming languages. Having it for a small embedded language that you just built yourself? I wouldn’t have even considered that.

Did it take long?

If I were Emilio’s manager I would applaud the demo and then would have to ask how many weeks he spent on that. Coming up with the language, getting the syntax extension right, writing the evaluator and especially learning how the debugger integration into VSCode (using the DAP protocol) works, and then instrumenting his evaluator to speak that protocol – that is a sizeable project!

It turns out the answer isn’t measured in weeks: it took just one day of coding together with GPT-Codex 5.3. My mind was blown a third time.

Why does Lean make a difference?

I am sure this post is just one of many stories you have read in recent weeks about how new models like Claude Opus 4.6 and GPT-Codex 5.3 built impressive things in hours that would have taken days or more before. But have you seen something like this? Agentic coding is powerful, but limited by what the underlying platform exposes. I claim that Lean is a particularly well-suited platform to unleash the agents’ versatility.

Here we are using Lean as a programming language, not as a theorem prover (which brings other immediate benefits when using agents, e.g. the produced code can be verified rather than merely plausible, but that’s a story to be told elsewhere.)

But arguably because Lean is also a theorem prover, and because of the requirements that stem from that, its architecture is different from that of a conventional programming language implementation:

As a theorem prover, it needs extensible syntax to allow formalizing mathematics in an ergonomic way, but it can also be used for embedding syntax.
As a theorem prover, it needs the ability to run “tactics” written by the user, hence the ability to evaluate the code right there in the editor.
As a theorem prover, it needs to give access to information such as tactic state, and such introspection abilities unlock many other features – such as a debugger for an embedded language.
As a theorem prover, it has to allow tools to present information like the tactic state, so it has the concept of interactive “Widgets”.

So Lean’s design has always made such a feat possible. But it was no easy feat. The Lean API is large, and documentation never ceases to be improvable. In the past, it would take an expert (or someone willing to become one) to pull off that stunt. These days, coding assistants have no issue digesting, understanding and using the API, as Emilio’s demo shows.

The combination of Lean’s extensibility and the ability of coding agents to make use of that is a game changer to how we can develop software, with rich, deep, flexible and bespoke ways to interact with our code, created on demand.

Where does that lead us?

Emilio actually shared more such demos (Github repository). A visual explorer for the compiler output (have a look at the screenshot. A browser-devtool-like inspection tool for Lean’s “InfoTree”. Any of these provide a significant productivity boost. Any of these would have been a sizeable project half a year ago. Now it’s just a few hours of chatting with the agent.

So allow me to try and extrapolate into a future where coding agents have continued to advance at the current pace, and are used ubiquitously. Is there then even a point in polishing these tools, shipping them to our users, documenting them? Why build a compiler explorer for our users, if our users can just ask their agent to build one for them, right then when they need it, tailored to precisely the use case they have, with no unnecessary or confusing feature. The code would be single use, as the next time the user needs something like that the agent can just re-create it, maybe slightly different because every use case is different.

If that comes to pass then Lean may no longer get praise for its nice out-of-the-box user experience, but instead because it is such a powerful framework for ad-hoc UX improvements.

And Emilio wouldn’t post demos about his debugger. He’d just use it.

Louis-Philippe Véronneau: Montreal's Debian & Stuff - February 2026

Louis-Philippe Véronneau — 2026-02-24T22:07:07+00:00

Our Debian User Group met on February 22^nd for our first meeting of the year!

Here's what we did:

pollo:

reviewed and merged Lintian contributions:
released lintian version 2.130.0
upstreamed a patch for python-wilderness, fixed a few things and released version 0.1.10-3
updated python-clevercsv to version 0.8.4
updated python-mediafile to version 0.14.0

lelutin:

opened up a RFH for co-maintenance for smokeping and added Marc Haber who responded really quickly to the call
with mjeanson's help: prepped and uploaded a new smokeping version to release pending work
opened a NM request to become DM

viashimo:

fixed freshrss timer
updated freshrss
installed new navidrome container
configured backups for new host (beelink mini s12)

tvaz:

did NM work
learned more about debusine and tested it
uploaded antimony to debusine
(co-)convinced lelutin to apply for DM (yay!)

lavamind:

worked on autopkgtests for a new version of jruby

Pictures

This time around, we held our meeting at cégep du Vieux Montréal, the college where I currently work. Here is the view we had:

We also ordered some delicious pizzas from Pizzeria dei Compari, a nice pizzeria on Saint-Denis street that's been there forever.

Some of us ended up grabbing a drink after the event at l'Amère à boire, a pub right next to the venue, but I didn't take any pictures.

John Goerzen: Screen Power Saving in the Linux Console

John Goerzen — 2026-02-24T14:22:10+00:00

I just made up a Debian trixie setup that has no need for a GUI. In fact, I rarely use the text console either. However, because the machine is dual boot and also serves another purpose, it’s connected to my main monitor and KVM switch.

The monitor has three inputs, and when whatever display it’s set to goes into powersave mode, it will seek out another one that’s active and automatically switch to it.

You can probably see where this is heading: it’s really inconvenient if one of the inputs never goes into powersave mode. And, of course, it wastes energy.

I have concluded that the Linux text console has lost the ability to enter powersave mode after an inactivity timeout. It can still do screen blanking — setting every pixel to black — but that is a distinct and much less useful thing.

You can do a lot of searching online that will tell you what to do. Almost all of it is wrong these days. For instance, none of these work:

Anything involving vbetool. This is really, really old advice.
Anything involving xset, unless you’re actually running a GUI, which is not the point of this post.
Anything involving setterm or the kernel parameters video=DPMS or consoleblank.
Anything involving writing to paths under /sys, such as ones ending in dpms.

Why is this?

Well, we are on at least the third generation of Linux text console display subsystems. (Maybe more than 3, depending on how you count.) The three major ones were:

The VGA text console
fbdev
DRI/KMS

As I mentioned recently in my post about running an accurate 80×25 DOS-style console on modern Linux, the VGA text console mode is pretty much gone these days. It relied on hardware rendering of the text fonts, and that capability simply isn’t present on systems that aren’t PCs — or even on PCs that are UEFI, which is most of them now.

fbdev, or a framebuffer console under earlier names, has been in Linux since the late 1990s. It was the default for most distros until more recently. It supported DPMS powersave modes, and most of the instructions you will find online reference it.

Nowadays, the DRI/KMS system is used for graphics. Unfortunately, it is targeted mainly at X11 and Wayland. It is also used for the text console, but things like DPMS-enabled timeouts were never implemented there.

You can find some manual workarounds — for instance, using ddcutil or similar for an external monitor, or adjusting the backlight files under /sys on a laptop. But these have a number of flaws — making unwanted brightness adjustments, and not automatically waking up on keypress among them.

My workaround

I finally gave up and ran apt-get install xdm. Then in /etc/X11/xdm/Xsetup, I added one line:

xset dpms 0 0 120

Now the system boots into an xdm login screen, and shuts down the screen after 2 minutes of inactivity. On the rare occasion where I want a text console from it, I can switch to it and it won’t have a timeout, but I can live with that.

Thus, quite hopefully, concludes my series of way too much information about the Linux text console!

Antoine Beaupré: net-tools to iproute cheat sheet

Antoine Beaupré — 2026-02-23T22:30:13+00:00

This is also known as: "ifconfig is not installed by default anymore, how do I do this only with the ip command?"

I have been slowly training my brain to use the new commands but I sometimes forget some. So, here's a couple of equivalence from the old package to net-tools the new iproute2, about 10 years late:

`net-tools`	`iproute2`	shorter form	what it does
`arp -an`	`ip neighbor`	`ip n`
`ifconfig`	`ip address`	`ip a`	show current IP address
`ifconfig`	`ip link`	`ip l`	show link stats (up/down/packet counts)
`route`	`ip route`	`ip r`	show or modify the routing table
`route add default GATEWAY`	`ip route add default via GATEWAY`	`ip r a default via GATEWAY`	add default route to `GATEWAY`
`route del ROUTE`	`ip route del ROUTE`	`ip r d ROUTE`	remove `ROUTE` (e.g. `default`)
`netstat -anpe`	`ss --all --numeric --processes --extended`	`ss -anpe`	list listening processes, less pretty

Note that I wrote a whole article about the latter.

Another trick

Also note that I often alias ip to ip -br -c as it provides a much prettier output.

Compare, before:

anarcat@angela:~> ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff permaddr xx:xx:xx:xx:xx:xx
    altname wlp166s0
    altname wlx8cf8c57333c7
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
20: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.108/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
       valid_lft 40699sec preferred_lft 40699sec

After:

anarcat@angela:~> ip -br -c a
lo               UNKNOWN        127.0.0.1/8 ::1/128 
wlan0            DOWN           
virbr0           DOWN           192.168.122.1/24 
eth0             UP             192.168.0.108/24

I don't even need to redact MAC addresses! It also affects the display of the other commands, which look similarly neat.

Also imagine pretty colors above.

Finally, I don't have a cheat sheet for iw vs iwconfig (from wireless-tools) yet. I just use NetworkManager now and rarely have to mess with wireless interfaces directly.

Background and history

For context, there are traditionally two ways of configuring the network in Linux:

the old way, with commands like ifconfig, arp, route and netstat, those are part of the net-tools package
the new way, mostly (but not entirely!) wrapped in a single ip command, that is the iproute2 package

It seems like the latter was made "important" in Debian in 2008, which means every release since Debian 5 "lenny" has featured the ip command.

The former net-tools package was demoted in December 2016 which means every release since Debian 9 "stretch" ships without an ifconfig command unless explicitly requested. Note that this was mentioned in the release notes in a similar (but, IMHO, less useful) table.

(Technically, the net-tools Debian package source still indicates it is Priority: important but that's a bug I have just filed.)

Finally, and perhaps more importantly, the name iproute is hilarious if you are a bilingual french speaker: it can be read as "I proute" which can be interpreted as "I fart" as "prout!" is the sound a fart makes. The fact that it's called iproute2 makes it only more hilarious.

Antoine Beaupré: PSA: North america changes time forward soon, Europe next

Antoine Beaupré — 2026-02-23T19:32:07+00:00

This is a copy of an email I used to send internally at work and now made public. I'm not sure I'll make a habit of posting it here, especially not twice a year, unless people really like it. Right now, it's mostly here to keep with my current writing spree going.

This is your bi-yearly reminder that time is changing soon!

What's happening?

For people not on tor-internal, you should know that I've been sending semi-regular announcements when daylight saving changes occur. Starting now, I'm making those announcements public so they can be shared with the wider community because, after all, this affects everyone (kind of).

For those of you lucky enough to have no idea what I'm talking about, you should know that some places in the world implement what is called Daylight saving time or DST.

Normally, you shouldn't have to do anything: computers automatically change time following local rules, assuming they are correctly configured, provided recent updates have been applied in the case of a recent change in said rules (because yes, this happens).

Appliances, of course, will likely not change time and will need to adjusted unless they are so-called "smart" (also known as "part of a bot net").

If your clock is flashing "0:00" or "12:00", you have no action to take, congratulations on having the right time once or twice a day.

If you haven't changed those clocks in six months, congratulations, they will be accurate again!

In any case, you should still consider DST because it might affect some of your meeting schedules, particularly if you set up a new meeting schedule in the last 6 months and forgot to consider this change.

If your location does not have DST

Properly scheduled meetings affecting multiple time zones are set in UTC time, which does not change. So if your location does not observer time changes, your (local!) meeting time will not change.

But be aware that some other folks attending your meeting might have the DST bug and their meeting times will change. They might miss entire meetings or arrive late as you frantically ping them over IRC, Matrix, Signal, SMS, Ricochet, Mattermost, SimpleX, Whatsapp, Discord, Slack, Wechat, Snapchat, Telegram, XMPP, Briar, Zulip, RocketChat, DeltaChat, talk(1), write(1), actual telegrams, Meshtastic, Meshcore, Reticulum, APRS, snail mail, and, finally, flying a remote presence drone to their house, asking what's going on.

(Sorry if I forgot your preferred messaging client here, I tried my best.)

Be kind; those poor folks might be more sleep deprived as DST steals one hour of sleep from them on the night that implements the change.

If you do observe DST

If you are affected by the DST bug, your local meeting times will change access the board. Normally, you can trust that your meetings are scheduled to take this change into account and the new time should still be reasonable.

Trust, but verify; make sure the new times are adequate and there are no scheduling conflicts.

Do this now: take a look at your calendar in two week and in April. See if any meeting need to be rescheduled because of an impossible or conflicting time.

When does time change, how and where?

Notice how I mentioned "North America" in the subject? That's a lie. ("The doctor lies", as they say on the BBC.) Other places, including Europe, also changes times, just not all at once (and not all North America).

We'll get into "where" soon, but first let's look at the "how". As you might already know, the trick is:

Spring forward, fall backwards.

This northern-centric (sorry!) proverb says that clocks will move forward by an hour this "spring", after moving backwards last "fall". This is why we lose an hour of work, sorry, sleep. It sucks, to put it bluntly. I want it to stop and will keep writing those advisories until it does.

To see where and when, we, unfortunately, still need to go into politics.

USA and Canada

First, we start with "North America" which, really, is just some parts of USA[1] and Canada[2]. As usual, on the Second Sunday in March (the 8th) at 02:00 local (not UTC!), the clocks will move forward.

This means that properly set clocks will flip from 1:59 to 3:00, coldly depriving us from an hour of sleep that was perniciously granted 6 months ago and making calendar software stupidly hard to write.

Practically, set your wrist watch and alarm clocks[3] back one hour before going to bed and go to bed early.

[1] except Arizona (except the Navajo nation), US territories, and Hawaii

[2] except Yukon, most of Saskatchewan, and parts of British Columbia (northeast), one island in Nunavut (Southampton Island), one town in Ontario (Atikokan) and small parts of Quebec (Le Golfe-du-Saint-Laurent), a list which I keep recopying because I find it just so amazing how chaotic it is. When your clock has its own Wikipedia page, you know something is wrong.

[3] hopefully not managed by a botnet, otherwise kindly ask your bot net operator to apply proper software upgrades in a timely manner

Europe

Next we look at our dear Europe, which will change time on the last Sunday in March (the 29th) at 01:00 UTC (not local!). I think it means that, Amsterdam-time, the clocks will flip from 1:59 to 3:00 AM local on that night.

(Every time I write this, I have doubts. I would welcome independent confirmation from night owls that observe that funky behavior experimentally.)

Just like your poor fellows out west, just fix your old-school clocks before going to bed, and go to sleep early, it's good for you.

Rest of the world with DST

Renewed and recurring apologies again to the people of Cuba, Mexico, Moldova, Israel, Lebanon, Palestine, Egypt, Chile (except Magallanes Region), parts of Australia, and New Zealand which all have their own individual DST rules, omitted here for brevity.

In general, changes also happen in March, but either on different times or different days, except in the south hemisphere, where they happen in April.

Rest of the world without DST

All of you other folks without DST, rejoice! Thank you for reminding us how manage calendars and clocks normally. Sometimes, doing nothing is precisely the right thing to do. You're an inspiration for us all.

Changes since last time

There were, again, no changes since last year on daylight savings that I'm aware of. It seems the US congress debating switching to a "half-daylight" time zone which is an half-baked idea that I should have expected from the current USA politics.

The plan is to, say, switch from "Eastern is UTC-4 in the summer" to "Eastern is UTC-4.5". The bill also proposes to do this 90 days after enactment, which is dangerously optimistic about our capacity at deploying any significant change in human society.

In general, I rely on the Wikipedia time nerds for this and Paul Eggert which seems to singlehandledly be keeping everything in order for all of us, on the tz-announce mailing list.

This time, I've also looked at the tz mailing list which is where I learned about the congress bill.

If your country has changed time and no one above noticed, now would be an extremely late time to do something about this, typically writing to the above list. (Incredibly, I need to write to the list because of this post.)

One thing that did change since last year is that I've implemented what I hope to be a robust calendar for this, which was surprisingly tricky.

If you have access to our Nextcloud, it should be visible under the heading "Daylight saving times". If you don't, you can access it using this direct link.

The procedures around how this calendar was created, how this email was written, and curses found along the way, are also documented in this wiki page, if someone ever needs to pick up the Time Lord duty.

Wouter Verhelst: On Free Software, Free Hardware, and the firmware in between

Wouter Verhelst — 2026-02-23T16:51:00+00:00

When the Free Software movement started in the 1980s, most of the world had just made a transition from free university-written software to non-free, proprietary, company-written software. Because of that, the initial ethical standpoint of the Free Software foundation was that it's fine to run a non-free operating system, as long as all the software you run on that operating system is free.

Initially this was just the editor.

But as time went on, and the FSF managed to write more and more parts of the software stack, their ethical stance moved with the times. This was a, very reasonable, pragmatic stance: if you don't accept using a non-free operating system and there isn't a free operating system yet, then obviously you can't write that free operating system, and the world won't move towards a point where free operating systems exist.

In the early 1990s, when Linus initiated the Linux kernel, the situation reached the point where the original dream of a fully free software stack was complete.

Or so it would appear.

Because, in fact, this was not the case. Computers are physical objects, composed of bits of technology that we refer to as "hardware", but in order for these bits of technology to communicate with other bits of technology in the same computer system, they need to interface with each other, usually using some form of bus protocol. These bus protocols can get very complicated, which means that a bit of software is required in order to make all the bits communicate with each other properly. Generally, this software is referred to as "firmware", but don't let that name deceive you; it's really just a bit of low-level software that is very specific to one piece of hardware. Sometimes it's written in an imperative high-level language; sometimes it's just a set of very simple initialization vectors. But whatever the case might be, it's always a bit of software.

And although we largely had a free system, this bit of low-level software was not yet free.

Initially, storage was expensive, so computers couldn't store as much data as today, and so most of this software was stored in ROM chips on the exact bits of hardware they were meant for. Due to this fact, it was easy to deceive yourself that the firmware wasn't there, because you never directly interacted with it. We knew it was there; in fact, for some larger pieces of this type of software it was possible, even in those days, to install updates. But that was rarely if ever done at the time, and it was easily forgotten.

And so, when the free software movement slapped itself on the back and declared victory when a fully free operating system was available, and decided that the work of creating a free software environment was finished, that only keeping it recent was further required, and that we must reject any further non-free encroachments on our fully free software stack, the free software movement was deceiving itself.

Because a computing environment can never be fully free if the low-level pieces of software that form the foundations of that computing environment are not free. It would have been one thing if the Free Software Foundation declared it ethical to use non-free low-level software on a computing environment if free alternatives were not available. But unfortunately, they did not.

In fact, something very strange happened.

In order for some free software hacker to be able to write a free replacement for some piece of non-free software, they obviously need to be able to actually install that theoretical free replacement. This isn't just a random thought; in fact it has happened.

Now, it's possible to install software on a piece of rewritable storage such as flash memory inside the hardware and boot the hardware from that, but if there is a bug in your software -- not at all unlikely if you're trying to write software for a piece of hardware that you don't have documentation for -- then it's not unfathomable that the replacement piece of software will not work, thereby reducing your expensive piece of technology to something about as useful as a paperweight.

Here's the good part.

In the late 1990s and early 2000s, the bits of technology that made up computers became so complicated, and the storage and memory available to computers so much larger and cheaper, that it became economically more feasible to create a small, tiny, piece of software stored in a ROM chip on the hardware, with just enough knowledge of the bus protocol to download the rest from the main computer.

This is awesome for free software. If you now write a replacement for the non-free software that comes with the hardware, and you make a mistake, no wobbles! You just remove power from the system, let the DRAM chips on the hardware component fully drain, return power, and try again. You might still end up with a brick of useless silicon if some of the things you sent to your technology make it do things that it was not designed to do and therefore you burn through some critical bits of metal or plastic, but the chance of this happening is significantly lower than the chance of you writing something that impedes the boot process of the piece of hardware and you are unable to fix it because the flash is overwritten. There is anecdotal evidence that there are free software hackers out there who do so. So, yay, right? You'd think the Free Software foundation would jump at the possibility to get more free software? After all, a large part of why we even have a Free Software Foundation in the first place, was because of some piece of hardware that was misbehaving, so you would think that the foundation's founders would understand the need for hardware to be controlled by software that is free.

The strange thing, what has always been strange to me, is that this is not what happened.

The Free Software Foundation instead decided that non-free software on ROM or flash chips is fine, but non-free software -- the very same non-free software, mind -- that touches the general storage device that you as a user use, is not. Never mind the fact that the non-free software is always there, whether it sits on your storage device or not.

Misguidedness aside, if some people decide they would rather not update the non-free software in their hardware and use the hardware with the old and potentially buggy version of the non-free software that it came with, then of course that's their business.

Unfortunately, it didn't quite stop there. If it had, I wouldn't have written this blog post.

You see, even though the Free Software Foundation was about Software, they decided that they needed to create a hardware certification program. And this hardware certification program ended up embedding the strange concept that if something is stored in ROM it's fine, but if something is stored on a hard drive it's not. Same hardware, same software, but different storage. By that logic, Windows respects your freedom as long as the software is written to ROM. Because this way, the Free Software Foundation could come to a standstill and pretend they were still living in the 90s.

An unfortunate result of the "RYF" program is that it means that companies who otherwise would have been inclined to create hardware that was truly free, top to bottom, are now more incentivised by the RYF program to create hardware in which the non-free low-level software can't be replaced.

Meanwhile, the rest of the world did not pretend to still be living in the nineties, and free hardware communities now exist. Because of how the FSF has marketed themselves out of the world, these communities call themselves "Open Hardware" communities, rather than "Free Hardware" ones, but the principle is the same: the designs are there, if you have the skill you can modify it, but you don't have to.

In the mean time, the open hardware community has evolved to a point where even CPUs are designed in the open, which you can design your own version of.

But not all hardware can be implemented as RISC-V, and so if you want a full system that builds RISC-V you may still need components of the system that were originally built for other architectures but that would work with RISC-V, such as a network card or a GPU. And because the FSF has done everything in their power to disincentivise people who would otherwise be well situated to build free versions of the low-level software required to support your hardware, you may now be in the weird position where we seem to have somehow skipped a step.

My own suspicion is that the universe is not only queerer than we suppose, but queerer than we can suppose.

-- J.B.S. Haldane

(comments for this post will not pass moderation. Use your own blog!)

Benjamin Mako Hill: What makes online groups vulnerable to governance capture?

Benjamin Mako Hill — 2026-02-22T21:12:41+00:00

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

For nearly a decade, the Croatian language version of Wikipedia was run by a cabal of far-right nationalists who edited articles in ways that promoted fringe political ideas and involved cases of historical revisionism related to the Ustaše regime, a fascist movement that ruled the Nazi puppet state called the Independent State of Croatia during World War II. This cabal seized complete control of the encyclopedia’s governance, banned and blocked those who disagreed with them, and operated a network of fake accounts to create the appearance of grassroots support for their policies.

Thankfully, Croatian Wikipedia appears to be an outlier. Though both the Croatian and Serbian language editions have been documented to contain nationalist bias and historical revisionism, Croatian Wikipedia seems unique among Wikipedia editions in the extent to which its governance institutions were captured by a small group of users.

The situation in Croatian Wikipedia was well documented and is now largely fixed, but we still know very little about why it was taken over, while other language editions seem to have rebuffed similar capture attempts. In a paper published in the Proceedings of the ACM: Human-Computer Interaction (CSCW), Zarine Kharazian, Kate Starbird, and I present an interview-based study that provides an explanation for why Croatian was captured while several other editions facing similar contexts and threats fared better.

Short video presentation of the work given at Wikimania in August 2023.

Based on insights from interviews with 15 participants from both the Croatian and Serbian Wikipedia projects and from the broader Wikimedia movement, we arrived at three propositions that, together, help explain why Croatian Wikipedia succumbed to capture while Serbian Wikipedia did not:

Perceived Value as a Target. Is the project worth expending the effort to capture?
Bureaucratic Openness. How easy is it for contributors outside the core founding team to ascend to local governance positions?
Institutional Formalization. To what degree does the project prefer personalistic, informal forms of organization over formal ones?

The conceptual model from our paper, visualizing possible institutional configurations among Wikipedia projects that affect the risk of governance capture.

We found that both Croatian and Serbian Wikipedias were attractive targets for far-right nationalist capture due to their sizable readership and resonance with national identity. However, we also found that the two projects diverged early in their trajectories in how open they remained to new contributors ascending to local governance positions and in the degree to which they privileged informal relationships over formal rules and processes as the project’s organizing principles. Ultimately, Croatian’s relative lack of bureaucratic openness and rules constraining administrator behavior created a window of opportunity for a motivated contingent of editors to seize control of the governance mechanisms of the project.

Though our empirical setting was Wikipedia, our theoretical model may offer insight into the challenges faced by self-governed online communities more broadly. As interest in decentralized alternatives to Facebook and X (formerly Twitter) grows, communities on these sites will likely face similar threats from motivated actors. Understanding the vulnerabilities inherent in these self-governing systems is crucial to building resilient defenses against threats like disinformation.

For more details on our findings, take a look at the published version of our paper.

Citation for the full paper: Kharazian, Zarine, Kate Starbird, and Benjamin Mako Hill. 2024. “Governance Capture in a Self-Governing Community: A Qualitative Comparison of the Croatian, Serbian, Bosnian, and Serbo-Croatian Wikipedias.” Proceedings of the ACM on Human-Computer Interaction 8 (CSCW1): 61:1-61:26. https://doi.org/10.1145/3637338.

This blog post and the paper it describes are collaborative work by Zarine Kharazian, Benjamin Mako Hill, and Kate Starbird.

Nazi.Compare: First speech of Chanellor Hitler, Andreas Tille & Debian denounce Branden Robinson

Nazi.Compare — 2026-02-22T18:30:00+00:00

Hitler became Chancellor of Germany in January 1933.

On 10 February 1933, Hitler gave his first official speech as Chancellor.

He used the occasion to attack his predecessors for everything that had transpired against German interests since the end of World War One.

Many copies of the speech are available online:

Thatâ€™s what Germany looks like today! Under the rule of these parties who have ruined our Volk for fourteen years. The only question is, for how much longer?

...

And this brings us thus to our sixth item, clearly the goal of our struggle: the preservation of this Volk and this soil, the preservation of this Volk for the future, in the realization that this alone can constitute our reason for being.

The word Volk, which means People or Population, appears forty two times in the speech.

On 10 February 2026, the Debianist leader Andreas Tille reprimanded one of his predecessors G. Branden Robinson, just as Adolf Hitler had reprimanded the predecessors who ruled Germany in the fourteen years before the Nazis took power.

While Hitler claimed to represent the Volk / People, Andreas Tille claims to represent the user, whoever that is, in this spiteful reply:

... directly harms our ability to serve our users

...

the project owes first and foremost to its users.

...

Andreas Tille was, on two successive occasions, elected on Hitler's birthday. Go figure.

Jonathan Dowland: Lanzarote

jmtd — 2026-02-21T19:00:30+00:00

I want to get back into the habit of blogging, but I've struggled. I've had several ideas of topics to try and write about, but I've not managed to put aside the time to do it. I thought I'd try and bash out a one-take, stream-of-conciousness-style post now, to get back into the swing.

I'm writing from the lounge of my hotel room in Lanzarote, where my family have gone for the School break. The weather at home has been pretty awful this year, and this week is traditionally quite miserable at the best of times. It's been dry with highs of around 25â„ƒ .

It's been an unusual holiday in one respect: one of my kids is struggling with Autistic Burnout. We were really unsure whether taking her was a good idea: and certainly towards the beginning of the holiday felt we may have made a mistake. Writing now, at the end, I'm not so sure. But we're very unlikely to have anything resembling a traditional summer holiday for the foreseeable.

Managing Autistic Burnout and the UK ways the UK healthcare and education systems manage it (or fail to) has been a huge part of my recent life. Perhaps I should write more about that. This coming week the government are likely to publish plans for reforming Special Needs support in Education. Like many other parents, we wait in hope and fear to see what they plan.

In anticipation of spending a lot of time in the hotel room with my preoccupied daughter I (unusually) packed a laptop and set myself a nerd-task: writing a Pandoc parser ("reader") for the MoinMoin Wiki markup language. There's some unfinished prior art from around 2011 by Simon Michael (of hledger) to work from.

The motivation was our plan to migrate the Debian Wiki away from MoinMoin. We've since decided to approach that differently but I might finish the Reader anyway, it's been an interesting project (and a nice excuse to write Haskell) and it will be useful for others.

Unusually (for me) I've not been reading fiction on this trip: I took with me Human Compatible by Prof Stuart Russell: discussing how to solve the problem of controlling a future Artificial Intelligence. I've largely avoided the LLM hype cycle we're suffering through at the moment, and I have several big concerns about it (moral, legal, etc.), and felt it was time to try and make my concerns more well-formed and test them. This book has been a big help in doing so, although it doesn't touch on the issue of copyright, which is something I am particularly interested in at the moment.

Thomas Goirand: Seamlessly upgrading a production OpenStack cluster in 4 hours : with 2k lines shell script

Goirand Thomas — 2026-02-21T00:44:05+00:00

tl;dr:

To the question: “what does it take to upgrade OpenStack”, my personal answer is: less than 2K lines of dash script. I’ll here describe its internals, and why I believe it is the correct solution.

Why writing this blog post

During FOSSDEM 2024, I was asked “how to you handle upgrades”. I answered with a big smile and a short “with a very small shell script” as I couldn’t explain in 2 minutes how it was done. Just saying “it is great this way” doesn’t help giving readers enough hints to be trusted. Why and how did I do it the right way ? This blog post is an attempt to reply better to this question more deeply.

Upgrading OpenStack in production

I wrote this script maybe a 2 or 3 years ago. Though I’m only blogging about it today, because … I did such an upgrade in a public cloud in production last Thuesday evening (ie: the first region of the Infomaniak public cloud). I’d say the cluster is moderately large (as of today: about 8K+ VMs running, 83 compute nodes, 12 network nodes, … for a total of 10880 physical CPU cores and 125 TB of RAM if I only count the compute servers). It took “only” 4 hours to do the upgrade (though I already wore some more code to speed this up for the next time…). It went super smooth without a glitch. I mostly just sat, reading the script output… and went to bed once it finished running. The next day, all my colleagues at Infomaniak were nicely congratulating me that it went that smooth (a big thanks to all of you who did). I couldn’t dream of an upgrade that smooth! :)

Still not impressed? Boring read? Yeah… let’s dive into more technical details.

Intention behind the implementation

My script isn’t perfect. I wont ever pretend it is. But at least, it does minimize down time of every OpenStack service. It also is a “by the book” implementation of what’s written in the OpenStack doc, following every upstream advice. As a result, it is fully seamless for some OpenStack services, and as HA as OpenStack can be for others. The upgrade process is of course idempotent and can be re-run in case of failure. Here’s why.

General idea

My upgrade script does thing in a certain order, respecting what is documented about upgrades in the OpenStack documentation. It basically does:

Upgrade all dependency
Upgrade all services one by one, in all the cluster

Installing dependencies

The first thing the upgrade script does is:

disable puppet on all nodes of the cluster
switch the APT repository
apt-get update on all nodes
install library dependency on all nodes

For this last thing, a static list of all needed dependency upgrade is maintained between each release of OpenStack, and for each type of nodes. Then for all packages in this list, the script checks with dpkg-query that the package is really installed, and with apt-cache policy that it really is going to be upgraded (Maybe there’s an easier way to do this?). This way, no package is marked as manually installed by mistake during the upgrade process. This ensure that “apt-get –purge autoremove” really does what it should, and that the script is really idempotent.

The idea then, is that once all dependencies are installed, upgrading and restarting leaf packages (ie: OpenStack services like Nova, Glance, Cinder, etc.) is very fast, because the apt-get command doesn’t need to install all dependencies. So at this point, doing “apt-get install python3-cinder” for example (which will also, thanks to dependencies, upgrade cinder-api and cinder-scheduler, if it’s in a controller node) only takes a few seconds. This principle applies to all nodes (controller nodes, network nodes, compute nodes, etc.), which helps a lot speeding-up the upgrade and reduce unavailability.

hapc

At its core, the oci-cluster-upgrade-openstack-release script uses haproxy-cmd (ie: /usr/bin/hapc) to drain each API server to-be-upgraded from haproxy. Hapc is a simple Python wrapper around the haproxy admin socket: it sends command to it with an easy to understand CLI. So it is possible to reliably upgrade one API service only after it’s drained away. Draining means one just wait for the last query to finish and the client to disconnect from http before giving the backend server some more queries. If you do not know hapc / haproxy-cmd, I recommend trying it: it’s going to be hard for you to stop using it once you tested it. Its bash-completion script makes it VERY easy to use, and it is helpful in production. But not only: it is also nice to have when writing this type of upgrade script. Let’s dive into haproxy-cmd.

Example on how to use haproxy-cmd

Let me show you. First, ssh one of the 3 controller and search where the virtual IP (VIP) is located with “crm resource locate openstack-api-vip” or with a (more simple) “crm status”. Let’s ssh that server who got the VIP, and now, let’s drain it away from haproxy.

$ hapc list-backends $ hapc drain-server --backend glancebe --server cl1-controller-1.infomaniak.ch --verbose --wait --timeout 50 $ apt-get install glance-api $ hapc enable-server --backend glancebe --server cl1-controller-1.infomaniak.ch

Upgrading the control plane

My upgrade script leverages hapc just like above. For each OpenStack project, it’s done in this order on the first node holding the VIP:

“hapc drain-server” of the API, so haproxy gracefully stops querying it
stop all services on that node (including non-API services): stop, disable and mask with systemd.
upgrade that service Python code. For example: “apt-get install python3-nova”, which also will pull nova-api, nova-conductor, nova-novncprox, etc. but services wont start automatically as they’ve been stoped + disabled + masked on the previous bullet point.
perform the db_sync so that the db is up-to-date [1]
start all services (unmask, enable and start with systemd)
re-enable the API backend with “hapc enable-server”

Starting at [1], the risk is that other nodes may have a new version of the database schema, but an old version of the code that isn’t compatible with it. But it doesn’t take long, because the next step is to take care of the other (usually 2) nodes of the OpenStack control plane:

“hapc drain-server” of the API of the other 2 controllers
stop of all services on these 2 controllers [2]
upgrade of the package
start of all services

So while there’s technically zero down time, still some issues between [1] and [2] above may happen because of the new DB schema and the old code (both for API and other services) are up and running at the same time. It is however supposed to be rare cases (some OpenStack project don’t even have db change between some OpenStack releases, and it often continues to work on most queries with the upgraded db), and the cluster will be like that for a very short time, so that’s fine, and better than an full API down time.

Satellite services

Then there’s satellite services, that needs to be upgraded. Like Neutron, Nova, Cinder. Nova is the least offender as it has all the code to rewrite Json object schema on-the-fly so that it continues to work during an upgrade. Though it’s a known issue that Cinder doesn’t have the feature (last time I checked), and it’s also probably the same for Neutron (maybe recent-ish versions of OpenStack do use oslo.versionnedobjects ?). Anyways, upgrade on these nodes are done just right after the control plane for each service.

Parallelism and upgrade timings

As we’re dealing with potentially hundreds of nodes per cluster, a lot of operations are performed in parallel. I choose to simply use the & shell thingy with some “wait” shell stuff so that not too many jobs are done in parallel. For example, when disabling SSH on all nodes, this is done 24 nodes at a time. Which is fine. And the number of nodes is all depending on the type of thing that’s being done. For example, while it’s perfectly OK to disable puppet on 24 nodes at the same time, but it is not OK to do that with Neutron services. In fact, each time a Neutron agent is restarted, the script explicitly waits for 30 seconds. This conveniently avoids a hailstorm of messages in RabbitMQ, and neutron-rpc-server to become too busy. All of these waiting are necessary, and this is one of the reasons why can sometimes take that long to upgrade a (moderately big) cluster.

Not using config management tooling

Some of my colleagues would have prefer that I used something like Ansible. Whever, there’s no reason to use such tool if the idea is just to perform some shell script commands on every servers. It is a way more efficient (in terms of programming) to just use bash / dash to do the work. And if you want my point of view about Ansible: using yaml for doing such programming would be crasy. Yaml is simply not adapted for a job where if, case, and loops are needed. I am well aware that Ansible has workarounds and it could be done, but it wasn’t my choice.

Bits from Debian: Proxmox Platinum Sponsor of DebConf26

Leonardo Martínez, Santiago Ruano Rincón — 2026-02-20T17:26:00+00:00

We are pleased to announce that Proxmox has committed to sponsor DebConf26 as a Platinum Sponsor.

Proxmox develops powerful, yet easy-to-use open-source server solutions. The comprehensive open-source ecosystem is designed to manage divers IT landscapes, from single servers to large-scale distributed data centers. Our unified platform integrates server virtualization, easy backup, and rock-solid email security ensuring seamless interoperability across the entire portfolio. With the Proxmox Datacenter Manager, the ecosystem also offers a "single pane of glass" for centralized management across different locations.

Since 2005, all Proxmox solutions have been built on the rock-solid Debian platform. We are proud to return to DebConf26 as a sponsor because the Debian community provides the foundation that makes our work possible. We believe in keeping IT simple, open, and under your control.

Thank you very much, Proxmox, for your support of DebConf26!

Become a sponsor too!

DebConf26 will take place from 20th to July 25th 2026 in Santa Fe, Argentina, and will be preceded by DebCamp, from 13th to 19th July 2026.

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

Clint Adams: Holger says

2026-02-18T22:59:00+00:00

sq network keyserver search $id ; sq cert export --cert=$id > $id.asc

Posted on 2026-02-18

Tags: quanks

Thomas Lange: 42.000 FAI.me jobs created

Thomas Lange — 2026-02-18T14:55:11+00:00

The FAI.me service has reached another milestone:

The 42.000th job was submitted via the web interface since the beginning of this service in 2017.

The idea was to provide a simple web interface for end users for creating the configs for the fully automatic installation with only minimal questions and without knowing the syntax of the configuration files. Thanks a lot for using this service and for all your feedback.

The next job can be yours!

P.S.: I like to get more feedback for the FAI.me service. What do you like most? What's missing? Do you have any success story how you use the customized ISO for your deployment? Please fill out the FAI questionaire or sent feedback via email to fai.me@fai-project.org

About FAI.me

FAI.me is the service for building your own customized images via a web interface. You can create an installation or live ISO or a cloud image. For Debian, multiple release versions can be chosen, as well as installations for Ubuntu Server, Ubuntu Desktop, or Linux Mint.

Multiple options are available like selecting different desktop environments, the language and keyboard and adding a user with a password. Optional settings include adding your own package list, choosing a backports kernel, adding a postinst script and adding a ssh public key, choosing a partition layout and some more.

Dirk Eddelbuettel: qlcal 0.1.0 on CRAN: Easier Calendar Switching

Dirk Eddelbuettel — 2026-02-18T13:21:00+00:00

The eighteenth release of the qlcal package arrivied at CRAN today. There has been no calendar update in QuantLib 1.41 so it has been relatively quiet since the last release last summer but we now added a nice new feature (more below) leading to a new minor release version.

qlcal delivers the calendaring parts of QuantLib. It is provided (for the R package) as a set of included files, so the package is self-contained and does not depend on an external QuantLib library (which can be demanding to build). qlcal covers over sixty country / market calendars and can compute holiday lists, its complement (i.e. business day lists) and much more. Examples are in the README at the repository, the package page, and course at the CRAN package page.

This releases makes it (much) easier to work with multiple calendars. The previous setup remains: the package keeps one ‘global’ (and hidden) calendar object which can be set, queried, altered, etc. But now we added the ability to hold instantiated calendar objects in R. These are external pointer objects, and we can pass them to functions requiring a calendar. If no such optional argument is given, we fall back to the global default as before. Similarly for functions operating on one or more dates, we now simply default to the current date if none is given. That means we can now say

> sapply(c("UnitedStates/NYSE", "Canada/TSX", "Australia/ASX"), 
         \(x) qlcal::isBusinessDay(xp=qlcal::getCalendar(x)))
UnitedStates/NYSE        Canada/TSX     Australia/ASX 
             TRUE              TRUE              TRUE 
>

to query today (February 18) in several markets, or compare to two days ago when Canada and the US both observed a holiday

> sapply(c("UnitedStates/NYSE", "Canada/TSX", "Australia/ASX"),
         \(x) qlcal::isBusinessDay(as.Date("2026-02-16"), xp=qlcal::getCalendar(x)))
UnitedStates/NYSE        Canada/TSX     Australia/ASX 
            FALSE             FALSE              TRUE 
>

The full details from NEWS.Rd follow.

Changes in version 0.1.0 (2026-02-18)

Invalid calendars return id ‘TARGET’ now

Calendar object can be created on the fly and passed to the date-calculating functions; if missing global one used

For several functions a missing date object now implies computation on the current date, e.g. isBusinessDay()

Courtesy of my CRANberries, there is a diffstat report for this release. See the project page and package documentation for more details, and more examples.

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.

Edited 2026-02-21 to correct a minor earlier error: it referenced a QuantLib 1.42 release which does not (yet) exist.

Russell Coker: Links February 2026

etbe — 2026-02-17T08:09:17+00:00

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

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

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

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

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

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

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

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

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

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

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

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

Antoine Beaupré: Keeping track of decisions using the ADR model

Antoine Beaupré — 2026-02-16T20:21:54+00:00

In the Tor Project system Administrator's team (colloquially known as TPA), we've recently changed how we take decisions, which means you'll get clearer communications from us about upcoming changes or targeted questions about a proposal.

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

The new process

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

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

a simpler template
a simpler process
communication guidelines separate from the decision record

The template

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

Context: What is the issue that we're seeing that is motivating this decision or change?
Decision: What is the change that we're proposing and/or doing?
Consequences: What becomes easier or more difficult to do because of this change?
More Information (optional): What else should we know? For larger projects, consider including a timeline and cost estimate, along with the impact on affected users (perhaps including existing Personas). Generally, this includes a short evaluation of alternatives considered.
Metadata: status, decision date, decision makers, consulted, informed users, and link to a discussion forum

The previous RFC template had 17 (seventeen!) headings, which encouraged much longer documents. Now, the decision record will be easier to read and digest at one glance.

An immediate effect of this is that I've started using GitLab issues more for comparisons and brainstorming. Instead of dumping in a document all sorts of details like pricing or in-depth alternatives comparison, we record those in the discussion issue, keeping the document shorter.

The process

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

Major decisions are introduced to stakeholders in a meeting, smaller ones by email. A delay allows people to submit final comments before adoption.

Now, of course, the devil is in the details (and ADR-101), but the point is to keep things simple.

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

Inversely, some decisions degenerate into endless discussions around trivial issues because too many stakeholders are consulted, a problem known as the Law of triviality, also known as the "Bike Shed syndrome".

The new process better identifies stakeholders:

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

Picking those stakeholders is still tricky, but our definitions are more explicit and aligned to the classic RACI matrix (Responsible, Accountable, Consulted, Informed).

Communication guidelines

Finally, a crucial part of the process (ADR-102) is to decouple the act of making and recording decisions from communicating about the decision. Those are two radically different problems to solve. We have found that a single document can't serve both purposes.

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

How we got there

The ADR process is not something I invented. I first stumbled upon it in the Thunderbird Android project. Then, in parallel, I was in the process of reviewing the RFC process, following Jacob Kaplan-Moss's criticism of the RFC process. Essentially, he argues that:

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

And, indeed, I have been guilty of a lot of those issues. A verbose writer, I have written extremely long proposals that I suspect no one has ever fully read. Some proposals were adopted by exhaustion, or ignored because not looping in the right stakeholders.

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

What's next?

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

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

We can't wait to hear what you think of the new process and how it works for you, here or in the discussion issue! We're particularly interested in people that are already using a similar process, or that will adopt one after reading this.

Note: this article was also published on the Tor Blog.

Philipp Kern: What is happening with this "connection verification"?

Philipp Kern — 2026-02-16T19:55:14+00:00

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

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

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

How is it implemented?

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

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

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

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

Conclusion

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

Antoine Beaupré: Kernel-only network configuration on Linux

Antoine Beaupré — 2026-02-16T14:40:50+00:00

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

works across all distributions
doesn't require any software installed apart from the kernel and a boot loader (no systemd-networkd, ifupdown, NetworkManager, nothing)
is backwards compatible all the way back to Linux 2.0, in 1996

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

Known options in Debian

People following Debian development might have noticed there are now four ways of configuring the network Debian system. At least that is what the Debian wiki claims, namely:

ifupdown (/etc/network/interfaces): traditional static configuration system, mostly for workstations and servers that has been there forever in Debian (since at least 2000), documented in the Debian wiki
NetworkManager: self-proclaimed "standard Linux network configuration", mostly used on desktops but technically supports servers as well, see the Debian wiki page (introduced in 2004)
systemd-network: used more for servers, see Debian reference Doc Chapter 5 (introduced some time around Debian 8 "jessie", in 2015)
Netplan: latest entry (2018), YAML-based configuration abstraction layer on top of the above two, see also Debian reference Doc Chapter 5 and the Debian wiki

At this point, I feel ifupdown is on its way out, possibly replaced by systemd-networkd. NetworkManager already manages most desktop configurations.

A "new" network configuration system

The method is this:

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

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

The oldest trace I found is in this 2002 commit, which imports the whole file at once, but the option might goes back as far as 1996-1997, if the copyright on the file is correct and the option was present back then.

What are you doing.

The trick is to add an ip= parameter to the kernel's command-line. The syntax, as mentioned above, is in nfsroot.txt and looks like this:

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

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

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

We're ignoring the options:

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

Note that the Red Hat manual has a different opinion:

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

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

Examples

For example, this command-line setting:

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

... will set the IP address to 192.0.2.42/24 and the gateway to 192.0.2.1. This will properly guess the network interface if there's a single one.

A DHCP only configuration will look like this:

ip=::::::dhcp

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

GRUB

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

GRUB_CMDLINE_LINUX=

and change it to:

GRUB_CMDLINE_LINUX=ip=::::::dhcp

systemd-boot and UKI setups

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

This assumes that is the Cmdline=@ setting in /etc/kernel/uki.conf. See 2025-08-20-luks-ukify-conversion for my minimal documentation on this.

Other systems

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

Arch (11 options, mostly /etc/default/grub, /boot/loader/entries/arch.conf for systemd-boot or /etc/kernel/cmdline for UKI)
Fedora (mostly /etc/default/grub, may be more RHEL mentions grubby, possibly some systemd-boot things here as well)
Gentoo (5 options, mostly /etc/default/grub, /efi/loader/entries/gentoo-sources-kernel.conf for systemd-boot, or /etc/kernel/install.d/95-uki-with-custom-opts.install)

It's interesting that /etc/default/grub is consistent across all distributions above, while the systemd-boot setups are all over the place (except for the UKI case), while I would have expected those be more standard than GRUB.

dropbear-initramfs

If dropbear-initramfs is setup, it already requires you to have such a configuration, and it might not work out of the box.

This is because, by default, it disables the interfaces configured in the kernel after completing its tasks (typically unlocking the encrypted disks).

To fix this, you need to disable that "feature":

IFDOWN="none"

This will keep dropbear-initramfs from disabling the configured interface.

Why?

Traditionally, I've always setup my servers with ifupdown on servers and NetworkManager on laptops, because that's essentially the default. But on some machines, I've started using systemd-networkd because ifupdown has ... issues, particularly with reloading network configurations. ifupdown is a old hack, feels like legacy, and is Debian-specific.

Not excited about configuring another service, I figured I would try something else: just configure the network at boot, through the kernel command-line.

I was already doing such configurations for dropbear-initramfs (see this documentation), which requires the network the be up for unlocking the full-disk encryption keys.

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

Caveats

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

This is useful for servers where the network configuration will not change after boot. Of course, this won't work on laptops or any mobile device.
This only works for configuring a single, simple, interface. You can't configure multiple interfaces, WiFi, bridges, VLAN, bonding, etc.
It does support IPv6 and feels like the best way to configure IPv6 hosts: true zero configuration.
It likely does not work with a dual-stack IPv4/IPv6 static configuration. It might work with a dynamic dual stack configuration, but I doubt it.
I don't know what happens when a DHCP lease expires. No daemon seems to be running so I assume leases are not renewed, so this is more useful for static configurations, which includes server-side reserved fixed IP addresses. (A non-renewed lease risks getting reallocated to another machine, which would cause an addressing conflict.)
It will not automatically reconfigure the interface on link changes, but ifupdown does not either.
It will not write /etc/resolv.conf for you but the dns0-ip and dns1-ip do end up in /proc/net/pnp which has a compatible syntax, so a common configuration is:
```
ln -s /proc/net/pnp /etc/resolv.conf
```
I have not really tested this at scale: only a single, test server at home.

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

Cleanup

Once you have this configuration, you don't need any "user" level network system, so you can get rid of everything:

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

Note that ifupdown (and probably others) leave stray files in (e.g.) /etc/network which you might want to cleanup, or keep in case all this fails and I have put you in utter misery. Configuration files for other packages might also be left behind, I haven't tested this, no warranty.

Credits

This whole idea came from the A/I folks (not to be confused with AI) who have been doing this forever, thanks!

Benjamin Mako Hill: Why do people participate in similar online communities?

Benjamin Mako Hill — 2026-02-16T03:13:59+00:00

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

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

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

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

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

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

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

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

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

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

Steinar H. Gunderson: A286874(15) >= 42

Steinar H. Gunderson — 2026-02-14T18:56:00+00:00

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

000000000011111
000000011100011
000000101101100
000001010110100
000001101010001
000001110001010
000010011011000
000100100110010
000110010000110
000110100001001
000111001100000
001000110000101
001010000110001
001010101000010
001011000001100
001100001010100
001100010101000
001101000000011
010001000101001
010010001000101
010010110100000
010011000010010
010100001001010
010100010010001
010101100000100
011000000100110
011000100011000
011001011000000
100001001000110
100010000101010
100010100010100
100011010000001
100100000100101
100100111000000
100101000011000
101000001001001
101000010010010
101001100100000
110000001110000
110000010001100
110000100000011
111110000000000

This shows that A286874 a(15) >= 42.

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

Bits from Debian: DebConf 26 Registration and Call for Proposals are open

Carlos Henrique Lima Melara, Santiago Ruano Rincón — 2026-02-14T12:15:00+00:00

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

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

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

As always, basic registration for DebConf is free of charge for attendees. If you are attending the conference in a professional capacity or as a representative of your company, we kindly ask that you consider registering in one of our paid categories to help cover the costs of organizing the conference and to support subsidizing other community members.

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

We also encourage eligible individuals to apply for a diversity bursary. Travel, food, and accommodation bursaries are also available. More details can be found on the bursary info page.

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

Call for proposals

The call for proposals for talks, discussions and other activities is also open. To submit a proposal you need to create an account on the website, and then use the "Submit Talk" button in the profile section.

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

Become a sponsor

DebConf 26 is also accepting sponsors. Interested companies and organizations may contact the DebConf team through sponsors@debconf.org or visit the DebConf 26 website.

See you in Santa Fe,

The DebConf 26 Team

Erich Schubert: Dogfood Generative AI

Erich Schubert — 2026-02-13T10:29:02+00:00

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

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

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

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

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

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

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

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

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

Dogfood the AI

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

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

Here is an example prompt that you can use:

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

Generate a {lang} implementation (with bugs) of: {n} ({desc})

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

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

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

Colin Watson: Free software activity in January 2026

Colin Watson — 2026-02-08T19:30:11+00:00

About 80% of my Debian contributions this month were sponsored by Freexian, as well as one direct donation via GitHub Sponsors (thanks!). If you appreciate this sort of work and are at a company that uses Debian, have a look to see whether you can pay for any of Freexian‘s services; as well as the direct benefits, that revenue stream helps to keep Debian development sustainable for me and several other lovely people.

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

Python packaging

New upstream versions:

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

Fixes for Python 3.14:

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

Fixes for pytest 9:

Porting away from the deprecated pkg_resources:

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

Other build/test failures:

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

Other bugs:

Other bits and pieces

Alejandro Colomar reported that man(1) ignored the MANWIDTH environment variable in some circumstances. I investigated this and fixed it upstream.

I contributed an ubuntu-dev-tools patch to stop recommending sudo.

I added forky support to the images used in Salsa CI pipelines.

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

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

Code reviews

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

Vincent Bernat: Fragments of an adolescent web

Vincent Bernat — 2026-02-08T14:51:44+00:00

I have unearthed a few old articles typed during my adolescence, between 1996 and 1998. Unremarkable at the time, these pages now compose, three decades later, the chronicle of a vanished era.¹

The word â€œblogâ€� does not exist yet. Wikipedia has yet to come. Google has not been born. AltaVista reigns over searches, while already struggling to embrace the nascent immensity of the web². To meet someone, you had to agree in advance and prepare your route on paper maps. ğŸ—ºï¸�

The web is taking off. The CSS specification has just emerged, HTML tables still serve for page layout. Cookies and advertising banners are making their appearance. Pages are adorned with music and videos, forcing browsers to arm themselves with plugins. Netscape Navigator sits on 86% of the territory, but Windowsâ€¯95 now bundles Internet Explorer to quickly catch up. Facing this offensive, Netscape open-sources its browser.

France falls behind. Outside universities, Internet access remains expensive and laborious. Minitel still reigns, offering a phone directory, train tickets, remote shopping. This was not yet possible with the Internet: buying a CD online was a pipe dream. Encryption suffers from inappropriate regulation: the DES algorithm is capped at 40 bits and cracked in a few seconds.

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

I recently noticed that Google no longer fully indexes my blog. For example, it is no longer possible to find the article on lanÄ‰o. I assume this is a consequence of the explosion of AI-generated content or a change in priorities for Google.Â â†©ï¸�

Thorsten Alteholz: My Debian Activities in January 2026

alteholz — 2026-02-08T13:25:37+00:00

Debian LTS/ELTS

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

During my allocated time I uploaded or worked on:

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

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

Debian Printing

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

Debian Lomiri

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

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

Debian Astro

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

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

Debian IoT

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

Debian Mobcom

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

misc

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

… liburjtag to unstable.

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

Louis-Philippe Véronneau: Montreal Subway Foot Traffic Data, 2025 edition

Louis-Philippe Véronneau — 2026-02-08T05:00:00+00:00

Another year of data from Société de Transport de Montréal, Montreal's transit agency!

A few highlights this year:

Although the Saint-Michel station closed for emergency repairs in November 2024, traffic never bounced back to its pre-closure levels and is still stuck somewhere around 2022 Q2 levels. I wonder if this could be caused by the roadwork on Jean-Talon for the new Blue Line stations making it harder for folks in Montreal-Nord to reach the station by bus.
The effects of the opening of the Royalmount shopping center has had a durable impact on the traffic at the De la Savane station. I reported on this last year, but it seems this wasn't just a fad.
With the completion of the Deux-Montagnes branch of the Réseau express métropolitain (REM, a light-rail, above the surface transit network still in construction), the transfer stations to the Montreal subway have seen major traffic increases. The Édouard-Montpetit station has nearly reached its previous all-time record of 2015 and the McGill station has recovered from the general slump all the other stations have had in 2025.
The Assomption station, which used to have one of the lowest number of riders of the subway network, has had a tremendous growth in the past few years. This is mostly explained by the many high-rise projects that were built around the station since the end of the COVID-19 pandemic.
Although still affected by a very high seasonality, the Jean-Drapeau station broke its previous record of 2019, a testament of the continued attraction power of the various summer festivals taking place on the Sainte-Hélène et Notre-Dame islands.

More generally, it seems the Montreal subway has had a pretty bad year. Traffic had been slowly climbing back since the COVID-19 pandemic, but this is the first year since 2020 such a sharp decline can be witnessed. Even major stations like Jean-Talon or Lionel-Groulx are on a downward trend and it is pretty worrisome.

As for causes, a few things come to mind. First of all, as the number of Montrealers commuting to work by bike continues to rise¹, a modal shift from public transit to active mobility is to be expected. As local experts put it, this is not uncommon and has been seen in other cities before.

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

Sadly, this also brought a unprecedented wave of incivilities. As riders' sense of security sharply decreased, the STM eventually resorted to banning unhoused people from sheltering in the subway. This decision did bring back some peace to the network, but one can posit damage had already been done and many casual riders are still avoiding the subway for this reason.

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

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

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

Licences

The subway map displayed on this page, the original dataset and my modified dataset are licenced under CCO 1.0: they are in the public domain.
The R code I wrote is licensed under the GPLv3+. It has not changed in a few years.

Mostly thanks to major improvements to the cycling network and the BIXI bikesharing program. ↩

Reproducible Builds: Reproducible Builds in January 2026

Reproducible Builds — 2026-02-06T20:04:31+00:00

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

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

Flathub now testing for reproducibility

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

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

The test results and status is available on their reproducible builds page.

Reproducibility identifying software projects that will fail to build in 2038

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

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

At the time of publication, Bernhard’s topic had generated 50 comments in response.

Distribution work

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

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

In Debian this month:

Scott Talbert uploaded a new version of dh-haskell (0.6.13), reverting parallel support as it broke reproducibility, thereby fixing Debian bug #1125000.
Vagrant Cascadian posted to our mailing list on the topic of “Duplicate Debian packages with matching name-version-arch problem”. The issue is that .buildinfo files only “record the package name, version and architecture of the build-dependencies (and perhaps a bit more), but there are corner cases where multiple artifacts have the same name, version and architecture”. This generated some discussion on the mailing list as well as elsewhere in Debian.
Roland Clobus also posted to our mailing list regarding Building Debian Live images from snapshot.debian.org. This surfaced an issue regarding the timestamps of the .deb file, leading to Roland filing Debian bug #1126000 to liaise with the developers of the snapshot.debian.org service.
A change was made to migrate away from using the results from tests.reproducible-builds.org in deciding whether a package is a suitable candidate for the Debian testing distribution (the staging area for the next stable Debian release) to use the results from reproduce.debian.net instead. This was, according to Paul Gevers’ merge request, because the former service “does so by building twice in a row with varying build environment. What we are actually interested in is if the binaries that we ship can be reproduced”. The information provided by reproduce.debian.net in future will be used to delay or speed up packages’ migration time based on their reproducibility status, and further in the future shall be used to block unreproducible packages from migrating entirely.
41 reviews of Debian packages were added, 7 were updated and 37 were removed this month adding to our knowledge about identified issues. Chris Lamb identified and added a new source_date_epoch_affected_by_timezone_by_d_compiler_gdc issue type, as well as timezone_variant_in_argparse_manpage.

In NixOS this month, it was announced that the GNU Guix Full Source Bootstrap was ported to NixOS as part of Wire Jansen bachelor’s thesis (PDF). At the time of publication, this change has landed in NiX’ stdev distribution.

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

Tool development

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

Fix test compatibility with u-boot-tools version 2026-01. […]
Drop the implied Rules-Requires-Root: no entry in debian/control. […]
Bump Standards-Version to 4.7.3. […]
Reference the Debian ocaml package instead of ocaml-nox. (#1125094)
Apply a patch by Jelle van der Waa to adjust a test fixture match new lines. […]
Also the drop implied Priority: optional from debian/control. […]

In addition, Holger Levsen uploaded two versions of disorderfs, first updating the package from FUSE 2 to FUSE 3 as described in last months report, as well as updating the packaging to the latest Debian standards. A second upload (0.6.2-1) was subsequently made, with Holger adding instructions on how to add the upstream release to our release archive and incorporating changes by Roland Clobus to set _FILE_OFFSET_BITS on 32-bit platforms, fixing a build failure on 32-bit systems. Vagrant Cascadian updated diffoscope in GNU Guix to version 311-2-ge4ec97f7 and disorderfs to 0.6.2.

Two new academic papers

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

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

A PDF of their paper is available online.

Quentin Guilloteau, Antoine Waehren and Florina M. Ciorba of the University of Basel in Sweden also published a Docker-related paper, theirs called Longitudinal Study of the Software Environments Produced by Dockerfiles from Research Artifacts:

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

A PDF of their paper is available online.

Miscellaneous news

On our mailing list this month:

kpcyrd started a thread after they noticed that “SWHID (also known as ISO/IEC 18670:2025) was published 1.0 in 2022 and ISO standardized in 2025, but uses the insecure SHA-1 as core cryptographic primitive”, asking whether there have been any attempts to upgrade this to SHA-256 or similar.
Jan-Benedict Glaw asked about the Reproducibility for Libreoffice [when performing] ODT to PDF conversion after they observed that “simply calling libreoffice --convert-to pdf some.odt results in unreproducible output PDF. After some replies, Jan-Benedict wrote back to observe that it may be an issue with both timestamps and embedded fonts.

Lastly, kpcyrd added a Rust section to the Stable order for outputs page on our website. […]

Upstream patches

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

Bernhard M. Wiedemann:
- clamav
- kf6-kuserfeedback
- libaom
- Nim
- otp
- Switcheroo (by Khaleel Al-Adhami)
- uwsm
- ZEO
Chris Lamb:
- #1124697 filed against sqlalchemy-i18n.
- #1125671 filed against tea-cli.
- #1125725 filed against libimage-librsvg-perl.
- #1125727 filed against seer.
- #1125729 filed against grabix.
- #1126038 filed against hovercraft.
- #1126039 filed against lomiri-location-service.
- #1126092 filed against argparse-manpage.
- #1126454 filed against xarray-safe-rcm.
- #1126512 filed against gcc-15 (forwarded upstream).
Jochen Sprickerhof:
- #1124951 filed against rsyslog.
- #1125000 filed against dh-haskell.

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

Birger Schacht: Status update, January 2026

Birger Schacht — 2026-02-06T05:28:51+00:00

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

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

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

There was a bug report for carl asking for Windows support. carl used the xdg create for looking up the XDG directories, but xdg does not support windows systems (and it seems this will not change) The reporter also provided a PR to replace the dependency with the directories crate which more system agnostic. I adapted the PR a bit and merged it and released version 0.6.0 of carl.

At my dayjob I refactored django-grouper. django-grouper is a package we use to find duplicate objects in our data. Our users often work with datasets of thousands of historical persons, places and institutions and in projects that run over years and ingest data from multiple sources, it happens that entries are created several times. I wrote the initial app in 2024, but was never really happy about the approach I used back then. It was based on this blog post that describes how to group spreadsheet text cells. It uses sklearns TfidfVectorizer with a custom analyzer and the library sparse_dot_topn for creating the matrix. All in all the module to calculate the clusters was 80 lines and with sparse_dot_topn it pulled in a rather niche Python library. I was pretty sure that this functionality could also be implemented with basic sklearn functionality and it was: we are now using DictVectorizer because in a Django app we are working with objects that can be mapped to dicts anyway. And for clustering the data, the app now uses the DBSCAN algorithm (with the manhattan distance as metric). The module is now only half the size and the whole app lost one dependency! I released those changes as version 0.3.0 of the app.

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

Some examples of talks I found interesting so far:

a talk about supporting Python web deployments with Rust in the Rust Developer room
a talk about duckdb in the Python Developer room
an introduction to particleos in the Distributions Developer room

Swiss JuristGate: JuristGate is for sale: three billion Swiss francs for a domain name

Swiss JuristGate — 2026-02-04T18:30:00+00:00

When the share price of Credit Suisse, one of Switzerland's two top banks, went into its death spiral, the Swiss authorities had some discussions among themselves and the inevitable result of that discussion was the sale of Credit Suisse to their main rival, UBS.

The public were told that UBS had offered three billion Swiss francs to compensate the shareholders of Credit Suisse for their shares. Some people were sceptical about the method used to reach this valuation. Nonetheless, it was important for Swiss national pride.

When writing the reports on the JuristGate web site, I've attempted to operate with the highest level of accuracy and integrity. Nonetheless, everybody has their price. If somebody offered me three billion Swiss francs for the domain then I would probably do like Urban Angehrn and Birgit Rutishauser and take a lengthy garden leave.

In the meantime, to make up for the wayward support from Swiss legal insurance I've started a crowdfunding campaign to resolve one of the disputes relating to Debian. This is vital because we all do a lot of work for Debian and we are all entitled to equal recognition.

In a previous blog, I looked at the prompt and efficient manner in which Bernice is undertaking enforcement action to protect the public from rogue health practitioners in the State of Victoria.

Bernice generated a lot of news stories when she banned a social media influencer, Emily Lal, who promoted herself as The Authentic Birthkeeper. Lal had promoted wild birthing. A number of mothers and babies have died around the world when following the advice of social media influencers.

I don't know how much Bernice gets paid but I found a job vacancy for her deputy. The salary is in the range up to $290,000 per year. That is approximately CHF 160,000 Swiss francs.

As Bernice is a nurse and keyworkers never get paid what they are really worth I'm guessing her salary is not too much bigger than that.

The FINMA annual reports reveal the salaries for the CEO and executive team. Urban Angehrn's salary was CHF 602,000. It looks like FINMA pays their CEO three or four times what the State of Victoria pays Bernice.

We can compare their performance and see how many banning orders each of them has published:

FINMA (Swiss financial regulator) banning orders: they published 24 bans between 2018 and 2025. Some bans are not reported publicly.

Health Complaints Commissioner (Victoria) banning orders: Bernice has personally signed over 100 interim or permanent bans since taking office in July 2022.

This was Urban Angehrn's payout, CHF 581,000, when he resigned at the same time that FINMA published their anonymous decision about Parreaux, Thiebaud & Partners. Clients/victims were offered nothing.

Ben Hutchings: FOSS activity in January 2026

Ben Hutchings — 2026-02-04T11:39:17+00:00

Debian packages:
- dracut:
  - Bugs:
    - replied to and reassigned #1124400: update-initramfs no longer includes /lib/modules/<kver>/updates directory
- flash-kernel:
  - Bugs:
    - closed #1102690: A higher version (…) is still installed, no reflashing required
    - closed #1125327: since linux 6.18, flash-kernel fails to find dtbs in /usr/lib/linux-image-*
  - Uploads:
    - uploaded version 3.110 to unstable
    - uploaded version 3.110~bpo13+1 to trixie-backports
- kernel-sec:
  - Merge requests:
    - opened !30: scripts/import-korg-vulns: Ignore issues in unsupported architectures
- libvirt:
  - Bugs:
    - (LTS) opened and replied to #1124549: libvirt passes invalid flags for network interface deletion
- linux:
  - Bugs:
  - Merge requests:
    - reviewed !1784: Add breaks on reform-tools and flash-kernel versions before support for…
  - (LTS) updated the bullseye-security branch to 5.10.248, but did not upload it
- (LTS) linux-6.1:
  - uploaded version 6.1.159-1~deb11u1 to bullseye-security
- linux-base:
  - Bugs:
  - Uploads:
    - uploaded version 4.12.1 to trixie
    - uploaded version 4.15 to unstable
- ministat:
  - Bugs:
    - closed #1123854: ministat: Packaging vcs doesn’t work, upstream vcs unspecified
    - closed #1123856: ministat: ministat crashes given all-inf input
  - Uploads:
    - uploaded version 20251113-1 to unstable
    - uploaded version 20251113-2 to unstable
- wireless-regdb:
  - Merge requests:
    - merged !7: Drop unnecessary B-D m2crypto (Closes: #1126431)
Debian non-package bugs:
- release.debian.org:
  - opened #1126020: trixie-pu: package linux-base/4.12.1
Mailing lists:
- debian-kernel:
  - posted Agenda items for kernel-team meeting on 2026-01-07
  - replied to Questions on debdiff for linux-signed-{amd64,arm64} in trixie-backports
  - (LTS) replied to [regression 5.10.y] Libvirt can no longer delete macvtap devices …
  - posted cpp-httplib FTBFS in unstable
  - (LTS) replied to kernel 5.10.0-28-amd64: linux-headers needed
- debian-lts:
  - posted and replied to Regression update for libvirt in bullseye?
- debian-lts-announce:
  - posted [SECURITY] [DLA 4436-1] linux-6.1 security update
- stable:
  - (LTS) posted [5.10] net/sched: act_ife: convert comma to semicolon
  - (LTS) posted [5.10] regression: virtual consoles 2-12 unusable
  - (LTS) reviewed and replied to various patches for 5.10 … … … … … … … … … … … … … … … … … …

Jonathan Dowland: FOSDEM 2026 talk recording available

jmtd — 2026-02-03T16:21:24+00:00

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

Benjamin Mako Hill: What do people do when they edit Wikipedia through Tor?

Benjamin Mako Hill — 2026-02-01T12:19:11+00:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Russ Allbery: Review: Paladin's Faith

Russ Allbery — 2026-02-01T04:54:00+00:00

Review: Paladin's Faith, by T. Kingfisher

Series:	The Saint of Steel #4
Publisher:	Red Wombat Studio
Copyright:	2023
ISBN:	1-61450-614-0
Format:	Kindle
Pages:	515

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

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

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

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

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

This is, like the other books in this series, a slow-burn romance with infuriating communication problems and a male protagonist who would do well to seek out a sack of hammers as a mentor. However, it has two things going for it that most books in this series do not: a long and complex plot to which the romance takes a back seat, and Marguerite, who is not particularly interested in playing along with the expected romance developments. There are also two main paladins in this story, not just one, and the other is one of the two female paladins of the Saint of Steel and rather more entertaining than Shane.

I generally like court intrigue stories, which is what fills most of this book. Marguerite is an experienced operative, so the reader gets some solid competence porn, and the paladins are fish out of water but are also unexpectedly dangerous, which adds both comedy and satisfying table-turning. I thoroughly enjoyed the maneuvering and the culture clashes. Marguerite is very good at what she does, knows it, and is entirely uninterested in other people's opinions about that, which short-circuits a lot of Shane's most annoying behavior and keeps the story from devolving into mopey angst like some of the books in this series have done.

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

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

By this point in the series, you probably know if you like the general formula. Compared to the previous book, Paladin's Hope, I thought Paladin's Faith was much stronger and more interesting, but it's clearly of the same type. If, like me, you like the plots but not the romance, the plot here is more substantial. You will have to decide if that makes up for a romance in the typical T. Kingfisher configuration.

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

Rating: 8 out of 10

Joey Hess: the local weather

Joey Hess — 2026-01-31T18:25:57+00:00

Snow coming. I'm tuned into the local 24 hour slop weather stream. AI generated, narrated, up to the minute radar and forecast graphics. People popping up on the live weather map with questions "snow soon?" (They pay for the privilege.) LLM generating reply that riffs on their name. Tuned to keep the urgency up, something is always happening somewhere, scanners are pulling the police reports, live webcam description models add verisimilitude to the description of the morning commute. Weather is happening.

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

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

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

(Not fiction FYI.)

Michael Prokop: apt, SHA-1 keys + 2026-02-01

mika — 2026-01-31T13:57:30+00:00

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

root@424812bd4556:/# apt update
Get:1 http://foo.example.org/debian demo InRelease [4229 B]
Hit:2 http://deb.debian.org/debian trixie InRelease
Hit:3 http://deb.debian.org/debian trixie-updates InRelease
Hit:4 http://deb.debian.org/debian-security trixie-security InRelease
Get:5 http://foo.example.org/debian demo/main amd64 Packages [1097 B]
Fetched 5326 B in 0s (43.2 kB/s)
All packages are up to date.
Warning: http://foo.example.org/debian/dists/demo/InRelease: Policy will reject signature within a year, see --audit for details

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

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

Let’s simulate the future:

root@424812bd4556:/# apt --update -y install faketime
[...]
root@424812bd4556:/# export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 FAKETIME="2026-08-29 23:42:11" 
root@424812bd4556:/# date
Sat Aug 29 23:42:11 UTC 2026

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

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

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

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

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

[hash_algorithms]
sha1.second_preimage_resistance = 2026-02-01    # Extend the expiry for legacy repositories
sha224 = 2026-02-01

[packets]
signature.v3 = 2026-02-01   # Extend the expiry

Adjust this according to your needs:

root@424812bd4556:/# mkdir -p /etc/crypto-policies/back-ends/

root@424812bd4556:/# cp /usr/share/apt/default-sequoia.config /etc/crypto-policies/back-ends/apt-sequoia.config

root@424812bd4556:/# $EDITOR /etc/crypto-policies/back-ends/apt-sequoia.config

root@424812bd4556:/# cat /etc/crypto-policies/back-ends/apt-sequoia.config
# APT Sequoia override configuration
[asymmetric_algorithms]
dsa2048 = 2024-02-01
dsa3072 = 2024-02-01
dsa4096 = 2024-02-01
brainpoolp256 = 2028-02-01
brainpoolp384 = 2028-02-01
brainpoolp512 = 2028-02-01
rsa2048  = 2030-02-01

[hash_algorithms]
sha1.second_preimage_resistance = 2026-09-01    # Extend the expiry for legacy repositories
sha224 = 2026-09-01

[packets]
signature.v3 = 2026-02-01   # Extend the expiry

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

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

Please note that this is a workaround, and not a proper solution.

Benjamin Mako Hill: Dialogue

Benjamin Mako Hill — 2026-01-31T10:59:24+00:00

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

M: Yunomi.

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

Russ Allbery: Review: Dragon Pearl

Russ Allbery — 2026-01-31T05:26:00+00:00

Review: Dragon Pearl, by Yoon Ha Lee

Series:	Thousand Worlds #1
Publisher:	Rick Riordan Presents
Copyright:	2019
ISBN:	1-368-01519-0
Format:	Kindle
Pages:	315

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

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

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

It's common for reviews of this book to open with a caution that this is a middle-grade adventure novel and you should not expect a story like Ninefox Gambit. I will be boring and repeat that caution. Dragon Pearl has a single first-person viewpoint and a very linear and straightforward plot. Adult readers are unlikely to be surprised by plot twists; the fun is the world-building and seeing how Min manages to work around plot obstacles.

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

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

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

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

One warning: The text of this book opens with an introduction by Rick Riordan that is just fluff marketing and that spoils the first few chapters of the book. It is unmarked as such at the beginning and tricked me into thinking it was the start of the book proper, and then deeply annoyed me. If you do read this book, I recommend skipping the utterly pointless introduction and going straight to chapter one.

Followed by Tiger Honor.

Rating: 6 out of 10