[00:36] <StevenK> wgrant: Hm, I wonder if we should error if authorized_size is null for ArchivePurpose.PPA
[00:37] <wgrant> StevenK: Or just enforce the quota iff authorized_size is set
[00:37] <wgrant> Rather than iff it's a PPA
[00:37] <StevenK> wgrant: This isn'
[00:37] <StevenK> Bleh
[00:38] <StevenK> I'm not sure about that bug, I'm looking at bug 965317
[00:38] <_mup_> Bug #965317: TypeError: unsupported operand type(s) for *: 'NoneType' and 'int'  on +repository-size page <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/965317 >
[00:39] <wgrant> Ah, so separate but related
[00:39] <wgrant> If there's no quota then there's no quota, I guess
[00:40] <wgrant> http://irclogs.ubuntu.com/2012/02/18/%23launchpad-dev.txt
[00:40] <StevenK> Right
[00:45] <lifeless> can has review ? - https://code.launchpad.net/~lifeless/lp-dev-utils/ppr/+merge/124084
[00:45] <lifeless> small
[00:47] <lifeless> wgrant: ^
[01:08] <lifeless> StevenK: ^?
[01:11] <StevenK> lifeless: r=me
[01:11] <lifeless> thanks'
[01:26] <lifeless> wgrant: test failures ~ critical?
[01:26] <wgrant> lifeless: Running the test suite outside X or xvfb-run is unsupported
[01:26] <wgrant> So that one is not critical
[01:27] <lifeless> oh, I didn't notice that nuance.
[01:27] <lifeless> where was he running it ?
[01:27] <wgrant> Assuming you're talking about bug #1020146
[01:27] <_mup_> Bug #1020146: lp.testing.layers.YUITestLayer tests fail in various ways without X <test-system> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1020146 >
[01:27] <wgrant> canonistack, I assume
[01:31] <lifeless> I'd wontfix in fact, if its not a supported config
[01:31] <wgrant> Nah
[01:31] <wgrant> It should work
[01:32] <lifeless> how?
[01:32] <wgrant> There's no reason our test browser should need to use X
[01:33] <StevenK> But it's not critical
[01:33] <wgrant> That's why I made it not critical.
[01:33] <rick_h_> all of the webkit enabled browsers require x though I think phantomjs was working around it. Not sure if they got it done
[01:34] <rick_h_> it's how they're working, by using the webkit ui toolkits to load the pages
[01:34] <wgrant> Right
[01:34] <wgrant> But nothing about this fundamentally requires X
[01:34] <wgrant> It's just the library we happen to use atm
[01:34] <lifeless> alloftheones
[01:35] <rick_h_> so yea, phantomjs would be a good way to go: http://code.google.com/p/phantomjs/wiki/XvfbSetup
[01:35] <rick_h_> I've testsed trying to run with grover + phantomjs but it blows up horribly currently
[01:42] <lifeless> wgrant: so what was bug 739042 ?
[01:42] <_mup_> Bug #739042: DistroArchSeries:+index timeouts <timeout> <Launchpad itself:Fix Released by wgrant> < https://launchpad.net/bugs/739042 >
[01:46] <wgrant> lifeless: Terrible FTI that I fixed a few months back
[01:47] <lifeless> ah cool
[01:47] <wallyworld> wgrant: looking at another web service exported collection - IBug.bug_tasks. It also just gives a list of dict values ie lp.bugs[5].bug_tasks.entries gives [{...}, {...}] so i'm yet to find a collection where one can get at objects
[01:48] <wallyworld> so i still can't see what the bug is wanting different to what we currently do elsewhere
[01:48] <wallyworld> or if it's possible/feasible
[02:09] <wgrant> wallyworld: Oh, why are you calling .entries?
[02:09] <wallyworld> to get the values in the Collection
[02:09] <wgrant> Iterate :)
[02:09] <wgrant> Asking for the entries will get you the raw entries
[02:10] <wgrant> In [3]: list(lp.bugs[5].bug_tasks)
[02:10] <wgrant> Out[3]: [<bug_task at https://api.launchpad.net/devel/launchpad/+bug/5>]
[02:10] <_mup_> Bug #5: Plone Placeless Translation Service metadata missing from po files <feature> <lp-translations> <Launchpad itself:Fix Released by daf> < https://launchpad.net/bugs/5 >
[02:10] <wallyworld> oh, ok. i didn't realise entries did that
[02:10] <wallyworld> and that i needed to iterate
[02:10] <wallyworld> thanks
[02:11] <wgrant> The collection is an iterable of EntryResources
[02:11] <wgrant> It also has a .entries attribute which is an iterable of the raw JSON representation of the entries
[02:12] <wallyworld> ok. i didn't appreciate there was a difference, i thought .entries just have the values in the current batch
[02:13] <lifeless> heh, nice trap
[02:14] <wallyworld> yeah, i fell into it. i'm still no expert on our restful api
[02:14] <lifeless> is anyone/
[02:25] <wallyworld> StevenK: auditor client bb failure!
[02:28] <StevenK> Strange
[02:32] <wgrant> sinzui: Can we kill bug #450480?
[02:32] <_mup_> Bug #450480: Get PCI and USB vendor/product names from the "PCI ID Repository" project and from linux-usb.org respectively <hwdb> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/450480 >
[02:33] <sinzui> I have not decided...
[02:33] <sinzui> maybe you cane
[02:33] <sinzui> help
[02:33] <sinzui> Leann does is not affected by the bug. She will not no if we fix it
[02:34] <sinzui> It is tempting to say that the unused feature is not a regression
[02:35] <wgrant> lifeless: Your last act on #579602 confuses me
[02:35] <_mup_> Bug #579602: cannot call getBranches on a source package using the API <api> <lp-code> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/579602 >
[02:36] <sinzui> wgrant, I think can say wont fix, but what of the oopses...I don't think we can close them until the code is removed
[02:37] <wgrant> sinzui: Which OOPSes?
[02:39] <sinzui> wgrant, https://bugs.launchpad.net/launchpad/+bugs?field.importance%3Alist=CRITICAL&field.tag=hwdb
[02:40] <lifeless> wgrant: me too
[02:40] <wgrant> sinzui: The other three must remain by ZOP
[02:41] <wgrant> sinzui: But the 450480 is a regression, not an oops
[02:41] <sinzui> I agree
[02:42] <sinzui> wgrant, as I suggested in the meeting, we can ignore them until we get the word that HWC has their replacement operational. There are about 31 bugs that can be closed with we remove the hwdb
[02:43] <wgrant> sinzui: Right, but I'm going to demote the regression since nobody cares
[02:45] <sinzui> +1
[02:46] <StevenK> sinzui: I'm going to remove the Builder:+history timeout FF on prod with your blessing
[02:47] <sinzui> Sure. We can put it back if we are wrong
[02:57] <lifeless> wallyworld: are you still working on 681767 ?
[02:57] <lifeless> bug 681767 that is
[02:57] <_mup_> Bug #681767: Can't use relative URLs with launchpadlib.Launchpad - generates URI object that breaks wadllib <lp-foundations> <lazr.restfulclient:In Progress by wallyworld> < https://launchpad.net/bugs/681767 >
[02:58] <wallyworld> lifeless: i think that one was put on hold
[02:58] <wallyworld> since my solution was rejected
[02:58] <lifeless> kk
[02:58] <lifeless> thanks
[03:12] <lifeless> sadface at the fix committed etc being images
[03:17] <wgrant> lifeless: Where?
[03:18] <lifeless> bug listings
[03:18] <wgrant> They're not images
[03:18] <lifeless> oh, wtf then
[03:18] <lifeless> ctrl-f won't find them
[03:18] <wgrant> Does so :)
[03:18] <lifeless> mmm, I must have had a typo.
[03:18] <lifeless> weird.
[03:18] <wgrant> Works for Triaged in Firefox at least
[03:19] <lifeless> ah
[03:19] <lifeless> the fix is funky
[03:19] <lifeless> try this
[03:19] <lifeless> https://bugs.launchpad.net/~lifeless/?field.status%3Alist=FIXCOMMITTED
[03:19] <lifeless> ctrl-F
[03:19] <lifeless> fix
[03:19] <lifeless> in firefox
[03:19] <wgrant> Works
[03:20] <lifeless> and nope, commit doesn't either.
[03:20] <lifeless> unless I click in one of them
[03:20] <lifeless> then it works
[03:20] <wgrant> Works either way for me
[03:21] <lifeless> so, doesn't for me :)
[03:21] <lifeless> until I click in the page
[03:21] <wgrant> Huh
[03:22] <lifeless> do you have match case enabled ?
[03:22] <lifeless> cause I did :(
[03:22] <lifeless> <- muppet
[03:22] <wgrant> haha
[03:23] <lifeless> UI could tell you
[03:23] <wgrant> Indeed
[03:23] <lifeless> '15 more hits if match case is turned off'
[03:27] <lifeless> wgrant: so - http://bugs.python.org/issue1638033 - what should the thing be set to to close in LP?
[03:27] <lifeless> its 'accepted closed' atm,
[03:27] <lifeless> surely closed should mean LP puts it in a terminal state ?
[03:28] <wgrant> Probably
[03:29] <wgrant> But I believe 'fixed closed' is what LP expects
[03:29] <wgrant> Perhaps they've changed
[03:29] <lifeless> what /is/ the python tracker ? RT ?
[03:30] <wgrant> Roundup
[03:30] <lifeless> ah
[03:30] <wgrant> We have a custom set of mapping tables for the Python Roundup in our codebase
[03:32] <lifeless> yay
[03:32] <lifeless> well if you care - https://bugs.launchpad.net/launchpad/+bug/1050173
[03:32] <_mup_> Bug #1050173: bugwatches set to accepted closed in roundup maps to 'fix committed' not 'fix released' <bugs> <bugtrackers> <bugwatch> <roundup> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1050173 >
[03:32] <wgrant> I'd say Python roundup
[03:32] <wgrant> I believe they're all different
[03:32] <wgrant> We certainly have a custom status map for python
[03:34] <lifeless> tweaked
[03:34] <wgrant> Thanks
[03:34] <wgrant> There's 3 or 4 checkwatches criticals, so someone's likely to get around to touching that area soon
[03:36] <lifeless> \o/
[03:36] <lifeless> on the make lifeless' bug list clean effort ;)
[03:36] <wgrant> Heh
[03:39] <wgrant> We should make more pages less terrible
[03:39] <wgrant> Particularly since that tends to involve making code shorter
[04:24] <StevenK> wallyworld, wgrant: https://code.launchpad.net/~stevenk/launchpad/deal-with-no-authorized_size/+merge/124097
[04:24] <wgrant> StevenK: Rejected due to invalid apostrophe use
[04:24] <wallyworld> +100
[04:24] <StevenK> What invalid apostrophe use ...
[04:24] <wallyworld> sigh
[04:25] <wallyworld> why don't people know grammar these days
[04:25] <StevenK> I just fixed it, so I'm playing innocent.
[04:25] <wallyworld> :-)
[04:25] <wallyworld> it's one of my pet peeves
[04:25] <wgrant> StevenK: Also, I'd prefer that you fixed policySpecificChecks  rather than checkArchiveSizeQuota, maybe
[04:25] <wgrant> StevenK: At least de-dupe the check
[04:26] <wgrant> It may be best to remove the PPA guard around the checkArchiveSizeQuota check, I guess.
[04:26] <StevenK> wgrant: Why? There are other checks in checkArchiveSizeQuota.
[04:26] <wgrant> After checking on production that it won't impact the primary archive
[04:26] <wgrant> We can apply the quota check to any archive with a quota set
[04:28] <StevenK> wgrant: Hmmmm
[04:33] <StevenK> wgrant: http://pastebin.ubuntu.com/1201917/ ?
[04:34] <wgrant> StevenK: You've changed the security rejection behaviour
[04:34] <wgrant> Also, you might want to explicitly check if it's not None
[04:34] <wgrant> Rather than if it's not 0
[04:35] <StevenK> wgrant: is None, even
[04:35] <wgrant> Well, yes.
[04:35] <wgrant> that
[04:38] <StevenK> wgrant: Changed? Sure, but I don't think it will impact anything.
[04:41] <StevenK> wgrant: And "SELECT id, name FROM archive WHERE authorized_size IS NOT NULL AND purpose <> 2;" == 46 on DF
[04:41] <wgrant> StevenK: It'll now reject security uploads to PPAs with a different message
[04:42] <StevenK> wgrant: PPAs do not have a security pocket?
[04:42] <wgrant> Right, they wouldn't have been accepted, but this might change the way they're rejected.
[04:43] <StevenK> So I don't think it's a concern. It is certainly something to keep in mind when it's QA'd.
[04:47] <StevenK> wgrant: ^ Agree or disagree?
[04:48] <wgrant> StevenK: Have you checked the history of that method, to see why the guard was added?
[04:49] <wgrant> It's possible it was incidental when the quota check was added
[04:49] <wgrant> But it would be nice to check before we remove it
[04:51] <StevenK> wgrant: For checkArchiveSizeQuota? Because it was written only for PPAs.
[04:51] <wgrant> StevenK: But there's the opposite guard for the security pocket check
[04:52] <StevenK> Because other archives have pockets, I guess
[04:52] <wgrant> Right
[04:52] <wgrant> It may have been there for a reason
[04:52] <wgrant> Or it may not
[04:52] <wgrant> But we should check before removing it
[04:55] <StevenK> The else was added in r15663
[04:55] <wgrant> Readded, perhaps
[04:55] <StevenK> [r=wgrant][rollback=15658] Revert r15658, as uploads to -security will have their builds automatically failed. Update associated comments.
[04:55] <wgrant> cjwatson removed it
[04:55] <wgrant> Ah yeah
[04:56] <wgrant> Then I readded it
[04:56] <wgrant> annotate before that
[04:56] <wgrant> Ah, no, cjwatson reverted it, but I reviewed it?
[04:56] <wgrant> Odd
[04:57] <wgrant> The else is a little over 5 years old
[04:57] <wgrant> I would remove it
[04:58] <wgrant> It was added with the ubuntero PPA check
[04:58] <StevenK> You mean, like I did? :-)
[04:58] <wgrant> Yes
[04:58] <wgrant> But with verification
[04:58] <StevenK> Which we just did
[04:59] <wgrant> Indeed
[04:59] <wgrant> Push and I can approve :)
[05:02] <StevenK> wgrant: Diff updating. I attempted to destroy archive-views.txt, but I'm sad to say it defeated me.
[05:04] <StevenK> wgrant: And diff updated
[05:08] <ajmitch> https://code.launchpad.net/~ajmitch/launchpad/prerelease-backports/+merge/124100 for minimal change, if you want to comment
[05:08] <StevenK> 8+ def test_insecure_does_not_approve_backports_before_release(self):
[05:08] <StevenK> 10+ self.setHoaryStatus(SeriesStatus.CURRENT)
[05:08] <StevenK> Uhhhh?
[05:09] <StevenK> :-)
[05:09] <ajmitch> lulwut
[05:09] <StevenK> Your two test cases are indentical
[05:09] <ajmitch> yeah, now I see that
[05:10] <ajmitch> I wasn't sure whether to even keep those since I'm not touching the uploadpolicy now
[05:10] <StevenK> Indeed
[05:10]  * ajmitch was copying from the earlier tests in there, fwiw 
[05:10] <ajmitch> just copied a bit too vigorously
[05:11] <StevenK> I was about to say something like that
[05:11] <StevenK> ajmitch: So, you don't touch the uploadpolicy at all, which means the comments for the two tests is technically correct, but only because the policy doesn't check
[05:12] <StevenK> ajmitch: bzr revert -r submit: lib/lp/archiveuploader/tests/test_uploadpolicy.py && bzr ci ?
[05:12] <wgrant> lifeless: Thoughts on my suggestion in bug #1050191?
[05:12] <_mup_> Bug #1050191: allocate-revision-karma.py is too slow to complete <branches> <karma> <lp-code> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1050191 >
[05:12] <ajmitch> right, I'd initially made the mistake of changing the approval policy & wrote the test
[05:12] <StevenK> RARGH
[05:12] <StevenK> Is the filename on neem pointless or something?
[05:14]  * ajmitch commits & pushes
[05:16] <StevenK> Bleh, I have a file with a current OOPS and the sha1 in the filename isn't the OOPS ID
[05:17] <ajmitch> StevenK: ok, less LOC added now :)
[05:17] <StevenK> ajmitch: test_checkUpload_backports_development could do with a comment
[05:18] <StevenK> wgrant: Thanks for the +1, tossing at ec2
[05:18] <ajmitch> ok to plagiarise from the test above, or do you like to have the bug # in there as well?
[05:19] <StevenK> ajmitch: Just plagiarise, no need for the bug number
[05:20] <StevenK> Right, so the oops id is 3607c5f44e382d14bd9ff678dbc51097, but the filename is OOPS-4f2364563d7a41ea4918845f2d86aec5.
[05:22]  * ajmitch waits for the diff to update
[05:22] <StevenK> Ah, so '?id%OOPS-' to search for. Sigh.
[05:23] <wgrant> ?
[05:23] <StevenK> Ah, so '?id%OOPS-' is the magic string to search for.
[05:24] <wgrant> Well
[05:24] <wgrant> I grep for the actual unique bit
[05:24] <wgrant> Oh, you mean finding the web-accessible OOPS ID in a known file?
[05:24] <StevenK> I had the filename, but not the ID
[05:25] <StevenK> wgrant: Yeah
[05:25] <wgrant> I just search for OOPS- :)
[05:26] <StevenK> wgrant: I'm happy to approve ajmitch's MP, do you see any issues with it?
[05:26] <wgrant> It's from New Zealand
[05:26]  * ajmitch was expecting a comment like that
[05:27] <StevenK> Oh, so, "This was written by a PHP developer." status => Rejected
[05:27] <wgrant> That too
[05:27] <ajmitch> the love I get in here
[05:28] <wgrant> ajmitch: Have you discussed this with cjwatson?
[05:28] <ajmitch> only in passing, not the submitted branch
[05:28] <wgrant> Ah, I see TB discussion
[05:28] <wgrant> Have you considered the issue of autoapproval?
[05:29] <ajmitch> they should land in unapproved
[05:29] <ajmitch> I'd considered it, made a change in uploadpolicy & then reverted once I clarified that they'll always be unapproved
[05:29] <wgrant> Right, only RELEASE and PROPOSED (and only in unstable series) get autoapproved
[05:30] <wgrant> I'd like to see an ack from Colin just in case, but otherwise that looks fine
[05:30] <ajmitch> ok
[05:30] <StevenK> Let me approve it, with that note
[05:30] <ajmitch> I'll ping him later when he's hopefully around
[05:30] <ajmitch> thanks for the review
[05:31] <ajmitch> not that the diff was overwhelming
[05:31] <wgrant> Heh
[05:56] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/double-archivesub/+merge/124102
[06:02] <wgrant> StevenK: It already deals with it
[06:02] <wgrant> By raising an exception
[06:03] <StevenK> wgrant: That isn't caught and ends up as an OOPS
[06:04] <wgrant> StevenK: Right, but you could catch it
[06:05] <wgrant> Or make it a 400 if it's an issue with the API
[06:06] <StevenK> wgrant: I could, I decided to follow the pattern that we have for bug/branch subscriptions
[06:07] <wgrant> It looks like that can only happen over the API
[06:07] <wgrant> So I would just annotate it with BAD_REQUEST
[06:08] <StevenK> https://oops.canonical.com/?oopsid=3607c5f44e382d14bd9ff678dbc51097 disagrees
[06:09] <wgrant> Ah, indeed, missed the two browser callsites
[06:10] <wgrant> In one case you want to crash
[06:10] <wgrant> In the other you probably want to inform the user that they're insane
[06:10] <wgrant> Alternatively, in the latter ('activate') case you could call getAuthToken first
[06:10] <wgrant> Or catch the exception and call getAuthToken
[06:11] <StevenK> We sort of
[06:11] <StevenK>         if self.request.form.get('activate') and not self.active_token:
[06:13] <wgrant> Hm, then do you know how the exception happened?
[06:13] <wgrant> Perhaps the token was deactivated
[06:13] <StevenK> Hm, perhaps
[06:19]  * StevenK tries to remember where PersonArchiveSubscriptionView is hit from
[06:19] <wgrant> You mean Person:+archivesubscriptions?
[06:19] <wgrant> Or one of the archive-specific views?
[06:20] <StevenK> I created an authtoken and then called deactivate on it and the UI says I have no tokens
[06:21] <wgrant> You need a subscription
[06:21] <wgrant> The UI shows subscriptions
[06:23] <StevenK> Hm, Archive:+subscriptions is forbidden as an admin?
[06:23] <wgrant> Yes
[06:23] <wgrant> Admins don't hold launchpad.Append on IArchive
[06:23] <wgrant> It's like launchpad.Special in that regard
[06:25] <StevenK> Right, now I have a subscription
[06:30] <StevenK> Then I set it to expired and it disappears from the UI again
[06:31] <wgrant> Sure
[06:31] <wgrant> Doesn't necessarily mean it's not accessible
[06:31] <wgrant> It's also possible that the token is somehow deactivated, but the sub is not
[06:31] <StevenK> Oh, there's a seperate table for the token?
[06:31] <wgrant> (eg. a team sub was created, a token was issued, then the team sub was revoked, then a person sub was created, maybe?)
[06:31] <wgrant> yes
[06:32] <wgrant> Subscriptions can be for teams
[06:32] <wgrant> Tokens can't be
[06:32] <stub> wgrant: is this index I see before me to replace an existing index, or in addition?
[06:32] <wgrant> stub: In addition
[06:33] <stub> wgrant: Why have status included then, as the preamble states it is indended for use when not filtering by status?
[06:34] <wgrant> stub: It's not necessary, but due to that order it also doesn't affect size/performance significantly.
[06:34] <wgrant> I can remove it if you want
[06:34] <wgrant> It's not really useful until we have index-only scans, I guess
[06:49] <wgrant> cjwatson: What blockers remain to prevent the removal of delayed copies?
[07:38] <adeuring> good morning
[07:38] <stub> wgrant: So that new index, is that status ever going to be used? We already have an alternative index on (archive, das, status, bpn)
[07:39] <stub> wgrant: Unless we need to use the four fields for ordering, but I don't think we ever want to do that.
[07:41] <wgrant> Indeed
[07:41] <wgrant> I might drop status
[07:46] <wgrant> stub: That's done
[07:46] <stub> ok
[08:47] <stub> Is this the correct way for force the use of our patched pgbouncer in Depends: ? pgbouncer (>= 1.5.2-2+lp2, < 1.5.2-3)
[08:47] <wgrant> stub: You need two separate dependencies
[08:48] <stub> ok, so don't just believe that builddeb worked :)
[08:48] <stub> 1.5.2-2+lp2~23~lucid1 and 1.5.2-2+lp2~23~precise1 are the two interesting versions it needs to work with
[08:48] <wgrant> Also, << rather than <
[08:51] <stub>   pgbouncer (>= 1.5.2-2+lp2), pgbouncer (<< 1.5.2-3),
[08:51] <maxb> It might be more practical to make the patched pgbouncer "Provides: pgbouncer-lp" and depend on that, unless the patch is going to get upstreamed shortly
[08:51] <wgrant> That won't work.
[08:51] <wgrant> Due to ~
[08:51] <wgrant> Yeah
[08:51] <wgrant> I was about to suggest the Provides
[08:52] <wgrant> But it will hopefully be upstream soonish
[08:52] <wgrant> For the versioned Depends to work, you'd want pgbouncer (>= 1.5.2-2+lp2~), pgbouncer (<< 1.5.2-3~)
[08:52] <wgrant> But the Provides is probably a better solution for now.
[08:52] <stub> Sure about that twiddly after the 3?
[08:53] <wgrant> Yes, otherwise eg. 1.5.2-3~lucid1 will satisfy your dep
[08:53] <stub> oh, guess so
[08:53] <wgrant> Which you probably don't want
[09:43]  * cjwatson adds a kanban card to have a look at ajmitch's MP a bit later
[09:44] <cjwatson> wgrant: I have branches leading up to it all locally.  The main blocker is that bigjools raised a concern about the PCJ queue for PPAs being starved if e.g. we'd just run an auto-sync.
[09:45] <cjwatson> wgrant: Which is arguably a blocker for removing the feature flag guarding the fix for bug 575450 (releasing that from beta), which will allow us to remove the synchronous +copy-packages mode and thereafter remove delayed copies.
[09:45] <_mup_> Bug #575450: Archive:+copy-packages nearly unusable due to timeouts <lp-soyuz> <ppa> <qa-ok> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/575450 >
[09:46] <wgrant> cjwatson: Ah, right.
[09:46] <wgrant> I'd forgotten about the starvation issue
[09:46] <cjwatson> wgrant: I'm not sure whether the proper fix is to bring up multiple cron jobs for PCJ processing, or to convert it all to celery.
[09:46] <cjwatson> The vague consensus seemed to be the latter, but also that celery was a bit untried.
[09:47] <wgrant> That's one way of putting it
[09:47] <cjwatson> I was due to try out celery for ProcessAcceptedBugsJob, when I get back to that ...
[09:47] <wgrant> Indeed
[09:50] <wgrant> adeuring: It looks like a recent private projects landing has broken buildbot. Can you investigate?
[11:13] <rick_h_> adeuring: ping
[11:13] <rick_h_> nvm, looks like wgrant already ping'd you on it
[11:13] <adeuring> morning rick_h_
[11:14] <rick_h_> adeuring: sorry, was just going to see if you'd peeked at the buidbot breakage. Looks like it's breaking on a query around specification stuff that landed
[11:14] <adeuring> rick_h, wgrant: acutally, I did not notice...
[11:14] <adeuring> looking now
[11:14] <rick_h_> adeuring: cool, thanks. Sorry for the dupe :)
[11:20] <dpm> hi launchpadders, could someone help me with a generic question on LP cronscripts? I'm trying to find out what it would take to move a script that currently talks to the DB to export translation data into the LP source tree. I'm told by jtv that the best way would be to turn the script's main code into a class derived from LaunchpadCronScript, but that I should double-check with other LP developers.
[11:21] <dpm> For reference, the script is here: https://launchpad.net/lp-get-ul10nstats/trunk
[13:52] <mpt> Are there any prizes given for marking really old bugs as duplicates?
[13:54] <czajkowski> mpt: I'll give you cake
[13:54] <czajkowski> how's that
[13:54] <mpt> deal :-)
[13:54] <czajkowski> win win :)
[13:54] <czajkowski> mpt: but you're not allowed to create new ones :)
[13:55] <mpt> What would be the point of that? If they're new ones they're not really old ones
[13:55] <mpt> oh, you mean you're limiting me to marking duplicates, not reporting bugs at all
[14:04] <dpm> > hi launchpadders, could someone help me with a generic question on LP cronscripts? I'm trying to find out what it would take to move a script that currently talks to the DB to export translation data into the LP source tree. I'm told by jtv that the best way would be to turn the script's main code into a class derived from LaunchpadCronScript, but that I should double-check with other LP developers.
[14:04] <dpm>  For reference, the script is here: https://launchpad.net/lp-get-ul10nstats/trunk
[15:14] <cjohnston> When trying to use lp-setup, I've tried many times now to run install-lxc.. I continue to get a Permission denied (publickey) error (http://paste.ubuntu.com/1202807/) each time I try.. any idea what is causing this?
[15:21] <cjohnston> I've double checked my key and its correct
[15:32] <cjohnston> hmm.. hmm.. appears as tho as somepoint I was logged out from bzr launchpad-login.. stand down all :-)
[16:05] <cjohnston> ok.. more hmm.. any chance that lpsetup changes my launchpad-login?
[16:06] <czajkowski> cjohnston: breaking things :)
[16:06] <cjohnston> probably
[16:06] <cjohnston> just not sure how :-(
[16:07] <czajkowski> sinzui: might you give cjohnston some pointers please
[16:07] <sinzui> I have't use it
[16:08] <cjohnston> Not quite sure why I'm importing the Yellow Squad key: http://paste.ubuntu.com/1202922/
[16:09] <deryck> jcsackett, hi.  I have a branch for review, but....
[16:10] <deryck> jcsackett, I'm about to lunch.  So don't mind waiting until I'm back if you need to chat interactively.
[16:10] <jcsackett> deryck: i don't mind looking now, i can put any questions in a comment.
[16:11] <deryck> jcsackett, awesome, thanks!  https://code.launchpad.net/~deryck/launchpad/use-specification-sharing-policy/+merge/124240
[16:11] <deryck> catch you after lunch then.
[16:18] <cjohnston> sinzui: I found the issue through the code.. you can pass --lpuser, but if you don't it defaults to your system user name.. :-/  /me wonders how many people have their system user name and lp name the same and if that should be the default or a required flag
[16:20] <sinzui> cjohnston, I agree. Lp chooses the user name from the first email address imported or sent from ubuntu SSO. There is little chance the system user will match the lp identity
[16:22] <sinzui> cjohnston, this may relate to benji's bug Bug #1034605
[16:22] <_mup_> Bug #1034605: handle_lpuser_as_username does validate the given LP username <lpsetup:Triaged> < https://launchpad.net/bugs/1034605 >
[16:24] <cjohnston> I don't think so.. from what I can tell, you can provide whatever username you want, and that bug is referencing checking to see if you mistyped your username.. whereas the issue I'm having that because I didn't know that I needed to provide a username, its picking what is a valid lp username, so his test would pass.. it just wouldn't be me
[16:24] <cjohnston> I guess related, possibly, the same, I don't think so
[16:26] <cjohnston> sinzui: should I talk to frankban_ about it, or someone else?
[16:32] <dpm> trying again...
[16:32] <dpm> hi launchpadders, could someone help me with a generic question on LP cronscripts? I'm trying to find out what it would take to move a script that currently talks to the DB to export translation data into the LP source tree. I'm told by jtv that the best way would be to turn the script's main code into a class derived from LaunchpadCronScript, but that I should double-check with other LP developers.
[16:32] <dpm>   For reference, the script is here: https://launchpad.net/lp-get-ul10nstats/trunk
[16:37] <czajkowski> dpm: poked elsewhere as well
[16:37] <dpm> thanks czajkowski
[16:38] <mgz> fallback would be an email to list, which would add the australians as an audience
[16:39] <jcsackett> dpm: assuming mgz's comment was at you, i agree with him. hit the launchpad-dev mailing list, and you'll get more attention.
[16:39] <jcsackett> dpm: or rather, you'll get attention with more direct knowledge on what you're doing. :-P
[16:40] <jcsackett> i would say though that we've done a lot of moving things *out* of the LP tree--what's the motivation to move this in?
[16:40] <dpm> jcsackett, I've been told that such scripts cannot live outside the LP tree, so it was disabled
[16:41] <jcsackett> dpm: that would be a good reason. :-P
[16:41] <cjwatson> jcsackett: direct db access
[16:43] <abentley> deryck[lunch]: Good morning.
[16:43] <jcsackett> so, dpm, i think step one is def to derive from LaunchpadCronScript.
[16:44] <jcsackett> i would still email the list though, so people who have done similar work can inform you of any potential gotchas.
[16:46] <dpm> jcsackett, yeah, that was what jtv recommended (LaunchpadCronScript), but he suggested to check with other devs whether that was still the recommended way to run such jobs (or if using celery tasks or any other technology is the preferred way in LP nowadays)
[16:46] <jcsackett> dpm: well, celery jobs and other job stuff is in my experience best meant for things that need to be jobs, but respond to real time events in the app.
[16:46] <jcsackett> like merging accounts, for example.
[16:47] <jcsackett> if this is just a nightly script or similar, i think cron is still the place for it.
[16:47] <jcsackett> others may of course have different opinions.
[16:47] <jcsackett> but i don't think we've abandoned cron as a way of doing things.
[16:48] <abentley> jcsackett: We do have Celery running one periodic task, but we haven't really migrated to Celery for everything yet.
[16:48] <abentley> jcsackett: So I don't know whether we'll prefer to use Celery for that in the future.
[16:50] <dpm> jcsackett, it's currently a daily job, and it simply exports data automatically (i.e. it does not need to respond to anything), so I guess cron should be fine
[16:52] <jcsackett> dpm: i would think so.
[17:21] <rick_h__> jcsackett: ping
[17:22] <jcsackett> pong.
[17:22] <rick_h__> jcsackett: hey, do you know the details of the bug/stuff going aroud on the linking of the nav stuff in the table listing?
[17:23] <rick_h__> I'm hitting a failing test out of no where with an error that linkify_navigation isn't defined and it's kind of confusing. I thought I saw some of your squad doing something with that in MP that flew by
[17:23] <jcsackett> rick_h__: wallyworld__ addressed a broken link error i think, but i don't recall the details.
[17:24] <jcsackett> i assume you're rebuilt js?
[17:25] <rick_h__> jcsackett: yea, ah there's the branch.
[17:25] <rick_h__> jcsackett: ok thanks
[17:25] <jcsackett> rick_h__: yw.
[17:29] <czajkowski> mpt: with those duplicates you get a cookie not a cake
[17:38] <deryck> abentley, hi there.
[17:39] <abentley> deryck: I see that abel was working on fixing my test failure.  I don't see it in devel, but I'm assuming it's in ec2.
[17:40] <deryck> abentley, yeah, it's in ec2.  Should be in shortly, assuming it passes.
[17:40] <abentley> deryck: I'm just digging into the privacy banner test failure, which appears to be from the same root cause.
[18:17] <sinzui> jcsackett, do you have time to review https://code.launchpad.net/~sinzui/launchpad/mailman-email-addresses/+merge/124273
[18:17] <jcsackett> sinzui: sure. :-)
[18:20] <jcsackett> sinzui: r=me. i love branches that delete doctests. :-)
[18:21] <sinzui> thank you jcsackett
[18:28] <rick_h__> jcsackett: branch your way if you have time: https://code.launchpad.net/~rharding/launchpad/lp_cache_update/+merge/124217
[18:29] <rick_h__> diff still updating though
[19:01] <jcsackett> rick_h__: one question: this dump to json utility only works for information types, and all the other info_type related stuff that's not tied to an artifact lives in registry. shouldn't it be there instead of app?
[19:03] <rick_h__> jcsackett: so if you know of a place in there to put it I'm happy to move it.
[19:03] <rick_h__> this is replacing the manual JSON stuff that was in each browser/xxxx.py
[19:03] <rick_h__> so it was in browser/product browser/bugtarget and going into browser/specification
[19:04] <rick_h__> since it was used in those places I defaulted to app/utilities
[19:04] <jcsackett> rick_h__: hm.
[19:04] <rick_h__> if no one minds it sitting in registry/enums I'm ok with it, or prefer a registry/utilities
[19:04] <rick_h__> it kind of didn't seem to fit so open to anything
[19:04] <jcsackett> i have no problem with enums, as its just a function to work with one of said enums.
[19:04] <jcsackett> but registry utilities would be fine as well.
[19:05] <jcsackett> i just don't want a developer months from now to waste time figuring out if information type lives in app or registry.
[19:05] <rick_h__> jcsackett: right, understand. I've got no dog in the fight at all.
[19:05] <jcsackett> so, i'll mark this approved with the understanding you'll move that to either reg/enum or reg/util?
[19:05] <rick_h__> sounds like a plan to me, thanks
[19:06] <jcsackett> r=me then. :-)
[19:06] <jcsackett> other than that, nice cleanup. :-)
[20:50] <sinzui> lifeless, do you have time to talk about escalated bugs
[20:50] <czajkowski> sinzui: you playing whack a bug today on bugs, you're so making progress on them :D
[20:51] <sinzui> czajkowski, yes, but it wont last. A lot are trivial or dupes. I expect the pace to slow in about 4 weeks
[20:52] <czajkowski> that's still a lot of weeks and a lot of bugs sinzui
[20:52] <lifeless> sinzui: I do. G+? Skype? IRC?
[20:53] <sinzui> czajkowski, I will cheer when the bug critical bug count  drops to 254, 1 less than Purple left it in July 2011
[20:53] <sinzui> lifeless, I want to try g+
[20:54] <czajkowski> :/
[20:54] <lifeless> sinzui: you or your canonical version should have an invite now
[21:51] <wallyworld__> sinzui: do you have time for a quick pre-impl before the standup?
[22:14] <sinzui> jcsackett, https://bugs.launchpad.net/bugs/bugtrackers/alsa-mantis lists fadly and it is only visible to ~registry
[22:14] <sinzui> bug 210821 is still not fixes
[22:14] <_mup_> Bug #210821: bug tracker list shows inactive projects <404> <bugwatch> <lp-bugs> <qa-ok> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/210821 >
[22:14] <sinzui> fixed
[22:29] <lifeless> czajkowski: why the sadface?
[22:31] <czajkowski> lifeless: the number in stats
[22:31] <czajkowski> lifeless: a year later and the number is down by 1
[22:32] <lifeless> not yet
[22:32] <lifeless> sinzui is looking forward to that point
[22:33] <lifeless> czajkowski: http://webnumbr.com/launchpad-critical-bugs
[22:34] <czajkowski> lifeless: aye he;s playing whack a mole on the bugs this week, it's interesting to follow.
[22:37] <StevenK> czajkowski: Not just sinzui.
[22:37] <StevenK> All five of us have been pouring over the critical bug list this week.
[22:38] <lifeless> jam: around ?
[22:38]  * lifeless doubts it
[22:38] <czajkowski> StevenK: yes you have I just picked one and refere to the whole team, but yes it's a group thing
[22:39] <czajkowski> lifeless: I think he's utc +5 no?
[22:39] <jelmer> yeah, he should be asleep
[22:39] <lifeless> should be :)
[22:40] <StevenK> +4, I think
[22:40] <lifeless> jelmer: have we published any bzr plugins to pypi ...
[22:40] <jelmer> lifeless: I think so. I know I have.
[22:40] <lifeless> I want to nuke sourcecode
[22:40] <lifeless> means letting bzr import plugins from eggs
[22:40] <lifeless> ahha
[22:41] <lifeless> http://pypi.python.org/pypi?%3Aaction=search&term=bzr&submit=search
[22:41] <StevenK> And mailman
[22:41] <lifeless> jelmer: ^
[22:41] <lifeless> StevenK: one crime against nature at a time
[22:42] <jelmer> lifeless: I like the idea.
[22:43] <jelmer> lifeless: so, bzr-git and bzr-svn are on pypi. we were going to get rid of bzr-hg. bzr-loom is missing, as is loggerhead.
[22:43] <lifeless> and bzr-pqm and others
[22:43] <jelmer> bzr-pqm is in sourcecode?
[22:43] <lifeless> I was pinging jam to ask his view on pushing them up, and to get acls as we'll need to fix the dependencies, switch them to use distribute ('setuptools')
[22:43] <lifeless> jelmer: its used for ec2test, so we need it somewhereish
[22:44] <jelmer> lifeless: don't we have it in the Launchpad PPA? Or do you really want it as egg?
[22:44]  * lifeless shrugs
[22:44] <lifeless> jelmer: http://rbtcollins.wordpress.com/2012/08/27/why-platform-specific-package-systems-exist-and-wont-go-away/
[22:45] <lifeless> jelmer: kindof like to setup lowest cost maintenance for the things we're maintaining
[22:45] <jelmer> lifeless: I've read it earlier :-)
[22:46] <jelmer> lifeless: I think that's the right approach, but bzr-pqm is also immutable enough that I wonder if it's worth worrying about at this point.
[22:46] <lifeless> sure, I'm not pushing hard for it, but it was in the working set that popped into mind
[22:47] <jelmer> Fair enough.
[22:50] <lifeless> huh
[22:50] <lifeless> looks like 2.6 does it already
[22:50] <lifeless> at least under pip
[22:51] <lifeless> ah, right, the virtualenv shoves it in the default search path
[22:51] <lifeless> so that provides an alternative
[22:51] <lifeless> gary_poster|away: if you come back, what would you say to a move to virtualenv+pip ?
[22:52] <mwhudson> please no
[22:53] <lifeless> mwhudson: details
[22:53] <mwhudson> lifeless: well, one thing is "move to pip" from what?  buildout?
[22:54] <lifeless> yes
[22:54] <mwhudson> i talked about this a little in my canonical-tech thread a bit
[22:54] <mwhudson> pip is not very good software
[22:55] <lifeless> imagine I have no idea what you're talking about
[22:55] <lifeless> desperately want to use pip
[22:55] <mwhudson> sorry
[22:55] <lifeless> and you have to dissuade me
[22:55] <lifeless> This is a lie, but will get you to tell me what you need to :)
[22:56] <mwhudson> lifeless: was trying to find a citation
[22:56] <mwhudson> lifeless: basically if you depend on packages a and b and a and b depend on _different_ versions of package c
[22:56] <mwhudson> lifeless: pip's response is "pick one"
[22:57] <mwhudson> lifeless: pip has no equivalent of buildout's allow-picked-versions = false
[22:57] <sinzui> wallyworld__, is this the bug?
[22:57] <sinzui> Bug #867529
[22:57] <_mup_> Bug #867529: Dynamic loading comments load on top of page content <firefox> <javascript> <qa-untestable> <regression> <story-batched-comment-loading> <Launchpad itself:Triaged> < https://launchpad.net/bugs/867529 >
[22:57] <lifeless> ok, assuming you're using the implicit dependency graph vs flatten and resolving to a single requirements doc like LP does with buildout (and can be done with pip too)
[22:58] <wallyworld__> sinzui: yes
[22:58] <mwhudson> lifeless: and this is more anecdata than something i can be specific about is that upgrades are very difficult
[22:58] <mwhudson> lifeless: so you want to make a new venv for each revno you deploy
[22:59] <lifeless> mwhudson: isn't that what -I -r versions.txt is for ?
[22:59] <mwhudson> lifeless: but there is no equivalent of the egg cache in the pip world, so making a new venv will take as long as a "make build" in a completely new launchad tree
[23:00] <lifeless> right, because it doesn't use eggs. Some folk would call that an advantage ;)
[23:00] <mwhudson> lifeless: i don't think there is any way to make pip check that versions.txt is complete
[23:01] <lifeless> mwhudson: how would you solve this for pip ?
[23:01] <mwhudson> lifeless: i wouldn't use it
[23:01] <lifeless> Ok.
[23:01] <mwhudson> oh you mean, if i was to try to fix pip?
[23:01] <mwhudson> i don't know
[23:01] <lifeless> How would you solve this in a world where buildout is going away, upstream are still discussing the colour of the bikeshed, and you are relentlessly pragmatic :)
[23:03] <mwhudson> lifeless: is buildout going away?
[23:03] <mwhudson> i don't know
[23:03] <mwhudson> embrace juju aggressively and move to debs (maybe using pypi-install liberally)?
[23:05] <lifeless> mwhudson: buildout: kindof, upstream have indicated that our LP specific tweaks are being removed in the next release.
[23:06] <lifeless> unless we port them, gary_poster|away has the details.
[23:07] <mwhudson> ah
[23:07] <mwhudson> mmf
[23:08] <mwhudson> this is the relative-path stuff i guess
[23:08] <lifeless> So we have a choice of investing in buildout, investing in pip, or investing in the heat death of the universe.
[23:08] <mwhudson> i guess we don't actually get a choice about the latter
[23:09] <mwhudson> lifeless: well, i don't want to impose my views on you over strongly
[23:09] <mwhudson> but we had a pip based deployment approached and it sucked
[23:09] <mwhudson> and we now have a buildout one and it works well
[23:09] <mwhudson> the underlying tech is surely not all of that
[23:09] <mwhudson> but it is probably part of it
[23:10] <lifeless> mwhudson: totally unscientific: http://www.googlefight.com/index.php?lang=en_GB&word1=pip&word2=buildout
[23:10] <lifeless> It may mean, for instance, that pip is hard to use so folk write about it more.
[23:10] <sinzui> wallyworld__, bug 402915 is what you may have a fix for
[23:10] <_mup_> Bug #402915: Can no longer move a branch to another project using the UI <lp-code> <package-branches> <regression> <target-picker> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/402915 >
[23:10] <mwhudson> lifeless: oh, pip is very popular no doubt
[23:10] <mwhudson> lifeless: you can also play the game with python/php or jquery/yui
[23:11] <lifeless> indeed.
[23:18] <StevenK> wgrant: ComponentLookupError: ((<Person at 0xfda1810 person-name-100003 (Person-name-100003)>, <lp.services.webapp.servers.LaunchpadTestRequest instance URL=http://127.0.0.1>), <InterfaceClass zope.interface.Interface>, '+archivesubscriptions/16')
[23:18] <StevenK> wgrant: I thought I'd constructed it to what the ZCML said, but obviously not.
[23:18] <wgrant> That's no view name
[23:18] <wgrant> That's a path
[23:19] <wgrant> You'll need to create a request with ['16'] as stepstogo
[23:19] <elmo> That's no moon!
[23:28] <StevenK> Hmm, still no failure
[23:35] <StevenK> wgrant: I need to grep through appserver logs?
[23:36] <wgrant> StevenK: No, you can see the request URL in the OOPS
[23:36] <bigjools> guten tag
[23:39] <StevenK> wgrant: Right, and that gives me the archive id and the user.
[23:42] <wgrant> StevenK: Right
[23:42] <wgrant> StevenK: So what would appserver logs give you?
[23:46] <wallyworld__> bigjools: your shift key broken?
[23:47] <bigjools> wallyworld__: I don't believe in german capitalisation
[23:47] <StevenK> wgrant: Handily, neither the archive or person exist on DF
[23:48] <wallyworld__> bigjools: you don't have a choice if you want to write properly :-P
[23:49] <bigjools> wallyworld__: I always have a choice
[23:50] <wallyworld__> same goes for writing English with poor grammar/spelling I guess
[23:53] <bigjools> wallyworld__: there's choice vs ignorance
[23:53] <bigjools> I am mainly ignorant when it comes to German :)
[23:53] <wgrant> StevenK: That's why we have ops :)
[23:54] <wallyworld__> bigjools: i was just trolling
[23:54] <bigjools> wallyworld__: I know, but I was chomping on the bait like a hooked fish
[23:54] <wallyworld__> yep, i reeled in a big one alright
[23:55] <bigjools> that begs an obvious response
[23:55] <wallyworld__> i throw out the bait....