| * spiv is reviewing https://code.launchpad.net/~maxb/bzr/2.2-close-ssh-subprocess-socket/+merge/40493 | 00:56 | |
| maxb | thanks :-) | 01:03 |
|---|---|---|
| dcoles_ | Should all version 2 merge directives have a target_branch inside the header of the merge directive? | 02:32 |
| dcoles_ | Just about to open a bug since Bazaar crashes when the target_branch is missing. | 02:33 |
| spiv | dcoles_: if it's a crash that produces a traceback, then it's definitely a bug even if that's not valid | 02:37 |
| dcoles_ | spiv: Right-o. Just opened bug #673344 | 02:39 |
| ubot5 | Bug 673344 on http://launchpad.net/bugs/673344 is private | 02:39 |
| dcoles_ | Can't seem to find the merge directive spec in the dev docs. | 02:39 |
| spiv | Yes, I can't find a description of the format (other than the code that implements it) at a glance either. | 02:41 |
| spiv | I might not be looking hard enough. | 02:41 |
| spiv | There's at least some code that appears to expect that the target_branch field may not be present. | 02:42 |
| dcoles_ | I can't imagine it being too important. From my own merge directives it just seems to contain the local checkout that it was branched off. | 02:42 |
| dcoles_ | target_branch: file:///home/dcoles/Documents/Projects/plagiarism\ | 02:43 |
| dcoles_ | Whoops. | 02:43 |
| dcoles_ | Either way, that target_branch wouldn't have made sense to the person who received it (since it's a local directory) | 02:44 |
| spiv | Well, if you configure a public_location for your local branches it'll use thta | 02:44 |
| dcoles_ | Aye. That might have been the cause. His version of bazaar must have just dropped the location. | 02:45 |
| spiv | Is there any particular reason that bug report is private? | 02:47 |
| dcoles_ | Not really. Unless I bumped a 'private' checkbox somewhere (I went via apport)... | 02:49 |
| lifeless | apport files all bugs as private | 02:49 |
| lifeless | until vetted for confidential data (which the apport retracer does for ones in ubuntu itself) | 02:49 |
| spiv | I should have asked, do you mind if we make that report public? :) | 02:50 |
| dcoles_ | Yeah. It's fine. I just un-privated it myself. | 02:51 |
| dcoles_ | Looks like nothing but Python and Bazaar stuff. | 02:51 |
| dcoles_ | ... And Google has already indexed the bug... | 02:56 |
| dcoles_ | Seems to have gone AWOL in the current docs, but http://doc.bazaar.canonical.com/bzr.2.0rc2-html/developers/bundle-format4.html | 03:03 |
| GaryvdM | Morning | 05:20 |
| spiv | Hmm, I'm increasingly wanting to use tribunal to read bzr test output I think. | 05:22 |
| spiv | So that I don't have to wade through masses of bzr log output in test failures by default (but so that the log output will still be there when I need it). | 05:22 |
| poolie | spiv, well, you should use it! | 05:25 |
| poolie | :) | 05:25 |
| poolie | it does work | 05:25 |
| poolie | there are many other features that would be nice, but we can add them over time... | 05:25 |
| spiv | poolie: the problem is I'd feel compelled to dust off my half-done patches for it first ;) | 05:32 |
| poolie | this is a problem? :) | 05:33 |
| spiv | Not in the long run :) | 05:33 |
| === jfroy_ is now known as jfroy | ||
| GaryvdM | I'm digging arround the code for loggerhead. I'm trying to find what would be the equivalent to routes.py in a pylons. | 06:36 |
| GaryvdM | i.e. where does it decide what controller to use? | 06:36 |
| GaryvdM | Ah - apps.branch.BranchWSGIApp.controllers_dict | 06:40 |
| mkanat | GaryvdM: I'm a loggerhead guy if you have other general questions. | 07:06 |
| GaryvdM | mkanat: I'm want to try use my loggraphviz code from qlog in loggerhead | 07:08 |
| mkanat | GaryvdM: Okay. That does a dot graph of revisions, or something? | 07:09 |
| GaryvdM | mkanat: Yes - a graph visualisation, but it does no use dot format. - screen shot: http://qbzr.googlegroups.com/web/gtk_qlog.png | 07:11 |
| mkanat | GaryvdM: Oh yeah, I've seen that, that's really slick. | 07:12 |
| GaryvdM | mkanat: You can also collapse/expand revisions | 07:12 |
| mkanat | GaryvdM: That would be quite a trick to do in HTML, I'd think. | 07:12 |
| GaryvdM | mkanat: I need to cache a object in memory. There would be one per branch, and it would be valid until the branch tip changes. | 07:13 |
| mkanat | GaryvdM: Ah, we already have a revision graph cache. | 07:14 |
| mkanat | GaryvdM: It's in loggerhead.history, as I recall. | 07:14 |
| GaryvdM | mkanat: According to the doc string, it only lives for the length of a request. | 07:16 |
| mkanat | GaryvdM: No, it is persistent. | 07:16 |
| mkanat | GaryvdM: At least, if you're using the right graph cache. | 07:16 |
| GaryvdM | Oh | 07:16 |
| mkanat | GaryvdM: The History object only lasts one request, but the actual graph cache is the lru_cache. | 07:17 |
| poolie | hi all | 07:18 |
| mkanat | Hey poolie. | 07:18 |
| GaryvdM | Hi poolie | 07:18 |
| poolie | i need to go in a sec | 07:18 |
| poolie | but, mkanat, can you let me know some time what happens next with loggerhead on codebrowse? | 07:18 |
| poolie | and/or talk to jam about it? | 07:18 |
| mkanat | jam: Yeah, I need to go back and look at what we need to fix in loggerhead itself before we can put it behind haproxy. | 07:19 |
| poolie | that would be good | 07:20 |
| mkanat | I mean, poolie, not jam. :-) | 07:21 |
| poolie | i guessed :) | 07:21 |
| mkanat | poolie: Yeah, I think I explained it briefly to lifeless by email, I have to go back and see what I was thinking the problems were when we talked about it. | 07:21 |
| poolie | you could perhaps just forward that to launchpad-dev? | 07:22 |
| poolie | oops, got to go, may be back tonight | 07:22 |
| spiv | poolie: g'night! | 07:23 |
| GaryvdM | mkanat: The object I want to cache is an instance of this object: http://bazaar.launchpad.net/~garyvdm/bzr/loggraphviz/annotate/head%3A/bzrlib/loggraphviz.py#L134 | 07:23 |
| mkanat | GaryvdM: I think that all the heavy lifting that that object does can be done by the existing revision graph cache. | 07:24 |
| mkanat | GaryvdM: Loggerhead currently has serious memory-usage problems, so adding a second cache would not be a good idea (it would never go on Launchpad, for example). | 07:24 |
| GaryvdM | mkanat: Sure - That why I'm trying to get a good understanding of the existing infrastructure first. | 07:25 |
| mkanat | GaryvdM: Okay, cool. :-) | 07:26 |
| GaryvdM | mkanat: Does lp run lp:loggerhead, or some other branch? | 07:26 |
| mkanat | GaryvdM: lp runs launchpad-loggerhead, which is a wrapper around normal loggerhead. (A whole separate project.) | 07:26 |
| mkanat | GaryvdM: But essentially yes, lp runs the trunk branch of loggerhead. | 07:26 |
| mkanat | (With a few differences in deployment and so on.) | 07:27 |
| lifeless | mkanat: we're now running two parallel instances | 07:27 |
| mkanat | lifeless: Oh, that actually happened? | 07:27 |
| lifeless | yeah | 07:28 |
| lifeless | we haven't trimmed the worker count yet | 07:28 |
| mkanat | lifeless: Okay. Is it working or is it killing the server with OOMs? | 07:28 |
| lifeless | working AFAIK | 07:28 |
| mkanat | lifeless: Okay. I suppose I'll have to ask spm, too. | 07:28 |
| lifeless | if you want details ;) | 07:32 |
| lifeless | the driver for the work so far was being able to do no downtime deployments | 07:32 |
| mkanat | lifeless: Ah, okay. | 07:35 |
| === lamont` is now known as lamont | ||
| mkanat | lifeless: I'll ask spm if there have still been any stability issues. | 07:39 |
| vila | hi all ! | 07:39 |
| vila | ping LOSA, can we have some feedback (or even better a fix) about rt #41340 | 07:41 |
| Sakura13 | any german out there? | 08:28 |
| lifeless | vila: the losas have asked that we ping on the internal launchpad-ops channel by preference | 08:47 |
| vila | lifeless: thx for th info | 08:48 |
| lifeless | vila: it was in flacostes meeting minutes a week or two back | 08:49 |
| vila | lifeless: I don't think I've seen such a thing :-/ | 08:50 |
| lifeless | vila: you may wish to subscribe to the launchpad list[s] - including canonical-launchpad | 08:51 |
| vila | lifeless: just when I was almost keeping up with my flood ? :-/ | 08:51 |
| === Ursinha-brb is now known as Ursinha | ||
| stefanlsd | Hi guys, im doing a UDD merge and it looks like in debian revision they uploaded with a .pc directory. This is problematic now as this quilt stuff is applied. Any advice? | 13:26 |
| jelmer_ | stefanlsd: You might want to ask Barry, he was dealing with this problem earlier as well. | 13:27 |
| === jelmer_ is now known as jelmer | ||
| maxb | stefanlsd: The presence of the .pc in the branch is actually the current standard | 13:31 |
| maxb | It's not a very good standard, IMO, but it's what dpkg-source does | 13:32 |
| jelmer | it'd be great if we could turn those patches into quilt threads or something.. | 13:32 |
| maxb | The storage of the debian patches applied in the branch goes hand-in-hand with using v3 source packages | 13:33 |
| stefanlsd | maxb: my understanding was that its quilt running that generates it. so during debuild for example it will apply, build and then remove it? | 13:33 |
| maxb | quite what you are supposed to do in an UDD merge scenario with the .pc directory is something I'm not really certain, as the only correct option is hideously painful | 13:34 |
| stefanlsd | maxb: well, in this case the .pc directory was introduced by debian a while ago. i removed the .pc directory and doing the merge and build, it fails to apply, as its already applied | 13:35 |
| stefanlsd | maybe i should leave it there and not remove it... (checks) | 13:35 |
| stefanlsd | as a side note - running bzr remerge --weave leaves me with .OTHER.OTHER (running it again gives me) .OTHER.OTHER.OTHER (not sure if this is working as designed...) | 13:36 |
| maxb | Well, the "correct" thing to do would be to leave the .pc directory in place, *including* updating its cached copy of modified upstream files. But that's really messy and breaks the UDD story as being a nice way to merge things | 13:37 |
| maxb | I think some more thought needs to be given to what the UDD importer actually commits to the the import branches for v3 source packages | 13:38 |
| maxb | hmm, I need to grab lunch. afk | 13:39 |
| === exarkun is now known as Guest26742 | ||
| === Guest26742 is now known as exarkun | ||
| === zyga is now known as zyga-lunch | ||
| === yailuj24 is now known as nailuj24 | ||
| === beuno is now known as beuno-lunch | ||
| === zyga is now known as zyga-gone | ||
| === beuno-lunch is now known as beuno | ||
| === elmo_ is now known as elmo | ||
| jam | mgz: if you care, I upgraded to testools 0.9.7 and it gives me a valid unicode failure, which is still odd, but at least it doesn't die. | 19:05 |
| jam | ah, it is failing during the cleanup phase, which is strange, but does explain some of the earlier issues | 19:06 |
| vila | jam: I'm not there anymore but I haven't managed to get in touch with a losa, may be you can ping Chex in #launchpad-ops so we get at least a bit of feedback about testtools on pqm ? | 19:08 |
| jam | vila: k, I haven't seen Chex yet today (I have other questions for him as well). Do you have an rt for it? | 19:09 |
| vila | jam: 41340 the one you commented on | 19:09 |
| GaryvdM | \o/ Graphviz for loggerhead : http://imagebin.ca/img/yJm8tLH.png <-work in progress. | 19:13 |
| jam | GaryvdM: pretty. Though I'd really like it to collapse by default :) | 19:16 |
| GaryvdM | jam: Yes, work in progress. :-) Look at the url - I've manually expanded 428.1.* | 19:17 |
| maxb | Hmm, 0.9.7. ~bzr PPA needs an update | 19:21 |
| gthorslund | morning stewart! | 19:24 |
| mgz | ha, swapped lifeless for jelmer. happiness all round? | 19:27 |
| mgz | jam: goodie. do you want to make the bug about the cleanup failure, or should I redupe it again? | 19:28 |
| jam | mgz: the cleanup failure was already a bug, but I just get a regular traceback now, so feel free to just mark it a dupe | 19:29 |
| mgz | maxb: you might want to not bother till 0.9.8 as 0.9.7 has some platform/version compat issues. | 19:29 |
| maxb | What's the likelyhood of bzr wanting to depend on testtools >= 0.9.4 in the medium-term future, if anyone knows? | 19:29 |
| mgz | jam: cool. what's the number for the cleanup failure? | 19:29 |
| mgz | maxb: https://code.launchpad.net/~gz/bzr/require_testtools_0.9.5_for_selftest/+merge/35144 | 19:29 |
| jam | maxb: AIUI we need 0.9.5 for some unicode failures | 19:29 |
| maxb | Oh. It's just people are talking about updating testtools on bzr's PQM, so I figured an up to date deb would be good | 19:30 |
| jam | so... high but paused waiting for sysadmins to upgrade pqm | 19:30 |
| jam | maxb: I thought there was one? | 19:30 |
| maxb | 0.9.6, not .7 | 19:30 |
| jam | well, >0.9.5 is good, .7 would be nice :) | 19:30 |
| jam | vila: what happened with all of the double mp requests? | 19:32 |
| maxb | lifeless: Are you OK with uploading a newer one to Debian unstable? Once that require_testtools_0.9.5_for_selftest MP lands, we're going to need it to update bzr there | 19:32 |
| jam | lifeless is away today | 19:32 |
| jam | and tomorrow, IIRC | 19:32 |
| maxb | I spy him talking in other channels right now :-) | 19:33 |
| jam | (he may answer anyway, but he is officially on leave) | 19:33 |
| mgz | debian's still in freeze which is a little annoying. | 19:33 |
| maxb | mgz: Are those issues in 0.9.7 you refer to sufficient that bzr's PQM might want to prefer 0.9.6 over 0.9.7? In which case I should *not* update the ~bzr PPA for now | 19:34 |
| GaryvdM | http://imagebin.ca/view/gNbLSX.html - better layout - One of the reasons I love working on graphical things, is it's easy to show others your progress :-) | 19:35 |
| GaryvdM | +colors | 19:35 |
| mgz | possibly not an issue for ubuntu? should be okay for all python versions and the testsuite not running without extra python packages might not hurt. | 19:36 |
| mgz | https://launchpad.net/testtools/+milestone/next <- what's pending. | 19:37 |
| maxb | mm, sounds like a release is needed :-) | 19:39 |
| vila | jam: wrong ordering of my loom threads to start with, then a after-thought about working around lp limitations, then one forgotten push, sry about the noise, the activereviews page looked fine in the end | 20:04 |
| jam | vila: probably, though I primarily review via my email :) | 20:05 |
| vila | jam: long story short: I try to make my proposals easier to review by trying new workflows so I uncover bugs | 20:05 |
| vila | jam: then make sure to start with the latest ones you received and check the pre-requisite branches to review in the right order ;) | 20:06 |
| vila | mgz: Hey ! | 20:13 |
| lifeless | maxb: I think we need a release | 20:24 |
| lifeless | maxb: I've uploaded python-fixtures, its in NEW | 20:24 |
| lifeless | maxb: it would be nice to recommends: that for the next testtools upload. | 20:24 |
| === Ursinha is now known as Ursinha-afk | ||
| === zyga-gone is now known as zyga | ||
| rittyan | Hello. Version is 2.1.0. bzr fast-export gives "Unable load library fastimport". Any ideas on how to make it work? | 21:11 |
| === Ursinha-afk is now known as Ursinha | ||
| rittyan | s/Unable load/Unable to import/ | 21:12 |
| GaryvdM | rittyan: Is this on windows, installed with the standalone installer | 21:15 |
| GaryvdM | ? | 21:15 |
| rittyan | it is on ubuntu, installed via apt-get | 21:15 |
| GaryvdM | rittyan: I did apt-get install bzr-fastimport; bzr fast-export MYBRANCH. It worked fine. From you bzr version, I assume you are on lucid? | 21:21 |
| rittyan | the server is on hardy :-( downloading fresh bzr onto my macosx, then will DL repo and try it on my notebook | 21:21 |
| GaryvdM | Sorry about asking if you use windows :-p - I was working on the windows installer last night, an fastimport is broken, so I jump to conclusions... | 21:23 |
| rittyan | yes that's fine | 21:23 |
| rittyan | I don't find it offending | 21:25 |
| rittyan | more offending is where my current project is, now, but it won't be long (until fastexport is broken in new version too) | 21:25 |
| rittyan | (nvm) | 21:26 |
| GaryvdM | rittyan: What version of bzr-fastimport do you have on the hardy box? | 21:27 |
| rittyan | latest checked out from launchpad | 21:28 |
| GaryvdM | Installed by putting into ~/.bazaar/plugins/? | 21:28 |
| GaryvdM | I think you also need do bzr branch lp:python-fastimport; cd python-fastimport; sudo ./setup.py install | 21:29 |
| GaryvdM | Not 100% sure though. | 21:30 |
| GaryvdM | rittyan: ^ | 21:30 |
| rittyan | I am not sure either | 21:30 |
| maxb | That sounds right to me | 21:30 |
| rittyan | still doesn't work | 21:31 |
| maxb | Alternatively, if you want to not install python-fastimport globally, you can make it work by checking it out to (say) ~/.bazaar/python-fastimport, and creating a tiny bzr plugin that adds it to your python path when running bzr | 21:31 |
| rittyan | to be honest i don't want to pollute my machine | 21:32 |
| rittyan | though i just did and it still doesn't work, ok | 21:32 |
| rittyan | will try locally when dl will finish | 21:32 |
| maxb | Me too. The way I install extra libraries for bzr plugins is to have a ~/.bazaar/plugins/AAAuselibs.py file which contains import sys; sys.path.insert(0, '/path/to/extra/libs') | 21:33 |
| rittyan | my 20mbit provider is down again so i am using gprs, extra$ for speed slower than staying still :( | 21:33 |
| rittyan | 8 min left | 21:33 |
| poolie | hi jam, all | 22:23 |
| jam | hi poolie | 22:23 |
| poolie | i was actually online, but on the phone etc | 22:23 |
| poolie | how was your day? | 22:23 |
| jam | poolie: pretty good | 22:24 |
| jam | still waiting on movement from a l-osa | 22:24 |
| jam | but I guess they had some critical launchpad regressions etc | 22:24 |
| jam | found a memory structure that I'm happy with for the groupcompress packing code | 22:24 |
| poolie | waiting for movement as far as getting the server started? | 22:35 |
| jam | right | 22:36 |
| jam | I need one of them to start it, and update the production configs so I can actually test it | 22:36 |
| poolie | well, keep pushing i guess | 22:39 |
| kiko | found this in an internal linaro wikipage comment from an engineer "* bzr doesn't like long (>1GB) checkouts - need to fetch in chunks (bzr get -r number)" | 22:41 |
| kiko | that's pretty weird -- is it possibly true though? | 22:41 |
| james_w | kiko, if it is interrupted you have to start from the beginning, using the incremental approach avoids that problem. That may be what they are referring to | 22:43 |
| kiko | james_w, I think it was a perf issue though -- it's davidgiluk's page | 22:43 |
| james_w | kiko, also possible, but I haven't really heard reports of that | 22:44 |
| jam | kiko: also depends how you define "doesn't like". You can checkout 'bzr lp:qtwebkit' which is about 1.7GB, but we'll use about 1GB+ of RAM to do so. | 22:45 |
| kiko | jam, I think that's a good definition of "doesn't like" :) | 22:46 |
| kiko | jam, does this get better soon? :) | 22:46 |
| jam | kiko: no current focus on pushing the peak memory down. 2.2 is about 2-3x better than 2.0 in this regard, but I haven't come back to address it again | 22:47 |
| jam | (iow, 2.0 would take more like 2+GB to copy it) | 22:47 |
| kiko | jam, okay, thanks. tough for people working on gcc-linaro, just that | 22:47 |
| kiko | but I guess I can buy them more ram as a gift ;) | 22:47 |
| mkanat | kiko: It also may be that they're using a 32-bit OS. | 22:54 |
| mkanat | kiko: So they can't address more than 2GB per process. | 22:54 |
| mwhudson | kiko: it's a bug in the ssh server we use | 22:54 |
| mwhudson | STOP SPECULATING EVERYONE | 22:55 |
| mwhudson | :-) | 22:55 |
| wam | I'm googling for about 2 hours now. How can I integrate/use bzr smart server so that I can commit/push to it? I'd like to use redmine and the repository on the redmine server. I think, redmine has nothing to do with it, because all I need is a smartserver that authenticates against sql. Any hints or URLs? | 22:55 |
| mkanat | wam: You could just use SSH and have some PAM module do the authentication. | 22:56 |
| wam | mkanat: then I have shell access for every user, righ? | 22:56 |
| kiko | mwhudson, oh really? | 22:56 |
| kiko | mkanat! | 22:56 |
| mwhudson | kiko: yes | 22:56 |
| kiko | mwhudson, what's the fix? :) | 22:56 |
| mkanat | Hey kiko! | 22:56 |
| mwhudson | kiko: hard :( http://twistedmatrix.com/trac/ticket/4395 | 22:56 |
| mkanat | wam: You don't have to--you could make "bzr serve" their shell. | 22:57 |
| mkanat | wam: Or something like that. We do something like that for bzr.mozilla.org. | 22:57 |
| wam | mkanat: sounds promising. Do you have any docs for that or should I just read the help? | 22:58 |
| mkanat | wam: I don't have any docs personally on the Mozilla setup, no. | 22:58 |
| kiko | mwhudson, why does that kick in when the checkout is over 1gb? | 22:59 |
| mwhudson | kiko: because the openssh client by default rekeys the connection after 1 gig of traffic | 22:59 |
| kiko | gotcha | 22:59 |
| mkanat | kiko: So they could do their checkouts over bzr:// if they have it. | 23:00 |
| mwhudson | it's launchpad, so that'd be a no | 23:00 |
| mkanat | mwhudson: Ahh. | 23:01 |
| kiko | indeed | 23:02 |
| kiko | mwhudson, can we contract somebody to fix the issue? | 23:03 |
| kiko | i.e. please :) | 23:03 |
| kiko | I want to avoid any additional bad press we get because of all things a bug in CONCH!! | 23:03 |
| kiko | (who's ousado btw) | 23:03 |
| mwhudson | kiko: probably | 23:05 |
| GaryvdM | mkanat: I made some good progress on adding graphviz to loggerhead: http://imagebin.ca/view/gNbLSX.html | 23:05 |
| kiko | mwhudson, how can I help get that ball rolling? | 23:05 |
| mwhudson | kiko: i could probably fix it given enough time so you could try going through the infrastructure process | 23:05 |
| kiko | mwhudson, I'd rather we contracted somebody else, you're too expensive | 23:06 |
| mkanat | GaryvdM: Hey, that looks pretty awesome! | 23:06 |
| kiko | GaryvdM, hah, that looks so cool | 23:06 |
| mkanat | GaryvdM: Are you just going to make it an option of the normal changes controller? | 23:06 |
| mwhudson | GaryvdM: cool | 23:07 |
| GaryvdM | mkanat: At the moment I have made a new controller, but I don't mind either way. | 23:07 |
| GaryvdM | Good night all. | 23:09 |
| mkanat | GaryvdM: Night! | 23:10 |
| poolie | mwhudson: we should mention the bzr lp bug there | 23:14 |
| poolie | hi kiko, mkanat | 23:14 |
| mkanat | Hey poolie. | 23:15 |
| mwhudson | poolie: yes, i guess so | 23:15 |
| poolie | kiko: so would this be your top item for linaro/udd/bzr? | 23:17 |
| kiko | poolie, well, linaro uses bzr heavily for gcc, and whatever causes problems for them I need to pay attention to, as it hasn't been a decision without detractors | 23:20 |
| kiko | poolie, I'd be happy to help pay for a contract to get that bug fixed and rolled out | 23:20 |
| poolie | k, thanks for raising ti | 23:22 |
| poolie | *it | 23:22 |
| kiko | poolie, cool, keep me posted on any progress | 23:23 |
| poolie | mwhudson, jml, do we know any obvious contractors to do it? i could just ask in #twisted... | 23:23 |
| jml | poolie: exarkun. | 23:24 |
| * poolie looks for the lp bug | 23:25 | |
| mwhudson | poolie: i'm not sure there is an lp bug, in fact | 23:28 |
| poolie | bug 556132 | 23:37 |
| ubot5 | Launchpad bug 556132 in Launchpad Bazaar Integration "bzr: ERROR: paramiko.SSHException: (affected: 1, heat: 1)" [Medium,Triaged] https://launchpad.net/bugs/556132 | 23:37 |
| poolie | mkanat: hi? | 23:55 |
| mkanat | poolie: hi | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
