[06:15] <inahandizha> http://VisitsToMoney.com/index.php?refId=386970
[07:47] <ppisati> yo yo yo
[08:36] <apw> yo
[08:36] <ogra_> ghurt
[11:34] <cking>  smb, i'm of the opinion IPMI probably be should be for x86 specific arches for T and we don't consider any other support of IPMI by default for other arches
[11:35] <apw> yeah for now, the upstream advise was an x86 centric thing, so leavin the others =m sounds reasonable
[11:35] <apw> and we can fix those on a whine by whine basis
[11:35] <smb>   cking Agreed. I don't know enough about what exists or not in the Arm world to make any better decision
[11:35] <apw> i am assuming ppisati is sorting out a patch (if he hasn't already)
[11:35] <smb> apw, Yeah
[11:36] <cking> apw, ppisati has sent a patch, and I've commented on it, so I guess another iteration is required to turn it back to =m for anything apart from x86
[11:36] <smb> I just saw that from x86 world where you can have some ipmi support but no declaration of it, that default probe just reads from "known" port addresses
[11:36] <smb> But that likely has complete other meaning in Arm
[11:36] <cking> bad x86 centric world view
[11:37] <smb> cking, come first serve first... :-P but yeah
[11:39] <infinity> Wait, why is there ipmi support in the kernel at all?
[11:39] <infinity> What has Intel done now?
[11:43] <infinity> cking: Please tell me this doesn't mean what I think it means (listening to the world with a known-insecure protocol, so everyone and their dog can reboot my computer?)
[11:47]  * cking is now overly concerned too
[11:51] <smb> infinity, ITs an interface to a BMC which should work even when no network access for the bmc has been set up
[11:51] <smb> The driver only "listens" to a character device
[11:52] <infinity> smb: Right, okay.  So, it's the module that ipmitool uses for localhost access.
[11:52] <infinity> smb: That's all that's being discussed here?
[11:52] <smb> infinity, Yes
[11:52] <infinity> smb: Still feels bloaty and wrong to have that build into the zImage, but no, not overly dangerous on x86, I'd guess.
[11:52] <infinity> s/build/built/
[11:53] <smb> infinity, That we changed ipmi_si (system interface driver, that char device this) to be built-in because it apparently can be a problem if not (on x86)
[11:53] <cking> compared to ACPI, it's not that bloaty
[11:54] <smb> infinity, Right now it probably is. And not well understood either (hence the fail for probing)
[11:54] <infinity> cking: Compared to ACPI, my mom's slim.
[11:54] <smb> infinity, It might be in future when Arm gets not well implemented acpi tables in larger scale...
[11:55] <infinity> smb: On ARM today, the IPMI driver Just Works on the three pieces of hardware that have IPMI BMCs, but probably scribbles the heck all over random memory on everything else. :P
[11:56] <infinity> It's like a return to the dark ages of ISA probing.
[11:56] <infinity> "Is that a video card over there?  Maybe a network card?  Wait, I think it's a.  Oh, nevermind, we'll just hang now.  And maybe play an awful tone on the PC speaker just because we hate you so."
[11:56] <smb> infinity, Yeah I would have to re-read it but probably when it found something with the other methods acpi, pci, smi it does not try the "default" method
[11:57] <smb> And nobody ever wondered whether that default method is working anywhere outside x86... :-P
[13:37] <brendand> bjf, i've lost track of the cadence. is this one ending on the 7th of march?
[13:55] <bjf> brendand, yes
[15:27] <Doctor_Nick> Hi, the wrong kernel version is in 3.14rc3 on the kernel ppa, can someone please fix this?
[15:27] <Doctor_Nick> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-rc3-trusty/
[15:30] <apw> Doctor_Nick, think i have found a variable aliasing issue, so the binaries are 3.14-rc3 just the .debs are named wrong
[15:30] <apw> i'll let it rebuild and see if that resolves it
[15:32] <Doctor_Nick> apw: cool, thanks
[15:32] <Doctor_Nick> apw: btw, where are the source packages for these?
[15:33] <apw> Doctor_Nick, there are no source packages, they are built from the source you get by checking out the commit listed in "COMMIT" and then applying the patches in the same directory
[15:34] <apw> Doctor_Nick, having the source pacakges too would about double the disk needed for each build
[15:34] <Doctor_Nick> true, the kernel package is pretty big
[15:35] <Doctor_Nick> what's the url for the source repo?
[15:36] <Doctor_Nick> oh, you mean directly from the kernel.org git?
[15:38] <_bjf> Doctor_Nick, our trusty git repo is at git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git
[15:38] <Doctor_Nick> ah, ok
[15:46] <apw> Doctor_Nick, though in the case of v3.14-rc3 that tag comes direct from the kernel.org repos
[15:47] <Doctor_Nick> ok, thanks
[17:17] <ogra_> wheee ! beaglebones !
[17:43] <ppisati> ogra_: you what's a pity? that i had to manually craft my own installation for it... if only we had a tool that created custom ubuntu dd-able images... ahhhh.... :)
[17:43] <ppisati> *you know
[17:44] <ogra_> i'm working on reviving rootstock ... but currentl touch is the only stuff that works in rootstock-ng
[17:46] <ppisati> ogra_: you know there's a rainy weekend in front of us, right? :)
[17:46] <ogra_> in italy perhaps :P
[17:46] <ogra_> germany has sun and springy waether all the time ;) 
[17:48] <ppisati> :)
[17:54] <JanC> > 10 °C expected for tomorrow here too...
[17:55] <JanC> and around that for the weekend too, with maybe some rain on Saturday before noon, and sun after that  :)
[18:19] <rsalveti> apw: infinity: why did we published the 4.4 based kernels?
[18:19] <rsalveti> mako/manta
[18:20] <apw> rsalveti, i don't recall doing anything there
[18:20] <rsalveti> it seems infinity copied them over
[18:21] <apw> erp
[18:23] <rsalveti> alright, as long we don't rebuild the android package until I'm able to drop the 4.4.2 version (which should hopefully happen tomorrow), we're still good
[18:23] <rsalveti> otherwise mako/manta will not even boot properly
[18:23] <apw> it looks like we uploaded it to the PPA correctly, but i cannot account for them moving out
[18:24] <rsalveti> yeah, guess infinity just moved everything that made sense (maybe because of FF)
[18:28] <apw> hmmm, yeah, i guess if things catch on fire we'll have to work out how to shove the old contents back into the new branch for a bit
[19:48] <jtaylor> hi todays kernel update seem to have broke perf
[19:49] <bjf> jtaylor, details? kernel version ?
[19:49] <jtaylor> /usr/lib/linux-tools/3.13.0-11-generic/perf -> ../linux-tools-3.13.0-11/perf
[19:49] <jtaylor> but its in /usr/lib/linux-tools-3.13.0-11/perf
[19:49] <jtaylor> one level down more
[19:49] <bjf> apw, ^ ?
[19:51] <apw> bjf, ta
[19:51] <bjf> i'm sure
[19:52] <apw> jtaylor, heh, that i could believe, i am doing a test build right now for tools so i will check it out
[19:52] <jtaylor> thx
[19:52] <jtaylor> < on trusty
[19:53] <apw> jtaylor, bah yeah that is just plain wrongo, will sort it out, i assume you can find your perf binary by hand in the interim
[19:54] <jtaylor> yes I fixed the link and it works
[19:55] <apw> jtaylor, well that at least is positive, i'll let these build complete and check i have sorted the pooch
[19:56] <apw> i suspect this and the ipmi issue might mean it is worth doing an upload sooner rather than later
[22:39] <miseria> la palabra manipuladora que dice un perdedor y arrogante pacifista si no estas conmigo, eres mi enemigo  bienvenidos httpcastroruben.com temo_a_un_ser_sin_rival