[00:23]  * penguin42 is getting 503's from launchpadlibrarian.net
[00:23] <penguin42>  '503 Service Unavailable' No server is available to handle this request
=== Lcawte is now known as Lcawte|Away
=== yofel_ is now known as yofel
[01:31] <waldir> hey guys. I'd like to add a bug to launchpad suggesting that when installing package A, if B is already installed, A-B should be installed too (e.g. php5, curl, and php5-curl). What search terms should i use to make sure it hasn'e been submitted before?
=== smokex_ is now known as smokex
[01:47] <wgrant> waldir: That would need a fix for Debian bug #77324
[01:47] <ubot5> Debian bug 77324 in dpkg "dpkg wish: conditional dependencies" [Wishlist,Open] http://bugs.debian.org/77324
[01:48] <wgrant> waldir: Neither dpkg nor apt support conditional dependencies, which are required to express the relation that you suggest.
[01:50] <waldir> wgrant: thanks for looking into this :)
[01:51] <waldir> so I take it that there's nothing I can do at the moment?
[01:51] <wgrant> That's right :(
[01:55] <waldir> wgrant: at least no progress was prevented by inaction of my part :) thanks for giving me that bit of peace of mind :)
[01:56] <wgrant> Heh.
[07:08] <tumbleweed> Can I rely on https access to launchpad librarian? I'd like pull-{lp,debian}-source to use https for fetching the .dsc file, but launchpad redirects from +files to http://launchpadlibrarian. I'm tempted to rewrite the redirect.
[07:09] <wgrant> tumbleweed: Yes, launchpadlibrarian.net provides both HTTP and HTTPS.
[07:09] <wgrant> The webapp uses HTTPS, so I don't think it'll go away any time soon :)
[07:11] <tumbleweed> wgrant: good, I just imagine that not much uses lp librarian over https
[07:11] <tumbleweed> I mean, all the redirects from lp are plain http (that I've sen)
[07:12] <wgrant> Right. It normally redirects to to HTTP, but uses HTTPS for stuff included in pages (icons, for example).
[07:14] <tumbleweed> oh, didn't know that came from librarian
[07:19] <wgrant> tumbleweed: Team and project images do.
[09:04] <lifeless> tumbleweed: shouldn't pull-lp-source use the bzr branch ?
[09:06] <micahg> lifeless: maybe once the package importer is fixed :)
[09:06] <persia> No, because that doesn't provide a .dsc
[09:06] <lifeless> persia: any?
[09:06] <lifeless> s/any/and/
[09:06] <persia> Also, we'd have to do historical package imports, unless pull-lp-source no longer takes a release argument.
[09:07] <persia> lifeless: Means one has to fiddle with stuff to get the .dsc to use in the next step of a number of processes.  UDD will replace this, if it does, but it's not worth attempting to insert UDD into this.
[09:26] <wgrant> micahg: (The package importer is fixed, it will catch up in the next day or so)
[09:27] <micahg> wgrant: ok, well, there are still the reasons that persia mentioned then
[09:34] <lifeless> tumbleweed: anyhow, a) yes https is here to stay; lp is staying https only
[09:35] <lifeless> tumbleweed: b) the urls on the appservers are authoritative; don't cache the urls on the librarian indefinitely
[09:35] <lifeless> and c) we should generate some urls to the librarian we don't at the moment, that needs some log care n attention
=== Lcawte|Away is now known as Lcawte
[09:50] <tumbleweed> lifeless: I simply want to use https because I have no other way to do verification, there won't be any caching
[09:50] <persia> tumbleweed: You don't trust TCP?
[09:51] <tumbleweed> persia: I tend to, but one shouldn't when building tools :)
[09:51] <persia> Why not?  The entire point of TCP is that it's reliable and transaction-based.  Otherwise folk would use UDP for everything.
[09:52] <wgrant> I'd be using HTTPS for this sort of thing... people don't normally verify .dsc sigs.
[09:52] <tumbleweed> .dsc sigs aren't very useful in ubuntu, we don't have a developer keyring
[09:53] <tumbleweed> (very useful in this use case)
[09:53] <persia> wgrant: Ah, to avoid routing attacks.  Good point.
[09:53] <persia> tumbleweed: We could construct one, although without a closed WoT, it's messy.
[09:55] <tumbleweed> eventually UDD should take over for a lot of this. I'm not particularly worried here, I just think our tools should try and not be the weakest security link
[09:56] <persia> Indeed.  I just momentarily forgot about routing attacks.
=== yofel_ is now known as yofel
[16:54] <kirkland> help, please
[16:54] <kirkland> spam leaking into bugs: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/543478/comments/10
=== epsy is now known as \u03b5
[18:31] <lifeless> kirkland: https://answers.launchpad.net/launchpad/+question/145236
[19:27] <kim0> Hi folks, newbie around. I'm pushing code to "https://code.launchpad.net/~kim0/+junk/ec2-ebs-migrate-Instance" which is a branch from "https://code.launchpad.net/~abd4lla/+junk/ec2-ebs-migrate" However I am not getting "propose for merging" link, any idea why ?
[19:30] <lifeless> +junk does not have collaboration features
[19:30] <lifeless> possibly it should, but it doesn't at the moment
[20:29] <mwhudson> huh, when did "86 queries/external actions issued in 1.10 seconds" start appearing in the top right of the page?
[20:31] <lifeless> friday, for LP devs.
[20:31] <lifeless> the discrepancy between that time and the http response time is in-dc queuing
[20:33] <lifeless> mwhudson: do you like it ?
[20:34] <mwhudson> yeah, it's nicely styled
[20:34] <mwhudson> it's there if i want to look for it, not too in your face though
[20:34] <lifeless> that was huwshimi
[20:34] <lifeless> we collaborated :) - I've wanted to do that for -ages-
[20:41] <lifeless> mwhudson: I'm thinking of making it much more aggressive on soft timeouts
[20:42] <mwhudson> like make it red and flashing if it soft-timed out?
[20:42] <lifeless> mwhudson: like - a watermark saying 'timeout', and a expanding widget listing the actions
[20:54] <mwhudson> that'd be awesome
[21:09] <mwhudson> is there a guide anywhere for accessing the launchpad api from another webapp?
[21:09] <mwhudson> i guess i want the js equivalent of launchpadlib
[21:13] <lifeless> well
[21:13] <lifeless> all the LP js
[21:13] <lifeless> except
[21:13] <lifeless> we don't see cross domain permissions
[21:13] <lifeless> so you'll run into browser security issues if you're trying to do authenticated actions
[21:14] <lifeless> I'm not sure what the best answer is there, guess we can whitelist sites we trust not to mess up and have vulnerabilities themselves
[21:14] <lifeless> alternatively, have your webapp make backend requests to lp using launchpadlib or similar
[21:15] <mwhudson> read only i think
[21:15] <lifeless> its not read/write that is the issue
[21:15] <lifeless> its 'hit another website using the secure cookie for that site'
[21:15] <mwhudson> ah, and anonymous :)
[21:15] <mwhudson> (at least for now)
[21:15] <lifeless> no cookie -> anonymous
[21:15] <lifeless> yes
[21:16] <mwhudson> can you use oauth from js, or does that fall foul of the cross domain restrictions as well?
[21:16] <mwhudson> can proxy via the backend if needed i guess
[21:17] <jinzo> hello, I'm wondering what does launchpad use for it's openid logins?
[21:17] <jinzo> which library? python-openid directly or?
[21:18] <mwhudson> ah
[21:18] <jinzo> I'm trying to browse the sourcecode, but I'm quite... lost in it
[21:18] <mwhudson> i think it uses python-openid yes
[21:19] <jinzo> is there a way to browse the current trunk online?
[21:19] <lifeless> mwhudson: I'm not a browser model expert, but given oauth was designed for backend-requests (thats why its a 3rd party auth system), I suspect the answer is 'yes you will'
[21:19] <mwhudson> yes, but note that some of the login stuff is not actually in the launchpad codebase
[21:20] <lifeless> jinzo: current trunk of what?
[21:20] <jinzo> launchpad
[21:20] <jinzo> I would want to see all the dependencies
[21:20] <mwhudson> jinzo: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/files
[21:20] <lifeless> we'd like to see tham all too
[21:20] <mwhudson> heh heh
[21:20] <lifeless> they're split in 4 places
[21:20] <lifeless> contrib
[21:20] <lifeless> setup.py/versions.cfg
[21:21] <lifeless> launchpad-dependencies packages
[21:21] <lifeless> sourcecode/ via config-manager
[21:21] <lifeless> this is a bit of a mess
[21:23] <jinzo> thanks for the info
[21:24] <mwhudson> lifeless: so, for read-only, anonymous access to the launchpad api from js i should ... what?
[21:24] <mwhudson> copy/paste chunks of launchpad's own js?
[21:24] <mwhudson> i guess i should ask this sort of thing on a day when more people are around
[21:24] <lifeless> mwhudson: we don't publish a js version of launchpad lib
[21:25] <lifeless> and unless/until we get a good answer around browser security model + archive permissions (for instance), we won't ;)
[21:25] <mwhudson> so i might be better off proxying via a webapp backend
[21:25] <lifeless> mwhudson: you *can* use the api from js pretty easily given its json yada yada yada
[21:25] <lifeless> mwhudson: if you fix the 'launchpadlib is not concurrency safe' bug, certainly.
[21:25] <lifeless> mwhudson: what are you doing?
[21:26] <mwhudson> lifeless: we're building an android build service
[21:26] <mwhudson> my design stores configurations in launchpad branches, so i want to access the list of branches for a project
[21:26] <mwhudson> it doesn't really have to be done in js at all, i guess
[21:26] <lifeless> will your backend want to verify any of its inputs ?
[21:27] <mwhudson> not especially, only trusted people will be able to build stuff
[21:28] <mwhudson> and 'build stuff' == 'running arbitrary code on the builders' so validating anything else seems a bit redundant
[21:28] <lifeless> kk
[21:28] <lifeless> in which case, do whatever is easiest
[21:28] <mwhudson> yeah :)
=== Lcawte is now known as Lcawte|Away
=== issyl0 is now known as Guest53231