vasilito
48a924c561
The libredox 0.1.19 / redox_syscall 0.9.1 bump left 45 recipe lockfiles pinning libredox 0.1.18+rb0.3.1 and redox_syscall 0.9.0+rb0.3.1. The cookbook builds with --locked, so every affected recipe died with error: cannot update the lock file .../Cargo.lock because --locked was passed to prevent this which is what took out redox-driver-sys -- and with it every Red Bear driver -- during the redbear-full build. Regenerating the fork lockfiles was not enough; the recipes that consume the forks as path deps carry their own. This is step 6 of local/docs/FORK-BUMP-PATCHING-POLICY.md applied to the recipe layer. Also drop the hardcoded GCC version in recipes/libs/libstdcxx-v3: the literal include/c++/13.2.0 stopped resolving the moment the cross toolchain moved to 16.1.0, leaving -I pointing at a directory that does not exist. Now resolves the newest installed C++ header directory and fails loudly if there is none. Same failure class as the hardcoded 13.2.0 in mk/prefix.mk. Note: a few recipe-level Cargo.lock files (redox-driver-pci, cpufreqd, redbear-acmd/-ecmd/-ftdi) sit beside a recipe.toml whose [source] is path = "source", so they are not build inputs; redox-driver-pci's even references a redox-driver-core/Cargo.toml that does not exist. They are left alone rather than given meaning they do not have. redox-driver-sys now cooks clean.
This directory contains various files used by the gccadmin account on gcc.gnu.org, mainly for automated tasks such as the daily update of the date in gcc/DATESTAMP. There isn't presently any scheme for files checked in here to be automatically checked out and used by gccadmin, so the files in Subversion and those used by gccadmin must be kept in sync manually.