[00:54] cjwatson: You're dealing with the QA of r15504? [00:54] jelmer has a bunch of QA. :-( [00:55] Yes, literally just finished it in fact [00:55] cjwatson: \o/ [00:56] wgrant: branch-unsubscribe-revokes is looking good so far, ~ 2 hours to go [01:07] * StevenK gets disgusted enough to run format-imports again. [01:08] cjwatson: Can we delete delayed copies yet? How about now? Now? :-P [01:08] Once the custom upload fix is done and pocket queue admin permissions work :) [01:08] I think those are the only two blockers. [01:19] * StevenK stabs the branch scanner. [01:20] Every time I get frustrated, ssh to carob and sync logs it then scans correctly. [01:23] wgrant: https://code.launchpad.net/~stevenk/launchpad/imports-really-this-time/+merge/112470 [01:24] StevenK: lib/lp/app/widgets/tests/test_popup.py is wrong [01:25] And wow I completely failed at bugsummaryrebuild [01:25] Oh, yeah, I completly missed the utter fail in test_popup [01:25] Let me fix that up [01:30] wgrant: Diff updated [01:31] r=me [01:31] Your nation thanks you for your service. [02:01] wgrant: You have an hour to object to branch-unsubscribe-revokes. [02:01] StevenK: doit [02:02] wgrant: And the garbo job? :-) [02:02] Objection [02:02] wgrant: And the discussion about ubuntu/precise/datereleased over our API in -devel? [04:16] wgrant: Can has a concrete ruling on the garbo job, rather than 'Objection' ? [04:20] StevenK: It can land once the unsubscribe stuff is deployed and we've performed some data checks. [04:55] * StevenK stabs lazr.enum and then twists the knife. [04:58] wgrant: So, I've been fighting with a generalisation branch for RBSJ for too long. [04:58] I think we need a seperate job [04:58] As much as pains to say [04:59] StevenK: Why? [05:00] wgrant: Because I'm getting damn well nowhere [05:00] Or it feels like it [05:01] What's the problem? :) [05:02] Perhaps starting with renaming every class I could find was not the best way to start. [05:03] Sounds fine to me. [05:05] wgrant: http://pastebin.ubuntu.com/1063704/ [05:07] StevenK: Looks not unreasonable. Is there a problem? [05:07] I was chasing through the importfacist again [05:08] Turns out lazr.enum gives unintelligble errors if the first line of a DBEnum is multi-line. [06:27] Hi lifeless — are you free for a question about job dispatch with celery/rabbit? [06:39] jtv: high latency but yes. Just ask [06:40] We want to dispatch jobs to workers through celery. But we'd like to get proper transactionality on that. We looked at django-celery-transaction but it's written from a mubbet-labs “just patch into commit/abort and do your work there” approach. [06:41] As opposed to the “whatever is in the database is the valid state” approach that you'd normally go for. [06:41] We'd like to avoid rolling our own code for transferring committed jobs from the database to rabbit… know of any ready-made alternatives? [06:43] There's django-async, which at least is written by someone who understands this stuff, but it was designed as a lightweight replacement for celery rather than as complementary to it. [06:43] no; in particular you'll need to have something poll, or something using postgresql's push facilities [06:44] I thought the plan was to avoid the need for that by not emitting state; just emitting 'something happened' events and letting the worker read-back ? [06:44] so you will be transactional anyway [06:44] Well, sort of. [06:46] Yes, the plan was to do that. I hadn't thought of it as a replacement for transactionality of messaging; we'd always have to call back to the central server even if just to see whether the requesting transaction had committed. [06:46] And hope that we'd not do so too fast for the commit to happen. :) [06:54] well, yes, unles you emit the event right after [06:55] which may lead to no notification, of course [06:55] jtv: things to watch out for: super big journal tables after doing this for a long time [06:55] Journals on the filesystem? Or do you mean un-vacuumed database tables? [06:56] unpruned specifically [06:56] you're basically building a queue in the db, be sure it gets cleaned out [06:56] So you are talking about tables in the database then? [06:56] yes [06:57] Well there's vacuum for those. Right now I'm not building a queue in the db; I'm asking if there's a good way to do it. [06:57] I mean lots of rows, not unvaccuumed pages [06:57] other implementations I've seen accumulate forever, failing to delete rows. [06:57] That seems silly. [06:57] yes ;) [06:58] So basically we don't know of anybody getting this right? [06:59] At least, with celery. [06:59] U1 are doing a roll-your-own implementation [06:59] for their materialised views implementation [06:59] the only precanned 'this is a robust answer' I know of our there is storm. [06:59] Which is probably not something you'd want for MAAS. [07:00] No. I didn't even know it integrated with rabbit. [07:00] it doesn't particularly but it knows how to deal with the general situation [07:01] jtv: it seems to me you're solving a single piece of the puzzle better than the rest of the stack supports it [07:01] jtv: amqp isn't intrinsically transactional [07:02] Sadly. [07:02] unless you run in specific 2pc mode [07:02] erm, specific trasnaction mode [07:02] this means, you may suffer dropped messages [07:02] if rabbit is shut down hard at an untimely point. [07:02] This means, that its no worse to just emit the celery event right after the db commit. [07:02] Its not a new failure mode. [07:03] That is sad. [07:03] whatever approach is used to deal with 'some numpty/event killed rabbit hard' will also deal with 'the appserver was killed/segfaulted between the db committing and it handing off the event to rabbit' [07:04] I may be wrong; critical analysis welcomed. [07:04] I need to run for a minute, baby->sleep. [07:04] I'll be here. [07:08] back, tho my focus won't be here [07:08] its mid-evening now [07:08] I'll keep replying if you want to chew on this more [07:08] just slower - sorry. [07:14] anyone know where the source for the launchpad qa bot is? [07:14] pqm? [07:16] https://launchpad.net/pqm [07:17] mgz: That's qa-tagger [07:17] not opened sadly [07:17] Creatively enough that's lp:qa-tagger [07:17] needs personal details purged to do so [07:17] heh [07:17] Oh, I thought that was free. Sad. [07:18] ta! [07:50] lifeless: some distractions on this end as well. Anyway, I was also somewhat concerned about immediate failures to handle a job request. It would seem more sensible if those could abort the transaction that requested them. [08:03] oh [08:04] also, james_w made something that's a bit like qa-tagger, except it tracks revisions rather than bugs. [08:05] unfortunately, I can't remember what it's called or where it lives. [08:06] one of the downsides of ec2/canonistack deployment is the lack of memorable hostnames [08:19] jml: the openbsd folks had a solution for that — use pokemon names. But I suspect even that is not a large enough set for EC2. === jelmer changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jelmer | Firefighting: - | Critical bugs: 3.47*10^2 [08:20] jtv: /memorable/ hostnames ? :P [08:20] jelmer: well I remember pikachu, and that's about the only pokemon I ever heard of. So it seems to be working. [08:21] that's also as far as I get.. [08:21] jtv: also, not memorable. as a case in point, my code is running in production on machine named after an obscure fruit. [08:21] * jelmer kind of likes the fact that canonical machine names make me learn more obscure English words [08:22] Come on, there has to be a way to re-pair my laptop to my bluetooth keyboard! [08:23] * jml just had an idea [08:25] jml: well, what's the idea? [08:26] jtv: it's pretty revolutionary [08:26] (and magical) [08:26] Come on, cut to the chase! [08:26] a table: Column 1 is 'machine name', Column 2 is 'list of services on that machine, in names that developers use to refer to them' [08:27] one of those per project [08:28] and then there's none of this "could you please run X on foo-svc?", "sure. is that snuffleberry?", "I don't know, you deployed it." [08:28] That would be nice, yes… we had something like that on the wiki, once upon a time, but I don't think it was maintained very actively. [08:28] I hate that situation. [08:28] me too. [08:29] I also hope that there isn't actually a machine called snuffleberry. [08:29] I've seen a couple of diagrams, and they do the job too. [08:29] but they are a little trickier to maintain & grep. [08:30] jtv: you mean if celery fails to dispatch ? [08:30] lifeless: yes [08:30] For example, because the data won't serialize. [08:31] jmm [08:31] so, I'd have thought the django glue would do that immediately, and only defer the dispatch [08:31] That would be nice, if possible. [08:31] Maybe it does. [08:32] jml: But then you have the problem of services that have like 5 different names depending on who you ask :) [08:32] (carob:~stevenk/name-to-service is pretty good for LP, though) [08:32] wgrant: well yeah, but one problem at a time. [08:33] I didn't know anyone actually used it [08:37] * nigelb notices the Critical bug count being less than 3.5 * 10^2. [08:39] nigelb: That's a lie. [08:39] There's 402 open critical tasks === wgrant changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jelmer | Firefighting: - | Critical bugs: 4.0*10^2 [08:43] :( [08:43] I should have kept quiet and lived the lie [08:46] nigelb: dont comment :) [09:37] StevenK: I actually started on a remove-delayed-copies branch last night, although wgrant's right that pocket queue admin needs to be done first. Other things that come to mind are converting the +copy-packages UI to PCJs (can it perhaps use PCJs for everything now rather than having the dodgy "am I going to be able to copy synchronously" check? is it possible to update the UI on the progress of a job?), and making ... [09:37] ... Archive.syncSource start failing when it's asked to do a private->public copy that would require a delayed copy. [09:38] (Or perhaps convert Archive.syncSource to be asynchronous in that case, although that kind of violates its advertised contract. Might be better to fail and get people to convert to Archive.copyPackage.) [09:38] StevenK: Also I know that some bits of PCJs are hidden behind feature flags or disabled and I'd like to understand why. [09:39] jam: http://pastebin.ubuntu.com/1064002/ [09:40] And of course go through all the delayed copy tests and work out which of them might be sensibly converted to apply to direct-copies/PCJs. [09:42] Ah, the soyuz.copypackageppa.enabled feature flag is due to having no way to give feedback. Anyone want to educate me on how that stuff might work? [09:46] bigjools: In bug 575450, you offered mentoring for anyone who wanted to sort out feedback in PPA pages from the new async copying code. I'm game, since this seems to get in the way of cleanup I've committed to do as part of feature work I've already done. Do you think it could work in the same way as feedback from distroseries initialisation? [09:46] <_mup_> Bug #575450: Archive:+copy-packages nearly unusable due to timeouts

