[00:57] man, where did the day go [00:58] lifeless: good question [00:58] hello lifeless, mwhudson [00:58] poolie: i've gotten a bit confused, sorry to say -- do you want me to land your mbp-trivial branch? [01:01] i'd like someone to do it [01:01] i don't think i have the right to land myself atm [01:01] * thumper -> modaks for lunch [01:01] are you in ~launchpad? if so you should modulo someone putting your key in pqm [01:02] which is a simple losa request :) [01:02] poolie: i'll land it then [01:02] * poolie looks [01:02] also, landing is kind of a many-roundtrip thing [01:02] and it seems to mess up my "i'll spend one day on launchpad" plan [01:03] yeah, I can get that [01:03] well, if you get in the position that you can run ec2 land yourself it's a lot easier [01:03] but yes [01:03] happy to do for you in general, just noting that policy wise, you should be allowed [01:03] i realize it may be partly my fault but the mean latency is somewhere over 24h [01:03] s//well over [01:04] thanks [01:04] just got a "thankyou" mail for bzr, specifically for mgz [01:04] and also for gnukeyring [01:04] what a nice way to start the week [01:04] btw i'm sure this landing latency will get better [01:06] i was saying to jml the other day that one thing i miss least from the days of officially being a launchpad hacker is the battle to land branches [01:06] I've figured out why we get N running librarians [01:06] poolie: your branch is playing in pqm now [01:06] mwhudson: you're now doing that what, 50% of the time ;P [01:06] we get N running librarians because: [01:06] - we use atexit (which isn't what you might think it is) [01:06] lifeless: only when cody-somerville is being slow at reviewing branches [01:07] - the existing kill-stuff code looks in $root/librarian.pid [01:07] - we rm -rt $root [01:07] s/rt/rf/ [01:07] mwhudson: oh, so your soyuz-skin is going into a different tree? [01:07] or you're working on this bash stuff? [01:07] * lifeless twists the knife [01:07] * mwhudson goes for a walk in the sun instead [01:08] mwhudson: I am genuinely interested in the soyuz skin project, its very unclear to me where its at. [01:08] lifeless: yes, a fair bit of bash hacking [01:08] lifeless: i think "a bit stalled" would be the current summary [01:08] lifeless: salgado would know more than me [01:08] back in a bit [01:09] heh, how can anyone not be in ~launchpad-users? :) [01:09] kk [01:09] (i realize it's a list) [01:09] i am in ~launchpad [01:09] we could add new accounts to it automatically [01:09] can i send a mail or should you? [01:09] an RT, i mean [01:09] then they would get a prompt to subscribe straight away. [01:09] poolie: you should; usual thing. [01:10] k thanks [01:17] oh yeah, I know where the day went. daylight savings. [01:17] nz is UTC+13 now [01:19] and with my typical early start [02:05] 5 files changed, 60 insertions(+), 85 deletions(-) [02:05] \o/ [02:16] mwhudson: and here is your monday present https://code.edge.launchpad.net/~lifeless/launchpad/test/+merge/36674 === _thumper_ is now known as thumper [02:34] Afternoon. Can access the blueprints on a project from the API? [02:34] hi michaelh1, i think you can [02:35] uhh [02:35] I thought blueprints didn't have an API at all? [02:35] i don't think blueprints are _very_ exposed [02:35] :) hi mwhudson! [02:35] hi beuno [02:36] poolie: I see there's a 'specification' object in the API docs but no 'specifications_collection' on a project [02:36] james_w put them up on the API [02:36] they are probably still quite vestigial [02:36] certainly, there is a lot of permission-by-view in the blueprints code, so i really hope those bits aren't exposed [02:36] probably it is [02:36] acid test on whether stallman was right about needing passwords [02:37] seems like the only bit that's exposed is for linking/unlinking branches and specs, probably for ajax love to that feature? [02:37] mwhudson: I think that's what was blocking that branch from being merged, last I saw it was still a work in progress [02:37] mwhudson: That was my vague recollection, yes. [02:38] michaelh1: you can ask the linaro infrastructure team to work on this if you like :-) [02:38] mwhudson: but they might go blind :P [02:38] mwhudson: I might do. I'm looking for some type of meta blueprint that has others attached to it. The current Launchpad UI makes this hard to navigate [02:39] lifeless: I would say "it's not that bad", but then again it's why I didn't go any further with it :) [02:39] ajmitch: its primarily a) old and b) unmaintained. [02:39] c) pointless [02:39] both of which don't really lend themselves well to having someone jump in & do a few fixes [02:39] its currently unique in LP [02:40] lifeless: Howso? [02:40] I have sympathy for the view that blueprints and bugs should be facets of one thing; but at the moment thats the way it is [02:40] wgrant: ^ [02:40] lifeless: How is it unique? [02:40] wgrant: dependencies primarily [02:40] Ah. [02:40] Yes. [02:40] also some of the reports [02:41] It also shells out to dot. [02:41] I died inside when I saw that. [02:41] on page view? [02:41] Yes/ [02:41] oh my [02:41] old skool [02:42] Very [02:42] I bet that won't fall under the 99% rule very easily [02:42] for rendering? [02:42] mmm separate resource I think; also deleted nw. [02:42] ok [02:42] (At least, i think it was deleted) [02:43] I didn't think it was deleted. [02:43] Maybe the full project overview thing. [02:43] * ajmitch woudl think it could take awhile to do if it was a large graph of blueprints, and that page hadn't been hit recently [02:43] https://blueprints.edge.launchpad.net/soyuz [02:43] fortunately it's also totally unreadable when there are a lot of blueprints [02:43] Launchpad also doesn't know how to capitalise its own name, apparently. [02:44] wgrant: that's amusing, given how https://blueprints.edge.launchpad.net/launchpad-project links to it [02:45] Indeed. [02:46] The blueprint listing reminds me of the good old days. [02:46] Of the really old 2005-ish theme. [02:46] that was stylish [02:46] hey [02:46] at least compared to the ubuntu bugzilla :) [02:47] anyone know how to get buildout working outside of LP? [02:53] lifeless: svn cat > bootstrap.py; python bootstrap.py [03:02] the branch is blocked on making the model safe to expose [03:03] I have a partial branch to do that, I think the main thing before it can be reviewed is some permission checks which involve moving some code from security.py to the model [03:06] mwhudson: I meant in zope.testing specifically [03:28] mwhudson: this is what I was meaning: [03:28] http://pastebin.com/Q2KbG7rs [03:29] oh, that problem - I ran into that in the weekend & didn't go any further [03:29] lifeless: that looks odd [03:29] mwhudson: this happens every time I attempt to use buildout. [03:29] mwhudson: I've a pretty firmly entrenched opinion now. [03:29] there are some arguments you can pass to bootstrap i think... [03:30] lifeless: this is why I was complaining in #nzpug this morning about buildout :) [03:30] it trying to write to /usr/local is spectactularly naughty. [03:30] lifeless: bootstrap.py --eggs=eggs maybe [03:31] mwhudson: this isn't in the LP tree, I don't see why that would help ? [03:31] lifeless: i think this will make it install eggs in a directory called 'eggs' [03:31] its finding my existing setuptools deb package, then going nana [03:31] lifeless: rather than /usr/local [03:31] mwhudson: ah, interesting. [03:31] lifeless: i'm cargo culting, clearly, but try it [03:31] sure [03:32] I probably shouldn't be so negative about it [03:32] except that it seems to be a net time consumer [03:33] i have mixed feelings about buildbot [03:33] when it works, it's quite ok [03:33] when it doesn't, it's ****ing mysterious at times [03:33] robertc@lpdev:~/zope.testing$ python ./bootstrap.py --eggs=eggs [03:33] Error: Invalid option -- [03:33] um [03:33] i meant buildout there [03:33] although both statements are accurate [03:34] !? [03:34] mwhudson: spectacular [03:34] :) [03:35] $ python ./bootstrap.py bootstrap --help [03:35] Getting distribution for 'distribute'. [03:35] ... [03:35] see under 'above failure' [03:35] maybe the bootstrap.py in the zope.testing tree is very old? [03:35] http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=error+%2Fusr%2Flocal%2Flib%2Fpython2.6%2Fdist-packages%2Fsetuptools-0.6c11-py2.6.egg-info%3A+Permission+denied === nigelbabu is now known as nigelb [03:36] its not an unknown thing :) [03:36] yeah i tried that too :) [03:38] I think this is a sign that I should migrate my lappy to maverick too [03:38] so, I shall. [03:39] Beware the wallpaper. [03:39] wgrant: Doom3 >> all other. [03:40] Hm? [03:42] I've not had a default wallpaper in many many many years [03:42] my desktop does, so I already know what the mav paper looks like. [03:43] Ah. [03:43] i see my desktop about once a month [03:44] I occasionally empty a workspace, and then am blinded. [03:46] the moire on my 1600x1200 crt is quite spectacular === almaisan-away is now known as al-maisan [05:19] wheee wow dpkg is slow these days. [05:19] fsync for the -pain- [05:19] [on ssd no less] === al-maisan is now known as almaisan-away [06:31] https://bugs.launchpad.net/bugs/648504 has a complaint about the dupefinder being too tight now [06:31] <_mup_> Bug #648504: exceptions.NotImplementedError: should resend request to http://feeds.edge.launchpad.net/bazaar/, but this isn't implemented [06:31] i realize it's a tradeoff === almaisan-away is now known as al-maisan [06:37] What would be magic would be some sort of "yes this traceback and version match (and this traceback isn't a symptom of multiple separate bugs)" dupe-matching. [06:37] But there's a fair bit of handwaving involved in describing exactly what would be awesome there :) [06:44] spiv: apport does that. [06:44] The retracers compare stack traces and dupe bugs as appropriate. [06:44] wgrant: not exactly [06:45] Right, after I've either filed my bug or, as a reporter, decided one of the suggested bugs is probably the same even though I'm not a developer and hardly qualified to know. [06:46] It has been argued that the dupefinder should be disabled for crashes, since the retracers can match them much more accurately. [06:46] I've been regularly asked by Launchpad recently to judge if random Xorg crash reports from other people with vaguely similar laptops are the same as mine, whic his a bit erid. [06:46] s/erid/weird/ [06:46] Almost as weird as that typo! [06:46] Yeah, that would make sense to me. === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === poolie_ is now known as poolie [08:00] mwhudson: did you see the oopses for the recipe branch build? BuildFarmJob without specific_job. [08:00] (See the launchpad-dev list.) [08:01] jtv: You sure it was a recipe build? [08:01] wgrant: BuildFarmJob.job_type == 3 [08:01] That's a RECIPEBRANCHBUILD, according to my map. [08:02] Ah. [08:02] That kind of BuildFarmJob. [08:03] Errrrrrrr. [08:03] Hwhat? [08:04] Oh, wait, misread. [08:04] Fail. [08:05] Is there a packagebuild with build_farm_job=1977174? [08:06] Is anyone here familiar with how pip interprets package versions? [08:06] I know just enough to not drown. What's the issue? [08:08] wgrant, sent you pm since its offtopic [08:40] good morning [09:03] does the lp webapp have a default log file in production? [09:07] good morning [09:07] hi bigjools [09:07] bigjools: morning / evening [09:07] hi jml ? [09:08] * bigjools has too much email [09:10] Morning bigjools. [09:10] hello William [09:11] Hello [09:11] morning mrevell [09:12] bigjools: Ubuntu wants ubuntu-release to be able to accept from UNAPPROVED in the Release pocket, and ubuntu-sru from UNAPPROVED in Proposed. Do you have any objections to extending queue admin perms to include optional pocket and status restrictions? [09:13] wgrant: provided I see a bug filed with a comment from Colin, that's fine [09:13] bigjools: Great, thanks. [09:14] wgrant: however I don't want those values hard-coded [09:14] I guess we can do it through ArchivePermission [09:14] bigjools: Certainly not. I'll just extend ArchivePermission to have upload_status and pocket fields. [09:14] Like we do with components already. [09:14] cool [09:14] yay for nullable FKs [09:48] hello everyone. [09:57] morning jml [09:58] bigjools, hi [09:59] jml: did you do any more work on the tests over the weekend? [09:59] bigjools, fwiw, I didn't get around to buildd-slavescanner.txt. I got fed up with having to do that TwistedLaunchpadZopeless dance so I started work on Deferred support for testtools. [09:59] bigjools, and then my batteries ran out. [09:59] heh [09:59] you need to run powertop [09:59] bigjools, I wanted to land a branch that killed buildd-slavescanner independently of the refactoring [09:59] bigjools, I do so from time to time [09:59] something's screwing you over [09:59] bigjools, I think it was Chrome, actually [10:00] npviewer.bin? [10:00] no, I don't think so. [10:01] :( A power problem not caused by Flash? [10:01] jml: ok did you figure out those adaptation errors? [10:01] bigjools, no. just focused on buildd-slavescanner [10:01] ok [10:01] bigjools, only had 90mins of hacking time :) [10:01] so you didn't change any of the builderslave-resume branch? [10:02] (which appears to be the new integration branch!) [10:04] bigjools, I'll push up what I've got. [10:04] bigjools, I don't think I did. [10:04] ok [10:04] I will spend the next million hours reading email then get back to that branch [10:19] yay upgrade glitches [10:21] lifeless, yay indeed. [10:23] * bigjools WTFs at the wtf bug tag [11:24] StevenK: will i-f-p skip disabled arches? [11:25] stub, will -vvv on ./bin/test also give transaction debug messages? [11:26] jml: Doubtful - I don't think test runners can use the python logging module as that is being used by the tests they are running. [11:26] stub, cool. checking since we run w/ -vvv on ec2. [11:26] bigjools: Doubtful, since that didn't exist when I was working on it. [11:27] stub: jml: You could sensible capture debug messages to a detail. [11:27] * lifeless crashes completely. [11:27] StevenK: ok can you add it to the list please, it's critical to get fixed before natty [11:27] Do we have a rollout before natty? [11:27] Doesn't the current i-f-p stuff live in db-devel? [11:28] we don't have a db rollout [11:28] lifeless, jml: Yes. We could make bin/test add a handler to getLogger('txn') that emits messages where we want, although we might have to reset it after every test in case the test tore things up. [11:28] stub: not bin/test - use a Fixture and register it with self.addDetail. === jtv is now known as jtv-afk [11:29] wgrant: No [11:29] bigjools: Right, I'll sort it out tomorrow [11:29] StevenK: Ah, good. [11:29] StevenK: thanks - I'll add a card now [11:29] It should be quite quick [11:29] stub, I think lifeless is talking about the facility in TestCase where you can add details to test output in response to certain events (generally exceptions) [11:29] * wgrant pokes at apt-ftparchive. [11:30] * bigjools gets caffeine [11:30] Right. We could do it, but we haven't done it :) [11:31] bigjools: It can be worked around with application of -a [11:31] As it emits a log message when the transaction starts, this might be useful for tracking down code that holds open long running transactions which can be sucky (such as the transaction being opened by Storm refreshing a property...) [11:35] Gnargh lucilleconfig kill kill. [11:35] Oh wtf. [11:39] bigjools: We need to stop creation of new arch-indep publications before maverick, or we'll need to do some manual cleanup before maverick gets changed to CURRENT. [11:40] Since we need p-d-r to remove all the files. [11:41] wgrant: gnar [11:42] Hm, except that p-d-r doesn't obviously respect the Release pocket freeze, so it might be OK to have it remove them afterwards. [11:43] I'd rather it worked now [11:45] At least there appear to only be two places that create arch-indep publications. [11:47] So, fix those two locations, tweak lucilleconfig to exclude disabled DASes, Delete existing publications, and we may be able to get maverick into a sane state. [11:47] I think. [11:50] Has the on-disk archive ever been compared with what Soyuz thinks should be there? [11:50] not to me knowledge [11:50] my* [11:52] p-d-r looks buggy, so I suspect there's a lot of cruft in the pool. [12:06] Morning, all. === jtv-afk is now known as jtv [12:16] deryck, good morning [12:19] wgrant: fyi, I just filed bug 648715 [12:19] <_mup_> Bug #648715: Binary publications should not be created for disabled architectures [12:33] Okay, I know that I know the answer to this, but I can't remember what it is for the life of me: "psycopg2.InterfaceError: connection already closed" <-- what is that and why is it happening? Any ideas? [12:35] gmb: Your PostgreSQL may be in recovery mode. [12:35] Check its logs. [12:37] Hm, no, that's a different thing. [12:48] wgrant, It is a pg problem though; make schema is blowing up. I'll dig into it further. Thanks for the pointer anyway. [13:07] danilos, hi [13:07] jml, hi [13:08] danilos, marjo has asked for a feature along these lines: "Enable translators working in Launchpad to seamlessly submit those translations to the upstream project to which they apply. " [13:08] danilos, I thought we did that already. [13:09] jml, well, "seamlessly" is very hard... that's next on our list after we've got the "seamless" imports going [13:09] jml, ("next on our list" if we are to continue on our bridging-the-gap theme for translations) [13:09] jml, what we've got know are partial tools that enable people to do lot of that work manually [13:09] s/got know/got now/ [13:10] * bigjools notices the EINTR bug that poolie fixed and doesn't know whether to laugh or cry [13:10] danilos, you guys are working on smoother imports now? [13:11] jml, "seamless" would be to have a button saying something like "submit these translations upstream" where they'd get into the upstream workflow for handling translations [13:11] jml, well, it's more like "we are still working on that" [13:11] jml, it's been going pretty slow [13:11] jml, "smoother imports" is getting translations directly from upstream into ubuntu [13:12] danilos, with what degree of interaction from users / admins? [13:14] jml, two differing steps: 1. get upstream translations into LP upstreams (requires code imports and admin interaction for now, but already possible); 2. set up packaging links between upstream series in LP and Ubuntu sourcepackages [13:14] jml, for 1, we want to improve the process further once we have the groundwork laid out to support actual sharing of translations between ubuntu and upstreams [13:15] danilos, I think Registry has done a lot of work on making code import, project registration & linking easier. Not 100% sure about series branches specifically. [13:15] jml, 1. already works for a wide range of intltool- and gettext-based upstreams, but requires admin set-up which is not nice [13:16] danilos, admin set up per package? [13:16] jml, I know, they are doing a good job with splitting the "official_*" tags as well [13:16] jml, in general, for translations it's pretty simple to set up so we just need to follow the same pattern and come up with good privilege models [13:17] jml, basically, set-up for translations should only include "this has external translations, IMPORT THEM" and "link the series with sourcepackage" [13:17] jml, "link the series" step is pretty nicely handled by registry folks already [13:17] cool. [13:18] jml, though, it'd be nice to integrate into one step if someone's interested in doing it all in one code (i.e. integrate set-up code branches, turn the translation imports on, link to source packages steps) [13:19] s/in one code/in one go/ [13:19] typing ahead of me :) [13:19] danilos, I guess there are two potential issues with having them split up: multiple POSTs, and users not necessarily knowing what the next step is [13:20] jml, well, there's always ajax, and there's always code-reuse :) if we make those bits of pages nice reusable ajaxy "portlets" (not necessarily in zope sense, but just bits that can be plugged into other pages), it would make a nicer experience without increasing our workload too much [13:21] jml, fwiw, some of these things might already be easily reusable, I haven't looked [13:21] danilos, you said there's some ground work that needs to be done. I had thought you'd already done it. [13:21] * jml nods [13:21] jml, well, we've got a huge feature branch in progress that I said is going slower than expected: that's to actually get upstream translations shared with Ubuntu directly [13:22] jml, we are nearing completion of that bit, but likely not this cycle after all [13:22] danilos, I understand :) huge feature branches being what they are. [13:24] danilos, with the other side, sending translations upstream seamlessly -- is there any reason to *not* do it after you've done the inbound direction? [13:26] jml, not really, it's just a lot of work because many upstreams will have differing needs... but we should attack it in a similar way, go for big "easy" upstreams first (gnome, kde, translationproject), then for big "hard" upstreams (mozilla, openoffice) and so forth [13:28] danilos, cool [13:28] danilos, it's rather nice that our broader plans happen to mesh with what Ubuntu says they need :) [13:29] jml, yeah, I am very happy with that as well :) [13:35] danilos, thanks for your time. I'll let Marjo know our current plans. [13:37] jml, cheers === mrevell is now known as mrevell-lunch [14:17] flacoste! [14:17] hi jml! [14:17] flacoste: welcome back :) [14:17] hello fellow launchpadders! [14:17] Hey! Welcome back flacoste [14:18] hi noodles775! are still a launchpadder ;-) [14:18] or did you move on already? [14:18] not that I wouldn't greet you if that was the case :-) [14:18] heh, yep - will be switching sometime soon, but just working on some soyuz UI work beforehand. [14:19] (And I'll still be here on #launchpad-dev anyway) [14:21] hey flacoste, flumper will be pleased to see you :) [14:21] bigjools: yeah, he told me that he was looking forward to give me my job back! [14:21] you guys gave him a hard time? [14:22] depends who "you guys" is I guess :) [14:24] hey wb flacoste! [14:25] hi deryck! [14:31] bigjools: Disabling an arch is somewhat problematic. If you disable it (to prevent new publications) then mark its publications deleted, it never gets published to actually remove them. [14:31] /o\ [14:31] grar [14:31] But I suppose we won't be doing this until powerpc dies in at least a couple of releases. [14:32] ? [14:33] bigjools: We shouldn't be disabling another DAS until powerpc dies. And that will be a while. [14:33] And sparc/ia64 need manual cleanup anyway, so it's not too bad. [14:33] ok [14:33] right [14:33] Hmmm. === mrevell-lunch is now known as mrevell [15:00] buildout question: is there a way to leverage buildout someone to build against package versions available in a particular release to make sure the code will work on that release? [15:04] huh? [15:06] sinzui: you around? [15:06] I am [15:07] sinzui: there have been some requests about blueprints on the stakeholder list. I have this feeling that you're the right person to talk to to get a sense of difficulty of implementation [15:07] jml :( Am I really the last remaining engineer to have hacked on blueprint? [15:08] sinzui: I don't know! You just have a blueish tinge to your aura. [15:09] I can help. I am pretty knowledgeable of the bug reports that often underly a blueprint feature request [15:09] sinzui: cool. [15:09] sinzui: what we want, probably, is easy ways to get a list of blueprints that are assigned to members of a given team [15:11] That sounds a lot like my proposal to find the intersection of items assigned to a team for a milestone. I really would like a common way to say I want to see the items for the members of a team for any structure [15:11] jml: what that "huh" for me? [15:12] sinzui: yes, that would be ideal. [15:12] cr3: I guess when you say "release" you're talking about something other than a release of Launchpad. [15:12] jml: sorry, yes, I meant release of Ubuntu [15:13] cr3: the whole point of buildout is that you are insulated from the underlying OS. [15:13] cr3: well, maybe that's the whole point. [15:13] jml: that is indeed a point but I figured it would also be used to couple with a particular OS [15:14] jml: for example, I happen to used a dependencies branch from where buildout can only get dependencies, nowhere else. I use this as a snapshot of what is known to work, rather than relying on the latest code. I believe launchpad does the same under source-dependencies or somesuch [15:16] jml: however, if that list of packages were taken from the release of an OS, that would provide somekind of predictability that it should work on the OS. the problem with that is that: 1. the orig.tar.gz files on archive.u.c are named funny; 2. those files are also not quite what's on the release of the OS. [15:16] jml: so, perhaps another approach would be to bzr branch lp:ubuntu/release/dependency instead of using tarballs [15:17] jml: I was hoping this was already attempted by someone so that I could learn from their experience rather than wasting time myself finding out there's a real problem [15:21] cr3: perhaps. you might also want to ask on general zope channels. [15:30] abentley, jelmer: where are we at with being able to import non-master git branches? [15:31] jml: it's not something I've been following. [15:32] abentley: np. just picking on you as a visible code team member :) [15:33] jml: the issue is that bzr-git is tied into the standard Bazaar branch behaviour, and that doesn't support colocated branches. [15:33] jml: so someone from the Bazaar team could update you on colocated branch support. [15:34] abentley: ta. I'll mosey on to #bzr. [15:52] *sigh* [15:52] I wish I had a notification system that would ping me -- "the builders are up and green. go for it! now!" [15:54] Don't worry, there's still gambling involved -- if you're lucky we'll be in testfix again by the time EC2 finishes :) [15:54] heh [15:55] My statement presumed I had already had a couple ec2 failures and was prepared to go to pqm directly. [15:55] Ah. [15:56] Thus ensuring that the cycle continues. [15:56] maybe. In this case, I had a translations windmill test that failed in ec2, and I ran locally with no issues. So submitted directly. === deryck is now known as deryck[lunch] [16:02] sinzui: hi [16:02] hi jml [16:08] deryck[lunch], it might be a test that could be helped with a longer timeout somewhere for ec2 runs, it's useful if you file a bug so we can look at it and close it as 'invalid' because we can't reproduce it... I mean, perhaps increase a timeout for a page load or two if it's a clear-cut case like that === Ursinha is now known as Ursinha-lunch === salgado is now known as salgado-lunch [16:33] noodles775: do I remember wrongly, or were you looking at generic comments code recently? [16:33] jml: Yes I was. [16:34]