tla.eclass is orphan

I see no maintainer under it, if anybody wants to take it...

Thanks

About masking net-misc/mDNSResponder for removal

Hello

Looks like our net-misc/mDNSResponder packages are orphan and
unmaintained for a looong time, they also have some opened bugs (with
hangs, build problems...) and looks like avahi with mdns compat can
replace it.

OK with masking it for removal? If not, is anyone willing to maintain
it?

Packages up for grabs due dertobi123 retirement

Due dertobi123 retirement the following packages need a new maintainer:
app-admin/fsvs
app-admin/gtkdiskfree
app-backup/tsm
app-misc/discomatic
app-misc/worker
app-portage/etc-proposals
dev-db/oracle-instantclient-basic
dev-db/oracle-instantclient-jdbc
dev-db/oracle-instantclient-odbc
dev-db/oracle-instantclient-sqlplus
dev-db/tora
gnome-extra/wp_tray
net-analyzer/nagtrap
net-analyzer/nagvis
net-ftp/gproftpd
net-misc/htpdate
net-nds/adtool
x11-misc/grsync

Thanks for taking them

Understanding the LINGUAS variable and use-expand

I just want to sanity-check my brain here.

LINGUAS seems to be mainly a variable to control the behavior of
gettext's autoconf code, installed as /usr/share/aclocal/po.m4.

If LINGUAS is set to a list of language codes, the build system will
only build/install MO files for those languages. If LINGUAS is unset,
the build system will build/install MO files for all available
languages.

Portage will also use-expand LINGUAS, so an ebuild *can* make use of
it where USE flags are needed. For example, in SRC_URI, where the USE
flags may be used to control downloading of extra language packs.

Given this information, I come to a few conclusions:

1. There is technically no need to define IUSE="linguas_$x" if an
ebuild is not using the USE flags in other ebuild metadata (like
SRC_URI).

2. In cases where the USE flags are needed, they should be enabled by
default to emulate the "default-all" behavior of the autoconf macros.
For example: IUSE="+linguas_fr_FR +linguas_de_DE".

3. An ebuild could use LINGUAS to control installation of translation
information which does not come from gettext PO files. It does not
necessarily need to make use of the linguas_$x USE flags to do so.

Does all of that make sense?

rfc: only the loopback interface should provide net

All,

I've been pondering for a while why All of OpenRC's network interfaces
provide net.

My understanding of the "net" service is that it is there to signal that
a generic network connection is active.

What I would like to do in OpenRC is change the network scripts so that
only the loopback interface provides net.

The down side of this approach will be that if a daemon uses a specific
ip address in its configuration, or if it binds to a specific address,
the user will have to set up the appropriate configuration options in
/etc/conf.d. For example, if I setup sshd to use 192.168.10.1 and eth0 has
this address, I have to put the following line in /etc/conf.d/sshd:

rc_need="net.eth0"

One advantage I see of this approach is it will provide a fix for bugs like
http://bugs.gentoo.org/show_bug.cgi?id=228973 by requiring users to
configure services like this to start after the interface they use
is started.

Attached to this message you will find the patch I want to apply to
OpenRC to make this change.

Any thoughts, comments, or suggestions would be helpful.

William

news item: baselayout-1 deprecation

This news item is to announce the end of supporting migration from
baselayout-1 to baselayout-2 and OpenRC.

I want to commit this on 2012-02-10, so any suggestions/comments are
welcome.

Thanks,

William

Title: baselayout-1.x deprecation
Author: William Hubbs <williamh <at> gentoo.org>
Content-Type: text/plain
Posted: 2012-02-10
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <sys-apps/baselayout-2

On 28 Jun 2011, baselayout-2.x and OpenRC were first marked stable on
all supported architectures in Gentoo Linux.

This was the point at which we stopped working on issues in baselayout-1
and began encouraging users to upgrade to baselayout-2 and OpenRC.

Although we are not supporting baselayout-1, we are supporting migration
from baselayout-1 to OpenRC and baselayout-2.

According to Gentoo policy, the support for migration from baselayout-1

Automated Package Removal and Addition Tracker, for the week ending 2012-02-05 23h59 UTC

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2012-02-05 23h59 UTC.

Removals:
app-accessibility/gnome-mousetrap   	2012-01-30 11:08:07	pacho
media-libs/phonon-xine              	2012-01-31 15:08:12	johu
gnome-extra/zeitgeist-sharp         	2012-02-01 10:41:54	jlec
app-text/lyx2html                   	2012-02-04 01:24:27	hwoarang

