Planet Debian

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

Freexian Meetup, by Stefano Rivera, Utkarsh Gupta, et al.

During DebConf, Freexian organized a meetup for its collaborators and those interested in learning more about Freexian and its services. It was well received and many people interested in Freexian showed up.

Some developers who were interested in contributing to LTS came to get more details about joining the project. And some prospective customers came to get to know us and ask questions.

Sadly, the tragic loss of Abraham shook DebConf, both individually and structurally. The meetup got rescheduled to a small room without video coverage. With that, we still had a wholesome interaction and here’s a quick picture from the meetup taken by Utkarsh (which is also why he’s missing!).

Debusine, by Raphaël Hertzog, et al.

Freexian has been investing into debusine for a while, but development speed is about to increase dramatically thanks to funding from SovereignTechFund.de. Raphaël laid out the 5 milestones of the funding contract, and filed the issues for the first milestone. Together with Enrico and Stefano, they established a workflow for the expanded team.

Among the first steps of this milestone, Enrico started to work on a developer-friendly description of debusine that we can use when we reach out to the many Debian contributors that we will have to interact with. And Raphaël started the design work of the autopkgtest and lintian tasks, i.e. what’s the interface to schedule such tasks, what behavior and what associated options do we support?

At this point you might wonder what debusine is supposed to be… let us try to answer this: Debusine manages scheduling and distribution of Debian-related build and QA tasks to a network of worker machines. It also manages the resulting artifacts and provides the results in an easy to consume way.

We want to make it easy for Debian contributors to leverage all the great QA tools that Debian provides. We want to build the next generation of Debian’s build infrastructure, one that will continue to reliably do what it already does, but that will also enable distribution-wide experiments, custom package repositories and custom workflows with advanced package reviews.

If this all sounds interesting to you, don’t hesitate to watch the project on salsa.debian.org and to contribute.

lpr/lpd in Debian, by Thorsten Alteholz

During Debconf23, Till Kamppeter presented CPDB (Common Print Dialog Backend), a new way to handle print queues. After this talk it was discussed whether the old lpr/lpd based printing system could be abandoned in Debian or whether there is still demand for it.

So Thorsten asked on the debian-devel email list whether anybody uses it. Oddly enough, these old packages are still useful:

• Within a small network it is easier to distribute a printcap file, than to properly configure cups clients.
• One of the biggest manufacturers of WLAN router and DSL boxes only supports raw queues when attaching an USB printer to their hardware. Admittedly the CPDB still has problems with such raw queues.
• The Pharos printing system at MIT is still lpd-based.

As a result, the lpr/lpd stuff is not yet ready to be abandoned and Thorsten will adopt the relevant packages (or rather move them under the umbrella of the debian-printing team). Though it is not planned to develop new features, those packages should at least have a maintainer. This month Thorsten adopted rlpr, an utility for lpd printing without using /etc/printcap. The next one he is working on is lprng, a lpr/lpd printer spooling system. If you know of any other package that is also needed and still maintained by the QA team, please tell Thorsten.

/usr-merge, by Helmut Grohne

Discussion about lifting the file move moratorium has been initiated with the CTTE and the release team. A formal lift is dependent on updating debootstrap in older suites though. A significant number of packages can automatically move their systemd unit files if dh_installsystemd and systemd.pc change their installation targets. Unfortunately, doing so makes some packages FTBFS and therefore patches have been filed. The analysis tool, dumat, has been enhanced to better understand which upgrade scenarios are considered supported to reduce false positive bug filings and gained a mode for local operation on a .changes file meant for inclusion in salsa-ci. The filing of bugs from dumat is still manual to improve the quality of reports.

Since September, the moratorium has been lifted.

Miscellaneous contributions

• Raphaël updated Django’s backport in bullseye-backports to match the latest security release that was published in bookworm. Tracker.debian.org is still using that backport.
• Helmut Grohne sent 13 patches for cross build failures.
• Helmut Grohne performed a maintenance upload of debvm enabling its use in autopkgtests.
• Helmut Grohne wrote an API-compatible reimplementation of autopkgtest-build-qemu. It is powered by mmdebstrap, therefore unprivileged, EFI-only and will soon be included in mmdebstrap.
• Santiago continued the work regarding how to make it easier to (automatically) test reverse dependencies. An example of the ongoing work was presented during the Salsa CI BoF at DebConf 23.
  In fact, omniorb-dfsg test pipelines as the above were used for the omniorb-dfsg 4.3.0 transition, verifying how the reverse dependencies (tango, pytango and omnievents) were built and how their autopkgtest jobs run with the to-be-uploaded omniorb-dfsg new release.
• Utkarsh and Stefano attended and helped run DebConf 23. Also continued winding up DebConf 22 accounting.
• Anton Gladky did some science team uploads to fix RC bugs.

Review: The Cassini Division, by Ken MacLeod

Series: Fall Revolution #3 Publisher: Tor Copyright: 1998 Printing: August 2000 ISBN: 0-8125-6858-3 Format: Mass market Pages: 305

The Cassini Division is the third book in the Fall Revolution series and a fairly direct sequel (albeit with different protagonists) to The Stone Canal. This is not a good place to start the series.

It's impossible to talk about the plot of this book without discussing the future history of this series, which arguably includes some spoilers for The Star Fraction and The Stone Canal. I don't think the direction of history matters that much in enjoying the previous books, but read the first two books of the series before this review if you want to avoid all spoilers.

When the Outwarders uploaded themselves and went fast, they did a lot of strange things: an interstellar probe contrary to all known laws of physics, the disassembly of Ganymede, and the Malley Mile, which plays a significant role in The Stone Canal. They also crashed the Earth.

This was not entirely their fault. There were a lot of politics, religious fundamentalism, and plagues in play as well. But the storm of viruses broadcast from their transformed Jupiter shut down essentially all computing equipment on Earth, which set off much of the chaos. The results were catastrophic, and also politically transformative. Now, the Solar Union is a nearly unified anarchosocialist society, with only scattered enclaves of non-cooperators left outside that structure.

Ellen May Ngewthu is a leader of the Cassini Division, the bulwark that stands between humans and the Outwarders. The Division ruthlessly destroys any remnant or probe that dares rise out of Jupiter's atmosphere, ensuring that the Outwarders, whatever they have become after untold generations of fast evolution, stay isolated to the one planet they have absorbed. The Division is very good at what they do. But there is a potential gap in that line of defense: there are fast folk in storage at the other end of the Malley Mile, on New Mars, and who knows what the deranged capitalists there will do or what forces they might unleash.

The one person who knows a path through the Malley Mile isn't talking, so Ellen goes in search of the next best thing: the non-cooperator scientist Isambard Kingdom Malley.

I am now thoroughly annoyed at how politics are handled in this series, and much less confused by the frequency with which MacLeod won Prometheus Awards from the Libertarian Futurist Society. Some of this is my own fault for having too high of hopes for political SF, but nothing in this series so far has convinced me that MacLeod is seriously engaging with political systems. Instead, the world-building to date makes the classic libertarian mistake of thinking societies will happily abandon stability and predictability in favor of their strange definition of freedom.

The Solar Union is based on what Ellen calls the true knowledge, which is worth quoting in full so that you know what kind of politics we're talking about:

Life is a process of breaking down and using other matter, and if need be, other life. Therefore, life is aggression, and successful life is successful aggression. Life is the scum of matter, and people are the scum of life. There is nothing but matter, forces, space and time, which together make power. Nothing matters, except what matters to you. Might makes right, and power makes freedom. You are free to do whatever is in your power, and if you want to survive and thrive you had better do whatever is in your interests. If your interests conflict with those of others, let the others pit their power against yours, everyone for theirselves. If your interests coincide with those of others, let them work together with you, and against the rest. We are what we eat, and we eat everything.

All that you really value, and the goodness and truth and beauty of life, have their roots in this apparently barren soil.

This is the true knowledge.

We had founded our idealism on the most nihilistic implications of science, our socialism on crass self-interest, our peace on our capacity for mutual destruction, and our liberty on determinism. We had replaced morality with convention, bravery with safety, frugality with plenty, philosophy with science, stoicism with anaesthetics and piety with immortality. The universal acid of the true knowledge had burned away a world of words, and exposed a universe of things.

Things we could use.

This is certainly something that some people will believe, particularly cynical college students who love political theory, feeling smarter than other people, and calling their pet theories things like "the true knowledge." It is not even remotely believable as the governing philosophy of a solar confederation. The point of government for the average person in human society is to create and enforce predictable mutual rules that one can use as a basis for planning and habits, allowing you to not think about politics all the time. People who adore thinking about politics have great difficulty understanding how important it is to everyone else to have ignorable government.

Constantly testing your power against other coalitions is a sport, not a governing philosophy. Given the implication that this testing is through violence or the threat of violence, it beggars belief that any large number of people would tolerate that type of instability for an extended period of time.

Ellen is fully committed to the true knowledge. MacLeod likely is not; I don't think this represents the philosophy of the author. But the primary political conflict in this novel famous for being political science fiction is between the above variation of anarchy and an anarchocapitalist society, neither of which are believable as stable political systems for large numbers of people. This is a bit like seeking out a series because you were told it was about a great clash of European monarchies and discovering it was about a fight between Liberland and Sealand. It becomes hard to take the rest of the book seriously.

I do realize that one point of political science fiction is to play with strange political ideas, similar to how science fiction plays with often-implausible science ideas. But those ideas need some contact with human nature. If you're going to tell me that the key to clawing society back from a world-wide catastrophic descent into chaos is to discard literally every social system used to create predictability and order, you had better be describing aliens, because that's not how humans work.

The rest of the book is better. I am untangling a lot of backstory for the above synopsis, which in the book comes in dribs and drabs, but piecing that together is good fun. The plot is far more straightforward than the previous two books on the series: there is a clear enemy, a clear goal, and Ellen goes from point A to point B in a comprehensible way with enough twists to keep it interesting. The core moral conflict of the book is that Ellen is an anti-AI fanatic to the point that she considers anyone other than non-uploaded humans to be an existential threat. MacLeod gives the reader both reasons to believe Ellen is right and reasons to believe she's wrong, which maintains an interesting moral tension.

