=== cinerama_ is now known as cinerama === jtv1 is now known as jtv [02:26] wgrant: https://code.launchpad.net/~stevenk/launchpad/branch-use-information_type-redux/+merge/107150 [02:41] Resurrect branch-use-information_type and fix all of the test failures. [02:41] StevenK: Do you have a diff of just the last part? [02:43] Hm, I could possibly construct one [02:45] StevenK: Also, in branchChanged and the child bit of transitionToInformationType you're setting information_type directly. [02:46] wgrant: http://pastebin.ubuntu.com/1004087/ [02:47] Version control systems are very good at this if you commit regularly :) [02:48] Shhh [02:56] wgrant: I don't like the idea of recursing into transitionToInformationType from transitionToInformationType. [02:57] StevenK: In fact, I don't like the idea of recursion at all [02:57] Drop it [02:57] The use cases are very few. [02:57] information_type is now only inherited to the branch that's doing the restacking. [02:57] Changing information_type no longer propagates. [02:58] The number of potential writes is unbounded, and I can't see why anybody would really want it. [02:58] We saw this morning that all the transitively_private cases are cases where people have project misconfigurations that will soon no longer be possible [02:59] And +sharing will soon say "You have 10 private branches, fool" [02:59] s/private/public [02:59] In the very rare case that it might happen. [02:59] I don't see how it will happen, though. [03:00] StevenK: So, drop the child code, and any tests that require it. [03:01] StevenK: Still, the branchChanged information_type setting thing needs to be transitionToInformationType [03:02] StevenK: This probably means adding a flag to transitionToInformationType that says "I actually know what I'm doing and really want this to happen; don't bother checking if the policies allow this branch to be private" [03:04] wgrant: Right -- I don't mind that idea, a strict_checking=True argument to transitionToInformationType. [03:06] I was thinking i_promise_i_know_what_i_am_doing, but that works too [03:11] wgrant: For a further win, I think that means the factory can use transitionToInformationType as well [03:12] StevenK: That would indeed be the case. [03:12] But I will worry about that after lunch. [03:12] Sounds like a plan. [03:37] r15291 \o/ [03:41] Indeed [03:50] wgrant: StevenK: it seems to me that FileBugInlineFormView is defined and used in some tests but is not hooked up anywhere and so is never used. am i right? [03:51] wallyworld_: That seems to be correct. [03:51] wgrant: well, i'm going to delete it then i think [03:51] Probably back from the days when it was more AJAXy [03:51] Indeed [03:51] Kill [03:52] Note that some of the tests may be the only tests of the base class' functionality. [03:52] * wallyworld_ gets out the BFG 9000 [03:52] That may be why it was kept. [03:52] hmmm. perhaps. will look at that [04:01] wgrant: http://pastebin.ubuntu.com/1004143/ [04:02] StevenK: Maybe s/strict_checking/verify_policy/, since that seems to be the only check that needs skipping [04:02] You can then reword the factory like this: [04:02] if private is not None: [04:02] information_type = blah [04:02] if information_type is not None: [04:03] tTIT [04:03] Rather than the nesting you have now [04:07] wgrant: http://pastebin.ubuntu.com/1004148/ [04:09] StevenK: "Check if the new information type complies with the `IBranchNamespacePolicy`." [04:09] parens on line 42 are redundant. [04:10] wgrant: If True, check if ... or just what you have? [04:10] I think just what I have, but it's subjective. [04:10] On line 64 the flag should be named explicitly to avoid people copying the code badly. [04:11] Same with 127 [04:11] Otherwise fine. [04:11] As long as information_type isn't set manually anywhere else. [04:12] wgrant: A bunch of tests do it [04:12] They are evil, but don't really count. [04:13] They can't break anything [04:14] wgrant: http://pastebin.ubuntu.com/1004155/ [04:14] Hm [04:15] Buildbot passed less than 5:40 after you reverted your branch [04:15] Suspicious [04:15] Elapsed5 hrs, 37 mins, 26 secs [04:15] It was marked testfix, buildbot won't wait for those [04:15] Even so, builds have been taking more than 6 hours lately [04:15] I guess we have had some optimisations in the last couple of days. [04:16] test 16776 tests 16776 passed [04:16] So it's correct. [04:16] (well, there's potentially 300 missing, but I don't know quite how buildbot counts) [04:17] That buildbot pass should fix up the db-stable deployment report too [04:17] Not until it's on prod, IIRC [04:17] But I don't quite remember. [04:18] wgrant: Anyway, you seem fairly happy with this branch, shall I commit and push? [04:19] StevenK: Indeed, and I shall go over it with my Fine-Toothed Comb of Pedantry again. [04:20] Total LoC delta for William Grant: -740. Churn: 25890 [04:20] Yay [04:21] wgrant: ohlo ? [04:21] cjwatson's thing [04:21] oh, I haven't seen that [04:21] linky ? [04:21] It's in lp-dev-utils now [04:21] Apparently [04:21] I should pull that :P [04:22] did he send mail about it ? [04:22] It counts from the introduction of the new policy by default [04:22] He didn't [04:22] It was discussed only on IRC and in the MP AFAIK [04:23] ah [04:23] perhaps I don't get lp-dev-utils MPs [04:23] wgrant: How do you get the churn? [04:24] StevenK: I used the vim option [04:24] Hah [04:25] wgrant: MP diff updated [04:39] wgrant: How goes the combing? [04:40] StevenK: Sorry, got distracted [04:40] Looking [04:41] wallyworld_: In your sharing jobs MP, I think you left the old sharing_jobs.error_dir config key there [04:41] You deleted the section header, but not the error_dir key [04:42] wallyworld_: It's raining in Sydney today -- you may think of it as the tears of NSW supporters if you wish. [04:46] wgrant: Stop getting distracted! [04:59] StevenK: Looks reasonable. [04:59] wgrant: Toss it at ec2? [05:02] StevenK: I'd test rather than land, given what happened before, but yes. [05:02] Haha [05:02] Trust our test suite much? [05:03] Test suite, sure [05:03] Testrunner... nope [05:47] StevenK: did you even watch the game? [05:48] wallyworld_: Nope [05:48] heathn [05:48] wgrant: you sure i left that error dir key in there? the mp diff says it's gone [05:49] wallyworld_: Why would I want to watch thugby? [05:49] wallyworld_: You removed the setting, not the schema key. [05:49] why not? it's a great game [05:49] 154 -dbuser: sharing-jobs [05:49] 155 - [05:49] 156 # See [error_reports]. [05:49] 157 error_dir: none [05:51] ah ok. tests still run. but will remove, thanks [06:31] wallyworld_: How're you intending to land this series? [06:31] wallyworld_: It seems like the early bits could be landed now. [06:31] Rather than doing it all in a 10000 line diff [06:31] i rather do the whole lot [06:31] That's a really good way to ensure that bugs slip through. [06:31] But we'll see :) [06:32] the functionality is all very narrowly focused [06:32] Well [06:32] There are things there like magically making the (API-visible?) sharing service writable when the moment the triggers are disabled. [06:33] that can happen after the landing and we have seen that everything is ok for a bit [06:33] I mean it's not a sensible thing to happen ever. [06:33] How do those things follow? [06:34] hmm? [06:35] I don't understand the logic around "triggers are disabled, so it's OK for everyone to write to grants whenever they want" [06:35] i don't think those are connected wither [06:36] https://code.launchpad.net/~wallyworld/launchpad/subscribe-grants-access-1000045/+merge/106278 line 182 [06:36] triggers disabled = turn on ff to manually keep subscriptions in line with access [06:37] sorry, what's your point? [06:37] we are replacing trigger code with model code [06:37] The sharing service magically becomes writable when the triggers are disabled [06:37] Rather than when writing is enabled. [06:37] This sharing service is callable over the API [06:37] only indirectly [06:39] the sharing service needs to be able to write to do the job the triggers used to do [06:48] The diff's ~6000 lines, and has a number of changes that I don't really understand, and dozens of conflicts that I can see. It's going to be very difficult to land it as a whole in any sensible fashion. [06:57] each individual piece has tests which need to pass [06:58] it's not really that complicated - the end result is two jobs which clean up subscriptions for inaccessible bugs, and optional code to grant access when someone is subscribed [06:58] And turning that on implicitly turns on APGs, because it makes the sharing service writable. [06:58] And other side-effects that I haven't noticed yet. [06:59] so what's wrong with turning on APGs? [06:59] branch-use-information_type-redux => devel [FAILED] (up for 1:53:05) i-37557451 [06:59] :-( [06:59] They're a great way to spy. [06:59] Because they're not shown on the bug page yet. [06:59] At least I know its marked as failed correctly ... [06:59] they are shown on the +sharing page [06:59] and it's not a side effect if the behaviour is intended [07:00] The behaviour is not intended./ [07:00] to me it is [07:00] And +sharing is not accessible to many people. [07:00] we are not allowed to change the bug ui [07:00] that was agreed to afaiui [07:01] so we cannot show apg on the bug page [07:01] Anybody who agreed to not showing APGs on the bug UI was silly and shall be overridden [07:01] who made you god? [07:01] We *cannot not show them* [07:01] That would make bug access entirely opaque. [07:01] it was agreed to by the product team and curtis i think but i could be wrong [07:01] It may have been agreed that we wouldn't need to show AAGs, because they require a subscription. [07:02] That is perhaps a reasonable position to take, but there is some dissent. [07:02] Not showing APGs is entirely unreasonable. [07:02] do they have to be shown on the bug page? what about the pillar page? [07:03] They should probably be on some publicly visible page on the pillar somewhere. [07:03] But it's essential that the bug page not make it impossible to see who has access. [07:03] that's what i thought we were going to do [07:08] good morning [07:12] stub: hi [07:12] stub: catchup ? [07:19] lifeless: sure. [07:21] stub: skype ? [07:22] stub: why you no answer :P [07:23] sorry - downstairs stealing my mike back [07:23] ah :) [07:24] better? [07:24] adjusting [07:29] stub: epic issues? [07:43] I was hearing you fine [07:43] I can hear you [07:48] dropped out [07:49] moin === danilo_ is now known as danilos === almaisan-away is now known as al-maisan [08:14] frankban, hi, it seems my branch hasn't landed even though it passed all the tests; perhaps pqm acting weird or something? [08:15] yes danilos :-( it should be fixed now, restarted the full land for your branch [08:18] frankban, ack, thanks (though, you can also do a direct pqm-submit when you don't want to wait for the full cycle: not a hurry with this one :) [08:19] yes I know danilos, but since it was a testrunner bug, i just wanted to try the whole process again [08:20] frankban, ok, sure thing, sorry for being annoying then :) [08:21] danilos: you are not annoying, I always appreciate suggestions on processes :-) [08:34] frankban: You can just search for tracebacks in the subunit output to confirm a good run [08:34] frankban: It still ran all the tests. [08:37] wgrant: you are right, thanks [08:38] If it was a good run you should see the full 17000ish count in the ec2 mail. [08:38] Without even going into the subunit stream. [08:38] AFAIK it's only on error that the stream gets corrupted. [08:45] jam: jelmer vila could someone have a look at https://bugs.launchpad.net/launchpad/+bug/1003576 [08:45] <_mup_> Bug #1003576: Automatic translation exports not committing PO files < https://launchpad.net/bugs/1003576 > [08:45] looking [08:45] jam: thanks [08:45] dpm ^^^^ [08:45] I'm guessing this is the "translations for Q are fairly stalled right now". [08:45] It's probably unrelated. [08:45] But jtv would know [08:46] ? [08:46] hi jam, this is about translations for projects not being committed, rather than translations for the distro [08:52] dpm, czajkowski, so at this point, I don't really know how to dig into this further without just agreeing that it is a critical issue (user impacting), and it should go into the queue of ThingsThatShouldBeFixed [08:53] jtv: hola there seems to be a possible regression bug https://bugs.launchpad.net/launchpad/+bug/1003576 [08:53] <_mup_> Bug #1003576: Automatic translation exports not committing PO files < https://launchpad.net/bugs/1003576 > [08:58] czajkowski: I'm looking into it — my guess is it's probably just transient problems or old locks sticking around. [08:58] Ah [08:58] jtv: cheers [08:58] You know what [08:58] I haven't had export cronspam for days [08:58] I wonder if it was never reenabled after the attempted initialisation earlier in the week [08:59] I bet they reenabled stuff on ackee/loganberry, but not crowberry [08:59] * wgrant checks. [08:59] Yeah' [08:59] gnuoy: Hi [08:59] wgrant, hi [09:00] gnuoy: translations-export-to-branch.py is still disabled on codehost@crowberry due to RT#52815. The other disabled jobs were reenabled a couple of days ago, but that one was apparently forgotten. [09:00] <_mup_> Bug #52815: logitech usb headset sound output dies after 1 minute < https://launchpad.net/bugs/52815 > [09:00] Could you uncomment it, please? [09:00] czajkowski: mystery solved. :) [09:00] ok course [09:00] s/ok/of/ [09:01] I shall also prepare an appropriate script-monitor invocation [09:01] As it appears to lack one. [09:01] wgrant, done [09:01] jtv: magic :) [09:02] gnuoy: Thanks. [09:02] jtv: cheers [09:02] No point running it manually now -- it may well take more than an hour and get killed. [09:02] dpm: yer sorted :) [09:02] But we could do a manual run in an hour if dpm thinks it's urgent. [09:02] wgrant: if this script is not run for too long, it may lose updates. [09:03] It will automatically run in a little under 20 hours [09:03] It has not run in 4 days [09:03] Enough to lose a day's worth of data. [09:03] If it hasn't run in 4 days, then it may have lost 2 or 3 days' worth of data. Adding a day is not good. [09:04] wgrant, I agree with jtv, if possible, it'd be good to have a one-off run asap in addition to the next run in 20 hours [09:04] Surely it uses a last update time, not hardcoding 24 hours which will never work? [09:04] Not 24 hours, but way back when it did hard-code some fixed time period. [09:04] * wgrant checks. [09:05] """Get date of last translations commit to `branch`, if any.""" [09:05] That looks encouraging [09:06] Yeah, should be fine [09:06] it uses the last translations commit - a fudge factior [09:06] Otherwise I would have had to append the exporter to my list of things that really aren't very good ideas :) [09:09] gnuoy: I propose https://pastebin.canonical.com/66679/ [09:09] wgrant, seconded [09:11] wgrant, done [09:12] gnuoy: Marvellous, thanks. [09:12] np [09:12] dpm: The export script somehow missed out on our usual monitoring; that has now been rectified. [09:13] thanks a lot for your help wgrant, great to hear it's sorted now [09:13] and thanks czajkowski [09:13] and gnuoy :) [09:13] We'll do a manual run right after fastdowntime. [09:13] when's fastdowntime? [09:13] 47 minutes from now [09:13] 10am UTC every day [09:13] cool [09:13] It normally takes about 25 minutes, I think, but it's got 4 days of stuff to do [09:14] "It" being translations-export-to-branch [09:14] fastdowntime will hopefully take about 67 seconds. [09:15] jtv, did your changes to fix translator credits and other stuff in Translations you were telling me the other day land? [09:24] hi could someone give some guidance to the guy willing to help fixing bug 869824? I think just a few comments in the bug report would already be helpful. Thanks! [09:24] <_mup_> Bug #869824: Doing a search in the ddtp-ubuntu project's translations templates times out < https://launchpad.net/bugs/869824 > [09:29] dpm: I added a note. [09:30] I'm trying with a trigram index [09:30] Should help at least a bit. [09:30] Will see in a few minutes [09:30] You're trying it right now? [09:30] On dogfood, but yes. [09:30] Indexes building [09:30] Ah, that explains. :) [09:31] Although the potranslation index is going to be maaaaassive [09:31] thanks jtv, glad to hear that the upgrade might help. Did you see the question above about the recent translations changes branch you mentioned a few days ago? ^ [09:31] dpm: oh, sorry — phone. [09:31] Missed that. [09:31] Well the branch I was waiting for has finally rolled out. [09:31] The follow-up branches are now going through testing prior to landing. [09:33] wgrant, StevenK - are you both purple mafia too? [09:33] Yes [09:33] If only they could have asked Al Capone such a simple question. [09:33] heh [09:34] wgrant: Wasn't there some work to change the diff generation from cron to job queue? rabbit? Did that land? [09:34] (or was that not purple) [09:34] jtv, cool. So once they've all landed, if I recall correctly, some of the things that we'll see are: translator-credits cleanup, translations done with message sharing enabled will be correctly committed, regardless of whether they were done in the distro or in the upstream project. Is that correct? Anything else? [09:34] nigelb: The backend job stuff is currently being tested on staging. [09:34] It's not purple. [09:34] Ah. Deryck's team? [09:35] Yes [09:35] Aha. [09:35] Orange :) [09:35] dpm: I'm not sure what you mean with committing of translations, but the *credits* will start fixing themselves. [09:35] dpm: It won't affect the comitting [09:35] dpm: That requires additional work [09:36] The credits for Ubuntu and upstream will be more or less identical. [09:36] ok, understood, thanks wgrant and jtv [09:39] nigelb: Purple *Assassins* [09:39] StevenK: Right. Sorry. Hey, I suggested the name. I think. [09:39] Purple Headed Monsters [09:40] nigelb: Maybe a variation of it. [09:40] jtv: Bah [09:40] jtv: My plan is foiled [09:40] bigjools++ [09:40] # CREATE INDEX temp_pomsgid ON pomsgid USING gist (msgid gist_trgm_ops); [09:40] ERROR: index row requires 8436 bytes, maximum size is 8191 [09:40] Any of you other than rob headed to kiwipycon? [09:41] wgrant: no toast? [09:41] jtv: Not for an index, I guess. [09:41] :( [09:41] jtv: We probably have to use full FTI [09:41] Rather than an ILIKE [09:41] StevenK: I think I gave it a different colour. Someone else picked the colour. [09:42] we should become the Rampant Reds [09:42] Oh please no [09:42] Rowdie Reds [09:42] wgrant: annoyingly, what we have works just great for everything else. We've been hoping for ddtp-ubuntu to be split up a bit more, but… [09:42] nigelb: We were Teal, until wgrant, sinzui and I revolted. [09:42] wgrant: there is downtime today at 20:00 UTC [09:43] I now have the Monty Python scene in my head ... "Welease Woger!" [09:43] czajkowski: There is [09:43] jtv: I'm surprised it works [09:43] jtv: Given the whole seq scan thing [09:43] wgrant: there is [09:43] StevenK: Haha [09:43] StevenK: you were already revolting [09:43] jtv: I guess every other template has few enough messages that it can just check them all... [09:43] bigjools: You must have taught me well, then. [09:44] wgrant: Exactly. [09:44] bigjools: Where in Australia are you settled? [09:44] nigelb: In wallyworld_'s lap. [09:44] the great barrier reef [09:44] lololol [09:44] I didn't realize this question would involve *hilarious* answers :) [09:44] i otlerate him for now [09:44] jtv: Also, that query is terrifying, btw [09:44] wgrant: your children will be next [09:45] err [09:45] wallyworld_: : your children will be next [09:45] Hahaha [09:45] That could be a while [09:45] best. tabfail. ever. [09:45] ehehe [09:45] wgrant: I don't recall it off the top of my head, mercifully [09:45] I hate irc [09:45] bigjools: next for what? [09:45] Ice cream! [09:45] jtv: It is 94 lines in length. [09:45] wallyworld_: you've heard the Manic Street Preachers? [09:45] * wallyworld_ shakes his head [09:46] you probably have but don't remember [09:46] I'll play some next time you're round [09:46] ok [09:46] one of their tracks is called Australia :) [09:46] Why wait? Turn up the volume a bit more. [09:46] ha [09:46] so long as it's not more van halen [09:46] HEATHEN [09:46] bigjools: Anyway, so you're in Sydney? Melbourne? [09:47] Bris [09:47] Ah. [09:47] ie. nowhere [09:47] I went to Melbournce once [09:47] that was enough [09:47] Grrr why can't I connect to anything? [09:47] and Melbourne too [09:49] I should be touching one of Sydney, Melbourne, or Brisbane on my way. [11:27] lifeless, hi, is there something I need to do to get db-stable r11610 deployed? [11:31] danilos: wrong timezone for him [11:31] czajkowski, he's lifeless, there's no wrong timezone for him ;) [11:36] danilos: Wait. See https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadProductionStatus [11:36] danilos: valid point there :) [11:38] cjwatson, thanks, but I've out of the process for a while, do you know if DB r11611 will also include r11610? or should I get a separate request up there [11:38] cjwatson, btw, are you rotating in LP, or just hacking on it (not so) randomly? :) [11:39] danilos: It means "everything up to r11611" (the rest are just merges and such) [11:40] cjwatson, cool, thanks, so it's not cherrypicking, great [11:40] We haven't cherrypicked in a long time. [11:40] danilos: Not rotating as such, but probably the majority of my scheduled work for this cycle involves improvements that Ubuntu Engineering needs in Launchpad [11:40] cjwatson, right, cool [11:40] danilos: So same kind of deal as the Linaro work items work AIUI [11:40] cjwatson, yeah [11:41] cjwatson, btw, while we are on the topic, do you know if ubuntu is planning to do any migration of their old workitems? I'd like to get rid of the migration script to help our LOC cause :) [11:42] danilos: I was under the general impression we weren't (and I'm not sure I see the point myself), but I'm not authoritative for that [11:42]