[00:13:34] --> pupnik has joined #GemRb
[00:19:48] <-- Guest40195 has left IRC (Ping timeout: 265 seconds)
[02:04:46] <-- Dark-Star|away has left IRC (Ping timeout: 276 seconds)
[02:08:48] --> Dark-Star|away has joined #GemRb
[02:08:48] --- ChanServ gives channel operator status to Dark-Star|away
[04:47:29] <-- Gekz has left IRC (Read error: Connection reset by peer)
[04:47:51] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[04:48:14] --> Gekz has joined #GemRb
[04:54:45] --> Gekz_ has joined #GemRb
[05:07:24] <-- Gekz has left IRC (Read error: Connection reset by peer)
[05:07:32] --> Gekz has joined #GemRb
[05:32:08] <-- Gekz_ has left IRC (Quit: This computer has gone to sleep)
[05:38:49] <-- raevol has left IRC (Quit: Leaving.)
[05:43:31] --> edheldil has joined #GemRb
[05:43:31] --- ChanServ gives channel operator status to edheldil
[05:48:16] <-- edheldil has left IRC (Ping timeout: 265 seconds)
[06:19:03] --> Gekz_ has joined #GemRb
[06:38:07] <-- Gekz_ has left IRC (Quit: This computer has gone to sleep)
[07:00:39] --> lynxlynxlynx has joined #GemRb
[07:00:40] --- ChanServ gives channel operator status to lynxlynxlynx
[07:03:16] <-- |Cable| has left IRC (Read error: Connection reset by peer)
[09:17:41] <lynxlynxlynx> http://pastebin.com/zX7nhTGn <-- tomprince, fuzzie: do you want to see something else in there too?
[09:24:19] <fuzzie> i don't have a good view of what changed, i think; i would've assumed magic missiles, tinting, etc had already seen a release
[09:24:33] <lynxlynxlynx> nope
[09:24:45] <lynxlynxlynx> last release was in november
[09:25:15] <lynxlynxlynx> one of the reasons i update the news regularly is this final phase
[09:29:11] <wjp> looking through the git repo I think we should try to rebase before pushing more often
[09:30:25] <lynxlynxlynx> --no-merges ;)
[09:32:36] <wjp> but that only helps with viewing the log, not with e.g., bisect
[09:32:58] <fuzzie> i just do pull --rebase
[09:33:14] <fuzzie> makes sure i don't get too far behind, too
[09:33:31] <wjp> yeah, same here
[09:33:59] <lynxlynxlynx> pull --rebase == fetch && rebase or does it work on a dirty tree?
[09:34:21] <fuzzie> is just fetch+rebase
[09:35:36] <wjp> I'd prefer not unnecessarily un-linearizing the repo (to use a triple negative ;-) )
[09:37:25] <fuzzie> but last time i looked the merges were mostly Avenger, and i would really rather not bother him with yet more obstacles
[09:38:00] <wjp> lynxlynxlynx and Avenger
[09:38:24] <lynxlynxlynx> sometimes i'm too lazy to stash first
[09:38:44] <lynxlynxlynx> it disrupts my editors needlessly too
[09:48:41] <Gekz> lol
[09:48:44] <Gekz> <3 Git
[10:39:59] --> barra_library has joined #GemRb
[10:48:59] <lynxlynxlynx> well well well
[10:57:38] <fuzzie> hm?
[11:00:33] <lynxlynxlynx> need to fix autotools - PythonHelpers.h doesn't get included in the tarball now
[11:06:42] <pupnik> "need to fix autotools" :|
[11:07:10] <lynxlynxlynx> i think i'll do the next release with cmake only
[11:07:30] <lynxlynxlynx> running autogen.sh is not such a big deal
[11:08:20] <fuzzie> well, i was wondering a while ago if it would be sensible to put warnings on autotools on this release
[11:08:41] <fuzzie> that it's no longer supported etc
[11:08:46] <lynxlynxlynx> it would be, as it is already doing less than cmake
[11:09:06] <lynxlynxlynx> do you think we should drop it someday?
[11:09:46] <fuzzie> i don't really mind either way
[11:09:51] <lynxlynxlynx> on some wierd platforms it was easier to get than cmake iirc
[11:10:01] <CIA-23> GemRB: 03lynxlupodian * rd66920757b25 10gemrb/gemrb/plugins/GUIScript/Makefile.am: GUIScript: include PythonHelpers.h in the makefile
[11:10:06] <fuzzie> yes
[11:10:18] <fuzzie> and on other weird platforms, cmake easier than making autotools work
[11:10:27] <lynxlynxlynx> on most, yes
[11:10:42] <fuzzie> hence my thoughts about splattering warnings over autotools and seeing if anyone complains :p
[11:16:50] <lynxlynxlynx> i'll add the warnings
[11:27:07] <CIA-23> GemRB: 03lynxlupodian * rf1b3782cd83d 10gemrb/ (autogen.sh configure.in): added two big fat warnings for users of autotools
[11:39:44] --> Gekz_ has joined #GemRb
[12:19:08] <CIA-23> GemRB: 03lynxlupodian * rb50d08e0fc25 10gemrb/ (admin/announcement.template gemrb/docs/en/Release.txt):
[12:19:08] <CIA-23> GemRB: documented more of the release process and added my release announcement
[12:19:08] <CIA-23> GemRB: template
[12:21:12] <lynxlynxlynx> tom is around gmt-5?
[12:37:46] <fuzzie> i think so
[12:50:57] <tomprince> Improved handling of 'CaseSensitive = 1'?
[12:51:15] <tomprince> And I am in the authors, don't need to be in the NEWS as well.
[12:51:54] <lynxlynxlynx> you weren't at the start
[12:52:19] <fuzzie> no harm noting that :)
[12:52:20] <lynxlynxlynx> mattinm was also mentioned like that
[12:54:24] <tomprince> Just seems silly is all.
[12:56:31] <Gekz_> you're silly
[12:57:35] <lynxlynxlynx> request denied
[12:59:54] <CIA-23> GemRB: 03tom.prince * r4c0cf9458049 10gemrb/NEWS: ...
[13:02:27] <lynxlynxlynx> hah
[13:03:24] * fuzzie puts the silly hat onto tomprince
[13:03:49] * tomprince takes the silly hat and puts it on lynxlynxlynx
[13:04:22] <fuzzie> g'morning, anyway :)
[13:04:27] <tomprince> morning.
[13:09:51] <CIA-23> GemRB: 03lynxlupodian * rbe15d3f18728 10gemrb/NEWS: NEWS: 0.6.1
[13:09:54] <CIA-23> GemRB: 03lynxlupodian * r6671e3fc94f8 10gemrb/ (configure.in gemrb/includes/globals.h): gemrb 0.6.1
[13:28:59] <tomprince> lynxlynxlynx: I don't know if it is too late, but do we want to cleanup the sample config?
[13:29:38] <lynxlynxlynx> i'd rather leave it for next time
[13:29:50] <fuzzie> judging by the discussion about what should or shouldn't be in it, it seems to deserve a bit more thought
[13:30:02] <tomprince> k.
[13:30:18] <tomprince> I was just looking at the gentoo ebuild, and that reminded me.
[13:30:20] <lynxlynxlynx> judging from the plans, we'll have another release in two months' time too
[13:30:39] <fuzzie> the ebuild which didn't update the config files?
[13:33:18] <tomprince> It doesn't install one, just puts an example in doc.
[13:33:35] <fuzzie> huh
[13:33:44] <fuzzie> that makes their shipping it with the ebuild even weirder
[13:36:16] <fuzzie> my only use of gentoo is their embedded stuff, no real clue about it on the desktop
[13:36:52] <lynxlynxlynx> i used to use
[13:37:21] <lynxlynxlynx> almost zero vanilla concept
[13:39:10] <tomprince> They don't shup it with the ebuild, they install it from the source.
[13:40:16] <tomprince> s/shup/ship/
[13:40:21] <fuzzie> the official gemrb ebuild in gentoo ships a config file with the ebuild
[13:40:24] <fuzzie> and installs that somewhere
[13:40:49] <fuzzie> we had a few people coming in very confused, because they didn't update that config file with new builds
[13:41:14] <fuzzie> and unless packages.gentoo.org is out-of-date, it's still doing the same thing now
[13:44:56] <lynxlynxlynx> +/usr/etc ugh
[13:46:36] <tomprince> Well, they just do 'make install'
[13:47:06] <tomprince> Which puts our sample in /etc/games/gemrb
[13:48:44] <tomprince> We should check CMAKE_INSTALL_DIR=/usr, and set SYSCONF_DIR to /etc/gemrb in that case. In FHS and OPT. Do you want me to do that?
[13:49:03] <lynxlynxlynx> sure
[13:49:13] <lynxlynxlynx> i just defined SYSCONF_DIR in the spell for now
[13:49:40] <lynxlynxlynx> comparing the autotools and cmake installs, i see we previously didn't install many (all?) iwd projectiles
[13:50:27] <lynxlynxlynx> and that we don't install most of the docs
[13:51:02] <lynxlynxlynx> no wonder
[13:56:43] <lynxlynxlynx> tomprince: are you working on that change now? i want to avoid conflicts
[13:56:54] <tomprince> Yes.
[13:57:01] <lynxlynxlynx> ok, i'll wait
[13:57:02] <tomprince> Pushing.
[13:57:14] <tomprince> Just the fhs case.
[13:59:22] <CIA-23> GemRB: 03tom.prince * rb9b518deb8ec 10gemrb/CMakeLists.txt: cmake: Use SYSCONF_DIR=/etc for fhs build into /usr.
[14:10:01] --> Maighstir_laptop has joined #GemRb
[15:02:43] <tomprince> lynxlynxlynx: When are you planning to make the release ... just curious as to when I should post the new gentoo ebuild.
[15:02:58] <lynxlynxlynx> later today
[15:03:05] <lynxlynxlynx> i'm fixing the doc issue
[15:03:37] <tomprince> Are you going to install the README and AUTHORS file in make install?
[15:03:54] <lynxlynxlynx> README already is
[15:04:12] <lynxlynxlynx> all of the docs/ is missing
[15:07:43] <tomprince> We don't seem to install README, at least not with cmake.
[15:07:57] <lynxlynxlynx> we do
[15:08:04] <lynxlynxlynx> oh wait, sorcery
[15:11:07] --> mvbarracuda_libr has joined #GemRb
[15:14:25] <-- barra_library has left IRC (Ping timeout: 265 seconds)
[15:14:45] <tomprince> I don't think we should install the test1 override/GUIScripts.
[15:15:27] <lynxlynxlynx> i think it should just die
[15:15:35] <tomprince> That works too.
[15:16:08] <tomprince> Anybody who cares can resurrect it from git. It is broken now anyway.
[15:20:34] <-- Gekz has left IRC (Quit: Leaving)
[15:25:14] <fuzzie> yes
[15:30:34] <tomprince> One thought (for after release), create a temporary directory inside CachePath to use as cache. That way, multiple running instances won't step on each other, if they are run with the same CachePath.
[15:34:28] <lynxlynxlynx> multiple running instances :)
[15:34:53] <fuzzie> well
[15:34:59] <fuzzie> there's no sane default for CachePath
[15:35:14] <fuzzie> and i thought it was you who had the alternative thought of simply making it default to inside the game dir
[15:35:34] <tomprince> /var/cache/gemrb, if we create a subdir.
[15:35:48] <tomprince> Which is actually what it was defaulting to on gentoo.
[15:35:51] <fuzzie> oh, you mean for specific distros?
[15:36:16] <fuzzie> yes, well, that's why it was broken for all the gentoo users who tried, because /var/cache/gemrb didn't exist and wouldn't be user-writable anyway
[15:37:41] <fuzzie> making temporary directories inside CachePath seems ok, but i would worry about them not being cleared up, if you made them with temporary names
[15:38:17] <lynxlynxlynx> and cachepath in the gamepath can also be problematic if the path isn't writeable or for multiple instances (think nfs)
[15:38:24] <fuzzie> sure
[15:38:30] <fuzzie> but there's no *good* default
[15:38:49] <lynxlynxlynx> the only safe one i can think of is home
[15:38:50] <fuzzie> it can't be /tmp, it can't be the game dir, it can't be in /var, it can't be in the gemrb dir
[15:39:07] <fuzzie> and it can't be home, either, because that's generally on internal storage
[15:39:15] <tomprince> Not tmp, or var/tmp?
[15:39:32] <fuzzie> /tmp filesystems are often <~10mb
[15:39:44] <lynxlynxlynx> or use tmfs
[15:39:54] <lynxlynxlynx> tmpfs
[15:39:59] <fuzzie> so, i mean, this is going to be distro-customised
[15:40:13] <fuzzie> there's nothing which will work for all
[15:40:52] <tomprince> But that doesn't mean there isn't a reasonable default.
[15:41:03] <fuzzie> well, what *is* areasonable default? :)
[15:41:21] <fuzzie> lynx might be right about home, i guess
[15:41:50] <fuzzie> default to ~/.gemrb/Cache/<gametype>/ or something
[15:42:01] <tomprince> /var/cache, /var/tmp, /tmp ~/.gemrb/cache
[15:42:31] <fuzzie> pupnik: any thoughts?
[15:42:57] <pupnik> on n900 it would need to be /media/mmc1/something
[15:43:03] <fuzzie> i can't imagine home directories are going to have enough space on embedded distros either, but they should work for almost everyone else..
[15:43:36] <pupnik> well, it wouldn't *need* to be that but you can't use /tmp
[15:43:50] <fuzzie> what about home directories, though?
[15:44:05] <fuzzie> i know on Android, home directories are on the internal storage, so you can't put data in them
[15:44:20] <lynxlynxlynx> that's why it would remain a config option
[15:44:37] <lynxlynxlynx> i think it is safe to say that the majority will be fine with home
[15:44:42] <fuzzie> i'm wondering if we could just put a config option for 'store in home directory' vs 'store in gamepath'
[15:44:47] <tomprince> exactly. Perhaps with a -DCONFIG_DIR
[15:44:48] <lynxlynxlynx> /tmp could be problematic with user mixing
[15:44:50] <fuzzie> and have that work for almost everyone
[15:45:02] <fuzzie> and then have CachePath in the documentation, for people who need something else
[15:45:03] <tomprince> That is what a temporary subdirectory is for.
[15:45:14] <fuzzie> well, there are a lot more people running with limited-size /tmp
[15:45:39] <fuzzie> but on the other hand, i would worry that people would end up with a whole bunch of files in ~/.gemrb and not notice where all their disk space was being wasted, how big is a typical gemrb Cache after you played a few areas?
[15:46:41] <fuzzie> i tried this for another engine, to allow mmap()ing of content, and people ended up with 500mb of stuff lurking in such a directory after they played a bunch of different games
[15:46:48] <fuzzie> i still don't have a good solution for it, so i am all ears
[15:47:25] <pupnik> i like the home/gamepath option. people on embedded systems will install gemrb to a gamepath with lots of space
[15:47:45] <fuzzie> yes, home vs gamepath seems like it should cover almost everyone
[15:48:21] <pupnik> n900 has a couple gigs of home. if i get a job with meego i can tell you more about the future
[15:49:44] <tomprince> Well, delete on exit, with a signal handler, seems like the obvious solution, although there are probably issues with that.
[15:50:15] <fuzzie> well, in this case, people tended to give up on a game after something had crashed and possibly stomped over the internal structures
[15:51:13] <fuzzie> but with some hard-coded sanity-checking on what is being deleted, i guess you could make it work, if not me :)
[15:53:51] <lynxlynxlynx> oh man am i silly
[15:54:09] <lynxlynxlynx> forgot to commit and so make dist kept creating old tarballs
[15:55:55] <lynxlynxlynx> i don't think the signal approach is too safe
[15:58:05] <tomprince> Definitely requires some thought and testing.
[15:58:13] <fuzzie> i was a bit disappointed to find out how limited signals are
[15:58:22] <CIA-23> GemRB: 03lynxlupodian * r3e3f99ad9366 10gemrb/ (4 files in 4 dirs): cmake: install the docs
[15:58:35] <fuzzie> windows has this lovely structured exception handling where you can do all kinds of magic, even throw C++ exceptions up the call stack and continue
[16:00:01] <lynxlynxlynx> ok, so the tarball is now final
[16:00:10] <fuzzie> hoorah
[16:00:38] <lynxlynxlynx> it's also nice to see all the *.la files not being installed anymore
[16:02:04] <tomprince> Still don't install the README?
[16:03:12] <lynxlynxlynx> oh, right
[16:04:36] <lynxlynxlynx> README INSTALL COPYING NEWS AUTHORS <-- do you want anything more?
[16:05:46] <lynxlynxlynx> hmpf, we don't look at /etc/gemrb.cfg anymore
[16:08:48] <tomprince> No.
[16:11:30] <tomprince> About etc: we only ever looked in SYSCONF_DIR
[16:11:58] <tomprince> Which probably default to /etc
[16:13:09] <tomprince> It might be reasonable to just look in /etc anyway, at least if we are looking for gemrb.cfg in particular. But probably not for gamename.cfg.
[16:13:09] <fuzzie> didn't your build above do just that?
[16:13:24] <fuzzie> your commit above, even
[16:13:31] <tomprince> /etc/gemrb
[16:13:49] <fuzzie> oh. that's kinda silly :)
[16:14:08] <lynxlynxlynx> the interface code handles all of them
[16:14:16] <lynxlynxlynx> just the prefix is too deep
[16:14:27] <tomprince> Better than /usr/etc/gemrb
[16:14:31] <tomprince> :)
[16:14:59] <lynxlynxlynx> yes, but worse than /etc :P
[16:16:00] <tomprince> A matter of opinion.
[16:16:10] <tomprince> I think /etc is worse then /etc/gemrb
[16:16:23] <fuzzie> well, it seems a bit silly to force a move
[16:16:33] <lynxlynxlynx> it is worse, but it is a change
[16:16:35] <fuzzie> and if it's a single config file, i don't really mind either way
[16:16:51] <CIA-23> GemRB: 03lynxlupodian * rbe2954a6225f 10gemrb/CMakeLists.txt: cmake: also install the topdir docs
[16:16:55] <fuzzie> but i think people will probably work it out, if they were relying on it
[16:17:16] <lynxlynxlynx> if they already had it in /etc/gemrb/, it should work with an /etc prefix too
[16:18:03] <lynxlynxlynx> but let's make an experiment and see if anyone notices
[16:18:25] <lynxlynxlynx> i'm getting tired of repeating the archive creation
[16:18:27] <tomprince> No, for a single config file, it probably doesn't make a difference, but if you have more than one...
[16:20:26] <tomprince> And I didn't realise that interface looks for $SYSCONF_DIR/$PACKAGE
[16:23:42] <tomprince> Looks good to me.
[16:30:43] <lynxlynxlynx> interesting, almost half a meg smaller archive
[16:30:54] <-- Gekz_ has left IRC (Changing host)
[16:30:54] --> Gekz_ has joined #GemRb
[16:32:30] * pupnik sits on the couch with popcorn
[16:33:41] --- lynxlynxlynx has changed the topic to: GemRB 0.6.1 | http://gemrb.sf.net | Be wary of your words for there are Modron sensors in this channel: http://log.usecode.org/gemrblog.php | Hey <CHARNAME>, we need some awesome screenshots!
[16:39:49] <tomprince> gentoo v0.6.1 ebuild bug posted.
[16:41:59] <lynxlynxlynx> homepage, sf done
[16:42:25] <lynxlynxlynx> source mage too
[16:53:39] <lynxlynxlynx> Gekz_: beep
[16:53:45] <Gekz_> what
[16:53:56] <lynxlynxlynx> mingw
[16:54:12] <lynxlynxlynx> do you have still it ;)
[16:54:32] <Gekz_> nope
[16:54:35] <Gekz_> well, yes
[16:54:38] <Gekz_> but not anywhere near me
[16:54:45] <Gekz_> tomprince has it, he's the mingw man now
[16:54:47] <Gekz_> make him do it
[16:55:05] <lynxlynxlynx> i'm trying to spread the work
[16:55:31] <Gekz_> I have two exams on saturday
[16:55:35] <Gekz_> and press releases to write
[16:55:39] <Gekz_> and a report to read and critique
[16:55:42] <Gekz_> I am well spread sir
[16:55:50] <lynxlynxlynx> ok
[16:55:59] <lynxlynxlynx> good luck
[16:57:05] <lynxlynxlynx> tomprince: any chance of making a windows build?
[16:57:45] <-- Gekz_ has left IRC (Quit: This computer has gone to sleep)
[17:02:57] <tomprince> I probably could. I don't know how we should handle dependencies, or hardcoded paths.
[17:03:51] <tomprince> It would be nice if there was a way to get my buildbot to create it.
[17:04:08] <lynxlynxlynx> we just bundle the python dll
[17:04:18] <tomprince> openal/sdl?
[17:04:39] <lynxlynxlynx> i don't remember
[17:04:57] <lynxlynxlynx> maybe they have good native installers
[17:08:22] <tomprince> I think python does.
[17:09:07] <lynxlynxlynx> there is something fishy about it
[17:09:21] <lynxlynxlynx> i don't remember the details
[17:11:57] <tomprince> Well, I'll have a look it at it. Though I probably won't get a chance until this weekend.
[17:13:59] <tomprince> Once I get is setup though, hopefully will be able to make nightlies, or occasionallys ... :)
[17:15:28] <lynxlynxlynx> you have too much hardware :P
[17:16:58] <tomprince> I don't have much.
[17:17:36] <tomprince> I just have my desktop, a server and my laptop. And the server is at my dad.
[17:18:40] <tomprince> The stuff I have is probably overpowered for most of what I do though.
[17:19:11] <fuzzie> we just bundle all the dlls
[17:19:51] <fuzzie> the openal soft build for openal32.dll, a python26.dll because we're careful not to depend on any modules, and then whatever dlls are necessary for SDL/vorbis/whatever is built against
[17:20:24] <tomprince> I guess that means I shold install vorbis as well then.
[17:20:58] <tomprince> :)
[17:21:26] <fuzzie> well, or not bother :)
[17:22:01] <fuzzie> i prodded the vorbis support into working just because i was too lazy to make Dungeon Be Gone's ogg->wav decoding work, i seem to remember
[17:22:40] <tomprince> Well, ogg does seem to be the standard for mods.
[17:23:22] <fuzzie> well, i mean, anyone installing them on Windows is going to have the mod do that for them
[17:23:30] <fuzzie> so i wouldn't worry about it.
[17:24:09] <CIA-23> GemRB: 03lynxlupodian * raf652b0b9022 10gemrb/admin/restart_news.sh:
[17:24:09] <CIA-23> GemRB: restart_news.sh: ensure only one revision is used
[17:24:09] <CIA-23> GemRB: tuck guiscript improvements under bugfixes
[17:24:13] <CIA-23> GemRB: 03lynxlupodian * rc7d557fefbd3 10gemrb/NEWS: NEWS: new cycle
[17:24:50] <tomprince> I will, since I'd like to get the mods to support gemrb eventually.
[17:25:11] <fuzzie> i just imagine there might be a few releases between now and then :)
[17:25:28] <tomprince> If we have out-of-the-box working binaries that support vorbis, it will be easier to convince people to try it.
[17:25:43] <tomprince> Yes, but I only need to do it once, so might as well do it right the first time.
[17:25:46] <tomprince> :)
[17:26:02] <fuzzie> am certainly not objecting if you want to do the work!
[17:26:23] <tomprince> ;)
[17:29:33] <fuzzie> (don't suppose you want to fly to the Netherlands and take an undergrad group theory exam? :p)
[17:29:52] <CIA-23> GemRB: 03lynxlupodian * r06f06d7b9864 10gemrb/ (32 files in 6 dirs): test1: RIP
[17:30:36] <tomprince> If you'll pay for it. :)
[17:31:02] <tomprince> :p
[17:42:37] --> |Cable| has joined #GemRb
[17:44:13] --> Guest40195 has joined #GemRb
[17:54:25] --> cubathy has joined #GemRb
[17:56:43] <-- Guest40195 has left IRC (Quit: Guest40195)
[17:57:14] --> Guest40195 has joined #GemRb
[17:57:50] --- Guest40195 is now known as tomprince_loki
[18:09:17] --> raevol has joined #GemRb
[18:16:57] --> edheldil has joined #GemRb
[18:16:57] --- ChanServ gives channel operator status to edheldil
[18:31:14] <Maighstir_laptop> Moving the MinGW build from one Windows machine to another (freshly installed Win2000 SP4 with only Windows Update-dictated updates added), the needed files seem to be the gemrb_deps_dlls_20090301.zip package from GemRB's SF download page, python26.dll, msvcr90.dll as well as libstdc++-6.dll and libgcc_s_dw2-1.dll from the version of MinGW used to build. msvcr90.dll is only because the python26.dll needs it,
[18:31:14] <Maighstir_laptop> the Visual C runtime installed, but the dll is only about 650 KB anyway.
[18:33:31] <tomprince_loki> I wonder if there is an ldd like tool for windows, that I could script to generate the dependencies. Or is something like cpack smart enought for that.
[18:35:54] <tomprince_loki> Maighsitr_laptop: Will you and that machine be around sometime this weekend, to be a guinea big for testing my binary builds?
[18:36:23] <Maighstir_laptop> Sure, but no later than monday
[18:36:52] <tomprince_loki> I'll make sure to do it this weekend then.
[18:38:39] <Maighstir_laptop> Ad if the machine isn't working, I can always run through VMWare.
[20:10:23] <-- raevol has left IRC (Ping timeout: 260 seconds)
[20:16:26] --> raevol has joined #GemRb
[21:10:41] <-- mvbarracuda_libr has left IRC (Quit: Verlassend)
[21:11:06] <-- edheldil has left IRC (Ping timeout: 276 seconds)
[21:33:39] <-- tomprince_loki has left IRC (Ping timeout: 272 seconds)
[21:58:50] --> pupnik_ has joined #GemRb
[21:59:00] --> tomprince_loki has joined #GemRb
[22:02:29] <-- pupnik has left IRC (Ping timeout: 240 seconds)
[22:32:45] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:12:27] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)