Early versions of automake have `autoconf` hardcoded into them as a
program that should exist. We *were* "fixing" this by creating a symlink
in autoconf-2.54. However this symlink is _not_ in the repo package,
which broke some things. Also meant that from autoconf 2.54 through
autoconf 2.71, automake was using autoconf 2.53.
Let's make it consistent by having autoconf symlinks in every autoconf
package.
deal with github mysteriously running actions with "ubuntu-latest" not resolving to 24.04. check for current ubuntu version and only do bwrap fix it >= 24.04
also, patch flakey flex mirrors, which were not working
Ever since an old patch version, it has (for reasonable security
reasons) not supported patched with ../ in the filename.
Many of our patches have been relying on this behaviour being OK,
because we start off with an ancient patch version that didn't perform
such checks. As soon as we need this behaviour after we build a newer
patch though, we will have problems.
So, let's change the policy.
Patches are relative to where tarballs are extracted, rather than the
"working directory" - e.g. have patches for `coreutils-9.4/src/cp.c`
instead of `src/cp.c`.
Keeping this consistent has a few implications;
- patches are applied from the build/ directory in bash era now, with
`-p0`
- when patches are manually applied in the bash era, use `-p` as
required, usually `-p1`
- in kaem era where patches are always manually applied, `-p1` is used
While this works for now, it's not a sustainable solution.
Supporting a simpler SSL library (small enough to bundle into srcfs) such as BearSSL or WolfSSL in the first build of curl would be preferable.
There isn't really any reason to use gzip instead of bzip2 for the Linux
initramfs/kernel, since we have it!
Saves a few MB (~13MB as far as I can tell)
Because src_get was never unset at the end of a build, it would propagate to subsequent builds until it would be either overridden again, or cleared by a new bash process starting (either due to a jump step or a new version of bash being built).
Thus, kexec-linux's override of src_get to a no-op would stay in effect in chroot mode until musl-1.2.4 phase2's override restored src_get's functionality. This override is actually obsolete, since musl-1.2.4's source code is now preserved across the Linux kexec via a different mechanism - but removing it mysteriously broke downloading bash-5.2.15 due to kexec-linux's override still being in effect.
