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'
signature.asc
Description: Digital signature
