[07:18] <ppisati> yo
[08:34] <smb> yo
[08:44] <smb> RAOF, You still around? Who would be the guy caring about llvm-pipe/xserver-modeset these days? 
[09:33] <RAOF> smb: You're probably after mlankhorst, mostly.
[09:34] <smb> RAOF, Ah, ok. Thanks. I am always unsure there...
[09:36] <RAOF> Also tjaalton and Sarvatt can still be of assistance, probably :)
[09:37] <RAOF> Well, and me, depending on the question :)
[09:37] <smb> RAOF, I put it out on #ubuntu-desktop
[09:38] <smb> RAOF, Basically gnome term in virtual machines is not a happy bunny
[09:39] <tjaalton> I'll check out what it looks like here..
[09:40] <tjaalton> oops, need to migrate the images somewhere other than btrfs..
[09:43] <smb> tjaalton, The key piece (if you where responding to my question kinda) is to have a kvm or xen guest using the default cirrus graphics
[09:44] <tjaalton> the default is wrong imo
[09:44] <tjaalton> iirc
[09:45] <smb> tjaalton, It is the historical default and its that (or potentially svga) that you get with xen
[09:48] <smb> tjaalton, I know some people like to push for vmvga but that is only available for kvm. And it is usually not working in different ways. Last time I looked it always went for an insanely big screen and crashed when trying to change that.
[09:49] <tjaalton> I need to make some room on my ssd first to check the situation, but iirc I switched off from cirrus immediately after the install
[09:50] <smb> tjaalton, Yeah, which is a failure from my point of view ;)
[09:54] <tjaalton> i'm using qxl it seems
[09:57] <smb> One does not have that luxury with Xen. I mean we should be better with cirrus now as both KVM and Xen can use the kernel-mod driver
[09:57] <smb> And the boot issues should be solved too
[11:07] <cristian_c> Hi
[11:07] <cristian_c> I've opened this bug report much time ago: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972604
[11:07] <ubot2> Launchpad bug 972604 in linux (Ubuntu) "168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Triaged]
[11:08] <cristian_c> I've to open an upstream bug report. There is this wiki page: https://wiki.ubuntu.com/Bugs/Upstream/kernel
[11:08] <cristian_c> I've read it, but I've got some doubts yet. for example: [7.7.] Other information that might be relevant to the problem (please look in /proc and include all information that you think to be relevant):  While booted into the newest upstream mainline kernel only, execute the following via a terminal, and paste the results
[11:08] <cristian_c> what information from /proc can I add to the upstream bug report?
[11:08] <cristian_c> and then: [X.] Other notes, patches, fixes, workarounds:  Please provide a link to your Launchpad bug report
[11:09] <cristian_c> What exactly can I do about this specific point? Any ideas?
[13:00] <ogra_> apw, there are two (untested) patches for flo and mako on bug 1270248, could i get a PPA build with them to test ?
[13:01] <ubot2> Launchpad bug 1270248 in logrotate (Ubuntu) "/var/log fills up disk space on phone" [High,Confirmed] https://launchpad.net/bugs/1270248
[14:08] <apw> ogra_, ack
[14:17] <ogra_> apw, thx
[14:47] <rsalveti> ogra_: I still think we should fix this differently somehow
[14:47] <rsalveti> ogra_: otherwise we'd need to patch every kernel
[14:47] <rsalveti> from every vendor
[14:47] <rsalveti> we need a way for the log to have a limit in size, and drop the rest that overflows it
[14:48] <rsalveti> like a ring-buffer but for whatever we store in syslog
[14:48] <ogra_> rsalveti, you still dont want a notice message every 20sec
[14:48] <rsalveti> ogra_: that's fine
[14:48] <rsalveti> as long it doesn't cost you anything
[14:48] <ogra_> it eats the log
[14:48] <rsalveti> right, but we shouldn't care about that, as long we limit the log
[14:48] <rsalveti> this is not a desktop, it's a phone
[14:50] <rsalveti> android is ridiculously verbose, but it's not storing anything in the disk
[14:50] <ogra_> rsalveti, only the chargers are 
[14:50] <ogra_> the rest is normal
[14:50] <rsalveti> right, but do we really want to keep those logs around?
[14:51] <rsalveti> and still, it's specific to a device
[14:51] <rsalveti> which annoys me as we need to start preparing a similar change for every build we have (and will have)
[14:51] <ogra_> can we discuss this at or after the meeting 
[14:52]  * ogra_ tries to get something in his stomack atm ... had no chance to eat today yet
[14:52] <rsalveti> sure, I believe it'd be good to have some sort of uds session (but out of uds) :-)
[14:58] <ogra_> done
[14:58] <ogra_> rsalveti, so the issue is that the kernel logs to a ringbuffer ... dmesg will be completely spammed away with batteray messages after 2min
[14:59] <rsalveti> ogra_: but that is fine
[14:59] <rsalveti> and expected
[14:59] <ogra_> i agree we need to limit logging more as well, but we also need to get rid of tehse spammers, 
[14:59] <ogra_> no
[14:59] <rsalveti> we don't need to care, really
[14:59] <rsalveti> and we shouldn't care
[14:59] <rsalveti> as that's specific to the kernel we have
[14:59] <ogra_> thats not expected by me ... if i want to see kernel messages i dont want to see 2000 the same battery message 
[15:00] <ogra_> it is *only* one place in the klernel that spams 
[15:00] <rsalveti> well, then just run dmesg right after boot
[15:00] <ogra_> then iu can use /var/log/dmesg, that gets copied on boot 
[15:00] <rsalveti> you shouldn't be able to get a useful dmesg output (since boot) after you used the phone for a while anyway
[15:00] <ogra_> but i want to be able to read normal kernel messages too 
[15:00] <rsalveti> right, but you're expecting too much
[15:00] <ogra_> and writing rubbish to all logs every 20sec is not acceptable
[15:00] <rsalveti> as I said, this is specific to vendor/device/kernel
[15:00] <ogra_> no
[15:01] <rsalveti> and I want us to have a solution that is common for whatever kernel we use
[15:01] <ogra_> this is specific to only power mgmt drivers
[15:01] <ogra_> look at the patches
[15:01] <rsalveti> right, a kernel tree
[15:01] <rsalveti> we don't even know if the vendor will be using the same drivers
[15:01] <ogra_> its as quiet as my desktop with these added
[15:01] <ogra_> i'm willing to maintain patches for this 
[15:01] <ogra_> i'm not willing to lose my logs to spam for that 
[15:02] <ogra_> esüpecially if we restrict them in size and you lose them way earlier
[15:03] <apw> ogra_, i have kernels ready to upload, are we a go, or not go
[15:03] <apw> rsalveti, ^
[15:03] <ogra_> apw, please upload to the PPA, i want to test on the weekend
[15:04] <ogra_> (we can still wipe them, right ?)
[15:04] <rsalveti> ogra_: I got a pending flo kernel in there that I want to upload today still
[15:04] <rsalveti> but I believe it's fine to upload this anyway
[15:04] <ogra_> apw, can you hold back until that landed ? 
[15:04] <rsalveti> until we work on a better solution
[15:04] <rsalveti> ogra_: I'm fine to land this today
[15:04] <ogra_> good
[15:05] <rsalveti> all I'm saying is that I want us to work on a more generic solution as well
[15:05] <rsalveti> apw: so please, push them to the ppa :-)
[15:09] <apw> rsalveti, ack
[16:41] <apw> rsalveti, ok both are built and published in the ppa
[16:41] <rsalveti> apw: great, thanks for the heads up
[17:36] <ogra_> apw, oh, and since i had pinged you about that, i worked around the bootchart CPU issue i had by simply forcing all cores online during boot, but i could imagine the server team will want bootcharts for their arm devices too and will run into something similar, so the CPU logic in bootchart probably deserves some attention
[20:33] <bladibla> does anyone have a hint how to get this one "Realtek Semiconductor Co., Ltd. Device 5249 " up and running?
[23:19] <wmp> hello, i build my own kernel package, and i have problem with brx2 (broadcom ethernet NIC)
[23:19] <wmp> i dont know why this NIC dont work on my kernel, i have check options for this NIC, but dont work
[23:21] <wmp> aughhhh... it isn't problem with NIC but with nat...