[00:24] sinzui: http://people.canonical.com/~ianb/new-related-projects.png [00:25] remove bugs, questions, blueprints; add the role info as shown [00:26] i think this then fixes bug 996599 [00:26] <_mup_> Bug #996599: Related projects does not say how the person is related

< https://launchpad.net/bugs/996599 > [00:26] Bleh, I can't copy stuff into the bzr ppa [00:27] cjwatson: There's a small potential issue with your source suite branch: the source series is looked up in the target archive's distribution, so it can't be used to do an explicit copy from another distro [00:27] Not an issue in practice today, though [00:35] lifeless, maxb: Can one of you please copy bzr-git 0.6.9-1~bazaar1~precise1 from bzr-proposed Quantal to bzr Quantal so that the bzr PPA has an index for Quantal? [00:50] StevenK: you could just fix that bug [00:51] lifeless: About needing a package published to produce indices? Yeah, no. [00:51] yeah, you could [00:51] lifeless: And you could just copy the package, too. :-) [00:53] The bug's not very easy to fix, and it's not quite clear what the fix is [00:54] StevenK: so why do you need a quantal index? doesn't apt deal ? [00:54] wgrant: as in, do you want empty indices ? [00:54] lifeless: Right [00:55] lifeless: As a PPA owner I don't want to support natty [00:55] Why does my PPA have natty indices? [00:55] wgrant: you want just in time indices! [00:55] It confuses my users :( [00:55] wgrant: thats clearly orthogonal [00:55] wgrant: as otherwise any mistake leads to the same sitation and no way out [00:55] It may lead to an undesirable situation, sure [00:56] Doesn't mean it's entirely orthogonal [00:56] lifeless: No, apt does not deal [00:56] lifeless: And rf-setup will add the bzr ppa for [00:56] hah [00:56] uhm [00:56] I don't want to put the wrong thing in there is all [01:00] lifeless: The version of bzr-git as published in Quantal is higher anyway, we just need *something* copied in [01:02] done [01:04] lifeless: Thanks [02:07] wallyworld_: You can change your sources.list entry for the LP PPA to quantal, it will work fine [02:07] StevenK: awesome thanks [02:07] It will probably want to upgrade a few things, just due to q sorting higher than p [02:58] * StevenK tries to find a bugwatch with comments [03:23] wgrant: StevenK: do you have any recollection of what causes timeouts in merging people based on any past experience looking at oopses? i have a bug report but the oops has been deleted. i'm working on another bug and could potentially put in some effort to fix a merge timeout root cause as a drive by, but need info [03:25] wallyworld_: Lots and lots and lots of FKs [03:25] wallyworld_: They've mostly gone away now, since it's asynchronous [03:25] The FK thing is only relatively minor now [03:25] the bit i'm looking at is 189 queries to collect the fk references [03:26] wallyworld_: Person merging is a job now [03:26] yes but isn;t a check done first? [03:26] to see if merging is possible? [03:27] It has no reason to check all the FKs [03:27] But perhaps it does [03:27] i'll look a little more, it could be the 189 queries is done in the job so it doesn't matter [03:27] so much [03:28] so it raises a RuntimeError in IPersonSet.merge if the FK stuff is not as it should be [03:30] and that's done in the job [04:19] * StevenK tries to work out how to delete a bugwatch [04:20] edit, delete [04:20] iirc [04:22] From a bug page? [04:28] Yeas [05:32] wallyworld_: Why don't we need to cascade, and are we sure that union will not perform absolutely terribly? [05:48] wgrant: Is an unlinked bugwatch with a comment a plausible scenario? [05:49] StevenK: Not linked to a task, just a bug? [05:50] wgrant: Well, I suspect it's invalid -- I'm using factory.makeBugComment(bug_watch=) rather than IBugWatch.addComment() [05:51] It may be invalid, but I'm not sure if it's relevant [05:51] 16:32:54 < wgrant> wallyworld_: Why don't we need to cascade, and are we sure that union will not perform absolutely terribly? [05:51] wgrant: bug 301740 [05:51] <_mup_> Bug #301740: It should be possible to delete an auto-generated bugwatch that has comments attached

< https://launchpad.net/bugs/301740 > [05:51] Yes, but I'm not sure how that's relevant to "an unlinked bugwatch with a comment" [05:52] wgrant: Apparently, it OOPSes. Based on my reading of the code, it will only do that if it has no linked bugtasks and it has a bugmessage that references the bugwatch and IBugWatch.getImportedBugMessages() is empty [05:56] StevenK: Well, I'd check the DB to see if there are any bugmessages with a bugwatch but no remote_comment_id [06:01] So, there are. So, awesome! [06:02] So I saw [06:04] https://bugs.launchpad.net/hplip/+bug/1031503 is the most recent [06:04] <_mup_> Bug #1031503: hplip-3.12.6 fails to scan on Photosmart_C309a < https://launchpad.net/bugs/1031503 > [06:07] wgrant: sorry, missed that question before. i'm not sure i understand what you are asking wrt cascading? [06:07] the indirect references are only applicable for merge jobs [06:08] since there is the need to check any and all indirect delete cascading [06:09] but here for this case, we only care about whether there are any referencing columns [06:10] Ah, fair point [06:15] Ah ha [06:15] I wonder if it's the Awaiting synchronization comments [06:16] wgrant: and the union has got to be better than 189 individual, separate queries, each using a separate db call. the union does the same thing, but just in one db call [06:17] Hm, how do I check that [06:17] * StevenK cheats and uses mawson [06:18] Right, it is indeed, the Awaiting synchronization comment [06:20] wallyworld: It's better in terms of roundtrips, but it's not necessarily better in terms of optimisation [06:20] In fact it's almost certainly much worse [06:21] hello hackers [06:21] Morning bigjools [06:21] bigjools: How is sunny, downtown Copenhagen? [06:21] evening [06:21] StevenK: haven't seen any sunlight since I got here - and we're not downtown, it's another "Brussels" [06:22] In more ways than one [06:22] Hahaha [06:22] bigjools: Oh, you're 20 minutes in the forest? [06:22] In its defense, it was a pretty nice forest [06:22] StevenK: worse - in a faceless, flat area with no trees near the airport [06:23] bigjools: stop whinging [06:23] :/ [06:23] wallyworld: blow me [06:23] i'll let StevenK do that [06:23] take one for the team [06:24] haha [06:24] But wallyworld will enjoy it much more [06:24] only if i skipped breakfast [06:25] dog barking, gotta investigate [06:59] wgrant: Isn't there already a bug for LocationError: (None, 'builder') [07:01] Found it, since it's Fix Released [07:43] quite a crowd at UDS ;) [07:44] nigelb: are you there ? [07:45] lifeless: No. I was commenting on the joins ^^ [07:45] party time! === almaisan-away is now known as al-maisan [08:42] wgrant: The missing -proposed announcements were actually a list mail configuration bug. Apparently raring-changes is misconfigured and is requiring manual moderation. [08:43] I hadn't realised that and will chase it up at some point, since that's clearly ridiculous. [08:47] cjwatson: I was going to ask you to check that, since I could see nothing else wrong [08:48] Though I thought the settings were carried across from quantal-changes [08:48] So did I. But IS denied knowledge. [08:48] I'll try a different sysadmin at some point :-) [08:48] Heh [09:06] How do I 'bzr lp-land' onto db-devel? I've already run the full test suite. [09:06] It'll detect from the MP [09:06] So 'bzr lp-land' [09:06] Ah, OK [09:15] cjwatson: ec2 land and bzr lp-land will prod at the relevant MP to work out how to land it. bzr pqm-submit has to be told by hand. [09:30] wgrant: Thanks for spotting that bug in my copy-explicit-pocket branch. How does https://code.launchpad.net/~cjwatson/launchpad/copy-explicit-pocket-2/+merge/131145 look? [09:31] anyone know what I'm missing in my locations.conf to get a "ERROR: No PQM submission email address specified" when lp-land'ing? [09:31] it's copied from my working install from before, I've got email, pqm_email, and pqm_user_email all set in there [09:31] pqm_email = Canonical PQM [09:32] cjwatson: r=me, thanks [09:32] hmmpqm_email = Launchpad PQM [09:32] grrrr [09:32] rick_h_: locations.conf is set by path, perhaps that's different? [09:32] rick_h_: Is your Launchpad tree in the same spot? [09:32] wgrant: yea, it's the default setup from a rocketfuel [09:33] Hah, wgrant and I come to the same conclusion at roughly the same time. [09:33] rick_h_: does 'bzr config' in the branch show pqm_email? [09:33] ah, I see part of my problems I think. [09:33] wgrant: no, don't see it [09:34] Then check the headers in .bazaar/locations.conf versus your current path [09:34] StevenK: ah, you're right gotcha. I forgot I had the ubuntu user on the vm [09:36] So, if buildbot passes, would there be any chance of an FDT today? I'm running out of time to get the -proposed migration stuff working before UDS :-) [09:38] oh son of a ... [09:39] cjwatson: We're going to miss the 10UTC window, but we can probably just ignore that and do it at our leisure [09:39] The next window (in 8ish hours) is unstaffed [09:40] Apart from sinzui and jcackett [09:40] Otherwise we can do the window in 16 hours [09:43] wgrant: StevenK thanks guys, think I got it in now. [09:43] rick_h_: Great [09:44] cjwatson: So, when do you expect to have the code changes ready/ [09:44] Heh, I'm just pushing a first cut as I type [09:44] Ah, so then it's 'RSN' [09:44] (In the expectation that it will need some review fixes, mind) [09:55] cjwatson: You seem to log the warning twice [10:04] Oh, because of the nascentupload / uploadprocessor split, I guess [10:04] Maybe this is a case where a doctest would actually be useful [10:04] But I'll see what I can pick out of test_uploadprocessor [10:11] Hmm, I only see one warning ... [10:21] Also, there seems to be a DB patch already ahead of mine in the queue - or was that applied live? === jtv1 is now known as jtv === al-maisan is now known as almaisan-away [10:42] cjwatson: Well, two places in the code log it. [10:42] Yeah, I was just trying to work out why I wasn't seeing it in practice, but I've got it now [10:43] Ah, and indeed there is still one in the queue, hmm [11:05] wgrant: fixed [11:08] cjwatson: Indeed, thanks [11:08] cjwatson: I'm not quite seeing how queue admins manage to bypass it [11:09] *blink* That's a good question, so how come that test passes ... [11:09] It looks like it'll just reject, which must mean the last test is wrong [11:09] Exactly [11:10] Oh, blast, silly CannotCopy handling [11:11] Yeah, right, fixed the test [11:12] (locally - working on the model) [11:20] You had me quite worried there for a few minutes, as I struggled to work out how I had so fundamentally misunderstood the uploadprocessor checks :) [11:28] dpm: O Hai. We've updated translations for raring on staging. The pages might require a bunch of reloads to load, but can you check it out? [11:34] heyt StevenK, thanks, looking... [11:36] dpm: I'm about to crash into bed, but if it looks good, we should be able to run the script on production tomorrow. [11:37] dpm: Drop me a note here, and I'll see it when I wake. [11:38] StevenK, I'm looking at https://translations.staging.launchpad.net/ubuntu/raring and I don't see any translations yet. Does it need to take a while to update the stats? [11:38] wgrant: OK, should be fixed [11:39] dpm: We haven't actually turned it all on, we've only run copy-translations-to-parent on staging, but the +translate URLs for raring source packages should work [11:39] StevenK, I can see that the templates have been copied ok from quantal at https://translations.staging.launchpad.net/ubuntu/raring/+templates but I the translations themselves still don't appear on the stats page at https://translations.staging.launchpad.net/ubuntu/raring [11:40] I'll have another look later on in case it takes sometime for the stats to be updated or translations to be imported [11:40] dpm: Ah, those are run by cron, which we don't run on staging [11:40] s/run/updated/ [11:41] It would be worth running that manually. [11:42] StevenK, gotcha. In any case, without the stats it's really difficult to see whether the translations look overall right. I'm trying to look at individual templates right now, but it's timing out [11:42] dpm: Templates should load after a refresh or two [11:43] thanks wgrant, that did it. [11:44] wgrant: What does the stats? cronscripts/rosetta-pofile-stats.py ? [11:44] StevenK: Heh heh heh [11:44] You may recognise that script [11:44] Quite [11:45] StevenK, so at a quick glance I can confirm that the translations are indeed in some individual templates such as https://translations.staging.launchpad.net/ubuntu/raring/+source/gfxboot-theme-ubuntu/+pots/bootloader/ca/+translate - but updating the overall stats would give us a much better picture [11:46] Ah ha, cronscripts/update-stats.pu [11:46] *py [11:47] No [11:47] That's the global stats [11:50] wgrant: Then it is the great evilness that is rosetta-pofile-stats ? [11:50] StevenK: I suspect so [11:50] I doubt the copier creates jobs [11:51] IDistroSeries.updateStatistics() did look relevant, though [11:52] That mostly just creates DistroSeriesLanguages [11:52] We care about POFile stats [11:53] wgrant: What about the last bit, which is updating the message counts for the series itself? [11:53] Not very interesting for this [11:53] Well, slightly [11:53] But it's not the main thing that matters [11:54] dpm: So with the stats updated it should be identical to precise? [11:55] Er, quantal, even [11:55] StevenK, yes, identical to quantal, as the translations imports from package uploads are disabled for raring, so no new translations should have come in [11:56] dpm: Right, I'll sort that out -- I'll prod you tomorrow to have another look [11:57] StevenK: So, we could lower taxes to support POFileStatsJob creators, or we could be socialist and spend probably about 4 days running rosetta-pofile-stats [11:57] ok cool, thanks StevenK :) [11:57] Ew, 4 days [11:57] It's probably faster to create jobs [11:57] wgrant: Let's talk about it on the call tomorrow [11:57] Indeedily === almaisan-away is now known as al-maisan [12:20] gary_poster: ping, deryck wants to know where you are === dpm__ is now known as dpm === al-maisan is now known as almaisan-away [14:48] jcsackett, r=me [14:49] sinzui: awesome. off it goes. === yofel_ is now known as yofel [16:06] I'm having great difficulty figuring out the problem in bug 1070804. Can anyone help me out? [16:06] <_mup_> Bug #1070804: Error notification by mails doesn't describe the error

