[01:46] wallyworld__, wgrant: https://code.launchpad.net/~stevenk/launchpad/fix-branch-subscribe-open-team/+merge/111326 [01:47] StevenK: otp, can look soon [02:05] StevenK: r=me [02:05] StevenK: i assume the existing tests look for the field error [02:14] wallyworld_: Yeah, that was added in branch-subscribe-aag [02:15] cool [02:28] cjwatson: I'll run gina with commits enabled in a sec to revert the DB archive to the state we have on disk. [02:39] Oh [02:39] gina might be even slower than I thought it was. [02:39] * wgrant fixes. [02:40] Ah, no. [02:42] -> Seq Scan on distributionjob (cost=0.00..3711.70 rows=1 width=70) (actual time=69.665..129.033 rows=4 loops=1) [02:42] Filter: ((job_type = 3) AND (distroseries = 107) AND (json_data = '{"sourcepackagename": 72909, "parent_series": 50}'::text)) [02:42] That seems... fragile [02:42] StevenK: wtf [02:42] ? [02:42] * wgrant blames bigjools too. [02:43] Do either of you recall why we do that, and what will break when I make it stop doing that? [02:43] Context? [02:43] errr someone is filtering on json_data [02:43] ? [02:43] DSDJ creation seems to first check if there are any existing jobs [02:44] By byte-matching the JSON [02:44] sweet fuck [02:44] Twitch, there are columns for thatr [02:44] s/r$// [02:44] There aren't columns for that. [02:44] But it's also probably not necessary. [02:44] And it's slow and fragile. [02:44] So I think I might delete it and see what happens. [02:44] who is bzr blaming? [02:45] do not delete [02:45] No idea, I haven't found the code yet. [02:45] check the commit msg please [02:46] You ruin all my fun. [02:46] why the heck is lp-propose pushing a target branch if it doesn't exist?! [02:46] wgrant: your delete and revert reflex is well known [02:48] Oh, sneaky, DSDJ is in Soyuz while DSD itself is in Registry. [02:48] I think it was jtv [02:48] find_waiting_jobs in DSDJ's model [02:48] # Look for identical pending jobs. This compares directly on [02:48] # the metadata string. It's fragile, but this is only an [02:48] # optimization. It's not actually disastrous to create [02:48] # redundant jobs occasionally. [02:48] Yeah [02:48] So it can be deleted without peril. [02:49] I can recall being a little dubious when that code landed. [02:54] StevenK, wgrant: yes that was me. Feel free to improve it. [02:54] o/ jtv [02:54] Hi there spm! [02:56] It's just a filter for curbing duplication of jobs. The thinking was that with 1 item in the JSON, it's a pretty reliable match; with 2 items in the JSON, there's only going to be at most 2 jobs even if the keys are in random order; and with 3 items in the JSON, it's time to actually think what should be done. [02:58] Heh, true. [03:04] If the filter is too costly, it can be removed — but first I'd assess the risk of duplicating DSDJs. That was part of the work I was hoping to avoid with this simple check. [03:05] Then again, 50ms doesn't seem like a huge cost. [03:05] An index could be another way to go. [03:06] well [03:06] its racy [03:06] unless we up our isolation level [03:06] Only slightly, but yes. [03:06] Upping the isolation doesn't help, I don't think [03:07] Oh, during the running I guess it would, indeed. [03:10] yah [03:11] it would make read-its-there-don't-add-commit conflict. [03:18] unless of couse a specific DSDJ is idempotent [03:18] in which case, the race isn't important, as it cannot be stale, but OTOH a duplicate should be approx free because the worker can check whether the output is there already. [03:21] The jobs are fairly expensive due to librarian access. [03:21] But it's otherwise not a problem for them to be duplicated. [03:25] can they not determine that they completely finished and shortcut (assuming idempotency) [03:29] Indeed, they probably could avoid recalculating the base version if neither series' version has changed. [04:42] morning [05:17] jtv: hiya, heading offline for a few days, left message in pm [05:17] see you all Monday [06:12] wgrant: thanks for QAing that, I wasn't looking forward to it [06:13] It took about 3 hours for the first run, IIRC. [06:13] Subsequent runs take less than a minute. [07:52] food morning === almaisan-away is now known as al-maisan [09:34] jelmer: could you review this? https://code.launchpad.net/~ivo-kracht/launchpad/bug-897571/+merge/111367 [10:04] ivory: sure [10:06] wgrant: are you still around [10:07] hi jelmer [10:12] hellø :) === jml is now known as jml_ === jml_ is now known as jml [11:10] is there an http equiv of 'bzr branch bzr+ssh://bazaar.launchpad.net/+branch/pkgme' (i.e. a fixed string that I can put before a project name to fetch its trunk?) [11:11] I don't want 'lp:' because it generates warnings about launchpad-login and this is an automated process. [11:13] morning [11:14] jml, so what I've done is branch with the lp: and bzr info to get the full url for that project [11:14] is it for one or many projects? [11:14] rick_h_: thanks. that's a bit of a shame, because I'd rather depend on the slightly more stable lp:foo url equivalent. [11:16] jml: it could be there for sure, I'm just so far from a bzr expert to say for sure. abently will be around in a couple of hours and he'd be able to tell for sure [11:16] rick_h_: many. thanks. [11:33] jml: nope, there's no simple mapping, you need xmlrpc === al-maisan is now known as almaisan-away [11:37] don't do this but... [11:37] >>> from bzrlib.plugins.launchpad import lp_directory [11:37] >>> lp_directory.get_lp_login = lambda: None [11:37] >>> lp_directory.LaunchpadDirectory().look_up("er...", "lp:bzr") [11:37] 'http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev' [11:41] * jml would rather patch LP to have a proper rewrite map for http [11:42] but there are only so many patches to LP that I can justify. [11:42] would be nice, wouldn't it. xmlrpc is an arse. === matsubara is now known as matsubara-lunch [11:54] doesn't just http://launchpad.net/PROJECT work? [11:54] it seems to here [11:54] jml: ^ === almaisan-away is now known as al-maisan === jelmer is now known as Guest22079 === bac` is now known as bac === matsubara-lunch is now known as matsubara === jam1 is now known as jam [14:13] dpm: how's the translation stuff coming? [14:16] jtv, dpm: from what I can see the summary statistics pages between P and Q are virtually identical. So it looks like all the async jobs have done their work, and got Q into pretty good shape. [14:16] guess jtv isn't here now. [14:26] is anyone else getting sporadically failing javascript errors on ec2? I keep getting hatemail with a ton of failures but when i run all YUI tests locally they all pass. === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | Welcome our new intern: ivory | On call reviewer: jcsackett | Firefighting: - | Critical bugs: 3.47*10^2 [14:33] * jcsackett realizes it's thursday. [14:42] jcsackett: been that way all week. Was so sad when the wife corrected me today that it's not friday [14:44] jam, I'll talk to the ubuntu-translations-coordinators team, and unless they see anything, I'm aiming to open translations tomorrow [14:49] jcsackett, can you review https://code.launchpad.net/~sinzui/launchpad/bug-tags-edit-0/+merge/111410 [14:49] sinzui: just opened it, actually. :-) [14:50] abentley: ping [14:50] frankban: pong [14:51] abentley: I am having troubles trying to fix a test isolation bug; if 3 tests are run in a predefined order I get a db DisconnectionError [14:52] abentley: these are the 3 tests: http://pastebin.ubuntu.com/1052752/ [14:53] frankban: Okay, is that the order they must be run in? [14:53] and the last raises "DisconnectionError: terminating connection due to administrator command. SSL connection has been closed unexpectedly." [14:53] abentley: yes [14:53] frankban: Can you post the traceback, please? [14:54] sinzui: r=me. [14:54] faboo [14:55] sinzui: so, given that a) i'm not that far in the new team form work, b) wallyworld_ seems to have all of that *well* in hand, and c) there's a critical in our next lane that's been sitting for awhile, i'm thinking of dropping my curent work and doing the critical. [14:55] thoughts? [14:56] jcsackett. I do want it worked on...but do we know how to solve it at this moment? [14:56] sinzui: i *think* so. want to chat about it? [14:57] We want to unsubscribe users that project does not share with, and are not in the bug-supervisor or security contact roles, but not break ubuntu [14:57] right, but we had to put a flag in for the ubuntu case anyway. which means we can structure what happens around that. [14:58] jcsackett, when the ubuntu community make a bug public, they expect all the subscribers to remain because they and Lp do not know who should have access. [14:58] abentley: http://pastebin.ubuntu.com/1052761/ [14:59] sinzui: hrm; fair. i had not thought about the "return to public" part. [14:59] jcsackett, so solving the issue for everyone except ubuntu fixes 99% of the problem [15:00] jcsackett, community might toggle between public and private by accident. The ubuntu bug supervisor does not get subscribed (we know that for certain) so we just have to hope the community can mange the subscriptions themselves [15:00] frankban: So, that exception is actually being raised on the Celery side, I believe. [15:01] sinzui: so, on switch to a private type, do the remove all subscriptions except special roles thing, and just hope everyone sorts it out when it switches back? [15:01] abentley: I agree, it is raised by a transaction.commit called by pop_remote_notifications [15:01] frankban: Which probably indicates a bug in the Celery stuff. [15:01] jcsackett, not for ubuntu. their supervisor is never subscribed [15:02] sinzui: right. [15:02] but otherwise. [15:02] jcsackett, lets just have a guard for ubuntu...no unsubscribing. They continue in the compromised fashion [15:02] sinzui: ok. so you're good with me tackling that and dropping the (now unecessary) new team form work? [15:03] every other project can be secure because Lp will unsubscribe everyone who is not in the legacy role or the info type is not shared [15:03] jcsackett, yep [15:03] frankban: So, the Celery tasks do some hacky stuff to switch database users. I'd assume that's the cause of the problem. [15:03] cool stuff. :-) [15:03] frankban: Are multiple tests doing pop_remote_notifications? [15:05] jcsackett, If my qa goes well today, I could return to bug tag manager. It requires a lot of markup that it could generate as progressive enhancement...this would be an incremental step to adding tag completion to +filebug and search which do not have the cumbersome markup. [15:05] frankban: Also, you know that you can get the celeryd-side traceback from the result object, right? [15:06] each test in that TestCase. and all the tests in that testcase call switch_dbuser(config.branchscanner.dbuser). But if I replace the last test with another one in the same TestCase everything is ok. [15:06] abentley: yes [15:07] sinzui: that would be awesome. [15:07] now, i just have to figure out why js tests are failing on ec2 but passing locally for me. [15:09] jcsackett, what really? [15:11] jcsackett, lucid uses an older version of webkit that knows that ids are unique. It return null if you try to locate it. The webkit on out computers returns the first one [15:29] sinzui: so, the require-id flag thing maybe the issue? [15:31] jcsackett, I am not sure. Recall we stopped the line a few months ago when wallyworld___ had a branch that always failed on lucid. The failure was legitimate because the page was creating bad ids, and the js only worked with the first item in a listing [15:32] sinzui: i do recall that; but these are modules i haven't touched and that don't rely on pickers, so i feel like something else might be happening than the new picker stuff generating bad ids. [15:32] I saw the same problem in workitems a few weeks ago too [15:32] oh, which modules [15:34] sinzui: http://pastebin.ubuntu.com/1052825/. all with JS timeout. [15:34] can't get it to happen locally though. :-/ [15:34] whoa [15:34] i've sent of ec2 test -o '--layer=YUI' to see if it's a "whole suite" vs "yui suite" issue. [15:35] jcsackett, I am very surprised. gary_poster added incremental reporting to html5-browser that also resolved timeout issues where tests grew too large. [15:36] sinzui: forget everything, i just figured it out, and i am an idiot. [15:36] :-) [15:36] yui_xhr are slow even on my computer. [15:36] yeah [15:36] they are [15:37] when i resent out the branch, not everything was pushed--it tested the old version, which had syntax issues. [15:37] so, if this ec2 test run comes back green i'll lp-land, since it's all just YUI changes. [15:37] well done. [15:37] yeah. i am smooth. [15:38] note to self: always double check revid. [15:38] sinzui, Easter Division? [15:38] jcsackett, I still use ec2 test and bzr pqm-submit in my working tree...they always abort if the revs are different === al-maisan is now known as almaisan-away [15:39] sinzui: yeah. i'm not actually sure why ec2 land doesn't. [15:39] perhaps that's something to change. [15:39] Huh, I thought it did. Doesn't it claim that it does? [15:39] Certainly seems surprising for it not to [15:39] gary_poster, In the Five Star Stories manga, the heroes are members of the Easter division. I think it is a Japanese corruption on East [15:39] it uses pqm-submits code to do that sort of thing [15:40] :-) cool sinzui [15:40] oh [15:40] and ec2 land is just a wrapper around ec2 test [15:41] at least that's what I saw when I looked at it last :-P [15:41] but you can run ec2 land from any directory. I think its goal it to land the approved version, not the current version [15:42] oh [15:42] maybe it changed then [15:46] abentley: here is the traceback attached to the job: http://pastebin.ubuntu.com/1052839/ [15:49] frankban: So my guess is that it's committing using the old connection. That seems to be the only way past operations could have an influence. [15:52] abentley: I'll investigate it, thanks for the hint. [15:56] hello everybody, i'm new to launchpad development, but i'd like to contribute fixing trivial bugs [15:56] hi replaceafill [15:56] i set up my environment with rocketfuel [15:56] hi jelmer_ [15:57] and chose LP: #210821 [15:57] <_mup_> Bug #210821: bug tracker list shows inactive projects <404> < https://launchpad.net/bugs/210821 > [15:57] replaceafill: great! How is it going? [15:57] jelmer_, http://pastebin.ubuntu.com/1052858/ [15:57] that's my approach [15:58] but i have a few doubts [15:58] 1. it changes part of a model [15:58] i'm not sure if it's better doing it at the "view level" [15:58] (assuming using .active checks is ok) [15:59] btw, sorry for my english, is not my first language :) [15:59] replaceafill: using .active seems reasonable to me [15:59] jelmer_, ah ok [15:59] replaceafill, that wont fix the bug [15:59] replaceafill, projects can be toggled from active to inactive, then back to active [16:00] It is okay for an inactive project to have a remote bug tracker [16:00] sinzui, i tried it in launchpad.dev, marking the gnome terminal project as inactive, and it gets filtered in the bugtrackers view [16:00] sinzui, ah [16:00] sinzui: this is just about what projects are listed in the remote bug tracker's info page I think [16:01] sinzui: wouldn't it make sense in that case to hide those projects that are inactive? [16:01] replaceafill, the problem is that queries to get the bugtacker/bugtask queries often forget to add Product.active == True [16:02] jelmer_, we do want to hide deactivate projects. That is either a query or a .active check in code iterating over a dumb result set. [16:03] sinzui: isn't that the code replaceafill is changing though? [16:08] okay. I am mistaken. That works, but it is iterating over unused data. Both queries in the preceding lines could be fixed to make LP faster: http://pastebin.ubuntu.com/1052872/ [16:09] jelmer_, replaceafill ^ is less work for Lp [16:09] ah, i had the sense that it could be fixed that way :) [16:09] but i don't know enough yet to change queries :( [16:09] sinzui: that makes sense [16:09] (does that really need raw SQL, btw?) [16:12] jelmer_, it should be storm, but this is very old code. [16:13] sinzui, could i help writing a test for your solution? [16:14] or maybe that's easy enough to write for you and i should move on to something else? [16:14] replaceafill, BugAlsoAffectsProductWithProductCreationView. _loadProductsUsingBugTracker is the last remaining origin of 404's for this case. BugTracker.product contains inactive products, and that view coverts the result set to a list without a filter [16:16] replaceafill, I think the test for your solution would be identical for either your solution of mine. We want to add a bugtracker to two products, make one inactive, then assert that .getPillarsForBugtrackers() returns one product [16:17] sinzui, ah ok, can i help with that? [16:18] sure. I want to have lunch, so you can continue work on the bug. I did not intend to steal it from you. [16:18] sinzui, :) np i understand [16:18] * sinzui needs to do QA [16:19] i'll dig into tests looking for examples to follow [16:19] and will report back [16:19] thanks sinzui and jelmer_ === salgado is now known as salgado-lunch === deryck is now known as deryck[lunch] [16:55] ivory: the link in your email came up bad, can you dbl check it please? === salgado-lunch is now known as salgado === deryck[lunch] is now known as deryck === gary_poster changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | Welcome our new intern: ivory | On call reviewer: jcsackett | Firefighting: https://wiki.canonical.com/IncidentReports/2012-06-21-LP-codehosting-intermittent-hangs (gary_poster) | Critical bugs: 3.47*10^2 [21:55] sinzui: just found out i'll need to bail around 6:30 or 6:45 tonight. :-/ === jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | Welcome our new intern: ivory | On call reviewer: - | Firefighting: https://wiki.canonical.com/IncidentReports/2012-06-21-LP-codehosting-intermittent-hangs (gary_poster) | Critical bugs: 3.47*10^2 === gary_poster changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | Welcome our new intern: ivory | On call reviewer: - | Firefighting: https://wiki.canonical.com/IncidentReports/2012-06-21-LP-codehosting-intermittent-hangs (lifeless) | Critical bugs: 3.47*10^2 === lifeless changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: https://wiki.canonical.com/IncidentReports/2012-06-21-LP-codehosting-intermittent-hangs (lifeless) | Critical bugs: 3.47*10^2 === lifeless changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2 [23:59] doh, no sinzui