[00:07] <Neko> it copies the asm stuff right but it seems any platform with a plat- and a mach- doesnt copyor link the plat-blah/include stuff into place
[00:47] <Neko> hmn doesn't do it for omap either
[00:47] <Neko> kernel bugggggg
[00:47] <persia> Indeed.  This may explain a number of fail-to-build module reports on armel installs.
[00:50] <Neko> how would you work out what the parent plat-???? directory is to the mach you're building for though, to fetch the right headers
[00:52] <persia> Well, linux-image-${target} could depend on linux-headers-${target}, and one could encode the requirements in the specific dependencies for linux-headers-${target} with a lookup table in the package source.  That said, doing it without the packaging sugar would be lots harder.
[00:52] <Neko> that assumes the target is directly related to the machine
[00:53] <persia> ah, but ${target} might support several machines?
[00:53] <Neko> all scripts/headers.sh knows is arch, srctree, and what kind of header build it's doing (check or install)
[00:53] <Neko> umm no
[00:53] <Neko> but what if the target is, like in Ubuntu -generic or -server
[00:54] <Neko> right now there's fsl-imx51 but what about fsl-imx53.. or does it get changed to fsl-mx5?
[00:54] <Neko> that still doesn't give you a direct indication of the need for the includes from plat-mxc
[00:54] <persia> They're just strings, and the semantic meaning is weak.
[00:55] <Neko> isn't what what I am saying? :D
[00:55] <Neko> I don't want the fix to be a case block in a bash script
[00:55] <persia> Sure, but in practice, we assign semantics.  For example, the -omap kernels only work on omap3
[00:55] <Neko> what about -omap4
[00:55] <persia> makefile, but yeah, there ought be a better way :)
[00:55] <Neko> seperate kernel?
[00:55] <persia> Currently, yes.
[00:56] <persia> If someone is able to make a kernel that boots both cleanly with full support, I'd expect that there would be available headers will the same level of support.
[00:56] <Neko> currently make headers_install calls scripts/headers.sh arm arm install
[00:56] <persia> So if someone created -generic for armel, I'd expect that to work for nearly every device (this is probably some years off)
[00:56] <Neko> or something similar
[00:57] <Neko> makefile doesn't do much, in the end there's a perl script too
[00:57] <persia> Most of the packaging sugar is managed by debian/rules, which is traditionally a makefile, which is why I mention make.
[00:57] <Neko> loops over files and unifdefs them
[00:58] <Neko> debian headers rules from kernel-package makes some clever changes but it still does not handle it
[00:58] <Neko> IMO it's a kernel bug not a packaging bug
[00:58] <persia> Indeed: that's the bug.
[00:58] <Neko> it's not a packaging bug
[00:58] <Neko> make headers_install needs to do this as well or the headers are useless
[00:58] <persia> I agree it's a kernel bug.  It could be masked with a packaging-class fix, but fixing it in the kernel would be vastly superior
[00:58] <Neko> mach/memory.h comes from plat- on 10 subarches of arm
[00:58] <Neko> you can't build libc without that file
[00:59] <Neko> there are google pages for hacks to fix bionic compilation with broken headers like that
[04:12] <rsalveti> apw: patches sent to our kernel team and linux-omap
[04:12] <rsalveti> apw: finally working at normal beagle and xM
[04:13] <rsalveti> spent a lot more time building and testing than actually coding
[04:13] <rsalveti> recreate the rootfs, etc
[04:13] <rsalveti> but should be fine now, I'm able to see the console and X11
[04:22] <ka6sox> rsalveti, what should I expect the rndis ethernet device to show up as in maverick?
[04:54] <sanket> hii
[05:45] <bagge> hi :) I'm about to install ubuntu-arm on my phone, but I'm wondering about something... I can only get packages that are made for ARM right?
[06:00] <Neko> bagge, if you have to ask that I'd say you're not ready to install ubuntu on a phone :D
[06:13] <bagge> Neko: I'll have to crash my phone to learn ;)
[06:18] <ka6sox> bagge which phone?
[06:22] <bagge> ka6sox xperia x10 mini pro (hehe)
[06:30] <ka6sox> Good Luck...I have no experience with that.
[12:44] <ogra> hrw, console-setup (1.57ubuntu5) was just uploaded, that should solve all hangs of the keyboard stuff on upgrade/dist-upgrade and install
[12:50] <hrw> cool
[12:57] <apw_> rsalveti: yo ... saw your patches, have some kernels building with them applied, will you be about in about half hour to test them?
[12:57] <rsalveti> apw: yup, lunch is in one hour :-)
[12:57] <rsalveti> apw_: ^
[13:01] <apw_> rsalveti: ok cool
[13:01] <apw_> will get it to you before then :)
[13:01] <rsalveti> :-)
[13:05]  * ogra wornders if you can actually make sure that with all these food things around these kernel patches since yesterday you dont leave breadcrumbs and fatty finger prints on the package :)
[13:06] <ogra> every time i see you guys talking about these patches one of you is busy with food stuff :)
[13:09] <rsalveti> :P
[13:10] <apw_> ogra: the kernel always has a bunch of fingerprints all over it :)
[13:10] <ogra> heh
[13:27] <apw> rsalveti, http://people.canonical.com/~apw/misc/arm/linux-image-2.6.38-1-versatile_2.6.38-1.28~pre1_armel.deb
[13:27] <apw> if you could do the honours
[13:27] <rsalveti> downloading :-)
[13:33] <rsalveti> apw: the name versatile is right?
[13:33] <apw> rsalveti, no i've pushed the wrong one cause i am stupid
[13:33] <rsalveti> ok :-)
[13:34] <apw> be about 5 mins ... bottom
[13:34] <rsalveti> np
[13:36] <apw> rsalveti, http://people.canonical.com/~apw/misc/arm/linux-image-2.6.38-1-omap_2.6.38-1.28~pre1_armel.deb
[13:36] <apw> silly apw
[13:47] <rsalveti> ok, installing
[13:59] <apw> rsalveti, how they looking?
[14:00] <rsalveti> apw: and we have a winner, using normal desktop :-)
[14:02] <rsalveti> apw: and tim already applied at master-next
[14:02] <apw> rsalveti, heh yeah he and i are duplicating work today :)
[14:02] <rsalveti> :-)
[14:02] <rsalveti> ok, sounds good timing for lunch
[14:03] <apw> rsalveti, yep, you are done, thanks muchly
[14:03] <rsalveti> apw: ping me if you want any test or have any update on the omap side
[14:03] <apw> rsalveti, will do indeed, i expect there will be a final final a2 kernel on monday to test
[14:03] <rsalveti> apw: cool
[14:03] <rsalveti> and it seems that it'll work fine, at least it didn't explode at my face yet
[14:04] <rsalveti> apw: do you want the patch to remove the WARN_ONCE from the erratum?
[14:04] <rsalveti> we could just use a simple printk
[14:04] <rsalveti> I have it here if you think it's worthy
[14:05] <rsalveti> apw: http://rsalveti.net/tmp/0001-OMAP3630-PM-don-t-warn-the-user-with-a-trace-in-case.patch
[14:05] <apw> rsalveti, i think it is worth while, send out to the kernel-team list, i recon
[14:06] <rsalveti> apw: ok, will do
[16:52] <apw> ogra, i am not sure what you mean about srus being pushed out by securty.  we h
[16:52] <apw> we haven't done that for the last two months at least
[17:06] <ogra> apw, well it happens occasionally i dont think its currently the issue
[17:06] <apw> ogra, ok so what is the issue
[17:06] <ogra> none, its just that not all SRUs have been tested yet
[17:07] <ogra>  * Maverick kernel SRU testing is still in progress
[17:07] <ogra> thats all i said
 and we wlao often clash with security uploads
 which force the SRU out of -updates
