[00:00] <jono_> well python-snippets is not for docs, it is just a library that aggregates examples
[00:00] <lifeless> jono_: the second link is probably more the sort of thing you're looking f or
[00:00] <lifeless> that page is full of examples
[00:00] <jono_> so if you are a developer you have a regularly growing library of examples to lean on
[00:00] <jono_> sure, and it would be great to put those examples in python-snippets
[00:01] <lifeless> jono_: I think it would be better to have acire pull them in automatically.
[00:01] <lifeless> jono_: rather than duplicating content, which can then go stale.
[00:01] <lifeless> jono_: I can file a bug for you, if you like.
[00:01] <jono_> lifeless, how could that work for any project?
[00:01] <jono_> lifeless, write a patch, that would be better ;-)
[00:01] <lifeless> jono_: I don't know, I'm not an Acire developer ;)
[00:01] <jono_> I don't think it would be possible in a generic
[00:02] <jono_> way
[00:02] <jono_> if you don't want to contribute the examples, thats fine
[00:02] <jono_> I just think it will help people get started quicker
[00:02] <lifeless> jono_: uhm, I don't think we're communicating effectively
[00:02] <lifeless> I know of the acire project - its a nice idea.
[00:02] <jono_> right
[00:03] <lifeless> and you're welcome to take the examples we've written already. I think that that creates a problem for acire though
[00:03] <lifeless> the problem is that you have to sync on an ongoing basis
[00:03] <lifeless> or the examples will stop working
[00:03] <lifeless> it also means that patches to the bzrlib docs to improve this may end up going to acire instead
[00:03] <lifeless> I don't think either of those things are desirable.
[00:04] <jono_> lifeless, I agree with the problem, I just don't know what the solution is :)
[00:04] <jono_> I suspect that if python-snippets gains momentum, people will fix the examples
[00:04] <jono_> that has happened so far
[00:04] <lifeless> so, if you agree with the problem, I can file a bug. That records the problem and perhaps someone with an interest can implement a solution.
[00:04] <jono_> I would love a way to pull in snippets automatically tbh
[00:04] <jono_> sure :)
[00:04] <lifeless> I can suggest techniques to do pull-ins for you
[00:05] <lifeless> its not conceptually hard
[00:05] <jono_> cool
[00:05] <jono_> :)
[00:05] <lifeless> lp:acire ?
[00:05] <jono_> yep
[00:16] <jono_> lifeless, are there docs for the UI bzrlib API?
[00:16] <lifeless> http://people.canonical.com/~mwh/bzrlibapi/bzrlib.ui.html
[00:16] <lifeless> http://people.canonical.com/~mwh/bzrlibapi/bzrlib.ui.UIFactory.html
[00:17] <jono_> :)
[00:18] <lifeless> they're not perfect, but pretty good we think
[00:18] <lifeless> please do let use know (by bugs) of any questions that aren't answered by the docstrings
[00:19] <jono_> lifeless, I am still not entirely clear what this does
[00:20] <jono_> as a bzr n00b
[00:20] <jono_> bzrlib n00b, that is
[00:20] <lifeless> ok, so thats bug one
[00:20] <lifeless> I'll file it
[00:20] <jono_> lol
[00:20] <jono_> :)
[00:23] <lifeless> ok filed
[00:23] <lifeless> bzrlib.ui.ui_factory is an instance of UIFactory (a subclass thereof)
[00:23] <lifeless> it is used to get hold of progress bars
[00:24] <lifeless> to prompt for passwords
[00:24] <lifeless> to geta file-like object that diffs and other things can be written to
[00:31] <jono_> lifeless, right, so could I use that to branch async so it doesnt block my GUI?
[00:32] <lifeless> jono_: you would run the bzr commands in a thread (pick one thread, don't move objects between threads). And then your UI factory can feed events back to your UI, yes.
[00:36] <PabloRubianes> hi i am having some troubles with Launchpad
[00:36] <PabloRubianes> I am trying to find someone to give me a hand
[00:37] <jono_> lifeless, cool
[00:40] <thumper> PabloRubianes: what type of troubles?
[00:40] <PabloRubianes> I am trying to add an email account and give me oops...
[00:41] <thumper> PabloRubianes: which account, which email and can you give me the oops number?
[00:41] <thumper> PabloRubianes: priv msg is fine
[00:41] <PabloRubianes> yes a sec
[00:47] <thumper> PabloRubianes: the tool that we use to look at the oopses is having issues of its own
[00:47] <thumper> PabloRubianes: have you asked a question on answers.launchpad.net/launchpad ?
[00:47] <thumper> PabloRubianes: that will probably be the best place to track it
[00:47] <thumper> and I can make sure someone looks at it as soon as they can
[00:48] <thumper> most of the devs in this area are in UTC-5 .. UTC-8
[00:48] <PabloRubianes> no. I just got that and the came here. But I will ask there if you say so.
[00:48] <thumper> PabloRubianes: probably best right now as I can't do anything
[00:48] <PabloRubianes> thumper: Thanks for your time
[00:49] <thumper> np
[00:49] <thumper> PabloRubianes: did you try the work around?
[00:49] <thumper> https://bugs.edge.launchpad.net/launchpad/+bug/431845/comments/1
[00:51] <PabloRubianes> the thing is that the email address has 30 minutes till i made it...
[00:51] <PabloRubianes> but i will try that
[00:52] <thumper> PabloRubianes: ah
[00:52] <thumper> PabloRubianes: so you've not used it before?
[00:54] <PabloRubianes> no
[00:56] <lifeless> wgrant: jono_: bzrlib.branch.Branch.open does directory service lookup, I think.
[00:56] <lifeless> I suspect the problem was not loading plugins at all
[00:56] <thumper> PabloRubianes: probably a different bug then
[00:57] <thumper> PabloRubianes: make sure you say that in the question (or add a comment saying that the email address is new and unused with LP or ubuntu in any way)
[00:57] <PabloRubianes> i think the work around gave me another empthy account
[00:58] <PabloRubianes> I think someone had that mail...
[00:58] <thumper> PabloRubianes: what account did it give you?
[00:58] <PabloRubianes> now i have it or something weird
[00:58] <thumper> PabloRubianes: did you use the email address for ubuntu forums?
[00:58] <thumper> PabloRubianes: or shipit?
[00:59] <PabloRubianes> no i use openID for thouse
[00:59] <thumper> open id from where?
[01:01] <PabloRubianes> from my lauchpad account
[01:03] <PabloRubianes> I will merge two and that's it..
[01:03] <thumper> ok
[01:05] <wgrant> lifeless: Ah, true.
[01:06] <fmarier> i'm a little confused by the team "reported bugs" page. i would expect that page to list all of the bugs that were reported by team members, but it doesn't seem to do that...
[01:06] <wgrant> fmarier: That probably isn't meant to exist, but your expectation makes sense.
[01:07] <fmarier> you mean the page isn't meant to be there at all?
[01:07] <wgrant> I suspect that is the case.
[01:07] <wgrant> (teams are really people in Launchpad, so they inherit stuff)
[01:07] <fmarier> ah bummer... i was hoping i'd be able to use that to find out what bugs a certain group of people had reported
[01:08] <wgrant> If you report a bug, you probably will be able to :)
[01:08] <wgrant> It's not hard to make that work.
[01:08] <fmarier> cool, i'll do that right now :)
[01:09] <fmarier> are there really just 3 open bugs on launchpad itself?
[01:09] <PabloRubianes> thumper: done... thanks again... I will comment the bug report
[01:10] <wgrant> fmarier: Launchpad's current usage of Launchpad projects is a bit strange. There are lots of separate projects, all the launchpad-project project group.
[01:10] <wgrant> fmarier: malone is the name of the bugs component.
[01:10] <fmarier> ah so i should be filing a bugs against that then
[01:10] <wgrant> 'launchpad' is the bugs that haven't yet been assigned to the appropriate component.
[01:11] <fmarier> or should i let the bug triager assign it to the right component?
[01:11] <wgrant> It's fine to file against 'launchpad' -- somebody will reassign it later on. But it'll probably be quicker if you file against the specific project to start with, yes.
[01:16] <fmarier> ah just found an existing bug for it from 2008 (#307572)
[01:18] <wgrant> Bug #307572
[01:19] <wgrant> fmarier: You might want to click the "Does this bug affect you?" thingy.
[01:20] <fmarier> wgrant, good point. done.
[01:35] <yofel> hi, where can I someone that can kill  a ppa build? My build on thorium seems to be stuck in an endless loop https://edge.launchpad.net/builders/thorium
[01:35] <yofel> *I find someone
[01:36] <yofel> (how about adding an 'abort' button somewhere?)
[01:38] <wgrant> yofel: Is it actually in an infinite loop, or is it not doing anything at all?
[01:39] <persia> yofel: For the abort button, file a bug.  That's likely tricky, but potentially possible.
[01:39] <wgrant> It's likely that the builder has died somehow.
[01:39] <wgrant> I have an abort backend mostly working.
[01:39] <persia> Cool!
[01:39] <wgrant> But it's unclear if it would work in this particular circumstance.
[01:39] <wgrant> (it depends on how badly the builder is wedged)
[01:40] <yofel> persia: will do
[01:41] <yofel> wgrant: I *think* the buildlog still gets updated but as the only thing it shows are inkscape warnings I can't really tell
[01:44] <wgrant> yofel: Ah, you're right, it is updating.
[01:44] <wgrant> So the builder is still alive.
[01:46] <thumper> fmarier: hi
[01:47] <thumper> fmarier: how are you enjoying launchpad?
[01:47] <thumper> fmarier: notice the subtle positive slant on that question :)
[01:55] <yofel> wgrant: can you kill it then, the build shouldn't take 8h...
[01:55] <wgrant> yofel: I'm just a user.
[01:56] <yofel> ok, should I post a question on launchpad or do you think someone will kill the build at some point?
[01:59] <wgrant> Somebody should kill it at some point.
[02:01] <yofel> ok, thx :)
[02:13] <fmarier> thumper, nice marketing work there :)
[02:14] <fmarier> actually launchpad is great for us, it's the most usable bug tracker i've ever seen
[02:14] <fmarier>  or used
[02:17] <fmarier> now if we could get our old bugs imported (Question #93120), we could finalise the move to Launchpad and decommission our old tracker
[02:17] <fmarier> thumper, notice the subtle prod on that last comment ;-)
[02:17] <thumper> :)
[02:18]  * thumper looks at the question
[02:18] <fmarier> one thing that would be nice with these imports is if there was a testing script we could use to "validate" our XML export before we send it to you guys
[02:19] <fmarier> but i'm guessing that perhaps the "testing script" currently involves trying to import it into launchpad staging...
[02:19] <thumper> :)
[02:19] <mwhudson> fmarier: launchpad running in ec2, i think, but yes
[02:24] <thumper> fmarier: I'll forward that request on to the right person :)
[02:25] <wgrant> It first gets tested on EC2 (or you can run it locally, if you want).
[02:25] <wgrant> Then it gets tested on staging, to ensure that it doesn't conflict with production data.
[02:26] <thumper> fmarier: request passed on, should get some form of response within a day or so
[02:26] <fmarier> thumper, cool, thanks!
[02:26] <thumper> fmarier: np
[06:31] <doctormo> OOPS-1521S65 - Looks like logging in on staging is broken.
[06:31] <doctormo> I was wondering how login.launchpad.net was being translated.
[06:33] <wgrant> doctormo: A warning about the OpenID stuff: Launchpad will probably start using login.ubuntu.com soon, so your code will probably break.
[06:35] <doctormo> wgrant: Already does break, is broken, uses edge by default.
[06:38] <wgrant> doctormo: login.ubuntu.com != login.launchpad.net
[06:38] <wgrant> The latter is used at the moment.
[06:40] <doctormo> wgrant: Will you still be sending the html form when you go to https://launchpad.net/+login ?
[06:40] <doctormo> wgrant: Because my code is moving towards detecting that form and sending it on.
[06:40] <doctormo> Where ever it points to
[06:41] <wgrant> doctormo: The edge behaviour is what will be on production in a few days.
[06:41] <doctormo> wgrant: Is openid being phaised out in favour of SSO?
[06:42] <wgrant> SSO uses OpenID.
[06:42] <wgrant> LP is becoming an OpenID consumer.
[06:42] <wgrant> (at the moment restricted to one provider -- now login.launchpad.net, but soon login.ubuntu.com, and hopefully eventually anything at all)
[06:42] <doctormo> I see
[06:43] <doctormo> Sounds like a good way forward
[06:43] <doctormo> And makes it fairly imperative that the oauth stuff has a desktop client.
[06:45] <wgrant> OpenID makes a desktop client a little more difficult.
[06:45] <wgrant> I don't really see why requiring a browser to authorize access to a webapp is a huge problem.
[06:47] <persia> Because one may not need a browser to use the LP API
[06:47] <doctormo> wgrant: Really bad security, terrible workflow and it doesn't work on machines without a gui.
[06:47] <persia> doctormo: Why bad security?
[06:48] <doctormo> persia: Web browsers can display anything, from anywhere, made to look like it's authentic, it's code base is large and hard to protect from all attacks.
[06:48] <doctormo> Better to have smaller, dedicated authentication tools
[06:49] <wgrant> A generic OpenID authentication solution without a browser borders on impossibility.
[06:50] <doctormo> wgrant: It does, we may just have to assume the authentication service and let the user configure it directly in a conf file if they're using something different
[06:51] <persia> Is there a reason that one can't use some http client library to do it?
[06:51] <wgrant> persia: There is no common interface for authentication to OpenID providers.
[06:51] <doctormo> persia: That's what I am doing with ground control, but it's not lp policy to allow such things.
[06:51] <wgrant> Against, but not to.
[06:51] <poolie1> hey
[06:52] <persia> wgrant: Aha.  That makes sense now.
[06:52] <doctormo> persia: I figured I could make it more robust by using a find a form and find fields logic that could make educated guesses.
[06:52] <persia> But I'd still like to see a liboath-authenticate: perhaps that needs work with the various providers (and the spec).
[06:53] <persia> doctormo: I think that's the wrong way to go about it, personally.
[06:53] <doctormo> persia: I'm happy to do something different
[06:54] <wgrant> persia: OAuth, or OpenID? They're separate things.
[06:54] <persia> doctormo: The path I'd recommend is a long one: to work with the spec to create a defined interface for authentication *to* providers, and work with the providers to implement it.
[06:54] <doctormo> persia: Of course, that's the right way to do outh as a desktop service.
[06:55] <wgrant> That's very difficult, as providers can choose whatever authentication mechanism they wish: SSL certificates, usernames and passwords, physical key generators, that sort of thing.
[06:55] <doctormo> wgrant: That's why you nail down a spec for defining such things.
[06:55] <persia> No, nailing it down would be bad.
[06:55] <wgrant> Very bad.
[06:56] <wgrant> Consumers aren't meant to care.
[06:56] <wgrant> And nailing it down would remove the abstraction that OpenID provides.
[06:56] <wgrant> Also, you're only meant to give your credentials to your provider through an application that you trust.
[06:56] <wgrant> Proxying that is a phishing attempt.
[06:56] <doctormo> wgrant: Only the abstract of method, not the abstract of authorisation as a seperated service.
[06:57] <doctormo> wgrant: That... gives me an idea.
[06:58] <doctormo> wgrant: Will launchpad accounts be able to be logged in via multiple openid logins or just the one?
[06:58] <wgrant> doctormo: That is undecided, TTBOMK.
[06:58] <persia> Just to make sure I'm reading the right specs, is it correct to say that LP API clients use oauth to connect to LP, and LP will use OpenID to authorise accounts?
[06:58] <wgrant> I would hope the former, though.
[06:58] <wgrant> persia: Correct.
[06:58] <wgrant> When you start an API client for the first time, it will request an OAuth token from LP.
[06:59] <wgrant> LP will give it a URL that the user must visit to authorise the token.
[06:59] <persia> OK.  So the client (e.g. groundcontrol) uses oauth, and if it gets a failure, needs to request that the user log into launchpad.
[06:59] <wgrant> This is normally in a browser, which has an existing user session with LP.
[06:59] <persia> wgrant: But presumably that's a bug in LP, as it cannot know in advance how the OpenID provider authenticates, no?
[07:00] <doctormo> wgrant: If the former, then there is nothing to stop us having our own desktop openid authentication service. Something with a well defined spec, even using ssh or gpg keys instead of passwords.
[07:00] <persia> doctormo: The main limiting factor there is in having a server to handle the requests (infrastructure).
[07:00] <wgrant> persia: An OpenID consumer redirects to the provider.
[07:01]  * persia reads specs harder
[07:01] <wgrant> persia: It makes no assumptions about the provider's authentication mechanisms; it just redirects there with a token, and the consumer redirects back with a sort of signed copy of the token.
[07:01] <doctormo> persia: nothing to stop us hooking that to ubuntu-one
[07:01] <wgrant> doctormo: That could be what login.ubuntu.com is.
[07:02] <wgrant> (I personally would want to unlink the login.ubuntu.com ID from my Launchpad account, because I do not trust it, so I wouldn't want applications locked to it, but that's another story)
[07:02] <doctormo> You don't trust the canonical sso?
[07:02] <wgrant> No.
[07:03] <doctormo> The why are we moving towards using it by default?
[07:03] <wgrant> I personally do not trust it. I am no Canonical person.
[07:04] <persia> doctormo: Consider that the move to make LP an openID consumer doesn't change the authentication path.  That LP logins happen to currently be insecure is entirely separate.
[07:04] <persia> Err..  well, it does change the path, but not the custodian of the path.
[07:05] <doctormo> wgrant: Right, but surely your opinion on the matter has some weight in the discussion
[07:07]  * doctormo feels that ground control is a project before it's time... ready to go but failed by it's cloud counterpart.
[07:08] <persia> Well, no.
[07:09] <persia> The trick is making authentication work generally.
[07:11] <doctormo> persia: I have no great confidence in the future design of it, made as it is to be elegant but missing some key considerations.
[07:12] <persia> doctormo: Hrm?  It's just code.  We can make it do anything.  The hard part is figuring out what it should do.
[07:13] <doctormo> persia: The openid stuff is closed source
[07:14] <persia> *which* "openid stuff"?
[07:15] <doctormo> persia: login.ubuntu.com and login.launchpad.net
[07:16] <doctormo> http://divajutta.com/doctormo/gcweb/ <- This is a website Bret Alton is putting together, what do you two think?
[07:16] <persia> doctormo: That a specific implementation is closed source is irrelevant.
[07:18] <doctormo> persia: Isn't not so long as launchpad is tied directly into it.
[07:19] <persia> doctormo: So, the problem is that one wants to have a client that authenticates to LP in a sane way.
[07:19] <persia> OAuth already provides useful information about authentication failures.
[07:19] <persia> I'm sill reading the OpenID spec, but I expect to find something useful there.
[07:20] <persia> Based on that spec, it should be possible to identify the correct behaviour for the client application.
[07:20] <persia> And any way in which LP doesn't meet that behaviour is likely a bug in LP.
[07:30] <doctormo> persia: With a tie to openid, the desktop would have to have a way of getting an oauth token by using some other method of authentication.
[07:31] <persia> No.
[07:31] <doctormo> Or would have to be tied to a specific openid system, not optional
[07:31] <persia> The desktop client needs to have some way to richly inform the user that they need to authenticate, and help them to do so.
[07:31] <persia> This depends on the volume of information available when the authentication failure is received.
[07:31] <doctormo> persia: Yes, they call that the web browser
[07:32] <persia> Not if my OpenID provider uses some other authentication method.
[07:37] <doctormo> persia: True, but there is not the tech for it currently, for most websites consuming that openid will fail.
[07:38] <wgrant> doctormo: Why would they?
[07:38] <wgrant> doctormo: Websites don't care -- they redirect to the provider.
[07:38]  * persia can't imagine why
[07:38] <wgrant> The provider is free to do whatever they want.
[07:39] <doctormo> wgrant: How do you redirect, if your not using a brwoser int he first place?
[07:39] <lifeless> wasn't openid/oauth was designed with the idea that the browser was the 'trusted computing base' for the user
[07:40] <lifeless> so users won't put their password into a strange app ?
[07:40] <wgrant> OAuth not so much, but OpenID was.
[07:40] <wgrant> And Launchpad's OAuth authorisation implementation was
[07:40] <lifeless> doctormo: HTTP != a browser.
[07:40] <doctormo> lifeless: OAuth might have been, but the OAuth developers backtracked after security failures.
[07:43] <doctormo> Shame we can't just grab webkit, rewrite the cookie implimentation and forge a system wide auth service. But it's too late for that, we got a bunch of legacy to deal with.
[07:47] <persia> OK.  So OpenID returns openid.user_setup_url when it fails.  That should be passed to the oauth failure.
[07:47] <persia> There is no documentation that indicates what that URL should contain.
[07:48] <persia> So, the next step is to work with the OpenID folk to make sure that openid.user_setup_url is guaranteed to be machine-readable.  Desktop clients can then pull and use this to provide rich information to users.
[08:44] <thumper> what's that damn command to list processes listening on ports?
[08:44] <thumper> netstat
[08:46] <lifeless> amongst other things
[08:51] <thumper> lifeless: any idea what kicks off /usr/bin/python /usr/lib/desktopcouch/desktopcouch-service ?
[08:53] <lifeless> thumper: dbus activation
[08:53] <persia> thumper: Have you looked in /etc/init and /etc/init.d/ ?
[08:53] <lifeless> thumper: gwibber will do it
[08:53] <thumper> arse
[08:53] <lifeless> thumper: as will ubuntu one
[08:53] <thumper> it was listening on 58000
[08:53] <lifeless> bindwiid
[08:53] <lifeless> bindwood
[08:53] <lifeless> and potentially other things
[08:53] <thumper> as does the test librarian
[08:53] <lifeless> thumper: ahhahah

