Created attachment 333180 [details, diff] cryptkeeper-0.9.5-r1.ebuild.diff Since "test" fails with cryptkeeper 0.9.5 because of an upstream error, I am uploading a new revision of the ebuild + the necessary patch fixing the issue. All the other patches are the same as in the ebuild 0.9.5 (see bug #245461). I will notify the upstream author too (and post the link to the upstream report).
Created attachment 333182 [details, diff] cryptkeeper-0.9.5-unit_tests.patch This is the actual patch fixing the "test" (unit_test) issue.
Here is the upstream bug report: https://github.com/tomm/cryptkeeper/issues/13
Hmm these addwrites there look a bit dangerous. We also don't need IUSE="test". This is in case you want to pull extra deps for tests in {R,}DEPEND. Also all these einfos maybe create too much noise but anyway this is a minor issue. Also, I see no reason to define your own emake_cmd command. First you pass it MAKEOPTS and then you overwrite that with -j1. I think "emake -j1" is pretty much the same. But the most important think that bugs me are these addwrites.
Yeah.. as we all know any addwrite could be dangerous and should be avoided or at least an addpredict should be used. The problem is that cryptkeeper (actually the encfs) uses fuse for all its actions, so in order the tests to be able to run a RW access to /dev/fuse is needed - this access is the default access to /dev/fuse for any system user, so this is not at all a problem. The second addwrite to /etc/mtab is a limitation because of fusermount which has some problems with /etc/mtab and if run by root needs a RW access, so it can lock it in order other concurrent fuse processes not to make a mess. The whole subroutine in fusermount.c (fuse project) is being worked on this problem but still it is not fixed well. I do not see any problem in allowing write to /etc/mtab anyway, since i've gone through all the code in unit_tests.cpp and the encfs_wrapper.cpp/.h and they do not do anything wrong with /etc/mtab... So the problem is in fusermount that requires it. A possible solution is to use: addread /etc/mtab but that means test should be run under "userpriv" or it will fail because it will not be able to get a lock on mtab. I do not like this kinda solution, 'cause it requires the user to take extra actions for a very simple test... Besides under "userpriv" there is a problem with libsandbox too (it is ignorable) and according to sandbox dev is just a debug ignorable problem... About the own emake_cmd... it is not exactly the same as emake -j1 .. I just add the MAKEOPTS without the EXTRA_EMAKE env variable... as far as overwriting MAKEOPTS, they can contain other options too (not only the -j one)... In fact it is a kinda insurance for future upstream code changes... Anyway it is totally optional and a pure "make" could be used also... I agree with the IUSE=test, but again I put it there for future ease if upstream code changes and requires some additional deps for the tests... As a whole if you ask me the "test" feature is totally unneeded in the ebuild, except in cases where devs need to be sure it works under a certain platform when they add new platforms/keywords. So a simple restrict of test is ok but since you asked me in bug #245461 to fix the test problem i did it... it is up to you if you will add it to portage :)
I see, anyway I will wait a bit to see how the upstream bug report goes and then I will drop the test use flag and the custom emake command and commit it.
looks like there hasn't been any response on the github bug.
commit 0625e74f6445ed4dfac4c91eb92c851dbbcccd4c Author: Michał Górny <mgorny@gentoo.org> AuthorDate: Sun Mar 12 22:22:08 2017 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: Sun Mar 12 22:24:49 2017 app-crypt/cryptkeeper: Remove last-rited pkg, #607772
