Bug#947143: RFS: wordpress/5.3.2+dfsg1-0.1 [NMU] [RC] -- weblog manager
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
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
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
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
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
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
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
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
Am 05.04.2017 um 22:28 schrieb Jeremy Bicha: > On Wed, Apr 5, 2017 at 3:44 PM, Markus Koschany 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
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]
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]
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]
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]
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 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]
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]
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]
Am 18.04.2016 um 02:15 schrieb Ben Finney: > Markus Koschany 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]
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: marked as done (RFS: corsix-th/0.50-1 ITP 610087 - A Theme Hospital engine reimplementation.)
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.
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: RFS: corsix-th/0.50-1 ITP 610087 - A Theme Hospital engine reimplementation.
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.
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.
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
Bug#807099: RFS: corsix-th/0.50-1 ITP 610087 - A Theme Hospital engine reimplementation.
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
Re: [jitsi-dev] Jitsi in Debian
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]
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
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
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
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 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 !
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]
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
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
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
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 expectati
Re: Bug#762228: RFS: ufoai-music review
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
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 copy&paste exercise without a real benefit. Markus signature.asc Description: OpenPGP digital signature
Re: Bug#762228: RFS: ufoai-music review
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
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 stat
Bug#762228: RFS: ufoai-music review
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: ufoai
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#759688: ufoai
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: RFS: ufoai/2.5-1 [ITP]
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]
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
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]
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]
On 29.10.2013 10:23, Andrew Shadura wrote: > Hello, > > On 29 October 2013 09:57, Markus Koschany 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#728181: RFS: tofrodos/1.7.13+ds-1 [ITA]
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#723142: RFS: dnt/0.10-1 [ITP]
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
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
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]
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]
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#695191: RFS: xarchiver/1:0.5.2+20090319+dfsg-4.1 [RC] [NMU]
On Wed, 05. Dec 17:13 Kartik Mistry wrote: > On Wed, Dec 5, 2012 at 1:56 PM, Markus Koschany 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]
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 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#693249: RFS: etw/3.6+svn140-4 [RC] [ITA] arcade-style soccer game
On Sun, 18. Nov 19:20 Michael Gilbert 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#693249: RFS: etw/3.6+svn140-4 [RC] [ITA] arcade-style soccer game
On Sat, 17. Nov 17:25 Michael Gilbert 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#693565: RFS: supertransball2/1.5-5 [ITA] -- Thrust type of game
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 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#693563: RFS: openyahtzee/1.9.1-2 [ITA] --classic dice game of Yahtzee
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 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#693249: RFS: etw/3.6+svn140-4 [RC] [ITA] arcade-style soccer game
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
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 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
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]
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 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
On Mon, 24. Sep 06:07 Bart Martens 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
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 , Yadickson Soto 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#688124: Subject: RFS: kic/2.4a-1.1 [RC] [NMU]
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
Bug#688126: RFS: textedit.app/4.0+20061029-3.4 [RC] [NMU]
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#688122: RFS: sauerbraten-wake6/1.0-1.1 [RC] [NMU]
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
Re: Advice on a new package
On 30.08.2012 21:33, Juhani Numminen wrote: > 2012/8/29 Boris Pek : >>> 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