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

AlexanderLanin · 2025-12-15T10:47:38Z

AlexanderLanin
Dec 15, 2025
Collaborator Author

Weekly

2025-12-15
To join the meeting see calendar in #107

Participants

@dcalavrezo-qorix
@nicu1989
@ubmarco
@nradakovic
@odra
@jgetas
@MayurMysoreNagaraja

Agenda / Minutes

QNX license issue?
- escalation needed - some PRs are opened for more than 10 days
Limit workflows to forks? (Collect idea, schedule follow up?) -> https://sdvworkinggroup.slack.com/archives/C0894QGRZDM/p1765795691165719
Update from last weeks topics:
- common c++ toolchain
  - via https://github.com/eclipse-score/bazel_cpp_toolchains
- new bazel_registry rewrite automation/scripts bazel_registry#190, e.g. version info can be removed from MODULE.bazel files
  - via rewrite scripts bazel_registry#188
- on_pr workflow for modules to trigger reference_integration via prepare script for integration feedback on PR #1852
  - delayed
- monorepo view (gita) onto score via reference_integration
  - progress?
- rust SCA
  - progress?
- os_images stuck due to old QNX --> keep going and call it "community supported" !?
  - progress?
  - AP: reping QNX folks
- dash-license-scan as POC to replace calling tools via bazel. See poc for entire flow dash-license-scan#3
  - blocked due to .eclipsefdn still stuck
Info: Release "0.5 beta" on 18th December.
On QORIX side, we have consciously decided not to continue the project unchanged under the current setup. Given the market and budget conditions, this would neither be strategically sound nor economically responsible. Instead of tying up resources and creating expectations we cannot reliably meet, we are executing a controlled ramp-down. This decision is not an exit from the topics and not a reflection of the quality. It is a deliberate focus to create the conditions to rebuild with clear priorities, a stable setup and reliable commitment
AP: evaluate the integration of the AutoSD toolchain into our common / aggregated toolchain

0 replies

dcalavrezo-qorix · 2025-12-17T13:06:19Z

dcalavrezo-qorix
Dec 17, 2025
Collaborator

Weekly RUST 17-12-2025

14:00-15:00 CET

Participants

@dcalavrezo-qorix
@darkwisebear
@bharatGoswami8
@pawelrutkaq

Agenda

clippy: added clippy support communication#117 - was rejected
ferrocene builder
QNX builds in S-Core

Minutes

we shall clarify the rules_rust vs Aspect till the end of the week and proceed with the agreed approach
ferrocene builder not working atm in CI
QNX 8 SDP available in S-CORE is outdated ( virtio packages are also missing - no QEMU support for aarch64, no mkifs support for real hw targets)
update on the safety rust guidelines: https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/milestone/1

0 replies

anmittag · 2025-12-29T16:41:10Z

anmittag
Dec 29, 2025
Collaborator

2026-01-??

Please review your open issues. Close them, adapt the description or delete them https://github.com/eclipse-score/score/issues?q=is%3Aissue%20state%3Aopen%20label%3Acommunity%3Ainfrastructure

0 replies

AlexanderLanin · 2026-01-12T13:28:43Z

AlexanderLanin
Jan 12, 2026
Collaborator Author

Weekly

2025-01-12
To join the meeting see calendar in #107

Participants

@dcalavrezo-qorix
@nradakovic
@AlexanderLanin
@odra
@a-zw
@kgraeper
@FScholPer
J. Zimmermann
@MaximilianSoerenPollak
N. Trifunovic
C. Swamy
@nradakovic
@jgetas
@nick-hildebrant-etas
aresetar

Agenda / Minutes

