[Pkg-xfce-devel] Bug#824092: Bug#824092: orage: FTBFS on amd64, i386, arm64, armel, armhf buildds

[Andreas Henriksson]

Hello Yves-Alexis Perez.

Thanks for your quick followup. Some additional information from
me below which maybe I should have remembered to include in
my initial mail. Not sure how useful it is though...

On Thu, May 12, 2016 at 05:05:30PM +0200, Yves-Alexis Perez wrote:
> On jeu., 2016-05-12 at 09:49 +0200, Andreas Henriksson wrote:
> > It seems since the last sourceful upload (4.12.1-2) the package started
> > failing to build from source on some architectures.
> > 
> > See https://buildd.debian.org/status/package.php?p=orage
> 
> I've checked the log for amd64, and it seems that the error is:
> 
> checking for gtk+-2.0 >= 2.14.0... not found
> *** The required package gtk+-2.0 was not found on your system.
> *** Please install gtk+-2.0 (atleast version 2.14.0) or adjust
> *** the PKG_CONFIG_PATH environment variable if you
> *** installed the package in a nonstandard prefix so that
> *** pkg-config is able to find it.
> 	"tail -v -n +0 config.log"
> 
> Which doesn't make sense considering libgtk2.0-dev (>= 2.10.1) is in build-
> depends.

I've also quickly looked at the build logs and the sources to confirm
that the gtk+-2.0 development packages seems to be successfully installed
during the build and should be findable via pkg-config.

My gut feeling is rather that there might be something wrong with the
home-brew m4 macros, since searching for gtk+2.0 is just the first time
the home-brew macro is used in the configure script....
Move searching for gtk+-2.0 further down and I'd assume you'll instead
see an error for something else which would then be the first thing
search for using the home-brew macro XDT_CHECK_PACKAGE ...
Makes me wonder why the normal PKG_CHECK_MODULES macros doesn't suffice?

http://sources.debian.net/src/orage/4.12.1-2/configure.in/#L84
http://sources.debian.net/src/orage/4.12.1-2/aclocal.m4/#L10810

> 
> I think we need to reschedule the builds, I'll ask that, but I don't think the
> problem lies in the package.

If I'm not mistaken there where recent binNMU attempts because of the
ongoing libical transition.

Regards,
Andreas Henriksson