[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Denemo-devel] Problems with 0.8.0 tarball when generating Fedora RP
From: |
Roy Rankin |
Subject: |
Re: [Denemo-devel] Problems with 0.8.0 tarball when generating Fedora RPM files |
Date: |
Fri, 16 Jan 2009 09:09:59 +1100 |
User-agent: |
Thunderbird 2.0.0.19 (X11/20090105) |
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