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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
"-a arch" is not requisite either; and having bunches
of empty lines in the resulting pkglists that are user
visible at least within the conventional installer's
alterator-pkg (groups selection) module wouldn't be nice.
I chose to sacrifice empty-line separators for clarity;
the really good cleanup would save *single* empty lines
between chunks of non-empty ones (not at the pkglist's
start or end); feel free to implement that as well.
This has been clearly lacking while making the previous commit
but the implementation isn't that clear so let it be a separate
step.
The problem requiring the change in subsequent processors
is that these relied upon "@arch" as a flag to be inspected,
and "pkg@!arch1,arch2" on arch2 needs to take out *all* of that
fragment *including* arch1 mention as well.
Part of the cause is difference in handling: "positive" multi-match
would explode its "client" line into multiple lines to filter down
the pipeline, while "negative" multi-match *has* to keep that line
on a similarly single line (otherwise we'd end up with N-1 of those
slipping past the filter for particular architecture thus defeating
the whole purpose of "negative" matching semantics):
$ echo 'pkg@!E2K,mipsel,riscv64' |
sed -r ':loop; s/^((([^@]+@!)[^,]+)+),([a-zA-Z0-9_]+)/\1@!\4/; t loop'
pkg@!E2K@!mipsel@!riscv64
I've tried my best to test this specific change but it still might
introduce a regression in some corner case; feel free to report;
looks like there's a space for improvement in m-p's automated
tests department as well.
So now we can do:
pkg@!ARCHES1,ARCHES2,arch3,arch4
and have pkg excluded on arches mentioned; the previous approach
could only offer explicit whitelists (not that it was entirely
wrong but then again, we have both ExclusiveArch and ExcludeArch
rpmtags in our spec files).
This has been inspired by a few commits that cared
for package availability reasons on a particular
architecture; the problem at hand is that pkglists
might need to include groups of packages that are
(un)available on groups of arches, and tackling that
with plain pkg@arch just results in combinatorial
explosion of that matrix.
Arches are handled one-by-one with a few hardcoded
macro substitutions.
Exploding a "pkg@arch1,arch2" string into a set of:
pkg@arch1
pkg@arch2
with subsequent archdep pruning would do the trick;
so here's another sed oneliner that does just that:
$ echo 'pkg@X86,ARM,ppc64le' |
sed -r ':loop; s/^((([^@]+@)[^,]+)+),([^,]+)/\1\n\3\4/; t loop'
pkg@X86
pkg@ARM
pkg@ppc64le
See-also: 9601a9e7ce92c7a521fd154f59d8e17524f12a95
See-also: 5581dc91ec6f3330c338995d1cdfbca285298011
See-also: http://stackoverflow.com/a/55781741/561921
The @META suffix is used to expand the metapackage into a list.
apt asks for the dependencies of such a package and adds them to the
package list after this metapackage.
The missing glob resulted in disk images properly
partitioned only for e2kv3 ("e2k" for historical
reasons in ALT), and v4+ ones only got a single
ext4 partition that wouldn't work with current
MCST's Boot code.
While this argument can only have one "EFI" value.
Thus, the problem of building an image for Raspberry Pi on armh,
where there is no grub-efi, was solved.
If build is performed on a system with EFI Secure Boot enabled,
then grub will not boot even on EFI without Secure Boot.
This problem is caused by the use of the --removable option, which
is not compatible with option --uefi-secure-boot the current grub.
Option --uefi-secure-boot is enabled automatically if the system is
booted in EFI Secure Boot mode.
I've long wanted to have this nice helper around in m-p too
but might have set the bar too high.
The "prorper integration" idea was to have the script check
just those pkglists which are relevant for a given image IIRC.
Let's toss it in to begin.
This code started breeding within pkg.in/*/Makefile,
and it was lacking both E2K (as a generic alias,
not just "e2k or e2kv4") _and_ the ability to negate
selection, as in "everywhere but not on any e2k").
Let's fix all of that at once, and parallelize sed
execution as well; my tests with 1000-line file
containing "a b c d@!E2K e@e2k f g@!X86 h i@IA32"
lines show roughly 3x higher CPU load and lower
execution time (~0.3 sec vs ~0.9 sec on 801-PC).
And turn that code snippet into a proper filter
with inline edit capability (I've dropped the exit
trap as failing to mv signals a disaster anyway).
This commit fixes duplication of root device entry in /etc/fstab
and changes LABEL=ROOT entry with the proper one if found.
Apparently this didn't hurt qemu images much though...
Sometimes REPORT=1 just wasn't passed to make, and the build.log
saved is noisy and harder to compare through diff(1); let's move
the implementation out of the makefile and into a standalone
script so it can be reused like this:
BUILDDIR=$(sed -rn "s/^mki-image-scripts: export GLOBAL_BUILDDIR='(.*)'$/\1/p" build/build.log
bin/cleanlog < build/build.log > build/reports/clean.log
See "export GLOBAL_BUILDDIR=" line in the particular log
(grabbing that one from stdin is not exactly trivial though).
Changing ROOTFS owner causes a problem:
created image's root directory is owned
by user executing make instead of root.
Changing WORKDIR owner is unnecessary
because it will be removed anyways.
The original commit broke system tar2fs use by accidentally
moving TOPDIR definition into a separate shell execution;
thanks iv@ for spotting and fixing it promptly.
Co-authored-by: Ivan A. Melnikov" <iv@altlinux.org>
This one supports multiple kernels (and tweaks boot
labels aiming to simplify target kernel selection
for the CPU at hand) instead of an earlier attempt
to fill in a template.
No need for the template so just drop it.
The current state made vm images belong to root group,
no reason to not change those to the primary group of
the user building an image.
kpartx -d -s could fail in some circumstances,
make a safety cleanup call more verbose.
