[06:45] <dholbach> good morning
[13:06] <ScottK> jtaylor: Any thoughts on the pytables FTBFS on powerpc from your sync?
[17:00] <jtaylor> hm
[17:00] <jtaylor> aren't ftbfs mails sent anymore from syncs?
[17:00] <jtaylor> I don't know how I could have overlooked that :O
[17:01] <jtaylor> yesterday I looked at pytables (only in pts) and thought hm I forgot to sync 2.4, oh well to late now ...
[17:01] <Laney> they never have been for API syncs
[17:01] <Laney> can't remember if they were for old style ones
[17:03] <jtaylor> hm how did it work in debian
[17:04] <jtaylor> probably numpy
[17:16] <jtaylor> looks like a straightforward fix, they just expect native types to not have the endian prefix, apparently that changed in 1.7
[17:16] <jtaylor> I guess its still fine to upload that to raring? or remove 2.4?
[17:30] <ScottK> jtaylor: Looks like cjwatson fixed it.
[17:32] <jtaylor> oh good
[17:32] <jtaylor> emulated ppc is so slow .-.
[17:33] <jtaylor> we really need some stuck in proposed notification system
[17:34] <jtaylor> I usually check if my stuff goes through, but such mistakes can easily happen
[17:34] <jtaylor> I guess the ppc queue was long or it took ages to build so I went to bed and forgot about it
[17:34] <jtaylor> (maybe also relying on a ftbfs mail)
[17:35] <ScottK> For syncs I usually open a browser tab for them and leave it until it's fully built.
[17:38] <cjwatson> My fix is a bit crappy but it will do
[17:38] <cjwatson> For now anyway
[17:38] <cjwatson> Feel free to supersede with something better in S :)
[17:39] <jtaylor> its the same I would have done :)
[17:39] <jtaylor> I'll check with upstream
[17:41] <jtaylor> cjwatson: thx for fixing it
[17:55] <ScottK> menesis: Shouldn't your schooltool-book versioin be 2.4.0-0ubuntu1?
[17:56] <menesis> ScottK: no, it is a native package
[17:59] <ScottK> Hmmm.
[18:00] <ScottK> OK.  I see the current package is native too.
[18:00] <ScottK> I'd suggest that's probably not the best way to do it for the future, but OK for now.
[18:02] <menesis> probably.
[18:02] <menesis> It is a new package in raring.
[18:05] <ScottK> I accepted it.
[18:08] <menesis> ScottK: thank you
[18:21] <jtaylor> cjwatson: your tcltk upload will fix all the remaining tcltk build failures?
[18:21] <jtaylor> will that be reverted post raring?
[18:22] <jtaylor> s/all/all that use tclConfig.sh/
[18:22] <crimsun> it should take care of the tclConfig.sh subset...yeah.
[18:23] <crimsun> i've encountered a couple outliers that do inane things with separate Tcl files; don't think there's a good way to get those
[18:24] <jtaylor> fixed one of these yesterday
[18:25] <jtaylor> uses tclConfig.sh but then for some reason still looks for all headers and files and needs the directory its actually in
[18:39] <cjwatson> jtaylor: I don't see any immediate reason to revert it; it would make the transition easier in Debian, which is generally a good thing, and helps with third-party sources using Tcl/Tk
[18:39] <cjwatson> Its only real downside is that it creates a dependency on dpkg-dev
[18:39] <jtaylor> why was it done in the firstplace then?
[18:40] <cjwatson> YM wasn't?  Well, it kind of seemed like a dirty hack, but meh, not worth the breakage
[18:40] <jtaylor> YM?
[18:41]  * crimsun grumbles about CMake module silliness
[18:42] <jtaylor> cjwatson: you could use gcc -print-multiarch and use gcc as dependency instead, might make more sense
[18:44] <cjwatson> "YM" -> you mean
[18:44] <cjwatson> is gcc -print-multiarch reliably identical?
[18:44] <cjwatson> on all architectures?
[18:44] <jtaylor> I used dpkg-dev in numpy, then quite quickly got a bug from someone who had gcc but not dpkg-dev
[18:45] <cjwatson> if so I agree and would be happy to do that for raring
[18:45] <jtaylor> its a ubuntu only patch so far I know
[18:45] <cjwatson> er, for S
[18:45] <jtaylor> so it should work everywhere
[18:45] <jtaylor> you have to ask doko
[18:45] <cjwatson> I think dpkg-dev from {tcl,tk}*-dev isn't a major problem though
[18:45] <cjwatson> I'd have worried more if they hadn't been *-dev packages