[00:50] wallyworld___: https://code.launchpad.net/~stevenk/launchpad/drop-garbo-accesspolicy-redux/+merge/97779 [00:50] Three underscores? That's a bit excessive ... [00:51] StevenK: each time i plug or unplug my laptop from the docking station it disconnects the network [00:51] Handy. [00:52] you sure you won't need to re-revert the revert again :-P [00:52] I bloody hope not. [00:53] r=me [00:53] It should be redeletion :-P [01:32] wallyworld___: Feel like reviewing https://code.launchpad.net/~wgrant/launchpad/GRAR/+merge/97782? [01:32] wgrant: looking now [01:33] Thanks. [01:34] wgrant: typo line 9 otherwise good. what a silly error [01:34] wallyworld___: Already fixed that [01:34] THanks. [01:34] np, r=me [01:58] wgrant: Importing a bug that has False into a product that has private_bugs = True still creates the bug as public. [02:00] StevenK: :( [02:01] wallyworld___: I guess we probably want to display the beta banner too. [02:01] wallyworld___: I think we can probably turn this on RO for beta testing on Tuesday morning if we get these few things fixed up. Are you going OK, or should I work on bits once I finish the garbo job? [02:03] wgrant: the read only branch is up for review, just entering a bug for the performance issue [02:03] I see there's an unassigned card in Coding -- that's you? [02:03] wgrant: Fixing it is easy, overwrite private if product.private_bugs. A test is harder [02:04] Aha [02:04] No longer unassigned. [02:04] wgrant: not unassigned anymore. i was in the middle of doing it when i answered you irc ping [02:04] Heh, sorry. [02:04] wallyworld___: I'll review the RO branch after lunch. [02:04] ok, thanks :-) [02:05] StevenK: Isn't that Done-Done? [02:05] Heh [02:06] :-) [02:06] wallyworld___: What about disclosure.enhanced_sharing.enabled and disclosure.enhanced_sharing.writable? [02:06] wgrant: Doesn't your everything is broken in IE8 card move? [02:06] StevenK: No [02:06] :-( [02:06] StevenK: A few less things are unbroken in IE. [02:06] But there are more branches. [02:07] wgrant: i guess so [02:07] * mwhudson squinets [02:07] i think there is the wrong parity of negatives in that sentence? [02:08] Um, yes. [02:12] wallyworld___: getPrecachedPersonsFromIDs is probably of interest. [02:12] wgrant: no kidding [02:12] but thanks :-) [02:13] I've seen people reimplement it before :) [02:14] the real issue will be the web service marshalling - whether that triggers lazy evaluation of properties [02:14] It does, but getPrecachedPersonsFromIDs is used to prevent that. [02:15] wgrant: sure, but i don't want to load data not needed on the client [02:15] there's a lot of joins etc that can be avoided [02:15] Indeed. [02:16] But you can't avoid that while still returning marshalled Persons. [02:17] wallyworld___: Person.api_activemembers shows the args you need. [02:17] It would be nice to avoid this, but the current API design makes that a bit hard. So for now I'd just precache. [02:17] wgrant: but i don't really need marshalled persons in their intirety [02:18] That's true. [02:18] kusy name,displayname, self_link really [02:18] Also icon, but you don't use that yet. [02:18] anyway, i'll see what can be done [02:32] wallyworld___: Reviewed [02:32] Hah [02:32] 13:32:23 < wgrant> wallyworld___: Reviewed [02:32] 13:32:25 -!- wallyworld_ [~quassel@27-33-46-253.static.tpgi.com.au] has joined #launchpad-dev [02:36] wgrant: what's up? [02:39] thanks for the review - the reason for making the links depend on either flag is so that it is robust enough to handle that we may want to just activate the writeable flag and expect that it all should work [02:39] Will the underlying APIs cope with that? [02:40] yes [02:40] well that is the intent, i'll double check to be 100% [02:41] why did you paste the "wallyworld has joined..." text? [02:42] wallyworld_: Because I tried to talk to you two seconds before you reconnected. [02:42] loltpg? :) [02:42] no. as i said to StevenK, when i disconnect the laptop from the docking station, the network hicups [02:43] i don't know why you guys dis tpg so much. it's been great for me [03:07] It's easy when you start the day as wallyworld and end up as wallyworld__________________________ [03:08] but that's nothing to do with tpg [03:08] So you say. :-P [03:10] StevenK: Is the migration done on prod yet? [03:10] how do you know it is? [03:12] wallyworld_: I'm yanking your chain. For a happy TPG customer, you sure are defensive. :-P [03:12] because you dis it so much :-) [03:13] wgrant: Nope. [03:13] 350k bugs to go [03:13] wgrant: did you put up the card about changing access for sharing to owners and not drivers? i didn't think we had agreement from the product team yet for that change? [03:15] wallyworld_: Did Product actually say that driver should have access? [03:15] That's pretty odd, since driver is approximately RM [03:15] I don't think we should open it up to driver yet. [03:15] wgrant: can't recall exactly where that came from but it was communicated as a requirement [03:16] in an email perhaps, can't recall [03:16] I think that's an OEM thing [03:16] Ah, right, the silliness with pmteam [03:16] But I'm not sure it matters massively for the initial beta next week... [03:17] I'd prefer to err on the side of revealing too little. [03:17] not sure. we'd best check [03:17] Indeed. [03:23] sinzui: I just fixed bug 457489, so I'm not sure why you self-assigned it. :-) [03:23] <_mup_> Bug #457489: Bug importer ignores the product.private_bugs flag

