[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: spring packages

On Fri, Oct 23, 2009 at 8:28 PM, Marco Amadori <marco.amadori@gmail.com> wrote:

> Shall I file ITP for mods only or also for maps?

Usually one ITP per source package.

>> Shouldn't AI_DATADIR be set to /usr/share/spring, or is that stuff
>> per-architecture?
> Both Arch dependent and arch indep, I already asked upstream if the can split
> AI more but as now .so, lua and java are mixed.

Ok, that is reasonable I guess.

>> Why the mods/maps split for kernelpanic?
> Because one could just install the mod and use springlobby to download and
> play it on different maps.

Hmm, ok.

>> Why do you override possible-gpl-code-linked-with-openssl?
> It is told on disclaimer on debian/control, for IRC chatting with a former ftp
> master it came clear that if the code does not need any ssl symbol, the
> conflict between openssl and gpl does not apply, even if ldd seems to suggests
> the opposite. (Probably a lintian bug should be open for that).

Hmm. I've often seen people switch to the GNUTLS version of curl to
get transitive GPL compliance.

>> Why is ttf-freefont in the build-deps?
> This is a mistake if we can have in-package dangling links.

I said build-deps, not deps. I thought tff-freefont would only be
needed at runtime, not build time.

>> There are a number of lintian complaints:
>> P: spring source: source-contains-prebuilt-windows-binary
>> installer/nsis_plugins/inetc.dll
>> P: spring source: source-contains-prebuilt-windows-binary
>> installer/nsis_plugins/FindProcDLL.dll
>> P: spring source: source-contains-prebuilt-windows-binary installer/7za.exe
>> P: spring source: source-contains-prebuilt-windows-binary
>>  installer/dos2unix.exe
> Shall I strip them from the sources and create a new stripped .orig.tar.gz ?

Best get upstream to do so and create a new release.

As vincent said, ftp-master will reject it otherwise, due to
sourceless windows binaries:


In any case, pre-built binaries (with or without source) should not be
present in a source tarball.

>>  I: spring: arch-dep-package-has-big-usr-share 3884kB 20%
> Would you like me to create a spring-common package?

I think so, yeah.

>> X: spring: shlib-calls-exit usr/lib/spring/libspringserver.so
>> X: spring: shlib-calls-exit usr/lib/spring/libunitsync.so
> Those 2 libraries are for internal use for spring lobbies and for standalone
> game server; I think I'll have very few possibility to have upstream care of
> these warnings.

Ok, best ignore them then.

> I already sent them the patches in a previous incarnation, not yet the
> manpages.


>> The automated patch to /usr/share/applications/spring.desktop
> Ok, I thought that was debian-specific and not of public interest.

None of the other .desktop files on my system (including those in
app-install) have a shebang, I don't see why upstream sees the need to
add it.

In addition, it isn't a valid .desktop file either:

$ desktop-file-validate ./installer/freedesktop/applications/spring.desktop
./installer/freedesktop/applications/spring.desktop: error: value
"application/x-spring-demo" for string list key "MimeType" in group
"Desktop Entry" does not have a semicolon (';') as trailing character
./installer/freedesktop/applications/spring.desktop: warning: value
"spring.png" for key "Icon" in group "Desktop Entry" is an icon name
with an extension, but there should be no extension as described in
the Icon Theme Specification if the value is not an absolute path
./installer/freedesktop/applications/spring.desktop: warning: value
"Application;Game;StrategyGame;" for key "Categories" in group
"Desktop Entry" contains a deprecated value "Application"

>> Ask them to use pango or quesoglc for font rendering since they select
>> the appropriate set of fonts based on the string being rendered
>> instead of relying on one specific font that may not have all the
>> glyphs for the string. This is good for enabling i18n.
> I 'll try but, I was told they are using plain ascii string and that they
> aren't ready yet for UTF8.

Great, perhaps they can enable i18n and get some translators in a later release.



Reply to: