[00:17] Yay [00:17] just configured a new commercial project on qastaging [00:17] With proprietary everything [00:18] As an unprivileged user [00:18] and an entitlement I presume ? [00:19] Right, you need a commercial subscription to activate the proprietary bits [00:19] But you get a complimentary 30 day sub automatically [00:19] So [00:19] Let's do a nodowntime [00:19] And then we can declare victory over Launchpad privacy [00:22] wallyworld, StevenK: https://oops.canonical.com/oops.py/?oopsid=9944a90ab5ba3bb77a3c7f4a17c39512 [00:22] We have a problem [00:23] Huh, I'm not even sure why that's trying to filter by pillar [00:23] looks easy enough to fix [00:24] I'm not sure there's a good reason to not just drop the pillar arg [00:24] But if we want to keep it then just grabbing the .pillar attribute should work~ [00:25] pillar is used for things like error recipients etc [00:25] so we do need it [00:25] Hm, really? [00:25] Also, we should maybe guard that behind a privacy check [00:26] I thought the error recipient was just the requestor [00:26] checkout the SharingJob getErrorRecipients and getOperationDescription methods [00:26] pillar owners should be informed [00:27] Oh right [00:27] That was a late change [00:27] Forgot that [00:28] so we just ned to extract the distro from DistributionSourcePackage and we are ok i think [00:28] Right, and BugTarget has a handy pillar attribute nowadays [00:28] So it's just a matter of adding that [00:29] i can fix it. how often are we oopsing? [00:30] Probably on every transition that involves a DSP [00:30] I don't have numbers [00:30] But it won't be uncommon [00:31] someone at front door, back in a sec [00:31] It'd be great if you could fix it, as I'm not exactly clear on what tests we have here [00:31] Sure [00:44] hopefully that will be the only problem we find today [01:07] StevenK: are you removing disclosure.unsubscribe_jobs.enabled ? [01:08] Yes [01:09] StevenK: in that case, my fix for the oops will conflict. it's 1 line. so you could add it to your branch or i could remove that flag https://pastebin.canonical.com/72985/ [01:10] i added a drive by while i was there [01:11] Right [01:11] bug 1040948 [01:11] <_mup_> Bug #1040948: oops retargeting a bug to a distribution source package < https://launchpad.net/bugs/1040948 > [01:11] did you want to take it then? [01:11] with the flag gone, no new tests will be required [01:11] so it's a dead easy fix [01:12] We need the OOPS fix ASAP [01:12] The flag removal will break hundreds of tests [01:13] (I suspect, at least -- DB permissions are probably going to be scary) [01:14] Shall we cowboy the OOPS fix then? [01:14] that might be an idea [01:15] Indeed [01:15] Given that it's Friday, that would be my suggestion [01:16] How close are we in terms of QA... [01:16] QA of? [01:16] the patch? [01:16] wgrant: We are nowhere near [01:16] There's a whole lot of disclosure-relevant revisions that we should really deploy today if possible [01:17] Still wondering how to QA my security_contact removal [01:17] Mmm, indeed [01:17] Might not be deploying today [01:18] Running test -vvm registry locally has tossed me 29 failures [01:18] And it's still going [01:19] Heh [01:20] wgrant: I guess I need to wait for the destruction of security_contact to be deployable before I land the DB patch that drops the columns. [01:20] StevenK: Not deployable [01:20] Deployed [01:21] Which is what I meant, but I thought so. [01:22] hurry up branch scanner ffs [01:29] sigh, looks like branch scanner fucked by branch [01:29] my [01:39] StevenK: wgrant: https://code.launchpad.net/~wallyworld/launchpad/retarget-bug-oops-1040948/+merge/121111 [01:40] And a drive-by [01:40] wallyworld: r=me [01:40] But do check that it actually works :) [01:40] already did that [01:41] so now i request a cowboy? [01:41] qas first [01:41] so lp-land, ask and for the rev to be cowboyed to qas? [01:41] Or wait six hours for buildbot [01:42] And 24 hours for QA [01:42] So what wallyworld said [02:25] StevenK: Up to 100 failures yet? :) [02:26] No, it was 30 for -m registry [02:26] Down to 6 [02:30] And they're all celery [04:19] Oh, BLEH. [04:19] test_transition_to_{PRIVATESECURITY,USERDATA}_information_type all rely on the code that fires if the feature flag isn't set. [04:25] wallyworld: ^ [04:25] um [04:26] so can you just change the expected subscribers in the test? [04:27] That sounds best [04:27] It's also possible that the tests are now pointeless [04:27] And can simply be deleted [04:27] well, even if expected = [], then we should still test [04:27] I wasn't certain, which is why I bought it up [04:27] since we want to avoid leaks [04:28] StevenK: so i would modify the tests to change the expected subscribers list [04:28] MismatchError: There were 3 matchers left over: Equals(), Equals(), Equals() [04:28] For example [04:30] so from memory, we no longer subscriber bug supervisor [04:30] not sure about the other 2 [04:33] Yeah, I'm not sure either [04:34] I think it requires more discussion, so I'm close to reverting the unsubscibe_jobs flag changes and proposing it [04:39] what i normally do is construct each person with a name reflecting the role eg 'bug supervisor' or 'pillar owner' on then it's clear who the subscribers are in the logged error [04:39] StevenK: ^^^ [04:40] Well, it's quite obvious the tests are checking that bit of code only [04:41] http://pastebin.ubuntu.com/1163826/ [04:44] so you no longer allow for required subscribers [04:44] on lines 16, 17 === almaisan-away is now known as al-maisan [04:52] wallyworld: Are those two blocks unrelated then? [04:52] Because they're guarded by the same flag [04:52] And prod certainly isn't running that code [04:53] are they really guarded by the same flag? i may have misread the diff [04:53] i though that the flag was all about whether to run the job or not [04:54] the flag is not about whether to remove unnecessary subscribers (from memory) [04:54] - if len(subscribers_to_remove) and not bool( [04:54] - getFeatureFlag('disclosure.unsubscribe_jobs.enabled')): [04:55] oh right, yes [04:55] i didn't connect the dots properly [04:57] i think we still need to understand whats going on here [04:57] I think the tests can pass as-is iff we run the RASJ [04:58] Or I can keep the behaviour and drop the FF guard [04:58] But I'm concerned because I think prod is not running that code [04:59] maybe a check on qas to see what's happening? [05:00] * wallyworld is late for school pickup [05:00] Yeah, I have to disappear for a bit too [05:01] wallyworld: I'll leave this for now, probably toss it at ec2, and we can chat about it on Monday [05:01] ok, sounds good === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === lifeless_ is now known as lifeless === al-maisan is now known as almaisan-away [06:25] wallyworld: Haha, db-devel failed in buildbot again [06:25] sigh [06:27] It's StevenK's fault this time [06:27] Wat [06:27] Exception: Timeout waiting for auditor to start. [06:27] setup failure [06:27] I bet that's the port in use crap [06:28] force it? [06:29] Yah [07:06] Need a SAN check: WAITING state in launchpad-buildd is when the buildd is waiting for buildd-manager to grab files or something of that matter? [07:06] could bug linking branches be broken in the World Order ? [07:09] lifeless: Yes [07:09] NCommander: yes [07:10] lifeless: It may be fallout from our work, but it's not clear. [07:10] at all [07:10] Hopefully blue can investigate the failures [07:10] And then throw them at us if it does prove to be our fault [07:11] wgrant: thanks. Second thing. THere doesn't seem to be much w.r.t test cases in launchpad-buildd; what is acceptable for tests in this case? [07:11] (I have a test_buildd_live-image script similar to the other ones that exist) [07:12] lalala [07:13] uh oh. I think I broke wgrant [07:14] Disclosure already broke him. [07:15] * NCommander vaguely wonders if H.P. Lovecraft wrote parts of Soyuz [07:17] At least this part of this project approaching something resembling to completion. It properly handles dispatch builds, and two of the three build engines are almost fully coded. Need to add some slightly better error handling, and a more conclusive test runner [07:19] I know DEPFAIL builds get auto-retired at least for normal builds. If I have an image that skews, I don't think I want to give this state to Launchpad lest it try to spin images automatically [07:20] DEPWAIT [07:21] Oh dear, does wgrant have a case of the FRIDAY? [07:21] StevenK: DEPFAIL = "BuildStatus.DEPFAIL" [07:21] StevenK: DEPWAIT as a state doesn't exist in the buildd code [07:21] * StevenK quickly patches and merges it so it does. [07:21] You were saying? :-P [07:22] lol [07:22] It's DEPFAIL on the buildd [07:22] MANUALDEPWAIT in Soyuz [07:23] Yes, and it's automatically re-tried. [07:23] Who said Soyuz was confusing? [07:23] * StevenK stabs the precise upgrader. [07:23] Why do you want to remove portmap? I need that! [07:24] Fetched 222 MB in 6s (15.2 MB/s) [07:24] Love my local mirror [07:25] StevenK: Just wait until it starts silently defaulting to NFSv4 and hanging [07:25] I don't want NFSv4 :-( [07:25] And anyone who tells me it's the future will be stabbed. [07:26] with extra kerberos on top? [07:26] NFS was just FINE without KRB. [07:26] For not very big values of fine [07:27] NFS before Kerberos belongs in the 60s [07:27] Well, it did expand to No File Security rather than Network File System, but it was fine! [07:27] wgrant: Oh, so before Ethernet, and UNIX? [07:33] mgz: Some Launchpad branches are failing to scan too, and without using --fixes [07:33] speaking of which mgz StevenK wgrant https://bugs.launchpad.net/launchpad/+bug/1040777 [07:33] <_mup_> Bug #1040777: Scanning of branches with linked bugs is broken < https://launchpad.net/bugs/1040777 > [07:34] StevenK: thanks [07:35] yeah, that's probably a misdiagnosis [07:36] I can push branches with --fixes and they work, but ubuntuone-client seem to have a high incidence of failure [07:36] StevenK: Yes, it should never have been used :) [07:36] mgz: ubuntuone-client has more private bugs [07:36] Possibly relevant [07:37] wgrant: and is the bug valid or was it being done wrong ? [07:37] --fixes private bug... [07:38] The bug is certainly valid [07:39] I don't know if the diagnosis is correct [07:39] Someone should test it [07:40] good morning [07:40] * NCommander feels that Soyuz was written by taking the Necronomicon and rewriting the summoning instructions for a Great Old One in Python [07:41] Damn it, NCommander is catching on. [07:41] * NCommander looks for commits by Abdul Alhazred [07:42] * czajkowski is off to find tea in this place [07:43] StevenK: re: NFS. Meh, upgrade to AFS. Less arcaic voodoo [07:44] Eh? What? Are you smoking crack. There's *MORE*. [07:46] Far more voodoo, but it's far less archaic and terrible voodoo :) [07:47] I was thinking about iSCSI [07:48] ATE is less pain [07:48] NFS == why stateless protocols suck [07:48] * NCommander ducks [07:51] Now, I wonder if I need dkms for 3.2.0 on this machine [07:55] Sigh, yes. [07:55] Because updating the version of the atl1e driver is too hard. === almaisan-away is now known as al-maisan === jam1 is now known as jam [08:56] jelmer: just checking in with you how the py2.7 stuff is coming. I see the 3 packages in ~jelmer/+archive/py2.7 which looks good. [08:56] is it time for us to start copying the other packages into there? [09:12] jam: yep, I'll put them all in the ~canonical-bazaar ppa [09:12] jelmer: sounds good, is the build system working a bit smoother yet, or do we still have a large backlog? [09:15] jelmer: looking here: https://launchpad.net/~jelmer/+archive/py2.7 i see 'failed to build' 3 days ago. [09:15] does that mean they were retried and successfull? [09:16] ah, missing dependencies seems to be claimed [09:16] 'libtinfo-dev' [09:16] it is in depwait [09:17] Hmm, that's definitely one I fixed [09:17] jam: I'll just upload to ~canonical-bazaar, should be fine there [09:17] https://launchpadlibrarian.net/113212101/buildlog_ubuntu-lucid-i386.python-defaults_2.7.3-0ubuntu6~lp1_FAILEDTOBUILD.txt.gz [09:17] seems to say there is a problem with deb helper and compat levels [09:17] dh_clean: Sorry, but 7 is the highest compatibility level supported by this debhelper. [09:18] I don't see anything about a libtinfo in https://launchpad.net/~pythoneers/+archive/lts/ [09:18] so I don't really know what that means [09:19] jam: I've simply dropped that dependency, which was fine [09:23] jelmer: k, can we consider the py2.6 as Done-Done then, (it certainly built correctly) [09:24] jam: sure [09:25] jelmer: I'll chat with webops about coordinating getting packages into -cat, though we still need to vet everything in EC2, right? [09:26] jam: yep === adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugs: 4.0*10^2 [10:02] jelmer: so do you want me to copy the packages to ~canonical-bazaar, or do we need to do a change to drop the extra dependency, etc.? [10:02] jam: I'll upload to ~canonical-bazaar [10:02] k === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [11:08] hmm, was +roadmap removed at some point? [11:11] [r=gmb] Fix bug #174480 by removing the specificationtarget roadmap [11:11] <_mup_> Bug #174480: Person's +roadmap page contains blueprints they're not assigned to < https://launchpad.net/bugs/174480 > [11:11] It's been gone a while [11:12] jelmer: I know what ti di wutg tgat queston [11:12] heroux: ^^ [11:12] got the answer last night off flacoste [11:12] but want to talk to mrevell about the update of the page [11:12] czajkowski: ah, cheers [11:13] thanks === al-maisan is now known as almaisan-away === bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring, bac | Firefighting: - | Critical bugs: 4.0*10^2 [12:24] yes please [12:31] https://docs.google.com/a/canonical.com/spreadsheet/viewform?formkey=dGpha1NHV2t4VU1ZSU9FZDdMRnlEZWc6MQ&ifq&pli=1&auth=DQAAAKEAAABo3bjn2-seKH26Wayo7aGz3TXRSLqxBB0kow7ltNjO6Be3g2CPijNFrSW7HBWMiRM3Qya0NGza7qgUzNGIejTm3cICSpVWTOiTZmr2lSkoSC6Tm7nUliaLq-Y5SnyAFYZYYdE5HtDqP9YM8TuJfUXgWwQoAWvpFvFZZD9Og7S4rCW34QrxE77EPctJubSTZpWjTv6FvlUz44rQxQCxRQaz7UjNHh7yL6MFoyuY9SWIbw&authuser=1 [12:32] nm [12:32] gary_poster: ^^ === Pendulum_ is now known as Pendulum [12:47] jelmer: hows the package uploading going? I'm pretty sure we're not going to quite get it all vetted for web-ops review by the end of the day. [12:57] jam: Sorry, was distracted trying to finish off some of my other work. They're uploaded now. === almaisan` is now known as al-maisan [13:09] jelmer: to what ppa? (I'm not seeing it browsing around) [13:11] adeuring, abentley, rick_h_ -- hi there. I'm here today after all. [13:11] Late news yesterday that my home wouldn't close today. [13:12] jam: https://launchpad.net/~canonical-bazaar/+archive/py27, though I don't see them either yet [13:14] jelmer: py27, not py2.7 [13:14] 2012-08-24 12:55:13 DEBUG Launchpad failed to process the upload path '~canonical-bazaar/py2.7': [13:14] 2012-08-24 12:55:13 DEBUG [13:14] 2012-08-24 12:55:13 DEBUG Could not find a PPA named 'py2.7' for 'canonical-bazaar'. [13:15] jelmer: right [13:17] I see it now, but it looks like 16-24 hr backlog [13:38] adeuring: your branch is blocking a rollout http://lpqateam.canonical.com/qa-reports/deployment-stable.html [13:43] sinzui: sorry, qa'ed th branch earlier today, but forgot to update the bug. done now [13:43] rock [13:43] thank you adeuring === slank` is now known as slank === slank is now known as Guest97004 === garyposter is now known as gary_poster [14:04] does this make sense to anyone https://bugs.launchpad.net/pybars/+bug/1040096 :/ [14:04] <_mup_> Bug #1040096: Missing a context variable causes an exception < https://launchpad.net/bugs/1040096 > [14:04] czajkowski: yea, makes sense [14:05] czajkowski: have to see if that's design or bug [14:05] jcsackett: Bug #1035298 need qa [14:05] <_mup_> Bug #1035298: lazr namespace in js modules should be removed

