[01:10] <kirkland> how do I mark a ppa as private?
[01:10] <FFEMTcJ> Can we make bug #493518 as high priority due to the fact that it effects multiple resolutions and multiple browsers?
[01:15] <jml> FFEMTcJ, a wise man once said, 'Why say "can we upgrade this to critical" when you mean "can we fix this?"'
[01:15]  * jml looks at the bug.
[01:16] <FFEMTcJ> jml: well.. if the right people see it to fix it.. I don't know how many people work on launchpad.. and i dont know if it may get missed..
[01:16] <jamesh> lifeless: hi
[01:16] <wgrant> kirkland: I don't believe you can make a PPA private, but you can ask a LOSA to create you one.
[01:17] <lifeless> jamesh: hi
[01:17] <lifeless> jamesh: I'm interested in figuring out that openid users on launchpad'
[01:17] <lifeless> s openid thing, are in a given group.
[01:17] <lifeless> are there docs, or can you tell me about this ?
[01:18] <jamesh> you can query their group membership when you authenticate them.
[01:18] <wgrant> But only if your RP is authorized to do so.
[01:18] <jamesh> there are some docs somewhere
[01:20] <kirkland> spm: wgrant: okay, thanks
[01:20] <jamesh> lifeless: this is part of some early documentation I wrote, but should still be valid: http://paste.ubuntu.com/338395/
[01:23] <lifeless> jamesh: thanks, reading
[01:23] <jamesh> lifeless: what sort of app are you wanting to integrate this into?
[01:23] <jamesh> if it's a Django app, we've already got code to do that
[01:23] <lifeless> java
[01:24] <lifeless> jamesh: where would be a good 'official' home for those docs.
[01:25] <jamesh> lifeless: I know stuartm was working on a more formal version of those docs a while back, but I don't know what happened to it.
[01:25] <jamesh> lifeless: that paste was from an early specification I wrote when designing the feature
[01:26] <jamesh> it should probably be on dev.launchpad.net somewhere if it isn't already
[01:27] <lifeless> I can't see it there; ok if I just create a /OpenIDGroups page and paste it ?
[01:28] <jamesh> probably OpenIDTeams
[01:28] <jamesh> the extension namespace is http://ns.launchpad.net/2007/openid-teams after all
[01:31] <lifeless>  https://dev.launchpad.net/OpenIDTeams#preview
[01:32] <lifeless> jamesh: thanks
[01:37] <jamesh> lifeless: you should be able to use that extension to query any public team.  For private teams, it won't provide any membership info unless LP is configured to do so for your RP
[01:42] <lifeless> thats cool; its a shame private teams need an explicit bit set (outside the team admins control I imagine)
[01:42] <lifeless> but in the first instance I want this for my own satisfaction, I have a hudson instance for things like subunit I'd like to expose cleanly.
[01:42] <lifeless> and for work needs, well, I can worry about that next year :)
[01:57] <lifeless> jamesh: to be an RP, you need to be able to accept a POST from the provider right ?
[01:58] <jamesh> lifeless: no
[01:58] <lifeless> the client gets a magic string then ?
[01:58] <jamesh> lifeless: the relying party is the consumer of the authentication service
[01:59] <lifeless> yes
[01:59] <lifeless> say I'm developing a site on my laptop behind a firewall
[01:59] <lifeless> I'm wondering if I have to punch holes inwards
[01:59] <jamesh> lifeless: the RP needs to be accessible to the user
[02:00] <jamesh> you can easily run an RP on localhost and authenticate against an external OP
[02:00] <jamesh> that OP might caution you about authenticating to http://localhost:port/
[02:00] <jamesh> but it should all work
[02:00] <lifeless> ok cool
[02:00] <lifeless> thanks
[02:00] <lifeless> I really should read the specs
[02:01] <jamesh> all required communication is either initiated as RP -> OP, user -> RP or user -> OP
[02:02] <jamesh> the OP might try to perform discovery on the RP, but if that fails it shouldn't block the authentication
[02:02] <jamesh> [if it passes, it may limit which return_to URLs the OP will accept for the RP though]
[02:06] <lifeless> jamesh: does lp do this?
[02:07] <jamesh> I'm not sure.
[02:07] <lifeless> ok
[02:07] <jamesh> But if the discovery fails, the spec says that all return_to URLs should be acceptable
[07:52] <stochastic> Hi, I'm trying to get a mailing list for my launchpad group subscribed to the iso tracker build notifications for Ubuntu Studio images, but no e-mails seem to be going through.  I've sorted everything out on the iso tracker subscription end, but because the originating address isn't associated with a launchpad account on the team, the e-mails aren't appearing on the list.  Is there any way to sort this out?
[09:08] <latz> hi I've just created an account on launchpad, but I can't see the key of the project I want to add to my repo!
[09:11] <noodles775> Hi latz! I'm not sure what you mean? Are you adding a PPA to your local system, or something else?
[09:13] <latz> yeahh I am trying to add an existing ppa to my local system. I see that there is a command add-apt-repository but I can't find that on my system ... ubuntu 9.10 server
[09:14] <micahg1> is there a URL where I can target a milestone?
[09:17] <latz> got it had to install apt-get install python-software-properties
[09:22] <henninge> micahg: can you re-phrase that quesiton, please, I am not sure what you are asking
[09:22] <micahg> henninge: if there is a url like +editstatus for milestones
[09:22] <micahg> the milestone link is to editstatus
[09:23] <micahg> but it's not working for an upstream bug task
[09:23] <henninge> micahg: other than +edit?
[09:24] <wgrant> micahg: +editstatus works fine for me. Do you perhaps not have sufficient privileges over the upstream projecT?
[09:24] <micahg> it's on an upstream bug watch
[09:24] <wgrant> I don't expect you'd be able to alter that.
[09:24] <wgrant> It doesn't make sense.
[09:24] <micahg> I can see it in the bug, but when I click it, it doesn't work, but takes me to editstatus
[09:25] <wgrant> Ah.
[09:25] <micahg> it's for mozilla upstreams :)
[09:25] <wgrant> So the bug is that the link is shown at all.
[09:25] <micahg> so I do have the permissions
[09:25] <micahg> hmmm...I like being able to target to milestones for upstream
[09:26] <micahg> it helps to group LP bugs for the release in ubuntu
[09:26] <micahg> before I was tagging bugs with the version fixed which wasn't as neat
[09:31] <gmb> micahg: Which bug are you looking at?
[09:31] <micahg> bug 369150
[09:33] <gmb> micahg: And you're trying to set the milestone for the Mozilla Thunderbird bug task, right? Not the thunderbird (Ubuntu) one?
[09:33] <micahg> gmb: correct
[09:34] <gmb> micahg: Then wgrant is right. That link shouldn't show up at all. In fact, in an ideal world what would happen is that Launchapd would be aware of the upstream milestone for the bug (if any) and display it appropriately.
[09:34] <gmb> Oh for an ideal world.
[09:35] <micahg> gmb: ok, but I like the "feature"...it's helpful for me to track upstream mozilla bugs fixed in a new upstream release
[09:35] <micahg> I can target the bugs to the upstream release and then close then in the changelog when it's released to Ubuntu
[09:35] <micahg> *them
[09:36] <micahg> see: https://edge.launchpad.net/thunderbird/+milestone/3.0
[09:37] <gmb> micahg: Right, but my point is that a) you shouldn't have to do that, LP should do it for you if anything and b) What happens if you stop tracking things manually? It then gets confusing for everyone else.
[09:37] <gmb> Because it gets out of date
[09:37] <micahg> well, it won't be any worse than it was before
[09:38] <micahg> gmb: I agree in an ideal world...but that's not what we have
[09:38] <gmb> micahg: Right. That doesn't mean that it's not a bug in Launchpad though :)
[09:38] <micahg> if the "solution" is to remove the link to target milestones..I'd rather keep the "bug"
[09:39] <micahg> Yes, I would love for LP to do all the work
[09:39] <davmor2> Morning guys I'm having an issue try to report a bug.  I keep getting timed out when I hit continue after typing in the description.
[09:40] <henninge> davmor2: Try a shorter descripton first and extend it later.
[09:40] <henninge> (this tip curtesy of wgrant)
[09:40] <davmor2> henninge: the description is now down to keyboard
[09:40] <gmb> davmor2: Alternatively try filing the bug through edge.launchpad.net. The timeout should be less of a problem there due to a new feature that just landed.
[09:40] <wgrant> gmb: Unless you're filing against Ubuntu, which is where the majority of the issues occur..
[09:41] <gmb> micahg: I can appreciate that. However, it's still a bug.
[09:41] <gmb> wgrant: Poo. Good poitn.
[09:41] <henninge> davmor2: sorry?
[09:41] <gmb> wgrant:  And you'd think, given that I just wrote a blog post about it, that I would know that.
[09:41] <wgrant> davmor2: 'zzzzzzzzz' often works
[09:41] <wgrant> If it's reeeeeeeally bad
[09:41] <micahg> gmb: the bug is that I can select a milestone?
[09:41] <henninge> wgrant: is that on the actual bug title?
[09:41] <gmb> micahg: Yes.
[09:41] <wgrant> henninge: Yes.
[09:42] <henninge> oh, that is bad ...
[09:42] <gmb> micahg: Well, that you're given the option to at all.
[09:42] <gmb> henninge: Working on it...
[09:42] <davmor2> wgrant: that worked thanks :)
[09:42] <micahg> gmb: can we leave it until LP starts importing upstream milestones?
[09:44] <gmb> micahg: I've filed bug 494941 about it. Given that you feel strongly about this I suggest you comment there. I suspect we won't look at it for at least a couple of cycles.
[09:44] <gmb> If that.
[09:45] <micahg> gmb: I just find it helpful, if you can give me another easy way to group bugs, then I'll do that
[09:46] <gmb> micahg: I can appreciate that, but that doesn't make it less of a bug. We've got ideas about personalised bug groupings but we haven't scheduled those yet.
[09:47] <micahg> ok, also, most people won't see it as they don't have privs for the upstream project I woudl think
[09:48] <micahg> gmb: do you know if there's a bug filed to pull milestones from upstream?
[09:48] <gmb> micahg: If there isn't I'm filing one as we speak...
[09:49] <micahg> gmb: I'm not sure which project to look in
[09:50] <gmb> micahg: I'm filing the bug now on bugs.launchpad.net/malone
[09:52] <gmb> micahg: bug 494943
[09:54] <micahg> gmb: I guess another way to solve this, which is probably better, is to be able to target fixes to versions in LP
[09:54] <gmb> micahg: But for an upstream project that makes no sense.
[09:54] <gmb> All the project in Launchpad does is serve as a pointer.
[09:55] <micahg> gmb: well, if it was implemented, I can target the version on the ubuntu task :)
[09:55] <micahg> gmb: which is what I really want to do anyways
[09:55] <gmb> micahg: I don't quite understand what you mean. You want to target a task on the ubuntu package of, say, thunderbird to a milestone on the Thunderbird project in Launchpad?
[09:56] <micahg> gmb: ideally, I'd target the ubuntu task to be fixed in version x.x even if it wasn't released yet
[09:56] <micahg> gmb: then I can pull up that version to see the fixes
[09:56] <micahg> and publish the changelog accordingly (I think)
[09:57] <micahg> or maybe not
[09:57] <gmb> micahg: That would confuse a lot of people, I think.
[09:57] <micahg> gmb: I guess seeing the version targeted in teh upstream project is better than
[09:57] <gmb> In fact that's the whole point of having separate tasks for the package and the project.
[09:58] <micahg> gmb: ok, I commented on teh first bug
[09:58] <gmb> Thanks.
[09:59] <micahg> thank you for the bugs :)
[09:59] <gmb> np
[10:15] <micahg> gmb: regarding bug 200890, I would think there should be a status closed_upstream as well to show the invalid/wfm bugs...should I file a new bug or comment on that one
[10:21] <gmb> micahg: Ok, thanks.
[10:22] <micahg> ok, I just commented on that bug
[12:16] <tsimpson> if anyone is interested: I just filed bug #494999 about the +text interface for bugs
[12:20]  * Mez is trying to go to the LP bug page, and just gets sent to bug 147723
[12:21] <Mez> never mind, stopped now
[12:43] <thekorn> gmb, hi, I like the inline dup finder, but I think I've found a bug: when you try to create a bugreport with an "unknown" summary (no similar bugreports found) you get no way to file the bug,
[12:43] <thekorn> the form is missing, or hidden
[12:45] <dpm> danilos, do you know if there is any entity in the LP API that corresponds to translation groups? I'm trying to get a list of the Ubuntu translation teams in the ubuntu-translators group through launchpadlib, and I'm wondering if I could pull it from ubuntu-translators, but reading https://edge.launchpad.net/+apidoc/ I see no references to translation groups - perhaps they map to something more generic
[13:02] <danilos> dpm, no, there isn't; the only translations related objects exposed through API are import queue related
[13:07] <dpm> danilos, ok, thanks
[13:21] <gmb> thekorn: That shouldn't happen. Let me see what's going on.
[13:22] <thekorn> gmb, in the meantime I filed a bug https://bugs.edge.launchpad.net/malone/+bug/495029
[13:22] <gmb> thekorn: Right, thanks. It's actually supposed to show you the form in that case. I'll look into it right away.
[13:23] <thekorn> super, thanks
[13:54] <gmb> thekorn: Fix is on its way to devel now. Thanks for spotting the problem!
[13:58] <thekorn> gmb, wow, that's quick fix, thanks for working on it
[14:30] <gmb> thekorn: np. It was a simple fix really - my own fault for not tracking the YUI change closely enough.
[15:41] <bjsnider> i'm running into the problem detailed in bug 330711
[15:42] <bjsnider> i have a large package to deal with. i don't really want to send in 4 different versions of it since it's 30 MB or something. is there a way to just send in the changes file and refer to the source already in the cloud?
[15:42] <bigjools> bjsnider: what are you trying to copy?
[15:42] <bjsnider> the only difference is the eries. i don't have to change anything else
[15:42] <bigjools> ok
[15:43] <bjsnider> that bug stops a rebuild from working
[15:43] <bigjools> It's not a bug.  You have 2 options: 1. copy with binaries, 2. re-upload different versions for each series
[15:43] <bjsnider> it seems so superfluous to send in so many source packages whent hey're all the same
[15:43] <bigjools> pool-based architectures can't cope with the same version built more than once
[15:44] <bigjools> s/architectures/repositories/  d'oh
[15:44] <bjsnider> dependency problems prevent 1. from being an option
[15:45] <bjsnider> there's no way i can change the changelog and then use the orig tarball already on the server?
[15:45] <bigjools> then you have to re-upload the source.  it's good if you have a large as possible .orig.tar.gz then you don't have to keep uploading it.
[15:45] <bigjools> yes, just refer to the same file in the changes file
[15:45] <bigjools> dsc file, sorry
[15:46] <bjsnider> the debuild command i use is -S -sa
[15:46] <bjsnider> is that the same?
[15:48] <bigjools> I'm not sure what you need exactly, #ubuntu-moto is a good place to ask though
[15:48] <bigjools> arg
[15:48] <bigjools> #ubuntu-motu, sorry
[15:48] <noodles775> https://help.launchpad.net/Packaging/PPA/Uploading
[15:48] <noodles775> ^^ indicates that -S -sa is to explicitly include the orig.tar.gz
[15:49]  * noodles775 is reading the man page now.
[15:49] <bjsnider> if i don't increment the version in the changelog, dput will not send the package in. if i delete the upload record, the file will go in and sop will the orig tarball, and they'd be rejected by the server as already having been uploaded
[15:49] <bigjools> bjsnider: you must increment the version for each upload
[15:50] <bjsnider> yes but then the orig tarball will be uploaded.
[15:50] <bjsnider> unless there's soemthing i'm missing here
[15:50] <bjsnider> which there probably is
[15:50] <bigjools> leave out the -sa
[15:50] <bigjools> or use -sd
[15:50] <bigjools> man dpkg-genchanges
[15:51] <bjsnider> yes, i think debuild is the key
[16:43] <persia> In playing with linking branches and blueprints, I discovered an oddity, and wonder if it's a bug.
[16:43] <persia> Specifically, if you try to link from a branch to a blueprint, it presents a pulldown (apparently of all blueprints for the same project as the branch)
[16:43] <persia> If you try to link from a blueprint to a branch, it presents a text box for the branch path.
[16:44] <persia> This ends up having interesting effects if you're working across projects, for instance addressing an Ubuntu blueprint in another project.
[16:44] <persia> Because one *must* link from the blueprint to the branch and cannot link from the branch to the blueprint.
[16:50] <henninge> persia: I'd think that there either simply is no blueprints picker (likely) or the branch picker should be limiting the choice.
[16:50] <henninge> I am not sure if linkage between blueprint and branches from different projects is an intended and usable feature.
[16:51] <persia> henninge: How do you mean no blueprints picker?  That the feature isn't implemented, or that there aren't any blueprints for the project that the branch is against?
[16:51] <persia> It works just fine if you link from blueprints to branches (and is useful at least when implementing Ubuntu blueprints against the many ubuntu-related non-ubuntu projects in LP)
[16:52] <persia> It's just that the UI is completely different in each direction, which reduces discoverability.
[16:52] <henninge> persia: yes, I was talking about a UI feature that lets you pick a blueprint Launchpad-wide.
[16:53] <henninge> like there is a branch picker (which is not used in blueprints).
[16:53] <persia> So the blueprints picker *is* project-specific?
[16:54] <henninge> persia: I was going by what you wrote earlier but I cannot image a single drop-down box containing all the blueprints in LP.
[16:54] <persia> heh.  No, that would be unwieldy.
[16:54] <persia> Even a pulldown with all the projects in Ubuntu would be exceedingly painful.
[16:55] <JamieBennett> what about the search box like for other entries
[16:55] <JamieBennett> ?
[16:56] <persia> Well, that would require a LP-wide blueprints picker, which would require someone to actually hack on blueprints.
[16:56] <henninge> exactly
[16:57]  * persia waits for a new Ubuntu bug report to try out the branch picker
[17:01] <persia> henninge: Do you know of a page that shows the branch picker?  I get roughly the same interface from both blueprints and bugs (text box that lets me enter a branch path)
[17:02] <henninge> persia: pick a branch for project series
[17:03] <henninge> persia: as in https://staging.launchpad.net/wordpress/trunk/+linkbranch
[17:04] <henninge> replace wordpress with a project you have edit rights to.
[17:10] <henninge> ok, I am outta here.
[17:12] <persia> Have a good night.
[17:18]  * persia doesn'T seem to have access to "trunk" for any projects, and so gives up.
[17:18] <persia> I don't think it's a bug anymore though, so much as a symptom of issues with blueprints.
[17:19] <persia> If either 1) a blueprint picker was created that specifically blocked picking other projects, or 2) the blueprints UI was modified to specifically block picking branches from other projects, I'd probably file a bug.
[17:33] <jcastro> barry: did +mailinglists get  moved?
[17:35] <beuno> jcastro, auto-approve from now on!
[17:35] <beuno> barry, btw, what happens to the mailing lists created on production?
[17:35] <jcastro> !
[17:36] <jcastro> ls
[18:14] <thekorn> hi, can anybody please tell me if OOPS-1440EA878 and OOPS-1440EC845 are related, or where to report them
[18:14] <thekorn> I get the 2nd one when trying to open https://bugs.edge.launchpad.net/zeitgeist/+bug/488967
[18:15] <thekorn> anf the first one when I try to open a merge proposal, the bug mentioned above might be linked to this proposal, but I'm not sure about it
[18:37] <kasimir> I have a policy question for Launchpad.  Are projects allowed that distribute binaries without the appropriate sources for them?
[18:37] <beuno> kasimir, no, they need to be open source
[18:37] <kasimir> okay
[18:38] <kasimir> how would I report a non-open-source project?
[18:38] <kasimir> namely, https://launchpad.net/euca-blobs
[18:38] <kasimir> (I really want the source for win-grub.img, which is why I looked into this)
[18:39] <beuno> kasimir, there seems to be a branch
[18:39] <beuno> https://code.edge.launchpad.net/~andrew-fulcher/euca-blobs/trunk
[18:39] <kasimir> (I don't want to just use their win-grub.img file without knowing how to built it myself, knowing whether it contains anything malicious, etc)
[18:39] <kasimir> yes
[18:39] <kasimir> however, that code does not compile or explain how to get win-grub
[18:39] <kasimir> that is just for the .bat and .pl file
[18:39] <beuno> kasimir, I would try contacting them first, otherwise just open a question on Launchpad
[18:40] <kasimir> beuno: okay, thanks for your help!
[18:40] <kasimir> if they don't reply, how would I let launchpad know they are not distributing their source?
[18:51] <kasimir> beuno: thanks again!
[18:51] <kasimir> bye all
[20:21] <Riddell> how do I report spam on launchpad?
[20:22] <persia> Generally by asking a question.  For instance, if it's spam in a bug report, ask a question against Malone.
[20:24] <bjsnider> awesome. i don't have to keep uploading redundant source packages if i want to build the same package for a different series
[20:24] <bjsnider> the ppa build system supports using one orig source over and over again
[20:32] <smoser> umm.. help?
[20:32] <smoser> https://edge.launchpad.net/+search?field.text=automated+cloud
[20:32] <smoser> indicates that (as I had thought) there was a page at https://blueprints.edge.launchpad.net/ubuntu/+spec/server-lucid-cloud-test
[20:32] <smoser> which is no longer there.
[20:48] <MTecknology> How long does it normally take to review a project import?
[23:47] <mkanat> gmb: "You received this bug notification because you are a member of GNOME
[23:47] <mkanat> Bugzilla maintainers, which is the registrant for bugzilla.gnome.org."
[23:47] <mkanat> gmb: You're kidding, right?
[23:47] <mkanat> gmb: Does that mean that I'm going to get every single mail from bugs linked to bugzilla.gnome.org?
[23:47] <mkanat> (That might make sense for individual installs, but for bgo, definitely not.)
[23:50] <wgrant> mkanat: I think it means the project (https://launchpad.net/bugzilla.gnome.org), not the bugtracker (https://launchpad.net/bugs/bugtrackers/gnome-bugs).
[23:51] <wgrant> mkanat: It looks like somebody has decided to file some bugs against the bugzilla.gnome.org project rather than the actual project.
[23:51] <mkanat> wgrant: Except that I'm getting bugs for other things--are people just filing them against the wrong thing? I don't think so, because I would have seen them filed.
[23:51] <mkanat> wgrant: Also, notice that it says "the registrant for bugzilla.gnome.org".
[23:51] <wgrant> mkanat: What's an example bug number?
[23:52] <mkanat> I just got a notification for Bug 456220.
[23:52] <wgrant> Right, you'll see that has a task in the 'bugzilla.gnome.org' project.
[23:52]  * mkanat notes that all of LP now has nearly as many bugs as bugzilla.mozilla.org and bugzilla.gnome.org. :-)
[23:52] <wgrant> Which does not make sense.
[23:52] <mkanat> wgrant: Ahhh.
[23:52] <wgrant> So a user just needs to be thwacked.
[23:52] <mkanat> That does not make sense indeed.
[23:52] <mkanat> Hahaha, okay.
[23:53] <mkanat> I don't think I ever got a bugmail that made it clear that anybody was adding that task.
[23:53] <wgrant> It would have been on 2009-10-20.
[23:53] <mkanat> wgrant: Yeah, no email then.
[23:54] <wgrant> Odd.