One thing that MacLeod is very good at is what Bob Shaw called "wee thinky bits." I think my favorite in this book is the computer technology used by the Cassini Division, who have spent a century in close combat with inimical AI capable of infecting any digital computer system with tailored viruses. As a result, their computers are mechanical non-Von-Neumann machines, but mechanical with all the technology of a highly-advanced 24th century civilization with nanometer-scale manufacturing technology. It's a great mental image and a lot of fun to think about.

This is the only science fiction novel that I can think of that has a hard-takeoff singularity that nonetheless is successfully resisted and fought to a stand-still by unmodified humanity. Most writers who were interested in the singularity idea treated it as either a near-total transformation leaving only remnants or as something that had to be stopped before it started. MacLeod realizes that there's no reason to believe a post-singularity form of life would be either uniform in intent or free from its own baffling sudden collapses and reversals, which can be exploited by humans. It makes for a much better story.

The sociology of this book is difficult to swallow, but the characterization is significantly better than the previous books of the series and the plot is much tighter. I was too annoyed by the political science to fully enjoy it, but that may be partly the fault of my expectations coming in. If you like chewy, idea-filled science fiction with a lot of unexplained world-building that you have to puzzle out as you go, you may enjoy this, although unfortunately I think you need to read at least The Stone Canal first. The ending was a bit unsatisfying, but even that includes some neat science fiction ideas.

Followed by The Sky Road, although I understand it is not a straightforward sequel.

Rating: 6 out of 10

KDE Mascot

I have completed the the ‘Big move’! There are still a few lingering MR’s, but I am sure they will be approved so I can merge soon. With the move I was also able to release 23.08.2 for most release service applications. Enjoy!

You can find them all here: https://snapcraft.io/search?q=KDE

I still need to raise a bit more to pay the Internet bill. If you can spare some change please consider a donation.

Thank you!

<script src=”https://liberapay.com/sgmoore/widgets/button.js”></script> <noscript><a href=”https://liberapay.com/sgmoore/donate”><img alt=”Donate using Liberapay” src=”https://liberapay.com/assets/widgets/donate.svg”></a></noscript>

Donate

https://gofund.me/b8b69e54

Review: Wolf Country, by Mar Delaney

Publisher: Kalikoi Copyright: September 2021 ASIN: B09H55TGXK Format: Kindle Pages: 144

Wolf Country is a short lesbian shifter romance by Mar Delaney, a pen name for Layla Lawlor (who is also one of the writers behind the shared pen name Zoe Chant).

Dasha Volkova is a werewolf, a member of a tribe of werewolves who keep to themselves deep in the wilds of Alaska. She's just become an adult and is wandering, curious and exploring, seeing what's in the world outside of her sheltered childhood. A wild chase after a hare, purely for the fun of it, is sufficiently distracting that she doesn't notice the snare before she steps in it going full speed.

Laney Rosen is not a werewolf. She's a landscape painter who lives a quiet and self-contained life in an isolated cabin in the wilderness. She only stumbles across Dasha because she got lost on the snowmobile tracks taking photographs. Laney assumes Dasha is a dog caught in a poacher's trap, and is quite surprised when the pain of getting her out of the snare causes Dasha to shapeshift into a naked woman.

This short book is precisely what it sounds like, which I appreciate in a romance novel. Woman meets wolf and discovers her secret accidentally, woman is of course entirely trustworthy although wolf can't know that, attraction at first sight, they have to pitch a tent in the wilderness and there's only one sleeping bag, etc. Nothing here is going to surprise you, but it's gentle and kind and fulfills the romance contract of a happy ending. It's not particularly steamy; the focus is on the relationship and the mutual attraction rather than on the sex.