[08:59] <persia> If I know the URL for an bug in a bugtracker known to launchpad, is there a way to see if the bug is already registered in launchpad?
[09:03] <wgrant> persia: Find the Launchpad bug tracker URL on https://edge.launchpad.net/bugs/bugtrackers
[09:03] <wgrant> Then add the bug number to the end of that URL.
[09:03] <wgrant> No, this is not documented.
[09:03] <persia> That's fine.  Being able to do it solves my immediate problem, and if I end up doing it several times, I'll be able to tell folk here.
[09:05] <wgrant> It comes up once or twice a year.
[09:06] <persia> Hrm.  Seems like my bug isn't there, but that's a good url to remember for lots of things, after exploring.
[09:59] <Zus> have a question abour pgp. and signing code of conduct. do i get one from a LoCo team or do i get one personaly
[10:02] <persia> Get which?
[10:05] <nigelb> Zus: you want to sign the ubuntu code of conduct?
[10:05] <nigelb> I believe the instructions are given there, how to generate key and how to upload your key
[10:05] <Zus> nigelb,  yeah i read it and downloaded it but  i need a pgp to sign it
[10:07] <nigelb> gpg?
[10:07] <Zus> i am reading  on how to make it now. but i wasnt sure if you need one per team..bugsquad or a LoCo team.. or  if i can make one on my  own
[10:07] <Zus> PgP sorry
[10:09] <Zus> will i only have to do the key once? regardless of upgrade?
[10:13] <nigelb> Zus: https://help.launchpad.net/YourAccount/ImportingYourPGPKey
[10:13] <geser> Zus: the gpg key you generate is your own personal key
[10:13] <geser> and you can use it not only within Ubuntu but also outside Ubuntu (if you want) to e.g. sign e-mails
[10:15] <Zus> geser even personal emails? even though its got my LP profile info?
[10:17] <geser> Zus: yes, but it's up to you. the gpg key itself has no connection to LP, LP only knows which key is yours because you told LP so
[10:18] <Zus> geser, now thats more the direction i was trying to go didnt know how to word it.
[10:22] <Zus> everyday im learning something new... i have been wasting time in XP lol  thank you guys!
[10:53] <jussi01> can I bug someoen about bug 488394
[10:57] <wgrant> jussi01: Replied on the bug with the solution. It's trivial.
[10:58] <jussi01> wgrant: yeah, Im sure it is. just someone needs to do it.
[10:58] <jussi01> and it would _really_ help if its done before the 3rd, but Im not holding my breath
[10:59] <wgrant> It's unlikely, given that it's release week and everything is frozen.
[10:59] <jussi01> wgrant: thank you for adding that though, every bit helps
[10:59] <wgrant> If it wasn't week 4, I'd do it now and get it landed tonight. But there's little point doing it now.
[11:00] <jussi01> ahh
[11:00] <jussi01> So next week then?
[11:02] <wgrant> Unless we have a nice/foolish RM.
[11:05] <jussi01> wgrant: if you have time, could you get it up there so at least the work is done and all we need to wait for it just upload?
[11:35] <Laney> what is a "Review type"?
[11:37] <askhl> Hi.  Regarding translations, I think I understand the meaning of the translation colour codings for projects that have launchpad as downstream, and a different upstream source.  But what determines the colour coding for projects whose upstream *is* launchpad?
[11:37] <thekorn> Laney, a random text describeing the kind of review which is supposed to be done by someone or was done by someone, like "code", "tests", "ui", whatever
[11:37] <Laney> oh, alright
[11:37] <Laney> is it ok to leave it blank?
[11:37] <askhl> (by translation colour codings I mean the green/purple/blue/red bar colours)
[11:37] <thekorn> yes
[11:38] <thekorn> Laney, launchpad provides no "correct" values for this field, it is the policy of the project you work on,
[11:39] <Laney> alright. It's just not clear from the UI what this is for.
[11:39] <thekorn> Laney, there might be the policy to never leave it blank
[11:40] <askhl> I guess those strings can only be purple ('new in launchpad') or red (untranslated).  Am I understanding this correctly?
[11:40] <dpm> askhl, if I'm not mistaken, it should mean the same: green are the translations which are the same in the source package (i.e. the developer has exported translations from Launchpad and committed them in the code), whereas the other colours mean that they've either not been translated (red) or not yet integrated in the sources. If you are using automatic translation imports and exports from bzr branches in the same branch, you should probably see everythin
[11:40] <dpm> g green nearly always
[11:41] <askhl> Green, really?
[11:42] <askhl> Transmission has its translations directly in Launchpad (no importing from upstream), and it seems to have lots of purple
[11:42] <askhl> https://translations.launchpad.net/transmission
[11:42] <askhl> Ah, I was viewing only the Danish translation.  I can see that other languages have green and even blue bars also
[11:43] <wgrant> askhl: The green strings are those that are unchanged from the last import or upload. Not necessarily upstream.
[11:44] <askhl> Ah, okay.  I thought uploading was mostly for upstream-downstream traffic...
[11:46] <dpm> askhl, it seems that Transmission is not using automatic bzr imports and exports, hence the comment on being "nearly always green" does not apply. The reason why they are purple is because translations have not yet been exported from Launchpad and integrated and committed in the sources
[11:46] <askhl> Hmm.  That is alarming, as this is quite a while ago
[11:47] <dpm> askhl, you might want to contact the Transmission devs to export translations, or even better, suggest them to use automatic bzr imports and exports, which will do that automatically for them
[11:49] <askhl> Nonetheless, I observe that the Danish translation of Transmission is actually working.
[11:50] <dpm> askhl, that's because Transmission is both open for translations on the upstream LP project and in Ubuntu. Ubuntu translations are put automatically in language packs, so that's why they are always used
[11:50] <dpm> (I'm assuming you're using Ubuntu)
[11:50] <askhl> Oh, okay.  So the *crucial* piece of information here is that Ubuntu has its own downstream for projects translated in launchpad!
[11:51] <dpm> askhl, if the upstream LP projects are also open for translation in Launchpad, yes.
[11:51] <muelli_> Heya :) https://launchpad.net/~ubuntu-bugs-auftrags-killer/+archive/muelli claims that my PPA is signed with a key, but http://ppa.launchpad.net/ubuntu-bugs-auftrags-killer/muelli/ubuntu/dists/karmic/Release.pgp does not exist. How can I get the repository signed?
[11:52] <dpm> askhl, in the future, this might be more automated when translations are automatically shared between the Ubuntu source packages and the upstream projects in LP
[11:53] <askhl> So let me get this straight: every translatable project in Ubuntu has a place in Launchpad where it can be translated.  This translation is imported from an upstream source which can be either outside of Launchpad or inside - in both cases these sources are 'outside' of Ubuntu, strictly speaking.
[11:53] <askhl> (O
[11:54] <askhl> (I'm taking over as coordinator for the Danish translators of Ubuntu, so I really have to get these things straight)
[11:57] <dpm> askhl: Yes, to be exact: in LP there is what we can call project space (where the translatable LP upstream projects are) and (Ubuntu) source package space (where the Ubuntu source packages are translatable). You might want to have a look at https://wiki.ubuntu.com/Translations/Upstream, since some of this applies there as well (you've made me realize I should add a section for projects where the upstream is LP)
[11:57] <askhl> Anyway, there's (I think) one more category of translations: how about entirely Ubuntu-specific things like the installation slideshow?  These exist only in Ubuntu, right?  That means they don't get synchronized from a source elsewhere in Launchpad
[11:58] <dpm> askhl, do you know about the #ubuntu-translators channel? I think as the discussion is leaning towards Ubuntu translations, we could continue there
[11:58] <askhl> dpm: I didn't know about that.  I will definitely be on that channel in the future
[11:59] <askhl> dpm: I'll have to think things over for a bit, maybe I'll have other questions later.  Thanks for the very informative responses so far
[12:00] <dpm> askhl, no worries, feel free to ask always. See you in #ubuntu-translators!
[12:06] <noodles775> muelli_: what does `gpg --list-keys| grep 2CD5CE3F` return?
[12:08] <noodles775> muelli_: hrm, weird that there is no Release.gpg there though... looking.
[12:09] <wgrant> muelli_: Did you upload to the PPA very soon after its creation (a few minutes, maybe)?
[12:10] <muelli_> wgrant: hm. well. yes and no. I tried but I was rejected a couple of times ;-)
[12:10] <muelli_> shall I just delete and reupload it..?
[12:11] <noodles775> You'll need to bump the version (btw: I'd add a ppa suffix to your version too)
[12:11]  * noodles775 finds help link
[12:11] <wgrant> muelli_: You could even just delete and resurrect it (using the 'Copy packages' link)
[12:13] <noodles775> muelli_: for your next upload :) https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#Versioning
[12:14] <muelli_> noodles775: yep. thanks.
[12:32] <muelli_> wgrant: I reuploaded stuff (see https://launchpad.net/~ubuntu-bugs-auftrags-killer/+archive/muelli/+sourcepub/981665/+listing-archive-extra) but still there no Release.pgp: http://ppa.launchpad.net/ubuntu-bugs-auftrags-killer/muelli/ubuntu/dists/karmic/Release.pgp :-\
[12:32] <bigjools> .gpg not .pgp
[12:32] <wgrant> leonardr: Are you aware that the devel webservice is serving WADL with beta URLs?
[12:33] <muelli_> oh, it exists now.
[12:33] <bigjools> muelli_: it takes time to generate the private key
[12:33] <Zus> when making a pgp key, i dont need to give  my password to anyone, nor will anyone see or need the password?
[12:33] <leonardr> wgrant: no, that's a problem. do the json resources serve the right urls?
[12:33] <wgrant> leonardr: Yes, which makes launchpadlib sad.
[12:34] <bigjools> muelli_: but you constantly pasted a url ending in .pgp rather than .gpg so were you looking for the wrong file the whole time?
[12:34] <muelli_> bigjools: nope. I had a look at the directory listing as well :)
[12:34] <bigjools> ok :)
[12:35] <leonardr> wgrant: ok, file a bug. i was about to say some part of the code was being lazy, but laziness would result in serving devel urls for beta, so i don't know what the problem is
[12:35] <persia> bigjools: We never caught each other last week.  What does your time look like this week for discussing native-source-syncing?
[12:35] <bigjools> muelli_: 2 things need to happen in sequence: 1. the private key has to be generated, this takes time as it waits for entropy, 2.the next publisher run will write the file (up to 5 minutes later)
[12:35] <wgrant> leonardr: lazr.restful or -foundations?
[12:36] <leonardr> wgrant: lazr.restful. i'll change it if that's wrong
[12:36] <bigjools> persia: there's a release on Wednesday but I hope to be finished with preparations today so maybe tomorrow
[12:36] <persia> bigjools: Let's target Thurs/Fri again then.
[12:36] <bigjools> persia: ok
[12:37] <persia> Just highlight me if you have time in the morning one of those days.
[12:38] <wgrant> leonardr: Bug #530002
[12:40] <muelli_> everything works now as expected :) thanks. This PPA thing is nice btw! Still has some rough edges such as getting used to all the necessary packaging or actually activating it, but still, very convenient :)
[12:41] <bigjools> muelli_: great!  let me know how you get on
[12:46] <leonardr> wgrant: it looks like a problem with launchpad, not lazr.restful
[12:47] <wgrant> leonardr: Is it keeping only one copy of the WADL?
[12:47] <wgrant> When I looked I could only see one.
[12:47] <leonardr> wgrant: oh, yes, that's something i still need to fix
[12:49] <leonardr> i'll fix that today
[12:50] <wgrant> Great.
[13:08] <Zus> how do i know  my key made it to the ubuntu seerver?
[13:24] <matsubara> Zus, you can check here: http://keyserver.ubuntu.com:11371/
[13:54] <kangarooo> Timeout error (Error ID:         OOPS-1521EB600)
[13:54] <kangarooo> thats from trying search in edge. but from usual page also search error          (Error ID:         OOPS-1521A1135)
[14:54] <ChogyDan> when I'm uploading to my ppa, it always threatens that the source package might be rejected on multiple uploads.  How can I take up that offer?  I am fixing packaging errors, so I don't need to upload the original source multiple times I would think
[14:57] <jml> ChogyDan, I don't know, sorrye
[14:59] <jml> any bugs folk around?
[14:59] <ChogyDan> jml: no worries, it would end up being a convenience more than anything.
[14:59] <jml> I'm looking at https://bugs.edge.launchpad.net/testresources/+bug/504092 and trying to figure out how to make the bug watch work
[15:10] <bigjools> ChogyDan: you don't need to upload the orig tarball more than once
[15:10] <persia> jml: While you're waiting for a bug person, would you have time to talk about making branches from patches?
[15:14] <ChogyDan> bigjools: yes, but I don't know what I'm doing.  I just debuild -S -sa, and then dput.  The tools decide to to reupload the orig tarball.  I wish I knew how to ask it not to
[15:15] <bigjools> ChogyDan: -sa forces inclusion of the source tarball, remove it
[15:15] <bigjools> in fact use -sd
[15:16] <bigjools> which explicily tells it to only use the diff
[15:16] <bigjools> explicitly*
[15:16] <ChogyDan> ok, thanks.  Where can I look up what those switches do?  the debuild man page doesn't seem to document them
[15:16] <jml> persia, a little.
[15:16] <jml> persia, which part in particular?
[15:17] <james_w> ChogyDan: dpkg-source manpage
[15:17] <ChogyDan> thanks!
[15:29] <persia> jml: Sorry.  Ran into a network issue.  Specifically, if there was current ongoing work to enable it, whether if work was done it was something you thought should be included, and if you had any pointers regarding possible blocking issues.
[15:29] <jml> persia, no work has been done yet.
[15:30] <jml> persia, or really work to enable it
[15:32] <jml> persia, afaict, it's just a matter of doing bzr branch trunk; bzr patch $PATCH_FILE; bzr ci -m "Turn $PATCH_FILE into a branch"; bzr push lp:~$USER/$PROJECT/$SENSIBLE_NAME
[15:32] <jml> persia, at least in the happy case
[15:33] <persia> From what I'd heard from other sources, the sensible solution would be to have some job that ran against bugs, attempted to guess the right branch to target (usually whatever is defined as trunk, but good to have some way to add hints to handle stuff like patches against stable branches), grabbed the patch, applied it, either marked the bug to indicate that the patch would not apply or commited the branch and pushed it attached to the bug.
[15:33] <jml> persia, the unhappy case requires a way of storing and displaying errors, maybe allowing people to pick a non-trunk branch and some other things
[15:33] <jml> persia, yeah, that's right.
[15:33] <persia> The happy case is enough to start.  The unhappy case can be addressed as bugs to the happy case.
[15:33] <jml> persia, to me, it's not a super-complex thing, and would be great to do
[15:34] <persia> Who would be the best person to talk to about detailed specifics?
[15:34] <jml> persia, it's also something that could be prototyped with relative ease outside of Launchpad.
[15:34] <persia> My ultimate target is Ubuntu, but I suspect that it's more sensible to target projects prior to distros.
[15:35] <persia> jml: So if something was written that used launchpadlib and bzrlib to just do it, that could be injected into the launchpad servers somewhere?
[15:35] <jml> persia, *probably*
[15:35] <jml> persia, that's how I'd do it.
[15:36] <persia> OK.  Should such a thing be written to iterate over all bugs, or get calls on a per-project basis?
[15:36] <jml> persia, the main difference is that the external tool would need to store data about which patches it has tried & failed
[15:36] <persia> Any reason not to use tags for that?
[15:36]  * persia would prefer not to have external state
[15:37] <jml> persia, no technical reason
[15:37] <jml> persia, but we'd almost certainly not use them if we implemented this in LP proper.
[15:37] <persia> That subtly implies a social or aesthetic reason :)
[15:37] <jml> persia, aesthetic :)
[15:37] <jml> persia, well spotted, btw :)
[15:37] <persia> How would you store state if it was implemented in LP proper?
[15:37] <jml> persia, new columns in the DB
[15:38] <persia> For bug objects?
[15:38] <jml> persia, we'd want to store error messages so we could show them on the web ui
[15:38] <jml> persia, implementation detail!
[15:38] <jml> persia, wherever makes the most sense. maybe even a new table.
[15:38] <jml> persia, as for how...
[15:39] <jml> persia, the Right Way is to respond to the event of a new patch being attached to a bug
[15:39] <persia> So a hook into the patch submission, similar to how the patch-checking thing would work?
[15:40] <persia> Err, patch-format-checking
[15:40] <jml> persia, yeah.
[15:40] <jml> persia, you can't do that (yet!) as an external client
[15:40] <jml> statik, how's that webhooks thing going?
[15:40] <persia> That's fine.  It was never likely to be implemented as an external client anyway :)
[15:41] <jml> persia, but you could do a similar thing with a query that looks for new or changed patches since the last run of the script
[15:41] <persia> But I think I have enough detail to write something up for design, etc.
[15:41] <persia> jml: That's less elegant, really.
[15:41] <jml> persia, yes. events are great. polling is bad.
[15:41] <persia> Um, well, depends, but in this case, yes.
[15:41] <jml> persia, thumper and deryck are the relevant app leads. kfogel & adeuring have had their heads buried in the patch code recently
[15:42] <jml> persia, almost always, IMHO.
[15:42] <persia> jml: heisenberg: observation can sometimes change events.  By polling, one can trigger, etc.  It's a rare case it's useful, but ...
[15:42] <jml> I admit that exceptions to the rule might exist.
[15:42] <jml> persia, good point.
[15:43] <persia> jml: Thanks for all the pointers.  I'll go chase stuff and document stuff and oke the relevant folks for review along the way.
[15:43] <persia> s/oke/poke/
[15:45] <jml> persia, my pleasure.
[15:45] <deryck> persia, hi.  yes, feel free to poke me about it as you work on it.  I would be very happy to see this work done.
[15:45] <deryck> jml, did you get your bug watch question answered or worked out?
[15:45] <jml> deryck, not at all.
[15:46] <jml> deryck, there are a few things that are confusing. I guess I should file them as bugs.
[15:46] <deryck> jml, yeah, it's not intuitive at all.
[15:47] <jml> deryck, would it be helpful if I list the non-intuitive bits?
[15:47] <persia> Are bugs about AJAX race conditions useful, or an inherent limitation of the medium?
[15:50] <jml> deryck, anyway, separately from that, I have no idea what to do to get more information and fix the "Launchpad couldn't connect to Twisted Bug Tracker." error
[15:50] <jml> persia, no idea.
[15:50] <jml> persia, also, fwiw, conversations like the one we had are prime fodder for #launchpad-dev
[15:50] <persia> jml: Thanks, but I hadn't meant to target you with that question :)
[15:51] <persia> jml: It was more in-depth than I had expected, but yes, I'll be going there with more depth.
[15:51] <jml> (which I personally think should be merged with this channel)
[15:51] <persia> Doesn't scale as the number of developers grows.
[15:52] <persia> At least for other areas in which I do things, it's helpful to separate things.
[15:52] <deryck> jml, ping allenap when he's available about the twisted tracker issue.  he's working on all this.
[15:52] <jml> deryck, will do.
[15:52] <deryck> jml, and I think just file bugs about the non-intuitive bits.
[15:52] <jml> deryck, ok.
[15:52] <jml> persia, I think we're below that point now.
[15:52] <deryck> jml, but the main problem is that we think about "bug watches" too much.  The "this is a bug in something else" workflow just needs changing.  what's all this affects mess? ;)
[15:52] <persia> jml: I'd agree :)
[15:53] <jml> deryck, +1
[15:54] <persia> deryck: A recipe for complaints related to bug #204980
[15:54] <deryck> persia, not sure I follow what you mean
[15:55] <persia> deryck: I think that "Also affects ..." encourages creation of bugs that are actually collections of bugs and lead to the complaints related to 204980.
[15:56] <persia> Implementing a fix for 204980 is really working around a problem with the workflow design.
[15:56] <deryck> persia, maybe so.  I think the actual bug there is different.  But I agree that one impacts the other.
[15:57] <persia> Well, sure.  I just think the importance of 204980 would be much lower were the workflow changed.
[15:57] <deryck> ah, right.  maybe so.
[15:58] <persia> Right now I probably get a complaint about how Ubuntu is spamming someone twice a week.  I suspect people with wider profiles get them more.
[15:58] <persia> WIth a fixed workflow, it ought only be annoying for a few folk.
[15:58] <persia> Also reduces training effort :)
[15:59] <persia> But that's just supporting arguments for your initial contention.  Good luck :)
[16:01] <deryck> thanks! :-)
[16:03] <idnar> what happened to bzr-autoreview?
[16:24] <statik> jml, i haven't had a moment to breath to work on the webhooks thing, i need to write it up and post it to launchpad-dev
[18:27] <flower> is it possible to 'track' an certain ppa repo, via feeds for example?
[18:30] <beuno> flower, no, but that sounds like a great feature request
[18:30] <beuno> *wink*
[18:31] <flower> yeah, then this is a feature request!! :)
[18:34] <beuno> flower, it's not official until you file a bug!
[18:35] <flower> where?
[18:36] <beuno> flower, https://bugs.edge.launchpad.net/launchpad/+filebug
[18:46] <matsubara> flower, beuno: bug 200643
[20:59] <hggdh> is there a minimum size for GPG keys in LP? Like 1024?
[21:04] <wgrant> hggdh: It appears not.
[21:05] <hggdh> hum. I have an user trying to import his GPG key, and failing... will check more
[21:05] <hggdh> thank you, wgrant
[21:06] <hggdh> no, just tried the fingerprint the user has, it fails to import
[21:18] <kris928> hey has anyone here ever had an issue with ubuntu destroying the daily AMIs and loosing the ramdisk / kernel from your own derived builds?