micahgwgrant: ajax seems broke on bug 741528, is there anything I can do (file a bug, cry)?03:37
ubot5Launchpad bug 741528 in firefox-3.5 (Ubuntu Karmic) "Compromised Comodo SSL certificates puts users at risk" [Undecided,New] https://launchpad.net/bugs/74152803:37
wgrantmicahg: Hmm, it all seems to work except for the task table.03:39
nigelbHas LP gotten past the sacrifice goat stage? :p03:40
micahgoh, yeah, sorry, should've been more specific :)03:40
spmnigelb: so to speak. tho we're using black cockerels. does that count?03:41
nigelbspm: definite improvement :D03:42
micahgwgrant: it's the task table I need to work tonight :)03:43
wgrantmicahg: I'm trying to work out what's up. Can you use the non-AJAX instead?03:44
micahgwgrant: yeah, I am, just taking a lot longer :)03:44
wgrant          tal:condition="not:view/many_bugtasks"03:47
wgrantlib/lp/bugs/browser/bugtask.py:        self.many_bugtasks = len(self.bugtasks) >= 1003:48
wgrantThat is slightly suboptimal.03:48
micahgyeah, especially with 5 releases, you're limited to 2 source packages or less across all, and that's when you need it most03:50
wgrantI guess that means someone found a performance issue with lots of tasks.03:51
micahgmy guess is originally the ajax code was per widget03:52
wgrantIt still sort of is.03:52
lifelesswhat does annotate say is up ?03:52
micahgah, that would explain it, the actions should be factored out and just be a function call w/parameters if they're not already03:52
wgrantI think we should probably migrate to the new inline widget stuff that thumper did.03:54
micahgwgrant: should I file a bug?03:55
wgrantBug #43028803:56
ubot5Launchpad 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/43028803:56
wgrantThat's why it was disabled.03:56
mwhudsonwgrant: i think it was something even worse, like n**2 behaviour in number of tasks or something03:56
mwhudsonit was definitely a cop-out03:56
wgrantLet's see if it's still bad.03:57
lifelesswgrant: btw there is a bug for the massive javascript redundancy on that page03:58
wgrantlifeless: Everything has massive JavaScript redundancy.03:58
lifelesswgrant: yes, just saying ;)03:59
wgrantIt's not quite as bad as it used to be.04:06
wgrantChromium does 100 bugtasks with full AJAX in 3s.04:06
wgrantStill bad.04:06
wgrantBut not terrible.04:06
micahgwgrant: what's FF4 time onIt was discovered that several invalid HTTPS certificates were issued and04:09
micahgrevoked. These were placed on the certificate blacklist to prevent their04:09
micahgmisuse.? that04:09
* micahg shakes fist at xchat04:09
wgrantLet's see.04:10
micahgwgrant: also, which version of chromium?04:11
wgrantmicahg: 11.something04:11
micahgok, so that'll be out next month :)04:11
wgrantSo the dev build.04:11
wgrantAh, Firebug is out now.04:12
* wgrant grabs.04:12
wgrantAh, now we see the problem.04:12
wgrantFirefox just hangs for a few seconds.04:12
micahgwgrant: AJAX related?04:13
wgrantWell, yeah, JS.04:13
wgrantOur JS is crap.04:13
lifelessmicahg: the way that the javascript is created and linked to the rows is extremely expensive04:13
micahgwgrant: if you have a good test case, we can try to get that fixed, performance is a big focus for them04:14
wgrantmicahg: It's really bad JS.04:14
micahglifeless: yeah, but if chromium can do it, firefox should be able to as well :)04:14
lifelessmicahg: when ff gets v804:14
lifelessmicahg: anyhow, its bad for chromium too04:15
micahglifeless: part of v8 is in FF404:15
lifelessmicahg: 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:15
wgrant2.8/3s in addPickerPatcher04:16
micahglifeless: exactly :)04:16
lifelessmicahg: but its not04:16
* micahg was trying to suggest something like that above04:16
lifelessmicahg: its js emitted as literals inline with each task04:16
nigelblifeless: that is the recommended way to do JS04:16
lifelessnigelb: of course it is04:16
nigelblifeless: (but everyone ignores it for code that works)04:17
lifelessnigelb: well, I filed a bug on it04:17
wgrantlifeless: Mmmm, not exactly.04:17
wgrantlifeless: The slow code is not reproduced.04:17
lifelessnigelb: but we have a queue of problems to fix :> - patches appreciated04:17
wgrantlifeless: Each task calls setup_bugtask_row04:17
lifelesswgrant: well, thats a small mercy04:17
wgrantWhich is slow.04:17
nigelbIf I get lp on my system working like ever, I'll help.04:17
nigelbRight now, I fail at getting it working :(04:17
lifelesswgrant: nigelb thats pretty straight forward if you're interested - I run it in a VM04:18
lifelessnigelb: ^04:18
micahglifeless: I'd like to discuss this with you in launchpad-dev in an hour or so if you're still around04:18
lifelessmicahg: sure04:18
nigelblifeless: I might grab you for help sometime then04:18
* nigelb back2work04:18
ScottKlifeless: The package accept page feels snappier now too.  Thanks.04:38
wgrantScottK: And not just because it times out more quickly? :)04:39
ScottKNo.  It's actually working so far (we just hit Beta 1 freeze and I did my first pass through the queue)04:40
lifelessScottK: \o/04:40
* lifeless pokes tongue out at the doubters04:40
ScottKLet's not get too excited too fast.  If I get through Beta 1 with no timeouts, then I'll start to feel good.04:42
lifelessno promises :)04:43
micahgwgrant: OOPS-1910F577, delete packages timeout, I'm updating bug 59052306:04
ubot5Launchpad bug 590523 in Launchpad itself "Archive:+delete-packages times out" [Critical,Triaged] https://launchpad.net/bugs/59052306:04
wgrantmicahg: ppa:ubuntu-security/ppa?06:04
micahgwgrant: yeah :)06:04
wgrantI guess that has a bit of history.06:04
wgrantAnd lots of builds.06:04
micahgyep, should I file a new bug since it's a P3A?06:05
micahgwgrant: update existing?06:05
wgrantmicahg: Yeah, the OOPS ID is useful. Thanks.06:07
micahgand another pg83 bug is made relevant :)06:08
geserlifeless: 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
ubot5Launchpad bug 558907 in Launchpad itself "IArchive.getBuildRecords should optionally filter by series" [Low,Triaged] https://launchpad.net/bugs/55890707:52
lifelessgeser: its timing out because the collection iteration in APIs depends on cheap indexing07:53
lifelesse.g. foo[1000] depends on determining item 1000 cheaply07:53
lifelessbut its not cheap07:53
lifelessif you process incrementally rather than reading all FTBFS for a series, there will be no problem07:53
lifelessand probably be faster too as you'll be doing less cross-network work07:54
geserwhat do you mean with "process incrementally"?07:56
geserlifeless: what do you mean with "process incrementally"?08:07
wgrantgeser: Keep a local cache of builds.08:08
geserwgrant: 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
geserthe script tries to fetch everything only once to avoid the delays from each http request08:14
wgrantgeser: 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
geserI 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
lifelessgeser: ask each package that was a fail, if it has a newer publication08:18
lifelessgeser: if it does, its been fixed.08:19
geserand new uploads that didn't fail previously?08:19
lifelesswalk the failure list - its in order - until you see a date that you saw on the previous run08:19
lifelessunless your script is shutdown for a month, that will be fast08:20
wgrant(I already have code to detect superseded packages)08:20
wgrantIt's still reasonably slow, but not that slow :)08:20
geserlifeless: 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 queue08:24
geserwould that be the "datebuilt" attribute from the "build" object?08:25
lifelessgeser: erg08:25
lifelessgeser: uhm, ok, walk back with 3 days overlap or something:)08:25
lifelesswe really need an api that matches your needs08:25
wgrantThe sort order changes depending on the status you request.08:25
lifelessgeneric programming over high latency links is fail08:25
wgrantAnd the object on which you request it.08:26
lifelesswgrant: failed is in date_created in as far as the ftbfs scripts requests are concerned08:26
geserlifeless: why not get the script (or more precisely the report) directly into LP? with more direct DB access it would probably cause less trouble08:26
wgrantlifeless: Sure?08:27
wgrantgetBuildsByArchIds seems to sort on date_finished.08:27
lifelesswgrant: check the timeout08:27
wgrantlifeless: Is that for Failed to Build?08:28
lifelesshuh, it is finished08:28
lifelessmea culpa08:28
geserto 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:33
geserand I don't miss new records that way?08:34
lifelessfailures are by date_finished08:34
lifelessso you shouldn't miss anything08:34
geseris that in the api?08:34
lifelessis it documented? probably not08:34
lifelessgeser: I'd be happy to do this in-launchpad08:35
wgrantDistroSeries.getBuildRecords orders by date_finished except for NEEDSBUILD, BUILDING, UPLOADED and SUPERSEDED.08:35
lifelessgeser: but as a working [mostly] thing already, working on that is kindof lower priority than all the stuff that isn't working08:35
lifelesswgrant: so what does it do when you get both FTB and NB ?08:35
wgrantlifeless: Huh?08:36
lifelesswgrant: if you ask for both a failed to build and a needsbuild status08:36
wgrantYou can't ask for both at once.08:36
wgrantYou can ask for one or all.08:36
wgrantYes, our API is stupid :)08:36
lifelesswe could just sort by date finished desc null first, date_created08:36
lifelessor something like that08:37
wgrantThat breaks on retries, but retries are broken anyway.08:37
wgrantCOEALESCE(date_finished, date_created) almost makes sense.08:38
geserlifeless: 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
ubot5Ubuntu bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress]08:38
wgrantgeser: datebuild == date_finished. The internal model has changed, while the API remains compatible to avoid breaking scripts.08:39
geserwgrant: UPLOADED == UPLOADFAIL in the API?08:44
wgrantgeser: UPLOADING, not UPLOADED, sorry.08:45
geserbut is it the same or a different state?08:46
wgrantUPLOADING == "Uploading build"08:46
geserok, so the sorting is ok for the cases the script uses08:48
geserwill try to work on the script over the weekend08:49
wgrantThanks. If you need any help give me a yell.08:49
lifelessgeser: thanks!08:50
lifelessgeser: we will need to make the collection faster in LP eventually, but thats likely to be feature level work.08:50
lifelessand we have /////many////// collections to fix08:50
geserhow 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:56
wgrantgeser: 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:57
geserok, so this doesn't cause problems? just the refetching of the data we're still interested in on each run?08:58
wgrantgeser: Retrieving the early parts of the collections is no problem.08:58
wgrantIt's when you're doing stuff like OFFSET 3000 LIMIT 75 that it gets terribly slow.08:59
wgrantBecause it basically has to work out the first 3075, then return the last 75.08:59
wgrantAnd the queries involved are not terribly fast.08:59
geserat which part of the script do such queries get issued? so I understand the problem better09:01
wgrantgeser: Iterating through getBuildRecords.09:01
wgrantThe API limits it to batches of something like 7509:01
wgrantSo it grabs 0-74 in one request, 75-149 in another, and so on.09:02
geserso it's the "for build in series.getBuildRecords(build_state = state):" causing such queries?09:03
geserhow can I avoid that even when I save the data from the previous run?09:04
wgrantYou'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:04
wgrantThe getBuildRecords call doesn't grab everything at once.09:05
geserah, so fresh ones are at the bedinning of the list?09:05
wgrantIt's date_finished DESC09:05
gesernow everything gets more clear09:05
geserwould it be enough to save the date of the last still published build record (for each state)? and skip later ones09:08
=== 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
=== Ursinha-lunch is now known as Ursinha
=== releaselogger is now known as apachelogger
=== aj00200 is now known as aj00400
=== herb__ is now known as herb
=== mnepton is now known as mneptok
bjfsinzui, 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 while21:32
bjfsinzui, is there any kind of schedule when the database gets reloaded ?21:33
lifelessbjf: in theory every week21:36
lifelessin practice possibly 2-3 week21:36
bjflifeless, hmmm, ok could be, i added a project to production about 3 to 4 weeks ago and qastaging doesn't know about it21:37
lifelessit was last synced 14 days ago21:38
lifelessfrom memory21:38
bjflifeless, is this handled by some kind of cron job or is it something someone has to remember to do and do it "manually" ?21:39
sinzuibjf staging was restored on the 13th with data from the 12.21:40
sinzuia cronscript does start the restore, every Saturday, but we are luck when we get to restores a month21:41
lifelessqastaging isn't in cron yet21:41
lifelessstaging is restored weekly21:42
sinzuiI do not think qastaging has ever gotten data since it was setup21:42
lifelesssinzui: yes, it was done a couple of weeks back21:42
sinzuiI use staging's db exclusively for research21:42
bjfsinzui, 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:43
sinzuibjf: qastaging has always has current code. Most users do not care about data. I do because I work with spam and I research user issues21:44
=== matsubara is now known as matsubara-afk
pedroits nice that people form canonical are here22:09
=== 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
