Log for #openttdcoop.devzone on 19th August 2013:
Times are UTC Toggle Colours
02:11:14  *** KenjiE20 has quit IRC
02:11:50  *** KenjiE20 has joined #openttdcoop.devzone
10:28:43  *** tycoondemon has quit IRC
10:34:29  *** tycoondemon has joined #openttdcoop.devzone
10:44:18  <planetmaker> so... can we change the versioning scheme slightly?
10:44:51  <planetmaker> Like version = branch_version * 10000 + build_number?
10:45:11  <planetmaker> or maybe not build_number but the revision within that branch (other branches pruned)?
11:31:46  *** Supercheese has quit IRC
11:32:19  *** Supercheese has joined #openttdcoop.devzone
13:32:01  *** gelignite has joined #openttdcoop.devzone
14:22:24  *** George|2 has joined #openttdcoop.devzone
14:22:24  *** George is now known as Guest3788
14:22:24  *** George|2 is now known as George
14:28:45  *** Guest3788 has quit IRC
15:15:19  *** ODM has joined #openttdcoop.devzone
16:03:51  <Brot6> Industrial Stations Renewal - Revision 238:697b69a7b3a1: Feature: Randomise cargo level thresholds f... Xmart3pX @
16:13:13  <planetmaker> o_O Nice
16:40:55  <Brot6> Industrial Stations Renewal - Revision 239:fac7858023f4: Codechange: Don’t use a word sized action... Xmart3pX @
16:44:15  *** Jam35 has joined #openttdcoop.devzone
17:23:42  <Brot6> isr: update from r237 to r239 done -
17:55:07  *** Alberth has joined #openttdcoop.devzone
18:04:40  <planetmaker> moin
18:05:34  <Alberth> hi hi
18:05:45  <planetmaker> Alberth, the typo in the German FIRS translation are the missing quotation marks for the first argument
18:06:08  <planetmaker> or rather both, I guess
18:06:19  <planetmaker> not sure... are they required?
18:06:20  <planetmaker> possibly
18:07:21  <Alberth> afaik they are optional if you don't have an empty string and no string with white space
18:07:29  <planetmaker> I agree with lugo's strong suggestion to revert meeresabhängig -> marin
18:07:41  <planetmaker> meeresabhängig... is very strange in that context
18:09:20  <planetmaker> actually... maritim. Not marin. He writes the latter and argues the first ;-)
18:12:03  <Alberth> well, tbh, I don't care what they decide, but it has to be agreed upon before hand
18:12:15  <Alberth> otherwise we end up in a game of pingpong
18:12:48  <planetmaker> otherwise I decide ;-)
18:13:16  <Alberth> you have commit access too, don't you? :)
18:13:47  <planetmaker> btw... did you already see?
18:14:06  <planetmaker> frosch installed that still yesterday
18:14:45  <planetmaker> it's not yet hooked to live version of RM and DB, though
18:15:05  <planetmaker> <-- devmine it talks to
18:15:10  <planetmaker> err... redmine
18:18:13  <planetmaker> something was not working when I left last night... I forgot what
18:18:32  <planetmaker> ah, login
18:21:50  *** frosch123 has joined #openttdcoop.devzone
18:22:31  <planetmaker> quak
18:22:42  <Alberth> quek
18:22:57  <planetmaker> quik
18:23:14  <planetmaker> quok
18:23:16  <planetmaker> quuk
18:23:57  <V453000> arse
18:24:11  <planetmaker> :-(
18:24:11  <V453000> [that is how slugs occassionally go]
18:25:00  <frosch123> moin
18:25:22  <V453000> hi frosch123
18:25:27  <V453000> not touching CSS ever
18:25:30  <V453000> fyi :)
18:25:55  <planetmaker> a pity, V453000. You could make a website design for the coop pages. All of them :-)
18:26:15  <V453000> I can draw it, but I am never touching website coding again
18:27:15  <planetmaker> why?
18:27:52  <V453000> firstly I dont understand how it works (not too well), secondly did it for job for a couple of months during which I managed go grow serious hate towards it
18:28:08  <planetmaker> :D
18:28:26  <V453000> the combination of first added to the job thing was kind of problematic :)
18:30:57  <V453000> oh and also andy proved on his newgrfs that he can do webstuff sooo ... :P
18:31:33  <planetmaker> :D
18:31:44  <planetmaker> I guess he makes his living by doing so
18:32:20  <V453000> indeed, so off to andy :>
18:33:07  <planetmaker> anyway... I need opinions on what to do with the revisions of all projects we build here, at least all which use branches in their repo
18:33:33  <planetmaker> it seems that both, bamboo and jenkins do partial clones or repo pruning to the point that they only pull commits of the branch they build
18:33:56  <planetmaker> thus our current way to determine the "revision" of repos fails.
18:34:33  <planetmaker> Personally I'll not be too keen to try hack into either of them to change that behaviour
18:35:36  <planetmaker> Thus we need a somewhat 'new' way to set the numeric version for mostly the NewGRFs being built, but also for things like NML and grfcodec
18:36:54  <Alberth> 08:13:47 PM) planetmaker: btw... did you already see?  <--  :O    \o/
18:37:36  <Alberth> thanks frosch123 & planetmaker
18:37:47  <Alberth> and ^Spike^ of course!
18:38:17  <planetmaker> that URL will remain, I think. It's a good one. Unless you want another name for it :-)
18:39:48  <frosch123> aww, the login did not magically fix itself since yesterday :/
18:39:55  <planetmaker> no, sorry
18:40:15  <planetmaker> maybe ^Spike^ has an idea or sees whether I did miss anything there?
18:40:33  <planetmaker> btw, frosch123, what credentials does it expect?
18:40:54  <Alberth> should be redmine login
18:41:18  <frosch123> what?
18:41:32  <planetmaker> login+pw it asks about. The RM ones?
18:41:50  <frosch123> yes
18:43:10  <frosch123> well, i'll add some debug output
18:43:23  <frosch123> whether the issue is on the eints or apache side
18:46:02  * ^Spike^ is innocent...
18:48:34  <Alberth> not responsible for msql -> psql???
18:48:38  <planetmaker> ^Spike^, I thought you could check whether I made sure that https to that machine will work from our side
18:49:07  <planetmaker> I still don't trust myself there to do everything right :-)
18:50:38  <planetmaker> <-- opinions, frosch123 , Alberth, Rubidium , ...?
18:51:54  <^Spike^> Alberth i know nothing about that migration
18:52:04  <^Spike^> don't know what idiot started it... or even setup that server... ;)
18:52:19  <planetmaker> all my work :-P
18:52:40  <planetmaker> all I say: please check whether https traffic to URL http://translator.o.o, VM 135 will work
18:54:09  <^Spike^> there was no mc installed...
18:54:19  <^Spike^> and i'm too lazy to check without :)
18:54:41  <Alberth> planetmaker: I think the brain washing worked quite well :p
18:55:08  <^Spike^> we might need to install mod_rpaf on that container aswell
18:55:29  <^Spike^> libapache2-mod-rpaf - module for Apache2 which takes the last IP from the 'X-Forwarded-For' header
18:55:30  <^Spike^> for that
18:56:10  <^Spike^> hmmmm
18:56:40  *** andythenorth has joined #openttdcoop.devzone
18:57:16  <planetmaker> andythenorth, your opinion on would be appreciated, too
18:57:49  <planetmaker> hello also ;-)
18:58:02  <andythenorth> also hello
18:58:14  <andythenorth> how is the problem handled for git repos?
18:58:24  <^Spike^> planetmaker that's what we need to keep in mind... install rpaf or something similiar (compatible with the webserver) to reverse proxy stuff
18:58:45  <planetmaker> doesn't exist, andythenorth. No such project with incremental version requirements exists here
18:58:54  <andythenorth> hmm
18:58:59  <planetmaker> it could be solved like b) probably, too
18:59:15  <planetmaker> or like a)
18:59:17  <andythenorth> so is that (1) no info for git or (2) not a problem with git?
18:59:25  <andythenorth> this isn't really about the vcs, but the version number?
18:59:29  <planetmaker> yes
19:00:01  <planetmaker> preferentially we need something new there... I'm not too keen to hack either, bamboo or jenkins
19:00:14  <andythenorth> so there are very many meanings of version number in my experience
19:00:18  <andythenorth> which version number is this?
19:00:20  <andythenorth> commit?
19:00:22  <planetmaker> and relying on unique numerical IDs from dvcs is... bad anyway
19:00:24  <andythenorth> newgrf?
19:00:34  <andythenorth> i.e. what's the goal? :)
19:00:36  <planetmaker> like the r2334 you get for FIRS
19:00:48  <planetmaker> it's currently taken from the repo
19:01:13  <planetmaker> but with one of the two (new) build systems it would build as, say r2069
19:01:15  <Rubidium> planetmaker: how's a time based thing going to work with merges? Or worse, rebasing?
19:01:21  <planetmaker> due to 300-odd commits in branches
19:01:43  <^Spike^> background story btw just to give you guys a thought:
19:01:45  <planetmaker> Rubidium, rewritten history, like rebasing does, will mess that up for sure
19:01:51  <^Spike^> Our current compile farm isn't maintainable...
19:01:58  <^Spike^> that's why we are looking @ other options
19:01:58  <planetmaker> I consider the the repos unmutable, thus that won't occur
19:02:16  <Rubidium> planetmaker: also not with cherry-pick?
19:02:20  <^Spike^> our thought is to move away from what we got right now cause we don't have any way to maintain it
19:02:59  <Rubidium> likewise, commits in branch... shallow copy?
19:03:13  <andythenorth> so the mercurial revision (r2334 or whatever) - that's specific to a branch?  (and we don't have a problem so far because most projects are on master?)
19:03:29  * andythenorth thinks that is wrong understanding
19:03:40  <planetmaker> Rubidium, with rewritten or partial history, you're always screwed, if you don't want to hardcode a number in the source
19:04:10  <andythenorth> is this a canonical-ness problem?
19:04:23  <andythenorth> i.e. what is canonical source of 'version' for build of a newgrf?
19:05:07  <planetmaker> andythenorth, currently it's basically the number of the commit as received by the DevZone
19:05:34  <planetmaker> the order in which commits are received (different branches) is not unique with distributed VCS
19:06:05  <planetmaker> thus... it's a daring assumption which we do now. Also it fails as soon as you use things which rewrite history and remove old changesets
19:06:13  <planetmaker> (like using the evolve extension)
19:06:36  <planetmaker> Rubidium, if you have a solution to that, though, please tell me :-)
19:07:00  <planetmaker> how would you tackle this? Or would you always update the newgrf's version manually with each commit?
19:07:01  <Rubidium> ... subversion ...
19:07:05  <^Spike^> heheh
19:07:28  <^Spike^> i would go for cvs personally... but well :)
19:07:39  <planetmaker> he :-)
19:07:45  <frosch123> no sccs?
19:08:09  <andythenorth> planetmaker: so canonical = revision + branch name?
19:08:13  <planetmaker> I think we can assume for the issue at hand, that the repos as-are on the DevZone are not history-modified
19:08:18  <andythenorth> is branch name guaranteed unique?
19:08:41  <frosch123> branch name would need to be a number anyway
19:08:47  <planetmaker> andythenorth, yes... for display purposes that works. But how to squeeze that in 4 bytes as required by the NewGRF version?
19:08:54  <andythenorth> :(
19:09:07  <^Spike^> those 4 bytes need to be sequential?
19:09:22  <planetmaker> andythenorth, thus I need something which keeps FIRS' reported version increasing with each commit you make.
19:09:23  <andythenorth> why release newgrfs with same grfid on branches?
19:09:28  <frosch123> ^Spike^: their only purpose is to decide what is newer :p
19:09:36  * andythenorth tries to make problem go away by convention
19:09:44  <andythenorth> what real use case needs to be supported?
19:09:48  <planetmaker> andythenorth, that doesn't exactly solve the problem
19:09:52  <frosch123> ^Spike^: and you can define your grf as savegame compatible with earlier versions of the grf starting with a certain number
19:10:10  <^Spike^> frosch123 ty for that... you realize i'm purely just a user of the game... and a sysadmin :D
19:10:11  <planetmaker> andythenorth, the use case of your current FIRS being reported newer than the one built one month ago.
19:10:27  <^Spike^> but that means they need to be sequential to realize that?
19:10:38  <planetmaker> ^Spike^, only strictly monotonous
19:10:51  <planetmaker> I used that mathematical wording for reason ;-)
19:10:55  <frosch123> ^Spike^: the number does not even need to be unique
19:11:00  <^Spike^> ....
19:11:02  <andythenorth> planetmaker: interesting, so is that a real case? :O
19:11:09  <frosch123> you could also let the author manually increment it :p
19:11:33  <planetmaker> andythenorth, FIRS versions are. OpenGFX versions are. NML versions are. And possibly a few others which also have branches
19:11:46  *** George has quit IRC
19:11:52  <planetmaker> I can't go back to NML 2027 now. which you now know as 2094
19:12:22  <planetmaker> or build NML 0.2.5 as version 72
19:12:32  <planetmaker> which it kinda would be
19:12:49  <planetmaker> well, maybe not that stark, but ...
19:13:01  <andythenorth> hmm
19:13:18  <andythenorth> so what's main use for version in the compiled newgrf?
19:13:26  <planetmaker> thus my idea: count revisions from r0 to the revision being built. And add a certain number to that
19:13:35  <planetmaker> exactly, andythenorth
19:13:52  <planetmaker> it need not have (much) impact on the displayed version
19:15:04  <andythenorth> version is pretty arbitrary?
19:15:13  <andythenorth> it provides for savegame compatibility, and what else?
19:15:25  <planetmaker> it provides for openttd to know which is newer
19:15:50  <Alberth> tag each build?
19:16:02  <planetmaker> most people will only have shown the newest one being available in the newgrf selection
19:16:07  <planetmaker> each day, each push, Alberth ?
19:16:13  <planetmaker> thus each revision?
19:16:15  <Alberth> sure, why not?
19:16:30  <planetmaker> then the question is: how do I tag them?
19:16:50  <planetmaker> IMHO that's deferring the problem to another place
19:16:59  <Alberth> something unique that fits in 4 bytes :p
19:17:08  * andythenorth considers manually maintaining version
19:17:11  <andythenorth> sounds boring though
19:17:13  <Alberth> why 4 bytes btw?
19:17:19  * andythenorth considers using UTC timestamp
19:17:32  <planetmaker> Alberth, that's the size the dword variable allows to report to openttd
19:17:41  <planetmaker> newgrf specs
19:18:10  <planetmaker> andythenorth, UTC timestamp quickly is larger than 4bytes :-)
19:18:37  <planetmaker> 130819211658
19:18:46  <planetmaker> @base 10 16 130819211658
19:18:46  <Webster> planetmaker: 1E756EC18A
19:18:50  <planetmaker> longer
19:19:35  <andythenorth> hmm
19:19:53  <andythenorth> puzzling isn't it
19:20:34  <planetmaker> that's why I think: let's assign a number to each branch. Highest number to the development branch. And lowest to the oldest branch with the lowest release builds
19:20:35  <^Spike^> well we only need an idea by ehm... when did we start with devmine planetmaker? :D
19:21:06  <planetmaker> then use the number of commits r0:buildrev + 100.000
19:21:24  <planetmaker> then use the number of commits r0:buildrev + 100.000 * branch's number
19:21:38  *** George has joined #openttdcoop.devzone
19:21:43  <planetmaker> thus we have something similar to OpenTTD's NewGRF version:
19:21:54  <planetmaker> 140XXXX
19:22:07  <planetmaker> where XXXX is the current revision. or here the number of commits in that branch
19:22:16  <planetmaker> and 140 is the branch's number (here 1.4.0)
19:22:24  <planetmaker> thus the next major release's version)
19:22:41  <andythenorth> try it?
19:22:45  <andythenorth> see what happens
19:22:52  <andythenorth> what's worst that can happen?
19:22:55  <planetmaker> well :-)
19:23:11  <andythenorth> it's only going to affect nightlies?  Or tagged versions as well?
19:23:12  <planetmaker> worst what happens is that the versioning of the newgrfs, NML and grfcodec are messed up
19:23:36  *** ODM has quit IRC
19:23:40  <planetmaker> tags... are only visual. it will also affect release builds. OpenTTD *only* cares about this number
19:24:04  <planetmaker> hm... but you give me an idea, andythenorth
19:24:29  <planetmaker> we can search for the last tag (and assume a form of x.y.z). and then add the rev-number :-)
19:24:43  <planetmaker> hm... or not
19:24:48  <planetmaker> might be bad
19:25:12  <planetmaker> I see how it fails :-)
19:25:32  <planetmaker> in a repo with tags only in branches. or where tags don't follow that scheme
19:25:50  <planetmaker> but... if there's no other suggestions... I might indeed just try this nevertheless
19:25:56  <planetmaker> option b)
19:27:08  <andythenorth> see what happens
19:27:18  <andythenorth> I have nothing branched, so am bad test case :P
19:28:40  <planetmaker> FIRS is quite branched
19:28:48  <planetmaker> it's the project with most branches ;-)
19:29:28  <andythenorth> oops
19:29:37  <andythenorth> I typed 'hg branch' instead of 'hg branches'
19:29:39  <andythenorth> which gave me 1 :P
19:29:45  <andythenorth> silly andythenorth
19:29:52  <planetmaker> :-)
19:30:05  <andythenorth> this is the problem with git :P
19:30:10  <andythenorth> it breaks my hg brain
19:30:23  <planetmaker> hm... I also see where my approach to count commits breaks...
19:30:30  <planetmaker> he, yo uchanged to git?
19:30:41  <andythenorth> yes
19:30:44  <andythenorth> well svn + git
19:30:47  <andythenorth> bonkers
19:31:00  <planetmaker> use svn+hg ;-)
19:31:31  <andythenorth> svn for the build part of the project, git for the code :P
19:31:38  <andythenorth> it's....interesting to remember which is which
19:31:50  <planetmaker> :D
19:31:52  <andythenorth> but all my ottd stuff is hg
19:31:58  <andythenorth> so it's fun :P
19:32:33  <frosch123> planetmaker: what about the timestamp reduced to the date?
19:32:49  <planetmaker> frosch123, and different commits done on the same date?
19:32:50  <frosch123> i think version numbers only matter for nighty bulds
19:32:54  <frosch123> and they are only done once a day
19:33:09  <planetmaker> projects like FIRS are built for each commit
19:33:21  <frosch123> and why would the version number need increasing every time?
19:33:31  <planetmaker> openttd needs to know which is newest
19:33:45  <Alberth> fix newgrf spec?
19:33:49  <frosch123> but not for people who download multiple times per day
19:34:11  <frosch123> it's not necessariy to be unique
19:34:30  <frosch123> put the hg revision hash in the newgrf title, for proper bug reports
19:34:47  <frosch123> and use some somewhat increasing version number for the grf version
19:35:12  <planetmaker> hm
19:35:36  <andythenorth> afaict only min. compatibility is interesting use of version number
19:35:40  <andythenorth> rest of it is 'meh'
19:35:50  <andythenorth> I'm sure I missed something :)
19:36:18  <planetmaker> as said andythenorth : most people will only see the one with the newest revision number
19:36:24  <frosch123> i see not purpose in counting revisions or similar
19:36:28  <planetmaker> newgrf_show_old_versions = false
19:36:38  <frosch123> you won't be able to "hg update" to an arbitrary number
19:36:58  <frosch123> so you can as well use a number independent of commits
19:37:13  <frosch123> and then something date related is easiest
19:37:23  <planetmaker> true
19:37:31  <planetmaker> so also the same for NML?
19:37:38  <planetmaker> and grfcodec?
19:38:11  <frosch123> they have no 32bit restriction, do they?
19:38:20  <planetmaker> nmlc --version
19:38:20  <planetmaker> 0.3.0.r2093M:d0dd45dec06d
19:38:21  <frosch123> so imo hg hash + commit timestamp
19:38:22  <planetmaker> ^ no
19:38:25  <frosch123> + branch name
19:38:55  <planetmaker> changes then to
19:39:03  <andythenorth> planetmaker: I'm not sure you're obliged to solve this completely :)  Unless it interests you.  Good enough is enough.
19:39:14  <frosch123> 0.3.0-20130818213930:d0dd45dec06d ?
19:39:24  <planetmaker> :-) true. We have the space there
19:40:10  <planetmaker> grfcodec -v
19:40:10  <planetmaker> GRFCodec trunk r959 - Copyright (C) 2000-2005 by Josef Drexler
19:41:29  <planetmaker> GRFCodec trunk r20130829213130 - ...?
19:42:01  <planetmaker> hm. But then, OpenTTD CF builds that officially...
19:42:04  <frosch123> GRFCodec default d08d5c86024b (2013-05-26 22:11:25 UTC)
19:42:14  <frosch123> not sure about "default", but "trunk" is nonsense :p
19:42:20  <planetmaker> :-)
19:42:30  <planetmaker> default is default default's branch name
19:43:02  <planetmaker> andythenorth, sure, good enough, yes. But we should choose something which we know is good enough :-)
19:43:13  <frosch123> i would remove the date/time separators in filenames, but keep them in the displays
19:43:13  <Alberth> just jumping in, but are you considering unifying numbers between different vcs-es too?
19:43:50  <frosch123> Alberth: utc date is quite unified :p
19:43:51  <planetmaker> we don't exactly have 'different VCS' here. But this approach surely would work for others, too
19:44:08  <planetmaker> nearly(?) everything on devzone is mercurial-based
19:44:11  <Alberth> ie being able to build an openttd from hg to play MP
19:44:28  <andythenorth> surely you jest? :P
19:44:35  <planetmaker> no, why? :-)
19:44:50  <andythenorth> *real men download the ottd nightly*
19:44:58  <andythenorth> none of this new-fangled building your own
19:45:04  <planetmaker> being able to build openttd is not my top priority. But it's not too far down. It comes right after nml, newgrfs, grfcodec :-)
19:45:15  <frosch123> @calc 365*13.5
19:45:15  <Webster> frosch123: 4927.5
19:45:33  <planetmaker> and... if I choose bamboo... then I might even see whether I can "copy" openttd's build nodes
19:46:15  <planetmaker> *13.5?
19:46:16  <andythenorth> btw, I am *very* glad this is being done.  Losing bundles / CF seems would be one of the more demotivating things I can think of.
19:47:10  <frosch123> planetmaker: about todays date
19:47:20  <frosch123> days since 2000-01-01
19:47:37  <frosch123> which seems to be the only reasonable reference date
19:47:41  <planetmaker> :-)
19:47:51  <^Spike^> so... figured something out yet? :)\
19:48:00  <^Spike^> and NO keeping current compile farm is not an option
19:48:14  <planetmaker> no-one suggested that, ^Spike^ :-)
19:48:38  <^Spike^> just wanted to be sure that it will not be given as an option :D
19:48:47  <^Spike^> i veto that option with all i can.... sort of... :)
19:49:03  <frosch123> ^Spike^: great idea, let's keep the current farm
19:49:19  <^Spike^> @kick frosch123 NO!
19:49:22  <^Spike^> damn... :)
19:49:31  <frosch123> i am lucky :p
19:49:39  <planetmaker> I'd open jenkins and bamboo installs publicly... but they're currently not secured at all :D
19:49:41  *** ChanServ sets mode: +o Webster
19:49:45  *** frosch123 has left #openttdcoop.devzone
19:49:45  <^Spike^> what.... frosch123? ;)
19:49:49  <^Spike^> lol
19:49:56  *** frosch123 has joined #openttdcoop.devzone
19:50:01  <planetmaker> quaaak!
19:50:02  <^Spike^> i love auto join clients :D
19:50:15  <^Spike^> there is a reason i disable that option :D
19:50:35  <^Spike^> planetmaker define secured
19:50:41  <^Spike^> as in ppl can change all settings secured?
19:50:59  <^Spike^> else just create some local users?
19:51:49  <planetmaker> ^Spike^, anything can do anything
19:51:53  <planetmaker> at least on jenkins
19:52:06  <planetmaker> bamboo has a login by default
19:53:18  <planetmaker> ok... so... date-based it is.
19:53:29  <planetmaker> now... base-2000 and days since then?
19:53:32  <planetmaker> then we can add time, too
19:54:03  <planetmaker> JMOD(current) - JMOD(2000-1-1-0:00)
19:54:14  <planetmaker> * 1000
19:54:15  <planetmaker> or so
19:54:21  <^Spike^> btw frosch123 / Alberth i might toy around on your container aswell to get stuff working with the proxy (just so you know... :))
19:54:41  <planetmaker> but the modified julian date is not exactly intuitive :-)
19:55:14  <frosch123> planetmaker: i thought 2 bytes for branch, 2 bytes for date
19:55:26  <frosch123> would last till 2170 or so
19:55:53  <planetmaker> 1 byte for branch would allow 255 branches already
19:56:06  <frosch123> how do you count branches?
19:56:16  <planetmaker> I'd just start with 0 (no branches).
19:56:38  <planetmaker> when I branch, I'd increase a branch-variable in default by 1. So that the branch keeps 0
19:56:43  <frosch123> well, do you commit the branch number to the source somewhere?
19:56:52  <planetmaker> assuming that the branch is the release branch and default the newer development versions
19:56:57  <planetmaker> yes, I do that
19:57:03  <planetmaker> like openttd
19:57:14  <planetmaker> has 1.4.0 in its source in trunk
19:57:15  <frosch123> ok :)
19:57:35  <planetmaker> well, NewGRFs don't do that yet. But that's an easy addition really, I think
19:58:05  <frosch123> @calc 24*60*365
19:58:05  <Webster> frosch123: 525600
19:58:17  <frosch123> @calc 2**24 / (24*60*365)
19:58:17  <Webster> frosch123: 31.9201217656
19:58:22  <frosch123> that's not so long
19:58:27  <frosch123> time does not fit
19:58:37  <planetmaker> 31 years? Hm
20:00:23  <planetmaker> @calc 2**24 / (24*365)
20:00:23  <Webster> planetmaker: 1915.20730594
20:00:27  <planetmaker> :D
20:00:39  <planetmaker> version increase every hour
20:00:55  <frosch123> makes it only more complicated
20:01:01  <planetmaker> yup
20:01:07  <frosch123> and either you commit 10 commits within one hour
20:01:09  <planetmaker> @calc 2**16 / 365
20:01:09  <Webster> planetmaker: 179.550684932
20:01:11  <frosch123> or one per day
20:01:20  <planetmaker> my thinking, too
20:01:28  <frosch123> i think 2179 is acceptable
20:01:32  <planetmaker> ^
20:01:38  <planetmaker> so two for the branch
20:01:44  <frosch123> 2031 wouldn't :)
20:01:46  <planetmaker> gives more leeway there
20:02:20  <planetmaker> I doubt there's many repos which need taking care with the branch variable anyway...
20:02:29  <planetmaker> only andy and myself are crazy enough to use branches
20:05:35  <planetmaker> ok. So I conclude: I'll change versioning of builds here for NewGRFs such that the reported version consists of 2bytes for the branch and 2bytes for the days since 2000-1-1. NML and grfcodec will report a commit-time based version and report branch and hash as well
20:05:51  <planetmaker> these versioning schemes should also work independent of VCS, so... should be quite future-proof
20:05:52  <frosch123> hmm, why are there no .pyc files?
20:05:57  <planetmaker> where?
20:06:30  <planetmaker> thanks for the input Rubidium , Alberth , andythenorth and frosch123 :-)
20:06:43  <frosch123> planetmaker: be careful with repos which have more than 4900 commits :)
20:06:50  <planetmaker> hm?
20:07:04  <planetmaker> only openttd has that
20:07:09  <frosch123> well, if you change the versioning schema the versions should still increase
20:07:22  <planetmaker> no newgrf I know :-)
20:07:23  <frosch123> i have no idea how many commits firs has :p
20:07:29  <planetmaker> 2300 or so
20:07:36  <Alberth> frosch123: python3 makes __pycache__  directories
20:08:03  <frosch123> anyway, i've added some debug output to eints
20:08:06  <andythenorth> FIRS repo is at r3798
20:08:14  <planetmaker> ups :-)
20:08:15  <andythenorth> for default branch
20:08:16  <frosch123> the input to the authenication window never reaches eints
20:08:24  <planetmaker> luckily still < 4900 then
20:08:31  <andythenorth> FIRS 5k will never happen? o_O
20:08:38  <andythenorth> I'll start FIRS 2 in a new repo :P
20:09:36  <planetmaker> andythenorth, it will :-)
20:09:45  <planetmaker> @calc 5000/365
20:09:45  <Webster> planetmaker: 13.698630137
20:09:58  <planetmaker> @calc 5000/365 - 13 * 365
20:09:58  <Webster> planetmaker: -4731.30136986
20:10:05  <planetmaker> @calc (5000/365 - 13) * 365
20:10:05  <Webster> planetmaker: 255.0
20:10:14  <planetmaker> day 255 this year... was that already?
20:10:19  <planetmaker> nope
20:10:48  <planetmaker> next month somewhen :D I've to be fast or it won't happen ;-)
20:11:05  <frosch123> day 231 today, but you also need to consider leap days
20:11:34  <planetmaker> at most like 3
20:11:52  <planetmaker> or 4?
20:12:10  <Alberth> 4 leap days? :o
20:12:17  <planetmaker> since 1.1.2000?
20:12:25  <frosch123> 4948 is today
20:12:47  <planetmaker> so... 52 days to go
20:12:48  <frosch123> 2013-09-09 is 5000
20:12:54  <planetmaker> o_O
20:12:57  <planetmaker> soon
20:13:03  <planetmaker> really?
20:13:10  <planetmaker> 52 days from now?
20:13:21  <frosch123> oh, i mistyped, today is not 4948
20:13:26  <frosch123> 4948 was 07-19 :p
20:13:31  <planetmaker> :D
20:13:33  <planetmaker> ok
20:13:37  <frosch123> today is 4979
20:14:40  <planetmaker> well. bamboo testing license till 18 September :D
20:17:18  <andythenorth> lego time
20:17:23  <planetmaker> :-)
20:19:01  <frosch123> let's try WSGIPassAuthorization :)
20:21:23  *** tycoondemon has quit IRC
20:21:27  <frosch123> \o/ success
20:21:35  <planetmaker> \o/
20:21:38  *** tycoondemon has joined #openttdcoop.devzone
20:21:52  <frosch123> let's also check https
20:22:18  <frosch123> yup :)
20:22:41  <frosch123> so, that's as far as i came with the test vm
20:22:54  <planetmaker> :-)
20:23:03  <frosch123> i have no idea what the new commit / repository stuff needs / does
20:23:49  <frosch123> oh, i should prepare a patch for albert with the new mod_wsgi support
20:24:27  <planetmaker> hm, should it create projects from the devzone projects automatically or does it need manual adding?
20:25:11  <frosch123> manual
20:25:34  <frosch123> but you can only create projects for which yuo are already manager :p
20:25:58  <planetmaker> so ... is that enforced already?
20:26:00  <frosch123> so, it's not exactly an "create project" but rather an "enable eints for project"
20:26:06  <frosch123> planetmaker: untested :p
20:26:24  <planetmaker> is at your disposal ;-)
20:31:03  <Alberth> planetmaker: lang_sync script just accesses the http server programmatically for making projects and up/downloading language changes, so it's just as enforced as the normal page access
20:31:42  <planetmaker> Alberth, should we add a commit hook to repos, if lang/* is touched?
20:31:52  <planetmaker> would that make it easier than, say, polling?
20:32:04  <frosch123> planetmaker: actually, eints manual suggests to only make eints accessible via https
20:32:08  <frosch123> should we enforce that?
20:32:18  <^Spike^> that is possible frosch123
20:32:27  <^Spike^> we can make a rewrite rule on http to https
20:32:28  <frosch123> (not that i know how though) :)
20:32:34  <^Spike^> on the proxy end
20:32:41  <Alberth> unless you want authentication to be freely floating over the internets
20:32:42  <^Spike^> so before it even reaches eints
20:32:55  <^Spike^> it will https -> proxy -> http -> eints
20:33:01  <^Spike^> as proxy-> eints is internal
20:33:05  <^Spike^> i wouldn't be too worried
20:33:11  <^Spike^> unless you prefer otherwise
20:33:18  <^Spike^> then we wouldn't do ssl offloading on the proxy
20:33:32  <Alberth> local access should be fine
20:33:38  <frosch123> Alberth: well, earlier i added debug output, which printed user names to the logs. i remembered to not print passwords to not trap poor souls; and in fact i would have trapped pm :p
20:33:56  <planetmaker> ^
20:34:16  <^Spike^> you do know... that abusing any rights when i'm around is very dangerous... :)
20:34:17  <Alberth> unless you don't trust people that have login access to the machine :)
20:34:27  <^Spike^> i work in the hosting business security breaches are taken very seriously... :)
20:34:32  <^Spike^> in any shape/form :)
20:34:46  <^Spike^> aka if we need to shutout a user we will
20:35:24  <planetmaker> :D got ^Spike^ on the wrong footing there :D
20:35:41  <Alberth> I fully agree with that policy
20:36:44  <^Spike^> planetmaker knows my stand on security and also knew i work in hosting so :)
20:36:54  <planetmaker> yup :-)
20:36:54  <Alberth> frosch123: https would not have made any difference afaik, the http request gets decoded before reaching eints
20:36:56  <^Spike^> it's not a suprise for him :D
20:37:00  <planetmaker> and I quite appreciate that
20:37:10  <^Spike^> Alberth i can make it ssl -> ssl just more of a pain to do :)
20:37:22  <frosch123> Alberth: ofc, in the password checking module the pw is always raw :p
20:39:51  <planetmaker> frosch123, well... one could compare hashes ;-)
20:40:27  <frosch123> then your browser already has to compare the hash
20:40:31  <frosch123> *compute
20:40:37  <planetmaker> hm... :-)
20:40:48  <Alberth> except RM has a different hashed value :p
20:41:35  <frosch123> Alberth: what's the .rst code for a preformatted section / quote / code example ?
20:42:29  <frosch123> some other places uses just indenting
20:42:36  <frosch123> i am using that as well :p
20:43:17  <Alberth>     <-- the :: start the example
20:43:55  <Alberth> you can have  ::  at the left margin, then they are not output
20:46:30  <Alberth>  is the place to look for stuff.  Restructured text (rst) is the base system, sphinx adds some stuff, like inter-document linking in a nice way
20:46:31  <Webster> Title: First Steps with Sphinx Sphinx 1.1.3 documentation (at
20:47:23  <Brot6> Industrial Stations Renewal - Revision 240:14af869fbfb2: Codechange: Fix whitespace errors Xmart3pX @
20:48:34  <Alberth> good night
20:49:05  <andythenorth> night
20:49:08  *** andythenorth has quit IRC
20:49:45  *** Alberth has left #openttdcoop.devzone
20:53:03  <Brot6> Webtranslator - Patch #6272 (New): Support for mod_wsgi XfroschX @
20:53:14  <frosch123> he, since when is it that fast?
20:53:57  <frosch123> didn't it use to take at least 30 seconds for announcing stuff?
20:55:29  <planetmaker> it has a good day ;-)
21:05:14  *** Jam35 has quit IRC
21:07:28  <^Spike^> :)
21:10:28  *** Supercheese has quit IRC
21:11:24  <frosch123> night
21:11:27  *** frosch123 has quit IRC
21:24:50  *** gelignite has quit IRC

Powered by YARRSTE version: svn-trunk