Posted: 2014-11-05, 07:37 vcmi 0.97 is in Debian NEW
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
Age: 25 Joined: 08 May 2009 Posts: 1438 Location: Ukraine
Posted: 2014-11-09, 14:54
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.
_________________ Send PM if there is something that needs my attention.
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
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.
Joined: 25 Feb 2011 Posts: 544 Location: Russia
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.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum