Just when I said that I was resuming my work as a PulseAudio maintainer in Gentoo, Lennart released a 0.9.16-test1 tarball. This was my cue to enter the scene upstream: the first test at packaging this in Gentoo failed, for a series of different reasons, some of which are internal (we don’t have the latest version of udev available yet, I hope we will by the time PulseAudio 0.9.16 final is releasd), but most are due to upstream changes that didn’t take into consideration some corner cases that Gentoo, as usual, gets to deal with.
So you won’t see the test1 (rc1) ebuild in the tree at all, you’ll probably have to wait for test2, and even that will require some work. For now I’ve fixed all the build- and run-time issues I’ve seen in the released tarball and git repository; plus I’ve been able to get it to properly build fully on both (Gentoo/)FreeBSD and OpenSolaris (with Prefix). I haven’t been able to experiment with actually having it playing yet, but it’ll come there at one point.
Unfortunately there are still a few shady details that I or someone else has to take care of. For instance, the tests still fail consistently: last time I tried them I got two failures on Yamato, one related to IPv6 enabled in PulseAudio build, but not enabled for the kernel, resulting in the IP ACL test asseting out (now I’ve fixed it, by warning of the case, and ignoring it as a failure); the other is the mixing test, which fails for everybody because it doesn’t know anything about the 24-bit and 24-bit-in-32-bit sample types; this I extended to support 24-bit, but was unable to do anything about the 24-bit-in-32-bit because I couldn’t grok it properly.
On non-Linux operating systems (FreeBSD and OpenSolaris), I had to work on a few more issues, like implicit declarations (there still is one in OpenSolaris), shadowed names, and of course there is some slight porting to be done, which I have nowhere near finished yet: the shm (Shared Memory) support in FreeBSD is imperfect, and for neither operating systems I’ve implemented the “get process name” function.
Okay I’m not able to provide a 100% porting to all the operating systems out there, but I still think I can do a bit to help out by making sure that PulseAudio won’t need to be extensively patched by all the porters out there. And until Lennart actually gets around merging my patches, you can find all them at gitorious so you can test them.
Update (2017-04-22): as you may know, Gitorious was acquired by GitLab in 2015 and turned down the service. This means you can’t access those patches anymore.
Good work, hopefully with your help Pulseaudio will “just work” with out any twiddling
Lennart doesn’t give a crap about platforms other than Linux and distros other than Fedora. The guy derides Gentoo users at any opportunity. Why bother?
Because like it or not pulseaudio is the future, if folk like Flameeyes don’t put in the work then we’ll fall behind
KDE people are skeptical of pulse, and rightly so. ‘Like it or not, it’s the future?’ They’ll be keeping their options open, and so will I. Options, you know? Choice? Linux? Gentoo?All I’m saying is Lennart has his head up in *kit madness, and is likely to insert timebombs when he detects we’re not running His work As He Intended. No consolekit/policykit/lock-me-out-of-my-comp-without-x-and-dbus-kit? HERESY!
You have no idea what you’re talking about, have you?PulseAudio works fine without X and DBus; if you need it on an embedded setup. But desktop setups should not be that way at all. The only problem seems to be with multiseat, but any other case is well working with user sessions.And of course Lennart won’t support setups he didn’t desgin to begin with, it’s not his task! For the Gentoo setup is the Gentoo maintainer (i.e.: me again now) that should be handling them!
Thank you, Diego, this kind of work is really needed for a distribution! …although I believe that KDE should develop user tools that integrate better with pulse (Kmix?). I’m not the first one to have this feeling: http://brainstorm.ubuntu.co…
It’s nice to read your posts about Pulseaudio, Diego. Sometimes I feel that you’re not focused enough on a single issue (getting proper pulseaudio support in Gentoo, not in *bsd/solaris would be a nice example of what I would expect), but all the bashing seems completely useless to me.Keep up the good work, I’m very confident you have the knowledge to decide in what way pulseaudio can/will be good for gentoo!
Well, AFAIK, last thing that stops udev 143 fromportage is util-linux release containing libuuid- planned for 2.16 (though it would be nice, ife2fsprogs-libs would get a release at the same timewith an option to disable its libuuid, so we coulddo without sed-ing that).Without that upgrade would be much more painful,including possibly circular deps.That’s just the effect of all of those recent interpackagelibrary moves (libblkid, libuuid, etc.).udev 143 doesn’t seem to break anything in anobvious way on Gentoo.On the other hand I do wonder just how wellwill pulseaudio 0.9.16 work without thatRealtimeKit stuff.
Pulseaudio without DBus is supposed to work?What’s this then:
RIDICULOUS!