[00:27] <wallyworld_> StevenK: remind me - are we eventually going to allow info type -> Proprietary via the API or will that always be verboten?
[00:28] <StevenK> wallyworld_: We will allow it under certain conditions.
[00:28] <wallyworld_> same conditions as for when using the web ui no doubt
[00:28] <StevenK> It's just denied for all with a strange error message because we don't want to deal with Proprietary bugs yet.
[00:28] <wallyworld_> yep, just wanted to double check, thanks
[00:32] <StevenK> wallyworld_: I refuse to fix 1005325. We decided we didn't want to support Private over the API when I exported transitionToInformationType()
[00:34] <wallyworld_> StevenK: i was thinking more that the error message is confusing since we don't support user data or proprierary yet
[00:34] <wallyworld_> but i guess we can ignore that for now
[00:36] <StevenK> wallyworld_: We do support User Data and Proprietary via the API. User Data will work, and show up as Private in the UI, and Proprietary will throw the terse error.
[00:37] <wallyworld_> StevenK: i also was thinking that Private was to be supported as a pseudonym for User Data but as you remind me, not over the api
[00:37] <wgrant> Right, it's just to avoid user confusion in the UI for now
[00:37] <wallyworld_> ok. i'll mark the bug as invalid
[00:37] <wgrant> API users already have to use tasks etc.
[00:38] <wgrant> They can deal with a terminology difference, or continue using flags as they do already.
[00:39] <wgrant> wallyworld_: I wonder if the trailing underline is related to the odd display issues in Opera
[00:39] <wgrant> A box appears after the picker activators, like it's trying to render the nbsp as a character
[00:39] <wgrant> It's very odd.
[00:39] <wallyworld_> wgrant: not sure. could be by the sounds of it
[00:40] <wallyworld_> worth fixing i think
[00:41] <wgrant> The tree used there is a bit interesting.
[00:41] <wgrant> Due to some old problems with KHTML and other browsers not showing them at all if the <a> didn't have some content.
[00:41] <wgrant> And stuff like that.
[01:20] <wgrant> lifeless: Are you sure the avahi instructions work?
[01:20] <wgrant> lifeless: I'm pretty sure it'll only work if you're lucky and the container's avahi user has a UID not matching anything running any other processes on the system.
[01:21] <wgrant> lifeless: Because the avahi initscripts set a user-wide limit of ~2 processes
[01:22] <wgrant> (it certainly didn't work two months ago if you tried to run avahi in two containers where it had the same UID, or if the UID matched the host's)
[01:22] <lifeless> the old instructions would work either
[01:22] <lifeless> they assume persistent ip, which is in no way guaranteed
[01:23] <lifeless> bah, english robert, english
[01:23] <wgrant> In practice they're reasonably persistent.
[01:23] <wgrant> And far better than avahi which in a lot of cases won't work at all
[01:23] <wgrant> And when it does it's inconsistent at best.
[01:24] <lifeless> did you record what you dug up ?
[01:24] <wgrant> http://siphon9.net/loune/2011/02/avahi-setrlimit-nproc-and-lxc/
[01:25] <lifeless> did you file a bug?
[01:26] <lifeless> specifically, the uid counting across boundaries is unsafe - avahi can break e.g. postgresql in a container, that way.
[01:27] <wgrant> Right, but user namespaces will make all this go away :)
[01:27] <wgrant> And they're meant to be happening for quantal, AIUI
[01:27] <lifeless> indeed
[01:28] <wgrant> So it's really not an avahi bug
[01:28] <wgrant> The nproc limit is probably a reasonable measure.
[01:28] <wgrant> It's just the lack of user namespacing that's breaking everything.
[01:29] <lifeless> yes
[01:29] <wgrant> lifeless: Bug #1005330 -- any objections/opinions before I implement it in 4 lines?
[01:29] <_mup_> Bug #1005330: Applications can't easily map an SSO account to a Launchpad one <api> <easy> <openid> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/1005330 >
[01:31] <lifeless> I dispute 'most correct way'
[01:31] <wgrant> lifeless: 'most reliable and only vaguely official way'
[01:31] <lifeless> multi-openid support, let alone browserid, is inherently hostile to using the ubuntu sso response at all :)
[01:32] <wgrant> Sure
[01:32] <wgrant> But there's currently no other reliable way :)
[01:35] <wgrant> StevenK: Are you QAing the information_type thingy?
[01:35] <StevenK> wgrant: I've just finished off the SPPH+PU QA, so that is up next, yes.
[01:36] <lifeless> indeed
[01:36] <lifeless> uhm
[01:37] <wgrant> StevenK: Great.
[01:39] <wgrant> lifeless: Yeah, anonymous is fine.
[01:39] <wgrant> It'll crash and burn if it returns a team, since that's meant to be impossible.
[01:39] <wgrant> No private people
[01:39] <wgrant> And identifiers aren't secret
[01:39] <wgrant> So there's no problem
[01:41] <wgrant> lifeless: Is that your uhm?
[01:41] <wgrant> Or is there something else?
[01:41] <lifeless> it would be nice to ensure the team thing specifically
[01:41] <lifeless> e.g. via a test or something
[01:42] <wgrant> Maybe
[01:42] <wgrant> I guess we can add a test now, since the DB doesn't forbid it
[01:42] <wgrant> Will be a bit awful, but is easy
[01:49] <bigjools> StevenK: now that you're setting pu on spph, there's probably a load of locations in the code that can be optimised to use it instead of joining/querying
[01:50] <StevenK> bigjools: I should probably circle back and populate it for older SPPHs too
[01:50] <wgrant> eg. changesfile
[01:50] <bigjools> StevenK: yes, hell yes
[01:50] <wgrant> Which currently is a hideous inaccurate query to guess the PU
[01:50] <StevenK> bigjools: You say after objecting to it in the first place :-)
[01:51] <StevenK> Hmmm, where is bazaar.qastaging.launchpad.net
[01:51] <bigjools> StevenK: I still object
[01:51] <bigjools> but since you've done it you can make it useful
[01:51] <StevenK> bigjools: Right, fair enough
[01:52] <bigjools> StevenK: another lovely garbo job? :)
[01:52] <StevenK> Yup
[01:52] <StevenK> Which will end being my fifth for the year or something
[02:07] <bigjools> we need a bit of code that rejects bugs with the word "should" in the title
[02:09] <lifeless> :)
[02:51]  * dobey files a bug that launchpad "shouldn't" do that :)
[03:04] <StevenK> wallyworld_: Can you delete the card for 1005325 too?
[03:04] <wallyworld_> yep
[03:33] <wgrant> lifeless: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-b903a8b9cb0e54ccb8b4660ed77bb0f0
[03:33] <wgrant> lifeless: Several implausibly long SQL statements on the same store on xmlrpc-private -- more evidence that we still have GIL issues with them
[03:37] <lifeless> wgrant: we could partition the farms, or we could kill the xmlrpc internal socket
[03:38] <lifeless> wgrant: (e.g. moving into the main socket and vhosting it up)
[03:38] <wgrant> lifeless: Yeah, I think the latter is probably best, but that gets interesting.
[03:39] <lifeless> or nuke all the internal users
[06:32] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/set-spph-packageupload/+merge/107583
[06:33] <wgrant> StevenK: That's incorrect.
[06:33] <StevenK> wgrant: Which part?
[06:33] <wgrant> StevenK: That finds any PU that references the source
[06:33] <wgrant> StevenK: That should, in fact, crash sometimes
[06:33] <wgrant> Because delayed coppies
[06:34] <wgrant> For a delayed copy there will be multiple PUSes for the SPR
[06:34] <wgrant> There's no foolproof way to do this.
[06:34] <StevenK> Bleh
[06:34] <wgrant> You sort of have to match the archive, suite and overrides.
[06:35] <wgrant> So if (SPPH.archive, SPPH.distroseries, SPPH.pocket) match the PU, and (SPPH.component, SPPH.section) match the SPR, it's probably the one you want.
[06:35] <wgrant> That will get the real uploads.
[06:35] <wgrant> Won't handle PCJs or delayed copies -- they're probably less feasible and useful to populate, though
[06:40] <StevenK> wgrant: http://pastebin.ubuntu.com/1010807/ with appropiate tests?
[06:40] <wgrant> Your indentation is criminal again.
[06:41] <wgrant> That's roughly correct, but it relies on my reasoning being flawless, which from 30s of thought it probably isn't.
[06:45]  * StevenK picks on DF
[06:50] <StevenK> wgrant: SELECT spph.id AS spph, pu.id AS pu FROM PackageUpload AS pu, SourcePackagePublishingHistory AS spph, SourcePackageRelease AS spr, PackageUploadSource AS pus WHERE spph.sourcepackagerelease = pus.sourcepackagerelease AND spph.sourcepackagerelease = spr.id AND pus.packageupload = pu.id AND pu.archive = spph.archive AND pu.distroseries = spph.distroseries AND pu.pocket = spph.pocket AND spph.component = spr.component AND spph.section =
[06:51] <StevenK> wallyworld_: ^ And you *want* to learn Soyuz? :-)
[06:52] <wallyworld_> not unless there's lots of beer involved
[06:52] <bigjools> ah the soyuz query
[06:54] <StevenK> wallyworld_: There has to be, one way or the other.
[06:54] <wallyworld_> yep, either at the start or at the end :-)
[06:55] <StevenK> Both has benefits, depending on which area of Soyuz
[06:55] <czajkowski> morning
[06:56] <bigjools> there has been a lot of beer, caffeine and pizza involved in writing soyuz
[06:56] <StevenK> You forgot swearing
[06:56] <StevenK> And Portuglish
[06:59] <bigjools> and combinations thereof
[07:24] <StevenK> wgrant: http://pastebin.ubuntu.com/1010839/ modulo working and fixing tests
[07:26] <wgrant> StevenK: That's probably OK.
[14:52] <mgz> is there a bug entry for +bug/NNNN/+thing pages not having cross project redirects like +bug/NNNN pages do?
[14:52] <mgz> can't find one with search
[14:52] <mgz> example case:
[14:53] <mgz> * user reports bug
[14:53] <mgz> * triager changes bug project
[14:53] <mgz> * user tries to add comment, gets 404
[14:55] <cjwatson> I think my brain is atrophying; I just typoed getUniqueString as makeDistroSeries
[14:56] <mgz> well, they have a similar rythym
[14:57] <jml> those keys are right next to each other!
[14:58] <mgz> ...and that was a creative misspelling
[15:00] <cjwatson> I think what has happened is that I've internalised about half of LaunchpadObjectFactory and my hindbrain just produces a random method from it on request
[18:45] <james_w> benji, thanks for the review of https://code.launchpad.net/~james-w/launchpad/suppress-notifications-for-all/+merge/107560 it seems that most of the changes you suggest were fixed in trunk in the meantime. I've made the one leftover change now.
[18:45] <james_w> benji, would you land that branch for me please?
[18:46] <benji> james_w: sure thing
[18:46] <james_w> benji, thanks
[18:46] <james_w> benji, not taking the day off today?
[18:46] <benji> james_w: I swapped it.
[18:46] <james_w> ah, ok
[18:47] <benji> I did all my memorializing last week.
[18:51] <lifeless> bac: around ?
[18:51] <bac> hi lifeless
[18:52] <lifeless> bac: I want to suggest you don't land your branch
[18:52] <lifeless> the one with test ids being allowed to be more duplicative
[18:52] <bac> which one?
[18:52] <lifeless> bug 682771 and bug 682772
[18:52] <_mup_> Bug #682771: test runner permits duplicate test ids <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/682771 >
[18:52] <_mup_> Bug #682772: doctest construction generates duplicate test ids <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/682772 >
[18:52] <lifeless> I had forgotten about these bugs, but they cover the situation
[18:52]  * bac looks
[18:53] <bac> hmm
[18:56] <bac> lifeless: so doctest constructors like create_interface_test_suite would need to change
[18:56]  * bac intercepts ec2
[18:57] <lifeless> bac: testtools.clone_test_with_new_id can be used to assign a unique id
[18:58] <lifeless> bac: create the test (duplicative id); then clone it to a new id, and add the resulting new-id test into the suite, let the original get gc'd.
[18:59] <bac> lifeless: are you suggesting doing that in filter_tests or in the various test_doc files?
[19:00] <lifeless> bac: I was assuming local-to-the-duplicativeness
[19:00] <lifeless> bac: with a sanity-check in the global test_suite() constructor to enforce uniqueness
[19:00] <bac> lifeless: that's what i thought but i read your statement the other way.
[19:02] <lifeless> I think bug 682771 will be fixed if the e.g. ./bin/test --list-tests errors when the are duplicates, and bug 682772 will be fixed when the current duplicates are fixed up
[19:02] <_mup_> Bug #682771: test runner permits duplicate test ids <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/682771 >
[19:02] <_mup_> Bug #682772: doctest construction generates duplicate test ids <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/682772 >
[19:02] <lifeless> you could do just 682772, but doing 682771 at the same time would give confidence that nothing has cracked through the slips
[19:07] <lifeless> jelmer: ping (subunit)
[19:10] <czajkowski> lifeless: he;s offline today on hols but has been peeping into irc
[19:11] <lifeless> czajkowski: thanks
[19:21] <czajkowski> lifeless:do you have a few mins spare so I can check stuff wiht you if you don't mind?
[19:21] <jelmer> lifeless: pong
[19:22] <jelmer> lifeless: subunit is building in the daily PPA these days
[20:01] <lifeless> jelmer: cool - and the thing gary saw, where the built binaries use python3, but the python3 module isn't installed
[20:01] <lifeless> czajkowski: sure, shoot
[20:04] <czajkowski> lifeless: doing the oops summaries as digo is gone and just a bit um confused.
[20:04] <czajkowski> https://devpad.canonical.com/~lpqateam/oops-summaries/production-2012-05-26.html
[20:04] <czajkowski> looking at PortConnectionError: DTPFactory timeout  as an example
[20:06] <lifeless> go on
[20:06] <czajkowski> sp when I search for bugs with that title they don't exist, so I checked the oops and they aren't reported
[20:06] <czajkowski> so do I created the bug based on that summary
[20:07] <czajkowski> sorry laggy this evening I suspect housemate is downloading
[20:08] <lifeless> what do you mean 'checked the oops and they aren't reported'
[20:08] <czajkowski> well the way it was explained was I search for the bug summary and then compare the oops that have been reported
[20:09] <jelmer> lifeless: I hadn't seen that one, looking at it now...
[20:09] <czajkowski> if they're not report and link the oops to the bug
[20:12] <lifeless> czajkowski: ok, so yes you search, if there is no open bug, then file one; if there is an open bug, don't bother linking the new oopses in unless the bug hasn't been touched in months - that would just be make-work.
[20:12] <lifeless> czajkowski: the reports can be dug back through by developers, theres no need to keep touching the bugs
[20:12] <czajkowski> lifeless: ah ok that wasn't explained
[20:12] <czajkowski> good to know
[20:12] <czajkowski> and thank you
[20:13] <lifeless> also I wouldn't worry about being exhaustive
[20:13] <lifeless> get the top 4-5 in timeouts, 4-5 in exceptions
[20:13] <lifeless> by frequency
[20:13] <lifeless> thats enough for folk to be getting on with.
[20:13] <jelmer> lifeless: hmm, it looks like it defaults to python3 just on ubuntu and to python2 on debian
[20:13] <jelmer> lifeless: I'll dig deeper tomorrow
[20:13] <czajkowski> lifeless: cheers much appreciated
[20:13] <lifeless> jelmer: yah, so this is the thing gary was complaining about :)
[20:14] <lifeless> jelmer: thanks!
[20:14] <jelmer> lifeless: IIRC he was complaining about it not building, which is fixed
[20:14] <jelmer> I'm now looking at bug 1003910
[20:14] <_mup_> Bug #1003910: subunit2junitxml failed on quantal: ImportError: No module named subunit.filters <amd64> <apport-bug> <qa-daily-testing> <quantal> <rls-mgr-p-tracking> <running-unity> <subunit (Ubuntu):Triaged> < https://launchpad.net/bugs/1003910 >
[20:16] <lifeless> jelmer: bug 987938
[20:16] <_mup_> Bug #987938: subunit trunk packaging breaks subunit-* commands <subunit:In Progress by jelmer> < https://launchpad.net/bugs/987938 >
[20:16] <lifeless> $ subunit-filter
[20:16] <lifeless> Traceback (most recent call last):
[20:16] <lifeless>   File "/usr/bin/subunit-filter", line 33, in <module>
[20:16] <lifeless>     from subunit import (
[20:16] <lifeless> ImportError: No module named subunit
[22:10] <cjwatson> I'm thoroughly lost.  Is there any documentation anywhere on how to debug the case where you've done export_as_webservice_entry on a class but it's stubbornly refusing to show up in the generated WADL?
[22:21] <lifeless> you exported it for devel, and are checking devel ?
[22:22] <cjwatson> Yes
[22:22] <cjwatson> At least I think so otherwise I'm going to feel silly, but I've ntuple-checked
[22:25] <cjwatson> lifeless: e.g. http://paste.ubuntu.com/1012244/
[22:25] <cjwatson> (as a reduced experiment)
[22:28] <lifeless> cjwatson: hmm, I'm not sure, its something i have diligently stayed on only passing terms with
[22:31] <cjwatson> Oh, yeesh, I just found lib/lp/soyuz/interfaces/webservice.py
[22:31] <cjwatson> DRY much
[22:33] <cjwatson> Adding the new interface to the obvious two places there fixed it
[22:35] <lifeless> do you mean ~DRY ?
[22:35] <cjwatson> I meant sarcasm
[22:36] <lifeless> :P
[22:37] <cjwatson> (The right answer is probably in fact not to export that interface, but it's nice to know how to do it)
[23:27] <lifeless> meep
[23:27] <lifeless> http://pam-face-authentication.org/
[23:28] <mwhudson_> cjwatson: if you want to get really depressed about the api, there's always https://bugs.launchpad.net/launchpad/+bug/951365
[23:28] <StevenK> I have fear.
[23:28] <_mup_> Bug #951365: Accessing milestone on project group via webservice api returns has_bugs object <api> <milestones> <oem-services> <projectgroups> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/951365 >
[23:33] <cjwatson> mwhudson_: nah, I'm trying to extend it, not get depressed about it :)
[23:43] <lifeless> sigh firefox, please become an OS
[23:43] <lifeless> the you might not use a full core when in the background
[23:47] <bigjools> it has to read email before it can become an OS