[01:10] <rovanion> I'm trying to build despotify on Ubuntu 9.10 but when trying to make I get a good couple of errors: http://pastebin.org/70412 And please point me in the right direction if I'm in the wrong channel
[01:18] <emgent> dendrobates: ola ;)
[01:20] <dendrobates> emgent: hi
[01:38] <geser> rovanion: looks like you're missing libao-dev (at least, perhaps other packages too)
[01:56] <rovanion> Thank you a lot geser, have a great day!
[14:34] <ScottK> jdstrand: I see from LP you're working on the Spamassassin Y2010 problem.
[14:34] <ScottK> Which releases are you doing?
[14:35] <ScottK> I'll do the others
[14:36]  * ion laughs at http://people.canonical.com/~scott/daily-bootcharts/
[14:37] <ScottK> jdstrand: Nevermind.  Saw your note in the bug now.
[15:17] <reduz> guys, simple question, WHY is pulseaudio used by default in ubuntu? it's always broken and full of bugs on every machine i installed ubuntu
[15:17] <reduz> crashes, causes sound corruption, etc since at least 3 ubuntu versions
[15:17] <reduz> or goes to 100% CPU when using small buffers
[15:17] <hunger> reduz: No idea! It is even installed in kubuntu for some reason.
[15:18] <ion> Theoretically, something like PulseAudio is totally the right way to go. As for anecdotes, here’s another: it works fine for me. :-P
[15:20] <hunger> ion: Why is pulseaudio the right way to go? I thought alsa made this whole audio daemon crap obsolete.
[15:21] <alkisg> alsa can't stream over the network. So pulseaudio is required for thin clients (just _my_ case)...
[15:22] <reduz> well, over here pulseaudio corrupts sound
[15:22] <reduz> the begining of each sound
[15:22] <ion> Audio interfaces that look like you’re communicating directly with the hardware has problems. For instance, network transparency is not nice to achieve with them. They have hard time providing low latency for applications requiring it and low CPU use for applications that don’t need low latency. Something that provides a higher-level interface is good.
[15:25] <reduz> ion, yeah because of something that 0.001% of the people using a desktop need, you add a whole new layer of complexity you have to mantain and bugs often for 99.9999% of the rest of the users. That's not good thinking
[15:25] <ScottK> hunger: Pulseaudio is not part of the standard Kubuntu install.  If you have it then it was dragged in as a recommends/depends of something else you installed.
[15:25] <ion> reduz: Switch the numbers with each other.
[15:26] <reduz> ion, network transparency? i think not
[15:26] <ScottK> ion: I have yet to require any of Pulseaudio's unique functionality.
[15:26] <ion> Low CPU use when needed, low latency when needed.
[15:26] <ScottK> (not saying some people don't need it, but it's certainly not everyone)
[15:26] <reduz> ion, sorry, but pulseaudio is not low latency friendly
[15:27] <reduz> it climbs to 100% cpu in most cases, while regular alsa or OSS4 do fine
[15:27] <reduz> even the own pulseaudio developers aknowledge that it's not low latency friendly
[15:27] <ScottK> reduz: It's a decision that was made 2 years ago, so there's no chance of them going back.  It's really not worth your time to argue about.
[15:28] <reduz> ScottK, i don't mind pulseaudio itself, but that it's full of bugs :(
[15:28] <ion> reduz: It can provide lower latency than the hardware itself can provide by using an accurate timer to put new audio data just after the hardware play position instead of having to rely on interrupts from the hardware requesting new audio data early.
[15:28] <ion> That means long hardware buffers can be used, which means less interrupts, which means either low CPU use or low latency, depending on what the application request.
[15:28] <ScottK> ion: Then why isn't it used in Ubuntu Studio? I'd think they'd want that.
[15:29] <reduz> ion, what you are saying makes no sense at all. if the app request a certain latency, pulseaudio shouldn't do anything
[15:29] <reduz> ion, apps already know what latenc they need, otherwise they wouldn't pass a buffersize as opening param
[15:30] <ion> scottk: At the moment, JACK is better for professional audio, since it provides audio (and MIDI IIRC) routing within and between applications. Perhaps they’ll be merged one day.
[15:30] <ion> reduz: You’re still thinking at too low level.
[15:32] <reduz> ion, i understand what you mean, but then again, that's too dependent on hardware as far as i remember
[15:32] <reduz> as in, not all hardware works the same way
[15:33] <ion> PulseAudio could, for instance, take 20 seconds of audio ahead from an MP3 player. If you seek or jump to another song, it can drop the buffer, immediately start playing the new thing, taking a short chunk of new audio initially and then taking exponentially longer chunks up to the upper limit if there’s no further user changes.
[15:33] <ion> An interface that looks like the application’s banging raw hardware just can’t provide something like that.
[15:34] <ScottK> slangasek or jdstrand (you two are the only ubuntu-sru members connected at the moment): Please have a look at Bug #502071 as it's a pretty urgent SRU (impact can be as bad as all not explicitly whitelisted mail gets marked spam).
[15:34] <ScottK> Sorry, jdstrand/jdong
[15:34] <ion> reduz: All PC audio hardware provides a buffer of certain length and at least interrupts.
[15:35] <ion> That’s pretty much all you need to do the magic PulseAudio does. The MacOSX audio system does the same.
[15:35] <reduz> ion, well, to make it short, pulseaudio is bugged on my system and sound is all corrupted. Any idea how to fix it or hints on how to find a similar report?
[15:35] <reduz> ion, or at least how to disable it?
[15:36] <ion> The usual way. Search at launchpad. If no-one has reported the same issue, run apport-bug pulseaudio.
[15:39] <ion> Ubuntu’s PulseAudio packaging is a bit crippled in 9.10, that can cause problems. Lucid fixes part of that (rtkit) but not yet everything (flat-volumes).
[15:42] <jdong> ScottK: ACKed. Ouch, what a painful way to welcome the new year
[15:42] <reduz> well, i'm left with no audio again
[15:42] <reduz> it's been 3 ubuntu versions i can't use alsa+pulse because pulseaudio fucks up
[15:43] <ScottK> Thanks jdong.  I'll accept them.
[15:43] <reduz> so i guess i'll go install OSS4.. again
[15:45] <alkisg> reduz: if those sound problems are with SDL apps, there are known workarounds...
[15:46] <reduz> alkisg, no, happens for every single app
[15:46] <alkisg> ok
[15:46] <reduz> pulseaudio just probably dislikes my pro-soundcard
[15:46] <reduz> alsa/oss work fine with it
[15:46] <reduz> as well as windows
[15:48] <reduz> eh
[15:49] <reduz> where is asoundconf? :(
[15:49] <reduz> guess it's gone in 9.10
[15:51] <reduz> it seems pulse cannot be removed in ubuntu anymore?
[15:53] <reduz> ah found to do it
[15:53] <reduz> and as usual, sound works flawlessly without it
[15:54] <reduz> ah... mixer applet no longer works without pulseaudio, good.
[15:58] <reduz> well, guys i really appreciate your work but it seems ubuntu is no longer for me
[17:14] <hyperair> how does one boot ubuntu in rc 3 instead of rc 2?
[17:16] <sladen> upgrade
[17:20] <ion> hyperair: Pass 3 as a parameter to Linux.
[21:00] <lamont> is there a magic command to fetch-n-install ddebs?  or do I just fetch'em manually?
[21:06] <bdrung_> ScottK: is my answer to bug #500870 enough?
[21:07] <ScottK> Looking
[21:47] <bdrung_> ScottK: why not carrying this patch until either cdbs or the policy is fixed?
[21:48] <ScottK> bdrung_: The CDBS change is on purpose to save CD space and because of the way it works, should always be policy compliant.  There may be other cases that the lintian check legitimately catches.
[21:48] <ScottK> So there isn't any fixing of policy or CDBS to do.
[21:49] <ScottK> Can you make it so that instead of turning off the check entirely, it's only turned off for CDBS packages that do the symlinking by design in Ubuntu?
[21:53] <geser> lamont: if I read the manpage of "apport-retrace" correctly it should install the needed ddebs for you (if you have a .crash file)
[21:56] <bdrung_> ScottK: that could work. a package is a CDBS package when it build-depends on cdbs?
[21:57] <ScottK> I'd assume so.  I can't think of another reason to build-dep on CDBS.
[21:58] <ScottK> bdrung_: For bonus points, only stop the check if you're running on Ubuntu.  Then maybe the patch could go upstream and we could sync again.
[22:01] <bdrung_> ScottK: we can't check, if we are running on ubuntu
[22:01] <ScottK> bdrung_: But you can check if the package has an ubuntu version string
[22:02] <bdrung_> ScottK: that's not enough. synced package will have symlinks, too.
[22:02] <ScottK> bdrung_: Who runs lintian on sync'ed packages?
[22:03] <bdrung_> ScottK: me :)
[22:03] <ScottK> Then you're free to ignore it.
[22:03] <ScottK> We had lintian sync'ed from Debian before and I think that's a good general state of affairs.
[22:05] <bdrung_> ScottK: for example i work on audacity. i build it on ubuntu and test it there, but upload it to debian. therefore i will see this warning every time.
[22:06] <ScottK> bdrung_: You should also build it on Debian.
[22:06] <bdrung_> ScottK: before uploading i build it in a sid pbuilder environment.
[22:15] <bdrung_> ScottK: should i work on the cdbs check, or do you insist on syncing?
[22:17] <ScottK> bdrung_: Even if it's uploaded to Ubuntu first, I'd like to have something that might get accepted upstream.
[22:17] <ScottK> Other potential sponsors may have a different view.
[22:20] <bdrung_> ScottK: there is probably no way to get it into debian (without playing with lsb_release), have a look at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536434
[22:22] <ScottK> bdrung_: Given what I've suggested is already in Lintian, yes, I think it should be sync'ed.
[22:40] <bdrung_> ScottK: is there a special procedure for package removals, or is it just filing a bug report and subscribing ubuntu-archive?
[22:41] <ScottK> bdrung_: That's mostly it.  There's a wiki page that says what needs to go in the bug.  I don't recall which one.
[22:44] <geser> I check rbuild-dependes, rdepends (and mention the status) and mention the reasons for the removal (e.g. existing Debian removal bug)
[22:46] <bdrung_> geser: can i request two removal in one bug report or should i split it? (remove A and B, B depends on A)
[22:47] <geser> in that case I'd use one bug (either both go or both stay)