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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
LUKS seems like a worthwile addition to this particular image;
it's also switched to use installer-distro-altlinux-server
for both LUKS support (until installer-steps are dynamic)
and server-oriented partitioning presets.
Make it automatically start in desktop ones,
and let it be available in rescue too (there's
a risk of gpm picking up a wrong protocol and
selecting/pasting at random which is not exactly
the right thing for rescue environment with root
shells all around).
It was a desperate kludge to warrant fallback localization
for cases when livecd-setlocale failed to work out properly;
"thanks" to systemd paralizing startup the order was chaotic,
see #28991 for some details.
Now that livecd-setlocale >= 0.3.1 looks like working this
should be dropped for good.
And the proper preset solution will be l10n feature.
That one requires part of alterator-sysconfig backend
factored out into a standalone package along with its data.
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).
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
