Bug#947143: RFS: wordpress/5.3.2+dfsg1-0.1 [NMU] [RC] -- weblog manager

[Markus Koschany]

Hello Niels,

Am 23.12.19 um 15:04 schrieb DebBug:

> Anyone to chime in? Craig? Markus?

There is a bit of confusion here, so I try to explain the situation and
how we should proceed. Thank you for filing bug report #947212 to track
the security issues in Wordpress. This will help to answer those
questions raised by Adam. However there was already #946905 that you
could have been used as well.

You have only recently added me to CC, presumably because I have done
some security uploads in the past for Wordpress. I don't know what you
have discussed with Craig and if he wants to review your work and
sponsor it later. Then you actually don't need to open a sponsorship
request on debian-mentors.

Sponsorship requests are either of severity normal or important. Here it
would be ok to use important but the severity is merely an indicator and
it doesn't automatically guarantee that a bug is prioritized. Security
related bugs like #947212/#946905 are either of severity important or
grave.

Version 5.3.2 seems to fix a couple of security vulnerabilities. No CVE
has been assigned yet. This version should be uploaded to unstable.

If you want to fix Wordpress in Buster and Stretch as well, then you
have to go a different route. The security team is responsible for that.
As previously discussed I recommend to base security updates on upstream
releases for specific Wordpress branches.

https://wordpress.org/download/releases/

Buster should be updated to version 5.0.8 and Stretch to 4.7.16. In both
cases you would base your work on the Wordpress packages in Buster and
Stretch. The changes to the debian files should be minimal, you would
merely rebase existing patches and repack the tarball to make it
compliant with the DFSG.

In short:

Version 5.3.2 -> unstable
Did Craig agree with the upload?
If there is simply no response because of the holiday season we could do
a NMU with a delay of 5 to 10 days. I assume you haven't made any major
changes to the package.

After that:
Version 5.0.8 -> buster-security
Version 4.7.16 -> stretch-security

You can already prepare the packages, then we contact the security team
and ask for approval.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#923180: Please sponsor my game bug=923180

[Markus Koschany]

Hi,

Am 11.03.19 um 21:05 schrieb Pedro Pena:
> Hello Markus,
> 
> Very exciting..
> 
> I applied the patches and made the other changes as well.
> However, there are lintian warnings because infinitetux.jar
> is now included in the source files.

[...]

I think I know the reason. You used source format 1.0. Better is to use
format 3.0 (quilt). The changelog version should be 1.1-1 because
infinitetux is a non-native package meaning we append a Debian revision
number to the upstream version. The changelog should also close the ITP
bug. I have already updated the package accordingly.

I forgot to mention that you can even remove the compat file nowadays if
you build-depend on debhelper-compat (= 12) instead of just debhelper.
Less is more. :)

I also added a watch file. See https://wiki.debian.org/debian/watch for
future projects.

Thanks for changing infinitetux-data to .infinitetux. Everything else
looks good, I've just uploaded the package to NEW and imported it to

https://salsa.debian.org/games-team/infinitetux

If you want to improve the package or package a new upstream version,
you can ask for sponsorship on debian-devel-games directly. You don't
have to take the mentors route again. I have granted you access to our
Git repository so you can prepare new updates there.

Thanks for your contribution!

Regards,

Markus








signature.asc
Description: OpenPGP digital signature

Bug#923180: Please sponsor my game bug=923180

[Markus Koschany]

Hello Pedro,

Am 08.03.19 um 02:49 schrieb Pedro Pena:
> Hello Markus,
> 
> I found an online appstream generator that helped me create the appstream 
> file.
> 
> I built the package without any errors. and just uploaded it.
> 
> I installed the package hoping to see the appstream data rendered in 
> the package manager but I guess it only displays info from the
> control file when it isn't an official debian package.
> 
> Please let me know if I'm  missing anything.

I think we are very close now to upload infinitetux. I have attached two
patches. The first one will change the installation directory to
/usr/share/games. The other one will use the --release flag instead of
-source and -target. This prevents an error when using OpenJDK 8 to run
the game.

Please remove the executable bit from all java and resource files. chmod
a-x. Currently the game creates an infinitetux-data directory in the
user's home directory where it saves tiles.dat. This directory should be
hidden and renamed to .infinitetux. You could also consider to follow
the XDG specification.

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Last but not least, please add some VCS links to debian/control and
change the maintainer field to

Debian Games Team 

and add yourself as Uploader.

Uploaders: qbancoffee 

This way it is easier for others to make changes to the package and keep
it in good shape.

Otherwise the rest looks good to me. I will import the next revision
into our Git repository. You can ask for access here:

https://salsa.debian.org/games-team

Cheers,

Markus
From 691369953345d31a88636c2f0f2aabdf0bb126f3 Mon Sep 17 00:00:00 2001
From: Markus Koschany 
Date: Sun, 10 Mar 2019 15:22:56 +0100
Subject: [PATCH 1/2] Install infinitetux.jar into /usr/share/games.

---
 debian/infinitetux.links | 2 +-
 debian/install   | 2 +-
 debian/rules | 5 +++--
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/debian/infinitetux.links b/debian/infinitetux.links
index 7c61489..6a78453 100644
--- a/debian/infinitetux.links
+++ b/debian/infinitetux.links
@@ -1 +1 @@
-/usr/share/infinitetux/infinitetux.jar /usr/games/infinitetux
+/usr/share/games/infinitetux/infinitetux.jar /usr/games/infinitetux
diff --git a/debian/install b/debian/install
index b317498..2f17a48 100644
--- a/debian/install
+++ b/debian/install
@@ -1,4 +1,4 @@
-../infinitetux.jar usr/share/infinitetux
+infinitetux.jar usr/share/games/infinitetux
 infinitetux.appdata.xml usr/share/metainfo
 infinitetux.desktop usr/share/applications
 infinitetux.png usr/share/icons/hicolor/256x256/apps
diff --git a/debian/rules b/debian/rules
index 091190d..7a62756 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,8 +5,9 @@
 override_dh_auto_build:
 	JAVA_HOME=/usr/lib/jvm/default-java
 	jh_build --no-javadoc --javacopts="-source 1.8 -target 1.8" \
-	--main=com.mojang.mario.FullScreenFrameLauncher ../infinitetux.jar src
+	--main=com.mojang.mario.FullScreenFrameLauncher infinitetux.jar src
 
 override_dh_install:
-	jar uf ../infinitetux.jar -C src/main/resources .
+	jar uf infinitetux.jar -C src/main/resources .
 	dh_install
+
-- 
2.20.1

From 824bce75f919d57e0019e3e842074583caaeeecc Mon Sep 17 00:00:00 2001
From: Markus Koschany 
Date: Sun, 10 Mar 2019 15:29:58 +0100
Subject: [PATCH 2/2] Use -release 8 option.

---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 7a62756..90c82a9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,7 +4,7 @@
 
 override_dh_auto_build:
 	JAVA_HOME=/usr/lib/jvm/default-java
-	jh_build --no-javadoc --javacopts="-source 1.8 -target 1.8" \
+	jh_build --no-javadoc --javacopts="--release 8" \
 	--main=com.mojang.mario.FullScreenFrameLauncher infinitetux.jar src
 
 override_dh_install:
-- 
2.20.1



signature.asc
Description: OpenPGP digital signature

Bug#923180: Please sponsor my game bug=923180

[Markus Koschany]

Control: reopen 923180

Am 07.03.19 um 05:24 schrieb Pedro Pena:
[...]
> "Bug #923180 does not belong to this package"
> 
> Is this normal?

Sorry, I got confused. This is your ITP bug.


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922844

It must be closed in debian/changelog, then Lintian won't complain
anymore. You opened two RFS bugs. Let's close 923172 and continue our
discussion in 923180 now.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#923180: Please sponsor my game bug=923180

[Markus Koschany]

Hi,

Am 07.03.19 um 05:24 schrieb Pedro Pena:
> Hello Markus,
> 
> The only thing I have left is figuring out how to create an appstream 
> file and how to integrate it.

There is a quick start guide which is quite helpful.

https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps

Here is an example file for another game in Debian.

https://sources.debian.org/src/cube2-data/1.2-1/cube2-data.appdata.xml/

In short appstream increases the visibility of software in Debian and
other distributions.


 All others things are done however,
> After uploading the source, lintian complains with the following
> error.
> 
> "Bug #923180 does not belong to this package"
> 
> Is this normal?
> 
> Does not having an appstream file pause this process?

This is unrelated. The error can be ignored. The ITP bug belongs to the
WNPP pseudo package and since infinitetux is not in Debian yet, there is
no possible way to reassign it.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#923180: Please sponsor my game bug=923180

[Markus Koschany]

Am 06.03.19 um 03:20 schrieb Pedro Pena:
> Hello Markus,
> Good to hear you finally able to play infinitetux!
> 
> I'll start working on applying your suggestions.
> 
> As far as the OGA -BY license goes,it appears that 
> OpenGameArt does indeed have a specific license.
> 
> I don't see any non commercial wording in it, so is it still o.k.
> to use?
> 
> OpenGameArt has the following in the FAQ page.
> 
> "OGA-BY 3.0 explicitly allows content to be relicensed under CC-BY 3.0.  
> Just change the license to CC-BY 3.0.  No need to get explicit permission
> to do this, as the license already allows it."
> 
> https://opengameart.org/content/oga-by-30-faq
> 
> 
> Should I just re-license the file then?
> 
> Thank you for your help!

Thanks for the link and clarification. Then OGA-BY-3.0 is just a
slightly modified version of CC-BY-3.0. I'm fine with that.

There is at least one -NC license though.

Files: src/main/resources/endscene.gif
Copyright: 2018, Pedro Pena 
License: CC-BY-NC-4.0
Comment: Modified by Pedro Pena link to source provided.
  http://pngimg.com/uploads/linux/linux_PNG43.png


If the source file was already licensed this way, then you can't change
the license to a non-NC one. In this case you have to find another image
or the author might be willing to relicense it to CC-BY-4.0.

Something I forgot to write yesterday. The icon must be renamed to
infinitetux.png if you install it into the hicolor directory. The
resulting jar file should be installed into /usr/share/games/infinitetux
and the link should be in /usr/games not /usr/bin. Debian makes a
distinction between games and normal applications, whether it is useful
is another question, but that's the current policy.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#923180: Please sponsor my game bug=923180

[Markus Koschany]

Hello Pedro,

Am 05.03.19 um 15:14 schrieb Pedro Pena:
> Hello Markus,
> 
> I have been able to remove the majority of the warnings that appear.
> Unfortunately I can not seem to get lintian to show me the same errors
> locally. I have to upload to mentors.debian.net to see the warnings.
> 
> I thought that this might be due to a version difference with lintian
> in  Ubuntu 16.04 so I installed debian 9.8.0 on a virtual machine
> in the hopes that that might makes things a little easier but the results 
> were the same.
> 
> I also have an issue with the deb helper version. When I change to a version
> higher than 10, debuild creates fatal errors.
> dpkg-checkbuilddeps: error: Unmet build dependencies: debhelper (>= 11)
> 
> Is it o.k. to leave it as 10 for now?

You can even use debhelper 12 in Debian unstable. It works for me just
fine. It is recommended to use an up-to-date Debian unstable/sid system
for development because older versions or derivatives like Ubuntu don't
provide all the features you need. Compat level 11 or 12 are not
available in Debian 9.

The package looks much better now and I could play the game for the
first time.

= copyright =

Please note that NC (= non commercial) licenses are not approved and you
must replace the content if you want to include infinitetux in Debian.

Is there really a specific OpenGameArt license? The OGA-BY-3.0 looks
similar to CC-BY-3.0.

= changelog =

The initial changelog should contain just one paragraph.

