[00:56]  * spiv is reviewing https://code.launchpad.net/~maxb/bzr/2.2-close-ssh-subprocess-socket/+merge/40493
[01:03] <maxb> thanks :-)
[02:32] <dcoles_> Should all version 2 merge directives have a target_branch inside the header of the merge directive?
[02:33] <dcoles_> Just about to open a bug since Bazaar crashes when the target_branch is missing.
[02:37] <spiv> dcoles_: if it's a crash that produces a traceback, then it's definitely a bug even if that's not valid
[02:39] <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:41] <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:42] <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:43] <dcoles_> target_branch: file:///home/dcoles/Documents/Projects/plagiarism\
[02:43] <dcoles_> Whoops.
[02:44] <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:45] <dcoles_> Aye. That might have been the cause. His version of bazaar must have just dropped the location.
[02:47] <spiv> Is there any particular reason that bug report is private?
[02:49] <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:50] <spiv> I should have asked, do you mind if we make that report public? :)
[02:51] <dcoles_> Yeah. It's fine. I just un-privated it myself.
[02:51] <dcoles_> Looks like nothing but Python and Bazaar stuff.
[02:56] <dcoles_> ... And Google has already indexed the bug...
[03:03] <dcoles_> Seems to have gone AWOL in the current docs, but http://doc.bazaar.canonical.com/bzr.2.0rc2-html/developers/bundle-format4.html
[05:20] <GaryvdM> Morning
[05:22] <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:25] <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:32] <spiv> poolie: the problem is I'd feel compelled to dust off my half-done patches for it first ;)
[05:33] <poolie> this is a problem? :)
[05:33] <spiv> Not in the long run :)
=== jfroy_ is now known as jfroy
[06:36] <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:40] <GaryvdM> Ah - apps.branch.BranchWSGIApp.controllers_dict
[07:06] <mkanat> GaryvdM: I'm a loggerhead guy if you have other general questions.
[07:08] <GaryvdM> mkanat: I'm want to try use my loggraphviz code from qlog in loggerhead
[07:09] <mkanat> GaryvdM: Okay. That does a dot graph of revisions, or something?
[07:11] <GaryvdM> mkanat: Yes - a graph visualisation, but it does no use dot format. -  screen shot: http://qbzr.googlegroups.com/web/gtk_qlog.png
[07:12] <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:13] <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:14] <mkanat> GaryvdM: Ah, we already have a revision graph cache.
[07:14] <mkanat> GaryvdM: It's in loggerhead.history, as I recall.
[07:16] <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:17] <mkanat> GaryvdM: The History object only lasts one request, but the actual graph cache is the lru_cache.
[07:18] <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:19] <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:20] <poolie> that would be good
[07:21] <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:22] <poolie> you could perhaps just forward that to launchpad-dev?
[07:22] <poolie> oops, got to go, may be back tonight
[07:23] <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:24] <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:25] <GaryvdM> mkanat: Sure - That why I'm trying to get a good understanding of the existing infrastructure first.
[07:26] <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:27] <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:28] <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:32] <lifeless> if you want details ;)
[07:32] <lifeless> the driver for the work so far was being able to do no downtime deployments
[07:35] <mkanat> lifeless: Ah, okay.
=== lamont` is now known as lamont
[07:39] <mkanat> lifeless: I'll ask spm if there have still been any stability issues.
[07:39] <vila> hi all !
[07:41] <vila> ping LOSA, can we have some feedback (or even better a fix) about rt #41340
[08:28] <Sakura13> any german out there?
[08:47] <lifeless> vila: the losas have asked that we ping on the internal launchpad-ops channel by preference
[08:48] <vila> lifeless: thx for th info
[08:49] <lifeless> vila: it was in flacostes meeting minutes a week or two back
[08:50] <vila> lifeless: I don't think I've seen such a thing :-/
[08:51] <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 ? :-/
=== Ursinha-brb is now known as Ursinha
[13:26] <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:27] <jelmer_> stefanlsd: You might want to ask Barry, he was dealing with this problem earlier as well.
=== jelmer_ is now known as jelmer
[13:31] <maxb> stefanlsd: The presence of the .pc in the branch is actually the current standard
[13:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <maxb> hmm, I need to grab lunch. afk
=== 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
[19:05] <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:06] <jam> ah, it is failing during the cleanup phase, which is strange, but does explain some of the earlier issues
[19:08] <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:09] <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:13] <GaryvdM> \o/ Graphviz for loggerhead : http://imagebin.ca/img/yJm8tLH.png  <-work in progress.
[19:16] <jam> GaryvdM: pretty. Though I'd really like it to collapse by default :)
[19:17] <GaryvdM> jam: Yes, work in progress. :-) Look at the url - I've manually expanded 428.1.*
[19:21] <maxb> Hmm, 0.9.7. ~bzr PPA needs an update
[19:24] <gthorslund> morning stewart!
[19:27] <mgz> ha, swapped lifeless for jelmer. happiness all round?
[19:28] <mgz> jam: goodie. do you want to make the bug about the cleanup failure, or should I redupe it again?
[19:29] <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:30] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <mgz> https://launchpad.net/testtools/+milestone/next <- what's pending.
[19:39] <maxb> mm, sounds like a release is needed :-)
[20:04] <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:05] <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:06] <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:13] <vila> mgz: Hey !
[20:24] <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.
=== Ursinha is now known as Ursinha-afk
=== zyga-gone is now known as zyga
[21:11] <rittyan> Hello. Version is 2.1.0. bzr fast-export gives "Unable load library fastimport". Any ideas on how to make it work?
=== Ursinha-afk is now known as Ursinha
[21:12] <rittyan> s/Unable load/Unable to import/
[21:15] <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:21] <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:23] <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:25] <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:26] <rittyan> (nvm)
[21:27] <GaryvdM> rittyan: What version of bzr-fastimport do you have on the hardy box?
[21:28] <rittyan> latest checked out from launchpad
[21:28] <GaryvdM> Installed by putting into ~/.bazaar/plugins/?
[21:29] <GaryvdM> I think you also need do bzr branch lp:python-fastimport; cd python-fastimport; sudo ./setup.py install
[21:30] <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:31] <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:32] <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:33] <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
[22:23] <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:24] <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:35] <poolie> waiting for movement as far as getting the server started?
[22:36] <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:39] <poolie> well, keep pushing i guess
[22:41] <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:43] <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:44] <james_w> kiko, also possible, but I haven't really heard reports of that
[22:45] <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:46] <kiko> jam, I think that's a good definition of "doesn't like" :)
[22:46] <kiko> jam, does this get better soon? :)
[22:47] <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:54] <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:55] <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:56] <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:57] <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:58] <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:59] <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
[23:00] <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:01] <mkanat> mwhudson: Ahh.
[23:02] <kiko> indeed
[23:03] <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:05] <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:06] <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:07] <mwhudson> GaryvdM: cool
[23:07] <GaryvdM> mkanat: At the moment I have made a new controller, but I don't mind either way.
[23:09] <GaryvdM> Good night all.
[23:10] <mkanat> GaryvdM: Night!
[23:14] <poolie> mwhudson: we should mention the bzr lp bug there
[23:14] <poolie> hi kiko, mkanat
[23:15] <mkanat> Hey poolie.
[23:15] <mwhudson> poolie: yes, i guess so
[23:17] <poolie> kiko: so would this be your top item for linaro/udd/bzr?
[23:20] <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:22] <poolie> k, thanks for raising ti
[23:22] <poolie> *it
[23:23] <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:24] <jml> poolie: exarkun.
[23:25]  * poolie looks for the lp bug
[23:28] <mwhudson> poolie: i'm not sure there is an lp bug, in fact
[23:37] <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:55] <poolie> mkanat: hi?
[23:58] <mkanat> poolie: hi