[00:04] <StevenK> wgrant: You're not done with mawson?
[00:05] <wgrant> StevenK: I would have been if it hadn't crashed.
[00:05] <wgrant> Nearly done.
[00:05] <wgrant> But I still need the buildd.
[00:05] <lifeless> StevenK: hi
[00:05] <StevenK> wgrant: Is perfectly fine, tell me when you're done.
[00:05] <StevenK> lifeless: mumble?
[00:06] <StevenK> lifeless: Or would you prefer something else?
[00:06] <lifeless> mumble is still fail on my link
[00:06] <StevenK> Get a better one? :-)
[00:06] <lifeless> 2012
[00:07] <StevenK> lifeless: Skype or pots?
[00:07] <lifeless> skype
[00:07] <StevenK> Bleh, that requires commitment
[00:08] <lifeless> I don't think you're craazy
[00:09] <StevenK> Bad puns will be punishable at the Epic
[00:10] <lifeless> i.e. never
[00:10] <lifeless> :>
[00:12] <StevenK> lifeless: On Skype and ready
[00:13] <lifeless> StevenK: skype id
[00:38] <StevenK> wgrant: Are we there yet?
[00:39] <wgrant> StevenK: Just finished about a minute ago.
[00:39] <wgrant> It's all yours.
[00:44] <wallyworld> thumper: ping
[00:56] <StevenK> wgrant: Didn't you say you'd fix the en_AU locale on mawson?
[01:15] <StevenK> wgrant: https://code.dogfood.launchpad.net/~stevenk/+recipes :-D
[01:20] <wgrant> StevenK: No. I was going to look at overriding LANG.
[01:20] <wgrant> Indeed, my .profile has:
[01:20] <wgrant> export LANG=C
[01:20] <wgrant> export LC_ALL=C
[01:20] <wgrant> And there are no more warnings.
[01:20] <wgrant> StevenK: Also, let me know when you're done with DF.
[01:20] <wgrant> I want to stab the publisher in the face.
[01:21] <wgrant> (that may be taken to mean optimising publishFileLists, or maybe not)
[01:21] <StevenK> wgrant: I'm done once I clean up, but I wanted you to see the evil I created.
[01:23] <lifeless> what should I do today?
[01:23] <wgrant> StevenK: What was the evil?
[01:23] <StevenK> wgrant: https://code.dogfood.launchpad.net/~stevenk/+recipes
[01:23] <wgrant> Besides what looks like a bug in findStaleDailyBuilds, or a manual request.
[01:23] <StevenK> wgrant: Look at the source branch
[01:23] <StevenK> wgrant: It was a manual request.
[01:24] <wgrant> Ah.
[01:24] <wgrant> you're trying to kill our builders!
[01:24] <StevenK> Haha
[01:24] <wgrant> What're you testing?
[01:24] <StevenK> I was QA'ing my findStaleDailyBuilds() change
[01:24] <StevenK> I needed a branch ...
[01:25] <wgrant> Ah
[01:25] <StevenK> wgrant: Recipe deleted, you should be good
[01:26] <wgrant> Thanks.
[01:27] <henninge> &away
[01:27] <LPCIBot> Project devel build (412): STILL FAILING in 6 hr 10 min: https://hudson.wedontsleep.org/job/devel/412/
[01:27] <LPCIBot> Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=707103] UI for searching for bugs with or
[01:27] <LPCIBot> without linked Blueprints.
[01:39] <thumper> wallyworld: whazzup?
[01:39] <wallyworld> thumper: mumble?
[01:39] <thumper> aye
[02:02] <wgrant> poolie: With the oauth thing... you did s/contrib.oauth/oauth/, right?
[02:04] <lifeless> wgrant: hey
[02:04] <lifeless> in oops 1855H1087
[02:04] <lifeless> for th elong query; can you suggest a likely value for archive?
[02:05] <lifeless> and the two status values
[02:06] <wgrant> That query suggests it was a copy archive.
[02:06] <wgrant> It's going to be difficult to reproduce entirely now.
[02:06] <lifeless> I'm looking for one that will be on qas
[02:07] <wgrant> Ah, yes, it was the copy archive.
[02:07] <wgrant> There's nothing like it on qas.
[02:07] <wgrant> Possible on staging, though.
[02:07] <wgrant> Let me see.
[02:07] <lifeless> not even lucid itself?
[02:07] <wgrant> No.
[02:07] <wgrant> This relies on there being lots of pending builds.
[02:07] <wgrant> We could create one on qas, though.
[02:08] <StevenK> Sure, how much do you want asuka to cry blood?
[02:09] <wgrant> The first status is 0 (there were probably 25000 or so matching BFJs), the second is 6 (probably only about 30).
[02:09] <lifeless> StevenK: it would hardly notice
[02:09] <wgrant> staging's snapshot is from just the right time.
[02:09] <StevenK> lifeless: Because it already is?
[02:09] <wgrant> But the pending builds have been nuked.
[02:12] <lifeless> hmmm, I wonder if https://help.launchpad.net/Code/Imports can be made snappier
[02:13] <wgrant> Snappier?
[02:13] <lifeless> easier for users of bzr to follow successfully
[02:14] <lifeless> so how do we go about creating one of these archives on [qa]staging?
[02:15] <wgrant> lifeless: We need to turn off the build farm, then run populate-archive.py.
[02:15] <wgrant> Or we could possibly leave the build farm on and the archive disabled.
[02:16] <thumper> wallyworld: are you all good?
[02:16] <thumper> wallyworld: we have a laptop emergency
[02:16] <thumper> wallyworld: and need to get Rachel a new one
[02:17] <lifeless> wgrant: https://qastaging.launchpad.net/builders is full of lies
[02:17] <wgrant> "scripts/populate-archive.py -v --distribution=ubuntu --suite=natty -a i386,amd64 --to-user=lifeless --to-archive=bye-bye-asuka --reason='i hate alive servers'" should do it.
[02:18] <lifeless> will that try to build things straight away?
[02:18] <wgrant> lifeless: Looks like qastaging has no buildd-manager.
[02:18] <StevenK> lifeless: Of course it is. We don't delete builders on qas
[02:18] <wgrant> So you can safely run it there.
[02:18] <lifeless> thats correct
[02:18] <lifeless> spm: hi
[02:18] <StevenK> I think he's lunching
[02:19] <lifeless> spm: 6 lines before I said hi, kthxburn
[02:19] <StevenK> On that note, so am I
[02:19] <lifeless> StevenK: I'm sure he is
[02:19] <wgrant> spm, lifeless: It may need to be "-a i386 -a amd64" instead of "-a i386,amd64". One will work, one will not, I forget which.
[02:20] <thumper> wallyworld: too late, off to hardly normal
[02:36] <lifeless> wgrant: where is your openid fix
[02:36] <wgrant> lifeless: In buildbot.
[02:36] <wgrant> It was testfixed away last night.
[02:36] <wallyworld> thumper: sorry, was eating
[02:36] <wgrant> So it is still a few hours away from qasbounce.
[02:37] <lifeless> wgrant: kk
[03:11] <spm> wgrant: so scripts/populate-archive.py -v --distribution=ubuntu --suite=natty -a i386 -a amd64 --to-user=lifeless --to-archive=bye-bye-asuka --reason='wgrant hates alive servers' <== on LPCONFIG=QAS on asuka?
[03:11] <wgrant> spm: I see what you did there.
[03:11] <wgrant> But yes, that should work.
[03:11] <spm> sneaky aren't I
[03:12] <spm> technically it's *you*, not I, as the command would have it. So I had to correct the 'person' sense. <== BIG ISSUES
[03:12] <wgrant> Indeed.
[03:12] <lifeless> spm: thanks
[03:14] <spm> ho ho.FATAL:  Ident authentication failed for user "lucille" <== fixin'
[03:15] <wgrant> I think that is the sole remaining reference to lucille.
[03:15] <wgrant> It is tempting to quickly remove that.
[03:15] <StevenK> Death to lucille
[03:15] <wgrant> Ah, no, the demon lives on in poppy's ident.
[03:15] <StevenK> Sigh, it's moving. Kill it.
[03:16] <spm> haha
[03:17] <wgrant> StevenK: What should I call the new user? archivepublisher?
[03:17] <spm> but yes. names that match functions, if only loosely, do help us. pls to fix. :-)
[03:17] <spm> wgrant: sigh. lucilleball of course. for shame.
[03:17] <wgrant> Needs more "l"s.
[03:17] <spm> llllllllllll ?
[03:17] <lifeless> loball
[03:17] <StevenK> wgrant: I'm tempted to suggest 'lolwut'
[03:17] <spm> lollball?
[03:18] <StevenK> Just due to the queries that lucille currently runs
[03:18] <wgrant> StevenK: mawson can handle the SPPH indices OK.
[03:18] <wgrant> But not both it and BPPH, it seems.
[03:19] <wgrant> Once hot, the source override queries are all sub-second...  SourcePackagePublishingHistory.archive = 1 AND SourcePackagePublishingHistory.distroseries = 103 AND SourcePackagePublishingHistory.pocket = 0 AND SourcePackagePublishingHistory.status = 2 ORDER BY SourcePackagePublishingHistory.id DESC LIMIT 10000 OFFSET 0;
[03:20] <wgrant> Component and Section are small. SPN isn't bad.
[03:20] <lifeless> moving to an actual model of suite would help.
[03:20] <wgrant> A little, yes.
[03:20] <StevenK> No, it wouldn't
[03:20] <StevenK> It would make adding a new suite for Ubuntu a lot harder
[03:21] <lifeless> by which you mean easier and more controlled
[03:21] <StevenK> No, by which I mean creation of new tables and duplicated data\
[03:21] <wgrant> I unfortunately have to agree with lifeless here.
[03:21] <wgrant> And I normally disagree with his Soyuz model arguments :P
[03:22] <StevenK> wgrant: Who are you, and what have you done with the real wgrant?
 I unfortunately have to agree with lifeless here. <== my world. It has ended.
