[08:39] <tgardner> cking, bug #818830
[08:39] <ubot2> Launchpad bug 818830 in linux "[Sandy Bridge] serious power regression from kernel 3.0.0-6 to 3.0.0-7 (rc6 disabled)" [Medium,Triaged] https://launchpad.net/bugs/818830
[08:57] <apw>         INTEL_VGA_DEVICE(0x0102, &intel_sandybridge_d_info),
[08:57] <apw>         INTEL_VGA_DEVICE(0x0112, &intel_sandybridge_d_info),
[08:57] <apw>         INTEL_VGA_DEVICE(0x0122, &intel_sandybridge_d_info),
[08:57] <apw>         INTEL_VGA_DEVICE(0x0106, &intel_sandybridge_m_info),
[08:57] <apw>         INTEL_VGA_DEVICE(0x0116, &intel_sandybridge_m_info),
[08:57] <apw>         INTEL_VGA_DEVICE(0x0126, &intel_sandybridge_m_info),
[08:57] <apw>         INTEL_VGA_DEVICE(0x010A, &intel_sandybridge_d_info),
[08:57] <apw> tgardner, ^^
=== smb` is now known as smb
[09:52] <Q-FUNK> smb: hiya :)
[09:52] <smb> Q-FUNK, morning
=== firewave is now known as FireWave_Job
=== bigbash is now known as zz_bigbash
[13:17]  * ppisati bails out for a bit...
[13:19]  * ogasawara back in 20
[13:46] <morgs> Hi, I need to get an updated version of the e1000e driver on a lucid box. I'm struggling to find a guide to building this the Ubuntu way - been years since I compiled a kernel.
[13:46] <morgs> Can anybody point me in the right direction please?
=== hcfd__ is now known as hcfd
[14:39] <ppisati> mdeslaur: ping
[14:39] <mdeslaur> ppisati: yes?
[14:39] <ppisati> mdeslaur: CVE-2011-2479
[14:39] <ubot2> ppisati: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2479)
[14:40] <ppisati> mdeslaur: are you it affects hardy, lucid and maverick too?
[14:41] <mdeslaur> ppisati: I don't know, I didn't look at ti
[14:41] <mdeslaur> s/ti/it/
[14:41] <ppisati> mdeslaur: can you give it a look?
[14:42] <ppisati> bug 869230
[14:42] <ubot2> Launchpad bug 869230 in linux-lts-backport-natty "CVE-2011-2479" [Medium,Fix committed] https://launchpad.net/bugs/869230
[14:42] <ppisati> actually you opened the lp bug for it
[14:42] <mdeslaur> ppisati: the kernel workflow script I use opened the bug
[14:43] <mdeslaur> ppisati: I'll ask jj to take a look at it when he arrives
[14:43] <ppisati> oook
[14:43] <ppisati> :)
[14:44] <herton> ppisati: you fsl-imx51 pull is adding debian/changelog back, it shouldn't
[14:44] <herton> *your
[14:45] <ppisati> crap
[14:48] <ppisati> herton: try now
[14:48]  * ppisati always screw up something...
[14:50] <herton> ppisati: it's ok now, but looking at the debian.fsl-imx51/changelog, it misses lucid-proposed, instead of UNRELEASED. also tracking bug is missing from the changelog
[14:50] <ppisati> grrr... :)
[14:50] <ppisati> wait
[14:51] <ppisati> than i forgot the Buglink in mvl-dove too
[14:51] <herton> sorry man, never tried verify-release-ready on topic branches but probably we should make them run against the arm branches to catch all these minor errors
[14:55] <ppisati> herton: what the lp bug for imx51?
[14:56] <ppisati> i already deleted the email
[14:56] <herton> ppisati: 873059
[14:56] <herton> but you can look also at http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html if you need to recall
[14:58] <ppisati> herton: ok, imx51 should be ok now
[14:58] <ppisati> herton: i fix the mvl-dove now
[15:06] <ppisati> herton: ok, and mvl-dove should be ok too now
[15:08] <herton> ppisati: looks good now. This should be the last mvl-dove update for lucid, after this no more tracking bugs will be created for it, I'll forward/cc you on the email
[15:09] <ppisati> herton: saw it, but we still need it for maverick
[15:10] <herton> ah ok. yes, the branch will have to still be maintained so the maverick rebase script can grab it
[15:12] <ppisati> yep
[15:40] <ogra_> apw, around ?
[15:41] <apw> s'up
[15:41] <ogra_> https://blueprints.launchpad.net/ubuntu/+spec/arm-p-optional-initrd
[15:41] <ogra_> have a look (its only a very rough draft yet)
[15:41] <ogra_> do you think it would be possible to teach the kernel to use UUIDs without initrd ?
[15:42]  * ogra_ wants to know if thats feasable, lese the spec is moot
[15:42] <ogra_> *else even
[15:47] <apw> ogra_, why so keen to get rid of the initrd ?
[15:47] <apw> ogra_, and have you considered building the initrd into the kernel
[15:47] <ogra_> apw, bootspeed 
[15:48] <ogra_> and complexity on arm ... 
[15:48] <ogra_> users coming from other distros are not familiar with the initrd concept
[15:48] <apw> if you build the initrd with only the needed stuff, how far from ideal would that be
[15:48] <ogra_> it will still switch the rootfs twice
[15:48] <ogra_> and process /init and then upstart
[15:49] <ogra_> we can work fine without initrd, the only two blockers are the packages that put stuff in there and actually need it before rootfs and the missing UUID support in the kernelö
[15:49] <apw> for me loading the initrd is the main cost, if you are goign to build everything in, won't the kernel just be a beast instead and take ages to load
[15:49] <ogra_> likely
[15:50] <apw> so have you meansured how much time you are going to save by not having
[15:50] <ogra_> why would i build anything beyond the basic boot stuff into the kernel anyway
[15:50] <ogra_> no, but thats scope of the spec
[15:50] <ogra_> i havent measured anything yet, currently its just a spec idea
[15:51] <apw> ogra_, define basic boot stuff
[15:51] <ogra_> the package stuff is easy to solve, but i have no clue about how much work it would be for the kernel side
[15:51] <ogra_> apw, well, the filesystems we use and the HW specific bits needed to mount /
[15:53] <ogra_> i'm looking from an arm prespective indeed
[15:53] <ogra_> where we dont have a kernel you re-use on multiple boards 
[15:56] <mdeslaur> jjohansen: ppisati had a question about  CVE-2011-2479, could you please help him?
[15:56] <ubot2> mdeslaur: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2479)
[16:00] <jjohansen> ppisati: what can I do for you on CVE-2011-2479
[16:00] <ubot2> jjohansen: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2479)
[16:01] <ppisati> jjohansen: i gave it a look
[16:01] <jjohansen> ppisati: okay
[16:01] <ppisati> jjohansen: and it seems it's all about mm huge pages
[16:01] <jjohansen> hrmm
[16:01] <ppisati> jjohansen: but it seems to me we don't have that stuff in hardy/lucid/maverick
[16:02] <ppisati> i mean
[16:02] <ppisati> we have the hugetlbpages but no huge pages
[16:02] <ppisati> we don't even have the vm flag HUGE_PAGE
[16:02] <jjohansen> right
[16:02] <ppisati> so i was wondering if it affects that kernel too
[16:02] <ppisati> *kernels
[16:02] <jjohansen> ppisati: unlikely but I can take a look
[16:03] <ppisati> jjohansen: that would be nice
[16:03] <ppisati> jjohansen: btw, redhat said it doesn't affect their RHEL 4,5 releases
[16:03] <ppisati> jjohansen: but i didn't check what kernels they are using on these releases
[16:04] <jjohansen> ppisati: heh, I can never keep track, and have to go check but RHEL 4,5 feels anchient
[16:04] <jjohansen> 2.6.9
[16:04] <ppisati> ah ok
[16:04] <ppisati> :)
[16:05] <jjohansen> :)
[16:05] <ppisati> anyway, if you can take a look at it
[16:05] <ppisati> that would be nice
[16:05] <jjohansen> yep, I'll look, I expect they won't be affected though
[16:05] <ppisati> ok
[16:06] <ppisati> actually it could be that the huge page logic that is affected in natty "madvise_$whatever_hugepages" back then was in the general madvise() but the fact that we don't even have the vm HUGEPAGE flag made me think that, perhaps, these kernels are not affected
[16:07] <ppisati> anyway, i'll let you look at it
[16:08] <jjohansen> well without having looked I am expecting its in andrea's huge page patches that where introduced in 2.6.37/38 time frame
[16:14] <jjohansen> ppisati: as I expected its in the transparent huge pages stuff which was introduced in 2.6.38
[16:14] <ppisati> jjohansen: nice
[16:18] <ppisati> btw, is there a way to "skip" splash screen while booting? i've a machine where oneiric hangs 
[16:18] <apw> ppisati, yep, change the set gfxpayload=xxx to =text and drop quiet splash from the command line replacing them with debug
[16:19] <ppisati> no grub here
[16:19] <ppisati> i mean something interactive
[16:20] <ppisati> or better, i don't have the interactive menu anymore
[16:22] <Q-FUNK> apw: welcome back! 
[16:22] <Q-FUNK> apw: would you happen to know why 3.1 mainline kernels no longer ship vesafb?
[16:23] <apw> ppisati, holding shift as grub loads ?
[16:23] <apw> Q-FUNK, not specifically, does it still exist?
[16:23] <ppisati> apw: nice, didn't know
[16:28] <Q-FUNK> apw: by the looks of it, the Kconfig option still exists but, for some reason, it's not built in the mainline kernels we have prepackaged for testing.
[16:28] <Q-FUNK> apw: ogasawara thought that you might know why.
[16:31] <Q-FUNK> apw: on hosts without KMS drivers, it produces a blank screen on bootup.
[16:39]  * ppisati -> gym/workout
[17:22] <Q-FUNK> did the archive key just change or is my APT going nuts?
[17:32] <Q-FUNK> ah. right. congratulations to whoever just pushed one eric out the door.
=== yofel_ is now known as yofel
=== zz_bigbash is now known as bigbash
=== bigbash is now known as zz_bigbash
=== SanbarComputing is now known as sanbar