Planet Debian

4 months ago I got my PinePhonePro [1]. Since then I have got SE Linux working on it to the stage of allowing it to boot correctly with Debian/Unstable, login with the user_t domain (minimum privilege for the graphical user) and make and receive calls. I finished getting SE Linux working reasonably well 3 days ago and most (but not all) of the SE Linux policy is in Debian now. I’ve been getting good at Github PRs and I’m sending a lot of policy upstream, so the next version of Debian will have a much smaller diff from the upstream Refpolicy. I have been running the PinePhone with Plasma Mobile because I prefer KDE, I would run GNOME/Phoc if it gave significantly better functionality.

3 days ago I moved my main SIM (the one with the number that people call about work etc) to my PhonePhone and tried running it as my main phone. Today I gave up on that.

My Android History

The last phone I had that did everything I needed was a Huawei Mate 10 Pro that I bought refurbished in June 2019 for $389. The Mate 10 Pro runs Android with the Google Play store and has been quite unremarkable which is presumably why I forgot to blog about it when I got it, it was a slight upgrade over the Huawei Mate 9 [2] that I had used for 2 years before that. In April 2022 I tried using a Huawei Nova 7i as my main phone without Google Play programs or services [3]. That experiment was a failure as I couldn’t get NextCloud to work for Calendaring and Contacts. It could be that I stuffed something up when trying that, but I put more skill and effort into trying to get it to work than most people ever would. The Nova 7i is a very slick phone, faster and nicer than the Mate 10 Pro (as expected being 2 years newer) while also having ridiculously long battery life. The Nova 7i when always on running the SchildiChat Matrix client and the Conversations Jabber client it will use less than 10% battery in a 8 hour work day.

As nice as the Nova 7i is for the core functions I still need to have Play Store apps for LinkedIn, Twitter, Facebook, Zoom, etc. Which meant connecting the Mate 10 Pro via Wifi. As slick as the Nova 7i is for non-Google stuff running it and the Mate 10 Pro is a medium amount of pain for a small amount of freedom.

So now I have for the moment abandoned the Nova 7i and gone back to the Mate 10 Pro. What I will try to do is to either forcibly install Google Play on the Nova 7i to make it my proprietary phone or to install an open distribution of Linux (IE not Android) to make it at least a small tablet which incidentally is much more powerful than a PinePhonePro.

Issues With the PinePhonePro

The battery charges very slowly (as much as 50 hours estimated charge time) and discharges fast. When used in a typical way in “Caffeine” mode to stop suspend so I can ssh to it etc it won’t come close to lasting an 8 hour day. Also it will only take 5V charging and ideally wants 5V 3A charging which most chargers won’t do. The charging speed over regular USB ports is very slow, sometimes stating it will take as much as 50 hours to charge. A phone that gets below 50% charge in less than 4 hours and can’t be charged at a reasonable speed from a USB port on a laptop or monitor is going to be a major pain to use in the office. I don’t think this can be fixed in software, we can alleviate it by making software more CPU efficient and by enabling various hardware sleep modes more effectively but the slow charging is a hardware issue that can’t be fixed.

The phone call quality is poor. Usually when on a call I hear static and sometimes the person at the other end appears to hear nothing. Also the UI for calls is different from Android which makes it take longer to answer a call and gives more missed calls. The UI issue is a combination of software and habits, both of which can be changed. But the call quality may be a hardware issue. I don’t know if it’s a hardware issue specific to my phone or something related to the PinePhonePro on the Telstra network.

Clicking on notification in the drop-down doesn’t take me to the app. I don’t know if this is regarded as a bug by the Plasma-Mobile developers. Also notifications aren’t displayed on the lock screen and there doesn’t seem to be a configuration option to enable this.

The Plasma-Mobile configuration for the wifi hotspot is difficult. There is no button for it in the drop-down menu (called Quicksettings in Plasma-Mobile) and no way of easily determining whether it’s in hotspot or wifi client mode. This isn’t an insurmountable problem and the worst-case is that I could write a script to do it, but it’s still annoying.

There is apparent support in the desktop version of KDE for syncing contacts from Google and I could probably get that working (although I failed last time I tried on the desktop), but it is a pain.

Conclusion

Most of the problems are software related and therefore I can get involved in solving them. I plan to keep working on these things. If all the software had worked in an ideal manner then I would have spent more time investigating the hardware issues of battery life and charge time and the quality of calls.

I now have my Librem5 [4] running Debian so I will be able to compare call quality with the PinePhonePro. If I’m unable to get the PinePhonePro working adequately then maybe making the Librem5 my main phone will be an option.

I hope that by early next year I will be able to make another test at using a FOSS phone my main phone. In the mean time I can still work on convergence and other things.

• [1] https://etbe.coker.com.au/2023/06/06/pinephonepro-first-impression/
• [2] https://etbe.coker.com.au/2017/12/14/huawei-mate9/
• [3] https://etbe.coker.com.au/2022/04/20/android-without-play/
• [4] https://etbe.coker.com.au/2022/03/19/more-librem5/

Related posts:

1. Health and Status Monitoring via Smart Phone Health Monitoring Eric Topol gave an interesting TED talk about...
2. Android Without Play A while ago I was given a few reasonably high-end...
3. PinePhonePro First Impression Hardware I received my PinePhone Pro [1] on Thursday, it...

APT currently knows about three types of upgrades:

• upgrade without new packages (apt-get upgrade)
• upgrade with new packages (apt upgrade)
• upgrade with new packages and deletions (apt{,-get} {dist,full}-upgrade)

All of these upgrade types are necessary to deal with upgrades within a distribution release. Yes, sometimes even removals may be needed because bug fixes require adding a Conflicts somewhere.

In Ubuntu we have a third type of upgrades, handled by a separate tool: release upgrades. ubuntu-release-upgrader changes your sources.list, and applies various quirks to the upgrade.

In this post, I want to look not at the quirk aspects but discuss how dependency solving should differ between intra-release and inter-release upgrades.

Previous solver projects (such as Mancoosi) operated under the assumption that minimizing the number of changes performed should ultimately be the main goal of a solver. This makes sense as every change causes risks. However it ignores a different risk, which especially applies when upgrading from one distribution release to a newer one: Increasing divergence from the norm.

Consider a person installs foo in Debian 12. foo depends on a | b, so a will be automatically installed to satisfy the dependency. A release later, a has some known issues and b is prefered, the dependency now reads: b|a.

A classic solver would continue to keep a installed because it was installed before, leading upgraded installs to have foo, a installed whereas new systems have foo, b installed. As systems get upgraded over and over, they continue to diverge further and further from new installs to the point that it adds substantial support effort.

My proposal for the new APT solver is that when we perform release upgrades, we forget which packages where previously automatically installed. We effectively perform a normalization: All systems with the same set of manually installed packages will end up with the same set of automatically installed packages. Consider the solving starting with an empty set and then installing the latest version of each previously manually installed package: It will see now that foo depends b|a and install b (and a will be removed later on as its not part of the solution).

Another case of divergence is Suggests handling. Consider that foo also Suggests s. You now install another package bar that depends s, hence s gets installed. Upon removing bar, s is not being removed automatically because foo still suggests it (and you may have grown used to foo’s integration of s). This is because apt considers Suggests to be important - they won’t be automatically installed, but will not be automatically removed.

In Ubuntu, we unset that policy on release upgrades to normalize the systems. The reasoning for that is simple: While you may have grown to use s as part of foo during the release, an upgrade to the next release already is big enough that removing s is going to have less of an impact - breakage of workflows is expected between release upgrades.

I believe that apt release-upgrade will benefit from both of these design choices, and in the end it boils down to a simple mantra:

• On upgrades within a release, minimize changes.
• On upgrades between releases, minimize divergence from fresh installs.

At the moment I am hard at work putting together the final bits for the AppStream 1.0 release (hopefully to be released this month). The new release comes with many new new features, an improved developer API and removal of most deprecated things (so it carefully breaks compatibility with very old data and the previous C API). One of the tasks for the upcoming 1.0 release was #481 asking about a formal way to distinguish Linux phone applications from desktop applications.

AppStream infamously does not support any “is-for-phone” label for software components, instead the decision whether something is compatible with a device is based the the device’s capabilities and the component’s requirements. This allows for truly adaptive applications to describe their requirements correctly, and does not lock us into “form factors” going into the future, as there are many and the feature range between a phone, a tablet and a tiny laptop is quite fluid.

Of course the “match to current device capabilities” check does not work if you are a website ranking phone compatibility. It also does not really work if you are a developer and want to know which devices your component / application will actually be considered compatible with. One goal for AppStream 1.0 is to have its library provide more complete building blocks to software centers. Instead of just a “here’s the data, interpret it according to the specification” API, libappstream now interprets the specification for the application and provides API to handle most common operations – like checking device compatibility. For developers, AppStream also now implements a few “virtual chassis configurations”, to roughly gauge which configurations a component may be compatible with.

To test the new code, I ran it against the large Debian and Flatpak repositories to check which applications are considered compatible with what chassis/device type already. The result was fairly disastrous, with many applications not specifying compatibility correctly (many do, but it’s by far not the norm!). Which brings me to the actual topic of this blog post: Very few seem to really know how to mark an application compatible with certain screen sizes and inputs! This is most certainly a matter of incomplete guides and good templates, so maybe this post can help with that a bit:

