[00:36] wgrant: Hm, I wonder if we should error if authorized_size is null for ArchivePurpose.PPA [00:37] StevenK: Or just enforce the quota iff authorized_size is set [00:37] Rather than iff it's a PPA [00:37] wgrant: This isn' [00:37] Bleh === matsubara-afk is now known as matsubara [00:38] 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 < https://launchpad.net/bugs/965317 > [00:39] Ah, so separate but related [00:39] If there's no quota then there's no quota, I guess [00:40] http://irclogs.ubuntu.com/2012/02/18/%23launchpad-dev.txt [00:40] Right === spm is now known as stevemci === stevemci is now known as spm [00:45] can has review ? - https://code.launchpad.net/~lifeless/lp-dev-utils/ppr/+merge/124084 [00:45] small [00:47] wgrant: ^ [01:08] StevenK: ^? [01:11] lifeless: r=me [01:11] thanks' === StevenK changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: ∞ [01:26] wgrant: test failures ~ critical? [01:26] lifeless: Running the test suite outside X or xvfb-run is unsupported === spm is now known as stevemci [01:26] So that one is not critical === stevemci is now known as spm [01:27] oh, I didn't notice that nuance. [01:27] where was he running it ? [01:27] Assuming you're talking about bug #1020146 [01:27] <_mup_> Bug #1020146: lp.testing.layers.YUITestLayer tests fail in various ways without X < https://launchpad.net/bugs/1020146 > [01:27] canonistack, I assume [01:31] I'd wontfix in fact, if its not a supported config [01:31] Nah [01:31] It should work [01:32] how? [01:32] There's no reason our test browser should need to use X [01:33] But it's not critical [01:33] That's why I made it not critical. [01:33] 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] it's how they're working, by using the webkit ui toolkits to load the pages [01:34] Right [01:34] But nothing about this fundamentally requires X [01:34] It's just the library we happen to use atm [01:34] alloftheones [01:35] so yea, phantomjs would be a good way to go: http://code.google.com/p/phantomjs/wiki/XvfbSetup [01:35] I've testsed trying to run with grover + phantomjs but it blows up horribly currently [01:42] wgrant: so what was bug 739042 ? [01:42] <_mup_> Bug #739042: DistroArchSeries:+index timeouts < https://launchpad.net/bugs/739042 > [01:46] lifeless: Terrible FTI that I fixed a few months back [01:47] ah cool [01:47] 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] so i still can't see what the bug is wanting different to what we currently do elsewhere [01:48] or if it's possible/feasible [02:09] wallyworld: Oh, why are you calling .entries? [02:09] to get the values in the Collection [02:09] Iterate :) [02:09] Asking for the entries will get you the raw entries [02:10] In [3]: list(lp.bugs[5].bug_tasks) [02:10] Out[3]: [] [02:10] <_mup_> Bug #5: Plone Placeless Translation Service metadata missing from po files

< https://launchpad.net/bugs/5 > [02:10] oh, ok. i didn't realise entries did that [02:10] and that i needed to iterate [02:10] thanks [02:11] The collection is an iterable of EntryResources [02:11] It also has a .entries attribute which is an iterable of the raw JSON representation of the entries [02:12] ok. i didn't appreciate there was a difference, i thought .entries just have the values in the current batch [02:13] heh, nice trap [02:14] yeah, i fell into it. i'm still no expert on our restful api [02:14] is anyone/ [02:25] StevenK: auditor client bb failure! [02:28] Strange [02:32] 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 < https://launchpad.net/bugs/450480 > [02:33] I have not decided... [02:33] maybe you cane [02:33] help [02:33] Leann does is not affected by the bug. She will not no if we fix it [02:34] It is tempting to say that the unused feature is not a regression [02:35] lifeless: Your last act on #579602 confuses me [02:35] <_mup_> Bug #579602: cannot call getBranches on a source package using the API

