In 2025 I was honored to be selected for the first cohort of Sovereign Tech Fellows, a program by Germany s Sovereign Tech Agency to improve the resilience of the open source ecosystem by supporting maintainers directly (complementing their existing support for larger FOSS organizations). Back in 2025, I was only working very limited hours however, this has changed in 2026.

For the second half of 2026, I am working again as a Sovereign Tech Fellow, but this time with significantly increased hours. After finishing my PhD, I do have time now for new tasks (and new jobs!), and the fellowship presents an amazing opportunity to really advance projects that I maintain or am part of. This also has a very nice effect on contributors and bug reporters, as their feedback gets addressed a lot faster. With some luck, this ultimately will help finding new (co)maintainers for projects as well (although in the age of AI, a lot of how open source used to work is much more uncertain, but that is a matter for a different blog post).

The fellowship is time-limited, so I am intending to make the time I currently have count!

So, what s planned?

I am involved in many projects, but three of them will be getting attention as part of the fellowship. I know I am notoriously slow at blogging, but expect more details on each of them very soon. Here s an overview:

Freedesktop.org, Specifications and Organization

I maintain the Freedesktop Specifications, which is an area of Freedesktop that has traditionally been a bit chaotic. This worked in the past, because Freedesktop was never intended to be a formal standards body, but more a shared space where people could throw a lot of code and ideas over the wall and see what sticks and what people can collaborate on.

While I very much love the spirit of this and want to keep it in some form, we definitely would benefit not just from more formalization and better procedures, but also from better organization of the specifications in general. A lot of conflicts can be avoided by that. I will work on improving procedures, crunching through the (lots!) of pending bug reports and MRs, and to make the specifications site better searchable and accessible (similar to how Mozilla s MDN presents information, but I am not sure if we will get quite that far). I also intent to add a compatibility matrix for specifications, so if a desktop opts out of any one of them (or does not implement them yet) that fact is documented and authors of applications know what they can expect. This will allow us to move a lot faster and avoid a lot of conflict, because there is no implicit assumption that everybody will implement everything anymore (which has never been quite true anyway).

Hopefully, this will ultimately result in a Freedesktop that is both a lot more useful for application authors who want to bring their project to Linux, as well as developers of desktop environments who need to see which specifications are available and which ones are current.

In addition to that, I have also worked on a Freedesktop.org website refresh, which is pretty much done in its first iteration (pending sysadmin action). The aim there is to have a more official website, separate from user-contributed wiki content, that showcases what Freedesktop is and which projects are using it for hosting. Once the new website is live, I will also review every page again, archive dead projects in their own section and reorganize the software and specifications directory. Those sections are severely outdated and are missing recent efforts from the community, while still containing long-dead old projects (remember HAL? ).

AppStream

A lot of extra maintenance work will be (has been!) done on it. This includes things such as JPEG-XL support (blog post soon), sandboxed media processing, support for newer specification additions, better OARS integration (and potentially migrating it to fd.o infrastructure), improvements and API stabilization for libappstream-compose and a lot of bugfixing and resolution of issues found by AI code review.

AppStream was originally designed to parse only trusted data from vetted Linux distribution sources this is no longer the case in today s world and in the way Flatpak uses it, so we need to increase resilience of the project.

I am also exploring a project that could vastly improve search accuracy for AppStream. Stay tuned for that.

PackageKit & System Upgrades

Many years ago, people thought we would all migrate to atomic Linux distributions and slowly not need PackageKit anymore. This has not turned out to be the case, and there are still plenty of reasons to use a package-based OS, especially in development environments. At the same time, PackageKit has been basically the same for years, and its older architecture is beginning to show. It being a daemon who s literal job it is to modify the entire system also makes it one of the most security-sensitive components that a Linux system can have, while simultaneously making it near-impossible to sandbox.

My plan is to create PackageKit 2.0 by building on the great foundation of PackageKit 1.0, but modernizing it. This will include simplifying its code and removing a bunch of features that have no more use in modern desktops, while also adding some features that PackageKit never had but that would be useful to expose to frontends (still no to interactivity an terminal-progress forwarding though!). PK 2.0 will also allow me to solve a few design issues that have been worked around in the past, by replacing them with better solutions. This will be a painful transition, as PackageKit 2.0 will break all interfaces PackageKit has and those interfaces have been frozen for more than a decade. However, I do fully expect this change to be worth the effort.

In addition to that, I intend to look into the offline-update procedure again and improve it. The current multi-reboot operation comes with downsides, that newer systemd features such as soft-reboot can alleviate. The end result should be a much smoother, less annoying offline-update experience for users (I especially want to get rid of updates running on system startup, which I consider quite bad from a usability perspective). The new behavior is in the early drafting stages and may need direct support from systemd. I will share more about it once I can.

That s a lot of tasks!

Yes! I will see how far I get. I am moving project-by-project though, to allow me to focus on one project at a time, rather than scattering my attention continuously. Amazingly, this means that the major tasks for AppStream are already almost done, and we are nearing the 1.2.0 release. AppStream got priority, because the new Freedesktop Flatpak runtime will be released soon, and because I want FlatHub/Flatpak to have access to the new AppStream release sooner. Freedesktop and PackageKit are next on the task list.

Either way, a lot of progress is coming if you have any feedback or want to help out, please don t hesitate to reach out! All work is happening fully in the open, so you can also chime in on the respective GitHub/GitLab tasks .

You can also expect blog posts about key features or interesting changes, so stay tuned!

TL;DR: What a great DebConf! I managed to recharge my Debian batteries, and my talks / BoF sessions all went fine. Already looking forward to DebConf in Japan next year!

DebCamp

