…already

according to the language docs

This is required for corrscope, also see #271863 (comment)

Diff: ActiveState/cpython@v2.7.18.7...v2.7.18.8

When native-compiling, gcc will install libraries into:

  /nix/store/...-$targetConfig-gcc-$version-lib/lib

When cross-compiling, gcc will install libraries into:

  /nix/store/...-$targetConfig-gcc-$version-lib/$targetConfig

When cross-compiling, we intended to create a link from $lib/lib to
$lib/$targetConfig, so that downstream users can always safely
assume that "${lib.getLib stdenv.cc.cc}/lib" is where the gcc
libraries are, regardless of whether `stdenv.cc.cc` is a cross
compiler or a native compiler.

Unfortunately, there were two problems with how we were trying to
create these links:

1. The link would be created only when `enableLibGccOutput==true`

2. The link was being created from the incorrect source
   `$lib/lib/lib` instead of `$lib/lib`.

Both of these mistakes are my fault.  This commit corrects them by
creating the link using `ln -Ts` (which is more predictable) and by
creating the link from `gcc/common/builder.nix` rather than from
`gcc/common/libgcc.nix`.

Changes: https://gitlab.gnome.org/GNOME/librsvg/-/releases/2.57.2

librsvg: 2.57.1 -> 2.57.2

Pulseaudio 17 crashes in certain situations with alsa_ucm devices, see https://gitlab.archlinux.org/archlinux/packaging/packages/pulseaudio/-/issues/4.
This happens for example on the PinePhone, leaving it with no audio.
Applying the two patches as done on Arch Linux solves this for me.

In order to have the 'reset' LUA_PATH (aka `;;`) work, and for purity
reasons(removing /usr paths) we(I) decided to patch the lua interpreters default LUA_PATH.
Turns out the interpreters have different defaults and the patch was too
coarse.
There is smarter patching that can be done via LUA_ROOT.

Also luajit doesn't need patching at all since LUA_ROOT is set via the
build system.

when LUA_PATH contains `;;`, it is replaced by `;LUA_PATH_DEFAULT;` in
lua 5.1:
Updated https://github.com/lua/lua/blob/69ea087dff1daba25a2000dfb8f1883c17545b7a/loadlib.c#L599
More recent versions might be smarter ?
https://github.com/lua/lua/blob/65b07dd53d7938a60112fc4473f5cad3473e3534/loadlib.c#L301

now that the lua interpreters include working directories with `./?.lua`
in LUA_PATH, the current test includes every derivation which quickly
becomes unreadable and unpractical.
The test is adapted to add a folder only if it can find lua files in the
subfolder.

explain why they are patched in nixpkgs.

with the lua patching

https://discourse.gnome.org/t/libxml2-2-12-6-released/19989
https://gitlab.gnome.org/GNOME/libxml2/-/compare/v2.12.5...v2.12.6

gcc: link $lib/lib -> $lib/$targetConfig correctly and consistently

ffmpeg: enable ffplay in small variant

pulseaudio: fix crash with alsa_ucm devices

luajit: adjust defaults LUA_(C)PATH

https://gitlab.gnome.org/GNOME/at-spi2-core/-/compare/AT_SPI2_CORE_2_50_1...AT_SPI2_CORE_2_50_2

For the 11.0 SDK, base the stubs on the SDK for now.

https://hydra.nixos.org/build/254162453/nixlog/2/tail
See issue #300635

even if luajitPackages.http is broken.
I'm confident that most people don't use it,
so at least those should get immediately unblocked.
(The main derivation only uses it for this test.)

This reverts commit f8b4e28.

We're instead disabling the failing test on the django derivation.

With the revert of xz 5.4.6 (down from 5.6.0) this test started failing
on aarch64-linux on Python 3.12.

With the revert of xz 5.4.6 (down from 5.6.0) this test started failing
on aarch64-linux on Python 3.12.

[staging-next] Fix python312Packages.django_{4,5} on aarch64-linux