Re: [gentoo-dev] [PATCH 4/4] Example conversion of pygobject to python-r1 + autotools-utils.

[Michał Górny]

On Thu, 29 Nov 2012 17:50:28 +0100
Gilles Dartiguelongue <eva@g.o> wrote:

> First, thanks for this patch, I was planning on converting it but did
> not have to do it.

Well, the patch was on the ml a while ago but it was reply to one
of the mails, so it was hard to notice it.

> Le jeudi 29 novembre 2012 à 14:40 +0100, Michał Górny a écrit :
> > ---
> >  .../dev-python/pygobject/pygobject-3.2.2-r1.ebuild | 106 +++++++++++++++++++++
> >  1 file changed, 106 insertions(+)
> >  create mode 100644 gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild
> >
> > diff --git a/gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild b/gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild
> > new file mode 100644
> > index 0000000..289eace
> > --- /dev/null
> > +++ b/gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild
> > @@ -0,0 +1,106 @@
> > +# Copyright 1999-2012 Gentoo Foundation
> > +# Distributed under the terms of the GNU General Public License v2
> > +# $Header: /var/cvsroot/gentoo-x86/dev-python/pygobject/pygobject-3.2.2.ebuild,v 1.5 2012/09/28 05:45:45 mattst88 Exp $
> > +
> > +EAPI="4"
> > +GCONF_DEBUG="no"
> > +PYTHON_COMPAT=( python2_6 python2_7 python3_1 python3_2 )
> > +AUTOTOOLS_AUTORECONF=1
> > +
> > +inherit autotools-utils eutils gnome2 python-r1 virtualx
>
> Please do not mix autotools utils with gnome2 eclass. gnome team does
> not support out of tree builds for now. I have plans to integrate this
> in the eclass but we found that upstream generally does not test this so
> we want to test it more extensively before making this available.

Well, the main purpose of this patch was to demonstrate using
out-of-source builds with python-r1.

Therefore, I ask thee: is it acceptable then to use gnome2-utils
in the eclass or shall I restrain completely from using out-of-source
builds on that package?

One thing I can assure you is that this package supports them.

> > +# FIXME: With python multiple ABI support, tests return 1 even when they pass
> > +src_test() {
> > +	local DBUS_SESSION_BUS_ADDRESS
> > +	local GIO_USE_VFS='local' # prevents odd issues with deleting ${T}/.gvfs
> > +	local VIRTUALX_COMMAND=python_test
> > +
> > +	export GIO_USE_VFS
> > +
> > +	python_foreach_impl virtualmake
> > +
> > +	python_execute_function -s testing
> > +}
> > +
> dbus variables needs to be unset for tests to work when you do your
> builds from a terminal started from your desktop, is that really
> equivalent ?

You are correct that it isn't. I wrote the patch before I actually
noticed how crazy local+export logic works. We need to re-export
DBUS_SESSION_BUS_ADDRESS here. Also, I forgot
to remove python_execute_function... silly.

After doing those two changes, the tests succeed for me
with DBUS_SESSION_BUS_ADDRESS set in the parent env.

To be more correct, they succeed for py2.7, 3.1 & 3.2.

In python2.6 they fail with:

    @unittest.expectedFailure
AttributeError: 'module' object has no attribute 'expectedFailure'

But that's another story.

I'd say that the ebuild works 100% fine in the version I'm attaching
to this mail.

-- 
Best regards,
Michał Górny