Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 195221
Summary: | Review Request: pulseaudio: Improved Linux sound server | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Pierre Ossman <pierre-bugzilla> | ||||||||
Component: | Package Review | Assignee: | Rex Dieter <rdieter> | ||||||||
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Package Reviews List <fedora-package-review> | ||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | medium | ||||||||||
Version: | rawhide | CC: | abo, davidf, eric.moret, gnomeuser, green, j, lkundrak, lpoetter, rdieter, seg, toshio, wtogami | ||||||||
Target Milestone: | --- | Flags: | kevin:
fedora-cvs+
|
||||||||
Target Release: | --- | ||||||||||
Hardware: | All | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2006-08-29 20:07:03 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Bug Depends On: | |||||||||||
Bug Blocks: | 163779, 195222, 195223, 198088, 198089 | ||||||||||
Attachments: |
|
Description
Pierre Ossman
2006-06-14 15:21:13 UTC
See also bug 174866. Could you please add support for zeroconf? Here is what I get when building polypaudio on a system with avahi-compat-howl-devel and avahi-compat-libdns_sd-devel installed. [...] Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/polypaudio-0.9.1-1-root-emoret error: Installed (but unpackaged) file(s) found: /usr/bin/pabrowse /usr/lib/libpolyp-browse.a /usr/lib/libpolyp-browse.so /usr/lib/libpolyp-browse.so.0 /usr/lib/libpolyp-browse.so.0.0.0 /usr/lib/polypaudio-0.9/modules/libhowl-wrap.so /usr/lib/polypaudio-0.9/modules/module-zeroconf-publish.so RPM build errors: Installed (but unpackaged) file(s) found: /usr/bin/pabrowse /usr/lib/libpolyp-browse.a /usr/lib/libpolyp-browse.so /usr/lib/libpolyp-browse.so.0 /usr/lib/libpolyp-browse.so.0.0.0 /usr/lib/polypaudio-0.9/modules/libhowl-wrap.so /usr/lib/polypaudio-0.9/modules/module-zeroconf-publish.so Ah, sorry. Must have missed that. I'm waiting for the first PulseAudio release so that I can do all the necessary name changes. I'll fix this at the same time. Spec URL: http://homes.drzeus.cx/~drzeus/pulseaudio/pulseaudio.spec SRPM URL: http://homes.drzeus.cx/~drzeus/pulseaudio/pulseaudio-0.9.2-1.src.rpm Updated to the new name and added the zeroconf parts. Before I start reviewing this, I checked and I don't see anything resembling "drzeus" or your name in the cvsextras group. If you haven't been sponsored, your review tickets need to block FE-NEEDSPONSOR. I haven't. So I'll add the dependency. OK, I'll take a look over the various packages; there should be enough here to show me what I need to know but if you've done some review work them please include the links so that I can take a look. Check http://fedoraproject.org/wiki/Extras/HowToGetSponsored for more information on the sponsorship process. I'm afraid I haven't done any reviews as of yet as I hadn't gotten that deeply involved in the Extras project until now. I just figured that I, as one of the main developers of PulseAudio, could give these packages the attention they need. :) Building on Rawhide works fine but does not work on FC5 with the following error: [emoret@fc5 pkgconfig]$ sudo ldconfig [...] gcc -shared .libs/libpulse_browse_la-browser.o -Wl,--rpath - Wl,/home/emoret/rpmbuild/BUILD/pulseaudio-0.9.2/src/.libs ./.libs/libpulse.so - lhowl -lcap -ldl -lm -pthread -m32 -march=i386 -mtune=generic -Wl,-soname - Wl,libpulse-browse.so.0 -o .libs/libpulse-browse.so.0.0.0 /usr/bin/ld: cannot find -lhowl collect2: ld returned 1 exit status make[3]: *** [libpulse-browse.la] Error 1 make[3]: Leaving directory `/home/emoret/rpmbuild/BUILD/pulseaudio-0.9.2/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/emoret/rpmbuild/BUILD/pulseaudio-0.9.2/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/emoret/rpmbuild/BUILD/pulseaudio-0.9.2' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.9607 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.9607 (%build) [emoret@fc5 SPECS]$ locate avahi-compat-howl.pc /usr/lib/pkgconfig/avahi-compat-howl.pc [emoret@fc5 SPECS]$ cd /usr/lib/pkgconfig/ [emoret@fc5 pkgconfig]$ ls -la howl.pc lrwxrwxrwx 1 root root 20 Jul 10 00:15 howl.pc -> avahi-compat-howl.pc [emoret@fc5 pkgconfig]$ locate libhowl /usr/lib/libhowl.so [emoret@fc5 pkgconfig]$ Also I have noticed that pabrowse is part of module-zeroconf while pax11publish is in utils even if it depends on module-x11. Don't you think it might make more sense to either include pabrowse in utils or move pax11publish in module- x11 for sake of consistency? pabrowse is packaged with lib-zeroconf (client side), not module-zeroconf (server side). There is no client side package for X11 integration (it's in the client lib unconditionally) so it made no sense to put pax11publish in its own package. The broken build is an error in the avahi package which has forgotten to add a dependency from the devel package to the "main" one. Filed as bug 198282. Actually you must be right regarding pabrowse :) Something else I noticed on rawhide, I don't get the nice icons I can see on the screenshot for the GUI interfaces in the default gnome fedora theme. IE, I see a red cross in the trayicon when launching padevchooser instead of the speaker from the main site's screenshot. Likewise no icon in Applications ! Sound & Video Menu for Pulseaudio Device Chooser. I must be missing something but what? PulseAudio follows the icon naming spec and GNOME isn't fully compliant yet. So in good time my friend :) (I have no insight into Bluecurve with regard to the naming spec) There is a plan to introduce a new set of icons which follow the freedesktop icon spec in FC6. Details at http://fedoraproject.org/wiki/Artwork/BluecurveAndBeyond When compiling the src.rpm on current Development I get the following error: gcc -shared .libs/libpulsecore_la-channelmap.o .libs/libpulsecore_la-error.o .libs/libpulsecore_la-mainloop.o .libs/libpulsecore_la-mainloop-api.o .libs/libpulsecore_la-mainloop-signal.o .libs/libpulsecore_la-sample.o .libs/libpulsecore_la-timeval.o .libs/libpulsecore_la-utf8.o .libs/libpulsecore_la-util.o .libs/libpulsecore_la-volume.o .libs/libpulsecore_la-xmalloc.o .libs/libpulsecore_la-autoload.o .libs/libpulsecore_la-cli-command.o .libs/libpulsecore_la-cli-text.o .libs/libpulsecore_la-client.o .libs/libpulsecore_la-conf-parser.o .libs/libpulsecore_la-core.o .libs/libpulsecore_la-core-scache.o .libs/libpulsecore_la-core-subscribe.o .libs/libpulsecore_la-core-util.o .libs/libpulsecore_la-dynarray.o .libs/libpulsecore_la-g711.o .libs/libpulsecore_la-hashmap.o .libs/libpulsecore_la-idxset.o .libs/libpulsecore_la-log.o .libs/libpulsecore_la-mcalign.o .libs/libpulsecore_la-memblock.o .libs/libpulsecore_la-memblockq.o .libs/libpulsecore_la-memchunk.o .libs/libpulsecore_la-modargs.o .libs/libpulsecore_la-modinfo.o .libs/libpulsecore_la-module.o .libs/libpulsecore_la-namereg.o .libs/libpulsecore_la-pid.o .libs/libpulsecore_la-pipe.o .libs/libpulsecore_la-play-memchunk.o .libs/libpulsecore_la-poll.o .libs/libpulsecore_la-props.o .libs/libpulsecore_la-queue.o .libs/libpulsecore_la-random.o .libs/libpulsecore_la-resampler.o .libs/libpulsecore_la-sample-util.o .libs/libpulsecore_la-sconv.o .libs/libpulsecore_la-sconv-s16be.o .libs/libpulsecore_la-sconv-s16le.o .libs/libpulsecore_la-sink .o .libs/libpulsecore_la-sink-input.o .libs/libpulsecore_la-sioman.o .libs/libpulsecore_la-sound-file.o .libs/libpulsecore_la-sound-file-stream.o .libs/libpulsecore_la-source.o .libs/libpulsecore_la-source-output.o .libs/libpulsecore_la-strbuf.o .libs/libpulsecore_la-tokenizer.o .libs/libpulsecore_la-core-error.o /usr/lib/libltdl.so -lsamplerate -lsndfile -loil-0.3 -lcap -ldl -lm -pthread -Wl,-soname -Wl,libpulsecore.so.0 -o .libs/libpulsecore.so.0.0.1 /usr/lib/libltdl.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[3]: *** [libpulsecore.la] Error 1 make[3]: Leaving directory `/usr/src/redhat/BUILD/pulseaudio-0.9.2/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/src/redhat/BUILD/pulseaudio-0.9.2/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/redhat/BUILD/pulseaudio-0.9.2' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.26234 (%build) I had no problems building in rawhide, but rpmlint is very unhappy: Tons of rpath warnings: E: pulseaudio binary-or-shlib-defines-rpath /usr/lib64/pulse-0.9/modules/libprotocol-esound.so ['/usr/lib64/pulse-0.9/modules/', '/usr/lib64'] and 69 others. The usual libtool hack doesn't work. This looks like a script but isn't executable: E: pulseaudio non-executable-script /etc/pulse/default.pa 0644 Some setuid bits: E: pulseaudio setuid-binary /usr/bin/pulseaudio root 04755 E: pulseaudio non-standard-executable-perm /usr/bin/pulseaudio 04755 which will need to be discussed to make sure we're not getting into any security issues. Some no-documentation warnings: W: pulseaudio-devel no-documentation W: pulseaudio-lib-glib no-documentation W: pulseaudio-lib-zeroconf no-documentation W: pulseaudio-module-alsa no-documentation W: pulseaudio-module-x11 no-documentation W: pulseaudio-module-zeroconf no-documentation W: pulseaudio-utils no-documentation which are probably OK but I'll have to check. This is problematic: E: pulseaudio-utils invalid-soname /usr/lib64/libpulsedsp.so libpulsedsp.so but unfortunately I'm not entirely sure how to fix it. (In reply to comment #16) > I had no problems building in rawhide, but rpmlint is very unhappy: > > Tons of rpath warnings: > E: pulseaudio binary-or-shlib-defines-rpath > /usr/lib64/pulse-0.9/modules/libprotocol-esound.so > ['/usr/lib64/pulse-0.9/modules/', '/usr/lib64'] > and 69 others. The usual libtool hack doesn't work. This is a libtool/gcc misfeature. I talked to Ralf Wildenhues about it, but he didn't have any way of solving it (short of bastardising libtool). It's just the way things are on multi-arch for now. > > This looks like a script but isn't executable: > E: pulseaudio non-executable-script /etc/pulse/default.pa 0644 > The hash bang is mostly there to show that it can be used that way. As it is located in /etc, I think we should keep the execute bit off. > Some setuid bits: > E: pulseaudio setuid-binary /usr/bin/pulseaudio root 04755 > E: pulseaudio non-standard-executable-perm /usr/bin/pulseaudio 04755 > which will need to be discussed to make sure we're not getting into any security > issues. Sure. Pulse only uses its root privileges to change to realtime scheduling, then drops them. Access control is based on who is in the 'realtime' group. > > Some no-documentation warnings: > W: pulseaudio-devel no-documentation > W: pulseaudio-lib-glib no-documentation > W: pulseaudio-lib-zeroconf no-documentation > W: pulseaudio-module-alsa no-documentation > W: pulseaudio-module-x11 no-documentation > W: pulseaudio-module-zeroconf no-documentation > W: pulseaudio-utils no-documentation > which are probably OK but I'll have to check. > The docs are in the other packages. > This is problematic: > E: pulseaudio-utils invalid-soname /usr/lib64/libpulsedsp.so libpulsedsp.so > but unfortunately I'm not entirely sure how to fix it. It's not a "real" lib, so it has no use for versioning. It's the active part of an LD_PRELOAD hack to provide OSS emulation. As such, the error is incorrect and the lib is just fine. License should be both GPL and LGPL. (See the LICENSE file for details) pkgconfig files won't do the right thing on x86_64. Will attach a patch for that. Created attachment 132822 [details]
Patch to correct pkgconfig files for libdir on x86_64
Is there a reason to ship static libraries with this package? (In reply to comment #20) > Is there a reason to ship static libraries with this package? Other than completeness, no. Spec URL: http://homes.drzeus.cx/~drzeus/pulseaudio/pulseaudio.spec SRPM URL: http://homes.drzeus.cx/~drzeus/pulseaudio/pulseaudio-0.9.3-1.src.rpm Updated with a new version. Also fixed the license and pc issue pointed out. (pc fix also committed upstream) * Should get rid of the static libraries as well. Comment #17: >> E: pulseaudio-utils invalid-soname /usr/lib64/libpulsedsp.so libpulsedsp.so >> but unfortunately I'm not entirely sure how to fix it. > > It's not a "real" lib, so it has no use for versioning. It's the active part of > an LD_PRELOAD hack to provide OSS emulation. As such, the error is incorrect > and the lib is just fine. libesddsp and libartsdsp are versioned:: $ objdump -p /usr/lib64/libartsdsp.so /usr/lib64/libesddsp.so.0|grep SONAME SONAME libartsdsp.so.0 SONAME libesddsp.so.0 I don't know how these libraries do their tricks, but is there any improbable case when you might want to have it versioned? The kernel upgrades what it expects to receive on /dev/dsp and you want to provide both the older interface and newer interface to programs? Created attachment 132852 [details]
patch spec to remove static libs and fix rpath breakage
Here's a spec patch for two of the issues. It removes static libraries and
fixes rpath. Note that some of the files in the modules directory,
%{_libdir}/pulse-0.9/modules, need to have an rpath to that directory because
they have dependencies on other shared objects in there. Before, they had a
second rpath set on /usr/lib64 which was wrong. Also, some of the modules do
not have dependencies on anything within that directory. Therefore, they
should have no rpath set. This patch should make all of that happy (and
rpmlint should no longer complain about rpaths.)
Why kill of the static libs? Although dynamic linking is preferred, I see no point in preventing those that want to do a static link. The versioning in lib*dsp is completely useless and can only be motivated by defeating warnings like those in rpmlint. The .so shouldn't be seen as a lib, more like a program. The reason it is a lib is because that's the way LD_PRELOAD works, not because you want the properties a shared library gives you. (In reply to comment #25) > Why kill of the static libs? Although dynamic linking is preferred, I see no > point in preventing those that want to do a static link. Policy.... http://fedoraproject.org/wiki/Packaging/Guidelines#head-2302ec1e1f44202c9cc4bcce24cb711266557ad7 I don't know the full reasoning behind the policy (it would be nice if the guidelines came with a raionale document), but the obvious reason is easy enough to guess. Static libs are security hole. If I link my program against the static versions of a library and a vulnerability is later fixed in the library I will still be carrying around vulnerable code until I recompile against the newer version. With dynamic libs, only the library packager needs to be on the ball about finding security holes and making updates. The consumers of the library get the hole closed after they update the library. Versioning: Bear with me. I'm trying to imagine if there's any reason that versioning could be useful so we know we're not introducing broken behaviour. Since arts and esd both do it they either have thought of some corner case where it's useful or they're both broken. The latter is very likely (they're broken in many other ways) but we want to make sure we actually are smarter than our predecessors rather than falling into a problem that they avoided. (In reply to comment #24) > Created an attachment (id=132852) [edit] > patch spec to remove static libs and fix rpath breakage > > Here's a spec patch for two of the issues. It removes static libraries and > fixes rpath. Note that some of the files in the modules directory, > %{_libdir}/pulse-0.9/modules, need to have an rpath to that directory because > they have dependencies on other shared objects in there. Before, they had a > second rpath set on /usr/lib64 which was wrong. Also, some of the modules do > not have dependencies on anything within that directory. Therefore, they > should have no rpath set. This patch should make all of that happy (and > rpmlint should no longer complain about rpaths.) The patch succesfully fixes the compile issue I pointed out earlier, thank you very much. Any hope of getting gst-pulse packaged as well so pulseaudio will be more useful on a default FC desktop? (http://0pointer.de/lennart/projects/gst-pulse/) Spec URL: http://homes.drzeus.cx/~drzeus/pulseaudio/pulseaudio.spec SRPM URL: http://homes.drzeus.cx/~drzeus/pulseaudio/pulseaudio-0.9.3-2.src.rpm Updated with Toshio's patch. About the versioning... The reason we have versions on libs is so that: a) We can have multiple versions of a lib on the system. b) If we break ABI, applications depending on this lib won't be able to load it as it will have a different ver. Now apply this to libpulsedsp.so and you'll see that neither matters. The primary reason being that the only "user" of the lib is the padsp script that needs to know the name when setting up the LD_PRELOAD variable. However, as the two are part of one package, there is no need for version handling. Adding it would be the equivalent of versioning glade files for every GTK application. If a valid case for versions presents itself, then I'll gladly support adding it. But if it is only to shut up an incorrect warning, then things should stay the way they are upstream. It could be that neither matters but the reasoning is flawed. In LTSP thin client installations (where you need to have a networked audio server in order to get sound) it is common to set up the LD_PRELOAD variable to load the dsp redirecting library system wide. So the padsp script is never used in this case. I think the real question is whether the calls that libpulsedsp is overriding (AFAICT: _ioctl, _close, _open, _fopen, _open64, _fopen64, _fclose, _access ) will ever change their ABI. And if they do, will we need to provide for concurrent old and new versions or will the change be such that everything will have to upgrade with no backwards compat-possible. I don't usually work at this level, so feel free to correct any misconceptions I might have as to how libpulsedsp works and to tell me what will happen in the case above. (In reply to comment #30) > It could be that neither matters but the reasoning is flawed. In LTSP thin > client installations (where you need to have a networked audio server in order > to get sound) it is common to set up the LD_PRELOAD variable to load the dsp > redirecting library system wide. So the padsp script is never used in this case. Doesn't this result in disable prelinking system wide? > I think the real question is whether the calls that libpulsedsp is overriding > (AFAICT: _ioctl, _close, _open, _fopen, _open64, _fopen64, _fclose, _access ) > will ever change their ABI. Yes, symbol versioning is something to worry about. LD_PRELOAD is a neat trick but I've learned the hard way that it's basically a bad idea for anything other than debugging. I'm not all that familiar with pulseaudio yet, but isn't there some other way to get similar functionality? (In reply to comment #31) > (In reply to comment #30) > > In LTSP thin client installations (where you need to have a networked audio > > server in order to get sound) it is common to set up the LD_PRELOAD variable > > to load the dsp redirecting library system wide. > > Doesn't this result in disable prelinking system wide? > I've never thought of that but it could. I'll mention this on the k12ltsp list and see what response comes back. > LD_PRELOAD is a neat trick but I've learned the hard way that it's basically a > bad idea for anything other than debugging. I'm not all that familiar with > pulseaudio yet, but isn't there some other way to get similar functionality? > Monty mentioned on IRC that he's working on fusd (Device files from userspace.) He thinks that will allow pulseaudio to create the device files rather than having to load a library that overrides calls to /dev/dsp with calls to pulseaudio instead. Without that I think all prior art is to use LD_PRELOAD in this manner. (Although thin client is the only place I'm aware of them doing it system-wide; most places use the {esd,arts,pa}dsp wrapper to target specific applications.) (In reply to comment #30) > It could be that neither matters but the reasoning is flawed. The reasoning is sound, you just expect the versioning to do more magic than it does. > > I think the real question is whether the calls that libpulsedsp is overriding > (AFAICT: _ioctl, _close, _open, _fopen, _open64, _fopen64, _fclose, _access ) > will ever change their ABI. And if they do, will we need to provide for > concurrent old and new versions or will the change be such that everything will > have to upgrade with no backwards compat-possible. Versioning does not work on this level. If we assume that _open changed it's ABI, then libc.so.6 would become libc.so.7. Still, this would mean nothing to libpulsedsp.so as the only one who knows about it is padsp (or some other script setting the LD_PRELOAD variable). If we have a mix of applications needing libc.so.6 and libc.so.7 then versioning libpulse.so wouldn't solve our problem. We, as users, would need to provide info on which ABI is in place. There wouldn't be any need for two libpulse.so though, as it could be designed to handle both ABI:s, provided it gets information about which it should use. Thanks for explaining. If I understand correctly, if an ABI change occurs, pulseaudio will enhance the pulsedsp library to receive either the old or new ABI, convert the call properly based on some external information (config file, ENVVAR, etc), and then send it on to the daemon. If that's the pulseaudio team's plan for dealing with ABI changes, then I can't think of any other instances versioning would come in handy at the moment. Given that libpulsedsp.so is a preload hack library, I don't think it should be in %{_libdir}, and thus in the default linker path. It belongs in a subdir. That would be nice. Unfortunately it isn't possible as we want to support multi-arch, which requires us to put it in lib[64] and let ld.so find it. I can try reviewing this... Pierre, do you have any notions/intentions to maintain more than just this in Fedora Extras? I ask mainly because as your first reviewer, I'll need to also sponsor you. Duh, just checked all(most?) other bugs depending on this one, and they're mostly yours too. Nevermind the silly question. MUSTFIX: lib-devel contains pkgconfig file(s), so it ought to: Requires: pkgconfig Can you explain/justify the existence of *both* a pulseaudio-devel and a pulseaudio-libs-devel pkg? I'm also inclined to say that there's needless complexity splitting out separate packages for module-alsa, lib-glib2, lib-zeroconf subpkgs. These are pretty low-level, core libraries that will (should?!) be present on any audio-capable/desktop-config machine. (In reply to comment #39) > MUSTFIX: lib-devel contains pkgconfig file(s), so it ought to: > Requires: pkgconfig Hmm... is this to get the correct directory structure? Because a owner of .pc files has no need for the pkgconfig command (the users of the .pc files are the ones that need the command). > > Can you explain/justify the existence of *both* a pulseaudio-devel and a > pulseaudio-libs-devel pkg? > Of course. :) pulseaudio-devel is the headers and libraries for building modules for the server. pulseaudio-libs-devel is the headers and libraries for building PulseAudio clients. > I'm also inclined to say that there's needless complexity splitting out separate > packages for module-alsa, lib-glib2, lib-zeroconf subpkgs. These are pretty > low-level, core libraries that will (should?!) be present on any > audio-capable/desktop-config machine. I couldn't find any reasonable list of libraries that are "always present", so I went with the approach of least dependencies. Note though that a machine running pulseaudio server/clients isn't necesariliy a desktop machine. You could have a machine hooked up to output sound on your living room stereo, or you could have a dedicated mp3 player (HTPC perhaps) that you want to stream data somewhere. (In reply to comment #40) > (In reply to comment #39) > > MUSTFIX: lib-devel contains pkgconfig file(s), so it ought to: > > Requires: pkgconfig > > Hmm... is this to get the correct directory structure? Because a owner of .pc > files has no need for the pkgconfig command (the users of the .pc files are the > ones that need the command). A .pc file is useless without pkgconfig, hence packages providing .pc files should require pkgconfig. And even if you don't buy that argument, the directory that the .pc file is installed into is owned by the pkgconfig package, which is another reason why it must be required. Moreover, libpulse-mainloop-glib.pc in the pulseaudio-lib-devel package contains: Requires: libpulse glib-2.0 glib-2.0.pc is provided by glib2-devel so pulseaudio-lib-devel should have a dependency on glib2-devel. Thanks for Paul's helpful analysis, (in addition to MUSTFIX item from comment #39): 2. MUSTFIX, pulseaudio-lib-devel needs: Requires: glib2-devel Since you're upstream dev, it may be worth perusing pulseaudio's headers to see if dependancies on other pkgs exist as well (I'm betting not, but you never know). Spec URL: http://homes.drzeus.cx/~drzeus/pulseaudio/pulseaudio.spec SRPM URL: http://homes.drzeus.cx/~drzeus/pulseaudio/pulseaudio-0.9.4-2.src.rpm Update to 0.9.4 and the dependency fix included. I haven't touched the number of subpackages as I want some more comments on the current state. These are the current split out packages: pulseaudio-lib-glib2: Client side dependency on GLib 2.0. pulseaudio-lib-zeroconf: Client side dependency on Avahi. pulseaudio-module-alsa: Server side dependency on ALSA libs pulseaudio-module-lirc: Server side dependency on LIRC libs. pulseaudio-module-x11: Server side dependency on X11, SM and ICE libs. pulseaudio-module-zeroconf: Server side dependency on Avahi. Personally, I don't care for packages that pull in everything and the kitchen sink because of some optional components, hence all these sub-packages. I am open to input if the concensus is that some/all of these are excessive. 0. Comment in specfile: # configure --disable-static had no effect; delete manually. FYI, this is most likely due to your using LIBTOOL=/usr/bin/libtool No suggestion here, just an FYI. (: 1. SHOULD/COULD: You could use the %{fedora} macro (defined in Fedora's buildsystem), to conditionalize this bit: # FC5 BuildRequires: libXt-devel, xorg-x11-proto-devel # FC4 or earlier # BuildRequires: xorg-x11-devel into something like: %if "%{?fedora}" > "4" BuildRequires: libXt-devel, xorg-x11-proto-devel %else BuildRequires: xorg-x11-devel %endif But I'll leave the choice of doing this up to you (you're the one that'll have to maintain it afterall). 2. Regarding split-out server/client libs/modules. Will pulseaudio apps link with these (and automatically include them as dependancies)? If yes and/or dependancies are handled automatically for end-users, end of problem. If no, how will users' get these extra dependancies installed on their machines (other than doing so manually)? Address this last 2 issues, and I'll APPROVE this (and sponsor you). URL in comment #43 should be http://homes.drzeus.cx/~drzeus/pulseaudio/pulseaudio-0.9.4-1.src.rpm (-1 not -2) 0. It was Toshio that did those additions. The Red Hat libtool was added to avoid getting a RPATH on x86_64. 1. I'm blisfully unaware to the the available macros. I'll get that into the next revision, thanks. :) 2. Yes and no, we'll have a look, package by package: pulseaudio-lib-glib2: This is for GLib 2 applications that want to easily integrate with the PulseAudio client lib. As such, they'll have a dependency on the .so file in this package and everything will be peachy. pulseaudio-lib-zeroconf: This is similar as it provides a shared object for automatically finding PulseAudio servers and connecting to them. It does, however, also contain a command line tool that might be of interest to the users. But as apt and yum can fetch based on knowing that tools name (pabrowse), users should be able to pull it in without much trouble. pulseaudio-module-alsa: Failure to have this package will result in error messages about failing to load modules, provided their configuration states that the ALSA modules should be loaded. As ALSA is the standard API, I suppose we could remove this subpackage. pulseaudio-module-lirc: Same result here. This module provides nothing as far as clients are concerned (it allows you to directly control the server via IR), so there will be an obvious error for those trying to use the function without having the package. pulseaudio-module-x11: This is more subtle from a user's point of view. This module provides some extra authentication features (allows you to set the security cookie as a X11 property). I am a strong proponent of keeping this subpackage though as X11 can be a big dependency. pulseaudio-module-zeroconf: This is a server-side feature and will therefore result in complaints about missing modules when trying to use it without the package. So I can accept removing the ALSA subpackage, but the others should stay. Fair reasoning. So, the conclusion is to (only) drop the module-alsa subpkg (to be subsumed into -lib?), and I think this should be good to go. Spec URL: http://homes.drzeus.cx/~drzeus/pulseaudio/pulseaudio.spec SRPM URL: http://homes.drzeus.cx/~drzeus/pulseaudio/pulseaudio-0.9.4-2.src.rpm Remove the ALSA subpackage. The %{?fedora} macro isn't defined in my rpm though, so I couldn't include that part. Is it perhaps only present on the build system? Hmmm ... the URLs in comment #48 still don't work for me, pulseaudio.spec seems to be the version from 2006-08-20 and pulseaudio-0.9.4-2.src.rpm doesn't exist Curiously http://homes.drzeus.cx/~drzeus/public.html seems to contain the latest pulseaudio.spec Am I the only one having these problems? I guess it was a bit late when I uploaded those. They should work now. :) Created attachment 134695 [details]
Patch to spec to build separate jack package
When I build pulseaudio, because of having jack-audio-connection-kit installed,
the build complains about unpackaged modules:
/usr/lib/pulse-0.9/modules/module-jack-sink.so
/usr/lib/pulse-0.9/modules/module-jack-source.so
Attached a patch to include these in a separate pulseaudio-module-jack package,
if an optional --with jack build switch is used.
I'm not sure if this is the best way to do it or if there is a way to detect an
optional dependency and use it automatically. If you have jack-audio-connection
kit installed and build without "--with jack" the build will fail, so I'm sure
there's a better way - any suggestions?
Spec URL: http://homes.drzeus.cx/~drzeus/pulseaudio/pulseaudio.spec SRPM URL: http://homes.drzeus.cx/~drzeus/pulseaudio/pulseaudio-0.9.4-3.src.rpm JACK should always be built, so this version has more or less your patch (just no if:s). Re: comment #48: > The %{?fedora} macro isn't defined in my rpm though, so I couldn't > include that part. Is it perhaps only present on the build system? Yes, the buildsystem defines it, as well as a few others, like %{dist}. You can similate that via: rpmbuild --define "fedora 5" -bb pulseaudio.spec That said, package looks good, APPROVED. Now I have to figure out this sponsorship thing. (: I'm working on getting an account up, but the CLA system doesn't seem to like me. I've sent a mail to the suggested email address for help, but so far no reply. I'll keep you posted as things progress... Ok, the CLA is now accepted. I've added myself to the cvsextras group, so feel free to approve that. :) OK, you are now sponsored. Import pulseaudio into cvs, and mark this as Resolved->NextRelease when done. Note that we plan on replacing esound in FC7 with pulseaudio. pulseaudio is supposed to be some kind of drop-in replacement to esound. So for < FC7 we need pulseaudio to co-exist without conflicting or removing esound, but FC7 we need to design a smooth upgrade path for both the sound server and packages that currently depend on it by name. So it will be moved into core then? Per Warren's comment, I'd venture -> Core sometime after FC-6 release and before FC-7. (: Does this current version co-exist with esound without causing conflicts? No direct conflicts no. Only one can have the local socket though of course. There aren't really any ways pulse can conflict with esound, apart from replacing "esd" with the esdcompat script. Package Change Request ====================== Package Name: pulseaudio Updated Fedora Owners: lpoetter,drzeus-bugzilla I am upstream of this package and Pierre agreed to co-maintain this package with me from now on. CVS done. Maintainer is OK with the change as per previous conversation with him. Package Change Request ====================== Package Name: pulseaudio New Branches: EL-5 Owners for new branch: lkundrak cvsextras commits for new branch: yes cvs done. |