< https://launchpad.net/bugs/579602 > [02:36] 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] sinzui: Which OOPSes? [02:39] wgrant, https://bugs.launchpad.net/launchpad/+bugs?field.importance%3Alist=CRITICAL&field.tag=hwdb [02:40] wgrant: me too [02:40] sinzui: The other three must remain by ZOP [02:41] sinzui: But the 450480 is a regression, not an oops [02:41] I agree [02:42] 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] sinzui: Right, but I'm going to demote the regression since nobody cares [02:45] +1 [02:46] sinzui: I'm going to remove the Builder:+history timeout FF on prod with your blessing [02:47] Sure. We can put it back if we are wrong [02:57] wallyworld: are you still working on 681767 ? [02:57] bug 681767 that is [02:57] <_mup_> Bug #681767: Can't use relative URLs with launchpadlib.Launchpad - generates URI object that breaks wadllib < https://launchpad.net/bugs/681767 > [02:58] lifeless: i think that one was put on hold [02:58] since my solution was rejected [02:58] kk [02:58] thanks [03:12] sadface at the fix committed etc being images [03:17] lifeless: Where? [03:18] bug listings [03:18] They're not images [03:18] oh, wtf then [03:18] ctrl-f won't find them [03:18] Does so :) [03:18] mmm, I must have had a typo. [03:18] weird. [03:18] Works for Triaged in Firefox at least [03:19] ah [03:19] the fix is funky [03:19] try this [03:19] https://bugs.launchpad.net/~lifeless/?field.status%3Alist=FIXCOMMITTED [03:19] ctrl-F [03:19] fix [03:19] in firefox [03:19] Works [03:20] and nope, commit doesn't either. [03:20] unless I click in one of them [03:20] then it works [03:20] Works either way for me [03:21] so, doesn't for me :) [03:21] until I click in the page [03:21] Huh [03:22] do you have match case enabled ? [03:22] cause I did :( [03:22] <- muppet [03:22] haha [03:23] UI could tell you [03:23] Indeed [03:23] '15 more hits if match case is turned off' [03:27] wgrant: so - http://bugs.python.org/issue1638033 - what should the thing be set to to close in LP? [03:27] its 'accepted closed' atm, [03:27] surely closed should mean LP puts it in a terminal state ? [03:28] Probably [03:29] But I believe 'fixed closed' is what LP expects [03:29] Perhaps they've changed [03:29] what /is/ the python tracker ? RT ? [03:30] Roundup [03:30] ah [03:30] We have a custom set of mapping tables for the Python Roundup in our codebase [03:32] yay [03:32] 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' < https://launchpad.net/bugs/1050173 > [03:32] I'd say Python roundup [03:32] I believe they're all different [03:32] We certainly have a custom status map for python [03:34] tweaked [03:34] Thanks [03:34] There's 3 or 4 checkwatches criticals, so someone's likely to get around to touching that area soon [03:36] \o/ [03:36] on the make lifeless' bug list clean effort ;) [03:36] Heh [03:39] We should make more pages less terrible [03:39] Particularly since that tends to involve making code shorter [04:24] wallyworld, wgrant: https://code.launchpad.net/~stevenk/launchpad/deal-with-no-authorized_size/+merge/124097 [04:24] StevenK: Rejected due to invalid apostrophe use [04:24] +100 [04:24] What invalid apostrophe use ... [04:24] sigh [04:25] why don't people know grammar these days [04:25] I just fixed it, so I'm playing innocent. [04:25] :-) [04:25] it's one of my pet peeves [04:25] StevenK: Also, I'd prefer that you fixed policySpecificChecks rather than checkArchiveSizeQuota, maybe [04:25] StevenK: At least de-dupe the check [04:26] It may be best to remove the PPA guard around the checkArchiveSizeQuota check, I guess. [04:26] wgrant: Why? There are other checks in checkArchiveSizeQuota. [04:26] After checking on production that it won't impact the primary archive [04:26] We can apply the quota check to any archive with a quota set [04:28] wgrant: Hmmmm [04:33] wgrant: http://pastebin.ubuntu.com/1201917/ ? [04:34] StevenK: You've changed the security rejection behaviour [04:34] Also, you might want to explicitly check if it's not None [04:34] Rather than if it's not 0 [04:35] wgrant: is None, even [04:35] Well, yes. [04:35] that [04:38] wgrant: Changed? Sure, but I don't think it will impact anything. [04:41] wgrant: And "SELECT id, name FROM archive WHERE authorized_size IS NOT NULL AND purpose <> 2;" == 46 on DF [04:41] StevenK: It'll now reject security uploads to PPAs with a different message [04:42] wgrant: PPAs do not have a security pocket? [04:42] Right, they wouldn't have been accepted, but this might change the way they're rejected. [04:43] So I don't think it's a concern. It is certainly something to keep in mind when it's QA'd. [04:47] wgrant: ^ Agree or disagree? [04:48] StevenK: Have you checked the history of that method, to see why the guard was added? [04:49] It's possible it was incidental when the quota check was added [04:49] But it would be nice to check before we remove it [04:51] wgrant: For checkArchiveSizeQuota? Because it was written only for PPAs. [04:51] StevenK: But there's the opposite guard for the security pocket check [04:52] Because other archives have pockets, I guess [04:52] Right [04:52] It may have been there for a reason [04:52] Or it may not [04:52] But we should check before removing it [04:55] The else was added in r15663 [04:55] Readded, perhaps [04:55] [r=wgrant][rollback=15658] Revert r15658, as uploads to -security will have their builds automatically failed. Update associated comments. [04:55] cjwatson removed it [04:55] Ah yeah [04:56] Then I readded it [04:56] annotate before that [04:56] Ah, no, cjwatson reverted it, but I reviewed it? [04:56] Odd [04:57] The else is a little over 5 years old [04:57] I would remove it [04:58] It was added with the ubuntero PPA check [04:58] You mean, like I did? :-) [04:58] Yes [04:58] But with verification [04:58] Which we just did [04:59] Indeed [04:59] Push and I can approve :) [05:02] wgrant: Diff updating. I attempted to destroy archive-views.txt, but I'm sad to say it defeated me. [05:04] wgrant: And diff updated [05:08] https://code.launchpad.net/~ajmitch/launchpad/prerelease-backports/+merge/124100 for minimal change, if you want to comment [05:08] 8+ def test_insecure_does_not_approve_backports_before_release(self): [05:08] 10+ self.setHoaryStatus(SeriesStatus.CURRENT) [05:08] Uhhhh? [05:09] :-) [05:09] lulwut [05:09] Your two test cases are indentical [05:09] yeah, now I see that [05:10] I wasn't sure whether to even keep those since I'm not touching the uploadpolicy now [05:10] Indeed [05:10] * ajmitch was copying from the earlier tests in there, fwiw [05:10] just copied a bit too vigorously [05:11] I was about to say something like that [05:11] 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] ajmitch: bzr revert -r submit: lib/lp/archiveuploader/tests/test_uploadpolicy.py && bzr ci ? [05:12] lifeless: Thoughts on my suggestion in bug #1050191? [05:12] <_mup_> Bug #1050191: allocate-revision-karma.py is too slow to complete