infinitetux (1.1) unstable; urgency=medium

  * Initial release. (Closes: #923180)

 -- qbancoffee   Thu, 27 Dec 2018 10:31:26 +


You can update the changelog timestamp by running dch -r.

= wrap-and-sort =

There is nice tool called wrap-and-sort in the devscripts package. As
the name implies it tidies your debian directory.

wrap-and-sort -sa

will also remove trailing whitespace (which is currently present in
d/copyright

= control =

The short description should be

Description: 2D platformer game inspired by Infinite Mario
 Here goes the long description.

Currently the long description is incomplete.

You duplicate the Homepage field.

Section should be games not X11.

desktop.file:

[Desktop Entry]
Comment=Infinite Tux.
Terminal=false
Name=Infinite Tux.
Exec=/usr/bin/infinitetux
Type=Application
Icon=/usr/share/doc/infinitetux/icon.png
NoDisplay=false
Categories=Game

The Comment should be different than the Name. I would change it to

[Desktop Entry]
Type=Application
Terminal=false
StartupNotify=false
Categories=Game;ArcadeGame;
Keywords=game;arcade;platform;
Icon=infinitetux
Exec=infinitetux
Name=Infinitetux
Comment=2D platformer game inspired by Infinite Mario

There is no need for absolute paths and you should install the icon into
the hicolor icon directory /usr/share/icons/hicolor/256x256/apps where
it will be detected automatically.

Bonus points if you create an appstream file as upstream too and install
it into /usr/share/metainfo

You can remove all maven.* files and infinitetux.poms because you don't
use Maven to build the package.

There is still one Lintian warning:

manpage-has-bad-whatis-entry

If you want to see all warnings including the experimental ones, then I
suggest to use

info=yes
display-info=yes
display-experimental=yes
pedantic=yes
show-overrides=yes
color=auto
verbose=yes

in ~/.config/lintian/lintianrc

We are getting closer!

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#859567: Bug#859568: Bug#859567: retro-gtk and gnome-games-app

[Markus Koschany]

Hi,

I have uploaded both packages based on your latest commits. It turned
out that the games had not been indexed by tracker yet but now it works.
I suggest to remove the debian/patches directory in gnome-games next
time because it isn't used anyway.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#859567: retro-gtk and gnome-games-app

[Markus Koschany]

Am 05.04.2017 um 22:28 schrieb Jeremy Bicha:
> On Wed, Apr 5, 2017 at 3:44 PM, Markus Koschany <a...@debian.org> wrote:
>> Please improve the package description a little and write one or two
>> additional sentences and explain what libretro is for.
>>
>> I think "retro-gtk is a library to make libretro frontends that use
>> GTK3." doesn't ring a bell for the uninitiated.
> 
> I will see if I can figure out something longer to silence the lintian
> warning. It's not really supposed to ring bells since no one should be
> installing the library directly. It's a library that is only used by
> gnome-games-app and maintained by the same developer.
> 
> The description I used is basically what I was given:
> https://git.gnome.org/browse/retro-gtk/tree/retro-gtk.doap

[...]

Thank you for the update. That's much better. I am fine with pulling
from your Git repository directly but I'm not a member of the pkg-gnome
team, so you need to take care of all the tagging and committing stuff
by yourself.

>> I have successfully installed gnome-games-app but no games show up. What
>> do I need to do to make my *.desktop file based games from Debian main
>> visible in gnome-games-app?
> 
> Are you using Debian GNOME stretch?

Yes

 Do you have the 'gnome'
> metapackage installed?

No. I installed gnome-core eight years ago and never followed the gnome
metapackage. However I did install the gnome metapackage right now,
rebooted the system but it makes no difference.

> Have you disabled tracker?
> 
> For instance, I have the gnome-games metapackage installed so I have
> 17 games that show up in gnome-games-app.

I have installed tracker and tracker-gui on my system and it appears to
be working but still there are no games listed in gnome-games-app. It's
a bit late here, I need to think this over tomorrow.

Markus





signature.asc
Description: OpenPGP digital signature

Bug#859567: retro-gtk and gnome-games-app

[Markus Koschany]

Control: owner -1 !

Hello Jeremy,

I intend to sponsor your packages which looks good and Policy compliant
to me.

Two points:

retro-gtk:

Please improve the package description a little and write one or two
additional sentences and explain what libretro is for.

I think "retro-gtk is a library to make libretro frontends that use
GTK3." doesn't ring a bell for the uninitiated.

I have successfully installed gnome-games-app but no games show up. What
do I need to do to make my *.desktop file based games from Debian main
visible in gnome-games-app?

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#822672: RFS: freecell-solver/4.2.0-0.1 [NMU]

[Markus Koschany]

Control: noowner -1 !

Am 27.04.2016 um 12:44 schrieb Paul Wise:
> On Wed, Apr 27, 2016 at 6:19 PM, Markus Koschany wrote:
> 
>> First of all thank you for updating freecell-solver. Your effort is much
>> appreciated. I intend to sponsor your package and to upload it to the
>> DELAYED/10 queue, should there be no reaction from the maintainer within
>> the next couple of days.
> 
> Please note that the maintainer surfaced in the meantime:
> 
> https://lists.debian.org/msgid-search/87a8kfv59x@errge.nilcons.com
> 

Thanks for the heads-up. Shlomi, I suggest that you coordinate the
upload with Gergely now. Gergely, please see

https://lists.debian.org/debian-mentors/2016/04/msg00600.html

for my comments on the package available at

http://mentors.debian.net/package/freecell-solver

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#822672: RFS: freecell-solver/4.2.0-0.1 [NMU]

[Markus Koschany]

Control: owner -1 !

Am 26.04.2016 um 12:10 schrieb Shlomi Fish:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "freecell-solver"

Hi Shlomi,

First of all thank you for updating freecell-solver. Your effort is much
appreciated. I intend to sponsor your package and to upload it to the
DELAYED/10 queue, should there be no reaction from the maintainer within
the next couple of days.

In general the changes look good to me but there is one serious issue
and a couple of smaller, non-intrusive ones which are already present in
the current package. While we are at it we should fix them.

You can use Lintian to detect them and by creating the lintianrc file in

~/.config/lintian/lintianrc

with the following content:

info=yes
display-info=yes
display-experimental=yes
pedantic=yes
show-overrides=yes
color=auto
verbose=yes

or by looking at this page

http://mentors.debian.net/package/freecell-solver

The serious one is the incomplete copyright file:

The copyright file states that all code is in the public domain. This is
not correct. There are source files with different license headers, e.g

Your own code is licensed under the MIT/Expat license.

board_gen/make_pysol_freecell_board.py (GPL-2+)
patsolve-shlomif/patsolve/ga/mt19937.c (LGPL)


Copyright (c) 2002 Tom Holroyd (Expat/MIT License)

Copyright (C) 2014 insane coder (http://insanecoding.blogspot.com/,
http://asprintf.insanecoding.org/)
+
+Permission to use, copy, modify, and distribute this software for any
+purpose with or without fee is hereby granted, provided that the above
+copyright notice and this permission notice appear in all copies.
+
+THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

Please update debian/copyright accordingly.

Optional: You could transform the file to copyright format 1.0.

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/


Other issues:

Only debian/control.in should be modified because the package uses
DEB_AUTO_UPDATE_DEBIAN_CONTROL from CDBS.

Dependency on debhelper should be debhelper (>= 9). Please remove the
duplicate entry debhelper (>= 7) in debian/control and update
debian/control.in accordingly.

debian/control.in: Please update the Vcs-fields to use Debian's
canonical URLs.

Vcs-Browser:
https://anonscm.debian.org/cgit/collab-maint/freecell-solver.git
Vcs-Git: https://anonscm.debian.org/git/collab-maint/freecell-solver.git

Please install the upstream changelog (NEWS.txt) in debian/rules with

DEB_INSTALL_CHANGELOGS_ALL := NEWS.txt

Since you are upstream for freecell-solver please consider to fix the
following minor issues:

There is a typo in main.c: explictly => explicitly

Please consider to write a man page for freecell-solver-config.

There is a spelling error in fc-solve.6 allows to => allows one to.

You could cryptographically sign your package, so that debian/watch can
verify its integrity.

https://lintian.debian.org/tags/debian-watch-may-check-gpg-signature.html

You might want to run check-all-the-things on your code. It executes
different checkers which may help you to improve freecell-solver.

e.g.

pep8 --ignore W191 . (Improvement suggestions how to style your code
according to pep8)

find -type f -iname '*.sh' -exec checkbashisms {} +

There are multiple *.sh files that don't seem to have a #! interpreter line.

There are more typos which can be found with

codespell --quiet-level=3

$ cppcheck -j1 --quiet -f . | grep -vF 'cppcheck: error: could not find
or open any of the paths given.'
[fc_pro_range_solver.c:429]: (error) Memory leak: binary_output.file
[state.h:32]: (error) Invalid number of character '{' when these macros
are defined: 'COMPACT_STATES'.
[state.h:32]: (error) Invalid number of character '{' when these macros
are defined: 'DEBUG_STATES'.
[state.h:32]: (error) Invalid number of character '{' when these macros
are defined: 'INDIRECT_STACK_STATES'.


Regards,

Markus











signature.asc
Description: OpenPGP digital signature

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Markus Koschany]

Am 20.04.2016 um 11:00 schrieb Ben Finney:
> Ben Finney  writes:
> 
>> I will merge the “common” files into the ‘colossal-cave-adventure’
>> binary package.
> 
> This is now done, and the updated source package is available:
> 
> $ dget -x 
> http://mentors.debian.net/debian/pool/main/p/python-adventure/python-adventure_1.4-1.dsc
> 

Hi Ben,

it looks like nobody has any objections against using the adventure
virtual name.

I think we are almost finished now:

debian/copyright:

"Every package must be accompanied by a verbatim copy of its copyright
information..."

That means the CC-BY-4.0 license must be quoted in full here because it
is not one of the common licenses. (which is a shame in my opinion, but
can't be helped at the moment)

debian/watch: s/version=3/version=4/

Please fix these issues and then I'm going to upload the package.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Markus Koschany]

Am 20.04.2016 um 00:53 schrieb Ben Finney:
> On 19-Apr-2016, Markus Koschany wrote:
>> thanks for your update. There are only a few things left before we can
>> upload the package.
> 
> Thank you for working with me on this.
> 
>> My main concern is the adventure-common binary package because I
>> don't believe that shipping advent.dat with an extra package is very
>> useful at the moment.
> 
> Would you decline to upload on that basis? I appreciate you don't
> think there's a benefit, but is there any appreciable harm from having
> the ‘adventure-common’ package?
> 
>> I think it is cool to have a modern Python3 version but it would be
>> rather boring to have identical versions that simply reuse the same
>> story from advent.dat.
> 
> My thinking is that the Python 3 package is rather idiosyncratic, and
> that I'd like to make it clear the common files are available for
> different ports from the original Fortran program.
> 
> I'm not going to insist, but I'd like to know whether you think this
> structure is harmful, or only that this isn't the style you would
> choose.

I think the word harmful is a bit too strong but I don't think that your
current approach is beneficial either. The rationale for providing
multiple binary packages is that users should be able to install a
subset of an application and save some disk space. In this case they
always have to install both packages because otherwise the game would be
broken. It would be a different case if they already had a choice and
could choose between different variants.

Games often provide a significant amount of data and media files and
then it really makes sense to split off the data into some arch:all
-data or -common package when the architecture dependent data is small
compared to the arch-indep part. It would have been extremely wasteful,
if I hadn't done that for freeorion. (C++ game, -data package ~150 MB)
but in your case the game is already arch:all instead of arch:any and
adventure-common is even smaller than colossal-cave-adventure. So
another variable must be taken into account: metadata. Every binary
package in Debian's archive produces metadata and _every_ user has to
fetch this information, for instance with apt when doing a daily update.
In your case the performance penalty (even when it's rather small) is
greater than the advantage of having a separate -common package which
could be reused for a potential and not yet packaged adventure variant.

And last but not least the ftp team once rejected an extra -doc package
for the game njam because it was very small and insisted to merge it
into the -data package. The funny part is that my sponsor back then
thought it was a good idea, so the situation was kind of reversed.

I wouldn't decline to upload but you should take this wall of text into
consideration. In my opinion you can always split the package later when
a potential port might require it.

[...]
>> and that we use cgit for better performance.
> 
> Recently, the default browser on Alioth was switched to Cgit. So,
> at <URL:https://anonscm.debian.org/git/collab-maint/dput.git> the Cgit
> browser is presented.

Indeed they redirect all requests now. I don't know if that comes with a
performance penalty though. I wonder why we need two fields, Vcs-Browser
and Vcs-Git, if they are identical...

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#821260: RFS: python-adventure/1.4-1 [ITP], Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Markus Koschany]

Hello Ben,

thanks for your update. There are only a few things left before we can
upload the package. My main concern is the adventure-common binary
package because I don't believe that shipping advent.dat with an extra
package is very useful at the moment. As a compromise I offer you help
in resolving future issues with possibly other adventure variants in
Debian. However I expect that they will a) just ship the file with their
own package and b) it is rather unlikely that we will see another
implementation of the original adventure game in Debian. I think it is
cool to have a modern Python3 version but it would be rather boring to
have identical versions that simply reuse the same story from advent.dat.

Please fix

colossal-cave-adventure.desktop: (found with desktop-file-validate)

colossal-cave-adventure.desktop: error: (will be fatal in the future):
value "colossal-cave-adventure.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

Please change the Vcs fields from:

Vcs-Git:
https://anonscm.debian.org/git/collab-maint/pkg-python-adventure.git

Vcs-Browser:
https://anonscm.debian.org/git/collab-maint/pkg-python-adventure.git

to

Vcs-Git: https://anonscm.debian.org/git/collab-maint/python-adventure.git
Vcs-Browser:
https://anonscm.debian.org/cgit/collab-maint/python-adventure.git

so that the name of the git repository is identical to the source
package name and that we use cgit for better performance. Please push
the package to collab-maint next time and I will work and upload from there.

Last but not least:

There is a authoritative list of virtual package names (yeah,
bureaucracy in Debian is wonderful)

https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt

Please follow the procedure outlined in this text file and post to
debian-devel and CC this RFS bug report. Personally I have no objections
against using the adventure name but it is polite to inform fellow DDs too.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Markus Koschany]

Am 18.04.2016 um 02:15 schrieb Ben Finney:
[...]
>> I found the following things with check-all-the-things:
>>
>> colossal-cave-adventure.desktop: found with desktop-file-validate
>> error: value "adventure;advent;colossal;cave;spelunk" for locale string
>> list key "Keywords" in group "Desktop Entry" does not have a semicolon
>> (';') as trailing character
> 
> Thank you. I formed that field just by copying others. Is there a
> specification for that field that I've missed?

Sorry I've missed this paragraph. The fix is simple just add a semicolon
after spelunk. desktop-file-validate is a useful tool to ensure
compliance with the freedesktop specification. The written text can be
found at

https://specifications.freedesktop.org/menu-spec/latest/

Another suggestion: The recommended location for hicolor icons is
/usr/share/icons/hicolor. If you resize your icons to 256x256 you could
install them to /usr/share/icons/hicolor/256x256/apps and replace the
absolute icon path in your desktop file with the icon name.

Markus




signature.asc
Description: OpenPGP digital signature

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Markus Koschany]

Am 18.04.2016 um 02:15 schrieb Ben Finney:
> Markus Koschany <a...@debian.org> writes:
> 
>> I had a look at your package and wanted to give you some feedback
>> because of the effort you put into packaging this game.
> 
> Thank you! Are you a prospective sponsor of this package?

Yes, I would sponsor the package if we can resolve the remaining issues.