< https://launchpad.net/bugs/1035298 > [14:05] looks like the bug says it's different so guess it's a bug [14:06] rick_h_: k cheers [14:09] sinzui: done. [14:10] thank you! [14:10] have a nice vacation [14:12] sinzui: I'm not sure where you're thinking of deploying up to, but I'd be fairly reluctant to do 15857 (the security_contact removal) on a Friday night. [14:12] The rest looks quite sensible [14:13] wgrant: I am somewhat more reluctant to release the features that I know are needed for commercial admins to complete sharing participation [14:14] sinzui: I think all the important changes are before the security_contact revision [14:14] wgrant: http://pastebin.ubuntu.com/1164503/ [14:14] So it should be doable [14:14] sinzui: Hm? [14:15] Those two hunks look unrelated [14:15] ^ my change to ensure the commercial admins only get access to commercial project sharing requires a grant to the mailprocessor. You expressed some concern that the change could affect other scripts [14:15] Oh, right. [14:16] We can apply the index in production now. But my change might really be for you to deal with monday [14:16] We already cowboyed a similar permission fix tonight, as you may have seen [14:16] Agreed [14:16] Though the index is not important now... [14:16] So I will list a release as required for czajkowski and yourself to help users next week [14:16] Also, I think that index may already be on production [14:17] sinzui: this will be for me and mrevell [14:17] to go through things right ? [14:19] czajkowski: Lp is caught in an ironic state in production. We are one release away from the fix. Lp only lets commercial admins set the bug and branch sharing policy, but they cannot see the sharing page. The fix is to let use see the page for commercial projects and let maintainers set the policies themselves [14:21] At this moment in Lp, we commercial admins can only configure the policies for our own projects. wgrant and I just updates Lp's projects. Cody can configure his projects if he chooses. That is about it [14:22] jelmer: so it looks like the python-2.6 i386 build got promoted and completed quickly, is it possible to do the python-2.7 and python-defaults? [14:22] If they are all going to queue for a while, it would be good to get them done over the weekend. [14:23] jam, jelmer: I've given that whole PPA a score bump [14:23] wgrant: thanks [14:23] So new uploads should build quickly [14:23] sinzui: ah ok [14:23] wgrant: yeah I saw it hit score of 99999 or something like that :) [14:24] mgz: could you look at https://support.one.ubuntu.com//Ticket/Display.html?id=21263 please [14:24] sinzui: So, I'll organise QA with StevenK on Monday, hopefully deploy in the morning, watch for missing permissions, and hope nothing breaks while the UK is on holiday [14:24] sinzui: Have you talked czajkowski/mrevell through what needs to be done? [14:25] I was preparing it when I got the urge to do the release [14:25] Great [14:25] as you do :) [14:25] I shall see you in a week and a bit, then [14:26] we can review sharing on qastaging now if your like [14:26] wgrant: ah, thanks :) [14:26] czajkowski: ^ you can see what we are advising users to do [14:26] https://qastaging.launchpad.net/fusionapp/+sharing [14:28] maybe I can get a sql report that will suggest the mapping of old rules to new sharing? [14:32] czajkowski: looking [14:33] ...that's... not the most useful question [14:35] answered. === al-maisan is now known as almaisan-away === Guest97004 is now known as slank === slank is now known as Guest26013 [15:40] abentley, I'll send you my updated doc in 20 minutes. And how about we talk around 30 minutes after that? To give you time to review it and think on it. [15:40] deryck: sounds good. [15:41] abentley, great, thanks! === salgado is now known as salgado-lunch === salgado-lunch is now known as salgado [17:49] deryck: abentley opinions on feature flag naming? Was going to use private.project.enabled [17:50] rick_h_: I think we're supposed to name the application first if applicable. registry.project_privacy.enabled? [17:51] rick_h_, I think I would go with disclosure.private_projects.enabled [17:51] abentley: yea, wasn't sure on that. purple seemed to use disclosure. so stuck with that [17:51] ok, can jump on their space they carved out [17:51] oh, sorry, missed abentley's reply [17:51] * abentley does not have a big stake in this. [17:51] I think the goal was to keep all related work under the disclosure project under that name. [17:52] yea, figured I'd just sanity check, will stick with disclosure [17:52] deryck: rgr [17:52] I'm not picky if the middle bit is private_projects or project_privacy or some other form of that [17:57] rick_h_: We need to consider how we display People associated with blueprints (those who have access, and those who are subscribed). Could we chat about this at some point? [17:57] abentley: sure thing [17:57] rick_h_: When's good for you? === almaisan-away is now known as al-maisan [17:59] abentley: give me 5 to look over the blueprint stuff and we can hangout [18:00] rick_h_: Cool. [18:05] abentley: normal standup hangout ok? [18:06] rick_h_: sure. === salgado is now known as salgado-afk [18:28] sinzui: We've stumbled over some UI issues with subscribers on blueprints and access grants. Do you have time to chat about what you're doing with bugs? [18:56] abentley: I am [18:57] sorry for the delay...my lunch appoint was interrupted by a kind police officer that pointed out my car was not street legal [18:57] sinzui: Cool. Could you meet me and rick_h_ in http://tinyurl.com/orange-standup ? [18:57] I had to detour to get the car inspected to prove it was legal [18:58] sinzui: So, cop was wrong. [18:58] sinzui: ? [18:58] No, my stickers expired last month [18:58] I don't drive often enough to notice [18:59] sinzui: ah. I had that earlier this year. Having baby blew our attention away from such things. OOPS. === deryck is now known as deryck[lunch] === salgado-afk is now known as salgado === al-maisan is now known as almaisan-away [20:14] Wow. 16 people have viewed the sharing video I uploaded within 15 minutes. I haven't even finished the blog to announce it [23:20] Oh [23:20] wallyworld [23:20] 's db-devel revert landed on devel [23:20] That explains the conflict [23:20] * wgrant disentangles