Crash cab4aa

[Dilvish]

I think AndrewW was right to report this issue here in this forum.

Yes, I agree. I think Marcel was meaning that we can't do much to directly support builds for which we can't identify just what version of the code it is they are running. Of course, now I think we have a pretty good handle on what commit cab4aa corresponds to.

I also have to insert the version string myself, (In this case GitCommit), because I don't see a simple way to achieve that without build-depending on Git or other tools. I simply replace the ???, the default version string, with the first eight characters of the Git commit. (Back then I only used six characters)

That sounds fine to me in general, and so I guess my suggestion above to more directly support that manual version specification is unneeded? Or would that still be helpful to you?

It's still not clear to me where the cab4aa came from beyond the fact that you specified it manually-- I don't find any commit in our repo that has cab4aa as a sha subsequence, although it sounds like you did intend it to represent the beginning portion of a commit sha that we would have. I think it's worthwhile sorting out what happened there so we can be confident going forward that we will be able to recognize the version for your builds. I suspect that you probably put an extra commit into your FO git repo before determining the sha to use-- do you still have that repo available to double check?

[AndrewW]

Dedicated players like AndrewW will skip the middleman and inform you guys directly. Thanks!

I don't count though. I've been compiling FreeOrion (on Gentoo previously) since way before I tried the Debian package...

[adrian_broher]

Hello Apo,

Just FYI how I came up with "cab4aa" in the first place and how I package versions of FreeOrion for Debian. If you disagree or if there is a better way to do it, please correct me and point me to the better alternative.

Just to make some things clear:

1. There is no commit (or any other git object for that matter) with the hash `cab4aa243552328e71de55f45bc11fc189930494` in the upstream repository.
2. We won't and can't support any modified FreeOrion version. I assume it's modified, because there is no commit with said hash.
3. http://anonscm.debian.org/cgit/pkg-game ... /rules#n62 will fail, if you pass an invalid hash. So I don't know what you even packaged there (probably the HEAD master at that time).
4. The logs at https://buildd.debian.org/status/fetch. ... 1430414296 don't seem to run the get-orig-source target. Do you do this manually?

[Vezzra]

If you release 0.4.5 before the 20th of August, I will package that release. If you don't release 0.4.5 before this date, I will package another Git snapshot.

I really hope that we can get out 0.4.5 before that date. My goal would be to have the final release ready by the end of July at the latest.

[Apo]

That sounds fine to me in general, and so I guess my suggestion above to more directly support that manual version specification is unneeded? Or would that still be helpful to you?

Let's say that I would prefer a fixed version string when you release a stable version of FreeOrion. I would expect that the next Github release of FreeOrion, probably 0.4.5, contained a valid version string instead of ???. I will just download the tar.gz tarball from Github, if you tag your releases accordingly. https://github.com/freeorion/freeorion/releases

Otherwise, I'm quite happy with the way how I substitute the version string already when I prepare Git snapshots of FreeOrion. There is nothing special about it. I think I will simply stick with this method. It works.

Just to make some things clear:

1. There is no commit (or any other git object for that matter) with the hash `cab4aa243552328e71de55f45bc11fc189930494` in the upstream repository.
2. We won't and can't support any modified FreeOrion version. I assume it's modified, because there is no commit with said hash.
3. http://anonscm.debian.org/cgit/pkg-game ... /rules#n62 will fail, if you pass an invalid hash. So I don't know what you even packaged there (probably the HEAD master at that time).
4. The logs at https://buildd.debian.org/status/fetch. ... 1430414296 don't seem to run the get-orig-source target. Do you do this manually?

