Please add your agenda items to our pad for the meeting minutes, so we know beforehand if there is anything to discuss (some people decide their attendance on that).
Please add your agenda items to our pad for the meeting minutes, so we know beforehand if there is anything to discuss (some people decide their attendance on that).
Please add your agenda items to our pad for the meeting minutes, so we know beforehand if there is anything to discuss (some people decide their attendance on that).
Removal of desvirt #22724: Yes, No, Maybe? (crasbe)
Seems unmaintained since it was added in 2016
desvirt received last update 4 years ago by Oleg
Still needs python2, which is no longer available in our Docker
What even is desvirt?
Oleg provides some insights:
I do have an opinion on desvirt though (independent from its Python version): I think very few people in the current RIOT community know about desvirt, what it can do and how to use it. Code and documentation are in a bad spot and IIRC Ben introduced some framework that provides similar functionality.
For the record: desvirt provides some scripts to define a network topology. One can define nodes and links. For the nodes you can choose a RIOT application and it will spawn the corresponding native instance. For the links you can define a PDR and whether the link is uni- or bidirectional. It uses ebtables and tc for traffic shaping.
I used it during my PhD to emulate RIOT networks with up to 1000 nodes. (1000 is the max. number of TAP devices a Linux bridge can handle in the default Kernel configuration.)
Long story short, I consider it useful but only if anyone finds the time to maintain the code base and document it. Since I havenât been able to do this for the last 10+ years, I consider it unlikely and would vote pro removing it.
Ann: In another project we had a similar with a python 2 tool but since Python 2 has become this EOL (Over 6 years by now) at this point, Iâd say the minimum baseline is that a tool can not be on Python 2 anymore, at least it should use some abstraction if possible to make it runnable using Python 3 (though idk whether these are still even maintained/exist at this point)
Should auto_init_foo have foo as a dependency?
Teufelchen encountered a user that was using auto_init_gnrc_netif but not gnrc who was confused why it wasnât working as intended. => Major UX issue.
Teufelchen made a poll on Matrix/RIOT:
Without looking it up, what is your gut feeling: If I add auto_init_gnrc_netif to my USEMODULE will it pull in gnrc as a dependency?
Yes it does! If I want to auto init foo, foo should be a dependency of the auto init. (As of 25.09. 9 votes)
No! Auto init is just a setting for a module, if that module is not selected it should be a no-op! (4 votes)
Teufelchen: asked in general chat, most were for it
Miri: Question felt more like a vibe check
Miri: What about a warning âyou want to include autoinit, u sure?â
Maribu: Whats the advantage instead of simply including?
Miri: Talk about , different choices to pick from
Maribu: Then it should just use the default (?)
Teufelchen: maybe use default, add warning if unclear (?)
Miri: netifs often unclear what to pick from exactly
Maribu: Maybe in that case makes sense to do warnings, otherwise not
If it compiles it should work, if not it shouldnât compile
Conclusion: If autoinit choice is clear, automatically just import, otherwise error
Teufelchen will look into it
Tree-wide clang format
Ann: Please let me run a tree-wide clang format so people stop looking at our own code only to see a bunch of formatting that isnt even allowed (would also make it more feasible to make clang format mandatory for PRs)
Ann: I will take the blame for the git history if we do
Miri: If somebody canât deal with git blame its their fault
Maribu: What about gitattributes
Ann: Unsure whether it gets applied for all clones
Maribu: Definitely just include it either way
Teufelchen: Go iteratively from old code to newer, hopefully only break old PRs through that
Karl: alignment of values was good, clang will take it away
Maribu: Only aligns when more than 2 values are close
Miri: Are there clang format ignore commands
Teufelchen/Maribu: Havenât seen instances where clang-format broke alignments yet
Ann: âSome of your code might get ugly but itâs a sacrifice Iâm willing to makeâ - Lord Farquaad
Maribu: If we do exceptions we will lose one of their main advantages of clang format
Karl: Ignore statements ugly
Maribu/Miri: But they donât break tool flow, exceptions without do
Not enabled, 17+ ppl donât have 2fa, outside contributors that donât have 2fa will automatically be kicked due to this
Wonât enable it now but we should give a warning and then enable it
Agreement to warn till next week, next week we enable it
Github scares Miri with fake enabling it due to vibecoding while it wasnât enabled
Miri will post the following message in #RIOT and the forum.
@room Please activate 2FA for your Github account until Friday, Oct 2, 2026, 15:00 CET. We will make it mandatory for the RIOT-OS organization until then. Here is what GitHub says:
Organization members who do not have two-factor authentication enabled will be unable to access resources owned by the RIOT organization, but will remain a member of RIOT until they update their settings. Outside collaborators who do not have two-factor authentication enabled will be removed from the organization and notified. View organization membership to see which users will be impacted.
Waakama
Ann: Leandro reported that Wakaama is deprecated in Forum
crasbe: similar issue to above, but that seems to be going on alright?
crasbe: would be nice to get some more eyes on there too
Miri will also do it
Positive News: Activity & Murdock Speed
crasbe: The period between July-September 2026 has been the most active period since January-March 2024
crasbe: 604 commits so far and September is not over yet
crasbe: Bas was also busy optimizing our Make system (e.g. remove unnecessary shell calls) and reduced the CPU time by about 1d (from >9d to right around 8d (sometimes more sometimes less))
crasbe: Overall build time reduced by 30-45min (difficult to pinpoint)
Ann: Static Tests also getting speed increase, tools-build-test is hopefully also getting reworked soon
Please add your agenda items to our pad for the meeting minutes, so we know beforehand if there is anything to discuss (some people decide their attendance on that).
Ann: Looked cool like Rust Logging, Carl not here, look at PR for some feedback to it
Karl: I thought we had a rule that core canât depend on sys
Miri: Not sure, but makes sense I guess, seems a bit broken
Karl: Maybe donât make it default
Ann: Afaik thatâs how it works right now, you have declare that you wanât to use it
Karl: Afaik the other way around that you want not clownfish?
Miri: Is clownfish pulling sys into core?
Maribu: I think already happens either way due to Log
Karl: I think so, currently carl has a config for that
Miri: I think there is an old PR that also tried to put LOG into Debug, donât remember fully
Karl: Also reserves double score, extremely reserved by C
Miri: Identifiers can be renamed
Karl does not like log to be reunified
Consensus: Look at PR and give feedback no point discussing right here since Carl is not here
Continued after Carl joined at the end
Carl: What I read is correct, if you donât use selective variable nothing changes, opt-in for DEBUG redirect to LOG
Carl: Tried to compile something for esp boards, logging really weird on esp, there is completely different logging module for esp, adapts on what other log modules are used, extremely weird, you cant use your own logging func with esp boards due to that, looking into how to integrate our logging into the esp-idf thingy, uses closed source library, would like feedback
Fixing, will dump into PR, can create another PR for ESP logging later - just want to keep eagle eye picture in the meantime so ESP wonât be afterthought
Maribu: The IDF is making stuff weird, have no chance of seeing some stuff due to decisions they made, which is why we have to kinda use it because RIOT is forced to work along the existing idf platform, e.g. implemented FreeRTOS Threads
Maribu: If somebody was to clean up, e.g. FreeRTOS threads as a general abstraction in RIOT, would make more PKGs portable to RIOT
Miri: I remember some PR for that?
Carl: Macro magic, debug invocation can change timings can also cause unsafe stuff to happen, my idea is in refactor you can specify the log level & unit, can optimize the rest out, added small feature flag for platforms such as the esp, dynamic control (for ESP compatibility) and static control of log levels
Ann: Sounds like a good thing for RIOT
Miri: If we can get rid of the circular dependency
Maribu: [I forgor what he said :(]
Carl: What was the reason for this?
Miri: Causes iffy behaviour, try to avoid because of that
Carl: Would option be to put debug header into core / move to module that sys & core can depend on
Miri: Make log its own root, e.g. ./log ./core ./sys
Carl: Would presumably be a source breaking change, e.g. for MLPA
Discussion about why that would(nât) break anything
Consensus: think about this more and how to structure
Murdock: How does this even work anymore
Ann: So crasbe tried to understand and update Murdock potentially, we discovered that workers were extremely outdated (e.g. avr-gcc jumped from 7 to 14), spiraled into rabbit hole of trying to fix a lot of issues that Murdock was supposed to catch
Ann: Ends with a rabbit hole at the end of the rabbit hole of Murdock suddenly breaking unrelated to the Murdock work we did before that
Miri: Tried a lot of stuff,
in the end: something:tm: in the gitea image itself seems to have been broken. I moved over to forgejo, see /srv/docker-compose/forgejo, with keeping both the gitea database and the data from /srv/docker-compose/gitea in place. I did not port the maze yet nor provide any functionality beyond the one needed for CI.
I suspect something is broken in /srv/docker-compose/gitea/data, which might be the culprit though if someone wants to pick up forensics.
Claude (via duck.ai) suggests git-upload-pack might be overwritten by Gitea and broken, as
docker exec -u git gitea sh -c 'SSH_ORIGINAL_COMMAND="git-upload-pack /murdock/riot.git" /app/gitea/gitea serv user-agent=git/2.43.0' returned some weird output
Miri: Makes clear that she is not the maintainer of CI and/or Tatooine, just stepping in for the admins
Ann: everything will be fine Crasbe still looking into this a bit, we will try to understand Murdock a bit more, shouldnât break anything hopefully at this point anymore
Consensus: Never touch Murdock again for the next 5-10 years so the next wave of Maintainers has to deal with it /s
RIOT Org Permissions: Why are maintainer permissions per-repo
Ann: Maintainer role only gives access to push in the main repo and some others, e.g. riot website, rust crate and so on appears to have different policies, kinda silly, if we trust people to be maintainers we should be able to trust them with everything, esp. since RIOT as the core repo is probably the most important
Miri: Yes, but donât want to decide in this group, higher ppl probably need to be here
Maribu: Doesnât need to be binary, could be some middleground
off topic discussion about website repo
Consensus: Move to VMA
RIOT Summit Orga: More transparent planning, videos look like from 1990, etc
Ann: Came from Chrysn and Oleg afaik, setup was intransparent
Miri: Was a bit chaotic, we tried to at least do a pretix documentation for next year at least
Ann: Chrysn idea was to have some public communication channel at least, discussed into forum
Miri: Now does a forum post about questioning current process
Maribu: Makes sense for ppl not on Matrix, Forum easier to understand
Maribu: Have a great joke about Matrix, not sure whether you can decrypt itg
Ann: Also Chrsyn complained about audio/video quality of videos
Miri: Was confused, Chrysn did a lot of high quality stuff but videos ended up being the Webex stream
Ann: What happened to high quality?
Miri: On SD card of Chrysn, did the mixing for the summit in vienna
Consensus: Wait for Chrysn post, better syncing about vids
Miri: Thought about this a while, easiest solution would be to just send a mail onto this, wait for 2 weeks and then just deprecate it when demand isnt there
Ann: Could we then also just ask why they would be against it
Maribu: If you have a security email there is an expectation that we read and react to them and we donât really do that
Miri: I read them, with more time right now I might react but itâs generally true
Ann: Can we just do auto-replies that they should contact on github?
Miri: Not sure mailman can do that but generally maybe
Maribu: Maybe checkmark âI invested more than 10m of human time on thisâ
Miri: Hard to have checkmark in mail Maybe in Agents.md âHey human has to review security stuffâ
Karl: Maybe have declaration of AI in security report?
Ann: Afaik basically everything has been LLM at this point
Maribu: Problem is time invested by people, security reports are often way too complicated, could be single line PRs
Ann: Do we have a âPlease open a PR insteadâ line in our security guidelines
Maribu: Would be in favour of this
Miri: Many security ppl still like responsible disclosure
Consensus: Add the line to security guidelines, ask whether autoreply is possible for now
AOB
Martine: Activated 2FA for GitHub RIOT-OS org right now
Maribu: SMS counts as unsafe 2fa for Github btw
This was followed by debugging the CI issue further for quite some while, if you want further details about that look here: https://youtu.be/YAgJ9XugGBo
Please add your agenda items to our pad for the meeting minutes, so we know beforehand if there is anything to discuss (some people decide their attendance on that).
Coding convention, style, and clang-deformat (carl)
Murâ
Murdock issues post mortem (martine)
ESP de-mummification (if time permits)
unstructured text is not a stable serialization format and must not be assumed to be
Notes
Coding convention, style, and clang-deformat
carl: RIOT feels like 90s, some conventions donât make sense
carl: seems like we want to do tree-wide clang-format, sensible idea. But: in some cases it de-formats (ex longer if-clauses). How to turn off for parts?
carl: proposing to change some conventions before we start to clang-format treewide
carl: first: switch from /* ⊠*/ to ///, would save 20 lines per file, 1MB in RIOT repo
karl: /** looks nicer than /// to me
carl: second: /// MARK: in headers is shown nicely in minimap in vscode etc.
carl: third, â@ingroup before {â should be â@addtogroupâ
carl: fourth: in/out param doxygen only make sense on pointers
carl: fifth: opening brace for function definition in newline breaks with rest of coding convention (if, switch etc have in same line)
carl: sixth: clang-format per default puts function arguments in blocks, instead of one per line (more readible)
Ann: indeed clang-format struggles with our convention, personal feeling after testing: just switch to llvm defaults with convention
maribu: kernel convention is supported by clang-format
maribu: reason for sixth is readibility, not personal taste (better)
martine: Parameter per line also better for git diffs: See immediately which parameter was removed/added.
karl: clang-format has no support for default 80, max 100 ColumnLimit
teufelchen: anyone against just setting 100
Ann: already arrived to this in PR
karl: suggested a workaround to support softlimit of 80, but hacky
mikolai: so adapt coding convention?
maribu: do we need coding convention if we just use clang-format?
karl/martine: yes, should not depend on tool
maribu: clang-format is not a beautifier but meant as canonicalization, uncrustify is beautifier
carl: concensus seems to be: update coding convention, then enforce/realize by clang-format
martine: we should discuss proposals individually in PR
carl: was asking for feedback here in the room
Teufelchen: agree with personal feeling, but too insignificant to bother and reformat whole tree
carl: I dont linke 90s style â karl: 90s are kinfof ok â miri: 90s style so colorful
martine: would refrain from changing too much of coding convention if it results in more changes in tree-wide reformat
carl: yes, idea was to piggyback on the tree-wide formatting that was planned anyhow
maribu: RIOT has very special coding convention, very different to others. would decrease friction with less special coding convention
carl: RIOT should stay cool/hip/new, since C is not hip anymore. improving coding convention could help
mikolai: proposal: carl drafts PR with changes to coding convention.md. people familiar with clang-format problems amend stuff that makes it hard to use clang-format to enforce it. Then gather consensus in following weeks.
karl: could split doxygen-related stuff and coding convention into two PRs
room agrees to Mikolaiâs proposal
Murâ
Ann: fancy fancy riot.annsann.eu, started as improvement of murdock-html, now on a hard-fork
Ann: not sure what future is.
martine: could merge back and update official frontend. maybe change theming
karl: just frontend, using same backend, can coexist?
ann: yes, since backend has no CORS configured
Ann: could post PR, fair warning, will be gigantic
martine: maybe wait until after release
Murdock issues post mortem
Martine: as a heads-up: murdock CI broke last week since gitea docker got RCE, interacting with git triggered malicious script
Martine: now switched to forgejo, banned malicious IPs
Martine: problem yesterday was intermittent murdock database connection problems. probably triggered by updated firewall rules for gitea IPs. replaced drop by reject, will test when murdock queue is empty
Ann: access to tatooine for crasbe?
crasbe: not sure if I want that. maybe after release. have fix in the pipeline that would have avoided murdock hangup. murdock containers cannot be built anymore because of broken dependencies. game plan: doc for guides by Claude
Teufelchen: how about moving to more standard tooling?
crasbe: Claude built a buildbot alternative. but not as efficient as Murdock. Murdock actually greatly optimized for our use-case. Problem is mostly missing documentation and outdated deployment.
Ann: woodpecker CI as alternative? murdock is a RIOT project and should be more visible and less separate repositories. can we move everything to RIOT orga? maybe 1-2 repos?
people seem to agree
martine: could improve murdock by switching away from python?
crasbe: rather try to pipeline more stuff. and poke maribu to improve ccache. or increase ccache size (improved 10% by increasing 8GB to 16GB)
teufelchen: not sure why CI is not as hard-working as possible. �
ESP de-mummification (if time permits)
carl: sth needs to be done in next years as our Espressif SDK version will not be supported anymore. nothing too pressing, but a problem for the future
martine: Gunnar is only intermittently available
crasbe: insider info from basilfx. there is a RIOT-OS repo called toolchains, which is still used for msp430. ESP SDK update could be done there as follow-up (?)
maribu: ESP is just shitty. also in Zephyr. HW is great, but software is shit. many binary blobs. Also in rust: esp-up instead of rust-up.
martine: re LLM decompilation in RIOT Off-Topic?
maribu: its even MIT licenced
unstructured text is not a stable serialization format and must not be assumed to be
maribu: Pickup up discussion in Matrix that shell command output changes should be considered as API change and handled with care
maribu: It is common practice to not consider unspecified and unstructured text output as a stable format
maribu: Common practice is to provide either standard serialization formats (e.g. JSON / XML / ⊠output) or special flags like --porcelain flag for git
maribu: Treating changes in output of shell commands as API change because it is breaking consumers is not acceptable:
The consumers take a volatile format without specification as a stable format, which is an invalid assumption
Asking contributors/maintainers to treat this as an API change is externalizing the cost of the moot assumption
Instead, the external consumers need to be fixed to parse stable output. If no feature is provided by RIOT to get the information, this would need to be upstreamed by the people intending to consume the information.
maribu: solution for problem at hand: Maybe add something to RIOT repo, test as murdock, let that expose a stable interface?
Martine: shell parser in RIOT repo, but currently not tested afaik against actual RIOT output
Please add your agenda items to our pad for the meeting minutes, so we know beforehand if there is anything to discuss (some people decide their attendance on that).
Jitsi Meeting Timer vs. HackânâACK and weeeeeeeeklies
Is noone taking the release tests serious anymore? (Martine)
Easy to fix interop test broken for 2 releases
Shell commands changed, pexpect expected old outputâŠ
Security Advisories, RIOT AI Filtering
Assisted-by: Brain & Stats
Woodpecker experiment
Unmaintained/âPick me upâ PRs should be closed, inflation of open PRs
Status Update Release 2026.10
Notes
Jitsi Meeting Timer vs. HackânâACK and weeeeeeeeklies
Martine: shouldnât be a problem for weeklies
Martine: proposal: just restart on timeout
people agree
Release tests
Martine: was disappointed about state of release tests, some were as easy as fixing some CLI commands
Ann: did manual on-desk testing back then, Kevin had similar issues and/or was rushed
Martine: can we improve documentation? what were the problems?
Ann: too long ago, canât really recall
Martine: known issue: tox version is outdated
Security Advisories, RIOT AI Filtering
Ann: discussion in Matrix chat about AI-generated security report
Ann: tried out: AI-generated summary. should we change it to policy?
Martine: letâs continue testing, evaluate then. wait at least for deadline.
Teufelchen: asked raptor (serious researcher, serious security reports in the past) if he would be pushed back by us not giving out CVEs. He would not and agreed that AI slops might just be CVE hunters.
Martine: maybe ask more people for more data points? Could also ask around at Congress etc.
Teufelchen: will do
Ann: agree to not give out CVEs anymore
Karl: mlpa is about to add security scans to their releases. so no CVE means no report?
Martine: but will still publish security advisories
Ann: process right now, not very useful. Github gives out CVEs after months
Karl: we query OSV database: Vulnerability Database - OSV for compliance, streamlined process for other libraries
Martine: will still publish reports, just not CVEs
Mikolai: publishing in our own format / database will increase load on RIOT users
Karl: process at our end not implemented yet, but would appreciate a central database for querying
Karl: would be concerned if RIOT does not publish CVEs anymore. but can also understand the slop load issues on RIOT side.
Ann: take-away: continue for now giving out CVEs?
Martine: yes. letâs bring it to a bigger circle at next VMA
Assisted-by: Brain & Stats
Ann: Total AI usage in October (01-today) is at 60%, 41% September, 34% August / July
(Following this increase AI usage will be at 2351% by next year /s)
So far October keeps trend from September, August had 125 reviewed PRs, September had 199, October already has 143
Ann: We recommend people to actually declare AI usage using the Assisted-by: commit tag, nobody actually does while AI usage keeps increasing
ann@ann-laptop13 ~/p/RIOT (master)> git log master --format='%B' | grep -i '^Assisted-by:' | sort | uniq -c | sort -rn
7 Assisted-By: Claude Code Opus 5.5
5 Assisted-by: Claude Code
2 Assisted-By: Claude Code Sonnet 5.5
2 Assisted-by: Claude Code Opus 5.5
1 Assisted-by: OpenAI Codex
1 Assisted-by: DeepSeek V4.1 Flash
1 Assisted-by: Claude Code Opus 4.8
Ann: similar to Linux kernel, just deprecate Assisted-by: commit message?
Teufelchen: correlation with AI labels AI:generated vs AI:ducky?
Ann: not checked, will do
Teufelchen: (rants about linux mailinglists)
Mikolai: Would like to keep the tag, itâs valuable information. we can simply enforce having the commit label if AI-label is set
Ann: question for which AI label we enforce it
Mikolai: gut feeling: not AI:ducky but AI:generated yet
BasilFX: AI-label may just apply to a subset of commit, so just check for at least one
Teufelchen: sidenote: We should not have âCo-Authored-By: LLMsâ
Mikolai: so consensus: leave in, enforce accordingly
Ann: will do (applause)
Woodpecker Experiment
Ann: Vibed test for replacing murdock backend over weekend, seems to work (on my machine), performance comparison unclear
crasbe: Iâll have my workstation soon, we can try to do a full build and see how much CPU time it would take (aka what the performance penalty would be)
Ann: Woodpecker deployment will need significant time investment from someone
Martine: also want to support HiL tests etc
Ann: Woodpecker is fairly extensible, also for Hil testing
Karl: after figuring out test jobs, will redistribute afterwards?
Ann: yes. probably logic stolen from Murdock
Mikolai: everything depends on actual performance, so propose to find out numbers with crasbe
Ann: we can try
crasbe: I still think we can fix up and document Murdock, but Woodpecker is worth a try
Unmaintained/âPick me upâ PRs should be closed, inflation of open PRs
Ann: I dislike current situation. I have at least one PR I donât want to work on anymore. I donât close it, but leave it open
Martine: we have State:Archived, then close
crasbe: My reasoning behind the âPick me upâ label is that nobody (well⊠not me) looks at closed PRs. And the âpick me upâ labels mean that that stuff should really be picked up at some point
Teufelchen: I tried to close old PRs, but even for old PRs I got bad feedback. But good experience to convert to drafts. When filtered out, gives an actionable list. We could automate this for stale PRs.
Ann: people see 500 open PRs, will get scared. actually 350 out of them are outdated / stale
Martine: for me, open issues/PRs shows that project is still alive. I disagree that open PRs show discontinued projects.
crasbe: I tend to look at when the last commits were made and when the last PRs were merged. If the list is full of merged PRs, a higher number of open PRs is not that scary.
Ann: so letâs keep things as they are. I will close my stale PR as State:archived.
BasilFX: about issues on feature/board requests. Will look at it and close old ones.
Please add your agenda items to our pad for the meeting minutes, so we know beforehand if there is anything to discuss (some people decide their attendance on that).
, different choices to pick from
)
Crasbe still looking into this a bit, we will try to understand Murdock a bit more, shouldnât break anything hopefully at this point anymore
Maybe in Agents.md âHey human has to review security stuffâ
)
