=== almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [06:04] good morning === Zhenech_ is now known as Zhenech === ubott2 is now known as ubottu === hrww is now known as hrw === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === NCommander is now known as Guest93709 === Lutin is now known as Guest6753 === yofel_ is now known as yofel === Quintasan_ is now known as Quintasan === al-maisan is now known as almaisan-away === ara is now known as Guest50889 === almaisan-away is now known as al-maisan === jbernard_ is now known as jbernard === arand_ is now known as arand === tgm4883` is now known as tgm4883 === azeem_ is now known as azeem === al-maisan is now known as almaisan-away === s1aden is now known as sladen === soren_ is now known as soren [16:34] ScottK: any opinions what to do with the numpy multiarch issue for oneiric? bug 818867, ugly patch in linked debian bug [16:34] Launchpad bug 818867 in python-numpy (Ubuntu) "numpy.distutils provides inaccurate system information for ubuntu-11.10" [Undecided,Confirmed] https://launchpad.net/bugs/818867 === tikohumsup is now known as Rajsun === jtaylor_ is now known as jtaylor [19:07] jtaylor: I can apt-get install python-enable in a clean chroot with no issue, so I don't think the bug is correct. [19:08] enable was fixed [19:08] OK. [19:08] the issue is numpy [19:09] btw you told me to ahve a look at that, besides what is in the debian bug I have no more input [19:09] no idea what plans there are to upstream multiarch stuff [19:11] My opinion then is we should do what I always do with multiarch stuff. [19:12] I pass the buck to slangasek. [19:12] slangasek: Thoughts on http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=numpy-multiarch.patch;att=1;bug=640940 [19:16] btw installing was never an issue, its just about compiling stuff using numpy.distutils [19:17] heh [19:18] * slangasek makes himself scarce and lets the remaining multiarch problems fix themselves ;p [19:19] well, that's not upstreamable of course [19:19] wasn't there a more-upstreamable multiarch search rule being pushed upstream for python itself? [19:20] http://bugs.python.org/issue12418 -ish? [19:21] ultimately, we need a non-Debian-specific runtime interface for querying the path, but we're not there yet [19:21] (config.multiarch or some such) [19:25] slangasek: think you could ACK my recent upload of pitos to oneiric? [19:25] so are there any objections to adding that non-upstreamable patch to numpy for oneiric? [19:25] *pithos [19:26] it doesn't break many package (non which havent been fixed via workaroudns to my knowledge) but who knows what user programs it breaks [19:26] jtaylor: uh... "it doesn't break many packages" is not the right standard for an upload during final freeze [19:26] lfaraone: looking [19:27] * lfaraone is afk, airplane. [19:28] hm yes probably a bit late [19:28] hopefully we'll have a proper fix for P [19:29] lfaraone: I guess support for proto 31 may be dropped some time during the o support cycle, then? [19:32] oh, I see v31 is already dropped - right then :) [19:39] slangasek: How about 0 day SRU for the numpy thing. Then we have an easy backwards path if there are issues? [19:40] ScottK: that sounds saner to me. what's the actual bug being fixed? The patch doesn't enlighten me as to why it's needed [19:40] The bug is numpy can't find the X11 libs. [19:40] Which is a side effect of the bigger issue that it thinks it's required to care. [19:41] but then adding this change breaks other packages? [19:42] it should only fix them [19:42] its adding an extra library search directory [19:42] can that be an issue if there is a possible library in both? [19:42] gcc will ust pick the first in the list or? === yofel_ is now known as yofel