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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Previously, you had to specify two parameters MKIMAGE_PREFIX and
GLOBAL_PREFIX with the same value - the path to mkimage. And this
behavior has not been documented. The GLOBAL_PREFIX variable is
defined in mkimage in config.mk and rules.mk.
More than one BOOTLOADER may be available for the same architecture.
Set IMAGE_PACKTYPE in boot/iso, there is no point in duplicating
in different features.
Closes ALT bug 39786.
This is necessary to prevent accidental hit of another branding.
Usually the problem is solved by setting up pkgpriorities in apt settings.
But this is inconvenient when you need to make building often with others
branding.
Every .iso was assumed to be bootable since the very beginning[*],
and isoboot images were deemed to be x86 isolinux ones; this didn't
change with basic ppc/armh support as I never ran into hardware
that would _boot_ those ISOs, not only run the code, and it was
only e2k isodata project that finally forced this refactoring.
It's still not perfect: pack and syslinux features still end up
somewhat interwoven, and too much places care for architecture
the image is being built for (instead of archdep features tossing
their appropriate bits and pieces in).
Should help:
- any-arch regarding isodata images;
- {x86,aarch64}/efi by decoupling isoboot and isolinux;
- ppc{,64} as introducing yaboot support will be easier now;
- mipsel{,64} too, hopefully.
* I knew of school addon images baked with mkimage-profiles-desktop
but postponed and then neglected the whole problem for years...
There's no qemu there so far, and there's no need
to fiddle with setarch either.
NB: part of this commit erroneously went into
1c777c8ad4
quite some time ago, sorry about the mess.
A classic brown paper bag bug: this was typed in a hospital
and that commit was a sick one indeed, the condition should
have been the opposite.
Reported-by: Ildar Mulyukov <ildar@altlinux.org>
Closes: #31982
Either /etc/hasher-priv/system or /etc/hasher-priv/user.d/$USER
must contain at least "allowed_mountpoints=/proc" for mkimage
to work for mkimage-profiles; thanks Daniil Golovanov for
providing feedback indicating the lack of the corresponding
checks.
This is an initial implementation of architecture dependent
contents handling for package lists more or less in the vein
of mkimage-profiles-desktop's one *but* using suffix part to
filter words in or out *not* prefix part to replace it with
a comment marker (thus filtering out lines).
The syntax should be pretty obvious:
a b@i586 c@x86_64
will get "a b" given ARCH=i586 and "a c" given ARCH=x86_64;
please see doc/archdep.txt for a more elaborate description
and a conversion script.
This one reduces the amount of output that's only
interesting when one is actually watching the console
during builds (at least the early stage) -- these tend
to look boilerplate and be useless when inspecting the
output of a large batch build like [[regular]] one.
The __frontend variable was introduced to address the needs
of alterator-mkimage module: list the images available in
one column, purge the builddir.
Looks like we should consider other cases with redirected
stdout (cron builds, piped calls, etc) like fundamentally
non-interactive and behave the same.
So commit 3a8af6b55d888d25c1d97561ed2ecf37ff28ad71's
description is wrong now; the current cleanup rules are:
- if CLEAN=0 or DEBUG>1, don't do it;
- if CHECK or REPORT is set, don't do it;
- otherwise if at least one of the following conditions is true:
+ there's more than one target being built in a row;
+ stdout was redirected (cronjob, alterator-mkimage...);
+ metaprofile directory is read-only
...then do a distclean.
If that doesn't suit your needs, describe the particular
situation please.
Thanks cas@ for wondering aloud whether greppable output
is unsupported with `make help'.
Yes these bits are related to distro/ prefixed images
still the overgeneralization in distro.mk didn't pay off
but rather hid a bug with the only boot/isolinux in use
having no dependency on use/syslinux (which is required).
Maybe this will get revisited when we have other kinds
of bootable images with other bootloaders (vm/ ones care
for themselves as of today).
There's a particular problem with lazy evaluation
in case of BOOT_LANG: mkimage uses internal variable,
BOOT_LANG = $(GLOBAL_BOOT_LANG) (note the lack of
immediate assignment there), and if we set up
export GLOBAL_BOOT_LANG = $(BOOT_LANG)
in the same namespace we end up with recursively
defined pair of variables; a ":=" in either place
would save the day _but_ it's not there in m-p due to
accumulator variables, e.g. USERS, which are defined
and exported by a corresponding feature and then get
populated *after* having been declared for export,
_and_ it's not in mkimage as of 0.2.16 for some reason
that might even be good (I don't know yet).
set() is a function of two variables but the and()
check for *both* is incorrect as one might need to
override a previously set variable with empty string;
this has manifested itself with a case like this:
@$(call set,ROOTPW_EMPTY,1)
# ...
@$(call set,ROOTPW_EMPTY,)
Just spotted that .disk/profile.tgz would hold
distcfg.mk with pre-expanded $(HOME) from build
host which is both info leak (user account that
was used to build the particular image) and just
wrong given that the in-image profile archive was
conceived as a means to pass that part of build
environment over instead of tying it to vendor.
Morale: premature optimization is premature.
This change is done to reduce ambiguity in some cases;
the previous intention has been to ease navigation when
staying in a particular directory, now it's been changed
in favour of convenient toplevel `git grep' in fact.
Both variants have their pros and cons, I just find myself
leaning to this one by now hence the commit. Feel free to
provide constructive criticism :)
Some path-related bitrot has also been fixed while at that.
The behaviour that sort of settled didn't actually follow
the principle of the least surprise when one really wanted
to have BUILDDIR available for inspection; DEBUG=2 would be
effective to achieve that but CLEAN=0 would not.
Thanks led@ for spotting and reporting this.
lib/*.mk aren't going to be parsed for build targets
in the near future; and the early placement of those
targets was superseded by a dedicated configuration
snippet directory so just move these bits there.
I've finally moved away from LC_MESSAGES=C on my main
development system half a year ago and finally spotted
that a grep for "Stop\.$" stopped to yield anything now.
This subprofile is akin to THE_* variables family: the configuration
bits and script hooks sitting there influence whatever chroot is
declared to be the user facing one in the end, whether it comes
from vm image or live subprofile.
The services feature ought to be a changeset of its own which would
be based on rootfs and become the base for ve/vm changes but I chose
to just do it atomically; some pre-existing duplicates are pruned now.
This one is a part of a larger rewrite to move away from
distro-centric build-up to configuration-centric one with
the particular packaging being of secondary importance
compared to actual functionality.
It happens when there are no separate arch/noarch subrepositories
but everything is dumped into a single directory like in installer
or live-builder environment (at least as of today).
Now this is ugly: instead of commoditizing the repetitive code
the result ended up working differently by creating several
repositories for the target subdirs instead of the single one
for the generated subprofile as a whole.
This results in .disk/profile.tgz being basically useless
in every image since c4311108ea.
