[03:37] wgrant: ajax seems broke on bug 741528, is there anything I can do (file a bug, cry)? [03:37] Launchpad bug 741528 in firefox-3.5 (Ubuntu Karmic) "Compromised Comodo SSL certificates puts users at risk" [Undecided,New] https://launchpad.net/bugs/741528 [03:39] micahg: Hmm, it all seems to work except for the task table. [03:40] Has LP gotten past the sacrifice goat stage? :p [03:40] oh, yeah, sorry, should've been more specific :) [03:41] nigelb: so to speak. tho we're using black cockerels. does that count? [03:42] spm: definite improvement :D [03:43] wgrant: it's the task table I need to work tonight :) [03:44] micahg: I'm trying to work out what's up. Can you use the non-AJAX instead? [03:44] wgrant: yeah, I am, just taking a lot longer :) [03:44] Yeah. [03:47] Oh. [03:47] tal:condition="not:view/many_bugtasks" [03:48] lib/lp/bugs/browser/bugtask.py: self.many_bugtasks = len(self.bugtasks) >= 10 [03:48] That is slightly suboptimal. [03:50] yeah, especially with 5 releases, you're limited to 2 source packages or less across all, and that's when you need it most [03:51] Yup. [03:51] I guess that means someone found a performance issue with lots of tasks. [03:52] my guess is originally the ajax code was per widget [03:52] It still sort of is. [03:52] what does annotate say is up ? [03:52] ah, that would explain it, the actions should be factored out and just be a function call w/parameters if they're not already [03:54] I think we should probably migrate to the new inline widget stuff that thumper did. [03:55] wgrant: should I file a bug? [03:56] Bug #430288 [03:56] Launchpad bug 430288 in Launchpad itself "Major page render time regression in 3.0-dev for many-bugtask bugs" [High,Fix released] https://launchpad.net/bugs/430288 [03:56] That's why it was disabled. [03:56] wgrant: i think it was something even worse, like n**2 behaviour in number of tasks or something [03:56] it was definitely a cop-out [03:57] Let's see if it's still bad. [03:58] wgrant: btw there is a bug for the massive javascript redundancy on that page [03:58] lifeless: Everything has massive JavaScript redundancy. [03:59] wgrant: yes, just saying ;) [04:05] Hmm. [04:06] It's not quite as bad as it used to be. [04:06] Chromium does 100 bugtasks with full AJAX in 3s. [04:06] Still bad. [04:06] But not terrible. [04:09] wgrant: what's FF4 time onIt was discovered that several invalid HTTPS certificates were issued and [04:09] revoked. These were placed on the certificate blacklist to prevent their [04:09] misuse.? that [04:09] oops [04:09] * micahg shakes fist at xchat [04:10] Heh. [04:10] Let's see. [04:11] wgrant: also, which version of chromium? [04:11] micahg: 11.something [04:11] ok, so that'll be out next month :) [04:11] So the dev build. [04:11] Yeah. [04:12] Ah, Firebug is out now. [04:12] * wgrant grabs. [04:12] Ah, now we see the problem. [04:12] Firefox just hangs for a few seconds. [04:13] wgrant: AJAX related? [04:13] javascript [04:13] Yeah. [04:13] Well, yeah, JS. [04:13] Our JS is crap. [04:13] micahg: the way that the javascript is created and linked to the rows is extremely expensive [04:14] wgrant: if you have a good test case, we can try to get that fixed, performance is a big focus for them [04:14] micahg: It's really bad JS. [04:14] lifeless: yeah, but if chromium can do it, firefox should be able to as well :) [04:14] micahg: when ff gets v8 [04:15] micahg: anyhow, its bad for chromium too [04:15] lifeless: part of v8 is in FF4 [04:15] micahg: this should be something lazy like: bind all the buttons to a single callback; when someone mouses over a button that callback can hook up the real code, and we only have one copy of the real code. [04:16] 2.8/3s in addPickerPatcher [04:16] lifeless: exactly :) [04:16] micahg: but its not [04:16] * micahg was trying to suggest something like that above [04:16] micahg: its js emitted as literals inline with each task [04:16] lifeless: that is the recommended way to do JS [04:16] nigelb: of course it is [04:17] lifeless: (but everyone ignores it for code that works) [04:17] nigelb: well, I filed a bug on it [04:17] lifeless: Mmmm, not exactly. [04:17] lifeless: The slow code is not reproduced. [04:17] nigelb: but we have a queue of problems to fix :> - patches appreciated [04:17] lifeless: Each task calls setup_bugtask_row [04:17] wgrant: well, thats a small mercy [04:17] Which is slow. [04:17] If I get lp on my system working like ever, I'll help. [04:17] Right now, I fail at getting it working :( [04:18] wgrant: nigelb thats pretty straight forward if you're interested - I run it in a VM [04:18] bah [04:18] nigelb: ^ [04:18] lifeless: I'd like to discuss this with you in launchpad-dev in an hour or so if you're still around [04:18] micahg: sure [04:18] lifeless: I might grab you for help sometime then [04:18] * nigelb back2work [04:38] lifeless: The package accept page feels snappier now too. Thanks. [04:39] ScottK: And not just because it times out more quickly? :) [04:40] No. It's actually working so far (we just hit Beta 1 freeze and I did my first pass through the queue) [04:40] ScottK: \o/ [04:40] * lifeless pokes tongue out at the doubters [04:40] Excellent. [04:42] Let's not get too excited too fast. If I get through Beta 1 with no timeouts, then I'll start to feel good. [04:43] no promises :) [06:04] wgrant: OOPS-1910F577, delete packages timeout, I'm updating bug 590523 [06:04] Launchpad bug 590523 in Launchpad itself "Archive:+delete-packages times out" [Critical,Triaged] https://launchpad.net/bugs/590523 [06:04] https://lp-oops.canonical.com/oops.py/?oopsid=1910F577 [06:04] micahg: ppa:ubuntu-security/ppa? [06:04] wgrant: yeah :) [06:04] I guess that has a bit of history. [06:04] And lots of builds. [06:05] yep, should I file a new bug since it's a P3A? [06:05] No. [06:05] wgrant: update existing? [06:07] updated [06:07] micahg: Yeah, the OOPS ID is useful. Thanks. [06:08] and another pg83 bug is made relevant :) [07:52] lifeless: re the FTBFS report: do you have any ideas which parts is causing the trouble and how to improve it? (I guess gettig bug 558907 fixed would be helpful) [07:52] Launchpad bug 558907 in Launchpad itself "IArchive.getBuildRecords should optionally filter by series" [Low,Triaged] https://launchpad.net/bugs/558907 [07:53] geser: its timing out because the collection iteration in APIs depends on cheap indexing [07:53] e.g. foo[1000] depends on determining item 1000 cheaply [07:53] but its not cheap [07:53] if you process incrementally rather than reading all FTBFS for a series, there will be no problem [07:54] and probably be faster too as you'll be doing less cross-network work [07:56] what do you mean with "process incrementally"? [08:07] lifeless: what do you mean with "process incrementally"? [08:08] geser: Keep a local cache of builds. [08:14] wgrant: I still don't understand how to improve the script. Would doing a list() on the results of getBuildRecords and then iterate over that list help? Or am I looking at the wrong part of the script? [08:14] the script tries to fetch everything only once to avoid the delays from each http request [08:15] geser: So, the idea is to avoid retrieving all the data every time, keeping a persistent local store of the failed builds so we don't have to request the whole lot every time the script runs. [08:15] ah [08:18] I thought about that but could think of a way that it would work. The main problem I see is how to get the new failed builds on the next run? [08:18] s/could/couldn't/ [08:18] geser: ask each package that was a fail, if it has a newer publication [08:19] geser: if it does, its been fixed. [08:19] and new uploads that didn't fail previously? [08:19] walk the failure list - its in order - until you see a date that you saw on the previous run [08:20] unless your script is shutdown for a month, that will be fast [08:20] (I already have code to detect superseded packages) [08:20] It's still reasonably slow, but not that slow :) [08:24] lifeless: ah, so the list is in "fail" order and not order when the build records got created? e.g. armel fails a day later that the amd64 build (for the same package) because of a large build queue [08:25] would that be the "datebuilt" attribute from the "build" object? [08:25] geser: erg [08:25] geser: uhm, ok, walk back with 3 days overlap or something:) [08:25] we really need an api that matches your needs [08:25] The sort order changes depending on the status you request. [08:25] generic programming over high latency links is fail [08:26] And the object on which you request it. [08:26] wgrant: failed is in date_created in as far as the ftbfs scripts requests are concerned [08:26] lifeless: why not get the script (or more precisely the report) directly into LP? with more direct DB access it would probably cause less trouble [08:27] lifeless: Sure? [08:27] getBuildsByArchIds seems to sort on date_finished. [08:27] wgrant: check the timeout [08:28] lifeless: Is that for Failed to Build? [08:28] yes [08:28] huh, it is finished [08:28] mea culpa [08:33] to sum it up: I store the data from a previous run in some file, and on the next run skip over the builds which have a datebuilt before the first run, and only fetch those after that? (of course check the old stored builds if it's superseded or fixed (given-back)) [08:34] and I don't miss new records that way? [08:34] failures are by date_finished [08:34] so you shouldn't miss anything [08:34] is that in the api? [08:34] is it documented? probably not [08:35] geser: I'd be happy to do this in-launchpad [08:35] DistroSeries.getBuildRecords orders by date_finished except for NEEDSBUILD, BUILDING, UPLOADED and SUPERSEDED. [08:35] geser: but as a working [mostly] thing already, working on that is kindof lower priority than all the stuff that isn't working [08:35] wgrant: so what does it do when you get both FTB and NB ? [08:36] lifeless: Huh? [08:36] wgrant: if you ask for both a failed to build and a needsbuild status [08:36] You can't ask for both at once. [08:36] You can ask for one or all. [08:36] whack [08:36] Yes, our API is stupid :) [08:36] we could just sort by date finished desc null first, date_created [08:37] or something like that [08:37] That breaks on retries, but retries are broken anyway. [08:38] COEALESCE(date_finished, date_created) almost makes sense. [08:38] lifeless: on https://launchpad.net/+apidoc/1.0.html#build I see only datebuilt (Date finished; The timestamp when the build farm job was finished). Is that the date_finished or a different attribute? [08:38] Ubuntu bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress] [08:39] geser: datebuild == date_finished. The internal model has changed, while the API remains compatible to avoid breaking scripts. [08:39] *datebuilt [08:44] wgrant: UPLOADED == UPLOADFAIL in the API? [08:45] geser: UPLOADING, not UPLOADED, sorry. [08:46] but is it the same or a different state? [08:46] UPLOADING == "Uploading build" [08:48] ok, so the sorting is ok for the cases the script uses [08:49] will try to work on the script over the weekend [08:49] Thanks. If you need any help give me a yell. [08:50] geser: thanks! [08:50] geser: we will need to make the collection faster in LP eventually, but thats likely to be feature level work. [08:50] and we have /////many////// collections to fix [08:56] how hard would it be (and how long would it take) to add filtering based on date_finished to distro_series.getBuildRecords? so the script doesn't have to fetch old records it knows already about (or are even superseded by now) just to skip them. would that help the timeout issue? [08:57] geser: That's not too difficult, but you can do the same thing by just iterating through the collection until you see one that is older than you want. [08:58] ok, so this doesn't cause problems? just the refetching of the data we're still interested in on each run? [08:58] geser: Retrieving the early parts of the collections is no problem. [08:59] It's when you're doing stuff like OFFSET 3000 LIMIT 75 that it gets terribly slow. [08:59] Because it basically has to work out the first 3075, then return the last 75. [08:59] And the queries involved are not terribly fast. [09:01] at which part of the script do such queries get issued? so I understand the problem better [09:01] geser: Iterating through getBuildRecords. [09:01] The API limits it to batches of something like 75 [09:02] So it grabs 0-74 in one request, 75-149 in another, and so on. [09:03] so it's the "for build in series.getBuildRecords(build_state = state):" causing such queries? [09:03] Yes. [09:04] how can I avoid that even when I save the data from the previous run? [09:04] You'll get them in date_built order. When you see one which is older than your cut-off date, break out of the loop. [09:05] The getBuildRecords call doesn't grab everything at once. [09:05] ah, so fresh ones are at the bedinning of the list? [09:05] Right. [09:05] beginning [09:05] It's date_finished DESC [09:05] now everything gets more clear [09:08] would it be enough to save the date of the last still published build record (for each state)? and skip later ones === henninge is now known as henninge-afk === henninge-afk is now known as henninge === jtv is now known as jtv-eat === henninge is now known as henninge-lunch === matsubara-afk is now known as matsubara === henninge-lunch is now known as henninge === jtv-eat is now known as jtv === mrevell is now known as mrevell-lunch === jcsackett changed the topic of #launchpad to: https://launchpad.net/ | Help contacts: jcsackett | Mail notifications for bugs can see a delay of 4 hours | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ === jcsackett changed the topic of #launchpad to: https://launchpad.net/ | Help contacts: jcsackett | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ === adeuring1 is now known as adeuring === matsubara is now known as matsubara-lunch === apachelogger is now known as releaselogger === mrevell-lunch is now known as mrevell === deryck is now known as deryck[lunch] === Brot1 is now known as BerndSch === matsubara-lunch is now known as matsubara === deryck[lunch] is now known as deryck === sinzui changed the topic of #launchpad to: https://launchpad.net/ | Help contacts: sinzui | Mail notifications for bugs can see a delay of 4 hours | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ === Ursinha is now known as Ursinha-lunch [20:44] hi === Ursinha-lunch is now known as Ursinha [20:46] Hello. [21:03] hi === releaselogger is now known as apachelogger === aj00200 is now known as aj00400 === herb__ is now known as herb === mnepton is now known as mneptok [21:32] sinzui, i've switched over to using qastaging as opposed to staging, it looks like the database hasn't been sync'd with production for a while [21:33] sinzui, is there any kind of schedule when the database gets reloaded ? [21:36] bjf: in theory every week [21:36] in practice possibly 2-3 week [21:36] s [21:37] lifeless, hmmm, ok could be, i added a project to production about 3 to 4 weeks ago and qastaging doesn't know about it [21:38] it was last synced 14 days ago [21:38] from memory [21:39] lifeless, is this handled by some kind of cron job or is it something someone has to remember to do and do it "manually" ? [21:40] c [21:40] oops [21:40] bjf staging was restored on the 13th with data from the 12. [21:41] a cronscript does start the restore, every Saturday, but we are luck when we get to restores a month [21:41] actually [21:41] qastaging isn't in cron yet [21:42] staging is restored weekly [21:42] I do not think qastaging has ever gotten data since it was setup [21:42] sinzui: yes, it was done a couple of weeks back [21:42] I use staging's db exclusively for research [21:43] sinzui, i've tried using staging but been told qastaging is the correct place because there is no priority on fixing staging when it busts and it gets updated "often" [21:44] bjf: qastaging has always has current code. Most users do not care about data. I do because I work with spam and I research user issues === matsubara is now known as matsubara-afk [22:08] hi [22:08] hi [22:09] its nice that people form canonical are here === bjf is now known as bjf[afk] === sinzui changed the topic of #launchpad to: https://launchpad.net/ | Help contacts: - | Mail notifications for bugs can see a delay of 4 hours | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ === bjf[afk] is now known as bjf === yofel_ is now known as yofel