# 2025-02-05 - coreboot Leadership Meeting
## Attendees
Felix Held, Jay Talbott, Julius Werner, Andy Ebrahiem, Martin Roth, Maximilian
Brune, Matt
DeVillier, Christian Walter, Andre, Mina Asante, David Hendricks, Alicja
Michalska, Jon Murphy,
Jeremy Compostella, Elyes.
## Open Action Items
* 2024-11-27
* Send out poll with regards to LLM usage (requested by SFC)
* 2024-10-30
* Add clarification to docs, “do not use gerrit change-id or CB: format in
reference to already-merged patches.”
* 2024-10-16
* Matt: Set up a meeting to discuss board status alternatives and send out
invites.
* Decouple data collection with uploading
* Require gerrit credentials or other auth to push
* Json format?
* https://github.com/chrultrabook/linux-tools/blob/main/debugging.sh
* 2024-09-18
* Jon: Schedule a dedicated meeting to discuss the Coverity defects and
action plan.
* Werner: Send out an invite for the meeting.
Sent out a poll to find a time slot:
https://rallly.co/invite/1c8J3azXAcje
* 2024-05-01
* Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to
translate to Russian (?)
* 2024-01-10
* Nico: (https://review.coreboot.org/q/topic:enforce_region_api)
* Daniel: Look at how we want to localize (non console) strings for
coreboot. Long term project.
## Minutes
### [Elyes] coreboot toolchain and/or Jenkins malfunction
* There is something wrong with the coreboot toolchain and/or Jenkins. Here,
(https://review.coreboot.org/c/coreboot/+/86100), I'm expecting the build to
fail, at least getting
this error: "error: initializer-string for array of 'char' is too long"!
And here, (https://review.coreboot.org/c/coreboot/+/86012), it looks like
Jenkins is mixing GCC
versions! So, what is the plan?
* I can understand adding support for a library that can be used by
coreboot, as seen
here(https://review.coreboot.org/c/coreboot/+/80737), but I'm having trouble
understanding the
purpose of adding LIBSTDCXX. Unless I'm mistaken, this library is not used in
coreboot.
What is the strategy of coreboot after this add and that of 'go' here
(https://review.coreboot.org/c/coreboot/+/63639)?
* To give some more background:
* During the creation of the patch there was talk about the US government
making SBOMs mandatory at
some point (not sure what the current status is).
* The go dependency was already there although to be fair it was only
present in tooling
(intel-sec-tools) as far as I know. We had multiple long talks (also in the
leadership meeting)
about adding go as a dependency into the coreboot build system. As far as I
know we agreed on
letting it into the coreboot build system because it was an optional dependency.
* We worked with [https://fwupd.org/](https://fwupd.org/) together to
facilitate SBOM as part of
Firmware updates. More specifically you can see SBOM information on their web
interface when you
look at the Firmware updates. I haven’t looked at it for a while now, so I am
not sure about the
current status.
* Isn’t that only an ABI for aarch64? According to the content of the
patch it is removing the
riscv abi (although the title mentions aarch64).
* Rv32 is used by one of our emulation targets
(src/mainboard/emulation/qemu-riscv)
### [Martin] Someone mentioned that GitHub isn't being synced anymore.
* Felix S. already handled this? Need to double-check.
### [Alicja] Release notes status?
### [Martin] Adding IT support (reducing the "bus" factor)
* Need someone knowledgeable in NixOS and our infra (Jenkins, Gerrit, Docker,
etc)
* Max has a potential candidate who can help.
* We're happy to use some coreboot funds to do admin duties and document
everything.
* [Max] Toolchain is a significant maintenance burden. There are other
projects out there, maybe we
can utilize another project's toolchain (or merge?) so we don't shoulder the
entire burden.
* [Martin] For now the plan is to just split it into a separate module. We
only update the
toolchain 4x per year, and probably don't need to do it that often.
* Splitting would allow us to test it separately from coreboot. We do
toolchain builds but don't
stress test the toolchain itself beyond "does it build?"
* Splitting would make it easier to update - if people want more frequent
updates, then that would be fine.
* [Jon] This is also what ChromeOS does, for the above reasons.
* [Max] Do we want all of our payloads to compile using coreboot's toolchain?
* [Martin] We can try this out to see what's needed to support different
payloads.
* [David] It's nice, but not required. When we started LinuxBoot, we were
using the coreboot
toolchain since ARM64 was one of the early targets and doing the usual
cross-toolchain setup was a
pain outside of coreboot.
* [Martin] Will look at adding build tests in Jenkins; can't promise to fix
anything.
* Having the latest working toolchain version is valuable info, even if
the more recent toolchains fail.
# Next Leadership Meeting
* February 19, 2025.
* [coreboot Calendar](https://coreboot.org/calendar.html).
# Notice
* Decisions shown here are not necessarily final, and are based on the current
information available.
If there are questions or comments about decisions made, or additional
information to present,
please put it on the leadership meeting agenda and show up if possible to
discuss it.
Of course, items may also be discussed on the mailing list, but as it's
difficult to interpret
tone over email, controversial topics frequently do not have good progress in
those discussions.
For particularly difficult issues, it may be best to try to schedule another
meeting.
# coreboot leadership meeting minutes
https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
