Landed as 5d4139f8bdb67bd6e8328422f9762661bd0d6454

• rebase
• update devel/Makefile
• science/py-emmet-core: switch to devel/py-setuptools_scm7 (instead of patching setup.py)

rebase, add math/py-matplotlib

rebase after committing some missing ${PY_SETUPTOOLS} cases

fix typo in science/py-emmet-core

rebase

At least www/webkit2-gtk successfully built under libc++ without #define _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR run in a libc++ with the define, though this may be due to dynamic linking.

In D43910#1003335, @brooks wrote:

I'm not assigned or CC'd on any bug reports that I can see so I'm not sure how I'm supposed to be triaging these issues. Rust has definitely has built for me (it's usually the longest pole in retesting textproc/R-cran-xml2 due to its utterly terrible build parallelism). I'm building cargo-c now and can test other things if people tell me about them. I'm not going to do a revert based on "certain programs are still crashing".

In D43858#1002921, @kib wrote:

Describing awful things that happens does not provide any useful input for debugging. There is some code in the build system of your port that failing, and I need to see it, either as source or binary, with direct instructions to check.

Ideally, t is some binary that does "a" instead of "b". If the binary needs some dso's not from the base system, I need them as well.

In D43858#1002919, @kib wrote:

In D43858#1002662, @vishwin wrote:

In D43858#1002638, @kib wrote:

Try D43910

Still crashes.

Then provide me some min example of rust code that crashes.

In D43910#1002661, @netchild wrote:

Can the issues this patch is supposed to fix lead to compile issues? I see failing rust and cargo-c builds in the "libc" part. And I see issues with nslookup to a bind 9.18 which serves an internal domain.

If yes, would it be a good idea to back out the libsys changes and ask people to give the patchset a real world test and some ports exp run?

In D43858#1002638, @kib wrote:

Try D43910

I've had to revert only rG968a18975adc locally (other commits are fine) due to a number of programs crashing, timing out or refusing to run. This extends to port builds that happen to use afflicted programs, either already existing as dependencies or built to support the rest of the build.

rebase

This is probably needed for the latest versions of www/webkit2-gtk, which use C++20 and these constructors/destructors amongst other things.

Abandoning, as this builds but doesn't function (JavaScriptCore thread indefinite wait condition). 2.42 WIP in a new review

fix www/epiphany's corresponding devel/libsoup3 LIB_DEPENDS

UPDATING entry also to come.

rebase

rebase

rebase

Also don't forget to add a MOVED entry.

Looks like @sunpoet has taken the bug so they will handle the commit, with maintainer of the service_identity port approving.

• devel/py-setuptools-scm: flip two more consumers

• devel/py-ddtrace: setuptools-scm max version not set upstream, remove
• science/py-emmet-core: remove setuptools-scm version restrictions

rebase again

Committed but the auto-close didn't work

• bsd.gecko.mk: add :noexport to USES=llvm, for any GCC cases

another stray conflict mark

• devel/wasi-{compiler-rt,libcxx}: add WITHOUT_CPU_CFLAGS
• devel/wasi-libc: remove BULK_MEMORY_SOURCES omission, all gecko now supports those opcodes

phab...

• devel/wasi-{compiler-rt,libcxx}17: sync to 17.0.5

remove stray conflict artefact

• devel/wasi-libc: remove extra ${CC} after USES=llvm default export

• devel/wasi-{compiler-rt,libcxx}17: sync to 17.0.3
• Revert "gecko-esr: limit to LLVM 15 due to old proc-macro2 crate"

rebase after devel/py-pytoolconfig update

• devel/py-setuptools-scm: "temporarily" add devel/py-wheel
• benchmarks/py-asv: fix devel/py-setuptools-scm

• remove archivers/unzip, use ${UNZIP_NATIVE_CMD}

• devel/py-setuptools-scm: add BUILD_DEPENDS=${PY_SETUPTOOLS} to consumers
• devel/py-{flit-scm,hatch-vcs}: add RUN_DEPENDS=${PY_SETUPTOOLS}

• devel/py-setuptools_scm: move directory to match updated package name
• devel/py-setuptools-scm: switch consumers

• update to 8.0.4

updating this to 8.0.4

This is wrong. Use D42144 instead

• handle devel/py-pybind11's USE_PYTHON=concurrent