Planet Debian

Subscribe to Planet Debian feed
Planet Debian -
Updated: 2 hours 52 min ago

Clint Adams: Mystical secrets of the bookworm

24 August, 2021 - 00:00

unmerged /usr is unsupported in bookworm and sid has been feeding bookworm since 2021-08-14,

unmerged /usr is also unsupported in sid since 2021-08-14,

no one using any portion of either bookworm or sid since 2021-08-14 should have any expectation that things should function correctly with unmerged /usr ,

∴ anyone using any portion of either bookworm or sid should execute apt install usrmerge or perform its equivalent on or prior to 2021-08-14.

Posted on 2021-08-23 Tags: ranticore

Bits from Debian: Lenovo, Infomaniak, Roche, Amazon Web Services (AWS) and Google, Platinum Sponsors of DebConf21

23 August, 2021 - 15:15

We are very pleased to announce that Lenovo, Infomaniak, Roche, Amazon Web Services (AWS) and Google, have committed to supporting DebConf21 as Platinum sponsors.

As a global technology leader manufacturing a wide portfolio of connected products, including smartphones, tablets, PCs and workstations as well as AR/VR devices, smart home/office and data center solutions, Lenovo understands how critical open systems and platforms are to a connected world.

Infomaniak is Switzerland's largest web-hosting company, also offering backup and storage services, solutions for event organizers, live-streaming and video on demand services. It wholly owns its datacenters and all elements critical to the functioning of the services and products provided by the company (both software and hardware).

Roche Roche is a major international pharmaceutical provider and research company dedicated to personalized healthcare. More than 100.000 employees worldwide work towards solving some of the greatest challenges for humanity using science and technology. Roche is strongly involved in publicly funded collaborative research projects with other industrial and academic partners and have supported DebConf since 2017.

Amazon Web Services (AWS) is one of the world's most comprehensive and broadly adopted cloud platform, offering over 175 fully featured services from data centers globally (in 77 Availability Zones within 24 geographic regions). AWS customers include the fastest-growing startups, largest enterprises and leading government agencies.

Google is one of the largest technology companies in the world, providing a wide range of Internet-related services and products such as online advertising technologies, search, cloud computing, software, and hardware.

Google has been supporting Debian by sponsoring DebConf for more than ten years, and is also a Debian partner sponsoring parts of Salsa's continuous integration infrastructure within Google Cloud Platform.

With these commitments as Platinum Sponsors, Lenovo, Infomaniak, Roche, Amazon Web Services and Google are contributing to make possible our annual conference, and directly supporting the progress of Debian and Free Software, helping to strengthen the community that continues to collaborate on Debian projects throughout the rest of the year.

Thank you very much for your support of DebConf21!

Participating in DebConf21 online

The 22nd Debian Conference is being held Online, due to COVID-19, from August 22nd to 28th, 2021. There are 8 days of activities, running from 10:00 to 01:00 UTC. Visit the DebConf21 website at to learn about the complete schedule, watch the live streaming and join the different communication channels for participating in the conference.

Leandro Doctors: Clojure CLI Tools in Debian - GSoC 2021 Final Report

23 August, 2021 - 10:00

NOTE: this blog post is based on my "Clojure CLI Tools in Debian" GSoC 2021 project Final Report.


My name is Leandro Doctors (“allentiak” on IRC), and I’ve been the GSoC intern working with the Debian Clojure Team during 2021. This is my final report. You can also check my original proposal and my first report.


Whereas the raw data may not sound by itself very positive, my personal conclusion is. This is, whereas I didn’t fully finish the required deliverables envisioned in my original proposal, I do feel I am much closer to, eventually, becoming a Debian Developer. So, by all means, I consider this project has had a positive outcome.


The goal of the “Clojure Build Tools in Debian” project was to provide Clojure Debian users with some of the latest advanced build tools and libraries the upstream Clojure developers have been lately working on. These include tools.deps.alpha, a library for dependency graph resolution and classpath building, and the CLI tool clj, for REPL interaction. If time permitted, I was also to improve the quality of both new and existing Clojure packages, and the overall Debian Clojure packaging process. My mentor was Louis-Louis-Philippe Véronneau, and my co-mentor was Utkarsh Gupta.


Why this project? On the one side, if you’re a Clojure lover like me, you may have noticed that the Clojure experience in Debian is, as of mid 2021, well... still quiet limited. Additionally, this project aligned with my own background in Free Software community building and my research interest in Peer Production.

When I mention how limited today’s Clojure experience in Debian is, I can see two reasons for this, deeply intertwined. The first one is that there currently aren’t many Clojure-specific packaging tools in Debian (such as a clojure-debian-helper). The second reason for which we only currently have a suboptimal Clojure experience in Debian, and probably the root of the previous one, is that many core build tools and libraries for the language have not simply been packaged yet. My project aimed to attack that seemingly root cause.

As I said, another reason for me choosing this project is my own experience as the Co-founder and Leader of, probably, the first Free Software Community experience in my hometown of San Juan, Argentina. That interest in Free Software evolved in a first PhD attempt in what is now known as the field of Peer Production. A subject that has lived within me as a research interest during my day job at a University.

Being a Clojure fan, it felt only logical combining all those interests somehow. And this project seemed like the ideal combination.

The Debian Clojure Team

I’ve been working with a small, yet very warm team. The current incarnation of the Debian Clojure Team exists thanks to the hard work of three people.

Elana Hashman (aka “the Clojure necromancer”), revived the team around three years ago. Later on, the team gained the invaluable presence of Louis-Philippe Véronneau and Utkarsh Gupta (my mentor and co-mentor, respectively).

Together, these “Three Musketeers” have maintained the team alive, allowing us, Debian users, to enjoy Clojure.


During the first part of my project, I mainly worked on learning the basics of Debian packaging, and got my first package uploaded. I have to thank Louis-Philippe, Utkarsh, and Elana for their immense patience and support during that part, as it took me quite some effort grasping the basics of Debian packaging.

