[00:00] <wallyworld_> there's a lot of memcache errors
[00:02] <wgrant> Indeed.
[00:02] <wgrant> Fortunately the access logs are free of such silliness.
[00:03] <wgrant> The 9138 librarian.logs are a nice touch, though.
[00:03] <lifeless> wgrant: phew
[00:03] <lifeless> wallyworld_: ^
[00:03] <lifeless> thanks for lookig guys
[00:04] <wallyworld_> the chances would have been very small given no-one knew about the page anyway
[00:06] <lifeless> wallyworld_: yes. Sadly we have journos that follow us stealthily looking for things like this.
[00:06] <lifeless> journos and others, but the journos we eventually find out about ;)
[00:07] <wallyworld_> do they work for news corp or something?
[00:07] <wallyworld_> i suppose they tap our phones also
[00:08] <wgrant> Nah, they're too busy pirating Foxtel and Austar, aren't they? :)
[00:08] <lifeless> wallyworld_: I detect skepticsm.
[00:09] <lifeless> which is fine, I don't care if you're skeptical or not. Just as long as you *are* paranoid. :>
[00:09] <wallyworld_> lifeless: none intended. poor attempt at humour
[00:09] <lifeless> wallyworld_: kk
[00:14] <wgrant> http://morecss.org/
[00:14] <wallyworld_> wgrant: bug 933839. to me that means revoke all direct grants (pillar and artifact) for team members as well as the team. whereas what it does now is just revoke the team but leaves any member's direct access in place. agree?
[00:14] <_mup_> Bug #933839: Share nothing with a user or team <disclosure> <job> <Launchpad itself:Triaged> < https://launchpad.net/bugs/933839 >
[00:14] <wgrant> wallyworld_: Nobody knows how that UI looks, AFAIK
[00:15] <wgrant> It can't be implicit.
[00:15] <wgrant> I may have missed some mockups, though.
[00:15] <wallyworld_> wgrant: there would be a new radio button otpion
[00:15] <wallyworld_> atm there is "All" "Some" "Nothing" and there would be "Nothing (revoke team)"
[00:16] <wallyworld_> i'm just checking i understand the Nothing (revoke team) behavour
[00:16] <wgrant> All | Some | Nothing (except not really) | Nothing (yarly)?
[00:16] <wgrant> Right.
[00:17] <wgrant> It needs to remove explicit APGs and AAGs for the team, and any APGs or AAGs where the grantee participates in the team.
[00:17] <wgrant> This is pretty handy.
[00:17] <wallyworld_> yes, that matches my understanding
[00:17] <wgrant> 'cause it means that I, as a random outside observer, can get everyone's access revoked :)
[00:18] <wallyworld_> how? you need to be a project owner to do it
[00:18]  * wgrant creates a team and subscribes it to a project's private bug.
[00:19]  * wgrant quietly adds the project team to that team.
[00:19] <wgrant> $projectowner says "wtf is this team doing in my sharing view, you should have nothing"
[00:19] <wallyworld_> it would only be direct team members afaiui
[00:19] <wgrant> Project team no longer has any privileges :(
[00:20] <wallyworld_> so if it's only direct team members that wouldn't work
[00:20] <wgrant> But considering only direct team members puts it in conflict with literally everything else that deals with teams in Launchpad.
[00:21] <wallyworld_> perhaps, but it's the only sane way to do it
[00:21] <lifeless> Wait, why would it remove transitively?
[00:21] <wallyworld_> it wouldn't, that's what i'm saying
[00:22] <lifeless> rephrase, why would it remove more than the grants that mention that team|person directly ?
[00:22] <wgrant> lifeless: The design calls for a way to revoke a team's access and access held by any of the team's members/participants.
[00:22] <lifeless> why does it want to do that ?
[00:22] <wallyworld_> s/design/requirements
[00:22] <wgrant> I do not know.
[00:22] <lifeless> wallyworld_: can you point me at the LEP ?
[00:23] <wallyworld_> just a sec, i find it
[00:23] <lifeless> I suspect its an overgeneralisation from one of the oem scripts
[00:23] <wallyworld_> https://dev.launchpad.net/LEP/ManagingDisclosure
[00:24] <lifeless> so, Constraints and Requirements/must/4 is the thing
[00:24] <lifeless> its got some nuance in there
[00:24] <wgrant> It doesn't explicitly say that it requires this.
[00:25] <wallyworld_> the mockups and screenshots they were based on did
[00:25] <wgrant> It is the private team requirement, however.
[00:26] <lifeless> wgrant: sorry, where is that ?
[00:26] <wgrant> lifeless: Requirements/must/4 is the reason the private team expansion is done.
[00:27] <wgrant> It's probably also the reason transitive revocation is done, but it doesn't explicitly require that.
[00:27] <lifeless> wgrant: the private team expansion does not follow from 4 as I read it. Can you help me understand ?
[00:27] <wgrant> "If the user has access via a team, the view must explain how to remove either the user or the team to unshare. "
[00:28] <wallyworld_> i think item #1 explains why private team expansion is required
[00:28] <wgrant> That implies that there is a way to see the user who is only participating in sharing by being a member of a team.
[00:28] <wgrant> Ah, true.
[00:28] <wallyworld_> a project owner must see who has access
[00:28] <lifeless> wgrant: (4) - you can enter a userid and see their teams; this is quite different to expanding the teams.
[00:29] <wgrant> lifeless: The leakage implications are only vaguely dissimilar.
[00:29] <lifeless> wgrant: there is room to mitigate on one side, not on the other. I agree it has serious complications though.
[00:30] <wallyworld_> so i won't start this today - we can discuss tomorrow at the standup
[00:31] <lifeless> on (1), when I reviewed the LEP I read that as 'person', not as implying every concrete user.
[00:31] <wgrant> 1. A lists of all the users with all or some things shared.
[00:31] <wgrant> The view must also show exactly how the user has access, for example: directly or via a team
[00:31] <lifeless> quoting the LEP doesn't help much.
[00:32] <wgrant> That pretty clearly implies that it must be transitive.
[00:32] <lifeless> yes; its also a major problem
[00:32] <wgrant> Certainly.
[00:40] <wallyworld_> lifeless: wgrant: whenever the team has discussed this, we've said that if a private team is granted access to a project via a policy, they are putting themselves in a position where their info has a right to be known to the project owner/drivers and so long as they are warned....
[00:41] <wallyworld_> we've already done this for subscribing private teams to bugs for example in the current access model
[00:41] <wgrant> wallyworld_: The only previous disclosure was LimitedView
[00:42] <wgrant> This is effectively full View
[00:42] <wgrant> It's not warned about, and is in many cases far worse.
[00:42] <wallyworld_> not warned about yet
[00:42] <wgrant> And we need to remove bug-retargetting and multi-pillar bugs.
[00:42] <wallyworld_> and it's only to project owner/drivers
[00:42] <wgrant> The latter of which was vetoed.
[00:42] <wallyworld_> and as a project owner, i have a right not to have people spy on my project
[00:43] <wgrant> Right,.
[00:43] <lifeless> wallyworld_: you need to reconcile that with 'as a private team owner, I have a right not to disclosure the membership of my team'
[00:43] <wallyworld_> lifeless: well, if you want to see someone else's project, then you must be prepared to tell them who is lookiing
[00:44] <wallyworld_> so if a private team is granted access to *my* project, i have every right ti see who they are
[00:44] <lifeless> wallyworld_: thats true; but is it the team or the members that are looking ?
[00:44] <wallyworld_> both
[00:44] <wallyworld_> as a member of a team with access, i have access also
[00:45] <wallyworld_> if that's not acceptable, then don't subscribe your private team to a public project
[00:45] <wgrant> So
[00:46] <wgrant> That argument would potentially hold water if Launchpad wasn't crap.
[00:46] <wgrant> But, as I went into slightly with mpt earlier, bugs are too unowned for that to work.
[00:46] <wgrant> This whole thing would be far easier if Launchpad wasn't gratuitously different from every other bugtracker in history :(
[00:46] <lifeless> wallyworld_: that approach cuts both ways: if you don't trust the admins of ~private-team, don't grant access to ~private-team to your project.
[00:47] <wallyworld_> that's true
[00:47] <lifeless> wallyworld_: Mitigating both those risks results in a system where you get limited view in both directions :
[00:47] <lifeless>  - access grants grant reflexive limitedview on the team (and only that)
[00:47] <wallyworld_> sounds like there's slight disagreement here when we've already embarked on an approved design :-(
[00:48] <lifeless> if one wants to be sure that ~someteam is managed well, you can talk to its owner, which limitedview lets you see - and that has to be transitive (clearly)
[00:48] <lifeless> well, I say clearly; I think it is.
[00:49] <wallyworld_> i think so
[00:49] <lifeless> you can walk up until you get a person you know.
[01:39] <StevenK> wallyworld_: We missed one call in terms of the privacy banner, but I have that working.
[01:39] <wallyworld_> StevenK: excellent!
[01:40] <wallyworld_> StevenK: so you are now a yui guru :-)
[01:40] <StevenK> wallyworld_: One thing I can't work out is on initial page load, clicking the link the overlay doesn't have a value set, but if I choose a value and then click the link again, it does.
[01:41] <wallyworld_> StevenK: the current value needs to be passed into the choicesource constructor
[01:41] <wallyworld_> so check the value: xxxx bit
[01:41] <StevenK> wallyworld_: value: information_type.value,
[01:42] <wallyworld_> and you've logged that just to be sure it is correct?
[01:42] <StevenK> Not as yet ...
[01:43] <wallyworld_> take a quick look just to be sure
[01:44] <StevenK> information_type.value is undef. That would explain it.
[01:44] <wallyworld_> StevenK: the value should be USERDATA etc, not 2, 3, 4 etc
[01:45] <StevenK> And doing it again involves the same object and it keeps track of what was selected.
[01:47] <StevenK> wallyworld_: So I'm getting a hold of the element correctly, but how can I return what it is currently showing? .value was my guess, and it's obviously wrong.
[01:48] <wallyworld_> StevenK: you are trying to read the dom value that is not set yet
[01:48] <wallyworld_> you need to seed the initial value from the model
[01:48] <wallyworld_> ie the json request cache
[01:48] <StevenK> Ah.
[01:48] <StevenK> Back to the Python
[02:03] <StevenK> wallyworld_: You have it backwards. It needs to be 3, not EMBARGOEDSECURITY.
[02:04] <wallyworld_> StevenK: in the sharing table widget, it does need to be USERDATA etc. i guess we are using slightly different data models
[02:05] <StevenK> Now I'm happy enough with the JS.
[02:05] <StevenK> Now to stab Zope's form handling.
[02:05] <wallyworld_> it would be nice to be consistent though
[02:06] <lifeless> StevenK: is today auditor day?
[02:06] <StevenK> lifeless: I was still deciding if I was going to do something on it, what did you have in mind?
[02:07] <lifeless> just touching base to make sure you're not blocked
[02:07] <StevenK> Not blocked, just feeling that the light at the end of the tunnel is an oncoming train.
[02:13] <StevenK> wgrant: How can I debug why information_type doesn't show up in +filebug, assuming that I've ripped out security_related everywhere I saw it in the browser code.
[02:35] <StevenK> lifeless: "Overwhelmed" would be a nicer way to say it.
[02:36] <lifeless> StevenK: w.r.t. auditor ?
[02:38] <StevenK> lifeless: For both auditor and this disclosure work -- but the difference between the two is I have a clear direction, a clear goal and the steps in terms of the current disclosure work.
[02:39] <lifeless> StevenK: well, if you want those things for auditor, I'd be happy to help make them up.
[02:40] <StevenK> lifeless: I think that will help. :-)
[02:40] <lifeless> I'm available whenever you like to do that then.
[02:40] <StevenK> lifeless: After lunch?
[02:40] <lifeless> I don't know what that means, but sure :)
[02:41] <StevenK> lifeless: 12:40 here, I'll be having lunch for ~30 at 1pm.
[02:41] <StevenK> Read as 'in a little bit over an hour'
[02:42] <nigelb> lifeless doesn't have lunch? lunchless?
[02:42] <StevenK> Haha
[02:42] <StevenK> mealless
[02:43] <mwhudson> i bet lifeless can charge from usb
[02:43] <nigelb> haha
[02:43] <StevenK> I'm not sure I want to know where his charging indicator is.
[02:44] <nigelb> tmi
[02:49] <lifeless> StevenK: col
[02:49] <lifeless> *cool*
[03:27] <wgrant> wallyworld_, jcsackett: Bug #971241
[03:28] <_mup_> Bug #971241: Sharing details page breaks when an inaccessible bug is shown <disclosure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/971241 >
[03:29] <wallyworld_> hmm. one could argue that a pillar driver should be able to see bugs filed against it
[03:29] <wgrant> Most certainly not.
[03:29] <wgrant> Owner perhaps.
[03:29] <wgrant> But there is no justification for drivers to.
[03:30] <wallyworld_> why not drivers?
[03:30] <wgrant> (even owner is debatable)
[03:30] <wallyworld_> i don't agree owner should be debatable
[03:30] <wallyworld_> if i own a prject, i have a right to see what bugs are filed against it
[03:30] <wgrant> wallyworld_: Because being someone who manages blueprint priorities shouldn't permit me to see embargoed security bugs.
[03:31] <lifeless> wgrant: careful of cause and effect
[03:31] <wallyworld_> but what if that info is required to help manage the priorities
[03:31] <lifeless> wgrant: ITYM 'Being someone who manages blueprint priorities does not imply seeing embargoed security bugs.'
[03:31] <wgrant> lifeless: Perhaps.
[03:31] <lifeless> wallyworld_: then you will have the ability to see those bugs separately.
[03:31] <lifeless> wallyworld_: e.g. via a grant to see them.
[03:32] <wgrant> Now, the owner can always grant themselves access. But I think having the separation is useful for large projects.
[03:32] <lifeless> wallyworld_: our job is to provide solid primitives that let folk drive the system.
[03:32] <wallyworld_> so the sharing details page should just filter out bugs without view access i guess
[03:32] <lifeless> (vs preconcluding particular detailed answers). We're writing a fine grained rules toolkit here.
[03:32] <wgrant> wallyworld_: It probably needs to say that they exist.
[03:33] <wgrant> But it can't say what they are.
[03:33] <lifeless> it sounds like a case of limitedview
[03:33] <wgrant> LimitedView considered harmful.
[03:33] <lifeless> same as duplicate-on-private; see the thing exists but no details.
[03:33] <wgrant> Indeed.
[03:33] <lifeless> why do you say limitedview considered harmful ?
[03:33] <wallyworld_> i'm not familiar with the implementation details of the sharing details page as i didn't write it, i'd have to look
[03:34] <wgrant> lifeless: Well
[03:34] <wgrant> lifeless: In a lot of cases it's difficult to do sensibly.
[03:35] <wgrant> In some cases it works well.
[03:35] <wgrant> But it's not the answer to everything :)
[03:35] <wgrant> Anyway.
[03:36] <wgrant> Drivers seeing them unconditionally is not open for debate. They must not.
[03:36] <wgrant> Owners I suspect can't always see them either, but that is more arguable.
[03:37] <wgrant> (eg. it's much easier to audit leaks if the owner has to explicitly add themselves in a logged fashion before they can see the embargoed security stuff)
[03:38] <wallyworld_> i feel sorry for drivers trying to managing priorities in the absence of all required information eg there could be a really important embargoed security bug filed they don't even know about
[03:38] <wallyworld_> i guess if the had limited view and knew the bug number they could ask
[03:40] <lifeless> what does the 'sharing details page' do ?
[03:40] <wallyworld_> show the artifacts (bugs and branches) a person can see
[03:40] <wallyworld_> for a pillar
[03:40] <wgrant> lifeless: https://qastaging.launchpad.net/launchpad/+sharingdetails/wgrant
[03:40] <lifeless> k
[03:41] <wgrant> wallyworld_: The Ubuntu drivers are not privy to the security bugs.
[03:41] <wgrant> wallyworld_: The security team manages the security bugs.
[03:41] <wgrant> From end to end.
[03:41] <wallyworld_> ok
[03:42] <lifeless> wallyworld_: so remember the user story: for proprietary projects (the focus), drivers could be either a) granted access to all proprietary bugs or b) granted access to all proprietary+security bugs
[03:42] <lifeless> wallyworld_: thats a project policy decision, not ours.
[03:42] <wallyworld_> true
[03:42] <lifeless> wallyworld_: in this case, given that anyone can check +sharingdetails, the first iteration probably should just elide inaccessible bugs.
[03:43] <lifeless> wallyworld_: (which it would have by default if the stock bug access query constraints were used)
[03:43] <wallyworld_> and branches
[03:43] <lifeless> indeed
[03:43] <wallyworld_> lifeless: it wouldn't use the stock bug access queries because it would be done of the flattened table
[03:43] <wallyworld_> off
[03:43] <lifeless> we can look at adding limitedview onto this in the future, but it will run into the same complexity-performance things we have today.
[03:44] <wgrant> wallyworld_: I would use the same queries.
[03:44] <wgrant> s/I/It/
[03:44] <wgrant> Just with an additional constraint to say "wgrant has access"
[03:45] <wallyworld_> looking at the code, it uses findArtifactsByGrantee
[03:45] <wgrant> Sure
[03:46] <wallyworld_> so right now it queries directly off the flattened table
[03:46] <wgrant> From that it could grab a list of bug IDs
[03:46] <wgrant> And feed them into bug search.
[03:46] <wallyworld_> agreed, just saying what it dies now
[03:52]  * wallyworld_ has to go and get a haircut
[03:57] <StevenK> lifeless: Skynet?
[04:08] <StevenK> wgrant: Did you miss my earlier question?
[04:09] <wgrant> StevenK: Indeed. Do you have a branch?
[04:09] <StevenK> wgrant: Locally. I can paste a diff, but it's 4 files changed, 103 insertions(+), 284 deletions(-)
[04:10] <wgrant> diffme
[04:10] <lifeless> StevenK: yup
[04:11] <StevenK> wgrant: http://pastebin.ubuntu.com/911045/
[04:12] <wgrant> StevenK: That's quite the obese diff you have there.
[04:12] <StevenK> I told you!
[04:12] <wgrant> Also, --syntax=diff :)
[04:12] <lifeless> StevenK: waiting for you to come online
[04:13] <StevenK> lifeless: I have been for the last ten minutes.
[04:13] <lifeless> StevenK: bah
[04:13] <StevenK> In fact, I was starting Skype when I queried you with Skynet
[04:13] <lifeless> skype fail fail fail
[04:13] <lifeless> pkill -9 skype
[04:13] <StevenK> lifeless: Book a flight to Sydney? It might be quicker and simpler.
[04:14] <lifeless> foad
[04:14] <lifeless> though I may come over mid april
[04:14] <nigelb> StevenK: heh
[04:14] <wgrant> StevenK: What does not working?
[04:14] <wgrant> I see the field fine.
[04:15] <StevenK> wgrant: The information type doesn't show up in Bug:+filebug
[04:15] <wgrant> Oh
[04:15] <wgrant> On filebug
[04:15] <wgrant> I see
[04:19] <wgrant> StevenK: Works better when the template doesn't refer to security_realted
[04:19] <wgrant> security_related
[04:20] <StevenK> wgrant: Which template? I didn't see that.
[04:20] <wgrant> StevenK: The filebug template? :)
[04:20] <wgrant> lib/lp/bugs/templates/bugtarget-filebug-guidelines.pt
[04:21] <StevenK> Right. I was looking at the filebug.pt I think.
[04:21] <bigjools> wallyworld_: which hair?
[04:22] <wgrant> StevenK: Also, numeric enum values have no place outside the DB access layer.
[04:22] <wgrant> But it looks like you might be using one here in the JS.
[04:22] <wgrant> Hard to tell.
[04:22] <StevenK> wgrant: Where am I using them?
[04:22] <wgrant> +            var information_type_by_value = {};
[04:22] <wgrant> But it seems to be by name, not value.
[04:22] <wgrant> So it's just a lie, and not wrong.
[04:22]  * jtv hopes wgrant's mother didn't hear that
[04:23] <jtv> lifeless: I just ran into a funny one with oopstools' date-dir repo.  Hope I filed it in the right place: bug 971255
[04:23] <_mup_> Bug #971255: Crash in _findHighestSerialFilename <Python OOPS Date-dir repository:New> < https://launchpad.net/bugs/971255 >
[04:23] <StevenK> wgrant: I get the number back, I need to map it back.
[04:23] <wgrant> StevenK: Whatever is returning the number is a horrible person.
[04:23] <wgrant> And a bug.
[04:23] <lifeless> jtv: thats probably the right place, though that method indicates you're using the old naming scheme which is awful
[04:24] <jtv> lifeless: I don't think we made a conscious choice to do that — isn't this the default?
[04:26] <jtv> lifeless: also, we happen to have other log files in the directory.  Their names happen to have dots in them, but not something to rely on.
[04:31] <lifeless> jtv: I've commented on the bug; happy to discuss more here, or there, or both as appropriate.
[04:31] <jtv> lifeless: thanks for the fast response.  I just summarized your message on there as well.
[04:32] <jtv> lifeless: where do I find out how we constrain our repository object?
[04:32] <jtv> Sorry, constrict.
[04:32] <jtv> No idea what it means actually.  :)
[04:38] <lifeless> construct
[04:38] <lifeless> jtv: ^ sorry, ELOCAL for a minute there
[04:38] <jtv> Sure.
[04:38]  * wgrant shreds BeautifulSoup
[04:38] <jtv> lifeless: We pass it an error dir and an instance id.
[04:39] <lifeless> don't pass an instance id
[04:39] <lifeless> pydoc oops_datedir_repo -
[04:39] <lifeless>      |      :param instance_id: If None, OOPS file names are named after the OOPS
[04:39] <lifeless>      |          id which is generated by hashing the serialized OOPS (without the
[04:39] <lifeless>      |          id field). Otherwise OOPS file names and ids are created by
[04:39] <lifeless>      |          allocating file names through a UniqueFileAllocator.
[04:39] <lifeless>      |          UniqueFileAllocator has significant performance and concurrency
[04:39] <lifeless>      |          limits and hash based naming is recommended.
[04:39] <lifeless> (easier to have it here to reference)
[04:40] <wgrant> jelmer: Can bug #296153 be closed now?
[04:40] <_mup_> Bug #296153: does not mirror bzr branches over ftp <lp-code> <qa-ok> <Launchpad itself:Fix Committed by jelmer> < https://launchpad.net/bugs/296153 >
[04:40] <jtv> lifeless: thanks!  I guess they'll still have timings in them to order them by time?
[04:41] <lifeless> jtv: if you have the default hooks installed there is a timestamper in there,yes.
[04:41] <jtv> Is there anything I need to do to make sure we have the default hooks installed?
[04:41] <wgrant> (the filenames don't, though)
[04:42] <lifeless> jtv: I urge you to make an oops/ subdir or something though, because oops isn't designed to have other stuff in the repository, and you may well encounter other bugs like this. The robustness that is there is to deal with oops-managed temporary files, for instance.
[04:42] <jtv> I see.  Oh well.  Thanks for the quick help!
[04:43] <lifeless> jtv: (defaulthooks) - they are default :) You have to take action to remove them.
[04:43] <jtv> OK
[04:43] <jtv> Laziness is the most reliable safety mechanism.
[04:44] <lifeless> jtv: so based on this, I'm going to close the bug (or do you want to retarget it to maas)?
[04:45] <jtv> Wait — it still shouldn't crash just because we passed a non-recommended option, right?
[04:45] <lifeless> the only way it can get crud like this in place is if you combine its own storage area with other content
[04:46] <lifeless> its not designed to do that, adding code to handle it would just be cruft, unless we want to design it to handle htat.
[04:46] <jtv> But the problem content was generated by the datedir repo.  The other crud was incidental.
[04:47] <lifeless> jtv: 'directory' in that call should be a date-named subdirectory
[04:47] <lifeless> jtv: not the explicit path you passed in.
[04:47] <jtv> I wonder why it wasn't.
[04:47] <jtv> Oh wait, it was!
[04:47] <jtv> So it was purely the datedir repo that broke itself.
[04:47] <lifeless> jtv: one possibility is that you're constructing a datedirepository without an instance id somewhere else
[04:48] <lifeless> (perhaps an earlier version on your own machine)
[04:48] <lifeless> that would write oopses with hashed names
[04:48] <lifeless> (but in the subdirectory)
[04:48] <jtv> Yup!  Found it.
[04:48] <lifeless> jtv: whats the actual name it is choking on ?
[04:48] <lifeless> jtv: again though, this isn't a supported config, I don't see value in trying to handle it
[04:48] <jtv> I don't know what name it was choking on… give me a minute to set things up for breaking again.
[04:49] <lifeless> okidoki
[04:49] <jtv> We only found out that this was not a supported config by asking you.
[04:50] <lifeless> if it is an interaction between the deprecated naming system and the new, that can be fixed I think by deleting the old style logic
[04:50] <lifeless> we shouldn't need it anywhere now, it was purely for migrationary purposes.
[04:51] <lifeless> and this bug would indeed be evidence that we need to do that.
[04:53] <jtv> Missed a step.  Back to step 1.  :/
[05:00] <StevenK> wgrant: Right, that sorted that out. But the default is "(no value)" rather than Public.
[05:01] <wgrant> StevenK: Indeed, you'll need to change the default.
[05:01] <wgrant> And ensure that the interface forbids None.
[05:01] <StevenK>     information_type = EnumCol(
[05:01] <StevenK>         enum=InformationType, notNull=True, default=InformationType.PUBLIC)
[05:02] <wgrant> That's no interface, that's a column.
[05:03] <StevenK> Doh
[05:04] <jtv> lifeless: gah.  Can't reproduce.  I have no way of telling what file was breaking it earlier.
[05:04] <jtv> Ah no, maybe I need to start pserv.
[05:11] <jtv> lifeless: having trouble reproducing the problem, because pserv seems to disappear every time I start it.  This needs more investigation.  But what may be happening is that one process (which constructs its datedir repo without an instance id) oopses out and then another tries to log an oops to a repo on the same directory but with an instance id.
[05:17] <lifeless>  yes, that would make sense to me
[05:17] <lifeless> I think we should remove the old code at this point
[05:17] <lifeless> the only reason to keep it was un-upgraded analysis consoles
[05:17] <lifeless> of which there are none that will be migrating to the new codebase now; (u1 are upgraded, isd are experimenting with sentry)
[05:17] <jtv> Meanwhile, I don't think the filenames are timestamped.  :-(
[05:18] <lifeless> jtv: the metadata is inside it
[05:18] <lifeless> jtv: you can also capture the oopses directly, either by subscribing to them via rabbit, or using a test specific publisher.
[05:18] <lifeless> jtv: (depending on your test environment)
[05:19] <jtv> My rabbit wasn't running earlier.
[05:19] <lifeless> (and you may not have a rabbit publisher setup either, but you can do so pretty easily)
[05:20] <lifeless> there is a rabbit-oops-fixture in the LP code base that can probably be pulled into oops-amqp (with an optional dep on fixtures)
[05:20] <jtv> What kind of usage would I get out of catching them that way?
[05:20] <lifeless> you avoid the ten sorts of mess that happen by going and looking on disk after the fact
[05:20] <jtv> For now I think it'd be good to minimize rabbit dependencies, given the recurring shutdown problems.
[05:21] <lifeless> I have to go cook
[05:21] <jtv> Don't let me stop you; I know what to fix.  Thanks again.
[05:22] <lifeless> but if you want a minimal replacement, you can use repo.republish() to pickup all the oopses that are in a datedir repository and throw them at another publisher
[05:22] <lifeless> so
[05:22] <lifeless> make a new repo object
[05:22] <lifeless> oopses = []
[05:22] <lifeless> repo.publishers.append(oopses.append)
[05:22] <lifeless> repo.republish()
[05:23] <lifeless> # make assertions about the oopses in 'oopses' here
[05:23]  * lifeless will be back later
[05:59] <wgrant> wallyworld_, StevenK: https://code.launchpad.net/~wgrant/launchpad/wbr-is-void/+merge/100357 is pretty simple if someone has a sec.
[06:00] <wallyworld_> i can look
[06:04] <wallyworld_> wgrant: i always thought it was simply <wbr>
[06:04] <wgrant> wallyworld_: In HTML, yes.
[06:04] <wgrant> wallyworld_: But that's not well-formed XML, and lots of people parse us as XML.
[06:05] <wgrant> <wbr /> is well-formed XML, XHTML and HTML5.
[06:05] <wgrant> And it's valid HTML5 and XHTML5.
 is only well-formed XML and XHTML, not well-formed HTML, and not valid in any of them.
