[gentoo-dev] gtk 3 preparation work
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. A non-exhaustive list of slotted libraries this far: gtk, gtksourceview, gtk-engines, libwnck, ... We aim at including gtk:3 in the coming days, so please forgive us if we get to your package before you read this mail. -- Gilles Dartiguelongue Gentoo
Re: [gentoo-dev] gtk 3 preparation work
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 use > slot notations or other EAPI compliant notation resulting in the same > effect. > > A non-exhaustive list of slotted libraries this far: gtk, gtksourceview, > gtk-engines, libwnck, ... > > We aim at including gtk:3 in the coming days, so please forgive us if we > get to your package before you read this mail. > > A precision, packages we only a slot 0 needs not to be slot depended on. We will slot move anything that needs to be and open tracker bugs once the first pass that this mail is about will be done. FTR, here is a exhaustive list of currently slotted packages in gentoo-x86 maintained by the gnome herds. If any of your packages uses one of these, please adjust your dependencies. Beware that some old slots have requests for removal that we are currently working on, so if your package depends on one such old slot, feel free to jump in the relevant bug reports. Package slots on their way out: * gnome-extra/libgnomedb < 4 (currently means all slots) * gnome-extra/libgda:1 (for now, 3 might follow soonish, we have :4) * dev-cpp/libgdamm:0 (we have :4) * x11-libs/gtksourceviewmm:1.0 (we have :2) I'll send a merged mail to dev-announce in a moment. -- Gilles Dartiguelongue Gentoo app-accessibility/gnome-mag:1 app-accessibility/gok:1 app-editors/ghex:2 app-office/abiword:2 app-text/scrollkeeper-dtd:1.0 dev-cpp/glibmm:2 dev-cpp/gnome-vfsmm:1.1 dev-cpp/gtkglextmm:1.0 dev-cpp/gtkmm:1.2 dev-cpp/gtkmm:2.4 dev-cpp/gtksourceviewmm:2.0 dev-cpp/libglademm:2.4 dev-cpp/libgnomecanvasmm:2.6 dev-cpp/libgnomemm:2.6 dev-cpp/libgnomeuimm:2.6 dev-cpp/libpanelappletmm:2.6 dev-cpp/libxmlpp:2.6 dev-cpp/pangomm:2.4 dev-lang/vala:0.10 dev-lang/vala:0.12 dev-libs/glib:1 dev-libs/glib:2 dev-libs/libcroco:0.6 dev-libs/libgweather:2 dev-libs/libsigc++:1.0 dev-libs/libsigc++:1.2 dev-libs/libsigc++:2 dev-libs/libunique:1 dev-libs/libxml2:2 dev-python/pygobject:2 dev-python/pygtk:2 dev-python/pygtksourceview:2 dev-util/glade:2 dev-util/glade:3 dev-util/gob:2 gnome-base/gconf:2 gnome-base/gnome-common:3 gnome-base/gnome-control-center:2 gnome-base/gnome-desktop:2 gnome-base/gnome-light:2.0 gnome-base/gnome-vfs:2 gnome-base/gnome:2.0 gnome-base/libglade:2.0 gnome-base/libgnomeprint:2.2 gnome-base/libgnomeprintui:2.2 gnome-base/libgtop:2 gnome-base/librsvg:2 gnome-base/orbit:2 gnome-extra/at-spi:1 gnome-extra/bug-buddy:2 gnome-extra/evolution-exchange:2.0 gnome-extra/gnome-media:2 gnome-extra/gtkhtml:2 gnome-extra/gtkhtml:3.14 gnome-extra/libgda:1 gnome-extra/libgda:3 gnome-extra/libgda:4 gnome-extra/libgnomedb:3 mail-client/evolution:2.0 media-gfx/eog:1 media-plugins/gst-plugins-meta:0.10 net-libs/gnet:2 net-libs/libsoup-gnome:2.4 net-libs/libsoup:2.4 net-libs/webkit-gtk:2 x11-libs/gdk-pixbuf:2 x11-libs/goffice:0.4 x11-libs/goffice:0.6 x11-libs/goffice:0.8 x11-libs/gtk+:1 x11-libs/gtk+:2 x11-libs/gtkglarea:1 x11-libs/gtkglarea:2 x11-libs/gtksourceview:1.0 x11-libs/gtksourceview:2.0 x11-libs/libgksu:2 x11-libs/libwnck:1 x11-libs/rep-gtk:gtk-2.0 x11-themes/gtk-engines-cleanice:2 x11-themes/gtk-engines-dwerg:2 x11-themes/gtk-engines-experience:2 x11-themes/gtk-engines-flat:2 x11-themes/gtk-engines:2 x11-themes/sawfish-themes:1
Re: [gentoo-dev] Re: Policy for conflicting USE flags
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 package.use entry should be added to profiles. Yes, we need to be careful when using REQUIRED_USE with global USE flags, especially the defaults. If a new user has to spend half an hour trying to figure out the magic combination of USE flags that will allow them to run `emerge @world` on their fresh install they're going to get frustrated and leave. I imagine it would break stage building as well (?) The stage building process is affected by ebuilds that die for conflicting and or missing use flags. Fortunately, stage building only builds packages in the system set and not the world set. So if you have a package in the system set, before you make it die in the above scenario, be sure to check with releng the impact and try to provide an "exception" for USE="build". --- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
[gentoo-dev] Last rites: x11-misc/talika
# 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
[gentoo-dev] Eclass review: xorg-2 virtualx
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
(ebuilds will be updated as bumped, live versions in overlay
are already prepared for this)
updated font disable calls
- with new fonts the disable call is much much easier so we
just need to reflect that
virtualx:
Pretty much add eclass-debug info everywhere and fix formatting.
migrate from "export maketype" to more reliable VIRTUALX_COMMAND global
variable (can be set anytime).
deprecate Xmake in favor of Xemake -j1 or VIRTUALX_COMMAND="emake -j1"
Change the VIRTUALX_REQUIRED and VIRTUALX_USE to be bit saner and merged
into one variable with qa deprecation warnings and fallback in place.
New usage described in eclassdoc pretty well.
So any comments? suggestions?
Cheers
Tom
--- /home/scarab/gentoo/gentoo-x86/eclass/virtualx.eclass 2010-11-12
15:43:12.0 +0100
+++ virtualx.eclass 2011-02-21 20:46:14.0 +0100
@@ -6,113 +6,132 @@
# @ECLASS: virtualx.eclass
# @MAINTAINER:
-# x...@gentoo.org
+# x...@gentoo.org
# @BLURB: This eclass can be used for packages that needs a working X
environment to build.
# @ECLASS-VARIABLE: VIRTUALX_REQUIRED
# @DESCRIPTION:
-# Is a dependency on xorg-server and xhost needed?
-# Valid values are "always", "optional", and "manual".
-# "tests" is a synonym for "optional".
-: ${VIRTUALX_REQUIRED:=optional}
+# Variable specifying the dependency on xorg-server and xhost.
+# Possible special values are "always" and "manual", which specify
+# the dependency to be set unconditionaly or not at all.
+# Any other value is taken as useflag desired to be in control of
+# the dependency (eg. VIRTUALX_REQUIRED="kde" will add the dependency
+# into "kde? ( )" and add kde into IUSE.
+: ${VIRTUALX_REQUIRED:=test}
-# @ECLASS-VARIABLE: VIRTUALX_USE
+# @ECLASS-VARIABLE: VIRTUALX_DEPEND
# @DESCRIPTION:
-# If VIRTUALX_REQUIRED=optional, what USE flag should control
-# the dependency?
-: ${VIRTUALX_USE:=test}
+# Dep string available for use outside of eclass, in case a more
+# complicated dep is needed.
+# You can specify the variable BEFORE inherit to add more dependencies.
+VIRTUALX_DEPEND="${VIRTUALX_DEPEND}
+ !prefix? ( x11-base/xorg-server[-minimal] )
+ x11-apps/xhost
+"
-# @ECLASS-VARIABLE: VIRTUALX_DEPEND
+# @ECLASS-VARIABLE: VIRTUALX_COMMAND
# @DESCRIPTION:
-# Dep string available for use outside of eclass, in case a more
-# complicated dep is needed.
-VIRTUALX_DEPEND="!prefix? ( x11-base/xorg-server )
- x11-apps/xhost"
+# Command (or eclass function call) to be run in the X11 environment
+# (within virtualmake function).
+: ${VIRTUALX_COMMAND:="emake"}
+
+has "${EAPI:-0}" 0 1 && die "virtualx eclass require EAPI=2 or newer."
case ${VIRTUALX_REQUIRED} in
+ manual)
+ ;;
always)
DEPEND="${VIRTUALX_DEPEND}"
RDEPEND=""
;;
optional|tests)
+ # deprecated section YAY.
+ ewarn "QA: VIRTUALX_REQUIRED=optional and
VIRTUALX_REQUIRED=tests are deprecated."
+ ewarn "QA: You can drop the variable definition completely from
ebuild,"
+ ewarn "QA: because it is default behaviour."
+
+ if [[ -n ${VIRTUALX_USE} ]]; then
+ # so they like to specify the useflag
+ ewarn "QA: VIRTUALX_USE variable is deprecated."
+ ewarn "QA: Please read eclass manpage to find out how
to use VIRTUALX_REQUIRED"
+ ewarn "QA: to achieve the same behaviour."
+ fi
+
+ [[ -z ${VIRTUALX_USE} ]] && VIRTUALX_USE="test"
DEPEND="${VIRTUALX_USE}? ( ${VIRTUALX_DEPEND} )"
RDEPEND=""
IUSE="${VIRTUALX_USE}"
;;
- manual)
- ;;
*)
- eerror "Invalid value (${VIRTUALX_REQUIRED}) for
VIRTUALX_REQUIRED"
- eerror "Valid values are:"
- eerror " always"
- eerror " optional (default if unset)"
- eerror " manual"
- die "Invalid value (${VIRTUALX_REQUIRED}) for VIRTUALX_REQUIRED"
+ DEPEND="${VIRTUALX_REQUIRED}? ( ${VIRTUALX_DEPEND} )"
+ RDEPEND=""
+ IUSE="${VIRTUALX_REQUIRED}"
;;
esac
+# @FUNCTION: virtualmake
+# @DESCRIPTION:
+# Function which attach to running X session or start new Xvfb session
+# where the VIRTUALX_COMMAND variable content gets executed.
virtualmake() {
+ debug-print-function ${FUNCNAME} "$@"
+
+ local i=0
local retval=0
local OLD_SANDBOX_ON="${SANDBOX_ON}"
local XVFB=$(type -p Xvfb)
local XHOS
[gentoo-dev] Python 3.2 in the tree
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.gentoo.org/show_bug.cgi?id=python-3.2 -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] RFC: check_license deprecation
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 it is the only reason that PROPERTIES=interactive is set (PROPERTIES=interactive is annoying because it inhibits parallel builds via emerge --jobs). [1] https://bugs.gentoo.org/show_bug.cgi?id=302001 -- Thanks, Zac
[gentoo-dev] Pending removal(?) of media-libs/pdflib
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 number of rdeps that will require fixing[4]. [1]: https://bugs.gentoo.org/355971 [2]: http://www.pdflib.com/download/free-software/pdflib-lite-7/ [3]: https://bugs.gentoo.org/253263 [4]: http://tinderbox.dev.gentoo.org/misc/rindex/media-libs/pdflib Thanks, -Jeremy
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
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? For more info, see the tracker bug for its > removal[1], there are a number of rdeps that will require fixing[4]. is there a suitable replacement functionality wise ? i'm aware of PHP based PDF generators (which often work great), but there doesnt seem to be any replacement for this package atm ? -mike signature.asc Description: This is a digitally signed message part.
