[00:00] <cjwatson> actually, mawson has a sufficient python-apt version
[00:00] <cjwatson> it'll have trouble with the multiarch-translations branch until we get it upgraded, but it'll be good enough for dpkg-xz-support
[00:01] <cjwatson> so it can be QAed on dogfood
[00:01] <StevenK> cjwatson: If this branch lands, it should be fine to test on mawson on Monday -- prod myself or wgrant before you start so we can update its code.
[00:02] <cjwatson> in that case, can I get https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations/+merge/67640 landed too?  we can test it on mawson then too
[00:02] <cjwatson> (I don't know what the procedure for QAing db-devel branches is)
[00:03] <StevenK> I think you might need to change the DB patch number. lifeless: ^
[00:03] <lifeless> cjwatson: that needs to be split
[00:03] <lifeless> its got both code and schema
[00:03] <lifeless> and we only deploy schema from db-devel
[00:04] <cjwatson> hm?  I already split out a schema branch for that
[00:04] <lifeless> https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess
[00:04] <lifeless> https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations/+merge/67640 ? i see changes to lib/lp/archivepublisher/model/ftparchive.py, to [00:04] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations-schema which has landed
[00:04] <lifeless>  etc
[00:05] <cjwatson> multiarch-translations was supposed to be just the code bit
[00:05] <lifeless> https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations/+merge/67640 has a db patch in it - = added file 'database/schema/patch-2208-79-0.sql'
[00:05] <lifeless> so this need to go to devel
[00:05] <lifeless> and it can't land until we've deployed the schema change
[00:06] <lifeless> thats blocked on the losas finishing pgbouncer migration
[00:06] <cjwatson> I'm confused about why LP is showing that, if you look at https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations-schema/+merge/67992 then it has the same schema patch
[00:06] <cjwatson> and it's merged
[00:06] <lifeless> which is blocked on them sprinting
[00:06] <lifeless> its certainly not deployed
[00:06] <cjwatson> I was told a couple of weeks ago that multiarch-translations needed to go to db-devel :-(
[00:06] <lifeless> the schema did
[00:06] <cjwatson> I would appreciate a consistent story here
[00:06] <lifeless> the other part, *if* you land on db-devel, will sit there until you cherrypick it across to devel post deploy of the schema change.
[00:07] <cjwatson> I can't cherrypick anything to devel personally, no access
[00:07] <StevenK> 79-0 is already on db-devel
[00:07] <lifeless> well, you would do it by preparing another branch which we can land via ec2 at the right time
[00:08] <lifeless> cjwatson: if you want to flush your queue, you can land this on db-devel yes. But we can't deploy it from there,
[00:08] <lifeless> cjwatson: I'm sorry that this feels inconsistent to you
[00:08] <lifeless> cjwatson: particularly if its my fault :)
[00:08] <cjwatson> 2011-07-14.log:12:54 <lifeless> cjwatson: for your branch, you'll need to land both components on db-devel (because we're not live on the incremental deploy steps yet)
[00:09] <lifeless> cjwatson: ah yes, so thats up to me to be more clear
[00:09] <cjwatson> so right now I am completely confused as to what I need to do.  I don't care about flushing my queue, I care about getting things deployed
[00:09] <lifeless> ok
[00:10] <StevenK> I can see the schema is already on db-devel
[00:10] <lifeless> so right now, this is blocked on losa work: we have no way to deploy schema changes until the pgbouncer migration is completed.
[00:10] <lifeless> thats stubs and the losas top priority ticket
[00:10] <lifeless> as soon as thats done we'll start doing fastdowntimes, one per day, with one db patch per day
[00:10] <cjwatson> that's fine.  what I'd like to know is (a) how I know when to proceed (b) what I should do next
[00:11] <cjwatson> oh and (c) what if anythng I should do to the multiarch-translations branch
[00:11] <lifeless> so - nothing.
[00:11] <cjwatson> merge it from db-devel maybe?
[00:11] <lifeless> the bug for the schema change should be sitting in fix committed now
[00:12] <lifeless> when we have the patch deployed that will toggle to fix released
[00:12] <lifeless> and we can continue with the rest of the work
[00:15] <cjwatson> bug for the schema change> is that https://bugs.launchpad.net/launchpad/+bug/809123 ?
[00:15] <_mup_> Bug #809123: we cannot deploy DB schema changes live <fastdowntime> <qa-ok> <Launchpad itself:Fix Committed by stub> < https://launchpad.net/bugs/809123 >
[00:15] <lifeless> that too; no I meant the one linked to your schema patch
[00:16] <lifeless> (there is one, isn't there? it may be the main one for your translations support)
[00:16] <cjwatson> there isn't onoe
[00:16] <lifeless> ah
[00:16] <lifeless> ok
[00:16] <beuno> hm
[00:16] <lifeless> so i suggest picking this up when 809123 is fix released
[00:16] <beuno> I'm getting an oops when searching for someone (trying to add a new ubuntu member)
[00:16] <lifeless> at that point we'll be a few days out from your thing being live
[00:16] <beuno> OOPS-2057DX
[00:16] <cjwatson> ok, subscribing to that
[00:18] <cjwatson> I basically just want to make sure that any delays in the process are not down to me - it's felt very much like there've been serial multiple-day delays so far
[00:19] <cjwatson> and I appreciate the assistance in deployment but the feature in general is important enough that I need to report on t
[00:19] <lifeless> cjwatson: welcome to LP dev :)
[00:19] <cjwatson> *it
[00:19] <cjwatson> heh
[00:20] <lifeless> cjwatson: this is one of the things that we're working on reducing - dev friction is insanely high atm
[00:20] <cjwatson> right, understood
[00:20] <cjwatson> and FWIW non-db stuff has clearly been getting better from my POV
[00:20] <lifeless> thanks!
[00:32] <cjwatson> I've merged db-devel into multiarch-translations so that it now clearly only contains code.  Do I need to resubmit that against devel (presumably after 809123 is fix released)?  Can I do that without losing approvals or will it need re-rubber-stamped?
[00:35] <lifeless> yes, an dyes, and probably needs a rubber stamp at that point. Use the 'resubmit' button.
[00:35] <lifeless> (at the right time)
[00:36] <cjwatson> ok
[02:19] <jtv> Hi wallyworld__
[02:19] <wallyworld__> jtv: yellow
[02:20] <jtv> ?
[02:20] <wallyworld__> jtv: hello
[02:20] <jtv> Ah.
[02:20] <wallyworld__> one review just popped up recently
[02:20] <wallyworld__> doing it soon
[02:20] <jtv> OK
[02:20] <wallyworld__> just finishing off a ^@%%@!& yui test
[02:21]  * jtv shudders in sympathy
[03:35] <jtv> StevenK, are you hammering dogfood?
[03:38] <StevenK> Not any more
[03:40] <jtv> Ah.  I just updated the code/schema as well.
[03:42] <jtv> And now it's failed to come up.
[03:42] <jtv> Ah.  Not that again.
[03:43] <jtv> Fixing it.
[04:07] <nigelb> wallyworld__: I thought my feelings to yui was isolated. apparently not ;-)
[04:08] <wallyworld__> nigelb: it's not that bad actually. just a bit tedious sometimes
[04:08] <nigelb> I know!
[04:08] <wallyworld__> to mock everything needed to allow the tests to run in isolation
[04:08] <nigelb> that's one of the things I'm stuck at because I lack time.
[04:08] <wallyworld__> how is your branch?
[04:08] <wallyworld__> yeah, i can understand that
[04:08] <nigelb> needs tests
[04:09] <wallyworld__> well you are not alone there
[04:09] <nigelb> hehe
[04:09] <nigelb> and work's been busy, so I get very little time
[04:09] <wallyworld__> what do yiu do for work?
[04:10] <nigelb> er, what? :)
[04:10] <wallyworld__> what's your day job?
[04:10] <nigelb> ah, I work as a systems engineer at a local startup :)
[04:11] <wallyworld__> sounds cool. i worked for a startup once, about 11 years ago
[04:11] <wallyworld__> but they went bust
[04:11] <wallyworld__> is everything working apart from the tests?
[04:11] <nigelb> heh
[04:11] <nigelb> yeah, the code's working for anon as well as non-anon user
[04:11] <nigelb> and I tested with private bug too
[04:12] <nigelb> so I want to catch alll that i my tests
[04:12] <nigelb> I put some ground work in there
[04:12] <wallyworld__> sounds good.
[04:14] <nigelb> the javascript bits doesn't have a test right now
[04:14] <lifeless> booyah
[04:14] <lifeless> I have oopses from gpgverify.
[04:14] <nigelb> So, I'll probably write a test for the entire code.  Also, because I want to learn how to do it
[04:19] <wallyworld__> nigelb: well, yes it will be educational to do it for sure
[04:20] <StevenK> s/educational/brain-damaging/
[04:21] <nigelb> lifeless: congrats!
[04:21] <nigelb> wallyworld__: yeah, that was my thinking :)
[04:21] <nigelb> StevenK: bwahaha
[04:25] <wgrant> lifeless: Paste?
[04:29] <lifeless> web.py
[04:30] <lifeless> doing $anything on thursday is daft.
[04:30] <lifeless> rule 1.
[04:30] <wgrant> I thought you'd discounted it.
[04:30] <wgrant> Hah.
[04:30] <wgrant> Right.
[04:30] <lifeless> http://bazaar.launchpad.net/~lifeless/+junk/gpgverify/revision/11?start_revid=11
[04:32] <wgrant> text/html... ew.
[04:32] <lifeless> meh
[04:32] <lifeless> that was cargo cloned; I should change.
[04:33] <wgrant> It must not be used frivolously.
[04:33] <wgrant> Like Twisted Web.
[04:33] <wgrant> (it defaults to text/html... what could possibly go wrong)
[04:33] <lifeless> or $all $web $frameworks
[04:33] <lifeless> so does flask
[04:33] <lifeless> and paste IIRC
[04:33] <wgrant> Kill it.
[04:33] <lifeless> for their errors
[04:33] <mwhudson> so does django
[04:33] <wgrant> Kill them all.
[04:33] <mwhudson> +1 wgrant
[04:34] <wgrant> Yes, let's just default to the most dangerous content type in the world.
[04:34] <wgrant> Nothing bad could come of that.
[04:37] <lifeless> fixed in 12
[04:40] <wgrant> Thanks.
[04:40] <wgrant> Although 'OOPS-ID' is not a standard HTTP header, AFAIK :P
[04:41] <nigelb> picky :P
[04:46] <wgrant> lifeless: We can't have some generic WSGI container launcher thing that does OOPS stuff, rather than having all this stuff in the core code of every service?
[04:46] <wgrant> Like our scripts, it seems silly to have all these boilerplate wrapper scripts rather than a parameterised launcher.
[04:49] <wgrant> I guess twistd is already a similar sort of thing.
[04:49] <wgrant> But I think we should do it for more than just daemons :)
[04:59] <lifeless> wgrant: well, if we have two * web.py services, we can have python-oops-webpy
[04:59] <lifeless> wgrant: it should be!
[05:00] <lifeless> wgrant: the problem is, as I said yesterday, web.py isn't actually wsgi
[05:00] <lifeless> its kindof wsgo
[05:01] <lifeless> same goes for flask.weurkzeug
[05:01] <lifeless> s/\.////
[05:01] <wgrant> :(
[05:01] <lifeless> they both want to stop exceptions bubbling out
[05:01] <lifeless> so they error handle themselves rather than as layers
[05:01] <wgrant> Yay
[05:02] <lifeless> by the time you're sniffing start_response for 500's and trying to reconstruct a long-gong sys.exc_info you've lost.
[05:02] <lifeless> I think hooking in in the preferred for for any given framework is best.
[05:02] <lifeless> thats the point of having a simple, flexible core, after all.
[05:02] <lifeless> its just a shame that wsgi is so micro that few things use it.
[05:03] <wgrant> It would be nice if there was a standard.
[05:03] <lifeless> e.g. werkzeug uses request and response objects, which wsgi has no knowledge off (and response puns as a wsgi app... which is actually quite good)
[05:03] <lifeless> but its request objects are thread local meta things
[05:05] <lifeless> anyhow
[05:05] <lifeless> I'm going to setup a project for gpgverify
[05:05] <lifeless> shove the current code in there
[05:05] <lifeless> teach it to handle detached sigs and use a regular form object at the same time
[05:05] <lifeless> and then next week, deploy the biatch.
[05:06] <lifeless> jamesh is playing with python-oops-wsgi, which django manages to have a sane way to integrate in
[05:06] <wgrant> Excellent.
[05:06] <lifeless> which is - huge - brownie points for django IMO
[05:07] <wgrant> (are you keeping a reasonably small backlog of in-progress work now, given your impending incapacitation?)
[05:07] <lifeless> we have two very modest features identified there to make it have parity with the used features of wsgi-oops
[05:07] <lifeless> wgrant: as much as I can yeah
[05:07] <wgrant> Great.
[05:07] <lifeless> I wanted to unblock SOA before my life changes forever
[05:07] <wgrant> Yes.
[05:08] <lifeless> the one key thing for oops remaining is to teach oops-tools to use a repo interface rather than parsing itself
[05:08] <lifeless> then we could switch it over to a different backend
[05:08] <wgrant> That interface gives back a dict?
[05:08] <lifeless> yes
[05:08] <wgrant> The current repo implementation is just a directory containing date dirs?
[05:09] <wgrant> So oops-tools would need lots?
[05:09] <lifeless> we'd want to shuffle a bunch of stuff like getOopReport(id) from lp into python-oops-datedir-repo
[05:10] <lifeless> we could model oops-tools needs as either a collection of repos
[05:10] <lifeless> or as a repo with knowledge of many root dirs.
[05:10] <wgrant> Right.
[05:10] <lifeless> the main thing is to lift the conceptual stuff out of rfc822 parsing and up to useful types
[05:10] <lifeless> with that done, we can switch to bson and iterate on things like messages and extra keys easily enough
[05:11] <lifeless> which is a totally separate project.
[05:11] <lifeless> relatedly, moving to cassandra might be unblocked if we take a map-reduce search approach rather than a pre-indexed one (for finding oopses by non-id)
[05:12] <wgrant> Why can't we pre-index?
[05:12] <lifeless> we can, with e.g. solandra
[05:12] <lifeless> but if we want anything more sophisticated map-reduce is probably a good idea anyway
[05:12] <wgrant> Yeah.
[05:12] <wgrant> Killall solr
[05:12] <lifeless> so starting with map-reduce would deliver the necessary conditions
[05:13] <lifeless> whereas starting with solandra doesn't really.
[05:13] <lifeless> þ
[05:16] <lifeless> anyhow
[05:16] <lifeless> thats for tomorrow^Wmonday
[06:40] <poolie> lifeless, hi, could we have a short supplementary chat?
[06:41] <nigelb> g31
[06:41] <nigelb> argh
[06:42] <poolie> :)
[08:07] <henninge> Anybody merging stable into db-devel currently?
[08:14] <henninge> No, that's not trivial for me.
[08:14] <henninge> ^ Looks like something jelmer_ and bigjools could do.
[08:17] <bigjools> seriously?
[08:17] <henninge> rvba: I will request a deploy. If your QA is quick it can still be included. ;-)
[08:18] <henninge> bigjools: I looked at bzr annotate and found your name and jelmer's for safe_open
[08:18] <rvba> henninge: if you're talking about 820452 then I'm afraid the QA won't be quick. :(
[08:18] <henninge> rvba: ok, np
[08:19] <henninge> one more reason to request the deploy asap ;)
[08:19] <rvba> Right :)
[08:22] <jelmer_> henninge, I'll have a look
[08:23] <henninge> bigjools, jelmer_ : I have a branch ready, so if you want to tell me how to fix it, I can do the mechanics.
[08:23] <bigjools> henninge: have you fixed the conflicts?
[08:23] <henninge> no ;)
[08:23] <henninge> just done the merge and looked at them
[08:24] <henninge> it's just one in each file, so it might be easy
[08:24] <bigjools> ok
[08:29] <StevenK> henninge: I'm a little concerned about deploying now, TBH.
[08:29] <henninge> StevenK: why is that?
[08:29] <henninge> StevenK: because it's Friday?
[08:29] <StevenK> henninge: Because most of IS are going to be on a plane over the weekend
[08:30] <henninge> oic
[08:30] <wgrant> It's Friday and everyone will be in the air for the weekend.
[08:30] <wgrant> And we don't have APAC LOSAs on Monday.
[08:30] <wgrant> The first LOSA will appear in 72 hours.
[08:30] <bigjools> do not deploy today, please
[08:30] <StevenK> The earliest we can deal with problems is Monday UK
[08:30] <henninge> good reasons ;-)
[08:30] <bigjools> we never deply on Fridays
[08:30] <henninge> I thought mornings are ok
[08:31] <henninge> but the "in the air" issue is a neck breaker.
[08:31] <henninge> I will re-visit this on Monday
[08:31] <bigjools> mornings are not ok
[08:31] <bigjools> some problems will only occurr overnight
[08:31] <henninge> so I learn ;-)
[08:32] <StevenK> henninge: Friday morning *in Australia* can be okay, since then we have LOSA coverage for another long while
[08:32] <wgrant> (we will occasionally deploy up to early afternoon my time, but I normally try to stick to mornings)
[08:34] <bigjools> henninge: for the test_notification conflict, take the second, larger chunk
[08:34] <henninge> bigjools: I will
[08:34] <bigjools> I dunno about the other
[08:36] <henninge> jelmer_: any insight on the merge?
[08:36] <henninge> for safe_open.py
[08:37] <allenap> henninge: I just emailed the list that I would sort out the stable -> db-devel conflicts, but bigjools says you're on it, and so I shall leave you to it :) Thank you.
[08:38] <henninge> allenap: you're welcome
[08:47] <jelmer_> henninge: what's the conflict like?
[08:47] <henninge> jelmer_: let me paste it
[08:48] <henninge> jelmer_: http://paste.ubuntu.com/669867/
[08:51] <jelmer_> henninge: you'd want the second chunk in that case
[08:51] <jelmer_> (bzr resolve --take-other)
[08:58] <jelmer_> is there a wiki page that describes what branch gets deployed where, when, how often, etc?
[09:01] <henninge> jelmer_: thanks
[09:06] <lifeless> poolie: sure
[10:22] <cjwatson> argh, why does launchpad-dependencies hate me
[10:23] <StevenK> cjwatson: It isn't just you, sadly.
[10:23] <cjwatson> turns out that the upload target isn't a reliable way to test which version it's being built for either
[10:24] <StevenK> cjwatson: I think I've just figured why your branch failed in ec2, too.
[10:24] <cjwatson> so it's broken in lucid right now
[10:24] <cjwatson> I suspect it might be related?
[10:24] <cjwatson> I mean, I noticed while trying to upgrade my LP dev VM, but ...
[10:24] <StevenK> cjwatson: The ec2 images are not updated for newer dependencies, they need to be done manually.
[10:25] <cjwatson> I could have sworn I saw an apt-get dist-upgrade in the test setup
[10:25] <cjwatson> ./lib/devscripts/ec2test/instance.py:134:aptitude -y full-upgrade
[10:25] <cjwatson>  launchpad-dependencies (0.97~lucid1) natty; urgency=low
[10:25] <StevenK> Hmm
[10:25] <cjwatson> anyway, that's why it's going wrong
[10:25] <cjwatson> bloody recipes
[10:26] <StevenK> Hah
[10:27] <cjwatson> while the IS builds are more like "launchpad-dependencies (0.97~0.IS.10.04) lucid-cat; urgency=low"
[10:54] <cjwatson> Could somebody review/merge https://code.launchpad.net/~cjwatson/meta-lp-deps/fix-target-detection-harder/+merge/72166 ?  Reasonably urgent since launchpad-dependencies is currently broken in the LP PPA for lucid
[10:54] <cjwatson> StevenK: maybe you could?
[11:02] <StevenK> cjwatson: You mean distroseries, not distribution
[11:03] <StevenK> But perhaps we should fix that
[11:03] <StevenK> Either way, r=me
[11:08] <cjwatson> StevenK: well - it's called Distribution in dpkg-parsechangelog output
[11:08] <cjwatson> so I was mirroring that
[11:08] <cjwatson> I can rename if you feel it necessary
[11:09] <cjwatson> StevenK: can you land it for me?
[11:29] <jtv> gary_poster: hi!  Say, do you know how I can enumerate all of Launchpad's registered utilities?  getGlobalSiteManager().registeredUtilities() gives me nothing.
[11:30] <gary_poster> hi jtv.  Thanks for looking at that.  Lemme look, one sec.
[11:32] <cjwatson> ... maybe somebody else can land https://code.launchpad.net/~cjwatson/meta-lp-deps/fix-target-detection-harder/+merge/72166 for me?  I've made the distribution -> distroseries substitution as suggested by StevenK
[11:33] <gary_poster> jtv, I'm surprised that registeredUtilities is giving you nothing.  It looks like it does all the right things.  Could it be that you called it before zcml was processed?
[11:34] <jtv> gary_poster: unlikely—I'm calling it from a LaunchpadScript and one of the reasons was that zcml would be processed for me.  :)
[11:34] <gary_poster> jtv, could you verify by trying to look up a utility?
[11:34] <jtv> You mean using zope.component.getUtility?
[11:35] <jtv> Or using getGlobalSiteManager().getUtility or something?
[11:35] <gary_poster> jtv, both, either.
[11:37] <jtv> gary_poster: Hmm... componentlookuperror
[11:37] <gary_poster> jtv, that's what I would expect.  registeredUtilities really does look in some integral data structures. :-)
[11:38] <jtv> Arrh… I think I needed to script.run() instead of script.main()
[11:38] <jtv> Now it takes the requisite 20 minutes to start up.
[11:38] <gary_poster> :-/
[11:38] <gary_poster> cjwatson, that needs ec2 land I assume?
[11:38] <jtv> gary_poster: it fails later now, so that gets us past the first hurdle.  Thanks.
[11:39] <gary_poster> cool jtv, np
[11:39] <cjwatson> gary_poster: no, AFAICS it's just direct-commit
[11:39] <gary_poster> cjwatson, you mean, you can verify that all tests pass, and if buildbot fails you will be shocked, awed, and at least mildly embarrassed? :-)
[11:39] <cjwatson> lp:meta-lp-deps is owned by ~launchpad-committers and the commits are all just direct
[11:40] <gary_poster> of duh
[11:40] <cjwatson> meta-lp-deps has no tests ...
[11:40] <gary_poster> s/of/oh/
[11:40]  * gary_poster was not looking closely enough
[11:40]  * gary_poster goes to look at mp
[11:40] <cjwatson> I wasn't suggesting direct commit to launchpad :-)
[11:40]  * cjwatson is nowhere near that brave
[11:41] <gary_poster> heh :-)
[11:42] <gary_poster> cjwatson, ok, I'm giving it a whirl
[11:43] <cjwatson> great, thanks
[11:46] <gary_poster> cjwatson, please approve/adjust commit message: "[r=StevenK] fix target detection so that it works for both recipe builds and the CAT repository"
[11:46] <jtv> gary_poster: next of my hurdles.  The docs I saw "on the internet somewhere" said UtilityRegistration had members "provides" and "provided."  But no.
[11:47] <jtv> Maybe it's just a typo.
[11:48] <gary_poster> jtv, according to code, it has "self.registry, self.provided, self.name, self.component, self.info, self.factory"
[11:48] <cjwatson> gary_poster: ack, that's fine
[11:48] <gary_poster> cool cjwatson
[11:48] <jtv> gary_poster: yup, the provides was a typo.  I'm getting further now.
[11:49] <jtv> Funny.  Some of them have empty names.
[11:50] <gary_poster> cjwatson, done
[11:50] <gary_poster> jtv, sure, those are utilities you just look up with an interface
[11:50] <gary_poster> ILaunchBag, for instance
[11:50] <cjwatson> gary_poster: thanks!
[11:50] <jtv> Well lots of them give an interface name as the utility registration's name.
[11:50] <gary_poster> welcome
[11:52] <gary_poster> jtv, yes, that's something you will probably want to filter out.  IIRC, something or other registers all interfaces that it encounters as a utility.  So that it can do something else.  Later.
[11:52] <gary_poster> s/all interfaces/each interface/
[11:53] <jtv> gary_poster: it looks as if the ones _with_ names are the ones I'm supposed to skip.
[11:54] <gary_poster> jtv, that's what I would expect to be the common case, yes.  I'd instead say that if the utility provides IInterface, skip it.  That might be equivalent, but it is more careful.
[11:55] <jtv> Oh, OK
[12:01] <jtv> gary_poster: checked 347 interfaces, 238 failed.  :/
[12:01] <gary_poster> jtv, ow.  :-(
[12:01] <jtv> Probably a bug in my code.
[12:01]  * gary_poster hopes so, practically speaking :-)
[12:02] <gary_poster> jtv, are you using the zope.interface-provided interface checker, or rolling your own
[12:02] <gary_poster> ?
[12:03] <jtv> gary_poster: I was lazy and grabbed our own test matchers' Provides.
[12:05] <gary_poster> jtv, ah ok.  I think I looked at that once but I forgot how that works.  I meant zope.interface.verify.verifyObject FWIW
[12:06] <jtv> Well, I'll just give it a whirl.
[12:07] <gary_poster> cjwatson, we've got a problem.  Don't know if it is related... https://launchpadlibrarian.net/77594282/buildlog.txt.gz
[12:08] <cjwatson> I just asked #is about that
[12:08] <cjwatson> it's not related to my change
[12:08] <gary_poster> ok thanks cjwatson
[12:08] <cjwatson> I suspect badness due to puppet deployment but that's just a guess ...
[12:09] <gary_poster> heh, puppet is getting a lot of bad press lately
[12:09] <cjwatson> I may be blaming it unfairly, it's just that I think I heard of a previous instance of this problem and I only started hearing about it this wewek
[12:09] <cjwatson> *week
[12:10] <jtv> gary_poster: getting better — 109 failures (out of 347)
[12:11] <jtv> I just wonder why so many raise DoesNotImplement.
[12:11] <gary_poster> jtv, I suggest you change the checker to lambda *args: True
[12:12] <jtv> What checker?
[12:12] <gary_poster> jtv, sorry, trying to make a joke.  verify your interface with an "everything passes".  Hee.  Hee.
[12:13] <jtv> Ah.  You are… American, right?  Might I suggest you check with a European first?  It may prevent misunderstandings.  :-P
[12:13] <gary_poster> jtv :-P
[12:13] <jtv> But the lambda idea is good too.  :)
[12:15] <jtv> gary_poster: I wonder if I need to do this differently for classProvides than for implements.
[12:15] <gary_poster> jtv, ah, quite possibly.
[12:16] <gary_poster> jtv, so you mean that we are registering some classes as utilities, yes?
[12:16] <jtv> And I'm pretty sure the component isn't supposed to be "security proxied __builtin__.type instance"
[12:16] <jtv> Yes, we use both in LP.
[12:16] <gary_poster> jtv, as a separate issue, you may need to rip off security procxies, if you have not already.
[12:17] <jtv> With disturbing pleasure.
[12:17] <gary_poster> lol
[12:18] <gary_poster> jtv, FWIW, I suspect you are right that neither verifyObject nor verifyClass will do what you want for class utilities.  You may need to make your own verification for that.
[12:19] <jtv> Seriously?
[12:19] <jtv> But I've verified them in the past as verifyObject(II, getUtility(II))
[12:22] <gary_poster> jtv, ah, then...I thought you implied it was not working? ("I wonder if I need to do this differently for classProvides than for implements.")  If it is working, then, uh, I suggest you keep using it.  I was just not confident that verifyObject would do what you need without digging into it.
[12:23] <jml> why would you remove security proxies?
[12:24] <jtv> gary_poster: I'm not sure if it's working or not.  I'm getting a bunch of DoesNotImplement exceptions (besides some other exceptions that I did expect)
[12:30] <gary_poster> jml, primarily because security proxies will only let someone with the proper authority look at the value.  I suppose another approach would be to log in as a Launchpad admin (if I remember correctly that they have all permissions in all contexts).  Secondarily because the verification machinery might not expect them generally, and it's a good first pass to ignore them.
[12:32] <gary_poster> jtv, ok.  In your shoes, I'd simply investigate some seemingly representative reports and see if the complaints seem to have merit.
[12:32] <jml> gary_poster: oh, of course. I was thinking only of the security proxies other duty as JIT interface validators (e.g. raising ForbiddenAttribute because you spelled 'displayname' incorrectly)
[12:33] <jtv> gary_poster: I guess I could try to verify the result of getUtility instead of the component.
[12:33] <jml> maybe some of those utilities don't have correct implements() lines.
[12:33] <jtv> Since 93 of the 124 failures I have now are DoesNotImplement, I think I'm verifying the wrong object.
[12:34] <jtv> jml: wouldn't that be noticed immediately?
[12:40] <jtv> gary_poster, jml: checked out a first case of DoesNotImplement… the implements() is in a base class.
[12:40] <jtv> I suppose that would also apply for all these vocabularies that are giving me the same error.
[12:42] <jtv> If I check getUtility(interface) instead of utility_registration.component, I only get 11 instances of DoesNotImplement.
[12:42] <gary_poster> huh
[12:43] <gary_poster> I have not worked with utility registrations enough to know how unexpected that might be
[12:43] <gary_poster> I'd say stick with whatever spelling seems to reflect reality and move on, myself.  That might be stating the obvious.
[12:53] <Ursinha> is is just me or launchpad has performance issues today?
[12:53] <Ursinha> scripts are timing out
[13:05] <gary_poster> Ursinha, I haven't experienced any problems myself, but graphs seem to suggest that we had increased db load and an increased number of errors starting about six hours ago.  I have no idea what that might be: we have not had a rollout since the 16th.
[13:06]  * gary_poster tries to find page performance report, and tries to remember other tools for this.
[13:06] <Ursinha> gary_poster: I'm not able to generate ubuntu reports for a while; in general it takes about 6 minutes and now it's timing out
[13:07] <StevenK> cjwatson: Sorry about that, I was picking up my wife and having dinner. Did you find someone?
[13:07] <gary_poster> StevenK, hey, I did it for him
[13:07] <StevenK> gary_poster: Excellent, thanks.
[13:08] <gary_poster> StevenK, do you happen to have an idea of something that might have changed six hours ago to make our db load and errors increase?  It is not an increased number of requests, according to the graphs.
[13:09] <StevenK> And the recipe fails due to chroot problem? Awesomeness
[13:09] <gary_poster> (number of requests: https://lpstats.canonical.com/graphs/AppServerRequestLpnet/ ; 5xx s : https://lpstats.canonical.com/graphs/AppServer5XXsLpnet/ ; db load : https://lpstats.canonical.com/graphs/DBCpuLoadAppServers/)
[13:09] <gary_poster> heh, yeah StevenK. :-/
[13:09] <StevenK> gary_poster: That isn't your fault, though.
[13:10] <gary_poster> StevenK, yeah, cjwatson thought it might be puppet
[13:10] <StevenK> gary_poster: The only thing I can think of that I did six hours ago was finish work. :-)
[13:10] <cjwatson> lamont is looking at it
[13:10] <gary_poster> StevenK, that's it! ;-)
[13:10] <StevenK> Aw, man. Now I have to work the weekend. :-P
[13:10] <gary_poster> :-)
[13:12] <StevenK> gary_poster: Just thinking about it, check with the LOSAs, mizuho and cocobanana were brought under the iron fist of puppet around that time
[13:12] <gary_poster> ok thanks StevenK, I'll ask them (do we even have any?)
[13:12] <gary_poster> I'll find out :-)
[13:18] <Daviey> Ursinha: yeah, i am seeing timeouts aswell.
[13:19] <Ursinha> Daviey: all of our scripts are failing, desktop team as well
[13:23] <jtv> gary_poster: any feedback on lp:~jtv/launchpad/audit-utilities would be most welcome.  Run utilities/audit-utilities.py to see what I get so far.
[13:23] <jtv> Not now though; I'll be off!
[13:24] <gary_poster> jtv, cool.  working on emergency; please ask Monday and will be happy to
[13:24] <gary_poster> Have a great weekend
[13:24] <jtv> same to you!
[13:30] <stub> Cool. fiera is doing recursive queries now. Didn't realize anyone was using them yet.
[13:31] <bigjools> Oo
[13:31] <deryck> henninge, ping for standup
[13:31] <henninge> oh, yeah
[13:31]  * henninge boots phone, looks for headset
[13:37] <jelmer> Hmm, qastaging is giving me a "Internal Server Error" for loggerhead - is there an easy way to see the actual error?
[14:25] <henninge> abentley: Hi!
[14:25] <abentley> henninge: hi!
[14:26] <henninge> abentley: can we mumble about iorecorder?
[14:26] <abentley> henninge: 1 sec
[14:43] <cjwatson> Does anyone know how to make https://code.launchpad.net/~launchpad/+archive/ppa/+recipebuild/73739 (from https://code.launchpad.net/~launchpad/+recipe/meta-lp-deps-on-demand) try again?
[14:43] <cjwatson> lamont tells me that the buildd problem is fixed now
[14:43] <cjwatson> maybe people in the ~launchpad team get more buttons there than I dod
[14:43] <cjwatson> *do
[14:44] <bigjools> looks like the build page has a bug
[14:44] <bigjools> says it's finished but offers me a link to cancel it still
[14:44] <cjwatson> me too
[14:44] <cjwatson> maybe if we cancel it will try again later?
[14:44] <bigjools> mebbe
[14:45] <bigjools> don't know much about this stuff
[14:45] <cjwatson> I can't rescore it either
[14:45] <cjwatson> who does?
[14:45] <bigjools> I can :)
[14:45] <bigjools> abentley does
[14:45] <cjwatson> I get the link, but it says "Cannot rescore this build because it is not queued."
[14:45] <bigjools> huh
[14:45] <bigjools> yes the page is buggy
[14:46] <bigjools> I bet it thinks "chroot problem" is not a real error
[14:47] <abentley> cjwatson: you request a build from https://code.launchpad.net/~launchpad/+recipe/meta-lp-deps-on-demand
[14:49] <cjwatson> abentley: I'm not sure I have the right team access to request a build that goes into ~launchpad/+archive/ppa
[14:50] <cjwatson> (if I did, that would probably be a bug)
[14:50] <cjwatson> abentley: can you?
[14:51] <abentley> cjwatson: I see the "request build(s)" link on the page, so I assume I do.
[14:51] <abentley> cjwatson: Do you not see it?
[14:53] <cjwatson> I do, but surely I only have access to request builds into PPAs owned by myself or teams I'm a member of; I am not a member of launchpad
[14:53] <bigjools> cjwatson: I'll request a build, is it just lucid you need?
[14:53] <cjwatson> yeah, the others look done
[14:53] <bigjools> done
[14:54] <cjwatson> thanks
[14:57] <allenap> adeuring, bac: Have you got time for a short-ish review? https://code.launchpad.net/~allenap/launchpad/librarian-log-bug-828151/+merge/72097
[14:57] <bac> allenap: i do
[14:57] <allenap> bac: Thanks :)
[14:57] <bac> np
[14:59] <deryck> bigjools, there's an lp question about sudo error and busted builds I'm working through....
[15:00] <bigjools> deryck: should be fixed
[15:00] <deryck> bigjools, ok, thanks.
[15:00] <bigjools> :)
[15:00] <deryck> easy peasy :)
[15:29] <bac> allenap: done
[15:29] <allenap> Thanks bac.
[15:30] <deryck> sinzui, ping.
[15:30] <sinzui> hi deryck
[15:31] <deryck> sinzui, hi there.  Do you think you could spare a minute to help kate in:  https://answers.launchpad.net/launchpad/+question/168164 ?
[15:31] <deryck> sinzui, you could probably directly answer her as quickly as walk me through how to answer her :)
[15:32] <sinzui> This might be a permission issue. Lots of attr are only setable by LOSAs because Ubuntu one made 100s of members project owners
[15:32] <sinzui> investigates
[15:33] <deryck> sinzui, thanks!
[15:34] <sinzui> s/Ubuntu one/Ubuntu once/
[15:39] <deryck> sinzui, can I assign the question to you and note that you're looking into it?
[15:39] <deryck> sinzui, ah, never mind.  I see you did assign it.  Sorry.
[15:40] <deryck> stupid page reloads.
[15:40] <sinzui> deryck, datereleased is not directly setable. it is implicitly set by the Web UI when the series status is set to current.
[15:41] <sinzui> deryck, since the releases are being done by API, there is no way that the date is set. the field is not exposed in the UI either
[15:41] <deryck> ah, ok.
[15:42] <sinzui> deryck, I think we need to choose a) push the rule into the model so that the status attr also updates the datereleased attr or b) expose the datereleased attr over the api to let owners change it anytime they like.,
[15:44] <deryck> sinzui, I like b personally.  Makes sense to me an owner might want to set this themselves, if doing everything else over the API.
[15:44] <sinzui> I see datereleased is exported over the API. I think someone can set it
[15:45] <sinzui> deryck, the rule is in place to ensure the field is not set in an impossible status. field validator is needed
[15:46] <jcsackett> sinzui: mumble?
[15:46] <deryck> sinzui, can't the validator kick in, even if set over the API?  But it sounds like this is possible anyway, if it's exposed.
[15:47] <sinzui> ah, the field is editable over the api by anyone with LP moderate, which hopefully includes the series RM
[15:48] <jcsackett> oh, sorry, i see you're in the middle of a conversation. :-P
[15:48] <sinzui> deryck, the validator will kickin if we define a new field or update the existing date field to use constraint=???
[15:52] <cjwatson> StevenK: do you think you could run dpkg-xz-support through again, once you see this?  I'd like to establish whether it has anything to do with the launchpad-dependencies breakage (which seems not unlikely) before doing further manual investigation
[15:52] <deryck> sinzui, ah, I was thinking of the old bugs way of having a mutator in the model that does the validation in Python. This doesn't work if there are db constraints doing the validation now.
[15:56] <sinzui> deryck, The answer to the question is the jeremy is not an admin or registry expert. I think we want to change the security checker so that the series.driver (RM) or all ubuntu drivers can change (version name status nominatedarchindep changeslist datereleased)
[15:57] <sinzui> I will update the question and link it to the really old bug we have been trying to fix by changing the Ubuntu team structure
[16:06] <deryck> sinzui, ok, cool.  Thanks much!
[16:51] <sinzui> jcsackett, I sorted out the distro stuff. I can talk now
[16:51] <jcsackett> sinzui: i just grabbed lunch. ping you when i'm done?
[16:52] <sinzui> yes
[17:00] <jcsackett> sinzui: i'm getting on to mumble now.
[17:06] <henninge> help!
[17:06] <henninge> I am totally stuck in trying to get a js test to run.
[17:06] <henninge> Something to do with loading, I think
[17:08] <henninge> hm, just solved one thing but there was more ...
[17:11] <henninge> Which js file do I need to load to have the "LP" object defined?
[17:13] <jml> henninge: lib/lp/app/templates/base-layout-macros.pt?
[17:13] <henninge> oh
[17:13]  * henninge looks
[17:13] <jml> it's just a grep-informed guess.
[17:15] <henninge> I only searched js files.
[17:15] <henninge> jml: yeah, it's there
[17:15] <henninge> but that's no use for a test, so I will have to create a dummy I guess.
[17:17] <jml> henninge: grep also points me at lib/lp/code/javascript/tests/test_branchrevisionexpander.html:
[17:17] <jml> henninge: which, at a guess, declares a dummy.
[17:18] <henninge> yes it does
[17:18] <henninge> jml: thanks
[17:18] <jml> henninge: don't thank me, thank 'bzr grep "var LP"'
[17:19] <henninge> ;-)
[17:36] <deryck> henninge, do you want LPS object or the js web service client?
[17:37] <henninge> deryck: LP.cache
[17:37] <henninge> but I got it figured out now.
[17:37] <deryck> henninge, ok.
[18:01] <flacoste> sinzui: you might interested in bug 829678
[18:02] <_mup_> Bug #829678: Person picker widget to add a member says it fails but really didn't <person-picker> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/829678 >
[18:03] <sinzui> flacoste, no I am not. It is a dupe of the bug that jcsackett is working on
[18:03] <flacoste> sinzui: a cool, then!
[18:04] <sinzui> I will update the master bug because I reported nothing happen because the spinner failed.
[18:13] <benji> jam: is there a particular person I should ask to review a small bzr MP?  (https://code.launchpad.net/~benji/bzr/bug-702914/+merge/72239)
[18:15] <benji> darn, I bet jam is quite AFK at the moment
[18:22] <jelmer> benji___: hi
[18:22] <benji> hi jelmer
[18:23] <jelmer> benji___: it's really nice to see tests for the lazy import threading issue
[18:23] <jelmer> benji: have you seen bug 396819
[18:23] <jelmer> ?
[18:23] <_mup_> Bug #396819: AttributeError: _factory - lazy imports are not threadsafe <lazy-imports> <oops> <Bazaar:Confirmed> <loggerhead:Triaged> < https://launchpad.net/bugs/396819 >
[18:25] <benji> jelmer: nope, I hadn't seen that; it looks like a dupe of the other (or rather, the other is a dupe of 396819)
[18:25] <jelmer> benji: yeah, indeed
[18:28] <abentley> bac: could you please review https://code.launchpad.net/~abentley/launchpad/upgrade-not-branch-error/+merge/72242 ?
[18:28] <bac> abentley: sure
[18:28] <abentley> bac: thanks.
[18:31] <benji> jelmer: do you know if the bzr guys look at their review queue regularly (i.e., will they find my MP lying there and pick it up) or should I email one or more of them?
[18:33] <abentley> benji: they have one guy assigned to the review queue, called the "patch pilot", every week.
[18:33] <bac> looks good abentley
[18:33] <benji> abentley: great, thanks
[18:33] <abentley> benji: from their topic, looks like it's Riddell this week;.
[18:33] <abentley> bac: thanks.
[18:34] <benji> abentley: cool, I'll anticipate hearing from him then
[18:35] <jelmer> benji: I was actually just doing a review :)
[18:35] <benji> jelmer: yay!
[18:36] <jelmer> benji: I'd like to get some input from jam too though, as he's probably most familiar with lazy_import and all its corner cases.
[18:37] <benji> makes sense
[19:04] <jelmer> benji: do you know if there's any way to find out why loggerhead on qastaging is failing? It's just giving me a "Internal Server Error" without referencing an OOPS or anything like that.
[19:05] <benji> jelmer: not off the top of my head... but I'll look at it in a minute and see if I can think of anything
[19:08] <jelmer> benji, thanks
[19:23] <nigelb> what's the correct alternative to EDGE_SERVICE_ROOT these days?
[19:24] <abentley> nigelb: production.
[19:25] <abentley> nigelb: i.e. LPNET_SERVICE_ROOT
[19:25] <nigelb> aha
[19:25] <nigelb> abentley: thanks!
[19:26] <abentley> nigelb: no problem.
[20:04] <benji> jelmer: it looks like it's having an error trying to report an error that it's having: https://pastebin.canonical.com/51493/
[20:20] <henninge> abentley: maybe you'd enjoy reviewing this? https://code.launchpad.net/~henninge/launchpad/bug-824435-failure-reporting/+merge/72255
[20:20] <henninge> abentley: but I can also ask the OCR
[20:21] <abentley> henninge: I'm happy to look at it.
[20:21] <henninge> abentley: thanks
[20:21] <nigelb> flacoste: aww, I wish I could see those graphs
[20:26] <abentley> henninge: in some browsers (IE), the last element in a list must not have a comma following it.  Please fix that before landing.
[20:31] <abentley> henninge: It also looks like you've made changes that will break the existing use of IORecorder, i.e. renaming success -> response.
[20:32] <henninge> abentley: I added "respond" and made "success" use that.
[20:33] <henninge> but  I just found something else, so expect another revision.
[20:33] <henninge> abentley: I also ran test_lp_client with that new iorecorder.
[20:34] <abentley> henninge: okay, cool.  I didn't see the new success.
[20:34] <flacoste> nigelb: i can't give you access, but I can copy them in a public location
[20:35] <nigelb> flacoste: that would work, thanks!
[20:36] <jelmer> benji: sorry, was away for a bit for dinner
[20:36] <jelmer> benji: that error looks odd
[20:36] <jelmer> benji, out of curiosity, where did you look to find that log?
[20:37] <benji> jelmer: note that I'm not sure that that error is the result of requests, but it's the only error in the logs
[20:37] <benji> jelmer: from /srv/launchpad.net-logs/qastaging/asuka/launchpad.log on devpad.canonical.com
[20:42] <jelmer> benji: ah, thanks
[20:42] <henninge> abentley: screenshots in the MP! ;-)
[20:43] <abentley> henninge: cool.
[20:45] <henninge> abentley: I also pushed a new revision
[20:46] <abentley> henninge: r=me
[20:46] <henninge> abentley: thanks! ;-)
[20:47] <nigelb> I forget, how is it that I run only one test?
[20:55] <flacoste> nigelb: http://people.canonical.com/~flacoste/LPProjectCriticalClosed-2011-04-01_2011-0820.png
[20:55] <flacoste> and http://people.canonical.com/~flacoste/LPProjectCriticalFiled-2011-04-01_2011-0820.png
[20:55] <nigelb> flacoste: yay, thanks!
[21:08] <deryck> Have a nice weekend, everyone.
[21:20] <bac> sinzui_: you still around?
[21:20] <sinzui_> I am
[21:20] <sinzui> irc was lying
[21:20] <bac> sinzui_: mvo is reporting he cannot see private bugs for a source package he is the maintainer
[21:21] <bac> has anything changed around private bug visibility?
[21:21] <sinzui> No
[21:21] <sinzui> You still need to be subscribed
[21:21] <bac> he's also indirectly in the team that is the bug supervisor for the distro
[21:22] <sinzui> but is the supervisor subscribed to those bugs?
[21:22] <sinzui> marking a bug private does not subscribe the supervisor, though I hope to fix the 6 year old bug in 4 weeks
[21:23]  * bac looks at userCanView
[21:24] <sinzui> bac: which distro? Ubuntu?
[21:24] <bac> yes
[21:24] <bac> update-manager package
[21:24] <bac> mvo
[21:25] <bac> sinzui: i thought the bug supervisor was subscribed to bugs when they are made private
[21:26] <nigelb> bac: I just tested on qastaging. Only security supervisor is sub'd for private bugs.
[21:27] <sinzui> bac: Consider the changes made by structural subscriptions. User can be very specific about what they subscribe to and about the team that is subscribed. When a bug is made private, the structural subscribers are converted to bug subscribers. In the past, the bug supervisor could not control which email he got...he was subscribed to every bug, so he was always in the set of people subscribed. Now that the team can filter
[21:27] <sinzui>  the notifications, the team is implicitly opting out of private bug subscriptions
[21:28] <bac> oi
[21:28] <sinzui> There is only one code point where a bug supervisor is explicitly subscribed to a bug, and it was written by statik 4 years ago. When a bug is created for a project with private bugs, the supervisor is subscribed
[21:29] <bac> ah, right, that's why a project must have a bug supervisor before 'private by default' is enabled. that bit is what was confusing me.
[21:36] <sinzui> bac, Since I can see mvo's +participation page, I assume his membership in ~ubuntu-bugs is correct. Can other members of that team see the bugs? Are then only subscribed via that team
[21:36] <sinzui> bac: there is a small chance that something else private on that page could cause a 403 oops for him as we have seen on branch pages
[22:21] <nigelb> anyone around?
[22:28] <nigelb> gah, monday then.