And we're working through quite nicely.
It's been a long, long day so far and we're about 1/2 way through :)
Shout out to Isy, Sledge and RattusRattus in Cambridge and also smcv.Two releases in a day is a whole bunch :)

About a month later than I probably should have posted it, here s a recap of my Free Software activities in 2021. For previous years see 2019 + 2020. Again, this year had fewer contributions than I d like thanks to continuing fatigue about the state of the world, and trying to work on separation between work and leisure while working from home. I ve made some effort to improve that balance but it s still a work in progress.

Conferences No surprise, I didn t attend any in-person conferences in 2021. I find virtual conferences don t do a lot for me (a combination of my not carving time out for them in the same way, because not being at the conference means other things will inevitably intrude, and the lack of the social side) but I did get to attend a few of the DebConf21 talks, which was nice. I m hoping to make it to DebConf22 this year in person.

Debian Most of my contributions to Free software continue to happen within Debian. As part of the Data Protection Team I responded to various inbound queries to that team. Some of this involved chasing up other project teams who had been slow to respond - folks, if you re running a service that stores personal data about people then you need to be responsive to requests about it. Some of this was dealing with what look like automated scraping tools which send no information about the person making the request, and in all the cases we ve seen so far there s been no indication of any data about that person on any systems we have access to. Further team time was wasted dealing with the Princeton-Radboud Study on Privacy Law Implementation (though Matthew did the majority of the work on this). The Debian Keyring was possibly my largest single point of contribution. We re in a roughly 3 month rotation of who handles the keyring updates, and I handled 2021.03.24, 2021.04.09, 2021.06.25, 2021.09.25 + 2021.12.24 For Debian New Members I m mostly inactive as an application manager - we generally seem to have enough available recently. If that changes I ll look at stepping in to help, but I don t see that happening. I continue to be involved in Front Desk, having various conversations throughout the year with the rest of the team, but there s no doubt Mattia and Pierre-Elliott are the real doers at present. I did take part in an NM Committee appeals process. In terms of package uploads I continued to work on gcc-xtensa-lx106, largely doing uploads to deal with updates to the GCC version or packaging (8 + 9). sigrok had a few minor updates, libsigkrok 0.5.2-3, pulseview 0.4.2-3 as well as a new upstream release of sigrok CLI 0.7.2-1. There was a last minute pre-release upload of libserialport 0.1.1-4 thanks to a kernel change in v5.10.37 which removed termiox support. Despite still not writing any VHDL these days I continue to keep an eye on ghdl, because I found it a useful tool in the past. Last year that was just a build fix for LLVM 11.1.0 - 1.0.0+dfsg+5. Andreas Bombe has largely taken over more proactive maintenance, which is nice to see. I uploaded OpenOCD 0.11.0~rc1-2, cleaning up some packaging / dependency issues. This was followed by 0.11.0~rc2-1 as a newer release candidate. Sadly 0.11.0 did not make it in time for bullseye, but rc2 was fairly close and I uploaded 0.11.0-1 once bullseye was released. Finally I did a drive-by upload for garmin-forerunner-tools 0.10repacked-12, cleaning up some packaging issues and uploading it to salsa. My Forerunner 305 has died (after 11 years of sterling service) and the Forerunner 45 I ve replaced it with uses a different set of tools, so I decided it didn t make sense to pick up longer term ownership of the package.

Linux My Linux contributions continued to revolve around pushing MikroTik RB3011 support upstream. There was a minor code change to Set FIFO sizes for ipq806x (which fixed up the allowed MTU for the internal switch + VLANs). The rest was DTS related - adding ADM DMA + NAND definitions now that the ADM driver was merged, adding tsens details, adding USB port info and adding the L2CC and RPM details for IPQ8064. Finally I was able to update the RB3011 DTS to enable NAND + USB. With all those in I m down to 4 local patches against a mainline kernel, all of which are hacks that aren t suitable for submission upstream. 2 are for patching in details of the root device and ethernet MAC addresses, one is dealing with the fact the IPQ8064 has some reserved memory that doesn t play well with AUTO_ZRELADDR (there keeps being efforts to add some support for this via devicetree, but unfortunately it gets shot down every time), and the final one is a hack to turn off the LCD backlight by treating it as an LED (actually supporting the LCD properly is on my TODO list).

Personal projects 2021 didn t see any releases of onak. It s not dead, just resting, but Sequoia PGP is probably where you should be looking for a modern OpenPGP implementation. I continued work on my Desk Viking project, which is an STM32F103 based debug tool inspired by the Bus Pirate. The main addtion was some CCLib support (forking it in the process to move to Python 3 and add some speed ups) to allow me to program my Zigbee dongles, but I also added some 1-Wire search logic and some support for Linux emulation mode with VCD output to allow for a faster development cycle. I really want to try and get OpenOCD JTAG mode supported at some point, and have vague plans for an STM32F4 based version that have suffered from a combination of a silicon shortage and a lack of time. That wraps up 2021. I d like to say I m hoping to make more Free Software contributions this year, but I don t have a concrete plan yet for how that might happen, so I ll have to wait and see.

The following contributors got their Debian Developer accounts in the last two months:

• Douglas Andrew Torrance (dtorrance)
• Mark Lee Garrett (lee)

The following contributors were added as Debian Maintainers in the last two months:

• Lukas Matthias M rdian
• Paulo Roberto Alves de Oliveira
• Sergio Almeida Cipriano Junior
• Julien Lamy
• Kristian Nielsen
• Jeremy Paul Arnold Sowden
• Jussi Tapio Pakkanen
• Marius Gripsgard
• Martin Budaj
• Peymaneh
• Tommi Petteri H yn l nmaa

Congratulations!

We've more or less finished the release of the Debian CD/DVD/Blu-Ray and other media for Bullseye 11.2 release. This is one of the (roughly) quarterly point releases and roll-up releases.Thanks firstly to the developers, users, helpers, bug filers who help to keep Debian moving and working and to the release team and press team who more or less finish their job before the media team start theirs.
Thanks to Sledge and RattusRattus and Isy in Cambridge and to Schweer who single-handedly clears all the Debian-edu testing. This release run seemed to be a bit more slick, a bit faster, a few fewer problems and it's always a joy to work with colleagues who are like family.The last couple of years have been more than a bit difficult: this (should) be more or less the last major action from the release team and others for 2021.I'm going to take the opportunity this gives me to wish all concerned with Debian (and every other Linux) the very best wishes for the year to come. Surely, it can only get better - eventually.

