[01:08] <infinity> kees: Or just apt-get install gcc-multilib.
[01:08] <infinity> kees: Which sets up the symlinks to make it all work for -m32
[13:35] <elfy> apw: currently I am at https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1371651/comments/58
[13:36] <apw> elfy, ok then this is something new, as the segv was the clear trigger for the problem i fixed
[13:36] <elfy> ok
[13:38] <apw> can you file a new bug against, erm lightdm to start with and let us get the bits for your issue together
[13:38] <elfy> apw was just going to ask that :)
[13:39] <elfy> apw: do you want me to do the bug before I've started lightdm ?
[13:41] <apw> elfy, sounds best yes
[13:43] <apw> elfy, also when there what does "cat /proc/fb" say
[13:44] <elfy> once booted or before?
[13:44] <apw> either i think
[13:45] <elfy> ok - well once lightdm starts 0 VESA VGA
[13:45] <elfy> I'll check the other in a minute
[13:48] <elfy> apw: bug 1375805
[13:52] <apw> elfy, ok can you grab a dmesg from the machine before lightdm starts onto the bug as well
[13:52] <elfy> do my best 
[13:55] <apw> jodh, is there a way to say "status all" to get all jobs ?
[13:55] <elfy> apw: done
[13:56] <apw> elfy, and an "initctl list"
[13:57] <elfy> yep - anything else while I'm there? 
[13:57] <apw> elfy, not sure, /me is flying blind currently
[13:57] <elfy> heh
[13:58] <apw> elfy, i wonder if this reproduces with --verbose on the end of the kernel command line
[14:00] <elfy> apw: initctl added - I'll try with --verbose
[14:02] <elfy> apw: just goes straight to tty1 without even trying tty7
[14:04] <apw> elfy, i hate debugging upstart interactions
[14:04] <elfy> :)
[14:06] <elfy> apw: ok - so now when I start lightdm (with --verbose and it not even trying tty7) it starts into a sensible sized vbox instance instead of 64x480 
[14:06] <apw> elfy, erm
[14:06] <elfy> probably no help - but I'm trying to just give you what I see here
[14:13] <apw> elfy, ok so i guess i need the syslog bits for init: at least from the --verbose boot you did, so i can compare them to mine; which obviously works
[14:13] <elfy> so verbose and do a new syslog? 
[14:16] <apw> yeah the --verbose bits get dumped into syslog, well they did on mine
[14:17] <elfy> apw: added
[14:17] <apw> elfy, what video options did you select for this VM btw ?
[14:18] <elfy> I don't tend to fiddle much - 3d enabled and 128Mb
[14:19] <apw> ok so you are different to me, i'll try those
[14:19] <elfy> apw: ok - what do you have - I can try with yours
[14:20] <apw> whatever the defaults are, something like 12M and none of the tickies on
[14:20] <elfy> ok
[14:20] <apw> yeah 12m
[14:21] <apw> nope that works for me as well (128m and 3d(
[14:21] <apw> elfy, what release is your host
[14:22] <elfy> utopic
[14:22] <apw> this is a trusty host
[14:22] <elfy> ok - I'll reboot into trusty and see what occurs there - biab
[14:23] <elfy> give me a while to install the vm - biab
[14:23] <elfy> and whatever updates I've got pending - don't boot it often :)
[14:51] <jsalisbury> **
[14:51] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[14:51] <jsalisbury> **
[14:53] <elfy> apw: ok - so in trusty with vbox v 4.3.16-95972 I get exactly the same fail
[14:53] <apw> elfy, ack thanks for testing that, i am sure it was a pita
[14:53] <elfy> fairly :)
[14:54] <elfy> not sure it puts us anywhere further forward though 
[15:17] <apw> elfy, ok i think i know approximatly what is happening; you are not getting a graphics card notification
[15:17] <apw> elfy, which for the moment i am going to put down to a race
[15:17] <apw> elfy, which means you should hit the fallback, and it seems that that is busted in utopic
[15:17] <apw> elfy, someone has tried to fix it, and failed badly
[15:18]  * apw will poke it and get back to you
[15:19] <apw> elfy, actually could you take the contents of http://paste.ubuntu.com/8466613/ as /etc/init/udev-fallback-graphics.conf
[15:19] <apw> elfy, and let me know if that at least gets you lightdm
[15:32] <backjlack> Hello!
[15:32] <backjlack> I'm seeing a major problem on Ubuntu 12.04 with trusty-lts: https://i.imgur.com/EXQm49N.png
[15:33] <backjlack> 1 GB of RAM is used by upstart-udev-bridge and 240 MB of RAM is used by "init"
[15:33] <backjlack> I was able to run into this problem by running ~200,000 Docker containers.
[15:38] <apw> jodh, ^^ that sounds like a memory lieak in upstart-udev-bridge or something
[15:39] <elfy> apw: I succeeded in killing the existing vm - reinstalling it now - will do that ^^ asap
[15:39] <apw> backjlack, is that in one instance of upstart-udev-bridge ?
[15:39] <backjlack> apw: yes
[15:40] <backjlack> apw: headless ubuntu server with trusty lts kernel, fully updated
[15:41] <apw> backjlack, ok that does sound like a memory leak or similar in upstart-udev-bridge ... could you file a bug on that
[15:41] <backjlack> apw: Ok, what should I file the bug against?
[15:42] <apw> backjlack, ubuntu-bug upstart
[15:43] <jodh> backjlack: as apw says, please raise a bug so we can investigate.
[15:43] <hallyn> "skipabi=tue"  well that ain't gonna fly
[15:44] <apw> hallyn, :)
[15:48] <elfy> apw: posted confirmation to bug - that .conf works here
[15:49] <rtg> hallyn, try skipabi=weds
[15:49] <apw> elfy, thanks ... thats at least an easy fix
[15:49] <apw> rtg, :)
[15:49] <elfy> :)
[15:51] <apw> elfy, now to go and beat on the person who removed it :)
[15:51] <elfy> heh
[15:52] <elfy> I shall toddle of into other less uncharted channels for me now - I'm about if needed :)
[15:52] <elfy> apw: thanks for your help 
[15:52] <apw> elfy, heh yeah thanks to you for your quick testing, that got us there
[15:52] <elfy> welcome as always 
[15:52] <elfy> cheers :)
[15:54] <hallyn> rtg: why not just shoot for the moon, fri no doubt will have the happiest results.  unless we're in one of those countries where kids get a hlaf day every wed
[15:57] <backjlack> apw: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1375874
[15:57] <backjlack> apw: You also had https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1198180, but that was ignored.
[15:57] <apw> jodh, ^
[15:59] <backjlack> Should I also investigate 14.04 to make sure it doesn't have the exact same problem?
[16:00] <apw> backjlack, that owuld be interesting to know for sure
[16:04] <backjlack> Ok, that should take only a few minutes to confirm.
[16:23] <apw> smb, shortly there should be new udev binaries for this fallback thing in https://launchpad.net/~apw/+archive/ubuntu/lp1375805 ... i'll be interested to know if they fix your binary-drivers not giving you lightdm issue too
[16:23] <smb> apw, okidok
[16:36] <apw> smb, of cour the build estimates are just static in time
[16:37] <smb> It will be build by 6pm (though we do not say which day)?
[16:38] <rtg> apw, can you comment on this ? (should be simple) https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1121699/comments/9
[16:40] <apw> rtg, ack, and i still have that perl thing to look at now i have "fixed" this vbox "kernel" issue
[16:41] <rtg> apw, the hyper-v dudes are complaining about crash dump still, but it appears to be a matter of a larger reservation.
[16:42] <apw> smb, ^ didn't we talk about using a smaller initrd for those? ==neeed or something ?
[16:42] <apw> smb, as i suspect we are holding like half the ram in these instances
[16:42] <smb> apw, Though the size was also just made bigger...
[16:43] <apw> smb, "just" == ?
[16:44] <smb> apw, would have to install it again.... though maybe arges remembers it from his head (having to use it)
[16:44] <apw> smb, ok trying to work out if the hyper-v folk tested before or after "just"
[16:45] <smb> apw, iirc it would be = something (something maybe 256M
[16:45] <apw> yeah i assumed they changed it from 128 to 256 or somethign
[16:45] <apw> but more it is the when of it ...
[16:45] <apw> though how big is am m1.small, that isn't going to leave anything for the actual instance :)
[16:46] <smb> Somehwen between P and T but I know that is vaque
[16:46] <jsalisbury> ##
[16:46] <jsalisbury> ## Ubuntu Kernel Team Meeting - in 15 minutes - #ubuntu-meeting
[16:46] <jsalisbury> ##
[16:46] <smb> smalles you get would be micros (~ 600M). I think m1.small is 3.5G already
[16:47] <smb> apw, Hrm... and m1 seems to be "old fashion" anyway http://aws.amazon.com/de/ec2/instance-types/
[16:48] <smb> ok... m1.small down there , so 1.7 G
[16:50] <apw> smb, that feels like they have gotten a whole heap bigger than i remember
[16:51] <smb> apw, Yeah. m1.small is now considered something similar than micro... at least one could think that
[16:51] <backjlack> Is there any way at all to get a libc with dbgsym?
[16:55] <arges> smb: what happened?
[16:56] <smb> arges, Nothing immediate. Just apw was asking about what mem size we nowadays use for kcrash
[16:57] <arges> smb: i think i had a bug to bump it
[16:57] <arges> it would be nice if we made it have an auto parameter
[16:58] <smb> Yeah, at least for the small ram size it would not work in the past. So I think we just went to something for all... just cannot remember what value
[16:58] <arges> 384M
[16:59] <smb> oh ok. quite a bit for small systems but we probably not expect those being around that much
[16:59] <arges> smb: we can specify ranges too
[17:00] <smb> Yeah, I know. Problem was the initrd by default being too big
[17:01] <jsalisbury> ##
[17:01] <jsalisbury> ## Meeting starting now
[17:01] <jsalisbury> ##
[17:21] <jdesfossez> Hi, I'm trying to detect if a target kernel is a ubuntu kernel
[17:21] <jdesfossez> I noticed the new UTS_UBUNTU_RELEASE_ABI symbol which is great
[17:22] <jdesfossez> but I need to include generated/utsrelease.h to have it
[17:22] <jdesfossez> which might not exist
[17:22] <apw> why might it not exist
[17:22] <jdesfossez> I don't see it on a vanilla kernel
[17:25] <jdesfossez> hum actually I see it, but I'm wondering if this file always exists
[17:31] <apw> i believe that is a purfectly standard header indeed, i am not sure you need to nclude generated though
[17:31] <apw> isn't there a real wrapper for that ?
[17:35] <smb> include/linux/vermagic.h:#include <generated/utsrelease.h>
[17:35] <jdesfossez> ah great
[18:03] <backjlack> Is there anything I should do for https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1375874 ?
[20:24] <backjlack> The ddebs repo is the slowest thing I've ever seen.
[20:25] <backjlack> good luck debugging the Ubuntu kernel to whomever is stupid/brave (choose the one you like most) enough to try.