Additions:
x11-libs/qt-openvg                  	2012-01-30 10:25:11	wired
dev-python/d2to1                    	2012-01-30 22:41:50	xarthisius
gnome-extra/gnome-activity-journal  	2012-01-31 17:26:06	jlec
dev-perl/AnyEvent-HTTP              	2012-01-31 19:16:13	ssuominen
gnome-extra/zeitgeist-sharp         	2012-01-31 21:28:41	jlec
x11-misc/spacefm                    	2012-01-31 22:33:46	xmw
sys-devel/boost-m4                  	2012-02-01 02:21:01	binki
dev-dotnet/zeitgeist-sharp          	2012-02-01 10:39:27	jlec
gnome-extra/zeitgeist-datasources   	2012-02-01 10:43:35	jlec
sci-libs/idlmarkwardt               	2012-02-01 18:22:47	bicatali
dev-perl/MogileFS-Client-Async      	2012-02-01 19:17:47	robbat2
dev-perl/CGI-Emulate-PSGI           	2012-02-02 15:32:50	tove
dev-perl/Class-Accessor-Lite        	2012-02-02 16:02:16	tove
dev-perl/Proc-Wait3                 	2012-02-02 16:13:26	tove
dev-perl/Parallel-Prefork           	2012-02-02 16:15:19	tove
dev-perl/Test-SharedFork            	2012-02-02 16:57:02	tove
dev-perl/Filesys-Notify-Simple      	2012-02-02 17:12:06	tove
dev-perl/Devel-StackTrace-AsHTML    	2012-02-02 17:17:05	tove
net-misc/leechcraft-netstoremanager 	2012-02-02 17:20:07	maksbotan
dev-perl/Hash-MultiValue            	2012-02-02 17:23:43	tove

Last rites: sys-kernel/kerneloops

# Markos Chandras <hwoarang <at> gentoo.org> (04 Feb 2012)
# Dead upstream
# Bug #276412. Removal in 30 days
sys-kernel/kerneloops

--

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Lat rites: app-portage/autounmask

# Markos Chandras <hwoarang <at> gentoo.org> (04 Feb 2012)
# No maintainer. Functionality is now embedded in portage
# Bug #398935. Removal in 30 days
app-portage/autounmask

--

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Maintainer needed: app-office/libreoffice, app-office/libreoffice-bin, app-office/libreoffice-l10n

Dear all,

Right now, noone is taking care of named packages and/or their bugs, after the 
most active dev left the herd. I've asked on the herd alias some days ago if 
anyone is willing to step in, however there was no positive reply (and barely 
a reply at all). For this reason I've assigned 

app-office/libreoffice
app-office/libreoffice-bin
app-office/libreoffice-l10n

to maintainer-needed, and would like to ask anyone interested and willing to 
help to step in and revive the openoffice team.

Cheers, 
Andreas

[PS. If anyone wonders why I'm taking care of this, the "openoffice" team was 
about to become the "office" team some time ago, and I'm taking care of 
koffice / calligra and occasionally other kde-related office apps as 
kmymoney...]

[PPS. However fitting, this only coincides with Chithanh's mail by 
accident...]

--

-- 
Andreas K. Huettel
Gentoo Linux developer 
kde, sci, tex, arm, printing

Packages masked for lack of maintainer, but metadata.xml says otherwise

Dear all,

there have been a number of packages masked lately due to lack of
maintainer. However, their metadata.xml does not list
maintainer-needed <at> g.o which I think should be the first step in
searching for a new maintainer. (The last being mask and treecleaning.)

The problem with this is that it keeps them off the radar[1] and also
formally prevents them from getting treatment from proxy-maintainers
or sunrise projects.

Is there anything that speaks against making metadata.xml tell the
truth? At least the following packages are affected:

# Markos Chandras <hwoarang <at> gentoo.org> (02 Feb 2012)
# Multiple security bugs: 284356, 341085, 369137, 384243, 401993
# No maintainer. Removal in 30 days
www-apps/twiki

# Andreas K. Hüttel <dilfridge <at> gentoo.org> (27 Jan 2012)
# Has developed into an unmaintainable mess, and everyone who
# knows about it is either retired or missing in action.
# Several minor bugs and one ugly security issues (#386271).
# Masked for removal because of lack of maintainer.
# Please try app-text/epdfview as light-weight replacement.
app-text/xpdf

# Samuli Suominen <ssuominen <at> gentoo.org> (26 Jan 2012)
# No support for stable TIFF 4.x wrt #400925 with multiple