S-CORE & QNX

[AlexanderLanin]

QNX 2026-01-28 15:00 CET

Link to join the meeting is in #score-infrastructure slack channel

⚠️ Beware parallel edits of this discussion.

We’re planning a meeting with QNX on short notice (~24h). Apologies for the rush—please share any topics you’d like to discuss.

• How to update QNX Tarball with new features
  • Process for tarball update (contact person/update every 2 weeks/S-Core ticket)
  • Current request: Update & Extension needed for efficient image generation:
    • QNX® SDP 8.0.3 (or later) with following additional QNX SDP packages integrated:
    • QNX® SDP 8.0 Networking - io-sock Virtio Drivers
    • QNX® SDP 8.0 Virtualization Drivers (Block)
    • QNX® SDP 8.0 Virtualization Drivers (Startup)
    • Raspberry pi 5 BSP support
• Publishing QNX-based S-Core images on GitHub as part of the S-Core releases (do we have a problem with „High risk application“ definition)
• Do we need a technical user license in CI (currently running with private Anton’s license)

---

Meeting Minutes

Participants

@AlexanderLanin (ETAS)
A. Gryc (QNX)
C. Sinnot (QNX)
@dcalavrezo-qorix (Qorix)
@jgetas (ETAS)
J Hanam (QNX)
@antonkri (BMW)
@odra (RedHat)
@FScholPer (Mercedes Benz)
@evinoth1206 (ETAS)

Minutes

• QNX wants to provide a regulary updated tarball (first one within 1-2 weeks)
  How to update QNX Tarball with new features

  • Requested packages can be included
  • Cadence: no internal monthly release, so monthly tarball update would not make much sense
  • Contact on QNX side is J Hanam.
  • First tarball as-as, later potential optimizations as in next point

• Storing tarball / image in S-CORE for testing, delivery and demos
  Publishing QNX-based S-Core images on GitHub as part of the S-Core releases (do we have a problem with „High risk application“ definition)

  • QNX needs to clarify internally

• Future optimizations

  • QNX will support score to generate the tarball ourselves via QNX Everywhere
    • Potentially by providing the recipe to individuals
  • S-CORE demand is probably: one size fits all, for a reference build
  • Outside S-CORE individual parties have their own QNX contracts as required for customized builds

• BSPSs:

  • Pi5 and qemu are available from software center, either source or prebuild.

• Technical User:
  Do we need a technical user license in CI (currently running with private Anton’s license)

  • QNX needs to clarify internally. Maybe based on an eclipse email address? Any other ideas by score?

• Follow-Up meeting in ~2 weeks

[AlexanderLanin]

QNX 2026-02-11 15:00 CET

Participants

@AlexanderLanin (ETAS)
A. Gryc (QNX)
C. Sinnot (QNX)
@jgetas (ETAS)
J Hanam (QNX)
@antonkri (BMW)
@pawelrutkaq
@FScholPer (Mercedes Benz)

Minutes

• QNX can provide opt-in multi user non-commercial license for "high risk" development, in addition to the current QNX non-commercial everywhere license which does not allow development of "high risk" applications. To be signed by participating companies as they see it as a requirement. Basically the new license allows "high risk" development, without any guarantees.
  • Note: we are not lawyers. The actual license text applies.
  • A. Gryc (QNX) will follow up with next formal steps.
  • QNX needs to know the S-CORE legal entity name. @FScholPer will provide it to angryc@qnx.com
• Prebuild QNX image can be provided by S-CORE, but must include a very clear statement that a QNX license is required, e.g. the everywhere license or this new license type.
  • After the license above is established, we can align on a concrete solution e.g. README text.
  • Note: for now the tarball still cannot be stored in S-CORE and must be downloaded every time on demand.
    • A. Gryc (QNX) to follow up on public hosting possibilities of the tarball.
    • @AlexanderLanin to follow up on private hosting possibilities in S-CORE (accessible to all committers + CICD)
