All times are UTC.
00:03:05 <-- arlolra has quit (Client exited) 00:12:58 <-- micahg has quit (Ping timeout: 121 seconds) 00:25:48 --> BWMerlin has joined #instantbird 00:30:26 <-- myk has quit (Ping timeout: 121 seconds) 00:33:09 <-- mconley has quit (Connection closed) 00:40:50 <-- AlexanderSalas has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 00:41:03 --> AlexanderSalas has joined #instantbird 00:55:04 <-- AlexanderSalas has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 00:55:13 --> AlexanderSalas has joined #instantbird 01:25:32 --> Widders has joined #instantbird 01:27:49 <-- Suiseiseki has quit (Ping timeout: 121 seconds) 01:28:13 <-- clokep has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 01:28:46 <-- Widdershins has quit (Ping timeout: 121 seconds) 01:43:18 --> Suiseiseki has joined #instantbird 01:50:52 --> myk has joined #instantbird 02:20:09 --> mconley has joined #instantbird 02:29:48 <-- mconley has quit (Connection closed) 02:35:37 <-- myk has quit (Ping timeout: 121 seconds) 02:54:10 <-- Widders has quit (Quit: Leaving) 02:54:18 --> Widdershins has joined #instantbird 03:16:58 --> mconley has joined #instantbird 03:30:37 <instant-buildbot> build #1355 of linux-nightly-default is complete: Failure [4failed compile] Build details are at http://buildbot.instantbird.org/builders/linux-nightly-default/builds/1355 03:50:42 <instant-buildbot> build #1680 of win32-nightly-default is complete: Success [3build successful] Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/1680 03:52:20 <-- mconley has quit (Connection closed) 04:47:17 <instant-buildbot> build #2613 of macosx-nightly-default is complete: Failure [4failed shell_5] Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/2613 04:47:43 --> mconley has joined #instantbird 04:51:25 --> nhnt11-tb has joined #instantbird 04:51:34 <-- nhnt11-tb has quit (Client exited) 04:52:24 <-- AlexanderSalas has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 04:52:29 --> AlexanderSalas has joined #instantbird 04:54:47 --> nhnt11-tb has joined #instantbird 04:57:55 <-- nhnt11-tb has quit (Client exited) 04:58:32 --> nhnt11-tb has joined #instantbird 04:59:33 <-- nhnt11-tb has quit (Client exited) 04:59:52 --> nhnt11-tb has joined #instantbird 04:59:56 <-- nhnt11-tb has quit (Client exited) 05:00:49 --> nhnt11-tb has joined #instantbird 05:01:01 <-- nhnt11-tb has quit (Client exited) 05:01:23 --> nhnt11-tb has joined #instantbird 05:01:25 <-- nhnt11-tb has quit (Client exited) 05:01:33 --> nhnt11-tb has joined #instantbird 05:01:35 <-- nhnt11-tb has quit (Client exited) 05:02:06 --> nhnt11-tb has joined #instantbird 05:02:23 <nhnt11-tb> Okay, so I've written code that clears out all the bad entires 05:02:52 <nhnt11-tb> Seems to work well 05:03:08 <nhnt11-tb> this is wrt gloda if that wasn't obvious :) 05:04:37 --> Mook has joined #instantbird 05:04:49 --> myk has joined #instantbird 05:05:11 <nhnt11-tb> I'm using synchronous statements right now, I'll change those to async. Then some error handling, and a cache version to trigger (or /not/ trigger) the process 05:05:23 * nhnt11-tb wants to get this done today 05:08:56 <nhnt11> Damn, should have backed up my "bad" profile to keep testing new versions of this... 05:10:00 --> mpmc has joined #instantbird 05:42:23 <-- nhnt11-tb has quit (Ping timeout: 121 seconds) 06:06:00 <-- myk has quit (Ping timeout: 121 seconds) 06:15:09 <-- mconley has quit (Connection closed) 06:19:18 --> Even has joined #instantbird 06:19:19 * ChanServ sets mode +o Even 06:19:27 <-- Even has quit (A TLS packet with unexpected length was received.) 06:19:52 --> Even has joined #instantbird 06:19:53 * ChanServ sets mode +o Even 06:27:00 --> myk has joined #instantbird 06:37:03 * nhnt11 will be back later 06:37:53 <nhnt11> BTW, I set up a bouncer and so will always be online except when my VPS is down 07:13:21 <-- myk has quit (Ping timeout: 121 seconds) 07:26:13 <instant-buildbot> build #267 of linux64-nightly-default is complete: Failure [4failed compile] Build details are at http://buildbot.instantbird.org/builders/linux64-nightly-default/builds/267 07:34:52 --> Bollebib has joined #instantbird 08:12:20 <-- Tonnes has quit (Connection closed) 08:17:51 --> Tonnes has joined #instantbird 08:30:40 <-- Bollebib has quit (Connection closed) 08:32:53 --> sherief has joined #instantbird 08:54:36 <-- sherief has quit (Ping timeout: 121 seconds) 09:32:06 --> gerard-majax has joined #instantbird 09:39:55 <-- gerard-majax has quit (Ping timeout: 121 seconds) 10:37:34 <-- dustinm` has quit (Ping timeout: 121 seconds) 10:55:38 --> dustinm` has joined #instantbird 11:33:42 <-- BWMerlin has quit (Client exited) 11:49:14 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 11:49:17 --> mpmc has joined #instantbird 12:05:46 --> aleth has joined #instantbird 12:05:46 * ChanServ sets mode +o aleth 12:10:20 <nhnt11> aleth: I've already attached a patch, by the way 12:10:37 <aleth> I saw. 12:10:47 <nhnt11> I think the main thing left is that right now it just deletes bad entries, I need to change that to an UPDATE to fix the path instead 12:11:16 <nhnt11> aleth: I've forgotten, did these log files with bad entries get re-indexed after your duplicate entries patch? 12:11:23 <nhnt11> s/did/do/ 12:11:41 <aleth> bad entries? 12:11:49 <nhnt11> entries with full paths 12:11:53 <nhnt11> versus relative.. 12:12:07 <nhnt11> I think not. 12:12:09 <aleth> They would have been reindexed as soon as your fix changing the paths back landed 12:12:20 <aleth> I think. 12:12:24 <nhnt11> Yeah, I think we discussed that 12:12:26 <nhnt11> But I think that's wrong 12:12:34 <nhnt11> Because the cache file only stores file names 12:13:04 <aleth> ah, you're right. 12:13:07 <nhnt11> I'll research that a bit more in a while 12:14:23 <nhnt11> Anyway, first thing I want to do is to roll back to a nightly without the regression fix and generate some bad entries for testing purposes 12:19:09 --> clokep has joined #instantbird 12:19:09 * ChanServ sets mode +o clokep 12:19:36 <aleth> nhnt11: "I haven't looked much into the datastore ID change thing yet. Should be as simple as executing a |DELETE * FROM imConversations| to clear out the table." What does this mean? 12:20:05 <nhnt11> aleth: It's in response to your comment just above mine 12:20:15 <nhnt11> should have quoted it, sorry 12:21:24 <aleth> I'm not sure it still applies as it did when I wrote it 12:21:41 <nhnt11> aleth: The link in your comment is bitrotted, it should point to https://dxr.mozilla.org/comm-central/source/mail/components/im/modules/index_im.js#274 12:22:14 <aleth> Ah, alright 12:22:28 <nhnt11> There's a chance we throw away the cache there, we should be clearing the table then 12:22:32 <aleth> nhnt11: The right thing to do there is to write a function that can look up the ID given a path and then use it 12:22:42 <nhnt11> yeah 12:22:57 <aleth> That will also be useful to fix the other bug 12:23:26 <nhnt11> aleth: I'm not sure what exactly the intention is of ignoring the cache if the datastore id doesn't match 12:23:29 <aleth> bug 1146698 12:23:32 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1146698 nor, --, ---, nobody, NEW, Chat Messages added to logs just before shutdown may not be indexed by gloda 12:23:41 <nhnt11> If it's that we want to invalidate the current index, then we really should be just nuking the table 12:23:59 <nhnt11> If it's just the cache file that's not relevant but the existing index is fine, then we will want to fine tune it.. 12:24:36 <nhnt11> aleth: What does that shutdown bug have to do with it? 12:24:44 <nhnt11> afaik we index files only after closing them 12:24:46 * clokep finds the reasoning at the bottom of http://work.erikvold.com/jetpack-pro-tip/2015/04/03/using-toolkit-require.html to be total BS. 12:24:50 <clokep> But there's no way to leave comments. 12:24:52 <nhnt11> i.e. a file's content will not change 12:24:56 <nhnt11> well, should not change. 12:24:59 <aleth> nhnt11: That's not the case 12:25:21 <nhnt11> Right, we're using OS.File to append now 12:25:26 * nhnt11 ponders 12:25:42 <nhnt11> I still think that once a conversation is closed, we create a new file next time it's opened 12:25:44 <aleth> Active conversations are continually indexed 12:25:53 <nhnt11> hmmm 12:26:10 <nhnt11> right, duh 12:26:25 <nhnt11> aleth: I think gloda takes care of updating it versus the same path though 12:26:54 <nhnt11> Ah, that's what that isNew flag is for 12:27:07 <aleth> Read comment 1 ;) 12:27:32 <nhnt11> ah :] 12:27:41 <aleth> What's missing is if (!isNew) setIDfromPath() 12:28:46 * nhnt11 sighs 12:29:06 <aleth> It works OK during sessions of course, as we get the ID when we create a new gloda entry. But the ID is not cached. 12:29:13 <nhnt11> yeah.. 12:29:23 * nhnt11 is going to worry about the re-indexing bug first 12:29:51 <aleth> clokep: I didn't understand that post :-/ 12:31:17 <aleth> I don't get those reasons, anyway. 12:39:55 <clokep> Yeah, oh well. 12:40:11 * aleth never had any desire to use SDK functions ;) 12:40:40 --> gerard-majax has joined #instantbird 12:44:14 <nhnt11> aleth: Gloda uses a FTS index 12:44:21 <nhnt11> there's an FTS enabled column "content" 12:44:25 <nhnt11> for the imConversations table 12:44:34 <nhnt11> deleting a row effectively deletes the index 12:44:41 <nhnt11> From my understanding of FTS anyway 12:45:30 <nhnt11> asuth also said that just deleting the rows should be enough 12:46:00 <aleth> OK 12:46:09 <nhnt11> as for removing it from the cache so it gets picked up for a reindex, if I change the delete to an update that shouldn't be necessary 12:46:13 <aleth> Still, like you said, updating the path would be much cheaper than reindexing 12:46:17 <nhnt11> Yeah 12:46:23 <nhnt11> I just wrote code to do that :P 12:46:27 <aleth> :-) 12:47:21 <-- aleth has quit (Quit: :tiuQ) 12:51:41 <-- Tonnes has quit (Connection closed) 12:53:16 <clokep> Does it work? ;) 12:53:37 <nhnt11> clokep: No reason it shouldn't 12:53:47 <nhnt11> I still need to create another dirty profile to test it though 12:54:08 <nhnt11> clokep: Do you have a thunderbird nightly with some chat logs spanning over a couple months? 12:55:52 <clokep> nhnt11: I don't use TB chat frequently. 12:56:15 <nhnt11> Doesn't need to be frequent, just as long as you have a few log files from before that regression fix landed :) 12:56:34 <clokep> I almost definitely do. Is there a way to check? 12:56:40 <clokep> I don't have time right thi ssecond to try something. 12:56:55 <nhnt11> Sure, ping me when you've got maybe 15 minutes 12:57:57 <clokep> Can you put the patch in the bug? 12:58:14 <nhnt11> There's a patch already, and I'll be attaching this new one soon too 12:58:24 <nhnt11> clokep: I'll attach one with some debugging info that will tell me if it works as well. 12:58:39 <nhnt11> That alright? Make sure to backup your profile before applying it though. 13:00:11 <clokep> Yes 13:00:33 <clokep> I'll use my dev profiel 13:00:46 <nhnt11> Still, back it up 13:01:17 * nhnt11 is figuring out the best way to add this debugging info 13:02:59 <nhnt11> bbl 13:07:18 --> Mnyromyr has joined #instantbird 14:46:53 --> sherief has joined #instantbird 14:47:25 --> aleth has joined #instantbird 14:47:26 * ChanServ sets mode +o aleth 15:29:29 --> Tonnes has joined #instantbird 16:14:25 <nhnt11> aleth: Have a few minutes to test this patch? 16:15:04 <nhnt11> I think currently, searching for something in those logs which were indexed against their full paths will get you search results, but when you click on a result, nothing 16:15:13 <nhnt11> After the patch, it should display the log 16:15:19 * nhnt11 downloads an old nightly 16:17:07 <aleth> nhnt11: OK, maybe my old profile has some cruft in it 16:17:24 <nhnt11> aleth: You'll want to backup the dirty profile, for repeated testing 16:17:40 * nhnt11 wonders why he's getting a 30KB/s download speed 16:21:06 <clokep> aleth: "Note this already worked for the IRC special case before, so it's not really "new", more "fixed for XMPP"."... no way was that in TB *31* though. 16:21:18 <aleth> Pretty sure it was 16:21:26 <clokep> Ah I forgot to search the im component of TB. :( 16:22:57 <aleth> clokep: bug 1014472 comment 1 says "Currently automatic reconnection of MUCs only works for IRC." 16:22:59 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1014472 nor, --, 1.6, aleth, RESO FIXED, Support automatic MUC reconnection for all protocols 16:23:13 --> spz has joined #instantbird 16:23:41 <clokep> OK? But I don't see how that helps us know it was in TB 31. 16:23:50 <clokep> It doesn't matter though. 16:25:05 --> nhnt11-tb has joined #instantbird 16:25:10 <nhnt11-tb> Hello 16:25:18 <nhnt11-tb> Just generating some bad log entries 16:25:45 <clokep> UUIDS? 16:26:18 <nhnt11-tb> Bah, I think I downloaded a nightly from before bug 1103647 16:26:20 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1103647 maj, --, Thunderbird 38.0, nhnt11, RESO FIXED, Chat logs no longer being indexed by gloda 16:26:25 <nhnt11-tb> So my logs aren't getting indexed at all :-/ 16:27:41 <-- spz has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 16:29:15 <nhnt11> I'm confused 16:29:55 <nhnt11> If both bug 1103647 and bug 1069845 were caused by bug 955292, then how did bad entries crop up at all? :S 16:29:58 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1103647 maj, --, Thunderbird 38.0, nhnt11, RESO FIXED, Chat logs no longer being indexed by gloda 16:29:59 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1069845 maj, --, Thunderbird 38.0, nhnt11, RESO FIXED, Viewing logs from faceted search results is broken 16:30:00 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=955292 enh, --, 1.6, nhnt11, RESO FIXED, Read/write chat logs asynchronously 16:33:51 <-- nhnt11-tb has quit (Client exited) 16:34:49 --> nhnt11-tb has joined #instantbird 16:35:46 --> mconley has joined #instantbird 16:35:56 * nhnt11 now somehow has 5 result UI items pointing to the same search result 16:36:37 <-- nhnt11-tb has quit (Client exited) 16:37:42 --> nhnt11-tb has joined #instantbird 16:38:41 <-- nhnt11-tb has quit (Client exited) 16:39:00 --> nhnt11-tb has joined #instantbird 16:39:54 <-- nhnt11-tb has quit (Client exited) 16:40:15 --> nhnt11-tb has joined #instantbird 16:40:37 <-- nhnt11-tb has quit (Client exited) 16:41:23 --> nhnt11-tb has joined #instantbird 16:42:19 <-- nhnt11-tb has quit (Client exited) 16:42:38 --> nhnt11-tb has joined #instantbird 16:43:01 <-- nhnt11-tb has quit (Client exited) 16:43:23 --> nhnt11-tb has joined #instantbird 16:43:38 <-- nhnt11-tb has quit (Client exited) 16:48:40 --> nhnt11-tb has joined #instantbird 16:51:15 --> nhnt11-tb1 has joined #instantbird 16:52:01 <-- nhnt11-tb1 has quit (Client exited) 16:52:41 <-- nhnt11-tb has quit (Ping timeout: 121 seconds) 16:53:20 --> nhnt11-tb has joined #instantbird 16:54:23 <-- nhnt11-tb has quit (Client exited) 16:55:34 --> nhnt11-tb has joined #instantbird 16:56:32 <-- nhnt11-tb has quit (Client exited) 16:56:59 --> nhnt11-tb has joined #instantbird 16:57:29 <-- nhnt11-tb has quit (Client exited) 16:57:53 --> nhnt11-tb has joined #instantbird 16:59:41 <-- nhnt11-tb has quit (Client exited) 17:00:22 --> nhnt11-tb has joined #instantbird 17:00:43 <-- nhnt11-tb has quit (Client exited) 17:01:45 --> nhnt11-tb has joined #instantbird 17:02:07 <-- nhnt11-tb has quit (Client exited) 17:02:26 --> nhnt11-tb has joined #instantbird 17:02:26 <-- nhnt11-tb has quit (Client exited) 17:03:24 --> nhnt11-tb has joined #instantbird 17:03:36 <-- nhnt11-tb has quit (Client exited) 17:04:28 --> nhnt11-tb has joined #instantbird 17:05:05 <-- nhnt11-tb has quit (Client exited) 17:05:24 --> nhnt11-tb has joined #instantbird 17:05:32 <-- nhnt11-tb has quit (Client exited) 17:06:29 <nhnt11> Okay 17:06:37 <nhnt11> I deleted my entire index 17:06:43 <nhnt11> and reindexed everything with full paths 17:06:49 <nhnt11> then I applied the patch and ran it 17:07:06 <nhnt11> well before applying it, faceted search results didn't work as expected 17:07:15 <nhnt11> then after applying the patch, the paths got updated correctly 17:07:20 <nhnt11> and faceted results started working 17:07:27 <nhnt11> So I think everything is in order 17:07:59 <aleth> Sounds good 17:08:11 <nhnt11> I also dumped the path of all database entries 17:08:14 <nhnt11> there are no more full paths 17:08:15 <aleth> Want me to run it on my profile? 17:08:24 <nhnt11> Yeah, that would be good 17:08:32 <nhnt11> Can you keep a particular search result handy that's not working right now 17:08:33 <nhnt11> ? 17:08:39 <nhnt11> So that you can see if it starts working after the patch 17:08:45 <aleth> Probably 17:08:55 <aleth> Just have to find one ;) 17:10:03 <nhnt11> aleth: Uploading a new patch, stay tuned 17:11:04 <nhnt11> aleth: I'm going to address your review comments over IRC, if that's ok 17:11:24 <aleth> It's better in the bug as this will likely need additional review from flo or asuth 17:11:26 <nhnt11> yielding null isn't a problem, just yields the event loop and continues whatever it was doing 17:11:27 <nhnt11> okay 17:11:43 <nhnt11> Seemed trivial yes or no questions, that's why I thought IRC 17:24:32 <clokep> nhnt11: Was there a patch uploaded? I feel like I'm missing part of a conversation... 17:24:34 * clokep doesn't hav eany bugmail 17:24:38 <nhnt11> clokep: https://bugzilla.mozilla.org/show_bug.cgi?id=1135291 17:24:41 <instantbot> Bug 1135291 nor, --, ---, nhnt11, NEW, Re-index chat log files since bug 955292 17:24:44 <nhnt11> Patches are up on that bug 17:24:50 <clokep> Hm.m.. 17:24:53 <clokep> I haven't gotten any mail 17:25:01 <nhnt11> looks like you aren't cc'd 17:29:03 <clokep> nhnt11: I subscribe to that component. 17:29:15 <clokep> Oh, no I don't. 17:29:18 <clokep> It' sin search, not IM. 17:31:35 <nhnt11> yeah.. 17:33:12 * aleth added some dumps 17:33:18 <aleth> heh, looks like it fixed a lot of entries 17:34:29 <aleth> :-) 17:34:41 <aleth> nhnt11: looks like it worked! 17:34:42 <nhnt11> cool :) 17:35:07 <clokep> aleth, nhnt11: So will everything be fixed after the? 17:35:59 <nhnt11> clokep: everything except bug 1146698 I think 17:36:01 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1146698 nor, --, ---, nobody, NEW, Chat Messages added to logs just before shutdown may not be indexed by gloda 17:36:21 <aleth> and that one is probably simpler... just needs a DB query added 17:36:24 <clokep> Will this fix issues with people have duplicated entries? 17:36:51 <aleth> No, it won't deduplicate entries 17:37:04 <nhnt11> Where are duplicate entries coming from? :( 17:37:25 <aleth> That was the bug I fixed. 17:38:05 <nhnt11> ahh, so the patch for that only prevents future duplications... of course 17:38:21 <nhnt11> looks like there'll need to be some sort of deduplication code as well then :-/ 17:38:43 * nhnt11 thinks we should just nuke everyone's indexes 17:38:47 <aleth> That's the least important issue though. I'm much more concerned about missing hits than duplicate ones 17:39:09 --> Defman has joined #instantbird 17:39:13 <nhnt11> true 17:41:22 <-- gerard-majax has quit (Ping timeout: 121 seconds) 17:41:25 --> gerard-majax has joined #instantbird 17:43:50 --> rosonline has joined #instantbird 17:46:27 <aleth> nhnt11: I'd be OK with reindexing everything for everyone if bug 1146698 is fixed, so we don't have to worry about consistency across restarts 17:46:29 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1146698 nor, --, ---, nobody, NEW, Chat Messages added to logs just before shutdown may not be indexed by gloda 17:47:18 <nhnt11> aleth: "Also, you never clear it..." it's cleared in saveCacheNow 17:47:35 <nhnt11> which is called after setting the version, as opposed to scheduleCacheSave 17:47:52 <aleth> Well, for me the version flag is not getting saved in the cache file. 17:48:03 <nhnt11> It is for me 17:48:05 <nhnt11> weird 17:48:11 <aleth> The new sweep runs on every restart. 17:48:40 <nhnt11> :S 17:49:40 * nhnt11 will have to debug/tweak that... 17:49:42 <aleth> Plus you should probably move the save to the completion handler of your select statement 17:49:52 <aleth> Otherwise it happens too early 17:50:00 <nhnt11> No it doesn't 17:50:06 <nhnt11> We're yielding that Promise 17:50:16 <nhnt11> and it doesn't resolve until completion of the select statement 17:50:24 <aleth> ah good 17:50:45 <nhnt11> Well 17:50:52 <nhnt11> It doesn't resolve until every async sql query is done 17:52:08 <-- mconley has quit (Connection closed) 17:52:23 <aleth> So it resolves before any updates happen, or after all but one update happens? That's my question 17:52:55 <nhnt11> aleth: It resolves after /all/ updates happen 17:53:12 <aleth> :-) 17:53:32 <aleth> ah right, they both use asynCompletionHandler 17:59:51 <-- aleth has quit (Quit: :tiuQ) 18:04:48 <-- mpmc has quit (Connection closed) 18:21:51 <-- rosonline has quit (Ping timeout: 121 seconds) 18:31:40 --> rosonline has joined #instantbird 19:08:53 --> Bollebib has joined #instantbird 19:32:26 --> spz has joined #instantbird 19:42:30 <-- AlexanderSalas has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 20:07:11 <-- clokep has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 20:07:22 --> clokep has joined #instantbird 20:07:22 * ChanServ sets mode +o clokep 20:17:06 <-- Bollebib has quit (Ping timeout: 121 seconds) 20:17:11 --> Bollebib has joined #instantbird 20:24:25 --> unghost has joined #instantbird 21:06:31 <-- Mnyromyr has quit (Ping timeout: 121 seconds) 21:07:22 --> Mnyromyr has joined #instantbird 21:13:06 --> AlexanderSalas has joined #instantbird 21:27:42 <-- AlexanderSalas has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 21:28:58 <-- Tonnes has quit (Connection closed) 21:33:24 --> Tonnes has joined #instantbird 21:41:03 <-- sherief has quit (Ping timeout: 121 seconds) 22:21:23 <-- clokep has quit (Ping timeout: 121 seconds) 22:31:48 <-- unghost has quit (Quit: Ð£Ñ Ð¾Ð¶Ñ Ñ Ð¾Ñ Ð²Ð°Ñ (xchat 2.4.5 или ÑÑаÑÑе)) 22:39:45 --> clokep has joined #instantbird 22:39:45 * ChanServ sets mode +o clokep 23:13:31 <-- Mnyromyr has quit (Quit: ChatZilla 0.9.91.1 [SeaMonkey 2.33/20150308222602])