The best part of this book is probably the backdrop. Delaney lives in Alaska, and it shows in both the attention to the details of survival and heat and in the landscape descriptions (and the descriptions of Laney's landscapes). Dasha's love of Laney's paintings is one of the most heart-warming parts of the book. Laney has retinitis pigmentosa and is slowly losing her vision, which I thought was handled gracefully and well in the story. It creates real problems and limitations for her, but it also doesn't define her or become central to her character.

Both Dasha and Laney are viewpoint characters and roughly alternate tight third-person viewpoint chapters. There are a few twists: potential parental disapproval on Dasha's part and some real physical danger from the person who set the trap, but most of the story is the two woman getting to know each other and getting past the early hesitancy to name what they're feeling. Laney feels a bit older than Dasha just because she's out on her own and Dasha was homeschooled and very sheltered, but both of them feel very young. This is Dasha's first serious relationship.

Delaney does use the fated lover trope, which seems worth a warning in case you're not in the mood for that. Werewolves apparently know when they've found their fated mate and don't have a lot of choice in the matter. This is a common paranormal and fantasy romance trope that I find disturbing if I think about it too hard. Thankfully, here it's not much of a distraction. Dasha is such an impulsive, think-with-her-heart sort of character that the immediate conclusion that Laney is her fated mate felt in character even without the werewolf lore.

I read this based on a random recommendation from Yoon Ha Lee when I was in the mood for something light and kind and uncomplicated, and I got exactly what I expected and was in the mood for. The writing isn't the best, but the landscape descriptions aren't bad and the characterization is reasonably good if you're in the mood for brightly curious but not particularly wise. Recommended if you're looking for this sort of thing.

Rating: 7 out of 10

Review: A Hat Full of Sky, by Terry Pratchett

Series: Discworld #32 Publisher: HarperTrophy Copyright: 2004 Printing: 2005 ISBN: 0-06-058662-1 Format: Mass market Pages: 407

A Hat Full of Sky is the 32nd Discworld novel and the second Tiffany Aching young adult novel. You should not start here, but you could start with The Wee Free Men. As with that book, some parts of the story carry more weight if you are already familiar with Granny Weatherwax.

Tiffany is a witch, but she needs to be trained. This is normally done by apprenticeship, and in Tiffany's case it seemed wise to give her exposure to more types of witching. Thus, Tiffany, complete with new boots and a going-away present from the still-somewhat-annoying Roland, is off on an apprenticeship to the sensible Miss Level. (The new boots feel wrong and get swapped out for her concealed old boots at the first opportunity.)

Unbeknownst to Tiffany, her precocious experiments with leaving her body as a convenient substitute for a mirror have attracted something very bad, something none of the witches are expecting. The Nac Mac Feegle know a hiver as soon as they feel it, but they have a new kelda now, and she's not sure she wants them racing off after their old kelda.

Terry Pratchett is very good at a lot of things, but I don't think villains are one of his strengths. He manages an occasional memorable one (the Auditors, for example, at least before the whole chocolate thing), but I find most of them a bit boring. The hiver is one of the boring ones. It serves mostly as a concretized metaphor about the temptations of magical power, but those temptations felt so unlike the tendencies of Tiffany's personality that I didn't think the metaphor worked in the story.

The interesting heart of this book to me is the conflict between Tiffany's impatience with nonsense and Miss Level's arguably excessive willingness to help everyone regardless of how demanding they get. There's something deeper in here about female socialization and how that interacts with Pratchett's conception of witches that got me thinking, although I don't think Pratchett landed the point with full force.

Miss Level is clearly a good witch to her village and seems comfortable with how she lives her life, so perhaps they're not taking advantage of her, but she thoroughly slots herself into the helper role. If Tiffany attempted the same role, people would be taking advantage of her, because the role doesn't fit her. And yet, there's a lesson here she needs to learn about seeing other people as people, even if it wouldn't be healthy for her to move all the way to Miss Level's mindset. Tiffany is a precocious kid who is used to being underestimated, and who has reacted by becoming independent and somewhat judgmental. She's also had a taste of real magical power, which creates a risk of her getting too far into her own head. Miss Level is a fount of empathy and understanding for the normal people around her, which Tiffany resists and needed to learn.

I think Granny Weatherwax is too much like Tiffany to teach her that. She also has no patience for fools, but she's older and wiser and knows Tiffany needs a push in that direction. Miss Level isn't a destination, but more of a counterbalance.

That emotional journey, a conclusion that again focuses on the role of witches in questions of life and death, and Tiffany's fascinatingly spiky mutual respect with Granny Weatherwax were the best parts of this book for me. The middle section with the hiver was rather tedious and forgettable, and the Nac Mac Feegle were entertaining but not more than that. It felt like the story went in a few different directions and only some of them worked, in part because the villain intended to tie those pieces together was more of a force of nature than a piece of Tiffany's emotional puzzle. If the hiver had resonated with the darker parts of Tiffany's natural personality, the plot would have worked better. Pratchett was gesturing in that direction, but he never convinced me it was consistent with what we'd already seen of her.

Like a lot of the Discworld novels, the good moments in A Hat Full of Sky are astonishing, but the plot is somewhat forgettable. It's still solidly entertaining, though, and if you enjoyed The Wee Free Men, I think this is slightly better.

Followed by Going Postal in publication order. The next Tiffany Aching novel is Wintersmith.

Rating: 8 out of 10

A while ago, I saw Stefano's portable monitor, and thought it was very useful. Personally, I rent a desk at an office space where I have a 27" Dell monitor; but I do sometimes use my laptop away from that desk, and then I do sometimes miss the external monitor.

So a few weeks before DebConf, I bought me one myself. The one I got is about a mid-range model; there are models that are less than half the price of the one that I bought, and there are models that are more than double its price, too. ASUS has a very wide range of these monitors; the cheapest model that I could find locally is a 720p monitor that only does USB-C and requires power from the connected device, which presumably if I were to connect it to my laptop with no power connected would half its battery life. More expensive models have features such as wifi connectivity and miracast support, builtin batteries, more connection options, and touchscreen fancyness.

While I think some of these features are not worth the money, I do think that a builtin battery has its uses, and that I would want a decent resolution, so I got a FullHD model with builtin battery.

The device comes with a number of useful accessories: a USB-C to USB-C cable for the USB-C connectivity as well as to charge the battery; an HDMI-to-microHDMI cable for HDMI connectivity; a magnetic sleeve that doubles as a back stand; a beefy USB-A charger and USB-A-to-USB-C convertor (yes, I know); and a... pen.

No, really, a pen. You can write with it. Yes, on paper. No, not a stylus. It's really a pen.

Sigh, OK. This one:

OK, believe me now?

Good.

Don't worry, I was as confused about this as you just were when I first found that pen. Why would anyone do that, I thought. So I read the manual. Not something I usually do with new hardware, but here you go.

It turns out that the pen doubles as a kickstand. If you look closely at the picture of the laptop and the monitor above, you may see a little hole at the bottom right of the monitor, just to the right of the power button/LED. The pen fits right there.

Now I don't know what the exact thought process was here, but I imagine it went something like this:

• ASUS wants to make money through selling monitors, but they don't want to spend too much money making them.
• A kickstand is expensive.
• So they choose not to make one, and add a little hole instead where you can put any little stick and make that function as a kickstand.
• They explain in the manual that you can use a pen with the hole as a kickstand. Problem solved, and money saved.

• Some paper pusher up the chain decides that if you mention a pen in the manual, you can't not ship a pen

  • Or perhaps some lawyer tells them that this is illegal to do in some jurisdictions
  • Or perhaps some large customer with a lot of clout is very annoying

• So in a meeting, it is decided that the monitor will have a pen going along with it

• So someone in ASUS then goes through the trouble of either designing and manufacturing a whole set of pens that use the same color scheme as the monitor itself, or just sourcing them from somewhere; and those pens are then branded (cheaply) and shipped with the monitors.

It's an interesting concept, especially given the fact that the magnetic sleeve works very well as a stand. But hey.

Anyway, the monitor is very nice; the battery lives longer than the battery of my laptop usually does, so that's good, and it allows me to have a dual-monitor setup when I'm on the road.

And when I'm at the office? Well, now I have a triple-monitor setup. That works well, too.

KDE Mascot

I have been working around the clock and over the weekend trying to get the transition for snapcraft files in their respective repos. What does this mean for users? Faster releases for Snaps and closer collaboration between snapcrafters and application developers so bugs get resolved much quicker.

Unfortunately, I have 2 days to finish before my internet gets cut off. I did not make enough to pay the bill. Seeing as this is the first time in a year, I am absolutely, positively grateful for all of you and your support over the past year. I know my work is appreciated! I will never be homeless or starve due to my wonderful local community, but the Internet bill is not something we can barter or trade labor for.

I have caught up on my Debian obligations ( so no MIA needed! )

KDE neon is in good hands with Jonathan and Carlos.

So for now, farewell ( I assure you I will be back! )

https://gofund.me/b8b69e54

A week ago I started to migrate my financial planning from a closed source system to a new system based on an open source, self-hosted solution. Main candidate is Firefly III - a relatively simple financial planner with a rather rich feature set and a solid user base and developer support.

Starting it up with a Docker-Compose file was quite easy, following the official documentation. The same Compose file also managed the MySQL database, the importer app and a cron container for regular imports. The separate importer app allows both imports from CSV files and also from external bank account connection services. For whatever weird reason both of those services support exporting data from my regular bank accounts, but not from my credit cards for exactly the same bank. So for those cards I would need to periodically download CVS transaction exports and feed them into the importer.

The combination of the cron container and the importer app allows for both of these functions. To do this you first do the import via the Web UI first and configure all the mappings - configure file and date formats, map account names in the bank output to account names that you added in Firefly, configure what otehr columns mean and what is the mapping of other values, like expense and income accounts. At the end of the process you can download a json file representing all the settings of the import you just did. Putting such a json config file in the input folder of the cron container and telling it to do an import (weekly, for example) would do such import periodically. Putting a credit card CSV file along with a config file for credit card import would also auto-import that.

So far so good. However, when I tried importing exports from MoneyWiz or even when I tried re-creating account history directly from the bank data, I hit a very annoying problem. Transfers. Thing is detecting transfers between the real (asset) accounts that you are managing is really essential. For one those are not real expenses and incomes, so failing to mark them as transfers would show weird income/expense numbers. But if you do detect them as transfers and correctly map the destination account, but fail to match the transations between another you get a double-transaction. This becomes really hard when transactions happen on different dates and have different descriptions. So you get both a +1000€ transaction "Credit card reset" on 14.09.2023 in the credit card account and a -1000$ transaction "Repayment of own credit card" on 24.09.2023 in the main account of the bank. Matching them to recognise that it is just one transfer and not two is ... non-trivial. The best solution I could come up with so far is to always map the "Opposing account name" for such transfers to a virtual "Transfers" asset account. That has the benefit of being actually able to correctly represent transfers that take several days to move between accounts and showing you how much money is still in transit at any point in time.

So after I figured this out, finally the account balances started matching up with reality.

Setting up spending categories required another change - the author of the Firefly III does not like complexity so it does not support nesting categories. Categories can only be in a single, flat list. It is suggested that if you do need to track multiple categories and also their combination, then category groups might help you. I will survive for now by simplifying the categories that I do actually use. Might actually make the reports more usable.

A new feature for me will be the ability to use automation rules to assign transactions to categories based on their contents, like expense accounts of keywords in descriptions.

Setting up regular bills (with matching rules to assign incoming transactions to those bills) is another feature that is very important to me. The feature itself works just fine in Firefly III, but it has two restrictions that the author of the software does not actually want to be changed. For one it can not be used to track prodictable incomes (like salary), presumably because it is only there for bills (subscriptions in v3 UI). And for other, there is nothing in the base software that actually uses the data from bills to look forward. The author does not like to try to predict the future. Which for me is basically the one of two reasons to use this kind of software at all. I want to know - given all manually entered regular and 100% predictable expenses and incomes, what will be the state of my accounts at particular date? It seems that to get at that I will need to write my own oracle script using the rich Firefly III API.

The last question I had for this week was - how will I enter a new cash puchace of potatoes on a farmers market into the system that sits in a private server in my home network? Turns out there are actually multiple Android apps for Firefly III that can be easily used for this using a robust OAuth or shared token authentification. Except the web UI needs to be exposed online for this to work (and ideally protected by HTTPS). Other users have also created Telegram bots that allow using chat messages to create transaction entries. This is a bit harder to use and more narrow scope, but should be easier to setup. Will have to try both apporaches.

But before I really get going on this, I need to fix another thing that I have been postponing for a while: I will need to migrate my Home Assistant installation from a Docker container installation to a Home Assistant OS installation so that I can install Addons, including Firefly III, MySQL and Portainer to have a bit more organised and less hand-knitted home server setup. Let's see how that goes next week :D

Review: A Killing Frost, by Seanan McGuire

Series: October Daye #14 Publisher: DAW Copyright: 2020 ISBN: 0-7564-1253-6 Format: Kindle Pages: 351

A Killing Frost is the 14th book in the October Daye urban fantasy series and a direct plot sequel to the events of The Brightest Fell. You definitely cannot start here.

This review has some relationship spoilers here for things that you would be expecting after the first five or six books, but which you wouldn't know when reading the first few books of the series. If you haven't started the series yet but plan to, consider skipping this review; if you haven't started reading this series, it will probably be meaningless anyway.

Finally, events seem to have slowed, enough trauma has been healed, and Toby is able to seriously consider getting married. However, no sooner is the thought voiced than fae politics injects itself yet again. In order to get married without creating potentially substantial future problems for herself and her family, Toby will have to tie up some loose ends. Since of those loose ends is a price from the Luidaeg that has been haunting her family for decades, this is easier said than done.

The Brightest Fell had a very unsatisfying ending. This, after a two book interlude, is the proper end to that story.

I picked this up when I had a bunch of stressful things going on and I wanted to be entertained without having to do much work as a reader. Once again, this series delivered exactly that. The writing is repetitive and a bit clunky, McGuire hammers the same emotional points into the ground, and one does wonder about Toby's tendency to emulate a half-human battering ram, but every book has me engrossed and turning the pages. Everyone should have at least one book series on the go that offers reliable, low-effort entertainment.

The initial lever that McGuire uses to push Toby into this plot (fae marriage requirements that had never previously been mentioned) felt rather strained and arbitrary, and I spent the first part of the book grumbling a bit about it. However, there is a better reason for this complication that is revealed with time, and which implies some interesting things about how the fae see heroes and how they use them to solve problems. Now I'm wondering if McGuire will explore that some more in later books.

This is the "all is revealed" book about Simon Torquill. As we get later into the series, these "all is revealed" books are coming more frequently. So far, I'm finding the revelations satisfying, which is a lot harder than it looks with a series this long and with this many hidden details. There are a few directions the series is taking that aren't my favorite (the Daoine Sidhe obsession with being the Best Fae is getting a bit boring, for example), but none of them seem egregiously off, and I'm deeply invested in the answers to the remaining questions.

Toby hits a personal record here for not explaining the dangerous things she's doing because people might talk her out of it. It makes for a tense and gripping climax, but wow I felt for her friends and family, and substantial parts of that risk seemed unnecessary. This is pointed out to her in no uncertain terms, and I'm wondering if it will finally stick. Toby's tendency to solve complicated problems by bleeding on them is part of what gives this series its charm, but I wouldn't mind her giving other people more of a chance to come up with better plans.

I did not like this one as well as the previous two books, mostly because I prefer the Luidaeg-centric stories to the Daoine-Sidhe-centric stories, but if you're enjoying the series to this point, this won't be an exception. It's a substantial improvement on The Brightest Fell and did a lot to salvage that story for me, although there are still some aspects of it that need better explanations.

Followed by When Sorrows Come.

As usual, there is a novella included in at least the Kindle edition.

"Shine in Pearl": I was again hoping for more Gillian, but alas. Instead, and breaking with the tendency for the novellas to be side stories unrelated to the main novel, this fleshes out Simon's past and the other primary relationship driving the novel's plot.

It's... fine? The best parts by far are the scenes from Dianda's viewpoint, which are just as refreshingly blunt as Dianda is elsewhere. Neither of the other two characters are favorites of mine, and since the point of the story is to describe the tragedy that is resolved in the plot of the main novel, it's somewhat depressing. Not my favorite of the novellas; not the worst of them. (6)

Rating: 7 out of 10

If you want to test upgrades on virtual machines (running on libvit/qemu/kvm) these are usually the most common steps:

• Clone the virtual machine and test the upgrade.
• Create a snapshot beforehand, do an in-place upgrade and hope everything works. If not, revert the snapshot..
• Combine both methods
• Use LVM or filesystem snapshots (snapper, etc)

As with recent versions, both libvirt and qemu have full support for dirty bitmaps (so called checkpoints). These checkpoints, once existent, will track changes to the block level layer and can be exported via NBD protocol.

Usually one can create these checkpoints using virsh checkpoint-create[-as], with a proper xml description.

Using the pull based model, the following is possible:

• Issue an backup-begin statement and freeze the virtual machines file systems during this process (using qemu-agent) so you get an consistent system state.
• Create an qcow2 image with backing image option that points to the created (readonly) NBD export via unix socket as overlay.
• Use the created overlay image to boot up the instance and test the system upgrade.
• Do so while the virtual machine is operating without any downtime.

The overlay image will only use the disk space for the blocks changed during upgrade: no need to create a full clone which may waste a lot of disk space.

In order to simplify the first step, its possible to use virtnbdbackup for creating the required consistent checkpoint and export its data using a unix domain socket.

Update: As alternative, ive just created a small utility called vircpt to create and export checkpoints.

In my example im using a debian11 virtual machine with qemu guest agent configured:

# virsh list --all Id Name State ------------------------------------------ 1 debian11_default running

Now let virtnbdbackup create an checkpoint, freeze the filesystems during creation and tell libvirt to provide us with a usable NBD server listening on an unix socket:

# virtnbdbackup -d debian11_default -o /tmp/foo -s INFO lib common - printVersion [MainThread]: Version: 1.9.45 Arguments: ./virtnbdbackup -d debian11_default -o /tmp/foo -s [..] INFO root virtnbdbackup - main [MainThread]: Local NBD Endpoint socket: [/var/tmp/virtnbdbackup.5727] INFO root virtnbdbackup - startBackupJob [MainThread]: Starting backup job. INFO fs fs - freeze [MainThread]: Freezed [2] filesystems. INFO fs fs - thaw [MainThread]: Thawed [2] filesystems. INFO root virtnbdbackup - main [MainThread]: Started backup job for debugging, exiting.

We can now use nbdinfo to display some information about the NBD export:

# nbdinfo "nbd+unix:///vda?socket=/var/tmp/virtnbdbackup.5727" protocol: newstyle-fixed without TLS, using structured packets export="vda": export-size: 137438953472 (128G) content: DOS/MBR boot sector uri: nbd+unix:///vda?socket=/var/tmp/virtnbdbackup.5727

And create a backing image that we can use to test an in-place upgrade:

# qemu-img create -F raw -b nbd+unix:///vda?socket=/var/tmp/virtnbdbackup.5727 -f qcow2 upgrade.qcow2

Now we have various ways for booting the image:

• Create another domain config in libvirt which points to this disk image, boot.
• Extract the current qemu command line for the the running domain using virsh domxml-to-native qemu-argv --domain debian11_default and execute it manually after adjusting required parameters.
• Trust for everything to work out in the simplest way and simply boot up the image via:

# qemu-system-x86_64 -hda upgrade.qcow2 -m 2500 --enable-kvm

After performing the required tests within the virtual machine we can simply kill the active NBD “backup job”:

# virtnbdbackup -d debian11_default -o /tmp/foo -k INFO lib common - printVersion [MainThread]: Version: 1.9.45 Arguments: ./virtnbdbackup -d debian11_default -o /tmp/foo -k [..] INFO root virtnbdbackup - main [MainThread]: Stopping backup job

And remove the created qcow image:

# rm -f upgrade.qcow2

Enabling AppArmor on a Debian Linode VPS is not entirely straightforward. Here's what I had to do in order to make it work.

Packages to install

The easy bit was to install a few packages:

apt install grub2 apparmor-profiles-extra apparmor-profiles apparmor

and then adding apparmor=1 security=apparmor to the kernel command line (GRUB_CMDLINE_LINUX) in /etc/default/grub.

Move away from using Linode's kernels

As mentioned in this blog post, I found out that these parameters are ignored by the Linode kernels.

I had to:

1. login to the Linode Manager (i.e. https://cloud.linode.com/linodes/<linode ID>/configurations),
2. click the node relevant node,
3. click "Edit" next to the configuration profile, and
4. change the kernel to "GRUB 2".

Fix grub

Next I found out that grub doesn't actually install itself properly because it can't be installed directly on the virtual drives provided by Linode (KVM). Manually running this hack worked for me:

grub-install --grub-setup=/bin/true /dev/null Unbound + Let's Encrypt fix

Finally, my local Unbound installation stopped working because it couldn't access the Let's Encrypt certificates anymore.

The solution to this was pretty straightforward. All I needed to do was to add the following to /etc/apparmor.d/local/usr.sbin.unbound:

/etc/letsencrypt/archive/** r, /etc/letsencrypt/live/** r,

A trip full of hitchhiking, beautiful places and welcoming locals.

Day 1: Arrival in Kochi

Kochi is a city in the state of Kerala, India. This year’s DebConf was to be held in Kochi from 3rd September to 17th of September, which I was planning to attend. My friend Suresh, who was planning to join, told me that 29th August 2023 will be Onam, a major festival of the state of Kerala. So, we planned a Kerala trip before the DebConf. We booked early morning flights for Kochi from Delhi and reached Kochi on 28th August.

We had booked a hostel named Zostel in Ernakulam. During check-in, they asked me to fill a form which required signing in using a Google account. I told them I don’t have a Google account and I don’t want to create one either. The people at the front desk seemed receptive, so I went ahead with telling them the problems of such a sign-in being mandatory for check-in. Anyways, they only took a photo of my passport and let me check-in without a Google account.

We stayed in a ten room dormitory. The dormitory room was air-conditioned, spacious, clean and beds were also comfortable. There were two bathrooms in the dormitory and they were clean. I noticed that that Zostel was not added in the OpenStreetMap and so, I added it :) . The hostel had a small canteen for tea and snacks, a common sitting area outside the dormitories, which had beds too. There was a separate silent room, suitable for people who want to work.

Dormitory room in Zostel Ernakulam, Kochi. Beds in Zostel Ernakulam, Kochi.

We had lunch at a nearby restaurant and it was hard to find anything vegetarian for me. I bought some freshly made banana chips from the street and they were tasty. As far as I remember, I had a big glass of pineapple juice for lunch. Then I went to the Broadway market and bought some cardamom and cinnamon for home. I also went to a nearby supermarket and bought Matta brown rice for home. I went to a nearby courier shop to send these stuff back home but it was not open (around 5 PM), due to Onam festival. After returning to the Zostel, I overslept till 9 PM and in the meanwhile, Suresh planned with Saidut and Shwetank (who met us during our stay in Zostel) to go to a place in Fort Kochi for dinner. I I suspected I will be disappointed by lack of vegetarian options as they were planning to have fish. I already had a restaurant in mind - Brindhavan restaurant (suggested by Anupa), which was a pure vegetarian restaurant.

To reach there, I got off at Palarivattom metro station and started looking for an auto-rickshaw to get to the restaurant. I didn’t get any for more than 5 minutes. Since that restaurant was not added to the OpenStreetMap, I didn’t even know how far that was and which direction to go to. Then, I saw a Zomato delivery person on a motorcycle and asked him where the restaurant was. It was already 10 PM and the restaurant closes at 10:30. So, I asked him whether he can drop me off. He agreed and dropped me off at that restaurant. It was 4-5 km from that metro station. I tipped him and expressed my gratefulness for the help. He refused to take the tip, but I insisted and he accepted.

I entered the restaurant and it was coming to a close, so many items were not available. I ordered some Kadhai Paneer (only item left) with naan. It tasted fine. Since the next day was Thiruvonam, I asked the restaurant about the Sadya thali menu and prices for the next day. I planned to eat Sadya thali at that restaurant, but my plans got changed later.

Onam sadya menu from Brindhavan restaurant. Day 2: Onam celebrations

Next day, on 29th of August 2023, we had plan to leave for Wayanad. Wayanad is a hill station in Kerala and a famous tourist spot. Praveen suggested to visit Munnar as it is far closer to Kochi than Wayanad (80 km vs 250 km). But I had already visited Munnar in my previous trips, so we chose Wayanad. We had a train late night from Ernakulam Junction (at 23:30 hours) to Kozhikode, which is the nearest railway station from Wayanad. So, we checked out in the morning as we had plans to roam around in Kochi before taking the train.

Zostel was celebrating Onam on that day. To opt-in, we had to pay 400 rupees, which included a Sadya Thali and a mundu. Me and Suresh paid the amount and opted in for the celebrations. Sadya thali had Rice, Sambhar, Rasam, Avial, Banana Chips, Pineapple Pachadi, Pappadam, many types of pickels and chutneys, Pal Ada Payasam and Coconut jaggery Pasam. And, there was water too :). Those payasams were really great and I had one more round of them. Later, I had a lot of variety of payasams during the DebConf.

Sadya lined up for serving Sadya thali served on banana leaf.

So, we hung out in the common room and put our luggage there. We played UNO and had conversations with other travellers in the hostel. I had a fun time there and I still think it is one of the best hostel experiences I had. We made good friends with Saiduth (Telangana) and Shwetank (Uttarakhand). They were already aware about the software like debian, and we had some detailed conversations about the Free Software movement. I remember explaining the difference between the terms “Open Source” and “Free Software”. I also told them about the Streetcomplete app, a beginner friendly app to edit OpenStreetMap. We had dinner at a place nearby (named Palaraam), but again, the vegetarian options were very limited! After dinner, we came back to the Zostel and me and Suresh left for Ernakulam Junction to catch our train Maveli Express (16604).

Day 3: Going to Wayanad

Maveli Express was scheduled to reach Kozhikode at 03:25 (morning). I had set alarms from 03:00 to 03:30, with the gap of 10 minutes. Every time I woke up, I turned off the alarm. Then I woke up and saw train reaching the Kozhikode station and woke up Suresh for deboarding. But then I noticed that the train is actually leaving the station, not arriving! This means we missed our stop. Now we looked at the next stops and whether we can deboard there. I was very sleepy and wanted to take a retiring room at some station before continuing our journey to Wayanad. The next stop was Quilandi and we checked online that it didn’t have a retiring room. So, we skipped this stop. We got off at the next stop named Vadakara and found out no retiring room was available. So, we asked about information regarding bus for Wayanad and they said that there is a bus to Wayanad around 07:00 hours from bus station which was a few kilometres from the railway station.

We took a bus for Kalpetta (in Wayanad) at around 07:00. The destination of the buses were written in Malayalam, which we could not read. Once again, the locals helped us to get on to the bus to Kalpetta. Vadakara is not a big city and it can be hard to find people who know good Hindi or English, unlike Kochi. Despite language issues, I had no problem there in navigation, thanks to locals. I mostly spent time sleeping during the bus journey.

A few hours later, the bus dropped us at Kalpetta. We had a booking at a hostel in Rippon village. It was 16 km from Kalpetta. On the way, we were treated with beautiful views of nature, which was present everywhere in Wayanad. The place was covered with tea gardens and our eyes were treated with beautiful scenery at every corner.

We were treated with such views during the Wayanad trip.

Rippon village was a very quiet place and I liked the calm atmosphere. This place is blessed by nature and has stunning scenery. I found English was more common than Hindi in Wayanad. Locals were very nice and helped me, even if they don’t know my language.

A road in Rippon.

After catching some sleep at the hostel, I went out in the afternoon. I hitchhiked to reach the main road from the hostel. I bought more spices from a nearby shop and realized that I should have waited for my visit to Wayanad to buy cardamom, which I already bought from Kochi. Then, I was looking for post office to send spices home. The people at the spices shop told me that the nearby Rippon post office was closed by that time, but the post office at Meppadi was open, which was 5 km from there.

I went to Meppadi and saw the post office closes at 15:00, but I reached five minutes late. My packing was not very good and they asked me to pack it tighter. There was a shop near the post office and the people there gave me a cardboard and tapes, and helped pack my stuff for the post. By the time I went to the post office again, it was 15:30. But they accepted my parcel for post.

Day 4: Kanthanpara Falls, Zostel Wayanad and Karapuzha Dam

Kanthanpara waterfalls were 2 km from the hostel. I hitchhiked to the place from the hostel on a scooty. Entry ticket was worth Rs 40. There were good views inside and nothing much to see except the waterfalls.

Entry to Kanthanpara Falls. Kanthanpara Falls.

We had a booking at Zostel Wayanad for this day and so we shifted there. Again, as with their Ernakulam branch, they asked me to fill a form which required signing in using Google, but when I said I don’t have a Google account they checked me in without that. There were tea gardens inside the Zostel boundaries and the property was beautiful.

A view of Zostel Wayanad. A map of Wayanad showing tourist places. A view from inside the Zostel Wayanad property.

Later in the evening, I went to Karapuzha Dam. I witnessed a beautiful sunset during the journey. Karapuzha dam had many activites, like ziplining, and was nice to roam around.

Chembra Peak is near to the Zostel Wayanad. So, I was planning to trek to the heart shaped lake. It was suggested by Praveen and looking online, this trek seemed worth doing. There was an issue however. The charges for trek were Rs 1770 for upto five people. So, if I go alone I will have to spend Rs 1770 for the trek. If I go with another person, we split Rs 1770 into two, and so on. The optimal way to do it is to go in a group of five (you included :D). I asked front desk at Zostel if they can connect me with people going to Chembra peak the next day, and they told me about a group of four people planning to go to Chembra peak the next day. I got lucky! All four of them were from Kerala and worked in Qatar.

Day 5: Chembra peak trek

The date was 1st September 2023. I woke up early (05:30 in the morning) for the Chembra peak trek. I had bought hiking shoes especially for trekking, which turned out to be a very good idea. The ticket counter opens at 07:00. The group of four with which I planned to trek met me around 06:00 in the Zostel. We went to the ticket counter around 06:30. We had breakfast at shops selling Maggi noodles and bread omlette near the ticket counter.

It was a hot day and the trek was difficult for an inexperienced person like me. The scenery was green and beautiful throughout.

Terrain during trekking towards the Chembra peak. Heart-shaped lake at the Chembra peak. Me at the heart-shaped lake. Views from the top of the Chembra peak. View of another peak from the heart-shaped lake.

While returning from the trek, I found out a shop selling bamboo rice, which I bought and will make bamboo rice payasam out of it at home (I have some coconut milk from Kerala too ;)). We returned to Zostel in the afternoon. I had muscle pain after the trek and it has still not completely disappeared.

At night, we took a bus from Kalpetta to Kozhikode in order to return to Kochi.

Day 6: Return to Kochi

At midnight of 2nd of September, we reached Kozhikode bus stand. Then we roamed around for something to eat. I didn’t find anything vegetarian to eat. No surprises there! Then we went to Kozhikode railway station and looked for retiring rooms, but no luck there. We waited at the station and took the next train to Kochi at 03:30 and reached Ernakulam Junction at 07:30 (half hours before train’s scheduled time!). From there, we went to Zostel Fort Kochi and stayed one night there and checked out next morning.

Day 7: Roaming around in Fort Kochi

On 3rd of September, we roamed around in Fort Kochi. We visited the usual places - St Francis Church, Dutch Palace, Jew Town, Pardesi Synagogue. I also visited some homestays and the owners were very happy to show their place even when I made it clear that I was not looking for a stay. In the evening, we went to Kakkanad to attend DebConf.

The story continues in my DebConf23 blog post.

It’s that time of year already! We have hit our first freeze of the year. While the kitties keep warm by the wood burning stove, I have been busy with many updates and fixes in a variety of projects.

KDE neon:

It’s true, Neon unstable has been very unstable. Due to a few factors including a builder being out of space, timed with a new Qt release. There is a cost with living in unstable land with bleeding edge releases. It takes time and finesse to get everything happy, especially with major transitions such as Qt. The drive issue was just bad timing. We worked night and day ( quite literally with people spanning from the US, Europe and Australia ) to get everything happy again. I know it’s frustrating when things are broken, but please keep in mind, most of us are volunteers. I am happy to report, it is once again stable. If you continue to experience issues please report them on https://bugs.kde.org there have been a few cases where there were rogue apt sources lists creating issues. We also have the User edition which is much more stable!

KDE Snaps:

The big move to snapcraft files per repo continues. With that comes a new version 23.08.2. This big win this week was Audiotube! I have finally got this snap working. With a combination of snappy-debug and snap run –gdb audiotube I was able to find all the hidden dependencies such as yt-dlp needed to be built with ffmpeg support and it needed a newer ytmusicapi as the version it called for was broken with gettext translations. I also had to fix the dbus name as it was not the standard org.kde.app. The final fix was it required the alsa plug and layouts adjusted to point to the snap alsa libraries ( which fixed the very important sound feature ). Who says you can’t teach an old dog new tricks. Unfortunately, it still requires –devmode to run, as it has one last network issue even with all the network plugs. I have to set it aside for now, as I have many more snaps to migrate. However, if you want to enjoy youtube music with this super awesome app you can, just append –devmode when installing. Enjoy!

The following apps have now migrated to their respective KDE repos and have the snap recipes in launchpad for automated builds:

• Blinken
• Bovo
• Calindori
• Dragon
• Dolphin ( still needs work )
• Digikam ( still needs work )
• Elisa ( Working on new qml issue )
• Falkon
• Filelight
• GCompris
• Granatier
• Ghostwriter
• Gwenview ( working on missing dependency )
• Haruna ( still needs work )
• isoimagewriter ( working on gpg support )
• Itinerary
• Juk
• K3b ( still needs work )

A new content pack with the latest Frameworks 5.110 and Qt 5.15.11 is complete and the neon extension update will follow after the required global autoconnect is approved from the store.

Debian:

I have caught up on my dashboard with new releases, fixed test failures, and FTBFS on the more obscure arches. The following debian packages have been uploaded to unstable:

descriptionumbrellosquashfusegolang-github-muesli-mangogolang-github-muesli-roffspeechpy-fastlingua-franca

If you have made it this far, thank you! As you can see I am quite busy and there is still much to do. If you can possibly spare a donation so I can continue my efforts in KDE neon / KDE Snaps / and Debian, it would be so appreciated. I enjoy doing this work and I hope it benefits someone out there. Have a lovely day and thanks for stopping by.

Donate

https://gofund.me/b8b69e54

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

* If the equivalent of `file -i` returns text/plain, fallback to comparing this file as a text file. This especially helps when file(1) miscategorises text files as some esoteric type. (Closes: Debian:#1053668) * Update copyright years.

You find out more by visiting the project homepage.

My previously mentioned C.H.I.P. repurposing has been partly successful; I’ve found a use for it (which I still need to write up), but unfortunately it’s too useful and the fact it’s still a bit flaky has become a problem. I spent a while trying to isolate exactly what the problem is (I’m still seeing occasional hard hangs with no obvious debug output in the logs or on the serial console), then realised I should just buy one of the cheap ARM SBC boards currently available.

The C.H.I.P. is based on an Allwinner R8, which is a single ARM v7 core (an A8). So it’s fairly low power by today’s standards and it seemed pretty much any board would probably do. I considered a Pi 2 Zero, but couldn’t be bothered trying to find one in stock at a reasonable price (I’ve had one on backorder from CPC since May 2022, and yes, I know other places have had them in stock since but I don’t need one enough to chase and I’m now mostly curious about whether it will ever ship). As the title of this post gives away, I settled on a Banana Pi BPI-M2 Zero, which is based on an Allwinner H3. That’s a quad-core ARM v7 (an A7), so a bit more oompfh than the C.H.I.P. All in all it set me back £25, including a set of heatsinks that form a case around it.

I started with the vendor provided Debian SD card image, which is based on Debian 9 (stretch) and so somewhat old. I was able to dist-upgrade my way through buster and bullseye, and end up on bookworm. I then discovered the bookworm 6.1 kernel worked just fine out of the box, and even included a suitable DTB. Which got me thinking about whether I could do a completely fresh Debian install with minimal tweaking.

First thing, a boot loader. The Allwinner chips are nice in that they’ll boot off SD, so I just needed a suitable u-boot image. Rather than go with the vendor image I had a look at mainline and discovered it had support! So let’s build a clean image:

noodles@buildhost:~$ mkdir ~/BPI noodles@buildhost:~$ cd ~/BPI noodles@buildhost:~/BPI$ ls noodles@buildhost:~/BPI$ git clone https://source.denx.de/u-boot/u-boot.git Cloning into 'u-boot'... remote: Enumerating objects: 935825, done. remote: Counting objects: 100% (5777/5777), done. remote: Compressing objects: 100% (1967/1967), done. remote: Total 935825 (delta 3799), reused 5716 (delta 3769), pack-reused 930048 Receiving objects: 100% (935825/935825), 186.15 MiB | 2.21 MiB/s, done. Resolving deltas: 100% (785671/785671), done. noodles@buildhost:~/BPI$ mkdir u-boot-build noodles@buildhost:~/BPI$ cd u-boot noodles@buildhost:~/BPI/u-boot$ git checkout v2023.07.02 ... HEAD is now at 83cdab8b2c Prepare v2023.07.02 noodles@buildhost:~/BPI/u-boot$ make O=../u-boot-build bananapi_m2_zero_defconfig HOSTCC scripts/basic/fixdep GEN Makefile HOSTCC scripts/kconfig/conf.o YACC scripts/kconfig/zconf.tab.c LEX scripts/kconfig/zconf.lex.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf # # configuration written to .config # make[1]: Leaving directory '/home/noodles/BPI/u-boot-build' noodles@buildhost:~/BPI/u-boot$ cd ../u-boot-build/ noodles@buildhost:~/BPI/u-boot-build$ make CROSS_COMPILE=arm-linux-gnueabihf- GEN Makefile scripts/kconfig/conf --syncconfig Kconfig ... LD spl/u-boot-spl OBJCOPY spl/u-boot-spl-nodtb.bin COPY spl/u-boot-spl.bin SYM spl/u-boot-spl.sym MKIMAGE spl/sunxi-spl.bin MKIMAGE u-boot.img COPY u-boot.dtb MKIMAGE u-boot-dtb.img BINMAN .binman_stamp OFCHK .config noodles@buildhost:~/BPI/u-boot-build$ ls -l u-boot-sunxi-with-spl.bin -rw-r--r-- 1 noodles noodles 494900 Aug 8 08:06 u-boot-sunxi-with-spl.bin

I had the advantage here of already having a host setup to cross build armhf binaries, but this was all done on a Debian bookworm host with packages from main. I’ve put my build up here in case it’s useful to someone - everything else below can be done on a normal x86_64 host.

Next I needed a Debian installer. I went for the netboot variant - although I was writing it to SD rather than TFTP booting I wanted as much as possible to come over the network.

noodles@buildhost:~/BPI$ wget https://deb.debian.org/debian/dists/bookworm/main/installer-armhf/20230607%2Bdeb12u1/images/netboot/netboot.tar.gz ... 2023-08-08 10:15:03 (34.5 MB/s) - ‘netboot.tar.gz’ saved [37851404/37851404] noodles@buildhost:~/BPI$ tar -axf netboot.tar.gz

Then I took a suitable microSD card and set it up with a 500M primary VFAT partition, leaving the rest for Linux proper. I could have got away with a smaller VFAT partition but I’d initially thought I might need to put some more installation files on it.

noodles@buildhost:~/BPI$ sudo fdisk /dev/sdb Welcome to fdisk (util-linux 2.38.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): o Created a new DOS (MBR) disklabel with disk identifier 0x793729b3. Command (m for help): n Partition type p primary (0 primary, 0 extended, 4 free) e extended (container for logical partitions) Select (default p): Using default response p. Partition number (1-4, default 1): First sector (2048-60440575, default 2048): Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-60440575, default 60440575): +500M Created a new partition 1 of type 'Linux' and of size 500 MiB. Command (m for help): t Selected partition 1 Hex code or alias (type L to list all): c Changed type of partition 'Linux' to 'W95 FAT32 (LBA)'. Command (m for help): n Partition type p primary (1 primary, 0 extended, 3 free) e extended (container for logical partitions) Select (default p): Using default response p. Partition number (2-4, default 2): First sector (1026048-60440575, default 1026048): Last sector, +/-sectors or +/-size{K,M,G,T,P} (534528-60440575, default 60440575): Created a new partition 2 of type 'Linux' and of size 28.3 GiB. Command (m for help): w The partition table has been altered. Calling ioctl() to re-read partition table. Syncing disks. $ sudo mkfs -t vfat -n BPI-UBOOT /dev/sdb1 mkfs.fat 4.2 (2021-01-31)

The bootloader image gets written 8k into the SD card (our first partition starts at sector 2048, i.e. 1M into the device, so there’s plenty of space here):

noodles@buildhost:~/BPI$ sudo dd if=u-boot-build/u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1024 seek=8 483+1 records in 483+1 records out 494900 bytes (495 kB, 483 KiB) copied, 0.0282234 s, 17.5 MB/s

Copy the Debian installer files onto the VFAT partition:

noodles@buildhost:~/BPI$ cp -r debian-installer/ /media/noodles/BPI-UBOOT/

Unmount the SD from the build host, pop it into the M2 Zero, boot it up while connected to the serial console, hit a key to stop autoboot and tell it to boot the installer:

U-Boot SPL 2023.07.02 (Aug 08 2023 - 09:05:44 +0100) DRAM: 512 MiB Trying to boot from MMC1 U-Boot 2023.07.02 (Aug 08 2023 - 09:05:44 +0100) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Banana Pi BPI-M2-Zero DRAM: 512 MiB Core: 60 devices, 17 uclasses, devicetree: separate WDT: Not starting watchdog@1c20ca0 MMC: mmc@1c0f000: 0, mmc@1c10000: 1 Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In: serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 => setenv dibase /debian-installer/armhf => fatload mmc 0:1 ${kernel_addr_r} ${dibase}/vmlinuz 5333504 bytes read in 225 ms (22.6 MiB/s) => setenv bootargs "console=ttyS0,115200n8" => fatload mmc 0:1 ${fdt_addr_r} ${dibase}/dtbs/sun8i-h2-plus-bananapi-m2-zero.dtb 25254 bytes read in 7 ms (3.4 MiB/s) => fdt addr ${fdt_addr_r} 0x40000 Working FDT set to 43000000 => fatload mmc 0:1 ${ramdisk_addr_r} ${dibase}/initrd.gz 31693887 bytes read in 1312 ms (23 MiB/s) => bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r} Kernel image @ 0x42000000 [ 0x000000 - 0x516200 ] ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 Working FDT set to 43000000 Loading Ramdisk to 481c6000, end 49fffc3f ... OK Loading Device Tree to 48183000, end 481c5fff ... OK Working FDT set to 48183000 Starting kernel ...

At this point the installer runs and you can do a normal install. Well, except the wifi wasn’t detected, I think because the netinst images don’t include firmware. I spent a bit of time trying to figure out how to include it but ultimately ended up installing over a USB ethernet dongle, which Just Worked and was less faff. Installing firmware-brcm80211 once installation completed allowed the built-in wifi to work fine.

After install you need to configure u-boot to boot without intervention. At the u-boot prompt (i.e. after hitting a key to stop autoboot):

=> setenv bootargs "console=ttyS0,115200n8 root=LABEL=BPI-ROOT ro" => setenv bootcmd 'ext4load mmc 0:2 ${fdt_addr_r} /boot/sun8i-h2-plus-bananapi-m2-zero.dtb ; fdt addr ${fdt_addr_r} 0x40000 ; ext4load mmc 0:2 ${kernel_addr_r} /boot/vmlinuz ; ext4load mmc 0:2 ${ramdisk_addr_r} /boot/initrd.img ; bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}' => saveenv Saving Environment to FAT... OK => reset

This is assuming you have /boot on partition 2 on the SD - I left the first partition as VFAT (that’s where the u-boot environment will be saved) and just used all of the rest as a single ext4 partition. I did have to do an e2label /dev/sdb2 BPI-ROOT to label / appropriately; otherwise I occasionally saw the SD card appear as mmc1 for Linux (I’m guessing due to asynchronous boot order with the wifi). You should now find the device boots without intervention.

The Free Software Foundation Europe and the Software Freedom Conservancy recently released a statement that they would no longer work with Eben Moglen, chairman of the Software Freedom Law Center. Eben was the general counsel for the Free Software Foundation for over 20 years, and was centrally involved in the development of version 3 of the GNU General Public License. He's devoted a great deal of his life to furthering free software.

But, as described in the joint statement, he's also acted abusively towards other members of the free software community. He's acted poorly towards his own staff. In a professional context, he's used graphically violent rhetoric to describe people he dislikes. He's screamed abuse at people attempting to do their job.

And, sadly, none of this comes as a surprise to me. As I wrote in 2017, after it became clear that Eben's opinions diverged sufficiently from the FSF's that he could no longer act as general counsel, he responded by threatening an FSF board member at an FSF-run event (various members of the board were willing to tolerate this, which is what led to me quitting the board). There's over a decade's evidence of Eben engaging in abusive behaviour towards members of the free software community, be they staff, colleagues, or just volunteers trying to make the world a better place.

When we build communities that tolerate abuse, we exclude anyone unwilling to tolerate being abused[1]. Nobody in the free software community should be expected to deal with being screamed at or threatened. Nobody should be afraid that they're about to have their sexuality outed by a former boss.

But of course there are some that will defend Eben based on his past contributions. There were people who were willing to defend Hans Reiser on that basis. We need to be clear that what these people are defending is not free software - it's the right for abusers to abuse. And in the long term, that's bad for free software.

[1] "Why don't people just get better at tolerating abuse?" is a terrible response to this. Why don't abusers stop abusing? There's fewer of them, and it should be easier.

comments

Welcome to the September 2023 report from the Reproducible Builds project

In these reports, we outline the most important things that we have been up to over the past month. As a quick recap, whilst anyone may inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries.

Andreas Herrmann gave a talk at All Systems Go 2023 titled “Fast, correct, reproducible builds with Nix and Bazel”. Quoting from the talk description:

You will be introduced to Google’s open source build system Bazel, and will learn how it provides fast builds, how correctness and reproducibility is relevant, and how Bazel tries to ensure correctness. But, we will also see where Bazel falls short in ensuring correctness and reproducibility. You will [also] learn about the purely functional package manager Nix and how it approaches correctness and build isolation. And we will see where Bazel has an advantage over Nix when it comes to providing fast feedback during development.

Andreas also shows how you can get the best of both worlds and combine Nix and Bazel, too. A video of the talk is available.

diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb fixed compatibility with file(1) version 5.45 […] and updated some documentation […]. In addition, Vagrant Cascadian extended support for GNU Guix […][…] and updated the version in that distribution as well. […].

Yet another reminder that our upcoming Reproducible Builds Summit is set to take place from October 31st — November 2nd 2023 in Hamburg, Germany.

If you haven’t been before, our summits are a unique gathering that brings together attendees from diverse projects, united by a shared vision of advancing the Reproducible Builds effort. During this enriching event, participants will have the opportunity to engage in discussions, establish connections and exchange ideas to drive progress in this vital field.

If you’re interested in joining us this year, please make sure to read the event page, the news item, or the invitation email that Mattia Rizzolo sent out recently, all of which have more details about the event and location.

We are also still looking for sponsors to support the event, so please reach out to the organising team if you are able to help. Also note that PackagingCon 2023 is taking place in Berlin just before our summit.

On the Reproducible Builds website, Greg Chabala updated the JVM-related documentation to update a link to the BUILDSPEC.md file. […] And Fay Stegerman fixed the builds failing because of a YAML syntax error.

Distribution work

In Debian, this month:

• Debian bug #940234 was originally opened in September 2019 by Aurelien Jarno to request that Debian “add a new requirement that repeatedly building the source package in the same environment produces identical .dsc file modulo the GPG signature”. This month, however, Russ Allbery closed the bug due to concerns about the viability of source reproducibility.

• 10 reviews of Debian packages were added, 56 were updated and 68 were removed this month adding to our knowledge about identified issues.

• Bastian Blank posted a mail to a number of Debian mailing lists titled “Upcoming changes to Debian Linux kernel packages”. Under Kernel modules will be signed with an ephemeral key, Bastian wrote: “Yes, this will make the build unreproducible, but no better solution currently exists.”

• Vagrant Cascadian posted about various experiments with verification builds for Debian and snapshotting the Debian archive

September saw F-Droid add ten new reproducible apps, and one existing app switched to reproducible builds. In addition, two reproducible apps were archived and one was disabled for a current total of 199 apps published with Reproducible Builds and using the upstream developer’s signature. […] In addition, an extensive blog post was posted on f-droid.org titled “Reproducible builds, signing keys, and binary repos”.

Upstream patches

The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:

• openSUSE monthly

• Bernhard M. Wiedemann:

  • linuxsampler (benchmarking issue)
  • antlr3 (date)
  • rpm (embeds too many build details)
  • seamonkey (date)
  • conky (date and ordering-related issue)
  • lsp-plugins-shared (date/copyright year issue)
  • build-compare
  • helix (ASLR-related non-determinism)
  • intel-graphics-compiler (ASLR)

• Chris Lamb:

  • #1052950 filed against sphinxcontrib-mermaid.
  • #1052970 filed against mkdocs-material.
  • #1052989 filed against apophenia.
  • #1053205 filed against lapackpp.
  • #1053263 filed against blaspp.

• Fridrich Strba applied 124 Java-related patches into openSUSE:

  • mysql-connector-java, java-21-openjdk, apache-ivy, maven-assembly-plugin, eclipse, antlr3, groovy18, hbci4java, ini4j, hppc, checkstyle, glassfish-jaxb, tycho, xmvn, mockito, languagetool, json-lib, jnr-unixsocket, jnr-ffi, jnr-enxio, jboss-jaxrs-2.0-api, istack-commons, rxtx-java, glassfish-jaxb, glassfish-hk2, findbugs, docker-client-java, maven, xmvn-connector-ivy, xmlstreambuffer, checkstyle, cglib, bean-validation-api, aws-sdk-java, javapackages-tools, ant, scala, osgi-service-log, jmdns, xml-security, super-csv, osgi-service-jdbc, msv, junit5, jsr-311, jersey, itextpdf, httpcomponents-asyncclient, ed25519-java, jnacl, javaparser, picocli, freemarker, extra166y, javaparser, xstream, woodstox-core, uom-lib, unit-api, uncommons-maths, tycho, treelayout, tiger-types, super-csv, stax-ex, stax2-api, sqlite-jdbc, reflectasm, prometheus-simpleclient-java, powermock, paranamer, opennlp, netty3, mybatis, morfologik-stemming, minlog, maven-archetype, mariadb-java-client, logback, kryo, jsonp, jopt-simple, jnr-posix, jnr-constants, jnr-a64asm, jfreechart, jffi, jetty-schemas, jetty-minimal, jeromq, jctools, jcsp, jboss-websocket-1.0-api, jboss-marshalling, jboss-logmanager, jboss-logging, javaewah, jatl, janino, jackson-modules-base, jackson-jaxrs-providers, jackson-datatypes-collections, jackson-dataformat-xml, jackson-dataformats-text, jackson-dataformats-binary, indriya, google-gson, glassfish-websocket-api, glassfish-transaction-api, glassfish-jsp, glassfish-jax-rs-api, glassfish-hk2, glassfish-fastinfoset, felix-scr, felix-gogo-shell, felix-gogo-command, disruptor, apache-commons-ognl, apache-commons-math, apache-commons-csv, antlr4, jettison, sisu, maven

• Pol Dellaiera:

  • Since version 2.6.4, Composer (the PHP package manager) is now fully reproducible. See the work in the corresponding PR.

Testing framework

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

• Disable armhf and i386 builds due to Debian bug #1052257. […][…][…][…]
• Run diffoscope with a lower ionice priority. […]
• Log every build in a simple text file […] and create persistent stamp files when running diffoscope to ease debugging […].
• Run schedulers one hour after dinstall again. […]
• Temporarily use diffoscope from the host, and not from a schroot running the tested suite. […][…]
• Fail the diffoscope distribution test if the diffoscope version cannot be determined. […]
• Fix a spelling error in the ‘email to IRC’ gateway. […]
• Force (and document) the reconfiguration of all jobs, due to the recent rise of zombies. […][…][…][…]
• Deal with a rare condition when killing processes which should not be there. […]
• Install the Debian backports kernel in an attempt to address Debian bug #1052257. […][…]

In addition, Mattia Rizzolo fixed a call to diffoscope --version (as suggested by Fay Stegerman on our mailing list) […], worked on an openQA credential issue […] and also made some changes to the machine-readable reproducible metadata, reproducible-tracker.json […]. Lastly, Roland Clobus added instructions for manual configuration of the openQA secrets […].

If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

• IRC: #reproducible-builds on irc.oftc.net.

• Mailing list: rb-general@lists.reproducible-builds.org

• Mastodon: @reproducible_builds

• Twitter: @ReproBuilds

Like each month, have a look at the work funded by Freexian’s Debian LTS offering.

Debian LTS contributors

In September, 21 contributors have been paid to work on Debian LTS, their reports are available:

• Abhijith PA did 10.0h (out of 0h assigned and 14.0h from previous period), thus carrying over 4.0h to the next month.
• Adrian Bunk did 7.0h (out of 17.0h assigned), thus carrying over 10.0h to the next month.
• Anton Gladky did 9.5h (out of 7.5h assigned and 7.5h from previous period), thus carrying over 5.5h to the next month.
• Bastien Roucariès did 16.0h (out of 15.5h assigned and 1.5h from previous period), thus carrying over 1.0h to the next month.
• Ben Hutchings did 17.0h (out of 17.0h assigned).
• Chris Lamb did 17.0h (out of 17.0h assigned).
• Emilio Pozuelo Monfort did 30.0h (out of 30.0h assigned).
• Guilhem Moulin did 18.25h (out of 18.25h assigned).
• Helmut Grohne did 10.0h (out of 10.0h assigned).
• Lee Garrett did 17.0h (out of 16.5h assigned and 0.5h from previous period).
• Markus Koschany did 40.0h (out of 40.0h assigned).
• Ola Lundqvist did 4.5h (out of 0h assigned and 24.0h from previous period), thus carrying over 19.5h to the next month.
• Roberto C. Sánchez did 5.0h (out of 12.0h assigned), thus carrying over 7.0h to the next month.
• Santiago Ruano Rincón did 7.75h (out of 16.0h assigned), thus carrying over 8.25h to the next month.
• Sean Whitton did 7.0h (out of 7.0h assigned).
• Sylvain Beucler did 10.5h (out of 17.0h assigned), thus carrying over 6.5h to the next month.
• Thorsten Alteholz did 14.0h (out of 14.0h assigned).
• Tobias Frost did 13.25h (out of 16.0h assigned), thus carrying over 2.75h to the next month.

Evolution of the situation

In September, we have released 44 DLAs.

The month of September was a busy month for the LTS Team.

A notable security issue fixed in September was the high-severity CVE-2023-4863, a heap buffer overflow that allowed remote attackers to perform an out-of-bounds memory write via a crafted WebP file. This CVE was covered by the three DLAs of different packages: firefox-esr, libwebp and thunderbird. The libwebp backported patch was sent to upstream, who adapted and applied it to the 0.6.1 branch.

It is also worth noting that LTS contributor Markus Koschany included in his work updates to packages in Debian Bullseye and Bookworm, that are under the umbrella of the Security Team: xrdp, jetty9 and mosquitto.

As every month, there was important behind-the-scenes work by the Front Desk staff, who triaged, analyzed and reviewed dozens of vulnerabilities, to decide if they warrant a security update. This is very important work, since we need to trade-off between the frequency of updates and the stability of the LTS release.

Thanks to our sponsors

Sponsors that joined recently are in bold.

• Platinum sponsors:
  • TOSHIBA (for 97 months)
  • Civil Infrastructure Platform (CIP) (for 65 months)
• Gold sponsors:
  • Roche Diagnostics International AG (for 108 months)
  • Linode (for 102 months)
  • Babiel GmbH (for 91 months)
  • Plat’Home (for 91 months)
  • University of Oxford (for 47 months)
  • Deveryware (for 34 months)
  • VyOS Inc (for 29 months)
  • EDF SA (for 18 months)
• Silver sponsors:
  • Domeneshop AS (for 112 months)
  • Nantes Métropole (for 106 months)
  • Univention GmbH (for 98 months)
  • Université Jean Monnet de St Etienne (for 98 months)
  • Ribbon Communications, Inc. (for 92 months)
  • Exonet B.V. (for 82 months)
  • Leibniz Rechenzentrum (for 76 months)
  • CINECA (for 65 months)
  • Ministère de l’Europe et des Affaires Étrangères (for 59 months)
  • Cloudways Ltd (for 49 months)
  • Dinahosting SL (for 47 months)
  • Bauer Xcel Media Deutschland KG (for 41 months)
  • Platform.sh (for 41 months)
  • Moxa Inc. (for 35 months)
  • sipgate GmbH (for 32 months)
  • OVH US LLC (for 30 months)
  • Tilburg University (for 30 months)
  • GSI Helmholtzzentrum für Schwerionenforschung GmbH (for 21 months)
  • Soliton Systems K.K. (for 19 months)
• Bronze sponsors:
  • Evolix (for 113 months)
  • Seznam.cz, a.s. (for 113 months)
  • Linuxhotel GmbH (for 110 months)
  • Intevation GmbH (for 109 months)
  • Daevel SARL (for 108 months)
  • Bitfolk LTD (for 107 months)
  • Megaspace Internet Services GmbH (for 107 months)
  • Greenbone AG (for 106 months)
  • NUMLOG (for 106 months)
  • WinGo AG (for 106 months)
  • Ecole Centrale de Nantes - LHEEA (for 102 months)
  • Entr’ouvert (for 97 months)
  • Adfinis AG (for 94 months)
  • GNI MEDIA (for 89 months)
  • Laboratoire LEGI - UMR 5519 / CNRS (for 89 months)
  • Tesorion (for 89 months)
  • Bearstech (for 80 months)
  • LiHAS (for 80 months)
  • Catalyst IT Ltd (for 75 months)
  • Supagro (for 70 months)
  • Demarcq SAS (for 69 months)
  • Université Grenoble Alpes (for 55 months)
  • TouchWeb SAS (for 47 months)
  • SPiN AG (for 44 months)
  • CoreFiling (for 39 months)
  • Institut des sciences cognitives Marc Jeannerod (for 34 months)
  • Observatoire des Sciences de l’Univers de Grenoble (for 31 months)
  • Tem Innovations GmbH (for 25 months)
  • WordFinder.pro (for 25 months)
  • CNRS DT INSU Résif (for 24 months)
  • Alter Way (for 17 months)
  • Institut Camille Jordan (for 6 months)

Something, something then something else, and it’s been another six months since I last wrote anything. The world is crazy, somehow there’s no time for anything, and yet life move forward, inexorably. (Well, without going into gory side-notes about how evil stops life in various parts of the world.)

As a proof that this blog is not dead, I’ve finally implemented proper per-page keywords support, rather than the hard-coded keywords that were present before. Well, those defaults are still present in all pages that don’t declare keywords, will probably remove them at one point.

Implementing this in Hakyll is not hard, at all, if one semi-regularly writes code. There are a number of examples out there, but what was confusing:

• I haven’t written a bit of Haskell lately
• Hakyll is nice, but quirky, and I always forget how it works (on the Haskell level)

Anyway, after 2 files changed, 23 insertions(+), 8 deletions(-), this page is the first one to have any keywords. And the funny thing, after initially struggling to write a single line of Haskell, the final version of the keywords is something like this:

… where renderKeywords = return . escapeHtml . intercalate "," . map trim . splitAll ","

And I wrote that as is, compiled successfully, and did the right thing from the first try. I only write some Haskell code 2-3 times per year, but man, I love this language.

Until next time, hopefully before 2024 😅

I have just got a PineTime smart watch [1] from Pine64. They cost $US27 each which ended up as $144.63 Australian for three including postage when I ordered on the 16th of September, it’s annoying that you can’t order more than 3 at a time to reduce postage costs.

The Australian online store Kogan has smart watches starting at about $15 [2] with Bluetooth and support for phone notifications so the $48.21 for a PineTime doesn’t compare well on just price and features. The watches Kogan sells start getting into high resolution at around the $25 price and many of them have features like 24*7 heart monitoring that the PineTime lacks (it just measures when you request it). No-one would order a PineTime for being cheap or having lots of features, you order it because you want open hardware that allows you to do things your way. Also the PineTime isn’t going to be orphaned while it’s likely that in a few years most of the cheap watches sold by Kogan etc won’t support the new phones running the latest version of Android.

The screen of the PineTime is 240*240 resolution (about 260dpi) with 64k colors. The screen resolution is lower than some high-end smart watches but higher than most phones and almost all monitors. I doubt that much benefit could be gained from higher resolution. Even on minimum brightness the screen is easy to read on all but the brightest sunny days. The compute capabilities are 4.5MB of flash storage, 64k of RAM, and a 64MHz CPU – this can’t run Linux and nothing like it will run Linux for a long time.

I’ve had the PineTime for 6 days now, I charged it once and it’s now at 55% battery. It looks like it will last close to 2 weeks on a single charge and it’s claimed that a newer firmware will make the battery last longer.

Software

The main Android app for using with the PineTime is GadgetBridge which I installed from the f-droid repository. It had lots of click-through menus for allowing access to various Android features (contacts, bluetooth, draw over foreground, location, and more) but after that it was easy to setup. It was the first bluetooth device I’ve used which had a 6 digit PIN for connecting to a phone.

Initially I used the PineTime with my Huawei Nova 7i [3]. The aim is to eventually have it run from my PinePhonePro but my test of the PinePhonePro didn’t go as well as hoped [4]. Now I’m using it on my Huawei Mate 10 Pro.

It comes with InfiniTime [5] installed as the default firmware, mine had 1.11.0 which is a fairly recent version. I will probably upgrade it soon to get the better power optimisation and weather alerts in the watch face. I don’t have any plans to use different watch firmware and I don’t have any plans to contribute to firmware development – I just can’t hack on every FOSS project around it’s better to do big contributions to a small number of projects.

For people who don’t want the default firmware the Wasp-OS project seems interesting as it’s written in Python [6], I don’t like Python but it’s very popular. Python is particularly popular in ML development, it will be interesting to see if Wasp-OS becomes a preferred platform for smart watches that talk to GPT servers.

Generally the software works well, one annoyance is that when a notification goes away on the phone it remains on the PineTime and has to be manually dismissed. It would be nice if clearing notifications on the phone would clear them on the PineTime too.

The music control works with RocketPlayer on Android, it displays the track name and has options for pause/play and skipping forward and backward one track. Annoyingly the current firmware doesn’t allow configuring the main screens, from the primary screen you swipe down for notifications, right for settings, up for menus, and there’s nothing defined for swipe left. I’d like to make swipe left the command to get to music control.

Hardware

It has a detachable band that appears to be within the common range of watch bands. According to the PineTime Wiki page [7] there are a selection of alternate bands that will fit it, but some don’t because the band is recessed into the watch.

It is IP67 rated which means you can probably wear it while swimming. The charging contacts are exposed on the bottom of the case which means that any chemicals left by pool water can be cleaned off and also as they are apparently not expected to be harmed by sweat and skin oil there shouldn’t be a problem charging it. I have significant experience using a Samsung Galaxy S5 Mini which is rated at IP67 in swimming pools. I had two problems with the S5 Mini when getting out of the pool, firstly water in the headphone socket made the phone consider that it was in headphone mode and turn off the speakers and secondly it took hours to become dry enough to charge and after many swims the charge rate dropped presumably due to oxide on the contacts. There are reports of success when swimming with a PineTime.

Generally it feels well made and appears more solid than the cheapest Kogan devices appear to be.

Conclusion

If I wanted monitoring for medical reasons then I would choose a different smart watch. I’ve read about people doing things like tracking their body stats 24*7 and trying to discover useful things, the PineTime is not a good option for BioHacking type use. However if I did have a need for such things I’d probably just buy a second smart watch and have one on each wrist.

The PineTime generally works well. It’s a pity it has fewer hardware features than closed devices that are cheaper. But having a firmware that can be continually improved by the community is good.

The continually expanding use of mobile phone technology devices for custom use in corporations (such as mobile phone in custom case for scanning prices etc in a supermarket) has some potential for use with this. I can imagine someone adding some custom features to a PineTime for such use. When a supermarket chain has 200,000 employees (as Woolworths in Australia does) then paying for a few months of software development work to make a smart watch do specific things for that company could provide significant value. There are probably some business opportunities for FOSS developers to hack on extra hardware on a PineTime and write software to support it.

I recommend that everyone who’s into FOSS buy one of these. Preferably make a deal with two friends to get the minimum postage cost.

• [1] https://pine64.com/product-category/pinetime-smartwatch/
• [2] https://www.kogan.com/au/shop/category/smart-watches/
• [3] https://etbe.coker.com.au/2022/04/20/android-without-play/
• [4] https://etbe.coker.com.au/2023/10/11/pinephone-status/
• [5] https://wiki.pine64.org/wiki/InfiniTime
• [6] https://wasp-os.readthedocs.io/en/latest/
• [7] https://wiki.pine64.org/wiki/PineTime

Related posts:

1. I Just Ordered a Nexus 6P Last year I wrote a long-term review of Android phones...
2. My Ideal Mobile Phone Based on my experience testing the IBM Seer software on...
3. Big Smart TVs Recently a relative who owned a 50″ Plasma TV asked...