Two weeks ago I decided to make myself a combined birthday and Christmas present and upgrade my coffee gear. I ve got my first espresso machine back in 2013, it was a cheap Saeco Philips Poemia, which made reasonably drinkable coffee, but not being able to make good coffee made me increasingly unhappy about it. However, since it worked, I wasn t motivated enough to change anything until it stopped working. One day the nut holding the shower screen broke, and I couldn t replace it. Having no coffee machine is arguably worse than having a mediocre one, so I started looking for a new one in the budget range. Having spent about two months reading reviews for all sorts of manual espresso machines, I realised the best thing I can probably do for the money I was willing to spend at the time was to buy a second-hand Gaggia Classic. Which is what I did: I paid 260 to a person who apparently decided they prefer to press a button to get their espresso rather than have to prepare it themselves. My first attempts at making espresso weren t very much successful, as my hand grinder couldn t produce the right grind for espresso (without using pressurised baskets), so I quickly upgraded it to the 50 De Longhi electric grinder, which was much better for espresso.

Gaggia Classic 2015 and De Longhi grinder

This setup has worked for me for nearly 4 years, but over the time the Gaggia started malfunctioning. See, this particular Gaggia Classic is the 2015 model, which resulted in the overhaul of the design after Gaggia was acquired by Philips. They replaced the boiler, changed the exterior design a bit, and importantly for me replaced the fully metal group head with the metal and plastic version typically found in cheap espresso machines like my old Poemia.

The Gaggia Classic 2015 group head

The trouble with this one is that the plastic bit (barely seen on the picture, but it s inserted into the notches on the sides of the group head) is that it gets damaged over the time, especially when the portafilter is inserted very tightly. The more damaged it gets, the tigher it is necessary to insert the portafilter to avoid leakage, the more damaged it gets and so on. At one point, the Gaggia was leaking water every time I was making coffee, affecting the quality of the brew and making a mess in the kitchen. I made a mistake and removed the plastic bit only to realise it cannot be purchased separately and nobody knows how to put it back once it s been removed; I ended up paying more than a hundred euro to replace the group head as a whole. Once I ve got the Gaggia back, I became too conscious of the potential damage I can make by overengaging the portafilter, I decided it s probably the time to get a new coffee machine.

Gaggia Classic 2015 vs 2019

The makers of Gaggia listened to the critics and undid the 2015 changes to the Gaggia Classic design, reverting to the previous one and fixing it they basically merged the fixes many of the owners of the old Gaggia did themselves. The group head is now without any plastic, so I don t have to worry that much about damaging it accidentally. A friend pointed out that my grinder is probably not good enough and recommended a couple of models to me; I checked Kev s Coffee Blog and found a grinder, Sage Dose Control Pro, which was available on sale in my local shop for a reasonable price. I ve also got a portafilter holder to make tamping more comfortable I used to tamp against an edge of the sink:

The final setup:

Gaggia Classic 2019 and Sage BCG600 Dose Control Pro

What I learnt from this is that the grinder does indeed make a huge difference. I am now able to consistently produce brews I would only occasionally get with the old De Longhi grinder. There is one downside to the new grinder. Happy with my new purchase, I went to read this review and thought to myself: lucky me, my grinder is absolutely quiet! And then I realised that the noise in my kitchen is not, in fact, produced by the fridge, but the grinder. Well, a cheap switched plug solved the issue completely (I wish sockets here each had a switch like they usually to in the UK!)

Z3 is a theorem prover developed at Microsoft research and available as a dynamically linked C++ library in Debian-based distributions. While the library is a whopping 16 MB, and the solver is a tad slow, it s permissive licensing, and number of tactics offered give it a huge potential for use in solving dependencies in a wide variety of applications. Z3 does not need normalized formulas, but offers higher level abstractions like atmost and atleast and implies, that we will make use of together with boolean variables to translate the dependency problem to a form Z3 understands. In this post, we ll see how we can apply Z3 to the dependency resolution in APT. We ll only discuss the basics here, a future post will explore optimization criteria and recommends.

Translating the universe APT s package universe consists of 3 relevant things: packages (the tuple of name and architecture), versions (basically a .deb), and dependencies between versions. While we could translate our entire universe to Z3 problems, we instead will construct a root set from packages that were manually installed and versions marked for installation, and then build the transitive root set from it by translating all versions reachable from the root set. For each package P in the transitive root set, we create a boolean literal P. We then translate each version P1, P2, and so on. Translating a version means building a boolean literal for it, e.g. P1, and then translating the dependencies as shown below. We now need to create two more clauses to satisfy the basic requirements for debs:

1. If a version is installed, the package is installed; and vice versa. We can encode this requirement for P above as P == atleast( P1,P2 , 1).
2. There can only be one version installed. We add an additional constraint of the form atmost( P1,P2 , 1).

We also encode the requirements of the operation.

1. For each package P that is manually installed, add a constraint P.
2. For each version V that is marked for install, add a constraint V.
3. For each package P that is marked for removal, add a constraint !P.

Dependencies Packages in APT have dependencies of two basic forms: Depends and Conflicts, as well as variations like Breaks (identical to Conflicts in solving terms), and Recommends (soft Depends) - we ll ignore those for now. We ll discuss Conflicts in the next section. Let s take a basic dependency list: A Depends: X Y, Z. To represent that dependency, we expand each name to a list of versions that can satisfy the dependency, for example X1 X2 Y1, Z1. Translating this dependency list to our Z3 solver, we create boolean variables X1,X2,Y1,Z1 and define two rules:

1. A implies atleast( X1,X2,Y1 , 1)
2. A implies atleast( Z1 , 1)

If there actually was nothing that satisfied the Z requirement, we d have added a rule not A. It would be possible to simply not tell Z3 about the version at all as an optimization, but that adds more complexity, and the not A constraint should not cause too many problems.

Conflicts Conflicts cannot have or in them. A dependency B Conflicts: X, Y means that only one of B, X, and Y can be installed. We can directly encode this in Z3 by using the constraint atmost( B,X,Y , 1). This is an optimized encoding of the constraint: We could have encoded each conflict in the form !B or !X, !B or !X, and so on. Usually this leads to worse performance as it introduces additional clauses.

Complete example Let s assume we start with an empty install and want to install the package a below.

Package: a
Version: 1
Depends: c   b
Package: b
Version: 1
Package: b
Version: 2
Conflicts: x
Package: d
Version: 1
Package: x
Version: 1

The translation in Z3 rules looks like this:

1. Package rules for a:
   1. a == atleast( a1 , 1) - package is installed iff one version is
   2. atmost( a1 , 1) - only one version may be installed
   3. a a must be installed
2. Dependency rules for a
   1. implies(a1, atleast( b2, b1 , 1)) the translated dependency above. note that c is gone, it s not reachable.
3. Package rules for b:
   1. b == atleast( b1,b2 , 1) - package is installed iff one version is
   2. atmost( b1, b2 , 1) - only one version may be installed
