[07:34]  * apw yawns
[07:35]  * smb waves
[07:36] <smb> ... and leaves to get more coffee
[07:38]  * apw makes tea
[07:54] <ppisati> diwic: i hit again the 'crackling noise'&c problem this morning
[07:54] <ppisati> diwic: but with mumble this time
[07:54] <ppisati> diwic: what was the status of the fix for R?
[07:54] <diwic> ppisati, okay, with PA 3.0 or 3.99/4.0 ?
[07:54] <ppisati> diwic: vanilla raring
[07:54] <ppisati> 1:3.0-0ubuntu6
[07:55] <diwic> ppisati, I made a package with the fix arun thought was right, uploaded to a ppa and asked people to test. No replies.
[07:55] <ppisati> diwic: doh!
[07:55] <ppisati> diwic: where is it?
[07:56] <ohsix> ubuntu-audio-dev ;D
[07:56] <diwic> ppisati, bug 1173073 comment 6
[07:56] <ubot2`> Launchpad bug 1173073 in skype (Ubuntu) "Broken sounds in Skype" [Undecided,Confirmed] https://launchpad.net/bugs/1173073
[07:56] <ppisati> diwic: let me try it
[08:00] <ppisati> diwic: i guess i need to logout, right?
[08:03] <diwic> ppisati, restarting pulseaudio is better, sometimes a logout/login doesn't trigger pulseaudio to restart
[08:03] <diwic> ppisati, pulseaudio -k
[08:04] <ppisati> smb: make some noise when you are back
[08:04] <ppisati> diwic: i restarted
[08:04] <ppisati> diwic: so far, skype is mute
[08:05] <ppisati> diwic: can't hear anything from it
[08:05] <smb> ppisati, I am making "noise"
[08:05] <ppisati> smb: now?
[08:05] <smb> yes
[08:05] <ppisati> smb: oh, i saw the lips
[08:05] <ppisati> diwic: ok, the new pulseaudio has defaned my system
[08:05] <diwic> skype is mute, but the lips refer to mumble?
[08:06] <ppisati> diwic: i have the 'cracking noise' problem with both skype and mumble
[08:06] <ppisati> diwic: hence i was trying both
[08:06] <ppisati> diwic: ok, actually my system is mute now
[08:06] <ppisati> diwic: since it don't emit any sound through skype/mumble
[08:07] <ppisati> diwic: i can still play a song
[08:07] <ppisati> diwic: but no mumble/skype
[08:07] <ppisati> :(
[08:07] <diwic> ppisati, hrm
[08:07] <diwic> ppisati, you restarted mumble/skype with the new pulseaudio too I assume?
[08:07] <ppisati> diwic: http://paste.ubuntu.com/5757463/
[08:07] <ppisati> diwic: i rebooted the box
[08:08] <ppisati> ah!
[08:08] <ppisati> skype has just emitted the first beep
[08:09] <ppisati> and now it's like in a torturing loop
[08:09] <ppisati> smb: can you hear me?
[08:09] <diwic> ppisati, uhm
[08:09] <smb> ppisati, no
[08:09] <ppisati> smb: :(
[08:09] <smb> fixed to death
[08:09] <ppisati> restared skype since it was driving me crazy
[08:10] <diwic> ppisati, pacmd set-log-level 4, then try skype or mumble (not both simultaneously!). Is there something interesting in /var/log/syslog ?
[08:12] <smb> ppisati, see lips, hear nothing
[08:14] <ppisati> diwic: http://people.canonical.com/~ppisati/pulseaudio_syslog
[08:14] <apw> diwic, am i expecting outputs and inputs to be lost over s/r in raring now ?
[08:15] <diwic> ppisati, okay, so endless streams of rewinds, exactly what the patch was supposed to *fix*, not *cause*
[08:16] <diwic> apw, could you elaborate?
[08:16] <ppisati> life is unfair... :(
[08:17] <diwic> ppisati, but that patch is in 4.0 too, so I guess I should test mumble on 4.0 and see if it still works
[08:17] <apw> diwic, by which i mean my i have external mic and speakers on USB and over s/r they used to remain the 'selected' outputs, now the defaults switch back to the internals every time
[08:18]  * ppisati goes back to vanilla PA
[08:18] <diwic> ppisati, anyway roll back for the time being
[08:19] <diwic> apw, well, it's probably due to a race between PA and the kernel, so it can change between Ubuntu versions.
[08:19] <apw> diwic, ok s/r is possibly slower right now, so that probabally accounts for it
[08:19] <diwic> apw, last time I asked somebody it was not possible to tell when the kernel has finished probing hardware
[08:20] <diwic> apw, but perhaps you know better?
[08:20] <apw> diwic, pretty much not if it is usb
[08:20] <diwic> apw, essentially, when PA resumes, usb sound appears no longer connected
[08:21] <apw> though one could listen on the udev events and as things appear if they are what i thought the default was before we could reinstate it
[08:21] <ohsix> are uevents for the device sent before it can actually be used?
[08:21] <apw> ohsix, i think the conjecture here is PA wakes and scans on 'whats still here' while the devices are still being scanned
[08:21] <diwic> apw, you mean a rule based ordering? Intel says they have something they want to upstream. We've been waiting for half a year for that.
[08:22] <ohsix> apw: it seems to race plugging in unrelated to suspending and stuff too; i've been operating ounder the assumption that you would be able to actually use the device by the time udev knows about it
[08:23] <apw> diwic, well i mean, whoever has the 'current default output' would wake up and say 'ahh crap the default is gone i supposed i'll change to the remaining thing', then later when the other device appears based on an event it could say 'oh look that is where my real default is meant to be, lets switch back transparently'
[08:23] <ohsix> that is what happens if the thing actually goes away
[08:23] <ohsix> barring interference from the desktop mixer applet :>
[08:24] <diwic> apw, right, and that can be extended to a list of devices, add to that different routes for roles and programs, and you have the big routing problem <tm>.
[08:24] <apw> diwic, well i am only really saying we should remember the 'users preferred default' for each
[08:26] <ppisati> ok, so
[08:26] <ppisati> i rolled back to 1:3.0-0ubuntu6
[08:26] <ppisati> but still can't hear anything
[08:26] <ppisati> :(
[08:26] <ohsix> fuser -v /dev/snd/*
[08:28] <diwic> apw, and we have been promised to get all that and more with Intel's routing system which we have been waiting for since October or so
[08:30] <ppisati> ok, i've sound back
[08:31] <ppisati> but still noises/crackings
[08:31] <ppisati> etcetc
[08:31] <ppisati> diwic: my previous 'muting' problem
[08:31] <ppisati> diwic: was because it selected the digital output
[08:31] <ppisati> diwic: intead of the analog one
[08:31] <ppisati> diwic: i'm on analog now + your ppa bits
[08:32] <ppisati> diwic: but there're still problems
[08:32] <diwic> ppisati, so essentially, what you're saying *now* is that the ppa makes no difference?
[08:32] <ppisati> diwic: well
[08:32] <ppisati> diwic: it's a bit better
[08:32] <ppisati> diwic: i can hear cking and apw ok now
[08:33] <ppisati> diwic: but if i start the dummy skype voice call test
[08:33] <ppisati> diwic: everything craps out
[08:34] <diwic> ppisati, and what was the skype voice call test before the ppa ?
[08:34] <ppisati> diwic: uhm
[08:34] <ppisati> diwic: wasn't working iirc
[08:34] <diwic> ppisati, so no regression at least, what about the event sounds that the original bug was about?
[08:35] <ppisati> diwic: it's a bit better now
[08:35] <ppisati> diwic: no noises are not constant
[08:35] <ppisati> diwic: i can hear the other people on mumble quite ok
[08:35] <ppisati> diwic: had some noises when i started mumble, but it's ok now
[08:36] <ppisati> diwic: ok, skype is mute again
[08:36] <ppisati> :(
[08:36] <ppisati> while mumble is ok
[08:41] <diwic> maybe I should try and see if I can reproduce it here
[08:42] <ppisati> diwic: if i can help you in any way, let me know
[08:42] <diwic> ppisati, when you say "skype is mute", does that refer to event sounds, the call stream or both?
[08:43] <ppisati> diwic: it's mute in general
[08:43] <ppisati> diwic: nothing comes out of the speakers
[08:43] <ppisati> diwic: but when it does
[08:43] <ppisati> diwic: it's either noise
[08:43] <ppisati> diwic: or a constant loop of a beeeeeeep
[08:44] <ppisati> diwic: do you want access to this box?
[08:44] <ppisati> diwic: i can fwd a port if you want
[08:44] <ppisati> let me see if syslog says anything when it craps out
[08:46] <diwic> ppisati, I'll first try setting up skype on raring and giving it a test to see if it works or not here
[08:46] <ppisati> diwic: try setting up mumble and skype
[08:46] <cking> apw http://www.maximintegrated.com/app-notes/index.mvp/id/3958
[08:46] <ppisati> diwic: join a mumble channel with people speaking
[08:46] <diwic> ppisati, simultaneously?
[08:47] <ppisati> diwic: and then try to make skype emit any sound
[08:47] <ppisati> diwic: yes, simultaneously
[08:47] <ppisati> diwic: looks like it's easier to trigger it this way
[08:48] <diwic> hmm, when searching for skype in USC, all I get is magazines in german.
[08:51] <ppisati> diwic: ok, i was able to reproduce the noise-loop
[08:52] <ppisati> diwic: and here is syslog
[08:52] <ppisati> diwic: http://people.canonical.com/~ppisati/pulseaudio_syslog_again
[08:52] <ppisati> diwic: at the end, then i -k pulseaudio
[08:53] <ppisati> brb
[08:54] <diwic> ppisati, what's the recommended method to install skype?
[08:55]  * diwic is listen in on mumble, sounds good 
[09:00] <diwic> ah, found it
[09:07] <diwic> ppisati, ok, now I did a skype test call while listening to the mumble chat, worked just fine
[09:10] <diwic> ppisati, that's with raring's PA.
[09:10] <ppisati> diwic: in my case, skype test calls always fail (no sound output at all)
[09:10] <ppisati> diwic: and it's really racy
[09:10] <ppisati> diwic: sometimes you trigger it
[09:10] <ppisati> diwic: sometimes it works
[09:12] <ppisati> diwic: do you have contacs in skype?
[09:13] <diwic> ppisati, maybe skype is hearing noise in the beginning of the call, when the voice talks ("welcome to skype call testing service"), it reduces the volume of itself because it thinks it's hearing the echo of itself
[09:13] <ppisati> diwic: can i add you in skype?
[09:13] <diwic> ppisati, diwic9 is my ID
[09:14] <ppisati> diwic: when i login/logout, do you get the notification sound? is it ok?
[09:15] <diwic> ppisati, yes, there are correct login/logout sounds from skype
[09:15] <diwic> ppisati, btw, what are the CPU powers of your machine?
[09:15] <ppisati> diwic: this is an haswell box
[09:16] <diwic> ppisati, that should be okay I assume
[09:19] <ppisati> diwic: how do i find out? cat /proc/...?
[09:20] <diwic> ppisati, /proc/asound/card*/codec*, pick the one's that not HDMI
[09:20] <diwic> s/one's that/one that's/
[09:21] <ppisati> diwic: http://people.canonical.com/~ppisati/haswell_hda_codecs
[09:21] <diwic> ppisati, ok
[09:28] <diwic> ppisati, the syslog_again log, that's from with the ppa installed, right? 
[09:29] <ppisati> diwic: yes
[09:34] <diwic> [alsa-source] alsa-source.c: Scheduling delay of 0.08ms, you might want to investigate this to improv
[09:35] <diwic> [alsa-source] alsa-source.c: Scheduling delay of 0.08ms, you might want to investigate this to improve latency...
[09:35] <diwic> sure PulseAudio should survive with more than 80 us of scheduling latency :-) 
[09:35] <diwic> probably a red herring though
[09:37] <ohsix> it actually says that? what is it using to determine how it was scheduled?
[09:37] <diwic> tsched watermark
[09:37] <diwic> it's too low
[09:39] <ohsix> oh, so not strictly scheduling
[09:41] <diwic> ohsix, if real_sleep_time - tsched_watermark > expected_sleep_time then complain
[09:43] <diwic> ohsix, hence the tsched_watermark is less than 80 us which is bad
[09:43] <diwic> I think
[09:47] <ppisati> brb
[10:23] <jampo> Is "What does a specific Ubuntu kernel version number mean?" on https://wiki.ubuntu.com/Kernel/FAQ outdated? If this info is correct, then the linux-image-3.2.0-48-generic 3.2.0-48.74 package of 12.04 would be based on kernel 3.2.0. But on http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html 3.2.0-48.74 is mapped to 3.2.46.
[10:25] <jampo> The Makefile in the current linux-source-3.2.0 (3.2.0.48.58) packages inside of /usr/src/linux-source-3.2.0/linux-source-3.2.0.tar.bz2 contains also 3.2.46 as the kernel version.
[10:25] <jampo> I am confused.
[10:33] <jampo> The last change of https://wiki.ubuntu.com/Kernel/FAQ was 2011-01-27. So I think it is outdated. And the version in the Makefile of linux-source-3.2.0 and the http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html mapping is the correct one. Correct?
[10:35] <jampo> So the latest linux-image-3.2.0-48-generic (3.2.0-48.74) package for 12.04 is based on kernel 3.2.46?
[10:39] <smb> jampo, No, the FAQ is correct. It is based on the release version of 3.2, but it also has the stable updates up to 3.246 included.
[10:39] <smb> 3.2.46
[10:42] <diwic> smb, would it make sense to then call it linux-source-3.2 instead of linux-source-3.2.0 ?
[10:43] <diwic> smb, (without saying that doing so would be worth all the tooling changes required)
[10:43] <smb> diwic, No, we went through that before. There was just too much historically depending on kernel versions having three parts
[10:45] <diwic> smb, so it would make sense, but we avoid it due to all the changes required?
[10:48] <smb> diwic, That would be my definition of making sense, actually. The 0 also makes sense in a way as spelling out it is the release version. Maybe there are other reasons as well which apw may remember
[10:49] <apw> diwic, possibly, though changing the name might be tricky for the consumers thereof
[10:49] <jampo> So linux-source-3.2.0 is not "based on" kernel 3.2.46 but "compatible with" it? If it would be "based on" then it would be really based on the v3.2.46 release tag of the kernel?
[10:50] <diwic> smb, thanks. I didn't mean to drag up an old debate (if any) so I'm satisfied with the answer :-)
[10:50] <smb> jampo, Look at it from debian packaging: the source package consist of a orig.tar.gz and a diff. And the tar is based on 3.2.0
[10:52] <jampo> smb: Thanks for the pointer. I will check http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_3.2.0.orig.tar.gz now. :-)
[10:52] <smb> jampo, Nowadays there will likely be most current stable updates applied, but that was not always the case and may be and the package number deliberately does not give any hint about what stable patches are included.
[11:00] <jampo> Verified: the version in the Makefile of linux_3.2.0.orig.tar.gz is 3.2.0 and the uncompressed linux_3.2.0-45.70.diff.gz is huge.
[11:00] <jampo> :-)
[11:05] <jampo> One last missing thing: there is no v3.2.0 release tag in the git repository of the kernel: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tag/?id=v3.2.0 and no tarball in https://www.kernel.org/pub/linux/kernel/v3.x/ Any way to find out the commit on which linux_3.2.0.orig.tar.gz is based?
[11:06] <ohsix> it's an upstream package drop
[11:06] <jampo> What does that mean?
[11:06] <ohsix> it should be in there somewhere ;D
[11:06] <jampo> From Debian.
[11:06] <ohsix> from kernel.org, it's a release
[11:07] <jampo> You mean it was released an then later removed?
[11:08]  * ppisati goes for some food
[11:13] <ohsix> jampo: i think so, yea
[11:15] <ohsix> or hm
[11:15] <jampo> I am stupid. :-)
[11:16] <jampo> Maybe the tag is called v3.2?
[11:16] <jampo> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tag/?id=v3.2
[11:16] <ohsix> there was no 3.0.x or 3.1.x, and only a 3.2-rc*, then, 3.2.1
[11:16] <ohsix> that looks plausible :]
[11:18] <jampo> That's nice, everything fits together now. Thanks for the clarification!
[11:18] <ohsix> np, i remember what people did with 2.6._40_ instead of '3' but i guess i got bored shortly after
[11:30] <infinity> apw: *pokity poke*
[11:30] <apw> yo
[11:30] <infinity> apw: Can you revert rtg's HAVE_CPLUS_DEMANGLE=n mess from the last linux and linux-grouper uploads?
[11:30] <infinity> (If he committed it to other trees, revert those too, please)
[11:31] <infinity> apw: It forces kernel uploads to be lockstep with binutils (and vice versa), which is pretty remarkably poop.
[11:31] <infinity> apw: And the bug he was working around (libiberty.a being missing) was fixed by me last night.
[11:31] <apw> in ack
[11:31] <apw> infinity, do i need to upload or are we good where we are
[11:31] <infinity> Shouldn't be an ABI bump, feel free to rapidly upload to undo the damage.
[11:32] <apw> ack
[11:32] <infinity> Otherwise, your kernel will never migrate, cause doko just pushed a new binutils. :P
[11:41] <apw> infinity, ack
[12:24] <apw> infinity, so the liberty change is in -proposed and published already
[12:30] <infinity> apw: Yeahp, has been for hours.
[12:31] <apw> infinity, these two fixes are non-abi-bumpers, so i am shoving them in with the revert
[12:31] <infinity> apw: Shiny.
[12:31] <infinity> apw: s/revert/reverts/ ... linux-grouper got caught in the crossfire here, too.
[12:31] <apw> infinity, there is one revert on master, otheres elsewhere
[12:32] <infinity> apw: (And you might want to check other HEADs to see if rtg lined up the same change for other flavours, but I'm hoping not)
[12:32] <apw> rtg_ is going to handle the others once this builds
[12:32] <infinity> Mmkay.
[12:32] <apw> at least on x86
[12:39]  * henrix -> lunch
[12:44] <apw> infinity, ok in the hole
[12:45] <infinity> apw: There's no way to interpret that that makes me feel good about that upload.
[12:45] <infinity> apw: But I'm going to take the high road, avoid the sexual innuendo, and assume that you uploaded a grenade.
[12:45] <apw> infinity, most likely :)  but ... what fun would that be
[12:46] <rtg_> infinity, I think only grouper (so far) has the MANGLE issue with binutils. I can re-upload now ?
[12:47] <infinity> rtg_: Please do.  It won't be blocking anything else, only itself, but if you wanted it in, it'll need an upload with that reverted.
[12:47] <infinity> (linux was more urgent, cause it's a tangled mess of interdependencies)
[12:47] <rtg_> infinity, ok, it'll be in the hole soon :)
[12:47] <infinity> Damn you people and your holes.
[12:49] <apw> infinity, we didn't want to fill them both at once, but you insisted
[12:49] <infinity> ...
[13:53] <apw> rtg_, that goes in ubuntu.pockets=proposed
[13:53] <apw> ubuntu.pockets=proposed
[13:59] <rtg_> apw,  line 15 [saucy-armhf-sbuild]: Unknown key 'ubuntu.pockets' used
[14:01] <rtg_> apw, Can't open /usr/share/schroot/setup/common-config
[14:04] <infinity> apw: You missed the matching linux-signed for your upload.
[14:05] <apw> infinity, bandits, will fix now
[14:45] <rsalveti> rtg_:  Depends: libc6 (>= 2.8), libdw1 (>= 0.143), libelf1 (>= 0.131), linux-maguro-tools-common
[14:46] <rsalveti> rtg_: guess the flavor specific tool is depending on flavor-tools-common
[14:46] <rsalveti> which is not yet available
[14:46] <rtg_> rsalveti, ok, I'll check on it.
[14:46] <rsalveti> rtg_: thanks
[14:48] <rtg_> rsalveti, um, it may be because flavor-tools-common has not been promoted out of proposed yet ?
[14:49] <rtg_> eh, that doesn't seem right eithetr
[14:49] <rsalveti> rtg_: are we even creating such package?
[14:50] <rtg_> rsalveti, don't think so. thats what doesn't seem right.ght be a typo
[14:51] <rtg_> rsalveti, the binary package names should be linux-maguro-tools-common and linux-maguro-tools-3.0.0-2.3. checking on the meta package now...
[14:55] <rtg_> rsalveti, the dependencies should be linux-maguro-tools -> linux-maguro-tools-3.0.0-2.3 -> linux-maguro-tools-common
[14:55] <rtg_> is that not what you're seeing ?
[14:56] <rsalveti> that's what I'm seeing, I just couldn't find linux-maguro-tools-common
[14:56] <rsalveti> rtg_: who should be in charge of generating such package?
[14:57] <rsalveti> the kernel itself?
[14:57] <rsalveti> https://launchpad.net/ubuntu/+source/linux-maguro
[14:57] <rtg_> rsalveti, yeah, its a binary generated by teh kernel
[14:57] <rsalveti> even on the one from proposed, just linux-maguro-tools-3.0.0-2_3.0.0-2.3_armhf.deb
[14:57] <rtg_> rsalveti, yeah, wtf ?
[14:58] <rtg_> rsalveti, maybe its because that package is 'Architecture: all' instead of 'Architecture: armhf' ?
[14:59] <rsalveti> rtg_: right
[15:00] <rsalveti> rtg_: for all to be published we'd need a build for i386
[15:00] <rtg_> rsalveti, cut-n-paste error
[15:03] <apw> rtg_, yeah any all packages in a single architecture package normally are : <arch> instead so that i only builds on one arch
[19:55] <rsalveti> rtg_: package still depending on linux-maguro-tools-common
[19:55] <rtg_> rsalveti, yeah, still working on it. I think I've figured it out for grouper.
[19:55] <rsalveti> rtg_: cool
[19:56] <rtg_> rsalveti, its been kind of a PITA
[20:28]  * rtg_ -> EOD
[20:48] <anon^_^> hi had a question about the -lowlatency kernel.  There appears to be two project pages on launchpad with different builds, both headed by GaryM
[20:49] <anon^_^> It makes it somewhat difficult to determine which package to use and why there are two project pages
[20:49] <anon^_^> https://launchpad.net/ubuntu/+source/linux-lowlatency
[20:49] <anon^_^> https://launchpad.net/ubuntu/+source/linux-meta-lowlatency
[20:53] <maxb> anon^_^: 'linux' = the kernel source itself, that builds packages which have ABI versioning info which often changes embedded in their names; 'linux-meta' = the metapackages which pull in the latest specific versioned packages  (or at least that's how it works in the non '-lowlatency' case, I assume it's the same)
[20:55] <anon^_^> so the safe route to go, stick with linux-meta builds which are used by default in the Ubuntu Repo