On 10/17/2013 8:19 PM, Alan W. Irwin wrote:
> Hi Orion:
>
> This is part 4 and the last part of my reply.
>
> On 2013-10-16 20:42-0600 Orion Poplawski wrote:
>
>> plplot-octave.x86_64: W: unstripped-binary-or-object
>> /usr/lib64/octave/site/oct/x86_64-redhat-linux-gnu/plplot_octave.oct
>>
>> similar to the above, needs to be installed with execute bit set.
>
> No, as stated in part 3 just treat this like you do all the
> rest of our libraries which all have the same non-execute permissions
> by default.
Nope, you are setting the permissions explicitly:
plplot-5.9.10/bindings/octave/CMakeLists.txt:
# Have to be specific about permissions for some reason (probably oct
suffix).
set(PERM_MODULES
OWNER_READ
OWNER_WRITE
GROUP_READ
WORLD_READ
)
install(TARGETS plplot_octave
EXPORT export_plplot
LIBRARY
DESTINATION ${OCTAVE_OCT_DIR}
PERMISSIONS ${PERM_MODULES}
)
If I remove the PERMISSIONS line, all is fine. The .oct is installed
executable.
> Also, if there is any question about the above permissions complaints
> for all of these *.in files, we deliberately set them to be executable
> in our source tree and also in the installed examples tree. They
> aren't actually meant to be executed so these execute permissions are
> technically incorrect (as noticed by rpmlint), but that permission
> automatically means the configured versions in both cases also have
> the appropriate execute permissions which is the result we want.
> There is probably a nicer way to get this result without setting
> technically incorrect execute bits on the *.in files, but I am
> not sure what it is. I will ask on the CMake list about this.
Thanks.
>> plplot-tk.x86_64: E: non-executable-script
>> /usr/share/plplot5.9.10/examples/tk/tk03 0644L /bin/sh
>> plplot-tk.x86_64: E: non-executable-script
>> /usr/share/plplot5.9.10/examples/tk/tk02 0644L
>> /usr/share/plplot5.9.10/examples/tk/xtk02
>> plplot-tk.x86_64: E: non-executable-script
>> /usr/share/plplot5.9.10/examples/tk/tk01 0644L
>> /usr/share/plplot5.9.10/examples/tk/xtk01
>> plplot-tk.x86_64: E: non-executable-script
>> /usr/share/plplot5.9.10/examples/tk/tk04 0644L
>> /usr/share/plplot5.9.10/examples/tk/xtk04
>>
>> If these are meant to be executed directly (which the presence of a #!
>> suggests), they should have the execute bit set.
>
> This is what I have here:
>
> software@raven> pushd $prefix/share/plplot5.9.10/examples/tk
> where $prefix is my install prefix.
>
> software@raven> ls -lt *tk0*
> -rwxr-xr-x 1 software software 3766 Oct 17 13:26 tk01*
> -rwxr-xr-x 1 software software 3707 Mar 18 2013 tk01.in*
> -rwxr-xr-x 1 software software 4243 Oct 17 13:26 tk02*
> -rwxr-xr-x 1 software software 4184 Mar 18 2013 tk02.in*
> -rwxr-xr-x 1 software software 6294 Oct 17 13:26 tk03*
> -rwxr-xr-x 1 software software 6262 Mar 18 2013 tk03.in*
> -rwxr-xr-x 1 software software 2821 Oct 17 13:26 tk04*
> -rwxr-xr-x 1 software software 2762 Mar 18 2013 tk04.in*
> -rw-r--r-- 1 software software 12881 Mar 18 2013 xtk01.c
> -rw-r--r-- 1 software software 9103 Mar 18 2013 xtk02.c
> -rw-r--r-- 1 software software 5697 Mar 18 2013 xtk04.c
Ah, sorry, I have:
#Don't pull in script interpreters for example binaries
chmod -x $RPM_BUILD_ROOT%{_datadir}/plplot%{version}/examples/tk/tk*
..
> I was confused a bit by the rpmlint mention of xtk0[124] files.
> However, that turns out to be just a mail wrap to an additional line
> of the rpmlint output that expresses what is found after #! for each
> of the configured tk0[124] files. Obviously, those xtk0[124] files
> should not be built except by interested users after rpm installation
> who want to test the system by trying the traditional or CMake-based
> build systems for the installed examples.
And that's why I did the chmod - otherwise rpm adds a dependency on
/usr/share/plplot5.9.9/examples/tk/xtk01 (which is no good).
There's a better way to handle this now in rpm though.
>>
>> plplot.x86_64: E: script-without-shebang
>> /usr/share/plplot5.9.10/examples/python/plplot_py_demos.py
>>
>> Not sure the point of this guy, but if it is meant to be executed
>> directly it should have #!/usr/bin/python2 at the top, otherwise no
>> execute bit.
>
> Again, it appears we differ in the permissions:
>
> irwin@raven> ls -l plplot_py_demos.py
> -rw-r--r-- 1 software software 41 Oct 4 17:39 plplot_py_demos.py
>
> What do you get for these permissions (in the installed examples tree)?
>
> That file is just a python module and not a python script so the
> above permissions are the correct ones.
>
> In sum, we appear to have different permissions for some
> of the files in the installed examples tree. It is obviously
> important that we figure out the cause of this.
This seems to be the cause:
set(
python_SCRIPTS
${python_SCRIPTS}
...
plplot_py_demos.py
And:
set(PERM_SCRIPTS
OWNER_READ
OWNER_WRITE
OWNER_EXECUTE
GROUP_READ
GROUP_EXECUTE
WORLD_READ
WORLD_EXECUTE
)
install(FILES ${python_SCRIPTS}
${CMAKE_CURRENT_BINARY_DIR}/test_plsmem.py
DESTINATION ${DATA_DIR}/examples/python
PERMISSIONS ${PERM_SCRIPTS}
)
It should be part of python_DATA I suppose.
>
> This has been a number of hours of work for me to put this 4-part
> reply together, but I do very much appreciate your rpmlint reports
> because they often highlight areas that do need to be cleaned up.
You are always extremely detail oriented. I hope you work pays off.
Sorry for some false leads.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane [email protected]
Boulder, CO 80301 http://www.nwra.com
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
