[00:00] <poolie> hm
[00:00] <poolie> if i change buildrecipe into an importable module so that i can test it...
[00:00] <poolie> that seems to have a fair risk of breaking something during deployment
[00:18] <lifeless> yes
[00:18] <lifeless> its also an entirely separate project
[00:18] <poolie> well
[00:19] <poolie> i would like to add automatic tests for my changes
[00:19] <lifeless> just something to be aware of
[00:19] <poolie> i guess i could add a separate landing to just make it testable
[00:19] <poolie> it seems like a high risk change so perhaps i'll just do without
[00:25] <wgrant> lifeless: Thanks.
[00:25] <wgrant> Still extremely slow, but it works.
[00:25] <wgrant> lifeless: What's the production rabbit status?
[00:25] <wgrant> lifeless: And are we going to persist with rsync-based fallback, or have a disk2amqp daemon?
[00:26] <wgrant> s/daemon/cronjob/, if you like.
[00:33] <lifeless> wgrant: cron job
[00:33] <lifeless> wgrant: plumbing written, just need a glue project to pull it all together (datedir repo on one hand, amqp on the other)
[00:33] <lifeless> wgrant: see oops-datedir-repo 0.0.10
[00:33] <wgrant> We should also ensure that the config name and tree base and script name are in the OOPSes, and then nuke all our OOPS configs :)
[00:34] <wgrant> Ah, excellent!
[00:34] <lifeless> prod rabbit is pending firewalls and tuolumne and nagios etc
[00:34] <lifeless> I've an rt up for migration to this including moving to a shared local-oops dir for all servers
[00:34] <wgrant> Great.
[00:35] <lifeless> beuno is champing at the bit to get this for u1 ;)
[00:35] <spm> i think the firewall's been done. was some chatter around that recently.
[00:36] <beuno> YES
[00:36] <lifeless> looks like it
[00:36] <wgrant> We also need a better way to handle rabbit passwords.
[00:36] <wgrant> Currently they're in the LP configs, which won't really do.
[00:36] <lifeless> so yes, we're ready to receive prod oopses over rabbit when the rest of the bits come together
[00:36] <wgrant> We probably need to read them from some other file.
[00:36] <lifeless> whats the issue ?
[00:37] <wgrant> Configs are widely accessible, and the rabbitmq instance is accessible from more than just production LP servers.
[00:37] <lifeless> you mean 'someone could connect and either consume or inject inappropriate messages' ?
[00:37] <wgrant> yes.
[00:38] <lifeless> so, moving oops-tools to its own box will help there
[00:38] <wgrant> Indeed.
[00:38] <lifeless> also we need to make sure the lp rabbit user has narrow perms
[00:38] <wgrant> But we should be treating our message queue like we treat our DB, I think.
[00:38] <lifeless> I haven't checked on that
[00:38] <wgrant> Good luck with that...
[00:38] <wgrant> How do you propose to do that?
[00:39] <wgrant> It basically needs to be able to write to everything.
[00:39] <lifeless> not at all
[00:39] <wgrant> And eventually read lots of things too, probably.
[00:39] <lifeless> write to oopses, create and write to longpoll.*, read from nothing, admin nothing.
[00:39] <lifeless> (today)
[00:39] <lifeless> thats pretty narrow
[00:39] <wgrant> Today.
[00:39] <lifeless> and as it changes, we can change it.
[00:39] <lifeless> bbs
[00:42] <poolie> lifeless, i commented on https://code.launchpad.net/~mbp/launchpad/bug-width/+merge/80161
[00:45] <poolie> wgrant: do you have any idea how buildrecipe gets installed, or where it gets renamed to buildrecipe.py?
[00:45] <StevenK> It's probably contained in lp-buildd
[00:45] <StevenK> So the build machinery of lp-buildd likely renames it
[00:46] <poolie> and that's not in the lp tree?
[00:46] <poolie> apparently not public ?
[00:46] <StevenK> It is, lib/canonical/buildd
[00:46] <wgrant> poolie: I don't think it actually does get renamed.
[00:47] <wgrant> [sourcepackagerecipemanager]
[00:47] <wgrant> buildrecipepath = /usr/share/launchpad-buildd/slavebin/buildrecipe
[00:47] <poolie> StevenK: i don't see anything in there that renames it
[00:47] <wgrant> argv[0] might be buildrecipe.py, but I think it's a lie.
[00:48] <poolie> yes!
[00:48] <poolie> just realized the same thing
[00:48] <poolie> :/
[01:11] <poolie> StevenK: hi
[01:12] <poolie> you don't need to write a lep for my sake
[01:12] <poolie> just a 'i'm planning to do X' on the bug would be ince in general though
[01:27] <poolie> short review on https://code.launchpad.net/~mbp/launchpad/884997-rusage/+merge/80971please anyone?
[01:57] <wgrant> lifeless: Did you change the uppercasing rule part-way through yesterday?
[01:57] <wgrant> Some of the hashes are allcaps, some are not.
[01:58] <lifeless> in the db ?
[01:58] <lifeless> or as reported to users? the latter is hashlib variations
[01:58] <wgrant> DB, I assume.
[01:58] <wgrant> It's in the reports.
[01:58] <lifeless> hmm, odd. Possibly dboopsloader needs a fix too.
[01:58] <lifeless> I shall check.
[01:59] <wgrant> Ah
[01:59] <wgrant> Could be.
[02:01] <lifeless> yeah, from_pathname needs a fix
[02:02] <lifeless> cowboyed
[02:02] <lifeless> [02:02] <lifeless> --- src/oopstools/oops/models.py        2011-10-31 02:07:24 +0000
[02:02] <lifeless> +++ src/oopstools/oops/models.py        2011-11-02 02:02:03 +0000
[02:02] <lifeless> @@ -476,6 +476,7 @@
[02:02] <lifeless>          oopsid = parsed_oops.get('id')
[02:02] <lifeless>          if oopsid is None:
[02:02] <lifeless>              raise OopsReadError('Not a valid OOPS report')
[02:02] <lifeless> +        parsed_oops['id'] = parsed_oops['id'].upper()
[02:05] <wgrant> Thanks.
[02:08] <wgrant> lifeless:        1 https%3A//launchpad.net/ubuntu/%2Bsource/oops/1.5.23.cvs-5.1/%2Bbuild/390896/%2Bindex (BinaryPackageBuild:+index)
[02:08] <wgrant>         OOPS-48d0191b7ac2d3136e4bd47d385fceb7
[02:08] <wgrant>        1 https://launchpad.net/ubuntu/+source/oops/1.5.23.cvs-5.1/+build/390896/+index (BinaryPackageBuild:+index)
[02:08] <wgrant>         OOPS-2131AU23
[02:08] <wgrant> New URLs are excessively URL-encoded.
[02:17] <lifeless> I was afrait of that
[02:17] <lifeless> I think I mentioned it
[02:18] <lifeless> probably need an LP change - I suspect its emitting them as unicode
[02:52] <poolie> is this pqm rejection lp's way of telling me you're only taking rc fixes?
[02:52] <poolie> no
[03:01] <wgrant> poolie: It's because we're in testfix.
[03:01] <poolie> and is that advertised anywhere?
[03:01] <StevenK> No, because PQM sucks.
[03:02] <poolie> i thought people used to put it in the topic here or something
[03:02] <poolie> anyhow, np, just glad it's not my branch
[03:27] <wgrant> lifeless: Around?
[03:29] <lifeless> yas
[03:30] <wgrant> lifeless:   File "/srv/lp-oops.canonical.com/cgi-bin/lpoops/src/oopstools/oops/models.py", line 309, in _get_oops_tuple
[03:30] <wgrant>     for key, value in req_vars:
[03:30] <wgrant> ValueError: need more than 1 value to unpack
[03:30] <wgrant> Broken by a ['field.blob']
[03:30] <wgrant> Without a value.
[03:30] <wgrant> Assume ''?
[03:31] <lifeless> ugh
[03:31] <lifeless> also win
[03:31] <lifeless> so that needs two bugs
[03:32] <lifeless> a) yes we should handle that
[03:32] <StevenK> I thought that was already done
[03:32] <lifeless> and b) we shouldn't be generating that
[03:32] <lifeless> also c) req_vars should be a dict
[03:32] <StevenK> I remember reviewing something that did that
[03:32] <lifeless> but there is a bug on that lready
[03:32] <lifeless> StevenK: urls
[03:32] <lifeless> StevenK: / encodings
[03:32] <StevenK> Not everything has a URL
[03:33] <StevenK> What do you do for script OOPS
[03:36] <wgrant> lifeless: Are you fixing the immediate issue, or should I?
[03:45] <lifeless> StevenK: I know
[03:46] <lifeless> wgrant: please do
[03:47] <wgrant> It even works.
[04:14] <StevenK> OOPS summaries twice in one day?
[04:14] <wgrant> Yes, the old ones were wrong.
[04:14] <wgrant> And today's are of particular interest.
[04:17] <wgrant> lifeless: Is there a branch for your cowboy?
[04:17] <lifeless> not yet
[04:18] <lifeless> if you're doing one, roll this in
[04:18] <wgrant> Was about to ask you to do the same :)
[04:18] <lifeless> I can later
[04:19] <wgrant> Also tempting to upper() the oopsids that were imported badly.
[04:19] <lifeless> it would make them accessible
[04:19] <lifeless> the oops table is a bit big to do it without date constraints
[04:19] <wgrant> I planned to restrict to the last few days.
[04:26] <wgrant> All seems happy now.
[04:43] <poolie> is lp out of testfix?
[04:43]  * StevenK becks
[04:43]  * StevenK grumbles at his keyboard
[04:44] <wgrant> spm: Can you check if pigeonpea and pilinut need cleaning?
[04:44] <spm> yup
[04:45] <wgrant> lifeless: https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1517/steps/shell_6/logs/summary looks possibly relevant to you
[04:46] <spm> there's a bunch of oldish rabbits still running
[04:46] <spm> only on pilinut tho
[04:46] <spm> pigeonpea looks clean
[04:46] <wgrant> Does pigeonpea have any old pid files in /var/tmp?
[04:47] <lifeless> no old appserver processes ?
[04:47] <spm> buildbot@pigeonpea:~$ ls /var/tmp/*.pid | wc -l
[04:47] <spm> 111
[04:47] <spm> maybe....
[04:48] <spm> nothing running as BB, just the slave itself. no old processes running.
[04:48] <spm> ^^ pigeonpea; all that applies to.
[04:50] <spm> should I assume those pids should be rm'd?
[04:50] <lifeless> pleas
[04:50] <lifeless> e
[04:50] <wgrant> Yup.
[04:50] <spm> ugh. pilinut is just as dirty
[04:51] <spm> any objections if I shutdown BB on pilinut and clear out the running rabbits
[04:51] <StevenK> Do eet
[04:51] <wgrant> No need to shut it down, but sure.
[04:51] <wgrant> No build, so shutting it down is fine.
[04:52] <spm> just to make it easy to clear out everything
[04:52] <wgrant> What, kill all processes owned by the user?
[04:52] <spm> yup
[04:52] <spm> well. more making sure I don't clobber the BB process itself hard.
[04:53] <StevenK> It deserves it, kill it anyway
[04:53] <spm> huh. there's 3 pgbouncers in there as well
[04:53] <spm> was
[04:53] <spm> pilinut cleaned; pigeonpea cleaned
[04:54]  * StevenK forces a devel builkd
[04:54] <StevenK> s/k//
[04:55] <wgrant> Thanks spm.
[04:55] <spm> np
[05:02] <StevenK> poolie: Your branch should be fine to land now
[05:02] <poolie> thanks
[05:07]  * StevenK sets lp-oops on fire.
[05:07] <StevenK> Perhaps SSO is to blame.
[05:07] <wgrant> StevenK: What's up?
[05:09] <StevenK> Forgetting the query string when logging in.
[05:09] <wgrant> That's apache-openid
[05:09] <wgrant> We should work around it by not using the query string.
[05:09] <wgrant> This isn't 1990 :)
[05:15] <jtv> wgrant: kindly refrain from ridiculing as ancient history a year that I used to look forward to as the wondrous future.
[05:16] <wgrant> Bah
[05:16] <wgrant> It predates me by a year, therefore it is ancient history :)
[05:16] <StevenK> Bwaha
[05:16] <jtv> Insolent whippersnapper.
[05:16] <jtv> This does illustrate why my quiz team lost that crucial point a few weeks back.
[05:16] <jtv> The question: name the four horsemen of the Apocalypse.
[05:17] <jtv> I shouted “Ronnie, Paul” etc. but whispered the real names to the teammate who was doing the writing.
[05:17] <jtv> He dutifully, but not altogether correctly, noted down:
[05:17] <jtv> Hunger
[05:17] <jtv> War
[05:17] <jtv> Dath
[05:17] <jtv> *Death
[05:18] <jtv> Insolence
[05:18] <jtv> I took him to task about it afterwards, after we'd lost by 1 point.  His defense: “I'm British.  To us, Insolence *is* a horseman of the apocalypse!”
[05:19]  * StevenK is trying to remember the four horsemen as according to Good Omens
[05:19] <jtv> Hunger, War, Pestilence, Death, and Ronnie who left before they became famous.
[05:21] <jtv> (Let's not give away the rest; there may be people here who haven't read it yet :)
[05:22] <StevenK> No, it's Pollution, since Pestilence retired in 1963 following the discovery of pencillin.
[05:24] <jtv> Damn you, Sir Alexander Fleming!
[05:25] <jtv> (Why do I remember the name?  Because the anniversary of his death was a few weeks ago, on quiz night.  It pays to look these things up.)
[05:28] <jtv> This just in: IPCC announces the floods in Thailand were caused by Global Warming, _not_ as a naïve reader would deduct from looking at the actual numbers, from the reservoirs failing to run off excess water throughout the rain season.
[05:29] <jtv> To understand these announcements better, replace “Science” with “God” and variants of “Climate Change” with “Satan.”
[05:30] <nigelb> I'm apparently expiring from 3 teams almost at the same time :/
[05:30] <nigelb> Yay launchpad spam
[05:30] <jtv> Shouldn't have joined them all in the same week.  :)
[05:31] <nigelb> Yeah, regrets.
[05:32] <jtv> Funny really: apparently team memberships expire, but when we wonder if untended membership _requests_ should expire, everyone's up in arms!
[05:33] <nigelb> heh.
[05:36] <nigelb> I want to change the lies in the expiry warning email.
[05:36] <nigelb> Or a way to say "Hey, I dont care, let me expire
[05:36] <nigelb> "
[05:37] <nigelb> If anyone else does it, I'll buy them a drink :)
[05:40] <jtv> nigelb: I must warn you about one subtlety in Launchpad, and one in the real world.
[05:40] <wgrant> jtv: Well, team memberships expire when the team admins want them too.
[05:41] <wgrant> s/too/to/
[05:41] <jtv> In Launchpad, where we say “person,” that person can also be a team.
[05:41] <jtv> And in the real world, champagne qualifies as a drink.
[05:41] <jtv> wgrant: that explains, thanks.
[05:42] <wgrant> We don't just expire them by default, so you can't use that as an argument for expiring requests :)
[05:42] <wgrant> by default
[05:45] <poolie> jtv, you're feisty today
[05:45] <jtv> hi poolie!
[05:52] <jtv> night StevenK
[05:56] <nigelb> jtv: hah.
[05:59] <jtv> nigelb: soooo… you just committed yourself to something that can be stretched to buying the entire team champagne.  On the bright side, that might make the search for a volunteer a little easier.  :)
[05:59]  * nigelb whistles
[06:30] <wgrant> Our tests are crap :(
[06:36] <spm> wgrant: so. write a test to test the crapness of our tests. problem solved. /me cross arms. nods.
[06:38] <wgrant> Also, bugtasks are the bane of my existence.
[06:54] <nigelb> wgrant: I'd argue its not bugtasks, but launchpad itself :P
[06:55] <wgrant> Nah, most Launchpad stuff is fixable without incredible migration costs.
[06:56] <wgrant> The existence of bugtasks is not.
[07:09] <poolie> ok, good night all
[07:09] <wgrant> Night poolie.
[08:17] <jtv> Reviewer needed for small & simple change!  https://code.launchpad.net/~jtv/launchpad/orderingcheck-unicode/+merge/80987
[08:18] <rvba> jtv: I can do it ;)
[08:18] <jtv> So you can!  Thanks.  :)
[08:19]  * rvba likes Unicode stuff; yummy.
[08:20] <stub> Spoken like a man with an umlaut
[08:30] <wgrant> Evening stub.
[08:31] <stub> Yo
[08:32] <jtv> Hi there stub — did you go back home?
[08:34] <jtv> Also, AFAIK Raphaël does not have an Umlaut; it's a different diacritical mark that happens to look the same (unless you're Hungarian I believe, in which case you use both for their respective purposes).
[08:34] <jtv> Ah: diaeresis, that's the word.
[08:34] <jtv> I think.
[08:35] <rvba> True, Umlaut != Diaeresis.
[08:36] <nigelb> All you pedantics :P
[08:36] <jtv> An Umlaut transforms one vowel into another (a bit like the vowel changes in English, actually); this one separates two consecutive vowels, to show that they are in separate syllables.
[08:37] <jtv> Nobody bothers with them now, but a few decades ago you'd still find the same mark in English: “coöperate”
[08:37] <jtv> (To show that it's co-op-er-ate, not coop-er-ate)
[08:38] <wgrant> stub: We ran into some slightly disturbing query speed issues yesterday. On qastaging, https://pastebin.canonical.com/55125/ takes <10ms to EXPLAIN ANALYZE, but 300-700ms to actually execute. On DF, it executes in <10ms too. It evaluates to [(1,)], so it's presumably not just terrible output formatting speed...
[08:38] <jtv> wgrant: too late.  I chased him off.
[08:38] <wgrant> Curses.
[08:38] <jtv> (This suggests he probably didn't go back home.  Smart choice.)
[08:38] <wgrant> Are you home?
[08:38] <jtv> No.
[08:39] <jtv> I'm making a trip there in a few hours, but don't want to sit around consuming scarce resources I'm not helping deliver.
[08:39] <jtv> Oh, done already eh?  Thanks rvba
[08:40] <rvba> np
[08:44] <nigelb> jtv: scarce resources?
[08:44] <jtv> Clean water, food, etc.
[08:45] <jtv> Even in areas that aren't affected, shops have found it difficult to keep stocks up.
[08:45] <nigelb> oh.
[08:50] <bigjools> morning
[08:51] <nigelb> Morning bigjools!
[08:52] <adeuring> good morning
[08:54] <jelmer> g'morning
[08:56] <lifeless> 'lo
[09:11] <lifeless>  4 / 1081  RootObject:+login
[10:28] <jelmer> hmm, this is odd. one of my pending builds has an estimated start and finish time in the past. is that possible?
[10:33] <jtv> Any reviewers out there?  I need to leave soon but I have a largish branch up for review: https://code.launchpad.net/~jtv/launchpad/bug-884649-branch-1/+merge/80988
[10:36] <bigjools> jtv: I'll take it
[10:36] <jtv> Thanks!
[10:40] <bigjools> jtv: why all the new tests?
[10:41] <jtv> bigjools: so we won't need to iterate through all the possibilities in the integration tests.
[10:41] <jtv> This is stuff that couldn't be tested in isolation before.
[10:41] <bigjools> ok
[10:43] <bigjools> jtv: approved
[10:45] <jtv> Thanks.  That was fast!
[11:34] <bigjools> can I bug someone for a review please? https://code.launchpad.net/~julian-edwards/launchpad/cancel-build-bug-173018-ui-part4/+merge/80997
[11:47] <jtv> bigjools: least I can do.
[11:49] <jtv> bigjools: I guess the “Cancel build” link takes you to a confirmation form (at +cancel)?
[11:52] <bigjools> jtv: correct
[11:53] <jtv> I swear I don't remember a thing about menu links.  I thought a link wouldn't show up in menu.links if its "enabled" condition said it was disabled.
[11:57] <bigjools> jtv: menu.links is just the list defined at the top of the class
[11:57] <jtv> Ah
[12:00] <jtv> bigjools: done
[12:00] <bigjools> thanks
[12:01] <jtv> I don't suppose python has a built-in equivalent to “lambda x: not x”?
[12:01] <jtv> Actually, no, that's not what I need.  What I need is partial application of operator.not_
[12:02] <jtv> Or something.
[12:02] <stub> __builtins__.not_ = lambda x: not x
[12:03] <jtv> I was hoping to combine it with an attrgetter: filter(negate(attrgetter('my_bool_attr')), my_list)
[12:03] <jtv> For some value of negater.
[12:04] <benji> jtv: operator.not_
[12:05] <jtv> The problem is combining it with the attrgetter.  :)
[12:05] <benji> ah; lambda is your friend
[12:05] <jtv> Or reduce maybe
[12:06] <jtv> No
[12:06] <jtv> So back to partial
[12:47] <gary_poster> hey stub.  We are getting a lot of activity on pgkillactive.py.  This may be old news; I was out last week and am consumed by interviewing.  But the logs are telling us stuff like this:
[12:47] <gary_poster> Killing lpnet127 (15802), 2011-11-01 11:20:17.341629+00:00, 2011-11-02 06:57:42.661591+00:00
[12:47] <gary_poster> Locks found:
[12:47] <gary_poster> relname, transactionid, mode, granted, current_query, query_start, age, procpid
[12:47] <gary_poster> It's on lpnet 127, 129 and 130.
[12:47] <gary_poster> Does that suggest an action item?  If so, has it already been taken?
[12:49] <stub> gary_poster: I spent last week in a small village 100km from the Laos border and am now encircled by flood waters. I know less than you :-)
[12:49] <gary_poster> stub, heh, ok
[12:49] <gary_poster> are things getting better or worse, stub?
[12:49] <gary_poster> for your physical environment I mean :-P
[12:50] <stub> gary_poster: I'm still dry, and if it floods in my area I'll be fine upstairs. Official news is crap though so hard to follow.
[12:50] <gary_poster> gotcha stub.  good luck.
[12:51] <wgrant> gary_poster: That was several hours ago?
[12:51] <wgrant> Yes.
[12:51] <gary_poster> wgrant, yes
[12:51] <wgrant> That was soybean wandering off into lala land.
[12:51] <wgrant> It was powerstabbed and recovered.
[12:51] <wgrant> We still don't really know what happened, but it wasn't an LP thing.
[12:52] <gary_poster> ok thanks wgrant
[13:01] <mrevell> Guten morgen alles.
[13:02] <nigelb> Bonjour mrevell
[13:02] <timrc> is the Launchpad web service going to get a 2.0 release for Precise?
[13:05] <deryck> Morning, all.
[13:05] <abentley> deryck: morning.
[13:11] <abentley> timrc: I'm not aware of any plans to do another stable API.  However, the devel API is improving over time.
[13:18] <timrc> abentley, okay... I wasn't sure what LTS would mean (if anything) to the web service
[13:20] <abentley> timrc: you might want to ask lifeless for his thoughts.  He's usually around in 6-7 hours.  I have the impression that the devel service is much more popular than the 1.0 service, so stable versions may not be worth the extra effort they require.
[13:27] <Ursinha> bug 879589
[13:27] <Ursinha> where's the bot
[13:28]  * nigelb pokes _mup_ 
[13:33] <cjohnston> One of the blueprints for a session during UDS was deleted.. do any of the devs have the ability to figure out when it was deleted
[13:42] <jtv> cjohnston: I'm not too familiar with blueprints (that'd be sinzui) but I'm not sure we normally delete blueprints at all.
[13:43] <jtv> We have various statuses along the line of "obsolete" and "declined," and if that's what happened we may be able to learn more.
[13:43] <cjohnston> its 404'ed
[13:43] <cjohnston> we figured out the issue.. so its all good
[13:43] <mwhudson> cjohnston: it's probably been renamed
[13:43] <jtv> Ah.
[13:44] <cjohnston> that could be too
[13:44] <mwhudson> or retargeted
[13:44] <cjohnston> would it be possible to create some sort of forward for a while when they are retargeted?
[13:45] <mwhudson> if you don't mind changing launchpad, sure!
[13:45] <cjohnston> lol
[13:45] <nigelb> He already has patches
[13:45] <nigelb> ;)
[13:45] <cjohnston> ive already made changes
[13:45] <nigelb> 6 landings I think?
[13:45] <cjohnston> something like that
[13:46] <jtv> And yet none of them fixed your problem?  Patch harder!
[13:46] <jtv> Meanwhile, any reviewers for tiny tiny leetle branch?  https://code.launchpad.net/~jtv/launchpad/getBinariesForDomination-bulk/+merge/81020
[13:47] <cjohnston> yup.. its a branch
[13:53] <cjohnston> jtv / mwhudson.. for sprints (ie the current UDS) when a track lead is set as an approver.. do they get a notification and or a reminder about a  blueprint that needs to be approved
[13:54] <mwhudson> cjohnston: don't know, sorry
[13:54] <jtv> Same here.
[13:55] <cjohnston> anyone else know by chance?
[13:56] <nigelb> cjohnston: *cough* "Use the source, Like" *cough*
[13:56] <cjohnston> too much work
[13:57] <nigelb> Blueprints is probably the easiest to understand.
[14:01] <allenap> Does anyone know why I'd get a NotABranch error from merge-proposal-jobs.py in qastaging? https://lp-oops.canonical.com/?oopsid=OOPS-d39c8d786a4c80ed1f17e9943d2f51ae
[14:01] <allenap> s/NotABranch/NotBranchError/
[14:01] <rvba> jtv: I've reviewed your tiny tiny branch ;)
[14:01] <jtv> Thanks!
[14:02] <jtv> allenap: not scanned yet?
[14:04] <allenap> jtv: I pushed it yesterday, and revisions are appearing in the UI <https://code.qastaging.launchpad.net/~allenap/scriptify/test1>
[14:04] <jtv> Oh, wait.  This is qastaging.
[14:04] <jtv> Does it have its own codehosting server?
[14:04] <allenap> jtv: It's running on gandwana as bzrsyncd.
[14:05] <allenap> Which is the same host as used for staging.
[14:05] <jtv> So much for that then.
[14:06] <allenap> jtv: The error mentioned lp-internal:///~allenap/scriptify/test1... there's no mention of qastaging there, or is it, as it implied, a purely internal identifier.
[14:07] <nigelb> danhg: Do you know if the launchpad session will have audio?
[14:08] <allenap> $ bzr push lp://qastaging/~allenap/scriptify/test1 --use-existing-dir
[14:08] <allenap> bzr: ERROR: Server sent an unexpected error: ('error', 'NotBranchError', 'Not a branch: "lp-83227408:///+branch-id/360039".')
[14:11] <allenap> $ bzr push lp://qastaging/~allenap/scriptify/test1
[14:11] <allenap> This transport does not update the working tree of: bzr+ssh://bazaar.qastaging.launchpad.net/~allenap/scriptify/test1/. See 'bzr help working-trees' for more information.
[14:11] <allenap> Created new branch.
[14:11] <allenap> $ bzr push lp://qastaging/~allenap/scriptify/test1
[14:11] <allenap> No new revisions to push.
[14:11] <allenap> Now I can see a .bzr directory in the right place (with hitchhiker).
[14:13] <deryck> abentley, hey, shall we mumble a bit now?
[14:13] <abentley> deryck: sure
[14:13] <deryck> hi coffeedude
[14:13] <rvba> jtv: I was thinking about BPPH.binarypackagename but I'm not sure that's helpful for you.
[14:14] <jtv> rvba: not really — it's still one-by-one.
[14:14] <jtv> But I'm not too worried about it; I think it'll be a secondary issue at worst.
[14:14] <rvba> Okay.
[14:14] <jtv> Oh wait, _now_ I get what you mean!
[14:15] <coffeedude> hey deryck
[14:15] <jtv> The column that's been recently added to the table.  Has that been fully initialized yet?
[14:15] <rvba> jtv: exactly
[14:15] <jtv> Has initialization completed yet?
[14:15] <rvba> jtv: I think it has.
[14:15] <jtv> If so then yes, it would be useful!
[14:15] <jtv> Thanks for pointing that out.
[14:15] <rvba> Glad to help ;)
[14:16] <jtv> It means we can avoid loading the BPN anywhere.
[14:16] <jtv> Maybe even the BPR… worth thinking about.
[14:24] <cjohnston> jtv: fwiw, the answer is yes, they do get emails, but sometimes get lost in rules and what not
[14:25]  * jtv wishes software could go back to being stupid and predictable, and leave the interesting stuff to us meatbags
[14:25] <cjohnston> heh
[14:26] <mrevell> nigelb, What's your Skype id?
[14:26] <nigelb> mrevell: heh, I was kidding originally :)
[14:26] <nigelb> mrevell: nigelbabu
[14:34] <abentley> deryck: you changed the listing to be a wide listing, but to me it looks too wide now.  Too much space between bug title and bug heat, especially if maximized.  Can we revisit that?
[14:36] <deryck> abentley, I'm just following the mockups.  I think we need to raise it with huw and mrevell if we want to change it.  FWIW, I like it wide. :)
[14:36] <deryck> but then I don't have a huge monitor.
[14:37] <deryck> also, it seems quite bare now, but when there are a lot of fields, it will fill up.  So there will always be some tension here.
[14:37] <abentley> deryck: On my monitor, the space between the title and the heat is often as wide as the title itself.  That makes the listings hard to read, because there's not a strong visual connection.
[14:38] <deryck> abentley, yeah, I can understand that.
[14:38] <deryck> abentley, I wonder if heat should drop down to the second row and fall directly inline with everything else.
[14:39] <deryck> or else directly to the right of the title.
[14:39] <abentley> deryck: the mockups actually show the title's column being ~ the same width as the longest title, which was how I had it.
[14:41] <deryck> abentley, all the mockups I see have it flush with the sidebar too.  so it's not clear which was meant -- i.e. follow with the title, or follow to the sidebar.
[14:41] <deryck> mrevell, care to weigh in on the intent here ^^ ?
[14:42] <deryck> abentley, what does the side bar do on a large display if the listings are narrow?
[14:42] <deryck> if you recall.
[14:42] <abentley> deryck: I don't recall.
[14:42] <deryck> ok, np.
[14:43] <deryck> abentley, are you wanting to fix it yourself in a branch your working on, or just raising the issue?
[14:43] <abentley> deryck: just raising the issue.
[14:44] <abentley> deryck: while it's still fresh.
[14:44] <deryck> abentley, ok.  let's chat with mrevell and huw when they have more availability, and I'll play with some options in css to see what possibilities we have.  fair enough?
[14:44] <abentley> deryck: sounds good.
[14:45] <deryck> abentley, cool.  I added a Kanban misc card to remind me to follow up on it. :)
[14:45] <allenap> jtv, rvba: Fwiw, the problem was that the *trunk* branch of the scriptify project was not pushed. The NotBranchError I got when pushing the test1 branch referred to an attempt to find the default stacking branch.
[14:46] <jtv> ouch
[14:46] <jtv> Bug.
[14:46] <allenap> jtv: Indeed, but the good news is that long-polling for merge proposals works in staging and qastaging (restricted to ~launchpad for now).
[14:46] <allenap> rvba: ^
[14:47] <jtv> Nice!
[14:47] <nigelb> allenap: <3
[14:47] <nigelb> Will it be rolled to production for launchpad only at least? :)
[14:48] <nigelb> Oh wait. ~launchpad. Not ~launchpad-dev :(
[14:48] <allenap> nigelb: The LOSAs are going to figure out how to deploy the new service effectively (it's a bit of a cowboy right now) then, yes, it'll get rolled out :)
[14:48] <nigelb> \o/
[14:48] <allenap> nigelb: I think it'll be safe to make it available to ~launchpad-dev.
[14:49] <nigelb> Yay!
[14:49] <nigelb> mrevell: Thanks for skyping me in!
[14:49] <mrevell> nigelb, Pleasure!
[14:56] <abentley> deryck: css class "bugtitile" appears mispeled.
[14:56] <deryck> heh
[14:57] <deryck> I had to look a couple times to spot the typo.
[14:57] <deryck> that's how I pronounce it in my accent. ;)
[14:57] <deryck> tie-tile :)
[14:57] <deryck> abentley, I'll fix in my branch.  Thanks!
[14:58] <abentley> deryck: lol.  Cool.
[15:12] <allenap> nigelb: Merge proposal long-poll stuff is enabled for ~launchpad-dev in staging and qastaging.
[15:12] <nigelb> allenap: Thanks!
[15:14] <allenap> nigelb: No worries. Please break it :)
[15:15] <allenap> abentley: Up for a review? https://code.launchpad.net/~allenap/launchpad/participation-keyerror-bug-810114/+merge/81012
[15:15] <abentley> allenap: sure.
[15:15] <bigjools> allenap: It still says "reload to see changes", right?
[15:15] <allenap> bigjools: Yes, it does.
[15:15] <allenap> abentley: Thanks.
[15:16] <bigjools> mrevell: is there an LP session on?
[15:16] <abentley> allenap: module docstring is a placeholder.
[15:16] <mrevell> bigjools, Not right now.
[15:16] <mrevell> bigjools, We're doing a check-point, though.
[15:16] <bigjools> cool
[15:16] <allenap> abentley: Oops. I'll fix that, and all the functions too.
[15:17] <abentley> allenap: yeah, the functions have comments rather than docstrings.
[15:17] <deryck> abentley, so you think bugnumber CSS class should become bugid (or some such)?  Or do you think it doesn't matter for class names so much?
[15:17] <abentley> deryck: I think we should standardize everything on bugnumber.
[15:18] <deryck> abentley, ah, ok.  The class I use for sorting is sort-id because each of them get a "sort-X" class where X is the actual orderby phrase.
[15:18] <deryck> abentley, so we can't actually change that to bugnumber.  but otherwise we can standardize.
[15:19] <abentley> deryck: makes sense.
[15:19] <deryck> ok, cool.
[15:19] <bigjools> allenap: it isn't working for me on staging
[15:20] <allenap> PEBKAC probably ;)
[15:20] <allenap> bigjools: Whassup?
[15:21] <bigjools> allenap: hoho!  yellow box still there, if I reload in a new tab, it's not there, but neither is the diff
[15:21] <allenap> bigjools: Can you point me to the branch?
[15:21] <bigjools> allenap: https://code.staging.launchpad.net/~julian-edwards/txlongpollfixture/FIRST/+merge/76676
[15:21] <bigjools> I merged one that was already on staging
[15:22] <abentley> allenap: transaction.abort in check_teamparticipation_consistency worries me a bit, because it doesn't seem to guarantee that any pending DB writes got written.
[15:23] <allenap> abentley: There are no pending db writes, and there shouldn't be.
[15:23] <gnuoy> allenap, Not a branch
[15:23] <gnuoy> OOPS-21e6aba1bf48244072ebdc537396b722
[15:23] <abentley> allenap: A function doesn't know who its caller is.
[15:24] <abentley> allenap: I guess you can keep it if you document it.  Otherwise, I'd prefer a commit.
[15:25] <allenap> abentley: Fair. Okay, I can do a store.rollback(), or even a store.close().
[15:25] <allenap> abentley: Okay, commit is fine actually.
[15:25] <abentley> allenap: cool.
[15:26] <gnuoy> allenap, I think bigjools is hitting the same problem you were
[15:26] <allenap> bigjools, gnuoy: It's because lp:txlongpollfixture is not a branch; branch content is not synced during a refresh. I've pushed it now, so try again.
[15:26] <bigjools> ahhh
[15:26] <allenap> bigjools: gnuoy and I spent a long time figuring out that little gem earlier.
[15:27] <abentley> allenap: check_teamparticipation_consistency has a lot of inner functions.  Have you considered structuring it as a class?
[15:28] <abentley> allenap: well, maybe "a lot" is a bit strong.  Some.
[15:28] <allenap> abentley: Yes, but I think it would get longer and less readable, imo. I have considered splitting it into two - a slurping part and a checking part - but haven't done it yet. I am working on a follow-up so I might do it there.
[15:29] <allenap> abentley: Also, the slurped data will use about ~200MB of memory so it's quite useful that this will be reclaimed as soon as the function returns.
[15:30] <abentley> allenap: "len(out) > 0" might be clearer and faster as out != ""
[15:33] <allenap> abentley: Okay.
[15:35] <abentley> allenap: r=me with the docstring updates.
[15:35] <allenap> abentley: Thanks!
[15:37] <rvba> abentley: could you please have a look at this (tiny) MP? https://code.launchpad.net/~rvb/launchpad/branches-timeout-bug-827935-always-display/+merge/81022
[15:37] <gnuoy> nigelb, bigjools, I need to quickly restart txlongpoll in staging and qastaging
[15:37] <abentley> rvba: sure.
[15:37] <rvba> ta
[15:37] <bigjools> gnuoy: fine
[15:38] <nigelb> I'm not testing yet.
[15:38] <nigelb> UDS :)
[15:38] <abentley> rvba: r=me
[15:38] <rvba> abentley: Thank you!
[15:39] <abentley> rvba: np
[15:41] <gnuoy> nigelb, bigjools. thanks and done
[15:48] <deryck> abentley, for your change you had to revert, you landed display-cleanup, reverted in another branch, and then fixed inside display-cleanup and landed that same branch again....
[15:48] <deryck> abentley, is that right?
[15:49] <abentley> deryck: that's right.
[15:49] <deryck> abentley, the "fake merge" commit you had is needed to get in sync with devel after the revert?
[15:50] <abentley> deryck: right.
[15:50] <deryck> abentley, how exactly did you fake merge?
[15:51] <abentley> deryck: bzr merge devel; bzr revert .; bzr commit
[15:51] <deryck> ah ha.  right, that makes sense.
[15:51] <deryck> abentley, thanks!
[15:52] <abentley> "revert ." reverts all file changes, but keeps the merge marker.
[16:35] <deryck> abentley, hey.  sorry to keep pestering you....
[16:35] <abentley> deryck: no worries.  What's up?
[16:36] <deryck> abentley, you have your object like this:  var navigator = Y.lp.bugs.buglisting.ListingNavigator.from_page();
[16:36] <deryck> abentley, and I work from that when I create my OrderByBar.  I'm going to feature flag all of that, I think.
[16:36] <deryck> abentley, there's no need for the navigator to be outside the flag, right?
[16:38] <abentley> deryck: The only thing is testability.  It's easier to test how Navigator behaves when the flag is disabled than to test whether the page has no navigator when the flag is disabled.
[16:39] <abentley> deryck: But I guess it's not that hard to test either way.
[16:39] <deryck> ah
[16:39] <deryck> abentley, so if I change it, tests will break?
[16:40] <abentley> deryck: No, but you should delete the code they're testing and the tests themselves.
[16:42] <abentley> deryck: test_render_no_client_listing, test_from_page_no_client
[16:43] <deryck> abentley, I'm confused, sorry.  Why would I want to delete tests?  We don't want to lose that coverage, do we?
[16:44] <abentley> deryck: We should have only one strategy for dealing with the feature flag.  So if you change the strategy, you should delete the old code.  And that would make the tests fail.
[16:44] <deryck> abentley, ah, now I see what you mean.  Thanks.
[16:45] <abentley> deryck: np.
[17:18] <deryck> abentley, so this is the sort of thing, I'm thinking:  http://pastebin.ubuntu.com/726516/
[17:18] <deryck> abentley, just putting our scripts behind a flag.
[17:21] <deryck> abentley, and as far as I can tell has no impact on your current approach or testing, though I don't mind deleting the empty return and tests if you feel it's unneeded.
[17:22] <deryck> oh, lunch now, sorry.  chat more when I'm back.
[18:25] <deryck> abentley, did you see what I wrote in the scrollback?
[18:26] <abentley> deryck: I did.  I do feel deleting the empty return and the check in render makes sense, because your change makes it dead code, and dead code should be deleted.
[18:27] <deryck> abentley, fair enough.  I'll kill it then.
[18:27] <abentley> deryck: cool.
[18:33] <deryck> abentley, http://pastebin.ubuntu.com/726581/  cool?
[18:34] <abentley> deryck: You've missed the check in render:     "if (! Y.Lang.isValue(this.target)){"
[18:36] <deryck> abentley, updated then: http://pastebin.ubuntu.com/726584/  cool now?
[18:36] <abentley> deryck: yes, thanks.
[18:36] <deryck> abentley, np.
[18:46] <abentley> Our linter has spelling errors: "To few newlines before selectors."
[18:48] <jtv> abentley: it could be a toast.
[18:48] <jtv> Here's to few newlines before selectors!  <ting> <slurp>
[18:49] <abentley> jtv: Toasts are usually written as exclamations, so then it would be a grammar error :-)
[18:50] <jtv> abentley: toasts must be considered in the context of the number, size, and alcohol content of preceding drinks.
[18:51] <jtv> But I admit your interpretation has merit.
[19:08] <abentley> deryck: could you please merge r14231 or later into custom-bug-listings and push?  My branch has conflicts that it's inheriting from custom-bug-listings.
[19:09] <deryck> abentley, sure.  the css-polish branch?
[19:09] <abentley> deryck: right.
[19:09] <deryck> ok.
[19:17] <deryck> abentley, done.  push includes the recent fixes we discussed in the scrollback too.
[19:17] <abentley> deryck: cool, thanks.
[19:17] <deryck> np
[19:26] <abentley> deryck: test_update_from_model_caches is broken in custom-bug-listings-css-polish.  I belive this is because render no longer short-circuits when there's no target.
[19:30] <deryck> abentley, ah, that sucks.  I think I broke the build then.  I could have sworn this test passed locally.
[19:31] <deryck> abentley, so fix the test or put the short circuits back?
[19:32] <abentley> deryck: Yep.  I'd fix the test, since there's only one, and we're already creating a custom object for it.
[19:32] <deryck> abentley, ok, I'll work on a fix now.
[19:33] <abentley> deryck: no rush.
[19:33] <deryck> well, not until the build breaks :)
[20:01] <deryck> abentley, this gets it working for me:  http://pastebin.ubuntu.com/726648/.   Look sane?
[20:02] <abentley> deryck: yes.
[20:02] <deryck> abentley, excellent.  I'll put up an MP.
[20:19] <lifeless> wgrant: that field.blob - what OOPS id was it on
[20:19] <lifeless> wgrant: I want to track the emitter down
[20:27] <deryck> abentley, care to review that testfix?  https://code.launchpad.net/~deryck/launchpad/testfix-buglisting-js-test/+merge/81073
[20:28] <abentley> deryck: r=me
[20:28] <deryck> abentley, thanks!
[20:29] <lifeless> abentley: could I please have a review of https://code.launchpad.net/~lifeless/python-oops-tools/amqp-polish/+merge/81075 ? diff coming in a minute
[20:29] <abentley> lifeless: sure.
[20:30] <lifeless> also, its so nice working on a code base with <20sec test runs :P
[20:30] <lifeless> abentley: thanks!
[20:33] <abentley> lifeless: to me, ValueError is vague enough that I'd rather check the length.
[20:34] <lifeless> abentley: its pretty precise:
[20:34] <lifeless> >>> foo, bar = 1
[20:34] <lifeless> TypeError: 'int' object is not iterable
[20:34] <lifeless> >>> foo, bar = [1]
[20:34] <lifeless> ValueError: need more than 1 value to unpack
[20:34] <lifeless> >>> foo, bar = [1,2,3]
[20:34] <lifeless> ValueError: too many values to unpack
[20:34] <lifeless> abentley: if its not iterable, you get TypeError
[20:34] <lifeless> abentley: if it is but the wrong length you get ValueError
[20:35] <lifeless> abentley: we haven't seen any corruption of the third form
[20:35] <lifeless> abentley: and I plan to make this be an actual dict soon, which will eliminate the corruption entirely once the producers are upgraded
[20:36] <abentley> lifeless: Yes, but that's not the only way ValueError is used.
[20:36] <lifeless> abentley: thats true, but its the only way its used for the short expression given
[20:36] <lifeless> abentley: we know that req_vars is a basic datatype because its just been deserialised
[20:36] <lifeless> e.g. no special objects implementing their own __iter__
[20:37] <abentley> lifeless: let's not go overboard about this.  I said I'd rather check the length, didn't mean that you had to.
[20:37] <lifeless> abentley: sorry, didn't mean to get contentious
[20:38] <lifeless> I was just about to say I'll change it if you want, was merely explaining why I did it the way I did
[20:38] <abentley> lifeless: Is line 46 tested?
[20:38] <lifeless> nope
[20:39] <lifeless> its probably testable, though its a bit awkward
[20:39] <lifeless> its in the factory-function that reads from disk files
[20:40] <abentley> lifeless: I think since it fixes a bug, that we should test it.
[20:40] <lifeless> if I change one of the sample oopses to have a lower case id
[20:41] <lifeless> that will cause other test to fail if the line is not present
[20:41] <lifeless> I think this is the simplest way to ensure its presence is needed
[20:41] <lifeless> how does that sound?
[20:41] <abentley> lifeless: that sounds fine to me.
[20:41] <abentley> lifeless: So with testing, r=me.
[20:42] <lifeless> thank you
[20:42] <abentley> lifeless: np
[20:42] <lifeless> ok, I get failures with the line removed
[20:43] <lifeless> and not with it present
[20:43] <lifeless> heh, spoke to soon
[20:43] <lifeless> something else blew out :P
[20:45] <lifeless> abentley: \o/ other oopses already exercised that failure mode. So, I'll have a slightly longer diff for you, showing the impact.
[20:48] <lifeless> hah
[20:48] <lifeless> abentley: I misanalyzed the cause of our issues around that line.
[20:49] <lifeless> abentley: I'm going to drop it from the diff and do a different patch for that part of it
[20:49] <abentley> lifeless: Okay.
[20:49] <lifeless> src/oopstools/oops/views.py index() is the issue
[20:49] <lifeless> it treats oopses starting with OOPS specially, which is why the u1 lowercase oopses work and the LP lowercase ones didn't.
[20:50] <lifeless> abentley: I may end up including the line in the final fix, just want to decouple things to get more time to look at it.
[21:03] <deryck> Later on, everyone.
[21:36] <lifeless> abentley: https://code.launchpad.net/~lifeless/python-oops-tools/amqp-polish/+merge/81083 if you have time
[21:51] <lifeless> bac: thanks!
[21:51] <lifeless> bac: I was just about to start a branch to fix up my booboo
[21:52] <bac> lifeless: actually, i haven't gotten too far with it.  if you'd like to add some thoughts to the bug that might be helpful.
[21:52] <lifeless> bac: I just did
[21:52] <bac> lifeless: i did see that the report created has no 'type', at least when created via the tests.
[21:53] <lifeless> bac: tests for this need to be asynchronous tests
[21:53] <bac> not have a type entry causes the filters to explode
[21:53] <lifeless> bac: using the custom runner, and returning a deferred from the test to have that executed by twisted
[21:53] <lifeless> bac: that may be a separate defect (but worth addressing too) - changing from
[21:54] <lifeless> report['type'] to report.get('type', 'No exception type')
[21:54] <lifeless> report['value'] to report.get('value', 'No exception value')
[21:54] <lifeless> should do that
[21:54] <bac> lifeless: yep, i'd done something similar
[21:54] <lifeless> I think python-oops-twisted made that change; this is kindof code duplication, because its twisted code logging to to non-twisted logging module.
[21:55] <lifeless> (also made that change)
[22:02] <mrevell> hey huwshimi, got time to talk in the next 20 minutes? We need to try something new for the manage-disclosure mock-ups
[22:03] <mrevell> huwshimi, Good morning, btw :)
[22:03] <huwshimi> mrevell: Morning
[22:03] <huwshimi> mrevell: 2 mins
[22:03] <mrevell> huwshimi, I'll be popping offline but back shortly. No need to talk immediately.
[22:03] <mrevell> huwshimi, But I'd love to hijack your day... :)
[22:03] <huwshimi> mrevell: Now's fine with me
[22:04] <mrevell> huwshimi, Oh, I'm going onto another call just now. I'll ping you in an hour or so.
[22:04] <huwshimi> mrevell: Ah ok, no problems
[22:05] <lifeless> flacoste: anytime..
[22:11] <lifeless> abentley: actually, nevermind, there is a code hcange neeed; next reviewer up can cop it :)
[22:24] <poolie> hi huwshimi, lifeless
[22:24] <huwshimi> poolie: Morning
[23:15] <poolie> huwshimi: i replied about wrapping; we can talk about that later if you like
[23:15] <huwshimi> poolie: Sure
[23:15] <poolie> otp now
[23:27] <huwshimi> wallyworld_: Do you know anything about adding a security view to the +manage-disclosure page?
[23:28] <huwshimi> wallyworld_: Also, hello
[23:28] <wallyworld_> huwshimi: hi. i'm not exactly sure what any security view needs
[23:28] <wallyworld_> is this a user request?
[23:29] <lifeless> can I have a review of https://code.launchpad.net/~lifeless/python-oops-tools/amqp-polish/+merge/81083 please? its simple.
[23:29] <huwshimi> wallyworld_: No, from Matthew
[23:29] <wallyworld_> huwshimi: the accessibility of project artifacts is basedon policies
[23:29] <lifeless> huwshimi: what do you mean by security view?
[23:29] <lifeless> :)
[23:30] <wallyworld_> huwshimi:  security is orthogonal to that
[23:30] <wgrant> I assume it's the policy stuff that I discussed on the call this morning.
[23:30] <lifeless> huwshimi: as in, do you mean the red banner ?
[23:30] <huwshimi> lifeless: I have no clue, that's what I'd trying to find out :)
[23:30] <lifeless> wgrant: wallyworld_: I'm OCR today, so I need someone else :P
[23:31] <wgrant> lifeless: Looking.l
[23:31] <wallyworld_> huwshimi: i think we need to talk to matthew to clarify
[23:31] <lifeless> wgrant: thanks
[23:31] <wallyworld_> lifeless: sorry, was going to look after conversation finished
[23:31] <lifeless> wallyworld_: no worries
[23:31] <huwshimi> wallyworld_: Yeah that's fine, he's just away for a bit and I think he was hoping for some mockups today
[23:31] <lifeless> wgrant: my commit message and description are now stale.
[23:31] <lifeless>  Fixing
[23:32] <lifeless> Fixed.
[23:32] <wallyworld_> huwshimi: i think there's confusion/disconnect about policy based access and security etc
[23:32] <wallyworld_> huwshimi: so at some point i think we all need to get on a call to clarify
[23:32] <huwshimi> wallyworld_: Ah ok
[23:33] <wgrant> Might have to be late in our evening.
[23:33] <wgrant> Unless we catch Matt while he's at UDS.
[23:33] <wallyworld_> huwshimi: matthew is at uds? perhaps we can get together later today our time
[23:34] <huwshimi> wallyworld_, wgrant: He's gone out for dinner and I think he will try and call when he gets back
[23:34] <wgrant> Hopefully we can obtain a Curtis as well.
[23:34] <wallyworld_> huwshimi: ok. let's try and have a call then
[23:34] <wgrant> Otherwise I know mostly what's going on here.
[23:34] <huwshimi> wallyworld_: Great
[23:35] <wallyworld_> it would be good for curtis to be there so he can take what's discussed to folks at uds etc
[23:37] <lifeless> wgrant: got a thumbnail sketch for me ?
[23:37] <wgrant> lifeless: Of?
[23:37] <lifeless> 12:30 < wgrant> I assume it's the policy stuff that I discussed on the call this morning.
[23:38] <wgrant> lifeless: Pretty much what Curtis, you and I discussed a few weeks back.
[23:38] <wgrant> That others seem to be largely unaware of.
[23:38] <lifeless> wgrant: a little more context please
[23:40] <wgrant> lifeless: The policy-based disclosure approach, to avoid all the hideous security/apport special casing. Private artifacts have an associated policy, with observers for that policy, optionally specific to an artifact.
[23:40] <lifeless> righto
[23:40] <lifeless> do you mean db backed policies ?
[23:40] <wgrant> Yes.
[23:41] <lifeless> k, thanks
[23:41] <wgrant> Rather than the "security is magical lalalala" that was initially proposed.
[23:43] <lifeless> great, so distraction over you can go back to my review ;)
[23:43] <wgrant> Indeed.
[23:43] <lifeless> also I may have made oops lookup a brazillion times faster in some cases
[23:45] <wgrant> lifeless: + oopsids.add(with_oops.lower())
[23:45] <wgrant> lifeless: Isn't that going to lower the OOPS- too?
[23:45] <wgrant> Which is probably wrong.
[23:46] <lifeless> well, depends on where you consider the abstraction barrier
[23:46] <lifeless> but yes, I can see that being an issue.
[23:47] <lifeless> will make it a .update(map(lambda x:'OOPS-' + x, oopsids)) instead
[23:47] <wgrant> Thanks.
[23:53] <poolie> jelmer: http://twitter.com/#!/mumak/status/131875802630471680