[00:16] <wgrant> Thanks StevenK.
[00:17] <wgrant> You are not yet imprisoned?
[00:17] <jelmer> What has StevenK done now?
[00:17] <StevenK> jelmer: On the call today I said I have a rental inspection, so if I'm not around for the rest of the day it's because I've been arrested for killing my landlord.
[00:21]  * jelmer tries to imagine what a rental inspection is
[00:21] <poolie> like this: http://www.youtube.com/watch?v=aCiYmCVikjo
[00:22] <jelmer> heh
[00:23] <StevenK> jelmer: Where the landlord comes over to inspect the place you're renting to make sure you're taking care of it
[00:23] <wgrant> StevenK: It looks like the FileBugAPI XML-RPC call has been used around once in the last three months.
[00:23] <jelmer> StevenK: I don't think my landlord is legally allowed to do that
[00:23] <StevenK> Haha, around once
[00:23] <poolie> wgrant: coincidentally i was wondering this morning if there are or should be postmortems for rollbacks
[00:24] <StevenK> wgrant: Zero is around once?
[00:25] <StevenK> wgrant: It seems cronscripts/create-debwatches.py uses debsync?
[00:25] <jelmer> StevenK: while you're here.. can I add a branch to your queue?
[00:25] <StevenK> jelmer: I just reviewed one of yours
[00:26] <StevenK> jelmer: Or do you mean a different branch?
[00:26] <jelmer> StevenK: ah, race condition.. thanks for the review :)
[00:27] <StevenK> And create-debwatches isn't actually run
[00:27] <StevenK> Orsum
[00:30] <wgrant> No, chromium, you may not have 7GB of RAM.
[00:31] <StevenK> Bwaha
[00:31] <wgrant> StevenK: Right, I'm pretty sure that create-debwatches and update-debwatches have never been used.
[00:32] <wgrant> They were written at the end of 2004.
[00:32] <wgrant> And haven't really been touched since.
[00:34] <wgrant> StevenK: Heh, look at r7675.771.2
[00:34] <wgrant> One of mine: "Port create-debwatches.py away from IDS.publishedBinaryPackages(). The script didn't work anyway, so I'm just going to pretend that I haven't broken it more."
[00:34] <StevenK> Haha
[00:35] <wgrant> So, IMO you should delete it and update-debwatches.py, and probably trherefore debsync.
[00:35] <StevenK> steven@liquified:~/launchpad/lp-branches/kill-cruft% bzr di | diffstat | tail -n 1
[00:35] <StevenK>  7 files changed, 1890 deletions(-)
[00:35] <wgrant> What's removed?
[00:36] <StevenK> wgrant: http://pastebin.ubuntu.com/657575/
[00:38] <wgrant> StevenK: You've confirmed we have a bugzilla exporter?
[00:38] <wgrant> This script was clearly written for the Ubuntu migration and probably hasn't been touched since, but best to check.
[00:40] <StevenK> wgrant: scripts/migrate-bugzilla-initialcontacts.py should probably die a firey death too
[00:41] <wgrant> Probably, yes.
[00:43] <StevenK> wgrant: You don't mean things like lp.bugs.externalbugtracker.bugzilla?
[00:44] <wgrant> No.
[00:44] <wgrant> That's the checkwatches backend.
[00:44] <wgrant> The bugzilla exporter won't be in our tree.
[00:44] <StevenK> Ah
[00:45] <wgrant> Meh, delete it anyway. There probably is one.
[00:45] <StevenK> Haha
[00:46] <StevenK> As a serious question, do we actually care?
[00:47] <wgrant> No.
[00:56] <lifeless> about what ?
[00:57] <wgrant> The ancient bugzilla import script.
[00:57] <lifeless> ubuntu bugzilla to lp?
[00:57] <lifeless> does it even work now ?
[00:58] <wgrant> Very probably not.
[00:58] <wgrant> Hence its imminent demise.
[01:09] <wgrant> lifeless: The XML-RPC FileBugAPI (https://help.launchpad.net/MaloneXMLRPC) has been used four times this year.
[01:09] <wgrant> Can we kill it?
[01:09] <lifeless> we what now?
[01:11] <wgrant> Hm?
[01:17] <StevenK> Can haz review?
[01:32] <poolie> wgrant: how much extra work does a rollback cost?
[01:32] <poolie> 10m, an hour, a day?
[01:33] <poolie> i mean across losas and developers
[01:34] <lifeless> poolie: you might like the mail I just sent
[01:34] <lifeless> poolie: which puts some structure on this for the pre-deploy case.
[01:34] <wgrant> poolie: LOSA time: should only be a few minutes, but I don't know how long they spend watching it.
[01:34] <poolie> ah ok
[01:34] <lifeless> poolie: things that have been deployed, and then rolledback incur the pre-deploy pipeline overheads *as well*
[01:34] <poolie> i was just writing up a few thoughts on this change
[01:34] <wgrant> Well, if we catch it before deployment, no LOSA time at all.
[01:36] <lifeless> poolie: which change ?
[01:37] <poolie> mail-scope
[01:37] <lifeless> poolie: so it never got deployed
[01:37] <lifeless> poolie: no cost to losa
[01:37] <poolie> it got deployed to qastaging
[01:37] <poolie> no?
[01:37] <poolie> or is that not called 'deployed'?
[01:38] <lifeless> an unqualified 'deployed' means production only.
[01:38] <wgrant> That's not "deployed"
[01:39] <lifeless> poolie: the mail scope change falls directly under the performance tuesday mail I just sent.
[01:39] <wgrant> Blah.
[01:39] <poolie> what is that called then, "deployed to qastaging"?
[01:39] <wgrant> Or just "on qastaging"
[01:41] <wgrant> wallyworld: The Subscribe spinner on your Answers work is a bit odd.
[01:41] <wallyworld> i reused what was there already
[01:41] <wallyworld> we can iterate if required
[01:41] <wgrant> It doesn't appear until a few seconds after the click :(
[01:42] <wallyworld> i call the method to display the spinner inthe onclick
[01:42] <wgrant> Huh.
[01:42] <wallyworld> well i thought i did
[01:42] <wallyworld> i will have to check
[01:43] <poolie> lifeless: yeah it totally does
[01:43] <wgrant> It seems to make an XHR request, show the spinner, then make another.
[01:44] <wgrant> lifeless: "20 minutes DEPLOY -> deployment -> fails or"
[01:44] <wgrant> Is that the 75 minutes or so to qastaging?
[01:44] <lifeless> wgrant: has it degraded?
[01:44] <poolie> i am trying to develop more sensitivity to risky landings by looking back at things that failed
[01:44] <lifeless> wgrant: but yeah, thats what I was refering to.
[01:44] <poolie> or, that could have been risky but worked
[01:45] <lifeless> poolie: I think that we have a skewed environment because of two things:
[01:45] <lifeless>  - long pipeline
[01:45] <lifeless>  - single pipeline
[01:45] <poolie> yes, that's clearly true
[01:45] <lifeless> as we get more services with independent pipelines, and a faster pipeline
[01:46] <lifeless> then we can iterate more in the direction responsive companies are talking about
[01:46] <wallyworld> wgrant: looks like you are right. it was supposed to be displayed before the first xhr call, but instead happens after. i'll raise a bug and fix. thanks
[01:46] <wgrant> lifeless: It only checks every half hour, and takes nearly an hour.
[01:47] <lifeless> I don't think applying their basic conclusions to us today will work at all well, though knowing their analysis methods / model for the problem is useful.
[01:47] <wgrant> wallyworld: Thanks! If possible, it mihgt be nice to also have it change the "(+) Subscribe" into "(o) Subscribing" like Bugs used to do, and hopefully will again soon.
[01:47] <lifeless> wgrant: please send an errata
[01:47] <lifeless> wgrant: I would appreciate that
[01:47] <wallyworld> wgrant: i thought about that approach but initially just wanted to reuse as much as possble what was there already
[01:48] <wallyworld> lifeless: might you have time to +1 that loggerhead mp?
[01:48] <wallyworld> https://code.launchpad.net/~xaav/loggerhead/export-tarball/+merge/66408
[01:48] <lifeless> wallyworld: I haven't re-read it yet
[01:48] <wallyworld> np
[01:48] <lifeless> wallyworld: this week has been -very- bitsy. Its a high pri for me.
[01:48] <wallyworld> that's cool. sorry for nagging :-)
[01:49] <wgrant> wallyworld: Good plan.
[01:49] <lifeless> nothing to apologise for
[01:49] <lifeless> I'm holding up someones contribution, which sucks.
[01:49] <poolie> lifeless: sent; would appreciate your thoughts on it some time
[01:50] <StevenK> lifeless: You were looking over my kill-cruft MP to review it, or out of interest?
[01:50]  * wallyworld puts on earplugs - electrician installing new solar inverter - *very noisy*
[01:50] <lifeless> StevenK: s/interest/horror/
[01:50] <lifeless> StevenK: :)
[01:50] <lifeless> StevenK: I think you should JFDI
[01:50] <poolie> oh no, the inverter's upside down!
[01:50] <lifeless> poolie: I wanted to touch base with you anyhow; would you like a chat now ?
[01:50] <poolie> sure
[01:51]  * wallyworld slaps forehead at poolie's bad pun
[01:51] <poolie> pots?
[01:51] <lifeless> I'm on the laptop, so can do sip or skype or whatever
[01:51] <poolie> sip
[01:52] <poolie> 'currently unavailable'
[02:11] <wgrant> lifeless: So, I think we should just drop the XML-RPC method. It's been pretty much deprecated since the API was introduced, seems to be used once every couple of months, and whoever is using it can spend the 5 minutes rewriting their script, if indeed someone is actually using it.
[02:12] <StevenK> TBH, I agree with lifeless. Let's FF it first
[02:16] <StevenK> And soyuz-upload.txt is broken
[02:16] <StevenK> Can we delete that yet?
[02:16] <wgrant> Wha?
[02:16] <wgrant> It passed ec2..
[02:17] <StevenK> http://pastebin.ubuntu.com/657616/
[02:17] <wgrant> Yeah.
[02:17] <wgrant> Maybe the race was real.
[02:37] <wgrant> StevenK: I think I will just rip the poppy section out of soyuz-upload.txt
[02:37] <wgrant> Since test_poppy.py tests it all already.
[02:38] <StevenK> Excellent
[02:55] <wgrant> In fact, this removes calls to poppy from outside lp.poppy.
[02:55] <wgrant> Handy.
[02:55] <StevenK> \o/
[02:56] <StevenK> Do you need a review?
[02:56] <wgrant> It's only test changes, so I will self-review it.
[03:00] <jtv> hi wallyworld — just letting you know I'm on the mentoring request.
[03:00] <wallyworld> jtv: thanks!
[03:01] <jtv> I've been doing disappointingly little of that lately, so high time I caught up.
[03:20] <lifeless> wgrant: in your lxc's, have you been configuring up postfix ?
[03:21] <lifeless> wgrant: or something like nullmailer ?
[03:31] <wallyworld> wgrant: the subscription portlet's existing behaviour was to display progress  after the initial xhr call. i can't fix that for "subscribe someone else" or for when "subscribe me" displays an entry in the list but can fix it for answers as it is currently used
[03:37] <lifeless> I wonder if 122 /    3  Person:EntryResource:searchTasks is a regression
[03:58] <wallyworld> StevenK: want a very small review? https://code.launchpad.net/~wallyworld/launchpad/subscriber-portlet-spinner/+merge/70247
[04:00] <StevenK> wallyworld: r=me, but I'm not very comfortable with my JS-foo
[04:00] <wallyworld> StevenK: thanks. the change was just moving a few lines around, so should be ok
[04:09] <lifeless> erm
[04:09] <lifeless> https://launchpad.net/ubuntu/+source/apt/+index
[04:09] <lifeless> click on the expanders
[04:09] <lifeless> they all seem to go 'failed to fetch package details'
[04:09] <lifeless> and retry reloads the whole page
[04:10] <lifeless> is this known ?
[04:10] <wgrant> lifeless: I haven't.
[04:10] <wgrant> lifeless: Just whatever rocketfuel-setup installs, which is IIRC nothing.
[04:10] <lifeless> wgrant: recommends are on by default
[04:11] <lifeless> wgrant: so it pulls in postfix
[04:11] <wgrant> Ah, no, I disable recommends.
[04:11] <wgrant> Halves the downloads or so.
[04:11] <lifeless> wgrant: right; see my mail to -dev :P
[04:11] <wgrant> I always add -o Apt::Install-Recommends=no, mostly for speed and clutter reasons.
[04:12] <wgrant> But have never had the heart to do it in devel.
[04:12]  * wgrant reads.
[04:12] <wgrant> Hah
[04:12] <wgrant> Erm.
[04:12] <wgrant> Isn't that top OOPS meant to be fixed?
[04:13] <wgrant> But maybe the fix wasn't a rollback and the original rev wasn't marked qa-bad :(
[04:13] <lifeless>  145.73s  OOPS-2040CCW4   http://www.urbanvelo.org/
[04:13] <lifeless>    ?
[04:13] <wgrant>  943 LocationError: (<zope.browserpage.metaconfigure.SimpleViewClass from /srv/launchpad.net/production/launchpad-rev-13552/lib/lp/registry/browser/../templates/object-timeline-graph.pt object at INSTANCE-ID>, 'getCacheJSON')
[04:13] <lifeless> I suspect not a rollback, not marked bad.
[04:13] <lifeless> In my mail about pipelines I've covered this sort of change FWIW
[04:14] <lifeless> I'd rather we never do such things.
[04:14] <lifeless>  https://launchpad.net/ubuntu/+source/apt/+sourcepub/1635507/+listing-archive-extra
[04:14] <lifeless> is 404ing
[04:14] <lifeless> (from https://launchpad.net/ubuntu/+source/apt/+index)
[04:15] <lifeless> wgrant: right any bells? I think you refactored stuff in this area?
[04:16] <wgrant> Possibly the expander refactoring a couple of weeks ago.
[04:16] <wgrant> I think that should be /ubuntu/+archive/primary, not /ubuntu/+source/apt.
[04:17] <wgrant>     /**
[04:17] <wgrant>      * If a page wants to use this outside of an archive context then it
[04:17] <wgrant>      * can define LP.cache['archive_context'], which should be a
[04:17] <wgrant>      * full or relative URL to the context archive page required.
[04:17] <wgrant>      */
[04:18] <wgrant> Suspicious
[04:18] <wgrant> And indeed, that's set correctly on DSP:+index...
[04:18] <wgrant> So why is it ignored.
[04:20] <lifeless> heh, you've got the bit between teeth huh.
[04:20] <lifeless> should I file a bug for this, or do you want to ?
[04:21] <wgrant> Bit between teeth?
[04:22] <lifeless> http://www.usingenglish.com/reference/idioms/bit+between+your+teeth.html
[04:22] <wgrant> Ah
[04:22] <StevenK> Build Source Stamp: [branch bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel] 13589
[04:22] <StevenK> WGRANT!
[04:22] <lifeless> if a horse grabs onto the bit, the bridle can no longer control the angle of its head, because the teeth can take a -lot- of pressure vs the back of the jaw
[04:22] <StevenK> Blamelist: William Grant <william.grant@canonical.com>
[04:23] <wgrant> StevenK: The testfix landed hours ago!
[04:23] <StevenK> Ah, it's soyuz-upload again
[04:23] <wgrant> Again?
[04:23] <wgrant> This is the build you complained about while it was in progress!
[04:24] <StevenK> That was ec2
[04:24] <StevenK> That failure was from buildbot
[04:24] <wgrant> Oh.
[04:24] <wgrant> I presumed you saw the failure on buildbot.
[04:25] <StevenK> Just then, from it's bleating mail
[04:26] <StevenK> wgrant: You've killed poppy ftp, can we nail https://bugs.launchpad.net/launchpad/+bug/29645 shut?
[04:26] <_mup_> Bug #29645: Weird requirement to poll the ftp.sock during the upload session <lp-soyuz> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/29645 >
[04:27] <wgrant> StevenK: I plan to go through all poppyish bugs soon, yeah.
[04:27] <StevenK> Cool
[04:36] <wgrant> lifeless: Ah!
[04:36] <wgrant> lifeless: It's a fresh regression.
[04:36] <wgrant> Aaron's thing.
[04:36] <wgrant> It now clobbers LP.cache instead of just adding new items to it.
[04:36] <lifeless> wgrant: urgh
[04:36] <wgrant> Checking to see what else is affected...
[04:36] <lifeless> wgrant: I'll let you file it
[04:36] <lifeless> I guess we need to revert prod ?
[04:37] <wgrant> Mmm. QA-wise we're in an OK state.
[04:38] <lifeless> we don't get js exceptions to count oopses
[04:38] <wgrant> We should be able to deploy this fix in 10 hours.
[04:38] <wgrant> So, maybe.
[04:38] <wgrant> I guess we should.
[04:38] <lifeless> so the fallout is unknown
[04:38] <wgrant> We have to go back all the way, though.
[04:38] <lifeless> yes
[04:38] <wgrant> It was my deployment, not the US one :(
[04:38] <lifeless> do you happen to know the old good evno ?
[04:39] <wgrant> The one before 13548... which was 13543
[04:40] <wgrant> This was reported 22 hours ago, but I didn't notice it :/
[04:42] <wgrant> lifeless: This should be the only fallout of this type.
[04:42] <wgrant> There are a couple of other templates which manipulate LP.cache, but they do it on domready and are working fine.
[04:43] <lifeless> wgrant: how was it reported ?
[04:45] <wgrant> 16:58:00 < diwic> "Failed to fetch package details. Retry" <- is this a known launchpad bug?
[04:45] <wgrant> In #launchpad.
[04:47] <lifeless> ah, didn't miss a bug report.
[04:47] <lifeless> thanks
[04:47] <wgrant> Bug #820174, anyway
[04:47] <_mup_> Bug #820174: Expanders on DistributionSourcePackage:+index broken by LP.cache changes <regression> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/820174 >
[04:50] <wgrant> StevenK: Just failed for me in ec2 too :(
[04:51] <wgrant> Yet I have an email here, "Test results: murder-poppy => devel: SUCCESS" :(
[04:51] <StevenK> Even with your change in devel?
[04:51] <wgrant> No.
[04:51] <wgrant> I know that's not racy :)
[04:52] <StevenK> Strange
[04:52] <wgrant> Oh?
[04:52] <jtv> wallyworld: I'm afraid I reverted to my usual nit-picky self on that branch.
[04:52] <StevenK> wgrant: That it failed, but you get a success message
[04:53] <wgrant> Ah, no, you misunderstand.
[04:53] <wgrant> The branch passed ec2. The test did not fail.
[04:53] <wgrant> It landed.
[04:53] <wgrant> Then broke buildbot and every subsequent ec2 run.
[04:54] <jtv> StevenK: are you ready to exact sweet, sweet revenge for all the horrible things I've done to you?
[04:54] <StevenK> Heh
[04:54] <wallyworld> jtv: i'm looking now, thanks
[04:54] <StevenK> jtv: No, because I'm not yet in the same country as you ...
[04:54] <jtv> StevenK: you clearly have not learned to appreciate the full potential of the internet.
[04:54] <StevenK> I can't kick people in the face over the Internet.
[04:55] <wgrant> lifeless: Would you prefer a full revert, or https://code.launchpad.net/~wgrant/launchpad/fix-dsp-index/+merge/70249?
[04:55] <wgrant> Since it can skip ec2.
[04:56] <lifeless> wtf
[04:56] <lifeless>  robertc@lucid-test-lp:~/source/launchpad/lp-branches/working$ ls /etc/postgresql/
[04:56] <lifeless> 8.2
[04:56] <wgrant> Erm.
[04:56] <StevenK> Fail
[04:56] <StevenK> wgrant: That MP looks good to me
[04:57] <lifeless> wgrant: is the other template thing fixed too already ?
[04:57] <wgrant> Wasn't 8.2 removed just after hardy?
[04:57] <lifeless> wgrant: no freaking idea
[04:57] <wgrant> lifeless: Which?
[04:57] <wgrant> The top OOPS from yesterday?
[04:57] <lifeless>  lsb_release -a
[04:57] <lifeless> No LSB modules are available.
[04:57] <lifeless> Distributor ID: Ubuntu
[04:57] <lifeless> Description:    Ubuntu 10.04 LTS
[04:57] <lifeless> wgrant: yea
[04:57] <StevenK> postgresql-8.2 |    8.2.7-1 | hardy/universe | source, amd64, i386
[04:57] <jtv> StevenK: I still say you're not appreciating (1) the full potential of the internet or (2) the awesome violent scale of my physical reaction to face-kicking attempts.  Hence my offer of safe retribution across the internet.
[04:58] <wgrant> lifeless: Was fixed in r13560
[04:58] <wgrant> lifeless: So the fix is on prod already.
[04:58] <wallyworld> jtv: you certainly are very detailed. i'll check in with curtis tomorrow. thanks again.
[04:58] <StevenK> wallyworld: s/details/pedantic/
[04:58] <wallyworld> lol
[04:58] <StevenK> jtv: How?
[04:58] <jtv> wallyworld: it's the risk of over-escaping date formatting that has me worried.
[04:58] <lifeless> wgrant: ok, I'm fine with rollforward if we're confident of no other sites.
[04:59] <jtv> StevenK: by reviewing one of my branches!  https://code.launchpad.net/~jtv/launchpad/bug-819674/+merge/70135
[04:59] <StevenK> Ah, that branch.
[04:59] <lifeless> wgrant: we will want the original bug to be bad-commit flagged and this new one flagged rollback too though.
[04:59] <lifeless> wgrant: I think.
[04:59] <wgrant> lifeless: Yup.
[04:59] <wallyworld> jtv: yes, i think that's a fair question to ask
[04:59] <StevenK> I am not comfortable doing so, since I don't like the idea of the publisher being SIGINT'd
[05:00] <wallyworld> i suspect it won't be an issue but still.....
[05:01] <wgrant> StevenK/lifeless: Can I have a +1 on the MP?
[05:01] <StevenK> wgrant: r=me
[05:01] <wgrant> Thankyou sir.
[05:02] <jtv> StevenK: fair enough.  It all ends up being nice & safe though.
[05:02] <StevenK> I don't trust it either
[05:02] <StevenK> How can you be *certain* that the publisher is safe to Ctrl-C
[05:02] <StevenK> It's a can of worms
[05:03] <wgrant> As long as the backup switch happens only around publish-distro and not process-accepted, it's not too bad,.
[05:03] <wgrant> The worst it can do is delay.
[05:04] <StevenK> Bleh, and my kill-cruft branch has failed due to soyuz-uploads
[05:04] <wgrant> :(
[05:05] <StevenK> RETRIBUTION
[05:05] <jtv> Feels good, doesn't it?
[05:07] <jtv> Anyway, if wgrant says it's not too bad, it's probably not too bad.  :)  I mapped out and simplified the whole directory dance when I re-did publish-ftpmaster, and now nothing risky gets done in the "real" dists directory until all the hard work is done.
[05:08] <StevenK> jtv: I was talking about retribution for wgrant
[05:08] <jtv> Oh.
[05:08] <wgrant> Just don't revert whatever process-accepted did, and you won't die.
[05:11] <wgrant> Hmm.
[05:11] <wgrant> So, confirmed, nothing else touches LP.cache in bad ways.
[05:11] <wgrant> The rest of that rev may be good.
[05:12] <StevenK> Then land your fix
[05:12] <StevenK> IMO
[05:12] <wgrant> It landed a while ago.
[05:12] <StevenK> Then speed up buildbot
[05:12]  * wgrant points at lifeless and LXC.
[05:17] <lifeless> looks like I'm ready to try parallel testing again, having beaten oneiric lxc into submission
[05:18] <jtv> ! \o/
[05:18] <wgrant> lifeless: I see the restart problem has been diagnosed.
[05:18] <lifeless> wgrant: there are some terrible hacks under the hood, something about O makes them more visible.
[05:19] <jtv> wgrant: would you be able to review my branch perhaps, since StevenK is too chicken?
[05:20] <wgrant> Maybe.
[05:25] <jtv> Maybe thanks.
[05:27] <wgrant> jtv-eat: So this is just improving tests?
[05:27] <wgrant> There seems to be no functional change.
[05:32] <lifeless> wheee
[05:33] <lifeless> localpackagediffs fail - generated two OOPSes :)
[05:33] <lifeless> https://launchpad.net/ubuntu/oneiric/+localpackagediffs?field.name_filter=apt&field.package_type=ignored&field.package_type-empty-marker=1
[05:33] <lifeless> and hit refresh
[05:33] <lifeless> Module lp.services.propertycache, line 116, in __get__
[05:33] <lifeless> value = self.populate(instance)
[05:33] <lifeless> Module lp.registry.browser.distroseries, line 1081, in cached_differences
[05:33] <lifeless> status = package_type_dsd_status[self.specified_package_type]
[05:33] <lifeless> KeyError: u'ignored'<br />
[05:35] <wgrant> Hmmm.
[05:35] <lifeless> (apt is currently generating a diff)
[05:35] <wgrant> That page does have a thread-safety issue, but it's behind a flag and shouldn't cause this.
[05:35] <wgrant> It seems to only affect some appservers.
[05:36] <wgrant> It renders every so often.
[05:50] <LPCIBot> Project devel build #941: FAILURE in 6 hr 8 min: https://lpci.wedontsleep.org/job/devel/941/
[05:50] <StevenK> Bah, there is an import violation that requires a storm fix
[05:59] <wgrant> Excellent.
[05:59] <wgrant> All remaining QA is European.
[06:00] <StevenK> allenap and danilos, right?
[06:01] <wgrant> And rvba.
[06:20] <jtv> wgrant: yup, I just didn't realize it until I'd written the tests.
[06:20] <wgrant> That explains my confusement.
[06:20] <jtv> And then the tests turned out still to be useful.
[06:20] <jtv> Damn, I thought I mentioned this in the cover letter.
[06:21] <wgrant> jtv: Do you know about assertRaisesWithContent
[06:21] <wgrant> ?
[06:21] <jtv> Yes
[06:21] <wgrant> Seems like you could use that in two of those tests.
[06:21] <jtv> Probably makes more sense to use that.  I'll fix it.
[06:21] <wgrant> It cuts out about 5 lines from each.
[06:23] <jtv> Yes… it doesn't really matter that it's the same exception object, I guess.
[06:24] <wgrant> No. But if you use getUniqueString you can be pretty sure.
[06:24] <wgrant> Anyway, apart from that it looks fine.
[06:24] <wgrant> More publisher tests are always good.
[06:25] <jtv> Thanks.
[06:25] <jtv> The change is pushing.
[06:25] <wgrant> You did sort of mention that it was only test changes in the cover letter, but I sort of assumed that couldn't be the case so ignored it.
[06:28] <jtv> wgrant: meanwhile, I'm just about through the testing I can do for the new publish-ftpmaster, except I'm not sure it expedites security updates.  Maybe there's more you can think of.
[06:28] <wgrant> jtv: Not sure that it does, or suspicious that it might not?
[06:29] <jtv> Suspicious that it might not—except we didn't actually get around to publishing a security update, and I don't really know what to look for.
[06:32] <jtv> Then again, that may not be a blocker.  Can't drag this out forever.
[06:33] <wgrant> Well, you could just get two fresh uploads, copy one into security and one not, and check the mtime of the security pool and dists files are before the non-security pool and dists files.
[06:35] <jtv> Thanks..
[06:41] <wgrant> It's easy enough to check, and I can do it if you want.
[06:44] <jtv> wgrant: I'd be lying if I'd say I wouldn't want that — if only because you're so much more likely to spot any glaring mistakes than I am.  :)
[06:44] <jtv> In other words, yes please!
[06:45] <jtv> (Please imagine better grammar when reading the above)
[06:45]  * wgrant enters the molasses.
[06:49] <wgrant> StevenK: :(
[06:49] <wgrant> StevenK: It wasn't entirely file deletions.
[06:49] <wgrant> I am disappoint
[06:49] <StevenK> Haha
[06:53] <wgrant> jtv: You seem to have a diff in 10-sign-releases.
[06:53] <wgrant>  #!/bin/sh -e
[06:53] <wgrant>  
[06:53] <wgrant> +exit 0 # XXX: DEBUG
[06:53] <wgrant> +
[06:56] <jtv> wgrant: that's just because the gpg won't work on dogfood.
[06:56] <jtv> Without it, test runs will break.
[06:56] <wgrant> Ah.
[06:57] <wgrant> Hmm. Why is --post-rsync an option>?
[06:58] <wgrant> I am loving the sane timestamps in this log.
[07:04] <wgrant> I might set oneiric to CURRENT for a while to clear out the -updates queue.
[07:04] <wgrant> NFI how stuff got there :/
[07:05] <jtv> wgrant: it was an experimental feature… doesn't look particularly useful on dogfood, though unknown benefits in production.  This way we get to try things.
[07:05] <wgrant> Ah, k.
[07:05] <jtv> When you say set oneiric to CURRENT, you mean on dogfood right?  :)
[07:05] <wgrant> I don't have privileges to do that on production, sadly.
[07:06] <jtv> If you hadn't added the "sadly," you might still have stood a chance of convincing an admin.  :-)
[07:07] <wgrant> OK, release, security and partner uploads uploaded.
[07:07] <wgrant> Now to wait for them to build.
[07:09] <wgrant> :( partner hates me.
[07:09] <wgrant> Also, mawson is slow.
[07:11] <jtv> Have you called the press or should I?
[07:12] <wgrant> Maybe we can steal gandwana and potassium for staging Soyuz or something.
[07:23] <jtv> wgrant: meanwhile, do you know the particulars of bug 659769?
[07:23] <_mup_> Bug #659769: should copy custom uploads to newly-initialised release <derivation> <lp-soyuz> <new-release-cycle-process> <soyuz-publish> <Launchpad itself:Triaged by jtv> < https://launchpad.net/bugs/659769 >
[07:25] <wgrant> jtv: Unassign.
[07:26] <jtv> ?
[07:26] <wgrant> Not really fixable without completely redesigning the custom upload model.
[07:26] <wgrant> Since they are entirely untracked once the build is processed for the first time.
[07:27] <wgrant> (they're currently published when a PackageUpload is process by process-accepted, and then nothing is recorded about them)
[07:27] <jtv> These are PackageUploadCustoms?  Do they get deleted?
[07:27] <wgrant> They don't get deleted at the moment, no.
[07:27] <wgrant> But we can't know what is still relevant.
[07:28] <wgrant> All we can do is republish every PackageUploadCustom ever.
[07:28] <wgrant> Except for the minor issue that translations tarballs are expired, so that will crash.
[07:28] <jtv> No other heuristics?  Matching filenames or somesuch?
[07:28]  * wgrant sobs.
[07:30] <jtv> Access dates?
[07:31] <jtv> Status of the attached PackageUploads?
[07:32] <wgrant> Once they're DONE, they're DONE.
[07:32] <wgrant> That is the end :(
[07:32] <jtv> And there's no way to determine that a PackageUpload supersedes an older PackageUpload?
[07:33] <wgrant> Nope.
[07:34] <jtv> Access stats on the Librarian file?
[07:34] <wgrant> There's probably only ever one hit.
[07:34] <jtv> And they all have different filenames?
[07:35] <wgrant> Mostly.
[07:37] <wgrant> wallyworld___: Will you be around to QA your thing in 3 hours?
[07:37] <wallyworld___> wgrant: sure
[07:37] <wallyworld___> i've been checking buildbot :-)
[07:38] <jtv> wgrant: what would that one single hit be?
[07:38] <wgrant> jtv: process-accepted putting it in dists/
[07:38] <jtv> And the rest of the use is from there then, I take it.
[07:38] <wgrant> 2011-08-03 07:33:14 INFO    Processing upload hello_2.6-1df1~querulous1_source.changes
[07:38] <wgrant> 2011-08-03 07:38:17 INFO    Committing the transaction and any mails associated with this upload.
[07:38] <jtv> Where do these files go, anyway?
[07:38]  * wgrant burns Soyuz to the ground.
[07:39] <wgrant> jtv: http://archive.ubuntu.com/ubuntu/dists/natty/main/
[07:39] <wgrant> Everything except binary-* and source is custom uploads.
[07:39] <wgrant> There are also two other types of custom uploads which don't end up there: translations and static-translations.
[07:40] <wgrant> But those that you see there are basically unpacked tarballs.
[07:40] <jtv> The translations tarballs are broken up instantly.
[07:40] <wgrant> (Until a year ago, tarballs unpacked without regard for whether the paths contain ../../ and spray files all over whichever archive the uploader wishes)
[07:41] <jtv> I remember making one of those code paths check that it's not trying to unpack devices…
[07:41] <jtv> But anyway.
[07:41] <wgrant> Ah yes, translation imports had that issue too.
[07:42] <jtv> Is there any way to delete custom uploads?
[07:42] <wgrant> rm -r
[07:42] <wgrant> The way we currently copy custom uploads is with cp.
[07:43] <wgrant> Yes, that is mutilating the one-step-from-live archive with cp and rm.
[07:44] <jtv> Which, admittedly, sounds like fun.
[07:44] <jtv> Especially with the dot-directory end-of-level baddie.
[07:44] <wgrant> Hah
[07:45] <wgrant> lifeless: What are gandwana and potassium up to these days?
[07:45] <jtv> rm -- rf .<tab><enter><backspace><backspace><ctrl-C><ctrl-C><panic>
[07:46] <lifeless> wgrant: not sure; possibly going to be the staging scripts machine and achive machine.
[07:46] <lifeless> [qa]staging that is
[07:46] <wgrant> Yay
[07:46] <wgrant> As I was hoping.
[07:46] <wgrant> Maybe it will happen this decade :)
[07:46] <wgrant> Because mawson is pissing me off.
[07:51] <jtv> wgrant: still, do the PUCs really need a redesign or just a bit of extra metadata so we can track and manage them?
[07:51] <wgrant> jtv: They need a *PublishingHistory table, probably.
[07:51] <wgrant> As sources and binaries have had since ~the start.
[07:51]  * jtv discovers it's his turn to sob
[07:52] <wgrant> I warned you!
[07:52] <jtv> Still, can't be as bad as BPPH
[07:58] <wgrant> I wonder if we can do away with scripts/ and cronscripts/
[07:58] <jtv> wgrant: are the Packages files I see for the installers also custom uploads?
[07:58] <jtv> They're in binary-* directories, but not at the top level so not clear where they fall.
[07:59] <adeuring> good morning
[07:59] <jtv> Hi adeuring
[07:59] <adeuring> hi jtv!
[07:59] <wgrant> jtv: Sorry, debian-installer/binary-* are also not custom uploads.
[07:59] <wgrant> jtv: They're udeb indicies.
[08:00] <jtv> So it's the translations stuff (which looks like it probably doesn't really need copying), dist-upgrader, and installer-<arch>
[08:00] <wgrant> Right.
[08:00] <wgrant> s/translations/ddtp/, to avoid confusion.
[08:01] <jtv> Where do the versioned directories inside the dist-upgrader and installer-<arch> come from?  Created by hand in the filesystem?  Or do the custom uploads go to a specific version?
[08:01] <wgrant> The versions are in the custom upload filename, and current is a symlink that we keep up to date, I believe.
[08:02] <jtv> Looks like it, yes.
[08:03] <jtv> ISTM we'd only want to copy custom uploads for the current versions.
[08:04] <jtv> (Which we may not trivially know, unless we have the symlink handy, but it'd make a big dent in the purging problem)
[08:05] <wgrant> Possibly.
[08:15] <mrevell> Hello
[08:22] <jtv> hi mrevell
[08:25] <jtv> wgrant: looks like it's a bit simpler actually.  I see two kinds of filename: <purpose>_<version>_<arch>.tar.gz and <purpose>_<version>.tar.gz, depending on <purpose>.  I'll bet the last of these for any given (<purpose>, (<arch> or 'all')) in the previous series will take us a long way.
[08:26] <wgrant> In an extremely distasteful manner, but possibly.
[08:26] <allenap> wgrant: Thanks for sorting out that rollback.
[08:27] <jtv> No more distasteful than other places where the debian edifice relies on tarball naming conventions.  Make it (<format>, <purpose>, (<arch> or 'all')) for luck.
[08:27] <jtv> Check whether the Librarian still has the file, and done.
[08:27] <wgrant> jtv: We make no assumptions like that outside the custom upload publisher.
[08:28] <wgrant> Putting that into series initialisation is awful.
[08:28] <wgrant> Possibly the easiest solution, but still thoroughly awful.
[08:28] <jtv> Well what produces the tarball names?
[08:29] <wgrant> Packages.
[08:31] <jtv> What aspect of packages produces the tarball names?
[08:44] <wgrant> jtv: It varies.
[08:45] <jtv> wgrant: taking just the dist-upgrader and the installer, what in the packages determines the tarball filenames?
[08:46] <jelmer> is canonical.launchpad.utilities.ftests.test_gpghandler.TestImportKeyRing.testHomeDirectoryJob known to be flaky?
[08:47] <wgrant> jelmer: Yes.
[08:47] <danilos> stub, about the DB patch, do I assign a patch number myself?
[08:47] <wgrant> jtv: debian-installer and update-manager
[08:47] <stub> danilos: Didn't you already have one? Yes, assign it yourself is best.
[08:47]  * danilos fetches ~launchpad/+junk/dbpatches
[08:47] <danilos> stub, ack
[08:48] <stub> danilos: Just don't use a -0.sql patch number, per newly added comments in the notes of that file.
[08:48] <danilos> stub, right, reading it now
[08:48] <jelmer> wgrant: thanks
[08:49] <jtv> wgrant: those have their own dedicated packageuploadcustomformats?  I think these two are the ones we _really_ care about; the rest at first glance seems more sort of optional.
[08:49] <wgrant> jtv: They do.
[08:49] <danilos> stub, do I use the existing "base" number (i.e. 79-0 is assigned, should I use 79-1)?
[08:50] <lifeless> danilos: https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess#Patch ids
[08:50] <stub> danilos: It doesn't really matter. Your patch number needs to be higher than any your patch depends on, but that rarely matters.
[08:51] <danilos> lifeless, that doesn't help answer my question, but thanks :)
[08:51] <danilos> stub, ok, thanks, I'll use 79-1 then
[08:51] <lifeless> danilos: we don't use -0 at all now
[08:52] <danilos> lifeless, right, stub already explained that (and pointed at comments in the allocated.txt), I was wondering how do I choose the "base" (middle) number for -1, -2 etc.
[08:55] <lifeless> danilos: could you add something to the file while you are there? I will add a note to the wiki reference I gave.
[08:56] <danilos> lifeless, sure, I will
[08:56] <lifeless> thanks!
[09:09] <jtv> cjwatson: got a moment to discuss possibilities for bug 659769?
[09:09] <_mup_> Bug #659769: should copy custom uploads to newly-initialised release <derivation> <lp-soyuz> <new-release-cycle-process> <soyuz-publish> <Launchpad itself:Triaged by jtv> < https://launchpad.net/bugs/659769 >
[09:10] <danilos> stub, can you please run http://paste.ubuntu.com/657714/ (it's the query you optimized yesterday) on qastaging? (if you are busy with the code hosting crisis as well, just ignore me)
[09:10] <danilos> stub, actually, ignore that, just got a response :)
[09:22] <lifeless> danilos: hi
[09:22] <lifeless> danilos: your https://code.launchpad.net/~danilo/launchpad/bug-814580-resubmit/+merge/70262 merge should be against devel - it has no db component
[09:23] <lifeless> danilos: its only the schema changes that should land on db-devel
[09:23] <danilos> lifeless, it depends on a branch that has a DB patch
[09:23] <lifeless> danilos: ah; well you'll need to remember to merge that to devel yourself when the DB patch is deployed.
[09:24] <danilos> lifeless, how can I know if the DB patch is deployed? devel/stable will contain it or is there something else that I need to watch out for?
[09:25] <lifeless> danilos: the db patch will be merged to devel by stub / myself after its deployed.
[09:25] <danilos> (hopefully something more of the push-type instead of a pull type notification)
[09:25] <danilos> lifeless, ack
[09:25] <lifeless> I think we will want to mail the list when we do this too, for clarity
[09:26] <lifeless> eventually there will be a view on the appservers to check, and stub has plans for a report
[09:26] <danilos> lifeless, it would be even better if original committers are emailed directly as well, perhaps even automatically, but I am sure you guys will figure something smart out :)
[09:27] <lifeless> first pass is just to get the cycle time benefits
[09:27] <lifeless> subsequent passes will add polish of various sorts
[10:07] <LPCIBot> Yippie, build fixed!
[10:07] <LPCIBot> Project db-devel build #777: FIXED in 6 hr 10 min: https://lpci.wedontsleep.org/job/db-devel/777/
[10:16] <jtv> Would anyone mind if I removed makeDistroRelease, replacing all calls with makeDistroSeries?
[10:18] <wgrant> I've been tempted to do that for a Long Time.
[10:20] <jtv> As a rule, I find that temptation isn't actually much cheaper than indulgence.
[10:20] <adeuring> lifeless: fancy a 200 diff review? https://code.launchpad.net/~adeuring/launchpad/bug-739052-3/+merge/70272
[10:20] <adeuring> (yeah, I know it's late for you...)
[10:20] <lifeless> tis almost early
[10:20] <lifeless> no diff yet :)
[10:24] <lifeless> adeuring: you decided not to handle desc, asc, asc, asc, desc as 3 expressions to reduce ?
[10:25] <adeuring> lifeless: well, I wanted a simple start :)
[10:25] <lifeless> ok
[10:25] <adeuring> I know that we could try this too
[10:25] <adeuring> but I'm wondering if we shouldn't first check how efficient the tuple expressions are
[10:26] <lifeless> sure
[10:37] <stub> what is the magic env variable for Storm statement logs again?
[10:38] <bigjools> LP_DEBUG_SQL
[10:39] <bigjools> LP_DEBUG_SQL_EXTRA if you want a trace with each one
[10:56] <adeuring> lifeless: you suggested in an older review to use "resultset.find(resultset.order_by)". Seems that this does not work:
[10:56] <adeuring> In [11]: rs.find(rs._order_by)
[10:56] <adeuring> Out[11]: <storm.store.ResultSet object at 0x278a6d0>
[10:56] <adeuring> In [12]: list(rs.find(rs._order_by))
[10:56] <adeuring> ProgrammingError: argument of AND must be type boolean, not type integer
[10:56] <adeuring> LINE 1: ...de_private FROM Bug WHERE Bug.id IN (1, 2, 3) AND Bug.id ORD...
[10:56] <adeuring>                                                              ^
[10:58] <lifeless> adeuring: it was pseudo code :P
[10:58] <adeuring> lifeless: ...but i did not understand it ;)
[10:58] <lifeless> adeuring: I think I further suggested
[10:58] <lifeless> find(<initial find clause> + (order by columns tupe) ...
[10:59] <lifeless> to get both the original data, and the precise data we need
[10:59] <lifeless> adeuring: however, your exception there is in the where clause not the select clause
[10:59] <adeuring> lifeless: resultset.find() only allows to extend the WHERE clause, but we can't extend the data returned
[11:00] <lifeless> adeuring: ah, shame
[11:00] <lifeless> adeuring: guess we need to fix that too
[11:00] <adeuring> lifeless: well, I think we can change the original query and used a DecoratedResultSet
[11:01] <adeuring> that does not require any changes for storm
[11:02] <lifeless> adeuring: get_select_expr
[11:02] <lifeless> can  be used too
[11:03] <adeuring> lifeless: Ah, ok. But is it worth the effort to tweak the result set?
[11:03] <lifeless> perhaps
[11:03] <lifeless> I dunno
[11:03] <adeuring> I mean, DecoratedResultSet are all we need
[11:03] <lifeless> big picture what I was saying is
[11:03] <lifeless> - use the existing things to retrieve
[11:03] <lifeless> - add in the things the order orders on with Asc/Desc removed
[11:03] <lifeless> - interrogate only those added things
[11:04] <lifeless> -> we now support queries that return funky stuff, are grouped, etc.
[11:04] <adeuring> lifeless: ok, I see
[11:06] <adeuring> lifeless: I suspect that queries with aggregates might fail really bad with StromRangeFactory
[11:06] <adeuring> unless the aggregates are done in sub-queries
[11:06] <adeuring> ...sub-selects...
[11:07] <lifeless> if its in order by
[11:07] <lifeless> it must be safe to have in the results
[11:08] <adeuring> well, you could do something like select sum(col) from table order by col; but that's quite pointless...
[11:11] <lifeless> adeuring: I don't think you can :)
[11:11] <adeuring> maybe ;)
[11:11] <lifeless> select sum(col1) from demo order by col1;
[11:11] <lifeless> ERROR:  column "demo.col1" must appear in the GROUP BY clause or be used in an aggregate function
[11:11] <lifeless> LINE 1: select sum(col1) from demo order by col1;
[11:13] <wgrant> wallyworld: Thanks.
[11:13] <wallyworld> np
[11:13] <wgrant> allenap: Hi.
[11:13] <wgrant> rvba: Hi
[11:15] <allenap> wgrant: Hi :)
[11:15] <lifeless> adeuring: and if you group by it, you can select it :P
[11:15] <adeuring> lifeless: yeah
[11:15] <wgrant> allenap: Bug #809985 needs QA within the next 3 or so hours.
[11:15] <_mup_> Bug #809985: DistroSeriesDifferenceBaseView modifies shared objects <derivation> <qa-needstesting> <tech-debt> <Launchpad itself:Fix Committed by allenap> < https://launchpad.net/bugs/809985 >
[11:16] <adeuring> lifeless: back to get_select_expr(): that would work, I think, it it will require two more SQL queries to retrieve the memo values. Do we want this?
[11:16] <allenap> wgrant: I'm on it already, but thanks for the reminder nonetheless.
[11:16] <wgrant> allenap: Thanks.
[11:16] <adeuring> lifeless: argh... i wropte plain nonsense
[11:17] <lifeless> adeuring: have you had your morning coffee ?
[11:18] <adeuring> lifeless: not enough... I nearly poured the coffee directly into ash tray this morning...
[11:18] <lifeless> LOL
[11:18] <lifeless> well, I have to crash, early start tomorrow.
[11:18] <lifeless> night all
[11:18] <adeuring> night lifeless
[11:18] <wgrant> Night lifeless.
[11:22] <jtv> hey danilos, I'm going EOD but if you want a bit of fun and you're out of good books: https://code.launchpad.net/~jtv/launchpad/we-prefer-distroseries-thank-you/+merge/70282
[11:22] <jtv> Something tells me I'll be approving it myself though.  ☺
[11:23] <danilos> jtv, it looks pretty decent considering the diff has not been generated yet
[11:23] <rvba> wgrant: Hi
[11:23] <danilos> jtv, and I thought DistroRelease stuff was the *preferred* spelling for DistroSeries
[11:24] <jtv> danilos: small linguistic note: it looks pretty decent *because* the diff has not been generated yet.  :-)
[11:24] <jtv> DistroRelease was the old spelling.
[11:24] <jtv> Mark had that nice 30,000-line branch that did away with it, a few years back.
[11:24] <wgrant> rvba: You have some pending QA. and we will are hoping to deploy 55 or so revs in a few hours.
[11:24] <danilos> jtv, heh, ok, if you say so (regarding the linguistic note)
[11:25] <rvba> wgrant: ok, I'm on it.
[11:25] <wgrant> Thanks.
[11:25] <danilos> btw, I wondered about the state of the deployment report, looks pretty weird to me
[11:25] <jtv> danilos: go on, ask yourself _why_ the diff hasn't generated yet.  :)
[11:25] <wgrant> danilos: We reverted the last two deployments.
[11:25] <wgrant> danilos: And found two bad revisions.
[11:25] <wgrant> Some of which were already deployed.
[11:26] <wgrant> danilos: We should be good to deploy again in 3.5 hours, and should deploy as soon as it is possible.
[11:26] <stub> Where is my long poll diff refresher dammit.
[11:26] <wgrant> danilos: Only one item in the current buildbot run needs QA, and it's quick and documented in the bug, so you should be able to deploy just about as soon as it hits qastaging.
[11:28] <stub> danilos: Short branch to review - https://code.launchpad.net/~stub/launchpad/trivial/+merge/70284
[11:28]  * stub wanders off for a bit for kitchen detail
[11:33] <wgrant> bigjools: If jtv returns, could you inform him that expedited security processing works fine?
[11:33] <bigjools> wgrant: he's EoD.  But thanks for letting me know.
[11:33] <danilos> stub, diff is still not showing up :(
[11:34] <bigjools> I think we're close to releasing this puppy
[11:34] <wgrant> bigjools: I think so.
[11:34] <wgrant> bigjools: The core stuff looks good, I believe, but I need to reexamine the hooks at some point.
[11:35] <bigjools> wgrant: yeah
[11:39] <LPCIBot> Project devel build #942: STILL FAILING in 5 hr 49 min: https://lpci.wedontsleep.org/job/devel/942/
[11:49] <danilos> diff generation seems dead
[11:49] <wgrant> danilos: See #launchpad-ops
[11:49] <wgrant> And see the spam that should be in your inbox :)
[11:51] <danilos> wgrant: thanks (and I am only trying to review stuff, thus not getting the spam)
[11:51] <wgrant> Heh.
[11:51] <wgrant> We'll hopefully have nagios checks on scriptactivity soon, but until then someone should watch for the emails.
[11:52] <danilos> wgrant: right, it's one thing we are particularly bad at (watching all the -errors emails)
[12:03] <danilos> stub, r=me, with a minor proposal which is entirely up to you (if you perhaps want to still update all of bug heat values with a single query, but you know better if that's worth it :))
[12:18] <StevenK> wgrant: Er, I think you broke devel
[12:18] <StevenK> wgrant: https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1212/steps/shell_6/logs/summary
[12:32] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/i-suck/+merge/70298
[12:33] <wgrant> StevenK: No diff, due to the ongoing incident, but you can get it from loggerhead.
[12:35] <stub> danilos: ta
[12:38] <StevenK> wgrant: Right. Approved, please land
[12:39] <wgrant> I forgot that |nothing swallows exception.
[13:03] <StevenK> danilos: You are the last person who needs to do QA, r13586
[13:05] <danilos> StevenK, hasn't that been QAd already?
[13:05] <danilos> StevenK, oh, separate db-devel landing has made qa-tagger mess up my tags, we are all good
[13:06] <StevenK> danilos: Until a bunch of new revs hit stable. Thanks!
[13:11] <jml> the diff generation issue wasn't announced on identi.ca :(
[13:12] <danilos> StevenK, thankfully, forthcoming testfix will put a stop to that! ;)
[13:14] <StevenK> danilos: Which wgrant has already fixed.
[13:17] <danilos> StevenK, he should be sleeping, shouldn't he? :)
[13:21] <StevenK> danilos: He fixed it before his bed time :-P
[13:33] <henninge> abentley: https://wiki.canonical.com/IncidentReports/2011-08-03-LP-failing-jobs
[15:51] <mtaylor> hey guys! did the bzr haproxy timeout get changed back down again?
[16:02] <jelmer> hi mtaylor
[16:02] <mtaylor> hi jelmer !
[16:03] <jelmer> (checking the haproxy status)
[16:07] <mtaylor> jelmer: I'm getting timeouts
[16:07] <jelmer> mtaylor: this is when a connection is idle for more than X seconds?
[16:07] <mtaylor> jelmer: not full sure - still tracking down on my side
[16:08] <jelmer> mtaylor: I think I saw your bug report yesterday about bzr handling that more gracefully
[16:08] <mtaylor> jelmer: https://jenkins.openstack.org/job/nova-tarmac/109707/console
[16:08] <mtaylor> jelmer: if you look at the bottom there, you'll see the "Connection to bazaar.launchpad.net closed by remote host."
[17:31] <LPCIBot> Project devel build #943: STILL FAILING in 5 hr 52 min: https://lpci.wedontsleep.org/job/devel/943/
[18:30] <sinzui> jcsackett, do you have time to mumble?
[18:30] <jcsackett> sinzui: i will in five minutes.
[18:44] <lifeless> morning
[18:53] <sinzui> jcsackett, https://code.launchpad.net/~sinzui/+recipe/mmm-archive-manager-daily
[18:54] <lifeless> bac: hi
[18:54] <bac> hi lifeless
[18:55] <lifeless> bac: just a very small note - it was great to see you identifying some dupes; could you please bias towards duping on the oldest one ?
[18:55] <bac> lifeless: i would've but i was already working the other so i biased toward it
[18:55] <lifeless> bac: ah... so I've just messed things up for you by switching them around
[18:55] <lifeless> bac: I'll put them back.
[18:56] <bac> perhaps
[18:56]  * bac will live
[18:56] <lifeless> bac: this isn't really documented anywhere, but I've a convention with timeouts of puting the page id in the title, it helps folk searching for the bug given a OOPS summary report.
[18:57] <lifeless> in this case I failed to update the subject on the newer one, and in not doing that I failed to notice it was a dupe :) - mea culpa
[18:57] <lifeless> there, all back, and I've copied the subject over
[18:58] <lifeless> sorry for the interrupt!
[18:58] <bac> lifeless: np!
[19:03] <sinzui> jcsackett, I am jinxed. The battery indicator just went belly up
[19:37] <sixstring> Howdy, #launchpad-dev. I'm happy to join the crew working on launchpad.
[19:38] <SpamapS> lifeless: here's a bug that consistently times out .. I suspect its a known issue: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/804896
[19:38] <_mup_> Bug #804896: gnome-settings-daemon assert failure: gnome-settings-daemon: ../../src/xcb_io.c:140: dequeue_pending_request: Assertion `req == dpy->xcb->pending_requests' failed. <apport-crash> <i386> <oneiric> <unity-2d> <gnome-settings-daemon (Ubuntu):Triaged by rodrigo-moya> <gnome-settings-daemon (Ubuntu Oneiric):Triaged by rodrigo-moya> < https://launchpad.net/bugs/804896 >
[19:40] <lifeless> sixstring: welcome
[19:42] <lifeless> whats the OOPS id
[20:14] <jml> sixstring: \o/
[20:14] <jml> sixstring: welcome :)
[20:15]  * sixstring is running rocketfuel-setup.
[20:15] <sixstring> Yep. It's a long process. :)
[20:16] <sixstring> Esp. at this coffeeshop.
[20:18] <jml> I'll bet!
[20:22] <sixstring> ~300KB/s. I'd better go get another cup o' joy.
[20:23] <sixstring> Incidentally, I don't suppose rocketfuel-setup would recover if I halted the bzr checkout step, would it?
[20:51] <lifeless> sixstring: not well :)
[20:52] <sixstring> 183MB so far, so good. Guess I'll just wait it out. :)
[21:29] <Ursinha> hello launchpadders :)
[21:29] <Ursinha> is there a way to bring someone's attention to a bug other than subscribing them to that?
[21:30] <lifeless> email them a url ?
[21:31] <Ursinha> lifeless: I'll pretend you didn't suggest me that :P
[21:33] <Ursinha> lifeless: what I see people doing is assigning to the bugtask the one they want input from
[21:34] <Ursinha> that's misleading
[21:34] <Ursinha> (from a defect analyst point of view)
[21:34] <lifeless> Ursinha: if the bug is blocked on that persons action, it seems accurate to me.
[21:34] <Ursinha> lifeless: right
[21:35] <lifeless> but there is no 'ask for input from <person>' facility in LP itself.
[21:35] <Ursinha> so assignee not just the one who's going to actually fix, but the one the bug is depending on... ok, makes sense
[21:36] <Ursinha> I'm working on the ubuntu server bug triage process, so I saw that a couple of times
[21:37] <Ursinha> people don't actually follow bug reports when there are lots and lots of them
[21:37] <Ursinha> well, you do, but that's you :P
[21:38] <lifeless> :)
[23:03] <sinzui> stevek, mumble
[23:24] <LPCIBot> Project devel build #944: STILL FAILING in 5 hr 52 min: https://lpci.wedontsleep.org/job/devel/944/
[23:55] <sinzui> wallyworld, ,maybe the save event needs to explicitly set the NUM_SEARCHES to 0
[23:56] <wallyworld> sinzui: perhaps, i'll look at that. i also want to see when it went bad