[00:00] whoops wrong button [00:00] i'm not used to using trillian for irc [00:05] also, is the person that made the bzr-tfs plugin here? [00:06] FryGuy_: I don't think John is here at the moment [00:07] okay, it's just past midnight, and I have an installer built [00:07] the actual fix will now take me, I think, five minutes. [00:09] mgz: Wow. I tried for days, and did not succeed. Well done. [00:09] well done! [00:10] I chopped nearly everything out of it, so it's a sort-of cheat [00:11] hm, and hook_debugger_to_signal is borked, but otherwise it seems to be working [00:13] mgz, you're talking about trying to get a 2.3 win32 installer? [00:13] or one that works on windows 7? [00:13] I'm trying to fix the manifest thing, as it *does* apparently break the installer for people [00:14] I'm just leaving a trail of smooth yaks behind me [00:14] :) [00:18] okay, weirdness to work out later... signal.signal is raising "ValueError: invalid signal value" with signal.SIGBREAK [00:18] but otherwise that installer works, but links the wrong dll [00:18] now, to do the change, and confirm it then links the right one [00:23] new installer built... [00:25] whoops, forgot one bit. [00:36] okay, works. [01:26] tooo late, bed bed bed. [01:59] night mgz [02:00] sadly I am not yet in fact in bed, I have just fixed the python trunk bug that was breaking hook_debugger_to_signal though, just need to post it [02:26] Hopefully that will really fix bug 596239 [02:26] Launchpad bug 596239 in Bazaar "Bazaar supports https! Update documentation (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/596239 [02:27] At least while we still can't have Sphinx features. [02:28] Where do ghost revisions come from? Uncommits? [02:28] jbowtie: developers of christmas past [02:29] bzr-svn, afaik, only [02:29] jbowtie: I had the same question when I was reading that code. [02:29] jbowtie: But I don't remember the answer. [02:30] A ghost is when you know a revision was merged, but you don't know anything else about the merged revision besides its id [02:30] It's just one of those things mentioned in the docs, but never defined. [02:31] So we should either remove it from the docs, or explain what they are and why we care about them. [02:32] If they're not really visible outside the code I'd vote for removing mentions of it. [02:32] * jbowtie is looking at bug 405452 [02:32] Launchpad bug 405452 in Bazaar "document the term "ghost" (affected: 1, heat: 0)" [Medium,Confirmed] https://launchpad.net/bugs/405452 [02:32] i think they should be perhaps in a faq or something similar [02:32] not normally something users should need to know about but the term might come up and then it's useful if there's a definition [02:33] I was thinking of adding a glossary to the user guide. [02:33] other than that i'd agree with removing confusing references [02:33] that would be great [02:34] Yes, it would, but I'm not doing it until we switch to Sphinx so I can use glossary and term directives. [02:35] Which in practice means until PQM gets updated. [02:44] Noticed on python-diversity people asking about female-friendly FLOSS projects, do we have any women on the core team? [02:46] i don't think so [02:46] poolie: Maybe you should point that out to HR when they send over the next stack of CVs. [02:47] oh, my [02:47] what would you like HR to do with that information? [02:47] Maybe we should explicitly reach out? I can put the word out on python-diversity and geekfeminism if we have some bandwidth to mentor new people. [02:48] there are female committers on other canonical-related projects, including launchpad [02:48] i hope they find it a good place to work [02:48] or good projects to work on, as appropriate [02:49] we have at least one female applicant for the currently-open bzr job [02:49] suggesting we should positively tilt things towards them is a difficult topic [02:49] That's great. [02:50] No, I just want to make sure we're not accidentally doing things that discourage women. :) [02:50] i would be very happy to see more technical women here [02:50] and, right, if we are doing anything that discourages them either applying or working here, that's a serious bug and we should fix it [02:51] i'm probably not best qualified to know if that's true [02:51] So if you mention to HR maybe they could shake the resume tree a little harder. [02:52] I only think of it because where I work now we have had no female applicants to the IT team for 5 years. [02:52] well, [02:52] And I'm pretty sure it's cultural or unconscious bias on the part of management. [02:53] we're working on a project to better expose and propagate the job openings we do have [02:53] jbowtie: canonical recruits pretty heavily from open source communities, and women are even less well represented there than in the it industry as a whole [02:53] why that is is an interesting topic, but perhaps not one for this channel :) [02:54] from my perspective as an outsider, the bzr dev is handled professionally; i can't see anything that would be particularly offputting for women, or anyone [02:54] i think we have pretty good diversity on other axes [02:54] race, religion, sexuality, veterans, disablity [02:54] So if I go back to python-diversity and say we're a female-friendly project, y'all are not going to make a liar out of me? :) [02:55] :) i hope not [02:55] i would be delighted if it's true [02:55] and if there are bugs, i would like to see them pointed out and fixed [02:55] you could ask maritza and emmajane how they found it [02:56] or ursinha in #launchpad [02:57] i guess you know our ceo is a woman, but perhaps that's a different situation to being directly in a technical team [02:57] Thanks, I will do. [02:58] Yes, it's a little different. But I know the Ubuntu community as a whole is pretty progressive compared to open source generally. [03:13] I think most FOSS projects are pretty friendly toward people of any sort. [03:13] I've never encountered one where there was any sort of prejudice, except perhaps against Windows users. :-) [03:14] hi every1 :) [03:14] mkanat: not to say anything against the bzr community, but if you think you've never encountered any prejudice, then probably that's a failure of observation. [03:15] exarkun: No, I don't think so. I probably just haven't worked with projects where there is any sort of gender or racial bias. [03:15] exarkun: Most of the male FOSS developers that I know bemoan the fact that it's such a male-dominated profession. [03:16] The only thing that I can't explain about software development is why ANY human being would want to spend 10 hours a day in front of a computer, except for the fact that I do it. :-) [03:17] * exarkun shrugs [03:17] as you like [03:17] exarkun: Prejudice about what? [03:18] I mean, a project member would of course be a little biased for their project. [03:18] jeremyw: Sure, *technical* prejudice, I see all the time. :-) [03:18] But, truth be told, I'm a Subversion committer and I have no bias toward it. It's great for some things but I don't use it much these days. [03:18] well, there are some projects that have a more, say, aggressive or confrontational style [03:18] That's practically the whole driving force behind the software industry--technical prejudice. :-D [03:18] Like the Git folks. ;) [03:18] poolie: Ah, yeah, that's true. [03:18] you said it not me :) [03:18] lol [03:19] * mkanat can think of a few other projects of a similar stripe. [03:19] but, that is sometimes said to be offputting to female contributors [03:19] The Git people are like little mini Linuses. If it ain't Git, it sucks and should be wiped off the record. [03:19] poolie: Sure, I can imagine that. It's offputting to me, too. [03:19] svn went very far in the other direction to be friendly, was my impression [03:19] You get my drift. I happen to be open to whatever works. [03:19] peitschie: hi, there, thanks for your summary mail [03:19] poolie: Subversion people are very nice if you ask me. I spend a lot of time in #svn answering a lot of help. I'm nice. ;) [03:20] well the svn guys _did_ do a whole google talk on how to deal with people messing up your project's community :) [03:20] poolie: Yeah, my experience is that unless somebody around is putting a specific effort into making a community friendly, then it tends to devolve into unpleasantness. [03:20] i don't have any particular renspose other than that we should/will fix those bugs [03:20] it's interesting that i'd say most of them, like the ghosts things, do come from bzr-svn [03:20] dash: Well, the idea was more geared towards project governance. ;) [03:20] which is a great feature, but also kind of inherently more difficult [03:20] mm [03:20] i agree [03:20] poolie: i definitely wasn't expecting much more :). I know a lot of them are being worked on.. just hoped the overall experience story might be interesting :) [03:21] i think the biggest problems we've had are in code reviews and that's probably now a positive overall [03:21] but again of course i may be biased [03:21] poolie: Yeah, we had that problem as well, with code reviews. [03:21] poolie: Because their purpose is to criticize. [03:21] I've pretty much learned that the VCS I used is more geared toward what my employer uses or what the open source project I'm contributing to uses. Sure, I have my personal preference for private stuff but... [03:21] see also jml's talk "your code sucks and i hate you" [03:21] poolie: lol [03:22] haha [03:22] poolie: That's an excellent talk name. [03:22] jeremyw: Same here, although I have a strange tendency to cause projects to switch to bzr. :-) [03:22] i was saying to robert the other day i think the point of code reviews is to improve the people and the relationship and only secondarily the code [03:22] poolie: I like that view, because ultimately it's the people who write the code. [03:22] hopefully to make them more knowledgeable, also more excited, and to know of easier ways to do things next time [03:22] poolie: the bzr-svn stuff is also a little disappointing because i've been noticing the latest releases really starting to shine. I kinda feel like I was a little early with letting this into the company unfortunately :( [03:23] also, the amoutn of code under review at any time is probably a small fraction of the total that person will ever write [03:24] poolie: Yeah, that's a good point. [03:24] poolie: That's kind of in line with the community research I did on the Bugzilla Project, that I wrote up here: http://groups.google.com/group/mozilla.dev.apps.bugzilla/browse_thread/thread/520f5aa32917a517/bb7c1a42bcc400d9 [03:25] wow, that's good [03:25] mkanat: thats a very interesting writeup :) [03:25] poolie: Thanks! [03:25] peitschie: Thanks! :-) [03:26] i strongly agree about freezes [03:26] poolie: Yeah, and that one had unarguable corroborating data. [03:26] poolie: You can draw a vertical line on the graph of the number of contributors at the freeze dates and see the graph crash from there. [03:28] Hmm... grep shows ghosts only being mentioned in the developer documentation, so I'm off to the next bug. [03:29] mkanat: Yes, that is a great writeup. [03:29] jbowtie: Thank you! [04:01] doing a first time contrib, so just wanting to make sure I'm doing it right [04:01] do I simply commit to my local branch, then push to bzr.dev? [04:02] ah, oop, looking at the docs... I push to my branch on launchpad, then send a merge request [04:04] is that right? [04:05] dmuir: i'm going through the process myself for the first time, and that sounds like what i did [04:06] now I just need to figure out how to push to launchpad.... :-) [04:07] it was in one of the docs -- there's an example of how to tweak bazaar.conf to make it fairly easy [04:08] I'm looking at the contribution-quickstart article which suggests putting some stuff in locations.conf [04:08] which i'm trying now [04:13] branching is fine but setting things up so changes _must_ stall is poor [04:15] dmuir: Generally I use bzr push lp:~jbowtie/bzr/branch-name (of course substitute your own launchpad id) [04:15] dmuir: Followed by bzr lp-propose-merge [04:16] ah, that's what I was looking for, the docs say to use `bzr propose-merge`, which I guess is wrong. [04:21] hmm, bzr crashed [04:21] bzr: ERROR: lazr.restfulclient.errors.HTTPError: HTTP Error 401: Unauthorized [04:22] odd, since I logged in fine [04:22] you can propose a merge using launchpad [04:24] I think I got it working now [04:27] dmuir: Thanks for pointing out the bug in the docs, I've proposed a merge to fix it. [04:28] thanks, was about to do it myself after submitting my current proposal [04:30] seems that I got it all working. bzr got all confused because launchpad didn't take me to the screen to authorise access from bzr. When I tried a second time it worked. But then it got all confused about the merge description. [04:31] so I updated that... except maybe it should have been the commit message? [04:35] dmuir: are you ok now? [04:36] just wondering if I should update the commit message? I set a description, but then noticed after that there's no commit message. [04:36] you can set both [04:36] ok [04:36] the commit message will go into the history, and the description can have more text just for the reviewers [04:37] ah, ok [04:38] done [04:39] yay, my first contribution to bzr! [04:39] :) [04:39] minor doc fix, but figured I'd start small :-) [04:42] so if I fix more things, do I push them to the same branch and create a new proposal? Or do I put that into a new branch, and propose that instead? [04:43] if they're related and should land together, put them in the same branch and just push [04:43] if you're doing a series of small doc fixes, put them togethr [04:43] if you're going to also fix a bug, i'd do it separately [04:43] I normally do a branch for each bug personally. [04:44] Which reminds me, I can't figure out how to use bzr-colo. [04:44] ok, thanks! [04:45] I got the idea it's good for managing lots of little branches like my workflow creates, but I can't figure out how to get started with it. [04:48] jbowtie: so what i did is [04:48] bzr colo-init ~/bzr/work [04:48] (i'm going to use that as my colo workspace) [04:48] cd ~/bzr/work [04:48] now it'll be on trunk by default, and have an empty repo [04:48] so then [04:48] bzr pull lp:bzr [04:48] now to start something else [04:49] bzr colo-branch 189757-stacking [04:49] and then you have the same tree, on that new branche [05:27] poolie: got a minute? [05:30] thumper: hi [05:31] poolie: skype? [05:33] ok, give me a sec [07:23] hi all ! [07:29] * fullermd quickly hands vila a parrot, a half gallon of milk, and 3 bags of sand, tells him to look natural, and runs the other way. [07:29] for bug 335577, I'm thinking of parsing the text of the global options text (effectively bzrlib.help_topics._global_options, but obtained via method call). The idea is to look for lines starting with "--" and treat those as options, an insert the appropriate magic-man-macros. Does that seem OK? Alternatively I could just create the man text from that text by hand. [07:29] Launchpad bug 335577 in Bazaar "bzr global options should be added to man page (affected: 0, heat: 5)" [Low,Confirmed] https://launchpad.net/bugs/335577 [07:31] hi there vila [07:32] wow, the early comments on that bug are pretty weird [07:32] and the last one is *cough* wrong [07:32] fullermd: not sure about what I should reply there.... What's up doc ? [07:33] roryy: so they want to be examined in tools/generate_man_page, i think it's called [07:34] i've ended up in doc_generate.autodoc_man [07:34] roryy: it would be a good start to just make sure the global options help topic appears as a heading in the man page [07:34] that sounds right [07:34] that's not quite idiomatic but it'd be close [07:34] mkanat: wow, there are gems in this mail, you should turn it into a blog [07:34] vila: I dunno. I just started typing... [07:35] you know as a followon it could be good to generate separate bzr-$command man pages [07:35] fullermd: ha, ok, I wasn't sure, I appreciate the intent ;) [07:35] nah, intent much appreciated sounds more like it [07:35] poolie: i.e., just a static section 'GLOBAL OPTIONS See "bzr help global-options" ' ? [07:36] well, ideally wit would have the actual text of it there [07:36] i've kind of gotten that [07:36] but the man formatting looks horrible [07:36] hence the parsing [07:37] or i could manually put in the man macros, which would be dead easy [07:38] ah, i see [07:39] hm [07:39] it would be better not to have to manually maintain the manpage [07:41] morning all. [07:41] ok, i'll have a bash at generating the man source from that text. shouldn't be hard [07:41] can't you assign a man to manually manage the manpage? [07:41] roryy: i think really it would be cleaner to generate it from the option objects [07:41] mgz :) [07:41] Man, you gotta be joking. [07:41] in both cases [07:42] poolie: fair enough [07:42] i guess you'd need to somehow mesh it with the explanatory text [07:42] i don't think we need to point to the profiling options here [07:42] that kind of belongs in developer docs [07:44] if i read commands.py correctly, '--no-plugins' is checked in run_bzr() -- i'm not following what an option object is [07:44] poolie, as you marked roryy's mp approved you think it's good to go? will go ahead and land that and andrej's changes now if so. [07:44] mgz: wow already up ! You did manage to build an installer finally ? [07:44] mgz is that the meliae one? [07:45] I built enough of it to write the fix. [07:45] poolie, no, the --show-base one [07:45] mgz: I *am* very interested tracking changes you had to do to get there, I hope you will submit some mps soon while it's fresh... [07:45] roryy: hm, some of them, including no-plugins, are handled a bit specially [07:45] *interested in [07:46] ok, i'll change that advice to say it would be nice to turn them into objects then format the objects for both cases [07:46] heh [07:46] ok [07:46] however if you want to just quote the text so that it formats properly, i think that would be a step forward [07:46] poolie: Do we have graphs of downloads somewhere and do we have them for ppas too ? [07:49] i don't think so [07:51] mgz, re --show-base, it's not the ideal implementation but i think it's reasonable [07:52] hm, yeah, you mentioned a config thing, have we got a bug on what you were intending? [07:52] not sure [07:53] * poolie looks [07:53] what i had in mind is that if there was a per-process configuration, [07:53] higher level things could map --show-base into setting merge.show_base = True [07:53] for the duration of the command [07:53] that would avoid the proliferation of things being passed down [07:53] it would also let people set it permanently if they wanted [07:55] bzrlib.merge.show_base could be a config option whose value can be overridden from the command line [07:57] exactly [07:58] * vila rejoices :) [07:59] that setting of that option (bzrlib.merge.show_base) would still be set in the appropriate commands? (pull, merge, update) ? [07:59] and no spurious failure on babune today ! [07:59] also, would it become --show-base=yes|no if it's an overrideable config option? [08:00] by the way, maverick is back as a regular slave with a single failure, guess which one... [08:00] bzrlib.tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh [08:01] paramiko thing? [08:03] mgz: yup [08:03] I asked spiv for a maverick version of its package that I use on lucid [08:05] why spiv? [08:05] because he did: https://edge.launchpad.net/~spiv/+archive/packaging-test [08:05] and I use this ppa for the babune lucid slave [08:06] the problem wasn't apparent before because the maverick slave was using python2.7 and paramiko wasn't packaged at all [08:07] but since I switch back to 2.6 to debug the ca.crt thing, I left it at 2.6 [08:14] Hi all. [08:16] morning Gary. [08:16] I put up an installers mp that should sort out the manifest thing. === ddaa1 is now known as ddaa [08:22] mgz: Cool. would you like me to build a full installer with it. [08:23] We probably want to before 2.2.2 but don't rush. [08:23] ok [08:30] poolie: you really want to separate show-config and set-config ? I thought bzr config name=value was more... natural ? [08:31] poolie: it's true that at the implementation level this would be almost completely separated though (with a bit of overlap nevertheless since setting applies to a subset of what is shown) === spike_ is now known as spikeWRK [10:26] What's the equivalent of "hg out", i.e. a dry-run push? [10:26] bzr missing --mine-only ? [10:29] Argh, the server's behind a bloody pptp server, so I have to bounce back into a ppp-enabled kernel to try it :-/ [10:38] vila: Thanks!! [10:38] vila: I was actually just thinking about making it into a blog. [10:38] mkanat: :) [10:39] I believe in many of the points you raised, it's nice to see you backed them with data [11:01] bzr missing was the Right Thing. [11:02] Unfortunately there are merge conflicts with upstream, and my patch is trivial, and I don't feel like learning how to resolve conflicts in bzr at 8PM on a Friday, so I'm just going to bzr log -c | ssh foo patch, resolve the conflict by hand, then commit it as a fresh change [11:26] mgz: I tried to build with your patch. I got this error again: "*** finding dlls needed *** \n error: MSVCP90.dll: No such file or directory" [11:28] vila: Thanks. :-) [11:30] mgz: last time I got that error, I copied msvc*.dll to some where py2exe could find it. The build host has been rolled back, so this is no longer in place. [11:31] I could do that again, but it did not feel right. [11:32] I was hopping your patch would fix this with needing to copy the dll's [11:32] mgz: what do you recommend I do? [11:34] * GaryvdM reads the py2exe doc again [11:38] GaryvdM: okay, that wasn't what I was trying to fix so it's not suprising it's still happening [11:38] if you copied the dlls last time to make it work, do it again [11:39] but tell me where you're copying them to, and I'll look at fixing that as well [11:40] ok - I see you used self.msvc_redist_dir, and I'm just looking where that comes from. [11:41] what I changed is all post-py2exe, it's a different issue [11:41] oh [11:42] https://lists.ubuntu.com/archives/bazaar/2010q3/070252.html <- what that branch is aimed at [11:43] hello, I've been trying to use bzr-pqm in an recently updated maverick machine and I get the following error: http://paste.ubuntu.com/503808/ [11:44] something that breaks then installer for users, not the process of building the installer [11:44] mandel: that's actually (mostly) harmless, but is fixed in the upcoming 2.3 [11:44] mgz: ok - I'm with you [11:45] mgz, ok, sweet, I was talking with the canonical losas and we had no bloody clue about that, I'll update our wiki so that people know about it [11:45] mgz, thx a lot! [11:45] I'll give you a bug number ina sec [11:45] mgz that would be superb! [11:45] ...I think Andrew filed a bug rather than just putting up an mp [11:46] * mgz goes for qlog rather than launchpad bug search anyway just in case [11:48] bug 633745 is what I was thinking of, but I'm not completely sure that's the right thing [11:48] Launchpad bug 633745 in Bazaar 2.2 "bzr+ssh to pre-1.6 server fails with AttributeError: 'NoneType' object has no attribute 'close' in close_ssh_proc (affected: 1, heat: 11)" [Critical,Fix released] https://launchpad.net/bugs/633745 [11:50] mgz, does look like the same one.. I'll just update the wiki so that is someone finds the issue does not have to worry about it, thx a lot for the help! [11:52] if it is that, 2.2.1 will fix it, file a bug if it doesn't. [12:06] mgz: Ah, we have a dll exclude for MSVCP60.dll, but not for MSVCP90.dll - Maybe we should add that? [12:07] in setup.exe line 691 [12:07] if that turns out to help, go for it, but I think we played around with this a week ago and didn't get that far [12:08] it doesn't really matter if we end up copying it in the script to make py2exe happy because we can seperately just not ship it [12:08] mgz: ok [12:38] mgz: https://dl.dropbox.com/u/4494367/bzr-2.2.1-setup-manifest.exe [12:39] getting, thanks Gary. [12:40] I've not tested myself yet. [12:41] it's a bit of a pain to do unless you have a clean vm somewhere [12:46] ah, uh, er... was just about to declare victory, but everything qt is broken [12:47] mgz: that may not be due to your patch [12:48] I'm going to try copying the cpp runtime library in to see if it's that [12:48] I had to reinstall pyqt oh build the host :-/ [12:48] *on [12:48] nope. [12:56] meh, pants [12:57] it the cpp runtime, wonder what the best way to fix this is [12:57] the only thing it's actually in there for: [12:57] MSVCP90.dll [12:57] BE4 ?uncaught_exception@std@@YA_NXZ [12:59] also, but unrelated, the crypto compiled bits seem to be missing [13:02] ...I'm failing to think of a non-ridiculous way of handling this [13:02] python26.dll has to be in the base dir, and needs the runtime next to it, qt dlls need to be in the lib dir, and have the runtime next to it [13:03] linking two different copies is asking for pain. [13:23] okay, that'd work. scrap the lib dir entirely and put *everything* in library.zip in the root folder [13:26] or install to SxS system dir [13:32] ah, or maybe just update the python? I'll read through all of but that's pretty much the issue. [13:40] nope, not relevent. [14:15] meh, what's the python equivalent for C __FILE__ __LINE__ ? [14:16] __file__ for __FILE__ but __LINE__ ? [14:16] i think __line__ works [14:16] Or you might just use the inspect module? [14:16] (in the callee) [14:17] Kinnison: :-) I am the callee, I want to know my line number [14:18] hmm [14:18] from inspect import currentframe [14:18] then use currentframe().f_lineno and currentframe().f_code.co_filename [14:18] ? [14:18] (untested) [14:20] Kinnison: works, thanks [14:21] * vila was stupid to try it under pdb just to get '1' as a result [14:21] note: probably not terribly efficient [14:21] if __file__ works, then use that instead of the latter [14:21] Kinnison: I did [14:22] :-) [14:22] efficiency is not a concern, it's to report an error to the user [14:22] http://code.activestate.com/recipes/145297-grabbing-the-current-line-number-easily/ [14:22] seems like inspect is the only way, __line__ would be too magic for python i guess :) [14:23] yeah, I think I was climbing the wrong tree, python is an interpreter not a preprocessor, doesn't really make sense to bind a symbol with that (unlike __file__) [14:24] Glenjamin: thanks for the additional bit of info (I will need f_back :-) [14:24] yoo [14:24] too [14:24] ha typos.... [15:16] mgz: I don't have any qt issues with that installer - on a fresh win 7 vm [15:17] everything just works [15:18] What error to you get? [15:18] *do [15:18] well, I don't think I've made anything worse, but I've probably not fixed anything [15:19] I suspect windows 7 (and possibly vista) has the vc9 runtime in a shared location anyway [15:20] I'll try reproduce in a xp vm, with an old installer [15:20] does your vm have %WINDIR%WinSxS\x86_Microsoft.VC90.CRT_? [15:20] * GaryvdM checks [15:21] I mean, the good news is this shouldn't really affect many people as various other bits of software will stick the dlls we need were they'll get found anyway, but I think this is kinda borked [15:22] I've just been looking at mercurial's new msi installer with some envy, the config is horrid but being native it handles these dumb windows 'innovations' [15:23] mgz: does have %WINDIR%WinSxS\x86_Microsoft.VC90.CRT [15:24] yeah, so that's good and bad. good in that for people with win7 bazaar will just work [15:24] mgz: You said qt stuff was broken? [15:24] bad in that we can't actually test to see if the installer's borked on that vm [15:25] yeah, basically everything in the subdir that /1) links a vc 9 runtime/ and /2) bundles a manifest/ is borked [15:25] * GaryvdM starts installing a xp vm... [15:25] including pywintypes (which doesn't actually matter as ctypes works) [15:26] anyway, this is where I'm happy I'm not a build engineer, at least with coding you create stuff rather than just trying to keep it unbroken [15:52] mgz: I think you're over-optimistic :) [15:52] mgz: your last sentence could be reversed and still holds true for some people :) [15:52] woot: http://www.youtube.com/watch?v=tMdE4GmFaDQ [15:54] Excremental Bazaar qlog selection behaviour. ^^^^ [15:54] what key's are you pressing there? [15:54] i was trying to figure out if it was a bug report or a feature demo [15:55] All mouse draging [15:55] oh [15:55] oh i see, it only selects items in the history of the first selection [15:55] Yes [15:57] excuse my poor english, but... excremental ? [15:58] ex == not in ? [15:58] experimental [15:58] thats my interpretation, i'm not convinced it's a real word [15:59] excremental actually means "pertaining to excrement" [15:59] weird freudian slip :) [15:59] I can't spell.. [16:01]