>> The vim comments at the bottom are not allowed (syntax-wise)
> 
> Those are in end-line comments (“# foo”). My understanding is that
> end-line comments with that syntax are permitted in any Debian control
> files.

cme check dpkg made me aware of this and it probably refers to:

https://www.debian.org/doc/debian-policy/ch-controlfields#s-controlsyntax

"Lines starting with # without any preceding whitespace are comments
lines that are only permitted in source package control files
(debian/control). These comment lines are ignored, even between two
continuation lines. They do not end logical lines."

The file syntax of copyright format 1.0 files is the same as for other
control files.

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#file-syntax


>> CC-BY-2.0 is not a DFSG-free license, if possible better use CC-BY-3.0
>> or CC-BY-4.0
> 
> Thanks. The package includes works I have derived from upstream works
> licensed under CC By-2.0.
> 
> My understanding of the problems with CC licenses version 2.0 is in the
> potential for some licensors to set impractical restrictions on
> attribution. That is not the case for any of these specific works, so I
> think they are DFSG-free currently.
> 
> To avoid such problems arising for the derived works, I will set the
> license to CC By-4.0 in those derived works as distributed in Debian.

CC-BY-4.0 is a good choice and would help to avoid any confusion. I
agree with you that CC-BY-2.0 is debatable but I'd rather prefer not to
open a can of worms here. On the following site are a few links of older
discussion:

https://wiki.debian.org/DFSGLicenses


>> You have patched the upstream sources (12 patches). In general the
>> patches look O.K but I wonder if they are all necessary. Did you
>> forward them upstream? Why do you think Debian should diverge from
>> upstream?
> 
> Those patches turn the work into a useable stand-alone program for
> Debian. Each one is submitted upstream, and I'm corresponding with the
> upstream maintainer to get these changes incorporated.

Fair enough.

>> You split the game into three arch:all binary packages. I'm not
>> totally convinced that this is really necessary for a game like
>> python-adventure. Your current approach is not totally wrong either,
>> perhaps a bit too perfectionist though. Are there strong reasons why
>> you split the game into three parts?
> 
> I would think rather that conforming to Debian policy would be the
> default, and a divergence would need a strong reason.

I'm not so sure about your last sentence since the Policy doesn't
dictate this particular packaging scheme IMO but I'd stand corrected if
you could point me to the relevant Policy part. Bas Wijnen has already
voiced some of my concerns in his previous e-mail.

In my opinion we should also take practical reasons into account and
creating three arch:all packages for such a trivial game comes with a
lot of overhead. For example adventure-common just ships the 50kb small
advent.dat file. Sometimes I need to package annotations or libraries
that can be equally small in seize but in those cases there is always a
concrete package in need of those dependencies. Here there only could be
a potential consumer in the future, which is also rather unlikely, but I
can't imagine that the trade off between meta data and maintenance costs
and saving 50 kb is really worth it. I recommend to merge advent.dat
into colossal-cave-adventure and be done with it.

I can live with the python3-adventure split off but as Bas already said
I also find it unlikely that another program will ever make use of it.

>> Why don't you join the Python or Games Team and maintain
>> python-adventure within one of these teams?
> 
> No particular reason. I am enjoying maintaining the code as it is.

Ok. The keyword is maintaining. In general I don't find it important
where people actually maintain software as long if they keep it updated
and in good shape. Still I would encourage you to join a team because it
often simplifies regular tasks like finding a sponsor.

Could you remove those ^L form feed characters please?

Regards,

Markus





signature.asc
Description: OpenPGP digital signature

Bug#821260: RFS: python-adventure/1.4-1 [ITP]

[Markus Koschany]

Am 17.04.2016 um 05:58 schrieb Ben Finney:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Howdy,
> 
> I am looking for a sponsor for my package ‘python-adventure’.

Hi Ben,

I had a look at your package and wanted to give you some feedback
because of the effort you put into packaging this game.

debian/copyright:

The vim comments at the bottom are not allowed (syntax-wise)
CC-BY-2.0 is not a DFSG-free license, if possible better use CC-BY-3.0
or CC-BY-4.0

There are a lot of form feed characters (^L) in various debian files
which I would remove.

You have patched the upstream sources (12 patches). In general the
patches look O.K but I wonder if they are all necessary. Did you forward
them upstream? Why do you think Debian should diverge from upstream?

You split the game into three arch:all binary packages. I'm not totally
convinced that this is really necessary for a game like
python-adventure. Your current approach is not totally wrong either,
perhaps a bit too perfectionist though. Are there strong reasons why you
split the game into three parts?

Why don't you join the Python or Games Team and maintain
python-adventure within one of these teams?

I found the following things with check-all-the-things:

colossal-cave-adventure.desktop: found with desktop-file-validate
error: value "adventure;advent;colossal;cave;spelunk" for locale string
list key "Keywords" in group "Desktop Entry" does not have a semicolon
(';') as trailing character

codespell --quiet-level=3
./adventure/advent.dat:996: KNIVE  ==> KNIFE
./adventure/advent.dat:1462: THRU  ==> THROUGH

Might be intentional since it's the original game dialogue.

pep8 --ignore W191 . found something that could be improved. Nothing
critical but it could be forwarded upstream.

pyflakes3 .
./adventure/__main__.py:10: 'readline' imported but unused

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#807099: RFS: corsix-th/0.50-1 ITP 610087 - A Theme Hospital engine reimplementation.

[Markus Koschany]

Am 27.12.2015 um 09:35 schrieb Alexandre Detiste:
> Le samedi 26 décembre 2015, 22:46:05 Markus Koschany a écrit :
>> The package looks good to me. Please add the missing license of tinyxml
>> to debian/copyright. 
> 
> Done

Uploaded. Thanks for your contribution.

Markus




signature.asc
Description: OpenPGP digital signature

Bug#807099: marked as done (RFS: corsix-th/0.50-1 ITP 610087 - A Theme Hospital engine reimplementation.)

[Markus Koschany]

Control: reopen -1

The package will close this bug report automatically when it enters the
archive. Please keep this bug report open until until corsix-th got
accepted.

Thanks,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#807099: RFS: corsix-th/0.50-1 ITP 610087 - A Theme Hospital engine reimplementation.

[Markus Koschany]

Am 26.12.2015 um 10:30 schrieb Alexandre Detiste:
> Hi,
> 
> I spent some time merging your advices & Simon's ones [1]
> in a way that don't trigger new lintian false positives.

The package looks good to me. Please add the missing license of tinyxml
to debian/copyright. After that I will upload the package.

Cheers,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#807099: RFS: corsix-th/0.50-1 ITP 610087 - A Theme Hospital engine reimplementation.

[Markus Koschany]

Am 11.12.2015 um 12:35 schrieb Alexandre Detiste:
> Le dimanche 6 décembre 2015, 20:34:42 Markus Koschany a écrit :
>> Several Expat copyright holder are missing in
>> CorsixTH/Lua/languages
>> CorsixTH/Src/jit_opt.h
>> SpriteEncoder/*
>> LevelEdit/*
>>
>> GPL-3+
>> SpriteEncoder/parser.cpp
>> SpriteEncoder/tokens.h
> 
> This license has this special exception; does this mean
> it can be considered Expat-licensed as the whole game ?
> 
>As a special exception, you may create a larger work that contains
>part or all of the Bison parser skeleton and distribute that work
>under terms of your choice

I would add the following paragraph to debian/copyright to avoid any
confusion.

License: GPL-3+-with-exception
 On Debian systems, the complete text of the GNU General Public License
 version 3 can be found in `/usr/share/common-licenses/GPL-3'.
 .
 As a special exception, you may create a larger work that contains
 part or all of the Bison parser skeleton and distribute that work
 under terms of your choice, so long as that work isn't itself a
 parser generator using the skeleton or a modified version thereof
 as a parser skeleton.  Alternatively, if you modify or redistribute
 the parser skeleton itself, you may (at your option) remove this
 special exception, which will cause the skeleton and the resulting
 Bison output files to be licensed under the GNU General Public
 License without this special exception.

Bonus points if these files are generated automatically during the build.

Markus




signature.asc
Description: OpenPGP digital signature

Bug#807099: RFS: corsix-th/0.50-1 ITP 610087 - A Theme Hospital engine reimplementation.

[Markus Koschany]

Control: owner -1 !

Am 05.12.2015 um 11:55 schrieb Alexandre Detiste:
> Package: sponsorship-requests
> Severity: wishlist
> 
>   Dear mentors,
> 
>   I am looking for a sponsor for my package "corsix-th":

Hi Alexandre,

here is my initial review. I am working with the pkg-games Git
repository of corsix-th and I suggest we continue to use it instead of
the mentors.debian.net packages.

debian/control:

You build-depend on wx2.8-headers but this package is obsolete and will
be removed soon. Please either use wx3.0-headers instead or remove the
build-dependency because I don't see anything in the sources that may
need it.

Why do you depend on lua-filesystem and lua-lpeg explicitly? If those
dependencies are really required, the ${shlibs:Depends} substvar should
include them already. Otherwise the build system should be updated to
require and incorporate those libraries.

desktop file: I have already fixed a few things that bothered me. I
believe it's a simulation game and StartupNotify should be set to false.
I also added keywords and a comment in German. Please tell me if you can
live with the changes or if there is a reason to stick with the old
values. Please forward the new desktop file upstream.

Please use Debian's system library of tinyxml. The embedded copy of
tinyxml in AnimView/ is neither mentioned in upstream's LICENSE.txt file
nor in debian/copyright. Please ask upstream to remove the embedded copy
or to offer a build system option to use the system library instead.
They should also mention the copyright holders and license in
LICENSE.txt. You can take a look at my Bullet package how I used
Debian's tinyxml library.

There are several issues with debian/copyright:
Some copyright holders and licenses are missing.


BSD-3-clause
CMake/CMakeFFmpegLibavMacros.cmake
CMake/FindFFmpeg.cmake
CMake/FindLibAV.cmake
CMake/FindSDL2.cmake
CMake/FindSDL2_mixer.cmake

public-domain
CMake/FindDirectX.cmake
CMake/FindLua.cmake
CMake/FindPkgMacros.cmake

Several Expat copyright holder are missing in
CorsixTH/Lua/languages
CorsixTH/Src/jit_opt.h
SpriteEncoder/*
LevelEdit/*

GPL-3+
SpriteEncoder/parser.cpp
SpriteEncoder/tokens.h

zlib:
WindowsInstaller/ReplaceInFile.nsh

Why don't you build the level editor? Wouldn't this be a useful addition
to the game?

Lintian error:  source-contains-unsafe-symlink

I think it is safe to override this error and since upstream already
removed the debian directory from Git master it will be fixed with the
next release of corsix-th. Another option might be to remove the
directory for the current version and to append +ds to the upstream version.

Forwarding the Lua patch upstream is a good idea.

I would change usr/lib/games/corsix-th/CorsixTH to
/usr/lib/corsix-th/CorsixTH. We still use /usr/games and
/usr/share/games for historical reasons but I think it is OK to omit the
games subdirectory here.

debian/scripts/corsix-th

Please use the exec command. It replaces the current process without
forking a new process.

That's it for now.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#807099: RFS: corsix-th/0.50-1 ITP 610087 - A Theme Hospital engine reimplementation.

[Markus Koschany]

Am 06.12.2015 um 21:13 schrieb Alexandre Detiste:
> Le dimanche 6 décembre 2015, 20:34:42 Markus Koschany a écrit :
[...]
>> You build-depend on wx2.8-headers but this package is obsolete and will
>> be removed soon. Please either use wx3.0-headers instead or remove the
>> build-dependency because I don't see anything in the sources that may
>> need it.
> 
> find . -type f -exec grep ^#include {} \; | grep wx | sort -u
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> ...
> 
> It's used in MapEdit/ (currently disabled) and AnimView/
> I need to check if this second direcotry is a depedency of MapEdit only or
> if it is used somewhere else.

I have just rebuilt the package without the B-D on wx2.8-headers and it
still works.

>> Why do you depend on lua-filesystem and lua-lpeg explicitly? If those
>> dependencies are really required, the ${shlibs:Depends} substvar should
>> include them already. Otherwise the build system should be updated to
>> require and incorporate those libraries.
> 
> Because they are only needed at runtime...
> does they really need to get pulled in the build chroot for nothing ?
> I guess it's cleaner that way.

No, if they are only needed at runtime, so be it.

>> desktop file: I have already fixed a few things that bothered me. I
>> believe it's a simulation game and StartupNotify should be set to false.
>> I also added keywords and a comment in German. Please tell me if you can
>> live with the changes or if there is a reason to stick with the old
>> values. Please forward the new desktop file upstream.
> 
> Upstream doesn't ship a .png icon either and had removed
> the non-maintained DebianPackager... 
> 
> It's not the kind of thing I really want to bother an upstream with; 
> ut rather more usefull things, like having appropriate configure
> scripts to avoid the need to patch the build system.

I saw that they provided a desktop file within the DebianPackager
directory. desktop files should definitely be provided with the upstream
sources because they are not Debian specific. Other distributions would
also benefit from this change.

> 
>> Please use Debian's system library of tinyxml. The embedded copy of
>> tinyxml in AnimView/ is neither mentioned in upstream's LICENSE.txt file
>> nor in debian/copyright.
> 
> As stated for WX, I need to check if AnimView is needed.
> 
>> Please ask upstream to remove the embedded copy
> That's downstream work.

No, it is not. Please point them to
https://wiki.debian.org/UpstreamGuide#No_inclusion_of_third_party_code

Markus



signature.asc
Description: OpenPGP digital signature

Re: [jitsi-dev] Jitsi in Debian

[Markus Koschany]

Am 18.10.2015 um 22:38 schrieb Wookey:
> +++ Damian Minkov [2015-10-18 14:17 -0500]:
[...]
>> I'm aware of the downloading while building problem, but you mean
>> there is no way to reuse maven stuff while packaging, as the list of
>> dependencies is maybe 30-40 libraries?
> 
> Maven and Debian policy go together very badly. If the project doesn't
> already use maven then _please_ don't change to it. It's terrible for
> security and reproducibility. Nothing about getting the project
> packaged would be helped by such a change - in fact it would be a
> major hindrance.

Hi,

just wanted to chime in here as a member of the Debian Java team.
Actually nowadays Maven and Debian go perfectly well together as we
prevent Maven from downloading anything during the build process. Of
course this requires that all your artifacts must be packaged for Debian
already. Then Maven will just find them in /usr/share/maven-repo.

So it doesn't really matter if you prefer Ant or Maven as build system.
Both are equally well supported. What matters is that the build system
is supported upstream and all necessary dependencies are packaged for
Debian.

Please feel free to ask Java specific questions on debian-java or to
join the team. We gladly help you to solve those packaging questions.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#797888: Membership application [was RFS: panda3d/1.9.0-1]

[Markus Koschany]

Am 04.09.2015 um 16:44 schrieb Jörn Schönyan:
[...]
> 
> 5) I did apply for membership something like a week ago, but nothing
> hapenned yet. But I really think working together with the pkg-games
> team would be beneficial.

Hi Jörn,

I cc our mailing list, someone there should be able to accept your
application and grant you access to the pkg-games group, so that you can
create your own Git repository for panda3d. Please subscribe to
debian-devel-games and feel free to ask further questions on the list.
We also have an IRC channel #debian-games on irc.debian.org.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Re: Help with Java package needed

[Markus Koschany]

On 27.04.2015 12:42, Andreas Tille wrote:
[...]
 So for whatever reason zeus-jscl is not found. :-(
 
 Any further hint?

Hi Andreas,

I think that's because the manifest file of mauve still references the
embedded upstream jar in the ext directory. Since you use javahelper,
you can create a mauve.manifest or mauve.classpath file and override
this behaviour by pointing to /usr/share/java/zeus-jscl.jar. That should
do the trick. You can also use your preferred text editor and open
/usr/share/java/Mauve.jar and modify the MANIFEST file by hand to test
if it works.

Please note that my patch was incomplete. Although it makes the package
compile, there are some pieces missing. If the console doesn't work it's
because of that.

Regards,

Markus






signature.asc
Description: OpenPGP digital signature

Re: Help with Java package needed

[Markus Koschany]

On 27.04.2015 13:30, Andreas Tille wrote:
 Hi Markus,
 
 On Mon, Apr 27, 2015 at 12:59:03PM +0200, Markus Koschany wrote:

 I think that's because the manifest file of mauve still references the
 embedded upstream jar in the ext directory. Since you use javahelper,
 you can create a mauve.manifest or mauve.classpath file and override
 this behaviour by pointing to /usr/share/java/zeus-jscl.jar. That should
 do the trick. You can also use your preferred text editor and open
 /usr/share/java/Mauve.jar and modify the MANIFEST file by hand to test
 if it works.
 
 Hmmm, I admit I forgot to activate the patch I did for other Debian
 packaged JARs in upstream .classpath file.  I did so now in Git but this
 does not change the situation.  The strange thing is that if I look into
 the MANIFEST file as you advised only the ext/* JARs are mentioned there
 but the Debian packaged are missing.  What is the difference between
 using a patched .classpath from upstream and  a mauve.manifest or
 mauve.classpath file.  What is the recommended way for creating Java
 packages.  Can I leave upstream .classpath untouched if I provide
 debian/mauve.classpath?

In the end you have to replace all embedded jar files. At the moment Ant
constructs the classpath based on the information in your build.xml
file. Mauve will successfully find zeus-jscl.jar if you append
/usr/share/java/zeus-jscl.jar to the classpath line in mauve's MANIFEST
file by hand. I remember that I did that too and I could start the
application.

Javahelper provides two helpers jh_classpath and jh_manifest. The first
one is probably easier to use if you only want to modify the classpath.
You can find more information in /usr/share/doc/javahelper/tutorial.txt.gz

Both helpers are useful because by using them you can avoid patching
upstream's MANIFEST file.

I suggest that you take a look at my package mediathekview which is very
similar to yours because both use javahelper and Ant.

https://anonscm.debian.org/cgit/collab-maint/mediathekview.git

I use jh_manifest (the mediathekview.manifest file) and a wrapper script
to start the application. You can either use jarwrapper or java-wrapper
for this purpose. In this case I use the latter.

The wrapper itself is very concise.

https://anonscm.debian.org/cgit/collab-maint/mediathekview.git/tree/debian/bin/mediathekview

mediathekview.manifest looks like that

usr/share/mediathekview/MediathekView.jar:
 Class-Path: /usr/share/java/commons-lang3.jar
/usr/share/java/commons-compress.jar /usr/share/java/swingx.jar
/usr/share/java/forms.jar /usr/share/java/mac_widgets.jar
/usr/share/java/jide-oss.jar /usr/share/java/xz.jar
/usr/share/java/jackson-core.jar /usr/share/java/TimingFramework.jar
/usr/share/java/jchart2d.jar
 Main-Class: mediathek.Main

You just jave to change the path to /usr/share/java/Mauve.jar, then put
all libraries on the Class-Path line and provide the Main-Class. (The
information can be found in upstream's MANIFEST file.

That's it.


 Please note that my patch was incomplete. Although it makes the package
 compile, there are some pieces missing. If the console doesn't work it's
 because of that.
 
 I'll most probably come back to ask for further hints once I've at least
 git the zeus-jscl.jar found. :-)
 

Ok. Good luck. :)

Markus




signature.asc
Description: OpenPGP digital signature

Re: Help with Java package needed

[Markus Koschany]

Hi,

On 26.04.2015 07:20, Andreas Tille wrote:
 Hi,
 
 I intent to package mauve[1] and prepared the package in Git[2].  I was
 able to get rid of several JARs upstream included but it seems now it
 starts to become tricky enough that I need some help.
 
 The Mauve download contains ext/zeus-jscl.jar.  The source of this is
 available here[3] and I think I was able to create a proper package of
 this in pkg-java Git[4].
 
 However, if I try to build Mauve which was working before changing the
 location of zaus-jscl.jar in build.xml I get:
 
 
 compile:
 [mkdir] Created dir: 
 /home/andreas/debian-maintain/repack/mauve/mauve-2.4.0+4734/bin
 [javac] 
 /home/andreas/debian-maintain/repack/mauve/mauve-2.4.0+4734/build.xml:96: 
 warning: 'includeantruntime' was not set, defaulting to 
 build.sysclasspath=last; set to false for repeatable builds
 [javac] Compiling 202 source files to 
 /home/andreas/debian-maintain/repack/mauve/mauve-2.4.0+4734/bin
 [javac] 
 /home/andreas/debian-maintain/repack/mauve/mauve-2.4.0+4734/src/org/gel/mauve/MyConsole.java:17:
  error: incompatible types
 [javac] console = JConsole.getConsole ();
 [javac]   ^
 [javac]   required: JConsole
 [javac]   found:JConsolePane
 [javac] 
 /home/andreas/debian-maintain/repack/mauve/mauve-2.4.0+4734/src/org/gel/mauve/MyConsole.java:22:
  error: cannot find symbol
 [javac] console.startConsole ();
 [javac]^

This is an upstream bug because mauve's code is incompatible with the
latest version of zeus-jscl and the code was split into JConsole.java
and JConsolePane.java years ago. I'm attaching a patch which at least
allows mauve to compile but there is still something wrong and the
console window shows only for a second on startup but nothing happens
when I click on the menu entry.

The problem is that in src/org/gel/mauve/MyConsole.java and in
src/org/gel/mauve/gui/MauveFrame.java the console variable is of type
JConsole but it should be JConsolePane. I would file an upstream bug
report for this.

Regards,

Markus
From: Markus Koschany a...@gambaru.de
Date: Sun, 26 Apr 2015 15:22:19 +0200
Subject: MyConsole

---
 src/org/gel/mauve/MyConsole.java  | 16 +---
 src/org/gel/mauve/gui/MauveFrame.java |  3 +--
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/src/org/gel/mauve/MyConsole.java b/src/org/gel/mauve/MyConsole.java
index 1781510..d9e7c3a 100644
--- a/src/org/gel/mauve/MyConsole.java
+++ b/src/org/gel/mauve/MyConsole.java
@@ -10,18 +10,20 @@ import java.io.PrintStream;
 public class MyConsole {
 	private static boolean useSwing = false;
 
-	private static JConsole console;
+	private static JConsole console = new JConsole();
 
 	public static void setUseSwing (boolean b) {
 		if (b  !useSwing) {
-			console = JConsole.getConsole ();
 			console.setTitle (Mauve Console);
 			console.setSize (400, 400);
 			Dimension dim = Toolkit.getDefaultToolkit().getScreenSize();
 			console.setLocation(dim.width-400, 0);
-			console.startConsole ();
+			JConsole.getConsole().startConsole ();
+			if (!console.isVisible()) {
+console.setVisible(true);
+			}
 		} else if (!b  useSwing) {
-			console.stopConsole ();
+			JConsole.getConsole().stopConsole ();
 			console = null;
 		}
 
@@ -30,13 +32,13 @@ public class MyConsole {
 
 	public static void showConsole () {
 		if (useSwing) {
-			console.showConsole ();
+			JConsole.getConsole().showConsole ();
 		}
 	}
 
 	public static PrintStream err () {
 		if (useSwing) {
-			console.showConsole ();
+			JConsole.getConsole().showConsole ();
 		}
 		return System.err;
 	}
@@ -44,4 +46,4 @@ public class MyConsole {
 	public static PrintStream out () {
 		return System.out;
 	}
-}
\ No newline at end of file
+}
diff --git a/src/org/gel/mauve/gui/MauveFrame.java b/src/org/gel/mauve/gui/MauveFrame.java
index eda9460..e82111e 100644
--- a/src/org/gel/mauve/gui/MauveFrame.java
+++ b/src/org/gel/mauve/gui/MauveFrame.java
@@ -497,8 +497,7 @@ public class MauveFrame extends JFrame implements ActionListener, ModelProgressL
 }
 if (source == jMenuHelpConsole || ae.getActionCommand().equals(Console))
 {
-	JConsole console = JConsole.getConsole();
-	console.showConsole();
+	JConsole.getConsole().showConsole();
 }
 if (source == jMenuHelpClearCache || ae.getActionCommand().equals(ClearCache))
 {


signature.asc
Description: OpenPGP digital signature

Re: Package creation - help needed !

[Markus Koschany]

On 10.04.2015 10:44, François BILLIOUD wrote:
 Trying here, but it's a lot of information to assimilate.
 
 First, I see that there are thousands of ways to do it. It is a Java
 program that uses Maven. The source is stored on GitHub. 

[...]

Hello,

There are three common solutions for building maven based packages.
First of all if your software is only targeted for private and local use
and it is not your intention to package it for Debian officially, then I
recommend to get used to jdeb [1] which simplifies the packaging process
and is easier to use for beginners.

If you want to get serious either maven-debian-helper [2] with CDBS or
javahelper [3] with maven-repo-helper [4] and DH (debhelper with dh
sequencer) are your best options.

maven-debian-helper Mini HowTo
==

1. git clone https://github.com/Sharcoux/MathEOS.git
2. cd MathEOS
3. mh_make

The mh_make command is included in maven-debian-helper. Just answer all
the questions and use lower case for the source and library package
names. Ignore all missing dependencies by pressing y. After that you
will find the auto-generated output in your debian directory. That is
all you need for getting started with packaging. Next step is to take a
look at maven.ignoreRules.

com.itextpdf itextpdf * * * *
net.sourceforge.jeuclid jeuclid-core16 * * * *
net.sourceforge.jeuclid jeuclid-core * * * *
net.sourceforge.jeuclid jeuclid * * * *
org.apache.maven.plugins maven-assembly-plugin * * * *
org.docx4j docx4j-ImportXHTML * * * *
org.imgscalr imgscalr-lib * * * *
svg salamander * * * *


These are all artifacts which were ignored in the initial package
creation step. I know we provide the salamander, jeuclid and itext
libraries, so these are most likely false positives and the only thing
left to do is to tell maven where it can find Debian's system jar files.
You can ignore maven-assemply-plugin because in most cases it is not
required for Debian packaging. docx4j and imgscalr are new dependencies
which should be packaged separately.

As Paul already wrote, if you have more questions please join us on
debian-j...@lists.debian.org.

Regards,

Markus


[1] https://packages.qa.debian.org/j/jdeb.html
[2] https://packages.debian.org/sid/maven-debian-helper
[3] https://packages.qa.debian.org/j/javatools.html
[4] https://packages.qa.debian.org/m/maven-repo-helper.html



signature.asc
Description: OpenPGP digital signature

Bug#772696: RFS: transmission/2.84-0.2 [RC]

[Markus Koschany]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package transmission which fixes RC
bug http://bugs.debian.org/718624, related bug #734467 and merged bugs.

 * Package name: transmission
   Version : 2.84-0.2
   Section : net

It builds those binary packages:

transmission - lightweight BitTorrent client
transmission-cli - lightweight BitTorrent client (command line programs)
transmission-common - lightweight BitTorrent client (common files)
transmission-daemon - lightweight BitTorrent client (daemon)
transmission-dbg - lightweight BitTorrent client (debug symbols)
transmission-gtk - lightweight BitTorrent client (GTK+ interface)
transmission-qt - lightweight BitTorrent client (Qt interface)

To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/transmission


Alternatively, one can download the package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/t/transmission/transmission_2.84-0.2.dsc

Changes since the last upload:

* Non-maintainer upload.
* transmission-daemon.postinst:
  - Change home directory of transmission-daemon to
/var/lib/transmission-daemon from /home/debian-transmission.
Thanks to Alex Peters for the report. (Closes: #734467)
  - Disable password authentication for debian-transmission user for
improved security. Logins with e.g. SSH RSA keys are still possible.
  - Check existence of debian-transmission user with getent passwd
debian-transmission instead of id.
* Add transmission-daemon.preinst:
  - Fix permissions in /var/lib/transmission-daemon and use
/var/lib/transmission-daemon as the new home directory.
  - Move old configuration files to appropriate config directory
/var/lib/transmission-daemon/.config/transmission-daemon.
All together this ensures that transmission-daemon will not segfault
when systemd is the default init system.
Thanks to Andrei Popescu and Antoine Legonidec for the report and
additional tests. (Closes: #718624)
* transmission-daemon.links:
  - Link settings.json from /etc/transmission-daemon/settings.json to
/var/lib/transmission-daemon/.config/transmission-daemon.
  - Link /var/lib/transmission-daemon/.config/transmission-daemon to
/var/lib/transmission-daemon/info due to compatibility reasons with
the old sysv-rc init script settings.
* transmission-daemon.dirs:
  - Do not create /var/lib/transmission-daemon/info anymore.


 Regards,

 Markus Koschany




signature.asc
Description: OpenPGP digital signature

Re: DFSG filtering question

[Markus Koschany]

Hi,

On 16.10.2014 19:50, Felix Natter wrote:
 hi,
 
 I have a small java package (jmapviewer) where I might soon have to
 remove a file (displaying tiles from bing maps) due to licensing issues.
 
 I would do this by specifying Files-Excluded:
 .../BingAerialTileSource.java in debian/copyright, but it's not that
 easy since other Files (Demo.java) reference it.
 
 = I see two ways to do this:
 
 1. remove BingAerialTileSource.java using Files-Excluded: and modify
 Demo.java using a quilt patch
 = orig.tar.gz contains code that won't compile, is that a problem?

If you run uscan BingAerialTileSource.java will be removed from the original
tarball due to the Files-Excluded directive. In conjunction with your patch 
there
shouldn't be any code left that won't compile. The Debian package is always the
original tarball + Debian changes (the debian directory).


 2. remove BingAerialTileSource.java and modify Demo.java both using
 quilt patches

I would go for 1. Just repack the tarball and add +dfsg to the version number.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#762228: RFS: ufoai-music review

[Markus Koschany]

Hello Tobias,

On 21.09.2014 18:26, Tobias Frost wrote:
 Am Saturday, den 20.09.2014, 17:33 +0200 schrieb Markus Koschany:
[...]
 I said I could duplicate the code but I feel that we gain nothing with
 it since I'm the only one who has to work with those packages. 
 
 According d/control this package is team maintained.

I have been working on this package for a year now and I am currently
the only one who cares about it.

 As long
 as it is not a Policy violation, I would prefer to make some independent
 decisions about maintaining my own packages.
 
 I'm not enforcing the decisions to you. You can still freely decide to
 change according to my request or not. But out of decissions follow
 consequences.
 
 Let me put this in some words, being very clear and very direct:
 The policy only describes a minimum set of rules.  Best practice can go
 over this standards. The policy does not constitute a right for you to
 demand that I lower my standards in respect what I consider best
 practice, especially if you fail to convince me that you are right. 
 If you cannot accept that, I will not the one sponsoring your uploads. 
 
 Now, decide for the red or blue pill. 

I have already lost count how many times you gave me the choice between
sink or swim and it is definitely not very pleasant to learn from you
that you are not interested in my opinion.

Since you are a member of the Debian Games Team, why didn't you simply
ask all your questions on our list or on IRC and closed the sponsorship
bugs? Besides there was always the opportunity to discuss everything in
detail, at least in one other language to avoid any misunderstandings.
This is not about Debian's policy or your right to make improvement
proposals. You simply don't listen to the one who knows this game best
without having any experience with games of this caliber.

I presume the main issue here is that you never followed my advice to
have a look at the ufoai source package and to start with the game's
core. Did you ever compile the sources and play the game? From the  flow
of our conversation, I can only deduce: No.

You constantly ignored my objections and never understood the necessity
to create Debian compliant source tarballs out of upstream's Git
repository and most importantly, how this is actually achieved in a
Policy compliant way. Your question about the file removals could have
been easily answered by looking at the get-orig-source target. Instead
you jumped to a conclusion without considering the package maintainers
ideas.

The decision is not about reality or illusion. More about: Is mutual
respect important? I think it is, so it's high time to quit here.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#762228: RFS: ufoai-music review

[Markus Koschany]

On 20.09.2014 09:57, Tobias Frost wrote:
[...]
 First of all I'd like to suggest that you start with the ufoai source
 package first because it contains the ufoai_copyright.py script and
 other information that are useful to understand the packaging of
 UFO:AI's data packages.
 
 My reasoning is, that because of every data package has its own
 orig.tar, they need to be crafted in a way to so that they will
 be -- individually looked at -- reach Debian quality requirements. 

I still don't see why the current copyright file does not meet Debian's
quality requirements. Instead of one huge 900 MB -data package, the game
data was simply split into three different source packages. This makes
it much easier to fix bugs without having to upload all data files every
time.

I would like to stress: The source packages are not independent of each
other, they belong together. It is due to mere technical reasons that
the -data was split. In my opinion we are in full compliance with
Debian's Policy because

- we state in d/copyright that the game data was split due to technical
  reasons
- we use a reproducible and convenient way to determine all copyright
  information.
- the copyright file is machine-readable and every file in each source
  package is covered by an license paragraph in debian/copyright.

Thus the whole copyright file is accurate.

[...]
 Admitting, upstream is exemplary in case of tracking of its licenses
 (also with the scope for Debian!), and it really helps to automate this
 to get a skeleton dep5 file. 

Indeed. UFO:AI is an exemplary and excellent free software game and its
developers care a lot about tracking licenses.

 However -- as with the output of licensecheck of the devscripts -- the
 output needs to be checked and compared to *every* files in the source.

Right. This is already achieved. Which license information are incorrect?

 The LICENSE file may (and have) also errors: For example there are files
 in this files with no copyright holder attributed. Or, there are URLs
 attributed as copyright owners. How does the script handle this? In the
 end this leads to wrongly attributed files that will either go unnoticed
 (so Debian is violating copyright law) or lead to an FTP Master reject. 

First of all the whole game is licensed under GPL-2+ and is copyright
The UFO:AI team. In addition the LICENSES file contains all information
about individual game data licenses that diverge from this general
assumption.

One line in LICENSES looks like that:

filename | license | author | source

base/maps/africa/af_empty6a.map | GNU General Public License 2.0 or
later | Holger 'ShipIt' Gellrich | base/maps/africa/af_empty6.map

The script splits all fields by the | delimiter and maps all filenames
to their corresponding licenses and copyright holders. If there is no
one mentioned under author one may assume that this is always a work by
the UFO:AI team.

 
 To make it clear: I require an 100% accurate d/copyright and this is one
 of the few points that are not subject to negotiations.

Absolutely. Could you elaborate on where a file is not accurately
addressed by copyright format 1.0?

[...]
 I believe we shouldn't make the process of creating debian/copyright
 even more painful and I think that a reference to
 /usr/share/common-licenses is more than enough for the most widely used
 free software license.
 
 I disagree. As said above, d/copyright is important. Yes, it is tedious
 to create it the first time and there are more exciting things to do,
 but it is a necessity to be done and to do it right.

Absolutely agreed. But can you point me to examples where the short
reference to /usr/share/common-licenses was deemed not appropriate by
the FTP team?

 The policy means you should not quote the verbatim license, but it is
 common practice to quote the first 3 paragraphs. 

No, that's not true. A lot of maintainers write standalone paragraphs
for common licenses exactly as I do.

 Otherwise we'll introduce fuzziness.  Consider License GPL-2+
 You refer to the GPL-2 file, which makes it non-obvious that you have
 the or later option in place. For the causal user, its not
 self-explaining what the + means.

Copyright format 1.0 clearly defines short names and keywords. GPL-2 and
GPL-2+ are well defined and unambiguous.

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

It is common practice and knowledge that GPL-2 refers to the GNU General
Public license 2 and GPL-2+ refers to the same license but includes the
or later clause.

 Please add the few lines, I consider it not enough to just have the
 reference. 

Ok, that's fine. I completely understand that it is your prerogative as
a developer to determine what you consider suitable for an upload.
However I have touched more than 100 source packages already and I am
sure that this is not what Policy demands and merely an arbitrary
requirement. Even the rules for copyright format 1.0 state for the
License field:

Otherwise, this field 

Re: Bug#762228: RFS: ufoai-music review

[Markus Koschany]

Hi,

On 20.09.2014 10:10, Christian Kastner wrote:
 Hi Markus,
 
 On 2014-09-20 01:22, Markus Koschany wrote:
 The debian/copyright file is identical for ufoai-data, ufoai-music and
 ufoai-maps.
 
 I find this somewhat confusing.
 
 Generally speaking, I don't believe that listing the copyright of files
 which are not part of the source package (in fact, which are part of
 another package) is policy-conform, regardless of whether upstream
 created the source split, or you.
 But specifically, imagine I fork the ufoai package to create my own
 modded version, and imagine I think the music is fine so I just depend
 on that package instead of forking that one, too. The music package
 would then, in its copyright, list incorrect information, as through my
 fork, the copyright of some of the other files would have changed.

Sorry, I don't understand your objection. debian/copyright provides all
copyright information that you need for the music files in a
machine-readable format. Did you have a look at the copyright file? What
information do you think is missing?

[...]

 Why not simply modify this script to generate 4 copyright files instead
 of 1 (one for each source package)? For example, if the music is in a
 subdirectory, you can split by that.

Yes, you could write even more code to parse nearly 7000 files until
everyone is satisfied. The question is whether the copyright file is
Policy compliant already and with the information provided, I think it is.

 
 It also comes with the advantage that all files are machine-readable
 now. Thus wildcards, except for the Files: * paragraph, aren't
 necessary and the whole copyright information are more precise.
 
 If you have a directory base/textures/tex_trak/, and all the files in
 there were created by the same author, then listing them individually
 or using the * glob pattern convey exactly the same amount of
 information, but using * makes the file far more (human-)readable.

Debian's copyright format 1.0 is well defined. This is one of the rare
occasions where you benefit from upstream's careful handling of license
information and a machine-readable format that makes the accuracy
visible and in addition it saves time to write d/copyright. There is no
need for glob patterns if you have a convenient way to reproduce the
result of the script.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#762228: RFS: ufoai-music review

[Markus Koschany]

On 20.09.2014 16:02, Tobias Frost wrote:
 Addendum:
 
 On Sat, 2014-09-20 at 15:45 +0200, Tobias Frost wrote:
 Absolutely agreed. But can you point me to examples where the short
 reference to /usr/share/common-licenses was deemed not appropriate by
 the FTP team?
 
 
 From
 https://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
 (the FTP master provides that link in their REJECT-FAQ,
 https://ftp-master.debian.org/REJECT-FAQ.html, under Copyright)
 Its from 2006, but still valid)
 
 - Its not enough to have the following two-liner:
   | On Debian systems, the complete text of the GNU General Public License
   | can be found in the `/usr/share/common-licenses/GPL' file.

   There are license headers, like the one used for GPL in the example below, 
 you
   should use those.
 

I think that contradicts the information from Debian's Policy and the
copyright format 1.0 manual and needs further clarification from the FTP
team. There are many packages that use copyright format 1.0 and the same
License paragraphs in the same way as I do and I am not aware that
anybody rejected packages because of that.

The example above is most like wrong because it refers to a symlink
license and not to a specific version.

If this is still the position of the FTP team and they simply
overlooked hundred of packages, I stand corrected. But I really hope
that this is no longer true for copyright format 1.0 because it would be
just another mindless copypaste exercise without a real benefit.


Markus



signature.asc
Description: OpenPGP digital signature

Re: Bug#762228: RFS: ufoai-music review

[Markus Koschany]

On 20.09.2014 16:00, Christian Kastner wrote:
 On 2014-09-20 13:02, Markus Koschany wrote:
 On 20.09.2014 09:57, Tobias Frost wrote:
 My reasoning is, that because of every data package has its own
 orig.tar, they need to be crafted in a way to so that they will
 be -- individually looked at -- reach Debian quality requirements. 
 
 To expand on this, try to see this from a contributor's POV.
 
 Say I use ufoai (I do, actually ;-) ), and say I find a bug in the
 ufoai-music package. A common way to contribute would `apt-get source
 ufoai-music`, and the produce a patch, or debdiff, or whatever.

I didn't know the unreleased package had already its first user. Be
welcome. Of course you can still do apt-get source ufoai-music. Nothing
prevents you from doing that.


 Say the Security Team wants to upload a security fix for an issue with
 ufoai, then they should be able to do so by just getting its source.

The security team will then work on src:ufoai for sure because it
contains the complete source code. src:ufoai-music contains only music
and sound files. It is unrealistic to believe that they will ever make a
security upload for ogg files.

 Note that these are purely hypothetical examples that are probably not
 relevant to ufoai (in total), they serve just to emphasize why it's
 important to not just look at a set of (source) packages as a whole, but
 also invidually.

I feel your hypothetical examples don't reflect the reality for a game
like UFO:AI. The place where you can find the get-orig-source targets is
documented and if you really consider contributing to UFO:AI, I'd like
to ask you to study src:ufoai as well.


[...]
 In my opinion we are in full compliance with
 Debian's Policy because

 - we state in d/copyright that the game data was split due to technical
   reasons
 - we use a reproducible and convenient way to determine all copyright
   information.
 
 Here's an example for where I see problems with the split: the script to
 reproduce the copyright information for ufoai-music is in ufoai, so just
 getting ufoai-music's source alone does not help me here.

That's why debian/copyright says you can find the ufoai_copyright.py in
src:ufoai. It is a helper script and nothing more.


 - the copyright file is machine-readable and every file in each source
   package is covered by an license paragraph in debian/copyright.

 Thus the whole copyright file is accurate.
 
 When, in source package $source, you are claiming copyright for a
 non-existing file, then that information -- minor issue as it may be --
 is most certainly not accurate.

If I really want an information about the licensing of a certain file I
can retrieve it rather easily by looking at debian/copyright be it in
the ufoai-data, ufoai-music or ufoai-maps package. A machine would
simply ignore those non-existing files and still find the matching
files in the related source package. A human being would even understand
that the same copyright file covers three source packages which are a
logic entity but were split due to technical reasons.

I understand that you think that makes the copyright file not accurate
whereas I think we just create a lot of busywork.

Markus






signature.asc
Description: OpenPGP digital signature

Bug#762228: RFS: ufoai-music review

[Markus Koschany]

On 20.09.2014 15:45, Tobias Frost wrote:
[...]
 The split is not under dispute. Other packages do that too, for example
 redeclipse. But redeclipse do it right (in my view) and their
 generate-copyright-script which is aware of the package it acts on. 
 (Your script can be enhanced to do that too. Probably less time effort
 that I spent already on this topic.)

Redeclipse consists only of src:redeclipse and src:redeclipse-data. So
in this case there is only *one* data package and naturally the
generate-copyright-script acts only on this one.

I agree with you that we both waste time here. I still think the comment
in debian/copyright and the nature of the split would justify a
unified d/copyright file but I intend to modify the script so that
everyone's happy.

[...]

 I disagree. Having 6362* entries in d/copyright which does not match any
 file is NOT accurate. To be very clear: I will NOT sign such a package
 with my PGP key. 
 
 (*6392 is the number of lintian
 wildcard-matches-nothing-in-dep5-copyright messages, already music/ and
 sound/ subtracted)

Please note that's an informational warning and with the information
given already, everyone knows that the three data packages should be
seen as one package just split in three parts.


 Due to the split I say we now have 4 related, but independent source
 packages and they should be handled as such.  
 The Relation is no guarantee that the packages will not diverge in the
 future. (e.g code could go forward, while data keeps the same, or vice
 verse)

Nope, those packages will always be kept in sync with src:ufoai. They
are not independent source packages and you should simply trust me with
that statement.


[...]
 To make it clear: I require an 100% accurate d/copyright and this is one
 of the few points that are not subject to negotiations.

 Absolutely. Could you elaborate on where a file is not accurately
 addressed by copyright format 1.0?
 
 
 Who's the copyright owner of those?
 base/models/objects/vegi/palm_v1/palm1.md2 | Creative Commons
 Attribution-Share Alike 3.0
 base/models/objects/vegi/palm_v1/palm2.md2 | Creative Commons
 Attribution-Share Alike 3.0
 base/models/objects/vegi/palm_v2/palm1.md2 | Cr.g teative Commons
 Attribution-Share Alike 3.0
 base/models/objects/vegi/palm_v2/palm2.md2 | Creative Commons
 Attribution-Share Alike 3.0
 
 (if emtpy means upstream, UFO:AI Team is not in the list for that
 license and its not GPL-2+. Either way, d/copyright is wrong here.)

Empty means UFO:AI team. I will add this information more prominently to
debian/copyright.

 
 contrib/7th.zip |  | 2002 Iconian Fonts - Daniel Zadorozny -
 http://www.iconian.com/
 contrib/scripts/compile_po.bat |  | Kostia Kildor Romanov
 contrib/scripts/update_potfiles_in.bat |  | Kostia Kildor Romanov
 
 no such files -- LICENSE has too many files
 
 radiant/bitmaps/texwindow_uniformsize.png |  | orbweaver (commiter in 
  darkradiant repository) |


True. I removed those files. They are not part of the sources.

[..l]
 base/textures/tex_pics/art_africa008.png | Creative Commons
 Attribution-Share Alike 3.0 | Udit Kulshrestha |
 http://commons.wikimedia.org/wiki/File:Ole_Man.jpg
 
 Wikimedia says Creative Commons Attribution-Share Alike 3.0 Unported

That's correct. It is CC-BY-SA-3.0 but that's the same information
LICENSES gives you currently. Unported is implied see also the
standalone paragraph.

 
 base/textures/tex_buildings/carpet024.png | GNU General Public License
 2.0 or later | MCR |
 http://commons.wikimedia.org/wiki/File:42556-Antique-Persian-Tabriz-Carpets-hires.jpg
 
 Wikimedia says
 GNU Free Documentation Licidenticalense, Version 1.2 (no invariant) or
 any later version or CC-BY-SA-30 and author is Nazmiyal
 
 (Those were random picks out of the http-ones; to avoid the imopression
 that everytghing is wrong: Its not, there are correct ones, which I did
 not quote.)

Those two files need to be investigated.

[...]
 Sure I could duplicate the same code for every source package but what
 would we gain? Quality? Reduction of maintenance work?
 
 Come on... Above you say keeping 4 duplicated copyright files in sync is
 fine and now you say you cannot handle to keep 4 identical
 get-orig-targets snippets in sync? (The snippets could use, for example,
 use the upstream version from d/changelog to get the right commmit --
 using the upstream tag and not the git commit id, then everything is
 wonderful and likely never needs a change.
 
 I see all of the 4 source packages as related, but independent entities.

I said I could duplicate the code but I feel that we gain nothing with
it since I'm the only one who has to work with those packages. As long
as it is not a Policy violation, I would prefer to make some independent
decisions about maintaining my own packages.

[...]
 
 Ok, lets leave that without +repack.
 
 (I still think people will have the expectation without it that they
 will be able to find the orig.tar somewhere on the net as is,
 especially as 

Bug#759688: ufoai

[Markus Koschany]

On 19.09.2014 07:32, Tobias Frost wrote:
 Control: owner -1 !
 Control: tags -1 pending
 
 I'll try to review these packages over the weekend.
 (the package looks huge :)

Hi Tobi!

Thank you for your interest in UFO:AI. Indeed it's one of the more
complex and bigger games. :)


 (First thing that I saw -- but I don't know how's the best practice
 in pkg-games, so maybe this is more a question to the list:
 There is only one ITP filed, but three source packages (ufoai, -data,
 -maps and -music)?

I presume you wanted to CC debian-devel-games. All e-mails to team
maintained packages are automatically forwarded to pkg-games-devel but
most of the discussion happens on debian-devel-games.

 Should the ITP be cloned (and blocking each other) to be able
 to close a ITP or is it fine to ignore/override the lintian?)

FWIW, I think we should follow Lintian's advice in this case and just
use one ITP bug to track the progress.

https://lintian.debian.org/tags/new-package-should-close-itp-bug.html

The three data packages are all part of the same game and they had to be
split because of size and functional reasons but they wouldn't make
sense without the ufoai source package.

 I'll probably also clone this RFS bug to have an per-package tracking of
 the review process. (unless this is a first-pass-package ;-))

Sure, it is. :P

Cheers,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#759688: ufoai

[Markus Koschany]

On 19.09.2014 21:44, Tobias Frost wrote:
[...]
 The three data packages are all part of the same game and they had to be
 split because of size and functional reasons but they wouldn't make
 sense without the ufoai source package.
 
 Well the lintian message says split of an *existing* Debian package,
 which is not the case here. On the other side, they are different source
 packages, so there would be a point for an ITP.

As I already stated above the game data had to be split in different
source packages but those source packages belong all to the same game
hence they are all covered by ITP bug #244582. The existing package is
clearly the ufoai source package.

In my opinion ITPs are useful to indicate that people work on packaging
certain software for Debian, so that double-work can be avoided but they
are not meant to become some sort of bureaucratic exercise. They should
always be filed before someone works on new software. Since the game has
already been packaged, now filing new ITPs would simply be busywork.

If you read through #244582 you will also notice that I mentioned the
reasons for the package split in this bug report. Thus it became clear
for everyone that #244582 is about all four source packages.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#762228: RFS: ufoai-music review

[Markus Koschany]

Hi Tobias,

thanks for taking your time for this.

On 19.09.2014 23:51, Tobias Frost wrote:
 Control: -1 moreoinfo
 
 Hi Markus,
 
 so, let's start with -music

First of all I'd like to suggest that you start with the ufoai source
package first because it contains the ufoai_copyright.py script and
other information that are useful to understand the packaging of
UFO:AI's data packages.

 - d/copyright contains *many* files not in this package.
 Please clean up the file. (Also, please use wildcards;
 this makes it far easier to review)

The debian/copyright file is identical for ufoai-data, ufoai-music and
ufoai-maps. I did this on purpose because upstream does not distinguish
between those files. In fact they maintain everything in one Git
repository and the LICENSE file contains all copyright information for
the game data. Thus I decided to use a script to parse all license
information and then I generated a machine-readable debian/copyright
file out of them.

This makes it far easier to review the packages IMO because you only
have to check and run the script on LICENSES. It also comes with the
advantage that all files are machine-readable now. Thus wildcards,
except for the Files: * paragraph, aren't necessary and the whole
copyright information are more precise.


 Seems that a base/ prefix slipped in the -music part of d/copyright?

Nope, I think the base prefix is correct in d/copyright but the music
and sounds directory should have been placed under the base directory in
src:ufoai-music. At least that would have been more consistent. I can
change that.

 Nitpick*: It looks like you are autogenerating the copyright file from
 LICENSES. In this case, it would probably make sense (even if the
 copyright-format-1.0 permits it to combine) to be more accurate and not
 combine so many authors in one big block. 

Please see above. The script transforms upstream's LICENSES file into a
machine-readable copyright format 1.0 file. I think the benefits are
obvious and having the same information about authors listed as in
LICENSES seems like a good thing to me.


 License: GPL-2
  On Debian systems, the complete text of the GNU General Public License
  version 2 can be found in /usr/share/common-licenses/GPL-2.
 
 This is not enough -- you need to add the first 3 paragraphs of the
 license -- see the dep5' examples section.

https://www.debian.org/doc/debian-policy/ch-docs.html

Packages distributed under the Apache license (version 2.0), the
Artistic license, the GNU GPL (versions 1, 2, or 3), the GNU LGPL
(versions 2, 2.1, or 3), and the GNU FDL (versions 1.2 or 1.3) should
*refer* to the corresponding files under
/usr/share/common-licenses,[119] *rather than quoting them* in the
copyright file. 

I believe we shouldn't make the process of creating debian/copyright
even more painful and I think that a reference to
/usr/share/common-licenses is more than enough for the most widely used
free software license.

 - d/README.Source is refering to src:ufoai -- but this has no
 README.Source, but should (actually a point of uifoai)
 I think you need to tell in this file how to get the music files,
 and you'll need to move the get-orig-source target from ufoai's
 d/control here... (I prefer to have self-containing src packages,
 which does not say look in yyy to do get the source for xxx ...

All information how to get the original sources are documented in
src:ufoai + the package provides convenient get-orig-source targets.

The reasons therefor are:

- It saves us from duplicating the same information
- It is easier to work with src:ufoai because we have all information
  in one place
- src:ufoai is small (only 9 MB) thus it saves bandwidth and time for
  those who want to recreate the original source tarballs.


 - d/watch does not produce the source file but a file that does not
 even have the -music files. This might be unexpected behavior, so this
 needs to be documented in README.Source and in the watchfile.

d/watch just checks for new releases. It is far more convenient to work
with the upstream Git repository hence I have created get-orig-source
targets in src:ufoai.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#759688: RFS: ufoai/2.5-1 [ITP]

[Markus Koschany]

Package: sponsorship-requests
Severity: wishlist


Dear mentors,

I am looking for a sponsor for my packages ufoai, ufoai-data, ufoai-maps
and ufoai-music.

* Package name: ufoai
  Version : 2.5-1
  Upstream Author : UFO:AI team
* URL : http://ufoai.org
* License : GPL-2+, CC-BY-SA, CC-BY, Expat, Public Domain
  Section : games

It builds those binary packages:

ufoai - UFO: Alien Invasion -- build your team and stop the aliens
ufoai-common - UFO: Alien Invasion -- scripts and configuration files
ufoai-dbg  - UFO: Alien Invasion -- debugging symbols
ufoai-misc - UFO: Alien Invasion -- miscellaneous files and documentation
ufoai-server - UFO: Alien Invasion -- dedicated server
ufoai-tools - UFO: Alien Invasion -- developer tools
ufoai-uforadiant - UFO: Alien Invasion -- map-building tool
ufoai-uforadiant-data - UFO: Alien Invasion -- map-building tool data files

ufoai-maps - UFO: Alien Invasion -- maps
ufoai-textures - UFO: Alien Invasion -- textures
ufoai-data - UFO: Alien Invasion -- data files
ufoai-music - UFO: Alien Invasion -- music files
ufoai-sound - UFO: Alien Invasion -- sound files


To access further information about those packages, please visit the
following URLs:

http://mentors.debian.net/package/ufoai
http://mentors.debian.net/package/ufoai-data
http://mentors.debian.net/package/ufoai-maps
http://mentors.debian.net/package/ufoai-music

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#740543: RFS: eggdrop/1.6.21-1 [ITA #698272]

[Markus Koschany]

Hi Vincent,

On 12.04.2014 11:10, Vincent Cheng wrote:
[...]
 
 debian/copyright is missing a few copyright holders + license
 statements, e.g. LGPL-2+ for src/compat/gnu_strftime.c and (partially)
 4-clause BSD for src/compat/inet_aton.c (actually, the latter is
 problematic because most of the upstream source is GPL-2+ licensed,
 which is incompatible with 4-clause BSD [1]). That's actually another
 RC bug right there...

the 4-clause BSD license should not be problematic in this case since
the copyright holder is the University of California. They granted all
licensees the right to delete the paragraph about advertising
materials thus making the license compatible with the GPL.

ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change

I think it is sufficient to document this fact with a comment in
debian/copyright and to ask upstream to remove the offending paragraph.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#734456: RFS: stockfish -- new version

[Markus Koschany]

On 07.01.2014 15:48, Andreas Tille wrote:
[...]
 I know that the Debian Games team does not really feel obliged to the
 Blends idea nor does it seem that all members even know that there is
 such a framework even for Debian Games.  Nevertheless I'd be fine to
 sponsor games if the conditions listed on the Sponsoring of Blends
 page are fullfilled:
 
https://wiki.debian.org/DebianPureBlends/SoB
 
 Just saying
 
Andreas. 


Hi Andreas,

I haven't forgotten about my promise to update the blends task page for games
and it will be finished soonish (meaning this month). Currently I'm combining 
this
task with another related goal of the Games Team for which I have to investigate
each and every games package in Debian.

https://wiki.debian.org/Games/JessieReleaseGoal

Rodrigo is surely welcome as a member of the team. It's usually a good idea to
say hello at debian-devel-games or in our IRC channel at #debian-games
and someone (maybe myself) could help with reviewing the package.

However we are extremely low on sponsors here and as you surely know, it is 
very hard
to attract new members, if nobody is willing to sponsor their work or if they 
have to
do something unrelated first.

Your message is understood. Nevertheless every sponsored package is welcomed 
here.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#732234: RFS: libgringotts/1:1.2.1-13 [RC]

[Markus Koschany]

Control: severity -1 important
Control: retitle -1 RFS: libgringotts/1:1.2.1-13 [RC]

Hello,

I would also love to see libgringotts and osmo back in testing again.
The original bug in libgringotts is RC thus the severity of this request
for sponsorship should be important.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#728181: RFS: tofrodos/1.7.13+ds-1 [ITA]

[Markus Koschany]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package tofrodos which I intend to
adopt.

Package name: tofrodos
Version : 1.7.13+ds-1
Upstream Author : Christopher Heng
URL : http://www.thefreecountry.com/tofrodos/index.shtml
License : GPL-2
Section : utils

It builds those binary packages:

tofrodos   - Converts DOS - Unix text files, alias tofromdos

To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/tofrodos

Alternatively, one can download the package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/t/tofrodos/tofrodos_1.7.13+ds-1.dsc

Changes since the last upload:

 [ Alexander Reichle-Schmehl ]
  * Fix last changelog entry, remove the NOT RELEASED YET entry.
(Closes: #645830) Thanks to Josh Triplett for noticing!

  [ Markus Koschany ]
  * New Maintainer. (Closes: #726553)
  * New upstream release. (Closes: #692421)
- Drop FTBFS_non-linux.patch. Merged upstream.
  * Switch to source format 3.0.
  * Bump compat level to 9 and require debhelper = 9.
  * Bump Standards-Version to 3.9.5, no changes.
  * Improve watch file. Thanks to Bart Martens.
  * Drop README.source and build dependency on quilt. Source format 3.0
uses quilt by default.
  * Drop NEWS file because it is obsolete.
  * Register tofrodos.html with doc-base.
  * Switch to dh sequencer.
  * Add a get-orig-source target to debian/rules.
  * Enable all hardening build flags.
  * debian/control:
- Maintain tofrodos in a Git repository. Change VCS-fields
  accordingly.
- Drop Conflicts field in debian/control. It is obsolete.
   * Update debian/copyright to copyright format 1.0.

Regards,

Markus Koschany



signature.asc
Description: OpenPGP digital signature

Bug#728181: RFS: tofrodos/1.7.13+ds-1 [ITA]

[Markus Koschany]

On 29.10.2013 10:23, Andrew Shadura wrote:
 Hello,
 
 On 29 October 2013 09:57, Markus Koschany a...@gambaru.de wrote:
 I am looking for a sponsor for my package tofrodos which I intend to
 adopt.
 
 I've built, signed and uploaded your package. Thanks for your work.
 
 Feel free to contact me if you need to sponsor your upload again.

Andrew, thank you very much!

Markus



signature.asc
Description: OpenPGP digital signature

Bug#723142: RFS: dnt/0.10-1 [ITP]

[Markus Koschany]

Hi Vincent,

as promised, here is my review for DNT.

First of all the overall impression is very positive and the whole
package is already in a good shape. Thanks for packaging DNT.
Things you could improve:

- please depend on debhelper =9 and use compat level 9
- you don't have to build-depend on quilt because source format 3.0
  uses quilt by default
- your dependency on dnt-data (= ${source:Version}) is probably too
  strict in this case because your data package is rather large. ( 150
  MB). You can save a lot of bandwidth by depending on

 dnt-data (= ${source:Upstream-Version}),
 dnt-data (= ${source:Version})

The same goes for dnt-tools.

- Package: dnt-data
I would lower Recommends: dnt (= ${binary:Version}) to Suggests: dnt.
Most people, who download the data package directly, are only interested
in the data files.

- package description: Maybe you could find one or two additional
sentences why people should play this game and describe what it makes
special. You don't have to mention that it is a free game. All packages
in main are free.

- Your desktop files contain a minor mistake because all keywords must
have a semicolon as trailing character. You can validate your desktop
file with desktop-file-validate.

- It is not 100% clear how you obtained the sources. The original
tarball is bz2 compressed. Yours is gz compressed. I suggest you switch
to xz compression in source/options and for the upstream tarball and
document modifications either in README.source or you might want to
write a get-orig-source target for debian/rules.

https://wiki.debian.org/onlyjob/get-orig-source

- The desktop icons for the map-editor and part-editor look blurred on
Gnome 3. The dnt icon looks much better.

- debian/copyright:
Please update the old dep5 syntax to copyright format 1.0.
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

- You might want to add the license paragraph in upstream's README as a
comment to your copyright file because it clarifies the whole licensing.

- You can avoid some useless dependencies by using

export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed

in debian/rules or by updating the build system.

- I get a strange error message when I run the map editor from the
command line:

EE r600_texture.c:786 r600_texture_transfer_map - mapping MSAA zbuffer
unimplemented
OpenGL Error: out of memory

Otherwise it seems to work.

- You need to install the game data to /usr/share/games
- Some of the fonts are non-free. Those have to be removed in the
  original tarball and not only in the final package.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Re: Hardening powder

[Markus Koschany]

On 10.05.2013 11:38, Steven Hamilton wrote:
 Hi folks,
 I'm adopting and repacking Powder as per bug #691835. In addition to
 modernising the package I'm attempt to harden it. The package uses a
 custom shell script to build which I fork out of the rules file. No
 matter what I do though I can't fully harden it with the best I can get
 being this;

Hi Steven,

you can use

export DEB_BUILD_MAINT_OPTIONS = hardening=+all

in debian/rules to activate all hardening features.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#696385: RFS: astromenace/1.3.1+ds-1 [ITP] -- hardcore 3D space shooter with spaceship upgrade possibilities

[Markus Koschany]

Hi Boris,

just a comment on the copyright file. You are targeting the data for
non-free but actually the game data is licensed under free licenses,
namely GPL-3+ and CC-BY-SA-3.0. I assume the precompiled 3D models are
the reason why astromenace-data should be in non-free because the
sources are missing. IMO this should be documented at the top of
debian/copyright like

Comment:
 This data package is non-free because... to make it free you have to
 do the following...

Otherwise nobody will know in a few years why you have made this
decision and the package will likely stay in non-free forever.

Regarding your font issue, i think you have already done the right thing
by contacting the decision makers. :)

Regards,

Markus





signature.asc
Description: OpenPGP digital signature

Bug#699273: RFS: cdrdao/1:1.2.3-1 [QA]

[Markus Koschany]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package cdrdao.

Package name: cdrdao
Version : 1:1.2.3-1
URL : http://cdrdao.sourceforge.net
License : GPL-2+
Section : otherosfs

It builds those binary packages:

cdrdao - records CDs in Disk-At-Once (DAO) mode
gcdmaster  - GNOME GUI for cdrdao

To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/cdrdao


Alternatively, one can download the package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/c/cdrdao/cdrdao_1.2.3-1.dsc

Changes since the last upload:

* QA upload.
* Set Maintainer to Debian QA Group.
* Bump compat level to 9 and use debhelper =9 for automatic hardening
  build flags.
* Bump Standards-Version to 3.9.4, no changes required.
* cdrdao-binary: Add missing dependency on
  libperl4-corelibs-perl | perl ( 5.12.3-7). (Closes: #658944)
* Update debian/copyright to copyright format 1.0.
* Add missing dep3 header to 15-kfreebsd-gnu.patch.
* debian/patches:
  - Add 18-create-valid-desktp-file.patch and remove deprecated UFT-8
Encoding entry, fix outdated categories and Icon entry.
  - Add 19-fix-format-not-a-string-literal-error.patch which prevents a
FTBFS.
  - Add 20-fix-spelling-and-hypen-used-as-minus.patch which corrects
errors of the same name in cdrdao's and gcdmaster's manpage.
* debian/rules:
  - Use dh sequencer to simplify debian/rules and to provide
recommended build-arch and build-indep targets.
  - Build with --parallel.
  - Use --with autotools_dev addon to provide an up-to-date
config.sub and config.guess file and do not remove these files in
the clean target.
  - Build with --Wl, --as-needed to avoid unnecessary dependencies on
gcdmaster.
  - Enable all hardening build flags with hardening=+all.
* Add watch file. Thanks to Bart Martens.

Regards,

Markus Koschany



signature.asc
Description: OpenPGP digital signature

Bug#695191: RFS: xarchiver/1:0.5.2+20090319+dfsg-4.1 [RC] [NMU]

[Markus Koschany]

Package: sponsorship-requests
Severity: important 

Dear mentors,

I am looking for a sponsor for my package xarchiver. The current
maintainer of xarchiver seems to be MIA. The new version fixes a crash
when someone opens a 7z archive and two minor/documentation bugs. The
new package is in accordance with the freeze policy. 

Package name: xarchiver
Version : 1:0.5.2+20090319+dfsg-4.1
Upstream Author : Giuseppe Torelli colossu...@gmail.com
URL : http://xarchiver.sourceforge.net
License : GPL-2+
Section : x11

It builds those binary packages:

xarchiver  - GTK+ frontend for most used compression formats

To access further information about this package, please visit the following 
URL:

http://mentors.debian.net/package/xarchiver


Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/x/xarchiver/xarchiver_0.5.2+20090319+dfsg-4.1.dsc


Changes since the last upload:

* Non-maintainer upload.
* Add patch 04-fix-7z-crash.patch and restore the ability to open and
  view 7z archives again. (Closes: #665642)
* Remove discouraged MIME type multipart/x-zip from desktop
  file. (Closes: #656301)
* Don't mention xarchive in the package description
  because it isn't available in Debian. (Closes: #692261)
* Update Homepage field in debian/control and point to the actual homepage
  of xarchiver at sourceforge.net.


Regards,

Markus Koschany




signature.asc
Description: Digital signature

Bug#695191: RFS: xarchiver/1:0.5.2+20090319+dfsg-4.1 [RC] [NMU]

[Markus Koschany]

On Wed, 05. Dec 17:13 Kartik Mistry kartik.mis...@gmail.com wrote:
 On Wed, Dec 5, 2012 at 1:56 PM, Markus Koschany a...@gambaru.de wrote:
  I am looking for a sponsor for my package xarchiver. The current
  maintainer of xarchiver seems to be MIA. The new version fixes a crash
  when someone opens a 7z archive and two minor/documentation bugs. The
  new package is in accordance with the freeze policy.
 
 Looks good. Ping me if you've not found sponsor yet.
 
Hi Kartik,

thanks for your interest in xarchiver. I haven't found a sponsor yet, so
please go ahead!

Best regards,

Markus


signature.asc
Description: Digital signature

Bug#695191: RFS: xarchiver/1:0.5.2+20090319+dfsg-4.1 [RC] [NMU]

[Markus Koschany]

Hi gregor,

On 05.12.2012 19:03, gregor herrmann wrote:
 BTW: I don't think it's a good idea to combine the fix for one RC
 bugs with changes that fix 2 minor bugs in an upload that should get
 into wheezy ...


I think fixing the two minor bugs is covered by point 4 of the freeze
policy. It's a win-win situation and it comes without altering one
single line of code.

http://release.debian.org/wheezy/freeze_policy.html

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#693249: RFS: etw/3.6+svn140-4 [RC] [ITA] arcade-style soccer game

[Markus Koschany]

On Sat, 17. Nov 17:25 Michael Gilbert mgilb...@debian.org wrote:
 Hi,
 
 I've just reviewed this, and it looks mostly good.  I did notice
 things like the following:
 
 + FILE *f;
 ++char path[1024];
 ++sprintf(path, %s/%s, getenv(HOME), .etw/etw.cfg );
 + D(bug(Reading configuration...\n/*-*/));
 
 Note that a hardcoded 1024 isn't very portable.  C defines PATH_MAX
 for this purpose.  Please use that instead.
 
