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

[muppet <scott asofyet org>]

On Jul 17, 2010, at 10:28 AM, gregor herrmann 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?

[snip]

> On Thu, May 20, 2010 at 06:57:26PM +0300, Niko Tyni wrote:
> > Package: libgtk2-perl
> > Version: 1:1.221-6
> > Severity: serious
> >
> > This package is not migrating to testing because it failed to build
> > on mips.
> >
> >  #   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 is reproducible on gabrielli.d.o.
>
> It's something of a heisenbug: running with the perl debugger 
> ('perl -d -Iblib/lib -Iblib/arch t/GtkCellRenderer.t') fails the first time,
> but after a restart ('R') the tests pass.
>
> The callback that doesn't get called is gtk2perl_cell_renderer_render(),
> in xs/GtkCellRenderer.xs.
>
> The class callbacks get initialized properly in
> gtk2perl_cell_renderer_class_init(), but gtk+ never calls the renderer
> one.
>
> It would be somewhat interesting to eliminate xvfb from the loop, but
> I can't seem to get an X11 connection to gabrielli.
>
> Unfortunately I won't have the time to look further into this in the
> next few weeks.  Hope this note helps somebody else a bit.
>
> There's 1.222 available upstream, but looking at the changes, I very
> much doubt it fixes this.


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.

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+?

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.

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.


--
Baseball is complicated.  I think I'd rather stick with learning about motorcycle engines.
  -- Elysse, baffled by the rules of baseball