Config
Log for #openttdcoop.devzone on 24th June 2010:
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

Powered by YARRSTE version: svn-trunk