Hi Michael,

thanks for taking the time to review the changes. Indeed the author of
etw already checks for PATH_MAX in etw.c and stores the result in
TEMP_DIR. On the other hand he uses 1024 bytes for the buffer at most
and truncates the rest if it exceeds this limit. You can find the
relevant part at line 800 and the following lines in menu.c.

Thanks for pointing this out. I've changed the code accordingly.

+--- a/etw/menu_config.c
 b/etw/menu_config.c
+@@ -392,9 +392,16 @@ void load_config(FILE *f)
+ void read_menu_config(void)
+ {
+ FILE *f;
++char path[1024];
++snprintf(path, 1024, %setw.cfg, TEMP_DIR);
++
+ D(bug(Reading configuration...\n/*-*/));
+ 
+-f=fopen(etw.cfg/*-*/,r);
++f=fopen(path/*-*/,r);
++
++if (f == NULL) {
++  f=fopen(etw.cfg/*-*/,r);
++}


I've uploaded the new version to mentors.debian.net and attached the complete 
debdiff to
bug report #693244. 

Regards,

Markus


signature.asc
Description: Digital signature

Bug#693249: RFS: etw/3.6+svn140-4 [RC] [ITA] arcade-style soccer game

[Markus Koschany]

On Sun, 18. Nov 19:20 Michael Gilbert mgilb...@debian.org wrote:
 I tried to build, but got an error: undefined reference to 'atan2'.  I
 think your linker flags are missing '-lm'?

That's strange. How did you try to build etw? Did you use the package at
mentors.debian.net?

https://mentors.debian.net/package/etw

I have never seen this error before with etw. I use pbuilder/cowbuilder and it 
builds just
fine here on amd64 and i386.

Cheers,

Markus



signature.asc
Description: Digital signature

Bug#693563: RFS: openyahtzee/1.9.1-2 [ITA] --classic dice game of Yahtzee

[Markus Koschany]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package openyahtzee which i intend
to adopt.

Package name: openyahtzee
Version : 1.9.1-2
Upstream Author : Guy Rutenberg guyrutenb...@gmail.com
URL : http://www.openyahtzee.org
License : GPL-2+
Section : games

It builds those binary packages:

openyahtzee - classic dice game of Yahtzee

To access further information about this package, please visit the
following URL:

 http://mentors.debian.net/package/openyahtzee


Alternatively, one can download the package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/o/openyahtzee/openyahtzee_1.9.1-2.dsc


Changes since the last upload:

* New Maintainer. (Closes: #544935)
* debian/control:
- Change Priority from extra to optional.
- New Standards-Version 3.9.4, no changes needed.
- Update Vcs-fields. Now Open Yahtzee is maintained in a git
  repository.
* Update debian/copyright to copyright format 1.0.
* debian/rules:
- Build with hardening=+all.
- Build with --as-needed to avoid unnecessary dependencies.
* Bump compat level to 9 and require debhelper (=9) to use automatic
  hardening build flags.

  Regards,
   Markus Koschany



signature.asc
Description: OpenPGP digital signature

Bug#693565: RFS: supertransball2/1.5-5 [ITA] -- Thrust type of game

[Markus Koschany]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package supertransball2 which i
intend to adopt.

Package name: supertransball2
Version : 1.5-5
Upstream Author : Santiago Ontañón santi.onta...@terra.es
URL : http://www.braingames.getput.com/stransball2/
License : GPl-2+
Section : games

It builds those binary packages:

supertransball2 - Thrust type of game
supertransball2-data - data files for supertransball2

To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/supertransball2


Alternatively, one can download the package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/s/supertransball2/supertransball2_1.5-5.dsc


Changes since the last upload:

* New Maintainer. (Closes: #661457)
* Switch to package format 3.0 (quilt). Thanks Jari Aalto for the patch!
  (Closes: #668030).
* Remove patch for command line option -f for fullscreen, it does
  not work. Instead improve supertransball2's manpage and suggest using
  the ingame key combinations ALT+1,2,3,4 or ALT+ENTER to control the
  video mode. (Closes: #590636)
* Bump compat level to 9 and require debhelper =9 for automatic
  hardening build flags.
* Merge the old patches into one and modify the Makefile.
  Don't link against libsdl_sound anymore to avoid a superfluous
  dependency.
* debian/control:
- Add hardening wrapper to Build Depends.
- Add Vcs-fields and point to supertransball2's git repository at
  git.debian.org.
- Improve the package description.
* debian/rules:
- Use dh sequencer to simplify debian/rules.
- Split readme.txt in README and changelog and install them in the
  right place.
- Build with hardening=+all.
* Add a desktop file, menu file and icons.
* Update debian/copyright to copyright format 1.0.


  Regards,

   Markus Koschany



signature.asc
Description: OpenPGP digital signature

Bug#693249: RFS: etw/3.6+svn140-4 [RC] [ITA] arcade-style soccer game

[Markus Koschany]

I had to revert the part of the change which enabled saving and loading
of replays in the user's home directory because i have discovered another way to
trigger a segfault by pressing SPACE while watching a replay.

This feature is way too buggy at the moment. Instead i've updated 
README.Debian and explained why the replay function doesn't work.

Loading and saving of the configuration is working as intended and
should still be made available for wheezy.

Regards,

Markus


signature.asc
Description: Digital signature

Bug#693249: RFS: etw/3.6+svn140-4 [RC] [ITA] arcade-style soccer game

[Markus Koschany]

Package: sponsorship-requests
Severity: important 

Dear mentors,

I am looking for a sponsor for my package etw which i intend to adopt.
While i was preparing a new version i discovered that the configuration
can't be saved permanently. This impairs strongly the overall usability
of the game.

The first part of the patch restores the ability to load the
configuration from $HOME/.etw and to save options permanently.

The second part deals in a similar manner with the replay function.
From now on replays can be saved in $HOME/.etw. Unfortunately the replay
function suffers from another bug which is limited to the game's arcade
mode though. The game will segfault reproducibly if you try to view a replay
which was recorded while playing in arcade mode.
Other modes are not affected.


Package name: etw
Version : 3.6+svn140-4
Upstream Author : Gabriele Greco gabrielegr...@gmail.com
URL : http://www.ggsoft.org/etw/
License : GPL-2+
Section : games

It builds those binary packages:

etw   - arcade-style soccer game
etw-data   - graphics and audio data for etw

To access further information about this package, please visit the following 
URL:

http://mentors.debian.net/package/etw

and http://bugs.debian.org/693244


Alternatively, one can download the package with dget using this command:

dget -x http://mentors.debian.net/debian/pool/main/e/etw/etw_3.6+svn140-4.dsc


Changes since the last upload:

* New Maintainer. (Closes: #544922)
* Eat the Whistle will be maintained in a Git repository from now
  on. Change the Vcs-fields in debian/control accordingly.
* debian/patches: 
  Add 0005-Change-conf-and-replay-path.patch.
  Save and load configuration and replays in $HOME/.etw/ instead of
  /usr/share/games/etw and stop failing silently. (Closes: #693244)

Regards,

Markus Koschany



signature.asc
Description: Digital signature

Re: supertransball2 at mentors 2012-11-01 16:38

[Markus Koschany]

Hi Bart,

Thank you for reviewing supertransball2.

On 03.11.2012 20:52, Bart Martens wrote:
 I read that the license is GPL 2, but I don't read or (at your option) any
 later version.  Where did you read that ?

The author of supertransball2 himself speaks simply of GPL license in
the readme.txt file and at his homepage.

http://www.braingames.getput.com/stransball2/

Thus the old debian copyright file also talks about GNU GPL and links
to /usr/share/common-licenses/GPL where you can find the GPL-3 today.

In addition he also put a new file called license.txt, the GPL-3, into
the last source package at his homepage which was created in 2009. The
source code is identical to the one shipped with Debian hence i
concluded the original intention back in 2005 was to let the users
decide if they prefer GPL-2 or any later version of the license. Thus i
think GPL-2+ is the appropriate license.

 Why experimental and not unstable ?

I started a thread on debian-devel-games about the games i intend to adopt.

http://lists.debian.org/debian-devel-games/2012/10/msg00063.html

Then Paul Wise asked me to target them at experimental because of the
freeze.

http://lists.debian.org/debian-devel-games/2012/10/msg00066.html

 I'm not sure about merge the old patches into one.  Are you sure that this 
 is
 an improvement ?

Bluntly spoken, yes, although it might be just a matter of taste.

My reasoning is: There were 4 patches whereas patch 2-4 dealt with the
same path issue and patch 1 modified the Makefile. So they could have
been already combined.
If upstream was still active today i would prefer multiple patches true
to the motto One issue, one patch. In reality there haven't been any
signs of upstream development for seven years now, so it's reasonable to
conclude the patches are not upstreamable. They simply represent the
delta to the original sources.
I'm also using git + git-buildpackage for the packaging and keeping all
the changes in one patch by creating a patch-queue branch, commiting and
using gbp-export is the most efficient way for me and saves time.

 Why base the debian/watch file on stransball2-v15-windows.zip and not on
 stransball2-v15-source.zip ?

stransball2-v15-windows.zip is the last available archive at the
homepage which also includes the sources. All other links including
stransball2-v15-source.zip are broken.


Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#689692: RFS: byzanz/0.3.0+git20120930-1 [ITA]

[Markus Koschany]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package byzanz which i would like to
adopt. I am also interested in maintaining it in a git repository at
git.debian.org.

Package name: byzanz
Version : 0.3.0+git20120930-1
Upstream Author : Benjamin Otte o...@gnome.org
URL : http://git.gnome.org/browse/byzanz
License : GPL-3+, LGPL-3+, Public Domain
Section : graphics

It builds those binary packages:

byzanz - small screencast creator

To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/byzanz


Alternatively, one can download the package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/b/byzanz/byzanz_0.3.0+git20120930-1.dsc


Changes since the last upload:

  * New Maintainer. (Closes: #654614)
  * New Upstream git snapshot which adds various translations.
  * Switch to packaging format 3.0 (quilt).
  * Create patches instead of modifying the sources.
- Remove config.sub and config.guess and add them automatically with
  autotools-dev.
- Incorporate the last NMUs and create proper patches for them.
- Add patches from Jari Aalto again which were overwritten by the
  last NMUs.
  * debian/rules:
- Simplify debian/rules by using dh.
- Build with hardening+=all.
- Build with -Wl, --as-needed to avoid unnecessary dependencies.
  * debian/control:
- Add autotools-dev to Build-Depends.
- Homepage field: Point to the git repository because the old
  homepage does not exist anymore.
- Remove the VCS-field because it points to the upstream repository.
  (Closes: #685358)
- Description: Make clear that Byzanz is an applet and command line
  tool.
- New Standards-Version 3.9.4, no changes needed.
  * Bump compat level to 9.
  * Add a short introductory manpage for Byzanz which points to
byzanz-record and byzanz-playback. (Closes: #606673)
  * Improve README.Debian and make clear where you can find the panel
applet. Create examples in case you can only use the command line
tools.(Closes: #606676)
  * Fix the wrong command in byzanz-playback's synopsis.
(Closes: #641663)
  * Update debian/copyright to copyright format 1.0.
  * Update the license to GPL-3+, LGPL-3+ and Public Domain where
necessary.


Regards,
Markus Koschany



signature.asc
Description: OpenPGP digital signature

Bug#688310: RFS: wbar/2.3.4-1 [ITA] -- light and fast launch bar

[Markus Koschany]

On Mon, 24. Sep 06:07 Bart Martens ba...@debian.org wrote:
 Hi Markus,
 
 I have set the severity of bug 575087 (merged with 599083) to grave with a
 short explanation why.  Please consider fixing that bug for wheezy before
 packaging a newer upstream release in unstable.

Hi Bart,

thank you for your interest in wbar. I already targeted the new
version, 2.3.4, for experimental in case a RC bug would be filed against the
old version in Wheezy. 

I had a look at #575087 and #599083 again but unfortunately severity
grave would only be justified under one condition which is to demand
that a package should work out-of-the-box even if the recommended
packages were not installed.

I'm sure both bug reporters didn't install the recommended
gnome-extra-icons and the dustin font. If you install wbar the
recommended way then it works just fine.

But as Julien Valroff mentioned in the bug report [1], even if you had
installed wbar without recommended packages, it would be enough
to change the configuration and to point to an existing font.

Don't get me wrong, i'd love to see wbar 2.3.4 in wheezy because it
works with or without recommended packages out-of-the-box. Now the
configuration is much easier with wbar-config but it still appeals to advanced
users who care about efficient and lightweight software.

Thus said i'd be happy to fix the bug for wheezy because i agree the old
wbar version lacks a user friendly configuration, but i can only fix the
bug if 2.3.4. migrates to wheezy. 

Otherwise i suggest to lower the severity to important again because
wbar isn't unusable.

Regards,
Markus

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599083#10

 



signature.asc
Description: Digital signature

Bug#688310: RFS: wbar/2.3.3-1 [ITA] -- light and fast launch bar

[Markus Koschany]

Package: sponsorship-requests
Severity: normal 

Dear mentors,

I am looking for a sponsor for my package wbar which i would like to
adopt. 

Package name: wbar
Version : 2.3.3-1
Upstream Author : Rodolfo Granata warlock...@gmail.com,
  Yadickson Soto yadick...@gmail.com
URL : http://code.google.com/p/wbar
License : GPL3+
Section : x11

It builds those binary packages:

wbar  - light and fast launch bar
wbar-config - GUI tool to configure wbar

To access further information about this package, please visit the following 
URL:

http://mentors.debian.net/package/wbar


Alternatively, one can download the package with dget using this command:

dget -x http://mentors.debian.net/debian/pool/main/w/wbar/wbar_2.3.3-1.dsc

More information about wbar can be obtained from
http://bugs.debian.org/678865.

Most important changes since the last upload:

* New maintainer.
* Latest upstream release and first update since November 2009. 
* New GUI tool to customize wbar.
* License updated to GPL3+.
* Now wbar fully complies with the DFSG. No repack necessary. 
* Pristine source tarball.
* Package format 3.0, copyright format 1.0.
* Hardening, built with --as-needed. 
* New bash_completion snippet.
* New recommended packages to make wbar work out-of-the-box.

Regards,
Markus Koschany



signature.asc
Description: Digital signature

Bug#688122: RFS: sauerbraten-wake6/1.0-1.1 [RC] [NMU]

[Markus Koschany]

Package: sponsorship-requests
Severity: important 

  Dear mentors,

  I am looking for a sponsor for my package sauerbraten-wake6. The
  change is trivial and should only take a few seconds to review.

 * Package name: sauerbraten-wake6
   Version : 1.0-1.1
   Section : games

  It builds those binary packages:

sauerbraten-wake6 - Small but dodgy deathmatch/instagib map for the 
Sauerbraten game

  To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/sauerbraten-wake6


  Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/contrib/s/sauerbraten-wake6/sauerbraten-wake6_1.0-1.1.dsc

  Changes since the last upload:

Fixes invalid email address of the maintainer which is a policy
violation.

  Regards,
   Markus Koschany



signature.asc
Description: Digital signature

Bug#688126: RFS: textedit.app/4.0+20061029-3.4 [RC] [NMU]

[Markus Koschany]

Package: sponsorship-requests
Severity: important

Dear mentors,

  I am looking for a sponsor for my package textedit.app. The change
  is trivial and should only take a few seconds to review.

 * Package name: textedit.app
   Version : 4.0+20061029-3.4
   Section : editors

  It builds those binary packages:

textedit.app - Text editor for GNUstep

  To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/textedit.app


  Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/t/textedit.app/textedit.app_4.0+20061029-3.4.dsc


  Changes since the last upload:

Fix invalid email address of the maintainer which is a policy
violation.

  Regards,
   Markus Koschany



signature.asc
Description: Digital signature

Bug#688124: Subject: RFS: kic/2.4a-1.1 [RC] [NMU]

[Markus Koschany]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package kic. The change is trivial
and should only take a few seconds to review.

* Package name: kic
  Version : 2.4a-1.1
  Section : x11

It builds those binary packages:

kic   - Enhanced KIC layout editor

To access further information about this package, please visit the following 
URL:

http://mentors.debian.net/package/kic

http://bugs.debian.org/685959

Alternatively, one can download the package with dget using this command:

dget -x http://mentors.debian.net/debian/pool/non-free/k/kic/kic_2.4a-1.1.dsc

Changes since the last upload:

Fix invalid email address of the maintainer which is a policy
violation. 

Regards,
Markus Koschany




signature.asc
Description: Digital signature

Re: Advice on a new package

[Markus Koschany]

On 30.08.2012 21:33, Juhani Numminen wrote:
 2012/8/29 Boris Pek tehnic...@yandex.ru:
 The package has a Lintian warning: W: fortuner:
 hardening-no-fortify-functions usr/games/fortuner. How should that be
 treated?

 http://wiki.debian.org/Hardening

 Note: Lintian can generate false positive here. So you should check it 
 manually.
 
 I can't solve this myself, if you have knowledge of this subject
 please take a look.
 Looks like the build flags are already there, even if I'm not using
 anything flags-thing in debian/rules. However, I get the following
 results:
 
 $ hardening-check debian/fortuner/usr/games/fortuner
 debian/fortuner/usr/games/fortuner:
  Position Independent Executable: no, normal executable!
  Stack protected: yes
  Fortify Source functions: no, only unprotected functions found!
  Read-only relocations: yes
  Immediate binding: no, not found!


Hi Juhani,

i'm working on a debian package myself at the moment and i think the
recommended way to implement hardening is to use dpkg-buildflags.

http://wiki.debian.org/HardeningWalkthrough

In case you're using debhelper 9 (compat level 9) you can simply put a
line like this at the top of debian/rules

export DEB_BUILD_MAINT_OPTIONS = hardening=+all

Then you could also refrain from using

DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/buildflags.mk

CFLAGS += -Wextra

If you discover a lintian warning again, you can look up more
information for example at

http://lintian.debian.org/tags/hardening-no-fortify-functions.html

As Boris mentioned before lintian can produce false positives thus you
should investigate carefully again if hardening=+all isn't working as
intended.

Cheers
Markus



signature.asc
Description: OpenPGP digital signature