Nope, I still get it...

git fetch
git checkout
python setup.py develop

Add an: assert(type(buf) == buffer) after the im.color_conv call, like

rows, cols, buf = im.color_conv (BYTE_FORMAT)
assert(type(buf) == buffer)
surface = ...

I think it should return a buffer type anyway due to unicode issues between 2 and 3.

Okay, I have got it to work by doing this as a workaround in backend_cairo.py:

rows, cols, buf = im.color_conv (BYTE_FORMAT)
buf = bytearray(buf)

Not the best fix as I think this just sticks a plaster over a problem with the C code not returning the right type.

I'd prefer not to return a buffer type from C, since it's been deprecated on Python 3 (honestly, GtkCairo shouldn't be using it anymore, but that's what we've got to work with here). Instead, the best we can do is return something that GtkCairo can turn into a buffer object, in this case a bytearray. So we know from your assert that it's not a buffer, but what is it? Still a str? It should be a bytearray if everything got recompiled correctly. And from your suggested fix, we know that Cairo takes a bytearray just fine.

I'm surprised it's not working for you. Can you go a git clean -fxd first? python setup.py develop is really flaky about rebuilding enough C code.

Also, it may be that you're not building this branch, from what you said above:

git fetch
git checkout

Yes, it still gave me a string... I will try doing a clean :).

I left out the specific names from the commands above:

git fetch master pull/4164/head:pr4154-fix-cairo-buffer
git checkout pr4154-fix-cairo-buffer

Okay, it works now for me 👍 it would help if I didn't make a 2nd typo in the PR name.

I get back buf of type <type 'bytearray'>

One more thing, did you mean to set the milestone for this as next major release, or next point release?

Oh, and Travis seems rather silent now...

The bug only exists on master, so it doesn't matter whether it's next major release or point release.

Travis seems to be universally stuck today -- not sure why.

I have an email draft I have not sent out yet, but 'next point' -> 2.1, 'next major' -> 3.0, 'color overhaul' -> 2.0

Re Travis, they have bugs of their own http://www.traviscistatus.com/

@mdboom If it is only on master, we don't need to backport this to color_overhaul which is based on 1.4.3.

@tacaswell cover overhaul, or color overhaul?

color. Interesting typo there...

Hmm, this never got merged, do I have the permissions to restart a Travis build? If so, how do I do that?

If go to travis.ci there should be a 'log in with github' link in the tippy top right and give it access to your public repos. Once you are logged in, the build will have a 'restart' button in the top right (but a bit lower than the login).

Odd, I don't see a link, on the travis profile page it says:

    You are not currently a member of
    any organization.

Is an organization missing?
Review and add your authorized Orgs.

but git hub says travis has access, hmph...

I restarted it.

@mdboom, I gather from your comment that this does not need to be backported to color_overhaul--but the title and milestone still indicate that it does need to be backported. Would you clarify this, please?