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

Re: RFS: jpeces/4.2.1-1 [ITP]


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

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

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



[1] https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: