=== ondrej [n=ondrej@82.208.57.226] has joined #launchpad [12:19] hi there, I seem to have problems with signing new CoC 1.0.1, although signed correctly it is not accepted [12:21] ondrej: what's the error message? [12:22] something about text not equal to CoC text... but one moment, I'll try it right now again [12:23] ondrej: when was it the last time you tried? [12:23] ondrej: today we rolled out a fix for that problem [12:23] yesterday [12:24] confirmed, bug was fixed [12:24] ondrej: it's problem fixed by now. [12:25] ondrej: nice. :) [12:25] just one more (aesthetic) thing, page with listing of signatures on CoC shows whole signed text of CoC on one line [12:26] ondrej: known bug, let me find the number [12:27] ondrej: bug 39995 [12:27] Malone bug 39995 in launchpad "No Line break in CoC active signatures" [Low,Confirmed] http://launchpad.net/bugs/39995 [12:28] thanks, I'll subscribe it; one more thing, I continuosly get subscribed to gnome-power bugs in launchpad, which is quite annoying, and I can't find a reason why... [12:28] nice, CoC bug is fixed? rock on [12:30] ondrej: maybe it's because bug 48860 [12:30] Malone bug 48860 in malone ""Also notified" makes difficult to unsubscribe" [Untriaged,Unconfirmed] http://launchpad.net/bugs/48860 [12:33] I am not sure, I was subscribed to several new bug report; it may be related to my DD part on gnome debian team? [12:33] s/report/reports/ [12:35] and I was able to unsubscribe [12:36] ondrej: oh, I misunderstood you [12:39] ondrej: what's your launchpad name? [12:40] ondrej [12:41] unfortunately I already unsubscribed from all bug reports I was getting mail from and already deleted all email related to that [12:41] if you are unable to find any relation on gnome-power-manager and my username, then let's just postpone it and I will ping this channel again when it happens [12:42] ondrej: now I see, you're the registrant of the gnome-power product, right? [12:44] well, I am not aware of it, but it could have happened in far past [12:45] ah, now I see, I registered gnome-power, propably so I could report a bug [12:46] ondrej: that's probably the cause. everytime someone reports a bug against gnome-power, I think you'll also be notified. bradb could really confirm that. [12:46] could you change it to "Registry Administrators"? [12:47] ondrej: I can't, but I know who can. I'll ask kiko to do it. [12:48] excelent, I was really clueless what was happening :-) [12:54] matsubara, what happens? [12:54] so, ondrej registered gnome-power product some time ago [12:55] kiko: to be able to report bugs against it. He's receiveing lots of bugemails and would like to transfer ownership to registry admins [12:55] that's fine. [01:02] ok, people, it's 01:00 (deep night) here, time to go sleep... have a nice rest of day whatever timezone you are in... [01:11] kiko: do you have time for a drive-by of the Importance perms patch in a few ins? [01:11] s/ins/mins/. also includes a lot of refactoring. [01:17] or anyone else have time for a drive-by? [01:25] hmmm [01:25] not really tonight [01:25] but I can queue it [01:25] do you want it done now? [01:27] kiko: well, i queued it. but tonight or tomorrow'd be ok. [01:27] where's the patch? [01:29] kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/fileChhDb9.html [01:39] hmm , is there no "remove from a meeting" action on the left portlet ? :) === BenC [n=bcollins@debian/developer/bcollins] has joined #launchpad === sivang is working on some spec registeration in LP === jd_ [n=jd@wikipedia/Meanos] has joined #launchpad [01:47] sivang: I could decline it for you [01:48] Keybuk: okay, so please decline the old one that I resubmitted, I want to have distinction betwene the "old" and then edgy plans [01:49] such that we have only the edgy-... one approvd for uds-paris [01:49] which one? [01:49] sec [01:51] actually the other way around. I see so many people sub'd to the original name in LP, I'll leave it for their sake to get updated of what happens with this spec. [01:51] please decline https://launchpad.net/distros/ubuntu/+spec/edgy-home-user-backup [01:51] I will just relink wiki pages instead [01:52] sorry for the hassle ... [01:54] kiko: ping (urgent) [02:12] Keybuk, what's up? [02:12] we need a database field changing in production [02:12] Keybuk, which field? [02:12] UPDATE distrorelease SET changeslist='edgy-changes@lists.ubuntu.com' WHERE name='edgy'; [02:13] and what's the context. [02:13] s'ok, looks like we found a writable user [02:13] Keybuk, cprov already has a patch up for review which allows you to edit that in the web ui btw [02:13] kiko: context is we'd like to upload to edgy without process-upload hitting a NULL :p [02:13] I'm supposed to look at it tonight [02:13] Keybuk, context is "uploading is currently broken" then? :) [02:14] yeah [02:14] s'ok, we monkeyed it :p [02:14] cowboy'd it === Keybuk needs a REALLY BIG stetson [02:16] then I could ride the publisher and go "Yee! Haw!" [02:20] heh, night Keybuk [02:20] I will let you guys fight it out [02:21] right now it's been 12+h on this seat [02:21] and my eyes are melting [02:21] night kiko-zzz === Kylekf [n=Kyle@218.111.183.25] has joined #launchpad [03:42] aha! WE HAVE ACHIEVED TIMEOUT ERROR! [03:42] the ponies are spinning hard, and the hamsters are at full burn! === Kylekf [n=Kyle@61.6.65.122] has joined #launchpad === merriam [n=merriam@84.12.152.175] has joined #launchpad === stub [n=stub@ppp-58.8.6.121.revip2.asianet.co.th] has joined #launchpad === Kylekf [n=Kyle@61.6.65.122] has joined #launchpad === Kylekf [n=Kyle@61.6.65.122] has joined #launchpad === dsas [n=dean@host86-129-18-102.range86-129.btcentralplus.com] has joined #launchpad === nenolod [n=nenolod@gentoo/user/nenolod] has joined #launchpad === nhjm449 [n=nhjm449@cpe-67-9-174-179.austin.res.rr.com] has joined #launchpad [06:53] hi, I would like to know what the procedure is for making a correction to: [06:53] http://launchpad.net/products/audacious [06:53] I'm upstream, and feel that it is described grossly inaccurately (it's displayed as being dependant on GST, when in reality it gets nowhere near GStreamer at this time.) [06:55] (oh, and did I mention I am upstream?) [06:59] nenolod: does the name of the person who registered it mean anything to you? [06:59] Bruno de Oliveira Abinader [07:01] looks like he registered that and bmpx as part of the gstreamer project [07:11] jamesh: no, it doesn't. which is why I am asking here [07:11] ;p [07:11] at any rate those two things should probably be cleaned up [07:11] as they don't make much sense under 'gstreamer' [07:11] well, bmpx does [07:11] sort of, i guess [07:12] but then you'd probably want to put rhythmbox, et al there [07:16] yeah, neither nhjm449 nor myself have heard of this guy [07:16] nope [07:19] nenolod: it would probably be best to send a message to the launchpad-users mailing list [07:19] nenolod: one of the admins can change alter the registrant of the product to you. [07:20] you can then remove edit the product details to remove the link to the gstreamer project in LP [07:20] (it probably doesn't make sense for bmpx to be under the gstreamer project either, btw [07:22] well, I'm not M. Derezynski, so I can't make that call :) [07:22] thanks :) === elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #launchpad [08:06] http://blogs.gnome.org/view/mortenw/2006/06/07/0 <- nice description of bug severities by one of the Gnumeric developers === marcus_notebook [n=mholthau@dz6330fenner-e0.fx-hfc.datazug.ch] has joined #launchpad === glatzor [n=sebi@ppp-62-245-208-121.mnet-online.de] has joined #launchpad === nhjm449 [n=nhjm449@cpe-67-9-174-179.austin.res.rr.com] has left #launchpad ["Leaving"] [09:40] morning all [09:40] where do i find pytz? [09:45] SteveA: did we introduce a new dependency on pytz? [09:52] hi [09:53] it is in zope [09:53] launchpad/zope/src/pytz [09:54] are you getting some kind of failure running launchpad, sabdfl ? === carlos [n=carlos@13.Red-88-15-198.dynamicIP.rima-tde.net] has joined #launchpad [09:57] morning [10:04] hi carlos === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad === doko [n=doko@dslb-088-073-065-191.pools.arcor-ip.net] has joined #launchpad === Fujitsu [n=fujitsu@c211-28-181-26.eburwd7.vic.optusnet.com.au] has joined #launchpad === fiendskull9 [n=clayton@12-201-47-48.client.mchsi.com] has joined #launchpad [11:04] SteveA: yes, failure to run it, no such module as pytz [11:06] sabdfl: i'd like to see the traceback. https://chinstrap.warthogs.hbd.com/~dsilvers/paste/ [11:06] it's strange that you'd get such an error [11:07] also, do you have the pytz symlink at launchpad/lib/pytz ? === ddaa [n=ddaa@george.kkhotels.co.uk] has joined #launchpad [11:19] SteveA: https://chinstrap.ubuntu.com/~dsilvers/paste/file0sgfOg.html [11:19] yes [11:20] to sourcecode/pytz/build/dist/pytz [11:20] which is odd [11:20] i use kiko's utilities/link-external-sourcecode.sh [11:21] and it seems not to have made that link [11:21] kiko-zzz: ? [11:21] i don't have pytz in sourcecode/ === nkvd [i=giggs@62.169.96.16.rev.optimus.pt] has joined #launchpad [11:22] ah [11:22] that's not good [11:22] ah, wait [11:22] you won't have pytz in sorcecode [11:23] it is in zope/src/pytz [11:23] so try symlinking from sourcecode/zope/src/pytz to lib/pytz [11:24] i don't want to overwrite a link in lib/ [11:24] because those are versioned, iirc [11:25] there is something strange going on here [11:25] my link to pytz goes to ../sourcecode/zope/src/pytz [11:25] do you get notice of changed links if you do bzr status in the launchpad tree? [11:26] only lib/pytz which I just modified [11:27] SteveA: this is very recent rocketfuel-get tree, copied over [11:28] i'll grab a new tree and see if something has changed [11:28] mine is only about 4 days old, though [11:28] hmm... [11:28] ok, so i fixed the pytz link [11:28] now i get another weird error with generalform [11:28] File "/home/mark/lptrees/development/meeting-agenda-approvals/utilities/../lib/canonical/launchpad/webapp/generalform.py", line 14, in ? [11:28] from transaction import get_transaction [11:28] ImportError: cannot import name get_transaction [11:28] make: *** [stop] Error 1 [11:29] i have never used the link-external-sourcecode.sh script [11:29] your symlinks are screwed [11:36] sabdfl: it seems like somehow you have an old tree, there's no such import in generalform.py. [11:38] i just got a fresh tree from rocketfuel-get, and the pytz symlink is correct there [11:44] is this correct: /home/warthogs/archives/rocketfuel-built/ [11:44] ? [11:44] ROCKETFUEL="/home/warthogs/archives/rocketfuel-built/*" [11:44] so, yes [11:45] that's from the rocketfuel-get script on my system [11:45] what does bzr info say for your launchpad tree? [11:46] Branch history: [11:46] 3255 revisions [11:46] 716 days old [11:46] first revision: Tue 2004-06-22 05:34:14 +0000 [11:46] latest revision: Sat 2006-03-11 14:54:44 +0000 [11:46] oh [11:46] weird [11:46] let me blow this one away and try again [11:46] Related branches: [11:46] parent branch: sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/launchpad/devel/ [11:46] publish to branch: sftp://chinstrap.ubuntu.com/home/warthogs/archives/stevea/launchpad/devel [11:46] [11:47] that's the part i thought might be wrong [11:47] but yeah, 700 days old... [11:47] oh, mine too [11:47] latest revision from march, though... === stub [n=stub@ppp-58.8.6.121.revip2.asianet.co.th] has joined #launchpad === aimaz [n=swp1@cornelyn.force9.co.uk] has joined #launchpad [12:16] hi [12:32] stub: could I trouble you for a dba approval and patch number, please? [12:32] sabdfl: Sure === manikandan [n=manikand@nat1.maa.collab.net] has joined #launchpad === manikandan is now known as pope [12:34] are there any guidelines on registering a product somewhere [12:34] i wish to register something for which i'm not the original developer [12:35] stub: privmsg === pope is now known as poiueyty === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [12:44] sabdfl: some blueprint love on the way? === jd_ [n=jd@wikipedia/Meanos] has joined #launchpad [12:45] SteveA: trivialities for mdz === jd_ [n=jd@wikipedia/Meanos] has joined #launchpad [01:23] hmm, have all the pages on wiki.launchpad.canonical.com become immutable? [01:23] I can't seem to be editing a spec proposal I've put there, https://wiki.launchpad.canonical.com/DistroPolicyTracker === malcc [n=malcolm@host81-159-193-176.range81-159.btcentralplus.com] has joined #launchpad [01:27] ah, it's okay , my mistake. [01:35] so, err [01:35] Kinnison, cprov [01:35] I appaer to have managed to put something in the pool without it being attached to any particular distrorelease === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:39] Kinnison: ok, slightly more urgent now with a hint of panic [01:39] please be somewhere near a keyboard [01:43] we're at full panic now [01:43] the publisher has been shut down [01:43] hi scott [01:43] so, err, could somebody find kinnison or cprov [01:43] we appear to have a problem [01:43] have you phoned Kinnison? [01:43] his phone went straight to voice mail [01:43] cprov will be here in 15 mins [01:44] thank you [01:44] context: all syncs just went to dapper, and got accepted straight though [01:44] i didn't do anything.. he's due to be here for the launchpad meeting anyway [01:45] Keybuk: Okay, explain === Kinnison had to get lunch, musta been out of signal === cprov [i=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:45] hi cprov [01:45] Kinnison: the sync-queue's process incoming script had a hard-coded dapper in it [01:46] Keybuk: and the policy let it in?! [01:46] so it was shoving syncs directly into dapper, bypassing all policy and checks [01:46] feck [01:46] they're in the pool [01:46] and publishinghistory [01:46] SteveA: hi, good morning [01:46] we appear to only be saved by the publisher not generating new Sources/Packages files for dapper [01:46] Keybuk: Yeesh, fortunately they'll not be in packagesfiles [01:46] which appears to prove elmo wrong, fortunately [01:47] The Packages files were being dsync de-duped which is what confused him [01:47] Kinnison, cprov: i propose you skip the launchpad meeting today to sort this out. [01:47] because edgy was equal to dapper [01:47] SteveA: okay [01:47] SteveA: noted. For reference, I am not up-to-date on daily reports, but I have the info to send out. DONE: prep for and opening edgy, TODO: more edgy related stuff, BLOCKED: no [01:48] Keybuk: care to join ##soyuz1.0 and let's deal with it there [01:48] cprov: your 3 sentences please [01:49] SteveA: so am I, not up-to-date in activities reported: DONE initialise-from-parent-script + fixes for open edgy TODO: open edgy related issues BLOCKED: none [01:51] launchpad meeting in about 8 minutes [01:56] SteveA: I just tried to phone kiko unsuccessfully; is he expected for the meeting as well? [01:56] SteveA: thanks for letting cprov get on this immediately [01:57] kiko just arrived here [01:57] mdz: he should be here very shortly for the launchpad meeting [01:58] salgado: could you ask him to call me so that I can bring him up to date quickly? [01:58] sure [01:59] me [02:00] mdz, I think I know what happened, eh. [02:00] LAUNCHPAD DEVELOPMENT MEETING [02:00] kiko: you are quick [02:00] anyway me [02:00] Welcome to the thursday 8 june launchpad development meeting [02:00] soyuz personnel are firefighting [02:01] who else is here today? [02:01] me [02:01] me === malcc is here [02:01] me [02:01] ddaa sends apologies, as he is traveling back from a sprint [02:01] me [02:01] me [02:01] me [02:01] me [02:01] me [02:01] mpt is on vacation [02:01] me [02:02] i think that's everyone accounted for [02:02] == Agenda == [02:02] * Roll call [02:02] * Agenda [02:02] * Next meeting [02:02] * Activity reports [02:02] * Actions from last meeting [02:02] * Launchpad oops milestone report [02:02] * Sysadmin requests [02:02] * Production and staging (stub) [02:02] ---- [02:02] * (other items) [02:02] ---- [02:02] * Keep, Bag, Change [02:02] * Three sentences [02:02] === ..[topic/#launchpad:SteveA] : WORLDWIDE SOYUZ APPRECIATION DAY | https://launchpad.net/ | developer meeting: Thu 15 Jun, 1200UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Channel logs: http://tinyurl.com/72w39 [02:02] next meeting, one week from now [02:02] any problems with that, speak now [02:02] * Activity reports [02:03] i'm bad again. i have not been formally reporting my activity. who can do better than me? [02:03] I'm up to date [02:03] up to date [02:03] i'm up to date [02:03] up to date [02:03] up to date [02:03] i'm up to date [02:03] I'm up to date [02:03] me too [02:03] me 2 [02:04] I'm not up to date. [02:04] cprov reports he is not up todate [02:04] Kinnison reports he is not up to date [02:04] but has the info to send out [02:04] MeetingAction: Kinnison to send out that info === Kinnison nods [02:04] thanks [02:04] * Actions from last meeting [02:04] i didn't write up the meeting summary, but i have a rough summary here. the actions were: [02:05] MeetingAction: SteveA to write up braindump spec of how we want pqm to output stuff [02:05] which i haven't done. So that's a MeetingAction for this time as well. [02:05] stub to improve the request logging code to cope with UnicodeDecode errors and log stuff [02:05] I saw the bug logged on that but haven't dealt with it yet. [02:05] BjornT: look at fixing __unicode__ of request upstream, user-agent and language headers. [02:06] i didn't do that [02:06] BjornT: do we have bugs filed about this in the zope collector or malone? [02:06] i'll check, i don't think so. i'll make sure one is filed in the zope collector. [02:06] stub: what's the bug number? are you the assignee? is it confirmed? [02:07] MeetingAction: BjornT to get bug filed in zope collector about __unicode__ of request [02:07] (on activity reports, ddaa is not up to date, as he's been in sprint meetings) [02:07] * Launchpad oops milestone report [02:08] matsubara: please go ahead [02:08] SteveA: the bug you're looking for is 47034 [02:08] thanks! [02:08] but 47034 [02:08] the one about the UnicodeDecodeError === Kamping_Kaiser [n=kgoetz@ppp100-144.static.internode.on.net] has joined #launchpad [02:08] bug 47034 [02:08] Malone bug 47034 in launchpad "We should log URLs being processed at the start of transaction" [Medium,Confirmed] http://launchpad.net/bugs/47034 [02:08] Yer - that one [02:08] at least is the one I'm using to keep track of that issue [02:09] so, the oops reports, until yesterday weren't printing the line that triggered the error. Is that a known issue? compare for instance the traceback output in OOPS-156B640 and OOPS-158B395. It seems to be fixed, but I'd like to know for sure. [02:09] https://chinstrap.ubuntu.com/~jamesh/oops.cgi/156B640 [02:09] https://chinstrap.ubuntu.com/~jamesh/oops.cgi/158B395 [02:09] i'm changing it to high importance [02:09] because it stops some people using launchpad entirely [02:10] bug 47034 [02:10] Malone bug 47034 in launchpad "We should log URLs being processed at the start of transaction" [High,Confirmed] http://launchpad.net/bugs/47034 [02:10] good. [02:11] well moving on, jamesh, did you manage to land Steve's tickcount extension that will help us debugging Non-sql timeouts? [02:11] matsubara: i don't see what you mean about comparing those two oops reports [02:11] so, what about the issue of not printing the last lines of the traceback? [02:12] SteveA: the line where the error occurred weren't printed [02:12] matsubara: I didn't have time to work on it this week. Will try and get it into a state where we can use it next week [02:12] matsubara: like: raise WidgetsError(errors, widgetsData=result) ? [02:12] jamesh: thanks [02:12] SteveA: exactly [02:13] that is rather strange [02:13] jamesh, stub: did you land anything that changed that [02:13] ? [02:13] Not me [02:13] matsubara: maybe worth looking at the OOPS .txt files to see if the final line is there in the original [02:14] matsubara: that will see if it is a problem with the formatting cgi script, or the oops generation stuff [02:14] SteveA: the error report code just calls a zope function to format the exception [02:14] SteveA: they're not. I already looked into it [02:14] hmm [02:14] SteveA: has there been any updates to our zope that might have changed things? [02:14] BjornT was looking at updating something in zope [02:14] for the testbrowser stuff [02:15] We are running the old Zope still (Bjorns update of zope.testbrowser didn't go out yesterday) [02:15] yeah, that was only in zope.testbrowser, nothing else [02:15] then it is mysterious. matsubara: mail the launchpad list if you notice the last line missing in future oops reports please [02:15] SteveA: ok [02:15] Fix bug 44872 would help debug xmlrpc exceptions. I'd like to try to fix that one if possible. Who could help me with that? [02:16] Malone bug 44872 in launchpad "xmlrpc should use the OOPS system" [Medium,Confirmed] http://launchpad.net/bugs/44872 [02:16] it's not on a single oops report [02:16] there's lots of them with this problem [02:16] salgado: yes, but as i understand it, they are all before a certain date [02:16] is that so? [02:17] SteveA: yes. that's what I noticed [02:17] well, we noticed it only yesterday [02:17] if we can get a reproducable error that causes a truncated oops, then we can look into it more [02:17] Is it using the standard Python traceback formatter, or something in Z3 to format the traceback? [02:17] something in z3 [02:17] so that it gets the __supplement__ data [02:18] If it is a problem, we could use the standard traceback formatter and log that output too, giving us a baseline to compare with. [02:18] yeah, we can do that. good idea [02:20] it's not just that the last line is missing [02:20] it is that in the newer TB, we get the line of code with each line of TB except when it is in page templates [02:20] and with the older one, we just get the lines of TB [02:20] actually, scratch the "except when it is in page templates" [02:21] so, i don't think there's a bug here in either case [02:21] but somehow we've changed what exception formatter settings we're using [02:21] so, one way to work out what happened is to find the code that controls this [02:21] and see with annotations who changed it and when [02:21] anyway, not a bug, and i see no reason why it should change back [02:22] matsubara: please continue [02:22] Fix bug 44872 would help debug xmlrpc exceptions. I'd like to try to fix that one if possible. Who could help me with that? [02:22] matsubara: re: the missing line numbers info, the only thing I can think of is that the .pyc files for the appserver contained invalid paths for the .py files that [02:22] Malone bug 44872 in launchpad "xmlrpc should use the OOPS system" [Medium,Confirmed] http://launchpad.net/bugs/44872 [02:23] jamesh: good point [02:23] stub: could it be related to the specific app server used? [02:23] e.g. quite possible with the build-tree-then-rsync-to-app-server methodology [02:23] stub: like, if the code was built on one, and then rsynced across to the other? [02:24] jamesh: is there an easy way to "lint" pycs to see if they have correct path info for their sibling py files? [02:24] jamesh: That could happen if our 'make clean' isn't clearing .pyc files, as the .pyc files could have been generated on balleny before the push out and not regenerated on the appserver. [02:24] BjornT: after your current tasks, would you help matsubara with xmlrpc error reporting? === Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has joined #launchpad [02:24] I just checked and our push script isn't excluding them === lincao [n=lincoln@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:24] SteveA, matsubara: sure, i can do that. [02:25] okay [02:25] matsubara: next? [02:25] Our top timeout is at $distroarchrelease/+lang page. kiko, does your work on SQLObject fixes or minimizes that? [02:25] SteveA: it should be possible [02:25] and thanks BjornT [02:26] matsubara: kiko's kinda busy with the firefighting, so move on and kiko will answer later [02:26] matsubara, yes! [02:26] my work does improve that [02:26] it's actually rather broken [02:26] matsubara: that page needs to be using batching [02:26] and there's an API change I can make to avoid querying [02:26] carlos, maybe. [02:26] matsubara: it's near 800KB [02:26] wow [02:27] indeed the bug reported about it says that [02:27] mark is against using batching there [02:27] but I think we MUST do it [02:27] or find a way to cache it [02:27] kiko: the only problem with batching there is that the sort functionality will be lost [02:27] and perhaps represent it in a more compact form [02:27] we could cut down the html [02:27] SteveA: downloading 800KB to load that page is still too much [02:28] yeah, trying to reduce its size would be another option, yes [02:28] we must get a move on [02:28] several more agenda items [02:28] ok, I'm done. Thanks guys. [02:28] but I think the problem is the amount of links we have there [02:28] thanks matsubara [02:28] And any unbatched page is a bug waiting to happen unless we have a max number of items that can possibly be displayed. [02:28]