qemu-img convert Kali-Linux-2021.3-vmware-amd64.vmdk ../kaliAfter converting it the file was 500M smaller than the VMWare files (10.2 vs 10.7G). Probably the Kali distribution file could be reduced in size by converting it to raw and then back to VMWare format. The Kali VMWare image is compressed with 7zip which has a good compression ratio, I waited almost 90 minutes for zstd to compress it with -19 and the result was 12% larger than the 7zip file. VMWare apparently likes to use an emulated SCSI controller, I spent some time trying to get that going in KVM. Apparently recent versions of QEMU changed the way this works and therefore older web pages aren t helpful. Also allegedly the SCSI emulation is buggy and unreliable (but I didn t manage to get it going so can t be sure). It turns out that the VM is configured to work with the virtio interface, the initramfs.conf has the configuration option MODULES=most which makes it boot on all common configurations (good work by the initramfs-tools maintainers). The image works well with the Spice display interface, so it doesn t capture my mouse, the window for the VM works the same way as other windows on my desktop and doesn t capture the mouse cursor. I don t know if this level of Spice integration is in Debian now, last time I tested it didn t work that way. I also downloaded Metasploitable [2] which is a VM image designed to be full of security flaws for testing the tools that are in Kali. Again it worked nicely after converting from VMWare to raw format. One thing to note about Metasploitable is that you must not make it available on the public Internet. My home network has NAT for IPv4 but all systems get public IPv6 addresses. It s usually nice that those things just work on VMs but not for this. So I added an iptables command to block IPv6 to /etc/rc.local. Conclusion Installing VMs for both these distributions was quite easy. Most of my time was spent downloading from a slow server, trying to get SCSI emulation working, working out how to convert image files, and testing different compression options. The time spent doing stuff once I knew what to do was very small. Kali has zsh as the default shell, it s quite nice. I ve been happy with bash for decades, but I might end up trying zsh out on other machines.
Garbage collecting with podman system prune.
Tells me it freed 20GB when it seems to have freed 4GB. Wondering where that discrepancy comes from.
186. This version includes the following changes:
[ Chris Lamb ]
* Don't call close_archive when garbage-collecting Archive instances unless
open_archive returned successfully. This prevents, amongst others, an
AttributeError traceback due to PGPContainer's cleanup routines assuming
that its temporary directory had been created.
(Closes: reproducible-builds/diffoscope#276)
* Ensure that the string "RPM archives" exists in the package description,
regardless of whether python3-rpm is installed or not at build time.
[ Jean-Romain Garnier ]
* Fix the LVM Macho comparator for non-x86-64 architectures.
Armadillo is a powerful and expressive C++ template library for linear algebra aiming towards a good balance between speed and ease of use with a syntax deliberately close to a Matlab. RcppArmadillo integrates this library with the R environment and language and is widely used by (currently) 912 other packages on CRAN.
This new release brings us Armadillo 10.7.0 released this morning by Conrad. Leading up to this were three runs of reverse dependencies the first of which uncovered the need for a small PR for subview_cols support which Conrad kindly supplied.
The full set of changes follows. We include the last interim release (sent as usual to the drat repo) as well.
Courtesy of my CRANberries, there is a diffstat report relative to previous release. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page. If you like this or other open-source work I do, you can sponsor me at GitHub.Changes in RcppArmadillo version 0.10.7.0.0 (2021-09-30)
- Upgraded to Armadillo release 10.7.0 (Entropy Maximizer)
- faster handling of submatrix views accessed by
X.cols(first_col,last_col)- faster handling of element-wise
min()andmax()in compound expressions- expanded
solve()withsolve_opts::force_approxoption to force use of the approximate solverChanges in RcppArmadillo version 0.10.6.2.0 (2021-08-05)
- Upgraded to Armadillo release 10.6.2 (Keep Calm)
- fix incorrect use of
constexprfor handling fixed-size matrices and vectors- improved documentation
- GitHub- and drat-only release
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
Debian Reunion Hamburg 2021 is almost over...
The Debian Reunion Hamburg 2021 is almost over
now, half the attendees have already left for Regensburg, while five remaining people are still busy here, though
tonight there will be two concerts at the venue, plus some lovely food and more. Together with the day trip tomorrow
(involving lots of water but hopefully not from above...) I don't expect much more work to be done, so that I
feel comfortable publishing the following statistics now, even though I expect some more work will be done while
travelling back or due to renewed energy from the event! So I might update these numbers later 
Together we did:
Debian Reunion / MiniDebConf Hamburg 2022 - save the date, almost!
Thus I think we should have another Debian event at Fux in 2022, and after checking suitable free dates
with the venue I think what could work out is an event from Monday May 23rd until Sunday May 29th 2022. What do you think?
For now these dates are preliminary. If you know any reasons why these dates could be less than optimal for such
an event, please let me know. Assuming there's no feedback indicating this is a bad idea, the dates shall be
finalized by November 1st 2021. Obviously assuming having physical events is still and again a thing! 
[warning] <0.368.0>@ejabberd_pkix:log_warnings/1:393 Invalid certificate in /etc/letsencrypt.sh/certs/buildd.net/fullchain.pem: at line 37: certificate is no longer valid as its expiration date has passed[warning] <0.18328.2>@ejabberd_s2s_out:process_closed/2:157 Failed to establish outbound s2s connection nerdica.net -> forum.friendi.ca: Stream closed by peer: Your server's certificate is invalid, expired, or not trusted by forum.friendi.ca (not-authorized); bouncing for 237 secondsWhen checking out with some online tools like SSLlabs or XMPP.net the result was strange, because SSLlabs reported everything was ok while XMPP.net was showing the chain with X3 and D3 certs as having a short term validity of a few days:
update-ca-certificates and ejabberdctl restart (instead of just ejabberdctl reload-config). UPDATE: be sure to use dpkg-reconfigure ca-certificates to uncheck the DST Root X3 cert (and others if necessary) before renewing the certs or running update-ca-certificates. Otherwise the update will bring in the expired cert again.
Currently I see at least two other XMPP domains in my server logs having certicate issues and in some MUCs there are reports of other domains as well.
Disclaimer: Again: this helped me in my case. I don t know if this is a bug in Ejabberd or if this procedure will help you in your case nor if this is the proper solution. But maybe my story will help you solving your issue if you experience SSL certs issues in the last few days, especially now that the R3 cert has already expired and the X3 cert following in a few hours.
My home automation setup has been fairly static recently; it does what we need and generally works fine. One area I think could be better is controlling it; we have access Home Assistant on our phones, and the Alexa downstairs can control things, but there are no smart assistants upstairs and sometimes it would be nice to just push a button to turn on the light rather than having to get my phone out. Thanks to the fact the UK generally doesn t have neutral wire in wall switches that means looking at something battery powered. Which means wifi based devices are a poor choice, and it s necessary to look at something lower power like Zigbee or Z-Wave.
Zigbee seems like the better choice; it s a more open standard and there are generally more devices easily available from what I ve seen (e.g. Philips Hue and IKEA TR DFRI). So I bought a couple of Xiaomi Mi Smart Home Wireless Switches, and a CC2530 module and then ignored it for the best part of a year. Finally I got around to flashing the Z-Stack firmware that Koen Kanters kindly provides. (Insert rant about hardware manufacturers that require pay-for tool chains. The CC2530 is even worse because it s 8051 based, so SDCC should be able to compile for it, but the TI Zigbee libraries are only available in a format suitable for IAR s embedded workbench.)
Flashing the CC2530 is a bit of faff. I ended up using the CCLib fork by Stephan Hadinger which supports the ESP8266. The nice thing about the CC2530 module is it has 2.54mm pitch pins so nice and easy to jumper up. It then needs a USB/serial dongle to connect it up to a suitable machine, where I ran Zigbee2MQTT. This scares me a bit, because it s a bunch of node.js pulling in a chunk of stuff off npm. On the flip side, it Just Works and I was able to pair the Xiaomi button with the device and see MQTT messages that I could then use with Home Assistant. So of course I tore down that setup and went and ordered a CC2531 (the variant with USB as part of the chip). The idea here was my test setup was upstairs with my laptop, and I wanted something hooked up in a more permanent fashion.
Once the CC2531 arrived I got distracted writing support for the Desk Viking to support CCLib (and modified it a bit for Python3 and some speed ups). I flashed the dongle up with the Z-Stack Home 1.2 (default) firmware, and plugged it into the house server. At this point I more closely investigated what Home Assistant had to offer in terms of Zigbee integration. It turns out the ZHA integration has support for the ZNP protocol that the TI devices speak (I m reasonably sure it didn t when I first looked some time ago), so that seemed like a better option than adding the MQTT layer in the middle.
I hit some complexity passing the dongle (which turns up as /dev/ttyACM0) through to the Home Assistant container. First I needed an override file in /etc/systemd/nspawn/hass.nspawn:
[Files]
Bind=/dev/ttyACM0:/dev/zigbee
[Network]
VirtualEthernet=true
udev rule on the host to change the ownership of the device file so the root user and dialout group in the container could see it was also necessary, so into /etc/udev/rules.d/70-persistent-serial.rules went:
# Zigbee for HASS
SUBSYSTEM=="tty", ATTRS idVendor =="0451", ATTRS idProduct =="16a8", SYMLINK+="zigbee", \
MODE="660", OWNER="1321926676", GROUP="1321926676"
PrivateDevices=true to PrivateDevices=false in the home-assistant.service file (which took me a while to figure out; yay for locking things down and then needing to use those locked down things).
Finally I added the hass user to the dialout group. At that point I was able to go and add the integration with Home Assistant, and add the button as a new device. Excellent. I did find I needed a newer version of Home Assistant to get support for the button, however. I was still on 2021.1.5 due to upstream dropping support for Python 3.7 and not being prepared to upgrade to Debian 11 until it was actually released, so the version of zha-quirks didn t have the correct info. Upgrading to Home Assistant 2021.8.7 sorted that out.
There was another slight problem. Range. Really I want to use the button upstairs. The server is downstairs, and most of my internal walls are brick. The solution turned out to be a TR DFRI socket, which replaced the existing ESP8266 wifi socket controlling the stair lights. That was close enough to the server to have a decent signal, and it acts as a Zigbee router so provides a strong enough signal for devices upstairs. The normal approach seems to be to have a lot of Zigbee light bulbs, but I have mostly kept overhead lights as uncontrolled - we don t use them day to day and it provides a nice fallback if the home automation has issues.
Of course installing Zigbee for a single button would seem to be a bit pointless. So I ordered up a Sonoff door sensor to put on the front door (much smaller than expected - those white boxes on the door are it in the picture above). And I have a 4 gang wireless switch ordered to go on the landing wall upstairs.
Now I ve got a Zigbee setup there are a few more things I m thinking of adding, where wifi isn t an option due to the need for battery operation (monitoring the external gas meter springs to mind). The CC2530 probably isn t suitable for my needs, as I ll need to write some custom code to handle the bits I want, but there do seem to be some ARM based devices which might well prove suitable
Debian Reunion Hamburg 2021, klein aber fein / small but beautiful
So the Debian Reunion Hamburg 2021 has been going on for not yet 48h now and it appears people are having fun, enjoying discussions between fellow Debian people and getting some stuff done as well. I guess I'll write some more about it once the event is over...
Sharing android screens...
For now I just want to share one little gem I learned about yesterday on the hallway track:
$ sudo apt install scrcpy
$ scrcpy
| Publisher: | Duke University Press |
| Copyright: | 2011 |
| ISBN: | 0-8223-5112-9 |
| Format: | Kindle |
| Pages: | 304 |
The lack of interest in representing the daily grind of work routines in various forms of popular culture is perhaps understandable, as is the tendency among cultural critics to focus on the animation and meaningfulness of commodities rather than the eclipse of laboring activity that Marx identifies as the source of their fetishization (Marx 1976, 164-65). The preference for a level of abstraction that tends not to register either the qualitative dimensions or the hierarchical relations of work can also account for its relative neglect in the field of mainstream economics. But the lack of attention to the lived experiences and political textures of work within political theory would seem to be another matter. Indeed, political theorists tend to be more interested in our lives as citizens and noncitizens, legal subjects and bearers of rights, consumers and spectators, religious devotees and family members, than in our daily lives as workers.This is only a quarter of a paragraph, and the entire book is written like this. I don't mind the occasional use of longer words for their precise meanings ("qualitative," "hierarchical") and can tolerate the academic habit of inserting mostly unnecessary citations. I have less patience with the meandering and complex sentences, excessive hedge words ("perhaps," "seem to be," "tend to be"), unnecessarily indirect phrasing ("can also account for" instead of "explains"), or obscure terms that are unnecessary to the sentence (what is "animation of commodities"?). And please have mercy and throw a reader some paragraph breaks. The writing style means substantial unnecessary effort for the reader, which is why it took me six months to read this book. It stalled all of my non-work non-fiction reading and I'm not sure it was worth the effort. That's unfortunate, because there were several important ideas in here that were new to me. The first was the overview of the "wages for housework" movement, which I had not previously heard of. It started from the common feminist position that traditional "women's work" is undervalued and advocated taking the next logical step of giving it equality with paid work by making it paid work. This was not successful, obviously, although the increasing prevalence of day care and cleaning services has made it partly true within certain economic classes in an odd and more capitalist way. While I, like Weeks, am dubious this was the right remedy, the observation that household work is essential to support capitalist activity but is unmeasured by GDP and often uncompensated both economically and socially has only become more accurate since the 1970s. Weeks argues that the usefulness of this movement should not be judged by its lack of success in achieving its demands, which leads to the second interesting point: the role of utopian demands in reframing and expanding a discussion. I normally judge a political demand on its effectiveness at convincing others to grant that demand, by which standard many activist campaigns (such as wages for housework) are unsuccessful. Weeks points out that making a utopian demand changes the way the person making the demand perceives the world, and this can have value even if the demand will never be granted. For example, to demand wages for housework requires rethinking how work is defined, what activities are compensated by the economic system, how such wages would be paid, and the implications for domestic social structures, among other things. That, in turn, helps in questioning assumptions and understanding more about how existing society sustains itself. Similarly, even if a utopian demand is never granted by society at large, forcing it to be rebutted can produce the same movement in thinking in others. In order to rebut a demand, one has to take it seriously and mount a defense of the premises that would allow one to rebut it. That can open a path to discussing and questioning those premises, which can have long-term persuasive power apart from the specific utopian demand. It's a similar concept as the Overton Window, but with more nuance: the idea isn't solely to move the perceived range of accepted discussion, but to force society to examine its assumptions and premises well enough to defend them, or possibly discover they're harder to defend than one might have thought. Weeks applies this principle to universal basic income, as a utopian demand that questions the premise that work should be central to personal identity. I kept thinking of the Black Lives Matter movement and the demand to abolish the police, which (at least in popular discussion) is a more recent example than this book but follows many of the same principles. The demand itself is unlikely to be met, but to rebut it requires defending the existence and nature of the police. That in turn leads to questions about the effectiveness of policing, such as clearance rates (which are far lower than one might have assumed). Many more examples came to mind. I've had that experience of discovering problems with my assumptions I'd never considered when debating others, but had not previously linked it with the merits of making demands that may be politically infeasible. The book closes with an interesting discussion of the types of utopias, starting from the closed utopia in the style of Thomas More in which the author sets up an ideal society. Weeks points out that this sort of utopia tends to collapse with the first impossibility or inconsistency the reader notices. The next step is utopias that acknowledge their own limitations and problems, which are more engaging (she cites Le Guin's The Dispossessed). More conditional than that is the utopian manifesto, which only addresses part of society. The least comprehensive and the most open is the utopian demand, such as wages for housework or universal basic income, which asks for a specific piece of utopia while intentionally leaving unspecified the rest of the society that could achieve it. The demand leaves room to maneuver; one can discuss possible improvements to society that would approach that utopian goal without committing to a single approach. I wish this book were better-written and easier to read, since as it stands I can't recommend it. There were large sections that I read but didn't have the mental energy to fully decipher or retain, such as the extended discussion of Ernst Bloch and Friedrich Nietzsche in the context of utopias. But that way of thinking about utopian demands and their merits for both the people making them and for those rebutting them, even if they're not politically feasible, will stick with me. Rating: 5 out of 10
Wrote a HTML ping-like something.
Uses fetch to fetch a page and measures time until 404 returns to js.
Here's my http ping.
The challenge was writing code to calculate standard
deviation in multiple languages and making sure it matched,
d'oh.
Release 0.6.28 of the digest package arrived at CRAN earlier today, and has already been uploaded Debian as well.
digest creates hash digests of arbitrary R objects (using the md5, sha-1, sha-256, sha-512, crc32, xxhash32, xxhash64, murmur32, spookyhash, and blake3 algorithms) permitting easy comparison of R language objects. It is a mature and widely-used as many tasks may involve caching of objects for which it provides convenient general-purpose hash key generation.
This release comes eleven months after the previous releases and rounds out a number of corners. Continuous Integration was updated using r-ci. Several contribututors help with a small fix applied to avoid unaligned reads, a rewording for a help page as well as windows path encoding for in the vectorised use case.
My CRANberries provides the usual summary of changes to the previous version. For questions or comments use the issue tracker off the GitHub repo.
If you like this or other open-source work I do, you can now sponsor me at GitHub. For the first year, GitHub will match your contributions.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
prrd facilitates the parallel running [of] reverse dependency [checks] when preparing R packages. It is used extensively for Rcpp, RcppArmadillo, RcppEigen, BH, and others.
The key idea of prrd is simple, and described in some more detail on its webpage and its GitHub repo. Reverse dependency checks are an important part of package development that is easily done in a (serial) loop. But these checks are also generally embarassingly parallel as there is no or little interdependency between them (besides maybe shared build depedencies). See the (dated) screenshot (running six parallel workers, arranged in a split byobu session).
This release brings some new features I used of late when testing and re-testing reverse dependencies for Rcpp. Enqueuing jobs can now consider the most recent prior job queue file. This allows us to find new packages that were not part of the previous runs. We added a second toggle to also add those packages who failed in the previous run. Finally, the dequeue interface allows to specify a date (rather than defaulting to the current date, useful for long-running jobs or restarts).
The release is summarised in the NEWS entry:
My CRANberries provides the usual summary of changes to the previous version. See the aforementioned webpage and its repo for details. For more questions or comments use the issue tracker off the GitHub repo. If you like this or other open-source work I do, you can now sponsor me at GitHub.Changes in prrd version 0.0.5 (2021-09-22)
- Some remaing http URLs were changed to https.
- The
dequeueJobsscript has a new argument date to help specify a queue file.- The
enqueueJobscan now compute just a delta of (new) packages relative to a given prior queuefile and run.- When running in delta mode, previously failed packages can also be selected.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
Three years ago, I organized a fun and most interesting colloquium at
Facultad de Ingenier a, UNAM about
privacy and anonymity online.
I would have loved to share this earlier with the world, but The
university s processes are quite slow (and, to be fair, I also took
quite a bit of time to push things through). But today, I m finally
happy to share the result of that work with all of you. We managed to
get 11 of the talks in the colloquium as articles. The back-cover text
reads (in Spanish):
We live in an era where human to human interactions are more and more often mediated by technology. This, of course, means everything leaves a digital trail, a trail that can follow and us relentlessly. Privacy is recognized, however, as a human right although one that is under growing threats. Anonymity is the best tool to secure it. Throughout history, clear steps have been taken legally, technically and technologically to defend it. Various studies point out this is not only a known issue for the network's users, but that a large majority has searched for alternatives to protect their communications' privacy. This book stems from a colloquium held by *Laboratorio de Investigaci n y Desarrollo de Software Libre* (LIDSOL) of Facultad de Ingenier a, UNAM, towards the end of 2018, where we invited experts from disciplines so far apart as law and systems development, psychology and economics, to contribute with their experiences to a transdisciplinary vision.If this interests you, you can get the book at our institutional repository. Oh, and What about the birds? In Spanish (Mexican only?), we have a saying, hay p jaros en el alambre , meaning watch your words, as uninvited people might be listening, as birds resting over the wires over which phone calls used to be made (back in the day where wiretapping was that easy). I found the design proposed by our editor ingenious and very fitting for our topic!
ErrorKind, which aims to categorise OS errors
in a portable way.
Audiences for this post
ErrorKinds are part of the Rust standard
library means that to get this right, you don't need to delve down
and get the actual underlying operating system error number, and
write separate code for each platform you want to support. You can
check whether the error is ErrorKind::NotFound
(or whatever).
Because ErrorKind is so important in many Rust APIs,
some code which isn't really doing an OS call can still have to
provide an ErrorKind. For this purpose, Rust provides
a special category ErrorKind::Other, which doesn't
correspond to any particular OS error.
Rust's stability aims and approach
Another thing Rust tries to do is keep existing code working.
More specifically, Rust tries to:
io::ErrorKind
(Very briefly:)
When you have a value which is an io::ErrorKind, you
can compare it with specific values:
if error.kind() == ErrorKind::NotFound ...But in Rust it's more usual to write something like this (which you can read like a
switch statement):
match error.kind()
ErrorKind::NotFound => use_default_configuration(),
_ => panic!("could not read config file : ", &file, &error),
Here _ means "anything else".
Rust insists that match statements are
exhaustive, meaning that each one covers all the possibilities.
So if you left out the line with the _, it wouldn't
compile.
Rust enums can also be marked non_exhaustive, which is
a declaration by the API designer that they plan to add more kinds.
This has been done for ErrorKind, so the _
is mandatory, even if you write out all the possibilities that exist
right now: this ensures that if new ErrorKinds appear,
they won't stop your code compiling.
Improving the error categorisation
The set of error categories stabilised in Rust 1.0 was too small.
It missed many important kinds of error. This makes writing
error-handling code awkward. In any case, we expect to add new
error categories occasionally. I set about trying to improve this
by proposing
new ErrorKinds. This obviously needed considerable
community review, which is why it took about 9 months.
The trouble with Other and tests
Rust has to assign an ErrorKind to every OS error,
even ones it doesn't really know about.
Until recently, it mapped all errors it didn't understand to
ErrorKind::Other - reusing the category for "not an OS
error at all".
Serious people who write serious code like to have serious tests.
In particular, testing error conditions is really important. For
example, you might want to test your program's handling of disk
full, to make sure it didn't crash, or corrupt files. You would set
up some contraption that would simulate a full disk. And then, in
your tests, you might check that the error was correct.
But until very recently (still now, in Stable Rust), there was
no ErrorKind::StorageFull. You would
get ErrorKind::Other. If you were diligent you would
dig out the OS error code (and check for ENOSPC on
Unix, corresponding Windows errors, etc.). But that's tiresome.
The more obvious thing to do is to check that the kind
is Other.
Obvious but wrong.
ErrorKind is non_exhaustive,
implying that more error kinds will appears, and, naturally, these
would more finely categorise previously-Other OS errors.
Unfortunately, the documentation note
Errors that arewas only added in May 2020. So the wrongness of the "obvious" approach was, itself, not very obvious. And even with that docs note, there was no compiler warning or anything. The unfortunate result is that there is a body of code out there in the world which might break any time an error that was previouslyOthernow may move to a different or a newErrorKindvariant in the future.
Other becomes properly categorised.
Furthermore, there was nothing stopping new people writing new
obvious-but-wrong code.
Chosen solution: Uncategorized
The Rust developers wanted an engineered safeguard against the bug of
assuming that a particular error shows up as Other.
They chose the following solution:
There is now a new ErrorKind::Uncategorized which is
now used for all OS errors for which there isn't a more specific
categorisation. The fallback translation of unknown errors was
changed from Other to Uncategorised.
This is de jure justified by the fact that this enum has always been
marked non_exhaustive. But in practice because this
bug wasn't previously detected, there is such code in the wild.
That code now breaks (usually, in the form of failing test cases).
Usually when Rust starts to detect a particular programming error,
it is reported as a new warning, which doesn't break anything. But
that's not possible here, because this is a behavioural change.
The new ErrorKind::Uncategorized is
marked unstable. This makes it impossible to write
code on Stable Rust which insists that an error comes out
as Uncategorized. So, one cannot now write code that
will break when new ErrorKinds are added.
That's the intended effect.
The downside is that this does break old code, and, worse,
it is not as clear as it should be what the fixed code looks like.
Alternatives considered and rejected by the Rust developers
Not adding more ErrorKinds
This was not tenable. The existing set is already too small, and
error categorisation is in any case expected to improve over time.
Just adding ErrorKinds as had been done before
This would mean occasionally breaking test cases (or, possibly,
production code) when an error that was
previously Other becomes categorised. The broken code
would have been "obvious", but de jure wrong, just as it is now,
So this option amounts to expecting this broken code to continue
to be written and continuing to break it occasionally.
Somehow using Rust's Edition system
The Rust language has a system to allow language evolution,
where code declares its Edition (2015, 2018, 2021).
Code from multiple editions can be combined, so that
the ecosystem can upgrade gradually.
It's not clear how this could be used for ErrorKind, though.
Errors have to be passed between code with different editions.
If those different editions had different categorisations, the
resulting programs would have incoherent and broken error handling.
Also some of the schemes for making this change would mean that new
ErrorKinds could only be stabilised about once every 3
years, which is far too slow.
How to fix code broken by this change
Most main-line error handling code already has a fallback case for
unknown errors. Simply replacing any occurrence
of Other with _ is right.
How to fix thorough tests
The tricky problem is tests. Typically, a thorough test case wants
to check that the error is "precisely as expected" (as far as the
test can tell). Now that unknown errors come out as an
unstable Uncategorized variant that's not so easy. If
the test is expecting an error that is currently not categorised,
you want to write code that says "if the error is any of the
recognised kinds, call it a test failure".
What does "any of the recognised kinds" mean here ? It doesn't
meany any of the kinds recognised by the version of the Rust
stdlib that is actually in use. That set might get bigger.
When the test is compiled and run later, perhaps years later, the
error in this test case might indeed be categorised. What you
actually mean is "the error must not be any of the kinds which
existed when the test was written".
IMO therefore the right solution for such a test case is to cut and
paste the current list of stable ErrorKinds into your
code. This will seem wrong at first glance, because the list in
your code and in Rust can get out of step. But when they do get out
of step you want your version, not the stdlib's. So freezing the
list at a point in time is precisely right.
You probably only want to maintain one copy of this list, so put it
somewhere central in your codebase's test support machinery.
Periodically, you can update the list deliberately - and fix any
resulting test failures.
Unfortunately this approach is not suggested by the documentation.
In theory you could work all this out yourself from first
principles, given even the situation prior to May 2020, but it seems
unlikely that many people have done so. In particular, cutting and
pasting the list of recognised errors would seem very unnatural.
Conclusions
This was not an easy problem to solve well.
I think Rust has done a plausible job given the various constraints,
and the result is technically good.
It is a shame that this change to make the error handling stability
more correct caused the most trouble for the most careful people who
write the most thorough tests.
I also think the docs could be improved.
edited shortly after posting, and again 2021-09-22 16:11 UTC, to fix HTML slips
The release of TeX Live 2021 is already half a year away, but due to the delay of waiting for Debian/Bullseye release, we haven t updated TeX Live in Debian for quite some time. But the waiting is over, today I uploaded the first packages of TeX Live 2021 to unstable.
All the changes listed in the upstream release blog apply also to the Debian packages.
I expect a few hiccups, but it is good to see it out of the door finally.
Enjoy.
Last week has seen the release of the first beta of Plasma 5.23 Anniversary Edition. Work behind the scenes to get this release as soon as possible into Debian has progressed well.
Starting with today, we provide binaries of Plasma 5.23 for Debian stable (bullseye), testing, and unstable, in each case for three architectures: amd64, i386, and aarch64.
To test the current beta, please add
deb https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/plasma523/DISTRIBUTION/ ./
to your apt sources (replacing DISTRIBUTION with one of Debian_11 (for Bullseye), Debian_Testing, or Debian_Unstable). For further details see this blog.
Warning
This is a beta release, and let me recall the warning from the upstream release announcement:
DISCLAIMER: This is beta software and is released for testing purposes. You are advised to NOT use Plasma 25th Anniversary Edition Beta in a production environment or as your daily desktop. If you do install Plasma 25th Anniversary Edition Beta, you must be prepared to encounter (and report to the creators) bugs that may interfere with your day-to-day use of your computer. https://kde.org/announcements/plasma/5/5.22.90/Enjoy, and please report bugs!
Next.