< https://launchpad.net/bugs/1050191 > [05:12] right, I'd initially made the mistake of changing the approval policy & wrote the test [05:12] RARGH [05:12] Is the filename on neem pointless or something? [05:14] * ajmitch commits & pushes [05:16] Bleh, I have a file with a current OOPS and the sha1 in the filename isn't the OOPS ID [05:17] StevenK: ok, less LOC added now :) [05:17] ajmitch: test_checkUpload_backports_development could do with a comment [05:18] wgrant: Thanks for the +1, tossing at ec2 [05:18] ok to plagiarise from the test above, or do you like to have the bug # in there as well? [05:19] ajmitch: Just plagiarise, no need for the bug number [05:20] Right, so the oops id is 3607c5f44e382d14bd9ff678dbc51097, but the filename is OOPS-4f2364563d7a41ea4918845f2d86aec5. === matsubara is now known as matsubara-afk [05:22] * ajmitch waits for the diff to update [05:22] Ah, so '?id%OOPS-' to search for. Sigh. [05:23] ? [05:23] Ah, so '?id%OOPS-' is the magic string to search for. [05:24] Well [05:24] I grep for the actual unique bit [05:24] Oh, you mean finding the web-accessible OOPS ID in a known file? [05:24] I had the filename, but not the ID [05:25] wgrant: Yeah [05:25] I just search for OOPS- :) [05:26] wgrant: I'm happy to approve ajmitch's MP, do you see any issues with it? [05:26] It's from New Zealand [05:26] * ajmitch was expecting a comment like that [05:27] Oh, so, "This was written by a PHP developer." status => Rejected [05:27] That too [05:27] the love I get in here [05:28] ajmitch: Have you discussed this with cjwatson? [05:28] only in passing, not the submitted branch [05:28] Ah, I see TB discussion [05:28] Have you considered the issue of autoapproval? [05:29] they should land in unapproved [05:29] I'd considered it, made a change in uploadpolicy & then reverted once I clarified that they'll always be unapproved [05:29] Right, only RELEASE and PROPOSED (and only in unstable series) get autoapproved [05:30] I'd like to see an ack from Colin just in case, but otherwise that looks fine [05:30] ok [05:30] Let me approve it, with that note [05:30] I'll ping him later when he's hopefully around [05:30] thanks for the review [05:31] not that the diff was overwhelming [05:31] Heh [05:56] wgrant: https://code.launchpad.net/~stevenk/launchpad/double-archivesub/+merge/124102 [06:02] StevenK: It already deals with it [06:02] By raising an exception [06:03] wgrant: That isn't caught and ends up as an OOPS [06:04] StevenK: Right, but you could catch it [06:05] Or make it a 400 if it's an issue with the API [06:06] wgrant: I could, I decided to follow the pattern that we have for bug/branch subscriptions [06:07] It looks like that can only happen over the API [06:07] So I would just annotate it with BAD_REQUEST [06:08] https://oops.canonical.com/?oopsid=3607c5f44e382d14bd9ff678dbc51097 disagrees [06:09] Ah, indeed, missed the two browser callsites [06:10] In one case you want to crash [06:10] In the other you probably want to inform the user that they're insane [06:10] Alternatively, in the latter ('activate') case you could call getAuthToken first [06:10] Or catch the exception and call getAuthToken [06:11] We sort of [06:11] if self.request.form.get('activate') and not self.active_token: [06:13] Hm, then do you know how the exception happened? [06:13] Perhaps the token was deactivated [06:13] Hm, perhaps [06:19] * StevenK tries to remember where PersonArchiveSubscriptionView is hit from [06:19] You mean Person:+archivesubscriptions? [06:19] Or one of the archive-specific views? [06:20] I created an authtoken and then called deactivate on it and the UI says I have no tokens [06:21] You need a subscription [06:21] The UI shows subscriptions [06:23] Hm, Archive:+subscriptions is forbidden as an admin? [06:23] Yes [06:23] Admins don't hold launchpad.Append on IArchive [06:23] It's like launchpad.Special in that regard [06:25] Right, now I have a subscription [06:30] Then I set it to expired and it disappears from the UI again [06:31] Sure [06:31] Doesn't necessarily mean it's not accessible [06:31] It's also possible that the token is somehow deactivated, but the sub is not [06:31] Oh, there's a seperate table for the token? [06:31] (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] yes [06:32] Subscriptions can be for teams [06:32] Tokens can't be [06:32] wgrant: is this index I see before me to replace an existing index, or in addition? [06:32] stub: In addition [06:33] wgrant: Why have status included then, as the preamble states it is indended for use when not filtering by status? [06:34] stub: It's not necessary, but due to that order it also doesn't affect size/performance significantly. [06:34] I can remove it if you want [06:34] It's not really useful until we have index-only scans, I guess [06:49] cjwatson: What blockers remain to prevent the removal of delayed copies? [07:38] good morning [07:38] 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] wgrant: Unless we need to use the four fields for ordering, but I don't think we ever want to do that. [07:41] Indeed [07:41] I might drop status [07:46] stub: That's done [07:46] ok === almaisan-away is now known as al-maisan [08:47] 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] stub: You need two separate dependencies [08:48] ok, so don't just believe that builddeb worked :) [08:48] 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] Also, << rather than < [08:51] pgbouncer (>= 1.5.2-2+lp2), pgbouncer (<< 1.5.2-3), [08:51] 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] That won't work. [08:51] Due to ~ [08:51] Yeah [08:51] I was about to suggest the Provides [08:52] But it will hopefully be upstream soonish [08:52] For the versioned Depends to work, you'd want pgbouncer (>= 1.5.2-2+lp2~), pgbouncer (<< 1.5.2-3~) [08:52] But the Provides is probably a better solution for now. [08:52] Sure about that twiddly after the 3? [08:53] Yes, otherwise eg. 1.5.2-3~lucid1 will satisfy your dep [08:53] oh, guess so [08:53] 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] 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] 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

