[00:00] <jjohansen> ah, right let me look at the man page more carefully
[00:04] <jjohansen> txomon: va_dcl is a define brought in by #include "arargs.h" to define anything that the compiler may need for the old style varags
[00:04] <jjohansen> from vararhgs.h
[00:04] <jjohansen> +#if __GNUC__ == 3 && __GNUC_MINOR__ >= 3
[00:04] <jjohansen> +#define	va_dcl			__builtin_va_alist_t __builtin_va_alist;
[00:04] <jjohansen> +#else
[00:04] <jjohansen>  #define	va_dcl			__builtin_va_alist_t __builtin_va_alist; ...
[00:04] <jjohansen> +#endif
[00:05] <jjohansen> so it may expand to nothing, or it can expand to some attributes to tell the compiler the function is using varages
[00:06] <jjohansen> I think it is only ever used on implementations that are using varargs.h instead of stdarg.h
[00:07] <txomon> oki
[00:08] <txomon> so is just something weird and outdated that I shouldn't take care off?
[00:08] <txomon> s/off/of
[00:10] <jjohansen> txomon: mostly yeah, if you are using varags.h you'll need it, but you should probably be using stdarg.h instead
[00:12] <txomon> ok, ty very much
[07:01] <smb> diwic, And I was just about to ask myself... :)
[07:50]  * apw yawns
[07:50]  * smb waves
[07:52] <ppisati> morning
[07:52] <apw> morning!
[08:15] <bryceh> hiya apw
[08:15] <apw> bryceh, hiya, late for you
[08:19] <bryceh> apw, unfortunately, not really (baby)
[08:19] <apw> ahh jj syndrome :)
[08:20] <bryceh> :-)
[08:30] <ppisati> so guys, according to the "kernel team new world order" i can't pull req till next week, right? (i mean the new topic branches discipline)
[08:34] <apw> ppisati, if they have asked you to prepare something, and its prepared i think you can ask anytime no?
[08:37] <ppisati> apw: didn't receive any notification... let me see if reading all the emails help
[08:38] <apw> smb, have they actually told you how they will tell you when there are derivative brach updates to do?
[08:38] <smb> apw, ppisati Not exactly. I guess the hope is that I won't miss the bugmail... but  Iam not convinced
[08:39] <smb> Last time I asked because I saw an upload message, there was none needed...
[08:40] <ppisati> anyway, the new omap4 kernel boots, has video working, etcetc and i wanted to give it to the arm people - i'll put a kernel pkg binary on people.* and push it to zinc so they can start tinkering with it
[08:40] <ppisati> rsalveti: ^
[08:41] <apw> ppisati, sounds good.  this is for oneiric ?
[08:41] <ppisati> yep
[08:41] <apw> ahh the new world order doesn't apply to that
[08:41] <apw> send away
[08:41] <ppisati> i want top dequeue ASAP so i can concentrate on the slow usb i/o thing
[08:42] <ppisati> doh!
[08:42] <ppisati> ok, pull req coming
[08:47] <apw> ppisati, slow usb> yeah that one is pretty odd, i think smb poked it a bit dunno if he had any insite to help get you started
[08:48] <smb> apw, Not too much but we talked about that yesterday
[08:48] <apw> smb, good enough
[09:26] <apw> RAOF, was it you who was asking me about mainline drm builds yesterday?
[09:50] <RAOF> apw: Yes, it was.
[09:50] <RAOF> apw: I haven't tried them yet; I want to see if those commits fix a bug where my external monitor gets permanently turned off.
[09:51] <apw> so remind me of the issue, the logs imply there has been no updates for a while now
[09:51] <apw> are we using teh wrong trees again ?
[09:56] <siji> smb, hi
[10:00] <apw> RAOF, ^^
[10:01] <RAOF> apw: The tree that I looked in FTBFS in ecryptfs
[10:01] <apw> oh really, hrm, which one
[10:02] <RAOF> I'm looking at http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/ whose COMMIT suggests that it contains the commits I'm after…
[10:10] <newb> hi
[10:10] <newb> I have a trouble in compile module...
[10:10] <newb> can anybody help?
[10:10] <apw> RAOF, seems that the ecryptfs boys have screwed the pooch
[10:11] <RAOF> Superlative
[10:11] <apw> will see if i can coax that option off and rebuild
[10:11] <RAOF> Of course, I *have* an ecryptfs filesystem.
[10:12] <RAOF> Just to make this super awkward.
[10:13] <newb> can anybody help my problem?
[10:13] <newb> my problem is same as here: http://www.incentivespro.com/forum/viewtopic.php?t=214
[10:13] <newb> If I compile my module, It says
[10:13] <newb> scripts/mod/modpost: 1: Syntax error: word unexpected (expecting ")") 
[10:13] <txomon> newb, syntax error
[10:14] <txomon> try in #c
[10:14] <txomon> if here nobody answers
[10:14] <txomon> bye!
[10:14] <RAOF> I guess I could just suck it up, cherry-pick those commits, and build a kernel locally.
[10:14] <newb> it is not a syntax error in my program...
[10:14] <newb> my program can compiled in my host PC
[10:14] <newb> I'm compile the module in target Embedded board
[10:15] <apw> newb, hm
[10:15] <RAOF> Different /bin/sh on your host and embedded?
[10:15] <ogra_> s/Embedded board/panda/ 
[10:15] <newb> yeah, pandaboard
[10:16] <apw> newb so on the machine which failed what does 'file scripts/basic/fixdep' say
[10:16] <ogra_> i sent newb here and asked him to compile natively instead of cross with the right headers installer 
[10:16] <ogra_> which i would have expected to work ... but apparently it causes that sytax error
[10:17] <ogra_> *headers installed
[10:17] <newb> first scripts/basic/fixdep is failed but
[10:18] <apw> newb, i don't think i understand what you mean there?
[10:18] <newb> Right now, I compile a module in Pandaboard
[10:18] <newb> And I install the kernel package linux-headers-2.6.38-1209
[10:18] <newb> linux-headers-2.6.38-1209-omap4
[10:19] <newb> linux-image-2.6.38-1209-omap4
[10:19] <newb> And then, I compile the module I wrote
[10:19] <newb> But it fails with scripts/basic/fixdep error
[10:19] <newb> So I tried "make modules_prepare" in /usr/src/linux-header forder
[10:19] <newb> but that command also fails...
[10:20] <apw> ok and on that system where the failure is occuring, what does 'file scripts/basic/fixdep' say
[10:20] <newb> Syntax error
[10:20] <newb> After the failure of "make modules_prepare", the error changed to "scripts/mod/modpost"
[10:21] <apw> no i mean the literal command, something like 'file /usr/src/*/scripts/basic/fixdep' what does _that_ command say
[10:23] <newb> you mean that command is "make modules_prepare"??
[10:24] <apw> no i want you to run the command 'file /usr/src/*/scripts/basic/fixdep' on the system which is failing the build and tell me what the output is
[10:24] <apw> if its long you could pastebin the output
[10:25] <newb> It was
[10:25] <newb> scripts/basic/fixdep: 1: Syntax error: "(" unexpected
[10:25] <apw> newb, no i really, really mean i want you to run the _new_ command i am giving you, not the old output
[10:26] <newb> sorry...
[10:26] <newb> I'll try
[10:27] <newb> I can type...
[10:28] <apw> newb if you have netowkr on the machine you can use pastebinit to upload the output
[10:28] <rsalveti> ppisati: I'd ask you to wait until tomorrow
[10:29] <rsalveti> ppisati: as tomorrow is the release date for the kernel at linaro
[10:29] <rsalveti> then you'll be getting the kernel from 11.08 release
[10:29] <rsalveti> ppisati: and as I said, you'd need to revert one patch to make sgx to work
[10:29] <newb> it says: /usr/src/linux-headers-2.6.38-1208-omap4/scripts/basic/fixdep: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped /usr/src/linux-headers-2.6.38-1209-omap4/scripts/basic/fixdep: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped
[10:29] <rsalveti> ppisati: where is your dev tree?
[10:30] <newb> apw: this is the output
[10:30] <apw> newb and if you run that /usr/src/linux-headers-2.6.38-1208-omap4/scripts/basic/fixdep directly, does it say Syntax error?
[10:30] <newb> there is no syntax error i think
[10:30] <newb> that is whole output
[10:31] <newb> the compile error is changed to modpost...
[10:31] <apw> newb i mean if you now additionally try and run the fixdep binary on the command line does it error
[10:32] <newb> additionally try and run the fixdep binary??
[10:32] <apw> what does executing /usr/src/linux-headers-2.6.38-1208-omap4/scripts/basic/fixdep say
[10:33] <newb> Usage: fixdep <depfile> <target> <cmdline>
[10:33] <ogra_> looks fine
[10:33] <apw> ok so that fixdep is ok
[10:33] <newb> ah
[10:33] <apw> and is a native binary as expected
[10:34] <newb> is it okay fixdep?
[10:35] <apw> newb, i think the Syntax error from the attempt to run fixdep is most likely caused by the fixdep it is running not being a binary for the machine you are compiling on
[10:35] <apw> the system things its not a binary so it tries to run it as a shell script, and it errors
[10:35] <newb> I execute /script/mod/modpost and it says cannot execute binary file
[10:36] <apw> and does that file exist and if so what does the command 'file <name>' on that file say
[10:37] <newb> It says executable, Intel 80386...
[10:37] <newb> I think it is not arm binary
[10:37] <apw> ok so that will not run on your arm machine indeed.  what is the full filename to that file
[10:38] <newb> filename:  /usr/src/linux-headers-2.6.38-1209-omap4/scripts/mod/modpost
[10:38] <ppisati> rsalveti: git://kernel.ubuntu.com/ppisati/ubuntu-oneiric.git ti-omap4
[10:39] <ppisati> rsalveti: the pull req is already out, i'll reissue another one when the next update hits
[10:39] <apw> newb, and who built the headers you have installed ?  was that us or you?
[10:39] <rsalveti> ppisati: ok
[10:39] <newb> me
[10:39] <newb> use dpkg-buildpackage
[10:39] <apw> newb, and where was it built? on the board or cross-compiled
[10:40] <ppisati> rsalveti: BTW, there're some new options about video&c (like OLD_VIDEO_$something) and that prevents some other DSS options to be turned on
[10:40] <newb> CROSS_COMPILE=arm-linux-gnueabi- do_tools=false dpkg-buildpackage -B -aarmel -uc -us
[10:40] <newb> cross-compiled
[10:41] <ppisati> rsalveti: when you compile the new kernel you'll see some warnings, revire it and tell me what i have to turn on/off
[10:41] <apw> newb, ok so you can only use cross-compiled kernels to cross-compile external modules and you need to use a native build kernel to native build external modules
[10:41] <ppisati> rsalveti: s/revire it/review them/g
[10:41] <apw> as the headers packages you are using contain copies of the binaries which are needed for the build, like modpost
[10:41] <rsalveti> ppisati: sure
[10:41] <ppisati> rsalveti: cool, thanks
[10:42] <newb> yes
[10:44] <newb> so what i have to do?
[10:45] <apw> use nativly compiled headers if you are compiling on the board and cross-compiled headers on your cross-compile environment
[10:46] <ogra_> just build on the panda
[10:46] <ogra_> that excludes such issues
[10:46] <ogra_> for a single module that wont make much difference in build time
[10:46] <apw> but you must use native header packages to do that, not ones you cross-compiled
[10:46] <newb> the compile of kernel in panda takes too long time....
[10:46] <ogra_> you want only a new module 
[10:46] <ogra_> no need to compile the kernel
[10:47] <apw> just use the one from the archive
[10:47] <newb> I need to change kernel too
[10:47] <apw> then you need to build both in the same place
[10:47] <newb> I need to use gpmc in pandaboard
[10:47] <apw> then you need to compile both your kernle and your external module in the very same environment
[10:47] <newb> so I need to modify kernel
[10:48] <rsalveti> ppisati: do you have a bug already for the issue with pulseaudio consuming 100% of the cpu?
[10:49] <rsalveti> ppisati: when using natty we also had that issue, as described by bug 816638
[10:49] <ubot2> Launchpad bug 816638 in linaro-ubuntu "Pulseaudio consumes 100% of the cpu when trying to play a sound with natty's linaro LEB and 3.0.0-1402-linaro-lt-omap " [High,Confirmed] https://launchpad.net/bugs/816638
[10:49] <rsalveti> but I still didn't reproduce with oneiric, so would be good to have your results
[10:50] <ogra_> newb, just out of curiosity, what are you using gpmc on a pandaboard for there is no flash ? 
[10:50] <newb> I want to connect FPGA
[10:50] <apw> RAOF, ok the issue for your build is that the new ecryptfs stuff is starting to use a new symbol from security/keys/encrypted.c, which means that if ecryptfs =y then that module needs to be =y, and it is =m and so its not there and blammo no buildy
[10:50] <ogra_> ah
[10:51] <apw> RAOF, now as it is a new requirement it is not obvious if you are able to move ECRYPTFS_FS=m for your test build then life will be ok
[10:52] <siji> apw, any updates on the Bug #824589
[10:52] <ubot2> Launchpad bug 824589 in ubuntu "improper Touch Screen Driver module(for arm beagleboard) for TSC2046 in the Expansion board,and it connect with DM3730 by SPI port ." [Undecided,Incomplete] https://launchpad.net/bugs/824589
[10:53] <apw> RAOF, so if you want that specific build you should be able to take a linus tree, git reset --hard to the sha1 in COMMIT, apply the patches in the directory, update the config and build the result
[10:58] <ppisati> rsalveti: nope, no bug yet
[11:00]  * ppisati -> lunch
[11:09] <siji> smb, ping 
[11:49] <smb> siji, Hi
[11:50] <siji> hi
[11:50] <siji> sorry for bothering you
[11:50] <siji> Just want to clarify something regd. kernel building 
[11:50] <smb> siji, Sure, just ask away
[11:51] <siji> I am trying to build it from my host PC(for omap3 beagle)
[11:52] <siji> And downloaded the kernel source from kernel.org , config file from ubuntu natty (/boot/config-2.6.38-8-omap
[11:53] <siji> so just want to confirm that if i did make modules with cross-gcc will it generate the module ?
[11:55] <smb> siji, You should generally be able to cross compile. But when you took the kernel source from upstream (which is 3.1-rc2 right now) the question is what version is running on your arm board. This may be completely incompatible
[11:56] <siji> smb, I think i have downloaded the right version 
[11:56] <siji> my arm kernel is 2.6.38-8
[11:57] <siji> (ubuntu natty -omap3)
[11:57] <smb> ppisati, Probably has the latest runes how to set up the cross compile part correctly, but still. Is there a reason you did not take the git tree from kerne.ubuntu.com for natty and changed to the ti-omap3 branch?
[11:57] <smb> siji, ^
[11:57] <siji> cose i think there is some bug in the desired module (ads7846) 
[11:58] <smb> Hm, actually natty already seems to be ti-omap4...
[11:58] <siji> ok
[11:58] <siji> actually the rootstock already built the the desired kernel module 
[11:59] <siji> but failed to insert it
[11:59] <siji> Bug #824589
[11:59] <ubot2> Launchpad bug 824589 in ubuntu "improper Touch Screen Driver module(for arm beagleboard) for TSC2046 in the Expansion board,and it connect with DM3730 by SPI port ." [Undecided,Incomplete] https://launchpad.net/bugs/824589
[12:00]  * smb looks at the report
[12:00] <smb> siji, Those kind of failure sounds like the module was build with the wrong headers somehow...
[12:01] <siji> smb, right but i have build it by rootstock 
[12:01] <smb> siji, I think I am not sure what you mean with rootstock
[12:01] <siji> smb, sorry 
[12:02] <siji> rootfile system building tool
[12:02] <smb> Ah
[12:02] <smb> Probably something doing a chroot to build
[12:03] <siji> right
[12:03] <siji> and there is a option in rootstock tool to build the kernel image too 
[12:03] <siji> which generated those modules 
[12:05] <smb> There seems to be something wrong with the tool or its usage then... But to get me correct, this driver is in the ubuntu kernel code and just not enabled or you need a newer version of it?
[12:06] <siji> the driver is there in the ubuntu kernel source +it has generated the loadable module 
[12:06] <siji> smb, you understood ?
[12:07] <smb> hmm, I try to parse... I may be a bit slow today...
[12:07] <siji> ok :)
[12:09] <siji> actually rootstock tool with the parameter linux-omap generated the RootFile System with initird and vmlinux of 2.6.38-8-omap 
[12:10] <smb> My confusion is that you said, that you got the kernel.org code and try to compile the module. The first question to me somehow is: why in the first place do you need the module compiled. You said there is a bug. So the original kernel package has the module but it does not work
[12:10] <siji> ah ,got it
[12:11] <siji> So you mean this bug is not only for ubuntu kernel 
[12:13] <siji> smb, what you will recomend ?
[12:13] <smb> Well maybe or maybe not. But generally its hard to claim it a bug when you try your own compile and it does not work as expected. At least not against a distro. You can say the module does not work and needs to be fixed or does not exist and should be enabled
[12:14] <siji> ok
[12:19] <smb> siji, And even just for giving help, there is a lot of information missing. Like the exact release and kernel version you are running. Where the module in question comes from, why it was made. Just looking at the content of the bug report there is unfortunately more questions open than answered.
[12:19]  * smb notes that we here may know how to compile kernels but have to mind-reading powers ;)
[12:21] <siji> smb, I assumes ubuntu-arm natty  is enough to indentify the kernel version 
[12:21] <smb> siji, There are updates
[12:22] <smb> It is clear that it is 2.6.38 but not exactly which upload
[12:22] <siji> ya may be .But this is build by rootstock for me 
[12:25] <smb> Yeah, but as I do not know what it is, I cannot say what it does exactly ... And what it takes as a source
[12:26] <smb> The module disagress about symbol could be wrong headers or slightly different configuration in something used by the module
[12:44] <tgardner> ppisati, are you ready for me to upload the meta package for oneiric ti-omap4 ?
[12:45] <tgardner> ppisati, never mind, just saw your email
[13:06]  * herton has to run an errand in business hours, back in 1h hopefully
[13:27]  * smb notices with some relief that assigning the topic branch tracking bug to him does make the notification go into a bucket which is not overflowing with other stuff..
[13:35] <apw> smb, heh something works then 
[13:35] <smb> yep
[14:45] <bjf> tgardner, ogasawara : http://people.canonical.com/~kernel/reports/_kernel_hot_.html
[14:46] <bjf> tgardner, ogasawara : this is the start of a "kernel hot list"
[14:46] <ogasawara> bjf: cool, I'll take a look
[14:46] <ogasawara> bjf: AM column stands for ?
[14:46] <bjf> ogasawara, "Affects Me"
[14:47] <ogasawara> ah, thanks
[14:47] <tgardner> bjf, is the AM column the metric that makes a bug 'hot' ?
[14:47] <bjf> tgardner, ogasawara : bdmurray clams that "heat" is working better, i'll be adding a "heat" column and if it works i may drop the CO SU AM columns
[14:48] <ogasawara> bjf: ack
[14:48] <tgardner> bjf, how is heat measured?
[14:48] <bjf> tgardner, ogasawara : we'll run with them all for a bit
[14:50] <bdmurray> tgardner: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/database/schema/trusted.sql#L1846
[14:50] <bdmurray> tgardner: the calculation is right there
[14:51] <tgardner> bdmurray, so I merely have to mark my bug private and a CVE to bump it to the top of the list.
[14:53]  * ogasawara back in 20
[14:56] <bdmurray> tgardner: yes that'd do it
[15:00] <tgardner> bdmurray, given that private bugs and CVE's generally come to us by fairly direct routes, does it make sense to have them in the hot list ?
[15:01] <bdmurray> tgardner-afk: well the same calculation is used for every package and project in Launchpad so I'd say yes
[15:08] <tgardner> bdmurray, well, I can sort bjf's page by column, so it makes it easy to ignore CVEs at least.
[15:08] <bjf> tgardner, apw wanted the cve's on the list
[15:09] <bjf> tgardner, there will be _no_ private bugs on this list as it is a public list
[15:09] <tgardner> bjf, well, I can sort such that I can ignore apw as well
[15:09] <apw> tgardner, yeah mostly as there actually should only be a couple on there as we only have a couple open... i need to clean them up and this will help
[15:10] <tgardner> bjf, so this is gonna get updated regularly ?
[15:11] <bjf> tgardner, every 30 minutes the list is refreshed, the data is refreshed more frequently than that
[15:12] <bjf> tgardner, there is also a mechanism in place to add a specific bug to the list, right now the list is based off of several tags
[15:14] <bjf> tgardner, the tags currently tracked are: "kernel-key", "iso-testing", "pc-cert", "kernel-cve-tracking-bug"
[15:14] <tgardner> bjf, ack
[15:16] <ogasawara> bjf: is there a tag to use to remove a bug from the list?
[15:17] <bjf> ogasawara, no
[15:18] <bjf> ogasawara, if it were tagged and on the list because of "kernel-key" you could remove the tag, but other than that, no
[15:38] <brendand> sconklin - is it still the case that the natty kernel will be respun?
[15:39] <sconklin> as far as we know, yes. HWE is still working with upstream as far as I know. Status has not changed since the last email status update.
[15:40] <apw> sconklin, is there a kernel with the relevant patches reverted?  i have a machine with a display regression in -11 and want to make sure its the same issue
[15:42] <sconklin> apw: talk with vanhoof. I believe that there are only a very limited number of machine configurations which exhibit this and if you have the same problem, you could be helpful for testing
[15:44] <herton> apw: if it is related to i915, I have some built kernels here, with patches reverted: http://people.canonical.com/~herton/lp814325
[15:44] <herton> but built amd64 only
[15:47] <apw> herton, ok i suspect i am i386, but i also am not any of the suspected platforms
[15:47] <vanhoof> apw: some sort of corruption? ... can you correct w/ cycling dpms?
[15:47] <sconklin> apw, herton: My understanding is that for the platform which was reported, the problem still exists upstream, and that if you revert the patch which seems to have introduced it, you lose graphics on all Sandy Bridge platforms. So we're waiting until we understand it before we do anything
[15:48] <apw> nope mine is a black-screen in X, damn
[15:49] <herton> sconklin: if we revert that patch we reintroduce bug 791752
[15:49] <ubot2> Launchpad bug 791752 in linux "Can not toggle Display to External only mode " [Medium,Fix committed] https://launchpad.net/bugs/791752
[15:49] <sconklin> herton: right
[15:50] <vanhoof> which impacts SandyBridge as a whole
[15:51] <apw> but that isn't a regression from the previous version, so thats ok
[15:54]  * apw is unsure it makes sense to hold every other fix in the tree while one decides.  the problem which it fixes is in the kernel out there, and will be the same in the kernel with the revert, so is it not safe to revert and release while we wait for the fixed fix
[15:56] <ppisati> smb: i found another bug related to the clk on omap4, but it didn't fix the i/o problem... crap...
[15:56] <herton> apw: it is a regression, on -proposed kernel
[15:56] <smb> ppisati, Suboptimal... But hey, another bug bites the dust... :)
[15:57] <apw> herton, which the 791752 itself or the bug introduced by its fix
[15:57] <herton> right
[15:58] <apw> herton, that was an OR question
[15:58]  * smb giggles
[15:58] <vanhoof> apw: on my end its just a question of the bigger win, the regression really does seem like a corner case, on a relatively niche subsystem of machines
[15:59] <apw> herton, was 791752 a regression in -proposed, or only the breakage by its fix
[15:59] <vanhoof> however, a regression is a regression, is a regression :)
[15:59] <apw> vanhoof, well thats not what policy says even if you are right
[15:59] <herton> apw: only the breakage by its fix
[15:59] <apw> ok so its broke in -updates and without the fix its broke in -updates, so i am wondering why we are sitting there waiting for upstream to possibly maybe fix it, rather then either reverting or releasing
[16:01] <herton> apw: now I'm confused. 791752 doesn't look a regression, but a bug in natty. the fix for it brought a regression (bug 814325)
[16:01] <ubot2> Launchpad bug 814325 in linux "fuzzy and corrupted display with update in natty-proposed" [High,Incomplete] https://launchpad.net/bugs/814325
[16:01] <ppisati> smb: yeah, if i keep this pace, sooner or later i'll find the right bug :)
[16:02] <smb> ppisati, And the panda won't jump into ones face when trying a simple upgrade... :)
[16:03]  * herton -> lunch
[16:09] <tjaalton> herton: exactly, the -proposed fix is for 791752, which affects every SNB machine using the built-in gfx. and what vanhoof said
[16:09] <tjaalton> ah, gone
[16:13] <apw> tjaalton, right but they are broken already, and not having the fix doesn't change that
[16:13] <vanhoof> apw: also as a side note, the regression introduced exists in 3.1 mainline as well
[16:14] <vanhoof> apw: worth noting, its not natty specific
[16:14] <apw> vanhoof, yes but its not in the kernel in -updates
[16:14] <apw> so you have to have a really good reason to introduce that regression to those users
[16:15] <vanhoof> apw: fair enough, we'll see what more we can turn up today, and I'll update you all again on where we stand
[16:15] <vanhoof> right now its not clear if its limited to the T510 + hybrid graphics + intel as default gpu OR arrandale + hybrid graphics + intel as the default gpu
[16:16] <apw> so we have no idea as to the size of the regression, thats not a positive
[16:16] <vanhoof> well we have a decent sizing, however this configuration isn't exactly prevalent, so a bit tricky to track down testers
[16:17] <vanhoof> I can tell you everything else is not exposed ;)
[16:17] <vanhoof> give us the day to see what more can be turned up, and we can take it from there
[16:25] <jjohansen> so my 7 year rode his bike into a tree on the morning running, its been an interesting morning so far
[16:27] <smb> jjohansen, hopefully not too badly ran into it. Kid and tree surviving?
[16:28] <jjohansen> smb: yeah, the tree got the better of him, though I must say from the moaning he is still doing he thinks he is dying
[16:29] <jjohansen> really just a few good scraps, nothing quite as good as his face plant though
[16:29] <apw> jjohansen, heh, as long as he doesn't start throwing up
[16:30] <jjohansen> apw: yeah, that would make things worse
[16:30] <smb> jjohansen, I guess it can feel rough. Though its sometimes hard to say where the pain stops and making use of the situation starts...
[16:31] <jjohansen> oh I am pretty sure he is into the making use of the situation
[16:31] <jjohansen> his moans got quite a bit loader when mommy came in :)
[16:32] <smb> jjohansen, Help, this wound needs a substantial amount of sweets to mend. :)
[16:32] <jjohansen> hehe, yeah
[16:33] <apw> jjohansen, heh typical, tells you he is fine then
[16:34] <apw> jjohansen, you need some "well if you are sick we can't have <favourite dinner>, it'll have to be gruel"
[16:35] <jjohansen> apw: sadly he already know what dinner plans where for the night, but perhaps we can use dessert as the lever :)
[16:53]  * smb -> gone
[17:00] <kobrien> Evenin'. I'm trying to boot kernel version 3.0 under Ubuntu 11.04 amd64. After I select it in grub, I'm presented with a purple splash which never goes away. I never get further than this. Any ideas on how to fix?
[17:02] <apw> kobrien, you'd want to turn of graphical splash and see if if you can get some diagnositics
[17:04] <apw> kobrien, which would be editing the command line in grub2, change the =$linux_gfx_mode for =text and then remove quiet splash and replace that with debug
[17:04] <apw> kobrien, oh and the vt.handoff=xxx bit as well, get rid of that
[17:08] <kobrien> apw: thanks, I'll try that now
[17:23] <apw> ogasawara, ok i've just pushed a major update to the devel config summary tools for use for next UDS
[17:24] <ogasawara> apw: awesome, was actually just going to start shoving bits in a wiki for some of the P specs
[17:24] <apw> ogasawara, we need some work on the OVERRIDES which i'll try and do a bit of tomorrow
[17:25] <apw> ogasawara, but we only shove it in raw anyhow.  once you have the config blueprint and spec i can shove in an early one from your tree
[17:25] <ogasawara> apw: cool
[17:26] <ogasawara> apw: I'm also not sure how much more of the module config review I'll be able to knock out between now and kernel freeze, so I'll likely carry that over to P as well
[17:26] <apw> ogasawara, well, i am inclined to think of things out of policy as a bug, so not really subject to the freeze
[17:27] <ogasawara> apw: most are usually powerpc changes, so as long as it builds I'm not too worried.
[17:27] <apw> ogasawara, even more so as they are only a ports port
[17:28] <ogasawara> apw: I was also going to ask if we should rip out the ppc64 bits
[17:28] <ogasawara> apw: as I recall that was a one time thing for natty?
[17:28] <ogasawara> apw: or is there value for us to carry that along
[17:29] <apw> ogasawara, there is a possibility we may need then i suspect, and they are easier keep in and maintain as we go through the rebases
[17:29] <apw> we should definatly drop them in 12.04 if we've not used them by then
[17:29] <ogasawara> apw: ack, definitely no pain in carrying them, I hardly notice most of the time
[17:44]  * tgardner --> lunch
[17:48] <ogasawara> apw: https://wiki.ubuntu.com/KernelTeam/Specs/KernelPConfigReview - empty spec template for now, but feel free to throw any bits there
[17:48] <apw> ogasawara, will do
[18:26] <apw> ogasawara, initial update in the spec
[18:26] <ogasawara> apw: ack, thanks
[18:26] <apw> i'll try and remember to update it regularly going forward
[19:04] <herton> tgardner: are you still looking at  the chromium lockup on lucid? I'm curious if with environ patch not reverted, but with the oops fix applied we still get a hang, and if yes, if it's on kernel (sysrq-w could help). Only place I can see it could may be deadlock because of that patch, would be getting the cred_guard_mutex, or task_lock inside get_task_mm (although get_task_mm was being used before in environ_read)
[19:06] <tgardner> herton, I was able to get both symptoms, the lockup as well as the oops. I could try just the oops fix just to be sure.
[19:07] <herton> I think would be good to check, just in case
[19:32] <apw> tgardner, if you could let me know any testing results there as i have looking at why thats bust tommorrow on my list
[19:32] <tgardner> apw, k
[19:33] <herton> tgardner, apw: the oops fix (commit 76597cd upstream) should go into natty master-next as well. hardy doesn't need it, checking here the backport doesn't patch m_start with ERR_PTR
[19:37] <herton> do you think I should see with sconklin and respin the lucid/maverick kernels, or can we wait? (I would respin maverick with the oops fix, and lucid with the revert + oops fix)
[19:37] <tgardner> herton, lemme verify lucid first
[19:38] <tgardner> herton, oops fix applied to natty
[19:39] <herton> ack
[19:49]  * jjohansen -> lunch
[20:06]  * ogasawara wonders who won the race to push to the repo, me or tgardner 
[20:06]  * ogasawara guesses I won since I had no conflicts
[20:07] <tgardner> ogasawara, I'm thinking you did too.
[20:07] <tgardner> ogasawara, but I also pushed an updateconfigs commit afterwards
[20:08] <ogasawara> damn, I thought I ran an  updateconfigs after rebasing
[20:09]  * kamal is cheering at the finish line \o/ in celebration of mjg59's backlight patch finally landing!
[20:11] <kamal> tgardner, ogasawara: thanks!    mjg59: super-duper-ultra-bright-thanks!
[20:34] <apw> tgardner, was it you who was complaining about the two handed alt-tab alt-down thing ?
[20:34] <tgardner> ogasawara, seems like you just did 3.02, and now greg has already released 3.0.3
[20:34] <ogasawara> sheesh, already?
[20:34]  * ogasawara rebases
[20:34] <tgardner> apw: not me. that would imply a sophisticated use of the keyboard.
[20:35] <apw> must have been jjohansen :)
[20:35] <jjohansen> yeah I hate that
[20:36] <jjohansen> I do complain about it almost daily lately
[20:36] <jjohansen> what I really hate is unity not letting me turn it off, even when resolving conflicts in ccsm
[20:37] <apw> jjohansen, well ccsm does have a keybinding for it, and moving it to alt-` seems to be _much_ less annouing
[20:38] <jjohansen> apw: hrmm I hadn't thought about that
[20:38] <jjohansen> now if I could only get to ccsm, unity layering issues strick again
[20:39] <apw> jjohansen, i think thats the osx binding :/
[20:40] <jjohansen> s/strick/strikes/
[20:40] <jjohansen> apw: how am I not surprised
[20:41] <jjohansen> apw: that is much better thankyou
[20:41] <apw> jjohansen, yeah at least one can single digit it
[20:42] <apw> though this thing shows empty spaces for iconified windows ... sigh
[20:43] <jjohansen> ewww
[20:50] <apw> jjohansen, i have filed like 8 bugs in two days :(
[20:51] <jjohansen> apw: yeah I keep finding them because you beat me to filing them
[21:00] <tgardner> herton, I've backed out the revert for CVE-2011-1020 on Lucid. It appears that that the oops fix is the right patch.
[21:00] <ubot2> tgardner: The proc filesystem implementation in the Linux kernel 2.6.37 and earlier does not restrict access to the /proc directory tree of a process after this process performs an exec of a setuid program, which allows local users to obtain sensitive information or cause a denial of service via open, lseek, read, and write system calls. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1020)
[21:02] <herton> tgardner: oh, cool. So I think we can go forward then and respin just with the fix, and hardy shouldn't be affected and can be released
[21:02] <tgardner> herton, correct
[21:03] <herton> ok, I'll "reopen" hardy tracking bug etc.
[21:07]  * tgardner -> EOD
[21:15] <apw> herton, thats good news, the revert not being required, just the extra fix ... 
[21:16] <herton> yep
[21:24] <jjohansen> rebooting