All but about four hours of my Debian contributions this month were
sponsored by
Freexian. (I ended up going a bit over my 20% billing limit this month.)
You can also support my work directly via
Liberapay.
Since autopkgtests are great for making sure we spot regressions caused by
changes in dependencies, I added one to man-db that runs the upstream tests
against the installed package. This required some preparatory work
upstream, but otherwise was surprisingly easy to do.
OpenSSH
I fixed the various 9.8 regressions I mentioned last
month: socket activation, libssh2, and
Twisted. There were a few other regressions reported too: TCP wrappers
support,
openssh-server-udeb,
and xinetd were all broken by changes
related to the listener/per-session binary split, and I fixed all of those.
Once all that had made it through to testing, I finally uploaded the first
stage of my plan to split out GSS-API
support: there
are now openssh-client-gssapi and openssh-server-gssapi packages in
unstable, and if you use either GSS-API authentication or key exchange then
you should install the corresponding package in order for upgrades to
trixie+1 to work correctly. I’ll write a release note once this has reached testing.
Multiple identical results from getaddrinfo
I expect this is really a bug in a chroot creation script somewhere, but I
haven’t been able to track down what’s causing it yet. My sbuild chroots,
and apparently Lucas Nussbaum’s as well, have an /etc/hosts that looks
like this:
The last line clearly ought to be ::1 rather than 127.0.0.1; but things
mostly work anyway, since most code doesn’t really care which protocol it
uses to talk to localhost. However, a few things try to set up test
listeners by calling getaddrinfo("localhost", ...) and binding a socket
for each result. This goes wrong if there are duplicates in the resulting
list, and the test output is typically very confusing: it looks just like
what you’d see if a test isn’t tearing down its resources correctly, which
is a much more common thing for a test suite to get wrong, so it took me a
while to spot the problem.
I tend to care about openssl migrating to testing promptly, since openssh
uploads have a habit of getting stuck on it otherwise.
Debian’s OpenSSL packaging recently split out some legacy code (cryptography
that’s no longer considered a good idea to use, but that’s sometimes needed
for compatibility) to an openssl-legacy-provider package, and added a
Recommends on it. Most users install Recommends, but package build
processes don’t; and the Python cryptography package requires this code
unless you set the CRYPTOGRAPHY_OPENSSL_NO_LEGACY=1 environment variable,
which caused a bunch of packages that build-depend on it to fail to build.
After playing whack-a-mole setting that environment variable in a few
packages’ build process, I decided I didn’t want to be caught in the middle
here and filed an upstream
issue to see if I could
get Debian’s OpenSSL team and cryptography’s upstream talking to each other
directly. There was some moderately spirited discussion and the issue
remains open, but for the time being the OpenSSL team has effectively
reverted the
change
so it’s no longer a pressing problem.
I upgraded alembic, automat, gunicorn, incremental, referencing, pympler
(fixing compatibility with Python >=
3.10), python-aiohttp, python-asyncssh
(fixing CVE-2023-46445,
CVE-2023-46446, and
CVE-2023-48795), python-avro,
python-multidict (fixing a build failure with GCC
14), python-tokenize-rt, python-zipp,
pyupgrade, twisted (fixing CVE-2024-41671
and CVE-2024-41810), zope.exceptions,
zope.interface, zope.proxy, zope.security, zope.testrunner. In the process,
I added myself to Uploaders for zope.interface; I’m reasonably comfortable
with the Zope Toolkit and I seem to be gradually picking up much of its
maintenance in Debian.
A few of these required their own bits of yak-shaving:
Another short status update of what happened on my side last month.
Quite a bit of time went
into helping organize the FrOSCon FOSS on Mobile dev room (day 1, day 2, summary) but that was all worth it and fun - so was releasing Phosh 0.41.0 (which incidetally happened right before FrOScon). A three years old MR to xdg-spec to add call categories landed (thanks Matthias) allowing us to finally provide proper feedback for e.g. IM calls too. The rest was some OSK improvements (around Indic language support via varnam and layout configuration), some Cell Broadcast advancements (thanks to NGI0 for supporting this) but also some fixes. Here's the details:
Allow to select OSK layouts (MR). This ensures only actually available layouts can be selected. Currently used by phosh-osk-stub but can easily be extended to squeekboard once it provides the information.
Rework most bits of Cell Broadcast to move it closer to undraft status (MR).
(Remaining bits affect enabling of unsolicited messages and setting channels).
If you want to support my work see donations. This includes
a list of hardware we want to improve support for. Thanks a lot to all current and past donors.
I asked Zyxel for a source dump for GPLed firmware on their GS1900-8HP
switches, and after months, they finally obliged (they seemingly had
no idea that it should just be, well, available). So I'm dumping it
here
in case anyone else wants it.
I haven't tried actually building it, but notably, it seems to contain
the entire CLI, since they base it on Quagga's vtysh (which is GPL).
Reasons Not to Worry is a self-help non-fiction book about
stoicism, focusing specifically on quotes from Seneca, Epictetus, and
Marcus Aurelius. Brigid Delaney is a long-time Guardian columnist
who has written on a huge variety of topics, including (somewhat
relevantly to this book) her personal experiences trying weird fads.
Stoicism is having a moment among the sort of men who give people life
advice in podcast form. Ryan Holiday, a former marketing executive, has
made a career out of being the face of stoicism in everyone's podcast
(and, of course, hosting his own). He is far from alone. If you pay
attention to anyone in the male self-help space right now (Cal Newport, in
my case), you have probably heard something vague about the "wisdom of the
stoics."
Given that the core of stoicism is easily interpreted as a strategy for
overcoming your emotions with logic, this isn't surprising. Philosophies
that lean heavily on college dorm room logic, discount emotion, and argue
that society is full of obvious flaws that can be analyzed and debunked by
one dude with some blog software and a free afternoon have been very
popular in tech circles for the past ten to fifteen years, and have spread
to some extent into popular culture. Intriguingly, though, stoicism is a
system of virtue
ethics, which means it is historically in opposition to consequentialist
philosophies like utilitarianism, the ethical philosophy behind
effective altruism and other
related Silicon Valley fads.
I am pretty exhausted with the whole genre of men talking to each other
about how to live a better life — Cal Newport by himself more than
satisfies the amount of that I want to absorb — but I was still mildly
curious about stoicism. My education didn't provide me with a satisfying
grounding in major historical philosophical movements, so I occasionally
look around for good introductions. Stoicism also has some reputation as
an anxiety-reduction technique, and I could use more of those. When I saw
a Discord recommendation for Reasons Not to Worry that specifically
mentioned its lack of bro perspective, I figured I'd give it a shot.
Reasons Not to Worry is indeed not a bro book, although I would
have preferred fewer appearances of the author's friend Andrew, whose
opinions on stoicism I could not possibly care less about. What it is,
though, is a shallow and credulous book that falls squarely in the middle
of the lightweight self-help genre. Delaney is here to explain why
stoicism is awesome and to convince you that a school of Greek and Roman
philosophers knew exactly how you should think about your life today. If
this sounds quasi-religious, well, I'll get to that.
Delaney does provide a solid introduction to stoicism that I think is a
bit more approachable than reading the relevant Wikipedia article. In her
presentation, the core of stoicism is the practice of four virtues:
wisdom, courage, moderation, and justice. The modern definition of
"stoic" as someone who is impassive in the presence of pleasure or pain is
somewhat misleading, but Delaney does emphasize a goal of
ataraxia, or tranquility of mind. By making that the goal rather
than joy or pleasure, stoicism tries to avoid the trap of the
hedonic treadmill
in favor of a more achievable persistent contentment.
As an aside, some quick Internet research makes me doubt Delaney's summary
here. Other material about stoicism I found focuses on apatheia
and associates ataraxia with Epicureanism instead. But I won't
start quibbling with Delaney's definitions; I'm not qualified and this
review is already too long.
The key to ataraxia, in Delaney's summary of stoicism, is to
focus only on those parts of life we can control. She summarizes those as
our character, how we treat others, and our actions and reactions.
Everything else — wealth, the esteem of our colleagues, good health, good
fortune — is at least partly outside of our control, and therefore we
should enjoy it when we have it but try to be indifferent to whether it
will last. Attempting to control things that are outside of our control
is doomed to failure and will disturb our tranquility. Essentially all of
this book is elaborations and variations on this theme, specialized to
some specific area of life like social media, anxiety, or grief and
written in the style of a breezy memoir.
If you're familiar with modern psychological treatment frameworks like
cognitive behavioral therapy or
acceptance and commitment therapy, this summary of stoicism may sound
familiar. (Apparently this is not an accident; the predecessor to CBT
used stoicism as a philosophical basis.) Stoicism, like those treatment
approaches, tries to refocus your attention on the things that you can
improve and de-emphasizes the things outside of your control. This is a
lot of the appeal, at least to me (and I think to Delaney as well).
Hearing that definition, you may have some questions. Why those virtues
specifically? They sound good, but all virtues sound good almost by
definition. Is there any measure of your success in following those
virtues outside your subjective feeling of ataraxia? Does the
focus on only things you can control lead to ignoring problems only mostly
outside of your control, where your actions would matter but only to a
small degree? Doesn't this whole philosophy sound a little self-centered?
What do non-stoic virtue ethics look like, and why do they differ from
stoicism? What is the consequentialist critique of stoicism?
This is where the shortcomings of this book become clear: Delaney is not
very interested in questions like this. There are sections on some of
those topics, particularly the relationship between stoicism and social
justice, but her treatment is highly unsatisfying. She raises the
question, talks about her doubts about stoicism's applicability, and then
says that, after further thought, she decided stoicism is entirely
consistent with social justice and the stoics were right after all. There
is a little bit more explanation than that, but not much. Stoicism can
apparently never be wrong; it can only be incompletely understood.
Self-help books often fall short here, and I suspect this may be what the
audience wants. Part of the appeal of the self-help genre is artificial
certainty. Becoming a better manager, starting a business, becoming more
productive, or working out an entire life philosophy are not problems
amenable to a highly approachable and undemanding book. We all know that
at some level, but the seductive allure of the self-help genre is the
promise of simplifying complex problems down to a few approachable bullet
points. Here is a life philosophy in a neatly packaged form, and if you
just think deeply about its core principles, you will find they can be
applied to any situation and any doubts you were harboring will turn out
to be incorrect.
I am all too familiar with this pattern because it's also how
fundamentalist Christianity works. The second time Delaney talked about
her doubts about the applicability of stoicism and then claimed a few
pages later that those doubts disappeared with additional thought and
discussion, my radar went off. This book was sounding less like a
thoughtful examination of one specific philosophy out of many and more
like the soothing adoption of religious certainty by a convert. I was
therefore entirely unsurprised when Delaney all but says outright in the
epilogue that she's adopted stoicism as her religion and approaches it
with the same dedicated practice that she used to bring to Catholicism. I
think this is where a lot of self-help books end up, although most of them
don't admit it.
There's nothing wrong with this, to be clear. It sounds like she was
looking for a non-theistic religion, found one that she liked, and is
excited to tell other people about it. But it's a profound mismatch with
what I was looking for in an introduction to stoicism. I wanted context,
history, and a frank discussion of the problems with adopting philosophy
to everyday issues. I also wanted some acknowledgment that it is highly
unlikely that a few men who lived 2000 years ago in a wildly different
social context, and with drastically limited information about cultures
other than their own, figured out a foolproof recipe for how to approach
life. The subsequent two millennia of philosophical debates prove that
stoicism didn't end the argument, and that a lot of other philosophers
thought that stoicism got a few things wrong. You would never know that
from this book.
What I wanted is outside the scope of this sort of undemanding self-help
book, though, and this is the problem that I keep having with philosophy.
The books I happen across are either nigh-incomprehensibly dense and
academic, or they're simplified into catechism. This was the latter.
That's probably more the fault of my reading selection than it is the
fault of the book, but it was still annoying.
What I will say for this book, and what I suspect may be the most useful
property of self-help books in general, is that it prompts you to think
about basic stoic principles without getting in the way of your thoughts.
It's like background music for the brain: nothing Delaney wrote was very
thorny or engaging, but she kept quietly and persistently repeating the
basic stoic formula and turning my thoughts back to it. Some of those
thoughts may have been useful? As a source of prompts for me to ponder,
Reasons Not to Worry was therefore somewhat successful. The
concept of not trying to control things outside of my control is simple
but valid, and it probably didn't hurt me to spend a week thinking about
it.
"It kind of works as an undemanding meditation aid" is not a good enough
reason for me to recommend this book, but maybe that's what someone else
is looking for.
We're doing fairly well: Debian release team have been working
really hard on a double point release today. Final release for Bullseye
as 11.11 as it moves to LTS.
12.7 Bookworm install media finishing tests - it's been quite a long day so far.
For 11.11 we're part way through media tests.
We've
been joined by a lot of enthusiastic folk from Cape Town who've been a
great help. Always nice to see old friends and new people join us on IRC
- and they've just joined us for a short video call.
This has gone well: two release day media checking and bug-squashing groups on two continents is excellent.
Dear
Cape Town - feel free to join us for the next time and we'll hold the
video call open for longer. If we don't see any of you here in Cambridge
for mini-Debconf, we'll meet up in Brest for Debconf 25.
In 2020, Google introduced Core Web Vitals metrics to measure some aspects
of real-world user experience on the web. This blog has consistently achieved
good scores for two of these metrics: Largest Contentful Paint and
Interaction to Next Paint. However, optimizing the third metric, Cumulative
Layout Shift, which measures unexpected layout changes, has been more
challenging. Let’s face it: optimizing for this metric is not really useful for
a site like this one. But getting a better score is always a good distraction. 💯
To prevent the “flash of invisible text” when using web fonts, developers should
set the font-display property to swap in @font-face rules. This method
allows browsers to initially render text using a fallback font, then replace it
with the web font after loading. While this improves the LCP score, it causes
content reflow and layout shifts if the fallback and web fonts are not
metrically compatible. These shifts negatively affect the CLS score. CSS
provides properties to address this issue by overriding font metrics when using
fallback fonts: size-adjust,
ascent-override, descent-override,
and line-gap-override.
Instead of computing each property from font average metrics, I put together a
tool for interactively tuning fallback fonts.1
Instructions
Load your custom font.
Select a fallback font to tune.
Adjust the size-adjust property to match the width of your custom font with
the fallback font. With a proportional font, it is not possible to achieve a
perfect match.
Fine-tune the ascent-override property. Aim to align the final dot of the
last paragraph while monitoring the font’s baseline. For more precise
adjustment, disable the “” option.
Modify the descent-override property. The goal is to make the two boxes
match. You may need to alternate between this and the previous property for
optimal results.
If necessary, adjust the line-gap-override property. This step is typically
not required.
The process needs to be repeated for each fallback font. Some platforms may not
include certain fonts. Notably, Android lacks most fonts found in other
operating systems. It replaces Georgia with Noto Serif, which is not
metrically-compatible.
Tool
This tool is not available from the Atom feed.
Results
For the body text of this blog, I get the following CSS definition:
@font-face{font-family:Merriweather;font-style:normal;font-weight:400;src:url("../fonts/merriweather.woff2")format("woff2");font-display:swap;}@font-face{font-family:"Fallback for Merriweather";src:local("Noto Serif"),local("Droid Serif");size-adjust:98.3%;ascent-override:99%;descent-override:27%;}@font-face{font-family:"Fallback for Merriweather";src:local("Georgia");size-adjust:106%;ascent-override:90.4%;descent-override:27.3%;}font-family:Merriweather,"Fallback for Merriweather",serif;
After a month, the CLS metric improved to 0:
Recent Core Web Vitals scores for vincent.bernat.ch
About custom fonts
Using safe web fonts or a modern font stack is often simpler. However, I
prefer custom web fonts. Merriweather and Iosevka, which are used in
this blog, enhance the reading experience. An alternative approach could be to
use Georgia as a serif option. Unfortunately, most default monospace fonts are
ugly.
Furthermore, paragraphs that combine proportional and monospace fonts can create
visual disruption. This occurs due to mismatched vertical metrics or weights. To
address this issue, I adjust Iosevka’s metrics and weight to align with
Merriweather’s characteristics.
Similar tools already exist, like the Fallback Font Generator,
but they were missing a few features, such as the ability to load the
fallback font or to have decimals for the CSS properties. And no source
code. ↩︎
A double length Debian release means the Release Team don't get much peace What with last minute breaks And the time that it takes Treat them with respect today, please
The media teams on the hook As we follow our normal play book With laptops all primed The images are timed Once we're told we'll start taking our look
This is the last time for 11 And for Bookworm, it's just 12.7 Give us time for each test As we all do our best With our ThinkPads - I see at least seven :)
The Shepherd's Crown is the 41st and final Discworld novel and the
5th and final Tiffany Aching novel. You should not start here.
There is a pretty major character event in the second chapter of this
book. I'm not going to say directly what it is, but you will likely be
able to guess from the rest of the review. If you're particularly adverse
to spoilers, you may want to skip reading this until you've read the book.
Tiffany Aching is extremely busy. Witches are responsible for all the
little tasks that fall between the cracks, and there are a lot of cracks.
The better she gets at her job, the more of the job there seems to be.
"Well," said Tiffany, "there's too much to be done and not enough
people to do it."
The smile that the kelda gave her was a strange one. The little woman
said, "Do ye let them try? Ye mustn't be afraid to ask for help.
Pride is a good thing, my girl, but it will kill you in time."
And that's before an earth-shattering change in the world of witches, one
that leaves Tiffany shuttling between Lancre and the Chalk trying to be
too many things to too many people. Plus the kelda is worried some deeper
trouble is brewing. And then Tiffany gets an exiled elven queen who has
never understood the worth of other people dumped on her, and has to
figure out what to do with her.
The starting idea is great. I continue to be impressed with how well
Pratchett handles Tiffany's coming-of-age story. Finding one's place in
the world isn't one lesson or event; it's layers of them, with each new
growth in responsibility uncovering new things to learn that are often
quite different from the previous problems. Tiffany has worked through
child problems, adolescent problems, and new adulthood problems. Now
she's on a course towards burnout, which is exactly the kind of problem
Tiffany would have given her personality.
Even better, the writing at the start of The Shepherd's Crown is
tight and controlled and sounds like Pratchett, which was a relief after
the mess of Raising Steam. The contrast
is so sharp that I found myself wondering if parts of this book had been
written earlier, or if Pratchett found a new writing or editing method.
The characters all sound like themselves, and although some of the turns
of phrase are not quite as sharp as in earlier books, they're at least at
the level of Snuff.
Unfortunately, it doesn't last. There are some great moments and some
good quotes, but the writing starts to slip at about the two-thirds point,
the sentences began to meander, the characters start repeating the name of
the person they're talking to, and the narration becomes increasingly
strained. It felt like Pratchett knew the emotional tone he wanted to
evoke but couldn't find a subtle way to express it, so the story and the
characters start to bludgeon the reader with Grand Statements. It's never
as bad as Raising Steam, but it doesn't slip smoothly off the page
to rewrite your brain the way that Pratchett could at his best.
What makes this worse is that the plot is not very interesting. I wanted
to read a book about Tiffany understanding burnout, asking for help, and
possibly also about mental load and how difficult delegation is. There is
some movement in that direction: she takes on some apprentices, although
we don't see as much of her interactions with them as I'd like, and
there's an intriguing new male character who wants to be a witch. I wish
Pratchett had been able to give Geoffrey his own book. He and his goat
were the best part of the story, but it felt rushed and I think he would
have had more impact if the reader got to see him develop his skills over
time the way that we did with Tiffany.
But, alas, all of that is side story to the main plot, which is about
elves.
As you may know from previous reviews, I do not get along with Pratchett's
conception of elves. I find them boring and too obviously evil, and have
since Lords and Ladies. Villains have
never been one of Pratchett's strengths, and I think his elves are my
least favorite. One of the goals of this book is to try to make them less
one-note by having Tiffany try to teach one of them empathy, but I didn't
find any of the queen's story arc convincing. If Pratchett had pulled
those threads together with something more subtle, emotional, and
subversive, I think it could have worked, but instead we got another
battle royale, and Lords and Ladies did that better.
"Granny never said as she was better than others. She just got on
with it and showed 'em and people worked it out for themselves."
And so we come to the end. I wish I could say that the quality held up
through the whole series, and it nearly did, but alas it fell apart
a bit at the end. Raising Steam I would skip entirely. The
Shepherd's Crown is not that bad, but it's minor Pratchett that's worth
reading mainly because it's the send-off (and there are a lot of reasons
within the story to think Pratchett knew that when writing it). There are
a few great lines, some catharsis, and a pretty solid ending for Tiffany,
but it's probably not a book that I'll re-read.
Content warning: major character death.
Special thanks to Emmet Asher-Perrin, whose
Tor.com/Reactor
re-read of all of Discworld got me to pick the series up again and
finally commit to reading all of it. I'm very glad I did.
A shiny new release 0.2.4 of pkgKitten
arrived on CRAN earlier, and
has also been been uploaded to Debian. pkgKitten
makes it simple to create new R packages via a simple function
invocation. A wrapper kitten.r exists in the littler
package to make it even easier.
This release contains several improvements to the (optional) setup of
the (wonderful) tinytest package,
now supports the (now mandatory) ‘Authors@R’ and polished a few aspect
around the package repository and continuous integrations.
The set of changes follows.
Changes in version 0.2.4
(2024-08-30)
The .Rbuildignore stanza now includes .github
The support of and usage illustrations of tinytest are much enhanced (Paul Hudor in #18
adressing #19 and
#20)
The .gitignore file now includes C++ related files
Improvements and polish to badges and continuous
integration
The DESCRIPTION file now contains an Authors@R entry
It (was) that time of year again - last weekend we hosted a bunch
of nice people at our place in Cambridge for the annual Debian
UK OMGWTFBBQ!
Lots of friends, lots of good food and drink. Of course lots of
geeky discussions about Debian, networking, random computer languages
and... screws? And of course some card games to keep us
laughing into each night!
Many thanks to a number of awesome friendly people for again
sponsoring the important refreshments for the weekend. It's
hungry/thirsty work celebrating like this!
DebConf24 was held in Busan, South Korea, from July 28th to August 4th 2024 and preceded by DebCamp from July 21st to July 27th. This was my second IRL DebConf (DC) and fourth one in total. I started in Debian with a DebConf, so its always an occassion when one happens.
This year again, I worked in fundraising team, working to raise funds from International sponsors. We did manage to raise good enough funding, albeit less than budgeted. Though, the local Korean team was able to connect and gather many Governmental sponsors, which was quite surprising for me.
I wasn’t seriously considering attending DebConf until I discussed this with Nilesh. More or less his efforts helped push me through the whole process. Thanks Nilesh for this. In March, I got my passport and started preparing documents for South Korean visa. It did require quite a lot of paper work but seeing South Koreas’s fresh passport visa rejection rate, I had doubts about visa acceptance. The visa finally got approved, which could be attributed to great documentation and help from DebConf visa team. This was also my first trip outside India, and this being to DebConf made many thing easy. Most stuff were documentated on DebConf website and wiki. Asking some query got immediate responses from someone in the DebConf channels.
We then booked a direct flight from Delhi, reaching Seoul in the morning. With good directions from Sourab TK who had reached Seoul a few hours earlier, we quickly got Korean Won, local SIM and T Money card (transportation card) and headed towards Seoul by AREX, airport metro. We spent the next two days exploring Seoul, which is huge. It probably has the highest number of skyscrappers I have ever seen. The city has good mix modern and ancient culture. We explored various plaes in Seoul including Gyeongbokgung Palace, Statue of King Sejong, Bukchon Hanok village, N Seoul Tower and various food markets which were amazing.
A Street in Seoul
Next, we to headed to Busan for DebConf using KTX (Korean high speed rail). (Fun fact, slogan for City of Busan is “Busan is Good”.) South Korea has good network of frequently running high speed trains. We had pre-booked our tickets because despite the frequency, trains were sold out most of the times. KTX ride was quite smooth, despite travelling at 300 Kmph at times through Korean countryside and long mountain tunnels.
PKNU Entrance
The venue was for DebConf was Pukyong National University (PKNU), Daeyeon Campus. PKNU had two campuses in the Busan and some folks ended up in wrong campus too. With good help and guidance from front desk, we got our dormitery rooms assigned. Dorms here were quite different ie:
Rooms had heated floors. It seems to snow in Busan.
Each area was had card based access. There was a seperate card for laundry too.
Rooms had announcement systems right inside the room, though we couldn’t decipher any announcement as all of them were in Korean.
Each room was provided with a dedicated access point and own SSID inside the room.
View from Dorm Room
Settling in was easy and we started meeting familiar folks after almost an year. The long conversations started again. Everyone was excited for DebConf.
Like everytime, first day was full of action (and chaos). Meet and greet, voluneteers checkin, video team running around and fixing stuff and things working (or not). There were some interesting talks and sponsors stalls . After day one, things more or less settled down. I again volunteered for video team stuff and helped in camera operations and talk directions which is always fun. As the tradition applies, saw few talks live on stream too sitting in the dorm room during the conf, which is always fun, when too tired to get ready and go out.
From Talk Director's chair
DebConf takes care of food needs for vegan/vegetration folks well, of which I’m one. I got to try different food items which was quite an experience. Tried using chopsticks again which didn’t work, which I later figured that handling metal ones were more difficult. We had late night ramens and wooden chopsticks worked perfectly. One of the days, we even went out to an Indian resturarent to have some desi aloo paratha, paneer dishes, samosas and chai (milk tea). I wasn’t particularyly craving desi food but wasn’t able to get something according to my taste so went there.
As usual Bits from DPL talk was packed
For daytrip, I went to Ulsan. San means mountains in Korean. Ulsan is a port city with many industries including Hyundai car factory, petrochemical industry, paint industry, ship building etc. We saw bamboo forest, Ulsan tower (quite a view towards Ulsan port), whale village, Ulsan Onggi Museum and the sea (which was beautiful).
The beautiful sea
View from Ulsan Bridge Observatory
Amongst the sponsors, I was most interested in our network sponsors folks who were National research and education networks (NREN) here. We had two network sponsors, KOREN and KREONET, thanks to efforts by local team. Initially it was discussed that they’ll provide 20G uplink each, so 40G in total, which was whopping but by the time the closing talk happened, we got to know we had 200G uplink to the Internet. This was massive update to last year where we had 1G main and 100M backup link. 200G wasn’t what is required but it was massive capacity and IIRC from the talk, we peaked at around 500M in usage but it’s always fun have astronomical amount of bandwidth for bragging rights ;)
Various mascots in attendence
Video and Network stats. Screengrab from closing ceremony
Now lets talk about things I found interesting about South Korea in general:
Convience stores were everywhere, one could see same brand stores less than kilometer apart. We had even had two of them (GS25(s)), a road cross away too. These places were well stocked with almost everything even alcohol.
There were wide footpaths and pedestrian friendly policies.
Public transport and intra modal transfer is convient and easy to figure. Each metro station connects to multiple nearby buildings through underground walkways and one never had to go out in the sun (in hot and humid weather). Also Seoul and Busan metro networks were massive. Same T money card worked for buses (almost hop on, tap and hop off at your destination), metros and even cabs.
South Korea pays special attention to maintaining their historical and cultural buildings. These venues had informational brochures in Korea, English, Japanese and Chinese.
We got constant stream of “Public safety alerts” on our phones. Some phones even read them aloud for heatwaves and rains warnings, all in Korean.
Trash was segrated at source everywhere.
Public, high speed WIFI was omni-present in malls, public transport, airport etc. In metro, each coach had access points from all three telecom providers (SK Telecom, KT and LG U+) which also had almost similar voice and data plans.
Police personals were quite helpful despite the language issue.
Not many folks here are comfortable in English but one can always make use of various mobile translation apps.
Cards are accepted everywhere and there’re too many of these cards ;)
Food situation was bit difficult for me as a vegetration. We always have vegan/veg food in DebConf but outside, this whole concept doesn’t seem to exist here.
I couldn’t find any public speedtest servers inside Korea. All my fast.com/speedtest.net servers were located either Hong Kong, Singapore, Japan and even in United States. On the very last day, I got a speedtest servers in Seoul, inside SK Telecom.
Grand Gyeongbokgung Palace, Seoul
Starfield Library, Seoul
If one has to get the whole DebConf experience, it’s better to attend DebCamp as well because that’s when you can sit and interact with everyone better. As DebConf starts, everyone gets busy in various talks and events and things take a pace. DebConf days literally fly. This year, attending DebConf in person was a different experience. Attending DebConf without any organisational work/stress so was better and I was able to understand working of different Debian team and workflows better while also identified a few where I would like to join and help. A general conclusion was that almost almost all Debian team needs more folks to help out. So if someone want to join, they can probably reach out to team and they would be able to onboard new folks. Though this would require some patience. Kudos to the Korean team who were able to pull of this event under this tight timeline and thanks for all the hospitality.
Thornhedge is a fantasy novella by T. Kingfisher, the pen name that
Ursula Vernon uses for her adult writing. It won the 2024 Hugo Award for
best novella. No matter how much my brain wants to misspell the title, it
is a story about a hedge, not a Neolithic earthwork.
The fairy was the greenish-tan color of mushroom stems and her skin
bruised blue-black, like mushroom flesh. She had a broad, frog-like
face and waterweed hair. She was neither beautiful nor made of malice,
as many of the Fair Folk are said to be.
There is a princess asleep in a tower, surrounded by a wall of thorns.
Toadling's job is to keep anyone from foolishly breaking in. At first, it
was a constant struggle and all that she could manage, but with time, the
flood of princes slowed to a trickle. A road was built and abandoned.
People fled. There was a plague. With any luck, the tower was finally
forgotten.
Then a knight shows up. Not a very rich knight, nor a very successful
knight. Just a polite and very persistent knight who wants to get into
the tower that Toadling does not want him to get into.
As you might have guessed, this is a Sleeping Beauty retelling. As you
may have also guessed from the author, or from the cover text that says
"not all curses should be broken," this version is a bit different. How
and why it departs from the original is a surprise that slowly unfolds
over the course of the story, in parallel to a delicate, cautious, and
delightfully kind-hearted conversation between the knight and the fairy.
If you have read a T. Kingfisher story before, particularly one of her
fractured fairy tales, you know what to expect. Toadling is one of her
typical well-meaning, earnest, slightly awkward protagonists who is just
trying to do the right thing in a confusing world full of problems and
dangers. She's constantly overwhelmed and yet she keeps going, because
what else is there to do. Like a lot of Kingfisher's writing, it's a
story about quiet courage from someone who doesn't consider herself
courageous. One of the twists this time is that the knight is a character
from a similar vein: doggedly unwilling to leave any problem alone, but
equally determined to try to be kind. The two of them together make for a
story with a gentle and rather melancholy tone.
We do, eventually, learn the whole backstory of the tower, the wall of
thorns, and Toadling. There is a god, a rather memorable one, who is
frustratingly cryptic in the way that gods are. There are monsters who
are more loving than most humans. There are humans who turn out to be
surprisingly decent when it matters. And, like most of Kingfisher's
writing, there is a constant awareness of how complicated the world is,
how full it is of people who are just trying to get through each day, and
how heavy of burdens people can shoulder when they don't see another way.
This story pulled me right in. It is not horror, although there are a few
odd bits like there always are in Kingfisher stories. Your largest risk
as a reader is that it might make you cry if stories about earnest people
doing their best in overwhelming situations hit you that way. My primary
complaint is that there was nowhere near enough ending for me. After
everything I learned about the characters, I wanted to spend some time
with them outside of the bounds of the story. Kingfisher points the
reader in a direction and then leaves the rest to your imagination, and I
can see why she chose that story construction, but I wanted more catharsis
than I got.
That complaint aside, this is quintessential T. Kingfisher, and I am
unsurprised that it won a Hugo. If you've read any of her other fractured
fairy tales, or the 2023 Hugo winner for best
novel, you know the sort of stories she tells, and you probably know
whether you will like this. I am one of the people who like this.
Warning: If you're not into meat, you might want to skip the
rest of this...
This year, I turned 50. Wow. Lots of friends and family turned up
to help me celebrate, with a BBQ (of course!). I was very grateful for
a lovely set of gifts from those awesome people, and I have a number
of driving experiences to book in the next year or so. I'm going to
have so much fun driving silly cars on and off road!
However, the most surprising gift was
something totally different - a full-day course of
hands-on pork butchery. I was utterly bemused - I've never
considered doing anything like this at all, and I'd certainly never
talked to friends about anything like it either. I was shocked, but in
a good way!
So, two weekends back Jo and I went over
to Empire
Farm in Somerset. We stayed nearby so we could be ready on-site
early on Sunday morning, and then we joined three other people doing
the course. Jo was there to observe, i.e. to watch and take (lots of!)
pictures.
I can genuinely say that this was the most fun surprise gift I've
ever received! David Coldman, the master butcher working with us, has
been in the industry for many years. He was an excellent teacher,
showing us everything we needed to know and being very patient with us
when we needed it. It was great to hear his philosophy too - he only
uses the very best locally-sourced meat and focuses on quality over
quantity. He showed us all the different cuts of pork that a butcher
will make, and we were encouraged to take everything home - no
waste here!
At the beginning of the day, we each started with half a pig. Over
the next several hours, we steadily worked our way through a series of
cuts with knife and saw, making the remaining pig smaller and smaller
as we went.
We finished the day with three sets of meat. First, a stack of
vacuum-packed joints, chops and steaks ready for cooking and eating at
home. Second: a box of off-cuts that we minced and made into sausages
at the end of the day. Finally: a bag of skin and bones. Our friend's
dog got some of the bones, and Jo turned a lot of the skin into
crackling that we shared with friends at the OMGWTFBBQ the next
weekend.
This was an amazing day. Massive thanks to my good friend Chris
Walker for suggesting this gift. As I told David on the day: this was
the most fun surprise gift I've ever received. Good hands-on teaching
in a new craft is an incredible thing to experience, and I can't
recommend this course highly enough.
Around a decade ago, I was happy to learn about bcache – a Linux block cache system that implements tiered storage (like a pool of hard disks with SSDs for cache) on Linux. At that stage, ZFS on Linux was nowhere close to where it is today, so any progress on gaining more ZFS features in general Linux systems was very welcome. These days we care a bit less about tiered storage, since any cost benefit in using anything else than nvme tends to quickly evaporate compared to time you eventually lose on it.
In 2015, it was announced that bcache would grow into its own filesystem. This was particularly exciting and it caused quite a buzz in the Linux community, because it brought along with it more features that compare with ZFS (and also btrfs), including built-in compression, built-in encryption, check-summing and RAID implementations.
Unlike ZFS, it didn’t have a dkms module, so if you wanted to test bcachefs back then, you’d have to pull the entire upstream bcachefs kernel source tree and compile it. Not ideal, but for a promise of a new, shiny, full-featured filesystem, it was worth it.
In 2019, it seemed that the time has come for bcachefs to be merged into Linux, so I thought that it’s about time we have the userspace tools (bcachefs-tools) packaged in Debian. Even if the Debian kernel wouldn’t have it yet by the time the bullseye (Debian 11) release happened, it might still have been useful for a future backported kernel or users who roll their own.
By total coincidence, the first git snapshot that I got into Debian (version 0.1+git20190829.aa2a42b) was committed exactly 5 years ago today.
It was quite easy to package it, since it was written in C and shipped with a makefile that just worked, and it made it past NEW into unstable in 19 January 2020, just as I was about to head off to FOSDEM as the pandemic started, but that’s of course a whole other story.
Fast-forwarding towards the end of 2023, version 1.2 shipped with some utilities written in Rust, this caused a little delay, since I wasn’t at all familiar with Rust packaging yet, so I shipped an update that didn’t yet include those utilities, and saw this as an opportunity to learn more about how the Rust eco-system worked and Rust in Debian.
So, back in April the Rust dependencies for bcachefs-tools in Debian didn’t at all match the build requirements. I got some help from the Rust team who says that the common practice is to relax the dependencies of Rust software so that it builds in Debian. So errno, which needed the exact version 0.2, was relaxed so that it could build with version 0.4 in Debian, udev 0.7 was relaxed for 0.8 in Debian, memoffset from 0.8.5 to 0.6.5, paste from 1.0.11 to 1.08 and bindgen from 0.69.9 to 0.66.
I found this a bit disturbing, but it seems that some Rust people have lots of confidence that if something builds, it will run fine. And at least it did build, and the resulting binaries did work, although I’m personally still not very comfortable or confident about this approach (perhaps that might change as I learn more about Rust).
With that in mind, at this point you may wonder how any distribution could sanely package this. The problem is that they can’t. Fedora and other distributions with stable releases take a similar approach to what we’ve done in Debian, while distributions with much more relaxed policies (like Arch) include all the dependencies as they are vendored upstream.
As it stands now, bcachefs-tools is impossible to maintain in Debian stable. While my primary concerns when packaging, are for Debian unstable and the next stable release, I also keep in mind people who have to support these packages long after I stopped caring about them (like Freexian who does LTS support for Debian or Canonical who has long-term Ubuntu support, and probably other organisations that I’ve never even heard of yet). And of course, if bcachfs-tools don’t have any usable stable releases, it doesn’t have any LTS releases either, so anyone who needs to support bcachefs-tools long-term has to carry the support burden on their own, and if they bundle it’s dependencies, then those as well.
I’ll admit that I don’t have any solution for fixing this. I suppose if I were upstream I might look into the possibility of at least supporting a larger range of recent dependencies (usually easy enough if you don’t hop onto the newest features right away) so that distributions with stable releases only need to concern themselves with providing some minimum recent versions, but even if that could work, the upstream author is 100% against any solution other than vendoring all its dependencies with the utility and insisting that it must only be built using these bundled dependencies. I’ve made 6 uploads for this package so far this year, but still I constantly get complaints that it’s out of date and that it’s ancient. If a piece of software is considered so old that it’s useless by the time it’s been published for two or three months, then there’s no way it can survive even a usual stable release cycle, nevermind any kind of long-term support.
With this in mind (not even considering some hostile emails that I recently received from the upstream developer or his public rants on lkml and reddit), I decided to remove bcachefs-tools from Debian completely. Although after discussing this with another DD, I was convinced to orphan it instead, which I have now done. I made an upload to experimental so that it’s still available if someone wants to work on it (without having to go through NEW again), it’s been removed from unstable so that it doesn’t migrate to testing, and the ancient (especially by bcachefs-tools standards) versions that are in stable and oldstable will be removed too, since they are very likely to cause damage with any recent kernel versions that support bcachefs.
And so, my adventure with bcachefs-tools comes to an end. I’d advise that if you consider using bcachefs for any kind of production use in the near future, you first consider how supportable it is long-term, and whether there’s really anyone at all that is succeeding in providing stable support for it.
A few weeks ago Tiziano Bacocco started a small
project to implement a (golang) proxy that allows to store proxmox backups on
S3 compatible storage:
pmoxs3backuproxy, a feature which
the current backup server does not have.
I wanted to have a look at the Proxmox Backup Server implementation for a
while, so i jumped on the wagon and helped with adding most of the API
endpoints required to
seamlessly use it as drop-in replacement in PVE.
The current version can be configured as storage backend in PVE. You can then
schedule your backups to the S3 storage likewise.
It now supports both the Fixed index
format
required to create virtual machine backups and the Dynamic index format,
used by the regular proxmox-backup-client for file and container backups. (full
and incremental)
The other endpoints like adding notes, removing or protecting backups, mounting
images using the PVE frontend (or proxmox-backup-client) work too. It comes
with a garbage collector that does prune the backup storage if snapshots expire
and runs integrity checks on the data.
You can also configure it as so called “remote” storage in the Proxmox Backup
server itself and pull back complete buckets using “proxmox-backup-manager
pull”, if your local datastore crashes.
I think it will become more interesting if future proxmox versions will
allow to push backups to other
stores, too.
Dark Horse is a science fiction romance novel, the first of a five
book series as of this writing. It is self-published, although it is
sufficiently well-edited and packaged that I had to do some searching to
confirm that.
Rose was abducted by aliens. The Tecrans picked her up along with a
selection of Earth animals, kept her in a cell in their starship, and
experimented on her. As the book opens, she has managed to make her
escape with the aid of an AI named Sazo who was also imprisoned on the
Tecran ship. Sazo dealt with the Tecrans, dropped the ship in the middle
of Grih territory, and then got Rose and most of the animals on shuttles
to a nearby planet.
Dav Jallan is the commander of the ship the Grih sent to investigate the
unexplained appearance of a Class 5 Tecran warship in the middle of their
territory. The Grih and the Tecran, along with three other species, are
members of the United Council, which means in theory they're all at peace.
With the Tecran, that theory is often strained. Dav is not going to turn
down one of their highly-advanced Class 5 warships delivered to him on a
silver platter. There is only the matter of the unexpected cargo, the
first orange dots (indicating unknown life forms) that most of the Grih
have ever seen.
There is a romance. That romance did not work for me. I thought it was
highly unprofessional on Dav's part and a bit too obviously constructed on
the author's part. It also leans on the subgenre convention that aliens
can be remarkably physically similar and sexually compatible, which always
causes problems for my suspension of disbelief even though I know it's no
less plausible than faster-than-light travel.
Despite that, I had so much fun with this book! It was absolutely
delightful and weirdly grabby in a way that caught me by surprise. I was
skimming some parts of it to write this review and found myself re-reading
multiple pages before I dragged myself back on task.
I think the most charming part of this book is that the United Council has
a law called the Sentient Beings Agreement that makes what the Tecran were
doing extremely illegal, and the Grih and the other non-Tecran aliens take
this very seriously and with a refreshing lack of cynicism. Rose has a
typical human reaction to ending up in a place where she doesn't know the
rules and isn't entirely an expected guest. She almost reflexively
smoothes over miscommunications and tensions, trying to adapt to their
expectations. And then, repeatedly, the Grih realize how much work she's
doing to adapt to them, feel enraged at the Tecran and upset that they
didn't understand or properly explain something, and find some way to make
Rose feel more comfortable. It's surprisingly soothing and comforting to
read.
It occurred to me in several places that Dark Horse could be read
as a wish-fulfillment fantasy of what life as a woman could be like if men
took their fair share of the
mental
load. (This concept is usually applied to housework, but I think it
generalizes to other social and communication contexts.) I suspect this
was not an accident.
There is a lot of wish fulfillment in this book. The Grih are very
human-like but hunky, which is convenient for the romance subplot. They
struggle to sing, value music exceptionally highly, and consider Rose's
speaking voice beautifully musical. Her typical human habit of singing to
herself is a source of immediate and almost overwhelming fascination. The
supplies Rose takes from the Tecran ship when she flees just happen to be
absurdly expensive scented shampoo and equally expensive luxury adaptable
clothing. The world she lands on, and the Grih ship, are low-gravity
compared to Earth, so Rose is unusually strong for her size. Grih
military camouflage has no effect on her human vision. The book is set up
to make Rose special.
If that type of wish fulfillment is going to grate, wait on this book
until you're more in the mood for it. But I like wish fulfillment
books when they're done well. Part of why I like to read is to imagine a
better world. And Rose isn't doted on; despite their hospitality, she's
constantly underestimated by the Grih. Even with their deep belief in the
Sentient Beings Agreement, the they find it hard to believe that an
unknown sentient, even an advanced sentient, is really their equal. Their
concern at the start is somewhat patronizing, so watching Rose constantly
surprise them delighted the part of my brain that likes both competence
porn and deserved reversals, even though the competence here is often due
to accidents of biology. It helps that Diener tells the story in
alternating perspectives, so the reader first watches Rose do something
practical and straightforward from her perspective and then gets to enjoy
the profound surprise and chagrin of the aliens.
There is a plot beneath this first contact story, and beyond the political
problem of figuring out what to do with Rose and the Tecran. Sazo, Rose's
AI friend, does not want the Grih to know he exists. He has a history
that Rose does not know about and may not be entirely safe. As the
political situation with the Tecran escalates, Sazo is pursuing goals of
his own, and Rose has a firm opinion about where her loyalties should lie.
The resolution is nothing ground-breaking as far as SF goes, but I thought
it was satisfyingly tense and complex. Dark Horse leaves obvious
room for a sequel, but it comes to a satisfying conclusion.
The writing is serviceable, particularly once you get into the story. I
would not call it great, and it's not going to win any literary awards,
but it didn't interfere with my enjoyment of the story.
This is not the sort of book that will make anyone's award list, but it is
easily in the top five of books I had the most fun reading this year.
Maybe save it for when you're looking for something light and wholesome
and don't mind some rather obvious tropes, but if you're in the mood for
imagining people who take laws seriously and sincerely try to help other
people, I found this an utterly delightful way to pass the time. I
immediately bought the sequel. Recommended.
At this years Debian conference in South Korea I've presented1 the
new feature of the FAIme web service. You can now build your own
Debian live media/ISO.
The web interface provides various settings, for e.g. adding a user
name and its password, selecting the Debian release (stable or
testing), the desktop environment and the language. Additionally you
can add your own list of packages, that will be installed into the
live environment. It's possible to define a custom script that gets
executed during the boot process. For remote access to the live
system, you can easily sepcify a github, gitlab or salsa account,
whose public ssh key will be used for passwordless root access. If your
hardware needs special grub settings, you may also add those.
I'm thinking about adding an autologin checkbox, so the live media
could be used for a kiosk system.
And finally newer hardware is supported with the help of
the backports kernel for the Debian stable release (aka bookworm).
This combination is not available from the official Debian live images or
the netinst media because the later has some complicated dependencies
which are not that easy to resolve2. At DebConf24 I've talked
to Alper who has some ideas3 how to improve the Debian installer
environment which then may support a backports kernel.
GNOME is one of the most widely used free and open-source desktop environments!
Your native language is Marathi and you are using GNOME as your
desktop environment? Then me as the coordinator for the Marathi translation
team in GNOME is excited to invite you to become part of the team who is
working on translating the GNOME Desktop into Marathi!
By this and contributing to the translation of GNOME into Marathi you would
be a member of an important project and you can help to make it more
accessible to Marathi speakers worldwide and help also to keep our language
alive in the open source world.
Why Should You Contribute?
Promote Your Language
By translating GNOME into Marathi, you help
to preserve and promote our beautiful language in the digital world.
Learn and Grow
Contributing to open-source projects like GNOME is a
great way to improve your language and technical skills, network with
like-minded individuals, and gain recognition in the global open-source
community.
Give Back to the Community
This is an opportunity to contribute to a project that has a significant
impact on users around the world. Your work will enable Marathi speakers
to use technology in their native language.
Who Can Contribute?
You don’t need to be a professional translator to join us! If you are fluent in
Marathi and have a basic understanding of English, your contributions will be
invaluable. Whether you’re a student, a professional, or just someone
passionate about your language, your help is needed and really appreciated!
How To Start Translating?
Once you’re familiar with the tools, you can easily begin translating. We
have a list of untranslated strings waiting for your contribution!
How To Join The Team?
Follow these steps to join the Marathi translation team for GNOME and start
contributing:
Step 2: If you’re a new user, click on the “Create Account” option to sign up.
Step 3: Once you’ve created your account, log in with your credentials.
Step 4: After logging in, click the “Join” button to become a translator for the Marathi team.
Step 5: You’ll now see a list of different modules that need translation. Choose one of the files that interests you and download it to your computer.
Step 6: Translate the content locally on your computer. Once you’re done, return to the website, click “Browse,” and submit your translated file.
Get Familiar with the Additional Tools
Varnam
If you’re not used to typing in Marathi, you can still contribute using the
Varnam website, a free and open-source tool that converts English text into
Marathi. Here’s how you can get started:
Step 2: Click on the “Try Now” button on the website.
Step 3: In the language selection menu, choose “Marathi” as
your desired language.
Step 4: Now you can start typing in English, and Varnam will
automatically convert your text into Marathi. If you need more guidance,
there’s a help window available on the site that you can explore for
additional support.
Need Help Or You Have Questions?
If you have any doubts or need further assistance how you get started with
translating GNOME into Marathi, don’t hesitate to reach out. I’m here to help
you on every step of the way!
You can connect with me directly at
[email protected] Whether you need
technical support, guidance on using the tools, or just want to discuss the
project, feel free to get in touch.
Let’s work together to make GNOME accessible to Marathi speakers around the
world. Your contributions are always invaluable, and I look forward to
welcoming you to our team!
It's clear that Twitter has been circling the drain for years, but
things have been especially bad in recent times. I haven't quit (I
have some sympathy with the viewpoint don't cede territory to
fascists) but I try to read it much less, and I certainly post
much less.
Especially at the moment, I really appreciate distractions.
Last time I wrote about Mastodon (by which
I meant the Fediverse1), I was looking for a new instance to
try. I settled on Debian's social
instance2. I'm now trying to put
any energy I might spend engaging on Twitter, into engaging in the Fediverse
instead. (You can follow me via the handle @[email protected], I think, which
should repoint to my actual handle, @[email protected].)
There are other potential successors to Twitter: two big ones are Bluesky and
Facebook-owned Threads. They are effectively cookie-cutter copies of the
Twitter model, and so, we will repeat the same mistakes there. Sadly I see the
majority of communities and sub-cultures I follow are migrating to one or the
other of these.
The Fedi experience is, sadly, pretty clunky. So I want to try and write a bit
from time to time with tips and tricks that might improve people's experiences.
First up, something I discovered only today about Mastodon instances. As JWZ
noted, If you are worried about picking the "right" Mastodon instance,
don't. Just spin the wheel.. You can spend too much time trying to guess
a good answer to this. Better to just get started.
At the same time, individual instances are supposed to cater to specific
niches. So it could be useful to sample the public posts from an entire
instance. For example, to find people to follow, or decide to hop over to that
instance yourself. You can't (I think) follow an entire instance from within
yours, but, they usually have a public page which shows you the latest
traffic.
These pages don't provide RSS or Atom feeds3, sadly. I hope that's
on the software's roadmap, and hasn't been spurned for ideological reasons.
For now at least, OpenRSS provide RSS/Atom feeds for
many Mastodon instances. For example, an RSS/Atom feed of the above:
https://openrss.org/infosec.exchange/public/local
One can add these feeds to your Feed reader and over time get a flavour for
the kind of discourse that takes place on given instances.
I think the OpenRSS have to manually add Mastodon instances to their service.
I tried three instances and only one (infosec.exchange) worked. I'm not sure
but I think trying an instance that doesn't work automatically puts it on
OpenRSS's backlog.
the Fediverse-versus-Mastodon nomenclature problem is just the
the tip of the iceberg, in terms of adoption problems. Mastodon provides a
twitter-like service that participates in the Fediverse. But it isn't correct
to call the twitter-like service "Mastodon" because other softwares also
participate in/provide that service. And it's not correct to call it "Fediverse"
because that describes a bigger thing, with e.g. youtube clones also taking
part. I'm not sure what the right term should be for "the twitter-like thing".
Also, everything I wrote here is probably subtly wrong.↩
Debian's instance actually runs Pleroma, an alternative to
Mastodon. Why should it matter? I think it's healthy for there to be more
than one implementation in an open ecosystem. However the experience can be
janky, as the features don't perfectly align, some Mastodon features/APIs are
not documented/standardised/etc.↩
I have to remind myself that the concept of RSS/Atom feeds and Feedreaders
might need explaining to a modern audience too. Perhaps in another blog post.↩
A new maintenance release of RcppEigen is now
on CRAN, and will go to Debian shortly as usual. Eigen is a C++ template library
for linear algebra: matrices, vectors, numerical solvers, and related
algorithms. RcppEigen is
used by 460 other CRAN
packages, and has been downloaded 31.9 million times just off the
mirrors of CRAN keeping logs
for counting.
The recent change switing to Authors@R (now that CRAN mandates it) contained in
dual typo in ORCID tags, this releases fixes it.
The complete NEWS file entry follows.
Changes in
RcppEigen version 0.3.4.0.2 (2024-08-23)
I am looking into getting a Wifi mesh network. The aim is to use it for providing access to devices through my home especially for devices on the congested 2.4GHz frequency. Ideally I want 6GHz Wifi6E for the communication between mesh nodes as well as for talking to the few devices that are new enough to support it (I like buying cheap second hand devices). 2.5Gbit ethernet connections on all mesh nodes would be good too.
Wifi 7 is semi-released, you can buy devices even though the specs aren’t entirely finalised. I expect that next year when Wifi 7 devices are more common the second hand prices of Wifi 6E will drop. Currently Wifi 6E devices are somewhat expensive.
One major problem at the moment is “cloud configuration”. Here is a 41 page forum thread of TP-Link customers asking in vain for non-cloud configuration [1]. The problems with cloud configuration are that it doesn’t allow configuration without Internet access (so no fixing things when internet breaks and no use for a private network without Internet), it relies on a proprietary phone app (so a problem with your phone breaks everything), and it adds a dependency on an unpaid service that TP-Link might decide to turn off at some future time. The TP -Link Deco X55 AX3000 looks like a good set of devices, it currently costs $328 for a set of three Wifi 6 (not 6E) devices is a good deal, pity that the poor software options let it down.
There is the OpenWrt project for open firmware on Wifi APs which is a great project [3] but it doesn’t seem to support any Wifi 6 mesh systems yet. If most Wifi hardware requires malware for operation it seems that running a VPN over Wifi is the way to go. A hostile party being able to sniff your home network is much worse than a hostile party sniffing public Internet traffic.
The Google Nest mesh devices have good specs and price, $359 for a three node Wifi 6E mesh that has 2.5Gbit ethernet. But they can only be configured with a Google app for Android or iOS and require a Gmail account. Giving Google the ability to shut down all my stuff by deleting my gmail account is not acceptable. Also Google is well known for cancelling services [4]. A mitigating factor is that there should be enough of those devices sold to make them a good target for an OpenWRT port.
Kogan is selling an own-brand Wifi 6 mesh network package that comes with 1/2/3 devices for $70/$120/$140. It doesn’t do Wifi 6E but supports the better encoding methods of Wifi 6 over Wifi 5 and will be good for bridging a LAN in one part of a house to a Wifi 2.4GHz or Ethernet connected device in another part. They also support up to 7 nodes so you could buy two of the 3 device packages and run one network with 2 and another with 4. The pricing is very competitive and they support web based administration!
I’ve just ordered the $140 Wifi 6 pack from Kogan. If it doesn’t do what I want then I can find someone else who will be happy with whatever functionality it gives and $140 is an amount I can risk without concern. If it works well then I might upgrade to Wifi 6E or Wifi 7 next year and deploy the Wifi 6 one for a relative. It seems that for my needs a cheap and OK Wifi 6 device is better than an expensive Wifi 6E device.
Regarding the specific news article, this is always a risk with distributed public key encryption systems. Lose control of one private key and attackers can do bad things. That doesn’t make it bad it just makes it less valuable. If you want to setup a system for a government agency, bank, or other high value target then it’s quite reasonable to expect an adversary to purchase systems of the same make and model to verify that their attacks will work. If you want to make your home PC a little harder to attack then you can expect that the likely adversaries won’t bother with such things. You don’t need security to be perfect, making a particular attack slightly more difficult than other potential attacks gives a large part of the benefit.
The purpose of Secure Boot is to verify the boot loader with a public key signature and then have the boot loader verify the kernel. Microsoft signs the “shim” that is used by each Linux distribution to load GRUB (or another boot loader). So when I configure a Debian system with Secure Boot enabled that doesn’t stop anyone from booting Ubuntu. From the signatures on the boot loader etc there is no difference from my Debian installation and a rescue image from Debian, Ubuntu, or another distribution booted by a hostile party to do things against my interests. The difference between the legitimate OS image and malware is a matter of who boots it and the reason for booting it.
It is possible to deconfigure Microsoft keys from UEFI to only boot from your own key, this document describes what is necessary to do that [2]. Basically if you boot without using any “option ROMs” (which among other things means the ROM from your video card) then you can disable the MS keys.
If it’s impossible to disable the MS keys that doesn’t make it impossible to gain a benefit from the Secure Boot process. You can use a block device decryption process that involves a signature of the kernel and the BIOS being used as part of the decryption for the device. So if a system is booted with the wrong kernel and the user doesn’t recognise it then they will find that they can’t unlock the device with the password. I think it’s possible on some systems to run the Secure Boot functionality in a non-enforcing mode such that it will use a bootloader without a valid signature but still use the hash for TPM calculations, that appears impossible on my Thinkpad Yoga Gen3 which only has enabled and disabled as options but should work on Dell laptops which have an option to run Secure Boot in permissive mode.
I believe that the way of the future is to use something like EFIStub [3] to create unified kernel images with a signed kernel, initrd, and command-line parameters in a single bundle which can be loaded directly by the UEFI BIOS. From the perspective of a distribution developer it’s good to have many people using the current standard functionality of shim and GRUB for EFI as a step towards that goal.
CloudFlare has a good blog post about Linux kernel hardening [4]. In that post they cover the benefits of a full secure boot setup (which is difficult at the current time) and the way that secure boot enables the lockdown module for kernel integrity. When Secure Boot is detected by the kernel it automatically enables lockdown=integrity functionality (see this blog post for an explanation of lockdown [5]). It is possible to enable this by putting “lockdown=integrity” on the kernel command line or “lockdown=confidentiality” if you want even more protection, but it happens by default with Secure Boot. Secure Boot is something you can set to get a selection of security features enabled and get a known minimum level of integrity even if the signatures aren’t used for anything useful, restricting a system to only boot kernels from MS, Debian, Ubuntu, Red Hat, etc is not useful.
For most users I think that Secure Boot is a small increase in security but testing it on a large number of systems allows increasing the overall security of operating systems which benefits the world. Also I think that having features like EFIStub usable for a large portion of the users (possibly the majority of users) is something that can be expected to happen in the lifetime of hardware being purchased now. So ensuring that Secure Boot works with GRUB now will facilitate using EFIStub etc in future years.
During Debconf, Edward Betts and myself started packaging Home Assistant for Debian. It consists of hundreds of Python packages. So far, we counted at least 675 packages. That’s a lot, though most packages are just libraries to talk with some IoT devices and some APIs. It’s fairly easy to create a new package: it takes me about 15 to 20 minutes, probably half that time to Edward. And it’s a lot of fun. So far in one month of time, we managed to package about 1 third of the list (probably 200+ Python packages already). Once we’ve done all the dependencies, we may start to have fun with the core of the application! At the current speed, hopefully we’ll be done before the end of the year. Edward and myself have swear to make at least one package a day, which I’ve been doing so far, and Edward did a way more… We also received contributions from Silton0506, Tianyu, piotr, EiPi Fun, sourabhtk37, and Count-Dracula, as per the very bottom of the TODO list in the wiki (see link below).
If you have a bit of free time, we’d love to have more contributors. Here’s were to get the needed information:
Feel free to join us on IRC: #debian-homeassistant
Discussing with a lot of people about it, I realized that A LOT of DDs are actually using Home Assistant. Wouldn’t you like it better if it was just a “apt install” away ? Any DD can simply take a package in the wiki, open an ITP, upload it’s debianized source on Salsa, and upload to the Debian archive. Most are very easy simple packages to make.
Diego wrote about his dislike for Advent of Code and that reminded me I hadn’t written up my experience from 2023. Mostly because, spoiler, I never actually completed it and always intended to do so and then write it up. I think it’s time to accept I’m not going to do that, and write down some thoughts before I forget all of them. These are somewhat vague, given the time that’s elapsed, but I think still relevant. You might also find Roger’s problem write up interesting.
I’ve tried AoC a couple of times before; I think I had a very brief attempt back in 2021, and I got 4 days in for 2022. For Advent of Code 2023 I tried much harder to actually complete the challenges, and got most of the way there. I didn’t allow myself to move on to the next day until fully completing the previous day, and didn’t end up doing the second half of December 24th, or any of December 25th.
Rust
First I want to talk about Rust, which is the language I chose to use for the problems. I’ve dabbled a little in it, but I’d like more familiarity with the basic language, and some programming problems seemed like a good way to get that. It’s a language I want to like; I’ve spent a lot of my career writing C, do more in Go these days, and generally think Rust promises a low level, run-time light environment like C but with the rough edges taken off.
I set myself the challenge of using just bare Rust; no external crates, no use of cargo. I was accused of playing on hard mode by doing this, but it really wasn’t the intention - I figured that I should be able to do what I needed without recourse to anything outside the core language, and didn’t want what seemed like the extra complexity of dealing with cargo.
That caused problems, however. I’m used to by-default generic error handling in Go through the error type, but Rust seems to have much more tightly typed errors. I was pointed at anyhow as the right way to do this in Rust. I still find this surprising; I ended up using unwrap() a lot when I think with more generic error handling I could have used ?.
The other thing I discovered is that by default rustc is heavy on the debug output. I got significantly better results on some of the solutions with rustc -O -C target-cpu=native source.rs. I probably shouldn’t be surprised by this, but worth noting.
Rust, to me, has a syntax only a C++ programmer could love. I am not a C++ programmer. Coming from C I found Go to be a nice, simple syntax to learn. Rust has not been the same. There’s a lot more punctuation, and it’s not always clear to me what it’s doing. This applies more when reading other people’s code than when writing it myself, obviously, but I see a lot of Rust code that could give Perl a run for its money in terms of looking like line noise.
The borrow checker didn’t bug me too much, but did add overhead to my thinking. The Rust compiler is generally very good at outputting helpful error messages when the programmer is an idiot. I ended up having to use a RefCell for one solution, and using .iter() for loops rather than explicit iterators (why, why is this different?). I also kept forgetting to explicitly mark variables as mutable when declaring them.
Things I liked? There’s a rich set of first class data types. Look, I’m a C programmer, I’m easily pleased. You give me some sort of hash array and I’ll be happy. Rust manages that, tuples, strings, all the standard bits any modern language can provide. The whole impl thing for adding methods to structures I like as a way of providing some abstraction, though I think Go has a nicer syntax for it. The compiler, as mentioned, is great at spitting out useful errors for the most part. Also although I wasn’t using external crates for AoC I do appreciate there’s a decent ecosystem there now (though that brings up another gripe: rust seems to still be a fairly fast moving target, to the extent I can no longer rely on the compiler in Debian stable to be able to compile random projects I find).
Advent of Code
Let’s talk about the advent of code bit now. Hopefully it’s long enough since it came out that this won’t be spoilers for anyone, but if you haven’t attempted the 2023 AoC and might, you might want to stop reading here.
First, a refresher on the format for those who might not be aware of it. Problems are posted daily from December 1st until the 25th. Each is in 2 parts; the second part is not viewable until you have provided the correct answer for the first part. There’s a whole leaderboard thing going on, but the puzzle opens at midnight UTC-5 so generally by the time I wake up and have time to look the problem has been solved many times over; no chance of getting listed.
Credit to AoC creator, Eric Wastl, for writing up the set of problems in an entertaining fashion. I quite enjoyed seeing how the puzzle would be phrased each day, and the whole thing obviously brings a lot of joy to folk I know.
I always start AoC thinking it’ll be a fun set of puzzles to solve. Then something happens and I miss a day or two, and all of a sudden I’ve a bunch of catching up to do and it’s all a bit more of a chore. I hit that at some points this time, but made a concerted effort to try and power through it.
That perseverance was required up front, because I found the second part of Day 1 to be ill specified, and had to iterate a few times to actually calculate the desired solution (IIRC, issues about whether sevenone at the end of a line ended up as 7 or 1 really tripped me up). I don’t recall any other problems that bit me as hard on the specification as this one, but it happening up front was unfortunate.
The short example input doesn’t always help with this either; either it’s not enough to be able to extrapolate patterns, or it doesn’t show all the variations you need to account for (that aren’t fully specified in the text), or in a few cases it turned out I needed to understand the shape of the actual data to produce a solution that could actually complete in a reasonable time.
Which brings me to another matter, sometimes brute force doesn’t actually work. This is fine, but the second part of the day’s problem can change the approach you’d take. So sometimes I got lucky in the way I handled the first half, and doing the second half was a simple 5 minute tweak, and sometimes I had to entirely change the way I was storing data.
You might claim that if I was a better programmer I’d have always produced a first half solution that was amenable to extension for the second half. First, I dispute that; I think there are always situations where the problem domain can change in enough directions that you can’t handle all of them without a lot of effort. Secondly, I didn’t find AoC an environment that encouraged me to optimise for generic solutions. Maybe some of the puzzles in isolation would allow for that, but a month of daily problems to solve while still engaging in regular life meant I hacked things up, took short cuts based on the knowledge I had of the input data, etc, etc.
Overall I can see the appeal, but the sheer quantity and the fact I write code as part of my day job just made it feel too much like a chore, rather than a fun mental exercise. I did wonder how they’d look as a set of interview puzzles (obviously a subset, rather than all of them), but I’m not sure how you’d actually use them for that - I wouldn’t want anyone to have to solve them in a live interview.
So, in case it’s not obvious, I’m not planning to engage in AoC again this yet. But I’m continuing to persevere with Rust (though most of my work stuff is thankfully still Go).
O Debian Day é um evento anual que celebra o aniversário do Debian, uma das
distribuições GNU/Linux mais importante do Software Livre, criada em 16 de
Agosto de 1993, por Ian Murdock.
No último sábado (17/08/2024) no Sebrae-RN comemoramos os 31 anos Debian em
Natal, no Rio Grande do Norte. A celebração, foi organizada pela
PotiLivre(Comunidade Potiguar de Software Livre), destacou os 31 anos de
história do Debian. O evento contou com algumas palestras e muitas discussões
sobre Software Livre. Tivemos 70 inscrições, 40 estiverem presentes.
O Debian Day em Natal foi uma ocasião para celebrar a trajetória do Debian e
reforçar a importância do Software Livre.
Palestrantes
Agradecemos imensamente a Isaque Barbosa Martins, Eduardo de Souza Paixão,
Fernando Guisso,que palestraram nessa edição! Obrigado por compartilhar tanto
conhecimento com a comunidade. Esperamos ver vocês novamente em futuros
encontros!
Um grande obrigado também a todos os participantes, nós fazemos isso por vocês!
Esperamos que tenham aprendido, se divertido e feito novas conexões entre a
comunidade
Essa edição do Debina Day Natal foi organizada por: Allythy, Clara Nobre,
Gabriel Damazio e Marcel Ribeiro.
Long version: When UEFI Secure Boot was specified, everyone involved was, well, a touch naive. The basic security model of Secure Boot is that all the code that ends up running in a kernel-level privileged environment should be validated before execution - the firmware verifies the bootloader, the bootloader verifies the kernel, the kernel verifies any additional runtime loaded kernel code, and now we have a trusted environment to impose any other security policy we want. Obviously people might screw up, but the spec included a way to revoke any signed components that turned out not to be trustworthy: simply add the hash of the untrustworthy code to a variable, and then refuse to load anything with that hash even if it's signed with a trusted key.
Unfortunately, as it turns out, scale. Every Linux distribution that works in the Secure Boot ecosystem generates their own bootloader binaries, and each of them has a different hash. If there's a vulnerability identified in the source code for said bootloader, there's a large number of different binaries that need to be revoked. And, well, the storage available to store the variable containing all these hashes is limited. There's simply not enough space to add a new set of hashes every time it turns out that grub (a bootloader initially written for a simpler time when there was no boot security and which has several separate image parsers and also a font parser and look you know where this is going) has another mechanism for a hostile actor to cause it to execute arbitrary code, so another solution was needed.
And that solution is SBAT. The general concept behind SBAT is pretty straightforward. Every important component in the boot chain declares a security generation that's incorporated into the signed binary. When a vulnerability is identified and fixed, that generation is incremented. An update can then be pushed that defines a minimum generation - boot components will look at the next item in the chain, compare its name and generation number to the ones stored in a firmware variable, and decide whether or not to execute it based on that. Instead of having to revoke a large number of individual hashes, it becomes possible to push one update that simply says "Any version of grub with a security generation below this number is considered untrustworthy".
So why is this suddenly relevant? SBAT was developed collaboratively between the Linux community and Microsoft, and Microsoft chose to push a Windows update that told systems not to trust versions of grub with a security generation below a certain level. This was because those versions of grub had genuine security vulnerabilities that would allow an attacker to compromise the Windows secure boot chain, and we've seen real world examples of malware wanting to do that (Black Lotus did so using a vulnerability in the Windows bootloader, but a vulnerability in grub would be just as viable for this). Viewed purely from a security perspective, this was a legitimate thing to want to do.
(An aside: the "Something has gone seriously wrong" message that's associated with people having a bad time as a result of this update? That's a message from shim, not any Microsoft code. Shim pays attention to SBAT updates in order to avoid violating the security assumptions made by other bootloaders on the system, so even though it was Microsoft that pushed the SBAT update, it's the Linux bootloader that refuses to run old versions of grub as a result. This is absolutely working as intended)
The problem we've ended up in is that several Linux distributions had not shipped versions of grub with a newer security generation, and so those versions of grub are assumed to be insecure (it's worth noting that grub is signed by individual distributions, not Microsoft, so there's no externally introduced lag here). Microsoft's stated intention was that Windows Update would only apply the SBAT update to systems that were Windows-only, and any dual-boot setups would instead be left vulnerable to attack until the installed distro updated its grub and shipped an SBAT update itself. Unfortunately, as is now obvious, that didn't work as intended and at least some dual-boot setups applied the update and that distribution's Shim refused to boot that distribution's grub.
What's the summary? Microsoft (understandably) didn't want it to be possible to attack Windows by using a vulnerable version of grub that could be tricked into executing arbitrary code and then introduce a bootkit into the Windows kernel during boot. Microsoft did this by pushing a Windows Update that updated the SBAT variable to indicate that known-vulnerable versions of grub shouldn't be allowed to boot on those systems. The distribution-provided Shim first-stage bootloader read this variable, read the SBAT section from the installed copy of grub, realised these conflicted, and refused to boot grub with the "Something has gone seriously wrong" message. This update was not supposed to apply to dual-boot systems, but did anyway. Basically:
1) Microsoft applied an update to systems where that update shouldn't have been applied 2) Some Linux distros failed to update their grub code and SBAT security generation when exploitable security vulnerabilities were identified in grub
The outcome is that some people can't boot their systems. I think there's plenty of blame here. Microsoft should have done more testing to ensure that dual-boot setups could be identified accurately. But also distributions shipping signed bootloaders should make sure that they're updating those and updating the security generation to match, because otherwise they're shipping a vector that can be used to attack other operating systems and that's kind of a violation of the social contract around all of this.
It's unfortunate that the victims here are largely end users faced with a system that suddenly refuses to boot the OS they want to boot. That should never happen. I don't think asking arbitrary end users whether they want secure boot updates is likely to result in good outcomes, and while I vaguely tend towards UEFI Secure Boot not being something that benefits most end users it's also a thing you really don't want to discover you want after the fact so I have sympathy for it being default on, so I do sympathise with Microsoft's choices here, other than the failed attempt to avoid the update on dual boot systems.
Anyway. I was extremely involved in the implementation of this for Linux back in 2012 and wrote the first prototype of Shim (which is now a massively better bootloader maintained by a wider set of people and that I haven't touched in years), so if you want to blame an individual please do feel free to blame me. This is something that shouldn't have happened, and unless you're either Microsoft or a Linux distribution it's not your fault. I'm sorry.
Things developed since my last post. Some lesions opened up on my ankle which was initially good news: the pain substantially reduced. But they didn’t heal fast enough and so medics decided on surgical debridement. That was last night. It seemed to be successful and I’m in recovery from surgery as I write. It’s hard to predict the near-future, a lot depends on how well and fast I heal.
I’ve got a negative-pressure dressing on it, which is incredible: a constantly maintained suction to aid in debridement and healing. Modern medicine feels like a sci fi novel.
These Burning Stars is a science fiction thriller with cyberpunk
vibes. It is Bethany Jacobs's first novel and the first of an expected
trilogy, and won the 2024 Philip K. Dick Award for the best SF paperback
original published in the US.
Generation starships brought humanity to the three star systems of the
Treble, where they've built a new and thriving culture of billions. The
Treble is ruled by the Kindom, a tripartite government structure built
around the worship of six gods and the aristocratic power of the First
Families. The Clerisy handle religion, the Secretaries run the
bureaucracy, and the Cloaksaan enforce the decisions of the other
branches.
The Nightfoots are one of the First Families. They control sevite, the
propellant required to move between the systems of the Treble now that the
moon Jeve and the sole source of natural jevite has been destroyed. Esek
Nightfoot is a cleric, theoretically following the rules of the Clerisy,
but she has made a career of training cloaksaan. She is is mercurial,
powerful, ruthless, ambitious, politically well-connected, and greatly
feared. She is also obsessed with a person named Six: an orphan she first
encountered at a training school who was too young to have a gender or a
name but who was already one of the best fighters in the school. In the
sort of manipulative challenge typical of Esek, she dangled the offer of a
place as a student and challenged the child to learn enough to do
something impressive. The subsequent twenty years of elusive taunts and
mysterious gifts from the impossible-to-locate Six have driven Esek wild.
Cleric Chono was beside Esek for much of that time. One of Six's
classmates and another of Esek's rescues, Chono is the rare student who
became a cleric rather than a cloaksaan. She is pious, cautious, and
careful, the opposite of Esek's mercurial rage, but it's impossible to
spend that much time around the woman and not be affected and manipulated
by her. As this story opens, Chono is summoned by the First Cleric to
join Esek on an assignment: recover a data coin that was stolen from a
pirate raid on the Nightfoot compound. He refuses to tell them what data
is on it, only saying that he believes it could be used to undermine
public trust in the Nightfoot family.
Jun is a hacker with considerably fewer connections to power or government
and no desire to meet any of these people. She and her partner Liis make
a dubiously legal living from smaller, quieter jobs. Buying a collection
of stolen data coins for an archivist consortium is riskier than she
prefers, but she's been tracking down rumors of this coin for months. The
deal is worth a lot of money, enough to make a huge difference for her
family.
This is the second book I've read recently with
strong cyberpunk vibes, although These Burning Stars mixes them
with political thriller. This is a messy world with complicated political
and religious systems, a lot of contentious history, and vast inequality.
The story is told in two interleaved time sequences: the present-day fight
over the data coin and the information that it contains, and a sequence of
flashbacks telling the history of Esek's relationship with Six and Chono.
Jun's story is the most cyberpunk and the one I found the most enjoyable
to read, but Chono is a good viewpoint character for Esek's vicious energy
and abusive charisma.
Six is not a viewpoint character. For most of the book, they're present
mostly in shadows, glimpses, and consequences, but they're the strongest
character of the book. Both Esek and Six are larger than life, creatures
of legend stuffed into mundane politics but too full of strong emotions,
both good and bad, to play by any of the rules. Esek has the power base
and access to the levers of government, but Six's quiet competence and
mercilessly targeted morality may make them the more dangerous of the
pair.
I found the twisty political thriller part of this book engrossing and
very difficult to put down, but it was also a bit too much drama for me in
places. Jacobs has some surprises in store, one of which I did not expect
at all, and they're set up beautifully and well-done within the story, but
Esek and Six become an emotional star that the other characters orbit
around and are in danger of getting pulled into. Chono is an accomplished
and powerful character in her own right, but she's also an abuse victim,
and while those parts are realistic, I didn't entirely enjoy reading them.
There is quiet competence here alongside the drama, but I think I wanted
the balance of emotion to tip a bit more towards the competence.
There is one thing that Jacobs does with the end of the book that greatly
impressed me. Unfortunately I can't even hint at it for fear of spoilers,
but the ending is unsettling in a way that I found surprising and
thought-provoking. I think what I can say is that this book respects the
intelligence and skill of secondary characters in a way that I think is
rare in a story with such overwhelming protagonists. I'm still thinking
about that, and it's going to pull me right into the sequel.
This is not going to be to everyone's taste. Esek is a viewpoint
character and she can be very nasty. There's a lot of violence and abuse,
including one rather graphic fight scene that I thought dragged on much
longer than it needed to. But it's a satisfying, complex story with a
true variety of characters and some real surprises. I'm glad I read it.
Followed by On Vicious Worlds, not yet published as I write this.
Content warnings: emotional and physical abuse, graphic violence,
off-screen rape and sexual abuse of minors.
Happy to announce a new package: RcppMagicEnum.
It arrived on CRAN yesterday
following the resumption of normal service following the CRAN summer break. RcppMagicEnum
brings the magicenum
library by Daniil Goncharov to R.
Modern C++ is powerful, but still lacks reflection. This may change
with C++26 but until then this library can help. A simple example, also
shown on the README is as follows (and can be called from R via
Rcpp::sourceCpp() if the RcppMagicEnum
package is installed):
// [[Rcpp::depends(RcppMagicEnum)]]#include <RcppMagicEnum>// define a simple enum class, it uses optional typing as well as optional assigned valuesenumclass Color :int{ RED =-10, BLUE =0, GREEN =10};// [[Rcpp::export]]void example(){// instantiate an enum value in variable 'val'auto val = Color::RED;// show the current value on stdout Rcpp::Rcout <<"Name of enum: "<< magic_enum::enum_name(val)<<std::endl; Rcpp::Rcout <<"Integer value of enum: "<< magic_enum::enum_integer(val)<<std::endl;}/*** Rexample()*/
It produces the following output (where the ‘meta-comment’ at the end
ensure the included and created-by-sourcing function
example() is also called):
> Rcpp::sourceCpp("miniex.cpp")>example()Name of enum: REDInteger value of enum:-10>
The plan to experiment some more with this and then see if we could
possible make factor variables map to such enums and vice versa. Help
and discussion input is always welcome, and could be submitted either on
the rcpp-devel
list or as an issue at the repo.
Debian Day in Santa Maria - RS 2024
was held after a 5-year hiatus from the previous version of the event. It took
place on the morning of August 16, in the Blue Hall of the
Franciscan University (UFN) with support from the
Debian community and the Computing Practices Laboratory of UFN.
The event was attended by students from all semesters of the Computer Science,
Digital Games and Informational Systems, where we had the opportunity to talk to
the participants.
Around 60 students attended a lecture introducing them to Free and Open Source
Software, Linux and were introduced to the Debian project, both about the
philosophy of the project and how it works in practice and the opportunities
that have opened up for participants by being part of Debian.
After the talk, a packaging demonstration was given by local DD Francisco
Vilmar, who demonstrated in practice how software packaging works in Debian.
I would like to thank all the people who helped us:
Debian Project
Professor Ana Paula Canal (UFN)
Professor Sylvio André Garcia (UFN)
Laboratory of Computing Practices
Francisco Vilmar (local DD)
And thanks to all the participants who attended this event asking intriguing
questions and taking an interest in the world of Free Software.
O evento contou com alunos de todos os semestres dos cursos de Ciência da
Computação, Jogos Digitais e Sistemas de Informação, fizemos um coffee break
onde tivemos a oportunidade de conversar com os participantes.
Cerca de 60 alunos prestigiaram uma palestra de introdução ao Software Livre e
de Código Aberto, Linux e foram introduzidos ao projeto Debian, tanto sobre a
filosofia do projeto, até como ele acontece na prática e oportunidades que se
abriram para participantes do projeto por fazerem parte do Debian.
Após a palestra foi feita uma demonstração de empacotamento pelo DD local
Francisco Vilmar, que demonstrou na prática como funciona o empacotamento de
software no Debian.
Gostaria de agradecer a todas as pessoas que nos ajudaram:
Projeto Debian
Professora Ana Paula Canal (UFN)
Professor Sylvio André Garcia
Laboratório de Práticas da Computação
Francisco Vilmar (DD local)
E um muito obrigado a todos os participantes que nos prestigiaram neste evento
fazendo perguntas intrigantes e se interessando pelo mundo do Software Livre.
Release 0.6.37 of the digest package
arrived at CRAN today and has
also been uploaded to Debian.
digest
creates hash digests of arbitrary R objects. It can use a number
different hashing algorithms (md5, sha-1,
sha-256, sha-512, crc32,
xxhash32, xxhash64, murmur32,
spookyhash, blake3,crc32c,
xxh3_64 and xxh3_128), and enables easy
comparison of (potentially large and nested) R language objects as it
relies on the native serialization in R. It is a mature and widely-used
package (with 70.8 million downloads just on the partial cloud mirrors
of CRAN which keep logs) as many tasks may involve caching of
objects for which it provides convenient general-purpose hash key
generation to quickly identify the various objects.
This release updates one of the different hashing source functions
which, to remain close to their upstream, used Free() and
Calloc() (uppercased to use the R allocator) but not the
prefixed stricter versions R_Free() and
R_Calloc(). R will switch to enforcing these in the next
release next year. Kevin had
noticed (while doing some other testing) that this now fails under
R-devel (with a switch set), and prepares a very nice and clean PR to
take care of it. As of today, CRAN is now sending ‘please fix,
or else …’ notes so it was a good time to send this to CRAN. We also updated some
remaining http URLs in the README.md to https, and switched to
Author/Maintainer field to the now also mandatory Authors@R.
(The issues described in this post have been fixed, I have not exhaustively researched whether any other issues exist)
Feeld is a dating app aimed largely at alternative relationship communities (think "classier Fetlife" for the most part), so unsurprisingly it's fairly popular in San Francisco. Their website makes the claim:
Can people see what or who I'm looking for? No. You're the only person who can see which genders or sexualities you're looking for. Your curiosity and privacy are always protected.
which is based on you being able to restrict searches to people of specific genders, sexualities, or relationship situations. This sort of claim is one of those things that just sits in the back of my head worrying me, so I checked it out.
First step was to grab a copy of the Android APK (there are multiple sites that scrape them from the Play Store) and run it through apk-mitm - Android apps by default don't trust any additional certificates in the device certificate store, and also frequently implement certificate pinning. apk-mitm pulls apart the apk, looks for known http libraries, disables pinning, and sets the appropriate manifest options for the app to trust additional certificates. Then I set up mitmproxy, installed the cert on a test phone, and installed the app. Now I was ready to start.
What became immediately clear was that the app was using graphql to query. What was a little more surprising is that it appears to have been implemented such that there's no server state - when browsing profiles, the client requests a batch of profiles along with a list of profiles that the client has already seen. This has the advantage that the server doesn't need to keep track of a session, but also means that queries just keep getting larger and larger the more you swipe. I'm not a web developer, I have absolutely no idea what the tradeoffs are here, so I point this out as a point of interest rather than anything else.
Anyway. For people unfamiliar with graphql, it's basically a way to query a database and define the set of fields you want returned. Let's take the example of requesting a user's profile. You'd provide the profile ID in question, and request their bio, age, rough distance, status, photos, and other bits of data that the client should show. So far so good. But what happens if we request other data?
graphql supports introspection to request a copy of the database schema, but this feature is optional and was disabled in this case. Could I find this data anywhere else? Pulling apart the apk revealed that it's a React Native app, so effectively a framework for allowing writing of native apps in Javascript. Sometimes you'll be lucky and find the actual Javascript source there, but these days it's more common to find Hermes blobs. Fortunately hermes-dec exists and does a decent job of recovering something that approximates the original input, and from this I was able to find various lists of database fields.
So, remember that original FAQ statement, that your desires would never be shown to anyone else? One of the fields mentioned in the app was "lookingFor", a field that wasn't present in the default profile query. What happens if we perform the incredibly complicated hack of exporting a profile query as a curl statement, add "lookingFor" into the set of requested fields, and run it?
Oops.
So, point 1 is that you can't simply protect data by having your client not ask for it - private data must never be released. But there was a whole separate class of issue that was an even more obvious issue.
Looking more closely at the profile data returned, I noticed that there were fields there that weren't being displayed in the UI. Those included things like "ageRange", the range of ages that the profile owner was interested in, and also whether the profile owner had already "liked" or "disliked" your profile (which means a bunch of the profiles you see may already have turned you down, but the app simply didn't show that). This isn't ideal, but what was more concerning was that profiles that were flagged as hidden were still being sent to the app and then just not displayed to the user. Another example of this is that the app supports associating your profile with profiles belonging to partners - if one of those profiles was then hidden, the app would stop showing the partnership, but was still providing the profile ID in the query response and querying that ID would still show the hidden profile contents.
Reporting this was inconvenient. There was no security contact listed on the website or in the app. I ended up finding Feeld's head of trust and safety on Linkedin, paying for a month of Linkedin Pro, and messaging them that way. I was then directed towards a HackerOne program with a link to terms and conditions that 404ed, and it took a while to convince them I was uninterested in signing up to a program without explicit terms and conditions. Finally I was just asked to email security@, and successfully got in touch. I heard nothing back, but after prompting was told that the issues were fixed - I then looked some more, found another example of the same sort of issue, and eventually that was fixed as well. I've now been informed that work has been done to ensure that this entire class of issue has been dealt with, but I haven't done any significant amount of work to ensure that that's the case.
You can't trust clients. You can't give them information and assume they'll never show it to anyone. You can't put private data in a database with no additional acls and just rely on nobody ever asking for it. You also can't find a single instance of this sort of issue and fix it without verifying that there aren't other examples of the same class. I'm glad that Feeld engaged with me earnestly and fixed these issues, and I really do hope that this has altered their development model such that it's not something that comes up again in future.
(Edit to add: as far as I can tell, pictures tagged as "private" which are only supposed to be visible if there's a match were appropriately protected, and while there is a "location" field that contains latitude and longitude this appears to only return 0 rather than leaking precise location. I also saw no evidence that email addresses, real names, or any billing data was leaked in any way)
For many years, I have been using the dlvr.it service to
echo my online activity to where more people can follow it. Namely, I write in
the following sources:
My blog (where this content is being posted to) → RSS
Anyway, dlvr.it sent me a mail stating they would be soon
(as in, the next few weeks) cutting their free tier. And, although I value
their services and am thankfulfor their value so far, I am not going to pay for
my personal stuff to be reposted to social media.
So, this post’s mission is twofold:
If you follow me via any of those media, you will soon not be following me
anymore 😉
If you know of any service that would fill the space left by
dlvr.it, I will be very grateful. Extra gratefulness
points if the option you suggest is able to post to accounts in
less-propietary media (i.e. the Fediverse). Please tell me by mail
([email protected]).
Oh! Forgot to mention: Of course, my blog will continue to be appear in Planet
Debian, Blografía, and
any decent aggregator that consumes my RSS.
Local celebrations of Debian 2024 Day
also happened on [Pouso Alegre, MG, Brazil] (https://www.openstreetmap.org/relation/315431).
In this year we managed to organize two days of lectures!
On the 14th of August 2024, Wednesday morning, we were on the
[Federal Institute of Education, Science and Technology of the South of Minas Gerais] (https://portal.ifsuldeminas.edu.br/index.php),
(IFSULDEMINAS), Pouso Alegre campus. We did an introductory presentation of the
Project Debian, operating system and community, for
the three years of the Technical Course in Informatics (professional high school).
The event was closed to IFSULDEMINAS students and talked to 60 people.
On August 17th, 2024, a Saturday morning, we held the event open to the
community at the University of the Sapucaí Valley
(Univás), with institutional support of the Information Systems Course. We speak
about the Debian Project with Giovani Ferreira
(Debian Developer); about the Debian pt_BR translation team
with Thiago Pezzo; about everyday experiences using free software with Virginia
Cardoso; and on how to set up a development environment ready for production
using Debian and Docker with Marcos António dos Santos. After the lectures,
snacks, coffee and cake were served, while the participants talked, asked
questions and shared experiences.
We would like to thank all the people who have helped us:
Michelle Nery (IFSULDEMINAS) and André Martins (UNIVÁS) for the aid in the local organization
Paulo Santana (Debian Brazil) by the general organization
Virginia Cardoso, Giovani Ferreira, Marco António and Thiago Pezzo for the lectures
And a special thanks to all of you who participated in our celebratio
The diffoscope maintainers are pleased to announce the release of diffoscope
version 276. This version includes the following changes:
[ Chris Lamb ]
* Also catch RuntimeError when importing PyPDF so that PyPDF or, crucially,
its transitive dependencies do not cause diffoscope to traceback at runtime
and build time. (Closes: #1078944, reproducible-builds/diffoscope#389)
* Factor out a method for stripping ANSI escapes.
* Strip ANSI escapes from the output of Procyon. Thanks, Aman Sharma!
* Update copyright years.
A new maintenance release of RcppEigen is now
on CRAN, and will go to Debian shortly as usual. Eigen is a C++ template library
for linear algebra: matrices, vectors, numerical solvers, and related
algorithms.
A very recent change in the development version of R (aka “r-devel”)
expanded the set of declared BLAS and LAPACK functions (and I tooted
approvingly about it as well). It turns out that the
xerbla() declaration there (which, as usual for R and as
discussed in Writing R Extensions, defines the new optional
character length entry for a char vector) conflicts with one in the
blas.h header in Eigen upsetting the compilation
of just one reverse-dependency. So CRAN, as they so often (and
quietly) do in these cases, gave us a friendly and concise heads-up and
asked for a change so we complied, did the usual reverse-dependency
check of the other 400+ packages using RcppEigen and
produced the new release which was injected into the repository during
the current summer break.
The complete NEWS file entry follows.
Changes in
RcppEigen version 0.3.4.0.1 (2024-08-14)
Conditionally comment-out xerbla in
blas.h as it is now providedd by R-devel albeit with
FC_LEN_T (per a CRAN request)
Minor package updates (continuous integration, badges)
As the expression goes, "Time flies when you are having fun", meaning you do
not normally account for the passage of time when you are distracted and
enjoying yourself. The expression is a well established English idiom, though
today for a moment the Debian Project pauses to reflect on that expression.
It has been 31 years now that we have been around.
It has been 31 amazing years of fun and amazement in watching the world around
us grow and ourselves grow into the world.
Let us tell you, we have had a great time in doing so.
We have been invited to nearly every continent and country for over 25 Debian
Developer Conferences, we have contributed to the sciences with our Debian Pure
Blends; we have not given up on or discounted aged hardware with Long Term
Support (LTS); we have encouraged and sponsored diversity with our Outreach
Programs. We have contributed to exploration of this lovely planet and the
vast vacuum of space (where no one hears Developers scream).
There is more to what we have done but from a cursory glance, we seem to have
done it all.
But we never noticed it.
Time does fly or "escape irretrievably" when having a good time and making
progress, though our pause at this moment is that we have also had a few
moments of honest self-evaluation and reflection. Over the years the project
has lost some significant loved ones who were dear to us - you may have called
them Developers while we called them Friends, we called them Mentors, we hurt,
we grieved, and in their memories we keep moving forward.
The course of the project has seen a few tragedies, has seen heated discourse
in the public domain, has addressed and weathered concerns, and has still
continually grown.
And we did that in the public sphere, because at the core this is an open
project. Our code is public, our bugs and failings are public, our
communications are public, our meetings are public, and our love of FLOSS is
most definitely public.
And now more than ever the Debian Project realizes that the "we" that is
sprinkled throughout this letter is just another way of saying: "you". You,
the user, contributor, sponsor, developer, maintainer, bug squasher; all of you
make the WE that is Debian. So what are WE waiting for? Lets celebrate!
Join the worldwide celebration or find an event local to you by visiting our
DebianDay events page - see you there!
So a common theme on the Internet about Debian is so old. And
right, I am getting close to the stage that I feel a little laggy: I
am using a bunch of backports for packages I need, and I'm missing a
bunch of other packages that just landed in unstable and didn't make
it to backports for various reasons.
I disagree that "old" is a bad thing: we definitely run Debian stable
on a fleet of about 100 servers and can barely keep up, I would make
it older. And "old" is a good thing: (port) wine and (any) beer
needs time to age properly, and so do humans, although some humans
never seem to grow old enough to find wisdom.
But at this point, on my laptop, I am feeling like I'm missing
out. This page, therefore, is an evolving document that is a twist
on the classic NewIn game. Last time I played seems to be
#newinwheezy
(2013!), so really, I'm due for an update. (To be fair to myself, I do
keep tabs on upgrades quite well at home and
work, which do have their share of "new in", just after the fact.)
New packages to explore
Those tools are shiny new things available in unstable or perhaps
Trixie (testing) already that I am not using yet, but I find
interesting enough to list here.
codesearch: search all of Debian's source code (tens of
thousands of packages) from the commandline! (see also dcs-cli,
not in Debian)
dasel: JSON/YML/XML/CSV parser, similar to jq, but different
syntax, not sure I'd grow into it, but often need to parse YML like
JSON and failing
Those are packages that I have tested because I found them
interesting, but ended up not using, but I think people could find
interesting anyways.
kew: surprisingly fast music player, parsed my entire library
(which is huge) instantaneously and just started playing (I still
use Supersonic, for which I maintain a flatpak on my
Navidrome server)
mdformat: good markdown formatter, think black or gofmt but
for markdown), but it didn't actually do what I needed, and
it's not quite as opinionated as it should (or could) be)
Backports already in use
Those are packages I already use regularly, which have backports or
that can just be installed from unstable:
If you know of cool things I'm missing out of, then by all means let
me know!
That said, overall, this is a pretty short list! I have most of what I
need in stable right now, and if I wasn't a Debian developer, I don't
think I'd be doing the jump now. But considering how easier it is to
develop Debian (and how important it is to test the next release!),
I'll probably upgrade soon.
Previously, I was running Debian testing (which why the slug on that
article is why-trixie), but now I'm actually considering just
running unstable on my laptop directly anyways. It's been a long time
since we had any significant instability there, and I can typically
deal with whatever happens, except maybe when I'm traveling, and then
it's easy to prepare for that (just pin testing).
The diffoscope maintainers are pleased to announce the release of diffoscope
version 275. This version includes the following changes:
[ Chris Lamb ]
* Update the test_zip.py text fixtures and definitions to support new changes
to IO::Compress. (Closes: #1078050)
* Do not call marshal.loads(...) of precompiled Python bytecode as it is
inherently unsafe. Replace, at least for now, with a brief summary of the
code section of .pyc files. (Re: reproducible-builds/diffoscope#371)
* Don't bother to check the Python version number in test_python.py: the
fixture for this test is deterministic/fixed.
* Update copyright years.
A while ago I got my hands on an electric car - after not having owned
a car for most of my life (there really is not much need here). It
wasn’t planned nor a goal of mine, but it kind of “came out of talks
with my boss”, so now it’s there.
Due to some special rules in the german tax system it turns out
really cheap for me - it comes from the company, which allows
personal use. So I have to pay taxes on the value of it plus whichever
amount of kilometers I have to drive to work. And the latter is what
is good for me - I have homeoffice in my contract, so no drive to
work, except maybe once a year for something. So no regular trip to
calculate, only if I ever really have to do a trip to the office.
And it being an electric car, running costs are also cheap. Way
below the outdated tech that needs gas to run, is annoyingly loud and
stinks.
The car
In the past I used either car sharing or renting a car when I needed
one, depending on what I actually needed. Last times renting I already
tried electric variants, so I could compare this with.
What I have now is a “Citroen e-Berlingo XL” from 2023 (so not the latest
change from 2024), which is on the huge size for space, but small
for battery. It has 7 seats (though I have the last 2 currently taken
out, no daily need) and more storage space than I need even on a
vacation trip.
The engine (or well, it’s battery) is on the small side - a capacity
of 50 kWh means it only has 278km reach according to WLTP. That
actually is a good bit less - as usual, those numbers are lying for
the producer. Turns out that on highways in a more realistic mode than
WLTP (read: real driving) it’s somewhat around 120km before one wants a
charger again. But, looking around, at least in Germany that is not a
big problem, there are more than enough chargers available.
Driving
Actually driving experience is good. It sure is a huge car (4.7m long,
1.85m high/wide) and feels more like driving a (small) bus, but it is
easy to handle. Maximum speed is limited (or the small battery would
suck even more) to 135km/h, but that is more than enough. Even on
german highways. Did my vacation trip with cruise control set to
115km/h and very few times only went above that manually. Real relaxed
driving that was.
Vacation trip
So we had a vacation just recently, and instead of renting a car for
the trip we, of course, wanted to take the e-Berlingo. Distance was
about double what the car can (realistically!) do, so one charging
stop in the middle somewhere was a must. Not having had to charge
on highways yet - and entirely new with this car - that made for a bit of
nervousness, but it all turned out really good. There are really nice
tools like ABRP to plan your trip
including charging, which can take live data of availability of
charging points into the planning.
And it turned out nice - we reached our planned charging point and
found a long queue of cars waiting. But turns out it was all those
poor folks that need actual gasoline for their outdated combustion
engines. The charging points for EV cars still had enough free space,
so we could bypass the queue and directly start charging. We also did
not need to repark the car after just a few minutes, we could directly
start our break.
With a charging time of approx. 30 minutes using the fast charger,
such a break is long enough to get enough energy for the next part of
the trip and short enough to not be annoying.
Charging prices
At home it depends. If one has some photovoltaic system to get power,
charging is basically free. If not it depends on whichever contract
one has, costs will be somewhat between 0 and ~30cent per kWh. Not
much, and way below gasoline costs.
Outside, using a fast charger, prices vary depending on where you
charge - and with what charging card. Prices between 40 and 70cent /
kWh, and the same charging point can vary, just from the card one
uses. That is a thing that the EU could actually go and better
regulate, similar to the phone regulations it took. Still, the costs
are still way below gasoline.
Charging cards
There is a huge amount of different providers available, and all do
their own things in pricing and how one can use them. They do have
standards (say, the plugs are standardized, by now the way to start
charging also), and that enables roaming (use a charging card of one
provider at a charging point of another), but other than that, it
seems to be random.
That is - if you use card A on a charging point of Provider B you may
pay 0.49cents, if you use card C on the same point, it may charge you
0.79cents. And card D isn’t taken at all. Some (the newer ones) you
can pay directly by credit card, many you can’t. Some may allow paypal
or Google/Apple Pay. So in the end you need more than just one
charging card - I collected 8 free ones by now - just to be sure you
can find a combination that isn’t hugely overpriced.
I’m happy to announce that Netplan version 1.1 is now available on GitHub and is soon to be deployed into a Debian and/or Ubuntu installation near you! Six months and 120 commits after the previous version (including one patch release v1.0.1), this release is brought to you by 17 free software contributors from around the globe.
Kudos to everybody involved!
Highlights
Custom systemd-networkd-wait-online logic override to wait for link-local and routable interfaces. (#456, #482)
Modification of the embedded-switch-mode setting without virtual-function (VF) definitions on SR-IOV devices (#454)
Parser flag to ignore individual, broken configurations, instead of not generating any backend configuration (#412)
In mid-June I picked up an unknown infection in my left ankle which turned out to be antibiotic resistant. The infection caused cellulitis. After five weeks of trial and error and treatment, the infection is beaten but I am still recovering from the cellulitis. I don’t know how long it will take to be fully recovered, nor how long before I can be “useful” again: I’m currently off work (and thus off my open source and other commitments too). Hopefully soon! That’s why I’ve been quiet.
Another loss last week of a friend. I am staying strong and working through it. A big thank you to all of you that have donated to my car fund, I still have a long way to go. I am not above getting a cheap old car, but we live in sand dunes so it must be a cheap old car with 4×4 to get to my property. A vehicle is necessary as we are 50 miles away from staples such as food and water. We also have 2 funerals to attend. Please consider a donation if my work is useful to you. https://gofund.me/1e784e74 All of my work is currently unpaid work, as I am between contracts. Thank you for your consideration. Now onto the good stuff, last weeks work. It was another very busy week with Qt6 packaging in Debian/Kubuntu and KDE snaps. I also have many SRUs for Kubuntu Noble .1 release that needs their verification done.
Kubuntu:
See Debian for the qt6 Plasma / applications work.
August will be the month that Debian 11 makes the transition to LTS. Our
contributors have already been hard at work with preparatorty tasks and also
with making contributions to packages in Debian 11 in close collaboration with
the Debian security team and package maintainers. As a result, users and
sponsors should not observe any especially notable differences as the transition
occurs.
While only one DLA was released in July (as a result of the transitional state
of Debian 11 “bullseye”), there were some notable highlights. LTS contributor
Guilhem Moulin prepared an update of libvirt for Debian 11 (in collaboration
with the Old-Stable Release Managers and the Debian Security Team) to fix a
number of outstanding CVEs which did not rise to the level of a DSA by the
Debian Security Team. The update prepared by Guilhem will be included in Debian
11 as part of the final point release at the end of August, one of the final
transition steps by the Release Managers as Debian 11 moves entirely to the LTS
Team’s responsibility. Notable work was also undertaken by contributors Lee Garrett
(fixes on the ansible test suite and a bullseye update), Lucas Kanashiro (Rust toolchain, utilized by the clamav,
firefox-esr, and thunderbird packages), and Sylvain Beucler (fixes on the ruby2.5/2.7 test
suites and CI infrastructure), which will help improve the quality of updates produced during
the next LTS cycle.
June was the final month of LTS for Debian 10 (as announced on the
debian-lts-announce
mailing list). No additional Debian 10 security updates will be made available
on security.debian.org.
However, Freexian and its team of paid Debian contributors will continue
to maintain Debian 10 going forward for customers of the
Extended LTS offer. Subscribe right
away if you still have Debian 10 systems which must be kept secure (and which
cannot yet be upgraded).
autopkgtest/Incus build streamlining, by Colin Watson
Colin contributed a change to allow maintaining Incus container and VM
images in parallel.
Both of these are useful (containers are faster, but some tests need
full machine isolation), and the build tools previously didn’t handle
that very well.
This isn’t yet in unstable, but once it is, keeping both flavours of
unstable images up to date will be a simple matter of running this
regularly:
In collaboration with Emmanuel Arias, Santiago
continued the work on the support for applying security fixes to the
Linux kernel in Debian, without the need to reboot the machine.
As mentioned in the previous month report, kpatch
0.9.9-1
(and 0.9.9-2 afterwards) was uploaded to unstable in July, closing the
Intent to Salvage (ITS) bug.
With this upload, the remaining RC bugs were solved, and kpatch was able
to transition to Debian testing recently.
Kpatch is expected to be an important component in the live-patching
support, since it makes it easy to build a patch as a kernel module.
Emmanuel and Santiago continued to work on the design for Linux
live-patching and presented the current status in the DebConf24
presentation.
Salsa CI, by Santiago Ruano Rincón
To be able to add RISC-V support and to avoid using tools not packaged
in Debian (See #331),
the Salsa CI pipeline first needed to move away from
kaniko to build the images used by the
pipeline.
Santiago created a merge request to use
buildah
instead, and it was merged last month.
Santiago also prepared a couple of more MRs related to how the images
are built: initial RISC-V
support,
that should be merged after improving how built images are
tested.
The switch to buildah introduced a regression in the
work-in-progress MR that adds new build image so the build job can run
sbuild.
Santiago hopes to address this regression and continue with the
sbuild-related MRs in August.
As Python 3.13 is approaching the first
release, Stefano has been uploading
the beta releases to Debian unstable.
Most of these have uncovered small bugs that needed to be investigated
and fixed.
Stefano also took the time to review the current patch set against
cPython in Debian.
Python 3.13 isn’t marked as a supported Python release in Debian’s
Python tooling, yet, so nothing has been built against it, yet.
Now that the Python 3.12 transition has completed, the next task will be
to start trying to build Debian’s Python module packages against Python
3.13, to estimate the work required to transition to 3.13 in unstable.
Miscellaneous contributions
Carles Pina updated the packages python-asyncclick, python-pyaarlo and
prepared updates for python-ring-doorbell and simplemonitor.
Carles Pina updated (reviewing or translating) Catalan translations
for adduser, apt-listchanges, debconf and shadow.
Colin merged OpenSSH 9.8, and prepared a corresponding release
note
for DSA support now being disabled.
This version included some substantial changes to split the server
into a listener binary and a per-session binary, and those required
some corresponding changes in the GSS-API key exchange patch.
Sorting out the details of this and getting it to work again took some
time.
Colin upgraded 11 Python packages to new upstream versions, and
modernized the build process and/or
added non-superficial autopkgtests to several more.
Raphaël Hertzog tweaked tracker.debian.org’s debci task to work around
changes in the JSON output.
He also improved tracker.debian.org’s ability to detect bounces due to
spam to avoid unsubscribing emails that are not broken, but that are
better than Debian at rejecting spam.
Helmut Grohne monitored the /usr-move transition with few incidents.
A notable one is that some systems have ended up with aliasing links
that don’t match the ones installed by base-files which could lead
to an unpack error from dpkg.
This is now prevented by having base-files.preinst error out.
Helmut investigated toolchain bootstrap failures with gcc-14 in
rebootstrap but would only discover the cause in August.
Helmut sent a
MR
for the cross-exe-wrapper requested by Simon
McVittie for gobject-introspection.
It is a way of conditionally requesting qemu-user when emulation is
required for execution during cross compilation.
Helmut sent three patches for cross build failures.
Thorsten Alteholz uploaded packages lprint and magicfilter to fix
RC-bugs that appeared due to the introduction of gcc-14.
Santiago continued to work on activities related to the DebConf24
Content Team, including reviewing the schedule and handling updates on
it.
Santiago worked on preparations for the DebConf25, to be held in
Brest, France, next year. A video of the BoF presented during DebConf24
can be found here.
Stefano worked on preparations for DebConf24, and helped to run the event.
Vienna - the capital of Austria - is one of the most visited cities in the world, popular for its rich history, gardens, and cafes, along with well-known artists like Beethoven, Mozart, Gödel, and Freud. It has also been consistently ranked as the most livable city in the world.
For these reasons, I was elated when my friend Snehal invited me last year to visit Vienna for a few days. We included Christmas and New Year’s Eve in my itinerary due to the city’s popular Christmas markets and lively events. The festive season also ensured that Snehal had some days off for sightseeing.
Indians require a visa to visit Austria. Since the travel dates were near, I rushed to book an appointment online with VFS Global in Delhi, and quickly arranged the required documents. However, at VFS, I found out that I had applied in the wrong appointment category (tourist), which depends on the purpose of the visit, and that my travel dates do not allow enough time for visa authorities to make a decision. Apparently, even if you plan to stay only for a part of the trip with the host, you need to apply under the category “Visiting Friends and Family”.
Thus, I had to book another appointment under this category, and took the opportunity to shift my travel dates to allow at least 15 business days for the visa application to be processed, removing Christmas and New Year’s Eve from my itinerary.
The process went smoothly, and my visa application was submitted by VFS. For reference, here’s a list of documents I submitted -
VFS appointment letter
Duly-filled visa application form
Original passport
Copy of passport
1 photograph
My 6 months bank account statement
Cover letter
Consent form (that visa processing will take up to 15 business days)
Snehal’s job contract
My work contract
Rent contract of Snehal
Residence permit of Snehal
A copy of Snehal’s passport
Invitation letter from Snehal
Return flight ticket reservations
Travel insurance for the intended travel dates
The following charges were collected from me.
Service Description
Amount (Indian Rupees)
Cash Handling Charge - SAC Code: (SAC:998599)
0
VFS Fee - India - SAC Code: (SAC:998599)
1,820
VISA Fee - India - SAC Code:
7,280
Convenience Fee - SAC Code: (SAC:998599)
182
Courier Service - SAC Code: (SAC:998599)
728
Courier Assurance - SAC Code: (SAC:998599)
182
Total
10,192
I later learned that the courier charges (728 INR) and the courier assurance charges (182 INR) mentioned above were optional. However, VFS didn’t ask whether I wanted to include them. When the emabssy is done processing your application, it will send your passport back to VFS, from where you can either collect it yourself or get it couriered back home, which requires you to pay courier charges. However, courier assurance charges do not add any value as VFS cannot “assure” anything about courier and I suggest you get them removed.
My visa application was submitted on the 21st of December 2023. A few days later, on the 29th of December 2023, I received an email from the Austrian embassy asking me to submit an additional document -
Subject: AUSTRIAN VISA APPLICATION - AMENDMENT REQUEST: Ravi Dwivedi VIS 4331
Dear Applicant,
On 22.12.2023 your application for Visa C was registered at the Embassy. You are requested to kindly send the scanned copies of the following documents via email to the Embassy or submit the documents at the nearest VFS centre, for further processing of your application:
Kindly submit Electronic letter of guarantee “EVE- Elektronische Verpflichtungserklärung” obtained from the “Fremdenpolizeibehörde” of the sponsor’s district in Austria. Once your host company/inviting company has obtained the EVE, please share the reference number (starting from DEL_____) received from the authorities, with the Embassy.
Kindly Note:
It is in your own interest to fulfil the requirements as indicated above and submit the missing documents within 14 days of the receipt of this email. Otherwise a decision will be taken based on the documentation available.
“Sie werden in Ihrem Interesse ersucht, die gekennzeichneten Mängel so schnell wie möglich zu beheben bzw. fehlende Unterlagen umgehend nachzureichen, um die weitere Bearbeitung des Antrages zu ermöglichen. Sollten Sie innerhalb 14 Tagen die gekennzeichneten Mängel nicht beheben bzw. die fehlenden Unterlagen nicht nachreichen, wird über den vorliegenden Antrag ohne diese Unterlagen bzw. Mängelbehebung entschieden.”
Austrian Embassy New Delhi
I misunderstood the required document (the EVE) to be a scanned copy of the letter of guarantee form signed by Snehal, and responded by attaching it.
Upon researching, Snehal determined that the document is an electronic letter of guarantee, and is supposed to be obtained at a local police station in Vienna. He visited a police station the next day and had a hard time conversing due to the language barrier (German is the common language in Austria, whereas Snehal speaks English). That day was a weekend, so he took an appointment for Monday, but in the meantime the embassy had finished processing my visa.
My visa was denied, and the refusal letter stated:
The Austrian embassy in Delhi examined your application; the visa has been refused.
The decision is based on the following reason(s):
The information submitted regarding the justification for the purpose and conditions of the intended stay was not reliable.
There are reasonable doubts as to your intention to leave the territory of the Member States before the expiry of the visa.
Other remarks:
You have been given an amendment request, which you have failed to fulfil, or have only fulfilled inadequately, within the deadline set.
You are a first-time traveller. The social and economic roots with the home country are not evident. The return from Schengen territory does therefore not seem to be certain.
I could have reapplied after obtaining the EVE, but I didn’t because I found the following line
The social and economic roots with the home country are not evident.
offensive for someone who was born and raised in India, got the impression that the absence of electronic guarantee letter was not the only reason behind the refusal, had already wasted 12,000 INR on this application, and my friend’s stay in Austria was uncertain after January. In fact, my friend soon returned to India.
To summarize -
If you are visiting a host, then the category of appointment at VFS must be “Visiting Friends and Family” rather than “Tourist”.
VFS charged me for courier assurance, which is an optional service. Make sure to get these removed from your bill.
Neither my travel agent nor the VFS application center mentioned the EVE.
Snehal informed me that a mere two months ago, his wife’s visa was approved without an EVE. This hints at inconsistency in processing of applications, even those under identical categories.
Such incidents are a waste of time and money for applicants, and an embarrassment to VFS and the Austrian visa authorities. I suggest that the Austrian visa authorities fix that URL, and provide instructions for hosts to obtain the EVE.
Credits to Snehal and Contrapunctus for editing, Badri for proofreading.
On Saturday 3 August 2024, the annual Debian Developers and Contributors
Conference came to a close.
Over 339 attendees representing 48 countries from around the world came
together for a combined 108 events made up of more than 50 Talks and
Discussions, 37 Birds of a Feather (BoF – informal meeting between
developers and users) sessions, 12 workshops, and activities in support
of furthering our distribution and free software (25 patches submitted
to the Linux kernel), learning from our mentors and peers, building our
community, and having a bit of fun.
The conference was preceded by the annual
DebCamp hacking session held July 21st
through July 27th where Debian Developers and Contributors convened to
focus on their Individual Debian-related projects or work in team sprints
geared toward in-person collaboration in developing Debian.
This year featured a BootCamp that was held for newcomers with a GPG
Workshop and a focus on Introduction to creating .deb files (Debian
packaging) staged by a team of dedicated mentors who shared hands-on
experience in Debian and offered a deeper understanding of how to work in
and contribute to the community.
The actual Debian Developers Conference started on Sunday July 28 2024.
In addition to the traditional 'Bits from the DPL' talk, the continuous
key-signing party, lightning talks and the announcement of next year's
DebConf25, there were several update sessions shared by internal projects
and teams.
Many of the hosted discussion sessions were presented by our technical
core teams with the usual and useful meet the Technical Committee and the
ftpteam and a set of BoFs about packaging policy and Debian infrastructure,
including talk about APT and Debian Installer and an overview about the
first eleven years of Reproducible Builds. Internationalization and
localization have been subject of several talks. The Python, Perl, Ruby,
and Go programming language teams, as well as Med team, also shared updates
on their work and efforts.
More than fifteen BoFs and talks about community, diversity and local
outreach highlighted the work of various team involved in the social
aspect of our community. This year again, Debian Brazil shared strategy
and action to attract and retain new contributors and members and
opportunities both in Debian and F/OSS.
The schedule
was updated each day with planned and ad-hoc activities introduced by
attendees over the course of the conference. Several traditional activities
took place: a job fair, a poetry performance, the traditional
Cheese and Wine party, the group photos and the Day Trips.
For those who were not able to attend, most of the talks and sessions were
broadcast live and recorded and the videos made available through a link in
their summary in the
schedule.
Almost all of the sessions facilitated remote participation via IRC
messaging apps or online collaborative text documents which allowed remote
attendees to 'be in the room' to ask questions or share comments with the
speaker or assembled audience.
DebConf24 saw over 6.8 TiB (4.3 TiB in 2023) of data streamed, 91.25
hours (55 in 2023) of scheduled talks, 20 network access points, 1.6 km
fibers (1 broken fiber...) and 2.2 km UTP cable deployed, more than 20
country Geoip viewers, 354 T-shirts, 3 day trips, and up to 200 meals
planned per day.
All of these events, activities, conversations, and streams coupled with our
love, interest, and participation in Debian and F/OSS certainly made this
conference an overall success both here in Busan, South Korea and online
around the world.
The DebConf24 website
will remain active for archival purposes and will continue to offer
links to the presentations and videos of talks and events.
Next year, DebConf25 will be held
in Brest, France, from Monday, July 7 to Monday, July 21, 2025. As
tradition follows before the next DebConf the local organizers in France
will start the conference activities with DebCamp with particular focus on
individual and team work towards improving the distribution.
Debian thanks the commitment of numerous
sponsors
to support DebConf24, particularly our Platinum Sponsors:
Infomaniak,
Proxmox,
and Wind River.
We also wish to thank our Video and Infrastructure teams, the DebConf24
and DebConf committees, our host nation of South Korea, and each and every
person who helped contribute to this event and to Debian overall.
Thank you all for your work in helping Debian continue to be "The Universal
Operating System".
See you next year!
About Debian
The Debian Project was founded in 1993 by Ian Murdock to be a truly free
community project. Since then the project has grown to be one of the
largest and most influential open source projects. Thousands of
volunteers from all over the world work together to create and maintain
Debian software. Available in 70 languages, and supporting a huge range
of computer types, Debian calls itself the universal operating system.
About DebConf
DebConf is the Debian Project's developer conference. In addition to a
full schedule of technical, social and policy talks, DebConf provides an
opportunity for developers, contributors and other interested people to
meet in person and work together more closely. It has taken place
annually since 2000 in locations as varied as Scotland, Argentina, Bosnia
and Herzegovina, and India. More information about DebConf is available from
https://debconf.org/.
About Infomaniak
Infomaniak is an independent cloud service
provider recognized throughout Europe for its commitment to privacy, the
local economy and the environment. Recording growth of 18% in 2023, the
company is developing a suite of online collaborative tools and cloud
hosting, streaming, marketing and events solutions. Infomaniak uses
exclusively renewable energy, builds its own data centers and develops its
solutions in Switzerland, without relocating. The company powers the
website of the Belgian radio and TV service (RTBF) and provides streaming
for more than 3,000 TV and radio stations in Europe.
About Proxmox
Proxmox provides powerful and user-friendly
Open Source server software. Enterprises of all sizes and industries use
Proxmox solutions to deploy efficient and simplified IT infrastructures,
minimize total cost of ownership, and avoid vendor lock-in. Proxmox also
offers commercial support, training services, and an extensive partner
ecosystem to ensure business continuity for its customers. Proxmox Server
Solutions GmbH was established in 2005 and is headquartered in Vienna,
Austria. Proxmox builds its product offerings on top of the Debian
operating system.
About Wind River
Wind River For nearly 20 years, Wind River
has led in commercial Open Source Linux solutions for mission-critical
enterprise edge computing. With expertise across aerospace, automotive,
industrial, telecom, and more, the company is committed to Open Source
through initiatives like eLxr, Yocto, Zephyr, and StarlingX.
This month I accepted 502 and rejected 40 packages. The overall number of packages that got accepted was 515.
In case you want to upload dozens of packages, it would be nice to give some heads-up before. It is kind of a shock to see a full NEW queue in the morning, though it was much shorter in the evening before.
Debian LTS
This was my hundred-twenty-first month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian.
[#1074439] bookworm-pu: cups 2.4.2-3+deb12u7 has been marked for accept
This month I finished the new version of tiff for Bullseye (and Bookworm). The upload will follow, when Bullseye has been handed over to the LTS team in August.
Last but not least I attended the monthly LTS/ELTS meeting.
Debian ELTS
This month was the seventy-second ELTS month. During my allocated time I uploaded or worked on:
[ELA-1126-1-1]exim4 security update for one CVE. This was the delayed ELA I mentioned in my last report.
[ELA-1144-1-1]exim4 security update for one CVE to fix parsing of multiline RFC 2231 header filenames in Stretch and Buster. Jessie was not affected by this issue.
Uploaded new versions of tiff for Jessie and Stretch that got stuck in the autopkgtests.
For whatever reason, I had trouble with the CI again. The new tiff package wanted to run the autopkgtest of cups but never did it. So the corresponding ELA will appear only in August.
I also continued to work on an update for libvirt. There really is a reason why some packages don’t get much attention. Nevertheless someone has to take care of them. I also did a week of FD and attended the LTS/ELTS meeting.
A relative also has one which is working well for them but which had some problems, I only discovered that holding the button down for a long time (longer than usual for device reset) makes a PineTime reboot because of their issues. I also once had their device get into a bad state where the only thing I could do was flash a newer firmware which fortunately fixed the problem.
My latest issue is the battery life. Recently it has been taking ages to get above about 90% charge when charging and the time taken to go down to ~70% when I charge it seems to be decreasing. Yesterday it suddenly went to 13% after being 73% the previous night. Then it stayed at 13% all day. It seems quite inaccurate. But also it doesn’t seem to be lasting as long as before.
Generally it seems to me that Pine64 products are almost great. I won’t rule out the possibility of a newer firmware for the PineTime alleviating the battery issues (or at least reporting the status accurately) and making Bluetooth connectivity more reliable (even on older phones). For the PinePhonePro an update to Mobian could reduce power wasting from user space (there’s an issue that I have reported in Plasma Mobile but no-one is interested on working on this before KDE 6), and a kernel update could improve things. But I don’t think there’s a possibility of it ever having the battery last a day while polling Matrix and Jabber servers which is something that every Android phone can do without problems.
The actor Kangana Ranaut plays in that movie the role of Rani Mehra, a
24-year-old Punjabi woman, who was a simple, homely girl that was always
reliant on her family. Similar to Rani I too rarely ventured out without my
parents and often needed my younger sibling by my side. Inspired by her
transformation, I decided it was time to take control of my own story and
discover who I truly am.
Trip Requirements
My First Passport
The journey began with a significant first step: Obtaining my first
passport❗️
Never having had one before, I scheduled the nearest available interview
date on June 29 2022. This meant traveling to Solapur, a city 309 km from my
hometown, accompanied by my father. After successfully completing the
interview, I received my passport on July 14 2022.
Select A Country, Booking Flights And Accommodation
Excited and ready to embark on my adventure, I planed trip to Albania 🇦🇱 and
booked the flight tickets. Why? I had heard from friends that it was a
beautiful European country with beaches and other attractions, and
importantly, it didn’t require a visa for Indian citizens and was more
affordable than other European destinations. Before heading to Albania, I
planned a overnight stop in Abu Dhabi with a transit visa, thanks to friend
who knew the process for obtaining it.
Some of my friends did travel also to Europe at the same time and quite
close to my plannings, but that I realized just later the trip. 😉
Day 1, Starting The Experience
On July 20, 2022, I started my journey by traveling from Pune, Maharashtra,
to Delhi, where my brother lives. He came to see me off at the airport,
adding a touch of warmth and support to the beginning of my solo adventure.
Upon arriving in Delhi, with my next flight scheduled for July 21, I stayed
at a backpacker hostel named Zostel, Paharganj, Delhi to rest.
During my stay, I noticed that many travelers at the hostel carried
rucksacks, which sparked a desire in me to get one for my own trip to
Europe. Up until then, I had always shopped with my mom and had never bought
anything on my own. Inspired by the travelers, I set out to find a suitable
rucksack. I traveled alone by metro from Paharganj to Rohini to visit a
Decathlon store, where I purchased a 50-liter rucksack. This was a
significant step in preparing for my European adventure and marked a
milestone in my journey of self reliance.
Day 2, Flying To Abu Dhabi
The following day, July 21 2024, I had a flight to Abu Dhabi. I spent the
night at the hostel to rest before my journey. On the day of the flight, I
needed to reach the airport by 3 PM, and a friend kindly came to drop me
off. With my rucksack packed and excitement building, I was ready for the
next leg of my adventure.
When we arrived at the airport, my friend saw me off, marking the start of
my international journey. With mom made spices, chutneys, and chilly flakes
packed for comfort, I completed my immigration process in about two and a
half hours. I then settled at the gate for my flight, feeling a mix of
excitement and anxiety as thoughts raced through my mind.
To ease my nerves, I struck up a conversation with a man seated nearby who was
also traveling to Abu Dhabi for work. He provided helpful information about
safety and transportation in Abu Dhabi, which reassured me. With the boarding
process complete and my anxiety somewhat eased. I found my window seat on the
flight and settled in, excited for the journey ahead. Next to me was a young
man from Ranchi(Zarkhand, India), heading to Abu Dhabi for work at a mining
factory. We had an engaging conversation about work culture in Abu Dhabi and
recruitment from India.
Upon arriving in Abu Dhabi, I completed my transit, collected my luggage, and
began finding my way to the hotel Premier Inn AbuDhabi,
which was in the airport area. To my surprise, I ran into the same man from the
flight, now in a cab. He kindly offered to drop me at my hotel, which I gladly
accepted since navigating an unfamiliar city with a short acquaintance felt
safer.
At the hotel gate, he asked if I had local currency (Dirhams) for payment,
as sometimes online transactions can fail. That hadn’t crossed my mind, and
I realized I might be left stranded if a transaction failed. Recognizing his
help as a godsend, I asked if he could lend me some Dirhams, promising to
transfer the amount later. He kindly assured me to pay him back once I
reached the hotel room. With that relief, I checked into the hotel, feeling
deeply grateful for the unexpected assistance and transferred the money to
him after getting to my room.
Day 3, Flying And Arrive In Tirana
Once in the hotel room, I found it hard to sleep, anxious about waking up on
time for my flight. I set an alarm to wake up early, but my subconscious mind
kept me alert, and I woke up before the alarm went off. I got freshened up and
went down for breakfast, where I found some vegetarian options like
Idli-Sambar and bread with butter, along with some morning tea.
After breakfast, I headed back to the airport, ready to catch my flight to my
final destination: Tirana, Albania.
I reached Tirana, Albania after a six hours flight, feeling exhausted and I was
suffering from a headache. The air pressure had blocked my ears, and jet lag
added to my fatigue. After collecting my checked luggage, I headed to the first
ATM machine at the airport. Struggling to insert my card, I asked a nearby
gentleman for help. He tried his best, but my card got stuck inside the
machine. Panic 🥵 set in as I worried about how I would survive without money.
Taking a deep breath, I found an airport employee and explained the situation.
The gentleman stayed with me, offering support and repeatedly apologizing for
his mistake. However, it wasn’t his fault, the ATM was out of order, which I
hadn’t noticed. My focus was solely on retrieving my ATM card. The airport
employee worked diligently, using a hairpin to carefully extract my card.
Finally, the card was freed, and I felt an immense sense of relief, grateful
for the help of these kind strangers. I used another ATM, successfully withdrew
money, and then went to an airport mobile SIM shop to buy a new SIM card for
local internet and connectivity.
Day 4, Arriving In Tirana, Facing Challenges In A Foreign Country
I had booked a stay at a backpacker hostel near the city center of Tirana.
After sorting out the ATM and SIM card issues, I searched for a bus or any
transport to get there. It was quite late, around 8:30 PM, and being in a
new city, I was in a hurry. I saw a bus nearly leaving the airport, stopped
it, and asked if it went to the city center. They gave me the green flag, so
I boarded the airport service bus and reached the city center.
Feeling very tired, I discovered that the hostel was about an hour and a
half away by walking. Deciding to take a cab, I faced a challenge as the
driver couldn’t understand my English or accent. Using a mobile translator
to convert my address from English to Albanian, I finally communicated my
destination to him. With that sorted out, I headed to the
Blue Door Backpacker Hostel and arrived around 9 PM,
relieved to have finally reached my destination and I checked in.
I found my top bunk bed, only to realize I had booked a mixed-gender
dormitory. This detail had completely escaped my notice during the booking
process. I felt unsure about how to handle the situation. Coincidentally,
my experience mirrored what Kangana faced in the movie “Queen”.
Feeling acidic due to an empty stomach and the exhaustion of heavy
traveling, I wasn’t up to cooking in the hostel’s kitchen.
I asked the front desk about the nearest restaurant. It was nearly 9:30 PM,
and the streets were deserted. To avoid any mishaps like in the movie
“Queen,” I kept my passport securely locked in my bag, ensuring it wouldn’t
be a victim of theft.
Venturing out for dinner, I felt uneasy on the quiet streets. I eventually
found a restaurant recommended by the hostel, but the menu was almost
entirely non-vegetarian. I struggled to ask about vegetarian options and was
uncertain if any dishes contained eggs, as some people consider eggs to be
vegetarian. Feeling frustrated and unsure, I left the restaurant without
eating.
I noticed a nearby grocery store that was about to close and managed to get
a few extra minutes to shop. I bought some snacks, wafers, milk, and tea
bags (though I couldn’t find tea powder to make Indian-style tea). Returning
to the hostel, I made do with wafers, cookies, and milk for dinner. That day
was incredibly tough for me, I filled with exhaustion and struggle in a new
country, I was on the verge of tears 🥹.
I made a video call home before sleeping on the top bunk bed. It was a new
experience for me, sharing a room with both unknown men and women. I kept my
passport safe inside my purse and under my pillow while sleeping, staying
very conscious about its security.
Day 5, Exploring Nearby Places
I woke up the next day at noon. After having some coffee, the hostel
management girl asked if I wanted breakfast. She offered curd with
cornflakes, which I refused because I don’t like curd. Instead, I ordered a
pizza from a vegetarian pizza place with her help, and I started feeling
better.
I met some people in the hostel, some from Syria and others from Italy. I
struggled to understand their accents but kept pushing myself to get
involved in their discussions. Despite the challenges, I felt more at ease
and was slowly adapting to my new environment.
I went out from the hostel in the evening to buy some vegetables to cook
something. I searched for shops and found some potatoes, tomatoes, and rice. I
decided to cook Khichdi, an Indian dish made with rice, and added
some chili flakes I brought from home. After preparing my dinner, I ate and
then went to sleep again.
Day 6, Tiranas Recent History
The next day, I planned to explore the city and visited Bunkart-1,
a fascinating museum in a massive underground bunker from the communist era.
Originally built as a shelter for Albania’s political and military elite, it
now offers a unique glimpse into the country’s history under Enver Hoxha’s
oppressive regime. The museum’s exhibits include historical artifacts,
photographs, and multimedia displays that detail the lives of Albanians during
that time. Walking through the dimly lit corridors, I felt the weight of
history and gained a deeper understanding of Albania’s past.
Day 7-8, Meeting Friends From India
The next day, I accidentally met with Chirag, who was returning from the
Debian Conference 2022 held in Prizren, Kosovo, and staying at the same
hostel. When I encountered him, he was talking on the phone, and I
recognized he was Indian by his accent. I introduced myself, and we
discovered we had some mutual friends.
Chirag told me that our common friend, Raju, was also coming to stay at the
hostel the next day. This news made me feel relaxed and happy to have known
people around. When Raju arrived, the three of us, Chirag, Raju, and
I planned to have dinner at an Indian restaurant and explore Tirana city. I
had a great time talking and enjoying their company.
Day 9-10, Meeting More Friends
Raju had a ticket to leave soon, so Chirag and I made a plan to visit
Shkodër and the nearby Komani Lake for kayaking. We started our journey
early in the morning by bus and reached Shkodër. There, we met new friends
from the conference, Pavit and Abraham, who were already there. We had
dinner together and enjoyed an ice cream treat from Chirag.
Day 12, Kayaking And Say Good Bye To Friends
The next day, Pavit and Abraham had a flight back to India, so Chirag and I
went to Komani Lake. We had an adventurous time kayaking, even though
neither of us knew how to swim. We took a ferry through the backwaters to
the island on Komani Lake and enjoyed a fantastic adventure together. After
our trip, Chirag returned to Tirana for his flight back to India, leaving me
to continue my journey alone.
Day 13, Climbing Rozafa Castel
By stopping at Shkodër, I visited Rozafa Castle. Despite the language
barrier, as most locals only spoke Albanian, people around me guided me
correctly on how to get there. At times, I used applications like Google
Translate to communicate. To read signs or hotel menus, I used Google
Photos' language converter. I even used the audio converter to understand
and speak some basic Albanian phrases.
I took a bus from Shkodër to the southern part of Albania, heading to
Sarandë. The journey lasted about five to six hours, and I had booked a stay
at Mona’s Hostel. Upon arrival, I met Eliza from America, and we went
together to Ksamil Beach, spending a wonderful day there.
Day 14, Vlora Beach: Beach Side Cycling
Next, I traveled to Vlorë, where I stayed for one day. During my time there, I
enjoyed beach side cycling with a cycle provided by the hostel owner and spent
some time feeding fish. I also met a fellow traveler from Delhi who had brought
along some preserved Indian curry. He kindly shared it with me, which was a
welcome change after nearly 15 days without authentic Indian cuisine, except
for what I had cooked myself in various hostels.
Day 15-16 Visiting Durress, Travelling Back To Tirana
I then visited Durrës, exploring its beautiful beaches, before heading back
to Tirana one day before my flight home. On the day of my flight, my alarm
didn’t go off, and I woke up late at the hostel. In a frantic rush, I packed
everything in just five minutes and dashed toward the city center to catch
the bus to the airport. If I had been just five minutes later, I would have
missed the bus. Thankfully, I managed to stop it just in time and began my
journey back home, reflecting on the incredible adventure I had experienced.
Fortunately, I wasn’t late; I arrived at the airport just in time. After
clearing immigration, I boarded my flight, which had a layover in Warsaw,
Poland. The journey from Tirana to Warsaw took about two and a half hours,
followed by a seven to eight-hour flight from Poland back to India. Once I
arrived in Delhi, I returned to Zostel and booked a train ticket to
Aurangabad for the next three days.
Backview 😄
This trip was an incredible adventure for me. I never imagined I could
accomplish something like this, but I did. Meeting diverse people,
experiencing different cultures, and learning so much made this journey
truly unforgettable.
Looking back, I realize how much I’ve grown from this experience. Although I
may have more opportunities to travel abroad in the future, this trip will
always hold a special place in my heart. The memories I made and the
incredible people I met along the way are irreplaceable.
This experience goes beyond what I can express through this blog or words;
it was incredibly precious to me. Every moment of this journey is etched in
my memory, and I am grateful for every part of it.
I care about performance, and I care about benchmarking. So it really
annoys me when people throw out stuff like “this is 0.3% faster so it's
a win”, without saying anything about the uncertainty in their benchmark
estimates.
Turns out this is actually a fairly hard problem; since performance
is essentially sum(before) / sum(after) and dividing anything by anything
is rarely well-behaved in statistics. So the best I see is usually
something like “worst and best we've seen”, which isn't… all that useful?
So at work, I coded up an implementation of the statistical bootstrap,
based on some R code I've used for a while. It gives reasonable 95% and 99%
confidence intervals of unpaired data, without relying on assumptions of
normality (including via the central limit theorem); here's a set of
benchmarks I ran recently over an optimization, as an example:
The program itself is geared towards interpreting a Chromium-specific
output format (it is not a test runner), but the actual statistics
code is encapsulated in a class with no other dependencies than a PRNG,
a simple sorter and a math library, so it should be simple to port to other languages
and environments. Like the rest of Chromium, it is liberally licensed.
The diffoscope maintainers are pleased to announce the release of diffoscope
version 274. This version includes the following changes:
[ Chris Lamb ]
* Add support for IO::Compress::Zip >= 2.212. (Closes: #1078050)
* Don't include debug output when calling dumppdf(1).
* Append output from dumppdf(1) in more cases.
(Closes: reproducible-builds/diffoscope#387)
* Update copyright years.
[ Mattia Rizzolo ]
* Update the available architectures for test dependencies.
In our reports, we outline what we’ve been up to over the past month and highlight news items in software supply-chain security more broadly. As always, if you are interested in contributing to the project, please visit our Contribute page on our website.
Last month, we were very pleased to announce the upcoming Reproducible Builds Summit, set to take place from September 17th — 19th 2024 in Hamburg, Germany. We are thrilled to host the seventh edition of this exciting event, following the success of previous summits in various iconic locations around the world, including Venice, Marrakesh, Paris, Berlin and Athens. Our summits are a unique gathering that brings together attendees from diverse projects, united by a shared vision of advancing the Reproducible Builds effort. During this enriching event, participants will have the opportunity to engage in discussions, establish connections and exchange ideas to drive progress in this vital field. Our aim is to create an inclusive space that fosters collaboration, innovation and problem-solving.
If you’re interesting in joining us this year, please make sure to read the event page, which has more details about the event and location. We are very much looking forward to seeing many readers of these reports there.
In a recent edition of Linux Weekly News, Daroc Alden has written an article on “bootstrappable” builds. Starting with a brief introduction that…
… a bootstrappable build is one that builds existing software from scratch — for example, building GCC without relying on an existing copy of GCC. In 2023, the Guix project announced that the project had reduced the size of the binary bootstrap seed needed to build its operating system to just 357-bytes — not counting the Linux kernel required to run the build process.
The article goes onto to describe that “now, the live-bootstrap project has gone a step further and removed the need for an existing kernel at all.” and concludes:
The real benefit of bootstrappable builds comes from a few things. Like reproducible builds, they can make users more confident that the binary packages downloaded from a package mirror really do correspond to the open-source project whose source code they can inspect. Bootstrappable builds have also had positive effects on the complexity of building a Linux distribution from scratch […]. But most of all, bootstrappable builds are a boon to the longevity of our software ecosystem. It’s easy for old software to become unbuildable. By having a well-known, self-contained chain of software that can build itself from a small seed, in a variety of environments, bootstrappable builds can help ensure that today’s software is not lost, no matter where the open-source community goes from here
Trisquel developer Simon Josefsson wrote an interesting blog post comparing the output of the .deb files from our tests.reproducible-builds.org testing framework and the ones in the official Debian archive. Following up from a previous post on the reproducibility of Trisquel, Simon notes that “typically [the] rebuilds do not match the official packages, even when they say the package is reproducible”, Simon correctly identifies that “the purpose of [these] rebuilds are not to say anything about the official binary build, instead the purpose is to offer a QA service to maintainers by performing two builds of a package and declaring success if both builds match.”
However, Simon’s post swiftly moves on to announce a new tool called debdistrebuild that performs rebuilds of the difference between two distributions in a GitLab pipeline and displays diffoscope output for further analysis.
Mehdi Keshani, Tudor-Gabriel Velican, Gideon Bot and Sebastian Proksch of the Delft University of Technology, Netherlands, have published a new paper in the ACM Software Engineering on a new tool to automatically reproduce Apache Maven artifacts:
Reproducible Central is an initiative that curates a list of reproducible Maven libraries, but the list is limited and challenging to maintain due to manual efforts. [We] investigate the feasibility of automatically finding the source code of a library from its Maven release and recovering information about the original release environment. Our tool, AROMA, can obtain this critical information from the artifact and the source repository through several heuristics and we use the results for reproduction attempts of Maven packages. Overall, our approach achieves an accuracy of up to 99.5% when compared field-by-field to the existing manual approach [and] we reveal that automatic reproducibility is feasible for 23.4% of the Maven packages using AROMA, and 8% of these packages are fully reproducible.
Nichita Morcotilo reached out to the community, first to share their efforts “to build reproducible packages cross-platform with a new build tool called rattler-build, noting that “as you can imagine, building packages reproducibly on Windows is the hardest challenge (so far!)”. Nichita goes onto mention that the Apple ecosystem appears to be using ZERO_AR_DATE over SOURCE_DATE_EPOCH. […]
Roland Clobus announced that the Debian bookworm 12.6 live images are “nearly reproducible”, with more detail in the post itself and input in the thread from other contributors.
Daniel Gröber asked for help in getting the Yosys documentation to build reproducibly, citing issues in inter alia the PDF generation causing differing CreationDate metadata values.
James Addison continued his long journey towards getting the Sphinx documentation generator to build reproducible documentation. In this thread, James concerns himself with the problem that even “when SOURCE_DATE_EPOCH is configured, Sphinx projects that have configured their copyright notices using dynamic elements can produce nonsensical output under some circumstances.” James’ query ended up generating a number of replies.
Allen ‘gunner’ Gunner posted a brief update on the progress the core team is making towards introducing a Code of Conduct (CoC) such that it is “in place in time for the RB Summit in Hamburg in September”. In particular, gunner asks “if you are interested in helping with CoC design and development in the weeks ahead, simply email [email protected] and let us know”. […]
[S]oftware repositories are a vital component of software development and release, with packages downloaded both for direct use and to use as dependencies for other software. Further, when software is updated due to patched vulnerabilities or new features, it is vital that users are able to see and install this patched version of the software. However, this process of updating software can also be the source of attack. To address these attacks, secure software update systems have been proposed. However, these secure software update systems have seen barriers to widespread adoption. The Update Framework (TUF) was introduced in 2010 to address several attacks on software update systems including repository compromise, rollback attacks, and arbitrary software installation. Despite this, compromises continue to occur, with millions of users impacted by such compromises. My work has addressed substantial challenges to adoption of secure software update systems grounded in an understanding of practical concerns. Work with industry and academic communities provided opportunities to discover challenges, expand adoption, and raise awareness about secure software updates. […]
Fay Stegerman performed some in-depth research surrounding her apksigcopier tool, after some Android .apk files signed with the latest apksigner could no longer be verified as reproducible. Fay identified the issue as follows:
Since build-tools >= 35.0.0-rc1, backwards-incompatible changes to apksigner break apksigcopier as it now by default forcibly replaces existing alignment padding and changed the default page alignment from 4k to 16k (same as Android Gradle Plugin >= 8.3, so the latter is only an issue when using older AGP). […]
Lastly, diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb uploaded version 272 and Mattia Rizzolo uploaded version 273 to Debian, and the following changes were made as well:
Chris Lamb:
Ensure that the convert utility is from ImageMagick version 6.x. The command-line interface has seemingly changed with the 7.x series of ImageMagick. […]
Factor out version detection in test_jpeg_image. […]
Correct the import of the identify_version method after a refactoring change in a previous commit. […]
Move away from using DSA OpenSSH keys in tests as support has been deprecated and removed in OpenSSH version 9.8p1. […]
Move to assert_diff in the test_openssh_pub_key package. […]
There were a number of improvements made to our website this month, including:
Bernhard M. Wiedemann updated the SOURCE_DATE_EPOCH page to include instructions on how to create reproducible .zip files from within Python using the zipfile module. […]
Chris Lamb fixed a potential duplicate heading on the Projects page. […]
Fay Stegerman added rbtlog to the Tools page […] and IzzyOnDroid to the Projects page […], also ensuring that the latter page was always sorted regardless of the ordering within the input data files. […]
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:
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 July, a number of changes were made by Holger Levsen, including:
Perform a dummy change to force update of all jobs. […][…]
In addition, Vagrant Cascadian performed some necessary node maintenance of the underlying build hosts. […]
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:
I’m finishing typing up this blog entry hours before my last 13 hour leg back home, after I spent 2 weeks in Busan, South Korea for DebCamp24 and DebCamp24. I had a rough year and decided to take it easy this DebConf. So this is the first DebConf in a long time where I didn’t give any talks. I mostly caught up on a bit of packaging, worked on DebConf video stuff, attended a few BoFs and talked to people. Overall it was a very good DebConf, which also turned out to be more productive than I expeced it would.
In the welcome session on the first day of DebConf, Nicolas Dandrimont mentioned that a benefit of DebConf is that it provides a sort of caffeine for your Debian motivation. I could certainly feel that affect swell as the days went past, and it’s nice to be excited about some ideas again that would otherwise be fading.
Recovering DPL
It’s a bit of a gear shift being DPL for 4 years, and DebConf Committee for nearly 5 years before that, and then being at DebConf while some issue arise (as it always does during a conference). At first I jump into high alert mode, but then I have to remind myself “it’s not your problem anymore” and let others deal with it.
It was nice spending a little in-person time with Andreas Tille, our new DPL, we did some more handover and discussed some current issues. I still have a few dozen emails in my DPL inbox that I need to collate and forward to Andreas, I hope to finish all that up by the end of August.
During the Bits from the DPL talk, the usual question came up whether Andreas will consider running for DPL again, to which he just responded in a slide “Maybe”. I think it’s a good idea for a DPL to do at least two terms if it all works out for everyone, since it takes a while to get up to speed on everything.
Also, having been DPL for four years, I have a lot to say about it, and I think there’s a lot we can fix in the role, or at least discuss it. If I had the bandwidth for it I would have scheduled a BoF for it, but I’ll very likely do that for the next DebConf instead!
Video team
I set up the standby loop for the video streaming setup. We call it loopy, it’s a bunch of OBS scenes that provide announcements, shows sponsors, the schedule and some social content. I wrote about it back in 2020, but it’s evolved quite a bit since then, so I’m probably due to write another blog post with a bunch of updates on it. I hope to organise a video team sprint in Cape Town in the first half of next year, so I’ll summarize everything before then.
It would’ve been great if we could have some displays in social areas that could show talks, the loop and other content, but we were just too pressed for time for that. This year’s DebConf had a very compressed timeline, and there was just too much that had to be done and that had to be figured out on the last minute. This put quite a lot of strain on the organisers, but I was glad to see how, for the most part, most attendees were very sympathetic to some rough edges (but I digress…).
I added more of the OBS machine setup to the videoteam’s ansible repository, so as of now it just needs an ansible setup and the OBS data and it’s good to go. The loopy data is already in the videoteam git repository, so I could probably just add a git pull and create some symlinks in ansible and then that machine can be installed from 0% to 100% by just installing via debian-installer with our ansible hooks.
This DebConf I volunteered quite a bit for actual video roles during the conference, something I didn’t have much time for in recent DebConfs, and it’s been fun, especially in a session or two where nearly none of the other volunteers showed up. Sometimes chaos is just fun :-)
Baekyongee is the university mascot, who’s visible throughout the university. So of course we included this four legged whale creature on the loop too!
Packaging
I was hoping to do more packaging during DebCamp, but at least it was a non-zero amount:
Uploaded gdisk 1.0.10-2 to unstable (previously tested effects of adding dh-sequence-movetousr) (Closes: #1073679).
Worked a bit on bcachefs-tools (updating git to 1.9.4), but has a build failure that I need to look into (we might need a newer bindgen) – update: I’m probably going to ROM this package soon, it doesn’t seem suitable for packaging in Debian.
Calamares: Tested a fix for encrypted installs, and uploaded it.
Calamares: Uploaded (3.3.8-1) to backports (at the time of writing it’s still in backports-NEW).
Pixelorama 1.0 – I did some initial packaging for Pixelorama back when we did the MiniDebConf Gaming Edition, but it had a few stoppers back then. Version 1.0 seems to fix all of that, but it depends on Godot 4.2 and we’re still on the 3 series in Debian, so I’ll upload this once Godot 4.2 hits at least experimental. Godot software/games is otherwise quite easy to run, it’s basically just source code / data that is installed and then run via godot-runner (godot3-runner package in Debian).
The session ended up being extended to a second part, since all the issues didn’t fit into the first session.
I was distracted by too many thing during the Python 3.12 transition (to the point where I thought that 3.11 was still new in Debian), so it was very useful listening to the retrospective of that transition.
There was a discussion whether Python 3.13 could still make it to testing in time for freeze, and it seems that there is consensus that it can, although, likely with new experimental features like disabling the global interpreter lock and the just in time compiler disabled.
I learned for the first time about the “dead batteries” project, PEP-0594, which removes ancient modules that have mostly been superseded, from the Python standard library.
There was some talk about the process for changing team policy, and a policy discussion on whether we should require autopkgtests as a SHOULD or a MUST for migration to testing. As with many things, the devil is in the details and in my opinion you could go either way and achieve a similar result (the original MUST proposal allowed exceptions which imho made it the same as the SHOULD proposal).
There’s an idea to do some ongoing remote sprints, like having co-ordinated days for bug squashing / working on stuff together. This is a nice idea and probably a good way to energise the team and also to gain some interest from potential newcomers.
Louis-Philipe Véronneau was added as a new team admin and there was some discussion on various Sphinx issues and which Lintian tags might be needed for Python 3.13. If you want to know more, you probably have to watch the videos / read the notes :)
Debian Developers can set up services on subdomains on debian.net, but a big problem we’ve had before was that developers were on their own for hosting those services. This meant that they either hosted it on their DSL/fiber connection at home, paid for the hosting themselves, or hosted it at different services which became an accounting nightmare to claim back the used funds. So, a few of us started the debian.net hosting project (sometimes we just call it debian.net, this is probably a bit of a bug) so that Debian has accounts with cloud providers, and as admins we can create instances there that gets billed directly to Debian.
We had an initial rush of services, but requests have slowed down since (not really a bad thing, we don’t want lots of spurious requests). Last year we did a census, to check which of the instances were still used, whether they received system updates and to ask whether they are performing backups. It went well and some issues were found along the way, so we’ll be doing that again.
We also gained two potential volunteers to help run things, which is great.
Pleroma has shown some cracks over the last year or so, and there are some forks that seem promising. At the same time, it might be worth while considering Mastodon too. So we’ll do some comparison of features and maintenance and find a way forward. At the time when Pleroma was installed, it was way ahead in terms of moderation features.
Pixelfed is doing well and chugging along nicely, we should probably promote it more.
Peertube is working well, although we learned that we still don’t have all the recent DebConf videos on there. A bunch of other issues should be fixed once we move it to a new machine that we plan to set up.
We’re removing writefreely and plume. Nice concepts, but it didn’t get much traction yet, and no one who signed up for these actually used it, which is fine, some experimentation with services is good and sometimes they prove to be very popular and other times not.
The WordPress multisite instance has some mild use, otherwise haven’t had any issues.
Matrix ended up to be much, much bigger than we thought, both in usage and in its requirements. It’s very stateful and remembers discussions for as long as you let it, so it’s Postgres database is continuously expanding, this will also be a lot easier to manage once we have this on the new host.
Jitsi is also quite popular, but it could probably be on jitsi.debian.net instead (we created this on debian.social during the initial height of COVID-19 where we didn’t have the debian.net hosting yet), although in practice it doesn’t really matter where it lives.
Most of our current challenges will be solved by moving everything to a new big machine that has a few public IPs available for some VMs, so we’ll be doing that shortly.
Debian Foundation Discussion BoF
This was some brainstorming about the future structure of Debian, and what steps might be needed to get there. It’s way too big a problem to take on in a BoF, but we made some progress in figuring out some smaller pieces of the larger puzzle. The DPL is going to get in touch with some legal advisors and our trusted organisations so that we can aim to formalise our relationships a bit more by the time it’s DebConf again.
I also introduced my intention to join the Debian Partners delegation. When I was DPL, I enjoyed talking with external organisations who wanted to help Debian, but helping external organisations help Debian turned out to be too much additional load on the usual DPL roles, so I’m pursuing this with the Debian Partners team, more on that some other time.
This session wasn’t recorded, but if you feel like you missed something, don’t worry, all intentions will be communicated and discussed with project members before anything moves forward. There was a strong agreement in the room though that we should push forward on this, and not reach another DebConf where we didn’t make progress on formalising Debian’s structure more.
Social
Conference Dinner
Conference Dinner Photo from Santiago
The conference dinner took place in the university gymnasium. I hope not many people do sports there in the summer, because it got HOT. There was also some interesting observations on the thermodynamics of the attempted cooling solutions, which was amusing. On the plus side, the food was great, the company was good, and the speeches were kept to a minimum, so it was a great conference dinner, even though it was probably cut a bit short due to the heat.
Cheese and Wine
Cheese and Wine happened on 1 August, which happens to be the date I became a DD at DebConf17 in Montréal seven years before, so this was a nice accidental celebration of my Debiversary :)
Since I’m running out of time, I’ll add some more photos to this post some time after publishing it :P
Group Photo
As per DebConf tradition, Aigars took the group photo. You can find the high resolution version on Debian’s GitLab instance.
Debian annual conference Debconf 24, Busan, South Korea Photography: Aigars Mahinovs [email protected] License: CC-BYv3+ or GPLv2+
Talking
Ah yes, talking to people is a big part of DebConf, but I didn’t keep track of it very well.
I mostly listened to Alper a bit about his ideas for his talk about debian installer.
I talked to Rhonda a bit about ActivityPub and MQTT and whether they could be useful for publicising Debian activity.
Listened to Gunnar and Julian have a discussion about GPG and APT which was interesting.
We had the usual continuous keysigning party. Besides it’s intended function, this is always a good ice breaker and a way to for shy people to meet other shy people.
… and many other fly-by discussions.
Stuff that didn’t happen this DebConf
loo.py – A simple Python script that could eventually replace the obs-advanced-scene-switcher sequencer in OBS. It would also be extremely useful if we’d ever replace OBS for loopy. I was hoping to have some time to hack on this, and try to recreate the current loopy in loo.py, but didn’t have the time.
toetally – This year videoteam had to scramble to get a bunch of resistors to assemble some tally light. Even when assembled, they were a bit troublesome. It would’ve been nice to hack on toetally and get something ready for testing, but it mostly relies on having something like a rasbperry pi zero with an attached screen in order to work on further. I’ll try to have something ready for the next mini conf though.
extrepo on debian live – I think we should have extrepo installed by default on desktop systems, I meant to start a discussion on this, but perhaps it’s just time I go ahead and do it and announce it.
Live stream to peertube server – It would’ve been nice to live stream DebConf to PeerTube, but the dependency tree to get this going got a bit too huge. Following our plans discussed in the Debian Social BoF, we should have this safely ready before the next MiniDebConf and should be able to test it there.
Desktop Egg – there was this idea to get a stand-in theme for Debian testing/unstable until the artwork for the next release is finalized (Debian bug: #1038660), I have an idea that I meant to implement months ago, but too many things got in the way. It’s based on Juliette Taka’s Homeworld theme, and basically transforms the homeworld into an egg. Get it? Something that hasn’t hatched yet? I also only recently noticed that we never used the actualhomeworld graphics (featuring the world image) in the final bullseye release. lol.
So, another DebConf and another new plush animal. Last but not least, thanks to PKNU for being such a generous and fantastic host to us! See you again at DebConf25 in Brest, France next year!
DebConf24 is now over! I'm very happy I was able to attend this year. If
you haven't had time to look at the schedule yet, here is a
selection of talks I liked.
What happens if I delete setup.py?: a live demo of upgrading to PEP-518 Python packaging
A great talk by Weezel showcasing how easy it is to migrate to PEP-518 for
existing Python projects.
This is the kind of thing I've been doing a lot when packaging upstream
projects that still use setup.py. I encourage you to send this kind of patch
upstream, as it makes everyone's life much easier.
Debian on Chromebooks: What's New and What's Next?
A talk by Alper Nebi Yasak, who has done great work on running Debian and the
Debian Installer on Chromebooks.
With Chromebooks being very popular machines in schools, it's nice to see people
working on a path to liberate them.
Sequoia PGP, sq, gpg-from-sq, v6 OpenPGP, and Debian
I had the chance to see Justus' talk on Sequoia — an OpenPGP implementation in
Rust — at DebConf22 in Kosovo. Back then, the conclusion was that
sq wasn't ready for production yet.
Well it seems it now is! This in-depth talk goes through the history of the
project and its goals. There is also a very good section on the current
OpenPGP/LibrePGP schism.
Chameleon - the easy way to try out Sequoia - OpenPGP written in Rust
A very short talk by Holger on Chameleon, a tool to make migration to Sequoia
easier.
TL;DW: apt install gpg-from-sq
Protecting OpenPGP keyservers from certificate flooding
Although I used to enjoy signing people's OpenPGP keys, I completely gave up on
this practice around 2019 when dkg's key was flooded with bogus
certifications and have been refusing to do so since.
In this talk, Gunnar talks about his PhD work on fixing this issue and making
sure we can eventually restore this important function on keyservers.
Bits from the DPL
Bits from the DPL! A DebConf classic.
Linux live patching in Debian
Having to reboot servers after kernel upgrades is a hassle, especially with
machines that have encrypted disk drives.
Although kernel live patching in Debian is still a work in progress, it is
encouraging to see people trying to fix this issue.
"I use Debian BTW": fzf, tmux, zoxide and friends
A fun talk by Samuel Henrique on little changes and tricks one can make to
their setup to make life easier.
Ideas to Move Debian Installer Forward
Another in-depth talk by Alper, this time on the Debian Installer and his ideas
to try to make it better. I learned a lot about the d-i internals!
Lightning Talks
Lighting talks are always fun to watch! This year, the following talks happened:
Customizing your Linux icons
A Free Speech tracker by SFLC.IN
Desktop computing is irrelevant
An introduction to wcurl
Aliasing in dpkg
A DebConf art space
Tiny Tapeout, Fomu, PiCI
Data processing and visualisation in the shell
Is there a role for Debian in the post-open source era?
As an economist, I've been interested in Copyright and business models in the
Free Software ecosystem for a while. In this talk, Hatta-san and Bruce Perens
discuss the idea of alternative licences that are not DFSG-free, like
Post-Open.