[cairo] Testsuite changes this week

[Bryce Harrington]

On Wed, Sep 17, 2014 at 11:06:17PM +0200, Uli Schlachter wrote:
> Hi,
> 
> Am 17.09.2014 um 22:43 schrieb Bryce Harrington:
> > On Tue, Sep 16, 2014 at 09:14:07AM +0200, Uli Schlachter wrote:
> [...]
> >> Something is merging font options wrongly? Why does this code work for
> >> cairo-xlib? I don't know...
> >>
> >> For the xlib backend: Are you running with --enable-xlib-xcb? Aka "are you
> >> testing xlib at all?".
> > 
> > Yes.  I've attached the script I run, that has the build options I am
> > using.  Would appreciate a sanity check.
> 
> Nope, you did not.

Whoops.  Attached now.
 
> However, I would suggest you remove --enable-xlib-xcb. There were bugs in that
> glue code, but its way less code than the xlib backend itself and to me it
> sounds like a better idea to include the xlib backend (in your test suite runs.
> This code is actually used in production while configure warns everyone about
> using xlib-xcb.

Alrighty.
 
> AFAIR this would also get rid of a number of test suite failures (which are
> mostly due to cairo-xcb producing different output than cairo-xlib, I remember
> cases where cairo-xcb matched the image result and cairo-xlib had its own
> reference image. With --enable-xlib-xcb, that will count as a failure.)

Sounds good.  Since the results won't be comparable with past runs I'll
reset the numbers.

And since I'm resetting the numbers anyway, I'm going to make a more
extensive change, splitting my testing into three runs each with a
different config - one non-GL, the second with GLX, and third with EGL.

> >> Not much time right now (or in the near future), so can't look too closely into this
> > 
> > Thanks, based on Lukas' feedback sounds like we should disable it until
> > folks have time to investigate.  I'll push that change today.
> 
> Please leave behind a FIXME-comment explaing the "if 0". Thanks for doing this.

Done and pushed.

> > Uli, btw, when you have a few minutes, I'd like to get your quick input
> > on a few of our milestoned bugs that have patches - see:
> 
> In general these milestones were pretty much ignored. Someone decides the
> release is "good enough" and does a release.

Yes, totally understandable.  Still, I find it useful to boil them down
as part of the release process.

> >   https://bugs.freedesktop.org/show_bug.cgi?id=68382
> 
> On the "have a few minutes"-front: Not much time in the next two weeks. Deadline
> for my master's thesis.
> 
> Your "bug 85688" comment points at a bug that does not exit.
> 
> I am not touching bug 74779. Sorry, but that code is enough magic to scare me away.
> 
> Uhm, yeah.
> 
> > Also, in the interest of getting 1.14 done sooner rather than later, I
> > flagged four bugs I think we could postpone, but would like a second
> > opinion.
> 
> The "postpone" category is fine with me per the above description. 54991 can
> just be removed from tracker bugs, 55836 isn't going to happen unless someone
> works on it and that's nothing to be sad about.
> 
> Part 1 of 60496 sounds like "that other" bug against cairo-xcb which I don't
> intend to fix any time soon, so likely a case of --enable-xlib-xcb. Part 2 can
> go into the "no idea, wait for someone to figure things out, cairo-win32 is
> broken anyway"-category.
> 
> Bug 62606 can be removed from trackers due to NEEDINFO.

Thanks, I'll make these updates.

> > Oh, and did we ever get a firm decision about whether the next
> > release would be numbered as 1.14.0 or 1.12.18?
> 
> Someone asked about a new release from the 1.12 branch today. That would
> definitely be 1.12.18. I don't have the time yet and I'd want to double-check
> that the patches in the branch are fine and that nothing useful hides in master.
> I could do that in two weeks.

Sounds good.  As we had a number of build fixes on master, would benefit
us to encourage some build testing of the 1.12 branch on Win32, OSX,
Arch, etc. and port whatever fixes are needed there.

> A new release from master should be 1.14.0. It adds new public API (surface
> scaling) and the image scaling patches that are going around still scare me. I'm
> scared enough not to touch this.

Alright, I'll focus on rolling out a 1.14.0 release.  I've gotten
positive feedback from Inkscape QA folks that the scaling changes have
solved the problem at hand, so am not so scared.  I'm going to work on
fleshing out / improving the downscaling tests in the coming week, but I
don't see that as a blocker.

Bryce
-------------- next part --------------
#!/bin/bash

if [ "${PATH:0:16}" != "/usr/lib/ccache:" ]; then
    export PATH="/usr/lib/ccache:$PATH"
fi
export CC=

# Assume we're in the cairogles directory already
if [ -f Makefile ]; then
   make clean
fi
./autogen.sh
echo
echo "== Configuring =="
./configure \
    --enable-gl --enable-glx --enable-egl \
    --enable-test-surfaces \
    --enable-xlib-xcb \
    --enable-xml \
    --enable-gtk-doc

# Lots of build failures:
#    --enable-directfb \
#	    --enable-drm \
#	    --enable-skia \
export CC=/usr/bin/ccache
make -j32