strictly speaking, it is possible for an x86_64 cpu to run 32-bit
userspace binaries without qemu emulation. it is also possible for an
aarch64 cpu to run armhf/armv7 binaries (as long as the cpu implements
it, most do). rather than check for every possible combination of when
this is allowed (host cpu + emulated target, does cpu support it, ...),
just downgrade this case to a warning, to permit non-emulated use.
ref https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/117#note_255174
these have a slight runtime hit (like fortify-source), but help find
bugs early, by making programs crash on invariants that would corrupt
memory and lead to hard to debug crashes/bugs later.
these are mostly useless and redundant given the other flags. all they
do is spam more flags onto every invocation line- things don't "only"
pass cppflags for anything in the general case.
There's some extra indentation on the first sections that doesn't match
other man pages and just looks misaligned with the rest of the page.
Example from man:
```
NAME
man – display manual pages
SYNOPSIS
man [-acfhklw] [-C file] [-M path] [-m path] [-S subsection]
[[-s] section] name ...
DESCRIPTION
```
Example from newapkbuild before this patch:
```
NAME
newapkbuild - generate a new APKBUILD
SYNOPSIS
newapkbuild options... [pkgname[-pkgver] | source_url]
DESCRIPTION
```
Example for newapkbuild after this patch:
```
NAME
newapkbuild - generate a new APKBUILD
SYNOPSIS
newapkbuild options... [pkgname[-pkgver] | source_url]
DESCRIPTION
```
this fetches only things for the target triple, so it usually skips e.g.
all the windows crates.
we do this in aports already, in places where it doesn't work we just
unset it.
- -G Ninja because that is always preferred
- remove inferred trailing dot
- use =ON as that is what we usually use most of the time for true/false
- add samurai to makedeps for -G Ninja
- use flatter ctest invocation
this is a good thing to have and we should reinstate it after 3.18,
however it requires fixing a million things, which is a bit too much for
a sudden release build.
i forgot the implications of this aside from fixing strerror_r and how
much work it was, so put this back after 3.18 branch.
otherwise every package prints
>>> gotosocial-openrc*: Running postcheck for gotosocial-openrc
find: /builds/raspbeguy/aports/testing/gotosocial/pkg/gotosocial-openrc/usr/lib/python*: No such file or directory
the other postchecks already conditionalise on if [ -d, but we use a wildcard here
no actual package change
Python by default pre-compiles cache files in __pycache__ directories,
which we currently happily install along in python packages.
Theses .pyc files are rather big and the time/space tradeoff could be
left to users if we just split these out to a -pyc subpackage.
With this default_pyc helper, one can add $pkgname-pyc to their
package's subpackages and it will automatically split off the pyc files
in a package that will be automatically installed if the virtual 'pyc'
package is installed.
Note that this does not work so easily if there already were python
subpackages, the function could be adjusted to strip off the last dash
if required but that seems rather rare.
Random data, sizes:
- python3: currently 47MiB, split into 23M (main package) / 24M (pyc)
- py3-markdown: currently 700KiB, 368K (main) / 288K (pyc)
Random benchmark, with python3-pyc:
hyperfine --warmup 5 -m 100 \
"python3 -c 'import time; print(time.strftime(\"%T\"))'"
Time (mean ± σ): 24.5 ms ± 2.5 ms [User: 18.4 ms, System: 6.0 ms]
Range (min … max): 19.4 ms … 28.9 ms 148 runs
without python3-pyc (same as user without root permissions, root would
generate files on first root, for reference this command generates 184KB
of pyc files):
hyperfine --warmup 5 -m 100 \
-p 'rm -rf /usr/lib/python3.10/__pycache__ /usr/lib/python3.10/encodings/__pycache__' \
"python3 -c 'import time; print(time.strftime(\"%T\"))'"
Time (mean ± σ): 53.7 ms ± 4.3 ms [User: 39.3 ms, System: 14.3 ms]
Range (min … max): 47.0 ms … 65.6 ms 100 runs
Link: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11906
Suggested-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
Packages installing python3 site packages for python3 in version 3.x.y
depend on python3~3.x. This automatically adds the required
dependencies.
Unit test cases have been added by reusing the `py3-foo-and-bar` test
package. However, the path of that has been renamed to contain spaces
to be extra sure the logic is safe in regrade to spaces in path
names.
Otherwise, if a different REPODEST is being used (e.g. due to
`buildrepo -d <repo-dest>`) then the abuild invocation in the
created chroot will not write packages to the correct REPODEST.
Therefore, `buildrepo -R -d` does presently not work correctly.
This commit fixes this by also copying the REPODEST value from
the environment.
This fixes a regression introduced in 1582617eb8.