Log for #openttdcoop.devzone on 23rd February 2012:
Times are UTC Toggle Colours
02:50:14  <Brot6> DictatorAI - Revision 197:291ccd58ebd1: - decrease vehnextprice to lower our money kept for buyin... (krinn) @
02:50:14  <Brot6> DictatorAI - Revision 198:513bb209639d: - Add missing new file dependency (krinn) @
06:09:26  <Brot6> Central European Train Set - Feature #3620: Force 32 bpp (Elukka) @
06:52:04  *** JVassie has joined #openttdcoop.devzone
07:08:40  *** andythenorth has joined #openttdcoop.devzone
07:13:57  <planetmaker> Yexo: NML writes nfo v8 already since r1752:
07:16:53  *** JVassie has quit IRC
07:57:19  <planetmaker> Ammler: recursion is recursive?
07:58:08  <planetmaker> dbg: [misc] /home/abuild/rpmbuild/BUILD/opengfx/lang/english.lng is not a valid language file
07:58:57  <planetmaker> can you see why r940 OpenGFX failed?
07:59:08  <planetmaker> All build logs seem fine to me. And I see no error log there
07:59:19  <Ammler> I know why
08:00:27  <Ammler> if the install dir exists, it creates again one,
08:00:31  <Ammler> error: Installed (but unpackaged) file(s) found:
08:00:32  <Ammler>    /usr/share/openttd/data/opengfx-r940/opengfx-r940
08:01:54  <Ammler> that happen, because it does not clean the build environment on the same run
08:02:10  <Ammler> but it is good, it should not happen
08:02:54  <Ammler> I do not understand, what you mean with recursion is recursive
08:03:41  <planetmaker> I mean the path opengfx is found in the openttd test
08:04:20  <planetmaker> dbg: [grf] Checking /home/abuild/.openttd/data/opengfx/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx
08:04:20  <planetmaker> -r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx-r940/opengfx.obg for base graphics set
08:04:30  <planetmaker> seems... weired
08:05:14  <planetmaker> dbg: [grf] Checking /home/abuild/.openttd/data/opengfx/opengfx-r940/opengfx.obg for base graphics set
08:05:14  <planetmaker> dbg: [grf] Not adding OpenGFX (940) as base graphics set (duplicate)
08:05:14  <planetmaker> d
08:05:50  <Ammler> but you see the issue with Makefile?
08:06:15  <Ammler> somehow, if install dir exists, it does create another one
08:06:24  <Ammler> hmm, let me try to reproduce locally
08:08:18  <Ammler> if you would retrigger build, this would not happen anymore
08:08:35  <Ammler> but it might be good that it happen, maybe we can fix it
08:09:46  <planetmaker> sorry, I honestly don't see the issue with the makefile? You say, if the installdir exists, it creats another level within the intended install dir?
08:10:37  <Ammler> seems so
08:11:31  *** ODM has joined #openttdcoop.devzone
08:12:13  <planetmaker> hm. "interesting"
08:12:33  <planetmaker> I guess we anyway should only install the tar and not the dir...
08:13:27  <planetmaker> but even so... that to me does not explain the failure
08:13:37  <Brot6> OpenGFX - Bug #3719: DevZone compile failed (planetmaker) @
08:15:38  <Ammler> what would be the benefit with tar?
08:16:38  <Ammler> openttd.grf isn't in a tar either
08:17:45  <Ammler> also you would have the readme twice then
08:23:58  <Ammler> planetmaker: if you get error because of missing grfid, building succeed, is that intendend?
08:25:49  <planetmaker> the benefit of a tar would be one file instead of 10
08:26:10  <Ammler> 10?
08:26:23  <Ammler> the docs are usually in another place
08:26:39  <planetmaker> even if you split them, it's 7 files
08:26:51  <Ammler> well, not for me, but afaik, debian and fedora does install it somewhere else
08:28:53  <Ammler> you could say, it is 7 only :-)
08:30:47  <Ammler> damn, I can't reproduce that locally
08:32:33  *** andythenorth has quit IRC
08:34:53  <Ammler> planetmaker: anyway, it did not error because of the openttd.log, if you want to review the openttd log, maybe use an older no-error one
08:35:36  <planetmaker> so why does it fail?
08:35:52  <Ammler> [09:00] <Ammler> error: Installed (but unpackaged) file(s) found:
08:35:53  <Ammler> [09:00] <Ammler>    /usr/share/openttd/data/opengfx-r940/opengfx-r940
08:36:18  <Ammler> in the devzone.log
08:37:46  <planetmaker> the makefile doesn't install anything unasked. So I'm left clueless
08:38:09  <planetmaker> can I thus assign the task to you?
08:39:54  <Ammler> I seem not able to find the reason either
08:40:29  <Ammler> what could be different on DevZone than locally?
08:42:23  <planetmaker> locally the makefile does not care about presence of OpenGFX anywhere during building
08:42:39  <Ammler> and why should it on DevZone?
08:43:07  <planetmaker> does it try to install opengfx somewhere in the build script?
08:43:09  <Ammler> make install INSTALL_DIR=%{buildroot}%{_datadir}/openttd/data/opengfx-%{version}
08:43:25  <planetmaker> why do you install?
08:43:39  <Ammler> to test install?
08:43:42  <planetmaker> and why that many recursive times?
08:43:54  <planetmaker> once would probably succeed
08:44:01  <Ammler> the recursive issue is not by the spec
08:44:06  <planetmaker> but it installs it about a quadrillion times
08:44:22  <Ammler> if you would retrigger build it would succeed
08:45:57  <planetmaker> obviously though the install test fails. I see not why, though
08:46:19  <planetmaker> Install works nicely, if called once. Even if called several times
08:46:30  <planetmaker> it must thus be something in the build script which is devzone specific
08:46:39  <Ammler> well, it works on the devzone too once, but not twice :-)
08:46:51  <Ammler> and as we usually cleanup the build env, we don't see that
08:47:37  <Ammler> I do not exclude the build env
08:47:44  <Ammler> I mean tthe build spec
08:47:52  <Ammler> but I still have no clue why
08:48:34  <Ammler> oh wow, another BROS, is that now rename number 4?
08:48:41  <Brot6> Central European Train Set - Feature #3717: Better custom articulation/other callbacks (Eddi) @
08:49:34  <planetmaker> o  default	932:321671e62cd9|Ammler Fix (r931): move %define of install dir down to the comment  <-- that did change something, I guess
08:49:52  <planetmaker> I stopped counting the BROS zombies
08:51:00  <Ammler> planetmaker: not really
08:51:32  <Ammler> that is just writing the variable, like you know from you cpp scripts too
08:52:08  <Ammler> also we don't use that spec on devzone
08:52:14  <Ammler> that is the spec on upstream
08:52:18  <Ammler> oh
08:52:23  <Ammler> down I meant :-)
08:52:27  <Ammler> the spec I use on suse
08:54:21  <Brot6> DevZone Help Center - Membership #3716: Applying for project: Britrains (admin) @
08:56:08  <Brot6> repository /home/hg/britrains registered in Redmine with url /home/hg/britrains
08:56:08  <Brot6> repository /home/hg/britrains created
08:57:33  <Brot6> DevZone Help Center - Membership #3716: Applying for project: Britrains (admin) @
09:03:36  <Ammler> nmlc: "sprites/nml/extra/extra-plus-rivers.pnml", line 896: Read beyond bounds of image file 'sprites/png/terrain/waterfeatures/rivermouth_tropical_ne.gimp.png'
09:03:48  <Ammler> I still have that issue, if I build without gimp
09:04:09  <Ammler> hmm
09:27:47  <Ammler> was old version
09:32:06  *** andythenorth has joined #openttdcoop.devzone
09:50:35  <planetmaker> why would OpenTTD trunk not complain about missing signal graphics but OpenTTD 1.1.5 would? Both show that they use the same OpenGFX.
09:51:24  <planetmaker> <-- related code
10:25:18  <Ammler> planetmaker: a very ugly thing is that make check does also build
10:25:31  <Ammler> it depends on other targets
10:26:51  <Ammler> Required file 'opengfx.check.md5' which to test against not found! <-- ha :-)
10:27:12  <Rubidium> planetmaker: no clue, maybe you can have fun tracing that ;)
10:27:30  <Ammler> anyway ugly
10:27:36  <Ammler> same ugly as make install does build
10:29:56  <Ammler> hmm,not just ugly, wrong
10:31:22  <planetmaker> he, I guess I'll have fun then
10:34:14  <planetmaker> Ammler: please read the "Makefile conventions" before you make such statements:
10:34:16  <Webster> Title: GNU `make' (at
10:35:09  <Ammler> yes, comparing with make install might be bad, sorry
10:35:16  <Ammler> but make check is wrong
10:35:20  <planetmaker> ‘install’
10:35:20  <planetmaker>     Compile the program and copy the executables, libraries, and so on to the file names where they should reside for actual use.
10:36:25  <Ammler> I removed the md5 file as dependency on check, but it still tries to build
10:36:57  <planetmaker> yes, it does that. Though indeed by the convention it should not for 'check'
10:38:11  <Ammler> I don't need to read the convention to know that ;-)
10:39:15  <Ammler> also added check .PHONY, but still
10:39:27  <Ammler> what is required so a target does not start with dep check?
10:40:33  <planetmaker> it must not depend on any file which depends on a dep check
10:41:15  <Ammler>
10:42:21  <Ammler>
10:42:58  <Ammler> it isn't the issue we have on the devzone, I just wondered why it built again
10:44:02  <Ammler> I know, I had this issue with suse spec too
10:44:14  <Ammler> but I can't reproduce there anymore either
10:48:37  <Ammler> btw. the convention handles the build/install issue too: "If possible, write the install target rule so that it does not modify anything in the directory where the program was built, provided ‘make all’ has just been done. This is convenient for building the program under one user name and installing it under another. ", my solution just would be safer ;-)
10:53:41  <Ammler> I need to play on the devzone directly, I nowhere else can reproduce it
11:05:29  <planetmaker> Ammler: paste 1148 shows that the use of 'check' is only useful for distribution tars
11:05:53  <planetmaker> and the missing file is NOT automatically generated except when creating a distribution tar
11:06:19  <Ammler> planetmaker: the issue is not that it doesn't generate it, the issue is that it builds
11:06:27  <planetmaker> no, not
11:06:30  <Ammler> it does at least start with dep check, doesn't it?
11:06:56  <planetmaker> it of course has to build in order to compare the md5sums with the expected md5sums as quoted in the missing file
11:07:11  <Ammler> yes, which should not happen
11:07:11  <planetmaker> but yes, according to the makefile specs check should just fail
11:07:21  <planetmaker> but I said that 30 minutes ago already ;-)
11:07:32  <Ammler> yep, I tried to fix it
11:07:36  <Ammler> but I failed
11:07:59  <planetmaker> oh, you mean with the diff in 1147?
11:08:08  <Ammler> also if I remove the md5 from check, it still tries to dep check
11:08:14  <Ammler> planetmaker: yes
11:09:00  <planetmaker> hm
11:09:20  <planetmaker> yes... it's in how makefiles are included...
11:09:39  <planetmaker> I really should write this from scratch. All of it. And especially OpenGFX could well get special treatment
11:10:18  <planetmaker> I just don't dare kill the dep check completely... not sure
11:10:23  <Ammler> well, it won't fix the issue on the devzone
11:11:23  <planetmaker> no, it won't. Still it's annoying, I know
11:13:59  <Ammler> yes, I will revert my patch and we silently forget about it until I complain again after a year or so ;-)
11:15:26  <planetmaker> hu?
11:16:33  <Ammler> I mean the check thing
11:16:49  <Ammler> I still try to reproduce the issue on devzone
11:17:06  <Ammler> that one I do not forget that fast :-P
11:18:52  <planetmaker> :-)
11:19:25  <planetmaker> let's do that with the check then that way. I fear it really will need some more fundamental changes to the Makefile
11:19:36  <planetmaker> It's probably related to how the sub-makefiles are included
11:19:59  <planetmaker> I currently don't know exactly whether OpenGFX uses the "newest" one in the framework (I think not).
11:20:00  <Ammler> yes, you see in the logs, if make check runs more than just the check
11:20:18  <planetmaker> But then the framework one isn't quite finished with this rework process
11:20:42  <planetmaker> the problem is: the Makefile.dep and friends are included conditionally
11:20:50  <planetmaker> But that means that it tries to make those makefiles
11:20:59  <planetmaker> which it can do. Thus it runs the whole dep check
11:21:24  <planetmaker> in the framework project I started to include those makefiles only for certain makefile targets
11:21:31  <planetmaker> but that gets messy pretty quickly
11:24:08  *** andythenorth has quit IRC
11:29:21  <Brot6> opengfx: update from r940 to r940 done -
11:29:44  <Ammler> so now let's try again :-)
11:35:20  <Brot6> NewGRF build framework - Bug #3706 (Confirmed): "caching" behaviour on nml error (planetmaker) @
11:36:26  <Brot6> Central European Train Set - Revision 647:df9bf7b6d0bd: some vague attempt at an SBB core set (Eddi) @
11:47:11  *** andythenorth has joined #openttdcoop.devzone
11:47:58  <Brot6> cets: update from r646 to r647 done (212 warnings) -
11:49:05  <Brot6> repository /home/hg/newgrf-nml registered in Redmine with url /home/hg/newgrf-nml
11:49:05  <Brot6> repository /home/hg/newgrf-nml created
11:49:08  <andythenorth> 212 warnings :o :)
11:50:34  <planetmaker> hm, bad name
11:50:39  <planetmaker> should be make-nml
11:51:23  <andythenorth> new project?
11:51:55  <Ammler> just create a new one, don't bother with reanming
11:53:56  <planetmaker> that's what I did
11:54:14  <planetmaker> andythenorth: not exactly. But I need a "real" project to improve the build framework on
11:54:37  <planetmaker> it's much easier that way than carrying all the ballast of nfo and nml. Caring about backward comaptible stuff etc
11:54:44  <andythenorth> makes sense
11:54:48  <andythenorth> no pun intended :P
11:54:51  <planetmaker> I can change the build framework when I have a better solution
11:54:55  <andythenorth> maybe call it makes-sense :P
11:54:59  <planetmaker> haha :-)
11:55:18  <planetmaker> that'd have been a good name indeed
11:56:05  <Brot6> repository /home/hg/make-nml registered in Redmine with url /home/hg/make-nml
11:56:05  <Brot6> repository /home/hg/make-nml created
11:57:42  <Ammler> planetmaker: I still would like the idea working with subrepos
11:58:16  <planetmaker> that makes not much sense for the build part
11:58:37  <Ammler> well, adding the framework as subrepo would
11:58:58  <Brot6> OpenGFX - Bug #3722 (New): DevZone compile failed (compiler) @
11:59:26  <Ammler> \o/ at least I can reproduce it on devzone :-)
11:59:44  <Ammler> now, dear god, tell me why
12:01:04  <Ammler> fuck
12:01:17  <Ammler> sorry :-$
12:01:55  <Ammler> of course someone had the idea to push exactly at the time when I try to debug the issue on devzone
12:02:11  <Brot6> Makefile for NML - Revision 0:697ad2203af5: Add: Import the NML project from the NewGRF build fra... (planetmaker) @
12:02:52  <Ammler> planetmaker: maybe it would also make sense to split newgrf and baseset
12:04:03  <planetmaker> yes
12:04:14  <planetmaker> maybe. Not sure yet
12:05:49  <Brot6> cets: update from r646 to r647 done (212 warnings) -
12:06:18  <Brot6> britrains: update from  to r3 done (4 warnings) -
12:09:02  <Ammler> I really going to hate my script
12:13:16  <planetmaker> you hate your script, I hate my build framework ;-)
12:13:29  <planetmaker> ugly like hell. But works somewhat ;-)
12:15:19  <Ammler> is bamboo opensource
12:15:21  <Ammler> ?
12:16:09  <planetmaker> yes
12:17:00  <Ammler> are you sure, any link to a source?
12:17:35  <planetmaker> or well. they provide you with the source, if you get a license.
12:17:40  <planetmaker> If you own a Bamboo license, you may be entitled to source code access. Login to My Account to view your licenses and download the source code. For more details, check out the source code FAQ.
12:18:12  <planetmaker> so maybe not exactly opensource in the defintion of FLOSS
12:19:17  <planetmaker> see
12:19:18  <Webster> Title: Open Source License Request (at
12:19:28  <Ammler> other alternaive is jenkins
12:20:29  <planetmaker> bamboo works well for OpenTTD itself
12:20:33  <Ammler> planetmaker: for me that sounds like opensource project get a free license, nothing with that bamboo is opensource
12:23:03  <planetmaker> yes, but see
12:23:04  <Webster> Title: Atlassian Purchasing and Licensing FAQ | Atlassian (at
12:23:18  <planetmaker> but yes, it's rather a free license.
12:24:04  <planetmaker> though you get access to the source as far as I understand
12:25:05  <Ammler> dihedral: could maintain it, it's java :-)
12:29:14  <planetmaker> lol :-)
12:30:17  <Brot6> opengfx: compile of r940 still failed (#3722) -
12:33:03  <Ammler> lrwxrwxrwx 1 399 399      94 Feb 23 12:29 opengfx-r940 -> /home/abuild/rpmbuild/BUILDROOT/opengfx-r940-suse1210.i386/usr/share/openttd/data/opengfx-r940
12:33:51  <Ammler> 68
12:33:52  <Ammler> ln -s %{buildroot}%{_datadir}/openttd/data/opengfx-%{version} $HOME/.openttd/data/opengfx
12:39:39  <Ammler> that it somehow installs the symlink wrongly is the only explaination I have
12:46:55  <Brot6> HEQS "Heavy Equipment" Set - Feature #3723 (New): Can fix vehicle info window length issues wit... (andythenorth) @
12:47:38  <Brot6> Dutch Trains 2.0 - Feature #3724 (New): Mat '35, '36, '40 and '46 (Voyager1) @
12:48:21  <planetmaker> why do you link that at all?
12:48:44  <planetmaker> *symlink
12:50:07  <Brot6> Dutch Trains 2.0 - Support #3632: list of vehicles to be drawn (Voyager1) @
13:11:29  <Ammler> planetmaker: I need to link the installed opengfx so openttd can read it at startup
13:11:43  <planetmaker> why?
13:11:50  <Ammler> note that rpmbuild does not install to /usr as it has no root access
13:11:51  <planetmaker> didn't you just compile opengfx?
13:12:20  <Ammler> so it installs the files to temporary buildroot
13:12:55  <planetmaker> in order to test OpenGFX it should not require a previous install. You could install an OpenTTD there and start it with the brand new OpenGFX
13:13:13  <Ammler> yes, that's the point
13:13:20  <planetmaker> eh?
13:13:36  <Ammler> because it is fresh installed, it isn't in /usr
13:13:55  <Ammler> I could make a testsuite package, which depends on openttd and opengfx
13:14:01  <Ammler> and then rebuilds
13:14:18  <planetmaker> well, I guess I don't quite get what you do
13:14:36  <Ammler> check the link, where make install is run
13:14:58  <Ammler> it isntalls to %{buildroot}/usr....
13:15:15  <Ammler> openttd would not search there for opengfx
13:15:19  <Ammler> so I link it to $HOME
13:17:09  <Ammler> well, that is fine, the issue is I have no clue where that symlink in the build root is from
13:20:02  <Ammler> maybe I should not use $HOME
13:20:30  <planetmaker> instead of the the directory mess, I'd rather suggest to install in the openttd local data dir
13:20:42  <planetmaker> you give the install path anyway
13:21:12  <Ammler> the directory mess happens only the second time
13:21:16  <planetmaker> or would that influence also the default install path for the rpm
13:21:27  <planetmaker> what is "the second time" actually?
13:21:34  <Ammler> I would rather like to know why than workaround installing it a second time just for the check
13:21:44  <planetmaker> I thought it builds in a clean environment everytime?
13:21:56  <planetmaker> or isn't that the point of a chroot ?
13:22:57  <Ammler> well, I reused the build env during one run
13:23:04  <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Bug #3708: Upload Code (Leanden) @
13:23:04  <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Feature #3721 (Assigned): British Rai... (Leanden) @
13:23:04  <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Feature #3721 (Assigned): British Rai... (Leanden) @
13:28:04  <Brot6> mode change on /home/hg/britrains
13:30:01  <Ammler> yes, very important to note python in the title :-)
13:30:43  <planetmaker> lol :-)
13:30:56  <andythenorth> at least it's making progress ;)
13:31:12  <Ammler> well, bros had that many commits too
13:31:32  <Ammler> every year another start :-)
13:33:58  <Ammler> planetmaker: also if we set cleanup for every build, this bug somehow still exists and I have no clue why, that sucks
13:50:31  <Brot6> opengfx: update from r940 to r940 done -
13:53:13  <dihedral> atlassian is sweet
13:53:30  <dihedral> however i do not think it would be something for you guys unless you get the full license
13:53:44  <dihedral> a 10 user license will only work if you really only have 10 users log in
13:54:01  <planetmaker> well. The only person who logs in would be the admins
13:54:07  <planetmaker> I guess
13:54:36  <dihedral> but i would not advise going with bamboo
13:54:42  <planetmaker> but that would need evaluation
13:54:55  <dihedral> i compared bamboo and a bunch of others once (about 3 years ago)
13:55:12  <planetmaker> three years is a lot of time
13:55:16  <dihedral> i would rather tell you to stick with jenkins / hudson
13:55:31  <planetmaker> it's not like we use that
13:55:33  <planetmaker> or any
13:55:41  <planetmaker> other than our own solution
13:55:50  <andythenorth> what's wrong with jenkins / hudson currently?
13:55:56  <planetmaker> nothing
13:55:57  <dihedral> i would not see the advantage of using banboo compared to those 2
13:56:19  <planetmaker> I've no preference for any so far. Mostly attributed to my ignorance of any details
13:56:52  <dihedral> there are a few interesting ones, yet jenkins/hudson usually wins the race ;-)
13:57:41  <Ammler> planetmaker: are you able to install build dependencies on the openttd cf?
13:57:57  <planetmaker> no
13:58:00  <Ammler> or is openttd cf able to use dependencies of projects it builds?
13:58:27  <planetmaker> but if you ask in general: one pretty sure can
13:58:35  <planetmaker> it's like creating VMs for building
13:58:44  <Ammler> that is the biggest issue I see with the existing solutions, those expect a static build environment
14:00:25  <Ammler> [14:58] <planetmaker> it's like creating VMs for building <-- that is basically doable by everyone on devzone, doesn't need special permission
14:00:43  <Ammler> you just define it with the sepc
14:01:43  <dihedral> why are you looking for a cf?
14:01:55  <Ammler> also how is the trust level with jenkins?
14:02:07  <Ammler> do you need to trust a dev with commit rights?
14:02:52  <dihedral> what do you mean Ammler ?
14:02:57  <dihedral> define 'trust'
14:03:06  <dihedral> if giving commit rights is not a need for trust ^^
14:03:19  <dihedral> afk
14:03:21  <Ammler> it isn't
14:03:57  <Ammler> I just wonder, how they work with git etc.
14:04:16  <Ammler> without internet access
14:05:35  <Ammler> using obs might still be the best and easiest
14:06:40  <Ammler> but of course, I would be happy to use another ci tool
14:06:53  <Ammler> but I would need help with maintenance
14:08:44  <Ammler> as we have a running system, the requirements are "clear"
14:09:30  <planetmaker> having a working system doesn't mean that the requirements are clear :-)
14:09:45  <Ammler> well, I meant, you guys know, what we need :-)
14:10:12  <Ammler> as we look for replacement, not for something new :-)
14:12:02  <Ammler> does dedicated openttd not require opengfx anymore?
14:12:11  <planetmaker> it still does
14:12:18  <planetmaker> nothing changed. why?
14:12:37  <Ammler> if I start with openttd -D, I got no output that opengfx is loaded, but it doesn't fail
14:13:03  <Ammler> ah, ubs
14:13:13  <Ammler> never mind :-)
14:13:26  <Ammler> grf=1 is the debug option
14:13:30  <Ammler> used misc=1
14:15:24  <dihedral> back
14:16:26  <Ammler> planetmaker: seriously no clue, where that symlink is from
14:16:39  <dihedral> maintaining jenkins / hudson is no work at all - only a setup ;-)
14:17:13  <dihedral> updating is a simple task of replacing a .war file and restarting the application server
14:17:20  <Ammler> well, that is included in my meaning about "maintaining" :-)
14:17:49  <dihedral> and have an apache in front so you can have a neat 500 error page saying that jenkins / hudson is being updated
14:19:12  <Ammler> dihedral: how do you like the nice new rule of oracle to forbid java distributed?
14:19:50  <Ammler> that very much sucks as e.g. the java vnc client for proxmox does not work with openjdk
14:20:00  <dihedral> :-D
14:20:21  <dihedral> if i am not mistaken, java may be distributed*
14:20:22  <Ammler> that is a reason, I would so much like to not use something javaish
14:20:29  <dihedral> *if you pay the license fees
14:20:32  <Ammler> not anymore
14:20:51  <Ammler> dists needed to remove it backwards :-)
14:21:15  <Ammler> only openjdk is available anymore
14:21:42  <dihedral> ah - distribution with linux ;-)
14:22:43  <dihedral> i do not rally care that much about that - you know where to get java from
14:25:08  *** andythenorth has quit IRC
14:26:22  <Ammler> yeah, you windows guy, but I prefer to use software manager :-)
14:26:38  <dihedral> :-P
14:27:03  <dihedral> i actually do not mind not being able to apt-get install sun-jdk-1.6
14:27:22  <Ammler> I don't think you can
14:27:32  <Ammler> could*
14:27:35  <dihedral> one used to be able to
14:27:42  <Ammler> when?
14:27:50  <dihedral> 2 years ago?
14:27:52  <Ammler> :-P
14:27:58  <dihedral> :-P
14:29:03  <Ammler> well, I blame proxmox making a client which doesn't work with openjdk
14:32:33  <dihedral> i would also blame openjdk for being so different
14:33:11  <Ammler> if I read the oracle faq right, they plan to use openjdk as official spec also for oracle java
14:33:37  <Ammler> that might be the reason, they do not want to distribute java for free anymore
14:35:40  * dihedral 's software works on openjdk :-P
15:50:56  *** andythenorth has joined #openttdcoop.devzone
16:36:15  *** andythenorth has quit IRC
16:41:56  <dihedral> if it may be of ease for deciding for your new cf, i'd offer cpu time by providing a hudson in 'child' mode ;-)
17:20:33  <Brot6> dutchtrains: update from r220 to r222 done (360 warnings) -
17:21:53  <Brot6> Makefile for NML - Bug #3725 (New): DevZone compile failed (compiler) @
17:22:47  <Brot6> britrains: update from  to r3 done (4 warnings) -
17:24:45  <Brot6> airportsplus: update from r162 to r169 done -
17:28:05  <Brot6> Makefile for NML - Bug #3726 (New): DevZone compile failed (compiler) @
17:28:48  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: britrains (4 warnings)
17:44:56  <Brot6> NewGRF Meta Language - Feature #3727 (New): Implement / document extra_callback_info1 for vehicle... (Hirundo) @
17:49:26  *** LordAro has joined #openttdcoop.devzone
18:01:41  *** frosch123 has joined #openttdcoop.devzone
18:11:03  *** andythenorth has joined #openttdcoop.devzone
18:13:16  <Rubidium> LordAro: do you compile OpenTTD yourself?
18:13:31  <LordAro> i am able to, yes
18:14:45  * Rubidium might have something for you that requires really recent trunk (newer than nightly)
18:14:57  <LordAro> :O
18:14:59  <LordAro> ;)
18:16:07  <Rubidium>
18:16:32  <Rubidium>
18:18:20  <LordAro> does that do what i think it does? :D
18:19:03  <Rubidium> I think it does (new version of create though)
18:20:08  <Rubidium> only works for base graphics though
18:20:14  <LordAro> i see
18:20:25  <LordAro> so, how do i get it to work?
18:21:19  <Rubidium> get pngcodec, grfcodec and the libraries nml needs + bash/sed/awk and run the script ;)
18:22:10  <LordAro> where would i place the script?
18:22:17  <LordAro> (relative to 32bpp sprites)
18:22:24  <Rubidium> amazing what once can do in a mere two hours. I guess more time was spent on the thread complaining the png loader got removed
18:22:32  <LordAro> :)
18:22:36  <Rubidium> it needs to be in the ogfx1_base directory
18:22:44  <Rubidium> together with empty.pcx
18:23:57  <LordAro> ogfx1_base of what? ogfx or a de-tarred 32bpp-ez tar file?
18:24:12  <LordAro> actually, i don['t know why i said ogfx :)
18:24:40  <Rubidium> the detarred ez tar
18:25:04  <LordAro> i shalt try it out :)
18:25:32  <LordAro> i guess i then place the  resulting grf file in a nightly ottd and see it it works?
18:27:55  <Rubidium> oh, it works ;)
18:28:05  <Rubidium> I just don't fancy uploading it
18:28:20  <LordAro> :P
18:28:21  *** andythenorth has quit IRC
18:28:24  <LordAro> why not?
18:29:18  <Rubidium> the file is huge
18:29:18  <Rubidium> s
18:29:19  <Rubidium> o
18:29:20  <Rubidium> i
18:29:20  <Rubidium> t
18:29:23  <Rubidium> t
18:29:25  <Rubidium> a
18:29:28  <Rubidium> k
18:29:30  <Rubidium> e
18:29:33  <Rubidium> s
18:29:35  <Rubidium> l
18:29:38  <Rubidium> o
18:29:40  <Rubidium> n
18:29:43  <Rubidium> g
18:29:51  <Rubidium> and then my internet is pretty laggy which I don't like
18:32:56  <LordAro> oh, ok
18:33:02  <LordAro> :)
18:35:08  <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Bug #3708 (Resolved): Upload Code (oberhuemer) @
18:36:07  <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Bug #3708 (Closed): Upload Code (oberhuemer) @
18:44:42  <LordAro> huh, 'pngcodec: command not found' while typing: 'pngcodec' manually does not yield this result...
18:47:02  <LordAro> same for grfcodec - works normally
18:47:09  <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Support #3728 (New): Resized templates (oberhuemer) @
18:47:21  <LordAro> does alias in .bashrc not work for bash files?
18:53:48  <Brot6> OpenGFX - Bug #3729 (New): Snow issues (PaulC) @
18:57:26  <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Support #3728: Resized templates (Leanden) @
19:08:08  * Hirundo ponders NML coding
19:08:30  <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Feature #3721: British Rail Class 390... (Leanden) @
19:09:25  <Rubidium> LordAro: possibly not
19:10:54  <LordAro> a bit of googling shows this to be the case :L
19:11:16  <LordAro> how would you add commands to your path (is that the right way to say it?)
19:11:18  <LordAro> ?
19:13:21  <Rubidium> add the path to PATH
19:13:39  <Rubidium> PATH=$PATH:/the/path/
19:20:18  <Yexo> Hirundo: I'm still not sure about the syntax for 32bpp mask files
19:20:49  <Yexo> do we want the user to provide alternative_sprites twice, once for the 32bpp sprite and once for the mask? or do we integrate the mask in the realsprite syntax somehow?
19:21:08  <Hirundo> Is the latter possible (sanely)?
19:23:18  <Yexo> a real sprite would be: [left_x, upper_y, width, height, offset_x, offset_y, filename]
19:23:45  <Yexo> an option would be something like this: [left_x, upper_y, width, height, offset_x, offset_y, filename, [mask_x, mask_y, mask_filename]]
19:24:07  <Yexo> width/height/offset_x/offset_y must be exactly the same as the normal sprite, so they can't be provided
19:24:20  <Yexo> mask_x/mask_y would be optional, default the same as left_x/upper_y
19:25:49  <Hirundo> hmmm
19:27:26  *** andythenorth has joined #openttdcoop.devzone
19:28:18  <Hirundo> Looks good in principle
19:28:33  <Hirundo> Problem might be that the number of parameter combinations becomes a bit unmanageable
19:29:50  <Hirundo> esp. once you start to include compression, omit filename, etc
19:29:58  <Yexo> yes, true
19:30:01  <Yexo> it's already that way
19:30:10  <Yexo> but for the parser it's no problem at all
19:30:32  <Yexo> first see if the last argument is an array, if so, it's the mask sprite. remove it and parse the rest as currently
19:30:44  <Hirundo> ah
19:30:53  <Hirundo> I read the nested []s as 'optional'
19:31:03  <Hirundo> having a nested array makes more sense ;-)
19:31:17  <Yexo> ah, ok :)
19:31:23  <Yexo> it was meant to be a nested array in this case
19:31:33  <Hirundo> That's OK with me
19:32:44  <Hirundo> then 'mask_file' could be an additional optional parameter for the alternative_sprites block
19:32:56  <Yexo> yes, I was planning that too :)
19:33:16  <Hirundo> so as an edge (perhaps often-occuring) case, mask would be []
19:33:20  <Yexo> in that case it could end up being an empty array
19:33:29  <Yexo> I'm not sure I want to allow that
19:33:37  <Yexo> on the other hand, why not?
19:34:03  <Hirundo> I see no reason why not
19:34:08  <Yexo> filename as argument to alternative_sprites is only more clear when there are multiple sprites that use the same file
19:34:27  <Yexo> nvm me
19:34:30  <Yexo> empty would be fine :)
19:34:55  * andythenorth does ow-in-the-brain a bit
19:35:14  <Hirundo> Yexo: Any suggestions wrt issues I could work on?
19:35:23  <Yexo> 32bpp sprites? :p
19:36:02  <andythenorth> pixel generator? :D
19:36:05  <LordAro> Rubidium: i still can't get it to work :( "Unknown NFO file version: 32.  Skipping file."
19:36:07  <Yexo> I did start, but the only thing I did was remove some obsolete code (not even committed yet)
19:36:11  <Yexo> so feel free to take over
19:37:32  <Hirundo> OK, will do
19:50:28  <Hirundo> Are there any 32bpp sprites available for testing purposes?
19:51:02  <Yexo> on jupix repo
19:51:06  <Yexo> or in the 32bpp forum
19:51:11  <Yexo> but nothing ready-made for a project
19:51:26  <LordAro> <-- take your pick :)
19:51:55  <LordAro> expect i splet that wrong :L
19:52:16  <LordAro> <-- better
19:54:40  <Rubidium> LordAro: you need a much newer version of grfcodec
19:55:11  <LordAro> i have r900 grfcodec, 4.0.0 nforenum
19:55:35  <Rubidium> that's ancient
19:55:42  <Rubidium> you need a recent nightly
19:56:09  <LordAro> i downloaded the latest version from download-grfcodec-nightly
19:57:13  <Rubidium> LordAro: was that error from nforenum? Then you need to use the one from grfcodec
19:57:30  <Rubidium> grfcodec and nforenum should have the same version
19:57:38  <LordAro> huh
19:58:33  <Rubidium> nforenum is in the grfcodec package
19:58:43  <LordAro> ok, i have r900 nforenum, but the terminal is using a 4.0.0 version from somewhere...
19:59:57  <Terkhen> which nforenum? :)
20:00:27  <LordAro> shush :P
20:00:54  <LordAro> ah, it seems the ubuntu repo 'default' didn't uninstall correctly
20:01:00  <Rubidium> but nforenum isn't 100% necessary I think
20:11:47  *** LordAro_ has joined #openttdcoop.devzone
20:14:22  *** LordAro is now known as Guest3706
20:14:22  *** LordAro_ is now known as LordAro
20:16:43  *** Guest3706 has quit IRC
20:17:59  * Terkhen meant to use the command which :)
20:18:56  <LordAro> i guessed as much a few minutes ago
20:18:57  <LordAro> :)
20:19:30  <LordAro> basically i hadn't realised that nforenum was a separate package (according to ubuntu repos) and i hadn't yet uninstalled it :L
20:26:14  <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Feature #3721: British Rail Class 390... (oberhuemer) @
20:29:16  <Rubidium> LordAro: but you can remove the nforenum line from the script
20:29:35  <LordAro> i've sorted it now :)
20:35:46  *** JVassie has joined #openttdcoop.devzone
20:37:43  <Rubidium> so you got a nice GRF by now? ;)
20:39:39  <Rubidium> @calc (1-48/55)*100
20:39:39  <Webster> Rubidium: 12.7272727273
20:40:09  <Rubidium> oh... 12% size reduction by using only chunked instead of non chunked ;)
20:42:02  <LordAro> no :P
20:42:21  <LordAro> "Insufficient meta data in sprite 1299"
20:42:47  <LordAro> (thats after commenting out the nforenum line as it was giving me problems)
20:44:09  <Rubidium> what png is that?
20:44:23  <LordAro> no idea :L
20:44:40  <LordAro> how can i find out?
20:44:41  <Rubidium> open the nfo and find that sprite ;)
20:45:12  <Rubidium> unless... nforenum didn't run, so it wasn't renumbered
20:45:22  <Rubidium> and thus the sprite numbers are all -1
20:46:10  <Rubidium> you got the dev nightlies tar of today, or do you have something else?
20:46:32  <LordAro> i have one of a few days ago, but i don't think anythings changed
20:47:04  <Rubidium> well, I have no clue what's going wrong without more information
20:47:12  <Rubidium> though it works for me
20:47:34  <LordAro> i'll have another go later with the latest
21:18:51  <Brot6> OpenGFX+ Airports - Revision 170:e1b7585406d9: Fix: some alignment and wrong sprite usage errors (yexo) @
22:15:50  <Brot6> NewGRF Meta Language - Feature Request #3712: New 32 bpp format (Hirundo) @
22:24:05  <Brot6> BANDIT - steel_trailer.png (andythenorth) @
22:25:08  *** frosch123 has quit IRC
22:35:33  <Brot6> BANDIT - Revision 291:abbcdb838a81: Codechange: draw a better flat trailer (andythenorth) @
22:38:20  *** andythenorth has quit IRC
22:47:29  *** JVassie has quit IRC
23:23:38  *** LordAro has quit IRC
23:26:52  *** ODM has quit IRC

Powered by YARRSTE version: svn-trunk