The ultimate cheat-sheet to mark your app “chassis-type” compatible

As a quick reminder, compatibility is indicated using AppStream’s relations system: A requires relation indicates that the system will not run at all or will run terribly if the requirement is not met. If the requirement is not met, it should not be installable on a system. A recommends relation means that it would be advantageous to have the recommended items, but it’s not essential to run the application (it may run with a degraded experience without the recommended things though). And a supports relation means a given interface/device/control/etc. is supported by this application, but the application may work completely fine without it.

I have a desktop-only application

A desktop-only application is characterized by needing a larger screen to fit the application, and requiring a physical keyboard and accurate mouse input. This type is assumed by default if no capabilities are set for an application, but it’s better to be explicit. This is the metadata you need:

<component type="desktop-application"> <id>org.example.desktopapp</id> <name>DesktopApp</name> [...] <requires> <display_length>768</display_length> <control>keyboard</control> <control>pointing</control> </requires> [...] </component>

With this requires relation, you require a small-desktop sized screen (at least 768 device-independent pixels (dp) on its smallest edge) and require a keyboard and mouse to be present / connectable. Of course, if your application needs more minimum space, adjust the requirement accordingly. Note that if the requirement is not met, your application may not be offered for installation.

Note: Device-independent / logical pixels

One logical pixel (= device independent pixel) roughly corresponds to the visual angle of one pixel on a device with a pixel density of 96 dpi (for historical X11 reasons) and a distance from the observer of about 52 cm, making the physical pixel about 0.26 mm in size. When using logical pixels as unit, they might not always map to exact physical lengths as their exact size is defined by the device providing the display. They do however accurately depict the maximum amount of pixels that can be drawn in the depicted direction on the device’s display space. AppStream always uses logical pixels when measuring lengths in pixels. I have an application that works on mobile and on desktop / an adaptive app

Adaptive applications have fewer hard requirements, but a wide range of support for controls and screen sizes. For example, they support touch input, unlike desktop apps. An example MetaInfo snippet for these kind of apps may look like this:

<component type="desktop-application"> <id>org.example.adaptive_app</id> <name>AdaptiveApp</name> [...] <requires> <display_length>360</display_length> </requires> <supports> <control>keyboard</control> <control>pointing</control> <control>touch</control> </supports> [...] </component>

Unlike the pure desktop application, this adaptive application requires a much smaller lowest display edge length, and also supports touch input, in addition to keyboard and mouse/touchpad precision input.

I have a pure phone/table app

Making an application a pure phone application is tricky: We need to mark it as compatible with phones only, while not completely preventing its installation on non-phone devices (even though its UI is horrible, you may want to test the app, and software centers may allow its installation when requested explicitly even if they don’t show it by default). This is how to achieve that result:

<component type="desktop-application"> <id>org.example.phoneapp</id> <name>PhoneApp</name> [...] <requires> <display_length>360</display_length> </requires> <recommends> <display_length compare="lt">1280</display_length> <control>touch</control> </recommends> [...] </component>

We require a phone-sized display minimum edge size (adjust to a value that is fit for your app!), but then also recommend the screen to have a smaller edge size than a larger tablet/laptop, while also recommending touch input and not listing any support for keyboard and mouse.

Please note that this blog post is of course not a comprehensive guide, so if you want to dive deeper into what you can do with requires/recommends/suggests/supports, you may want to have a look at the relations tags described in the AppStream specification.

Validation

It is still easy to make mistakes with the system requirements metadata, which is why AppStream 1.0 will provide more commands to check MetaInfo files for system compatibility. Current pre-1.0 AppStream versions already have an is-satisfied command to check if the application is compatible with the currently running operating system:

:~$ appstreamcli is-satisfied ./org.example.adaptive_app.metainfo.xml Relation check for: */*/*/org.example.adaptive_app/* Requirements: • Unable to check display size: Can not read information without GUI toolkit access. Recommendations: • No recommended items are set for this software. Supported: Physical keyboard found. Pointing device (e.g. a mouse or touchpad) found. • This software supports touch input.

In addition to this command, AppStream 1.0 will introduce a new one as well: check-syscompat. This command will check the component against libappstream’s mock system configurations that define a “most common” (whatever that is at the time) configuration for a respective chassis type.

If you pass the --details flag, you can even get an explanation why the component was considered or not considered for a specific chassis type:

:~$ appstreamcli check-syscompat --details ./org.example.phoneapp.metainfo.xml Chassis compatibility check for: */*/*/org.example.phoneapp/* Desktop: ✘ Incompatible • recommends: This software recommends a display with its shortest edge being << 1280 px in size, but the display of this device has 1280 px. • recommends: This software recommends a touch input device. Laptop: ✘ Incompatible • recommends: This software recommends a display with its shortest edge being << 1280 px in size, but the display of this device has 1280 px. • recommends: This software recommends a touch input device. Server: ✘ Incompatible • requires: This software needs a display for graphical content. • recommends: This software needs a display for graphical content. • recommends: This software recommends a touch input device. Tablet: Compatible (100%) Handset: Compatible (100%)

I hope this is helpful for people. Happy metadata writing!

Review: Chilling Effect, by Valerie Valdes

Series: Chilling Effect #1 Publisher: Harper Voyager Copyright: September 2019 Printing: 2020 ISBN: 0-06-287724-0 Format: Kindle Pages: 420

Chilling Effect is a space opera, kind of; more on the genre classification in a moment. It is the first volume of a series, although it reaches a reasonable conclusion on its own. It was Valerie Valdes's first novel.

Captain Eva Innocente's line of work used to be less than lawful, following in the footsteps of her father. She got out of that life and got her own crew and ship. Now, the La Sirena Negra and its crew do small transport jobs for just enough money to stay afloat. Or, maybe, a bit less than that, when the recipient of a crate full of psychic escape-artist cats goes bankrupt before she can deliver it and get paid. It's a marginal and tenuous life, but at least she isn't doing anything shady.

Then the Fridge kidnaps her sister.

The Fridge is a shadowy organization of extortionists whose modus operandi is to kidnap a family member of their target, stuff them in cryogenic suspension, and demand obedience lest the family member be sold off as indentured labor after a few decades as a popsicle. Eva will be given missions that she and her crew have to perform. If she performs them well, she will pay off the price of her sister's release. Eventually. Oh, and she's not allowed to tell anyone.

I found it hard to place the subgenre of this novel more specifically than comedy-adventure. The technology fits space opera: there are psychic cats, pilots who treat ships as extensions of their own body, brain parasites, a random intergalactic warlord, and very few attempts to explain anything with scientific principles. However, the stakes aren't on the scale that space opera usually goes for. Eva and her crew aren't going to topple governments or form rebellions. They're just trying to survive in a galaxy full of abusive corporations, dodgy clients, and the occasional alien who requires you to carry extensive documentation to prove that you can't be hunted for meat.

It is also, as you might guess from that description, occasionally funny. That part of the book didn't mesh for me. Eva is truly afraid for her sister, and some of the events in the book are quite sinister, but the antagonist is an organization called The Fridge that puts people in fridges. Sexual harassment in a bar turns into obsessive stalking by a crazed intergalactic warlord who frequently interrupts the plot by randomly blasting things with his fleet, which felt like something from Hitchhiker's Guide to the Galaxy. The stakes for Eva, and her frustrations at being dragged back into a life she escaped, felt too high for the wacky, comic descriptions of the problems she gets into.

My biggest complaint, though, is that the plot is driven by people not telling other people critical information they should know. Eva is keeping major secrets from her crew for nearly the entire book. Other people are also keeping information from Eva. There is a romance subplot driven almost entirely by both parties refusing to talk to each other about the existence of a romance subplot. For some people, this is catnip, but it's one of my least favorite fictional tropes and I found much of the book both frustrating and stressful. Fictional characters keeping important secrets from each other apparently raises my blood pressure.

One of the things I did like about this book is that Eva is Hispanic and speaks like it. She resorts to Spanish frequently for curses, untranslatable phrases, aphorisms, derogatory comments, and similar types of emotional communication that don't feel right in a second language. Most of the time one can figure out the meaning from context, but Valdes doesn't feel obligated to hold the reader's hand and explain everything. I liked that. I think this approach is more viable in these days of ebook readers that can attempt translations on demand, and I think it does a lot to make Eva feel like a real person.

I think the characters are the best part of this book, once one gets past the frustration of their refusal to talk to each other. Eva and the alien ship engineer get the most screen time, but Pink, Eva's honest-to-a-fault friend, was probably my favorite character. I also really enjoyed Min, the ship pilot who's primary goal is to be able to jack into the ship and treat it as her body, and otherwise doesn't particularly care about the rest of the plot as long as she gets paid.

A lot of books about ship crews like this one lean hard into found family. This one felt more like a group of coworkers, with varying degrees of friendship and level of interest in their shared endeavors, but without the too-common shorthand of making the less-engaged crew members either some type of villain or someone who needs to be drawn out and turned into a best friend or love interest. It's okay for a job to just be a job, even if it's one where you're around the same people all the time. People who work on actual ships do it all the time.

This is a half-serious, half-comic action romp that turned out to not be my thing, but I can see why others will enjoy it. Be prepared for a whole lot of communication failures and an uneven emotional tone, but if you're looking for a space-ships-and-aliens story that doesn't take itself very seriously and has some vague YA vibes, this may work for you.

Followed by Prime Deceptions, although I didn't like this well enough to read on.

Rating: 6 out of 10

A new minor release of the drat package arrived on CRAN today making it the first release in one and a half years. drat stands for drat R Archive Template, and helps with easy-to-create and easy-to-use repositories for R packages. Since its inception in early 2015 it has found reasonably widespread adoption among R users because repositories with marked releases is the better way to distribute code.

Because for once it really is as your mother told you: Friends don’t let friends install random git commit snapshots. Properly rolled-up releases it is. Just how CRAN shows us: a model that has demonstrated for two-plus decades how to do this. And you can too: drat is easy to use, documented by six vignettes and just works. Detailed information about drat is at its documentation site. Two more blog posts using drat from GitHub Actions were just added today showing, respectively, how to add to a drat repo in either push or pull mode.

This release contains two extended PRs contributed by drat users! Both extended support for macOS: Joey Reid extended M1 support to pruning and archival, and Arne Johannes added bug-sur support. I polished a few more things around the edges, mostly documentation or continuos-integrations related.

The NEWS file summarises the release as follows:

Changes in drat version 0.2.4 (2023-10-09)

• macOS Arm M1 repos are now also supported in pruning and archival (Joey Reid in #135 fixing #134)

• A minor vignette typo was fixed (Dirk)

• A small error with setwd() in insertPackage() was corrected (Dirk)

• macOS x86_64 repos (on big-sur) are now supported too (Arne Johannes Holmin in #139 fixing #138)

• A few small maintenance tweaks were applied to the CI setup, and to the main README.md

Courtesy of my CRANberries, there is a comparison to the previous release. More detailed information is on the drat page as well as at the documentation site.

If you like this or other open-source work I do, you can 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.

I have been managing my finances and getting an overview of where I am financially and where I am going month-to-month for a few years already. That means that I already have a method of doing my finances and a method of thinking about them. So far this has been supported by a commerical tool called MoneyWiz. I was happy to pay them for the ability to have a solid product and be able to easily access my finances from my phone (to enter cash transactions directly in the field) and sync data across multiple devices with their cloud offering. However, MoneyWiz development stalled. So much so that they stopped updating their Android app and cancelled web version plans to just focus on a iPhone and MacOS clients. And even there the development did not seem very successful over the last year. So I am cancelling their subscription, extracting all my data (as CSV) and looking for alternatives.

So let's start with the basics - what I want from finace software?

• Open source and self-hosted
• Accounts to represent real accounts in my bank, credit cards, cash account
• Transactions to represent money moving in/out/between accounts
• Tree of categories for transactions to categorise spending
• Category reports on arbitrary time periods
• Ability to see the expected balance on each account at any historic point in time from given transactions
• Ability to do a corrective transaction - hmm, I don't know what happened, but right now I have X€ in cash
• Adding past transactions before a corrective transaction should not change balance after correction
• Ability to automatically import transactions from my bank
• Ability to plan future, recurring transactions
• Incoming transactions from bank import should be auto-matched with planned recuring transactions
• Ability to see missed planned recurring transactions
• Ability to see value deviations in planned recuring transactions
• Ability to manually match a transaction with a planned recurring transaction for that month or skip a month
• Ability to see a projected balance on my accounts at any future date given planned transactions
• Credit card fully refilling its current (negative) balance to zero (from a given account) should be a plannable transaction
• Accessible from multiple devices, like Linux, Android, iPhone, MacOS. Most likely that means web-based
• Achiving accounts without loosing their past transactions with active accounts
• API to access data, so that I could wire that up to a Home Assistant dashboard

I don't care about currencies (thanks Euro!), localization, taxes and double-entry bookkeeping. I don't have much use for tags, budgets or savings targets.

It could be useful to be able to track stock investment values (but I do have a pretty good from the bank that does that anyway). And tracking loans (incoming and outgoing) could be a worthwhile thing as well, but that can also be simulated with separate accounts for each loan. Tracking refundable expenses (like medical expenses that insurances should refund later on) would also be nice. Could also be simulated by having a separate expense category (Medical - refundable) and putting the refund as a negative expense into that category.

One weird feature that I really like is having transfer transactions that have arbitrary incoming and outgoing dates. For some transactions it is a simple transfer delay - money leaves the account A on Friday and only appears in the destination account B on Monday morning. However, this can also happen the other way around - a few credit cards I have seen work in a way that on 14th of each month the balance of the credit card gets reset to zero and then a week later the negative balance that was on that credit card gets taken from the base account that the card is bound to. So the money leaves the base account a week later than it arrives in the credit card account. Financial systems really are magic sometimes :D

Ideally that should be represented by a single transaction with two dates - one date when money leaves one account and another date when it arrives in a different account, so that balances on both accounts in the days between would be correct (as in matching what the bank says they were on those dates). And it should automatch such transaction from bank data imports. And predict its value from the negative balance of the credit card. And a pony! But in worst case this could be simulated using a separate "In transfer" account.

When I am thinking about my finances, the key metric for me is - how much will I spend this month - both in fixed spending (rent, Internet and phone bills, health insurance, subscriptions, ...) and in variable spending (groceries, eating out, clothing, ...). In theory that should be trivial, but in practice a simple calendar month view will fail because a bunch of fixed expenses occur at the month end/start boundary and can happen either at the end of previous month or at start on next month, depending on how the weekends happen to fall and how the systems of various providers decided to do direct debits this month. So 1st of month is not a good snapshoting time. Any date between 6th (last possible days for monthly bills) and 20th (earliest possible salary day) would be a better cut off point. Looking at the balance of my main account at that time point lets me know what was the difference between income and expenses for the past month. And that is the number I want the financial app to be able to predict as soon as possible.

And additional complication is the way credit cards work here. The expenses booked to a credit card after 14th of September will only appear in the main account on 20th of October and thus will actually only count towards the expenses of month of October. That makes it very confusing to see a larger overspend in the main account on 6th of October and then use the categories to try to figure out where the money went, because all the spending that happened on the credit card after the 14th of September should not really be looked at in that context, but spending on the main account or cash account should be counted all the way to 6th of October. :D

I am not optimistic that any finance software would able to doea with this mess correctly.

So far I am tending to consider Firefly III which has most of what I need and looks great and well maintained, but has the tiny drawback of being written in PHP, so that basically excludes me from ability to contribute anything beyond ideas and feedback. :D

I already did a quick test of Firefly via local Docker containers, so the next step would be to try to set it up as a production instance (using the same always-on mini PC that is running my Home Assistant instance), get the database up and working, get the Firefly III itself up and running, get account importer working for bank connection, import historical transactions from there, setup my categories and recurring transactions, import past data dumped out of MoneyWiz and see if this works well and gives me the insights I need.

If you know a better solution, please let me know on any social or email channel!

I have made a new helper for producing Debian packages called debputy. Today, I uploaded it to Debian unstable for the first time. This enables others to migrate their package build using dh +debputy rather than the “classic” dh. Eventually, I hope to remove dh entirely from this equation, so you only need debputy. But for now, debputy still leverages dh support for managing upstream build systems.

The debputy tool takes a radicially different approach to packaging compared to our existing packaging methods by using a single highlevel manifest instead of all the debian/install (etc.) and no “hook targets” in debian/rules.

Here are some of the things that debputy can do or does:

• debputy can perform installation similar to dh_install, dh_installdocs (etc.) plus a bit of the dh-exec support. Notably, debputy supports “install /usr/bin/foo into foo” and “install everything else in /usr/bin into foo-utils” without you having to resort to weird tricks. With debhelper, this would require dh-exec‘s => /usr/bin/foo operator.
• debputy can assign mode to files without needing hooks and static file ownership can be assigned without resorting to fakeroot. If you request Rules-Requires-Root: no, debputy will assemble the deb without using fakeroot. The fragileness of fakeroot may some day just be a horror story we tell our unruly children that they do not really believe is true.
• debputy defaults to all scripts with a “#! /bin/tool” or “#! /usr/bin/tool” to have mode 0755 (a+x) unless they are placed in directories known not to have executable files (such as the perl module dirs). As an example, scripts in the examples directory may now get an automatic executable bit if they have a proper #!-line for /usr/bin or /bin.
• debputy supports the default flow of 48 debhelper tools. If you are using pure dh $@ with no sequence add-ons and no hook targets in debian/rules (or only hook targets for the upstream side), odds are that debputy got your needs covered.

There are also some features that debputy does not support at the moment:

• Almost any debhelper sequence add-on. The debputy tool comes with a migration tool that will auto-detect any unsupported dh add-on from Build-Depends and will flag them as potential problematic. The migration tool works from an list of approved add-ons. Note that manually activated add-ons via dh $@ –with … are not detected.
• Anything that installs or recently installed into /lib or another /usr-merged location. My life is too short to be directly involved in the /usr-merge transition. This means no udev and no systemd unit support at the moment (note tmpfiles and sysusers is supported). For the systemd side, I am also contemplating a different model for how to deal with services. Even without the /usr-merge transition, these would not have been supported. The migration tool will detect problematic file in the debian directory immediately and debputy will detect upstream provided systemd unit files at build time.
• There is also no support for packager provided maintscript files at this time. If you have your own maintscripts, then you will not be able to migrate. The migration tool detects the debhelper based path and warns you (such as debian/postinst).
• Additionally, if you need special cases in tools (such as perl-base dependency with dh_perl) or rely on dh_strip-nondeterminsm for reproducibility, then you cannot or is advised not to migrate at this time.

There are all limitations of the current work in progress. I hope to resolve them all in due time.

Trying debputy

With the limitations aside, lets talk about how you would go about migrating a package:

# Assuming here you have already run: apt install dh-debputy $ git clone https://salsa.debian.org/rra/kstart [...] $ cd kstart # Add a Build-Dependency on dh-sequence-debputy $ perl -n -i -e \ 'print; print " dh-sequence-debputy,\n" if m/debhelper-compat/;' \ debian/control $ debputy migrate-from-dh --apply-changes debputy: info: Loading plugin debputy (version: archive/debian/4.3-1) ... debputy: info: Verifying the generating manifest debputy: info: Updated manifest debian/debputy.manifest debputy: info: Removals: debputy: info: rm -f "./debian/docs" debputy: info: rm -f "./debian/examples" debputy: info: Migrations performed successfully debputy: info: Remember to validate the resulting binary packages after rebuilding with debputy $ cat debian/debputy.manifest manifest-version: '0.1' installations: - install-docs: sources: - NEWS - README - TODO - install-examples: source: examples/krenew-agent $ git add debian/debputy.manifest $ git commit --signoff -am"Migrate to debputy" # Run build tool of choice to verify the output.

This is of course a specific example that works out of the box. If you were to try this on debianutils (from git), the output would look something like this:

$ debputy migrate-from-dh debputy: info: Loading plugin debputy (version: 5.13-13-g9836721) ... debputy: error: Unable to migrate automatically due to missing features in debputy. * The "debian/triggers" debhelper config file (used by dh_installdeb is currently not supported by debputy. Use --acceptable-migration-issues=[...] to convert this into a warning [...]

And indeed, debianutils requires at least 4 debhelper features beyond what debputy can support at the moment (all related to maintscripts and triggers).

Rapid feedback

Rapid feedback cycles are important for keeping developers engaged in their work. The debputy tool provides the following features to enable rapid feedback.

Immediate manifest validation

It would be absolutely horrible if you had to do a full-rebuild only to realize you got the manifest syntax wrong. Therefore, debputy has a check-manifest command that checks the manifest for syntactical and semantic issues.

$ cat debian/debputy.manifest manifest-version: '0.1' installations: - install-docs: sources: - GETTING-STARTED-WITH-dh-debputy.md - MANIFEST-FORMAT.md - MIGRATING-A-DH-PLUGIN.md $ debputy check-manifest debputy: info: Loading plugin debputy (version: 0.1.7-1-gf34bd66) ... debputy: info: No errors detected. $ cat <<EOF >> debian/debputy.manifest - install: sourced: foo as: usr/bin/foo EOF # Did I typo anything? $ debputy check-manifest debputy: info: Loading plugin debputy (version: 0.1.7-2-g4ef8c2f) ... debputy: warning: Possible typo: The key "sourced" at "installations[1].install" should probably have been 'source' debputy: error: Unknown keys "{'sourced'}" at installations[1].install". Keys that could be used here are: sources, when, dest-dir, source, into. debputy: info: Loading plugin debputy (version: 0.1.7-2-g4ef8c2f) ... $ sed -i s/sourced:/source:/ debian/debputy.manifest $ debputy check-manifest debputy: info: Loading plugin debputy (version: 0.1.7-2-g4ef8c2f) ... debputy: info: No errors detected.

The debputy check-manifest command is limited to the manifest itself and does not warn about foo not existing as it could be produced as apart of the upstream build system. Therefore, there are still issues that can only be detected at package build time. But where debputy can reliably give you immediate feedback, it will do so.

Idempotence: Clean re-runs of dh_debputy without clean/rebuild

If you read the “fine print” of many debhelper commands, you may see the following note their manpage:

This command is not idempotent. dh_prep(1) should be called between

invocations of this command …

Manpage of an anonymous debhelper tool

What this usually means, is that if you run the command twice, you will get its maintscript change (etc.) twice in the final deb. This fits into our “single-use clean throw-away chroot builds” on the buildds and CI as well as dpkg-buildpackage‘s “no-clean” (-nc) option. Single-use throw-away chroots are not very helpful for debugging though, so I rarely use them when doing the majority of my packaging work as I do not want to wait for the chroot initialization (including installing of build-depends).

But even then, I have found that dpkg-buildpackage -nc has been useless for me in many cases as I am stuck between two options:

• With -nc, you often still interact with the upstream build system. As an example, debhelper will do a dh_prep followed by dh_auto_install, so now we are waiting for upstream’s install target to run again. What should have taken seconds now easily take 0.5-1 minute extra per attempt.
• If you want to by-pass this, you have to manually call the helpers needed (in correct order) and every run accumulates cruft from previous runs to the point that cruft drowns out the actual change you want to see. Also, I am rarely in the mood to play human dh, when I am debugging an issue that I failed to fix in my first, second and third try.

As you can probably tell, neither option has worked that well for me. But with dh_debputy, I have made it a goal that it will not “self-taint” the final output. If dh_debputy fails, you should be able to tweak the manifest and re-run dh_debputy with the same arguments.

• No waiting for dpkg-buildpackage -nc nor anything implied by that.
• No “self-tainting” of the final deb. The result you get, is the result you would have gotten if the previous dh_debputy run never happened.
• Because dh_debputy produces the final result, I do not have to run multiple tools in “the right” order.

Obviously, this is currently a lot easier, because debputy is not involved in the upstream build system at all. If this feature is useful to you, please do let me know and I will try to preserve it as debputy progresses in features.

Packager provided files

On a different topic, have you ever wondered kind of kind files you can place into the debian directory that debhelper automatically picks up or reacts too? I do not have an answer to that beyond it is over 80 files and that as the maintainer of debhelper, I am not willing to manually maintain such a list manually.

However, I do know what the answer is in debputy, because I can just ask debputy:

$ debputy plugin list packager-provided-files +-----------------------------+---------------------------------------------[...] | Stem | Installed As [...] +-----------------------------+---------------------------------------------[...] | NEWS | /usr/share/doc/{name}/NEWS.Debian [...] | README.Debian | /usr/share/doc/{name}/README.Debian [...] | TODO | /usr/share/doc/{name}/TODO.Debian [...] | bug-control | /usr/share/bug/{name}/control [...] | bug-presubj | /usr/share/bug/{name}/presubj [...] | bug-script | /usr/share/bug/{name}/script [...] | changelog | /usr/share/doc/{name}/changelog.Debian [...] | copyright | /usr/share/doc/{name}/copyright [...] [...]

This will list all file types (Stem column) that debputy knows about and it accounts for any plugin that debputy can find. Note to be deterministic, debputy will not auto-load plugins that have not been explicitly requested during package builds. So this list could list files that are available but not active for your current package.

Note the output is not intended to be machine readable. That may come in later version. Feel free to chime in if you have a concrete use-case.

Take it for a spin

As I started this blog post with, debputy is now available in unstable. I hope you will take it for a spin on some of your simpler packages and provide feedback on it.

For documentation, please have a look at:

• GETTING-STARTED-WITH-dh-debuty.md (how-to guide)
• MANIFEST-FORMAT.md (reference documentation)

Thanks for considering

PS: My deepest respect to the fakeroot maintainers. That game of whack-a-mole is not something I would have been willing to maintain. I think fakeroot is like the Python GIL in the sense that it has been important in getting Debian to where it is today. But at the same time, I feel it is time to let go of the “crutch” and find a proper solution.

Twenty-four is a big number. More than one/fourth (or more) of my life is behind me now. At this point, I truly feel like I have become an adult; mentally and physically. Another year seem to have gone by quickly. I still vividly remember writing 23 and Counting and here I’m writing the next one so soon.

Probably the lowest I felt ever on my birthday; with loss of Abraham and on the other hand, medical issues with a dear one. Didn’t even felt like birthday was almost here. The loss of Abraham, taught me to care for people more and meet cherish everyone. I’m grateful for all the people who supported and cared for me and others during times of grief when things went numb. Thank you!

Also, for the first time ever, I went to office on my birthday. This probably would become a norm in coming years. Didn’t felt like doing anything, so just went to office. The cake, wishes and calls kept coming in throughout the day. I’m grateful for the all people around for remembering :)

This year marked my first “official” job switch where I moved from MakeMyTrip to Unmukti as a GNU/Linux Network Systems engineer (that’s a mouthful of a job role, I know) where I do anything and everything ranging from system admin, network engineering, a bit of social media, chronicling stuff on company blog and bringing up new applications as per requirement. Moving from MMT to Unmukti was a big cultural shift. From a full-blown corporate with more than 3 thousand employees to a small 5-person team. People still think I work for a startup on hearing the low head count, though Unmukti is a 13 year old organization. I get the freedom to work at my own pace and put my ideas in larger technical discussions, while also actively participating in the community, which I’m truly grateful of. I go full geek here and almost everyone here is on the same spectrum, so things technical or societal discussions just naturally flow.

The months of August-September again marked the Great Refresh. For reasons unforeseen, I have had to pack my stuff again and move, albeit to just next door for now, but that gave me the much need opportunity to sift through my belongings here. As usual, I threw a boatload of stuff which was of no use and/or just hogging space. My wardrobe cupboard finally got cleaned and sorted, with old and new clothes getting (re)discovered. The Refresh is always a pain with loads of collating stuff in carry worthy bags and hauling stuff but as usual, there’s nothing else I can do other than just pack and move.

This year also culminated our four plus years of work for organizing annual Debian conference, DebConf to India. DebConf23 happened in Kochi, Kerala from 3rd September to 17th September (including DebCamp). First concrete work to bring conference to India was done Raju Dev who made the first bid during DebConf18 in Hsinchu, Taiwan. We lost but won during the next year bid at DebConf19 Curitiba, Brazil in 2019. I joined the efforts after meeting the team online after DebConf20. Initially started with the publicity team, but we didn’t need much publicity for event, I was later asked to join sponsors/fundraising team. That turned out to be quite an experience. Then the conference itself turned to be a good experience. More on that in an upcoming DebConf23 blog post, which will come eventually.

After seeing how things work out in Debian in 2020, I had the goal to become a Debian Developer (DD) before DebConf23, which gave me almost three years to get involved and get recognized to become a DD. I was more excited to grab sahil AT debian.org, a short email with only my name and no number of characters after it. After, quite a while, I dropped the hope of become a DD because I wasn’t successful in my attempts to meaningfully package and technically contribute to the project. But people in Debian India later convinced me that I have done enough to become a Debian Developer, non uploading, purely by showing up and helping around all for the Debian conferences. I applied and got sponsored (i.e. supported) for my request by srud and Praveen. Finally, on 23rd Feb, I officially became part of Debian project as 14th (at the moment) Debian Developer from India. Got sahil AT debian.org too :) For some grace, I also became a DD before DebConf23. Becoming a DD didn’t change anything much though, I still believe, it might have helped secure me a job though.

Also, worth mentioning is my increased interest in OpenStreetMap (OSM) mapping. I heavily mapped this year and went around for mapathon-meetups too. One step towards a better OSM and more community engagement around it.

Looking back at my blog, this year around, it seems mostly dotted with Debian and one OSM post. Significant shift from the range of topics I use to write about in the past year but blogging this year wasn’t a go-to activity. Other stuff kept me busy.

Living in Gurugram has shown me many facades of life from which I was shielded or didn’t come across earlier. It made me realize all the privileges which has helped me along the way, which became apparent while living “almost” alone here and managing thing by oneself.

Over in Cambridge with RattusRattus, Sledge, egw and Isy. Andy is very kindly putting us up.

We're almost all of the way through testing 12.2 and some of the way through testing 11.8.

It's a LONG day - heads down into laptops and relatively quiet - I think we're all tired and we've a way to go yet.

Last Sunday, our local Debian user group gathered to chat, to work on Debian and to do other, non-Debian related hacking. A "Debian & Stuff"!

It had been a while since we held a proper meetup. Our last event was the Montreal BSP we organised back in March 2023... We somewhat missed the window for a June meetup and summer events never seem to gather a good crowd, so I didn't try to organise one.

All this to say it was nice to see folks from the Montreal Debian community :)

This event was also the first time we were hosted by L'Espace des possibles - Petite Patrie, a social venue that aims to provide a space for not-for-profit activities, like repair cafés, sowing classes, board game nights, etc. It was really nice and we will surely meet there again in the future.

Many people came to the event, including some new ones. Although people always tend to come and go during the day, a total of 12 people attended the event.

As always, people worked on very different projects! One of the focus of this D&S was assembling AirGradient DIY basic kits. Our local community has been talking a lot about air quality metrics in the past few months1. Tiago thus decided to have a company print the PCBs for this kit and graciously gave away a few spares. Michael then took upon himself to order parts on AliExpress and a few of us ended up soldering the kits together while chatting.

Otherwise, some Debian work was also done:

• I triaged and closed a bunch of bug reports and started packaging labwc, a Wayland compositor heavily inspired by Openbox.
• Jérôme did some work on Clojure libraries that broke when Java 21 became supported in Sid.
• Gabriel worked on the libinfluxdb-http-perl library.
• Tiago and Tassia continued their work on the new DC Sources project and Tiago applied for a debian.net VM for this service.

The whole event was super fun, the tacos we had for lunch were delicious (and very authentic!), and we ended up at a local microbrewery to share a pint later in the evening.

Looking forward to the next event!

1. Mostly as a result of the large forest fires in Canada this summer. I myself blogged twice about air quality-related projects recently. ↩

Sick with COVID-19 and flu. This time around we had two different things going around the household. Failure to isolate the second case in the household resulted in more cases.

There are many valid reasons to create a custom Debian Installer image. You may need to pass some special arguments to the kernel, use a different GRUB version, automate the installation by means of preseeding, use a custom kernel, or modify the installer itself.

If you have a EFI system, which is probably the case in 2023, there is no need to learn complex procedures in order to create a custom Debian Installer stick.

The source of many frustrations is that the ISO format for CDs/DVDs is read-only, but you can just create a VFAT filesystem on a USB stick, copy all ISO contents onto the stick itself, and modify things at will.

Create a writable USB stick

First create a FAT32 filesystem on the removable device and mount it. The device is sdX in the example.

$ sudo parted --script /dev/sdX mklabel msdos $ sudo parted --script /dev/sdX mkpart primary fat32 0% 100% $ sudo mkfs.vfat /dev/sdX1 $ sudo mount /dev/sdX1 /mnt/data/

Then copy to the USB stick the installer ISO you would like to modify, debian-testing-amd64-netinst.iso here.

$ sudo kpartx -v -a debian-testing-amd64-netinst.iso # Mount the first partition on the ISO and copy its contents to the stick $ sudo mount /dev/mapper/loop0p1 /mnt/cdrom/ $ sudo rsync -av /mnt/cdrom/ /mnt/data/ $ sudo umount /mnt/cdrom # Same story with the second partition on the ISO $ sudo mount /dev/mapper/loop0p2 /mnt/cdrom/ $ sudo rsync -av /mnt/cdrom/ /mnt/data/ $ sudo umount /mnt/cdrom $ sudo kpartx -d debian-testing-amd64-netinst.iso $ sudo umount /mnt/data

Now try booting from the USB stick just to verify that everything went well and we can start customizing the image.

Boot loader, preseeding, installer hacks

The easiest things we can change now are the shim, GRUB, and GRUB’s configuration. The USB stick contains the shim under /EFI/boot/bootx64.efi, while GRUB is at /EFI/boot/grubx64.efi. This means that if you want to test a different shim / GRUB version, you just replace the relevant files. That’s it. Take for example /usr/lib/grub/x86_64-efi/monolithic/grubx64.efi from the package grub-efi-amd64-bin, or the signed version from grub-efi-amd64-signed and copy them under /EFI/boot/grubx64.efi. Or perhaps you want to try out systemd-boot? Then take /usr/lib/systemd/boot/efi/systemd-bootx64.efi from the package systemd-boot-efi, copy it to /EFI/boot/bootx64.efi and you’re good to go. Figuring out the right systemd-boot configuration needed to start the Installer is left as an exercise.

By editing /boot/grub/grub.cfg you can pass arbitrary arguments to the kernel and the Installer itself. See the official Installation Guide for a comprehensive list of boot parameters.

One very commong thing to do is automating the installation using a preseed file. Add the following to the kernel command line: preseed/file=/cdrom/preseed.cfg and create a /preseed.cfg file on the USB stick. As a little example:

d-i time/zone select Europe/Rome d-i passwd/root-password this-is-the-root-password d-i passwd/root-password-again this-is-the-root-password d-i passwd/user-fullname string Emanuele Rocca d-i passwd/username string ema d-i passwd/user-password password lol-haha-uh d-i passwd/user-password-again password lol-haha-uh d-i apt-setup/no_mirror boolean true d-i popularity-contest/participate boolean true tasksel tasksel/first multiselect standard

See Steve McIntyre’s awesome page with the full list of available settings and their description: https://preseed.einval.com/debian-preseed/.

Two noteworthy settings are early_command and late_command. They can be used to execute arbitrary commands and provide thus extreme flexibility! You can go as far as replacing parts of the installer with a sed command, or maybe wgetting an entirely different file. This is a fairly easy way to test minor Installer patches. As an example, I’ve once used this to test a patch to grub-installer:

d-i partman/early_command string wget https://people.debian.org/~ema/grub-installer-1035085-1 -O /usr/bin/grub-installer

Finally, the initrd contains all early stages of the installer. It’s easy to unpack it, modify whatever component you like, and repack it. Say you want to change a given udev rule:

$ mkdir /tmp/new-initrd $ cd /tmp/new-initrd $ zstdcat /mnt/data/install.a64/initrd.gz | sudo cpio -id $ vi lib/udev/rules.d/60-block.rules $ find . | cpio -o -H newc | zstd --stdout > /mnt/data/install.a64/initrd.gz Custom udebs

From a basic architectural standpoint the Debian Installer can be seen as an initrd that loads a series of special Debian packages called udebs. In the previous section we have seen how to (ab)use early_command to replace one of the scripts used by the Installer, namely grub-installer. It turns out that such script is installed by a udeb, so let’s do things right and build a new Installer ISO with our custom grub udeb.

Fetch the code for the grub-installer udeb, make your changes and build it with a classic dpkg-buildpackage -rfakeroot.

Then get the Installer code and install all dependencies:

$ git clone https://salsa.debian.org/installer-team/debian-installer/ $ cd debian-installer/ $ sudo apt build-dep .

Now add the grub-installer udeb to the localudebs directory and create a new netboot image:

$ cp /path/to/grub-installer_1.198_arm64.udeb build/localudebs/ $ cd build $ fakeroot make clean_netboot build_netboot

Give it some time, soon enough you’ll have a brand new ISO to test under dest/netboot/mini.iso.

Custom kernel

Perhaps there’s a kernel configuration option you need to enable, or maybe you need a more recent kernel version than what is available in sid.

The Debian Linux Kernel Handbook has all the details for how to do things properly, but here’s a quick example.

Get the Debian kernel packaging from salsa and generate the upstream tarball:

$ git clone https://salsa.debian.org/kernel-team/linux/ $ ./debian/bin/genorig.py https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

For RC kernels use the repo from Linus instead of linux-stable.

Now do your thing, for instance change a config setting by editing debian/config/amd64/config. Don’t worry about where you put it in the file, there’s a tool from https://salsa.debian.org/kernel-team/kernel-team to fix that:

$ /path/to/kernel-team/utils/kconfigeditor2/process.py .

Now build your kernel:

$ export MAKEFLAGS=-j$(nproc) $ export DEB_BUILD_PROFILES='pkg.linux.nokerneldbg pkg.linux.nokerneldbginfo pkg.linux.notools nodoc' $ debian/rules orig $ debian/rules debian/control $ dpkg-buildpackage -b -nc -uc

After some time, if everything went well, you should get a bunch of .deb files as well as a .changes file, linux_6.6~rc3-1~exp1_arm64.changes here. To generate the udebs used by the Installer you need to first get a linux-signed .dsc file, and then build it — with sbuild in this example:

$ /path/to/kernel-team/scripts/debian-test-sign linux_6.6~rc3-1~exp1_arm64.changes $ sbuild --dist=unstable --extra-package=$PWD linux-signed-arm64_6.6~rc3+1~exp1.dsc

Excellent, now you should have a ton of .udebs. To build a custom installer image with this kernel, copy them all under debian-installer/build/localudebs/ and then run fakeroot make clean_netboot build_netboot as described in the previous section. In case you are trying to use a different kernel version from what is currently in sid, you will have to install the linux-image package on the system building the ISO, and change LINUX_KERNEL_ABI in build/config/common. The linux-image dependency in debian/control probably needs to be tweaked as well.

That’s it, the new Installer ISO should boot with your custom kernel!

There is going to be another minor obstacle though, as anna will complain that your new kernel cannot be found in the archive. Copy the kernel udebs you have built onto a vfat formatted USB stick, switch to a terminal, and install them all with udpkg:

~ # udpkg -i *.udeb

Now the installation should proceed smoothly.

Review: The Far Reaches, edited by John Joseph Adams

Publisher: Amazon Original Stories Copyright: June 2023 ISBN: 1-6625-1572-3 ISBN: 1-6625-1622-3 ISBN: 1-6625-1503-0 ISBN: 1-6625-1567-7 ISBN: 1-6625-1678-9 ISBN: 1-6625-1533-2 Format: Kindle Pages: 219

Amazon has been releasing anthologies of original short SFF with various guest editors, free for Amazon Prime members. I previously tried Black Stars (edited by Nisi Shawl and Latoya Peterson) and Forward (edited by Blake Crouch). Neither were that good, but the second was much worse than the first. Amazon recently released a new collection, this time edited by long-standing SFF anthology editor John Joseph Adams and featuring a new story by Ann Leckie, which sounded promising enough to give them another chance.

The definition of insanity is doing the same thing over and over again and expecting different results.

As with the previous anthologies, each story is available separately for purchase or Amazon Prime "borrowing" with separate ISBNs. The sidebar cover is for the first in the sequence. Unlike the previous collections, which were longer novelettes or novellas, my guess is all of these are in the novelette range. (I did not do a word count.)

If you're considering this anthology, read the Okorafor story ("Just Out of Jupiter's Reach"), consider "How It Unfolds" by James S.A. Corey, and avoid the rest.

"How It Unfolds" by James S.A. Corey: Humans have invented a new form of physics called "slow light," which can duplicate any object that is scanned. The energy expense is extremely high, so the result is not a post-scarcity paradise. What the technology does offer, however, is a possible route to interstellar colonization: duplicate a team of volunteers and a ship full of bootstrapping equipment, and send copies to a bunch of promising-looking exoplanets. One of them might succeed.

The premise is interesting. The twists Corey adds on top are even better. What can be duplicated once can be duplicated again, perhaps with more information.

This is a lovely science fiction idea story that unfortunately bogs down because the authors couldn't think of anywhere better to go with it than relationship drama. I found the focus annoying, but the ideas are still very neat. (7)

"Void" by Veronica Roth: A maintenance worker on a slower-than-light passenger ship making the run between Sol and Centauri unexpectedly is called to handle a dead body. A passenger has been murdered, two days outside the Sol system. Ace is in no way qualified to investigate the murder, nor is it her job, but she's watched a lot of crime dramas and she has met the victim before. The temptation to start poking around is impossible to resist.

It's been a long time since I've read a story built around the differing experiences of time for people who stay on planets and people who spend most of their time traveling at relativistic speeds. It's a bit of a retro idea from an earlier era of science fiction, but it's still a good story hook for a murder mystery. None of the characters are that memorable and Roth never got me fully invested in the story, but this was still a pleasant way to pass the time. (6)

"Falling Bodies" by Rebecca Roanhorse: Ira is the adopted son of a Genteel senator. He was a social experiment in civilizing the humans: rescue a human orphan and give him the best of Genteel society to see if he could behave himself appropriately. The answer was no, which is how Ira finds himself on Long Reach Station with a parole officer and a schooling opportunity, hopefully far enough from his previous mistakes for a second chance.

Everyone else seems to like Rebecca Roanhorse's writing better than I do, and this is no exception. Beneath the veneer of a coming-of-age story with a twist of political intrigue, this is brutal, depressing, and awful, with an ending that needs a lot of content warnings. I'm sorry that I read it. (3)

"The Long Game" by Ann Leckie: The Imperial Radch trilogy are some of my favorite science fiction novels of all time, but I am finding Leckie's other work a bit hit and miss. I have yet to read a novel of hers that I didn't like, but the short fiction I've read leans more heavily into exploring weird and alien perspectives, which is not my favorite part of her work. This story is firmly in that category: the first-person protagonist is a small tentacled alien creature, a bit like a swamp-dwelling octopus.

I think I see what Leckie is doing here: balancing cynicism and optimism, exploring how lifespans influence thinking and planning, and making some subtle points about colonialism. But as a reading experience, I didn't enjoy it. I never liked any of the characters, and the conclusion of the story is the unsettling sort of main-character optimism that seems rather less optimistic to the reader. (4)

"Just Out of Jupiter's Reach" by Nnedi Okorafor: Kármán scientists have found a way to grow living ships that can achieve a symbiosis with a human pilot, but the requirements for that symbiosis are very strict and hard to predict. The result was a planet-wide search using genetic testing to find the rare and possibly nonexistent matches. They found seven people.

The deal was simple: spend ten years in space, alone, in her ship. No contact with any other human except at the midpoint, when the seven ships were allowed to meet up for a week. Two million euros a year, for as long as she followed the rules, and the opportunity to be part of a great experiment, providing data that will hopefully lead to humans becoming a spacefaring species.

The core of this story is told during the seven days in the middle of the mission, and thus centers on people unfamiliar with human contact trying to navigate social relationships after five years in symbiotic ships that reshape themselves to their whims and personalities. The ships themselves link so that the others can tour, which offers both a good opportunity for interesting description and a concretized metaphor about meeting other people.

I adore symbiotic spaceships, so this story had me at the premise. The surface plot is very psychological, and I didn't entirely click with it, but the sense of wonder vibes beneath that surface were wonderful. It also feels fresh and new: I've seen most of the ideas before, but not presented or written this way, or approached from quite this angle. Definitely the best story of the anthology. (8)

"Slow Time Between the Stars" by John Scalzi: This, on the other hand, was a complete waste of time, redeemed only by being the shortest "story" in the collection. "Story" is generous, since there's only one character and a very dry, linear plot that exists only to make a philosophical point. "Speculative essay" may be closer.

The protagonist is the artificial intelligence responsible for Earth's greatest interstellar probe. It is packed with a repository of all of human knowledge and the raw material to create life. Its mission is to find an exoplanet capable of sustaining that life, and then recreate it and support it. The plot, such as it is, follows the AI's decision to abandon that mission and cut off contact with Earth, for reasons that it eventually explains.

Every possible beat of this story hit me wrong. The sense of wonder attaches to the most prosaic things and skips over the moments that could have provoked real wonder. The AI is both unbelievable and irritating, with all of the smug self-confidence of an Internet reply guy. The prose is overwrought in all the wrong places ("the finger of God, offering the spark to animate the dirt of another world" would totally be this AI's profile quote under their forum avatar). The only thing I liked about the story is the ethical point that it slowly meanders into, which I think I might agree with and at least find plausible. But it's delivered by the sort of character I would actively leave rooms to avoid, in a style that's about as engrossing as a tax form. Avoid. (2)

Rating: 5 out of 10

KDE neon

KDE neon:

KDE neon is extremely important to the KDE snaps eco-system as I briefly mentioned in my last post.

Why? KDE neon is based on Jammy LTS which is the same as Core 22 base for snaps. Neon has a very useful continuous integration system in place that tests all the things, including dependencies, qml, cmake errors, debian packaging lintian tool and the list go on. This is very important to get packages out that don’t break things on user desktops. Once the packages are a lovely shade of green on the neon CI ( or at least all the important issues are resolved ) it is in good shape for snapping. I have scripts that pull the build and runtime dependency information for our application package to use in the snapcraft.yaml. We know this list is complete, because it passed the tests!

As applications gain features, they requires newer dependencies than what is provided in the ubuntu jammy repositories. Neon builds those newer dependencies and provides them to our users in the neon aptly repositories. It is much easier and more reliable than tracking down PPAs and hoping they stay maintained. We use the neon user edition repository in our snapcraft file to ensure we are up to date on KDE applications dependency needs.

This week my work in Neon included turning jobs green and fixing kio-gdrive which is still qt5, but it’s dependency libkgapi is qt6! We have to provide both versions in cases like this which entails tracking both master and the qt5 release branch.

Snaps:

This week begun the big transition from single repository remote-builds to per repository snapcraft and using snap recipes on launchpad. This is an important move for a couple of reasons. We were having major issues with build failures as I pointed out in this bug report on launchpad: https://bugs.launchpad.net/launchpad/+bug/2031307 . This was due to the way remote-build works. It creates temporary snap recipes that builds once and sends back the snap or failure status. This made it very difficult to debug build failures as once the failure status was sent the job disappeared off of launchpad, taking all build logs with it.

Now with the per repository snapcraft files, I have set up proper snap recipes on launchpad and the builds are automated by polling the github mirror for changes and it publishes the shiny new snap to candidate for testing or sends me the failure log that I can view at my convenience.

This of course is a work in progress as we have 186 snaps currently and there are a few steps to get each one done. But once it is done, it will reduce my workload immensely and make debugging build issues faster.

While making the move, I am also updating the snapcraft files for changes within snapcraft, adding cleanup to decrease bloat and fixing bugs!

Snap move complete:

• KMymoney 5.1: Fixed issue where hitting calculator button did nothing. It now launches a kcalc snap.
• Blinken 23.08.1
• Artikulate 23.08.1: This is now shipped with courses from https://invent.kde.org/education/artikulate-data
• Bomber 23.08.1
• Bovo 23.08.1
• Alligator 23.08.1: Added missing qml dependencies.
• Angelfish 23.08.1: Added missing qml dependencies.
• Arianna 23.08.1

Current WIP: Audiotube, Digikam, Cantor, Neochat

I also made a new content pack with KDE frameworks 5.110, but a new Qt 5.15.11 was just released so I will be making a new one tomorrow.

The kf6 content snap has come to a halt as the qt6 content snap has stalled. I asked to be given access to the snapcraft file so that I may collaborate, but have not heard back.

My mysterious project has reached its end for me. I might get a part time gig doing snaps out of it, but I do not meet the requirements to do any of the engineering of it. It is what it is. Thank you to all who vouched for me, alas it wasn’t meant to be.

If you can spare some change, I would appreciate it, especially to pay my phone/Internet bill so I can do more Neon and snaps Thank you for stopping by.

Donate https://gofund.me/b8b69e54

I've released version 2.3.0 of Nageru, my free software video mixer. As always, it's also been uploaded to Debian unstable.

The “big ticket” thing this time around is SRT video output; the world is finally moving on from RTMP, and I thought that it was a good opportunity to add a method of push contribution (even though I still find pull more flexible).

Apart from that, there's a slew of deprecations in FFmpeg that have built up over the last few versions. Keeping up with the churn is something that really doesn't benefit users much at all, so I'm a bit reluctant to do it before it's really needed, but it was getting hard to see actual warnings ammong all the deprecations, so now there's pretty much everything in one version, and I hope that's it for a little while.

The changelog reads:

Nageru and Futatabi 2.3.0, October 5th, 2023 - Support SRT output of the encoded stream, including output to YouTube if your account is enabled for this (beta testers only as of this release). This is useful for push, and for bad networks (e.g. 4G). - Fix various deprecation warnings with newer FFmpeg (Nageru should now be warning-free with FFmpeg 6.0). This also means that Nageru now requires FFmpeg 5.1 or newer. - Fix crashes with newer SVT-AV1.

Review: The Last Watch, by J.S. Dewes

Series: Divide #1 Publisher: Tor Copyright: 2021 ISBN: 1-250-23634-7 Format: Kindle Pages: 476

The Last Watch is the first book of a far-future science fiction duology. It was J.S. Dewes's first novel.

The station of the SCS Argus is the literal edge of the universe: the Divide, beyond which there is nothing. Not simply an absence of stars, but a nothing from a deeper level of physics. The Argus is there to guard against a return of the Viators, the technologically superior alien race that nearly conquered humanity hundreds of years prior and has already returned once, apparently traveling along the Divide. Humanity believes the Viators have been wiped out, but they're not taking chances.

It is not a sought-after assignment.

The Sentinels are the dregs of the military: convicts, troublemakers, and misfits, banished to the literal edge of nowhere. Joining them at the start of this book is the merchant prince, cocky asshole, and exiled sabateur Cavalon Mercer. He doesn't know what to expect from either military service or service on the edge of the universe. He certainly did not expect the Argus to be commanded by Adequin Rake, a literal war hero and a far more effective leader than this post would seem to warrant.

There are reasons why Rake is out on the edge of the universe, ones that she's not eager to talk about. They quickly become an afterthought when the Argus discovers that the Divide is approaching their position. The universe is collapsing, and the only people who know about it are people the System Collective would prefer to forget exist.

Yes, the edge of the universe, not the edge of the galaxy. Yes, despite having two FTL mechanisms, this book has a scale problem that it never reconciles. And yes, the physics do not really make sense, although this is not the sort of book that tries to explain the science. The characters are too busy trying to survive to develop new foundational theories of physics.

I was looking for more good military SF after enjoying Artifact Space so much (and still eagerly awaiting the sequel), so I picked this up. It has some of the same elements: the military as a place where you can make a fresh start with found family elements, the equalizing effects of military assignments, and the merits of good leadership. They're a bit disguised here, since this is a crew of often-hostile misfits under a lot of stress with a partly checked-out captain, but they do surface towards the end of the book.

The strength of this book is the mystery of the contracting universe, which poses both an immediate threat to the ship and a longer-term potential threat to, well, everything. The first part of the book builds tension with the immediate threat, but the story comes into its own when the crew starts piecing together the connections between the Viators and the Divide while jury-rigging technology and making risky choices between a lot of bad options. This is the first half of a duology, so the mysteries are not resolved here, but they do reach a satisfying and tantalizing intermediate conclusion.

The writing is servicable and adequate, but it's a bit clunky in places. Dewes doesn't quite have the balance right between setting the emotional stakes and not letting the characters indulge in rumination. Rake is a good captain who is worn down and partly checked out, Mercer is scared and hiding it with arrogance and will do well when given the right sort of attention, and all of this is reasonably obvious early on and didn't need as many of the book's pages as it gets. I could have done without the romantic subplot, which I thought was an unnecessary distraction from the plot and turned into a lot of tedious angst, but I suspect I was not the target audience. (Writers, please remember that people can still care about each other and be highly motivated by fear for each other without being romantic partners.)

I would not call this a great book. The characters are not going to surprise you that much, and it's a bit long for the amount of plot that it delivers. If you are the sort of person who nit-picks the physics of SF novels and gets annoyed at writers who don't understand how big the universe is, you will have to take a deep breath and hold on to your suspension of disbelief. But Dewes does a good job with ratcheting up the tension and conveying an atmosphere of mysterious things happening at the edge of nowhere, while still keeping it in the genre of mysterious technology and mind-boggingly huge physical phenomena rather than space horror. If you've been looking for that sort of book, this will do. I was hooked and will definitely read the sequel.

Followed by The Exiled Fleet.

Rating: 7 out of 10

Several years ago, several people proposed a mechanism to upload packages to Debian just by doing "git tag" and "git push". Two not too long discussions on debian-devel (first and second) did not end with an agreement how this mechanism could work.1 The central problem was the ability to properly trace uploads back to the ones who authorised it.

Now, several years later and after re-reading those e-mail threads, I again was stopped at the question: can we do this? Yes, it would not be just "git tag", but could we do with close enough? I have some rudimentary code ready to actually do uploads from the CI. However the list of caveats are currently pretty long.

Yes, it works in principle. It is still disabled here, because in practice it does not yet work.

Problems with this setup

So what are the problems?

It requires the git tags to include the both signed files for a successful source upload. This is solved by a new tool that could be a git sub-command. It just creates the source package, signs it and adds the signed file describing the upload (the .dsc and .changes file) to the tag to be pushed. The CI then extracts the signed files from the tag message and does it's work as normal.

It requires a sufficiently reproducible build for source packages. Right now it is only known to work with the special 3.0 (gitarchive) source format, but even that requires the latest version of this format. No idea if it is possible to use others, like 3.0 (quilt) for this purpose.

The shared GitLab runner provides by Salsa do not allow ftp access to the outside. But Debian still uses ftp to do uploads. At least if you don't want to share your ssh key, which can't be restricted to uploads only, but ssh would not work either. And as the current host for those builds, the Google Cloud Platform, does not provide connection tracking support for ftp, there is no easy way to allow that without just allowing everything. So we have no way to currently actually perform uploads from this platform.

Further work

As this is code running in a CI under the control of the developer, we can easily do other workflows. Some teams do workflows that do tags after acceptance into the Debian archive. Or they don't use tags at all. With some other markers, like variables or branch names, this support can be expanded easily.

Unrelated to this task here, we might want to think about tying the .changes files for uploads to the target archive. As this code makes all of them readily available in form of tag message, replaying them into possible other archives might be more of a concern now.

Conclusion

So to come back to the question, yes we can. We can prepare uploads using our CI in a way that they would be accepted into the Debian archive. It just needs some more work on infrastructure.

1. Here I have to admit that, after reading it again, I'm not really proud of my own behaviour and have to apologise. ↩

Electronic receipt storage in Japan. Japan also started allowing electronic data for receipts, but had some red tape associated with it. Presumably they were worried about increase in fraud cases. Law amendment that went in effet Jan 2022 made the last annoying bits simpler. We used to be required to sign the paper receipt and scan within 3 days of receiving the receipt. This special requirement is now gone. It took a few years to reach this state but now we are at a similar state as our colleagues in the US. Nice.

Review: Monstrous Regiment, by Terry Pratchett

Series: Discworld #31 Publisher: Harper Copyright: October 2003 Printing: August 2014 ISBN: 0-06-230741-X Format: Mass market Pages: 457

Monstrous Regiment is the 31st Discworld novel, but it mostly stands by itself. You arguably could start here, although you would miss the significance of Vimes's presence and the references to The Truth. The graphical reading order guide puts it loosely after The Truth and roughly in the Industrial Revolution sequence, but the connections are rather faint.

There was always a war. Usually they were border disputes, the national equivalent of complaining that the neighbor was letting their hedge row grow too long. Sometimes they were bigger. Borogravia was a peace-loving country in the middle of treacherous, devious, warlike enemies. They had to be treacherous, devious, and warlike; otherwise, we wouldn't be fighting them, eh? There was always a war.

Polly's brother, who wanted nothing more than to paint (something that the god Nuggan and the ever-present Duchess certainly did not consider appropriate for a strapping young man), was recruited to fight in the war and never came back. Polly is worried about him and tired of waiting for news. Exit Polly, innkeeper's daughter, and enter the young lad Oliver Perks, who finds the army recruiters in a tavern the next town over. One kiss of the Duchess's portrait later, and Polly is a private in the Borogravian army.

I suspect this is some people's favorite Discworld novel. If so, I understand why. It was not mine, for reasons that I'll get into, but which are largely not Pratchett's fault and fall more into the category of pet peeves.

Pratchett has dealt with both war and gender in the same book before. Jingo is also about a war pushed by a ruling class for stupid reasons, and featured a substantial subplot about Nobby cross-dressing that turns into a deeper character re-evaluation. I thought the war part of Monstrous Regiment was weaker (this is part of my complaint below), but gender gets a considerably deeper treatment. Monstrous Regiment is partly about how arbitrary and nonsensical gender roles are, and largely about how arbitrary and abusive social structures can become weirdly enduring because they build up their own internally reinforcing momentum. No one knows how to stop them, and a lot of people find familiar misery less frightening than unknown change, so the structure continues despite serving no defensible purpose.

Recently, there was a brief attempt in some circles to claim Pratchett posthumously for the anti-transgender cause in the UK. Pratchett's daughter was having none of it, and any Pratchett reader should have been able to reject that out of hand, but Monstrous Regiment is a comprehensive refutation written by Pratchett himself some twenty years earlier. Polly is herself is not transgender. She thinks of herself as a woman throughout the book; she's just pretending to be a boy. But she also rejects binary gender roles with the scathing dismissal of someone who knows first-hand how superficial they are, and there is at least one transgender character in this novel (although to say who would be a spoiler). By the end of the book, you will have no doubt that Pratchett's opinion about people imposing gender roles on others is the same as his opinion about every other attempt to treat people as things.

That said, by 2023 standards the treatment of gender here seems... naive? I think 2003 may sadly have been a more innocent time. We're now deep into a vicious backlash against any attempt to question binary gender assignment, but very little of that nastiness and malice is present here. In one way, this is a feature; there's more than enough of that in real life. However, it also makes the undermining of gender roles feel a bit too easy. There are good in-story reasons for why it's relatively simple for Polly to pass as a boy, but I still spent a lot of the book thinking that passing as a private in the army would be a lot harder and riskier than this. Pratchett can't resist a lot of cross-dressing and gender befuddlement jokes, all of which are kindly and wry but (at least for me) hit a bit differently in 2023 than they would have in 2003. The climax of the story is also a reference to a classic UK novel that to even name would be to spoil one or both of the books, but which I thought pulled the punch of the story and dissipated a lot of the built-up emotional energy.

My larger complaints, though, are more idiosyncratic. This is a war novel about the enlisted ranks, including the hazing rituals involved in joining the military. There are things I love about military fiction, but apparently that reaction requires I have some sympathy for the fight or the goals of the institution. Monstrous Regiment falls into the class of war stories where the war is pointless and the system is abusive but the camaraderie in the ranks makes service oddly worthwhile, if not entirely justifiable.

This is a real feeling that many veterans do have about military service, and I don't mean to question it, but apparently reading about it makes me grumbly. There's only so much of the apparently gruff sergeant with a heart of gold that I can take before I start wondering why we glorify hazing rituals as a type of tough love, or why the person with some authority doesn't put a direct stop to nastiness instead of providing moral support so subtle you could easily blink and miss it. Let alone the more basic problems like none of these people should have to be here doing this, or lots of people are being mangled and killed to make possible this heart-warming friendship.

Like I said earlier, this is a me problem, not a Pratchett problem. He's writing a perfectly reasonable story in a genre I just happen to dislike. He's even undermining the genre in the process, just not quite fast enough or thoroughly enough for my taste.

A related grumble is that Monstrous Regiment is very invested in the military trope of naive and somewhat incompetent officers who have to be led by the nose by experienced sergeants into making the right decision. I have never been in the military, but I work in an industry in which it is common to treat management as useless incompetents at best and actively malicious forces at worst. This is, to me, one of the most persistently obnoxious attitudes in my profession, and apparently my dislike of it carries over as a low tolerance for this very common attitude towards military hierarchy.

A full expansion of this point would mostly be about the purpose of management, division of labor, and people's persistent dismissal of skills they don't personally have and may perceive as gendered, and while some of that is tangentially related to this book, it's not closely-related enough for me to bore you with it in a review. Maybe I'll write a stand-alone blog post someday. Suffice it to say that Pratchett deployed a common trope that most people would laugh at and read past without a second thought, but that for my own reasons started getting under my skin by the end of the novel.

All of that grumbling aside, I did like this book. It is a very solid Discworld novel that does all the typical things a Discworld novel does: likable protagonists you can root for, odd and fascinating side characters, sharp and witty observations of human nature, and a mostly enjoyable ending where most of the right things happen. Polly is great; I was very happy to read a book from her perspective and would happily read more. Vimes makes a few appearances being Vimes, and while I found his approach in this book less satisfying than in Jingo, I'll still take it. And the examination of gender roles, even if a bit less fraught than current politics, is solid Pratchett morality.

The best part of this book for me, by far, is Wazzer. I think that subplot was the most Discworld part of this book: a deeply devout belief in a pseudo-godlike figure that is part of the abusive social structure that creates many of the problems of the book becomes something considerably stranger and more wonderful. There is a type of belief that is so powerful that it transforms the target of that belief, at least in worlds like Discworld that have a lot of ambient magic. Not many people have that type of belief, and having it is not a comfortable experience, but it makes for a truly excellent story.

Monstrous Regiment is a solid Discworld novel. It was not one of my favorites, but it probably will be someone else's favorite for a host of good reasons. Good stuff; if you've read this far, you will enjoy it.

Followed by A Hat Full of Sky in publication order, and thematically (but very loosely) by Going Postal.

Rating: 8 out of 10

It's been quiet here (I hope to change that), but I want to share some good news: I've been promoted to Principal Software Engineer! Next February will start my 9th year with Red Hat. Time flies when you're having fun!