Re: [Denemo-devel] Problems with 0.8.0 tarball when generating Fedora RPM files

[Roy Rankin]

Jeremiah Benham wrote:
> On Sat, 2009-01-10 at 13:23 +1100, Roy Rankin wrote:
> > I have had several issues in generating clean (ie passes rpmlint) Fedora 
> > RPM files for the 0.8.0 distribution tarball.
> >
> > The first issue is the most important. As of 0.8.0 Denemo is linked 
> > using the -rpath flag. This is not permitted in Fedora.
>
> can you configure with this option?
>
>  --disable-rpath

I tired this, but it had no effect. (which might need looking at)
It is possible for me to meet the Fedora guidelines by running after the 
build.
        chrpath -d src/denemo

> > Why is the -rpath flag being used? What are the alternatives.
>
> The libtool manual suggests it:
>
> http://sourceware.org/autobook/autobook/autobook_88.html
Obviously a contentious issue as recognized by libtool. At least i am 
now more comfortable that a Denemo function does not require the 
--disable-rpath.

> If disabling it does not work for you then I will remove it. 
>
> > Two issues concern the actions tree.
> >
> > 1> There are backup copies (ie ending in ~) files in this tree. As they 
> > are not in git this is probably a production issue with the tarball. 
> > Note that Fedora requires packages to be based on the released version 
> > of the tarball from the upstream site where such a file exists.
>
> I ran make dist and unpacked the tarball. I did not see any files ending
> in ~.
If you look at the 0.8.0 source tarball on Savannah you will see that 
when the tarball was generated there were such files on the machine that 
generated the tarball. Fedora requires rpm packages to be built on the 
upstream release tarball where these exist.
> > 2> In the current git version, a problem involves the install-data-hook 
> > section of the Makefile. It does a "chmod -R 755 
> > ${DESTDIR}/$(datadir)/${PACKAGE}/actions" command. This means the exec 
> > bits are set for the text XML files. Text files with the exec bits set 
> > and not starting with a shebang (#!) is considered an error.
>
> I tried 644 instead of 755 but I could not read the directories. actions
> had this permission:
>
> drw-r--r-- 3 root root  4096 2009-01-15 09:42 actions
>
> When I do:
>
> ls /usr/local/share/denemo/actions/
>
> I get:
>
> ls: cannot access /usr/local/share/denemo/actions/Makefile.am:
> Permission denied
> ls: cannot access /usr/local/share/denemo/actions/NumericKeypad.cmdset:
> Permission denied
> ls: cannot access /usr/local/share/denemo/actions/init.denemo:
> Permission denied
> ls: cannot access /usr/local/share/denemo/actions/Makefile.in:
> Permission denied
> ls: cannot access /usr/local/share/denemo/actions/Default.cmdset:
> Permission denied
> ls: cannot access /usr/local/share/denemo/actions/Makefile: Permission
> denied
> ls: cannot access /usr/local/share/denemo/actions/menus: Permission
> denied
> Default.cmdset  init.denemo  Makefile  Makefile.am  Makefile.in  menus
> NumericKeypad.cmdset
>
> Its weird it says permission denied then at the end it lists the file. 
>
> less /usr/local/share/denemo/actions/Default.cmdset
> won't allow me to read it. while the permission is:
>
> -rw-r--r-- 1 root root 70965 2009-01-15 09:42 Default.cmdset
>
> So will I have to create a makefile.am for every subdirectory inside of
> actions? I wrote a script to do this that we could possibly use and
> would resolve this issue.
0755 is the correct mode for directories, but not the other files.
On my system the permissions are correct without the chmod after a make 
install.

perhaps what is needed is something like
install-data-hook:
        cp -r actions  $(DESTDIR)$(datadir)/${PACKAGE}/
       find $(DESTDIR)$(datadir)/${PACKAGE}/actions -type d |xargs 
chmod 755


Roy