Bug#764460: Bug#765179: RFS: yubikey-neo-manager/0.2.2-1 [ITP] -- YubiKey NEO management graphical user interface
On Sun, 2014-10-26 at 18:53 -0400, Harlan Lieberman-Berg wrote: 1. There are several generated files included as part of the tarball that really should be removed, if possible. The m4 stuff has several examples of generated files in it - aclocal.m4, several Makefile.in's, much of the content in ./build-aux (depcomp, config.sub, ar-lib, test-driver, among others). If you could go through and remove these generated files, it's preferable. As much as possible, the upstream source should be kept clean and files regenerated as needed. (See https://wiki.debian.org/UpstreamGuide#Generated_files for more information). The upstream tarball (but *not* the upstream git repo) is expected to contain autotools cruft for packages using autotools so this is fine. However, the Debian package should use dh-autoreconf to rebuild and or update them from their canonical sources in autoconf/automake/etc. 2. In a similar vein, the documentation u2f-host.pdf should be regenerated at build time, rather than the pdf be included. If it can be removed from the upstream tarball, that would be preferable, but if not, it should be regenerated at build-time in the debian/rules. Indeed. You can add a second download for the prebuilt docs. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#764460: Bug#765179: RFS: yubikey-neo-manager/0.2.2-1 [ITP] -- YubiKey NEO management graphical user interface
On Thu, 2014-10-23 at 22:31 -0400, Harlan Lieberman-Berg wrote: Glad to help! I'll take a look at this tonight, and I'll send both of you two emails separately, CCed to the particular bugs. Hello! Thanks for packaging libu2f-host for Debian! Sorry for the delay in the review; I had family visiting that took up more time than I thought it would. Took a look over the package, and there are a couple things that need fixing - some as upstream, and some as packaging for Debian. 1. There are several generated files included as part of the tarball that really should be removed, if possible. The m4 stuff has several examples of generated files in it - aclocal.m4, several Makefile.in's, much of the content in ./build-aux (depcomp, config.sub, ar-lib, test-driver, among others). If you could go through and remove these generated files, it's preferable. As much as possible, the upstream source should be kept clean and files regenerated as needed. (See https://wiki.debian.org/UpstreamGuide#Generated_files for more information). 2. In a similar vein, the documentation u2f-host.pdf should be regenerated at build time, rather than the pdf be included. If it can be removed from the upstream tarball, that would be preferable, but if not, it should be regenerated at build-time in the debian/rules. 3. The watchfile is currently not working because the link it is scraping is returning a 500 error. Other than that, the package looks pretty good! Let me know when you've made the above fixes, and I'll take another look through it - quicker, next time, I hope! Sincerely, -- Harlan Lieberman-Berg ~hlieberman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765179: RFS: yubikey-neo-manager/0.2.2-1 [ITP] -- YubiKey NEO management graphical user interface
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 signature.asc Description: This is a digitally signed message part
Bug#765179: RFS: yubikey-neo-manager/0.2.2-1 [ITP] -- YubiKey NEO management graphical user interface
I have uploaded a new version of the package to mentors incorporating the changes mentioned below. There is one remaining blocker for this package entering Debian: The libu2f-host0 package is not yet in Debian. 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 Re icons, larger non-XPM ones (including SVG) should be installed in /usr/share/icons/hicolor/widthxheight/apps: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout 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). Some other things you might want to fix: I like to wrap debian/*.menu files at one attribute per line to make diffs more readable. Agreed, done. I like to run wrap-and-sort -sa to wrap the other debian/* files in the same way for the same reason. Didn't know about that tool, thanks for pointer. Ran it without -s though. I think the Priority should be optional rather than extra. Done. I would recommend debian/compat 9 and debhelper 9. Done. The license for neoman/libloader.py seems to be BSD-3-clause not BSD-2-clause? Done. The multiarch handling in neoman/libloader.py is incorrect, it should not hard-code the paths for amd64 and i386, Debian has other 64-bit and 32-bit ports plus the non-Linux ports. The neoman/libloader.py looks at /etc/ld.so.conf but that won't work on multi-arch systems becase /etc/ld.so.conf just includes /etc/ld.so.conf/*.conf and contains no dirs. 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. The manual page, desktop file and icon(s) should be installed by the upstream build system. PNG might be a better choice for the icons since it provides 8-bit transparency instead of 1-bit transparency. They seem to be PNG's in 0.2.3. Dain, can you install them? These files look like they were generated from other files, I would suggest removing them from the VCS and tarballs and creating them at build time if possible: resources/installer_bg.png resources/neoman.icns resources/neoman.ico resources/neoman.xpm debian/neoman.xpm neoman/neoman.png 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? 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. Are the files listed in neoman/appletdb.json Free Software? Are they required for operation of yubikey-neo-manager? ykneo-oath and ykneo-openpgp are free software, but they are not required for operation and most people will not want or need them. The upstream signing key uses SHA1 for the self-sig, it should be re-signed with a SHA512 self-sig: https://help.riseup.net/en/security/message-security/openpgp/best-practices#self-signatures-should-not-use-sha1 Leave this to Dain :-) uscan doesn't like the upstream signing key unless I move it to debian/upstream/signing-key.asc (see below). Dain? The cowbuilder parts of debian/README.source do not look necessary, lots of folks use sbuild and the cowbuilder docs cover what is mentioned in debian/README.source. Yeah, it is mostly an example and reminder for the people working with the packaging. os.system (in release.py) should be replaced by use of the subprocess module (with shell=False). Upstream issue -- Dain? Automated checks: Nice, will take a further looks later. /Simon https://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git $ lintian W: yubikey-neo-manager: image-file-in-usr-lib usr/lib/python2.7/dist-packages/neoman/icon-about.png W: yubikey-neo-manager: image-file-in-usr-lib usr/lib/python2.7/dist-packages/neoman/icon_installed.png W: yubikey-neo-manager: image-file-in-usr-lib usr/lib/python2.7/dist-packages/neoman/icon_not_installed.png W: yubikey-neo-manager: image-file-in-usr-lib usr/lib/python2.7/dist-packages/neoman/icon_some_installed.png W: yubikey-neo-manager: image-file-in-usr-lib usr/lib/python2.7/dist-packages/neoman/neoman.png E: yubikey-neo-manager: menu-icon-too-big usr/share/pixmaps/neoman.xpm: 128x128 32x32 $ uscan --download-current-version --verbose --destdir . ... -- Verifying OpenPGP signature yubikey-neo-manager-0.2.2.tar.gz.pgp for yubikey-neo-manager-0.2.2.tar.gz gpgv: Signature made Fri 26 Sep 2014 19:52:37 AWST using RSA key ID 6FBA95E8 gpgv: [don't know]: invalid
Bug#765179: RFS: yubikey-neo-manager/0.2.2-1 [ITP] -- YubiKey NEO management graphical user interface
Chiming in on some of the issues below. *Dain Nilsson* Senior Software Developer, Yubico d...@yubico.com yubico.com On Wed, Oct 15, 2014 at 11:54 AM, Simon Josefsson si...@josefsson.org wrote: I have uploaded a new version of the package to mentors incorporating the changes mentioned below. There is one remaining blocker for this package entering Debian: The libu2f-host0 package is not yet in Debian. 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 Re icons, larger non-XPM ones (including SVG) should be installed in /usr/share/icons/hicolor/widthxheight/apps: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout 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). This sounds fine, I think placing the files in the correct location for the Debian package is best. Some other things you might want to fix: I like to wrap debian/*.menu files at one attribute per line to make diffs more readable. Agreed, done. I like to run wrap-and-sort -sa to wrap the other debian/* files in the same way for the same reason. Didn't know about that tool, thanks for pointer. Ran it without -s though. I think the Priority should be optional rather than extra. Done. I would recommend debian/compat 9 and debhelper 9. Done. The license for neoman/libloader.py seems to be BSD-3-clause not BSD-2-clause? Done. The multiarch handling in neoman/libloader.py is incorrect, it should not hard-code the paths for amd64 and i386, Debian has other 64-bit and 32-bit ports plus the non-Linux ports. The neoman/libloader.py looks at /etc/ld.so.conf but that won't work on multi-arch systems becase /etc/ld.so.conf just includes /etc/ld.so.conf/*.conf and contains no dirs. 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. 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. The manual page, desktop file and icon(s) should be installed by the upstream build system. PNG might be a better choice for the icons since it provides 8-bit transparency instead of 1-bit transparency. They seem to be PNG's in 0.2.3. Dain, can you install them? 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. These files look like they were generated from other files, I would suggest removing them from the VCS and tarballs and creating them at build time if possible: resources/installer_bg.png resources/neoman.icns resources/neoman.ico resources/neoman.xpm debian/neoman.xpm neoman/neoman.png 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? debian/neoman.xpm and neoman/neoman.png have already been removed in 0.2.3. All of the resources/* files are manually created. 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. Are the files listed in neoman/appletdb.json Free Software? Are they required for operation of yubikey-neo-manager? ykneo-oath and ykneo-openpgp are free software, but they are not required for operation and most people will not want or need them. The upstream signing key uses SHA1 for the self-sig, it should be re-signed with a SHA512 self-sig: https://help.riseup.net/en/security/message-security/openpgp/best-practices#self-signatures-should-not-use-sha1 Leave this to Dain :-) uscan doesn't like the upstream signing key unless I move it to debian/upstream/signing-key.asc (see below). Dain? The cowbuilder parts of debian/README.source do not look necessary, lots of folks use sbuild and the cowbuilder docs cover what is mentioned in debian/README.source. Yeah, it is mostly an example and reminder for the people working with the packaging. os.system (in release.py) should be replaced by use of the subprocess module
Bug#765179: RFS: yubikey-neo-manager/0.2.2-1 [ITP] -- YubiKey NEO management graphical user interface
I'm resolving the issue of pixmaps in /usr/lib, as well as replacing the
menuicon with one that is 32x32 as we speak. It looks bad when I test it on
Ubuntu (which uses 48x48), but it seems Ubuntu has an app-install-data
package with higher res icons for all of the included packages, so we can
worry about that later I suppose.
*Dain Nilsson*
Senior Software Developer, Yubico
d...@yubico.com
yubico.com
On Tue, Oct 14, 2014 at 11:54 AM, Simon Josefsson si...@josefsson.org
wrote:
On Mon, 2014-10-13 at 21:35 +0200, Simon Josefsson wrote:
Dear mentors,
I am looking for a sponsor for our package yubikey-neo-manager:
Hello Simon!
Thank you for your help in packaging the yubikey neo manager for
Debian! I've got a few things that might need fixing up for you to
take a look at.
Thank you! Cc'ing Dain who has wrote the project.
- The file neoman/libloader has a different copyright than the rest of
the code, both in license and copyright holder. It needs to be
specified in d/copyright
Good catch! Dain, is it needed? I added it to debian/copyright
meanwhile.
- Do you want debian/* to be copyrighted by Yubico, or should it be
copyrighted by you? (This may or may not be a question for legal
counsel.)
Having debian/* be owned by Yubico is fine, we are the same group of
people working on both upstream and the packaging, and all are bound to
Yubico.
- There are several pixmap files being installed under /usr/lib;
architecture independent files should be installed under /usr/share.
- Icons in the Debian menu system should be 32x32 at the largest -
the /usr/share/pixmap/neoman.xpm, file is 128x128.
Yep, we are trying to figure these two out -- do you happen to know how
to get high-res menu icons? 32x32 is really crappy, and there ought to
be a way to provide a better image.
- There is a substitution variable ${python:Provides}, but there
isn't a substitution variable for that. What are you trying to get
from that?
Likely cut'n'paste issue, I dropped it.
I have built and uploaded a new version to mentors.
Thanks, again, for packaging these tools. I have a NEO on my
keychain, so this definitely caught my eye!
Glad to hear that :-) Btw, are you a DD? If you would be willing to
sponsor this, that would be appreciated.
/Simon
Bug#765179: RFS: yubikey-neo-manager/0.2.2-1 [ITP] -- YubiKey NEO management graphical user interface
On Mon, 2014-10-13 at 21:35 +0200, Simon Josefsson wrote:
Dear mentors,
I am looking for a sponsor for our package yubikey-neo-manager:
Hello Simon!
Thank you for your help in packaging the yubikey neo manager for
Debian! I've got a few things that might need fixing up for you to
take a look at.
Thank you! Cc'ing Dain who has wrote the project.
- The file neoman/libloader has a different copyright than the rest of
the code, both in license and copyright holder. It needs to be
specified in d/copyright
Good catch! Dain, is it needed? I added it to debian/copyright
meanwhile.
- Do you want debian/* to be copyrighted by Yubico, or should it be
copyrighted by you? (This may or may not be a question for legal
counsel.)
Having debian/* be owned by Yubico is fine, we are the same group of
people working on both upstream and the packaging, and all are bound to
Yubico.
- There are several pixmap files being installed under /usr/lib;
architecture independent files should be installed under /usr/share.
- Icons in the Debian menu system should be 32x32 at the largest -
the /usr/share/pixmap/neoman.xpm, file is 128x128.
Yep, we are trying to figure these two out -- do you happen to know how
to get high-res menu icons? 32x32 is really crappy, and there ought to
be a way to provide a better image.
- There is a substitution variable ${python:Provides}, but there
isn't a substitution variable for that. What are you trying to get
from that?
Likely cut'n'paste issue, I dropped it.
I have built and uploaded a new version to mentors.
Thanks, again, for packaging these tools. I have a NEO on my
keychain, so this definitely caught my eye!
Glad to hear that :-) Btw, are you a DD? If you would be willing to
sponsor this, that would be appreciated.
/Simon
signature.asc
Description: PGP signature
Bug#765179: RFS: yubikey-neo-manager/0.2.2-1 [ITP] -- YubiKey NEO management graphical user interface
On Tue, Oct 14, 2014 at 8:50 AM, Harlan Lieberman-Berg wrote:
On Mon, 2014-10-13 at 21:35 +0200, Simon Josefsson wrote:
Dear mentors,
I am looking for a sponsor for our package yubikey-neo-manager:
Thank you for your help in packaging the yubikey neo manager for Debian!
I've got a few things that might need fixing up for you to take a look
at.
Good review Harlan.
There is one remaining blocker for this package entering Debian:
The libu2f-host0 package is not yet in Debian.
Re icons, larger non-XPM ones (including SVG) should be installed in
/usr/share/icons/hicolor/widthxheight/apps:
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout
Some other things you might want to fix:
I like to wrap debian/*.menu files at one attribute per line to make
diffs more readable.
I like to run wrap-and-sort -sa to wrap the other debian/* files in
the same way for the same reason.
I think the Priority should be optional rather than extra.
I would recommend debian/compat 9 and debhelper 9.
The license for neoman/libloader.py seems to be BSD-3-clause not BSD-2-clause?
The multiarch handling in neoman/libloader.py is incorrect, it should
not hard-code the paths for amd64 and i386, Debian has other 64-bit
and 32-bit ports plus the non-Linux ports.
The neoman/libloader.py looks at /etc/ld.so.conf but that won't work
on multi-arch systems becase /etc/ld.so.conf just includes
/etc/ld.so.conf/*.conf and contains no dirs.
The manual page, desktop file and icon(s) should be installed by the
upstream build system. PNG might be a better choice for the icons
since it provides 8-bit transparency instead of 1-bit transparency.
These files look like they were generated from other files, I would
suggest removing them from the VCS and tarballs and creating them at
build time if possible:
resources/installer_bg.png
resources/neoman.icns
resources/neoman.ico
resources/neoman.xpm
debian/neoman.xpm
neoman/neoman.png
DEFAULT_KEY does not look like something that should be included?
Are the files listed in neoman/appletdb.json Free Software? Are they
required for operation of yubikey-neo-manager?
The upstream signing key uses SHA1 for the self-sig, it should be
re-signed with a SHA512 self-sig:
https://help.riseup.net/en/security/message-security/openpgp/best-practices#self-signatures-should-not-use-sha1
uscan doesn't like the upstream signing key unless I move it to
debian/upstream/signing-key.asc (see below).
The cowbuilder parts of debian/README.source do not look necessary,
lots of folks use sbuild and the cowbuilder docs cover what is
mentioned in debian/README.source.
os.system (in release.py) should be replaced by use of the subprocess
module (with shell=False).
Automated checks:
https://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package
https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git
$ lintian
W: yubikey-neo-manager: image-file-in-usr-lib
usr/lib/python2.7/dist-packages/neoman/icon-about.png
W: yubikey-neo-manager: image-file-in-usr-lib
usr/lib/python2.7/dist-packages/neoman/icon_installed.png
W: yubikey-neo-manager: image-file-in-usr-lib
usr/lib/python2.7/dist-packages/neoman/icon_not_installed.png
W: yubikey-neo-manager: image-file-in-usr-lib
usr/lib/python2.7/dist-packages/neoman/icon_some_installed.png
W: yubikey-neo-manager: image-file-in-usr-lib
usr/lib/python2.7/dist-packages/neoman/neoman.png
E: yubikey-neo-manager: menu-icon-too-big
usr/share/pixmaps/neoman.xpm: 128x128 32x32
$ uscan --download-current-version --verbose --destdir .
...
-- Verifying OpenPGP signature yubikey-neo-manager-0.2.2.tar.gz.pgp
for yubikey-neo-manager-0.2.2.tar.gz
gpgv: Signature made Fri 26 Sep 2014 19:52:37 AWST using RSA key ID 6FBA95E8
gpgv: [don't know]: invalid packet (ctb=2d)
gpgv: keydb_search failed: invalid packet
gpgv: Can't check signature: public key not found
uscan warning: OpenPGP signature did not verify.
$ codespell --quiet-level=3
./ChangeLog:758: persistant == persistent
$ find -type f -iname '*.desktop' -exec desktop-file-validate {} \;
./resources/neoman.desktop: error: value YubiKey;NEO;Manager for
locale string list key Keywords in group Desktop Entry does not
have a semicolon (';') as trailing character
./debian/neoman.desktop: error: value YubiKey;NEO;Manager for locale
string list key Keywords in group Desktop Entry does not have a
semicolon (';') as trailing character
$ pep8 --ignore W191 .
./neoman/device_ccid.py:34:40: W601 .has_key() is deprecated, use 'in'
./neoman/device_ccid.py:103:34: E128 continuation line under-indented
for visual indent
./neoman/device_ccid.py:106:5: E265 block comment should start with '# '
./neoman/device_ccid.py:123:80: E501 line too long (80 79 characters)
./neoman/device_ccid.py:128:80: E501 line too long (82 79 characters)
./neoman/device_u2f.py:41:36: W601 .has_key() is deprecated, use 'in'
./neoman/device_u2f.py:84:9: E265 block comment should start with '# '
Bug#765179: RFS: yubikey-neo-manager/0.2.2-1 [ITP] -- YubiKey NEO management graphical user interface
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for our package yubikey-neo-manager: * Package name: yubikey-neo-manager Version : 0.2.2-1 Upstream Author : Dain Nilsson d...@yubico.com * URL : https://developers.yubico.com/yubikey-neo-manager/ * License : BSD-2-clause Section : utils It builds these binary packages: yubikey-neo-manager -- YubiKey NEO management graphical user interface To access further information about this package, please visit the following URL: http://mentors.debian.net/package/yubikey-neo-manager Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/y/yubikey-neo-manager/yubikey-neo-manager_0.2.2-1.dsc I'm happy to maintain the package for Debian. /Simon signature.asc Description: PGP signature
Bug#765179: RFS: yubikey-neo-manager/0.2.2-1 [ITP] -- YubiKey NEO management graphical user interface
On Mon, 2014-10-13 at 21:35 +0200, Simon Josefsson wrote:
Dear mentors,
I am looking for a sponsor for our package yubikey-neo-manager:
Hello Simon!
Thank you for your help in packaging the yubikey neo manager for Debian!
I've got a few things that might need fixing up for you to take a look
at.
- The file neoman/libloader has a different copyright than the rest of
the code, both in license and copyright holder. It needs to be
specified in d/copyright
- Do you want debian/* to be copyrighted by Yubico, or should it be
copyrighted by you? (This may or may not be a question for legal
counsel.)
- There are several pixmap files being installed under /usr/lib;
architecture independent files should be installed under /usr/share.
- Icons in the Debian menu system should be 32x32 at the largest -
the /usr/share/pixmap/neoman.xpm, file is 128x128.
- There is a substitution variable ${python:Provides}, but there isn't
a substitution variable for that. What are you trying to get from that?
Thanks, again, for packaging these tools. I have a NEO on my keychain,
so this definitely caught my eye!
Sincerely,
--
Harlan Lieberman-Berg
~hlieberman
signature.asc
Description: This is a digitally signed message part
