>Number:         34663
>Category:       pkg
>Synopsis:       cairo is broken on non-x86 platforms
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Sep 29 14:15:00 +0000 2006
>Originator:     Stuart Shelton
>Release:        n/a
>Organization:
>Environment:
IRIX64 octane 6.5 07202013 IP30
>Description:

Any program which uses cairo (which means anything that uses GTK too) is broken on IRIX, and apparently Solaris/SPARC too.

Any program launches, runs correctly, and renders windows.  However, no text within these windows is drawn, and it seems that only some decals are drawn.

Gadgets are rendered correctly (e.g. the borders are drawn), but again no text is rendered.

In addition to this, there are many instances of:

No workaround for this pixel format: Visual: class=TrueColor, bpRGB=8, CM=256, r=ff, g=ff00, b=ff0000

... output to the console.

(Note: As mentioned below, bpRGB=8 is almost certainly wrong)
>How-To-Repeat:

Start any application which, directly or indirectly, makes use of cairo.
>Fix:

There is a bug report of this problem on Solaris here:

http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=bac51fc6d05a8b59fa3ebbb8:vCrm?bug_id=6445831

... which links to:

http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=f9e13032cc9a75fc4fc2f1968b11:vCrm?bug_id=6438502

... which is reported as closed and fixed.  Has the patch which supposedly fixes the problem been integrated into the pkgsrc build? (or, if it has, what was the last revision which *didn't* have this patch, for testing)

(Note that I'm running a 24bit desktop on an 16 byte/pixel (yes, really) display.  Apparently, some applications mis-detect IRIX as running at 8bit depth even when it isn't... I'm not sure if this has any bearing on the problem.)

Additionally, I found a related cairo diff here:

http://archives.neohapsis.com/archives/openbsd/2006-05/att-3002/cairo.diff


I'm wondering if cairo is mis-detecting the display as being 8bpp when it's really 24bpp - and then implementing a workaround for 8bpp displays which is unecessary, breaking things in the process...