IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The sort key field value has been off-by-one apparently,
"6" corresponds to "capacity" field of df -PT output
while the "available" one was meant:
Filesystem Type 1024-blocks Used Available Capacity Mounted on
/dev/sda9 ext4 15350768 12799972 1747980 88% /
tmpfs tmpfs 1967204 27396 1939808 2% /tmp
1 2 3 4 5 6
This lapse has been five years old, looks like it's only
been masked by lower available space limit *and* filesystem
ordering by type so far. It didn't hit me even now, rather
inspected the code while implementing volumes-profile-starterkit...
As was found out by Vladimir Karpinsky (thanks for patience!),
the autochosen directory might still have too restrictive mount
options -- nodev and/or noexec. Hopefully the diags are a bit
better and faster by now.
It happens that if the host environment isn't particularly
tuned up for package builds already then bin/mktmpdir might
come up with a directory outside hasher-allowed prefix list;
now that's a shame and not a Christmas gift, clearly.
Thanks Vladimir Karpinsky for pointing this problem out too.
The fallback case of building in a brother directory moved
from the last line of code to the first one becoming more
explicit along the way.
Support for slash-containing argument (being a tmpdir name
template prefix) has been added.
With not-that-recent mkimage-profiles development,
it's no longer apparent that at least a gigabyte
of free space is required to build something useful
(at least for the tests, like syslinux.iso).
In short, the guesser cutoff margin is now 256M.
Just in case the build.log will be inobvious, and it's easy to diagnose
automatically. Thanks Andrey Stroganov for this use case.
Thanks for improving the initial implementation go to raorn@ for kind
commit lynch and to Yuri Bushmelev for actually suggesting something
more concise.
BTW the "1024" magic number was taken out of thin air:
the "no free space" errors are most likely to happen while
forming/populating a chroot (apt/rpm errors out) and chroots are
roughly two orders of magnitude heftier than a megabyte.