• tarball
  • QNX: new tarball almost ready
  • S-CORE feedback: new tarball has super slow download (30 minutes, 10.000% slower). QNX to follow up.
  • S-CORE feedback: current/old tarball download fails very very often. This script is used for download. QNX will follow up. Example failure. Used core to trigger the error. S-CORE contact i.e. @pawelrutkaq (reach via Slack)
• Do we need a technical user license in CI (currently running with private Anton’s license) --> @FScholPer will clarify with Eclipse Foundation.
• We'll try Slack chat for faster iterations: Initial subscription, and then direct link to the chat: #score-qnx

Follow-Up

Bi-Weekly Wednesday 15:00 CEST (UTC+1) - S-CORE & QNX Meeting

• iCal (Outlook import)
• Web View
• Google Calendar
• Direct Zoom Link: https://eclipse.zoom.us/j/85906130055?pwd=G44Cg6MSbtrL28ThxBI0VOFRay6aQe.1

[JohnAtQNX]

Howdy! I think we have worked through the two tarball-related points above:

• slow download caused by no regional cloud caching (solved, hopefully)
• CI fails to download tarball solved by CI config change

[pawelrutkaq]

slow is still as slow as it was ;(

[JohnAtQNX]

Pawel confirmed offline that it is quick for them now.

[AlexanderLanin]

QNX 2026-02-25 15:00 CET

Participants

@AlexanderLanin (ETAS)
A. Gryc (QNX)
C. Sinnot (QNX)
@jgetas (ETAS)
J Hanam (QNX)
@antonkri (BMW)
@FScholPer (Mercedes Benz)

Minutes

• Update: license is in legal discussion at QNX. Initial alignment with Eclipse done. BMW will be pilot user.
• Fixed: new tarball has normal download speed
• can timeout be increased in S-CORE to avoid rare timeout problems? Root cause not analyzed yet.
• Info: QNX is investigating mass market compliance, to avoid export restrictions, this will simplify hosting tars/images at score.
• use QNX Software Centre CLI for download individual tarball contents, instead of prebuild static tarball files? To be investigated, whether that is helpful or another indirection? (this is probably especially interesting if we can host a self pre-builded tarball at score)
  • An example package list:
    https://gitlab.com/qnx/custom-target-image-builds/repo/-/blob/release/CTI-8.0.3r2/targets/rpi4/qsc_install_packages.list
  • And the example use in a Makefile (but applicable to a CI environment too):
    https://gitlab.com/qnx/custom-target-image-builds/repo/-/blob/release/CTI-8.0.3r2/Makefile?ref_type=heads#L110
  • Support: John Hanam
• Update on technical user license in CI (currently running with private Anton’s license):
  • We need a user with a MyQNX account, with a proper email address that someone actually maintains.
  • Andy (QNX) will respond to Waynes email
• Note: the two March metings are cancelled; we concentrate on slack chat (Initial subscription, and then direct link to the chat: #score-qnx)

[AlexanderLanin]

Reminder: the two March metings are cancelled; we concentrate on slack chat (Initial subscription, and then direct link to the chat: #score-qnx). Next meeting 2026-04-08.

[AlexanderLanin]

QNX 2026-04-08 15:00 CEST

Participants

@AlexanderLanin (ETAS)
C. Sinnot (QNX)
@jgetas (ETAS)
@FScholPer (Mercedes Benz)
@dcalavrezo-qorix

Minutes

• Storage: eclipse can provide us storage which is only accessible to CI and committers. Requires feedback from QNX regarding: Can you provide more details on what exactly is expected? As far as I understand regardless of tarball download or tarball creation we need to store it non publicly. Or was that resolved by now? See full comment by Wayne: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/7305
• QNX 8.0.3 SDP provided via tarball at https://www.qnx.com/download/feature.html?programid=87174 / https://www.qnx.com/download/download/87174/installation_qnx_803_260305.tar.xz. Score will discuss upgrade at https://github.com/orgs/eclipse-score/discussions/434#discussioncomment-16387676

Open points, not discussed:

• technical user license in CI (currently running with private Anton’s license)
• use QNX Software Centre CLI for download individual tarball contents
• can timeout be increased in S-CORE to avoid rare timeout problems? Root cause not analyzed yet.
• QNX is investigating mass market compliance, to avoid export restrictions, this will simplify hosting tars/images at score.
• S-CORE specific license, and therefore storage of build artifacts (image)

[antonkri]

QNX 2026-04-22 15:00 CEST

Participants

@jgetas (ETAS)
@JohnAtQNX
Karumuri Hari (LGE)
@antonkri

Minutes

• Storing SDP tarball within score to avoid unstable qnx download site
  • Probably initial identification is a problem that leads sometimes to longer timeouts. We may need to increate the timeout.
  • For now the storing of the tarball at S-Core infrastructure is still not possible from the legal point of view. QNX is still looking into it.
  • Using CLI could solve the problem, as
    • this would have text file as a list of all packages, that are needed
    • CLI binary could be hosted on S-Core as it doesn't contain any QNX "Secrets".
    • Identification can be much faster, as we do not depend on the "WebServer Cookie" approach.
  • Usage of technical user license -> @JohnAtQNX will clarify.
• Exact requirements for publishing qnx images in score
  • @AlexanderLanin will need to follow-up with @JohnAtQNX per email.
• Why we cant download 8.0.3 tarball with the commercial license
  • @JohnAtQNX will ping the team and will answer in the slack channel
  • QNX 8.0.4 is available
    • Do we want to switch to 8.0.4, we assume, that yes
    • Do we want to build another tarball with 8.0.4 or may be we should go for a "proper solution" with CLI.

[AlexanderLanin]

QNX 2026-05-06 15:00 CEST

Participants

@AlexanderLanin
@jgetas
@FScholPer

Agenda

• Storing SDP tarball
• technical user license
• Exact requirements for publishing qnx images in score
• Why we cant download 8.0.3 tarball with the commercial license
• S-Core high risk license
• Using CLI tool instead of tarballs (stabler download, user facing decision on updates, not dependent on qnx tarballs)

[AlexanderLanin]

QNX 2026-05-20 15:00 CEST

Participants

@AlexanderLanin
John (partial)
Andy
@nradakovic
@FScholPer (partial)
@dcalavrezo-qorix (partial)

Agenda / Minutes

• QNX License Agreement for S-CORE to replace/extend the QNX Everywhere license for development of high risk applications: first version was sent to @antonkri for review by BMW legal team. If approved by BMW as an early adopter, QNX will offer it to all S-CORE developers.
  --> R: @antonkri

• Request: QNX 8.0.4 via tarball from QNX, as we cannot build and store it ourselves (see above) -> R: John

• Can we store the QNX SDP in S-CORE? Eclipse is wiling to support, but we need the exact requirements. Either downloaded or self-build with the CLI tool, but it would help to store that stuff locally. For obvious performance reasons, and also more importantly for bazel caching, as it would be invalidated every time.

  • Absolute minimum: access only to CI (therefore kind of the same as storing a secret to download the SDP on the fly) (1)
  • Better: store it with access to few users (e.g. 5)
  • Better: access by "qnx-committers" (aka score members with write access and a qnx account) (~30)
  • Better: access by committers (aka score members with write access) (~50)
  • Better: access by all registered score developers (~200)
  • --> R: Andy

• How about CI license-key in general? We are still using the one from Anton (BMW), which doesn’t seem quite right. This is currently being discussed between QNX and eclipse (Wayne & Christian). Andy will ping them again to get this resolved :-) --> R: Andy

• Does QNX offer any API to query whether a user has a QNX account? e.g. authorize someone else to query such data as in typical oauth scenarios. -> no

• How about a personalized SDP-build-server within score, which will pass through credentials to QNX CLI and respond with a "personal SDP download link"? -> score would need to request such a server. any other implementation ideas?

---

• What are the exact requirements for publishing qnx images? You mentioned “making clear that this is score and not qnx in a README”?!

[AlexanderLanin]

QNX 2026-06-03 15:00 CEST

Participants

@AlexanderLanin
Andy
@antonkri
John
@dcalavrezo-qorix
Sistlajr

Agenda / Minutes

• QNX is working on extending their license agreements to contain rules for consortiums, will cover e.g. sharing SDP and generated images within the consortium (non public) --> R: Andy (but on vacation)

-> within S-CORE we need to find a place where to store the SDP etc. Currently the only thing we have is github cache?!

• How is QNX used in S-CORE?
  Within CICD it's used via setup-qnx-sdp action

• QNX SDP 8.0.4 package, as shared in Chat: https://www.qnx.com/download/feature.html?programid=88447

[nradakovic]

QNX 2026-06-17 15:00 CEST

Participants

@AlexanderLanin
@dcalavrezo-qorix
@antonkri
Berugu Suresh
@nradakovic
Sri Ram Yedula

Open Topics

Request: response here/via mail/via slack

• QNX is working on extending their license agreements to contain rules for consortiums, will cover e.g. sharing SDP and generated images within the consortium (non public)
• Building SDP during Bazel build using qnxsoftwarecenter_clt:
  • Is it possible to override default location of license file?
  • In case of multiple license keys, who has priority, which key is selected?
  • Using patchset list to generate SDP --> is it possible that one user generate a list and another user generate a SDP from the patchset list?
• Options for building SDP:
  • Repository rule installs SDP directly
    → one go, label-addressable, poor cacheability
  • Normal rule builds SDP archive
    → cacheable, but requires second step to consume as repository
  • Prebuild/publish SDP archive
    → best Bazel-native user experience
  • Normal rule produces tree artifact
    → one go and cacheable, but contents are opaque to filegroup/glob

[AlexanderLanin]

Note by Dan:

for the licensing resolution - from own experiments -try playing with env variables

QNX_CONFIGURATION_EXCLUSIVE- > overrides QNX_CONFIGURATION - > LM_LICENSE_FILE

that way you can override the default location
but the clear behavior is not described

[AlexanderLanin]

Note: Meeting on July 1st is cancelled

[AlexanderLanin]

QNX 2026-07-15 15:00 CEST

Participants

@AlexanderLanin
@lmilne-qnx
@JohnAtQNX
@Rutuja-Patil-Bosch
@arbassett
@FScholPer
Larry

Meeting Minutes

• "QNX is working on extending their license agreements to contain rules for consortiums, will cover e.g. sharing SDP and generated images within the consortium (non public)"
  • in progress, draft expected in 2 weeks
• eclipse-score/bazel_cpp_toolchains#68
• Old questoins to be followed up:
  • Is it possible to override default location of license file?
  • In case of multiple license keys, who has priority, which key is selected?
  • Using patchset list to generate SDP --> is it possible that one user generate a list and another user generate a SDP from the patchset list?

[JohnAtQNX]

Sorry for the delay! I have answers to the questions above now. Big thanks to my colleague Sandy for the help.

Is it possible to override default location of license file?
Yes! The default location is /.qnx (the QNX_CONFIGURATION environment variable points at this location). The documentation for defining a different location for the licenses file is here: https://www.qnx.com/developers/docs/qsc/com.qnx.doc.qsc.user_guide/topic/configure_default_location.html?hl=qnx_configuration

In case of multiple license keys, who has priority, which key is selected?
If you have been assigned multiple licenses that are all associated to the same SDP version, then you need to decide which to use and activate it. At any given time, you can only have ONE activated license per SDP version. There shouldn't be any scenario where multiple license keys are activated for the same SDP version. QNX tools look for the activated license.

Using patchset list to generate SDP --> is it possible that one user generate a list and another user generate a SDP from the patchset list?
Absolutely; that is the purpose of the patchset. User 1 can set up an installation using QSC then export the patchset. As long as User 2 has access to the same set of packages as User 1, User 2 can install the patchset to create an identical installation.

[AlexanderLanin]

QNX 2026-07-29 15:00 CEST

Participants

@AlexanderLanin
@antonkri
@dcalavrezo-qorix
Andy G

Meeting Minutes

• in progress, but vacation season:
  • cli questions above
  • licensing
    • ideal goal:
      • SDP - within the consortium (non public)
      • generated images for qemu / raspberry etc - public

[AlexanderLanin]

QNX 2026-08-12 15:00 CEST

Participants

@AlexanderLanin
Andy G
@jgetas
Aaron B
John H

Meeting Minutes

• license adjustment draft is ready. Now waiting for legal feedback from @antonkri (BMW as an exemplary OEM) and Wayne (Eclipse)
  • storage will be restricted to S-CORE consortium aka https://projects.eclipse.org/projects/automotive.score/who aka https://github.com/orgs/eclipse-score/people
• 8.0.5 for Inotify broken in SDPs up to 8.0.4 bazel_cpp_toolchains#68 would take 2 weeks + vacation delay. So the legal approach should even be faster at this point of time.
• starting today we may store QNX binaries as required for Inotify broken in SDPs up to 8.0.4 bazel_cpp_toolchains#68!

[AlexanderLanin]

QNX 2026-08-26 15:00 CEST

Participants

• @AlexanderLanin (ETAS)
• Andy Gryc (QNX)
• @antonkri (BMW)
• John Hanam (QNX)
• Aaron Bassett (QNX)
• @nradakovic (BMW)

Meeting Minutes

• Update on exception letter for QDL: good progress so far, required feedback was received. Either letter or time-plan expected end of the week.
  • Next: S-CORE to collect feedback from eclipse foundation, as technically no counter signing is required. But someone needs to store it etc. --> @AlexanderLanin
  • Next: Eclipse foundation to formally confirm that https://github.com/orgs/eclipse-score/people is a subset of https://projects.eclipse.org/projects/automotive.score/who --> @AlexanderLanin
  • Next/open: re-request (3rd time) private storage from eclipse foundation, restricted to S-CORE members + S-CORE CICD. Alternatively setup a private repository. --> @AlexanderLanin
• QNX 8.0.5 is released, but no ready-to-use tarball for S-CORE exists. Expectation is that with the above approach S-CORE can create their own tarball. --> @nradakovic
• floating license server was requested within S-CORE. Currently all developers have their own personal free license. --> Andy Gryc
• cicd license was never solved. Needs to be an eclipse account with a proper email address etc. Was previously discussed with Wayne Beaton --> Andy Cryc

Reference for QNX usage in S-CORE:

I would like to explain our intended approach for using and distributing the QNX binaries within our build system.
Our plan is as follows:

1. We will use the QNX Software Center CLI to acquire and configure a predefined QNX environment containing all components required by our build system.
2. The SDP QNX binaries themselves will not be modified, patched, or otherwise altered in any way. We will use the binaries exactly as provided by QNX through the QNX Software Center. In particular, once the binaries have been acquired by the QNX Software Center, no modifications or patches will be applied to them.
3. The QNX environment will be provisioned and packaged by a dedicated release pipeline in the toolchains_gcc_packages repository. This ensures that the package is created in a controlled build/release environment rather than on an individual developer's machine. The pipeline will use Otterdog-provided secrets (QNX license) to facilitate the download and use of the QNX Software Center CLI.
4. The packages will be uploaded to Eclipse Foundation infrastructure so that they can be consumed by the S-CORE build system and by S-CORE members:

• 1. S-CORE CI/CD pipelines: The S-CORE CI/CD infrastructure should use a dedicated technical/service account and associated credentials for accessing the QNX SDP packages. This avoids tying automated builds to individual developer accounts and provides a controlled and auditable mechanism for CI/CD systems to retrieve the required packages.
• 2. S-CORE members: Access for individual users will be restricted to verified S-CORE members. The QNX packages will therefore not be generally accessible to the public.

5. The resulting package will contain the QNX installation without any license files, credentials, or other license-related information. A valid QNX license will still be required to actually use the toolchain for compilation, linking, and QNX image generation.
6. The resulting package is expected to be approximately 1 GB per supported platform. Currently, we have two supported platforms, but this is not a fixed limitation, and the number could increase to approximately 10 different platforms (versions).
7. The user will provide the QNX license separately through the public license API exposed by our Bazel build system. The license itself will therefore not be included in, or distributed together with, the QNX binary package.
8. The process of creating the QNX SDP package and consuming it in the build system are completely separated. The QNX SDP package stored on Eclipse Foundation infrastructure will be treated as an immutable artifact and will not be modified after it has been produced. In addition, the Bazel build system has a built-in mechanism for verifying the checksum of downloaded packages. Therefore, any deviation from the expected package contents will cause the build to fail rather than allowing a modified package to be consumed.

With regard to patching, Bazel's native repository rules support applying patches to downloaded sources or artifacts. However, our implementation uses a Bazel Module Extension to download and provision the QNX package, and the corresponding API/mechanism does not provide support for applying patches in this way. More importantly, our intended process does not require or permit modification of the QNX SDP binaries in the first place.
The main idea is therefore to keep the creation, distribution, and consumption of the unmodified QNX binaries separate from QNX licensing. The release pipeline provides the required QNX binaries in a controlled, reproducible, and preconfigured form, while the resulting artifact is treated as immutable and verified by checksum when consumed by Bazel. Access to the packages is restricted to S-CORE members and CI/CD infrastructure, while each S-CORE member remains responsible for providing a valid QNX license when using the QNX SDP binaries.

[AlexanderLanin]

QNX 2026-09-09 15:00 CEST

Participants

• @AlexanderLanin (ETAS)
• John Hanam (QNX)
• @dcalavrezo-qorix
• Cris Sonnott

Meeting Minutes

• Update on exception letter for QDL: done
  • Next/open: re-request (3rd time) private storage from eclipse foundation, restricted to S-CORE members + S-CORE CICD. Alternatively setup a private repository. --> @AlexanderLanin
  • open/new: who is liable in case of a leak of qnx artefacts? like human error during review. Is it that person? personally? eclipse as the letter was addressed to them? -> John
  • new: attempt CI design which does not permit ~100 people to change CI workflow which has access to QNX artifacts --> @AlexanderLanin
• QNX 8.0.5 is released, but no ready-to-use tarball for S-CORE exists. Expectation is that with the above approach S-CORE can create their own tarball. --> @nradakovic
• floating license server was requested within S-CORE. Currently all developers have their own personal free license. --> Andy Gryc
• cicd license was never solved. Needs to be an eclipse account with a proper email address etc. Was previously discussed with Wayne Beaton --> Andy Cryc

Meeting on 23rd September is cancelled ⚠️

[AlexanderLanin]

S-CORE & Eclipse - 2026-09-17 14:30 CEST

Participants

• @AlexanderLanin
• @antonkri
• @nradakovic
• @waynebeaton
• @chheis
• maria teresa delgado
• carmen delgado
• @MaximilianSoerenPollak

Agenda

How can we store and use QNX binaries in S-CORE?
Usage: see two posts higher.

Meeting Minutes

---

Current Setup

Identified alternative

We could move the workflow triggers. Moving the workflow trigger helps with secrets, but that doesn't help with security. It's a lot of effort and complexity, for "powerpoint security", without improving anything.

Spread the knowledge

Only CODEOWNERS can approve QNX-related workflows. Whoever is added as CODEOWNER must be informed of the discussions here.

---

"QNX artifact downloader" repo

We'd setup a qnx_sdp repo (or something like that, or reuse an existing one). We don't see any problem in making that repo public.

-> verify with QNX, but sounds ok

technical user

Which user we will use to access, download and execute QNX Software Center?

--> @waynebeaton

Storage

Where

private github repo (to get started today), or any other artifact storage system
e.g. storage of gcc packages works fine via github repo releases: https://github.com/eclipse-score/toolchains_gcc_packages/releases

--> delegated to Eclipse-IT guys (e.g. Matt)

Who will have access to this location?

All S-CORE members? Only committers? Only a select group?

-> if private repository, by default all project leads + committers + contributors have access

[AlexanderLanin]

@waynebeaton do you have any update on the technical user for qnx license / download?