On Wed, 2014-10-15 at 11:54 +0200, Simon Josefsson wrote: > I'd love for you two to put your review cycles into it: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764262 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764460 My recent reviews have been to test Harlan's ability to review packages. If he wants to review this one too, I can check his review again. > Thanks -- we are trying to sort this out, either we do something in the > Debian packaging or we do it upstream -- but the latter requires some > thinking since the package is cross-platform (Windows, Mac, GNU). Generally icons are done upstream. > No idea how to resolve this -- I suppose libloader.py is some external > file we copie in, maybe there are Debian-ified versions of it. Dain? > Not sure why this package have to hardcode or read ld.so.conf at > all. It is dynamically loading shared libraries, seems to need to know where to find those libraries.. > It is common to ship generated files in tarballs, to avoid forcing > users to have a lot of tools available. Agree with removing them from > git though, Dain? Users generally use binary packages, not source packages. Anyone willing to work with the source should be willing to install the relevant tools. > > DEFAULT_KEY does not look like something that should be included? > > Why not? Earlier NEOs had that key as the default (it is the common > Visa/Mastercard standard key), although modern NEOs have randomized > keys. It wasn't clear to me if this was an example key or a private key or what. Having every device contain the same private key seems bad, I wonder if it would be a good idea to recall these devices and replace them with ones containing random keys. > ykneo-oath and ykneo-openpgp are free software, but they are not > required for operation and most people will not want or need them. Is it possible to build them using OpenJDK? I took a look and the Java Card stuff seems to be proprietary. > Yeah, it is mostly an example and reminder for the people working with > the packaging. Fair enough. On Wed, 2014-10-15 at 14:17 +0200, Dain Nilsson wrote: > Yes, this code is copied from an external source, I'm not entirely > sure why it does some things it does, but it seems to work pretty well > and I'm not sure we have the resources to be testing this on a vast > number of different distros, so I've refrained from making any changes > to this file. I'll open an issue for the upstream package regarding > this. If libloader.py is unmodified, it might be best to package that separately, which upstream does it come from? > The menu icon is XPM now, I thought Debian required these to be XPM? > If not then I agree that PNG is better. As for the upstream build > system installing the man page, .desktop file and icons, I'm not sure > the upstream build system has a good way of doing this. I'll open > another issue for this nonetheless. In Debian there are two menu systems: The Debian menu, it requires XPM and is not shown by most desktops in Debian. It is the older of the two menu systems and Debian-specific. The Freedesktop menu, it allows PNG, XPM, SVG and is shown by modern desktops in Debian but not window managers and older things. It is the newer of the two menu systems and is cross-distro. > Other than subprocess being newer there's no real reason not to use > os.system, but then again, there's no reason not so use it, so I'll > open an issue for this as well. subprocess isn't vulnerable to shell metacharacter injection attacks, os.system (and other things in python) is because it uses a shell. http://bonedaddy.net/pabs3/log/2014/02/17/pid-preservation-society/ -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part