During the second part of my project, I worked on my last packages, and almost completed the originally required scope of the project. I only have to finish working on the transition from the currently provided set of packages (based on a Debian-specific clojure runner) to the newly provided upstream clojure and clj runners.

Unfortunately, I didn’t have much time left to start working on the opportunities for improvement already identified by the Debian Clojure Team originally outlined in my proposal. Whereas I did update one older Clojure package not built using leiningen (tools-data-xml-clojure), I didn’t write any Lintian tags to make Clojure packaging in Debian more robust, nor worked towards the automation of Clojure unit tests in autopkgtests via autodep8.

Deliverables: Data vs. Conclusions

If we are to talk about deliverables, we should start with the data. According to my original proposal, I was required to provide both new and updated Clojure packages accepted into Debian “unstable”, and updated Clojure packaging documentation. Additionally, if time permitted, I was to also provide new Clojure Lintian tags merged by the Lintian maintainers, and new Clojure autodep8 scripts merged by the autodep8 maintainers. Whereas I partially accomplished both required tasks, I didn’t manage to start working on any of the optional deliverables.

When looked in isolation, those numbers may look somewhat disappointing for some people. However, I can draw a much more positive conclusion. Why?

Firstly, GSoC is supposed to be a learning experience. Moreover, as I said in my original proposal, “I approach[ed] this project as a great opportunity to, finally, start my journey towards becoming a Debian Developer”. In that sense, I consider the time invested into this project fruitful. In this way, I have learned the basics of packaging, how to interact with the Debian Clojure Team, and and already got my first packages accepted. Plus, I’m looking forward to continuing to work with the Debian Clojure Team so I can attain the original scope of the project. Therefore, all things considered, I can consider this experience as a moderate success.

Lessons Learned

Technically speaking, if I have learned one thing during these weeks, is that packaging, although easy to be underestimated, is by no means a trivial process. As any Debian Developer surely knows, the onboarding process can take some time. Plus, what is easy for some people, can be difficult for others. In my case, this was quite evident. Whereas I can speak several languages and learning new ones takes me little effort, grasping the basics of packaging took me (literally!) blood, sweat and tears. Indeed, the packaging learning curve was quite steep for me.

That being said, I did learn a thing or two about packaging. So, if I managed to get here, I’m sure many others can. It may take them more or less time than what it took me, but learning (at least the basics) of packaging is an achievable goal.

Technical skill learning aside, I value very highly the non-technical skills I have so far improved during this project.

For instance, I also learned that it can take some time to adapt to real-time online communication. Before this project, remote working meant either exchanging emails or getting into video or audio calls, with a low emphasis on chat-based interaction. Early on, I realized that the Debian Clojure Team interacts almost exclusively via, well... chat! And those two approaches are very different indeed. It has taken me some time to adjust, but I’ve improved greatly in this aspect as well.

Finally, improving my time management skills has been also a key part of this process. Whereas I had already been working remotely for over a year and a half already, my day job is not so interaction-dependent as this project (specially in the beginning). So it took me some time to adapt to this way of working, and to plan my workload so I could use those waiting moments to advance in other parts of the project. Still a lot to improve here, but improving nevertheless.


I first have to thank upstream. More specifically, one of the upstream developers of the clojure-tools, Alex Miller. Everytime I needed specific information on what do specific parts of the Clojure CLI tools’s codebase do, tools.deps.alpha do, he popped up a reply in a matter of hours. He has shown genuine interest in the success of is project during by carefully replying to my emails with detailed explanations of code intent and form, both in private and in public conversations. Thank you for all that, Alex!

Let’s move on to the Debian Clojure Team.

First, Elana. I thank Elana for her initial openness when I first contacted her about this idea. It was *her* who initially contacted Louis-Philippe so he would become my mentor. I wouldn’t have started to work on this project if it wasn’t for her. Plus, she provided quite a piece of advise in more that one ocassion. So, thank you very much for all that, Elana!

I also thank Utkarsh, my co-mentor, for his overall technical advise. And a special mention to his initial help to setup my Matrix client for OFTC chat. At that moment, it was *him* who took the time to help me in real time so I could solve that problem. So, thank you very much for all that, Utkarsh!

I finally have to thank Louis-Philippe, my mentor, for his patient guidance during the whole process. His dedication and hard work has been *instrumental* for my progress. And a special mention for his tolerance with respect to some unforeseen personal circumstances I had to endure during the first weeks. When one is playing the newbie, times abound when one depends on other people’s feedback. And Debian is made of volunteers, who have a life outside it. Every time I asked, Louis-Philippe was there. I wouldn’t have gotten here if it wasn’t for him. So, thank you *so* much for all that, Louis-Philippe!

Final Words

I would like to close this report with a reflection.

I have been using Debian for many, many years now, and I had been looking for a way to contribute back to the project for some time already. I even did some work on a non-packaging Debian project. That being said, I never managed to deliver much, really.

So, the very existence of outreach programs as this one is, in my humble opinion, crucial. In my case, the funding I got through the GSoC program was instrumental in being able to allocate time for this endeavor, and to finally get started contributing to Debian. Plus, it has had a very positive impact on me; in many ways, some of which I am only starting to discover now that the project is ending.

When I put things into perspective, this project is very important for me. Actually, it is nothing but the first step within a long-term journey: becoming a Debian member. Hopefully, I would like to be able to apply for Debian membership by the end of this year.


Thank you very much for your time reading this! I look forward to hearing (or reading) your feedback. Please come and meet with the Debian Clojure Team Moreover, I will be in the Clojure BoF on DebConf2021. Moreover, do not hesitate to send me an email.

