[00:24] <wallyworld_> sinzui: http://people.canonical.com/~ianb/new-related-projects.png
[00:25] <wallyworld_> remove bugs, questions, blueprints; add the role info as shown
[00:26] <wallyworld_> i think this then fixes bug 996599
[00:26] <_mup_> Bug #996599: Related projects does not say how the person is related <confusing-ui> <lp-registry> <related-projects-packages> <Launchpad itself:Triaged> < https://launchpad.net/bugs/996599 >
[00:26] <StevenK> Bleh, I can't copy stuff into the bzr ppa
[00:27] <wgrant> 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] <wgrant> Not an issue in practice today, though
[00:35] <StevenK> 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] <lifeless> StevenK: you could just fix that bug
[00:51] <StevenK> lifeless: About needing a package published to produce indices? Yeah, no.
[00:51] <lifeless> yeah, you could
[00:51] <StevenK> lifeless: And you could just copy the package, too. :-)
[00:53] <wgrant> The bug's not very easy to fix, and it's not quite clear what the fix is
[00:54] <lifeless> StevenK: so why do you need a quantal index? doesn't apt deal ?
[00:54] <lifeless> wgrant: as in, do you want empty indices ?
[00:54] <wgrant> lifeless: Right
[00:55] <wgrant> lifeless: As a PPA owner I don't want to support natty
[00:55] <wgrant> Why does my PPA have natty indices?
[00:55] <lifeless> wgrant: you want just in time indices!
[00:55] <wgrant> It confuses my users :(
[00:55] <lifeless> wgrant: thats clearly orthogonal
[00:55] <lifeless> wgrant: as otherwise any mistake leads to the same sitation and no way out
[00:55] <wgrant> It may lead to an undesirable situation, sure
[00:56] <wgrant> Doesn't mean it's entirely orthogonal
[00:56] <StevenK> lifeless: No, apt does not deal
[00:56] <StevenK> lifeless: And rf-setup will add the bzr ppa for <release>
[00:56] <lifeless> hah
[00:56] <lifeless> uhm
[00:56] <lifeless> I don't want to put the wrong thing in there is all
[01:00] <StevenK> lifeless: The version of bzr-git as published in Quantal is higher anyway, we just need *something* copied in
[01:02] <lifeless> done
[01:04] <StevenK> lifeless: Thanks
[02:07] <StevenK> wallyworld_: You can change your sources.list entry for the LP PPA to quantal, it will work fine
[02:07] <wallyworld_> StevenK: awesome thanks
[02:07] <StevenK> 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] <wallyworld_> 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] <StevenK> wallyworld_: Lots and lots and lots of FKs
[03:25] <wgrant> wallyworld_: They've mostly gone away now, since it's asynchronous
[03:25] <wgrant> The FK thing is only relatively minor now
[03:25] <wallyworld_> the bit i'm looking at is 189 queries to collect the fk references
[03:26] <StevenK> wallyworld_: Person merging is a job now
[03:26] <wallyworld_> yes but isn;t a check done first?
[03:26] <wallyworld_> to see if merging is possible?
[03:27] <wgrant> It has no reason to check all the FKs
[03:27] <wgrant> But perhaps it does
[03:27] <wallyworld_> i'll look a little more, it could be the 189 queries is done in the job so it doesn't matter
[03:27] <wallyworld_> so much
[03:28] <wallyworld_> so it raises a RuntimeError in IPersonSet.merge if the FK stuff is not as it should be
[03:30] <wallyworld_> and that's done in the job
[04:19]  * StevenK tries to work out how to delete a bugwatch
[04:20] <wgrant> edit, delete
[04:20] <wgrant> iirc
[04:22] <StevenK> From a bug page?
[04:28] <wgrant> Yeas
[05:32] <wgrant> wallyworld_: Why don't we need to cascade, and are we sure that union will not perform absolutely terribly?
[05:48] <StevenK> wgrant: Is an unlinked bugwatch with a comment a plausible scenario?
[05:49] <wgrant> StevenK: Not linked to a task, just a bug?
[05:50] <StevenK> wgrant: Well, I suspect it's invalid -- I'm using factory.makeBugComment(bug_watch=) rather than IBugWatch.addComment()
[05:51] <wgrant> It may be invalid, but I'm not sure if it's relevant
[05:51] <wgrant> 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] <StevenK> wgrant: bug 301740
[05:51] <_mup_> Bug #301740: It should be possible to delete an auto-generated bugwatch that has comments attached <bugwatch> <lp-bugs> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/301740 >
[05:51] <wgrant> Yes, but I'm not sure how that's relevant to "an unlinked bugwatch with a comment"
[05:52] <StevenK> 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] <wgrant> StevenK: Well, I'd check the DB to see if there are any bugmessages with a bugwatch but no remote_comment_id
[06:01] <StevenK> So, there are. So, awesome!
[06:02] <wgrant> So I saw
[06:04] <StevenK> 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 <HPLIP:New> <Gentoo Linux:Fix Released> < https://launchpad.net/bugs/1031503 >
[06:07] <wallyworld> wgrant: sorry, missed that question before. i'm not sure i understand what you are asking wrt cascading?
[06:07] <wallyworld> the indirect references are only applicable for merge jobs
[06:08] <wallyworld> since there is the need to check any and all indirect delete cascading
[06:09] <wallyworld> but here for this case, we only care about whether there are any referencing columns
[06:10] <wgrant> Ah, fair point
[06:15] <StevenK> Ah ha
[06:15] <StevenK> I wonder if it's the  Awaiting synchronization comments
[06:16] <wallyworld> 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] <StevenK> Hm, how do I check that
[06:17]  * StevenK cheats and uses mawson
[06:18] <StevenK> Right, it is indeed, the Awaiting synchronization comment
[06:20] <wgrant> wallyworld: It's better in terms of roundtrips, but it's not necessarily better in terms of optimisation
[06:20] <wgrant> In fact it's almost certainly much worse
[06:21] <bigjools> hello hackers
[06:21] <wgrant> Morning bigjools
[06:21] <StevenK> bigjools: How is sunny, downtown Copenhagen?
[06:21] <bigjools> evening
[06:21] <bigjools> StevenK: haven't seen any sunlight since I got here - and we're not downtown, it's another "Brussels"
[06:22] <wgrant> In more ways than one
[06:22] <StevenK> Hahaha
[06:22] <StevenK> bigjools: Oh, you're 20 minutes in the forest?
[06:22] <wgrant> In its defense, it was a pretty nice forest
[06:22] <bigjools> StevenK: worse - in a faceless, flat area with no trees near the airport
[06:23] <wallyworld> bigjools: stop whinging
[06:23] <wgrant> :/
[06:23] <bigjools> wallyworld: blow me
[06:23] <wallyworld> i'll let StevenK do that
[06:23] <wallyworld> take one for the team
[06:24] <bigjools> haha
[06:24] <StevenK> But wallyworld will enjoy it much more
[06:24] <wallyworld> only if i skipped breakfast
[06:25] <wallyworld> dog barking, gotta investigate
[06:59] <StevenK> wgrant: Isn't there already a bug for LocationError: (None, 'builder')
[07:01] <StevenK> Found it, since it's Fix Released
[07:43] <nigelb> quite a crowd at UDS ;)
[07:44] <lifeless> nigelb: are you there ?
[07:45] <nigelb> lifeless: No. I was commenting on the joins ^^
[07:45] <rick_h_> party time!
[08:42] <cjwatson> wgrant: The missing -proposed announcements were actually a list mail configuration bug.  Apparently raring-changes is misconfigured and is requiring manual moderation.
[08:43] <cjwatson> I hadn't realised that and will chase it up at some point, since that's clearly ridiculous.
[08:47] <wgrant> cjwatson: I was going to ask you to check that, since I could see nothing else wrong
[08:48] <wgrant> Though I thought the settings were carried across from quantal-changes
[08:48] <cjwatson> So did I.  But IS denied knowledge.
[08:48] <cjwatson> I'll try a different sysadmin at some point :-)
[08:48] <wgrant> Heh
[09:06] <cjwatson> How do I 'bzr lp-land' onto db-devel?  I've already run the full test suite.
[09:06] <wgrant> It'll detect from the MP
[09:06] <wgrant> So 'bzr lp-land'
[09:06] <cjwatson> Ah, OK
[09:15] <StevenK> 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] <cjwatson> 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] <rick_h_> 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] <rick_h_> 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] <cjwatson> pqm_email = Canonical PQM <launchpad@pqm.canonical.com>
[09:32] <wgrant> cjwatson: r=me, thanks
[09:32] <rick_h_> hmmpqm_email = Launchpad PQM <launchpad@pqm.canonical.com>
[09:32] <rick_h_> grrrr
[09:32] <StevenK> rick_h_: locations.conf is set by path, perhaps that's different?
[09:32] <wgrant> rick_h_: Is your Launchpad tree in the same spot?
[09:32] <rick_h_> wgrant: yea, it's the default setup from a rocketfuel
[09:33] <StevenK> Hah, wgrant and I come to the same conclusion at roughly the same time.
[09:33] <wgrant> rick_h_: does 'bzr config' in the branch show pqm_email?
[09:33] <rick_h_> ah, I see part of my problems I think.
[09:33] <rick_h_> wgrant: no, don't see it
[09:34] <StevenK> Then check the headers in .bazaar/locations.conf versus your current path
[09:34] <rick_h_> StevenK: ah, you're right gotcha. I forgot I had the ubuntu user on the vm
[09:36] <cjwatson> 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] <rick_h_> oh son of a ...
[09:39] <wgrant> cjwatson: We're going to miss the 10UTC window, but we can probably just ignore that and do it at our leisure
[09:39] <wgrant> The next window (in 8ish hours) is unstaffed
[09:40] <wgrant> Apart from sinzui and jcackett
[09:40] <wgrant> Otherwise we can do the window in 16 hours
[09:43] <rick_h_> wgrant: StevenK thanks guys, think I got it in now.
[09:43] <wgrant> rick_h_: Great
[09:44] <wgrant> cjwatson: So, when do you expect to have the code changes ready/
[09:44] <cjwatson> Heh, I'm just pushing a first cut as I type
[09:44] <StevenK> Ah, so then it's 'RSN'
[09:44] <cjwatson> (In the expectation that it will need some review fixes, mind)
[09:55] <wgrant> cjwatson: You seem to log the warning twice
[10:04] <cjwatson> Oh, because of the nascentupload / uploadprocessor split, I guess
[10:04] <cjwatson> Maybe this is a case where a doctest would actually be useful
[10:04] <cjwatson> But I'll see what I can pick out of test_uploadprocessor
[10:11] <cjwatson> Hmm, I only see one warning ...
[10:21] <cjwatson> Also, there seems to be a DB patch already ahead of mine in the queue - or was that applied live?
[10:42] <wgrant> cjwatson: Well, two places in the code log it.
[10:42] <cjwatson> Yeah, I was just trying to work out why I wasn't seeing it in practice, but I've got it now
[10:43] <wgrant> Ah, and indeed there is still one in the queue, hmm
[11:05] <cjwatson> wgrant: fixed
[11:08] <wgrant> cjwatson: Indeed, thanks
[11:08] <wgrant> cjwatson: I'm not quite seeing how queue admins manage to bypass it
[11:09] <cjwatson> *blink* That's a good question, so how come that test passes ...
[11:09] <wgrant> It looks like it'll just reject, which must mean the last test is wrong
[11:09] <wgrant> Exactly
[11:10] <cjwatson> Oh, blast, silly CannotCopy handling
[11:11] <cjwatson> Yeah, right, fixed the test
[11:12] <cjwatson> (locally - working on the model)
[11:20] <wgrant> 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] <StevenK> 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] <dpm> heyt StevenK, thanks, looking...
[11:36] <StevenK> 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] <StevenK> dpm: Drop me a note here, and I'll see it when I wake.
[11:38] <dpm> 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] <cjwatson> wgrant: OK, should be fixed
[11:39] <StevenK> 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] <dpm> 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] <dpm> 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] <StevenK> dpm: Ah, those are run by cron, which we don't run on staging
[11:40] <StevenK> s/run/updated/
[11:41] <wgrant> It would be worth running that manually.
[11:42] <dpm> 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] <wgrant> dpm: Templates should load after a refresh or two
[11:43] <dpm> thanks wgrant, that did it.
[11:44] <StevenK> wgrant: What does the stats? cronscripts/rosetta-pofile-stats.py ?
[11:44] <wgrant> StevenK: Heh heh heh
[11:44] <wgrant> You may recognise that script
[11:44] <StevenK> Quite
[11:45] <dpm> 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] <StevenK> Ah ha, cronscripts/update-stats.pu
[11:46] <StevenK> *py
[11:47] <wgrant> No
[11:47] <wgrant> That's the global stats
[11:50] <StevenK> wgrant: Then it is the great evilness that is rosetta-pofile-stats ?
[11:50] <wgrant> StevenK: I suspect so
[11:50] <wgrant> I doubt the copier creates jobs
[11:51] <StevenK> IDistroSeries.updateStatistics() did look relevant, though
[11:52] <wgrant> That mostly just creates DistroSeriesLanguages
[11:52] <wgrant> We care about POFile stats
[11:53] <StevenK> wgrant: What about the last bit, which is updating the message counts for the series itself?
[11:53] <wgrant> Not very interesting for this
[11:53] <wgrant> Well, slightly
[11:53] <wgrant> But it's not the main thing that matters
[11:54] <StevenK> dpm: So with the stats updated it should be identical to precise?
[11:55] <StevenK> Er, quantal, even
[11:55] <dpm> 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] <StevenK> dpm: Right, I'll sort that out -- I'll prod you tomorrow to have another look
[11:57] <wgrant> 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] <dpm> ok cool, thanks StevenK :)
[11:57] <StevenK> Ew, 4 days
[11:57] <wgrant> It's probably faster to create jobs
[11:57] <StevenK> wgrant: Let's talk about it on the call tomorrow
[11:57] <wgrant> Indeedily
[12:20] <rick_h_> gary_poster: ping, deryck wants to know where you are
[14:48] <sinzui> jcsackett, r=me
[14:49] <jcsackett> sinzui: awesome. off it goes.
[16:06] <cjwatson> 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 <email> <package-copies> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1070804 >
[16:06] <cjwatson> I'm using http://paste.ubuntu.com/1302902/, which indeed causes the test to fail
[16:06] <cjwatson> But CannotCopy is in PlainPackageCopyJob.user_error_types, which *should* suppress this
[16:08] <cjwatson> 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 (<class 'lp.soyuz.interfaces.archive.CannotCopy'>,) - it's not the case that user_error_types is being defined in the wrong place, as far as I can tell
[16:09] <cjwatson> But the except doesn't fire, and I get:
[16:09] <cjwatson> (Pdb) p isinstance(info[1], job.user_error_types)
[16:09] <cjwatson> *** TypeError: TypeError('isinstance() arg 2 must be a class, type, or tuple of classes and types',)
[16:10] <cjwatson> which has me totally baffled because as far as I can tell it *is* a tuple of types
[16:10] <cjwatson> ('isinstance(info[1], (CannotCopy,))' returns True)
[16:10] <cjwatson> Is this a Zope weirdness, or a Python weirdness, or what?
[16:50] <sinzui> 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] <cjwatson> (But then I would have to rebuild all the extensions needed, argh)
[17:17] <cjwatson> sinzui: Ah - job.user_error_types is security-proxied
[17:17] <sinzui> buggery
[17:17] <cjwatson> isinstance(info[1], removeSecurityProxy(job.user_error_types)) -> True
[17:17] <cjwatson> So is the right answer here to use 'except removeSecurityProxy(job.user_error_types) as e:' ?
[17:18] <cjwatson> Seems a little clunky ...
[17:18] <sinzui> that's yuck
[17:18] <sinzui> y
[17:18] <sinzui> I don't think any error should be wrapped in a proxy
[17:19] <cjwatson> Well, the error isn't, but the attribute retrieved from job is
[17:19] <sinzui> ah, be I see we got the job via a zope utility, so all attrs are wrapped
[17:20] <cjwatson> (rSP there does work)
[17:20] <cjwatson> Is there a way to declare some attributes as always being unproxied?
[17:20] <sinzui> doesn't this mean that lazr.jobrunner.jobrunner never gets the tuple it expects
[17:21] <sinzui> no, but there is a helper that will unwrap everything. we use in webapp.authenticate I think
[17:23] <sinzui> cjwatson, we can create a property on our job class that unwraps and returns the error classes...
[17:24] <sinzui> 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] <cjwatson> haha, there's already one of these for retry_error_types, called retryErrorTypes
[17:27] <cjwatson> 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] <cjwatson> Does that make sense?
[17:29] <cjwatson> Otherwise we have two very similar things using different patterns
[17:30] <sinzui> 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] <cjwatson> Sure, but then we'd have two things right next to each other that should really look the same but are different
[17:31] <cjwatson> Is that worth it to avoid changing lazr?
[17:31] <cjwatson> It sort of seems like a "future developers will curse thy name" to me
[17:32] <sinzui> 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] <cjwatson> By which I mean, user_error_types and retry_error_types are literally right next to each other in BaseRunnableJob
[17:32] <cjwatson> They should surely be handled similarly
[17:33] <sinzui> ah, yes, they must be treated the same
[17:33] <cjwatson> (BaseJob, I mean)
[17:35] <cjwatson> Actually, with the way the code is structured, it could work either way round; doing lazr.jobrunner first would make QA easier
[17:36] <sinzui> right, so we want the same solution, and lazr.job has chosen its method approach
[17:43] <cjwatson> Also, lazr.jobrunner is only at 0.9 on PyPI for some reason; what happened to 0.10?
[17:44] <cjwatson> adeuring: ^-
[20:40] <jcsackett> 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] <sinzui> 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] <sinzui> jcsackett, did I ever send you testemail.py
[20:47] <jcsackett> sinzui: you did not, but it sounds promising.
[20:48] <jcsackett> (or if you did, i have since forgotten).
[20:48] <sinzui> I will send it
[20:48] <jcsackett> awesome.
[21:00] <sinzui> jcsackett, you might want to just run all the tests in lp.services.mail and on success, lp-land the branch
[22:10] <sinzui> 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. <lp-translations> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/401633 >
[22:30] <sinzui> 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 <lp-translations> <message-sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/373269 >
[22:38] <sinzui> wgrant, https://wiki.canonical.com/Launchpad/Translations/UbuntuOpenings