Hans de Graaff | 2 Sep 07:31 2014

Last rites: dev-java/jruby-1.6

# Hans de Graaff <graaff <at> gentoo.org> (1 Sep 2014)
# Mask jruby 1.6.x for removal in 30 days. This version is still based
# on ruby 1.8.  Many packages are no longer compatible with its
# syntax, and security support for ruby 1.8 has stopped. This
# incompatibility now has reached central packages like rubygems so we
# have decided to remove jruby 1.6 now.  jruby upstream has released
# the 1.7.x series some time ago, but unfortunately we only have a
# masked version that has too many issues to unmask. Please let us
# know if you know java and ruby and want to help out here:

Michał Górny | 1 Sep 12:52 2014

Unifying option passing conventions in the PMS

Hello again, developers.

Don't worry, this is the last e-mail I was planning to send :).
Currently, PMS doesn't have any convention for option passing.
In particular, we have:

a. has_version and best_version having long '--host-root' (no

b. dodoc, doheader, doins have short '-r' option. docompress has short
'-x' option.

c. dohtml has whole lot of short options, some taking parameters.

d. doman has -i18n=LANG old-style long option.

(econf, emake, einstall are pass-through so they don't count)

In other words, it's an inconsistent mess. I think we should set up
a few basic rules for functions in PMS, and hopefully spread them into
eclasses as well.

While normally I'd suggest following getopt_long() as close
as possible, I don't think this is the best way here since:

1. I'm not ware of any sane, dep-free, portable way of reusing
getopt_long() from bash.

2. Implementing the whole option parsing would introduce a lot of extra
code for each function.
(Continue reading)

Michał Górny | 31 Aug 23:39 2014

Unified directory slash convention for EAPI6?

Hello, developers.

The directory conventions in PMS are confusing developers for a long
time. Long story short, D, ED, ROOT and EROOT are supposed to contain
a trailing slash while remaining directory variables don't. This often
confuses developers and brings repeating mistakes resulting in double
slashes in paths.

For example, developers often write '${D}/usr/bin/foo', while they
should '${D}usr/bin/foo'. Of course, this gets more complicated with
every variable added. For example, if you were to reference
bashcompdir, you'd have to use pattern substitution to actually remove
double slashes, e.g. '${D%/}$(get_bashcompdir)'.

More than a year ago, I've suggested that we unify the convention for
directories and require all of them not to contain a trailing slash
[1]. The bug contains all the details, including statistics (year old
but still) and repoman check suggestions.

I would like to suggest finally doing the change for the sake of
improved consistency. EAPI 6 is a great opportunity to clean up some of
the historical mess, and make ebuild writing have one pitfall less.

What do you think?



Best regards,
Michał Górny
(Continue reading)

Samuli Suominen | 31 Aug 16:13 2014

udev-9999 (and upcoming 217) no longer has userspace firmware loader (will need Linux 3.7 for firmware's to be loaded)

Trying to raise awareness:



I will release a GLEP 42 news item *at the same time* =sys-fs/udev-217
is released into ~arch, so nobody
will get caught off guard

Consider this message a prenotice, now you know it's gone

- Samuli

Pacho Ramos | 31 Aug 14:14 2014

readme.gentoo.eclass: expand variables when a file is used instead of setting DOC_CONTENTS in ebuild

This tries to solve:

Looks to do the job but maybe there are shorter or saner ways of doing

Thanks for your help
Attachment (1.patch): text/x-patch, 966 bytes
Michał Górny | 30 Aug 22:54 2014

The future of einstall


I believe that we should work towards deprecating and removing
the einstall helper from PMS, for the following reasons:

1. einstall is confusing to new developers and contributors who often
see it as the 'proper' way of installing software -- mostly because of
the name matching econf/emake/einstall scheme. Likely that scheme was
desired in the past.

2. The use for it is pretty scarce. Major build systems and most of
the common custom Makefiles support DESTDIR. For the few remaining
cases, it's rather optimistic throwing of variables into make,
and hoping they would work.

Why do we have einstall?

I don't know the exact reasoning for having it in the first place.
One reason I've heard is that old versions of automake didn't support
DESTDIR, and therefore we had to specify all the directories. However,
DESTDIR support in automake dates back to 1998 when automake 1.3 was
released -- and that pretty much predates Gentoo.

I've asked Ciaran about it, and he said that 'the idea was to avoid
people duplicating anything'. In other words, that einstall was used
only because calling 'emake install DESTDIR="${D}"' was considered bad.

If anyone could shed some more light into this, I'd appreciate that.

(Continue reading)

Anthony G. Basile | 30 Aug 22:02 2014

RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.

Hi everyone,

I've written a GLEP which outlines a standard for what information 
should be stored by any package management systems (PMS) in /var/db/pkg 
(VDB) and mandates some API for exporting it to other tools [1].  The 
need to do so was discussed in the Council during the 20130910 meeting 
[2].  During that meeting, the council focused on NEEDED.ELF.2 which is 
recorded by portage, but not paludis. Linkage information is generated 
during package builds, is expensive to recalculate and is needed by 
other packages like revdep-pax for PaX marking ELF objects.

I've aimed to make the GLEP open to how each PMS team wants to implement 
this without being too vague.  We should also consider carefully the 
list of items we want cached although we could always update this list 

Feedback welcome.

[1] https://wiki.gentoo.org/wiki/GLEP:64
[2] http://www.gentoo.org/proj/en/council/meeting-logs/20130910-summary.txt


Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness <at> gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

(Continue reading)

Michał Górny | 30 Aug 13:46 2014

maintainer-needed <at> packages need you!


Right now, we have 1262 packages assigned to maintainer-needed <at> . Only
a few of them have a large number of bugs, many have just version bump
requests. 953 packages have no bug open.

Please consider adopting some of the packages, or at least fixing some
of the relevant bugs. For package - bug count list, take a look at [1].
Please note that this list is not autogenerated, so it will soon be
outdated, I hope :).

We should also consider removing some of the packages listed there.



Best regards,
Michał Górny
Jauhien Piatlicki | 30 Aug 01:09 2014

systemd profiles

Hi all,

I have a simple question: why do we have systemd subprofiles only in gnome and kde profiles?

Could we add systemd subprofiles also to default/linux/$arch/13.0/ and desktop (and any other profiles
where it makes sense)?

Thanks for answers,

Michał Górny | 29 Aug 20:37 2014

Guidelines for forward bash-completion compatibility

Hello, developers.

Here are a few short notes on how to properly install bash-completions
so that they will work fine with autoloading support that will be
enabled in bash-completion-2.1-r100.

I will also place the following instructions on the wiki once I figure
out where. Suggestions are welcome :).

1. Completion files are to be installed to the directory specified by
$(get_bashcompdir) from bash-completion-r1 (dobashcomp and newbashcomp
respect that).

1a. Allowed exception: if the build system has hardcoded
/usr/share/bash-completion/completions path, it is acceptable to leave
it as-is and not use the eclass.

1b. Allowed exception: if the build system uses pkg-config to determine
completionsdir and doesn't allow override, it is acceptable to leave
it as-is. However, you need to DEPEND on app-shells/ebash-completion
then -- so it's better to actually make the path configurable.

2. Completion files must be named after *all* commands they're
completing. For example, completion for pulseaudio has to be named
'pulseaudio' and not 'pulseaudio-bash-completion.sh'.

2a. If a completion file provides completions for multiple commands,
it should be installed for one of the commands, and symlinked for
the others. For example, 'pacat', 'paplay', 'parecord' etc. should be
all symlinked to 'pulseaudio'. Extra aliases can be created using
(Continue reading)

Sven Vermeulen | 29 Aug 17:30 2014

Removing 'selinux? ( sec-policy/selinux-*)' from DEPEND

tldr; I want to remove USE="selinux" deps from DEPEND in
non-libselinux-linking packages in a sane manner and use a bug tracker with
6 months timeframe.

Hi all

In the past, to enable proper SELinux support in our tree, we had to have
the appropriate SELinux policy modules installed and loaded before the
package/application for which the policy was designed is merged to the
system. The reason is that otherwise the files installed on the system will
have the wrong labels assigned, making the applications unable to function

We implemented this by having the USE="selinux" triggered dependency in both
DEPEND (needed before merge) and RDEPEND (policy needs to be available
during runtime), like so:

DEPEND="selinux? ( sec-policy/selinux-somepolicy )"
RDEPEND="selinux? ( sec-policy/selinux-somepolicy )"

Recently, we updated the SELinux eclass so that after installation of a
policy package, the reverse dependencies of that package are looked up and
those reverse dependencies are relabeled (i.e. proper SELinux labels are
assigned to the files of that package).

With this change, we implement the same end result (correctly labeled files
after installation) while removing the need for the DEPEND dependency. After
all, this was not a build-time dependency but a "merge-time" one, which we
abused a bit to make things work.

(Continue reading)