=== bjf is now known as bjf-afk
[04:57] <superdug> why am I so impressed with linux on a processor that can run linux?
[09:40] <ogra> lool, so about imx-libs and xserver-xorg-video-imx and theior linking .... xserver-xorg-video-imx needs to link against mxcfb.h/ipu.h as well (looking for it on include/linux), do you know if the policy allows it that i would copy both headers during package build into imx-libs so it would ship these two in /usr/include/linux and the xserver wouldnt have to be hacked up for isung linux-headers ?
[09:42] <ogra> s/isung/using/
[09:48] <lool> ogra: I think this would create another libdrm and I dont think we want that; it sounds like these headers should be in the kernel tree instead?
[09:49] <lool> ogra: In which case we'd have to build-dep on linux-headers-imx51 instead of linux-libc-dev because of the mx51 stuff not being upstream
[09:49] <ogra> lool, yes, it is in the kernel tree atm
[09:50] <ogra> and imx-libs dep on linux-headers-imx51 and build fine with it
[09:50] <ogra> the xserver has no configure option to add additional includes though
[09:50] <ogra> and hasnt /usr/src/linux* in its default include path
[09:51] <ogra> given that apps that build against imx-libs always need to have the headers from linux-headers it would be more easy to have imx-libs ship them in the default include path instead of having to hack up each app that uses them
[09:53] <lool> Oh right
[09:53] <lool> ogra: I disagree that we want imx-libs to ship them
[09:53] <lool> These headers are in the kernel source and should remain there
[09:54] <lool> ogra: But we might have to move them to the expected place
[09:54] <ogra> ok, then i'll need to hack up the xserver autofoo
[09:54] <lool> Or add -I flags when using imx-libs
[09:54] <lool> ogra: Well you could also copy them in linux-fsl-imx51
[09:54] <lool> But you'd have to be really careful in only adding new headers
[09:55] <ogra> hmm, would linking not work ?
[09:55] <lool> Perhaps it's best to add an -I flag for now; until the headers make it to linux-libc-dev
[09:55] <lool> To avoid any clash
[09:55] <lool> ogra: Well linking or copying, yeah, but the issue is that if the upstream kernel or another vendor or another kernel tree (e.g. lange) wants to provide the same filenames, we're in trouble
[09:55] <lool> While adding the -I is safe
[09:56] <ogra> i could make a link from /usr/include/linux/mxcfb.h to /usr/src/linux-headers/*.../mxcfb.h in the libimx-dev package
[09:56] <ogra> i think currently its highly inlikely that we get the same files anywhere
[09:57] <ogra> ipu.h and mxcfb.h are pretty exclusively only on the imx51 arch
[09:57] <lool> I'm not too hot on it
[09:58] <ogra> well, ok, i'll hack up the xserver for now to look in the linux-headers dir too
[09:58] <ogra> but that makes two packages that have to stay in sync
[09:59] <lool> ogra: Actually one thing which strikes me is that the headers are under an ABI path
[09:59] <ogra> right
[09:59] <ogra> which is pointless unless the patches get actually updated
[10:00] <ogra> even if we have an ABI bump they usually stay untouched
[10:00] <lool> ogra: The core of the issue is that we currently rely on linux-libc-dev/armel to build everything on armel
[10:00] <lool> While we truly have multiple kernel ABIs
[10:00] <lool> One per subarch
[10:00] <ogra> yeah
[10:00] <ogra> plus vendor patches
[10:00] <lool> We cant have multiple linux-libc-dev
[10:00] <lool> I think using the upstream kernel ABI/API is best for us by defalut
[10:01] <lool> But we could use a more specific ABI/API for packages which need it, like here
[10:01] <ogra> right, but that wont work for such device specific headers
[10:01] <lool> Still, this should be offered by the linux-fsl-imx51 packages
[10:01] <ogra> well, i fear any changes in the packaging of linux-fsl-imx51
[10:02] <lool> So perhaps we should have a linux-libc-dev-fsl-imx51 which would install in /usr/include/fsl-imx51/* (/linux etc.)
[10:02] <ogra> especially this late in the cycle and with the experience i made this round
[10:02] <lool> (I'm speaking long term)
[10:02] <lool> I dont think that's doable for karmic
[10:02] <ogra> yes, i understand
[10:02] <ogra> right
[10:02] <lool> (But I want to get the logic right as to solve this properly next cycle)
[10:02] <ogra> yup
[10:03] <lool> ogra: So either imx51 gets merged upstream in the kernel and we use linux-libc-dev (unlikely before long), or we come up with such a hack
[10:03] <ogra> well, atm there are in max 5 devices
[10:03] <lool> ogra: I'd rather use a new binary package for this since the linux-headers packages already have use cases
[10:03] <ogra> so that package would be fairly empty
[10:03] <ogra> we only use three of the 5 atm
[10:03] <lool> ogra: I think it would be a full replacement for libc-dev
[10:04] <lool> ogra: In theory, the ABI could be difference in some places than the upstream one
[10:04] <ogra> though sahara was enabled in the config, i will probably switch it back on in imx-libs
[10:04] <lool> ogra: e.g. they could add some fb ABI calls
[10:04] <lool> (ioctls)
[10:04] <ogra> ah
[10:04] <ogra> yep, i understand
[10:04] <lool> ogra: Is this approach fine with you for karmic+1?
[10:04]  * ogra thought of it as addon package
[10:04] <ogra> yup
[10:05] <lool> ogra: Ok; now looking at what we can do in karmic
[10:05] <ogra> bloats the archive with duplkicates though ... but surely the best path to take
[10:05] <lool> ogra: So I dont think we want to change kernel at this point
[10:05] <ogra> well, both packages arent even in the archive
[10:05] <ogra> and unlikely to enter
[10:06] <ogra> so let me add hacks to the packages for now
[10:06] <lool> ogra: What we could do is have imx-libs build-dep on linux-headers-fsl-imx51 and copy the latest headers from there into imx-libs
[10:06] <lool> or use them directly there
[10:06] <ogra> thats what i asked initially for :)
[10:06] <ogra> it alreayd build-deps on the headers
[10:06] <lool> Well I prefer planning the clean fix first, then looking at immediate workarounds
[10:06] <lool> ogra: Do you that in imx-libs or xorg-imx51 or both?
[10:07] <ogra> and libimx-dev can easily copy them into /usr
[10:07] <ogra> i would do it in libimx-dev and make it ship them in /usr/include/linux
[10:07] <ogra> then have the xserver just b-d on libimx-dev
[10:07] <lool> Well dont you think we can implement the /usr/include/fsl-imx51 part directly?
[10:08] <ogra> that would mean to hack up the xserver package to look in there
[10:08] <lool> Which will be needed for the long term plan anyway
[10:08] <ogra> ok
[10:08] <ogra> so i'll do both
[10:08] <ogra> copy the headers and hack up xserver
[10:09] <lool> Cool
[10:09] <ogra> thanks :)
[10:09] <lool> ogra: Do you want to file the bug for the lucid stuff?
[10:09] <ogra> can do
[10:09] <lool> Ok
[10:09] <lool> ogra: I just had this bug again that I did a reboot on babbage 2.0 and it shutdown instead; do you know if we have a bug for that or shall I file one?
[10:09] <ogra> we dont
[10:10] <ogra> and i didnt see such behavior yet
[10:10] <lool> ogra: So reboot works for you?
[10:10] <ogra> yep
[10:10] <ogra> but thats 2.5
[10:10] <JamieBennett> lool: I had the exact same thing yesterday
[10:10] <lool> Right
[10:10] <ogra> you have other weird issues on your 2.0
[10:10] <lool> JamieBennett: On 2.0 and/or 2.5?
[10:10] <JamieBennett> 2.0
[10:10]  * ogra remembers the xterm issue 
[10:10] <lool> JamieBennett: did you try on 2.5?
[10:11] <JamieBennett> I don't have the lead yet (going to a specialist shop this morning to get it.
[10:11] <JamieBennett> )
[10:13] <lool> b444386
[10:13] <lool> #444386
[10:14] <ogra> we should try to make that bug appear on 2.5 too, then it would at least shut off at all :P
[10:15] <lool> Eh
=== Stskeepz is now known as Stskeeps
[10:15] <lool> I thought the same, that it was really ironic that one shuts off too easily while the other cant
[10:15] <ogra> yeah :)
[10:15] <JamieBennett> lool: have you seen video issues with 2.0 on the desktop? I have about 20 pixels missing from the top left hand corner running horizontal.
[10:15] <ogra> could that be caused by the toolchain issue ?
[10:15] <lool> ogra: make sure you include karmic+1 or something in the headers bug
[10:16] <ogra> will do
[10:16] <lool> ogra: No
[10:16] <lool> The toolchain issues are only problematic when doing stack unwinding in C++ stuff, so not in the kernel
[10:16] <ogra> ok
[10:16] <lool> JamieBennett: I did file a couple of video bugs on b2.0
[10:16]  * JamieBennett goes to look
[10:16] <lool> JamieBennett: 2.5 is more stable so nobody bothers with the 2.0 specific bugs
[10:17] <JamieBennett> ok
[10:17] <ogra> JamieBennett, does it go away if you definate a video= option on the cmdline
[10:17] <lool> JamieBennett: https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51 and ~ubuntu-armel bugs are good places to check for them
[10:17]  * ogra thinks he has seen that before 
[10:17] <lool> https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51/+bug/430969
[10:17] <ubot4> Launchpad bug 430969 in linux-fsl-imx51 "Display unstable when running xterm" [Low,New]
[10:18] <ogra> JamieBennett, make sure to have the laters redboot-tools (0.7) you can easily edit the cmdline with redboot-cmdline from the running system
[10:18] <JamieBennett> ogra: haven't tried, just strange that its 1px x 20px top left and nothing else
[10:18] <lool> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/358956
[10:18] <ubot4> Launchpad bug 358956 in linux-fsl-imx51 "armel Babbage iMX51 line truncation and addition on VGA output" [Undecided,Incomplete]
[10:18] <ogra> i think it goes away if the driver gets a video= option
[10:18] <JamieBennett> ok
[10:19] <lool> JamieBennett: Can you reopen that last bug if it matches?
[10:19] <JamieBennett> lool: Will do.
[10:21] <ogra> JamieBennett, try with video=mxcfb:1024x768-32@60
[10:21] <JamieBennett> ogra: OK
[10:21]  * ogra hopes he has that right from the top of his head
=== doko__ is now known as doko
[10:56] <lool> JamieBennett: also, the first bug (xterm makes display unstable) wasn't confirmed by anyone else; it's low prio but your confirmation would be nice
[10:59] <JamieBennett> lool: I'll look into it now
[11:06] <ogra> lool, the truncation bug is different though ... its just a small square above thats rendered black directly over the applications menu
[11:06] <ogra> s/above/at the top/
[11:26] <lool> JamieBennett: Or perhaps file a new bug, use your judgement
[11:27] <lool> It was painful to setup this local debmirror, but it feels so snappy when I use it that I really don't regret it!
[11:27] <lool> I think I'll enjoy deboostrap as well
[12:09] <JamieBennett> Just caught your Bug #430969 on camera lool :)
[12:09] <ubot4> Launchpad bug 430969 in linux-fsl-imx51 "Display unstable when running xterm" [Low,New] https://launchpad.net/bugs/430969
[12:36] <lool> k
[12:38] <ogra> ogra@babbage2:~/devel/kernel/linux-fsl-imx51-2.6.31$ grep -r "pin config changed" *
[12:38] <ogra> ogra@babbage2:~/devel/kernel/linux-fsl-imx51-2.6.31$
[12:38]  * ogra scratches his head
[12:38] <ogra> i wonder where "iomux_config_mux: Warning: iomux pin config changed" might come from on boot
[12:44] <ogra> its the very first bootmessage the babbage spits out
[12:55] <ogra> lool, the regulator errors on bug 438680 look suspiciously like a porting error
[12:55] <ubot4> Launchpad bug 438680 in linux-fsl-imx51 "please quieten down bootmessages" [Low,Triaged] https://launchpad.net/bugs/438680
[12:55] <ogra> i wonder if i should open a new bug for it
[12:55] <ogra> ogra@babbage2:~/devel/kernel/linux-fsl-imx51-2.6.31$ grep -r "with no identifier" drivers/*
[12:55] <ogra> drivers/regulator/core.c:		printk(KERN_ERR "regulator: get() with no identifier\n");
[13:02] <ogra> lool, i think bug 439282 should be high instead of medium
[13:03] <ubot4> Launchpad bug 439282 in linux-fsl-imx51 "does not power down the system properly" [Medium,Confirmed] https://launchpad.net/bugs/439282
[13:03] <ogra> what do you think ?
=== JamieBennett1 is now known as JamieBennett
[13:21] <lool> ogra: I dont really care beween the two as long as it's fixed   ;-)
[13:21] <lool> ogra: I dont think it's a big deal for a developer board
[13:21] <lool> I find it a pain that sound doesn't work because I can imagine people using that for development
[13:22] <lool> And ethernet not working with NM is also a pain for a desktop use case, since ethernet is in the soc it hits all boards
[13:22] <lool> But wiring of the PMU is likely to differ per board (as it does on lange for instance) so I'm not too concerned that we use power when off; even if it's a bug we should try to fix for release
[13:23] <lool> ogra: Not sure what you want me to do about the regulator stuff?
[13:25] <ogra> nothing, i want to know if you would consider it better being a separate bug
[13:26] <ogra> i have no idea what it implies if the code isnt properly integrated with the core kernel regulator code
[13:26] <ogra> the messages seem to come from that
[13:26] <lool> Oh I dont know either
[13:26] <lool> probably best to check with kernle folks
[13:26] <ogra> yeah
[13:27] <ogra> waiting for brad or some other ARM person to get up though
[13:36] <NCommander> ogra, I talked w/ cjwatson. The easiest way to get partman-uboot tested is in an alternative CD environment. Probably best if I spend a few cycles working on this with your assistance (as we want alternates anyway ...)
[13:37] <NCommander> er
[13:37] <NCommander> lool,
[13:37] <ogra> NCommander, but d-i should come up, shouldnt it ?
[13:37] <NCommander> ogra, it doesn't get as far as partman
[13:38] <ogra> whats the stopper ?
[13:38] <lool> NCommander: Well they are mostly working already
[13:38] <NCommander> lool, they are?
[13:38] <lool> NCommander: For me alternates worked
[13:38] <lool> I think I tested netboot
[13:39] <lool> I got the console fonts bug and then the symlink issue IIRC
[13:39] <ogra> lool, right, cd detection fails on the normal alternates
[13:39] <NCommander> Oh, netboot works, but there isn't a way to easily preseed on netboot
[13:40] <ogra> netinst should work if you have a working NIC
[13:40]  * NCommander notes that he should probably write a boot.scr for netboot soonish
[13:40] <lool> NCommander: Oh and I had to do the cdrom-detect/try-usb=y thing
[13:40] <lool> NCommander: There isnt??  I thought there was a preseed file on the CD and it's just a kernel cmdline parameter
[13:41] <lool> Oh you mean in the image itself; I'm sure we can add that
[13:41] <NCommander> lool, ah :-)
[13:41] <lool> NCommander: files are in initrd, so it's probably trivial to add one and add a cmdline arg
[13:41] <NCommander> lool, yeah, I was going to make that change once I sit down and hit d-cd with a shovel
[13:44] <lool> it's debian-installer rather
=== jldugger is now known as pwnguin