DataTask Status
  • Required Tasks:

    • T1: Setting up a full Debian packaging development environment and learning the basics of Debian packaging.

      • Successfully completed the first part during the Application period.

      • Successfully completed the second part during the Coding periods.

    • T2: Identifying and packaging the missing dependencies to package clojure-cli.

      • Successfully completed as of the end of Coding II.
    • T3: Packaging clojure-cli.

      • 90% done as of the end of Coding II.
    • T4: Updating clojure to use clojure-cli.

      • To be completed after GSoC.
    • T5: Updating the Clojure Packaging Guide with information on how to use the new clojure-cli scripts.

      • Improved existing documentation. To be completed after GSoC.
  • Optional Tasks:

    • T6: Writing Lintian tags to make Clojure packaging in Debian more robust.

      • To be completed after GSoC.
    • T7: Working to automate Clojure unit testing in autopkgtests using autodep8.

      • To be completed after GSoC.
    • T8: Updating older Clojure packages not built using leiningen or clojure-cli.

      • To be completed after GSoC.
  1. Updated packages:

  2. New packages:

    • tools-gitlibs-clojure -- Clojure API for programatically accessing git libraries. ITP: #905543 in NEW.

    • “ITP: tools-deps-alpha-clojure -- functional API for dependency management and classpath creation” Needs to be uploaded by Louis-Philippe.

  3. In-Progress packages:

    • “ITP: clojure-cli -- upstream CLI entrypoints for Clojure” 90% done - Package completed. I only need to finish implementing the transition from existing ‘clojure‘ scripts. To be completed after GSoC.
  4. Opened ITPs:

  5. Reported bugs

  1. Interactions with upstream in the Debian-Clojure mailing list:

    • Many productive interactions with one of the upstream developers, Alex Miller (June, August).
  2. Wiki page:


Pavit Kaur: GSoC 2021: Final Evaluation

23 August, 2021 - 07:00

Project: Incremental Improvements to Debian’s CI platform
Project Link:
Code Repository:
Mentors: Antonio Terceiro and Paul Gevers

About the Project

Debian Continuous Integration is Debian’s CI platform. It runs tests on the packages published in the Debian archive, and today is used to control migration of packages from unstable, Debian’s development area, to testing, the area of the archive where the next Debian release is being prepared. This makes it a crucial part of Debian’s infrastructure.

The web platform shows the results of all the tests executed. Debian CI provides developers both API and a GUI Self-Service section to request tests for the packages and get information on test history.

This project involves implementing incremental improvements to the platform, making it easier to use and maintain.

Deliverables of the project:
  • Migrating Logins to Salsa
  • Adding support for testing security uploads and Debian LTS
Work done Migrating Logins to Salsa
  • Originally, Debian CI used Debian SSO client certificates for logging in, but since that was deprecated logins are migrated to Salsa, Debian’s Gitlab instance and this is implemented with the help of OmniAuth, the ruby authentication framework.

  • Another thing fixed as part of this task was that there exists a limitation in the existing database structure, where usernames were directly stored as the test requestor field, so that relationship was normalized with a proper foreign key to the users table.

Merge Requests:

Adding support for testing security uploads and Debian LTS

In this task, work was done to enable private tests in Debian CI for adding support for testing security uploads and Debian LTS. It includes tasks from adding the private field in the API and Self-Service section in requesting tests to adding an option to publish them when ready through both interfaces.

Merge Requests:


I worked on some issues to add usability improvements for the web interface:

Learning Takeaways

I learned a lot throughout the entire journey. Some of the things to mention are:

  • Writing tests: I learned about using Rspec for writing tests in ruby and understood how writing tests is an integral part of coding any project.
  • Using good coding practices: By my merge requests reviews done by my mentor Antonio, I came to know about good coding practices which help in keeping the code both clean and concise.

I owe huge thanks to my mentors Antonio Terceiro and Paul Gevers for their constant support and guidance throughout the entire duration. It is for them that I was able to get started with the code-base of the project in the first place. And while working on the project, they were extremely responsive to all my queries. My merge requests were all thoroughly reviewed which enables me to learn more and work more efficiently. It was a complete pleasure interacting with them on weekly meet calls.

To sum up, my GSoC journey was awesome 🎉 and I had a fun and productive summer with Debian 😃

What’s next?

As part of a continuation of my project task Adding support for testing security uploads and Debian LTS, I would be working on Debian CI to facilitate the process of connecting the embargoed archive.

It’s the end of my GSoC journey but certainly not the end of my journey with Debian or Open-Source. I plan to stay an active contributor to Debian and get involve with more Open Source projects as well 🌟


The link to my Salsa Profile for all my work activities can be found here.
To know more about my journey, my other GSoC blog posts can be found below:

Joachim Breitner: Sweet former employee appreciation

22 August, 2021 - 16:32

Two months ago was my last day of working as an employee for DFINITY, and as I mentioned in the previous blog post, one of my main contributions was the introduction and maintenance of the Interface Specification.

The Interface Specification as a book

Hence I was especially happy to find that my former colleague Hans Larsen has, as a farewell gift and token of appreciation, created a hard copy of the document, with 107 pages of dry technical content that, and a very sweet dedication on the back. This is especially valuable as it came from Lars personally (i.e. it’s not “just” routine HR work to keep former employees happy, which I could imagine to be a thing in big and mature corporations), and despite the fact that he himself has left DFINITY since.

I also take this as further confirmation that this specification-driven design process, despite the initial resistance and daily hurdles, is a good one. A rough list of guiding principles would be:

  • Describe the complete interface, not just signatures (schemas), but also semantics (behavior), in one document. The teams on either side of the interface should not need any other information. In particular, they should never have to peek into the other team’s code to see how it works.
  • New features or changes are first designed by writing down how they affect the interface specification, discussed on that level with the “other” teams, agreed upon, and then implemented. Treating the document as code and discussing these features on pull requests is helpful here. Depending on how quickly DFINITY becomes more open, we may get to see that happening on the currently internal ic-ref repository.
  • The interface semantics is described not just using possibly ambiguous or incomplete prose, but also a comprehensive formalism. That formalism is ideally mechanized, but pseudo-math is better than nothing.
  • The interface is implemented more than once (e.g. a prototype reference implementation, and the production implementation) to keep the implementations honest.
  • Dually, the interface has more than one consumer, one ideally being a executable test suite that is implementation-agnostic.