< https://launchpad.net/bugs/457489 > [03:23] StevenK, I did not see you working on it [03:24] sinzui: why are you awake? [03:24] sinzui: I even have a card for it [03:24] Because the bug should have been fixed. I see the public security rule trumped the default rule [03:24] lifeless: Clearly the bug I linked is so henious that sinzui can't sleep. [03:25] StevenK, I was looking a the bug, I do not look a kanban during non-work outs [03:25] hours [03:26] sinzui: Sorry if I stepped on your toes, I reproduced the bug before lunch and just finished off the branch. [03:27] Yeah. I wrote the test and thought, what, the call chain is right, why is it wrong [03:27] StevenK, you get a free review [03:27] Heh [03:28] sinzui: I love how the bug importer was setting private, creating the bug, and then re-grabbing private from the node. [03:28] StevenK, the public security rule still trumps your code [03:28] and it should not [03:30] sinzui: http://pastebin.ubuntu.com/885845/ [03:33] you missed the duplict rewrite of of security (twice no less) The bug is made private correctly, then change once by code from 5 years ago then made public by code from last year [03:33] There are duplicate lines which i see you saw [03:33] http://pastebin.ubuntu.com/885848/ [03:34] Your code will fail if you run my test I think [03:35] I think my new code is okay, since your test reads reads like mine. [03:36] StevenK, I believe product.createBug() -> BugSet.createBug() which ignores/overwrites any value in the private param. The bug is create private every time. [03:37] You code has a needless check of .private_bug. We do not do that anywhere else in lp code. Searching will reveal two methods seem to know about it [03:38] sinzui: Now test_public_security_bug fails since I force private = Ture [03:38] *True [03:38] why does your change still set security twice after creation! [03:39] Oh, bloody heck. I missed that one. [03:40] sinzui: http://pastebin.ubuntu.com/885859/ [03:40] I tested with a public security bug. I found that bug was created private but those two alterations overwrote what createBug does [03:41] Right. [03:44] StevenK, didn't you just break the public security bug case in another test. I am allowed to import a public security bug. Lp created it private, then the import makes it public, but it should only do that if the project does not have default private bugs [03:45] Sigh, can't we use information_type [03:45] That makes it so much easier. :-) [03:46] Damn right [03:46] I think bug.setPrivacyAndSecurityRelated is needed, but it must be guarded by if not self.product.private_bugs: [03:47] And we need the private or security_related [03:47] Just to deal with that case [03:49] StevenK, Look at by diff http://pastebin.ubuntu.com/885848/ [03:49] * wgrant randomises everything except faq_id_seq, bug_id_seq and question_id_seq. [03:50] We test with the public_security_bug because it was the reason there were two rules in the code to overwrite. [03:50] security and privacy. [03:51] We just want a second test that shows that .private_bugs wins in battle with public security [03:51] Right [03:52] Or I can just re-use the current test ... [03:52] StevenK, any, you understand what I was seeing. I am approving your branch. I see jc's branch came back with two failures, So I can fix these and go to sleep [03:56] I'm looking forward to CreateBugParams() taking information_type, since that setting crap can die [04:01] Yay, /builders in less than 100 queries [04:08] I'm thinking we need more soft oopses [04:08] -> on any page with > 100 queries [04:10] lifeless: I think we should soft oops anything over 2s or 100 queries, personallhy. [04:11] It's an awful lot of soft oopses, but all those requests are bad. [04:22] wgrant: 2 queries, static [04:22] https://code.launchpad.net/~wallyworld/launchpad/sharing-view-scalability-956634/+merge/97793 [04:23] previously it was O(n) [04:25] wallyworld_: Hell yeah [04:25] That's what I like to see. [04:25] me too [04:29] Mm [04:29] This makes API usage awkward [04:29] But I guess it will do for now. [04:49] wgrant: with the api usage, it depends on what data they want back. we can always add additional attributes, but for now, let's get this landed to fix the core issue [04:50] are you able to +1 it and i'll send to ec2 [04:51] wallyworld_: Sorry, got distracted in -ops [04:51] np [04:52] wgrant: one option is for the callers to ask for the attributes they want [04:52] otherwise they just get a minimal set like what's there now [04:52] i've used that pattern before quite successfully [04:52] that way the api can be used for any use case [04:52] and not have to over or under deliver [04:53] Good luck doing that with lazr.restful(client) [04:53] Approved [04:53] thanks [05:16] has anyone else encountered https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/956655 by running lxc locally? [05:16] <_mup_> Bug #956655: libvirt dnsmasq causes runaway chain reaction < https://launchpad.net/bugs/956655 > [05:55] * wallyworld_ stabs ec2 - a landing run failed and no email :-( [05:59] wgrant: why + getUtility(IAccessPolicyArtifactSource).deleteByArtifact(abstracts) ? [06:00] wallyworld_: Ah, good point. Because artifact deletion should remove the grants and policy links, rather than removing the grants and then failing with a foreign key violation. [06:00] Should probably test that directly. [06:00] yes, was wondering why exiting tests didn't fail or there wasn't a new test added [06:08] wgrant: we can't select from the access artifact grant table to see if a bug id is in there and therefore already mirrored? [06:10] wallyworld_: There may not be any grants. [06:10] We've used this pattern before. [06:10] For the SPR.changelog migration, IIRC [06:10] storing the value in memcached. [06:11] ok. and if the app is restarted, we just redo some work [06:11] Not the app, memcached. [06:11] And memcached is very rarely restarted. [06:11] that runs in a separate process, ok [06:12] The migration should complete within one run. [06:12] I believe. [06:13] ffs. another ec2 run failed with no email [06:13] Hm [06:14] Sure you've updated your lp-dev-utils? [06:14] Mine are emailing fine. [06:14] and only an hour in, before any of the new tests would have been run [06:14] wgrant: yes, i landed stuff yesterday ok iirc. and i just updated then and no changes [06:14] Maybe EC2 is being shit. [06:15] yeah :-( [06:15] wallyworld_: The delete() change is now tested. [06:15] wgrant: cool. i just +1'ed it anyway [06:16] Thanks. [06:26] wallyworld_: You probably conflicted with jcsackett's branch [06:27] perhaps. sorting it out now [06:27] I'm just sorting out the beta banner. [06:27] ok, cool. next week will be good [06:28] wallyworld_: I guess that page also wants the privacy banner. [06:28] Unconditionally. [06:29] hmmm. could do. is it really displaying private info though? [06:29] I guess it could be argued either way. [06:29] * wgrant just goes with the beta banner for now. [06:29] +1 [06:29] is anyone running lxc on your laptop/etc? [06:30] no, bare metal for me [06:30] poolie: I run it on my laptop (oneiric) and desktop (precise) [06:30] Only precise's has its own libvirt. [06:30] s/libvirt/dnsmasq/ [06:30] did you see anything like https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/956655 [06:30] But it's working for me. [06:30] <_mup_> Bug #956655: libvirt dnsmasq causes runaway chain reaction < https://launchpad.net/bugs/956655 > [06:30] I'm running libvirt, lxc and system dnsmasqs [06:30] And it's working OK [06:31] ok [06:31] I haven't rebooted in several days, though. [06:31] poolie: Heh [06:31] ? [06:31] poolie: You know what adds that dhclient.conf thing... [06:31] poolie: LP's setuplxc [06:31] oh ffs [06:31] :D [06:31] i should never have run that [06:32] it's so ridiculously intrusive [06:32] worse than rocketfuel-setup [06:32] despite intending to run on the host [06:32] You should run it from an lxc container. [06:32] only inside an existing container? [06:32] ok [06:32] Implied smiley [06:32] dhclient thing? [06:33] poolie: YHBT by stub :) [06:33] $ bzr grep domain-name-servers [06:33] utilities/setuplxc.py: 'prepend domain-name-servers {};\n'.format(lxc_gateway_address)) [06:33] erm wtf [06:33] it modifies your dhclient.conf in a way that sets up an echo loop between various dnsmasqs [06:33] Why would it add that [06:33] wtf is right :) [06:33] for fun [06:33] poolie: file a bug, I think it indicates a missetup host [06:33] against what? [06:34] launchpad for now, which is where the setuplxc script is [06:34] i already filed a bug [06:34] i don't believe setuplxc's serious [06:34] in what way? [06:34] it's full of stuff that does random modifications to the host [06:35] reporting them individually doesn't seem like a good use of time [06:35] the discussion needs to be around splitting it into bits you could safely run on a host you care about [06:35] that should be very conservative [06:35] and things inside the guest, that can do whatever [06:36] sigh [06:36] but, per stub's troll, i don't know if that's even what it's meant for [06:36] is it? [06:36] i gotta go [06:36] ah, sorry if that's too bitter [06:36] i can post to the list [06:36] i thought i already did though [06:37] ok, i mentioned this in https://bugs.launchpad.net/bugs/936817 and you replied, but no one else [06:37] <_mup_> Bug #936817: setuplxc scrambles your bzr whoami < https://launchpad.net/bugs/936817 > [06:38] anyhow, thanks for that wgrant [06:39] poolie: I believe its purpose is to completely setup a Lucid lxc container with a full Launchpad development environment ready to go. [06:39] right [06:39] it's intended to be run on the host? [06:39] I think so, yes (I didn't write it, but I vaguely recall running it once) [06:39] i infer it's only meant to be run on a host you don't care about, like an ec2 vm [06:40] wallyworld: https://code.launchpad.net/~wgrant/launchpad/sharing-beta-banner/+merge/97801 [06:40] ooh. a banner, i like banners [06:41] I ran it on a host I cared about. It seemed to survive. Would have been december or January? [06:41] biab [06:42] wgrant: that's nice infrastructure the bugs team added. i had no idea it would be so easy [06:42] wallyworld_: Yep, it's pretty nice. [06:42] It can also link each feature to a URL, but I don't think we have anything for these yet. [06:42] So meh. [06:43] one thing at a time [06:43] r=me [06:43] poolie: so, I'm sure you'll agree that if it was *just* refactored, and you ran it to setup an lxc container for you (so ran on the host), the existing change to your resolv.conf would be wrong [06:43] poolie: its not particularly useful to reject identifying specific bugs just because the structure could be better [06:44] wallyworld_: Thanks. [06:44] poolie_: so, I'm sure you'll agree that if it was *just* refactored, and you ran it to setup an lxc container for you (so ran on the host), the existing change to your resolv.conf would be wrong [06:44] poolie_: its not particularly useful to reject identifying specific bugs just because the structure could be better [06:44] wallyworld_: It depends on yours, so I'll watch and land it when appropriate. [06:44] poolie_: its meant to be run by random developers as well as on e.g. ec2 [06:45] wgrant: ok. i'm keeping an eye on mine too so i can land if i get to it first [06:45] poolie_: filing bugs is a useful thing to do; suggesting ways to make similar bugs less likely is also good, *but does not replace* identifying existing flaws. [06:45] poolie_: the folk writing it are not unix sysadmins, so they may well make mistakes or oversights, and we should be supporting them in getting a good result [06:45] yes, that's all fine [06:46] i just thought it might be closed invalid 'it's meant to do that' [06:47] LP very rarely does that :) - you may get 'but X happens and we need to address it' as an answer, and if so we can have a discussion [06:47] speaking of bug https://bugs.launchpad.net/launchpad/+bug/936817 you have assigned it to yourself, so I suspect noone has answered because they assume its all under control [06:47] <_mup_> Bug #936817: setuplxc scrambles your bzr whoami < https://launchpad.net/bugs/936817 > [06:48] poolie_: I don't know why these things have been added, I can ask gary, but I suspect something came up and the team took the most direct solution they saw. [06:48] yes, i'm sure that's true [06:49] this happens reasonably often in software dev AFAICT, and its usually 'wast'e [06:49] I'm not sure how to stop it without really negative velocity side effects [06:49] wgrant: found one of the ec2 issues, looks spurious, nothing to do with my changes: test_memory_hog_job [06:49] wallyworld_: That seems to fail on certain days. [06:49] fridays perhaps [06:49] wallyworld_: eg. I had two branches fail with it yesterday, one not. [06:49] One failed today, two did not.; [06:49] lifeless, what i would have liked to have happen is for one of the developers to reply to my original bug to say [06:50] "sorry, it's not meant to mangle your host, please tell us of any other issues" [06:50] It did the same thing a couple of months ago. [06:50] And recovered without anybody doing anything. [06:50] then i would have felt encouraged to do it again [06:50] poolie_: that would have been nice. I guarantee they haven't seen it :) [06:50] oh? [06:50] poolie_: - I failed to tag it for their queue [06:50] cause they're rotated? [06:50] poolie_: and few folk are subscribed to all LP bugs [06:51] :/ [06:51] poolie_: and you triaged it yourself, so noone who is not subscribed had cause to look at it and tag it. [06:51] (all of which is fine, but you can see why they probably hadn't seen it) [06:51] this comes under 'LP is too big, we need to split stuff out' - I've asked that this script move to lp-dev-utils [06:52] ok, i see [06:52] which is a smaller project, and they could reasonably be expected to be subscribed for the project duration, for instance. [06:53] anyhow, my general advice when feeling ignored by a developer of $anything, is to reach out directly and seek help from them :) [06:53] lol [06:53] I just heard a massive THUMP [06:53] cat trying to get out of the lounge [06:55] lifeless, i don't mind being ignored on it, i was just not going to run it until it was more stable [06:55] if the residual damage hadn't caused my whole network to fallover i wouldn't have been thinking about it [06:56] poolie_: anyhow, can you please file a new bug for that other damage, also on LP, and either point me at it, or tag it paralleltests [06:56] erm, paralleltest IIRC [06:56] i retargeted the existing bug [06:57] dnsmasq is perhaps a bit dangerous but i think the proximate cause is setuplxc [06:57] oh, the existing dnsmasq bug ? [06:58] so yeah, thats purely setuplxc doing something inappropriate [06:58] probably the ec2 image is missing dnsmasq [06:58] and so the libvirt dnsmast magic isn't kicking in [06:58] yes bug 956655 [06:58] <_mup_> Bug #956655: libvirt dnsmasq causes runaway chain reaction < https://launchpad.net/bugs/956655 > [06:58] yes, and missing networkmanager [06:58] (or missing a rule for (host) dnsmasq usage. [06:58] so you need a few different things for it to kick off [06:58] thus my question whether it was even intended to be used on laptops [06:58] do you need n-m for libvirt to do its thing ? [06:59] definitely, its concieved as a dev + devops + ops tool [06:59] n-m is starting the host's dnsmasq [06:59] you could have dnsmasq without nm [07:00] wallyworld_: Ah, one thing I missed in the review: you check whether the flag values are None, rather than letting them naturally cast to bool. This makes it impossible to override them to false. [07:00] wallyworld_: You have to have no matches rules at all instead. [07:01] right, so we'll need to tease that all out, the code in setuplxc today is flawed [07:01] wgrant: can't we just delete the flag [07:01] EOW'ing for reals [07:02] wallyworld_: Occasionally we need to disable it just in one exceptional case. [07:02] wallyworld_: eg. to this day we have two rules for dynamic bug listings. [07:02] The main one to enable it globally. [07:02] And a second one to disable it just for one page that doesn't work with it. [07:02] lifeless, thanks, have a great weekend [07:02] and we can only do that if we cast to boolean? [07:03] wallyworld_: It will implicitly do that. [07:03] wallyworld_: The pattern is to just say "if getFeatureFlag('foo'):" [07:03] Rather than "if getFeatureFlag('foo') is not None:" [07:04] ok, will fix [07:05] Thanks. [07:05] Should be pretty trivial :) === wallyworld_ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10 [08:16] wgrant: you can land you beta banner branch now [08:21] wallyworld_: Excellent, thanks. [08:22] np [08:52] Quite irritating now that LP is marking merged MPs diffs as empty [08:53] good morning === almaisan-away is now known as al-maisan [09:46] hey guys, I'm trying to get the info from https://bugs.launchpad.net/glance/+bug/950364/+activity using the launchpadlib but it seems that the content of the activity entries is not available via the API. All I can get is the total number of entries, but the "bug.activity.entries" object is always empty. Any ideas? [09:46] <_mup_> Bug #950364: the owner field in glance is tenant_name < https://launchpad.net/bugs/950364 > [09:48] lcanas: You can't access activity entries anonymously right now. [09:48] Even for public bugs. [09:48] But if you're authenticated at all it will work. [09:49] wgrant, I see, thank you! :D === adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugtasks: 4*10 === al-maisan is now known as almaisan-away [11:45] morning party people [11:46] rick_h: ello [11:54] rick_h: Recovered from pycon? [11:54] nigelb: the process begins...I think it might take a while. [11:54] heh === matsubara-afk is now known as matsubara [12:33] sinzui: Morning. [12:34] I am afraid it is [12:35] heh [12:35] Heh [12:36] sinzui: wallyworld and I landed several branches today which get us into a state where we could sensibly turn on a read-only version +sharing page with fully populated data on Tuesday. [12:36] Does that sound like a reasonable idea? [12:37] oh yeah [12:37] yes it does [12:42] Great. [12:42] It all looks pretty nice. [12:42] And it is nice and fast. === almaisan-away is now known as al-maisan [13:18] Morning, everyone. [13:18] morning [13:23] welcome back, rick_h [13:23] morning [13:23] deryck: thanks, let the shoveling begin!! [13:23] rick_h, a little email there to tend to? :) [13:24] adeuring, deryck, rick_h: hi. [13:24] heh, not just that, but crap to do. 2-factor auth, reviews, etc. You all got busy last week [13:24] 2-factor auth? [13:25] oh right [13:25] I recall now :) [13:25] yea, giant thread on using phone for 2-factor auth stuff [13:25]