cad/freecad-devel: Mark BROKEN
Fails to build,
"The Addon Manager requires the Python package 'defusedxml', which was not found"
Reported by: pkg-fallout
Force ACL application on app-owned ix-volume paths
## Problem
Enabling an ACL on an ix-volume of an installed app fails with `path contains existing data and 'force' was not specified`. The served schema hides the `force` flag for ix-volumes and defaults it to true, but clients can still submit an explicit false, and middleware then faithfully applies it - so the guard trips as soon as the app has written anything into its own volume, which is almost immediately after install. A false which has already been persisted is worse: on the next update validation rejects the config before normalization ever gets a chance to correct it.
## Solution
Add an `is_app_volume_path` helper and use it at the two places the same root cause surfaces. Both gates are structural - they hang off the ix-volume node itself rather than off what a path string happens to look like, because the two call sites are shared with host path ACLs and because an ix-volume's path is not final until the ix-volume ref has run.
**Normalization** - `normalize_ix_volume` stamps `force` to true right after it computes the volume's host path, in place, so the dict which gets written back to the app config agrees with the ACL which was actually applied and a stored false heals itself. Doing it there rather than in `normalize_acl` matters twice over: `normalize_acl` is also reached by `host_path_config.acl`, which must keep its data-loss guard, and for volumes whose `acl_entries` carries its own `normalize/acl` ref the child is normalized while descending, before the parent has re-pointed the path - a decision taken then would outlive the re-point. `dataset_name` is not validated as a path anywhere, so the containment check is what stops an absolute or `..`-laden one from steering the clamp onto somebody else's data.
**Validation** - `validate_question` threads a flag marking whether a node sits under a `normalize/ix_volume` parent, and `validate_acl_entries` skips the existing-data probe only for a contained path on such a node. It only skips, never mutates. The exemption is permanent rather than transitional: a volume with its ACL disabled keeps a persisted path and whatever force value was stored with it, and normalization ignores it because it has no entries, so without the skip that config stays unsavable forever.
The app name is threaded from `normalize_and_validate_values` through validation rather than read off `app_data`, which is None on create - and on create the volume datasets do not exist yet, so probing a real path there would raise a spurious `path does not exist`.
www/py-django_statici18n: Update to 2.7.1
* Assume maintainership.
* Switch to the PEP517 build framework to make the port future-proof.
* Use the more preferred DISTVERSION and fix LICENSE as well.
Changelog since 2.6.0:
https://github.com/zyegfryed/django-statici18n/blob/v2.7.1/docs/changelog.rst
PR: 297808
Reported by: Christos Longros
Co-authored-by: Kai Knoblich <kai at FreeBSD.org>
[ConstraintElim] Bound non-increasing header IVs by start value. (#217921)
Generalize addLowerBoundsForHeaderInductions to also support bounding
decrementing IVs: if the IV gets decremented w/o wapping in the signed
sense, it will never exceed the start value and we can add PN s<=
StartValue.
This helps to remove a number of branches in real-world workloads:
https://github.com/dtcxzyw/llvm-opt-benchmark-nightly/pull/984
Note that in a few instances (found 2), the removed branches result in
flags dropped. We should be able to recover those (and more) by using
info from ConstrantElimination to strengthen flags.
Alive2 Proof: https://alive2.llvm.org/ce/z/7t_xHX
PR: https://github.com/llvm/llvm-project/pull/217921
mail/protonmail-bridge: Add port: Proton Mail Bridge for e-mail clients
Use Proton Mail with your desktop email client.
Proton Mail Bridge adds end-to-end encryption to popular email apps,
including Outlook, Thunderbird, and Apple Mail. Secure email made
easy.
NOTE: Proton Mail Bridge is available only with a paid plan that
includes Proton Mail.
WWW: https://proton.me/mail/bridge
Force ACL application on app-owned ix-volume paths
## Problem
Enabling an ACL on an ix-volume of an installed app fails with `path contains existing data and 'force' was not specified`. The served schema hides the `force` flag for ix-volumes and defaults it to true, but clients can still submit an explicit false, and middleware then faithfully applies it - so the guard trips as soon as the app has written anything into its own volume, which is almost immediately after install. A false which has already been persisted is worse: on the next update validation rejects the config before normalization ever gets a chance to correct it.
## Solution
Add an `is_app_volume_path` helper and use it at the two places the same root cause surfaces.
**Normalization** - `normalize_acl` stamps `force` to true for paths inside the app's own volume directory, in place, so the dict which gets written back to the app config agrees with the ACL which was actually applied and a stored false heals itself. This is the single chokepoint for every ix-volume ACL apply; host path ACLs land in the same action dict and are distinguishable only by path, so they keep their default and their data-loss guard.
**Validation** - `validate_acl_entries` skips the existing-data probe for those paths, since forcing is implied for them. It only skips, never mutates. The exemption is permanent rather than transitional: a volume with its ACL disabled keeps a persisted path and whatever force value was stored with it, and normalization ignores it because it has no entries, so without the skip that config stays unsavable forever.
The app name is threaded from `normalize_and_validate_values` through validation rather than read off `app_data`, which is None on create - and on create the volume datasets do not exist yet, so probing a real path there would raise a spurious `path does not exist`.
flux2: Update to 2.9.4
Changes:
2.9.4
-----
Flux v2.9.4 is a patch release that ships various fixes to the Flux
controllers, covering source-watcher tarball extraction and glob
expansion limits, the refspecs accepted by ImageUpdateAutomation, the
HTTP request limits of the notification-controller servers, and Helm
repository index loading, OCI chart digest pinning, Bucket error
handling and GCS static authentication in source-controller. On the CLI
side, flux migrate -f now supports migrating repositories to Flux 2.9.
Users are encouraged to upgrade for the best experience.
Note that this release contains CRD schema changes for
ArtifactGenerator and ImageUpdateAutomation; both CRDs must be updated
along with the controllers.
