=== hrw|gone is now known as hrw
[07:53] <hrw> morning
[09:00] <lag> sebjan: Ping
=== kmargar is now known as markos_
[09:36] <cooloney> lag: sebjan is away on vacation i think.
[11:04] <lag> cooloney: When do we get TIs patches
[11:08] <cooloney> lag: i didn't get it yet
[11:08] <cooloney> lag: i will ping them today
[11:11] <lag> I'm happy to do it
[11:11] <lag> How do they normally send them to you?
[11:12] <cooloney> normally, sebjan will prepare the branch in their integration tree
[11:12] <cooloney> and ask me to pull
[11:12] <cooloney> but i think this time ndec will help to do that
=== zyga_ is now known as zygq
=== zygq is now known as zyga
[11:15] <lag> cooloney: Let me know if you want me to take care of it
[11:21] <cooloney> lag: no problem, man. just send out an email to ndec and added you in
[11:22] <lag> I received it
[14:18] <rsalveti> lag: did you get the new TI release?
[14:18] <lag> rsalveti: Nothing yet
[14:18] <lag> Perhaps ndec will know more?
[14:19] <ndec> lag: hi. sorry I am not too responsive these days...
[14:19] <ndec> lag: many people on vacations, too many things to cover ;-)
[14:20] <lag> ndec: Do you think they will be done sometime this week?
[14:21] <ndec> lag: i have seen cooloney email. i received the new BSP based on .35, but I haven't had time to look into it.
[14:21] <lag> ndec: We have a few users (and developers) who are struggling with a few things we're waiting for bugs for
[14:21] <lag> bug fixes*
[14:21] <ndec> lag: this branch: http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=shortlog;h=refs/heads/L24.9 has the latest BSP, but it does not support panda yet, only blaze.
[14:22] <lag> Panda is the key one for us
[14:22] <ndec> lag: i am planning to have a branch with this .35 OMAP4 BSP + ubuntu patches + panda sometimes this week.
[14:22] <lag> ndec: Thanks
[14:22] <lag> rsalveti: There's your answer :)
[14:23] <ndec> rsalveti: hi... does it answer your question?
[14:25] <rsalveti> lag: ndec: yep, thanks :-)
[14:55] <dyfet> I found a simple armel ftbfs much earlier this morning...libgd2
[14:57] <asac> dyfet: have a fix? ;)(
[14:57] <asac> or you mean "found a fix" ;)
[14:57] <dyfet> yes
[14:57] <asac> dyfet: if you want a sponsor at best file a bug attach the debdiff and let me or ogra know
[14:58] <dyfet> I have to go back to the doctor this morning, but it was a quick one to fix, so i am going to do that shortly
[15:02] <ogra> libgd2 ? doesnt that need a fix in libc ?
[15:02] <ogra> iirc it fails on the wrong dh_shlibs setting currently
[15:24] <asac> ogra: dunno. didnt look at the build failure ... ;)
[15:24] <ogra> i think it was the one
[15:24]  * asac goes looking
[15:24] <ogra> it looked like a bug in dh_shlibs
[15:24] <asac> yeah feels like it
[15:24] <ogra> but it turned out that glibc provides broken info to dh_shlibs
[15:25] <asac> yes, if libc still mentions not existing package then thats the case
[15:25] <asac> but maybe dyfet managed to not use that part at all ;)
[15:25] <ogra> so its effectively a glibc bug, only if we cant fix it there in time we should add a hack, else just wait
[15:25] <asac> (which wouldnt be that bad either ... of course libc needs to be fixed)
[15:25] <ogra> right, if he has a better fix thats indeed better :)
[15:25] <asac> right
[15:26] <asac> ogra: and he should open a bug for the libc issue if its not reported and make it release critical so doko actually fixes it ;)
[15:26] <ogra> i think its open upstream or in debian somewhere, i dont have the bug #'s here atm
[15:27] <ogra> we added the hack in karmic already (same issue back then)
[15:28] <ogra> bah, sigh, i just bought a new car ... only thing it needs are new tires .... and i just looked up the tire price for that size of tires ... seems thats additional 10% of the price of the car ... sigh
[15:39] <markos_> ogra: are you referring to the ld-linux3-dev override hack in d-shlibmove for libgd2?
[15:39] <ogra> markos_, xactly
[15:39] <markos_> if so, I found more packages with exactly the same problem -well, the debian ones, but I guess it might still be valid for ubuntu
[15:40] <markos_> namely ghostscript, graphviz and jbig2dec (plus libgd2 ofc)
=== asac_ is now known as asac
[15:40] <ogra> yeah
[15:40] <lag> mpoirier: Works for me
[15:41] <ogra> we had probs with all these back in karmic and changing the ld-linux3-dev entry fixed all of them
[15:41] <markos_> fixed it in glibc?
[15:41] <mpoirier> lag: fantascit - I'll wait 'till GrueMaster has a chance to test it too.
[15:41] <ogra> no, in dh-slibs
[15:42] <markos_> oh, right, but the maintainer in debian opposes the change
[15:42] <ogra> which is right
[15:42] <GrueMaster_> mpoirier: I'll try to get to it sometime today.  I'm in the middle of a Lucid>Maverick upgrade test atm.
[15:43] <mpoirier> GrueMaster: that would be great.
[15:43] <markos_> well, I used a simple "fix" in the same packages, I just added an override in each package, though the best solution would be ofc to fix glibc
[15:43] <mpoirier> GrueMaster:  I'll push the change in when you confirm it works for your.
[15:46] <amitk> anybody know how to "resume" booting after one has been dropped to the initramfs shell?
[15:52] <ogra> amitk, ctrl-d
[15:52] <ogra> though if you are past a script thats essential and it doesnt get re-executed it might fail
[16:08] <amitk> ogra: it does :-/ with "chvt: can't open console"
[16:08] <ogra> that sounds more like a devtmpfs or udev prob
[16:09] <ogra> do you have devtmpfs compiled in ?
[16:09] <ogra> and is udevd running
=== hrw is now known as hrw|gone
[17:05] <lag> ogra: If I have a kernel and I run update-initramfs on it them mkimage it, should it just work?
[17:06] <ogra> lag, if you wait until my just uploaded initramfs-tools is in the archive you only need update-initramfs
[17:06] <ogra> no mkimage or anyrthing needed ;)
[17:07] <lag> So what's this for then:
[17:07] <lag> mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d ./initrd.img-* ./uInitrd
[17:09] <ogra> that will give you a uImage in $(pwd)
=== kmargar is now known as markos_
[17:20] <lag> A uImage?
[17:20] <lag> Not a uInitrd?
[17:21] <lag> ogra: ?
[17:34] <ogra> lag, err, indeed, uInitrd
[17:34] <lag> And that's what I want right?
[17:35] <ogra> no idea what you want
[17:35] <ogra> what do you plan to do ?
[17:36] <ogra> lag, if you want to actually use it, it needs to be copied into the vfat partition too
[17:38] <lag> ogra: http://paste.ubuntu.com/475518/
[17:39] <lag> This is what I'm doing
[17:39] <lag> Is it correct
[17:39] <rsavoye> any ideas for a stable kernel I can run on an XM board that seems to trigger segfaults ?
[17:39] <lag> ogra: Line 67-71
[17:40] <ogra> lag, yeah
[17:40] <lag> rsalveti: Would you mind rephrasing the question please?
[17:40] <lag> Hmmm
[17:40] <rsalveti> lag: rsavoye :-)
[17:40] <ogra> rsavoye, there are bad ram chips on a good bunch of the XMs
[17:41] <rsavoye> is that my problem ? I can;t compile anything
[17:41] <ogra> rsavoye, if you have one of these, no kernel wont help
[17:41] <rsavoye> arg.... so much for free hardware :-(
[17:41] <ogra> i dont know exactly how to tell them apart
[17:41] <lag> rsalveti: :)
[17:41] <rsavoye> I'd love to know, it's getting in the way of work...
[17:41] <ogra> but there are two different manufacturers for the ram
[17:42] <ogra> one works, the other doesnt
[17:42] <rsavoye> Mine's got an 'A' on it
[17:42] <lag> rsavoye: I think it will only affect you if you are using >255.9MB RAM
[17:42] <rsavoye> I've got 512M, can I limit it to 256 but at 1Ghz ?
[17:42] <ogra> which he likely does when compiling
[17:43] <ogra> you could try booting with mem=
[17:43] <rsavoye> I'm using micheal1's C4, but now there are two of trying to compile at the same time...
[17:44] <ogra> well, XM is pre-production HW, dont expect it to work flawless yet
[17:45] <rsavoye> this was supposedly post production... :-(
[17:45] <rsavoye> ogra: how to boot with mem= from the monitor ?
[17:45] <ogra> there are no "post production" XMs yet
[17:46] <rsavoye> ah....
[17:46] <ogra> you need to change the cmdline in boot.scr (if your image has one, no idea what you use over there)
[17:46] <ogra> else you are doomed to serial console :)
[17:47] <rsavoye> I can live in the serial console no problem if it stops crashing :-)
[17:47] <ogra> just for setting the mem= option i mean :)
[17:48] <rsavoye> that's what I was going to try, just gotta figure out the command line
[17:49] <ogra> in ubuntu the source for boot.scr is stored in /boot/boot.script, you can just change it and run sudo flash-kernel and reboot, not sure how it is on the linaro images
[17:50] <rsavoye> I should be running stock maverick
[17:51] <ogra> stock maverick from one of the alpha releases ? that should work with the ubuntu method above
[17:52] <rsavoye> yes, alpha-2 I believe
[17:52] <lag> ogra: So I can download the daily build, run that script on it (where uImage is my own kernel) and it should work?
[17:53] <ogra> lag, how would the update-initramfs be executed ?
[17:53] <ogra> (line 67)
[17:53] <ogra> i assume you run that script on your x86 host ?
[17:53] <lag> Yeah
[17:53] <ogra> then it wont work
[17:54] <lag> Oh?
[17:54] <ogra> the initramfs needs to be rolled inside the rootfs
[17:54] <rsavoye> ogra: flash-kernel run on the host or the target ?
[17:54] <ogra> rsavoye, all run in a booted beagle
[17:55] <rsavoye> don't see it, let me go look for it
[17:56] <ogra> lag, you would at least need to chroot into the rootfs and run it there, but it will try to install the modules from the kernel package which is indeed not installed inside your rootfs
[17:56] <ogra> since you work with raw uImage files
[17:57] <ogra> lag, if you only rebuild existing kernels and dont fiddle with modules etc i'd just omit the initramfs building completely
[17:57] <ogra> doing it in a cross way is some effort
[18:02] <rsavoye> ogra: what package is flash-kernel in ?
[18:02] <lag> ogra: NP - thanks
[18:02] <ogra> rsavoye, flash-kernel :)
[18:03] <rsavoye> I need more coffee....
[18:04] <rsavoye> You are currently running the Community Kernel edition  ?
[18:04] <ogra> i'm running the linux-omap or the linux-omap4 metapackages
[18:04] <rsavoye> should I remove /etc/flash-kernel.conf ?
[18:04] <ogra> depending on the board/image i run
[18:05] <ogra> no, /etc/flash-kernel.conf is needed so flash-kernel finds the vfat
[18:05] <ogra> (which holds bootloader and kernel)
[18:05] <rsavoye> ah, thanks. Maybe I should try linux-omap too
[18:07] <ogra> rsavoye, not on the XM ....
[18:08] <ogra> rsavoye, the XM doesnt find it's SD card currently with the -omap kernel, dont even try it
[18:09] <rsavoye> ok, thanks for stopping me before it was too late :-)
[18:10] <rsavoye> ## Executing script at 80200000
[18:10] <rsavoye> Bad data crc
[18:10] <rsavoye> oops...
[18:11] <rsavoye> time to reinstall from scratch I guess
[18:13]  * ogra calls it a da
[18:13] <ogra> y
[18:14] <rsavoye> guess I'll try alpha-3 this time
[18:26]  * XorA wishes he could just get meeting requests in non garbled forms in linux :-(
=== bjf[afk] is now known as bjf
[18:56] <rsavoye> oh well, maverick alp[ha-3 won't boot on an XM
[19:25] <GrueMaster> mpoirier: Test kernel is booting fine on my 4G Class 2 SD Card.  :D
=== Andy is now known as Guest52835
[21:58] <rsavoye> dpkg: error processing linux-image-2.6.35-14-omap (--configure):
[21:58] <rsavoye>  subprocess installed post-installation script returned error exit status 2
[21:58] <rsavoye> ah, "Cannot find mtd partition 'Kernel'"
=== JaMa is now known as JaMa|Zzz
=== bjf is now known as bjf[afk]
[22:35] <GrueMaster> rsavoye: That's an interesting issue.  Can you try running update-initramfs and possibly flash-kernel separately to see which is hitting this?  I suspect it may be flash-kernel.
[22:35] <rsavoye> after it reboots, it just hung on me...
[22:37] <rsavoye> yes, Cannot find mtd partition 'Kernel' comes from flash-kernel
[22:38] <GrueMaster> I wonder if I am hitting a similar issue with my lucid>maverick upgrade test (which I restarted and is still running).
[22:40] <GrueMaster> Are you running a maverick image?
[22:42] <jcrigby> rsavoye:does /etc/flash-kernel.conf exist?
[22:45] <rsavoye> nope
[22:47] <jcrigby> update-initramfs sources that file to setup UBOOT_PART
[22:47] <jcrigby> UBOOT_PART is what flash-kernel needs to know the boot partition device to update the kernel and initrd
[22:47] <rsavoye> no wonder it won't work :-)
[22:48] <rsavoye> can I just create the file ?
[22:48] <jcrigby> yes but update-initramfs may still not call flash-kernel because of another but there
[22:48] <jcrigby> s/but/bug
[22:49] <jcrigby> echo UBOOT_PART=/dev/mmcblk0p1 > /etc/flash-kernel.conf
[22:49] <rsavoye> I'm just trying to get my XM to run long enough to actually compile something
[22:50] <jcrigby> so you are trying a kernel upgrade?
[22:50] <jcrigby> update
[22:50] <jcrigby> ?
[22:51] <jcrigby> not sure newer kernel will fix anything
[22:55] <rsavoye> I get Creating backups of uImage and uInitrd... cp: cannot create regular file `/tmp/m
[22:55] <rsavoye> Failed to create initrd image.
[22:55] <rsavoye> what's weird is it wants to reinstall the kernel I'm already running
[22:57] <jcrigby> all flash-kernel does is mount your boot partition and copy kernel and initrd there
[22:58] <jcrigby> if you are already running the same kernel then this wont help anything
[22:58] <jcrigby> are you running ubuntu or linaro now?
[22:59] <jcrigby> I assume linaro since it missing the flash-kernel.conf file
[23:00] <rsavoye> I think linaro, but the repository seems to point to maverick
[23:00] <rsavoye> I couldn't get alpha3 to boot, so tried the linaro image, which at least booted
[23:03] <rsavoye> it's so much more fun to be on the bleeding edge like this :-)
[23:06] <GrueMaster> Odd.  I could have sworn either ogra or rsalveti had tested Alpha 3 on XM.
[23:07] <GrueMaster> Ah, found it.  Bug 613855.
[23:07] <ubot2> Launchpad bug 613855 in jockey (Ubuntu) "Jockey adds outdated debian repo for xerox from openprinting.org (affects: 1) (heat: 39)" [Undecided,New] https://launchpad.net/bugs/613855
[23:08] <GrueMaster> Err, that's not the right bug.  weird.
[23:08] <GrueMaster> Bug 613855
[23:08] <ubot2> Launchpad bug 613855 in linux (Ubuntu) "omap3 beagle XM MMC card always comes up readonly (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/613855
[23:08] <GrueMaster> Much better (or not, depending on your perspective).
[23:13] <rsavoye> GrueMaster: I'll gladly try alpha-3 again, but I reinstalled twice and it never booted
[23:14] <rsavoye> arg, build-dep is braindead
[23:15] <GrueMaster> I was looking at iso.qa.ubuntu.com.  According to the test results, it fails because the kernel is only seeing the microSD as read-only.
=== bjf[afk] is now known as bjf
[23:47] <rcn-ee> rsavoye, that's probally my bad with the /etc/flash-kernel.conf, what am i missing in my images to help users switch between kernels.. My main motivation is to stop 'flash-kernel' when i don't want it to right to flash..
[23:48] <rsavoye> rcn-ee: I'm trying the linaro image of 2.6.35-14, course it just hung...
[23:49] <rcn-ee> if it hangs after 'uncompressing' it's basicly bombing on the lack of omap3630 stuff..
[23:50] <rsavoye> that time it hung running configure
[23:50] <rsavoye> that is the configure script for Gnash
[23:56] <rcn-ee> rsavoye, are you going to be around for a bit? got to disable a couple config things to get it built, but i almost have a latest git kernel..
[23:56] <rsavoye> yep, it's only 1700 here
[23:57] <rcn-ee> oh, your montain time.. cool central here so basicly the same..  usually everyone's from europe..
[23:58] <rsavoye> yep, mountain time. I live up at 9000 feet in the Rockies of Colorado
[23:58] <rsavoye> wow, somebody almost in my time zone ? :-)
[23:58] <rsavoye> we must be the only 2...