The similarity to the concept of “deep specifications” from the DeepSpec project is indeed striking.

One of my hopes at DFINITY was that these principles would catch on and that other components (e.g the NNS, the nodes or the ICP ledger canister) would follow suite. That did not happen, it seems. Or rather, it did not happen yet…

PS, in case you are wondering how: The rendering of the document that’s shown at at is not great; the internal website had a different style with made navigating this large document more possible, as it was a dedicated site with the document’s nested table of content on the left.

Dirk Eddelbuettel: RcppFastFloat 0.0.3: Maintenance

22 August, 2021 - 01:40

The third release of RcppFastFloat arrived on CRAN. The package wraps fastfloat, another nice library by Daniel Lemire. For details, see the recent arXiv paper showing that one can convert character representations of ‘numbers’ into floating point at rates at or exceeding one gigabyte per second.

This release deals with a header include on everybody’s favourite CRAN platform bringing the result status to a clean suite of all OKs.

Changes in version 0.0.3 (2021-08-21)
  • Account for SunOS with an additional #define

  • Minor update to DESCRIPTION

Courtesy of my CRANberries, there is also a diffstat report for this release.

If you like this or other open-source work I do, you can now sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Pavit Kaur: GSoC: Second Phase of Coding Period

21 August, 2021 - 14:36

Hello there.

So here we are near the end of GSoC 2021 and with that, I am sharing details of the work I completed in the second phase of the coding period.

Continuing with details of the task I left on…

Task: Adding support for testing security uploads and Debian LTS
  • The extra-apt-sources parameter is added to both API and Self-Service section for the test request object and the part which took some time was deciding on its validation since if you ever deal with apt sources, you would know that there exist a lot of combinations of a valid apt source and in the end, the decision was taken to just add the minimal checks.

  • Since, we have enough setup to request private tests, it made sense to have a way of looking them up in the Self-Service section. So a new column is added to the test records in Job-History marking the visibility of a test (private or public) and a new filter to filter out records based on the visibility.

  • The option to retry tests is also added in Self-Service in the Job-History section so that private tests can also be retried. As earlier, this option was only available in Package History pages but those pages do not show the private tests.

  • The next thing in the list was to publish these test results of private tests at some point. For the API section, a new endpoint is added to accept a string of run_ids which is ready to be published, and for the Self-Service , in the Job-History page a Publish button is added to be clicked after check boxing the required tests.

This ends the list of my planned work for the project. 🎉

Some more interesting stuff

As we got some more time for the coding period to end, my mentor Antonio Terceiro suggested that I could pick any issue from the opened issues list to work on so I picked up the one to add a user menu for the Self-Service section and completed that.

Antonio also gave me insights into Debian Packaging and even let me try packaging a newer upstream version of the package itamae which is one of the packages maintained by him.

I also worked on creating a video about my GSoC project for DebConf21 and this was truly the hardest thing to do. From setting up everything to final editing, it took me about 2 days to create something sane to submit. Now, I am excited about DebConf21 😃

That concludes my work in the second phase of the coding period and next, I will be sharing my Final Evaluation Submission real soon.

Stay tuned!

Jonathan Dowland: PhD year 4 progression

20 August, 2021 - 16:37

I've now completed my 4th year on my part-time PhD (a.k.a. Stage 2). I'm 2/3 of the way through.

Here's my stage 2 / year 4 report. As I've written before, this isn't graded so it might not be an example of a good one, but I did pass progression.

I had hoped to write some more blog posts about the actual content of my work before another administrative document. I spent a couple of hours drafting one a few weeks back but didn't finish it!

Norbert Preining: Krita 5.0-beta for Debian

20 August, 2021 - 09:38

I have been using the GIMP since about 20 years or so, but recently started to also work with Krita since I found it quite nice to work with (besides the text module, which is a pain).

As there came out the first beta of Krita 5, I decided to throw it into my KDE/Plasma OBS builds to try it out. To get it working, add my OBS key say in /usr/local/share/keyrings/obs-npreining.asc and add a file /etc/apt/sources.lists.d/obs-npreining-krita-beta.list, containing the following line:

deb [signed-by=/usr/local/share/keyrings/obs-npreining.asc] ./

Warning: Krita will also warn you, but files saved with version 5 might not be openable with version 4 of Krita, so be sure to have a backup of your files in case you need to go back to Krita 4.


Reproducible Builds (diffoscope): diffoscope 181 released

20 August, 2021 - 07:00

The diffoscope maintainers are pleased to announce the release of diffoscope version 181. This version includes the following changes:

[ Chris Lamb ]

