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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
*_PACKAGES and *_LISTS shouldn't inflict copypasted blocks;
we can iterate over these just fine.
NB: dump-*, not dump_*, due to namespace pollution hurting
debug target if done the latter way (in case someone misses
the morning tea as wel).
As current devmapper doesn't allow for simultaneous
mounts of virtually the same device by different names
(signalled by "Device or resource busy" when trying to
e.g. mount /dev/sda2 but with /dev/evms/sda2 being just
fine), EVMS triggering such behaviour but rarely needed
should be avoided altogether until a hook to disable it
is in place.
Fixed up the remnants of the early style mix
to correspond to the proposed doc/style.txt;
the rationale being that
if [ ... ]; then
...
...
fi
is the more readable construct among itself,
if test ...; then
...
...
fi
and
[ ... ] && {
...
...
}
due to the condition being more distinguishable
when bracketed and the body more apparent as the
one inside "if" and not any other block; the less
obvious difference is that the final construct of
the latter form is prone to the whole script exit
status being non-zero if the condition isn't met.
Some parts of *image* configuration started slipping down
into the *feature* configuration, and that was wrong; fixed.
Also introduced proper use/live/x11 (via use/x11/xorg with added
wacom support for the sake of #26723/#26724) and rebased the
pre-existing descendants onto it.
As too many things started duplicating between distros proper
and (e.g. corresponding) LiveCDs, it became apparent that a class
of entities which end up working for THE_USER (not a sysadmin,
and not a developer, just a Linux user) is in need.
So THE_KMODULES will power installed basesystem and live image,
while THE_PACKAGES, THE_LISTS and THE_GROUPS will participate
in building those.
- parameter order fixed to "simple first, then those with args"
and documented as the preferred one (might be debatable, okay)
- added "lowmem" to live so it avoids a ramdisk but works off media
(it's a knob for propagator)
- added "fastboot" everywhere (but failsafe install) to make use
of Linux 2.6.29+ async controller initialization
- every snippet got a trailing newline so that isolinux.cfg is readable
And a fancy makefile to check for shortcut dups!
Some more filesystem related utilities inspired by PLD rescue
are due indeed; but ntfsprogs are obsoleted by ntfs-3g, in fact.
iotop and iperf were suggested by stalker@.
Here we go with postprocessing priorities along the way
as ISO hybridization has to occur before implanting
final MD5 sum (which must happen earlier than e.g. some
external MD5SUM file generation).
Unfortunately proper dependencies aren't applicable here
(though I'd like to be proved wrong on this one).
Please note that this needs propagator > 20101130-alt9
for automatic mode to work (has also been worked around
in gfxboot case with design-bootloader-source-6.0-alt1).
Thanks rom_as@ for asking about the hybrid image status
and helping out with testing.
This one used to use LIVE_MAIN_GROUPS which seems to be
overlooked substitution artifact from walking over
GLOBAL_PKG_GROUPS and GLOBAL_LIVE_PKG_GROUPS of m-p-d...
(not that LIVE_GROUPS are defined anywhere yet)
Actually there's an added duplication in the form of the
test that was previously missing in pkg.in/lists/Makefile
-- that has to be done properly when it's clear how.
This fully omits pkg/lists/.base generation in environments
that won't make use of it.
The outmost shell loop got replaced with a (hidden) bunch
of targets -- it's somewhat controversial as the inner loops
are still there (but at least don't wrap around my SXGA+).
Full targetization might be beneficial in terms of parallelism
achievable *but* that would ruin git history being generated,
and building a distro configuration takes a few seconds at most.
(upon reading http://stackoverflow.com/questions/5414418/)
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
The bin/pkgdups.sh script comes from m-p-d in considerably optimized
form and is to be used with the pkglist files of interest passed
as its arguments to produce a "hall of duplicates" among those.
The tagged lists received some updates along the rescue image lines,
most of those are actually inspired by http://rescuecd.pld-linux.org/
and to lesser extent a few articles on rescue/recovery/forensics
software -- so some newcomers are even employed already.
New stuff:
* distro/live-icewm -- basic icewm livecd with autologin;
* distro/live-rescue -- yet another gparted^Wrescue CD.
A better part of base+rescue tagged pkglist split off into
extra+rescue where the content belongs.
Thanks ruslandh@ for proposing to do a graphical rescue with some
particular tools (albeit qt4-fsarchiver clearly needs more work).
use/live/autologin target tries hard to configure any available
autologin means, including a dedicated package and a few DMs.
Thanks gns@ as liveflash.eeepc got robbed somewhat.
distro/live-builder target used to employ a few duplicated
packages that might make it to a list but as the list would
have only a single user so far these were moved to a target-
specific variable (hm, weird but "private" modifier broke).
Actually this is the proper rewrite that was looming ever since
tgz support was introduced: there are multiple archive formats
supported by mkimage, and there are multiple compression methods
available as well.
So the bullet got bitten yet again along with the "goal parser"
which should be more straightforward by now.
Thanks dkr@ and mithraen@ for the inspiration of this evening.
Partially reverts "Makefile: presume a distro by default" commit:
plain `make' should better help the user to decide the target
rather than rush to build them all upon her.
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 noted by imz@ in #26608, a LiveCD is the more preferred
boot target to a local drive usually (just as was discussed
and implemented for ALT Linux 4.0 IIRC).
It was actually trivial given that the script was already
maintained as a package by enp@ and msp@; its usage requires
one to manually partition the target disk and optionally
mkswap in advance.
When ve/ support was introduced, a simple "make icewm.iso"
had to turn into the more elaborate "make distro/icewm.iso".
This latter one involves several keystrokes more, which is
not even (environ)mentally friendly.
This was supposed to get fixed somewhere down the road with
a fallback but the elegance of IMAGE_* setup waterfall barred
me from tweaking IMAGE_TARGET at once (and the downstream fixup
would imply re-tweaking the consequent variables as well which
is blatantly anti-mkimage-profilic being a brute fork).
OTOH testing for a "directory" part of the goal is going to
either deadlock on IMAGE_CLASS or duplicate its assignment.
So now when I've had enough typing an extra "distro/",
I'm going to just bite the bullet and tweak IMAGE_TARGET
with a test duplicating IMAGE_CLASS assignment indeed
(testing for e.g. "/" results in a different test,
which would be worse yet).
Please suggest a more elegant solution if you invent one!
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.
It's now possible to:
- make distro/server-ovz.iso;
- make distro/server-ovz-netinst.iso;
- publish the former image's contents on ftp.linux.kiev.ua;
- boot the latter (~17M) image and enjoy the netinstall ;-)
The catch is that the stage2 (altinst file) location has to be
hardwired into syslinux config snippet for things to happen
automatically -- even if it can be specified manually in case
of failure.
The other catch is that currently a netinstall image is somewhat
tied to the particular image it installs since stage1 kernel and
stage2 modules must correspond strictly (the typical symptoms of
the glitch would be missing mouse driver and weird "permission
denied" errors during an attempt to partition the hard drives).
It might be desirable to provide multi-distro netinstall image...
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...
It appears that features.in/Makefile functioned a bit
differently by now than was described back then: after
loops and pushds got rearranged for robustness, it stopped
to pick up a cleanup feature tagged script.
That particular script is now better de-tagged and simply
placed as a script to be merged into install2 subprofile.
The tagged scripts still require a bit more comprehension
to understand the use cases (e.g., do we need per-subprofile
tagged script subdirs or just a toplevel one should be looked
at, with script names telling where to put them).
README used to mix up subprofiles and features; fixed.
We've got some parts of it in build-distro feature,
and some went to dev feature for no real reason.
But a bare installer might go without package base,
and LiveCDs other than live-builder might find local
repository useful given aufs2 root overlay.
Now the overall scheme is more straightforward:
- a distro:
+ asks that a package repo be included
+ cares to further add the packages to it
- a repo feature:
+ pulls in sub/main for it to happen
+ provides genbasedir script to create repo metadata
+ supplements live feature with repo configuration
This is a base for "media check" to become available:
using this feature will implant a checksum into the image
so that it can be verified during install.
Also added a test/demo distro/live-isomd5sum target.
For real distros an alterator module is probably due.
