[00:27] StevenK: remind me - are we eventually going to allow info type -> Proprietary via the API or will that always be verboten? [00:28] wallyworld_: We will allow it under certain conditions. [00:28] same conditions as for when using the web ui no doubt [00:28] It's just denied for all with a strange error message because we don't want to deal with Proprietary bugs yet. [00:28] yep, just wanted to double check, thanks [00:32] wallyworld_: I refuse to fix 1005325. We decided we didn't want to support Private over the API when I exported transitionToInformationType() [00:34] StevenK: i was thinking more that the error message is confusing since we don't support user data or proprierary yet [00:34] but i guess we can ignore that for now [00:36] 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] 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] Right, it's just to avoid user confusion in the UI for now [00:37] ok. i'll mark the bug as invalid [00:37] API users already have to use tasks etc. [00:38] They can deal with a terminology difference, or continue using flags as they do already. [00:39] wallyworld_: I wonder if the trailing underline is related to the odd display issues in Opera [00:39] A box appears after the picker activators, like it's trying to render the nbsp as a character [00:39] It's very odd. [00:39] wgrant: not sure. could be by the sounds of it [00:40] worth fixing i think [00:41] The tree used there is a bit interesting. [00:41] Due to some old problems with KHTML and other browsers not showing them at all if the didn't have some content. [00:41] And stuff like that. === Ursinha is now known as Ursinha-zz === Ursinha-zz is now known as Ursinha-zzz [01:20] lifeless: Are you sure the avahi instructions work? [01:20] 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] lifeless: Because the avahi initscripts set a user-wide limit of ~2 processes [01:22] (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] the old instructions would work either [01:22] they assume persistent ip, which is in no way guaranteed [01:23] bah, english robert, english [01:23] In practice they're reasonably persistent. [01:23] And far better than avahi which in a lot of cases won't work at all [01:23] And when it does it's inconsistent at best. [01:24] did you record what you dug up ? [01:24] http://siphon9.net/loune/2011/02/avahi-setrlimit-nproc-and-lxc/ [01:25] did you file a bug? [01:26] specifically, the uid counting across boundaries is unsafe - avahi can break e.g. postgresql in a container, that way. [01:27] Right, but user namespaces will make all this go away :) [01:27] And they're meant to be happening for quantal, AIUI [01:27] indeed [01:28] So it's really not an avahi bug [01:28] The nproc limit is probably a reasonable measure. [01:28] It's just the lack of user namespacing that's breaking everything. [01:29] yes [01:29] 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 < https://launchpad.net/bugs/1005330 > [01:31] I dispute 'most correct way' [01:31] lifeless: 'most reliable and only vaguely official way' [01:31] multi-openid support, let alone browserid, is inherently hostile to using the ubuntu sso response at all :) [01:32] Sure [01:32] But there's currently no other reliable way :) [01:35] StevenK: Are you QAing the information_type thingy? [01:35] wgrant: I've just finished off the SPPH+PU QA, so that is up next, yes. [01:36] indeed [01:36] uhm [01:37] StevenK: Great. [01:39] lifeless: Yeah, anonymous is fine. [01:39] It'll crash and burn if it returns a team, since that's meant to be impossible. [01:39] No private people [01:39] And identifiers aren't secret [01:39] So there's no problem [01:41] lifeless: Is that your uhm? [01:41] Or is there something else? [01:41] it would be nice to ensure the team thing specifically [01:41] e.g. via a test or something [01:42] Maybe [01:42] I guess we can add a test now, since the DB doesn't forbid it [01:42] Will be a bit awful, but is easy [01:49] 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] bigjools: I should probably circle back and populate it for older SPPHs too [01:50] eg. changesfile [01:50] StevenK: yes, hell yes [01:50] Which currently is a hideous inaccurate query to guess the PU [01:50] bigjools: You say after objecting to it in the first place :-) [01:51] Hmmm, where is bazaar.qastaging.launchpad.net [01:51] StevenK: I still object [01:51] but since you've done it you can make it useful [01:51] bigjools: Right, fair enough [01:52] StevenK: another lovely garbo job? :) [01:52] Yup [01:52] Which will end being my fifth for the year or something [02:07] we need a bit of code that rejects bugs with the word "should" in the title [02:09] :) [02:51] * dobey files a bug that launchpad "shouldn't" do that :) [03:04] wallyworld_: Can you delete the card for 1005325 too? [03:04] yep [03:33] lifeless: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-b903a8b9cb0e54ccb8b4660ed77bb0f0 [03:33] 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] wgrant: we could partition the farms, or we could kill the xmlrpc internal socket [03:38] wgrant: (e.g. moving into the main socket and vhosting it up) [03:38] lifeless: Yeah, I think the latter is probably best, but that gets interesting. [03:39] or nuke all the internal users === Ursinha-zzz is now known as Ursinha [06:32] wgrant: https://code.launchpad.net/~stevenk/launchpad/set-spph-packageupload/+merge/107583 [06:33] StevenK: That's incorrect. [06:33] wgrant: Which part? [06:33] StevenK: That finds any PU that references the source [06:33] StevenK: That should, in fact, crash sometimes [06:33] Because delayed coppies [06:34] For a delayed copy there will be multiple PUSes for the SPR [06:34] There's no foolproof way to do this. [06:34] Bleh [06:34] You sort of have to match the archive, suite and overrides. [06:35] 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] That will get the real uploads. [06:35] Won't handle PCJs or delayed copies -- they're probably less feasible and useful to populate, though [06:40] wgrant: http://pastebin.ubuntu.com/1010807/ with appropiate tests? [06:40] Your indentation is criminal again. [06:41] 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] 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] wallyworld_: ^ And you *want* to learn Soyuz? :-) [06:52] not unless there's lots of beer involved [06:52] ah the soyuz query [06:54] wallyworld_: There has to be, one way or the other. [06:54] yep, either at the start or at the end :-) [06:55] Both has benefits, depending on which area of Soyuz [06:55] morning [06:56] there has been a lot of beer, caffeine and pizza involved in writing soyuz [06:56] You forgot swearing [06:56] And Portuglish [06:59] and combinations thereof [07:24] wgrant: http://pastebin.ubuntu.com/1010839/ modulo working and fixing tests [07:26] StevenK: That's probably OK. === jml` is now known as jml === bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2 === benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: benji | Firefighting: - | Critical bugs: 3.47*10^2 === salgado is now known as salgado-brb [14:52] is there a bug entry for +bug/NNNN/+thing pages not having cross project redirects like +bug/NNNN pages do? [14:52] can't find one with search [14:52] example case: [14:53] * user reports bug [14:53] * triager changes bug project [14:53] * user tries to add comment, gets 404 [14:55] I think my brain is atrophying; I just typoed getUniqueString as makeDistroSeries [14:56] well, they have a similar rythym [14:57] those keys are right next to each other! [14:58] ...and that was a creative misspelling [15:00] 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] 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] benji, would you land that branch for me please? [18:46] james_w: sure thing [18:46] benji, thanks [18:46] benji, not taking the day off today? [18:46] james_w: I swapped it. [18:46] ah, ok [18:47] I did all my memorializing last week. [18:51] bac: around ? [18:51] hi lifeless [18:52] bac: I want to suggest you don't land your branch [18:52] the one with test ids being allowed to be more duplicative [18:52] which one? [18:52] bug 682771 and bug 682772 [18:52] <_mup_> Bug #682771: test runner permits duplicate test ids < https://launchpad.net/bugs/682771 > [18:52] <_mup_> Bug #682772: doctest construction generates duplicate test ids < https://launchpad.net/bugs/682772 > [18:52] I had forgotten about these bugs, but they cover the situation [18:52] * bac looks [18:53] hmm [18:56] lifeless: so doctest constructors like create_interface_test_suite would need to change [18:56] * bac intercepts ec2 [18:57] bac: testtools.clone_test_with_new_id can be used to assign a unique id [18:58] 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] lifeless: are you suggesting doing that in filter_tests or in the various test_doc files? [19:00] bac: I was assuming local-to-the-duplicativeness [19:00] bac: with a sanity-check in the global test_suite() constructor to enforce uniqueness [19:00] lifeless: that's what i thought but i read your statement the other way. [19:02] 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 < https://launchpad.net/bugs/682771 > [19:02] <_mup_> Bug #682772: doctest construction generates duplicate test ids < https://launchpad.net/bugs/682772 > [19:02] you could do just 682772, but doing 682771 at the same time would give confidence that nothing has cracked through the slips [19:07] jelmer: ping (subunit) [19:10] lifeless: he;s offline today on hols but has been peeping into irc [19:11] czajkowski: thanks [19:21] lifeless:do you have a few mins spare so I can check stuff wiht you if you don't mind? [19:21] lifeless: pong [19:22] lifeless: subunit is building in the daily PPA these days [20:01] jelmer: cool - and the thing gary saw, where the built binaries use python3, but the python3 module isn't installed [20:01] czajkowski: sure, shoot [20:04] lifeless: doing the oops summaries as digo is gone and just a bit um confused. [20:04] https://devpad.canonical.com/~lpqateam/oops-summaries/production-2012-05-26.html [20:04] looking at PortConnectionError: DTPFactory timeout as an example [20:06] go on [20:06] 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] so do I created the bug based on that summary [20:07] sorry laggy this evening I suspect housemate is downloading [20:08] what do you mean 'checked the oops and they aren't reported' [20:08] well the way it was explained was I search for the bug summary and then compare the oops that have been reported [20:09] lifeless: I hadn't seen that one, looking at it now... [20:09] if they're not report and link the oops to the bug [20:12] 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] czajkowski: the reports can be dug back through by developers, theres no need to keep touching the bugs [20:12] lifeless: ah ok that wasn't explained [20:12] good to know [20:12] and thank you [20:13] also I wouldn't worry about being exhaustive [20:13] get the top 4-5 in timeouts, 4-5 in exceptions [20:13] by frequency [20:13] thats enough for folk to be getting on with. [20:13] lifeless: hmm, it looks like it defaults to python3 just on ubuntu and to python2 on debian [20:13] lifeless: I'll dig deeper tomorrow [20:13] lifeless: cheers much appreciated [20:13] jelmer: yah, so this is the thing gary was complaining about :) [20:14] jelmer: thanks! [20:14] lifeless: IIRC he was complaining about it not building, which is fixed [20:14] I'm now looking at bug 1003910 [20:14] <_mup_> Bug #1003910: subunit2junitxml failed on quantal: ImportError: No module named subunit.filters

