pyside version 1.0.4-1 failed to build in oneiric

Building this has been a challenge. Both pbuilder and sbuild fail on the libphonon-dev build-dep, e.g.:

│ Install pyside build dependencies (apt-based resolver) │
└──────────────────────────────────────────────────────────────────────────────┘

Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 sbuild-build-depends-pyside-dummy : Depends: libphonon-dev but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
apt-get failed.
Package installation failed
Not removing build depends: cloned chroot in use

However, if I use the aptitude resolver, I can get sbuild to continue past this problem. Perhaps that's a bug with libphonon-dev, but atm I'm not shaving that particular yak. `sbuild --build-dep-resolver=aptitude` for now to see if the originally posted ftbfs can be confirmed.

Hrm, I generally find sbuild's internal resolver to be the closest to Launchpad buildds. In this case, the internal resolver works fine (sbuild 0.62.5-1)

On Aug 30, 2011, at 08:57 PM, Stefano Rivera wrote:

>Hrm, I generally find sbuild's internal resolver to be the closest to
>Launchpad buildds. In this case, the internal resolver works fine
>(sbuild 0.62.5-1)

Here's what the sbuild(1) manpage says about the internal resolver:

       --build-dep-resolver=resolver
              ...
              mended for use by default. The internal resolver is much
              older, contains several significant deficiencies such as not
              being able to handle complex alternative and virtual dependen‐
              cies, and is deprecated. Like apt, it only uses the first
              alternative build dependency when multiple alternatives exist.
              It is not recommended for future use, and will be removed in
              the future.

I've generally had pretty good luck with the default apt resolver. I think
this is the first case where it's failed me.

Further information, if, after the initial failed attempt to install the build
dependencies, I enter the preserved chroot and do `apt-get build-dep pyside`
they all install just fine. This makes me wonder whether this is an sbuild
problem, an apt problem, or a problem with the dependencies.

My local pyside build is still ongoing (it takes a long time), but I'll give
the internal resolver a shot to see if I can confirm your observation. I
suppose I'll file a bug on sbuild after that, and it can always be
re-targeted to apt if that's the real problem.

Cheers.

(this is way off topic for the bug, but wth). Launchpad uses an internal fork of sbuild from ages ago (before the apt/aptitude resolvers) which is why the internal resolver is closer to launchpad. Debian uses the aptitude resolver on most buildds, and apt on some.

Yeah, I'm still building it too... And I pointed the debian maintainer to this bug, he generally cares about Ubuntu (and has a PPA where newer pysides have built just fine https://launchpad.net/~pyside/+archive/ppa/+packages )

If this can be solved with a sync, I'd do that.

Not syncable (pyside is a twisted heap of dependencies :) ):

After installing, the following source dependencies are still unsatisfied:
debhelper(inst 8.9.0ubuntu1 ! >= wanted 8.9.3~) shiboken(inst 1.0.4-2 ! >= wanted 1.0.6) libshiboken-dev(inst 1.0.4-2 ! >= wanted 1.0.6) shiboken-dbg(inst 1.0.4-2 ! >= wanted 1.0.6) generatorrunner(inst 0.6.11-1 ! >= wanted 0.6.12) libgenrunner-dev(inst 0.6.11-1 ! >= wanted 0.6.12)

Yes. One has to do the set.

My local build finally ended, confirming the failure in the original posting. Unfortunately, Chromium decided just then was a good time to lock the machine, so I lost my session. I'll start another build now so I can take a closer look at the problem in the morning. I guess I'll take this opportunity to try the built-in resolver.

<hat type="Debian-maintainer-of-pyside" on="head" />
Some data points:
a) if you want to sync from Debian, you need apiextractor, generatorrunner and shiboken
b) you don't need to run the full build to see if it will succeed, running one (of the 4) configure is enough.
c) I'm maintaining the same packages for PySide "upstream" on lucid+maverick+natty PPAs: https://launchpad.net/~pyside/+archive/ppa/+packages and they "always" work, so the issue is probably a change is Qt/phonon/whatever and not PySide (I guess).

@ScottK: given where we are in the release cycle, doesn't it make more sense to try to fix the immediate problem rather than sync a bunch of new packages? debhelper is the most worrying one.

