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 problem at hand is that different kernels can have
varying module sets, and it makes sense to put four of
those at once sometimes; so avoid silly build breakage.
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.
I've just borrowed glebfm@'s one introduced by commit
ec23a8ec7baaf28474063082b7238f58e9ca119f 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.
This reverts commit 115a1901cd289e8a21a949378ee8bf85508f5cfa:
the change has not been tested properly unfortunately,
and it broke today's regular-rc builds fortunately;
there are no vulkan-{intel,radeon} packages in sisyphus
(only amdgpu), and these are present in lakostis@' repo:
http://www.unsafe.ru/lakostis/RPMS/ALTLinux/glvnd/repo/x86_64/RPMS.hasher/
Just drop the whole thing until it gets sorted out.
The whole RADEON_PACKAGES affair was introduced to deal
with fglrx/radeon incompatibility; it got basically
deprecated following fglrx removal from sisyphus,
and lakostis@ should have done "add" logic instead
of reusing the "set" one inappropriately.
Fixes: 85c52d71c68860d73ef3efa17038407ef1e04b1e
See-also: https://lists.altlinux.org/pipermail/devel/2019-July/208126.html
Signed UEFI loader not required for aarch64.
NB: i586 images don't need UEFI SB either
and 32-bit shim is used for x86_64 images
along with proper 64-bit one.
This reverts commit 1b457a5d859e2bdec957ba59b21baab55448a73c.
It wasn't prudent to switch everyone to master FTP server;
Yandex mirror still has an order of magnitude more bandwidth.
The problem is that `chkconfig dm on' will enable
display manager service on *all* runlevels feasible
without paying any attention to its customary subset
of those; the solution seems just to avoid that.
Note that there's at least one more similar case
with networking services vs runlevels 2 and 3;
it's to be handled either in a similar manner,
or somewhat more generically.
Reported-by: Konstantin Savun and Speccyfighter
Suggested-by: Anton Midyukov <antohami@altlinux.org>
See-also: https://bugzilla.altlinux.org/36967
See-also: https://forum.altlinux.org/index.php?topic=36177.msg340553#msg340553
See-also: https://www.opennet.ru/openforum/vsluhforumID3/117762.html#81