bazel_registry no longer requires version & compatibility_level set in MODULE.bazel.
- version & compatibility_level will be patched automatically based on git tag (compatibility_level is semver.major).
- locally it should be module(score_mymodule, version='0.0.0')
- We'll add a warning somewhere when the version is not 0.0.0 in your MODULE.bazel
- modules can be set as "periodic-pull": true, in metadata.json no more separate modules.json file
- other modules can be updated by triggering workflows/check_new_releases.yml
Presentation of bazel_cpp_toolchains by @nradakovic
- @odra, @kgraeper will try it out "today"
- this will deprecate toolchains_cpp and toolchains_qnx
new image file systems repo, it will be used by os_images repo. No decision record required, as there are no good alternatives. To be created by @nradakovic
- Note: one os_images qnx branch by @jgetas is blocked at the moment as we need qnx 8.0.3 + Virtualization Drivers

Not discussed today (out of time):

branching strategy
c++ formatting

0 replies

dcalavrezo-qorix · 2026-01-14T09:31:49Z

dcalavrezo-qorix
Jan 14, 2026
Collaborator

Weekly RUST 14-01-2026

14:00-15:00 CET

Participants

@dcalavrezo-qorix
@darkwisebear
@bharatGoswami8
@pawelrutkaq

Agenda

Rebuilt the Ferrocene toolchain using the official Ubuntu 20.04 CI image to match the older baseline ( still building)
Enabled profiling support and rebuilt the toolchain accordingly.
Hit QNX build failures when profiling is on; prepared a patch but it still needs to be submitted/integrated, so QNX profiling is deferred.
Prepared the coverage tooling workflow (blanket + symbol-report) with a runnable example in examples/coverage-demo/
Upgrading rust version in s-core toolchain

Minutes

AP: discuss in the next Infra weekly about hermetic approaches for our builds ( Bazel, containerized, etc)
commercial offer will arrive by the end of the week
S-CORE & QNX mtg regarding RUST certification ( details tba)
clarify clippy execution scenario (rules_rust vs Aspect)
https://hackmd.io/@plevasseur/r199Y_lS-l
Constraints for ABI bazelbuild/platforms#38
Extend QNX support by adding all currently supported variants bazelbuild/rules_rust#3723
AP: we need to fork our own rules_rust and publish a release with our changes in our S-CORE BCR

5 replies

dcalavrezo-qorix Jan 15, 2026
Collaborator

Reminder : request from @MaximilianSoerenPollak for next week's Minutes:

Can you take the topic of 'Testing' into the Rust meeting next week?
Specifically the discussion what test framework to use.
As it came up again that the current one does not support properties in XML.

If the frameworks that exist that support that are too much (or too hard to verify / secure etc.) then we might need to find another way to parse rust tests inside docs-as-code.

pawelrutkaq Jan 15, 2026
Collaborator

So I hope @PLeVasseur or @darkwisebear or others have a better approach but since I don't really know any solution that could let us connect test with req-id out of box, I would tend to say that using syn::parse_file and adding a small macro like

...
#[tracable_test="req-id"]
fn test_somethig_nicely() {
}

should allow to write simple Rust tool that extracts locations, and ids for doc-as-code.

tracable_test - simply expand to #test

MaximilianSoerenPollak Jan 15, 2026
Collaborator

The tests are different than the source code link. They work via xml properties.
Though it can also work through source code parsing.

darkwisebear Jan 22, 2026
Collaborator

I would strongly encourage to put the links to the source where possible. Either as attributes or as rustdoc somehow. I also spoke to a maintainer of rustdoc last year and they were open to extensions if we give reason why this is necessary. But no, I don't have a better idea than these...

MaximilianSoerenPollak Jan 22, 2026
Collaborator

I would strongly encourage to put the links to the source where possible. Either as attributes or as rustdoc somehow. I also spoke to a maintainer of rustdoc last year and they were open to extensions if we give reason why this is necessary. But no, I don't have a better idea than these...

Pure links to source code are different than the testing linkage.
As the testlinkage will parse things from the XML and also create testcase needs that can be used in statistics etc.
Yes it will also link to the source code itself (in the testlink attribute) so that is the same. But via the XML there is more too it than just that.
Simple links (without any additional information) already work right now regardless of language.

