Since the freeze has slowly crept in, now is the time to revisit my pet peeve with Debian's release process: to publish a new Debian release as soon as GNOME published a new X.XX.0 version. This is an extremely bad idea: X.XX.0 releases tend to lack polish, their translations are not up-to-date and several silly bugs that hamper the user experience (what the Ubuntu guys call "paper cuts") exist. Those issues tend to be fixed later when GNOME X.XX.1, X.XX.2, etc. bugfix releases are published. However, Debian has a policy of not pushing non-security releases onto a stable distribution. In this particular case, there are only two valid alternatives: either release Bullseye with GNOME 3.38.X or change the Debian policy to allow pushing 3.40.X bugfix releases via bullseye-updates.
2021-02-15
OpenWRT: WRT54GL: Backfire: IPv6 issues
While having a Debian boxen as a router feels nice, I kept on longing for something smaller and quieter. I then remembered that I still had my old WRT54GL somewhere. After upgrading the OpenWRT firmware to the latest supported version for that hardware (Backfire 10.03.1, r29592), I installed radvd and wide-dhcpv6-client. Configuring radvd to deliver consistent results was easy enough.
The issue I keep on experiencing is the external interface (wan) dropping the IPv6 address it received from the ISP via router advertisement, which in turn kills the default IPv6 route to the outside world. Logging in via SSH and manually running "rdisc6 eth0.1" restores the IPv6 gateway. I just honestly wished I didn't have to do this every time I need to reboot the router.
Does this issue sound familiar to anyone? What was the solution?
PS: No, I won't just go and ditch this WRT54GL just because new toys exist on the market. This is obviously a software issue, so I need a software solution.
PPS: IPv6 pretty much works out of the box on the Debian boxen I had been using as my router. I previously wrote about this on my blog. Basically, it's unlikely to be an ISP issue.
2021-01-02
Help needed: clean up and submit KMS driver for Geode LX to LKML
Ever since X.org switched to rootless operation, the days of the Geode X.org driver have been numbered. The old codebase dates back from Geode's early days at Cyrix, was then updated by NSC to add support for their new GX2 architecture, from which AMD dropped GX1 support and added support for their new LX architecture. To put it mildly, that codebase is a serious mess.
However, at least the LX code comes with plenty of niceties, such as being able to detect when it runs on an OLPC XO-1 and to probe DCC pins to determine the optimal display resolution on other hardware. This still doesn't make the codebase cruft-free.
Anyhow, most Linux distributions have dropped support for anything older than i686 with PAE, which essentially means that the GX2 code is just for show. Debian is one of very few distributions whose x86-32 port still ships with i686 without PAE. In fact, the lowest common denominator kernel on i386 is configured for Geode (LX).
A while back, someone had started working on a KMS driver for the Geode LX. Through word of mouth, I got my hands on a copy of their Git tree. The driver worked reasonably well, but the codebase needs some polishing before it could be included in the Linux kernel tree.
Hence this call for help:
Is there anyone with good experience of the LKML coding standards who would be willing to clean up the driver's code and submit the patch to the LKML?
2020-11-03
Adding IPv6 support to my home LAN
A couple of year ago, I moved into a new flat that comes with RJ45 sockets wired for 10 Gigabit (but currently offering 1 Gigabit) Ethernet.
This also meant changing the settings on my router box for my new ISP.
I took this opportunity to review my router's other settings too. I'll be blogging about these over the next few posts.
Adding IPv6 support to my home LAN
I have been following the evolution of IPv6 ever since the KAME project produced the first IPv6 implementation. I have also been keeping track of the IPv4 address depletion.
Around the time the IPv6 Day was organized in 2011, I started investigating the situation of IPv6 support at local ISPs.
Well, never mind all those rumors about Finland being some high-tech mecca. Back then, no ISP went beyond testing their routers for IPv6 compatibility and producing white papers on what their limited test deployments accomplished.
Not that it matters much, in practice. Most IPv6 documentation out there, including Debian's own, still focuses on configuring transitional mechanisms, especially how to connect to a public IPv6 tunnel broker.
Relocating to a new flat and rethinking my home network to match gave me an opportunity to revisit the topic. Much to my delight, my current ISP offers native IPv6.
This prompted me to go back and read up on IPv6 one more time. One important detail:
IPv6 hosts are globally reachable.
The implications of this don't immediately spring to mind for someone used to IPv4 network address translation (NAT):
Any network service running on an IPv6 host can be reached by anyone anywhere.
Contrary to IPv4, there is no division between private and public IP addresses. Whereas a device behind an IPv4 NAT essentially is shielded from the outside world, IPv6 breaks this assumption in more than one way. Not only is the host reachable from anywhere, its default IPv6 address is a mathematical conversion (EUI-64) of the network interface's MAC address, which makes every connection forensically traceable to a unique device.
Basically, if you hadn't given much thought to firewalls until now, IPv6 should give you enough goose bumps to get around it. Tightening the configuration of every network service is also an absolute must. For instance, I configured sshd to only listen to private IPv4 addresses.
What /etc/network/interfaces might look like on an dual-stack (IPv4 + IPv6) host:
allow-hotplug enp9s0 iface enp9s0 inet dhcp iface enp9s0 inet6 auto privext 2 dhcp 1
The auto method means that IPv6 will be auto-configured using SLAAC; privext 2 enables IPv6 privacy options and specifies that we prefer connecting via the randomly-generated IPv6 address, rather than the EUI-64 calculated MAC specific address; dhcp 1 enables passive DHCPv6 to fetch additional routing information.
The above works for most desktop and laptop configurations.
Where things got more complicated is on the router. I decided early on to keep NAT to provide an IPv4 route to the outside world. Now how exactly is IPv6 routing done? Every node along the line must have its own IPv6 address... including the router's LAN interface. This is accomplished using the sample script found in Debian's IPv6 prefix delegation wiki page. I modified mine as follows (the rest of the script is omitted for clarity):
#Both LAN interfaces on my private network are bridged via br0 IA_PD_IFACE="br0" IA_PD_SERVICES="dnsmasq" IA_PD_IPV6CALC="/usr/bin/ipv6calc"
Just put the script at the suggested location. We'll need to request a prefix on the router's outside interface to utilize it. This gives us the following interfaces file:
allow-hotplug enp2s4 enp2s8 enp2s9 auto br0 iface enp2s4 inet dhcp iface enp2s4 inet6 auto request_prefix 1 privext 2 dhcp 1 iface enp2s8 inet manual iface enp2s8 inet6 manual iface enp2s9 inet manual iface enp2s9 inet6 manual iface br0 inet static bridge_ports enp2s8 enp2s9 address 10.10.10.254 iface br0 inet6 manual bridge_ports enp2s8 enp2s9 # IPv6 from /etc/dhcp/dhclient-exit-hooks.d/prefix_delegation
The IPv4 NAT and IPv6 Bridge script on my router looks as follows:
#!/bin/sh PATH="/usr/sbin:/sbin:/usr/bin:/bin" wan=enp2s4 lan=br0 ######################################################################## # IPv4 NAT iptables -F; iptables -t nat -F; iptables -t mangle -F iptables -X; iptables -t nat -X; iptables -t mangle -X iptables -Z; iptables -t nat -Z; iptables -t mangle -Z iptables -t nat -A POSTROUTING -o $wan -j MASQUERADE echo 1 > /proc/sys/net/ipv4/ip_forward ######################################################################## # IPv6 bridge ip6tables -F; ip6tables -X; ip6tables -Z # Default policy DROP ip6tables -P FORWARD DROP # Allow ICMPv6 forwarding ip6tables -A FORWARD -p ipv6-icmp -j ACCEPT # Allow established connections ip6tables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT # Accept packets FROM LAN to everywhere ip6tables -I FORWARD -i $lan -j ACCEPT echo 1 > /proc/sys/net/ipv6/conf/all/forwarding echo 1 > /proc/sys/net/ipv6/conf/default/forwarding # IPv6 propagation via /etc/dhcp/dhclient-exit-hooks.d/prefix_delegation
The above already provided enough IPv6 connectivity to pass the IPv6 test on my desktop inside the LAN.
To make things more fun, I enabled DHCPv6 support for my LAN on the router's dnsmasq by adding the last 3 lines to the configuration:
dhcp-hostsfile=/etc/dnsmasq-ethersfile bind-interfaces interface=br0 except-interface=enp2s4 no-dhcp-interface=enp2s4 dhcp-range=tag:br0,10.10.10.0,static,infinite dhcp-range=tag:br0,::1,constructor:br0,ra-names,ra-stateless,infinite enable-ra dhcp-option=option6:dns-server,[::],[2606:4700:4700::1111],[2001:4860:4860::8888]
The 5 first lines (included here for emphasis) are extremely important: they ensure that dnsmasq won't provide any IPv4 or IPv6 service to the outside interface (enp2s4) and that DHCP will only be provided for LAN hosts whose MAC address is known. Line 6 shows how dnsmasq's DHCP service syntax differs between IPv4 and IPv6. The rest of my configuration was omitted on purpose.
Enabling native IPv6 on my LAN has been an interesting experiment. I'm sure that someone could come up with even better ip6tables rules for the router or for my desktop hosts. Feel free to mention them in the blog's comment.
Migrating to Predictable Network Interface Names
A couple of years ago, I moved into a new flat that comes with RJ45 sockets wired for 10 Gigabit (but currently offering 1 Gigabit) Ethernet.
This also meant changing the settings on my router box for my new ISP.
I took this opportunity to review my router's other settings too. I'll be blogging about these over the next few posts.
Migrating to Predictable Network Interface Names
Ever since Linus decided to flip the network interface enumeration order in the Linux kernel, I had been relying on udev's persistent network interface rules to maintain some semblance of consistency in the NIC naming scheme of my hosts. It has never been a totally satisfactory method, since it required manually editing the file to list the MAC addresses of all Ethernet cards and WiFi dongles likely to appear on that host to consistently use an easy-to-remember name that I could adopt for ifupdown configuration files.
Enter predictable interface names. What started as a Linux kernel module project at Dell was eventually re-implemented in systemd. However, clear documentation on the naming scheme had been difficult to find and udev's persistent network interface rules gave me what I needed, so I postponed the transition for years. Relocating to a new flat and rethinking my home network to match gave me an opportunity to revisit the topic.
The naming scheme is surprisingly simple and logical, once proper explanations have been found. The short version:
- Ethernet interfaces are called en i.e. Ether Net.
- Wireless interfaces are called wl i.e. Wire Less. (yes, the official documentation call this Wireless Local but, in everyday usage, remembering Wire Less is simpler)
The rest of the name specifies on which PCI bus and which slot the interface is found. On my old Dell laptop, it looks like this:
- enp9s0: Ethernet interface at PCI bus 9 slot 0.
- wlp12s0: Wireless interface at PCI bus 12 slot 0.
An added bonus of the naming scheme is that it makes replacing hardware a breeze, since the naming scheme is bus and slot specific, not MAC address specific. No need to edit any configuration file. I saw this first-hand when I got around upgrading my router's network cards to Gigabit-capable ones to take advantage of my new home's broadband LAN. All it took was to power off the host, swap the Ethernet cards and power on the host. That's it. systemd took care of everything else.
Still, migrating looked like a daunting task. Debian's wiki page gave me some answers, but didn't provide a systematic approach. I came up with the following shell script:
#!/bin/sh lspci | grep -i -e ethernet -e network sudo dmesg | grep -i renamed for n in $(ls -X /sys/class/net/ | grep -v lo); do echo $n: && udevadm test-builtin net_id /sys/class/net/$n 2>/dev/null | grep NAME; sudo rgrep $n /etc sudo find /etc -name '*$n*' done
This combined ideas found on the Debian wiki with a few of my own. Running the script before and after the migration ensured that I hadn't missed any configuration file. Once I was satisfied with that, I commented out the old udev persistent network interface rules, ran dpkg-reconfigure on all my Linux kernel images to purge the rules from the initrd images, and called it a day.
... well, not quite. It turns out that with bridge-utils, bridge_ports all no longer works. One must manually list all interfaces to be bridged. Debian bug report filed.
PS: Luca Capello pointed out that Debian 10/Buster's Release Notes include migration instructions.
GRUB fine-tuning
A couple of years ago, I moved into a new flat that comes with RJ45 sockets wired for 10 Gigabit (but currently offering 1 Gigabit) Ethernet.
This also meant changing the settings on my router box for my new ISP.
I took this opportunity to review my router's other settings too. I'll be blogging about these over the next few posts.
GRUB fine-tuning
One thing that had been annoying me ever since Debian migrated to systemd as /sbin/init is that boot message verbosity hasn't been the same. Previously, the cmdline option quiet merely suppressed the kernel's output to the bootscreen, but left the daemon startup messages alone. Not anymore. Nowadays, quiet produces a blank screen.
After some googling, I found the solution to that:
GRUB_CMDLINE_LINUX_DEFAULT="noquiet loglevel=5"
The former restores daemon startup messages, while the later makes the kernel output only significant notices or more serious messages. On most of my hosts, it mostly reports inconsistencies in the ACPI configuration of the BIOS.
Another setting I find useful is a reboot delay in case a kernel panic happens:
GRUB_CMDLINE_LINUX="panic=15"
This gives me enough time to snap a picture of the screen output to attach to the bug report that will follow.
2017-12-29
Jackpot
2017-12-02
dbus, rsyslogd, systemd: Which one is the culprit?
This is a nasty one, since it also prevents performing a clean poweroff. That systemd-journald line about getting a timeout while attempting to connect to the Watchdog keeps on showing ad infinitum.
What am I missing?
2017-08-31
Firefox slow as HEL even after boosting RAM from 4GB to 16GB
2017-01-25
OpenWRT Backfire on WRT54GL signal strenght
One issue remains unanswered:
In GNOME shell's top panel and WiFi menu, the signal strength remains at 2 out of 4 bars. Given how the router sits only a few meters behind me, I would have expected much better signal strength than that.
Would anyone happen to know how to improve on these results? Thanks!
2016-08-07
Debian within a Windows partition?
2016-06-22
Batch photo manipulation via free software tools?
I have a need for batch-processing pictures. My requirements are fairly simple:
- Resize the image to fit Facebook's preferred 960 pixel box.
- Insert Copyright, Byline and Bylinetitle into the EXIF data.
- Optionally, paste my watermark onto a predefined corner of the image.
- Optionally, adjust the white balance.
- Rename the file according to a specific syntax.
- Save the result to a predefined folder.
Until recently, I was using Phatch to perform all of this. Unfortunately, it cannot edit the EXIF data of my current Lumix camera, whose JPEG it claims to be MPO. I am thus forced to look for other options. Ideally, I would do this via a script inside gThumb (which is my main photo editing software), but I cannot seem to find adequate documentation on how to achieve this.
I am thus very interested in hearing about other options to achieve the same result. Ideas, anyone?
2016-02-04
xf86-video-geode 2.11.18
Yesterday, I pushed out version 2.11.18 of the Geode X.Org driver. This is the driver used by the OLPC XO-1 and by a plethora of low-power desktops, micro notebooks and thin clients. This release mostly includes maintenance fixes of all sorts. Of noticeable interest is a fix for the long-standing issue that switching between X and a VT would result in a blank screen (this should probably be cherry-picked for distributions running earlier releases of this driver). Many thanks to Connor Behan for the fix!
Unfortunately, this driver still doesn't work with GNOME. On my testing host, launching GDM produces a blank screen. 'ps' and other tools show that GDM is running but there's no screen content; the screen remains pitch black. This issue doesn't happen with other display managers e.g. LightDM. Bug reports have been filed, additional information was provided, but the issue still hasn't been resolved.
Additionally, X server flat out crashes on Geode hosts running Linux kernels 4.2 or newer. 'xkbcomp' repeatedly fails to launch and X exits with a fatal error. Bug reports have been filed, but not reacted to. However, interestingly enough, X launches fine if my testing host is booted with earliers kernels, which might suggest what the actual cause of this particular bug might be:
Since kernel 4.2 entered Debian, the base level i386 kernel on Debian is now compiled for i686 (without PAE). Until now, the base level was i586. This essentially makes it pointless to build the Geode driver with GX2 support. It also means that older GX1 hardware won't be able to run Debian either, starting with the next stable release.
2016-01-31
Stupid Design: Facebook's Selling Something feature
Over these past few months, I've been going through my personal belongings to reduce them to the bare essentials – more-or-less following the rule "If I cannot remember that I had it, I probably don't need it" – with an explicit goal to make it easier for me to relocate in the near future.
Part of that iterative process has involved selling surplus items via Facebook groups. While I initially rejoiced at the invention of the new Selling Something feature, the more I use it, the more I end up cursing at the lack of thought that went into designing that feature:
For instance, in the feature's most recent implementation, it has become possible to post the same ad in several groups. Great idea, right? Actually, no. What this option does is post individual copies of that exact same ad in each group. Managed to sell a particular item? You'll have to sort through each and every duplicate post in each group to mark the item as sold. Need to edit the ad to lower the price or add requested information about the item? Same thing: go through each individual copy of the ad in each group. Seriously, Facebook? Who the fuck designed that senseless implementation?!
Here's a better implementation: centrally manage all items via the user's account preferences, and let the user tick checkboxes besides each item to decide which groups will see that particular item. Ditto whenever editing the ad's content or marking an item as sold; do everything via the user's account preferences. Rather than making the content group-centric, make it user-centric.
You're welcome.
2015-10-28
xf86-video-geode: Last call, dernier sévice
I guess that the time has finally come to admit that, as far as upstream development is concerned, the Geode X.Org driver is reaching retirement age:
While there have indeed been recent contributions by a number of developers to keep it compilable against recent X releases, the Geode driver has accumulated too much cruft from the Cyrix and NSC days, and it hasn't seen any active contribution from AMD in a long time. Besides, nowadays, Xserver pretty much assumes that its runs on an X driver that leverages its matching kernel driver and thus won't require root priviledges to launch. This isn't the case with the Geode driver, since it directly probes FBDEV and MSR, both of which reside in /dev and require root priviledges to access.
On Debian, as a stopgap measure, the package now Recommends a legacy wrapper that enforces operation as root. Meanwhile, other distributions are mercilessly droping all X drivers that don't leverage KMS. Basically, unless a miracle happens really quick, Geode will soon become unusable on X.
Back when AMD was still involved, a concensus had been reached that, since the Geode series doesn't offer any sort of advanced graphic capabilities, the most sensible option would indeed be to make a KMS driver and let Xserver use its generic modeline driver on top of that, then drop the Geode X driver entirely. Amazingly enough, someone did start working on a KMS driver for Geode LX, but it never made it as far as the Linux kernel tree (additionally, Gitorious seems to be down, but I have a copy of the driver's Git tree on hand, if anyone is interested). While I'll still be accepting and merging patches to the Geode X driver, our best long-term option would be to finalize the KMS driver and have it merged into Linux ASAP.
2015-05-20
xf86-video-geode 2.11.17
This morning, I pushed out version 2.11.17 of the Geode X.Org driver. This is the driver used by the OLPC XO-1 and by a plethora of low-power desktops, micro notebooks and thin clients. This is a minor release. It merges conditional support for the OpenBSD MSR device (Marc Ballmer, Matthieu Herrb), fixes a condition that prevents compiling on some embedded platforms (Brian A. Lloyd) and upgrades the code for X server 1.17 compatibility (Maarten Lankhorst).
Pending issues:
- toggle COM2 into DDC probing mode during driver initialization
- reset the DAC chip when exiting X and returning to vcons
- fix a rendering corner case with Libre Office
2015-03-23
This and That
I haven't blogged anything in months and figured that now might be a good time to get around that. Here it goes:
Free Software
While I occasionally upgrade the packaging of the software I maintain at Debian to keep up with best practices, my activity downsizing goes on. Simply put: I never had any ambition to become a Debian Developer. My involvement has always remained pragmatic and mostly from the perspective of packaging software that I found useful. Even then, my motivation for doing that keeps on dwindling into nothingness, because key pieces of software keep on breaking, whenever someone upstream decides to reinvent the wheel.
For instance, GNOME no longer works at all on Geode chipsets and it barely works on Nouveau chipsets. This happened as soon as GNOME 3.14 was uploaded into unstable, right before the freeze started. Then again, I wouldn't jump to a conclusion that GNOME itself might be at fault, since Plymouth also stopped working on the same two video platforms at the same time. For all we know, this could be caused by some changes in the X.Org server code. Bugs were filed, additional information was provided, but no fix has taken place.
Given how Geode and Nouveau represent 80% of my hardware investment (my Intel laptop being the sole exception), it essentially means that the upcoming Debian "stable" is useless for me. Now try and remain motivated, even just as a mere Free Software end-user. At this point, I'm done.
Politics
Finland is holding national elections this April. I still have no idea who I'll vote for this time. The guy I voted for last time has become a career politician with an inflated ego and zero connection to the average Finn's aspirations and worries. Meanwhile, two friends are standing as candidates: one who is a razor-sharp fact finder and who is a proven pragmatic decision-maker, but whose values are slightly off with mine, and one whose actions come straight from the heart but whose concept of today's Finnish reality leaves a lot to be desired.
National Defence
There's been a lot of recent articles about how former hardware and locations of the Finnish defence forces and border guards have been sold, often for peanuts, to Russian interests. In some cases, we're only talking about buildings formerly used for on-site staff accommodations. In other cases, former patrol boats and navy harbours changed hands. Now, to top it all, it appears that our north-western neighbour, Norway, has sold a former submarine base to German investors who, in turn, leased it to – you guessed it – Russian interests.
Looking at Russian actions in Ukraine, I cannot help but feel great concern that strategic locations are falling into potentially dangerous hands. Just seeing the picture of a former navy harbour with a handful of patrol boats on standby, right on the Finnish coastline, half-way between Helsinki and Turku, was a sobering experience. While the whole idea of shooting at people – even invading armies – gives me the creeps, at this point, I cannot help but start pondering whether defending this country might in fact be an occupation worth training for.
Employment
It has now been 6 years since I held my last dayjob. Since then, the only thing I've found is an unpaid training in the national bureaucracy. I've also freelanced as an actor and model, but that barely brought me pocket change, if even that. Seeing my face on posters advertising a movie I participated in last year was indeed nice, getting some media attention in connection to that too, but it hasn't lead to additional gigs. As far as I can tell, this was just my Warholian 15 minutes of fame.
However, there's a larger issue at stake. Newspapers recently published an employment statistics map for Nordic countries and the truth couldn't be more bleak: while Norway and Sweden's employment figures are nearly spotless for almost every province, those of Finland are – save for a couple of mildly successful provinces – outright catastrophic. Given this and despite feeling relatively happy living in Finland and having developed a will to defend this country from an eventual Russian assault, I've come to the conclusion that I would be better off going West, with a strong preference for Norway.
Now, the main question is, doing what? 6 years later, I have strong doubts that I would be remotely considered for any high-tech job. Besides, come to think of it, I wouldn't want any new office job. Off the top of my head, my idea of a cool job that would allow me to stay physically fit would be working as a tourist guide in Lapland. However, if Norway is anything like Finland, someone probably needs a dozen of permits of all sorts (first aid certification, C or even D class driving license, college degree in tourism, etc.) that I cannot afford. What then?
2014-12-02
GNOME is destroying the whole GTK universe
When GNOME 3.14 components were uploaded into Debian (just a few days before the Jessie freeze started), GNOME stopped working on two video platforms: Geode (xf86-video-geode) and NVIDIA (xf86-video-nouveau). On Geode, GDM launches into a black screen. On NVIDIA, GDM launches as expected, but then the GNOME session itself barfs with the dreaded "Oh No! Something went wrong. [Logout]" dialog during session initialization. Basically, components in GNOME have become too tightly dependent upon some video driver features. Thinking out loud, I figured that reverting to a desktop environment that is based upon GTK+3, without GNOME's bells and whistles, would at least restore operation on my NVDIA hosts. Alas, it does not: Cinnamon, too, barfs during session initialization. Great. Now what?
2014-11-09
On the Joey debacle
Looking back, I cannot think of a single moment when Joey wouldn't have shown the utmost patience and courtesy towards anyone involved in Debian, even towards mere users filing sometimes senseless bug reports against his packages. From this perspective, I cannot help but venture that whatever chain of events lead to Joey's decisions essentially means one thing: Debian must have seriously gotten off-course for someone who has been involved for so long to call it quits. As for the current situation at hands, while I admittedly haven't followed too closely who or what caused Joey's decision, I nonetheless cannot help but feel that whoever pushed Joey's buttons so hard as to make him decide to leave Debian ought to be the one(s) kicked out of Debian instead.
2014-11-07
HEL has just frozen over. Wait. No. Debian did.
sudo apt-get update && \ sudo apt-get install apt dpkg locales && \ sudo apt-get --purge dist-upgrade && \ sudo apt-get --fix-policy install && \ sudo apt-get --purge autoremove $(deborphan --guess-all)
I guess I'll be busy filing bug reports for the next few hours. Wish me (and each faulty package's maintainer) luck!
PS: Apparently, so many aspects of Debian have become dependent upon GPG features that merely upgrading APT, DPKG and libc6+locales is no longer enough. One must also upgrade gnupg and gnupg2. Thus, the second element of the above recipe has become:
sudo apt-get install apt dpkg gnupg gnupg2 locales && \
Hopefully, APT's dist-upgrade command already knows that these must be upgraded first...
PPS: Hosts running Network-Manager cannot be upgraded remotely, because Network-Manager insists upon killing the network connection and the SSH daemon with it, when its turn comes to get upgraded.