Continuing PyTorch / Linux Foundation database of harvested emails and sending advertisements to them - https://social.kernel.org/notice/B3bhz39OUEdNndylVI

Linux Foundation apologized for "internal marketing operations error" and that "Your email address, along with those of other kernel maintainers, was included in a dataset from a third-party data provider that was improperly imported into our marketing systems without consent verification."

No name for 3rd party provider was given, so GDPR cannot follow to that provider, though...

Linux Foundation also stated they were executing a "permanent deletion". That was 5th of March.

However today I got message from other kernel maintainer, who just got spam/advertisement from the PyTorch Foundation. So saga keeps going.

Maybe they removed only my address from the harvested list. :)

@manut In case you did not find it so far, this might be useful:
https://github.com/guillemj/debian-pkg-neard
https://github.com/sameo/neard-deb.git
And the last packaging for Ubuntu: https://launchpad.net/ubuntu/+source/neard

@manut Awesome, thanks!

New release: neard v0.20, the user-space counterpart of Linux NFC stack

The release includes a few minor fixes.

Source code release:
https://web.git.kernel.org/pub/scm/network/nfc/neard.git/tag/?h=v0.20
https://web.git.kernel.org/pub/scm/network/nfc/neard.git/snapshot/neard-0.20.tar.gz

I should have released it much earlier, though. I think this release thanks to Mark Greer finally dumps Python 2 dependency - last blocker of packaging for Debian. Anyone would like to revive the Debian package?

@cynicalsecurity @tobhe OK, thanks for confirming.

@cynicalsecurity @tobhe If I correctly see in OpenBSD ports, around November DTS was moved from v6.15 to v6.17. In the kernel that was quite an update and T14s got proper USB description (retimers), DisplayPort support and few more less impactful changes. X1E SoC got SCMI cpufreq and several PCI improvements, but nothing stands out as something having ABI impact, so maybe we did not break there anything...

@cynicalsecurity @tobhe If you can replace the DTBs from booted USB stick, then please try older versions, e.g. v6.16. If that confirms that DTS/DTB is the problem, then bisecting would be useful. The sources are taken from:
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/snapshot/ and currently at v6.17 in OpenBSD Makefile.

@kernellogger Did he just propose PGP/GnuPG web-of-trust? Isn't this like a 30 year old thing?

Updated guideline: https://social.kernel.org/notice/B4DukxPLisztLVWuEi

Since a year we got some contributions for converting Devicetree bindings from TXT to DT schema as part of some sort mentorship programs (e.g. GSoC). This is great although leads to some misunderstandings in that work, considering mentorships did not ask DT maintainers about some sort of guidance. To clarify:

1. Please convert bindings which have active DTS users. First choose bindings with DTS built by arm64 defconfig, then next choice by arm multi_v7 defconfig. Then any other ARM or different architecture DTS.

2. Be sure dt_binding_check (including yamllint) and checkpatch pass without any warnings. See writing-schema.rst document.

3. Be sure that all DTS files using this binding pass dtbs_check validation. If this means binding needs to be adapted during conversion, mention briefly in commit message changes done comparing to pure TXT->DT schema conversion. Sometimes DTS has to be fixed. Sometimes both - DTS and binding - must be changed, because actual ABI (Linux drivers) is different.

4. Do not send conversions of TXT bindings in staging, because these need to follow standard review process. Bindings in staging are not considered accepted/reviewed DT ABI.

5. Don't ever send output of LLM microslop tools. It's pointless and brings no benefits to the community. Rob already converted all TXT bindings with LLM, so why you doing this again would be beneficial to anyone?

6. Read also Rob's expectations and hints:
https://lore.kernel.org/linux-devicetree/CAL_JsqJp133hGSkja9tabtsE9D7MSA9JErVkmkcy91piHMgfwg@mail.gmail.com/

This is an updated guideline from 2025 https://social.kernel.org/notice/Ai9hYRUKo8suzX3zNY .

I think the graph is not the best representing the phenomena. Probably accuracy = 1.0 is possible only when amount of properties = 0, because even with one property there is a chance employee won't bother enough to input it right knowing how terrible tool JIRA is. IOW, filling even one property to a task in JIRA is such a terrible experience, that people likely will put random data just to shorten the exposure to this horrible interface.

The accuracy of information added to Jira tasks by employees is inversely proportional to amount of detailed information being asked by managers to put there. So called overeager manager law, aka krzk's principle.

@lwn I love the timeline of initial disclosure to Cline:
https://adnanthekhan.com/posts/clinejection/#timeline

"January 1st, 2026: GHSA submitted via private vulnerability reporting on github.com/cline/cline. Same day, email sent to security@cline.bot ..."

January 8th, 2026: Follow-up email sent ... No response received to my email.

January 18th, 2026: Attempted direct message to Cline’s CEO on X with request to review the GHSA containing technical details. No response.

February 7th, 2026: Final attempt — new email to security@cline.bot, no response...

February 9th, 2026: Public disclosure via blog post."

Can we agree that Cline screwed so badly they should never be trusted again as software vendor? Ah, who am I kiddin, that's probably SW workflows managed by AI, so no one cares...

@broonie @monsieuricon Yep, most of them had at least one useful comment. The problem is that if SoC platform maintainer sends review with three comments of which two are correct and one is wrong, how can an unaware contributor figure out which one is right...
Well, the one about the copyright time is obvious and it simply should not have been sent.

Review on mailing list:

Copyright (C) 2026 Variscite Ltd. AI bot review and may be useless.

Copyright year is 2026, which is in the future. Should be 2024 or current year.

Great, now everyone will get to read useless AI agent reviews.

https://lore.kernel.org/all/20260303210131.2966214-8-Frank.Li@nxp.com/

@geert I'll Cc you on my complain / discussion with LF.

@z3ntu Crappy hell, what a PyTorch mess.

@okias There should be a "I am a tourist" checkbox when doing reviews :)

Every Google Maps review score in Germany is fake. Believe me.

Well, it does not have to be truly fake, but because of lack of negative reviews, what you have is score built only on positive experiences + advertisements.

Two of my honest, not defaming, describing real experience, negative (1-star and 2-star) reviews of two places in Munich from some visit in 2023 got removed by "defamation" process. It's the process where you as customer can do nothing, your review will be gone and Google will completely ignore your appeals.

I can assume that many or even most of negative reviews older than 2 years will be just removed by Google using this German defamation process, leaving only positive ones.

In the same time these places have many 5-star review written by agencies, posting similar AI-generated ludicrously exaggerated poetry, which obviously no one will ever drop, because they are not a defamation.

So please remember - Google Maps in Germany is full of crap reviews.

@geert And PyTorch needed it for ... ? :)