[00:19] <GrueMaster> TheMuso: Ping.  Have you seen this issue with alsa 1.0.25? http://paste.ubuntu.com/853433/ Lines 2-4.
[00:20] <GrueMaster> Not sure if it is a pulse issue or an alsa issue.
[00:38] <GrueMaster> definitely new to alsa-lib 1.0.25.  I just reverted to libasound2_1.0.24.1-4ubuntu1 and I don't get that error.
[00:38] <Neko> maybe it's old or corrupted? :D
[00:39] <GrueMaster> Neko: New image.  Probably just need to kick pulse to work with some change in upstream alsa.
[00:43] <GrueMaster> Guess I'll need to see if I can reproduce this on x86, since it is pulse-alsa.conf.
[00:47] <GrueMaster> Yea, I can reproduce it on an x86 VM instance with "sudo alsactl restore".
[02:28] <GrueMaster> Well, I have a solution to the pandaes audio issue.  Not perfect, but works within the current confines of alsaucm.
[02:28] <GrueMaster> Will upload tomorrow, when my eyes are no longer crossed.
[05:07] <TheMuso> GrueMaster: I just fixed some of those alsa-lib errors you showed me the other day, seems 1.0.25 changed some syntax for its conf files.
[07:45] <NCommander> aramadxp images now building momentary
[08:51] <ppisati> ogra_: why is it called the FINAL arm meeting? do you plan to commit mass suicide after it (e.g. Lemmings)? :)
[09:09] <janimo`> ppisati, the ARM team within Canonical is being dissolved and its memebers assigned to other teams in the company
[09:17] <rbasak> NCommander: around? Daviey asked me about http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html - are you aware of the "linux-armadaxp-tools-3.0.0-1500 has no installation candidate" in there, or is that resolved now?
[09:18] <NCommander> !@#$#!@!
[09:18] <NCommander> we shouldn't be building linux-tools
[09:18] <NCommander> ^- cooloney
[09:19] <cooloney> linux-tools built failed under armhf
[09:20] <cooloney> so i disable it in out linux-armadaxp package due to urgent upload request
[09:20] <cooloney> it can be built under armel, i think
[09:23] <NCommander> cooloney: I don't think we even need it
[09:24] <cooloney> NCommander: perf is very useful tool even for arm, we use it a lot for ti-omap4
[09:24] <cooloney> NCommander: and I saw some new tools was added from Marvell LSP
[09:24] <NCommander> cooloney: what would it take to fix it ?
[09:25] <cooloney> NCommander: i guess it's related to compiler, but don't have much time to take a look
[10:18] <infinity> cooloney: Oh, can you merge my latest armadaxp upload into git?
[10:18] <infinity> (I really should request zinc access)
[10:20] <infinity> cooloney: Oh, I see in another channel that you're already on top of it.  Nevermind. :)
[15:50] <GrueMaster> ogra_: Did you get my email on the pandaES audio situation?
[15:50] <ogra_> GrueMaster, yes, looks ok, lets upload it after someone (i.e. infinity) also eyeballed it quickly
[15:51] <ogra_> that udev rule is our hack anyway, adding another few lines for PandaES wont do any harm
[15:55] <infinity> ogra_: I'm sure you and Tobin are enough of a review.  And I'm happy to not take the blame on Panda audio this cycle. ;)
[15:55] <ogra_> haha, ok, then i'll just upload after the call
[16:37] <ogra_> WHEEE!
[16:37] <ogra_> so chromium 17 seems to work just fine on armel
[16:37] <ogra_> looks shiny, but takes twice as long as FF to start
[16:45] <infinity> ogra_: Yeah, no big shock there.  It's just as bloated, just differently. :P
[16:46] <ogra_> yep, but its great to have it after we had to live with 14 for ages
[16:48] <GrueMaster> Not seeing chromium for armhf (at least not on my mirror yet).
[16:52] <ogra_> GrueMaster, thats what we taljked about in the meeting :)
[16:52] <ogra_> only armel yet
[16:53] <ogra_> but it builds there for the first time in years
[16:54] <GrueMaster> ah, ok.
[17:07] <mahmoh> NCommander: armadaxp netinstall uImage resets, bug 939645
[17:07] <mahmoh> (which doesn't exist yet)
[17:07] <NCommander> mahmoh: the image fails to boot?
[17:07] <NCommander> greaaaaaaaaaaaat
[17:07] <mahmoh> right
[17:08] <NCommander> GrueMaster: ^, can you take a look?
[17:08] <mahmoh> ubot2`: ?
[17:08] <GrueMaster> NCommander: Can I nuke the armada here or do you have data that you want to keep?
[17:08] <mahmoh> for me at least, I'm using the 1500.3 uImage and the net installer uInitrd now
[17:08] <NCommander> GrueMaster: nuke and path.
[17:08] <NCommander> *pave
[17:09] <GrueMaster> ok
[17:09] <GrueMaster> I'm in a meeting now, but will be soon.
[17:09] <NCommander> mahmoh: so it doesn't boot at all? You got the bootargs right?
[17:10] <mahmoh> NCommander: it loads and tries to boot but resets immediately
[17:10] <NCommander> mahmoh: ugh, might be an issue with the mkimage commands
[17:10] <infinity> mahmoh: Gets into userspace, or dies in kernel init?
[17:10] <mahmoh> disclaimer: I did tftpboot it though but the checksum was fine so ...
[17:11] <mahmoh> infinity: dies before kernel init, right after load - you should be able to get to the bug
[17:11] <infinity> Oh, shiny.
[17:11] <infinity> (And no, I can't get the bug, I don't have the hardware)
[17:12] <mahmoh> infinity: I meant see the bug (maybe) to see the details of where it fails exactly
[17:13] <mahmoh> Starting kernel ...  interrupt request pc : [<0000803c>]          lr : [<006505cc>] sp : 005ffde0  ip : fffeffff     fp : 006d6ce8 r10: 005fff98  r9 : 00000bdc     r8 : 005fffcc r7 : 00000018  r6 : 005ffdec     r5 : 00000000  r4 : 005ffef7 r3 : 00008010  r2 : 000000f8     r1 : 00000bdc  r0 : 0040ff14 Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32 Resetting CPU ...
[17:13] <mahmoh> NCommander: the good news is the uInitrd looks like it's fine so far ...
[17:30] <NCommander> mahmoh: god thats special
[17:31] <NCommander> mahmoh: try it with a differentuImage
[17:42] <GrueMaster> Yea, I see the same thing.  Will look at the kernel a little.
[17:48] <GrueMaster> Did the linux-armadaxp meta get bumped?  It seems to be pulling linux-image-3.0.0-1500-armadaxp 3.0.0-1500.2 instead of 3.0.0-1500.3
[17:50] <GrueMaster> apt-get dist-upgrade is pulling the kernel in, but usually I should be able to just do apt-get update && apt-get install linux-armadaxp to update the kernel.
[17:53] <GrueMaster> grrr.  resolvconf install error.
[17:56] <infinity> GrueMaster: That trick only works in the case of ABI bumps.
[17:56] <GrueMaster> ok.
[17:56] <infinity> GrueMaster: No ABI bump means no new linux-meta, means you need to upgrade the kernel image itself, not count on linux-meta to do it.
[17:56] <infinity> (But, as you note, apt-get upgrade gets it right)
[18:01] <GrueMaster> Guess I'm just used to more that a minor change with new kernels.
[18:03] <GrueMaster> Ok, the kernel in ubuntu-ports/dists/precise/main/installer-armhf/20101020ubuntu113/images/armadaxp/ is busted.  Not even sure of it's origins.
[18:08] <micahg> infinity: sorry, I started to look at it, but lost my session (forgot to run in screen)
[18:08] <micahg> infinity: for chromium on armhf, if someone else has time to look, feel free
[18:08] <infinity> micahg: Oops.
[18:09] <infinity> I'm pretty craptacularly busy today, but remind me tomorrow to kick off a build, so I can look at it Monday. :P
[18:09] <infinity> GrueMaster: Yeah, I think the SRU 2-week cadence with an ABI bump almost every time has conditioned people to assume that new kernel == new ABI.
[18:12] <micahg> infinity: that's about the same timeframe I have :)
[18:18] <GrueMaster> ppisati: The mmap patch seems to have fallen out of the 2.6.35 omap4 kernel.
[18:21] <ppisati> GrueMaster: uh? it was there
[18:21] <ppisati> GrueMaster: wait
[18:23] <ppisati> GrueMaster: gitweb on kernel.u.com is sloooooooowwww...
[18:24] <ogra_> use bzr !
[18:24] <ogra_> :P
[18:25] <ppisati> ogra_: i'll send a pull req to convert from git to bzr :)
[18:25] <ppisati> GrueMaster: patches are still there
[18:25] <ppisati> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=2956dd26b949343aca5581356bff6c1cf18a22c2
[18:25] <ppisati> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=ddc72fa76d3965ca3576cfbc7a1de6e1e4b4a681
[18:25] <ppisati> M/omap4
[18:26] <GrueMaster> Maybe in the tree, but the tests are failing.
[18:26] <GrueMaster> sudo ./mmap-test
[18:26] <GrueMaster> Couldn't allocate the heap: 1902Mb
[18:26] <ppisati> doh!
[18:26] <ppisati> SRU kernel?
[18:26] <GrueMaster> These are the tests included from the earlier bug (can't remember the bug number.
[18:26] <GrueMaster> Yes, latest SRU kernel.
[18:26] <ppisati> ok, i'll check it out
[18:27] <GrueMaster> 2.6.35-903-omap4 #31-Ubuntu
[18:27] <ppisati> remind me where the test are located
[18:27] <ppisati> *these tests
[18:27] <GrueMaster> I'm trying to find the original bug.  It was fix released a while ago.
[18:28] <GrueMaster> (and of course the bug isn't in the test source.
[18:32] <GrueMaster> https://bugs.launchpad.net/bugs/861296
[18:32] <ubot2`> Launchpad bug 861296 in linux-ti-omap4 "mmap fails to allocate 2030Mb heap on ARM" [Undecided,Fix committed]
[18:32] <xranby_ac100> GrueMaster: the original bug was that eclipse failed to compile on arm
[18:33] <xranby_ac100> since the eclipse build passed some herejava please use insane amounts of memory plx
[18:33] <xranby_ac100> and this made x86 builds pass while arm where failing due to this bug
[18:33] <GrueMaster> xranby_ac100: I think it was renamed or a new bug with specific info was created (see above).
[18:35] <xranby_ac100> im not sure there exist an original bug.. try ask doko
[18:35] <xranby_ac100> since it was clear mmap did not behave identical on x86 and arm i filed the above bug
[18:35] <GrueMaster> xranby_ac100: I already posted the link (see backscroll).
[18:35]  * xranby_ac100 scrolls back
[18:36] <xranby_ac100> GrueMaster: before i rejoined?
[18:36] <GrueMaster> bug 861296 is what I was referring to.
[18:36] <ubot2`> Launchpad bug 861296 in linux-ti-omap4 "mmap fails to allocate 2030Mb heap on ARM" [Undecided,Fix committed] https://launchpad.net/bugs/861296
[18:36] <GrueMaster> It has the mmap-test source.
[18:38] <infinity> xranby_ac100: haskell-src-exts and qtwebkit-source are still FTBFS with OOMing issues.
[18:38] <xranby_ac100> (07:26:30 PM) GrueMaster: Couldn't allocate the heap: 1902Mb  <---- how much swap are in use on your test system?
[18:39] <infinity> I'm not convinced that it's this particular issue, though.  I can get the mmap test to pass on some kernels where the builds will still fail. :/
[18:39] <GrueMaster> SwapTotal:      33554428 kB
[18:39] <xranby_ac100> ok
[18:40] <infinity> I think I probably need to spend some solid time revisiting that next week and hunt down the root cause before we get too close to release.
[18:40] <GrueMaster> xranby_ac100: I run the same SRU test suite on all platforms and kernels.  This passed on the previous kernel for this platform.  Every image is installed from netboot & preseed.
[18:41] <xranby_ac100> GrueMaster: i am convinced
[18:41] <xranby_ac100> btw, thank you for running those tests
[18:41] <GrueMaster> I added them to my SRU regression testing specifically for this reason.
[18:46] <infinity> micahg: Kicking off a chromium testbuild locally now, but yeah, my timeframe for looking at it is probably still Monday. ;)
[18:48] <infinity> micahg: Kicking off a chromium testbuild locally now, but yeah, my timeframe for looking at it is probably still Monday. ;)
[18:53]  * ppisati -> EOD
[18:54] <GrueMaster> ppisati: Also, still missing headers from the dove headers package.
[18:55] <GrueMaster> linux-headers-2.6.32-423 is virtually empty.
[18:55] <GrueMaster> (changelog & copyright info only).
[18:55] <infinity> GrueMaster: Yeah, didn't we agree that we just didn't deeply care anyway? :)
[18:56] <GrueMaster> infinity: really should be a kernel team call on that, but in general yes.
[18:56] <GrueMaster> (and I had thought he was going to look at it).
[18:56] <infinity> GrueMaster: well, yes.  If they care, they can fix it.  But I'm betting they don't if we don't.
[18:56] <infinity> And I'd be shocked if we had any dove users.
[18:57] <ogra_> we do !
[18:57] <ogra_> GrueMaster !
[18:57] <infinity> ogra_: I said users, not QA testers. :P
[18:57] <ogra_> heh
[18:58] <GrueMaster> I think there are commercial users, but maybe not for this specific kernel.
[18:58] <infinity> ogra_: If GrueMaster's desk is representative of our average user, we're doing a pretty poor job of targetting, well, normal people.
[18:58] <ogra_> surely not on dove devboards
[18:58] <GrueMaster> I know HP has a little desktop system (I've seen one at a friends house).
[18:59] <ogra_> did they ever sell that armada ebox they showed in brussels ?
[18:59] <infinity> Ubuntu: Linux for Crazy People?
[18:59] <ogra_> isnt it that ?
[18:59] <GrueMaster> And it has our kernel patches at least.
[18:59] <ogra_> from crazy people for crazy people
[18:59] <infinity> I'm pretty sure I have a t-shirt that says something about Human Beings.
[18:59]  * GrueMaster is having issues with LP.
[18:59] <infinity> QA people don't qualify.
[19:00] <GrueMaster> That's why my blog is titled "Terminal Insanity".
[19:00] <infinity> ;)
[19:00] <ogra_> GrueMaster, about time you gain membership
[19:00] <ogra_> so it shows up on planet
[19:01] <GrueMaster> Yea, I looked into that a while ago.  Lot of hassle.
[19:01] <ogra_> heh
[19:01] <ogra_> not really
[19:01] <GrueMaster> And I just haven't had the spare cycles to jump through the hoops.
[19:01] <ogra_> one wikipage that lists your contributions
[19:02] <ogra_> and one evening to attend the rmb meeting
[19:02] <mahmoh> NCommander: GrueMaster: otherwise, the net-installer works fine as far as I can tell, need to preseed it now to enable nightly install verification testing
[19:02] <NCommander> mahmoh: I'll takea hammer to it
[19:02] <ogra_> you surely got enough bugs under your belt to qualify easily
[19:02] <GrueMaster> mahmoh: I'll pass you my preseed.
[19:02] <mahmoh> thx
[19:04] <GrueMaster> Guhhh.  What is going on with our web servers?  paste.ubuntu.com is slow, lp is almost non-existant.
[19:05] <GrueMaster> and email is also having issues.
[19:06] <infinity> GrueMaster: No issues here, perhaps you're suffering routing issues to the DC?
[19:06] <GrueMaster> Must be.
[19:07] <GrueMaster> ping seems fine.
[19:57] <GrueMaster> mahmoh: http://paste.ubuntu.com/854454/
[19:57] <GrueMaster> That's the preseed I am currently working with.
[19:58] <mahmoh> GrueMaster: thx!
[23:05] <slangasek> janimo`: for this apr upload in the freeze queue, what's the definition of "recent enough" for the kernels?
[23:07] <ogra_> slangasek, hey, thanks for the welcome mail ! :)
[23:07] <slangasek> :-)