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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The logic is pretty much the same as with live.mk,
even somewhat extended as this has actually been
the driver of this change: some images like icewm
or lxqt-based ones might show off other browsers
explicitly (in addition to zerg@'s request).
Firefox was the very reasonable default for initial livecd
implementation but now that at least initial browser chooser
infrastructure is in place it's time to un-hardwire its use.
It's _the_ default but switchable now so that images providing
a comprehensive browser can avoid feature duplication.
This package contains a custom dialog-based dc3dd frontend
aimed to help non-expert CLI users to deal with common tasks
involving full-drive imaging and contributed by Maxim Suhanov.
These are rather foreignsic:
liblnk-tools: Tools to access the Windows Shortcut File (LNK) format
libregf-tools: Utilities to inspect Windows REGF-type Registry files
libuna-tools: Utilities from libuna for Unicode/ASCII Byte Stream conversions
libvshadow-tools: Tools to access the Volume Shadow Snapshot (VSS) format
Suggested by Maxim Sunahov and ported from OBS packages.
plasma-applet-networkmanager has been superseded by a bunch
of kde4-plasma-nm* packages; only the main one has been included
in regular-kde4 flavour since the switch resulting in the lack of
VPN/mobile connectivity options.
My opinion still is that plasma-applet-networkmanager should be
returned as a metapackage for p7/branch timespan so that images
could be built no matter whether it's sisyphus or p7 at hand.
Oh well.
These plugins should be required by a metapackage providing
plasma-applet-networkmanager so that branch and sisyphus builds
use the same pkglist; let's add those explicitly while that's
not done yet.
There's a whole slew of improved dd(1) forks out there
and several more utilities around, some might stick to
this one and others to that one; let's try and make'em
all happy even if it's not really feasible...
There's a nuance: libaff used to contain the utilities
and is required by sleuthkit; 3.7.4-alt1 has aff-tools
split into a subpackage of its own so we'd better keep
the binaries by adding this one.
biew was strangely missing indeed; several more
http://www.forensicswiki.org/wiki/Category:Tools
added as these have been packaged for ALT already;
fatback is on the way and dc3dd should come soon.
Debugging department has seen a /minor facelift/ too.
Some tools depend on X11 though and have been put
into a separate pkglist for that matter.
This is a refactored result of Zabbix-related experiments;
we can do a rough zabbix server sketch that still requires
its own setup to go.
NB: both the pkglist and the target are describing several
distinct things actually: zabbix server, zabbix agent,
and the underlying SQL/HTTP/SMTP servers which might get
their own smaller targets some day.
acpid is not enough since power button handling configuration
has been split apart; and tracking this in zillion places is
utterly useless in face of a specially trained power feature.
Just use it.
It's missing in Sisyphus since php5 update to 5.5.x;
while an opcode cache would be a powerful boost for
many webapps this has to be sorted out in repos first.
Burn.app won't list a USB DVDRW drive with CD-RW inside
(NOT_FOUND), and its README states explicitly that wodim
is not supported yet.
Mixer.app would start with three knobs none of which would
actually change any mixer channel.
Some more editing has been due over pkg.in/lists/tagged/README
to make it more comprehensible and up-to-date; the problem with
groups isn't actually that bad as alterator-pkg's groups concept
is currently aligned with the requisite functionality provided by
pkg.in/lists/* directly; the tagged pkglists come into play when
we want to add "something like that" and don't really care about
the fine details of a secondary thing trusting that it's actually
comprised and working as advertized through its name tags.
Compare to reusing the pre-existing image configuration or features
versus reimplementing things in a rigid manner -- it's a flexibility
vs predictability question, and both scenarios are supported within
m-p explicitly.
