shells/xonsh: Update to 0.23.4
- Update from 0.22.8 to 0.23.4
- Fix short and long descriptions (Reported by: Andy Kipp, makc)
- Move prompt-toolkit to RUN_DEPENDS as it is required for the interactive shell
- Combined backport from main
(Cherry picked from commits:
4af2752617fa, cb1add6ce17a, 4e15accd4c4c, 171de8a60868,
20eabb3ff3c3, 8d46b1cef06d, b2bc7a430fb3)
[compiler-rt][UBSan] Add __ubsan_default_suppressions() hook (#194862)
In line with commit 5c62af5 and 83566da.
Assisted-by: Gemini
---------
Co-authored-by: Vitaly Buka <vitalybuka at google.com>
devel/llvm{15-22}-libs: rewrite with proper OPTIONS framework
Replace hardcoded CMAKE_ARGS with proper OPTIONS_DEFINE/OPTIONS_DEFAULT
matching each parent port's default flavor. This ensures ABI-compatible
builds by using the same option-driven LLVM_ENABLE_PROJECTS (and
LLVM_ENABLE_RUNTIMES for llvm20+) as the full ports.
Key changes across all 8 -libs ports:
- Add PATCHDIR/FILESDIR pointing to parent port's files/
- Add SHEBANG_FILES, SUB_FILES/SUB_LIST from parent
- Add post-patch and post-patch-CLANG-on targets from parent
- Add post-patch-LLD-on where applicable (llvm15-17, llvm20-22)
- Use option-driven LLVM_ENABLE_PROJECTS construction
- Add proper backend definitions (BE_FREEBSD/NATIVE/STANDARD)
- Add arch-specific OPTIONS_EXCLUDE matching parent
- CLANG conditionally adds USES+=gnome (llvm15-19)
- LLDB conditionally adds USES+=gnome (llvm20-22)
- Remove hardcoded BUILD_DEPENDS for swig/pexpect (now via LLDB option)
gvfs: update to 1.60.0
* Enable gudev support on *BSD alongside some options depending on it.
* General clean-up, in respect of the good work PHO already did here.
* Some stuff has been moved to options.
* Update paths for dependencies imported in the main tree.
man: Kill off MANSUBDIRs
Three architecture dependent manuals are installed to MANSUBDIRs,
creating at least two empty manual page directories on everyone's
boxxen. Move those manuals to their canonical area, enhancing clarity,
grepability, removing useless inodes, and increasing consistency with
the rest of the architecture dependent manuals which are unconditionally
installed, and noted at the top of the rendered manual.
MFC after: 3 days
Undo some of the previous, restore flexibility
This is related to PR bin/59957 (in that it is a continuation/
alteration of the previous fix). This was primarily designed
to (hopefully) fix the ~80 extra ATF test failures that the previous
solution caused, by allowing the utilities to work as they had
previously, rather than attempting to enforce one universal true
world order.
Change the openspecial() function to be findspecial() as it no longer
opens anything - but leave it in openspecial.c for several reasons:
First, it might make sense to recreate openspecial() for use in just
those utilities that want to do all that it did (just 2 of the four
that were modified to use it).
Also, this function (or functions) really should be moved to libutil,
rather than buried in sbin/fsck (which doesn't even use it/them at all
- though could perhaps use the findspecial() variant), and I didn't see
[27 lines not shown]
ports.7/FILES: Expand and refactor into 3 tables
Add make.conf, CHANGES, CONTRIBUTING.Md, UPDATING, and Tools/scripts.
Refactor the FILES section of the ports reference manual into a bigger
table with three sections separated by root directory. Remove preceeding
article from all but "the big Kahuna", and root dirs where reasonable.
MFC after: 3 days
Relnotes: yes
Reported by: adamw, arrowd, linimon
Differential Revision: https://reviews.freebsd.org/D55441
Despite pooka's dislike of the situation, it is sometimes unavoidable
that systems within a given $MACHINE may have different vmparams.
Furthermore, rump is fundamentally a user-space entity on NetBSD, and
it's absolutely true that different $MACHINEs within a $MACHINE_ARCH
may legitimately have different vmparams related to physical memory
layout, and so using the real <machine/vmparams.h> is an impediment
to a $MACHINE_ARCH-generic user-space build.
As such, rump once again has its own vmparams.h file with values that
should be perfectly adequate for the rump virtual environment and its
non-existent subordinate user-space.
[MLIR][Presburger] Conversion between Int- and FracMatrix (#192822)
A straightforward conversion between `IntMatrix` and `FracMatrix`. This
is one further preparation PR.
The next step for upstreaming is to find a particular solution `x` to
the system `Ax = Bp + C`, which might contain fractions while `A`, `B`
and `C` are IntMatrices. That's the reason we need these conversion
helpers.
---------
Co-authored-by: Arjun Pitchanathan <arjunpitchanathan at gmail.com>
PR 58762: disable MKCOMPAT for earm*.
If someone is interested in re-adding support for oabi compat library
builds, they can figure out the missing bits. But for now, stop producing
bogus compat32/debug32 sets on all evbarm builds.