The evening before DebCamp started, we had a nice bbq (we taught some locals to call it a braai at an organiser s house and went for a walk around the river as the sun set. It was a very peaceful lead-in to DebCamp.

• I set up and sent out the call for Forky desktop artwork:
  • https://lists.debian.org/msgid-search/910906f3-7ce4-4884-a49f-4b4a5975471b@debian.org
• Had many nice discussions about various Debian topics with all the Debian people around. It s really fun being around people who are natural problem solvers who care deeply about both technical and social issues. At one point Jonas told me Holy shit, these people are motivated! and I appreciate that so much too!

Debian LTS wine

• Most of my DebCamp was dedicated to preparing for my demo and main talk that followed at DebConf.
• Sadly, we had no loopy this year, I just didn t have the time, and the people who stepped up to help last year were either overwhelmed with other issues or couldn t make it. I ll try to make it happen again for next year by kicking it off long before DC27.

View of Santa Fe city from hotel

DebConf

Talk Is it even possible to build a truly universal system installer?

In this talk I do a very quick comparison of system installers based on my experience with them. It s hard to directly compare all of them, since there are so many, and each have their own niche that they attempt to satisfy.

I also introduce Yasi my attempt to answer the question of whether we could build a universal installer, which can also better cover advanced installations, automated installations and niche setups.

It s very early days for the project, and I didn t quite feel ready to share the code with the world, but it was nice that I did a quick demo where I could install a Debian system and the resulting system actually booted up. *phew*.

This is also going to be my main focus for the mid-term future. I aim to have all the basic partitioning options working by the time Debian 14 (Forky) is released, and by the time Debian 15 is released, I have a long list of features that I aim to have working. So, my timeline for having something that s generally useful is around a year from now, and in around 3 years it should be a fully fledged installer that should cover a very large amount of Debian use cases and architectures.

Day Trip

For the day trip, we did a tour across Santa Fe, visited Constituci n de la Naci n Argentina, had lunch where we tried various dishes based on local fish from the river, and then went on a boat ride on the river.

BoF Sessions:

Funding in Free Software Projects: I initially registered this BoF because I m increasingly concerned about how upstreams are asking for donations in their software. I increased the scope to talk about funding in free software in general. It followed Marga s talk about funding, which focussed more about how developers are funded in general. We didn t dive very deep into this, but we certainly need some further discussion (and action) on this within Debian.

Debian Social Team: My most important issue for this team is a carry-over from last year, I want to set up barman (packaged in Debian) for live postgres syncing for our larger databases. For the smaller DBs, doing a daily dump is quite cheap. But for Matrix, it s very expensive in terms if i/o and CPU, so it would be ideal to do less regular complete dumps and use live replication for the first line of redundancy instead.

Images Team: I wasn t initially planning to say much during this session, I have some ideas to reduce both size and count of images, without losing any benefits, but I don t have any work to show for that yet. I ended up talking a lot more than I anticipated, the topics covered were quite good and representative of the current state of Debian images built. I don t have time to create a full summary, so I suggest checking the etherpad / video recording if you re interested.

Some more wine variety during the conference dinner

Debianites in the main hacklab

Rosario

I m spending two days in Rosario before I head home. Exploring a bit, catching up with sleep, finishing this blog post, signing keys and exploring some ideas I made note of during DebConf.

Thank you to the DebConf26 Team!

It was a little surreal not being part of any DebConf team for the first time ever, I ve just been too focussed on getting Yasi ready for my talk (no regrets!). I hope to be more involved again next year, in the meantime, I m very grateful to everyone who has made this happen, you did a stellar job! I hope to see many of you again next year in Japan!

Changes in Rcpp release version 1.1.2 (2026-07-01)

• Changes in Rcpp API:
  • Use of execinfo.h is again conditional to avoid build complexity (Dirk in #1445 addressing #1442)
  • An internal state component for Datetime is now int (Dirk in #1448 and #1449 fixing #1447)
  • Three new (in R 4.6.0) attribute accessors are used conditionally (Dirk in #1450 closing #1432)
  • An UBSAN error in the Sugar-based NA comparison has been corrected (I aki in #1453 fixing #1452)
  • Treatment of Inf outside of integer range in Sugar function has been corrected (I aki in #1458 fixing #1455)
  • Integer overflow protection has been added for sugar functions (I aki in #1457 fixing #1454)
  • The parent environment is now accessed via R_ParentEnv (Dirk in #1460 fixing #1459)
  • Change to returning dataptr again for better handling of empty vectors (I aki in #1462 fixing #1461)
  • Undefined behavior errors in use of ListOf proxies have been addressed (I aki in #1464 fixing #1463)
  • Under newer R version, R_UnboundValue is no longer used (I aki in #1466 fixing #1465)
  • New R API access point R_getRegisteredNamespace() is used with current R versions (Dirk in #1469 fixing #1468)
  • The Nullable::as() exporter now uses an explicit cast to the templated type (Dirk in #1471 fixing #1470)
  • A memory leak in the variadic Rcpp::warning() template has been fixed (Kevin in #1475 fixing #1474)
  • The Nullable::operatorT() has been added as a 'opt-out' (Dirk in #1477 with coordination in #1472)
  • Add templated integer-index overload for operator[] on small systems such as WASM (Jeroen Ooms in #1482)
  • The attribute accessors in AttributeProxyPolicy no longer rely on get__() (Kevin in #1484 fixing #1483)
• Changes in Rcpp Documentation:
  • Reference in the bibliography used by the package vignettes have been updated.
• Changes in Rcpp Deployment:
  • Excute permissions are set consistently on scripts with shebangs (Mattias Ellert in #1467)
  • R 4.5.* has been added to the CI matrix (Dirk in #1476)
  • Three nag messages issued when obsolete build flag accessors are used now show Rcpp::: (Dirk in #1480 fixing #1456)
  • Reference GitHub Actions have been updated to their current versions (Dirk in #1481)
• Non-release Changes:
  • A non-release hotfix 1.1.1-1 used by CRAN accommodates breaking changes to the API in R 4.6.0. It would be nice to have the same level of release management in R itself that CRAN expects from us.

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

• [1] https://etbe.coker.com.au/2026/06/21/hp-z4-g4/
• [2] https://einsteinathome.org/
• [3] https://etbe.coker.com.au/2025/11/09/amd-video-driver-issues/

The first years During my first years, the department operated like a startup. Its cradle was the French company Echo. They built a search engine. France T l com bought it and renamed it Voila. It was the most visited search engine in France in the early 2000s. France T l com consolidated the portal activities into the Wanadoo Portails division, later renamed Orange Portails. The technical environment was excellent. We had many internal tools:³ a ticket system, an RRD-based graphing tool, an IPAM, a reporting tool, and an SNMP-based alerting tool.⁴ We deployed our Linux servers with CFEngine. We installed systems and applications from internal Debian repositories. We documented everything in a private MediaWiki instance. Supervision was performed with an ancestor of Xymon. The network architecture was clean and scalable with little legacy. We onboarded new people in a day. It was a nurturing environment for me. I developed several tools: lldpd, an 802.1AB implementation, Snimpy, a pythonic binding for Net-SNMP, Wiremaps, a layer-2 discovery tool with a time machine to know which device is connected where, Kit r , a tool to simulate network conditions, QCSS-3, a controller for load-balancers, and ipoo, a service available through a Jabber chatbot and a Greasemonkey script to expose IP-related information. I added SNMP support for Keepalived and Quagga. I also started this blog, with articles like Anycast DNS, TLS-related articles like TLS computational DoS mitigation, SNMP-related articles like Integration of Net-SNMP into an event loop, Linux-related articles like Tuning Linux IPv4 route cache, and an article about VXLAN long before it was cool.

The collapse When we needed new servers, the on-site team would take a set from the inventory, install our base Linux distribution on them, put them in the datacenter, and cable them to the top-of-the-rack switches. We opened a ticket describing the servers we needed, and one week later, our servers were available. Orange wanted to know if this team was performing well, so they asked for KPIs. They decided to use the number of tickets completed in a year. They asked to double this number. So instead of one ticket for a new service, we would open six tickets one per server. By the end of the year, the KPIs had more than doubled. Everybody saw it as a success for performance management. So, they asked to do the same for the next year. Now, we needed to open a ticket per server and per step. Again, the KPIs doubled. Behind the scenes, the tickets went to different people and were no longer handled in order. So, for the next year, it was decided to have meta-tickets and meetings to follow the progress of these tickets. Of course, all these extra steps pushed the KPI even higher. This performance management method spread to the other teams.⁵ Everything became slower. Instead of a couple of weeks, a new service now took six months. We built a Soviet nail factory. But the KPIs were good, and we stopped caring. Let me give you another example. We had to estimate the impact of each night operation. We weren t half bad: we declared most operations without any expected impact. Most of the time, there was no impact. One time out of five, there was a 5-second impact. We were told to try harder to meet our expected impact. What did we do? We started declaring a 5-second expected impact. One day, we got a 30-second impact and were told we failed to match the expected impact. In the end, we declared most operations with a 10-minute expected impact, and we stopped caring: instead of carefully shifting traffic around, we allowed ourselves a 5-minute impact. And our KPIs were never better.

An artist's rendering of the evolution of impacts over the years.

---

KPIs are not bad, but they are easy to break. Use them carefully: let the people doing the work help choose the metrics, and tie those metrics to the quality of the service for example, with service level objectives. Otherwise, even dedicated people stop caring, game the system, and eventually quit.⁶

---

1. Internally, this division was named Hebex. It was located in Bagnolet (next to Paris) and Sophia-Antipolis (near Nice).
2. Goodhart s law often gets the credit, but Campbell s law describes my experience even better: the more you lean on a number to make decisions, the faster people corrupt it.
3. At the time, SaaS was not really a thing. I remember we considered, with a couple of colleagues, selling Wiremaps as a SaaS, with homomorphic encryption for the database. But who would outsource their observability stack?
4. Snalert was a metacircular alerting tool in Perl. It was able to poll a very large number of SNMP targets in a short timespan. All our monitoring was SNMP-based, including system monitoring.
5. My team also managed the rules of many Linux-based firewalls. To increase our KPIs, we used the same method: rather than accepting one ticket with a flow matrix, we requested one ticket per flow.
6. Orange is not unique. Google s promotion process is another well-known example of a broken KPI. Michael Lynch explains it in Why I Quit Google to Work for Myself.

• the RISC-V CPU architecture is open source,
• the price point is within reach of home and small business users and
• the overall feature set makes it an ideal platform to build local and offline AI systems.

Comparing the resellers SpacemiT does not sell anything directly to consumers. Instead you need to buy a board that includes the K3 chip from an integrator. Currently the main resellers are:

• Milk-V
• Sipeed
• Banana Pi
• Firefly
• DeepComputing

All of the above are Chinese companies that ship to customers both inside and outside China. DeepComputing stands out as the only one that actually has done real integration and ships the K3 on a custom board, while the others simply resell the SpacemiT-produced K3 pico-ITX and K3 CoM260 Kit.

Milk-V Milk-V is a RISC-V specialized integrator, as the name already implies. They sell the K3 under the name Jupiter2. Of all the K3 pico-ITX reseller product pages, the Jupiter2 presentation is the nicest and most detailed. Unfortunately their order page at arace.tech only states that it is a pre-order with no information about shipping schedule, taxes, or other details like what SSD is included (if any). Based on the pictures it does ship with a Milk-V branded case. The 32 GB RAM lists at 504 EUR, which is a very reasonable price. The @MilkV_Official account on X recently promoted the K3.

Documentation and support As of this writing, the Milk-V Jupiter2 documentation site is just a stub and has no actual content, and only two links to the SpacemiT K3 documentation site. For support there is a web forum with a dedicated Jupiter2 section. There is also a Matrix space, but unlike their other products, there is no dedicated Jupiter (neither v1 nor v2) channel.

Community size and open source involvement At least one prior Milk-V product was certified by Canonical, which indicates there is some collaboration in progress. Canonical also lists the Milk-V Titan on its official Ubuntu for RISC-V partner-built hardware page.

Sipeed The Sipeed K3 announcement is well written (in English) with all the relevant details and links to additional PDF manuals. However, their main page at sipeed.com says nothing about the K3, so one must know the subpage URL to access it. They offer both the K3 CoM260 kit compatible with Jetson Orin Nano carrier boards, and the stand-alone K3 pico-ITX-sized motherboard. The CoM260 kit is only 10 USD cheaper than the full pico-ITX motherboard, so choosing the latter is a no-brainer if starting from scratch. The pico-ITX model with 32 GB DDR5 RAM sells for 639 USD. The product page does not mention anything about hard disk size, so you don t really know exactly what you will be getting if placing an order. There is no indication about case, Wi-Fi antennas or power supply either, so most likely they are not included. Their store.sipeed.com website does not work at all, and their Taobao and AliExpress stores are not public and only accessible to registered users. The order page also says nothing about shipping time, delivery time, or taxes. The X account @SipeedIO is active and recently posted pictures of shipments in progress.

Documentation and support The main documentation wiki does not yet have any K3 content at the time of writing. There is a Discord channel for general RISC-V discussion, and their MaixHub also has a discussion board, but I didn t find anything K3-specific.

Community size and open source involvement Sipeed has had at least one of their previous devices certified by Canonical, which indicates they are active in the community. Note that the other RISC-V company SiFive that also has had hardware certified and officially supported by Canonical is a different company, despite the very similar name.

Banana Pi Banana Pi announced that they offer both the K3 CoM260 kit and the K3 pico-ITX motherboard version. Their product page for the K3 confusingly shows a MediaTek product in the page banner rather than the SpacemiT K3. Based on the product description and the fact they renamed the product as BPI-SM10, it seems to ship with some carrier board. The product pictures look identical to the SpacemiT documentation and there is no picture of the carrier board, and details are very sparse. The pico-ITX version with 8 GB RAM and 128 GB SSD sells for 293 USD and the CoM260 developer kit with the same specs sells for 287 USD and the 32 GB RAM with 128 GB SSD model sells for 595 USD. The shop page shows only five orders so far and items are currently out of stock. As there was no 32 GB RAM version of the pico-ITX available at all, this isn t an option for me as I want to run 30B parameter models that need the larger memory version. Of all of these resellers, the Banana Pi website seems the most outdated. It does not have a search feature, it is not mobile-friendly, pictures can t be pinched to zoom in and so forth. Product names are also almost all identical, and as the product listings only show the beginning of the product name, figuring out what product is what requires extra effort that just makes the online purchase experience plain bad.

Documentation and support I was only able to find the documentation page for the CoM260 kit, but none for the pico-ITX version. For support there is a forum, but the category list does not show any section for K3, and the forum search prohibits using the search term k3 as too short.

Community size and open source involvement Banana Pi has a long history in the ARM single-board computer market, but their presence in the RISC-V ecosystem is still growing. Their X account @sinovoip has posted only once about the K3 and otherwise promotes their ARM boards. However, their community culture page does express a commitment to open hardware in general, but there is no visible K3-specific community activity.

Firefly Firefly s K3 product page is comprehensive. Based on the details, they do not offer the K3 pico-ITX variant at all, but only the K3 CoM260 board inside the AIBOX-K3 Firefly RISC-V Edge Mini PC product. This is a feature-complete offering with a Jetson Orin Nano carrier board and case. The AIBOX-K3 with 32 GB RAM and 128 GB SSD in a case sells for 689 USD in their own Firefly.store. Unfortunately it only has HDMI and there is no USB-C with DisplayPort support, which is a deal-breaker for me personally. Interestingly, Firefly also offers rack-mounted servers with K3 as the CPU.

Documentation and support The wiki link on the product page is broken. The Firefly wiki does have a section for the AIBOX-K3, but it too has a broken link. It seems that as of the time of writing, there is no wiki section for this product yet. For support there is a web forum, which does have at least one K3 thread covering guides such as Hermes Agent installation, though broader K3-specific sections are still sparse.

Community size and open source involvement Firefly s X account @TeeFirefly has had no posts since 2024, and their GitLab/T-Firefly shows mostly 2024 activity, with only one repository updated in 2025 and nothing in 2026. Historically they have built a moderate community around their ARM-based Rockchip boards, with active forums and wiki contributions for those product lines. Their RISC-V K3 offerings are newer, and likely need a lot more polish to be attractive products overall.

DeepComputing Last, but certainly not least, is the laptop manufacturer DeepComputing that offers a Framework laptop compatible motherboard with the SpacemiT K3 chip. They also sell the plain motherboard, or with the Cooler Master case, which allows one to easily connect it to an external monitor and keyboard and use it as a desktop computer. The plain board with 32 GB RAM and no SSD sells for about 882 EUR. Shipping of the first batch is expected to start by end of June 2026. Their X account @DeepComputingio promotes this DC-ROMA RISC-V Mainboard III as their flagship product, so they seem to put a lot of effort into it. The overall product design and packaging seems good. Of all the K3 resellers and integrators that I was able to find, DeepComputing is the only one that actually designs their own boards with the K3 processor, while all the other vendors above are simply reselling the vanilla K3 boards with or without a case. After reviewing all these options I decided to buy the DC-ROMA RISC-V Mainboard III for Framework Laptop 13 with 32 GB RAM, 1 TB SSD and the Cooler Master case, totalling about 1100 EUR.

Documentation and support DeepComputing maintains product information for their RISC-V hardware at github.com/DC-DeepComputing/Framework, with documentation of the newest Mainboard III (FML13V05) still being finalized ahead of the first batch shipment. They provide community support through Discord and web forum, although the latter has very little activity.

Community size and open source involvement DeepComputing has established itself as a pioneer in RISC-V laptops, beginning with the DC-ROMA. I have seen their stand at FOSDEM, which shows they are genuinely active in the open source community. Canonical lists DeepComputing s first mainboard / FML13V01 on its official Ubuntu for RISC-V partner-built hardware page, and it seems likely that they will continue to collaborate with Canonical with the new model once it ships. While the underlying Linux enablement depends on SpacemiT s upstream efforts, DeepComputing s involvement helps bridge the gap between reference hardware and consumer-ready products.

Conclusion After weighing all the options, I ended up placing an order with DeepComputing for their custom K3 board with the Cooler Master case. Despite the premium price, the active community support and the properly documented promise of a complete, working system made it easy to place an order with confidence. The SpacemiT K3 is poised to be one of the most significant RISC-V chips for local AI workloads, thanks to its RVA23 compliance and high tokens per second potential. Yet the buying experience in mid-2026 remains fragmented and incomplete. Hopefully this is just because the product is new, and they will get the purchase experience polished soon. What struck me most during this process was how poor the customer experience is across nearly all of these vendor websites: broken links, missing search functions, outdated product banners, pages that show the wrong product entirely, and no information about shipping times, stock levels, taxes, and so on. One wonders why these companies don t fully invest in their web presence. Personally I would assume they likely have enough customers already, primarily through domestic channels like Taobao and JD.com, that they do not feel any pressure to improve their international-facing sites. However, I did also review what was offered on Taobao, and the product details were very incomplete there too. Taobao, however, has a built-in live chat with almost all sellers, which can be used to ask questions and thus compensate for missing product details. I don t fully understand why the sales process seems unpolished. The websites feel almost like an afterthought a checkbox to claim global reach while the real business apparently happens elsewhere via closed platforms or via inaccessible reseller channels. It is a frustrating reminder that in the RISC-V hardware world, the technology may be open and global, but the purchase experience is less so.

What is Mentoring Mondays? Mentoring Mondays is a recurring video call that lasts roughly 45 minutes with the agenda:

• Weekly walk-through: demo of something in Debian packaging, explaining the what and why
• Discussion on pros and cons to help participants develop their judgment
• Questions & answers on Debian packaging, or open source contributing in general

This is ideal for you if you:

• Have built a .deb package at least once and want to do it better
• Are stuck on a specific Debian packaging bug and need guidance
• Want to understand how Debian Developers actually work day-to-day

The call is mainly intended for those who want to contribute to Debian (or Debian derivatives, with Ubuntu being the most popular), but anyone can join to learn about things related to contributing to a Linux distribution. Please note that video chat uses Debian Social Jitsi. Joining the call requires authentication using a Salsa account, which anyone contributing to Debian should have anyway. Calls are not recorded, so participants can chat freely, and are also encouraged to be on-camera for an enhanced sense of community.

Next call: Monday May 4th, 2026

• Time: Monday May 4th, 2026 at 12:30 UTC
• Calendar event: Download 2026-05-04.ics
• Meeting URL: https://jitsi.debian.social/MentoringMondays

Make sure you are logged into Salsa first, before opening the call on Debian s Jitsi instance.

Matrix channel and future meeting time announcements Please join the Matrix channel #mentoringmondays:matrix.debian.social if you plan to attend Mentoring Mondays. All future meeting times will be announced there. It is also the channel to post questions about Debian packaging to be answered during the call. The current meeting time is friendly to people in Europe, Asia and Australian time zones, and will repeat at the same time slot on:

• May 11th, 2026 at 12:30 UTC
• May 18th, 2026 at 12:30 UTC
• May 25th, 2026 at 12:30 UTC
• June 1st, 2026 at 12:30 UTC
• June 8th, 2026 at 12:30 UTC

Starting in mid-June the meeting time will change to accommodate participation in different time zones.

Spread the word Feel free to extend the invite to anyone you think might be interested in joining! If you mention this on social media, please post using tag #mentoringmondays, or simply boost the existing posts on the social media of your preference: Mastodon, Lemmy, Reddit, Bluesky, LinkedIn, Farcaster, X.

Thanks A big thanks to Jason Kregting for helping organize. I would also like to thank in advance all the Debian Developers who are able to join the call and be available to participate in discussions and help answer questions.

1. Make it possible to reply directly to a message from a support person. Accept email with a custom subject to sort it, give a URL for a web form, anything. Collating discussions with a customer allows giving better support while taking less time for the support people.
2. Have someone monitor every social media address that is used by the company. When someone sends a support request in a public Mastodon post it indicates that something has gone wrong and you want to move quickly to resolve it.
3. Take care of the little things, like sending a tracking number for every parcel. If it s something too small for a parcel (the SIM caddy could have fit in a regular letter) then just tell the customer what date it was posted and where it was posted from so they have some idea of when it will arrive.

• [1] https://etbe.coker.com.au/2026/01/19/furilabs-flx1s/
• [2] https://etbe.coker.com.au/2025/08/19/colmi-p80-smartwatch/
• [3] https://github.com/FuriLabs/issue-tracker/issues/216
• [4] https://tinyurl.com/27vkulbr

# dig -t txt _spf.google.com grep spf1
_spf.google.com.	300	IN	TXT	"v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ip6:2001:4860:4864::/56 ip6:2404:6800:4864::/56 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"
# dig -t txt outlook.com grep spf1
outlook.com.		126	IN	TXT	"v=spf1 include:spf2.outlook.com -all"
# dig -t txt _spf.mail.yahoo.com grep spf1
_spf.mail.yahoo.com.	1800	IN	TXT	"v=spf1 ptr:yahoo.com ptr:yahoo.net ip4:34.2.71.64/26 ip4:34.2.75.0/26 ip4:34.2.84.64/26 ip4:34.2.85.64/26 ip4:34.2.64.0/22 ip4:34.2.68.0/23 ip4:34.2.70.0/23 ip4:34.2.72.0/22 ip4:34.2.78.0/23 ip4:34.2.80.0/23 ip4:34.2.82.0/23 ip4:34.2.84.0/24 ip4:34.2.86.0" "/23 ip4:34.2.88.0/23 ip4:34.2.90.0/23 ip4:34.2.92.0/23 ip4:34.2.85.0/24 ip4:34.2.94.0/23 ?all"
# dig -t txt icloud.com grep spf1
icloud.com.		3586	IN	TXT	"v=spf1 ip4:17.41.0.0/16 ip4:17.58.0.0/16 ip4:17.142.0.0/15 ip4:17.57.155.0/24 ip4:17.57.156.0/24 ip4:144.178.36.0/24 ip4:144.178.38.0/24 ip4:112.19.199.64/29 ip4:112.19.242.64/29 ip4:222.73.195.64/29 ip4:157.255.1.64/29" " ip4:106.39.212.64/29 ip4:123.126.78.64/29 ip4:183.240.219.64/29 ip4:39.156.163.64/29 ip4:57.103.64.0/18" " ip6:2a01:b747:3000:200::/56 ip6:2a01:b747:3001:200::/56 ip6:2a01:b747:3002:200::/56 ip6:2a01:b747:3003:200::/56 ip6:2a01:b747:3004:200::/56 ip6:2a01:b747:3005:200::/56 ip6:2a01:b747:3006:200::/56 ~all"

• [1] https://en.wikipedia.org/wiki/Instant_messaging
• [2] https://en.wikipedia.org/wiki/Real-time_computing
• [3] https://en.wikipedia.org/wiki/Eudora_(email_client)
• [4] https://flounder.linux.org.au/
• [5] https://en.wikipedia.org/wiki/Lemmy_(social_network)

• Setup management board for Qt6 migration in Lomiri [1]
• Setup management board for salsa2ubports package syncing [2]
• Bootstrap Qt 6.8 in UBports APT repository
• Bootstrap Qt 6.8 in Lomiri PPA
• Fix Salsa CI for all Lomiri-related Debian packages
• Facilitate contributor's project around XDG Desktop Portal support for Lomiri.
• Plan how to bring DeltaTouch and DeltaChat core to Debian

• Replace libofono-qt by libqofono in telepathy-ofono
• Rework unit tests in telepathy-ofono utilizing ofone-phonesim
• Obsolete not-used-anymore u1db-qt
• Fixing wrong bin:pkg names regarding snapd-glib's QML module

• qmake -> CMake porting (if needed) and Qt6 porting of shared libraries and QML modules consumed by Lomiri shell and Lomiri apps:
  • biometryd
  • libqofono
  • libqofonoext
  • libqtdbusmock
  • lomiri-account-polld
  • lomiri-action-api
  • lomiri-api
  • lomiri-download-manager
  • lomiri-location-service
  • lomiri-online-accounts
  • lomiri-push-qml
  • lomiri-push-service
  • maliit-framework
  • mediascanner2
  • qtlomiri-appmenutheme
  • qtpim (started, work in progress)
  • qwebdavlib
  • signond (flaws spotted in Debian's porting of signond to Qt6)

• Continuing with Morph Browser Qt6 / LUITK
  • Build, run and fix LUITK unit tests for Qt6
  • various bug fixes and improvements for Morph Qt6
• Add mbim modem support to ofono upstream
• Improve ofono support in Network Manager
• Improve mbim modem support in lomiri-indicator-network
• Package kazv (convergent Matrix client) and dependencies for Debian
• Provide Lomiri images for Mobian

• Research on fuse-based caching Webdav client for lomiri-cloudsync-app.
• Research on alternative ORM instead of QDjango in libusermetrics

Debian Contributions: 2026-02 Contributing to Debian is part of Freexian s mission. This article covers the latest achievements of Freexian and their collaborators. All of this is made possible by organizations subscribing to our Long Term Support contracts and consulting services.

DebConf 26 Registration, by Stefano Rivera, Antonio Terceiro, and Santiago Ruano Rinc n DebConf 26, to be held in Santa Fe Argentina in July, has opened for registration and event proposals. Stefano, Antonio, and Santiago all contributed to making this happen. As always, some changes needed to be made to the registration system. Bigger changes were planned, but we ran out of time to implement them for DebConf 26. All 3 of us have had experience in hosting local DebConf events in the past and have been advising the DebConf 26 local team.

Debian CI improvements, by Antonio Terceiro Debian CI is the platform responsible for automated testing of packages from the Debian archive, and its results are used by the Debian Release team automation as Quality Assurance to control the migration of packages from Debian unstable into testing, the base for the next Debian release. Antonio started developing an incus backend, and that prompted two rounds of improvements to the platform, including but not limited to allowing user to select a job execution backend (lxc, qemu) during the job submission, reducing the part of testbed image creation that requires superuser privileges and other refactorings and bug fixes. The platform API was also improved to reduce disruption when reporting results to the Release Team automation after service downtimes. Last, but not least, the platform now has support for testing packages against variants of autopkgtest, which will allow the Debian CI team to test new versions of autopkgtest before making releases to avoid widespread regressions.

Miscellaneous contributions

• Carles improved po-debconf-manager while users requested features / found bugs. Improvements done - add packages from unstable instead of just salsa.debian.org, upgrade and merge templates of upgraded packages, finished adding typing annotations, improved deleting packages: support multiple line texts, add debug to see subprocess.run commands, etc.
• Carles, using po-debconf-manager, reviewed 7 Catalan translations and sent bug reports or MRs for 11 packages. Also reviewed the translations of fortunes-debian-hints and submitted possible changes in the hints.
• Carles submitted MRs for reportbug (reportbug --ui gtk detecting the wrong dependencies), devscript (delete unused code from debrebuild and add recommended dependency), wcurl (format help for 80 columns). Carles submitted a bug report for apt not showing the long descriptions of packages.
• Carles resumed effort for checking relations (e.g. Recommends / Suggests) between Debian packages. A new codebase (still in early stages) was started with a new approach in order to detect, report and track the broken relations.
• Emilio drove several transitions, most notably the haskell transition and the glibc/gcc-15/zlib transition for the s390 31-bit removal. This last one included reviewing and requeueing lots of autopkgtests due to britney losing a lot of results.
• Emilio reviewed and uploaded poppler updates to experimental for a new transition.
• Emilio reviewed, merged and deployed some performance improvements proposed for the security-tracker.
• Stefano prepared routine updates for pycparser, python-confuse, python-cffi, python-mitogen, python-pip, wheel, platformdirs, python-authlib, and python-virtualenv.
• Stefano updated Python 3.13 and 3.14 to the latest point releases, including security updates, and did some preliminary work for Python 3.15.
• Stefano reviewed changes to dh-python and merged MRs.
• Stefano did some debian.social sysadmin work, bridging additional IRC channels to Matrix.
• Stefano and Antonio, as DebConf Committee Members, reviewed the DebConf 27 bids and took part in selecting the Japanese bid to host DebConf 27.
• Helmut sent patches for 29 cross build failures.
• Helmut continued to maintain rebootstrap addressing issues relating to specific architectures (such as musl-linux-any, hurd-any or s390x) or specific packages (such as binutils, brotli or fontconfig).
• Helmut worked on diagnosing bugs such as rocblas #1126608, python-memray #1126944 upstream and greetd #1129070 with varying success.
• Antonio provided support for multiple MiniDebConfs whose websites run wafer + wafer-debconf (the same stack as DebConf itself).
• Antonio fixed the salsa tagpending webhook.
• Antonio sent specinfra upstream a patch to fix detection of Debian systems in some situations.
• Santiago reviewed some Merge Requests for the Salsa CI pipeline, including !703 and !704, that aim to improve how the build source job is handled by Salsa CI. Thanks a lot to Jochen for his work on this.
• In collaboration with Emmanuel Arias, Santiago proposed a couple of projects for the Google Summer of Code (GSoC) 2026 round. Santiago has been reviewing applications and giving feedback to candidates.
• Thorsten uploaded new upstream versions of ipp-usb, brlaser and gutenprint.
• Rapha l updated publican to fix an old bug that became release critical and that happened only when building with the nocheck profile. Publican is a build dependency of the Debian s Administrator Handbook and with that fix, the package is back into testing.
• Rapha l implemented a small feature in Debusine that makes it possible to refer to a collection in a parent workspace even if a collection with the same name is present in the current workspace.
• Lucas updated the current status of ruby packages affecting the Ruby 3.4 transition after a bunch of updates made by team members. He will follow up on this next month.
• Lucas joined the Debian orga team for GSoC this year and tried to reach out to potential mentors.
• Lucas did some content work for MiniDebConf Campinas - Brazil.
• Colin published minor security updates to bookworm and trixie for CVE-2025-61984 and CVE-2025-61985 in OpenSSH, both of which allowed code execution via ProxyCommand in some cases. The trixie update also included a fix for mishandling of PerSourceMaxStartups.
• Colin spotted and fixed a typo in the bug tracking system s spam-handling rules, which in combination with a devscripts regression caused bts forwarded commands to be discarded.
• Colin ported 12 more Python packages away from using the deprecated (and now removed upstream) pkg_resources module.
• Anupa is co-organizing MiniDebConf Kanpur with Debian India team. Anupa was responsible for preparing the schedule, publishing it on the website, co-ordination with the fiscal host in addition to attending meetings.
• Anupa attended the Debian Publicity team online sprint which was a skill sharing session.

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

What's happening? For people not on tor-internal, you should know that I've been sending semi-regular announcements when daylight saving changes occur. Starting now, I'm making those announcements public so they can be shared with the wider community because, after all, this affects everyone (kind of). For those of you lucky enough to have no idea what I'm talking about, you should know that some places in the world implement what is called Daylight saving time or DST. Normally, you shouldn't have to do anything: computers automatically change time following local rules, assuming they are correctly configured, provided recent updates have been applied in the case of a recent change in said rules (because yes, this happens). Appliances, of course, will likely not change time and will need to adjusted unless they are so-called "smart" (also known as "part of a bot net"). If your clock is flashing "0:00" or "12:00", you have no action to take, congratulations on having the right time once or twice a day. If you haven't changed those clocks in six months, congratulations, they will be accurate again! In any case, you should still consider DST because it might affect some of your meeting schedules, particularly if you set up a new meeting schedule in the last 6 months and forgot to consider this change.

If your location does not have DST Properly scheduled meetings affecting multiple time zones are set in UTC time, which does not change. So if your location does not observer time changes, your (local!) meeting time will not change. But be aware that some other folks attending your meeting might have the DST bug and their meeting times will change. They might miss entire meetings or arrive late as you frantically ping them over IRC, Matrix, Signal, SMS, Ricochet, Mattermost, SimpleX, Whatsapp, Discord, Slack, Wechat, Snapchat, Telegram, XMPP, Briar, Zulip, RocketChat, DeltaChat, talk(1), write(1), actual telegrams, Meshtastic, Meshcore, Reticulum, APRS, snail mail, and, finally, flying a remote presence drone to their house, asking what's going on. (Sorry if I forgot your preferred messaging client here, I tried my best.) Be kind; those poor folks might be more sleep deprived as DST steals one hour of sleep from them on the night that implements the change.

If you do observe DST If you are affected by the DST bug, your local meeting times will change access the board. Normally, you can trust that your meetings are scheduled to take this change into account and the new time should still be reasonable. Trust, but verify; make sure the new times are adequate and there are no scheduling conflicts. Do this now: take a look at your calendar in two week and in April. See if any meeting need to be rescheduled because of an impossible or conflicting time.

When does time change, how and where? Notice how I mentioned "North America" in the subject? That's a lie. ("The doctor lies", as they say on the BBC.) Other places, including Europe, also changes times, just not all at once (and not all North America). We'll get into "where" soon, but first let's look at the "how". As you might already know, the trick is:

Spring forward, fall backwards.

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

USA and Canada First, we start with "North America" which, really, is just some parts of USA[1] and Canada[2]. As usual, on the Second Sunday in March (the 8th) at 02:00 local (not UTC!), the clocks will move forward. This means that properly set clocks will flip from 1:59 to 3:00, coldly depriving us from an hour of sleep that was perniciously granted 6 months ago and making calendar software stupidly hard to write. Practically, set your wrist watch and alarm clocks[3] back one hour before going to bed and go to bed early. [1] except Arizona (except the Navajo nation), US territories, and Hawaii [2] except Yukon, most of Saskatchewan, and parts of British Columbia (northeast), one island in Nunavut (Southampton Island), one town in Ontario (Atikokan) and small parts of Quebec (Le Golfe-du-Saint-Laurent), a list which I keep recopying because I find it just so amazing how chaotic it is. When your clock has its own Wikipedia page, you know something is wrong. [3] hopefully not managed by a botnet, otherwise kindly ask your bot net operator to apply proper software upgrades in a timely manner

Europe Next we look at our dear Europe, which will change time on the last Sunday in March (the 29th) at 01:00 UTC (not local!). I think it means that, Amsterdam-time, the clocks will flip from 1:59 to 3:00 AM local on that night. (Every time I write this, I have doubts. I would welcome independent confirmation from night owls that observe that funky behavior experimentally.) Just like your poor fellows out west, just fix your old-school clocks before going to bed, and go to sleep early, it's good for you.

Rest of the world with DST Renewed and recurring apologies again to the people of Cuba, Mexico, Moldova, Israel, Lebanon, Palestine, Egypt, Chile (except Magallanes Region), parts of Australia, and New Zealand which all have their own individual DST rules, omitted here for brevity. In general, changes also happen in March, but either on different times or different days, except in the south hemisphere, where they happen in April.

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

Changes since last time There were, again, no changes since last year on daylight savings that I'm aware of. It seems the US congress debating switching to a "half-daylight" time zone which is an half-baked idea that I should have expected from the current USA politics. The plan is to, say, switch from "Eastern is UTC-4 in the summer" to "Eastern is UTC-4.5". The bill also proposes to do this 90 days after enactment, which is dangerously optimistic about our capacity at deploying any significant change in human society. In general, I rely on the Wikipedia time nerds for this and Paul Eggert which seems to singlehandledly be keeping everything in order for all of us, on the tz-announce mailing list. This time, I've also looked at the tz mailing list which is where I learned about the congress bill. If your country has changed time and no one above noticed, now would be an extremely late time to do something about this, typically writing to the above list. (Incredibly, I need to write to the list because of this post.) One thing that did change since last year is that I've implemented what I hope to be a robust calendar for this, which was surprisingly tricky. If you have access to our Nextcloud, it should be visible under the heading "Daylight saving times". If you don't, you can access it using this direct link. The procedures around how this calendar was created, how this email was written, and curses found along the way, are also documented in this wiki page, if someone ever needs to pick up the Time Lord duty.

The new process We had traditionally been using a "RFC" ("Request For Comments") process and have recently switched to "ADR" ("Architecture Decision Record"). The ADR process is, for us, pretty simple. It consists of three things:

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

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

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

The previous RFC template had 17 (seventeen!) headings, which encouraged much longer documents. Now, the decision record will be easier to read and digest at one glance. An immediate effect of this is that I've started using GitLab issues more for comparisons and brainstorming. Instead of dumping in a document all sorts of details like pricing or in-depth alternatives comparison, we record those in the discussion issue, keeping the document shorter.

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

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

Now, of course, the devil is in the details (and ADR-101), but the point is to keep things simple. A crucial aspect of the proposal, which Jacob Kaplan-Moss calls the one weird trick, is to "decide who decides". Our previous process was vague about who makes the decision and the new template (and process) clarifies decision makers, for each decision. Inversely, some decisions degenerate into endless discussions around trivial issues because too many stakeholders are consulted, a problem known as the Law of triviality, also known as the "Bike Shed syndrome". The new process better identifies stakeholders:

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

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

Communication guidelines Finally, a crucial part of the process (ADR-102) is to decouple the act of making and recording decisions from communicating about the decision. Those are two radically different problems to solve. We have found that a single document can't serve both purposes. Because ADRs can affect a wide range of things, we don't have a specific template for communications. We suggest the Five Ws method (Who? What? When? Where? Why?) and, again, to keep things simple.

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

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

And, indeed, I have been guilty of a lot of those issues. A verbose writer, I have written extremely long proposals that I suspect no one has ever fully read. Some proposals were adopted by exhaustion, or ignored because not looping in the right stakeholders. Our discussion issue on the topic has more details on the issues I found with our RFC process. But to give credit to the old process, it did serve us well while it was there: it's better than nothing, and it allowed us to document a staggering number of changes and decisions (95 RFCs!) made over the course of 6 years of work.

What's next? We're still experimenting with the communication around decisions, as this text might suggest. Because it's a separate step, we also have a tendency to forget or postpone it, like this post, which comes a couple of months late. Previously, we'd just ship a copy of the RFC to everyone, which was easy and quick, but incomprehensible to most. Now we need to write a separate communication, which is more work but, hopefully, worth the as the result is more digestible. We can't wait to hear what you think of the new process and how it works for you, here or in the discussion issue! We're particularly interested in people that are already using a similar process, or that will adopt one after reading this.

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

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

• a talk about supporting Python web deployments with Rust in the Rust Developer room
• a talk about duckdb in the Python Developer room
• an introduction to particleos in the Distributions Developer room

• [1] https://furilabs.com/shop/flx1s/
• [2] https://droidian.org/
• [3] https://wiki.debian.org/InstallingDebianOn/PINE64/PinePhonePro
• [4] https://wiki.debian.org/MobileApps
• [5] https://www.graphhopper.com/
• [6] https://etbe.coker.com.au/2026/01/05/phone-charging-speeds/

• Documentation Adding to install guides
• Pseudo Tests Suggesting an idea after finding an error or idea
• Pointing out bugs / errors when trying out tests
• Work on tests
• Contribute towards the wider community / help out other contributors
• Heck, you can even create a screen-cast video doing the set up and add it to the guide / docs
• Developers with further understanding can try to work with the maintainers on packages

• Images / Operating System Installation through dual booting
• More Linux commands
• Images / Operating System Installation and testing on Virtual Machine
• Git commands
• Writing testing documentation
• Writing Pseudo Tests
• Writing test modules / code using Perl
• Working on configuration

openqa-cli api -X POST isos ISO=debian-13.1.0-amd64-netinst.iso DISTRI=debian VERSION=stable FLAVOR=netinst-iso ARCH=x86_64 BUILD=1310 #This is the test you will run on the guide
openqa-cli api -X POST isos ISO=debian-13.1.0-amd64-netinst.iso DISTRI=debian VERSION=stable FLAVOR=netinst-iso ARCH=x86_64 BUILD=1310 TEST=cinnamon #I have added a TEST variable that runs only cinnamon test suite

    strategy:
      matrix:
        include:
          -   name: container, os: ubuntu-latest, container: rocker/r2u4ci  
          -   name: r-devel,   os: ubuntu-latest, container: rocker/drd  
          -   name: macos,     os: macos-latest  
          -   name: ubuntu,    os: ubuntu-latest  

    runs-on: $  matrix.os  
    container: $  matrix.container  

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

• Switch back to default them when disabling automatic HighContrast (MR)
• Hande gnome-session 49 changes so OSK can still start up (MR)
• Release 0.50.0, 0.50.1
• Don't forget to apply corner-shift to gear icon (MR)
• Fix startup warning (MR)
• Update doap (MR)
• DBus codegen cleanups (MR, MR, MR)
• Add Autobrightness handling (MR), (MR), (MR)

• Dispatch idle loop in prepare (MR)
• Release 0.50.0

• Allow to hide plugins (MR)
• Release 0.50~rc1, 0.50.0
• Hide demo plugins by default (MR)
• Sink floating refs properly (MR)
• Simplify includes (MR)
• Allow to configure alarm sound if clock app likely supports it (MR)
• Use shared check CI images (MR)
• Release 0.50.1
• Fix ringtone role (MR)

• Ship sytemd user unit so things work with gnome-session 49 (MR)
• Fix fallback to default OSK size with multiple outputs (MR)
• Improve character styling a bit (MR)
• Consolidate input surface creation (MR)
• Release 0.50.0, 0.50.1
• Don't trigger backspace key repeat in keypad or emoji layouts (MR)
• Better restore layout after swipe closing (MR)

• Release 0.50.0

• Build shared CI image MR

• Use pfs subproject for Rust portal (MR)

• Fix doc build (MR)

• Release 49.1
• Fix plugin loading (MR)
• Fix debug logging (MR)

• Allow OSKs to run with gnome-session 49 (MR)
• Release 0.50.0 (MR)

• Fix build (MR)
• Simplify and cleanup docs (MR)
• Fix mkosi build (MR)
• Install Recommends: (MR)
• Draft: Add support for initial-setup (MR)
• Add version option (MR)
• Drop debos build (MR, MR)

• Fix compatiblility with systemd >= 258 (MR)
• Use meson.options (MR)
• Add phone role (MR)

• Add support for Google Pixel 3A (MR)

• Fix failing CI build (MR)

• Add systemd unit to start with gnome-session 49 (MR)

• Upload phosh-tour 0.50.0
• Upload stevia 0.50.0, 0.50.1
• Upload phosh-mobile-settings 0.50.0
• Upload feedbackd 0.8.6
• Prepare phrog upload (MR)
• gnome-session Breaks (MR, MR)
• cellbroadcastd: Backport our upstream deadlock fix (MR)
• Upload wlroots 0.19.2
• Upload iio-sensor-proxy 3.8 (MR)

• Release 0.0.3
• Fix deadlock on start MR)

• Fix brightness values (MR)

• Ignore role based loopbacks (MR)

• Use AdwSwitchRow to reduce horizonatal allocation (MR)
• Quit when done (and not under GDM) (MR)

• shift6mq: Switch to mainline panel driver (MR)

• RequiredComponents is now gone (MR)

• stevia: Add hunspell-en-us dependency (MR)

• Install sensor firmware for SHIFT6mq (MR)
• Install sensor firmware for Oneplus 6T (MR)
• Fix clippy complaints (MR)

• Mention mirror (MR)
• Update for hugo 150 (MR, MR)
• Embed some ouf our peertube videos (MR)
• Add donations item (MR)
• Update osk post to mention systemd unit (MR)
• Update list of distributions and users (MR)
• Switch nightly builds to forky (MR)
• Lint more markdown (MR)
• Release 0.50.1 (MR)
• Notes on audio (MR)

• Switch to Debian forky (MR)
• Add g-i-s (MR)

• shift6mq: Add missing panel driver dependency (MR)
• shift6mq: Fix DTS warning (MR)

• Update media-role volume MR (MR)
• Allow to set a default target for e.g. alerts and alarms (MR)

• Add demo videos (MR)
• Add demo epubs (MR)

• phoc: Use correct format specifiers (MR)
• phoc: seat: Use the getter to access focused layer's output (MR)
• phosh: Upcoming events empty state (MR)
• phosh: Caffeine duration (MR)
• phosh: Location service quick setting (MR)
• phosh: UI check fix (MR)
• phosh: Autobrightness toggle (MR)
• p-m-s: Empty tweaks page test (MR)
• p-m-s: Symlink backend (MR)
• p-m-s: Return boolean from value setters (MR)
• p-m-s: conf-tweaks: Make setting_data a prop in Xresources backend (MR)
• p-m-s: conf-tweaks: Add gtk3settings backend (MR)
• gmobile: xiaomi-sweet support (MR)
• xdg-d-p: Use clippy (MR), MR)
• libcmatrix: various tweaks ([MR (https://source.puri.sm/Librem5/libcmatrix/-/merge_requests/110))
• libcmatrix: Release 0.0.4 (MR](https://source.puri.sm/Librem5/libcmatrix/-/merge_requests/115)
• meta-phosh: Add cellbroadcasts (MR)
• calls: Unload plugin test (MR)
• calls: Sip proxy support (MR)
• calls: Build system cleanups (MR)
• m-b-p-i: JP MVNO (MR)