| Noldorin | hi lifeless | 00:01 |
|---|---|---|
| lifeless | Noldorin: hi there | 00:14 |
| === mwhudson_ is now known as mwhudson | ||
| Noldorin | lifeless, just had a though about the namespace issue... | 00:37 |
| Noldorin | might be worth considering | 00:37 |
| Noldorin | lifeless, ping | 00:56 |
| lifeless | Noldorin: I'm here | 01:00 |
| lifeless | Noldorin: waiting for you to describe your though | 01:00 |
| Noldorin | lifeless, okay :-P | 01:00 |
| Noldorin | lifeless, so what about having user/team-based namespaces, but the global namespace underlying that... the global namespace could have unique aliases that go to the team/user project names | 01:01 |
| Noldorin | which may or may not be the same according to availability | 01:01 |
| lifeless | I'm not sure I follow | 01:02 |
| Noldorin | ... | 01:02 |
| Noldorin | ok | 01:02 |
| StevenK | If I understand correctly, he wants a namespace that is contained to within a team or user, and the global namespace links to those. | 01:03 |
| Noldorin | yep | 01:03 |
| Noldorin | just aliases | 01:03 |
| StevenK | However, we have seven years of global namespace use ... | 01:03 |
| Noldorin | so that you can maintain the benefits of a global namespace and user-based namespaces ;-) | 01:04 |
| Noldorin | StevenK, length of time of usage doesn't make it good ;-) | 01:04 |
| Noldorin | although lifeless claimed global namespaces have one or two advantages, and i agreed | 01:04 |
| Noldorin | just about | 01:04 |
| StevenK | Noldorin: Certainly not, and I'm not implying that. I'm just saying that it is fairly well entrenched. | 01:04 |
| Noldorin | that is true | 01:04 |
| lifeless | Noldorin: so if the global namespace is just aliases to specific team+project|distro pairs | 01:05 |
| Noldorin | StevenK, but this certainly allows a better transition than a switch simly to github-style project namespaces | 01:05 |
| lifeless | Noldorin: that implies we'd still need controls around alias setting | 01:05 |
| Noldorin | lifeless, yes. the same controls that already exist basically | 01:05 |
| lifeless | Noldorin: but could allow free-for-all within a user/team | 01:05 |
| lifeless | context | 01:05 |
| Noldorin | i'm suggesting this because i know you like your global namespaces | 01:05 |
| Noldorin | lifeless, yes indeed | 01:05 |
| Noldorin | that's the idea | 01:05 |
| lifeless | so, this might be a good way to tackle a migration | 01:05 |
| Noldorin | yeah. better backwards compatibility eh? | 01:06 |
| lifeless | it is contingent on .. ELOCAL< back soon | 01:06 |
| Noldorin | ELOCAL? | 01:06 |
| StevenK | It's a UNIX thing -- EPERM == Permission denied | 01:06 |
| StevenK | ELOCAL == Local problem or so | 01:06 |
| Noldorin | ah ok | 01:07 |
| Noldorin | so ELOCAL< back soon mean? | 01:07 |
| StevenK | "I have a local problem that I need to deal with, back soon" ? | 01:07 |
| Noldorin | haha okay | 01:08 |
| Noldorin | StevenK, sorry, i'm completely unfamiliar with unix geek-lingo :-) | 01:08 |
| StevenK | Noldorin: It wasn't helped that lifeless typoed ',' as '<' | 01:11 |
| lifeless | right, back | 01:11 |
| StevenK | But , and < share a key | 01:11 |
| Noldorin | heh yeah | 01:11 |
| Noldorin | so they do | 01:11 |
| Noldorin | lifeless, hi | 01:11 |
| lifeless | so, one of the things you can do with a global project|distro namespace + team namespace is treat them as two-dimensional coordinates | 01:11 |
| lifeless | that is | 01:11 |
| lifeless | '~lifeless' + ubuntu == lifelesses things to do with Ubuntu | 01:12 |
| lifeless | for that to work, you need the concept of ubuntu to be consistent across all such tuples | 01:12 |
| lifeless | e.g. ~ubuntu-council + ubuntu must refer to the same ubuntu. | 01:13 |
| lifeless | This is in tension with a hierarchical namespace where ~ubuntu-council/ubuntu could be totally different to ~lifeless/ubuntu | 01:13 |
| Noldorin | not sure i get you | 01:14 |
| lifeless | Strictly speaking we could do ~lifeless+~ubuntu-council/ubuntu, to implement this on top of a hierarchical namespace | 01:14 |
| lifeless | but I suspect that would confuse users | 01:14 |
| lifeless | Noldorin: say you want to find our about your bugs in ubuntu, how do you do that? | 01:15 |
| Noldorin | lifeless, the same way as i do now. why would it be different? | 01:15 |
| lifeless | well, today you can't | 01:15 |
| Noldorin | oh really? | 01:16 |
| Noldorin | heh | 01:16 |
| lifeless | you can search for your related bugs - returns everything, or you can search in Ubuntu for bugs with a specific rule like assigned-to-you | 01:16 |
| Noldorin | fair enough | 01:16 |
| Noldorin | sounds like an orthogonal feature to me though | 01:16 |
| lifeless | but there isn't a way to combine these two primitives | 01:16 |
| Noldorin | could work equally well on top of the old or new namespace system | 01:16 |
| lifeless | in terms of computer code, certainly. In terms of UI, I'm not so sure | 01:17 |
| lifeless | /~ubuntu-council/ubuntu/~lifeless | 01:17 |
| lifeless | ^ what would that really mean? | 01:17 |
| Noldorin | that would be invalid syntax to me | 01:17 |
| Noldorin | under what i'm proposing, at least | 01:17 |
| lifeless | in which case, you're proposing this other feature not be implementable :) | 01:17 |
| Noldorin | perhaps you envisage my suggested changes as more radical than they in fact are | 01:17 |
| lifeless | Noldorin: I don't think they are radical | 01:18 |
| Noldorin | good | 01:18 |
| Noldorin | :-) | 01:18 |
| lifeless | Noldorin: but they have consequences | 01:18 |
| lifeless | such as changing the potential hierarchy from intersection-of-interests to control-of-components | 01:19 |
| lifeless | (and diluting the concept of 'project|distro identity') | 01:19 |
| lifeless | there are some good social arguments around identity being a claimed/earnt thing rather than an imposed thing | 01:19 |
| lifeless | 'centre of gravity' | 01:20 |
| lifeless | etc | 01:20 |
| Noldorin | lifeless, so just to be clear, give me an example of a current structure/feature that would break in a potentially bad way under my proposed system | 01:20 |
| lifeless | the one I gave before | 01:20 |
| lifeless | my bugs in the context of ubuntu, where ubuntu has been redefined as ~ubuntu-council/ubuntu | 01:20 |
| Noldorin | can that be done presently though? | 01:20 |
| Noldorin | sorry if i'm just ignorant about Launchpad features | 01:21 |
| lifeless | It is an open opportunity today | 01:21 |
| Noldorin | there's some i inevitably don't use | 01:21 |
| lifeless | its not implemented | 01:21 |
| Noldorin | okay | 01:21 |
| lifeless | I'm exploring the consequences of your suggestion | 01:22 |
| lifeless | one of them is that this other thing would be a lot harder | 01:22 |
| Noldorin | lifeless, so your argument is that if you implement mine in the future, ~ubuntu-council/ubuntu/~lifeless would appear confusing, eh? | 01:22 |
| Noldorin | (e.g.) | 01:22 |
| lifeless | right | 01:22 |
| Noldorin | hmm | 01:22 |
| lifeless | and in fact branches work this way today | 01:22 |
| lifeless | branches are ~$USER/$PROJECT/$BRANCHNAME | 01:23 |
| lifeless | so if you redefine project as being defined by a user | 01:23 |
| Noldorin | lifeless, unless it's associated with a series, in which case it's $project/$branchname, no? | 01:23 |
| Noldorin | or at least aliased to such | 01:23 |
| lifeless | ~lifeless/ubuntu/foo would become something like ~lifeless/~ubuntu-council/ubuntu/foo | 01:23 |
| lifeless | indeed, the series provides an alias | 01:23 |
| Noldorin | hmm | 01:24 |
| Noldorin | okay, i see your point | 01:24 |
| Noldorin | lifeless, this is a fairly high priority feature you guys want to implement then, i take it? | 01:24 |
| lifeless | well, branches already work this way | 01:24 |
| Noldorin | so it would make sense for bugs to as well, yeah... | 01:24 |
| StevenK | It would? Branches look like nothing else inside LP. :-( | 01:25 |
| lifeless | you can argue that we have been inconsistent about how different primitives interact | 01:25 |
| lifeless | and I'd accept that | 01:25 |
| lifeless | but I feel that adding inconsistency when there is a clear conflict would be unwise; we'd need to have *some* way forward to resolve the inconsistency | 01:25 |
| Noldorin | lifeless, so it really boils down to the URL syntax, in some respects. perhaps something like ~lifeless | 01:26 |
| lifeless | the overall goal being to decrease the amount of special-casing needed to learn how LP works. | 01:26 |
| Noldorin | err one sec: | 01:26 |
| Noldorin | ~ubuntu-council/ubuntu/#~lifeless | 01:27 |
| Noldorin | or even query strings | 01:27 |
| Noldorin | yes i concur with that general aim | 01:27 |
| Noldorin | i thing the problem is with this proposal for the URL syntax for a user's bugs in a certain project | 01:28 |
| Noldorin | lifeless, the url would be slightly confusing even under the current project namespace system | 01:28 |
| Noldorin | (i.e. global namespaces) | 01:28 |
| Noldorin | maybe not as much, but there would be semantic inconsistencies | 01:28 |
| Noldorin | for sure | 01:28 |
| Noldorin | or ambiguity | 01:28 |
| lifeless | indeed | 01:28 |
| lifeless | it could mean 'my bugs' like it means 'my branches' or it could mean 'things I'm interested in' without implying ownership | 01:29 |
| lifeless | or $other | 01:29 |
| Noldorin | so i think we need to sacrifice URL terseness by making the semantics clearer... | 01:29 |
| Noldorin | if at the expense of length/verbosity, then so be it | 01:29 |
| Noldorin | that's my proposal | 01:29 |
| Noldorin | (ideally not query strings, but you get the idea i think...) | 01:30 |
| Noldorin | lifeless, does that sound reasonable? | 01:33 |
| wgrant | cjohnston: The API method we discussed yesterday is on production now: http://paste.ubuntu.com/1012430/ | 01:39 |
| mhall119 | cjohnston: sup? | 01:41 |
| cjohnston | mhall119: < wgrant> cjohnston: The API method we discussed yesterday is on production now: http://paste.ubuntu.com/1012430/ | 01:41 |
| mhall119 | yeah, we need a service that does the opposite, takes a launchpad nickname and returns an openid | 01:42 |
| wgrant | mhall119: That doesn't make sense. | 01:42 |
| wgrant | mhall119: That's not a 1-1 mapping. | 01:42 |
| mhall119 | I know | 01:42 |
| wgrant | mhall119: The intent is that you call this on login. | 01:42 |
| wgrant | So you get the identifier from SSO, and then ask LP who it is. | 01:42 |
| mhall119 | we have username on login (most of the time) | 01:42 |
| mhall119 | from openid | 01:42 |
| wgrant | Then why do you need the other direction? | 01:43 |
| mhall119 | our problem is when we create users from our Blueprints and Attendees import, and we need to associate them with an openid so they can log in | 01:43 |
| wgrant | Why not associate them with a username so they can log in? | 01:43 |
| mhall119 | we have username, we don't have openid | 01:44 |
| mhall119 | we can't let them login with an unknown openid using an existing username, because it's not secure | 01:44 |
| mhall119 | I talked to pindonga earlier about adding an API to SSO to give us the info we need, but it'll be a matter of allocating the resouces on that team to get it implemented | 01:45 |
| wgrant | SSO doesn't have the info you need. | 01:45 |
| mhall119 | what is it missing? | 01:45 |
| wgrant | What do you need? | 01:46 |
| mhall119 | a list of all openids associated with a given Launchpad nickname | 01:46 |
| lifeless | Noldorin: I'm not sure its sufficient to avoid the user confusion I referenced | 01:46 |
| wgrant | SSO can't reasonably give you that. | 01:46 |
| mhall119 | why not? | 01:46 |
| wgrant | LP could, but it's still really going the wrong way. | 01:46 |
| wgrant | Because SSO doesn't really know about Launchpad nicknames, except for deprecated legacy reasons. | 01:46 |
| mhall119 | LP only has one openid per profile, doesn't it? | 01:47 |
| wgrant | No | 01:47 |
| wgrant | That's precisely the problem. | 01:47 |
| mhall119 | wgrant: well it returns launchpad nicknames as part of the OpenID response | 01:47 |
| wgrant | mhall119: Right, deprecated legacy reasons. | 01:47 |
| mhall119 | is that really a deprecated use case? | 01:48 |
| lifeless | mhall119: yes | 01:48 |
| Noldorin | lifeless, why not? i think you can make it arbitrarily clear/verbose... | 01:48 |
| mhall119 | so at some point SSO won't be able to give us sreg.username? | 01:48 |
| wgrant | mhall119: Right. | 01:48 |
| Noldorin | URLs can only convey so much information | 01:48 |
| lifeless | Noldorin: verbosity doesn't intrinsically increase usability | 01:48 |
| wgrant | mhall119: Unless it grows its own definition of username. | 01:48 |
| lifeless | Noldorin: sorry, while this is fascinating, I need to context switch now | 01:48 |
| Noldorin | lifeless, it decreases ambiguity/confusion if done right, as is the case here :-P | 01:48 |
| Noldorin | lifeless, okay. something to mull over anyway | 01:49 |
| Noldorin | catch you later | 01:49 |
| lifeless | ciao | 01:49 |
| Noldorin | only other thing i was going to ask about is how the launchpad wiki effort is going, but that can wait ;-) | 01:49 |
| Noldorin | yeah, bye | 01:49 |
| lifeless | mhall119: both the SSO developers and LP devs would like to untangle things | 01:49 |
| wgrant | mhall119: Currently SSO pretends to be separate from LP. They want to be completely separate. | 01:49 |
| lifeless | mhall119: the SSO split which carried the username across made a mistake in doing that | 01:49 |
| wgrant | mhall119: But returning LP-specific data is mutually exclusive with that goal. | 01:50 |
| wgrant | mhall119: And rather confusing. | 01:50 |
| lifeless | mhall119: what we now believe is that the LP username and group information should have not been offered via Ubuntu SSO | 01:50 |
| mhall119 | so....we will still need a way to create a user from the Launchpad profile prior to that person logging in via SSO, but we'll need to know ahead of time the allowed SSO ids for that user | 01:51 |
| lifeless | mhall119: because it adds confusion when you consider e.g. browserid, alternative openid providers like facebook and google | 01:51 |
| lifeless | mhall119: SSO doesn't *have* ids | 01:51 |
| wgrant | SSO has an OpenID identifier. | 01:51 |
| wgrant | That's all | 01:51 |
| mhall119 | it does, from my understanding | 01:51 |
| lifeless | mhall119: thats rather the point; it just has openid urls | 01:51 |
| mhall119 | right, identifyer == id | 01:51 |
| lifeless | mhall119: this is for summit right? why do you need to know the openid urls a priori? | 01:52 |
| lifeless | mhall119: why can't you do this: | 01:52 |
| mhall119 | summit, ltp, probably others | 01:52 |
| lifeless | - allow anyone to sign in via SSO | 01:52 |
| lifeless | - after they *authenticate* do group mapping via the LP API | 01:52 |
| lifeless | if they aren't in any groups you recognise, show them a 'you need to sign up <list of relevant LP groups>' | 01:52 |
| mhall119 | we need to map a logged in user to a blueprint subscription | 01:53 |
| mhall119 | for Summit | 01:53 |
| lifeless | yes | 01:53 |
| lifeless | I believe what I describe will do that perfectly. | 01:53 |
| lifeless | Clearly that knowledge isn't getting through the narrow pipe that is IRC:) | 01:53 |
| wgrant | There is the user rename issue. There's no way to avoid that entirely. | 01:53 |
| wgrant | Even now it could race if someone does it at a bad time. | 01:53 |
| mhall119 | ok, I think I understand now what you mean | 01:54 |
| mhall119 | so on their first login, when we have *only* an openid url, we use that to lookup the username to give them? | 01:54 |
| lifeless | mhall119: on every login | 01:54 |
| mhall119 | right, ok | 01:54 |
| wgrant | The idea is that your internal key is username, not OpenID identifier. | 01:55 |
| mhall119 | unfortunately that would require changes to django-openid-auth that would be specific to Launchpad | 01:55 |
| lifeless | mhall119: you need to have a mapping of openidurl -> username | 01:55 |
| mhall119 | lifeless: yes, django-openid-auth does that | 01:55 |
| lifeless | mhall119: and you can have many openidurls->sameusername | 01:55 |
| mhall119 | but it expects username to come from the OpenID SReg response | 01:55 |
| mhall119 | lifeless: yes | 01:55 |
| lifeless | mhall119: if you then see an existing openidurl -> differentusername | 01:55 |
| lifeless | you can handle the rename a few ways | 01:56 |
| lifeless | you can make a new local username and delete the old mapping | 01:56 |
| lifeless | or you can update the username | 01:56 |
| mhall119 | we already handle renames (coming from SReg response) | 01:56 |
| lifeless | great | 01:56 |
| lifeless | then this doesn't need any django-openid-auth changes, you just need an additional plugin to let you do group mapping via the LP API | 01:56 |
| mhall119 | so, here's the first of our problems, the openid identity url we currently get from launchpadlib doesn't match what SSO sends us when they log in | 01:57 |
| lifeless | the problem there is that you are *getting an openid url from launchpadlib* | 01:57 |
| lifeless | its what wgrant said way back: thats the wrong way to map | 01:57 |
| wgrant | mhall119: what lifeless said | 01:57 |
| wgrant | mhall119: Now, I ensured that the new API accepts either login.launchpad.net or login.ubuntu.com | 01:57 |
| wgrant | So whichever provider you're using will work. | 01:58 |
| mhall119 | so http://paste.ubuntu.com/1012430/ won't be using the same openid url that launchpadlib is telling us is associated with that nickname? | 01:58 |
| mhall119 | wgrant: the problem wasn't the domain part, it was the ID part | 01:58 |
| wgrant | mhall119: launchpadlib doesn't expose OpenID identifiers AFAIK | 01:58 |
| mhall119 | the last bit of the URL would be different | 01:58 |
| mhall119 | wgrant: it does | 01:58 |
| wgrant | The method I added yesterday is the first one. | 01:58 |
| lifeless | mhall119: when you say 'launchpadlib is telling us is associated with that nickname?' what *exactly* do you mean | 01:59 |
| mhall119 | let me find the code | 01:59 |
| wgrant | mhall119: Are you sure you're not thinking of scraping from https://launchpad.net/~username? | 01:59 |
| wgrant | mhall119: AFAIK that's the only place we expose it. | 01:59 |
| wgrant | In the XRDS delegation stuff on that page. | 01:59 |
| wgrant | That was only ever designed to be used as an OpenID endpoint -- not for Summit and Gerrit to scrape for other purposes :) | 02:00 |
| mhall119 | wgrant: ah, you are right, it's not from launchpad lib, I thought it was | 02:01 |
| mhall119 | http://bazaar.launchpad.net/~summit-hackers/summit/trunk/view/head:/summit/schedule/launchpad.py#L40 | 02:01 |
| mhall119 | yeah, looks like it's scraping | 02:01 |
| mhall119 | ok, so we can use your API now instead? | 02:01 |
| wgrant | Scraping will give you a URL like https://login.launchpad.net/+id/4tLsDY8 | 02:02 |
| wgrant | The new API accepts that, as well as s/launchpad.net/ubuntu.com/ | 02:02 |
| mhall119 | hmm, that'll still require some changes to the login auth code | 02:02 |
| mhall119 | since it currently creates a new user with the SReg username, when a matching user doesn't already exist | 02:02 |
| mhall119 | wgrant: making SSO stop providing user and group info is going to break a lot of stuff, not just our django apps, but the drupal and wordpress plugins too | 02:06 |
| * mhall119 is glad he won't be responsible for fixing those | 02:07 | |
| wgrant | mhall119: Sure, they'll probably have to provide it for years. But we want to stop adding new consumers of it ASAP. | 02:07 |
| wgrant | So we can actually have some hope of migrating within the decade. | 02:07 |
| lifeless | well | 02:08 |
| lifeless | so what will happen is that SSO will start using the LP API itself | 02:08 |
| wgrant | Right, that too. | 02:08 |
| lifeless | so we can support it indefinitely | 02:08 |
| lifeless | anyone doing funkies though, or working with LP, should stop using it immediately, because its single-valued nature leads to the issues you're having | 02:08 |
| mhall119 | maybe it would be better to fork django-openid-auth and make it django-launchpad-auth | 02:09 |
| lifeless | mhall119: LP doesn't *do* auth :P | 02:09 |
| lifeless | mhall119: its a separation between identification and authenticaiton | 02:10 |
| mhall119 | no, but we could use login.launchpad.net and then call Launchpad APIs to get username and group info | 02:10 |
| lifeless | mhall119: making a separate module that doesn't do any of openid, and teach django-openid-auth and it to play nice would be a good beneficial project | 02:10 |
| mhall119 | django auth doesn't separate identity from auth | 02:10 |
| mhall119 | so I'm not sure we'll be able to cleanly separate them | 02:10 |
| lifeless | mhall119: no, you can't use login.launchpad.net sensibly, in the medium future LP will want to support other openid providers and (perhaps) things like browser.id | 02:11 |
| lifeless | mhall119: we'll provide a mapping API for any new authentication groups we support | 02:11 |
| lifeless | mhall119: well, you really want, AIUI, is group mapping for an identity | 02:12 |
| mhall119 | right, and we'll have to support all of those users on Summit and LTP | 02:12 |
| lifeless | mhall119: you can get your identity from login.ubuntu.com and map groups via LP | 02:12 |
| lifeless | mhall119: which is my point, your problem isn't in openid's remit, never was. | 02:12 |
| lifeless | mhall119: so you just need a post-auth step within django to do the group mapping | 02:13 |
| wgrant | sreg is designed for Simple Registration | 02:13 |
| mhall119 | and username mapping | 02:13 |
| wgrant | It's not meant to be used for mapping to other services. | 02:13 |
| lifeless | mhall119: we don't care about usernames | 02:13 |
| mhall119 | we do | 02:13 |
| lifeless | well | 02:13 |
| wgrant | OpenID SReg doesn't make much sense here, since you get all your identity information from Launchpad. | 02:13 |
| lifeless | you'll have that problem with third party openid and browser id too | 02:13 |
| wgrant | You only care about OpenID for auth. | 02:13 |
| lifeless | so I still think forking django-openid-auth is a poor idea | 02:14 |
| mhall119 | well we'll have to change it, whether upstream or in a fork | 02:14 |
| lifeless | indeed | 02:14 |
| mhall119 | an either add launchpad-specific code to it, or add hooks that will let us call external code when creating a new user record in Django | 02:15 |
| wgrant | mhall119: Sounds like you want to split out django-openid-auth's SReg stuff into a separate module that you can replace | 02:15 |
| wgrant | If it's not already hookable. | 02:15 |
| mhall119 | it's not, IIRC | 02:16 |
| lifeless | mhall119: hooks :) | 02:16 |
| mhall119 | fun | 02:18 |
| windbuntu | nasty bug in brasero in 12.04 ubuntu | 04:32 |
| StevenK | This is not the place to ask about that. | 04:33 |
| === vibhav is now known as Guest59295 | ||
| Daviey | oopstastic, OOPS-fc6e9ba04bf0ad1262968049d512d137 | 08:15 |
| ubot5 | https://lp-oops.canonical.com/oops.py/?oopsid=fc6e9ba04bf0ad1262968049d512d137 | 08:15 |
| Daviey | status: Doomed | 08:17 |
| lifeless | Daviey: seems usually pretty well behaved | 08:23 |
| lifeless | Daviey: 99% under 2.94s - try again ? | 08:23 |
| Daviey | lifeless: yep, worked now.. but did fail 5 refreshes spread over about 1 minute | 08:25 |
| lifeless | Daviey: first 2 can be different slaves easily enough | 08:25 |
| Daviey | right | 08:27 |
| Daviey | i'd just never seen a timeout when going to +related-software before | 08:27 |
| lifeless | it runs a slowish query 4 times | 08:32 |
| lifeless | maybe more on success | 08:32 |
| lifeless | slow == 285ms | 08:32 |
| lifeless | Daviey: oh, hah, s I know why it timed out for you :) | 08:32 |
| lifeless | you, my friend, are the 1% | 08:33 |
| soren | Daviey: What, really? I've seen that loads of times. | 08:33 |
| lifeless | Daviey: https://lists.launchpad.net/launchpad-dev/msg09410.html | 08:33 |
| lifeless | Daviey: this page works well most of the time, so its now capped at 5s | 08:36 |
| lifeless | Daviey: which means when it doesn't work well, it will oops | 08:36 |
| soren | Daviey: I can't remember when I've last seen my own related-software page and I dont think I've uploaded that many packages, really. People like cjwatson or doko are far, far worse off. | 08:37 |
| lifeless | soren: 29 / 3 Person:+related-software | 08:38 |
| lifeless | time outs per day | 08:38 |
| soren | "29 out of 3"? :-/ | 08:39 |
| lifeless | no | 08:39 |
| lifeless | 29 hard, 3 soft | 08:39 |
| soren | Ah. | 08:39 |
| lifeless | a soft logs data for us to analyse | 08:39 |
| lifeless | a hard gets cut off to free resources | 08:39 |
| soren | Soft timeouts are just logged, hard ones are seen by the requestor? | 08:39 |
| soren | Gotcha. | 08:39 |
| lifeless | soren: it gets 6.5K hits per day | 08:39 |
| lifeless | soren: so 29 timeouts out of 6500 | 08:40 |
| lifeless | or 1 in 200 | 08:40 |
| === danhg_ is now known as danhg | ||
| === Guest59295 is now known as vibhav | ||
| soren | lifeless: No doubt it works for most people. | 08:47 |
| lifeless | indeed | 08:50 |
| lifeless | asymmetric access patterns like this are common in LP | 08:50 |
| lifeless | it will now be more visible as an issue :) | 08:50 |
| soren | I sometimes wish there was a special im_willing_to_wait_for_this_for_however_long_it_takes paramater. | 08:54 |
| soren | Giving yourself incentive to speed things up (a noble goal for sure) is great, but as a user, slow access is often times better than no access at all. | 08:55 |
| === czajkowski changed the topic of #launchpad to: https://launchpad.net/ | Help contact: czajkowski | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support: https://answers.launchpad.net/launchpad | For packaging help: join #ubuntu-packaging | ||
| === JanC_ is now known as JanC | ||
| === Pendulum_ is now known as Pendulum | ||
| === Guest55695 is now known as Pici | ||
| TheLordOfTime | permissions question. if a person is on bug control for a specific ubuntu package, does that person get access to the private security bugs for said package? | 14:30 |
| TheLordOfTime | czajkowski: would you happen to know? | 14:33 |
| czajkowski | TheLordOfTime: just doing something brb | 14:33 |
| TheLordOfTime | mhm | 14:33 |
| czajkowski | TheLordOfTime: so have you seen http://blog.launchpad.net/general/how-bug-information-types-work-with-privacy | 14:34 |
| czajkowski | TheLordOfTime: what is the actual issue ? | 14:34 |
| TheLordOfTime | czajkowski: question posed to a bugcontrol admin (jorge castro) in regards to an individual package, and whether a bug control member for that specific package can see private bugs related to said package. | 14:35 |
| TheLordOfTime | since jorge didn't know, he suggested i ask here :P | 14:35 |
| czajkowski | sinzui: could you elaboate more here please? | 14:37 |
| sinzui | TheLordOfTime, at this moment, ANY subscribed user/team can see and change the bug | 14:40 |
| TheLordOfTime | does this include security/private bugs on a package? | 14:41 |
| TheLordOfTime | i.e. things that are newly reported security bugs against said package get marked as private automatically (from what i've seen thus far) | 14:41 |
| sinzui | TheLordOfTime, for Ubuntu, only ubuntu-security gets automatic access (via automatic subscription) to embargoed security bugs. Ubuntu has a very specific rule that no other person/team gets automatic access. Lp has a hack to ensure that it does not work like all other projects | 14:42 |
| TheLordOfTime | thought so, that was the question. thanks. | 14:43 |
| czajkowski | sinzui: thanks | 14:43 |
| czajkowski | sinzui: I know how to make a project private and with that the code and bugs, | 14:46 |
| czajkowski | to do the inverse unticking the bugs and private and changing the licence? | 14:46 |
| czajkowski | how do I sort out the code? | 14:46 |
| sinzui | czajkowski, I do not understand | 14:48 |
| sinzui | czajkowski, are you saying you want to open the code and bugs? | 14:48 |
| czajkowski | sinzui: yes | 14:49 |
| czajkowski | sinzui: am trying to work this out to help arielweil | 14:49 |
| sinzui | czajkowski, only the project maintainer can change the project license, so nothing happens when you untick private-by-default bugs, and I am not even sure how to make code public. | 14:50 |
| czajkowski | sinzui: aye we've never done it going the other way | 14:50 |
| sinzui | czajkowski, with code, first the default-private needs to be removed (can it?). | 14:51 |
| arielweil | czajkowski, sinzui: the goal is not to lose all of our history, and also to keep the current project name, url, etc. Ideally everything will be public, and we'll switch a (very) few bugs and branches private to protect customer privacy. | 14:52 |
| czajkowski | sinzui: never done it before, not seen a request like this | 14:52 |
| sinzui | czajkowski, changing the default rules does not change existing private bugs and branch... | 14:52 |
| sinzui | Once the default rules are changed... | 14:52 |
| sinzui | The project maintainers push the public version of their series branches. They then delete the private versions, then finish by linking the public branches to the series | 14:53 |
| sinzui | czajkowski, Users cannot change the existing branches, and maybe they do not want to since the branch history might contain information that should not be public | 14:54 |
| czajkowski | arielweil: this making sense to you for your deadline to make this happen | 14:55 |
| sinzui | czajkowski, when Lp went public, it was decide that all history was okay to be public, but our profanity might offend the faint of heart, so we pushed up a branch with no bad word. | 14:55 |
| czajkowski | nods | 14:56 |
| * czajkowski is in a meeting for the next while so will come back if needed to this | 14:56 | |
| arielweil | sinzui, czajkowski: so as a maintainer of our project I can take the project, as well as individual branches and bugs public at my discretion. Anything new I'll have the option of making public/private? | 14:56 |
| arielweil | sinzui: (since czajkowski's away), is that about right? | 14:56 |
| sinzui | arielweil, czajkowski a webops can use super powers to make branch public once the "forbidden" rule is removed | 14:57 |
| sinzui | arielweil, Lp's code management is unusable. no user can change a branch's visibility between public/private | 14:58 |
| * sinzui will fix this in next month | 14:58 | |
| arielweil | sinzui: ah, so email to whom to get the process underway? Or should I time this appropriately and DM you via irc? | 14:59 |
| jf_ | hi, how to get help on bug #869022 ? I can't branch my project ! | 14:59 |
| ubot5 | Launchpad bug 869022 in Bazaar "ValueError: Something wrong with: cp_off = 2314752, cp_size = 3 source_size = 494614, size = 89493" [Undecided,Confirmed] https://launchpad.net/bugs/869022 | 14:59 |
| sinzui | arielweil, czajkowski can change the default rule, then ask the webops to make the series branches public. Other branches will remain private forever. You can delete them then push a new version of the branch, which will be public | 15:00 |
| arielweil | sinzui: thanks! | 15:01 |
| sinzui | jam, jelmer can either you you help jf_? | 15:05 |
| czajkowski | arielweil: are you ok with me changing the default rule today or do you want to wait till tomorrow ? | 15:48 |
| arielwei_ | czajkowski: sorry, you can change the default rule today | 16:21 |
| czajkowski | ok will do | 16:26 |
| czajkowski | arielwei_: can you pm me the project name please | 16:26 |
| colon_D | Anyone else seeing this error when uploading to launchpad? Unhandled exception processing upload: [Errno 13] Permission denied: '/tmp/tmpmMsATk/trafficserver-3.1.3/debian/copyright | 17:27 |
| penguin42 | hi, I'm getting a reliable 'Processing Failed' when clicking on a 'Download diff' link in a patch of mine from the patch on here https://code.launchpad.net/~ubuntu-treblig/ubuntu/precise/procps/fix-for-bug-965341 | 17:48 |
| geser | colon_D: which permission does debian/copyright have when you unpack your source package? | 17:54 |
| nwilliams | sinzui: ping | 17:55 |
| sinzui | hi | 17:56 |
| nwilliams | sinzui: Hi! I'm a developer on Persistit that arielwei_ has been bugging you about. Specifics I can assist with? | 17:56 |
| sinzui | nwilliams, akiban-persistit is becoming public and need to be reconfigured to complete this | 17:59 |
| sinzui | nwilliams, There are two options to making the code public. The fastest route is to ask a WebOps to make branch linked to https://launchpad.net/akiban-persistit/trunk public. If the commit history cannot be made public, then I suggest deleting the current branch, then push up a new branch with just the files from the tree to reset the revision to 1. | 18:02 |
| sinzui | nwilliams, Once the base branch is public, new branches that are pushed to Lp will also be public. Branches that are already private remain private because their history or content cannot automatically be concluded to be public | 18:03 |
| nwilliams | sinzui: If I have a branch that was constructed by fast-export, fast-import-filter, and fast-import (to get rid of non-public bits), will pushing that into /trunk do it? Or does it need to be a branch new branch with rev1? | 18:03 |
| colon_D | geser: 644, root:root | 18:04 |
| sinzui | nwilliams, the rev number is not important, but you do need to delete the existing branch...the identity information in the branch are what Lp sees to know it is private. When you ask Lp to delete the branch, it knows to also remove the privacy rule for it | 18:05 |
| nwilliams | sinzui: If I attempt to delete that branch, I get this error: "This branch cannot be deleted as it has 265 branches sharing revisions. " | 18:08 |
| geser | colon_D: looks ok, if trafficserver-3.1.3 and trafficserver-3.1.3/debian have also sane permissions, then I've no idea and you have to wait on someone with access to that tmp-directory to check | 18:08 |
| colon_D | geser: thanks. I have tried uploading a few times and have gotten the same error since friday | 18:10 |
| === nwilliams_ is now known as nwilliams | ||
| sinzui | nwilliams, okay, just unlink the branch, the push and link the new branch. These at least tells us how many branches will remain private | 18:17 |
| === zaki[] is now known as zaki | ||
| nwilliams | sinzui: arielwei_: Looks like that did the trick. Thanks! | 18:22 |
| arielwei_ | nwilliams, sinzui: huzzah! | 18:23 |
| dlynch | Hi everyone, I have a project on launchpad and the automatic import of translations seems to have stopped. Is this the right place to see how I can fix it? | 18:32 |
| lifeless | sure | 18:34 |
| lifeless | I suspect our friendly support person has finished for their day, so you might want to file a ticket at https://answers.launchpad.net/launchpad/ | 18:34 |
| dlynch | ok thanks lifeless :) | 18:36 |
| alkisg | While trying to delete our "sch-devs" team: "This team cannot be deleted until its mailing list is first deactivated, then purged after the deactivation is confirmed." | 19:09 |
| alkisg | I deactivated the mailing list, but I see no option to delete it, what should I do? | 19:10 |
| czajkowski | alkisg: hi if you file a question https://answers.launchpad.net/launchpad/ | 19:11 |
| czajkowski | alkisg: it'll get looked at | 19:11 |
| alkisg | Thank you czajkowski, doing so right now... | 19:11 |
| === czajkowski changed the topic of #launchpad to: https://launchpad.net/ | Help contact: | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support: https://answers.launchpad.net/launchpad | For packaging help: join #ubuntu-packaging | ||
| alkisg | czajkowski: https://answers.launchpad.net/launchpad/+question/198806 - thank you :) | 19:14 |
| czajkowski | alkisg: done | 19:16 |
| alkisg | Cool, ty | 19:17 |
| alkisg | czajkowski: I had set "ts.sch.gr" as our project (sch-scripts) Maintainer and Driver, but unfortunately lp:~sch-devs/sch-scripts now went to https://code.launchpad.net/~registry/sch-scripts/trunk... Can it be moved to ~ts.sch.gr ? | 19:23 |
| alkisg | (or deleted, we have the branch locally and can push it again) | 19:23 |
| alkisg | ...although then we'd lose the bug history :( | 19:23 |
| Zoohouse | Hello everyone | 19:24 |
| sinzui | alkisg, looks like a team was deleted, which transferred the branch to ~registry so that the project would keep working | 19:26 |
| alkisg | sinzui: true, but I thought that setting the Maintainer and Driver to a new team before deleting the team that owned sch-scripts would be enough, unfortunately it wasn't, and I don't know what I should have done to avoid that | 19:27 |
| sinzui | alkisg, make me a member of https://launchpad.net/~ts.sch.gr then I will change the branch owner to the team. I can leave the team when the branch is transferred | 19:27 |
| alkisg | Thanks, doing so... | 19:27 |
| alkisg | sinzui: done | 19:27 |
| Zoohouse | If I set a second branch (0.02-dev) as the current development branch, does that mean when I run bzr push it will merge my changes with the 0.02-dev branch? | 19:28 |
| sinzui | alkisg, Done | 19:30 |
| alkisg | Thank you both very much, and sorry for the trouble :) | 19:30 |
| sinzui | Zoohouse, No. Changing the focus of development/series branch does not change the existing branches. They continue to be stacked on their previous branches. New branches will be stacked on the new branch | 19:33 |
| sinzui | Zoohouse, If you delete the branch, then repush, it will be restacked on the new focus of development | 19:34 |
| Zoohouse | sinzui: At the moment I only have 1 branch (0.01-dev) in the 0.01 series. Right now all I do is bzr push lp:<project> and updates 0.01-dev. Would I have to do bzr push lp:<project>/<branch>? | 19:35 |
| Zoohouse | Would I have to do bzr push lp:<project>/<branch> to get a new branch is what I meant to ask | 19:36 |
| sinzui | Zoohouse, exactly | 19:36 |
| Zoohouse | ah | 19:36 |
| Zoohouse | Is it normal to delete old branches? Or do you keep them? | 19:36 |
| sinzui | Zoohouse, Branches are rarely deleted. Lp detects one one branch merges into another and then updates the status. | 19:38 |
| sinzui | Merged branches are hidden from the default page views, but you can always search for them if you want to see the old branch | 19:38 |
| Zoohouse | sinzui: Ok let me see if I understand this. There's one branch for development, branch 1 for example, that branch matures and becomes a release. Then that same branch changes name to 2 or whatever and continues until it matures to a release and so on | 19:40 |
| Zoohouse | That's how it works? | 19:42 |
| sinzui | Zoohouse, that is one workflow. It is not common. | 19:42 |
| sinzui | Zoohouse, Most project have one branch for trunk. The make releases from trunk. If they want to support an old release, create a series for it, and branch/clone/fork trunk at that point to maintain a separate branch | 19:44 |
| Zoohouse | sinzui: do the help pages have different workflow examples? I'm looking but haven't found it yet | 19:45 |
| sinzui | Zoohouse, yes | 19:45 |
| * sinzui looks | 19:45 | |
| === bulldog98_ is now known as bulldog98 | ||
| sinzui | Zoohouse, https://help.launchpad.net/Projects/SeriesMilestonesReleases | 19:46 |
| Zoohouse | sinzui: This is the closest I've seen to a workflow https://help.launchpad.net/Code/QuickStart#Set_your_project.27s_trunk_branch | 19:46 |
| Zoohouse | Ah thanks | 19:46 |
| sinzui | Zoohouse, Since changing the branch linked to a series, does not update all the existing branches, it it better to minimise the work to rebase branches by using the trailing working flow | 19:48 |
| dds_ | hi, I'm getting a PPA upload rejection claiming that the file "opencryptoki_2.4.2-1~lucid1.debian.tar.gz already exists in Goobuntu Laptop Testing" (https://launchpad.net/~goobuntu-team/+archive/glaptop-testing/), but I deleted that file over an hour ago and continue to get this rejection message. | 19:52 |
| dds_ | looking at the above link, you won't find any ~lucid1 files | 19:53 |
| === dds_ is now known as dds | ||
| Zoohouse | sinzui: wonderful, thank you for your help | 20:00 |
| sinzui | np | 20:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!