Hello, I had a look at your package. I would sponsor it but there are some issues we should fix before uploading. Some of them are upstream bugs but since you are upstream for jpeces, I think that should be doable. There are two issues which are really blocking bugs for me. 1. The program is configured to open your upstream URL on startup. Although this happens only once (or as long as .jpeces.configuracio.gz exists) it is quite surprising, if not a bit annoying. It could also be perceived as a privacy issue. It's completely ok to have this link in your help menu but it should not be forced on the user. 2. The help/documentation feature (F1) is not working because the ajuda directory is not installed. Ideally it should be installed into /usr/share/jpeces too because it is required to make a certain feature of your program work. You probably need to adjust your code and make it a bit more flexible because jpeces is looking for it in the current working directory at the moment. Other issues which could be fixed but are not critical (yet). There are some deprecation warnings like warning: [deprecation] Observable in java.util has been deprecated which are no problem with Java 9 now but will become a problem in the future. Bonus points if the preferences file jpeces.configuracio.gz would follow the XDG specification [1]. So ideally it would be stored into ~/.config/jpeces/. You could also use Java's Preferences feature but that's just an idea and not a blocker. Packaging issues ================ Removed the line about glpeces in the description because glpeces is a separate program and not part of jpeces. Standards-Version is 4.1.3 jpeces must depend on jarwrapper to enable binfmt support otherwise users can't launch the program. An alternative method to launch a Java application is to write a wrapper script. For instance you can take a look at mediathekview [2] that makes use of this technique. This requires a dependency on java-wrappers though. Build-Depends/Build-Depends-Indep: If you only build an arch:all binary package you can simplify d/control a little and move all build-dependencies to Build-Depends and remove the Build-Depends-Indep field. This field is only useful if you build arch:any and arch:all binary packages from the same source package and you need certain build-dependencies only for building the arch:all package. jpeces.desktop: The '' in your Exec field are superfluous and you can just write Exec=jpeces which is more generic and universal. Thus other distributions that install the binary into a different location don't need to patch your desktop file again. Keywords should be separated by semicolon, no spaces between words. logic game as a keyword is duplicating the Categories field, hence it also superfluous. Again the desktop-file-validate tool is quite helpful to spot such mistakes. A high resolution icon would be nice. I suggest not to compress the manual page and let the distributions do it for you. This makes it simpler to apply patches as well. For instance there are some typos which I couldn't fix that easily. s/tagram/tangram, s/where player/where the player/, s/The program have/The program contains/ debian/jpeces.manifest: There is a typo s/Main-class/Main-Class. I'm not sure if the JRE even cares about that but this will silence the Lintian error. You could also fix "debian-watch-could-verify-download" since you already provide the signing key in your package. I hope that helps a little Regards, Markus [1] https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html [2] https://anonscm.debian.org/cgit/collab-maint/mediathekview.git/tree/debian/bin/mediathekview
Attachment:
signature.asc
Description: OpenPGP digital signature