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. > > plplot-tk.x86_64: E: wrong-script-interpreter > /usr/share/plplot5.9.10/examples/tk/tk02.in @xtk02_LOCATION@ > plplot-tk.x86_64: E: non-executable-script > /usr/share/plplot5.9.10/examples/tk/tk02.in 0644L @xtk02_LOCATION@ > plplot-tk.x86_64: E: non-executable-script > /usr/share/plplot5.9.10/examples/tk/tk03.in 0644L /bin/sh > plplot-tk.x86_64: E: wrong-script-interpreter > /usr/share/plplot5.9.10/examples/tk/tk04.in @xtk04_LOCATION@ > plplot-tk.x86_64: E: non-executable-script > /usr/share/plplot5.9.10/examples/tk/tk04.in 0644L @xtk04_LOCATION@ > plplot-tk.x86_64: E: wrong-script-interpreter > /usr/share/plplot5.9.10/examples/tcl/standard_examples.in @SH_EXECUTABLE@ > plplot-tk.x86_64: E: wrong-script-interpreter > /usr/share/plplot5.9.10/examples/tk/standard_examples.in @SH_EXECUTABLE@ > plplot-tk.x86_64: E: wrong-script-interpreter > /usr/share/plplot5.9.10/examples/tk/tk01.in @xtk01_LOCATION@ > plplot-tk.x86_64: E: non-executable-script > /usr/share/plplot5.9.10/examples/tk/tk01.in 0644L @xtk01_LOCATION@ > > Do we really want to install the .in files too? Yes, our cmake-based build system for the installed examples configures these files. If $prefix is the install prefix, see $prefix/share/plplot5.9.10/examples/tcl/CMakeLists.txt for the configuration of tcl/standard_examples and see $prefix/share/plplot5.9.10/examples/tk/CMakeLists.txt for the configuration of the rest of these. 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. > 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 I have explained the necessity of the *.in results above which are configured to a separate build tree without the .in suffix for the CMake-based build system of the installed examples. So technically those configured files in the build tree for that build system have nothing to do with the tk?? files in this source tree which are there for the use of our traditional build system and which are configured by the CMake-based build system _for our build tree_. So all is well on my platform with regard to permissions. It appears though that you might be getting different permissions for these files which I don't understand at all. 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. To compare with my results above, what do you get for "ls -lt *tk0*" in the correct directory? > > 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. What happens if you just do an ordinary command-line install of PLplot without rpm being involved? Obviously, rpm does have the capability of fiddling with permission bits (required for example to set the executable bits on the libraries mentioned earlier in this thread to make the library permissions conform to Fedora standards). So please remove rpm from the equation to see whether that solves the issue. And if it does, (i.e., the permissions I demonstrate for the files above come out to be the same for you), then your spec file needs to be changed to not fiddle with those permissions. But if the permission results of the ordinary command line you get still differ from mine, than we will have to dig deeper. One possibility that might have an effect (but which should not) is the umask value. Mine is software@raven> umask 0022 I don't think the umask value should make any difference to the permissions of the CMake results, but if that turns out to be the case, the build system should be fixed so that installed results whose permissions have not been fiddled with by rpm should always have the same permissions achieved above on my platform. That's the end of part 4, and the end of my initial response to your detailed e-mail demonstrating issues found by rpmlint. 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. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ 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=60135031&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