The problem appears to be that phonon.so doesn't get built so there's nothing to install, and the d/python-pyside.phonon.install names a non-existent file. I'll look at the PPA to see if that's an easy fix. I actually see nothing in the build log that even references phonon.so until the install failure.

 @barry: debhelper is needed because of multiarch, that can easily be backported. In fact the PPA reverts everything multiarch-related.

On Aug 31, 2011, at 03:19 PM, Didier Raboud wrote:

>@barry: debhelper is needed because of multiarch, that can easily be
>backported. In fact the PPA reverts everything multiarch-related.

Thanks for the help Didier. I think it's worth at least giving the sync a
try. I'll work on that and see how it goes.

I've built the Debian sid stack of packages, and PySide still doesn't build phonon.so, so something else must clearly be going on.

Build log?

FYI, I have just uploaded "backported" packages targetted at oneiric to the "official PySide PPA":
https://launchpad.net/~pyside/+archive/ppa/+packages We'll see what gets out of that.

On Sep 02, 2011, at 09:32 AM, Didier Raboud wrote:

>FYI, I have just uploaded "backported" packages targetted at oneiric to the "official PySide PPA":
>https://launchpad.net/~pyside/+archive/ppa/+packages We'll see what gets out of that.

Great, thanks Didier. I uploaded my own local build log so we can compare
what happens with yours. Looks like we only have to wait a few hours for the
PPA builds to start. :)

Looking at the Debian build log I see it says:

-- Checking for VideoCaptureDevice in phonon -- found

during configure and yours doesn't. I checked and libphonon-dev has the same VideoCaptureDevice headers in both distros, so no idea what's up there.

On Sep 02, 2011, at 02:21 PM, Scott Kitterman wrote:

>Looking at the Debian build log I see it says:
>
>-- Checking for VideoCaptureDevice in phonon -- found
>
>during configure and yours doesn't. I checked and libphonon-dev has the
>same VideoCaptureDevice headers in both distros, so no idea what's up
>there.

Googling found one possible match in an armel ftbfs, but AFAIC the referenced
patch in upstream has been applied to our copy, so I don't think that's it.
What's interesting here isn't that the check fails, but that it doesn't happen
at all.

I'm not a cmake expert, so I've got to do some additional research.

Didier, could you take a look at PySide/phonon/CMakeLists.txt and tell me what the top of the file says. Here's what I've got:

project(phonon)

# workaround for a cmake bug under MacOSX, it finds phonon but not the include path
if (NOT QT_PHONON_INCLUDE_DIR AND CMAKE_HOST_APPLE)
    set(QT_PHONON_INCLUDE_DIR "${QT_LIBRARY_DIR}/phonon.framework/Headers")
endif ()

set(phonon_OPTIONAL_SRC )
set(phonon_DROPPED_ENTRIES )
check_qt_class(phonon VideoCaptureDevice phonon_OPTIONAL_SRC phonon_DROPPED_ENTRIES Phonon ObjectDescription)

Now, I don't know cmake very well, but from a quick scan of its documentation, the two set() commands look suspicious. It seems to me that it's setting those variables to the empty string. I have no idea if that's right or not, but I'd love to compare that against what you have.

A bit more information:

In PySide/CMakeLists.txt, if you replace the line that says

HAS_QT_MODULE(QT_PHONON_FOUND phonon)

with

add_subdirectory(phonon)

then you get the

-- Checking for VideoCaptureDevice in phonon -- found

