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