4. Dependencies for b (= 2):
   1. atmost( b2, x1 , 1) - the conflicts between x and b = 2 above
5. Package rules for x:
   1. x == atleast( x1 , 1) - package is installed iff one version is
   2. atmost( x1 , 1) - only one version may be installed

The package d is not translated, as it is not reachable from the root set a1 , the transitive root set is a1,b1,b2,x1 .

Next iteration: Optimization We have now constructed the basic set of rules that allows us to solve solve our dependency problems (equivalent to SAT), however it might lead to suboptimal solutions where it removes automatically installed packages, or installs more packages than necessary, to name a few examples. In our next iteration, we have to look at introducing optimization; for example, have the minimum number of removals, the minimal number of changed packages, or satisfy as many recommends as possible. We will also look at the upgrade problem (upgrade as many packages as possible), the autoremove problem (remove as many automatically installed packages as possible).

Getting the latest version of a package into Debian involves checking when there are new versions available fortunately (and not surprisingly) Debian has tools to make this simpler. I have recently ran into the problem when an upstream beta version sorts higher than a newer non-beta version. Which is problematic, of course. This is due to Debian sorting something like 1.0b as later than a pure 1.0 version.

gusnan@debian-i7:~ > dpkg --compare-versions 1.0b lt 1.0 && echo true
gusnan@debian-i7:~ > dpkg --compare-versions 1.0b gt 1.0 && echo true
true

But there s a solution name the beta versions something like 1.0~beta. And you don t need to force upstream to make any changes either. You can use uscan and the watch file to make it interpret an upstream 1.0b version as 1.0~beta in Debian. This is done by using a line like

uversionmangle=s/(\d)[\_\.\-\+]?((RC rc pre dev beta alpha b a)\d*)$/$1~$2/;s/\~b/\~beta/;,\

in uversionmangle in your debian/watch file. In this case i have added on the end something to make the ending ~b into ~beta instead. Full version of the watch file available here.

The Motoko programming language has a built-in data type for optional values, named ?t with values null and ?v (for v : t); this is the equivalent of Haskell s Maybe, Ocaml s option or Rust s Option. In this post, I explain how Motoko represents such optional values (almost) without allocation. I neither claim nor expect that any of this is novel; I just hope it s interesting.

Uniform representation The Motoko programming language, designed by Andreas Rossberg and implemented by a pretty cool team at DFINITY is a high-level language with strict semantics and a strong, structural, equi-recursive type system that compiles down to WebAssembly. Because the type system supports polymorphism, it represents all values uniformly. Simplified for the purpose of this blog post, they are always pointers into a heap object where the first word of the heap object, the heap tag, contains information about the value:

 
  tag    
 

The tag is something like array, int64, blob, variant, record, , and it has two purposes:

• The garbage collector uses it to understand what kind of object it is looking at, so that it can move it around and follow pointers therein. Variable size objects such as arrays include the object size in a subsequent word of the heap object.
• Some types have values that may have different shapes on the heap. For example, the ropes used in our text representation can either be a plain blob, or a concatenation node of two blobs. For these types, the tag of the heap object is inspected.

The optional type, naively The optional type (?t) is another example of such a type: Its values can either be null, or ?v for some value v of type t, and the primitive operations on this type are the two introduction forms, an analysis function, and a projection for non-null values:

null : () -> ?t
some : t -> ?t
is_some : ?t -> bool
project : ?t -> t     // must only be used if is_some holds

It is natural to use the heap tag to distinguish the two kind of values:

• The null value is a simple one-word heap object with just a tag that says that this is null:

   
    null  
   

• The other values are represented by a two-word object: The tag some, indicating that it is a ?v, and then the payload, which is the pointer that represents the value v:

   
    some   payload  
   

With this, the four operations can be implemented as follows:

def null():
  ptr <- alloc(1)
  ptr[0] = NULL_TAG
  return ptr
def some(v):
  ptr <- alloc(2)
  ptr[0] = SOME_TAG
  ptr[1] = v
  return ptr
def is_some(p):
  return p[0] == SOME_TAG
def project(p):
  return p[1]

The problem with this implementation is that null() and some(v) both allocate memory. This is bad if they are used very often, and very liberally, and this is the case in Motoko: For example the iterators used for the for (x in e) construct have type

type Iter<T> =   next : () -> ?T  

and would unavoidably allocate a few words on each iteration. Can we avoid this?

Static values It is quite simple to avoid this for for null: Just statically create a single null value and use it every time:

static_null = [NULL_TAG]
def null():
  return static_null

This way, at least null() doesn t allocate. But we gain more: Now every null value is represented by the same pointer, and since the pointer points to static memory, it does not change even with a moving garbage collector, so we can speed up is_some:

def is_some(p):
  return p != static_null

This is not a very surprising change so far, and most compilers out there can and will do at least the static allocation of such singleton constructors. For example, in Haskell, there is only a single empty list ([]) and a single Nothing value in your program, as you can see in my videos exploring the Haskell heap. But can we get rid of the allocation in some(v) too?

Unwrapped optional values If we don t want to allocate in some(v), what can we do? How about simply

def some(v):
  return v

That does not allocate! But it is also broken. At type ??Int, the values null, ?null and ??null are distinct values, but here this breaks. Or, more formally, the following laws should hold for our four primitive operations:

1. is_some(null()) = false
2. v. is_some(some(v)) = true
3. p. project(some(p)) = p

But with the new definition of some, we d get is_some(some(null())) = false. Not good! But note that we only have a problem if we are wrapping a value that is null or some(v). So maybe take the shortcut only then, and write the following:

def some(v):
  if v == static_null   v[0] == SOME_TAG:
    ptr <- alloc(2)
    ptr[0] = SOME_TAG
    ptr[1] = v
    return ptr
  else:
    return v

The definition of is_some can stay as it is: It is still the case that all null values are represented by static_null. But the some values are now no longer all of the same shape, so we have to change project():

def project(p):
  if p[0] == SOME_TAG:
    return p[1]
  else:
    return p

Now things fall into place: A value ?v can, in many cases, be represented the same way as v, and no allocation is needed. Only when v is null or ?null or ??null or ???null etc. we need to use the some heap object, and thus have to allocate. In fact, it doesn t cost much to avoid allocation even for ?null:

static_some_null = [SOME_TAG, static_null]
def some(v):
  if v == static_null:
    return static_some_null
  else if v[0] == SOME_TAG:
    ptr <- alloc(2)
    ptr[0] = SOME_TAG
    ptr[1] = v
    return ptr
  else:
    return v

So unless one nests the ? type two levels deep, there is no allocation whatsoever, and the only cost is a bit more branching in some and project. That wasn t hard, but quite rewarding, as one can now use idioms like the iterator shown above with greater ease.

