Ulrich Mueller | 28 Nov 22:14 2015

RFD: Replacement for versionator.eclass in PMS (for EAPI 7?)

As you may know, we intend to move the functionality of
versionator.eclass to the package manager, possibly in EAPI 7.
The following is what mgorny and myself have come up with, see
bug 482170 [1], especially comments 15 and 16 there.

Currently there are 15 functions defined in that eclass, and we
believe that it will not be feasible to implement all of them.
However, several of the functions are similar to each other and can
be combined. Two of them, namely get_version_component_range() and
replace_version_separator(), account for the vast majority of what
is used by ebuilds.

We therefore think that the following three functions would be
sufficient to cover all ebuilds' needs:

version_test [VERSION1] OP VERSION2

This comes in a two and a three argument form. Syntax is based on
test(1) (therefore the name).

- Compares VERSION1 with VERSION2, using the usual PMS version
  comparison algorithm.

- OP can be one of -eq, -ne, -lt, -le, -gt, -ge, i.e. the binary
  arithmetic operators from test(1). (We avoid C style <, >, etc.
  because they suffer from quoting issues.)

- Both VERSION1 and VERSION2 must be valid Gentoo versions.

(Continue reading)

Michał Górny | 28 Nov 20:10 2015

Re: [PATCH] python-utils-r1.eclass: python_export_utf8_locale(), ensure sane locale

On Sun, 15 Nov 2015 10:21:51 +0100
Michał Górny <mgorny <at> gentoo.org> wrote:

> Ensure that the locale selected by python_export_utf8_locale() conforms
> to POSIX-ish case conversions. Otherwise, we may accidentally force
> a locale that will break random ebuilds and programs.
> ---
>  eclass/python-utils-r1.eclass | 24 ++++++++++++++++++++++--
>  1 file changed, 22 insertions(+), 2 deletions(-)



Best regards,
Michał Górny
Justin Lecher | 28 Nov 14:24 2015

[PATCH 0/8] virtualx.eclass: New API and EAPI=6 support

The main new feature is the introduction of virtx(). This function executes
the arguments inside a Xfvb context in contrast to the deprecated
virtualmake which required to set VIRTUALX_COMMAND, which then gets

Xemake and Xeconf should be converted to "virtx emake" and "virtx econf",

Justin Lecher (8):
  virtualx.eclass: Use case/esac to handle supported EAPIs
  virtualx.eclass: Only source eclas once
  virtualx.eclass: Use eqawarn instead of ewarn "QA:..."
  virtualx.eclass: Ban deprecated functionality in EAPI > 5
  virtualx.eclass: Support EAPI=6
  virtualx.eclass: Whitespace cleanup
  virtualx.eclass: Add missing die
  virtualx.eclass: Simplify API into single virtx()

 eclass/virtualx.eclass | 87 +++++++++++++++++++++++++++++++++++++-------------
 1 file changed, 65 insertions(+), 22 deletions(-)



Andreas K. Huettel | 28 Nov 01:25 2015

Introducing perl-functions.eclass

Hi all, 

before we even start implementing EAPI=6 stuff, Perl support will be 
reorganized a little bit. 

TL;DR: No need to do anything. :)

Longer version:
We're going to split all helper functions out of perl-module.eclass into a new 
eclass, perl-functions.eclass. 

* perl-functions will export no phases and keep all global variable meddling 
to a minimum. If you need perl support in a package that has a non-perl build 
system, this is what you may want to use in the future to get some helpers.

* perl-module.eclass will inherit perl-functions, and all things exported by 
perl-functions are explicitly also part of the API of perl-module (documented 
in the eclass), so you dont have to explicitly inherit perl-functions in your 
ebuild as well. perl-module.eclass is the "ready-made solution for CPAN", 
exporting all required phases.

We are only splitting the code into two parts now, but not really changing 
anything. So, because of abovementioned inheritance all ebuilds should just 
keep working as usual. 

Some changes will come later with the introduction of EAPI=6 support. 

(Boring) Patch attached for completeness. 

(Continue reading)

Michał Górny | 27 Nov 15:53 2015

[PATCHES] systemd.eclass: Clean up & EAPI 6 support


Here's an EAPI 6 patch set for systemd.eclass for review. Major changes:

1. commonized out pkg-config getters alike bash-completion-r1,

2. removed systemd_to_myeconfargs (long deprecated and unused),

3. banned systemd_with_* in EAPI 6, write --with-*= explicitly instead,

4. disallowed systemd_update_catalog outside pkg_post*.

Best regards,
Michał Górny

Michał Górny | 27 Nov 14:53 2015

[PATCHES] bash-completion-r1.eclass: Error handling cleanup + EAPI 6


A quick patch set to bash-completion-r1.eclass. Adds missing ||die,
||return to bashcomp_alias for nonfatal and enables EAPI 6. Please

Best regards,
Michał Górny

Andreas K. Huettel | 26 Nov 20:43 2015

New arches??

Hi all, 

just curious, where did "riscv" come from

(and nios2, but that seem's to have been around for longer...)




Andreas K. Huettel
Gentoo Linux developer 
dilfridge <at> gentoo.org

Kristian Fiskerstrand | 25 Nov 18:12 2015

[RFC] New project: Crypto


As recently discussed herds are migrating to projects, and in that
connection we've now set up a project[0] for what was previously the
Crypto herd.

Please consider this an official announcement and request for comment
related to establishing a new project.

[0] https://wiki.gentoo.org/wiki/Project:Crypto


Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
William Hubbs | 25 Nov 18:10 2015

rfc: adding sbin directories to PATH for all users


I would like for us to discuss adding the sbin directories to PATH for
all users.

The only reason I can think of that we have removed them is cosmetic (it
removes things from tab completion), but I have also heard that having
those things in tab completion would be a good thing.

Another reason I am bringing this up is this bug [1]. On standard OSx,
there is no reason to hard code the path to sysctl like I'm being asked
to do in the patch associated with this bug, because the sbin
directories are always  in the path. In other words, it isn't worth the
effort to send this patch upstream, which means there will always be a
Gentoo-specific patch to dev-lang/go unless upstream finds another way
to do the test they are doing on OSx via sysctl.

Any ideas?



[1] https://bugs.gentoo.org/show_bug.cgi?id=558368
Michał Górny | 25 Nov 15:40 2015

repo-mirror-ci now provides exported function info, and cache for pull requests

Hello, everyone.

I'm pleased to announce that the services run by repo-mirror-ci project
had received a little update yesterday. I've added three new features:

1. EAPI=6 awareness. All our services are running pkgcore, and sadly
pkgcore does not support EAPI=6 yet. While I can't currently afford to
implement all features of EAPI=6 at the moment, I have enabled
the minimal support needed to get cache updates and pkgcheck working.

2. Metadata cache for pull requests. Now all pull requests are mirrored
in [1] along with the master branch of Gentoo repository. The pull-NNN
branches contain the pull request state with metadata cache merged on
top of it. Furthermore, cache update is done and committed twice --
before and after the pull request commits. As a result, you can easily
compare changes to cache the pull request does, e.g. [2].

3. Exported function information. Have you even wondered which of
the inherited eclasses sets a particular phase function? You have to
guess no more, my little hack to pkgcore [3] figures that out for you.
The results are put in metadata cache [4] since they're quite expensive
to obtain, and since we update metadata cache for pull requests, you can
now easily see if a pull request changes inherited phase functions!

As a matter of formality, I have to add that the last feature is quite
fresh and the result format may change when it gets polished and added
to more package managers. Currently the entry lists all redefined phase
functions in form of <phase>:<eclass> for phase functions defined by
eclasses, or <phase>:- for phase functions defined in ebuild. Phases
not listed have no explicit overrides, so are defined by EAPI or not
(Continue reading)

Gilles Dartiguelongue | 25 Nov 15:19 2015

[PATCH] xdg.eclass: break dependency loop with glib and utility packages

Hello all,

making gnome2.eclass depend on xdg.eclass has the unfortunate
consequence of having xdg utility package in the dependency loop of
glib which uses gnome2.eclass for various features (such as gsettings
schema compilation).

Since there is no other need that I know of to make these dependencies
optional for xdg.eclass, I am proposing to have them skipped for glib

This issue currently breaks stage generation.


Gilles Dartiguelongue <eva <at> gentoo.org>