AlexanderLanin · 2026-01-19T13:24:23Z

AlexanderLanin
Jan 19, 2026
Collaborator Author

Weekly

2025-01-19
To join the meeting see calendar in #107

Participants

@dcalavrezo-qorix
@nradakovic
@AlexanderLanin
@kgraeper
@MaximilianSoerenPollak
@nradakovic
@jgetas
@nick-hildebrant-etas
D Kenjic
@guejan
@kgraeper
@odra
@ubmarco
@opajonk

Agenda / Minutes

bazel_registry no longer requires version & compatibility_level set in MODULE.bazel -> approach as discussed last time is now documented. @AlexanderLanin
new action more-disk-space, can be used @AlexanderLanin
integration status by @kgraeper:
- "pull request feedback from integration" as a reusable workflow is now available. Volunteer for testing? baselibs via @nradakovic? - in case baselibs is using pull requests now.
- next: auto update of known good manifest on main branch
fix: Test linking via Pytest decorator now also works with class based tests. It will name the link '__' if both are available, or just if it's not a class based test. Test linking can be used now! by @MaximilianSoerenPollak docs, example
architecture of tooling, score-tools

I want(ed) to do a score-tools pipx approach for tooling. And I still believe it's one of the best appraches I've seen so far. But:
let's be realistic. I have not touched that repo for 3 months now.
if people have the chance to call ruff instead of score-ruff, they will. So basically this is fighting the same problems as a bazel integration. No IDE support. As soon as the command is non standard, you are screwed.
So I'm now proposing a different solution.
We put a central ruff.toml, pyrightconfig.json, clang-format, etc file somewhere in cicd-workflows / module-template, and push it from there to all the other repos. We'll need to figure out some way to merge that with local stuff, and I have no idea how at the moment. But that's only one pain point, compared to the many if we use pipx-approach or bazel-approac

proposal for tools that do not benefit from bazlification (fast enough, no cache required, bazel does not provide inputs):
- provide tool versioning centrally, via devcontainer
- provide tool config from one central place, automatically copied to all the repositories (daily)
- @AlexanderLanin writes a "mini DR", building on top of DR-001, for this decision.

request: present analyzed GitHub-caching options by ETAS
general problem: AppArmor in Ubunut 24 + GitHub Runners (without admin access) + Docker + Bazel is a bad combination for bazel process sandbox (used by communication tests). Tracked in Enable linux-sandbox also for Ubuntu 24.04 devcontainer#40. Was solved just TODAY?! See eclipse-score/communication@108d1f8

copybara usage experience: Is anyone using it? ETAS (@nick-hildebrant-etas, @AlexanderLanin etc) have tried using it, but so far the conclusion is to abandon it. Feedback @dcalavrezo-qorix: similar experience, and it stores a state - which is bad for CI, abandoned as well after some attempts -> using native git instead. We can collect feedback async from @nradakovic.

0 replies

AlexanderLanin · 2026-01-19T15:47:55Z

AlexanderLanin
Jan 19, 2026
Collaborator Author

Weekly

2025-01-26
To join the meeting see calendar in #107

Participants (to be updated)

@dcalavrezo-qorix
@AlexanderLanin
@MaximilianSoerenPollak
@kgraeper
@jgetas
@nick-hildebrant-etas
@odra
@ubmarco
@a-zw
A. Resetar
@MTomBosch
@tbreckle
@arnoox

Agenda / Minutes

Testing table format for topics :-)