[06:06] <StevenK> wgrant: Except that BeautifulSoup doesn't think so?
[06:06] <wallyworld_> ok
[06:06] <wgrant> Yeah, BeautifulSoup has an outdated hardcoded list of void elements.
[06:06] <wallyworld_> so do any tests fail that use BeautifulSoup?
[06:06] <wgrant> Every other element it assumes the end tag is missing if it's self-closing.
[06:07] <wgrant> wallyworld_: Just the one. I replace it with <wbr></wbr> before passing it into BeautifulSoup.
[06:07] <wgrant> Search for BeautifulSoup to find the test.
[06:07] <lifeless> that seems like an odd behaviour
[06:07] <wallyworld_> wgrant: can you please add an XXX then
[06:07] <wgrant> lifeless: It's designed to deal with tag soup.
[06:08] <wgrant> lifeless: So it's sort of justified.
[06:08] <wgrant> If a non-void element doesn't have an end tag, it should probably assume the end tag is just missing.
[06:08] <StevenK> wallyworld_: It isn't really an XXX.
[06:08] <wgrant> StevenK: It is.
[06:08] <lifeless> wgrant: <foo /> ... </foo> - where would that ever make sense ?
[06:09] <wgrant> lifeless: I don't think HTML knows about <foo />
[06:09] <wgrant> Does it?
[06:09] <wgrant> I'm pretty sure that's just an XML thing.
[06:10] <wgrant> Regularly used in HTML to make a polyglot document.
[06:10] <wallyworld_> wgrant: is the space before the /> required? my eyes prefer <wbr/>
[06:10] <wgrant> But only on void elements, because otherwise the parser cries.
[06:10] <lifeless> wgrant: it does for foreign elements
[06:10] <lifeless> http://www.w3.org/TR/html5/syntax.html
[06:10] <wgrant> lifeless: That's for HTML5.
[06:10] <wgrant> Which is a bit more sensible.
[06:11] <wgrant> But let's see.
[06:11] <wgrant> wgrant@lplucid:~/launchpad/lp-branches/wbr-is-void$ bzr grep '[^ ]/>' | wc -l
[06:11] <wgrant> 10623
[06:11] <wgrant> wgrant@lplucid:~/launchpad/lp-branches/wbr-is-void$ bzr grep ' />' | wc -l
[06:11] <wgrant> 11095
[06:11] <wgrant> wallyworld_: ^^ I win
[06:11] <wgrant> (either is OK)
[06:11] <wallyworld_> hmmm.
[06:11] <wgrant> (but mine is perferred by almost 5%! incontrovertible evidence that mine is superior)
[06:12] <wgrant> lifeless: Ah
[06:12] <wgrant> lifeless: Foreign elements are MathML and SVG (ie. XML formats forced against their will into an HTML document), so don't apply here.
[06:12] <lifeless> wgrant: also in html 5 <wbr/> isn't ok; but the parser-recovery rules handle it
[06:13] <wgrant> lifeless: The validator is fine with it. Are you sure it doesn't parse it as an invalid valueless attribute and ignore it?
[06:14] <lifeless> wgrant: which validator ?
[06:14] <wgrant> lifeless: validator.w3c.org in HTML5 mode.
[06:14] <wgrant> Which is still somewhat experimental, but still.
[06:14] <wgrant> "Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/). This character has no effect on void elements, but on foreign elements it marks the start tag as self-closing."
[06:15] <wgrant> So /> is valid in HTML5
[06:15] <lifeless> ah, void is special cased
[06:15] <wgrant> Yep
[06:15] <wgrant> Confusing enough.
[06:15] <lifeless> so this comes back to beautifulsoup - it *should* special case voids
[06:15] <lifeless> and all others should have end tags
[06:15] <wgrant> No, old SGML-subset HTML should die already,.
[06:16] <wgrant> Everybody should just use XML because XML doesn't suck as much.
[06:16] <lifeless> the validator is special casing voids
[06:16] <wgrant> Yeah
[06:16] <lifeless> other self closed elements will generate 'Self-closing syntax (/>) used on a non-void HTML element. Ignoring the slash and treating as a start tag.' from the validator
[06:16] <StevenK> lifeless: It does special case voids: [16:06] < wgrant> Yeah, BeautifulSoup has an outdated hardcoded list of void elements.
[06:16] <wgrant> But the relevant BeautifulSoup is the embedded one in mechanize or zope.testbrowser (not to be confused with the other embedded BeautifulSoups in our tree), so I didn't really want to mutilate it.
[06:16] <lifeless> StevenK: I know it *does*, the question was *should it*
[06:17] <StevenK> And then you said it should. And it does.
[06:17] <wgrant> I see no problem with that.
[06:17] <lifeless> StevenK: and the answer is, a) yes it should and b) the standard says to ignore the self-closing and look for an end tag.
[06:17] <wgrant> We were arguing the correctness.
[06:17] <wgrant> It is correct.
[06:17] <lifeless> and its fallback is correct as well, which was the bit I started querying.
[06:18] <lifeless> so I've cleared up a bit of fuzz in my head, which is good, and we know that the right fix is updating the void list in bs
[06:18] <wgrant> Yeah
[06:18] <lifeless> http://tiffanybbrown.com/2011/03/23/html5-does-not-allow-self-closing-tags/ is a cite for this btw
[06:18] <wgrant> HTML5 seems to have that exception just to cope with this sort of case.
[06:20] <wgrant> I wish WHATWG had just disregarded IE, specced out XHTML5, and left HTML4.01 as the last horror. :/
[06:22] <wgrant> I guess in 2015 people can start using XHTML :)
[06:22] <wgrant> 15 YEARS LATER
[06:22] <wgrant> wallyworld_: Thanks.
[06:22] <wallyworld_> np
[06:24] <lifeless> didn't you hear, browsers are agile now.
[06:25] <wgrant> Anyway
[06:25] <wgrant> This is the last large-scale validity issue. :)
[06:25] <StevenK> lifeless: Except for Safari and IE.
[06:26] <wgrant> Safari's not that terrible.
[06:26] <StevenK> And who knows what the truck Opera are doing.
[06:26] <wgrant> Opera is fine.
[06:26] <wgrant> Better than Safari, even.
[06:26] <StevenK> I was conflating agile with 'make a release every two days' purely to troll.
[06:27] <StevenK> What are they at now, Chrome 25.2?
[06:34]  * micahg just uploaded Chromium 18.0.1025.142
[06:43] <lifeless> using 4 numtets is cheating
[06:44] <bigjools> I've lost track of where to download a stable one these days
[06:45] <lifeless> didn't you hear, they are all stable :>
[06:46] <nigelb> surely, you mean unstable :)
[06:50] <micahg> bigjools: we've been pretty good about pushing stable versions out save for the last two
[06:51] <bigjools> micahg: pushing where? :)
[06:51] <micahg> to the archive
[06:51] <bigjools> nice one
[06:51] <micahg> 18 should be in -proposed later today
[07:20] <wgrant> StevenK, wallyworld_: If you're still around, could you look at https://code.launchpad.net/~wgrant/launchpad/bugtaskflat-garbo/+merge/100363?
[07:46] <StevenK> wgrant: r=me
[07:55] <wgrant> StevenK: Thanks.
[07:59] <czajkowski> aloha
[08:04] <adeuring> good morning
[10:49] <cjwatson> I'm working on API extensions to make it possible to turn queue into a launchpadlib script.  The wart is overriding individual binaries in a queue entry; PackageUpload currently only has an overrideBinaries method which overrides all of them, and queue traverses through queue_item.builds[i].build.binarypackages[j].override() to override individual binaries.  Would it be better to add an overrideBinary method to ...
[10:49] <cjwatson> ... PackageUpload that would allow overriding one at a time, or to expose all the objects down to BPR.override and expect clients to traverse that directly?
[10:50] <cjwatson> Hmm, even just writing that I think I might have convinced myself that a new PackageUpload.overrideBinary method would be better than all that object traversal ...
[10:52] <wgrant> cjwatson: I'd expose overrideBinaries({name: overrides, ...})x
[10:53] <wgrant> cjwatson: With the slight awkwardness that there are multiple overrides, but I guess that could be a dict.
[10:54] <cjwatson> Hmm.  The client would be pretty unmanageable if the overrides were all different.  How about I just allow passing in a list of names?
[10:54] <cjwatson> (I'll also need to expose something on PackageUpload that lets you get the list of binarypackagenames in a build upload.
[10:54] <cjwatson> )
[10:54] <cjwatson> The interface I'm trying to replace is typically used as something like "queue override -c universe binary foo bar baz"
[10:56] <wgrant> That would work too, but I'm trying to minimise the number of requests.
[10:56] <wgrant> Although I guess RTT for you isn't too bad :)
[10:56] <wgrant> From here, every request counts.
[10:59] <cjwatson> I think in practice hardly anyone would use it as -c universe binary foo bar baz -x editors blah spong, and the CLI looks distinctly unwieldy at that point
[11:00] <wgrant> Yeah
[11:00] <cjwatson> Even that example is ambiguous and if you start trying to make it unambiguous you end up with something like find(1) :-)
[11:00] <cjwatson> You're right that there's clearly no need for YA method though.
[11:00] <wgrant> Launchpad unwieldy and ambiguous? Surely you jest.
[11:01] <cjwatson> Call me a fool for aspiring to something higher :-)
[11:01] <wgrant> So, yeah, overrideBinaries([bpn], component?, section?, priority?) sounds reasonable.
[11:01] <cjwatson> Right.
[11:02] <cjwatson> Let me see what I can do, then.  (This is sort of back-burner for me but I'm trying to get stuff done before I get redirected to something else.)
[11:02] <wgrant> It's pretty simple :)
[11:03] <cjwatson> I've got the source override API working already.
[11:03] <wgrant> Great.
[11:03] <wgrant> What about permissions?
[11:04] <cjwatson> Controlled by queue-admin ArchivePermissions.
[11:04] <wgrant> Excellent.
[11:04] <cjwatson> If you're overriding between two components you need queue admin on both.
[11:04] <wgrant> Perfect.
[11:04] <cjwatson> Most of that was there already for the web UI.
[11:05] <wgrant> Yeah, but pretty much every large export of Soyuz stuff in the past has had obvious gaping holes.
[11:05] <wgrant> So this would be a nice first.
[11:05] <cjwatson> My tests are mostly about permissions at the moment.
[11:06] <wgrant> :)
[11:17] <wgrant> Oh good
[11:17] <wgrant> This is marvellous.
[11:17] <wgrant> Truly marvellous.
[11:17] <wgrant> It seems that feeds are produced using BeautifulSoup
[11:17] <wgrant> whhhhhy
[11:18] <wgrant> So our legal HTML gets mangled unreadable, I suppose.
[11:19] <stub> Because this was from the dark ages when it was the sanest way of generating the xml-like files that could only be validated using a form running on Mark Pilgrim's web site?
[11:20] <wgrant>             # Unqualified hrefs must be qualified using the original subdomain
[11:20] <wgrant>             # or they will try be served from http://feeds.launchpad.net,
[11:20] <wgrant>             # which will not work.
[11:20] <wgrant> It uses BeautifulSoup to do that :(
[11:20] <wgrant> Not quite sure what's wrong with teaching canonical_url to do that...
[11:21] <wgrant> Anyway, looks like I am monkeypatching BeautifulSoup :(
[12:00] <StevenK> wgrant: I think we should solve it another way, and just destroy feeds.
[13:06] <deryck> Morning, all.
[13:06] <abentley> deryck: morning.
[13:07] <abentley> adeuring: After discussing queues and routing keys with Celery's main author on Friday, I think we should switch to using queues explicitly.
[13:07] <abentley> adeuring: Celery is unlikely to support routing keys the way it supports queues in the near future.
[13:07] <adeuring> abentley: sshall talk about it after the standup?
[13:08] <abentley> adeuring: Sure.
[13:10] <czajkowski> gmb: ello
[13:10] <gmb> czajkowski: Wotcher
[13:11] <czajkowski> gmb: care to give a talk during UAD week?  https://wiki.ubuntu.com/UbuntuAppDeveloperWeek/
[13:11] <abentley> czajkowski: I figured out the national holiday issue.  I accidentally had Christmas holidays ending Feb 26.  I've asked dragnob to delete/correct it.
[13:12] <gmb> czajkowski: What topic are you thinking about? Development using the LP API?
[13:12] <czajkowski> gmb: aye
[13:13] <czajkowski> gmb: could be handy as I want to do  ablog series on low bugs to get people involved
[13:13] <czajkowski> abentley: see I wasn't going crazy :)
[13:13] <gmb> czajkowski: Okay. Let me have a think, see if I can come up with anything that would fit well.
[13:13] <czajkowski> gmb: thanks
[13:13] <abentley> czajkowski: Yeah, but where's the evidence you weren't already crazy :-)
[13:14] <czajkowski> abentley: good counter argument!
[13:14] <czajkowski> can't fault you there
[13:21] <StevenK> czajkowski: So you want to fix bugs and blog about it, or what are you thinking?
[13:24] <czajkowski> StevenK: i sent a mail to lp-dev there on friday
[13:24] <czajkowski> people to suggest a low bug
[13:24] <czajkowski> then to try and get people to work on those in the community
[13:25] <nigelb> Remember to ask that folks contrubting to LP need to sig the contributor agreement.
[13:25] <nigelb> *sign
[13:35] <czajkowski> and conversation dead :(
[15:00] <rick_h> deryck: ping, so just to be sure, we want the notification to go out when someone adds an email/gpg key, and we want that timed when the initial request goes out, not when it's accepted/verified right?
[15:00] <deryck> rick_h, yeah, that sounds right to me.
[15:01] <rick_h> 142372
[15:02] <deryck> rick_h, was that number for me?
[15:03] <rick_h> deryck: no, it's this stupid yubikey. I keep finding ways to bump it
[15:04] <rick_h> sorry, I keep trying different usb ports, but all are too handy it appears
[15:14] <deryck> rick_h, no worries :)
[15:30] <abentley> adeuring: I've tested CELERY_CREATE_MISSING_QUEUES, and it works as advertised.  Here's my current config: http://pastebin.ubuntu.com/911604/
[15:30] <adeuring> abentley: cool
[18:06] <reed> hi thedac, we didn't make a copy of http://people.canonical.com/~dames/openstack.mbox.tar.gz in time :( Should I file the request again?
[18:08] <thedac> reed: hi, I will get that to you again
[18:09] <reed> thanks thedac, I apologize for the extra work
[18:13] <thedac> reed: I have placed that at the same URL
[18:16] <reed> thedac, thank you very mych
[18:16] <thedac> no problem
[18:20] <rick_h> deryck: ping, have a sec?
[18:25] <deryck> rick_h, otp.  ping when off.
[18:26] <rick_h> deryck: k
[18:41] <ayan> is there a Go implementaiton of the launchpad api?
[18:44] <rick_h> ayan: looks like: http://blog.launchpad.net/api/launchpad-is-go
[18:45] <deryck> rick_h, hey, what's up?
[18:45] <rick_h> deryck: want to chat on this before I put up for mp if you don't mind
[18:45] <deryck> rick_h, sure.  hangout?
[18:45] <rick_h> yes please the go-deryck url?
[18:46] <deryck> yeah
[19:09] <lifeless> morning
[19:10] <abentley> lifeless: morning.
[19:10] <abentley> lifeless: How would you feel if all Jobs ran under that same db userid, e.g. launchpad_main?
[19:16] <lifeless> I would worry - some of our jobs have access to privileged data and that would increase the surface area that security breaches can happen within.
[19:17] <lifeless> OTOH there is a healthy (but very high latency) discussion taking place on the dev list about whether our multiple db users is worth it
[19:18] <lifeless> that said, for situations where one can do 'dbuser(foo)', the degree of security we gain is minimal, its only when a db user is /not/ available that security is really increased.
[19:19] <lifeless> finally, we do get reasonably significant benefits on reporting db *load* by user, which I'd be sad to lose
[19:19] <jelmer> 'morning lifeless, abentley
[19:19] <abentley> jelmer: morning.
[19:19] <lifeless> hi jelmer
[19:21] <abentley> lifeless: Okay.  Getting rid of 'em as we move to Celery would simplify it some, but not dramatically.
[19:32] <rick_h> deryck: so no current messages when ssh keys are added/removed. Are we thinking we want both?
[19:33] <deryck> rick_h, yeah, a user should be notified of both.
[19:33] <rick_h> deryck: ok, will do.
[19:33] <deryck> cool, thanks
[19:55] <bac> hi flacoste
[20:02]  * deryck heads back home
[20:05] <lifeless> flacoste: hey there
[22:57] <lifeless> fun shiny of the day: create trigger ... where NEW.col is distinct from OLD.col
[22:57] <lifeless> s/where/when/ :)
[23:01] <wgrant> lifeless: Yeah, but only in 9.1
[23:01] <wgrant> That almost made me wait.