Red Hat Bugzilla – Bug 174866
Review Request: polypaudio: Improved Linux sound server
Last modified: 2007-11-30 17:11:18 EST
Spec Name or Url: http://auroralinux.org/people/spot/review/polypaudio.spec SRPM Name or Url: http://auroralinux.org/people/spot/review/polypaudio-0.7-1.src.rpm Description: polypaudio is a sound server for Linux and other Unix like operating systems. It is intended to be an improved drop-in replacement for the Enlightened Sound Daemon (ESOUND).
*** Bug 174944 has been marked as a duplicate of this bug. ***
NEEDSWORK MD5Sums: 1c3693ab9c6904dbed6dfa7656778de4 polypaudio-0.7.tar.gz Good: * Source URL is canonical * Upstream source tarball verified * Package name conforms to the Fedora Naming Guidelines * Group Tag is from the official list * Buildroot has all required elements * All paths begin with macros * All directories are owned by this or other packages * No deprecated fields used * All desired features are enabled * Package rebuilds as non-root user * Package installs and uninstalls cleanly on FC4. (After adding missing BR) Needswork: * Package needs additional BuildRequires: Missing BR for xorg-x11-devel on FC4 Missing BR for libXt-devel & xorg-x11-proto-devel on FC5 (You might want to verify that I'm correct on the necessary BR for FC5). * Rpmlint errors: W: polypaudio unstripped-binary-or-object /usr/bin/polypaudio E: polypaudio setuid-binary /usr/bin/polypaudio root 04755 E: polypaudio non-standard-executable-perm /usr/bin/polypaudio 04755 E: polypaudio non-executable-script /etc/polypaudio/default.pa 0644
(In reply to comment #2) > * Rpmlint errors: > W: polypaudio unstripped-binary-or-object /usr/bin/polypaudio Out of curiosity: did you build in mock ? In my home setup, I have in .rpmmacros: %debug_package %{nil} %_enable_debug_packages 0 and I noticed that it (apparently) causes the unstripped warnings in rpmlint...
(In reply to comment #3) > Out of curiosity: did you build in mock ? Yes.
(In reply to comment #3) > (In reply to comment #2) > > * Rpmlint errors: > > W: polypaudio unstripped-binary-or-object /usr/bin/polypaudio > > Out of curiosity: did you build in mock ? > In my home setup, I have in .rpmmacros: > %debug_package %{nil} > %_enable_debug_packages 0 > and I noticed that it (apparently) causes the unstripped warnings in rpmlint... That's to be expected. Turning off the separate debug package means that the debug information is left in the main package, i.e. not stripped.
setuid/setgid executables are not stripped by rpmbuild, see bug 117858. Workaround: remove those bits in %install and restore in %files using %attr.
(In reply to comment #6) > setuid/setgid executables are not stripped by rpmbuild, see bug 117858. Ah, didn't know that. Thanks! > Workaround: remove those bits in %install and restore in %files using %attr. Yup. IMHO, this should be a SHOULD or even a MUST in the guidelines...
(In reply to comment #7) > (In reply to comment #6) > > setuid/setgid executables are not stripped by rpmbuild, see bug 117858. > > Ah, didn't know that. Thanks! > > > Workaround: remove those bits in %install and restore in %files using %attr. > > Yup. IMHO, this should be a SHOULD or even a MUST in the guidelines... > Agreed - an rpm should be buildable by unprivileged users, which means those bits have to be set with %attr You may also need to patch the Makefile to not set them (to get it to build as a non root user)
Note that packages that don't insist doing chown/chgrp but do chmod setuid/setgid are unaffected wrt. being buildable by unprivileged users, and the '-'s in eg. %defattr(-,root,root,-) will do the right thing regarding the files' ownership. rpmbuild not stripping setuid/setgid binaries is a different, orthogonal issue.
(In reply to comment #9) > Note that packages that don't insist doing chown/chgrp but do chmod > setuid/setgid are unaffected wrt. being buildable by unprivileged users, and the > '-'s in eg. %defattr(-,root,root,-) will do the right thing regarding the files' > ownership. After building and installing the package, I get (on my FC4, x86_64 box): root: ls -al /usr/bin/polypaudio -rwsr-xr-x 1 root root 632416 Dec 8 23:35 /usr/bin/polypaudio So, I stand by my (humble) opinion that the guidelines should mandate no chown/chmod in %install, and use of %attr in %files. This way, it is much clearer which packages introduce suid binaries. > rpmbuild not stripping setuid/setgid binaries is a different, > orthogonal issue. Right. And quite useful as a warning :-) BTW, rpmlint on x86_64 is noisy about rpath: E: polypaudio binary-or-shlib-defines-rpath /usr/bin/polypaudio ['/usr/lib64'] E: polypaudio binary-or-shlib-defines-rpath /usr/bin/paplay ['/usr/lib64'] E: polypaudio binary-or-shlib-defines-rpath /usr/bin/pacat ['/usr/lib64'] E: polypaudio binary-or-shlib-defines-rpath /usr/bin/pactl ['/usr/lib64']
(shameless plug) This might be of interest: :) http://article.gmane.org/gmane.linux.alsa.devel/31738
What's the status of this? The links in the initial comment are dead. I'd really like to see this included in Fedora.
Spec Name or Url: http://auroralinux.org/people/spot/review/polypaudio.spec SRPM Name or Url: http://auroralinux.org/people/spot/review/polypaudio-0.7-2.src.rpm Fixed packages resolve the unstripped binary. The rpath issues on x86_64 are much harder to resolve, as removing the rpath calls causes it to explode on that architecture, and an rpath of /usr/lib64 is not fatal, just a bit redundant.
This multiple architecture business is a bit new to me, so I'm unclear to what the problem is. Does library paths get stored inside the resulting binaries? If you can point me in the right direction I can try to remedy the situation. :)
Yep, that's exactly what it is. Google for rpath, and grep through the polypaudio source tree to see it in action.
This seems to be a libtool issue since only x86_64 gets the rpath set. I also examined the command sent to libtool and it contained no rpath. The resulting gcc command does though. I tried googling the issue but didn't see anything to help me solve it. Do you have any pointers?
Further investigation shows that this is indeed a libtool problem (in combination with gcc not giving a complete picture on multilib systems). It is currently unresolved, so unless we do a dirty hack the RPATH is here to stay. I'd also like to do some suggestions for packaging. There should be at least four packages: * libpolyp - Client libraries. * libpolyp-devel - Headers and such for building clients * polypaudio - The daemon. * polypaudio-devel - Headers and such for building daemon modules. Possibly one could also package the modules in their own packages to minimise the dependencies. As for separating libpolyp-devel files from polypaudio-devel files you have to look in the Makefile for the 0.7 release. The 0.8 release will install these in separate locations so it will be much more clear there.
Spec Name or Url: http://homes.hades.drzeus.cx/~drzeus/polypaudio/polypaudio.spec SRPM Name or Url: http://homes.hades.drzeus.cx/~drzeus/polypaudio/polypaudio-0.8.1-1.src.rpm Updated to the current version (0.8.1). I've also created a whole bunch of sub-packages to minimise the dependencies.
Spec Name or Url: http://homes.hades.drzeus.cx/~drzeus/polypaudio/polypaudio.spec SRPM Name or Url: http://homes.hades.drzeus.cx/~drzeus/polypaudio/polypaudio-0.9.0-1.src.rpm Updated again. Anyone but me still interested in this?
Spec Name or Url: http://homes.drzeus.cx/~drzeus/polypaudio/polypaudio.spec SRPM Name or Url: http://homes.drzeus.cx/~drzeus/polypaudio/polypaudio-0.9.0-1.src.rpm Bad URLs, sorry about that.
Spec Name or Url: http://homes.drzeus.cx/~drzeus/polypaudio/polypaudio.spec SRPM Name or Url: http://homes.drzeus.cx/~drzeus/polypaudio/polypaudio-0.9.0-2.src.rpm Fixed some rpmlint problems. Remaining warnings: polypaudio-0.9.0-2.i386.rpm: E: polypaudio setuid-binary /usr/bin/polypaudio root 04755 E: polypaudio non-standard-executable-perm /usr/bin/polypaudio 04755 E: polypaudio non-executable-script /etc/polypaudio/default.pa 0644 polypaudio-devel-0.9.0-2.i386.rpm: W: polypaudio-devel no-documentation polypaudio-lib-glib-0.9.0-2.i386.rpm: W: polypaudio-lib-glib no-documentation polypaudio-lib-glib2-0.9.0-2.i386.rpm: W: polypaudio-lib-glib2 no-documentation polypaudio-module-alsa-0.9.0-2.i386.rpm: W: polypaudio-module-alsa no-documentation polypaudio-module-lirc-0.9.0-2.i386.rpm: W: polypaudio-module-lirc no-documentation polypaudio-module-x11-0.9.0-2.i386.rpm: W: polypaudio-module-x11 no-documentation polypaudio-utils-0.9.0-2.i386.rpm: E: polypaudio-utils invalid-soname /usr/lib/libpolypdsp.so libpolypdsp.so W: polypaudio-utils no-documentation
Adding back the comments and status changes that were lost in the crash. Note that I might not have copies of the new review tickets that were opened since I wasn't CC'd; could whoever did those add them back? ------- Additional Comments From tibbs@math.uh.edu 2006-06-10 16:29 EST ------- I am interested in this simply because I'd like to see some action on all of the old review tickets. However, I'm not sure if this is spot's ticket or Pierre's ticket. Perhaps one of you could review the other's package, or if spot wishes to drop his review request, this could be closed NOTABUG and Pierre could open a new review request with his package. BTW, 0.9.1 seems to be out now. ------- Additional Comments From drzeus-bugzilla@drzeus.cx 2006-06-10 20:34 EST ------- I'm fine either way. The packages I've been putting up are based on spot's anyway. I have a new RPM ready for 0.9.1 as well as for some Polypaudio utils. I've been holding off on them until I saw some activity here. ------- Additional Comments From tcallawa@redhat.com 2006-06-11 15:19 EST ------- Pierre: Go ahead and open a new review request for this package. ------- Additional Comments From drzeus-bugzilla@drzeus.cx 2006-06-13 09:27 EST ------- New request opened as bug 194957. (Note that the new request bug number is incorrect due to being lost in the crash.)
I'll readd the new requests. Should I add you as cc for them directly?
New request opened as bug 195221.