[03:23] <StevenK> Haha
[03:24] <spm> I had 3 cornerstones. Death, Taxes and lifeless/wgrant not agreeing. This is now over. /me hols forearm theatrically and dramatically to forehead
[03:25]  * lifeless applies stablegun
[03:25] <lifeless> *staple*
[03:25] <lifeless> something that shoots stables would be awesome, scary, and worrying.
[03:25] <spm> meh. I play a pally.  My DK is currently doing 9k and I button mash
[03:27] <lifeless> its a dk.
[03:27] <lifeless> bastards.
[03:27] <spm> wgrant: for the record - what are you doing that needed that DB access change? "add to pg_ident: lucille for qastaging access for wgrant doing soyuz builders <...>" ?
[03:28] <StevenK> lifeless: Hell, I did 7k as *prot* in H SFK last night
[03:28] <lifeless> spm: we're making a copy archive to test performance of some soyuz q's.
[03:28] <lifeless> StevenK: prot dk ? again...
[03:28] <StevenK> lifeless: Prot pally, dks tanking tree is 'blood'
[03:28] <spm> lifeless: ta
[03:29] <lifeless> StevenK: I roll between 5 and 9 in prot, depending on encounters.
[03:29] <StevenK> Due to classes, we had no reliable CC for the entire instance
[03:29] <StevenK> Although Holy Wrath is awesome again
[03:32] <StevenK> lifeless: Back to work time things. wgrant has tagged my bugs qa-bad, and with the rollback. What will the qatagger do when the new branch hits stable?
[03:32]  * lifeless started work at 6am
[03:32] <lifeless> whats this work time you speak of?
[03:32] <wgrant> StevenK: Your thing is OK to deploy since the rollback./
[03:33] <wgrant> Just tag the bug qa-ok as normal once this thing is QA'd.
[03:33] <StevenK> lifeless: Sorry, s/time/type/
[03:33] <StevenK> wgrant: And leave the rollback tag?
[03:33] <lifeless> StevenK: the rollback comes from the commit, not the bug
[03:33] <lifeless> StevenK: it will all Just Work
[03:34] <wgrant> Leave bad-commit-39423423, though.
[03:41] <StevenK> wgrant: Are you using mawson?
[03:41] <wgrant> StevenK: No.
[03:42] <StevenK> Pondering how best to create test accounts to QA my branch
[03:42] <wgrant> Oh?
[03:42] <wgrant> Ah, the merge one?
[03:42] <StevenK> Yes
[03:42] <wgrant> No need for test accounts.
[03:42] <wgrant> Just find an account with recipes and subsume it.
[03:42] <lifeless> nom nom nom
[03:43] <StevenK> Don't I need to be logged in as that person?
[03:43] <wgrant> You merge them into you.
[03:43] <wgrant> It will send an email to the mergee with a logintoken.
[03:43] <wgrant> You have DB access.
[03:44] <lifeless> or
[03:44] <wgrant> Or use adminpeoplemerge
[03:44] <lifeless> use the staging mailbox to read the email
[03:44] <wgrant> Or that.
[03:44] <wgrant> But that's slow.
[03:44] <wgrant> And non-TLs aren't meant to have access, IIRC.
[03:50] <wgrant> $ bzr push
[03:50] <wgrant> Using saved push location: lp:~wgrant/launchpad/the-death-of-lucille
[03:50] <wgrant> bzr: ERROR: No such file: '/~wgrant/launchpad/the-death-of-lucille/.hg/requires'
[03:50] <wgrant> Pardon?
[03:51] <lifeless> \o/
[03:51] <wgrant> Ah, new bzr-hg this morning.
[03:51] <lifeless> jelmer: ^
[03:57] <wgrant> lifeless: I don't know the archive ID, but "SELECT id FROM archive WHERE owner=2 AND name='bye-bye-asuka'" should tell you.
[03:57] <wgrant> Also, damn, that's a nice UID.
[03:57] <lifeless> wgrant: the boss wanted 1.
[04:14] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/the-death-of-lucille/+merge/48424
[04:16] <StevenK> wgrant: +1'd with a comment
[04:24] <StevenK> wgrant: I have to say, I don't quite like the idea of merging random people into my account on DF
[04:24] <lifeless> Be the big dog.
[04:24] <wgrant> StevenK: :(
[04:25] <wgrant> StevenK: Remove email addresses and OpenIDs from some other account, reassign your cookie or OpenID to that user, then merge people into that.
[04:25]  * StevenK blinks
[04:26] <wgrant> Or is +adminpersonmerge effective here too?
[04:26] <wgrant> I think it might be.
[04:28]  * StevenK tries to work out if a person is a team using only the DB
[04:29] <wallyworld> thumper: can you find that working example we discussed? i can see in firebug the post is happening but it's not getting to the back end code.
[04:30] <StevenK> Ah, teamowner.  A suitable candidate is merging 'liferea' into 'midori'
[04:37] <huwshimi> wgrant: There are other reasons too :P
[04:37] <wgrant> StevenK: ~midori hath no recipes.
[04:37] <wgrant> Oh.
[04:37] <wgrant> It does on dogfood.
[04:37] <StevenK> wgrant:  https://code.dogfood.launchpad.net/~midori/+recipe/development ?
[04:38] <StevenK> And identically named branches
[04:38] <wgrant> doit
[04:39] <StevenK> wgrant: So, I should mark liferea's 3 PPAs as DELETED?
[04:40] <wgrant> StevenK: I'd say so.
[04:40] <wgrant> lifeless: Any idea on QAing that last thing?
[04:41] <wgrant> It's advanced subscriptions stuff.
[04:41] <wgrant> But I'm not sure if it's in the UI.
[04:41] <lifeless> wgrant: join the alpha team
[04:41] <wgrant> I enabled it globally on DF.
[04:41] <wgrant> Still couldn't see the UI anywhere.
[04:41] <lifeless> ok
[04:41] <lifeless> uhm
[04:41] <lifeless> sec
[04:41] <wgrant> Maybe I should grep around.
[04:43] <wgrant> Ah, the new UI is there if you bypass AJAX.
[04:43] <lifeless> spm: so that merge is in the pqm queue in slot 4
[04:43] <lifeless> spm: but the merge to db-devel is in slot 0
[04:44] <lifeless> spm: its liable that staging will blow up as a result.
[04:44] <StevenK> wgrant: Done, what next? :-)
[04:53] <wgrant> StevenK: Did the merge work?
[04:53] <StevenK> wgrant: I'm still trying to work out *how* to do the merge
[04:53] <wgrant> lifeless: Could you mentor https://code.launchpad.net/~wgrant/launchpad/the-death-of-lucille/+merge/48424?
[04:53] <wgrant> StevenK: /people/+adminteammerge
[04:54] <huwshimi> wgrant: Can you show me how to reproduce bug #392079?
[04:54] <_mup_> Bug #392079: "Recent revisions" header on branch page jumps around due to "clear: both" <lp-code> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/392079 >
[04:55] <spm> lifeless: no worries. staging blowing up is nothing abnormal :-)
[04:56] <StevenK> Oh damn it
[04:56] <StevenK> I am a muppet
[04:56] <wgrant> huwshimi: I think that's fixed.
[04:56] <wgrant> there's now just a clear: left;
[04:57] <StevenK> Can I unmerge a team? :-)
[04:57] <huwshimi> wgrant: Want to close that bug then?
[04:57] <wgrant> huwshimi: Doing so.
[04:57] <wgrant> StevenK: Hah. What did you do?
[04:57] <huwshimi> wgrant: Thanks mate :)
[04:57] <StevenK> wgrant: Forgot to merge in my branch *first*
[04:57] <wgrant> Heh.
[04:58] <StevenK> So, bugger
[05:00] <wgrant> lifeless: that's why I branched from and proposed to db-devel :)
[05:00] <lifeless> great minds
[05:02] <wgrant> Grrr
[05:02] <wgrant> nightly.sh still sucks.
[05:02] <wgrant> And it doesn't log :(
[05:08] <stub> Now lets see if this is just good timing, or if this position cuts out the wireless interference from next door.
[05:09] <stub> 0.5% packet loss down from 25-50%
[05:10] <lifeless> nice
[05:22] <lifeless>     Hard / Soft  Page ID
[05:22] <lifeless>      862 / 8918  Archive:+index
[05:22] <lifeless> spm: did that copy archive creation complete?
[05:22] <wgrant> Yes.
[05:22] <spm> yup
[05:23] <lifeless> how hard would it be to add an expander to the subscriber portlets
[05:23] <lifeless> just the 'subscribers' and 'also notified' buts
[05:24] <stub> wgrant: How do you want nightly.sh improved? We should certainly twiddle all the jobs to use --log-file=DEBUG:/srv/wherever/foo.log and only emit errors.
[05:25] <wgrant> stub: it sucks because it doesn't finish within 24 hours, and you can't tell what's going on unless you're subscribed to launchpad-error-reports.
[05:25] <wgrant> Which I am, as of about a minute ago.
[05:25] <stub> launchpad-error-reports only sees logs at the end, so that sucks too.
[05:26] <wgrant> But it at least confirms that update-pkgcache is still running when the next thing starts.
[05:27] <stub> So it needs to echo "Running foo `date`" >> /srv/whatever/nightly.log so we can see wtf it is running, and --log-file added to the command line so we get detailed logs of what is running, syncing the new logs regularly, and commenting out crap running far too long (bugs opened, separate cronjob installed)
[05:27] <wgrant> Ah, there's the full log.
[05:27] <wgrant> Yup.
[05:27] <wgrant> Curtis removed a couple of things during the thunderdome.
[05:28] <huwshimi> Another UI branch to be reviewed when someone has the chance: https://code.launchpad.net/~huwshimi/launchpad/remove-icon-alt-528367/+merge/48430
[05:29] <wgrant> spm: Could you confirm when scriptactivity says update-pkgcache.py last finished? It seems to call itself update-cache.
[05:30] <spm> wgrant: loganberry:update-cache with all the other nightly.sh's
[05:30] <poolie> would someone kindly review https://code.edge.launchpad.net/~mbp/launchpad/701545-oauth/+merge/48431
[05:30] <poolie> it should be very easy
[05:31] <wgrant> spm: When did it finish? It's the one time that isn't logged by nightly.sh.
[05:31] <wgrant> I want to know how far over we are running.
[05:32] <spm> ahh. you should be able to infer that from when the email was actually sent
[05:32] <spm> but one sec
[05:32] <wgrant> Fair point.
[05:32] <wgrant> Oh wow.
[05:33] <wgrant> 7 hours.
[05:33] <spm> but a fix as to "I'm finished date/time" would be nice.
[05:33] <wgrant> Er, no, that's wrong.
[05:33] <wgrant> The time on the email seems to be the time the cron job started :(
[05:34] <wgrant> And pipermail won't give me the headers.
[05:34]  * wgrant finds the mbox.
[05:34] <lifeless> wgrant: so its archive 20929
[05:34] <wgrant> You don't have permission to access /mailman/private/launchpad-error-reports/Week-of-Mon-20110131.mbox on this server.
[05:34] <lifeless> wgrant: what are the enums we expect ?
[05:34] <wgrant> lifeless: The first status is 0, the second 6.
[05:34] <spm> wgrant: https://pastebin.canonical.com/42777/ 15 hours
[05:35] <wgrant> spm: ... ouch.
[05:35] <wgrant> thanks.
[05:35] <lifeless> wgrant: what creates the buildfarmjobs ?
[05:35]  * spm won't mention the name of "nightly".sh ;-)
[05:36] <wgrant> lifeless: populate-archive.py should.
[05:36] <lifeless> launchpad_qastaging=> select count(*) from packagebuild where archive=20929;
[05:36] <lifeless>  count
[05:36] <lifeless> -------
[05:36] <lifeless>      0
[05:36] <lifeless> (1 row)
[05:36] <wgrant> Uh.
[05:36] <wgrant> Could you enable the archive?
[05:36] <wgrant> I can't see it unless it's enabled.
[05:36] <lifeless> url
[05:37] <wgrant> https://qastaging.launchpad.net/ubuntu/+archive/bye-bye-asuka/+edit
[05:37] <wgrant> Oh.
[05:37] <lifeless> timeout
[05:37] <wgrant> Goddammit.
[05:37] <lifeless> OOPS-1860QS14
[05:37] <lifeless> gottendamerung?
[05:37] <wgrant> I bet qastaging is old enough that it doesn't have any natty chroots.
[05:38] <wgrant> Hm, no, it does.
[05:38] <wgrant> upports_virtualized
[05:38] <wgrant> False
[05:38] <wgrant> Fail.
[05:38] <wgrant> We have a half-initialised natty on qas.
[05:39] <wgrant> spm: Could you rerun populate-archive.py with a new archive name, and maverick instead of natty?
[05:39] <spm> sure
[05:40] <spm> hereeeeees-asuka, underway
[05:40] <spm> with apologies to Here's Johnny.
[05:47]  * huwshimi is away
[05:49]  * henninge is here
[05:50] <henninge> Hi!
[05:50] <henninge> Anybody feel like doing a review for me? ;-)
[05:51] <wgrant> Hmm.
[05:51] <wgrant> I wonder if I can just delete all DistributionSourcePackageCache and DistroSeriesPackageCaches for PPAs and copy archives.
[05:51] <wgrant> Nothing uses them except the package count calculation.
[05:51] <wgrant> Which is easily implementable in other ways.
[05:53] <wgrant> And avoids a million inserts a night.
[06:00] <poolie> henninge, i'll happily look
[06:00] <henninge> poolie: thanks, it's https://code.edge.launchpad.net/~henninge/launchpad/devel-710591-sharing-info-groundwork-0/+merge/48416
[06:02] <poolie> i infer you're using Idea - is it good?
[06:04] <poolie> to me it looks clear and well explained and not obviously wrong
[06:04] <poolie> of course i'm not familiar with that code
[06:08] <wgrant> poolie: You lie.
[06:08] <wgrant> poolie: You proposed the branch to the wrong place.
[06:09] <wgrant> lp:~mbp/bzr/trunk
[06:09] <poolie> :/
[06:09] <poolie> that'd be it
[06:09] <wgrant> Scared me for a minute, since I thought I'd fixed that bug two weeks ago.
[06:09] <wgrant> Indeed I had.
[06:09] <poolie> i did check for that but must have glazed over the url
[06:09] <wgrant> Heh
[06:10] <poolie> in https://bugs.launchpad.net/launchpad/+bug/707808
[06:10] <_mup_> Bug #707808: Unmerged revisions list does not exclude merged revisions <qa-ok> <regression> <Launchpad itself:Fix Released by wgrant> < https://launchpad.net/bugs/707808 >
[06:12] <wgrant> stub: You suggest that the script should log stuff directly to a file, but is there a reason to do that over just redirecting its output in crontab?
[06:12] <wgrant> That's what all the rest do.
[06:15] <wgrant> spm: Is qasbounce automatically updating now?
[06:16] <poolie> i just tried make check in a branch off lp trunk and got
[06:16] <spm> wgrant: should be
[06:16] <poolie> a failure in testPPAPublisherOverrides ... connection_raw_execute ... not enough arguments for format string
[06:17] <wgrant> spm: Yay, thanks.
[06:17] <spm> wgrant: qastaging-logs/qastaging-update.log <== should be on carob for qaasbounce
[06:17] <wgrant> poolie: That should have been fixed in r12305
[06:17] <wgrant> poolie: Broke in r12302
[06:18] <wgrant> spm: So it is.
[06:19] <poolie> thanks
[06:31] <lifeless> wgrant: losa long term goal, previously agreed strategy etc
[06:32] <wgrant> lifeless: ECONTEXT
[06:32] <lifeless> wgrant: output logging / redirect for scripts
[06:33] <wgrant> Ah, right.
[06:33] <lifeless> you'd need to talk to tom for more info
[06:33] <lifeless> so, query stil returns 0 rows
[06:33] <lifeless> with archive 20930
[06:33] <wgrant> lifeless: Could you enable it so I can poke around?
[06:34] <lifeless> no
[06:34] <lifeless> I'd love to
[06:34] <lifeless> but I can't even show the edit page
[06:34] <lifeless> is there a trivial UPDATE?
[06:34] <wgrant> Er, what do you mean you can't?
[06:34] <lifeless> e.g. spm: can you please do 'update archive set enabled=TRUE where id=20930' on qastaging
[06:34] <wgrant> It times out?
[06:34] <lifeless> wgrant: yes
[06:34] <wgrant> Huh.
[06:34] <lifeless> OOPS-1860QS19
[06:34] <spm> wgrant: the problem is that LP scripts tend to only write to STDERR. which is bad. because we either get emailed flooded and miss errors, or dump everything to a log and miss errors.
[06:35] <wgrant> It's not complete, but that UPDATe will work for all we need it to.
[06:35] <spm> lifeless: wgrant: is that a real "pls make it so #1" request?
[06:35] <wgrant> spm: Yup.
[06:36] <spm> coo. the ''eg' threw me
[06:36] <spm> UPDATE 1, done
[06:36] <StevenK> You can
[06:36] <StevenK> Sigh
[06:36] <StevenK> You can
[06:37] <StevenK> You can't be Number One, your face doesn't look like balsa wood.
[06:38] <LPCIBot> Project devel build (413): STILL FAILING in 5 hr 11 min: https://hudson.wedontsleep.org/job/devel/413/
[06:38] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless, wgrant][bug=506630, 669288,
[06:38] <LPCIBot> 683798] Also merge recipes on person/team merge.
[06:38] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][bug=676372][rollback=12290] Use a custom python-openid
[06:38] <LPCIBot> which suppresses the Expect: 100-continue that makes loggerhead auth choke.
[06:38] <LPCIBot> * Launchpad Patch Queue Manager: [r=danilo][ui=none][bug=681326] Add a duplicate_only_subscriptions
[06:38] <LPCIBot> set to BugSubscriptionInfo.
[06:41] <lifeless> wgrant: so, ...
[06:41] <lifeless> packagebuild is still 0 rows
[06:41] <wgrant> lifeless: It is.
[06:42] <wgrant> I am chasing that once I work out WTF is up with buildbot-poller.
[06:43] <StevenK> wgrant: Eh?
[06:43] <StevenK> wgrant: What's wrong with buildbot-poller?
[06:43] <wgrant> StevenK: It failed to notice that 12309 is good.
[06:44] <wgrant> Possibly because the next build started immediately after?
[06:45] <wgrant> You've hacked it recently -- do you have any ideas?
[06:45] <lifeless> doubt that, it gets a vector
[06:45] <StevenK> wgrant: It should ignore the currently building job
[06:45] <wgrant> lifeless: Ha ha.
[06:45] <wgrant> lifeless: It gets the last 10 in case the checkout fails.
[06:46] <wgrant> If it was successful, it only uses the last one.
[06:46] <wgrant> But StevenK's suggestion makes sense.
[06:46] <wgrant> Does it log anywhere?
[06:46] <spm> ugh. So I'm ignorant on current "how I build Dev LP". I have an updtaed tree, how do I get the eggs?
[06:46] <lifeless> wgrant: its noting 12307 is good
[06:46] <wgrant> lifeless: It submitted that to PQM ages ago.
[06:46] <lifeless> spm: you should have a dist-cache somewhere
[06:46] <StevenK> spm: utilties/update-sourcecode
[06:46] <wgrant> Is it still doing that?
[06:46] <spm> ta
[06:46] <lifeless> spm: run 'bzr update' in that
[06:46] <wgrant> StevenK: that doesn't do eggs.
[06:46] <lifeless> spm: and then 'make
[06:46] <lifeless> '
[06:46]  * StevenK looks at hudson
[06:47] <wgrant> spm: rocketfuel-get does it all. Otherwise bzr up in ~/launchpad/lp-sourcedeps/download-cache
[06:47] <spm> I suspect my original branch is too old for a dist-cache.
[06:47] <StevenK> spm: If you use the rocketfuel stuff, rf-get works
[06:48] <StevenK> Otherwise, I can furnish you with the script Hudson uses
[06:48] <spm> probably should have gone that path. nm, see if this works.
[06:48] <StevenK> spm: http://pastebin.ubuntu.com/561781/
[06:48] <spm> ta
[06:48] <wgrant> lifeless: Does it log somewhere?
[06:48] <lifeless> wgrant: does what?
[06:48] <wgrant> lifeless: buildbot-poller
[06:49] <lifeless> wgrant: I believe so, on prase
[06:49] <lifeless> wgrant: spm may know the location
[06:49] <StevenK> lp.codehosting.codeimport.tests.test_workermonitor.TestWorkerMonitorIntegrationScript.test_import_hg
[06:49] <lifeless> and if its replicated
[06:49] <StevenK> Failing test on hudson :-(
[06:49] <wgrant> StevenK: It does that occasionally.
[06:49] <spm> I know Nothing!
[06:49] <wgrant> But I haven't seen it on Hudson in months...
[06:49] <wgrant> I blame Windmill.
[06:50] <lifeless> spm: wee, thats a quotes page thing :)
[06:50] <spm> :-)
[06:50] <StevenK> spm: Are you also from Barcelona?
[06:51] <spm> alaas no
[06:51] <StevenK> (I think that's it)
[06:53] <wgrant> spm: hereeeeeeeeeeeeeeeeeeeeeeeeeeeeeees-asuka seems to be a little too natty.
[06:54] <spm> wgrant: hrm. not sure how? https://pastebin.canonical.com/42778/
[06:54] <wallyworld> wgrant: you still working on getting r12290 unblocked?
[06:55] <wgrant> wallyworld: It's stuck behind a laggy buildbot-poller.
[06:55] <wallyworld> ah ok
[06:55] <wgrant> wallyworld: But it should be on qastaging tonight.
[06:55] <wgrant> And I already know it works.
[06:55] <wallyworld> cool :-)
[06:56] <wgrant> Sorry, it should have been done this morning. But curl and testfix intervened.
[06:56] <wallyworld> no problem at all. just trying to get loose ends tidied up sp pqm can close tomorrow
[07:00] <wgrant> spm: headdesk.
[07:00] <spm> oh?
[07:00] <spm> whaddididowrong?
[07:00] <wgrant> spm: That script doesn't take --suite. It's what we've always used, but it doesn't actually do anything.
[07:00] <spm> hahahahaha
[07:00] <wgrant> But we've never copied a non-development series before.
[07:00] <lifeless> I had a private bet on this
[07:00] <wgrant> --from-suite
[07:01] <wgrant> And --to-suite
[07:01] <lifeless> it just ignores unknown options?
[07:01] <wgrant> Try setting both to maverick.
[07:01] <wgrant> lifeless: No, I think --suite is a standard SoyuzScript option.
[07:01] <spm> I've just now had two complaints - from both wife and son - to pls quiet down the laughter
[07:01] <lifeless> wgrant: which isn't used here
[07:01] <wgrant> Right.
[07:01] <lifeless> wgrant: thus effectively unknown :)
[07:02] <wgrant> spm: So, s/--suite maverick/--from-suite maverick --to-suite maverick/, and pick a new appropriately offensive name.
[07:03] <spm> "wgrant-likes-to-deskhead" ?
[07:03] <wgrant> Sounds appropriate.
[07:03] <spm> you'll get me in trouble with my family for laughing too loud again you know!
[07:03] <wgrant> :(
[07:03] <spm> heh
[07:04] <spm> launchpad@asuka:~$ $LP_PY /srv/qastaging.launchpad.net/qastaging/launchpad/scripts/populate-archive.py -v --distribution=ubuntu --from-suite maverick --to-suite maverick -a i386 -a amd64 --to-user=lifeless --to-archive=asuka-wants-to-get-rocked --reason='wgrant hates alive servers'
[07:04] <wgrant> :(
[07:04] <spm> with no apologies to Def Leppard.
[07:08] <wgrant> spm: are buildbot-pollers logs synced anywhere?
[07:08] <wgrant> Add apostrophes as required.
[07:08] <spm> bah. I was chasing that. ta.
[07:08] <wgrant> The build finished 70 minutes ago, yet no push has happened.
[07:09] <spm> Oookay. more to the point. where does the poller run, if indeed it still does.
[07:09] <wgrant> prasé
[07:09] <wgrant> buildbot-poll.py
[07:09] <spm> yeah. found it - was inside another script
[07:10] <spm> should be with the stoick pqm logs. buildbot.log
[07:11] <wgrant> Ah, indeed. How odd.
[07:11] <wgrant> Thanks.
[07:11] <wgrant> Merge request already in queue
[07:11] <wgrant> Well, that's not a very good excuse.
[07:11] <spm> probably a case of "we can easily sync from there over" vs any logical location
[07:12] <wgrant> What calls buildbot-poll?
[07:13] <wgrant> Because that check is crackful.
[07:13] <wgrant> And it's not in lp:lpbuildbot.
[07:14] <spm> parent branch: bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/lpbuildbot/trunk/ ?
[07:15] <lifeless> cron pehraps :P
[07:15] <spm> or do you mean the wrapper script?
[07:15] <spm> or cron...
[07:15] <lifeless> whatever is causing it to not poll when there is a merge proposal outstanding
[07:15] <wgrant> Something stops it from starting if there's already a merge in the PQM queue.
[07:15] <wgrant> That's crackful and I want to delete it.
[07:15] <lifeless> the promotion is orthogonal to the merges.
[07:15] <spm> that's the wrapper script
[07:15] <spm> https://pastebin.canonical.com/42779/
[07:16] <wgrant> I cannot see any reason for that.
[07:16] <wgrant> Oh.
[07:16] <wgrant> Of course, it'll submit multiple times. Bah.
[07:17] <wgrant> Because it's running multiple branches in one instance.
[07:17] <lifeless> the check needs to be inlied
[07:17] <lifeless> rather than as a wrapper
[07:17] <wgrant> Yeah.
[07:17] <spm> it's also been like that for about 1.5 years. so may be dated.
[07:17] <lifeless> you could import the pqm queue class
[07:17] <lifeless> or roll your own
[07:17] <wgrant> Or ignore it and wait for tarmac.
[07:17] <wgrant> It wouldn't be a problem if PQM didn't take 30 minutes to merge a 1-line diff.
[07:18] <lifeless> remove the bzr lookups in the merge and tell pqm to do a lightweight checkout
[07:18] <lifeless> very easy
[07:23] <lifeless> wgrant: so tell me again why we have three tables filtering this query ?
[07:24] <wgrant> lifeless: Hmm?
[07:28] <lifeless> wgrant: anyhow, there is a low hanging fruit
[07:28] <lifeless> wgrant: I've commented in the bug
[07:29] <wgrant> lifeless: Thanks.
[07:30] <lifeless> I suspect it can be made faster by not using except
[07:30] <wgrant> I don't really know why it uses EXCEPT.
[07:30] <wgrant> sinzui: p-r-f seems to be failing with an FTP connection error. Not sure how fatal it is.
[07:31] <lifeless> wgrant: it can be made trivially simpler still by the obvious substitution of the relating column
[07:31] <lifeless> but I doubt that will affect performance
[07:34] <lifeless> wgrant: so in english, from the composite table bpb, pb, bfj, it wants - for all builds ever made in the archive, those with state 0 for which there is no spr with state6 ?
[07:34] <lifeless> what is 0 and 6 ?
[07:34] <wgrant> lifeless: 0 is NEEDSBUILD, 6 is BUILDING.
[07:35] <lifeless> so this is packages for which none of the binarys have started to build?
[07:35] <wgrant> lifeless: I believe so.
[07:55] <lifeless> wgrant: is this used a lot?
[07:55] <lifeless> I have 260ms on 11K packages
[07:56] <wgrant> lifeless: It's used on Archive:+index, but only for copy archives will there be more than a few dozen builds.
[08:20] <lifeless> wgrant: do you happen to know the 'and its done' row count?
[08:21] <wgrant> lifeless: "and its done"?
[08:21] <lifeless> the copy archive
[08:21] <lifeless> we're at 15919
[08:22] <wgrant> Sources?
[08:22] <lifeless> yeah
[08:22] <lifeless> 16077
[08:22] <wgrant> I would have expected the copy to finish an hour ago.
[08:22] <wgrant> Hmm.
[08:22] <wgrant> Odd.
[08:22] <lifeless> 'asuka'
[08:22] <wgrant> Yeah, but on mawson it takes 15 minutes.
[08:22] <wgrant> Although that was only for armel.
[08:22] <wgrant> And main.
[08:22] <wgrant> So 4000 builds, not 27000.
[08:22] <wgrant> I guess that makes sense.
[08:23] <lifeless> 25K binaries so far
[08:24] <wgrant> Must be nearly there.
[08:24] <wgrant> Since maverick is not quite as big as natty, and the natty archive had something like 27000
[08:26] <wgrant> Ugh.
[08:28] <lifeless> wgrant: anyhow
[08:28] <lifeless>  count
[08:28] <lifeless> -------
[08:28] <lifeless>  17185
[08:29] <lifeless> that was
[08:29] <lifeless> 21:29 < lifeless>  count
[08:29] <lifeless> 21:29 < lifeless> -------
[08:29] <lifeless> 21:29 < lifeless>  17185
[08:29] <lifeless> 21:29 < lifeless> (1 row)
[08:29] <lifeless> 21:29 < lifeless> Time: 357.483 ms
[08:29] <wgrant> Aha.
[08:29] <wgrant> So it's quick now>
[08:29] <lifeless> thats the query I've come pu with
[08:31] <lifeless> I think we're done - 17332, 380ms hot.
[08:31] <lifeless> wgrant: this one - https://bugs.launchpad.net/launchpad/+bug/709717/comments/3
[08:31] <_mup_> Bug #709717: Archive:+index timeouts : ArchiveView.num_pkgs_building can be very slow <lp-soyuz> <oops> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/709717 >
[08:32] <wgrant> lifeless: Give me a sec, just untangling the db-devel merge conflict.
[08:39] <wgrant> StevenK: Is your recipe merger qa-ok?
[08:40] <wgrant> It is an optional extra for the next deploy.
[08:40] <wgrant> lifeless: Could you try https://bazaar.qastaging.launchpad.net/~launchpad-pqm/launchpad/production-stable?
[08:40] <wgrant> It auths me properly, but I'd like a second check just in case.
[08:41] <wgrant> Plus your username is longer.
[08:41] <lifeless> OOPS-1860QSCB1
[08:41] <wgrant> Good.
[08:41] <StevenK> wgrant: It is, yes. I was waiting for the mail from the qa-tagger
[08:41] <wgrant> StevenK: Great, thanks.
[08:41] <lifeless> it prompted and passed me through
[08:41] <wgrant> That'll be 20 minute off.
[08:41] <wgrant> lifeless: yeah, it's still screwed, but it's qastaging, not auth.
[08:42] <lifeless> ok
[08:42] <wgrant> We are good to deploy 12309, yay.
[08:42] <lifeless> we should fix that tomorrow
[08:42] <wgrant> Yes.
[08:42] <lifeless> faaaaaaaantastic
[08:42]  * wgrant prepares the request.
[08:42] <wgrant> Oh, damn, still need r12307.
[08:43] <wgrant> But that's easy enough, particularly once allenap arrives in 20 minutes.
[08:45] <adeuring> good morning
[08:49] <wgrant> I think I want to patch qa-tagger to generate a deployment request template.
[08:49] <lifeless> wgrant: theres an open bug for that
[08:50] <wgrant> Since collecting these bug numbers is tedious.
[08:50] <Ursinha> bug 667390
[08:50] <_mup_> Bug #667390: provide wiki syntax bug links in deployable revision reports for easy copying to the LPS report <qa-tagger:Triaged by ursinha> < https://launchpad.net/bugs/667390 >
[08:51] <lifeless> Ursinha: good morning ? :P
[08:51] <Ursinha> lifeless, morning :P
[08:53] <wgrant> Morning Ursinha.
[08:54] <Ursinha> morning
[08:54] <Ursinha> wgrant, I'd be happy to review your patch
[08:55] <wgrant> I'm thinking about how it should handle rollback=
[08:55] <wgrant> I'm not sure there is a sensible way.
[08:56] <lifeless> offer a menu
[08:56] <lifeless> or add in rollforward
[08:56] <lifeless> which is just a yak shave away
[08:57] <lifeless> night all
[08:58] <wgrant> Night lifeless.
[09:01] <Ursinha> good night lifeless
[09:03] <mrevell> Hello
[09:07] <wgrant> Hmm, that's a bit sad.
[09:07] <wgrant> Ursinha: qa-tagger is crashing :(
[09:07] <wgrant> ERROR:qa-tagger:Something went wrong when marking bugs: 'LPQAStagingDeployment' object has no attribute 'deployed_source_revno'
[09:12] <Ursinha> wgrant, where are you seeing this?
[09:13] <wgrant> Ursinha: https://devpad.canonical.com/~lpqateam/qa_reports/logs/output-launchpad-stable.log
[09:13] <Ursinha> wgrant, let me look previous runs logs
[09:13] <wgrant> Ah, it got a 504 from qas.
[09:13] <wgrant> I guess it updated right then.
[09:13] <Ursinha> ah
[09:14] <Ursinha> yes
[09:14] <Ursinha> is qastaging down?
[09:14] <Ursinha> or was
[09:14] <wgrant> It just updated.
[09:14] <wgrant> It's up now.
[09:14] <Ursinha> good
[09:14] <allenap> Morning wgrant, what's up?
[09:14] <Ursinha> there's a bug for this too
[09:15] <wgrant> allenap: Morning. Could you QA r12307, or tell me how to do it?
[09:15] <allenap> wgrant: Sure.
[09:15] <Ursinha> bug 688082
[09:15] <_mup_> Bug #688082: when qastaging is down deployment reports crash and stop updating <qa-tagger:Triaged> < https://launchpad.net/bugs/688082 >
[09:15] <wgrant> It's not entirely obvious, and I'd like to get a rollout done ASAP.
[09:16] <wgrant> Ursinha: Can you easily run it manually, or should I just wait?
[09:17] <Ursinha> wgrant, I can, but maybe it's already running again
[09:17]  * Ursinha checks
[09:17] <StevenK> wgrant: Have you tagged my bugs, or should I?
[09:18] <wgrant> StevenK: Can't until it runs.
[09:18] <wgrant> I think it's */30, but I don't know for sure.
[09:18] <wgrant> StevenK: The last run crashed.
[09:18] <Ursinha> wgrant, yeah, it's running
[09:18] <Ursinha> wgrant, */15
[09:18] <Ursinha> wgrant, https://devpad.canonical.com/~lpqateam/qa_reports/logs/output-launchpad-stable.log
[09:18] <Ursinha> on its way
[09:22] <wgrant> Ursinha: Ah, I see. Thanks.
[09:22] <adeuring> jtv: still aroud?
[09:31] <Ursinha> wgrant, which revisions will you request deployment?
[09:32] <wgrant> Ursinha: 12309
[09:34] <allenap> wgrant: Looks fine, I'll update the bug. However, marking a bug as a duplicate is consistently timing out on qastaging, in recalculateBugHeatCache(). I'm pretty sure that's not my fault :)
[09:35] <wgrant> allenap: That's been happening for weeks. It's fine.
[09:35] <wgrant> Thanks.
[09:35] <allenap> wgrant: Cool :)
[09:38] <Ursinha> wgrant, I see bug 676372 is blocking other revisions in the report, is that really qa-bad?
[09:38] <_mup_> Bug #676372: "Server denied check_authentication" from bazaar.launchpad.net private branch since 11926 deployed <bad-commit-12290> <lp-foundations> <qa-ok> <regression> <Launchpad itself:Fix Committed by wgrant> < https://launchpad.net/bugs/676372 >
[09:39] <wgrant> Ursinha: I fixed that like two minutes ago.
[09:40] <Ursinha> ah, right
[09:40] <wgrant> Heh.
[09:40] <wgrant> I forgot I had to manually fix that up, since the rollback was marked untestable.
[09:45] <bigjools> Ursinha: up early?
[09:46] <Ursinha> bigjools, yes sir
[09:46] <bigjools> or, are you up late
[09:46] <Ursinha> no, up early :)
[09:46] <wgrant> That would be quite late indeexd.
[09:49] <Ursinha> it's rarer to wake up this early than to be up this late :)
[09:49] <bigjools> as I suspected :)
[09:50] <wgrant> I find that I am more likely to be doing workish things when up early then when up quite that late.]
[09:50] <bigjools> the fact that I can't restore any browser tabs with oops reports on them is seriously irritating
[09:51] <wgrant> bigjools: jcsackett has a hack for that.
[09:51] <wgrant> But I believe it's blocked on ISD.
[09:51] <wgrant> And they are sprinting at the moment.
[09:51] <bigjools> does it fix the throwing away of the ?arg ?
[09:52] <wgrant> Yes.
[09:52] <bigjools> \o/
[09:52]  * bigjools goes back to AMI building
[09:53] <Ursinha> bigjools, that's hateful
[09:53] <bigjools> yes, it's making me sad
[09:54] <wgrant> bigjools: AMI building again?
[09:54] <wgrant> Do we have a new apt already?
[09:54] <bigjools> the first one doesn't work
[09:54] <bigjools> I need to build another to see why
[09:54] <bigjools> something wrong with the database, it's not installed
[09:55] <wgrant> bigjools: BTW, I shelved your a-f changes on DF.
[09:55] <wgrant> Then DF crashed.
[09:56] <wgrant> It seems to have survived, but don't be too surprised if something breaks.
[09:56] <wgrant> (it stopped responding to ping and everything)
[09:58] <bigjools> it's been rebooted
[09:58] <wgrant> Right, bradm powercycled it.
[09:59] <wgrant> Could find no explanation for its vanishment.
[09:59] <wgrant> Somewhat concerning.
[09:59] <bigjools> hardware
[09:59] <wgrant> Almost certainly.
[10:03] <bigjools> wgrant: so you QA'd jtv's CommandSpawner stuff?
[10:03] <bigjools> the problem is that it does not fix that bug, it needs a new bug
[10:04] <wgrant> bigjools: Right. It works fine, but does not fix the bug.
[10:05] <wgrant> I will set it back to Triaged when I close everything else later tonight.
[10:06] <bigjools> this is just highlighting that we need to QA revisions, not bugs
[10:06] <wgrant> Yes, it is a bit of an issue. But I think the current process is pretty good apart from that.
[10:06] <wgrant> Although qa-tagger seems to not be doing much right now.
[10:37] <jtv> wgrant: Hi!  So you looked at my MF code?  On staging, or locally, or on dogfood?
[10:37] <wgrant> jtv: MF?
[10:37] <wgrant> a-f?
[10:37] <bigjools> MotherForker....
[10:37] <jtv> Well one of the names I considered was MotherForker.
[10:37] <wgrant> Ah.
[10:37] <wgrant> That would have been better.
[10:38] <wgrant> Yes, I looked at it. Looks good. Even works on DF.
[10:38] <jtv> I don't like calling classes "manager."  Unexpressive.
[10:38] <jtv> Cool!
[10:38]  * wgrant stabs merge conflicts in the face.
[10:38] <bigjools> jtv: there's a backport of a-f available
[10:38]  * jtv cruelly laughs at wgrant turn of phrase
[10:39] <wgrant> jtv: That's the second set I've resolved in two hours.
[10:39] <bigjools> I'd like to stab ec2 in the face
[10:39] <wgrant> db-devel hates me.
[10:39] <jtv> bigjools: fantastic!  But the code that needs that actually does run a-f in parallel.
[10:39] <bigjools> how do you know?
[10:39] <jtv> bigjools: are you asking me or wgrant?
[10:40] <bigjools> jtv: either
[10:40] <jtv> Sigh.
[10:41] <jtv> The problem with the extra apt-ftparchive option only happens in the code that runs all apt-ftparchive instances in parallel.
[10:41] <bigjools> I have a feeling we're not on the same page here
[10:43] <bigjools> stub: around?
[10:43] <jtv> bigjools: Okay, let's start again: "how do you know" what?
[10:43] <stub> yo
[10:44] <bigjools> stub: any idea why my new ami image is failing to find a PG instance?  http://pastebin.ubuntu.com/561519/
[10:44] <bigjools> I am building a new one and pg seems to be installed...
[10:45] <bigjools> jtv: how do you know that the parallelised version of your code works?
[10:45] <stub> bigjools: looks like it is getting confused because PG 8.2 is installed
[10:45] <jtv> bigjools: we don't—so far we only know that we can't run the parallel version on lucid's a-f.
[10:46] <stub> bigjools: And PG 8.4 is not...
[10:46] <bigjools> stub: 8.2 is not installed
[10:46] <jtv> bigjools: I was saying "that's fantastic" because the backport removes that obstacle, not because Now Everything Works Perfectly.
[10:46] <bigjools> jtv: ah :)
[10:47] <bigjools> irc is great
[10:47] <jtv> *However*
[10:47] <stub> grep isn't finding some critical files anyway, so PG 8.4 is not setup on that box or setup weirdly, like in a chroot
[10:47] <jtv> it would also be really really nice if we could now proceed to establish that it works.
[10:47] <jtv> bigjools: yes this is something I hate about IRC too.
[10:48] <bigjools> stub: can you help me debug it please?  I am ssh'ed into the instance as  it's building the image
[10:48] <stub> bigjools: When I've installed PG under Ubuntu, /etc/postgresql/8.4/main/* exists. On that box, it looks like it doesn't.
[10:48] <bigjools> /etc/postgres is not there at all
[10:48] <jtv> postgresql, not postgres
[10:48] <bigjools> just /etc/postgresql-common/
[10:49] <stub> If it is there, then the script is buggered. If not, the PG package installation is buggered. Maybe needs some dpkg magic to set it up?
[10:49] <bigjools> /etc/postgresql is not there at all either
[10:49] <jtv> I think I added some looping over available postgres versions at one point.
[10:49] <stub> I'd uninstall and reinstall the PG packages
[10:49] <jtv> What do you get for ls /etc/init.d/postgres*?
[10:50] <bigjools> stub: /etc/postgresql/8.4/main/ does not exist on mawson, yet it has a functioning database ...
[10:50] <jtv> ahhh
[10:51] <jtv> launchpad-database-setup loops over known postgres versions, from latest to oldest.
[10:51] <jtv> It stops at 8.2, but doesn't check for the case where it didn't find anything.
[10:51] <bigjools> jtv: exactly :)
[10:51] <bigjools> I have /etc/init.d/postgresql-8.4 installed
[10:52] <stub> That script would fail on mawson too then. If PG is setup in a strange way, it won't work because files it needs are not where it expects them.
[10:52] <stub> This is lucid?
[10:52] <bigjools> yes
[10:52] <stub> I have /etc/init.d/postgresql
[10:52] <bigjools> yeah that's maverick
[10:53] <stub> So I'd say the package is installed but some step hasn't been run. dpkg reconfigure or whatever (I just stick to the gui tools).
[10:54] <bigjools> I am just running the "bin/ec2 update-image" script ...
[10:55] <bigjools> that's all that's in the desctructions at https://dev.launchpad.net/EC2Test/Image
[10:55] <stub> I can't really help - I know bugger all about packages or ec2 images.
[10:57] <wgrant> stub: Want to review https://code.launchpad.net/~wgrant/launchpad/nightly.sh-fixes/+merge/48441?
[10:58] <wgrant> (I have to wonder why this is in the tree at all...)
[10:59] <bigjools> stub: well, here's a clue.  Trying to start the PG server and literally nothing happens.
[11:00] <bigjools> not even a message to the terminal
[11:01] <wgrant> Sounds like you might have -common installed, but not the server itself.
[11:01] <wgrant> init scripts will generally exit early if the binary is not present.
[11:01] <bigjools> /usr/lib/postgresql/8.4/bin/postgres
[11:02] <jtv> Or in this case, if /usr/share/postgresql-common/init.d-functions is not present.
[11:02] <bigjools> they are there
[11:02] <jtv> It may help to know what return code you get when you run the init.d script.
[11:03] <bigjools> remind me of the bash-fu to get that?
[11:03] <jtv> echo $?
[11:03] <wgrant> echo $?
[11:03] <jtv> right after the command.
[11:03] <bigjools> 1
[11:03] <jtv> So it's not all those nice "am I installed" checks.
[11:05] <jtv> Note the init.d script runs with -e, so it can be an implicit failure.  Of anything.
[11:05] <adeuring> jtv: could you have a look at this MP: https://code.launchpad.net/~adeuring/launchpad/bug-705652/+merge/48437 ?
[11:05] <jtv> adeuring: I will, yes!
[11:05] <adeuring> jtv: thanks!
[11:06] <bigjools> it's because /etc/postgresql/ is missing, it just bails out
[11:06] <bigjools> no package owns that directory
[11:07]  * bigjools gets caffeine in the hope that the answer will come
[11:07] <jtv> Good idea!
[11:08] <jtv> Colour me copycat.
[11:08] <Ursinha> ☕
[11:09] <stub> wgrant: Fine here. mthaddon might want a look (https://code.launchpad.net/~wgrant/launchpad/nightly.sh-fixes/+merge/48441 )
[11:10]  * stub waits for the intertubes to let him click 'approve'
[11:10] <wallyworld> wgrant: any idea why stuff is so slow to get merged into devel once ec2 has finished with it. and also deployment to qastaging seems slower than usual?
[11:10] <mthaddon> wgrant: we tend to prefer the $(command) vs. `command` convention
[11:11] <mthaddon> (handles escaping slightly better, not that that's relevant here)
[11:12] <wgrant> mthaddon: Ah, I just used the same as the old code.
[11:12] <wgrant> I will fix.
[11:12] <wgrant> wallyworld: ec2 takes a lot longer since windmill was reenabled, and there has been a bit of a PQM backlog the last couple of days.
[11:12] <wgrant> wallyworld: qastaging deployment can also be slow because of the PQM backlog.
[11:12] <wgrant> And buildbot is slow.
[11:13] <wgrant> And buildbot fails a lot now.
[11:13] <wallyworld> wgrant: yeah, i have probably 3 branches that i want to qa before pqm closes and i am waiting for them to appear on qastaging
[11:13] <wallyworld> why is buildbot so flakey?
[11:13] <wgrant> wallyworld: It should start updating in about 30 seconds.
[11:13] <wgrant> wallyworld: To 12314, I believe.
[11:13] <wgrant> wallyworld: Windmill and those spurious librarian failures.
[11:13] <wallyworld> \o/
[11:14] <wgrant> And the occasional bad branch :P
[11:14] <wallyworld> :-P
[11:14] <gmb> Windmill is making me sad today.
[11:14] <gmb> Just wanted to spread it around.
[11:14] <wallyworld> share the love
[11:15] <bigjools> I need to punch something
[11:15] <gmb> Thing is, it's so easy to come to the conclusion that Windmill is the thing that's to blame rather than my shoddy code.
[11:16] <bigjools> stub, jtv: TADA
[11:16] <bigjools> "Error: The locale requested by the environment is invalid."
[11:17] <bigjools> when installing PG
[11:18] <bigjools> it didn't like my LC_LANG of en_GB.utf8
[11:18] <bigjools> now, how do I override that in the setup script
[11:20] <danilos> allenap, hi, I assume bug 151129 is not really fix committed (marked by qa-tagger for one of your branches?)
[11:20] <_mup_> Bug #151129: Can't subscribe to a tag <bad-commit-11972> <bugtag> <lp-bugs> <lp-dogfood> <qa-ok> <story-better-bug-notification> <story-subscribe-to-search> <ubuntu-qa> <Launchpad itself:Fix Committed by yellow> < https://launchpad.net/bugs/151129 >
[11:21] <danilos> allenap, fwiw, we believe we've got a lot more work to do on this, and I am not sure what's the best way to indicate this in the bug tracker now that we are using bugs for QA as well
[11:22] <wgrant> danilos: I try to set those sort of bugs back to In Progress when I close the rest after a deployment.
[11:22] <wgrant> It might be nice if we could tag them somehow to prevent qa-tagger from changing the status, though.
[11:23] <danilos> wgrant, yeah
[11:23] <danilos> wgrant, incremental?
[11:23] <stub> bigjools: LC_LANG=C ./whateveryouarerunning ?
[11:23] <allenap> danilos: I had a discussion with lifeless about this yesterday. I've agreed to only land one branch per bug in the future. It is fix committed for the last branch, fix released in spirit.
[11:23] <bigjools> stub: I meant LC_TIME
[11:23] <bigjools> but yeah, about to try that
[11:23] <wgrant> danilos: --incr prevents QA tags, though.
[11:23] <allenap> danilos: Apparently that causes landing to be marked untestable.
[11:23] <wgrant> Right.
[11:24] <gmb> So, interesting fact: Windmill doesn't work over X-forwarding.
[11:24] <bigjools> it does for me!
[11:24] <bigjools> well, define "work"
[11:24] <danilos> allenap, ah, ok
[11:26] <wgrant> mthaddon: The diff is updated with your requested changes.
[11:26] <wgrant> It even still works.
[11:27] <mthaddon> wgrant: looks good
[11:28] <wgrant> wallyworld: qastaging should be on 12314 in half an hourish.
[11:28] <gmb> bigjools: Well, it loads, then it just sort of stops whilst waiting for a pageload.
[11:28] <bigjools> gmb: oh, it always got further than that for me
[11:29] <gmb> Yeah, well, it's Windmill.
[11:29] <wallyworld> wgrant: cool. thanks. i hate waiting
[11:29] <gmb> Let's not expect consistency here.
[11:29] <jtv> adeuring: don't you mean logger.getEffectiveLevel() > logging.WARN, i.e. with ">" instead of "<="?
[11:29] <wgrant> That often happens even without X forwarding...
[11:29] <gmb> Hah.
[11:29] <jtv> adeuring: sorry, >=
[11:29] <bigjools> It was whenever I forgot to set DISPLAY= before running the tests on a machine I'd ssh'd to
[11:29] <wgrant> wallyworld: I think these deploys would become a lot faster if we cached the built eggs/ dir.
[11:29] <gmb> Also, it's doing it's "I'm going to fail at random points" thing.
[11:29] <gmb> I suspect that the timeouts are a touch too short.
[11:30] <bigjools> or windmill is pants
[11:30] <gmb> Well, that.
[11:30] <wallyworld> wgrant: for sure
[11:30] <bigjools> I think, at the 3rd attempt to build a new AMI, it's DTRT at last
[11:30] <wgrant> Yay, private codebrowse works on production again!
[11:31] <bigjools> wallyworld: you are a crazy guy - up at 3am - and you're still up?!
[11:31] <wgrant> stub, mthaddon: Thanks for the reviews.
[11:31] <wallyworld> bigjools: no rest for the wicked :-)
[11:31] <gmb> allenap: Are you OCRing today?
[11:31] <adeuring> jtv: no, I think level <= WARN is correct:
[11:32] <allenap> gmb: Oh yes. What have you got for me?
[11:32] <adeuring> >>> import logging
[11:32] <adeuring> >>> logging.DEBUG
[11:32] <adeuring> 10
[11:32] <adeuring> >>> logging.WARN
[11:32] <adeuring> 30
[11:32] <adeuring> >>> logging.ERROR
[11:32] <adeuring> 40
[11:32] <gmb> allenap: JS fun and games: https://code.launchpad.net/~gmb/launchpad/make-subscriptions-editable-bug-710603/+merge/48359
[11:32] <gmb> allenap: To test the UI you need to add a feature flag for "malone.advanced-subscriptions.enabled"
[11:32] <allenap> gmb: I chose a bad day to quit glue sniffing.
[11:33] <gmb> Yeah.
[11:33] <gmb> My sympathies.
[11:33] <allenap> gmb: Okay, how do I add a feature flag?
[11:33] <gmb> allenap: Using PSQL works quite well. Hang on, I'll paste you the necessary.
[11:34] <gmb> allenap: http://pastebin.ubuntu.com/561875/
[11:34] <allenap> gmb: Ta.
[11:35] <wgrant> allenap, gmb: There's UI too.
[11:35] <wgrant> I used it on DF earlier.
[11:35] <wgrant> It's pretty nice.
[11:35] <gmb> wgrant: I always forget about that because it needs rubber ducky powers in production / staging / qastaging
[11:35] <gmb> But you're right.
[11:37] <allenap> wgrant: Is it a big textarea? Truth be told, I don't understand feature flags properly so it was greek to me.
[11:38] <jtv> adeuring: you're right :)
[11:38] <wgrant> allenap: It's a big textarea, yes. But it is very pretty and shows diffs and avoids SQL, and has a link to a page which documents possible flags and scopes and their values.
[11:39] <allenap> wgrant: Neat :)
[11:39] <jtv> adeuring: it may help to extract that piece of code into a function by the way.  The script (mea culpa) does far too little of that.
[11:40] <adeuring> jtv: right, makes sense
[11:42] <jtv> adeuring: btw looking at this brings up a far greater concern—the script in its current form is hard-wired to remove Ubuntu translations.  Won't work for upstream ones AFAICT.
[11:43] <adeuring> jtv: do you mean setting is_current_upstream?
[11:43] <jtv> Which isn't surprising really, given that the bug mentions making it side-aware.
[11:43] <adeuring> jtv: setting is_current_upstream would be even more difficult.
[11:43] <jtv> Well it may need to set either is_current_upstream or is_current_ubuntu, depending on which side the template is on.
[11:44] <adeuring> I discussed this woth Henning and Danilo, and we agreed that it is not worth the effort to implement this
[11:44] <jtv> There's a helper class, TranslationSideTraits, which knows things like "what is the name of the flag that applies for translations on this side."
[11:44] <adeuring> jtv: I know about this class -- the main issue is: Setting an Ubuntu translation as current in upstrem might simply be wrong...
[11:45] <jtv> Yes, but that's a separate policy issue.
[11:45] <jtv> Isn't that basically just a big "if" around the unmasking code?
[11:46] <danilos> jtv, from my glance at the script, it seems to have both is_current_upstream and is_current_ubuntu options
[11:46] <danilos> jtv, and it seemed pretty symmetric to me, fwiw
[11:46] <danilos> (other than the "unmasking")
[11:46] <jtv> danilos: it has both options for what exactly?
[11:47] <adeuring> I don't think it works for is_current_upstream. But making the script "more symmetric" regarding finding another is_current_(upstream|ubuntu) would affect poilcy...
[11:47] <jtv> Yes, but that's only the unmasking code which should simply be skipped when deleting on the upstream side.
[11:47] <danilos> jtv, it has an option for removing is_current_ubuntu translations, and option for removing is_current_upstream translations
[11:48] <adeuring> well, you can delete translations for upstream and ubuntu in one script run.,..
[11:48] <jtv> danilos: oic—yes, so it should be able to do both.
[11:48] <jtv> Ah
[11:49] <danilos> jtv, adeuring: the only thing is that you have to specify the side yourself when you run the script, other than that I think it's fine
[11:50] <jtv> I'm looking again… maybe it's just the unmasking code that has the hard-coding.
[11:51] <adeuring> danilos: ? you can set --is-current-upstream and --is-current-ubuntu, but this affect the filter which messages shall be dleteld
[11:51] <adeuring> but it does not affect the question if any other translation should become current instead
[11:51] <danilos> adeuring, right, that's what we are calling "unmasking" (as per the code itself, fwiw :)
[11:52] <jtv> danilos: I think he means the asymmetry in when we should unmask.
[11:52] <adeuring> well, ok... but... perhaps I am a bit slow, but what does this mean for the script?
[11:52] <jtv> In other words, the fact that unmasking on the upstream side is dangerous because it activates Ubuntu messages in upstream.
[11:53] <adeuring> jtv: right, that's what I mean
[11:53] <danilos> jtv, right, but I believe we have hard-coded unmasking only for ubuntu side, because that's the only thing that made sense in the past
[11:54] <danilos> worth checking, of course :)
[11:54] <jtv> At the moment that's a bit implicit in the code (even though it's well-documented); it may make sense to extract unmasking into a function and put an "if" around it.
[11:54] <danilos> jtv, sure, agreed
[11:54] <danilos> anyway, I am just introducing more confusion into the discussion, so I'll be quiet :)
[11:54] <jtv> No, no, it's fun!
[11:55] <danilos> heh, it sure is :)
[11:55] <jtv> adeuring: I _think_ the script only removes messages on one, user-selected side (ubuntu or upstream).
[11:55] <jtv> What may not have been worth the trouble, but would have been nice, is to detect automatically which side that should be based on what templates are selected.
[11:56] <adeuring> jtv: well, you have a ton of options to select messages. If you specify simply IDs, both sides can be affected
[11:56] <jtv> ah, clever!
[11:56] <jtv> Never even thought of supporting that, to be honest.
[11:57] <adeuring> similar for filtering ny reviewer or translator
[11:58] <jtv> Sorry for all the confusion; I'm a bit rusty with this script.
[11:58] <jtv> The "current_ubuntu" and "current_upstream" flags are further filters, not choices of side.
[11:59] <adeuring> jtv: well, my main conclsuion regarding bug 705652 was: it's not worth to make the script more clever, but it makes sense to give more warning
[11:59] <_mup_> Bug #705652: Make remove_translations side aware. <upstream-translations-sharing> <Launchpad itself:In Progress by adeuring> < https://launchpad.net/bugs/705652 >
[12:00] <jtv> One relatively simple option might have been to require that the caller choose a side.
[12:00]  * gmb -> lunch
[12:00] <adeuring> ...and I removed the clause "imported.potemplate = doomed.potemplate" because does not seem to make sense
[12:00] <gmb> allenap: I'll respond to your review when I return.
[12:00] <allenap> gmb: Cool. I haven't done it yet :)
[12:00] <adeuring> jtv: ok, we can do that. But how would that be an important feature?
[12:00] <jtv> adeuring: yes, I think that's a holdover from a relatively mechanical conversion.
[12:01] <jtv> adeuring: true, feature-wise all it brings us is more speed and limited protection against typos in ids.
[12:02] <jtv> Which isn't a huge deal.
[12:02] <jtv> I'll try to stay away from the bikeshed.  :)
[12:02] <adeuring> I am more inclined to make the script simpler... like the clean up of the WHERE clause. I neede some time to figure out that it was just obsolete...
[12:03] <jtv> Yes, that's also why it's there: massive conversion to the new model didn't allow us much time to contemplate that.
[12:03] <jtv> So we thank you for spotting it.
[12:05] <deryck> Morning, all.
[12:05] <adeuring> morning deryck
[12:05] <jtv> adeuring: It does raise the question: does removing a diverged translation unmask a shared one?  But that's not a "sides" issue, more a concern about a previous migration.
[12:05] <jtv> Or wait.
[12:05] <adeuring> jtv: I think it does. But isn't this a useful feature?
[12:06] <jtv> Yes.  It gets complicated in unexpected ways: deactivating a diverged message should unmask an underlying shared one, not a shared one from the other side.
[12:07]  * jtv ponders
[12:07] <adeuring> jtv: if we try to figure out if there was another diverged translation being is__current_whereever before, we're close to the undo feature...
[12:07] <jtv> No, no, previous diverged translations can go take a hike.
[12:07] <adeuring> that would be really cool, but it should not be implemented in this script, i think
[12:07] <jtv> We don't _like_ translations to be diverged.  :)
[12:08] <adeuring> maybe, but I think there are valid/useful situation
[12:08] <jtv> Well we do support them.  We just don't encourage them.  :)
[12:08] <adeuring> but anyway, if we unmask a shared thanslation automagically, that's just fine, isn't it?
[12:09] <jtv> Yes, I was just verifying that the new code does that.
[12:10] <jtv> (The "Imported" table aliases in the queries are misleading by the way: that's a name from the old model.  Now they would be either Upstream or OtherSide, depending)
[12:10] <jtv> (Or Alternate)
[12:10] <adeuring> jtv: can we leave this for a another "cleanup" bug?
[12:10] <jtv> Sure.
[12:11] <jtv> Sorry to hold you up like this; I need to restore a lot of forgotten detail in order to grok the work.
[12:13] <jtv> I didn't know about the log handler.  You make nice use of it.
[12:14] <jtv> adeuring: in the last paragraph of the diff, "current" really should be "ubuntu" or future readers will misunderstand.
[12:15] <adeuring> jtv: right, that should read "When a shared, current Ubutnu message is deleted..."
[12:15] <jtv> Well maybe not Ubutnu.  ;-)
[12:16] <adeuring> sure ;)
[12:18] <jtv> adeuring: meanwhile, you have my vote.
[12:18] <jtv> Thanks for doing this.
[12:18] <adeuring> jtv: Thanks!
[12:19] <jtv> Ursinha: did you paste that coffee cup (e.g. from the character map), or do you know of a way to type it?  It's so incredibly useful.
[12:19] <Ursinha> jtv, I pasted
[12:20] <jtv> Ah blast ☹  I would so love to be able to type this (without customizing config I can barely read)
[12:20] <wgrant> I think we need to add it to the compose key map and SRU to all supported releases.
[12:20] <Ursinha> me too!
[12:20] <jtv> Yes!
[12:20] <Ursinha> hahaha
[12:20] <jtv> I want my "ij" ligatures too.  But I'm told they're discouraged now.
[12:23] <salgado> jelmer, do you know of a good howto-style guide for using bzr and Launchpad?
[12:34] <jelmer> salgado: I think one of the bzr docs describes it pretty well. Let me see if I can find a link...
[12:35] <jelmer> salgado: http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/using_bazaar_with_launchpad.html?highlight=launchpad
[12:35] <salgado> jelmer, cool, thanks!
[12:37] <jtv> jam: free to discuss bug 701329 today?
[12:37] <_mup_> Bug #701329: loggerhead OOPS - error: [Errno 32] Broken pipe <oops> <Launchpad itself:Triaged> <loggerhead:Invalid> < https://launchpad.net/bugs/701329 >
[12:41] <bigjools> this ec2 management stuff is archaic
[12:42] <jtv> bigjools: which is great because we'll also need that backport in our AMI.
[12:48] <bigjools> and now my 4th attempt at making an AMI
[12:53] <gary_poster> stub, hey.  Could you take a look at https://code.launchpad.net/~gary/launchpad/bug548-db-2/+merge/48318 ?  I had to change it significantly.  allenap, you would be a great code reviewer too, if you are willing and able.
[12:54] <allenap> gary_poster: Okay, cool.
[12:54] <LPCIBot> Project devel build (414): STILL FAILING in 6 hr 15 min: https://hudson.wedontsleep.org/job/devel/414/
[12:54] <LPCIBot> * Launchpad Patch Queue Manager: [r=sinzui][ui=sinzui][bug=708436] Fixed the width of the tag list so
[12:54] <LPCIBot> it doesn't wrap (bug #708436).
[12:54] <LPCIBot> * Launchpad Patch Queue Manager: [r=stevenk,
[12:54] <LPCIBot> thumper][ui=sinzui][bug=670452] Add display of related branches to
[12:54] <LPCIBot> recipe add and edit pages
[12:54] <_mup_> Bug #708436: Bug tag list wrapping <css> <qa-needstesting> <ui> <Launchpad itself:Fix Committed by huwshimi> < https://launchpad.net/bugs/708436 >
[12:54] <LPCIBot> * Launchpad Patch Queue Manager: [r=stevenk, thumper][bug=654585,
[12:54] <LPCIBot> 710291] Linkify and preserve line breaks in the bug acknowledgement
[12:54] <LPCIBot> message.
[12:54] <LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][ui=none][bug=680733] Fix query used to load recipe build
[12:54] <LPCIBot> jobs so those which have failed to build expire off the recent
[12:54] <LPCIBot> builds list as expected
[12:54] <LPCIBot> * Launchpad Patch Queue Manager: [rs=sinzui][ui=none][bug=711527][no-qa] Migrate widgets to the lp
[12:54] <LPCIBot> tree.
[12:55] <gary_poster> thank you
[12:57] <jtv> bigjools: is there anything I need to do to get the a-f backport rolled out (df, *staging, AMI, production)?
[12:59] <bigjools> jtv: file an RT to get the package installed on DF + cocoplum, plus PQM and buildbot
[12:59] <bigjools> the AMI you need to do yourself, but please wait since I am currently doing one
[12:59] <jtv> bigjools: OK… where do we keep this backport?
[13:00] <bigjools> jtv: the losas will install it to CAT, but we also need to copy it from mvo's PPA to the launchpad PPA
[13:00] <bigjools> put it in the LP PPA first
[13:00] <jtv> bigjools: what _is_ CAT?
[13:00] <bigjools> and make it a dependency of launchpad-dependencies
[13:01] <bigjools> canonical admin team
[13:01] <jtv> _thank_ you!
[13:01] <bigjools> they have their own prod repo
[13:02] <jtv> They run a business reposessing cattle prods?
[13:02] <bigjools> this is a good time to go to lunch methinks
[13:25] <gary_poster> stub, thank you again.
[13:25] <gary_poster> I did a fair amount of changes and investigation--and had to throw out some of the more interesting parts of your patch--because I thought you actively wanted to separate person and team bits.
[13:25] <gary_poster> Would you like me to throw together another branch just with the verbose_bugnotifications changes?  It would probably be easy.
[13:25] <gary_poster> I tended to think that it would be easier to have a shared settings object too, but it is true AFAIK that selfgenerated_bugnotifications will be specific to people and not teams, so attributes like that exist (I think).
[13:37] <gmb> allenap: Yay for fragile JS.
[13:37] <gmb> I'll look into that shortly.
[13:44] <allenap> gmb: Yeah :) You can ignore [2] and on, don't worry, they're just my mumblings. And [1] is only a suggestion.
[13:46] <gmb> Noted, thanks.
[13:55] <stub> gary_poster: I do want PersonSettings and TeamSettings separate. But your observation threw a spanner in the works. We need to think more about settings shared between teams and people before moving them to PersonSettings.
[13:55] <gary_poster> stub, ah ok.  cool, I'll leave it alone then.  Thanks
[14:19] <deryck> henninge, I'll just take a look at the branch for you now.  to review it.
[14:20] <henninge> deryck: thanks, I'll look at Aaron's
[14:20] <henninge> deryck: did you just hear me OK or was I a bit faint?
[14:20] <deryck> henninge, no, I heard you fine.
[14:20] <henninge> ok, cool
[14:26] <deryck> henninge, what's the bzr ignore for .idea for?
[14:27] <henninge> deryck: I am trying out pyCharm, the idea that Ian demostrated in Dallas.
[14:27] <henninge> deryck: that is using that directory.
[14:27] <deryck> ah, ok
[14:28] <deryck> henninge, and what have you disabled for pylint in the test?  (Sorry don't know those codes myself.)
[14:29] <henninge> oh, that must be a copy-and-paste error ... ;)
[14:29] <henninge> deryck: I'll remove that.
[14:29] <deryck> henninge, ok, cool.
[14:59] <LPCIBot> Project db-devel build (338): FAILURE in 5 hr 0 min: https://hudson.wedontsleep.org/job/db-devel/338/
[15:01] <deryck> gah!  adeuring, call time.  Sorry.  Was doing henninge's review.
[15:01] <adeuring> deryck: no problem
[15:01] <henninge> yeah right, blame it on me ... ;)
[15:01] <deryck> adeuring, let's bump it a half hour, if that doesn't throw you off.  and let me finish this review.
[15:01] <adeuring> deryck: sure, let's do that
[15:01]  * deryck always blames henninge
[15:02] <deryck> :-)
[15:02] <deryck> henninge, I have questions/comments about the review... can we get on Mumble for higher bandwidth?
[15:08] <jml> sinzui: hi
[15:08] <sinzui> hi jml
[15:08] <jml> sinzui: what's the status of the team subscription policy discussion?
[15:08] <sinzui> I am resolving a merge conflict now. I will send it to ec2 in 25 minutes
[15:11] <leonardr> allenap, would you like to review a wadllib branch? they're incredibly rare
[15:15] <leonardr> jcsackett: maybe you want to review it? https://code.launchpad.net/~leonardr/wadllib/what-kind-of-link/+merge/48485
[15:16] <jcsackett> leonardr: sure.
[15:22] <leonardr> aargh... did someone do a 1.1.8. of wadllib and not tell me? how did this happen?
[15:23] <bigjools> latest devel pull is giving me a conflict on lib/canonical/widgets.moved
[15:23]  * sinzui hands leonardr a dagger.
[15:23] <sinzui> bigjools: I just got that
[15:24] <leonardr> the trunk says 1.1.7, but pypi says 1.1.8
[15:24] <bigjools> sinzui: and Conflict adding file lib/canonical/widgets.
[15:24] <sinzui> I was going to send an email when I got distracted by seemingly impossible merge conflicts with lp.bugs.emum
[15:24] <bigjools> I am freaking doomed trying to land my branch
[15:25] <sinzui> bigjools: rm -r lib/canonical/widgets.moved, then resolve the three listed dirs
[15:26] <bigjools> sinzui: yeah, I just wish I'd not encountered it in ec2.... :)
[15:26] <sinzui> right. Why did it land without a conflict?
[15:28] <jml> sinzui: oh, as in you're landing a patch? great news :D
[15:29] <sinzui> jml: yes. mrevell approved the text/help revisons a few hours ago
[15:30] <allenap> leonardr: Yeah, sure.
[15:30] <leonardr> allenap: jcsackett has it
[15:31] <allenap> leonardr: Okay. I would have to choose now to get a cup of tea. Next time.
[15:41] <sinzui> allenap: do you have time to review https://code.launchpad.net/~sinzui/launchpad/itemswidgets-term-title-1/+merge/48483
[15:41] <allenap> sinzui: Sure.
[15:43] <allenap> sinzui: I got an Unauthorized error followed by Chromium's "This web page is not available".
[15:44] <allenap> sinzui: Back to simple Unauthorized now: http://pastebin.ubuntu.com/562026/
[15:44] <allenap> Any ideas?
It's the zcml, you'll see.  Knew it the first time I met it.</mutter>
[15:46] <jcsackett> leonardr: r=me, with a few suggestions. i've requested follow up from sinzui.
[15:47] <leonardr> ok
[15:47] <sinzui> allenap: someone change my branch to private without making suer we can access.
[15:48] <sinzui> branch privacy is "funking" retarded
[15:48]  * sinzui looks
[15:48] <sinzui> sweet only me and admins can see the branch
[15:51] <sinzui> allenap: I subscribed you to the branch
[15:51] <allenap> sinzui: Thanks, got it.
[15:52] <sinzui> I see we have ~launchpad-reviewers setup to leak private information to a list
[15:53] <allenap> sinzui: Perfect :)
[15:53] <leonardr> jcsackett, sinzui: i've incorporated your comments and i've also been able to reconstruct the missing version 1.1.8 (benji's fault)
[15:55] <bigjools> so it turns out that ec2 land doesn't warn about uncommitted revisions.... :'(
[15:55] <jtv> ouch
[16:06] <jcsackett> leonardr: cool.
[16:23] <jml> branch up for review: https://code.launchpad.net/~jml/launchpad/sphinx-it-up/+merge/48502
[16:24] <leonardr> jcsackett, sinzui: i added another useful method while i was at it. it's revision 23 and very simple
[16:37] <jcsackett> leonardr: looks fine by me.
[17:00] <sinzui> leonardr: r=me
[17:02] <maxb> AWOOGA: Code import farm is broken. SourceForge have changed their SSL certificate such that every https: import now blocks with a "This certificate is untrusted: (R)eject, accept (t)emporarily or accept (p)ermanently?" prompt, until the import times out after an hour.
[17:03] <maxb> I think we need to find a LOSA to use SQL to suspend all code imports matching https://%.svn.sourceforge.net/%
[17:05] <maxb> gary_poster: It's not exactly CHR, but.... ^^^
[17:05] <gary_poster> maxb, ack, I'll try to wave my arms around.  ythanks
[17:06] <leonardr> jcsackett: maybe you want to take the follow-up branch as well
[17:06] <leonardr> https://code.launchpad.net/~leonardr/lazr.restfulclient/know-your-limitations/+merge/48511
[17:07] <jcsackett> leonardr: sure.
[17:07] <jcsackett> jml: sorry, missed your branch up for review. i'll hit it after leonardr.
[17:07] <jml> jcsackett: thanks.
[17:07] <jcsackett> unless allenap is already looking at it.
[17:08] <allenap> jcsackett: Nope, not yet.
[17:10] <gary_poster> maxb: is the certificate change legitimate and permanent?  I don't see an announcement with a quick google search
[17:11] <maxb> uncertain. I just know it's breaking the importd farm right now. Furthermore, due to the way svn stores certificate exceptions, it would need an exception stored for *each separate sourceforge project*, so that's not feasible
[17:18] <henninge> abentley: Thanks for the reply! Can you please push your changes? Or are you not done yet?
[17:18] <abentley> henninge, I have pushed my changes and emailed a diff.
[17:18] <henninge> hm
[17:19] <abentley> Well, I emailed a diff.  Now I've pushed the changes.
[17:19] <henninge> ah, there is the diff! Thanks!
[17:22] <abentley> henninge, I replied before I started work, so that if you had further comments, I would get them sooner.
[17:22] <henninge> ah!
[17:25] <henninge> abentley: only other comment is that you could use ResultSet.is_empty() but that is just an optimization.
[17:25] <henninge> abentley: thank you for the fixes, r=me
[17:26] <abentley> henninge, thanks.
[17:26] <gary_poster> emergency-ish: who is on bug rotation right now?
[17:27] <gary_poster> that is here and available to do some investigation?
[17:28] <gary_poster> deryck, do you happen to know where I can find a list of people on bug rotation?
[17:29] <gary_poster> ah, flacoste's email might work...
[17:29] <deryck> gary_poster, hmmm, I feel dumb.  I don't know what bug rotation is.
[17:29] <gary_poster> deryck, I mean, not doing feature work
[17:29] <gary_poster> squad stuff
[17:29] <deryck> gary_poster, ah.  red and green, I believe.
[17:29] <gary_poster> ok thanks
[17:30] <deryck> gary_poster, "bug rotation" sounds much better than "import work" :-)
[17:30] <gary_poster> :-)
[17:31] <deryck> gary_poster, gah.  ruined my funny.  that was meant to be "interrupt work" but yes, the two names are equivalent often.
[17:31] <gary_poster> heh, yeah
[17:38] <allenap> jcsackett: If you have time, would you be able to take a look at https://code.launchpad.net/~allenap/launchpad/remove-addChangeNotification/+merge/48351? I won't be around to ask question of though.
[17:42] <jcsackett> leonardr: your diff shows you bumbing wadllib to 1.20; i thought even given the oddities in wadllib version we were now at 1.19?
[17:45] <gary_poster> maxb, do you happen to have some specific failing branches you could send me very quickly?
[17:45] <gary_poster> links
[17:45] <jcsackett> sinzui: think you might be able to mumble around 1pm? i finally got some test runs back for the not-ec2ing assertion error branch, and have a weird error i cannot figure out.
[17:46] <sinzui> jcsackett: I have interviews at 1 and 3
[17:46] <jcsackett> sinzui: nevermind then. :-)
[17:46] <maxb> gary_poster: Pretty much anything currently on the importds: https://code.launchpad.net/+code-imports/+machines (because each problem import sticks around on the importds for 1 hour)
[17:47] <gary_poster> maxb, many thanks
[17:48] <jcsackett> allenap: looking at your branch now.
[17:49] <sinzui> mbarnett: maxb I see https://dev.launchpad.net/ReviewingCodeImports suggests changing https to http for SF. Do either of you know if there are projects that are https-only
[17:50] <maxb> urgh
[17:50] <maxb> that wiki page advice is greivously out of date
[17:50] <maxb> I now change all new sf imports *to* https, because they have stupid connection timeouts on http that break long operations
[17:50] <sinzui> I suspected as much. I found it from an obsolete CHR page
[17:51] <leonardr> jcsackett: i decided to take it to 1.2.0 since i added new features
[17:51] <jcsackett> leonardr: okay, cool. i missed that bit.
[17:51] <maxb> If we change all existing URLs to http, most of them will probably keep going because they'll only be importing a few revisions at a time. However, new imports over http from SF generally fail
[17:52] <maxb> So it might be worth doing that, to preserve service levels as best we can
[17:56] <danilos> deryck, hi, do you happen to know if BugNotificationRecipients are "expanded"? (i.e. if we are creating notifications for entire team, we evaluate it and create them by person instead)
[17:57] <deryck> danilos, I believe the rule is "if the team doesn't have a contact address, send to individuals"
[17:58] <danilos> deryck, right, but do you know where is that rule applied? I'm trying to modify addChange/addChangeNotification to remove the changee if they don't want email they generated themselves (by using recipient_set.remove(changee)), but I just figured that we might have a team in there which includes the changee, so that might not work
[17:59] <danilos> deryck, I guess it's best if I write a test for this just to be sure :)
[18:01] <deryck> danilos, I'm looking at the code.  I assume it's where the recipient list is built, but am checking....
[18:03] <danilos> deryck, I was doing the same thing, and then figured it's faster to ask :)
[18:04] <deryck> danilos, yeah, no. :-)  Sorry, but I never could keep this all in my head.
[18:04] <deryck> it's moved around a bit lately, too.
[18:05] <danilos> deryck, yeah, I know, and it's still moving around according to allenap :) anyway, I wrote a test which confirms that team is in the list of notifications, which means that it's just a tad bit harder for me to figure out :)
[18:08] <deryck> danilos, lib/canonical/launchpad/doc/notification-recipient-set.txt confirms how it all works.
[18:10] <danilos> deryck, basically, since notifications are async, we don't have enough information to decide this when they are actually sent out
[18:11] <danilos> deryck, how would you feel about: 1) adding "changed_by" DB column to BugNotification and/or BugNotificationRecipient and 2) flattening out teams for which the changer is member of?
[18:12] <danilos> deryck, I'm leaning to 2), and I'd only do it when the "changer" actually wants to suppress email for his changes, but if this happens inside POST requests, it'd be a terribly bad idea
[18:13] <deryck> danilos, so the point is to suppress my own emails, if I've selected this as a configurable option for bug mail?
[18:13] <danilos> deryck, exactly
[18:13] <danilos> triple digit bug, fwiw, 548 :)
[18:14] <deryck> hmmm, db change seems heavy weight.  I would think we could turn this off when we build the recipient list.  or is the db column for performance?
[18:15] <danilos> deryck, well, it'd move any harder decision logic back to the backend, so yes, DB field would be for performance
[18:15]  * deryck is thinking
[18:16] <danilos> deryck, basically, if we don't introduce "changer" in the DB, we'd have to evaluate all team members and add notification rows for each of them except the "changer" (in this case: I wouldn't change how it behaved previously)
[18:17] <danilos> deryck, and since this might be happening on each change to a bug through a web page, if there's a very large team a person is a member of, it may mean a very large number of rows being inserted, and we know that causes trouble
[18:17] <danilos> deryck, (iow, I've stopped leaning to 2, and lean more to 1 now, though I'd love to be told that 2 is better because it's easier :)
[18:19] <deryck> I'm not convinced we need either :-)
[18:19]  * deryck is still thinking
[18:19] <danilos> deryck, excellent, I'd be happy to hear any other option :)
[18:21] <danilos> deryck, (though, to be honest, I don't believe there is any other option, but I'd be delighted to be proven wrong :)
[18:33] <lifeless> danilos: deryck: FWIW I'd probably add change to the notification if its not there already
[18:33] <lifeless> but I'm simple minded
[18:33] <lifeless> *changer*
[18:35] <deryck> danilos, lifeless -- so I would favor just changing construct_email_notifications to drop the notification if person has this config flag set and he/she is the changer.  can we not work out who the changer is from that function?
[18:37] <deryck> I thought if person == email_person in that function, we would have the changer.  but I'm not entirely sure, even after having read through it all, jumping around a bit now.
[18:38] <danilos> deryck, there's nothing in either of bugnotification/bugnotificationrecipient which can tell us who the changer is
[18:39] <danilos> deryck, we can probably parse one of rationale or something but that'd be pretty fragile
[18:39] <danilos> lifeless, so, I am generally in agreement, thanks for the support :)
[18:39] <deryck> danilos, who is BugNotification.message.owner  ?
[18:40] <danilos> deryck, I don't know, but isn't that just for comments?
[18:40] <leonardr> sinzui, the sooner you can mentor jcsackett's review of my lazr.restfulclient branch, the better--it's all i need to land a huge launchpad branch
[18:41] <danilos> deryck, fwiw, bugnotificationrecipient.person is the actual recipient (eg. a team in the case I want to solve)
[18:41] <sinzui> leonardr: I am on the phone at the moment I will get to it in 30min
[18:41] <leonardr> sinzui, ok
[18:41] <deryck> danilos, I thought "message" was the message being sent, not just a comment.
[18:41] <lifeless> deryck: does construct_email_notifications run in the webserver context ?
[18:41] <deryck> lifeless, nope
[18:41] <danilos> deryck, and you are right, it is the message being sent
[18:42] <lifeless> so something a little unrelated
[18:42] <lifeless> that I'd like us to do
[18:42] <danilos> deryck, and owner does seem to be the person who changed stuff, wooohooo
[18:42] <lifeless> is to setup valid participations in backend services
[18:42] <deryck> danilos, so if the message owner is the person who created the notification -- i.e. the changer -- then I see no point in storing that in the db.  especially since this runs offline.  however....
[18:42] <deryck> danilos, if I'm wrong, feel free to add a column. :-)
[18:43] <lifeless> this would let you look up the participation to find out who the work is being done on behalf of
[18:43] <danilos> deryck, agreed
[18:43] <deryck> danilos, the down side of adding it if it's already there, is that people will create new queries where none exist today.  just cause they can :-)
[18:43] <danilos> deryck, yeah, it's just that I didn't really understand what message was, but you were right all along
[18:44] <deryck> danilos, no worries.  Wasn't trying to prove myself right.  Just wanted to avoid more columns if we could.
[18:44] <danilos> deryck, there are plenty downsides to unneeded redundancy, so let's not go into that :)
[18:44] <deryck> and I wasn't completely sure, honestly. :)
[18:44] <deryck> danilos, right :-)
[18:44] <danilos> deryck, heh, well, you did prove yourself right, cheers :)
[18:44] <deryck> cheers :-)
[18:44] <danilos> deryck, btw, where is the code that actually assembles notifications for sending then? :)
[18:45] <danilos> deryck, (I've so far not touched on that side of things, only up to the point of creating BugNotification records)
[18:45] <deryck> danilos, in lp.bugs.model.bug start with addChange and work your way down :-)
[18:46] <danilos> deryck, heh, actually, that's this side of things that I have touched; it seems it might be bugs/scripts/bugnotifications.py
[18:46] <deryck> danilos, ah, the look up side.  sorry.  yes, that script.  the first function there is what you want.
[18:48] <danilos> deryck, thanks, very useful help, I'm running off now, but will have this ready for landing tomorrow :)
[18:48] <deryck> danilos, cool.  catch you later.
[18:52] <allenap> jcsackett: Thanks for the review :)
[18:57] <jcsackett> allenap: you're welcome. :-)
[19:02] <LPCIBot> Project devel build (415): STILL FAILING in 6 hr 8 min: https://hudson.wedontsleep.org/job/devel/415/
[19:02] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][bug=711901] Implement LIFECYCLE notification level for direct
[19:02] <LPCIBot> subscriptions.
[19:02] <LPCIBot> * Launchpad Patch Queue Manager: [r=bac,
[19:03] <LPCIBot> benji][ui=none][bug=699719] A (currently disabled) JS overlay has
[19:03] <LPCIBot> been added for advanced direct bug subscriptions.
[19:08] <sinzui> leonardr: r=me
[19:18] <leonardr> yay
[19:34] <abentley> henninge, does this make any sense to you? http://pastebin.ubuntu.com/562165/
[19:49] <henninge> abentley: looking
[19:49] <abentley> henninge, nm
[19:50] <abentley> henninge, it was because it defaults to 0 for sequence.
[19:50] <henninge> right ;)
[19:51] <abentley> henninge, I think this is confusing behaviour, though.
[19:52] <henninge> abentley: of the factory method?
[19:53] <henninge> I guess it could default to getUniqueInteger
[19:53] <abentley> henninge, I think that would be better.
[19:53] <henninge> but there are so many tests that use this, we'd have to check all of them.
[19:54] <henninge> well, we could just see which are failing ...
[19:54] <henninge> I guess
[19:54] <abentley> henninge, or if having a continuous sequence is valuable, we can find out the last sequence number.
[19:55] <henninge> abentley: actually, in most cases sequence != 0 would be the important information.
[19:56] <abentley> henninge, It's also confusing that getPOTMsgSets does not, by default, return all msgsets.
[19:57] <henninge> tests that test the actual sequence of POTMsgsets would set it explicitely.
[19:57] <abentley> henninge, I realise that getting active messagesets is probably the common case for that method, though.
[19:57] <henninge> abentley: exactly
[20:20] <LPCIBot> Project db-devel build (339): STILL FAILING in 5 hr 21 min: https://hudson.wedontsleep.org/job/db-devel/339/
[20:20] <LPCIBot> * Launchpad Patch Queue Manager: [rs=wgrant][no-qa] Merge stable,
[20:20] <LPCIBot> resolving conflicts. Again. We like conflicts.
[20:20] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless, stevenk][bug=712249] Remove remaining lucille references.
[20:26]  * jcsackett is having some irc difficulties.
[20:42] <deryck> henninge, hey.  Your friendly neighborhood nag coming your way. :-)
[20:42] <deryck> henninge, hows the work for a fix for bug 710591 coming?
[20:55] <leonardr> what's the best way to dynamically set the title of a launchpad page?
[20:55] <leonardr> ie. set it to some non-static value determined by the view code
[20:57] <wallyworld> leonardr: see SourcePackageRecipeEditView
[20:57] <wallyworld>     def title(self):
[20:57] <wallyworld>         return 'Edit %s source package recipe' % self.context.name
[20:57] <wallyworld>     label = title
[20:57] <wallyworld> is that what you want?
[20:58] <henninge> deryck: it's underway but won't be done today, we'll be aiming for an r-c tomorrow here.
[20:59] <leonardr> wallyworld: not ideal, but let's see if i can make it work
[21:00] <wallyworld> leonardr: there may be a better way - that's the one way i have personnally seen
[21:04] <deryck> henninge, ok, thanks
[21:08] <wallyworld> StevenK: leonardr: thumper: we having a standup today?
[21:09] <thumper> wallyworld: yep
[21:12] <leonardr> thumper: my mic isn't plugged in
[21:14] <StevenK> wallyworld, thumper; I'm coming, just having laptop issues
[21:30] <wallyworld> lifeless: ping
[21:34] <lifeless> wallyworld: hi
[21:35] <wallyworld> lifeless: i need to qa something but the db for qastaging is so old that i can't do it
[21:36] <lifeless> how so?
[21:36] <wallyworld> can we organise to refresh the qastaging db?
[21:36] <wallyworld> there's some recipe build records that reflect the problem in production but qastaging doesn't have them
[21:37] <wallyworld> i need to test on a system that has those particular records
[21:37] <wallyworld> i think qastaging db should be updated once a week? but it appears way older than that?
[21:37] <lifeless> wallyworld: in this situation is better to create the problem
[21:38] <lifeless> rather than wait for a sync
[21:38] <lifeless> particularly as we may well need to fix data in prod so there is never any guarantee that a problem will exist on [qa]staging
[21:39] <wallyworld> the data in prod doesn't need fixing
[21:39] <wallyworld> the issue is with how it is displayed
[21:39] <wallyworld> so you mean script some sql and get it run on qastaging?
[21:39] <lifeless> wallyworld: I'm familiar with the bug; opinions vary about whether the data is a problem or not :>
[21:39] <lifeless> wallyworld: putting that aside.
[21:40] <lifeless> wallyworld: yes, geting losa to help you reproduce the issue on qastaging
[21:41] <wallyworld> ok, so i'll write some sql to generate some records. do i have query access to the qastaging database?
[21:42] <wgrant> Morning.
[21:43] <lifeless> wallyworld: You don't need sql
[21:44] <lifeless> wallyworld: login to qas; make a recipe; request a build; request another build; ask losa to update the finished time on the one that would normally sort lower and check it sorts higher
[21:44] <lifeless> wallyworld: they may want sql for the last step, but the losas are pretty familiar with sql too :)
[21:44] <wallyworld> lifeless: isn't that sql?
[21:44] <mbarnett> lies
[21:44] <mbarnett> we know nothing about your fancy structured languages!
[21:44] <wallyworld> oh ok, i don't need to write the sql myself
[21:44] <lifeless> it can also be done via bin/harness without any sql at all
[21:45] <lifeless> wallyworld: you may be asked to; but don't prejudge.
[21:45] <wallyworld> i'm not familar with bin/harness :-)
[21:45] <lifeless> certainly don't *start* with sql, start with the web ui :)
[21:46] <wallyworld> lifeless: ok. i'll grab some breakfast and do it after that
[21:46] <wallyworld> mbarnett: i think you know more than you admit to :-)
[21:46] <mbarnett> shhh!
[21:48] <wallyworld> mbarnett: will you be around for another hour or so? can i ping you to help with the data manipulation?
[21:51] <mbarnett> wallyworld: most likely.  I should be here, and if i am swamped, i'll fool one of my compatriots into helping!
[21:55] <lifeless> wallyworld: the other thing
[21:55] <lifeless> wallyworld: remember that the goal of the final qa step is 'ok to deploy'
[21:58] <huwshimi> Did someone break the bugs api on qastaging? I'm trying to add tags to a bug and it fails with a 503 (trying to hit this page: https://bugs.qastaging.launchpad.net/api/devel/bugs/664553).
[21:58] <_mup_> Bug #664553: Arduino should be in ubuntu software center <Ubuntu:Expired> < https://launchpad.net/bugs/664553 >
[21:59] <james_w> huwshimi, 503 means "sorry, try again" here
[21:59] <james_w> possibly it implies a problem with the qastaging appservers or similar though
[22:03] <lifeless> huwshimi: do you see the headers?
[22:04] <huwshimi> lifeless: Chrome console is giving me the headers
[22:05] <huwshimi> lifeless: But the status code is "503 Service Unavailable"
[22:06] <lifeless> if there isn't an OOPS header, then that is the frontend detecting qas not responding at all within 30 seconds
[22:06] <lifeless> which isi odd
[22:09] <huwshimi> I can't see anything referring to oops. There's some stuff about zope, but that's all I can see.
[22:10] <lifeless> paste the headers?
[22:10] <wgrant> huwshimi: A 503 is almost always a timeout.
[22:10] <wgrant> There should be an OOPS ID.
[22:10] <wgrant> Most bug changes currently time out due to heat recalculation.
[22:10] <wgrant> qastaging seems worse than staging :/
[22:12] <huwshimi> lifeless: http://paste.ubuntu.com/562237/
[22:12] <lifeless> blaj
[22:12] <lifeless> the oops is probably in the body :(
[22:13] <wgrant> I guess the timeout code doesn't know the X-Lazr-Oops stuff :(
[22:14] <lifeless> depends on the render path
[22:14] <lifeless> api -> header; web -> body
[22:14] <poolie> huwshimi, hi
[22:14] <poolie> huwshimi, i am hungry for the fix for bug 708436 but it doesn't seem to be active in https://bugs.qastaging.launchpad.net/bzr
[22:14] <_mup_> Bug #708436: Bug tag list wrapping <css> <qa-needstesting> <ui> <Launchpad itself:Fix Committed by huwshimi> < https://launchpad.net/bugs/708436 >
[22:15] <poolie> despite the revision number seeming to say it would be
[22:15] <poolie> i may be just confused though
[22:16] <huwshimi> poolie: I'm just trying to test that on qastaging, but now I've run into a problem with adding bugs to a task
[22:17] <huwshimi> *tags to a bug
[22:17] <huwshimi> I'm not sure what happened with my words there
[22:17] <huwshimi> lifeless: the body didn't have any helpful stuff (it was a standard "sorry, try again later" page)
[22:19] <huwshimi> poolie: Oh, now I think I understand your confusion. That is a different bug to the one about tag clouds.
[22:28] <huwshimi> ok seems to be working now
[22:31] <lifeless> flacoste: so when you're done with calls; we should talk briefly about the output from the rt meeting
[22:31] <flacoste> lifeless: i'm done
[22:31] <flacoste> lifeless: skype me
[22:31] <poolie> o/ flacoste
[22:31] <poolie> huwshimi, ah, you're right, i was confusing them
[22:31] <poolie> or they were confusing me
[22:32] <huwshimi> poolie: It's ok, we were all confused.
[22:44] <wallyworld> thumper: you able to tick and flick that mp?
[22:58] <cody-somerville> Does zope security policy for an object only come into effect when its instantiated or would it also throw an exception if for example you try to delete an object the current principle doesn't have access to via a bulk operation on a result set which is done using SQL (and thus no objects are actually loaded into Python)?
[23:04] <wgrant> cody-somerville: Only attribute access on the Python object is protected.
[23:06] <lifeless> cody-somerville: can't delete an object you can't talk about.
[23:06] <StevenK> jtv: Ping
[23:06] <lifeless> cody-somerville: but operations below the object layer are not relevant to the zope security framework
[23:07] <cody-somerville> Okay.
[23:08] <StevenK> lifeless: O hai
[23:09] <lifeless> StevenK: hi
[23:11] <StevenK> lifeless: Could you take a look at https://code.launchpad.net/~abentley/launchpad/recipe-errors/+merge/42305 ? It's not a review, but I'm wondering if you agree with the reviewers comments.
[23:11] <cody-somerville> How does Zope magically wrap objects returned by a storm result set in a security proxy?
[23:13] <abentley> StevenK, I rejected that because I don't plan to work on it anymore and it wasn't approved by the reviewer.
[23:13] <wallyworld> lifeless: i have a question when you are free
[23:13] <lifeless> wallyworld: quick or involved?
[23:13] <wgrant> cody-somerville: The ResultSet is itself wrapped.
[23:14] <wallyworld> likely involved :-)
[23:14] <lifeless> wallyworld: if it can wait for me to do a shopping run for Lynne, that would be awesome
[23:14] <StevenK> abentley: I figured as much, I'm just trying to understand why there was so much pushback.
[23:14] <wallyworld> lifeless: of course. just wanted to see if you were free. just ping me when you are able
[23:15] <abentley> StevenK, so I think he's right that it would make more sense to fix the text of the errors, so that they could just be stringified.
[23:15] <lifeless> abentley: FWIW I think the use of the __exit__ to consolidate the exception statements is pretty cool
[23:16] <lifeless> abentley: I'm a little ambivalent about the use of it for flow control as well
[23:16] <lifeless> abentley: if there was some way to tease that apart, that might make it really good
[23:17] <lifeless> abentley: if the exceptions can be reliably stringified - or if they could be given some extended protocol to let us get a web page error from them, that would be simpler overall
[23:17] <lifeless> wallyworld: ok, in a bit then.
[23:19] <StevenK> lifeless, abentley: I guess my hidden question is "Do you feel this is a good base to start work with, or shall I scorched earth and start from scratch?"
[23:20] <cody-somerville> wgrant, Interesting. I assume thats because the store is also wrapped? And if so, what prevents an unwrapped store from being instantiated?
[23:21] <wgrant> cody-somerville: Nothing.
[23:22] <abentley> lifeless, I think the three cases, no error, user error and programming error, make it difficult to deal with in a ContextManager unless we do the oops handling there.
[23:22] <lifeless> cody-somerville: zope security is insurance
[23:23]  * cody-somerville nods.
[23:24] <abentley> StevenK, if this was the only way of avoiding code duplication, I would probably still do it this way.  Maybe you can think of another way.
[23:25] <cody-somerville> Does Zope keep the the current principle in a thread local storage or is that information only available if you have the request object like in Django?
[23:25] <StevenK> abentley: I was tempted to write a validator function that returns None on no error, or the string of the exception
[23:25] <StevenK> abentley: And then call it from the two sites
[23:26] <StevenK> abentley: Which means we can iterate and get the recipe text set using a AJAX text field
[23:27] <abentley> StevenK, validators are look-before-you-leap.
[23:28] <wgrant> cody-somerville: It uses TLS.
[23:28] <StevenK> abentley: Yes, I was suggesting calling it before setRecipeText()
[23:29] <cody-somerville> Is using TLS as naughty as the Django folks make it seem?
[23:29] <abentley> StevenK, to be clear, I believe EAFP is a better pattern than LBYL.
[23:30] <wgrant> cody-somerville: Just about.
[23:30] <wgrant> But it's convenient sometimes.
[23:32] <StevenK> abentley: Sorry, can you expand EAFP?
[23:32] <lifeless> easie to ask forgiveness than permission
[23:33] <StevenK> Ah
[23:33] <abentley> StevenK, http://docs.python.org/glossary.html#EAFP
[23:34] <lifeless> StevenK: and I'm with aaron - the default behaviour should be to try and handle rejection, rather than plan and then try. There are some cases where performance or correctness will be better the other way around, but they are precious few.
[23:37] <thumper> abentley: unfortunately that isn't how launchpad forms normally work
[23:38] <thumper> StevenK: fyi - the webservice just calls set recipe text and returns propagates the error with a 400 response code
[23:38] <lifeless> wgrant: :( I missed sinzui
[23:38] <mwhudson> cody-somerville: given the settings module, django people are in no position to regards other practices as evil
[23:38] <StevenK> mwhudson: Their moral high ground is on a bed of quicksand?
[23:38] <wgrant> lifeless: Why'd you want him?
[23:40] <mwhudson> StevenK: something like that
[23:40] <lifeless> wgrant: apache-openid.
[23:40] <lifeless> wgrant: bug 712698
[23:40] <_mup_> Bug #712698: No way to expire existing sessions <Apache OpenID:New> < https://launchpad.net/bugs/712698 >
[23:41] <lifeless> wgrant: I was going to ask if he could spare a slot for it
[23:42] <wgrant> lifeless: Hmm.
[23:42] <wgrant> lifeless: Also, re. Debian, what status did you have in mind for squeeze?
[23:42] <lifeless> wgrant: dunno; not-dev-focus ?
[23:42] <wgrant> The development focus is not explicit for distributions.
[23:43] <lifeless> wgrant: something controls branch stacking ......
[23:43] <wgrant> lifeless: Whichever series has status DEVELOPMENT.
[23:43] <lifeless> there are three for debian, surely.
[23:43] <lifeless> sid, experimental and $next
[23:43] <lifeless> wgrant: also https://bugs.launchpad.net/apache-openid/+bug/712698/comments/1
[23:43] <_mup_> Bug #712698: No way to expire existing sessions <Apache OpenID:New> < https://launchpad.net/bugs/712698 >
[23:43] <lifeless> bbiab
[23:44] <wgrant> Right. Experimental is currently EXPERIMENTAL, Sid is FUTURE, and Squeeze is DEVELOPMENT.
[23:44] <wgrant> We could possibly swap Sid and Squeeze.
[23:44] <wgrant> But making the dev focus explicit is probably better.
[23:51] <wgrant> "Given the depths of the cuts already made to reclaim CD space, and the
[23:51] <wgrant> fact that we should be taking a leadership position in encouraging
[23:51] <wgrant> migration to Python3, I don't think it makes any sense to keep
[23:51] <wgrant> python2.6 around in Ubuntu for Natty.
[23:51] <wgrant> "
[23:51] <wgrant> :(
[23:51] <wgrant> Porting time yay?
[23:51] <james_w> porting Launchpad?
[23:52] <wgrant> Yes.
[23:53] <james_w> to 2.7?
[23:53] <wgrant> Right. It's still a bit broken.
[23:53] <james_w> that was surely inevitable before the next LTS
[23:53] <wgrant> Indeed.
[23:53] <wgrant> But not necessarily before Natty.
[23:53] <james_w> you are just concerned about developers?
[23:54] <james_w> deployment obviously isn't going to move to natty is it?
[23:54] <wgrant> Right.
[23:54] <james_w> ok, with you
[23:56] <abentley> thumper, forms seem to handle setting errors in actions (i.e. asking forgiveness) very well.  The problem we've got here is how best to generalise the control flow.
[23:57] <thumper> abentley: I think the main reason for the validation code is to catch all the errors at once, rather than one at a time
[23:59] <abentley> thumper, there's that.