[01:14] is there a python import hook for importing from a bzr branch (with no working tree)? [01:16] exarkun: not that I'm aware of [01:16] that would be a cool (and fairly achievable, at least from the bzr side) thing to write though [01:19] nice [01:23] an equivalent thing would be a FUSE fs backed onto a branch i guess [01:25] mwhudson: or an x86 implementation in javascript on v8 running a linux installation preloaded with the contents of the branch as a normal part of an ext4 filesystem [01:25] mwhudson: or a Transport implementation on top of the Tree API [01:26] exarkun: that sounds modestly over complicated [01:26] jelmer: ... yes, i guess so [01:26] jelmer: that's quite a confusing thing to think about though :) [01:26] mwhudson: nested trees? >-) [01:27] How does bzr+ssh:// figure out which bzr executable to launch? [01:27] exarkun: it just runs bzr, or you can set the BZR_REMOTE_PATH environment variable [01:27] And what are the chances I'll be able to get it to run bzr with PyPy? [01:27] exarkun: in other words, it leaves it to the shell on the remote machine [01:28] exarkun: I think there are still some open issues running bzr with pypy, LarstiQ was looking into some today. [01:28] https://bugs.launchpad.net/bzr/+bugs?field.tag=pypy [01:30] argh, always so difficult [01:31] exarkun: I think it's mostly tests failing, not sure how much matters in practice [01:31] before I even get to any of those issues, I can't use the system installed version of bzr on pypy because sys.path doesn't work that way [01:31] and I really don't feel like installing bzr just for pypy either [01:32] what do you mean about sys.path? [01:33] "ImportError: No module named bzrlib" [01:35] ahhh, pointing PYTHONPATH directly into /usr/share/python-support/python-bzrlib works [01:35] implausible, but I'll take it [01:42] i wonder if it's something about pypy not reading pth files [01:42] does it work with that fixed? [01:42] I think pypy intentionally avoids using cpython's library, including site^Wdist-packages [01:44] it's pretty hard to tell what's going on [01:52] aha, think it's working [01:52] on top of a precious stack of ad hoc configuration :/ [01:52] oh well good enough [01:57] okay, just one more thing I'll try tonight... [01:58] what's a good way to restrict a plugin to running on only one branch? [01:58] hm [01:59] the normal thing is to just have an option in that plugin [01:59] .. there ought to be a builtin option though [02:00] what kind of option? like, something in ~/.bazaar/config? [02:00] there is no option for it now but there should be [02:00] well, perhaps in locations.conf [02:00] but, there is a bit of a bootstrapping problem, that plugins are loaded very early on [02:00] so that they can control how branches are opened [02:00] you could do it from some shell scripting outside of bzr [02:01] hm. I can't quite think of what that would look like. [02:03] if [ `pwd` == /home/me/foo ]; then; export BZR_DISABLE_PLUGINS=pqm ; fi; exec bzr "$@" [02:04] and the pwd is the branch being operated on? [02:05] no, it would be just your pwd [02:05] so it's not quite accurate [02:05] in the fairly common case where the branch comes from one of the args [02:05] what's the specific case? [02:06] I'm writing a server-side plugin that deploys an application whenever the server-side branch is pushed to [02:06] ok.. [02:06] and you want it only to do this for some branches? [02:07] passingly [02:07] as it happens, there's only one branch I've ever pushed to this machine before [02:07] if I ever decided to push some totally unrelated bzr branch to it for some reason, it'd be nice to not trigger the plugin [02:07] ok [02:08] so i think your plugin should just load unconditionally and install its hook [02:08] then when it gets the branch that has been changed, [02:09] if branch.get_config_stack().get('my_deploy_plugin.enabled'): do_it [02:09] then you can put that in the branch.conf, locations.conf, or globally [02:09] oh, fancy [02:09] that sounds just fine [02:09] thanks [02:10] you're welcome [02:12] something I noticed while doing this, the end of the bzr output is a little mixed up: [02:12] Pushed up to revision 62. [02:12] exarkun@top:~/Projects/treeplan$ bzr: warning: some compiled extensions could not be loaded; see [02:12] I know why the compiled extensions could not be loaded, but I don't know why I get warned about it after I've gotten my new shell prompt... [02:13] not sure [02:13] maybe ssh lack of synchronization between stderr/stdout [02:13] (lunch) [02:21] huh, http://codepad.org/VZ85gbDu [02:22] is it because some extentions arn't compiled? [02:22] AuroraBorealis: Seems unlikely. [02:23] exarkun: you have a bzr older than 2.4 - use branch.get_config().get_user_option("foo") [02:23] ah, ok [02:30] Cool, seems to be working well now [02:30] I notice some leftover files in /tmp [02:31] eg bzr-index-q3bQ3p [02:31] isnt that the point [02:31] its in /tmp, who cares? [02:31] starting with "B+Tree Graph Index 2" [02:31] AuroraBorealis: I care, when I run out of disk space in 6 months [02:32] i dont think bazaar is going to make you run out of disk space o.o [02:32] espeically if you restart anytime in between said period [02:32] exarkun: yeah, those should be cleaned up. I wonder what creates them [02:32] AuroraBorealis: it's common courtesy for applications to clean up files they no longer need, even in /tmp [02:32] yeah. at least you have /tmp, windows they stick around forreevverrrr [02:33] AuroraBorealis: if nothing deletes them they can stick around forever too in /tmp.. [02:33] doesn't it clear /tmp when you restart? [02:33] This machine had an uptime of 900+ days the last time it restarted [02:34] That's a long time for temp files to pile up [02:34] your kernel must BELONG IN A MUSEUM [02:34] [02:34] but yes i see your point [02:37] Anyway, I'm reasonably happy with this for now. Thanks for the help, everybody. In case you're curious, the plugin is http://bazaar.launchpad.net/~exarkun/+junk/treeplan/view/head:/generate_schedule.py [02:37] good night === bradm_ is now known as bradm [07:22] vila, jelmer, hi? [07:48] buongiorno a tutti ! [08:43] jelmer: ping, https://code.launchpad.net/~jelmer/bzr-pqm/2.5-compat/+merge/89367 reviewed, double check my proposed tweaks but I think the end result should be good to land (tests are passing here (before you ask, 'bzr plugins -v' double-checked ;)) [08:44] jelmer: and thanks for that, I discovered the issue recently and fixing it was up in my TODO list [08:56] ... [08:57] the release notes are clean, 2.5 already merged into trunk... isn't the world a beautiful place ? [09:00] how can i get 2.5 so i can test colocated branches? [09:01] oh durr wrong website [09:05] AuroraBorealis: you can download the latest beta from https://launchpad.net/bzr/+download, or bzr branch lp:bzr/2.5 if you want to track the work leading up to the final [09:08] kay. first thing i noticed about colocated branches, bzr switch doesn't work. get "cannot switch a branch, only a checkout" [09:12] morning all [09:13] hey mgz ! [09:13] mgz: windows installers ? [09:13] sure. [09:13] mgz: I said I'll announce today, would be nice if they were available :) [09:51] jelmer: in bzr trunk, BZR_DISABLE_PLUGINS=svn ./bzr selftest -s bzrlib.tests.test_http.SmartHTTPTunnellingTest.test_open_bzrdir pass but ./bzr selftest -s bzrlib.tests.test_http.SmartHTTPTunnellingTest.test_open_bzrdir fails [09:52] jelmer: I'm a bit lost :-/ [09:52] jelmer: this may be related to probers but I can't understand why [09:53] jelmer: fails with: AssertionError: is an instance of rather than [09:53] }}} [10:05] jelmer: hmm, could it be some pycurl internal state borking ? [10:14] jelmer: yup, found it, playing around with pycurl.CUSTOMREQUEST is the culprit, your svn prober seems to force "GET" which get in the way of the smart server trying to use POST [10:15] jelmer: pycurl is probably to blame here for providing two incompatible API (CUSTOMREQUEST vs HTTPGET/POST) [10:17] jelmer: I can hear you ask for bzr supporting OPTIONS you know ;) [10:45] jelmer: ok, I had a fix for bzr itself, but I've found a less risky one for bzr-svn instead: http://paste.ubuntu.com/810565/ [10:45] jelmer: there is also an unrelated fix in this paste for the config stuff that is taking dust in my local copy [10:45] jelmer: gotta go now bbl [11:34] ah. [11:34] svn-lib 1.6.6 [11:34] I suspect that's... not right any more. [11:34] * mgz gently kicks jelmer [11:35] Morning guys. What's the command to show the gui that shows who made what changes to a file? [11:36] `bzr qblame FILE` [11:37] found it, qannotate [11:37] that's the same as qblame? [11:39] that's the allenap milquetoast version of qblame [11:40] of course, real developers add a 'qwhosucksthemost' alias and use that [11:40] * jelmer kicks mgz back - what's up with 1.6.6 ? [11:41] is it the version I want? [11:41] mgz: possibly, it should be sufficient [11:41] okay, thanks. [11:41] mgz: any recent version (prior to 1.7) should do [11:43] ah, so, *not* 1.7? [11:44] oo, they're up to 1.6.17 under that. [11:45] will leave as is unless this build breaks. [11:51] mgz: yeah, 1.7 has a bunch of changes that break assumptions in subvertpy/bzr-svn [12:04] what the hey, why is this deprecation warning getting through... [12:04] that would make me feel really bad about not posting my config location finding changes for review [12:05] but I thought release versions weren't meant to whine [12:06] they're not [12:07] then why is the installer version doing it ;_; [12:07] ah, b5!=release? [12:07] okay, er... [12:07] I wonder whether I should cheat and change the tip, or just put a note in saying "yes, I know I messed this up" [12:08] I need some smallish svn repo to test against too, any suggestions? [12:11] mgz: svn://svn.samba.org/subvertpy/trunk ? [12:14] works... will have to mark the bug as incomplete. [12:37] * vila back [12:37] jelmer: seen my previous remarks about bzr-svn prober ? [12:39] vila: yeah, see recent lp:bzr-svn commits :) [12:40] \o/ [12:43] vila: uploading windows installers now [12:43] \o/ [12:43] :) [12:43] I had to er... adjust for a little problem I caused on trunk [12:46] gah! [12:46] trunk ? [12:46] complaining about password after already uploading [12:47] which trunk ? [12:47] and the script has now broken my terminal [12:51] hpmf, lp_registration directly uses _urllib2_wrappers.Opener, makes it harder to fix the last test failure for cert validation ;_; [13:01] bingo, quick, dirty, works [13:01] okay, I'm stuck, launchpad won't let me upload with the script [13:01] switch to manual upload ? [13:01] either launchpad has changed, or it's no longer accepting the SSO password [13:02] which is what I swear it was last time [13:02] I have a vague souvenir that you encountered issues last time too no ? [13:03] it's just a pain, but I documented it and everything [13:03] but it no longer works [13:04] nothing in .bzr.log ? [13:05] it's using curl to post to a webpage, there's no launchpad api [13:05] hmpf [13:08] "Application error. Unauthenticated user POSTing to page that requires authentication." [13:08] * mgz growls [13:09] coockies involved ? [13:09] it's curl. [13:09] curls supports coockies :) [13:09] I guess lp or sso just broke it. [13:11] can't imagine why nor how [13:11] always possible but... my little daemon tells me it's unlikely [13:17] < wgrant> That's been unsupported for about 2 years, and I removed it last week. [13:18] I removed basic auth. [13:19] * vila to his little daemon: put that in your pipe [13:21] http://doc.bazaar.canonical.com/beta/en/user-reference/location-alias-help.html <== possible to add new custom ones? [13:22] Specific per checkout, I mean [13:38] LeoNerd: I'm not sure I understand your question, do you mean locations defined in branch.conf or defined for checkout property ? [13:39] Either. [13:39] As an enduser: I want some way to bzr diff :fred [13:39] To compare to Fred's branch, where :fred would just expand to the full URL [13:40] ok, so an already available trick then: [13:41] bzr config fred= [13:41] bzr diff --old `bzr config fred` [13:41] Oohright [13:41] Oh.. :( [13:41] ? [13:42] I wanted it to appear as a :NAME like the others.. [13:42] Yeah, that falls nicely into the category of "_technically_ answering the question, but" :p [13:42] I said trick !! [13:42] :) [13:42] The closest answer would be bookmarks. [13:42] * fullermd will hold out for the treat :p [13:43] Ooh. that's probably close enough [13:43] bm:fred [13:43] yup [13:43] But you'll have to find a way to hire Michael Baker. [13:44] I need to implement a config: specifier some day... [13:45] ... and add an alias as c: just to confuse windows users :) [13:45] C:\ is the root of all evil. [13:45] * vila receives BOFH bonus points [13:46] Where's my excuse calendar... [13:49] When I push to a file location, my locations.conf succeeds in supplying some configuration about the branch. if I push to the same place, but via bzr+ssh, it doesn't. what am I missing? [13:52] exarkun: the client can't resolve the aliasing between the two locations, you need to add a location for bzr+ssh [13:52] :O [13:53] jelmer: https://code.launchpad.net/~bzr/bzr/urllib-verifies-ssl-certs/+merge/89437 up for review on top of your proposal [13:54] vila: I'll have a look [13:54] jelmer: not the cleanest proposal I ever made but it does the job for now ;) [13:55] jelmer: the proposal is only the diff against yours, not sure anybody else can understand :-/ [13:59] vila: is there a particular reason you're deferring the fetching of ca_certs from config in the HTTPSConnection, rather than doing it in the constructor? [14:02] in the transport constructor you mean ? [14:02] vila: no, in HTTPSConnection. [14:03] jelmer: not really [14:04] I did it there because the stack was already available [14:04] vila: I think it would make sense to move the configuration variable fetching to the constructor, perhaps [14:04] and since I think this should be reworked anyway it doesn't really change the issue [14:04] not really a big deal :) [14:05] yeah [14:05] I went for the easiest (there were enough issues to deal with ;) [14:05] do I just have to duplicate configuration in locations.conf in two sections, to get multiple urls for the same branch to work? [14:06] exarkun: AFAIK, yes, the only exception being stacked_on_location which you're not supposed to tweak without really understanding the fallouts ;) [14:06] exarkun: either that, or you can put the configuration in .bzr/branch/branch.conf [14:06] exarkun: if they are specific to the branch, jelmer's suggestion is even better [14:07] exarkun: no duplication at all [14:08] Does .bzr/branch/branch.conf move around with the branch? Or is it unversioned local-only configuration? [14:08] exarkun: it's unversioned local-only [14:08] exarkun: "bzr branch" won't copy it [14:09] okay, rewrote the upload script, seemed to work against staging, doing the real thing now, and lunch [14:10] Is this the wrong time to grump that locations.conf really should be called branches.conf, since it only applies to branches? :p [14:11] Okay, that's working. Not sure if I'm happy about unversioned local-only state... but we'll see. [14:11] fullermd: it will apply to repositories and working trees once they gain their associated config file :) [14:12] fullermd: unless I can convince people to introduce defaults.conf and overrides.conf and clearly document them ;) [14:13] fullermd: and I think there was a branches.conf in the past that locations.conf replaced, dunno about the rationale though, I'm too young for that [14:14] Any problem with 1 config file can be solved by introducing 2 config files :p [14:15] well, that's hillarious [14:15] the lp api for uploading files wants the whole thing at once [14:15] and... it OOMed on the third one [14:15] using curl was better, it knows how to stream packets [14:17] Look, Taiwan is full of DRAM makers losing money. A well-designed API will do what it can to help jump-start the economy :p [14:21] vila: approved [14:22] vila: if you have a chance to look at my sibling-branches MP this week, that would be awesome - I hope to do some work next week based on that === yofel_ is now known as yofel [14:54] jelmer: urgh, I hate it when I reviewed a proposal and somehow lost my comments because I close the tab without pushing the right button [14:54] I did review that code, I'm sure [14:56] solution: do reviews in lynx [14:56] Who has room on their system for lynx once they've got emacs crammed in there? [15:00] or in pentadactyl ^I [15:02] jelmer: done [15:03] hm, I don't have push access to lp:lptools [15:03] emacs will soon be part of the bios so this won't matter anymore [15:03] someone want to push a tyop fix for me? [15:03] Wow, I didn't know emacs was that buggy. [15:03] I didn't hear that [15:06] jelmer: lp:~gz/lptools/trivial_content_typeo -> lp:lptools plz [15:06] Well, I'm pretty sure there's a law that no code is allowed into the BIOS unless it's got more bugs than an encrusted entymologic eatery. [15:06] okay, that's my stack of stuff mostly popped, except the doc updates [15:07] And emacs probably runs the same on every system, so that's another strike against it in the BIOS sweeps. [15:07] mgz: "lptools has no active code reviews." ? [15:07] fullermd: you got that wrong, every system run the same under emacs, that's the point ;) [15:09] it's a one-character change [15:09] mgz: ah, sorry [15:09] mgz: I thought you were asking for a review [15:10] and launchpad doesn't actually care what you say the content type is, I was just correcting in drive-by but found out I couldn't push [15:12] mgz: merrrrged [15:12] :) [15:22] vila: how do you want to handle the landing of the urllib-verifies-certs branch? [15:22] jelmer: almost there, finishing the 2.5b5 release, I think landing my branch should be fine no ? [15:23] vila: you can't land it though, because it's got a prerequisite that hasn't landed. [15:23] ? You mean feed-pqm won't list it ? [15:23] vila: yeah [15:23] jelmer: but we've fixed pqm-submit no ? :-D [15:23] vila: heh, fair 'nough [15:24] or do you mean I should approve your branch first ? [15:24] vila: no, but feed-pqm won't allow you to submit your branch until mine has been submitted [15:25] vila: and mine can't be submitted because it won't pass make check [15:25] ha right, so pqm-submit will do [15:25] jelmer: let me check pqm-submit [15:28] jelmer: ha, we agree in the end, good, I wrote my comment in a hurry :) [15:30] jelmer: you miss the (2,5,0,'beta',5) trick, I'll fix (two occurrences, luckily I had some uncommitted changes locally that conflicted) [15:40] hmm, feed-pqm appeared happy to send it... [15:40] oh wait, I may need to upgrade ? ;) [15:41] yeah, that's a bug... [15:41] right, it served me ;) [15:45] fullermd: does bzr requires pycurl on FreeBSD ? [16:09] No. [16:10] ('course, it'll use it if it's there, but installing bzr won't drag in pycurl) [16:15] bzr update elapsed time 33 mins, 20 secs :( [16:16] That sucks. If it were 13 seconds longer, it'd be way more cool. [16:17] don't worry [16:17] it's still running [16:17] are there known performance issues on Windows 7? [16:24] exarkun: which version of bzr? [16:25] a pretty new one I hope === Quintasan_ is now known as Quintasan === deryck is now known as deryck[lunch] === deryck[lunch] is now known as deryck === ISK_ is now known as ISK