[03:14] <wgrant> spm: Users can deactivate their accounts, right..?
[03:14] <spm> wg-rant: deactivate yes; purge no
[03:14] <spm> if you appreciate the difference. we get very few requests for the latter, but enough.
[03:14] <wgrant> How do you purge? Merge them away?
[03:15] <spm> sql nullify the relevant bits in the appropriate tables
[03:15] <wgrant> Ah.
[03:15] <spm> not ... pretty, but.
[03:15] <spm> actually.. I think that's correct. verifying...
[03:17] <spm> bleh. it's not docco'd. but that'd be the likely way.
[03:18] <spm> wgrant: heh, ref the 'ssh codebounce' I'd typed that much and was starting to get frustrated at why ssh tab completion wasn't. then the light came on. whee. :-D
[03:19] <wgrant> Heh.
[03:19] <wgrant> It's not a DNS alias yet? :(
[03:23] <spm> that would be .. unwise :-)
[03:24] <spm> i know we have cocobanana as an alias for a rollout target. but generally we do limit our moments of ... public silliness :-)
[03:25] <wgrant> Pfft.
[05:45] <lifeless> thumper: hi
[05:45] <lifeless> thumper: Can we have a 5 minute pre-impl call ?
[05:48] <thumper> lifeless: sure
[05:49] <lifeless> when suits? now would be great for me
[05:49] <thumper> lifeless: now is fine
[05:51] <thumper> lifeless: you dropped
[05:53] <lifeless> can you hear me ?
[05:53] <lifeless> [120531.779865] iwlagn 0000:02:00.0: Microcode SW error detected.  Restarting 0x2000000.
[05:54] <ajmitch> iwlagn isn't the most stable of wireless drivers, I've had problems with it at times that required rmmod & modprobe
[08:22] <adeuring> good morning
[08:58] <mrevell_> Morning
[09:23] <kb9vqf> wgrant: You around?
[09:23] <kb9vqf> Any idea why this might be happening? https://quickbuild.pearsoncomputing.net/builders/vidar
[09:25]  * kb9vqf wonders if it's unique to Debian
[09:31] <wgrant> kb9vqf: Not sure. Maybe check Ubuntu's console-data diff?
[09:31] <kb9vqf> OK, just wondering if you guys had seen it before ;-)
[09:31] <kb9vqf> Those almost look like drawing commands for the text-based interactive mode
[10:05] <kb9vqf> Hmmm...why does the build farm ignore the remaining idle builders insead of assinging them chunks of the build queue?
[10:06] <kb9vqf> I have two active and two idle with a long build queue...
[10:06] <kb9vqf> https://quickbuild.pearsoncomputing.net/builders/
[10:06] <kb9vqf> I don't see any errors anywhere
[10:07] <wgrant> Check the buildd-manager log for references to those builders.
[10:08] <kb9vqf> Nothing
[10:08] <kb9vqf> wgrant: The only thing in the log are references to the broken builders
[10:08] <wgrant> What if you edit lib/lp/buildmaster/manager.py, replace logging.INFO with logging.DEBUG, then restart buildd-manager?
[10:12] <kb9vqf> wgrant: Not much, just a bunch of
[10:12] <kb9vqf> 2010-06-17 04:11:32-0500 [-] Considering odin
[10:12] <kb9vqf> 2010-06-17 04:11:32-0500 [-] No build candidates available for builder.
[10:12] <kb9vqf> Strangely both builders work, just not simultaneously
[10:12] <wgrant> Ahh.
[10:12] <wgrant> I bet it's the 80% restriction.
[10:12] <kb9vqf> ?
[10:13] <wgrant> That is, no PPA is allowed to use more than 80% of the builders for any architecture.
[10:13] <kb9vqf> Makes sense
[10:13] <kb9vqf> Can I override it?
[10:14] <wgrant> No, but you can delete it.
[10:14] <wgrant> See the end of addCandidateSelectionCriteria in lp.soyuz.model.buildpackagejob
[10:14] <kb9vqf> OK, thanks (Each of my builders is a separate physical machine, so adding more builders isn't a very palatable solution)
[10:14] <wgrant> remove the num_arch_builders stuff and everything from there until the return.
[10:16] <kb9vqf> It looks like I could override it (sort of) by just changing the 80 to something else
[10:16] <kb9vqf> That way it's a small change from production Launchpad, not a big one ;-)
[10:16] <wgrant> Or just delete the bit that adds the clause.
[10:17] <kb9vqf> I assume a simple restart of the buildd manager will apply the change?
[10:18] <wgrant> Correct.
[10:19]  * kb9vqf needs to get to bed...it's way to early here
[10:19] <kb9vqf> Thanks for your help!
[10:19] <wgrant> Night.
[11:10] <deryck> Morning, all.
[14:26] <leonardr> Chex, i filed an rt earlier this morning to ask for help running a performance test. it should only take a few minutes, so let me know when you can spare the time
[14:29] <leonardr> argh, where's my receipt?
[15:05] <sinzui> mars: I did not get an email from ec2 this morning. The instance finished, but not success or fail email
[15:30] <mars> sinzui, did it finish in a reasonable amount of time?  Also, was it an 'ec2 land' mail?  Those can take forever sometimes.
[15:30] <sinzui> How could I know it finished in a reasonable amount of time?
[15:30] <mars> (just noticed how ridiculous that sounds - if it took forever, how would I know when it finished?)
[15:30] <sinzui> I used ec2 test
[15:30] <mars> ok
[15:31] <mars> sinzui, ok, so there may still be problems, barring a few-hours delivery delay.  I have a follow-up branch that should address that.
[15:32] <sinzui> I resubmitted the test. I hope it to be complete in 4 hours
[15:33] <mars> ok, please let me know what the result is.  If it is a success, then we have an intermittent failure.  If it eats it again, then I might have something I can reproduce.
[16:36] <Ursinha> sinzui, hi
[16:38] <sinzui> Hi Ursinha
[16:38]  * sinzui was lost and could not find the window that wanted his attention
[16:39] <Ursinha> sinzui, :)
[16:39] <Ursinha> sinzui, about your email: the bugs marked as fix committed without qa tags weren't marked fix committed by my script, but manually
[16:39] <Ursinha> that's why they don't have the tags
[16:40] <Ursinha> when the script runs on them, it will mark them properly
[16:40]  * sinzui nods
[16:40] <Ursinha> I've stopped the script for now, I'm putting newer code there, but it should happen rsn
[16:41] <sinzui> Ursinha, is it a concern that they are not being tracked?
[16:41]  * sinzui QAs every fix-committed in answers, blueprint and registry regardless of tags
[16:41] <Ursinha> sinzui, I'll run the script and check if they will be properly tagged
[16:42] <Ursinha> sinzui, yes, I often monitor those
[16:42] <Ursinha> the fixed but untagged
[16:42] <sinzui> fab
[16:42] <sinzui> I will not worry then
[16:42] <Ursinha> same way I monitor the orphaned ones
[16:42] <Ursinha> :)
[17:52] <sinzui> mars, ec2 sent me emails this time. Both instances ran about 4 hours
[18:10] <mrevell> Night!
[18:26] <cody-somerville> If anyone asks, it appears PPA publishing is broken at the moment. Working on fixing it.
[18:47] <jml> g'night all. see you next week.
[18:48] <jml> cody-somerville, btw, if it's down for more than 15 minutes, it's an incident. Please find someone to manage it.
[18:48]  * jml flees the scene
[18:48] <cody-somerville> jml, trying to. It seems all the Soyuz people have EODed
[18:49] <mars> flacoste, ^ ?
[18:53] <cody-somerville> It appears to have been broken now for four hours and 5 minutes now.
[18:54] <cody-somerville> * 10 minutes
[22:26] <sinzui> It looks like the devel build will fail. I have a fix for the two failing tests that I know about
[22:26]  * sinzui waits for the official failure message
[23:33] <wgrant> U1 is very good at 'fixing' major security flaws but somehow managing to leave them wide open.
[23:35] <beuno> wgrant, that's not exactly useful
[23:36] <thumper> beuno: hi
[23:36] <beuno> wgrant, there is a roll-out to production that has been delayed 3 times already
[23:36] <beuno> wgrant, that contain the actual fixes
[23:36] <beuno> heya thumper!
[23:36] <wgrant> beuno: Ah. That makes more sense.
[23:36] <beuno> wgrant, hence, the fix-committed and not fix-released
[23:36] <wgrant> Just jdo said it was fixed... and it's not. Which reminds of last time someone said it was fixed, where the fourth fix finally worked.
[23:36] <wgrant> Mmm, no, the bug in question here is Fix Released.
[23:36] <beuno> wgrant, I would of expected you to know that by now  ;)
[23:37] <beuno> oh?
[23:37] <beuno> it's wrong then
[23:37] <beuno> he probably thinks the roll-out happened
[23:37] <wgrant> Bug 590540
[23:37] <beuno> wgrant, right, no deployed
[23:37] <beuno> tomorrow, hopefully
[23:37] <wgrant> Ahhh, good. Sorry about that.
[23:38] <beuno> I see where the confusion came up
[23:39] <beuno> if PQM behaves the roll out tomorow will include all fixes
[23:39] <beuno> the branch for #535651 is bouncing with an unrelated error
[23:39] <beuno> the rest are all landed
[23:40] <lifeless> beuno: 'if' :)
[23:40] <beuno> heh, yes
[23:40] <beuno> may be all of them minus one
[23:40] <wgrant> OK, great. Thanks.
[23:40] <beuno> wgrant, thanks for the reports
[23:40] <beuno> it was a bit of a shock to see those open
[23:41] <beuno> we did some db mangling to make sure they hadn't been exploited
[23:41] <beuno> they haven't
[23:41]  * thumper afk
[23:42] <wgrant> beuno: It returned no results at all?
[23:42] <wgrant> Because I did try it.
[23:42] <beuno> wgrant, I didn't see the query, but it may of been "nobody except wgrant"  ;)
[23:43] <lifeless> wgrant: now try % encoded path seperators
[23:46] <wgrant> sinzui: +participation 403s sometimes.
[23:47] <sinzui> ouch
[23:47] <wgrant> You, for example.
[23:47] <sinzui> me
[23:48] <sinzui> I will investigaste
[23:48] <wgrant> Thanks.
[23:52] <sinzui> ha ha, there are 17 deprecated private membership teams, and I appear to be a members of a few. and since the new page shows the path to membership, it breaks
[23:53] <sinzui> I will land a fix for this tomorrow. I wish I could remove the teams too
[23:59] <wgrant> Why can't you?