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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Setting up apt configuration in every container
is pretty annoying, let's enable it by default.
Some provision to add/enable local mirror would
be beneficial but not there yet...
etckeeper was suggested by george@ along with vim-console;
the latter should come by server,base tags but so far does not
(splitting server-base list into common, bare metal and virtualized
parts in haste looked suboptimal).
That is, no need to pull in systemd as syslogd-daemon provider
when an unspecified one has been requested by interactivesystem
or anything else.
The tricky issue is that THE_LISTS will get expanded separately
and too late to specify a particular provider which will have been
auto-chosen while expanding e.g. BASE_PACKAGES.
So the autobuilds were failing for these two weeks since
commit e43386c1fe was *totally*
braindead: there's no "arm-e17" target neither "arm-kde4" one.
Fixed while awake and adjusted (in sync with build node)
to reference particular nexus7 and not just "arm".
The sad thing is that it should now read "nexus7old" TBH,
2013 model is not Linux friendly at all at the moment...
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.
gvfs pulls gnome-online-accounts and dconf in;
these add considerable bloat that well may be
undesirable in a lightweight distro, just pull
this into a separate pkglist.
It was a temporary hack actually, and is better dropped long-term:
things like predefined root accounts with remote access are *evil*
and this hook was a half of that "solution".
Use of oem feature to integrate first-boot setup is recommended
to deal with this issue, at least when graphics are available.
This one was asked for and is pretty reasonable common base
to play with cubox from scratch (being ALT); the intermediate
targets had to be refactored with:
- vm/.cubox-bare becoming *that* bare (it doesn't even
warrant an init anymore, let alone xorg);
- vm/.cubox-desktop accomodating most of desktop bits;
- vm/.cubox-base becoming vm/.cubox-oem as it should be.
The just-introduced tty feature is employed either.
The initial suggestion that any cubox image is a desktop one
didn't hold out for long; and xorg related bits are not that
related to boot script setup in terms of neccessity.
It basically reads the same but was referring to a neighbour
script that has been moved to a separate deflogin feature
during heavy refactoring of initial implementation draft.
This one was replaced by the net feature completely
and has been declared obsolete since 1.1.1 (a month ago).
A few remaining users trivially adjusted.
There was no need to split carrying over the pubkey
and tightening up permissions on the file and its parent
directory to be done in two separate scripts; this should
be more generic now as a bonus.
Users adjusted accordingly.
Minor fix: /boot directory is not cleaned for livecd if there are
homeros-install or luwrain-install files (in addition to live-install
and livecd-install being already checked).
The automated build relies on particular names
to be buildable and this broke during some sync;
http://nightly.altlinux.org/sisyphus-arm/snapshots/
were empty as autobuild was failing since 20130710.
p7 aliases go in too.
This inobvious buglet has been spotted shortly after
1.1.0 refactoring was roughly over; the problem is
that armh-specific targets would get ignored without
explicit ARCH=armh.
It's commit 768df7e9e9
which streamlined introspection within main.mk
and a bug in Makefile which left ARCH empty
even upon having autodetected it for ARCHES.
The current version is more straightforward as a bonus.
Thanks glebfm@ for nudging me to do this; initial draft
was the very firsh armh distro target successfully built
and tested but the effort has refocused onto nexus7 ones
with cubox images joining the party a bit later.
Now it's the time for all good servers...
It was sitting next to the wrong line after refactoring
of cubox related target and was referring to "king"
instead of "kind", very kind of me but not so kingly.
george@ spotted gqview in regular-lxde.iso and wondered why;
it's not being developed since 2006 or so while there's a fork
named geeqie which has continued to improve upon it.
Intro: NetworkManager-wait-online.service would, well, wait
for some network interface to become online or for timeout
to kick in.
Problem: if a LiveCD is tested in offline environment
that timeout will only impede the boot.
Proposed solution: use/net/nm/nodelay target has been implemented
to disable that service as proposed by sem@ and done in Simply;
"+nm" target changed to be an alias to this one.
It's old, it uses consolekit (even if not neccessarily),
it borders obsolescence *but* removal of udev-alsa has caused
massive regressions (e.g. regular-gnome3 had soundcard mixer
levels dropped to zero from the start, regular-razorqt added
inability to poweroff to that...).
Just get it back.
Thanks boyarsh@ and cas@ for pointing out that the branding
that takes MATE peculiarities (e.g. background settings)
into account is in Sisyphus/armh already.
This one is IMHO best suited DE for cubox' meagre performance
(especially on I/O side due to microSD) as it incurs quite modest
I/O, CPU and RAM footprint quite suitable for PII-300 times
(cubox feels quite like that but has lots of RAM compared to
even maxed-out Pentium II workstation).
The image includes OpenSCADA as a nice and unique feature
which has been developed with TDE environment in mind
and was used on ARM hardware like N900, incidentally;
thanks aen@ for this suggestion.
Most of these are slated to employ oem feature by now,
no sense to call it in almost every dependency chain;
the only image left with predefined locale and credentials
is cubox-xfce-ru.
The nuance being that:
- alterator-setup package would change default.target
for systemd providing a symlink of its own and making
a backup of what was there (rc3 basically);
- 40-x11-autostart would ignore that backup;
- 99-oem-setup would do nothing about it all either;
- alterator-setup removal would restore rc3 symlink.
It's not pretty either, something more robust should be
invented some day.
rootfs presented a special case when there is no resulting
directory at all as it gets merged with the target subprofile
by design.
Still those features adding only rootfs scripts need to depend
on it but this resulted in an attempt to process a missing subdir.
This is brought back to sanity now.
Few things:
- extend feature specification
+ SysVinit can be chosen explicitly via init feature,
no need to keep sysklogd in yet another pkglist;
+ power management should be included too
(both cpufreq setup and power button handling);
+ LILO seems to be heavily preferred among the
target audience :)
- use desktop installer for regular-server
+ the seeming controversy is explained easily:
installer-distro-altlinux-generic has very few
modules to the point of being inconvenient for
anything but quick rounds of basic testing,
and distributions rather do need network setup
along with a non-privileged user.
The funny thing while debugging this was "how the heck
could a sound related change induce privilege related shift?"
-- turns out that udev-alsa (which pulls in ConsoleKit)
was the culprit... looks like LXDE hasn't dumped it yet :)
As 50-sudo-su script cares for sudo and su control facilities no more
that hook is aptly renamed to 50-sshd-root (should be generalized
either some day).
Setting NM_CONTROLLED is apparently not enough to disable
/etc/net handling of a particular interface; thanks sem@
for noticing the fortunate error messages in logs
and explaining this peculiarity to me.
This bunch of commits was done so these can be
mixed and matched (or even reverted) later if needed;
it was tempting to just revamp things wholesale again
but coarse grained approach is worse to maintain.
The client side might benefit a bit more in the future
but the server side does not (and should not) require
everything client side does; thus use base ALSA target.
This replaces the many sets of the corresponding packages
wandering all over pkglists, features and configurations;
the interface should be rather well-defined by now.
use/live/install stopped to provide a desktop icon; the nuance is
that zdg-user-dirs-install.sh script in livecd-install package
expects ~/.config/user-dirs.dirs to actually do that.
This script hook used to lurk in live feature but was deemed needed
in cubox images too; thus it's time to move it into a standalone
feature (maybe a configurable one, even).
Thanks glebfm@ for initial shot and sem@ for discussion.
regular-xfce managed to lack NM somehow (so it even lacked
network after being installed since some build which wasn't
identified right away unfortunately); let's fix that either
during this small refactoring.
...net uses services, not services use net. That is,
"network" is a service that needs to be enabled by the
now-existing mechanism of "services" feature, don't be
fooled by "network services" here.
Some of those were long asking to be done but cubox project
managed to actually get them done at least to the extent
needed for it; so let's land those and prune things up a bit.
Based on m-p-d's domain-client pkglist and scripts from
installer-feature-network-shares-client-stage3 package.
Many thanks to boyarsh@ for his kind help to get this working.
NB: this works on cubox but is not yet ready for installers!
This is applicable at least to XFCE and MATE based images
(plugins for the appropriate file managers are available).
NB: basically untested with installers.
...as per aen@'s advice: parole can use gst0.10 specific
hardware acceleration on Cubox but Firefox doesn't, so it's
way more reasonable to download video and watch it and not some
kind of slideshow.
XFCE seems fine on that device while E17 has segfaulted on me so far
(specifically on Cubox and not on e.g. Nexus 7).
In a nutshell, cubox-xfce is an experiment into OEM-like flashware
while cubox-xfce-ru strives to become something more or less ready
for actual use.
This is an experimental and known incomplete support
for the system configuration that has to be done at the
first boot-up by its user since it's their choice.
This draft uses systemd which has been a requirement :-/
Thanks sem@ for helping out with the somewhat tricky
unit file for alterator-setup.
The '[alt]' signature reference in the stock package
doesn't fit current reality as the hash files for
Sisyphus/armh are *not* cryptographically signed.
This commit should be reverted when these are.
That \t has lurked in the source variant of the script,
was fixed in features.in/live/live/image-scripts.d/30-users once
and still has managed to creep into this fork!
Ugh.
The issue with the original hasty code that stuck around
was that it bluntly ignored any ifdef/ifeq constructs due to
an obvious reason of being essentially a grep, not a makefile
interpreter.
It's now fixed so that e.g. arch-specific targets won't pop up
for no good reason.
Thanks ldv@ for discussion and a reminder about the dump mode
(make -p).
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.
- 1.1.x branch: public alpha development status
+ new subprofile: rootfs
+ new features: armh*, deflogin, init, services
+ refactored features: build-*, efi, fonts, live, x11*
+ tar2vm got rewritten as tar2fs, gained ARM support
- minor spec metadata update
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.
Those based on x86 ones but pruned according to armh repo
presence; most notably, these are missing:
compiz compiz-gtk
java-1.6.0-sun mozilla-plugin-java-1.6.0-sun
libreoffice
remmina
xfcalendar
yagf
It was actually done much earlier during an experiment with
Marvell ArmadaXP but is now integrated more or less properly.
NB: ext2 is not needed anymore (uboot should do it),
ext4 should become configurable by an existing knob.
It was implemented in a pretty quick-and-dirty way
for regular-mate back then, clean things up a bit.
Package lists should be deduplicated either but
that's another story.
gdm-theme-simply is still around but turns out that it counts
on gdm2.20 (providing gdm) to be installed, and it is not;
thus gdm-3 is actually pulled in and it doesn't work here.
The package should be dropped from Sisyphus probably,
let's drop it here anyways.
Overview of the changes:
- ARM support: separate ext2 /boot, no LILO
- avoid race condition with devmapper
- trap ERR so that -e in shebang doesn't result in extra cleanup hassle
- configurable root filesystem type (ext4 by default)
- jumps through parted hoops
Details:
1. LILO is x86-specific while the rest of the script can be used
to prepare e.g. Marvell ArmadaXP or CuBox images; we can generally
count on uboot supporting ext2 for relatively sane platforms but
not ext4 that would be a better root filesystem performance-wise.
2. Apparently /dev/mapper/loopXpY can be still missing at the time
when kpartx returns and pop up a bit later... sit there, wait
and check for it.
3. If something went wrong with any command of the script it would bail out
due to -e in shebang; it is now better to clean up the loopback device
and its mappings in this situation either.
4. One size doesn't fit all, really.
5. The parted sizing was sloppy as in broken, now it's just half insane.
Someone's decision to stick units and auto-alignment knobs into
a single one was apparently hilarious...
http://www.gnu.org/software/parted/manual/parted.html#unit
Manual loop/dm cleanup is described in documentation just in case.
/boot size meter is suboptimal in terms of additional I/O incurred,
will be most likely rewritten to make use of advance "du -s".
The issue at hand is the hack to be employed in the init feature:
@$(call add,THE_LISTS,$$(INIT_TYPE))
where INIT_TYPE is set separately; $(value $V) would leave that kind
of substitution unmolested while we would actually need it done.
Hardly belonged there in the first place and became a culprit
during armh branch development since it had to be forked in
an ugly manner; move to rootfs hooks and be done with it.
VM images will be able to benefit either *but* installed systems
might have some trouble when this is implemented:
http://lists.altlinux.org/pipermail/devel/2013-May/197447.html
Split off use/live/x11 as a common free/proprietary ground either
(this refactoring had to be performed in parallel with x11 feature
being revamped, diffs quickly became intertangled unfortunately).
This has had several goals:
- a target suitable for x86 and armh providing a rather
minimal set of base xorg packages and generic drivers;
- task-oriented targets for graphics use cases:
+ "desktop" means rather 2D focus with 3D being welcome
or even essential but not performance critical, thus
"a slower driver is fine as long as it does work";
+ "3d" means specific 3D performance being critical,
that is "no 3D means no use at all".
Regarding the free and proprietary 3D-capable drivers:
the previous idea was to split out some common ground
and then add the contenders on top of that; the current
approach is based on the observation that the live images
requiring proprietary NVIDIA/AMD drivers *by default*
are usually of not much use with hardware that lacks
proper 3D acceleration (like Tseng cards) or the driver
support for that (like Matrox these days).
Intel videodriver makes for a special case though:
it is both free and top-notch performer.
Thanks sem@ and boyarsh@ for discussion.
PS: xorg-drv-{keyboard,mouse,void} dropped;
those who need these can usually help themselves.
These handle only VE-like products (think TWRP on Nexus 7);
the proper image support should be backported later on.
An experiment in layered configurations is still in its
early stages regarding ARM zoo...
The feature officially introduces the "engineering passwords"
including empty ones which have been around since forever but
weren't properly managed (and still are not, at least until
there are no stray passwd/chpasswd/usermod calls in both the
profile, installer-features and all the other related parts).
It is based on an m-p-d init3-users script by stanv@ but was
cleaned up and restructured in a pretty severe manner; thanks
glebfm@ for additional discussion.
This also cleans up the kludge previously stuck into build-vm.
Note that vm/icewm sports graphical autologin now as well as
the default root password (which can be overridden by passing
ROOTPW=... to make but it is a change from the previous state
of affairs indeed).
The issue is that use/fonts/infinality doesn't actually
require the script hook thus registering the feature's
name in FEATURES variable so that the feature's contents
get copied over is not neccessary (distcfg.mk build-up
will have happened anyways).
But that's confusing if one's forgot this peculiarity
(like me today) or never knew of it, so let's spare
some frustration.
This feature is more generally applicable indeed;
might result in duplication due to the installer
components adding "efivars" independently but that
is to be sorted out later in those components:
- check whether it's added already sometime soon;
- maybe stop adding that at some point in the future.
install2 and rescue roots still need this too though.
Classic VEs don't carry any kernel since these are running
under a single OpenVZ (or potentially LXC) kernel image;
ARM Multiboot (TWRP in this particular case) allows to boot
off a chroot via kexec, and we need a kernel in it for that,
obviously.
No bootloader required inside such VE though.
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.
...and switch to cinnamon-regular metapackage in general:
the remaining blocker being gdm required by that and not
actually going to work (it used to start gnome-shell which
wouldn't work in that configuration either) is now fixed,
thanks cow@.
PS: plymouth is moved upstream, drop the dup.
INSTALL2_PACKAGES turned out to be sensitive to the
feature addition order: if efi was added before install2
then the packages added by the former were overridden
by the latter.
This is also related to commit g7b76c73 as +installer
can be added pretty much anywhere, there's no warranty
that use/install2 appears early enough in configuration
build-up sequence.
There were several packages which don't really belong to base
list but rather to the desktop one; given that both of these
are included in desktop images it's a no-op for them but the
server ones might be better off without graphics.
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.
The installed livecd would lack fstab entries for the filesystems
other than those mounted explicitly during partition step; while
this might be considered either bug or feature, let's try that
and see.
Whoops: XFS, JFS, NTFS, FAT support has been lost while dancing
with reusing rescue lists and back to being lean.
Thanks Vladimir Gusev for spotting [a part of] this.
Another service that's not very useful on a LiveCD;
maybe should be enabled by default upon installation,
this also requires a proper framework in place.
This reverts commit ae44169139
as libglx has been fixed already; see #27340 and #28782 for
the details, huge thanks go to Alexey Borisenkov for his
thorough investigation and patches as well as to shrek@
and sin@ for their cooperation to get this fixed in Sisyphus.
The regular images became a bit too fat and rescueish
with all the good stuff going into rescue+extra pkglist;
that stuff does belong to dedicated rescue images but not
to each and every one.
The base+rescue pkglist has been tailored to take this
into account so we can now make regular-*.iso more fit too.
Moved the packages which impeded pkglist reuse for live distros
so that these stay within dedicated rescue images but don't
neccessarily go into the more generic ones where things like
fdisk are still quite useful.
This is to cope with #28782 while the culprit is being found out;
not much of a loss while #27340 is open (thus no 3D with vboxdrv
anyways).
I chose to avoid pulling the service related machinery into
vmguest (and haven't got around to factoring it out from live
feature's scripts into a standalone form) so had to tweak these
as well.
The issue at hand is the ability to accomodate boot sector
payload at the start of the filesystem's underlying block device.
XFS doesn't spare that space.
Thanks vsu@ for the reminder, by the way.
It might benefit the existing users to be able to configure the
build node persistently across reboots; though the need for something
like NFS overlay or repo settings piggybacked over DHCP is still there
(just ask ildar@).
The expected behaviour is to have online repositories enabled
when the livecd is running; the trouble with runtime detection
relates to the asynchronous nature of network configuration,
connection might get probed just before it is brought up
(thus failing the test).
Systems having been installed-from-live don't misbehave this way
so left unmolested.
Runtime detection is still available via use/live/repo/online
but is definitely not the default mechanism.
Thanks to Baurzhan Muftakhidinov's efforts along with help
from cas@ and zerg@, regular images should now support Kazakh
fairly well at least in terms of translation; this commit amends
these images with Ukrainian too and adds an experimental razorqt
based distribution that boots in kk_KZ by default.
There's no NetworkManager or connman in this lightweight image
so let's put at least the lightweight connection specific GUIs
like this one; proposed on the forum by Speccyfighter and
acked by squire as useful for traffic-metered plans:
http://forum.altlinux.org/index.php/topic,28619.msg201159.html#msg201159
Suggested by YYY; the initial plan was to include CUPS
in all the regular images but that turned out to be
impractical (too much bits added with too few actual
usage per bit expected).
So let's take s-c-p along with cups.
A syslogd is required by interactivesystem and we definitely
don't want any extra systemd on a sysvinit image.
Thanks Speccyfighter on the forum for the observation.
The former helps totem a lot regarding actual video reproduction,
suggested for gnome3-default metapackage; the latter helps aris@
to actually get any sound out, so is supposed to land there too.
A duplicate has formed while factoring out bare target;
as currently only the rescue image uses it in a special way
and that one benefits from additional crypto packages as well,
let's put LUKS related packages into bare for the time being.
The persistent storage is a nice addition to LiveCD images;
it doesn't come for free though in terms of performance
(especially for the first boot), so it should stay optional.
Note that use/live/rw belongs to base and not bare since
otherwise rescue becomes rescue+live which is superfluous;
hence the special use/rescue/rw.
There's a need for a separate boot target since
persistent storage is way slower than tmpfs indeed;
usbflash has a tendency for huge performance drops
given simultaneous writes in addition to reads which
are the bottleneck already.
make-initrd-propagator 0.18 introduced ext4 rw slice,
so the corresponding kernel module needs to be included
into stage1; see also #28289.
NB: not available on x86_64-efi (or hybrid GPT to be strict)
due to fragility of the hack being made: parted(8) panics
upon seeing that, and good ol' fdisk is unable to treat it.
NB: use/live/rw use/rescue/rx use/syslinux/ui/gfxboot
are unlikely to play very nice together due to the latter's
magic l10n: "session" label is taken by live_rw config snippet
and *is* translated in design-bootloader-source;
OTOH "rescue_session" is *not*.
The original mkisofs would only care for the proper ISO9660 image
but we've switched to xorriso which is able to perform the hack
to yield UEFI hybrid images; thus no need for the postprocessing.
Requires mkimage >= 0.2.5 and xorriso (obviously).
Added sysklogd and udev-rule-generator-net there too; if someone
needs to inherit a systemd based image from distro/.desktop-network
don't break the existing behaviour please.
Rebased tde flavours to .desktop-network as these were the actual
target to fix.
There's some peculiarity causing Sisyphus' initrd
(namely led-ws and make-initrd{,-propagator} of today
to die with this message while booting the resulting ISO:
initrd: Running /scripts/pre/prepare/000-propagator
FATAL ERROR IN INIT: mkdir
I can't recover from this,please reboot manually and send bugreport.
It's required by make-initrd-propagator in "rw slice" mode
when the remainder of an USB Flash drive is prepared and used
for persistent storage; fdisk is also immensely useful in general.
Please see the bug for explanations; too bad I chose to limit this
workaround to experimental gnustep image yesterday when aen@ suggested
to apply it universally...
Whoops, and I was mildly wondering where are alterator modules...
thanks Speccyfighter again for bringing attention to the issue
which has turned out to be ultimately caused by an overlooked bit
being missing.
The real issue was that regular-tde.iso was discovered to
lack FAT support in alterator-vm (known as #28470); as the
filesystem specific packages are pulled in via rescue lists
let's add it here along with dosfstools.
Thanks Speccyfighter at forum.altlinux.org for spotting this.
As zerg@ noted there's synaptic-kde already; I managed to overlook
that synaptic-usermode still gets into kde4 image as it's put into
base+regular pkglist. Thanks aen@ for spotting.
Quite a few filesystem specific tools and utilities went into extra,
some of them pulled back from fs since the proper categorization will
clearly require even more effort.
Added utilities for: f2fs, nilfs, logfs, reiser4fs, clicfs, cloop,
ocfs2, exofs, zfs, cifs.
This one was just asking to be built for quite a long time;
http://sourceforge.net/apps/trac/smartmontools/wiki/LiveCDs
specifically accenting use of smartmontools 6.0 has finally
persuaded me to roll out yet another rescue livecd, that is
on the regular basis.
The reason is to contain the implementation details
within this feature while adding the ability to include
everything it can provide (e.g., for rescue images).
This includes an updated version of 50-fontconfig script
which actually works (the preliminary one attached to #28612
didn't); thanks zerg@ and cow@ for providing the incentive
to introduce it.
Based on m-p-d and installer-feature-kdesktop-fontconfig.
Forum feedback has shown that it's a bit surprising
given the lack of other multimedia applications in
baseline package set; aen@ suggested to leave it out
and hardware support testing requires much more than
that anyways.
The issue is that r8169 is rather broken nowadays while
r8168 tends to work on the same hardware; see also #28473.
Thanks zerg@ for having hinted that it's stage1 modules,
not the root squashfs.
The metapackage was fine, the "only one" additional package
was more or less okay, but there came a dozen more so it's
now reasonable to stash these into a separate pkglist.
...and refactored its use in cinnamon image too;
this isn't a permanent solution though,
slated to move into fonts feature.
Thanks gns@ for suggestion.
There isn't much sense to keep an entirely separate flavour
as deepsolver starts being actually useful and icewm is
a somewhat special flavour for those who know their ways
around Linux plumbing.
It's possible that use/efi/signed target has fired already
at the time when use/efi/shell is invoked; shouldn't clobber
the signed shell with unsigned one.
The various *8168 and friends among kernel modules
have finally been pushed into a designated target
so that RM doesn't have to care which particular
additional ethernet modules are available in this
particular branch and kernel.
Tweak distros as appropriate.
NB: *maybe* this is required by distro/.base either.
acpi_call is used far too often when dealing with the newer
portable x86 hardware, we're better off including it when
it's available.
regular.mk adjusted appropriately.
Richard and Theo would probably roll their eyes at this point
but the unfortunate reality is that wireless hardware is very
much dependent on firmware being explicitly provided; so here
it is.
rtl8192 kernel module added since it's present in t6/branch
at least.
This change mostly concerns with making icewm flavour
the lean one again.
The goal is to widen the dynamic range of regular image features:
icewm is not a desktop thus can bear withouth systemd-logind
even if a bunch of network-managing-media-mounting crap has been
rigged to depend on it, and ALT domain client should be included
in most builds for convenient testing in SMB environments but can
stay out of this minimal and "different" image.
It also receives the "un-def" kernel flavour (3.8.0 as of today)
which might benefit from the more available testing facility too.
Its branding is also simplified, plain syslinux menu is fine;
in similar vein, refind feature is flipped from icewm-only to
all-but-icewm set of images with its state being good enough
as of refind 0.6.7 and mkimage 0.2.7.
mate-default pulls in mate-minimal and both of them
require packages which are also specified in this
pkglist; thus the pkglist should be pruned to avoid
double work and splits like "mate-vfs is dropped
from 1.5 package set, mate-default is adjusted but
the pkglist references the now-missing package".
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).
It was removing autodetection setting completely
thus implicitly setting it to the default "all"
with make-initrd-0.8.1+; just set it to be empty.
Thanks legion@ and boyarsh@; see also #28578.
Added use/live/net-eth so that autoconfigured images
still work in predictable manner.
May those breaking trivial cases walk with zillion of
cdrom, modem, ethernet etc device nodes all around them!
The inobvious issue is that while lxde-settings
is required by lxde-common and provided by both
lxde-settings-{altlinux,upstream}, we can't just
add the needed one via PACKAGES since the LISTS'
deps are expanded already with -upstream taking
lexicographical precedence.
This might become more serious if/when there are
several useful packages, -upstream isn't AFAIK
(thanks gns@ for explanation).
Citing the initial comment: "lxterminal is reportedly
sub-par (gns@) but official (aen@)"; the functionality
PoV finally won.
Terminus fonts added to account for presets.
See also #28567.
Added fvwm flavour specially for perestoronin from da LOR.
As if it wasn't enough,
- added UEFI support to desktop/,live-desktop intermediate target;
- added live installation capability to desktop/.livecd-install;
- added "net-eth" subfeature to get good ol' eth0 insteal of enp0s3;
- dropped use/x11/autologin as live subprofile sets up
a supported DM for automatic login anyways.
It'd be better for this commit to appear before 0.9.7
(and clobber the original one) but at least the added
functionality has been tested; time to generalize it.
The issue has shown up in regular-*-20130207: /etc/resolv.conf
would suddenly be empty upon successful bootup in virtualbox
with a single DHCP configurable ethernet.
dmesg has some trouble signs:
aufs au_lkup_neg:267:kworker/0:2[998]:
I/O Error, resolv.conf should be negative on b0
sem@ tells something like that has been seen before in a different
configuration (multiple aufs overlays with /etc/ and /var sitting
in different ones resulting in broken hardlinks); rescue boot with
a test "echo > /etc/resolv.conf" yields an I/O error either.
The patch is loosely based upon livecd-net-eth and
m-p-d::profiles/live/image-scripts.d/init3-{network,resolve}.
See also #28484 for the (still ongoing) discussion.
enp0s3 is quite inferior to eth0 in terms of usability
even if it might be more convenient for the machine{,ry}.
Let's stick with what works here in ALT Linux (see #28484).
Once upon a time the first and only ethernet interface
on a Linux system used to be known under the name of eth0;
but years passed and the systemd shadow has drawn closer
even to the seemingly remote areas like interface names.
In short, it might get named e.g. enp0s3 (a more human
friendly name of course) and the exact name is to be
figured out in runtime as well.
Sigh.
The issue is that gfxboot's gettext support works on "label"
strings but doesn't work properly on "menu label" ones as of 4.04
(the "menu label" translations pop up in the "Loading ..." window
but menu items themselves are unaffected thus untranslated).
NB: debian wheezy's syslinux-4.05 package patchset contains
somewhat related 07-gfxboot-menu-label.patch; might be worth
attention given that debian folks participate in upstream.
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.
The same "regular-gtk" based set of images received common
desktop background provided; note that kde4 won't like it
(branding package didn't really anticipate kde4 and is to
be updated appropriately as well as extended for mate/fvwm).
This one is also used for lightdm/gtk.
"regular-gtk" based images moved from the (unsupported) gdm2.20
to the (supported) lightdm with gtk greeter; while a couple of
gdm2 forks have emerged it's still unclear whether mate or mint
one will be actually alive, even short/mid-term.
The issue is that it's suddenly broken in current Sisyphus,
looks like the peculiar set of assumptions in fedora-tweaked
systemd+plymouth+gdm3 relies on tty1 being the X session tty
and it's different here.
It appears that manually specified IMAGEDIR, e.g. by adding
IMAGEDIR = ~/out/$(shell date +%Y%m%d)
to ~/.mkimage/profiles.mk, might be problematic due to
missing globbing. Let's make sure the paths are globbed
and directories are created -- since make's wildcard()
returns an empty string when there's nothing there [yet].
It appeared that plymouthd.conf wasn't set up properly
thus "service plymouth stop" didn't result in anything
meaningful; thanks boyarsh@ for his help figuring this
out again.
Folks have been wondering already whether e.g. t6 breakage
qualifies as a bug; it does indeed unless the "broken" part
depends on the features not available with that branch yet,
e.g. EFI support.
Its support was dropped in mkimage some time ago
since xorriso semantics changed quite considerably
and the tweak that was done here is now performed
out-of-box thus no longer needed.
It's aimed at providing UEFI shell implementation which is very
useful for repairs and debug; if the "signed" mode is requested
then the signed variant is used either.
Please note that there are two distinct uses:
- a shell lying around on a filesystem to be copied by hand;
- a shell available in EFI part of boot media to be launched
by firmware's or standalone boot manager (e.g. refind).
Let's provide the official terminal emulator as the reference one,
and those preferring others are welcome to include these either.
(to some extent this commit is biased towards regular.mk though)
The reason is that the most interesting live images by now are
installable ones, and while configurable boot order is not there yet
the "classic" livecd images will require manual choice to boot.
Thanks sem@ for reminding of that FR (which is still open).
It would be great to have #28289 fixed either so that aris@
could approve the image as usable (I totally agree that it's
a major piece of real world functionality currently missing)
looks like there's sense to prepare a starter iso for tests.
Currently done for 40-autologin script only but might be
more widely useful: when describing an action to be done
while forming the LiveCD image, also prepare the one that
undoes the effect so that an installed LiveCD doesn't
(mis)behave as if it were young again.
NB: livecd-install provides 50-{gdm,kdm}-autologin-off.sh
hooks which can collide with ours, so let's override those
until things are sorted out properly at both sides.
PS: some half-year old nodm hacks are still in place for t6/branch
(and #27451 should be re-examined when dropping those).
- added destination homeros-nano.iso yields minimal
speaking image;
- added "homeros" feature contain scripts appropriate
for general Homeros functions but need further development.
The current refind support implementation doesn't boot
with either USB Flash or CD-ROM for me (due to the different
actual volumes, FAT vs El Torito, accordingly).
And when it does, a host with Secure Boot present and not
disabled yet would turn the unsigned kernel down unlike ELILO
(due to rEFInd using "natural" calls to boot it).
Both issues are reported upstream; in the meanwhile let's
migrate a single test image but build the rest with elilo.
It's not e17-default alone right now, gnome-icon-theme package
appears requisite at the moment so that menus and IBar aren't
half-empty regarding graphics.
Thanks aris@ for the advice and lots of patience with me.
UEFI support is pretty requisite by now;
and el-smp hasn't seen updates for almost
half a year by now so an actively maintained
one is clearly preferred.
See http://www.altlinux.org/Регулярные_сборки_образов
for the idea behind this set of images; in short, it's
*not* a bunch of polished end-user distros in a moment
but rather to facilitate Sisyphus package base testing
in as-is state during branch pre-release time.
It's a separate installation step to set the LUKS password;
see also #28200 for (terse) discussion and instructions on
getting this actually working for a distro.
These are out there in Sisyphus and should be used
instead of copious lines in a package list.
Thanks sem@ for proposing gnome-icon-theme to supplement
the lack of icons in the default theme; note that tango
set doesn't quite cut it, even with extras.
Thunar -> thunar; xfcalendar -> orage
There's use/x11/kde already but that serves somewhat different
purpose as of today; the naming issue (kde vs kde4) was tersely
discussed with sin@ at the time of the merge of his KDE4 image
related bits and it's still not that clear.
Let's try this way and see if existing images would be ported
to use/x11/kde4.
The whole live-rescue needs a massive facelift regarding
applications included and user experience achieved (remember
that folks are going to be stressed enough already with data
lost or system(s) not booting, and probably offline as well);
but at least it's UEFI bootable now.
The (funny but somewhat confusing) problem manifests itself as
E: Couldn't find package Binary
during a build run in the profile where a tagged packagelist
referenced by a specific target being built is open with vim
(which results in .FILE.sw? temporary file lying aside).
There's a possibility to run into IA32 EFI but that's rather
uninteresting hardware (ancient Xeon servers and <s>outdated</s>
early Intel Mac laptops). Just drop it on the floor.
As x86_64 UEFI support would result in "2D hybrid(r)(tm)" image
which boots with all combinations of BIOS/UEFI by CD|DVD/Flash
(or at least should boot), some downgrace seems due: use/efi will
turn use/isohybrid on non-x86_64 -- which will require further
tweaks on PPC/ARM some day.
Intermediate one: build-propagator *is* run off stage1,
no mkimage changes for that matter so far. This means
that m-p still duplicates mki-pack-boot to some extent
but the way to dedup this is still not clear enough...
The initial approach required some quite involved postprocessing
as described in http://www.altlinux.org/UEFI#HOWTO; after having
ironed out the kinks so that initial EFI support could be merged
into mkimage proper we're better off just using it, eh?
As was proposed by Alexey Varakin in community@,
whdd was built for ALT Linux by drool@ and pauli@
with some help by torabora@ and mithraen@; looks like
it's a worthy addition to the rescue kit.
The problem manifests itself when the naive parser ignores
any conditions that might have been set in the makefiles
included with subsequent attempt to run a target which has
its actual rule defined within e.g. "ifdef DEBUG" clause
(as is the case for conf.d/test.mk); that will fail with
no proper diagnostics currently.
Maybe this would be of some use (but then again maybe not):
http://stackoverflow.com/questions/3063507/list-goals-targets-in-gnu-make
The previous part was fixed and discussed in commit
c30490e2e884f8655a2704fa6a84e60b13876874;
so much for a deduplication effort...
This would result in almost immediate
make[1]: *** [profile/populate] Error 2
as well.
That is, p6/t6 continue to use 3.81 (while providing 3.82
alongside with it), and Sisyphus has moved to 3.82 before
p7/t7. We support both versions by now.
While ildar@ has some reason for the slimmer image
the somewhat standalone one is documented in examples
for offline use, ruining it in-place is not an option.
Let's just do a split (and lose a target-specific variable
example in favour of a commodity pkglist by the way; oh well).
a live-builder appliance is (or may be) usually used for building software
with many dependencies, hence needing access to external resources,
e.g. apt repos with lib${NAME}-devel packages.
This commit cuts RPM packages from the live-builder LiveCD.
The issue (#28002) resulting in vm image build error reading
Syntax error at or above line 5 in file '/etc/lilo-loop.conf'
was caused by fdisk-2.22 changing its "-l" option output format
to drop the very mention of the long irrelevant crap named "CHS".
The problem is, however, that we still need that crap to piggyback
a loop device's fake geometry to lilo while installing it there.
Reported by icesik@.
Somewhat kludgy unfortunately and might need even more tweaking,
I have only armv7l board handy at the moment to verify that
the transformation is going to work.
QEMU is bailing out here and now ("Exec format error").
Example sources.list.sisyphus.armh of the season:
rpm http://ftp.altlinux.ru/pub/people/asdus/sisyphus armh classic
rpm http://ftp.altlinux.ru/pub/people/asdus/sisyphus noarch classic
propagator-20121109-alt1 obsoleted initfs (and dropped
mkinitfs script altogether); that was taken into account
in both make-initrd-propagator and mkimage-profiles-desktop
but not in mkimage proper, see also discussion in #27976.
Both do require postprocessing (see http://www.altlinux.org/UEFI)
until mkimage receives xorriso support and efiboot.img is passed
down there somehow, but it's beta than nothin' so far.
EFI/UEFI is mostly about partitioning and bootloader setup,
at least from a distribution's point of view; so the
appropriate tools should be handy and firmware interface
module should not be exterminated from installer images
but get autoloaded instead.
Please note that while there exists 32-bit x86 EFI
we don't bother with it at the time being: it's relevant
to some irrelevant Xeon systems as well as for the older
Intel Macs (<2008) that are long out of fashion anyways.
That is, initially we deal with x86_64 EFI only.
Introduced distro/.live-desktop-ru as a shortcut for
distro/.live-desktop use/live/ru which occurs several times
already (and the counter will increase right now).
This was requested by aris@ for live-gnome.iso but is so far
reasonable enough to do by default: the case of a LiveCD
including X and a display manager but willing to get on
with startx by default is rather nonexistant by now.
Thanks go to ildar@ for spotting this: my ~/.mkimage/profiles.mk
routinely contains DEBUG = 1 line which effectively masked this
regression in commit 307fb51f15.
Wouldn't be a big deal but syslinux.iso is recommended in
tutorial docs being slim and fast-building, and it's also
what's buildable locally in live-builder.iso environment.
ildar@ noted that the test involving whitespace is too
quirky for some quirky enough cases like
rpm-dir file:/var/cache/apt/archives . x86_64
-- let's introduce word boundaries there.
*Of course* the "weird" [ ... ] || ... construct meant to avoid
the non-zero exit status of the whole thing wasn't employed
where it actually does make the difference!
Thanks ildar@ for hitting and reporting this, as in
+ verbose '/usr/lib64/propagator exists'
+ '[' -n '' ']'
mki-scripts: .../stage1/scripts.d/80-make-initfs: unable to run script.
make[3]: *** [run-scripts] Error 1
The newer kernels have versioned NFS support code moved
into a few separate modules with nice self-explanatory
messages reading "Protocol not supported" if one has
managed to overlook this; thanks boyarsh@ for heads-up
(based on f545923271f9d1938d1887632ab4697c4c009039 m-p-d).
The initial sketch did work but was somewhat redundant
while lacking the knob conveniently change output directory
as well as means to get it cleaned up.
This is thanks to the fact that alterator-based install2 needs
alterator-browser-qt which needs X11 which needs working device drivers
-- and at least AMD C60 APU would only yield a nice dotted white screen
without that firmware.
Roughly the same for X11 bearing LiveCD images.
The rationale for the former is that the image gets slightly
more compact (although the current sisyphus build is way larger
than the t6/branch build of the optimization time, need to look
into that...); and for the latter it's to provide yet another
installer with a different enough kernel so that there's one more
chance in a weird situation.
Actually just a split of livecd-webkiosk into the kiosk related
part and generic livecd firefox setup (turning off queries that
are pretty useless in that environment).
This is a mild generalization of what has been done by hand
to figure out a problem with make-initrd-propagator-0.10-alt1:
stripping anything intrinsically volatile off the build.log.
The filter set isn't perfect, and the proper logging will
involve mkimage tweaks as well (e.g., one generally isn't
interested in instrumental chroots' population that much,
so it should only be verbose at the higher debug levels).
The issue that appeared pretty hard to diagnose occured
to be the enhancement made in make-initrd-propagator=0.8.1-alt1.2
(that didn't hit Sisyphus until merged into 0.10-alt1) which
drops propagator dependency.
And that was optimized out in m-p, of course.
The added pdir check was a hillarious(tm) overlooked bug indeed:
I tried to put .../initfs/initfs instead of .../initfs as the result.
Duly spotted by torabora@, thanks a lot.
Still the kmod+propagator+kernel-image combo needed some tweaking too,
see #27640
The issue actually hit image.in/Makefile: "metadata" target
in features.in/metadata/lib/50-metadata.mk wasn't reached
even if features.in/build-distro/lib/90-build-distro.mk
would ACK that the "whatever" actions included "metadata";
thus Metadata/pkg-groups.tar wasn't created and the installer
silently failed to install the .base system.
Let's armour the rest of the cases where the order of inclusion
might be important as well.
It's pretty ugly but dropping the current way
means losing the dependency tracking which is
critical to get the required alterator module
into install2.
Thanks mithraen@ for spotting, boyarsh@ for explaining,
and legion@ for hearty support :)
The problem would manifest itself like this:
/.host/script.sh: line 20: /usr/lib64/propagator/initfs: \
No such file or directory
mki-scripts: .../stage1/scripts.d/80-make-initfs: unable to run script.
Thanks Serg Markov for bringing my attention to this:
http://www.opennet.ru/openforum/vsluhforumID3/86552.html#61
While the official distros might skip some filesystems for
support reasons there's no reason for community distros to
do so either.
Let's try that with icewm.iso...
NB: installer has a misfeature of dropping jfs/reiserfs
support in runtime unless "expertmode" magic word
is on the kernel bootargs string (#27763, #17368).
Its immediate purpose was influencing the GRUB boot menu
*but* the implemented mechanism is actually a part of the
long planned text branding and might be further merged
into branding when hierarchical features finally chime in.
So let's get the naming straight before it breeds.
See http://www.opennet.ru/openforum/vsluhforumID3/86239.html#1
for a query that has led to this one; in particular,
- xdm dropped (won't log in root and there are no users yet);
- network is brought up and configured via DHCP by default;
- apt-get works out-of-box;
- default image size is twice the chroot size.
3.5.2-std-def-alt2 brings boot problems which were absent
with 3.4.x-std-def and are absent with 3.5.x-un-def;
seems like it's better to stay with known good variant
at the moment instead of having to fall back to it.
hsh-initroot leaves the chroot's root directory permissions
as 1775 while these should really be 755 at most; let's fix it
(important for both VE and VM images, useful for rescue/livecd
ones as well -- especially those with an installer onboard).
The missing "; @:" at the end of the otherwise recipeless rule
resulted in target graph being broken; I should have checked this
when introducing these aliases (the intent was to reduce noise).
Not even alpha quality yet but at least debuggable:
- X session doesn't autostart but service dm start works;
- keyboard layout indicator is missing until started by hand.
There's a bunch of additions to the MATE package list:
thanks viy@ for pulling extras into autoimports,
several more tweaks done due to hints by dek@,
and openssh packages added for debugging convenience.
The kernel's been changed for the latest one (un-def).
This isn't ready for general consumption (just as centos one)
but the notion of REPO is floating around along with apt-conf
thoughts, and it might still be useful to someone poking around
conf.d/test.mk.
Request hasher-pkg-init.spec from mike@ or led@ if interested;
the experiments were carried out using openSUSE 11.4 repository
and slightly patched hasher (cpio blacklist for devices).
This part of docs was pleading to put it into a small shell
script; it was done to facilitate kas@' debugging efforts
so that qemu-system-ppc might eventually get fixed, thus
livecd-qemu-arch package now "obsoletes" this file.
Thanks both drool@ for his mild frustration with the current
documentation as well as Greg Kroah-Hartman, Heikki Orsila
and Neil Brown for http://lwn.net/Articles/504814/ -- the docs
should really emphasize *why* something is done, not *how*,
as the "how" part is better documented with the code itself
(that doesn't mean that "the big picture" isn't needed).
That sub/stage2/install2 was somewhat clumsy actually as it looked
like a hierarchical thing while being a substitution thing:
generic stage2 would get put in place renamed as install2.
This could only get worse with hierarchical features which have
already been both requested and considered for quite a time,
and "stage2 at install2" reads much more naturally.
There were heaps of "if type -t git" there already;
it wasn't an unintentional mishap but rather a moderate
copy-paste to get the use cases, and now these seem to
have essentially settled.
So time to scrap some dups.
NB: the scripts in the generated profile can't rely on
the contents of the metaprofile (these need to be able
to work in standalone case either), so a bit of crap
still lurks there.
Found myself pretty silly while sittin' at the rescue console
and bein' unable to leave the cool server room for a way
more comfortable armchair and a laptop's keyboard...
(yes, it was that disk array needing GPT tools)
Another feature suggested by Michael Radyuk (torabora):
some images are known alpha/beta quality, it's more handy
to just state this at the build time than to rename by hand.
This trots along the TODO item on text branding
and hopefully helps Michael Radyuk (torabora)
with his feature request to tweak the installer's
"Install ALT Linux" label; as an example, Simply
will now offer to "Install Simply Linux".
The package actually passed the test and just got uploaded
to Sisyphus proper; its aim is to help set up the cross-arch
QEMU build environment.
NB: there are known issues with PPC32-on-x86_64 (which were
the cause for this package and commit to be created in the
first place).
Some images were unbuildable (at least without special setup,
like ve/centos), unusable or just not useful in any meaningful way
(like distro/live-isomd5sum); as these tend to get any attention
during experiments, I decided to put them together in a separate
configuration file that would be effectively skipped if DEBUG
is not requested.
This one was suggested by enp@ for industrial use where
some extra protection for the boot process might be quite
desirable.
If no syslinux ui was specified (the stock configuration paths
ensure there is one) or if it was set to "none" explicitly,
then there's no boot: prompt (let alone any menu).
If there's a need to ensure that the boot process is not
interruptable by Ctrl/Shift/Caps Lock/Scroll Lock.
The prerequisites for a cleanup after a successful build
were somewhat weird at this point; now the rules are:
- if DEBUG level is more than 1 or CHECK 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;
+ the build was run by e.g. alterator-mkimage;
+ metaprofile directory is read only
...then do a distclean.
If these are still weird or feel unsuitable for profile hacking,
drop me a note (or a patch).
Essentially all the relevant server images got cpufreq setup
and a power button handler; feel free to ask for revert if
this causes any harm in any situation.
`help' used to be the default target described at the very top
of the toplevel makefile but that got broken with g2f307ff;
spotted while discussing m-p with enp@.
Also pulled the pkglist/kmodule part out of distro/server-mini's
recipe and started off a standalone feature based on it.
NB: el-smp kernel now contains aufs as a module but propagator
doesn't try to modprobe it.
Actually the templates pretending to be usable missed the whole
interactivesystem (sysvinit would get pulled in by services as well).
Fixed somewhat but time and practice will tell.
TDE distros don't really need kdm4 which was proposed as
a replacement by zerg@ (for all the valid reasons but kdm3
wasn't maintained at that point, this has changed since).
The reason is that package lists and individual packages
are processed in different dependency resolution "transactions"
by mkimage; thus if packages (the more precise form of specifying
the contents) come first they can't override the lists appearing
later, and that's wrong: we should be able to specify the more
generic things and then pinpoint the specifics.
This became apparent while authoring [[Mkimage/Profiles/m-p/howto]]
asked for by drool@.
The problem was spotted by Alexander Bandura:
bin/tar2vm wasn't present in the generated profile.
I considered extending features.in/Makefile to include
bin/ alongside lib/ but that would make the helper's location
unpredictable (unless BUILDDIR is specified explicitly) so
restricting sudoers would be harder; worse yet, the copied file
would come with write access for the user building an image.
The implications in restricted case are complex enough anyways
so the recommended implementation would only include a fixed
readonly location like /usr/share/mkimage-profiles/bin/tar2vm
as laid out in doc/vm.txt, and that means it's in the metaprofile
not a generated profile.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
