=== infinity_ is now known as infinity === gerald is now known as Guest85863 [07:18] yo [08:34] yo [08:44] RAOF, You still around? Who would be the guy caring about llvm-pipe/xserver-modeset these days? === anubhav_ is now known as anubhav [09:33] smb: You're probably after mlankhorst, mostly. [09:34] RAOF, Ah, ok. Thanks. I am always unsure there... [09:36] Also tjaalton and Sarvatt can still be of assistance, probably :) [09:37] Well, and me, depending on the question :) [09:37] RAOF, I put it out on #ubuntu-desktop [09:38] RAOF, Basically gnome term in virtual machines is not a happy bunny [09:39] I'll check out what it looks like here.. [09:40] oops, need to migrate the images somewhere other than btrfs.. [09:43] 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] the default is wrong imo [09:44] iirc [09:45] tjaalton, It is the historical default and its that (or potentially svga) that you get with xen [09:48] 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] 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] tjaalton, Yeah, which is a failure from my point of view ;) [09:54] i'm using qxl it seems [09:57] 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] And the boot issues should be solved too [11:07] Hi [11:07] I've opened this bug report much time ago: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972604 [11:07] 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] I've to open an upstream bug report. There is this wiki page: https://wiki.ubuntu.com/Bugs/Upstream/kernel [11:08] 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] what information from /proc can I add to the upstream bug report? [11:08] and then: [X.] Other notes, patches, fixes, workarounds: Please provide a link to your Launchpad bug report [11:09] What exactly can I do about this specific point? Any ideas? [13:00] 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] Launchpad bug 1270248 in logrotate (Ubuntu) "/var/log fills up disk space on phone" [High,Confirmed] https://launchpad.net/bugs/1270248 === gerald is now known as Guest89730 [14:08] ogra_, ack [14:17] apw, thx [14:47] ogra_: I still think we should fix this differently somehow [14:47] ogra_: otherwise we'd need to patch every kernel [14:47] from every vendor [14:47] we need a way for the log to have a limit in size, and drop the rest that overflows it [14:48] like a ring-buffer but for whatever we store in syslog [14:48] rsalveti, you still dont want a notice message every 20sec [14:48] ogra_: that's fine [14:48] as long it doesn't cost you anything [14:48] it eats the log [14:48] right, but we shouldn't care about that, as long we limit the log [14:48] this is not a desktop, it's a phone [14:50] android is ridiculously verbose, but it's not storing anything in the disk [14:50] rsalveti, only the chargers are [14:50] the rest is normal [14:50] right, but do we really want to keep those logs around? [14:51] and still, it's specific to a device [14:51] which annoys me as we need to start preparing a similar change for every build we have (and will have) [14:51] 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] sure, I believe it'd be good to have some sort of uds session (but out of uds) :-) [14:58] done [14:58] 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] ogra_: but that is fine [14:59] and expected [14:59] i agree we need to limit logging more as well, but we also need to get rid of tehse spammers, [14:59] no [14:59] we don't need to care, really [14:59] and we shouldn't care [14:59] as that's specific to the kernel we have [14:59] thats not expected by me ... if i want to see kernel messages i dont want to see 2000 the same battery message [15:00] it is *only* one place in the klernel that spams [15:00] well, then just run dmesg right after boot [15:00] then iu can use /var/log/dmesg, that gets copied on boot [15:00] you shouldn't be able to get a useful dmesg output (since boot) after you used the phone for a while anyway [15:00] but i want to be able to read normal kernel messages too [15:00] right, but you're expecting too much [15:00] and writing rubbish to all logs every 20sec is not acceptable [15:00] as I said, this is specific to vendor/device/kernel [15:00] no [15:01] and I want us to have a solution that is common for whatever kernel we use [15:01] this is specific to only power mgmt drivers [15:01] look at the patches [15:01] right, a kernel tree [15:01] we don't even know if the vendor will be using the same drivers [15:01] its as quiet as my desktop with these added [15:01] i'm willing to maintain patches for this [15:01] i'm not willing to lose my logs to spam for that [15:02] esüpecially if we restrict them in size and you lose them way earlier [15:03] ogra_, i have kernels ready to upload, are we a go, or not go [15:03] rsalveti, ^ [15:03] apw, please upload to the PPA, i want to test on the weekend [15:04] (we can still wipe them, right ?) [15:04] ogra_: I got a pending flo kernel in there that I want to upload today still [15:04] but I believe it's fine to upload this anyway [15:04] apw, can you hold back until that landed ? [15:04] until we work on a better solution [15:04] ogra_: I'm fine to land this today [15:04] good [15:05] all I'm saying is that I want us to work on a more generic solution as well [15:05] apw: so please, push them to the ppa :-) [15:09] rsalveti, ack [16:41] rsalveti, ok both are built and published in the ppa [16:41] apw: great, thanks for the heads up === hatch__ is now known as hatch [17:36] 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] does anyone have a hint how to get this one "Realtek Semiconductor Co., Ltd. Device 5249 " up and running? === [BNC]alphacrypt is now known as alphacrypt === hatch__ is now known as hatch [23:19] hello, i build my own kernel package, and i have problem with brx2 (broadcom ethernet NIC) [23:19] i dont know why this NIC dont work on my kernel, i have check options for this NIC, but dont work [23:21] aughhhh... it isn't problem with NIC but with nat... === FreezingAlt is now known as FreezingCold