libcitygml ftfs with new openscenegraph

This doesn't even come close to a point where pkgbinarymangler (or pkg-create-dbgsym) is involved. Linked the relevant Debian bug (thanks Daniel Holback for pointing out). Sounds like this just needs a merge now.

This bug was fixed in the package libcitygml - 0.14+svn134-2+3p2p1

---------------
libcitygml (0.14+svn134-2+3p2p1) unstable; urgency=medium

  * Team upload.
  * Tweak OpenSceneGraph version detection in gencontrol script.
    Fixes FTBFS on kfreebsd-*.

 -- Bas Couwenberg <email address hidden> Sun, 28 Sep 2014 00:44:08 +0200

libcitygml (0.14+svn134-1+3p2p1) unstable; urgency=medium

  * Team upload.
  * Apply patch from Jonathan Wiltshire to fix FTBFS with OpenSceneGraph 3.2.1.
    (closes: #763047)

 -- Bas Couwenberg <email address hidden> Sat, 27 Sep 2014 16:39:53 +0200

Unfortunately the sync doesn't fix it, calling the gen_control script with bash doesn't fix it either.

amd64 vivid: https://launchpadlibrarian.net/198138827/buildlog_ubuntu-vivid-amd64.libcitygml_0.14%2Bsvn134-2%2B3p2p1ubuntu1_FAILEDTOBUILD.txt.gz

i386 vivid: https://launchpadlibrarian.net/198138870/buildlog_ubuntu-vivid-i386.libcitygml_0.14%2Bsvn134-2%2B3p2p1ubuntu1_FAILEDTOBUILD.txt.gz

To fix the issue mentioned in comment 3, I adjusted the install paths, but still no dice, the gencontrol script breaks:

amd64 vivid: https://launchpadlibrarian.net/198152891/buildlog_ubuntu-vivid-amd64.libcitygml_0.14%2Bsvn134-2%2B3p2p1ubuntu2_FAILEDTOBUILD.txt.gz
i386 vivid: https://launchpadlibrarian.net/198152918/buildlog_ubuntu-vivid-i386.libcitygml_0.14%2Bsvn134-2%2B3p2p1ubuntu2_FAILEDTOBUILD.txt.gz

(dget https://launchpad.net/~dholbach/+archive/ubuntu/ppa/+files/libcitygml_0.14%2Bsvn134-2%2B3p2p1ubuntu2.dsc)

Can anyone help with this?

Bas: can you advise?

I can't reproduce this problem: on my system (dpkg-buildpackage -b with fakeroot, in amd64 vivid+vivid-proposed chroot on Debian kernel) it builds successfully (log attached).

I also don't see where the "19 1" can be coming from (unlike the "0~rc1" in the vaguely similar https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719396 ); the below debian/gencontrol was meant to find out, but that requires a system where the bug happens.

LIBOSG_SHARE=`dpkg --get-selections | grep "libopenscenegraph[0-9]*:.*\s*install" | awk '{print $1}' | awk -F: '{print $1}'`
LIBOSG_VERSION=`dpkg -l $LIBOSG_SHARE | grep "^ii\s*$LIBOSG_SHARE" | awk '{print $3}' | sed 's/-.*//'`
TMP1=`echo $LIBOSG_VERSION | awk -F '.' '{print $1}'`
TMP2=`echo $LIBOSG_VERSION | awk -F '.' '{print $2}'`
TMP3=`echo $LIBOSG_VERSION | awk -F '.' '{print $3}' | sed 's/~.*$//'`
echo $LIBOSG_SHARE
echo $LIBOSG_VERSION
echo $TMP1
echo $TMP2
echo $TMP3
TMP3=$((TMP3+1))
echo $TMP3
LIBOSG_VERSIONPLUS=$TMP1.$TMP2.$TMP3~
echo $LIBOSG_VERSIONPLUS
dh_gencontrol -- -Vlibosg-share="$LIBOSG_SHARE" -Vlibosg-static="libopenscenegraph-dev (>= $LIBOSG_VERSION), libopenscenegraph-dev (<< $LIBOSG_VERSIONPLUS)"

> Bas: can you advise?

I'm not in the best position for that right now, as I don't have my VMs
available here.

libcitygml was fixed in Debian for OSG 3.2.1 with 0.14+svn134-2+3p2p1,
make sure you're using that revision in Ubuntu too.

While briefly looking over the bug report it looks like you do, so I'd
need to reproduce the issue in a Vivid VM (which I need to setup first) to
be able to assist further.

I may find the time for that tonight after I get back from work.

The buildlogs I checked all fail with:

dh_install: openscenegraph-plugin-citygml-shared missing files
(usr/lib/*/osgPlugins-*/*.so), aborting

This suggests the osgPlugins are not using Multi-Arch paths as they do in
Debian. There was a thread about that on debian-devel, see:

https://lists.debian.org/debian-devel/2015/02/msg00276.html

Not sure if it's related.

A guess at what's going on: the first line of gencontrol is failing to find libopenscenegraph100 (possibly because the grep pattern assumes dpkg --get-selections will include the :arch suffix; does it do that if multiarch isn't on?), and the second line is hence extracting the version numbers of _everything_ installed.

dholbach's test builds appear to have been without -proposed as they used libopenscenegraph99, which isn't multiarch (the libopenscenegraph100 in -proposed is), but I don't have any other theory for where the 19 comes from.

If it is multiarch-related, the fix would be to replace the libopenscenegraph[0-9]*:.*\s*install pattern with libopenscenegraph[0-9]*[:\s].*install

Ah ok, it looks like PPAs don't use -proposed?

Locally I got it to build, without modifications from Debian. I'm not quite sure what to do.

PPA:s use -proposed if set so in the Edit PPA dependencies page.

No luck with the suggested change from comment #9:

https://launchpadlibrarian.net/198181539/buildlog_ubuntu-vivid-amd64.libcitygml_0.14%2Bsvn134-2%2B3p2p1ubuntu1~vivid1~test1_FAILEDTOBUILD.txt.gz

With debug gencontrol from comment #6:
https://launchpadlibrarian.net/198182758/buildlog_ubuntu-vivid-i386.libcitygml_0.14%2Bsvn134-2%2B3p2p1ubuntu1~vivid1~test2_FAILEDTOBUILD.txt.gz

I can't help anymore today though.

That confirms that the problem is on the first line (i.e. LIBOSG_SHARE is being set to the empty string), but means it isn't related to the presence or absence of a multiarch suffix.

The version numbers that end up in LIBOSG_VERSION appear to be only packages that are in the base/build-essential system (eg. gcc), as opposed to the ones installed as build-dependencies of libcitygml itself (eg. the libopenscenegraph100 this script is trying to find): is that all that dpkg --get-selections and/or dpkg -l list in an Ubuntu buildd setup?

The simple solution would be to stop trying to autodetect the version and hardcode LIBOSG_SHARE=libopenscenegraph100, LIBOSG_VERSION=3.2.1, and (to fail the build if we forget to update these) a Build-Depends: libopenscenegraph100 (<< 3.2.2~) with a "see debian/gencontrol" comment.

Just harcoding the stuff and skipping the brittle gencontrol is an option.

FWIW, my build on vivid with build-deps from vivid-proposed completed without issues.

The current libcitygml will only build successfully with OSG 3.2.1, not also 3.2.0.

https://launchpad.net/ubuntu/+source/libcitygml/0.14+svn134-2+3p2p1ubuntu1 in proposed now, but there's probably more work to be done for the openscenegraph migration? Simgear is in binary NEW queue so needs to be accepted by archive admins.

Note regarding this bug that anyone can experiment with the PPA's when you just go to the Edit PPA dependencies page and enable -proposed. I think it'd be useful to get some more automation back, whatever the cause of the problem is.

> there's probably more work to be done for the openscenegraph migration?

ossim, osgearth and openwalnut need rebuilding (but probably no actual changes, given Debian's experience).

I experimented on the same PPA and based on that I've uploaded no-change rebuilds of osgearth, openwalnut and choreonoid, but qgis is failing and would need some sort of a fix: bug #1423906

ossim uploaded too, and Bas hinted at patches to backport for qgis. Thanks hugely to everyone helping! simgear binaries should still be accepted from the NEW queue, but it's possible the OSG transition otherwise could be handled.

This bug was fixed in the package libcitygml - 0.14+svn134-2+3p2p1ubuntu1

---------------
libcitygml (0.14+svn134-2+3p2p1ubuntu1) vivid; urgency=medium

  * debian/gencontrol: Hardcode the first two lines based on suggestions in
    LP: #1368801 to fix FTBFS instead of the string manipulation
  * debian/control: Require << 3.2.2 of openscenegraph, to force updating
    gencontrol when osg gets updated
 -- Timo Jyrinki <email address hidden> Fri, 20 Feb 2015 10:26:29 +0200