[07:38] <DanaG> Nice job: http://theironlion.net/blog/2010/06/06/ubuntu-arm-board-and-i-walk-bar/
[07:38] <DanaG> RON LION
[07:38] <DanaG> That's what I get at 150% fullzoom.
[08:19] <hrw> morning
[11:20] <ogra> lool, what are you fiddling with upstart ? it didnt FTBFS since two uploads
[11:20] <lool> ogra: Fiddling?
[11:20]  * ogra wonders if the -fpic is still needed
[11:21] <lool> ogra: I don't understand your remark
[11:21] <ogra> lool, oh, it was -fpie not pic, why did you make that change to libnih ?
[11:21] <lool> ogra: I reverted an armel-specific workaround, read the changelog
[11:22] <ogra> oh, oops
[11:22] <ogra> sorry, misread
[11:22] <lool>   * Re-add -fPIE to the testsuite on armel, removing all armel-specific tests;
[11:22] <lool>     current gcc-4.4 don't seem affected by the ICE anymore (see LP #398403).
[11:22] <ubot2> Launchpad bug 398403 in upstart (Ubuntu) (and 4 other projects) "[PR40735] gcc-4.4 fails to build upstart 0.6 on armel due to an internal compiler error (affects: 2) (heat: 20)" [Undecided,Fix released] https://launchpad.net/bugs/398403
[11:22] <ogra> yeah
[13:46] <rsalveti> mythripk: how do you identified all the supported timing values for omap4 in the hdmi driver?
[13:46] <rsalveti> I was thinking if it can be compatible with omap 3 too
[13:47] <rsalveti> robclark: maybe you also know the answer :-) ^
[13:51] <ogra> lool, wrt your filesystem corruption issue from the weekend, do you use the initrd from the image and also the boot.scr ?
[13:52] <ogra> lool, i wonder how you even got fsck output on stdout, the scripts in initramfs redirect all that to the jasper.log
[13:53] <ogra> lool, also you wont be able to use that image without dd'ing it to a bigger img file (or min. 4G SD card), did you do that ?
[13:54] <ogra> (thre images we produce are really not suited for qemu usage without a lot of fiddling)
[13:59] <robclark> rsalveti: not sure how the timings were identified..  I think that is a question for mythripk
[14:00] <robclark> but I'm not sure how similar the beagle hdmi driver is..  but I assume there must be a table somewhere that the bootargs map to
[14:00] <rsalveti> robclark: yeah, could be, will have a look at it
[14:01] <hrw> robclark: omap3 did not checked edid
[14:01] <rsalveti> because the hdmi driver basically fetch the edid and then finds the best resolution that has a matching timing
[14:01] <robclark> hrw: but I assume it still uses timings somewhere under the hood... when you set code/mode bootargs, those must map to some supported timings
[14:02] <rsalveti> don't know if the code/mode is actually supported at beagle
[14:02] <hrw> there is a map of resolutions in omap3 driver
[14:02] <ogra> we have a spec to implement using EDID under omap3
[14:02] <ogra> fyi
[14:02] <rsalveti> ogra: I know, that's why I'm asking all these questions :-)
[14:02] <robclark> that map should contain the timings, I would guess..  since at some point that needs to be programmed in to the hw to generate correct signal
[14:03] <hrw> ogra: but without going to highest possible I hope
[14:03] <rsalveti> robclark: hm, true, will try to find it
[14:04] <ogra> hrw, with going to highest possible the current monitor and driver support
[14:07] <hrw> ogra: 1680x1050x16@24 omap3 can generate, my display probably will display but I prefer to not go more then 1280x800 on it
[14:07] <ogra> hrw, you are free to change the generated cmdline
[14:07] <ogra> its just to get a good default entry
[14:07] <hrw> sure
[14:08] <ogra> indeed preferably the omap3 driver would do the same the omap4 one just learns and wouldnt need cmdline args :)
[14:09] <ogra> but since we dont put much effort into omap3 development the cmdline will do for now
[14:19] <hrw> armel-cross-toolchain 1.16 sent to PPA for build
[14:31] <lool> ogra: As noted in my email, I don't touch the image at all and run it without resizing
[14:31] <ogra> lool, yeah, but did you use the cmdline from boot.scr and the initrd from the image ?
[14:31] <lool> ogra: I understand it might not be expected to work out of the box under QEMU, but my experience seems to indicate an underlying bug which might be worth looking into
[14:31] <lool> ogra: I'm not touching the image
[14:31] <lool> ogra: So it uses everything in there
[14:31] <ogra> (the corruption is surely on buildd side, i'm just wondering why you get that output at all)
[14:32] <ogra> so you use u-boot to boot it ?
[14:32] <lool> The u-boot in your image
[14:32] <ogra> right
[14:32] <ogra> thats weird
[14:32] <ogra> and when do you see the error ? before or after the automatic reboot
[14:33] <ogra> (there shouldnt be an fsck at all apart from teh jasper one before the boot and all jasper output is logged silently to a file)
[14:33] <ogra> s/boot/reboot/
[14:36] <lool> ogra: On first boot
[14:36] <ogra> thats strange
[14:36] <ogra> there is only one forced fsck during the resize process, then it should reboot right after jasper prints "reboot check"
[14:37] <ogra> if you see the fsck after "reboot check" its likely not following the process
[14:37] <ogra> i.e. reboot doesnt work
[14:38] <ogra> its also very likely that it doesnt do the resizing and reformatting at all in your case, which will definitely cause issues
[14:40] <ogra> (partitioning or filesystem size doesnt matter at all since we rewrite the whole partition table and reformat/resize the filesystems before the rootfs gets ever mounted)
[14:40] <ogra> so the corruption doesnt matter for functionality if the resizing works
[14:45] <ogra> ndec, try to re-upload to the PPA, it should build armel now
[15:08] <ndec> ogra: well, in fact it's not showing armel, but it does show sparc and powerpc ;-)
[15:09] <ndec> ogra: you should be able to see the PPA, i have uploaded
[15:09] <ogra> well, it was just changed, it should build armel now
[15:09] <ogra> i think you need to re-upload
[15:09] <ndec> ogra: I uploaded after you told me about it... is there any delay?
[15:14] <ogra> ndec, ok, i'm told it should be fixed *now*
[15:16] <ndec> ogra: i just tried to upload a package with arch=armel only, and it seems that the upload worked. we will see in a few mins.
[15:16] <ogra> yep
[15:16] <ogra> seems armel needed special treatment for enabling
[15:16] <ogra> enabling the ports just gave ia64, sparc and ppc
[15:16] <ogra> ah, your ubuntu4 upload looks good
[15:17] <ndec> ogra: ubuntu3 looks good too. it has arch=any, and armel is there.
[15:18] <ogra> ah, i didnt look at 3 :)
[15:18] <ogra> but right, seems ok now
[15:18] <ogra> ndec, so i'd say enjoy your PPA :)
[15:19] <ogra> (and give me a list with other trusted uploaders at some point)
[15:19] <ndec> ogra: i can add them myself since you made me admin, no?
[15:19] <ogra> i didnt make you admin, i think asac did though
[15:20] <ogra> but yes, you should be able to
[15:20] <ndec> ogra: i will try. for now we will try to put all the packages in the PPA for review, and let you know.
[15:21] <ogra> great :)
[15:50] <prpplague> mopdenacker: hey, do i need to send another confirmation for my ELF-EU presentation, or was that just for the people who were CC'd on that email?
[15:53] <mopdenacker> prpplague: no, you don't have to. I already have your confirm. :-)
[15:53] <prpplague> mopdenacker: dandy
[15:54] <prpplague> mopdenacker: i've got to finish testing some new boards this morning, then this afternoon i'll be back on your display issue
[15:55] <mopdenacker> prpplague: perfect. Thank you very much! I'm excited to meet you in Cambridge at last :-)
[15:55] <mopdenacker> Good luck!
[15:56] <prpplague> mopdenacker: me too
[17:15] <prpplague> robclark: hey, so you think we need to trace through the resize notification to track down this issue?
[17:18] <DanaG> hmm, that bit about the log redirecting to jasper.log... shouldn't it use "tee"?
[17:19] <robclark> prpplague: yes.. I think so
[17:19] <prpplague> robclark: can you recommend a function call to start looking at?
[17:19] <ogra> DanaG, why =
[17:19] <ogra> s/=/?/
[17:20] <DanaG> So you can get them over stdout.
[17:20] <DanaG> Or is it not possible to lose jasper.log anyway?
[17:20] <DanaG> Say the thing fails in some way that makes you unable to retrieve the log... can that even happen?
[17:21] <robclark> prpplague: hang on, I'll swing by
[17:21] <ogra> DanaG, it cant get lost but in some stages it can get hard to access the log
[17:22] <prpplague> robclark: thanks
[17:23] <DanaG> Ah, pidgin died: https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/622831
[17:23] <ubot2> DanaG: Error: Bug #622831 is private.
[17:24] <DanaG> ah
[17:24] <DanaG> Would pidgin bug logs have passwords?
[17:26] <DanaG> ah yeah, the core dump has my irc password.
[17:57] <ogra> GrueMaster, so the oem-config fix works fine, as soon as dyfet has fixed telepathy-glib the images should build again and we should have a working install process again
[18:01] <rsalveti> cool, finally :-)
[18:02] <ogra> and oem-config has a cute panel now
[18:02] <ogra> which suspiciously looks like upanel
[18:03] <ogra> (the thing we dropped because DX didnt provide the code for it)
[18:04] <ogra> anyway
[18:04]  * ogra calls it a day
[18:04] <GrueMaster> cool
[18:05] <GrueMaster> ogra: I'm going to be spending the day trying to figure out how I am going to manage 3 new platforms into my office layout.  Should be ready for testing later today.
[18:36] <prpplague> robclark: looks like i can replicate that problem with the dvi display
[18:52] <mythripk> rsalveti: Timings supported by omap4 are based on functional spec and max /supported pixel clock values that can be generated by hdmi pll
[18:52] <rsalveti> mythripk: hm, ok
[18:53] <rsalveti> mythripk: I was thinking about omap 3, how can we check the supported timings?
[18:55] <mythripk> rsalveti:not all omap4 timings are supported by omap3,it  has limited set of timings is what i believe ,I can check with pulukuru,srinivas in case you dont have his contacts and get back to you.
[18:55] <rsalveti> mythripk: nice, that would for sure help :-)
[18:55] <rsalveti> because then we can try to identify the best supported video mode for omap 3
[18:57] <robclark> prpplague: oh good.. I can swing by in a bit
[18:59] <mythripk> rsalveti:720P is the maximum supported timing in omap3 is what im aware of.. other timings i need to confirm
[19:00] <rsalveti> mythripk: hm, I thought it would support higher timings
[19:00] <rsalveti> mythripk: but please, confirm it if possible :-)
[19:11] <mythripk> rsalveti : confirmed max omap3 supports is 720P
[19:17] <ynezz> I think, that you can do 1080i/1080p@30 on beagle
[19:21] <rsalveti> ynezz: the pixel clock seems to limit you
[19:21] <rsalveti> mythripk: nice, thanks
[19:22] <ynezz> rsalveti: yes, it depends on TV/monitor also, if it can do lower sync rates
[19:22] <ynezz> but I've read, that somebody was able to run 1080p30 at beagle
[19:28] <rsalveti> ynezz: cool
[19:30] <ynezz> http://markmail.org/message/b7fii2z6qcf3di3x
[19:56] <ynezz> heh, I'm blind or need more cofee, but where could I enter here new bug/feature request? :-) https://bugs.launchpad.net/~beagleboard-kernel
[20:06] <GrueMaster> ynezz: If you wish to file it as a bug against the Ubuntu kernel for omap3, file it against linux-image-omap.  Use linux-image-omap4 for omap4 kernels.
[20:06] <GrueMaster> Mark importance as wishlist.
[20:07] <GrueMaster> Oops, excuse me, that should be linux-ti-omap & linux-ti-omap4.
[20:09] <ynezz> ah, thanks :)
[20:12] <ian_brasil_> is there a mobile meeting tomorrow?
[20:13] <rsalveti> ian_brasil_: yep, every week
[20:14] <rsalveti> ian_brasil_: 9 am for you, I guess
[20:15] <ian_brasil_> rsalveti: thx
[21:10] <DanaG> weird... plymouth doesn't work on the beagleboard.
[21:11] <DanaG> ah, I see... it won't splash if serial console is present.
[22:32] <lool> ogra: FYI libnih built fine
[23:28] <DanaG> Weird... flash-kernel hangs the board at "erasing kernel NAND space..."
[23:28] <DanaG> er, wait, it unfroze.
[23:29] <rsavoye> to upgrade to maverick but leave the kernel, uboot, and firmware alone on a iMX51, is using update-manager a stupid idea ?
[23:29] <DanaG> It's spewing: [ 6632.227600] uncorrectable error :
[23:30] <DanaG> [ 6631.614959] Buffer I/O error on device mtdblock3, logical block 124