#email@example.com logs for 31 Mar 2013 (GMT)Archive Today Yesterday Tomorrow
[00:08:13] --> omichalek has joined #gemrb
[00:10:56] <omichalek> hi all, can anybody help with PST on ipad? I packed my game which had widescreen mod configured to 1024x768, and two other mods installed - "GhostDog's UI" mod and ultimate fixpack
[00:12:10] <omichalek> now the game is in the device, but when I start it, it doesn't respond to any input, except for swiping up or down the keyboard
[00:13:16] <omichalek> I tried setting MouseFeedback from 3 to 0 but no cursor appears
[00:13:57] <omichalek> otherwise the theme song plays in the background
[00:15:03] <vampi-the-frog> PST=awesome
[01:10:21] <-- omichalek has left IRC (Ping timeout: 256 seconds)
[01:12:38] <-- vampi-the-frog has left IRC (Quit: Leaving)
[01:41:54] <-- edheldil_ has left IRC (Ping timeout: 272 seconds)
[02:02:09] <-- Maighstir has left IRC (Quit: .)
[05:39:36] --> brada has joined #gemrb
[06:09:19] <-- brada has left IRC (Quit: brada)
[08:59:53] --> edheldil_ has joined #gemrb
[09:35:38] <-- edheldil_ has left IRC (Ping timeout: 272 seconds)
[09:54:10] --> fizzle has joined #gemrb
[10:01:55] --> rocket_hamster has joined #gemrb
[10:58:04] --> Yoshimo has joined #gemrb
[11:10:25] <-- rocket_hamster has left IRC (Remote host closed the connection)
[11:45:17] --> edheldil_ has joined #gemrb
[11:48:14] --> lynxlynxlynx has joined #gemrb
[11:48:14] --- ChanServ gives channel operator status to lynxlynxlynx
[12:27:14] <lynxlynxlynx> so much for mail, looks like sf does filter too
[12:44:19] <psch> http://filebin.ca/c5lcxNa4nB8 md5 78aa49850c36cfb3aad1d1453bb8f247
[12:55:20] <-- edheldil_ has left IRC (Ping timeout: 246 seconds)
[12:56:51] --> edheldil_ has joined #gemrb
[13:10:58] <-- edheldil_ has left IRC (Ping timeout: 272 seconds)
[13:31:03] <lynxlynxlynx> ok
[13:31:16] <lynxlynxlynx> i'll clean it up and add it
[13:48:33] <-- Yoshimo has left IRC (Quit: Yoshimo)
[14:04:14] <lynxlynxlynx> i don't know how you managed to compile this
[14:05:25] <psch> run bash prep_env.sh from the android directory
[14:05:33] <psch> then cd build/gemrb and run ndk-build && ant debug
[14:05:45] <psch> you need android-ndk and -sdk
[14:05:57] <psch> in PATH
[14:18:17] <lynxlynxlynx> yeah, the instructions are clear
[14:18:32] <lynxlynxlynx> but i don't see how you could compile master with this, since the patches don't all apply
[14:18:49] <lynxlynxlynx> eg patch 2
[14:20:24] <lynxlynxlynx> doesn't look like it's needed anymore at al
[14:20:26] <lynxlynxlynx> all
[14:20:45] <psch> huh
[14:21:05] <psch> i guess i screwed up the patches somehow
[14:21:30] <psch> ooh
[14:21:33] <psch> i know
[14:21:35] <psch> yeah
[14:21:51] <psch> remember how i said that git format-patch didnt output anything
[14:21:55] <lynxlynxlynx> i'll just remove that one
[14:22:06] <psch> to get output i used git format-patch origin
[14:22:09] <psch> which, i realize now
[14:22:10] <psch> is totally wrong
[14:22:21] <lynxlynxlynx> 09 - GEM_DATA looks like it replaced it
[14:22:58] <lynxlynxlynx> origin should be fine if the repo had a recent fetch
[14:23:54] <psch> i've only pulled, never fetched
[14:24:39] <lynxlynxlynx> doh, it was reverted later
[14:24:49] <lynxlynxlynx> pull fetches, but you didn't rebase
[14:24:54] <psch> uh
[14:24:57] <psch> yes?
[14:29:45] <lynxlynxlynx> which means things should be merged throughout, but it doesn't look like it
[14:30:07] <lynxlynxlynx> anyway, i'm half through
[14:30:32] <psch> i probably screwed up the workflow at least a few times in between
[14:31:00] <psch> i really don't know git well
[14:34:30] <lynxlynxlynx> ok, all applied now
[14:34:46] <lynxlynxlynx> removed a few of the patches, redid one manually
[14:40:27] <lynxlynxlynx> ok, it's in
[14:43:27] <lynxlynxlynx> hopefully still intact, but weee
[14:45:06] <psch> im running it as it is in-tree now
[14:50:07] <lynxlynxlynx> ok
[14:50:42] <lynxlynxlynx> it's unfortunate that we have yet another config template
[14:54:44] <psch> that's actually an oversight my be i just notice
[14:55:04] <psch> it's not actually needed anymore, i can copy the sample config from somewhere else in the tree too
[14:56:25] <psch> the point was to not have to fiddle with the config in prep_env.sh, back when gemrb didn't deal with app-specific data dirs correctly
[14:56:42] <psch> but brada fixed that, so i can now just copy the normal template
[14:57:49] <psch> ah, and my name-each-file-specifically makefile bites me again
[14:58:18] <psch> jni/src/Android.mk doesn't include InterfaceConfig.cpp
[15:03:20] <lynxlynxlynx> aha
[15:04:06] <psch> i fixed that yesterday, guess i didnt commit it
[15:04:17] <psch> but with that file added to the makefile it builds fine
[15:04:33] <psch> ill install and run it on my tablet in half an hour or so
[15:05:18] <lynxlynxlynx> it's in now
[15:07:38] --> rocket_hamster has joined #gemrb
[15:12:51] --> brada has joined #gemrb
[15:15:52] <psch> http://nopaste.info/6c35bc224b.html this is another fix
[15:15:53] <Seniorita> Nopaste - powered by project-mindstorm IT Services
[15:15:57] <psch> although
[15:16:11] <psch> maybe ignore that and i adjust prep_env to copy the sample conf we have already
[15:16:22] <psch> seeing as i don't need any magic placeholders anymore
[15:19:10] <lynxlynxlynx> that wouldn't change anything if the dir already exists
[15:20:10] --> omichalek has joined #gemrb
[15:21:29] <psch> right
[15:21:37] <psch> that means the dir doesn't exist
[15:21:44] <psch> which means i have the order wrong in the script
[15:21:51] <psch> which is pretty much as bad
[15:21:56] <lynxlynxlynx> then it would only provide an error
[15:22:05] <psch> and the app wouldn't have the config file
[15:22:24] <psch> the problem i ran into was that the config was copied as "assets" into the project directory
[15:22:32] <psch> so creation of the dir failed and i didnt have unhardcoded etc.
[15:22:45] <psch> anyway, ill fix that, change it to copy the sample conf we have already
[15:23:21] <lynxlynxlynx> feel free to add those commented out debug paths to it
[15:24:16] <psch> the /sdcard paths?
[15:24:32] <psch> they depend on android version and current user
[15:24:51] <psch> i'd rather not, seeing as we have proper logic to find those directories now
[15:25:00] <lynxlynxlynx> the emulated ones
[15:25:38] <psch> yeah those work only for android 4.1 onwards, any 4.0 or below device has different paths
[15:25:39] <lynxlynxlynx> if it's fine now then good, forget about it
[15:26:39] <brada> that "unused" member in sdlcolor is now alpha btw
[15:27:10] <brada> so it may be wise to initialize it
[15:29:36] <brada> tomprince: buildbot appears to be down
[15:33:51] <lynxlynxlynx> bbl monday night
[15:34:16] <lynxlynxlynx> targetting release about end of next week
[15:34:44] <lynxlynxlynx> https://bugs.freedesktop.org/show_bug.cgi?id=62764
[15:39:13] <-- lynxlynxlynx has left IRC (Ping timeout: 240 seconds)
[15:46:28] --> Yoshimo has joined #gemrb
[15:49:19] <-- brada has left IRC (Quit: brada)
[16:01:32] <-- omichalek has left IRC (Ping timeout: 255 seconds)
[16:13:19] <-- rocket_hamster has left IRC (Ping timeout: 245 seconds)
[16:26:57] --> rocket_hamster has joined #gemrb
[16:58:48] <viilee> lynxlynxlynx: If you want, go ahead and point me in the right direction in the 0-config issue.
[16:58:57] <viilee> Should I use gdb or something?
[17:00:41] --> Maighstir has joined #gemrb
[17:06:04] <fizzle> do you know how to use gdb?
[17:07:07] <viilee> not really. Well I can start programs in it, but have no idea what to do ;-)
[17:07:46] <fizzle> okay, I can try to step you through it
[17:07:57] <viilee> ok
[17:08:37] <fizzle> I assume your gem-.ini only gets created if you change some options?
[17:08:46] <viilee> Yes
[17:09:15] <fizzle> please delete it if it currrently exists
[17:09:16] <viilee> Should I delete it before I run it? Or does it matter...
[17:09:19] <viilee> ok
[17:09:37] <fizzle> then start under gdb
[17:10:18] <viilee> Mok, should I goto options and change something?
[17:10:24] <fizzle> are you running head?
[17:11:11] <viilee> I believe so (I checked out yesterday, and if that's the default branch or whatever. Never used much git)
[17:11:24] <fizzle> should be fine
[17:11:31] <fizzle> Ctrl-C in gdb
[17:11:48] <fizzle> enter "break Interface.cpp:3826"
[17:11:55] <fizzle> "c"
[17:12:34] <fizzle> then go to options and change stuff
[17:12:42] <viilee> No symbol table is loaded. Use the "file" command. \ Make breakpoint pending on future shared library load? (y or [n])
[17:12:54] <viilee> Umm... what is it saying?
[17:12:57] <fizzle> is gemrb already running?
[17:13:28] <viilee> Yes, that's what it said when I made the break thing (breakpoin?)
[17:13:54] <viilee> Should I have compiled with some debugging options, or something?
[17:13:54] <fizzle> if you're already running it means you compiled without debugging smybols
[17:13:59] <fizzle> yes
[17:14:18] <viilee> Ahh. Well, this is my first time ever debugging enything ;-)
[17:14:54] <viilee> So, DCMAKE_BUILD_TYPE=Debug ?
[17:15:12] --> edheldil_ has joined #gemrb
[17:15:17] <fizzle> I'm not really intimate with CMake and I know I had to fiddle with that myself
[17:15:23] <fizzle> so, maybe? :)
[17:16:30] <viilee> Ok, recompiling. And taking trash out and stuff. I'll be back in a while...
[17:30:22] <viilee> Hmm, it still says no debugging symbols found (I believe this should change if they are compiled), also the breakpoint doesn't work
[17:32:22] <fizzle> can you see if "-g" is passed to the compiler when building?
[17:32:45] <viilee> Probably. I just need to figure where to look ;-)
[17:32:57] <viilee> I was using the ebuild still, but I could change that
[17:33:05] <viilee> At least CMake says Build type is debug
[17:34:09] <fizzle> make VERBOSE=1
[17:34:45] <viilee> It's there
[17:35:20] <fizzle> hm
[17:36:01] <viilee> I can post the whole g++ line, if you like (it's pretty long). Maybe there's something that shouldn't be there...
[17:36:21] <viilee> /usr/bin/x86_64-pc-linux-gnu-g++ -Dgemrb_core_EXPORTS -DHAVE_CONFIG_H -DGEM_BUILD_DLL -DPLUGINDIR=\"/usr/games/lib64/plugins\" -DDATADIR=\"/usr/share/games/gemrb\" -DSYSCONFDIR=\"/etc/games/gemrb\" -march=athlon64-sse3 -O2 -pipe -fomit-frame-pointer -Werror -Wno-error=cast-align -Wall -W -Wpointer-arith -Wcast-align -pedantic -Wno-format-y2k -Wno-long-long -fno-strict-aliasing -fvisibility=hidden -g -fPIC -I/var/tmp/portage/games-engines/gemrb-9999/work/gemrb
[17:36:47] <fizzle> it's possible that the ebuild strips symbols after, I guess
[17:36:48] <viilee> -g is there after -fvisibility=hidden...
[17:37:00] <-- edheldil_ has left IRC (Ping timeout: 258 seconds)
[17:37:04] <fizzle> also, if you could change -O2 into -O0 that will be helpful later on
[17:37:38] <viilee> Hmm., I think I will forget the ebuild for now as it makes things more comlicated ;-)
[17:38:11] <viilee> Previously, when I tried to run from the source dir / home dir, gemrb insisted on looking for files in /usr/share...
[17:38:37] <viilee> So I was a bit lazy, and adopted the ebuild to git, since it was easier than settting the dirs in the config file ;-)
[17:38:55] <fizzle> I understand that
[17:38:57] <viilee> Oh, and by home dir I meant installed with PREFIX=$HOME
[17:39:47] <viilee> I don't know how to change the flags per ebuild. Also, I will have more control what is going on compiling by myself...
[17:41:39] <fizzle> -DCMAKE_BUILD_TYPE=DEBUG -DCMAKE_CXX_FLAGS="-O0" works for me
[17:43:30] <fizzle> so it's probably the ebuild stripping the symbols
[17:43:52] <viilee> Ok, compiling again... probably need to rewrite the gemrb config file (unless it now finds the folder automatically after installing. Previously, I think I tried a different method (a wrong one?) when setting the PREFIX
[17:44:08] <viilee> So maybe it'll search in the right place now ;-)
[17:46:16] <fizzle> the gemrb config shouldn't need changing
[17:46:27] <fizzle> it only contains paths to the game data
[17:46:35] <viilee> Ok, now I'll just test that the bug is reproducible still... At least debugging symbols are found ;-)
[17:46:48] <fizzle> great
[17:46:52] <viilee> Yes, It was previously, now it searched in the right place
[17:46:56] <viilee> I had messed up something
[17:48:23] <viilee> Umm.. typical, I believe it works now. Must be somthing in the layout and / or files not reciding in home directory... now options are saved!
[17:48:29] <viilee> I'm just re-checking to make sure...
[17:50:23] <viilee> Yes, I can't reproduce it with this build - only difference is installed gemrb into my home dir with PREFIX=$HOME), and also without the ebuild...
[17:50:53] <fizzle> hm, did you use -O0 now?
[17:50:57] <viilee> Yes
[17:51:06] <fizzle> can you try with -O2?
[17:51:14] <viilee> Ok
[17:51:59] <fizzle> the optimizer might be tripping us up
[17:52:45] <fizzle> oh, or the assert gets thrown away...
[17:53:41] <viilee> With -O2?
[17:54:12] <fizzle> not sure which options would cause that to happen
[17:54:27] <fizzle> but if -O2 still works for you we can make a simple test
[17:55:59] <-- rocket_hamster has left IRC (Quit: bye!)
[17:58:04] <viilee> OK, it still works with -O2 (options are saved)
[17:58:34] <fizzle> alright, then we'll use your ebuild for again
[17:59:00] <fizzle> in Interface.cpp there is one line you need to change
[17:59:33] <viilee> ok
[17:59:36] <fizzle> line 3851: "assert(vars->Lookup...)"
[18:00:16] <fizzle> just remove the enclosing "assert(...)", not the part in between
[18:00:45] <fizzle> then rebuild using your ebuild and check whether it's fine now
[18:01:12] <viilee> vars->Lookup(key, value);
[18:01:17] <viilee> It looks like that?
[18:01:23] <fizzle> yes
[18:02:20] <viilee> I could also figure out how to set the -O0 for ebuilds (or, actually I could just unpack -> configure manually -> merge)
[18:02:26] <viilee> But lets test this first
[18:02:59] <fizzle> you'd also need to figure out how not to throw away debugging symbols
[18:03:28] <viilee> Well, it was not done in the compiler options I pasted above?
[18:03:40] <viilee> Is not, well I have no idea what the ebuilds do ;-)
[18:03:50] <viilee> s/Is/If/
[18:03:59] <fizzle> no, the -g tells the compiler to add them
[18:04:28] <fizzle> the ebuild probably calls strip or something later in the packaging process
[18:05:23] <fizzle> -O0 disables compiler optimizations
[18:05:33] <viilee> Ok
[18:05:51] <viilee> I could paste the ebuild I'm using in pastebin or something, maybe someone knows how to tweak it
[18:06:12] <viilee> There's nothing exotic there AFAICT so it must be something per default in Gentoo (or cmake eclass)
[18:06:32] <fizzle> quite likely
[18:06:39] <viilee> Oh, btw. I can't 'make uninstall' the gemrb from my home dir
[18:06:45] <fizzle> stripping those symbols saves a lot of space
[18:06:55] <viilee> ah well
[18:07:08] <viilee> Good I didn't install as root / to root ;-)
[18:07:29] <fizzle> I have not the slightest idea what cmake does on make uninstall
[18:08:05] <viilee> It does nothing in this case. Complains about missing /home/ville/usr/src/gemrb/gemrb/build/cmake_uninstall.cmake
[18:08:20] <fizzle> I try to avoid touching it if possible :)
[18:10:27] <viilee> Ok, now it works from the ebuild too
[18:10:27] <fizzle> only ever do system installs using your package manager of choice
[18:10:33] <viilee> Options are saved
[18:10:39] <viilee> Of course I will ;-)
[18:10:47] <fizzle> okay, great, then it's the assert being removed
[18:11:04] <fizzle> thanks for tracking this down
[18:11:18] <viilee> So, is it a bug in the ebuild or your end?
[18:11:27] <fizzle> weeeelllll
[18:11:37] <viilee> Should the ebuild in portage be tweaked so that the asserts are not removed...
[18:11:43] <viilee> Or is it complicated ;-)
[18:12:16] <fizzle> I think we don't officially endorse or support non-debug builds (which is what causes asserts to be dropped, even though I don't know exactly which options)
[18:12:53] <fizzle> still, they seem to be fairly widespread so I think we don't just want to break in those cases regardless
[18:13:26] <fizzle> e.g. the config issue was reported on Windows and Android and maybe others
[18:13:58] <viilee> Ok
[18:14:34] <fizzle> ideally, however, the ebuild would be adjusted to not drop asserts
[18:15:11] <fizzle> that should also make the experience a bit more robust and help locate errors if they happen
[18:15:15] <viilee> I have no idea how to do that...
[18:15:58] <viilee> Well, it works for me so I can play ;-)
[18:16:12] <fizzle> fuzzie can probably tell you what options need to be changed
[18:17:48] <wjp> it's probably cmake
[18:18:14] <wjp> but we explicitly undefine NDEBUG already in CMakeLists.txt?
[18:18:21] <wjp> so I'm confused
[18:18:36] <viilee> Anyways, here's the ebuild: http://pastebin.com/s4qGXrdL
[18:18:42] <Seniorita> gemrb live ebuild - Pastebin.com
[18:19:04] <viilee> The gentoo ebuild cmake eclass does a lot of stuff. Probably overwrites CMakeLists.txt? Or something.
[18:24:07] <fizzle> that we only undefine it for !MSVC seems slightly unsafe, too
[18:26:07] <wjp> hm, the cmake-utils eclass does add NDEBUG for non-debug builds
[18:26:40] <wjp> but since this gemrb ebuild sets CMAKE_BUILD to debug/Debug, it doesn't trigger this undefining it
[18:26:57] <wjp> since it only does it for CMAKE_BUILD_TYPE matching Rel.*
[18:27:06] <wjp> anyway, we should just fix that warning
[18:27:29] <wjp> but we still don't like building without those asserts as they're still too valuable to disable
[18:29:05] <fizzle> it's really a bug that the program breaks when the assertion gets taken out, though
[18:29:26] <fizzle> but, yeah, they are generally desirable to have around
[18:30:17] <viilee> Well, one could probably file a bug report about cmake eclass dropping asserts when build type is set to debug?
[18:30:46] <wjp> as I said, we should fix that warning
[18:31:40] <wjp> the eclass uses the debug useflag to see that, which seems reasonable
[18:32:11] <wjp> hm, although that code is in a block checking if CMAKE_BUILD_TYPE = Gentoo
[18:32:23] <wjp> so I'm probably not looking closely enough
[18:33:35] <tomprince> Well. We shouldn't be using assert, probably.
[18:34:03] <tomprince> At least, not one controled by NDEBUG.
[18:34:49] <fuzzie> why not?
[18:35:55] <fuzzie> wjp: it defaults to CMAKE_BUILD_TYPE=Gentoo
[18:36:26] <fuzzie> last night viilee reported it built fine with CMAKE_BUILD_TYPE="RelWithDebInfo"
[18:36:54] <fizzle> it builds fine, yes
[18:37:01] <fuzzie> but of course I don't advocate putting required code inside an assert :-p
[18:37:18] <fizzle> but the assert in the config saving stuff is not just checking stuff
[18:37:20] <fizzle> right
[18:38:25] <wjp> fuzzie: that ebuild sets it to Debug or debug though
[18:39:25] <fuzzie> oh, i'm assuming that is the fixed ebuild
[18:40:03] <fuzzie> but clearly I am not following here, I'm confused
[18:40:15] <fizzle> we didn't manage to fix the ebuild
[18:40:30] <fizzle> it was still stripping symbols
[18:40:46] <fuzzie> stripping symbols is a different thing, though
[18:41:05] <fizzle> and dropping asserts
[18:41:29] <fuzzie> it seems weird if it built with dropping asserts, since -Werror is still there, right?
[18:41:50] <fizzle> I thought viilee removed that yesterday?
[18:42:11] <fizzle> but clearly I did not really follow that discussion either
[18:42:19] <fuzzie> i suggested fixing the NDEBUG thing instead, and i thought that was where we'd gotten to
[18:44:51] --> edheldil_ has joined #gemrb
[18:45:20] <viilee> Hmm, I removed the -Werror by hand once, but then I changed the build type (CMAKE_BUILD_TYPE=Gentoo), which I believe, did the same thing?
[18:45:56] <fuzzie> you set it to Gentoo?
[18:46:43] <viilee> No, that's the default. At fist I set it to RelWithDebInfo, and today to debug (or Debug - i put the other line there in case the use flag wasn't parsed correctly)
[18:46:57] <fuzzie> yes
[18:47:05] <fuzzie> those don't remove -Werror though
[18:47:11] <viilee> RelWithDebInfo allowed it to compile (but with warnings)
[18:47:34] <fuzzie> well then I am very confused :)
[18:47:37] <viilee> Oh, well. I'm probably very confused about stuff since I'm no programmer
[18:48:04] <fuzzie> if you get warnings from gcc but it still compiles, then there is no -Werror
[18:48:42] <viilee> Yes, I thought so. But the asserts are dropped after compile time, somewhere. I don't know where (let alone know how cmake or the eclass works)
[18:48:59] <viilee> Or that's what fizzle said
[18:49:18] <fuzzie> well, if you get warnings then they are probably caused by the asserts being dropped
[18:49:21] <viilee> If I understod correctly ;-)
[18:49:44] <viilee> Yes, that's how I understod too
[18:49:52] <fuzzie> well, I only just got back home, so I will go fetch some coffee and see if it makes more sense after :)
[18:52:52] <viilee> Summary: Problem caused by dropped asserts. 0.7.2 ebuild compiled fine on gentoo (doesn't cause wornings), but GIT doesn't (because it causes warnings). Changing build type allows git to compile, with the same problem (but asserts are still dropped, since that is hard-wired somewhere by Gentoo or git-2.eclass). Removing the said assert [Interface.cpp:3851: "assert(vars->Lookup...)"], works around the problem (of options not being saved).
[18:53:29] <viilee> Hope I was thorough ;-)
[18:53:47] <fizzle> git master should be fine now
[18:54:55] <wjp> really?
[18:55:57] <wjp> did you push to SF already? c9d55f8 will give an unused variable warning
[18:57:45] <fizzle> if asserts are disabled, yes
[18:58:43] <fizzle> as I understood it we have other places where that happens, too, though
[18:59:32] <fizzle> and I'm not sure how to avoid that (or whether we should even try)
[19:02:56] <fizzle> (I guess we could just do the lookup twice if we wanted to...)
[19:03:10] <tomprince> No.
[19:12:16] <viilee> FWIW, I set CMAKE_BUILD_TYPE=Gentoo, and set debug useflag. That allowed gemrb to build with asserts (but, seemingly no debuggin symbols). So, I think there's a bug in the eclass (if CMAKE_BUILD_TYPE!=Gentoo), but that's a whole another issue...
[19:13:14] <viilee> Sorry, no. I think it's the updated code, probaly ;-)
[19:18:12] --> omichalek has joined #gemrb
[19:27:48] <-- Yoshimo has left IRC (Read error: Connection reset by peer)
[21:02:28] <-- fizzle has left #gemrb
[21:17:55] --> omichalek_ has joined #gemrb
[21:17:55] <-- omichalek has left IRC (Read error: Connection reset by peer)
[21:18:04] --- omichalek_ is now known as omichalek
[22:15:24] <-- omichalek has left IRC (Quit: ChatZilla 0.9.90 [Firefox 19.0.2/20130307023931])