[00:15] <rlameiro> anyone here has problms with ureadhead?
[00:16] <persia> I think rsalveti was talking about some issues with it and OOM in the past
[00:18] <rlameiro> well, it still have that problem
[00:18] <rlameiro> Im not sure if I used the last rootstock
[00:18] <rlameiro> I remeber i needed to change some file somewhere, i will dig it again
[00:21] <persia> I think rsalveti was having the issue with jasper images: maybe rootstock needs the same hack
[00:23] <GrueMaster> rlameiro: Bug 600359
[00:23] <ubot2> Launchpad bug 600359 in ureadahead (Ubuntu Maverick) (and 1 other project) "ureadahead generating oom messages during boot. (affects: 10) (dups: 1) (heat: 70)" [High,In progress] https://launchpad.net/bugs/600359
[00:24] <GrueMaster> Is that what you are referring to?
[00:24] <rlameiro> yes
[00:24] <rlameiro> it hangs at boot
[00:24] <GrueMaster> Hangs?  Which system?
[00:26] <rlameiro> IGEPv2
[00:26] <rlameiro> beagle clone with more ram and wireless
[00:27] <rcn-ee> rlameiro, anything special with your setup? (mine with IGEPv2's factory u-boot and mainline 2.6.35 is solid..)
[00:28] <rlameiro> i build the kernel 2.6.33.7 and custum rootfs made with rootstock
[00:28] <rlameiro> this happended to me before
[00:28] <rlameiro> it hangs at the boot and it doesnt prompt for login
[00:29] <rlameiro> ahh, and the led is blinking green
[00:29] <rlameiro> rcn-ee: opps didnt ping you
[00:29] <rcn-ee> humm weird.. (mine's in the basement so i never see it..)  anything special in that 2.6.33.7?
[00:30] <rlameiro> well, it had some stuff added for the omap stuff
[00:31] <rlameiro> its the igepv2's website
[00:31] <rcn-ee> reference if nothing too special (i have most of the omap stuff in it.): i'm running: http://rcn-ee.net/deb/maverick/v2.6.35.4-l4/linux-image-2.6.35.4-l4_1.0maverick_armel.deb
[00:31] <rlameiro> does audio works aut of the box?
[00:32] <rlameiro> rcn-ee: and his it built for the igepv2 board?
[00:32] <rcn-ee> audio i don't know... video works, one of the igepv2 guys sent me patches when it wasn't working..  otherwise sgx/dspbridge stuff enabled..
[00:32] <rcn-ee> it's built for all. ;) (beagle, overo, touchbook, igepv2, panda)
[00:33] <rlameiro> why is it a deb?
[00:33] <rlameiro> isnt it an uImage file?
[00:33] <rcn-ee> for rootstock.. ;)
[00:33] <rlameiro> ohhhh, i need to build a new rootfs
[00:33] <rlameiro> :D
[00:33] <rcn-ee> otherwise, dpkg extract, mkimage on vmlinuz.. ;)
[00:33] <rlameiro> well, the problem will be the same i guess
[00:33] <persia> .debs are better anyway: they can have pre- and post- install logic, and be removed cleanly :)
[00:34] <rlameiro> rcn-ee: but will rootstock build and install the modules?
[00:35] <rlameiro> lol
[00:35] <rlameiro> http://webcache.googleusercontent.com/search?q=cache:ZavfyW4gZlwJ:thetechshop.org/showthread.php%3F193-Ubuntu-Howto-Fix-ureadahead-problem-on-10-04+how+to+fix+ureadahead&cd=8&hl=pt-PT&ct=clnk
[00:35] <rcn-ee> yeap, it'll output a vmlinuz-.... and a uIntrd-....  for first boot and the modules wil be installed. (i'm the one who sent ogra the patches for --kernel-image addon to rootstock)
[00:36] <rcn-ee> that's easy enough, do that first... ;)
[00:36] <rlameiro> so, i copy the vmlinuz and uIntrd to the boot partition
[00:37] <rcn-ee> yeap, you'll have to run mkimage... the script plays dumb, since u-boot/omap address isn't 100% of the arm boards...
[00:39] <rcn-ee> hey persia, are you guys tracking/noticing a lot of oem-config/ubiquity bugs in your armel images?
[00:40] <persia> I'm not, but I've no idea about others.  I've seen ogra trying to work around some things with jasper and ubiquity and debian-installer changes.
[00:41] <rlameiro> well, i think i will need to do it your way rcn-ee  :D
[00:41] <rlameiro> do you have some place explaining the steps?
[00:41] <GrueMaster> I'm seeing some issues getting the XM to boot into oem-config on the 20100909 image.
[00:41] <GrueMaster> rcn-ee: ^^^
[00:41] <rcn-ee> GrueMaster, it just dies with oem user not found, black screen/etc. ;)
[00:41] <GrueMaster> Been fighting it all day now.
[00:42] <GrueMaster> Interesting.  My problem is that it just fails to run, or part of it fails.
[00:42] <persia> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bugs?field.tag=armel is the URL for the current set of reported armel/ubiquity bugs.
[00:42] <rcn-ee> sure rlameiro, where you at with it..
[00:42] <GrueMaster> Worked fine when I first tested the 20100909 image.
[00:43] <rlameiro> rcn-ee: well, bette, do you have it in some webpage explained ? :D
[00:43] <rcn-ee> rlameiro, yeap.. elinux.org/BeagleBoardUbuntu  ;)
[00:43] <rlameiro> rcn-ee: oki
[00:43] <rcn-ee> those demo images will work on the igepv_2.. ;) just use the latest setup_sd.sh script..
[00:44]  * rcn-ee don't you hate when you cant' find that bug/report log browser tab...
[00:44] <rlameiro> rcn-ee: one problem, I dont have HDMI here for the first boot.
[00:45] <rlameiro> i run it headless via serial/ssh...
[00:45] <rcn-ee> ahh crap yeah... i'll have that fixed for the next image.. (defaults ubuntu/temppwd)...
[00:46] <rcn-ee> GrueMaster, i think that happend between 2.3.18/2.3.19 http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/changes
[00:46] <rlameiro> but if i build it with rootstock will i have the same problem?
[00:46] <rlameiro> maybe that is my problem now
[00:46] <rcn-ee> rlameiro, as long as you put a login and password it'll be fine...
[00:46] <rlameiro> it boots but doesnt give me acces to a console
[00:47] <rcn-ee> actually it might be, if oem-config was installed..
[00:47] <rlameiro> maybe it boots but graphical only, i put a password in it
[00:47] <GrueMaster> rcn-ee: There is a problem with it not running on newer images.  Not sure what it was, but I was told they were working on it.
[00:47] <rlameiro> brb
[00:48] <rcn-ee> i'm just doing nightly builds/tests and it's getting worse.. my workaround with 2.3.3 doesn't work anymore either. ;)
[00:49] <GrueMaster> The last daily image that built was 20100916, but oem-config fails to run.  Prior to that, 20100909 was the last working preinstalled image.
[00:52] <persia> I thought people said good things about 20100914 at one point
[00:52] <GrueMaster> It was good for omap4.
[00:52] <persia> Ah.
[00:52] <GrueMaster> No omap build.
[00:54] <rcn-ee> as a plus the next release those should be combined.. (well 2.6.37 based ubuntu)
[00:56] <persia> The next release is probably .37 or .38, so that's likely.
[00:56] <rlameiro> rcn-ee: well i went to test it on the Tv and it passed after the "hang" place
[00:56] <GrueMaster> rcn-ee: Not sure if we will have 1 kernel to rule them all by then.  I know there is active work going on in devicetree, but not sure on status.
[00:56] <rcn-ee> cool rlameiro that was quick.. ;)
[00:56] <persia> GrueMaster, one kernel to rule all omap != one kernel to rule all armel
[00:56] <GrueMaster> Oh.
[00:56] <rlameiro> but then the screen changed to black with a coursor blinking at the top right corner
[00:56] <rcn-ee> probally not, but one omap kernel atleast. ;)
[00:57]  * GrueMaster gives up for the day on beagleXM.  5 reinstalls on three different SD cards, 5 different failures, none reproducible.
[00:57] <persia> Now, for linux 3.0, one of the goals should be a single build that works on every architecture.
[00:58] <GrueMaster> that would be...interesting.
[00:58] <GrueMaster> Maybe if they shift the code to java?
[00:58] <persia> Yep.  Think about the board initialisation detection phase :)
[00:58] <rcn-ee> GrueMaster, random... a1 by chance?
[00:58] <GrueMaster> This is a premee.  P8 board.
[00:58] <rcn-ee> what 'mpurate=xx' are you using?
[00:59] <rcn-ee> did you set mem=256 on boot?
[00:59] <GrueMaster> It worked fine before.  With this image.
[01:00] <rcn-ee> on my pre production boards, i had to limit them to 800mzh with "mpurate=800" and the first 256 of the 512 of memory...
[01:00] <GrueMaster> I usually don't muck with the bootargs, except to add serial console.
[01:02] <rcn-ee> i muck with them all the time.. ubuntu could get a 'unfair' speed bump from lucid to maverick by bumping from the default 500mhz to 720 on the c4's like the part is designed ;)
[01:02] <GrueMaster> What I am seeing is that sometimes it will boot to gdm before oem-config runs, sometimes parts of oem-config will crash.  Nothing consistant, which suggests memory issues.  Nothing on the serial console.
[01:02] <rlameiro> rcn-ee: you make boards?
[01:03] <rcn-ee> sometimes.. (i didn't make the beagle thou)... i do work at a place that sells them.. ;)
[01:03] <GrueMaster> My job is to test the images as they are.  I usually don't have time to muck with out-of-image settings.
[01:03] <rcn-ee> which is perfectly allright and better for the end customer
[01:04] <rcn-ee> but once the voltage scalling patches hit mainline, we need to bump the xm from 500mhz to 1Ghz.. ;)
[01:05] <GrueMaster> Speed is good.
[01:05] <GrueMaster> I'd like to see them run at a more usable pace.
[01:09] <GrueMaster> (at least it would fail faster).  :P
[01:13]  * GrueMaster thinks 10 hours is enough work for one Friday and wanders off to find a beer.
[10:40] <ogra_cmpc> wohoo !
[10:40]  * ogra_cmpc managed to get root on the toshiba ac100
[10:49] <zyga> ogra_cmpc, how did you do it?.
[10:49] <ogra_cmpc> there is a tool called rageagainstthecage
[10:49] <zyga> ;D
[10:49] <zyga> good name
[10:50] <zyga> ogra_cmpc, nice machine, it has 0.5GB of memory
[10:50] <ogra_cmpc> copying that to a partition thats not mounted noexec, running it in a shell will get you a rootshell in the next terminal app you opwn
[10:50] <zyga> ogra_cmpc, how much did you pay for it?
[10:50] <ogra_cmpc> nearly 400euro
[10:51] <zyga> ogra_cmpc, ouch! how long does the battery last?
[10:52] <ogra_cmpc> 7-8h undr android
[10:52] <ogra_cmpc> over 100h in standby
[10:52] <ogra_cmpc> (according to the docs)
[10:53] <persia> That means ~6 hours under Ubuntu, I'd suggest, based on similar claims from similar hardware I've run Ubuntu on.
[10:53] <zyga> ogra_cmpc, what SoC does it use?
[10:53] <persia> 100h is time in sleep, which is nice, but...
[10:54] <ogra_cmpc> zyga, tegra 250
[10:54] <ogra_cmpc> dual core a9
[10:55] <zyga> O_O
[10:55] <zyga> wow
[10:55] <zyga> that's a beast
[10:55] <zyga> ogra_cmpc, but no neon, right?
[10:55] <ogra_cmpc> sadly less ram than the dev board
[10:55] <ogra_cmpc> no neon but at least nvidia offers binary #d drivers
[10:55] <persia> Is it expansible?
[10:56] <ogra_cmpc> 3D
[10:56] <ogra_cmpc> no, its a SoC
[10:56] <ogra_cmpc> probably solderable
[10:57] <zyga> ogra_cmpc, is ram POP or separate on the board?
[10:58] <zyga> ogra_cmpc, did you hear about that guy that installed android on the iphone 2G?
[10:59] <zyga> ogra_cmpc, I have a spare 2G that nobody uses and I though I could try that, and if it works, try to rebuild the stack with linaro toolchain
[10:59] <zyga> ogra_cmpc, if _that_ would work then we would, kind of, have linaro on the iphone ;-) which is very cool :-)
[11:00] <persia> Bah.  No keyboard.
[11:00] <zyga> persia, iphone?
[11:00] <zyga> persia, yeah but you get serial
[11:00] <zyga> persia, and running android is probably usable enough
[11:00] <zyga> persia, for a web tabled of sort
[11:00] <ogra_cmpc> everzthing on the board is soldered on directly
[11:00] <ogra_cmpc> includiong the eMMC
[11:01] <persia> zyga, No little trackball: doesn't that break something?
[11:01] <zyga> persia, huh? I have no idea what you are talking about
[11:02] <zyga> persia, are you talking about ac100?
[11:04] <persia> I thought android UI required a little trackball (having seen lots of touchscreen devices with little trackballs in unusable positions),  That said, I don't actually care much (my interest is only in having consumer HW that runs Ubuntu: especially HW that I can take off my desk.
[11:04] <zyga> persia, ah
[11:04] <zyga> persia, no, you don't need that
[11:04] <zyga> persia, it works quite fine on all samsung phones that don't have that
[11:05] <persia> Ah, OK.  Wonder why it's stuck in the middle of the device right against the hinge in a bunch of the 4" clamshells at the shops.  Poor Human Interface design, and if it's not required, kinda pointless.
[11:07] <zyga> persia, probably because it's good for hitting links on websites on crappy first get touchscreens
[11:08] <persia> zyga, Come and see: it's not usable if you have either large fingers or long fingernails.  After seeing, look at the hands of Japanese consumers ...
[11:09] <zyga> persia, yeah, I never said it's perfect, but without it the first android devices would likely suck more
[11:09] <persia> Anyway, not important.  Most of them have only moderate-spec processors, etc.
[11:09] <zyga> persia, /me wants to go to japan :P
[11:09] <persia> And now you have an excuse: critical research on human interface design :)
[11:10] <zyga> persia, next I need a business reason for expenses ;-)
[14:14] <naveenpenda> hi all i am new in gtk programming..
[14:15] <naveenpenda> i just started small program for button click
[14:15] <naveenpenda> how i will know which gtk version is installed in my ubuntu ?
[15:46] <naveenpenda> is this package can be installed llibgtk2.0-dev and used in any ubuntu-arm? any help is appreciated
[22:51] <rlameiro> persia: are you there?
[23:05] <persia> http://git.chris-lamb.co.uk/?p=contentless-ping.git;a=summary
[23:15] <rlameiro> persia: found issues with jackd /qjackctl on my igepv2
[23:16] <persia> What issues?  Have you filed the bug?
[23:17] <rlameiro> not yet
[23:17] <rlameiro> first of all, pd has some issues with the alsa drivers wit it, so it needs to run over oss backend
[23:18] <rlameiro> also trying to run qjackctl over ssh with X tunnel i could see that it couldnt lock memory or something, then it crash,
[23:18] <rlameiro> also it gaves a error saying it doesnt find alsa midi devices
[23:19] <rlameiro> it shouldnt be a showstopper...
[23:20] <rlameiro> rebooting now to see if it is the problem
[23:21] <persia> OK.  Sounds to me like the issue is with alsa, and JACK is just having a hard time because of that.
[23:21] <persia> My recommendation would be to troubleshoot with aplay and arecord until you have working alsa, and *then* chase pulse.
[23:22] <rlameiro> persia: it plays with asound
[23:22] <rlameiro> that was already reported on pd community
[23:22] <rlameiro> http://puredata.info/docs/developer/BuildingPdForBeagleboard
[23:22] <persia> I suspect you can sort this with amixer, and if you file a bug with the exact amixer calls required along with the regular sound information script output, it becomes possible to fix the kernel so that you don't need the amixer calls.
[23:23] <rlameiro> i have sound, and unmutted the mixers
[23:24] <persia> But when you use `pd -alsa` you get the horrid sound?
[23:25] <rlameiro> cracles
[23:25] <rlameiro> yes
[23:26] <rlameiro> i dont have a way to know what isnt working on the alsa driver
[23:26] <persia> Would you file a bug about that with `ubuntu-bug puredata` and include a sound sample generated on your machine?
[23:26] <rlameiro> i just know that puredata can sync the ADC
[23:27] <rlameiro> I can try :D
[23:27] <persia> Because there's either an ALSA bug or some PD bug, and randomly switching to use PD-over-OSS-over-ALSA doesn't even begin to address it, nor does that help for other things affected.
[23:27] <rlameiro> but i dont know if it is a puredata bug
[23:27] <rlameiro> i think is alsa
[23:28] <persia> Let's file it, and the testcase against puredata right now.
[23:28] <rlameiro> ok
[23:28] <persia> I think mpoirer was looking at audio issues for the omap kernels (although I'm sure he'd like help), so he might appreciate another testcase.
[23:29] <persia> That is does work with the OSS backend makes me think it is ALSA, but it's exposed in PD, so it could also be something related to the PD porting.
[23:31] <rlameiro> well it may be, but pd is a lot more demanding over the audio backends
[23:31] <rlameiro> it demands accurate thing sync etc
[23:32] <rlameiro> Im installing midori now to file the bug
[23:33] <rlameiro> persia: do you know a easy way to record the audio output of a programm over the command line?
[23:33] <rlameiro> something like piping?
[23:33] <persia> No, but.
[23:34] <persia> So, if you have the sort of audio hardware that is on the beagle, you can't: anything that claims to do that will capture the audio *before* it gets processed by the hardware.
[23:34] <rlameiro> well then i need to make it old school then :D
[23:35] <rlameiro> pipe it with real copper to my laptop :D
[23:35] <persia> If you have an audio interface that exposes monitor channels, you can record the monitors to see what was playing, but this means two passes through the drivers, so isn't useful to test the drivers in isolation.
[23:35] <persia> Yes :)