[00:42] <neil_d> can you use an ARM board as a LTSP client?   where the server is x386 bassed.
[01:00] <Martyn> yes
[01:00] <Martyn> well, sort of
[01:00] <Martyn> PXE booting support is kind of lacking
[01:00] <Martyn> although we've got a patch at work, which we're working on upstreaming, to add pxe support to uboot
[02:32] <neil_d> I suppose you could put the chroot environment on a compact flash card... have it boot from that.. then switch to using the main server for everything else...
[07:20] <rsalveti> cooloney: for the highmem issue, it'd be nice to test it upstreams
[07:20] <rsalveti> *upstream
[07:20] <rsalveti> http://marc.info/?l=linux-omap&m=128413257515288&w=2
[07:20] <rsalveti> it seems we have a tree that can boot at the es2, but for me it was unable to find the mmc
[07:20] <rsalveti> so can't test it
[07:21] <rsalveti> once we have a better answer from Ghorai, pointing us what is needed to make it work, we can easily test if we can reproduce the highmem issue with upstream
[07:29] <cooloney> rsalveti: thanks, man
[07:30] <cooloney> rsalveti: did you try the audio things on your ES2.0
[07:30] <cooloney> i need to reinstall the daily-live image on my board, but lost my HDMI cable
[08:23] <hrw> morning
[09:32] <vstehle> ogra_omap4: Hi! Today's image checks the drives at boot, and finds errors! "Press F to attempt to fix..."
[09:34] <ogra> vstehle, smells like the rsizing didnt happen
[09:34] <ogra> *re
[09:35] <ogra> vstehle, is that completely unmodified ?
[09:35] <vstehle> ogra: Yes. zcat, reboot.
[09:36] <vstehle> ogra: I saw the resize happen.
[09:36] <ogra> hmm
[09:36] <ogra> and it reboots too ?
[09:37] <ogra> after resize ...
[09:37] <vstehle> ogra: Yes.
[09:38] <ogra> hrm
[09:38] <vstehle> ogra: The disk checks happens before reboot.
[09:38] <ogra> *before* ?!?
[09:38] <ogra> now thats weird, there is nothing that could do an interactive check at that point
[09:39] <vstehle> ogra: Ok, not completely accurate: it rebooted after checks :)
[09:39] <vstehle> ogra: Probably because slash was "fixed" ?
[09:39] <ogra> slash ?
[09:39] <vstehle> ogra: /
[09:39] <ogra> no
[09:40] <ogra> there is one fsck right before resizing, but thats completely /dev/null'ed
[09:40] <ogra> after resizing there isnt any fsck until the reboot command
[09:40] <vstehle> ogra: This one I did not see
[09:40] <ogra> "checking filesystem before resizing..."
[09:40] <ogra> thats the one
[09:40] <vstehle> ogra: I don't know the exact command; it was the graphical frontend, with the dots
[09:41] <vstehle> ogra: It was not in text mode any more
[09:41] <ogra> but there should be no output ot the screen and definitely no interaction
[09:41] <ogra> then it was after reboot
[09:41] <vstehle> ogra: There were messages about filesystem check
[09:41] <vstehle> ogra: And it definitely asked me to type 'F' to confirm that it should "fix" the filesystem
[09:42] <vstehle> ogra: It complained also for a fraction of a second about tmp not being there or not ready
[09:42] <vstehle> ogra: and then reboot
[09:42] <ogra> there is no splash screen before reboot at all
[09:42] <vstehle> ogra: maybe it rebooted also between resize and dots, probably.
[09:42] <ogra> well, you would have noticed
[09:42] <ogra> it takes a while for u-boot
[09:43] <vstehle> ogra: But I don't have the serial console in front of me always
[09:43] <ogra> no, but you would have a black screen for about 30sec at least
[09:43] <ogra> until kernel/initrd are there
[09:43] <vstehle> ogra: I'll redo the steps more carefully and take notes :)
[09:44] <ogra> k, i'll try to reproduce it here too
[09:44] <vstehle> ogra: I can run a terminal ok, today :)
[09:44] <ogra> did you have network plugged in btw ?
[09:44] <vstehle> ogra: Yes
[09:44] <ogra> hmm, k
[09:45]  * ogra zsyncs todays image to check whats going on
[09:45] <vstehle> ogra: Oh, wait, you mean: when the "checks" happened? The board had no network.
[09:45] <ogra> aha
[09:45] <ogra> might be an issue with the fixrtc script that sets the clock to last mount time of the disk
[09:46] <ogra> it is to prevent fsck if the clock is wrong
[09:47] <ogra> (which it always is if there is no ntp server reachable and no RTC closk)
[09:47] <ogra> *clock
[09:47] <ogra> err
[09:47] <ogra> s/clock/battery/
[09:49] <vstehle> ogra: Also, we don't have a gnome "bar" any more. Is this awaited?
[09:49] <ogra> no, its not
[09:50] <vstehle> ogra: I would have sworn it was there during the installer...
[09:50] <ogra> thats not gnome :)
[09:50] <ogra> the installer has its own minimal panel now
[09:50] <ogra> (i'll switch our desktop to it during natty)
[09:52] <vstehle> ogra: There is something weird with the console colors; the red is black.
[09:52] <ogra> checked your cable ?
[09:52] <ogra> we didnt have a kernel upgrade or anything afaik
[09:52] <ogra> so the framebuffer shouldnt have changed
[09:53] <vstehle> ogra: :) Looks like a software thing this time. Try typing 'z' in top in text mode.
[09:53] <ogra> well, let me get an image first, still zsyncing
[09:54] <ogra> 3min to go
[09:54] <vstehle> ogra: You can do the same in a gnome terminal and see the difference
[09:54] <vstehle> ogra: I'll redo the zcat and install.
[09:54] <ogra> and i need to find some breakfast first
[09:54] <ogra> hmm you are using zcat ... ?
[09:54]  * ogra has never done it that way ...
[10:24] <neil_d> anyone here know anything about this http://www.embeddedarm.com/products/board-detail.php?tab=options&product=TS-7800#   like if ubuntu can be put on it?
[10:33] <ogra_cmpc> neil_d, thats ARM9 (ARMv5) ... ubuntu only supports v7 (cortex-a8 and upwards)
[10:33] <ogra_cmpc> use debian on ARM9
[10:36] <ynezz> neil_d: as ogra said debian or with some little work openembedded(angstrom) and openwrt
[10:37] <ynezz> neil_d: there's support for ts72xx boards in OpenEmbedded already
[10:38] <ynezz> neil_d: and here's quite old but a good starting point for ts7800 http://ted.openavr.org/OE-for-ts7800/
[11:59] <neil_d> so is the ARM9 a different thing to the cotex-a8 etc.?
[11:59] <ogra> cortex-a8 is ARMv7
[11:59] <ogra> while ARM9 is only ARMv5
[11:59] <ogra> different specifications
[12:00] <ogra> all ubuntu binaries are built specifically for v7
[12:00] <ogra> so they wont run on older stuff
[12:00] <neil_d> oh!
[12:01] <ogra> imagine you try to run binaries that are compiled for i686 on a real 386 machine
[12:01] <ogra> 386 wont have all the instructions the 686 has
[12:01] <neil_d> been trying to find an ARM card with SATA for a dedicated server... but they are hard to find.
[12:02] <ogra> yeah
[12:02] <ogra> SATA is very rare on ARM SoCs
[12:02] <hrw> neil_d: grab guruplug
[12:02] <ogra> right
[12:02] <ogra> but that wont run ubuntu either
[12:02] <hrw> neil_d: or other kirkwood based device with sata and run debian on it
[12:56] <ogra> vstehle, so i had no fsck yet with todays daily image
[12:57]  * ogra wonders if vstehle's SD card is somewhat worn out
[12:58] <vstehle> ogra: I could not reproduce it. I think I might have not waited enough for shutdown
[12:58] <ogra> ah, yeah, that could be
[12:58] <vstehle> ogra: Btw, the gnome menu is back; was probably linked to my bad fs somehow
[12:58] <ogra> we only flush the cache for the Sd at unmount
[12:58] <vstehle> ogra: I am now trying SGX on top of daily; promising
[12:58] <ogra> sweet
[13:00] <ogra> jasper sets vm.vfs_cache_pressure=50 and vm.dirty_writeback_centisecs = 6000 ... that causes the kernel to write to the SD less often which results in a massive speedup, but requires that you properly shut down
[13:00] <rsalveti> vstehle: cool, with the latest driver?
[13:00] <ogra> (as a rule of thumb, just wait until the monitor shuts off)
[13:06] <vstehle> rsalveti: Yes. But it is not completely ok now :)
[13:08] <rsalveti> vstehle: oh, ok :-)
[14:53] <lag> ogra: If I boot up my ES2.0 and install a new kernel using dpkg, do I have to do anything after?
[14:53] <lag> I am 'downgrading' the kernel
[14:54] <lag> ls
[14:55] <rsalveti> lag: besides updating uInitrd and uImage, nothing
[14:56] <rsalveti> just make sure flash-kernel is taking the kernel you want
[14:56] <lag> How do I do that from inside the image?
[14:56] <lag> So far I've issued: dpkg -i linux-*
[14:58] <ogra> that should suffice
[14:58] <ogra> try it :)
[14:58] <lag> That does everything?
[14:58] <ogra> a reboot only takes a minute
[14:58] <lag> It's still installing
[14:58] <rsalveti> I should, I believe
[14:58] <ogra> it generates an initrd and calls flash-kernel in the end, yes
[14:59] <lag> k
[14:59] <ogra> if you have any issues, file a bug against flash-kernel
[14:59] <ogra> but i dont think you will have any
[15:03] <lag> 0 bytes read
[15:03] <lag> ## Booting image at 80000000 ...
[15:03] <lag> Bad Magic Number
[15:03] <lag> PANDA #
[15:03] <lag> :(
[15:03] <rsalveti> lag: could be the case that you're still using the old u-boot
[15:03] <ogra> smells like it
[15:03] <lag> It's a fresh flash
[15:03] <lag> From today's image
[15:04] <lag> It booted the first time
[15:04] <lag> Oh wait!
[15:28] <ogra> lag, we're still waiting :)
[15:28]  * lag is reflashing
[15:29] <ogra> ah
[15:59] <GrueMaster> ogra: omap not building images?  I only got a blank email.
[15:59] <ogra_ac> Yeah, that happens if the builder is down
[15:59] <GrueMaster> Ah.
[15:59] <ogra_ac> I pinged lamont already
[16:00] <ogra_ac> At least omap4 worked fine
[16:14] <lag> How do you retrieve this number: 2.6.35-903.X
[16:30] <armin76> lag: grep :D
[16:32] <furibondox> hi all, I have a problem using --no-root with the latest rootstock (version 126):  http://paste.ubuntu.com/493171/
[16:32] <lag> armin76: grep what for what?
[16:33] <rsalveti> furibondox: can you paste your log file?
[16:33] <furibondox> yes
[16:34] <ogra_cmpc> lag, uname -r
[16:34] <furibondox> http://paste.ubuntu.com/493172/
[16:34] <furibondox> this is the last part of the file
[16:34] <lag> ogra_cmpc: Tried that
[16:35] <ogra_cmpc> lag, and ?
[16:35] <furibondox> rsalveti: I'm running the rootstock from a lucid pc
[16:36] <lag> Displays 2.6.35-903-omap4
[16:36] <lag> I need to know X where X is a number
[16:36] <ogra_cmpc> oh tou want the abi
[16:36] <rsalveti> furibondox: interesting, the error message is "Success" :-)
[16:36] <lag> Yeah
[16:36] <ogra_cmpc> *you
[16:36] <furibondox> right... it seems that genext2fs return a right error code (0)
[16:36] <rsalveti> furibondox: let me try it here
[16:36] <rsalveti> yep
[16:37] <furibondox> rsalveti: I try to insert an echo $? and the output was 0
[16:39] <ogra_cmpc> lag, dpkg -l|grep linux-image|grep ^ii|grep $(uname -r)
[16:39] <ogra_cmpc> and then some cut magic to get the second field
[16:39] <lag> What's ^ii?
[16:40] <ogra_cmpc> it greps only installed packages
[16:40] <ogra_cmpc> (filter for dpkg -l)
[16:40] <lag> It just locked up on me :(
[16:41] <ogra_cmpc> what ? dpkg
[16:41] <rsalveti> furibondox: for now, try commenting the if part of genext2fs (calling it directly) to see if rootstock is able to create the rootfs
[16:41] <lag> No, the board
[16:41] <lag> Went to screen saver and refused to come out
[16:41] <ogra_cmpc> try switching consoles
[16:41] <lag> Rebooting
[16:41] <ogra_cmpc> gah
[16:41] <lag> Next time
[16:41] <ogra_cmpc> yeah
[16:41] <rsalveti> furibondox: I'm looking why genext2fs trying to be verbose
[16:42] <rsalveti> *is trying
[16:42] <furibondox> ok
[16:42] <ogra_cmpc> i noticed something similar but console switching solves it ... i cant reproduce it reliably yet though
[16:42] <furibondox> now i try commenting the if part...
[16:43] <lag> ogra: What's the current ABI?
[16:43]  * ogra_cmpc cant tell from here
[16:44] <lag> When I installed it, it said "downgrading to x.x.x-903.8 from x.x.x-902.11
[16:44] <lag> But only 5 and 8 are installed
[16:44] <ogra_cmpc> hmm
[16:45] <ogra_cmpc> thats also not a downgrade
[16:45] <ogra_cmpc> 903 > 902
[16:47] <furibondox> rsalveti: after commenting the if part it seems that it stops again... but I don't understand why
[16:47] <furibondox> http://paste.ubuntu.com/493180/
[16:48] <furibondox> after line 7 it return to the prompt
[16:49] <lag> ogra_cmpc: What?
[16:49] <rsalveti> furibondox: probably because of genext2fs return code (the script has set -e)
[16:49] <lag> ogra_cmpc: Oh, I see
[16:49] <lag> No, that's a typo
[16:49] <lag> Both were 903
[16:51] <furibondox> yes... I see
[16:52] <rsalveti> furibondox: after failing, try running genext2fs by hand
[16:52] <rsalveti> so we can understand why it's failing
[16:53] <furibondox> I can try to print the same command line used by genext2fs and then execute the same command...
[16:53] <rsalveti> furibondox: yep, or call it with bash -x ./rootstock
[16:54] <furibondox> I've done it before but the /tmp/tmp.XXXXX/rootfs folder is not more present...
[16:55] <furibondox> may be now without the if part the cleanup function is not called so the rootfs folder extracted should be leaved in the /tmp/tmp.XXXXXX
[16:55] <furibondox> right?
[16:56] <rsalveti> furibondox: yep, without the if part the clean_up is not called
[16:57] <rsalveti> so you can still go to the generated directory
[16:57] <furibondox> i can check but I have to run the rootstock again with the set -x in order to check the exact parameters to pass to genext2fs
[16:58] <rsalveti> furibondox: or you can try to look for the /tmp/tmp.XXX directory that was't wiped out
[16:59] <rsalveti> genext2fs -b 104857 -i 4096 -d rootfs rootfs.img should be ok
[17:00] <rsalveti> furibondox: genext2fs -b 2097152 -i 4096 -d rootfs rootfs.img as you requested 2GB
[17:00] <furibondox> genext2fs -b 2097152 -i 4096 -d /tmp/tmp.8DXifxNx1k/rootfs /tmp/tmp.8DXifxNx1k/qemu-armel-201009131759.img
[17:00] <furibondox> I'm waiting the exit of the program...
[17:00] <rsalveti> ok
[17:04] <furibondox> http://paste.ubuntu.com/493184/
[17:04] <furibondox> very strange... the qemu image is 0 byte long
[17:05] <rsalveti> furibondox: did it fail with the same message?
[17:05] <furibondox> genext2fs: output filesystem image: Success
[17:05] <furibondox> yes
[17:05] <rsalveti> furibondox: try using -b 1048576
[17:06] <rsalveti> genext2fs consumes a lot of ram
[17:06] <furibondox> I'm trying
[17:06] <ogra_ac> yes, you need as much free ram as the imagesize is
[17:07] <rsalveti> genext2fs is a quite old code, and it was created to generate small images, so they just map everything into memory
[17:08] <furibondox> great! using -b 1048576 the image is generated correctly
[17:08] <rsalveti> furibondox: so try running with -i 1GB
[17:09] <furibondox> yes I'm just trying ;)
[17:11] <furibondox> I've also remove the comment to the if part...
[17:22]  * rsalveti lunch
[17:44] <GrueMaster> ogra: On bug 628204, should I refile it against the go-home-applet?
[17:44] <ubot2> Launchpad bug 628204 in ubuntu-netbook-efl-default-settings (Ubuntu Maverick) (and 1 other project) "go-home-applet not accessable on armel images (affects: 2) (heat: 506)" [Medium,Confirmed] https://launchpad.net/bugs/628204
[17:44] <ogra_ac> yeah
[17:46] <GrueMaster> Done.  I had been looking at the gconf settings between Lucid & Maverick and not seeing anything different there.
[17:48] <ogra_ac> i doubt its gconf
[17:50] <GrueMaster> Like I said, I didn't find anything there.  Just a blank entry.  Nothing in the go-home-applet source indicates that it uses more than that.
[20:06] <armin76> http://www.anandtech.com/show/3912/boxee-box-the-inside-story
[20:48] <mpoirier> robclark: good afternoon
[20:49] <robclark> hi mpoirier
[20:50] <mpoirier> robclark: a few weeks ago we had a chat about EDID
[20:50] <mpoirier> I read it from user space, you from the driver.
[20:51] <mpoirier> could you point me to your patch one again pls ?
[20:51] <robclark> yeah.. and I talked a bit w/ mythripk about it since then.. since we have a similar issue with the DVI-D interface on panda..
[20:51] <robclark> sure hang on..
[20:52] <robclark> fwiw, mythripk was suggesting adding an API to the panel driver to return either the fixed timings (for LCD type device, with hard-coded resolution), or EDID for things like HDMI/DVI monitor..
[20:52] <robclark> so probably we should have a talk with her one of these mornings
[20:53] <mpoirier> at this time, we are looking to do a back port of your work in omap3 - do you think this is possible ?
[20:53] <robclark> possibly..
[20:54] <robclark> although mythripk was talking about splitting out EDID code into separate utility within DSS2..  that would make your life a bit easier, but not sure about the timeframe
[20:54] <mpoirier> I wanted to investigat first
[20:54] <robclark> fwiw, my most current branch right now is http://gitorious.org/~robclark/pandaboard/robclarks-kernel-omap4/commits/drm-lite ... but the patches you are interested in are a bit further down..
[20:54] <mpoirier> let check...
[20:55] <robclark> I guess look at the commits that have EDID or HDMI in the name ;-)
[20:56] <ogra_ac> mpoirier, did you talk to ricardo ? he owns teh EDEI spec now
[20:56] <ogra_ac> *EDID
[20:57] <mpoirier> robclark: thanks for your time
[20:57] <ogra_ac> (just to make sure we dont duplicate work here, i'm not sure if he doesnt work on the u-boot implementation right now)
[20:58] <ogra_ac> rsalveti ^^^
[20:58] <robclark> mpoirier: also.. dss2/omapfb don't deal well with dynamic resizing.. have a look at the commits cad4d0c, c07189e
[20:59] <rsalveti> mpoirier: I have a patch already trying to add the EDID parsing in omap3
[20:59] <rsalveti> that's what I'm currently working on
[21:00] <rsalveti> what I'm trying at the moment is probing and parsing the edid at the panel-generic
[21:00] <rsalveti> using the api we already have at the kernel
[21:01] <rsalveti> omap4 is not using the edid api
[21:01] <rsalveti> but getting and parsing everything by hand
[21:02] <rsalveti> robclark: the idea for now would be just to probe and get it right while booting the kernel
[21:02] <rsalveti> the second step would be changing it, when needed
[21:04] <robclark> rsalveti: just keep in mind, that omapfb might end up initializing itself (and therefore reading the resolution) before the HDMI driver has a chance to read the EDID
[21:04] <robclark> so even if the monitor is plugged in a boot, the order of things at bootup might screw you
[21:05] <rsalveti> robclark: oh, sure
[21:08] <rsalveti> argh, sgx packaging is just terrible
[21:08] <rsalveti> we have 3 different sets of libraries
[21:08] <rsalveti> each one for a different hardware
[21:08] <rsalveti> at least the kernel modules are the same
[21:08] <rsalveti> and just the .so files
[23:35] <GrueMaster> NCommander: Any chance of reviving apport-retrace this cycle?
[23:39] <NCommander> GrueMaster: now that I'm back home, maybe
[23:39] <NCommander> depends on how stable my A0 is
[23:41] <GrueMaster> Other than the stupid parallel port driver, it should be fine.  Mine is.
[23:42] <NCommander> GrueMaster: indeed. the A0 is much more stable IMHO