Log for #openttdcoop.devzone on 25th October 2012:
Times are UTC Toggle Colours
06:10:40  *** Zuu has joined #openttdcoop.devzone
07:22:08  *** Zuu has quit IRC
09:38:51  <Ammler> <-- opengfx fails the check
09:40:16  <Ammler> it needs to be a new tool, there are working 0.4.5 there
09:43:05  <Ammler> extra grf, so looks like nml, right?
09:45:02  <Ammler> nml is the only tool which I can imagine to break all distros at once
10:11:44  <planetmaker> but 0.4.5 built on our server when I pushed it
10:12:04  <planetmaker> and it should build using latext release of nml 0.2 branch
10:12:44  <planetmaker> so unless I know what error exactly occurs it's a bit hard to comment and a bit pointless to speculate
10:23:49  <Ammler> it also built on obs
10:24:09  <Ammler> if you click on a distro, you see there are already 0.4.5 packages
10:26:44  <Ammler> if it is extra only, we can exclude ply and pil, right?
11:01:00  <Brot6> zBaseBuild - Bug #4437 (New): Updating sprites XzephyrisX @
11:15:15  <Ammler> same issue with 0.4.4
11:21:19  <Ammler> planetmaker: not possible, nml 0.2.3 and 0.2.4 are makeing different sums?
11:30:47  <Ammler> Yexo: planetmaker, if I am able to confirm 0.2.3 and 0.2.4 producing different extra grf, how should we proceed?
11:31:50  <Yexo> nml 0.2 builds 'old' newgrfs, so md5sum is over the complete newgrf
11:32:02  <Yexo> it's very possible there are differences in the binary output between 0.2.3 and 0.2.4
11:32:10  <Yexo> that doesn't mean either is broken, just that they're different
11:32:40  <Yexo> planetmaker: was 0.4.5 not pushed before the nml 0.2.4 release?
11:33:50  <Ammler> yes
11:35:52  <Ammler> 0.4.5   2012-09-25      opengfx releases
11:35:54  <Ammler> 0.2.4   2012-10-14      nml     releases        abf432e8d9f8
11:38:27  <Ammler> [   ] openttd-opengfx-0.4.5-9.1.noarch.rpm        27-Sep-2012 20:22  3.0M   Details <-- last successful build
11:38:48  <Ammler> (on obs)
11:39:22  <Ammler> planetmaker: you see, it is dangerous to ignore errors :-P
11:41:44  <Ammler> Yexo: you don't see changing md5sum as a bug?
11:42:22  <Yexo> no, I don't
11:42:32  <Yexo> I see broken grf output as bug
11:42:36  <Ammler> anyway, what shall I do?
11:43:12  <Ammler> maybe we simply release 0.4.6
11:43:16  <Yexo> if you rebuild opengfx with a different nml version you can't compare the md5sum to the md5sum of the previous version
11:43:28  <Yexo> so either force the same nml version or don't compare the md5sum
11:43:35  <Ammler> Yexo: well, that was possible before
11:43:45  <Yexo> it worked by luck, not by design
11:44:03  <Ammler> and it was with grfcodec
11:44:35  <Ammler> I guess, you added a kind of sorting to nml to reach the same effect
11:44:38  <Yexo> grfcodec is a lot simpler tool, and there have been changes to grfcodec that would break the md5sum too (r920 springs to mind)
11:45:32  <Yexo> Say you write a python program that reads "a += 1". Python 2.5 encodes it exactly like that, but in python 2.5.1 they discovered it can be executed more efficiently as "a++". Do you care what the underlying implementation is as long as the result is the same? (a increased by one)
11:45:41  <Ammler> IMO, it would be easier to make a new opengfx release which requires nml 0.2.4
11:46:05  <Yexo> but opengfx doesn't require nml 0.2.4, it works perfectly fine with 0.2.3
11:46:26  <Ammler> yep, opengfx 0.4.4 does
11:46:32  <Ammler> or 0.4.5
11:46:48  <Ammler> but it doesn't if you build with nml 0.2.4
11:46:55  <Yexo> it still works fine
11:47:00  <Ammler> no
11:47:06  <Yexo> the only thing that is broken is that the md5sum is compared, that shouldn't be done
11:47:16  <Yexo> or rather: it should only be done as long as you're sure the nml version used is identical
11:47:21  <Ammler> md5sum is essential for upgrade or is that depreciated?
11:47:50  <Yexo> not for basesets
11:48:10  <Ammler> so why is it in the obg?
11:48:23  <Yexo> if you really want binary identical output you should force a specific nml revision, not an nml release branch like 0.2
11:48:55  <Ammler> Yexo: you know, we check md5sum since ever?
11:49:23  <Ammler> this is not somethng just I introduced lately :-P
11:49:40  <Yexo> Ammler: please go compile something with grfcodec 5 and later with grfcodec 6
11:49:44  <Yexo> you'll see binary differences too
11:51:02  <Yexo> also: over the course of nml development the regression test output (.nfo and .grf) files have been changed multiple times without changes to the input files. That alone shows that there are binary incompatibilities between different versions of nml
11:51:39  <Ammler> the newgrf rebuilds show that too
11:52:12  <Ammler> the issue we still have now, what would you suggest, shall I ignore the check?
11:52:36  <Yexo> either ignore the check or force the exact same nml version
11:52:44  <Ammler> we would also need to communicate that to other mainatainers
11:53:18  <Ammler> downgrading nml could be done too
11:53:37  <Ammler> might be easiest
11:54:17  <Ammler> a bit embarasssing
11:54:17  <Yexo> why not ignore the check but update the md5sum in the obg?
11:55:09  <Ammler> well, if that is fine, I would remove the check completely
11:55:29  <Ammler> afaik, this check also helped once to find a bug in nml
11:55:45  <Yexo> true, it's useful as long as output from one nml version is compared on multiple systems
11:55:58  <Yexo> but comparing output from different nml versions is not useful, and that's what is happening now
11:56:40  <Ammler> so releasesing opengfx 0.4.6 with nml 0.2.4 would be the perfect solution
11:56:40  <Yexo> you could also write the nml version used to create the grf files in the .obg as comment, and only enable the check if the nml version is identical
11:57:00  <Yexo> Ammler: no, because then you have the same problem when nml 0.2.5 is released and 0.4.6 would be recompiled
11:57:24  <Ammler> well, you would mention the nml version with the release
11:57:39  <Ammler> BuildRequires: nml = 0.2.4
11:57:43  <Yexo> as before: if you want to make the check you have to release 0.4.6 with a requirement on nml version == 0.2.4, not nml version >= 0.2.4
11:57:51  <Yexo> so yes, that would work
11:58:17  <Yexo> maybe something for new released, imo a build issue like this doesn't qualify a new opengfx release
11:58:33  <Ammler> so I don't downgrade nor disable check for now, let's wait for pms comments
11:58:54  <Yexo> agreed, that seems best
11:59:10  <Ammler> well, there should be a solution with next openttd release
11:59:41  <Yexo> plenty of time before that
12:42:04  <Brot6> OpenGFX - Bug #4439 (New): opengfx 0.4.5 doesn't build with nml 0.2.4 XAmmlerX @
12:45:07  <planetmaker> <Yexo> planetmaker: was 0.4.5 not pushed before the nml 0.2.4 release? <-- drat, yes. you are right.
12:46:50  <planetmaker> Yexo, but yes, for OpenGFX we need to force a specific NML version in this case. Otherwise the distributions can't re-build OpenGFX and people who get OpenGFX from a distribution will still see their OpenGFX not match bananas' one and re-download the very same thing
12:47:43  <planetmaker> thus for OpenGFX which people want to re-build to obtain binary identical grfs we need to be very specific. Unfortunately
12:52:20  <Ammler> planetmaker: yexo just said, this isn't the case for basesets anymore
12:53:22  <planetmaker> md5sum is kinda "wrong". But the comparison of the grfstripped hash is the thing to do
12:53:25  <Ammler> well, made a ticket, would be nice to "fix" this until next openttd release
12:53:43  <Ammler> which is the same for grfs without 32bpp content
12:53:56  <Ammler> grfid -m = md5sum
12:54:49  <Ammler> I checked it as I was wondering, why sou still use md5sum :-)
12:55:26  <planetmaker> why... it's the old nml 0.2 anywhay which builds container v1 where both, md5sum and grfstrip give the same result ;-)
12:55:43  <planetmaker> opengfx default or especially zbase should use grfstrip
12:56:06  <Ammler> you could use it already, it would not matter
12:56:21  <Ammler> the result it the same
12:56:32  <planetmaker> yes, wouldn't matter. But pointless to re-invent it and backport it
12:56:36  <Ammler> it would not solve the issue we get with nml
12:56:41  <planetmaker> when it only is needed for default
12:56:52  <planetmaker> it would not, indeed. It's unrelated
12:57:55  <Ammler> the easiest from view of maintainer might still be to make a new opengfx release
12:58:30  <Ammler> since yexo's assumtion that different md5sum doesn't matter is wrong
13:00:06  <Ammler> as I would not be suprised, if other distros don't do checks
13:00:46  <Ammler> nml 0.2.4 was a bad move
13:03:38  <Ammler> and the commit which makes a new release valid is mostly force nml version
13:06:19  <Ammler> though, maybe openttd could be fixed and make md5sum check depreciated
14:54:55  <Brot6> zBaseBuild - Bug #4437: Updating sprites XRubidiumX @
14:57:22  <Rubidium> Yexo/Ammler: for OpenGFX it is somewhat important that the md5sum of the GRFs matches for all distributors of OpenGFX. If this is not the case, OpenTTD will think that there is a new OpenGFX on bananas even though it's basically the same version
15:00:09  <Brot6> zBaseBuild - Bug #4437: Updating sprites XAmmlerX @
15:00:40  *** ODM has joined #openttdcoop.devzone
15:01:18  <Ammler> Rubidium: what's your suggestion
15:01:35  <Ammler> (for fixing current issue)
15:02:15  <Rubidium> document very clearly which NML must be used for OpenGFX. Also document the caveat of this issue w.r.t. bananas and then if there are problems, just blame the packager for not following recommendations
15:02:59  <Ammler> something like that would need a release
15:27:15  *** frosch123 has joined #openttdcoop.devzone
15:58:28  *** ODM has quit IRC
16:00:02  <Brot6> repository /home/hg/finnishtrainset registered in Redmine with url /home/hg/finnishtrainset
16:00:02  <Brot6> repository /home/hg/finnishtrainset created
16:25:21  *** ODM has joined #openttdcoop.devzone
16:27:34  *** Alberth has joined #openttdcoop.devzone
17:19:59  <Yexo> c<Ammler> [15:00:46] nml 0.2.4 was a bad move <- I disagree, nml 0.2.4 was not just for opengfx
17:20:19  <Yexo> and wrt the issue: I think rb's plan is best: force specific revision and document that very clearly
17:20:31  <Yexo> if it needs 0.4.6 of opengfx to document it, that's up to you/pm
17:25:16  <Ammler> or just ignore it and wait until openttd 1.3
17:26:11  <Ammler> thei issue that if we document without release, we would need document to use 0.2.3
17:27:15  <Ammler> also IMO, the makefile should add a version check and exit 1 if not matching version
17:36:01  <Ammler> My issue is that I already submitted those packages to suse but without that we wouldn't have noticed it
17:36:35  <Ammler> maybe we need to setup rebuild check also with releaes
17:44:11  <Yexo> so resubmit to suse forming version 0.2.3?
17:46:56  *** Zuu has joined #openttdcoop.devzone
17:47:52  <Ammler> well, I would just keep it as failed
17:48:09  <Ammler> until we fix it
17:49:01  <Ammler> we have opengfx 0.4.5 there, so there is no real need to get it working asap
18:18:32  *** andythenorth has joined #openttdcoop.devzone
18:18:48  <Alberth> hi andy
18:26:19  <andythenorth> lo
19:56:58  <Brot6> Finnish Trainset - Revision 0:19cc33b6f9da: Set up repo XfoobarX @
19:56:58  <Brot6> Finnish Trainset - Revision 1:a3dbb5733408: Add: makefile setup (planetmaker) XfoobarX @
19:57:48  <Brot6> Finnish Trainset - Revision 2:932dfddd43d1: Add: basic NML project setup XfoobarX @
19:57:48  <Brot6> Finnish Trainset - Revision 3:d0ed9213147d: Change: enable nightly builds XfoobarX @
20:20:48  *** ODM has quit IRC
20:35:40  *** Webster has joined #openttdcoop.devzone
20:36:46  *** Guest3156 has quit IRC
20:37:50  *** Alberth has left #openttdcoop.devzone
21:09:24  *** andythenorth has left #openttdcoop.devzone
21:14:38  *** frosch123 has quit IRC
22:10:56  <planetmaker> ui
22:11:02  <planetmaker> busy foobar
22:12:47  <planetmaker> Yexo, yes, there's no immediate gain for stable users in OpenGFX 0.4.5 (0.4.4 is fine for them). So we have a bit leeway. And an NML version check in OpenGFX might be best. I'll put it high in my agenda
23:36:54  *** Zuu has quit IRC

Powered by YARRSTE version: svn-trunk