Package Details: nitrokey-app 1.3-4

Git Clone URL: (read-only)
Package Base: nitrokey-app
Description: Nitrokey management application
Upstream URL:
Keywords: crypto smartcard
Licenses: GPL3
Submitter: cjsthompson
Maintainer: milouse
Last Packager: milouse
Votes: 14
Popularity: 0.494590
First Submitted: 2015-02-12 07:56
Last Updated: 2018-06-04 16:33

Latest Comments

milouse commented on 2018-06-04 16:34

Fixed. Thank you very much for your investigation!

benoliver999 commented on 2018-06-04 15:45

Thanks for posting the issue on GH. The fix there works.

milouse commented on 2018-05-30 07:25

Hi jarred,

As qt 5.10 are not provided easily as package or in aur, I don't think it worth to pin it to 5.10 as new comers will be blocked too. I think this issue should be quickly fixed.

Can you create an upstream issue?

I don't know much Qt but it seems to be a naming problem, maybe easily fixed with compiler macro?

jarred commented on 2018-05-30 00:15

Qt5 has been bumped to 5.11. When trying to build against that version, I got the following error:

[ 50%] Building CXX object CMakeFiles/nitrokey-app.dir/src/ui/stick20changepassworddialog.cpp.o
nitrokey-app/src/nitrokey-app-1.3/src/ui/stick20changepassworddialog.cpp: In member function ‘void DialogChangePassword::moveWindowToCenter()’:
nitrokey-app/src/nitrokey-app-1.3/src/ui/stick20changepassworddialog.cpp:196:15: error: incomplete type ‘QStyle’ used in nested name specifier
       QStyle::alignedRect(Qt::LeftToRight, Qt::AlignCenter, size(), desktop->availableGeometry()));
make[2]: *** [CMakeFiles/nitrokey-app.dir/build.make:217: CMakeFiles/nitrokey-app.dir/src/ui/stick20changepassworddialog.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:68: CMakeFiles/nitrokey-app.dir/all] Error 2
make: *** [Makefile:152: all] Error 2
==> ERROR: A failure occurred in build().
Error making: nitrokey-app

I had to downgrade qt5-base, qt5-svg and qt5-tools to 5.10 to get this package to build. The Github project mentions it is tested against 5.9. Is it worth pinning those dependencies to 5.9?

Arvedui commented on 2018-04-24 16:06

Looks good to me too.

techge commented on 2018-04-24 09:22

Looks good to me!

milouse commented on 2018-04-24 08:20

Thank you very much Arvedui and techge for your help. Can you all confirm that it's ok now?

coderkun commented on 2018-04-23 21:08

Thanks for investigating, Arvedui. As workaround I built the package without chroot but would prefer to use a chroot properly, of course.

Arvedui commented on 2018-04-23 20:06

I believe I found the issue with building in a clean chroot.

The logpipe is deleted by an exit handler of makechrootpkg, which runs twice. First when the subshell that grep is running in terminates abnormal, because the grep fails and bash is setup to exit on any error. Second when the prepare function returns.

That the grep fails indicates that the entire for loop is obsolete, and indeed it builds without error (even in clean chroot) after removing the for loop in the prepare function.

techge commented on 2018-04-23 18:06

Thank you for fixing! I have tried the proposed change on #346. This indeed fix the icon problem. As far as I can see this will not fixed in 1.3 but in 1.4.

As next release will be in some month, you could add the following line in the meantime: 'sed -i '/qt5_add_resources/d' ./CMakeLists.txt' to the prepare() section (I did in line 29)?

milouse commented on 2018-04-23 08:32

