Robin H. Johnson | 28 Jul 02:25 2014
Picon

Automated Package Removal and Addition Tracker, for the week ending 2014-07-27 23h59 UTC

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

Removals:
virtual/perl-PodParser           	2014-07-21 19:12:16	dilfridge
perl-core/digest-base            	2014-07-22 19:34:16	dilfridge
virtual/perl-digest-base         	2014-07-22 19:45:04	dilfridge
perl-core/i18n-langtags          	2014-07-22 22:35:11	dilfridge
virtual/perl-i18n-langtags       	2014-07-22 22:45:12	dilfridge
perl-core/locale-maketext        	2014-07-23 00:00:53	dilfridge
virtual/perl-locale-maketext     	2014-07-23 00:08:28	dilfridge
perl-core/net-ping               	2014-07-23 00:20:39	dilfridge
virtual/perl-net-ping            	2014-07-23 00:28:03	dilfridge
virtual/perl-Switch              	2014-07-25 21:38:42	dilfridge
perl-core/Switch                 	2014-07-25 21:44:08	dilfridge
x11-misc/keytouch                	2014-07-27 10:33:07	pacho
x11-misc/keytouch-editor         	2014-07-27 10:33:14	pacho
media-video/y4mscaler            	2014-07-27 10:35:00	pacho
dev-python/manifestdestiny       	2014-07-27 10:37:09	pacho
dev-cpp/libsexymm                	2014-07-27 10:37:28	pacho

Additions:
virtual/perl-Pod-Parser          	2014-07-21 18:52:54	dilfridge
sci-libs/libcerf                 	2014-07-21 20:53:33	ottxor
games-fps/enemy-territory-omnibot	2014-07-22 01:36:22	ottxor
dev-libs/libflatarray            	2014-07-22 12:02:13	slis
perl-core/Digest                 	2014-07-22 19:29:54	dilfridge
virtual/perl-Digest              	2014-07-22 19:37:42	dilfridge
net-libs/stem                    	2014-07-22 20:56:10	mrueg
perl-core/I18N-LangTags          	2014-07-22 22:29:08	dilfridge
(Continue reading)

Jonathan Callen | 28 Jul 02:19 2014
Picon

Patches for multilib-build.eclass

The attached patches (attached so that Thunderbird won't mangle them)
fix some of the documentation for multilib-build.eclass, then add a
couple new functions to simplify some use cases where a flag would be
unconditionally enabled for native builds and disabled for non-native
builds.

--

-- 
Jonathan Callen
Pacho Ramos | 27 Jul 18:52 2014
Picon

Re: About what kind of changes could be stabilized on all arches by the same arch team

El dom, 27-07-2014 a las 07:31 -0700, Matt Turner escribió:
> On Sun, Jul 27, 2014 at 7:02 AM, Pacho Ramos <pacho <at> gentoo.org> wrote:
> > Recently I saw some cases where some bugs reported were getting blocked
> > by some arch teams being slow to reply. The issue is that this pending
> > bug reports were only related with changes that weren't arch dependent.
> >
> > Some cases that comes to my mind now:
> > - Changes only adding systemd unit files
> > - Changes to fix logrotate files (yeah, also to handle restarting of
> > services in systemd to stop trying to use openRC ways on them ;))
> > - Packages only installing icons, wallpapers.
> > - Any more do you remember?
> 
> I suppose maybe there are significant changes to the ebuild, if not
> the installed files but I always wonder whether stabilizing an -r1
> version that just adds multilib support on an architecture that
> doesn't have multilib should actually require any testing.

In that concrete case I would make it require testing-by-arch as it
involves several changes in ebuild and the way things are installed,
also usually introduce out-of-sources building that can cause new bugs
in some cases :|

Well, that is the main reason I wrote the original mail: to be able to
have a list of the changes we all agree that need no special checking
per arch :)

Pacho Ramos | 27 Jul 16:02 2014
Picon

About what kind of changes could be stabilized on all arches by the same arch team

Recently I saw some cases where some bugs reported were getting blocked
by some arch teams being slow to reply. The issue is that this pending
bug reports were only related with changes that weren't arch dependent.

