2026 already! The winter weather here has really been beautiful and I always enjoy
this time of year. Writing this yearly musical retrospective has now become a
beloved tradition of mine1 and I enjoy retracing the year's various
events through albums I listened to and concerts I went to.
Albums
In 2025, I added 141 new albums to my collection, around 60% more than last
year's haul. I think this might have been too much? I feel like I didn't have
time to properly enjoy all of them and as such, I decided to slow down my
acquisition spree sometimes in early December, around the time I normally do the
complete opposite.
This year again, I bought the vast majority of my music on Bandcamp. Most of
the other albums I bought as CDs and ripped them.
Concerts
In 2025, I went to the following 25 (!!) concerts:
January 17th: Uzu, Young Blades, She came to quit, Fever Visions
February 1st: Over the Hill, Jail, Mortier, Ain't Right
February 7th: B ton Arm , Mulchulation II, Ooz
February 15th: The Prowlers, Ultra Razzia, Sistema de Muerte,
Trauma Bond
February 28th: Francb tards
March 28th: Conflit Majeur, to Even Exist, Crachat
April 12th: Jetsam, Mortier, NIIVI, Canette
April 26th-27th (Montreal Oi! Fest 2025): The
Buzzers, Bad Terms, Sons of Pride, Liberty and Justice, Flafoot 56, The
Beltones, Mortier, Street Code, The Stress, Alternate Action
May 1st: Bauxite, Atomic threat, the 351's
May 30th: Uzu, Tenaz, Extra a Humana, Sistema de muerte
June 7th: Ordures Ioniques, Tulaviok, Fucking Raymonds, Voyou
June 18th: Tiken Jah Fakoly
June 21st: Sa an Supa Celebration
June 26th: Taxi Girls, Death Proof, Laura Krieg
July 4th: Frente Cumbiero
July 12th: Montreal's Big Fiesta DJ Set
August 16th: Guerilla Poubelle
September 11th: No Suicide Act, Mortier
September 20th: Hors Contr le, Union Thugs, Barricade Mentale
October 20th: Ezra Furman, The Golden Dregs
October 24th: Overbass, Hommage B rurier Noir, Self Control,
Vermin Kaos
November 6th: B ton Arm , Faze, Slash Need, Chain Block
November 28th (Blood Moon Ritual 2025): Bhatt, Channeler,
Pyrocene Death Cult, Masse d'Armes
December 13th (Stomp Records' 30th Anniversary Bash):
The Planet Smashers, The Flatliners, Wine Lips, The Anti-Queens, Crash ton
rock
Although I haven't touched metalfinder's code in a good while, my instance
still works very well and I get the occasional match when a big-name artist in
my collection comes in town. Most the venues that advertise on Bandsintown are
tied to Ticketmaster though, which means most underground artists (i.e. most of
the music I listen to) end up playing elsewhere.
As such, shout out again to the Gancio project and to the folks running the
Montreal instance. It continues to be a smash hit and most of
the interesting concerts end up being advertised there.
See you all in 2026!
December 2025 started off with a nice event, namely a small gathering of Vienna
based DDs. Some of us were at DebConf25 in
Brest and we thought it might be nice to have a get-together of DDs in Vienna.
A couple of months after DebConf25 I picked up the idea, let someone else
ping the DDs, booked a table at a local cafe and in the end we were a group of
6 DDs. It was nice to put faces to names, names to nicknames and to hear what
people are up to. We are definitely planning to repeat that!
December also ended with a meeting of nerds: the 39th Chaos Communication
Congress in Hamburg.
As usual, I did not really have that much time to watch many talks. I tend to
bookmark a lot of them in the scheduling app in advance, but once I m at the
congress the social aspect is much more important and I try to only attend
workshop or talks that are not recorded. Watching the recordings afterward is
possible anyway (and I actually try to do that!).
There was also a Debian Developers meetup at day 3, combined with the usual
time confusion regarding UTC and CET. We talked about having a Debian table at
40c3, so maybe the timezone won t be that much of a problem in the next time.
Two talks I recommend are CSS Clicker Training: Making games in a styling
language
and To sign or not to sign: Practical vulnerabilities in GPG &
friends.
Regarding package uploads this month did not happen that much, I only uploaded
the new version (0.9.3) of labwc.
I created two new releases for carl. First a
0.5 release that adds Today and SpecifiedDate as properties. I forwarded an
issue about dates not being parsed correctly to the icalendar issue
tracker and this was fixed a
couple of days later (thanks!). I then created a 0.5.1 release containing that
fix. I also started planning to move the carl repository back to codeberg,
because Github feels more and more like an AI Slop platform.
The work on debiverse also continued. I removed the tailwind CSS framework,
and it was actually not that hard to reproduce all the needed CSS classes with
custom CSS. I think that CSS frameworks make sense to a point, but once you
start implementing stuff that the framework does not provide, it is easier if
everything comes out of one set of rules. There was also the article Vanilla
CSS is all you
need which goes
into the same direction and which gave me some ideas how to organize the CSS
directives.
I also refactored the filter generation for the listing filters and the HTML
filter form is now generated from the FastAPI Query Parameter
Model.
For navigation I implemented a sidebar, that is hidden on small screens but can
be toggled using a burger menu.
I also stumbled upon An uncomfortable but necessary discussion about the
Debian bug
tracker,
which raises some valid points. I think debiverse could be a solution to the
first point of What could be a way forward? , namely: Create a new web
service that parses the existing bug data and displays it in a rich format .
But if there is ever another way than email to interact with bugs.debian.org,
than this approach should not rely on passing on the commands via mail. If
I click a button in a web interface to raise the severity, the severity should
be raised right away - not 10 minutes later when the email is received. I think
the individual parts (web, database, mail interface) should be decoupled and
talk to each other via APIs.
In 2025, I finished and reviewed 32 books, not counting another five books
I've finished but not yet reviewed and which will therefore roll over to
2026.
This was not a great reading year, although not my worst reading year
since I started keeping track. I'm not entirely sure why, although part of
the explanation was that I hit a bad stretch of books in spring of 2025
and got into a bit of a reading slump. Mostly, though, I shifted a lot of
reading this year to short non-fiction (newsletters and doom-scrolling)
and spent rather more time than I intended watching YouTube videos, and
sadly each hour in the day can only be allocated one way.
This year felt a bit like a holding pattern. I have some hopes of being
more proactive and intentional in 2026. I'm still working on finding a
good balance between all of my hobbies and the enjoyment of mindless
entertainment.
The best book I read this year was also the last book I reviewed (and yes,
I snuck the review under the wire for that reason): Bethany Jacobs's
This Brutal Moon,
the conclusion of the Kindom Trilogy that started with
These Burning Stars.
I thought the first two books of the series were interesting but flawed,
but the conclusion blew me away and improved the entire trilogy in
retrospect. Like all books I rate 10 out of 10, I'm sure a large part of
my reaction is idiosyncratic, but two friends of mine also loved the
conclusion so it's not just me.
The stand-out non-fiction book of the year was Rory Stewart's
Politics on the
Edge. I have a lot of disagreements with Stewart's political positions
(the more I listen to him, the more disagreements I find), but he is an
excellent memoirist who skewers the banality, superficiality, and contempt
for competence that has become so prevailing in centrist and right-wing
politics. It's hard not to read this book and despair of electoralism and
the current structures of governments, but it's bracing to know that even
some people I disagree with believe in the value of expertise.
I also finished Suzanne Palmer's excellent Finder Chronicles series,
reading The Scavenger
Door and Ghostdrift. This series is some of the best science fiction I've
read in a long time and I'm sad it is over (at least for now). Palmer has
a new, unrelated book coming in 2026 (Ode to the Half-Broken), and
I'm looking forward to reading that.
This year, I experimented with re-reading books I had already reviewed for
the first time since I started writing reviews. After my reading slump, I
felt like revisiting something I knew I liked, and therefore re-read C.J.
Cherryh's Cyteen and
Regenesis.
Cyteen mostly held up, but Regenesis was worse than I had
remembered. I experimented with a way to add on to my previous reviews,
but I didn't like the results and the whole process of re-reading and
re-reviewing annoyed me. I'm counting this as a failed experiment, which
means I've still not solved the problem of how to revisit series that I
read long enough ago that I want to re-read them before picking up the new
book. (You may have noticed that I've not read the new Jacqueline Carey
Kushiel novel, for example.)
You may have also noticed that I didn't start a new series re-read, or
continue my semi-in-progress re-reads of Mercedes Lackey or David Eddings.
I have tentative plans to kick off a new series re-read in 2026, but I'm
not ready to commit to that yet.
As always, I have no firm numeric goals for the next year, but I hope to
avoid another reading slump and drag my reading attention back from
lower-quality and mostly-depressing material in 2026.
The full analysis includes some
additional personal reading statistics, probably only of interest to me.
The majority of P r ch ( ) is stored in Asia (predominantly China, some in Malaysia and Taiwan) because of its climatic conditions:
warm (~30 C)
humid (~75% RH)
stable (comparatively small day to day, day to night, and seasonal differences)
These are ideal for ageing and allow efficient storage in simple storehouses, usually without the need for any air conditioning.
The climate in Western European countries is significantly colder, drier, and more variable. However, residential houses offers throughout the year a warm (~20 C), humid (~50% RH), and stable baseline to start with. High quality, long term storage and ageing is possible too with some of the Asian procedures slightly adjusted for the local conditions. Nevertheless, fast accelerated ageing still doesn t work here (even with massive climate control).
Personally I prefer the balanced, natural storage over the classical wet or dry , or the mixed traditional storage (of course all storage types are not that meaningful as they are all relative terms anyway). Also I don t like strong fermentation either (P r is not my favourite tea, I only drink it in the 3 months of winter).
Therefore, my intention is primarily to preserve the tea while it continues to age normally, keep it in optimal drinking condition and don t rush its fermentation.
The value of correct storage is of great importance and has a big effect on P r, and is often overlooked and underrated. Here s a short summary on how to store P r ch (in Western Europe).
Image: some D y P r ch stored at home
1. Location
1.1 No light
Choose a location with neither direct nor indirect sunlight (= ultraviolet radiation) exposure:
direct sunlight damages organic material ( bleeching )
indirect sunlight by heating up the containers inbalances the microclimate ( suppression )
1.2 No odors
Choose a location with neither direct nor indirect odor exposure:
direct odor immissions (like incense, food, air polution, etc.) makes the tea undrinkable
indirect odor immissions (especially other teas stored next to it) taint the taste and dilute the flavours
Always use individual containers for each tea, store only identical tea of the same year and batch in the same container. Idealy never store one cake, brick or tuo on its own, buy multiples and store them together for better ageing.
2. Climate
2.1 Consistent temperature
Use a location with no interference from any devices or structures next to it:
use an regular indoor location for mild temperature curves (i.e. no attics with large day/night temperature differences)
aim for >= 20 C average temperature for natural storage (i.e. no cold basements)
don t use a place next to any heat dissipating devices (like radiators, computers, etc.)
don t use a place next to an outside facing wall
always leave 5 to 10cm distance to a wall for air to circulate (generally prevents mold on the wall but also isolates the containers further from possible immissions)
As consistent temperature as possible allows even and steady fermentation. However, neither air conditioning or filtering is needed. Regular day to day, day to night, and season to season fluctuations are balanced out fine with otherwise correct indoor storage. Also humidity control is much more important for storage and ageing, and much less forgiving than temperature control.
2.2 Consistent humidity
Use humidity control packs to ensure a stable humidity level:
aim for ~65% RH
Lower than 60% RH will (completely) dry out the tea, higher than 70% RH increases chances for mold.
3. Equipment
3.1 Proper containers
Use containers that are long term available and that are easily stackable, both in form and dimensions as well as load-bearing capacity. They should be inexpensive, otherwise it s most likely scam (there are people selling snake-oil containers specifically for tea storage).
For long term storage and ageing:
never use plastic: they leak chemicals over time (no tupperdors , mylar and zip lock bags, etc.)
never use cardboard or bamboo: they let to much air in, absorb too much humity and dry to slow
never use wood: they emit odors (no humidors)
never use clay: they absorb all humidity and dry out the tea (glazed or porcelain urns are acceptable for short term storage)
Always use sealed but not air tight, cleaned steal cans (i.e. with no oil residues from manufacturing; such as these).
3.2 Proper humidity control
Use two-way humidity control packs to either absorb or add moisture depending on the needs:
3.3 Proper labels
Put labels on the outside of the containers to not need to open them to know what is inside and disturbe the ageing:
write at least manufacturer and name, pressing year, and batch number on the label (such as these)
if desired and not otherwise kept track already elsewhere, add additional information such as the amount of items, weights, previous storage location/type, date of purchase, vendor, or price, etc.
3.4 Proper monitoring
Measuring and checking temperature and humidity regularly prevents storage parameters turning bad going unnoticed:
put temperature and humidity measurement sensors (such as these) inside some of the containers (e.g. at least one in every different size/type of container)
keep at least one temperature and humidity measurement sensor next to the containers on the outside to monitor the storage location
4. Storage
4.1 Continued maintenance
Before beginning to initially store a new tea, let it acclimatize for 2h after unpacking from transport (or longer if temperature differences between indoors and outdoors are high, i.e. in winter).
Then continuesly:
once a month briefly air all containers for a minute or two
once a month check for mold, just to be safe
every 3 to 6 months check all humidity control packs for need of replacement
monitor battery life of temperature and humidity measurement sensors
Humidity control packs can be recharged (usually voiding any warranty) by submerging them for 2 days in distilled water and 4 hours drying on paper towl afterwards. Check with a weight scale after recharging, they should regain their original weight (e.g. 60g plus ~2 to 5g for the packaging).
Finally
With a correct P r ch storage:
beginn to drink Sh ng P r ( ) roughly after about 10-15 years, or later
beginn to drink Sh u P r ( ) roughly after about 3-5 years, or later
Prepare the tea by breaking it into, or breaking off from it, ~5 to 10g pieces about 1 to 3 months ahead of drinking and consider increase humidity to 70% RH during that time.
2026
As announced in
Brest, France,
in July, the Debian Conference is heading to Santa Fe, Argentina.
The DebConf26 team and the local organizers team in Argentina are excited to
announce
Debconf26 dates, the 27th edition of the Debian Developers and
Contributors Conference:
DebCamp, the annual hacking session, will
run from Monday July 13th to Sunday to July 19th 2026, followed by DebConf
from Monday July 20th to Saturday July 25th 2026.
For all those who wish to meet us in Santa Fe, the next step will be the
opening of registration on January 26, 2026. The call for proposals period
for anyone wishing to submit a conference or event proposal will be launched
on the same day.
DebConf26 is looking for sponsors; if you are interested or think you know of
others who would be willing to help, please have a look at our sponsorship
page and get in
touch with sponsors@debconf.org.
About Debian
The Debian Project was founded in 1993 by Ian Murdock to be a truly free
community project. Since then the project has grown to be one of the
largest and most influential Open Source projects. Thousands of
volunteers from all over the world work together to create and maintain
Debian software. Available in 70 languages, and supporting a huge range
of computer types, Debian calls itself the universal operating system.
About DebConf
DebConf is the Debian Project's developer conference. In addition to a
full schedule of technical, social and policy talks, DebConf provides an
opportunity for developers, contributors and other interested people to
meet in person and work together more closely. It has taken place
annually since 2000 in locations as varied as Scotland, Bosnia and Herzegovina,
India, Korea. More information about DebConf is available from
https://debconf.org/.
For further information, please visit the DebConf26 web page at
https://debconf26.debconf.org/ or send
mail to press@debian.org.
Debconf26 is made possible by Proxmox and others.
Disappointments this year included 28 Years Later (Danny Boyle, 2025), Cover-Up (Laura Poitras & Mark Obenhaus, 2025), Bugonia (Yorgos Lanthimos, 2025) and Caught Stealing (Darren Aronofsky, 2025).
Older releases
ie. Films released before 2024, and not including rewatches from previous years.
Here s my monthly but brief update about the activities I ve done in the FOSS world.
Debian
Whilst I didn t get a chance to do much, here are still a few things that I worked on:
Prepared security update for wordpress for trixie and bookworm.
A few discussions with the new DFSG team, et al.
Assited a few folks in getting their patches submitted via Salsa.
Mentoring for newcomers.
Moderation of -project mailing list.
Ubuntu
I joined Canonical to work on Ubuntu full-time back in February 2021.
Whilst I can t give a full, detailed list of things I did, here s a quick TL;DR of what I did:
ceph: Affected by CVE-2024-47866, using the argument x-amz-copy-source to put an object and specifying an empty string as its content leads to the RGW daemon crashing, resulting in a DoS attack.
[LTS]: Whilst the patch is straightforward, backports are a bit tricky. Also trying to backport the fix for CVE-2022-0670. The update has been prepared as of December 16th and awaiting Thomas Goirand s review.
knot-resolver: Affected by CVE-2023-26249, CVE-2023-46317, and CVE-2022-40188, leading to Denial of Service.
[LTS]: The patches aren t very trivial, with
CVE-2023-46317 reverting much of the patch for CVE-2023-26249. And then it had to be re-adjusted a bit for v5.3.1. The backports are ready as of December 23rd and awaiting Jakub or Santiago s review.
adminer: Affected by CVE-2023-45195 and CVE-2023-45196, leading to SSRF and DoS, respectively.
[ELTS]: I picked it up again and the patches were already ready in Git. I ve reached out to Alexandre for a quick review and smoke test before we can release it for buster.
u-boot: Affected by CVE-2025-24857, where boot code access control flaw in U-Boot allowing arbitrary code execution via physical access.
[ELTS]: As it s only affected the version in stretch, I ve started the work to find the fixing commits and prepare a backport. Not much progress there, I ll roll it over to January.
ruby-rack: There were multiple vulnerabilities reported in Rack, leading to DoS (memory exhaustion) and proxy bypass.
[ELTS]: After completing the work for LTS myself, Bastien picked it up for ELTS and reached out about an upstream regression and we ve been doing some exchanges. Bastien has done most of the work backporting the patches but needs a review and help backporting CVE-2025-61771.
Other Activities
Frontdesk from 01-12-2025 to 07-12-2025.
Auto EOL d a bunch of packages.
Marked CVE-2025-12084/python2.7 as end-of-life for bullseye, buster, and stretch.
Marked CVE-2025-12084/jython as end-of-life for bullseye.
Marked CVE-2025-13992/chromium as end-of-life for bullseye.
Marked apache2 CVEs as postponed for bullseye, buster, and stretch.
Marked CVE-2025-13654/duc as postponed for bullseye and buster.
Marked CVE-2025-32900/kdeconnect as ignored for bullseye.
Marked CVE-2025-12084/pypy3 as postponed for bullseye.
Marked CVE-2025-14104/util-linux as postponed for bullseye, buster, and stretch.
Marked several CVEs for fastdds as postponed for bullseye.
Marked several CVEs for pytorch as postponed for bullseye.
Marked CVE-2025-2486/edk2 as postponed for bullseye.
Marked CVE-2025-6172 7,9 /golang-1.15 as postponed for bullseye.
Marked CVE-2025-65637/golang-logrus as postponed for bullseye.
Marked CVE-2025-12385/qtdeclarative-opensource-src ,gles as postponed for bullseye, buster, and stretch.
Marked TEMP-0000000-D08402/rust-maxminddb as postponed for bullseye.
Added the following packages to d,e la-needed.txt:
liblivemedia, sogo.
During my triage, I had to make the bin/elts-eol script robust to determine the lts_admin repository - did a back and forth with Emilio about this on the list.
I claimed php-horde-css-parser to work on CVE-2020-13756 for buster and did almost all the work only to realize that the patch already existed in buster and the changelog confirmed that it was intentionally fixed.
After speaking with Andreas Henriksson, we figured that the CVE ID was missed when the ELA was generated and so I fixed that via 87afaaf19ce56123bc9508d9c6cd5360b18114ef and 5621431e84818b4e650ffdce4c456daec0ee4d51 in the ELTS security tracker to reflect the situation.
Participated in a thread which I started last month around using Salsa CI for E/LTS packages and if we plan to sunset it in favor of using Debusine. The plan for now is to keep it around as it s still beneficial and Debusine is still in its early phase.
Did a lot of back and forth with Helmut about debusine uploads on #debian-elts.
While debugging a failure in dcut uploads, I ran into an SSH compatibility issue on deb-master.freexian.com that could be fixed on the server-side. I shared all my findings to Freexian s sysadmin team.
A minimal fix on the server side would be one of:
PubkeyAcceptedAlgorithms -ssh-dss
or explicitly restricting to modern algorithms, e.g.:
Jelly on #debian-lts reported that all my DLA mails had broken GMail s DKIM signature. So I set up sending replies from @debian.org and that seems to have fixed that! \o/
[LTS] Attended a rather short monthly LTS meeting on Jitsi. Summary here.
[E/LTS] Monitored discussions on mailing lists, IRC, and all the documentation updates.
## 0.23 2025-12-20
commit be15aa25dea40aea66a8534143fb81b29d2e6c08
Author: C.J. Collier
Date: Sat Dec 20 22:40:44 2025 +0000
Fixes C-level test infrastructure and adds more test cases for upb_to_sv conversions.
- **Makefile.PL:**
- Allow extra_src in c_test_config.json to be an array.
- Add ASan flags to CCFLAGS and LDDLFLAGS for better debugging.
- Corrected echo newlines in test_c target.
- **c_test_config.json:**
- Added missing type test files to deps and extra_src for convert/sv_to_upb and convert/upb_to_sv test runners.
- **t/c/convert/upb_to_sv.c:**
- Fixed a double free of test_pool .
- Added missing includes for type test headers.
- Updated test plan counts.
- **t/c/convert/sv_to_upb.c:**
- Added missing includes for type test headers.
- Updated test plan counts.
- Corrected Perl interpreter initialization.
- **t/c/convert/types/**:
- Added missing test_util.h include in new type test headers.
- Completed the set of upb_to_sv test cases for all scalar types by adding optional and repeated tests for sfixed32 , sfixed64 , sint32 , and sint64 , and adding repeated tests to the remaining scalar type files.
- **Documentation:**
- Updated 01-xs-testing.md with more debugging tips, including ASan usage and checking for double frees and typos.
- Updated xs_learnings.md with details from the recent segfault.
- Updated llm-plan-execution-instructions.md to emphasize debugging steps.
## 0.22 2025-12-19
commit 2c171d9a5027e0150eae629729c9104e7f6b9d2b
Author: C.J. Collier
Date: Fri Dec 19 23:41:02 2025 +0000
feat(perl,testing): Initialize C test framework and build system
This commit sets up the foundation for the C-level tests and the build system for the Perl Protobuf module:
1. **Makefile.PL Enhancements:**
* Integrates Devel::PPPort to generate ppport.h for better portability.
* Object files now retain their path structure (e.g., xs/convert/sv_to_upb.o ) instead of being flattened, improving build clarity.
* The MY::postamble is significantly revamped to dynamically generate build rules for all C tests located in t/c/ based on the t/c/c_test_config.json file.
* C tests are linked against libprotobuf_common.a and use ExtUtils::Embed flags.
* Added JSON::MaybeXS to PREREQ_PM .
* The test target now also depends on the test_c target.
2. **C Test Infrastructure ( t/c/ ):
* Introduced t/c/c_test_config.json to configure individual C test builds, specifying dependencies and extra source files.
* Created t/c/convert/test_util.c and .h for shared test functions like loading descriptors.
* Initial t/c/convert/upb_to_sv.c and t/c/convert/sv_to_upb.c test runners.
* Basic t/c/integration/030_protobuf_coro.c for Coro safety testing on core utils using libcoro .
* Basic t/c/integration/035_croak_test.c for testing exception handling.
* Basic t/c/integration/050_convert.c for integration testing conversions.
3. **Test Proto:** Updated t/data/test.proto with more field types for conversion testing and regenerated test_descriptor.bin .
4. **XS Test Harness ( t/c/upb-perl-test.h ):** Added like_n macro for length-aware regex matching.
5. **Documentation:** Updated architecture and plan documents to reflect the C test structure.
6. **ERRSV Testing:** Note that the C tests ( t/c/ ) will primarily check *if* a croak occurs (i.e., that the exception path is taken), but will not assert on the string content of ERRSV . Reliably testing $@ content requires the full Perl test environment with Test::More , which will be done in the .t files when testing the Perl API.
This provides a solid base for developing and testing the XS and C components of the module.
## 0.21 2025-12-18
commit a8b6b6100b2cf29c6df1358adddb291537d979bc
Author: C.J. Collier
Date: Thu Dec 18 04:20:47 2025 +0000
test(C): Add integration tests for Milestone 2 components
- Created t/c/integration/030_protobuf.c to test interactions
between obj_cache, arena, and utils.
- Added this test to t/c/c_test_config.json.
- Verified that all C tests for Milestones 2 and 3 pass,
including the libcoro-based stress test.
## 0.20 2025-12-18
commit 0fcad68680b1f700a83972a7c1c48bf3a6958695
Author: C.J. Collier
Date: Thu Dec 18 04:14:04 2025 +0000
docs(plan): Add guideline review reminders to milestones
- Added a "[ ] REFRESH: Review all documents in @perl/doc/guidelines/**"
checklist item to the start of each component implementation
milestone (C and Perl layers).
- This excludes Integration Test milestones.
## 0.19 2025-12-18
commit 987126c4b09fcdf06967a98fa3adb63d7de59a34
Author: C.J. Collier
Date: Thu Dec 18 04:05:53 2025 +0000
docs(plan): Add C-level and Perl-level Coro tests to milestones
- Added checklist items for libcoro -based C tests
(e.g., t/c/integration/050_convert_coro.c ) to all C layer
integration milestones (050 through 220).
- Updated 030_Integration_Protobuf.md to standardise checklist
items for the existing 030_protobuf_coro.c test.
- Removed the single xt/author/coro-safe.t item from
010_Build.md .
- Added checklist items for Perl-level Coro tests
(e.g., xt/coro/240_arena.t ) to each Perl layer
integration milestone (240 through 400).
- Created perl/t/c/c_test_config.json to manage C test
configurations externally.
- Updated perl/doc/architecture/testing/01-xs-testing.md to describe
both C-level libcoro and Perl-level Coro testing strategies.
## 0.18 2025-12-18
commit 6095a5a610401a6035a81429d0ccb9884d53687b
Author: C.J. Collier
Date: Thu Dec 18 02:34:31 2025 +0000
added coro testing to c layer milestones
## 0.17 2025-12-18
commit cc0aae78b1f7f675fc8a1e99aa876c0764ea1cce
Author: C.J. Collier
Date: Thu Dec 18 02:26:59 2025 +0000
docs(plan): Refine test coverage checklist items for SMARTness
- Updated the "Tests provide full coverage" checklist items in
C layer plan files (020, 040, 060, 080, 100, 120, 140, 160, 180, 200)
to explicitly mention testing all public functions in the
corresponding header files.
- Expanded placeholder checklists in 140, 160, 180, 200.
- Updated the "Tests provide full coverage" and "Add coverage checks"
checklist items in Perl layer plan files (230, 250, 270, 290, 310, 330,
350, 370, 390) to be more specific about the scope of testing
and the use of Test::TestCoverage .
- Expanded Well-Known Types milestone (350) to detail each type.
## 0.16 2025-12-18
commit e4b601f14e3817a17b0f4a38698d981dd4cb2818
Author: C.J. Collier
Date: Thu Dec 18 02:07:35 2025 +0000
docs(plan): Full refactoring of C and Perl plan files
- Split both ProtobufPlan-C.md and ProtobufPlan-Perl.md into
per-milestone files under the perl/doc/plan/ directory.
- Introduced Integration Test milestones after each component
milestone in both C and Perl plans.
- Numbered milestone files sequentially (e.g., 010_Build.md,
230_Perl_Arena.md).
- Updated main ProtobufPlan-C.md and ProtobufPlan-Perl.md to
act as Tables of Contents.
- Ensured consistent naming for integration test files
(e.g., t/c/integration/030_protobuf.c , t/integration/260_descriptor_pool.t ).
- Added architecture review steps to the end of all milestones.
- Moved Coro safety test to C layer Milestone 1.
- Updated Makefile.PL to support new test structure and added Coro.
- Moved and split t/c/convert.c into t/c/convert/*.c.
- Moved other t/c/*.c tests into t/c/protobuf/*.c.
- Deleted old t/c/convert.c.
## 0.15 2025-12-17
commit 649cbacf03abb5e7293e3038bb451c0406e9d0ce
Author: C.J. Collier
Date: Wed Dec 17 23:51:22 2025 +0000
docs(plan): Refactor and reset ProtobufPlan.md
- Split the plan into ProtobufPlan-C.md and ProtobufPlan-Perl.md.
- Reorganized milestones to clearly separate C layer and Perl layer development.
- Added more granular checkboxes for each component:
- C Layer: Create test, Test coverage, Implement, Tests pass.
- Perl Layer: Create test, Test coverage, Implement Module/XS, Tests pass, C-Layer adjustments.
- Reset all checkboxes to [ ] to prepare for a full audit.
- Updated status in architecture/api and architecture/core documents to "Not Started".
feat(obj_cache): Add unregister function and enhance tests
- Added protobuf_unregister_object to xs/protobuf/obj_cache.c .
- Updated xs/protobuf/obj_cache.h with the new function declaration.
- Expanded tests in t/c/protobuf_obj_cache.c to cover unregistering,
overwriting keys, and unregistering non-existent keys.
- Corrected the test plan count in t/c/protobuf_obj_cache.c to 17.
## 0.14 2025-12-17
commit 40b6ad14ca32cf16958d490bb575962f88d868a1
Author: C.J. Collier
Date: Wed Dec 17 23:18:27 2025 +0000
feat(arena): Complete C layer for Arena wrapper
This commit finalizes the C-level implementation for the Protobuf::Arena wrapper.
- Adds PerlUpb_Arena_Destroy for proper cleanup from Perl's DEMOLISH.
- Enhances error checking in PerlUpb_Arena_Get .
- Expands C-level tests in t/c/protobuf_arena.c to cover memory allocation
on the arena and lifecycle through PerlUpb_Arena_Destroy .
- Corrects embedded Perl initialization in the C test.
docs(plan): Refactor ProtobufPlan.md
- Restructures the development plan to clearly separate "C Layer" and
"Perl Layer" tasks within each milestone.
- This aligns the plan with the "C-First Implementation Strategy" and improves progress tracking.
## 0.13 2025-12-17
commit c1e566c25f62d0ae9f195a6df43b895682652c71
Author: C.J. Collier
Date: Wed Dec 17 22:00:40 2025 +0000
refactor(perl): Rename C tests and enhance Makefile.PL
- Renamed test files in t/c/ to better match the xs module structure:
- 01-cache.c -> protobuf_obj_cache.c
- 02-arena.c -> protobuf_arena.c
- 03-utils.c -> protobuf_utils.c
- 04-convert.c -> convert.c
- load_test.c -> upb_descriptor_load.c
- Updated perl/Makefile.PL to reflect the new test names in MY::postamble 's $c_test_config .
- Refactored the $c_test_config generation in Makefile.PL to reduce repetition by using a default flags hash and common dependencies array.
- Added a fail() macro to perl/t/c/upb-perl-test.h for consistency.
- Modified t/c/upb_descriptor_load.c to use the t/c/upb-perl-test.h macros, making its output consistent with other C tests.
- Added a skeleton for t/c/convert.c to test the conversion functions.
- Updated documentation in ProtobufPlan.md and architecture/testing/01-xs-testing.md to reflect new test names.
## 0.12 2025-12-17
commit d8cb5dd415c6c129e71cd452f78e29de398a82c9
Author: C.J. Collier
Date: Wed Dec 17 20:47:38 2025 +0000
feat(perl): Refactor XS code into subdirectories
This commit reorganizes the C code in the perl/xs/ directory into subdirectories, mirroring the structure of the Python UPB extension. This enhances modularity and maintainability.
- Created subdirectories for each major component: convert , descriptor , descriptor_containers , descriptor_pool , extension_dict , map , message , protobuf , repeated , and unknown_fields .
- Created skeleton .h and .c files within each subdirectory to house the component-specific logic.
- Updated top-level component headers (e.g., perl/xs/descriptor.h ) to include the new sub-headers.
- Updated top-level component source files (e.g., perl/xs/descriptor.c ) to include their main header and added stub initialization functions (e.g., PerlUpb_InitDescriptor ).
- Moved code from the original perl/xs/protobuf.c to new files in perl/xs/protobuf/ (arena, obj_cache, utils).
- Moved code from the original perl/xs/convert.c to new files in perl/xs/convert/ (upb_to_sv, sv_to_upb).
- Updated perl/Makefile.PL to use a glob ( xs/*/*.c ) to find the new C source files in the subdirectories.
- Added perl/doc/architecture/core/07-xs-file-organization.md to document the new structure.
- Updated perl/doc/ProtobufPlan.md and other architecture documents to reference the new organization.
- Corrected self-referential includes in the newly created .c files.
This restructuring provides a solid foundation for further development and makes it easier to port logic from the Python implementation.
## 0.11 2025-12-17
commit cdedcd13ded4511b0464f5d3bdd72ce6d34e73fc
Author: C.J. Collier
Date: Wed Dec 17 19:57:52 2025 +0000
feat(perl): Implement C-first testing and core XS infrastructure
This commit introduces a significant refactoring of the Perl XS extension, adopting a C-first development approach to ensure a robust foundation.
Key changes include:
- **C-Level Testing Framework:** Established a C-level testing system in t/c/ with a dedicated Makefile, using an embedded Perl interpreter. Initial tests cover the object cache ( 01-cache.c ), arena wrapper ( 02-arena.c ), and utility functions ( 03-utils.c ).
- **Core XS Infrastructure:**
- Implemented a global object cache ( xs/protobuf.c ) to manage Perl wrappers for UPB objects, using weak references.
- Created an upb_Arena wrapper ( xs/protobuf.c ).
- Consolidated common XS helper functions into xs/protobuf.h and xs/protobuf.c .
- **Makefile.PL Enhancements:** Updated to support building and linking C tests, incorporating flags from ExtUtils::Embed , and handling both .c and .cc source files.
- **XS File Reorganization:** Restructured XS files to mirror the Python UPB extension's layout (e.g., message.c , descriptor.c ). Removed older, monolithic .xs files.
- **Typemap Expansion:** Added extensive typemap entries in perl/typemap to handle conversions between Perl objects and various const upb_*Def* pointers.
- **Descriptor Tests:** Added a new test suite t/02-descriptor.t to validate descriptor loading and accessor methods.
- **Documentation:** Updated development plans and guidelines ( ProtobufPlan.md , xs_learnings.md , etc.) to reflect the C-first strategy, new testing methods, and lessons learned.
- **Build Cleanup:** Removed ppport.h from .gitignore as it's no longer used, due to -DPERL_NO_PPPORT being set in Makefile.PL .
This C-first approach allows for more isolated and reliable testing of the core logic interacting with the UPB library before higher-level Perl APIs are built upon it.
## 0.10 2025-12-17
commit 1ef20ade24603573905cb0376670945f1ab5d829
Author: C.J. Collier
Date: Wed Dec 17 07:08:29 2025 +0000
feat(perl): Implement C-level tests and core XS utils
This commit introduces a C-level testing framework for the XS layer and implements key components:
1. **C-Level Tests ( t/c/ )**:
* Added t/c/Makefile to build standalone C tests.
* Created t/c/upb-perl-test.h with macros for TAP-compliant C tests ( plan , ok , is , is_string , diag ).
* Implemented t/c/01-cache.c to test the object cache.
* Implemented t/c/02-arena.c to test Protobuf::Arena wrappers.
* Implemented t/c/03-utils.c to test string utility functions.
* Corrected include paths and diagnostic messages in C tests.
2. **XS Object Cache ( xs/protobuf.c )**:
* Switched to using stringified pointers ( %p ) as hash keys for stability.
* Fixed a critical double-free bug in PerlUpb_ObjCache_Delete by removing an extra SvREFCNT_dec on the lookup key.
3. **XS Arena Wrapper ( xs/protobuf.c )**:
* Corrected PerlUpb_Arena_New to use newSVrv and PTR2IV for opaque object wrapping.
* Corrected PerlUpb_Arena_Get to safely unwrap the arena pointer.
4. **Makefile.PL ( perl/Makefile.PL )**:
* Added -Ixs to INC to allow C tests to find t/c/upb-perl-test.h and xs/protobuf.h .
* Added LIBS to link libprotobuf_common.a into the main Protobuf.so .
* Added C test targets 01-cache , 02-arena , 03-utils to the test config in MY::postamble .
5. **Protobuf.pm ( perl/lib/Protobuf.pm )**:
* Added use XSLoader; to load the compiled XS code.
6. **New files xs/util.h **:
* Added initial type conversion function.
These changes establish a foundation for testing the C-level interface with UPB and fix crucial bugs in the object cache implementation.
## 0.09 2025-12-17
commit 07d61652b032b32790ca2d3848243f9d75ea98f4
Author: C.J. Collier
Date: Wed Dec 17 04:53:34 2025 +0000
feat(perl): Build system and C cache test for Perl XS
This commit introduces the foundational pieces for the Perl XS implementation, focusing on the build system and a C-level test for the object cache.
- **Makefile.PL:**
- Refactored C test compilation rules in MY::postamble to use a hash ( $c_test_config ) for better organization and test-specific flags.
- Integrated ExtUtils::Embed to provide necessary compiler and linker flags for embedding the Perl interpreter, specifically for the t/c/01-cache.c test.
- Correctly constructs the path to the versioned Perl library ( libperl.so.X.Y.Z ) using $Config archlib and $Config libperl to ensure portability.
- Removed VERSION_FROM and ABSTRACT_FROM to avoid dependency on .pm files for now.
- **C Cache Test (t/c/01-cache.c):**
- Added a C test to exercise the object cache functions implemented in xs/protobuf.c .
- Includes tests for adding, getting, deleting, and weak reference behavior.
- **XS Cache Implementation (xs/protobuf.c, xs/protobuf.h):**
- Implemented PerlUpb_ObjCache_Init , PerlUpb_ObjCache_Add , PerlUpb_ObjCache_Get , PerlUpb_ObjCache_Delete , and PerlUpb_ObjCache_Destroy .
- Uses a Perl hash ( HV* ) for the cache.
- Keys are string representations of the C pointers, created using snprintf with "%llx" .
- Values are weak references ( sv_rvweaken ) to the Perl objects ( SV* ).
- PerlUpb_ObjCache_Get now correctly returns an incremented reference to the original SV, not a copy.
- PerlUpb_ObjCache_Destroy now clears the hash before decrementing its refcount.
- **t/c/upb-perl-test.h:**
- Updated is_sv to perform direct pointer comparison ( got == expected ).
- **Minor:** Added util.h (currently empty), updated typemap .
These changes establish a working C-level test environment for the XS components.
## 0.08 2025-12-17
commit d131fd22ea3ed8158acb9b0b1fe6efd856dc380e
Author: C.J. Collier
Date: Wed Dec 17 02:57:48 2025 +0000
feat(perl): Update docs and core XS files
- Explicitly add TDD cycle to ProtobufPlan.md.
- Clarify mirroring of Python implementation in upb-interfacing.md for both C and Perl layers.
- Branch and adapt python/protobuf.h and python/protobuf.c to perl/xs/protobuf.h and perl/xs/protobuf.c, including the object cache implementation. Removed old cache.* files.
- Create initial C test for the object cache in t/c/01-cache.c.
## 0.07 2025-12-17
commit 56fd6862732c423736a2f9a9fb1a2816fc59e9b0
Author: C.J. Collier
Date: Wed Dec 17 01:09:18 2025 +0000
feat(perl): Align Perl UPB architecture docs with Python
Updates the Perl Protobuf architecture documents to more closely align with the design and implementation strategies used in the Python UPB extension.
Key changes:
- **Object Caching:** Mandates a global, per-interpreter cache using weak references for all UPB-derived objects, mirroring Python's PyUpb_ObjCache .
- **Descriptor Containers:** Introduces a new document outlining the plan to use generic XS container types (Sequence, ByNameMap, ByNumberMap) with vtables to handle collections of descriptors, similar to Python's descriptor_containers.c .
- **Testing:** Adds a note to the testing strategy to port relevant test cases from the Python implementation to ensure feature parity.
## 0.06 2025-12-17
commit 6009ce6ab64eccce5c48729128e5adf3ef98e9ae
Author: C.J. Collier
Date: Wed Dec 17 00:28:20 2025 +0000
feat(perl): Implement object caching and fix build
This commit introduces several key improvements to the Perl XS build system and core functionality:
1. **Object Caching:**
* Introduces xs/protobuf.c and xs/protobuf.h to implement a caching mechanism ( protobuf_c_to_perl_obj ) for wrapping UPB C pointers into Perl objects. This uses a hash and weak references to ensure object identity and prevent memory leaks.
* Updates the typemap to use protobuf_c_to_perl_obj for upb_MessageDef * output, ensuring descriptor objects are cached.
* Corrected sv_weaken to the correct sv_rvweaken function.
2. **Makefile.PL Enhancements:**
* Switched to using the Bazel-generated UPB descriptor sources from bazel-bin/src/google/protobuf/_virtual_imports/descriptor_proto/google/protobuf/ .
* Updated INC paths to correctly locate the generated headers.
* Refactored MY::dynamic_lib to ensure the static library libprotobuf_common.a is correctly linked into each generated .so module, resolving undefined symbol errors.
* Overrode MY::test to use prove -b -j$(nproc) t/*.t xt/*.t for running tests.
* Cleaned up LIBS and LDDLFLAGS usage.
3. **Documentation:**
* Updated ProtobufPlan.md to reflect the current status and design decisions.
* Reorganized architecture documents into subdirectories.
* Added object-caching.md and c-perl-interface.md .
* Updated llm-guidance.md with notes on upb/upb.h and sv_rvweaken .
4. **Testing:**
* Fixed xt/03-moo_immutable.t to skip tests if no Moo modules are found.
This resolves the build issues and makes the core test suite pass.
## 0.05 2025-12-16
commit 177d2f3b2608b9d9c415994e076a77d8560423b8
Author: C.J. Collier
Date: Tue Dec 16 19:51:36 2025 +0000
Refactor: Rename namespace to Protobuf, build system and doc updates
This commit refactors the primary namespace from ProtoBuf to Protobuf
to align with the style guide. This involves renaming files, directories,
and updating package names within all Perl and XS files.
**Namespace Changes:**
* Renamed perl/lib/ProtoBuf to perl/lib/Protobuf .
* Moved and updated ProtoBuf.pm to Protobuf.pm .
* Moved and updated ProtoBuf::Descriptor to Protobuf::Descriptor (.pm & .xs).
* Removed other ProtoBuf::* stubs (Arena, DescriptorPool, Message).
* Updated MODULE and PACKAGE in Descriptor.xs .
* Updated NAME , *_FROM in perl/Makefile.PL .
* Replaced ProtoBuf with Protobuf throughout perl/typemap .
* Updated namespaces in test files t/01-load-protobuf-descriptor.t and t/02-descriptor.t .
* Updated namespaces in all documentation files under perl/doc/ .
* Updated paths in perl/.gitignore .
**Build System Enhancements (Makefile.PL):**
* Included xs/*.c files in the common object files list.
* Added -I. to the INC paths.
* Switched from MYEXTLIB to LIBS => ['-L$(CURDIR) -lprotobuf_common'] for linking.
* Removed custom keys passed to WriteMakefile for postamble.
* MY::postamble now sources variables directly from the main script scope.
* Added all :: $ common_lib dependency in MY::postamble .
* Added t/c/load_test.c compilation rule in MY::postamble .
* Updated clean target to include blib .
* Added more modules to TEST_REQUIRES .
* Removed the explicit PM and XS keys from WriteMakefile , relying on XSMULTI => 1 .
**New Files:**
* perl/lib/Protobuf.pm
* perl/lib/Protobuf/Descriptor.pm
* perl/lib/Protobuf/Descriptor.xs
* perl/t/01-load-protobuf-descriptor.t
* perl/t/02-descriptor.t
* perl/t/c/load_test.c : Standalone C test for UPB.
* perl/xs/types.c & perl/xs/types.h : For Perl/C type conversions.
* perl/doc/architecture/upb-interfacing.md
* perl/xt/03-moo_immutable.t : Test for Moo immutability.
**Deletions:**
* Old test files: t/00_load.t , t/01_basic.t , t/02_serialize.t , t/03_message.t , t/04_descriptor_pool.t , t/05_arena.t , t/05_message.t .
* Removed lib/ProtoBuf.xs as it's not needed with XSMULTI .
**Other:**
* Updated test_descriptor.bin (binary change).
* Significant content updates to markdown documentation files in perl/doc/architecture and perl/doc/internal reflecting the new architecture and learnings.
## 0.04 2025-12-14
commit 92de5d482c8deb9af228f4b5ce31715d3664d6ee
Author: C.J. Collier
Date: Sun Dec 14 21:28:19 2025 +0000
feat(perl): Implement Message object creation and fix lifecycles
This commit introduces the basic structure for ProtoBuf::Message object
creation, linking it with ProtoBuf::Descriptor and ProtoBuf::DescriptorPool ,
and crucially resolves a SEGV by fixing object lifecycle management.
Key Changes:
1. ** ProtoBuf::Descriptor :** Added _pool attribute to hold a strong
reference to the parent ProtoBuf::DescriptorPool . This is essential to
prevent the pool and its C upb_DefPool from being garbage collected
while a descriptor is still in use.
2. ** ProtoBuf::DescriptorPool :**
* find_message_by_name : Now passes the $self (the pool object) to the
ProtoBuf::Descriptor constructor to establish the lifecycle link.
* XSUB pb_dp_find_message_by_name : Updated to accept the pool SV* and
store it in the descriptor's _pool attribute.
* XSUB _load_serialized_descriptor_set : Renamed to avoid clashing with the
Perl method name. The Perl wrapper now correctly calls this internal XSUB.
* DEMOLISH : Made safer by checking for attribute existence.
3. ** ProtoBuf::Message :**
* Implemented using Moo with lazy builders for _upb_arena and
_upb_message .
* _descriptor is a required argument to new() .
* XS functions added for creating the arena ( pb_msg_create_arena ) and
the upb_Message ( pb_msg_create_upb_message ).
* pb_msg_create_upb_message now extracts the upb_MessageDef* from the
descriptor and uses upb_MessageDef_MiniTable() to get the minitable
for upb_Message_New() .
* DEMOLISH : Added to free the message's arena.
4. ** Makefile.PL :**
* Added -g to CCFLAGS for debugging symbols.
* Added Perl CORE include path to MY::postamble 's base_flags .
5. **Tests:**
* t/04_descriptor_pool.t : Updated to check the structure of the
returned ProtoBuf::Descriptor .
* t/05_message.t : Now uses a descriptor obtained from a real pool to
test ProtoBuf::Message->new() .
6. **Documentation:**
* Updated ProtobufPlan.md to reflect progress.
* Updated several files in doc/architecture/ to match the current
implementation details, especially regarding arena management and object
lifecycles.
* Added doc/internal/development_cycle.md and doc/internal/xs_learnings.md .
With these changes, the SEGV is resolved, and message objects can be successfully
created from descriptors.
## 0.03 2025-12-14
commit 6537ad23e93680c2385e1b571d84ed8dbe2f68e8
Author: C.J. Collier
Date: Sun Dec 14 20:23:41 2025 +0000
Refactor(perl): Object-Oriented DescriptorPool with Moo
This commit refactors the ProtoBuf::DescriptorPool to be fully object-oriented using Moo, and resolves several issues related to XS, typemaps, and test data.
Key Changes:
1. **Moo Object:** ProtoBuf::DescriptorPool.pm now uses Moo to define the class. The upb_DefPool pointer is stored as a lazy attribute _upb_defpool .
2. **XS Lifecycle:** DescriptorPool.xs now has pb_dp_create_pool called by the Moo builder and pb_dp_free_pool called from DEMOLISH to manage the upb_DefPool lifecycle per object.
3. **Typemap:** The perl/typemap file has been significantly updated to handle the conversion between the ProtoBuf::DescriptorPool Perl object and the upb_DefPool * C pointer. This includes:
* Mapping upb_DefPool * to T_PTR .
* An INPUT section for ProtoBuf::DescriptorPool to extract the pointer from the object's hash, triggering the lazy builder if needed via call_method .
* An OUTPUT section for upb_DefPool * to convert the pointer back to a Perl integer, used by the builder.
4. **Method Renaming:** add_file_descriptor_set_binary is now load_serialized_descriptor_set .
5. **Test Data:**
* Added perl/t/data/test.proto with a sample message and enum.
* Generated perl/t/data/test_descriptor.bin using protoc .
* Removed t/data/ from .gitignore to ensure test data is versioned.
6. **Test Update:** t/04_descriptor_pool.t is updated to use the new OO interface, load the generated descriptor set, and check for message definitions.
7. **Build Fixes:**
* Corrected #include paths in DescriptorPool.xs to be relative to the upb/ directory (e.g., upb/wire/decode.h ).
* Added -I../upb to CCFLAGS in Makefile.PL .
* Reordered INC paths in Makefile.PL to prioritize local headers.
**Note:** While tests now pass in some environments, a SEGV issue persists in make test runs, indicating a potential memory or lifecycle issue within the XS layer that needs further investigation.
## 0.02 2025-12-14
commit 6c9a6f1a5f774dae176beff02219f504ea3a6e07
Author: C.J. Collier
Date: Sun Dec 14 20:13:09 2025 +0000
Fix(perl): Correct UPB build integration and generated file handling
This commit resolves several issues to achieve a successful build of the Perl extension:
1. **Use Bazel Generated Files:** Switched from compiling UPB's stage0 descriptor.upb.c to using the Bazel-generated descriptor.upb.c and descriptor.upb_minitable.c located in bazel-bin/src/google/protobuf/_virtual_imports/descriptor_proto/google/protobuf/ .
2. **Updated Include Paths:** Added the bazel-bin path to INC in WriteMakefile and to base_flags in MY::postamble to ensure the generated headers are found during both XS and static library compilation.
3. **Removed Stage0:** Removed references to UPB_STAGE0_DIR and no longer include headers or source files from upb/reflection/stage0/ .
4. **-fPIC:** Explicitly added -fPIC to CCFLAGS in WriteMakefile and ensured $(CCFLAGS) is used in the custom compilation rules in MY::postamble . This guarantees all object files in the static library are compiled with position-independent code, resolving linker errors when creating the shared objects for the XS modules.
5. **Refined UPB Sources:** Used File::Find to recursively find UPB C sources, excluding /conformance/ and /reflection/stage0/ to avoid conflicts and unnecessary compilations.
6. **Arena Constructor:** Modified ProtoBuf::Arena::pb_arena_new XSUB to accept the class name argument passed from Perl, making it a proper constructor.
7. **.gitignore:** Added patterns to perl/.gitignore to ignore generated C files from XS ( lib/*.c , lib/ProtoBuf/*.c ), the copied src_google_protobuf_descriptor.pb.cc , and the t/data directory.
8. **Build Documentation:** Updated perl/doc/architecture/upb-build-integration.md to reflect the new build process, including the Bazel prerequisite, include paths, -fPIC usage, and File::Find .
Build Steps:
1. bazel build //src/google/protobuf:descriptor_upb_proto (from repo root)
2. cd perl
3. perl Makefile.PL
4. make
5. make test (Currently has expected failures due to missing test data implementation).
## 0.01 2025-12-14
commit 3e237e8a26442558c94075766e0d4456daaeb71d
Author: C.J. Collier
Date: Sun Dec 14 19:34:28 2025 +0000
feat(perl): Initialize Perl extension scaffold and build system
This commit introduces the perl/ directory, laying the groundwork for the Perl Protocol Buffers extension. It includes the essential build files, linters, formatter configurations, and a vendored Devel::PPPort for XS portability.
Key components added:
* ** Makefile.PL **: The core ExtUtils::MakeMaker build script. It's configured to:
* Build a static library ( libprotobuf_common.a ) from UPB, UTF8_Range, and generated protobuf C/C++ sources.
* Utilize XSMULTI => 1 to create separate shared objects for ProtoBuf , ProtoBuf::Arena , and ProtoBuf::DescriptorPool .
* Link each XS module against the common static library.
* Define custom compilation rules in MY::postamble to handle C vs. C++ flags and build the static library.
* Set up include paths for the project root, UPB, and other dependencies.
* **XS Stubs ( .xs files)**:
* lib/ProtoBuf.xs : Placeholder for the main module's XS functions.
* lib/ProtoBuf/Arena.xs : XS interface for upb_Arena management.
* lib/ProtoBuf/DescriptorPool.xs : XS interface for upb_DefPool management.
* **Perl Module Stubs ( .pm files)**:
* lib/ProtoBuf.pm : Main module, loads XS.
* lib/ProtoBuf/Arena.pm : Perl class for Arenas.
* lib/ProtoBuf/DescriptorPool.pm : Perl class for Descriptor Pools.
* lib/ProtoBuf/Message.pm : Base class for messages (TBD).
* **Configuration Files**:
* .gitignore : Ignores build artifacts, editor files, etc.
* .perlcriticrc : Configures Perl::Critic for static analysis.
* .perltidyrc : Configures perltidy for code formatting.
* ** Devel::PPPort **: Vendored version 3.72 to generate ppport.h for XS compatibility across different Perl versions.
* ** typemap **: Custom typemap for XS argument/result conversion.
* **Documentation ( doc/ )**: Initial architecture and plan documents.
This provides a solid foundation for developing the UPB-based Perl extension.
A new release of my mixed collection of things package dang package arrived
at CRAN earlier today. The dang package regroups
a few functions of mine that had no other home as for example
lsos() from a
StackOverflow question from 2009 (!!), the overbought/oversold
price band plotter from an older blog post, the market monitor
blogged about as well as the checkCRANStatus() function
tweeted about by Tim
Taylor. And more so take a look.
This release retires two functions: the social media site nobody ever
visits anymore shut down its API too, so no way to mute posts by a given
handle. Similarly, the (never official) ability by Google to supply
financial data is no more, so the function to access data this way is
gone too. But we also have two new ones: one that helps with CRAN entries for ORCiD ids, and
another little helper to re-order microbenchmark results by
summary column (defaulting to the median). Other than the usual updates
to continuous integrations, as well as a switch to Authors@R which will
result in CRAN nagging me less
about this, and another argument update.
The detailed NEWS entry follows.
Changes in version 0.0.17
(2025-12-18)
Added new funtion reorderMicrobenchmarkResults with
alias rmr
Use tolower on email argument to
checkCRANStatus
Added new function cranORCIDs bootstrapped from two
emails by Kurt Hornik
Switched to using Authors@R in DESCRIPTION and added ORCIDs where
available
Switched to r-ci action with included bootstrap
step; updated updated the checkout action (twice); added (commented-out)
log accessor
Removed googleFinanceData as the (unofficial) API
access point no longer works
Removed muteTweeters because the API was turned
off
We announced a public beta of
Debusine repositories
recently (Freexian
blog,
debian-devel-announce).
One thing I m very keen on is being able to use these to prepare
transitions : changes to multiple packages that need to be prepared
together in order to land in testing. As I said in my DebConf25
talk:
We have distribution-wide CI in unstable, but there s only one of it and
it s shared between all of us. As a result it s very possible to get into
tangles when multiple people are working on related things at the same
time, and we only avoid that as much as we do by careful coordination such
as transition bugs. Experimental helps, but again, there s only one of it
and setting up another one is far from trivial.
So, what we want is a system where you can run experiments on possible
Debian changes at a large scale without a high setup cost and without fear
of breaking things for other people. And then, if it all works, push the
whole lot into Debian.
Time to practice what I preach.
Setup
The setup process is documented on the Debian
wiki. You need to
decide whether you re working on a short-lived experiment, in which case
you ll run the create-experiment workflow and your workspace will expire
after 60 days of inactivity, or something that you expect to keep around for
longer, in which case you ll run the create-repository workflow. Either
one of those will create a new workspace for you. Then, in that workspace,
you run debusine archive suite create for whichever suites you want to
use. For the case of a transition that you plan to land in unstable, you ll
most likely use create-experiment and then create a single suite with the
pattern sid-<name>.
The situation I was dealing with here was moving to
Pylint 4. Tests showed that we
needed this as part of adding Python 3.14 as a supported Python version, and
I knew that I was going to need newer upstream versions of the astroid and
pylint packages. However, I wasn t quite sure what the fallout of a new
major version of pylint was going to be. Fortunately, the Debian Python
ecosystem has pretty good autopkgtest coverage, so I thought I d see what
Debusine said about it. I created an experiment called cjwatson-pylint
(resulting in
https://debusine.debian.net/debian/developers-cjwatson-pylint/ - I m not
making that a proper link since it will expire in a couple of months) and a
sid-pylint suite in it.
Iteration
From this starting point, the basic cycle involved uploading each package
like this for each package I d prepared:
I could have made a new dput-ng profile to cut down on typing, but it
wasn t worth it here.
Then I looked at the workflow results, figured out which other packages I
needed to fix based on those, and repeated until the whole set looked
coherent. Debusine automatically built each upload against whatever else
was currently in the repository, as you d expect.
I should probably have used version numbers with tilde suffixes (e.g.
4.0.2-1~test1) in case I needed to correct anything, but fortunately that
was mostly unnecessary. I did at least run initial test-builds locally of
just the individual packages I was directly changing to make sure that they
weren t too egregiously broken, just because I usually find it quicker to
iterate that way.
I didn t take screenshots as I was going along, but here s what the list of
top-level
workflows
in my workspace looked like by the end:
You can see that not all of the workflows are successful. This is because
we currently just show everything in every workflow; we don t consider
whether a task was retried and succeeded on the second try, or whether
there s now a newer version of a reverse-dependency so tests of the older
version should be disregarded, and so on. More fundamentally, you have to
look through each individual workflow, which is a bit of a pain: we plan to
add a dashboard that shows you the current state of a suite as a whole
rather than the current workflow-oriented view, but we haven t started on
that yet.
Drilling down into one of these workflows, it looks something like this:
This was the first package I uploaded. The first pass of failures told me
about pylint (expected), pylint-flask (an obvious consequence), and
python-sphinx-autodoc2 and sphinx-autoapi (surprises). The slightly odd
pattern of failures and errors is because I retried a few things, and we
sometimes report retries in a slightly strange way, especially when there
are workflows involved that might not be able to resolve their input
parameters any more.
The next level was:
Again, there were some retries involved here, and also some cases where
packages were already failing in unstable so the failures weren t the fault
of my change; for now I had to go through and analyze these by hand, but
we ll soon have regression tracking to compare with reference runs and show
you where things have got better or worse.
After excluding those, that left pytest-pylint (not caused by my changes,
but I fixed it anyway in unstable to clear out some noise) and spyder.
I d seen people talking about spyder on #debian-python recently, so after
a bit of conversation there I sponsored a rope upload by Aeliton Silva,
upgraded python-lsp-server, and patched spyder. All those went into my
repository too, exposing a couple more tests I d forgotten in spyder.
Once I was satisfied with the results, I uploaded everything to unstable.
The next day, I looked through the tracker as usual starting from
astroid, and while there are some
test failures showing up right now it looks as though they should all clear
out as pieces migrate to testing. Success!
Conclusions
We still have some way to go before this is a completely smooth experience
that I d be prepared to say that every developer can and should be using;
there are all sorts of fit-and-finish issues that I can easily see here.
Still, I do think we re at the point where a tolerant developer can use this
to deal with the common case of a mid-sized transition, and get more out of
it than they put in.
Without Debusine, either I d have had to put much more effort into searching
for and testing reverse-dependencies myself, or (more likely, let s face it)
I d have just dumped things into unstable and sorted them out afterwards,
resulting in potentially delaying other people s work. This way, everything
was done with as little disruption as possible.
This works best when the packages likely to be involved have reasonably good
autopkgtest coverage (even if the
tests themselves are relatively basic). This is an increasingly good
bet in Debian, but we have plans to
add installability comparisons (similar to how Debian s testing suite
works) as well as optional rebuild testing.
If this has got you interested, please try it out for
yourself and let us know how it
goes!
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) 1272 other packages on CRAN, downloaded 43.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 661 times according
to Google Scholar.
This versions updates to the 15.2.3 upstream Armadillo release from
yesterday. It brings minor changes over the RcppArmadillo 15.2.2 release
made last month (and described in
this post). As noted previously, and due to both the upstream
transition to C++14 coupled with the CRAN move away from C++11, the
package offers a transition by allowing packages to remain with the
older, pre-15.0.0 legacy Armadillo yet offering the
current version as the default. If and when CRAN will have nudged (nearly) all
maintainers away from C++11 (and now also C++14 !!) we can remove the
fallback. Our offer to help with the C++ modernization still stands, so
please get in touch if we can be of assistance. As a reminder, the
meta-issue #475
regroups all the resources for the C++11 transition.
There were no R-side changes in this release. The detailed changes
since the last release follow.
Changes in
RcppArmadillo version 15.2.3-1 (2025-12-16)
Upgraded to Armadillo release 15.2.3 (Medium Roast Deluxe)
I recently won a lawsuit against Roy and Rianne Schestowitz, the authors and publishers of the Techrights and Tuxmachines websites. The short version of events is that they were subject to an online harassment campaign, which they incorrectly blamed me for. They responded with a large number of defamatory online posts about me, which the judge described as unsubstantiated character assassination and consequently awarded me significant damages. That's not what this post is about, as such. It's about the sole meaningful claim made that tied me to the abuse.
In the defendants' defence and counterclaim[1], 15.27 asserts in part The facts linking the Claimant to the sock puppet accounts include, on the IRC network: simultaneous dropped connections to the mjg59_ and elusive_woman accounts. This is so unlikely to be coincidental that the natural inference is that the same person posted under both names. "elusive_woman" here is an account linked to the harassment, and "mjg59_" is me. This is actually a surprisingly interesting claim to make, and it's worth going into in some more detail.
The event in question occurred on the 28th of April, 2023. You can see a line reading *elusive_woman has quit (Ping timeout: 2m30s), followed by one reading *mjg59_ has quit (Ping timeout: 2m30s). The timestamp listed for the first is 09:52, and for the second 09:53. Is that actually simultaneous? We can actually gain some more information - if you hover over the timestamp links on the right hand side you can see that the link is actually accurate to the second even if that's not displayed. The first event took place at 09:52:52, and the second at 09:53:03. That's 11 seconds apart, which is clearly not simultaneous, but maybe it's close enough. Figuring out more requires knowing what a "ping timeout" actually means here.
The IRC server in question is running Ergo (link to source code), and the relevant function is handleIdleTimeout(). The logic here is fairly simple - track the time since activity was last seen from the client. If that time is longer than DefaultIdleTimeout (which defaults to 90 seconds) and a ping hasn't been sent yet, send a ping to the client. If a ping has been sent and the timeout is greater than DefaultTotalTimeout (which defaults to 150 seconds), disconnect the client with a "Ping timeout" message. There's no special logic for handling the ping reply - a pong simply counts as any other client activity and resets the "last activity" value and timeout.
What does this mean? Well, for a start, two clients running on the same system will only have simultaneous ping timeouts if their last activity was simultaneous. Let's imagine a machine with two clients, A and B. A sends a message at 02:22:59. B sends a message 2 seconds later, at 02:23:01. The idle timeout for A will fire at 02:24:29, and for B at 02:24:31. A ping is sent for A at 02:24:29 and is responded to immediately - the idle timeout for A is now reset to 02:25:59, 90 seconds later. The machine hosting A and B has its network cable pulled out at 02:24:30. The ping to B is sent at 02:24:31, but receives no reply. A minute later, at 02:25:31, B quits with a "Ping timeout" message. A ping is sent to A at 02:25:59, but receives no reply. A minute later, at 02:26:59, A quits with a "Ping timeout" message. Despite both clients having their network interrupted simultaneously, the ping timeouts occur 88 seconds apart.
So, two clients disconnecting with ping timeouts 11 seconds apart is not incompatible with the network connection being interrupted simultaneously - depending on activity, simultaneous network interruption may result in disconnections up to 90 seconds apart. But another way of looking at this is that network interruptions may occur up to 90 seconds apart and generate simultaneous disconnections[2]. Without additional information it's impossible to determine which is the case.
This already casts doubt over the assertion that the disconnection was simultaneous, but if this is unusual enough it's still potentially significant. Unfortunately for the Schestowitzes, even looking just at the elusive_woman account, there were several cases where elusive_woman and another user had a ping timeout within 90 seconds of each other - including one case where elusive_woman and schestowitz[TR] disconnect 40 seconds apart. By the Schestowitzes argument, it's also a natural inference that elusive_woman and schestowitz[TR] (one of Roy Schestowitz's accounts) are the same person.
We didn't actually need to make this argument, though. In England it's necessary to file a witness statement describing the evidence that you're going to present in advance of the actual court hearing. Despite being warned of the consequences on multiple occasions the Schestowitzes never provided any witness statements, and as a result weren't allowed to provide any evidence in court, which made for a fairly foregone conclusion.
[1] As well as defending themselves against my claim, the Schestowitzes made a counterclaim on the basis that I had engaged in a campaign of harassment against them. This counterclaim failed.
[2] Client A and client B both send messages at 02:22:59. A falls off the network at 02:23:00, has a ping sent at 02:24:29, and has a ping timeout at 02:25:29. B falls off the network at 02:24:28, has a ping sent at 02:24:29, and has a ping timeout at 02:25:29. Simultaneous disconnects despite over a minute of difference in the network interruption.
The Debian LTS Team, funded by [Freexian s Debian LTS offering]
(https://www.freexian.com/lts/debian/), is pleased to report its activities for
November.
Activity summary
During the month of November, 18 contributors have been
paid to work on Debian LTS (links to individual
contributor reports are located below).
The team released 33 DLAs
fixing 219 CVEs.
The LTS Team kept going with the usual cadence of preparing security updates for Debian
11 bullseye , but also for Debian 12 bookworm , Debian 13 trixie and even
Debian unstable.
As in previous months, we are pleased to say that there have been multiple
contributions of LTS uploads by Debian Fellows outside the regular LTS Team.
Notable security updates:
Guilhem Moulin prepared DLA 4365-1
for unbound, a caching DNS resolver, fixing a cache poisoning vulnerability
that could lead to domain hijacking.
Another update related to DNS software was made by Andreas Henriksson. Andreas
completed the work on bind9, released as
DLA 4364-1 to fix
cache poisoning and Denial of Service (DoS) vulnerabilities.
Chris Lamb released DLA 4374-1
to fix a potential arbitrary code execution vulnerability in pdfminer, a tool
for extracting information from PDF documents.
Ben Hutchings published a regular security update for the linux 6.1 bullseye
backport, as DLA 4379-1.
A couple of other important recurrent updates were prepared by Emilio Pozuelo,
who handled firefox-esr and thunderbird (in collaboration with Christoph
Goehre), published as DLAs
DLA 4370-1 and
DLA 4372-1,
respectively.
Contributions from fellows outside the LTS Team:
Thomas Goirand uploaded a bullseye update for
keystone
and
swift
As mentioned above, Christoph Goehre prepared the
bullseye update for thunderbird.
Mathias Behrle provided feedback about the tryton-server and tryton-sao vulnerabilities that were disclosed last month, and helped to review the bullseye patches for tryton-server.
Other than the regular LTS updates for bullseye, the LTS Team has also
contributed updates to the latest Debian releases:
Bastien Roucari s prepared a bookworm update for
squid,
the web proxy cache server.
Carlos Henrique Lima Melara filed a bookworm point update
request for gdk-pixbuf to fix
CVE-2025-7345, a heap buffer overflow vulnerability that could lead to
arbitrary code execution.
Daniel Leidert prepared bookworm and
trixie updates for r-cran-gh to fix
CVE-2025-54956, an issue that may expose user credentials in HTTP responses.
Along with the bullseye updates for unbound mentioned above, Guilhem helped
to prepare the trixie update
for unbound.
In collaboration with Lukas M rdian, Tobias Frost prepared
trixie and
bookworm
updates for log4cxx, the C++ port of the logging framework for JAVA.
Jochen Sprickerhof prepared a bookworm update for syslog-ng.
Utkarsh completed the bookworm update
for wordpress, addressing multiple security issues in the popular blogging
tool.
Beyond security updates, there has been a significant effort in revamping our
documentation, aiming to make the processes more clear and consistent for all
the members of the team. This work was mainly carried out by Sylvain, Jochen
and Roberto.
We would like to express our gratitude to the sponsors for making the Debian
LTS project possible. Also, special thanks to the fellows outside the LTS
team for their valuable help.
We re happy to announce that
Debusine can now be used
to maintain APT-compatible add-on package repositories for Debian. This
facility is available in public beta to Debian developers and maintainers.
Why?
Debian developers typically put most of their effort towards maintaining the
main Debian archive. However, it s often useful to have other places to
work, for various reasons:
Developers working on a set of packages might need to check that changes
to several of them all work properly together on a real system.
Somebody fixing a bug might need to ask affected users to test the fix
before uploading it to Debian.
Some projects are difficult to package in a way that meets Debian policy,
or are too niche to include in Debian, but it s still useful to distribute
them in a packaged form.
For some packages, it s useful to provide multiple upstream versions for
multiple Debian releases, even though Debian itself would normally want to
keep that to a minimum.
The Ubuntu ecosystem has had PPAs for a long time to meet these sorts of needs, but
people working directly on Debian have had to make do with putting things
together themselves using something like
reprepro or
aptly. Discussions about this have been
happening for long enough that people started referring to PPAs for Debian
as bikesheds , and users often find themselves trying to use Ubuntu PPAs on
Debian systems and hoping that dependencies will be compatible enough for
things to more or less work. This clearly isn t ideal, and solving it is
one of Freexian s objectives for Debusine.
Developers publishing packages to Debusine repositories can take advantage
of all Debusine s existing facilities, including a battery of QA tests and
regression tracking (coming soon). Repositories are signed using
per-repository keys held in Debusine s signing service, and uploads to
repositories are built against the current contents of that repository as
well as the corresponding base Debian release. All repositories include
automatic built-in snapshot capabilities.
Who can use this service?
We ve set up debusine.debian.net to allow
using repositories. All Debian
Developers and Debian
Maintainers can log in there and
publish packages to it. The resulting repositories are public by default.
debusine.debian.net only allows packages with licences that allow
distribution by Debian, and it is intended primarily for work that could
reasonably end up in Debian; Freexian reserves the right to remove
repositories from it.
How can I use it?
If you are a Debian contributor, we d be very excited to have you try this
out, especially if you give us
feedback.
We have published instructions for
developers on using
this. Since this is a beta service, you can expect things to change, but
we ll maintain compatibility where we can.
If you re interested in using this in a commercial setting, please contact
Freexian to discuss what we can do for you.
Boost is a very large and
comprehensive set of (peer-reviewed) libraries for the C++ programming
language, containing well over one hundred individual libraries. The BH package provides a
sizeable subset of header-only libraries for (easier, no linking
required) use by R. It is fairly
widely used: the (partial) CRAN mirror logs (aggregated from the cloud
mirrors) show over 41.5 million package downloads.
Version 1.90.0 of Boost was released a few days ago following the
regular Boost release schedule of April, August and December releases.
As before, we packaged it almost immediately and started testing
following our annual update cycle which strives to balance being close
enough to upstream and not stressing CRAN and the user base too much.
The reverse depends check revealed only one really minor issue among the
over three hundred direct reverse dependencies. And that issue was
addressed yesterday within hours by a truly responsove maintainer (and
it helped that a related issue had been addressed months earlier with
version 1.89.). So big thanks to Jean-Romain Roussel for the
prompt fix, and to Andrew
Johnson for the earlier test with 1.89.0.
As last year with 1.87.0, no new Boost libraries were added to BH so the (considerable)
size is more or less unchanged. It lead to CRAN doing a manual
inspection but as there were no other issues it sailed through as is now
in the CRAN repository.
The short NEWS entry follows.
Changes in version
1.90.0-1 (2025-12-13)
Upgrade to Boost 1.90.0, patched as usual to comment-out
diagnostic suppression messages per the request of CRAN
Minor upgrades to continuous integration
Via my CRANberries, there
is a diffstat report relative to the previous
release. Comments and suggestions about BH are welcome via the issue
tracker at the GitHub
repo.
DebConf Video Team Sprint
The DebConf Video Team records, streams, and publishes talks from DebConf and
many miniDebConfs. A lot of the infrastructure development happens during setup
for these events, but we also try to organize a sprint once a year to work on
infrastructure, when there isn t a DebConf about to happen. Stefano attended the
sprint in Herefordshire this year and
wrote up a report.
rebootstrap, by Helmut Grohne
A number of jobs were stuck in architecture-specific failures. gcc-15 and
dpkg still disagree about whether PIE is enabled occasionally and big endian
mipsen needed fixes in systemd. Beyond this regular uploads of libxml2 and
gcc-15 required fixes and rebasing of pending patches.
Earlier, Loongson used rebootstrap to create the initial package set for
loong64 and Miao Wang now submitted their changes. Therefore, there is now
initial support for suites other than unstable and use with derivatives.
Building the support for Software Bill Of Materials tooling in Debian, by Santiago Ruano Rinc n
Vendors of Debian-based products may/should be paying attention to the evolution
of different jurisdictions (such as the CRA
or updates on CISA s Minimum Elements for a Software Bill of Materials)
that require to make available Software Bill of Materials (SBOM) of their
products. It is important then to have tools in Debian to make it easier to
produce such SBOMs.
In this context, Santiago continued the work on packaging libraries related to
SBOMs. This includes the packaging of the SPDX python library (python-spdx-tools),
and its dependencies rdflib
and mkdocs-include-markdown-plugin.
System Package Data Exchange (SPDX), defined by ISO/IEC 5962:2021, is an open
standard capable of representing systems with software components as SBOMs and
other data and security references. SPDX and CycloneDX (whose python library
python3-cyclonedx-lib was
packaged by prior efforts this year),
encompass the two main SBOM standards available today.
Miscellaneous contributions
Carles improved po-debconf-manager:
added checking status of bug reports automatically via python-debianbts;
changed some command line options naming or output based on user feedback;
finished refactoring user interaction to rich; codebase is now flake8-compliant;
added type safety with mypy.
Carles, using po-debconf-manager, created 19 bug reports for translations
where the merge requests were pending; reviewed and created merge requests for
4 packages.
Carles planned a second version of the tool that detects packages that
Recommends or Suggests packages which are not in Debian. He is taking ideas from
dumat.
Stefano did miscellaneous python package updates: mkdocs-macros-plugin,
python-confuse, python-pip, python-mitogen.
Stefano reviewed a beets upload for a new maintainer who
is taking it over.
Stefano handled some debian.net infrastructure requests.
Stefano updated debian.social
infrastructure for the trixie point release.
The update broke jitsi.debian.social, Stefano put some time into debugging it
and eventually enlisted upstream assistance,
who solved the problem!
Stefano worked on some patches for Python that help Debian:
GH-139914: The main HP
PA-RISC support patch for 3.14.
GH-141930: We observed
an unhelpful error when failing to write a .pyc file during package
installation. We may have fixed the problem, and at least made the error better.
GH-141011: Ignore missing
ifunc support on HP PA-RISC.
Helmut monitored the transition moving libcrypt-dev out of build-essential
and bumped the remaining bugs to rc-severity in coordination with the release team.
Helmut updated the Build-Profiles patch for debian-policy
incorporating feedback from Sean Whitton with a lot of help from
Nattie Mayer-Hutchings and Freexian colleagues.
Helmut discovered that the way mmdebstrap deals with start-stop-daemon may
result in broken output and sent a patch.
As a result of armel being removed from sid , but not from forky , the
multiarch hinter broke. Helmut fixed it.
Helmut uploaded debvm
accepting a patch from Luca Boccassi to fix it for newer systemd.
Colin packaged django-pgtransaction
and backported it to trixie , since it looks useful for Debusine.
Thorsten uploaded the packages lprng, cpdb-backend-cups, cpdb-libs and
ippsample to fix some RC bugs as well as other bugs that accumulated over time.
He also uploaded cups-filters to all Debian releases to fix three CVEs.
Hello, my name is Isoken, I m a software engineer and product manager from Nigeria. I am excited and grateful to begin this journey as an Outreachy intern working on the project Debian Images Testing with OpenQA .
I am particularly drawn to helping solve problems for people; it keeps bugging me till I can find a way to help. This interest in problem-solving and improving quality is what drew me to this project.
OpenQA is an automated test tool that simulates a user s interaction by looking at the screen and sending actions like mouse clicks and keyboard inputs. It takes screenshots and compares the image to known reference images to verify if the system is behaving correctly.
During the contribution phase (which was 4 weeks), I got to know about Debian software, it s different mode of installation and available different desktop environments, at first I felt intimidated as most of it was new to me, but the setup material and docs for the project made it easy for me, the fact that it looked like a gradual process, getting to know the program, registering the steps in mind and then take notes of every step and visuals, writing it in a way another developer would understand (this is called detail level 3), and then translate it to test code level 1.
I contributed to improving the installation documents and a detail level 3 doc for a bug report on the system locale being incorrect. This strengthened my documentation skills and ability to adjust to the writing style of the project.
I also started working on app start-stop tests for two desktop environments. I was able to explore, check the applications, and note their differences and similarities. It was really interesting to me; this was where I started writing on coding level 1, and my tests started passing. I will spend the next few weeks continuing on it and hopefully creating a way to synergize the tests and make it easy to maintain later on.
I am also grateful for the assistance from other candidates during the contribution stage and the privilege of having the mentors, Tassia Camoes Araujo and Roland Clobus, and Philip Hands, to guide and correct me through the internship period. I will share my progress regularly here on the blog. You can follow the progress of the work here on the main repo.
Wish me luck on the rest of this journey
Hello there . I am a software developer and tester. Some of my interests include bash scripting , website full-stack development and also open source software contribution.
Outreachy is dedicated to the open source community. The OpenQA community in itself had the right project I wanted to contribute to. It was a really great match for my interests and skills. The project is Debian Images testing with OpenQA.
The contribution period was very intense. It was a learning phase at first. I made adjustments to my computer to ensure it would handle the tasks. I also had many trials , failures and problem solving to do. There was a lot of questions asked. My mentors were really helpful.
What worked for me in the end was:
Communicating in the social network with fellow contributors and helping out whenever they got stuck.
Writing the small steps I made during the contribution period, from dual booting to all errors encountered and the ways I solved them in a google docs application.
The small steps I made and the word application were then added to the list of contributions I made.
I also wrote and edited the main application in small phases and was detailed on my experiences
Last but not least I did work on my first task. It was speech testing and capturing all audio. I got a lot help from the mentors through out the process.
Every week is a learning phase to me. I encounter newer issues , lets say my latest issue was connecting the Virtual Machine to a newer Wi-Fi network. It took a whole day to get a solution but I eventually solved it. I regularly share my issues and write the solutions so that it would be helpful to anyone in the future.
By the end of the internship period, I hope to have contributed to the Debian OpenQA Open Source community.This is by working on the tasks and working with the Opensuse broader community on any issues. I want to build a network with my mentors: Philip, Tassia, Roland and other mentors in the community in order to create future opportunities for contributions, mentoring and just general communication.
Yeah, again three months have passed since my last (trivial) post, and I really
don t know where the time has flown.
I suppose the biggest problem was the long summer vacation, which threw me
off-track, and then craziness started. Work work work, no time for anything,
which kept me fully busy in August, and then you should travel .
So mid-September I went on my first business trip since Covid, again to
Kirkland, which in itself was awesome. Flew out Sunday, and as I was concerned I
was going to lose too much fitness had a half-marathon planned on the weekend
after the return I ran every morning of the four days I was there. And of
course, on the last day, I woke up even earlier (05:30 AM), went out to run
before sunrise, intending to do a very simple run along the road that borders
the lake for 2.5K, then back . And right at the farthest point, a hundred metres
before my goal of turning around, I tripped, started falling, and as I was
falling, I hit sideways a metal pole. I was in a bus station, it was the pole
that has the schedule at the top, and I hit it at relatively full speed, right
across my left-side ribs. The crash took the entire air out of my lungs, and I
don t remember if I ever felt pain/sensation like that I was seriously not able
to breathe for 20 seconds or so, and I was wondering if I m going to pass out at
this rate.
Only 20 seconds, because my Garmin started howling like a police siren, and the
screen was saying something along the lines of: Incident detected; contacting
emergency services in 40 35 and I was fumbling to cancel that, since a) I
wasn t that bad, b) notifying my wife that I had a crash would have not been a
smart idea.
My left leg was scraped in a few places, my left hand pretty badly, or more than
just scraped, so my focus was on limping back, and finding a fountain to wash my
injuries, which I did, so I kept running with blood dripping down my hand. Fun
fun, everything was hurting, I took an Uber for the ~1Km to the office, had many
meetings, took another Uber and flew back to Zurich. Seattle San Francisco
Z rich, I think 14 hours, with my ribs hurting pretty badly. But I got home
(Friday afternoon), and was wondering if I can run or not on Saturday.
Saturday comes, I feel pretty OK, so I said let s try, will stop if the pain is
too great. I pick up my number, I go to the start, of course in the last block
and not my normal block, and I start running. After 50 metres, I knew this won t
be good enough, but I said, let s make it to the first kilometre. Then to the
first fuelling point, then to the first aid point, at which moment I felt good
enough to go to the second one.
Long story short, I ran the whole half marathon, with pain. Every stop for
fuelling was mentally hard, as the pain stopped, and I knew I had to start
running again, and the pain would resume. In the end, managed to finish: two and
a half hours, instead of just two hours, but alive and very happy. Of course, I
didn t know what was waiting for me Sunday I wake up in heavy pain, and despite
painkillers, I was not feeling much better. The following night was terrible,
Monday morning I went to the doctor, had X-rays, discussion with a radiologist.
Not really broken, but more than just bruised. See this angle here? Bones don t
have angles normally . Painkillers, chest/abdomen wrapping, no running! So my
attempts to not lose fitness put me off running for a couple of weeks.
Then October came, and I was getting better, but work was getting even more
crazy. I don t know where November passed, honestly, and now we re already in
December. I did manage to run, quite well, managed to bike a tiny bit and swim a
little, but I m not in a place where I can keep a regular and consistent
schedule.
On the good side, I managed this year, for the first time since Covid, to not
get sick. Hey, a sport injury is 100 better than a sickness, like I had in
previous years, taking me out for two weeks. But life was crazy enough that I
didn t read some of my email accounts for months, and I m just now starting to
catch up to, well, baseline.
Of course, the rib the lowest one on the left side is long-healed, or so I
thought. After some strength training early this week, I was very sore the next
day, and I wanted to test whether my rib is still sore. I touched it at the
point , and it hurt so badly I couldn t believe. Two and a half months, and it s
not done-done.
And now it s just two weeks before Christmas and New Year s, and that time off
will ruin my rhythm again. At least ski vacation is booked, ski service is done,
and slowly, work is getting in good enough shape to actually enjoy thinking
about vacation.
So, in the end, a very adventurous last third of the year, and that wasn t even
all. As I m writing this, my right wrist is bandaged and for the past 24 hours
it hasn t hurt too much, but that s another, and not so interesting, story.
I ll close with a yay for always being behind/backlogged, but alive and
relatively well. My sport injuries are elective injuries so to speak, and I m
very thankful for that. See you in the next post!
2026 already! The winter weather here has really been beautiful and I always enjoy
this time of year. Writing this yearly musical retrospective has now become a
beloved tradition of mine1 and I enjoy retracing the year's various
events through albums I listened to and concerts I went to.
Albums
In 2025, I added 141 new albums to my collection, around 60% more than last
year's haul. I think this might have been too much? I feel like I didn't have
time to properly enjoy all of them and as such, I decided to slow down my
acquisition spree sometimes in early December, around the time I normally do the
complete opposite.
This year again, I bought the vast majority of my music on Bandcamp. Most of
the other albums I bought as CDs and ripped them.
For navigation I implemented a sidebar, that is hidden on small screens but can
be toggled using a burger menu.
I also stumbled upon 
Here are my favourite books and movies that I read and watched throughout 2025.
A new release of my mixed collection of things package 
We announced a public beta of
You can see that not all of the workflows are successful. This is because
we currently just show everything in every workflow; we don t consider
whether a task was retried and succeeded on the second try, or whether
there s now a newer version of a reverse-dependency so tests of the older
version should be disregarded, and so on. More fundamentally, you have to
look through each individual workflow, which is a bit of a pain: we plan to
add a dashboard that shows you the current state of a suite as a whole
rather than the current workflow-oriented view, but we haven t started on
that yet.
Drilling down into one of these workflows, it looks something like this:
This was the first package I uploaded. The first pass of failures told me
about 
Again, there were some retries involved here, and also some cases where
packages were already failing in unstable so the failures weren t the fault
of my change; for now I had to go through and analyze these by hand, but
we ll soon have regression tracking to compare with reference runs and show
you where things have got better or worse.
After excluding those, that left 
I recently won 
The Debian LTS Team, funded by [Freexian s Debian LTS offering]
(
