[01:07] <LPCIBot> Yippie, build fixed!
[01:07] <LPCIBot> Project db-devel build #703: FIXED in 5 hr 25 min: https://lpci.wedontsleep.org/job/db-devel/703/
[02:53] <LPCIBot> Project devel build #869: STILL FAILING in 5 hr 39 min: https://lpci.wedontsleep.org/job/devel/869/
[03:07] <lifeless> bbiab
[03:27] <wallyworld_> anyone know what's up with qastaging?
[03:30] <wgrant> LOSA ping: ^^
[03:31] <hloeung> wgrant: looking
[03:31] <hloeung> wallyworld_: looking
[03:31] <wallyworld_> hloeung: thanks!
[03:31] <wgrant> I have a suspicion it's the DB patch.
[03:31] <wgrant> qastaging-nohup.out should be informative.
[03:36] <hloeung> wgrant: yes it is
[03:36] <wgrant> hloeung: What's the error?
[03:36] <hloeung> wgrant: canonical.database.revision.InvalidDatabaseRevision: patch-2208-76-2.sql has not been applied to the database. You probably want to run 'make schema'.
[03:37] <wgrant> But it's meant to ignore it unless the suffix is 0...
[03:37] <wgrant> Or maybe it only ignores it in the other direction.
[03:37] <wgrant> Let me check.
[03:37] <lifeless> this is the 'qastaging should run db updates automatically' RT
[03:38] <wallyworld_> so a qastaging deployment needs make schema manually?
[03:38] <wgrant> Yeah, it will ignore it if it's applied but missing, but not if it's unapplied but present.
[03:38] <lifeless> not make schema
[03:38] <lifeless> never make schema
[03:38] <wgrant> wallyworld_: database/schema/upgrade.py
[03:38] <wallyworld_> right
[03:58] <hloeung> wgrant: okay, so what do I need to do to fix it up?
[03:59] <wgrant> hloeung: In sourcherry's qastaging tree, "LPCONFIG=qastaging database/schema/upgrade.py"
[04:00] <hloeung> wgrant: ok running it now
[04:04] <hloeung> wallyworld_, wgrant: all up and running now
[04:04] <wallyworld_> hloeung: wgrant: thanks!
[04:05] <hloeung> np
[04:05] <wgrant> hloeung: Thanks.
[04:05] <wgrant> hloeung: We already run security.py on qastaging automatically, right?
[04:05] <hloeung> wgrant: let me check
[04:07] <hloeung> wgrant: yes we do, ever 20 and 50 minutes past the hour
[04:07] <wgrant> hloeung: Could we run upgrade.py too?
[04:07] <wgrant> lifeless: Any objections?
[04:09] <lifeless> I believe there is an rt/bug asking for it
[04:09] <lifeless> its more likely to deadlock if the server isn't kicked out.
[04:09] <lifeless> but hell, we need that option anyway for prod ;)
[04:09] <lifeless> so no, no objection
[04:15] <wgrant> I can't see an RT for it. I guess it could deadlock, but meh.
[04:17] <wgrant> lifeless: Lots of rabbit plugins automatically listen on a default port, which makes things problematic for the fixture (as rvb saw, causing him to create the MP you looked at last night)
[04:18] <wgrant> lifeless: I think we probably want to make the fixture whitelist plugins.
[04:20] <wgrant> (rabbit provides no way to disable plugins, but we can create an alternative plugin directory containing symlinks to the whitelisted plugins)
[04:21] <lifeless> wgrant: +1
[04:21] <wgrant> Great.
[04:21] <lifeless> also, are the rabbit authors just idiots?
[04:21] <lifeless> <damn, my inner pessimist escaped>
[04:21] <wgrant> And we can configure the management port from a commandline option, fortunately.
[04:22] <wgrant> You haven't seen the plugin system, have you?
[04:22] <lifeless> let me guess, they run as separate erlang processes
[04:22] <wgrant> No, no.
[04:22] <wgrant> The build system is a bit odd.
[04:22] <wgrant> Everything is locked to the one version.
[04:22] <lifeless> oh? see, thats how *every one says you should do it*
[04:22] <wgrant> They all have different config mechanisms.
[04:23] <wgrant> The Makefile in the root of each plugin's tree starts with "include ../umbrella.mk"
[04:23] <wgrant> Because you're meant to build them in a subdirectory of their plugin umbrella project.
[04:23] <wgrant> Despite them all being separate projects and VCS repos.
[04:25] <wgrant> ~/create-lxc-aufs is pretty handy.
[04:25] <wgrant> VM setup in 5 seconds, with automatic destruction once you close the session.
[04:25] <lifeless> it would be neat if it was included in lxc proper
[04:26] <wgrant> It would be neat if it was less evil.
[04:26] <lifeless> EPARSE
[04:26] <lifeless> :P
[04:26] <lifeless> translationgroup story test is breaking me
[04:26] <wgrant> Oh?
[04:26] <wgrant> How many are there?
[04:27] <lifeless> 01-translation-groups-page.txt  10-distro-translation-group.txt   30-show-group-translation-targets.txt  40-remove-translator.txt                   46-test-distro-structured-permissions.txt  xx-change-translation-policy.txt
[04:27] <lifeless> 05-add-translation-group.txt    15-product-translation-group.txt  35-appoint-translators.txt             44-test-distro-closed-permissions.txt      55-pofile-upload.txt                       xx-link-to-documentation.txt
[04:28] <lifeless> 06-edit-translation-group.txt   20-project-translationgroup.txt   36-change-translator.txt               45-test-distro-restricted-permissions.txt  60-translation-suggestions.txt
[04:28] <wgrant> Hee hee
[04:28] <lifeless> thats not the problem
[04:28] <lifeless> its failing when catted together
[04:28] <wgrant> It's still horrible.
[04:28] <wgrant> Huh.
[04:28] <spiv> accidentally including the xx-* in the concatenation?
[04:28] <lifeless> spiv: no
[04:29] <lifeless> spiv: (but a reasonable guess)
[04:29] <spiv> Ok, probably something difficult and horrible then ;)
[04:29] <lifeless> I've done most of the other stories and they all worked first time
[05:34] <StevenK> How do I change the context of a picker when the vocab is being set inside a Choice()?
[05:35] <wgrant> You may be able to do it by overriding the widget used by the form.
[05:42] <StevenK> And where is the widget set?
[05:43] <wgrant> They are normally automatically derived from the interface.
[05:43] <wgrant> Possibly grep around for setUpWidgets
[06:13] <LPCIBot> Project db-devel build #704: FAILURE in 5 hr 5 min: https://lpci.wedontsleep.org/job/db-devel/704/
[06:15] <wgrant> allenap: rabbitfixture r18 breaks lazr.amqp's test suite.
[06:15] <wgrant>   File "/home/wgrant/Development/lazr.amqp/trunk/eggs/rabbitfixture-0.3-py2.7.egg/rabbitfixture/server.py", line 249, in _spawn
[06:15] <wgrant>     with open(self.config.logfile, "wb") as logfile:
[06:15] <wgrant> IOError: [Errno 2] No such file or directory: '/tmp/tmp1jc1vI/server.log'
[06:16] <wgrant> Ahh.
[06:19] <wgrant> allenap: RabbitServerResources won't setUp() properly once it's been tearDown()d, as its fixtures are destroyed but not unassigned.
[06:21] <wgrant> I guess __init__ should set some templates that setUp uses if present.
[06:21] <wgrant> But if they're not, setUp should create new fixtures even if the existing value is not None.
[07:41] <allenap> wgrant: Okay, can you file a bug? I'll try and fix it today. Sorry about that.
[07:41] <wgrant> allenap: I've fixed it and added a test.
[07:42] <wgrant> Seems to be happy now.
[07:42] <allenap> wgrant: Tip top :)
[07:43] <wgrant> allenap: What was that change for? Getting a dev rabbitmq running?
[07:44] <allenap> wgrant: Yeah, but lifeless has said that I probably ought to stick to ephemeral ports even in dev. I'm still trying to figure out how to do that and not make development less convenient (i.e. having to manually specify an LPCONFIG, or something like that).
[07:44] <wgrant> allenap: I don't think you can.
[07:45] <wgrant> As the config has to be shared between lots of scripts.
[07:45] <wgrant> And the only common ancestor is the shell.
[07:45] <wgrant> And that's hideous.
[07:45] <allenap> wgrant: I did have one idea.
[07:45] <wgrant> Plus there's the LP process which runs inside Apache.
[07:45] <wgrant> Oh?
[07:46] <allenap> wgrant: Move configs/development to configs/development-base, then create a new, mostly empty development config into which things like the rabbit service can write their configuration.
[07:47] <allenap> development would extend development-base.
[07:47] <wgrant> Possibly... but urgh. Does that mean I'd have to restart everything after restarting rabbit, because it will reallocate its port?
[07:48] <wgrant> Woo
[07:48] <allenap> wgrant: Yes :)
[07:49] <wgrant> :(
[07:49] <allenap> wgrant: I think it's more convenient to stick to a known port for dev services.
[07:49] <wgrant> Yes.
[07:52] <wgrant> Grar.
[07:52] <wgrant> rabbitmq reset still takes up to 10ms sometimes :/
[07:52] <wgrant> But mostly around 5ms.
[07:55] <allenap> wgrant: Is that with the management plugin?
[07:55] <wgrant> allenap: Yes.
[07:55] <mrevell> Good morrow
[07:55] <allenap> wgrant: That's better than several seconds though :)
[07:56] <wgrant> I have a rabbitfixture branch which starts the plugin on a randomish port, and just hacked lazr.amqp to make use of it to reset.
[07:56] <wgrant> Still, eventually most tests shouldn't be running with real rabbit.
[07:56] <wgrant> So it won't be that bad.
[07:57] <adeuring> good morning
[08:08] <bigjools> lifeless: I thought of something else I wanted to chat to you about last night
[09:33] <bigjools> wgrant: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-2013BUILDMASTER1
[09:35] <allenap> rvba: Do you mind if I mark https://code.launchpad.net/~rvb/launchpad/rabbit-error-plugins/+merge/67000 as rejected?
[09:36] <rvba> allenap: no problem ;).
[09:36] <wgrant> allenap, rvba: I have an alternate fix for that. I have a branch that makes rabbitfixture use only whitelisted plugins
[09:36] <allenap> rvba: And apologies for suggesting it :)
[09:36] <wgrant> bigjools: That's pleasant.
[09:36] <allenap> wgrant: Cool.
[09:36] <rvba> wgrant: Great!
[09:36] <wgrant> bigjools: Do you have a copy of the upload?
[09:39] <bigjools> wgrant: nope, just noticed it in the oops report
[09:40] <bigjools> wgrant: but notice the: "builddmaster/incoming/20110706-222926-RECIPEBRANCHBUILD-58393"
[09:40] <wgrant> Yes.
[09:40] <wgrant> So we can easily grab the upload and see that the maintainer is non-ASCII or something.
[09:40] <bigjools> I thought we had fixed unicode stuff *ages* ago
[09:41] <wgrant> Right.
[09:41] <wgrant> So it's probably something obscure.
[09:43] <bigjools> I shall embuggerate it
[09:46] <jtv> Anyone mind if I kick mawson?
[09:47] <wgrant> bigjools: Hmm, no unicode in the dsc or changes.
[09:47] <wgrant> jtv: Feel free.
[09:47] <bigjools> wgrant: and, still getting None returned in the build deps from slaves :/
[09:47]  * jtv feels free
[09:47] <wgrant> bigjools: Ja
[09:47]  * bigjools goes back to bug fixing
[09:48] <jtv> allenap, can I trouble you for a review?  It's this one: https://code.launchpad.net/~jtv/launchpad/dsd-packageset-filter/+merge/66757
[09:49] <wgrant> Ah, I bet the regression is 13373 or so.
[09:49] <allenap> jtv: Sure.
[09:49] <jtv> Thanks
[09:49] <wgrant> adeuring: ^^
[09:50] <adeuring> wgrant: thanks!
[09:50] <wgrant> adeuring: Not confirmed yet, but it's probably it.
[09:50] <wgrant> Still rebuilding...
[09:51] <jtv> Here goes dogfood…
[09:56] <jtv> bigjools, StevenK, wgrant: permission to update the CommonTasks page to say _just once_ that LPCONFIG must be "dogfood" and that this is automatic for the launchpad user, which you should always be?
[09:59] <bigjools> jtv: automatic?
[09:59] <jtv> Well, set as soon as you sudo into launchpad.
[09:59] <bigjools> oh someone fixed that then
[10:00] <wgrant> adeuring: Confirmed: r13373 causes the regression and needs to be rolled back.
[10:00] <adeuring> wgrant: cool, thanks!
[10:01] <wgrant> StevenK: See, I was right to be suspicious of it!
[10:02] <bigjools> feck
[10:02] <bigjools> I hate starting a branch in devel only to realise that I need to switch to db-devel to add new db permissions
[10:03] <jtv> bigjools: you don't need db-devel just for security.cfg.
[10:03] <bigjools> it depends
[10:05] <bigjools> I heart merge --uncommitted
[10:07] <wgrant> bigjools: Why do you think you need db-devel?
[10:08] <bigjools> I am making a change to PCJ that needs a new update permission on a table
[10:08] <wgrant> devel
[10:08] <wgrant> Unless it's a new table.
[10:08]  * bigjools blinks
[10:08] <wgrant> We run security.py before each rollout.
[10:09] <wgrant> Even on qastaging nowadays.
[10:09] <bigjools> ok, didn't know that
[10:09] <bigjools> and, yay
[10:09] <wgrant> security.py --no-revoke, that is.
[10:10]  * bigjools still doesn't see the need for security.cfg
[10:12] <wgrant> adeuring: So, do you know how to roll that back?
[10:12] <wgrant> adeuring: It needs to be rolled back nowish.
[10:13] <adeuring> wgrant: erm, no, haven't this yet,,,
[10:19] <wgrant> jtv: You're handling both your QA items, I guess?
[10:19] <wgrant> rvba: How about yours?
[10:19] <jtv> wgrant: that's what I'm trying to do
[10:19] <lifeless> bigjools: shoot
[10:19] <wgrant> jtv: Just checking, so we can deploy this regression fix ASAP.
[10:19] <jtv> yesyesyesi'mworkingonit
[10:19] <rvba> wgrant: bigjools & I are doing the QA since there is a lot to do.
[10:20] <wgrant> Great, thanks guys.
[10:20] <bigjools> lifeless: have you thought about using uuids instead of configuring oops prefixes everywhere?
[10:20] <lifeless> bigjools: yes
[10:20] <lifeless> bigjools: see lp:oops-repository
[10:20] <bigjools> because they are a FPITA
[10:21] <bigjools> lifeless: is that imminent?
[10:21] <wgrant> adeuring: Reversion has landed.
[10:21] <lifeless> bigjools: pretty close
[10:21] <adeuring> wgrant: wow, that was fast! thanks!
[10:21] <lifeless> bigjools: but a background task not foregrond atm
[10:21] <bigjools> lifeless: fawesome.
[10:21] <lifeless> https://bugs.launchpad.net/launchpad-project/+bugs?field.searchtext=oops+prefix may interest you too
[10:21] <wgrant> adeuring: So, I guess you'll not still be around in 5 hours?
[10:22] <adeuring> wgrant: well, I think I will be ;)
[10:22] <lifeless> bigjools: I haven't filed bugs yet; sorry - been head bashing on stories/translationgroups
[10:23] <lifeless> bigjools: will tie myself to the non-coding wheel tomorrow
[10:23] <gmb> Does anyone know what I can do about EC2 runs failing with this error "IOError: [Errno 30] Read-only file system: '/var/www/summary.log'"?
[10:23] <wgrant> adeuring: This fix should be deployable in a little over 5 hours.
[10:23] <bigjools> lifeless: np - just wanted to see what the future looked like.  It's gotta be better than oops prefixes :)
[10:42] <jml> gmb: no. never seen that one before.
[10:42] <mwhudson> gmb: my guess is that means your instance is ******ed
[10:43] <jml> gmb: my guess is that it's either a race (writing before a disk is ready somehow), or... what mwhudson said.
[10:43] <allenap> wallyworld_: Are you around?
[10:43] <gmb> jml: Okay. mwhudson's concise summation of the situation accepted, I shall try staying connected to the instance and see what happens when. THe error message is a bit opaque.
[10:44] <mwhudson> gmb: this is reproducable?
[10:44] <gmb> mwhudson: IDK yet. ISTR that it happened twice yesterday, but I can only find one email about it so I might be making that up.
[10:45] <gmb> I do know that it didn't take long to fail, so I'll start an instance and grab some food and see what blows up whilst I'm dining.
[10:46] <jtv> thanks allenap
[10:46] <allenap> np jtv :)
[10:46]  * gmb -> lunch
[10:46] <allenap> It was a pleasure.
[10:47]  * jtv coughs modestly
[10:55] <jtv> Anyone else getting this error when running launchpadlib_for to connect to the web service?
[10:55] <jtv> IntegrityError: new row for relation "oauthrequesttoken" violates check constraint "reviewed_request"
[10:56] <wgrant> jtv: Production?
[10:57] <jtv> I thought it defaulted to qastaging?
[10:57] <wgrant> staging
[10:57] <wgrant> Unless that changed recently, which would be abhorrent.
[10:58] <wgrant> We committed great evil to oauthnonce on production yesterday or the day before, but that shouldn't affect this..
[10:59] <jtv> Hmm service_root defaults to http://api.launchpad.dev/ it seems, but changing that to another server did not change the error.
[11:03] <jtv> And why does this happen locally?  I'd expect this to be strictly a server-side concern.
[11:17] <LPCIBot> Project db-devel build #705: STILL FAILING in 5 hr 3 min: https://lpci.wedontsleep.org/job/db-devel/705/
[11:20] <wgrant> Does Translations really have a nice error email to send out when an error occurs during error handling of an export‽
[11:22] <StevenK> wgrant: Heh.
[11:25] <danilos> allenap, hi, I've got a nice little half-tested branch up for review: https://code.launchpad.net/~spiv/launchpad/bmp-inline-diffs/+merge/66634 :)
[11:25] <danilos> wgrant, 'nice' is debatable, but some emails are indeed going out
[11:26] <wgrant> danilos: well, it's nice compared to the rest of Launchpad...
[11:26] <allenap> danilos: I've already looked at that one this morning; it has conflicts.
[11:26] <danilos> allenap, whoops, wrong URL
[11:26] <danilos> allenap, I need a branch that introduces the conflicts :)
[11:26] <allenap> Hehe.
[11:26] <danilos> allenap, https://code.launchpad.net/~danilo/launchpad/expander-anim/+merge/67161
[11:27] <danilos> allenap, a prereq for that other branch
[11:27] <allenap> danilos: Cool. I'm looking at a wallyworld branch right now, I'll do yours next.
[11:27] <StevenK> Hm, I should put up my WIP branch
[11:30] <danilos> allenap, thanks
[11:31] <danilos> allenap, btw, I have an actual branch which replaces a couple of existing one-off expanders with the new one on https://code.launchpad.net/~danilo/launchpad/replace-expanders-1/+merge/67169 so if you can get to that, I'd appreciate it very much (it can also help you test the code)
[11:31] <danilos> allenap, (test the expander-anim code among other things)
[11:32] <allenap> danilos: I'll probably be able to get to it today. If not, jcsackett is reviewing later.
[11:32] <danilos> allenap, cool, ta
[12:08] <Ursinha> morning launchpadders :)
[12:16] <danilos> Ursinha, good morning
[12:16] <bigjools> hi Mrs Ursinha :)
[13:07] <deryck> Morning, all.
[13:13] <jcsackett> morning, deryck.
[13:13] <gary_poster> morning deryck.  did my email make sense?  I think I'm finished with what I intend to do for that branch (unless you pass it back to me) so If you pull the branch, hopefully you'll be conflict free for the rest of the day.  bug 806744 tracks the other work I mentioned to you; I'll land that separately.
[13:13] <_mup_> Bug #806744: lazr.smtptest increases fragility of Launchpad appserver layer tests <thunderdome> <Launchpad itself:In Progress by gary> <lazr.smtptest:In Progress by gary> < https://launchpad.net/bugs/806744 >
[13:13] <deryck> gary_poster, ok, great.  Haven't looked at the email yet, but that all sounds fine.
[13:14] <gary_poster> cool deryck.
[13:14] <deryck> gary_poster, and I don't think I'll have to pass it back to you.  Should be okay finishing that myself.
[13:14] <gary_poster> deryck, I figured, just saying I wouldn't take it amiss if something came up and you had to. :-)
[13:15] <deryck> gary_poster, ah, gotchas. :)
[13:15] <deryck> gary_poster, thanks again for your work on this!  Will be very nice when this lands.
[13:15] <gary_poster> deryck, np, thanks for pushing us to do it.  I'm excited for it to land too.
[13:28] <deryck> gary_poster, seb128 is in #launchpad and can't subscribe a team he owns. we assume he has to make himself and admin....
[13:28] <deryck> gary_poster, is this a known bug or a feature? :)
[13:28] <deryck> gary_poster, if neither, he can file a bug for us.
[13:29] <gary_poster> deryck, I think that's expected but I could be wrong.  danilos, do you remember?
[13:29] <gary_poster> would be fine with a bug in the abstract deryck
[13:29] <deryck> gary_poster, ok, cool.
[13:37] <rvba> abentley: Hi, I've replied to your comments on my MP (https://code.launchpad.net/~rvb/launchpad/lp-app-longpoll-js)
[13:38] <rvba> I tried to be thorough but I'm here if you need more information.
[13:38] <abentley> rvba: I see.  Sorry, I'm on a call, but I'll be looking at it soon.
[13:38] <rvba> abentley: sure. Thanks.
[13:40] <deryck> gary_poster, seb128 filed bug 806971.
[13:40] <_mup_> Bug #806971: team owners can't subscribe their team to bug emails <Launchpad itself:New> < https://launchpad.net/bugs/806971 >
[13:41] <deryck> gary_poster, I'm happy to triage since I'm on interrupt, but it might be worth someone on yellow weighing in if it's a bug or a feature. :)
[13:44] <gary_poster> deryck, ack.  I'll ask danilos to look at it
[13:44] <deryck> gary_poster, thanks.
[13:48] <flacoste> bigjools: do you have time to review my scoring branch? otherwise i could ask an ocr?
[13:48] <flacoste> bigjools: i'll remove the --raise-priority option
[13:48] <abentley> rvba: thanks for your changes.
[13:49] <rvba> abentley: thanks for your comments :).
[13:49] <abentley> rvba: I don't understand your rationale for wanting setupLongPollManager not to take LP.cache.longpoll as a parameter.
[13:50] <rvba> I wanted to call setupLongPollManage() without argument in the main template.
[13:50] <rvba> To avoid putting any logic in the main template.
[13:52] <abentley> rvba: setupLongPollManager() is logic too, so I don't see a big difference.
[13:53] <rvba> abentley: I still think it's best to keep all the details of the way the long poll thing works inside the js file.
[13:54] <bigjools> flacoste: would you mind using an OCR, I'm right in the middle of something.  FWIW it looked ok to me, apart from that option :)
[13:54] <flacoste> bigjools: ok, no problem
[13:54] <abentley> rvba: Okay.  r=me.
[13:55] <rvba> abentley: thanks.
[14:01] <flacoste> jcsackett: are you available to review https://code.launchpad.net/~flacoste/launchpad/bug-805634/+merge/67077
[14:01] <jcsackett> flacoste: sure.
[14:03] <jcsackett> flacoste: a little confused; the whole MP talks about a --raise-priority, but the most recent commit says it removes that option?
[14:04] <flacoste> jcsackett: yep, that was contentious as it would potentially block the build farm for a day or more to other users
[14:04] <jcsackett> flacoste: ok. i'll ignore that part of the MP then.
[14:05] <flacoste> yeah, so that becomes, new way to compute score for copy archives -- allowing for relative scoring within it
[14:05] <flacoste> and some other clean-ups
[14:25] <jcsackett> flacoste: r=me. you made soyuz code more understandable--that should get a medal. :-P
[14:25] <danilos> gary_poster, deryck: hum, could be a bug, don't remember right now
[14:25] <flacoste> jcsackett: thanks!
[14:25] <bigjools> jcsackett: I resemble that remark
[14:26] <gary_poster> danilos, ok.  so, the only important question is if it is a regression, I guess.  if it is, the bug is critical, if not, high or low, whatever.  deryck, do you happen to remember the old behavior here?
[14:26] <jcsackett> flacoste: :-)
[14:27] <deryck> gary_poster, well, we didn't provide a list before.  you could search to subscribe someone else, and search for your team.
[14:27] <gary_poster> you can still do that AFAIK, yeah?
[14:28] <gary_poster> deryck, danilos, I dunno, I'm inclined to mark this critical/regression and move on.  anyone disagree?
[14:28] <deryck> gary_poster, no.  seb128 wants to subscribe a team to for https://bugs.launchpad.net/ubuntu/+source/gnome-desktop3/
[14:28] <danilos> gary_poster, I feel the same, it's probably a minor bug in the server side code
[14:28] <deryck> and the list is provided once you click through.
[14:29] <deryck> gary_poster, danilos, I don't have any objections to critical and move on :)
[14:29] <danilos> (btw, this conversation seems weird considering we are talking 'critical' here :))
[14:29] <gary_poster> deryck, oh, I see.  I thought this was per bug, not per per pillar or whatever.  ok, cool, I'm triaging.  Thanks deryck and danilos!
[14:34] <gary_poster> deryck, danilos, actually I remember this.  I triaged high, with explanation in bug 806971, if you care.
[14:34] <_mup_> Bug #806971: team owners can't subscribe their team to bug emails <Launchpad itself:Triaged> < https://launchpad.net/bugs/806971 >
[14:37] <deryck> gary_poster, ah, good memory.
[15:24] <cr3> should mixin classes be implemented to be listed before or after base classes in the inheritance list?
[16:05] <danilos> jcsackett, hi, got time for a review? :)
[16:05] <danilos> jcsackett, hum, never mind, you already did :)
[16:07] <jcsackett> danilos: :)
[16:37] <LPCIBot> Yippie, build fixed!
[16:37] <LPCIBot> Project devel build #870: FIXED in 5 hr 54 min: https://lpci.wedontsleep.org/job/devel/870/
[16:53] <danilos> jcsackett, hi, now I do have another branch up with more of the expander replacements, though this one is mostly code removal: https://code.launchpad.net/~danilo/launchpad/drop-collapsibles/+merge/67224
[16:53] <jcsackett> danilos: i'm happy to look at it, as soon as i finish the one i'm currently looking at.
[16:53] <danilos> jcsackett, cool, thanks
[16:53] <danilos> jcsackett, I am about to leave, I hope you don't mind non-OCR reviews :)
[16:54] <jcsackett> danilos: no problem, i'll just leave comments on the diff if i have questions.
[16:54] <danilos> cool, ta
[16:55] <jml> cr3: mixins are generally after the main base class
[17:00] <bigjools> right, good night all
[17:00] <cr3> jml: thanks for the reassurance, I noticed the opposite in lazr.restful: class EntryResource(CustomOperationResourceMixin, FieldUnmarshallerMixin, EntryManipulatingResource):
[17:02] <jml> cr3: sometimes you do it differently to take advantage of Python's MRO semantics
[19:25] <cr3> how do you typically test for integrity errors, like making sure the same product cannot be created twice? I've seen very few references to the IntegrityError exception under the tests directories, so I'm wondering if there's a better
[19:25] <cr3> ... a better way even :)
[19:56] <lifeless> generally we don't
[19:56] <lifeless> not saying thats right or wrong ;)
[20:13] <gary_poster> jcsackett, are you up for a branch? https://code.launchpad.net/~gary/launchpad/bug607961/+merge/67246
[20:13] <jcsackett> garyposter: sure.
[20:13] <gary_poster> thanks
[20:37] <flacoste> lifeless or anyone else: any tip on what to do when the TEST RESULTS email failed with a 'message size exceeded error'?
[20:38] <lifeless> it means something went catastrohpically wrong
[20:38] <lifeless> the error output didn't compress enough to get mailed back
[20:39] <lifeless> if you run it again, but follow the status page, you can pull down the subunit before the thing shuts down
[20:39] <lifeless> gary_poster: FWIW: using the tip revision datestamp to sort out etags - wicked nice answer
[20:40] <gary_poster> lifeless, cool!  Glad you like it.  Based on an idea from benji.
[20:41] <flacoste> lifeless: i'm running --attached now
[20:50] <gary_poster> flacoste, IIRC, our default license is AGPL 3.  barry would like our bounce-detecting LMTP to be GPL 3 or LGPL 3, and has requested that this be worked out before we work on it.  He thinks it might be a general-purpose component, and indeed ISD seems like they want something similar (bug 592814).  I'm always a fan of LGPL myself.
[20:50] <gary_poster> What do I need to do to get the non-AGPL license approved?  It's been awhile since I had this kind of question...
[20:50] <flacoste> gary_poster: get approval from statik
[20:50] <flacoste> and potentially silbs
[20:51] <flacoste> but you can just ask statik, he can handle any higher approval needed
[20:51] <gary_poster> ack flacoste.  I'd prefer not to run it up that flagpole until we actually have something concrete, so I'll tell that to barry.
[20:51] <gary_poster> oh ok
[20:51] <gary_poster> I can do that then
[20:56] <jcsackett> gary_poster: r=me.
[20:58] <gary_poster> thanks jcsackett!
[21:19] <LPCIBot> Project db-devel build #706: STILL FAILING in 6 hr 6 min: https://lpci.wedontsleep.org/job/db-devel/706/
[22:13] <LPCIBot> Project devel build #871: FAILURE in 5 hr 35 min: https://lpci.wedontsleep.org/job/devel/871/
[22:45] <jcsackett> wgrant, wallyworld, StevenK: if you're planning on getting on mumble in about 15 minutes, I can be there.
[22:57] <wallyworld_> jcsackett: ok
[23:19] <StevenK> wgrant: You fail. Your db-devel merge included a 2208-99 DB patch number
[23:20] <wgrant> StevenK: Arghhh.
[23:26] <lifeless> wtf is this about http://pastebin.com/uyXnkWMK
[23:30] <mwhudson> that does seem pretty confused
[23:42]  * wallyworld_ needs more coffee already. it's going to be one of those days....
[23:43] <lifeless> ok, I've tracked down the problem, folk are changing the auth for 'browser'
[23:44] <lifeless> different to my pastebin
[23:44] <lifeless> the problem with gpg-coc and translationgroups
[23:44] <lifeless>     browser.mech_browser.addheaders
[23:44] <lifeless> Differences (ndiff with -expected +actual):
[23:44] <lifeless>     + [('User-agent', 'Python-urllib/2.6'), ('X-zope-handle-errors', False), ('Authorization', 'Basic test@canonical.com:test'), ('Authorization', 'Basic test@canonical.com:test'), ('Authorization', 'Basic test@canonical.com:test'), ('Authorization', 'Basic test@canonical.com:test')]