[02:54] <aroman> hey, about the new "recipies" feature, can that work for a very involved chroot/squashfs ubuntu-to-custom_distro build script?
[02:55] <aroman> needs root to run, naturally
[03:06] <wgrant> aroman: It only works for building source packages.
[09:14] <mrevell> Morning
[09:50] <czajkowski> mrevell: howdy
[09:53] <jelmer> hey mrevell
[11:31] <dpm> hi launchpadders, I'd like to change the type of project of https://launchpad.net/ubuntu-translations from independent to a container for subprojects (sorry, I don't know the terminology). People are starting to contribute with code to projects related to Ubuntu translations, and it would be very useful to have subprojects under the ubuntu-translations umbrella. Is migration from project to "container project" possible, and if so, how?
[11:32] <lifeless> dpm: its not directly possible.
[11:33] <lifeless> dpm: you need to rename the project to whatever its actual name should be and then create the superproject (we call them  project groups)
[11:37] <dpm> lifeless, I'm not sure I can follow. So I've got ubuntu-translations and then I rename it to ubuntu-translations-old and then create the ubuntu-translations project group?
[11:38] <lifeless> yes, or whatever thing the ubuntu-translations project should be called: presumably you created it to hold code :)
[11:39] <lifeless> dpm: a simpler thing is just to create 'ubuntu-translations-project' and make that the contianer
[11:39] <lifeless> (by create it, I mean have a sysadmin make it - you cannot make project groups)
[11:40] <dpm> lifeless, I think I'll go for the simple approach. Ideally, I'd like to have the current ubuntu-translations project to be the project group (keeping the bugs and answers from the original) and have other projects underneath. But I think if it's not easy to do, it's not worth the hassle
[11:41] <dpm> So I'd be happy with the simpler approach
[11:42] <lifeless> dpm: project groups cannot have bugs and answers
[11:43] <lifeless> dpm: they are not 'projects that can nest other projects' - they are /just/ a container for other projects.
[11:46] <dpm> lifeless, ok, I see, thanks. I think it will still be useful to have the ubuntu-translations-project group. How do I go about requesting the creation?
[11:48] <lifeless> grab the help contact :)
[11:55] <dpm> ok, :-) thumper, wallyworld, I'd like to create an ubuntu-translations-project project group, could you help me with that?
[11:59] <wgrant> dpm: They're probably not around, but I can do it for you.
[11:59] <wallyworld> dpm: hi dpm. i assume no-one got back to you yesterday? sorry about that. it was 1am here when your question came up and i forgot to do it this morning
[11:59] <dpm> thanks wgrant - tell me if you need any more details
[12:00] <wgrant> wallyworld: Do you want to do it? I already have the form filled out.
[12:00] <dpm> wallyworld, thanks for coming back to me. It seems it's sorted: the langpack just took longer to generate than usual. It was there this morning, so all good.
[12:00] <wallyworld> wgrant: i don't mind but if you are almost there.....
[12:01] <wgrant> dpm: https://launchpad.net/ubuntu-translations-project
[12:01] <wgrant> I was a bit uncreative with the display name, title, summary and description, as you can probably see.
[12:03] <dpm> :)
[12:05] <dpm> wgrant, do you happen to know how to associate an existing project with it? I can't see any obvious way to do it on the overview page
[12:05] <dpm> I can only see links to registerin a new project
[12:08] <wgrant> dpm: You do it from the project's "Change details" page. "Part of", I believe the field caption is.
[12:09] <dpm> wgrant, ok, cool, thanks. Do you know any other things I should be aware of re: project groups?
[12:11] <wgrant> dpm: At the moment anybody can add their project to your project group. But that just makes it show up on your project group page and gives you certain powers over their project, so people don't tend to do that.
[12:11] <wgrant> Apart from that there's not much to them.
[12:11] <dpm> ok, gotcha
[12:11] <dpm> thanks!
[12:17] <dpm> so now that I've added the existing ubuntu-translations project to it, https://launchpad.net/ubuntu-translations-project shows me the code, answers and all the rest for ubuntu-translations. What happens if I add other subprojects? Will the code/bugs and other tabs show me a combined view of all branches, bugs, etc. coming from all subprojects?
[12:17] <wgrant> Right, it shows all the objects from the children.
[12:20] <dpm> ok, understood
[13:29] <pindonga> morning, I've seen a feature I'd like to enable for my project, but I don't know how: I'd like to automatically subscribe a team to any private branches I submit for a project, in order to let any member of the team access my branches
[13:29] <pindonga> I've seen this happening for somebody else, but neither he nor I know exactly what setting to tweak to allow for this behaviour
[13:29] <pindonga> any clues?
[13:34] <wgrant> pindonga: At the moment it does a bit of limited guesswork. If the owner of the new branch is a member of a team that's set up to have private branches for the project, that team will be subscribed.
[13:34] <pindonga> wgrant, mhhh, I'm a member of the team owning the project, and it's not happening
[13:34] <pindonga> :(
[13:35] <pindonga> wgrant, is there any way I can figure out why?
[13:35] <wgrant> pindonga: Which is the branch?
[13:36] <pindonga> wgrant, pm
[13:36] <wgrant> Sure.
[18:23] <popey> hullo!
[18:24] <popey> bug 664088
[18:24] <popey> does ^^ that mean its a private bug?
[18:24] <popey> if so a) shouldn't it say so on the page and not give a 'lost' page, and b) say so in the bug bot text?
[18:55] <Ampelbein> popey: regarding part "b", the bot does say it's private, when it's a private bug. like bug 667125
[18:55] <Ampelbein> oh, this one doesn't.
[18:55] <Ampelbein> the other incarnations do, from what I've seen.
[18:56] <Ampelbein> nvm me then
[19:27] <popey> Ampelbein: exactly :)
[19:27] <popey> I suspect an API change in LP
[19:36] <lifeless> popey: Ampelbein: high
[19:36] <lifeless> we did change private bugs recently to fix an information disclosure hole
[19:37] <lifeless> popey: bug 664088 *is* a private bug
[19:38] <lifeless> popey: would need to see what ubot5 is doing to see why its getting confused now
[19:38] <lifeless> popey: we should be sending a 404 to it
[19:39] <Ampelbein> lifeless: 'ubot4`' correctly replies "Bug 664088 on http://launchpad.net/bugs/664088 is private" when I /msg him
[19:39] <lifeless> fun
[19:39] <Ampelbein> and I thought all ubotX where just clones of each other?
[19:50] <vanguard> I tried the OpenID feature, looks nice, but what do I do when lp does not provide OpenID any more? Are all my accounts lost then?
[19:52] <lifeless> vanguard: so lp doesn't provide openid, what it does is forward to login.ubuntu.com
[19:52] <lifeless> vanguard: and thats going to keep doing openid for a -long- time
[19:54] <vanguard> lifeless: ty robert, but in case ubuntu would not do that the accounts whould be lost, right? (I do trust canonical/ubuntu/lp with that, I am just thinking)
[19:54] <lifeless> as for what to do if login.ubuntu.com were to stop doing openid, I guess that would depend on the sites you've been logging into via openid
[19:54] <lifeless> if we were to stop doing offering openid, I imagine there would be a long migration period - there are -many- people depending on it today
[19:55] <vanguard> right, kinda like Google does not go out of business by tomorrow
[20:07] <popey> lifeless: thanks
[21:52] <popey> lifeless: is there anything you can do on the lp side to help with bug 737108
[21:54] <lifeless> popey: sounds like its fixed to me: bug 664088
[21:54] <lifeless> bah, when it gets deployed ;)
[21:55] <lifeless> tsimpson: ^ have you deployed the fix?
[21:58] <popey> bug 999999
[21:58] <popey> surely that's going to give me 404 too?
[21:59] <popey> a non-existent bug is not the same as a private bug IMO
[21:59] <lifeless> they are now
[21:59] <lifeless> and it was a bug that they were not in the past
[21:59] <popey> well thats broken IMO
[21:59] <lifeless> why?
[21:59] <popey> this is especially apparent when (as in this case) someone tags a public bug as a dupe of a private one
[21:59] <lifeless> so, thats a problem too, in a different way
[21:59] <lifeless> it also needs fixing
[22:00] <lifeless> the rules we have for private bugs are:
[22:01] <lifeless>  - noone can know about private bugs unless they can see them [reason: private bugs on public projects are generally either under ndas or cve etc]
[22:03] <lifeless> popey: let me give you an example
[22:03] <popey> i can understand why we have private bugs
[22:03] <lifeless> popey: say you had a public project hosted on LP, and you did some commercial dev in that environment
[22:03] <lifeless> popey: would you be happy if anyone could determine that 40% of your bugs were private?
[22:04] <popey> I'm not a developer so maybe cant relate to that example
[22:05] <lifeless> popey: so step me through the impact on you
[22:05] <popey> I filed a bug as user of a website which is part of the canonical project
[22:06] <popey> the developer who works on that has tagged it as a dupe of a private bug
[22:06] <popey> i cant see that private bug so cannot take part in the discussion
[22:06] <lifeless> ok
[22:06] <popey> All I will know is that at some unknown point in the future it will or wont be fixed
[22:06] <popey> I have no way to contribute, and no way to know what the thought process around the bug is
[22:06] <james_w> Schrödinger's popey
[22:06] <lifeless> so private bugs fall (broadly) in a few categories
[22:07] <lifeless> one is security issues
[22:07] <lifeless> another is client-specific confidential work
[22:07] <lifeless> mmm, possibly a third but lets stick to these two for a second
[22:07] <popey> i appreciate both of those
[22:08] <lifeless> in the security case, folk that *suffer* the bug are not trusted to *see the details* - because that would trivially let a hacker observe the changes going on
[22:08] <lifeless> in the client specific case, there is little reason for the owner of a dupe filed publicly to be prevented from seeing the discussion - but there may be
[22:09] <lifeless> so in both cases, we default to not adding the subscribers to the dup to be subscribers to the master
[22:09] <lifeless> which is why you don't get visbility
[22:10] <popey> which I am partially okay with
[22:10] <popey> i have signed no NDA
[22:10] <lifeless> ok
[22:12] <lifeless> so, we could ask 'do you want to give the subscribers to bug <x> access to the master bug'
[22:12] <lifeless> I suspect in this case that schwuk would have said no
[22:13] <popey> ok
[22:13] <popey> so there's commercially sensitive detail in the bug, i can understand not being a subscriber
[22:13] <lifeless> (I suspect that from a quick look at the bug in question - I'm in the hardware cert teams)
[22:14] <lifeless> another option would be for them to not dupe the bug
[22:14] <lifeless> and we should almost certainly warn on duping against private bugs
[22:16] <lifeless> popey: what are your needs here?
[22:16] <popey> well theres still two specific issues.
[22:16] <lifeless> popey: knowing when your defect is fixed? partaking of design discussion?
[22:16] <popey> both of those, plus the fact that launchpad is lying to the bot, which leads people to get confused about the existence of bugs
[22:16] <lifeless> well
[22:16] <lifeless> that bit isn't going to change - sorry.
[22:16] <popey> it could also lead to people thinking "their" contribution isn't being looked at
[22:17] <popey> or that their contribution isnt wanted
[22:17] <lifeless> the reason the visibility thing is a high risk issue is that complexity leads to mistakes
[22:18] <lifeless> and allowing -partial- visibility lead to a situation where the API could tell what tasks a private bug had on it, amongst other things
[22:18] <lifeless> which was a Big Deal
[22:20] <lifeless> let me just grab that bug
[22:21] <lifeless> bug 735202
[22:23] <popey> thanks for explaining it
[22:27] <lifeless> popey: I think we should make it easier for projects using private bugs to work with partial disclosure
[22:27] <lifeless> some things we have queued up for this:
[22:27] <lifeless>  - bug relationships - duplication is one special case, but also dependency, alternative etc
[22:28] <lifeless>    these will make it possible to have a private master bug with confidential discussion
[22:28] <lifeless> and a public master bug with public discussion
[22:28] <lifeless> make dups onto the public master
[22:28] <lifeless> discuss private stuff on the private
[22:29] <lifeless> devs that can see both will see bidirectional links
[22:29] <lifeless> folk that can't will only see the public bug
[22:31] <lifeless>  - an overhaul of disclosure and private bug management
[22:31] <lifeless>    just to mae it easier to work with them
[22:32] <lifeless> popey: you might like to look and see if we hve bugs for - warning when duping public onto private, and asking/allowing control of migrating subscribers across when dealing with duping and private bugs
[22:35] <popey> ok
[22:37] <lifeless> I think at the heart of this though, its a combination of not much sophistication in LP for managing this complex situation, and a lack of clear articulation about what teams doing private bugs need to worry about
[22:37] <lifeless> making it easier in LP will help, but won't be a panacea
[22:39] <popey> sure
[22:42] <james_w> OOPS-1902C2255)
[22:42] <james_w> preventing me from looking at the linaro-image-tools branches, which means I may have to duplicate work
[22:44] <wgrant> james_w: Is it reproducible?
[22:45] <james_w> twice in a row for me
[22:45] <wgrant> james_w: It looks like a timeout from one of the old appservers being slow.
[22:45] <james_w> different browser worked now
[22:45] <wgrant> We'll be replacing them in the next couple of weeks, which should eliminate this sort of timeout.
[22:48] <james_w> ok, thanks
[23:04] <tsimpson> lifeless: I've committed a fix for the "Could not parse data returned by Launchpad" error to properly identify 404s, the bots will pick it up in some time