| jam | 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 |
|---|---|---|
| poolie | hi there | 00:51 |
| poolie | glad to hear that | 00:51 |
| poolie | so you're going pretty soon? | 00:52 |
| jam | I probably won't be around for a long time right now | 00:52 |
| jam | though maybe 10 min or so | 00:53 |
| poolie | oh, i meant moving | 00:53 |
| poolie | if you had more specific dates you could post them | 00:53 |
| poolie | (or maybe you did) | 00:53 |
| jam | 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:53 |
| jam | (when applying for a work visa, you're not allowed to get a travel visa anymore, etc.) | 00:54 |
| jam | 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. | 00:55 |
| jam | 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:01 |
| poolie | hm, and it looks like the knowngraph thing would make it a bit hard to do so? | 01:06 |
| poolie | and adding a .update() method to them would be possible but slightly nontrivial because it has a compiled implementation | 01:06 |
| jam | poolie: right, it is actually going via find_ancestry, though, which *is* composable, because it just returns dicts and sets | 01:10 |
| jam | but it is an Index level api, which doesn't know about fallbacks | 01:10 |
| jam | 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 |
| jam | not that it is worth doing for older bzr's | 01:11 |
| poolie | i was a bit concerned about the performance impacts | 01:12 |
| poolie | do you think we could prune some of these methods? | 01:12 |
| poolie | there seem to be a lot of similar ones | 01:12 |
| jam | poolie: what would you prune? | 01:15 |
| jam | I'm happy to have names changed to protect the innocent :) | 01:15 |
| jam | I certainly wrote a fair amount of it, and I'm happy to discuss why, and open to suggestions for improvements | 01:17 |
| poolie | i haven't got to real specifics yet | 01:18 |
| poolie | there just seem a fair number of interfaces that give you similar data in different forms | 01:19 |
| poolie | i think that combines poorly with having multiple implementations of a class | 01:19 |
| poolie | because it can look like N*M different methods | 01:19 |
| jam | 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 |
| jam | I would like to see leaner classes as well | 01:20 |
| poolie | perhaps it's better to have just one method on the implementation and then wrappers that redo it | 01:21 |
| jam | Part of that is trying to break Abstraction issues. | 01:21 |
| poolie | as someone said in dallas (?) "Let's remember functions are pythonic too" | 01:21 |
| jam | poolie: so the issue is that at least part of the functional code is all the way down at BtreeGraphIndex | 01:21 |
| jam | because that is where the peek-ahead code lies | 01:21 |
| jam | then you aggregate that up through about 4 levels of abstraction | 01:22 |
| jam | Repository.get_known_graph calls into VF.get_known_graph_ancestry with a wrapper | 01:22 |
| jam | which calls self._index. do something | 01:22 |
| jam | which is actually a CombinedGraphIndex | 01:22 |
| jam | which then needs to collect information from each actual index object | 01:22 |
| jam | sorry, there is one more level in there | 01:23 |
| poolie | :) | 01:23 |
| jam | VF._index is actually a VFIndex | 01:23 |
| jam | (GCGraphIndex, KnitGraphIndex, etc.) | 01:23 |
| jam | poolie: and only at the VF and Repo levels do they know about fallbacks | 01:23 |
| poolie | so jam i was hoping to provoke you into making it more obvious :) | 01:31 |
| poolie | or deleting some stuff | 01:31 |
| poolie | perhaps it's fine as it is | 01:31 |
| poolie | or could just do with some discussion in the developer oveview | 01:31 |
| jam | poolie: it doesn't help that there are also compiled vs pure python code in the stack :) | 01:32 |
| poolie | anyhow, you're +1 on landing this change to 2.3? | 01:32 |
| jam | poolie: yeah, fine with me for 2.3 | 01:32 |
| jam | poolie: any update on the status of lp-forking-service in production? | 02:03 |
| jam | you were talking with spm about it, just wondering if you heard anything | 02:04 |
| poolie | jam, it's going to be rolled out in about 21h from now | 02:07 |
| poolie | wallyworld_ and spm will be doing it and i'll help if anything is needed | 02:07 |
| poolie | we're going to do a dry run today | 02:07 |
| wallyworld_ | poolie: /me will be watching :-) don't know how much help i'll be | 02:08 |
| === Ursinha is now known as Ursinha-zzz | ||
| kkrev | 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:37 |
| bob2 | bzr-rewrite is a way | 03:38 |
| lifeless | or just merge; revert --forget-merges | 03:39 |
| kkrev | revert --forget-merges sounds scary. rebase looks like the way to roll together local changes. | 03:44 |
| kkrev | 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:51 |
| kkrev | 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:52 |
| bob2 | well, if you go back to the branch point, you can do what lifeless said (which is simple and non-scary) | 03:53 |
| bob2 | bzr-rewrite probably has a way for you to do that without moving the branch but I don't know it | 03:53 |
| kkrev | 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 |
| bob2 | ? | 03:59 |
| bob2 | merge needs to be run on the branch point so there is something to merge | 03:59 |
| kkrev | bzr merge says "nothing to do". The only changes are in the local branch (not a checkout) | 04:00 |
| spiv | 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 |
| spiv | 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:03 |
| spiv | kkrev: does that make sense? | 04:04 |
| kkrev | I think so. if the docs were a wiki I'd paste that in. | 04:05 |
| kkrev | all clear now. much thanks. | 04:11 |
| poolie | and now bug expiry kicks off | 04:32 |
| lifeless | *boom* :P | 04:36 |
| spiv | poolie: should the single ` in NEWS of 715000-stacking be double? | 04:38 |
| poolie | we're a bit inconsistent | 04:40 |
| poolie | to me it seemed better rest to use single ticks for program identifiers | 04:40 |
| poolie | in some configurations it highlights them differently | 04:40 |
| spiv | I think single backticks have special meaning in ReST? http://docutils.sourceforge.net/docs/user/rst/quickref.html#inline-markup | 04:41 |
| spiv | 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:43 |
| spiv | 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 |
| spiv | In short: I don't think we should use `single backticks` :) | 04:44 |
| maxb | right, 2.3.0 is out in the main PPA | 04:45 |
| maxb | and on that note, sleeeep | 04:46 |
| spiv | Tangentially, it'll be really nice when we can depend on just sphinx and drop the docs-plain target. | 04:46 |
| === oubiwann_ is now known as oubiwann | ||
| poolie | wow 2.2 is so slow to get through pqm compared to 2.5 | 05:43 |
| vila | poolie: try 2.0 ! :D | 06:17 |
| * vila back to coffee | 06:17 | |
| poolie | hi vila; you're early | 06:23 |
| * poolie is merging 2.2-2.3-2.4 | 06:32 | |
| vila | hi all ! | 07:13 |
| * fullermd . o O ( Obviously, the cofffee worked... ) | 07:14 | |
| vila | hey ! I put only 2 f there ! | 07:14 |
| fullermd | I know. I thought you might be running out, so I gave you an extra one there. | 07:14 |
| fullermd | Don't say I never gave you anything : | 07:14 |
| fullermd | p | 07:14 |
| vila | ha cool, now I can type uck without being gross :) | 07:15 |
| fullermd | It's good to know I provide a valuable service to the community like that :p | 07:16 |
| vila | spiv: yup, single backticks are for url refs AIUI | 07:25 |
| vila | poolie: so what's up with the p-i and bug #715000 ? Do we still wait to restart it ? | 07:28 |
| ubot5 | Launchpad bug 715000 in Launchpad itself "Stacking is not fully transitive" [Critical,In progress] https://launchpad.net/bugs/715000 | 07:28 |
| poolie | vila, it's waiting on the lp deployment of the fixed bzr | 07:29 |
| vila | ok | 07:29 |
| vila | poolie: are you asking for a review of lp:~mbp/bzr/integration-2.3 or will you just land it ? | 07:30 |
| poolie | you could just check it quickly | 07:31 |
| poolie | ok, good night vila | 08:42 |
| vila | poolie: g'night | 08:42 |
| * vila back to bed | 08:43 | |
| vila | err, wait ! | 08:43 |
| mr-russ | 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 |
| mr-russ | What I don't understand is is a shared tree setup kind of like the SVNParentPath, group of repositories type setup. | 08:43 |
| mr-russ | Is there a preferred way to get that kind of setup? | 08:44 |
| poolie | vila, can you help, i need to go | 08:45 |
| mr-russ | k, thanks for responding. | 08:46 |
| poolie | mr-russ, as far as i can tell you just need to export that directory | 08:47 |
| poolie | i don't think you need any special setup with bzr | 08:47 |
| mr-russ | 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 |
| mr-russ | what i mean is make the bzr server structure appear like svn as a set of repositories. | 08:48 |
| mr-russ | and not have to maintain config for each one. | 08:48 |
| mr-russ | also, don't forget you need to go poolie :) | 08:50 |
| maxb | 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:17 |
| maxb | 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:18 |
| maxb | Example of what loggerhead looks like in this scenario: http://bzr.maxb.eu/ | 09:24 |
| * maxb glares at recipe builds | 09:36 | |
| mr-russ | maxb: do you setup a project that is a shared directory of branches? | 09:59 |
| mr-russ | maxb: Then that just works with the standard push/pull | 09:59 |
| === zyga_ is now known as zyga | ||
| vila | mr-russ: sorry, my chat notifications broke again | 10:06 |
| vila | 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:07 | |
| maxb | 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 |
| vila | exactly | 10:08 |
| maxb | But that's a time/bandwidth/diskspace optimization rather than a necessity | 10:08 |
| * vila scratches head | 10:14 | |
| vila | maxb: why is 'rmadison bzr' showing 2.3.0 for natty source but 2.3.0~beta5 for amd64 and i386 ? | 10:15 |
| maxb | vila: Because the binaries are stuck in the NEW queue? | 10:15 |
| vila | maxb: stuck as in: too much load on same server or there is a problem waiting for a fix ? | 10:16 |
| vila | maxb: and is there some way to consult this NEW queue ? | 10:16 |
| vila | s/same/some/ | 10:16 |
| maxb | 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 |
| maxb | https://launchpad.net/ubuntu/natty/+queue?queue_state=0&queue_text=bzr | 10:17 |
| mr-russ | Thanks, I think I get it. I just need to go setup the structure on the server and it will just work. | 10:17 |
| vila | mr-russ: that's the idea, come back for more help if needed | 10:18 |
| maxb | This has comically caused the main bzr package to shrink to 38 kB :-) | 10:18 |
| Decorian | 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:18 |
| Decorian | 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:19 |
| Decorian | 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:20 |
| spiv | Decorian: probably the server got a MemoryError. I'd file a bug report anyway :) | 11:22 |
| Decorian | ok, is that something to do with my configuration of the server, and how would i work around it | 11:22 |
| Decorian | i could always wipe the server's repository, and do a fresh push from my most up to date local one. | 11:23 |
| Decorian | I'll file a bug report anyway, with as much information as i know (which unfortunately isn't much). | 11:23 |
| spiv | Decorian: I'd check the .bzr.log on the server | 11:23 |
| * spiv -> bed | 11:23 | |
| Decorian | is that .bzr/.log? | 11:24 |
| Decorian | thank you spiv | 11:24 |
| spiv | No, probably ~/.bzr.log | 11:24 |
| Decorian | ok thank you. | 11:24 |
| Decorian | yes, it's a MemoryError. | 11:26 |
| Decorian | does it still need a bug report, or is this known? | 11:26 |
| vila | Decorian: file a bug report anyway :) With the relevant excerpt from .bzr.log | 12:36 |
| vila | Decorian: there is little that can be said without that | 12:36 |
| Decorian | 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:37 |
| Decorian | 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 |
| Decorian | i'll report what i found. | 12:38 |
| === Meths_ is now known as Meths | ||
| === oubiwann is now known as oubiwann_ | ||
| shakaran | Hi, I have this error doing a bzr upgrade: | 14:09 |
| shakaran | bzr: ERROR: Cannot convert from format Remote: Branch format 7 to format <class | 14:09 |
| shakaran | 'bzrlib.branch.BzrBranchFormat7'>. No converter | 14:09 |
| vila | o_O | 14:10 |
| shakaran | How I can solve? I need upgrade for make a bzr unbind on a lightweight checkout | 14:10 |
| vila | O_O | 14:10 |
| shakaran | I am saying weird things? | 14:10 |
| * fullermd pokes vila in the O | 14:10 | |
| vila | You can't unbind a lightweight checkout | 14:11 |
| shakaran | $ bzr unbind | 14:11 |
| shakaran | bzr: ERROR: To use this feature you must upgrade your branch at bzr+ssh://bazaar | 14:11 |
| shakaran | .launchpad.net/~shakaran/ea/angel/. | 14:11 |
| shakaran | how to upgrade then? | 14:11 |
| vila | bah, unhelpful error message | 14:12 |
| vila | you want to turn your lightweight checkout into a regular branch | 14:12 |
| vila | bzr reconfigure --help | 14:13 |
| vila | 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:14 | |
| shakaran | vila: I will fill a bug. I did previously on ask here a: bzr reconfigure --unstacked | 14:16 |
| shakaran | so, previously to ask I can commit and push | 14:16 |
| shakaran | but when I commit, directly push the commit, so for that reason I looking for a unbind | 14:17 |
| vila | shakaran: right, it seems to me you want a regular branch not a lightweight checkout | 14:17 |
| shakaran | I could take the right way. Delete the branck, and make a regular checkout, but my curiosity wants to know because the problem | 14:18 |
| vila | err, delete the checkout and make a regular branch | 14:23 |
| vila | 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:24 |
| vila | 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 |
| vila | a lightweight checkout doesn't have a local branch, only a master one | 14:25 |
| vila | 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:26 |
| vila | shakaran: so use whatever works for you, which seem to be the regular branches | 14:27 |
| vila | s/regular/standalone/ | 14:27 |
| * vila slaps fingers for using the wrong word when trying to clarify a confusing UI | 14:28 | |
| fullermd | 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:31 |
| * vila looks at bialix postcard... | 14:32 | |
| * vila looks at bialix's postcard... | 14:32 | |
| === tchan1 is now known as tchan | ||
| catsup | how do i check out a revision by revno? | 15:22 |
| catsup | that | 15:24 |
| catsup | 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 |
| fullermd | And then commit it? | 15:25 |
| catsup | i don't know, maybe | 15:26 |
| === Ursinha is now known as Ursinha-afk | ||
| fullermd | 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:26 |
| fullermd | ... well, I guess you COULD do it all via update, but you'd be gambling that it goes smoothly. | 15:27 |
| === Ursinha-afk is now known as Ursinha | ||
| catsup | i'm very confused, from update -h, how you would do that | 15:29 |
| fullermd | bzr update -rX | 15:29 |
| === Ursinha is now known as Ursinha-lunch | ||
| catsup | oh. -r isn | 15:29 |
| catsup | t listed there | 15:29 |
| fullermd | What version do you have? | 15:29 |
| catsup | bzr: ERROR: no such option: -r | 15:30 |
| catsup | Bazaar (bzr) 2.0.3 | 15:30 |
| Peng | Well, it's there in newer versions. | 15:30 |
| fullermd | In 2.1 and newer. | 15:31 |
| Peng | You could "bzr revert -r 123". | 15:31 |
| fullermd | revert would be OK for looking at it, but you wouldn't have any chance of getting it committable from that. | 15:31 |
| Peng | Right. | 15:31 |
| Peng | Look but don't touch. :D | 15:31 |
| Peng | "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:32 |
| Peng | Which is just fine for looking at it, but would be a horrible thing to commit. | 15:33 |
| Peng | If you want to commit anything, you need to use a new branch. | 15:33 |
| catsup | ok, i got that figure out | 15:35 |
| catsup | figured* | 15:37 |
| yshavit | 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:38 |
| vila | yshavit: I use: http://paste.ubuntu.com/565025/ | 15:40 |
| vila | yshavit: this gives me a new branch which is a mirror of the submitter's one | 15:41 |
| vila | yshavit: I then use: alias bzr-review='. `which bzr-review.sh`' | 15:42 |
| yshavit | 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 |
| vila | yshavit: so I can issue 'bzr diff -rsubmit:' right away | 15:42 |
| Peng | yshavit: bzr merge --preview? | 15:42 |
| yshavit | vila, Peng: ah, didn't know about either of those options! I'll take a look now | 15:43 |
| Peng | yshavit: ...except that would just produce the diff seen on lp | 15:43 |
| yshavit | Peng: ah, okay. | 15:43 |
| catsup | ok, i just issued bzr merge, got a conflict, resolved it by editing the file... how do i finish the merge? | 15:43 |
| vila | 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 |
| yshavit | Peng, vila : Do either of you have any best practices for looking at largish (~1500+) diffs? | 15:43 |
| vila | yshavit: shoot the submitter gives good results | 15:44 |
| yshavit | vila: :D | 15:44 |
| vila | yshavit: the following submissions are smaller (on average) | 15:44 |
| catsup | oic, bzr resolve | 15:44 |
| fullermd | 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 |
| yshavit | 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 |
| fullermd | Ah. VCS MAD :p | 15:45 |
| vila | yshavit: seriously, for large diffs, hopefully there are several commits with smaller diffs... | 15:46 |
| Peng | yshavit: When I see a large diff, I run away and hope someone else handles it. | 15:46 |
| yshavit | vila: yes, that there are. I hadn't actually considered looking at it diff-by-diff, that's a good idea. | 15:46 |
| Peng | yshavit: Fortunately I'm only involed in FOSS. :D | 15:46 |
| vila | yshavit: if not, then, yeah, you're kind of doomed, but asking for reviews and not recommending frequent commits... won't fly | 15:47 |
| yshavit | Peng: hippy! ;-) | 15:47 |
| jam | vila: can I get a second review on: https://code.launchpad.net/~eric97/bzr/dump-btree-traceback/+merge/49002 | 15:55 |
| jam | it is pretty small | 15:55 |
| vila | jam: morning jam ! | 15:56 |
| vila | eric's one ? Oh, right, 2 reviews needed, well let me check again but I think I was fine, just forgot to vote ;-/ | 15:56 |
| vila | jam: done, want me to land it ? | 15:58 |
| jam | vila: sure | 15:59 |
| === Ursinha-lunch is now known as Ursinha | ||
| === beuno is now known as beuno-lunch | ||
| henninge | Hi abentley! | 17:14 |
| henninge | How do I merge two pipes? | 17:14 |
| henninge | i.e. the next one into the current one. | 17:14 |
| thumper | bzr merge :next | 17:15 |
| * henninge thought he had tried that | 17:15 | |
| henninge | I had not. | 17:16 |
| henninge | thumper: thanks! | 17:16 |
| abentley | 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:16 |
| henninge | oh right, I think I have used that before | 17:17 |
| henninge | thanks | 17:17 |
| === beuno-lunch is now known as beuno | ||
| === deryck is now known as deryck[lunch] | ||
| zooko | 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 |
| zooko | HACK Zooko-Ofsimplegeos-MacBook-Pro:~/playground$ bzr get lp:txaws | 18:29 |
| zooko | /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 |
| zooko | RandomPool_DeprecationWarning) | 18:29 |
| zooko | Permission denied (publickey). | 18:29 |
| zooko | bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. | 18:29 |
| zooko | Hm, I have bzr 2.3b1. | 18:30 |
| * zooko upgrades to 2.3b4. | 18:30 | |
| maxb | 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:33 |
| maxb | The warning is not usually an issue because bzr suppresses all deprecation warnings when it is a final (non-beta) release | 18:34 |
| vila | ...but the patch is carried by the OSX installer IIRC, at least for the most recent versions | 18:34 |
| maxb | Also, 2.3b4 is an odd thing to upgrade to. 2.3.0 final is out | 18:34 |
| maxb | and there was a 2.3b5 in between | 18:34 |
| vila | and anyyway it's a warning you can ignore, you problem seem to be the 'Permission denied (publickey)' | 18:34 |
| zooko | Ah, I assumed that it didn't need any credentials of mine since this is a public repo. | 18:36 |
| zooko | But... if it is trying to use my ssh key then that probably explains the problem... | 18:37 |
| maxb | 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 |
| maxb | Therefore, ssh is often a lot faster | 18:38 |
| lifeless | s/lot/massively/ | 18:38 |
| lifeless | maxb: consider pinging robey on twitter | 18:38 |
| zooko | Hm, no my ssh public key *is* already registered in launchpad. | 18:40 |
| zooko | Can I get bzr to tell me more about what is going wrong? | 18:40 |
| zooko | Or test the ssh interface with the ssh client directly? | 18:40 |
| === deryck[lunch] is now known as deryck | ||
| maxb | zooko: "ssh your-lp-id@bazaar.launchpad.net" should print "No shells on this server." | 18:49 |
| zooko | Thanks! Fixed. (I didn't have my current ssh key registered after all.) | 18:59 |
| shakaran | vila: https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/716006 the file bug as you requested | 19:13 |
| kkrev | 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:22 |
| kkrev | 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:25 |
| jam | kkrev: there is the plugin bzr-extmerge, but I don't fully remember how to invoke/configure it | 20:27 |
| mgz | also Gordon Tyler's mergetools stuff on trunk addresses this problem no? | 20:28 |
| kkrev | 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:35 |
| kkrev | 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. | 20:47 |
| === Ursinha is now known as Ursinha-bbl | ||
| poolie | hi jam, jelmer | 20:59 |
| jam | hi poolie | 20:59 |
| jam | how did the dry-run lp-forking service stuff go? | 20:59 |
| jam | I saw the lead-up conversation, but none of the final stuff | 20:59 |
| jelmer | hi jam, poolie | 20:59 |
| jam | I did land lp-production-configs since spm approved it | 20:59 |
| poolie | ah, good | 20:59 |
| jam | hopefully that doesn't mess up the ordering you proposed | 20:59 |
| poolie | i didn't hear him specifically reach a conclusion | 20:59 |
| poolie | maybe he was interrupted | 20:59 |
| poolie | i wasn't sure if you were going to land it or him, but it's good it's done | 21:00 |
| poolie | we have a udd meeting now in #ubuntu-meeting | 21:00 |
| poolie | jam, can you join us? | 21:03 |
| maxb | jelmer: Do you happen to be around? | 21:36 |
| jelmer | maxb: somewhat | 21:36 |
| jelmer | maxb: got a bad case of the flu, so I'll disappear after the udd meeting | 21:37 |
| maxb | 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 |
| jelmer | maxb: done | 21:37 |
| maxb | oh dear - get well soon! | 21:37 |
| maxb | yay, and now I can view the page | 21:37 |
| jelmer | thanks :) | 21:37 |
| jelmer | maxb: is there a lp bug about that? | 21:38 |
| maxb | bug 715325 | 21:38 |
| ubot5 | Launchpad bug 715325 in Launchpad itself "recipe is forbidden when it lists a deleted archive" [Critical,Triaged] https://launchpad.net/bugs/715325 | 21:38 |
| jelmer | maxb: you rock, thanks | 21:38 |
| mgz | ha, bzr-git update means I've finally got a repo on bug 393038 | 21:59 |
| ubot5 | Launchpad bug 393038 in Bazaar "UnicodeDecodeError in _inaccessible_normalized_filename" [Medium,Confirmed] https://launchpad.net/bugs/393038 | 21:59 |
| mgz | it's basically what I had before, must have been masked by the other breakage. | 22:00 |
| maxb | 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 |
| poolie | maxb, what are you trying to test? | 22:02 |
| poolie | hi guilhembi | 22:02 |
| maxb | poolie: I'm trying to repair the bzr-dbus testsuite | 22:03 |
| poolie | and it needs to run in a test suite? | 22:03 |
| poolie | blah | 22:03 |
| poolie | in a subprocess | 22:03 |
| poolie | you could try setting BZR_PLUGINS_AT to something handcrafted to work | 22:03 |
| maxb | [ 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 |
| maxb | bzrlib.plugins.dbus cannot be loaded from ['/home/maxb/wc/bzr/bzr-dbus/unstable'] | 22:07 |
| maxb | right path.... shame it doesn't say *why* it can't be loaded :-/ | 22:07 |
| maxb | ah.... | 22:13 |
| maxb | actually, no, I don't have a path starting ['.... :-) | 22:13 |
| poolie | john, with the fallback mps | 22:40 |
| poolie | most of them are superseded | 22:40 |
| poolie | lp doesn't send mail when that happens apparently | 22:41 |
| poolie | i was trying things out to get a good diff showing only the changes since 2.3 | 22:41 |
| === 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 | ||
| mgz | 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:19 |
| ubot5 | '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<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http:/ | 23:20 |
| ubot5 | '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<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http:/ | 23:20 |
| mgz | ...thanks ubot5. | 23:20 |
| poolie | haha | 23:20 |
| poolie | it's probably also a bug that failed api calls return html | 23:20 |
| mgz | 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:20 |
| mgz | the associated branch touched workingtree, but not mutabletree | 23:21 |
| poolie | on the whole in that case i would just go with the new bug | 23:21 |
| poolie | and maybe post a note on the old bug for people who are still affected by it | 23:21 |
| mgz | okay, will do. | 23:21 |
| poolie | i think generally speaking having bugs cycle open-fixed is just confusing y | 23:22 |
| poolie | if we just fixed it and then discovered we didn't that's different | 23:22 |
| jam | mgz: I think it is a new bug | 23:24 |
| mgz | well, the root issue is sorted(os.listdir(...)) which has been in smart_add all along, and is unsafe in those circumstances. | 23:25 |
| mgz | it's easy to move this kind of bug around though, it could well have been failing somewhere else for a bit. | 23:25 |
| mgz | just changing the mutabletree code may well move the problem somewhere else. | 23:25 |
| mgz | I'll play around and see where I get. | 23:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!