Topic	Who	Discussion	Conclusion
caching options analysis presentation	@MTomBosch	pptx will be attached later	-
module -> module dependencies, see image, release frequency: in order to not spam releases we should allow usage of `git_override` for daily work. However module releases must refer to other modules via release, otherwise their local testing becomes meaningless	@AlexanderLanin	..	1b
remove feo from ref_int? main is not maintained since 3month and module name is still feo instead of score_feo on main	@kgraeper	Feedback Tech Leads: Will be discussed tomorrow. FEO is still maintained. Make sure an issue exists.	eclipse-score/feo#33
add lifecycle to ref_int	@kgraeper	Feedback Tech Leads: feel free to try out, but it is still very volatile.	..
latest logging does not work with latest communication	@kgraeper		Create ticket in logging that in order to be integrated, they must be compatible to latest communication -> eclipse-score/logging#41

0 replies

dcalavrezo-qorix · 2026-01-21T12:59:05Z

dcalavrezo-qorix
Jan 21, 2026
Collaborator

Weekly RUST 21-01-2026

14:00-15:00 CET

Participants

@dcalavrezo-qorix
@bharatGoswami8
@pawelrutkaq
@odra
@arvindr19
@MaximilianSoerenPollak
@haritha

Agenda

integrated clippy into communication using rules_lint
prepared DR for clippy clippy: added decision record on how to integrate clippy #2466
prepared S-CORE execution contract draft execution contract #2475
still opened: - AP: we need to fork our own rules_rust and publish a release with our changes in our S-CORE BCR
issue from @MaximilianSoerenPollak https://github.com/orgs/eclipse-score/discussions/236#discussioncomment-15505810

Minutes

the AP still remains valid - forking our own rules_rust @dcalavrezo-qorix
AP: perform an analysis whether we actually need a custom tool/framework - if not go ahead with vanilla
commercial offer from Ferrocene <100k for certification

1 reply

MaximilianSoerenPollak Jan 22, 2026
Collaborator

Here is a small write-up I made regarding the Testing Framework Discussion:

Rust Testing Framework Suggestions

A couple of suggestions for the community to consider.
These frameworks would supply at least somewhat the things needed to make the docs-as-code solution via XML work.
If none of these are viable options determined by the community then a custom solution might be the only way, as traceability is a must have.

Frameworks

1. Cargo-Nextest

A very powerful testing framework that does a lot, and in addition with quick-junit it also allows for properties inside the XML as far as I can tell.

The main issue here is that it has over 100 dependencies, and that might be an issue once it gets to porting the tests etc. to other architectures.

2. Cargo Test (Vanilla) + cargo2junit

This allows for the output to be in XML, though we would be missing the properties here as far as I know. That means we would have to find another way to add properties & attributes to the XML in order to enable this

3. Cargo Test (Vanilla) + Custom solution

Also possible that we can just make a custom solution that enables properties to tests and parses the output from cargo tests. We theoretically could even skip the XML creation and go straight to generating the JSON that will be outputed but that might be more confusing especially if we change how the source code linker behaves.
There already is a prototype of this that could be looked at / build upon, made by @PiotrKorkus a while back.

Conclusion

I'm not qualified to say which is the best way to go about this, I merely gathered some possible paths the rust community could take.
If there is need of example XML's (what the source_code_linker would expect) or any questions on how it works, I'm more than happy to answer those.

AlexanderLanin · 2026-01-26T15:00:44Z

AlexanderLanin
Jan 26, 2026
Collaborator Author

Weekly

2025-02-02
To join the meeting see calendar in #107

Participants (to be updated)

@a-zw
@opajonk
A. Resetar
A. Riess
@dcalavrezo-qorix
@FScholPer
@guejan
@jgetas
@odra
@MaximilianSoerenPollak
@nick-hildebrant-etas
@nradakovic
@kgraeper

Agenda / Minutes