Examples The following tables shows the representation of various values before and after. Here [ ] is a pointed-to dynamically allocated heap object, a statically allocated heap object, N = NULL_TAG and S = SOME_TAG.

type	value	before	after
Null	null	N	N
?Int	null	N	N
?Int	?23	[S,23]	23
??Int	null	N	N
??Int	?null	[S, N ]	S, N
??Int	??23	[S,[S,23]]	23
???Int	null	N	N
???Int	?null	[S, N ]	S, N
???Int	??null	[S,[S, N ]]	[S, S, N ]
???Int	???23	[S,[S,[S,23]]]	23

Concluding remarks

• If you know what parametric polymorphism is, and wonder how this encoding can work in a language that has that, note that this representation is on the low-level of the untyped run-time value representation: We don t need to know the type of v in some(v), merely its heap representation.
• The uniform representation in Motoko is a bit more involved: The pointers are tagged (by subtracting 1) and some scalar values are represented directly in place (shifted left by 1 bit). But this is luckily orthogonal to what I showed here.
• Could Haskell do this for its Maybe type? Not so easily:
  • The Maybe type is not built-in, but rather a standard library-defined algebraic data type. But the compiler could feasible detect that this is option-like?
  • Haskell is lazy, so at runtime, the type Maybe could be Nothing, or Just v, or, and this is crucial, a yet to be evaluated expression, also called a thunk. And one definitely needs to distinguish between a thunk t :: Maybe a that may evaluate to Nothing, and a value Just t :: Maybe a that definitely is Just, but contains a value, which may be a thunk.
  Something like this may work for a strict Maybe type or unlifted sums like (# (# #) a #), but may clash with other ticks in GHC, such as pointer tagging.
• As I said above, I don t expect this to be novel, and I am happy to add references to prior art here.
• Given that a heap object with tag SOME_TAG now always encodes a tower ? null for n>0, one could try to optimize that even more by just storing the n:

   
    some    n   
   

  But that seems unadvisable: It is only a win if you have deep towers, which is probably rare. Worse, now the project function would have to return such a heap object with n decremented, so now projection might have to allocate, which goes against the cost model expected by the programmer.
• If you rather want to see code than blog posts, feel free to check out Motoko PR #2115.
• Does this kind of stuff excite you? Motoko is open source, so your contributions may be welcome!

Review: Shadow Scale, by Rachel Hartman

Series:	Seraphina #2
Publisher:	Ember
Copyright:	2015
ISBN:	0-375-89659-7
Format:	Kindle
Pages:	458

Shadow Scale, despite confusing publisher marketing that calls it a "companion" to Seraphina, is a direct sequel. It picks up shortly after Seraphina and resolves most of the loose ends of the previous book. This is a book for which my completionist tendencies did me no favors. The book I was intending to read, when I started on Hartman's work, is Tess of the Road, but I hate starting series in the middle and it was clear that Tess was set after Seraphina. (I have been repeatedly assured that this doesn't matter and that one can start with Tess. Such reassurances rarely work on me; do as I say, not as I do.) For Seraphina itself, this turned out fine; I'm mildly surprised by the book's Andre Norton award nomination, but it was enjoyable enough and I liked the first-person protagonist. Shadow Scale I approached with a bit more trepidation. I hadn't heard much about it and the few reviews I saw were lukewarm. Unfortunately, there's a reason for that. Seraphina left obvious room for a sequel, including a brewing war, significant unresolved interpersonal relationships, and Seraphina's own newfound understanding of the nature of her internal menagerie. Alas, the start of the book uses the war primarily as plot device (and introduces a brand-new bit of magic that I never found interesting), largely ignores the relationship, and focuses on that third plot element. And by focuses, I mean Seraphina is sent out of the country of Goredd on a journey of map exploration to collect plot coupons. The best description I have for the middle of this book is tedious and depressing. Like a lot of novels, it has a U-shaped plot: things get worse and worse until a crisis, and then start getting better. This plot can work, but the reader has to have a good reason to stick through the depressing bits. One of the better reasons is if the plot allows the main character some small triumphs, maintaining their agency throughout even if larger events are spiraling out of control. This is not one of those books. After some early successes tracking down some objects of her search, Seraphina encounters an antagonist from her own past (barely hinted at in the first book) who can systematically corrupt everything she is trying to do. She spends most of the book feeling like what she's doing is futile, or hoping for things the reader knows aren't going to happen. Given that this is happening during plodding map exploration fantasy through largely indistinguishable faux-medieval countries, or (later) somewhat more interesting but obviously irrelevant local politics in a remote trading city, it's hard to avoid sharing that sense of futility. The other structural problem with Shadow Scale is that the plot coupons are people, which means this book has an excessive cast size problem. Seraphina collects too many people for me to even keep straight, let alone care about. Critical developments (usually for the worst) in the lives of one of these characters were frequently met with reader mutterings like, "Now which one was Brasidas again, was he the plague doctor?" This tends to undermine the emotional impact. It didn't help that the plot was enough of a slog that I kept putting the book aside for a few days. This does get better, but not enough better to redeem the middle of the book, and one has to put up with a lot of helpless despair to get there. Shadow Scale is one of those stories where the protagonist has the innate power to resolve the plot, is told cryptically by various people that this is the case, but has absolutely no idea how to use it and her supposed mentors are essentially useless. The result is that she feels both hopeless and guilty, which was not the reading experience I wanted. I did enjoy the moment when she finally figures it out, and I thought Hartman's idea was reasonably clever, but it would have been better if that had happened faster. Like, 200 pages faster. At least. The major world-building in Seraphina was the dragons. The dragons also show up in this book (and feel less like autism spectrum archetypes, which I appreciated), and in theory are central to the plot, but I'm not entirely sure why? It was an odd reading experience. I think Hartman was attempting to set up dual villains posing different threats, but the dragon one is off-screen for nearly the entire book and never developed, so it feels perfunctory. Near the end of the book, Hartman abruptly picks up the dragons again, but that whole section felt oddly disconnected from the rest of the plot and is only barely relevant to the resolution. At least for me, the plot structure didn't cohere. Shadow Scale does go up a whole point in rating for me because of the romance plot and how Hartman resolves it, which I will not spoil but which I loved. The process of getting there is immensely frustrating because it feels like Hartman is forcing the characters into a corner where only stupid resolutions are possible, but in this case the U-shaped emotional structure worked on me. The ending is completely true to the characters in a way that I thought Hartman had made impossible (and which does a lovely bit of undermining of traditional roles), so full credit there. It helped that the relationship is put on ice for most of the book and only appears at the end (which is also the best part of the book), so it didn't drag on like the other parts of the plot. Overall, though, I tentatively agree with the general advice to skip this one, and suspect that advice will become less tentative once I read Tess of the Road. It's a largely unpleasant slog. There are some mildly interesting world-building revelations that fill in the background of Seraphina, the ending was reasonably good, and the relationships were much better than I was expecting through most of the book, but the amount of time and patience required to get there was not a good trade-off for me. Followed (in the sense that it's set in the same universe but is not a sequel and I suspect does not depend heavily on this plot) by Tess of the Road. Rating: 4 out of 10

Focus This month I didn't have any particular focus. I just worked on issues in my info bubble.

Changes

• gadget-tool: build cleanup
• bootstrappable.org: https (1 2)
• iotop-py: fix crash, handle Linux kernel API changes (1 2)
• jq: document security issue
• esprima-python: cleanup typos, links, license mistakes
• feed2exec: save page resources in wayback machine plugin
• purple-discord: add missing linking, fix compile warnings
• check-all-the-things: remove duplicate TODO, add pigz-test check
• devscripts: sync BTS tags
• Debian puppet: block BTS spammer
• Debian package uploads: pytest-rerunfailures, purple-discord (1 2), harmony, quesoglc
• Debian wiki pages: AutomatedUpgrade, Debhelper, DebianInstaller/Build, DebianInstaller/Loader/SuspectedVirus, Derivatives/Census (Pengwin, Quirinux), DeveloperNews, Hardware/Database, InstallingDebianOn/Turris/Omnia, Printing, StaticLinking, Statistics, SuitesAndReposExtension, Teams/ReleaseTeam/ReleaseCheckList
• FOSSjobs wiki pages: Resources

Issues

• Crashes in lintian-brush, gnome-shell-extension-shortcuts
• Broken symlinks in speech-dispatcher, ucx
• Dependency bloat in librecaptcha
• Test hangs in pyemd
• Features in apt-listchanges, evolution (1 2 3), baobab, pipewire, reportbug (1 2), systemd-coredump (1 2), find-dbgsym-packages (1 2), gdb
• Syntax highlighting issues in gtksourceview (1 2)
• Outdated links in duktape
• License change needed in cloudflared
• Rebuild needed for ricochet-im
• New versions of pidgin
• Usability issues in GNOME Keyring certificate viewer (also mistakenly filed against Firefox)
• Underlinking in ucx
• False positives in lintian
• Security issues in systemd-coredump (sent privately, rejected)

Review

• Spam: reported 1 Sourceware Bugzilla comment, 1 KDE Bugzilla comment, 580 Debian bug reports and 178 Debian mailing list posts
• Debian packages: sponsored iotop-c backports
• Debian wiki: RecentChanges for the month
• Debian BTS usertags: changes for the month
• Debian screenshots:
  • approved ark audacious bpfmon chameleon-cursor-theme chromium color-picker convertall convert-pgn cpufrequtils cpuid cpuidtool cpulimit cpustat dclock desktop-base docker.io elementary-xfce-icon-theme engrampa ephoto eterm exadrums exifprobe exiftags file-roller firefox fspanel imgp ipython3 linphone-desktop linux-cpupower live-image-xfce-desktop lxqt-archiver mate-desktop mwm network-manager nm-tray pamix pulsemixer python3-pip supertuxkart transmission-remote-gtk xarchiver xfce4 xfce4-datetime-plugin xscreensaver
  • rejected fonts-recommended (just debian/control), obfsproxy (private data), gpart/p7zip/p7zip-full/unzip/unrar (usage), cruft (doesn't show use of tool), weboob-qt/acetoneiso/klettres (screenshot of screenshots website), default-jre-headless/minetest-mod-basic-materials (illustration), gamine/weboob-qt/libstdc++6/med-imaging (photograph), drumstick-tools (wrong package), totem (newspaper article)

Administration

• Debian BTS: reopened bugs closed by a spammer
• Debian wiki: unblock IP addresses, approve accounts

Communication

• Respond to queries from Debian users and contributors on the mailing lists and IRC

Sponsors The purple-discord/harmony/pyemd/librecaptcha/esprima-python work was sponsored by my employer. All other work was done on a volunteer basis.

The following contributors got their Debian Developer accounts in the last two months:

• Alo s Micard (creekorful)
• Sophie Brun (sophieb)

The following contributors were added as Debian Maintainers in the last two months:

• Douglas Andrew Torrance
• Marcel Fourn
• Marcos Talau
• Sebastian Geiger

Congratulations!

I have been using the awesome window manager for 10 years. It is a tiling window manager, configurable and extendable with the Lua language. Using a general-purpose programming language to configure every aspect is a double-edged sword. Due to laziness and the apparent difficulty of adapting my configuration about 3000 lines to newer releases, I was stuck with the 3.4 version, whose last release is from 2013. It was time for a rewrite. Instead, I have switched to the i3 window manager, lured by the possibility to migrate to Wayland and Sway later with minimal pain. Using an embedded interpreter for configuration is not as important to me as it was in the past: it brings both complexity and brittleness.

Dual screen desktop running i3, Emacs, some terminals, including a Quake console, Firefox, Polybar as the status bar, and Dunst as the notification daemon.

The window manager is only one part of a desktop environment. There are several options for the other components. I am also introducing them in this post.

i3: the window manager i3 aims to be a minimal tiling window manager. Its documentation can be read from top to bottom in less than an hour. i3 organize windows in a tree. Each non-leaf node contains one or several windows and has an orientation and a layout. This information arbitrates the window positions. i3 features three layouts: split, stacking, and tabbed. They are demonstrated in the below screenshot:

Demonstration of the layouts available in i3. The main container is split horizontally. The first child is split vertically. The second one is tabbed. The last one is stacking.

Tree representation of the previous screenshot.

Most of the other tiling window managers, including the awesome window manager, use predefined layouts. They usually feature a large area for the main window and another area divided among the remaining windows. These layouts can be tuned a bit, but you mostly stick to a couple of them. When a new window is added, the behavior is quite predictable. Moreover, you can cycle through the various windows without thinking too much as they are ordered. i3 is more flexible with its ability to build any layout on the fly, it can feel quite overwhelming as you need to visualize the tree in your head. At first, it is not unusual to find yourself with a complex tree with many useless nested containers. Moreover, you have to navigate windows using directions. It takes some time to get used to. I set up a split layout for Emacs and a few terminals, but most of the other workspaces are using a tabbed layout. I don t use the stacking layout. You can find many scripts trying to emulate other tiling window managers but I did try to get my setup pristine of these tentatives and get a chance to familiarize myself. i3 can also save and restore layouts, which is quite a powerful feature. My configuration is quite similar to the default one and has less than 200 lines.

i3 companion: the missing bits i3 philosophy is to keep a minimal core and let the user implements missing features using the IPC protocol:

Do not add further complexity when it can be avoided. We are generally happy with the feature set of i3 and instead focus on fixing bugs and maintaining it for stability. New features will therefore only be considered if the benefit outweighs the additional complexity, and we encourage users to implement features using the IPC whenever possible. Introduction to the i3 window manager

While this is not as powerful as an embedded language, it is enough for many cases. Moreover, as high-level features may be opinionated, delegating them to small, loosely coupled pieces of code keeps them more maintainable. Libraries exist for this purpose in several languages. Users have published many scripts to extend i3: automatic layout and window promotion to mimic the behavior of other tiling window managers, window swallowing to put a new app on top of the terminal launching it, and cycling between windows with Alt+Tab. Instead of maintaining a script for each feature, I have centralized everything into a single Python process, i3-companion using asyncio and the i3ipc-python library. Each feature is self-contained into a function. It implements the following components:

make a workspace exclusive to an application

When a workspace contains Emacs or Firefox, I would like other applications to move to another workspace, except for the terminal which is allowed to intrude into any workspace. The workspace_exclusive() function monitors new windows and moves them if needed to an empty workspace or to one with the same application already running.

implement a Quake console

The quake_console() function implements a drop-down console available from any workspace. It can be toggled with Mod+ . This is implemented as a scratchpad window.

back and forth workspace switching on the same output

With the workspace back_and_forth command, we can ask i3 to switch to the previous workspace. However, this feature is not restricted to the current output. I prefer to have one keybinding to switch to the workspace on the next output and one keybinding to switch to the previous workspace on the same output. This behavior is implemented in the previous_workspace() function by keeping a per-output history of the focused workspaces.

create a new empty workspace or move a window to an empty workspace

To create a new empty workspace or move a window to an empty workspace, you have to locate a free slot and use workspace number 4 or move container to workspace number 4. The new_workspace() function finds a free number and use it as the target workspace.

restart some services on output change

When adding or removing an output, some actions need to be executed: refresh the wallpaper, restart some components unable to adapt their configuration on their own, etc. i3 triggers an event for this purpose. The output_update() function also takes an extra step to coalesce multiple consecutive events and to check if there is a real change with the low-level library xcffib.

I will detail the other features as this post goes on. On the technical side, each function is decorated with the events it should react to:

@on(CommandEvent("previous-workspace"), I3Event.WORKSPACE_FOCUS)
async def previous_workspace(i3, event):
    """Go to previous workspace on the same output."""

The CommandEvent() event class is my way to send a command to the companion, using either i3-msg -t send_tick or binding a key to a nop command. The latter is used to avoid spawning a shell and a i3-msg process just to send a message. The companion listens to binding events and checks if this is a nop command.

bindsym $mod+Tab nop "previous-workspace"

There are other decorators to avoid code duplication: @debounce() to coalesce multiple consecutive calls, @static() to define a static variable, and @retry() to retry a function on failure. The whole script is a bit more than 1000 lines. I think this is worth a read as I am quite happy with the result.

dunst: the notification daemon Unlike the awesome window manager, i3 does not come with a built-in notification system. Dunst is a lightweight notification daemon. I am running a modified version with HiDPI support for X11 and recursive icon lookup. The i3 companion has a helper function, notify(), to send notifications using DBus. container_info() and workspace_info() uses it to display information about the container or the tree for a workspace.

Notification showing i3 s tree for a workspace

polybar: the status bar i3 bundles i3bar, a versatile status bar, but I have opted for Polybar. A wrapper script runs one instance for each monitor. The first module is the built-in support for i3 workspaces. To not have to remember which application is running in a workspace, the i3 companion renames workspaces to include an icon for each application. This is done in the workspace_rename() function. The icons are from the Font Awesome project. I maintain a mapping between applications and icons. This is a bit cumbersome but it looks great.

i3 workspaces in Polybar

For CPU, memory, brightness, battery, disk, and audio volume, I am relying on the built-in modules. Polybar s wrapper script generates the list of filesystems to monitor and they get only displayed when available space is low. The battery widget turns red and blinks slowly when running out of power. Check my Polybar configuration for more details.

Polybar displaying various information: CPU usage, memory usage, screen brightness, battery status, Bluetooth status (with a connected headset), network status (connected to a wireless network and to a VPN), notification status, and speaker volume.

For Bluetooh, network, and notification statuses, I am using Polybar s ipc module: the next version of Polybar can receive an arbitrary text on an IPC socket. The module is defined with a single hook to be executed at the start to restore the latest status.

[module/network]
type = custom/ipc
hook-0 = cat $XDG_RUNTIME_DIR/i3/network.txt 2> /dev/null
initial = 1

It can be updated with polybar-msg action "#network.send.XXXX". In the i3 companion, the @polybar() decorator takes the string returned by a function and pushes the update through the IPC socket. The i3 companion reacts to DBus signals to update the Bluetooth and network icons. The @on() decorator accepts a DBusSignal() object:

@on(
    StartEvent,
    DBusSignal(
        path="/org/bluez",
        interface="org.freedesktop.DBus.Properties",
        member="PropertiesChanged",
        signature="sa sv as",
        onlyif=lambda args: (
            args[0] == "org.bluez.Device1"
            and "Connected" in args[1]
            or args[0] == "org.bluez.Adapter1"
            and "Powered" in args[1]
        ),
    ),
)
@retry(2)
@debounce(0.2)
@polybar("bluetooth")
async def bluetooth_status(i3, event, *args):
    """Update bluetooth status for Polybar."""

The middle of the bar is occupied by the date and a weather forecast. The latest also uses the IPC mechanism, but the source is a Python script triggered by a timer.

Current date and weather forecast for the day in Polybar. The data is retrieved with the OpenWeather API.

I don t use the system tray integrated with Polybar. The embedded icons usually look horrible and they all behave differently. A few years back, Gnome has removed the system tray. Most of the problems are fixed by the DBus-based Status Notifier Item protocol also known as Application Indicators or Ayatana Indicators for GNOME. However, Polybar does not support this protocol. In the i3 companion, The implementation of Bluetooth and network icons, including displaying notifications on change, takes about 200 lines. I got to learn a bit about how DBus works and I get exactly the info I want.

picom: the compositor I like having slightly transparent backgrounds for terminals and to reduce the opacity of unfocused windows. This requires a compositor.¹ picom is a lightweight compositor. It works well for me, but it may need some tweaking depending on your graphic card.² Unlike the awesome window manager, i3 does not handle transparency, so the compositor needs to decide by itself the opacity of each window. Check my configuration for details.

systemd: the service manager I use systemd to start i3 and the various services around it. My xsession script only sets some environment variables and lets systemd handles everything else. Have a look at this article from Micha G ral for the rationale. Notably, each component can be easily restarted and their logs are not mangled inside the ~/.xsession-errors file.³ I am using a two-stage setup: i3.service depends on xsession.target to start services before i3:

[Unit]
Description=X session
BindsTo=graphical-session.target
Wants=autorandr.service
Wants=dunst.socket
Wants=inputplug.service
Wants=picom.service
Wants=pulseaudio.socket
Wants=policykit-agent.service
Wants=redshift.service
Wants=spotify-clean.timer
Wants=ssh-agent.service
Wants=xiccd.service
Wants=xsettingsd.service
Wants=xss-lock.service

Then, i3 executes the second stage by invoking the i3-session.target:

[Unit]
Description=i3 session
BindsTo=graphical-session.target
Wants=wallpaper.service
Wants=wallpaper.timer
Wants=polybar-weather.service
Wants=polybar-weather.timer
Wants=polybar.service
Wants=i3-companion.service
Wants=misc-x.service

Have a look on my configuration files for more details.

rofi: the application launcher Rofi is an application launcher. Its appearance can be customized through a CSS-like language and it comes with several themes. Have a look at my configuration for mine.

Rofi as an application launcher

It can also act as a generic menu application. I have a script to control a media player and another one to select the wifi network. It is quite a flexible application.

Rofi to select a wireless network

xss-lock and i3lock: the screen locker i3lock is a simple screen locker. xss-lock invokes it reliably on inactivity or before a system suspend. For inactivity, it uses the XScreenSaver events. The delay is configured using the xset s command. The locker can be invoked immediately with xset s activate. X11 applications know how to prevent the screen saver from running. I have also developed a small dimmer application that is executed 20 seconds before the locker to give me a chance to move the mouse if I am not away.⁴ Have a look at my configuration script.

Demonstration of xss-lock, xss-dimmer and i3lock with a 4 speedup.

The remaining components

• autorandr is a tool to detect the connected display, match them against a set of profiles, and configure them with xrandr.
• inputplug executes a script for each new mouse and keyboard plugged. This is quite useful to load the appropriate the keyboard map. See my configuration.
• xsettingsd provides settings to X11 applications, not unlike xrdb but it notifies applications for changes. The main use is to configure the Gtk and DPI settings. See my article on HiDPI support on Linux with X11.
• Redshift adjusts the color temperature of the screen according to the time of day.
• maim is a utility to take screenshots. I use Prt Scn to trigger a screenshot of a window or a specific area and Mod+Prt Scn to capture the whole desktop to a file. Check the helper script for details.
• I have a collection of wallpapers I rotate every hour. A script selects them using advanced machine learning algorithms and stitches them together on multi-screen setups. The selected wallpaper is reused by i3lock.

---

1. Apart from the eye candy, a compositor also helps to get tear-free video playbacks.
2. My configuration works with both Haswell (2014) and Whiskey Lake (2018) Intel GPUs. It also works with AMD GPU based on the Polaris chipset (2017).
3. You cannot manage two different displays this way e.g. :0 and :1. In the first implementation, I did try to parametrize each service with the associated display, but this is useless: there is only one DBus user session and many services rely on it. For example, you cannot run two notification daemons.
4. I have only discovered later that XSecureLock ships such a dimmer with a similar implementation. But mine has a cool countdown!

Focus This month I didn't have any particular focus. I just worked on issues in my info bubble.

Changes

• zxing-cpp: use system deps, fix Python tests
• git-remote-hg: gitignore
• hexedit: add test
• libpst: fix header detection
• webdl: fix SBS video params
• libusbgx: fix alignment
• tracegraph: API porting
• pyemd: cleanup code, packaging
• pytest-rerunfailures: cleanup code, build, packaging
• librecaptcha: cleanup Python packaging, links
• check-all-the-things: update MIME types, command verbosity (1 2), TODO items (1 2 3)
• devscripts: multiple packages for grep-excuses --wipnity
• debhelper: typo, cmake ctest argument order
• Debian website: sync langs
• Debian /updates to -security transition: 1 2 3 4 5 6
• Debian release info hardcoding: 1 2
• Debian QA services: cleanup
• Debian package uploads: libpst, foxtrotgps, sptag (1 2 3), pytest-rerunfailures, git-remote-hg (1 2), librecaptcha
• Debian wiki pages: 900000thBugContest, ALSA, AlyssaRosenzweig, BugTriage, DebianDay/2021/India/Online, DebianEdu/Status/Bullseye, FrontPage, Fvwm, HostingControlPanels, InstallingDebianOn (Microsoft/Windows/SubsystemForLinux, Thinkpad/L13 Gen 2/buster), ReleaseParty, SourcesList, Status/Stable, SuitesAndReposExtension, Teams (Apt, ReleaseTeam/ReleaseCheckList), ungoogled-chromium
• FOSSjobs wiki pages: Resources
• Wikipedia: Display_Data_Channel

Issues

• Crash in eog
• Web request mishandling in fossjobs
• AppArmor issues in torbrowser-launcher
• Broken links in Debian backports NEW, GMime
• Missing link in GMime
• Outdated links in crouton, breezy
• Broken pages in GNOME Bugzilla archive
• Features in debiman (1 2), gokart, debhelper, shellcheck (1 2)
• New versions of umatrix, doc8, git-remote-hg
• New repo needed for misspelling research
• Hardcoded Debian release info updates for debiman (1 2)
• Syntax error in freefem++
• Adoption needed for veles
• Underlinking in libuemf0
• Conffile removal needed in wireplumber
• Build issues in SPTAG (1 2), plocate, zxing-cpp
• Git tag conflict in git-remote-hg
• Dependency updates for catfish, education-common, cruft-ng
• Cruft deposited by qgis-providers
• More binary packages needed in zxing-cpp (1 2)
• Malicious Python module on PyPI

Review

• Spam: reported 1 sourceware bug report, 2 Debian bug reports and 86 Debian mailing list posts
• Debian packages: reviewed iotop-c and approved DM upload
• Debian wiki: RecentChanges for the month
• Debian BTS usertags: changes for the month
• Debian screenshots:
  • approved aptitude faenza-icon-theme gnome-icon-theme-yasis gnome-illustrious-icon-theme gnome-power-manager juffed mm3d mystiq shiki-brave-theme
  • rejected unetbootin (random web page), tuxmath (photograph not screenshot)

Administration

• Debian servers: expand LV, fix debbugs config
• Debian wiki: unblock IP addresses, approve accounts
• Debian QA services: deploy changes

Communication

• Initiate discussion about Debian source tarball choices

Sponsors The pyemd, pytest-rerunfailures, libpst, sptag, librecaptcha work was sponsored by my employer. All other work was done on a volunteer basis.

I'm guessing the last glasses will be through the dishwasher (again) and Pepper the dog can settle down without having to cope with so many people.For those who don't know - Steve and his wife Jo (Sledge and Randombird) hold a barbeque in their garden every August Bank Holiday weekend [UK Bank Holiday on the last Monday in August]. The barbeque is not small - it's the dominating feature in the suburban garden, brick built, with a dedication stone, lights, electricity. The garden is small, generally made smaller by forty or so Debian friends and allies standing and sitting around. People are talking, arguing, hugging people they've not seen for (literal) years and putting the world to rights. This is Debian central point - with large quantities of meat and salads, an amount of beer/alcohol and "Cambridge gin" and general goodwill. This year was more than usually atmospheric because for some of us it was the first time with a large group of people in a while. Side conversations abound: for me it was learning something about the high energy particle physics community, how to precision build helicopters, fly quadcopters and precision 3D print anything, the maths of Isy counting crochet stitches to sew together randomly sized squares ... and, of course, obligatory things like how random is random and what's good enough entropy. And a few sessions of the game of our leader.
This is also a place for stuff to get done: I was unashamedly using this to upgrade the storage in my laptop while there were sensible engineers around. A corner of the table, a RattusRattus and it was quickly sorted - then a discussion around the internals of Thinkpads as he took his apart. Then getting a full install - Gb Ethernet to the Debian mirror in the cupboard six feet away is faster bandwidth than a jumbo jet full of tapes. Then getting mail to work again - it's handy when the mailserver owner is next to you, having come in from the garden to help, and finally IRC. And not just me: "You need a GPG key signed - there's three DPLs here, there's a release manager - but you've just missed one of the DAMs." plus an in-depth GPG how-to session on the other side of the table.I was the luckiest one with the most comfortable bed in the house overnight but I couldn't stay for last night. Thanks once again to all involved but especially Steve and Jo who do this for the love of it, and the fun, and the community and the family. Oh, and thanks to Lenovo - not just for being a platinum sponsor of Debconf but also for providing the official laptop of this and most Debian occasions

Thanks to all who've made Debconf 21 such a good place to be.

A song for Debconf21 ["What shall we do with the drunken sailor"]

What shall we do with the online Debconf?What shall we do with the online Debconf?What shall we do with the online Debconf?

Earl-y in the morning

Close it up as we agreed it

Save each script in case we need it

Work out how we best live-feed itNext year s Debconf s dawning

Next year s Kosovo and Pristina

This virtual Debconf needs no cleaner

Hope when COVID s gone we re keener

To meet up every morning

Thanks to the Debconf orga team

Thanks to those who Loopy meme

Things are not always as they seeem

In virtual Debconf s morning

Bullseye s out its share is rising

Debconf s fun and quite surprising

Linux 30 :)

Yours and my thing - Debian s 28

Thanks to all who video d sessions

Debconf T-shirts - prized possessions

Debcamp bug-fixed some regressions

Now onto next year!

A closing song for Debconf 21 [Frere Jacques/Brueder Martin]

DebConf21

Virtual DebConf s

Now all through

Closed for you

Kosovo is next year

See you in Pristina!!

DebConf 22

Twenty twenty-two

Thanks to the good folk who put the hard work into building a UEFI implementation for the Raspberry Pi 4 which "just works", allowing you to install Debian straightforwardly, and especially to Pete Batard who has written up the process and collected a zip file together.

Not quite so straightforward ...

I have an early model Raspberry Pi 4. I wanted to install Debian on an SSD connected via a cable to a USB3 port. It turned out that the version of the software in the EEPROM would not boot reliably so the first task was to update this with the latest stable EEPROM available from the Raspberry Pi downloads.

The easiest way to do this was to boot an SD card with Raspbian on. Once that was done, I had a Pi that would boot from an SSD.

Untar the files

A tarball of UEFI from Pete's Github repository at https://github.com/pftf/RPi4/releases - latest is v 1.29 as at 20210814.

Plugging in the SSD to another machine to format the drive: msdos format, one ESP partition in FAT32 and marked bootable and the rest of the drive blank.

One aarch64 DVD image from the usual place.

https://cdimage.debian.org/debian-cd/current/arm64/iso-dvd/debian-11.0.0-arm64-DVD-1.iso

Untar the UEFI tarball into the ESP partition you've just made

Plug the SSD into a USB3 port on the RPi using a USB -> SATA cable

Write the aarch image to a USB stick using dd and place that into one of the other USB ports. Add a keyboard.

Install

Power up the RPi4, hit Esc and work your way through UEFI to select a boot device and go, save the settings and go.

The install is almost identical to any Debian d-i install.

There is a setting in UEFI to reclaim the 1G of memory that was masked out, there's a setting for control of the fan shim if you have that style of fan.

End result - happiness

Done the other day and sitting next to me on the desktop.

28 today. In a video call for Debian day earlier on, I was reminiscing about the earliest distributions: MCC Interim Linux gave instructions to turn it's final version into Debian. Debian is the second oldest Linux distribution, just behind Slackware.Debian 1.2 was my first Debian: my latest is, obviously, Debian Bullseye. Debian is like a family - often discordant, sometimes dysfunctional but always full of people that care and are cared for. I wish that some of my friends and colleagues no longer with us could be here to see just how well we're doing.This is something that's been with me for so long that I can't imagine life without it: software, obscure hardware but above all friends closer than family. The biggest software project anywhere, potentially, and it's all for free - and 95.7% independently reproducible. Thanks to all my colleagues and co-workers who've become friends over the years without whom none of this would be possible. Oh, and thanks to Ian Murdock - I never got to meet him but I did get to email him when he was in charge of Progeny. Without him, none of this would even have started.

It's been quite a long day - last few normal tests are being run through now.Lots more involvement from more people: nothing too catastrophic and a good many installs run through. The usual back and forth and noticing odd things that crop up: it's always interesting to get someone else's viewpoint and second pair of eyes on something.Thanks also to Schweer who's done his usual solo testing of all the Debian-Edu software, quietly and with no fuss.Looking good.

Lots of people - lots of effort - we're gradually closing in on a last few tests.It's been quite a long time but we're significantly ahead of where we would be on many tests for release candidates and main releases. It's always fun to do and chat back and forth. Having new testers check in from tomorrow (Australia) has also been a novelty.It's been a very long wait for this but "This is the best Debian release ever", as they say.

And so we're building CDs / DVDs and larger images. Lots of people joining us, either to say Hi or to actually add to the tests.All of the most common CDs / DVDs have been tested. Not too many obvious bugs found in our processes this time and tests are going well.Some of the usual suspects but also some new testers: Hi to bittin who dropped in before the Stockholm release party, to smcv and to highvoltage and to liz and Linux-Fan
Hope all's going well with everyone.