Hoffentlich bringt Debian nächstes Wochende auch so viel Energie nach Innsbruck.

Event 16.–18. Mai: https://wiki.debian.org/DebianEvents/de/2025/MountainCamp

Es ist noch genug platz für interessierte kreaturen. Aber vorsicht: Wer ohne Bugs kommt wird nicht ohne wieder gehen 🐞.

Bild: mini DebConf Hamburg letzte woche.

No, I do not want to install your app.

No, I do not want that app to run on startup.

No, I do not want that app shortcut on my desktop.

No, I do not want to subscribe to your newsletter.

No, I do not want your site to send me notifications.

No, I do not want to tell you about my recent experience.

No, I do not want to sign up for an account.

No, I do not want to sign up using a different service and let the two of you know about each other.

No, I do not want to sign in for a more personalized experience.

No, I do not want to allow you to read my contacts.

No, I do not want you to scan my content.

No, I do not want you to track me.

No, I do not want to click "Later" or "Not now" when what I mean is NO.

in german we don't say "techbro", we say "Wirtschaftsinformatik"

So, it’s the file tool on my machine. Tracked it down to:

file sdk/sysroots/x86_64-pokysdk-linux/lib/libc.so.6
*** buffer overflow detected ***: terminated
Bad system call (core dumped)

Definitely not my day…

Extracting SDK......................................................................................................................................................................................................................................................................done Setting it up...*** buffer overflow detected ***: terminated xargs: file: terminated by signal 31 sed: no input files Failed to replace perl. Relocate script failed. Abort!

@ross I'm not sure, I see such long lasting builds on many different machines and Yocto setups. This is also a common complaint I get from customers as soon they need clang/LLVM for whatever reason.
In this case it is Styhead build for AArch64.
What do you suggest to speed it up? According to monitoring it's pure CPU bound.

Home made burger buns

This is why I hate clang so much. It turns Yocto builds into a build time nightmare. ;-)

P.s. This is a *fast* machine. 24 Intel Xeon cores.

Sempervivum arachnoideum

#FOSS

Inline-asm poll.

GCC is looking how to improve __builtin_unreachable behavior by maybe expanding it to a trap instruction instead of following through to the next function.

So the original reason why __builtin_unreachable[https://gcc.gnu.org/PR39252] was added was to mark inline-asm as not "returning" for use inside the Linux Kernel.
There was an old patch (https://gcc.gnu.org/legacy-ml/gcc-patches/2000-01/msg00190.html) which adds "pc" as a clobber to do it too.
Though with the raise of attributes, maybe it is better to use an attribute on the inline-asm.

So the poll is what syntax would be better.

Please spread this wide. I will doing a more formal poll on both GCC's mailing list and LLVM discourse next week after this informal poll is finished but I want to get some ideas/inputs here first before I submit a RFC. I will implementing the GCC side of things and hope someone on the LLVM will pickup the LLVM side.

This happens all of a sudden with qemu-aarch64. Used to work three weeks ago. :-/

# dpkg-deb --show zlib1g_1%3a1.2.13.dfsg-1_arm64.deb
dpkg-deb: error: <decompress> subprocess was killed by signal (Segmentation fault), core dumped

Got a cool t-shirt from @linuxtage
#glt25

@zev @paulmckrcu
well, I have downloaded the high resolution scan from archive.org and bought a print online.

Just arrived. Need to find a good place in the office.

Bootloaders are fun. 😬

https://sigma-star.at/blog/2025/01/filesystem-vulnerabilities-in-bootloaders-a-hidden-risk-for-verified-boot-mechanisms/

Open Letter to Mark Zuckerberg

Reinstalled my laptop and upgraded to KDE Plasma 6. After a while, I noticed that mail search in KMail no longer works. Reading Akonadi logs revealed this gem. I’m no Akonadi expert, but creating an SQL statement with 40k variables does not seem wise to me. Guess how many mails I have in my inbox?

org.kde.pim.akonadiserver: Handler exception when handling command FetchItems on 
connection  akonadi_indexing_agent (0x56536e3d9e50) : Failed to query database
org.kde.pim.akonadi_indexer_agent: Failed to fetch items:  "Failed to query database"
org.kde.pim.akonadi_indexer_agent: Indexing failed:  ""
org.kde.pim.akonadiserver: DATABASE ERROR while PREPARING QUERY:
org.kde.pim.akonadiserver:   Error code: "1"
org.kde.pim.akonadiserver:   DB error:  "too many SQL variables"
org.kde.pim.akonadiserver:   Error text: "too many SQL variables Unable to execute statement"
org.kde.pim.akonadiserver:   Query: "SELECT DISTINCT ResourceTable.name FROM
PimItemTable  LEFT JOIN CollectionTable ON ( PimItemTable.collectionId = CollectionTable.id )
 LEFT JOIN ResourceTable ON ( CollectionTable.resourceId = ResourceTable.id ) WHERE (
PimItemTable.id IN ( :0, :1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13,
 :14, :15, :16, :17, :18,  :19, :20, :21, :22, :23, :24, :25, :26, :27, :28, 
:29, :30, :31, :32, :33, :34, :35, :36, :37, :38, :39, :40, :41, :42, :43, 
:44, :45, :46, :47, :48, :49, :50, :51, :52, :53, :54, :55, :56, :57, :58,
:59, :60, :61, :62, :63, :64, :65, :66, :67, :68, :69, :70, :71, :72,
...
...MANY...MORE...
...
:44273, :44274, :44275, :44276, :44277, :44278, :44279, :44280, :44281, :44282, :44283, 
:44284, :44285, :44286, :44287, :44288, :44289, :44290, :44291, :44292, :44293, :44294, 
:44295, :44296, :44297, :44298, :44299, :44300 ) )"
org.kde.pim.akonadiserver: Handler exception when handling command FetchItems on
 connection akonadi_indexing_agent (0x56536e3d9e50) : Failed to query database
org.kde.pim.akonadi_indexer_agent: Failed to fetch items:  "Failed to query database"

Having reasonably large mailboxes is no longer a thing, is it? 😞

Edit: Broke lines.

Judging from the absolutely packed out rust sessions I went to at LPC and the very positive support from senior people including especially @gregkh it is super clear to me that rust is here to stay in the kernel and a big part of its future.

Have offered to help (or at least be cc'd in hopes I have time for it :) on mm binding stuff fwiw from the kernel side.

And also I really do have to sit down with rust finally... Maybe advent of code this year...

🐧