Bug#582410: (Fwd) Bug#582410: libgtk2-perl: FTBFS on mips: Failed test 'callbacks encountered'

[gregor herrmann]

On Sun, 18 Jul 2010 11:19:50 -0400, muppet wrote:

> > see below: libgtk2-perl has problems on the mips build daemon in
> > Debian. Maybe some of you guys has any idea what's going on there?

> >>  #   Failed test 'callbacks encountered'
> >>  #   at t/GtkCellRenderer.t line 228.
> >>  #     Structures begin differing at:
> >>  #          $got->[2] = 'size'
> >>  #     $expected->[2] = 'render'
> >>  # Looks like you failed 1 test of 20.
> >>  t/GtkCellRenderer.t ................ 
> >>  Dubious, test returned 1 (wstat 256, 0x100)
> >>  Failed 1/20 subtests 

> This behavior implies that there are cases in which the cell
> renderer is never being asked to draw itself. Since it works
> sometimes and not others, it seems unlikely that this is a problem
> with the bindings, but instead some interesting interaction between
> gtk+ and/or the display server.

Sounds reasonable.
(Or it's a toolchain problem on ia64 ...)
 
> The build log indicates that the code was built against gtk+
> 2.20.x, which is roughly in the right time frame to have offscreen
> rendering and some treeview drawing speed fixes. Either of these
> might cause the cell renderers not to be rendered. Is it possible
> to test this same binding code against an older or newer gtk+?

On the Debian porter machines we can only use chroots that have the
versions of a package that are currently in one of Debian's archive
areas, but not any "arbitrary" versions.
 
> The build log also shows the unit tests complaining that the
> display is missing the RENDER extension, which means that the tests
> were running with a DISPLAY. I presume it is to this that your xvfb
> comment refers.

Exactly.
We're running the test suite under xvfb in order to run as many tests
as possible, also those needing an X server where no "real" one is
present.
 
> If the DISPLAY variable is empty, the unit tests will skip the
> attempts to do real drawing and such, and only test binding and
> marshaling code. This build mode is intended for use by automated
> packaging systems, and may be the best option.

Ok.
In general I'm a bit reluctant to skip tests, but if it's the
upstream recommendation to skip those tests during automated building
that seems like a good reason.

Thanks for your help!


What do other people from the Debian Perl Group think?


Cheers,
gregor

-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-    NP: Jimi Hendrix: Hear My Train A Comin'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20100721/80dbf2e2/attachment.pgp>