title: Debian Day 30 years online in Brazil
description: by Paulo Henrique de Lima Santana (phls)
published: true
date: 2025-03-01T17:39:03.284Z
tags: blog, english
editor: markdown
dateCreated: 2023-08-25T16:00:00.000Z
In 2023 the traditional Debian Day is
being celebrated in a special way, after all on August 16th Debian turned 30
years old!
To celebrate this special milestone in the Debian's life, the
Debian Brasil community organized a week with
talks online from August 14th to 18th. The event was named
Debian 30 years.
Two talks were held per night, from 7:00 pm to 10:00 pm, streamed on the
Debian Brasil channel on YouTube totaling 10 talks. The recordings are also available on the
Debian Brazil channel on Peertube.
We had the participation of 9 DDs, 1 DM, 3 contributors in 10 activities.
The live audience varied a lot, and the peak was on the preseed talk with
Eriberto Mota when we had 47 people watching.
Thank you to all participants for the contribution you made to the success of
our event.
Antonio Terceiro
Aquila Macedo
Charles Melara
Daniel Lenharo de Souza
David Polverari
Eriberto Mota
Giovani Ferreira
Jefferson Maier
Lucas Kanashiro
Paulo Henrique de Lima Santana
Sergio Durigan Junior
Thais Araujo
Thiago Andrade
Veja abaixo as fotos de cada atividade:
Nova gera o: uma entrevista com iniciantes no projeto Debian
Instala o personalizada e automatizada do Debian com preseed
Manipulando patches com git-buildpackage
debian.social: Socializando Debian do jeito Debian
Proxy reverso com WireGuard
Celebra o dos 30 anos do Debian!
Instalando o Debian em disco criptografado com LUKS
O que a equipe de localiza o j conquistou nesses 30 anos
Debian - Projeto e Comunidade!
Design Gr fico e Software livre, o que fazer e por onde come ar
Since my motivation boost in the beginning of the month caused me
to wrap up a new release of
liboggz, I have used the
same boost to wrap up new editions of
libfishsound,
liboggplay
and
libkate
too. These have been tagged in upstream git, but not yet published on
the Xiph download location. I am waiting for someone with access to
have time to move the tarballs there, I hope it will happen in a few
days. The same is the case for a minor update of liboggz too.
As I was looking at Xiph packages lacking updates, it occurred to
me that there are packages in Debian that have not received a new
upload in a long time. Looking for a way to identify them, I came
across the ltnu script from the
devscripts
package. It can sort by last update, packages maintained by a single
user/group, and is useful to figure out which packages a single
maintainer should have a look at. But I wanted a archive wide
summary. Based on the UDD SQL
query used by ltnu, I ended up with the following command:
#!/bin/sh
env PGPASSWORD=udd-mirror psql --host=udd-mirror.debian.net --user=udd-mirror udd --command="
select source,
max(version) as ver,
max(date) as uploaded
from upload_history
where distribution='unstable' and
source in (select source
from sources
where release='sid')
group by source
order by max(date) asc
limit 50;"
This will sort all source packages in Debian by upload date, and
list the 50 oldest ones. The end result is a list of packages I
suspect could use some attention:
So there are 8 packages last uploaded to unstable in 2011, 12
packages in 2012 and 26 packages in 2013. I suspect their maintainers
need help and we should all offer our assistance. I already contacted
two of them and hope the rest of the Debian community will chip in to
help too. We should ensure any Debian specific patches are passed
upstream if they still exist, that the package is brought up to speed
with the latest Debian policy, as well as ensure the source can built
with the current compiler set in Debian.
As usual, if you use Bitcoin and want to show your support of my
activities, please send Bitcoin donations to my address
15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.
I have been testing fish for a couple months now (this file started on
2025-01-03T23:52:15-0500 according to stat(1)), and those are my
notes. I suspect people will have Opinions about my comments here. Do
not comment unless you have some Constructive feedback to provide: I
don't want to know if you think I am holding it Wrong. Consider that I
might have used UNIX shells for longer that you have lived.
I'm not sure I'll keep using fish, but so far it's the first shell
that survived heavy use outside of zsh(1) (unless you count
tcsh(1), but that was in another millenia).
My normal shell is bash(1), and it's still the shell I used
everywhere else than my laptop, as I haven't switched on all the
servers I managed, although it is available since August 2022 on
torproject.org servers. I first got interested in fish because they
ported to Rust, making it one of the rare shells out there
written in a "safe" and modern programming language, released after an
impressive ~2 year of work with Fish 4.0.
Cool things
Current directory gets shortened,
~/wikis/anarc.at/software/desktop/wayland shows up as
~/w/a/s/d/wayland
Autocompletion rocks.
Default prompt rocks. Doesn't seem vulnerable to command injection
assaults, at least it doesn't trip on the git-landmine.
It even includes pipe status output, which was a huge pain to
implement in bash. Made me realized that if the last command succeeds,
we don't see other failures, which is the case of my current prompt
anyways! Signal reporting is better than my bash implementation too.
So far the only modification I have made to the prompt is to add a
printf '\a' to output a bell.
By default, fish keeps a directory history (but separate from the
pushd stack), that can be navigated with cdh, prevd, and
nextd, dirh shows the history.
Less cool
I feel there's visible latency in the prompt creation.
POSIX-style functions (foo() true ) are unsupported. Instead,
fish uses whitespace-sensitive definitions like this:
function foo
true
end
This means my (modest) collection of POSIX functions need to be ported
to fish. Workaround: simple functions can be turned into aliases,
which fish supports (but implements using functions).
EOF heredocs are considered to be "minor syntactic sugar". I find
them frigging useful.
Process substitution is split on newlines, not whitespace. you need to
pipe through string split -n " " to get the equivalent.
<(cmd) doesn't exist: they claim you can use cmd foo - as a
replacement, but that's not correct: I used <(cmd) mostly where
foo does not support - as a magic character to say 'read from
stdin'.
Documentation is... limited. It seems mostly geared the web docs
which are... okay (but I couldn't find out about
~/.config/fish/conf.d there!), but this is really inconvenient when
you're trying to browse the manual pages. For example, fish thinks
there's a fish_prompt manual page, according to its own completion
mechanism, but man(1) cannot find that manual page. I can't find the
manual for the time command (which is actually a keyword!)
Fish renders multi-line commands with newlines. So if your terminal
looks like this, say:
Note that this is an issue specific to foot(1), alacritty(1) and
gnome-terminal(1) don't suffer from that issue. I have already filed
it upstream in foot and it is apparently fixed already.
Globbing is driving me nuts. You can't pass a * to a command
unless fish agrees it's going to match something. You need to escape
it if it doesn't immediately match, and then you need the called
command to actually support globbing. 202[345] doesn't match
folders named 2023, 2024, 2025, it will send the string
202[345] to the command.
Blockers
() is like $(): it's process substitution, and not a
subshell. This is really impractical: I use ( cd foo ; do_something)
all the time to avoid losing the current directory... I guess I'm
supposed to use pushd for this, but ouch. This wouldn't be so bad if
it was just for cd though. Clean constructs like this:
... which fails and suggests using begin/end, at which point: why
not just support the curly braces?
FOO=bar is not allowed. It's actually recognized syntax, but creates
a warning. We're supposed to use set foo bar instead. This really
feels like a needless divergence from standard.
Aliases are... peculiar. Typical constructs like alias mv="\mv -i"
don't work because fish treats aliases as a function definition, and
\ is not magical there. This can be worked around by specifying the
full path to the command, with e.g. alias mv="/bin/mv -i". Another
problem is trying to override a built-in, which seems completely
impossible. In my case, I like the time(1) command the way it
is, thank you very much, and fish provides no way to bypass that
builtin. It is possible to call time(1) with command time, but
it's not possible to replace the command keyword so that means a lot
of typing.
Again: you can't use \ to bypass aliases. This is a huge annoyance
for me. I would need to learn to type command in long form, and I
use that stuff pretty regularly. I guess I could alias command to
c or something, but this is one of those huge muscle memory challenges.
alt . doesn't always work the way i expect.
I re-implemented the proxmox backup nbdkit
plugin in C.
It seems golang shared libraries don t play
well with programs that fork().
As a result, the Plugin was only usable if nbdkit was run in foreground mode
(-f), making it impossible to use nbdkit s captive modes, which are quite
useful.. Lessons learned.
Here is the C version
I am tasked with contributing to the debianhugo project which aim is to re-design the old debian pages and make the content better accessible. We've since reached a significant milestone and migrated multiple pages including the start, intro, news and now the download page.
creating "simple" and "advanced" download pages
At first we made the "simple" download page:
target audience; less experienced users
only added more common download arhitectures/options i.e amd64-64 bit pc and arm64
descriptive content for easy user experience; listing positives and negatives of each option, adding download sizes
interactive download cards with iso, torrent and debian-cd mirror selections.
"advanced" download page:
more download architectures and options including testing release streams
straight to point content
challenges/issues while developing
The mirror selection option while it might help with faster downloads depending on the region is still somewhat a manual proccess on the user end and could come with various complications like the chosen debian-cd mirror not having the latest version of debian.
We're looking into testing if the delivery of the images/ISOs is also possible to be done through the Fastly CDN, this would prevent us to provide manual mirror selection.
Introduction
This is just a note-taking about how to upgrading Mozc package for up-coming trixie ready (with many restrictions) last year.
Maybe Mozc 2.29.5160.102+dfsg-1.3 will be shipped for Debian 13 (trixie).
FTBFS with Mozc 2.28.4715.102+dfsg-2.2
In May 2024, I've found that Mozc was removed from testing, and still in FTBFS.
#1068186 - mozc: FTBFS with abseil 20230802: ../../base/init_mozc.cc:90:29: error: absl::debian5::flags_internal::ArgvListAction has not been declared - Debian Bug report logs
That FTBFS was fixed in the Mozc upstream, but not applied for a while.
Not only upstream patch, but also additional linkage patch was required to fix it.
Mozc is the de-fact standard input method editor for Japanese.
Most of Japanese uses it by default on linux desktop.
(Even though frontend input method framework is different, the background engine is Mozc in most cases -
uim-mozc for task-japanese-desktop, ibus-mozc for task-japanese-gnome-desktop in Debian)
There is a case that Mozc was re-built locally with integrated external dictionary
to improve quantity of vocabulary. If FTBFS keep ongoing, it means that it blocks such a usage.
So I've sent patches to fix it and they were merged.
Motivation to update Mozc
With fixing #1068186, I've also found Mozc version is not synced to upstream for a long time.
At that time, Mozc in unstable was version 2.28.4715.102+dfsg, but upstream already released 2.30.5544.102.
It seems that Mozc's maintainer was too busy and can't afford to update it, so I've tried to do it.
The blockers for updating Mozc
But, it was not so easy task to do so.
If you want to package latest Mozc, there were many blockers.
Newer Mozc requires Bazel to build, but there is no Bazel package to fit it (There is bazel-bootstrap 4.x, but it's old. v6.x or newer one is required.)
Newer abseil and protobuf were required
Renderer was changed to Qt. GTK renderer was removed
Revise existing patchsets (e.g. for UIM, for Fcitx)
It was not all.
Road to latest Mozc
First, I knew the existence of debian-bazel, so I've posted about bazel-packaging progress.
Any updates about bazel packaging effort?
Sadly there was no response from it.
Thus, it was not realistic to adopt Bazel as build tool chain.
In other words, we need to keep GYP patch and maintain it.
And as another topic, upstream changed renderer from GTK+ to Qt.
Here are the major topics about each release of Mozc.
The internal renderer change are too big, and before GYP deprecation
in 2.29.5544.102, GYP support was already removed gradually.
As a result, target to 2.29.5160.102 was the practical approach to make it forward.
Revisit existing patchsets for 2.28.4715.102+dfsg
Second, need to revisit existing patchset to triage them.
UIM patch was maintained in third-party repository,
and directory structure was quite different from Mozc.
It seems that maintenance activity was too low, so it was not enough that picking changes
from macuim. It was required to fix FTBFS additionally.
Fcitx patch was also maintained in fcitx/mozc.
But it tracks only master branch, so it was hard to pick patchset for specific version of Mozc.
Finally, I could manage to refresh patchset for 2.29.5160.102.
OT: Hardware breakage
There was another blocker to do this task.
I've hit the situation that g++ cause SEGV during building Mozc randomly.
First, I wonder why it fails, but digging further more, finally I've found that
memory module was corrupted. Thus I've lost 32GB memory modules. :-<
Unexpected behaviour in uim-mozc
When uploaded Mozc 2.29.5160.102+dfsg-1 to experimental,
I've found that there is a case that uim-mozc behaves weird.
The candidate words were shown with flickering.
But it was not regression in this upload.
uim-mozc with Wayland cause that problem.
Thus GNOME and derivatives might not be affected because ibus-mozc will be used.
Mozc 2.29.5160.102+dfsg-1
As the patchset was matured, then uploaded 2.29.5160.102+dfsg-1 with --delayed 15 option.
$ dput --delayed 15 mozc_2.29.5160.102+dfsg-1_source.changes
Uploading mozc using ftp to ftp-master (host: ftp.upload.debian.org; directory: /pub/UploadQueue/DELAYED/15-day)
running allowed-distribution: check whether a local profile permits uploads to the target distribution
running protected-distribution: warn before uploading to distributions where a special policy applies
running checksum: verify checksums before uploading
running suite-mismatch: check the target distribution for common errors
running gpg: check GnuPG signatures before the upload
signfile dsc mozc_2.29.5160.102+dfsg-1.dsc 719EB2D93DBE9C4D21FBA064F7FB75C566ED20E3
fixup_buildinfo mozc_2.29.5160.102+dfsg-1.dsc mozc_2.29.5160.102+dfsg-1_amd64.buildinfo
signfile buildinfo mozc_2.29.5160.102+dfsg-1_amd64.buildinfo 719EB2D93DBE9C4D21FBA064F7FB75C566ED20E3
fixup_changes dsc mozc_2.29.5160.102+dfsg-1.dsc mozc_2.29.5160.102+dfsg-1_source.changes
fixup_changes buildinfo mozc_2.29.5160.102+dfsg-1_amd64.buildinfo mozc_2.29.5160.102+dfsg-1_source.changes
signfile changes mozc_2.29.5160.102+dfsg-1_source.changes 719EB2D93DBE9C4D21FBA064F7FB75C566ED20E3
Successfully signed dsc, buildinfo, changes files
Uploading mozc_2.29.5160.102+dfsg-1.dsc
Uploading mozc_2.29.5160.102+dfsg-1.debian.tar.xz
Uploading mozc_2.29.5160.102+dfsg-1_amd64.buildinfo
Uploading mozc_2.29.5160.102+dfsg-1_source.changes
Mozc 2.29.5160.102+dfsg-1 was landed to unstable at 2024-12-20.
Additional bug fixes
Additionally, the following bugs were also fixed.
These bugs were fixed in 2.29.5160.102+dfsg-1.1
And more, I've found that even though missing pristine-tar branch commit, salsa CI succeeds.
I've sent MR for this issue and already merged into.
Note that protobuf 3.25.4 on experimental depends on older absl
20230802, so it must be rebuilt against absl 20240722.0.
And more, we need to consider how to migrate from GTK renderer to
Qt renderer in the future.
Posted on February 23, 2025
Tags: madeof:atoms, craft:sewing, FreeSoftWear
Many years ago I made myself a vest with lots of pockets1 in a few layers of cheap cotton, and wore the hell out of it,
for the added warmth, but most importantly for the convenience provided
by the pockets.
Then a few years ago the cheap cotton had started to get worn, and I
decided I needed to replace it. I found a second choice (and thus
cheaper :) ) version of a water-repellent cotton
and made another vest, lined with regular cotton, for a total of just
two layers.
This time I skipped a few pockets that I had found I didn t use that
much, and I didn t add a hood, which didn t play that well when worn
over a hoodie, but I added some detached sleeves, for additional wind
protection.
This left about 60 cm and some odd pieces of leftover fabric in my
stash, for which I had no plan.
And then February2 came, and I needed a quick simple mindless
handsewing projects for the first weekend, I saw the vest (which I m
wearing as much as the old one), the sleeves (which have been used much
less, but I d like to change this) and thought about making a matching
hood for it, using my square hood pattern.
Since the etaproof is a bit stiff and not that nice to the touch I
decide to line3 it with the same cotton as the vest and
sleeves, and in the style of the pattern I did so by finishing each
panel with its own lining (with regular cotton thread) and then
whipstitching the panels together with the corespun cotton/poly thread
recommended by the seller of the fabric. I m not sure this is the best
way to construct something that is supposed to resist the rain, but if I
notice issues I can always add some sealing tape afterwards.
I do have a waterproof cape to wear in case of real rain, so this is
only supposed to work for light rain anyway, and it may prove not to be
an issue.
As something designed to be worn in light rain, this is also something
likely to be worn in low light conditions, where 100% black may not be
the wisest look. On the vest I had added reflective piping to the
armscyes, but I was out of the same piping.
I did however have a spool of reflector thread made of glass fibre by
Rico Design, which I think was originally sold to be worked into
knitting or crochet projects (it is now discontinued) and I had never
used.
I decided to try and sew a decorative blanket stitch border, a decision
I had reasons to regret, since the thread broke and tangled like crazy,
but in the end it was done, I like how it looks, and it seems pretty
functional. I hope it won t break with time and use, and if it does I ll
either fix it or try to redo with something else.
Of course, the day I finished sewing the reflective border it stopped
raining, so I haven t worn it yet, but I hope I ll be able to, and if it
is an horrible failure I ll make sure to update this post.
and I ve just realized that I haven t migrated that pattern
to my pattern website, and I should do that. just don t hold your
breath for it to happen O:-). And for the time being it will not have
step-by-step pictures, as I currently don t need another vest.
and February of course means a weekend in front of a
screen that is showing a live-streamed conference.
and of course I updated the pattern with instructions on
how to add a lining.
Yesterday i released a new version of
virtnbdbackup with a nice
improvement.
The new version can now detect zeroed regions in the bitmaps by comparing the
block regions against the state within the base bitmap during incremental
backup.
This is helpful if virtual machines run fstrim, as it results in less backup
footprint. Before the incremental backups could grow the same amount of size as
fstrimmed data regions.
I also managed to enhance the tests by using the arch linux cloud images. The
automated github CI tests now actually test backup and restores against a
virtual machine running an real OS.
I can t remember exactly the joke I was making at the time in my
work s slack instance (I m sure it wasn t particularly
funny, though; and not even worth re-reading the thread to work out), but it
wound up with me writing a UEFI binary for the punchline. Not to spoil the
ending but it worked - no pesky kernel, no messing around with userland . I
guess the only part of this you really need to know for the setup here is that
it was a Severance joke,
which is some fantastic TV. If you haven t seen it, this post will seem perhaps
weirder than it actually is. I promise I haven t joined any new cults. For
those who have seen it, the payoff to my joke is that I wanted my machine to
boot directly to an image of
Kier Eagan.
As for how to do it I figured I d give the uefi
crate a shot, and see how it is to use,
since this is a low stakes way of trying it out. In general, this isn t the
sort of thing I d usually post about except this wound up being easier and
way cleaner than I thought it would be. That alone is worth sharing, in the
hopes someome comes across this in the future and feels like they, too, can
write something fun targeting the UEFI.
First thing s first gotta create a rust project (I ll leave that part to you
depending on your life choices), and to add the uefi crate to your
Cargo.toml. You can either use cargo add or add a line like this by hand:
uefi = version = "0.33", features = ["panic_handler", "alloc", "global_allocator"]
We also need to teach cargo about how to go about building for the UEFI target,
so we need to create a rust-toolchain.toml with one (or both) of the UEFI
targets we re interested in:
Unfortunately, I wasn t able to use the
image crate,
since it won t build against the uefi target. This looks like it s
because rustc had no way to compile the required floating point operations
within the image crate without hardware floating point instructions
specifically. Rust tends to punt a lot of that to libm usually, so this isnt
entirely shocking given we re nostd for a non-hardfloat target.
So-called softening requires a software floating point implementation that
the compiler can use to polyfill (feels weird to use the term polyfill here,
but I guess it s spiritually right?) the lack of hardware floating point
operations, which rust hasn t implemented for this target yet. As a result, I
changed tactics, and figured I d use ImageMagick to pre-compute the pixels
from a jpg, rather than doing it at runtime. A bit of a bummer, since I need
to do more out of band pre-processing and hardcoding, and updating the image
kinda sucks as a result but it s entirely manageable.
This will take our input file (kier.jpg), resize it to get as close to the
desired resolution as possible while maintaining aspect ration, then convert it
from a jpg to a flat array of 4 byte RGBA pixels. Critically, it s also
important to remember that the size of the kier.full.jpg file may not actually
be the requested size it will not change the aspect ratio, so be sure to
make a careful note of the resulting size of the kier.full.jpg file.
Last step with the image is to compile it into our Rust bianary, since we
don t want to struggle with trying to read this off disk, which is thankfully
real easy to do.
Remember to use the width and height from the final kier.full.jpg file as the
values for KIER_WIDTH and KIER_HEIGHT. KIER_PIXEL_SIZE is 4, since we
have 4 byte wide values for each pixel as a result of our conversion step into
RGBA. We ll only use RGB, and if we ever drop the alpha channel, we can drop
that down to 3. I don t entirely know why I kept alpha around, but I figured it
was fine. My kier.full.jpg image winds up shorter than the requested height
(which is also qemu s default resolution for me) which means we ll get a
semi-annoying black band under the image when we go to run it but it ll
work.
Anyway, now that we have our image as bytes, we can get down to work, and
write the rest of the code to handle moving bytes around from in-memory
as a flat block if pixels, and request that they be displayed using the
UEFI GOP. We ll just need to hack up a container
for the image pixels and teach it how to blit to the display.
/// RGB Image to move around. This isn't the same as an
/// image::RgbImage , but we can associate the size of
/// the image along with the flat buffer of pixels.
structRgbImage/// Size of the image as a tuple, as the
/// (width, height)
size: (usize, usize),
/// raw pixels we'll send to the display.
inner: Vec<BltPixel>,
impl RgbImage
/// Create a new RgbImage .
fnnew(width: usize, height: usize) -> Self
RgbImage
size: (width, height),
inner: vec![BltPixel::new(0, 0, 0); width * height],
/// Take our pixels and request that the UEFI GOP
/// display them for us.
fnwrite(&self, gop: &mut GraphicsOutput) -> Result
gop.blt(BltOp::BufferToVideo
buffer: &self.inner,
src: BltRegion::Full,
dest: (0, 0),
dims: self.size,
)
impl Index<(usize, usize)>for RgbImage
typeOutput= BltPixel;
fnindex(&self, idx: (usize, usize)) -> &BltPixellet (x, y) = idx;
&self.inner[y * self.size.0+ x]
impl IndexMut<(usize, usize)>for RgbImage
fnindex_mut(&mut self, idx: (usize, usize)) -> &mut BltPixel
let (x, y) = idx;
&mut self.inner[y * self.size.0+ x]
We also need to do some basic setup to get a handle to the UEFI
GOP via the UEFI crate (using
uefi::boot::get_handle_for_protocol
and
uefi::boot::open_protocol_exclusive
for the GraphicsOutput
protocol), so that we have the object we need to pass to RgbImage in order
for it to write the pixels to the display. The only trick here is that the
display on the booted system can really be any resolution so we need to do
some capping to ensure that we don t write more pixels than the display can
handle. Writing fewer than the display s maximum seems fine, though.
fnpraise() -> Result
let gop_handle = boot::get_handle_for_protocol::<GraphicsOutput>()?;
letmut gop = boot::open_protocol_exclusive::<GraphicsOutput>(gop_handle)?;
// Get the (width, height) that is the minimum of
// our image and the display we're using.
let (width, height) = gop.current_mode_info().resolution();
let (width, height) = (width.min(KIER_WIDTH), height.min(KIER_HEIGHT));
letmut buffer = RgbImage::new(width, height);
for y in0..height
for x in0..width
let idx_r = ((y * KIER_WIDTH) + x) * KIER_PIXEL_SIZE;
let pixel =&mut buffer[(x, y)];
pixel.red = KIER[idx_r];
pixel.green = KIER[idx_r +1];
pixel.blue = KIER[idx_r +2];
buffer.write(&mut gop)?;
Ok(())
Not so bad! A bit tedious we could solve some of this by turning
KIER into an RgbImage at compile-time using some clever Cow and
const tricks and implement blitting a sub-image of the image but this
will do for now. This is a joke, after all, let s not go nuts. All that s
left with our code is for us to write our main function and try and boot
the thing!
#[entry]fnmain() -> Status
uefi::helpers::init().unwrap();
praise().unwrap();
boot::stall(100_000_000);
Status::SUCCESS
If you re following along at home and so interested, the final source is over at
gist.github.com.
We can go ahead and build it using cargo (as is our tradition) by targeting
the UEFI platform.
Testing the UEFI Blob
While I can definitely get my machine to boot these blobs to test, I figured
I d save myself some time by using QEMU to test without a full boot.
If you ve not done this sort of thing before, we ll need two packages,
qemu and ovmf. It s a bit different than most invocations of qemu you
may see out there so I figured it d be worth writing this down, too.
$ doas apt install qemu-system-x86 ovmf
qemu has a nice feature where it ll create us an EFI partition as a drive and
attach it to the VM off a local directory so let s construct an EFI
partition file structure, and drop our binary into the conventional location.
If you haven t done this before, and are only interested in running this in a
VM, don t worry too much about it, a lot of it is convention and this layout
should work for you.
With all this in place, we can kick off qemu, booting it in UEFI mode using
the ovmf firmware, attaching our EFI partition directory as a drive to
our VM to boot off of.
If all goes well, soon you ll be met with the all knowing gaze of
Chosen One, Kier Eagan. The thing that really impressed me about all
this is this program worked first try it all went so boringly
normal. Truly, kudos to the uefi crate maintainers, it s incredibly
well done.
Booting a live system
Sure, we could stop here, but anyone can open up an app window and see a
picture of Kier Eagan, so I knew I needed to finish the job and boot a real
machine up with this. In order to do that, we need to format a USB stick.
BE SURE /dev/sda IS CORRECT IF YOU RE COPY AND PASTING. All my drives
are NVMe, so BE CAREFUL if you use SATA, it may very well be your
hard drive! Please do not destroy your computer over this.
$ doas fdisk /dev/sda
Welcome to fdisk (util-linux 2.40.4).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): n
Partition type
p primary (0 primary, 0 extended, 4 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1):
First sector (2048-4014079, default 2048):
Last sector, +/-sectors or +/-size K,M,G,T,P (2048-4014079, default 4014079):
Created a new partition 1 of type 'Linux' and of size 1.9 GiB.
Command (m for help): t
Selected partition 1
Hex code or alias (type L to list all): ef
Changed type of partition 'Linux' to 'EFI (FAT-12/16/32)'.
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
Once that looks good (depending on your flavor of udev you may or
may not need to unplug and replug your USB stick), we can go ahead
and format our new EFI partition (BE CAREFUL THAT /dev/sda IS YOUR
USB STICK) and write our EFI directory to it.
$ doas mkfs.fat /dev/sda1
$ doas mount /dev/sda1 /mnt
$ cp -r esp/efi /mnt
$ find /mnt
/mnt
/mnt/efi
/mnt/efi/boot
/mnt/efi/boot/bootx64.efi
Of course, naturally, devotion to Kier shouldn t mean backdooring your system.
Disabling Secure Boot runs counter to the Core Principals, such as Probity, and
not doing this would surely run counter to Verve, Wit and Vision. This bit does
require that you ve taken the step to enroll a
MOK and know how
to use it, right about now is when we can use sbsign to sign our UEFI binary
we want to boot from to continue enforcing Secure Boot. The details for how
this command should be run specifically is likely something you ll need to work
out depending on how you ve decided to manage your MOK.
I figured I d leave a signed copy of boot2kier at
/boot/efi/EFI/BOOT/KIER.efi on my Dell XPS 13, with Secure Boot enabled
and enforcing, just took a matter of going into my BIOS to add the right
boot option, which was no sweat. I m sure there is a way to do it using
efibootmgr, but I wasn t smart enough to do that quickly. I let er rip,
and it booted up and worked great!
It was a bit hard to get a video of my laptop, though but lucky for me, I
have a Minisforum Z83-F sitting around (which, until a few weeks ago was running
the annual http server to control my christmas tree
) so I grabbed it out of the christmas bin, wired it up to a video capture
card I have sitting around, and figured I d grab a video of me booting a
physical device off the boot2kier USB stick.
Attentive readers will notice the image of Kier is smaller then the qemu booted
system which just means our real machine has a larger GOP display
resolution than qemu, which makes sense! We could write some fancy resize code
(sounds annoying), center the image (can t be assed but should be the easy way
out here) or resize the original image (pretty hardware specific workaround).
Additionally, you can make out the image being written to the display before us
(the Minisforum logo) behind Kier, which is really cool stuff. If we were real
fancy we could write blank pixels to the display before blitting Kier, but,
again, I don t think I care to do that much work.
But now I must away
If I wanted to keep this joke going, I d likely try and find a copy of the
original
video when Helly 100%s her file
and boot into that or maybe play a terrible midi PC speaker rendition of
Kier, Chosen One, Kier after
rendering the image. I, unfortunately, don t have any friends involved with
production (yet?), so I reckon all that s out for now. I ll likely stop playing
with this the joke was done and I m only writing this post because of how
great everything was along the way.
All in all, this reminds me so much of building a homebrew kernel to boot a
system into but like, good, though, and it s a nice reminder of both how
fun this stuff can be, and how far we ve come. UEFI protocols are light-years
better than how we did it in the dark ages, and the tooling for this is SO
much more mature. Booting a custom UEFI binary is miles ahead of trying to
boot your own kernel, and I can t believe how good the uefi crate is
specifically.
Praise Kier! Kudos, to everyone involved in making this so delightful .
Evolution of the situation
In January, we have released 33 DLAs.
There were numerous security and non-security updates to Debian 11 (codename bullseye ) during January.
Notable security updates:
rsync, prepared by Thorsten Alteholz, fixed several CVEs (including information leak and path traversal vulnerabilities)
tomcat9, prepared by Markus Koschany, fixed several CVEs (including denial of service and information disclosure vulnerabilities)
ruby2.7, prepared by Bastien Roucari s, fixed several CVEs (including denial of service vulnerabilities)
tiff, prepared by Adrian Bunk, fixed several CVEs (including NULL ptr, buffer overflow, use-after-free, and segfault vulnerabilities)
Notable non-security updates:
linux-6.1, prepared by Ben Hutchings, has been packaged for bullseye (this was done specifically to provide a supported upgrade path for systems that currently use kernel packages from the bullseye-backports suite)
debian-security-support, prepared by Santiago Ruano Rinc n, which formalized the EOL of intel-mediasdk and node-matrix-js-sdk
In addition to the security and non-security updates targeting bullseye , various LTS contributors have prepared uploads targeting Debian 12 (codename bookworm ) with fixes for a variety of vulnerabilities. Abhijith PA prepared an upload of puma; Bastien Roucari s prepared an upload of node-postcss with fixes for data processing and denial of service vulnerabilities; Daniel Leidert prepared updates for setuptools, python-asyncssh, and python-tornado; Lee Garrett prepared an upload of ansible-core; and Guilhem Moulin prepared updates for python-urllib3, sqlparse, and opensc. Santiago Ruano Rinc n also worked on tracking and filing some issues about packages that need an update in recent releases to avoid regressions on upgrade. This relates to CVEs that were fixed in buster or bullseye, but remain open in bookworm. These updates, along with Santiago s work on identifying and tracking similar issues, underscore the LTS Team s commitment to ensuring that the work we do as part of LTS also benefits the current Debian stable release.
LTS contributor Sean Whitton also prepared an upload of jinja2 and Santiago Ruano Rinc n prepared an upload of openjpeg2 for Debian unstable (codename sid ), as part of the LTS Team effort to assist with package uploads to unstable.
Thanks to our sponsors
Sponsors that joined recently are in bold.
Python 3.13 is now the default Python 3 version in Debian, by Stefano Rivera and Colin Watson
The Python 3.13 as default transition has now completed. The next step is to
remove Python 3.12 from the archive, which should be very straightforward, it
just requires rebuilding C extension packages in no particular order. Stefano
fixed some miscellaneous bugs blocking the completion of the 3.13 as default
transition.
Fixing qtpaths6 for cross compilation, by Helmut Grohne
While Qt5 used to use qmake to query installation properties, Qt6 is moving
more and more to CMake and to ease that transition it relies on more qtpaths.
Since this tool is not naturally aware of the architecture it is called for, it
tends to produce results for the build architecture. Therefore, more than 100
packages were picking up a multiarch directory for the build architecture during
cross builds. In collaboration with the Qt/KDE team and Sandro Knau in
particular (none affiliated with Freexian), we added an architecture-specific
wrapper script in the same way qmake has one for Qt5 and Qt6 already. The
relevant CMake module has been updated to prefer the triplet-prefixed wrapper.
As a result, most of the KDE packages now cross build on unstable ready in time
for the trixie release.
/usr-move, by Helmut Grohne
In December, Emil S dergren reported that a live-build was not working for him
and in January, Colin Watson reported that the proposed mitigation for
debian-installer-utils would practically fail. Both failures were to be
attributed to a wrong understanding of implementation-defined behavior in
dpkg-divert. As a
result, all M18 mitigations had to be reviewed and many of them replaced. Many
have been uploaded already and all instances have received updated patches.
Even though dumat has been in
operation for more than a year, it gained recent changes. For one thing,
analysis of architectures other than amd64 was requested. Chris Hofstaedler
(not affiliated with Freexian) kindly provided computing resources for
repeatedly running it on the larger set. Doing so revealed various
cross-architecture undeclared file conflicts in gcc, glibc, and
binutils-z80, but it also revealed a previously unknown /usr-move issue in
rpi.rpi-common. On top of that, dumat produced false positive diagnostics
and wrongly associated Debian bugs in some cases, both of which have now been
fixed. As a result, a supposedly fixed python3-sepolicy issue had to be
reopened.
rebootstrap, by Helmut Grohne
As much as we think of our base system as stable, it is changing a lot and the
architecture cross bootstrap tooling is very sensitive to such changes requiring
permanent maintenance. A problem that recently surfaced was that building a
binutils cross toolchain would result in a binutils-for-host package that
would not be practically installable as it would depend on a binutils-common
package that was not built. This turned into an examination of binutils-common
and noticing that it actually differed across architectures even though it
should not. Johannes Schauer Marin Rodrigues (not affiliated with Freexian) and
Colin Watson kindly helped brainstorm possible solutions. Eventually, Helmut
provided a patch to move gprofng bits out of
binutils-common. Independently, Matthias Klose
(not affiliated with Freexian) split out binutils-gold into a separate source
package. As a result, binutils-common is now equal across architectures and
can be marked Multi-Arch: foreign resolving the initial problem.
Salsa CI, by Santiago Ruano Rinc n
Santiago continued the work about the sbuild support for Salsa CI, that was
mentioned in the previous month
report. The
!568
merge request that created the new build image was merged, making it easier to
test !569
with external projects. Santiago used a fork of the debusine repo to try the
draft !569,
and some issues were spotted, and part of them fixed. This is the last debusine
pipeline run with the current
!569:
https://salsa.debian.org/santiago/debusine/-/pipelines/794233.
One of the last improvements relates to how to enable projects to customize the
pipeline, in an equivalent way than they currently do in the extract-source
and build jobs. While this is work-in-progress, the results are rather
promising. Next steps include deciding on introducing schroot support for
bookworm, bookworm-security, and older releases, as they are done in the
official debian buildd.
DebConf preparations, by Stefano Rivera and Santiago Ruano Rinc n
DebConf will be happening in Brest, France, in July. Santiago continued the
DebConf 25 organization work, looking for catering providers.
Both Stefano and Santiago have been reaching out to some potential sponsors.
DebConf depends on sponsors to cover the organization cost, if your company
depends on Debian, please consider sponsoring
DebConf.
Stefano has been winding up some of the finances from previous DebConfs.
Finalizing reimbursements to team members from DebConf 23, and handling some
outstanding issues from DebConf 24. Stefano and the rest of the DebConf
committee have been reviewing bids for DebConf 26, to select the next venue.
Ruby 3.3 is now the default Ruby interpreter, by Lucas Kanashiro
Ruby 3.3 is about to become the default Ruby interpreter for Trixie. Many bugs
were fixed by Lucas and the Debian Ruby team during the sprint hold in Paris
during Jan 27-31. The
next step is to remove support of Ruby 3.1, which is the alternative Ruby
interpreter for now. Thanks to the Debian Release team for all the support,
especially Emilio Pozuelo Monfort.
Rails 7 transition, by Lucas Kanashiro
Rails 6 has been shipped by Debian since Bullseye, and as a WEB framework, many
issues (especially security related issues) have been encountered and the
maintainability of it becomes harder and harder. With that in mind, during the
Debian Ruby team sprint last
month, the transition to
Rack 3 (an important dependency of rails containing many breaking changes) was
started in Debian unstable, it is ongoing. Once it is done, the Rails 7
transition will take place, and Rails 7 should be shipped in Debian Trixie.
Miscellaneous contributions
Stefano improved a poor ImportError for users of the turtle module on Python
3, who haven t installed the python3-tk package.
Stefano updated several packages to new upstream releases.
Stefano added the Python extension to the re2 package, allowing for the use
of the Google RE2 regular expression library as a direct replacement for the
standard library re module.
Stefano started provisioning a new physical server for the
debian.social infrastructure.
Carles improved simplemonitor (documentation on systemd integration, worked
with upstream for fixing a bug).
Carles upgraded packages to new upstream versions: python-ring-doorbell and
python-asyncclick.
Carles did po-debconf translations to Catalan: reviewed 44 packages and
submitted translations to 90 packages (via salsa merge requests or bugtracker
bugs).
Carles maintained po-debconf-manager with small fixes.
Rapha l worked on some outstanding
DEP-14merge
request and
participated in the associated discussion. The discussions have been more
contentious than anticipated, somewhat exacerbated by Otto s desire to
conclude fast while the required tool support is not yet there.
Rapha l, with the help of Philipp Kern from the DSA team, upgraded
tracker.debian.org to use Django 4.2 (from bookworm-backports) which in turn
enabled him to configure authentication via salsa.debian.org. It s now
possible to login to tracker.debian.org with your salsa credentials!
Rapha l updated zim a nice desktop wiki that is very handy to organize
your day-to-day digital life to the latest upstream version (0.76).
It is a while since I posted a summary of the free software and
open culture activities and projects I have worked on. Here is a
quick summary of the major ones from last year.
I guess the biggest project of the year has been migrating orphaned
packages in Debian without a version control system to have a git
repository on salsa.debian.org. When I started in April around 450
the orphaned packages needed git. I've since migrated around 250 of
the packages to a salsa git repository, and around 40 packages were
left when I took a break. Not sure who did the around 160 conversions
I was not involved in, but I am very glad I got some help on the
project. I stopped partly because some of the remaining packages
needed more disk space to build than I have available on my
development machine, and partly because some had a strange build setup
I could not figure out. I had a time budget of 20 minutes per
package, if the package proved problematic and likely to take longer,
I moved to another package. Might continue later, if I manage to free
up some disk space.
Another rather big project was the translation to Norwegian Bokm l
and publishing of the first book ever published by a S mi woman, the
M ter
vi liv eller d d? book by Elsa Laula, with a PD0 and CC-BY
license. I released it during the summer, and to my surprise it has
already sold several copies. As I suck at marketing, I did not expect
to sell any.
A smaller, but more long term project (for more than 10 years now),
and related to orphaned packages in Debian, is my project to ensure a
simple way to install hardware related packages in Debian when the
relevant hardware is present in a machine. It made a fairly big
advance forward last year, partly because I have been poking and
begging package maintainers and upstream developers to include
AppStream metadata XML in their packages. I've also released a few
new versions of the isenkram system with some robustness improvements.
Today 127 packages in Debian provide such information, allowing
isenkram-lookup to propose them. Will keep pushing until the
around 35 package names currently hard coded in the isenkram package
are down to zero, so only information provided by individual packages
are used for this feature.
As part of the work on AppStream, I have sponsored several packages
into Debian where the maintainer wanted to fix the issue but lacked
direct upload rights. I've also sponsored a few other packages, when
approached by the maintainer.
I would also like to mention two hardware related packages in
particular where I have been involved, the megactl and mfi-util
packages. Both work with the hardware RAID systems in several Dell
PowerEdge servers, and the first one is already available in Debian
(and of course, proposed by isenkram when used on the appropriate Dell
server), the other is waiting for NEW processing since this autumn. I
manage several such Dell servers and would like the tools needed to
monitor and configure these RAID controllers to be available from
within Debian out of the box.
Vaguely related to hardware support in Debian, I have also been
trying to find ways to help out the Debian ROCm team, to improve the
support in Debian for my artificial idiocy (AI) compute node. So far
only uploaded one package, helped test the initial packaging of
llama.cpp and tried to figure out how to get good speech recognition
like Whisper into Debian.
I am still involved in the LinuxCNC project, and organised a
developer gathering in Norway last summer. A new one is planned the
summer of 2025. I've also helped evaluate patches and uploaded new
versions of LinuxCNC into Debian.
After a 10 years long break, we managed to get a new and improved
upstream version of lsdvd released just before Christmas. As
I use it regularly to maintain my DVD archive, I was very happy to
finally get out a version supporting DVDDiscID useful for uniquely
identifying DVDs. I am dreaming of a Internet service mapping DVD IDs
to IMDB movie IDs, to make life as a DVD collector easier.
My involvement in Norwegian archive standardisation and the free
software implementation of the vendor neutral Noark 5 API continued
for the entire year. I've been pushing patches into both the API and
the test code for the API, participated in several editorial meetings
regarding the Noark 5 Tjenestegrensesnitt specification, submitted
several proposals for improvements for the same. We also organised a
small seminar for Noark 5 interested people, and is organising a new
seminar in a month.
Part of the year was spent working on and coordinating a Norwegian
Bokm l translation of the marvellous children's book
Ada and
Zangemann , which focus on the right to repair and control your own
property, and the value of controlling the software on the devices you
own. The translation is mostly complete, and is now waiting for a
transformation of the project and manuscript to use Docbook XML
instead of a home made semi-text based format. Great progress is
being made and the new book build process is almost complete.
I have also been looking at how to companies in Norway can use free
software to report their accounting summaries to the Norwegian
government. Several new regulations make it very hard for companies
to do use free software for accounting, and I would like to change
this. Found a few drafts for opening up the reporting process, and
have read up on some of the specifications, but nothing much is
working yet.
These were just the top of the iceberg, but I guess this blog post
is long enough now. If you would like to help with any of these
projects, please get in touch, either directly on the project mailing
lists and forums, or with me via email, IRC or Signal. :)
As usual, if you use Bitcoin and want to show your support of my
activities, please send Bitcoin donations to my address
15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.
The Scavenger Door is a science fiction adventure and the third
book of the Finder Chronicles. While each of the books of this series
stand alone reasonably well, I would still read the series in order. Each
book has some spoilers for the previous book.
Fergus is back on Earth following the events of Driving the Deep, at loose ends and annoying his relatives. To
get him out of their hair, his cousin sends him into the Scottish hills to
find a friend's missing flock of sheep. Fergus finds things
professionally, but usually not livestock. It's an easy enough job,
though; the lead sheep was wearing a tracker and he just has to get close
enough to pick it up. The unexpected twist is also finding a metal
fragment buried in a hillside that has some strange resonance with the
unwanted gift that Fergus got in Finder.
Fergus's alien friend Ignatio is so alarmed by the metal fragment that he
turns up in person in Fergus's cousin's bar in Scotland. Before he
arrives, Fergus gets a mysteriously infuriating warning visit from alien
acquaintances he does not consider friends. He has, as usual, stepped into
something dangerous and complicated, and now somehow it's become his
problem.
So, first, we get lots of Ignatio, who is an enthusiastic large ball of
green fuzz with five limbs who mostly speaks English but does so from an
odd angle. This makes me happy because I love Ignatio and his tendency to
take things just a bit too literally.
SANTO'S, the sign read. Under it, in smaller letters, was CURIOSITIES
AND INCONVENIENCES FOR COMMENDABLE SUMS.
"Inconveniences sound just like my thing," Fergus said. "You
two want to wait in the car while I check it out?"
"Oh, no, I am not missing this," Isla said, and got out of the podcar.
"I am uncertain," Ignatio said. "I would like some curiouses, but not
any inconveniences. Please proceed while I decide, and if there is
also murdering or calamity or raisins, you will yell right away, yes?"
Also, if your story setup requires a partly-understood alien artifact that
the protagonist can get some explanations for but not have the mystery
neatly solved for them, Ignatio's explanations are perfect.
"It is a door. A doorbell. A... peephole? A key. A control light. A
signal. A stop-and-go sign. A road. A bridge. A beacon. A call. A map.
A channel. A way," Ignatio said. "It is a problem to explain. To say a
doorkey is best, and also wrong. If put together, a path may be
opened."
"And then?"
"And then the bad things on the other side, who we were trying to lock
away, will be free to travel through."
Second, the thing about Palmer's writing that continues to impress me is
her ability to take a standard science fiction plot, one whose variations
I've read probably dozens of times before, and still make it utterly
engrossing. This book is literally a fetch quest. There are a bunch of
scattered fragments, Fergus has to find them and keep them from being
assembled, various other people are after the same fragments, and Fergus
either has to get there first or get the fragments back from them. If you
haven't read this book before, you've played the video game or watched the
movie. The threat is basically a Stargate SG-1 plot. And yet, this
was so much fun.
The characters are great. This book leans less on found family than the
last one and a bit more on actual family. When I started reading this
series, Fergus felt a bit bland in the way that adventure protagonists
sometimes can, but he's fleshed out nicely as the series goes along. He's
not someone who tends to indulge in big emotions, but now the reader can
tell that's because he's the kind of person who finds things to do in
order to keep from dwelling on things he doesn't want to think about. He's
unflappable in a quietly competent way while still having a backstory and
emotional baggage and a rich inner life that the reader sees in glancing
fragments.
We get more of Fergus's backstory, particularly around Mars, but I like
that it's told in anecdotes and small pieces. The last thing Fergus wants
to do is wallow in his past trauma, so he doesn't and finds something to
do instead. There's just enough detail around the edges to deepen his
character without turning the book into a story about Fergus's emotions
and childhood. It's a tricky balancing act that Palmer handles well.
There are also more sentient ships, and I am so in favor of more sentient
ships.
"When I am adding a new skill, I import diagnostic and environmental
information specific to my platform and topology, segregate the skill
subroutines to a dedicated, protected logical space, run incremental
testing on integration under all projected scenarios and variables,
and then when I am persuaded the code is benevolent, an asset, and
provides the functionality I was seeking, I roll it into my primary
processing units," Whiro said. "You cannot do any of that,
because if I may speak in purely objective terms you may incorrectly
interpret as personal, you are made of squishy, unreliable
goo."
We get the normal pieces of a well-done fetch quest: wildly varying
locations, some great local characters (the US-based trauma surgeons on
vacation in Australia were my favorites), and believable antagonists.
There are two other groups looking for the fragments, and while one of
them is the standard villain in this sort of story, the other is an
apocalyptic cult whose members Fergus mostly feels sorry for and who add
just the right amount of surreality to the story. The more we find out
about them, the more believable they are, and the more they make this
world feel like realistic messy chaos instead of the obvious (and boring)
good versus evil patterns that a lot of adventure plots collapse into.
There are things about this book that I feel like I should be criticizing,
but I just can't. Fetch quests are usually synonymous with lazy plotting,
and yet it worked for me. The way Fergus gets dumped into the middle of
this problem starts out feeling as arbitrary and unmotivated as some video
game fetch quest stories, but by the end of the book it starts to make
sense. The story could arguably be described as episodic and cliched, and
yet I was thoroughly invested. There are a few pacing problems at the very
end, but I was too invested to care that much. This feels like a book
that's better than the sum of its parts.
Most of the story is future-Earth adventure with some heist elements. The
ending goes in a rather different direction but stays at the center of the
classic science fiction genre. The Scavenger Door reaches a
satisfying conclusion, but there are a ton of unanswered questions that
will send me on to the fourth (and reportedly final) novel in the series
shortly.
This is great stuff. It's not going to win literary awards, but if you're
in the mood for some classic science fiction with fun aliens and neat
ideas, but also benefiting from the massive improvements in
characterization the genre has seen in the past forty years, this series
is perfect. Highly recommended.
Followed by Ghostdrift.
Rating: 9 out of 10
Debian LTS
This was my hundred-twenty-seventh month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian. During my allocated time I uploaded or worked on:
[DLA 4014-1] gnuchess security update to fix one CVE related to arbitrary code execution via crafted PGN (Portable Game Notation) data.
[DLA 4015-1] rsync update to fix five CVEs related leaking information from the server or writing files outside of the client s intended destination.
[DLA 4015-2] rsync update to fix an upstream regression.
[DLA 4039-1] ffmpeg update to fix three CVEs related to possible integer overflows, double-free on
errors and out-of-bounds access.
As new CVEs for ffmpeg appeared, I started to work again for an update of this package
Last but not least I did a week of FD this month and attended the monthly LTS/ELTS meeting.
Debian ELTS
This month was the seventy-eighth ELTS month. During my allocated time I uploaded or worked on:
[ELA-1290-1] rsync update to fix five CVEs in Buster, Stretch and Jessie related leaking information from the server or writing files outside of the client s intended destination.
[ELA-1290-2] rsync update to fix an upstream regression.
[ELA-1313-1] ffmpeg update to fix six CVEs in Buster related to possible integer overflows, double-free on errors and out-of-bounds access.
[ELA-1314-1] ffmpeg update to fix six CVEs in Stretch related to possible integer overflows, double-free on errors and out-of-bounds access.
As new CVEs for ffmpeg appeared, I started to work again for an update of this package
Last but not least I did a week of FD this month and attended the monthly LTS/ELTS meeting.
Debian Printing
This month I uploaded new packages or new upstream or bugfix versions of:
brlaser new upstream release (in new upstream repository)
This work is generously funded by Freexian!
Debian Matomo
This month I uploaded new packages or new upstream or bugfix versions of:
Patrick, our Outreachy intern for the Debian Astro project, is doing very well and deals with task after task. He is working on automatic updates of the indi 3rd-party drivers and maybe the results of his work will already be part of Trixie.
Debian IoT
Unfortunately I didn t found any time to work on this topic.
Debian Mobcom
This month I uploaded new packages or new upstream or bugfix versions of:
Welcome to the first report in 2025 from the Reproducible Builds project!
Our monthly reports outline what we ve been up to over the past month and highlight items of news from elsewhere in the world of software supply-chain security when relevant. As usual, though, if you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website.
Table of contents:
reproduce.debian.net
The last few months saw the introduction of reproduce.debian.net. Announced at the recent Debian MiniDebConf in Toulouse, reproduce.debian.net is an instance of rebuilderd operated by the Reproducible Builds project. Powering that is rebuilderd, our server designed monitor the official package repositories of Linux distributions and attempt to reproduce the observed results there.
This month, however, we are pleased to announce that in addition to the existing amd64.reproduce.debian.net and i386.reproduce.debian.net architecture-specific pages, we now build for a three more architectures (for a total of five) arm64armhf and riscv64.
Two new academic papers
Giacomo Benedetti, Oreofe Solarin, Courtney Miller, Greg Tystahl, William Enck, Christian K stner, Alexandros Kapravelos, Alessio Merlo and Luca Verderame published an interesting article recently. Titled An Empirical Study on Reproducible Packaging in Open-Source Ecosystem, the abstract outlines its optimistic findings:
[We] identified that with relatively straightforward infrastructure configuration and patching of build tools, we can achieve very high rates of reproducible builds in all studied ecosystems. We conclude that if the ecosystems adopt our suggestions, the build process of published packages can be independently confirmed for nearly all packages without individual developer actions, and doing so will prevent significant future software supply chain attacks.
In this work, we perform the first large-scale study of bitwise reproducibility, in the context of the Nix functional package manager, rebuilding 709,816 packages from historical snapshots of the nixpkgs repository[. We] obtain very high bitwise reproducibility rates, between 69 and 91% with an upward trend, and even higher rebuildability rates, over 99%. We investigate unreproducibility causes, showing that about 15% of failures are due to embedded build dates. We release a novel dataset with all build statuses, logs, as well as full diffoscopes: recursive diffs of where unreproducible build artifacts differ.
As above, the entire PDF of the article is available to view online.
Distribution work
There as been the usual work in various distributions this month, such as:
10+ reviews of Debian packages were added, 11 were updated and 10 were removed this month adding to our knowledge about identified issues. A number of issue types were updated also.
The FreeBSD Foundation announced that a planned project to deliver zero-trust builds has begun in January 2025 . Supported by the Sovereign Tech Agency, this project is centered on the various build processes, and that the primary goal of this work is to enable the entire release process to run without requiring root access, and that build artifacts build reproducibly that is, that a third party can build bit-for-bit identical artifacts. The full announcement can be found online, which includes an estimated schedule and other details.
Following-up to a substantial amount of previous work pertaining the Sphinx documentation generator, James Addison asked a question pertaining to the relationship between SOURCE_DATE_EPOCH environment variable and testing that generated a number of replies.
Adithya Balakumar of Toshiba asked a question about whether it is possible to make ext4 filesystem images reproducible. Adithya s issue is that even the smallest amount of post-processing of the filesystem results in the modification of the Last mount and Last write timestamps.
FUSE (Filesystem in USErspace) filesystems such as disorderfs do not delete files from the underlying filesystem when they are deleted from the overlay. This can cause seemingly straightforward tests for example, cases that expect directory contents to be empty after deletion is requested for all files listed within them to fail.
Upstream patches
The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:
diffoscopediffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made the following changes, including preparing and uploading versions 285, 286 and 287 to Debian:
Security fixes:
Validate the --css command-line argument to prevent a potential Cross-site scripting (XSS) attack. Thanks to Daniel Schmidt from SRLabs for the report. []
Prevent XML entity expansion attacks. Thanks to Florian Wilkens from SRLabs for the report.. [][]
Print a warning if we have disabled XML comparisons due to a potentially vulnerable version of pyexpat. []
Bug fixes:
Correctly identify changes to only the line-endings of files; don t mark them as Ordering differences only. []
When passing files on the command line, don t call specialize( ) before we ve checked that the files are identical or not. []
Do not exit with a traceback if paths are inaccessible, either directly, via symbolic links or within a directory. []
Don t cause a traceback if cbfstool extraction failed.. []
Use the surrogateescape mechanism to avoid a UnicodeDecodeError and crash when any decoding zipinfo output that is not UTF-8 compliant. []
Testsuite improvements:
Don t mangle newlines when opening test fixtures; we want them untouched. []
Move to assert_diff in test_text.py. []
Misc improvements:
Drop unused subprocess imports. [][]
Drop an unused function in iso9600.py. []
Inline a call and check of Config().force_details; no need for an additional variable in this particular method. []
Remove an unnecessary return value from the Difference.check_for_ordering_differences method. []
Remove unused logging facility from a few comparators. []
Update copyright years. [][]
In addition, fridtjof added support for the ASAR.tar-like archive format. [][][][] and lastly, Vagrant Cascadian updated diffoscope in GNU Guix to version 285 [][] and 286 [][].
strip-nondeterminism is our sister tool to remove specific non-deterministic results from a completed build. This month version 1.14.1-1 was uploaded to Debian unstable by Chris Lamb, making the following the changes:
Clarify the --verbose and non --verbose output of bin/strip-nondeterminism so we don t imply we are normalizing files that we are not. []
Bump Standards-Version to 4.7.0. []
Website updates
There were a large number of improvements made to our website this month, including:
Update the website s README to make the setup command copy & paste friendly. []
Reproducibility testing framework
The Reproducible Builds project operates a comprehensive testing framework running primarily at tests.reproducible-builds.org in order to check packages and other artifacts for reproducibility. In January, a number of changes were made by Holger Levsen, including:
Disable debug output for FreeBSD rebuilding jobs. []
Upgrade to FreeBSD 14.2 [] and document that bmake was installed on the underlying FreeBSD virtual machine image [].
Misc:
Update the real year to 2025. []
Don t try to install a Debian bookworm kernel from backports on the infom08 node which is running Debian trixie. []
Don t warn about system updates for systems running Debian testing. []
Fix a typo in the ZOMBIES definition. [][]
In addition:
Ed Maste modified the FreeBSD build system to the clean the object directory before commencing a build. []
Gioele Barabucci updated the rebuilder stats to first add a category for network errors [] as well as to categorise failures without a diffoscope log [].
Jessica Clarke also made some FreeBSD-related changes, including:
Ensuring we clean up the object directory for second build as well. [][]
Updating the sudoers for the relevant rm -rf command. []
Update the cleanup_tmpdirs method to to match other removals. []
Rework and simplify the generation of statistics linked from reproduce.debian.net. [][][][]
Roland Clobus:
Update the reproducible_debstrap job to call Debian s debootstrap with the full path [] and to use eatmydata as well [][].
Make some changes to deduce the CPU load in the debian_live_build job. []
Lastly, both Holger Levsen [] and Vagrant Cascadian [] performed some node maintenance.
If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:
Hi
In my last blog, I explained how we resolved a throttling issue involving Azure storage API. In the end, I mentioned that I was not sure of the root cause of the throttling issue.
Even though we no longer had any problem in dev and preprod cluster, we still faced throttling issue with prod. The main difference between these 2 environments is that we have about 80 PVs in prod versus 15 in the other environments. Given that we manage 1500 pods in prod, 80 PVs does not look like a lot.
To continue the investigation, I ve modified k8s-scheduled-volume-snapshotter to limit the number of snaphots done in a single cron run (see add maxSnapshotCount parameter pull request).
In prod, we used the modified snapshotter to trigger snapshots one by one.
Even with all previous snapshots cleaned up, we could not trigger a single new snapshot without being throttled. I guess that, in the cron job, just checking the list of PV to snapshot was enough to exhaust our API quota.
Azure doc mention that a leaky bucket algorithm is used for throttling. A full bucket holds tokens for 250 API calls, and the bucket gets 25 new tokens per second. Looks like that not enough.
I was puzzled and out of ideas .
I looked for similar problems in AKS issues on GitHub where I found this comment that recommend using useDataPlaneAPI parameter in the CSI file driver. That was it!
I was flabbergasted by this parameter: why is CSI file driver able to use 2 APIs ? Why is one on them so limited ? And more importantly, why is the limited API the default one ?
Anyway, setting useDataPlaneAPI: "true" in our VolumeSnapshotClass manifest was the right solution. This indeed solved the throttling issue in our prod cluster.
But not the snaphot issue . Amongst the 80 PV, I still had 2 snaphots failing.
Fortunately, the error was mentioned in the description of the failed snapshots: we had too many (200) snapshots for these shared volumes.
What ?? All these snapshots were cleaned up last week.
I then tried to delete these snaphots through azure console. But the console failed to delete these snapshot due to API throttling. Looks like Azure console is not using the right API.
Anyway, I went back to the solution explained in my previous blog, I listed all snapshots with az command. I indeed has a lot of snaphots, a lot of them dated Jan 19 and 20. There was often a new bogus snaphot created every minute.
These were created during the first attempt at fixing the throttling issue. I guess that even though CSI file driver was throttled, a snaphot was still created in the storage account, but the CSI driver did not see it and retried a minute later. What a mess.
Anyway, I ve cleaned up again these bogus snapshot , and now, snaphot creation is working fine .
For now.
All the best.
Dear Debian community,
this is bits from DPL for January.
Sovereign Tech Agency
I was recently pointed to Technologies and Projects supported by the
Sovereign Tech Agency which is financed by the German Federal
Ministry for Economic Affairs and Climate Action. It is a subsidiary of
the Federal Agency for Disruptive Innovation, SPRIND GmbH.
It is worth sending applications there for distinct projects as that is
their preferred method of funding. Distinguished developers can also
apply for a fellowship position that pays up to 40hrs / week (32hrs when
freelancing) for a year. This is esp. open to maintainers of larger
numbers of packages in Debian (or any other Linux distribution).
There might be a chance that some of the Debian-related projects
submitted to the Google Summer of Code that did not get funded could be
retried with those foundations. As per the FAQ of the project:
"The Sovereign Tech Agency focuses on securing and strengthening open
and foundational digital technologies. These communities working on
these are distributed all around the world, so we work with people,
companies, and FOSS communities everywhere."
Similar funding organizations include the Open Technology Fund and
FLOSS/fund. If you have a Debian-related project that fits these
funding programs, they might be interesting options. This list is by no
means exhaustive just some hints I ve received and wanted to share. More
suggestions for such opportunities are welcome.
Year of code reviews
On the debian-devel mailing list, there was a long thread titled
"Let's make 2025 a year when code reviews became common in Debian".
It initially suggested something along the lines of:
"Let's review MRs in Salsa." The discussion quickly expanded to
include patches that have
been sitting in the BTS for years, which deserve at least the same
attention. One idea I'd like to emphasize is that associating BTS bugs
with MRs could be very convenient. It s not only helpful for
documentation but also the easiest way to apply patches.
I d like to emphasize that no matter what workflow we use BTS, MRs, or a
mix it is crucial to uphold Debian s reputation for high quality.
However, this reputation is at risk as more and more old issues
accumulate. While Debian is known for its technical excellence,
long-standing bugs and orphaned packages remain a challenge. If we don t
address these, we risk weakening the high standards that Debian is
valued for. Revisiting old issues and ensuring that unmaintained
packages receive attention is especially important as we prepare for the
Trixie release.
Debian Publicity Team will no longer post on X/Twitter
The Press Team has my full support in its decision to stop posting on X.
As per the Publicity delegation:
The team is in charge of deciding the most suitable publication
venue or venues for announcements and when they are published.
the team once decided to join Twitter, but circumstances have since
changed. The current Press delegates have the institutional authority to
leave X, just as their predecessors had the authority to join. I
appreciate that the team carefully considered the matter, reinforced by
the arguments developed on the debian-publicity list, and communicated
its reasoning openly.
Kind regards,
Andreas.
The RcppUUID package
on CRAN has been providing
UUIDs (based on the underlying Boost
library) for several years. Written by Artem Klemsov and maintained
in this gitlab
repo, the package is a very nice example of clean and
straightforward library binding.
When we did our annual
BH upgrade to 1.87.0 and check reverse dependencies, we noticed the
RcppUUID
needed a small and rather minor update which we showed as a short diff
in an
issue filed. Neither I nor CRAN heard from Artem, so the
packaged ended up being archived last week. Which in turn lead me to
make this minimal update to 1.1.2 to resurrect it, which CRAN processed more or less like a
regular update given this explanation and so it arrived last Friday.
Courtesy of my CRANberries, there
is also a a
new package note (no diffstat report yet). More detailed
information is on the RcppUUID
page, or the github repo.
This was originally posted on SOTA
Forums.
It s here for completeness of my writing.
To Quote @MM0EFI and the GM0ESS gang, today was a particularly Amateur showing!
Having spent all weekend locked in the curling rink ruining my knees and inflicting mild liver damage in the Aberdeen City Open competition, I needed some outside time away from people to stretch the legs and loosen my knees.
With my teammates/guests shipped off early on account of our quality performance and the days fair drawin out now, I found myself with a free afternoon to have a quick run up something nearby before a 1640 sunset! Up the back of Bennachie is a quick steady ascent and in 13 years of living up here I ve never summited the big hill! Now is as good a time as any. In SOTA terms, this hill is GM/ES-061. In Geographical terms, it s around 20 miles inland from Aberdeen city here.
I ve been experimenting with these Aliexpress whips since the end of last year and the forecast wind was low enough to take one into the hills. I cut and terminated 8x 2.5m radials for an effective ground plane last week and wanted to try that against the flat ribbon that it came with.
The ascent was pleasant enough, got to the summit in good time, and out came my Quansheng radio to get the GM/ES-Society on 2m. First my Nagoya whip - called CQ and heard nothing, with general poor reports in WhatsApp I opted to get the slim-g up my aliexpress fibreglass mast.
In an amateur showing last week, I broke the tip of the mast on Cat Law helping 2M0HSK do his first activation due to the wind, and had forgotten this until I summited this week. Squeezing my antenna on was tough, and after many failed attempts to get it up (the mast kept collapsing as I was rushing and not getting the friction hold on each section correctly) and still not hearing anything at all, I changed location and tried again.
In my new position, I received 2M0RVZ 4/4 at best, but he was hearing my 5/9. Similarly GM5ALX and GM4JXP were patiently receiving me loud and clear but I couldn t hear them at all. I fiddled with settings and decided the receive path of the Quansheng must be fried or sad somehow, but I don t yet have a full set of diagnostics run.
I ll take my Anytone on the next hill and compare them against each other I think.
I gave up and moved to HF, getting my whip and new radials into the ground:
Quick to deploy which is what I was after. My new 5m of coax with a choke fitted attached to the radio and we were off to the races - A convenient thing of beauty when it s up:
I ve made a single guy with a sotabeams top insulator to brace against wind if need be, but that didn t need to be used today.
I hit tune, and the G90 spent ages clicking away. In fact, tuning to 14.074, I could only see the famed FT8 signals at S2.
What could be wrong here? Was it my new radials? the whip has behaved before Minutes turned into tens of minutes playing with everything, and eventually I worked out what was up - my coax only passed signal when I the PL259 connector at the antenna juuuust right. Once I did that, I could take the tuner out the system and work 20 spectacularly well. Until now, I d been tuning the coax only.
Another Quality Hibby Build Job . That s what s wrong!
I managed to struggle my way through a touch of QRM and my wonky cable woes to make enough contacts with some very patient chasers and a summit to summit before my frustration at the situation won out, and down the hill I went after a quick pack up period. I managed to beat the sunset - I think if the system had worked fine, I d have stayed on the hill for sunset.
I think it s time for a new mast and a coax retermination!
Most of my Debian contributions this month were
sponsored by
Freexian. If you appreciate this sort of work and are at a company that
uses Debian, have a look to see whether you can pay for any of
Freexian s services; as well as the direct
benefits, that revenue stream helps to keep Debian development sustainable
for me and several other lovely
people.
You can also support my work directly via
Liberapay.
Python team
We finally made Python 3.13 the default version in testing! I fixed various
bugs that got in the way of this:
I ported python-pypump to IPython 8.0.
I fixed python-datamodel-code-generator to handle isort 6, and contributed
that
upstream.
I fixed some packages to tolerate future versions of dh-python that will
drop their dependency on python3-setuptools:
I removed the old python-celery-common transitional
package from celery, since nothing in
Debian needs it any more.
I fixed or helped to fix various other build/test failures:
Nova gera o: uma entrevista com iniciantes no projeto Debian
Instala o personalizada e automatizada do Debian com preseed
Manipulando patches com git-buildpackage
debian.social: Socializando Debian do jeito Debian
Proxy reverso com WireGuard
Celebra o dos 30 anos do Debian!
Instalando o Debian em disco criptografado com LUKS
O que a equipe de localiza o j conquistou nesses 30 anos
Debian - Projeto e Comunidade!
Design Gr fico e Software livre, o que fazer e por onde come ar
Many years ago I made myself a 
Then a few years ago the cheap cotton had started to get worn, and I
decided I needed to replace it. I found a second choice (and thus
cheaper :) ) version of a 
This time I skipped a few pockets that I had found I didn t use that
much, and I didn t add a hood, which didn t play that well when worn
over a hoodie, but I added some detached sleeves, for additional wind
protection.
This left about 60 cm and some odd pieces of leftover fabric in my
stash, for which I had no plan.
And then February
I did however have a spool of reflector thread made of glass fibre by
Rico Design, which I think was originally sold to be worked into
knitting or crochet projects (it is now discontinued) and I had never
used.
I decided to try and sew a decorative blanket stitch border, a decision
I had reasons to regret, since the thread broke and tangled like crazy,
but in the end it was done, I like how it looks, and it seems pretty
functional. I hope it won t break with time and use, and if it does I ll
either fix it or try to redo with something else.
Of course, the day I finished sewing the reflective border it stopped
raining, so I haven t worn it yet, but I hope I ll be able to, and if it
is an horrible failure I ll make sure to update this post.
I can t remember exactly the joke I was making at the time in my
Like each month, have a look at the work funded by 
To continue the investigation, I ve modified 
. I guess that, in the cron job, just checking the list of PV to snapshot was enough to exhaust our API quota. 
Azure 
I was puzzled 
and out of ideas 
.
I looked for similar problems in 
I was flabbergasted 
by this parameter: why is CSI file driver able to use 2 APIs ? Why is one on them so limited ? And more importantly, why is the limited API the default one ?
Anyway, setting 
But not the snaphot issue 
. Amongst the 80 PV, I still had 2 snaphots failing.
Fortunately, the error was mentioned in the description of the failed snapshots: we had too many (200) snapshots for these shared volumes.
What ?? 
All these snapshots were cleaned up last week.
I then tried to delete these snaphots through azure console. But the console failed to delete these snapshot due to API throttling. Looks like Azure console is not using the right API. 
Anyway, I went back to the solution explained in my previous blog, I listed all snapshots with 
. What a mess.
Anyway, I ve cleaned up again these bogus snapshot 
, and now, snaphot creation is working fine 
.
For now.
All the best.
Dear Debian community,
this is bits from DPL for January.
Sovereign Tech Agency
I was recently pointed to Technologies and Projects supported by the
The 
Quick to deploy which is what I was after. My new 5m of coax with a choke fitted attached to the radio and we were off to the races - A convenient thing of beauty when it s up:
I ve made a single guy with a sotabeams 
Most of my Debian contributions this month were