Topic	Who	Discussion	Conclusion
PR reviews	@nick-hildebrant-etas	the review requests chat is not the best option ever to facilitate reviews. Any other ideas?	CODEOWNERS are expected to merge after approval - or leave an explicit "not merged yet because..." reason in general everyone please close some draft PRs. We have too many.
dash-licensce-scan	@AlexanderLanin	new tool / action for scanning dependencies. Example 1, Example 2	will be documented & presented further once finished
docs-as-code source links API change	@a-zw	change in API: docs-as-code will no longer scan the entire repo for source code links. HowTo	will be included in next docs-as-code release. Leads to such statistics
cicd-workflows vs multiple repos	@AlexanderLanin	Looking for volunteers to discuss https://github.com/orgs/eclipse-score/discussions/2493	Deep dive with @AlexanderLanin, @MTomBosch, @odra, @FScholPer @kgraeper @nick-hildebrant-etas
bug in score_platform due merge of old PR branch	@AlexanderLanin	Require up to date PRs? Activate merge queue?	-> per repository decision, but one of them must be enabled (merge queues are slightly more effort, but better long term)
name for the Image FileSystem repo	@nradakovic	rules_ifs, rules_imagefs, and many more proposals	rules_imagefs
branch naming for release	@AlexanderLanin	We have a long running discussion on branching... However we need a common (temporary) approach ASAP, like today, therefore I propose "SemVer standard branching model for git". I guess this is the best explanation. So basically repos should have releases either from main or from `release/x.y` branches. Reminder: tags are prefixed with a v, e.g. vX.Y.Z	valid start for now. TODO: public announcement for repo/module maintainers
Rust toolchain issue	@kgraeper	rust toolchain does not work with QNX 8.0.3. Background: rust toolchain does not officially support QNX 8 at all. In the future ferroscene toolchain will be used. Score toolchain switched with latest release.	@dcalavrezo-qorix and @kgraeper please document what people need to do

next week

Topic	Who	Discussion	Conclusion
autosd in os_images	@odra	present about how autosd will be included in the os_images repository, together with some autosd image
builder updates (bootc) and how that integrates in a Bazel workflow	-

8 replies

AlexanderLanin Jan 27, 2026
Collaborator Author

Yeah we do. But lets address it. Devcontainer is a special case at the moment since CODEOWNER != maintainer.

FScholPer Jan 27, 2026
Collaborator

I would say devcontainer is special as it is used by everyone. There should be no owner

opajonk Jan 27, 2026
Collaborator

Agreed, this is certainly a tool for everyone. However, you still need some kind of maintainer which keeps the lights on (update tools etc. regularly) and keeps and eye on the "architecture"... just like for the rest of the infrastructure...

odra Jan 28, 2026
Collaborator

I would like to present about how autosd will be included in the os_images repository, together with some autosd image builder updates (bootc) and how that integrates in a Bazel workflow.

odra Feb 5, 2026
Collaborator

@AlexanderLanin could you please add the topic of "autosd cpp toolchain"? Related PRs:

dcalavrezo-qorix · 2026-01-28T12:55:09Z

dcalavrezo-qorix
Jan 28, 2026
Collaborator

Weekly RUST 28-01-2026

14:00-15:00 CET

Participants

@dcalavrezo-qorix
@bharatGoswami8
@pawelrutkaq
@PLeVasseur

Agenda

prepared DR for clippy clippy: added decision record on how to integrate clippy #2466
prepared S-CORE execution contract draft execution contract #2475
still opened: - AP: we need to fork our own rules_rust and publish a release with our changes in our S-CORE BCR
issue from @MaximilianSoerenPollak https://github.com/orgs/eclipse-score/discussions/236#discussioncomment-15505810
- release new score_toolchain_rust with blanket and symbol-report incorporated
updated score_tooling to 1.1.0, incorporating bazel rules to easily produce RUST coverage
at this point we have a Demo coverage workflow set-up for persistency ferrocene: build with compiler persistency#201
- it will be switched to a reusable workflow
- the job fails if the configured coverage is not met - the gate is per test target/ component, not an overall one
- the line coverage for the RUST within the repo is 93%

