Log for #openttdcoop.devzone on 20th May 2010:
Times are UTC Toggle Colours
00:20:23  *** OwenS has quit IRC
00:21:23  *** Seberoth has quit IRC
00:30:22  <Webster> Latest update from devactivity: OpenGFX - Bug #942: Profit icons are too similar to "moving" icon <>
01:38:09  *** PeterT is now known as Sn2
01:38:11  *** Sn2 is now known as SN2
01:38:43  *** SN2 is now known as PeterT
03:52:24  *** Webster` has joined #openttdcoop.devzone
03:55:49  *** Webster has quit IRC
03:55:50  *** Webster` is now known as Webster
06:39:54  *** ODM has joined #openttdcoop.devzone
07:41:10  *** OwenS has joined #openttdcoop.devzone
08:09:24  *** ODM has quit IRC
09:04:27  *** Seberoth has joined #openttdcoop.devzone
09:46:33  *** OwenS has quit IRC
09:57:26  *** Seberoth has quit IRC
09:57:31  *** Seberoth has joined #openttdcoop.devzone
10:05:27  *** ChanServ sets mode: +o Webster
10:39:24  *** KenjiE20 has joined #openttdcoop.devzone
11:31:45  *** welshdragon has quit IRC
11:35:39  *** welshdragon has joined #openttdcoop.devzone
11:36:27  *** PeterT has quit IRC
11:36:52  *** PeterT has joined #openttdcoop.devzone
12:33:48  *** Seberoth has quit IRC
12:34:57  *** Seberoth has joined #openttdcoop.devzone
13:56:37  *** Seberoth has quit IRC
14:00:51  *** yorick has joined #openttdcoop.devzone
14:59:46  *** OwenS has joined #openttdcoop.devzone
15:24:49  *** ODM has joined #openttdcoop.devzone
15:34:54  *** Seberoth has joined #openttdcoop.devzone
16:18:38  <Brot6> worldairlineset: compile completely failed! :-( -
16:18:38  <Brot6> Following repos didn't need a update: 2cctrainset (r528), 32bpp-extra (r33), airportsplus (r48), bros (r10), comic-houses (r69), firs (r833), fish (r367), heqs (r318), nmts (r15), nutracks (r59), opensfx (r88), snowlinemod (r10)
16:31:39  <Ammler> yorick: any chance to tell FaddyPainter that he checks his mailbox?
16:32:04  <Ammler> maybe he can define another better address, not this stupid hotmail
16:32:21  <Ammler> it is possible to hide the address from public
16:32:23  <Webster> Latest update from devactivity: World Airliners Set - Support #944 (New): Email check <>
16:33:10  <Ammler> He seems to ignore the tickets, which really sucks...
16:36:55  *** frosch123 has joined #openttdcoop.devzone
16:37:49  <yorick> Ammler: I'll try extspotter
16:38:44  <yorick> extspotter said "k"
16:38:57  <yorick> and passed it on :P
16:39:27  * yorick afk
16:39:37  <Ammler> I send a pm with tt-forums
16:42:52  <planetmaker> there can be only one
17:03:36  <Webster> Latest update from devactivity: World Airliners Set - Revision 641: Fixed problem USAir A330 was not pushed. <> || OpenMSX - Revision 57: DevZone: enable nightlies compile <>
17:04:58  <yorick> I don't think he fixed the right one
17:05:09  <yorick> oh nvm he did
17:05:45  <yorick> andythenorth:
17:05:50  <yorick> ammler: translation missing: nl, lable_no_code_reviews
17:05:53  <yorick> meh
17:05:56  <yorick> wrong tab
17:06:50  *** Doorslammer has quit IRC
17:08:28  <Ammler> yorick: I would rather like he is fixing his mail
17:09:09  <Ammler> or checking the tickets
17:09:20  <yorick> Ammler: how else did he fix the easyjet issue?
17:09:54  <Ammler> I don't think with tickets
17:10:10  <Ammler> else he would comment those or mention in the commit logs
17:10:56  <Ammler> I do add WAS to the new compiler now, would need a commit from my side, is that ok?
17:11:35  <Ammler> or will you? :-)
17:11:58  <Ammler>
17:12:24  <Ammler> the new compiler doesn't need any ssh access anymore
17:12:52  <yorick> hmm there's a new compiler?
17:12:56  <yorick> I needed ssh access?
17:13:06  <Ammler> for the nightlies
17:13:26  <Ammler> you needed ssh to activate it
17:13:45  * yorick never did that
17:14:45  <Ammler> .devzone/build/nightlies/enable
17:14:58  <Ammler> of course, I don't think you have ssh access, do you?
17:15:25  <yorick> I think not
17:15:29  <yorick> I used to :P
17:15:44  <Ammler> someone of use enabled it for WAS
17:16:05  <Ammler> shall I push that file or will you?
17:16:53  <yorick> you can push it
17:17:02  <Ammler> also maybe we should rename the project and remove the typo, or add :-)
17:18:51  * yorick gone
18:12:12  <Brot6> worldairlineset: compile of r642 failed -
18:14:02  <Rubidium> whahahaha
18:22:38  <Webster> Latest update from devactivity: World Airliners Set - Revision 642: DevZone: enable project for new nightly compiler <>
18:36:47  <Ammler> hmm, needs a custom spec
18:37:29  <Rubidium> or a bogus md5
18:45:46  <Brot6> worldairlineset: compile of r643 failed -
18:45:47  <Brot6> Following repos didn't need a update: nml (r171), ogfxplus (r18), opengfx (r457), openmsx (r57)
18:48:17  <Brot6> worldairlineset: update from  to r643 done -
18:53:24  <Ammler> majonaise!
18:53:33  <planetmaker> ketchup!
18:54:14  <Webster> Latest update from devactivity: World Airliners Set - Revision 643: DevZone: slightly custom spec and files list <>
18:54:27  <Ammler> planetmaker: you think, you are able to enable a project for the new compiler?
18:54:45  <Ammler> now I finish the release part
18:54:50  <planetmaker> dunno?
18:55:07  <planetmaker> I've no idea, but I didn't look at how to do that either
18:55:10  <planetmaker> so far
18:55:40  <Ammler> well, all pm-Makefile projects should work by simply add a file called ".devzone/build/nightlies/enable"
18:55:52  <Ammler> (touch)
18:56:16  <Ammler> please do also think about security...
18:56:21  <planetmaker> then I guess I should be able to do that ;-)
18:56:49  <Ammler> is it possible for "pushers" to make something bad?
18:57:09  <planetmaker> depends on the rights make is called with
18:57:13  <planetmaker> can it do harm?
18:57:34  <Ammler> well, that doesn't hurt, that is in a chroot
18:58:00  <Ammler> you can run rm / -rf if you like ;-)
18:58:22  <Rubidium> as long as you rebuild the chroot each time, that's not a real problem
18:58:55  <Ammler> does it need rebuilding?
18:59:02  <Rubidium> *until* you grant applications in the chroot network access. Then they might run a spam server or something in the chroot
18:59:10  <Ammler> no network access
18:59:26  <Rubidium> Ammler: if you rm -rf the whole chroot, then for the next run it shouldn't crash I'd say
18:59:55  <Ammler> well, the build script works just with rpm
19:00:17  <Ammler> you aren't root in the chroot :-)
19:00:39  <Ammler> it does su you to a user
19:00:52  <Ammler> I am more afraid of the part I do outside...
19:01:53  <Brot6> Following repos didn't need a update: nml (r171), ogfxplus (r18), opengfx (r457), openmsx (r57), worldairlineset (r643)
19:02:19  <planetmaker> what do you do outside?
19:04:01  <Ammler>
19:09:24  <Webster> Latest update from devactivity: #openttdcoop - Revision 48: Major update after some test runs <>
19:14:35  <Ammler> I am still waiting for a script to merge a patch queue to a dummy repo
19:14:45  <Ammler> (and a patch for the public)
19:14:58  <Ammler> Hirundo: ^ :-)
19:23:31  <Ammler> I move the old compiler to 17:17 and set the new to 18:18
19:25:14  <Webster> Latest update from devactivity: FISH - Revision 369: Change: partial progress on Flying Lion Hovercraft <> || FISH - Revision 370: Change: hide Flying Lion hovercraft <> || FISH - Revision 368: Add: nfo file for Medium Mixed Hovercraft <>
19:28:14  <planetmaker> Ammler: hg qpush -a && hg diff > complete_patch.diff && hg clone trunk && cd trunk && patch -p1 < path/to/compelte_patch.diff
19:28:55  <Ammler> planetmaker: what does qclone?
19:29:09  <planetmaker> no idea.
19:29:16  <planetmaker> does it even exist?
19:29:22  <Ammler> yes, it does
19:29:32  <Ammler> but it wouldn't work on our DevZone :-)
19:29:37  <planetmaker> no?
19:29:38  <yorick> planetmaker: I'd prefer a pipe :p
19:29:58  <planetmaker> yorick: but you don't have to maintain the server ;-)
19:30:21  <yorick> hg qpush -a && hg clone trunk && cd trunk && (hg diff .. | patch -p1)
19:30:36  <Ammler> hmm
19:30:43  <yorick> or maybe without ()
19:30:53  <planetmaker> yorick: you notice that you propose something entirely different than I do?
19:31:01  <Ammler> it doesn't need to be a onliner :-)
19:31:07  <planetmaker> that you do a diff of a clean repo while I do that of the queued repo?
19:31:08  <Ammler> oneliner*
19:31:24  <planetmaker> yours will utterly fail to do what is needed / intended
19:32:50  <yorick> planetmaker: did you notice the .. too?
19:33:43  <planetmaker> yes. you don't want to take my commands too litterally. One doens't want to create a repo within another like this
19:33:59  <planetmaker> mine was meant as the steps needed. The cloning would need doing in a chroot or so
19:34:24  <yorick> mhm
19:35:51  <planetmaker> besides the combined patch is a separate, desired output anyway
19:37:11  <planetmaker> As Ammler says: it's not required to be a one-liner anyway :-)
19:37:42  <Ammler> I am not sure about both of you :-)
19:37:59  <Ammler> hg qpush means, I need a repo with patch queue
19:38:06  <planetmaker> yes, it does
19:38:09  <yorick> I'm not sure about me either :-)
19:38:20  <planetmaker> you don't want that, Ammler ?
19:38:28  <planetmaker> without it's difficult
19:38:46  <Ammler> planetmaker: well, if I need to, I guess, I can live with it
19:38:58  <Ammler> but then, why do I need to clone trunk again?
19:39:07  <planetmaker> I thought about a process which would take the patch queue, patch a clean trunk repo with it, create combined patch and binary from it
19:39:23  <planetmaker> Ammler: as the patch queue repo only contains the patches ;-)
19:39:28  <planetmaker> and not the whole repo
19:39:56  <planetmaker> s/repo/whole trunk repo/
19:40:28  <Ammler> can't I apply the patches to a repo, where I have also the patches as queue?
19:41:46  <planetmaker> you don't have a repo where the patch queue is.
19:42:08  <planetmaker> the patch queue repo is just a bunch of patches
19:42:12  <Ammler> I need for qpush
19:42:16  <planetmaker> and the file indicating their order
19:42:26  <Ammler> series does?
19:42:29  <planetmaker> ah. Yes.
19:42:45  <planetmaker> Well. Then the hg clone needs to be before the hg qpush, yes :-)
19:42:48  <planetmaker> and some copying
19:43:49  <Ammler> so hg clone <trunk> && cd .hg && hg clone <patch-queue-repo> patches && cd .. && hg qpush
19:44:17  <planetmaker> probably something like that, yes
19:44:44  <planetmaker> you will need to make sure that the repo is recognized to run with mq
19:44:48  <Ammler> hg diff > total.diff hg ci -A -m "..."
19:45:55  <Ammler> oobs
19:46:39  <planetmaker> maybe a hg qinit and then the cloning of the mq
19:46:40  <planetmaker> dunno
19:46:46  *** yorick has quit IRC
19:47:44  <Yexo> it should be "hg qpush -a" instead of just "hg qpush"
19:47:47  <Ammler> don't think so
19:48:13  <Ammler> hg qinit does simply create .hg/patches and init
19:48:40  <Ammler> if you clone, you should have a repo already
19:48:49  <Ammler> hmm, no, it doesn't
19:49:05  <Ammler> there is no versioned repo per default, is there?
19:55:15  <planetmaker> I don't thins so, no
19:58:37  <Ammler> so hg qinit just creates the dir?
19:58:56  <Ammler> (.hg/patches)
20:03:55  <planetmaker> IIRC yes
20:04:03  <planetmaker> only hg qnew starts to create a patch
20:27:30  <Webster> Latest update from devactivity: #openttdcoop - Revision 49: [Compiler] chmod +x <>
20:32:42  *** frosch123 has quit IRC
20:42:38  <Webster> Latest update from devactivity: OpenTTD-GUI - Revision 15234: - Codechange: Tidy up the OnPaint function of the newgame window an... <>
21:18:48  <Hirundo> Ammler: Patch queue pseudo-script:
21:20:32  <Ammler> --no-commit?
21:23:25  <Ammler> Hirundo: you pull trunk from, I assume?
21:23:39  <Hirundo> Yes
21:24:16  <Hirundo> I used to apply each patch independently, so not using --no-commit would result in 10-15 commits per patch queue commit
21:25:12  <Ammler> merge algorithm = internal:other?
21:26:02  <Ammler> pop the patches before pull trunk?
21:26:15  <Ammler> and then reapply and merge
21:27:07  <Hirundo> In my case, the 'normal' repo does not use patches, so there's nothing to pop
21:27:18  <Ammler> I guess, it still makes sense to keep a merged repo available for public?
21:27:44  <Ammler> or shall we keep that "private" for the compile farm only?
21:27:49  <Hirundo> What do you mean by 'merged' repo?
21:28:12  <Ammler> trunk merged with patch queue so tip can be compiled
21:28:33  <Ammler> (repo without patch queue)
21:29:17  <Hirundo> Basically such a repo is meant for two things, at least for me
21:29:37  <Hirundo> a) it allows hg pull without any extra hassle, useful for the compile farm
21:29:56  <Ammler> s/useful/required/
21:29:57  <Hirundo> b) it provides a better readable history (no diffs of diffs)
21:31:08  <Ammler> maybe we could make a script, which applies every single patch queue commit as single commit to the repo?
21:32:40  <Ammler> and reuses the commit message
21:33:16  <Hirundo> You mean every patch queue commit in the entire patch queue history?
21:33:24  <Ammler> yes
21:33:38  <Ammler> maybe create a branch per patch :-)
21:34:07  <Ammler> or would that become a big merge hassle?
21:35:16  <Hirundo> The trunk version isn't constant during the life of a patch queue, getting that right may be immensely tricky
21:35:46  <Ammler> hmm, true
21:38:14  <Ammler> [23:26] <Hirundo> In my case, the 'normal' repo does not use patches, so there's nothing to pop <-- how you mean
21:38:31  <Ammler> you need to apply the patches somewhere to compile openttd :-)
21:39:08  <Hirundo> "pop the patches before pull trunk" <- popping does not work in the normal repo
21:39:46  <Ammler> ah ok
21:40:01  <Ammler> so you revert the patches, update and apply again?
21:40:50  <Ammler> meh, I fear, I still don't get it...., I should try it myself...
21:42:48  <Hirundo> If there's nothing to pull, you revert to the latest trunk rev and re-apply the patches
21:43:20  <Hirundo> If there is something to pull, pull those revs and merge the two heads (old tip and trunk)
21:43:54  <Hirundo> By setting merge algorithm to internal:other, the merge leaves the working dir in the state of the trunk rev, so the patches can be applied
21:45:34  *** GT has joined #openttdcoop.devzone
21:47:14  <Ammler> I added your paste to the tracker, so it doesn't go lost
21:47:27  <Ammler> first I finish the compiler for releases
21:47:41  <GT> Ammler, planetmaker: I saw you were creating a script to apply a patch queue to a trunk repo. Isn't it easier to just pull from the patch queue (in the patches dir) and then push -a?
21:47:56  <Ammler> hehe
21:48:03  <Ammler> we just talked about it
21:48:11  <GT> Thats what I do locally
21:48:27  <GT> I know, thats why I reacted
21:48:54  <Ammler> [23:28] <Hirundo> Basically such a repo is meant for two things, at least for me
21:48:55  <Ammler> [23:29] <Hirundo> a) it allows hg pull without any extra hassle, useful for the compile farm
21:49:02  <Ammler> [23:29] <Hirundo> b) it provides a better readable history (no diffs of diffs)
21:49:17  <Hirundo> That leaves you without a revision history (b)), although it is suitable for the compile farm( a))
21:49:56  <Ammler>
21:52:54  <Hirundo> OK, going to sleep now, goodnight
21:53:03  <Ammler> good night and thanks
21:54:01  <GT> night
21:55:08  <GT> Ammler, I ve been struggling a bit with this too, and the diffs of the diffs is a valid point, but otoh, having each project a complete ottd repo is not very efficient for your server.
21:55:08  <Ammler> GT, is your patch MP "safe"?
21:55:22  <GT> ? safe as in?
21:55:33  <GT> no desyncs
21:55:43  <GT> Then I guess so
21:55:56  <Ammler> GT, I would clone/pull a local clone of trunk
21:56:10  <Ammler> so that shouldn't be a bit issue
21:56:52  <GT> As the patch only changes graphics
21:57:00  <Ammler> GT running 32bpp-ez on a non-ez server
21:57:24  <GT> I think so, all blittering etc is done on the client
21:57:57  <Ammler> you don't patch moving and such?
21:57:57  <GT> no docommand changes, I think, though Ive never tried it in MP
21:58:19  <GT> What do you mean with patch moving
21:58:22  <Webster> Latest update from devactivity: #openttdcoop - Feature #945 (New): Automerge of patch queue <>
21:58:38  <Ammler> not patch moving, I meant for example moving of a vehicle
21:58:48  <GT> no
21:59:08  <Ammler> or you also had a longwagon version sometime agao
21:59:27  <GT> I dropped it, too hacky, and too many glitches
21:59:51  <GT> It was in V10, in later versions original scales are back again
22:01:55  <GT> I have not restored the 32bpp-ez repo again, because imho there are two kind of users: windows: all they nag about is a run of the compile farm, and linux users, they usually are very capable of applying a patch from the patch queue
22:03:24  <Ammler> GT no need for you
22:03:33  <Ammler> that would be task of the DevZone
22:03:45  <Ammler> for example with changegroup hook
22:04:34  <GT> So in my ideal scenario, your server would have a weekly or monthly, whatever, run on the compile farm, having a script that would apply the various patches to the trunk repo. It's not efficient for your server to have a complete duplicate of the ottd repo for every project
22:05:04  <Ammler> there aren't that many openttd projects :-)
22:05:27  <Ammler> let me check, how much space such a "clone" weights
22:05:38  <GT> Not yet, but still, it also matters for the devs of the patches, having to push every change twice
22:06:37  <GT> I think users would be more pleased with having a binary directory, than with a complete repo, as not everyone uses hg.
22:07:06  <Ammler> 62M     trunk
22:07:07  <Ammler> 484K    trunk.zwei
22:07:21  <Ammler> so you see, a clone of trunk isn't 1MB :-)
22:08:02  <Ammler> thanks to intelligent linux file system :-P
22:08:14  <GT> yeah, hard linking rulez
22:08:39  <Ammler> well, I should apply a patch to trunk.zwei
22:08:46  <Ammler> and see how that would change
22:09:01  <GT> zwei is two I suppose?
22:09:11  <Ammler> yes :-D
22:10:19  <Ammler> now, where do I get a patch?
22:10:33  <Ammler> is2 is already old ;-)
22:10:43  <GT> 32bpp-ez-patches isnt
22:11:11  <Ammler> you still have only one?
22:11:57  <GT> yes, really should be splitting it in several ones, but you know, time, real life etc..
22:12:02  <Ammler> 1 out of 29 hunks FAILED -- saving rejects to file src/viewport.cpp.rej
22:12:13  <Ammler> mäh, :-P
22:12:41  <GT> mm, guess I should update again
22:13:44  <Ammler> 62M     trunk
22:13:45  <Ammler> 12M     trunk.zwei
22:13:48  <Ammler> with your patch
22:14:06  <GT> I always put the svn rev nr in the commit message, but it would take some scripting to update the trunk repo to that rev (use some templating for the hg log)
22:14:26  <Ammler> I have already such scripts
22:14:47  <GT> Nice :)
22:14:53  <Ammler>
22:16:20  <GT> from 484k to 12M, that's pretty much
22:16:33  <Ammler> hehe, you have a huge patch
22:17:00  <GT> Well, maybe, but not compared to the ottd trunk
22:17:23  <GT> I dont think it changes 20% of the files
22:17:31  <Ammler> every file you patch lost the link
22:18:05  *** andythenorth has left #openttdcoop.devzone
22:18:24  <Ammler> and some files can have huge history...
22:18:26  <GT> All the more reason to not have a full 32bpp-ez repo, and only have the patch queue
22:18:28  *** ODM has quit IRC
22:18:39  <Ammler> I don't really care
22:18:52  <Ammler> today, disk space isn't really a issue
22:19:31  <Ammler> it a sep repo would help, fine with me
22:23:32  <GT> Maybe, but then there's still the issue of the devs having to push each change twice, and for projects that are updated by multiple people, the problem of pulling the full repo and the patch repo, and apply everything in the correct order. Makes things complicated.
22:24:21  <GT> And I still think far more people would appreciate frequent windows bins, than having a full hg patched repo
22:25:05  <Rubidium> does frequent imply regular?
22:25:44  <GT> no, frequent is often, regular is at fixed intervals, once a year is also regular
22:26:13  <GT> geregeld vs regelmatig
22:27:19  <GT> most would be interested in frequent, even irregular I think
22:28:53  <Rubidium> hmm, that makes me wonder whether the CF can run on not-a-day intervals
22:29:52  <Rubidium> nope, that would need to be coded
22:31:26  <GT> Too bad, anyway, I call it a night, have to go to Delft tomorrow, to explain a professor something, so I need the sleep
22:31:30  <Rubidium> so "regular", in the sense of CF, can only be once a daily every day
22:32:16  <Rubidium> in which case a full hg patched repo is probably worth more as the binaries (for multiple platforms) will be generated automagically
22:33:40  <GT> You mean having a full repo could enable having up to date bins daily?
22:33:54  <Rubidium> yes
22:34:00  <GT> That would be a strong argument to create one
22:34:18  <Rubidium> probably at an unsane time-of-day though
22:34:35  <Rubidium> i.e. somewhere in the middle of the night
22:35:47  <Ammler> Rubidium: or something weekly...
22:35:57  <GT> well, if that would mean daily updates, I coulnd care less, builds on openttdcoop are also once a day, dont think may would object to the exact time.
22:36:14  <GT> Even weeklies would be a big improvement over none at all
22:37:00  <Rubidium> oh, a long time ago someone was kinda picky about which time the thing had to be compiled
22:37:41  <Rubidium> anyhow, the early evening is "booked" full with all kinds of small things like strgen/pngcodec/catcodec and openttd's nightlies
22:38:19  <Rubidium> later in the evening the site gets quite busy and devs get pretty active, so not doing a compile run would be best at those times; it's also the regular time for releases
22:38:19  <GT> Well, now I'm really going, but I'm certainly getting back at this.  Night to yall..
22:38:43  <Rubidium> and somewhere in the night ttdpatch/grfcodec/nforenum gets compiled (don't know exactly when)
22:40:13  <Ammler> and it does only build, if there are changes, so chances are high, it isn't daily anyway
22:40:21  <Ammler> like IS2 had no update since january
22:43:07  *** GT has quit IRC
23:21:46  <Ammler> @mode +b *!*
23:21:47  *** Webster sets mode: +b *!*
23:28:51  *** Seberoth has quit IRC
23:41:18  <Ammler> <-- specially the repository view
23:41:25  <Ammler> with tags and hashes
23:42:57  *** OwenS has quit IRC
23:44:21  <Ammler> very nice :-)
23:52:25  *** KenjiE20 has quit IRC

Powered by YARRSTE version: svn-trunk