Debian is a trademark of Software in the Public Interest, Inc. This site is operated independently in the spirit of point three of the Debian Social Contract which tells us We will not hide problems.

Feeds

September 14, 2025

Ian Jackson

tag2upload in the first month of forky

tl;dr: tag2upload (beta) is going well so far, and is already handling around one in 13 uploads to Debian.

Introduction and some stats

We announced tag2upload’s open beta in mid-July. That was in the middle of the the freeze for trixie, so usage was fairly light until the forky floodgates opened.

Since then the service has successfully performed 637 uploads, of which 420 were in the last 32 days. That’s an average of about 13 per day. For comparison, during the first half of September up to today there have been 2475 uploads to unstable. That’s about 176/day.

So, tag2upload is already handling around 7.5% of uploads. This is very gratifying for a service which is advertised as still being in beta!

Sean and I are very pleased both with the uptake, and with the way the system has been performing.

Recent UI/UX improvements

During this open beta period we have been hard at work. We have made many improvements to the user experience.

Current git-debpush in forky, or trixie-backports, is much better at detecting various problems ahead of time.

When uploads do fail on the service the emailed error reports are now more informative. For example, anomalies involving orig tarballs, which by definition can’t be detected locally (since one point of tag2upload is not to have tarballs locally) now generally result in failure reports containing a diffstat, and instructions for a local repro.

Why we are still in beta

There are a few outstanding work items that we currently want to complete before we declare the end of the beta.

Retrying on Salsa-side failures

The biggest of these is that the service should be able to retry when Salsa fails. Sadly, Salsa isn’t wholly reliable, and right now if it breaks when the service is trying to handle your tag, your upload can fail.

We think most of these failures could be avoided. Implementing retries is a fairly substantial task, but doesn’t pose any fundamental difficulties. We’re working on this right now.

Other notable ongoing work

We want to support pristine-tar, so that pristine-tar users can do a new upstream release. Andrea Pappacoda is working on that with us. See #1106071. (Note that we would generally recommend against use of pristine-tar within Debian. But we want to support it.)

We have been having conversations with Debusine folks about what integration between tag2upload and Debusine would look like. We’re making some progress there, but a lot is still up in the air.

We are considering how best to provide tag2upload pre-checks as part of Salsa CI. There are several problems detected by the tag2upload service that could be detected by Salsa CI too, but which can’t be detected by git-debpush.

Common problems

We’ve been monitoring the service and until very recently we have investigated every service-side failure, to understand the root causes. This has given us insight into the kinds of things our users want, and the kinds of packaging and git practices that are common. We’ve been able to improve the system’s handling of various anomalies and also improved the documentation.

Right now our failure rate is still rather high, at around 7%. Partly this is because people are trying out the system on packages that haven’t ever seen git tooling with such a level of rigour.

There are two classes of problem that are responsible for the vast majority of the failures that we’re still seeing:

Reuse of version numbers, and attempts to re-tag

tag2upload, like git (and like dgit), hates it when you reuse a version number, or try to pretend that a (perhaps busted) release never happened.

git tags aren’t namespaced, and tend to spread about promiscuously. So replacing a signed git tag, with a different tag of the same name, is a bad idea. More generally, reusing the same version number for a different (signed!) package is poor practice. Likewise, it’s usually a bad idea to remove changelog entries for versions which were actually released, just because they were later deemed improper.

We understand that many Debian contributors have gotten used to this kind of thing. Indeed, tools like dcut encourage it. It does allow you to make things neat-looking, even if you’ve made mistakes - but really it does so by covering up those mistakes!

The bottom line is that tag2upload can’t support such history-rewriting. If you discover a mistake after you’ve signed the tag, please just burn the version number and add a new changelog stanza.

One bonus of tag2upload’s approach is that it will discover if you are accidentally overwriting an NMU, and report that as an error.

Discrepancies between git and orig tarballs

tag2upload promises that the source package that it generates corresponds precisely to the git tree you tag and sign.

Orig tarballs make this complicated. They aren’t present on your laptop when you git-debpush. When you’re not uploading a new upstream version, the tag2upload service reuses existing orig tarballs from the archive. If your git and the archive’s orig don’t agree, the tag2upload service will report an error, rather than upload a package with contents that differ from your git tag.

With the most common Debian workflows, everything is fine:

If you base everything on upstream git, and make your orig tarballs with git archive (or git deborig), your orig tarballs are the same as the git, by construction. We recommend usually ignoring upstream tarballs: most upstreams work in git, and their tarballs can contain weirdness that we don’t want. (At worst, the tarball can contain an attack that isn’t visible in git, as with xz!)

Alternatively, if you use gbp import-orig, the differences (including an attack like Jia Tan’s) are imported into git for you. Then, once again, your git and the orig tarball will correspond.

But there are other workflows where this correspondence may not hold. Those workflows are hazardous, because the thing you’re probably working with locally for your routine development is the git view. Then, when you upload, your work is transplanted onto the orig tarball, which might be quite different - so what you upload isn’t what you’ve been working on!

This situation is detected by tag2upload, precisely because tag2upload checks that it’s keeping its promise: the source package is identical to the git view. (dgit push makes the same promise.)

Get involved

Of course the easiest way to get involved is to start using tag2upload.

We would love to have more contributors. There are some easy tasks to get started with, in bugs we’ve tagged “newcomer” — mostly UX improvements such as detecting certain problems earlier, in git-debpush.

More substantially, we are looking for help with sbuild: we’d like it to be able to work directly from git, rather than needing to build source packages: #868527.



comment count unavailable comments

14 September, 2025 03:36PM

hackergotchi for Dirk Eddelbuettel

Dirk Eddelbuettel

RcppSimdJson 0.1.14 on CRAN: New Upstream Major

A brand new release 0.1.14 of the RcppSimdJson package is now on CRAN.

RcppSimdJson wraps the fantastic and genuinely impressive simdjson library by Daniel Lemire and collaborators. Via very clever algorithmic engineering to obtain largely branch-free code, coupled with modern C++ and newer compiler instructions, it results in parsing gigabytes of JSON parsed per second which is quite mindboggling. The best-case performance is ‘faster than CPU speed’ as use of parallel SIMD instructions and careful branch avoidance can lead to less than one cpu cycle per byte parsed; see the video of the talk by Daniel Lemire at QCon.

This version includes the new major upstream release 4.0.0 with major new features including a ‘builder’ for creating JSON from the C++ side objects. This is something a little orthogonal to the standard R usage of the package to parse and load JSON data but could still be of interest to some.

The short NEWS entry for this release follows.

