Hi list,
a quick mail to announce that the gnome team, in order to prepare for
gnome 3, started slotting a lot of gnome team managed packages. If you
find yourself using such a package, please update your ebuilds to use
slot notations or other EAPI compliant notation resulting in the same
effect.
Le lundi 21 février 2011 à 15:09 +0100, Gilles Dartiguelongue a écrit :
> Hi list,
>
> a quick mail to announce that the gnome team, in order to prepare for
> gnome 3, started slotting a lot of gnome team managed packages. If you
> find yourself using such a package, please update your ebuilds to
On Thu, 10 Feb 2011, Ryan Hill wrote:
On Wed, 9 Feb 2011 13:04:11 +0100
Ulrich Mueller wrote:
Maybe we also need a guideline that whenever possible, ebuilds should
accept the default USE flags from our profiles as a valid combination?
Or, in the exceptional case when that isn't possible, a pa
# Markos Chandras (21 Feb 2011)
# Does not work with gnome-panel-2.32.1. Bug #355901
# Removal in 30 days
x11-misc/talika
--
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
pgpE8C1E9awlj.pgp
Description: PGP signature
Hello lads,
I would like you to review following patches we kept hidden from you in
x11 overlay up till now.
xorg-2:
autotools-utils usage
- out of tree build by default
- killing all .la files
added doc dependencies
- it is same for all pkgs and easier to keep it in eclass
Python 3.2 is now in the main tree. It is currently package.masked.
Currently I'm planning unmasking on friday 2011-05-13 :) .
Bug #python-3.2 [1] is used to track incompatible packages. This bug can be
blocked ONLY by bugs in packages, which work correctly with Python 3.1.
[1] https://bugs.gento
Hi,
In theory, the check_license function from eutils.eclass is obsoleted by
ACCEPT_LICENSE support which has been available in stable since January
2010 when sys-apps/portage-2.1.7.16 was marked stable [1].
We may want to actively remove this function from ebuilds, especially
for cases in which
The bugs are stacking up[1] and upstream only offers a paid version of
pdflib-8[2]. It is my understanding that there is no way for us to
package future versions and the bundled libs are vulnerable[3].
So, should it be removed? For more info, see the tracker bug for its
removal[1], there are a
On Tuesday, February 22, 2011 00:32:52 Jeremy Olexa wrote:
> The bugs are stacking up[1] and upstream only offers a paid version of
> pdflib-8[2]. It is my understanding that there is no way for us to
> package future versions and the bundled libs are vulnerable[3].
>
> So, should it be removed? F
