[00:00] that would be a good use case for the icon font, being able to make the icon significant (edit) but make the color signify action like link vs popup [00:00] and then keep the color significance with the text to be link vs popup [00:09] hah [00:09] if you change the product that a bugtask is for, the other ajax controls break [00:09] is this a known bug? [00:10] i'll search but usually asking here is faster.. [00:10] probably [00:10] but yea, don't have a number off the top of my head at all [00:12] https://bugs.launchpad.net/launchpad/+bug/919369 [00:12] <_mup_> Bug #919369: acting on a bug task which has been retargeted oopses <404> < https://launchpad.net/bugs/919369 > [00:21] mwhudson: IIRC it's usually not a problem except on multitask bugs, since changing the current context causes a refresh [00:22] wgrant: this was a multitask bug, indeed [00:22] but hm, it was the task i was accessing the bug through that i changed [00:22] should that not still refresh? [00:22] Hmm [00:22] I'd expect that to work [01:00] wgrant: Given your mail, I hope I can avoid a DB trigger. [01:00] But I suspect I have to write some manual SQL to fix up the mistakes. [01:20] StevenK: Correct. [01:21] StevenK: The idea of this is to avoid a DB trigger. [01:21] The fix for bug 1000570 has been deployed, but it hasn't been marked Fix Released AFAICS. Did somebody miss a bug closure pass after an NDT? [01:21] <_mup_> Bug #1000570: "Packageset.score" is badly named

