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