My trip to pgday.at started Wednesday at the airport in D sseldorf. I was there on time, and the plane started with an estimated flight time of about 90 minutes. About half an hour into the flight, the captain announced that we would be landing in 30 minutes - in D sseldorf, because of some unspecified technical problems. Three hours after the original departure time, the plane made another attempt, and we made it to Vienna.
setup.py install deprecation, by Colin Watson
setuptools upstream will be removing the setup.py install command
on 31 October. While this may not trickle down immediately into Debian, it does
mean that in the near future nearly all Python packages will have to use
pybuild-plugin-pyproject (though they don t necessarily have to use
pyproject.toml; this is just a question of how the packaging runs the build
system). Some of the Python team talked about this a bit at DebConf, and Colin
volunteered to write up some notes
on cases where this isn t straightforward. This page will likely grow as the
team works on this problem.
---
include:
- https://salsa.debian.org/santiago/pipeline/raw/sbuild-unshare-02-salsa-ci/salsa-ci.yml
- https://salsa.debian.org/santiago/pipeline/raw/sbuild-unshare-02-salsa-ci/pipeline-jobs.yml
Recommends packages which
don t exist in unstable. Processed (either reported
or ignored due to mis-detected problems or temporary problems) 16% of the
reports. Will continue next month./usr-move.gcc-15.:any annotations. Helmut identified the root cause to be the handling of
virtual packages and fixed it.
Release 0.2.9 of our RcppSMC package arrived at
CRAN today. RcppSMC
provides Rcpp-based bindings to R for the Sequential Monte Carlo
Template Classes (SMCTC) by Adam
Johansen described in his JSS article. Sequential
Monte Carlo is also referred to as Particle Filter
in some contexts. The package now also features the Google Summer of Code
work by Leah South
in 2017, and by Ilya Zarubin in
2021.
This release is again entirely internal. It updates the code for the
just-released RcppArmadillo
15.0.2-1, in particular opts into Armadillo 15.0.2. And it makes one
small tweak to the continuous integration setup switching to the
r-ci action.
The release is summarized below.
Courtesy of my CRANberries, there is also a diffstat report detailing changes. More information is on the RcppSMC page and the repo. Issues and bugreports should go to the GitHub issue tracker.Changes in RcppSMC version 0.2.9 (2025-09-09)
- Adjust to RcppArmadillo 15.0.* by setting
ARMA_USE_CURRENTand updating two expressions from deprecated code- Rely on r-ci GitHub Action which includes the bootstrap step
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.
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) 1279 other packages on CRAN, downloaded 41.2 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 644 times according
to Google Scholar.
Fairly shortly after the release of Armadillo 14.6.3 (which became
our precedig release 14.6.3),
Conrad released version
15.0.0 of Armadillo. It
contains several breaking changes which made it unsuitable for CRAN as is. First, the
minimum C++ standard was lifted to C++14. There are many good reasons
for doing so, but doing it unannounced with no transition offered cannot
work at CRAN. For (mostly
historical) reasons (as C++11 was once a step up from even more archaic
code) many packages still enforce C++11. These packages would
break under Armadillo
15.0.0. With some reverse-dependency checks we quickly found that this
would affect over 200 packages. Second, Armadillo frequently deprecates
code and issues a warning offering a hint towards an improved / current
alternative. That too is good practice, and recommended. But at CRAN a deprecation warning seen
leads to NOTE and an unfixed NOTEs can lead to archival which is not
great. For that reason, we had added a global muffler suppressing the
deprecation warnings. This was now removed in C++14 (as one can rely on
newer compiler attributes we cannot undo, whereas the old scheme just
used macros). Again, not something we can do at CRAN.
So I hatched the plan of offering both the final release
under the previous state of the world, i.e. 14.6.3, along with 15.0.0.
User could then opt-into 15.0.0 but have a fallback of 14.6.3 allowing
all packages to coexist. The first idea was to turn the fallback on only
if C++11 compilation was noticed. This lead still a lot of deprecation
warnings meaning we had to more strongly default to 14.6.3 and only if
users actively selected 15.0.* would they get it. This seemed to work.
We were still faced with two hard failures. Turns out one was local to a
since-archived package, the other reveal a bad interaction betweem Armadillo and gcc
for complex variables and lead to bug fix 15.0.1. Which I
wrapped and uploaded a week ago.
Release 15.0.1 was quickly seen as only temporary because I
overlooked two issues. Moving legacy and current into, respectively,
a directory of that name meant to top-level include header
armadillo remained. This broked a few use cases where
packages use a direct #include <armadillo> (which we
do not recommend as it may miss a few other settings we apply for the R
case). The other is that an old test for limited LAPACK capabilities
made noise in some builds (for example on Windows). As (current) R
versions generally have sufficient LAPACK and BLAS, this too has been
removed.
We have tested and rested these changed extensively. The usual
repository with the logs shows eight reverse-dependency runs each of
which can take up to a day. This careful approach, together with pacing
uploads at CRAN usually works. We got a NOTE for seven uploads in six
months for this one, but a CRAN maintainer quickly advanced it, and the
fully automated test showed no regression or other human intervention
which is nice given the set of changes, and the over 1200 reverse
dependencies.
The changes since the last announced CRAN release 14.6.3 follow.
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 Rcpp R-Forge page.Changes in RcppArmadillo version 15.0.2-1 (2025-09-08)
- Upgraded to Armadillo release 15.0.2-1 (Medium Roast)
- Optionally use OpenMP parallelisation for fp16 matrix multiplication
- Faster vectorisation of cube tubes
- Provide a top-level include file
armadilloas fallback (#480)- Retire the no-longer-needed check for insufficient LAPACK as R now should supply a sufficient libRlapack (when used) (#483)
- Two potential narrowing warnings are avoided via cast
Changes in RcppArmadillo version 15.0.1-1 (2025-09-01)
- Upgraded to Armadillo release 15.0.1-1 (Medium Roast)
- Workaround for GCC compiler bug involving misoptimisation of complex number multiplication
- This version contains both 'legacy' and 'current' version of Armadillo (see also below). Package authors should set a '#define' to select the 'current' version, or select the 'legacy' version (also chosen as default) if they must. See GitHub issue #475 for more details.
- Updated DESCRIPTION and README.md
Changes in RcppArmadillo version 15.0.0-1 (2025-08-21) (GitHub Only)
- Upgraded to Armadillo release 15.0.0-1 (Medium Roast)
- C++14 is now the minimum required C++ standard
- Aded preliminary support for matrices with half-precision fp16 element type
- Added second form of
cond()to allow detection of failures- Added
repcube()- Added
.freeze()and.unfreeze()member functions towall_clock- Extended
conv()andconv2()to accept the "valid" shape argument- Also includes Armadillo 14.6.3 as fallback for C++11 compilations
- This new 'dual' setup had been rigorously tested with five interim pre-releases of which several received full reverse-dependency checks
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.
Back in March, with version 4.17.0, Lean introduced partial_fixpoint, a new way to define recursive functions. I had drafted a blog post for the official Lean FRO blog back then, but forgot about it, and with the Lean FRO blog discontinued, I ll just publish it here, better late than never.
With the partial_fixpoint mechanism we can model possibly partial functions (so those returning an Option) without an explicit termination proof, and still prove facts about them. See the corresponding section in the reference manual for more details.
On the Lean Zulip, I was asked if we can use this feature to define the McCarthy 91 function and prove it to be total. This function is a well-known tricky case for termination proofs.
First let us have a brief look at why this function is tricky to define in a system like Lean. A naive definition like
def f91 (n : Nat) : Nat :=
if n > 100
then n - 10
else f91 (f91 (n + 11))termination_by 101 - n) is doomed, because we would have to prove facts about the function s behaviour (namely that f91n = f91101 = 91 for 90 n 100) and at the same time use that fact in the termination proof that we have to provide while defining the function. (The Wikipedia page spells out the proof.)
We can make well-founded recursion work if we change the signature and use a subtype on the result to prove the necessary properties while we are defining the function. Lean by Example shows how to do it, but for larger examples this approach can be hard or tedious.
With partial_fixpoint, we can define the function as a partial function without worrying about termination. This requires a change to the function s signature, returning an Option Nat:
def f91 (n : Nat) : Option Nat :=
if n > 100
then pure (n - 10)
else f91 (n + 11) >>= f91
partial_fixpointOption.none is then used for those inputs for which the function does not terminate.
This function definition is accepted and the function runs fine as compiled code:
#eval f91 42some 91.
The crucial question is now: Can we prove anything about f91 In particular, can we prove that this function is actually total?
Since we now have the f91 function defined, we can start proving auxillary theorems, using whatever induction schemes we need. In particular we can prove that f91 is total and always returns 91 for n 100:
theorem f91_spec_high (n : Nat) (h : 100 < n) : f91 n = some (n - 10) := by
unfold f91; simp [*]
theorem f91_spec_low (n : Nat) (h : n 100) : f91 n = some 91 := by
unfold f91
rw [if_neg (by omega)]
by_cases n < 90
rw [f91_spec_low (n + 11) (by omega)]
simp only [Option.bind_eq_bind, Option.some_bind]
rw [f91_spec_low 91 (by omega)]
rw [f91_spec_high (n + 11) (by omega)]
simp only [Nat.reduceSubDiff, Option.some_bind]
by_cases h : n = 100
simp [f91, *]
exact f91_spec_low (n + 1) (by omega)
theorem f91_spec (n : Nat) : f91 n = some (if n 100 then 91 else n - 10) := by
by_cases h100 : n 100
simp [f91_spec_low, *]
simp [f91_spec_high, Nat.lt_of_not_le _ , *]
-- Generic totality theorem
theorem f91_total (n : Nat) : (f91 n).isSome := by simp [f91_spec]theorem f91_spec_low is itself recursive in a somewhat non-trivial way, but Lean can figure that out all by itself. Use termination_by? if you are curious.)
This is already a solid start! But what if we want a function of type f91! (n : Nat) : Nat, without the Option? Then can derive that from the partial variant, as we have just proved that to be actually total:
def f91! (n : Nat) : Nat := (f91 n).get (f91_total n)
theorem f91!_spec (n : Nat) : f91! n = if n 100 then 91 else n - 10 := by
simp [f91!, f91_spec]partial_fixpoint one can decouple the definition of a function from a termination proof, or even model functions that are not terminating on all inputs. This can be very useful in particular when using Lean for program verification, such as with the aeneas package, where such partial definitions are used to model Rust programs.
| Series: | Cyteen #2 |
| Publisher: | DAW |
| Copyright: | January 2009 |
| ISBN: | 0-7564-0592-0 |
| Format: | Mass market |
| Pages: | 682 |
Some additional thoughts after re-reading Regenesis in 2025: Cyteen mostly held up to a re-reading and I had fond memories of Regenesis and hoped that it would as well. Unfortunately, it did not. I think I can see the shape of what I enjoyed the first time I read it, but I apparently was in precisely the right mood for this specific type of political power fantasy. I did at least say that you have to be comfortable with pages of internal monologue, but on re-reading, there was considerably more of that than I remembered and it was quite repetitive. Ari spends most of the book chasing her tail, going over and around and beside the same theories that she'd already considered and worrying over the nuances of every position. The last time around, I clearly enjoyed that; this time, I found it exhausting and not very well-written. The political maneuvering is not that deep; Ari just shows every minutia of her analysis. Regenesis also has more about the big questions of how to design a society and the role of the azi than I had remembered, but I'm not sure those discussions reach any satisfying conclusions. The book puts a great deal of effort into trying to convince the reader that Ari is capable of designing sociological structures that will shape Union society for generations to come through, mostly, manipulation of azi programming (deep sets is the term used in the book). I didn't find this entirely convincing the first time around, and I was even less convinced in this re-read. Human societies are a wicked problem, and I don't find Cherryh's computer projections any more convincing than Asimov's psychohistory. Related, I am surprised, in retrospect, that the authoritarian underpinnings of this book didn't bother me more on my first read. They were blatantly obvious on the second read. This felt like something Cherryh put into these books intentionally, and I think it's left intentionally ambiguous whether the reader is supposed to agree with Ari's goals and decisions, but I was much less in the mood on this re-read to read about Ari making blatantly authoritarian decisions about the future of society simply because she's smart and thinks she, unlike others, is acting ethically. I say this even though I like Ari and mostly enjoyed spending time in her head. But there is a deep fantasy of being able to reprogram society at play here that looks a lot nastier from the perspective of 2025 than apparently it did to me in 2012. Florian and Catlin are still my favorite characters in the series, though. I find it oddly satisfying to read about truly competent bodyguards, although like all of the azi they sit in an (I think intentionally) disturbing space of ambiguity between androids and human slaves. The somewhat too frank sexuality from Cyteen is still present in Regenesis, but I found it a bit less off-putting, mostly because everyone is older. The authoritarian bent is stronger, since Regenesis is the story of Ari consolidating power rather than the underdog power struggle of Cyteen, and I had less tolerance for it on this re-read. The main problem with this book on re-read was that I bogged down about halfway through and found excuses to do other things rather than finish it. On the first read, I was apparently in precisely the right mood to read about Ari building a fortified home for all of her friends; this time, it felt like endless logistics and musings on interior decorating that didn't advance the plot. Similarly, Justin and Grant's slow absorption into Ari's orbit felt like a satisfying slow burn friendship in my previous reading and this time felt touchy and repetitive. I was one of the few avid defenders of Regenesis the first time I read it, and sadly I've joined the general reaction on a re-read: This is not a very good book. It's too long, chases its own tail a bit too much, introduces a lot more authoritarianism and doesn't question it as directly as I wanted, and gets even deeper into Cherryh's invented pseudo-psychology than Cyteen. I have a high tolerance for the endless discussions of azi deep sets and human flux thinking, and even I got bored this time through. On re-read, this book was nowhere near as good as I thought it was originally, and I would only recommend it to people who loved Cyteen and who really wanted a continuation of Ari's story, even if it is flabby and not as well-written. I have normally been keeping the rating of my first read of books, but I went back and lowered this one by two points to ensure it didn't show as high on my list of recommendations.
I ve noticed that procrastination and inability to be consistently productive at work has become quite common in recent years. This is clearly visible in younger people who have grown up with an endless stream of entertainment literally at their fingertips, on their mobile phone. It is however a trap one can escape from with a little bit of help.
Procrastination is natural they say humans are lazy by nature after all. Probably all of us have had moments when we choose to postpone a task we know we should be working on, and instead spent our time doing secondary tasks (valorisation). Classic example is cleaning your apartment when you should be preparing for an exam. Some may procrastinate by not doing any work at all, and just watching YouTube videos or the like. To some people, typically those who are in their 20s and early in their career, procrastination can be a big challenge and finding the discipline to stick to planned work may need intentional extra effort, and perhaps even external help.
During my 20+ year career in software development I ve been blessed to work with engineers of various backgrounds and each with their unique set of strengths. I have also helped many grow in various areas and overcome challenges, such as lack of intrinsic motivation and managing procrastination, and some might be able to get it in check with some simple advice.
texlive packages.
However, it was not so easy to just remove texlive with a simple apt remove command. I had to remove the texlive packages from /usr/bin. Then I ran into other errors. Hours after I started the upgrade, I realized I preferred having my system as it was before, as I had to travel to Noida the next day. Needless to say, I wanted to go to sleep rather than fix my broken system. Only if I had a way to go back to my system before I started upgrading, it would have saved a lot of trouble for me. I ended up installing Trixie from scratch.
It turns out that there was a way to recover to the state before the upgrade - using Timeshift to roll back the system to a state (in our example, it is the state before the upgrade process started) in the past. However, it needs the Btrfs filesystem with appropriate subvolumes, not provided by Debian installer in their guided partitioning menu.
I have set it up after a few weeks of the above-mentioned incident. Let me demonstrate how it works.
/boot and turned on the bootable flag and then selected Done setting up the partition.
df -h to have a look at how our disk is partitioned. In my case, the output was:
# df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 1.6G 344.0K 1.6G 0% /run
devtmpfs 7.7G 0 7.7G 0% /dev
/dev/sdb1 3.7G 3.7G 0 100% /cdrom
/dev/mapper/sda2_crypt 952.9G 5.8G 950.9G 0% /target
/dev/sda1 919.7M 260.0K 855.8M 0% /target/boot
df -h shows us that /dev/mapper/sda2_crypt and /dev/sda1 are mounted on /target and /target/boot respectively.
Let s unmount them. For that, we run:
# umount /target
# umount /target/boot
/mnt.
# mount /dev/mapper/sda2_crypt /mnt
/mnt directory.
# cd /mnt
/mnt # ls
@rootfs
@rootfs subvolume to @.
/mnt # mv @rootfs @
/mnt # ls
@
@home.
/mnt # btrfs subvolume create @home
Create subvolume './@home'
ls now, we will see there are two subvolumes:
/mnt # ls
@ @home
/dev/mapper/sda2_crypt to /target
/mnt # mount -o noatime,space_cache=v2,compress=zstd,ssd,discard=async,subvol=@ /dev/mapper/sda2_crypt /target/
/home.
/mnt # mkdir /target/home/
/home directory with subvol=@home option.
/mnt # mount -o noatime,space_cache=v2,compress=zstd,ssd,discard=async,subvol=@home /dev/mapper/sda2_crypt /target/home/
/dev/sda1 to /target/boot.
/mnt # mount /dev/sda1 /target/boot/
/target/etc/fstab. Unfortunately, vim is not installed in this console. The only way to edit is Nano.
nano /target/etc/fstab
fstab file to look similar to the one in the screenshot above. I am pasting the fstab file contents below for easy reference.
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/sda2_crypt / btrfs noatime,compress=zstd,ssd,discard=async,space_cache=v2,subvol=@ 0 0
/dev/mapper/sda2_crypt /home btrfs noatime,compress=zstd,ssd,discard=async,space_cache=v2,subvol=@home 0 0
# /boot was on /dev/sda1 during installation
UUID=12842b16-d3b3-44b4-878a-beb1e6362fbc /boot ext4 defaults 0 2
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
Ctrl+O followed by pressing Enter to save the file. Then press Ctrl+X to quit Nano. Now, preview the fstab file by running
cat /target/etc/fstab
Ctrl + Alt + F1 to go back to the installer.
Screenshot of Debian installer installing the base system.
linux-image-amd64.
After this, the installer will ask you a few more questions. For desktop environment, I chose KDE Plasma. You can choose the desktop environment as per your liking. I will not cover the rest of the installation process and assume that you were able to install from here.
ravi to the suoders file (/etc/sudoers) so that ravi can run commands with sudo. Follow this if you would like to do the same.
Now we set up zram as swap. First, install zram-tools.
sudo apt install zram-tools
/etc/default/zramswap and make sure to have the following lines are uncommented:
ALGO=lz4
PERCENT=50
sudo systemctl restart zramswap
lsblk now, you should see the below-mentioned entry in the output:
zram0 253:0 0 7.8G 0 disk [SWAP]
timeshift, which can be done by running
sudo apt install timeshift
I have been using my Samsung Galaxy Tab A (2015) with PostmarketOS on and off since last year. It serves as a really good e-book reader with KOReader installed on it. Have tried phosh and plasma-mobile on it, works nicely but slows the device down heavily (2 GB RAM and old processor) so I use MATE Desktop environment on it.Lately I have started using this tablet along with my laptop as a second screen for work. And it has been working super nicely for that. The only issue being that I have to manually rotate the screen to landscape every time I reboot the device. It resets the screen orientation to portrait after a reboot. So I went through the pmOS wiki and a neat nice hack documented there worked very well for me. First we will test if the auto-rotate sensor works and if we can read values from it. So we install some basic necessary packages$ sudo apk add xrandr xinput inotify-tools iio-sensor-proxyiio-sensor-proxy sudo rc-update add iio-sensor-proxymonitor-sensoruser@samsung-gt58 ~> monitor-sensor
Waiting for iio-sensor-proxy to appear
+++ iio-sensor-proxy appeared
=== Has accelerometer (orientation: normal, tilt: vertical)
=== Has ambient light sensor (value: 5.000000, unit: lux)
=== No proximity sensor
=== No compass
Light changed: 14.000000 (lux)
Accelerometer orientation changed: left-up
Tilt changed: tilted-down
Light changed: 12.000000 (lux)
Tilt changed: vertical
Light changed: 13.000000 (lux)
Light changed: 11.000000 (lux)
Light changed: 13.000000 (lux)
Accelerometer orientation changed: normal
Light changed: 5.000000 (lux)
Light changed: 6.000000 (lux)
Light changed: 5.000000 (lux)
Accelerometer orientation changed: right-up
Light changed: 3.000000 (lux)
Light changed: 4.000000 (lux)
Light changed: 5.000000 (lux)
Light changed: 12.000000 (lux)
Tilt changed: tilted-down
Light changed: 19.000000 (lux)
Accelerometer orientation changed: bottom-up
Tilt changed: vertical
Light changed: 1.000000 (lux)
Light changed: 2.000000 (lux)
Light changed: 4.000000 (lux)
Accelerometer orientation changed: right-up
Tilt changed: tilted-down
Light changed: 11.000000 (lux)
Accelerometer orientation changed: normal
Tilt changed: vertical
Tilt changed: tilted-down
Light changed: 18.000000 (lux)
Light changed: 21.000000 (lux)
Light changed: 22.000000 (lux)
Light changed: 19.000000 (lux)
Accelerometer orientation changed: left-up
Light changed: 17.000000 (lux)
Tilt changed: vertical
Light changed: 14.000000 (lux)
Tilt changed: tilted-down
Light changed: 16.000000 (lux)
Light changed: 18.000000 (lux)
Light changed: 17.000000 (lux)
Light changed: 18.000000 (lux)
Light changed: 17.000000 (lux)
Light changed: 18.000000 (lux)
Light changed: 17.000000 (lux)
Light changed: 18.000000 (lux)
Light changed: 17.000000 (lux)
#!/bin/sh
killall monitor-sensor
monitor-sensor > /dev/shm/sensor.log 2>&1 &
while inotifywait -e modify /dev/shm/sensor.log; do
ORIENTATION=$(tail /dev/shm/sensor.log grep &aposorientation&apos tail -1 grep -oE &apos[^ ]+$&apos)
case "$ORIENTATION" in
normal)
xrandr -o normal
xinput set-prop "Goodix Capacitive TouchScreen" "Coordinate Transformation Matrix" 1 0 0 0 1 0 0 0 1
;;
left-up)
xrandr -o left
xinput set-prop "Goodix Capacitive TouchScreen" "Coordinate Transformation Matrix" 0 -1 1 1 0 0 0 0 1
;;
bottom-up)
xrandr -o inverted
xinput set-prop "Goodix Capacitive TouchScreen" "Coordinate Transformation Matrix" -1 0 1 0 -1 1 0 0 1
;;
right-up)
xrandr -o right
xinput set-prop "Goodix Capacitive TouchScreen" "Coordinate Transformation Matrix" 0 1 0 -1 0 1 0 0 1
;;
esac
doneauto-rotate-screen.sh
xinput --list , make sure to type this on the device terminal. user@samsung-gt58 ~> xinput --list
* Virtual core pointer id=2 [master pointer (3)]
* * Virtual core XTEST pointer id=4 [slave pointer (2)]
* * Zinitix Capacitive TouchScreen id=10 [slave pointer (2)]
* * Toad One Plus id=12 [slave pointer (2)]
* Virtual core keyboard id=3 [master keyboard (2)]
* Virtual core XTEST keyboard id=5 [slave keyboard (3)]
* GPIO Buttons id=6 [slave keyboard (3)]
* pm8941_pwrkey id=7 [slave keyboard (3)]
* pm8941_resin id=8 [slave keyboard (3)]
* Zinitix Capacitive TouchScreen id=11 [slave keyboard (3)]
* samsung-a2015 Headset Jack id=9 [slave keyboard (3)]
Zinitix capacitive screen, it will be different for yours.Once your script is ready with the correct touchscreen name. Save and make the script executable. chmod +x auto-rotate-screen.sh Then test your script in your terminal ./auto-rotate.sh , stop the script using Ctrl + CNow we need add this script to auto-start. On MATE DE you can go to System > Control Center > Startup Applications, then click on Custom Add button, browse the script location, give it a name and then click on Add button. Now reboot the tablet/device, login and see the auto rotation working. apt-get update, which failed and broke subsequent provisioning steps. The errors reported by apt-get indicated that there was no route to the service in question, which more accurately probably meant that there was not yet a route to the service. But there was shortly after, when I investigated.
This was surprising because the apt-get invocations occur in a cloud-init sequence that s explicitly ordered after the network is configured according to systemd-networkd-wait-online. Investigation eventually led to similar issues encountered in other environments reported in Debian bug #1111791, systemd: network-online.target reached before IPv6 address is ready . The issue described in that bug is identical to mine, but the bug is tagged wontfix. The behavior is considered correct.
systemd-networkd behavior is correct, and it s also not something we d want to override in the cloud images. Without explicit configuration, systemd can t accurately infer the intended network configuration of a given system. If a system is IPv6-only, systemd-networkd-wait-online will introduce unexpected delays in the boot process if it waits for IPv4, and vice-versa. If it assumes dualstack, things are even worse because it would block for a long time (approximately two minutes) in any single stack network before failing, leaving the host in degraded state. So the most reasonable default behavior is to block until any protocol is configured.
For these same reasons, we can t change the systemd-networkd-wait-online configuration in our cloud images. All of the cloud environments we support offer both single stack and dual stack networking, so we preserve systemd s default behavior.
What s causing problems here is that IPv6 takes significantly longer to configure due to its more complex router solicitation + router advertisement + DHCPv6 setup process. So in this particular case, where I ve got a dualstack VM that needs to access a v6-only apt server during the provisioning process, I need to find some mechanism to override systemd s default behavior and wait for IPv6 connectivity specifically.
systemd-networkd-wait-online.service is trivial. Unfortunately, this doesn t give us everything we actually need. We still need to invoke systemctl daemon-reload to get systemd to actually apply the changes after we ve written them, and of course we need to do that before the service actually runs. Cloud-init provides a bootcmd module that lets us run shell commands very early in the boot process , but it runs too early: it runs before we ve written out our configuration files. Similarly, it provides a runcmd module, but scripts there are towards the end of the boot process, far too late to be useful.
Instead of using the bootcmd facility, to simply reload systemd s config, it seemed possible that we could both write the config and trigger the reload, similar to the following:
bootcmd:
- mkdir -p /etc/systemd/system/systemd-networkd-wait-online.service.d
- echo "[Service]" > /etc/systemd/system/systemd-networkd-wait-online.service.d/10-netplan.conf
- echo "ExecStart=" >> /etc/systemd/system/systemd-networkd-wait-online.service.d/10-netplan.conf
- echo "ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --operational-state=routable --any --ipv6" >> /etc/systemd/system/systemd-networkd-wait-online.service.d/10-netplan.conf
- systemctl daemon-reload
systemd-networkd-wait-online.service has completed before bootcmd is executed:
root@sid-tmp2:~# journalctl --no-pager -l -u systemd-networkd-wait-online.service
Aug 29 17:02:12 sid-tmp2 systemd[1]: Starting systemd-networkd-wait-online.service - Wait for Network to be Configured...
Aug 29 17:02:13 sid-tmp2 systemd[1]: Finished systemd-networkd-wait-online.service - Wait for Network to be Configured
.
root@sid-tmp2:~# grep -F 'config-bootcmd ran' /var/log/cloud-init.log
2025-08-29 17:02:14,766 - handlers.py[DEBUG]: finish: init-network/config-bootcmd: SUCCESS: config-bootcmd ran successfully and took 0.467 seconds
systemd-networkd-wait-online.
APT::Update::Pre-Invoke hook that s executed just before apt s update operation. By writing the following to a file in /etc/apt/apt.conf.d/, we re able to ensure that we have IPv6 connectivity before apt-get tries accessing the network. This cloud-config snippet accomplishes that:
- path: /etc/apt/apt.conf.d/99-wait-for-ipv6
content:
APT::Update::Pre-Invoke "/usr/lib/systemd/systemd-networkd-wait-online --operational-state=routable --any --ipv6";
systemd-networkd-wait-online directly from a cloud-init bootcmd. Similar to the first solution, it s not exactly correct because the host has already reached network-online.target, but it does block enough of cloud-init that package installation happens only after it completes. The cloud-config snippet for this is
bootcmd:
- [/usr/lib/systemd/systemd-networkd-wait-online, --operational-state=routable, --any, --ipv6]
systemd-networkd-wait-online to wait for IPv6 connectivity for future reboots. Even though cloud-init won t necessarily run in those cases, and many cloud VMs never reboot at all, it does complete the solution. Additionally, it solves the problem for any derivative images that may be created based on the running VM s state. (At least if we can be certain that instances of those derivative images will never run in an IPv4-only network!)
write_files:
- path: /run/systemd/system/systemd-networkd-wait-online.service.d/99-ipv6-wait.conf
content:
[Service]
ExecStart=
ExecStart=/lib/systemd/systemd-networkd-wait-online --any --operational-state=routable --ipv6
cloud-init to support a configuration key allowing the admin to specify the required protocols. Based on the presence of this key, cloud-init could reconfigure systemd-networkd-wait-online.service accordingly. Alternatively it could set the appropriate RequiredFamilyForOnline= value in the generated .network file. cloud-init supports multiple network configuration backends, so each of those would need to be updated. If using the systemd-networkd configuration renderer, this should be straightforward, but Debian uses the netplan renderer, so that tool might also need to be taught to pass such a configuration along to systemd-networkd.
Some time ago, I wanted to encrypt a bunch of data in an application I was writing in Rust, mostly to be stored in a database, but also session cookies and sensitive configuration variables.
Since Rust is widely known as a secure-yet-high-performance programming language, I was expecting that there would be a widely-used crate that gave me a secure, high-level interface to strong, safe cryptography.
Imagine my surprise when I discovered that just didn t seem to exist.
Don t get me wrong: Rust is replete with fast, secure, battle-tested cryptographic primitives.
The RustCrypto group provides all manner of robust, widely-used crates for all manner of cryptography-related purposes.
They re the essential building blocks for practical cryptosystems, but using them directly in an application is somewhat akin to building a car from individual atoms of iron and carbon.
So I wrote my own high-level data encryption library, called it StrongBox, and have been happily encrypting and decrypting data ever since.
StrongBox trait, which has only two methods: encrypt and decrypt, each of which takes just two arguments.
The first argument is the plaintext (for encrypt) or the ciphertext (for decrypt) to work on.
The second argument is the encryption context, for use as Authenticated Additional Data, an important part of many uses of encryption.
There s essentially no configuration or parameters to get wrong.
You can t choose the encryption algorithm, or block cipher mode, and you don t have to worry about generating a secure nonce.
You create a StrongBox with a key, and then you call encrypt and decrypt.
That s it.
StructBox.
When I started using StrongBox in the wild , it quickly became clear that what I almost always wanted to encrypt in my application wasn t some ethereal plaintext .
I wanted to encrypt things, specifically structs (and enums).
So, through the magic of Rust derive macros, I built StructBox, which provides encrypt and decrypt operations on any Serde-able type.
Given that using Serde encoders can be a bit fiddly to use, it s virtually easier to get an encrypted, serialized struct than it is to get a plaintext serialized struct.
StemStrongBox type.
You ll typically start off by creating a StemStrongBox with the root key, and then derive whatever other StrongBoxes you need, for encrypting and decrypting different kinds of data.
RotatingStrongBox type.
This comes in handy when you re encrypting a lot of ephemeral data, like cookies (or server-side session data).
It provides a way to automatically expire old data, and prevents attacks that become practical when large amounts of data are encrypted using a single key.
As per the previous Polkit blog post the policykit framwork has lost the ability to understand its own .pkla files and policies need to be expressed in Javascript with .rules files now.
To re-enable allowing remote users (think ssh) to reboot, hibernate, suspend or power off the local system, create a 10-shutdown-reboot.rules file in /etc/polkit-1/rules.d/:
systemctl restart polkit.
The x13binary team
is happy to share the availability of Release 1.1.61.1 of the x13binary
package providing the X-13ARIMA-SEATS program
by the US Census Bureau which arrived on CRAN earlier today.
This release responds to a recent change in gfortran
version 15 which now picks up a missing comma in a Fortran format string
for printing output. The change is literally a one-char
addition which we also reported upstream. At the same time this release
also updates one README.md URL to an archive.org URL of an apparently
deleted reference. There is now also an updated upstream release 1.1-62
which we should package next.
Courtesy of my CRANberries, there
is also a diffstat report for this release showing
changes to the previous release.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.
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) 1268 other packages on CRAN, downloaded 41 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 642 times according
to Google Scholar.
Conrad made three minor
bug fix releases since the 4.6.0
release last month. We need to pace releases at CRAN so we do not immediately
upload there on each upstream release and then CRAN also had the usual (and
well-deserved) summer rest leading to a slight delay relative to the
last upstream. The minor changes in the three releases are summarized
below. All our releases are always available via the GitHub repo and
hence also via r-universe, and
still rigorously tested via our own reverse-dependency checks. We also
note that the package once again passed with flying colours and no human
intervention which remains impressive given the over 1200 reverse
dependencies.
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 Rcpp R-Forge page.Changes in RcppArmadillo version 14.6.3-1 (2025-08-14)
- Upgraded to Armadillo release 14.6.3 (Caffe Mocha)
- Fix OpenMP related crashes in
Cube::slice()on Arm64 CPUsChanges in RcppArmadillo version 14.6.2-1 (2025-08-08) (GitHub Only)
- Upgraded to Armadillo release 14.6.2 (Caffe Mocha)
- Fix for corner-case speed regression in
sum()- Better handling of OpenMP in
omit_nan()andomit_nonfinite()Changes in RcppArmadillo version 14.6.1-1 (2025-07-21) (GitHub Only)
- Upgraded to Armadillo release 14.6.1 (Caffe Mocha)
- Fix for speed regression in
mean()- Fix for detection of compiler configuration
- Use of
powoptimization now optional
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.
Historically the primary way to contribute to Debian has been to email the Debian bug tracker with a code patch. Now that 92% of all Debian source packages are hosted at salsa.debian.org the GitLab instance of Debian more and more developers are using Merge Requests, but not necessarily in the optimal way. In this post I share what I ve found the best practice to be, presented in the natural workflow from forking to merging.
Following the Browse link opens the Debian package source repository, which is usually a project page on Salsa. To contribute, start by clicking the Fork button, select your own personal namespace and, under Branches to include, pick Only the default branch to avoid including unnecessary temporary development branches.
Once forking is complete, clone it with git-buildpackage. For this example repository, the exact command would be gbp clone --verbose git@salsa.debian.org:otto/glow.git.
Next, add the original repository as a new remote and pull from it to make sure you have all relevant branches. Using the same fork as an example, the commands would be:
git remote add go-team https://salsa.debian.org/go-team/packages/glow.git
gbp pull --verbose --track-missing go-teamgbp pull command can be repeated whenever you want to make sure the main branches are in sync with the original repository. Finally, run gitk --all & to visually browse the Git history and note the various branches and their states in the two remotes. Note the style in comments and repository structure the project has and make sure your contributions follow the same conventions to maximize the chances of the maintainer accepting your contribution.
It may also be good to build the source package to establish a baseline of the current state and what kind of binaries and .deb packages it produces. If using Debcraft, one can simply run debcraft build in the Git repository.
git checkout -b <branch name> to clearly separate your work from the main branch.
When making changes, remember to follow the conventions you already see in the package. It is also important to be aware of general guidelines on how to make good Git commits.
If you are not able to immediately finish coding, it may be useful to publish the Merge Request as a draft so that the maintainer and others can see that you started working on something and what general direction your change is heading in.
If you don t finish the Merge Request in one sitting and return to it another day, you should remember to pull the Debian branch from the original Debian repository in case it has received new commits. This can be done easily with these commands (assuming the same remote and branch names as in the example above):
git fetch go-team
git rebase -i go-team/debian/latestgit push --force. While GitLab does allow squashing, I recommend against it. It is better that the submitter makes sure the final version is a neat and clean set of commits that the receiver can easily merge without having to do any rebasing or squashing themselves.
When ready, remove the draft status of the Merge Request and wait patiently for review. If the maintainer does not respond in several days, try sending an email to <source package name>@packages.debian.org, which is the official way to contact maintainers. You could also post a comment on the MR and tag the last few committers in the same repository so that a notification email is triggered. As a last resort, submit a bug report to the Debian bug tracker to announce that a Merge Request is pending review. This leaves a permanent record for posterity (or the Debian QA team) of your contribution. However, most of the time simply posting the Merge Request in Salsa is enough; excessive communication might be perceived as spammy, and someone needs to remember to check that the bug report is closed.
When you see a new Merge Request, try to review it within a couple of days. If you cannot review in a reasonable time, posting a small note that you intend to review it later will feel better to the submitter compared to not getting any response.
Personally, I have a habit of assigning myself as a reviewer so that I can keep track of my whole review queue at https://salsa.debian.org/dashboard/merge_requests?reviewer_username=otto, and I recommend the same to others. Seeing the review assignment happen is also a good way to signal to the submitter that their submission was noted.
When adding the first comment, I choose Start review and for the following remarks Add to review. Finally, I click Finish review and Submit review, which will trigger one single email to the submitter with all my feedback. I try to avoid using the Add comment now option, as each such comment triggers a separate notification email to the submitter.
git pull <remote url> <branch name>. There is no need to run git remote add as pulling using a URL directly works too and saves from needing to clean up old remotes later.
Pulling the Merge Request contents locally allows me to build, run and inspect the code deeply and review the commits with full metadata in gitk or equivalent.
debian/ subdirectory that contains the actual Debian packaging. For the same reason, a typical Debian packaging Git repository has a debian/latest branch that has changes only in the debian/ subdirectory while the surrounding upstream files are the actual upstream files and have the actual upstream Git history. For details, see my post explaining Debian source packages in Git.
Because of this Git branch structure, importing a new upstream version will typically modify three branches: debian/latest, upstream/latest and pristine-tar. When doing a Merge Request for a new upstream import, only submit one Merge Request for one branch: which means merging your new changes to the debian/latest branch.
There is no need to submit the upstream/latest branch or the pristine-tar branch. Their contents are fixed and mechanically imported into Debian. There are no changes that the reviewer in Debian can request the submitter to do on these branches, so asking for feedback and comments on them is useless. All review, comments and re-reviews concern the content of the debian/latest branch only.
It is not even necessary to use the debian/latest branch for a new upstream version. Personally, I always execute the new version import (with gbp import-orig --verbose --uscan) and prepare and test everything on debian/latest, but when it is time to submit it for review, I run git checkout -b import/$(dpkg-parsechangelog -SVersion) to get a branch named e.g. import/1.0.1 and then push that for review.
gbp pull to automate fetching all branches from the submitter s fork. Assume you are reviewing a submission targeting the Glow package repository and there is a Merge Request from user otto s fork. As the maintainer, you would run the commands:
git remote add otto https://salsa.debian.org/otto/glow.git
gbp pull --verbose ottogbp pull --force will not suffice, and this trick of manually fetching each branch and resetting them to the submitter s version is needed:
for BRANCH in pristine-tar upstream debian/latest
do
git checkout $BRANCH
git reset --hard origin/$BRANCH
git pull --force https://salsa.debian.org/otto/glow.git $BRANCH
done
Like each month, have a look at the work funded by Freexian s Debian LTS offering.
sshd listener process into two pieces: a minimal network listener (still
called sshd), and an sshd-session process dealing with each individual
session. Before this change, when sshd received an incoming connection, it
forked and re-executed itself with some special parameters to deal with it;
after this change, it forks and executes sshd-session instead, and sshd no
longer accepts the parameters it used to accept for this.sshd
received the connection and tried to hand it off to a freshly-executed copy of
the new sshd binary on disk, which no longer supports this. This wasn t much
of a problem when upgrading OpenSSH on its own or with a small number of other
packages, but in release upgrades it left a large gap when you can t SSH to the
system any more, and if anything fails in that interval then you could be in
trouble.openssh-server package divert /usr/sbin/sshd to
/usr/sbin/sshd.session-split before the unpack step of an upgrade from before
9.8, then removing the diversion and moving the new file into place once it s
ready to restart the service. This reduces the period when new connections fail
to a minimum.
sshd, check for a compatible version of
the OpenSSL library when they start up. This check used to be very picky, among
other things requiring both the major and minor part of the version number to
match. OpenSSL 3 has a better versioning policy,
and so OpenSSH 9.4p1 relaxed this check.sshd stopped working. This
couldn t be fixed by a change in trixie; we needed to change bookworm in advance
of the upgrade so that it would tolerate newer versions of OpenSSL, and time was
tight if we wanted this to be available before the release of Debian 13.stable-updates
mechanism for exactly this sort of thing, and the stable release managers kindly
accepted Colin s proposal to fix this there.
stable-updates / bookworm-updates, which is enabled by default) before
starting the upgrade to trixie, everything should be fine.
python3-dev:any, libpython3-dev) yetkconf_update (thanks to Aur lien COUDERC)trixie release, about two thirds of the packages can satisfy their cross
Build-Depends and about half of the packages actually can be cross built.
hurd-any mostly reviewing Samuel s patches. He proposed a
patch for improving bash s detection of its pipesize
and a change to dpkg-shlibdeps to improve behavior for building cross toolchains.glibc upgrade failure
induced by a /usr-move mitigation of systemd and sent a patch and regression
fix both of which reached trixie in time. Thanks to Aurelien Jarno and the
release team for their timely cooperation.Architecture: all packages in a multiarch context in order to improve the
long-standing interpreter problem. With help from Tollef Fog Heen better
semantics were discovered and agreement was reached with Guillem Jover and
Julian Andres Klode to consider this change. The idea is to record a concrete
architecture for every Architecture: all package in the dpkg database and
enable choosing it as non-native.debvm.Next.