[08:39]  * apw yawns
[08:39]  * smb pats apw
[08:40]  * apw wags his tail
[08:41]  * smb did not want that much info... :-P
[09:09]  * ppisati -> reboot
[11:49]  * ppisati -> back in ~10
[12:03] <Fudge> hi how can i find out which module is responsible for sound with Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) (rev 40)
[12:18] <apw> Fudge, does lspci -nnvv tell you?
[12:18] <apw> but if its HDA it'll be that the intel hda driver with a code specific to the card
[12:19] <apw> Fudge, and then if so aplay --list-devices may help
[12:19] <apw> card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
[12:19] <apw> for exmaple for me i get that
[12:20] <Fudge> apw  strange, at the bottom of the card in the first -nnvv you said, i get Capabilities: <access denied> Kernel driver in use: snd_hda_intel Kernel modules: snd-hda-intel
[12:22] <Fudge> card 0: SB [HDA ATI SB], device 1: ALC889 Digital [ALC889 Digital]
[12:23] <apw> so thats the one then
[12:25] <Fudge> its a pretty new gigabyte amd board, the sound is pretty shocking seemlingly
[12:26] <Fudge> to track down sound probs would it be something like, the module, alsa, pulse im not sure where to start
[12:26] <apw> Fudge, what are the symptoms 
[12:26] <Fudge> when it boots the sound is very crackly
[12:27] <Fudge> not like the standard sometimes record static you used to hear on a album
[12:27] <Fudge> like a big round record ...
[12:27] <apw> diwic, what is that option to ignore the hda pointer thingy 
[12:27] <Fudge> this actually echos several times for everything playing, if i get another stream going under a different user like root and make espeak say something, it clears up
[12:27] <diwic> apw, looking for https://wiki.ubuntu.com/Audio/PositionReporting ?
[12:28] <diwic> apw, not sure if that's what you mean with "pointer thingy"
[12:28] <apw> diwic, yep thats the one ... thanks
[12:28] <apw> Fudge, that is a good place to start
[12:29] <diwic> A good place to start is https://wiki.ubuntu.com/DebuggingSoundProblems .
[12:29] <apw> diwic, thanks
[12:29] <apw> Fudge, have at it, and let us know... do file a bug
[12:29] <diwic> but yeah, for crackling sound PositionReporting is one thing to try
[12:30] <Fudge> diwic  yes thank you, apw  I will try now
[12:30] <diwic> Fudge, what ubuntu release?
[12:30] <Fudge> current alpha2
[12:30] <diwic> oh
[12:31] <diwic> haven't heard of any crackling stuff for 12.04; and we fixed ATI around natty I think
[12:42] <Fudge> ok the first fix1 made the audio come good in about five seconds
[12:42] <Fudge> the second fix2 made it not cracle but my sound was breaking up
[12:43] <Fudge> which sux when i rely on text to speech lol, i now jsut tried the udev mod and it didnt appear to make a lot of difference
[12:48] <ppisati> tgardner: refrain from uploading P/omap4, i want to rebase it on top of latest master today
[12:48] <tgardner> ppisati, no problem. hadn't quite gotten to the email bucket yet
[12:49] <ppisati> k
[12:49]  * ppisati -> lunch
[12:50] <Fudge> apw  ubuntu-bug audio just asks if i would like to bug about a pulse crash, which i think may have been my fault anyway
[13:35]  * tgardner bounces gomeisa for kernel update
[13:41] <apw> tgardner, man we are getting a lot of those these days
[13:41] <tgardner> apw, what? kernel updates?
[13:41] <apw> tgardner, yep
[13:42] <tgardner> apw, it took my mirror almost 8 hours to sync yesterday
[13:50] <apw> tgardner, oh i wonder, could they have sync'd only to -security by accident
[13:50] <apw> tgardner, so you were waiting on that poor puppy
[13:50] <tgardner> apw, dang, looks like gomeisa didn't boot again
[13:51] <apw> tgardner, ogasawara, meant to ask ... do either of you have non-native build runes for powerpc at all ?
[13:51] <tgardner> apw, not me
[13:54] <ppisati> apw: something along the line - export $(dpkg-architecture -apowerpc); export CROSS_COMPILE=powerpc-linux-gnueabi-; fakeroot debian/rules clean binary-$ppc?
[13:54] <ppisati> apw: bear in mind that i guessed some values
[13:59] <apw> ppisati, do we have cross compilers installed somewhere ?
[14:03] <ogasawara> apw: sorry, I don't have any non native build runes either
[14:05] <apw> ogasawara, and how many hours does one build take there ?  one flavour ?
[14:05] <tgardner> ogasawara, gomeisa is hosed. gonna take me a bit to restore the runes for looking at the remote console. what a pain in the ass.
[14:05] <ogasawara> apw: 2-3hrs?
[14:06] <ogasawara> tgardner: ugh, hosed after an update?
[14:06] <apw> tgardner, i have been investigating why the chroot build stuff doesn't honour the http_proxy etc parameters one might offer it ... seems that we have two places the environ gets trashed, one at the first sudo and the other at the individual schroot commands ... any objection to me adding options to let those through?
[14:06] <tgardner> ogasawara, I suspect its like last time, the initrd didn't get rebuilt correctly
[14:06] <apw> ogasawara, it wouldn't be the first time that it died cause update didn't take right rather than the update itself
[14:06] <apw> what he said
[14:07] <apw> ogasawara, when you build test, do you just do one flavour or the lot ?
[14:07] <ogasawara> apw: I usually just do one
[14:07] <ogasawara> apw: I'm too impatient to do the whole lot
[14:07] <apw> has anyone tried using the qemu style thing like we do for a real arm build ?
[14:07] <apw> (for power builds)
[14:07] <tgardner> apw, I've no preference. whatever makes it work properly.
[14:08] <ogasawara> apw: I haven't
[14:08] <tgardner> apw, I did awhile back. qemu didn't work very well
[14:08] <apw> tgardner, i can't think of any good reason its not safe, given we pass that script in the tree anyhow so there is no security in it
[14:08]  * apw sighs ... its like arm all over again, without the working builds
[14:08] <tgardner> apw, well, since I don't know what you're intending, I have no objection :)
[14:09] <apw> tgardner, i am intending to add -E to the sudo incantion in the scripts, and a -p to the schroot ... which will pass the environ across allowing apt to use the proxy one has in your enviroment
[14:10] <tgardner> apw, on tangerine and gomeisa ? I didn't think we had a proxy
[14:10] <apw> tgardner, this lets you use the squid-deb-proxy style proxies to install new chroots
[14:10] <apw> tgardner, there not at the moment, though in your new world order having one on the gateway would maek sense
[14:10] <apw> tgardner, and we should consider getting something cheap for that box, to keep gomeisa as a real machine
[14:11] <tgardner> apw, I've got a nice AMD server thats not worth much as a builder
[14:11] <apw> tgardner, but here i want to use the scripts at home and while i could get them to work with apt-cahcher-ng (it has some magic to support that use case) i can't with squid, unless i can use http_proxy
[14:11] <apw> to get them installed, then i can add a proxy command inside and all is good
[14:12] <apw> tgardner, if you run these scripts again they just build the missing ones right ?
[14:12] <tgardner> apw, yep, shuold
[14:13] <tgardner> apw, you're talking about the stuff under kteam-tools/chroot right ?
[14:13] <apw> tgardner, indeed.  i want to have the exact same stuff and not have to fight them every time
[14:13] <apw> tgardner, that and i just changed proxies for convienience
[14:14] <tgardner> apw, ok, commit the changes and I'll test on my end
[14:14] <apw> tgardner, am just seeing if i can easily add the required proxy config inside the chroot if it is specified outside, if so that will rock
[14:16] <ppisati> apw: dunno, never messed with ppc
[14:18] <ppisati> apw: how about the debian/embedian one?
[14:18] <ppisati> apw: http://psas.pdx.edu/DebianCrossCompilerHowto/#index1h1
[14:21] <apw> ppisati, that might work, will put that on my list to poke
[14:21] <apw> 2.5 hours is excruciating
[14:21] <ppisati> apw: i'm testing right now
[14:21] <ppisati> apw: P kernel?
[14:21] <apw> ppisati, yeah thats the one i want to be able to build and test
[14:24] <ppisati> apw: it's compiling
[14:25] <apw> ppisati, interesting, let me know how long it takes
[14:25] <ppisati> apw: first install the embedian cross compiler
[14:25] <ppisati> apw: then
[14:25] <ppisati> apw: export $(dpkg-architecture -apowerpc);
[14:25] <ppisati> apw: export CROSS_COMPILE=powerpc-linux-gnu-
[14:25] <ppisati> fakeroot debian/rules clean binary-powerpc
[14:27] <apw> ppisati, and where do i get the embedian cross comp ?
[14:28] <ppisati> http://psas.pdx.edu/DebianCrossCompilerHowto/#index1h1
[14:28] <apw> doh
[14:28] <ppisati> they are still at 4.4 btw
[14:29] <apw> ppisati, still interesting for a quick build
[14:29] <apw> thanks, will play with those and see if they at least make a kernel for me
[14:30] <apw> bjf, did you upgrade your hed in the end ?
[14:30] <apw> bjf, i think you said you had no problems didn't you with a live-cd ?
[14:57] <ppisati> apw: ~25min on my Q6600@2.4ghz and Raptor WD@10krpm
[14:57] <ppisati> apw: linux-image-3.2.0-16-powerpc_3.2.0-16.25_powerpc.deb
[15:08] <apw> ppisati, pretty impressive indeed, thanks
[15:31] <apw> infinity, 
[15:31] <apw> bugger
[15:44]  * ogasawara back in 20
[15:57] <jsalisbury> **
[15:57] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:57] <jsalisbury> **
[16:09] <ppisati> brb
[16:17] <scott-work> can someone (maybe apw ) review the lowlatency kernel in REVU?  http://revu.ubuntuwire.com/p/linux-lowlatency
[16:18] <scott-work> if someone here were also a MOTU and can advocate it, well then, that would exceedingly awesome as well :)
[16:31] <herton> ppisati, what do you mean with POLA?
[16:47] <ppisati> herton: Principle Of Least Astonishment
[16:47] <ppisati> herton: don't make any changes that could break someone else work
[16:49] <herton> ppisati, ok, wasn't sure of what the acronym stands for, first time I see it I think :)
[17:19] <apw> smb, fyi i have pushed a fix onto the top of the chroot build scripts that let you use an exported http_proxy variable
[17:19] <apw> smb, export http_proxy=http://name-of-squid-host:8000/
[17:20] <apw> smb, and that will use the proxy for the initial installation of the chroot, and also insert that proxy configuration into the inside of the chroot as well so its configured for good
[17:20] <smb> apw, Ah ok. Should have a look at taht
[17:20] <apw> smb, and ... if you have them and change your proxy, rerunning the command will update the internal config
[17:22] <smb> apw, Ah, so it would have actually used http_proxy for the initial deboostrap
[17:24] <smb> apw, Oh, ok one had to preserve the environment, too
[17:25] <tgardner> apw, looks good
[17:26] <apw> smb, yeah you need the -E to get the http_proxy through to the dbootstrap, then i insert the proxy config for every more
[17:26] <smb> nice
[17:57] <apw> sforshee, fyi there are three .sh scripts with msmtp which give you a queue and queue runner abstraction.  seem to work here for me
[17:57] <sforshee> cool, I'll check that out
[17:58] <apw> sforshee, i just modded the enqueue to always swan the queue runner so it either sends them immediatly, or they get queued
[17:58] <apw> seems to work as i would hope
[18:26] <apw> as its some made up celebration today, i am calling it a day ... see you all on the morrow
[18:36] <herton> ppisati_, the fsl-imx51 branch is missing your email on the closing commit (the changelog you close with you name/email current date)
[18:50] <ppisati_> herton: the changelog has tim's email because he started the relase
[18:50] <ppisati_> *release
[18:52] <herton> ppisati_, yep, but you should update it on the closing commit]
[18:53] <ppisati_> herton: ok, hold on
[19:06] <ppisati_> herton: updated
[19:21] <herton> ppisati_, thanks, looking
[19:28] <herton> ppisati_, everything good, pushed
[19:31] <ogasawara> rtg_: I notice there is an ndiswrapper dkms package in main -> https://launchpad.net/ubuntu/+source/ndiswrapper so do we even need to carry this in the kernel?
[19:31] <rtg_> ogasawara, indeed? I'd be happy to drop it from the kernel.
[19:32] <rtg_> ogasawara, there seems to be 2 source packages
[19:32] <rtg_> but the dkms version is current
[19:33] <rtg_> ogasawara, yeah, I'm happy to drop it.
[19:34] <ogasawara> rtg_: it was already disabled in the Makefile, so it shouldn't have any affect if we just yank it.
[19:34] <ogasawara> rtg_: I'll rip it out and push
[19:34] <rtg_> ogasawara, well, that makes it really easy :)
[19:34] <rtg_> ogasawara, squash it out of existence
[21:10] <tgardner> ogasawara, gomeisa is back online
[21:11] <ogasawara> tgardner: sweet
[21:18] <broder> hey, has anybody looked at bug #898003? it's been sitting in the sponsorship queue for over 2 months now
[21:18] <ubot2`> Launchpad bug 898003 in linux "usbip source is maintained in kernel tree now" [Low,Confirmed] https://launchpad.net/bugs/898003
[21:18] <broder> i'm wondering whether or not it would be plausible to incorporate the usbip userspace pieces into the kernel package build (there's a client, a server, and a library), or whether we should keep snapshotting the source from the kernel into a separate source package
[21:19] <tgardner> broder, looking
[21:23] <tgardner> broder, this is still a staging driver. while we have a mechanism for building and distributing applications from the kernel source tree, I'm not sure I wanna bother with a staging driver.
[21:25] <broder> tgardner: ok. that's reasonable. it doesn't seem like it's going through a whole lot of churn anyway
[21:26] <broder> i'll work on updating the separate package
[21:26] <tgardner> broder, maybe we can pick it up when it gets promoted to mainline
[21:28]  * tgardner is EOD