[00:00] The progress bars showing bandwidth usage is very cool, but why did it take 2.2 MB to download half a dozen revisions? :( [00:00] ...OK, a dozen revisions. [00:00] Peng_: from a 1.9 format repo? if not, its because the index layer in < 1.9 is quite inefficient (which is why it was replace) [00:02] alf: is bzr not doing something you want it to? [00:05] lifeless: I would just expect bzr diff to inform me that the tree is not in sync with the branch tip (as bzr status does) [00:06] lifeless: Ah, right. (It was bzr.dev.) [00:06] alf: ah! So the reason bzr diff doesn't do that is that its not really relevant to diff - diff is about textual changes, not overall status [00:06] alf: diff also doesn't show pending merges for instance [00:23] lifeless: I have (finally) understood what is going on and its necessity, I must however admit it is a bit unintuitive because of the difference in behaviour between local/remote push [00:24] is it possible to use the bzr command inside a virtualenv that has been activated? [00:24] right now it seems to me that no, but maybe there are workarounds [00:30] whats a virtualenv? [00:30] hmm, it works on the root level of a virtualenv, but not in a subdirectory that is a python module... [00:31] lifeless: it's a Python tool for creating virtual environments for Python installations/apps [00:31] What happens if you branch from a loomified branch? [00:31] davidstrauss: you get a loom [00:31] davidstrauss: with the state of the last record of the loom [00:33] RaceCondition: bzr should just work regardless, unless you're only copying in some of the bzr modules [00:34] RaceCondition: what error do you get? [00:34] lifeless: that bzr cannot find bzrlib [00:34] the cause of this issue is pythonpath actually [00:34] http://dpaste.com/113360/ [00:34] RaceCondition: 'python -c "import bzrlib"' [00:34] it's different depending on which folder Python is run [00:35] I guess it's a Python matter/queston, not a bzr one [00:35] seems likely to me [00:36] mercurial is having the same issue [00:36] both hg and bzr use lazy imports [00:37] how does virtualenv decide what to copy in ? [00:38] lifeless: I dunno [00:38] I'm neither a Python nor a virtualenv expert [00:39] my guess is the lazy import nature [00:41] lifeless: Thank you for the explanation, it has been very helpful [00:41] alf: my pleasure [00:44] lifeless: nope, it's because sys.path actually does not contain what needs to be there [01:08] jelmer: ah, svn-upgrade is what I need if I want to move to bzr-svn 0.5 while keeping existing branches around, correct? My situation is a "trunk" branch in Subversion, a local trunk mirror Bazaar branch and a set of local and remote Bazaar branches created from that local trunk branch. [01:11] jfroy|work: Only for your local branches that are not in svn [01:20] none of them are besides trunk [01:21] jelmer: and what is the correct procedure? upgrade bzr-svn, wipe the cache, nuke my local trunk, re-checkout from svn, then svn-upgrade all the local trunk branches? [01:40] *sigh* [01:42] jelmer: i hit a whole new kind of hell now that i dont only want to have a view on stuff like branches but also getting them from remotes in the various possible flavours [01:42] ronny, hi [01:43] jfroy|work, no need to wipe the cache (unless you've used experimental versions of bzr-svn 0.5) [01:43] jfroy|work, no need to re-checkout from trunk [01:43] jfroy|work, I wouldn't use svn-upgrade atm, pending LarstiQ's bug [01:44] OK [01:44] jelmer: i cant find any reasonable model that fits all ways of bzr to get a repo/branch/workdir [01:44] jelmer: so I can just update bzr-svn and move along? [01:44] ronny, is your current interface definition up somewhere? [01:44] jelmer: no [01:44] s/definition/design/ [01:45] jelmer: the whole checkout vs branch vs dir branch in repo is kina nasty cause bzr is the only one that is that "complex" there [01:46] ronny, I don't think it's complex [01:47] ronny, you basically have branches and trees, either of which can be present [01:47] working trees always have a pointer to some branch [01:47] that's it basically [01:48] jelmer: still, hg, git, darcs do all of that more simple [01:48] ronny, more simple in what regard? [01:48] gits index is approximately our tree [01:48] 1 repo, 1 workdir, 1 way to get it [01:49] ronny: Bazaar is the same, 1 branch, 1 work directory - there's also only one way to get it if you ignore checkouts [01:49] (which I think make sense if you do abstraction like that) [01:50] git can do naked repos and trees without repos too [01:50] you have to set environment variables though :) [01:51] jelmer: it gets nasty as soon as i want to track multiple remote branches in a single repo [01:51] hi nevans [01:51] ronny, How would you do that in darcs? [01:51] ronny: I'd just ignore the repo, its not meant to be semantic; its all about branches [01:51] s/its/they are/ [01:53] repos are kinda important, at least for monotone, git and hg [01:53] but those dont have brnaches as subdirs within repos, but as semantic entities [01:53] ronny: all quite different though [01:54] git branchs are refs in a repo; hg branches are unmerged revs in a single repo, and monotone branches are non-signed revs [01:54] bzr branches are revision ids [01:55] lifeless: but they exist as actual entities in the fs [01:55] ronny: yes, thats a key design point [01:55] ronny: it gives them unique URL's [01:56] lifeless: but adds massive amounts of complexity to deal with for me [01:56] ronny: in what way [01:56] and i think its important enough to deal with [01:57] if its adding complexity for our users, we may need to change this, so I really would like to understand [01:57] lifeless: it makes getting a repo + branches really different from the others [01:58] why worry about the repo [01:58] why not 'get branches'? [01:58] perhaps some background is required here [01:58] im intrested in sets of branches [01:58] not just one [01:58] ronny, this is for your work on a vcs abstraction library, right? [01:58] jelmer: yeah [01:58] lifeless, ^ [02:00] I'd ffigured that much :P [02:00] and bzr always manages to look the most complex from *my* point of view [02:00] at things where the others have one oblivious way i see 3 different ways that are all valid [02:01] its true that there are many combinations bzr supports; I think you'll find that git and hg both support the same things bzr does, but not as clearly in the UI [02:01] and the whole standalone branch vs dir branch in repo vs checkout is my most nasty thing i see [02:02] which suggests to me that what jelmer said is very applicable - there is no need to represent everything in your library [02:02] ronny: how is it nasty for you? [02:03] (I'm not an ELIZA bot honest) [02:03] lifeless: it seems very complex [02:03] i learned dvcs with monotone [02:03] ronny: tree.branch.repository [02:03] ronny: three objects, left->right dependency so if you have tree, you always have branch and repo [02:03] so git/hg feel rather natural, but bzr is kinda alienating [02:04] this is mostly related to having n ways instead of just one [02:05] ronny: but git has more than one way! and so does hg [02:05] ronny: so I *fail* to understand that commend [02:05] lifeless: git/hg have only clone there [02:06] i fail to see how that can be more than one way [02:06] ronny: uhm, sounds like there are wires crossed. [02:06] ronny: are you talking about how to get a branch, or about the way things can be laid out on disk ? [02:07] lifeless: how to get a branch [02:07] or better a set of them [02:07] 'bzr branch' is the only command in bzr to get a branch [02:07] and we don't have a UI for getting a set of branches at the moment, not in the core [02:08] a clone in git/hg (or sync in monotone) always gets me the stuff thats currently up - including tracked branches [02:09] bascially i get my set of branches, then work on them like i need to [02:10] well, hg doesn't do branches in a way thats friendly to that, but sure, git does [02:10] for me it makes no sense to limit dealing with them to exactly one at a time [02:10] I'd use loom or jelmers colocated plugin to do that in bzr, if I felt the urge [02:11] colocated? [02:12] jelmer wrote a plugin that gives something approximating git branch management [02:13] I didn't think darcs did sets of branches either [02:13] codeville either [02:13] lifeless: Speaking of which, I'm still interested in feedback on the spec for that :-) [02:13] svn doesn't [02:13] lifeless: darcs is kinda different [02:13] jelmer: on my todo [02:13] lifeless, cool, thanks! [02:13] and svn is just a workdir, the branches are always remote [02:14] ronny: but remote branches are one per url, and a 'repo' may have thousands of unrelated things in it [02:14] ronny: svn's branch management is actually quite similar to bzr IMO [02:14] except in bzr they are typed rather than free-form (which is fugly) [02:15] lifeless: local+remote vs only remote [02:15] ronny: URL based, which is all I'm talking about [02:15] 'bzr branches' -> list of branches [02:15] etc [02:16] lifeless: i dont actually care about url's, all i need is a name [02:17] ronny: branch.get_nick() I think is the API, that will give you the name [02:18] lifeless: is that plugin called loom? [02:18] tro: which plugin? [02:18] lifeless: thats not my issue here, its the n ways to get the thing set up as well as the different fs layout [02:18] the one that jelmer wrote to approximate git branch management [02:18] ronny: you say there are n ways, but I only know of one way to get a branch to work on. [02:18] ronny: which is 'bzr branch' [02:19] tro, it's bzr-local-branches [02:19] tro: no loom is for patch management; ^ is jelmers [02:19] ah, ok [02:19] tro, it mainly does multiple branches in one dir though, no tracking of remotes like git [02:20] hmm, so its just as powerfull as hg bookmarks [02:20] that would work for me, i think. my use case is that i've got a large project that takes like 30 mins to setup in my IDE. it's not fun to branch around into separate directories because of that [02:20] hmm [02:20] tro: you do know about 'bzr switch' yes ? [02:21] lifeless: yes, it's what i use, but then i have to think about where to put the repository. then when i wanna switch i have to remember what the branches are called [02:22] maybe all i need is a plugin with a "switch history" [02:22] reminds me, i'll have to implement "switch" support too [02:22] * igc lunch [02:22] tro: I see. What I generally do is just have the repo at ~/src/project, then branches under that are cheap [02:22] so i could do "bzr switch -1" to go back to the previous see branch [02:22] seen* [02:23] tro: for C projects I just checkout --lightweight one branch to 'working' and then swtich from there [02:23] tro: thats a nice idea [02:23] i'll see if i can do something about it :) [02:23] tro: perhaps the bookmarks plugin could grow that, writing something to the tree [02:24] i'll take a look at the bookmarks plugin, thanks [02:25] hmm [02:26] i'll ignore checkouts and figure a good way to deal with repos + branch dirs [02:36] where has bzr shelve put the shelf now? [02:37] thumper: i think it's inside .bzr/checkout/shelf , if it's a checkout, anyway [02:38] can I just move that to another checkout? [02:40] probably [02:42] yep, it works [02:45] statik: ping [02:59] lifeless: hi [03:04] abentley: replied to our thread; hoping we can get consensus before you crash [03:04] statik: mailed you about ack ;) [03:05] lifeless: yeah, just saw it. i'll have to try bzr-search out again, but this week might be pretty tough. i'm on the wrong side of a deadline, and flying to london on saturday [03:07] * statik pulls the latest trunk of bzr search [03:16] lifeless: Quite a while 'till we crash, but I doubt we'll get consensus. [03:17] abentley: ah. Well I want to make sure I don't cause problems for lp or bb. As long as I know what those constraints are I'll be happy [03:18] lifeless: Well, the nub of it is that I don't believe there are sane default paths for plugins. [03:19] lifeless: There are sane paths for given clients, but they'll vary based on circumstance. [03:23] abentley: I believe the default should be what bzr does, because that is least confusing for users of bzrlib. [03:25] lifeless: I believe the default should be to do nothing, because that has the least potential to explode when the user's system bzr is upgraded. [03:26] I think that bzrlib.plugins is, itself, confusing. Because it doesn't behave the way other packages do. [03:26] abentley: how does it behave differently? [03:26] I'm a little bit uncomfortable about bzrlib doing that, it feels a bit too much like assuming bzr is the only client. I don't feel strongly about it, it just makes me slightly nervous. [03:26] spiv: qualify 'that' please. [03:27] lifeless: Importing from bzrlib.plugins imports things from directories other bzrlib/plugins [03:27] abentley: thats standard python functionality [03:27] abentley: the __path__ in the module controls the search [03:27] we used to have some really complex stuff, but I unified it with default python logic some time ago [03:28] lifeless: I know how it works. It's still unlike every other package I've encountered. [03:28] ok [03:28] lifeless: doing things at import time, basically. I think this case is likely to be just fine, it's just the sort of thing worries me slightly :) [03:28] It is magic. [03:30] it was fine for years. I think a totally different change borked things [03:30] Whatever we do, we should clearly document both how to get a typical bzr plugin path, and how to do something different that will make e.g. launchpad feel safe. [03:31] lifeless: To me, that totally different change brought the problems with default paths to the fore. [03:31] lifeless: That's why I submitted a patch to stop loading default paths, instead of reverting the other change. [03:31] I am a little curious about the use case for "import bzrlib.plugins.FOO" without first telling bzrlib to configure the plugins path. Just interactive convenience? [03:32] spiv: sane default, interactive convenience [03:33] I'd say load all plugins by default too but that makes me twitch too. (Not to mention that there is a bootstrap issue trying to do --no-plugins if we did that). [03:35] Right, loading all plugins by default conflicts with being able to write other than bzr on bzrlib. (And even conflicts with bzr itself, as you say.) [03:36] Whereas this proposal just sets some configuration a certain way by default... It's still a bit weird that "import bzrlib.plugins.FOO" won't work, but "import bzrlib.plugin; import bzrlib.plugins.FOO" will. [03:37] Or is bzrlib.plugin always imported by bzrlib? I guess it is. [03:46] spiv: loading bzrlib.plugin doesn't set a path either [03:46] spiv: importing bzrlib.plugins sets a path of ['.'] basically, because thats what python does [04:07] it might be useful to have an API like "load this one particular plugin using the same logic to find it as load_plugins() does" [04:08] given that "import bzrlib.plugins.FOO" won't find everything [04:08] jamesh: there is such an api - 'import bzrlib.plugins.PLUGIN' [04:08] jamesh: what won't it find? [04:08] lifeless: I've had problems using that to find plugins in ~/.bazaar/plugins. Has that been fixed since then? [04:09] jamesh: did you file a bug? They are asserted to be the same [04:09] lifeless: if they are under bzrlib/plugins, things work as you describe [04:09] lifeless: I didn't know that it was a bug. [04:09] jamesh: were you acting as a bzrlib client? [04:09] lifeless: yes. [04:10] if by that you mean a Python program that imports bzrlib [04:10] jamesh: then this is likely exactly the bug I'm talking about [04:10] jamesh: starting in (I think) 1.11, you have to manually set the plugins path. Which is what I want to back out. [04:11] lifeless: hmm. I've got bzr-1.10 here [04:11] jamesh: does bzrlib/__init__ contain a call to set_plugins_path()? [04:12] lifeless: no [04:12] ok, then it was 1.10 that this got changed in [04:12] diff __init__.py with 1.9 :) [04:31] what would be the best way to iterate over the revisions of a branch starting from revision 1 and preserving the merging history ? [04:31] seems like branch.get_history () only returns the mainline rev-ids [04:31] s/get_/revision_/ [04:53] you'll need a topological sort [04:53] and you have to rewrite most of the merged nodes too because they may refer to nodes you are rewriting [05:02] anyhow,the tsort module is your friend [05:08] ooh [05:08] * nDuff wonders if bzrlib.tsort.TopoSort is faster than the topological sort in the NX graph library he's using elsewhere. [05:10] nDuff: worth giving it a spin [05:26] abentley: /win 51 [05:26] bah [05:26] abentley: I'd really like to get something that won't break lp/hitchhiker/bundlebuggy etc. I *will* be putting up a patch though, so please help me to put one up that doesn't break those other tools. === mneptok_ is now known as mneptok [05:27] also, freenode fail. yay === thumper_laptop is now known as thumper [06:32] abentley, you're not around are you? [07:01] hi all [07:12] bzr version 1.11, bzr update => *** Bazaar has encountered an internal error. [07:12] _unpack_entry() got an unexpected keyword argument 'entry_cache' [07:12] any ideas? [07:18] sohail: pastebin a full traceback? [07:18] sohail: also, maybe try --no-plugins. [07:19] spiv, will do [07:20] spiv, can you access https://bugs.launchpad.net/bzr/+bug/321765 [07:20] Ubuntu bug 321765 in bzr "When executing bzr update, get error: _unpack_entry() got an unexpected keyword argument 'entry_cache'" [Undecided,New] [07:23] sohail: looks like a bug! [07:23] congrats ;) [07:24] spiv, groan... [07:24] workaround possible? [07:24] hmm [07:24] * sohail notices no bzr stash [07:25] ah bzr shelve [07:26] sohail: looking... [07:28] sohail: that's a strange one. I can't see the cause by reading the code, but I'd expect to be able to. [07:30] spiv, yep [07:30] I was looking at the code too [07:30] no idea [07:30] hi vila [07:30] hi Ian ! [07:31] sohail: can you print the type of self in that failing _unpack_inventory method? [07:31] spiv, ok [07:31] spiv, so you mean print type(self) yeah? [07:31] Right. [07:32] igc, vila: good evening [07:32] [07:32] that doesn't help! [07:32] Heh, no. [07:33] I guess I was forgetting that you were using --no-plugins, so it was hardly going to be otherwise. [07:34] spiv, I think I may have got it? [07:34] it should be inheriting from v7 not v6 [07:35] No, I don't think so. [07:35] Besides, Serializer_v7 defines _unpack_entry with the same signature. [07:35] no, v6 does not have the cache parameter [07:36] b/c v6 inherits from v8 [07:36] You must be looking at a different 1.11 than me... [07:36] I must be... [07:36] hm.. wtf [07:37] Because in mine, v6 inherits from v8 (as you say), and v8 defines _unpack_entry with the same signature as v7. [07:37] wt [07:37] f [07:37] I'm using bzr from ppa or something [07:38] I wonder if it didn't uninstall properly [07:38] doh that must have been it [07:40] spiv, I think that's it! [07:40] gigantic PEBKAC [07:40] sohail: phew :) [07:40] wait... still checking [07:41] yep, all good [07:41] geez [07:41] thanks spiv [07:41] sohail: maybe file a bug about the packaging? :( [07:42] Oh, d'oh, you already closed your bug just before I did :) [07:42] spiv, no what happened was that I had the ubuntu version of it [07:42] switched to ppa before uninstalling [07:42] and presumably THEN removed it (or something) [07:43] but still... it shouldn't have royally screwed up like that [07:43] * sohail shrugs [07:43] Yeah, neither the ubuntu or the ppa versions should do that. [07:43] * sohail unshelves and continues [07:43] First time I've heard of it happening! [07:43] I'm pretty sure I did something wrong [07:44] so unless it happens again, I'm happy [07:44] Ok :) [07:44] bzr shelve is quite cool [08:49] bzrtools needs to be updated in launchpad ppa. [09:27] Can the rebase plugin help move revisions between "unrelated" branches? [09:28] Use case: after the GForge→FusionForge fork^Wrenaming, we're considering starting with a mirror of the previous SVN repository. [09:29] Same contents, same history, but different repo UUIDs and therefore different bzr revision ids. [09:31] But I'd like to graft the previous branches onto the trunk based on the new SVN repo. [09:31] I suppose rebase could help, but I fear it would complain about unrelated branches. And the doc doesn't help me much. [09:32] * Lo-lan-do tries with --onto [09:37] Doesn't seem to work :-/ === asac_ is now known as asac [10:44] Lo-lan-do: try to run bzr replay [10:44] Aha! [10:45] it is a hidden command from bzr-rebase [10:45] * Lo-lan-do tries that [10:47] Not working either. I get conflicts :-( === Guest44711 is now known as jelmer [11:14] asabil, Lo-lan-do: replay and rebase are in essence the same thing, just different UIs [11:18] Is it possible to utilise 'external' branches within a project, similar to svn:externals ? [11:33] I just updated to bzr HEAD and am impressed with the new pull output. So kudos to whoever did that. :) === sabdfl1 is now known as sabdfl [11:50] jelmer: Do you have your subvertpy packages available anywhere? [12:02] Odd_Bloke, yes, http://people.samba.org/bzr/jelmer/bzr-svn/debian [12:02] ehum [12:02] Odd_Bloke, yes, http://people.samba.org/bzr/jelmer/subvertpy/debian :-) [12:03] Odd_Bloke, there's also packages uploaded to the subverpty PPA and NEW [12:03] CaMason, that's nested branches, which have been stalled for a while [12:03] jelmer: Yeah, I saw them in NEW. But I don't want to have to wait. :p [12:05] how can I create a commit with 2 parents using bzrlib ? [12:06] Lo-lan-do, the problem is that the file ids are still different even if the revision ids are not [12:07] Lo-lan-do, bug 231674 [12:07] Launchpad bug 231674 in bzr-rebase "can't replay, need maptree support in rebase" [Wishlist,Triaged] https://launchpad.net/bugs/231674 [12:07] asabil: You can specify the parent ids to the commit function [12:07] jelmer: Thanks. :) [12:07] asabil_: You can specify the parent ids to the commit function [12:07] Odd_Bloke, just "bzr builddeb http://people.samba.org/bzr/jelmer/subvertpy/debian" should build you a package [12:07] ok thanks jelmer === asabil_ is now known as asabil === poolie2 is now known as poolie [12:23] !pastebin [12:23] pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) [12:23] can someone help me with this code: http://pastebin.com/m315e7782 [12:24] after a while I get the following error: [12:24] bzr: ERROR: Working tree is out of date, please run 'bzr update'. [12:25] http://paste.ubuntu.com/110254/ - i can not get bzr shelve work in 1.10 or 1.11, it reports same error [12:26] hsn_: run bzr break-lock [12:27] jelmer: That makes sense. I guess I'll go the old way then, and apply diffs by hand. [12:27] asabil: it doesnt help, after breaking lock i will get could not obtain lock error again [12:28] jelmer: did you see my comment on bug #256612 [12:28] Launchpad bug 256612 in bzr "should handle 401 (unauthorized) response" [High,In progress] https://launchpad.net/bugs/256612 [12:29] vila, could we do password prompting for 401 responses? [12:30] err, we already do password prompting for 401, are you asking for *user* prompting instead ? [12:32] jelmer: anyway, that would be a different problem, 256512 is about getting the credentials from svn when we connect to a svn server [12:32] vila: ah, I wasn't aware we did password prompting already [12:32] I'll have a look at the svn side of things [12:33] I'm pretty sure we fail right now because we have no *user* to provide which a svn credential store plugged into authentication.conf *can* provide [12:34] from there bzr can prompt for password, fail its probe, fall back to bzr-svn probe, which finally can succeed [12:35] That's the scenario you and I identified months ago for which there was no good solution. Remember that ? [12:36] my error is same as this: https://bugs.launchpad.net/bzr/+bug/305006 - so its currently fix commited to devel bazaar version? [12:36] Ubuntu bug 305006 in bzr "shelve fails with "Could not acquire lock"" [Undecided,Fix committed] [12:39] jelmer: any idea about my code ? [12:39] vila, yeah [12:40] asabil, which code? [12:40] http://pastebin.com/m315e7782 [12:40] I am trying to rebuild a branch from another branch [12:40] in the same way that bzr-rebase does [12:41] and it fails when it encounters a merge [12:41] any reason for not just using rebase? [12:42] asabil, How does it fail? [12:43] jelmer: I am trying to write bzr filter-branch [12:43] asabil, ah, cool [12:43] it fails asking for update to be ran [12:43] when I add tree_to.update () before the commit [12:43] it fails with conflicts [12:48] asabil, why whould you be calling update() ? [12:49] jelmer: its asks for it [12:51] I don't think you actually need to *do* a merge do you? [12:51] james_w: I just copied what bzr-rebase does [12:51] do you not know what the tree of the revisions is supposed to look like at each point? [12:51] I do know [12:53] you can just put the tree in that state and use "tree.set_parent_ids()" and then commit in that case [12:54] james_w: and how can I put it in that state ? [12:55] sorry I am not yet familiar with theses apis [12:55] well, that depends on where you get the information from [12:55] presumably you check out the old revisions tree [12:55] apply the filter-branch transform on it [12:56] and then commit the result [12:56] I just need the no-transform case for now [12:56] I will find my way later [12:56] for a merge it will be the same thing, but you set an extra parent or three on the working tree before committing [12:56] ok, just checking it out and committing [12:57] though I see your point now, I'm not sure what the API is for checking out the old revision tree in to the new working tree [12:58] vila: is RedirectRequested something new? [12:58] that's what I am looking for [12:59] james_w: no [12:59] james_w: I think it's even pre-1.0... [12:59] vila: hmm, my transport.do_catching_redirections code appears to have just broken [13:00] e.get_target_url() [13:00] AttributeError: 'RedirectRequested' object has no attribute 'get_target_url' [13:00] wow, where are you using such code ? [13:00] vila: is ~/.netrc supposed to work for regular sftp:// and bzr+ssh:// usage yet? [13:00] vila: in a plugin(ish) [13:01] james_w: ouch, I may have broken backward compatibility then, but on the other hand there was several bugs there [13:01] I need to follow some launchpad redirects to get the librarian url for some files I need [13:02] vila: no problem, this code is only running in one place, so it's not difficult to fix [13:02] vila: do you know off-hand what the new way of doing that would be? [13:02] james_w: give me a minute to page-in the code [13:02] * vila 's memory acess times is in the minute range... what a shame [13:02]