< https://launchpad.net/bugs/575450 > [09:46] cjwatson: I'd prefer Archive.syncSource to fail, TBH [09:47] StevenK: OK. That obviously is definitely blocked on pocket queue admin, since we need things to be self-service for the security team before breaking what they're using now. [09:47] cjwatson: I am a little tired right now, just had twins, so if you can wait a couple of weeks I'll be happy to help [09:47] bigjools: hah, congratulations! [09:47] ta :) [09:48] go change one nappy with each hand or something then [09:48] cjwatson: If the distroseries init stuff is making use of IDSJ, it can probably be used as inspiration [09:48] StevenK: It is [09:48] * StevenK heads off to pick up his wife [09:48] There's a thing where the job calls notifyUserError on failure and that pops up through distroseries-portlet-derivation.pt [09:49] So I can probably monkey-see-monkey-do that if it's broadly a usable approach [09:49] cjwatson: the plan was to have failed jobs showing on the page and to have someone ack them by deleting them [09:49] anyway, cheerio [09:49] Hm, right, a bit different then [09:52] r14665 seems to be a moderate-sized chunk of that [09:53] rvba: Do you happen to recall what was left to do in bug 575450? Your r14665 seems to be approximately what bigjools said above needed to be done [09:53] <_mup_> Bug #575450: Archive:+copy-packages nearly unusable due to timeouts

