Bug#462371: new upstream release 0.0.5
Package: opencity Severity: normal Remainder: Opencity 0.0.5.1 is released. ___ Pkg-games-devel mailing list Pkg-games-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel
Processed: Re: Bug#461626: debsums: /var/games/bastet.scores checked, shouldn't be
Processing commands for [EMAIL PROTECTED]: reassign 461626 bastet Bug#461626: debsums: /var/games/bastet.scores checked, shouldn't be Bug reassigned from package `debsums' to `bastet'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) ___ Pkg-games-devel mailing list Pkg-games-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel
Processed: Re: Log for failed build of scorched3d_41.2dfsg-1 (dist=unstable4)
Processing commands for [EMAIL PROTECTED]: found 417691 41.2dfsg-1 Bug#417691: FTBFS with GCC 4.3: missing #includes Bug marked as found in version 41.2dfsg-1 and reopened. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) ___ Pkg-games-devel mailing list Pkg-games-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel
Bug#462379: FTBFS with GCC 4.3: missing #includes
Package: ogre Version: 1.4.5-3 Severity: important Usertags: ftbfs-gcc-4.3 Your package fails to build with GCC 4.3. Version 4.3 has not been released yet but I'm building with a snapshot in order to find errors and give people an advance warning. In GCC 4.3, the C++ header dependencies have been cleaned up. The advantage of this is that programs will compile faster. The downside is that you actually need to directly #include everything you use (but you really should do this anyway, otherwise your program won't work with any compiler other than GCC). There's some more information about this at http://gcc.gnu.org/gcc-4.3/porting_to.html You can reproduce this problem with gcc-4.3 or gcc-snapshot from unstable. Automatic build of ogre_1.4.5-3 on em64t by sbuild/amd64 0.53 ... mkdir .libs x86_64-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../../../OgreMain/include -DYY_NEVER_INTERACTIVE -DYY_NO_UNPUT -I../../../../RenderSystems/GL/include -I../../../../OgreMain/include -I../../../../PlatformManagers/GLX/include -fvisibility=hidden -fvisibility-inlines-hidden -DOGRE_GCC_VISIBILITY -g -O2 -fPIC -MT nvparse.lo -MD -MP -MF .deps/nvparse.Tpo -c nvparse.cpp -fPIC -DPIC -o .libs/nvparse.o nvparse.cpp: In function 'void nvparse(const char*, int, ...)': nvparse.cpp:85: error: 'strdup' was not declared in this scope nvparse.cpp:177: error: 'free' was not declared in this scope make[5]: *** [nvparse.lo] Error 1 make[5]: Leaving directory `/build/tbm/ogre-1.4.5/RenderSystems/GL/src/nvparse' make[4]: *** [all-recursive] Error 1 -- Martin Michlmayr http://www.cyrius.com/ ___ Pkg-games-devel mailing list Pkg-games-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel
Bug#417691: Log for failed build of scorched3d_41.2dfsg-1 (dist=unstable4)
found 417691 41.2dfsg-1 thanks Sorry, since I sent my patch some more headers got cleaned up (but there won't be any further changes). You'll need cstring Automatic build of scorched3d_41.2dfsg-1 on em64t by sbuild/amd64 0.53 ... mv -f .deps/Logger.Tpo .deps/Logger.Po x86_64-linux-gnu-g++ -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE=\scorched3d\ -DVERSION=\41\ -DHAVE_OGG=1 -DHAVE_VSNPRINTF=1 -DHAVE_SNPRINTF=1 -DHAVE_VASPRINTF=1 -DHAVE_ASPRINTF=1 -DHAVE_ICONV=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UNISTD_H=1 -DHAVE_ICONV_H=1 -I. -I../porting -I.. -I/usr/lib/wx/include/gtk2-unicode-release-2.6 -I/usr/include/wx-2.6 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DNO_GCC_PRAGMA -I/usr/include/freetype2 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/X11R6/include -I/usr/X11R6 -I/usr/local/include -g -O2 -DS3D_DOCDIR=\/usr/share/doc/scorched3d\ -DS3D_DATADIR=\/usr/share/games/scorched3d\ -DS3D_BINDIR=\/usr/games\ -MT LoggerI.o -MD -MP -MF .deps/LoggerI.Tpo -c -o LoggerI.o `test -f '../common/LoggerI.cpp' || echo './'`../common/LoggerI.cpp ../common/LoggerI.cpp: In member function 'void LoggerInfo::setTime()': ../common/LoggerI.cpp:41: error: 'strchr' was not declared in this scope make[3]: *** [LoggerI.o] Error 1 make[3]: Leaving directory `/build/tbm/scorched3d-41.2dfsg/src/scorched' -- Martin Michlmayr http://www.cyrius.com/ ___ Pkg-games-devel mailing list Pkg-games-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel
Re: Bug#461626: debsums: /var/games/bastet.scores checked, shouldn't be
reassign 461626 bastet
thanks
On Sun, Jan 20, 2008 at 12:26:53AM +, phil wrote:
debsums detects that /var/games/bastet.scores has changed.
I would have thought that all files in /var/ would be skipped. Certainly
scores
files should be!
Is this a debsums or bastet issue?
A problem with bastet: The package contains an empty file as
/var/games/bastet.scores, and an md5sum for that file.
This is not just a problem for debsums, having the scores file as part
of the package means that on upgrade the scores will be replaced by an
empty file from the new version.
The normal way to handle this is to not include the file in the package,
but to create conditionally in the postinst and remove it in the postrm
on purge. Something like:
postinst:
scores=/var/games/bastet.scores
[ -e $scores ] || { touch $scores; chgrp games $scores; chmod 664 $scores; }
postrm:
if [ $1 = purge ]; then rm -f /var/games/bastet.scores; fi
--bod
___
Pkg-games-devel mailing list
Pkg-games-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel
Bug#462426: FTBFS with GCC 4.3: missing #includes
Package: warzone2100 Version: 2.1.0~0.svn3330-1 Severity: important Usertags: ftbfs-gcc-4.3 Your package fails to build with GCC 4.3. Version 4.3 has not been released yet but I'm building with a snapshot in order to find errors and give people an advance warning. In GCC 4.3, the C++ header dependencies have been cleaned up. The advantage of this is that programs will compile faster. The downside is that you actually need to directly #include everything you use (but you really should do this anyway, otherwise your program won't work with any compiler other than GCC). There's some more information about this at http://gcc.gnu.org/gcc-4.3/porting_to.html You can reproduce this problem with gcc-4.3 or gcc-snapshot from unstable. Automatic build of warzone2100_2.1.0~0.svn3330-1 on em64t by sbuild/amd64 0.53 ... make[1]: Entering directory `/build/tbm/warzone2100-2.1.0~0.svn3330/build_tools' Making all in autorevision make[2]: Entering directory `/build/tbm/warzone2100-2.1.0~0.svn3330/build_tools/autorevision' x86_64-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -g -O2 -MT autorevision.o -MD -MP -MF .deps/autorevision.Tpo -c -o autorevision.o autorevision.cpp autorevision.cpp: In function 'int main(int, char**)': autorevision.cpp:218: error: 'strcmp' was not declared in this scope autorevision.cpp: In member function 'virtual bool RevSVNQuery::extractRevision(RevisionInformation)': autorevision.cpp:365: error: 'strlen' was not declared in this scope autorevision.cpp:371: error: 'strlen' was not declared in this scope autorevision.cpp:375: error: 'strlen' was not declared in this scope autorevision.cpp:381: error: 'strlen' was not declared in this scope autorevision.cpp: In member function 'virtual bool RevFileParse::extractRevision(RevisionInformation)': autorevision.cpp:428: error: 'strlen' was not declared in this scope autorevision.cpp: In member function 'virtual bool RevConfigFile::extractRevision(RevisionInformation)': autorevision.cpp:451: error: 'strlen' was not declared in this scope make[2]: *** [autorevision.o] Error 1 make[2]: Leaving directory `/build/tbm/warzone2100-2.1.0~0.svn3330/build_tools/autorevision' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/build/tbm/warzone2100-2.1.0~0.svn3330/build_tools' make[1]: Entering directory `/build/tbm/warzone2100-2.1.0~0.svn3330/win32' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/build/tbm/warzone2100-2.1.0~0.svn3330/win32' Another problem is that the build doesn't fail even though it fails to compile this file! -- Martin Michlmayr http://www.cyrius.com/ ___ Pkg-games-devel mailing list Pkg-games-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel
Bug#461346: lincity-ng-data: help/en/windmill.xml malformed
Hello, one wish It would be good to split the lincity-ng-data package in two parts * lincity-ng-data with real data = sound, images, fonts ... ~30 MB in tgz * lincity-ng-l10n with help files and translations : data/help/ data/locale/ data/gui/ (yes gui/ is only xml text describing the ui) Together these 3 dir putted in a tgz weight only 800kB This would ease translations upgrade (currently 3 more translations are being done :) and prevent useless bandwidth usage. Cheers. Alain ___ Pkg-games-devel mailing list Pkg-games-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel
Bug#461659: warsow: Clarification for the Warsow Content License
Dear Warsow Team, I wasn't sure who exactly to contact about this so I've decided to contact everybody whose email address was posted in the contact.txt file of the Warsow archive/installer. I and other Debian users would like to create and distribute a package for the new version of Warsow (0.4). Before I get started on the new packages, we have some concerns about the Warsow Content License that we'll need clarification for. The license states Assets that are property of Chasseur de bots, use the following Warsow Content License. Then there are these two clauses. 3. You may not copy, modify, publish, transmit, sell, participate in the transfer or sale or reproduce, create Derivative Works from, distribute, perform, display or in any way exploit any of the Material released under this License unless expressly permitted by the Warsow Team. 4. You may freely distribute the Warsow archive/installer unmodified on any media. You may re-compress using different archival formats suitable for your OS (i.e. zip/tgz/rpm/deb/dmg), any changes beyond that require explicit permission of the Chasseur de bots association. In clause 3 when it's stated, unless expressly permitted by the Warsow Team, did you really mean to say the Warsow Team or Chasseur de bots? I ask this since it's stated that the license applies to Assets that are property of Chasseur de bots. If you did mean to say the Warsow Team, can it be assumed that the members of the Warsow Team are those listed in the Warsow team page http://www.warsow.net/?page=team or is there a different list? In regards to clause 4, a Debian package includes a tarball (orig tarball) that would contain the original source (a tarball named package-name_version.orig.tar.gz). The Warsow archive/installer can be delivered unmodified in the orig tarball, but this would be a problem for the deb package. The deb package contains the files in a manner that is compliant with the Filesystem Hierarchy Standard. So the Warsow content would need to reside in /usr/share/games/warsow-data/. Documentation would be placed in /usr/share/doc/warsow-data/. A Debian package also would add in other documentation that are related with the Debian package or are for Debian users. The changelog.txt file from the Warsow archive/installer is renamed to upstream_changelog.txt so as not to confuse it with changelog.Debian.gz, which is the changelog for the Debian packaging. Also, the changelog files are always compressed using gzip, regardless of its size. Also, the binaries from the Warsow archive/installer are included in a separate package that has the binaries built from the SDK. So the binaries from the Warsow archive/installer are not included in the deb package with the Warsow content. The scripts from the Warsow archive/installer are also not used. Even if they were used, they would need to be modified for use in a Debian system and included in the package with the binaries. Also, in the package with the binaries, some of the documentation from the Warsow archive/installer is included in the package's diff.gz file that contains the makefile script and other files necessary to build a Debian package. This way, the documentation from the Warsow archive/installer can be delivered in both packages. With all this said, there are things that are added to, modified, and deleted from the Warsow archive/installer in order to create packages for Debian. Most of the modifications I've listed are meant as a way to create and deliver a Debian package. Some others are for purposes of complying with Debian policy. What I'm generally asking in regards to this is, can it be acceptable to build and deliver Debian packages without having to leave the Warsow archive/installer unmodified? There is also some other things I want clarification for. I'm assuming that the Warsow archive/installer is the warsow_0.4_unified.zip file. Am I correct? Also, I'm assuming that when it's stated that the Warsow Content License is applied to all art/models/music/texts/names/setting/... present in the game, that this means art/models/music/texts/names/setting/... that would appear only while playing the game. Am I correct? If you respond, please email the Debian Games Developers' list at [EMAIL PROTECTED] and also the Bug Tracking System for Bug #461659 at [EMAIL PROTECTED] In your response, please also clarify if the response is the position of Chasseur de bots and/or the Warsow Team. -- Regards, Andres Mejia ___ Pkg-games-devel mailing list Pkg-games-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel
