Times are UTC Toggle Colours
02:45:14 <Brot6> Redmine - Revision 3811: Sanitize image links and handle nils in the toc formatter. #5445 (edavis10) @ http://dev.openttdcoop.org/projects/redmine/repository/revisions/3811 02:45:14 <Brot6> Redmine - Revision 3812: Merged r3811 from trunk. (edavis10) @ http://dev.openttdcoop.org/projects/redmine/repository/revisions/3812 03:27:21 <Brot6> Swedish Rails - Feature #1036: Add more elaborate level crossings for railtypes (planetmaker) @ http://dev.openttdcoop.org/issues/1036#change-2717 03:29:04 <Brot6> Swedish Rails - Feature #1036: Add more elaborate level crossings for railtypes (planetmaker) @ http://dev.openttdcoop.org/issues/1036#change-2717 03:44:48 <Brot6> Redmine - Revision 3813: Force string comparison for login search to be case sensitive on MySQL. ... (edavis10) @ http://dev.openttdcoop.org/projects/redmine/repository/revisions/3813 04:04:54 <Brot6> NewGRF Meta Language - Revision 490:ab2a9bd9c4cf: Doc: Mention some global parameters (planetmaker) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/ab2a9bd9c4cf 04:35:07 <Brot6> NewGRF Meta Language - Revision 491:6db051e5ff56: Doc: Rename the TTDPATCH flags into CONFIGFLAG ... (planetmaker) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/6db051e5ff56 06:31:40 *** ODM has joined #openttdcoop.devzone 07:07:47 <Brot6> OpenGFX+ - Revision 31:2fddbc3d6e5b: Fix: dependency check was broken (planetmaker) @ http://dev.openttdcoop.org/projects/ogfxplus/repository/revisions/2fddbc3d6e5b 07:25:16 *** andythenorth has joined #openttdcoop.devzone 07:26:19 <Brot6> Swedish Rails - Revision 78:b3de947f6d69: Fix: Dependency check was broken (planetmaker) @ http://dev.openttdcoop.org/projects/swedishrails/repository/revisions/b3de947f6d69 07:30:43 <Brot6> Example NewGRF Project - Revision 101:3d049157d52a: Fix: [NML] Dependency check was broken (planetmaker) @ http://dev.openttdcoop.org/projects/newgrf-makefile/repository/revisions/3d049157d52a 07:53:58 <Brot6> Swedish Rails - Revision 79:edeb7dd29f8c: Change: Implement drive side and parameter choice for l... (planetmaker) @ http://dev.openttdcoop.org/projects/swedishrails/repository/revisions/edeb7dd29f8c 08:36:20 *** dan123 has joined #openttdcoop.devzone 08:36:45 <dan123> hello to all 08:37:48 <dan123> I was messing around with 2cctrainset and found where wagon weights are stored (and set to 0t) 08:38:17 <Rubidium> and now they don't accelerate anymore? 08:38:45 <dan123> well, I couldn't complie it (some strange issues with my linux) 08:38:50 <dan123> :/ 08:39:36 <dan123> "Error: Encountered invalid character looking for literal byte. 08:39:36 <dan123> While reading sprite:610" 08:39:57 <dan123> I did try to change locale to en_US, but it didn't change a thing 08:40:03 <Rubidium> so there's something wrong with that sprite 08:40:47 <dan123> and that's output I get not only from version modified by me, but also vanila one 08:41:45 <Rubidium> what version of grfcodec? 08:42:19 <dan123> 0.9.10 08:42:22 <Rubidium> (assuming it is grfcodec spitting that error) 08:42:42 <dan123> yes 08:42:54 <Rubidium> "only" 0.9.10? Or 0.9.10 r....? 08:43:41 <dan123> complied version form http://www.ttdpatch.net/grfcodec/ 08:44:17 <Rubidium> try it with the one from http://www.openttd.org/en/download-grfcodec 08:45:11 <Rubidium> it's roughly 3.5 years newer 08:47:11 <dan123> now it worked, thanks! 08:48:22 <Rubidium> everything from the ttdpatch side has a bit of a "release new version" problem 09:05:02 <dan123> Rubidium: well... 09:05:13 <dan123> it *works* as intended :) 09:05:42 <dan123> now only problem is to get around what those weights should be :) 09:13:40 <planetmaker> dan123, did you get the 2cctrainset's source? 09:13:47 <dan123> hmm, almost as intended 09:13:47 <dan123> for some strange reason 1st and 2nd gen have the same masses 09:13:57 <dan123> also 3rd and 4th 09:14:00 <dan123> planetmaker: yes 09:14:12 <planetmaker> dan123, if you find errors / have improvements, patches for the trainset are warmly welcome 09:14:39 <planetmaker> The (main) author is currently on vacation, but still. 09:14:41 <dan123> that's why I'm here :) 09:14:43 <planetmaker> If you post patches to the bug tracker or post in the forum thread, they'll be noticed 09:15:05 <planetmaker> ok :-) Sweet 09:15:18 <planetmaker> There are not many around who actually dare to mess with newgrfs 09:45:40 *** KenjiE20 has joined #openttdcoop.devzone 10:35:10 *** MindB_ender has joined #openttdcoop.devzone 10:35:32 <MindB_ender> ola's 10:37:05 <Rubidium> ohla 10:39:20 <MindB_ender> you knowledgable about Openttd svn? I use tortoise normally for other projects, but I'm kinda confused by the whole setup on the OpenTTD site. 10:41:55 <MindB_ender> normally i'd just make a mydocs "OpenTTD" folder and do a "create repository here" via tortoise. But i see all links are to c:/dev/ etc. Just wondering if that's code related, cause i just want to do data (gfx) changes/addon. 10:44:52 <MindB_ender> (uhm... "check out") 10:45:05 <planetmaker> MindB_ender, if you're just into writing (new)grfs, you might just want to a) look at existing projects found here and b) look at http://wiki.ttdpatch.net/tiki-index.php?page=NewGraphicsSpecs and maybe, just maybe look at NML http://dev.openttdcoop.org/projects/nml and the swedishrails project as a first example 10:45:14 <planetmaker> you don't need to chew through OpenTTD code in order to develop graphic extensions for it 10:46:30 <MindB_ender> that's what i thought 10:46:58 <MindB_ender> this link seems more useful, thanks. 10:47:24 * MindB_ender thought the svn may have a /art or /data folder he would have to use 10:48:41 <planetmaker> it does does. Somewhat. 10:49:06 <planetmaker> But have a look at all the projects found at http://dev.openttdcoop.org 10:49:15 <planetmaker> those are a range of more or less advanced newgrf extensions for OpenTTD 10:49:39 <planetmaker> Personally I find it VERY helpful to have existing code to start from 10:49:43 <planetmaker> I don't know what your intentions are. 10:50:20 <MindB_ender> just want to do basically a "skin" mod, not so much changing the game as just the graphics and strings 10:50:39 <planetmaker> If you're totally new to this, I very much like to recommend to look at the new grf language which is currently developed, NML 10:50:39 <planetmaker> it's much easier to read than the byte code which all graphics were programmed in so far 10:51:14 <planetmaker> strings might need patching (that's what translations are for) - except if they are part of a newgrf extension 10:51:36 <MindB_ender> any chance of the project going png instead of sticking to pcx? i'm fine with pcx and 256 palettes etc, just think i'll miss having real opacity:) 10:51:39 <planetmaker> if it's just for simple replacement of sprites... easy 10:52:05 <planetmaker> check out NML ;-) 10:52:05 <planetmaker> but the palette won't change 10:52:09 <planetmaker> what you can do is 32bpp 10:52:18 <planetmaker> you can replace each 8bpp sprite by a 32bpp sprite 10:52:30 <MindB_ender> ah yes, game needs to be able to change the company colors i guess 10:52:39 <planetmaker> there's a whole 32bpp replacement project also 10:52:48 <planetmaker> yes, for example 10:53:08 <planetmaker> but it also does that in 32bpp 10:53:39 <MindB_ender> using a greyscale pic? 10:53:39 <planetmaker> but for starters I advise to go for 8bpp with the palette 10:53:44 * MindB_ender nods 10:53:44 <planetmaker> if you want more than 1:1 replacement with just more colours 10:54:07 <planetmaker> MindB_ender, 8bpp isn't gray scale. The colours actually are quite well defined 10:54:39 <planetmaker> Everything you usually see in OpenTTD is based on that palette 10:55:04 <MindB_ender> well i'm more wanting to make a sci-fi type deal out of the existing game. so really just a 1:1 data replacement. I like the gameplay as it is, so for now not really wanting to touch code. (well, ok.. i'm just no coder) 10:55:39 <planetmaker> and there is and won't be a way around that - except the 32bpp thingy 10:55:39 <planetmaker> Ok, you can do a Sci-Fi style without looking at the source 10:56:09 <MindB_ender> For the 32bpp greyscale could be colored by code for compay colors, is what i meant. 10:56:39 <planetmaker> You mostly need MANY sprites and probably to make it somewhat fitting you also need to get into coding: vehicles want different stats, industries and houses have different properties then most likely - even if they generally on average stay the same 10:57:05 <planetmaker> MindB_ender, there's some means to identify company colour in 32bpp. Dunno how though 10:57:05 <planetmaker> But it's well-established 10:57:14 <MindB_ender> but thanks for the link to that tutorial. i'll first will have to just go through and see how far i get with the existing 8bpp stuff for quite a while i guess:) 10:57:45 <planetmaker> MindB_ender, how far you go, you'll 99% likely need everything at least also in 8bpp. 10:58:05 <planetmaker> as that's the common denominator for everything 10:58:39 <planetmaker> but... don't worry about that when drawing graphics. 10:58:41 <planetmaker> There exists a half-done Marsian theme 10:59:07 <planetmaker> http://george.zernebok.net/newgrf/downloadsold.html 10:59:08 <Webster> Title: Download new graphics (at george.zernebok.net) 10:59:47 * MindB_ender favs it 11:00:06 <planetmaker> But be warned: to create a full replacement for even one climate means to draw like 3000+ sprites at least 11:00:26 <MindB_ender> no biggie. that's why i picked tttd to mod in the first place 11:00:39 <planetmaker> and as piece of advise:start with the drawing :-) 11:00:48 <MindB_ender> nah, rendering>:) 11:01:09 <planetmaker> Post your results, also intermediate, in the forums 11:01:09 <planetmaker> it will excite interest 11:01:29 <MindB_ender> the moment i do have results, of course i will:) 11:02:07 <planetmaker> also like "this is a set of ground sprites" 11:02:10 <planetmaker> "this is an assortment of foundations" 11:02:17 <planetmaker> not like already the whole thing :-) 11:02:45 <MindB_ender> recently found that to do lotsa sprites quick, the fastest ways are just 3dmax, rendering out animations to loose bitmaps and bulkprocess those to the sprite format 11:03:06 <planetmaker> the whole thing (all graphics) took like 3 years to finish. With various people contributing drawings, and various people coding them 11:03:15 * MindB_ender nods 11:03:16 <planetmaker> if you know that and it works for you awesome. :-) 11:03:39 * planetmaker has no clue about drawing graphics 11:03:55 <MindB_ender> i'll prolly just go for vehicles first, then buildings and perhaps skip environment entirely 11:03:56 * ODM has no clue period:P 11:04:27 <Rubidium> be very aware of the perspective (or whatever it's called) 11:04:34 <MindB_ender> not really interested in a "new game", more just a different setting.:) 11:05:09 <planetmaker> MindB_ender, well, "different" is a relative thing 11:05:09 <MindB_ender> yes, another reason for max. you set the camera and lighting right once and your perspective is fine for everything. 11:05:39 <planetmaker> But you certainly don't want your new skyranger having the stats of a 1930 turboprop machine? 11:05:58 <MindB_ender> well, gfx first. stats and strings later:) 11:06:12 <planetmaker> :-) 11:06:16 <planetmaker> good approach 11:06:17 <MindB_ender> although, in star wars for example.. the stats of the fighters are those of ww2 ones. 11:06:39 <planetmaker> he :-) 11:06:39 <MindB_ender> it would all be relative afterall. 11:07:05 <planetmaker> yeah 11:07:39 <Brot6> NewGRF Meta Language - Revision 492:785dc43dbfc9: Change: failed regression test fails the build,... (Ammler) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/785dc43dbfc9 11:07:39 <planetmaker> though of course it could also be used as the frequently-sought "new vehicles past the 2050 date" extension ;-) 11:07:39 <planetmaker> then it should kinda extend stat-wise the existing set(s) 11:08:06 <planetmaker> hm... regression fails? 11:08:39 <planetmaker> nope 11:09:09 <Ammler> if the regression test fails, also build will fail 11:09:11 <MindB_ender> yes, but progressing stats beyond the 2050 also unbalances the game and is actually not as much fun as initially thought. 11:09:19 <Ammler> so my error counter became useless :-) 11:09:39 <planetmaker> in any case, MindB_ender, I'm looking forward to seeing your work :-) 11:09:39 <planetmaker> MindB_ender, yes, the balance issue is present, I fully agree 11:10:05 <planetmaker> in what way, Ammler ? 11:10:10 <MindB_ender> and thankies.. off to painstshop. latah:) 11:10:17 <planetmaker> :-) 11:10:22 *** MindB_ender has quit IRC 11:10:23 <Ammler> hmm? 11:11:07 <planetmaker> what's your 'error counter'? 11:11:22 <Ammler> before I marked the rpm as required, we had output like Compile NML from r345 to r350 done (5 errors) 11:11:39 <planetmaker> the thing which stops it from re-compiling? 11:11:55 <Ammler> we still use that for newgrfs 11:12:05 <planetmaker> yes 11:12:25 <Ammler> but in case of nml, we decided that a failed regression test should also fail building 11:12:37 <Ammler> so you don't use such a version for the grfs 11:14:05 <planetmaker> yes. 11:14:11 <planetmaker> quite reasonably :-) 11:14:36 <Ammler> basically the change I made just does silence a compiler error, not noticeable at all for you 11:15:39 <planetmaker> ok :-) 11:15:55 <Ammler> just one email fewer for me 11:17:23 <Ammler> E;%{BUILD}/regression/*.log <-- E means, it does count the lines and outputs as (XX errors) 11:17:39 <planetmaker> hehe 11:17:41 <planetmaker> hm, there should probably be a difference between warning and error 11:18:12 <Ammler> I think, it doesn't matter, our newgrfs devs wouldn't care more or less 11:18:16 <planetmaker> http://bundles.openttdcoop.org/swedishrails/nightlies/LATEST/log/swedishrails-r76-build.err.log <-- I find those errors quite pointless. And a bit sad to have always an error reported 11:18:47 <Ammler> I thought about a sed script to prefilter those 11:19:06 <planetmaker> that might be the hack we just need. 11:19:10 <planetmaker> Probably the best idea 11:19:19 <Ammler> afaik "yacc: Warning. Token 'RANDOM' defined, but not used." is valid 11:19:39 <planetmaker> the first two lines are attributed to the CF's own installation. The other two will go in time, but are NML errors rather than newgrf errors 11:20:01 <Ammler> shouldn't NML silence those? 11:20:05 <planetmaker> it is 11:20:19 <planetmaker> yes. By implementing random varaction2 11:20:27 <Ammler> I meant the md5 part 11:20:39 <planetmaker> :-) 11:20:39 <planetmaker> Hirundo is working on that 11:21:02 <Ammler> then I don't need to add a sed script, do I? 11:21:09 <planetmaker> ah. NML cannot silence the first two lines. It's warnings in yacc 11:21:09 <planetmaker> And yacc is a python package 11:21:39 <planetmaker> an installed package. Just read where the warning comes from 11:21:54 <Ammler> I think, we shouldn't silence errors, which others also might get, if the clone the repo and build those self 11:22:09 <planetmaker> it's our server installation using a package which uses a deprecated call 11:22:23 <Ammler> nono 11:22:29 <Ammler> I get the same locally 11:22:39 <planetmaker> others don't if they use other versions 11:22:45 <Ammler> I would bet, all rpm distros would get that error 11:22:45 <planetmaker> But having always a non-clean output. ALWAYS. 11:23:06 <planetmaker> That's not the point of the build errors 11:23:18 <planetmaker> it's nothing a newgrf author (nor an NML author) can fix 11:23:39 <planetmaker> only we as server admins by installing 'propery' python version 11:23:39 <planetmaker> *'proper' 11:23:47 <Ammler> that, we should ask the python pros 11:23:49 <planetmaker> As such the first two lines need to be filetered 11:23:56 <Ammler> I am not sure about. 11:24:05 <planetmaker> Ammler, you asked them. They told what I just told ;-) 11:24:22 <Ammler> yes :-) 11:25:06 <planetmaker> The error message is clear IMHO 11:25:37 <Ammler> the problem is likely the problem we have with nfo disable errors 11:25:58 <Ammler> how will we ever find out, if something of that get fixed? 11:26:06 <planetmaker> eh? 11:26:09 <planetmaker> no 11:26:15 <planetmaker> Ammler, it's completely different 11:26:18 <Ammler> if we disable error messages 11:26:34 <Ammler> we also won't notice fixes about those 11:26:39 <planetmaker> We just need to grep -v "/usr/lib/python2.6/site-packages/ply/yacc.py:74: DeprecationWarning: the md5 module is deprecated; use hashlib instead" and fine is 11:27:06 <planetmaker> we won't notice them, unless we update python on the server, e.g. the md5 module 11:27:11 <Ammler> planetmaker: then we update to python 3.0 and that error might go away 11:27:15 <Ammler> but we won't notice 11:27:39 <planetmaker> silencing errors which are way out of our control is fine. But nforenum / grfcodec, that's something we can do about the errors as we build it ourselves 11:27:39 <planetmaker> Not so the md5module 11:28:09 <planetmaker> Ammler, yes. But then we grep on a message which won't exist. So what 11:28:09 <Ammler> so hiding python erorrs is worse :-P 11:28:39 <planetmaker> It's not like we disable all errors. We disable ONLY the md5 module deprecation. 11:28:39 <planetmaker> *sigh* 11:28:39 <planetmaker> I give up 11:28:46 <Ammler> does it really hurt, since we moved the logs to a subfolder? 11:29:06 <planetmaker> The error reports are useless 11:29:10 <Ammler> maybe we could just add a threshold 11:29:13 <planetmaker> I don't need compile news which will ALWAYS tell me that it failed 11:29:46 <planetmaker> if I have a failure announced here everyday we can skip the announcements entirely 11:29:54 <Ammler> which is currently 2, so you get only (2 errors) in the annoucement 11:30:38 <Ammler> well, you know, your current "level" is 4, you have check again, if that changes 11:30:39 <planetmaker> while there is NO error 11:30:40 <planetmaker> so the ERROR in the CF is to tell there are errors while there is none 11:31:09 <planetmaker> Ammler, that's like having zillions of whitespace warnings. Errors will also be reported. yes 11:31:09 <planetmaker> But they will pass unnoticed 11:31:44 <Ammler> like andy and djn do ignore nfo errors 11:32:41 <Ammler> planetmaker: we tell the CF, which python packages it should use to build 11:32:55 <Ammler> the CF doesn't decide that magically 11:33:05 <planetmaker> then it uses the wrong md5 one 11:33:28 <Ammler> either that, or nml uses the wrong version 11:33:44 <planetmaker> ? 11:34:05 <planetmaker> NML has no fixed preference on a python version 11:34:21 <Ammler> if I read that message right yacc should use hash instead md5 11:34:39 <planetmaker> it might be like >=2.5 and <=3.0(?), but... 11:35:06 <planetmaker> yes. And yacc is a python module provided by the CF 11:35:39 <planetmaker> as such it's a problem with the server modules 11:36:01 <Ammler> planetmaker: the server might even not have installed those 11:36:07 <planetmaker> it's like gcc 4.0 reporting warnings when compiling openttd code. pointless but annoying 11:36:26 <Ammler> those packages will be installed evertime just for building nml 11:36:36 <Ammler> or the projects 11:36:40 <planetmaker> Ammler, ok, but then the obs(?) might want to define one which doesn't exercise this warning 11:37:06 <planetmaker> ok, my error there :-) 11:37:58 <Ammler> hmm, where is yacc included? 11:38:01 <Ammler> in ply? 11:38:18 <planetmaker> Actually I don't really mind how that warning about the md5 module is silenced. Whether by a different python or a sed script 11:38:19 <Ammler> http://dev.openttdcoop.org/projects/nml/repository/entry/.devzone/build/nml.spec 11:38:56 <Ammler> you don't like my idea about a simple threshold? 11:39:33 <Ammler> which is 4 for nml projects 11:39:39 <planetmaker> yacc: parser.py 11:39:39 <planetmaker> Ammler, no, I don't 11:39:40 <Ammler> then it wouldn't report any errors 11:39:44 <planetmaker> A threshold will hide real errors 11:39:49 <Ammler> no 11:39:55 <Ammler> the log is still there 11:40:05 <planetmaker> just kicking out a specific on, the md5 one is safe 11:40:20 <Ammler> and if error get fixed from nml, it would go below 0 11:40:33 <Ammler> so you could "fix" the threshold 11:40:39 <planetmaker> cluttered with pointless errors 11:40:39 <planetmaker> it's a non-error. A non-message 11:40:39 <planetmaker> It really should go 11:40:42 <planetmaker> We cannot do anything about it 11:41:09 <planetmaker> Ammler, definitely the wrong approach to set a threshold for errors in general 11:41:25 <Ammler> I guess, you don't get me :-/ 11:41:39 <planetmaker> warn about every error except a single pointless and known error: fine 11:42:05 <planetmaker> you want to not report errors in IRC if there are less than 4 11:42:07 <planetmaker> I consider that very bad 11:42:11 <planetmaker> correct? 11:42:29 <Ammler> no 11:42:37 <Ammler> if there are exactly 4 11:43:04 <Ammler> if there are less then 4, you need to be notified about a fix 11:43:06 <planetmaker> still: conceptually totally wrong 11:43:36 <Ammler> then tell me, how someone will be notified about a fix, if we just silence it, that is what I have my issue with 11:43:39 <planetmaker> We know what warnings there are and which is pointless. Then we should just ignore the single, known warning 11:43:41 <planetmaker> not generally assume that with 4 warnings everything is in order 11:44:05 <planetmaker> Ammler, it doesn't matter. It's not our bug nor our fix 11:44:39 <planetmaker> we cannot do a bloody thing about the md5 python module using deprecated shit 11:44:55 <Ammler> we could force using the right package version 11:45:06 <planetmaker> and OLD python module also. As it is supposedly fixed in upstream md5 modules 11:45:39 <planetmaker> if you want. 11:46:06 <planetmaker> But the only other solution is to ignore this single known bogus warning specifically. Not blindly anything which produces exactly 4 lines of warnings 11:46:11 <Ammler> or nml could check the package versions and silence it maybe directly 11:46:39 <planetmaker> how would it do that? 11:47:06 <planetmaker> restrict possible python versions on the basis of one bogus warning? 11:47:06 <planetmaker> sounds not nice, too 11:47:39 <planetmaker> if OpenTTD did that our servers couldn't compile it anymore 11:49:05 <Ammler> I didn't say something about restrictions, just silence 11:49:24 <Ammler> but I think, it is the easiest to prefilter the errorlog 11:49:39 <planetmaker> how can OpenTTD silence a bogus compiler warning? 11:50:15 <Rubidium> it can't in all cases 11:50:49 <Ammler> you really would prefer if openttd would silence compile warning, if those are caused by gcc version difference? 11:51:09 <ODM> how was the party btw?:P 11:52:15 <Ammler> he, weren't you invited? :-) 11:52:39 <ODM> mightve been 11:53:08 <Ammler> it was very funny to see some faces to the nicks here 11:56:55 <Ammler> planetmaker: grep -vP "(DeprecationWarning:)|(^yacc:)|(^ import)" 11:57:05 <planetmaker> Ammler, yes, a prefilter on this very single known message is all I advocated the whole time ;-) 11:57:23 <Ammler> that would make the current swedishrail log empty 11:57:41 <planetmaker> like a grep -v "..." 11:57:41 <planetmaker> why grep on a regex, if you can grep on the full thing to really only grep that? 11:58:05 <planetmaker> and the (valid) NML warnings: they should stay 11:58:06 <planetmaker> they will go anyway soon 11:58:12 <planetmaker> and: they are not bogus 11:58:27 <Ammler> hmm, ok, so only the first 2 lines? 11:58:39 <planetmaker> or at least we can do something about it ;-) 11:58:43 <planetmaker> yes 11:58:49 <planetmaker> which is one 11:59:05 <planetmaker> warning 11:59:09 <Ammler> no, 2, it has a linebreak 11:59:40 <Ammler> but that shouldn't be a big issue 11:59:45 <planetmaker> yes: message + line raising the warning 12:00:39 <planetmaker> but I'd really filter only the exact message. 12:00:39 <planetmaker> we want to know when anything else changes 12:04:29 <Ammler> hmm, I can't "cat log | grep -v filter > log" 12:05:06 <planetmaker> nope 12:05:11 <planetmaker> that'll give you an empty file 12:07:07 <planetmaker> can't you pipe the log directly? 12:14:34 *** dan123 has quit IRC 12:44:42 <Brot6> #openttdcoop - Revision 69:7a13eff40c31: [OTTD] Change: output created patch again to IRC (Ammler) @ http://dev.openttdcoop.org/projects/home/repository/revisions/7a13eff40c31 12:45:11 *** TheODM has joined #openttdcoop.devzone 12:49:40 *** ODM has quit IRC 13:51:51 *** Seberoth has joined #openttdcoop.devzone 14:22:17 *** dan123 has joined #openttdcoop.devzone 14:41:49 <Brot6> #openttdcoop - Revision 70:fffed18b5271: [Compiler] Feature: Add support for NML as own global type (Ammler) @ http://dev.openttdcoop.org/projects/home/repository/revisions/fffed18b5271 14:42:48 *** dan123 has quit IRC 14:43:06 *** dan123 has joined #openttdcoop.devzone 14:43:51 <Brot6> #openttdcoop - Revision 71:b27c75d3b895: [Compiler] Fix (r70): requires was in wrong location (Ammler) @ http://dev.openttdcoop.org/projects/home/repository/revisions/b27c75d3b895 15:09:26 <Brot6> OpenGFX+ - Revision 32:8cdb75ff5bfb: DevZone: Use new global type nml (Ammler) @ http://dev.openttdcoop.org/projects/ogfxplus/repository/revisions/8cdb75ff5bfb 15:11:12 <Brot6> Swedish Rails - Revision 80:81c3fb6c11b8: DevZone: Use new global type nml (Ammler) @ http://dev.openttdcoop.org/projects/swedishrails/repository/revisions/81c3fb6c11b8 16:15:02 <planetmaker> yippieh :-) 16:15:09 <planetmaker> let's see :-) 16:15:17 * planetmaker time warps 16:18:44 <Brot6> newgrf-makefile: compile of r101 failed - http://bundles.openttdcoop.org/newgrf-makefile/nightlies/ERROR/r101 16:18:59 <Brot6> newgrf_makefile: compile of r101 failed - http://bundles.openttdcoop.org/newgrf_makefile/nightlies/ERROR/r101 16:19:39 <Brot6> nml: update from r485 to r492 done - http://bundles.openttdcoop.org/nml/nightlies/r492 16:20:05 <Ammler> the newgrf_makefile is a silly thing 16:20:20 <Brot6> ogfxplus: update from r29 to r32 done (2 errors) - http://bundles.openttdcoop.org/ogfxplus/nightlies/r32 16:20:51 <Ammler> planetmaker: happy? ^ 16:21:10 <Brot6> swedishrails: update from r76 to r80 done (2 errors) - http://bundles.openttdcoop.org/swedishrails/nightlies/r80 16:21:13 <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r557), 32bpp-extra (r36), airportsplus (r50), bros (r12), comic-houses (r70), firs (r1010), fish (r375), heqs (r320), nmts (r16), nutracks (r69), opengfx (r460), openmsx (r57), opensfx (r94), snowlinemod (r12), worldairlinersset (r643) 16:22:20 <planetmaker> what about the newgrf makefile? 16:22:51 <planetmaker> I actually thought yesterday to remove the distinction on the Makefile level between the two projects 16:23:08 <Ammler> ? 16:25:26 <Ammler> planetmaker: shouldn't we for debug and demo reasons create also a nfo with nml projects? 16:26:04 <planetmaker> I thought about that. I'm not sure 16:26:33 <planetmaker> I guess currently it might not be the best of ideas. I recall yexo to say that currently the nfo output might be somewhat a bit ill-maintained 16:26:39 <planetmaker> though it seems to work, though 16:27:13 <planetmaker> concerning NML vs NFO project: there's no real need to distinguish between different projects actually 16:27:25 <planetmaker> I just define the rules for one and the other files - and that's it. 16:27:39 <planetmaker> only a combination of both methods for the same grf file won't work 16:27:45 <Ammler> you could define different targets, if you like 16:28:00 <Ammler> since we use now different setup sepcs 16:28:21 <planetmaker> that's what is being done. basically 16:28:38 <planetmaker> the main file either depends upon a nml or an nfo file 16:28:49 <planetmaker> and then the rest follows automatically by the rules give 16:28:50 <planetmaker> n 16:29:18 <planetmaker> the only distinction there currently is, is the rules for the dependency check: the type of files being parsed is different 16:34:33 <planetmaker> I actually made the distinction of nfo / nml also as I thought that they need different dep checks. But that's absolutely not the case. 17:19:01 *** frosch123 has joined #openttdcoop.devzone 17:21:34 *** Alberth has joined #openttdcoop.devzone 17:26:50 <Alberth> hmm, why does redmine not show the 3 open issues in the roadmap? 17:33:18 <planetmaker> you selected "bugs" and not "all"? 17:33:28 <planetmaker> they're features presumably 17:34:45 <Alberth> oh, there is a selection box at the right :) 17:34:47 <Alberth> thanks 17:35:06 <planetmaker> np. I wondered the same two days ago :-P 17:39:00 *** TheODM has quit IRC 17:40:02 <planetmaker> http://dev.openttdcoop.org/attachments/754/beautifydoc.diff <-- care to comment on the optics? :-) 17:40:36 <Brot6> NewGRF Meta Language - Support #1042 (New): beautify the documentation a bit (planetmaker) @ http://dev.openttdcoop.org/issues/1042 18:09:51 <Alberth> the joys of having a log :) 18:09:59 <Brot6> NewGRF Meta Language - Patch #1040: name of the main script (Alberth) @ http://dev.openttdcoop.org/issues/1040#change-2718 18:11:11 <Alberth> bah, redmine does not save my roadmap checkbox settings :( 18:15:29 <planetmaker> Alberth: each project has also its own activity page 18:16:20 <Alberth> euhm, how is this related to what? 18:16:42 <planetmaker> it shows commits and comments and tracker activity 18:16:53 <planetmaker> I read you being happy about logs ;-) 18:17:10 <planetmaker> reading the update to the issue it seems to me that you meant it slightly different ;-) 18:17:46 <planetmaker> nmlc for nml compiler maybe :-) 18:20:27 <Alberth> sounds generic enough :) 18:20:47 <planetmaker> :-) Yexo found it also agreeable 18:21:38 <planetmaker> btw, re: version thingy. I implemented that. And added the version to the internal NML errors 18:21:48 <planetmaker> That's what I mostly would like it for :-) 18:22:26 <planetmaker> And build and error version determination are now the same. But granted, it's kinda the same principle 18:22:43 <Ammler> Alberth: my suggestion was nml-wrapper.py and then the copy in /usr/bin just nml :-) 18:23:11 <Alberth> w.r.t. #1042, the block below "An example of a part is" should be blue, I think (examples are blue, seems to be the rule). There is a run-away "string" text just below Railtypes, but that is seperate from your patch. Otherwise, it seems a nice step to me. 18:23:12 <planetmaker> I thought about adding a flag to the get_version() thing like update_version, so that the file is not written to 18:23:15 <Ammler> I thought, that is the usual python script handling 18:23:58 <planetmaker> Alberth: do you know where the run-away string is found? I searched for it... but without avail 18:25:23 <Alberth> <tr><td>menu_text</td> string<td></td><td></td></tr> 18:25:23 <Ammler> hmm, does it need to put someone on the watcher list, who is already memeber? 18:25:33 <planetmaker> oh 18:26:10 <Ammler> he, actually you can only members put on the list :-) 18:27:10 <planetmaker> Ammler: watchlist = e-mail upon update (if e-mail is enabled) 18:27:12 <Alberth> planetmaker: reporting versions when an error happens is a good move 18:27:23 <planetmaker> in our cases it might be over-engineered 18:28:03 <Alberth> Ammler: I don't understand your 'nml-wrapper.py' remark 18:28:35 <Ammler> well, that my guess was wrong, all fine :-P 18:28:40 <Ammler> then* 18:29:01 <Alberth> planetmaker: I am still not happy about writing data when doing a 'get'. 18:29:22 <Alberth> it may break in unexpected ways, like when I put installed software in a hg repo. 18:30:06 <Alberth> or when installing in a non-writable place like in /usr 18:30:34 <planetmaker> that's why it's in try... except 18:31:21 <planetmaker> but that's why I proposed a flag to the routing (write_version) which is true when called from setup.py and false when from nml 18:31:30 <Ammler> planetmaker: I said that already sometimes, feel free to use our compiler chroots to test installs... 18:31:42 <planetmaker> :-) 18:32:09 <planetmaker> Alberth: does that sound like a solution? I understand and agree to the reservation 18:32:26 <planetmaker> otherwise we'd have kinda quite a bit duplication 18:33:02 <Ammler> for example with "scheduler.sh -q -n ogfxplus" to build the chroot fro ogfxplus but without publishing 18:33:17 <Alberth> you cannot refactor the code, and have a 'write_version()' and a 'get_version()' function? 18:34:00 <planetmaker> well..., I guess 18:48:01 <Ammler> planetmaker: if you fix that, the newgrf_makefile might also work: http://dev.openttdcoop.org/issues/1017 18:48:23 <Ammler> I postpone my investigation in that direction :-) 18:49:00 <planetmaker> I don't understand how that's related 18:49:12 <Ammler> it looks for a grf, but there isn't one 18:49:16 <Ammler> only a tar 18:50:28 <planetmaker> but isn't it the same like every other newgrf? 18:50:35 <Brot6> newgrf_makefile: compile of r101 failed - http://bundles.openttdcoop.org/newgrf_makefile/nightlies/ERROR/r101 18:51:00 <Ammler> rm: cannot remove `mynewgrf-nightly/*.grf': No such file or directory 18:52:22 <Ammler> anyway, as I asked for taring the opengfx grfs, I didn't expect you do it in the framework for every grf :-) 18:52:29 <Ammler> it really should be fixed 18:53:13 <Ammler> also needed for ttdp btw. 18:53:35 <planetmaker> the latter is a good argument 18:54:03 <Ammler> well, another is that you can't use the zip for bananas 18:54:38 <planetmaker> well, that's really minor. I can use the tar ;-) 18:54:54 <Ammler> but then, you have to build or unzip first 18:55:18 <planetmaker> make bundle_tar is anyway executed by make bundle_zip 18:55:38 <planetmaker> zip = bundle_tar + docs 18:55:57 <planetmaker> bundle_tar = grf + docs 18:56:12 <Ammler> so you have grf + 2docs :-P 18:56:31 <planetmaker> yes 18:56:50 <Ammler> that is fine for opengfx, but stupid for all others 18:57:34 <Ammler> we could make a big devzone.tar :-) 18:58:21 <planetmaker> :-) 18:58:30 <planetmaker> 2cctrainset and firs are not small either 18:58:58 <Ammler> but still only one grf 18:59:23 <planetmaker> Ammler: so you want the zip without a tar inside, just docs + grf, yes? 18:59:34 <Ammler> in a directory 18:59:42 <planetmaker> hm, ok 18:59:47 <planetmaker> everything in a dir 18:59:47 <Ammler> hmm, I have a big deja-vu :-P 18:59:52 <planetmaker> exactly 19:00:03 <planetmaker> and I remember to exactly your bidding :-P 19:00:33 <Ammler> yep, I asked that for opengfx 19:00:36 <Ammler> and you did it for all 19:01:39 <Ammler> maybe, just revert that commit? 19:03:12 *** Seberoth2 has joined #openttdcoop.devzone 19:03:58 *** Seberoth is now known as Guest1068 19:03:58 *** Seberoth2 is now known as Seberoth 19:08:25 *** Seberoth has quit IRC 19:08:30 *** Seberoth has joined #openttdcoop.devzone 19:10:37 *** Guest1068 has quit IRC 19:21:02 <Alberth> f.write('# this file is autogenerated by setup.py\n') <-- that is incorrect comment 19:23:05 <Brot6> NewGRF Meta Language - Revision 493:db127e629d25: Codechange: Merge version_info import with the ... (Alberth) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/db127e629d25 19:24:53 <Brot6> NewGRF Meta Language - Revision 494:dec8d691941c: Doc: Add some more css directives to the refere... (planetmaker) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/dec8d691941c 19:28:17 <Brot6> NewGRF Meta Language - Support #1042 (Closed): beautify the documentation a bit (planetmaker) @ http://dev.openttdcoop.org/issues/1042 19:28:17 <Brot6> NewGRF Meta Language - Support #1042 (Closed): beautify the documentation a bit (planetmaker) @ http://dev.openttdcoop.org/issues/1042#change-2719 19:47:05 <Brot6> NewGRF Meta Language - Revision 495:8753f92a5391: Fix: Errors found by pylint. (Alberth) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/8753f92a5391 19:55:05 <Ammler> Alberth: would it make sense to include pylint to the nightly build script? 19:56:04 <Alberth> only if we aim to reduce the number of lines it outputs 19:56:19 <Ammler> :-) 19:56:21 <Alberth> but that first needs a decision on a python coding style 19:57:00 <Alberth> the same more or less holds for automagic function documentation generation, but that needs an agreement on style as well. 19:57:11 <Alberth> currently I am the only person doing that. 19:58:06 <Alberth> (documenting functions) 19:59:09 <Alberth> currently, pylint produces 2383 lines output :) 19:59:38 <planetmaker> he :-) 20:00:00 <planetmaker> I guess the common idea was: get some working version, then refactor... 20:00:10 <planetmaker> though questionable how sane that is. 20:00:38 <Rubidium> Alberth: if you're bored you can always work on reducing http://master.binaries.openttd.org/nightlies/trunk/r20017/logs/general-docs-error.log :) 20:01:28 <Alberth> I know, and did some already in the past :) 20:01:57 <Alberth> unfortunately, the "get some working version, then refactor.." approach was used much longer there :) 20:03:56 <planetmaker> haha :-) 20:13:33 <Brot6> NewGRF Meta Language - Revision 496:b5a8abb57249: Codechange: Move command line parsing to its ow... (Alberth) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/b5a8abb57249 20:17:58 *** frosch123 has quit IRC 20:18:43 <planetmaker> Alberth: http://paste.openttd.org/225998 <-- like that maybe? 20:22:49 <Alberth> why do you write the file if you don't use it? 20:23:07 <planetmaker> I do use it in get_version 20:23:20 <planetmaker> for the cases when we don't have a hg repo 20:23:32 <planetmaker> it's the version info we ship in tars 20:23:46 <Alberth> ie I don't understand how software with this code is supposed to be used 20:23:56 <planetmaker> setup.py does that 20:24:10 <Alberth> no, main() does 20:24:15 <planetmaker> ? 20:24:24 <planetmaker> setup.py writes the version 20:24:46 <planetmaker> as only that calls it. Wasn't that your concern? 20:25:24 <planetmaker> only when building a distribution bundle via setup we need to store it - as later we most probably won't have a hg repo anymore for reference? 20:25:36 <Alberth> oh, you changed that. Good 20:27:26 <Alberth> even during setup you may not have it, eg with 'hg archive'. or a version may get installed in a hg repo, and it promptly looses its version number. 20:27:55 <Alberth> but those are cases that should not happen, I guess 20:27:58 <planetmaker> well. yes. But then we don't know it 20:28:07 <planetmaker> we cannot be sure then about the version 20:28:53 <planetmaker> that's the whole point 20:28:59 <Alberth> if you first read the version file, and if it fails check the hg the latter case would still work 20:29:46 <planetmaker> that fails in all our cases where we use the repo 20:30:43 <Alberth> we never run setup, so you never get a version file 20:31:10 <planetmaker> hm, true 20:31:42 <planetmaker> but hg check should always be first 20:32:05 <planetmaker> we could test the version file, if that fails, though 20:32:20 <Alberth> like you do now :p 20:32:28 <planetmaker> :-) 20:32:53 <planetmaker> well, I don't quite understand why I should do the other way around. 20:36:15 <planetmaker> well. What's wrong with checking for the hg repo first? 20:36:29 <planetmaker> I honestly fail so far to understand that. Honest question 20:38:21 <planetmaker> so you say that we fail here, if we put it into another hg repo? 20:39:23 <Ammler> Alberth: you create source pack with "./setup.py sdist", not hg archive 20:40:03 <Alberth> to run setup.py, you must have the files at the disk 20:42:28 <Ammler> if you check first for the file, then for the repo, how would it work with updates? 20:42:32 <Alberth> and why would you clone a repo for that? 20:42:52 <Ammler> does it? 20:43:36 <Alberth> (10:43:02 PM) Alberth: and why would you clone a repo for that? <-- was intended as part of my previous line 20:45:09 <planetmaker> Alberth: the question I think is: when and under what conditions will it be used 20:45:18 <planetmaker> a) by us to create a distribution bundle 20:45:22 <Alberth> well, it all comes down to how you consider version numbers, and how you assign and keep track of them 20:45:26 <planetmaker> b) by end users to install it locally 20:46:15 <planetmaker> maybe c) someone with a repo who just installs it. 20:46:37 <planetmaker> but sure, it comes down to exactly that what you say 20:46:39 <Alberth> d) by us without ever doing a propoer install 20:47:07 <planetmaker> so, what should happen? 20:47:15 <planetmaker> d): report the repo version in use 20:47:25 <planetmaker> c) report the repo version used 20:47:39 <planetmaker> b) report the version which was bundled 20:47:42 <Alberth> d) does not matter much imho 20:47:47 <planetmaker> a) report the repo version 20:48:31 <Ammler> IMO, source packages should be the whole hg repo anyway 20:48:32 <planetmaker> the critical part is b) as it means to maintain the version as we don't have access to the repo 20:49:07 <Ammler> then we would need to keep only one version :-) 20:49:26 <planetmaker> Ammler: a user should not require to have hg for using nml 20:49:31 <Alberth> Ammler: 423340 for hg_trunk of openttd :) 20:49:42 <Alberth> KB 20:50:49 <Alberth> hmm, -300000 KB for the HTML document :) 20:51:13 <Alberth> but still a lot of source if you just need 1 revision 20:51:21 <Ammler> hehe 20:51:54 <Ammler> well, the hg requirement is also a valid reason against 20:54:16 <Alberth> the difference is I think, that in your view, the version number is kept in the repo, while in my view, it becomes part of the source code when you make a release. 20:54:30 <Ammler> which it does 20:54:42 <Ammler> with version file 20:54:51 <Alberth> you check that into the repo? 20:55:03 <Alberth> when you tag eg 0.1 ? 20:55:05 <Ammler> no, but setup.py writes that, afaik 20:55:31 <Ammler> the release source is made with setup.py sdisk 20:55:34 <Ammler> t* 20:55:45 <Alberth> "becomes part of the source code" means literally that in my view 20:55:54 <planetmaker> Alberth: it's not checked in but written and distributed 20:56:40 <Alberth> I know 20:56:43 <planetmaker> it's implicitly in the repo by the repo having that exact tag - and thus any distributable version will get that file 20:57:17 <Alberth> *IF* you run setup from a repo dir 20:57:39 <Alberth> in my case, just checking out, or even 'archive' would be enough 20:58:24 <Alberth> but I don't know which is better, I just observe that is the fundamental difference in idea of versioning software 20:58:37 <planetmaker> Alberth: but it requires to add that on every release, to make a separate branch for them. All work which doesn't really help 20:58:52 <planetmaker> hg archive wouldn't be any official release 20:59:15 <planetmaker> and when I take e.g. OpenTTD's release source as tar archive... oh well. I can write anything into the version, too 20:59:31 <planetmaker> so 'unknown' is quite accurate 21:01:14 <planetmaker> IF you want to have a version inside the repo, I propose to add a kind of target version 21:01:17 <Alberth> well, if you don't do certain things, it will work, and as I don't know which is better, let's keep the current system 21:01:27 *** ODM has joined #openttdcoop.devzone 21:01:49 <planetmaker> which then could be reported back as 'maybe XXXX' in the cases we currently say 'unknown' 21:02:26 <planetmaker> then the target version only needs changing prior or after a release (however one wants to handle it) 21:04:10 <Alberth> please drop it, I have had enough of the subject. When it appears to be broken we can consider fixing it. Until that time, just keep the current system. 21:04:18 <Ammler> is it really not possible to silence that md5 warning? 21:04:29 <Ammler> I get that on every command 21:04:52 <planetmaker> sorry, I didn't mean to annoy you :-) 21:07:00 <Alberth> Ammler: what md5 warning, nml does not even have the word "md5" in its sources 21:07:18 <Ammler> salieri:~> nml2nfo --version 21:07:20 <Ammler> /usr/lib/python2.6/site-packages/ply/yacc.py:74: DeprecationWarning: the md5 module is deprecated; use hashlib instead 21:07:21 <Ammler> import re, types, sys, cStringIO, md5, os.path 21:07:23 <Ammler> r496 (b5a8abb57249) 21:07:32 <Alberth> oh, yacc.py 21:08:01 <Alberth> what version of yacc.py do you use? 21:08:40 <Alberth> __version__ = "3.3" here, and I don't get warnings 21:08:56 <Alberth> line 62 21:09:21 <Ammler> installing python-ply-2.5-5.1 21:09:29 <Ammler> how do I get the yacc version? 21:09:44 <Alberth> open /usr/lib/python2.6/site-packages/ply/yacc.py 21:09:47 <Ammler> http://bundles.openttdcoop.org/nml/nightlies/r492/log/nml-r492-devzone.log <-- build script 21:10:35 <Ammler> __version__ = "2.5" 21:11:52 <Alberth> very old :) 21:12:10 <Rubidium> 2.5's in Debian stable 21:12:28 <Ammler> for me, it seems logical to use 2.5 with python 2.6 21:12:34 <Brot6> NewGRF Meta Language - Revision 497:b16329f37a7e: Codechange: Only write the version file when ca... (planetmaker) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/b16329f37a7e 21:12:38 <Ammler> 3.3 sounds like python 3 21:13:06 <Alberth> 2.5 is the last one before 3.0, so it is not that old 21:13:46 <Alberth> ply 3.3 is python 3 compatible afaik, but it also works with python 2.x 21:14:12 <Ammler> windows seems to mix versions 21:14:36 <Ammler> or do you also use python 3 already? 21:14:49 <Alberth> ply 2.5 README is of 2008-05-28 in the .tar.gz 21:14:59 <Alberth> so a little over 2 years 21:15:40 <Alberth> no, still using python 2 (2.6) 21:15:51 <Alberth> and I expect that to do for a few years to come 21:16:07 <Ammler> I see no linux distro which uses python-ply >2.5 21:16:20 <Alberth> fedora 13 does :) 21:16:36 <Alberth> python-ply.noarch 3.3-2.fc13 @fedora 21:17:00 <Alberth> python3-ply.noarch 3.3-2.fc13 fedora 21:17:01 <Ammler> hmm, true 21:17:12 <Alberth> and they also have a python 3 version, apparently 21:17:13 <Ammler> but the upcomming suse 11.3 doesn't 21:17:13 <Rubidium> https://launchpad.net/ubuntu/+source/ply 21:17:16 <Webster> Title: “ply” package : Ubuntu (at launchpad.net) 21:17:34 <Alberth> yeah, of course ubuntu does :) 21:17:58 <Ammler> then I might make my own package :-) 21:17:59 <Rubidium> but then the question is whether Ubuntu counts as a distribution or as Debian Unstable + extra issues 21:18:34 <Ammler> Rubidium: fedora does, I don't care about ubuntu :-P 21:18:34 * Alberth votes for the latter option 21:19:07 <Alberth> fedora is also quite bleeding edge, in general 21:20:01 <Alberth> but ply is just 2 python files 21:20:18 <Alberth> I am not even sure it comes with a setup.py 21:21:23 <Alberth> good night 21:21:43 <Rubidium> slaapze 21:22:51 <Alberth> you as well, although it will probably a few hours from now :) 21:22:59 *** Alberth has left #openttdcoop.devzone 21:25:42 *** ODM has quit IRC 21:51:32 *** Yexo has joined #openttdcoop.devzone 22:00:07 <Ammler> we have now ply-3.3 :-) 22:00:47 <planetmaker> yippieh :-) 22:03:07 <Yexo> so the only warning is now the unused random token? 22:03:59 <planetmaker> without testing on my part I assume so 22:08:14 <Ammler> deleting unwanted python-ply-2.5-5.1 22:08:16 <Ammler> installing python-ply-3.3-13.1 22:08:18 <Ammler> yes :-) 22:08:36 <Ammler> planetmaker: the whole silencing is now obsolete :-P 22:08:45 <planetmaker> yep 22:08:56 <planetmaker> good this way :-) 22:14:06 <planetmaker> have a good night 22:25:15 <Ammler> https://build.opensuse.org/package/files?package=python-ply&project=home%3Aopenttdcoop 22:41:31 *** Yexo has quit IRC 23:01:18 *** Seberoth has quit IRC 23:53:07 *** KenjiE20 has quit IRC