lang/zig015: copy from lang/zig
Create the lang/zig015 for ports not ready for Zig 0.16.0 and depending
on Zig 0.15
PR: 294741
Approved by: arrowd (co-mentor)
rge: add the Intel Killer E5000 PCI ID
This and the E3000 are both handled by the r8169 driver in Linux, and
reportedly this is infact just a straight re-brand of the RTL8126.
Tested by: "Sinetek" on Discord
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D56917
NAS-140905 / 27.0.0-BETA.1 / Stop migration 0015 from forcing MISSION_CRITICAL profile (by creatorcary) (#18918)
Two small fixes for issues present on Goldeye:
- Migration `0015_update_profile.py` was force-setting `update.profile =
MISSION_CRITICAL` on every enterprise system regardless of the running
version's actual profile. A user upgrading from Fangtooth to a Goldeye
`EARLY_ADOPTER` release (e.g. 25.10-RC.1) was silently locked into
`MISSION_CRITICAL`. Once 25.10.3 (the first `MISSION_CRITICAL` Goldeye
release) shipped, `update.status` started returning a profile mismatch
and the `CurrentlyRunningVersionDoesNotMatchProfile` alert fired.
Migration is now a no-op; `update.config` already auto-populates
`profile` from `current_version_profile()` on first read.
- The mismatch alert was resolving profile names through
`update.profile_choices`, which filters out profiles outside the user's
product type (enterprise hides `DEVELOPER`/`EARLY_ADOPTER`). When the
running profile fell outside that filter, the alert text rendered
`<Unknown>` instead of the friendly name. Switched to resolving via
`UpdateProfiles[...].describe().name`.
[7 lines not shown]
libregex: fix our mapping for \w
A small oversight in our implementation of \w is that it's actually
not strictly [[:alnum:]]. According to the GNU documentation, it's
actually [[:alnum:]] + underscore. The fix is rather trivial: just add
it to our set explicitly, and amend our test set to be sure that _ is
actually included.
PR: 287396
(cherry picked from commit d0ff5773cefaf3fa41b1be3e44ca35bd9d5f68ee)
[libc] Fix BigInt shift on big-endian platforms (#196957)
BigInt<128> stores the value in two separate word sized array slots
with the low 64 bits being stored in val[0] and high 64 bits in val[1].
This can't be reinterpreted as a 128 bit value on big-endian platforms
because the values are reversed.
This has caused test failures on s390x builds of V8:
https://issues.chromium.org/issues/511831894
---------
Co-authored-by: Guillaume Chatelet <gchatelet at google.com>
NAS-140946 / 27.0.0-BETA.1 / Add basic NFSv4 change-attribute regression tests (#18919)
This commit adds a variety of tests in which we validate the behavior
the the NFSv4 change-attribute FATTR4_CHANGE over a variety of NFS
operations that should advance it.
