Re: [gentoo-dev] man pages: build or copy?
On Sat, 9 Jul 2016 14:54:56 +0100
Neil Bothwick wrote:
> I've created an ebuild for net-misc/zerotier [1]. This has a BDEP on
> app-text/ronn, the build system uses it to create the man pages. The
> trouble is that ronn is a Ruby program and pulls in a shedload of
> dependencies, just to install man pages.
>
> It seems to me to make more sense to put pre-built man pages in
> ${FILESDIR}/${PV} and copy them with doman. Is this considered the
> correct or acceptable way to deal with this?
>
> 1) https://bugs.gentoo.org/show_bug.cgi?id=588324
If they are quite static (i.e. don't have important content that
depends on USE flags etc.), generate them, put in a tarball somewhere
(you can ask a proxy committer to host it for you), then fetch them via
SRC_URI.
--
Best regards,
Michał Górny
Re: [gentoo-dev] man pages: build or copy?
On Sat, Jul 9, 2016 at 5:24 PM, Neil Bothwick wrote:
> On Sat, 9 Jul 2016 10:13:13 -0400, Michael Orlitzky wrote:
>
> > On 07/09/2016 09:54 AM, Neil Bothwick wrote:
> > > I've created an ebuild for net-misc/zerotier [1]. This has a BDEP on
> > > app-text/ronn, the build system uses it to create the man pages. The
> > > trouble is that ronn is a Ruby program and pulls in a shedload of
> > > dependencies, just to install man pages.
> >
> > Ruby packages (besides dev-lang/ruby itself) install quickly, like perl
> > packages, so this isn't a *huge* deal. They can also be removed
> > afterwards with a depclean.
>
> That's when it really hurt, installing on a system without ruby itself.
> That's when I looked at alternatives.
>
> > > It seems to me to make more sense to put pre-built man pages in
> > > ${FILESDIR}/${PV} and copy them with doman. Is this considered the
> > > correct or acceptable way to deal with this?
> >
> > It's up to you. If they release a new version every day, it's going to
> > get real annoying to regenerate the man pages each time. Also keep an
> > eye on the size of the man pages. We have a soft limit of "a few
> > kilobytes" for things in FILESDIR,
>
> There's only three of them, totally 15kB uncompressed.
Having recently been annoyed by a package that for some reason depends on a
command-line web browser to build documentation, I'd really appreciate the
pre-built-without-oddball-dependencies variety :) (And ZeroTier looks like
something interesting I might find some use for)
Re: [gentoo-dev] man pages: build or copy?
On Sat, 9 Jul 2016 16:32:58 +0200, Dirkjan Ochtman wrote:
> > It seems to me to make more sense to put pre-built man pages in
> > ${FILESDIR}/${PV} and copy them with doman. Is this considered the
> > correct or acceptable way to deal with this?
>
> In dev-libs/nanomsg, I've hidden building the docs behind the "doc"
> USE flag. nanomsg builds it docs with AsciiDoc, which also pulls in
> ruby and a bunch of stuff.
use.desc says doc is for extra documentation. These are basic man pages
that are more or less needed to use the software.
--
Neil Bothwick
One-seventh of life is spent on Monday.
pgpWAJ7n7CIWR.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] man pages: build or copy?
On Sat, 9 Jul 2016 10:13:13 -0400, Michael Orlitzky wrote:
> On 07/09/2016 09:54 AM, Neil Bothwick wrote:
> > I've created an ebuild for net-misc/zerotier [1]. This has a BDEP on
> > app-text/ronn, the build system uses it to create the man pages. The
> > trouble is that ronn is a Ruby program and pulls in a shedload of
> > dependencies, just to install man pages.
>
> Ruby packages (besides dev-lang/ruby itself) install quickly, like perl
> packages, so this isn't a *huge* deal. They can also be removed
> afterwards with a depclean.
That's when it really hurt, installing on a system without ruby itself.
That's when I looked at alternatives.
> > It seems to me to make more sense to put pre-built man pages in
> > ${FILESDIR}/${PV} and copy them with doman. Is this considered the
> > correct or acceptable way to deal with this?
>
> It's up to you. If they release a new version every day, it's going to
> get real annoying to regenerate the man pages each time. Also keep an
> eye on the size of the man pages. We have a soft limit of "a few
> kilobytes" for things in FILESDIR,
There's only three of them, totally 15kB uncompressed.
--
Neil Bothwick
Nothing is illegal if one hundred businessmen decide to do it.
pgpVxnU9KpTUd.pgp
Description: OpenPGP digital signature
[gentoo-dev] [PATCH 4/4] profiles: Add an amd64 no-lib-symlink profile
Add an amd64 no-symlink profile that removes 'lib' symlink from the (current) default amd64 profile. Please note that this is not really a standard configuration (unlike the lib+lib64 model) but a profile intended to help developers find mispackaged software. It provides a clean split where lib64 contains 64-bit libraries, lib32 -- 32-bit libraries, and lib -- any other software packages (i.e. the new-style libexec use). --- profiles/arch/amd64/no-lib-symlink/make.defaults| 2 ++ profiles/arch/amd64/no-lib-symlink/parent | 1 + profiles/default/linux/amd64/13.0/no-lib-symlink/parent | 2 ++ profiles/profiles.desc | 1 + 4 files changed, 6 insertions(+) create mode 100644 profiles/arch/amd64/no-lib-symlink/make.defaults create mode 100644 profiles/arch/amd64/no-lib-symlink/parent create mode 100644 profiles/default/linux/amd64/13.0/no-lib-symlink/parent diff --git a/profiles/arch/amd64/no-lib-symlink/make.defaults b/profiles/arch/amd64/no-lib-symlink/make.defaults new file mode 100644 index 000..a715cf1 --- /dev/null +++ b/profiles/arch/amd64/no-lib-symlink/make.defaults @@ -0,0 +1,2 @@ +# do not want lib -> lib64 symlink, let lib be a directory on its own! +SYMLINK_LIB="no" diff --git a/profiles/arch/amd64/no-lib-symlink/parent b/profiles/arch/amd64/no-lib-symlink/parent new file mode 100644 index 000..f3229c5 --- /dev/null +++ b/profiles/arch/amd64/no-lib-symlink/parent @@ -0,0 +1 @@ +.. diff --git a/profiles/default/linux/amd64/13.0/no-lib-symlink/parent b/profiles/default/linux/amd64/13.0/no-lib-symlink/parent new file mode 100644 index 000..2a54eb8 --- /dev/null +++ b/profiles/default/linux/amd64/13.0/no-lib-symlink/parent @@ -0,0 +1,2 @@ +../../../../../arch/amd64/no-lib-symlink +.. diff --git a/profiles/profiles.desc b/profiles/profiles.desc index 2634742..9c4160f 100644 --- a/profiles/profiles.desc +++ b/profiles/profiles.desc @@ -26,6 +26,7 @@ amd64 default/linux/amd64/13.0/desktop/kde/systemd stable amd64 default/linux/amd64/13.0/desktop/plasmastable amd64 default/linux/amd64/13.0/desktop/plasma/systemdstable amd64 default/linux/amd64/13.0/developer stable +amd64 default/linux/amd64/13.0/no-lib-symlinkdev amd64 default/linux/amd64/13.0/no-multilib dev amd64 default/linux/amd64/13.0/systemd stable amd64 default/linux/amd64/13.0/x32 dev -- 2.9.0
[gentoo-dev] [PATCH 2/4] sys-apps/baselayout: Fix SYMLINK_LIB=no to create lib dir instead of sym
Fix the 'else' branch of SYMLINK_LIB=no code to create lib directory
rather than a symlink.
---
sys-apps/baselayout/baselayout-2.2-r1.ebuild | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/sys-apps/baselayout/baselayout-2.2-r1.ebuild
b/sys-apps/baselayout/baselayout-2.2-r1.ebuild
index 11326dc..a9e1a65 100644
--- a/sys-apps/baselayout/baselayout-2.2-r1.ebuild
+++ b/sys-apps/baselayout/baselayout-2.2-r1.ebuild
@@ -118,9 +118,7 @@ multilib_layout() {
else
# nothing exists, so just set it up sanely
ewarn "Initializing ${prefix}lib as a dir"
- mkdir -p "${prefix}" || die
- rm -f "${prefix}lib" || die
- ln -s ${def_libdir} "${prefix}lib" || die
+ mkdir -p "${prefix}lib" || die
fi
fi
done
--
2.9.0
[gentoo-dev] [PATCH 3/4] sys-apps/baselayout: Do not complain about lib+lib32 when it is valid
Remove the error on 'lib' directory with SYMLINK_LIB=no multilib layout
if lib32 is a valid directory as well. This fixes the wrong assert
in the new no-lib-symlink profile while preserving the check on regular
lib+lib64 profile.
---
sys-apps/baselayout/baselayout-2.2-r1.ebuild | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sys-apps/baselayout/baselayout-2.2-r1.ebuild
b/sys-apps/baselayout/baselayout-2.2-r1.ebuild
index a9e1a65..3c3aa95 100644
--- a/sys-apps/baselayout/baselayout-2.2-r1.ebuild
+++ b/sys-apps/baselayout/baselayout-2.2-r1.ebuild
@@ -99,7 +99,7 @@ multilib_layout() {
else
mkdir -p "${prefix}lib" || die
fi
- elif [ -d "${prefix}lib" ] ; then
+ elif [ -d "${prefix}lib" ] && ! has lib32 ${libdirs} ;
then
# make sure the old "lib" ABI location does not
exist; we
# only symlinked the lib dir on systems where
we moved it
# to "lib32" ...
--
2.9.0
[gentoo-dev] [PATCH 1/4] sys-libs/glibc: Do not reset multilib vars unless cross-compilnig, #588368
Do not call multilib_env_reset unless cross-compiling, in order to
prevent the function from redefining profile-defined variables such as
LIBDIR_*.
---
sys-libs/glibc/files/eblits/common.eblit | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sys-libs/glibc/files/eblits/common.eblit
b/sys-libs/glibc/files/eblits/common.eblit
index e56f10e..370782b 100644
--- a/sys-libs/glibc/files/eblits/common.eblit
+++ b/sys-libs/glibc/files/eblits/common.eblit
@@ -318,8 +318,9 @@ setup_env() {
unset LD_RUN_PATH
unset LD_ASSUME_KERNEL
- multilib_env ${CTARGET_OPT:-${CTARGET}}
if is_crosscompile || tc-is-cross-compiler ; then
+ multilib_env ${CTARGET_OPT:-${CTARGET}}
+
if ! use multilib ; then
MULTILIB_ABIS=${DEFAULT_ABI}
else
--
2.9.0
[gentoo-dev] [PATCH 0/4] New no-lib-symlink profile for developers
Hello, everyone. I've finally gotten around to wrapping up my multilib setup in a profile, and providing necessary patches to system packages to make it possible to use it without having to hack their mistaken logic around. The profile is called 'no-lib-symlink', and is provided as an alternate amd64 variant. Unlike the common profiles, it is based on three lib* directories: lib32 for 32-bit binaries, lib64 for 64-bit binaries and lib as a directory for software packages only (the new-style libexec). Please note that this is not the goal layout Gentoo should be working towards. In that layout, 'lib' needs to be used for 32-bit binaries for ABI compatibility's sake. My layout is rather targeted at developers who can benefit from having a clear split on where packages install files, and therefore being able to catch mistakes such as using 'lib' and $(get_libdir) interchangeably. This batch of patches includes also three patches for base system packages: a. a patch to prevent glibc from overriding LIBDIR* variables set by profiles. The logic used there is probably used for cross-compiling, and so it is moved into cross-compiling branch of code. b. a patch to fix 'else' branch of baselayout for SYMLINK_LIB=no systems. For some reason, this branch created 'lib' symlink when 'lib' did not exist -- therefore triggering another branch of code on next baselayout installation that replaced the symlink with a directory. The patch changes it to create the directory instead. c. a patch to prevent baselayout from complaining when both lib and lib32 are separate directories. In order to cover that case while preserving compatibility with the original intent, it skips the complaint when lib32 is considered a valid directory as well as lib. -- Best regards, Michał Górny --- Michał Górny (4): sys-libs/glibc: Do not reset multilib vars unless cross-compilnig, #588368 sys-apps/baselayout: Fix SYMLINK_LIB=no to create lib dir instead of sym sys-apps/baselayout: Do not complain about lib+lib32 when it is valid profiles: Add an amd64 no-lib-symlink profile profiles/arch/amd64/no-lib-symlink/make.defaults| 2 ++ profiles/arch/amd64/no-lib-symlink/parent | 1 + profiles/default/linux/amd64/13.0/no-lib-symlink/parent | 2 ++ profiles/profiles.desc | 1 + sys-apps/baselayout/baselayout-2.2-r1.ebuild| 6 ++ sys-libs/glibc/files/eblits/common.eblit| 3 ++- 6 files changed, 10 insertions(+), 5 deletions(-) create mode 100644 profiles/arch/amd64/no-lib-symlink/make.defaults create mode 100644 profiles/arch/amd64/no-lib-symlink/parent create mode 100644 profiles/default/linux/amd64/13.0/no-lib-symlink/parent -- 2.9.0
Re: [gentoo-dev] man pages: build or copy?
On Sat, Jul 9, 2016 at 3:54 PM, Neil Bothwick wrote:
> I've created an ebuild for net-misc/zerotier [1]. This has a BDEP on
> app-text/ronn, the build system uses it to create the man pages. The
> trouble is that ronn is a Ruby program and pulls in a shedload of
> dependencies, just to install man pages.
>
> It seems to me to make more sense to put pre-built man pages in
> ${FILESDIR}/${PV} and copy them with doman. Is this considered the
> correct or acceptable way to deal with this?
In dev-libs/nanomsg, I've hidden building the docs behind the "doc"
USE flag. nanomsg builds it docs with AsciiDoc, which also pulls in
ruby and a bunch of stuff. Personally, I don't care that much about
the ruby packages, but on my servers, I don't generally even need ruby
itself, so I'd rather not install it. Since this grants the user the
choice of how to use your package, it seems in line with Gentoo's
principles.
Cheers,
Dirkjan
Re: [gentoo-dev] man pages: build or copy?
On 07/09/2016 09:54 AM, Neil Bothwick wrote:
> I've created an ebuild for net-misc/zerotier [1]. This has a BDEP on
> app-text/ronn, the build system uses it to create the man pages. The
> trouble is that ronn is a Ruby program and pulls in a shedload of
> dependencies, just to install man pages.
Ruby packages (besides dev-lang/ruby itself) install quickly, like perl
packages, so this isn't a *huge* deal. They can also be removed
afterwards with a depclean.
> It seems to me to make more sense to put pre-built man pages in
> ${FILESDIR}/${PV} and copy them with doman. Is this considered the
> correct or acceptable way to deal with this?
It's up to you. If they release a new version every day, it's going to
get real annoying to regenerate the man pages each time. Also keep an
eye on the size of the man pages. We have a soft limit of "a few
kilobytes" for things in FILESDIR, which may mean you'd have to upload
the man pages somewhere else and include that in SRC_URI. Doing so makes
the regeneration process even more annoying.
Nevertheless, I've had to pre-build man pages for a few packages myself.
Re: [gentoo-dev] the graveyard overlay
On 07/08/2016 04:50 PM, Alec Warner wrote: On Fri, Jul 8, 2016 at 1:21 PM, Philip Webb mailto:purs...@ca.inter.net>> wrote: 160708 William Hubbs wrote: > On Fri, Jul 08, 2016 at 05:56:04PM +0300, Andrew Savchenko wrote: >> IMO the criteria should be whether they work or not, >> not whether upstream is more or less active. >> If they're blockers on other work, by all means cull them. >> However, if the biggest problem with them is >> that they're using a few inodes in the repo, they should probably stay. > There is an overlay for packages that are removed from the official tree > -- https://github.com/gentoo/graveyard -- > and that is where old software should go, > if it doesn't have an active maintainer. A lot of this lengthy discussion is missing some basic points, though a few people have mentioned them in passing. As someone who has used Gentoo exclusively since 2003 & who raised the objections to removal of Xcdroast + Nethack, let me try to get you all to focus on the real-life issues. (1) The fact that a pkg has little or no upstream support or that it doesn't have an active Gentoo maintainer is not a reason for removing it from the regular tree. +1 So basically what you are advocating for is: "Having completely unmaintained packages in the tree is OK." And honestly, I do not buy that premise. I think what Phillip has outlined is that different use cases have different prospective on use, stability and security. Take the ancient serial (rs232-C) code based net-dialup/minicom for example. It has long outlived it's usefulness for most users. Serial ports that have TCP/IP laid on top of them use to form the backbone of phone line modem access. "Upstream:None specified" Yet it is still extraordinarily useful to embedded systems work, and industrial uses, such as modbusTCP/ppp/rs232. To a "go hacker" it needs to be cleaned out, but to an older or embedded hacker it is fundamental to raw hardware access. Granted the "Maintainer: embed...@gentoo.org (Embedded Gentoo)" has stepped up. So, my point is there are (probably) lots of other example codes in the 1500 unmaintained packages that have not yet been scrutinized by the larger gentoo user community. I've got over a dozen deprecated packages in my /usr/local/portage/ tree, as I try to keep up with the tree cleaners on old useful codes. "no maintainer" should not be part of the criteria for removal, at least not for a year or so. WE need to document the methods and procedures for proxy-maint, to a robust level, before such actions are warranted. Then a campaign to recruit proxy maintainers for a while. Right now the devManual, quizzes, repo structures(github, sunrise etc), eapi, and many other aspects of gentoo are in a phase of rapid change. It's going to take a while to get things stabilized and documented and then a period of recruitment. I know, I for one have been on this path and things are time consuming. Just look at the dev-wrangling over many of these issues. That is the reason we have 1500 orphaned packages. For now, I suggest we just label these packages as deficient, no-maintainer, security, inactive-upstream and any other relevant statuses. While some parse the proxy-maint correspondences to first create FAQs and then a guide, with some basic examples. Then aggressive removal would be viable and community supported. This effort would also bode well for corporations to train and maintain their linux sources with lots of folks participating in a full-spectrum structure, that these discussions illuminate, should we want to attract new and younger hackers to gentoo. A well defined proxy-maint program would do more for gentoo recruiting (of both devs and users) than most any thing else, imho. Teach a user how to create and maintain their own code, and you'll have a user for life. One basic reason some software is no longer being actively developed is simply that they work perfectly well as they now are, eg the file manager Krusader & the desktop manager Fluxbox : both of these are very useful & have no drop-in replacements, but very little development has occurred for several years. The same is true of Xcdroast & Nethack, which have been threatened, but which have been rescued after some small patches have been applied. This is likely to be true of more + more pkgs, as time passes : even changes in the kernel these days rarely affect desktop users. !1. No one is trying to remove flubox (which had a release in 2015 and had activity in its git repo as recently as last week.) Xcdroast for example, hasn't had a release in 8 years and I can't even find its source tracker in sourceforge. These are the sorts of packages that I think are not great to have in the tree and for Xcdroast, if I were treecleaner lead i would probably advocate for working around the security b
[gentoo-dev] man pages: build or copy?
I've created an ebuild for net-misc/zerotier [1]. This has a BDEP on
app-text/ronn, the build system uses it to create the man pages. The
trouble is that ronn is a Ruby program and pulls in a shedload of
dependencies, just to install man pages.
It seems to me to make more sense to put pre-built man pages in
${FILESDIR}/${PV} and copy them with doman. Is this considered the
correct or acceptable way to deal with this?
1) https://bugs.gentoo.org/show_bug.cgi?id=588324
--
Neil Bothwick
pgp0hWLNMY6sU.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] the graveyard overlay
160708 Alec Warner wrote: > On Fri, Jul 8, 2016 at 1:21 PM, Philip Webb wrote: >> (1) The fact that a pkg has little or no upstream support >> or that it doesn't have an active Gentoo maintainer >> is not a reason for removing it from the regular tree. > So basically what you are advocating for is: > "Having completely unmaintained packages in the tree is OK". > And honestly, I do not buy that premise. I went on to point out : >> One basic reason some software is no longer being actively developed >> is simply that they work perfectly well as they now are, >> eg the file manager Krusader & the desktop manager Fluxbox : >> both of these are very useful & have no drop-in replacements, >> but very little development has occurred for several years. >> The same is true of Xcdroast & Nethack, which have been threatened, >> but which have been rescued after some small patches have been applied. >> This is likely to be true of more + more pkgs, as time passes : >> even changes in the kernel these days rarely affect desktop users. My point here is that lack of upstream development doesn't necessarily mean that an app is "dead", but may simply result from it's being completed. Xcdroast simply works & had 1 obscure security problem, now fixed. The problem with other burners is that they demand sound software, which I have no need for on my system, so I want to go on using the simple reliable app which has always got the job done. > No one is trying to remove Flubox, which had a release in 2015 > and had activity in its git repo as recently as last week. Not yet, they're not, but changes have been minimal for a long time. Krusader had an update in Git 24 hours ago, but the latest version is 3 years old. It's an excellent file manager, which I rely on regularly, but it's only "semi-alive" upstream. > Xcdroast for example, hasn't had a release in 8 years > and I can't even find its source tracker in Sourceforge. > These are the sorts of packages I think are not great to have in the tree > and for Xcdroast, if I were treecleaner lead, I would probably advocate > for working around the security bug (dropped SUID) instead of removal. > I do not necessarily want to remove software that people are using. So you are saying -- perhaps correctly -- that the problem here was not bad tree-cleaning policy, but incompetent tree-cleaning (I don't mean to criticise whoever did it : I make mistakes too). > That being said, I do not want unmaintained software in the tree either. This is not black vs white : a package can be 'lightly maintained', ie there's no regular maintainer, but equally there are no real problems & those which exist could be fixed fairly easily, if need be. That was the case with Xcdroast & earlier with Nethack. So another suggestion from me for Gentoo policy -- like recognising different categories of user -- is to create a new class of pkg called 'lightly maintained', which would include older but still useable software, which is no longer being actively developed, as it is largely complete. >> (2) There are 3 basic categories of Gentoo user : >> (a) server-farm managers, (b) multi-user sysadmins, (c) single-users. >> Each of these have different security concerns : >> (a) need to be alert to the many threats from all over the Internet ; >> (b) need (among other things) to prevent privilege escalation ; >> (c) are largely immune to those types of threat, >> though a few of the Internet variety can affect them. > I appreciate the argument you are trying to make, > but I do not think it should drive Gentoo Security Policy. Surely, it's very relevant for the reasons I have listed : eg I don't have to worry re privilege escalation, as I can escalate my privileges anytime I want by opening a root terminal (no-one else has physical access to my machine). > As my security manager used to say "security is not a race to the bottom". Obviously true, but that's not in question here. > Suppose : > 1) It appears that no Gentoo developers want to maintain a package. > 2) The software package has no active upstream. > 3) The software has open bugs. > 4) We mask it for years, because it has bugs and no active maintainer. > 5) No one volunteers to proxy-maintain the software. > You advocate we keep such software in the tree, > because users are "too busy" or "too old" to maintain it themselves ? Yes, I do, depending on how serious the bugs are : in the cases of Xcdroast + Nethack, they were not serious on single-user systems. Nor do I accept your scare quotes : most users are too busy to be able to become developers nor should they be asked to ; the average age of Gentoo developers seems to be around 30 years, so anyone 50 years old or more would find the job that much more challenging. >> (b) there needs to be a developer role 'General Maintainer', > In an ideal world, the tree would be full of properly maintained packages. > There are > 1500 packages in the tree in the 'maintainer-needed' state : > see htt
Re: [gentoo-dev] masking and removing *coin packages
On 2016-07-08 08:10, james wrote: > On 07/08/2016 05:17 AM, Andrew Savchenko wrote: > > On Thu, 7 Jul 2016 20:30:36 -0400 Anthony G. Basile wrote: > >> Hi everyone, > >> > >> I emailed the list some time ago about giving away a bunch of bitcoin > >> forks to see if anyone was interested in taking them. I didn't get any > >> feedback so as of tomorrow I'll be masking the following for removal in > >> 30 days. > > > > Any reason for mask and removal? Are these packages broken? > > Just drop them to maintainer-needed. > > > > Best regards, > > Andrew Savchenko > > > > Perhaps we should start posting these orphaned-package announcements to > gentoo-user, so folks interested in learning about ebuilds can ponder > proxy-maintenance of a few packages as an opportunity? > > > Surely there is a wider audience that will see some packages they like > are going away because there are not enough maintainers, and thus > respond by 'stepping up' to maintain a few packages? I would think those who are interested in (and capable of) maintaining packages would already be subscribed to gentoo-dev. -- Tuomo Hartikainen