< https://launchpad.net/bugs/575450 > [09:53] I wonder if it's just cleanup at this point ... [09:59] Mr Reviewer Please: https://code.launchpad.net/~gz/launchpad/py27_xmlrpc_transport_timeout/+merge/112528 [10:19] rvba: If the UI does indeed now do what bigjools said it needed to, it is extremely tempting to propose something like http://paste.ubuntu.com/1064032/ for merging [10:21] (Does it matter if the DB has feature flags that are no longer referenced anywhere in code?) [10:37] Hm, OK, this runs headlong into bug 795005 [10:37] <_mup_> Bug #795005: Asynchronous PPA copying with default series OOPSes < https://launchpad.net/bugs/795005 > [10:40] cjwatson: If the DB has feature flags that no longer referenced, they should be removed. [10:43] StevenK: Right, but will it make anything fail if they aren't - that is, are there deployment considerations in landing patches that remove feature flags? [10:44] cjwatson: Right, so I've in fact just done this. [10:45] cjwatson: It's fine to remove the code first. [10:45] cjwatson: r15494 drops two related feature flags from the code. [10:45] cjwatson: Nothing breaks if there are unknown flags set. [10:45] Or unknown scopes [10:45] etc [10:45] cjwatson: I was going to ask that the two flags be removed from prod tomorrow morning. [10:50] Cool. [10:51] jelmer: mr reviewer, if you please: https://code.launchpad.net/~jameinel/launchpad/py27-parse-response-1018768/+merge/112537 === matsubara is now known as matsubara-lunch [12:02] cjwatson: flags were designed to fit a relaxed workflow [12:03] cjwatson: vs lazr.config which is designed to fit a strict, but high latency work flow. [12:12] lifeless: have you come across this issue or is there a step missing ?https://answers.launchpad.net/launchpad/+question/201678 [12:15] czajkowski: he should add a release, that's the way to add downloads [12:15] jelmer: ahh I see [12:15] confusing me aslso [12:15] thanks [12:15] Sounds like an opportunity to improve the docs then :-) [12:16] czajkowski: I've replied on the question page [12:16] jelmer: ack, I can view his screen shot so can see his point [12:16] cjwatson: indeed === matsubara-lunch is now known as matsubara === mrevell_ is now known as mrevell === Nigel is now known as G [12:56] rvba: Also, is it possible that your r14665 fixed bug 812869? It certainly looks as though it should have done [12:56] <_mup_> Bug #812869: Failed PackageCopyJobs should show up on the PPA page somehow < https://launchpad.net/bugs/812869 > [12:58] cjwatson: let me refresh my memory and have a look at the revision and the bug in question :) [13:03] cjwatson: that would make sense indeed. Also, what I've done in my branch is exactly what Julian suggests to do in the description of the bug, for that type of error that is (if the target archive is a ppa). [13:12] Yeah, that's what I thought [13:12] Difficult to easily try it at the moment since async copies are disabled [13:12] Speaking of which: [13:12] jelmer: Oh hi Mr. OCR. Fancy having a look at https://code.launchpad.net/~cjwatson/launchpad/copy-packages-with-default-series/+merge/112557 ? [13:14] cjwatson: yep, I'll have a look [13:14] I *think* that should let us re-enable async copies in the UI. [13:14] Assuming there are no other lurking undocumented reasons. [13:21] Morning, everyone. [13:22] morning [13:30] cjwatson: I'd like to have a chat with you sometime about how we can get some of the 'when is it safe to cleanup files' policies encoded into Launchpad, rather than having them be as ad-hoc as they are now. [13:33] Mm. Well, at the very least it seems as though it ought to be a script in the tree that web0ps can run, rather than it being ad-hoc pastebins. [13:34] adeuring, https://plus.google.com/hangouts/_/f9d8daf3da1ea6e3b6c53ff8ed10332dbde5899c?authuser=0&hl=en [13:34] Unfortunately the fact that PES have a habit of relying on obsolete distroseries after Ubuntu stops supporting them, and we have to confirm with them that they no longer care, makes it difficult to do it all automatically. [13:34] I just hit a timeout loading my branch page :( [13:47] cjwatson: PES? [13:47] also, we can make it manual as much as "we've confirmed it is ok to nuke N, do it" [13:48] The division formerly known as OEM [13:48] so there is a bit of manual step in there, but all of the validation that we're doing is mostly already done inside launchpad, we just have to realize if we can trust it. [13:49] lib/lp/services/doc/timeout.txt seems appropriately named === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jelmer,jcsackett | Firefighting: - | Critical bugs: 4.0*10^2 [13:52] jcsackett: feel like some JS in the morning? https://code.launchpad.net/~rharding/launchpad/bug_yui35_two [13:53] rick_h_: sure. [13:55] rick_h_: it's only because i want these changes landed that i'm not going to yell about diff size. :-P [13:55] jcsackett: well, don't let it fool you, it's 98% "tab over all the linse" [13:56] rick_h_: yeah, i'm seeing that. i'm just giving you a hard time, anyway. :-P [13:56] :) I'll send the 'gift beverage' later [13:56] hopefully I'll have one more of these before EOD [14:00] * jcsackett laughs at "gift beverage". [14:01] i wish diffs were smarter about tabovers. [14:07] rick_h_: how many tests have you seen in YUI land that rely on .wait() in some form? [14:08] i'm vaguely concerned about those in relation to gary_poster et al's info regarding tests with programmed delays being problematic for parallel testing. [14:08] jcsackett: in our code? [14:08] rick_h_: yeah. [14:08] * gary_poster on call [14:08] there's a solid handful I think, but I think most of that stuff has started to get 'skipanimation' flags and such to help clear that up [14:08] rick_h_: okay, cool. [14:09] I've not gone through everything though so can't say for sure [14:16] cjwatson: check_copy_permissions properly checks with the source distroseries of each spph if none is specified explicitly; however, copy_asynchronously uses the dest_series of the first specified spph for all specified spphs if no distro_series was explicitly specified. [14:17] cjwatson: apologies for the abundant use of the word specified in that sentence.. [14:25] jelmer: could you take a look at this please? https://code.launchpad.net/~ivo-kracht/launchpad/bug-436663/+merge/112576 [14:25] ivory: yep [14:25] jelmer: thanks [14:37] gmb: for your pleasure https://code.launchpad.net/~vila/launchpad/py27-mail-header-continuation-lines/+merge/112579 === Ursinha` is now known as Ursinha [14:40] jcsackett, do you have time to review https://code.launchpad.net/~sinzui/launchpad/bug-tag-completions/+merge/112580 [14:40] sinzui: sure. [14:43] jelmer: Oh, yes, I see what you mean (after some thought) [14:44] jelmer: Fixing [14:44] jcsackett, I see I was mentioned in passing. Thank you for keeping that in mind! The biggest thing is to make sure that you allow for a testing machine being much, much slower than you expect. We don't want the tests to hang forever, but if it passes in a really long time because of contention on [X random thing I wish I knew but is not apparently RAM, CPU or I/O] then we'd rather give it a nice long while to try [14:44] and let it pass. [14:45] jelmer: OK, fixed now [14:45] Er, modulo pushing (pushed now too) [14:48] StevenK: A bit to go, but very provisionally the gain from removing delayed copies looks like 1160 LoC [15:01] sinzui: jelmer said a ui reviewer should take a look at this and since you are the only one, could you? https://code.launchpad.net/~ivo-kracht/launchpad/bug-436663/+merge/112576 [15:01] sinzui: i attached a screenshot to the bug description [15:02] sinzui: so you can set a CSS name override on extending a Widget: http://yuilibrary.com/yui/docs/api/files/widget_js_Widget.js.html#l95 [15:02] * sinzui looks [15:02] sinzui: not sure if that helps you with the issue in your MP addendum [15:02] rick_h_, ! [15:02] rick_h_, I bet it does. [15:02] ivory: Fixing that bit of lint would just amount to deleting one line; I'm not a reviewer but IMO you might as well do that [15:02] * sinzui wonders how quickly he ca rewite the widget again [15:03] sinzui: heh, you want me to look over the rest here? [15:03] rick_h_, please do. [15:04] ivory, that is a good improvement. [15:05] sinzui: i was a little bit concerned about the little gap next to the bug icon but i have no idea how to fix that [15:06] ivory, one of the links is not using a sprite properly [15:06] * sinzui looks at code [15:08] ivory, this looks like one of the macros is bad, but fix it would require a review of many pages that use the macro [15:08] ivory, few mp reference both blueprint and bug, so the issue will rarely be visible [15:09] sinzui: so its ok for now? [15:10] yes [15:10] ok then thank you for helping me [15:14] sinzui: r=me, but there's a short style note on the MP. [15:14] thanks [15:14] yw. [15:15] jelmer: Thanks for the review. I thought that test_copyPackages_with_default_distroseries was exactly such a test, or am I misunderstanding you? [15:16] It creates two SPPHs with different distroseries, and copies both with to_series=None. [15:17] cjwatson: we're trying to sort out https://answers.launchpad.net/launchpad/+question/194817 [15:17] I think we've unblocked ubuntu translations to open Q for translations, but it is pending DPM actually exposing Q to users [15:17] (specifically, unchecking the Hide translations for this release box) [15:17] I haven't seen dpm around in about a week, so I don't know if there is something blocking. Do you know anything about it? [15:18] jtv said that the import queue looked good [15:18] jam: Right, thanks. From my point of view the question is a fire-and-forget notification which I am required to emit as part of NewReleaseCycleProcess but otherwise don't care much about. :-) [15:18] I don't know anything about dpm's status on it. [15:18] czajkowski: then I think we can close the question [15:18] as we took his info, and did our part of it [15:19] dpm is on vacation [15:19] sinzui: couple other suggestions but good stuff! [15:19] cjwatson: ah, that's true.. [15:19] thank you [15:19] cjwatson: did that test fail before r15510 ? [15:19] he's back in 7 days [15:19] jam: grand will do thanks [15:19] jcsackett: heads up, YUI3.5 doesn't like the selector stuff [id=field.name], it has to be in quotes in 3.5 [id="field.name"] [15:20] rick_h_: i was gathering that from your updates. [15:20] jcsackett: so any time we can catch that now the better [15:20] jelmer: No - that comes under my comment in the MP about not adding a browser test because there's one that fails already once I remove copy_synchronously [15:20] jelmer: I can try to figure out if *that* test would have failed before r15510 [15:20] jcsackett: yea, I've got a google doc with the new things to watch out for. Going to get a bit farther before I wiki/send that out to the list [15:20] (Too many branches!) [15:21] And for that matter I ought to test that the failing test passes with r15510 [15:23] gary_poster: ok, i think most of our tests in YUI have a fair bit more padding than they need, so perhaps they'll be alright. and as rick_h_ has mentioned, we're slowly removing a lot of the need for delays anyway. [15:24] awesome [15:24] Hm, it doesn't check for the bug fixed in r15510 [15:24] jelmer: OK, let me stop trying to dodge it and see if I can figure out how to add a proper browser test or two here [15:25] rick_h_: ah, i see your comments on sinzui's diff. now i understand you're highlighting it. good catch, and thanks. [15:25] jcsackett: yea, just pushing the word out since you're reviewing/doing JS stuff. I know I hit up a review for ian bringing it up as well [15:26] rick_h_: yeah. there's a slight mental lag in realizing something is needed and applying that to reviews. :-P [15:26] cjwatson: okay, great [15:27] jelmer: Perhaps I should convert at least some of archive-views.txt to unit tests while I'm at it ... [15:28] I'm rarely confident that I can extend doctests without either (a) breaking something or (b) wanting to shoot myself to ease the pain [15:28] cjwatson: You should get some kind of public service medal if you did that.. :) [15:28] I assure you it's entirely selfish [15:29] cjwatson: I'm mostly concerned about corner case bugs, so as long as the test coverage is decent I'm happy [15:29] Yeah, me too [15:30] Since I'm trying to accelerate making the async copy stuff the only path [15:30] One of those things in Launchpad where it looks like it's been about 90% done [15:31] jcsackett, I will make the changes you ask, but I am not being pythonic. That function is an method argument ending in ");" [15:32] jcsackett, it would be more obvious if I defined the function first, then passed it to the method [15:34] sinzui: well, i see that one is a creation call, one is an event call binding, and one is a function def. my understanding was that for all of those closing at the same tab level as the start, rather than the enclosed, was preferred. [15:34] wtf [15:34] another timeout [15:34] sinzui: if i'm wrong as goes JS style (or LP's version of it) i'm happy to be told so. :-) [15:36] jcsackett, js hackers have inconsistent style because JS does not require it, and encourages anonymous inline definition to manage scoping. I am very consistent since I know that how I wrote my method calls will not change if I choose to no use anonymous functions [15:38] sinzui: fair. we should probably at some point then figure out a rule for consistency's sake in our code. but it's not terribly important if you're aginst it -- rick_h_'s points are definitely more key. [15:40] sinzui: yea, I think in JS you always tend to have at least one closing }; lined up with the start of a block [15:40] ime that is [15:40] but you're right that it's more of a practice thing than something jslint, etc will yell about [15:47] ummm, jcsackett did I ever tell you that you're a great co-worker? https://code.launchpad.net/~rharding/launchpad/bug_yui35_three/+merge/112590 [15:47] * rick_h_ runs to go fetch some lunch far far away [15:52] right, everyone else? rick_h_ is why your MP is not being looked at today. blame him. [15:52] * jcsackett settles down to a long review. [15:52] jcsackett: it was only 3 files? not my fault there are nearly 4k long JS files in the tree [15:52] jcsackett: these are even fewer changes than the earlier set [15:53] rick_h_: yeah, it doesn't actually look that bad. [15:53] but diff size: 7000 has a way of setting one back on one's heels. :-P [15:54] yea :/ [15:54] makes you feel better, I wasn't going to do a _four, but kind of have to [15:55] eh, i don't really need to be made to feel better. the only real problem with these branches is that the diff ordering makes it impossible to tell what's just indenting and what's an actual new line. [15:55] only new lines shold be the top of the files [15:56] rick_h_: ah, that makes things easier, then. [15:56] I'm really only changing the top 20 lines of files, and indenting the rest. Oh and each suite.add is now tests.suite.add [15:56] in this one I had the s/LPClient/Y.lp.testing.helpers.LPClient to fix that bug/code dupe [15:57] I'll try to note explicitly in the next one. [15:58] 8/c [16:01] jam: bug 1018905 filed [16:01] <_mup_> Bug #1018905: lp/services/doc/timeout.txt hangs in Python 2.7 < https://launchpad.net/bugs/1018905 > [16:05] vila, http://paste.ubuntu.com/1064552/. The failure is somewhere before line 2664 [16:12] sinzui: can you hit up #315 of the updated MP ? [16:14] sinzui: sorry, the id=field quotes [16:14] ruse [16:14] sure [16:14] gary_poster, jelmer just found our problem: lp.codehosting.codeimport.tests.test_worker.TestBzrImport.test_unsupported_feature starts but never (apparently ) finishes. [16:16] Keeping that test: line gives you 17 tests (not parsing out all the crud we parsed out). Removing it gives you 800-something. [16:16] Will poke at it properly tomorrow. [16:16] gary_poster, http://paste.ubuntu.com/1064576/ is the subunit stream. The test is at line 70. [16:37] gmb: bug 507804 [16:37] <_mup_> Bug #507804: damaged streams may not be obvious < https://launchpad.net/bugs/507804 > [16:37] wgrant: I believe I have fixed https://code.launchpad.net/~cjwatson/launchpad/custom-uefi/+merge/111626 in light of your configuration comment, by handling this in publisher configuration as well. Do you think this is a better approach now? [16:38] gary_poster, See that bug that jelmer just pasted ^^ [16:38] Fun times. === matsubara is now known as matsubara-afk [17:07] gmb :-) . I don't see how that subunit bug will be fixed, exactly. makes the whole thing fragile, but...not sure what else subunit could do other than various heuristics. Meanwhile, we should fix that test, and then hopefully we'll be ok. There may be other tests like that though--note that other workers seemed to be generating the "unknown worker" tests too. [17:51] jelmer: I've added that test now (though I gave up on the unit test conversion, sorry :-) I found some relevant tests that were already unit tests instead) and will land that shortly. Thanks for the feedback. [17:52] jelmer: (And the new test failed before r15510) [17:56] did anyone here just expire launchpadlib 1.6.0 on pypi? [18:05] cause now I can't 'pip install launchpadlib==1.6.0' [18:06] which means I can't have a virtualenv that reliably looks like lucid [18:09] jml: yea, and not seeing it on crate.io either. [18:19] jcsackett: last one https://code.launchpad.net/~rharding/launchpad/bug_yui35_four/+merge/112609 [18:34] rick_h_: on it. [18:37] also oauth is missing [18:45] rick_h_: r=me. [18:46] jcsackett: ty much. [18:55] deryck, rick_h_Do either of you have any insight into why I cannot between the items in a choicelist? For example I open bug status, the close button is focused. I cannot tab to the items in the list...though I know all but one is a anchor. [18:57] sinzui: looking [19:01] sinzui: sinzui can you tab outside of a form? [19:01] well... [19:02] I'm trying to find something that confirms/denys this but no luck yet [19:03] sinzui, I recall some bug about this before too. Seems like we used tabindex to fix it. [19:03] right, the tabindex docs don't state if they only work inside of forms or not [19:03] rick_h_, no but I just hacked the picker to add tabindexes to the anchors tabbing from the close button goes to the top of the page (leaving the overlay) then eventually returns to 2 of the link many links listed [19:03] http://www.w3.org/TR/WCAG20-TECHS/H4 [19:04] this is madening [19:04] sinzui: right, but what's the order on the tabindex? [19:04] it works on dom order by default, so top of the page makes sense [19:04] 0 for the button, 1-n for the items in the list [19:05] try setting 0 on the close button and then 1+ for the links [19:07] sorry, isn't that what I did? [19:08] ah The links to have the tabindexes, but the button did not stick. [19:08] * sinzui looks [19:08] sorry, when you said 0 for the button didn't follow [19:16] rick_h_, I don't appear to be setting tabindex="0" on the close button. There is no error, maybe I added it to some other overlay's button. The link do have a sequence on tabindexes [19:17] sinzui: yea, and tested that it works sans form no problem [19:17] so must be a matter of getting the order/relationship going with the rest of the page noise [19:18] Maybe I should start the index at 100,000 [19:18] hah, there you go [19:19] so is there some code in the widget setting focus on the close icon? [19:19] ah yea, there it is [19:20] yes, after we render we position and set focus... [19:20] but that is also were I decided to add the tabindex and it does not show [19:20] using set or setAttribute? [19:20]