[01:32] <lifeless> mkanat: hi
[01:32] <mkanat> lifeless: Hello.
[01:32] <lifeless> mkanat: do you know if we've deployed your fix for https://bugs.launchpad.net/loggerhead/+bug/643497 yet ?
[01:33] <mkanat> lifeless: I've never seen that bug before.
[01:33] <mkanat> lifeless: Oh wait.
[01:33] <mkanat> lifeless: Yes, you have deployed that.
[01:33] <mkanat> lifeless: That is a dup.
=== Ursinha is now known as Ursinha-afk
[04:11] <lifeless> spm: ping
[04:11] <lifeless> spm: is it possible that nagios etc are generating 7K requests a day per loggerhead instance?
[04:11] <lifeless> spm: including direct, and via ha proxy and via apache
[04:18] <poolie> ok, out for a bit
[04:54] <spm> lifeless: not that I'm seeing - I did a grep on check_http on prod-1, and only saw ~ 15 an hour. Tho ... now the brain engages, we have two. behind a haproxy. which does it's own separate check. betcha dollars to peso's....
[05:14] <AfC> Gotta love proxies. "Yes, the web site is responding. And rapidly at that!" "With what?" "Dunno. Does 404 mean anything to you?"
[06:27] <chx> how can i see changes made in a branch, no merges?
[06:38] <AfC> $ bzr status --no-pending
[06:45] <chx> AfC: i mean, the already committed changes to the branch
[06:45] <chx> AfC: log shows the branch the commit "branch nick" and whether it's a merge or not, i juts want a cumulative diff for the commits to the current branch , no merges.
[06:48] <AfC> $ bzr diff -r -2..-1
[06:48] <chx> ahhhh
[06:48] <chx> ancestor:
[06:48] <chx> gotcha!
[06:48] <AfC> Oh. You're asking about relative to _another_ branch. You didn't say that.
[06:48] <AfC> Yes, ancestor:../mainline (or whatever) is very useful indeed
[06:49] <chx> mmm beautiful
[06:49]  * chx staples the diff to a pink slip and mails to his boss
[06:49] <chx> just as i thought...
[06:50] <chx> very useful indeed.
[07:05] <jelmer> good morning #bzr
=== GaryvdM_away is now known as GaryvdM_work
[07:25] <GaryvdM_work> chx: also, if you have a submit branch set, submit: is a short cut for ancestor:<path to submit>
[07:48] <vila> GaryvdM_work: http://paste.ubuntu.com/559415/ (sorry I forgot to mail this yesterday)
[07:49] <vila> goooood morning jelmer !
[07:51] <chx> GaryvdM_work: good to know. next time i need to fire a developer based on his (non) work i can use that :D
[08:00] <GaryvdM_work> vila: thanks - My suspicion  was wrong, but I now have a better idea where to look.
[08:00] <vila> GaryvdM_work: excellent !
[08:01] <vila> GaryvdM_work: feel free to poke me at anytime if you want more tests, I know how hard it is to debug something any mean to reproduce and this one seem like a damn stealth bug
[08:01] <vila> poolie: hey !
[08:01] <GaryvdM_work> vila: did you sleep well?
[08:01] <vila> GaryvdM_work: I *slep* which is a huge progress :D
[08:02] <vila> slept, rats
[08:02] <vila> I still feel a bit like crap, but that's at 8pm instead of 11 or 12...
[08:03] <vila> poolie: well done with the kanban stuff, I just found a bug that I forgot to mark fixed released !
[08:04] <vila> poolie: the card give links for both the bug and the branch ! Awesome !
[08:05] <vila> poolie: when are the pages updated ?
[08:19] <jelmer> hi vila, poolie, Gary!
[08:19] <GaryvdM_work> Hi jelmer
[08:20] <vila> maxb: any update about SRU/MRE for 2.2.3 ?
[08:22] <maxb> update?
[08:23] <vila> maxb: what is left to be done, where are we ?
[08:24] <vila> lp:~maxb/ubuntu/maverick/bzr/sru/ doesn't include 2.2.3 and
[08:24] <maxb> I don't think anyone has tackled updating the packaging for 2.2.3 yet. I could look into that over the weekend
[08:25] <vila> lp:ubuntu/maverick/bzr/ is still at 2.2.0
[08:25] <vila> maxb: that would be awesome
[08:25] <mgz> morning all.
[08:25] <jelmer> hi mgz
[08:25] <vila> maxb: tell me if I can help here
[08:25] <vila> hi mgz
[08:26] <maxb> NB lucid is in SRU freeze at the moment
[08:27] <maxb> Although we somehow seem to have not started discussing SRUing lucid, even though it's the LTS
[08:27] <vila> maxb: from your explanations I thought we should start with maverick
[08:28] <poolie> hi vila, jelmer, gary, maxb
[08:28] <vila> maxb: which is 2.2 and that's the one I mostly interested in, lucid is only at 2.1
[08:28] <poolie> vila, at the moment i built the kanban on my laptop and uploaded it
[08:28] <maxb> Well, we need to include maverick, certainly
[08:28] <poolie> i might see about running it somewhere more central
[08:28] <poolie> let's say roughly daily for now
[08:29] <vila> poolie: daily is fine by me to start with but if we can target hourly it will be better in the long run
[08:29] <GaryvdM_work> Hi poolie, maxb, mgz!
[08:29] <maxb> Lucid is going to need a SRU sooner or later to clear up those pesky references to the LP beta API that got left in
[08:29] <maxb> Because the LP beta API is supposed to expire on the death of Karmic
[08:30] <vila> maxb: sure, I'm forgetting lucid, but I'd like maverick first
[08:30] <vila> meh
[08:30] <maxb> (i.e. in three months)
[08:30] <vila> I'm *not* forgetting
[08:31] <vila> maxb: And I'm not *that* concerned about LP beta API, there are other clients and I suspect LP will have to take them into account even after we manage the lucid SRU
[08:31] <maxb> mm
[08:31] <maxb> https://launchpad.net/+apidoc/
[08:32] <maxb> Warning has been given
[08:32] <vila> maxb: I've landed the relevant patches on all releases for bzr, *we* are ready
[08:32] <poolie> vila, i'd just need to get the dependencies installed on devpad or whatever
[08:32] <poolie> at the moment it is staff-only
[08:32] <maxb> oh - neat
[08:32] <poolie> it might be better off public, if we omitted private bugs
[08:32] <maxb> right, byebye, I should go to the office now
[08:33] <vila> maxb: enjoy !
[08:33] <poolie> jelmer, are you back at work today or just saying hi?
[08:33]  * vila set mode +just_say_hi
[08:33] <vila> :)
[08:34] <jelmer> poolie: I'm back at work
[08:34] <poolie> vila, really all references to beta are gone? just recently?
[08:35] <poolie> welcome back; i wondered if you would help vila push our srus through?
[08:35] <poolie> also, i'm going to the developer membership board on monday evening utc to ask for ppu for bzr
[08:35] <poolie> maybe you should too?
[08:35] <vila> poolie: yes, but we may need to cut releases for 2.1 and 2.0,
[08:36] <vila> poolie: but 2.2 first
[08:36] <jelmer> poolie, vila: Sure, I'd be happy to
[08:37] <poolie> vila, bzr.2.2 in bzrlib/plugins/lp_api still has hardcoded urls for the beta service root
[08:37] <poolie> they probably shouldn't be hardcoded at all but they may predate lplib facilities to get them
[08:37] <vila> meh, for 2.2.3 ?
[08:37] <poolie> in 2.2 tip
[08:38] <vila> haaaaa beta not edge !
[08:38] <vila> maxb: ^ I was wrong
[08:38] <poolie> yes, there are two similar but different things
[08:38] <poolie> edge, and beta
[08:38] <poolie> edge is a bit more urgent
[08:39] <vila> edge is done
[08:40] <poolie> there's a separate bug about beta
[08:40] <vila> hmm, and I suspect we have no tests about whether we use 1.0 supported features :-/
[08:40] <poolie> hm
[08:41] <poolie> i don't think we have any tests about interaction with lp
[08:41] <poolie> which would be the main way to catch it
[08:41] <vila> <shudder/>
[08:41] <poolie> in theory you can statically check against the wadl, but not so easily in python, or with the approach lplib takes
[08:43] <vila> poolie: The more I think about it, the more I feel the launchpad plugin should not be in core but part of launchpad itself
[08:44] <vila> poolie: this way we could stop worrying about 1) testing it properly 2) being compatible with launchpad
[08:46] <vila> poolie: we will still package it in our installers and other packagers should be warned to do it too if/when we switch
[08:48] <poolie> mm
[08:48] <poolie> we still need to work out how to test it
[08:48] <poolie> but it does create some special cases by being in the tree and yet a plugin
[08:49] <poolie> i would probably test it by having an environment variable giving the service root to test against
[08:49] <poolie> and making the tests skip if that's not set
[08:50] <vila> poolie: so lp devs can test it properly ? Sounds fine to me and could even be set on babune if/when I manage to run a local lp vm
[08:51] <vila> but that's still significantly more work for me than for an lp dev
[08:54] <poolie> anyone who changes the plugin code, or things it relies on, needs to test it
[08:54] <poolie> if we use a variable, they can test it either locally or against staging
[08:54] <poolie> if it makes minimal assumptions about what will be in the instance
[09:06] <GaryvdM_work> vila: how long does it take for you to run the whole test suit?
[09:06] <vila> GaryvdM_work: < 10 minutes with ---parallel=fork
[09:07] <vila> poolie: meh, where are you :(
[09:07] <jelmer> vila: is there a bug # for the SRU?
[09:08] <GaryvdM_work> vila: Is there a way to run the test suit across multiple computers?
[09:08] <GaryvdM_work> --parallel=cluster :-)
[09:08] <vila> jelmer: bug #687653 will be a good candidate for 2.2.3
[09:08] <ubot5> Launchpad bug 687653 in Launchpad itself "infinite recursion trying to format NotBranchError" [Critical,Fix released] https://launchpad.net/bugs/687653
[09:09] <vila> GaryvdM_work: there is a plugin for that named ec2 something
[09:09] <GaryvdM_work> Oh - cool
[09:12] <vila> GaryvdM_work: without plugins it's ~5 minutes
[09:29] <GaryvdM_work> vila: cool - I have managed to reproduce
[09:38] <vila> GaryvdM_work: cool !
[10:36] <jelmer> vila: I've pushed a branch to lp:~jelmer/ubuntu/maverick/bzr/proposed-2.2.3
[10:37] <vila> jelmer: rock&roll
[10:38] <vila> branching
[10:45] <vila> jelmer: the test were run and passed during build right ?
[10:47] <jelmer> they should have been, but the package did build fairly quickly. Let me double check
[10:47] <vila> debian/rules contains a selftest invocation at least
[10:59] <vila> jelmer: regarding bug #704647 does  http://paste.ubuntu.com/559471/ looks correct to you ?
[10:59] <ubot5> Launchpad bug 704647 in Ubuntu Distributed Development "lp-propose default target doesn't work for packaging branches" [High,Fix released] https://launchpad.net/bugs/704647
[11:00] <vila> jelmer: I needed it to lp-propose a bug branch
[11:00] <vila> jelmer: i.e. not related to  a packaging branch
[11:01] <vila> jelmer: and should I attribute the lag since your 'Let me double-check' as an indication that something went wrong ?
[11:03]  * jelmer looks
[11:04] <jelmer> vila: no, I'm waiting for the package to build
[11:04] <jelmer> vila: +1 on that patch
[11:04] <vila> ha good, not so fast then ;)
[11:05] <vila> jelmer: ok, I'll make a proposal for it then
[11:06] <vila> jelmer: I'll take your branch as a base to see if you added tests for it (unlikely as it seems to be closely tight to lp anyway :-/)
[11:06] <jelmer> vila: no, there aren't any tests for this code unfortunately :-/
[11:06] <vila> jelmer: np
[11:13] <vila> jelmer: https://code.launchpad.net/~vila/bzr/704647-lp-propose/+merge/47790
[11:14] <jelmer> vila: +1, thanks!
[11:14] <jelmer> heh, we voted Approve within 3 seconds of each other :-)
[11:14] <vila> jelmer: my pleasure
[11:14] <vila> hehe
[11:15] <vila> but I sent it to pqm first !
[11:16] <jelmer> :)
=== oubiwann_ is now known as oubiwann
[14:04] <vila> GaryvdM_work: any news ?
[14:04] <vila> jelmer: any news ?
[14:04]  * vila sets mode +any_news
[14:05] <jelmer> vila: what kind of news are you looking for?
[14:06] <vila> jelmer: the test were run and passed during build right ?
[14:10] <vila> jelmer: I'm waiting for your feedback to nominate bug #687653 for SRU
[14:10] <ubot5> Launchpad bug 687653 in Launchpad itself "infinite recursion trying to format NotBranchError" [Critical,Fix released] https://launchpad.net/bugs/687653
[14:10] <vila> jelmer: or did I misunderstood something ?
[14:11] <jelmer> vila: yeah, that's a good one for the SRU
[14:11] <jelmer> garr, looks like I should enable swap on my laptop again.. it goes bonkers without it
[14:12] <vila> jelmer: I want to say that the tests passed during build, hence my question :)
[14:12] <vila> jelmer: buy a real desktop ;)
[14:19] <jelmer> vila: I've got one.. it's just not the machine I was running the tests on :-)
[14:20] <vila> oooh, you mean the build is still running ?
[14:50] <jelmer> vila: looks like there was actually one failing test
[14:50] <vila> which one ?
[14:50] <jelmer> vila: the packaging required 'test' to be specified in DEB_BUILD_OPTIONS, it didn't enable them by default. I've fixed that now, too.
[14:51] <jelmer> vila: the test_locale issue we fixed last week. I'm cherrypicking the fix.
[14:51] <vila> jelmer: you rock, don't forget to fire a mp for lp:bzr/2.3 too
[15:02] <vila> good morning jam !
[15:05] <jelmer> hi John!
[15:19] <jam> hi vila
[15:19] <jam> and jelmer
=== deryck is now known as deryck[lunch]
[15:44] <jam> Peng: if you're around, I had a loggerhead Q for you
=== beuno is now known as beuno-lunch
=== mm-mysql_ is now known as mm-mysql
[16:03] <exarkun> http://buildbot.twistedmatrix.com/builders/lucid32-py2.6-select/builds/513/steps/bzr/logs/stdio
[16:03] <exarkun> I dunno if that's the same basic problem as https://bugs.launchpad.net/bzr/+bug/701940 or not.  It happened in the same place under (one supposes) roughly the same circumstances.
[16:04] <exarkun> It looks kind of similar, in that the error seems to be about a missing .pack file.  But it's not reported /exactly/ the same way.
[16:04] <jelmer> bug 701940
[16:04] <ubot5> Launchpad bug 701940 in Bazaar "Pack moved to obsolete_packs, but still referenced in pack-names" [High,In progress] https://launchpad.net/bugs/701940
=== Ursinha is now known as Ursinha-lunch\
=== Ursinha-lunch\ is now known as Ursinha-lunch
[16:20] <vila> exarkun: what bzr version are you using, this bug is fixed in 2.2.3 (released), 2.3.0 (unreleased) and trunk
[16:21] <exarkun> vila: I'm using 2.2.3
[16:22] <exarkun> The one packaged for lucid in http://ppa.launchpad.net/bzr/ubuntu/
[16:23] <vila> that's bad :( File a new bug mentioning 701940
[16:23] <exarkun> okay, will do
[16:24] <vila> IIUI, issuinga 'bzr pack' locally should work around the problem
[16:25] <vila> the weird thing is that it occurs on a buildbot instance which should do commits by itself, only pulls no ? Ha, wait, there may be concurrent pulls there..
[16:25] <vila> s/issuinga/issuing a/
[16:25] <vila> s/should do/shouldn't do/
[16:26] <exarkun> vila: Yes, it is concurrent.
[16:27] <vila> exarkun: 'bzr pack' during happy hours :-}
[16:27] <vila> and definitely file a bug
[16:28] <vila> exarkun: no-on is pushing there with a different bzr version right ?
[16:28] <exarkun> right
[16:28] <exarkun> it's only pulls
[16:37] <vila> exarkun: so forcing 'bzr pack' should reduce the occurrence of the bug
[16:38] <exarkun> vila: Once?  Once in a while?  Before any pull?
[16:38] <vila> exarkun: well, depends on how often it occurs, *between* the pulls if there is such a time slice
[16:39] <exarkun> This is the first time I've seen it happen, over probably about a month of operation.
=== deryck[lunch] is now known as deryck
[16:39] <exarkun> But that probably just means a hidden variable suddenly changed and the probability when from ~0% to ~100%
[16:40] <vila> or two pulls were identical ?
[16:40] <exarkun> They're probably usually identical, I guess
[16:41] <jelmer> that's what the other bug was related to, too
[16:41] <exarkun> There's two builders on the machine using a shared repository
[16:41] <exarkun> So when a build is triggered they both probably try to pull exactly the same thing into it
[16:41] <vila> a more drastic workaround would be to use one shared repo by builder until the bug is fixed :-/
[16:42] <exarkun> if it turns out to happen with much frequency, I'll probably do that
[16:42] <exarkun> if not, I'd rather leave it in this configuration and keep reporting bugs :p
[16:42] <exarkun> someday it will have to work right, right?
[16:42] <vila> exarkun: that's more valuable for us :) Yeah, definitely
[16:43] <vila> mention that in the bug too (2 builders probably pulling the same revisions) that may help
=== oubiwann is now known as oubiwann_
[16:43] <exarkun> okay
[16:50] <exarkun> vila: 'bzr pack' doesn't look like it can deal with the state the repository is in now, though
[16:50] <exarkun> Maybe you didn't mean that it would fix the state, just that it would help after I manually fix the state
[16:50] <vila> yup
[16:51] <vila> exarkun: do you need help to fix the state ?
[16:53] <exarkun> I think it's fixed, I moved the .pack from obsolete_packs into packs and the other files into indices
[16:53] <exarkun> And then 'bzr pack' worked
[16:53] <vila> perfect thne
[16:53] <exarkun> and filed bug 709349
[16:53] <ubot5> Launchpad bug 709349 in Bazaar "bzr: ERROR: bzrlib.errors.RetryWithNewPacks: Unprintable exception RetryWithNewPacks" [Undecided,New] https://launchpad.net/bugs/709349
[16:54] <vila> oh ! didn't link the nick and the lp login name :)
[16:57] <exarkun> :)
=== beuno-lunch is now known as beuno
[17:09] <vila> jelmer: can I nominate the bug for the sru now ?
[17:19] <jelmer> vila: tests *still* running
[17:19] <vila> jelmer: oh my...
[17:20] <vila> . o O (Who said "a laptop is good enough for bzr dev" :-)
[17:25] <jelmer> hehe
[17:26] <jelmer> vila: it's passed
[17:26] <jelmer> vila: ... and I've pushed
[17:27] <vila> cool, thanks a lot, I should really do this myself, I'll look at your branch anyway
[17:39] <maxb> My laptop is good enough for bzr dev :-)
[17:40] <jelmer> argh, python 2.7 has broken bzrtools
[17:40] <jelmer> "ReadError: empty header" from bzrtools
[17:40] <jelmer> 'evening max
[17:44] <maxb> jelmer: yeah, I think I filed that bug already
[17:44] <maxb> bug 708268
[17:44] <ubot5> Launchpad bug 708268 in BzrTools "bzrtools testsuite has python 2.7 incompatibility" [Undecided,New] https://launchpad.net/bugs/708268
[17:49] <kire> any ideas if bzr 2.3 will get to lenny backports (I am currently unable to install a decent ubuntu release on my server)?
[17:50] <jelmer> kire: please request a backport using the normal channels
[17:50] <kire> okay
[17:56] <maxb> kire: The standard debian backports rules prevent it being updated until squeeze releases and testing thaws
[17:59] <vila> Soo, I have a jubany VM, with a first package tracking its depedencies (ouch, based on hardy so bzr-2.1.1 so far)
[17:59] <jelmer> maxb: of course, squeeze should be out soon. before 2.3 hopefully (or is that too hopeful?)
[17:59] <maxb> I tend to the cautious where Debian stable is concerned
[18:01] <vila> maxb: by the way, bug #687653 has been nominated for the 2.2.3 sru, thanks to jelmer providing a branch
[18:01] <ubot5> Launchpad bug 687653 in bzr (Ubuntu) "infinite recursion trying to format NotBranchError" [Undecided,New] https://launchpad.net/bugs/687653
[18:01] <jelmer> abentley: hi
[18:02] <vila> I wasn't able to create to nominate for maverick, some weird lp backtrace about not being owner and as such lacking permissions
[18:02] <vila> s/to create//
[18:02] <abentley> jelmer, hi.
[18:03] <jelmer> abentley: bzrtools' tests/upstream_import.py has some strange code that appends more data to a tarfile that is already present
[18:03] <jelmer> (around line 125)
[18:04] <abentley> jelmer, is this related to the 2.7 incompatibility?
[18:04] <jelmer> abentley: Removing that code unbreaks bzrtools' tests on python2.7, but I wonder why it's there in the first place.
[18:04] <kire> maxb, thanks (and of course i meant 2.2.3, not 2.3 but my question is answered anyway :))
[18:04] <jelmer> abentley: yep
[18:05] <abentley> jelmer, I don't know the answer right away, and I'm taking the rest of the day off for a trip.  I'll look into it, though.
[18:05] <jelmer> abentley: thanks, no hurry
[18:14] <vila> Oh, for the record, the vm use a 32GB HDD but the package importer currently uses ~90GB. Most of it being logs, debug files and maybe some working trees that could be re-created
=== Ursinha-lunch is now known as Ursinha
=== oubiwann_ is now known as oubiwann
=== oubiwann is now known as oubiwann_
[22:16] <Peng> jam: Obviously, i wasn't around. :P Feel free to ask me anything, but I may or may not know the answer.
[22:17] <jam> Peng: did you see the discussion about the launchpad team taking stewardship for loggerhead?
[22:17] <jam> (I think most of the *discussion* took place on launchpad-dev, but some summary stuff showed up on bazaar@)
[22:18] <Peng> jam: No. I've been doing an even worse job reading my email than following bzr/lh/lp. :P
[22:18] <Peng> I think someone mentioned it here a week ago, though?
[22:19] <jam> Peng: anyway, Launchpad is trying to take more direct responsibility for code they rely on, loggerhead being one of those things
[22:19] <jam> at the same time, loggerhead "trunk" is not 100% ready to be just deployed on launchpad
[22:19] <jam> so they wanted to move it 'to the side' as a future-work branch
[22:19] <jam> I didn't know how much that would specifically affect you, since you've run some bleeding edge loggerhead stuff
[22:20] <Peng> Ergh, I'm not awake yet... And like I said, I've fallen out of bzr/lh/lp.
[22:21] <Peng> Why isn't LH trunk usable for LP? Because it's, well, a not-always-stable trunk branch?
[22:22] <Peng> jam: Thanks for the heads-up. I'll dig into the list archives today.
=== Ursinha is now known as Ursinha-afk
[22:24] <jam> Peng: not-always-stable, and without tweaking the launchpad side of things, history-db is an initial perf regression
[22:25] <jam> (once caches are filled, it is generally a big win, but the first load is slower than the existing code)
=== Ursinha-afk is now known as Ursinha
[22:27] <jam> Peng: looking at it, the launchpad branch of loggerhead also has some site-specific customization. But the "launchpad code team wants to start with a stable base" is the big thing they want to move trunk to the side for
[22:27] <jam> I've been poking at it a bit, because I'd really like to see my code deployed
[22:27] <jam> and I've been given some leeway to push on that
[22:29] <Peng> ISTM, even if the LP folks mangle trunk for a while, I could just pull future, no?
[22:30] <Peng> This is encouraging me to finally update LH, which I haven't done in a while, so I'll feel like I really deserve to have input on this. :P