Using a subset of disabled tests from the base package, as others only
apply to >1.0
---
Additionally, disable test_chroma.py and test_client.py:
These tests have issues running in parallel, such as when building the
python 3.12 and 3.13 versions simultaneously.
E.g. when running nixpkgs-review or unlucky timing in hydra.
Usually issues show up as:
ValueError: An instance of Chroma already exists for ephemeral with different settings
The tests need to import onnxruntime (a transitive of chromadb),
however it has issues running in the build sandbox on aarch64-linux.
It may work at runtime, so the package is not marked broken, however it
will break tests, so the check phase is disabled when building on
aarch64-linux.
Since the issue comes via chromadb, we inherit its `doCheck` attribute.
On aarch64-linux onnxruntime cannot be imported, as it attempts to read
/sys/devices/system/cpu, which does not exist in the sandbox.
As onnxruntime cannot be imported, chromadb cannot be tested.
However, this issue only applies in the build sandbox, not at runtime.
Therefore the package doesn't need to be marked broken.
Updated the condition to check `buildPlatform` instead of `hostPlatform`,
as the issue relates to the build sandbox and is not a runtime issue.
Use `isAarch` and `isLinux` attributes instead of doing string comparison.
---
See https://github.com/NixOS/nixpkgs/pull/412528#discussion_r2129396116
And upstream onnxruntime issue: https://github.com/microsoft/onnxruntime/issues/10038
This addresses a TOCTOU (Time-of-Check to Time-of-Use) vulnerability in Nix's
build system that could potentially allow privilege escalation or unauthorized
file access during the build process.
The patch includes:
- Safe file operations using file descriptors
- Secure temporary directory handling
- Safe chown operations
- PassAsFile security improvements
- Path validation fixes
This addresses a TOCTOU (Time-of-Check to Time-of-Use) vulnerability in Nix's
build system that could potentially allow privilege escalation or unauthorized
file access during the build process.
The patch includes:
- Safe file operations using file descriptors
- Secure temporary directory handling
- Safe chown operations
- PassAsFile security improvements
- Path validation fixes
This addresses a TOCTOU (Time-of-Check to Time-of-Use) vulnerability in Nix's
build system that could potentially allow privilege escalation or unauthorized
file access during the build process.
The patch includes:
- Safe file operations using file descriptors
- Secure temporary directory handling
- Safe chown operations
- PassAsFile security improvements
- Path validation fixes
This addresses a TOCTOU (Time-of-Check to Time-of-Use) vulnerability in Nix's
build system that could potentially allow privilege escalation or unauthorized
file access during the build process.
The patch includes:
- Safe file operations using file descriptors
- Secure temporary directory handling
- Safe chown operations
- PassAsFile security improvements
- Path validation fixes
This manages the `2. status: stale` label for pull requests only (not
issues, yet) with the following conditions:
- The last event on the timeline of the Pull Request counts.
- Labeling and unlabeling of any kind are ignored.
- Older than 180 days are stale.
- Security labeled PRs are never stale.
To handle this label correctly, it's important to go through all pull
requests. Any approach to limit the list of PRs via search are not going
to work:
- Filtering by `updated` is not going to work, because it includes the
last time that *a label was set* on the PR. To actually find out whether
a PR is stale or not, the timeline of events needs to be looked at.
- Filtering by an existing stale label is not going to work either,
because such a label might have been added manually and thus breaking
the rules we set up here. Thus any existing label needs to be confirmed
as well.
We keep working through the PR, even though we don't have any eval
results. This will allow actually managing labels for much older PRs as
well. Most importantly, it will allow merge-conflict and stale-labeling
next.
This replaces the manual dispatch trigger with a batched run through all
pull requests every day. This has the small benefit of not having to
worry about backfilling labeling after fixing bugs - and the much bigger
one in being able to handle merge-conflict and stale labels properly
later. For those, it's inevitable to eventually scan through all PRs.
At this stage, the vast majority of PRs will still be skipped, because
there won't be an eval run with artifact available. This will be
improved in the next step.
Technically, the workflow_dispatch trigger is kept to allow easily
testing this in forks, where the scheduled jobs are disabled. The
triggered job will behave similar to the scheduled job, though, and have
no special inputs.