Some cases that comes to my mind now:
- Changes only adding systemd unit files
- Changes to fix logrotate files (yeah, also to handle restarting of
services in systemd to stop trying to use openRC ways on them ;))
- Packages only installing icons, wallpapers.
- Any more do you remember?

I was wondering if we could document what kind of revision bumps
depending on the changes they imply could be stabilized in all arches
with the previous revision already stable on relevant arches by any arch
team member.

Thanks a lot

Pacho Ramos | 27 Jul 15:55 2014
Picon

Clarifying if some arch teams allows maintainers to stabilize package on arches they can test

Today some user on IRC noted that there were some doubts about if
developers are allowed to stabilize packages they maintain when they are
able to test on relevant arches (I guess this would benefit amd64 and
x86 mostly as it's likely more spread). 

If I don't misremember amd64 team allows that, but looks like devmanual
doesn't reflect that yet:
http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/

Then, I guess we would need a confirmation to fix devmanual and, in
advance, know more about if there is any other arch team allowing it
(x86?)

Of course, developers stabilizing packages should still follow the usual
test procedures as arch teams members will do.

Thanks a lot

Johannes Huber | 27 Jul 12:22 2014
Picon

CMake 3.0 unmasking

Hi all,

your favorite build tool =dev-util/cmake-3.0.0 just hit the tree. If no 
regressions show up, we would like to unmask it in ~30 days. Please test it!

Greetings,
--

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD
Pacho Ramos | 27 Jul 13:33 2014
Picon

Lastrites: app-crypt/opencdk, net-dialup/gnome-ppp, media-plugins/vdr-dxr3, media-video/dxr3config, media-video/em8300-libraries, net-misc/xsupplicant, sys-cluster/util-vserver, www-apache/mod_lisp2,dev-python/py-gnupg,media-sound/decibel-audio-player, sys-power/gtk-cpuspeedy, dev-lang/gforth,sys-fs/chironfs,app-emulation/emul-linux-x86-glibc-errno-compat, net-p2p/giftui, app-misc/discomatic, x11-misc/uf-view,

# Pacho Ramos <pacho <at> gentoo.org> (27 Jul 2014)
# Upstream dead, fails tests, nothing needs it.
# Removal in a month (#336256)
app-crypt/opencdk

# Pacho Ramos <pacho <at> gentoo.org> (27 Jul 2014)
# Upstream dead for ages, fails to build due underlinking,
# nothing needs it (#367573). Removal in a month.
net-dialup/gnome-ppp

# Pacho Ramos <pacho <at> gentoo.org> (27 Jul 2014)
# Not buildable for a long time, bug #414903
# Removal in a month.
media-plugins/vdr-dxr3
media-video/dxr3config
media-video/em8300-libraries

# Pacho Ramos <pacho <at> gentoo.org> (27 Jul 2014)
# Not building since 2012 (#423799). Removal in a
# month.
sys-cluster/util-vserver

# Pacho Ramos <pacho <at> gentoo.org> (27 Jul 2014)
# Fails to build, tries to access /proc, nothing
# needs it (#424093). Removal in a month
net-misc/xsupplicant

# Pacho Ramos <pacho <at> gentoo.org> (27 Jul 2014)
# Dead since 2009, not compatible with apache-2.4
# (#443670). Removal in a month.
(Continue reading)

Manuel Rüger | 26 Jul 15:38 2014
Picon

Call for help: app-admin/chef

Hello,

app-admin/chef and its related packages are currently maintainer-needed.

So if you're using chef on Gentoo, this is your chance to step up!

These packages have some restricting dependencies (e.g.
<dev-ruby/json-1.7.7), that ruby herd doesn't want to deal with.
Currently two version bumps (one major, one minor) are missing [1].

Ruby herd is willing to assist and help to work with ruby eclasses.

Feel free to ping me on IRC (#gentoo-ruby) if you want to help out,
otherwise we will have to treeclean it sooner or later.

Cheers,

Manuel

[1]
https://bugs.gentoo.org/buglist.cgi?quicksearch=app-admin%2Fchef&list_id=2433248

Pacho Ramos | 25 Jul 21:28 2014
Picon

About current ppc/ppc64 status

Hello

With last gnome maintained packages stabilization round I noticed some
pending stabilizations/keywordings for really a long time waiting for
ppc* teams. For example:
https://bugs.gentoo.org/show_bug.cgi?id=470768 -> it's waiting for more
than a year and it's blocking from dropping old versions for so long
https://bugs.gentoo.org/show_bug.cgi?id=508006 -> the same case, and we
cannot drop that stable keywords because looks like ppc team still wants
to keep kde in stable

Then, I finally needed to ask Agostino for help because of that and I
wondered if there are some kind of issue in this teams, if they are
still able to keep ppc* as stable arches or... :/

I see two options:
- Move ppc* to testing only -> I guess some people will disagree as this
architecture is not so old and probably it's still used by enough people
- Clarify what packages do they really want in stable. 

The problem of all this is that, as it is shown in this concrete
example, if they want to keep, for example, KDE in stable, they will
need to also be fast enough for other dependencies. If not, we could go
with the "package-per-package" proposal that was approved one year ago
by the Council for alpha/ia64. 

But the problem of "package-per-package" proposal is shown in:
https://bugs.gentoo.org/show_bug.cgi?id=470768#c9

Once we start dropping stable keyword in one package, we need to do the
(Continue reading)

Ian Stakenvicius | 25 Jul 20:49 2014
Picon

RFC: USE flags in virtuals, to allow a specific provider to be determined


Hey all..  So, putting aside for now how much of a mess this would be
to implement in the virtuals' ebuilds themselves, what do people think
of changing the virtuals so that they contain an entry in IUSE for
each provider that can satisfy it?

The idea here is that the package satisfying a virtual could be
optionally explicitly-chosen through package.use (or USE= in
make.conf, perhaps) instead of having an entry in  <at> world, that way if
nothing depends on the virtual then it and the provider can be
--depclean'ed from the system.  The idea is specifically NOT to have
rdeps depend on these flags, that would undermine the whole purpose of
the virtual; it would just be for end-users to set if they so chose.

This may also help with getting portage to peg a virtual's provider to
a specific package instead of constantly trying to switch from one to
another, ie, how systemd kept getting pulled in, in relation to the
upower virtual.  Note - I haven't done any tests to determine if this
actually helps with such issues tho (or even attempted to reproduce
them, as i was apparently one of the lucky ones that it didn't happen to).

I don't know if this would aid heavy binpkg users or not.

For completion, here's one of those rather messy examples:

--- virtual/krb5-0.ebuild       2013-06-28 09:04:47.000000000 -0400
+++ virtual/krb5-0.ebuild.new   2014-07-25 14:47:48.000000000 -0400
 <at>  <at>  -2,7 +2,7  <at>  <at> 
 # Distributed under the terms of the GNU General Public License v2
 # $Header: /var/cvsroot/gentoo-x86/virtual/krb5/krb5-0.ebuild,v 1.2
(Continue reading)

J. Roeleveld | 23 Jul 15:24 2014

Help needed with ebuilds for pear.horde.org

Hi All,

I am trying to create an ebuild for Egroupware 14.1. (released this month)

To find out the dependencies, I am going through the setup check and am stuck 
with the following:
**
Checking PEAR pear.horde.org/Horde_Imap_Client (2.16.0) is installed: False
PEAR::Horde_Imap_Client is needed by: EMailAdmin. You can install it by 
running: pear channel-discover pear.horde.org ; pear install 
pear.horde.org/Horde_Imap_Client
**

If I run those commands, it works, however, I prefer to use ebuilds for the 
dependencies.
I tried to create some based on existing ebuilds from the kolab overlay (they 
also use the "pear.horde.org" channel), but even though the install seems to 
work, it still isn't found.

I also tried to adjust an existing PEAR ebuild to:
**
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

inherit php-pear-r1

LICENSE="LGPL-3"
SLOT="0"
KEYWORDS="amd64"
(Continue reading)


Gmane