=== yofel_ is now known as yofel [11:41] hi AuroraBorealis. [11:42] sup [11:43] if you've got some time, can you try some debug things on meliae? [11:43] sure! [11:44] okay, what's your current diff on the meliae install? [11:44] I want to go back and work out why the IO wasn't functioning without the hack first. [11:45] that might be difficult cause i downloaded the tarball [11:45] any suggestion on how to do it? o.o [11:47] can i somehow diff it against the original tarball? [11:48] hm. [11:49] maybe step one should be working out why your setup is borked so you can't branch lp projects then. [11:49] i think i can do that now [11:50] its just that one day launchpad was being iffy [11:50] okay, branch a fresh lp:meliae and delete the currently installed one from Python27\Lib\site-packages\meliae [11:51] I've got the hacks here anyway so we can re-apply them as needed :) [11:52] k did that [11:54] okay, run setup.py on that, then the testsuite bit we got to crash and see if that's still happening. [11:56] what was the command to build the test suite again? [11:59] http://irclogs.ubuntu.com/2011/10/02/%23bzr.html#t11:57 [12:00] there's actually a script to run the tests I realised after, but what we did before works too. [12:01] yeah crashes python still [12:02] okay, great. [12:03] well, not great, but you get the idea. [12:03] yes! [12:07] okay, instructions: [12:07] ....I should have wrapped some lines [12:07] ask if anything doesn't make sense [12:08] k [12:08] otherwise, paste me things as you go [12:09] where is python.dll? [12:11] possibly in C:\Windows\system32\python27.dll but adapt for win64 [12:11] something like process explorer will tell you exactly which dll files get loaded if you run python the import meliae.scanner [12:11] yeah its in SysWOW64 [12:12] if that has different C runtimes loaded it's a sign something's gone wrong [12:13] ^*then import [12:13] hmm [12:13] "link.exe: the program can't start becamse mspdb80.dll is missing" [12:14] let me google this... [12:15] you probably need to run your vcvars bat file first [12:17] though the fact that says 80 not 90 makes me worry. [12:17] well [12:17] that was with the 9.0 sdk [12:18] ok that worked [12:18] I have Microsoft Visual Studio 8\Common7\IDE\mspdb80.dll - which isn't the right VS version for Python 2.7 [12:18] with running 9.0's vcvarsall [12:18] cool. [12:19] wait, I also have it in Microsoft Visual Studio 9, no worries. [12:19] python's dumpbin [12:19] http://paste.ubuntu.com/704851/ [12:20] you need the /IMPORTS flag [12:20] dumpbin /IMPORTS python27.dll [12:27] scanner dump: http://paste.ubuntu.com/704853/ [12:27] pythondll: http://paste.ubuntu.com/704854/ [12:28] okay, you see our problem there? :) [12:29] compiling with 10 instead of 9? [12:29] yeah, _scanner is linked against a newer C runtime [12:30] really distutils shouldn't let that happen, but I'm guessing we can work around it easily enough [12:30] can i force a version? [12:30] cause the microsoft sdk installed both 9 and 10 [12:31] yup, just looking to see how. [12:31] so, running meliae `setup.py build_ext --help" gives a bunch of options [12:34] does build_ext actually put it in the sitelib folder? [12:36] by default it puts its output in a subfolder of ./build [12:36] then install moves the stuff to site-packages [12:36] so, start by deleting meliae from site packages again, and deleting the build folder under meliae [12:37] in fact, it may be worth clearing out all of site-packages and re-installing if every built extension has this problem [12:38] you can double-check by running dumpbin on other pyd files. [12:38] k, let me check.. [12:42] I wonder if the hacks we needed to get distutils to work in the first place were entirely correct [12:43] can you pastebin the contents of ..\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd maybe? [12:44] and run meliae `setup.py build_ext` and paste me the contents so we can see where it's linking the wrong thing [12:44] http://paste.ubuntu.com/704860/ thats setenv.cmd [12:46] okay yeah, that's referencing "Microsoft Visual Studio 10.0" [12:46] hmm [12:47] is there another .cmd as well? because that one isn't right. [12:49] would be annoying if it required actually installing an older SDK. [12:50] this is setup.py build_ext [12:50] let me look for another cmd [12:50] and that seems to be the only .cmd file in that folder [12:55] did i somehow make it use the 10 compiler? [12:55] well, [12:56] either that's just the wrong SDK version, and we need an older one [12:56] or we just need it to not set the paths to point at VS 10 [12:56] well i have a Microsoft Visual Studio 9.0 folder [12:57] yup, but running that SDK script makes distutils look at VS 10 instead, which it shoudln't [12:57] so, start by undoing the addition to vcvarsamd64.bat which added the call to that .cmd [12:58] we can then manually set the LIB, LIBPATH, and INCLUDE if needed [12:59] I suggest: [13:00] start a new cmd window, call that problematic cmd and do `echo %LIB%` and the same for LIBPATH and INCLUDE, and paste it [13:01] then we can copy that with corrections straight into a distutils conf file rather than messing the vcvarsamd64 at all. [13:02] i dont seem to have a lib, libpath or include env variable as it just prints out %libpath% or whatever [13:03] hm, maybe run vcvars pre-edit and try? [13:05] http://paste.ubuntu.com/704870/ [13:06] ran the vcvars in the 9.0 folder [13:09] hm, and if you then run the v7.1\Bin\SetEnv.cmd file? [13:12] with calling the vccars64.bat file (which calls SetEnv.cmd) http://paste.ubuntu.com/704876/ [13:12] okay. [13:13] so, if you have the 9.0 equivalent of those paths, we can just change the versions [13:13] eg C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\Lib\amd64 -> C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\Lib\amd64 [13:14] and we can set them in setup.cfg rather than editing bat files [13:14] there is a lib folder but no amd64 folder inside of it [13:15] meh, then this is our problem, and short of building python itself against 10.0 I'm not sure what the fix is. [13:15] why did installing visual studio install 64 bit of 10 but not 64 bit of 9 [13:16] this I don't know. [13:18] okay, I need to do some cooking, work out a way of getting the 64bit versions of the msvc9 runtimes, that would solve things. [13:19] yeah [13:19] i need to get to bed, i'll google around and see if i can get those [13:37] * AuroraAustralis reinstalls the windows 7 sdk [13:37] hoping for magic [13:46] the reinstall has defeated me [13:46] going to bed, night [16:56] is there anyone around with any experience getting bzr to work with Jenkins/Hudson for CI? I'm using the plugin they list but I'm getting errors when I try a build that says it can't find bzrlib [17:06] vila would be your man but he's not around currently. [17:11] wgz: thanks [18:29] Pilky: the plugin shells out to bzr [18:30] Pilky: so if its not working, your bzr isn't installed correctly (e.g. you've installed it to ~/bin but PYTHONPATH isn't export) or something like that [18:32] yeah, I had to mess around with the location as bzr is in /usr/local/bin on my machine as I used the Mac installer [18:32] I think I might have got it now though, just required some messing around with settings [19:53] 'morning === yofel_ is now known as yofel [19:53] hi jelmer [19:54] hi Noldorin [20:01] ...is it jelmer? [20:02] 'evening wgz :) [20:03] are you somewhere far away currently? :) [20:05] ah, heh [20:05] no, I'm at home [20:06] I'm used to saying 'morning around this time of day since thats when the Ozzies and Kiwis show up :) [20:12] In my mind, it's always morning... [21:25] jelmer: did you get anything exciting back from PQM? [21:25] see the comment at the end of [21:26] Ubuntu bug 78601 in Ubuntu "[Sync] marble (NEW) from Debian experimental" [Undecided,Fix released] [21:26] * wgz bops ubot5 on the head === AuroraBorealis is now known as aurora|away