* New features and bug fixes:
  - Don't require apksigner in order to compare .apk files using apktool.
  - Add a special-case to squshfs image extraction to not fail if we aren't
    root/superuser. (Closes: #991059)
  - Reduce the maximum line length to avoid O(n^2) Wagner-Fischer algorithm,
    which meant that diff generation took an inordinate amount of time.
    (Closes: reproducible-builds/diffoscope#272)
  - Include profiling information in --debug output if --profile is not set.
  - Don't print an orphan newline when the Black source code formatter
    self-test passes.

* Tests:
  - Update test to check specific contents of squashfs listing, otherwise it
    fails depending on the test systems uid-to-username mapping in passwd(5).
  - Assign "seen" and "expected" values to local variables to improve
    contextual information in/around failed tests.

* Misc changes:
  - Print the size of generated HTML, text (etc.) reports.
  - Profile calls to specialize and diffoscope.diff.linediff.
  - Update various copyright years.

You find out more by visiting the project homepage.

Russ Allbery: Review: The Past is Red

19 August, 2021 - 11:30

Review: The Past is Red, by Catherynne M. Valente

Publisher: Tordotcom Copyright: 2021 ISBN: 1-250-30112-2 Format: Kindle Pages: 151

Tetley is nineteen and is the most hated person in Garbagetown. That's kind of horrible, but life is otherwise great. As she puts it:

I'm awfully lucky when you think about it. Garbagetown is the most wonderful place anybody has ever lived in the history of the world, even if you count the Pyramids and New York City and Camelot. I have Grape Crush and Big Bargains and my hibiscus flower, and I can fish like I've got bait for a heart so I hardly ever go hungry, and once I found a ruby ring and a New Mexico license plate inside a bluefin tuna. Everyone says they only hate me because I annihilated hope and butchered our future, but I know better, and anyway, it's a lie. Some people are just born to be despised. The Loathing of Tetley began small and grew bigger and bigger, like the Thames, until it swallowed me whole.

Garbagetown is a giant floating pile of garbage in the middle of the ocean, and it is, so far as anyone knows, the only "land" left in the world. Global warming has flooded everything until the remaining Fuckwits (as their future descendants call everyone who was alive at the time) took to the Misery Boats and searched hopelessly for land. Eventually they realized they could live on top of the now-massive Pacific Garbage Patch and began the Great Sorting, which is fifty years into Tetley's past. All of the types of garbage were moved into their own areas, allowing small micronations of scavengers to form and giving each area its own character.

Candle Hole is the most beautiful place in Garbagetown, which is the most beautiful place in the world. All of the stubs of candles the Fuckwits threw out piled up into hills and mountains and caverns and dells, votive candles and taper candles and tea lights and birthday candles and big fat colorful pillar candles, stacked and somewhat melted into a great crumbling gorgeous warren of wicks and wax. All the houses are cozy little honeycombs melted into hillside, with smooth round windows and low golden ceilings. At night, from far away, Candle Hole looks like a firefly palace. When the wind blows, it smells like cinnamon, and freesia, and cranberries, and lavender, and Fresh Linen Scent, and New Car Smell.

Two things should be obvious from this introduction. First, do not read this book looking for an accurate, technical projection of our environmental future. Or, for that matter, physical realism of any kind. That's not the book that Valente is writing and you'll just frustrate yourself. This is science fiction as concretized metaphor rather than prediction or scientific exploration. We Fuckwits have drowned the world with our greed and left our descendants living in piles of our garbage; you have to suspend disbelief and go with the premise.

The second thing is that either you will like Tetley's storytelling style or you will not like this book. I find Valente very hit-and-miss, but this time it worked for me. The language is a bit less over-the-top than Space Opera, and it fits Tetley's insistent, aggressive optimism so well that it carries much of the weight of characterization. Mileage will definitely vary; this is probably a love-it-or-hate-it book.

The Past is Red is divided into two parts. The first part is the short story "The Future is Blue," previously published in Clarkesworld and in Valente's short story collection of the same name. It tells the story of Tetley's early life, how she got her name, and how she became the most hated person in Garbagetown. The second part is much longer and features an older, quieter, more thoughtful, and somewhat more cynical Tetley, more life philosophy, and a bit of more-traditional puzzle science fiction. It lacks some of the bubbly energy of "The Future is Blue" but also features less violence and abuse. The overall work is a long novella or very short novel.

This book has a lot of feelings about the environment, capitalism, greed, and the desire to let other people solve your problems for you, and it is not subtle about any of them. It's satisfying in the way that a good rant is satisfying, not in the way that a coherent political strategy is satisfying. What saves it from being too didactic or self-righteous is Tetley, who is happy to record her own emotions and her moments of wonder and is mostly uninterested in telling other people what to do. The setting sounds darkly depressing, and there are moments where it feels that way in the book, but the core of the story and of Tetley's life philosophy is a type of personal resilience: find the things that make you happy, put one foot in front of the other, and enjoy the world for what it is rather than what it could be or what other people want to convince you it might be. It's also surprisingly funny, particularly if you see the humor in bizarrely-specific piles of the detritus of civilization.

The one place where I will argue with Valente a bit is that The Past is Red thoroughly embraces an environmental philosophy of personal responsibility. The devastating critique aimed at the Fuckwits is universal and undistinguished except slightly by class. Tetley and the other inhabitants of Garbagetown make no distinction between types of Fuckits or attempt to apportion blame in any way more granular than entire generations and eras.

This is probably realistic. I understand why, by Tetley's time, no one is interested in the fine points of history. But the story was written today, for readers in our time, and this type of responsibility collapse is intentionally and carefully constructed by the largest polluters and the people with the most power. Collective and undifferentiated responsibility means that we're using up our energy fretting about whether we took two showers, which partly deflects attention from the companies, industries, and individuals that are directly responsible for the vast majority of environmental damage. We don't live in a world full of fuckwits; we live in a world run by fuckwits and full of the demoralized, harried, conned, manipulated, overwhelmed, and apathetic, which is a small but important difference. This book is not the right venue to explore that difference, but I wish the vitriol had not been applied quite so indiscriminately.

The rest, though, worked for me. Valente tends to describe things by piling clauses on top of adjectives, which objectively isn't the best writing but it fits everything about Tetley's personality so well that I think this is the book where it works. I found her strange mix of optimism, practicality, and unbreakable inner ethics oddly endearing. "The Future is Blue" is available for free on-line, so if in doubt, read some or all of it, and that should tell you whether you're interested in the expansion. I'm glad I picked it up.

Content warning for physical and sexual abuse of the first-person protagonist, mostly in the first section.

Rating: 7 out of 10

Kunal Mehta: Kiwix returns in Debian Bullseye

19 August, 2021 - 10:41

(This is my belated #newindebianbullseye post.)

The latest version of the Debian distro, 11.0 aka Bullseye, was released last week and after a long absence, includes Kiwix! Previously in Debian 10/Buster, we only had the underlying C/C++ libraries available.

If you're not familiar with it, Kiwix is an offline content reader, providing Wikipedia, Gutenberg, TED talks, and more in ZIM (.zim) files that can be downloaded and viewed entirely offline. You can get the entire text of the English Wikipedia in less than 100GB.

apt install kiwix will get you a graphical desktop application that allows you to download and read ZIMs. apt install kiwix-tools installs kiwix-serve (among others), which serves ZIM files over an HTTP server.

Additionally, there are now tools in Debian that allow you to create your own ZIM files: zimwriterfs and the python3-libzim library.

All of this would not have been possible without the support of the Kiwix developers, who made it a priority to properly support Debian. All of the Kiwix and repositories have a CI process that builds Debian packages for each pull request and needs to pass before it'll be accepted.

Ubuntu users can take advantage of our primary PPA or the bleeding-edge PPA. For Debian users, my goal is that unstable/sid will have the latest verison within a few days of a release, and once it moves into testing, it'll be available in Debian Backports.

It is always a pleasure working with the Kiwix team, who make a point to send stickers and chocolate every year :)

Steinar H. Gunderson: plocate 1.1.9 released

19 August, 2021 - 03:30

I've just released version 1.1.9 of plocate. It adds support for the -e (--existing) option from mlocate, since I needed it and it's nice to be complete.

Perhaps more importantly, plocate now has taken over from mlocate in Debian! After conferring with Tollef Fog Heen, longtime mlocate maintainer, this was deemed to be the sensible option for bookworm; if you have mlocate and full-upgrade, you will automatically get plocate (and can safely remove the transition package afterwards). Most people are unlikely to notice any difference besides higher speeds and less space usage (although it does break cruft-ng, and nobody has a good solution for this yet).

I'm still a bit dismayed we couldn't get an agreement to have plocate as standard in non-cloud installs, but this is the second best thing. :-)

John Goerzen: Distributed, Asynchronous Git Syncing with NNCP

18 August, 2021 - 23:11

I have a problem.

I have a directory that I use with org-mode and org-roam. I want it to be synced across multiple machines. I also want to keep the history with git. And, I want to use end-to-end encryption (no storing a plain git repo on a remote server), have a serverless setup, not require any two machines to be up simultaneously, and be resilient in the face of races and conflicts.


I’ve tried a number of setups – git-remote-gcrypt on a remote server (fragile), some complicated scripts around a separate repo in syncthing (requires one machine to be “in charge”), etc. They all were subpar.

Then NNCP introdoced asynchronous multicast and I was intrigued.

So, I wrote gitsync-nncp, which uses NNCP to distribute git bundles to all the participating machines. The comprehensive documentation for gitsync-nncp goes into a lot more detail about how it works and what problems it solves. It’s working quite well for me!

Jonathan Dowland: Budgeting tools

18 August, 2021 - 20:56

On the advice of many friends, I tried to use You Need A Budget. I gave it a seriously long, proper evaluation: over a year. But I just couldn't get it to work for me. I don't want to try and explain why. To be honest, those same friends who advocated for it fairly strongly, also gave me a pretty hard time for giving up on it!

Despite it not clicking for me, there are a few concepts from YNAB that I quite like:

  • "give every dollar a job". Or: Budget your entire income.
  • The jam-jar budgeting approach of carrying budget "pots" over from month to month, so you can budget a small amount towards a large thing over a long period.

Jimmy Kaplowitz suggested back in 2012 that I should take a look at GNUCash. It took me a few more years before I did. The eventual trigger point for me was organising an event where I paid for a load of things on behalf of others and needed to track who had paid me back. It excelled for that.

I've continued to use GNUCash to manage my personal money &emdash that is, my "play money" and anything I've accumulated &emdash but I haven't committed to it for my family finances. Practically speaking that would lock my wife out of them, which wouldn't be fair. But also because GNUCash's shortcomings (and despite its strengths, it certainly has some) mean that I don't expect I will be using it into the indefinite future, even for my personal stuff.

The most significant drawback, in my opinion, is GNUCash's support for scripting. Sometimes, there's a laborious but easily-mechanisable (in theory) task I need to perform that would be ideal to script. GNUCash has built-in scripting support using Guile &emdash the GNU lisp/scheme dialect &emdash but this is limited to Reports only, I don't think it can be used for a task such as "match a series of transactions using one or more filters or regular expressions, and apply a transformation to them, such as change the account to which they are posted", etc.

It also has a C library and auto-generated bindings for other languages. This has a horrible API, which is carried over into the language bindings. Documentation for the whole lot is basically non-existent too.

Plain-text accounting

For that reason I set out to find some better tools. There's a lot of interest and activity in plain-text accounting (PTA), including tools such as beancount, ledger or the Haskell re-implementation hledger. In a future post I'll write about PTA and hledger.

Jamie McClelland: Anyone still using gitweb?

18 August, 2021 - 19:27

It seems like the self-hosting git world has all moved to gitlab or gitea.

For a number of reasons not worth enumerating, I’m still running gitolite and recently decided I wanted to checkout my code via https using gitweb.

I got through most of the installation and configuration without trouble (I could browse via the web and see all my repositories). But, when I tried to git clone using the https address I got a fatal “not found” error.

It seems that gitweb, out of the box, allows for easy web-browsing of git repositories but needs some extra work if you want to clone over https. Specifically, you need to use git-http-backend.

The git-http-backend man page is very useful, but assumes you are accessing your repos via instead of simply

These lines are my variation to the suggested apache configuration lines provided by man git-http-backend.

They differ by:

  • allowing for web access without specifying a subdirectory
  • using the debian /usr/lib/git-core path instead of /usr/libexec/git-core
  • removing git-receive-pack since I only plan to clone and don’t plan to push back to this repo.
DocumentRoot /usr/share/gitweb
<Directory /usr/share/gitweb>
  Options +FollowSymLinks +ExecCGI
  AddHandler cgi-script .cgi
  Require all granted
<Directory /usr/lib/git-core>
  Require all granted
SetEnv GIT_PROJECT_ROOT /var/lib/git
AliasMatch ^/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$          /var/lib/git/$1
AliasMatch ^/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/lib/git/$1
ScriptAliasMatch \
  "(?x)^/(.*/(HEAD | \
    info/refs | \
    objects/info/[^/]+ | \
    git-upload-pack))$" \
ScriptAlias / /usr/share/gitweb/gitweb.cgi/

The main trick is to direct some requests to apache2, some requests to /usr/lib/git-core/git-http-backend, and everything else to gitweb.cgi.

Norbert Preining: Debian KDE/Plasma Status 2021-08-18

18 August, 2021 - 12:52

Bullseye has been released, and we are in the post-release rush with lots of changes going on. On the KDE/Plasma side we are trying to move all our accumulated changes to unstable. On the OSC side, frameworks 5.85 and KDE Gears 21.08.0 have been released.

Debian Bullseye

As mentioned previously, the now released Debian/Bullseye contains KDE Frameworks 5.78, including several backports of fixes from 5.79 to get smooth operation. Plasma 5.20.5, again with several cherry picks for bugs will be in Bullseye, too. The KDE/Apps are mostly at 20.12 level, and the KDE PIM group packages (akonadi, kmail, etc) are at 20.08.

Debian unstable (and in time also testing)

Frameworks 5.83 and Plasma 5.21.5 have been uploaded to unstable. This is a temporary measure until several necessary packages have cleared the NEW queue. After that we will upload frameworks 5.85 and Plasma 5.22.N.

KDE Gears is still at 20.08, but we have 21.04 in experimental, and I am currently preparing to upload 21.08.0, should be done soon.

OBS packages

The OBS packages as usual follow the latest release, and currently ship KDE Frameworks 5.85, KDE Gears 21.08.0, and Plasma 5.22.4. The package sources are as usual (note the different path for the Plasma packages and the apps packages, containing the release version!), for Debian/unstable:

deb ./
deb ./
deb ./
deb ./

and the same with Testing instead of Unstable for Debian/testing.

OBS for bullseye

For now, use the Testing packages with the addition dependencies:

deb ./
deb ./
deb ./
deb ./
deb ./

Sooner or later OBS will offer Debian Bullseye as proper target, and then I will prepare releases for it and write another blog post.


Expect continued breakage of the next weeks until the upload storm subsides a bit.

Ian Jackson: Releasing nailing-cargo 1.0.0

18 August, 2021 - 03:19

I have just tagged nailing-cargo/1.0.0. nailing-cargo is a wrapper around the Rust build tool cargo. nailing-cargo can:

  • Work around cargo's problem with totally unpublished local crates (by temporally massaging your Cargo.toml)
  • Make it easier to work in Rust without giving the Rust environment (and every author of every one of your dependencies!) control of your main account. (Privsep, with linkfarming where needed.)
  • Tweak a few defaults.
Background and history

It's not really possible to make a nontrivial Rust project without using cargo. But the build process automatically downloads and executes code from, which is a minimally-curated repository. I didn't want to expose my main account to that.

And, at the time, I was working on a project which for which I was also writing a library as a dependency, and I found that cargo couldn't cope with this unless I were to commit (to my git repository) the path (on my local laptop) of my dependency.

I filed some bugs, including about the unpublished crate problem. But also, I was stubborn enough to try to find a workaround that didn't involve committing junk to my git history. The result was a short but horrific shell script.

I wrote about this at the time (March 2019).

Over the last few years the difficulties I have with cargo have remained un-resolved. I found my interactions with upstream rather discouraging. It didn't seem like I would get anywhere by trying to help improve cargo to better support my needs.

So instead I have gradually improved nailing-cargo. It is now a Perl script. It is rather less horrific, and has proper documentation (sorry, JS needed because GitLab).

Why Perl ?

Rust would have been my language of choice. But I wanted to avoid a chicken-and-egg situation. When you're doing privsep, nailing-cargo has to run in your more privileged environment. I wanted something easy to get going with.

nailing-cargo has to contain a TOML parser; and I found a small one, TOML-Tiny, which was good enough as a starting point, and small enough I could bundle it as a git subtree. Perl is nicely fast to start up (nailing-cargo --- true runs in about 170ms on my laptop), and it is easy to write a Perl script that will work on pretty much any Perl installation.

Still unsolved: embedding cargo in another build system A number of my projects contain a mixture of Rust code with other languages. Unfortunately, nailing-cargo doesn't help with the problems which arise trying to integrate cargo into another build system.

I generally resort to find runes for finding Rust source files that might influence cargo, and stamp files for seeing if I have run it recently enough; and I simply live with the fact that cargo sometimes builds more stuff than I needed it to.


There are a number of ways nailing-cargo could be improved.

Notably, the need to overwrite your actual Cargo.toml is very annoying, even if nailing-cargo puts it back afterwards. A big problem with this is that it means that nailing-cargo has to take a lock, while your cargo rune runs. This effectively prevents using nailing-cargo with long-running processes. Notably, editor integrations like rls and racer. I could perhaps solve this with more linkfarm-juggling, but that wouldn't help in-tree builds and it's hard to keep things up to date.

I am considering using LD_PRELOAD trickery or maybe bwrap(1) to "implement" the alternative Cargo.toml feature which was rejected by cargo upstream in 2019 (and again in April when someone else asked).

Currently there is no support for using sudo for out-of-tree privsep. This should be easy to add but it needs someone who uses sudo to want it (and to test it!) The documentation has some other dicusssion of limitations, some of which aren't too hard to improve.

Patches welcome!


Russ Allbery: Review: Black Sun

17 August, 2021 - 10:58

Review: Black Sun, by Rebecca Roanhorse

Series: Between Earth and Sky #1 Publisher: Saga Press Copyright: October 2020 ISBN: 1-5344-3769-X Format: Kindle Pages: 454

Serapio has been crafted and trained to be the vessel for a god. He grew up in Obregi land, far from his ancestral home, but he will return to Tova at the appropriate time and carry the hopes of the Carrion Crow clan with him.

Xiala is a ship captain, a woman, and a Teek. That means she's a target. Teek have magic, which makes them uncanny and dangerous. They're also said to carry that magic in their bones, which makes them valuable in ways that are not pleasant for the Teek. Running afoul of the moral codes of Cuecola is therefore even more dangerous to her than it would be to others, which is why she accepts a bargain to run errands for a local lord for twelve years, paid at the end of that time with ownership of a ship and crew. The first task: ferry a strange man to the city of Tova.

Meanwhile, in Tova, the priestess Naranpa has clawed her way to the top of the Sky Made hierarchy from an inauspicious beginning in the poor district of Coyote's Maw. She's ruthlessly separated herself from her despised beginnings and focused her attention on calming Tova in advance of the convergence, a rare astronomical alignment at the same time as the winter solstice. But Carrion Crow holds a deep-seated grudge at their slaughter by the priesthood during the Night of Knives, and Naranpa's position atop the religious order that partly rules Tova's fractious politics is more precarious than she thinks.

I am delighted that more fantasy is drawing on mythologies and histories other than the genre default of western European. It's long overdue for numerous reasons and a trend to be rewarded. But do authors writing fantasy in English who reach for Mesoamerican cultures have to gleefully embrace the excuse to add more torture? I'm developing an aversion to this setting (which I do not want to do!) because every book seems to feature human sacrifice, dismemberment, or some other horror show.

Roanhorse at least does not fill the book with that (there's lingering child abuse but nothing as sickening as the first chapter), but that makes the authorial choice to make the torture one's first impression of this book even odder. Our introduction to Serapio is a scene that I would have preferred to have never read, and I don't think it even adds much to the plot. Huge warnings for people who don't want to read about a mother torturing her son, or about eyes in that context.

Once past that introduction, Black Sun settles into a two-thread fantasy, one following Xiala and Serapio's sea voyage and the other following Naranpa and the political machinations in Tova. Both the magic systems and the political systems are different enough to be refreshing, and there are a few bits of world-building I enjoyed (a city built on top of rocks separated by deep canyons and connected with bridges, giant intelligent riding crows, everything about the Teek). My problem was that I didn't care what happened to any of the characters. Naranpa spends most of the book dithering and whining despite a backstory that should have promised more dynamic and decisive responses. The other character from Tova introduced somewhat later in the book is clearly "character whose story will appear in the next volume"; here, he's just station-keeping and representing the status quo. And while it's realistic given the plot that Serapio is an abused sociopath, that didn't mean I enjoyed reading his viewpoint or his childhood abuse.

Xiala is the best character in the book by far and I was warming to the careful work she has to do to win over an unknown crew, but apparently Roanhorse was not interested in that. Instead, the focus of Xiala's characterization turns to a bad-boy romance that did absolutely nothing for me. This will be a matter of personal taste; I know this is a plot feature for many readers. But it had me rolling my eyes and turning the pages to get to something more interesting (which, sadly, was not forthcoming). It also plays heavily on magical disabled person cliches, like the blind man being the best fighter anyone has met.

I did not enjoy this book very much, but there were some neat bits of world-building and I could see why other people might disagree. What pushed me into actively recommending against it (at least for now) is the publishing structure.

This is the first book of a trilogy, so one can expect the major plot to not be resolved by the end of the book. But part of the contract with the reader when publishing a book series is that each volume should reach some sense of closure and catharsis. There will be cliffhangers and unanswered questions, but there should also be enough plot lines that are satisfactorily resolved to warrant publishing a book as a separate novel.

There is none of that here. This is the first half (or third) of a novel. It introduces a bunch of plot lines, pulls them together, describes an intermediate crisis, and then simply stops. Not a single plot line is resolved. This is made worse by the fact this series (presumably, as I have only seen the first book) has a U-shaped plot: everything gets worse and worse until some point of crisis, and then presumably the protagonists will get their shit together and things will start to improve. I have soured on U-shaped plots since the first half of the story often feels like a tedious grind (eat your vegetables and then you can have dessert), but it's made much worse by cutting the book off at the bottom of the U. You get a volume, like Black Sun, that's all setup and horror and collapse, with no payoff or optimism.

After two tries, I have concluded that Roanhorse is not for me. This is clearly a me problem rather than a Roanhorse problem, given how many other people love both Black Sun and her Sixth World series, but this is the second book of hers where I mildly enjoyed the world building but didn't care about any of the characters. Ah well, tastes will differ. Even if you get along with Roanhorse, though, I recommend against starting this book until the second half of it is published (currently scheduled for 2022). As it stands, it's a wholly unsatisfying reading experience.

Followed by the not-yet-published Fevered Star.

Rating: 4 out of 10

Andrew Cater: Happy Birthday, Debian!

17 August, 2021 - 03:34

 28 today. In a video call for Debian day earlier on, I was reminiscing about the earliest distributions: MCC Interim Linux gave instructions to turn it's final version into Debian. Debian is the second oldest Linux distribution, just behind Slackware.

Debian 1.2 was my first Debian: my latest is, obviously, Debian Bullseye. Debian is like a family - often discordant, sometimes dysfunctional but always full of people that care and are cared for. I wish that some of my friends and colleagues no longer with us could be here to see just how well we're doing.

This is something that's been with me for so long that I can't imagine life without it: software, obscure hardware but above all friends closer than family. The biggest software project anywhere, potentially, and it's all for free - and 95.7% independently reproducible. Thanks to all my colleagues and co-workers who've become friends over the years without whom none of this would be possible. Oh, and thanks to Ian Murdock - I never got to meet him but I did get to email him when he was in charge of Progeny. Without him, none of this would even have started.


Creative Commons License ลิขสิทธิ์ของบทความเป็นของเจ้าของบทความแต่ละชิ้น
ผลงานนี้ ใช้สัญญาอนุญาตของครีเอทีฟคอมมอนส์แบบ แสดงที่มา-อนุญาตแบบเดียวกัน 3.0 ที่ยังไม่ได้ปรับแก้