---
Fully Tested: 131
Partially tested: 11
Fully untested: 6
Fully ignored: 24
Total: 172
---
Generated coverage report at /home/runner/.bazel/execroot/_main/bazel-out/k8-fastbuild/bin/coverage/rust-tests/__src_rust_rust_kvs_tests/blanket/index.html
Line coverage for //src/rust/rust_kvs:tests: 93.16% (913/980 lines)
Report for //src/rust/rust_kvs:tests: /home/runner/.bazel/execroot/_main/bazel-out/k8-fastbuild/bin/coverage/rust-tests/__src_rust_rust_kvs_tests/blanket/index.html
---
Overall line coverage: 93.16% (913/980 lines across 1 targets)

 -  you can download the artifacts/reports from here

https://github.com/eclipse-score/persistency/actions/runs/21402500267/artifacts/5273959839

Minutes

AP: identify how to consolidate coverage reports for mixed situations ( repos with both C++/ RUST code)

1 reply

PLeVasseur Jan 28, 2026
Collaborator

https://github.com/rustfoundation/safety-critical-rust-coding-guidelines

dcalavrezo-qorix · 2026-02-04T13:07:14Z

dcalavrezo-qorix
Feb 4, 2026
Collaborator

Weekly RUST 04-02-2026

14:00-15:00 CET

Participants

@dcalavrezo-qorix
@bharatGoswami8
@pawelrutkaq
@PLeVasseur
@CryptoNutcase
@sophokles73

Agenda

coding guidelines for RUST
clippy integration update

Minutes

reference: https://github.com/ANSSI-FR/rust-guide ( new version coming out soon ~ couple of weeks)

0 replies

AlexanderLanin · 2026-02-09T13:40:45Z

AlexanderLanin
Feb 9, 2026
Collaborator Author

Weekly

2025-02-09
To join the meeting see calendar in #107

Participants

@AlexanderLanin
@dcalavrezo-qorix
@FScholPer
@odra
@opajonk
@anmittag
A. Resetar
@jgetas
@kgraeper
@Lukasz-Juranek
@lurtz
@nick-hildebrant-etas
@nradakovic

Agenda / Minutes

Topic	Who	Discussion	Conclusion
autosd in os_images	@odra	present about how autosd will be included in the os_images repository, together with some autosd image	create a PR with proposed changes
builder updates (bootc) and how that integrates in a Bazel workflow	@odra
FYI: new ref int repo layout	@pawelrutkaq	cleaning up refrence_integration, reducing the number of module files	-
UT coverage	@FScholPer		@AlexanderLanin to align roadmap with @PiotrKorkus
Dev containers	@AlexanderLanin	size has reached > 4GB; do we need the full llvm package?	Ideas: VSCode extensions brings its own `clangd` ? Use `clangd` from bazel toolchain?
FYI: SBOM	@Lukasz-Juranek	PR in `score_tooling`, gets the dependencies for RUST/CPP	-

Next week

Topic	Who	Discussion	Conclusion
Reuse	@lurtz	reuse is active in devcontainer. Pros, Cons. Rollout everywhere? We can unbazilify yet another tool.	-

Lessons learned

We're currently repeatedly running out of time
We need links on all items for quick deep dives
We need concrete decision points and alternatives if we want to discuss some decision

0 replies

dcalavrezo-qorix · 2026-02-11T13:59:03Z

dcalavrezo-qorix
Feb 11, 2026
Collaborator

Weekly RUST 11-02-2026

14:00-15:00 CET

Participants

@dcalavrezo-qorix
@bharatGoswami8
@pawelrutkaq
@PLeVasseur
@darkwisebear
@MaximilianSoerenPollak

Agenda

rules_rust - we have don our own S-CORE fork - we need to port the QNX related fixes to it
score_toolchains_rust issues