Changes in version 0.1.14 (2025-09-13)

  • simdjson was upgraded to version 4.0.0 (Dirk in #96

  • Continuous integration now relies a token for codecov.io

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

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

14 September, 2025 02:52PM

September 11, 2025

Jonathan Wiltshire

Debian stable updates explained: security, updates, and point releases

Please consider supporting my work in Debian and elsewhere through Liberapay.

Debian stable updates work through three main channels: point releases, security repositories, and the updates repository. Understanding these ensures your system stays secure and current.

A note about suite names

Every Debian release, or suite, has a codename — the most recent major release was trixie, or Debian 13. The codename uniquely identifies that suite.

We also use changeable aliases to add meaning to the suite’s lifecycle. For example, trixie currently has the alias stable, but when forky becomes stable instead, trixie will become known as oldstable.

This post uses either codenames or aliases depending on context. In source lists, codenames are generally preferred since that avoids surprise major upgrades right after a release is made.

The stable suites (point releases)

stable and oldstable (currently trixie and bookworm) are only updated during a “point release.” This is a minor update released to a major version. For example, 13.1 is the first minor update to trixie. It’s not possible to install older minor versions of a suite except via the snapshots mechanism (not covered here). It’s possible to view past versions via snapshot.debian.org, which preserves historical Debian archives.

There are also the testing and unstable aliases for the development suites. However, these are not relevant for users who want to run officially released versions.

Almost every stable installation of Debian will be opted into a stable or oldstable base suite. An example APT source might look like:

Type: deb
URIs: http://deb.debian.org/debian
Suites: trixie
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Or, in legacy sources.list style:

deb https://deb.debian.org/debian trixie main

The security suites (DSAs explained)

For urgent security-related updates, the Security Team maintains a counterpart suite for each stable suite. These are called stable-security and oldstable-security when maintained by Debian’s security team, and oldstable-security, oldoldstable-security, etc when maintained by the LTS team.

Example APT source:

Type: deb
URIs: https://deb.debian.org/debian-security
Suites: trixie-security
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Or, in legacy sources.list style:

deb https://deb.debian.org/debian-security trixie-security main

The Debian installer enables the security suites by default. Debian Security Announcements (DSAs) are published to debian-security-announce@lists.debian.org.

The updates suites (SUAs and maintenance)

For urgent non-security updates, the final recommended suites are stable-updates and oldstable-updates. This is where updates staged for a point release, but needed sooner, are published. Examples include virus database updates, timezone changes, urgent bug fixes for specific problems and corrections to errors in the release process itself.

Example APT source:

Type: deb
URIs: https://deb.debian.org/debian
Suites: trixie-updates
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Or, in legacy sources.list style:

deb https://deb.debian.org/debian trixie-updates main

Debian enables the updates suites by default. Stable Update Announcements (SUAs) are published to debian-stable-announce@lists.debian.org. This is also where announcements of forthcoming point releases are published.

Summary

These are the recommended suites for all production Debian systems:

SuiteExample codenamePurposeAnnouncements
stabletrixieBase suite containing all the available software for a release. Point releases every 2–4 months including lower-severity security fixes that do not require immediate release.Debian Release Announcements on debian-announce
stable-securitytrixie-securityUrgent security updates.Debian Security Announcements on debian-security-announce
stable-updatestrixie-updatesUrgent non-security updates, data updates and release maintenance.Stable Update Announcements on debian-stable-announce

After a release moves from oldstable to unsupported status, Long Term Support (LTS) takes over for several more years. LTS provides urgent security updates for selected architectures. For details, see wiki.debian.org/LTS.

If you’d like to stay informed, the official Debian announcement lists and release.debian.org share the latest schedules and updates.


Photo by Brian Wangenheim on Unsplash

11 September, 2025 08:29PM by Jonathan

John Goerzen

Performant Full-Disk Encryption on a Raspberry Pi, but Foiled by Twisty UARTs

In my post yesterday, ARM is great, ARM is terrible (and so is RISC-V), I described my desire to find ARM hardware with AES instructions to support full-disk encryption, and the poor state of the OS ecosystem around the newer ARM boards.

I was anticipating buying either a newer ARM SBC or an x86 mini PC of some sort.

More-efficient AES alternatives

Always one to think, “what if I didn’t have to actually buy something”, I decided to research whether it was possible to use encryption algorithms that are more performant on the Raspberry Pi 4 I already have.

The answer was yes. From cryptsetup benchmark:

root@mccoy:~# cryptsetup benchmark --cipher=xchacha12,aes-adiantum-plain64 
# Tests are approximate using memory only (no storage IO).
#            Algorithm |       Key |      Encryption |      Decryption
xchacha12,aes-adiantum        256b       159.7 MiB/s       160.0 MiB/s
xchacha20,aes-adiantum        256b       116.7 MiB/s       169.1 MiB/s
    aes-xts                   256b        52.5 MiB/s        52.6 MiB/s

With best-case reads from my SD card at 45MB/s (with dd if=/dev/mmcblk0 of=/dev/null bs=1048576 status=progress), either of the ChaCha-based algorithms will be fast enough. “Great,” I thought. “Now I can just solve this problem without spending a dollar.”

But not so fast.

Serial terminals vs. serial consoles

My primary use case for this device is to drive my actual old DEC vt510 terminal. I have long been able to do that by running a getty for my FTDI-based USB-to-serial converter on /dev/ttyUSB0. This gets me a login prompt, and I can do whatever I need from there.

This does not get me a serial console, however. The serial console would show kernel messages and could be used to interact with the pre-multiuser stages of the system — that is, everything before the loging prompt. You can use it to access an emergency shell for repair, etc.

Although I have long booted that kernel with console=tty0 console=ttyUSB0,57600, the serial console has never worked but I’d never bothered investigating because the text terminal was sufficient.

You might be seeing where this is going: to have root on an encrypted LUKS volume, you have to enter the decryption password in the pre-multiuser environment (which happens to be on the initramfs).

So I started looking. First, I extracted the initrd with cpio and noticed that the ftdi_sio and usbserial modules weren’t present. Added them to /etc/initramfs-tools/modules and rebooted; no better.

So I found the kernel’s serial console guide, which explicitly notes “To use a serial port as console you need to compile the support into your kernel”. Well, I have no desire to custom-build a kernel on a Raspberry Pi with MicroSD storage every time a new kernel comes out.

I thought — well I don’t stricly need the kernel to know about the console on /dev/ttyUSB0 for this; I just need the password prompt — which comes from userspace — to know about it.

So I looked at the initramfs code, and wouldn’t you know it, it uses /dev/console. Looking at /proc/consoles on that system, indeed it doesn’t show ttyUSB0. So even though it is possible to load the USB serial driver in the initramfs, there is no way to make the initramfs use it, because it only uses whatever the kernel recognizes as a console, and the kernel won’t recognize this. So there is no way to use a USB-to-serial adapter to enter a password for an encrypted root filesystem.

Drat.

The on-board UARTs?

I can hear you know: “The Pi already has on-board serial support! Why not use that?”

Ah yes, the reason I don’t want to use that is because it is difficult to use that, particularly if you want to have RTS/CTS hardware flow control (or DTR/DSR on these old terminals, but that’s another story, and I built a custom cable to map it to RTS/CTS anyhow).

Since you asked, I’ll take you down this unpleasant path.

The GPIO typically has only 2 pins for serial communication: 8 and 10, for TX and RX, respectively.

But dive in and you get into a confusing maze of UARTs. The “mini UART”, the one we are mostly familiar with on the Pi, does not support hardware flow control. The PL011 does. So the natural question is: how do we switch to the PL011, and what pins does it use? Great questions, and the answer is undocumented, at least for the Pi 4.

According to that page, for the Pi 4, the primary UART is UART1, UART1 is the mini UART, “the secondary UART is not normally present on the GPIO connector” and might be used by Bluetooth anyway, and there is no documented pin for RTS/CTS anyhow. (Let alone some of the other lines modems use) There are supposed to be /dev/ttyAMA* devices, but I don’t have those. There’s an enable_uart kernel parameter, which does things like stop the mini UART from changing baud rates every time the VPU changes clock frequency (I am not making this up!), but doesn’t seem to control the PL011 UART selection. This page has a program to do it, and map some GPIO pins to RTS/CTS, in theory.

Even if you get all that working, you still have the problem that the Pi UARTs (all of them of every type) is 3.3V and RS-232 is 5V, so unless you get a converter, you will fry your Pi the moment you connect it to something useful. So, you’re probably looking at some soldering and such just to build a cable that will work with an iffy stack.

So, I could probably make it work given enough time, but I don’t have that time to spare working with weird Pi serial problems, so I have always used USB converters when I need serial from a Pi.

Conclusion

I bought a fanless x86 micro PC with a N100 chip and all the ports I might want: a couple of DB-9 serial ports, some Ethernet ports, HDMI and VGA ports, and built-in wifi. Done.

11 September, 2025 01:41PM by John Goerzen

hackergotchi for Gunnar Wolf

Gunnar Wolf

Saying _hi_ to my good Reproducible Builds friends while reading a magazine article

Just wanted to share… I enjoy reading George V. Neville’s Kode Vicious column, which regularly appears on some of ACM’s publications I follow, such as ACM Queue or Communications.

Today I was very pleasantly surprised, while reading the column titled «Can’t we have nice things» Kode Vicious answers to a question on why computing has nothing comparable to the beauty of ancient physics laboratories turned into museums (i.e. Faraday’s laboratory) by giving a great hat tip to a project stemmed off Debian, and where many of my good Debian friends spend a lot of their energies: Reproducible builds. KV says:

Once the proper measurement points are known, we want to constrain the system such that what it does is simple enough to understand and easy to repeat. It is quite telling that the push for software that enables reproducible builds only really took off after an embarrassing widespread security issue ended up affecting the entire Internet. That there had already been 50 years of software development before anyone thought that introducing a few constraints might be a good idea is, well, let’s just say it generates many emotions, none of them happy, fuzzy ones.

Yes, KV is a seasoned free software author. But I found it heart warming that the Reproducible Builds project is mentioned without needing to introduce it (assuming familiarity across the computing industry and academia), recognized as game-changing as we understood it would be over ten years ago when it was first announced, and enabling of beauty in computing.

Congratulations to all of you who have made this possible!

RB+ACM

11 September, 2025 12:02AM

September 10, 2025

hackergotchi for Daniel Pocock

Daniel Pocock

Culture of silence: Ubisoft harassment convictions, Mozilla, Sylvestre Ledru & Debian make no comment

In an earlier blog, I provided an English translation of the accusations against the Ubisoft executives. This is serious stuff.

In the summer of 2017, people discovered the head of the Albanian group, who was also a Mozilla Tech Speaker, had a 16-year-old girlfriend. He was 24 at the time.

In October 2017, I sent a protected whistleblower complaint to Mozilla.

Here is the internal complaint about the harassment. The date is 12 October 2017 so the misfits publishing alternative statements about harassment are lying. I have redacted the section that identifies underage victims.

The next internal email from Larissa Shapiro at Mozilla admits that kids are at risk.

Emma Irwin from Mozilla admits this is a serious matter and asks me to speak to Marta, Mozilla's HR investigator.

It was around this time that I confided in some of the women that I had a family connection with the choir of Cardinal George Pell and that I was watching these matters very carefully.

Elio Qoshi

 

On 18 January 2018, at the peak of the scandals involving the Albanian female whisteblowers, Sylvestre Ledru, who is employed by Mozilla, sent a private email to Chris Lamb, Nicolas Dandrimont and I telling us that he was resigning as an administrator in Google Summer of Code.

On my side, I would appreciate being removed from this list and delegation. While I love Debian, my responsibilities at Mozilla are growing and I don't have the bandwidth for outreach/gsoc

On 27 August 2018 I sent a public message to the mailing list where I also resigned from future mentoring in the program.

Who wants to be part of the admin team in 2019? Personally, I am going to step back from that role with GSoC and I want to make that clear now so other people can step forward well before registration opens in January.

People have now spent seven years complaining. They never paid us anything for the work we did recruiting and mentoring the interns for Google. They squeal like stuck pigs after we resign.

In December 2018, the late Cardinal Pell was convicted of abuse and the rogue Debianists immediately began spreading rumors about my family and I.

A few weeks later, on 12 February 2019, Sylvestre Ledru used his blog at Mozilla to announce a collaboration between Ubisoft and Mozilla using the Ubisoft Clever-Commit artificial intelligence. An excerpt:

Making the Building of Firefox Faster for You with Clever-Commit from Ubisoft

Firefox fights for people online: for control and choice, for privacy, for safety. ... No other tech company has people’s back like we do.

... Mozilla just partnered with Ubisoft to start using Clever-Commit, an Artificial Intelligence coding assistant developed by Ubisoft La Forge ...

...

... Ultimately, the integration of Clever-Commit into the full Firefox developer workflow could help catch up to 3 to 4 out of 5 bugs ...

...

Mozilla will contribute to the development of Clever-Commit by providing programming language expertise in Rust, C++ and Javascript, as well as expertise in C++ code analysis and analysis of bug tracking systems.

It looks like a very close relationship between the developers at Mozilla and Ubisoft. Sylvestre is one of the Mozilla developers based in Paris, which is also the headquarters of Ubisoft.

Around the same time, Mozilla censored my blog from the Planet Mozilla blog syndication service. Is this because they don't want the Mozilla community to know what women told me in 2017 and 2018?

Mozilla, censorship, mhoye, Mike Hoye, Daniel Pocock

 

Look at the Mozilla Manifesto. It says that Mozilla is against censorship. Why did they censor my blog immediately before the evidence about harassment was published?

2. The internet is a global public resource that must remain open and accessible.

...

8. Transparent community-based processes promote participation, accountability and trust.

The franceinfo report about harssment describes the culture in our industry with quotes from the audit of Ubisoft culture:

"humiliations were commonplace"
"any resistance was immediately broken"

The fellowship had elected me as a representative in 2017 and somebody at Mozilla didn't want me to share evidence about harassment (real harassment).

Ubisoft employees began to speak up about harassment (real harassment) in summer 2020 ( Wikipedia report). French newspaper Libération started an investigation, eventually running a series of reports.

In 2023, Mozilla created and promoted a petition against the French government's browser censorship (SREN) legislation. Five years after censoring the blog of the person elected by the Fellowship, Mozilla declared:

Sign our petition to stop France from forcing browsers like Mozilla's Firefox to censor websites

In the summer of 2025, three senior Ubisoft executives were convicted and punished for harassment (real harassment).

Nobody from Mozilla or Debian has ever made any public Statement on Ubisoft.

Whether we are talking about censorship or talking about harassment, the message is clear: do as we say, not as we do

Why did they attack my family when my father died but they maintain the culture of silence for the Ubisoft scandals?

Here is a photo of Sylvestre Ledru, Paul Tagliamonte and I in the offices of Google during the Google Summer of Code mentor summit 2013.

Sylvestre Ledru, Paul Tagliamonte, Daniel Pocock, Google Summer of Code

 

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

10 September, 2025 07:00PM

Harassment evidence: franceinfo’s Clara Lainé report on Ubisoft prosecution

In the summer of 2025, executives of the French game development company Ubisoft were tried and convicted for harassment in the workplace. It is interesting to contrast the stories from Ubisoft with the stories about the Debian harassment culture. Clara Lainé at public broadcaster franceinfo published an in-depth report about the accusations. A partial English translation is provided here.

Remember, Debian's Sylvestre Ledru, who also works for Mozilla, published blogs promoting collaboration between Ubisoft and the open source software communities. Sylvestre was formerly a Debian administrator for the Google Summer of Code internships.

From the original report in French:

Serge Hascoët, Tommy François, and Guillaume Patrux are on trial for moral and sexual harassment starting Monday. But alongside them, the victims were hoping to see Ubisoft appear in court.

"Stop talking about this immediately. There's no problem at Ubisoft." This is the order a former employee of the French video game giant says he received when he tried, in 2017, to alert his superiors about moral harassment. "At the time of #MeToo, all companies tried, or pretended, to clean up. Not Ubisoft ," he laments in the investigation file consulted by franceinfo. The silence broke in July 2020, with the publication of a vast investigation by Libération. On the 6th floor of a building in Montreuil, home to Ubisoft's prestigious editorial department, the walls could no longer contain the hearty laughter, inappropriate remarks, and serial humiliations.

Five years later, the case reaches the Bobigny Criminal Court . Starting Monday, June 2, three former executives will have to answer for their actions: Serge Hascoët, the group's former number 2; Thomas François (nicknamed Tommy), former vice-president of editorial services; and Guillaume Patrux, former game director. All three deny the facts. For five days, they will be tried for moral and sexual harassment and attempted sexual assault, following accusations brought by six women, three men, and two unions.

The facts they are accused of are part of a system where "humiliations were commonplace" and where "any resistance was immediately broken , " concluded an internal investigation carried out in July 2020. How could such an omerta have taken root and lasted for almost a decade? Why did so many employees end up believing that they could "do nothing" other than "close their eyes or grit their teeth" ?

"We can no longer differentiate whether it's inappropriate or normal."

Behind the window of a creative and relaxed company, dozens of employee testimonies paint a different picture. "The victims' words (...) describe a department [Ubisoft's editorial department] in the hands of a group of immature men, who consider it their personal fiefdom and engage in all kinds of abuse there ," concluded the internal investigation conducted by the Altaïr firm in July 2020.

In this environment, the boundary between professional and personal life dissolves. Clarisse*, who held the position for six years, was unable to file a complaint, as the facts were statute-barred. However, she retains vivid memories of this stifling atmosphere. "I felt like I was always in a bar with constant flirting ," she told investigators. Crossing the open-plan office is a daily ordeal: pointed stares, ambiguous messages, barely veiled invitations...

"I felt like I was walking through a neighborhood alone at night."

Clarisse, former Ubisoft employee facing the investigators

"It was so hard to get up in the morning, I was putting on makeup and crying at the same time ," the young woman confides. "We can no longer differentiate if it's inappropriate or if these things are normal," she says. In this microcosm, everything seems permitted under the guise of humor. Some meetings end with drawings of penises on flipcharts, walls, or post-its, several employees say. Games of "cat-bite" or "olive" are freely played in the corridors, according to the accounts of a dozen witnesses to the case.

Tommy François, one of the three defendants in the case, admitted during a hearing to having evolved in an "institutionalized (...) schoolboy environment" to which one had to adhere "if one did not want to be excluded" . When he arrived at Ubisoft in 2006, he remembers being given the nickname "the TV whore" because he came from the Game One channel or "the fat one" because of his "weight" . As for the "cat-bite", he says he "suffered" it as much as he practiced it, "as a joke" . "It happened between colleagues who knew each other well, always in a humorous tone" , assures the former vice-president of the editorial department.

Misogynistic and racist remarks become commonplace

On the 6th floor of the Montreuil building, the victims of these acts are often the same: women, interns, people of color... Juliette*, hired in 2010 as an intern for Serge Hascoët's assistant, is forced to work at an absurd pace: "Alain* [her manager, for whom the statute of limitations has expired] timed my responses to his emails and sometimes he would say to me: 'you took six minutes to reply to my email, but you're slow.'" She stayed with the company for five years: "I had just come out of a very precarious situation (...), I had to arm myself to hold out."

Nathalie*, who succeeded her in 2015, very quickly became the target of her managers.

"Alain told me that I needed to get a makeover and lose weight."

Nathalie, former Ubisoft employee facing the investigators

She specifies that he forbade her from taking the elevator. Between Juliette and Nathalie, the name of an informal network circulates: "the bracelet community ," a group of employees who know "the truth" about the open space and help each other in hushed tones. These whispers ended up finding an echo in the Bobigny criminal court: the two young women will be on the benches of the civil parties.

The testimonies also report Islamophobic and racist remarks. Nathalie remembers a black colleague nicknamed "Bamboula" and comments about the size of his penis. The young woman , who is Muslim, also recounts that a manager asked her after the Bataclan attacks "if [she] planned to join Daesh ." She adds that her colleagues "amused themselves by changing [her] screen with images of McBacon" or putting sandwiches on her desk during Ramadan. Confronted with these comments, Serge Hascoët told investigators that he had no memory of such scenes.

An all-powerful "king" who "knights"

At the top of the pyramid, power was concentrated in the hands of a handful of "unavoidable and omnipotent" men . "Serge Hascoët had the power of life or death over projects ," summarizes an employee interviewed by the Altaïr firm. The creative director has the complete confidence of CEO Yves Guillemot. "To have the budget to complete the game created, you have to please Serge ," we can read in an internal investigation.

"When the king knights, he delegates his power ," emphasizes a veteran of the editorial department. This power is transmitted from one person to another, by affinity more than by competence, according to him. "There was no HR policy until 2020. Serge placed his knowledge ," notes the author of the internal audit on the department. Alain, his right-hand man for years, testified to this himself during his hearing: "They called me the king's son."

This privileged circle occupies the heart of a system where some can get away with anything. "The editorial department was the star department, and Tommy François was an untouchable personality. We couldn't say anything to him," recalls a former employee. On the HR side, the powerlessness is obvious. "It made him laugh a lot, me not at all," laments a manager, recounting a scene where Serge Hascoët and Tommy François simulate spanking each other while shouting "harassment!" in front of the human resources office. One of her colleagues admits that Ubisoft's number 2 "didn't like to follow the rules" : "I would even say that it amused him (...) to annoy us." During his hearing, Tommy François argued that "during [his] almost 14 years at Ubisoft, HR or [his] managers never notified [him] anything about [his] behavior . "

"Loyalty is a cardinal virtue"

Added to this omnipotence of managers is loyalty to the company and the fear of losing one's job. Ubisoft embodies the elite of global video games. In this "big family ," there is no criticism of the elders, much less those who hold the reins. "Loyalty is a cardinal virtue, even outweighing values," a Ubisoft employee said during an interview with Altaïr.

“My partner told me a while ago: 'Your company is a cult.' That's not wrong!"

A Ubisoft employee as part of Altaïr's internal audit

For many, reporting wrongdoing is not an option. "In the department's environment, it's difficult to speak out without risking reprisals or being ostracized," a former employee confided in 2020. More than 30 witnesses were heard during the investigation, but many of them decided not to file a complaint "for fear of reactions from the video game industry ," investigators point out.

Reputation weighs heavily. "Looking back, I think that at the time, it was a prestigious thing to join Ubisoft and Serge's team... Perhaps someone was willing to put up with certain things instead of speaking out," observed a human resources director during an interview. Because beyond the Montreuil studio, Ubisoft remains a key name in the industry.

Those who tried to resist found themselves alone. Bérénice*, who says she was regularly "humiliated" by Tommy François and "overloaded with work ," suffered a burnout in 2015. The reaction of Alain, one of her superiors, according to her? "Anyway, you have more than that, so we're taking advantage of it, you'll never say anything." Facing investigators, Alain declared that he had "nothing to say" about Bérenice and that he had "always found her very nice . "

She will be on the bench of the civil parties, just like Benoît*, for whom the years spent at Ubisoft as a 3D artist constituted "a downward spiral" which led him "towards anxiety, sleep and eating disorders" . He explained during a hearing: "This complaint is almost an act of desperation... In any case, I have nothing to lose since I will never return to a video game company."

“HR knew everything, saw everything”

At Ubisoft, many people point to the human resources department as a weak link in the system. "HR wasn't the allies of employees, but the protectors of abusers ," accuses a former employee. When Nathalie raises the alarm about a manager's sexist comments, the response is brutal, she says: "The assistant you're replacing lasted three years, it's up to you to adapt." Three human resources directors were indicted and interviewed by investigators, who ultimately dropped the charges. But their findings don't erase the image of a passive, even complicit, department. "I think everyone had pieces of the puzzle, but no overall vision ," admits one manager to investigators. "There was no disciplinary power in 2015 ," acknowledges another.

Bérénice describes a locked-down system and a broken chain of responsibility at every level. "HR knew everything, saw everything, and sometimes even joked with the harassers. Some played the role of stepmother, taking on the role of executioner to protect Serge Hascoët and Tommy François." Even medical appeals seem futile. Bérénice claims that "the occupational physician was 85 years old, she was no longer in her right mind. She asked people to undress and get dressed several times."

“We didn’t know who to turn to.”

Bérénice, former employee and victim facing the investigators

For his part, Yves Guillemot speaks of "a few toxic people" but denies any systemic abuse. This interpretation is contested by unions, civil parties, and defense lawyers. Jean-Guillaume Le Mintier, who represents Serge Hascoët, denounces the trial's scope as too narrow. "If we want to be consistent with the idea that harassment is systemic, everyone must be present in court," he argues.

"All management departments have encouraged this company policy."

Jean-Guillaume Le Mintier, lawyer of Serge Hascoët to franceinfo

"The alert tools still don't work ," laments the lawyer for the Video Game Workers' Union, which has filed a civil suit. She castigates a company "habitually doing this ," where "omerta has become a management method ." And concludes: "This trial should also have been Ubisoft's."

* First names have been changed.

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

10 September, 2025 03:00PM

John Goerzen

ARM is great, ARM is terrible (and so is RISC-V)

I’ve long been interested in new and different platforms. I ran Debian on an Alpha back in the late 1990s and was part of the Alpha port team; then I helped bootstrap Debian on amd64. I’ve got somewhere around 8 Raspberry Pi devices in active use right now, and the free NNCPNET Internet email service I manage runs on an ARM instance at a cloud provider.

ARM-based devices are cheap in a lot of ways: they use little power and there are many single-board computers based on them that are inexpensive. My 8-year-old’s computer is a Raspberry Pi 400, in fact.

So I like ARM.

I’ve been looking for ARM devices that have accelerated AES (Raspberry Pi 4 doesn’t) so I can use full-disk encryption with them. There are a number of options, since ARM devices are starting to go more mid-range. Radxa’s ROCK 5 series of SBCs goes up to 32GB RAM. The Orange Pi 5 Max and Ultra have up to 16GB RAM, as does the Raspberry Pi 5. Pine64’s Quartz64 has up to 8GB of RAM. I believe all of these have the ARM cryptographic extensions. They’re all small and most are economical.

But I also dislike ARM. There is a terrible lack of standardization in the ARM community. They say their devices run Linux, but the default there is that every vendor has their own custom Debian fork, and quite likely kernel fork as well. Most don’t maintain them very well.

Imagine if you were buying x86 hardware. You might have to manage AcerOS, Dellbian, HPian, etc. Most of them have no security support (particularly for the kernel). Some are based on Debian 11 (released in 2021), some Debian 12 (released in 2023), and none on Debian 13 (released a month ago).

That is exactly the situation we have on ARM. While Raspberry Pi 4 and below can run Debian trixie directly, Raspberry Pi has not bothered to upstream support for the Pi 5 yet, and Raspberry Pi OS is only based on Debian bookworm (released in 2023) and very explicitly does not support a key Debian feature: you can’t upgrade from one Raspberry Pi OS release to the next, so it’s a complete reinstall every 2 years instead of just an upgrade. OrangePiOS only supports Debian bookworm — but notably, their kernel is mostly stuck at 5.10 for every image they have (bookworm shipped with 6.1 and bookworm-backports supports 6.12).

Radxa has a page on running Debian on one specific board, they seem to actually not support Debian directly, but rather their fork Radxa OS. There’s a different installer for every board; for instance, this one for the Rock 4D. Looking at it, I can see that it uses files from here and here, with custom kernel, gstreamer, u-boot, and they put zfs in main for some reason.

From Pine64, the Quartz64 seems to be based on an ancient 4.6 or 4.19 kernel. Perhaps, though, one might be able to use Debian’s Pine A64+ instructions on it. Trixie doesn’t have a u-boot image for the Quartz64 but it does have device tree files for it.

RISC-V seems to be even worse; not only do we have this same issue there, but support in trixie is more limited and so is performance among the supported boards.

The alternative is x86-based mini PCs. There are a bunch based on the N100, N150, or Celeron. Many of them support AES-NI and the prices are roughly in line with the higher-end ARM units. There are some interesting items out there; for instance, the Radxa X4 SBC features both an N100 and a RP2040. Fanless mini PCs are available from a number of vendors. Companies like ZimaBoard have interesting options like the ZimaBlade also.

The difference in power is becoming less significant; it seems the newer ARM boards need 20W or 30W power supplies, and that may put them in the range of the mini PCs. As for cost, the newer ARM boards need a heat sink and fan, so by the time you add SBC, fan, storage, etc. you’re starting to get into the price range of the mini PCs.

It is great to see all the options of small SBCs with ARM and RISC-V processors, but at some point you’ve got to throw up your hands and go “this ecosystem has a lot of problems” and consider just going back to x86. I’m not sure if I’m quite there yet, but I’m getting close.

Update 2025-09-11: I found a performant encryption option for the Pi 4, but was stymied by serial console problems; see the update post.

10 September, 2025 01:16PM by John Goerzen

September 09, 2025

hackergotchi for Dirk Eddelbuettel

Dirk Eddelbuettel

RcppSMC 0.2.9 on CRAN: Maintenance

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

This release is again entirely internal. It updates the code for the just-released RcppArmadillo 15.0.2-1, in particular opts into Armadillo 15.0.2. And it makes one small tweak to the continuous integration setup switching to the r-ci action.

The release is summarized below.

Changes in RcppSMC version 0.2.9 (2025-09-09)

  • Adjust to RcppArmadillo 15.0.* by setting ARMA_USE_CURRENT and updating two expressions from deprecated code

  • Rely on r-ci GitHub Action which includes the bootstrap step

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

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

09 September, 2025 08:42PM

Sven Hoexter

debian/watch version 5 is a beauty

Kudos to yadd@ (and who else was involved to make that happen), for the new watch file v5 format. Especially templates for the big git hoster make it much nicer. Prepared two of my packages to switch on the next upload, exfatprogs tracking github releases and pflogsumm scraping a web page. That is much easier to read and less error prone.

09 September, 2025 03:02PM

John Goerzen

btrfs on a Raspberry Pi

I’m something of a filesystem geek, I guess. I first wrote about ZFS on Linux 14 years ago, and even before I used ZFS, I had used ext2/3/4, jfs, reiserfs, xfs, and no doubt some others.

I’ve also used btrfs. I last posted about it in 2014, when I noted it has some advantages over ZFS, but also some drawbacks, including a lot of kernel panics.

Since that comparison, ZFS has gained trim support and btrfs has stabilized. The btrfs status page gives you an accurate idea of what is good to use on btrfs.

Background: Moving towards ZFS and btrfs

I have been trying to move everything away from ext4 and onto either ZFS or btrfs. There are generally several reasons for that:

  1. The checksums for every block help detect potential silent data corruption
  2. Instant snapshots make consistent backups of live systems a lot easier, and without the hassle and wasted space of LVM snapshots
  3. Transparent compression and dedup can save a lot of space in storage-constrained environments

For any machine with at least 32GB of RAM (plus my backup server, which has only 8GB), I run ZFS. While it lacks some of the flexibility of btrfs, it has polish. zfs list -o space shows a useful space accounting. zvols can be behind VMs. With my project simplesnap, I can easily send hourly backups with ZFS, and I choose to send them over NNCP in most cases.

I have a few VMs in the cloud (running Debian, of course) that I use to host things like this blog, my website, my gopher site, the quux NNCP public relay, and various other things.

In these environments, storage space can be expensive. For that matter, so can RAM. ZFS is RAM-hungry, so that rules out ZFS. I’ve been running btrfs in those environments for a few years now, and it’s worked out well. I do async dedup, lzo or zstd compression depending on the needs, and the occasional balance and defrag.

Filesystems on the Raspberry Pi

I run Debian trixie on all my Raspberry Pis; not Raspbian or Raspberry Pi OS for a number of reasons. My 8-yr-old uses a Raspberry Pi 400 as her primary computer — and loves it! She doesn’t do web browsing, but plays Tuxpaint, some old DOS games like Math Blaster via dosbox, and uses Thunderbird for a locked-down email account.

But it was SLOW. Just really, glacially, slow, especially for Thunderbird.

My first step to address that was to get a faster MicroSD card to hold the OS. That was a dramatic improvement. It’s still slow, but a lot faster.

Then, I thought, maybe I could use btrfs with LZO compression to reduce the amount of I/O and speed things up further? Analysis showed things were mostly slow due to I/O, not CPU, constraints.

The conversion

Rather than use the btrfs in-place conversion from ext4, I opted to dar it up (like tar), run mkfs.btrfs on the SD card, then unpack the archive back onto it. Easy enough, right?

Well, not so fast. The MicroSD card is 128GB, and the entire filesystem is 6.2GB. But after unpacking 100MB onto it, I got an out of space error.

btrfs has this notion of block groups. By default, each block group is dedicated to either data or metadata. btrfs fi df and btrfs fi usage will show you details about the block groups.

btrfs allocates block groups greedily (the ssd_spread mount option I use may have exacerbated this). What happened was it allocated almost the entire drive to data block groups, trying to spread the data across it. It so happened that dar archived some larger files first (maybe /boot), so btrfs was allocating data and metadata blockgroups assuming few large files. But then it started unpacking one of the directories in /usr with lots of small files (maybe /usr/share/locale). It quickly filled up the metadata block group, and since the entire SD card had been allocated to different block groups, I got ENOSPC.

Deleting a few files and running btrfs balance resolved it; now it allocated 1GB to metadata, which was plenty. I re-ran the dar extract and now everything was fine. See more details on btrfs balance and block groups.

This was the only btrfs problem I encountered.

Benchmarks

I timed two things prior to switching to btrfs: how long it takes to boot (measured from the moment I turn on the power until the moment the XFCE login box is displayed), and how long it takes to start Thunderbird.

After switching to btrfs with LZO compression, somewhat to my surprise, both measures were exactly the same!

Why might this be?

It turns out that SD cards are understood to be pathologically bad with random read performance. Boot and Thunderbird both are likely doing a lot of small random reads, not large streaming reads. Therefore, it may be that even though I have reduced the total I/O needed, the impact is unsubstantial because the real bottleneck is the “seeks” across the disk.

Still, I gain the better backup support and silent data corruption prevention, so I kept btrfs.

SSD mount options and MicroSD endurance

btrfs has several mount options specifically relevant to SSDs. Aside from the obvious trim support, they are ssd and ssd_spread. The documentation on this is vague and my attempts to learn more about it found a lot of information that was outdated or unsubstantiated folklore.

Some reports suggest that “older” SSDs will benefit from ssd_spread, but that it may have no effect or even a harmful effect on newer ones, and can at times cause fragmentation or write amplification. I could find nothing to back this up, though. And it seems particularly difficult to figure out what kind of wear leveling SSD firmware does. MicroSD firmware is likely to be on the less-advanced side, but still, I have no idea what it might do. In any case, with btrfs not updating blocks in-place, it should be better than ext4 in the most naive case (no wear leveling at all) but may have somewhat more write traffic for the pathological worst case (frequent updates of small portions of large files).

One anecdotal report I read — and can’t find anymore, somehow — was from a person that had set up a sort of torture test for SD cards, with reports that ext4 lasted a few weeks or months before the MicroSDs failed, while btrfs lasted years.

If you are looking for a MicroSD card, by the way, The Great MicroSD Card Survey is a nice place to start.

For longevity: I mount all my filesystems with noatime already, so I continue to recommend that. You can also consider limiting the log size in /etc/systemd/journald.conf, running daily fstrim (which may be more successful than live trims in all filesystems).

Conclusion

I’ve been pretty pleased with btrfs. The concerns I have today relate to block groups and maintenance (periodic balance and maybe a periodic defrag). I’m not sure I’d be ready to say “put btrfs on the computer you send to someone that isn’t Linux-savvy” because the chances of running into issues are higher than with ext4. Still, for people that have some tech savvy, btrfs can improve reliability and performance in other ways.

09 September, 2025 02:01PM by John Goerzen

September 08, 2025

hackergotchi for Dirk Eddelbuettel

Dirk Eddelbuettel

RcppArmadillo 15.0.2-1 on CRAN: New Upstream, Some Changes

armadillo image

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

Fairly shortly after the release of Armadillo 14.6.3 (which became our precedig release 14.6.3), Conrad released version 15.0.0 of Armadillo. It contains several breaking changes which made it unsuitable for CRAN as is. First, the minimum C++ standard was lifted to C++14. There are many good reasons for doing so, but doing it unannounced with no transition offered cannot work at CRAN. For (mostly historical) reasons (as C++11 was once a step up from even more archaic code) many packages still enforce C++11. These packages would break under Armadillo 15.0.0. With some reverse-dependency checks we quickly found that this would affect over 200 packages. Second, Armadillo frequently deprecates code and issues a warning offering a hint towards an improved / current alternative. That too is good practice, and recommended. But at CRAN a deprecation warning seen leads to NOTE and an unfixed NOTEs can lead to archival which is not great. For that reason, we had added a global ‘muffler’ suppressing the deprecation warnings. This was now removed in C++14 (as one can rely on newer compiler attributes we cannot undo, whereas the old scheme just used macros). Again, not something we can do at CRAN.

So I hatched the plan of offering both the final release under the previous state of the world, i.e. 14.6.3, along with 15.0.0. User could then opt-into 15.0.0 but have a fallback of 14.6.3 allowing all packages to coexist. The first idea was to turn the fallback on only if C++11 compilation was noticed. This lead still a lot of deprecation warnings meaning we had to more strongly default to 14.6.3 and only if users actively selected 15.0.* would they get it. This seemed to work. We were still faced with two hard failures. Turns out one was local to a since-archived package, the other reveal a bad interaction betweem Armadillo and gcc for complex variables and lead to bug fix 15.0.1. Which I wrapped and uploaded a week ago.

Release 15.0.1 was quickly seen as only temporary because I overlooked two issues. Moving ‘legacy’ and ‘current’ into, respectively, a directory of that name meant to top-level include header armadillo remained. This broked a few use cases where packages use a direct #include <armadillo> (which we do not recommend as it may miss a few other settings we apply for the R case). The other is that an old test for ‘limited’ LAPACK capabilities made noise in some builds (for example on Windows). As (current) R versions generally have sufficient LAPACK and BLAS, this too has been removed.

We have tested and rested these changed extensively. The usual repository with the logs shows eight reverse-dependency runs each of which can take up to a day. This careful approach, together with pacing uploads at CRAN usually works. We got a NOTE for ‘seven uploads in six months’ for this one, but a CRAN maintainer quickly advanced it, and the fully automated test showed no regression or other human intervention which is nice given the set of changes, and the over 1200 reverse dependencies.

The changes since the last announced CRAN release 14.6.3 follow.

Changes in RcppArmadillo version 15.0.2-1 (2025-09-08)

  • Upgraded to Armadillo release 15.0.2-1 (Medium Roast)

    • Optionally use OpenMP parallelisation for fp16 matrix multiplication

    • Faster vectorisation of cube tubes

  • Provide a top-level include file armadillo as fallback (#480)

  • Retire the no-longer-needed check for insufficient LAPACK as R now should supply a sufficient libRlapack (when used) (#483)

  • Two potential narrowing warnings are avoided via cast

Changes in RcppArmadillo version 15.0.1-1 (2025-09-01)

  • Upgraded to Armadillo release 15.0.1-1 (Medium Roast)

    • Workaround for GCC compiler bug involving misoptimisation of complex number multiplication
  • This version contains both 'legacy' and 'current' version of Armadillo (see also below). Package authors should set a '#define' to select the 'current' version, or select the 'legacy' version (also chosen as default) if they must. See GitHub issue #475 for more details.

  • Updated DESCRIPTION and README.md

Changes in RcppArmadillo version 15.0.0-1 (2025-08-21) (GitHub Only)

  • Upgraded to Armadillo release 15.0.0-1 (Medium Roast)

    • C++14 is now the minimum required C++ standard

    • Aded preliminary support for matrices with half-precision fp16 element type

    • Added second form of cond() to allow detection of failures

    • Added repcube()

    • Added .freeze() and .unfreeze() member functions to wall_clock

    • Extended conv() and conv2() to accept the "valid" shape argument

  • Also includes Armadillo 14.6.3 as fallback for C++11 compilations

  • This new 'dual' setup had been rigorously tested with five interim pre-releases of which several received full reverse-dependency checks

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

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

08 September, 2025 07:03PM

Thorsten Alteholz

My Debian Activities in August 2025

Debian LTS

This was my hundred-thirty-fourth 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 4272-1] aide security update of two CVEs where a local attacker can take advantage of these flaws to hide the addition or removal of a file from the the report, tamper with the log output, or cause aide to crash during report printing or database listing.
  • [DLA 4284-1] udisks2 security update to fix one CVE related to a possible local privilege escalation.
  • [DLA 4285-1] golang-github-gin-contrib-cors security update to fix one CVE related to circumvention of restrictions.
  • [#1112054] trixie-pu of golang-github-gin-contrib-cors, prepared and uploaded
  • [#1112335] trixie-pu of libcoap3, prepared and uploaded
  • [#1112053] bookworm-pu of golang-github-gin-contrib-cors, prepared and uploaded

I also continued my work on suricata and could backport all patches. Now I have to do some tests with the package. I also started to work on an openafs regression and attended the monthly LTS/ELTS meeting.

Debian ELTS

This month was the eighty-fifth ELTS month. During my allocated time I uploaded or worked on:

  • [ELA-1499-1] aide security update to fix one embargoed CVE in Stretch, related to a crash. The other CVE mentioned above was not affecting Stretch.
  • [ELA-1508-1] udisks2 security update to fix one embargoed CVE in Stretch and Buster.

I could also mark the CVEs of libcoap as not-affected. I also attended the monthly LTS/ELTS meeting.Of course like for LTS, As suricata had been requested for Stretch as well now, I didn’t not finish my work here.

Debian Printing

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

This work is generously funded by Freexian!

Debian Astro

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

Debian IoT

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

Debian Mobcom

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

misc

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

On my fight against outdated RFPs, I closed 31 of them in August.

FTP master

Yeah, Trixie has been released, the tired bones need to be awaken again :-). This month I accepted 203 and rejected 18 packages. The overall number of packages that got accepted was 243.

08 September, 2025 03:35PM by alteholz

September 07, 2025

Antoine Beaupré

Encrypting a Debian install with UKI

I originally setup a machine without any full disk encryption, then somehow regretted it quickly after. My original reasoning was that this was a "play" machine so I wanted as few restrictions on accessing the machine as possible, which meant removing passwords, mostly.

I actually ended up having a user password, but disabled the lock screen. Then I started using the device to manage my photo collection, and suddenly there was a lot of "confidential" information on the device that I didn't want to store in clear text anymore.

Pre-requisites

So, how does one convert an existing install from plain text to full disk encryption? One way is to backup to an external drive, re-partition everything and copy things back, but that's slow and boring. Besides, cryptsetup has a cryptsetup-reencrypt command, surely we can do this in place?

Having not set aside enough room for /boot, I briefly considered a "encrypted /boot" configuration and conversion (e.g. with this guide) but remembered grub's support for this is flaky, at best, so I figured I would try something else.

Here, I'm going to guide you through how I first converted from grub to systemd-boot then to UKI kernel, then re-encrypt my main partition.

Note that secureboot is disabled here, see further discussion below.

systemd-boot and Unified Kernel Image conversion

systemd folks have been developing UKI ("unified kernel image") to ship kernels. The way this works is the kernel and initrd (and UEFI boot stub) in a single portable executable that lives in the EFI partition, as opposed to /boot. This neatly solves my problem, because I already have such a clear-text partition and won't need to re-partition my disk to convert.

Debian has started some preliminary support for this. It's not default, but I found this guide from Vasudeva Kamath which was pretty complete. Since the guide assumes some previous configuration, I had to adapt it to my case.

Here's how I did the conversion to both systemd-boot and UKI, all at once. I could have perhaps done it one at a time, but doing both at once works fine.

Before your start, make sure secureboot is disabled, see the discussion below.

  1. install systemd tools:

    apt install systemd-ukify systemd-boot
    
  2. Configure systemd-ukify, in /etc/kernel/install.conf:

    layout=uki
    initrd_generator=dracut
    uki_generator=ukify
    

    TODO: it doesn't look like this generates a initrd with dracut, do we care?

  3. Configure the kernel boot arguments with the following in /etc/kernel/uki.conf:

    [UKI]
    Cmdline=@/etc/kernel/cmdline
    

    The /etc/kernel/cmdline file doesn't actually exist here, and that's fine. Defaults are okay, as the image gets generated from your current /proc/cmdline. Check your /etc/default/grub and /proc/cmdline if you are unsure. You'll see the generated arguments in bootctl list below.

  4. Build the image:

    dpkg-reconfigure linux-image-$(uname -r)
    
  5. Check the boot options:

    bootctl list
    

    Look for a Type #2 (.efi) entry for the kernel.

  6. Reboot:

    reboot
    

You can tell you have booted with systemd-boot because (a) you won't see grub and (b) the /proc/cmdline will reflect the configuration listed in bootctl list. In my case, a systemd.machine_id variable is set there, and not in grub (compare with /boot/grub/grub.cfg).

By default, the systemd-boot loader just boots, without a menu. You can force the menu to show up by un-commenting the timeout line in /boot/efit/loader/loader.conf, by hitting keys during boot (e.g. hitting "space" repeatedly), or by calling:

systemctl reboot --boot-loader-menu=0

See the systemd-boot(7) manual for details on that.

I did not go through the secureboot process, presumably I had already disabled secureboot. This is trickier: because one needs a "special key" to sign the UKI image, one would need the collaboration of debian.org to get this working out of the box with the keys shipped onboard most computers.

In other words, if you want to make this work with secureboot enabled on your computer, you'll need to figure out how to sign the generated images before rebooting here, because otherwise you will break your computer. Otherwise, follow the following guides:

Re-encrypting root filesystem

Now that we have a way to boot an encrypted filesystem, we can switch to LUKS for our filesystem. Note that you can probably follow this guide if, somehow, you managed to make grub work with your LUKS setup, although as this guide shows, you'd need to downgrade the cryptographic algorithms, which seems like a bad tradeoff.

We're using cryptsetup-reencrypt for this which, amazingly, supports re-encrypting devices on the fly. The trick is it needs free space at the end of the partition for the LUKS header (which, I guess, makes it a footer), so we need to resize the filesystem to leave room for that, which is the trickiest bit.

This is a possibly destructive behavior. Be sure your backups are up to date, or be ready to lose all data on the device.

We assume 512 byte sectors here. Check your sector size with fdisk -l and adjust accordingly.

  1. Before you perform the procedure, make sure requirements are installed:

    apt install cryptsetup systemd-cryptsetup cryptsetup-initramfs
    

    Note that this requires network access, of course.

  2. Reboot in a live image, I like GRML but any Debian live image will work, possibly including the installer

  3. First, calculate how many sectors to free up for the LUKS header

    qalc> 32Mibyte / ( 512 byte )
    
      (32 mebibytes) / (512 bytes) = 65536
    
  4. Find the sector sizes of the Linux partitions:

    fdisk  -l /dev/nvme0n1 | awk '/filesystem/ { print $1 " " $4 }' |
    

    For example, here's an example with a /boot and / filesystem:

    $ sudo fdisk -l /dev/nvme0n1 | awk '/filesystem/ { print $1 " " $4 }'
    /dev/nvme0n1p2 999424
    /dev/nvme0n1p3 3904979087
    
  5. Substract 1 from 2:

    qalc> set precision 100
    qalc> 3904979087 - 65536
    

    Or, last step and this one, in one line:

    fdisk -l /dev/nvme0n1 | awk '/filesystem/ { print $1 " " $4 - 65536 }'
    
  6. Recheck filesystem:

    e2fsck -f /dev/nvme0n1p2
    
  7. Resize filesystem:

    resize2fs /dev/nvme0n1p2 $(fdisk -l /dev/nvme0n1 | awk '/nvme0n1p2/ { print $4 - 65536 }')s
    

    Notice the trailing s here: it makes resize2fs interpret the number as a 512 byte sector size, as opposed to the default (4k blocks).

  8. Re-encrypt filesystem:

    cryptsetup reencrypt --encrypt /dev/nvme0n1p2 --resize-device-size=32M
    

    This is it! This is the most important step! Make sure your laptop is plugged in and try not to interrupt it. This can, apparently, be resumed without problem, but I'd hate to show you how.

    This will show progress information like:

    Progress:   2.4% ETA 23m45s,      53GiB written, speed   1.3 GiB/s
    

    Wait until the ETA has passed.

  9. Open and mount the encrypted filesystem and mount the EFI system partition (ESP):

    cryptsetup open /dev/nvme0n1p2 crypt
    mount /dev/mapper/crypt /mnt
    mount /dev/nvme0n1p1 /mnt/boot/efi
    

    If this fails, now is the time to consider restoring from backups.

  10. Enter the chroot

    for fs in proc sys dev ; do
      mount --bind /$fs /mnt/$fs
    done
    chroot /mnt
    

    Pro tip: this can be done in one step in GRML with:

    grml-chroot /mnt bash
    
  11. Generate a crypttab:

    echo crypt_dev_nvme0n1p2 UUID=$(blkid -o value -s UUID /dev/nvme0n1p2) none luks,discard >> /etc/crypttab
    
  12. Adjust root filesystem in /etc/fstab, make sure you have a line like this:

    /dev/mapper/crypt_dev-nvme0n1p2 /               ext4    errors=remount-ro 0       1
    

    If you were already using a UUID entry for this, there's nothing to change!

  13. Configure the root filesystem in the initrd:

    echo root=/dev/mapper/crypt_dev_nvme0n1p2 > /etc/kernel/cmdline
    
  14. Regenerate UKI:

    dpkg-reconfigure linux-image-$(uname -r)
    

    Be careful here! systemd-boot inherits the command line from the system where it is generated, so this will possibly feature some unsupported commands from your boot environment. In my case GRML had a couple of those, which broke the boot. It's still possible to workaround this issue by tweaking the arguments at boot time, that said.

  15. Exit chroot and reboot

    exit
    reboot
    

Some of the ideas in this section were taken from this guide but was mostly rewritten to simplify the work. My guide also avoids the grub hacks or a specific initrd system (as the guide uses initramfs-tools and grub, while I, above, switched to dracut and systemd-boot). RHEL also has a similar guide, perhaps even better.

Somehow I have made this system without LVM at all, which simplifies things a bit (as I don't need to also resize the physical volume/volume groups), but if you have LVM, you need to tweak this to also resize the LVM bits. The RHEL guide has some information about this.

07 September, 2025 02:39AM

September 06, 2025

John Goerzen

Dreams of Late Summer

Here on a summer night in the grass and lilac smell
Drunk on the crickets and the starry sky,
Oh what fine stories we could tell
With this moonlight to tell them by.

A summer night, and you, and paradise,
So lovely and so filled with grace,
Above your head, the universe has hung its lights,
And I reach out my hand and touch your face.

I sit outside today, at the picnic table on our side porch. I was called out here; in late summer, the cicadas and insects of the plains are so loud that I can hear them from inside our old farmhouse.

I sit and hear the call and response of buzzing cicadas, the chirp of crickets during their intermission. The wind rustles off and on through the treetops. And now our old cat has heard me, and she comes over, spreading tan cat hair across my screen. But I don’t mind; I hear her purr as she comes over to relax nearby.

Aside from the gentle clack of my keyboard as I type, I hear no sounds of humans. Occasionally I hear the distant drone of a small piston airplane, and sometimes the faint horn of a train, 6 miles away.

As I look up, I see grass, the harvested wheat field, the trees, and our gravel driveway. Our road is on the other side of a hill. I see no evidence of it from here, but I know it’s there. Maybe 2 or 3 vehicles will pass on a day like today; if they’re tall delivery trucks, I’ll see their roof glide silently down the road, and know the road is there. The nearest paved road is several miles away, so not much comes out here.

I reflect of those times years ago, when this was grandpa’s house, and the family would gather on Easter. Grandpa hid not just Easter eggs, but Easter bags all over the yard. This yard. Here’s the tree that had a nice V-shaped spot to hide things in; there’s the other hiding spot.

I reflect on the wildlife. This afternoon, it’s the insects that I hear. On a foggy, cool, damp morning, the birds will be singing from all the trees, the fog enveloping me with unseen musical joy. On a quiet evening, the crickets chirp and the coyotes howl in the distance.

Now the old cat has found my lap. She sits there purring, tail swishing. 12 years ago when she was a kitten, our daughter hadn’t yet been born. She is old and limps, and is blind in one eye, but beloved by all. Perfectly content with life, she stretches and relaxes.

I have visited many wonderful cities in this world. I’ve seen Aida at the Metropolitan Opera, taken trains all over Europe, wandered the streets of San Francisco and Brussels and Lindos, visited the Christmas markets in the lightly-snowy evenings in Regensburg, felt the rumble of the Underground beneath me in London. But rarely do the city people come here.

Oh, some of them think they’ve visited the country. But no, my friends, no; if you don’t venture beyond the blacktop roads, you’ve not experienced it yet. You’ve not gone to a restaurant “in town”, recognized by several old friends. You’ve not stopped by the mechanic — the third generation of that family fixing cars that belong to yours — who more often than not tells you that you don’t need to fix that something just yet. You’ve not sat outside, in this land where regular people each live in their own quiet Central Park. You’ve not seen the sunset, with is majestic reds and oranges and purples and blues and grays, stretching across the giant iMax dome of the troposphere, suspended above the hills and trees to the west. You’ve not visited the grocery store, with your car unlocked and keys in the ignition, unconcerned about vehicle theft. You’ve not struggled with words when someone asks “what city are you from” and you lack the vocabulary to help them understand what it means when you say “none”.

Out there in the land of paved roads and bright lights, the problems of the world churn. The problems near and far: a physical and mental health challenges with people we know, global problems with politics and climate.

But here, this lazy summer afternoon, I forget about the land of the paved roads and bright lights. As it should be; they’ve forgotten the land of the buzzing cicadas and muddy roads.

I believe in impulse, in all that is green,
In the foolish vision that comes out true.
I believe that all that is essential is unseen,
And for this lifetime, I believe in you.

All of the lovers and the love they made:
Nothing that was between them was a mistake.
All that we did for love’s sake,
Was not wasted and will never fade.

All who have loved will be forever young
And walk in grandeur on a summer night
Along the avenue.

They live in every song that is sung,
In every painting of pure light,
In every pas de deux.

O love that shines from every star,
Love reflected in the silver moon;
It is not here, but it is not far.
Not yet, but it will be here soon.

No two days are alike. But this day comes whenever I pause to let it.

May you find the buzzing cicadas and muddy roads near you, wherever you may be.

Poetry from “A Summer Night” by Garrison Keillor

06 September, 2025 10:07PM by John Goerzen

Reproducible Builds

Reproducible Builds in August 2025

Welcome to the August 2025 report from the Reproducible Builds project!

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

In this report:

  1. Reproducible Builds Summit 2025
  2. Reproducible Builds and live-bootstrap at WHY2025
  3. DALEQ Explainable Equivalence for Java Bytecode
  4. Reproducibility regression identifies issue with AppArmor security policies
  5. Rust toolchain fixes
  6. Distribution work
  7. diffoscope
  8. Website updates
  9. Reproducibility testing framework
  10. Upstream patches

Reproducible Builds Summit 2025

Please join us at the upcoming Reproducible Builds Summit, set to take place from October 28th — 30th 2025 in Vienna, Austria!**

We are thrilled to host the eighth edition of this exciting event, following the success of previous summits in various iconic locations around the world, including Venice, Marrakesh, Paris, Berlin, Hamburg and Athens. Our summits are a unique gathering that brings together attendees from diverse projects, united by a shared vision of advancing the Reproducible Builds effort.

During this enriching event, participants will have the opportunity to engage in discussions, establish connections and exchange ideas to drive progress in this vital field. Our aim is to create an inclusive space that fosters collaboration, innovation and problem-solving.

If you’re interesting in joining us this year, please make sure to read the event page which has more details about the event and location. Registration is open until 20th September 2025, and we are very much looking forward to seeing many readers of these reports there!


Reproducible Builds and live-bootstrap at WHY2025

WHY2025 (What Hackers Yearn) is a nonprofit outdoors hacker camp that takes place in Geestmerambacht in the Netherlands (approximately 40km north of Amsterdam). The event is “organised for and by volunteers from the worldwide hacker community, and knowledge sharing, technological advancement, experimentation, connecting with your hacker peers, forging friendships and hacking are at the core of this event”.

At this year’s event, Frans Faase gave a talk on live-bootstrap, an attempt to “provide a reproducible, automatic, complete end-to-end bootstrap from a minimal number of binary seeds to a supported fully functioning operating system”.

Frans’ talk is available to watch on video and his slides are available as well.


DALEQ Explainable Equivalence for Java Bytecode

Jens Dietrich of the Victoria University of Wellington, New Zealand and Behnaz Hassanshahi of Oracle Labs, Australia published an article this month entitled DALEQ — Explainable Equivalence for Java Bytecode which explores the options and difficulties when Java binaries are not identical despite being from the same sources, and what avenues are available for proving equivalence despite the lack of bitwise correlation:

[Java] binaries are often not bitwise identical; however, in most cases, the differences can be attributed to variations in the build environment, and the binaries can still be considered equivalent. Establishing such equivalence, however, is a labor-intensive and error-prone process.

Jens and Behnaz therefore propose a tool called DALEQ, which:

disassembles Java byte code into a relational database, and can normalise this database by applying Datalog rules. Those databases can then be used to infer equivalence between two classes. Notably, equivalence statements are accompanied with Datalog proofs recording the normalisation process. We demonstrate the impact of DALEQ in an industrial context through a large-scale evaluation involving 2,714 pairs of jars, comprising 265,690 class pairs. In this evaluation, DALEQ is compared to two existing bytecode transformation tools. Our findings reveal a significant reduction in the manual effort required to assess non-bitwise equivalent artifacts, which would otherwise demand intensive human inspection. Furthermore, the results show that DALEQ outperforms existing tools by identifying more artifacts rebuilt from the same code as equivalent, even when no behavioral differences are present.

Jens also posted this news to our mailing list.


Reproducibility regression identifies issue with AppArmor security policies

Tails developer intrigeri has tracked and followed a reproducibility regression in the generation of AppArmor policy caches, and has identified an issue with the 4.1.0 version of AppArmor.

Although initially tracked on the Tails issue tracker, intrigeri filed an issue on the upstream bug tracker. AppArmor developer John Johansen replied, confirming that they can reproduce the issue and went to work on a draft patch. Through this, John revealed that it was caused by an actual underlying security bug in AppArmor — that is to say, it resulted in permissions not (always) matching what the policy intends and, crucially, not merely a cache reproducibility issue.

Work on the fix is ongoing at time of writing.


Rust toolchain fixes

Rust Clippy is a linting tool for the Rust programming language. It provides a collection of lints (rules) designed to identify common mistakes, stylistic issues, potential performance problems and unidiomatic code patterns in Rust projects. This month, however, Sosthène Guédon filed a new issue in the GitHub requesting a new check that “would lint against non deterministic operations in proc-macros, such as iterating over a HashMap”.


Distribution work

In Debian this month:

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


diffoscope

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, 303, 304 and 305 to Debian:

  • Improvements:

    • Use sed(1) backreferences when generating debian/tests/control to avoid duplicating ourselves. []
    • Move from a mono-utils dependency to versioned mono-devel | mono-utils dependency, taking care to maintain the [!riscv64] architecture restriction. []
    • Use sed over awk to avoid mangling dependency lines containing = (equals) symbols such as version restrictions. []
  • Bug fixes:

    • Fix a test after the upload of systemd-ukify version 258~rc3. []
    • Ensure that Java class files are named .class on the filesystem before passing them to javap(1). []
    • Do not run jsondiff on files over 100KiB as the algorithm runs in O(n^2) time. []
    • Don’t check for PyPDF version 3 specifically; check for >= 3. []
  • Misc:

    • Update copyright years. [][]

In addition, Martin Joerg fixed an issue with the HTML presenter to avoid crash when page limit is None [] and Zbigniew Jędrzejewski-Szmek fixed compatibility with RPM 6 []. Lastly, John Sirois fixed a missing requests dependency in the trydiffoscope tool. []


Website updates

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


Reproducibility testing framework

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

  • reproduce.debian.net-related:

    • Run 4 workers on the o4 node again in order to speed up testing. [][][][]
    • Also test trixie-proposed-updates and trixie-updates etc. [][]
    • Gather seperate statistics for each tested release. []
    • Support sources from all Debian suites. []
    • Run new code from the prototype database rework branch for the amd64-pull184 pseudo-architecture. [][]
    • Add a number of helpful links. [][][][][][][][][]
    • Temporarily call debrebuild without the --cache argument to experiment with a new version of devscripts. [][][]
    • Update public TODO. []
  • Installation tests:

    • Add comments to explain structure. []
    • Mark more old jobs as old or “dead”. [][][]
    • Turn the maintenance job into a no-op. []
  • Jenkins node maintenance:

    • Increase penalties if the osuosl5 or ionos7 nodes are down. []
    • Stop trying to fix network automatically. []
    • Correctly mark ppc64el architecture nodes when down. []
    • Upgrade the remaining arm64 nodes to Debian trixie in anticipation of the release. [][]
    • Allow higher SSD temperatures on the riscv64 architecture. []
  • Debian-related:

    • Drop the armhf architecture; many thanks to Vagrant for physically hosting the nodes for ten years. [][]
    • Add Debian forky, and archive bullseye. [][][][][][][]
    • Document the filesystem space savings from dropping the armhf architecture. []
    • Exclude i386 and armhfr from JSON results. []
    • Update TODOs for when Debian trixie and forky have been released. [][]
  • tests.reproducible-builds.org-related:

  • Misc:

    • Detect errors with openQA erroring out. []
    • Drop the long-disabled openwrt_rebuilder jobs. []
    • Use qa-jenkins-dev@alioth-lists.debian.net as the contact for jenkins.debian.net. []
    • Redirect reproducible-builds.org/vienna25 to reproducible-builds.org/vienna2025. []

    • Disable all OpenWrt reproducible CI jobs, in coordination with the OpenWrt community. [][]
    • Make reproduce.debian.net accessable via IPv6. []
    • Ignore that the megacli RAID controller requires packages from Debian bookworm. []

In addition,

  • James Addison migrated away from deprecated toplevel deb822 Python module in favour of debian.deb822 in the bin/reproducible_scheduler.py script [] and removed a note on reproduce.debian.net note after the release of Debian trixie [].

  • Jochen Sprickerhof made a huge number of improvements to the reproduce.debian.net statistics calculation [][][][][][] as well as to the reproduce.debian.net service more generally [][][][][][][][].

  • Mattia Rizzolo performed a lot of work migrating scripts to SQLAlchemy version 2.0 [][][][][][] in addition to making some changes to the way openSUSE reproducibility tests are handled internally. []

  • Lastly, Roland Clobus updated the Debian Live packages after the release of Debian trixie. [][]


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:



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:

06 September, 2025 09:58PM

September 04, 2025

Noah Meyerhans

False Positives

There are times when an email based workflow gets really difficult. One of those times is when discussing projects related to spam and malware detection.

 noahm@debian.org
host stravinsky.debian.org [2001:41b8:202:deb::311:108]
SMTP error from remote mail server after end of data:
550-malware detected: Sanesecurity.Phishing.Fake.30934.1.UNOFFICIAL:
550 message rejected
submit@bugs.debian.org
host stravinsky.debian.org [2001:41b8:202:deb::311:108]
SMTP error from remote mail server after end of data:
550-malware detected: Sanesecurity.Phishing.Fake.30934.1.UNOFFICIAL:
550 message rejected

This was, in fact, a false positive. And now, because reportbug doesn’t record outgoing messages locally, I need to retype the whole thing.

(NB. this is not a complaint about the policies deployed on the Debian mail servers; they’d be negligent if they didn’t implement such policies on today’s internet.)

04 September, 2025 02:53PM by Noah Meyerhans (frodo+blog@morgul.net)

September 03, 2025

hackergotchi for Joachim Breitner

Joachim Breitner

F91 in Lean

Back in March, with version 4.17.0, Lean introduced partial_fixpoint, a new way to define recursive functions. I had drafted a blog post for the official Lean FRO blog back then, but forgot about it, and with the Lean FRO blog discontinued, I’ll just publish it here, better late than never.

With the partial_fixpoint mechanism we can model possibly partial functions (so those returning an Option) without an explicit termination proof, and still prove facts about them. See the corresponding section in the reference manual for more details.

On the Lean Zulip, I was asked if we can use this feature to define the McCarthy 91 function and prove it to be total. This function is a well-known tricky case for termination proofs.

First let us have a brief look at why this function is tricky to define in a system like Lean. A naive definition like

def f91 (n : Nat) : Nat :=
  if n > 100
  then n - 10
  else f91 (f91 (n + 11))

does not work; Lean is not able to prove termination of this functions by itself.

Even using well-founded recursion with an explicit measure (e.g. termination_by 101 - n) is doomed, because we would have to prove facts about the function’s behaviour (namely that f91n = f91101 = 91 for 90 ≤ n ≤ 100) and at the same time use that fact in the termination proof that we have to provide while defining the function. (The Wikipedia page spells out the proof.)

We can make well-founded recursion work if we change the signature and use a subtype on the result to prove the necessary properties while we are defining the function. Lean by Example shows how to do it, but for larger examples this approach can be hard or tedious.

With partial_fixpoint, we can define the function as a partial function without worrying about termination. This requires a change to the function’s signature, returning an Option Nat:

def f91 (n : Nat) : Option Nat :=
  if n > 100
    then pure (n - 10)
    else f91 (n + 11) >>= f91
partial_fixpoint

From the point of view of the logic, Option.none is then used for those inputs for which the function does not terminate.

This function definition is accepted and the function runs fine as compiled code:

#eval f91 42

prints some 91.

The crucial question is now: Can we prove anything about f91 In particular, can we prove that this function is actually total?

Since we now have the f91 function defined, we can start proving auxillary theorems, using whatever induction schemes we need. In particular we can prove that f91 is total and always returns 91 for n ≤ 100:

theorem f91_spec_high (n : Nat) (h : 100 < n) : f91 n = some (n - 10) := by
  unfold f91; simp [*]

theorem f91_spec_low (n : Nat) (h₂ : n ≤ 100) : f91 n = some 91 := by
  unfold f91
  rw [if_neg (by omega)]
  by_cases n < 90
  · rw [f91_spec_low (n + 11) (by omega)]
    simp only [Option.bind_eq_bind, Option.some_bind]
    rw [f91_spec_low 91 (by omega)]
  · rw [f91_spec_high (n + 11) (by omega)]
    simp only [Nat.reduceSubDiff, Option.some_bind]
    by_cases h : n = 100
    · simp [f91, *]
    · exact f91_spec_low (n + 1) (by omega)

theorem f91_spec (n : Nat) : f91 n = some (if n ≤ 100 then 91 else n - 10) := by
  by_cases h100 : n ≤ 100
  · simp [f91_spec_low, *]
  · simp [f91_spec_high, Nat.lt_of_not_le ‹_›, *]

-- Generic totality theorem
theorem f91_total (n : Nat) : (f91 n).isSome := by simp [f91_spec]

(Note that theorem f91_spec_low is itself recursive in a somewhat non-trivial way, but Lean can figure that out all by itself. Use termination_by? if you are curious.)

This is already a solid start! But what if we want a function of type f91! (n : Nat) : Nat, without the Option? Then can derive that from the partial variant, as we have just proved that to be actually total:

def f91! (n : Nat) : Nat  := (f91 n).get (f91_total n)

theorem f91!_spec (n : Nat) : f91! n = if n ≤ 100 then 91 else n - 10 := by
  simp [f91!, f91_spec]

Using partial_fixpoint one can decouple the definition of a function from a termination proof, or even model functions that are not terminating on all inputs. This can be very useful in particular when using Lean for program verification, such as with the aeneas package, where such partial definitions are used to model Rust programs.

03 September, 2025 08:18PM by Joachim Breitner (mail@joachim-breitner.de)

Enrico Zini

CAdES signatures on Debian

CAdES is a digital signature standard that is used and sometimes mandated, by the Italian Public Administration.

To be able to do my job, I own a Carta Nazionale dei Servizi (CNS) with which I can generate legally binding signatures. Now comes the problem of finding a software to do it.

Infocamere Firma4NG

InfoCamere are distributing a software called Firma4NG, with a Linux option, which, I'm pleased to say, seems to work just fine.

Autofirma

AutoFirma is a Java software for digital signatures distributed by the Spanish government, which has a Linux version.

It is licensed as GPL-2+ | EUPL-1.1, and the source seems to be here.

While my Spanish is decent I lack jargon for this specific field, and I didn't manage to make it work with my CNS.

Autogram

Andrej Shadura pointed me to Autogram, a Slovakian software for digital signatures, licensed under the EUPL-1.2.

The interface is still only in Slovakian, so tried it but I didn't go very far in trying to make it work.

OpenSSL

In trixie, openssl is almost, but not quite, able to do it. Here's as far as I've got.

Install opensc

apt install opensc

Test if you can access the smart card with:

pkcs11-tool --list-objects [-l]

You can find other pkcs11-tool examples here

Set up a pkcs11 provider for openssl

apt install pkcs11-provider

Edit /etc/ssl/openssl.cnf:

  • In [provider_sect] add pkcs11 = pkcs11_sect
  • In [default_sect], uncomment activate = 1
  • Add this new section:
[pkcs11_sect]
module = /usr/lib/x86_64-linux-gnu/ossl-modules/pkcs11.so
pkcs11-module-path = /usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so
default_algorithms = ALL
activate = 1

Test with openssl list -providers

You can check if openssl can see keys on the card:

openssl pkey -in 'pkcs11:id=%01' -pubin -pubout -text

See PKCS11 URI documentation here.

Install the PKCS11 engine for openssl

apt install libengine-pkcs11-openssl

It looks like providers replaced engines, and this would not be needed, but I couldn't find a way to convince openssl to work without this.

Sign a document

openssl cms -nodetach -binary -cades -outform DER -in filename -out filename.p7m -sign -signer 'pkcs11:id=%01' -keyform engine -engine pkcs11

It verifies correctly using the Austrian verification system.

All the Italian verification systems I tried, however, complain that, although the signature is valid, the certificate is emitted by an unqualified CA and the certificate revocation information cannot be found.

PAdES

When signing PDF files, the PAdES standard is sometimes accepted.

LibreOffice is able to generate PAdES signatures using the "File / Digital signatures…" menu, and provided the smart card is in the reader it is able to use it. Both LibreOffice and Okular can verify that the signature is indeed there.

However, when trying to validate the signature using Italian validators, I get the same complaints about unqualified CAs and missing revocation information.

Wall of shame

Dike GoSign

Infocert (now Tinexta) used to distribute a software called "Dike GoSign" that worked on Ubuntu, which I used on a completely isolated VM, and it was awful but it worked.

I had to regenerate the VM for it, and discovered that the version they distribute now will refuse to work unless one signs in online with a Tinexta account. From the same company that asks you to install their own root certifiactes to use their digital signature system.

Gross.

Dropped.

Aruba Sign

Aruba used to distribute a software called Aruba Sign, which also worked on Ubuntu.

Ubuntu support has been discontinued, and they now only offer support for Windows or Mac.

Yuck. Dropped.

03 September, 2025 03:38PM

hackergotchi for Colin Watson

Colin Watson

Free software activity in August 2025

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

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

Python team

forky is open! As a result I’m starting to think about the upcoming Python 3.14. At some point we’ll doubtless do a full test rebuild, but in advance of that I concluded that one of the most useful things I could do would be to work on our very long list of packages with new upstream versions. Of course there’s no real chance of this ever becoming empty since upstream maintainers aren’t going to stop work for that long, but there are a lot of packages there where we’re quite a long way out of date, and many of those include fixes that we’ll need for 3.14, either directly or by fixing interactions with new versions of other packages that in turn will need to be fixed. We can backport changes when we need to, but more often than not the most efficient way to do things is just to keep up to date.

So, I upgraded these packages to new upstream versions (deep breath):

  • aioftp
  • aiosignal (building on work by IanLucca)
  • audioop-lts
  • celery
  • djangorestframework
  • djoser
  • fpylll
  • frozenlist
  • git-repo-updater
  • ipykernel
  • klepto
  • kombu
  • multipart
  • netmiko (sponsoring work by Eduardo Silva; contributed supporting fix upstream)
  • pathos
  • ppft
  • pydantic
  • pydantic-core
  • pydantic-settings
  • pylsqpack
  • pymssql
  • pytest-mock
  • pytest-pretty
  • pytest-repeat
  • pytest-rerunfailures
  • python-a2wsgi
  • python-apptools (sponsoring work by Kathlyn Lara Murussi)
  • python-asgiref
  • python-asyncssh
  • python-bitarray
  • python-bitstring
  • python-bytecode
  • python-channels-redis
  • python-charset-normalizer
  • python-daphne
  • python-django-analytical
  • python-django-guid
  • python-django-health-check
  • python-django-pgbulk
  • python-django-pgtrigger
  • python-django-postgres-extra
  • python-django-storages
  • python-holidays
  • python-httpx-sse
  • python-icalendar
  • python-lazy-model
  • python-line-profiler
  • python-lz4
  • python-marshmallow-dataclass
  • python-mastodon
  • python-model-bakery
  • python-oauthlib
  • python-parse-type
  • python-pathvalidate
  • python-pgspecial
  • python-processview
  • python-pytest-subtests
  • python-roman
  • python-semantic-release
  • python-testfixtures
  • python-time-machine
  • python-tokenize-rt
  • python-typeguard
  • python-typing-extensions
  • python-urllib3
  • pyupgrade
  • requests (fixing CVE-2024-47081)
  • responses
  • zope.deferredimport
  • zope.schema
  • zope.testrunner

That’s only about 10% of the backlog, but of course others are working on this too. If we can keep this up for a while then it should help.

I packaged pytest-run-parallel, pytest-unmagic (still in NEW), and python-forbiddenfruit (still in NEW), all needed as new dependencies of various other packages.

setuptools upstream will be removing the setup.py install command on 31 October. While this may not trickle down immediately into Debian, it does mean that in the near future nearly all Python packages will have to use pybuild-plugin-pyproject (note that this does not mean that they necessarily have to use pyproject.toml; this is just a question of how the packaging runs the build system). We talked about this a bit at DebConf, and I said that I’d noticed a number of packages where this isn’t straightforward and promised to write up some notes. I wrote the Python/PybuildPluginPyproject wiki page for this; I expect to add more bits and pieces to it as I find them.

On that note, I converted several packages to pybuild-plugin-pyproject:

  • billiard
  • lazr.config
  • python-timeline
  • zope.sqlalchemy
  • zope.testing

I fixed several build/test failures:

I fixed some other bugs:

I reviewed Debian defaults: nftables as banaction and systemd as backend, but it looked as though nothing actually needed to be changed so we closed this with no action.

Rust team

Upgrading Pydantic was complicated, and required a rust-pyo3 transition (which Jelmer Vernooij started and Peter Michael Green has mostly been driving, thankfully), packaging rust-malloc-size-of (including an upstream portability fix), and upgrading several packages to new upstream versions:

  • rust-serde
  • rust-serde-derive
  • rust-serde-json
  • rust-smallvec
  • rust-speedate
  • rust-time
  • rust-time-core
  • rust-time-macros

bugs.debian.org

I fixed bugs.debian.org: misspelled checkbox id “uselessmesages”, as well as a bug that caused incoming emails with certain header contents to go missing.

OpenSSH

I fixed openssh-server: refuses further connections after having handled PerSourceMaxStartups connections with a cherry-pick from upstream.

Other bits and pieces

I upgraded libfido2 to a new upstream version.

I fixed mimalloc: FTBFS on armhf: cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU, which was blocking changes to pendulum in the Python team. I also spent some time helping to investigate libmimalloc3: Illegal instruction Running mtxrun —generate, though that bug is still open.

I fixed various autopkgtest bugs in gssproxy, prompted by #1007 in Debusine.

Since my old team is decommissioning Bazaar/Breezy code hosting in Launchpad (the end of an era, which I have distinctly mixed feelings about), I converted Storm to git.

03 September, 2025 10:56AM by Colin Watson

Paul Wise

FLOSS Activities August 2025

Focus

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

Changes

Issues

  • Obsolete conffile in zmap

All work was done on a volunteer basis.

03 September, 2025 05:16AM

hackergotchi for Ben Hutchings

Ben Hutchings

FOSS activity in August 2025

03 September, 2025 01:14AM by Ben Hutchings

September 02, 2025

hackergotchi for Jonathan Dowland

Jonathan Dowland

Luminal and Lateral

For my birthday I was gifted copies of Eno's last two albums, Luminal and Lateral, both of which are collaborations with Beatie Wolfe.

Luminal and Lateral records in the sunshine

Let's start with the art. I love this semi-minimalist, bold style, and how the LP itself (in their coloured, bio-vinyl variants) feels like it's part of the artwork. I like the way the artist credits mirror each other: Wolfe, Eno for Luminal; Eno, Wolfe for Lateral.

My first "bio vinyl" LP was the Cure's last one, last year. Ahead of it arriving I planned to blog about it, but when it came arrived it turned out I had nothing interesting to say. In terms of how it feels, or sounds, it's basically the same as the traditional vinyl formulation.

The attraction of bio-vinyl to well-known environmentalists like Eno (and I guess, the Cure) is the reduced environmental impact due to changing out the petroleum and other ingredients with recycled used cooking oil. You can read more about bio-vinyl if you wish. I try not to be too cynical about things like this; my immediate response is to assume some kind of green-washing PR campaign (I'm currently reading Consumed by Saabira Chaudhuri, an excellent book that is not sadly only fuelling my cynicism) but I know Eno in particular takes this stuff seriously and has likely done more than a surface-level evaluation. So perhaps every little helps.

On to the music. The first few cuts I heard from the albums earlier in the year didn't inspire me much. Possibly I heard something from Luminal, the vocal album; and I'm generally more drawn to Eno's ambient work. (Lateral is ambient instrumental). I was not otherwise familiar with Beatie Wolfe. On returning to the albums months later, I found them more compelling. Luminal reminds me a little of Apollo: Atmospheres and Soundtracks. Lateral worked well as space music for phd-correction sessions.

The pair recently announced a third album, Liminal, to arrive in October, and totally throw off the symmetry of the first two. Two of its tracks are available to stream now in the usual places.

02 September, 2025 11:23AM

hackergotchi for Junichi Uekawa

Junichi Uekawa

September.

September. Kids Summer Vacation is over and things are starting to come back to the usual rhythm.

02 September, 2025 12:30AM by Junichi Uekawa

September 01, 2025

hackergotchi for Guido Günther

Guido Günther

Free Software Activities August 2025

Another short status update of what happened on my side last month. Released Phosh 0.49.0 and added some more QoL improvements to Phosh Mobile stack (e.g. around Cell broadcasts). Also pulled my SHIFT6mq out of the drawer (where it was sitting in a drawwer far too long) and got it to show a picture after a small driver fix. Thanks to the work the sdm845-mainlining folks are doing that was all that was needed. If I can get touch to work better that would be another nice device for demoing Phosh.

See below for details on the above and more:

phosh

  • Allow to auto-start pomodoro timer (MR)
  • Improve mpris player thumbnails (MR)
  • Cellbroadcast fixes (MR)
  • Release (MR)
  • searchd related build system fixes (MR)
  • gchar vs char cleanup (MR)
  • upcoming-events: Add filter icons (MR)
  • Fix missing header dependency (MR)
  • Release 0.49~rc1, 0.49.0
  • Fix some incorrect callback signatures (MR)

phoc

  • Workspace indicators (MR)
  • Don't overwrite picked output (MR)
  • Release (0.49~rc1, 0.49.0
  • Raise nofile rlimit (MR)
  • Fix gettings tarted page title (MR)
  • Update cursor when layer surface moves away from under the cursor (MR)
  • Support cursor-shape-v1 protocol (MR)
  • pointer: Use libinput's LIBINPUT_CONFIG_DRAG_LOCK_ENABLED_STICKY: (MR)

phosh-mobile-settings

  • Cellbroadcast fixes (MR)
  • build: Link statically against libcellbroadcast subproject (MR)
  • Release 0.49~rc1, 0.49.0

stevia (formerly phosh-osk-stub)

  • Release 0.49~rc1, 0.49.0
  • Fix emoji matching on big endian (MR)
  • Fix emoji matching again aftr switching to GTK's embedded emoji data (MR)
  • Fix scaling when adding new layouts (MR)
  • Improve character popover and other fixes (MR)

xdg-desktop-portal-phosh

pfs

  • Let pressing <enter> save the file (MR)

feedbackd

  • Release 0.8.4
  • Fix important override. (MR)

feedbackd-device-themes

  • Release 0.8.5
  • Lower status LED brightness on sargo (MR)

libcmatrix

  • Track room version (MR)

Chatty

  • Warning fixes (MR)
  • matrix: Show room version (MR)

Debian

Cellbroadcastd

  • Fix daemon systemd target (MR)
  • Ignore case when matching country when looking up channels (MR)
  • Meson dependency fix (MR)

ModemManager

  • Fix two country codes (MR)

gnome-clocks

  • Fix sporadic wakeup due to not diposed timers (MR) also resulting in a vala issue

git-buildpackage

  • Move test data to salsa and fetch it from there: deb, rpm, MR
  • clone: Be less strict on vcs-git URLs (MR)

mobian-recipies

  • Fail early without an ssh key (MR)

Linux

  • Shift6mq: Fix clock frequency of panel driver (MR)
  • Shift6mq: Set chassis type (MR)
  • Shift6mq: Tried to improve the touch driver to increase the sensitivity / sample rate not success yet.

Reviews

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

  • phosh/upcoming-events: Allow to filter out empty days in (MR)
  • phosh: keypad and search bar CSS improvements (MR)
  • p-m-s: Tweaks definition parsing code (MR)
  • p-m-s: osk-shortcuts: UI tweaks (MR)
  • p-m-s: Add gchar check (MR)
  • p-m-s: Make it a search provider (MR)
  • phoc: toplevel-addons (MR)
  • debian: MM stable update (MR)
  • stevia: Use default font (MR)
  • upcoming-events: Use filtered list model (MR)
  • pms: Tweaks rename (MR)
  • pms: Clang build fix (MR)
  • feedbackd: Udev rule for AW86927 (FP5) (MR)
  • xdpm: Allow pure rust build for using in xdg-d-p-phrosh (MR)

Help Development

If you want to support my work see donations.

Comments?

Join the Fediverse thread

01 September, 2025 06:05AM

Birger Schacht

Status update, August 2025

Due to the freeze I did not do that many uploads in the last few months, so there were various new releases I packaged once Trixie was released. Regarding the release of Debian 13, Trixie, I wrote a small summary of the changes in my packages.

I uploaded an unreleased version of cage to experimental, to prepare for the transition to wlroots-0.19. Both sway and labwc already had packages in experimental that depended on the new wlroots version. When the transition happened, I uploaded the cage version to unstable, as well as labwc 0.9.1 and sway 1.11.

I updated

  • foot to 1.23.1
  • waybar to 0.14.0
  • swaylock to 1.8.3
  • git-quick-stats to 2.7.0
  • swayimg to 4.5
  • usbguard to 1.1.4
  • fcft to 3.3.2
  • fnott to 1.8.0
  • wdisplays to 1.1.3
  • wev to 1.1.0
  • wlopm to 1.0.0
  • wmenu to 0.2.0
  • libsfdo to 0.1.4

Most of the packages I uploaded using git-debpush, some of them could not be uploaded this way due to upstream using git submodules (this is 1107219). I also created 1112040 - git-debpush: should also say which tag it created and 1111504 - git-debpush: pristine-tar check warns about pristine-tar data thats not present (which is already fixed).

I uploaded wayback 0.2 to NEW, where it is waiting for review, (ITP).

In my dayjob I added extended the place lookup form of apis-core-rdf to allow searching places and selecting them on a map using leaflet and the nominatim API. Another issue I worked on was about highlighting those inputs of our generic list filter that are used to filter the results. I released a couple of bugfix releases for the v0.50 release, then v0.51 and two bugfix releases and then v0.52 and another couple of bugfix releases. v0.53 will land in a couple of days. I also released v0.6.2 of apis-highlighter-ng, which is sort of a plugin for apis-core-rdf, that allows to highlight parts of a text and link them to whatever Django object (in our case relations).

01 September, 2025 05:28AM

Russ Allbery

Review: Regenesis

Review: Regenesis, by C.J. Cherryh

Series: Cyteen #2
Publisher: DAW
Copyright: January 2009
ISBN: 0-7564-0592-0
Format: Mass market
Pages: 682

The main text below is an edited version of my original review of Regensis written on 2012-12-21. Additional comments from my re-read are after the original review.

Regenesis is a direct sequel to Cyteen, picking up very shortly after the end of that book and featuring all of the same characters. It would be absolutely pointless to read this book without first reading Cyteen; all of the emotional resonance and world-building that make Regensis work are done there, and you will almost certainly know whether you want to read it after reading the first book. Besides, Cyteen is one of the best SF novels ever written and not the novel to skip.

Because this is such a direct sequel, it's impossible to provide a good description of Regenesis without spoiling at least characters and general plot developments from Cyteen. So stop reading here if you've not yet read the previous book.

I've had this book for a while, and re-read Cyteen in anticipation of reading it, but I've been nervous about it. One of the best parts of Cyteen is that Cherryh didn't belabor the ending, and I wasn't sure what part of the plot could be reasonably extended. Making me more nervous was the back-cover text that framed the novel as an investigation of who actually killed the first Ari, a question that was fairly firmly in the past by the end of Cyteen and that neither I nor the characters had much interest in answering. Cyteen was also a magical blend of sympathetic characters, taut tension, complex plotting, and wonderful catharsis, the sort of lightning in a bottle that can rarely be caught twice.

I need not have worried. If someone had told me that Regenesis was another 700 pages of my favorite section of Cyteen, I would have been dubious. But that's exactly what it is. And the characters only care about Ari's murderer because it comes up, fairly late in the novel, as a clue in another problem.

Ari and Justin are back in the safe laboratory environment of Reseune, safe now that politics are not trying to kill or control them. Yanni has taken over administration. There is a general truce, and even some deeper agreement. Everyone can take a breath and relax, albeit with the presence of Justin's father Jordan as an ongoing irritant. But broader Union politics are not stable: there is an election in progress for the Defense councilor that may break the tenuous majority in favor of Reseune and the Science Directorate, and Yanni is working out a compromise to gain more support by turning a terraforming project loose on a remote world. As the election and the politics heat up, interpersonal relationships abruptly deteriorate, tensions with Jordan sharply worsen, and there may be moles in Reseune's iron-clad security. Navigating the crisis while keeping her chosen family safe will once again tax all of Ari's abilities.

The third section of Cyteen, where Ari finally has the tools to take fate into her own hands and starts playing everyone off against each other, is one of my favorite sections of any book. If it was yours as well, Regenesis is another 700 pages of exactly that. As an extension and revisiting, it does lose a bit of immediacy and surprise from the original. Regenesis is also less concerned with the larger questions of azi society, the nature of thought and personality, loyalty and authority, and the best model for the development of human civilization. It's more of a political thriller. But it's a political thriller that recaptures much of the drama and tension of Cyteen and is full of exceptionally smart and paranoid people thinking through all angles of a problem, working fast on their feet, and successfully navigating tricky and treacherous political landscapes.

And, like Cyteen but unlike others of Cherryh's novels I've read, it's a novel about empowerment, about seizing control of one's surroundings and effectively using all of the capability and leverage at one's fingertips. That gives it a catharsis that's almost as good as Cyteen.

It's also, like its predecessor, a surprisingly authoritarian novel. I think it's in that, more than anything else in these books, that one sees the impact of the azi. Regenesis makes it clear that the story is set, not in a typical society, but inside a sort of corporation, with an essentially hierarchical governance structure. There are other SF novels set within corporations (Solitaire comes to mind), but normally they follow peons or at best mid-level personnel or field agents, or otherwise take the viewpoint of the employees or the exploited. When they follow the corporate leaders, the focus usually isn't down inside the organization, but out into the world, with the corporation as silent resources on which the protagonist can draw.

Regenesis is instead about the leadership. It's about decisions about the future of humanity that characters feel they can make undemocratically (in part because they or their predecessors have effectively engineered the opinions of the democratic population), but it's also about how one manages and secures a top-down organization. Reseune is, as in the previous novel, a paranoid's suspicions come true; everyone is out to get everyone else, or at least might be, and the level of omnipresent security and threat forces a close parsing of alliances and motivations that elevates loyalty to the greatest virtue.

In Cyteen, we had long enough with Ari to see the basic shape of her personality and her slight divergences from her predecessor, but her actions are mostly driven by necessity. Regenesis gives us more of a picture of what she's like when her actions aren't forced, and here I think Cherryh manages a masterpiece of subtle characterization. Ari has diverged substantially from her predecessor without always realizing, and those divergences are firmly grounded in the differences she found or created between her life and the first Ari's. She has friends, confidents, and a community, which combined with past trauma has made her fiercely, powerfully protective. It's that protective instinct that weaves the plot together. So many of the events of Cyteen and Regenesis are driven by people's varying reactions to trauma.

If you, like me, loved the last third of Cyteen, read this, because Regenesis is more of exactly that. Cherryh finds new politics, new challenges, and a new and original plot within the same world and with the same characters, but it has the same feel of maneuvering, analysis, and decisive action. You will, as with Cyteen have to be comfortable with pages of internal monologue from people thinking through all sides of a problem. If you didn't like that in the previous book, avoid this one; if you loved it, here's the sequel you didn't know you were waiting for.

Original rating: 9 out of 10


Some additional thoughts after re-reading Regenesis in 2025:

Cyteen mostly held up to a re-reading and I had fond memories of Regenesis and hoped that it would as well. Unfortunately, it did not. I think I can see the shape of what I enjoyed the first time I read it, but I apparently was in precisely the right mood for this specific type of political power fantasy.

I did at least say that you have to be comfortable with pages of internal monologue, but on re-reading, there was considerably more of that than I remembered and it was quite repetitive. Ari spends most of the book chasing her tail, going over and around and beside the same theories that she'd already considered and worrying over the nuances of every position. The last time around, I clearly enjoyed that; this time, I found it exhausting and not very well-written. The political maneuvering is not that deep; Ari just shows every minutia of her analysis.

Regenesis also has more about the big questions of how to design a society and the role of the azi than I had remembered, but I'm not sure those discussions reach any satisfying conclusions. The book puts a great deal of effort into trying to convince the reader that Ari is capable of designing sociological structures that will shape Union society for generations to come through, mostly, manipulation of azi programming (deep sets is the term used in the book). I didn't find this entirely convincing the first time around, and I was even less convinced in this re-read. Human societies are a wicked problem, and I don't find Cherryh's computer projections any more convincing than Asimov's psychohistory.

Related, I am surprised, in retrospect, that the authoritarian underpinnings of this book didn't bother me more on my first read. They were blatantly obvious on the second read. This felt like something Cherryh put into these books intentionally, and I think it's left intentionally ambiguous whether the reader is supposed to agree with Ari's goals and decisions, but I was much less in the mood on this re-read to read about Ari making blatantly authoritarian decisions about the future of society simply because she's smart and thinks she, unlike others, is acting ethically. I say this even though I like Ari and mostly enjoyed spending time in her head. But there is a deep fantasy of being able to reprogram society at play here that looks a lot nastier from the perspective of 2025 than apparently it did to me in 2012.

Florian and Catlin are still my favorite characters in the series, though. I find it oddly satisfying to read about truly competent bodyguards, although like all of the azi they sit in an (I think intentionally) disturbing space of ambiguity between androids and human slaves.

The somewhat too frank sexuality from Cyteen is still present in Regenesis, but I found it a bit less off-putting, mostly because everyone is older. The authoritarian bent is stronger, since Regenesis is the story of Ari consolidating power rather than the underdog power struggle of Cyteen, and I had less tolerance for it on this re-read.

The main problem with this book on re-read was that I bogged down about halfway through and found excuses to do other things rather than finish it. On the first read, I was apparently in precisely the right mood to read about Ari building a fortified home for all of her friends; this time, it felt like endless logistics and musings on interior decorating that didn't advance the plot. Similarly, Justin and Grant's slow absorption into Ari's orbit felt like a satisfying slow burn friendship in my previous reading and this time felt touchy and repetitive.

I was one of the few avid defenders of Regenesis the first time I read it, and sadly I've joined the general reaction on a re-read: This is not a very good book. It's too long, chases its own tail a bit too much, introduces a lot more authoritarianism and doesn't question it as directly as I wanted, and gets even deeper into Cherryh's invented pseudo-psychology than Cyteen. I have a high tolerance for the endless discussions of azi deep sets and human flux thinking, and even I got bored this time through.

On re-read, this book was nowhere near as good as I thought it was originally, and I would only recommend it to people who loved Cyteen and who really wanted a continuation of Ari's story, even if it is flabby and not as well-written. I have normally been keeping the rating of my first read of books, but I went back and lowered this one by two points to ensure it didn't show as high on my list of recommendations.

Re-read rating: 6 out of 10

01 September, 2025 04:41AM

Iustin Pop

Small PSA: git.k1024.org turndown

Just a small thing: I’m going to turn down the very simple gitweb interface at https://git.k1024.org/. Way back, I thought I should have a backup for GitHub, but the decentralised Git model makes this not really needed, and gitweb is actually pretty heavy, even if it is really bare-bones.

Practically, as small as that site was, it was fine before the LLM era. Since then, I keep getting lots of traffic, as if these repositories which already exist on GitHub hold critical training information… Thus, I finally got the impetus to turn it down, for no actual loss. Keeping it would make sense only if I were to change it into a proper forge, but that’s a different beast, in which I have no interest (as a public service). So, down it goes.

I’ll probably replace all of it with a single static page, text-only even 😄

Next in terms of simplification will probably be removing series from this blog, since there’s not enough clear separation between tags and series. Or at least, I’m not consequent enough to write a very clean set of articles that can be ordered and numbered as a unit.

01 September, 2025 12:08AM

August 31, 2025

Russell Coker

August 30, 2025

hackergotchi for Steinar H. Gunderson

Steinar H. Gunderson

Bruteforcing pwgen passwords

I needed to bruteforce some passwords that I happened to know that were generated with the default mode (“pronouncable”) of pwgen, so I spent a fair amount of time writing software to help. It went through a whole lot of iterations and ended up being more efficient than I had ever assumed would be possible (although it's still nowhere near as efficient as it should ideally be). So now I'm sharing it with you. If you have IPv6 and can reach git.sesse.net, that is.

I'm pasting the entire README below. Remember to use it for ethical purposes.

Introduction
============

pwbrute creates all possible pwgen passwords (default tty settings, no -s).
It matches pwgen 2.08. It supports ordering them by most common first.
Note that pwgen before 2.07 also supported a special “non-tty mode”
that was even less secure (no digits, no uppercase) which is not supported here.

To get started, do

   g++ -std=c++20 -O2 -o pwbrute pwbrute.cc -ljemalloc
  ./pwbrute --raw --sort --expand --verbose > passwords.txt

wait for an hour or two and you're left with 276B passwords in order
(about 2.5TB). (You can run without -ljemalloc, but the glibc malloc
makes pwbrute take about 50% more time.)

pwbrute is not a finished, polished product. Do not expect this to be
suitable for inclusion in e.g. a Linux distribution.


A brief exposition of pwgen's security
======================================

pwgen is a program that is fairly widely used in Linux/UNIX systems
to generate “pronounceable” (and thus supposedly easier-to-remember)
passwords. On the surface of it, the default 8-letter passwords with
uppercase letters, lowercase letters and digits would have a password
space of

  62^8 = 218,340,105,584,896 ~= 47.63 bits

This isn't enough to save you from password cracking against fast hashes
(e.g. NTLM), but it's enough for almost everything else.

However, pwgen (without -s) does by design not use this entire space.
It builds passwords from a list of 40 “phonemes” (a, ae, ah, ai, b,
c, ch, ...) in sequence, with some rules of which can come after each
others (e.g. the combination f-g is disallowed, since any consonant
phoneme must be followed by a vowel or sometimes a digit), and sometimes
digits. Furthermore, some phonemes may be uppercased (only first letter,
in case of two-letter phonemes). In all, these restrictions mean that
the number of producable passwords drop to

  307,131,320,668 ~= 38.16 bits

Furthermore, if a password does not contain at least one uppercase letter
and one digit, it is rejected. This doesn't affect that many passwords,
but it's still down to

  276,612,845,450 ~= 38.00 bits

You would believe that this means that to get to a 50% chance of cracking
a password, you'd need to test about ~138 billon passwords; however, the
effective entropy is much, much worse than that:

First, consider that digits are inserted (at valid points) only with
30% probability, and phonemes are uppercased (at valid points) only
with 20% probability. This means that a password like “Ahdaiy7i” is
_much_ more likely than e.g. “EXuL8OhP” (five uppercase letters),
even though both are possible to generate.

Furthermore, when building up the password from left to right, every
letter is not equally likely -- every _phoneme_ is equally likely.
Since at any given point, (e.g.) “ai” is as likely as “a”, a lot fewer
rolls of the dice are required to get to eight letters if the password
contains many dipthongs (two-letter phonemes). This makes them vastly
overrepresented. E.g., the specific password “aechae0A” has three dipthongs
and a probability of about 1 in 12 million of being generated, while
“Oozaey7Y” has only two dipthongs (but an extra capital letter) and a
probability of about 1 in 9.33 _billion_!

In all, this means that to get to 50% probability of cracking a given
pwgen password (assuming you know that it was indeed generated with
pwgen, without -s), you need to test about 405 million passwords.
Note that pwgen gives out a list of passwords and lets the user choose,
which may make this easier or harder; I've had real-world single-password
cracks that fell after only ~400k attempts (~2% probability if the user
has chosen at random, but they most likely picked one that looked more
beautiful to them somehow).

This is all known; I reported the limited keyspace in 2004 (Debian bug
#276976), and Solar Designer reported the poor entropy in CVE-2013-4441.
(I discovered the entropy issues independently from them a couple of
months later, then discovered that it was already known, and didn't
publish.) However, to the best of my knowledge, pwbrute is the first
public program that will actually generate the most likely passwords
efficiently for you.

Needless to say, I cannot recommend using pwgen's phoneme-based
passwords for anything that needs to stay secure. (I will not make
concrete recommendations beyond that; a lot of literature exists
on the subject.)


Speeding up things
==================

Very few users would want the entire set of passwords, given that the
later ones are incredibly unlikely (e.g., AB0AB0AB has a chance of about
2^-52.155, or 1 in 5 quadrillion). To not get all, you can use e.g.
-c -40, which will produce only those with more than approx. 2^-40 probability
before final rejection (roughly ~6B passwords).

(NOTE: Since the calculated probability is before final rejection of those
without a digit or uppercase letter, they will not sum to 1, but something
less; approx. 0.386637 for the default 8-letter passwords, or 2^-1.3709.
Take this into account when reading all text below.)

pwbrute is fast but not super-fast; it can generate about 80M passwords/sec
(~700 MB/sec) to stdout, of course depending on your CPUs. The expansion phase
generally takes nearly all the time; if your cracker could somehow accept the
unexpanded patterns (i.e., without --expand) for free, pwbrute would basically
be infinitely fast. (It would be possible to microoptimize the expansion,
perhaps to 1B passwords/sec/core if pulling out all the stops, but at some point,
it starts becoming a problem related to pipe I/O performance, not candidate
generation.)

Thus, if your cracker is very fast (e.g. hashcat cracking NTLM), it's suboptimal
to try to limit yourself to only pwbrute-created passwords. It's much, much
faster to just create a bunch of legal prefixes and then let hashcat try all
of them, even though this will test some “impossible” passwords.
For instance:

  ./pwbrute --first-stage-len 5 --raw > start5.pwd
  ./hashcat.bin -O -m 1000 ntlm.pwd -w 3 -a 6 start5.pwd -1 '?l?u?d' '?1?1?1'

The “combination” mode in hashcat is also not always ideal; consider using
rules instead.

If you need longer passwords than 8 characters, you may want to split the job
into multiple parts. For this, you can combine --first-stage-len with --prefix
to generate passwords in two stages, e.g. first generate all valid 3-letter
prefixes (“bah” is valid, “bbh” is not) and then for each prefix generate
all possible passwords.  This requires much less RAM, can go in parallel,
and is pretty efficient.

For instance, this will create all passwords up to probability 2^-30,
over 16 cores, in a form that doesn't use too much RAM:

  ./pwbrute -f 3 -r -s -e | parallel -j 16 "./pwbrute -p {} -c -30 -s 2>/dev/null | zstd -6 > up-to-30-{}.pwd.zst"

You can then use the included merge.cc utility to merge the sorted files
into a new sorted one (this requires not using pwbrute --raw, since merge
wants the probabilities to merge correctly):

  g++ -O2 -o merge merge.cc -lzstd
  ./merge up-to-30-*.pwd.zst | pv | pzstd -6 > up-to-30.pwd.zst

merge is fairly fast, but not infinitely so. Sorry.

Beware, zstd uses some decompression buffers that can be pretty big per-file
and there are lots of files, so if you put the limit  lower than -30,
consider merging in multiple phases or giving -M to zstd, unless you want to
say hello to the OOM killer half-way into your merge.

As long as you give the --sort option to pwbrute, it is designed to give exactly
the same output in the same order every time (at the expense of a little bit of
speed during the pattern generation phase). This means that you can safely resume
an aborted generation or cracking job using the --skip=NUM flag, without worrying
that you'd lose some candidates.

Here are some estimated numbers for various probability cutoffs, and how much
of the probability space they cover (after correction for rejected passwords):

  p >= 2^-25:           78,000 passwords   (  0.00% coverage,   0.63% probability)
  p >= 2^-26:          171,200 passwords   (  0.00% coverage,   1.12% probability)
  p >= 2^-27:        3,427,100 passwords   (  0.00% coverage,   9.35% probability)
  p >= 2^-28:        5,205,200 passwords   (  0.00% coverage,  12.01% probability)
  p >= 2^-29:        8,588,250 passwords   (  0.00% coverage,  14.17% probability)
  p >= 2^-30:       24,576,550 passwords   (  0.01% coverage,  19.23% probability)
  p >= 2^-31:       75,155,930 passwords   (  0.03% coverage,  27.58% probability)
  p >= 2^-32:      284,778,250 passwords   (  0.10% coverage,  43.81% probability)
  p >= 2^-33:      540,418,450 passwords   (  0.20% coverage,  55.14% probability)
  p >= 2^-34:      808,534,920 passwords   (  0.29% coverage,  60.49% probability)
  p >= 2^-35:    1,363,264,200 passwords   (  0.49% coverage,  66.28% probability)
  p >= 2^-36:    2,534,422,340 passwords   (  0.92% coverage,  72.36% probability)
  p >= 2^-37:    5,663,431,890 passwords   (  2.05% coverage,  80.54% probability)
  p >= 2^-38:   11,178,389,760 passwords   (  4.04% coverage,  87.75% probability)
  p >= 2^-39:   16,747,555,070 passwords   (  6.05% coverage,  91.55% probability)
  p >= 2^-40:   25,139,913,440 passwords   (  9.09% coverage,  94.25% probability)
  p >= 2^-41:   34,801,107,110 passwords   ( 12.58% coverage,  95.91% probability)
  p >= 2^-42:   52,374,739,350 passwords   ( 18.93% coverage,  97.38% probability)
  p >= 2^-43:   78,278,619,550 passwords   ( 28.30% coverage,  98.51% probability)
  p >= 2^-44:  111,967,613,850 passwords   ( 40.48% coverage,  99.25% probability)
  p >= 2^-45:  147,452,759,450 passwords   ( 53.31% coverage,  99.64% probability)
  p >= 2^-46:  186,012,691,450 passwords   ( 67.25% coverage,  99.86% probability)
  p >= 2^-47:  215,059,885,450 passwords   ( 77.75% coverage,  99.94% probability)
  p >= 2^-48:  242,726,285,450 passwords   ( 87.75% coverage,  99.98% probability)
  p >= 2^-49:  257,536,845,450 passwords   ( 93.10% coverage,  99.99% probability)
  p >= 2^-50:  268,815,845,450 passwords   ( 97.18% coverage, 100.00% probability)
  p >= 2^-51:  273,562,845,450 passwords   ( 98.90% coverage, 100.00% probability)
  p >= 2^-52:  275,712,845,450 passwords   ( 99.67% coverage, 100.00% probability)
  p >= 2^-53:  276,512,845,450 passwords   ( 99.96% coverage, 100.00% probability)
         all:  276,612,845,450 passwords   (100.00% coverage, 100.00% probability)


License
=======

pwbrute is Copyright (C) 2025 Steinar H. Gunderson.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

30 August, 2025 09:56AM

August 29, 2025

Noah Meyerhans

Determining Network Online Status of Dualstack Cloud VMs

When a Debian cloud VM boots, it typically runs cloud-init at various points in the boot process. Each invocation can perform certain operations based on the host’s static configuration passed by the user, typically either through a well known link-local network service or an attached iso9660 drive image. Some of the cloud-init steps execute before the network comes up, and others at a couple of different points after the network is up.

I recently encountered an unexpected issue when configuring a dualstack (uses both IPv6 and legacy IPv4 networking) VM to use a custom apt server accessible only via IPv6. VM provisioning failed because it was unable to access the server in question, yet when I logged in to investigate, it was able to access the server without any problem. The boot had apparently gone smoothly right up until cloud-init’s Package Update Upgrade Install module called apt-get update, which failed and broke subsequent provisioning steps. The errors reported by apt-get indicated that there was no route to the service in question, which more accurately probably meant that there was not yet a route to the service. But there was shortly after, when I investigated.

This was surprising because the apt-get invocations occur in a cloud-init sequence that’s explicitly ordered after the network is configured according to systemd-networkd-wait-online. Investigation eventually led to similar issues encountered in other environments reported in Debian bug #1111791, “systemd: network-online.target reached before IPv6 address is ready”. The issue described in that bug is identical to mine, but the bug is tagged wontfix. The behavior is considered correct.

Why the default behavior is the correct one

While it’s a bit counterintuitive, the systemd-networkd behavior is correct, and it’s also not something we’d want to override in the cloud images. Without explicit configuration, systemd can’t accurately infer the intended network configuration of a given system. If a system is IPv6-only, systemd-networkd-wait-online will introduce unexpected delays in the boot process if it waits for IPv4, and vice-versa. If it assumes dualstack, things are even worse because it would block for a long time (approximately two minutes) in any single stack network before failing, leaving the host in degraded state. So the most reasonable default behavior is to block until any protocol is configured.

For these same reasons, we can’t change the systemd-networkd-wait-online configuration in our cloud images. All of the cloud environments we support offer both single stack and dual stack networking, so we preserve systemd’s default behavior.

What’s causing problems here is that IPv6 takes significantly longer to configure due to its more complex router solicitation + router advertisement + DHCPv6 setup process. So in this particular case, where I’ve got a dualstack VM that needs to access a v6-only apt server during the provisioning process, I need to find some mechanism to override systemd’s default behavior and wait for IPv6 connectivity specifically.

What won’t work

Cloud-init offers the ability to write out arbitrary files during provisioning. So writing a drop-in for systemd-networkd-wait-online.service is trivial. Unfortunately, this doesn’t give us everything we actually need. We still need to invoke systemctl daemon-reload to get systemd to actually apply the changes after we’ve written them, and of course we need to do that before the service actually runs. Cloud-init provides a bootcmd module that lets us run shell commands “very early in the boot process”, but it runs too early: it runs before we’ve written out our configuration files. Similarly, it provides a runcmd module, but scripts there are towards the end of the boot process, far too late to be useful.

Instead of using the bootcmd facility, to simply reload systemd’s config, it seemed possible that we could both write the config and trigger the reload, similar to the following:

 bootcmd:
- mkdir -p /etc/systemd/system/systemd-networkd-wait-online.service.d
- echo "[Service]" > /etc/systemd/system/systemd-networkd-wait-online.service.d/10-netplan.conf
- echo "ExecStart=" >> /etc/systemd/system/systemd-networkd-wait-online.service.d/10-netplan.conf
- echo "ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --operational-state=routable --any --ipv6" >> /etc/systemd/system/systemd-networkd-wait-online.service.d/10-netplan.conf
- systemctl daemon-reload

But even that runs too late, as we can see in the logs that systemd-networkd-wait-online.service has completed before bootcmd is executed:

root@sid-tmp2:~# journalctl --no-pager -l -u systemd-networkd-wait-online.service
Aug 29 17:02:12 sid-tmp2 systemd[1]: Starting systemd-networkd-wait-online.service - Wait for Network to be Configured...
Aug 29 17:02:13 sid-tmp2 systemd[1]: Finished systemd-networkd-wait-online.service - Wait for Network to be Configured
.
root@sid-tmp2:~# grep -F 'config-bootcmd ran' /var/log/cloud-init.log
2025-08-29 17:02:14,766 - handlers.py[DEBUG]: finish: init-network/config-bootcmd: SUCCESS: config-bootcmd ran successfully and took 0.467 seconds

At this point, it’s looking like there are few options left!

What eventually worked

I ended up identifying two solutions to the issue, both of which involve getting some other component of the provisioning process to run systemd-networkd-wait-online.

Solution 1

The first involves getting apt-get itself to wait for IPv6 configuration. The apt.conf configuration interface allows the definition of an APT::Update::Pre-Invoke hook that’s executed just before apt’s update operation. By writing the following to a file in /etc/apt/apt.conf.d/, we’re able to ensure that we have IPv6 connectivity before apt-get tries accessing the network. This cloud-config snippet accomplishes that:

 - path: /etc/apt/apt.conf.d/99-wait-for-ipv6
content: |
APT::Update::Pre-Invoke { "/usr/lib/systemd/systemd-networkd-wait-online --operational-state=routable --any --ipv6"; }

This is safe to leave in place after provisioning, because the delay will be negligible once IPv6 connectivity is established. It’s only during address configuration that it’ll block for a noticeable amount of time, but that’s what we want.

This solution isn’t entirely correct, though, because it’s only apt-get that’s actually affected by it. Other service that start after the system is ostensibly “online” might only see IPv4 connectivity when they start. This seems acceptable at the moment, though.

Solution 2

The second solution is to simply invoke systemd-networkd-wait-online directly from a cloud-init bootcmd. Similar to the first solution, it’s not exactly correct because the host has already reached network-online.target, but it does block enough of cloud-init that package installation happens only after it completes. The cloud-config snippet for this is

bootcmd:
- [/usr/lib/systemd/systemd-networkd-wait-online, --operational-state=routable, --any, --ipv6]

In either case, we still want to write out a snippet to configure systemd-networkd-wait-online to wait for IPv6 connectivity for future reboots. Even though cloud-init won’t necessarily run in those cases, and many cloud VMs never reboot at all, it does complete the solution. Additionally, it solves the problem for any derivative images that may be created based on the running VM’s state. (At least if we can be certain that instances of those derivative images will never run in an IPv4-only network!)

write_files:
- path: /run/systemd/system/systemd-networkd-wait-online.service.d/99-ipv6-wait.conf
content: |
[Service]
ExecStart=
ExecStart=/lib/systemd/systemd-networkd-wait-online --any --operational-state=routable --ipv6

How to properly solve it

One possible improvement would be for cloud-init to support a configuration key allowing the admin to specify the required protocols. Based on the presence of this key, cloud-init could reconfigure systemd-networkd-wait-online.service accordingly. Alternatively it could set the appropriate RequiredFamilyForOnline= value in the generated .network file. cloud-init supports multiple network configuration backends, so each of those would need to be updated. If using the systemd-networkd configuration renderer, this should be straightforward, but Debian uses the netplan renderer, so that tool might also need to be taught to pass such a configuration along to systemd-networkd.

29 August, 2025 04:38PM by Noah Meyerhans (frodo+blog@morgul.net)

August 27, 2025

Russell Coker

ZRAM and VMs

I’ve just started using zram for swap on VMs. The use of compression for swap in Linux apparently isn’t new, it’s been in the Linux kernel since version 3.2 (since 2012). But until recent years I hadn’t used it. When I started using Mobian (the Debian distribution for phones) zram was in the default setup, it basically works and I never needed to bother with it which is exactly what you want from such a technology. After seeing it’s benefits in Mobian I started using it on my laptops where it worked well.

Benefits of ZRAM

ZRAM means that instead of paging data to storage it is compressed to another part of RAM. That means no access to storage which is a significant benefit if storage is slow (typical for phones) or if storage wearing out is a problem.

For servers you typically have SSDs that are fast and last for significant write volumes, for example the 120G SSDs referenced in my blog post about swap (not) breaking SSD [1] are running well in my parents’ PC because they outlasted all the other hardware connected to them and 120G isn’t usable for anything more demanding than my parents use nowadays. Those are Intel 120G 2.5″ DC grade SATA SSDs. For most servers ZRAM isn’t a good choice as you can just keep doing IO on the SSDs for years.

A server that runs multiple VMs is a special case because you want to isolate the VMs from each other. Support for quotas for storage IO in Linux isn’t easy to configure while limiting the number of CPU cores is very easy. If a system or VM using ZRAM for swap starts paging excessively the bottleneck will be CPU, this probably isn’t going to be great on a phone with a slow CPU but on a server class CPU it will be less of a limit. Whether compression is slower or faster than SSD is a complex issue but it will definitely be just a limit for that VM. When I setup a VM server I want to have some confidence that a DoS attack or configuration error on one VM isn’t going to destroy the performance of other VMs. If the VM server has 4 cores (the smallest VM server I run) and no VM has more than 2 cores then I know that the system can still run adequately if half the CPU performance is being wasted.

Some servers I run have storage limits that make saving the disk space for swap useful. For servers I run in Hetzner (currently only one server but I have run up to 6 at various times in the past) the storage is often limited, Hetzner seems to typically have storage that is 8* the size of RAM so if you have many VMs configured with the swap that they might need in the expectation that usually at most one of them will be actually swapping then it can make a real difference to usable storage. 5% of storage used for swap files isn’t uncommon or unreasonable.

Big Servers

I am still considering the implications of zram on larger systems. If I have a ML server with 512G of RAM would it make sense to use it? It seems plausible that a system might need 550G of RAM and zram could make the difference between jobs being killed with OOM and the jobs just completing. The CPU overhead of compression shouldn’t be an issue as when you have dozens of cores in the system having one or two used for compression is no big deal. If a system is doing strictly ML work there will be a lot of data that can’t be compressed, so the question is how much of the memory is raw input data and the weights used for calculations and how much is arrays with zeros and other things that are easy to compress.

With a big server nothing less than 32G of swap will make much difference to the way things work and if you have 32G of data being actively paged then the fastest NVMe devices probably won’t be enough to give usable performance. As zram uses one “stream” per CPU code if you have 44 cores that means 44 compression streams which should handle greater throughput. I’ll write another blog post if I get a chance to test this.

27 August, 2025 05:19AM by etbe

hackergotchi for Matthew Palmer

Matthew Palmer

StrongBox: Simple, Safe Data Encryption for Rust

Some time ago, I wanted to encrypt a bunch of data in an application I was writing in Rust, mostly to be stored in a database, but also session cookies and sensitive configuration variables. Since Rust is widely known as a secure-yet-high-performance programming language, I was expecting that there would be a widely-used crate that gave me a secure, high-level interface to strong, safe cryptography. Imagine my surprise when I discovered that just… didn’t seem to exist.

Don’t get me wrong: Rust is replete with fast, secure, battle-tested cryptographic primitives. The RustCrypto group provides all manner of robust, widely-used crates for all manner of cryptography-related purposes. They’re the essential building blocks for practical cryptosystems, but using them directly in an application is somewhat akin to building a car from individual atoms of iron and carbon.

So I wrote my own high-level data encryption library, called it StrongBox, and have been happily encrypting and decrypting data ever since.

Cryptography So Simple Even I Can’t Get It Wrong

The core of StrongBox is the StrongBox trait, which has only two methods: encrypt and decrypt, each of which takes just two arguments. The first argument is the plaintext (for encrypt) or the ciphertext (for decrypt) to work on. The second argument is the encryption context, for use as Authenticated Additional Data, an important part of many uses of encryption.

There’s essentially no configuration or parameters to get wrong. You can’t choose the encryption algorithm, or block cipher mode, and you don’t have to worry about generating a secure nonce. You create a StrongBox with a key, and then you call encrypt and decrypt. That’s it.

Practical Cryptographic Affordances

Ok, ok… that’s not quite it. Because StrongBox is even easier to use than what I’ve described, thanks to the companion crate, StructBox.

When I started using StrongBox “in the wild”, it quickly became clear that what I almost always wanted to encrypt in my application wasn’t some ethereal “plaintext”. I wanted to encrypt things, specifically structs (and enums). So, through the magic of Rust derive macros, I built StructBox, which provides encrypt and decrypt operations on any Serde-able type. Given that using Serde encoders can be a bit fiddly to use, it’s virtually easier to get an encrypted, serialized struct than it is to get a plaintext serialized struct.

Key Problems in Cryptography

The thing about cryptography is that it largely turns all data security problems into key management problems. All the fancy cryptographic wonkery is for naught if you don’t manage the encryption keys well.

So, most of the fancy business in StrongBox isn’t the encryption and decryption, but instead solving problems around key management.

Different Keys for Different Purposes

Using the same key for all of your cryptographic needs is generally considered a really bad idea. It opens up all manner of risks, that are easily avoided if you use different keys for different things. However, having to maintain a big pile of different keys is a nightmare, so nobody’s going to do that.

Enter: key derivation. Create one safe, secure “root” key, and then use a key derivation function to spawn as many other keys as you need. Different keys for each database column, another one to encrypt cookies, and so on.

StrongBox supports this through the StemStrongBox type. You’ll typically start off by creating a StemStrongBox with the “root” key, and then derive whatever other StrongBoxes you need, for encrypting and decrypting different kinds of data.

You Spin Me Round…

Sometimes, keys need to be rotated. Whether that’s because you actually know (or even have reason to suspect) someone has gotten the key, or just because you’re being appropriately paranoid, sometimes key rotation has to happen.

As someone who has had to rotate keys in situations where such an eventuality was not planned for, I can say with some degree of authority: it absolutely sucks to have to do an emergency key rotation in a system that isn’t built to make that easy. That’s why StrongBox natively supports key rotation. Every StrongBox takes one encryption key, and an arbitrary number of decryption keys, and will automatically use the correct key to decrypt ciphertexts.

Will You Still Decrypt Me, Tomorrow?

In addition to “manual” key rotation, StrongBox also supports time-based key rotation with the RotatingStrongBox type. This comes in handy when you’re encrypting a lot of “ephemeral” data, like cookies (or server-side session data). It provides a way to automatically “expire” old data, and prevents attacks that become practical when large amounts of data are encrypted using a single key.

Invasion of the Invisible Salamanders!

I mostly mention this just because I love the name, but there is a kind of attack possible in common AEAD modes called the invisible salamanders attack. StrongBox implements mitigations against this, by committing to the key being used so that an attacker can’t forge a ciphertext that decrypts validly to different plaintexts when using different keys. This is why I love cryptography: everything sounds like absolute goddamn magic.

Call Me Crazy, Support Me Maybe?

If you’re coding in Rust (which you probably should be), encrypting your stored data (which you definitely should be), and StrongBox makes your life easier (which it really will), you can show your appreciation for my work by contributing to my open source code-fund. Simply by shouting me a refreshing beverage, you’ll be helping me out, and helping to grow the software commons. Alternately, if you’re looking for someone to Speak Rust to Computers on a professional basis, I’m available for contracts or full-time remote positions.

27 August, 2025 12:00AM by Matt Palmer (mpalmer@hezmatt.org)

August 25, 2025

hackergotchi for David Bremner

David Bremner

Hibernate on the pocket reform 11/n

Context

Update to latest rockchip-devel

  • rebase reform-patches on top of collabora/rockchip-devel
  • pci reset series has new conflicts
  • try dropping from rebase and re-applying
$ b4 am 20250715-pci-port-reset-v6-0-6f9cce94e7bb@oss.qualcomm.com
# follow hint from b4
$ git checkout -b v6_20250715_manivannan_sadhasivam_oss_qualcomm_com 19272b37aa4f83ca52bdf9c16d5d81bdd1354494
$ git am ./v6_20250715_manivannan_sadhasivam_pci_add_support_for_resetting_the_root_ports_in_a_platform_specifi.mbx
$ git rebase -i collabora/rockchip-devel
  • conflict in pcie-qcom.c: take new version
  • conflict in pcie-dw-rockchip.c resolved as in hibernate-pocket-8

  • rebase reform patches on top of pci reset, instead of vice versa.

  • rebuild as discussed in hibernate-pocket-8

$ cp /boot/config-6.16.0-rc7+ .config
$ make olddefconfig
# this generates a message about "reform2_lpc config not found!!"
# and "rockchip_vdec2 config not found!!"
# hopefully this is ok
$ yes '' | make localmodconfig
$ make KBUILD_IMAGE=arch/arm64/boot/Image bindeb-pkg -j$(nproc)

previous episode

25 August, 2025 07:57PM

hackergotchi for Gunnar Wolf

Gunnar Wolf

The comedy of computation, or, how I learned to stop worrying and love obsolescence

This post is a review for Computing Reviews for The comedy of computation, or, how I learned to stop worrying and love obsolescence , a book published in Stanford University Press

“The Comedy of Computation” is not an easy book to review. It is a much enjoyable book that analyzes several examples of how “being computational” has been approached across literary genres in the last century — how authors of stories, novels, theatrical plays and movies, focusing on comedic genres, have understood the role of the computer in defining human relations, reactions and even self-image.

Mangrum structures his work in six thematic chapters, where he presents different angles on human society: How have racial stereotypes advanced in human imagination and perception about a future where we interact with mechanical or computational partners (from mechanical tools performing jobs that were identified with racial profiles to intelligent robots that threaten to control society); the genericity of computers –and people– can be seen as generic, interchangeable characters, often fueled by the tendency people exhibit to confer anthropomorphic qualities to inanimate objects; people’s desire to be seen as “truly authentic”, regardless of what it ultimately means; romantic involvement and romance-led stories (with the computer seen as a facilitator for human-to-human romances, distractor away from them, or being itself a part of the couple); and the absurdity in antropomorphization, in comparing fundamentally different aspects such as intelligence and speed at solving mathematical operations, as well as the absurdity presented blatantly as such by several techno-utopian visions.

But presenting this as a linear set of concepts that are presented does not do justice to the book. Throughout the sections of each chapter, a different work serves as the axis — Novels and stories, Hollywood movies, Broadway plays, some covers for the Time magazine, a couple of presenting the would-be future, even a romantic comedy entirely written by “bots”. And for each of them, Benjamin Mangrum presents a very thorough analysis, drawing relations and comparing with contemporary works, but also with Shakespeare, classical Greek myths, and a very long etcætera. This book is hard to review because of the depth of work the author did: Reading it repeatedly made me look for other works, or at least longer references for them.

Still, despite being a work with such erudition, Mangrum’s text is easy and pleasant to read, without feeling heavy or written in an overly academic style. I very much enjoyed reading this book. It is certainly not a technical book about computers and society in any way; it is an exploration of human creativity and our understanding of the aspects the author has found as central to understanding the impact of computing on humankind.

However, there is one point I must mention before closing: I believe the editorial decision to present the work as a running text, with all the material conceptualized as footnotes presented as a separate, over 50 page long final chapter, detracts from the final result. Personally, I enjoy reading the footnotes because they reveal the author’s thought processes, even if they stray from the central line of thought. Even more, given my review copy was a PDF, I could not even keep said chapter open with one finger, bouncing back and forth. For all purposes, I missed out on the notes; now that I finished reading and stumbled upon that chapter, I know I missed an important part of the enjoyment.

25 August, 2025 04:35PM

August 22, 2025

Russell Coker

Dell T320 H310 RAID and IT Mode

The Problem

Just over 2 years ago my Dell T320 server had a motherboard failure [1]. I recently bought another T320 that had been gutted (no drives, PSUs, or RAM) and put the bits from my one in it.

I installed Debian and the resulting installation wouldn’t boot, I tried installing with both UEFI and BIOS modes with the same result. Then I realised that the disks I had installed were available even though I hadn’t gone through the RAID configuration (I usually make a separate RAID-0 for each disk to work best with BTRFS or ZFS). I tried changing the BIOS setting for SATA disks between “RAID” and “AHCI” modes which didn’t change things and realised that the BIOS setting in question probably applies to the SATA connector on the motherboard and that the RAID card was in “IT” mode which means that each disk is seen separately.

If you are using ZFS or BTRFS you don’t want to use a RAID-1, RAID-5, or RAID-6 on the hardware RAID controller, if there are different versions of the data on disks in the stripe then you want the filesystem to be able to work out which one is correct. To use “IT” mode you have to flash a different unsupported firmware on the RAID controller and then you either have to go to some extra effort to make it bootable or have a different device to boot from.

The Root Causes

Dell has no reason to support unusual firmware on their RAID controllers. Installing different firmware on a device that is designed for high availability is going to have some probability of data loss and perhaps more importantly for Dell some probability of customers returning hardware during the support period and acting innocent about why it doesn’t work. Dell has a great financial incentive to make it difficult to install Dell firmware on LSI cards from other vendors which have equivalent hardware as they don’t want customers to get all the benefits of iDRAC integration etc without paying the Dell price premium.

All the other vendors have similar financial incentives so there is no official documentation or support on converting between different firmware images. Dell’s support for upgrading the Dell version is pretty good, but it aborts if it sees something different.

The Attempts

I tried following the instructions in this document to flash back to Dell firmware [2]. This document is about the H310 RAID card in my Dell T320 AKA a “LSI SAS 9211-8i”. The sas2flash.efi program didn’t seem to do anything, it returned immediately and didn’t give an error message.

This page gives a start of how to get inside the Dell firmware package but doesn’t work [3]. It didn’t cover the case where sasdupie aborts with an error because it detects the current version as “00.00.00.00” not something that the upgrade program is prepared to upgrade from. But it’s a place to start looking for someone who wants to try harder at this.

This forum post has some interesting information, I gave up before trying it, but it may be useful for someone else [4].

The Solution

Dell tower servers have as a standard feature an internal USB port for a boot device. So I created a boot image on a spare USB stick and installed it there and it then loads the kernel and mounts the filesystem from a SATA hard drive. Once I got that working everything was fine. The Debian/Trixie installer would probably have allowed me to install an EFI device on the internal USB stick as part of the install if I had known what was going to happen.

The system is now fully working and ready to sell. Now I just need to find someone who wants “IT” mode on the RAID controller and hopefully is willing to pay extra for it.

Whatever I sell the system for it seems unlikely to cover the hours I spent working on this. But I learned some interesting things about RAID firmware and hopefully this blog post will be useful to other people, even if only to discourage them from trying to change firmware.

22 August, 2025 03:57PM by etbe

August 21, 2025

hackergotchi for Matthew Palmer

Matthew Palmer

Progress on my open source funding experiment

When I recently announced that I was starting an open source crowd-funding experiment, I wasn’t sure what would happen. Perhaps there’d be radio silence, or a huge out-pouring of interest from people who wanted to see more open source code in the world. What’s happened so far has been… interesting.

I chose to focus on action-validator because it’s got a number of open feature requests, and it solves a common problem that people have. The thing is, I’ve developed and released a lot of open source over the multiple decades I’ve been noodling around with computers. Much of that has been of use to many people, the overwhelming majority of whom I will never, ever meet, hear from, or even know that I’ve helped them out.

One person, however, I do know about – a generous soul named Andy, who (as far as I know) doesn’t use action-validator, but who does use another tool I wrote some years ago: lvmsync. It’s somewhat niche, essentially “rsync for LVM-backed block devices”, so I’m slightly surprised that it’s my most-starred repository, at nearly 400(!) stars. Andy is one of the people who finds it useful, and he was kind enough to reach out and offer a contribution in thanks for lvmsync existing.

In the spirit of my open source code-fund, I applied Andy’s contribution to the “general” pool, and as a result have just released action-validator v0.8.0, which supports a new --rootdir command-line option, fixing action-validator issue #54. Everyone who uses --rootdir in their action-validator runs has Andy to thank, and I thank him too.

This is, of course, still early days in my experiment. You can be like Andy, and make the open source world a better place, by contributing to my code-fund, and you can get your name up in lights, too. Whether you’re an action-validator user, have gotten utility from any of the other things I’ve written, or just want to see more open source code in the world, your contribution is greatly appreciated.

21 August, 2025 12:00AM by Matt Palmer (mpalmer@hezmatt.org)

August 20, 2025

hackergotchi for Dirk Eddelbuettel

Dirk Eddelbuettel

x13binary 1.1.61.1 on CRAN: Micro Fix

The x13binary team is happy to share the availability of Release 1.1.61.1 of the x13binary package providing the X-13ARIMA-SEATS program by the US Census Bureau which arrived on CRAN earlier today.

This release responds to a recent change in gfortran version 15 which now picks up a missing comma in a Fortran format string for printing output. The change is literally a one-char addition which we also reported upstream. At the same time this release also updates one README.md URL to an archive.org URL of an apparently deleted reference. There is now also an updated upstream release 1.1-62 which we should package next.

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.

20 August, 2025 09:51PM

Sven Hoexter

Istio: Connect via a VirtualService to External IP Addresses

Rant - I've a theory about istio: It feels like a software designed by people who hate the IT industry and wanted revenge. So they wrote a software with so many odd points of traffic interception (e.g. SNI based traffic re-routing) that's completely impossible to debug. If you roll that out into an average company you completely halt the IT operations for something like a year.

On topic: I've two endpoints (IP addresses serving HTTPS on a none standard port) outside of kubernetes, and I need some rudimentary balancing of traffic. Since istio is already here one can levarage that, combining the resource kinds ServiceEntry, DestinationRule and VirtualService to publish a service name within the istio mesh. Since we do not have host names and DNS for those endpoint IP addresses we need to rely on istio itself to intercept the DNS traffic and deliver a virtual IP address to access the service. The sample given here leverages the exportTo configuration to make the service name only available in the same namespace. If you need broader access remove or adjust that. As usual in kubernetes you can resolve the name also as FQDN, e.g. acme-service.mynamespace.svc.cluster.local.

---
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: acme-service
spec:
  hosts:
    - acme-service
  ports:
    - number: 12345
      name: acmeglue
      protocol: HTTPS
  resolution: STATIC
  location: MESH_EXTERNAL
  # limit the availability to the namespace this resource is applied to
  # if you need cross namespace access remove all the `exportTo`s in here
  exportTo:
    - "."
  # use `endpoints:` in this setup, `addreses:` did not work
  endpoints:
    # region1
    - address: 192.168.0.1
      ports:
        acmeglue: 12345
    # region2
     - address: 10.60.48.50
       ports:
        acmeglue: 12345
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: acme-service
spec:
  host: acme-service
  # limit the availability to the namespace this resource is applied to
  exportTo:
    - "."
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
    connectionPool:
      tcp:
        tcpKeepalive:
          # We have GCP service attachments involved with a 20m idle timeout
          # https://cloud.google.com/vpc/docs/about-vpc-hosted-services#nat-subnets-other
          time: 600s
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: acme-service
spec:
  hosts:
    - acme-service
  # limit the availability to the namespace this resource is applied to
  exportTo:
    - "."
  http:
  - route:
    - destination:
        host: acme-service
    retries:
      attempts: 2
      perTryTimeout: 2s
      retryOn: connect-failure,5xx
---
# Demo Deployment, istio configuration is the important part
apiVersion: apps/v1
kind: Deployment
metadata:
  name: foobar
  labels:
    app: foobar
spec:
  replicas: 1
  selector:
    matchLabels:
      app: foobar
  template:
    metadata:
      labels:
        app: foobar
        # enable istio sidecar
        sidecar.istio.io/inject: "true"
      annotations:
        # Enable DNS capture and interception, IP resolved will be in 240.240/16
        # If you use network policies you've to allow egress to this range.
        proxy.istio.io/config: |
          proxyMetadata:
            ISTIO_META_DNS_CAPTURE: "true"
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Now we can exec into the deployed pod, do something like curl -vk https://acme-service:12345, and it will talk to one of the endpoints defined in the ServiceEntry via an IP address out of the 240.240/16 Class E network.

Documentation
https://istio.io/latest/docs/reference/config/networking/virtual-service/
https://istio.io/latest/docs/reference/config/networking/service-entry/#ServiceEntry-Resolution
https://istio.io/latest/docs/reference/config/networking/destination-rule/#LoadBalancerSettings-SimpleLB
https://istio.io/latest/docs/ops/configuration/traffic-management/dns-proxy/#sidecar-mode

20 August, 2025 04:07PM

hackergotchi for Dirk Eddelbuettel

Dirk Eddelbuettel

RcppArmadillo 14.6.3-1 on CRAN: Minor Upstream Bug Fixes

armadillo image

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

Conrad made three minor bug fix releases since the 4.6.0 release last month. We need to pace releases at CRAN so we do not immediately upload there on each upstream release—and then CRAN also had the usual (and well-deserved) summer rest leading to a slight delay relative to the last upstream. The minor changes in the three releases are summarized below. All our releases are always available via the GitHub repo and hence also via r-universe, and still rigorously tested via our own reverse-dependency checks. We also note that the package once again passed with flying colours and no human intervention which remains impressive given the over 1200 reverse dependencies.

Changes in RcppArmadillo version 14.6.3-1 (2025-08-14)

  • Upgraded to Armadillo release 14.6.3 (Caffe Mocha)

    • Fix OpenMP related crashes in Cube::slice() on Arm64 CPUs

Changes in RcppArmadillo version 14.6.2-1 (2025-08-08) (GitHub Only)

  • Upgraded to Armadillo release 14.6.2 (Caffe Mocha)

    • Fix for corner-case speed regression in sum()

    • Better handling of OpenMP in omit_nan() and omit_nonfinite()

Changes in RcppArmadillo version 14.6.1-1 (2025-07-21) (GitHub Only)

  • Upgraded to Armadillo release 14.6.1 (Caffe Mocha)

    • Fix for speed regression in mean()

    • Fix for detection of compiler configuration

    • Use of pow optimization now optional

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

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

20 August, 2025 02:31PM

Reproducible Builds

Reproducible Builds summit 2025 to take place in Vienna

We are extremely pleased to announce the upcoming Reproducible Builds summit, which will take place from October 28th—30th 2025 in the historic city of Vienna, Austria.

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

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

About the event

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

With your help, we will bring this (and several other areas) into life:


The main seminar room.

Schedule

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

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

Logs and minutes will be published after the meeting.

Location & date

Registration instructions

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

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

20 August, 2025 12:00AM

August 19, 2025

Russell Coker

Colmi P80 SmartWatch First Look

I just bought a Colmi P80 SmartWatch from Aliexpress for $26.11 based on this blog post reviewing it [1]. The main things I was after in this was a larger higher resolution screen because my vision has apparently deteriorated during the time I’ve been wearing a Pinetime [2] and I now can’t read messages on it when not wearing my reading glasses.

The watch hardware is quite OK. It has a larger and higher resolution screen and looks good. The review said that GadgetBridge (the FOSS SmartWatch software in the F-Droid repository) connected when told that the watch was a P79 and in a recent release got support for sending notifications. In my tests with GadgetBridge it doesn’t set the time, can’t seem to send notifications, can’t read the battery level, and seems not to do anything other than just say “connected”. So I installed the proprietary app, as an aside it’s a neat feature to have the watch display a QR code for installing the app, maybe InfiniTime should have a similar QR code for getting GadgetBridge from the F-Droid repository.

The proprietary app is quote OK for the basic functionality and a less technical relative who is using one is happy. For my use the proprietary app is utterly broken. One of my main uses is to get notifications of Jabber messages from the Conversations app (that’s in F-Droid). I have Conversations configured to always have a notification of how many accounts are connected which prevents Android from killing it, with GadgetBridge that notification isn’t reported but the actual message contents are (I don’t know how/why that happens) but with the Colmi app I get repeated notifcation messages on the watch about the accounts being connected. Also the proprietary app has on/off settings for messages to go to the watch for a hard coded list of 16 common apps and an “Others” setting for the rest. GadgetBridge lists the applications that are actually installed so I can configure it not to notify me about Reddit, connecting to my car audio, and many other less common notifications. I prefer the GadgetBridge option to have an allow-list for apps that I want notifications from but it also has a configuration option to use a deny list so you could have everything other than the app that gives lots of low value notifications. The proprietary app has a wide range of watch faces that it can send to the watch which is a nice feature that would be good to have in InfiniTime and GadgetBridge.

The P80 doesn’t display a code on screen when it is paired via Bluetooth so if you have multiple smart watches then you are at risk of connecting to the wrong one and there doesn’t seem to be anything stopping a hostile party from connecting to one. Note that hostile parties are not restricted to the normal maximum transmission power and can use a high gain antenna for reception so they can connect from longer distances than normal Bluetooth devices.

Conclusion

The Colmi P80 hardware is quite decent, the only downside is that the vibration has an annoying “tinny” feel. Strangely it has a rotation sensor for a rotating button (similar to analogue watches) but doesn’t seem to have a use for it as the touch screen does everything.

The watch firmware is quite OK (not great but adequate) but lacking a password for pairing is a significant lack.

The Colmi Android app has some serious issues that make it unusable for what I do and the release version of GadgetBridge doesn’t work with it, so I have gone back to the PineTime for actual use.

The PineTime cost twice as much, has less features (no sensor for O2 level in blood), but seems more solidly constructed.

I plan to continue using the P80 with GadgetBridge and Debian based SmartWatch software to help develop the Debian Mobile project. I expect that at some future time GadgetBridge and the programs written for non-Android Linux distributions will support the P80 and I will transition to it. I am confident that it will work well for me at some future time and that I will get $26.11 of value from it. At this time I recommend that people who do the sort of things I do get one of each and that less technical people get a Colmi P80.

19 August, 2025 10:31AM by etbe

August 18, 2025

hackergotchi for Daniel Pocock

Daniel Pocock

Phil Wyett evidence & Debian Zizian plagiarism, modern slavery tendencies

A new Debian crisis emerged on Sunday of the Debian Day weekend with an email from Phil Wyett (kathenas). He chose the subject line Ending Debian Contribution. The snobby people insulted him and he quit.

The email only received one reply. Nobody thanked Phil for his enormous work over an extended period of years. Once again, they chewed somebody up, spat him out and abandoned him at the side of the road.

The email was sent on 17 August in the UK time zone, that is, the anniversary of the book Animal Farm. Phil is in the UK.

When Phil applied to be a Debian Developer in December 2023, he received this very positive reference from Gianfranco Costamagna (locutusofborg):

For nm.debian.org, at 2023-07-24:
I support Philip Wyett 's request to become a Debian Developer, uploading.
I have worked with Philip Wyett on X and Y
for 2 years, and I consider them as having sufficient technical competence.

I don't usually advocate when I "just" sponsor less than 20 packages for a person.
I decided to gran him an exception, because:
1) he has strong motivation in keeping filezilla/libfilezilla in a good shape in Debian.
2) he is fast in acting and answer to questions/emails
3) he knows how ABI/API works, and he does "transition" the two packages successfully since
when he started working on them (its a 2 packages transition, but he knows his stuff!)
4) libfilezilla bumps ABI on each release, so being DM for him is probably painful.
5) he did work on other packages such as pingus, rednotebook.
6) I think having them as DD is a great value for Debian project.

I have personally worked with Philip Wyett 
(key 70A0AC45AC779EFE84F63AED724AA9B52F024C8B) for 2 years, and I know Philip Wyett
can be trusted to be a full member of Debian, and have unsupervised, unrestricted upload rights, right now.

Addendum:
For nm.debian.org, at 2024-01-22:
After the closing of the previous application, I asked Philip to do *many* Debian related things.
It turned out that the application was a little bit premature, Debian is not just
about having technical skills (and he strongly has them), but
also about helping newcomers, understanding how the community is built and how to interact each
other without loosing the objective that has to be to bring an OS to end users.
For this reason, after sponsoring a ton of packages reviewed by him on mentors.debian.org, and giving
them DM rights for the packages he maintains, I'm more confident about his ability to become
a full unsupervised DD.

In December 2024, a whole group of people all wrote positive references for Phil.

His Debian wiki profile, now deleted, included the comments:

Most of the money you see in and around Free / Open Source Software, Hardware and other projects is in the hands of large groups and self styled organisations, with little or none reaching the actually contributors/maintainer/developers of your favourite projects who actually do the core work.

Consider donating to projects and persons directly.

That must have annoyed the people who spend money without doing any work.

Quoting Phil's email from 17 August 2025:

In my opinion I have been messed about for over a year, discriminated against by one or more of the Debian Application Managers who overlooked my DD application for over 7 months whilst moving forward with other applications that were made after my own, one done in 10 days.

Looking through the history of mailing lists and the wiki (links below), we can see hundreds of messages from Phil as he works on his own packages and helps other people begin packaging with Debian. It looks like he has done more than enough work to have rights as a Debian Developer under copyright law.

The Debian Project Leader (DPL), Andreas Tille, obtained a PhD in Physics and works at the Robert Koch-Institute in Wernigerode, Germany. Surely he understands that in any publication, whether it is a scientific research paper or a piece of software, the names of all the authors/developers have to be listed with an equal status. Not including somebody's name is a close cousin of plagiarism. I've raised concerns about plagiarism in Debian before.

My next communication was from the DAMs closing my application and stating I could never apply again. The DPL has agreed with this decision.

If the Debian Account Managers were never going to respect his copyright status anyway, why did they encourage him to keep doing all this work over the years?

Their willingness to continue accepting his contributions and collaboration without giving him equal recognition reeks of exploitation. Exploitation is an element of any modern slavery prosecution. I have published a series of blogs looking at how exploitative situations arise in open source software.

There are two crucial pieces of evidence from the history of Enrico Zini, one of the Debian Account Managers:

First, in 2009, he asked Debian election candidates to each name five people they would like to censor and humiliate.

Please write a list of 5 Debian Developers you would like to kick out of the project.

Second, in 2018, Zini went to DebConf18 and gave a talk called "Multiple people" where he talks about having relationships with other men.

During the last year, I have been thinking passionately about things such as diversity, gender identity, sexual orientation, neurodiversity, and preserving identity in a group.

The last phrase, "preserving identity in a group", reveals a lot. Zini and other members of the group are screening Debian collaborators based on a very distorted worldview that only seems to tolerate the people they would be willing to sleep with.

Phil Wyett, being a former soldier and engineer, may have given the impression that he is not going to be an easy target for the social engineering culture and Code of Conduct gaslighting that has infected Debian in recent times.

Earlier this year there was significant publicity about the Zizian group. It is interesting to note that one of the Zizian victims was a border guard while Phil Wyett is a former soldier from the British Army's Royal Engineers.

David Maland, Phil Wyett, Debian, Zizian

 

US Border Patrol Agent David Maland, a US Air Force veteran, is pictured with a service dog. Phil Wyett, a British Army vet, is pictured with a regular house cat. Apart from the cat, they served their respective communities in a multitude of different ways.

Another Zizian victim was their landlord, Curtis Lind. The trial is ongoing. Mr Lind, pictured with a horse, lost one eye:

Curtis Lind, horse, Zizian

 

People who spend time developing software have rights under copyright law just as landlords have rights under real estate law.

The pattern of vicious attacks on authors, developers and landlords all suggest a significant disregard for the law and a sense of entitlement from people who operate in a pack, like dogs, barking at the rest of us.

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

Links, history of Phil Wyett's contributions

This is not a complete list.

Phil and Jay's web site.

Phil's blog.

Instagram.

Youtube.

Github

Gitlab

BuyMeACoffee.com profile and feedback from supporters

https://rpm.kathenas.org/ - Phil's RPM repository.

Phil's Ubuntu wiki profile has been edited between 2007 and 2009.

GNOME wiki profile and a snapshot in the Wayback machine tells us the page was first edited in 2014.

Phil's blog posts from 2017 where he mainly writes about CentOS.

CentOS wiki profile and a snapshot in the Wayback machine tells us the page was last edited in 2019.

Debian: kathenas-guest@alioth history from 2017 to 2019

Debian: kathenas history from 2017 to 2025

Debian wiki: history and old versions of the /PhilWyett page, which has been deleted. The page was first created in 2017 and maintained regularly until very recently.

Debian wiki: history and old versions of the /PhilWyett/DebianMentoring page, which has been deleted. The page was created in February 2025 and contains guidance for people Phil has been mentoring with the packaging process.

34 packages that Phil is maintaining (Wayback machine snapshot)

Debian new maintainer report - multiple attempts to be registered between February 2023 and December 2024

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

Phil Wyett, kathenas, Debian, packages

 

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

18 August, 2025 09:00PM

hackergotchi for Jonathan Dowland

Jonathan Dowland

Amiga redux

Matthew blogged about his Amiga CDTV project, a truly unique Amiga hack which also manages to be a novel Doom project (no mean feat: it's a crowded space)

This re-awakened my dormant wish to muck around with my childhood Amiga some more. When I last wrote about it (four years ago ☹) I'd upgraded the disk drive emulator with an OLED display and rotary encoder. I'd forgotten to mention I'd also sourced a modern trapdoor RAM expansion which adds 2MiB of RAM. The Amiga can only see 1.5MiB1 of it at the moment, I need perform a mainboard modification to access the final 512kiB2, which means some soldering.

[Amiga Test Kit](https://github.com/keirf/Amiga-Stuff) showing 2MiB RAM

Amiga Test Kit showing 2MiB RAM

What I had planned to do back then: replace the switch in the left button of the original mouse, which was misbehaving; perform the aformentioned mainboard mod; upgrade the floppy emulator wiring to a ribbon cable with plug-and-socket, for easier removal; fit an RTC chip to the RAM expansion board to get clock support in the OS.

However much of that might be might be moot, because of two other mods I am considering,

PiStorm

I've re-considered the PiStorm accelerator mentioned in Matt's blog.

Four years ago, I'd passed over it, because it required you to run Linux on a Raspberry Pi, and then an m68k emulator as a user-space process under Linux. I didn't want to administer another Linux system, and I'm generally uncomfortable about using a regular Linux distribution on SD storage over the long term.

However in the intervening years Emu68, a bare-metal m68k emulator has risen to prominence. You boot the Pi straight into Emu68 without Linux in the middle. For some reason that's a lot more compelling to me.

The PiStorm enormously expands the RAM visible to the Amiga. There would be no point in doing the mainboard mod to add 512k (and I don't know how that would interact with the PiStorm). It also can provide virtual hard disk devices to the Amiga (backed by files on the SD card), meaning the floppy emulator would be superfluous.

Denise Mainboard

I've just learned about a truly incredible project: the Denise Mini-ITX Amiga mainboard. It fitss into a Mini-ITX case (I have a suitable one spare already). Some assembly required. You move the chips from the original Amiga over to the Denise mainboard. It's compatible with the PiStorm (or vice-versa). It supports PC-style PS/2 keyboards (I have a Model M in the loft, thanks again Simon) and has a bunch of other modern conveniences: onboard RTC; mini-ITX power (I'll need something like a picoPSU too)

It wouldn't support my trapdoor RAM card but it takes a 72-pin DIMM which can supply 2MiB of Chip RAM, and the PiStorm can do the rest (they're compatible3).

No stock at the moment but if I could get my hands on this, I could build something that could permanently live on my desk.


  1. the Boobip board's 1.5MiB is "chip" RAM: accessible to the other chips on the mainboard, with access mediated by the AGNUS chip.
  2. the final 512kiB is "Fast" RAM: only accessible to the CPU, not mediated via Agnus.
  3. confirmation

18 August, 2025 05:52AM

August 17, 2025

hackergotchi for C.J. Adams-Collier

C.J. Adams-Collier

The Very Model of a Patriot Online

It appears that the fragile masculinity tech evangelists have identified Debian as a community with boundaries which exclude them from abusing its members and they’re so angry about it! In response to posts such as this, and inspired by Dr. Conway’s piece, I’ve composed a poem which, hopefully, correctly addresses the feelings of that crowd.


The Very Model of a Patriot Online

I am the very model of a modern patriot online,
My keyboard is my rifle and my noble cause is so divine.
I didn't learn my knowledge in a dusty college lecture hall,
But from the chans where bitter anonymity enthralls us all.
I spend a dozen hours every day upon my sacred quest,
To put the globo-homo narrative completely to the test.
My arguments are peer-reviewed by fellas in the comments section,
Which proves my every thesis is the model of complete perfection.
I’m steeped in righteous anger that the libs call 'white fragility,'
For mocking their new pronouns and their lack of masculinity.
I’m master of the epic troll, the comeback, and the searing snark,
A digital guerrilla who is fighting battles in the dark.

I know the secret symbols and the dog-whistles historical,
From Pepe the Frog to ‘Let’s Go Brandon,’ in order categorical;
In short, for fighting culture wars with rhetoric rhetorical,
I am the very model of a patriot polemical.

***

I stand for true expression, for the comics and the edgy clown,
Whose satire is too based for all the fragile folks in town.
They say my speech is 'violence' while my spirit they are trampling,
The way they try to silence me is really quite a startling sampling
Of 1984, which I've not read but thoroughly understand,
Is all about the tyranny that's gripping this once-blessed land.
My humor is a weapon, it’s a razor-bladed, sharp critique,
(Though sensitive elites will call my masterpiece a form of ‘hate speech’).
They cannot comprehend my need for freedom from all consequence,
They call it 'hate,' I call it 'jokes,' they just don't have a lick of sense.
So when they call me ‘bigot’ for the spicy memes I post pro bono,
I tell them their the ones who're cancelled, I'm the victim here, you know!

Then I can write a screed against the globalist cabal, you see,
And tell you every detail of their vile conspiracy.
In short, when I use logic that is flexible and personal,
I am the very model of a patriot controversial.

***

I'm very well acquainted with the scientific method, too,
It's watching lengthy YouTube vids until my face is turning blue.
I trust the heartfelt testimony of a tearful, blonde ex-nurse,
But what a paid fact-checker says has no effect and is perverse.
A PhD is proof that you've been brainwashed by the leftist mob,
While my own research on a meme is how I really do my job.
I know that masks will suffocate and vaccines are a devil's brew,
I learned it from a podcast host who used to sell brain-boosting goo.
He scorns the lamestream media, the CNNs and all the rest,
Whose biased reporting I've put fully to a rigorous test
By only reading headlines and confirming what I already knew,
Then posting my analysis for other patriots to view.

With every "study" that they cite from sources I can't stand to hear,
My own profound conclusions become ever more precisely clear.
In short, when I've debunked the experts with a confident "Says who?!",
I am the very model of a researcher who sees right through you.

***

But all these culture wars are just a sleight-of-hand, a clever feint,
To hide the stolen ballots and to cover up the moral taint
Of D.C. pizza parlors and of shipping crates from Wayfair, it’s true,
It's all connected in a plot against the likes of me and you!
I've analyzed the satellite photography and watermarks,
I understand the secret drops, the cryptic Qs, the coded sparks.
The “habbening” is coming, friends, just give it two more weeks or three,
When all the traitors face the trials for their wicked treachery.
They say that nothing happened and the dates have all gone past, you see,
But that's just disinformation from the globalist enemy!
Their moving goalposts constantly, a tactic that is plain to see,
To wear us down and make us doubt the coming, final victory!

My mind can see the patterns that a simple sheep could never find,
The hidden puppet-masters who are poisoning our heart and mind.
In short, when I link drag queens to the price of gas and child-trafficking,
I am the very model of a patriot whose brain is quickening!

***

My pickup truck's a testament to everything that I hold dear,
With vinyl decals saying things the liberals all hate and fear.
The Gadsden flag is waving next to one that's blue and starkly thin,
To show my deep respect for law, except the feds who're steeped in sin.
There's Punisher and Molon Labe, so that everybody knows
I'm not someone to trifle with when push to final shoving goes.
I've got my tactical assault gear sitting ready in the den,
Awaiting for the signal to restore our land with my fellow men.
I practice clearing rooms at home when my mom goes out to the store,
A modern Minuteman who's ready for a civil war.
The neighbors give me funny looks, I see them whisper and take note,
They'll see what's what when I'm the one who's guarding checkpoints by their throat.

I am a peaceful man, of course, but I am also pre-prepared,
To neutralize the threats of which the average citizen's unscared.
In short, when my whole identity's a brand of tactical accessory,
You'll say a better warrior has never graced a Cabela's registry.

***

They say I have to tolerate a man who thinks he is a dame,
While feminists and immigrants are putting out my vital flame!
There taking all the jobs from us and giving them to folks who kneel,
And "woke HR" says my best jokes are things I'm not allowed to feel!
An Alpha Male is what I am, a lion, though I'm in this cubicle,
My life's frustrations can be traced to policies Talmudical.
They lecture me on privilege, I, who have to pay my bills and rent!
While they give handouts to the lazy, worthless, and incompetent!
My grandad fought the Nazis! Now I have to press a key for ‘one’
To get a call-rep I can't understand beneath the blazing sun
Of global, corporate tyranny that's crushing out the very soul
Of men like me, who've lost their rightful, natural, and just control!

So yes, I am resentful! And I'm angry! And I'm right to be!
They've stolen all my heritage and my masculinity!
In short, when my own failures are somebody else's evil plot,
I am the very model of the truest patriot we've got!

***

There putting chips inside of you! Their spraying things up in the sky!
They want to make you EAT THE BUGS and watch your very spirit die!
The towers for the 5G are a mind-control delivery tool!
To keep you docile while the children suffer in a grooming school!
The WEF, and Gates, and Soros have a plan they call the 'Great Reset,'
You'll own no property and you'll be happy, or you'll be in debt
To social credit overlords who'll track your every single deed!
There sterilizing you with plastics that they've hidden in the feed!
The world is flat! The moon is fake! The dinosaurs were just a lie!
And every major tragedy's a hoax with actors paid to cry!
I'M NOT INSANE! I SEE THE TRUTH! MY EYES ARE OPEN! CAN'T YOU SEE?!
YOU'RE ALL ASLEEP! YOU'RE COWARDS! YOU'RE AFRAID OF BEING TRULY FREE!

My heart is beating faster now, my breath is short, my vision's blurred,
From all the shocking truth that's in each single, solitary word!
I've sacrificed my life and friends to bring this message to the light, so...
You'd better listen to me now with all your concentrated might, ho!

***

For my heroic struggle, though it's cosmic and it's biblical,
Is waged inside the comments of a post that's algorithm-ical.
And still for all my knowledge that's both tactical and practical,
My mom just wants the rent I owe and says I'm being dramatical.

17 August, 2025 09:21AM by C.J. Collier

August 16, 2025

hackergotchi for Bits from Debian

Bits from Debian

Debian turns 32!

Alt 32th Debian Day by Daniel Lenharo

On August 16, 1993, Ian Murdock announced the Debian Project to the world. Three decades (and a bit) later, Debian is still going strong, built by a worldwide community of developers, contributors, and users who believe in a free, universal operating system.

Over the years, Debian has powered servers, desktops, tiny embedded devices, and huge supercomputers. We have gathered at DebConfs, squashed countless bugs, shared late-night hacking sessions, and helped keep millions of systems secure.

Debian Day is a great excuse to get together, whether it is a local meetup, an online event, a bug squashing party, a team sprint or just coffee with fellow Debianites. Check out the Debian Day wiki to see if there is a celebration near you or to add your own.

Here is to 32 years of collaboration, code, and community, and to all the amazing people who make Debian what it is.

Happy Debian Day!

16 August, 2025 09:10AM by Debian Publicity Team

Birger Schacht

Updates and additions in Debian 13 Trixie

Last week Debian 13 (Trixie) was released and there have been some updates and additions in the packages that I maintain, that I wanted to write about. I think they are not worth of being added to the release notes, but I still wanted to list some of the changes and some of the new packages.

sway

Sway, the tiling Wayland compositor was version 1.7 in Bookworm. It was updated to version 1.10 (and 1.11 is already in experimental and waiting for an upload to unstable). This new version of sway brings, among a lot of other features, updated support for touchpad gestures and support for the ext-session-lock-v1 protocol, which allows for more robust and secure screen locking. The configuration snippet that activates the default sway background is now shipped in the sway-backgrounds package instead of being part of the sway package itself.

The default menu application was changed from dmenu to wmenu. wmenu is a Wayland native alternative to dmenu which I packaged and it is now recommended by sway.

There are some small helper tools for sway that were updated: swaybg was bumped from 1.2.0 to 1.2.1, swaylock was bumped from 1.7.2 to 1.8.2.

The grimshot script, which is a script for making screenshots, was part of the sway’s contrib folder for a long time (but was shipped as a separate binary package). It was removed from sway and is now part of the sway-contrib project. There are some other useful utilities in this source package that I might package in the future.

slurp, which is used by grimshot to select a region, was updated from version 1.4 to version 1.5.

labwc

I uploaded the first labwc package two years ago and I’m happy it is now part of a stable Debian release. Labwc is also based on wlroots, like sway. It is a window-stacking compositor and is inspired by openbox. I used openbox for a long time back in the day before I moved to i3 and I’m very happy to see that there is a Wayland alternative.

foot

Foot is a minimalistic and fast Wayland terminal emulator. It is mostly keyboard driven. foot was updated from version 1.13.1 to 1.21.0. The probably most important change for users updating might be the fact that:

  • Control+Shift+u is now bound to unicode-input instead of show- urls-launch, to follow the convention established in GTK and Qt
  • show-urls-launch now bound to Control+Shift+o

et cetera

The Wayland kiosk cage was updated from 0.1.4 to 0.2.0.

The waybar bar for wlroots compositors was updated from 0.9.17 to 0.12.0.

swayimg was updated from 1.10 to 3.8 and now brings support for custom key bindings, support for additional image types (PNM, EXR, DICOM, Farbfeld, sixel) and a gallery mode.

tofi, another dmenu replacement was updated from 0.8.1 to 0.9.1, wf-recorder a tool for screen recording in wlroots-based compositors, was updated from version 0.3 to version 0.5.0. wlogout was updated from version 1.1.1 to 1.2.2. The application launcher wofi was updated from 1.3 to 1.4.1. The lightweight status panel yambar was updated from version 1.9 to 1.11. kanshi, the tool for managing and automatically switching your output profiles, was updated from version 1.3.1 to version 1.5.1.

usbguard was updated from version 1.1.2 to 1.1.3.

added

  • fnott - a lightweight notification daemon for wlroots based compositors
  • fyi - a utility to send notifications to a notification daemon, similar to notify-send
  • pipectl - a tool to create and manage short-lived named pipes, this is a dependency of wl-present. wl-present is a script around wl-mirror which implements output mirroring for wlroots-based compositors
  • poweralertd - a small daemon that notifies you about the power status of your battery powered devices
  • wlopm - control power management of outputs
  • wlrctl - command line utility for miscellaneous wlroots Wayland extensions
  • wmenu - already mentioned, the new default launcher of sway
  • wshowkeys - shows keypresses in wayland sessions, nice for debugging
  • libsfdo - libraries implementing some freedesktop.org specs, used by labwc

16 August, 2025 05:28AM

August 15, 2025

hackergotchi for Steinar H. Gunderson

Steinar H. Gunderson

Abstract algebra structures made easy

Group theory, and abstract algebra in general, has many useful properties; you can take a bunch of really common systems and prove very useful statements that hold for all of them at once.

But sometimes in computer science, we just use the names, not really the theorems. If you're showing that something is a group) and then proceed to use Fermat's little theorem (perhaps to efficiently compute inverses, when it's not at all obvious what they would be), then you really can't go without the theory. But for some cases, we just love to be succinct in our description of things, and for outsiders, it's just… not useful.

So here's Steinar's easy (and more importantly, highly non-scientific; no emails about inaccuracies, please :-) ) guide to the most common abstract algebra structures:

  • Set: Hopefully you already know what this is. A collection of things (for instance numbers).
  • Semigroup: A (binary) operation that isn't crazy.
  • Monoid: An operation, but you also have a no-op.
  • Group: An operation, but you also have the opposite operation.
  • Abelian group: An operation, but the order doesn't matter.
  • Ring: Two operations; the Abelian group got a friend for Christmas. The extra operation might be kind of weird (for instance, has no-ops but might not always have opposites).
  • Field: A ring with some extra flexibility, so you can do almost whatever you are used to doing with “normal” (real) numbers except perhaps order them.

So for instance, assuming that x and y are e.g. positive integers (including zero), then max(x,y) (the motivating example for this post) is a monoid. Why? Because it's a non-crazy binary operation (in particular, max(max(x,y),z) = max(x,max(y,z))), and you can use x=0 or y=0 as a no-op (max(anything, 0) = anything). But it's not a group, because once you've done max(x,y), there's nothing you can max() with to get the smallest value back.

There are many more, but these are the ones you get today.

15 August, 2025 06:31PM

hackergotchi for Daniel Pocock

Daniel Pocock

Fête de l’Assomption, procession à Fourvière, Lyon, France

Donald Trump a peut-être mis un terme à la diversité, mais la fête de Marie demeure sacrée. Les Lyonnais ont bravé la canicule pour porter la statue de Marie sur la colline de Fourvière.

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7021.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7024.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7025.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7029.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7031.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7037.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7045.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7049.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7050.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7051.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7062.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7067.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7078.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7086.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7095.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7100.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7103.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7116.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7125.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7129.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7130.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7134.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7137.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7139.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7141.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7143.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7147.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7151.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7152.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7153.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7155.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7156.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7158.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7159.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7160.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7163.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7165.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7167.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7168.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7174.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7176.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7183.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7184.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7190.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7202.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7209.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7210.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7217.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7221.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7224.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7225.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7227.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7231.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7235.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7248.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7257.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7264.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7267.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7268.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7274.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7279.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7281.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7284.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7286.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7287.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7293.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7296.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7298.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7299.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7302.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7303.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7310.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7313.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7321.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7322.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7323.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7331.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7332.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7335.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7336.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7340.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7346.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7349.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7351.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7353.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7357.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7358.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7365.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7372.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7376.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7378.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7380.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7385.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7387.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7391.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7394.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7395.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7404.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7405.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7406.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7413.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7419.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7420.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7422.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7429.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7440.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7443.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7447.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7448.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7449.JPG


 

Blogs connexes sur l'église

Catholic.Community

Veuillez suivre le site web de Catholic.Community et en faire votre page d'accueil.

15 August, 2025 07:30AM

Feast of the Assumption, procession at Fourvière, Lyon, France

Donald Trump may have stopped diversity in its tracks but Mary's day remains sacred. The citizens of Lyon, France, braved a heat wave (canicule) to carry Mary's statue up the hill to the Fourvière.

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7021.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7024.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7025.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7029.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7031.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7037.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7045.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7049.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7050.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7051.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7062.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7067.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7078.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7086.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7095.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7100.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7103.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7116.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7125.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7129.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7130.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7134.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7137.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7139.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7141.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7143.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7147.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7151.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7152.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7153.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7155.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7156.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7158.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7159.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7160.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7163.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7165.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7167.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7168.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7174.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7176.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7183.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7184.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7190.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7202.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7209.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7210.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7217.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7221.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7224.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7225.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7227.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7231.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7235.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7248.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7257.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7264.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7267.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7268.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7274.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7279.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7281.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7284.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7286.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7287.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7293.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7296.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7298.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7299.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7302.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7303.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7310.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7313.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7321.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7322.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7323.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7331.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7332.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7335.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7336.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7340.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7346.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7349.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7351.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7353.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7357.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7358.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7365.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7372.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7376.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7378.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7380.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7385.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7387.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7391.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7394.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7395.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7404.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7405.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7406.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7413.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7419.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7420.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7422.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7429.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7440.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7443.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7447.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7448.JPG


 

Assumption, Procession, Monseigneur Patrick Le Gal, Fourvière, Lyon, France, 2025

Filename: DSC_7449.JPG


 

Related blogs about the church

Catholic.Community

Please follow the Catholic.Community web site and make it your home page.

15 August, 2025 07:30AM

August 14, 2025

hackergotchi for Jonathan McDowell

Jonathan McDowell

Local Voice Assistant Step 4: openWakeWord

People keep asking me when I’ll write the next instalment of my local voice assistant journey. I didn’t mean for it to be so long since the last one, things have been busier than I’d like. Anyway. Last time we’d built Tensorflow, so now it’s time to sort out openWakeWord. As a reminder we’re trying to put a local voice satellite on my living room Debian media machine.

The point of openWakeWord is to run on the machine the microphone is connected to, listening for the wake phrase (“Hey Jarvis” in my case), and only then calling back to the central server to do a speech to text operation. It’s wrapped up for Wyoming as wyoming-openwakeword.

Of course I’ve packaged it up - available at https://salsa.debian.org/noodles/wyoming-openwakeword. Trixie only released yesterday, so I’m still running all of this on bookworm. That means you need python3-wyoming from Trixie - 1.6.0-1 will install fine without needing rebuilt - and the python3-tflite-runtime we built last time.

Like the other pieces I’m not sure about how this could land in Debian; it’s unclear to me that the pre-trained models provided would be accepted in main.

As usual I start it with with a systemd unit file dropped in /etc/systemd/service/wyoming-openwakeword.service:

[Unit]
Description=Wyoming OpenWakeWord server
After=network.target

[Service]
Type=simple
DynamicUser=yes
ExecStart=/usr/bin/wyoming-openwakeword --uri tcp://[::1]:10400/ --preload-model 'hey_jarvis' --threshold 0.8

MemoryDenyWriteExecute=false
ProtectControlGroups=true
PrivateDevices=false
ProtectKernelTunables=true
ProtectSystem=true
RestrictRealtime=true
RestrictNamespaces=true

[Install]
WantedBy=multi-user.target

I’m still playing with the threshold level. It defaults to 0.5, but the device lives under the TV and seems to get a bit confused by it sometimes. There’s some talk about using speex for noise suppression, but I haven’t explored that yet (it’s yet another Python module to bind to the C libraries I’d have to look at).

This is a short one; next post is actually building the local satellite on top to tie everything together.

14 August, 2025 07:07PM

August 13, 2025

Sven Hoexter

Automated Browsing with Gemini and Chrome via BrowserMCP and gemini-cli

Brief dump so I don't forget how that worked in August 2025. Requires npm, npx and nodejs.

  1. Install Chrome
  2. Add the BrowserMCP extension
  3. Install gemini-cli npm install -g @google/gemini-cli
  4. Retrieve a Gemini API key via AI Studio
  5. Export API key for gemini-cli export GEMINI_API_KEY=2342
  6. Start BrowserMCP extension, see manual, an info box will appear that it's active with a cancel button.
  7. Add mcp server to gemini-cli gemini mcp add browsermcp npx @browsermcp/mcp@latest
  8. Start gemini-cli, let it use the mcp server and task it to open a website.

13 August, 2025 12:21PM

August 10, 2025

hackergotchi for Jonathan Carter

Jonathan Carter

Debian 13

Debian 13 has finally been released!

One of the biggest and under-hyped features is support for HTTP Boot. This allows you to simply specify a URL (to any d-i or live image iso) in your computer’s firmware setup and then you can boot to it directly over the Internet, so no need to download an image, write it to flash disk and then boot from the flash disk on computers made in the last ~5 years. This is also supported on the Tianocore free EFI firmware, which is useful if you’d like to try it out on QEMU/KVM.

More details about Debian 13 available on the official press release.

The default theme for Debian 13 is Ceratopsian, designed by Elise Couper. I’ll be honest, I wasn’t 100% sure it was the best choice when it won the artwork vote, but it really grew on me over the last few months, and it looked great in combination with all kinds of other things during DebConf too, so it has certainly won me over.

And I particularly like the Plymouth theme. It’s very minimal, and it reminds me of the Toy Story Trixie character, it’s almost like it helps explain the theme:

Plymouth (start-up/shutdown) theme.

Trixie, the character from Toy Story that was chosen as the codename for Debian 13.

Debian Local Team ISO testing

Yesterday we got some locals together for ISO testing and we got a cake with the wallpaper printed on it, along with our local team logo which has been a work in progress for the last 3 years, so hopefully we’ll finalise it this year! (it will be ready when it’s ready). It came out a lot bluer than the original wallpaper, but still tasted great.

For many releases, I’ve been the only person from South Africa doing ISO smoke-testing, and this time was quite different, since everyone else in the photo below tested an image except for me. I basically just provided some support and helped out with getting salsa/wiki accounts and some troubleshooting. It went nice and fast, and it’s always a big relief when there are no showstoppers for the release.

My dog was really wishing hard that the cake would slip off.

Packaging-wise, I only have one big new package for Trixie, and that’s Cambalache, a rapid application design UI builder for GTK3/GTK4.

The version in trixie is 0.94.1-3 and version 1.0 was recently released, so I’ll get that updated in forky and backport it if possible.

I was originally considering using Cambalache for an installer UI, but ended up going with a web front-end instead. But that’s moving firmly towards forky territory, so more on that another time!

Thanks to everyone who was involved in this release, so far upgrades have been very smooth!

10 August, 2025 02:53PM by jonathan

hackergotchi for C.J. Adams-Collier

C.J. Adams-Collier

Upgrading Proxmox 7 to 8

Some variant of the following[1] worked for me.

The first line is the start of a for loop that runs on each node in my cluster a command using ssh. The argument -t is passed to attach a controlling terminal to STDIN, STDERR and STDOUT of this session, since there will not be an intervening shell to do it for us. The argument to ssh is a workflow of bash commands. They upgrade the 7.x system to the most recent packages on the repository. We then update the sources.list entries for the system to point at bookworm sources instead of bullseye. The package cache is updated and the proxmox-ve package is installed. Packages which are installed are upgraded to the versions from bookworm, and the installer concludes.

Dear reader, you might be surprised how many times I saw the word “perl” scroll by during the manual, serial scrolling of this install. It took hours. There were a few prompts, so stand by the keyboard!

[1]

gpg: key 1140AF8F639E0C39: public key "Proxmox Bookworm Release Key " imported
# have your ssh agent keychain running and a key loaded that's installed at 
# ~root/.ssh/authorized_keys on each node 
apt-get install -y keychain
eval $(keychain --eval)
ssh-add ~/.ssh/id_rsa
# Replace the IP address prefix (100.64.79.) and  suffixes (64, 121-128)
# with the actual IPs of your cluster nodes.  Or use hostnames :-)
for o in 64 121 122 123 124 125 126 127 128 ; do   ssh -t root@100.64.79.$o '
  sed -i -e s/bullseye/bookworm/g /etc/apt/sources.list $(compgen -G "/etc/apt/sources.listd.d/*.list") \
  && echo "deb [signed-by=/usr/share/keyrings/proxmox-release.gpg] http://download.proxmox.com/debian/pve bookworm pve-no-subscription" \
    | dd of=/etc/apt/sources.list.d/proxmox-release.list status=none \
  && echo "deb [signed-by=/usr/share/keyrings/proxmox-release.gpg] http://download.proxmox.com/debian/ceph-quincy bookworm main no-subscription" \
    | dd of=/etc/apt/sources.list.d/ceph.list status=none \
  && proxmox_keyid="0xf4e136c67cdce41ae6de6fc81140af8f639e0c39" \
  && curl "https://keyserver.ubuntu.com/pks/lookup?op=get&search=${proxmox_keyid}" \
    | gpg --dearmor -o /usr/share/keyrings/proxmox-release.gpg  \
  && apt-get -y -qq update \
  && apt-get -y -qq install proxmox-ve \
  && apt-get -y -qq full-upgrade \
  && echo "$(hostname) upgraded"'; done

10 August, 2025 06:48AM by C.J. Collier

August 09, 2025

hackergotchi for Bits from Debian

Bits from Debian

Debian stable is now Debian 13 "trixie"!

Alt trixie has been released

We are pleased to announce the official release of Debian 13, codenamed trixie!

What's New in Debian 13

  • Official support for RISC-V (64-bit riscv64), a major architecture milestone
  • Enhanced security through ROP and COP/JOP hardening on both amd64 and arm64 (Intel CET and ARM PAC/BTI support)
  • HTTP Boot support in Debian Installer and Live images for UEFI/U-Boot systems
  • Upgraded software stack: GNOME 48, KDE Plasma 6, Linux kernel 6.12 LTS, GCC 14.2, Python 3.13, and more

Want to install it?

Fresh installation ISOs are now available, including the final Debian Installer featuring kernel 6.12.38 and mirror improvements. Choose your favourite installation media and read the installation manual. You can also use an official cloud image directly on your cloud provider, or try Debian prior to installing it using our "live" images.

Already a happy Debian user and you only want to upgrade?

Full upgrade path from Debian 12 "bookworm" is supported and documented in the Release Notes. Upgrade notes cover APT source preparation, handling obsoletes, and ensuring system resilience.

Additional Information

For full details, including upgrade instructions, known issues, and contributors, see the official Release Notes for Debian 13 "trixie".

Congratulations to all developers, QA testers, and volunteers who made Debian 13 "trixie" possible!

Do you want to celebrate the release?

To celebrate with us on this occassion find a release party near to you and if there isn't any, organize one!

09 August, 2025 09:30PM by Anupa Ann Joseph

hackergotchi for David Bremner

David Bremner

Using git-annex for email and notmuch metadata

Introducing git-remote-notmuch

Based on an idea and ruby implementation by Felipe Contreras, I have been developing a git remote helper for notmuch. I will soon post an updated version of the patchset to the notmuch mailing list (I wanted to refer to this post in my email). In this blog post I'll outline my experiments with using that tool, along with git-annex to store (and sync) a moderate sized email store along with its notmuch metadata.

WARNING

The rest of this post describes some relatively complex operations using (at best) alpha level software (namely git-remote-notmuch). git-annex is good at not losing your files, but git-remote-notmuch can (and did several times during debugging) wipe out your notmuch database. If you have a backup (e.g. made with notmuch-dump), this is much less annoying, and in particular you can decide to walk away from this whole experiment and restore your database.

Why git-annex?

I currently have about 31GiB of email, spread across more than 830,000 files. I want to maintain the ability to search and read my email offline, so I need to maintain a copy on several workstations and at least one server (which is backed up explicitly). I am somewhat commited to maintaining synchronization of tags to git since that is how the notmuch bug tracker works. Commiting the email files to git seems a bit wasteful: by design notmuch does not modify email files, and even with compression, the extra copy adds a fair amount of overhead (in my case, 17G of git objects, about 57% overhead). It is also notoriously difficult to completely delete files from a git repository. git-annex offers potential mitigation for these two issues, at the cost of a somewhat more complex mental model. The main idea is that instead of committing every version of a file to the git repository, git-annex tracks the filename and metadata, with the file content being stored in a key-value store outside git. Conceptually this is similar to git-lfs. From our current point, the important point is that instead of a second (compressed) copy of the file, we store one copy, along with a symlink and a couple of directory entries.

What to annex

For sufficiently small files, the overhead of a symlink and couple of directory entries is greater than the cost of a compressed second copy. When this happens depends on several variables, and will probably depend on the file content in a particular collection of email. I did a few trials of different settings for annex.largefiles to come to a threshold of largerthan=32k 1. For the curious, my experimental results are below. One potentially surprising aspect is that annexing even a small fraction of the (largest) files yields a big drop in storage overhead.

Threshold fraction annexed overhead
0 100% 30%
8k 29% 13%
16k 12% 9.4%
32k 7% 8.9%
48k 6% 8.9%
100k 3% 9.1%
256k 2% 11%
∞ (git) 0 % 57%

In the end I chose to err on the side of annexing more files (for the flexibility of deletion) rather than potentially faster operations with fewer annexed files at the same level of overhead.

Summarizing the configuration settings for git-annex (some of these are actually defaults, but not in my environment).

$ git config annex.largefiles largerthan=32k
$ git config annex.dotfiles true
$ git config annex.synccontent true

Delivering mail

To get new mail, I do something like

# compute a date based folder under $HOME/Maildir
$ dest = $(folder)
# deliver mail to ${dest} (somehow).
$ notmuch new
$ git -C $HOME/Maildir add ${folder}
$ git -C $HOME/Maildir diff-index --quiet HEAD ${folder} || git -C $HOME/Maildir commit -m 'mail delivery'

The call to diff-index is just an optimization for the case when nothing was delivered. The default configuration of git-annex will automagically annex any files larger than my threshold. At this point the git-annex repo knows nothing about tags.

There is some git configuration that can speed up the "git add" above, namely

$ git config core.untrackedCache true
$ git config core.fsmonitor true

See git-status(1) under "UNTRACKED FILES AND PERFORMANCE"

Defining notmuch as a git remote

Assuming git-remote-notmuch is somewhere in your path, you can define a remote to connect to the default notmuch database.

$ git remote add database notmuch::
$ git fetch database
$ git merge --allow-unrelated database

The --allow-unrelated should be needed only the first time.

In my case the many small files used to represent the tags (one per message), use a noticeable amount of disk space (in my case about the same amount of space as the xapian database).

Once you start merging from the database to the git repo, you will likely have some conflicts, and most conflict resolution tools leave junk lying around. I added the following .gitignore file to the top level of the repo

*.orig
*~

This prevents our cavalier use of git add from adding these files to our git history (and prevents pushing random junk to the notmuch database.

To push the tags from git to notmuch, you can run

$ git push database master

You might need to run notmuch new first, so that the database knows about all of the messages (currently git-remote-notmuch can't index files, only update metadata).

git annex sync should work with the new remote, but pushing back will be very slow 2. I disable automatic pushing as follows

$ git config remote.database.annex-push false

Unsticking the database remote

If you are debugging git-remote-notmuch, or just unlucky, you may end up in a sitation where git thinks the database is ahead of your git remote. You can delete the database remote (and associated stuff) and re-create it. Although I cannot promise this will never cause problems (because, computers), it will not modify your local copy of the tags in the git repo, nor modify your notmuch database.

$ git remote rm database
$ git update-rf -d notmuch/master
$ rm -r .git/notmuch

Fine tuning notmuch config

  • In order to avoid dealing with file renames, I have

      notmuch config maildir.synchronize_flags false
    
  • I have added the following to new.ignore:

       .git;_notmuch_metadata;.gitignore
    

  1. I also had to set annex.dotfiles to true, as many of my maildirs follow the qmail style convention of starting with a .
  2. I'm not totally clear on why it so slow, but certainly git-annex tries to push several more branches, and these are ignored by git-remote-annex.

09 August, 2025 12:21PM

Thorsten Alteholz

My Debian Activities in July 2025

Debian LTS

This was my hundred-thirty-third 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 4255-1] audiofile security update of two CVEs related to an integer overflow and a memory leak.
  • [DLA 4256-1] libetpan security update to fix one CVE related to prevent a null pointer dereference.
  • [DLA 4257-1] libcaca security update to fix two CVEs related to heap buffer overflows.
  • [DLA 4258-1] libfastjson security update to fix one CVE related to an out of bounds write.
  • [#1106867] kmail-account-wizard was marked as accepted

I also continued my work on suricata, which turned out to be more challenging than expected. This month I also did a week of FD duties and attended the monthly LTS/ELTS meeting.

Debian ELTS

This month was the eighty-fourth ELTS month. Unfortunately my allocated hours were far less than expected, so I couldn’t do as much work as planned.

Most of the time I spent with FD tasks and I also attended the monthly LTS/ELTS meeting. I further listened to the debusine talks during debconf. On the one hand I would like to use debusine to prepare uploads for embargoed ELTS issues, on the other hand I would like to use debusine to run the version of lintian that is used in the different releases. At the moment some manual steps are involved here and I tried to automate things. Of course like for LTS, I also continued my work on suricata.

Debian Printing

This month I uploaded a new upstream version of:

Guess what, I also started to work on a new version of hplip and intend to upload it in August.

This work is generously funded by Freexian!

Debian Astro

This month I uploaded new upstream versions of:

  • supernovas (sponsored upload to experimental)
  • calceph (sponsored upload to experimental)

I also uploaded the new package boinor. This is a fork of poliastro, which was retired by upstream and removed from Debian some months ago. I adopted it and rebranded it at the desire of upstream. boinor is the abbreviation of BOdies IN ORbit and I hope this software is still useful.

Debian Mobcom

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

misc

On my fight against outdated RFPs, I closed 31 of them in July. Their number is down to 3447 (how can you dare to open new RFPs? :-)). Don’t be afraid of them, they don’t bite and are happy to be released to a closed state.

FTP master

The peace will soon come to an end, so this month I accepted 87 and rejected 2 packages. The overall number of packages that got accepted was 100.

09 August, 2025 11:35AM by alteholz

August 06, 2025

Reproducible Builds

Reproducible Builds in July 2025

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

In this report:

  1. Reproducible Builds Summit 2025
  2. Reproducible Builds an official goal for SUSE Enterprise Linux
  3. Reproducible Builds at FOSSY 2025
  4. New OSS Rebuild project from Google
  5. New extension of Python setuptools to support reproducible builds
  6. diffoscope
  7. New library to patch system functions for reproducibility
  8. Independently Reproducible Git Bundles
  9. Website updates
  10. Distribution work
  11. Reproducibility testing framework
  12. Upstream patches

Reproducible Builds Summit 2025

We are extremely pleased to announce the upcoming Reproducible Builds Summit, set to take place from October 28th — 30th 2025 in Vienna, Austria!

We are thrilled to host the eighth edition of this exciting event, following the success of previous summits in various iconic locations around the world, including Venice, Marrakesh, Paris, Berlin, Hamburg and Athens. Our summits are a unique gathering that brings together attendees from diverse projects, united by a shared vision of advancing the Reproducible Builds effort.

During this enriching event, participants will have the opportunity to engage in discussions, establish connections and exchange ideas to drive progress in this vital field. Our aim is to create an inclusive space that fosters collaboration, innovation and problem-solving.

If you’re interesting in joining us this year, please make sure to read the event page which has more details about the event and location. Registration is open until 20th September 2025, and we are very much looking forward to seeing many readers of these reports there!


Reproducible Builds an official goal for SUSE Enterprise Linux

On our mailing list this month, Bernhard M. Wiedemann revealed the big news that reproducibility is now an official goal for SUSE Linux Enterprise Server (SLES) 16:

[Everything] changed earlier this year when reproducible-builds for SLES-16 became an official goal for the product. More people are talking about digital sovereignty and supply-chain security now. […] Today, only 9 of 3319 (source) packages have significant problems left (plus 7 with pending fixes), so 99.5% of packages have reproducible builds.


Reproducible Builds at FOSSY 2025

On Saturday 2nd August, Vagrant Cascadian and Chris Lamb presented at this year’s FOSSY 2025. Their talk, titled Never Mind the Checkboxes, Here’s Reproducible Builds!, was introduced as follows:

There are numerous policy compliance and regulatory processes being developed that target software development… but do they solve actual problems? Does it improve the quality of software? Do Software Bill of Materials (SBOMs) actually give you the information necessary to verify how a given software artifact was built? What is the goal of all these compliance checklists anyways… or more importantly, what should the goals be? If a software object is signed, who should be trusted to sign it, and can they be trusted … forever?

Hosted by the Software Freedom Conservancy and taking place in Portland, Oregon, USA, FOSSY aims to be a community-focused event: “Whether you are a long time contributing member of a free software project, a recent graduate of a coding bootcamp or university, or just have an interest in the possibilities that free and open source software bring, FOSSY will have something for you”. More information on the event is available on the FOSSY 2025 website, including the full programme schedule.

Vagrant and Chris also staffed a table, where they will be available to answer any questions about Reproducible Builds and discuss collaborations with other projects.


New OSS Rebuild project from Google

The Google Open Source Security Team (GOSST) published an article this month announcing OSS Rebuild, “a new project to strengthen trust in open source package ecosystems by reproducing upstream artifacts.” As the post itself documents, the new project comprises four facets:

  • Automation to derive declarative build definitions for existing PyPI (Python), npm (JS/TS), and Crates.io (Rust) packages.
  • SLSA Provenance for thousands of packages across our supported ecosystems, meeting SLSA Build Level 3 requirements with no publisher intervention.
  • Build observability and verification tools that security teams can integrate into their existing vulnerability management workflows.
  • Infrastructure definitions to allow organizations to easily run their own instances of OSS Rebuild to rebuild, generate, sign, and distribute provenance.

One difference with most projects that aim for bit-for-bit reproducibility, OSS Rebuild aims for a kind of “semantic” reproducibility:

Through automation and heuristics, we determine a prospective build definition for a target package and rebuild it. We semantically compare the result with the existing upstream artifact, normalizing each one to remove instabilities that cause bit-for-bit comparisons to fail (e.g. archive compression).

The extensive post includes examples about how to access OSS Rebuild attestations using the Go-based command-line interface.


New extension of Python setuptools to support reproducible builds

Wim Jeantine-Glenn has written a PEP 517 Build backend in order to enable reproducible builds when building Python projects that use setuptools.

Called setuptools-reproducible, the project’s README file contains the following:

Setuptools can create reproducible wheel archives (.whl) by setting SOURCE_DATE_EPOCH at build time, but setting the env var is insufficient for creating reproducible sdists (.tar.gz). setuptools-reproducible [therefore] wraps the hooks build_sdist build_wheel with some modifications to make reproducible builds by default.


diffoscope

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 301, 302 and 303 to Debian:

  • Improvements:

    • Use Difference.from_operation in an attempt to pipeline the output of the extract-vmlinux script, potentially avoiding it all in memory. []
    • Memoize a number of calls to --version, saving a very large number of external subprocess calls.
  • Bug fixes:

    • Don’t check for PyPDF version 3 specifically, check for versions greater than 3. []
    • Ensure that Java class files are named .class on the filesystem before passing them to javap(1). []
    • Mask stderr from extract-vmlinux script. [][]
    • Avoid spurious differences in h5dump output caused by exposure of absolute internal extraction paths. (#1108690)
  • Misc:

    • Use our_check_output in the ODT comparator. []
    • Update copyright years. []

In addition:

Lastly, Chris Lamb added a tmpfs to try.diffoscope.org so that diffoscope has a non-trivial temporary area to unpack archives, etc. []

Elsewhere in our tooling, however, reprotest is our tool for building the same source code twice in different environments and then checking the binaries produced by each build for any differences. This month, reprotest version 0.7.30 was uploaded to Debian unstable by Holger Levsen, chiefly including a change by Rebecca N. Palmer to not call sudo with the -h flag in order to fix Debian bug #1108550. []


New library to patch system functions for reproducibility

Nicolas Graves has written and published libfate, a simple collection of tiny libraries to patch system functions deterministically using LD_PRELOAD. According to the project’s README:

libfate provides deterministic replacements for common non-deterministic system functions that can break reproducible builds. Instead of relying on complex build systems or apps or extensive patching, libfate uses the LD_PRELOAD trick to intercept system calls and return fixed, predictable values.

Describing why he wrote it, Nicolas writes:

I originally used the OpenSUSE dettrace approach to make Emacs reproducible in Guix. But when Guix switch to GCC@14, dettrace stopped working as expected. dettrace is a complex piece of software, my need was much less heavy: I don’t need to systematically patch all sources of nondetermism, just the ones that make a process/binary unreproducible in a container/chroot.


Independently Reproducible Git Bundles

Simon Josefsson has published another interesting article this month. Titled Independently Reproducible Git Bundles, the blog post describes the advantages of why you might a reproducible bundle, and the pitfalls that can arise when trying to create them:

One desirable property is that someone else should be able to reproduce the same git bundle, and not only that a single individual is able to reproduce things on one machine. It surprised me to see that when I ran the same set of commands on a different machine (started from a fresh git clone), I got a different checksum. The different checksums occurred even when nothing had been committed on the server side between the two runs.


Website updates

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


Distribution work

In Debian this month:

Debian contributors have made significant progress toward ensuring package builds produce byte-for-byte reproducible results. You can check the status for packages installed on your system using the new package debian-repro-status, or visit reproduce.debian.net for Debian’s overall statistics for trixie and later. You can contribute to these efforts by joining #debian-reproducible on IRC to discuss fixes, or verify the statistics by installing the new rebuilderd package and setting up your own instance.


The IzzyOnDroid Android APK repository made further progress in July, crossing the 50% reproducibility threshold — congratulations. Furthermore, a new release of the Neo Store was released, which exposes the reproducible status directly next to the version of each app.


In GNU Guix, a series of patches intended to fix the reproducibility for the Mono programming language was merged, fixing reproducibility in Mono versions 1.9 [], 2.4 [] and 2.6 [].


Lastly, in addition to the news that openSUSE Enterprise Linux now [has an official goal of reproducibility]((https://lists.reproducible-builds.org/pipermail/rb-general/2025-July/003846.html), Bernhard M. Wiedemann posted another monthly update for their work there.


Reproducibility testing framework

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

  • Switch the URL for the Tails package set. []
  • Make the dsa-check-packages output more useful. []
  • Setup the ppc64el architecture again, has it has returned — this time with a 2.7 GiB database instead of 72 GiB. []

In addition, Jochen Sprickerhof improved the reproducibility statistics generation:

  • Enable caching of statistics. [][][]
  • Add some common non-reproducible patterns. []
  • Change output to directory. []
  • Add a page sorted by diffoscope size. [][]
  • Switch to Python’s argparse module and separate output(). []

Holger also submitted a number of Debian bugs against rebuilderd and rebuilderd-worker:

  • Config files and scripts for a simple one machine setup. [][]
  • Create a rebuilderd user. []
  • Create rebuilderd-worker user with sbuild. []

Lastly, Mattia Rizzolo added a scheduled job to renew some SSL certificates [] and Vagrant Cascadian performed some node maintenance [][].


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:

There were a number of other patches from openSUSE developers:



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:

06 August, 2025 08:56PM

hackergotchi for Colin Watson

Colin Watson

Free software activity in July 2025

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

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

DebConf

I attended DebConf for the first time in 11 years (my last one was DebConf 14 in Portland). It was great! For once I had a conference where I had a fairly light load of things I absolutely had to do, so I was able to spend time catching up with old friends, making some new friends, and doing some volunteering - a bit of Front Desk, and quite a lot of video team work where I got to play with sound desks and such. Apparently one of the BoFs (“birds of a feather”, i.e. relatively open discussion sessions) where I was talkmeister managed to break the automatic video cutting system by starting and ending precisely on time, to the second, which I’m told has never happened before. I’ll take that.

I gave a talk about Debusine, along with helping Enrico run a Debusine BoF. We still need to process some of the feedback from this, but are generally pretty thrilled about the reception. My personal highlight was getting a shout-out in a talk from CERN (in the slide starting at 32:55).

Other highlights for me included a Python team BoF, Ian’s tag2upload talk and some very useful follow-up discussions, a session on archive-wide testing, a somewhat brain-melting whiteboard session about the “multiarch interpreter problem”, several useful discussions about salsa.debian.org, Matthew’s talk on how Wikimedia automates their Debian package builds, and many others. I hope I can start attending regularly again!

OpenSSH

Towards the end of a release cycle, people tend to do more upgrade testing, and this sometimes results in interesting problems. Manfred Stock reported “No new SSH connections possible during large part of upgrade to Debian Trixie”, and after a little testing in a container I confirmed that this was a reproducible problem that would have affected many people upgrading from Debian 12 (bookworm), with potentially severe consequences for people upgrading remote systems. In fact, there were two independent problems that each led to much the same symptom:

  • OpenSSH 9.8 split the monolithic sshd listener process into two pieces: a minimal network listener (still called sshd), and an sshd-session process dealing with each individual session. (OpenSSH 10.0 further split sshd-session, adding an sshd-auth process that deals with the user authentication phase of the protocol.) This hardens the OpenSSH server by using different address spaces for privileged and unprivileged code.

    Before this change, when sshd received an incoming connection, it forked and re-executed itself with some special parameters to deal with it. After this change, it forks and executes sshd-session instead, and sshd no longer accepts the parameters it used to accept for this.

    Debian package upgrades happen in two phases: first we unpack the new files onto disk, and then we run some package-specific configuration steps which usually include things like restarting services. (I’m simplifying, but this is good enough for this post.) Normally this is fine, and in fact desirable: the old service keeps on working, and this approach often allows breaking what would otherwise be difficult cycles by ensuring that the system is in a more coherent state before trying to restart services. However, in this case, unpacking the new files onto disk immediately means that new SSH connections no longer work: the old sshd receives the connection and tries to hand it off to a freshly-executed copy of the new sshd binary on disk, which no longer supports this.

    If you’re just upgrading OpenSSH on its own or with a small number of other packages, this isn’t much of a problem as the listener will be restarted quite soon; but if you’re upgrading from bookworm to trixie, there may be a long gap when you can’t SSH to the system any more, and if something fails in the middle of the upgrade then you could be in trouble.

    So, what to do? I considered keeping a copy of the old sshd around temporarily and patching the new sshd to re-execute it if it’s being run to handle an incoming connection, but that turned out to fail in my first test: dependencies are normally only checked when configuring a package, so it’s possible to unpack openssh-server before unpacking a newer libc6 that it depends on, at which point you can’t execute the new sshd at all. (That also means that the approach of restarting the service at unpack time instead of configure time is a non-starter.) We needed a different idea.

    dpkg, the core Debian package manager, has a specialized facility called “diversions”: you can tell it that when it’s unpacking a particular file it should put it somewhere else instead. This is normally used by administrators when they want to install a locally-modified version of a particular file at their own risk, or by packages that knowingly override a file normally provided by some other package. However, in this case it turns out to be useful for openssh-server to temporarily divert one of its own files! When upgrading from before 9.8, it now diverts /usr/sbin/sshd to /usr/sbin/sshd.session-split before the new version is unpacked, then removes the diversion and moves the new file into place once it’s ready to restart the service; this reduces the period when incoming connections fail to a minimum. (We actually have to pretend that the diversion is being performed on behalf of a slightly different package since we’re using dpkg-divert in a strange way here, but it all works.)

  • Most OpenSSH processes, including sshd, check for a compatible version of the OpenSSL library when they start up. This check used to be very picky, among other things requiring both the major and minor number to match. OpenSSL 3 has a better versioning policy, and so OpenSSH 9.4p1 relaxed this check.

    Unfortunately, bookworm shipped with OpenSSH 9.2p1, which means that as soon as you unpack the new libssl3 during an upgrade (actually libssl3t64 due to the 64-bit time_t transition), sshd stops working. This couldn’t be fixed by a change in trixie; we needed to change bookworm in advance of the upgrade so that it would tolerate newer versions of OpenSSL. And time was tight if we wanted to maximize the chance that people would apply that stable update before upgrading to trixie; there isn’t going to be another point release of Debian 12 before the release of Debian 13.

    Fortunately, there’s a stable-updates mechanism for exactly this sort of thing, and the stable release managers kindly accepted my proposal to fix this there.

The net result is that if you apply updates to bookworm (including stable-updates / bookworm-updates, which is enabled by default) before starting the upgrade to trixie, everything should be fine. Many thanks to Manfred for reporting this with just enough time to spare that we were able to fix it before Debian 13 is released in a few days!

debmirror

I did my twice-yearly refresh of debmirror’s mirror_size documentation, and applied a patch from Christoph Goehre to improve mirroring of installer files.

madison-lite

I proposed renaming this project along with the rmadison tool in devscripts, although I’m not yet sure what a good replacement name would be.

Python team

I upgraded python-expandvars, python-typing-extensions (in experimental), and webtest to new upstream versions.

I backported fixes for some security vulnerabilities to unstable:

I fixed or helped to fix a number of release-critical bugs:

I fixed some other bugs, mostly Severity: important:

I reinstated python3-mastodon’s build-dependency on and recommendation of python3-blurhash, now that the latter has been fixed to use the correct upstream source.

06 August, 2025 10:41AM by Colin Watson

hackergotchi for Matthew Palmer

Matthew Palmer

I'm trying an open source funding experiment

As I’m currently somewhat underemployed, and could do with some extra income, I’m starting an open source crowd-funding experiment. My hypothesis is that the open source community, and perhaps a community-minded company or two, really wants more open source code in the world, and is willing to put a few dollars my way to make that happen.

To begin with, I’m asking for contributions to implement a bunch of feature requests on action-validator, a Rust CLI tool I wrote to validate the syntax of GitHub actions and workflows. The premise is quite simple: for every AU$150 (about US$100) I receive in donations, I’ll implement one of the nominated feature requests. If people want a particular feature implemented, they can nominate a feature in their donation message, otherwise when “general” donations get to AU$150, I’ll just pick a feature that looks interesting. More details are on my code fund page.

In the same spirit of simplicity, donations can be made through my Ko-fi page, and I’ll keep track of the various totals in a hand-written HTML table.

So, in short, if you want more open source code to exist, now would be a good time to visit my Ko-fi page and chip in a few dollars. If you’re curious to know more, my code fund page has a list of Foreseeably Anticipated Questions that might address your curiosity. Otherwise, ask your questions in the comments or email me.

06 August, 2025 12:00AM by Matt Palmer (mpalmer@hezmatt.org)