[06:43] <ppisati> moin
[06:59] <smb> morning
[07:20]  * ppisati goes for the big monday upgrade...
[07:20] <ppisati> 218 pkgs, cross your limbs
[07:25] <smb> what could possibly go wr#!§$
[07:25] <ppisati> ok, i lied
[07:25] <ppisati> i did a dist-upgrade
[07:26] <ppisati> and it's now removing all the unity-scope*
[07:26] <ppisati> besides, i never used them so...
[07:26] <ppisati> :)
[07:26] <smb> we don't need them :)
[07:28] <smb> ppisati, Only got 152 to upgrade and none to remove. Must already have them removed and I did not miss them. :-P
[07:29] <ppisati> you lucky :)
[07:29]  * ppisati -> reboot
[07:31] <ppisati> sees to work
[07:31] <ppisati> seems
[07:31] <smb> Keyboard is flakey
[07:31] <smb> :)
[07:31] <ppisati> :)
[07:31] <ppisati> no, that's me :)
[07:32] <smb> infinity, Could you please press the accept button for Xen 4.2.2 in Raring?
[07:33] <smb> ppisati, We cannot be faulty. It must be the computer. ;)
[07:33]  * ppisati should try to ditch pidgin and go back to... $whatever we ship
[07:39] <apw> ppisati, for me my at-tab and dash invokations now take 20-40s to occur
[07:39] <apw> morning all
[07:39] <apw> alt-tab
[07:39] <ppisati> uhm no, alt-tab is still fast
[07:39] <ppisati> andi admit i never use the dash
[07:40] <smb> apw, morning. always or only first
[07:40] <apw> oh i never use dash _intentionally_ but when i do now it freezes my desktop for 30s
[07:40] <apw> oh every time, always
[07:40] <ppisati> nope
[07:40] <smb> Hm, ok. I only see a very long time the first time I bring it up
[07:40] <ppisati> still fast
[07:40] <ppisati> even the dash
[07:41] <apw> smb, i am very glad i did not upgrade my desktop to daily-quality
[07:41] <smb> apw, Yeah, me too.
[07:41] <apw> my main non-fixed workhorse agent57 is now in the scrap pile thanks to it
[07:42] <apw> i am pretty sure it is not kernel because that machine is one of the very boxes i test kernels on before upload
[07:42] <ppisati> "haswell i5 + ati gpu" box is ok
[07:42] <smb> awesome
[07:42] <RAOF> apw: Hm, sounds like the intel regression in mesa that I thought was fixed, then fixed again, and then fixed another time?
[07:42] <apw> and my typing useage style makes this bug immediatly obvious
[07:42] <apw> RAOF, need some of your bees back ?
[07:42] <apw> RAOF, how could i confirm ... this is a baby (read old) atom
[07:42] <RAOF> apw: Nah, that'd bee a tjaalton problem now :)
[07:43] <apw> heh :)
[07:43] <RAOF> Oh, you're trying to use a 915?
[07:43] <apw> heh
[07:43] <RAOF> :)
[07:44] <apw> RAOF, so it cannot be ubiquitus can it, i think my other i915 is ok, i think
[07:44] <RAOF> ??? :(
[07:44] <smb> apw, So maximegalon seems to come up with latest updates and that is a similarly old atom and i915
[07:44] <apw> i am upgrading another aom to the same level to see if it is affected too
[07:45]  * apw parays this is not one of those "it could never have worked" bugs, the ones which only exhibit for me
[07:45] <apw> also ... i have "blacker" cursors today, is that normal
[07:45] <smb> apw, mine is Intel Corporation Mobile 945GSE Express Integrated Graphics Controller (rev 03)
[07:45] <RAOF> apw: Not normal, but you're not alone.
[07:46] <apw> mine is a D4xx/D5xx/N4xx/N5xx integrated ..
[07:46] <apw> RAOF, yeah i have inverted cursors
[07:47] <smb> apw, Hm... mine is not blinking and solid right now but seems bright enough
[07:47] <tjaalton> apw: huh, so dash is slow for you?
[07:48] <smb> apw, tjaalton Oh great, mine is not slow ... it does not appear at all
[07:48] <smb> now the whole dash turned grey
[07:49] <smb> apw, Something likely unrelated but maybe we should have a look: "perf samples too long (5012 > 5000), lowering kernel.perf_event_max_sample_rate to 25000"
[07:51] <smb> Those I think I remember appearing more often recently
[07:52] <apw> smb, yeah the slower machines seem to say things about that, i assume it is benigh
[07:52] <apw> but knowing would be good
[07:52] <apw> tjaalton, on that machine, yeah like hit alt, have nothing moving or changing but the cursor for like 40s
[07:52] <apw> then it appears half filled, then wait a bit more
[07:53] <tjaalton> nice
[07:53] <apw> 35d by naieve counting == seconds
[07:53] <smb> apw, Ok, yeah, seems I have exactly the same
[07:54] <apw> the launcher scrolls on just fine if i use meta+N to get to windows
[07:54] <apw> smb, how is alt-tab
[07:54] <smb> There is now a shadow dash
[07:54] <smb> Have not tried yet as it was so slow to even get the first thing up
[07:54] <apw> yeah it is half there i think, like that is the start of it fading in
[07:54] <tjaalton> looks like it's filed as #1222602 
[07:54] <apw> bug #1222602
[07:54] <ubot2`> Launchpad bug 1222602 in mesa (Ubuntu) "Bad performance on GMA950" [Undecided,New] https://launchpad.net/bugs/1222602
[07:56] <apw> tjaalton, to downgrade mesa, do you have a list of packages i would need to actually downgrade
[07:56] <apw> (so i can confirm this)
[07:57] <tjaalton> libgl1-mesa-dri -glx
[07:57] <apw> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1222351
[07:57] <ubot2`> Launchpad bug 1222351 in unity (Ubuntu) "alt-tab and alt tap hang unity for 20s or so before operating" [High,Triaged]
[07:57] <apw> was the bug i filed, which if this reproduces i will reassign and dup appropraitly
[07:57] <apw> tjaalton, thanks will test noe
[07:57] <tjaalton> yeah 9.1.x was confirmed on the other bug to be fine
[08:01] <apw> ok about to test will let you know
[08:07] <apw> tjaalton, ok ... confirmed, mesa downgrade fixes behaviour
[08:07] <apw> will update the bugs
[08:07] <tjaalton> thx
[08:09] <apw> if there is anything one can do to help find this ... let us know, it sounds like you have two testers here
[08:09] <tjaalton> i'm looking at upstream changes since 9.1
[08:10]  * apw bets they are untested on atom :)  till now
[08:10] <tjaalton> well, gen3 isn't that uncommon
[08:11] <tjaalton> "i915: Remove all the HiZ code from i915"
[08:11] <tjaalton> perhaps
[08:11] <smb> We probably have two different i915 generations as well
[08:13] <tjaalton> i915..i945 is gen3
[08:14] <tjaalton> http://en.wikipedia.org/wiki/Intel_Extreme_Graphics#Third_generation
[08:14] <tjaalton> throw in these atoms too
[08:14] <smb> tjaalton, Ah ok, I just thought apw's netbook had something slightly newer than mine
[08:14] <apw> tjaalton, they are on gen7 inhouse i would think
[08:14] <apw> so that is 4+ versions older, "what are they"
[08:14] <tjaalton> apw: probably so
[08:18] <apw> tjaalton, i am feeling retarded how do i find the exact GMA I have
[08:18] <tjaalton> apw: lspci probably
[08:18] <smb> apw, check for the pci id
[08:18] <apw> 00:02.0 VGA compatible controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller
[08:18] <smb> apw, I would assume something along gma 3150
[08:18] <apw> that seems rather wishy washy
[08:18] <smb> apw, -vvvnn
[08:19] <tjaalton> aka gma3150
[08:19] <apw> 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller [8086:a011] (prog-if 00 [VGA controller])
[08:19] <smb> apw, mine is a 0x27ae, so gma950
[08:19] <tjaalton> pineview
[08:19] <smb> apw, a011 is 3150
[08:20] <apw> cool, ok so smb is the same as the OR and i have added my chipset to the title
[08:20] <apw> smb, could you 'affects me' on it
[08:20] <smb> apw, Hm, newer but looks like slower, less pipelines...
[08:21] <smb> apw, think I have
[08:21] <apw> ok good
[08:22] <apw> smb, title says 'me and one other' which would be the OR
[08:22] <smb> apw, mine says me and two other 
[08:22] <apw> smb, i hate launchpad some days
[08:23] <smb> But as the title changed to add your gma3150 I thnk we look at the same. :)
[08:23] <apw> oh i see, when you update one you have, it +1's the number _you_ have
[08:23] <apw> not the actual number, POC
[08:24] <apw> tjaalton, i think you and i may have collided updating the title, and i may have bolloxed your update
[08:24] <smb> apw, Speaking of breakage... my FFE for Xen-4.3 in Saucy got approved over the weekend... :)
[08:24]  * apw hates LP more
[08:24]  * apw adds smb to the list
[08:25]  * smb thought he was already on it in the tops region
[08:25] <tjaalton> heh, I added [gen3] there now, it should cover it all
[08:25] <apw> great
[08:25]  * apw moves smb up the list, rapidly
[08:26] <smb> At least moving up ranks *somewhere*. Though on the "todo" list would be so much better. :-P
[08:26] <apw> smb, can you test 'resume' performance on your gen3, i am finding a good 10s of "i am on, but there is nothing to talk to password wise" before i can use that box
[08:26] <apw> *down* on that one, *down* i say
[08:27] <smb> apw, I think that moves priority of what I can test as well
[08:27] <apw> bah, tuche' m'lord
[08:28] <smb> apw, suspend/resume seems to be ok (only one attempt)
[08:28] <apw> smb, it works fine, it just seems reallly slow to let me start typing the password
[08:28] <apw> ie the backlight comes on immediatly but gnome screensaver is not talking to me for ages
[08:29] <smb> apw, Yes, but no that looks good, too
[08:29] <smb> It even comes up quickly without needing another keypress
[08:29] <apw> i guess that means there is something i can fix, perhaps something installed
[08:30] <smb> Either that or a slight difference between gma950 and 3150
[08:30] <apw> yeah
[08:30] <apw> one or t'other
[08:31] <smb> Wasn't that the machine that more often than the rest seemed to suffer from i915 problems
[08:31] <apw> yeah this machine was a bit of a lemo
[08:31] <apw> lemon
[08:32] <tjaalton> this was actually filed upstream months ago, no reply.. https://bugs.freedesktop.org/show_bug.cgi?id=64202
[08:32] <ubot2`> Freedesktop bug 64202 in Drivers/DRI/i915 "Enabling opengl 2.1 on intel gen3 breaks the Unity desktop (and possibly others)" [Normal,New]
[08:33] <tjaalton> there's a workaround too
[08:33] <Gsport> will linux ever be fixed?
[08:33] <apw> Gsport, heh
[08:35] <Gsport> intel grafics suck
[08:35]  * apw really hopes not, else there is no reason to pay me
[08:36] <apw> Gsport, heh no i think it sucks as much as any other, just cause it is developed in the clear it is more obvious
[08:36] <Gsport> i have to respect your opinion i suppose
[08:37] <Gsport> IMHO intel isnt dead it just deserves to die
[08:38] <smb> tjaalton, Ok, that environment variable override does work for me, too
[08:38] <tjaalton> good
[08:46] <apw> Gsport, i think someone who is willing to engage and share their data is to applauded, even if they are not the most powerful GPU makers
[08:47] <apw> it isn't like you have to buy their products if you don't like them, vote with your wallet
[08:54] <apw> tjaalton, ok that bug upstream implies that unity needs to adapt
[08:56] <tjaalton> could be
[08:56]  * apw wonders what the recommendation is, pin mesa back or switch the environment
[08:58]  * apw tries the env for completeness
[09:02] <ppisati> brb
[09:06] <apw> tjaalton, confirming the /etc/environment thing here as well
[09:51] <apw> ppisati, how utterly broken is calxeda
[09:51] <apw> given this is about the 40th patch we are applying for it
[10:17] <apw> tjaalton, i don't know if you saw the somewhat off topic comment in the bottom of the mesa bug, it seems the "unity puts the second screen in a place you can no longer render to it" bug is back (if they are accurate)
[10:36] <apw> henrix, i see that kees fixes for those various CVEs are starting to trickle in via the HID tree
[10:36] <apw> (and i assume you have the same searcher i do to find them :))
[10:36] <henrix> apw: yeah, i've already started updating cvetracker with those :)
[10:37] <apw> henrix, heh i noticed when i went to add them :)
[10:37] <apw> saved me the effort
[10:53] <apw> kees, hey ... it seems only half of your input cves arrived in linus' tree, are the others coming via some other route or is there some issue we should know about
[11:14] <hashken> I want to know if process virtualization is enabled in a particular kernel
[11:15] <hashken> What flags should I check for in the kernel config file?
[11:15] <apw> hashken, what sort of virtualisation?
[11:17] <hashken> I want to know if this particular kernel can support mininet - https://github.com/mininet/mininet
[11:17] <apw> hashken, do you mean lxc or something else
[11:17] <hashken> A brief description of mininet from the github page
[11:17] <hashken> Mininet creates virtual networks using process-based virtualization and network namespaces - features that are available in recent Linux kernels. In Mininet, hosts are emulated as bash processes running in a network namespace, so any code that would normally run on a Linux server (like a web server or client program) should run just fine within a Mininet "Host". The Mininet "Host" will have its own private network interface an
[11:18] <hashken> Switches in Mininet are software-based switches like Open vSwitch or the OpenFlow reference switch. Links are virtual ethernet pairs, which live in the Linux kernel and connect our emulated switches to emulated hosts (processes).
[11:18] <hashken> I am not exactly familiar with virtualization and stuff.
[11:18] <apw> so that sounds like it uses network namespaces and openvswitch, so i would expect that to work on later releases if anywhere
[11:19] <apw> as we keep pretty much up on the leading edge there for openstack and the like
[11:22] <smb> It still would not be completely clear what feature is being looked for. Openvswitch in in the kernel and relatively complete in Saucy/3.11 
[11:22] <smb> To run VMs is also supported in the kernels
[11:23] <smb> or containers
[11:23] <apw> yeah i am going on the page which that above snippet came from, which sounds like it is trying to use something lightweight to simulate many hosts, basically a cut down lxc as they are all under ones control and not malicious
[11:26] <hashken> I am actually seeing if the raspberry pi kernel can support mininet
[11:26] <hashken> So, I actually need to know the kerenl config flags that are related to virtualization
[11:26] <hashken> I have been able to find the flag fornetwrok namespaces - CONFIG_NET_NS
[11:27] <hashken> But, process virtualization is such a general concept, that I have not been able to find the relevant flags.
[11:28] <hashken> Since you guys have a much better idea about the kernel than me, I am hoping that you will able to point out the appropriate flags to make mininet work.
[11:31] <apw> hashken, well indeed, there a are a lot, i would look at the init/Kconfig which has all the namespaces which are 'generic' listed, search for NET_NS
[11:31] <smb> hashken, This sounds like you are looking for a containerization, so probably a mix of cgroup and *_NS options
[11:31] <apw> and whether openvswitch is in the version you are using, harder to say
[11:36] <smb> Hm looking at the readme and checkign with Saucy, there is a mininet package in the archive
[11:37] <smb> I would assume then this works with the stock ubuntu kernels
[11:38] <smb> https://github.com/mininet/mininet/blob/master/INSTALL
[11:38] <smb> States the only requirement would be NET_NS
[11:39] <smb> and openvswitch 
[12:07] <Kaloz> Hi. I would like to ask for the merge of two bugfixes into the generic kernel for saucy. Who should I bug about them? ;)
[12:17] <ppisati> apw: ah, i keept thinking the 'disable module check' + abi bump are enough
[12:17] <smb> Kaloz, If those fixes are upstream in Linus tree and picked up by upstream stable they will be in the Saucy kernel automatically at some point.
[12:17] <ppisati> *keep
[12:20] <smb> Kaloz, When unsure you can point out the fixes on kernel-team@lists.ubuntu.com
[12:21] <Kaloz> smb: yeah, but as one of them breaks booting, if those fixes get late, saucy won't install
[12:22] <Kaloz> smb: do I have to subscribe there or is it internal?
[12:22] <apw> ppisati, well that patch didn't disable the module check either
[12:22] <apw> or if it did it did it against the wrong abi
[12:23] <smb> Kaloz, Ok, so for that one you should file a bug (if you have not already) with ubuntu-bug linux. The list is public and you don't have to subscribe. Just takes a bit longer then as you have to get trhough moderation
[12:23] <ppisati> apw: no, it didn't
[12:23] <apw> Kaloz, so you might email the kernel-team mailing list with the patches and ask for them as well, a bug always helps focus the mind
[12:25] <Kaloz> smb: there's a bug, but it seems $randomuser can set it to "Fix released" so I'm afraid it will stay below radar or be missed in the noise
[12:25] <apw> Kaloz, if it isn't fixed change it back
[12:25] <apw> and ... what is the bug number
[12:25] <smb> Kaloz, Right, and I would write the email in addition
[12:25] <Kaloz> apw: okay, I'll wait for the second ones upstream submission and send mail to there
[12:25] <Kaloz> apw: 1197451
[12:26] <smb> bug 1197451
[12:26] <ubot2`> Launchpad bug 1197451 in linux (Ubuntu Raring) "Ubuntu fails to properly boot on Macbook Air 2013 6,1 & 6,2" [High,Triaged] https://launchpad.net/bugs/1197451
[12:27] <apw> bloody macs
[12:27] <Kaloz> apw :P only haswell I was able to pick up
[12:27] <smb> Kaloz, and yes, fix committed should be only set by us when we apply it
[12:28] <Kaloz> apw: anyways, with the help of the Intel guys that one is fixed, and with the help of the hda maintainer sound fully works, too. actually, everything works almost flawlessly with linux now
[12:29] <Kaloz> smb: as I can't switch it back to Triaged, Confirmed or In Progress fits better for you?
[12:29] <smb> Kaloz, I switched it back to triaged
[12:29] <Kaloz> ok, thanks
[12:29] <apw> smb, heh so did i
[12:30] <apw> i hate LP
[12:30] <smb> apw, Which lp does not care about. :-P
[12:30] <smb> +1
[12:30] <smb> Hm, that upstream report looks like that was CSM not working but EFI did?
[12:31] <Kaloz> EFI does, but only with the patch
[12:31] <smb> ah ok, have not read through all comments
[12:31] <Kaloz> otherwise LPSS makes the kernel puke and it happens before framebuffer gets initialized
[12:32] <Kaloz> so one gets no output at all :P
[12:32] <apw> Kaloz, that fix hasn't hit linus' tree as yet, so ... we are going to be resistant on picking it up
[12:32] <apw> in case it changes
[12:34] <Kaloz> apw: well, it's surely affects the macs, but if you check the patch, it could fail on other systems, too.. I know it's queued for 3.12, but stable was added in CC -- no idea when Linus would merge it
[12:40]  * henrix -> lunch
[12:45] <smb> Looks to be in linux-next which is a good sign
[13:39] <rtg> apw, just sent you an email re: aufs fails to load. your changes in -5.10 may have broken it
[13:40] <apw> rtg, ack
[13:57] <apw> rtg, upstream aufs foobar on release, am sorting out
[13:57] <rtg> apw, ack. I assume this'll require an upload to fix.
[13:58] <apw> rtg, yes code fix required, will get it on the tip as soon as i have it tested
[13:58] <apw> i think it should be abi agnostic, so we can shove it in quick
[14:19] <rtg> apw, aufs may not change the ABI, but 'mfd: rtsx: Read vendor setting from config space' does. drat.
[14:19] <ppisati> brb
[14:32] <rtg> apw, rebased and pushed ABI bump
[14:33] <apw> rtg, ok will get this test done and shove mine on the top
[14:43] <rtg> ppisati, rebooting tangerine for kernel update
[14:45] <ppisati> rtg: ack
[14:48] <rtg> ppisati, though, as usual, it doesn't seem to wanna reboot without a power cycle.
[14:50] <ppisati> rtg: yep
[14:52] <rtg> ppisati, tangerine is back
[14:52] <ppisati> rtg: cool, thanks
[14:59] <rtg> apw, there is a bug about the aufs bits: bug #1222407
[14:59] <ubot2`> Launchpad bug 1222407 in linux (Ubuntu) "3.11.0-5.11 has broken aufs support (needed for docker)" [Undecided,Confirmed] https://launchpad.net/bugs/1222407
[15:02] <apw> rtg ok ta will reference that
[15:03] <rtg> apw, looks like a simple thinko ?
[15:03] <apw> just a bit of code which got lost in a rearrangement indeeed
[15:06] <rtg> henrix, kamal, bjf: bug #1222442 is a straightforward regression with analysis. please check our other stable releases to see if they are affected. 
[15:06] <ubot2`> Launchpad bug 1222442 in linux (Ubuntu) "Linux kernel regression: Links on CIFS shares" [Undecided,Incomplete] https://launchpad.net/bugs/1222442
[15:07] <henrix> rtg: looking...
[15:07] <apw> a
[15:07] <bjf> rtg, if there is a fix, we are cranking this week so we could get this fixed up right away
[15:08] <rtg> bjf, chat of Ben to see if its been reported in debian
[15:08] <rtg> chat up*
[15:11] <henrix> rtg: bjf: the fix is already upstream (757c4f6260febff982276818bb946df89c1105aa) and ben's 3.2 kernel containing it is currently under review
[15:12] <smb> rtg, I think gomeisa might be pending a reboot too. Right now I could interrupt what I am doing if it is otherwise idle
[15:12] <rtg> smb, hmm, I think it is up to date
[15:12] <kamal> rtg, henrix, apw: the change that the reporter says introduced the bug is
[15:13] <kamal> upstream commit 62106e9 cifs: only set ops for inodes in I_NEW state
[15:13] <kamal> and it *has* been applied to all stable trees
[15:13] <smb> rtg, Yeah, should have looked before. I *thought* I had seen it but probably some other host
[15:13] <henrix> kamal: yeah, check my msg ^^^ (forgot to highlight your nick :) )
[15:13]  * smb logs in into too many
[15:14] <kamal> henrix, doh!
[15:14] <henrix> kamal: the fix for that bug is tagged for stable and is under review for precise
[15:14] <henrix> kamal: i've it queued for Q as well, but i'll probably just SRU it as i won't be releasing a 3.5 this week
[15:14] <kamal> henrix, and it looks like I've already applied the fix to 3.8-stable, but you have *not* applied it to 3.5-stable
[15:15] <henrix> kamal: i did (today!) :)
[15:15] <kamal> henrix, ah ha!
[15:15] <apw> rg
[15:15]  * smb lends apw a t
[15:15] <apw> rtg, just pushed some updated aufs bits which fix the current issue
[15:15] <apw> smb, thanks, i needed that
[15:15] <bjf> henrix, please SRU it and as long as you are doing yours, please do the precise one as well
[15:16] <henrix> bjf: ack
[15:16] <henrix> kamal: have you released 3.8 with this fix, or shall i SRU it as well?
[15:16] <rtg> apw, cool. will package and upload after I've finished reviewing my pile of LP bugs.
[15:16] <apw> rtg, ack and thanks
[15:17] <kamal> henrix, bjf: I have released it (in 3.8.13.7) ... it already appears in raring's master-next
[15:17] <bjf> kamal, ack
[15:17] <henrix> kamal: cool, so i'll just prepare the P and Q patches
[15:18] <kamal> henrix, agreed
[15:19] <rtg> kamal, there is a note on the k-team list for you regarding 3.8 stable: "nouveau fix for ubuntu kernel" 
[15:19] <kamal> rtg, thanks! will look shortly
[15:20] <rtg> bjf, kamal: its an obvious bug fix and should likely get applied before the next turn of the crank
[15:20] <bjf> rtg, ack, can do
[15:26] <rtg> kamal-afk, bug #1222627 appears to be made just for you
[15:26] <ubot2`> Launchpad bug 1222627 in linux (Ubuntu) "Suspend stopped working after the 3.8.0-30 upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/1222627
[15:33] <apw> r
[15:33] <apw> rtg, i didn't put the bug link in that aufs update, cause it was scripted
[15:34] <rtg> apw, I'll get it in
[15:34] <apw> rtg, ta
[15:38] <rtg> apw, I'm gonna upload this kernel since the aufs bug is causing some real issues.
[15:38] <apw> rtg seems appropriate
[15:59] <bjf> kamal-afk, i'll sru the nouveau driver fix (unless you've already done it)
[16:24] <henrix> bjf: while we're at regressions, i never managed to get any reply from bug #1215513
[16:24] <ubot2`> Launchpad bug 1215513 in linux (Ubuntu) "System locks up, requires hard reset" [High,Incomplete] https://launchpad.net/bugs/1215513
[16:24] <henrix> bjf: the one on the staging zram bug
[16:25] <kamal> bjf, I haven't looked at the nouveau thing yet ... feel free to handle it.
[16:26] <bjf> kamla, done
[16:26] <rtg> kamal even
[16:27] <bjf> henrix, greg sob'd it, it must be good
[16:28] <rtg> besides, its a staging driver....
[16:29] <henrix> bjf: rtg: agreed.. so we just keep it as it is and i'll try to keep an eye on other regressions on this driver
[16:30] <bjf> henrix, no, let's go ahead and sru that fix and get it into this cycle
[16:31] <henrix> bjf: oh, ok. so... iirc the backport isnt trivial and i would rather revert the commit that introduced the issue then having an untested (possibly broken) fix.
[16:32] <henrix> bjf: but i'll have to look again to the fix (there has been a weekend since last time i looked!)
[16:34] <bjf> henrix, ack, go for the simple fix if the backport is a pita
[16:34] <henrix> bjf: ack
[18:18] <dave_> hi, what should I use for grouper: "fakeroot debian/rules binary-omap4" (from https://wiki.ubuntu.com/KernelTeam/ARMKernelCrossCompile)
[18:19] <rtg> dave_, I use 'dpkg-buildpackage -d -B -aarmhf -us -uc'
[18:21] <dave_> rtg: I was trying this all weekend. It builds. But I can't deploy the zImage (via abootimg) on grouper. It won't boot.
[18:21] <rtg> hmm, well that is a different issue
[18:22] <dave_> rtg: what am I supposed to do once 'dpkg-buildpackage -d -B -aarmhf -us -uc' is finished? How do I get the kernel (boot.img) replaced?
[18:23] <rtg> dave_, there is some abootimg magic that I can never remember. perhaps ogra_ does.
[18:23] <ogra_> just run flash-touch-kernel ... it should dtrt
[18:24] <ogra_> root@ubuntu-phablet:/# flash-touch-kernel -h
[18:24] <ogra_> usage: flash-touch-kernel [path to kernel]
[18:24]  * rtg -> lunch
[18:24] <ogra_> (needs zImage|vmlinuz)
[18:25] <dave_> where does flash-touch-kernel come from?
[18:26] <ogra_> initramfs-tools-ubuntu-touch 
[18:26] <ogra_> it is preinstalled on the device
[18:26] <ogra_> (and undocumented on purpose :) )
[18:27] <dave_> yes, flash-touch-kernel is on the device. But how is that supposed to work? I can cp a zImage over and flash it on the device???
[18:28] <ogra_> yes
[18:28] <ogra_> adb push zImage /tmp/
[18:28] <ogra_> adb shell
[18:28] <dave_> let me try that
[18:28] <ogra_> flash-touch-kernel /tmp/zImage
[18:30] <ogra_> (you could also just install the .deb of your build, flash-touch-kernel will be called automatically if you do that
[18:30] <ogra_> )
[18:33] <dave_> (when I was trying to install my .deb files,  got an error msg saying smth like "cannot write to /system/.." or similar)
[18:33] <dave_> "flash-touch-kernel /tmp/zImage" does not work. My zImage is not good I guess.
[18:35] <dave_> "fastboot flash boot saucy-preinstalled-boot-armhf+grouper.img" and I'm back in business :-)
[18:35] <dave_> So let me see, 'dpkg-buildpackage -d -B -aarmhf -us -uc' should work on raring?
[18:37] <rtg> dave_, I build on precise using  gcc-4.6-arm-linux-gnueabi
[18:37] <phillw> Hi, is the fix for bug 1218691 noteworthy to kernel team / bug-team / ubuntu+1 ?
[18:37] <ubot2`> Launchpad bug 1218691 in linux-firmware (Ubuntu) "Possible missing firmware /lib/firmware/radeon/KAVERI" [Low,Triaged] https://launchpad.net/bugs/1218691
[18:38] <rtg> phillw, its benign (unless you have a Radeon that requires the Kaveri firmware)
[18:38]  * apw gives up for the day
[18:39] <dave_> rtg: gcc-4.6-arm-linux-gnueabi is not available on raring. I am using 4.7 here. But I also tried on precise + quantal (chroot) with gcc-4.6-arm-linux-gnueabi. On quantal I can build complete. Maybe I should try that zImage with flash-touch-kernel...
[18:39] <rtg> dave_, we had trouble with 4.7 and higher. it would not produce a bootable kernel
[18:40] <phillw> rtg: in my tiny opinion, having the warning message still flag up is a pain and could lead to further bug reports. However, I leave it in your good hands :)
[18:40] <dave_> rtg: OK
[18:40] <dave_> rtg: precise and quantal both good?
[18:40] <rtg> phillw, I'm hoping the kaveri firmware is upstream by the time saucy releases
[18:41] <rtg> dave_, same cross compiler IIRC, so yeah it should be
[18:41] <phillw> rtg: is there anyone I should ask about https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1218691/comments/4
[18:41] <ubot2`> Launchpad bug 1218691 in linux-firmware (Ubuntu) "Possible missing firmware /lib/firmware/radeon/KAVERI" [Low,Triaged]
[18:42] <phillw> it is there, just possibly needs a sponsor?
[18:44] <rtg> phillw, get the radeon guys to send a patch to Ben Hutchings <ben@decadent.org.uk> to include the Kaveri firmware 
[18:44] <phillw> rtg: do they have a channel? 
[18:45] <rtg> phillw, the linux kernel mailing list (which the radeon devs should know about)
[18:49] <phillw> rtg: thanks, will do :)
[19:18] <dave_> what is "build-generic-lpae" good for?
[19:25] <apw> dave_, larger memory systems (in arm land)
[19:26] <rtg> apw, what happended with you "giving up" for the day ?
[19:28] <dave_> am I supposed to use ./debian/build/build-generic/arch/arm/boot/zImage for grouper, or "./debian/build/build-generic-lpae/arch/arm/boot/zImage" ?
[19:28] <rtg> dave_, I think you're not building from the right branch
[19:29] <dave_> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-saucy.git
[19:29] <dave_> git checkout -b grouper remotes/origin/grouper
[19:29] <rtg> you should be building from the grouper branch (which does not contain an lpae flavour)
[19:29] <dave_> huh?
[19:30] <rtg> well, that looks right wrt  the branch name.
[19:32] <dave_> well, I just tried a new "./debian/build/build-generic/arch/arm/boot/zImage" and it still doesn't boot on my grouper
[19:33] <dave_> how would I skip building drivers, if I'm in a hurry?
[19:34] <dave_> (I'm a little more familiar with the AOSP build process)
[19:37] <dave_> Looks like I was indeed not on the grouper branch.
[19:43] <dave_> woah, I'm in
[19:46] <dave_> rtg + apw: thank you. "which does not contain an lpae flavour" was solving it for me :)
[19:47] <rtg> dave_, cool
[19:47] <dave_> ...and "flash-touch-kernel /tmp/zImage" is helpful info. But I need to master abootimg too. Thank you!!
[19:48] <rtg> dave_, as for skipping drivers, there really aren't any shortcuts because of debian packaging.
[19:48] <rtg> nuless you _really_ know what yuo're doing
[19:48] <rtg> unless*
[19:50] <dave_> aha. well, normally I do. I just made a mistake in my chroot. didn't have git installed... lalala
[19:51] <dave_> my I ask how long it takes for you to build, say, grouper from scratch?
[19:51] <rtg> dave_, 5-7 minutes on my 4-way 80 CPU server
[19:51] <rtg> longer on my laptop
[19:52] <dave_> "4-way 80 CPU"?
[19:52] <rtg> dave_, its kind of noisy too
[19:53] <rtg> oops, only 64 hyper-threads
[19:53] <ogra_> oh, cking is already gone 
[19:53] <dave_> rtg: are you honest?
[19:54] <rtg> ogra_, of course. we chase him off every day at 5P
[19:54] <ogra_>  [    0.000183] Calibrating delay loop (skipped) preset value.. 13.53 BogoMIPS (lpj=67677)
[19:54] <ogra_> :)
[19:54] <ogra_> 13.53 ... funny value for a 1.6 GHz CPU on boot 
[19:54] <rtg> dave_, processor	: 63
[19:54] <rtg> vendor_id	: GenuineIntel
[19:54] <rtg> cpu family	: 6
[19:54] <rtg> model		: 46
[19:54] <rtg> model name	: Intel(R) Xeon(R) CPU           X7550  @ 2.00GHz
[19:54] <ogra_> i'll try to catch him tomorrow then 
[19:55] <dave_> I admit it takes longer that 5-7 minutes on mine. But won't say how much.
[20:05] <dave_> boot.img via abootimg working also. Life can be good.
[21:03]  * rtg -> EOD
[21:48] <dave_> Why no adb logcat during boot? Or is there a trick?
[21:50] <ogra_> during boot ?
[21:51] <dave_> yeah, link on that other OS, you know.
[21:52] <dave_> like
[21:54] <ogra_> no, we are not that other OS :) our logs live in /var/log 
[21:54] <ogra_> but you can use /system/bin/logcat to get logcat output from the android container
[21:54] <ogra_> (it isnt in PATH)
[21:58] <dave_> When this other OS is installed I can run "adb logcat" on my laptop and if the grouper is connected via USB I can watch it boot, from very early on. When I have Ubuntu installed, "adb logcat" shows nothing during boot.
[22:10] <dave_> Above, I was talking about the system log, not the kernel log. The kernel log can be watched during boot like so: adb shell cat /proc/kmsg (on the other OS). Maybe just a simple adb thing, that can be enabled?