I think this shows how @linuxfoundation is not necessarily on our side.

https://social.lfx.dev/@linuxfoundation/114993371357953940

Oh no!

@bagder couldn't convince Emerson to shut up about CRAs, so they are now mailing debian-devel@

And here I am, wanted to cut down on the 🍿 this month.

https://lists.debian.org/debian-devel/2025/08/msg00108.html

The "good" people at Emerson for some reason couldn't think for themselves when I responded to them on behalf of #curl and instead continue and send the same questions to the #libssh2 project with the same "demands".

"This is a gentle reminder regarding our earlier request for your input on the cybersecurity risk assessment of the software component “libssh2” version 1.11.0, as part of our compliance efforts with the EU Cyber Resilience Act (CRA)."

From my today's review list of patches for Devicetree bindings in Linux, two very poor quality submissions had weird pieces. Pieces which do not exist in usptream EVER. But I could imagine someone used AI tools to generate the bindings based on DTS. That would explain a lot... so it started. :/

There will be a Devicetree Microconference on Linux Plumbers in Tokyo, covering wide range of topics for Devicetree-based systems. The Call For Proposals is still open and you can submit your talk choosing "Devicetree MC" as the track. More details with examples of topics (not limited to these!): https://lpc.events/event/19/contributions/2008/

We started getting patches for Linux kernel with GPL-4.0 and GPL-6.0 license... Yes! GPL-4.0 and GPL-6.0!
https://lore.kernel.org/all/?q=GPL-4.0
https://lore.kernel.org/all/?q=GPL-6.0-only

Let's guess what was that:

Open Source Summit Europe 2025 is coming (in August)!

I will speak about two Linux kernel topics on introductory level, so if you want to learn something practical about Devicetree or using static analysis during development in Linux kernel then please come or watch online.

If you want to come and ask questions just find me around the hall or after the talks. We can also organize Unconference Session if there are more Devicetree topics.

1. DTS 101: From Roots To Trees, Aka Devicetree for Beginners
https://sched.co/25Vsl

2. Between Building and Testing Your Linux Driver
https://sched.co/25VoV

The Wayback Machine managed to capture a Linux Journal article about the Arch Linux distribution's plan to switch to "rye-init" before whatever human intelligence remains there figured out that "rye-init" does not actually exist.

The Linux Journal predates LWN by some years and was, for a long time, the definitive read for Linux users. The Don Marti ( @dmarti ) years were especially noteworthy. It is sad to see where it has ended up now.

https://web.archive.org/web/20250618001301/https://www.linuxjournal.com/content/arch-linux-breaks-new-ground-official-rust-init-system-support-arrives

If you are on-site or virtual attendee of Linaro Connect 25 in Lisbon, join me and Google Landing Team today at 5 PM (Lisbon time) to see what is cooking in Samsung Exynos SoC and Google Pixel SoC in the upstream Linux kernel:
https://www.kitefor.events/events/linaro-connect-2025/submissions/307
... or just read the slides linked above! :)

We are doing our utmost to strengthen Ukraine's hand.

We've disbursed the fourth €1 billion tranche of our exceptional Macro-Financial Assistance loans.

This funding supports urgent military needs and will be repaid using proceeds from immobilised Russian state assets in the EU.

With this, the EU strengthens its role as Ukraine’s top donor since the full-scale invasion.

Our support to Ukraine is unwavering. We stay ready to respond swiftly to any further requests.

→ https://europa.eu/!P6YwqY

I think many kernel developers - including myself, a long time ago - believe that becoming a Linux kernel maintainer is a difficult process. As if some secret group has to choose you, you need to prove yourself, and then a Masonic lodge will select the best candidates from a huge pool of competition.

That's simply not true. Becoming a Linux kernel maintainer is actually quite easy.

The difficulty lies in staying one.

Every now and then, I notice subsystems that need more maintainers. Do you want to be one?

Of course taking maintainership position and being a true maintainer are a bit different things, but I hope you get the point...

Today's misinformation provided by Google Search's "AI Overview" (which cannot be disabled, apparently):
"All EU member states are parties to the Rome Statute, except for Turkey."

(I am not complaining that the AI missed today's withdrawal of Hungary)

2024 was a record-breaking year for forest fires in Ukraine.

This is another devastating consequence of Russia’s illegal invasion.

Nearly one million hectares were burnt in the country – more than twice the area burned in the EU in the same period.

The EU is committed to helping Ukrainians strengthen their rescue and fire services by providing them with machinery and protective equipment.

With Ukraine – and its brave firefighters – unflinchingly.

ℹ️ https://europa.eu/!fxW7MD

#EU

I sent a simple, yet not the shortest, DT bindings patch for the Linux kernel. I got five review tags in response, for which I thank you, however three (60%) of them where in format:

> My commit msg...
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Reviewed-by: Mr. Foo

> here goes
> my ...
> entire patch
> for su knows how long.
> Really long!

I was complaining about this on the lists already. I am not going to, heh, no one should be to, scroll through entire message to check whether there was something after that Reviewed-by tag. Or after comment.

Knowing that it is trivial to remove unneeded context (see below), I find that just disrespectful to me and my time.

I am going to ignore EVERYTHING from something which looks like end of message. if you put there something, your problem.

E.g. if one uses mutt and vim - that's part of your alias:
```
nmap <silent> <leader>A :.,$d<CR>A<CR><CR>Acked-by: Krzysztof Kozlowski <krzk@kernel.org><CR><CR>Best regards,<CR>Krzysztof<CR><ESC>
```

ZTE or zte.com.cn apparently decided to flood kernel with extremely poor quality, automated patches. Reminds me previous flood from Vivo.com. Some of the patches were never built and clearly do not compile. Some are looking correct, but are wrong if you open the context of the file (e.g. using sysfs_emit in procfs or some other code). None of the review feedbacks were responded to, they just keep sending the code, sometimes 5 same patches without noticeable changes or without changelog.

And I bet somewhere within this flood of automation-generated stuff, is actual fix or actual bug pretending to be a fix but introducing a vulnerability.

When Trump says that he can apply economic pressure on Putin, he's lying. He has very few levers that haven't already been pushed. Using his own analogy, Trump acts like he has an ace up his sleeve, but he only has a pair of jokers. The only sure way to apply pressure on Putin is to give Ukraine all they need to win on the battlefield.

If #Ukraine really did attack #Twitter, | think the only logical thing is for #Elon to sign a cease fire immediately, give them half of Twitter and make sure he says thank you.

Good morning to readers; #Kyiv remains in Ukrainian hands.

#Ukraine helped the U.S. in its invasion of Iraq, losing 18 of its own men.

But when #Kyiv needed help, the U.S. leveraged Ukraine's weakness.

Serhii, who served in Iraq, knows the risks of allying with the U.S.

PSA: please don't use git.kernel.org directly for your CI needs. It is not viable for us to provide enough capacity to withstand dozens of CI nodes all trying to clone linux.git at the same time for multiple CI farms. You *will* get ip-blocked. Please set up a local mirror and hit that instead.