< https://launchpad.net/bugs/1070804 > [16:06] I'm using http://paste.ubuntu.com/1302902/, which indeed causes the test to fail [16:06] But CannotCopy is in PlainPackageCopyJob.user_error_types, which *should* suppress this [16:08] If I use pdb to stop in JobRunner.runJobHandleError, the exception that's raised is an instance of CannotCopy, and job.user_error_types is indeed (,) - it's not the case that user_error_types is being defined in the wrong place, as far as I can tell [16:09] But the except doesn't fire, and I get: [16:09] (Pdb) p isinstance(info[1], job.user_error_types) [16:09] *** TypeError: TypeError('isinstance() arg 2 must be a class, type, or tuple of classes and types',) [16:10] which has me totally baffled because as far as I can tell it *is* a tuple of types [16:10] ('isinstance(info[1], (CannotCopy,))' returns True) [16:10] Is this a Zope weirdness, or a Python weirdness, or what? === dpm is now known as dpm-afk [16:50] cjwatson, I am still thinking about this. I think this is python, not zope, but I agree that (CannotCopy,) is tuple [17:09] * cjwatson wonders if a debug build of Python will make life any clearer [17:10] (But then I would have to rebuild all the extensions needed, argh) [17:17] sinzui: Ah - job.user_error_types is security-proxied [17:17] buggery [17:17] isinstance(info[1], removeSecurityProxy(job.user_error_types)) -> True [17:17] So is the right answer here to use 'except removeSecurityProxy(job.user_error_types) as e:' ? [17:18] Seems a little clunky ... [17:18] that's yuck [17:18] y [17:18] I don't think any error should be wrapped in a proxy [17:19] Well, the error isn't, but the attribute retrieved from job is [17:19] ah, be I see we got the job via a zope utility, so all attrs are wrapped [17:20] (rSP there does work) [17:20] Is there a way to declare some attributes as always being unproxied? [17:20] doesn't this mean that lazr.jobrunner.jobrunner never gets the tuple it expects [17:21] no, but there is a helper that will unwrap everything. we use in webapp.authenticate I think [17:23] cjwatson, we can create a property on our job class that unwraps and returns the error classes... [17:24] maybe we want the property to be on out base class, so that all subclasses define a private attr with the attr classes [17:24] * cjwatson tries that [17:25] haha, there's already one of these for retry_error_types, called retryErrorTypes [17:27] So it kind of seems to me that to avoid surprising future developers we should add a userErrorTypes property to LP, deploy that, then add userErrorTypes support to lazr.jobrunner [17:28] Does that make sense? [17:29] Otherwise we have two very similar things using different patterns === Ursinha-afk is now known as Ursinha [17:30] we could avoid changing lazr by instead defining our user_error_types property on lp.services.job... the four cases that have the property get a leading underscore to make them private [17:31] Sure, but then we'd have two things right next to each other that should really look the same but are different [17:31] Is that worth it to avoid changing lazr? [17:31] It sort of seems like a "future developers will curse thy name" to me [17:32] cjwatson, http://paste.ubuntu.com/1303118/ looks right to me because lazr.job is not zope, so the zope implementations are violating the contract [17:32] By which I mean, user_error_types and retry_error_types are literally right next to each other in BaseRunnableJob [17:32] They should surely be handled similarly [17:33] ah, yes, they must be treated the same [17:33] (BaseJob, I mean) [17:35] Actually, with the way the code is structured, it could work either way round; doing lazr.jobrunner first would make QA easier [17:36] right, so we want the same solution, and lazr.job has chosen its method approach [17:43] Also, lazr.jobrunner is only at 0.9 on PyPI for some reason; what happened to 0.10? [17:44] adeuring: ^- [20:40] sinzui: if you have time, short review for you https://code.launchpad.net/~jcsackett/launchpad/email-authentication-type-error/+merge/131282/ [20:40] * sinzui looks [20:42] jcsackett, I have a script I use to send "volleys" of emails at Lp. We might be able to use to to contrive the example address in the bug [20:43] jcsackett, did I ever send you testemail.py [20:47] sinzui: you did not, but it sounds promising. [20:48] (or if you did, i have since forgotten). [20:48] I will send it [20:48] awesome. [21:00] jcsackett, you might want to just run all the tests in lp.services.mail and on success, lp-land the branch [22:10] StevenK, https://bugs.launchpad.net/launchpad/+bug/401633 , I found people removed the unused attrs, but left the schema behind [22:10] <_mup_> Bug #401633: Remove POTMsgSet.potemplate from db schema.

< https://launchpad.net/bugs/401633 > [22:30] StevenK, https://bugs.launchpad.net/launchpad/+bug/373269 is the bug I was thinking of about message-sharing [22:30] <_mup_> Bug #373269: Message sharing and POFile statistics

< https://launchpad.net/bugs/373269 > [22:38] wgrant, https://wiki.canonical.com/Launchpad/Translations/UbuntuOpenings