[17:08] <apw> well you said that which prompted my question
[17:08] <apw> i think everyone would have taken that as the reason the testing was not done from the context
[17:08] <ogra> hmm, i didnt mean it like that
[17:08] <ogra> though its often enough the cause
[17:08] <ogra> not thins time though
[17:09] <apw> well its going to be rare now as most security is going in the hopper with the rest of the updates
[17:09] <apw> as long as we don't have a process issue between us i am happy
[17:09] <ogra> i think we dont
[17:09] <ogra> but that would be a question for GrueMaster
[17:10] <ogra> since he is the one who suffered from it in the past
[17:11] <ogra> i really didnt mean to blame anyone i just tried to quieten marjo :P
[17:11] <ogra> sorry if it came across that way
[17:11] <apw> ogra, no harm no foul, just wanted to make sure we'd not missed something, ta
[17:11] <ogra> (the phrase above is always in my report since it is nearly always true that there are some SRUs to test)
[17:12] <ogra> *nobody* ever asked about it :P
[17:12] <apw> ogra, yep and we are making more now-a-days so it'll be even more true
[17:53]  * GrueMaster hears his name being mentioned.
[17:54] <GrueMaster> what kernel in maverick still needs testing?
[17:54] <GrueMaster> ogra: apw ^^^
[17:58] <rsalveti> ogra: both images are using the new x-loader package, so we should be ok to remove the x-loader-omap4 one
[18:43] <ogra> rsalveti, awesome
[18:44] <ogra> GrueMaster, dunno, i just saw several uploads this week and assumed some would still need testing
[18:46] <GrueMaster> ogra: I haven't seen anything for omap4.  Until Monday, I can't test omap3 stuff easily, unless I build a stripped down image for my beagle.  Too painful otherwise.
[18:47] <ogra> GrueMaster, right, i was referring to omap3 rather
[18:49] <GrueMaster> Well, unless there is a specific patch for omap3 in the main kernel, I'm not too worried.  Security updates usually get pushed through without my help.  It is specific omap3 bug fixes I usually have issues getting tested on time.