Forever and a Day is a coda to Haley Cass's self-published sapphic
romance novel Those Who Wait. There is
no point in reading it unless you have already read and enjoyed the full
book and wanted more of a denouement.
Given that Those Who Wait is a romance novel, it is definitionally
not a spoiler to reveal that Sutton and Charlotte ended up together. This
novella is seven scenes sketching out the next few years of their lives,
interspersed with press clippings and social media commentary. These tie
up loose ends, give the characters a bit more time together, throw in one
more conflict and resolution, add one more sex scene, and stick a few
exclamation points after the happily ever after.
I am the sort of person who likes long denouements in stories, so I'm the
target audience for this sort of sequel that's essentially additional
chapters to the book. (The funniest version of this I've read is
Jacqueline Carey's Saints Astray.) They
are usually not great literature, since there are good reasons for not
including these chapters in the book. That is exactly what this is: a few
more chapters of the characters being happy, entirely forgettable, and of
interest only to people who want that.
Cass does try to introduce a bit of a plot via some light family conflict,
which was sweet and mostly worked, and some conflict over having children,
which was very stereotyped and which I did not enjoy as much. I thought
the earlier chapters of this novella were the stronger ones, although I do
have to give the characters credit in the later chapters for working
through conflict in a mature and fairly reasonable way. It does help,
though, when the conflict is entirely resolved by one character being
right and the other character being happily wrong. That's character
conflict on easy mode.
I was happy to see that Sutton got a career, although as in the novel I
wish Cass had put some more effort into describing Sutton's efforts in
building that career. The details are maddeningly vague, which admittedly
matches the maddeningly vague description of Charlotte's politics but
which left me unsatisfied.
Charlotte's political career continues to be pure wish fulfillment in the
most utterly superficial and trivialized way, and it bothered me even more
in the novella than it did in the novel. We still have absolutely no idea
what she stands for, what she wants to accomplish, and why anyone would
vote for her, and yet we get endless soft-focus paeans to how wonderful
she will be for the country. Her opponents are similarly vague to the
point that the stereotypes Cass uses to signal their inferiority to
Charlotte are a little suspect.
I'm more critical of this in 2025 than I would have been in 2015 because
the last ten years have made clear the amount of damage an absolute
refusal to stand for anything except hazy bromides causes, and I probably
shouldn't be this annoyed that Cass chose to vaguely gesture towards
progressive liberalism without muddying her romance denouement with a
concrete political debate. But, just, gah. I found the last chapter
intensely annoying, in part because the narrative of that chapter was too
cliched and trite to sufficiently distract me from the bad taste of the
cotton-candy politics.
Other than that, this was minor, sweet, and forgettable. If you want
another few chapters of an already long novel, this delivers exactly what
you would expect. If the novel was plenty, nothing about this novella is
going to change your mind and you can safely skip it. I really liked the
scene between Charlotte and Sutton's mom, though, and I'm glad I read the
novella just for that.
Rating: 6 out of 10
Here s my monthly but brief update about the activities I ve done in the FOSS world.
Debian
Whilst I didn t get a chance to do much, here are still a few things that I worked on:
Did a few sessions with the new DFSG team to help kickstart things, et al.
Assited a few folks in getting their patches submitted via Salsa.
Mentoring for newcomers.
Moderation of -project mailing list.
Ubuntu
I joined Canonical to work on Ubuntu full-time back in February 2021.
Whilst I can t give a full, detailed list of things I did, here s a quick TL;DR of what I did:
wordpress: There were multiple vulnerabilities reported in Wordpress, leading to Sent Data & Cross-site Scripting.
[bookworm]: Roberto rightly pointed out that the upload to bookworm hadn t gone through last month, so I re-uploaded wordpress/6.1.9+dfsg1-0+deb12u1 to bookworm-security.
ruby-rack: There were multiple vulnerabilities reported in Rack, leading to DoS (memory exhaustion) and proxy bypass.
[ELTS]: Last month I had backported fixes for CVE-2025-46727 & CVE-2025-32441 to buster and stretch but the other backports were being a bit tricky due to really old versions.
I spent a bit more time but there s a lot to demystify. Gonna take a bit of break from this one and come back to this after doing other updates. Might even consider sending a RFH to the list.
libwebsockets: Multiple issues were reported in LWS causing denial of service and stack-based buffer overflow.
Backporting tests was an interesting exercise as I had to make them compatible with the bullseye version. :)
ceph: Affected by CVE-2024-47866, using the argument x-amz-copy-source to put an object and specifying an empty string as its content leads to the RGW daemon crashing, resulting in a DoS attack.
[LTS]: Whilst the patch is straightforward, backports are a bit tricky. I ve prepared the update but would like to reach out to zigo, the maintainer, to make sure nothing regresses.
[ELTS]: Same as LTS, I d like to get a quick review and upload to LTS first before I start staging uploads for ELTS.
[LTS] Attended the monthly LTS meeting on IRC. Summary here.
It was also followed by a 50-minute post-meeting technical discussion/question session.
[E/LTS] Monitored discussions on mailing lists, IRC, and all the documentation updates. Thanks, Sylvain, for a great documentation summary.
Review: The Last Soul Among Wolves, by Melissa Caruso
Series:
The Echo Archives #2
Publisher:
Orbit
Copyright:
August 2025
ISBN:
0-316-30404-2
Format:
Kindle
Pages:
355
The Last Soul Among Wolves is urban high fantasy with strong
mystery vibes. It is a direct sequel to The Last Hour Between Worlds. You need the previous book for some
character setup (and this book would spoil it badly), but you don't have
to remember the first book in detail. Only the main plot outcomes are
directly relevant and the characters will remind you of those.
Kembrel Thorne is a Hound, the equivalent of a police detective in the
medieval-inspired city setting of this series, but this book does not open
with an official assignment. Instead, she has been dragged by her
childhood friend Jaycel Morningrey as company for a reading of the will of
old lady Lovegrace, reclusive owner of a gothic mansion on an island
connected to the city by an intermittent sandbar. A surprise reunion with
her gang of childhood friends ensues, followed by the revelation that they
are all in serious trouble.
Shortly after Kem left the group to become a Hound, the remaining four,
plus several other apparently random people, got entangled with a powerful
Echo artifact. Now that Lovegrace has died, one of them will inherit the
artifact and the ability to make a wish, but only one. The rest will be
killed at decreasing intervals until only the winner is left alive.
The Last Hour Between Worlds was fae fantasy built around a problem
that was more of a puzzle than a mystery. The Last Soul Among
Wolves is closer to a classic mystery: A cast of characters are brought
together and semi-isolated in a rural house, they start dying, and it's up
to the detective to solve the mystery of their death before it's too late.
In this case, the initial mechanism of death is supernatural and not in
doubt the challenge instead is how to stop it from happening again but
Kem's problems quickly become more complicated.
As mystery plots go, this is more thriller than classical despite the
setting. There are a few scenes of analyzing clues, but Kem is more likely
to use the time-honored protagonist technique of throwing herself into
danger and learning what's going on via the villain monologues. As readers
of the previous book would expect, Rika Nonesuch is here too, hired by
another of Kem's old friends, and the two navigate their personal feelings
and the rivalry between their guilds in much the way that they did in
the Last Hour Between Worlds. As in the first book, there is a
sapphic romance subplot, but it's a very slow burn asexual romance.
The best part of this series continues to be the world-building. The
previous book introduced the idea of the Echoes and sent the characters
exploring into stranger and stranger depths. This book fleshes out the
rules in more detail, creating something that feels partly like a fae
realm and partly like high fantasy involving gods, but diverges from both
into a logic of its own. The ending satisfyingly passes my test of fantasy
mysteries: Resolving the mystery requires understanding and applying the
rules of the setting, which are sufficiently strange to create interesting
outcomes but coherent enough that the reader doesn't feel like the author
is cheating.
There are some hissable villains here, but my favorite part of this book
was the way Caruso added a lot of nuance and poignancy to the Echoes
rather than showing them only as an uncanny threat. That choice made the
world feel deeper and richer. It's not yet clear whether that element is
setup for a longer-term series plot, but I hope Caruso will develop the
story in that direction.
It felt to me like Caruso is aiming for an ongoing series rather than a
multi-volume story with a definite ending. She avoids a full episodic
reset Rika, in particular, gets considerable character development and
new complications that bode well for future volumes but it doesn't feel
like the series is building towards an imminent climax. This is not a
complaint. I enjoy these characters and this world and will happily keep
devouring each new series entry.
If you liked The Last Hour Between Worlds, I think you will like
this. It doesn't have the same delight of initial discovery of the great
world-building, but the plot is satisfying and a bit more complex and the
supporting characters are even better than those in the first book. Once
again, Caruso kept me turning the pages, and I'm now looking forward to a
third volume. Recommended.
The third book in the series has not yet been announced, but there are
indications on social media that it is coming.
Rating: 7 out of 10
I am a huge fan of Git, as I have witnessed how it has made software development so much more productive compared to the pre-2010s era. I wish all Debian source code were in Git to reap the full benefits.
Git is not perfect, as it requires significant effort to learn properly, and the ecosystem is complex with even more things to learn ranging from cryptographic signatures and commit hooks to Git-assisted code review best practices, forge websites, and CI systems.
Sure, there is still room to optimize its use, but Git certainly has proven itself and is now the industry standard. Thus, some readers might be surprised to learn that Debian development in 2025 is not actually based on Git. In Debian, the version control is done by the Debian archive itself. Each commit is a new upload to the archive, and the commit message is the debian/changelog entry. The commit log is available at snapshots.debian.org.
In practice, most Debian Developers (people who have the credentials to upload to the Debian archive) do use Git and host their packaging source code on salsa.debian.org the GitLab instance of Debian. This is, however, based on each DD s personal preferences. The Debian project does not have any policy requiring that packages be hosted on salsa.debian.org or be in version control at all.
Is collaborative software development possible without git and version control software?
Debian, however, has some peculiarities that may be surprising to people who have grown accustomed to GitHub, GitLab or various company-internal code review systems.
In Debian:
The source code of the next upload is not public but resides only on the developer s laptop.
Code contributions are plain patch files, based on the latest revision released in the Debian archive (where the unstable area is equivalent to the main development branch).
These patches are submitted by email to a bug tracker that does no validation or testing whatsoever.
Developers applying these patches typically have elaborate Mutt or Emacs setups to facilitate fetching patches from email.
There is no public staging area, no concept of rebasing patches or withdrawing a patch and replacing it with a better version.
The submitter won t see any progress information until a notification email arrives after a new version has been uploaded to the Debian archive.
This system has served Debian for three decades. It is not broken, but using the package archive just feels well, archaic.
There is a more efficient way, and indeed the majority of Debian packages have a metadata field Vcs-Git that advertises which version control repository the maintainer uses. However, newcomers to Debian are surprised to notice that not all packages are hosted on salsa.debian.org but at various random places with their own account and code submission systems, and there is nothing enforcing or even warning if the code there is out of sync with what was uploaded to Debian. Any Debian Developer can at any time upload a new package with whatever changes, bypassing the Git repository, even when the package advertised a Git repository. All PGP signed commits, Git tags and other information in the Git repository are just extras currently, as the Debian archive does not enforce or validate anything about them.
This also makes contributing to multiple packages in parallel hard. One can t just go on salsa.debian.org and fork a bunch of repositories and submit Merge Requests. Currently, the only reliable way is to download source packages from Debian unstable, develop patches on top of them, and send the final version as a plain patch file by email to the Debian bug tracker. To my knowledge, no system exists to facilitate working with the patches in the bug tracker, such as rebasing patches 6 months later to detect if they or equivalent changes were applied or if sending refreshed versions is needed.
To newcomers in Debian, it is even more surprising that there are packages that are on salsa.debian.org but have the Merge Requests feature disabled. This is often because the maintainer does not want to receive notification emails about new Merge Requests, but rather just emails from bugs.debian.org. This may sound arrogant, but keep in mind that these developers put in the effort to set up their Mutt/Emacs workflow for the existing Debian process, and extending it to work with GitLab notifications is not trivial. There are also purists who want to do everything via the command-line (without having to open a browser, run JavaScript and maintain a live Internet connection), and tools like glab are not convenient enough for the full workflow.
Inefficient ways of working prevent Debian from flourishing
I would claim, based on my personal experiences from the past 10+ years as a Debian Developer, that the lack of high-quality and productive tooling is seriously harming Debian. The current methods of collaboration are cumbersome for aspiring contributors to learn and suboptimal to use for both new and seasoned contributors.
There are no exit interviews for contributors who left Debian, no comprehensive data on reasons to contribute or stop contributing, nor are there any metrics tracking how many people tried but failed to contribute to Debian. Some data points to support my concerns do exist:
Most packages are maintained by one person working alone (just pick any package at random and look at the upload history).
Debian should embrace git, but decision-making is slow
Debian is all about community and collaboration. One would assume that Debian prioritized above all making collaboration tools and processes simpler, faster and less error-prone, as it would help both current and future package maintainers. Yet, it isn t so, due to some reasons unique to Debian.
There is no single company or entity running Debian, and it has managed to operate as a pure meritocracy and do-cracy for over 30 years. This is impressive and admirable. Unfortunately, some of the infrastructure and technical processes are also nearly 30 years old and very difficult to change for the same reason: the nature of Debian s distributed decision-making process.
As a software developer and manager with 25+ years of experience, I strongly feel that developing software collaboratively using Git is a major step forward that Debian needs to take, in one form or another, and I hope to see other DDs voice their support if they agree.
Debian Enhancement Proposal 18
Following how consensus is achieved in Debian, I started drafting DEP-18 in 2024, and it is currently awaiting enough thumbs up at https://salsa.debian.org/dep-team/deps/-/merge_requests/21 to get into CANDIDATE status next.
In summary, the DEP-18 proposes that everyone keen on collaborating should:
Maintain Debian packaging sources in Git on Salsa.
Use Merge Requests to show your work and to get reviews.
Run Salsa CI before upload.
The principles above are not novel. According to stats at e.g. trends.debian.net, and UDD, ~93% of all Debian source packages are already hosted on salsa.debian.org. As of June 1st, 2025, only 1640 source packages remain that are not hosted on Salsa. The purpose of DEP-18 is to state in writing what Debian is currently doing for most packages, and thus express what among others new contributors should be learning and doing, so basic collaboration is smooth and free from structural obstacles.
Most packages are also already allowing Merge Requests and using Salsa CI, but there hasn t been any written recommendation anywhere in Debian to do so. The Debian Policy (v.4.7.2) does not even mention the word Salsa a single time. The current process documentation on how to do non-maintainer uploads or salvaging packages are all based on uploading packages to the archive, without any consideration of using git-based collaboration such as posting a Merge Request first. Personally I feel posting a Merge Request would be a better approach, as it would invite collaborators to discuss and provide code reviews. If there are no responses, the submitter can proceed to merge, but compared to direct uploads to the Debian archive, the Merge Request practice at least tries to offer a time and place for discussions and reviews to happen.
It could very well be that in the future somebody comes up with a new packaging format that makes upstream source package management easier, or a monorepo with all packages, or some other future structures or processes. Having a DEP to state how to do things now does not prevent people from experimenting and innovating if they intentionally want to do that. The DEP is merely an expression of the minimal common denominators in the packaging workflow that maintainers and contributors should follow, unless they know better.
Transparency and collaboration
Among the DEP-18 recommendations is:
The recommended first step in contributing to a package is to use the built-in Fork feature on Salsa. This serves two purposes. Primarily, it allows any contributor to publish their Git branches and submit them as Merge Requests. Additionally, the mere existence of a list of Forks enables contributors to discover each other, and in rare cases when the original package is not accepting improvements, collaboration could arise among the contributors and potentially lead to permanent forks in the general meaning. Forking is a fundamental part of the dynamics in open source that helps drive quality and agreement. The ability to fork ultimately serves as the last line of defense of users rights. Git supports this by making both temporary and permanent forks easy to create and maintain.
Further, it states:
Debian packaging work should be reasonably transparent and public to allow contributors to participate. A maintainer should push their pending changes to Salsa at regular intervals, so that a potential contributor can discover if a particular change has already been made or a bug has been fixed in version control, and thus avoid duplicate work.
Debian maintainers should make reasonable efforts to publish planned changes as Merge Requests on Salsa and solicit feedback and reviews. While pushing changes directly on the main Git branch is the fastest workflow, second only to uploading all changes directly to Debian repositories, it is not an inclusive way to develop software. Even packages that are maintained by a single maintainer should at least occasionally publish Merge Requests to allow new contributors to step up and participate.
I think these are key aspects leading to transparency and true open source collaboration. Even though this talks about Salsa which is based on GitLab the concepts are universal and will work also on other forges, like Forgejo or GitHub. The point is that sharing work-in-progress on a real-time platform, with CI and other supporting features, empowers and motivates people to iterate on code collaboratively. As an example of an anti-pattern, Oracle MySQL publishes the source code for all their releases and is license-compliant, but as they don t publish their Git commits in real-time, it does not feel like a real open source project. Non-Oracle employees are not motivated to participate as second-class developers who are kept in the dark. Debian should embrace git and sharing work in real-time, embodying a true open source spirit.
Recommend, not force
Note that the Debian Enhancement Proposals are not binding. Only the Debian Policy and Technical Committee decisions carry that weight. The nature of collaboration is voluntary anyway, so the DEP does not need to force anything on people who don t want to use salsa.debian.org.
The DEP-18 is also not a guide for package maintainers. I have my own views and have written detailed guides in blog articles if you want to read more on, for example, how to do code reviews efficiently.
Within DEP-18, there is plenty of room to work in many different ways, and it does not try to force one single workflow. The goal here is to simply have agreed-upon minimal common denominators among those who are keen to collaborate using salsa.debian.org, not to dictate a complete code submission workflow.
Once we reach this, there will hopefully be less friction in the most basic and recurring collaboration tasks, giving DDs more energy to improve other processes or just invest in having more and newer packages for Debian users to enjoy.
Next steps
In addition to lengthy online discussions on mailing lists and DEP reviews, I also presented on this topic at DebConf 2025 in Brest, France. Unfortunately the recording is not yet up on Peertube.
The feedback has been overwhelmingly positive. However, there are a few loud and very negative voices that cannot be ignored. Maintaining a Linux distribution at the scale and complexity of Debian requires extraordinary talent and dedication, and people doing this kind of work often have strong views, most of the time for good reasons. We do not want to alienate existing key contributors with new processes, so maximum consensus is desirable.
We also need more data on what the 1000+ current Debian Developers view as a good process to avoid being skewed by a loud minority. If you are a current or aspiring Debian Developer, please add a thumbs up if you think I should continue with this effort (or a thumbs down if not) on the Merge Request that would make DEP-18 have candidate status.
There is also technical work to do. Increased Git use will obviously lead to growing adoption of the new tag2upload feature, which will need to get full git-buildpackage support so it can integrate into salsa.debian.org without turning off Debian packaging security features. The git-buildpackage tool itself also needs various improvements, such as making contributing to multiple different packages with various levels of diligence in debian/gbp.conf maintenance less error-prone.
Eventually, if it starts looking like all Debian packages might get hosted on salsa.debian.org, I would also start building a review.debian.org website to facilitate code review aspects that are unique to Debian, such as tracking Merge Requests across GitLab projects in ways GitLab can t do, highlighting which submissions need review most urgently, feeding code reviews and approvals into the contributors.debian.org database for better attribution, and so forth.
Details on this vision will be in a later blog post, so subscribe to updates!
Activity summary
During the month of October, 21 contributors have been
paid to work on Debian LTS (links to individual
contributor reports are located below).
The team released 37 DLAs fixing 893 CVEs.
The team has continued in its usual rhythm, preparing and uploading security
updates targeting LTS and ELTS, as well as helping with updates to oldstable,
stable, testing, and unstable. Additionally, the team received several
contributions of LTS uploads from Debian Developers outside the standing LTS
Team.
Notable security updates:
https-everywhere, prepared by Markus Koschany, deals with a problem created by ownership of the https-rulesets.org domain passing to a malware operator
openjdk-17 and openjdk-11, prepared by Emilio Pozuelo Monfort, fixes XML external entity and certificate validation vulnerabilities
intel-microcode, prepared by Tobias Frost, fixes a variety of privilege escalation and denial of service vulnerabilities
Notable non-security updates:
distro-info-data, prepared by Stefano Rivera, updates information concerning current and upcoming Debian and Ubuntu releases
Contributions from outside the LTS Team:
Lukas M rdian, a Debian Developer, provided an update of log4cxx
Andrew Ruthven, one of the request-tracker4 maintainers, provided an update of request-tracker4
Christoph Goehre, co-maintainer of thunderbird, provided an update of thunderbird
Beyond the typical LTS updates, the team also helped the Debian community more broadly:
Guilhem Moulin prepared oldstable/stable updates of libxml2, and an unstable update of libxml2.9
Bastien Roucari s prepared oldstable/stable updates of imagemagick
Daniel Leidert prepared an oldstable update of python-authlib, oldstable update of libcommons-lang-java and stable update of libcommons-lang3-java
Utkarsh Gupta prepared oldstable/stable/testing/unstable updates of ruby-rack
The LTS Team is grateful for the opportunity to contribute to making LTS a high quality for sponsors and users. We are also particularly grateful for the collaboration from others outside the time; their contributions are important to the success of the LTS effort.
One of the servers to which I SSH ratcheted up its public key
requirements and thus the Monkeysphere key I've been using for 15
years stopped working.
Unfortunately, monkeysphere gen-subkey hardcodes RSA keys and
if I'm going to be forced to use a new subkey I want mine to
be of the 25519 variety. Therefore, to add a subkey by hand:
gpg --expert --edit-key $KEYID
Follow roughly what's in /usr/share/monkeysphere/m/gen_subkey,
but change the key type to 11 (ECC (set your own capabilities)),
don't bother with Encrypt capability, and pick Curve25519.
monkeysphere subkey-to-ssh-agent and agent-transfer will be all
happy with the "ed25519" subkey without any code modifications,
and you won't need to rewrite monkeysphere from scratch to use
Sequoia for the next 15 years.
The debian-with-guix-container project build and publish container images of Debian GNU/Linux stable with GNU Guix installed.
The images are like normal Debian stable containers but have the guix tool and a reasonable fresh guix pull.
Supported architectures include amd64 and arm64. The multi-arch container is called:
registry.gitlab.com/debdistutils/guix/debian-with-guix-container:stable
It may also be accessed via debian-with-guix at Docker Hub as:
docker.io/jas4711/debian-with-guix:stable
The container images may be used like this:
$ podman run --privileged -it --hostname guix --rm registry.gitlab.com/debdistutils/guix/debian-with-guix-container:stable
root@guix:/# hello
bash: hello: command not found
root@guix:/# guix describe
guix c9eb69d
repository URL: https://gitlab.com/debdistutils/guix/mirror.git
branch: master
commit: c9eb69ddbf05e77300b59f49f4bb5aa50cae0892
root@guix:/# LC_ALL=C.UTF-8 /root/.config/guix/current/bin/guix-daemon --build-users-group=guixbuild &
[1] 21
root@guix:/# GUIX_PROFILE=/root/.config/guix/current; . "$GUIX_PROFILE/etc/profile"
root@guix:/# guix describe
Generation 2 Nov 28 2025 10:14:11 (current)
guix c9eb69d
repository URL: https://gitlab.com/debdistutils/guix/mirror.git
branch: master
commit: c9eb69ddbf05e77300b59f49f4bb5aa50cae0892
root@guix:/# guix install --verbosity=0 hello
accepted connection from pid 55, user root
The following package will be installed:
hello 2.12.2
hint: Consider setting the necessary environment variables by running:
GUIX_PROFILE="/root/.guix-profile"
. "$GUIX_PROFILE/etc/profile"
Alternately, see guix package --search-paths -p "/root/.guix-profile"'.
root@guix:/# GUIX_PROFILE="/root/.guix-profile"
root@guix:/# . "$GUIX_PROFILE/etc/profile"
root@guix:/# hello
Hello, world!
root@guix:/#
Below is an example GitLab pipeline job that demonstrate how to run guix install to install additional dependencies, and then download and build a package that pick up the installed package from the system.
The images were initially created for use in GitLab CI/CD Pipelines but should work for any use.
The images are built in a GitLab CI/CD pipeline, see .gitlab-ci.yml.
The containers are derived from official Debian stable images with Guix installed and a successful run of guix pull, built using buildah invoked from build.sh using image/Containerfile that runs image/setup.sh.
The pipeline also push images to the GitLab container registry, and then also to Docker Hub.
Guix binaries are downloaded from the Guix binary tarballs project because of upstream download site availability and bandwidth concerns.
Enjoy these images! Hopefully they can help you overcome the loss of Guix in Debian which made it a mere apt-get install guix away before.
There are several things that may be improved further. An alternative to using podman --privileged is to use --security-opt seccomp=unconfined --cap-add=CAP_SYS_ADMIN,CAP_NET_ADMIN which may be slightly more fine-grained.
For ppc64el support I ran into an error message that I wasn t able to resolve:
guix pull: error: while setting up the build environment: cannot set host name: Operation not permitted
For riscv64, I can t even find a Guix riscv64 binary tarball for download, is there one anywhere?
For arm64 containers, it seems that you need to start guix-daemon with --disable-chroot to get something to work, at least on GitLab.com s shared runners, otherwise you will get this error message:
guix install: error: clone: Invalid argument
Building the images themselves also require disabling some security functionality, and I was not able to build images with buildah without providing --cap-add=CAP_SYS_ADMIN,CAP_NET_ADMIN otherwise there were errors like this:
guix pull: error: cloning builder process: Operation not permitted
guix pull: error: clone: Operation not permitted
guix pull: error: while setting up the build environment: cannot set loopback interface flags: Operation not permitted
Finally on amd64 it seems --security-opt seccomp=unconfined is necessary, otherwise there is an error message like this, even if you use --disable-chroot:
guix pull: error: while setting up the child process: in phase setPersonality: cannot set personality: Function not implemented
This particular error is discussed upstream, but I think generally that these error suggest that guix-daemon could use more optional use of features: if some particular feature is not available, gracefully fall back to another mode of operation, instead of exiting with an error. Of course, it should never fall back to an insecure mode of operation, unless the user requests that.
Happy Hacking!
Review: A Matter of Execution, by Nicholas & Olivia Atwater
Series:
Tales of the Iron Rose #0
Publisher:
Starwatch Press
Copyright:
2024
ISBN:
1-998257-08-8
Format:
Kindle
Pages:
131
A Matter of Execution is the introductory novella that kicked off
the Tales of the Iron Rose series. It is steampunk fantasy with airships.
I previously read and reviewed the subsequent novel,
Echoes of the Imperium.
As noted in that review, I read the novel first. That was a mistake; this
is a much better place to start. A Matter of Execution was clearly
intended as the introduction of all of these characters. More importantly,
I think reading the novella first would have given me enough affinity with
the characters to not mind the worst part of Echoes of the
Imperium: the extremely slow first half that seemed filled with the
protagonist's impostor syndrome.
A Matter of Execution opens, fittingly, with Captain William Blair,
a goblin, former Imperial soldier, Oathbreaker, and series first-person
protagonist being carted to his execution. He is not alone; in the same
prison wagon is an arrogant (and racist) man named Strahl, the killer of
one of the rulers of Lyonesse.
Strahl is rather contemptuous of Blair's claim to be a captain, given that
he's both a goblin and an Oathbreaker. Strahl quickly revises that opinion
when Blair's crew, somewhat predictably given that he is the series
protagonist, creates a daring escape for both of them. The heat of action
gives both a chance to gain some respect for the other, which explains why
Blair is not only willing to invite Strahl to join his crew, but to go
back for Strahl's companion.
Breaking out Strahl's companion will be a more difficult, and surprising,
problem.
Nicholas Atwater is a role-playing game GM, something that you will learn
in the "about the author" section at the end of this novella but probably
will have guessed by then. Even more than Echoes of the Imperium,
this novella feels like a (good) write-up of an RPG adventure. A wildly
varied cast of characters come together and form a party with a
well-defined objective that has some surrounding mysteries and surprises.
Each of those characters get their individual moments to show off their
specific skills. Readers with a certain gaming background will know
exactly where to insert the Borderlands-style title card with a
slightly demented description of each character.
This is not a complaint. You may be able to see the bones of the setup
adventure for a long-running campaign, but I like this style of character
introduction and the story moves right along. There are a ton of varied
characters, some interesting villains and maybe-villains, a rather
satisfying heist setup, and some good chemistry and a bit of banter. This
is not a deep story it's clearly an introductory episode for both the
characters and the world background but it's a fun way to spend a few
hours.
I think the best part of this series is the world-building. If you have
read my review of Echoes of the Imperium, you have unfortunately
been mildly spoiled for the revelation in this novella. I don't think it
hurt the story that much; you will be able to predict what obvious gaps in
the novel backstory the novella is going to fill in, but it's just as
enjoyable to see how that happens. But the Atwaters aren't going to drop
any of the big world-building bombs in the introductory novella, of
course. Instead, you get a gradual introduction to the nature of magic in
this world, some of the political setup of the recent war, and a quick
introduction to the capabilities of Strahl's mysterious companion.
If you've not yet read this series, I recommend starting here. It's a
quick investment to see if you'll be interested. The novel is heavier and
slower, and the pacing of the first half isn't great, but the
world-building is even better.
If you've already read the novel, this is still worth reading as long as
you enjoyed it. You'll have a few moments of "oh, that's how that
happened," and it's a fun and fast-moving way to spend a bit more time
with the characters.
Followed by Echoes of the Imperium. The
back matter of the novella says that The Winds of Fortune is
supposedly forthcoming.
Rating: 7 out of 10
I ve had a Pine Time for just over 2 years [1]. About a year ago I had a band break and replaced it from a spare PineTime and now I just had another break. Having the band only last one year isn t that great, but it s fortunate that the break only affects the inner layer of plastic so there is no risk of the watch suddenly falling off and being broken or lost. The Pine64 web site has a page about this with bad options, one broken link and a few Amazon items that are have ridiculous postage [2].
I started writing this post while using the band from a Colmi P80 [3]. I bought one for a relative who wanted the metal band and the way the Aliexpress seller does it is to sell the package with the plastic band and include the metal band in the package so I had a spare band. It fits quite well and none of the reported problems of the PineTime having insufficient space between the spring bar and the watch. The Colmi band in question is described as rose gold but is more like pinkish beige and doesn t match the style of the black PineTime.
I ordered a couple of cheap bands from AliExpress which cost $9.77 and $13.55 including postage while the ones that Pine64 recommend have over $15 postage from Amazon!
The 20mm Silicone Magnetic Buckle Watch Strap Band For Huawei GT2 Smart Watch Connected Bracelet Black Watchband Man [4] cost $13.55 including postage. It has a magnetic unfold mechanism which I find a bit annoying and it doesn t allow easily changing the length. I don t think I ll choose that again. But it basically works and is comfortable.
The 20mm Metal Strap for Huawei Watch GT2 3 Quick Release Stainless Steel Watch Band for Samsung Galaxy Watch Bracelet [5] cost $9.77 including postage. I found this unreasonably difficult to put on and not particularly comfortable. But opinion will vary on that, it is cheap and will appeal to some people s style.
Conclusion
There are claims that getting a replacement band for a PineTime is difficult. My experience is that every band with a 20mm attachment works as long as it s designed for a square watch, some of the bands are designed to partly go around a round face and wouldn t fit. I expect that some bands won t fit, but I don t think that it s enough of a problem to be worried about buying a random band from AliExpress. The incidence of bands not fitting will probably be lower than the incidence of other AliExpress products not doing quite what you want (while meeting the legal criteria of doing what they are claimed to do) and not being used.
I m now wearing the PineTime with the Magnetic Buckle Watch Strap Band and plan to wear it for the next year or so.
Posted on November 27, 2025
Tags: madeof:atoms, madeof:bits, craft:bookbinding
A few years ago I wrote some planner generating code to make myself a
custom planner; in November 2023 I generated a few, and posted them
here on the blog, in case somebody was interested in using them.
In 2024 I tried to do the same, and ended up being even more late, to
the point where I didn t generate any (uooops).
I did, however, start to write a Makefile to automate the generation
(and got stuck on the fact that there wasn t an easy way to deduce the
correct options needed from just the template name); this year, with the
same promptness as in 2023 I got back to the Makefile and finished it, so
maybe next year I will be able to post them early enough for people to
print and bind them? maybe :)
Anyway, these are all of the variants I currently generate, for 2026.
The files with -book in the name have been imposed on A4 paper for a
16 pages signature. All of the fonts have been converted to paths, for
ease of printing (yes, this means that customizing the font requires
running the script, but the alternative also had its drawbacks).
In English:
Some of the planners include ephemerids and moon phase data: these have
been calculated for the town of Como, and specifically for
geo:45.81478,9.07522?z=17, because that s what everybody needs, right?
If you need the ephemerids for a different location and can t run the
script yourself (it depends on pdfjam, i.e. various GB of LaTeX, and a
few python modules such as dateutil, pypdf and jinja2), feel free to
ask: unless I receive too many requests to make this sustainable I ll
generate them and add them to this post.
I hereby release all the PDFs linked in this blog post under the CC0
license.
You may notice that I haven t decided on a license for the code dump
repository; again if you need it for something (that is compatible with
its unsupported status) other than running it for personal use (for
which afaik there is an implicit license) let me know and I ll push
decide on a license higher on the stack of things to do :D
Finishing the Makefile meant that I had to add a tiny feature to one of
the scripts involved, which required me to add a dependency to pypdf:
up to now I have been doing the page manipulations with pdfjam, which
is pretty convenient to use, but also uses LaTeX, and apparently not
every computer comes with texlive installed (shocking, I know).
If I m not mistaken, pypdf can do all of the things I m doing with
pdfjam, so maybe for the next year I could convert my script to use that
one instead.
But then the planners 2027 will be quick and easy, and I will be able to
publish them promptly, right?
Another maintenance release of the tidyCpp
package arrived on CRAN this morning, the first in about two years. The
packages offers a clean C++ layer (as well as one small C++ helper
class) on top of the C API for R which aims to make use of this robust
(if awkward) C API a little easier and more consistent. See the (now
updated, see below) vignette for motivating
examples.
This release contains mostly internal upkeep of the usual type:
refreshing continuous integration, updating links, switching to
Authors@R. But as we wrap the C API of R here too, changes made in
R-devel this week affected the two reverse-dependencies
(i.e. downstream ) packages (of mine) using this. So we commented-out
the definitions for the five now-hidden accessors so that these
downstream packages can build again under R-devel.
The NEWS entry follows.
Changes in tidyCpp
version 0.0.8 (2025-11-25)
Updated continuous integration setup several times
Updated README.md documentation with link to R API site
Updated example snippets to use of Protect
Updated documentation in defines.h header
Updated internals.h header reflecting in R API
changes
As it happens, hours after the release at CRAN a helpful issue ticket was
opened detailing more than a handful of typos in the vignette. This has
been corrected, and I am not exporting the vignette via GitHub Pages so
the motivating
examples vignette contains the corrections.
Thanks to my CRANberries, there
is also a diffstat report for this
release. For questions, suggestions, or issues please use the issue tracker
at the GitHub
repo. If you like this or other open-source work I do, you can now
sponsor me at
GitHub.
I previously blogged about buying a refurbished Hisense 65u80g 8K TV with the aim of making it a large monitor [1] and about searching for a suitable video card for 8k [2]. After writing the second post I bought an Intel Arc B580 which also did a maximum of 4096*2160 resolution.
This post covers many attempts to try and get the TV to work correctly and it doesn t have good answers. The best answer might be to not buy Hisense devices but I still lack data.
Attempts to Force 8K
I posted on Lemmy again about this [3] and got a single response, which is OK as it was a good response. They didn t give me the answer on a silver platter but pointed me in the right direction of EDID [4].
I installed the Debian packages read-edid, wxedid, and edid-decode.
The command get-edid > out.edid saves the binary form of the edid to a file. The command wxedid out.edid allows graphical analysis of the EDID data. The command edid-decode out.edid dumps a plain text representation of the output, the command edid-decode out.edid grep VIC cut -d: -f2 sort -n shows an ordered list of video modes, in my case the highest resolution is 4096 2160 which is the highest that Linux had allowed me to set with two different video cards and a selection of different cables (both HDMI and DisplayPort).
At this time I don t know how much of this is due to the video card and how much is due to the TV. The parameters for xrandr came from a LLM because I couldn t find any Google results on what 8K parameters to use. As an aside if you have a working 8K TV or monitor connected to a computer please publish the EDID data, xrandr, and everything else you can think of.
I found a Github repository for EDID data [5] but that didn t have an entry for my TV and didn t appear to have any other entry for an 8K device I could use.
Resolution for Web Browsing
I installed a browser on the TV, Chrome and Firefox aren t available for a TV and the Play Store program tells you that (but without providing a reason) when you search for them. I tried the site CodeShack What is my Screen Resolution [6] which said that my laptop is 2460*1353 while the laptop display is actually 2560*1440. So apparently I have 100 pixels used for the KDE panel at the left of the screen and 87 pixels used by the Chrome tabs and URL bar which seems about right. My Note 9 phone reports 384*661 out of it s 2960*1440 display so it seems that Chrome on my phone is running web sites at 4/15 of the native resolution and about 16% of the height of the screen is used by the system notification bar, the back/home/tasklist buttons (I choose buttons instead of swipe for navigation in system settings), and the URL bar when I have Screen zoom in system settings at 1/4. When I changed Screen zoom to 0/4 the claimed resolution changed to 411*717 (2/7 of the native resolution). Font size changes didn t change the claimed resolution. The claimed Browser Viewport Size by CodeShack is 1280*720 which is 1/6 of the real horizontal resolution and slightly more than 1/6 of the vertical resolution, it claims that the Pixel Density is 2* and a screen resolution of 970*540 which means to imply that the browser is only working at 1920*1080 resolution!
Netflix
When I view Netflix shows using the Netflix app running on the TV is reports 4K which doesn t happen on Linux PCs (as they restrict 4K content to platforms with DRM) and in the Device setting it reports Device Model as Hisense_SmartTV 8K FFM so the Netflix app knows all about 4K content and knows the text string 8K .
YouTube
When I view a YouTube video that s described as being 8K I don t get a request for paying for YouTube Premium which is apparently what happens nowadays when you try to play actual 8K video. I turn on State for Nerds and one line has Viewport / Frames 1920 1080*2.00 and another has Current / Optimal Res 3840 2160@60 / 3840 2160@60 so it seems that the YouTube app is seeing the screen as 4K but choosing to only display FullHD even when I have Quality set to 2160p60 HDR . It declares the network speed to be over 100mbit most of the time and the lowest it gets is 60mbit while 50mbit is allegedly what s required for 8K.
I installed a few Android apps to report hardware capabilities and they reported the screen resolution to be 1920*1080.
Have I Been Ripped Off?
It looks like I might have been ripped off by this. I can t get any app other than Netflix to display 4K content. My PC will only connect to it at 4K. Android apps (including YouTube) regard it as 1920*1080.
The AI Upscaling isn t really that great and in most ways it seems at best equivalent to a 4K TV and less than a 4K TV that runs Android apps with an actual 4K display buffer.
Next Steps
The next things I plan to do are to continue attempts to get the TV to do what it s claimed to be capable of, either an Android app that can display 8K content or a HDMI input of 8K content will do. Running a VNC client on the TV would be an acceptable way of getting an 8K display from a Linux PC.
I need to get a somewhat portable device that can give 8K signal output. Maybe a mini PC with a powerful GPU or maybe one of those ARM boards that s designed to drive an 8K sign. Then I can hunt for stores that have 8K TVs on display.
It would be nice if someone made a USB device that does 8K video output NOT a USB-C DisplayPort alternative mode that uses the video hardware on the laptop. Then I could take a laptop to any place that has an 8K display to show and connect my laptop to it.
The one thing I haven t done yet is testing 8K MP4 files on a USB stick. That s mainly due to a lack of content and the fact that none of the phone cameras I have access to can do 8K video. I will try displaying 8K PNG and JPEG files from a USB stick.
Most people would give up about now. But I am determined to solve this and buying another large TV isn t out of the question.
Having learnt that Bootstrap supports
color modes,
we decided to implement an option for users to
enable dark mode
in Debusine.
By default, the color mode is selected depending on the user browser
preferences. If explicitly selected, we use a cookie to store the theme
selection so that a user can choose different color modes in different
browsers.
The work is in merge request !2401
and minimizes JavaScript dependencies
like we do in other parts of debusine.
A view to select the theme
First is a simple view to configure the selected theme and store it in a
cookie. If auto is selected, then the cookie is deleted to delegate theme
selection to JavaScript:
classThemeSelectionView(View):
"""Select and save the current theme."""defpost(
self, request: HttpRequest, *args: Any, **kwargs: Any# noqa: U100 ) -> HttpResponse:
"""Set the selected theme."""value = request.POST.get("theme", "auto")
next_url = request.POST.get("next", None)
ifnext_urlisNone:
next_url = reverse("homepage:homepage")
response = HttpResponseRedirect(next_url)
ifvalue == "auto":
response.delete_cookie("theme")
else:
response.set_cookie(
"theme", value, httponly=False, max_age=dt.timedelta(days=3650)
)
returnresponse
The base template will use this value to set data-bs-theme on the main
<html> element, and that s all that is needed to select the color mode in
Bootstrap:
Since we added the theme selection buttons in the footer, we use CSS to render
the buttons in the same way as the rest of the footer links.
Bootstrap has a set of CSS variables
that can be used to easily in sync with the site theme, and they are especially
useful now that the theme is configurable:
% if not theme %
<scriptblocking="render">
(function()
lettheme = window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light';
let [html] = document.getElementsByTagName("html");
html.setAttribute("data-bs-theme", theme);
)();
</script>
% endif %
This reads the color scheme preferences and sets the data-bs-theme attribute
on <html>.
The script is provided inline as it needs to use blocking="render" to avoid
flashing a light background at the beginning of page load until the attribute
is set.
Given that this is a render-blocking snippet, as an extra optimization it is
not added to the page if a theme has been set.
Bootstrap CSS fixes
We were making use of the bootstrap btn-light class in navbars to highlight
elements on hover, and that doesn t work well with theme selection.
Lacking a button class that does the right thing across themes, we came up with
a new CSS class that uses variables to define a button with hover highlight
that works preserving the underlying color:
Dark mode!
This was a nice integration exercise with many little tricks, like how to read
color scheme preferences from the browser, render form buttons as links, use
bootstrap variables, prevent a flashing background, handle cookies in Django.
And Debusine now has a dark mode!
A minor release of RcppQuantuccia
arrived on CRAN moments ago. RcppQuantuccia
started from the Quantuccia header-only
subset / variant of QuantLib which it
brings it to R. This project
validated the idea of making the calendaring functionality of QuantLib available in a
more compact and standalone project which we now do with qlcal which can be seen as a
successor package to this earlier package. qlcal tracks QuantLib (releases)
closely and provides approximately quarterly updates. Switching to using
qlcal is generally
recommended.
This release, the first in almost exactly two years, only updates
internals (as detailed below). Notably it switches to Authors@R to
avoid a nag from CRAN on two
platforms. The complete list changes for this release follows.
Changes in version 0.1.3
(2025-11-24)
A badge URL and link have been updated in README.md
The continuous integration sript switched first to r-ci-setup and
then to the r-ci action with embedded setup
Armadillo is a powerful
and expressive C++ template library for linear algebra and scientific
computing. It aims towards a good balance between speed and ease of use,
has a syntax deliberately close to Matlab, and is useful for algorithm
development directly in C++, or quick conversion of research code into
production environments. RcppArmadillo
integrates this library with the R environment and language and is
widely used by (currently) 1286 other packages on CRAN, downloaded 42.6 million
times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint
/ vignette) by Conrad and myself has been cited 659 times according
to Google Scholar.
This versions updates to the 15.2.2 upstream Armadillo release made two days
ago. It brings a few changes over the RcppArmadillo 15.2.0 release made
only to GitHub (and described in
this post), and of course even more changes relative to the last CRAN release described in
this earlier post. As described previously, and due to both the
upstream transition to C++14 coupled with the CRAN move away from C++11, the
package offers a transition by allowing packages to remain with the
older, pre-15.0.0 legacy Armadillo yet offering the
current version as the default. During the transition we did not make
any releases to CRAN allowing both the upload cadence to settle back to
the desired about six in six months that the CRAN Policy asks for, and
for packages to adjust to any potential changes. Most affected packages
have done so (as can be seen in the GitHub issues #489 and
#491)
which is good to see. We appreciate all the work done by the respective
package maintainers. A number of packages are still under a (now
formally expired) deadline at CRAN and may get removed. Our offer to
help where we can still stands, so please get in touch if we can be of
assistance. As a reminder, the meta-issue #475
regroups all the resources for the transition.
With respect to changes in the package, we once more overhauled the
OpenMP detection and setup, following the approach take by package
data.table but sticking with an autoconf-based
configure. The detailed changes since the last CRAN release
follow.
Changes in
RcppArmadillo version 15.2.2-1 (2025-11-21)
Upgraded to Armadillo release 15.2.2 (Medium Roast Deluxe)
Improved reproducibility of random number generation when using
OpenMP
Skip a unit test file under macOS as complex algebra seems to
fail under newer macOS LAPACK setting
Further OpenMP detection rework for macOS (Dirk in #497, #499)
Define ARMA_CRIPPLED_LAPACK on Windows only if 'LEGACY' Armadillo
selected
Changes
in RcppArmadillo version 15.2.1-0 (2025-10-28) (GitHub Only)
Upgraded to Armadillo release 15.2.1 (Medium Roast Deluxe)
Faster handling of submatrices with one row
Improve OpenMP detection (Dirk in #495
fixing #493)
Changes
in RcppArmadillo version 15.2.0-0 (2025-10-20) (GitHub Only)
Upgraded to Armadillo release 15.2.0 (Medium Roast Deluxe)
Added rande() for generating matrices with elements
from exponential distributions
shift() has been deprecated in favour of
circshift(), for consistency with Matlab/Octave
Reworked detection of aliasing, leading to more efficient
compiled code
Transferring a Signal account between two Android devices
I spent far too much time recently trying to get a Signal Private Messenger account to transfer from one device to another.
What I eventually found worked was a very finicky path to enable functioning "Wi-Fi Direct", which I go into below.
I also offer some troubleshooting and recovery-from-failure guidance.
All of this blogpost uses "original device" to refer to the Android pocket supercomputer that already has Signal installed and set up, and "new device" to mean the Android device that doesn't yet have Signal on it.
Why Transfer?
Signal Private Messenger is designed
with the expectation that the user has a "primary device",
which is either an iPhone or an Android pocket supercomputer.
If you have an existing Signal account,
and try to change your primary device
by backing up and restoring from backup,
it looks to me like Signal will cause your
long-term identity keys to be changed.
This in turn causes your peers to see
a message like "Your safety number with Alice has changed."
These warning messages are the same messages that they would get if an adversary were to take over your account.
So it's a good idea to minimize them when there isn't an account takeover false alarms train people to ignore real alarms.
You can avoid "safety number changed" warnings by using signal's "account transfer" process during setup,
at least if you're transferring between two Android devices.
However, my experience was that the transfer between two Android devices was very difficult to get to happen at all.
I ran into many errors trying to do this, until I finally found a path that worked.
Dealing with Failure
After each failed attempt at a transfer, my original device's Signal installation would need to be re-registered.
Having set a PIN meant that i could re-register the device without needing to receive a text message or phone call.
Set a PIN before you transfer!
Also, after a failure, you need to re-link any "linked device" (i.e. any Signal Desktop or iPad installation).
If any message came in during the aborted transfer, the linked device won't get a copy of that message.
Finally, after a failed transfer, i recommend completely uninstalling Signal from the new device, and starting over with a fresh install on the new device.
Permissions
My understanding is that Signal on Android uses Wi-Fi Direct to accomplish the transfer.
But to use Wi-Fi Direct, Signal needs to have the right permissions.
On each device:
Entirely stop the Signal app
Go to Settings Apps Signal Permissions
Ensure that the following permissions are all enabled whenever the app is running:
Location
Nearby Devices
Network
Preparing for Wi-Fi Direct
The transfer process depends on "Wi-Fi Direct", which is a bit of a disaster on its own.
I found that if i couldn't get Wi-Fi Direct to work between the two devices, then the Signal transfer was guaranteed to fail.
So, for clearer debugging, i first tried to establish a Wi-Fi Direct link on Android, without Signal being involved at all.
Setting up a Wi-Fi Direct connection directly failed, multiple times, until i found the following combination of steps, to be done on each device:
Turn off Bluetooth
Ensure Wi-Fi is enabled
Disconnect from any Wi-Fi network you are connected to (go to the "Internet" or "Wi-Fi" settings page, long-press on the currently connected network, and choose "Disconnect"). If your device knows how to connect to multiple local Wi-Fi networks, disconnct from each of them in turn until you are in a stable state where Wi-Fi is enabled, but no network is connected.
Close to the bottom of the "Inteernet" or "Wi-Fi" settings page, choose "Network Preferences" and then "Wi-Fi Direct"
if there are any entries listed under "Remembered groups", tap them and choose to "Forget this group"
If there are Peer devices that say "Invited", tap them and choose to "Cancel invitation"
I found that this configuration is the most likely to enable a successful Wi-Fi Direct connection, where clicking "invite" on one device would pop up an alert on the other asking to accept the connection, and result in a "Connected" state between the two devices.
Actually Transferring
Start with both devices fully powered up and physically close to one another (on the same desk should be fine).
On the new device:
Reboot the device, and log into the profile you want to use
Enable Internet access via Wi-Fi.
Remove any old version of Signal.
Install Signal, but DO NOT OPEN IT!
Set up the permissions for the Signal app as described above
Open Signal, and choose "restore or transfer" -- you still need to be connected to the network at this point.
The new device should display a QR code.
On the original device:
Reboot the device, and log into the profile that has the Signal account you're looking to transfer
Enable Internet access via Wi-Fi, using the same network that the old device is using.
Make sure the permissions for Signal are set up as described above
Open Signal, and tap the camera button
Point the camera at the new device's QR code
Now tap the "continue" choices on both devices until they both display a message that they are searching for each other.
You might see the location indicator (a green dot) turn on during this process.
If you see an immediate warning of failure on either device, you probably don't have the permissions set up right.
You might see an alert (a "toast") on one of the devices that the other one is trying to connect.
You should click OK on that alert.
In my experience, both devices are likely to get stuck "searching" for each other.
Wait for both devices to show Signal's warning that the search has timed out.
At this point, leave Signal open on both devices, and go through all the steps described above to prepare for Wi-Fi Direct.
Your Internet access will be disabled.
Now, tap "Try again" in Signal on both devices, pressing the buttons within a few seconds of each other.
You should see another alert that one device is trying to connect to the other.
Press OK there.
At this point, the transfer should start happening!
The old device will indicate what percentag has been transferred, and the new device will indicate how many messages hav been transferred.
When this is all done, re-connect to Wi-Fi on the new device.
Temporal gap for Linked Devices
Note that during this process, if new messages are arriving, they will be queuing up for you.
When you reconnect to wi-fi, the queued messages will flow to your new device.
But the process of transferring automatically unlinks any linked devices.
So if you want to keep your instance of Signal Desktop with as short a gap as possible, you should re-link that installation promptly after the transfer completes.
Clean-up
After all this is done successfully, you probably want to go into the Permissions settings and turn off the Location and Nearby Devices permissions for Signal on both devices.
I recommend also going into Wi-Fi Direct and removing any connected devices and forgetting any existing connections.
Conclusion
This is an abysmally clunky user experience, and I'm glad I don't have to do it often.
It would have been much simpler to make a backup and restore from it, but I didn't want to freak out my contacts with a safety number change.
By contrast, when i wanted extend a DeltaChat account across two devices, the transfer was prompt and entirely painless -- i just had to make sure the devices were on the same network, and then scanned a QR code from one to the other.
And there was no temporal gap for any other deviees.
And i could use Delta on both devices simultaneously until i was convinced that it would work on the new device -- Delta doesn't have the concept of a primary account.
I wish Signal made it that easy!
Until it's that easy, i hope the processes described here are useful to someone.
Well, you are right, you can t. At least not directly. This is well documented in many projects relying on interposing binaries, like faketime.
But what if we could write something that would take a static binary, replace at least the direct syscalls with ones going through libc and load it with the dynamic linker? We are in luck, because the excellent QEMU project has a user space emulator! It can be compiled as a dynamically linked executable, honors LD_PRELOAD and uses the host libc s syscall well, at least sometimes. Sometimes syscalls just bypass libc.
The missing piece was a way to make QEMU always take the interposable path and call the host libc instead of using an arch-specifix assembly routine ( safe_syscall_base ) to construct the syscall and going directly to the kernel. Luckily, this turned out to be doable. A small patch later, QEMU gained a switch that forces all syscalls through libc. Suddenly, our static binaries started looking a lot more dynamic!
With this in place, Firebuild can finally wrap even those secretive statically linked tools. QEMU runs them, libc catches their syscalls, LD_PRELOAD injects libfirebuild.so, and from there the usual interposition magic happens. The result: previously uncachable build steps can now be traced, cached, and shortcut just like their dynamic friends.
There is one more problem though. Why would the static binaries deep in the build be run by QEMU? Firebuild also intercepts the exec() calls and now it rewrites them on the fly whenever the executed binary would be statically linked!
The QEMU patch is forwarded to qemu-devel. If it lands, anyone using QEMU user-mode emulation could benefit not just Firebuild.
For Firebuild users, though, the impact is immediate. Toolchains that mix dynamic and static helpers? Cross-builds that pull in odd little statically linked utilities? Previously invisible steps in your builds? All now fair game for caching.
Firebuild 0.8.5 ships this new capability out of the box. Just update, make sure you re using a patched QEMU, and enjoy the feeling of watching even static binaries fall neatly into place in your cached build graph. Ubuntu users can get the prebuilt patched QEMU packages from the Firebuild PPA already.
Static binaries, welcome to the party!
Release 0.6.39 of the digest package
arrived at CRAN today and has
also been uploaded to Debian.
digest
creates hash digests of arbitrary R objects. It can use a number
different hashing algorithms (md5, sha-1,
sha-256, sha-512, crc32,
xxhash32, xxhash64, murmur32,
spookyhash, blake3,crc32c,
xxh3_64 and xxh3_128), and enables easy
comparison of (potentially large and nested) R language objects as it
relies on the native serialization in R. It is a mature and widely-used
package (with 86.8 million downloads just on the partial cloud mirrors
of CRAN which keep logs) as many tasks may involve caching of
objects for which it provides convenient general-purpose hash key
generation to quickly identify the various objects.
As noted last week in the 0.6.38
release note, hours after it was admitted to CRAN, I heard from the
ever-so-tireless Brian Ripley about an SAN issue on arm64 only (and
apparently non-reproducible elsewhere). He kindly provided a fix; it
needed a cast. Checking this on amd64 against our Rocker-based ASAN and UBSAN
containers (where is remains impossible to replicate, this issue is
apparently known for some arm64 issues) another micro-issue (of a
missing final argument NULL missing in one
.Call()) was detected. Both issues were fixed the same day,
and constitute the only change here. I merely waited a week to avoid a
mechanical nag triggered when release happen within a week.
My CRANberries
provides a summary of changes to the previous
version. For questions or comments use the issue tracker
off the GitHub
repo. For documentation (including the changelog)
see the documentation
site.
If you like this or other open-source work I do, you can now sponsor me at
GitHub.
I am a huge fan of Git, as I have witnessed how it has made software development so much more productive compared to the pre-2010s era. I wish all Debian source code were in Git to reap the full benefits.
Git is not perfect, as it requires significant effort to learn properly, and the ecosystem is complex with even more things to learn ranging from cryptographic signatures and commit hooks to Git-assisted code review best practices, forge websites, and CI systems.
Sure, there is still room to optimize its use, but Git certainly has proven itself and is now the industry standard. Thus, some readers might be surprised to learn that Debian development in 2025 is not actually based on Git. In Debian, the version control is done by the Debian archive itself. Each commit is a new upload to the archive, and the commit message is the 
The Debian LTS Team, funded by 
The following contributors got their Debian Developer accounts in the last two
months:
Another maintenance release of the 
