Log file Viewer

[16:12:44] <deepy> Is there any way to install PIL or Pillow on NetBSD with JPEG support? I got the jpeg library and all but changing JPEG_ROOT in Pillow's setup.py doesn't help me at all

[16:13:25] <aclark> deepy: install jpeg-dev

[16:14:54] <deepy> I assume you mean graphics/jpeg by that, it's already installed

[16:15:26] <deepy> and in /usr/pkg/lib/ ( which I give in JPEG_ROOT ) I have libjpeg.so libjpeg.so.9 libjpeg.so.9.0.0

[16:16:20] <aclark> deepy: no i mean the headers (.h, etc)

[16:21:12] <deepy> that'd be graphics/jpeg

[16:25:24] <aclark> deepy: what's the path to the headers? /usr/pkg/include? JPEG_ROOT should be /usr/pkg then i guess

[16:25:56] <deepy> headers are in /usr/pkg/include/, JPEG_ROOT set to /usr/pkg, no result

[16:27:09] <deepy> interestingly enough, I seem to have lost tiff support along the way

[16:27:58] <wiredfool> morning

[16:28:37] <aclark> wiredfool: o/

[16:29:15] <aclark> deepy: no idea if JPEG_ROOT actually does anything ;-) you may need to just stuff those dirs in setup.py (assuming we don't support them already)

[16:29:33] <deepy> Whereabouts should I stuff them?

[16:30:03] <deepy> ooh, I start to remember now

[16:30:07] <aclark> deepy: look for other sys.path mangling to add lib and include dirs

[16:30:23] <wiredfool> there's a method build_extensions

[16:30:32] <wiredfool> with lots of sys.platform bits

[16:30:35] <aclark> deepy: and send a pull request to include /usr/pkg/include, /usr/pkg/lib when you are done :-)

[16:30:49] <deepy> will do

[16:30:51] <aclark> yeah it's terrible, but the status quo

[16:33:26] <deepy> three lines added, everything except for one thing shows up now

[16:33:57] <wiredfool> aclark: what do you think of #394

[16:34:01] <deepy> Can't remember why I needed Pillow in the first place anylonger

[16:34:23] <wiredfool> deepy: it'll come back to you

[16:36:40] <aclark> wiredfool: are you worried that it's not harmless?

[16:37:44] <wiredfool> aclark: yeah. the command is basically passed straight through to os.system

[16:41:20] <wiredfool> I'm not sure what security guarantees we're actually following, cause someone who can write/insert python code can monkey patch something in.

[16:41:44] <wiredfool> but something that takes an arbitrary string and executes it seems that much worse.

[16:48:12] <aclark> wiredfool: if that's what it does then yes I'd probably not merge that PR and fix the other places we are doing that

[16:48:31] <wiredfool> The other places we're passing through a filename.

[16:48:51] <wiredfool> I haven't checked to see if it's enforced that we've generated it with something like tempnam

[16:49:26] <wiredfool> I'm thinking of going through the other two places we do os.system calls and making sure that they're safe or removing them.

[16:51:11] <aclark> wiredfool: +1, sounds like a hack waiting to happen

[16:52:11] <wiredfool> I think for pr 394, adding the bits that make it easier to specify a command are good, but require that anyone writing the command do the class and the registration, like we do with image plugins

[16:54:05] <aclark> ok