vcmi 0.97 is now in the Debian NEW queue and will migrate to Debian unstable after being checked by ftp-masters.
Thanks a lot to the vcmi team, especially Ivan and Warmonger, who helped to make vcmi fit for Debian inclusion. A big thanks also goes to Juan Rada-Vilela, the author of fuzzylite who ported vcmi to use the latest fuzzylite 5.0 release.
Let me also thank the whole vcmi team for creating this amazing engine! You guys rock!
Soon, users of Debian, Ubuntu and their derivatives will be able to âapt-get installâ vcmi - cannot wait
Although I donât like Debian/Ubuntu LTS 2-year release cycles ( -> 2-year old vcmi in repositories) but better than nothing I guess. Feel free to annoy me if you need something else done in terms of packaging/releases.
Lots of Debian/Ubuntu users are using either unstable or testing. Everybody who decides to use stable or LTS will be aware that their software might be very outdated. If you get any complaints that vcmi in Debian stable or Ubuntu LTS is too outdated, please send them to me. In that case, they are clearly using the wrong distribution for their needs and should either start using unstable/testing or install vcmi through the packages/sources that you offer. I see having vcmi in Debian/Ubuntu (and whatever other derivatives) mostly as a convenience. If it is not convenient for somebody (for example because the version in stable/LTS is too old for them) then they can use the existing means to install it. I donât think having vcmi in Debian/Ubuntu and derivatives can have any negative effects for vcmi.
Once vcmi reaches unstable you can have a look at the differences between the Debian version and the upstream version. The only remaining differences are about embedded code copies (I removed minizip and fuzzylite), about binaries without source or license (the osx folder) and the disabled autoupdate of the launcher.
One small thing I wonder about. Is there any downside of adding ââparallelâ into rules by default?
Currently in VCMI repository debian/rules looks like this:
#! /usr/bin/make -f
%:
dh $@
And itâs might looks this way:
#! /usr/bin/make -f
%:
dh $@ --parallel
That would save a bit of pain of those who just want to change code and build deb package with apt-src using DEB_BUILD_OPTIONS=âparallel=Nâ environment variable.
Personally I always use âapt-srcâ way when I just need to patch some software in my system rapidly so think itâs might be nice small improvement for other lazy guys like me. Still worry if this might cause some problem in case like when clang used or in any other rare configuration.
If the build machine has enough ram, then --parallel works perfectly fine.
This is a workaround for the current Debian build infrastructure not allowing a automated way to either select the value of N in DEB_BUILD_OPTIONS=parallel=N or of selecting a build machine with enough ram.
Once one can specify either, the --parallel option will be back in no time.
josch, if youâll be around please let me know what you think about this pull request: github.com/vcmi/vcmi/pull/109
As far as I get Debian would use a bit different build configuration anyway due to additional privacy patches. So I think we can add parallel by default?