The necessary files for qt-concurrent are in the qt5-base package, thus it's ok for that. I've added the qt5-svg dependency (I already have it as it's required by vlc, sorry to not have read seriously the release notes).

For the other problem (@coderkun I don't forget you, I promise), it'll take some times again, I'll to do my best to investigate them quickly.

techge commented on 2018-04-19 10:18

Could you please add qt5-svg as dependency? There was 'Qt Concurrent' added as well, but I have no idea what packages in Arch correspond to this one... (please see

Furthermore, it looks like we are affected of as well, aren't we? At least I get a bunch of warnings on terminal when starting nitrokey-app.

coderkun commented on 2018-04-17 11:27

@milouse, I use the Building in a Clean Chroot method and build the package with

$ makechrootpkg -c -r $CHROOT

milouse commented on 2018-04-17 11:03

coderkun: weird… there no such file in the source code. It may come from the way you made the clean chroot. Which tool do you use ?

coderkun commented on 2018-04-14 15:44

Trying to build version 1.3-1 in a clean chroot I get the following exception:

==> Starting prepare()...
rm: cannot remove '/logdest/logpipe.ZIOIZXVb': No such file or directory
==> ERROR: A failure occurred in prepare().

Is it working for anyone?

techge commented on 2018-03-18 11:52

It is the other way around. I have not seen any problem with the qt variant, but on the gtk variant of my DE. I have no idea if it has anything to do with it though. To be honest I am not sure if this is upstream either, but let's see what szszszsz will say.

I try to submit example screenshot on github tomorrow. I suggest we proceed with discussion on github for now, in case it is indeed upstream. Thanks for your help!!!

milouse commented on 2018-03-15 10:42

@techge I must admit I never had a QT environment at hand, and thus never test my package agaist one. On the other hand, one problem I didn't try to solve is that the nitrokey icon is always white, even on a very light background. Could your problem be just that? And you don't recognise the icon because of the very low contrast?

Can you provide us a screenshot of the problem? Can you test it against a big QT environment like KDE (to be sure it's not a LXQT only problem)?

But anyway, as I just follow upstream recommandation to build the app, it may be an upstream bug you should report there: May your problem be this one:

Thanks for reporting.

techge commented on 2018-03-15 09:06

The icon is missing on some platform (e. g. LXDE), but totally fine on other (e. g. LXQT). Is there may a GTK/QT issue? Did anyone else had the issue?

behaviour: App starts and is usable as always, but instead of the Nitrokey icon one can only see a white quadrat at system tray.

milouse commented on 2018-02-11 17:56

@awh: it seems you don't have the bash-completion package. I didn't know it was a needed dependency. Can you install it and say if it resolves your issues?

On the other hand, which version of libnitrokey-git are you using?

By the way, I've pushed today a new release, which use the stable libnitrokey version. Can you try to install it and notify me if something goes wrong?

awh commented on 2018-02-11 03:05

Getting the following error:

NitrokeyApp: Build type: Release
fatal: No names found, cannot describe anything.
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.2") 
-- Setting udev rules dir to lib/udev/rules.d
Package bash-completion was not found in the pkg-config search path.
Perhaps you should add the directory containing `bash-completion.pc'
to the PKG_CONFIG_PATH environment variable
No package 'bash-completion' found
-- Setting bash-completion dir to etc/bash_completion.d
-- Checking for one of the modules 'libnitrokey-1'
Using bundled libnitrokey
CMake Error at CMakeLists.txt:239 (add_subdirectory):
  The source directory


  does not contain a CMakeLists.txt file.

Am I missing something?

milouse commented on 2018-01-04 09:23

Yes, sorry I forgot my pinned comment :(

The last stable libnitrokey version does not easily permit its usage as a shared library, contrary to the git version. The problem mainly comes from the fact that the nitrokey app develop both the app and the lib as a whole, in two different repository, with the library as a submodule. Thus they compile it as a static dependancy, what I try to avoid.

Again, sorry for the confusion. It is possible that in a near future this package depends again on the stable version of the lib. Please note however, that this time you can easily upgrade both package without worrying about which package you must use (the nitrokey-app will be upgraded after libnitrokey and pull the correct version).

coderkun commented on 2018-01-03 17:07

@milouse, does this package depend on the git version of “libnitrokey” again?

coderkun commented on 2017-10-13 18:11

Thanks, @milouse. I have removed the old version and installed the new version including the non-git version of libnitrokey without any issues.

Feel free to reuse the binaries from

milouse commented on 2017-05-18 09:33

Nice catch. That was the case for the bash-completion script too. This last version is a big change compared to the previous version and the build chain changes a lot. Sorry for the inconvenience.

coderkun commented on 2017-05-17 11:22

Hey @milouse:
Since the update from 0.6 to 1.1 the udev rules file is not placed correctly:
nitrokey-app /usr/usr/
nitrokey-app /usr/usr/lib/
nitrokey-app /usr/usr/lib/udev/
nitrokey-app /usr/usr/lib/udev/rules.d/
nitrokey-app /usr/usr/lib/udev/rules.d/41-nitrokey.rules

The /usr folder is there twice.

coderkun commented on 2017-05-16 08:47

Everything builds fine now. Thanks a lot for the quick fix!

milouse commented on 2017-05-16 07:43

Yes, qt5-tools is a required dependancy. As I've it already on my machine, I did not see it. I'm testing if it's a runtime or just a build dependancy and will push the fix ASAP.

Thanks for reporting!

[Edit] Done

coderkun commented on 2017-05-16 07:27

I get the following error:
“CMake Warning at CMakeLists.txt:92 (find_package):
By not providing "FindQt5LinguistTools.cmake" in CMAKE_MODULE_PATH this
project has asked CMake to find a package configuration file provided by
"Qt5LinguistTools", but CMake did not find one.

Could not find a package configuration file provided by "Qt5LinguistTools"
with any of the following names:


Add the installation prefix of "Qt5LinguistTools" to CMAKE_PREFIX_PATH or
set "Qt5LinguistTools_DIR" to a directory containing one of the above
files. If "Qt5LinguistTools" provides a separate development package or
SDK, be sure it has been installed.

CMake Error at CMakeLists.txt:94 (qt5_create_translation):
Unknown CMake command "qt5_create_translation".”

Is any dependency missing?

coderkun commented on 2017-05-15 12:55

Version 1.1 is out:

Do you need any help updating the PKGBUILD?

milouse commented on 2017-03-26 17:47

I disagree with you, as nitrokey-app should be run only on userspace. It has nothing to do with systemd, at least on a system point of view. You are free to add your own service file in your profile (and start it as a --user service) or add a shortcut in your ~/.config/autostart folder (if you use mate, gnome, kde…).

This is not a packaging feature request, but more an upstream request. Feel free to ask them to add a mean to create a user service file or an autostart .desktop file.

lesto commented on 2017-03-25 01:32

@mis can you please add a service file for autostart? something like



shieldwed commented on 2016-11-15 22:30

@mis thank you very much for this update

Anonymous comment on 2016-11-14 15:18

This was orphaned so I applied your suggestions.
I don't use it and orphaned it again.

milouse commented on 2016-08-10 07:45


In fact, there is a problem with the naming of this package. As it fetch the last git revision, it must be called nitrokey-app-git [1]. Thus this package should either be renamed or build nitrokey-app from the last known release, in this case the v0.4 tag.

Also, you should remove the icon cache related lines from the nitrokey-app.install file as this is a process managed by hooks now.



zapper commented on 2016-08-10 01:10

When is this going to be updated?

LittleAlex commented on 2016-05-28 08:40


there is a HOTP-Bug in this version of Nitrokey-App.

Would be great if you update the package.

PS: Thanks for the package. :-)

cjsthompson commented on 2015-11-09 20:50

Thanks for the report. I've corrected it here. The fix is coming as soon as I get around to updating it.

millson249 commented on 2015-09-25 00:51

I'd recommend adding the cmake packages as a build dependency for this. For whatever reason I didn't have that installed and, naturally, the package failed to build. Fortunately it was an easy fix! But it might be wise to add it as a build dependency for anyone else who may not realize the issue.