git log may return color codes if users colored output forcibly enabled
with:
[color]
ui = always
Use `git rev-list` instead of `git log` to make sure that we don't get
any color codes.
fixes https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10042
Now all python packages that install python modules under
/usr/lib/pythonX.Y/site-packages will have a provider that indicates
their MAJOR (X) and MINOR (Y) versions.
pyX maps to the MAJOR version of the package, its objective is to allow
users to quickly install a python module without having to search around
for the correct package, doing `apk add py3.9:foo` will install whatever
packages provides the foo module.
The directories checked only go one level deep, so
'/usr/lib/python3.9/site-packages/date' will generate
py3:date=$pkgver-r$pkgrel.
files ending with .py also count and are added with their .py prefix
stripped away. so '/usr/lib/python3.9/site-packages/six.py' will
generate py3:six=$pkgver-r$pkgrel.
The reason for doing this is the same as creating pc:, so: and cmd:, it
is more reliable and robust to depened on what we known of what the package
provides than to try to guess via the pkgname.
Co-authored-by: Chloe Kudryavtsev <toast@toast.cafe>
If there are only empty files in the pkgdir, on some filesystems
(discovered on btrfs), du might return 0 for the sum size of the files.
But apk-tools considers packages with size = 0 to be virtual and skips
extraction of any files contained.
To work around that (until it is resolved in apk-tools 3), settings the
size to 1 when it is zero AND some files are present should work fine.
Simplify locking by using lockf(3). It is POSIX compatible and should
work over NFS.
Fix download race condition when:
1) host A creates lockfile and aquire lock to fetch from distfiles
mirror
2) host B opens the lockfile and waits for lock
3) host A gets 404 from distfiles, releases lock and deletes the
lockfile, which host A has an open file handle for
4) host B gets lock of the deleted file and downloads file
5) host A retries download and creates a new lockfile, but is not
blocked by host B, even if it should
Solve this by releaseing the lock, give the other processes a chance
to aquire it (using sleep(0)), and then only delete the lockfile if:
a) download was successful (no 404) or b) no-one else has a lock.
This reverts commit 281720ec39 (abuild-fetch: aquire a second lock
using flock(2))
fixes#10026
