Times are UTC Toggle Colours
02:50:14 <Brot6> DictatorAI - Revision 197:291ccd58ebd1: - decrease vehnextprice to lower our money kept for buyin... (krinn) @ http://dev.openttdcoop.org/projects/ai-dictator/repository/revisions/291ccd58ebd1 02:50:14 <Brot6> DictatorAI - Revision 198:513bb209639d: - Add missing new file dependency (krinn) @ http://dev.openttdcoop.org/projects/ai-dictator/repository/revisions/513bb209639d 06:09:26 <Brot6> Central European Train Set - Feature #3620: Force 32 bpp (Elukka) @ http://dev.openttdcoop.org/issues/3620#change-9748 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: http://hg.openttdcoop.org/nml/rev/009996f5c92c?revcount=120 07:16:53 *** JVassie has quit IRC 07:57:19 <planetmaker> Ammler: recursion is recursive? http://bundles.openttdcoop.org/opengfx/nightlies/ERROR/r940/opengfx-r940-openttd.log 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) @ http://dev.openttdcoop.org/issues/3719#change-9749 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) @ http://dev.openttdcoop.org/issues/3717#change-9750 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) @ http://dev.openttdcoop.org/issues/3716#change-9751 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) @ http://dev.openttdcoop.org/issues/3716#change-9752 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> http://paste.openttdcoop.org/show/1146/ <-- 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: http://www.gnu.org/software/make/manual/make.html#Makefile-Conventions 10:34:16 <Webster> Title: GNU `make' (at www.gnu.org) 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> http://paste.openttdcoop.org/show/1147/ 10:42:21 <Ammler> http://paste.openttdcoop.org/show/1148/ 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 - http://bundles.openttdcoop.org/opengfx/nightlies/r940 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) @ http://dev.openttdcoop.org/issues/3706#change-9754 11:36:26 <Brot6> Central European Train Set - Revision 647:df9bf7b6d0bd: some vague attempt at an SBB core set (Eddi) @ http://dev.openttdcoop.org/projects/cets/repository/revisions/df9bf7b6d0bd 11:47:11 *** andythenorth has joined #openttdcoop.devzone 11:47:58 <Brot6> cets: update from r646 to r647 done (212 warnings) - http://bundles.openttdcoop.org/cets/push/r647 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) @ http://dev.openttdcoop.org/issues/3722 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) @ http://dev.openttdcoop.org/projects/make-nml/repository/revisions/697ad2203af5 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) - http://bundles.openttdcoop.org/cets/nightlies/r647 12:06:18 <Brot6> britrains: update from to r3 done (4 warnings) - http://bundles.openttdcoop.org/britrains/push/r3 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 http://www.atlassian.com/software/views/open-source-license-request 12:19:18 <Webster> Title: Open Source License Request (at www.atlassian.com) 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 http://www.atlassian.com/licensing/purchase-licensing#source-1 12:23:04 <Webster> Title: Atlassian Purchasing and Licensing FAQ | Atlassian (at www.atlassian.com) 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) - http://bundles.openttdcoop.org/opengfx/nightlies/ERROR/r940 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) @ http://dev.openttdcoop.org/issues/3723 12:47:38 <Brot6> Dutch Trains 2.0 - Feature #3724 (New): Mat '35, '36, '40 and '46 (Voyager1) @ http://dev.openttdcoop.org/issues/3724 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) @ http://dev.openttdcoop.org/issues/3632#change-9757 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) @ http://dev.openttdcoop.org/issues/3708#change-9753 13:23:04 <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Feature #3721 (Assigned): British Rai... (Leanden) @ http://dev.openttdcoop.org/issues/3721 13:23:04 <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Feature #3721 (Assigned): British Rai... (Leanden) @ http://dev.openttdcoop.org/issues/3721#change-9755 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 - http://bundles.openttdcoop.org/opengfx/nightlies/r940 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) - http://bundles.openttdcoop.org/dutchtrains/nightlies/r222 17:21:53 <Brot6> Makefile for NML - Bug #3725 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/3725 17:22:47 <Brot6> britrains: update from to r3 done (4 warnings) - http://bundles.openttdcoop.org/britrains/nightlies/r3 17:24:45 <Brot6> airportsplus: update from r162 to r169 done - http://bundles.openttdcoop.org/airportsplus/nightlies/r169 17:28:05 <Brot6> Makefile for NML - Bug #3726 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/3726 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) @ http://dev.openttdcoop.org/issues/3727 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> http://rbijker.net/openttd/empty.pcx 18:16:32 <Rubidium> http://rbijker.net/openttd/create 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) @ http://dev.openttdcoop.org/issues/3708#change-9758 18:36:07 <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Bug #3708 (Closed): Upload Code (oberhuemer) @ http://dev.openttdcoop.org/issues/3708#change-9759 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) @ http://dev.openttdcoop.org/issues/3728 18:47:21 <LordAro> does alias in .bashrc not work for bash files? 18:53:48 <Brot6> OpenGFX - Bug #3729 (New): Snow issues (PaulC) @ http://dev.openttdcoop.org/issues/3729 18:57:26 <Brot6> Britrains (Python Scripted British Train Set for Openttd) - Support #3728: Resized templates (Leanden) @ http://dev.openttdcoop.org/issues/3728#change-9760 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) @ http://dev.openttdcoop.org/issues/3721#change-9761 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> http://jupxi.info/openttd/gfxdev-repo <-- take your pick :) 19:51:55 <LordAro> expect i splet that wrong :L 19:52:16 <LordAro> http://jupix.info/openttd/gfxdev-repo <-- 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) @ http://dev.openttdcoop.org/issues/3721#change-9762 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) @ http://dev.openttdcoop.org/projects/airportsplus/repository/revisions/e1b7585406d9 22:15:50 <Brot6> NewGRF Meta Language - Feature Request #3712: New 32 bpp format (Hirundo) @ http://dev.openttdcoop.org/issues/3712#change-9763 22:24:05 <Brot6> BANDIT - steel_trailer.png (andythenorth) @ http://dev.openttdcoop.org/attachments/download/2520/steel_trailer.png 22:25:08 *** frosch123 has quit IRC 22:35:33 <Brot6> BANDIT - Revision 291:abbcdb838a81: Codechange: draw a better flat trailer (andythenorth) @ http://dev.openttdcoop.org/projects/bandit/repository/revisions/abbcdb838a81 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