Times are UTC Toggle Colours
07:33:15 <DevZone> Project OpenGFX build #83-push: SUCCESS in 7 min 59 sec: https://jenkins.openttdcoop.org/job/opengfx/83/ 07:36:19 *** Supercheese has quit IRC 08:30:12 *** zooks has joined #openttdcoop.devzone 09:58:15 *** frosch123 has joined #openttdcoop.devzone 11:42:57 *** zooks has quit IRC 12:11:58 *** zooks has joined #openttdcoop.devzone 14:26:01 *** zooks has quit IRC 16:06:46 *** ODM has joined #openttdcoop.devzone 16:50:36 <DevZone> Project Iron Horse build #350-push: SUCCESS in 3 min 2 sec: https://jenkins.openttdcoop.org/job/iron-horse/350/ 16:50:46 <DevZone> Project xussrset - Trains from Russia build #73-push: SUCCESS in 3 min 26 sec: https://jenkins.openttdcoop.org/job/xussrset/73/ 16:57:53 <DevZone> Project FIRS Industry Replacement Set build #39-push: SUCCESS in 7 min 16 sec: https://jenkins.openttdcoop.org/job/firs/39/ 17:21:43 <DevZone> Project NML - NewGRF Meta Language build #105-nightlies: SUCCESS in 3 min 7 sec: https://jenkins.openttdcoop.org/job/nml/105/ 17:25:47 *** oskari89 has joined #openttdcoop.devzone 18:08:53 <DevZone> Project finnishtrams build #8-nightlies: SUCCESS in 2 min 16 sec: https://jenkins.openttdcoop.org/job/finnishtrams/8/ 18:22:14 <DevZone> Yippee, build fixed! 18:22:14 <DevZone> Project OpenGFX+ Landscape build #30-push: FIXED in 26 min: https://jenkins.openttdcoop.org/job/ogfx-landscape/30/ 18:27:40 <DevZone> Project Finnish Rail Infrastructure - Rails build #127-nightlies: SUCCESS in 1 min 3 sec: https://jenkins.openttdcoop.org/job/frissrails/127/ 18:31:17 <DevZone> Project Nutracks build #54-nightlies: SUCCESS in 41 sec: https://jenkins.openttdcoop.org/job/nutracks/54/ 18:49:32 <DevZone> Project Iron Horse build #351-nightlies: SUCCESS in 1 min 51 sec: https://jenkins.openttdcoop.org/job/iron-horse/351/ 18:54:04 *** Supercheese has joined #openttdcoop.devzone 19:00:08 *** andythenorth has joined #openttdcoop.devzone 19:00:57 *** andythenorth has joined #openttdcoop.devzone 19:06:02 <DevZone> Project OpenGFX build #84-nightlies: SUCCESS in 7 min 26 sec: https://jenkins.openttdcoop.org/job/opengfx/84/ 19:52:28 <DevZone> Project OpenGFX+ Landscape build #31-push: SUCCESS in 27 min: https://jenkins.openttdcoop.org/job/ogfx-landscape/31/ 19:52:53 <Supercheese> 27 minutes, whew 19:55:18 <planetmaker> yeah. It has to generate nearly all sprites 19:55:35 <planetmaker> https://jenkins.openttdcoop.org/job/ogfx-landscape/31/console <-- and that's a lot :-) 19:55:42 <planetmaker> and it cannot use grf caching 19:55:49 <planetmaker> thus locally it's much faster 19:56:06 <planetmaker> and it's limited to one core ;-) 19:56:29 <planetmaker> while locally I let it use at least 6. 19:57:13 <Rubidium> planetmaker: got around to testing my hunch on Windows and OSX? 19:59:43 <planetmaker> I've not yet finnished setting up the compile environment locally to create the windows one... that requires some specially-crafted wine config and python installed therein 20:04:17 <planetmaker> and on OSX I'm repairing my install... I must have left it borked when I toyed with PIL/pillow testing :S 20:05:16 <andythenorth> :P 20:05:42 <andythenorth> planetmaker: I now have guaranteed foolproof python setup on OS X fwiw 20:05:50 <andythenorth> (unless you can find a bigger class of fool) 20:05:50 <planetmaker> can you document it? 20:06:11 <andythenorth> this is a generalised approach, not specific to nml 20:06:34 <Rubidium> oh... let me loose on it ;) 20:06:37 <andythenorth> it avoids issues with Apple python, setuptools, and this insane 'install system wide python modules' approach 20:07:04 * Rubidium has scored points on high school for hanging a Mac with merely magic fingers ;) 20:07:07 <andythenorth> planetmaker: I can copy and paste from our work python instructions :P 20:07:19 <andythenorth> we invested in figuring it out once and for all, after many days lost 20:07:43 *** gelignite has joined #openttdcoop.devzone 20:14:26 <andythenorth> planetmaker: foolproof-ish http://paste.openttdcoop.org/show/2752/ 20:14:39 <andythenorth> YMMV 20:15:06 <andythenorth> this method survives OS X upgrades and installs, and eliminated a lot of voodoo and silly crap 20:16:05 <andythenorth> concept 1: stay away from the Apple-supplied python, and *never* touch macports 20:16:14 <andythenorth> concept 2: isolate projects with disposable virtualenvs 20:16:48 <planetmaker> I mix apple python with macports :-P 20:16:54 <andythenorth> been there done that :( 20:17:01 <andythenorth> if you're not trying to use python for multiple projects, and you never upgrade OS X, then the method above may seem overkill 20:17:07 <andythenorth> but it's a small investment to avoid a lot of pain 20:17:21 <planetmaker> yeah, I likely are right 20:18:22 <andythenorth> we very nearly switched to doing all development on Linux VMs on OS X, but there was a rebellion :P 20:18:25 <andythenorth> and the issue got fixed 20:29:30 <planetmaker> let's screw it more and install pillow :D 20:34:44 <planetmaker> Rubidium, ok, OSX is fine. And for windows I rather commit that and have devzone build the binary 20:34:53 <planetmaker> you want to take the honour? :-) 20:37:26 <Rubidium> dare I 20:37:44 <Rubidium> what to use a commit message? 20:37:56 <Rubidium> something that doesn't close the bug (yet) 20:40:09 <planetmaker> hm... Change #xxx 20:45:05 <DevZone> Project NML - NewGRF Meta Language build #106-push: SUCCESS in 2 min 32 sec: https://jenkins.openttdcoop.org/job/nml/106/ 20:45:32 <DevZone> Project ISR Industrial Station Renewal build #46-push: SUCCESS in 34 sec: https://jenkins.openttdcoop.org/job/isr/46/ 20:45:35 <Rubidium> does it work? ;) 20:46:33 <planetmaker> what work? 20:46:44 <planetmaker> nmlc --version? 20:46:54 <planetmaker> oh, does it work. Let's see 20:46:55 <Rubidium> yup, in that case where it used to fail 20:54:03 <planetmaker> hm. version of nmlc is unknow 20:54:16 <planetmaker> so, I fear it didn't exactly help :-( 20:54:44 <Rubidium> at least it isn't a wrong version anymore ;) 20:56:34 <planetmaker> true 20:57:06 <Rubidium> so __file__ or realpath isn't doing the same on Windows as on Linux 20:57:09 <Rubidium> but which? 21:03:02 <planetmaker> or that gets screwed by cxfreeze somewhere, where the exe is made from the stuff 21:03:46 <Rubidium> I guess it needs more experimenting, but using the live repository isn't the right way to do it 21:04:14 <Rubidium> first step would be printing __file__ and all the sub steps like realpath(__file__) etc. 21:04:14 <planetmaker> no, it's not 21:04:36 <planetmaker> so... I need that windows here actually work :-) 21:05:13 <Taede> tried abspath? 21:05:55 <Taede> or does that not give the desired output? 21:06:06 <Rubidium> no clue 21:06:23 <Rubidium> mostly what I did was a stab in the dark without knowing much of python 21:06:27 <planetmaker> hm, how do I exit python on windows command line? 21:06:36 <planetmaker> in linux / osx it's ctrl+d. But on windows? 21:06:49 <Rubidium> but keeping stabbing in the dark is kinda a waste of revisions and such 21:07:04 <Rubidium> ctrl+d? ctrl+c? 21:07:12 <Rubidium> task manager -> kill it with fire!!!! 21:07:21 <planetmaker> :-) 21:07:21 <Taede> os.chdir(os.path.dirname(os.path.abspath(__file__))) <- what i use to change the cwd to where the python file is located 21:07:26 *** ODM has quit IRC 21:07:28 <Taede> untested for windows though 21:07:52 <Rubidium> path = os.path.dirname" target="_blank">os.path.dirname(os.path.dirname" target="_blank">os.path.dirname(os.path.realpath(__file__))) 21:08:22 <planetmaker> double? 21:08:33 <Rubidium> yes 21:08:40 <Taede> the outer .dirname seems a bit surplus 21:09:15 <Taede> but try path = os.path.dirname(os.path.abspath(__file__)) ? 21:09:38 <Rubidium> os.path.realpath(__file__) gets (for me) "${the path that I want}/nml/version_info.py" 21:10:00 <Rubidium> I want to strip the version_info.py (first dirname), and then the nml (second dirname) 21:10:31 <Rubidium> planetmaker: the exe doesn't even have a .hg folder, so where would it get its version from in any case? 21:11:23 <planetmaker> a packaged nml also has a version. hm. 21:11:36 <Rubidium> I reckon that __version__ isn't created/compiled into the exe 21:12:37 <Taede> path = os.path.dirname" target="_blank">os.path.dirname(os.path.dirname" target="_blank">os.path.dirname(os.path.abspath(__file__))) then 21:16:20 <Rubidium> the path isn't the problem, or at least isn't the problem that is currently faced 21:16:24 <Rubidium> yay oversight ;) 21:18:26 <planetmaker> hm... I wonder. nml/__version__.py should exist. Building first runs the regression tests. Which should generate the version file. hm 21:19:02 <planetmaker> ah, there's another version place... 21:19:31 <planetmaker> nml/get_version.py 21:19:42 <planetmaker> err... nml/version_info.py 21:21:59 <planetmaker> but I think you're right nevertheless.... nml/__version__.py might not be generated... and cxfreeze might need that 21:26:43 <planetmaker> hm... let's try build with a slight modification to the build process 21:27:14 <planetmaker> calling ./setup.py --version before freezing. Thus generating nml/__version__.py 21:27:35 <DevZone> Project NML - NewGRF Meta Language build #107-push: SUCCESS in 1 min 4 sec: https://jenkins.openttdcoop.org/job/nml/107/ 21:28:23 *** andythenorth has quit IRC 21:29:25 <planetmaker> success 21:29:36 <planetmaker> thank you rubidium :-) 21:30:17 <planetmaker> somewhat success at least. I should change it to the days_since_2000 as well 21:31:18 <Rubidium> oh... that's looming over grfcodec as well, ain't it? 21:31:23 <planetmaker> yes 21:31:38 <planetmaker> it's not that critical there as it's a repo w/o branches 21:31:53 <planetmaker> nml has branches, though. Thus 2037 is actually wrong... 21:32:08 <planetmaker> would I have permission to change grfcodec in that respect? 21:32:28 <planetmaker> (or if you want, do that) 21:32:29 <Rubidium> as long as you don't break openttd's configure script ;) 21:32:48 <planetmaker> versions will only increase. we're at day/version 5049 now :-) 21:33:35 <planetmaker> I'd only want to change the reported version. Not the format it's reported in 21:33:42 <planetmaker> for that very reason you mentioned 21:33:48 <planetmaker> same actually with NML 21:35:30 <Rubidium> though I wonder whether it gets confusing when rREV is about the same as rDAYS 21:35:48 <planetmaker> hm? 21:37:03 <Rubidium> "I'm building r5048, but the binary says r5049" 21:37:39 <planetmaker> days_since_2000 references the commit date, thus should be unique 21:37:51 <Rubidium> I know... but... 21:38:06 <planetmaker> well, would not for many commits in a single day 21:38:27 <Rubidium> imagine the case where the commit/revision count of a repository is roughly equal to the number of days since 2000 21:39:18 <planetmaker> yes, what then? 21:39:28 <Rubidium> and someone new-ish or forgetful tries to figure out what revision is being used. Then whatever comes out of number of days is close to the revision, which might confuse things 21:40:27 <planetmaker> yes. Iff. But the numeric version of any DVCS is basically pointless... only the hash is unique 21:40:32 <Rubidium> e.g. now is 5049 days since, but the repository goes to r5053. I do a hg up and compile. I see r5049 in my --version and wonder why that doesn't match with the revision I'm using 21:41:04 <planetmaker> the repository goes to 5053:af3927b3a43 21:41:28 <Rubidium> mostly due to those numbers being not, relatively easily, identifiable as being days instead of revision 21:41:30 <frosch123> easy solution, just commit more 21:42:11 <planetmaker> sorry, I don't really get the problem you try to construct. 21:42:17 <Rubidium> planetmaker: and you type hg up -r 5053:abcdef1234? 21:42:26 <planetmaker> I know the days-since-2000 is bad for many commits a day. But... we rarely have that 21:42:56 <planetmaker> Rubidium, no. hg up -rXXX. Where XXX is either 5053 or abcdef1234 21:43:07 <Rubidium> it's not about many commits a day, it's about it not being recognisable as something that is likely not a changeset number 21:43:44 <frosch123> does it actually put a "r" in front of the number? 21:43:51 <Rubidium> especially since grfcodec will keep it's r5048 version numbering 21:44:01 <frosch123> an "r" would indeeed be confusing 21:44:15 <planetmaker> I changed it in projects to 'v5053' instead of r 21:44:37 <Rubidium> but that breaks openttd's configure script 21:44:53 <planetmaker> VERSION :2013-10-28 (5049:6990c2d1af9aM) 21:44:54 <planetmaker> yes 21:46:44 <Rubidium> r20131028 will probaby be slightly less worse 21:47:05 <planetmaker> or we simply break version detection 21:47:09 <Rubidium> not sure whether the configure handles r20131028+abcdef123456 properly 21:49:43 <Rubidium> but then either trunk or stable fails to detect grfcodec properly 21:53:04 <planetmaker> for stable we have a release of grfcodec which compiles it. And we could have for trunk another which does so 21:55:48 <Rubidium> that's not really the problem... but on my system I don't have a dual installation of stable and trunk grfcodec 21:56:06 <Rubidium> if I compile openttd, it's usually with grfcodec HEAD 21:56:33 <Rubidium> and especially with backporting that is occasionally needed to still function 21:57:13 <Rubidium> which is where my worries w.r.t. changing the way versions are written down for grfcodec comes from 21:57:16 *** oskari89 has quit IRC 21:57:56 <Rubidium> anyhow... I'm too sleepy to have coherent thoughts 22:03:42 <planetmaker> same here actually. Sleep well :-) 22:08:10 *** gelignite has quit IRC 23:05:01 *** frosch123 has quit IRC