Description of problem: The postin-scriptlet of the openni rpm seems broken: ... Installing : openni-1.5.7.10-3.fc22.x86_64 4/4 Failed: Failed to write to the file! Failed: Failed to write to the file! Failed: Failed to write to the file! warning: %post(openni-1.5.7.10-3.fc22.x86_64) scriptlet failed, exit status 255 Non-fatal POSTIN scriptlet failure in rpm package openni-1.5.7.10-3.fc22.x86_64 ... Version-Release number of selected component (if applicable): openni-1.5.7.10-3.fc22 How reproducible: Always Steps to Reproduce: 1. mock -r fedora-rawhide-x86_64 --init 2. mock -r fedora-rawhide-x86_64 --install openni Actual results: cf. above. Expected results: Function. Additional info: f20 (openni-1.3.x) doesn't seem to be affected. f21 and above (openni-1.5.x) are.
Apparent cause is niReg trying to write to /etc/ni/modules.xml inside of the scriptlet, which fails because the directory /etc/ni doesn't exist: # rpm -q --scripts openni postinstall scriptlet (using /bin/sh): /sbin/ldconfig if [ $1 == 1 ]; then niReg -r /usr/lib64/libnimMockNodes.so niReg -r /usr/lib64/libnimCodecs.so niReg -r /usr/lib64/libnimRecorder.so fi => openni should provide the directory /etc/ni and own /etc/ni/modules.xml (Likely an empty and %ghosted) such that this package installs cleanly. Another question would be, whether /etc/ni/ is an appropriate location for such a "registry". Likely it should be /var/lib/ni or something similar, because files under /etc are supposed to be config-files, which in my understanding modules.xml isn't.
Thanks for the report. I agree that this should be in /var/lib and not /etc. I think it was like this before, I probably messed up backporting the patches when I updated openni to the latest upstream version. I'll work on moving modules.xml to /var/lib/, and making sure the rpm ownership is correct.
(In reply to Rich Mattes from comment #2) > Thanks for the report. I agree that this should be in /var/lib and not > /etc. I think it was like this before, I probably messed up backporting the > patches when I updated openni to the latest upstream version. I am inclined to agree ;) Upon closer inspection, I believe the LINUX-related snippet from openni-1.5.7.10-willow.patch is wrong: ... diff -up ./Source/OpenNI/XnOpenNI.cpp.willow ./Source/OpenNI/XnOpenNI.cpp --- ./Source/OpenNI/XnOpenNI.cpp.willow 2013-11-12 11:30:03.000000000 -0500 +++ ./Source/OpenNI/XnOpenNI.cpp 2014-06-01 18:16:31.326206324 -0400 @@ -7070,9 +7070,9 @@ XN_C_API XnStatus xnScriptNodeRun(XnNode #if (XN_PLATFORM == XN_PLATFORM_WIN32)M #define XN_OPEN_NI_FILES_LOCATION "\\Data\\"M #elif (CE4100)M - #define XN_OPEN_NI_FILES_LOCATION "/usr/etc/ni/"M + #define XN_OPEN_NI_FILES_LOCATION "/etc/ni/"M #elif (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_MACOSX)M - #define XN_OPEN_NI_FILES_LOCATION "/var/lib/ni/"M + #define XN_OPEN_NI_FILES_LOCATION "/etc/ni/"M #elif (XN_PLATFORM == XN_PLATFORM_ANDROID_ARM)M /* Resolved dynamically in Android */M #elseM ... AFAIU, it seems to change the registry's location from using "/var/lib/ni" to "/etc/ni".
Created attachment 976198 [details] Proposed patch, addressing what I outlined in previous comment
*** Bug 1131422 has been marked as a duplicate of this bug. ***
Thanks for the patch Ralf. I've applied it and changed modules.xml to be ghosted rather than be a config file. I've installed and uninstalled the package, and it looks like modules.xml is now being properly populated and deleted.
openni-1.5.7.10-4.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/openni-1.5.7.10-4.fc21
Package openni-1.5.7.10-4.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing openni-1.5.7.10-4.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-0323/openni-1.5.7.10-4.fc21 then log in and leave karma (feedback).
openni-1.5.7.10-4.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.