[00:51] hi poolie, still a bit in-and-out. K still sick, though looking better. Working a bit in the evening to make up for it. [00:51] hi there [00:51] glad to hear that [00:52] so you're going pretty soon? [00:52] I probably won't be around for a long time right now [00:53] though maybe 10 min or so [00:53] oh, i meant moving [00:53] if you had more specific dates you could post them [00:53] (or maybe you did) [00:53] I don't have exact dates yet. I'll post when I have more concrete stuff. Roughly late Feb. They want us to be there by March 1st, but we don't have the visas yet to actually travel. [00:54] (when applying for a work visa, you're not allowed to get a travel visa anymore, etc.) [00:55] technically, I'm not allowed into Europe until we sort through it, but it's not an issue since we don't have any plans to be there for a while. [01:01] poolie: anyway, I did do some digging, and get_known_graph_ancestry really looks to be the only api not handling recursive fallbacks, because it is the only one that doesn't recurse via a public api [01:06] hm, and it looks like the knowngraph thing would make it a bit hard to do so? [01:06] and adding a .update() method to them would be possible but slightly nontrivial because it has a compiled implementation [01:10] poolie: right, it is actually going via find_ancestry, though, which *is* composable, because it just returns dicts and sets [01:10] but it is an Index level api, which doesn't know about fallbacks [01:11] but if you promote find_ancestry to a VF attribute, that just thunks to self._index.find_ancestry and handles fallbacks, then get_known_graph_ancestry just becomes a thin shell over aggregating it [01:11] not that it is worth doing for older bzr's [01:12] i was a bit concerned about the performance impacts [01:12] do you think we could prune some of these methods? [01:12] there seem to be a lot of similar ones [01:15] poolie: what would you prune? [01:15] I'm happy to have names changed to protect the innocent :) [01:17] I certainly wrote a fair amount of it, and I'm happy to discuss why, and open to suggestions for improvements [01:18] i haven't got to real specifics yet [01:19] there just seem a fair number of interfaces that give you similar data in different forms [01:19] i think that combines poorly with having multiple implementations of a class [01:19] because it can look like N*M different methods [01:20] poolie: so there isn't anything you can do here that you couldn't do with get_parent_map calls. The main difference is that it is just a *lot* faster when you are going to get the whole ancestry. [01:20] I would like to see leaner classes as well [01:21] perhaps it's better to have just one method on the implementation and then wrappers that redo it [01:21] Part of that is trying to break Abstraction issues. [01:21] as someone said in dallas (?) "Let's remember functions are pythonic too" [01:21] poolie: so the issue is that at least part of the functional code is all the way down at BtreeGraphIndex [01:21] because that is where the peek-ahead code lies [01:22] then you aggregate that up through about 4 levels of abstraction [01:22] Repository.get_known_graph calls into VF.get_known_graph_ancestry with a wrapper [01:22] which calls self._index. do something [01:22] which is actually a CombinedGraphIndex [01:22] which then needs to collect information from each actual index object [01:23] sorry, there is one more level in there [01:23] :) [01:23] VF._index is actually a VFIndex [01:23] (GCGraphIndex, KnitGraphIndex, etc.) [01:23] poolie: and only at the VF and Repo levels do they know about fallbacks [01:31] so jam i was hoping to provoke you into making it more obvious :) [01:31] or deleting some stuff [01:31] perhaps it's fine as it is [01:31] or could just do with some discussion in the developer oveview [01:32] poolie: it doesn't help that there are also compiled vs pure python code in the stack :) [01:32] anyhow, you're +1 on landing this change to 2.3? [01:32] poolie: yeah, fine with me for 2.3 [02:03] poolie: any update on the status of lp-forking-service in production? [02:04] you were talking with spm about it, just wondering if you heard anything [02:07] jam, it's going to be rolled out in about 21h from now [02:07] wallyworld_ and spm will be doing it and i'll help if anything is needed [02:07] we're going to do a dry run today [02:08] poolie: /me will be watching :-) don't know how much help i'll be === Ursinha is now known as Ursinha-zzz [03:37] is there any way to concatenate revisions? like you have three incremental revisions you want to roll together before commiting to a central repository? [03:38] bzr-rewrite is a way [03:39] or just merge; revert --forget-merges [03:44] revert --forget-merges sounds scary. rebase looks like the way to roll together local changes. [03:51] I don't think I get how this is supposed to work. I made a branch and committed two revisions. I say "bzr rebase" and it says "no revisions to rebase". [03:52] I just want to roll those two revisions into a single revision for cleaner version history. They're incremental work on a single task. [03:53] well, if you go back to the branch point, you can do what lifeless said (which is simple and non-scary) [03:53] bzr-rewrite probably has a way for you to do that without moving the branch but I don't know it [03:59] it's a local branch off a remote repository and neither rebase nor --forget-merges seem to do anything, even if I manually specify a revision. rebase says "no revisions to rebase". revert just silelently doesn't do anything. [03:59] ? [03:59] merge needs to be run on the branch point so there is something to merge [04:00] bzr merge says "nothing to do". The only changes are in the local branch (not a checkout) [04:03] kkrev: they way to use revert --forget-merges to do this is "bzr branch trunk new-branch; cd new-branch; bzr merge ../local-changes; bzr revert --forget-merges; bzr commit" [04:03] kkrev: (assuming 'trunk' is the branch you want to add this one new commit to, and that 'local-changes' is the branch where you have made your local commits) [04:04] kkrev: does that make sense? [04:05] I think so. if the docs were a wiki I'd paste that in. [04:11] all clear now. much thanks. [04:32] and now bug expiry kicks off [04:36] *boom* :P [04:38] poolie: should the single ` in NEWS of 715000-stacking be double? [04:40] we're a bit inconsistent [04:40] to me it seemed better rest to use single ticks for program identifiers [04:40] in some configurations it highlights them differently [04:41] I think single backticks have special meaning in ReST? http://docutils.sourceforge.net/docs/user/rst/quickref.html#inline-markup [04:43] I guess it probably renders ok, but I get the impression from the ReST docs it's a bit semantically strange to use it like that. [04:44] Hmm, apparently the "default default role" for single backticks without an explicit :role: suffix/prefix is http://docutils.sourceforge.net/docs/ref/rst/roles.html#title-reference [04:44] In short: I don't think we should use `single backticks` :) [04:45] right, 2.3.0 is out in the main PPA [04:46] and on that note, sleeeep [04:46] Tangentially, it'll be really nice when we can depend on just sphinx and drop the docs-plain target. === oubiwann_ is now known as oubiwann [05:43] wow 2.2 is so slow to get through pqm compared to 2.5 [06:17] poolie: try 2.0 ! :D [06:17] * vila back to coffee [06:23] hi vila; you're early [06:32] * poolie is merging 2.2-2.3-2.4 [07:13] hi all ! [07:14] * fullermd . o O ( Obviously, the cofffee worked... ) [07:14] hey ! I put only 2 f there ! [07:14] I know. I thought you might be running out, so I gave you an extra one there. [07:14] Don't say I never gave you anything : [07:14] p [07:15] ha cool, now I can type uck without being gross :) [07:16] It's good to know I provide a valuable service to the community like that :p [07:25] spiv: yup, single backticks are for url refs AIUI [07:28] poolie: so what's up with the p-i and bug #715000 ? Do we still wait to restart it ? [07:28] Launchpad bug 715000 in Launchpad itself "Stacking is not fully transitive" [Critical,In progress] https://launchpad.net/bugs/715000 [07:29] vila, it's waiting on the lp deployment of the fixed bzr [07:29] ok [07:30] poolie: are you asking for a review of lp:~mbp/bzr/integration-2.3 or will you just land it ? [07:31] you could just check it quickly [08:42] ok, good night vila [08:42] poolie: g'night [08:43] * vila back to bed [08:43] err, wait ! [08:43] Hi, I'm coming from SVN and would like a central repository area for developers to push/pull from for updates. I'd like it to be over http, I've read http://doc.bazaar.canonical.com/latest/en/tutorials/centralized_workflow.html and http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/http_smart_server.html#running-a-smart-server [08:43] What I don't understand is is a shared tree setup kind of like the SVNParentPath, group of repositories type setup. [08:44] Is there a preferred way to get that kind of setup? [08:45] vila, can you help, i need to go [08:46] k, thanks for responding. [08:47] mr-russ, as far as i can tell you just need to export that directory [08:47] i don't think you need any special setup with bzr [08:48] Also to add to that, I'm wanting loggerhead to allow viewing the repository groups, hopefully without addition config for each set of branches. [08:48] what i mean is make the bzr server structure appear like svn as a set of repositories. [08:48] and not have to maintain config for each one. [08:50] also, don't forget you need to go poolie :) [09:17] mr-russ: As far as hosting multiple projects and branches thereof is concerned, Bazaar works on the principle (whichever access method you use) of exposing a portion of the directory tree, under which you can put as many branches as you like [09:18] Loggerhead supports basic browsing of the directory tree containing branches, and then switches to the interface that is familiar from bazaar.launchpad.net when you enter a given branch [09:24] Example of what loggerhead looks like in this scenario: http://bzr.maxb.eu/ [09:36] * maxb glares at recipe builds [09:59] maxb: do you setup a project that is a shared directory of branches? [09:59] maxb: Then that just works with the standard push/pull === zyga_ is now known as zyga [10:06] mr-russ: sorry, my chat notifications broke again [10:07] mr-russ: http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief explain some concepts that will make the discussions easier [10:07] * fullermd dreams of the day he can bury this !#&$ project and maybe have time to polish up those sow's ears... [10:08] mr-russ: Basically, a project is just a convention of keeping related branches in a directory - ideally having made the shared directory a Bazaar shared repository so that revision data is shared between all branches under it [10:08] exactly [10:08] But that's a time/bandwidth/diskspace optimization rather than a necessity [10:14] * vila scratches head [10:15] maxb: why is 'rmadison bzr' showing 2.3.0 for natty source but 2.3.0~beta5 for amd64 and i386 ? [10:15] vila: Because the binaries are stuck in the NEW queue? [10:16] maxb: stuck as in: too much load on same server or there is a problem waiting for a fix ? [10:16] maxb: and is there some way to consult this NEW queue ? [10:16] s/same/some/ [10:17] Jelmer split out python-bzrlib as a separate .deb in this release. A new binary package name requires ack-ing by an archive admin before the packages enter the archive. [10:17] https://launchpad.net/ubuntu/natty/+queue?queue_state=0&queue_text=bzr [10:17] Thanks, I think I get it. I just need to go setup the structure on the server and it will just work. [10:18] mr-russ: that's the idea, come back for more help if needed [10:18] This has comically caused the main bzr package to shrink to 38 kB :-) [11:18] hi, bazaar is asking me to file a bug report, thought i'd just mention it here first as I don't know much about the crash so I can't effectively write a bug report. [11:19] it crashed whilst doing a push to a bzr+ssh server (run by me) that worked 20 mins previously, and the other repository on the same server works. [11:20] pastebin of the output bzr explorer gave http://pastebin.com/Gzh73z3U, I'd be gratefull if anyone has any ideas, even if it's 'file a bug report anyway' [11:22] Decorian: probably the server got a MemoryError. I'd file a bug report anyway :) [11:22] ok, is that something to do with my configuration of the server, and how would i work around it [11:23] i could always wipe the server's repository, and do a fresh push from my most up to date local one. [11:23] I'll file a bug report anyway, with as much information as i know (which unfortunately isn't much). [11:23] Decorian: I'd check the .bzr.log on the server [11:23] * spiv -> bed [11:24] is that .bzr/.log? [11:24] thank you spiv [11:24] No, probably ~/.bzr.log [11:24] ok thank you. [11:26] yes, it's a MemoryError. [11:26] does it still need a bug report, or is this known? [12:36] Decorian: file a bug report anyway :) With the relevant excerpt from .bzr.log [12:36] Decorian: there is little that can be said without that [12:37] vila: Ok, I will, I'll attach a few excerpts from .bzr.log because I tried again a few times and sometimes got a pipe failed or something problem [12:38] I tried working around it by choosing to create a new repository in a different directory on the server, but it still failed. [12:38] i'll report what i found. === Meths_ is now known as Meths === oubiwann is now known as oubiwann_ [14:09] Hi, I have this error doing a bzr upgrade: [14:09] bzr: ERROR: Cannot convert from format Remote: Branch format 7 to format 'bzrlib.branch.BzrBranchFormat7'>. No converter [14:10] o_O [14:10] How I can solve? I need upgrade for make a bzr unbind on a lightweight checkout [14:10] O_O [14:10] I am saying weird things? [14:10] * fullermd pokes vila in the O [14:11] You can't unbind a lightweight checkout [14:11] $ bzr unbind [14:11] bzr: ERROR: To use this feature you must upgrade your branch at bzr+ssh://bazaar [14:11] .launchpad.net/~shakaran/ea/angel/. [14:11] how to upgrade then? [14:12] bah, unhelpful error message [14:12] you want to turn your lightweight checkout into a regular branch [14:13] bzr reconfigure --help [14:14] shakaran: please file a bug explaining your misunderstanding, this error message needs to be fixed [14:14] * fullermd wishes reconfigure had more choice of modalities :| [14:16] vila: I will fill a bug. I did previously on ask here a: bzr reconfigure --unstacked [14:16] so, previously to ask I can commit and push [14:17] but when I commit, directly push the commit, so for that reason I looking for a unbind [14:17] shakaran: right, it seems to me you want a regular branch not a lightweight checkout [14:18] I could take the right way. Delete the branck, and make a regular checkout, but my curiosity wants to know because the problem [14:23] err, delete the checkout and make a regular branch [14:24] unbind is for... bound branches, a lightweight checkout is not a bound branch, that's the bug, unbind should warn about that, not suggesting upgrade [14:25] a bound branch ensures that commits happen on the msater branch before they happen on the local branch (the local and master branches are bound) [14:25] a lightweight checkout doesn't have a local branch, only a master one [14:26] this is a confusing UI and one of the cause is that lightweight checkouts and bound branches are generally used by different people because they match different workflows [14:27] shakaran: so use whatever works for you, which seem to be the regular branches [14:27] s/regular/standalone/ [14:28] * vila slaps fingers for using the wrong word when trying to clarify a confusing UI [14:31] Actually, you were probably right the first time, with 'standalone' generally being a term of art for describing its state relative to a shared repo.. [14:32] * vila looks at bialix postcard... [14:32] * vila looks at bialix's postcard... === tchan1 is now known as tchan [15:22] how do i check out a revision by revno? [15:24] that [15:25] that's probably unclear; i mean, i have downloaded a repo with bzr branch, and now i want to get a particular version into my working directory so that i can apply a patch to it [15:25] And then commit it? [15:26] i don't know, maybe === Ursinha is now known as Ursinha-afk [15:26] If you just wanna look at it, you can use update. If you want to commit it, you'll need a branch for that. [15:27] ... well, I guess you COULD do it all via update, but you'd be gambling that it goes smoothly. === Ursinha-afk is now known as Ursinha [15:29] i'm very confused, from update -h, how you would do that [15:29] bzr update -rX === Ursinha is now known as Ursinha-lunch [15:29] oh. -r isn [15:29] t listed there [15:29] What version do you have? [15:30] bzr: ERROR: no such option: -r [15:30] Bazaar (bzr) 2.0.3 [15:30] Well, it's there in newer versions. [15:31] In 2.1 and newer. [15:31] You could "bzr revert -r 123". [15:31] revert would be OK for looking at it, but you wouldn't have any chance of getting it committable from that. [15:31] Right. [15:31] Look but don't touch. :D [15:32] "bzr update -r 123" makes bzr check out the older revision. "bzr revert -r 123" is like applying a massive patch to the currently checked out revision that coincidentally makes it look like revision 123. [15:33] Which is just fine for looking at it, but would be a horrible thing to commit. [15:33] If you want to commit anything, you need to use a new branch. [15:35] ok, i got that figure out [15:37] figured* [15:38] Hi all. Sometimes when I'm reviewing a largish diff on launchpad, I like to load it up in my IDE. To do that, I 1) create a new local branch from trunk, 2) merge in (but don't commit) the proposed branch. That way I can see the changed files in my IDE. Obviously these aren't a lot of steps, but I was wondering if there's a single bzr command that does it? I wrote a really small shell script, I'm just curious to see if there was a better way. [15:40] yshavit: I use: http://paste.ubuntu.com/565025/ [15:41] yshavit: this gives me a new branch which is a mirror of the submitter's one [15:42] yshavit: I then use: alias bzr-review='. `which bzr-review.sh`' [15:42] vila: ah, okay. Yeah I like to have not a mirror but a diff from trunk to submitter's, so I can see just the proposed changes. Or is that what you're doing and I'm missing it? [15:42] yshavit: so I can issue 'bzr diff -rsubmit:' right away [15:42] yshavit: bzr merge --preview? [15:43] vila, Peng: ah, didn't know about either of those options! I'll take a look now [15:43] yshavit: ...except that would just produce the diff seen on lp [15:43] Peng: ah, okay. [15:43] ok, i just issued bzr merge, got a conflict, resolved it by editing the file... how do i finish the merge? [15:43] yshavit: Peng solution is one shot only, having a mirror also allows you to look at the history and better understand the final result [15:43] Peng, vila : Do either of you have any best practices for looking at largish (~1500+) diffs? [15:44] yshavit: shoot the submitter gives good results [15:44] vila: :D [15:44] yshavit: the following submissions are smaller (on average) [15:44] oic, bzr resolve [15:45] vila: No no no, you injure them, you just make the responses slower. Kidnapping family members and/or pets focuses their attention much more usefully. [15:45] vila: my company's still new with bzr, so we're learning to get our diffs down to size. I'm guilty of it, too... just dropped a 2400er on a colleague :( [15:45] Ah. VCS MAD :p [15:46] yshavit: seriously, for large diffs, hopefully there are several commits with smaller diffs... [15:46] yshavit: When I see a large diff, I run away and hope someone else handles it. [15:46] vila: yes, that there are. I hadn't actually considered looking at it diff-by-diff, that's a good idea. [15:46] yshavit: Fortunately I'm only involed in FOSS. :D [15:47] yshavit: if not, then, yeah, you're kind of doomed, but asking for reviews and not recommending frequent commits... won't fly [15:47] Peng: hippy! ;-) [15:55] vila: can I get a second review on: https://code.launchpad.net/~eric97/bzr/dump-btree-traceback/+merge/49002 [15:55] it is pretty small [15:56] jam: morning jam ! [15:56] eric's one ? Oh, right, 2 reviews needed, well let me check again but I think I was fine, just forgot to vote ;-/ [15:58] jam: done, want me to land it ? [15:59] vila: sure === Ursinha-lunch is now known as Ursinha === beuno is now known as beuno-lunch [17:14] Hi abentley! [17:14] How do I merge two pipes? [17:14] i.e. the next one into the current one. [17:15] bzr merge :next [17:15] * henninge thought he had tried that [17:16] I had not. [17:16] thumper: thanks! [17:16] henninge, you can also just use the branch locations. The only thing special about merging pipes is that --uncommitted works with uncommitted changes in a pipe. [17:17] oh right, I think I have used that before [17:17] thanks === beuno-lunch is now known as beuno === deryck is now known as deryck[lunch] [18:29] Hi folks! This web page https://code.launchpad.net/txaws tells me to run "branch lp:txaws", but when I do it says: [18:29] HACK Zooko-Ofsimplegeos-MacBook-Pro:~/playground$ bzr get lp:txaws [18:29] /Library/Python/2.6/site-packages/pycrypto-2.3-py2.6-macosx-10.6-universal.egg/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases. See http://www.pycrypto.org/randpool-broken [18:29] RandomPool_DeprecationWarning) [18:29] Permission denied (publickey). [18:29] bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. [18:30] Hm, I have bzr 2.3b1. [18:30] * zooko upgrades to 2.3b4. [18:33] zooko: This is a known issue with paramiko. The bzr developers have set a patch to paramiko, but paramiko's upstream are being rather slow to apply it [18:34] The warning is not usually an issue because bzr suppresses all deprecation warnings when it is a final (non-beta) release [18:34] ...but the patch is carried by the OSX installer IIRC, at least for the most recent versions [18:34] Also, 2.3b4 is an odd thing to upgrade to. 2.3.0 final is out [18:34] and there was a 2.3b5 in between [18:34] and anyyway it's a warning you can ignore, you problem seem to be the 'Permission denied (publickey)' [18:36] Ah, I assumed that it didn't need any credentials of mine since this is a public repo. [18:37] But... if it is trying to use my ssh key then that probably explains the problem... [18:38] zooko: Connections to launchpad lp: URLs prefer SSH because Launchpad providers the Bazaar smart server over ssh, but only dumb serving via http [18:38] Therefore, ssh is often a lot faster [18:38] s/lot/massively/ [18:38] maxb: consider pinging robey on twitter [18:40] Hm, no my ssh public key *is* already registered in launchpad. [18:40] Can I get bzr to tell me more about what is going wrong? [18:40] Or test the ssh interface with the ssh client directly? === deryck[lunch] is now known as deryck [18:49] zooko: "ssh your-lp-id@bazaar.launchpad.net" should print "No shells on this server." [18:59] Thanks! Fixed. (I didn't have my current ssh key registered after all.) [19:13] vila: https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/716006 the file bug as you requested [20:22] is there supposed to be a way you make bzr launch kdiff automatically for needed manual merges: bzr usekdiff myfile.cpp ? Or do you really have to manually run kdiff3 and then mark resolved? [20:25] it just seems like a very annoying bit of typing to have to specify 'kdiff3 myfile.BASE myfile.THIS myfile.OTHER -o myfile' every single time a manual merge is needed. [20:27] kkrev: there is the plugin bzr-extmerge, but I don't fully remember how to invoke/configure it [20:28] also Gordon Tyler's mergetools stuff on trunk addresses this problem no? [20:35] extmerge looks perfectly good, but is there a trick to making plugins work on windows? It works from cygwin, but from the dos shell "bzr extmerge" just says "unknown command" [20:47] For some reason it doesn't like living in %HOME%/.bazaar/plugins on windows. I had to put it in /program files/bazaar/plugins to make it work. === Ursinha is now known as Ursinha-bbl [20:59] hi jam, jelmer [20:59] hi poolie [20:59] how did the dry-run lp-forking service stuff go? [20:59] I saw the lead-up conversation, but none of the final stuff [20:59] hi jam, poolie [20:59] I did land lp-production-configs since spm approved it [20:59] ah, good [20:59] hopefully that doesn't mess up the ordering you proposed [20:59] i didn't hear him specifically reach a conclusion [20:59] maybe he was interrupted [21:00] i wasn't sure if you were going to land it or him, but it's good it's done [21:00] we have a udd meeting now in #ubuntu-meeting [21:03] jam, can you join us? [21:36] jelmer: Do you happen to be around? [21:36] maxb: somewhat [21:37] maxb: got a bad case of the flu, so I'll disappear after the udd meeting [21:37] jelmer: Hi, could you go here: https://code.launchpad.net/~bzr/+recipe/bzr-dbus-daily and trigger some builds? I am not allowed to view the page because it contains a deleted PPA in the last 5 builds list [21:37] maxb: done [21:37] oh dear - get well soon! [21:37] yay, and now I can view the page [21:37] thanks :) [21:38] maxb: is there a lp bug about that? [21:38] bug 715325 [21:38] Launchpad bug 715325 in Launchpad itself "recipe is forbidden when it lists a deleted archive" [Critical,Triaged] https://launchpad.net/bugs/715325 [21:38] maxb: you rock, thanks [21:59] ha, bzr-git update means I've finally got a repo on bug 393038 [21:59] Launchpad bug 393038 in Bazaar "UnicodeDecodeError in _inaccessible_normalized_filename" [Medium,Confirmed] https://launchpad.net/bugs/393038 [22:00] it's basically what I had before, must have been masked by the other breakage. [22:02] Can someone suggest how to start_bzr_subprocess *and* ensure that the plugin you're currently testing is available to be loaded by the subprocess? [22:02] maxb, what are you trying to test? [22:02] hi guilhembi [22:03] poolie: I'm trying to repair the bzr-dbus testsuite [22:03] and it needs to run in a test suite? [22:03] blah [22:03] in a subprocess [22:03] you could try setting BZR_PLUGINS_AT to something handcrafted to work [22:07] [ 646] 2011-02-09 22:06:22.571 WARNING: bzrlib.plugins.dbus cannot be loaded from ['/home/maxb/wc/bzr/bzr-dbus/unstable'] [22:07] bzrlib.plugins.dbus cannot be loaded from ['/home/maxb/wc/bzr/bzr-dbus/unstable'] [22:07] right path.... shame it doesn't say *why* it can't be loaded :-/ [22:13] ah.... [22:13] actually, no, I don't have a path starting ['.... :-) [22:40] john, with the fallback mps [22:40] most of them are superseded [22:41] lp doesn't send mail when that happens apparently [22:41] i was trying things out to get a good diff showing only the changes since 2.3 === mbarnett changed the topic of #bzr to: Launchpad down/read-only from 23:00 - 00:30 UTC for a code update || Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.2.4 officially released, 2.3.0 frozen. Release plugins ! Build installers ! (rm vila) === Ursinha-bbl is now known as Ursinha [23:19] jam/poolie: do you have any feelings about whether I should reopen bug 77657 and dupe bug 715547 against it, or treat the second as a new thing? [23:20] 'Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable\nResponse headers:\n---\nconnection: close\ncontent-length: 5640\ncontent-type: text/html;charset=utf-8\ndate: Wed, 09 Feb 2011 23:19:59 GMT\nserver: zope.server.http (HTTP)\nstatus: 503\nvia: 1.1 wildcard.launchpad.net\nx-powered-by: Zope (www.zope.org), Python (www.python.org)\n---\nResponse body:\n---\n 'Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable\nResponse headers:\n---\nconnection: close\ncontent-length: 5641\ncontent-type: text/html;charset=utf-8\ndate: Wed, 09 Feb 2011 23:20:10 GMT\nserver: zope.server.http (HTTP)\nstatus: 503\nvia: 1.1 wildcard.launchpad.net\nx-powered-by: Zope (www.zope.org), Python (www.python.org)\n---\nResponse body:\n---\n ...thanks ubot5. [23:20] haha [23:20] it's probably also a bug that failed api calls return html [23:20] as far as I can tell, the exact problem the first (and many of its dupes) was never actually fixed, but a different path was. [23:21] the associated branch touched workingtree, but not mutabletree [23:21] on the whole in that case i would just go with the new bug [23:21] and maybe post a note on the old bug for people who are still affected by it [23:21] okay, will do. [23:22] i think generally speaking having bugs cycle open-fixed is just confusing y [23:22] if we just fixed it and then discovered we didn't that's different [23:24] mgz: I think it is a new bug [23:25] well, the root issue is sorted(os.listdir(...)) which has been in smart_add all along, and is unsafe in those circumstances. [23:25] it's easy to move this kind of bug around though, it could well have been failing somewhere else for a bit. [23:25] just changing the mutabletree code may well move the problem somewhere else. [23:28] I'll play around and see where I get.