< https://launchpad.net/bugs/575450 > [09:46] cjwatson: Ah, right. [09:46] I'd forgotten about the starvation issue [09:46] 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] The vague consensus seemed to be the latter, but also that celery was a bit untried. [09:47] That's one way of putting it [09:47] I was due to try out celery for ProcessAcceptedBugsJob, when I get back to that ... [09:47] Indeed [09:50] adeuring: It looks like a recent private projects landing has broken buildbot. Can you investigate? === al-maisan is now known as almaisan-away [11:13] adeuring: ping [11:13] nvm, looks like wgrant already ping'd you on it [11:13] morning rick_h_ [11:14] 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] rick_h, wgrant: acutally, I did not notice... [11:14] looking now [11:14] adeuring: cool, thanks. Sorry for the dupe :) [11:20] 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] For reference, the script is here: https://launchpad.net/lp-get-ul10nstats/trunk === broder_ is now known as broder === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === _mup__ is now known as _mup_ === micahg_ is now known as micahg === almaisan` is now known as al-maisan === jamestunnicliff_ is now known as jamestunnicliffe === heroux_ is now known as heroux === al-maisan is now known as almaisan-away === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jcsackett | Firefighting: - | Critical bugs: ∞ [13:52] Are there any prizes given for marking really old bugs as duplicates? [13:54] mpt: I'll give you cake [13:54] how's that [13:54] deal :-) [13:54] win win :) [13:54] mpt: but you're not allowed to create new ones :) [13:55] What would be the point of that? If they're new ones they're not really old ones [13:55] oh, you mean you're limiting me to marking duplicates, not reporting bugs at all === matsubara_ is now known as matsubara [14:04] > 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] For reference, the script is here: https://launchpad.net/lp-get-ul10nstats/trunk === wgrant_ is now known as wgrant === salgado` is now known as salgado [15:14] 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] I've double checked my key and its correct [15:32] hmm.. hmm.. appears as tho as somepoint I was logged out from bzr launchpad-login.. stand down all :-) === lan3y is now known as Laney [16:05] ok.. more hmm.. any chance that lpsetup changes my launchpad-login? [16:06] cjohnston: breaking things :) [16:06] probably [16:06] just not sure how :-( [16:07] sinzui: might you give cjohnston some pointers please [16:07] I have't use it [16:08] Not quite sure why I'm importing the Yellow Squad key: http://paste.ubuntu.com/1202922/ [16:09] jcsackett, hi. I have a branch for review, but.... [16:10] jcsackett, I'm about to lunch. So don't mind waiting until I'm back if you need to chat interactively. [16:10]