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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This function's got its argument order chosen for "aesthetical"
reason of $(2) following $(1) in the macros but the logical order
is exactly the opposite: we care for kernel flavour much more than
for module set (which is dependent upon it).
So while silent dropout of kernel-image if KFLAVOURS is set
but KMODULES is empty could be fixed by testing for $(2) only,
it looks like a good time to fix this discrepancy altogether.
As it happens, adding another architecture required almost no changes;
native 32-bit ppc build took only ARCH and a repo, qemu-ppc one still
has problems (/.host/entry hangs while unpacking setup for fakedata).
Proof of concept on a QS22:
$ make ve/bare.tar.gz
** ARCH: ppc
/bin/sh: rpmvercmp: command not found
21:41:01 cleaning up
21:41:03 initializing BUILDDIR: build/
21:41:03 preparing distro config
21:41:05 starting image build (coffee time)
21:42:48 done (1:42)
** image: $TMP/out/bare-20120716-ppc.tar.gz [21M]
The only thing to be fixed was setarch(8) symlinks assumption
that is correct for x86 but not for ARM.
There's also some hasher(7) setup to be done:
mkdir -p ~/.hasher
echo >> ~/.hasher/config <<-EOF
def_target=arm
#cache_dir=$HOME/tmp # depends on RAM/storage configuration
EOF
...and of course apt(8) should be properly set up too.
An example PoC build on a CM-A510 board (tmpfs):
$ make BRANDING=altlinux-centaurus ve/bare.tar.gz
** ARCH: arm
18:10:45 initializing BUILDDIR: build/
18:10:45 preparing distro config: build/distcfg.mk
18:10:46 starting image build: tail -f build/build.log
18:14:49 done (4:02)
** image: $TMP/out/bare-20120706-arm.tar.gz [23M]
An initial draft of it was done half a year ago but several tricky
thingies had kept the code from showing up as it was rather brittle
and incomplete.
This implementation involves quite a few changes all over the place
but finally works good enough for live and installer images.
Please pay attention to the versions of these packages:
- installer-feature-setup-plymouth (0.3.2-alt1+)
- branding-altlinux-sisyphus (20110706-alt2+ if used)
- plymouth (0.8.3-alt20.git20110406+)
See also:
- http://www.altlinux.org/Branding
- http://www.altlinux.org/Plymouth
This further refines the modular build by making
metadata being a clearly separated feature rather
than having to rely on runtime tests, and also by
moving the code which cares for kernel bits of base
installation (.base list) in a feature of its own.
There's more to it but let's get the ball rolling first.
As duly noted by glebfm@, branding issues need more attention
by now since only stage1/install2 got some of it so far in this
regard. Hence the dedicated feature comes to the rescue
(well no, it doesn't actually mess with rescue!).
The former toplevel Makefile is now toplevel main.mk;
this change allows for multi-target, multi-arch processing
in the current toplevel Makefile.
As the "build" symlink semantics change quite considerably
when one is doing bulk builds (several pruned builddirs might
be useful for comparison), BUILDDIR is now much more likely
to be recreated: the cases when it will persist are when it's
either a single-image build or when the prefix hasn't changed.
There are some more or less subtle bugfixes and enhancements
all over the map as well.
Done within 20111230..20120102 timeframe, actually...
If the build is (re-)run withing generated profile directory,
the makefiles no longer have ARCH passed by upstream -- the
upstream might be unreachable at that point indeed.
This is unfortunate but we should cope with that.
NB: might be revisited when architecture-specific packagelists emerge
since currently there's no difference in package lists so we can just
re-run the build for a different architecture but this might change...
This is quite a large-scale change since mkimage-profiles got used to
baking distributions over the last year, and virtual environments are
quite different, so e.g. image.in/Makefile had to be split in two with
the main part of it moved into features.in/iso/lib/.
Short overview:
- features.in/Makefile: lib/ support
(supporting VE images requires dynamic modifications
to image.in/Makefile before starting the build;
the most natural way to achieve that seems to use
features mechanism along with makefile include dir)
- packaging format related part moved into features.in/pack
(should be better prepared for diversity either)
- features.in/iso renamed to features.in/build-distro
- features.in/ve renamed to features.in/build-ve
+ NB: these could not be merged as e.g. features.in/build
due to completely different script hooks
- lib/image.mk renamed to lib/build.mk
- image, config, log postprocessing moved downstream
- added a sort of a topping in the form of lib/sugar.mk
- assorted style fixups (like ifeq usage)
- clean.mk: reliability fix (the problem was observed by Oleg Ivanov
and me too but finally it did get the attention quantum)
- reviewed, updated and extended docs
+ QUICKSTART: should be[come] a step-by-step guide
(thanks Leo-sp50 for prodiving feedback)
- image.in/functions.mk: rework kpackage()
+ it takes two arguments explicitly now: this adds some noise
for "generic" invocations but is rather less messy with recently
introduced STAGE1_KFLAVOUR (which in its turn is rather cleaner
than messing with KFLAVOURS, especially since soemthing changed
in presumably apt and we can't rely on kernel packages being
installed in the order formed).
- BUILDDIR/DEBUG related fixes
+ Makefile: BUILDDIR initialization moved to distro.mk
- build.log += git info
- drop hardwired kernel flavour from pkglists
- today's std-ng lacks aufs, let's switch to un-def
- second assault at KERNEL_PACKAGES_REGEXP
- re-introduced kpackages (builds ok)
PS: base lists: switch to grub, add udev, cleanup
