[03:34] <bvb> Well, I ended up using the 2.6.35 maverick build, and I've got vga_switcheroo running nicely or else lying to me. I was wondering, though: from reading through the wiki, it appears that the 'mainline' builds do not have the Ubuntu modifications. Would that be why the boot splash doesn't show up, or did I break something else? Also, any thoughts on what that kernel would do to a Synaptics touchpad?
[03:37] <RAOF> bvb: Mainline builds do not have the Ubuntu sauce, yes.  This shouldn't prevent the boot splash from showing up; that's likely to be configuration problems.
[03:40] <bvb> RAOF: OK, that's what I thought. I guess I'll poke around and see if I did something else to the boot splash ... although I may end up just waiting for the "official" build next month, as I'm about to start school and the thing works just fine otherwise.
[09:07] <ericm|ubuntu> lag, regarding 601226, any update on a suitable patch being upstreamed?
[09:55] <ericm|ubuntu> lag, ping
[14:46] <hallyn> asking here bc i don't know particularly where else to start - if i run a lucid livecd .iso in kvm -with '-vga cirrus' and play solitaire, it works fine.  With maverick, it hangs almost immediately.  Anyone know which driver to look at for regressions?  (both are on the same maverick host, so it may be kvm bug, but some kernel driver change seems to be triggering it in any case)
[14:47] <hallyn> it's making testdrive of maverick images pretty much unusable...
[15:00] <tgardner> hallyn, just ran a maverick daily on a lucid host (but I didn't specify a -vga option)
[15:07] <hallyn> tgardner: it only happens from a livecd (once it's installed it's fine), and only with -vga cirrus.  and i guess it may just be a memory thing, bc with 1G ram tossed at the VM, it's still going after awhile
[15:08] <tgardner> hallyn, the default is 386MB right?
[15:08] <hallyn> but really, 356M should be enough !
[15:08] <tgardner> 384*
[15:08] <hallyn> tgardner: yeah
[15:09] <hallyn> tgardner: at least, in testdrive, which is how i ran into it again
[15:09] <tgardner> hallyn, how are you passing the -vga option? Lucid testdrive doesn't like it as a CL option
[15:09] <hallyn> (mind you, there was an old bug about this, and I guess it fell off the radar bc i must usually not use cirrus)
[15:09] <hallyn> hm
[15:10] <hallyn> just as '-vga cirrus' at the end of the cmdline
[15:10] <hallyn> my whole cmdline:
[15:10] <hallyn> kvm -m 384 -smp 2 -cdrom /home/serge/.cache/testdrive/iso/ubuntu_maverick-desktop-i386.iso -drive file=delme.img,if=virtio,cache=writeback,index=0 -boot d -usb -usbdevice tablet -net nic,model=virtio -net user -soundhw es1370 -vga cirrus
[15:11] <tgardner> oh, you're running kvm directly.
[15:11] <tgardner> lemma see if it faults on a Lucid host
[15:13] <hallyn> tgardner: it's rough, i know, but the most reliable way to reproduce is to pull up games->solitaire and move cards aroudn really fast
[15:14] <tgardner> ah, so it actually boots up OK, but doesn't wedge until you start messing with it
[15:17] <hallyn> tgardner: right
[15:18] <tgardner> well, at least its really freaking slow with 384M
[15:18] <hallyn> becoming more and more convinced it's just a memory leak.  This time i got it to kill the window manager, then restart it but in a very messed-up state
[15:20] <tgardner> hallyn, do you have sufficient network on the guest that you can ssh in and look at slab info?
[15:23] <tgardner> hallyn, oh yeah, sudden death when just starting solitaire.
[15:24] <hallyn> tgardner: i can try that
[15:27] <hallyn> tgardner: lol, no sshd on liveiso
[15:28] <tgardner> hallyn, what a PITA
[15:28] <hallyn> yup
[15:30] <hallyn> tgardner: fwiw the bug where i first saw this was https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/595427
[15:30] <ubot2> Launchpad bug 595427 in qemu-kvm (Ubuntu) "VM locks up, vmsvga_fifo_run: Unknown command 0xffffff in SVGA command FIFO (affects: 3) (heat: 58)" [Medium,Confirmed]
[15:32] <tgardner> hallyn, so, you could go ahead and install using 1GB RAM, then reboot with 384M on the kernel command line (after installing openssh-server) in order to watch slabinfo
[15:33] <hallyn> tgardner: no, the problem is that only the liveiso does it
[15:34] <tgardner> I just saw that in the bug report
[15:34] <hallyn> now, maybe that's bc the liveiso is dd'd to ram so we really have even less ram available?
[15:34] <tgardner> thas curious
[15:34] <hallyn> yup
[15:39] <tgardner> hallyn, I'll bet that would eventually happen on an installed KVM instance. It likely just takes a lot longer because there is a swap partition.
[15:50] <hallyn> tgardner: all right, lemme test that with swapoff...  i won't have results until after lunch break though
[15:50] <hallyn> tgardner: but that would be intresting.  hadn't thought of that
[15:53] <tgardner> hallyn, ack
[16:23] <ogasawara> JFo: just wanted to do a quick check for open maverick beta work items...
[16:23] <JFo> k
[16:23] <ogasawara> JFo: kernel-maverick-bug-handling - "Kernel Triage Summit: set schedule and communicate to all involved" ... I assume an announcement will go out relatively soon?
[16:24] <JFo> hmmm, should have already, but I think that was during the time I was having issues sending mail from my old laptop
[16:24] <JFo> will send again today
[16:24] <JFo> sorry about that :-/
[16:24] <ogasawara> JFo: cool, no worries.  mark er DONE after you send.
[16:25] <ogasawara> JFo: also, kernel-maverick-tracing-support - "Arsenal scripts for common ftrace uses" ... should I postpone that one or will you have time to get to it this cycle?
[16:26] <JFo> will do
[16:26] <JFo> not sure about the ftrace stuff
[16:26] <JFo> I have what I need 
[16:26] <JFo> but I am not sure I'll get it done this cycle
[16:26] <JFo> that will probably be best set to postponed
[16:27] <JFo> I'll mark it such
[16:27] <ogasawara> JFo: k sounds good as it seems you have a pretty full plate looking at your remaining work items.
[16:27] <JFo> yeah, tons of stuff in the wings
[16:33] <ogasawara> jjohansen: I'm going to remove the kernel-maverick-apparmor blueprint from the weekly IRC meeting agenda, as you've finished all the work items.
[16:34] <ogasawara> jjohansen: same for the kernel-maverick-pv-ops-ec2-kernel blueprint.
[16:57] <jjohansen> ogasawara: thanks
[17:00] <smb> JFo, bug call?
[17:00] <JFo> indeed
[17:00] <JFo> 1 moment
[17:10] <ogra> argh ...
[17:10] <ogra> tgardner, please make sure nobody accepts the omap4 kernel ... we dont have any bootloader support for ES2.0 hardware at all, it needs to wait until after beta
[17:11] <tgardner> ogra, well, its still pending awaiting archive love. how do I make sure its not accepted?
[17:12] <ogra> just dont say yes if any release manager asks you about it .... :)
[17:21] <tgardner> ogra, it generally just happens without any interaction from me
[17:22] <ogra> hmm
[17:26] <ogra> i wonder if its safet to reject the upload then and keep away from it until after beta ...
[17:26] <ogra> if the new binary ends up in the images we're screwed
[17:26] <ogra> *safer
[17:26] <tgardner> ogra, maybe slangasek will help you.
[17:37] <ogra> tgardner, would you be very unhappy if you had to upload it again after beta ? 
[17:38] <tgardner> ogra, no problem. it only takes a few minutes.
[17:38] <ogra> seems there is no way to tag a package for all release managers to not accept it, the safest is to reject the package, but that requires a new upload
[17:38] <ogra> ok
[19:12]  * tgardner lunches
[19:45] <hallyn> tgardner: installing, running with -m 384, doing swapoff, I'm not reproducing the hang
[19:46] <tgardner> hallyn, dang
[19:47] <hallyn> if i move a card really fast it'll hang for a half second, but that's it.  I suppose I can just keep cranking down the ram, but...
[19:48] <JFo> <-lunch finally...
[20:25] <sconklin> JFo: five boxes of hardware on the way to you
[20:25] <JFo> yep, I got the tracking numbers earlier :-)
[20:26] <sconklin> I just dropped them off
[20:26] <JFo> cool
[20:26] <JFo> what all is there?
[20:27] <sconklin> For some reason, the fedex account would only let me schedule a pickup in London, and that wasn't going to work for me :)
[20:27] <JFo> heh
[20:31]  * jjohansen -> lunch
[21:08] <jcrigby> tgardner, who can I beg to approve the linux-linaro kernel that you uploaded this morning?
[21:09] <jcrigby> tgardner, we would like to build a beta rc tomorrow
[21:09] <tgardner> jcrigby, hang on, I'm looking for the archive admin schedule
[21:09] <jcrigby> tgardner, thx
[21:10] <tgardner> https://wiki.ubuntu.com/ArchiveAdministration#Archive days
[21:10] <tgardner> jcrigby, so, being Monday, I'd say slangasek could help out
[21:10] <jcrigby> doh!
[21:11] <tgardner> assuming that schedule is still accurate
[21:20] <slangasek> tgardner: unapproved queue is the responsibility of the release team, not the archive team; but conveniently it's cold outside today so I'm wearing both hats
[21:21] <tgardner> slangasek, hmm, that is a fine distinction that is utterly lost on this poor kernel developer
[22:30] <sconklin> does anyone know which package supplies the git_lib python module? It's imported in one of Stefan's scripts and I can't find it
[22:31] <tgardner> no clues here
[22:41] <jjohansen> sconklin: python-git I think
[22:41] <sconklin> jjohansen: I installed that but no go.
[22:42] <sconklin> it's ok, it;s time to stop for the day anyway and I'll ask Stefan tomorrow. - thanks!
[22:42] <jjohansen> hrmmm, -enoclue
[23:09] <jcrigby> tgardner, if we wanted to produce multiple linux-linaro source packages so we could get parallel builds.  Would I have separate git trees that are identical except for flavour or would you want some script that tweeked the source and ran debuild -S n times?