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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
As noted in doc/assumptions.txt, the SHELL based target tracing
only works for rules with recipes, even empty but present ones.
The simplest thing to do is hooking "; @:" onto the rule's tail
(one-liner with a non-printing shell builting "true" command).
The purpose is being able to examine particular target interdependency
graph for a given image having been configured to avoid convoluted
dependencies (loops in particular).
The implementation is based on SHELL hook hint by John Graham-Cumming:
http://cmcrossroads.com/ask-mr-make/6535-tracing-rule-execution-in-gnu-make
As was duly noted by Leo-sp50, both server.mk and desktop.mk
duplicate a few bits layered over bare distro/installer which
happened to be both a dependency (thus should reduce redundancy)
and a "real distro" target (well, it doesn't just work yet, need
to provide networking and sources.list in install2 by hand).
Fixed by moving a "node" to distro/.installer along with typical
additions and leaving a bare installer as is by now; there's a
need to get it working at least for DHCP/ftp.altlinux.org case.
A minimal chroot supporting extension via apt-get;
vitals if built on Sisyphus as of Jan 16, 2012:
i586: 13M tar.xz, 58M chroot (33M w/o /usr/share/{doc,locale,man})
x86_64: 14M tar.xz, 60M chroot (35M w/o /usr/share/{doc,locale,man})
Trivial fixups (extra checks) added to two script hooks.
As was found out by Vladimir Karpinsky (thanks for patience!),
the autochosen directory might still have too restrictive mount
options -- nodev and/or noexec. Hopefully the diags are a bit
better and faster by now.
It was briefly mentioned in QUICKSTART but somehow managed
to evade the commandlines provided. And while at it, let's
make errors like this more explicit to avoid extra lookups.
Oh, and fix QUICKSTART so that readers miss the hassle. :)
Thanks Vladimir Karpinsky for pointing this problem out.
doc/variables.txt was missing the already-existing BUILDLOG
variable description, and ARCHES got added during multi-target
toplevel rewrite. Other minor fixes come as appropriate.
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...
First, let's not do rsync --delete on an unverified target dir
again: the lesson was learned during a subway hacking session
and I must say that SSDs are frightening fast (even if it was
more than a second to realize what happens and terminate the
extermination before it got /home, thanks xterm).
Second, let's use a variable for common name and make's own
realpath function instead of external binary.
Initial openSUSE package base taming effort has shown that
relatively few things should be fixed; subst has been generalized
as -i option to sed(1) since its introduction, so let's just fix it.
The idea is to check:
- the reachability of every target
used to build the image in question;
- the availability of all the package lists
and subsequently packages for that image;
- the lack of "dangling" intermediate targets,
features, pkglists, hooks etc.
So far only the first step is implemented --
it's easy and somewhat helpful already for
make CHECK=1 all
distro/.base target used to pull in localboot syslinux config
snippet which might be too early for some of the further distros;
it's a quite fragile equilibrium which was shifted a bit by imz@
(see #26606). Feel free to reopen the discussion though, things
might be tweaked so that localboot might be desirable on almost
every image even if with lower priority...
As was (quite reasonably) asked by someone and me too,
why should a successful build yield a *red* line
(a grep's default)?
So now it's new and improved, 25% free and so forth:
with a successful build you get a green line, while
errors from a broke one result in red ones.
Clinically tested in both b/w and w/b colour schemes;
in case you're not satisfied, please return original
ANSI_OK and ANSI_FAIL values to the colour dealer
and pass your favourite ones instead.
The features might get copy-pasted (or even copied-and-pruned)
when initialized; there's an unneccessary duplication of the
function name in the line adding it to FEATURES list, thus
prone to being forgotten and causing some havoc later on.
It was wrong in the first place but tackling this with some
double-colon rules ran into terminality issues, and further
tortures were considered unneccessary.
The current solution isn't perfect (no completely transparent
function name registration upon corresponding target being called)
but at least it is an improvement...
CLEAN is so useful and fiddling with .work chroots does
demand knowledge (hsh-shell is handy btw); so unless we
really get our hands dirty, let's spare ours preciouss
tmpfss.
- toplevel README received some long-needed refactoring
+ lowlevel detail moved, well, to lowlevel READMEs
- reflected more thoroughly that m-p is not about distros anymore
- dropped features.in/00example/README.en: it's already out-of-date
a bit, and there's no perceived need in thorough English docs so far
- wiki article got split into parts and somewhat rewritten, links updated
- mv doc/{CodingStyle,style.txt}
Essentially some more polishing:
- image path extracted from downstream build log;
- extended error/warning regexp a bit so those with
color grep options get even prettier output.
Notes:
- "1024" a magic number (briefly explained when introduced)
moved to a sort of variable;
- "100 lines" for tail(1) is a rule-of-thumb taking into account
typical amount of hasher/mkimage exhaust given GLOBAL_VERBOSE.
Preferences might be somewhat interesting too: while the official
ones shouldn't influence the build result at all, there's no whitelist
so all kinds of weirdness can be stuffed into local config in principle.
That should be diagnosable at least.
This one regulates the build wrapper: if the value is non-empty
then nice(1) and ionice(1) will be attempted so that the build
behaves better in regard to other tasks running on the system.
A few doc/variables.txt updates along the way.
Thanks torabora@ for yet again seemingly obvious feature request
which strangely managed to evade implementation before.
On an afterthought, mass builds would suggest too much coffee
instead of a progress indicator -- so implemented the latter.
NB: the actual downstream-make-calling rule would expand the "naive"
$(shell date) too early: the rule is evaluated before starting its
execution, and as it's the time consuming one the shell evaluation
was in need, not make's. The result is less generally available
(needs to be double quoted and won't work inside e.g. awk programs)
but way more precise.
If you make distro/live-builder.iso, the result is an image
containing almost everything (short of actual full enough
repository) to rebuild itself. It will attempt to configure
eth0 with DHCP and reach http://ftp.altlinux.org for packages.
RAM requirements start with 2Gb, self-build is accomplished
on a 4Gb host with "make CLEAN=1 distro/live-builder.iso".
Packages required for "make distro/syslinux.iso" get included.
(some due fixups all over the place too)
Implemented opportunistic alarm support as proposed by torabora;
the actual result depends on readline and/or terminal settings
(read up on "visual bell" vs "audible bell" in case it's wrong).
TODO: this ought to be shifted downstream when proper logging
framework is there.
This was asked for by Leo-sp50 and torabora, and seems quite reasonable:
let's provide means to keep at least some distribution configurations
a bit apart, so that these can be considered more standalone in terms
of hard warranted functionality but at the same time enjoying the common
infrastructure.
Considering lib/distro.mk: it's now experimentally pulled apart so that
parallel development of different distro families can go on without
major merge hassles. *Please* don't abuse with massive copy-paste.
And before you ask: this might get extended to allow for "private"
out-of-tree configurations being included since apparently there
are goals with no meaning outside of some very particular context...
but otherwise I'd like to encourage getting reusable bits in-tree.
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)
