[02:29] <michaelh1> Hi there.  Can a public project have private branches?  I want to start a project for the Linaro benchmarks which will have public scripts, some public results, some private results, and some private licensed benchmarks
[02:34] <persia> michaelh1: No.  The usual procedure in that case is to have parallel projects (e.g. foo and foo-private).
[02:34] <michaelh1> persia: OK.  How can I create a private project?
[02:35] <michaelh1> (I already have a private group ~linaro-toolchain-benchmarks)
[02:35] <maco> pay canonical
[02:35] <michaelh1> Already am :)
[02:36] <persia> Contact the LP admins.  It's a commercial service.  I think (but don't know) that one starts by asking a question at answers.launchpad.net/launchpad
[02:36] <michaelh1> Ta.
[02:36] <wgrant> michaelh1: Does Linaro not have documented processes for requesting private projects?
[02:36] <maco> huh. interesting that the "register a project" page doesnt have a "i want to make this private [    ]" checkbox
[02:37] <wgrant> maco: There's no such thing as a private project yet.
[02:37] <wgrant> They can have private bugs and branches by default.
[02:37] <wgrant> But there are no private projects.
[02:37] <maco> ooh. well still, is there like a checkbox to be like "make this private and charge me $x"?
[02:39] <wgrant> Normally you'd select that your project's license is proprietary, and then purchase and apply a commercial usage voucher to the project.
[02:39] <wgrant> But Linaro is a bit special.
[02:41]  * michaelh1 feels special
[02:41] <persia> The specialness ought be masked in invoicing details, rather than exposed in the intereface.
[02:41] <wgrant> Certainly.
[02:41] <michaelh1> wgrant: no on the process.  I'm sending Joey and Kiko an email asking...
[02:41] <wgrant> michaelh1: They are both former Launchpadders, so they are probably best, yes.
[02:41] <wgrant> Launchpad'
[02:42] <wgrant> s present privacy offerings were designed in 2007 or so and have not been touched since. They are known to be suboptimal.
[02:42] <wgrant> My squad is currently working on fixing this to suck a bit less.
[02:42] <wgrant> But it's not there yet.
[09:45] <dart> hello, the new ubuntu mono font in launchpad is too small to read
[09:46] <dart> can i increase it in settings?
[09:59] <lag> How do you remove a single package from a PPA?
[10:00] <bigjools> Click "View packlage details" then click "Delete packages"
[10:02] <candrea> Hello! Could someone please take a look at https://answers.launchpad.net/launchpad/+question/159992 ?
[10:04] <bigjools> candrea: done
[10:04] <candrea> bigjools, thanks!
[10:04] <bigjools> np
[10:13] <candrea> bigjools, I'm done with the project; feel free to change the ownership back to ~registry
[10:14] <bigjools> candrea: you need to do that yourself
[10:15] <candrea> bigjools, right, done
[17:22] <apw> can anyone tell me why the pickers are not working on bug #791918
[17:31] <micahg> apw: you mean the AJAX selectors?
[17:31] <apw> micahg, erm, i mean the popups normally connected to the pencils on the stautus fields etc
[17:32] <micahg> yeah, it's because there are too many tasks, I'm looking for the bug
[17:32] <apw> micahg, ergle
[17:34] <deryck> apw, yeah, we disabled that intentionally for bugs with lots of tasks.  it's a shortcoming in how that code was written, where pages would hang setting up the icons....
[17:34] <micahg> deryck: I can't seem to find the bug...
[17:34] <apw> damn, those are exactly the bugs where you really need them
[17:34] <deryck> apw, we want to fix it so we have js icons and quick render, too.  but it's not yet been a priority.
[17:34] <deryck> apw, yeah
[17:35] <deryck> micahg, let me see if we have a bug.  there may just be the one that was marked fix.  the slow render one.
[17:41] <deryck> micahg, apw -- I cannot find a bug either.  not an old or new one.  Can one of you file a bug about needing this back?
[17:41]  * micahg digs a little more
[17:42] <deryck> it was intentional to remove it until we could address the performance issues, but we need a bug tracking that we should fix said performance issues and bring it back :)
[17:45]  * micahg remembers being showed the bug at one point...
[17:45] <micahg> apw: can you file a new one?
[17:46] <apw> micahg, against which thing
[17:46] <micahg> apw: launchpad
[17:48] <apw> https://bugs.launchpad.net/launchpad/+bug/791936
[17:49] <apw> micahg, ^^
[17:50] <micahg> apw: looks good, I figure lifeless will probably remember if there's a duplicate or not
[17:58] <deryck> micahg, apw I've commented and triaged that bug.  Thanks for filing it!
[17:59] <deryck> It should be fixed, so it's high.  but unfortunately, I have no idea when someone will get to it with the number of critical issues we have open at the moment.
[18:40] <deryck> abentley, I'll pass to you now.
[18:40] <abentley> deryck: aye aye.
[20:24] <Renegade15> good day
[20:25] <Renegade15> in the sidebar, Launchpad is telling me I'm at 100% configuration, but complains "Launchpad needs to know where the user can submit code"...how do I tell it that?
[20:56] <Darxus> Pedro Villavicencio's habbit of marking bugs incomplete just because they're old is pissing me off.
[20:58] <micahg> Darxus: you should talk to pedro in #ubuntu-bugs about that, nothing to do with #launchpad
[20:59] <Darxus> Thanks, sorry.
[21:01] <Renegade15> in the sidebar, Launchpad is telling me I'm at 100% configuration, but complains "Launchpad needs to know where the user can submit code"...how do I tell it that?
[21:19] <abentley> Renegade15: Have you set a development focus yet?  That might be it.
[21:20] <Renegade15> I have indeed, and it is connected to a branch...the branch is a git import, though, can that be the reason?
[21:22] <abentley> Renegade15: that could be the reason.  That area seems to have changed recently.  Used to be you could set whether the project used Launchpad for Code.
[21:22] <abentley> Renegade15: what project is this?
[21:22] <Renegade15> openyr - it's fairly new
[21:24] <abentley> Renegade15: I think the text is inaccurate-- if development happens elsewhere, then users definitely can't submit code.
[21:25] <Renegade15> I see
[21:26] <Renegade15> I'll send users around in the description, then. I was just wondering if I was missing a piece of config
[21:26] <Renegade15> thank you :)
[21:26] <abentley> Renegade15: No problem.
[21:26] <Renegade15> see ya
[23:37] <maxb> Hrm. it is irksome not being able to retry a binary build resulting from a recipe build
[23:38] <lifeless> I think we should allow that
[23:38] <lifeless> but we need a solution to the unique-version-string-thing
[23:40] <maxb> how does that impact retrying binary builds?
[23:40] <lifeless> hmm
[23:41] <lifeless> ah
[23:41] <lifeless> ok, so I didn't click to your point
[23:41] <lifeless> do we really not permit that?
[23:41] <maxb> Apparently not
[23:41] <lifeless> iz bug
[23:42] <maxb> Boo, I tried to cheat via the WS, but it threw an AssertionError :-)
[23:48] <mwhudson> that means it oopsed i guess, which makes it critical at least!
[23:51] <maxb> x-lazr-oopsid: OOPS-1979AY85 :-)
[23:52] <maxb> ooh
[23:53] <maxb> All recipe builds end with something like ~lucid1
[23:53] <maxb> It would be awesome if they snooped the target archive before they started the build, and incremented the final digit until there was no published source that they would collide with
[23:59] <wgrant> maxb: Huh, you should be able to retry binary builds. There's no difference.