1. There is no commit with the exact same hash now but there was one in the past. So probably you modified your git repository in the past weeks.
2. That sounds reasonable. However I don't modify FreeOrion. As you can see in the rules file at https://sources.debian.net/src/freeorio ... ian/rules/, I created a get-orig-source target, so that everyone can verify that Debian's tarball corresponds to the exact upstream Git commit. It's only a matter of calling "debian/rules get-orig-source" in the appropriate source directory. If Debian modifies your upstream version, you can always find the changes under debian/patches. In this case I have increased the GG build verbosity because it reveals additional compiler warnings, which is a good thing in my book. I still would appreciate if you accepted this patch for the official FreeOrion release.
3. It was a valid hash back then, I assume you recreated the Git repository which would explain the differences.
4. The get-orig-source-target is only meant for manual use, so that everyone can verify how the maintainer came up with this version. Normally you won't find this target when the upstream project provides an official tarball release. I would usually download the sources this way and apply the debian directory on top it. debian/patches provides all the information how Debian diverges from the exact upstream sources.

[adrian_broher]

1. There is no commit with the exact same hash now but there was one in the past. So probably you modified your git repository in the past weeks.

That's true, but was communicated at that time. See comments from viewtopic.php?p=75832#p75832 to viewtopic.php?p=75990#p75990 for further details. I don't have the announcement available, but we announced, that we still needed to figure some things out to make a proper sourceforge -> github (svn -> git) migration and we need to re-upload the repository (we needed to do this several times to get it right). Sorry for the inconvenience anyway. The commit `cab4aa` is actually located in freeorion-archive:freeorion-backup4 and should now be identified by `06c7393c720b84ec48ad493a51bd70a80d0700af` in the freeorion:freeorion repository.

However I don't modify FreeOrion.

Given the case a user reports an issue with your software, that you can't identify the version/release and is packaged and released by a third party (Debian) what would be your first assumption? This however doesn't mean that I don't want Debian to distribute FreeOrion or you to stop packaging, quite the opposite.

If Debian modifies your upstream version, you can always find the changes under debian/patches. In this case I have increased the GG build verbosity because it reveals additional compiler warnings, which is a good thing in my book. I still would appreciate if you accepted this patch for the official FreeOrion release.

The patch you point out will never be added to upstream, because it forces me and other developers to see a lot of compile messages. Those messages are most of the time completely useless most of the and probably will hide important error messages. Instead I would suggest you call cmake with `-DCMAKE_VERBOSE_MAKEFILE=ON` (in fact you already do so) and I will remove this set statement to let the end user decide how much verbosity he likes during the compile.

4. The get-orig-source-target is only meant for manual use, so that everyone can verify how the maintainer came up with this version. Normally you won't find this target when the upstream project provides an official tarball release. I would usually download the sources this way and apply the debian directory on top it. debian/patches provides all the information how Debian diverges from the exact upstream sources.

Okay. I agree that a tarball would nice, but seeing how you modify the checkout I doubt that we can agree on how a source package should look like.

We won't deliver multiple source releases for every platform because unless I can convince the other on how much more pain free a pure CMake setup would be, the Xcode, MSVC and Installer directories still would be part of the source release. I don't understand why you would remove those anyway. Do they violate the DFSG? The same applies for the 'default/*.ttf' pattern? Why you remove this from the source release? If you don't want have it installed applying a patch or removing it in the `override_dh_install` rule wouldn't be more appropriate? Could you point out the Debian policy, that requires to remove those kind of files for having a 'pristine' source tarball?

Also is there a particular reason why you don't use CPack to package the source? In case we release a source tarball this tool would be the way to do it for us anyway. They way you do it now with sed-ing is prone to break (the current master for example won't work with that change).

[Dilvish]

1. There is no commit with the exact same hash now but there was one in the past. So probably you modified your git repository in the past weeks.

That's true, but was communicated at that time. See comments from...

It's good we've figured out where that commit sha came from, but please let's not keep acting like the timing of making that release at the same time as the git migration was Apo's primary responsibility. As has been previously discussed multiple times now, I prompted that release by specific request to Apo. I believe it was the completion of the SDL migration (along with various significant bug fixes that had already been accomplished) that prompted me to initiate the request (though my memory on it is a bit vague now), but I was not careful enough about the timing relative to the prospective git migration. For all I remember now perhaps the migration was already in process and it was just exceptionally poor thinking on my part that led me to prompt Apo's new release then; regardless, if anything about the timing of that release needs to be discussed more then I think it should be addressed to me rather than consuming further time from Apo.

