[00:32] * thumper attempts to suspend again [00:33] sinzui: I'm going to work on the moderate thing [00:34] yay, it worked [00:37] thumper: ping [00:37] lifeless: hey [00:37] https://bugs.edge.launchpad.net/launchpad-code/+bug/633758 - can has qa? [00:38] * thumper gets on it [00:38] (oh, and goo dmorning) [00:39] morning [00:39] my talk went well I think [00:41] thumper: cool [00:41] what was it ? [00:41] qa done [00:41] I was giving a talk to second year software engineering students about our development process [00:42] one of the errors last night on BB : bzrlib.errors.InvalidHttpResponse: Invalid http response for https://xmlrpc.edge.launchpad.net/bazaar/: Unable to handle http code 502: Bad Gateway [00:42] a one hour lecture [00:42] ?!? [00:42] thumper: 'we throw stuff at the wall and hope it works' [00:42] thumper: the 502 is probably an edge deploy. [00:42] thumper: I wonder what bzr version it is, that its using edge [00:44] * lifeless waits for https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt to update [00:57] sinzui: is there a list with lots of messags that I can look at the moderation page with ? === Ursinha is now known as Ursinha-afk [01:11] Edwin-afk: / jcsackett: https://bugs.edge.launchpad.net/launchpad-registry/+bug/597738 needs QA for the latest landing (rev 11547) [02:08] thumper: https://code.edge.launchpad.net/~lifeless/launchpad/cp/+merge/35764 [02:08] thumper: No new code, and I've marked up all the user facing / risk mitigating/correcting changes. [02:08] thumper: I'd like to get this through ec2 today to ask for a CP on monday. [04:46] thumper: ping? [04:47] lifeless: hey [04:47] could you tag your review release-critical please? [04:47] (thanks for doing it) [04:49] When's the next release? [04:49] lifeless: so this is part of the "try to release more often?" [04:50] just trying to work out your rationale [04:54] lifeless: my thinking is based around marking it "release-critical" where it clearly isn't just to cross some 'T's and dot some 'I's seems stupid [04:55] if we are changing the process, we should just do it [04:55] and not require this fake stamp just for the hell of it [04:59] thumper: yes [04:59] thumper: I suggest; we do this under the current process, and simultaneously point out that the current process is more onerous than the proposed, approved RFWTAD process [05:00] thumper: and so qa-ok'd stuff gets a free pass for CP's. [05:00] thumper: we'll need to tweak some toolchain stuff though - at least for the moment we *need* release-critical stamps to get past PQM. [05:00] and PQM isn't really setup to check 'has been qa-oked'. [05:00] wgrant: three weeks [05:00] * thumper sighs [05:01] lifeless: so you need the rc to get pqm to land it? [05:01] wgrant: yes [05:01] bah [05:01] thumper: yes [05:01] Hm. [05:01] ok, I'll stamp it [05:02] There are revs in devel that shouldn't go out onto prod, AFAICT... [05:02] wgrant: yes, my branch isn't all of devel [05:02] wgrant: its all the ones passed by the qatagger [05:02] eg. r11552 enabled some unfinished UI on prod. [05:02] The bug doesn't have a tag, so I don't know its QA status. [05:02] wgrant: I'm doing up to and including 11546 [05:03] thats all that has been fully QA'd. [05:03] Aha. [05:03] Everything up to there is fairly sane, IIRC. Sounds good. [05:06] thumper: ping? [05:06] wallyworld: aye [05:06] just want to check something.... [05:07] anyone can submit a merge proposal, right? [05:07] wallyworld: as long as they can see the source and target branches, yes [05:08] ok. there's some ambiguity with some of the comments in a test [05:08] just wanted to confirm, thanks [05:08] i might skype you later if i need to discuss [05:19] StevenK: did you ever figure out that broken test? [05:23] jtv: Which one? [05:24] StevenK: the one you suspected fakelibrarian of [05:24] jtv: I didn't investigate it, sorry [05:25] StevenK: Oh, I thought it was what put db-devel into testfix so I thought it'd be a big thing. [05:32] lifeless: are you familiar with LaunchpadScriptLayer? [05:33] No, but i can be [05:33] why? [05:33] It combines ZopelessLayer and LaunchpadLayer, and adds one thing: [05:33] provideUtility(TestMailBox(), IMailBox) [05:34] There's a 4-year-old XXX from Francis saying it should be registered via ZCML in LaunchpadFunctionalLayer. [05:35] Sorry; the comment says it _is_ registered via ZCML in the LaunchpadFunctionalLayer. [05:35] Anyway, this smells of installFixture to me. [05:36] I was thinking tests that use this could use ZopelessDatabaseLayer instead, and install fixtures for the test mailbox and if needed, the fake librarian. [05:40] (Or if they need the real librarian, they could use LaunchpadLayer—though that provides memcached which I'm not sure scripts are currently supposed to access) [05:41] so [05:41] I'd like to move all our 'layers' to use fixtures, decoupling stuff [05:41] specifically [05:41] lp:python-fixtures [05:41] I need to tweak the API a little more though === poolie_ is now known as poolie [05:47] jtv: 16:41 < lifeless> so [05:47] 16:41 < lifeless> I'd like to move all our 'layers' to use fixtures, decoupling stuff [05:47] 16:41 < lifeless> specifically [05:47] 16:41 < lifeless> lp:python-fixtures [05:49] lifeless: thanks for repeating—my IRC connections are extra-weird today. Yes, fixtures instead of layers would be good. I've gotten used to reserving setUp for that sort of thing—as opposed to the creation of repetitive test data. [05:49] hello jtv! [05:49] hi poolie! [05:49] How's things? [05:50] good; i thought my drive had died but it was just a loose cable [05:50] though it's a bit annoying to lose time to carefully working this out [05:50] Life's little rollercoasters [05:50] I'm _hoping_ I've got a similar problem with my backup drive. :) [05:51] how do i provoke an oops again? [05:51] poolie: do something wrong [05:51] poolie: :P [05:51] poolie: ++oops++ [05:52] ah, and it appears in the comment [05:52] thanks! [05:52] and i see the memcache feature was used! yay [05:52] poolie: it was ? [05:52] oh yes, it will get evaluated [05:52] according to the comment in view-source:https://edge.launchpad.net/bzr/ it was queried [05:52] i don't know if it had any effect [06:00] yes, any page that uses memcache will query it === almaisan-away is now known as al-maisan [06:15] back later === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [08:25] jtv: I have converted the import code but still some tests are failing. [08:25] henninge: what problems are you hitting? [08:26] jtv: let me have a closer look, 'll get back to you in a few minutes. [08:31] jtv: http://paste.ubuntu.com/495141/ [08:31] jtv: I have not yet worked with Karma. [08:31] jtv: Is that something updateTranslation does, too, which I need to do manually now? [08:32] henninge: shall I run you through the conceptual model of karma? [08:32] What's happening here is that the karma we assign has changed a bit [08:32] jtv: that would be nice [08:33] In a nutshell, karma can be assigned in various contexts (somewhat similar to our queue entries, really). [08:33] (only 5 failing tests in lp.translations, btw) [08:33] Additionally, each assignment of karma is in a particular category. [08:34] In the database, you might thus have a karma record that says something like "henning earned 5 karma points today in category marking-a-bug-as-fix-released, for the gim." [08:34] updateTranslation assigns karma. [08:34] It does so in Mysterious Ways. [08:35] ;-) [08:35] I did not try to reconstruct and emulate exactly how, when & what. [08:35] but it is still done by ... sumitSuggestion/approve/... ? [08:35] Instead, we now have a model that's relatively easy to track (see POTMsgSet, though I added an implementation method to POTemplate) [08:35] Yes. [08:36] Well, not "still" since those messages are new. :) [08:36] *methods [08:36] yes, but they are the replacements for updateTranslation [08:36] Off the top of my head, we award 3 kinds of karma: [08:36] * Submitting a suggestion. [08:36] * Reviewing. [08:36] * Having your suggestion approved by someone else. [08:37] jtv: ok, I see two of those in the traceback [08:37] Those are now neatly separated, with rules like "don't assign review/approved karma for someone approving their own translations." [08:37] where are they defined? [08:37] Look for awardKarma in potmsgset.py [08:38] One in submitSuggestion, and two in approveSuggestion. [08:38] Come to think of it, I think I forgot to do that in approveAsDiverged! [08:39] And clearCurrentTranslation. That's review karma for the reviewer, I think (assuming that there really are suggestions). [08:41] ok [08:42] maybe I need to add that. I use approveAsDiverged in the import if the incumbent ;) message was diverged. [08:44] Then that should probably award karma in the same way approveSuggestion does: only if the message was not previously current and the reviewer is not the translator. [08:49] henninge: maybe updateTranslation would be a fit for what you're doing. That also follows the "if it's diverged, and the new translation is not identical to the shared one, keep diverged" rule. [08:50] jtv: oh, I have to add the "is not identical" ... [08:52] jtv: and that is not something "approveAsDiverged" does? [08:52] diverged = suggestion.is_diverged [08:52] jtv: ^ Can a suggestion actually be diverged? [09:04] Hi [09:10] good morning [09:19] henninge: a suggestion can be diverged _in another template_. [09:20] henninge: as for approveAsDiverged: that method is for explicitly diverging a message. It always diverges (except where you're actually trying to set the shared translation as a diverged translation). [09:20] but setCurrentTranslation checks if the current message is diverged and if so, maintains divergence. (Again of course, except if the new translation is identical to the current shared one) [09:27] jtv: I don't like setCurrentTranslations because it expects strings ... ;( [09:28] which is kind of dumb, considering that I already have a message, and msgstr objects and all that. [09:28] that's why I'd prefer using approve [09:28] approveSuggestion [09:28] henninge: shouldn't be that hard to change—it's only used by tests, and other methods that can look up the POTranslation objects. [09:29] I'm not saying you have to use it, but have a look if it serves your needs otherwise. [09:30] jtv: well, "approveSuggestion" is really only a wrapper around setCurrentTranslation [09:30] plus karma assignment [09:31] jtv: So, I guess I don't need to check for divergence - submit suggestion will DTRT? [09:32] submitSuggestion can't [09:33] But I see what you mean—approveSuggestion maintains divergence. [09:34] I do see one other thing that approveSuggestion probably should do: disable a diverged message in the same pofile that may be masking the suggestion. [09:35] It shortcuts the case where the suggestion is already current. It probably shouldn't, though of course not shortcutting does mean that the karma assignment needs a bit of extra care. [09:36] But yes, this means that in principle approveSuggestion is good enough for imports. No need for approveAsDiverged. [10:07] rockstar, https://dev.launchpad.net/LEP/BetterPrivacy, https://dev.launchpad.net/LEP/BugzillaComponents and https://dev.launchpad.net/LEP/BuildFarmScalability all spring to mind [11:26] jtv: I think approveSuggestion may have gotten the Karma handling wrong. [11:26] jtv: this is from the failing test: http://paste.ubuntu.com/495203/ [11:29] henninge: I can see how that's different from what approveSuggestion does, but how is what approveSuggestion does wrong? [11:29] jtv: well, different from documentation == wrong [11:29] ;-) [11:29] This pastebin leaves me with the impression that updateTranslation gets it wrong [11:30] that is possible [11:31] jtv: should a translator not get karma twice -- once for suggesting and once for suggestion being approved? [11:31] a translator, yes [11:31] but if it's the same person approving that same translation? [11:31] That seemed wrong to me. [11:32] jtv: so, what is karma trying to show? [11:32] It is trying to reward people for doing useful things. [11:33] I'm trying to find something wrong with my own earlier reasoning, but not finding anything so far. [11:34] Yes, it does mean that a reviewer can hope to gain more karma from translating in translation mode—_if_ they can get those suggestions reviewed by someone else. [11:34] I don't think that's a bad thing. [11:34] A translator that translates 10 strings that are all approved by a reviewer will get twice as much karma as a reviewer that enters the same translations directly. [11:35] I think that's actually rewarding good behaviour. [11:35] At first glance it seems to increase the risk of those translations staying unapproved. But the author doesn't get the extra karma until they are. [11:36] So a proper, well-motivated karma whore will try to get them reviewed. [11:36] In total, a suggested-approved translation will deal out three times as much karma as a directly-approved will. [11:37] To different people. [11:37] jtv: I am just finding reasons, trying to understand. I am not against your reasoning. [11:37] That's fine. [11:37] So I should update the test. [11:37] I think so, yes. [11:38] BTW dogfood is being upgraded to lucid. It'll take about an hour. [11:39] So far, imported translation would give the uploader "translationsuggestionapproved" karma, now they will get "translationsuggestionadded" karma. [11:39] Are they weighed differently? [11:39] Don't know. [11:40] * henninge consults launchpad_dev [11:42] jtv: http://paste.ubuntu.com/495216/ [11:43] henninge: thanks for digging that up! [11:43] looks like we have some more karma actions ... [11:43] BTW another way of looking at the current karma design is, "karma shouldn't reward people for joining a translation team just to translate." === al-maisan is now known as almaisan-away [12:04] Morning, all. === mrevell is now known as mrevell-lunch [12:14] deryck, good morning [12:26] I'm going to head out to Foyles and see if I can pick up a book on queueing theory === mrevell-lunch is now known as mrevell === matsubara-afk is now known as matsubara === Ursinha-afk is now known as Ursinha [14:41] hello [14:45] does the .dev instance run with multiple request threads? [14:49] bigjools, yes [14:50] salgado: cool thanks [14:51] now I have a fighting chance of re-creating my concurrency issue === almaisan-away is now known as al-maisan [15:05] salgado: do you have any clue how I could write a test case that simulates simultaneous requests in 2 threads? [15:06] bigjools, I think the test suite runs single threaded [15:06] yeah, that's why I asked :) [15:09] bigjools, I guess it all depends on how the test browser works [15:10] jml: I've only ever seen it manage single-threaded stuff [15:11] jml: I've re-created an issue locally where I need to bash the copy button on the PPA copy page as fast as I can [15:11] bigjools, well, I don't know how it works. It might just be that all you need to do is spawn two threads each of which has its own test browser [15:12] bigjools, hmm. [15:12] bigjools, in that case, you might not even need to worry about the test browser [15:12] jml: that's one way but it seems as though it might not be deterministic [15:12] bigjools, you are using threads, kiss determinism goodbye [15:12] that's why I said "simulate" in my original question :) [15:13] bigjools, then what's the problem with spawning two threads and using the test browser? [15:13] bigjools, or, actually [15:13] bigjools, you don't need the test browser, you just need to have instantiated view objects pointing to the same store [15:13] I'm starting to think that a test case is not worth it [15:13] bigjools, hang on [15:13] bigjools, is this for debugging the problem or writing a test? [15:13] a test [15:13] I know what the problem is, I think [15:14] the two transactions don't clash at all, so don't trigger a serialization issue [15:14] but the checks that are made work once one of them is committed [15:14] bigjools, otp [15:14] so I have an evil plan to make them clash some how [15:15] ok [15:32] jml, did you see my LEP? [15:33] rockstar, I saw that it exists. still otp. [15:35] jml, ack. [15:52] bigjools, do you know off the top of your head what times the Walter de Cantelupe is closed on Sundays? [15:54] jml: late [15:54] usually ~11 I think [15:54] but if you're going to be late I'd call and let him know [15:55] bigjools, istr Martin saying that it's closed for some time during the afternoon [15:55] bigjools, I'll be arriving at ~6pm [15:56] jml: I'd call him then, yes it is closed in the afternoons, I can't remember what time it opens [15:56] bigjools, will do. [15:56] bigjools, thanks [15:57] np [16:20] grr. === matsubara is now known as matsubara-lunch [16:42] Do you know what would make most technology better? [16:42] Actually working. === benji is now known as benji-lunch === beuno is now known as beuno-lunch === deryck is now known as deryck[lunch] [17:14] rockstar, I just scribbled all over https://dev.launchpad.net/Code/MergeQueues/LEP [17:14] rockstar, basically adding more details in the requirements. [17:14] jml, great, I'll take a look. [17:20] jml, ah, yeah, most of those details we've already addressed in my notes at https://dev.launchpad.net/Code/MergeQueues but I'm happy to LEPify them. [17:21] rockstar, yeah. I see the notes cover similar ground in story format. [17:21] rockstar, [17:22] rockstar, but I want to get it down in a requirements format [17:22] jml, absolutely. abentley and I were just going over the recipe LEP and reviewing what else needs to be done, so I'm identifying what is important about a LEP. [17:23] rockstar, cool. [17:24] rockstar, also, I'm really keen to see thoughts on the full cycle of any given feature: how do people find out about it; how does one use it for the very first time; how does one know it's safe to try out; what do the inner cycles look like; how does one stop using it? etc [17:24] jml, yeah, and I think we're going to identify much of that with our UI mockups. [17:24] rockstar, agreed [17:24] (I have a list of them I need to do) [17:25] rockstar, it's easy to let UI mockups focus on the inner bits of the workflow rather than a more broad context, so just flagging now [17:26] jml, yeah, I actually like to address the more broad context in UI mockups. They should be a general idea, not the final UI. [17:26] rockstar, also, I noticed on your notes page that you're thinking of having something on the branch page that says the branch isn't managed by a queue [17:26] The final UI gets sorted as you actually implement the feature and find out what works. [17:26] rockstar, for a project that uses feature branches, that's going to be irrelevant for most branches. === salgado is now known as salgado-lunch === matsubara-lunch is now known as matsubara [18:01] * gmb EoWs. Night folks. === benji-lunch is now known as benji === beuno-lunch is now known as beuno === salgado-lunch is now known as salgado === al-maisan is now known as almaisan-away === Ursinha is now known as Ursinha-lunch [19:35] bac: hi, around? [19:36] hi lifeless [19:36] rev 11552 on stable [19:36] I'm not clear if that is ok to deploy to lpnet now, or not. [19:38] lifeless: b/c it is qa-untestable or b/c of pre-requisite branches [19:38] because of the description [19:38] 'show xx on lpnet' [19:38] I don't know if you intend that to wait for the next release [19:38] or if showing it on Monday would be ok. [19:39] lifeless: Monday is great [19:39] ok, cool [19:39] we're not qa'd all the way up to it, but as things move forward... [19:39] lifeless: we should have rolled it in 10.09 but it slipped my mind [19:39] Ursinha-lunch: hiya [19:39] bac: feature flags will help :) [19:39] lifeless: yes, they just weren't ready at the time... [19:42] lifeless: why do you do the endwith test at line 27 of https://code.edge.launchpad.net/~lifeless/launchpad/registry/+merge/35774 [19:43] completeness === EdwinGrubbs is now known as Edwin-lunch [19:43] lifeless: but when would it not pass? [19:43] oh ahh [19:44] thats a bug, I meant to put %3f or whatever in there. [19:44] I'll come back to it, its already in ec2 land - thanks for noticing. [19:44] ok, i wasn't sure if it was a bug or you were doing something clever [19:45] very very clever [19:45] so clever you put a tail on it and call it a ferret === Ursinha-lunch is now known as Ursinha [20:27] lifeless, hi [20:38] Ursinha: hi there [20:38] uhm, /me pages in [20:38] Ursinha: oh right, tagger stuff - how goes it? Anything blocking you? [20:45] lifeless, I'm not blocked on anything right now [20:46] lifeless, more trying to figure out how to solve the mess unique branches for several bugs introduced to the scenario :) [20:48] heh, sorry ;) [20:57] grah [20:57] ec2 fail [20:57] File "./test_on_merge.py", line 50, in setup_test_database [20:57] con = psycopg2.connect('dbname=template1') [20:57] psycopg2.OperationalError: could not connect to server: No such file or directory [20:57] Is the server running locally and accepting [20:57] connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"? [21:55] ok, is the AMI bust or something? [21:56] I'm getting pg not connected errors consistently on ec2land [21:56] mars: ^ [21:56] # Run all tests. test_on_merge.py takes care of setting up the [21:56] # database. [21:56] /var/launchpad/test/bin/py -t ./test_on_merge.py -vv "--subunit -vvv" [21:56] Traceback (most recent call last): [21:56] ... [21:56] File "./test_on_merge.py", line 50, in setup_test_database [21:56] con = psycopg2.connect('dbname=template1') [21:56] psycopg2.OperationalError: could not connect to server: No such file or directory [21:56] Is the server running locally and accepting [21:56] connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"? === matsubara is now known as matsubara-afk [22:51] What is the status of Python 2.6 / datacentre lucid upgrades these days? [22:51] lifeless, help me with something here [22:53] lifeless, latest deployed revision from stable on lpnet was 11515, now the script states it's 11546 [22:54] while True: head -> desk [22:58] Ursinha: heh [22:58] lifeless, no, not funny [22:58] Ursinha: looking at stable branch ? [22:58] deployments.check_status() is returning that revision as latest deployed [22:58] thats right [22:58] production-stable [22:58] its looking at the branch [22:58] its correct; it goes live Monday [22:59] wait, what goes live Monday [22:59] check LaunchpadProductionStatus [22:59] * Ursinha looks [23:00] jelmer: you need to update that page now you've landed your branch on production-devel [23:00] Ursinha: under 'requested cherrypicks' [23:00] lifeless, oh [23:01] so production-stable already has that [23:01] ? [23:01] yes [23:01] ah [23:01] *whew* [23:01] working as designed [23:01] I was about to kill someone [23:01] its not live on the appserver because doing it friday isn't the smartest thing for a big merge like that [23:01] not when we were low-losa to boot [23:02] jcsackett: ping [23:02] https://bugs.edge.launchpad.net/launchpad-registry/+bug/597738 [23:02] thats the next blocking unqa'd commit [23:02] the one for bugs? [23:02] jcsackett: rev 11547 [23:02] jcsackett: but the process looks at a whole bug, not one branch-for-it. [23:03] jcsackett: its qa-needstesting at the moment, if the bugs bits are doing what they should on staging/edge, please qa-ok it [23:03] do that and I will run the script [23:03] i can ping EdwinGrubbs about the branch he landed to QA; the remaining hasn't reached fix-committed yet. Blueprints should be through buildbot shortly. [23:04] jcsackett: 11547 is what I care about right now. [23:04] jcsackett, so it's part of a larger fix? [23:04] in general its a bit odd to do what this bug is doing [23:04] I QAed bugs yesterday and reported bugs. [23:04] sinzui: so should it be qa-bad ? [23:04] no [23:04] it is still an improvement [23:04] so its qa-ok? [23:04] jcsackett: my branch was qa'ed fine. I didn't update the bug since it is is just going back to qa-needstesting when the next bugtask is completed. [23:04] yes [23:05] cool [23:05] EdwinGrubbs: it needs to go to qa-ok to deploy [23:05] EdwinGrubbs: okay, i thought you already had done that. [23:05] otherwise it blocks all commits after it [23:05] EdwinGrubbs, you can tag the bug when your branch lands [23:05] * sinzui found to pre-existing issues that must be fixed to say bridging-the-gap is done [23:05] * jcsackett is confused about the QA process. [23:05] oh, I forgot about that. [23:05] are we not supposed to use needstesting anymore? [23:05] jcsackett: yes, you should. You should also test asap. [23:06] jcsackett, yes, of course :) but you're saying qa-needstesting for a branch [23:06] Wake up, QA [23:06] jcsackett: https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt [23:06] you landed a branch that fixes your bugtask in that bug, that lands, it's marked qa-needstesting for your landing [23:06] notice staging updates QA...QA is the fastest way to unblock the team [23:06] or on edge [23:06] okay, that all jives with what i thought. have caught bits and pieces of conversations today that have left me off kilter. :-P [23:06] jcsackett: I just treated this bug differently since it has multiple bugtasks. I didn't think about how it needs to go to qa-ok temporarily even though it will go to qa-needstesting when the next branch lands. [23:06] because edge runs stable [23:06] We were 3 hours from exceeding our limits 3 days ago [23:07] EdwinGrubbs: I would have done multiple bugs for this thing [23:07] because the work going on in each one is different [23:07] yes, hindsight is 20/20 [23:08] never too late to change ;) [23:09] anyhow yes, this isn't a big issue [23:09] we're changing process [23:09] so we're going to have muscle memory to unlearn and so on [23:09] i'll keep this in mind tomorrow--the blueprints task should be ready to qa then. [23:10] I think the registry team can take ownership of EmailAddress if the foundations team have given up using the table for SSO [23:12] wgrant: please qa https://bugs.edge.launchpad.net/soyuz/+bug/564491 [23:12] wgrant: and https://bugs.edge.launchpad.net/soyuz/+bug/566339 [23:13] lifeless, so I cannot mark that bug as qa-ok? [23:14] Ursinha: I don't know [23:14] Ursinha: hang on, which bug :) [23:14] hehe [23:14]