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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
E19 would ask the user if they want to shut down
when facing power button event; it won't get a chance
though as the system will hurl down immediately as per
acpid-events-power package provided configuration.
This is a similar trouble: p7/t7 branches had
plasma-applet-networkmanager while sisyphus has
switched to kde4-plasma-nm* (there's a bunch of
subpackages there, basically all of them desired).
Looks like today's xorg won't autoload radeon_drv but
insists on ati_drv falling back to fbdev if it's not there;
FlightGear runs definitely slow on C-60 APU with that.
I didn't specify ati since it pulls r128 and mach64 modules in
which are rather useless in this context (accelerated 3D graphics).
The use/x11/nvidia/optimus target will pull the bits required
to operate NVIDIA Optimus GPU scheme which relies on integrated
GPU to actually drive the screen; much thanks to barssc@ for
good walkthrough: http://altlinux.org/optimus
NB: this *will* break if nouveau gets in, YHBW.
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.
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.
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.
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.
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).
It is actually an effort by glebfm@ to create an experimental
systemd-based Simply Linux LiveCD; I merely reviewed the original
diff, moved kernel related bits to firmware (see preceding commits)
and introduced a dedicated pkglist namespace by creating a directory.
Now is the time for all fonts to be pulled in when needed and not
along with the X server and hardware drivers; tablet support is
moved to a (preexisting) specific target either.
There's no need now to arch-discriminate a few older drivers too.
The previous configuration would result in intel-only
3D being available since nouveau and radeon kernel modules
are packaged separately with most kernel-images; getting
NVIDIA/AMD drivers in is more tricky due to availability
of both proprietary and free implementations with the choice
being rather a tradeoff in each case (somewhat less so with
ATI/AMD drivers).
So this is a first shot at the problem: FlightGear would
freeze on me with today's nouveau.
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).
It looks like the intermediate targets aren't all equal:
some define a finished feature while some create a common
lower level piece of configuration.
Let's do shortcuts for the former so that a distro line can be
more terse and descriptive; help targets in features.in/ tweaked
accordingly.
The package list taken from mkimage-profiles-desktop
and trimmed down due to current TDE packaging difference
as well as extras being defined elsewhere.
It's preferred for Razor-qt's logout app to be able to turn
the system off or reboot it; xdm lacks consolekit support.
Thanks Alexander Sokoloff for the hint.
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.
This one is pre-alpha quality and very basic but complete enough
to crank out an icewm.iso successfully installing and booting
into xdm ;-)
(actually a week's on-and-off work including a pile of
underlying infrastructure stuff which was planned already
just not there yet)
