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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
tavolga-image-tool contains helpers for building images
for Tavolga Terminal; doing that on other platforms
is highly unlikely (x86 means qemu host, of course).
recovery.tar needed for tavolga (mipsel).
This commit is the result of transferring the required functionality
from build-mr (mipsel rootfs).
This change uses external tool to build Tavolga-compatible
recovery.tar. This simplifies the logic and avoids having
recovery workdir in the profile.
After this change, m-p will require tavolga-image-tools >= 3.0.
Looks like the initial empirical rule "mixin must not depend
on another mixin" is too restrictive for practical purposes
given enough image targets multiplied by enough platforms;
let's declare it obsolete and see what follows.
The builder-useradd package installs components of ALT build
environment into the system, namely gear, hasher, and git-core
required for those to work.
I've just borrowed glebfm@'s one introduced by commit
ec23a8ec7b before; this
still might be improved it seems.
Suggested-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
build-vm ceases to be a target for building only virtual machine images.
Now it can be used to build tarballs designed for installation on real
machines.
This commit is the result of transferring the required functionality from
build-mr (mipsel rootfs) by Ivan Melnikov <iv@altlinux.org>.
NB: mike@ strongly objected to this dilution but gave up eventually;
the whole kernel/build-vm/tar2fs/pack mess should be split into
distinct layers busy with their own responsibilities:
1) a tarball with kernel is done without tar2fs at all
(and no build-vm bits should be needed either, maybe
it's worth splitting and renaming as "vm" meaning
disk image for some armh board is grossly misleading);
2) a tarball with kernel can be further (multi-)packed
as, well, (compressed) tarball and a disk image
(only the latter one should employ build-vm/tar2fs);
3) compression should be done in pack feature style,
preferably described once and not duplicated all over
the profile for every single new kind of its output.
In the mean time, running into this and moving no further
starts to hurt more than it could help.