< https://launchpad.net/bugs/1003910 > [20:16] jelmer: bug 987938 [20:16] <_mup_> Bug #987938: subunit trunk packaging breaks subunit-* commands < https://launchpad.net/bugs/987938 > [20:16] $ subunit-filter [20:16] Traceback (most recent call last): [20:16] File "/usr/bin/subunit-filter", line 33, in [20:16] from subunit import ( [20:16] ImportError: No module named subunit === benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2 [22:10] 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] you exported it for devel, and are checking devel ? [22:22] Yes [22:22] At least I think so otherwise I'm going to feel silly, but I've ntuple-checked [22:25] lifeless: e.g. http://paste.ubuntu.com/1012244/ [22:25] (as a reduced experiment) [22:28] cjwatson: hmm, I'm not sure, its something i have diligently stayed on only passing terms with [22:31] Oh, yeesh, I just found lib/lp/soyuz/interfaces/webservice.py [22:31] DRY much [22:33] Adding the new interface to the obvious two places there fixed it [22:35] do you mean ~DRY ? [22:35] I meant sarcasm [22:36] :P [22:37] (The right answer is probably in fact not to export that interface, but it's nice to know how to do it) [23:27] meep [23:27] http://pam-face-authentication.org/ [23:28] cjwatson: if you want to get really depressed about the api, there's always https://bugs.launchpad.net/launchpad/+bug/951365 [23:28] I have fear. [23:28] <_mup_> Bug #951365: Accessing milestone on project group via webservice api returns has_bugs object

< https://launchpad.net/bugs/951365 > [23:33] mwhudson_: nah, I'm trying to extend it, not get depressed about it :) [23:43] sigh firefox, please become an OS [23:43] the you might not use a full core when in the background [23:47] it has to read email before it can become an OS