1.0.518a651-dirty

[Cooper]

Hello everyone!
After a few months break from openxcom Im finally back. However I ran on to this problem on my fresh installation. Does it mean something is wrong with the installation?

[Meridian]

No, probably everything alright.

Just in case: where did you get your build from?

[Cooper]

Alright
Its from https://openxcom.org/git-builds/ > Ubuntu   

[Meridian]

Everything alright then.
It's not the newest version, but quite recent (10th June 2016).

[R1dO]

The dirty tag is there to remind people that the exe was build using source-code with alterations to tracked files based on the specific commit (518a651 in this case).
Alterations could mean anything ranging from a simple comma in a readme file to massive source code alterations.

Think of it as a warning message telling devs that it would be hard (if not impossible) to exactly recreate the exe when investigating strange behavior.

What is strange though is that this 'rogue' build ended up as an official git-build.

[SupSuper]

The dirty tag is there to remind people that the exe was build using source-code with alterations to tracked files based on the specific commit (518a651 in this case).
Alterations could mean anything ranging from a simple comma in a readme file to massive source code alterations.

Think of it as a warning message telling devs that it would be hard (if not impossible) to exactly recreate the exe when investigating strange behavior.

What is strange though is that this 'rogue' build ended up as an official git-build.

Any changes to build makefiles, which you might make in order to automatically build nightly packages, would count as "dirty" no?

[R1dO]

It would if those files are under git control.

For this specific case i suspect the following files cause the dirty tag:

Code: [Select]

install/debian/changelog
install/debian/control

The second one could have an easy fix (propagate the requirement to the master branch, although i would recommend a slight change in order to allow people with older yaml versions to run the nighlies as well)

The first one is more difficult since it will change on each build.

[knapsu]

Hey! Sorry for digging up such an old thread... The problem with version number is now fixed. I had a typo in my automated build scripts which resulted in OPENXCOM_VERSION_STRING always sticking with commit hash 518a651 despite sources being in more recent version. I've checked the latest builds and it is good now.