[Apo]

I think Dilvish has already explained why I uploaded this specific FreeOrion snapshot to Debian. I don't rebuke anybody. Actually I was fully aware that the svn/git migration was going on but I wasn't concerned at all, I even communicated that back then (can't find the thread now) and I still don't worry about it.

Given the case a user reports an issue with your software, that you can't identify the version/release and is packaged and released by a third party (Debian) what would be your first assumption? This however doesn't mean that I don't want Debian to distribute FreeOrion or you to stop packaging, quite the opposite.

I would contact the guy who packaged this version and ask him how he came up with it. As it was already explained in this thread, there is nothing fishy about how the tarball is constructed. Everyone can view the code in debian/rules and regenerate the same upstream release or snapshot by running "debian/rules get-orig-source" in the FreeOrion source directory. If there is no get-orig-source target (optional), you can find normally more information in debian/README.source (optional). Otherwise the released version corresponds exactly with your released upstream version. If the version string contains a +dfsg, +ds or +repack it means there was a reason to repack the tarball. Most common case is it went against the Debian Free Software Guidelines.

Okay. I agree that a tarball would nice, but seeing how you modify the checkout I doubt that we can agree on how a source package should look like.

I am absolutely sure we can agree on a source tarball release. Since I created a get-orig-source target for my and others convenience anyway, I also took the liberty to remove files which are quite unnecessary on a Linux system and I'm sure you agree that the msvc2010, Xcode and Installer can be ignored for Debian. However I would not remove them from your original tarball because they don't violate the DFSG and there is no compelling reason to repack the tarball just because it would save a few hundred KB of disk space. The same goes for the font files. Every project on this planet bundles font files and we try to optimize this process by packaging all fonts only once in separate packages and then we symlink your font files to the appropriate place. The benefit is, as it is with all other software, you need to fix issues only in one place. This saves precious time and disk space and is in general very efficient. The only downside is that I have to document the copyright for the fonts files in debian/copyright but that's not a real blocker.

The patch you point out will never be added to upstream, because it forces me and other developers to see a lot of compile messages. Those messages are most of the time completely useless most of the and probably will hide important error messages. Instead I would suggest you call cmake with `-DCMAKE_VERBOSE_MAKEFILE=ON` (in fact you already do so) and I will remove this set statement to let the end user decide how much verbosity he likes during the compile.

Please remove the set statement then. The only reason why I have to keep this patch around is because -DCMAKE_VERBOSE_MAKEFILE=ON does not work for this directory (because it is set to OFF explicitly. Having verbose compiler messages is good in many ways. Most importantly the log files for Debian's autobuilder are scanned for compiler warnings and some of these warnings indicate hidden issues like buffer overflows.

https://qa.debian.org/bls/index.html
https://qa.debian.org/bls/bytag/E-array-bounds.html

This is just another QA tool but a useful one. I doubt that end users will ever complain about too much compiler verbosity. This is a feature for developers. Please make it at least an option to opt-in for more verbosity.

Also is there a particular reason why you don't use CPack to package the source? In case we release a source tarball this tool would be the way to do it for us anyway. They way you do it now with sed-ing is prone to break (the current master for example won't work with that change).

The get-orig-source-target is really optional. I, as the maintainer of FreeOrion, am ultimately responsible for what I upload to the official archive. Cloning the git repository has always worked for me and nobody ever complained to me.

Of course I wouldn't need all this stuff, if there was a nice source tarball of your official releases.

Github offers all the functionality to make this a really easy step and all package maintainers will be eternally grateful to you. Check out MegaGlest. These guys know how it should be done.

https://github.com/MegaGlest