Meeting Minutes #236

AlexanderLanin · 2025-01-28T09:04:29Z

AlexanderLanin
Jan 28, 2025
Collaborator

All official meetings will be documented in this thread. So if you subscribe here, you'll get summaries of the meetings you missed.

Landing page for our team: #107

AlexanderLanin · 2025-01-28T09:05:59Z

AlexanderLanin
Jan 28, 2025
Collaborator Author

0 replies

AlexanderLanin · 2025-01-28T09:07:51Z

AlexanderLanin
Jan 28, 2025
Collaborator Author

Daily

2025-01-28

Agenda

Alignment on currently worked upon issues. Specifically identification of dependences and collaboration.

Participants

Meeting Minutes

Contribute to Issues via comment or via pull request. You'll need to fork the repository.
Operational Backlog
"Kick-Off": a few more people in our existing community
Meeting Infrastructure: Meetings stay as they are for now. We'll switch to open eclipse infrastructure mid February: google calender & zoom meetings.
Chat:
- Chat-Access
- Chat
Let's make issues smaller, so they are estimatable and closed
Let's create "milestones" what we aim to achieve e.g. end of january / february

OSS deep dive
split OSS (#82, #126) to sub-issues, e.g.:

setup dash for python on PR (non blocking) -> dash: Integrate DASH tool in Bazel build #155
- rename "license check" to something like "license dry run"
automation: print problems as comment to pull request, see also bug: pr-preview comment #211
create private key for automatic clearance
extend automaton with automatic clearance
add rust dependencies to dash (via bazel)
add C++ dependencies to dash (via bazel)
bazel modules
change automation (daily / blocking / etc)

0 replies

AlexanderLanin · 2025-01-28T21:26:26Z

AlexanderLanin
Jan 28, 2025
Collaborator Author

Daily

2025-01-29

Agenda / Minutes

Collect current member status (see below)
Yet another issue organization attempt: INF - Infrastructure Community
Collect what needs to be documented: document current setup #245
Daily time -> 1 hour earlier? @nradakovic ok?
Hint: good first issues
esbonio setup broken? -> @MaximilianSoerenPollak

Participants

Current member status

who	score-member (GitHub)	chat (Slack)
Alexander Lanin @AlexanderLanin	✔️	✔️
Nikola Radakovic @nradakovic	✔️	✔️
Maximillian Sören Pollak, @MaximilianSoerenPollak	✔️	✔️
Dan Calavrezo @dcalavrezo-qorix	✔️	✔️
Nicolae Dicu @nicu1989	✔️	✔️
Sameer Srivastava @sameer6989	❌	✔️
Aymen Soussi	requested ❓	✔️
Tomas Pereira	❌ (blocked by legal)	❌ (blocked by legal)
Daniel Woste @danwos	✔️	✔️
Philip Partsch @PhilipPartsch	✔️	✔️
Michael Mueller	❌	❌

0 replies

AlexanderLanin · 2025-01-31T08:29:57Z

AlexanderLanin
Jan 31, 2025
Collaborator Author

0 replies

MaximilianSoerenPollak · 2025-02-03T10:02:13Z

MaximilianSoerenPollak
Feb 3, 2025
Collaborator

0 replies

AlexanderLanin · 2025-02-05T09:20:44Z

AlexanderLanin
Feb 5, 2025
Collaborator Author

0 replies

AlexanderLanin · 2025-02-07T09:33:21Z

AlexanderLanin
Feb 7, 2025
Collaborator Author

0 replies

AlexanderLanin · 2025-02-07T11:33:36Z

AlexanderLanin
Feb 7, 2025
Collaborator Author

0 replies

AlexanderLanin · 2025-02-10T09:21:54Z

AlexanderLanin
Feb 10, 2025
Collaborator Author

0 replies

AlexanderLanin · 2025-02-12T14:07:32Z

AlexanderLanin
Feb 12, 2025
Collaborator Author

0 replies

AlexanderLanin · 2025-02-12T15:38:35Z

AlexanderLanin
Feb 12, 2025
Collaborator Author

Python tooling in bazel deep dive

2025-02-14
To join the meeting, get in contact via Chat-Access + Chat

Agenda / Minutes

Sharing experience on how to best integrate python tools into bazel
Sandbox Approach
Dependency Management in Bazel
Running Black as Bazel Aspect

Participants

0 replies

hoe-jo · 2025-02-14T14:57:35Z

hoe-jo
Feb 14, 2025
Collaborator

Python tooling in bazel deep dive follow up

2025-02-21
To join the meeting, get in contact via Chat-Access + Chat

Agenda / Minutes

Continue on exchanging experiences with bazel IDE integration and linter support

Participants

0 replies

AlexanderLanin · 2025-02-17T09:00:06Z

AlexanderLanin
Feb 17, 2025
Collaborator Author

0 replies

AlexanderLanin · 2025-02-17T10:01:42Z

AlexanderLanin
Feb 17, 2025
Collaborator Author

How to reuse tools across repositories?

2025-02-17
To join the meeting, get in contact via Chat-Access + Chat

Agenda / Minutes

How to reuse tools across repositories?
We can use bazel (see https://eclipse-score.github.io/score/main/features/infrastructure/bazel_registry.html) to pull tools via bazel
One repository per tool is too much
One repository can hold multiple bazel modules
one bazel module = one tool, or we group them:
=> start with one group and split as needed
Example:
- Setup: score-tooling with cr_checker
- Scenario: bug in cr_checker
  - fix in score-tooling
  - release new score-tooling-group
  - update bazel-registry
  - update all users (e.g. Dependabot, Renovatebot?)
Separate repo or keep in score?
- For now we can use the score repository with modules as described above
- Note: bazel_registry is even optional. Direct usage is also possible.
Proposal: use both approaches
- Move one tool (e.g. cr_checker) to a separate repository (tooling repo in https://github.com/eclipse-score/) -> POC by @nradakovic
- Keep the rest in score for now. Depending on timeline, we wait for tooling POC.
How to synchronize python versions across repositories / modules?
- root repository sets the python version. tooling sets a minimal supported version.

Participants

0 replies

AlexanderLanin · 2025-02-17T19:26:24Z

AlexanderLanin
Feb 17, 2025
Collaborator Author

0 replies

dcalavrezo-qorix · 2026-04-22T12:06:34Z

dcalavrezo-qorix
Apr 22, 2026
Collaborator

Weekly RUST 15-04-2026

14:00-15:00 CET

Participants

@PLeVasseur
@bharatGoswami8
@dcalavrezo-qorix
@jgetas
@satoshi58

Agenda

Hi community - I am new to Rust and have some stupid questions about end-customer use cases with respect to sharing binary code supported by S-CORE. I come from C/C++ development and we used to share dynamic libraries with customers.

Now, with Rust I read everywhere (but not on an official Rust site :thinking_face:) that there is no stable ABI, unless using the extern "C" ABI. Additionally, according to what I read I am not sure about how dynamic libraries are recommended in Rust. And I don't know what the S-CORE view on this is.

Therefore I have a set of questions/assumptions and I kindly ask you to comment.


Do we have any ABI requirements to public Rust APIs in our libraries in S-CORE that they must be "stable" - i.e. extern "C"?
If not, as there is no stable ABI in Rust: I assume the expectation for the end-customer is, that he/she builds his/her application and the S-CORE Rust libs always from source with his/her Rust toolchain. Re-using pre-built libraries has risks because nobody gives guarantees about the linker interfaces. Is this correct?
And we only support static linking with our Rust libraries, right?
I just found: https://docs.rs/abi_stable/latest/abi_stable/ - does anyone know what it is and does anyone use it?
(edited)

Minutes

we need an agreement on the set of flags ( compilation/linking )
sharing binary libraries in RUST is cumbersome at this point
atm we don't have a concrete use case ( but there is the risk this requirement will come in the future)
carbi ABI - attempt for a stable Rust ABI: Tracking Issue for the experimental crabi ABI rust-lang/rust#111423

0 replies

AlexanderLanin · 2026-04-27T09:53:28Z

AlexanderLanin
Apr 27, 2026
Collaborator Author

Weekly

2025-04-27
To join the meeting see calendar in #107

Participants

Agenda / Minutes

NEW points

devcontainer provides tools via bazel (@AlexanderLanin)

POC: feat: provide tools via bazel in addition to devcontainer devcontainer#116

planning resurrection

INF - Infrastructure Community (view)
limited scope: only things that people actually work on. No backlog. Backlog just piles up endlessly - no chance for now.

harden_runner

Examples: https://github.com/eclipse-score/bazel_registry/actions
Confrm with eclipse that this is required / makes sense -> @AlexanderLanin
Next: start rolling out to all workflows/jobs

OLD points, which are not closed yet

Upgrade to bazel 8.6 -> Backlog

OS images QNX8

Who: @jgetas
Discussion:
- Testing idea:
  - Use generic QEMU QNX IFS
  - Add custom test partition (instead of custom IFS)
- Requires new QNX SDP 8.0.3 tarball
- Should align with default SDP in C++ toolchain
Conclusion:
- Conflicts with parallel PR: Adding pkg_rules support rules_imagefs#4
- To be discussed offline by @jgetas and @nradakovic
- Goal: decide best approach or support both
- Update 2026-04-13: discussion ongoing
- Update 2026-04-20: 8.0.3 is ok from tech lead & alignment round, if the change is indeed/still required. If optional, we should support 8.0.0 & 8.0.3!
- Update 2026-04-27: @AlexanderLanin will organize a meeting with @jgetas, @nradakovic, someone from testing like Piotr, and ask Anton for someone from BMW.

GNU11 vs C11

done

Feature injection in toolchains

PR in review

Renovate Bot

no update

Test environment requirements for platform integration tests (system tests)

Who: @jgetas

ID	Text	comment
ENV1	The tester requires support for testing on Host Ubuntu x86_64.
ENV2	The tester requires support for testing on QEMU QNX8 aarch64.
ENV3	The tester requires support for testing on QEMU QNX8 x86_64.
ENV4	The tester requires support for testing on Hardware QNX8 aarch64.

OS1	The QEMU QNX8 OS image shall support using shared host directories using virtio-9p	<-- still under discussion!
OS2	The QEMU QNX8 OS image shall support mounting qnx6fs partitions if virtual disks are present by QEMU configuration.
OS3	The hardware QNX8 OS image shall support mounting qnx6fs partitions if qnx6fs partitions are present.
	Predefined mount points:
OS4	The QNX8 OS image shall support mounting qnx6fs partitions to mount point `/opt/score`.
OS5	The QNX8 OS image shall support mounting qnx6fs partitions to mount point `/opt/persist`.
OS6	The QNX8 OS image shall support mounting qnx6fs partitions to mount point `/opt/test`.
OS7	The QNX8 OS image shall support mounting qnx6fs partitions read-write by default.
OS8	The QNX8 OS image shall support mounting qnx6fs partitions read-only if configured.	maybe remount r/o if a file `/mount-read-only` is present on partition.
OS9	The OS image/test environment shall provide an option to reset the test environment state to a defined starting condition. Note: maybe re-formatting the qnx6fs partition.
OS10	The OS image shall support file transfer using ssh.
OS11	The OS image shall support extracting and creating tar.gz files.

FS1	The tester shall be able to use QEMU QNX8 OS IFS image.
FS3	The tester shall be able to create a qnx6fs file system and populate it with tester defined files.
FS4	The tester shall be able to create a FAT file system and populate it with tester defined files.
FS5	The tester shall be able to create a disk image out of partition images.

Assumption: no mac OS arm host support.

Conclusion:

Everyone welcome to provide feedback! Especially @dcalavrezo-qorix and @nradakovic
Timeframe till next Monday

Safety analysis process update

no update

Tooling repo

The repo is basically unmaintained. Whats the current plan? pre-commit sync.

Discussion:

tools in tooling repo are basically obsolete -> @AlexanderLanin
python basics is deprecated maybe? -> @AlexanderLanin
next: pre-commit behaves differently locally and in CI -> short term: exclude those specific checks
next: replace cr_checker with new approach as discussed in #infrastructure chat. Note: seems like reuse cannot be wrapped in bazel.
discuss future tooling/pre-commit approach for score via slack in the next days, as its a little bit of a mess at the moment
template repo is probably out of date

Version mismatches: the versions from eclipse-score/devcontainer#115 are actually not used in most repositories

See also https://eclipse-score.github.io/score/main/design_decisions/DR-001-infra.html

Open: https://meetup.build/presentations/integrating-bazel-pre-commit.pdf

FMEA

json can be used for needimport, see comment. This will allow stanrad importer and it will keep using validations. We still don't see a reason to not use rst/md files for FMEA.

ubCode support

Demo planned in process meeting on Thursday
TODO: document ubCode to docs-as-code relationship (GUI-nice-to-have addition for usability, ground of truth remains pure docs-as-code as-is)
PR: Feat/generate ubproject and schema validation docs-as-code#394

Centralized metrics (@FScholPer)

PR: feat: traceability metrics docs-as-code#484 (in progress)
Standard metrics and standard dashboards, so they measure and show the same stuff
Include check with thresholds like 20%...
Global overview in reference integration

Info: rust problem in communication

1. linking order was incorrect, @nradakovic will fix it
1. acl library is pulled in pre-compiled, which was compiled with different compiler flags (e.g. fpeg)

Not discussed

in case we have too much time *cough*

https://github.com/jvolkman/rules_pycross

7 replies

MaximilianSoerenPollak Apr 27, 2026
Collaborator

On every IDE or just VsCode?

arnoox Apr 27, 2026

vs code for now, via the ubcode extension. There are plans to make this more general but I need to check what exactly is in the pipeline...

chrisjsewell Apr 27, 2026

On every IDE or just VsCode?

What does "every" IDE mean? 😅

The core of the VS Code extension is IDE agnostic; An LSP, MCP and core compile engine.
Then the CLI is also obviously IDE agnostic

Things like Tree/Web views are specific to the VS Code API.

There is also some potential/speculative future plans to be able to "launch" some web views from the CLI directly, and thus be dtached from any specific IDE API

MaximilianSoerenPollak Apr 27, 2026
Collaborator

Well 'every' is a stretch :D and not feasable. Let me re-word it.
Does it only work via VsCode extension or does it use some open way like language servers etc. that 'in theory' it could be ported to other places?

FScholPer Apr 27, 2026
Collaborator

I would also throw eclipse-score/docs-as-code#484 in the round as it goes in the same direction of eclipse-score/docs-as-code#394. We should avoid double work. I think for the harness engineering we need a dedicated session (or AI community?!)

dcalavrezo-qorix · 2026-04-29T11:56:53Z

dcalavrezo-qorix
Apr 29, 2026
Collaborator

Weekly `Rust` 29-04-2026

14:00-15:00 CET

Participants

@PLeVasseur
@bharatGoswami8
@dcalavrezo-qorix
@FScholPer

Agenda

PRs for MIRI integration: miri: integrated MIRI kyron#79 miri: integrate Bazel Miri tests in baselibs_rust baselibs_rust#91
Bug: rust_binary linking fails for linux_aarch64_score_gcc_12_2_0_posix with non-PIC and missing outline atomic symbols toolchains_rust#27
low engagement in the community

0 replies

nradakovic · 2026-05-04T14:05:55Z

nradakovic
May 4, 2026
Collaborator

Weekly

Date: 4th of May, 2026.
Participants:

Facilitator: @nradakovic

Traceability Coverage Checker & CI Reporting Mode

Introduced the traceability coverage checker along with the CI reporting mode.
Reviewed the following pull requests:
Discussion points:
- Alignment of coverage expectations across repositories.
- Integration of reporting into CI pipelines.

Dependency Management Strategy

Renovate Bot
- Proposal to remove it from the workflow.
- Decision: Pending further confirmation.
Dependabot
- Decision: Keep as-is.
- Responsibility:
  - Module maintainers are responsible for final validation and merging of dependency updates.
- Module Template Repository
  - Open questions:
    - Who is the official owner/maintainer/code owner?
    - How will long-term support be handled?
Action Items:
- Clarify ownership and assign code owners.
- Define maintenance and support strategy for the repository.

ACL Toolchain Support

Reviewed progress on ACL toolchain support.
Relevant PR:
- GNU/Linux toolchain: Include ACL support in toolchain toolchains_gcc_packages#11
Discussion points:
- Compatibility and integration considerations.
- Next steps for validation and rollout.
Action Items:
- Complete testing of GNU/Linux toolchain integration.
- Provide support for other platforms/toolchains.
- Document setup and usage guidelines.

1 reply

AlexanderLanin May 6, 2026
Collaborator Author

@nradakovic why no renovate? I just finished the PR 🗡️
eclipse-score/cicd-workflows#104

dcalavrezo-qorix · 2026-05-06T12:15:23Z

dcalavrezo-qorix
May 6, 2026
Collaborator

Weekly `Rust` 06-05-2026

14:00-15:00 CET

Participants

@PLeVasseur
@bharatGoswami8
@dcalavrezo-qorix

Agenda

PRs have not been reviewed
https://public-docs.ferrocene.dev/main/certification/core/index.html

0 replies

AlexanderLanin · 2026-05-11T07:17:37Z

AlexanderLanin
May 11, 2026
Collaborator Author

Weekly

Date: 11th of May, 2026.
Participants:

Facilitator: @AlexanderLanin

Renovate

Last meeting said to not use it, so lets have a look again
eclipse-score/cicd-workflows#104

Note: renovate updates score -> score dependencies, everything else remains in dependabot (for now)

tools via bazel

Solution for running trivial tools uniformly via devcontainer/bazel is ready:
eclipse-score/docs-as-code#511

runner disk space

S-CORE runners have 90GB free disk space. Forks as well. Copies/mirros have 17GB. So S-CORE has/will become "not copyable", as workflows in copies will run out of disk space.

Homework: is that a problem for anyone here?

@AlexanderLanin to address that to tech leads.

LLM/Agent-Coding

Different Frameworks exist, e.g.:

@FScholPer will set up an interest group within S-CORE, as few users/experts are in the #infrastructure meeting.

0 replies

dcalavrezo-qorix · 2026-05-13T12:26:13Z

dcalavrezo-qorix
May 13, 2026
Collaborator

Weekly `Rust` 13-05-2026

14:00-15:00 CET

Participants

@PLeVasseur
@bharatGoswami8
@dcalavrezo-qorix
@darkwisebear

Agenda

PRs have not been reviewed
https://public-docs.ferrocene.dev/main/certification/core/index.html
upstream Miri introduction into official rules_rust

Minutes

rules_rs can be an alternative


Miri is now part of rules_rs

https://github.com/hermeticbuild/rules_rs/releases/tag/v0.0.78

if u want to raise it with score
https://registry.bazel.build/docs/rules_rs#rs-experimental-miri-miri_test-bzl

registry.bazel.build

[Bazel Central Registry](https://registry.bazel.build/docs/rules_rs#rs-experimental-miri-miri_test-bzl)

0 replies

odra · 2026-05-13T14:57:42Z

odra
May 13, 2026
Collaborator

Weekly

Date: 18th of May, 2026.

Participants:

Facilitator: @AlexanderLanin

bazel_cpp_toolchains and gcc versions

Requester: @odra
Topic: How to support different gcc versions (12 and 14) in bazel_cpp_toolchains?

gcc 14 has new compiler flags, how to handle that in the repository?
where do we keep the flags, where and who will maintain them?
as we still don't have a proper understanding of cpp_policies repo, this is hard to answer. Maybe such flags belong there?
Rahul from BMW-India might know more on the idea.
In the end we want architects to define the flags. We "just" have to provide a place where they are.
Nikola will check with Rahul, Ulrich and Andrej.

toolchains, platforms and external development dependencies

Requester: @odra
Topic: Some modules (baselibs and crypto) are building parts of OpenSSL and/or LibACL from source, which can be reasonable for development. What happens if a supported S-CORE platform provides these same libraries?

Currently unknown why baselibs has own dependencies. Potentially to pin specific versions. Although those are usually provided by the system, and not by a module.
Who will actually maintain such pinned dependencies?
Nikola will sync up with Andrey

dashboards

Requester: @FScholPer

Currently we have quite a few dashboards, and even more confusion about them
e.g.
- Fully AI generated: https://eclipse-score.github.io/process_description/pr-675/standards/feature_and_process_status.html - great for quick overview, but not really maintainable
- Docs-As-Code based: https://eclipse-score.github.io/docs-as-code/main/internals/requirements/implementation_state.html
  - Open / not yet implemented: summary dashboard in reference_integration
  - "Template" that all modules can/should/must use. Let's start my introducing the "current dashboard apprach" to 1-3 modules.
- Repo Overview (using docs-as-code data): https://eclipse-score.github.io/.github/#traceability
  - Open: add warning that this is a repo overview, and not formal metrics / traceability
@AlexanderLanin to add dashboard/links to Improve onboarding documentation #2874 (or subsequent PR)

requirements coverage numbers

Requester: @FScholPer

Currently most repositories are at 0% or no number at all. As infrastructure team we can introduce mandatory minimums. We can go for 1% mandatory, or per repository "as high as possible". Let's have a look at the dashboards once they are there, and address this to tech lead circle.

qnx software center cli

Requester: @FScholPer

It's been on our todo list for 2+ months, but no-one has attempted it yet. This can replace the super-fragile downloads from qnx.com. Link.
@dcalavrezo-qorix has tried that half a year ago. Would need another try.

docs-as-code DR-008-Infra: Generating documentation sources via Bazel

Requester: @a-zw
https://eclipse-score.github.io/score/pr-2826/design_decisions/DR-008-infra.html

Moved to separate meeting tomorrow, same time (15:00 CEST)

0 replies

dcalavrezo-qorix · 2026-05-20T12:02:27Z

dcalavrezo-qorix
May 20, 2026
Collaborator

Weekly `Rust` 20-05-2026

14:00-15:00 CET

Participants

@dcalavrezo-qorix
@bharatGoswami8

Agenda

score_crate release

0 replies

dcalavrezo-qorix · 2026-05-25T12:20:11Z

dcalavrezo-qorix
May 25, 2026
Collaborator

Weekly

Date: 25th of May, 2026.

Hermeticity, Reproducibility & LTS — Status and Open Topics

Reproducibility ( 10-year LTS)

Bazel version is pinned via .bazelversion (8.4.2) across all repos. Bazelisk ensures the correct version is used. This must be enforced and checked.
Module lockfile (MODULE.bazel.lock) is committed in all repos. CI enforces --lockfile_mode=error, so any dependency drift fails the build.
Hermetic toolchains are registered in all repos: Ferrocene Rust, score_gcc_x86_64, QCC (QNX), EBCLFSA SDK, remotejdk17/21, Python 3.12, Node.js. No auto-detected system compilers ( although rules_cc does some compiler autodetection which we need to disable)
known_good.json in the integration repo pins all 16 S-CORE modules by exact git commit SHA.
What's missing: No release archival workflow yet. No bazel vendor in practice. No archived Bazel binary alongside releases. The lockfile and pinned SHAs provide integrity, but not offline reproducibility — a build today still depends on GitHub, BCR and crates.io being reachable.

Hermeticity

Lockfile checksums cover the full resolved module graph. Any change in transitive dependencies is detected.
BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN is set only for QNX builds. Other configs still trigger local_config_cc auto-detection, which probes the host system and produces non-reproducible results.
rules_boost is pinned to master in the integration repo — the content changes over time. This is a hermeticity gap we need to fix

Traceability

known_good.json records the exact repo URL + commit SHA for every S-CORE module in the integration build.
MODULE.bazel.lock records checksums for all resolved external dependencies.
What's missing: No release manifest (manifest.json) capturing the full provenance of a tagged release — Bazel version, platform, lockfile hash, devcontainer image digest, known_good checksums — in a single auditable artifact.

Layer separation — are we still planning containerized builds?

Layer	What	Current state
Layer 1 — Host	OS baseline	Documented (Ubuntu 24.04). CI uses `ubuntu-latest` or `ubuntu-24.04`. Not pinned — `ubuntu-latest` drifts.
Layer 2 — Execution context	Devcontainer	`ghcr.io/eclipse-score/devcontainer:v1.1.0` exists and is used by EBCLFSA workflow. Other workflows run on bare runners with `apt-get install` at runtime — not reproducible.
Layer 3 — Bazel	Build tool + deps + toolchains	Lockfile + hermetic toolchains in place. Vendor-at-release planned but not implemented yet.

Current gap: inconsistent Layer 2

Only 1 of 6 build workflows in reference_integration runs inside the devcontainer (build_and_test_ebclfsa.yml). The others install tools via
apt-get on bare runners.

Devcontainer for local development

Developers can (and should) use the same devcontainer image locally via VS Code("Reopen in Container") or the devcontainer CLI. This ensures local builds use the same tool versions as CI. It is not mandatory — CI remains the authoritative environment for reproducibility — but it eliminates the "works on my machine" class of issues.

Bazel-ifying tools vs. devcontainer — have we decided?

Category	Mechanism	Examples
Build toolchains (directly produce build outputs)	Bazel hermetic toolchains	Ferrocene Rust, GCC, QCC, remotejdk, Python interpreter, Node.js
Build-adjacent tools (support the build but don't produce outputs)	Devcontainer image	protoc, lcov, graphviz, QEMU, git, CodeQL, pre-commit
Developer tools (IDE, linting, formatting)	Devcontainer image	clangd, rust-analyzer, ruff, buildifier, starpls

0 replies

dcalavrezo-qorix · 2026-05-27T12:16:03Z

dcalavrezo-qorix
May 27, 2026
Collaborator

Weekly `Rust` 27-05-2026

14:00-15:00 CET

Participants

@dcalavrezo-qorix
@bharatGoswami8
@PLeVasseur

Agenda

score_crate released
POC switch from rules_rust to rules_rs

0 replies

AlexanderLanin · 2026-06-01T13:29:09Z

AlexanderLanin
Jun 1, 2026
Collaborator Author

Infastructure Weekly

Date: 01st June, 2026.

Participants

Agenda

docs-DR-008

New option available (4th)
2 POCs exist
Currently no clear decision possible, how to make progress
Proposal is to push both POCs futher. If there is a common piece, that could already be integrated.
Define a (more) concrete list if features that the solutions need to support - already covered with DR update?
Follow-Up in smaller round: @a-zw, @MaximilianSoerenPollak, @AlexanderLanin (+whoever is interested!)

Coverage doesn't mention files with 0% coverage

So code without tests and code with failing tests is not mentioned as not covered
https://bazel.build/configure/coverage#running_coverage
No solution known to todays participants
Maybe baselibs or communication have a solution?
Hint: https://eclipse-score.github.io/infrastructure/main/how-to/testing.html#collect-coverage + genhtml --branch-coverage --output genhtml "$(bazel info output_path)/_coverage/_coverage_report.dat"

add generic bazel toolchain job

add generic bazel toolchain job cicd-workflows#94
bazel: instructions needed on how to add a target system to S-CORE. Ideally so we don't need to modify MODULE.bazel in all modules every time?!
@AlexanderLanin, @MaximilianSoerenPollak (+ however is interested) need to urgently clean up cicd-workflows, as this PR has been open forever. e.g. do we do a common build.yml or one per target system, or.... etc

how to do to integration discussion

Decision record - reference_integration scope #2747
might be nearing a decision towards "option 4"
whoever is interested should have a look at it!
It's almost identical to https://eclipse-score.github.io/score/main/design_decisions/DR-002-infra.html, detailed diff see comment

Last week

As most people were absent, here is a hint to read last weeks meeting: https://github.com/orgs/eclipse-score/discussions/236?sort=new#discussioncomment-17050035

docs-as-code release today

new check for needextend, which will allow to add stuff but not to modify stuff. See docs for details. In the future it will be further restricted to "current document only".
versioning of needs (e.g. requirements) is available since docs-as-code 3.2.0. Assuming the upstream requirements have versions. This will help you immensely in updating (formally: impact analysis). Highly recommend to start using it.

0 replies

AlexanderLanin · 2026-06-01T13:43:41Z

AlexanderLanin
Jun 1, 2026
Collaborator Author

Infastructure Weekly

Date: 08th June, 2026.

Participants

Agenda

docs-as-code DR8

Setup follow-up via slack soonish, starting Wednesday.

rust

Weekly 2pm CEST rust meeting has few people joining. Everyone aware of the meeting? No interest in rust? See weekly meeting in this discussion thread! Join via Eclipse S-CORE calender.
Whats the current state of rust in S-CORE? Are modules actually using it? Is it the standard in S-CORE for (new) modules? -> answer by TLs needed.
Whats the current rust certification funding state?
Discussed: change cadence, contact rust modules directly (see https://eclipse-score.github.io/.github/#tech-stack). All of that is up to the rust meeting participants.

lockfiles

Let's start with a workflow, although overkill for a single line, but that enables rollout to all repos. Just run bazel mod deps --lockfile_mode=error. No clear design for cicd yet, as the problem is basically the same on every level. The only solution is to use a generic build workflow.
maybe extend https://github.com/eclipse-score/cicd-workflows/blob/main/.github/workflows/bzlmod-lock-check.yml

small repos & bazel / devcontainer

minimalist proposal: add devcontainer, but dont use it in ci (yet)
- pro: it's opt-in, it doesn't hurt. If you don't need it, don't use it.
also: maintainers per repo decide on the best approach. But it must be documented, as it will be raised again and again.

adding toolchains to repos / CI

we have 3+ toolchains in 10+ modules, thats potential for a lot churn
toolchains are configured by .bazelrc
idea: toolchains can be extracted to a synchronized .bazelrc-toolchain file, which can be synced to all repositories. That file can be included from module specific .bazelrc. This way modules can keep all their custom options, without weekly merge problems. Same can probably be applied to module.bazel - already done so in reference_integration. This would even make life easier, as the configurations would be exactly the same in all repositories!
note: assuming we go with option 4 in reference integration, modules technically do not need to support multiple toolchains locally. But it makes live easier.
next steps: Alex to contact bazel experts like @nradakovic, @4og, @ltekieli

dashboards

Idea is to add a default dashboard to all modules. Either fully mandatory, is as some sort of dashboard.
Advantage: standardized metrics, for which the modules are not responsible.
Advantage: New mandatory metrics will appear simply by updating docs-as-code.
FYI docs-as-code is providing standardized data for each repo at https://eclipse-score.github.io/docs-as-code/main/metrics.json, which can be addressed by pointing needpie to get_metrics_with_first_value_total(overall_metrics:total, overall_metrics:with_test_link, overall_metrics:with_code_link, overall_metrics:fully_linked). The advantage is that the graphics are guarenteed to show the same data as the json.
Current idea: @FScholPer will try with verification report, and present results next week.

tests

uniform approach required to handle unit test reports
prototype in baselibs repo: https://github.com/eclipse-score/baselibs/pull/204/changes

planning

quite out of date, what we have is: INF - Infrastructure Community (view)

7 replies

AlexanderLanin Jun 8, 2026
Collaborator Author

How do we roll out lockfiles? As we cannot figure out a common PR workflow (at the moment), and even for an actions it's kind of overkill. How do we ensure all repos have bazel mod deps --lockfile_mode=error?

AlexanderLanin Jun 8, 2026
Collaborator Author

Small/infrastructure repos currently do not have heavy weight dependencies like bazel or devcontainer, as they typically rely solely on uv. There are PRs in cicd-actions and cicd-workflows to change that.

a-zw Jun 8, 2026
Collaborator

Obviously https://eclipse-score.github.io/score/pr-2826/design_decisions/DR-008-infra.html again 😉

arnoox Jun 8, 2026

... this might be helping: https://github.com/useblocks/sphinx-mounts We could talk about it? If @ubmarco didn't present it already.

a-zw Jun 8, 2026
Collaborator

(I fear I won't make it to the meeting today)

I already updated DR-008 to address sphinx-mounts. I consider it a PoC. I certainly do not want to use it for real because it is newly vibe-coded on a Friday afternoon and I want such immature stuff in the docs_as_code repo, where it is easier and faster to change, instead of an external project.

dcalavrezo-qorix · 2026-06-03T12:16:13Z

dcalavrezo-qorix
Jun 3, 2026
Collaborator

Weekly `Rust` 03-06-2026

14:00-15:00 CET

Participants

@dcalavrezo-qorix
@bharatGoswami8
@PLeVasseur
@lionel

Agenda

POC for kyron - switching from rules_rust to rules_rs - ongoing
RUST in S-CORE

0 replies

AlexanderLanin · 2026-06-09T15:34:30Z

AlexanderLanin
Jun 9, 2026
Collaborator Author

Infastructure Weekly

Date: 15th June, 2026.

Participants

News

.github

repo overview shows bazel lockfile status

cicd

new workflow: for asserting bazel lockfile status
new action: setup-bazel-cache -> chore: use setup-bazel-cache action cicd-workflows#125
updated action: more-disk-space v1.1

Agenda

proposal for tagging & changelog for cicd-actions and cicd-workflows -> @AlexanderLanin to try tolling it out in cicd-actions and cicd-workflows, and document it.
module_template and preconfigured toolchains: adding score toolchains module_template#92. Sounds good overall! But see critical points commented in the PR. -> @odra will try this further
random runner selection.
- official docs say 14GB free space on linux: https://docs.github.com/en/actions/reference/runners/github-hosted-runners
- Observation: ~95% of our workflows start with 90GB free.
- what now? Add more-disk-space to basically every workflow?! Contact GitHub support and ask about it -> @4og will write github support request, https://support.github.com/
SemVer vs date-based: SemVer attempt to carry additional "change/risk" information in the tag, while date based is simpler to provide. No major movement in either direction, stay with SemVer.
QNX SDP on-the-fly build via QNX CLI instead of downloading it from qnx.com every time. We need to 1. download their runner script from the qnx software center, which is changing the .qnx folder e.g. licenses. All of that would require executing the script during bazel load phase, which is not designed that way. And it doesnt work in a sandbox. Proposal: use a pre-bazel script (e.g. shell) to download/build the qnx sdp, then pass on the path to bazel. Therefore we can also try passing the SDP to bazel. And we can even use github caching to store that SDP.

1 reply

odra Jun 15, 2026
Collaborator

module_template and preconfigured toolchains: eclipse-score/module_template#92

Eclipse S-CORE

Meeting Minutes #236

Uh oh!

Uh oh!

AlexanderLanin Jan 28, 2025 Collaborator

Replies: 128 comments · 52 replies

Uh oh!

Uh oh!

AlexanderLanin Jan 28, 2025 Collaborator Author

Kick-Off

Uh oh!

Uh oh!

AlexanderLanin Jan 28, 2025 Collaborator Author

Daily

Uh oh!

Uh oh!

AlexanderLanin Jan 28, 2025 Collaborator Author

Daily

Uh oh!

Uh oh!

AlexanderLanin Jan 31, 2025 Collaborator Author

Daily

Uh oh!

MaximilianSoerenPollak Feb 3, 2025 Collaborator

Daily

Uh oh!

Uh oh!

AlexanderLanin Feb 5, 2025 Collaborator Author

Daily

Uh oh!

Uh oh!

AlexanderLanin Feb 7, 2025 Collaborator Author

Daily

Uh oh!

Uh oh!

AlexanderLanin Feb 7, 2025 Collaborator Author

Daily

Uh oh!

Uh oh!

AlexanderLanin Feb 10, 2025 Collaborator Author

Daily

Uh oh!

Uh oh!

AlexanderLanin Feb 12, 2025 Collaborator Author

Daily

Uh oh!

Uh oh!

AlexanderLanin Feb 12, 2025 Collaborator Author

Python tooling in bazel deep dive

Uh oh!

hoe-jo Feb 14, 2025 Collaborator

Python tooling in bazel deep dive follow up

Uh oh!

Uh oh!

AlexanderLanin Feb 17, 2025 Collaborator Author

Daily

Uh oh!

Uh oh!

AlexanderLanin Feb 17, 2025 Collaborator Author

How to reuse tools across repositories?

Uh oh!

Uh oh!

AlexanderLanin Feb 17, 2025 Collaborator Author

Daily

Uh oh!

Uh oh!

AlexanderLanin
Jan 28, 2025
Collaborator

Replies: 128 comments 52 replies

AlexanderLanin
Jan 28, 2025
Collaborator Author

AlexanderLanin
Jan 28, 2025
Collaborator Author

AlexanderLanin
Jan 28, 2025
Collaborator Author

AlexanderLanin
Jan 31, 2025
Collaborator Author

MaximilianSoerenPollak
Feb 3, 2025
Collaborator

AlexanderLanin
Feb 5, 2025
Collaborator Author

AlexanderLanin
Feb 7, 2025
Collaborator Author

AlexanderLanin
Feb 7, 2025
Collaborator Author

AlexanderLanin
Feb 10, 2025
Collaborator Author

AlexanderLanin
Feb 12, 2025
Collaborator Author

AlexanderLanin
Feb 12, 2025
Collaborator Author

hoe-jo
Feb 14, 2025
Collaborator

AlexanderLanin
Feb 17, 2025
Collaborator Author

AlexanderLanin
Feb 17, 2025
Collaborator Author

AlexanderLanin
Feb 17, 2025
Collaborator Author