< https://launchpad.net/bugs/1000570 > [01:23] cjwatson: Ah, I left that one because it hasn't been renamed in the DB, and doing so is awkward. Not sure what you want to do. [01:24] Ah, well either way it shouldn't stay as Fix Committed. I'm not planning on doing anything more to it for the time being, largely because I have no idea how to do so smoothly. [01:24] Maybe -> Triaged/Low/unassigned. [01:24] That would be my suggestion. [01:24] I'll do that then. [01:24] We haven't done a straight column rename since fastdowntime. [01:25] But I'd probably do it as a two-day trigger [01:25] Oh, I can't set Triaged. [01:25] Doing [01:26] ta [01:28] Bah. Dealing with both private and information_type *and* the creation rules in IBranchNamespace.createBranch() is giving me a headache. [01:28] (In LaunchpadObjectFactory.makeBranch()) [01:29] StevenK: Both default to None. At most one can be not None. [01:32] Oh, bah, it doesn't help that I overwrite the values during the course of the method. [01:34] Right, that should fix it. [01:51] wgrant: Can you glance over https://code.launchpad.net/~stevenk/launchpad/branch-use-information_type/+merge/106109 again? [01:53] StevenK: Looking [02:11] StevenK: Can't the factory just use transitionToInformationType? [02:11] wgrant: Nope [02:11] It can [02:12] Why do you say it can't? [02:13] 120 + if (self.stacked_on and self.stacked_on.information_type != [02:13] 121 + InformationType.PUBLIC and information_type != [02:13] 122 + self.stacked_on.information_type): [02:13] 123 + raise BranchCannotChangeInformationType() [02:13] That's wrong [02:13] The indentation is still criminal [02:13] And it doesn't implement the rules we defined this morning [02:13] s/indentation/line-breaking/ [02:14] 156 + # If the branch we are stacking on is not public, and we are, [02:14] 157 + # set our information_type to the stacked on's. [02:14] 158 + if (self.stacked_on and self.stacked_on.information_type != [02:14] 159 + InformationType.PUBLIC and self.information_type == [02:14] 160 + InformationType.PUBLIC): [02:15] Should use PUBLIC_INFORMATION_TYPES [02:17] wgrant: In terms of lines 120-123, the information_type can change, as long as it remains in PRIVATE_INFORMATION_TYPES ? [02:18] StevenK: I think so. [02:18] The only constraint we have now is that a newly created branch probably shouldn't be public if it's stacked on something private. [02:18] Implementing the same rule on stacking changes is roughly free, so we should do that too. [02:19] wgrant: That's lines 156-160 in branchChanged [02:19] Right, just explaining that that's the full ruleset :) [02:22] wgrant: Are those your two issues? [02:23] StevenK: Mostly. Will give it another deep look-over when they're fixed. [02:23] lifeless: https://lpstats.canonical.com/graphs/PPR/20110123/20120524/ <- can I delete rosetta? [02:23] wgrant: I have them fixed locally, I'm just wondering if I have tests for the stacked on behaviour in transitionToInformationType [02:24] wgrant: I undesrstand the temptation [02:49] the quality of commit messages these days is awful :( [02:50] I did like the "use a private fork of bzr" this morning [02:50] no kidding [02:51] * bigjools composes email to list [03:24] bigjools: got time for a brief call about your favourite launchpad component ? [03:51] lifeless: can do 5 mins now or more later [03:52] wgrant: And again? [03:53] Hmmm, that's an annoying bug. [03:53] bigjools: now is good [03:53] bigjools: skype? hangout ? [03:54] If you leave the media menu open and go to lunch, you can interact with the menu, but as soon as you close it, the screen locks. [03:55] StevenK: The factory is still insane. [03:55] StevenK: And it might break lots of text by already having a change event [03:55] wgrant: How so? [03:55] tests [03:55] not text [03:55] StevenK: Why doesn't it use transitionToInforationType? [03:56] With proper spelling. [03:56] wgrant: Because transitionToInformationType has a bunch of rules about when privacy/information_type can change, and some branches want to be created that break those rules. [03:57] StevenK: No they don't. [03:58] StevenK: If they really need to (eg. for testing that it's possible to fix that situation), I'd set the information_type manually in the test. [03:58] I don't think it's valuable to let the factory knowingly create invalid data. [03:59] wgrant: http://pastebin.ubuntu.com/1002332/ [03:59] (because that means tests might unknowingly do it) [04:00] StevenK: Ah, I see. So there's no privacy policy? [04:00] I wouldn't expect there to be too much fallout from that, and it's one line to fix each test. [04:02] wgrant: It is? [04:03] Create an appropriate BranchVisibilityPolicy [04:05] wgrant: And the project doesn't exist until inside makeBranch() [04:07] StevenK: Ah, that's less than convenient. [04:11] wgrant: So I need to create a project, a team and a BranchVisibilityPolicy and then I can create a private branch just so makeBranch() can use transitionToInformationType? [04:21] StevenK: Technically, yes, you should. [04:21] StevenK: But perhaps that's not ideal here yet. [04:23] wgrant: There are 246 occurances of private=True in the tree -- some of those are going to be for makeArchive(), but ... ouch? [04:23] lib/lp/soyuz/tests/test_binarypackagebuildbehavior.py: UPDATE archive SET private=True,buildd_secret='foo' [04:23] * StevenK facepalms [04:25] wgrant: is there a trigger which updates btf.access_policies and btf.access_grants when a bug info type or bugtask target changes? if there is, i have missed finding it [04:26] z_bug_maintain_bugtaskflat_trigger AFTER UPDATE ON bug FOR EACH ROW EXECUTE PROCEDURE bug_maintain_bugtaskflat_trig() [04:26] z_bugtask_maintain_bugtaskflat_trigger AFTER INSERT OR DELETE OR UPDATE ON bugtask FOR EACH ROW EXECUTE PROCEDURE bugtask_maintain_bugtaskflat_trig() [04:26] wallyworld_: ^^ [04:26] (z because they have to happen after the FTI updates etc :/) [04:26] wgrant: So, shall I leave the information_type = call in the factory? [04:26] wgrant: ok, thanks. something else is going wrong for me then. [04:27] StevenK: I suppose. [04:27] wgrant: Do you have any other issues with the MP? [04:44] Well thats amusing. Package builds fine under i386, not amd64 [04:44] stub: Possibly because i386 builds arch-indep, amd64 doesn't. [04:44] If it's not an obvious arch difference. [04:45] https://launchpadlibrarian.net/105848284/buildlog_ubuntu-lucid-amd64.postgresql-9.1_9.1.3-2%2Blp4_FAILEDTOBUILD.txt.gz ? [04:45] Yeah [04:45] arch-indep difference [04:45] i386 will be building doc packages, amd64 won't [04:45] But both copy them into debian/tmp [04:46] StevenK: Your linebreaking is still a criminal offence. [04:46] 121 + if (self.stacked_on and self.stacked_on.information_type in [04:46] 122 + PRIVATE_INFORMATION_TYPES and information_type in [04:46] 123 + PUBLIC_INFORMATION_TYPES): [04:46] wgrant: When can I expect you over to arrest me? [04:47] wgrant: What would you prefer, nested ifs? :-) [04:51] StevenK: Replied [04:55] wgrant: http://pastebin.ubuntu.com/1002355/ [04:56] StevenK: I accept your plea bargain. [04:56] Haha [04:56] wgrant: And the linebreak for name='branch_%s' % x, private=x > 2) is still required. [04:56] Really? it didn't look that long. [04:57] How far over is it? [04:58] wgrant: 81 [04:58] StevenK: s/branch_/b/g [04:58] Done [04:58] branch = self.factory.makeBranch(name='branch_' + x, private=x>2) [04:59] I mean, naming a branch "branch_foo" doesn't really make sense anyway. [05:01] The branches do not require names, we don't test for them. [05:01] Even better [05:01] Remove stupid piece of test, save a line. [05:01] Everybody wins. [05:01] One less crime. [05:01] wgrant: -4/+2 [05:06] steven@undermined:~/launchpad/lp-branches/branch-use-information_type% bzr log | head -n 7 | tail -n 1 [05:06] Drop some useless names from a test, and fix my crimes against humanity. [05:06] wgrant: ^ [05:06] They were merely capital offences, not crimes against humanity. [05:08] which capital? [05:08] lifeless: So, looks like I need some manual SQL. :-( [05:09] LATER [05:09] Not until this is deployed everywhere [05:09] But won't that leak some branches? [05:10] Don't you still respect transitively_private? [05:10] Only information_type in the New World Order. [05:10] Oh [05:10] Indeed you don't [05:10] In fact, I don't think Branch._private is even needed [05:11] There's only like a dozen branches that are affected, right? [05:11] 29 [05:12] Any created recently? [05:13] Normally you'd do a 3-stage migration here, but they may be rare enough that you can get away with 2-stage with manual SQL. [05:21] wgrant: I'm going to kill Branch._private, it isn't needed because the two columns are named differently. [05:26] StevenK: Sounds reasonable. [05:33] * wgrant fixes cjwatson's test failurse [05:49] 9.1 right ? [05:49] 559 / 222 Distribution:+ppas [05:49] 348 / 37 Builder:+history [05:50] lifeless: Yes [05:53] Builder:+history has a bug filed against it, at least. [05:54] I believe Distribution:+ppas is similar misbehaviour on a different query, but I haven't looked in depth. [05:55] Both rarely used pages, anyway. [05:55] Particularly since Distribution:+ppas timed out half the time anyway [06:10] wgrant: i have a question i'd like to ask if you have a moment. a bit of code which calls bug.subscribe() appears to mess with bug visibility checks. i have a bit of code in https://pastebin.canonical.com/66554/ to try and illustrate the issue [06:11] wallyworld_: Looking [06:11] thanks. hope it makes sense [06:21] wallyworld_: What's policy_team_grantee? [06:21] wgrant: typo, sorry [06:21] should be policy_gantee [06:21] argh, you know what i mean [06:22] Haha [06:22] can't type [06:22] i cut and pasted a bit of code from a test and stripped out bits [06:22] wallyworld_ is obviously so excited by the prospect of a NSW win tonight that his hands are shaking. [06:22] StevenK: you can go and f%^@@!%^%^@ yourself [06:22] blasphemy [06:23] * wallyworld_ just hope to make it home from soccer training on time not to miss any [06:23] wallyworld_: You haven't disabled the triggers? [06:23] wgrant: no. i had. but there were other issues [06:23] wallyworld_: We have this thing, called a PVR. It can pause live TV. [06:23] wallyworld_: Toggling the information_type on line 40 without disabling the triggers will cause the grant to be recreated due to the subscription. [06:23] StevenK: but others will be watching [06:24] it's rugby *league*, who TF watches that crap [06:24] What's the difference? [06:24] Bwaha [06:24] wgrant: ah, bollocks. thanks for spotting that. i'll disable the triggers again and see if i can reproduce the issue that caused me to disable them [06:24] bigjools: wallyworld_ will be *glued* to the TV. [06:25] bigjools: it's state of origin. better than any super 16 or 6 nations stuff [06:25] you can tell yourself that, yeah :) [06:25] Who cares? Both rugby league and union are played by and watched by bogans. [06:25] bigjools: it's a lot tougher. i mean what sort of rugger pussy disallows a shoulder charge [06:26] wallyworld_: league is the one where after they get tackled they hump the ball for a bit right? [06:26] StevenK: i don't consider myself a bogan [06:26] wallyworld_: The thing to remember about the triggers is that they were designed to always keep the mirror in a sane state, regardless of whether it was sane to start with. Every time they're fired, they force any AAGs and APAs to match the legacy disclosure data. [06:26] bigjools: only in your dreams [06:26] wallyworld_: I couldn't just apply a delta, since the table started empty. [06:27] wgrant: ok. i'll try and get this particular test case to work with the legacy triggers disabled from the start. the sharing jobs in question are not really meant to be run with the triggers on [06:28] i ran into issues but can't recall what they are right now [06:29] I'm happy to help if you hit trouble. [06:29] no problem, thanks [06:30] Is there some magic to dput to get packages build for multiple releases since I can't use the web UI to rebuild packages for a different release in the same PPA? [06:30] wgrant: i'll send out an email maybe tonight to summarise where we are at with being able to turn off the legacy triggers. i think we will be close after i get this branch sorted. we'll have code to grant access on subscribe and also unsubscribe if access becomes verboten [06:31] stub: you need >1 upload [06:31] unless you want to copy the same build [06:31] Recipes let me do it I guess. [06:31] yep [06:32] wallyworld_: Marvellous. [06:33] stub: Right, recipes are handy for that. Or you can often build in lucid and copy up, as long as a soname bump hasn't happened. [06:33] wgrant: main outstanding bit will be some form of garbo / celerybeats / cron job to check for inconsistencies if we feel that's necessary [06:45] wgrant: one issue - without the legacy triggers, self.factory.makeAccessPolicyGrant does not allow the bug to be visible [06:46] wallyworld_: You probably want to disable bug_mirror_legacy_access_t, bugtask_mirror_legacy_access_t, bugsubscription_mirror_legacy_access_t [06:47] wallyworld_: You still want things mirrored to bugtaskflat, you just don't want the legacy sharing schema mirrored to the new one. [06:47] wgrant: those ones are the only 3 i am disabling [06:47] using a new fixture i wrote [06:48] wallyworld_: Are you creating the APA manually? [06:48] Disabling those triggers will prevent APAs from happening automatically [06:48] no [06:48] So the APG will not be effective for the bug. [06:48] Because it's not linked to any policies. [06:48] wgrant: i would have hoped that APA will be done by triggers still [06:49] wallyworld_: It's all done by the one trigger right now, unfortunately. [06:49] :-( so we need to do a new trigger [06:49] and strip out the APA stuff [06:49] from the legacy trggers [06:49] AAG stuff [06:49] Well [06:49] Split them up [06:50] Or we can find all the stuff that creates tasks, all the stuff that changes targets, and all the stuff that changes information types [06:50] ok, i'll do it bt hand for now and include an xxx [06:50] And make them create the APAs in the application. [06:50] That's the ideal situation, and it might be doable now [06:50] Since those things are reasonably well factored nowadays. [06:50] hmm. ok. this branch is already waaay to big. might do it in the test for now and do a new branch to do it in the model [06:50] Target setting is guarded, task creation is mostly factored into a single method, and information type transitioning is done by a single method. [06:51] It'll certainly need to be a separate branch or three. [06:51] * wallyworld_ off to soccer and then straight home to watch the might maroons thrash nsw [06:52] Heh [06:52] Is that where bigjools heard the odd pronunciation? [06:52] odd? it's pronounced "marown" [06:52] Odd to him. [06:53] you're all wrong [07:41] good mmorning [07:47] wgrant: Doh. Thanks [07:47] hate doctests [07:52] That's the point :) [08:01] Confused at how that passed EC2. === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban* (rvba) | Firefighting: - | Critical bugs: 3.47*10^2 === almaisan-away is now known as al-maisan [08:17] Could somebody set https://code.launchpad.net/~cjwatson/launchpad/remove-distro-parts/+merge/106920 to Status: Approved (since it's had an Approve review) so I can land it? [08:20] cjwatson: done [08:21] Thanks === dpm__ is now known as dpm [11:07] wgrant: around? [11:08] wallyworld_: Sure [11:09] wgrant: 1/2 watching footy so may no be seeing it, but see https://pastebin.canonical.com/66571/ - #4 is not as i expect [11:09] wgrant: triggers disabled [11:10] wallyworld_: Recall that the triggers are disabled, so changing bug.information_type isn't going to change the APA [11:10] wgrant: only the legacy triggers are disabked [11:10] Right, and they maintain APA [11:10] wgrant: i thought there were separate trigers for info tpy changes [11:10] That's why you had to create it manually [11:11] No. Bug* -> Access* is all the legacy triggers [11:11] hmmm. [11:11] * wallyworld_ sad [11:11] i think i will need to create a db-devel branch to fix that [11:11] I can reimplement all that in the app tomorrow if you want [11:11] before i land this branch [11:11] The APA stuff [11:11] Why do you need a db-devel branch? [11:11] yes, we really do need that now [11:12] db-devel to add the triggers [11:12] We can't remove the triggers until after the appserver code is deployed. [11:12] can't we split out the APA stuff [11:12] still have the legacy triggers but have the APA stuff on its own [11:12] since we will need it even when legacy triggers are gone [11:13] oh, you want to do it in the app [11:13] Yeah [11:13] It's become a little less of a free-for-all in the last few months [11:13] So it's easy enough to do there now [11:13] whatever works :-) [11:14] i really don't want to "pollute" the tests with the APA stuff [11:14] Since we're going to be managing grants from the app, we might as well manage the APAs too [11:14] yeah. the calling code should be easy to write. at the moment it isn't :-) [11:14] well, not intuitive or transparent perhaps [11:15] The task creation code is all now nicely centralised, same with information_type, and I refactored target setting, so there's basically just 3 methods that need hacking [11:15] wgrant: we would need to use the legacy triggers removed feature flag [11:15] so the triggers and app code don't double up [11:16] oh, i haven't landed that flag yet [11:16] sigh [11:16] wallyworld_: They can't double up. [11:16] They're idempotent. === danilos_ is now known as danilos [11:17] wgrant: i've been getting pk errors if i don't diable the triggers and have app code to do the same thing [11:18] wallyworld_: The triggers won't recreate stuff that already exists. [11:18] So the appserver code will just check what's there, and fix it if it's wrong. [11:18] Same as the triggers. [11:18] wgrant: yes but they fire first [11:18] and my app code didn;t check, just assumed the stuff needed creating [11:19] anyways, footy is back on :-) [11:19] Right. My centralised app code will render that no longer necessary, and will do the check. [11:19] Heh, k [11:19] Thanks for sorting all this stuff out! [11:20] np. i'll code my branch and it tests will fail and i'll merge devel when your stuff is in and tests will work [11:20] Yeah [11:20] I'll also grep for any makeAccessPolicyArtifact calls that are lying around [11:20] And delete them. [11:21] awesome [11:21] it's all quite verbose atm [11:21] Yeah [11:21] The transition phase wasn't meant to last quite as long as it has :) [11:21] Still, its end is nigh [11:21] yep, can't wait [11:22] and we nweed to do branches [11:23] Branches are easy :) [11:23] As of 12 hours ago... [11:23] i have a few XXXs in tests etc [11:23] waiting for it to be sorted [11:23] Great [11:24] so we need the same app code as we just discussd for bugs [11:24] Branch code will be entirely app. In fact, we'll lost the transitively_private trigger shortly. [11:24] But yeah [11:25] StevenK is basically cleaning up the points we'll need to hook into [11:25] cool [12:34] hmm, quantal and lxc don't seem to be an ideal combination here at the moment [12:36] jelmer: Oh? [12:36] What's breaking? [12:37] kernel panic :) [12:37] Oh [12:37] That's quite impressive. [12:37] 3.4? [12:37] yep [12:37] this is the second time it's happened to me, next time I'll take a photo [12:38] ...you mean you don't have a serial cable hooked up? [12:38] I'm disappointed in you jelmer. [12:39] hehe [12:40] mgz: Did you get your LP instance working? [12:41] wgrant: yup, and forwarded via socks over chinstrap to the browser here [12:41] one oddness was the new bugs page wasn't in, so maybe I didn't have it setup the same way the current live version is? [12:42] are there more things I managed to ignore on the wiki about setting flags or similar? [12:42] mgz: you probably have to be in one of the special groups for that? [12:42] I thought new bugs were on for everyone now? [12:43] I thought it was still behind a feature flag [12:43] otherwise, how do you make the stub test data gain the feature flags you care about? [12:43] mgz: You add it? http://launchpad.dev/+feature-rules [12:43] StevenK: thanks :) [12:44] It's still behind a feature flag, despite being enabled everywhere for nearly 6 months [12:44] The old code was never removed. [12:44] are there other features that are enabled live but still not on by default for the test setup? [12:44] mgz: Sounds like a good learning exercise. ^ :-) [12:44] or is the bug listing stuff unusual... [12:45] mgz: Some feature flags are supposed to be short lived [12:45] I'm hoping that disclosure.show_information_type_in_ui gets ripped out next week, for instance. [12:46] is there somewhere that tells me what launchpad beta testers have turned on? [12:46] You can have a look at the feature rules on prod [12:48] I can, or I can tell some poor l-osa to? [12:56] Morning, all. [12:56] mgz: You can see them, you just can't edit. [13:00] StevenK: is there some documentation you can point me at? things involving 'prod' I'm nervous prodding without knowing what I'm doing. [13:00] am not even aware of which boxes are involved with the live launchpad setup for example. [13:07] mgz: You can't change anything there, so there is no harm in looking. [13:07] mgz: There is some doco around of the LP producution setup including a diagram. I can't recall where off the top of my head [13:11] mgz: are you looking for the URL? https://launchpad.net/+feature-rules [13:12] ah, doh, I assumed that'd be a dev setup only thing [13:13] and the changelog is very informative. [13:13] It's restricted to ~admins and ~registry [13:14] Mortals like myself just get 403 :) [13:14] :) [13:14] cjwatson: ah thought you were a demi god myself [13:14] just in all other regards czajkowski :) [13:14] Only for stuff under /ubuntu :) [13:15] cjwatson: ahhh :) [13:19] I can't find my recipe [13:20] ahh... wrong branch [13:35] mgz: how would you travel from the UK to NL, I'm trying to decide if Eindhoven or Utrecht is a better meeting point. Ein has a direct Stansted <=> Ein flight, but Utrecht is a more central train station. [13:39] jam: norwich 'international' airport has a hop to schiphol [13:40] stanstead isn't too hard to get to either [13:40] there used to be a ferry from these parts too, but I think no longer [13:41] mgz: could you do a quick check on pricing, including train/taxi/whatever for the two routes? [13:41] sure [13:41] Stansted is way easier to get to than Norwich from just about anywhere except Norwich [13:42] Though I know the latter's probably more important to mgz :) [13:42] cjwatson: yeah [13:43] I was surprised how many people in directory.canonical.com are listed as in Norwich, though. (4) [13:44] and amigadave is also norfolk [13:44] we're doing pretty purple round here. [13:46] so, NOR-AMS return is £120-150 range, then need train on the dutch side which you might have a better idea on [13:47] heh, first web search hit is the dutch train operator, second in bbc news article about crash in april [13:48] looks like about 8 euros one way to utrecht from schiphol, so not expensive === al-maisan is now known as almaisan-away [13:53] from stansted I'm failing to find flights to eindhoven at all, but to schiphol it's £110 upwards [13:54] mgz: aren't you near Harwich? How long does the boat take? [13:54] to get the train to eindhoven goes through utrecht, costs about another 10 euros [13:55] jelmer: however long it takes me to hide in a container ship without being noticed? :) [13:56] mgz: hehe [13:56]