line, and it appears to build phonon (I haven't tested it all the way through yet, I killed it to test a few other things). It looks like if you expand HAS_QT_MODULE you get two tests:

if (NOT DISABLE_phonon AND QT_PHONON_FOUND)

so I tried each of these. NOT DISABLE_phonon appears to be true (expected), but QT_PHONON_FOUND does not appear to be true (unexpected, I'd think). This is making me think there's a problem with the libphonon-dev build, though I can't see it, and don't know enough about the Qt build system or cmake to find it (yet :). WAG: could it be some problem with libphonon-dev and multiarch?

So, I think one quick workaround, which I'll test all the way through now, is to just 'add_directory(phonon)' unconditionally. If that works, I'll commit and dput the fix, and open another bug on phonon to figure out why QT_PHONON_FOUND is false, since that may affect other packages.

One more thing: if this does manage to hack around the problem, then we still have the decision of whether to upgrade to a newer PySide and dependencies. My suspicion is that the same hack will get PySide 1.0.4 building too so an upgrade would not strictly be necessary. Scott, do you have an opinion on that (given that we're already in beta and an update would require FFes)?

If pyside still doesn't have any rdepends, I think we're should just go with
the latest.

On Sep 02, 2011, at 06:10 PM, Scott Kitterman wrote:

>If pyside still doesn't have any rdepends, I think we're should just go with
>the latest.

There are rdeps in the stack:

Package: python-pyside.qtcore
Reverse Depends:
  python-pyside.qtcore:i386,python-pyside.qtcore
  python-pyside.qtxml,python-pyside.qtcore 1.0.4-1
  python-pyside.qtscript,python-pyside.qtcore 1.0.4-1
  python-pyside.qtnetwork,python-pyside.qtcore 1.0.4-1
  python-pyside.qtgui,python-pyside.qtcore 1.0.4-1
  python-pyside-dbg,python-pyside.qtcore 1.0.4-1
  python-pyside,python-pyside.qtcore 1.0.4-1
  pyside-tools,python-pyside.qtcore 1.0.4
  python-pyudev,python-pyside.qtcore

Package: python-pyudev
Reverse Depends:
  kde-config-touchpad,python-pyudev

Package: kde-config-touchpad
Reverse Depends:
  kubuntu-full,kde-config-touchpad
  kubuntu-desktop,kde-config-touchpad
  kcm-touchpad,kde-config-touchpad

The rest seem to be internal to the package. Since I don't know much about
Qt, could one of you please look into that? Assuming the build with my patch
completes, I'll upload it to ppa:barry/python for testing.

From the upstream IRC chan, today:

<renato> OdyX`, I have confirmed the problem is related with cmake + phonon dev package
<renato> I suggest to you create a patch that always add the phonon dir on CMakeList file
<renato> until we get this problem fixed on phonon-dev package

I will prepare such a -2+o1 package and upload it to the PPA; if it successes, I'll prepare a -2ubuntu1 up for sponsorship.

On Sep 05, 2011, at 09:14 PM, Didier Raboud wrote:

>>From the upstream IRC chan, today:
>
><renato> OdyX`, I have confirmed the problem is related with cmake + phonon dev package
><renato> I suggest to you create a patch that always add the phonon dir on CMakeList file
><renato> until we get this problem fixed on phonon-dev package
>
>I will prepare such a -2+o1 package and upload it to the PPA; if it
>successes, I'll prepare a -2ubuntu1 up for sponsorship.

Before the long USA holiday weekend, I did manage to get PySide 1.0.6 built
locally with this exact change, however I think if we really want to go with
the latest PySide and its dependents[1], an FFe will be necessary. I don't know
enough about PySide to know whether it's worth upgrading or not. If you think
it is, please file the FFe.

In the meantime, I'm going to backport my fix to PySide 1.0.4 and upload it.

Has a bug on phonon-dev been filed?

[1] apiextractor, generatorrunner, and shiboken updates are necessary. I
downgraded debhelper to 8.9.0 in the debian/control file and that worked fine.

I spoke with one of the phonon developers (who's also a Kubuntu dev) and he felt the problem was that the phonon detection in pyside was wrong.

Unless Odyx says otherwise, we want the latest pyside stack (FFe approved).

This bug was fixed in the package pyside - 1.0.6.1-2ubuntu1

---------------
pyside (1.0.6.1-2ubuntu1) oneiric; urgency=low

  * debian/patches/force-phonon.patch:
    Force the addition of the phonon directory to the CMake files.
    (LP: #832864)
  * debian/control: Ubuntu 11.10 only has debhelper 8.9.0.
 -- Barry Warsaw <email address hidden> Fri, 02 Sep 2011 13:38:16 -0400

Looks like this is a bug in /usr/share/cmake-2.8/Modules/FindQt4.cmake. It expects all Qt4 modules to be in a subdirectory of QT_LIBRARY_DIR, but phonon hasn't been multi-arched yet.