Folks, I don’t know what kind of internal feud is going on, but this is open source and we do things in the open. Please don’t land breaking changes unannounced. If there’s a problem, bring it up and discuss it first.

  PR :https://github.com/eclipse-score/toolchains_rust/pull/14

  Recent change in score_toolchains_rust broke Linux builds:

  - Linux builds use the GCC toolchain (g++) and rules_rust passes -nodefaultlibs, so only explicitly listed libs are linked.
  - The GCC sysroot from @score_bazel_cpp_toolchains ships libstdc++ but not libc++, so -lc++ fails with ld: cannot find -lc++.
  - -lstdc++ is the correct default for GCC-based Linux; -lc++ likely targets QNX/clang (where libc++ is standard) and shouldn’t have been applied to the Linux GCC toolchain.

safety qualification board

Minutes

AP: add checks to toolchains to prevent breaking changes in the future
groomed our board

0 replies

AlexanderLanin · 2026-02-16T11:10:24Z

AlexanderLanin
Feb 16, 2026
Collaborator Author

Weekly

2025-02-16
To join the meeting see calendar in #107

Participants

Agenda / Minutes

Topic	Who	Decision to be made	Conclusion
pre-commit	@lurtz / @AlexanderLanin	see below	yes; details below
Reuse	@lurtz / @AlexanderLanin	reuse is active in devcontainer repo. We can unbazilify yet another tool (copyright checker). Anyone interested in leading this?	@lurtz will centralize this via pre-commit hooks
Infrastructure Docs	@AlexanderLanin	We now have `infrastructure` repo. Anyone interested in starting a docs build there with some initial content?	@arnoox, support by @MaximilianSoerenPollak
cicd-workflows	@AlexanderLanin	Presentation of DR Preparation: #repos for common workflows. Max 5 minute discussion.	presented, discussed, no contradictions to proposal
sync python tooling versions across repos	@AlexanderLanin	Yet another approach, which allows pyton tool/libs version sync with local dev, CI and devcontainer -> collect feedback on the idea	no decision. Next: will try this in 1-2 repos. Or move those mini-repos to devcontainer.
testlinker	@MaximilianSoerenPollak	see below	no output needed

2 replies

MaximilianSoerenPollak Feb 16, 2026
Collaborator

testlinker

Wanted behaviour of 'testlinker' in regards to properties found in xml files that it doesn't know.

Just do nothing => continue to run
Put out an info log that the properties is unknown => continue to run
Put out a warning => build would fail then

I would say the first or maybe a deubg log to print this (if wanted) would make most sense.
Currently it seems that it just errors when something like that is found that's why I bring it up.

Edit:

There is already an easy fix proposed. The question would now just be if the consumers would prefer to be notified by the testlinker if it sees some properties it doesn't know.

AlexanderLanin Feb 16, 2026
Collaborator Author

pre-commit

Some repos have started using pre-commit. We should align whether we want to use it.

Example 1 WF
Example 2 WF

Current behavior = agreed behavior:

in devcontainer: pre-commit is opt-out (when config is found in a repo, pre-commit is auto activated).
CI will verify in any case.
for non devcontainer its opt-in

Idea, not fully discussed yet: create a repo for all score pre-commit hooks (or reuse cicd-workflows, at least at the start)

pawelrutkaq · 2026-02-18T13:21:38Z

pawelrutkaq
Feb 18, 2026
Collaborator

Weekly RUST 18-02-2026

14:00-15:00 CET

Participants

@dcalavrezo-qorix
@bharatGoswami8
@pawelrutkaq
@darkwisebear
@arsibo

Agenda

rules_rust - PR to be reviewed

Minutes

Review requested ported S-CORE related QNX changes into rules_rust rules_rust#3
release name will be 0.68.1-score
next step, try to again adapt upstream via the platform_contrib module, and then we will use rules_rust from upstream again
@sophokles73 asked how to use S-CORE within Cargo itself -> currently S-CORE does not provide SDK, the question can be raised inthe Monday Architecture meeting.

0 replies

Eclipse S-CORE

Meeting Minutes #236

Uh oh!

Uh oh!

AlexanderLanin Jan 28, 2025 Collaborator

Replies: 97 comments · 27 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: 97 comments 27 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