[aur-general] Corrected package ekeyd ready for AUR
Hello, I am using the entropy key from Simtec and I found the ekeyd package on AUR - unfortunately there are some problems with it, as outlined. Changes I have done to the original tarball: * Fixed the problem compiling with host/lstate.c. * Added a systemd unit egd-linux.service. Source package is attached for your review, guys, this is my very first one, so please bear with me... Regards Thomas -- www.preissler.co.uk | Twitter: @module0x90 | PGP-Key: 75889415 GPG Fingerprint: CCBD 153A D257 CA7E A217 FDF7 5928 03D1 7588 9415
----------------------------------------
Date: Fri, 13 Dec 2013 01:13:59 +0000 From: thomas@preissler.co.uk To: aur-general@archlinux.org Subject: [aur-general] Corrected package ekeyd ready for AUR
Hello,
I am using the entropy key from Simtec and I found the ekeyd package on AUR - unfortunately there are some problems with it, as outlined.
Changes I have done to the original tarball: * Fixed the problem compiling with host/lstate.c. * Added a systemd unit egd-linux.service.
Source package is attached for your review, guys, this is my very first one, so please bear with me...
Regards
Thomas
Patching/sed should be done in a separate prepare function. Does the make install need those _make_flags? If not, it would make more sense to not define a new variable, just include them in the make in the build function. For that matter, the _base_distro variable doesn't really do anything, but I can understand that so that it's easier to change. Please quote all path that contain $srcdir or $pkgdir. You don't know if they contain spaces or not. No reason to use "${srcdir}/../egd-linux.service", "${srcdir}/egd-linux.service" is just fine. Not a big deal, but the variable at the top are usually defined in a specific order. It works fine as is, just a little jarring. See https://wiki.archlinux.org/index.php/Pkgbuild
On Thu, Dec 12, 2013 at 09:29:43PM -0600, Doug Newgard wrote:
----------------------------------------
Date: Fri, 13 Dec 2013 01:13:59 +0000 From: thomas@preissler.co.uk To: aur-general@archlinux.org Subject: [aur-general] Corrected package ekeyd ready for AUR
Hello,
I am using the entropy key from Simtec and I found the ekeyd package on AUR - unfortunately there are some problems with it, as outlined.
Changes I have done to the original tarball: * Fixed the problem compiling with host/lstate.c. * Added a systemd unit egd-linux.service.
Source package is attached for your review, guys, this is my very first one, so please bear with me...
Regards
Thomas
Patching/sed should be done in a separate prepare function. Does the make install need those _make_flags? If not, it would make more sense to not define a new variable, just include them in the make in the build function. For that matter, the _base_distro variable doesn't really do anything, but I can understand that so that it's easier to change. Please quote all path that contain $srcdir or $pkgdir. You don't know if they contain spaces or not. No reason to use "${srcdir}/../egd-linux.service", "${srcdir}/egd-linux.service" is just fine. Not a big deal, but the variable at the top are usually defined in a specific order. It works fine as is, just a little jarring. See https://wiki.archlinux.org/index.php/Pkgbuild
Apologies for coming back so late... I picked this up again and I tried to fix it as per your suggestions. Thanks for these btw! My entropy key was before plugged into a Debian 7, and this system was runing ekeyd & egd-linux and my desktop with AL was running egd-linux, it was sort of running most of the time. Debian 7 is using LUA 5.1 btw. Now with my fw running AL (and LUA 5.2) I tried to get ekeyd running on it. Long story short, I couldn't get it to work. I am not sure now whether LUA 5.2 (the default on AL) was a problem as well, but I can test that again, if required. The biggest problem was that initializing the entropy key with ekey-rekey [...] was either just sitting there, or showing a "MAC timout" error. Last but not least I was thinking of contacting Simtec, the manufacturer of this key. I had a dive into their mailinglists entropykey-users and ektropykey-dev as listed on http://www.entropykey.co.uk/contact/, and I found two things: 1) The latest entry is from July 2013 2) and this entry is somebody complaining that they cannot be contacted, but with an answer that they have "some hardship right now". I just didn't want to let this hang here, half in the middle of it and let you guys know. Regards Thomas -- www.preissler.co.uk | Twitter: @module0x90 | PGP-Key: 75889415 GPG Fingerprint: CCBD 153A D257 CA7E A217 FDF7 5928 03D1 7588 9415
Am 10.02.2014 22:37, schrieb Thomas Preissler: [...]
My entropy key was before plugged into a Debian 7, and this system was runing ekeyd & egd-linux and my desktop with AL was running egd-linux, it was sort of running most of the time. Debian 7 is using LUA 5.1 btw.
Now with my fw running AL (and LUA 5.2) I tried to get ekeyd running on it. Long story short, I couldn't get it to work. I am not sure now whether LUA 5.2 (the default on AL) was a problem as well, but I can test that again, if required. The biggest problem was that initializing the entropy key with ekey-rekey [...] was either just sitting there, or showing a "MAC timout" error. [...] Why do you want to force the use of lua 5.2 at all? Lua 5.2 is not compatible with 5.1 in many places[1], because of that we have a 'lua51' package in the repositories. 'lua-socket' is also packaged for 5.1 and 5.2. After having a quick look at that tarball, I see that 'ekeyd-1.1.4/host/Makefile' explicitly uses lua 5.1 for the headers and should do for the libraries. If not, this can be fixed.
Please change the dep to lua51 and try to compile and use it again. It is impossible to do for most of us, because we do not have that special device. best regards, carstene1ns [1]: http://www.lua.org/manual/5.2/manual.html#8
On Tue, Feb 11, 2014 at 01:20:08PM +0100, carstene1ns wrote:
Please change the dep to lua51 and try to compile and use it again. It is impossible to do for most of us, because we do not have that special device.
I have made the modifications suggested by Doug and by yourself and the latest version is attached. I was not sure how I should put the patching the current maintainer is doing as part of build() function into a separate function. I tested it on a server, ie. ekeyd & egd-linux running, but also for a client with only the egd-linux running. So I provided now two .service files. Cheers Thomas -- www.preissler.co.uk | Twitter: @module0x90 | PGP-Key: 75889415 GPG Fingerprint: CCBD 153A D257 CA7E A217 FDF7 5928 03D1 7588 9415
Am 12.02.2014 01:28, schrieb Thomas Preissler:
I was not sure how I should put the patching the current maintainer is doing as part of build() function into a separate function. You can just move all the seds from your build() function to a prepare() function (and add the 'cd ...') https://wiki.archlinux.org/index.php/Creating_Packages#The_prepare.28.29_fun...
I tested it on a server, ie. ekeyd & egd-linux running, but also for a client with only the egd-linux running. So I provided now two .service files. Great! Now all that's left to do is to get the current maintainer to include the changes you made or orphan the package, so you can maintain it yourself.
best regards, carstene1ns
participants (3)
-
carstene1ns
-
Doug Newgard
-
Thomas Preissler