=== XorA is now known as XorA|gone
[01:34] <persia> Yes!  kde4libs has made it to the install stage!
[01:39] <GrueMaster> Sweet.
[01:39] <GrueMaster> What are you building on?
[01:44] <persia> cushaw
[01:44] <persia> https://launchpad.net/ubuntu/+source/kde4libs/4:4.5.1-0ubuntu5/+build/1961555
[01:44] <persia> I think it's a Babbage 3.0, but that's guessing based on IRC traffic.
[01:46] <tommd> I have Alpha 1 (for 10.10) on my Touchbook but it seems to want a password - is there a default?
[01:47] <persia> tommd, How did you install?
[01:47] <tommd> persia: With dd (https://wiki.ubuntu.com/ARM/OMAPMaverickInstall)
[01:48] <GrueMaster> tommd: You should be able to boot and it should run oem-install on it's own.
[01:48] <GrueMaster> Where did you get the image?
[01:49] <persia> tommd, An image from http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/ ?
[01:49] <tommd> GrueMaster: It didn't.  Is this a result of me using the AI kernel (not the default Ubuntu/Maverick alpha kernel)
[01:49] <tommd> no
[01:49] <tommd> persia: http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/10.10/beta/
[01:49] <tommd> oops, yes
[01:49] <tommd> ;-)
[01:49] <persia> OK.
[01:49] <persia> Where are you seeing the username prompt?
[01:50] <tommd> Its an X login prompt
[01:50] <GrueMaster> If you are using a custom kernel and not the provided initrd, it will fail.
[01:50] <tommd> It's off now and I'm just replacing the /etc/shadow.
[01:50] <persia> Hrm.  I wonder if there are odd board-support issues.  That oughtn't happen.
[01:50] <tommd> GrueMaster: Ah.  How is the kernel involved in first-boot setup?  I would have thought this as something user space + a flag/file.
[01:51] <persia> the kernel has to have the right modules enabled, and the initrd needs to have the right code to set stuff up for the first-boot experience.
[01:51] <persia> So an arbitrary kernel/initrd ends up connecting to a half-installed system, which doesn't work.
[01:51] <GrueMaster> There are a couple of scripts that run from initrd, one that resizes the image to fill the Sd card, the other to do some minor tweaks, like triggering oem-install to run.
[01:52] <GrueMaster> The scripts are part of the jasper-intramfs package.
[01:52] <persia> tommd, If you must replace the kernel, try not replacing the initrd (as risky as this is).
[01:52] <persia> I have a low confidence in that solution.
[01:53] <persia> Next, try booting into some other working environment, and mounting the half-installed system as a chroot, and rebuilding the initramfs inside that, and then extracting that for use.
[01:54] <persia> ideally, determine what part is failing, and file some bugs so that the touchbook can be supported in the future (although with that RAM and IO, I fear it will never be well supported)
[01:54] <tommd> Perhaps I can just go with the custom mlo
[01:55] <tommd> and the Ubuntu kernel... though I bet that won't have much of the hardware supported.
[01:57] <persia> tommd, It's mostly a mainline kernel: does mainline support the touchbook yet?
[01:57] <tommd> Not really.  There are a couple issues (accelerometer, I think... some people made noise about the screen)
[01:57] <tommd> I'm going to try though
[01:57] <persia> Once you complete the rootfs install, you can probably swap kernels without such poor results.
[01:58] <tommd> ok,  I'm giving it a go
[01:58] <tommd> owch
[01:58] <tommd> ugly screen.
[01:59] <persia> Which one?
[01:59] <tommd> Its a somewhat long story - basically my NAND is a bit screwed up so I need an mlo/u-boot that doesn't use the NAND settings.
[01:59] <tommd> The latest AI u-boot is sufficient.
[02:00] <tommd> And it seems trying to boot the 10.10 kernel with the other mlo/u-boot was a bad idea.
[02:00] <persia> Unfortuantely, it seems that uboots are even more sensitive to board changes than kernels.
[02:00]  * persia wants EFI+grub last year more
[02:00] <tommd> yeah, I don't know much about u-boot other than I'm unhappy when I hear it said.
[02:26] <Neko> is there a big package update going on or something?
[02:26] <Neko> I can't install gnome desktop, smbclient requires samba-common of a very exacting version but the one in the pool is one version better than the smbclient wants
[02:27] <persia> Final Freeze was 8.5 hours ago.
[02:27] <persia> Lots of folks pushed to the hard limit for their uploads, so the queues got huge.
[02:28] <Neko> okay it's just I noticed this:
[02:28] <persia> Should be sorted in ~30 hours.
[02:28] <Neko> [ ]	samba-common_3.5.4~dfsg-1ubuntu6_all.deb	16-Sep-2010 07:05 	386K	
[02:28] <Neko> [ ]	samba-common_3.5.4~dfsg-1ubuntu7_all.deb	16-Sep-2010 21:04 	385K	
[02:28] <Neko> .. the build times are less than 14 hours apart... which is freakish
[02:28] <Neko> 30 hours is a long time to wait for the counterpart packages :]
[02:30] <persia> https://launchpad.net/ubuntu/maverick/armel/+builds?build_text=&build_state=pending is the list of stuff needing building and the order in which it will build.  LP guesses about times, but isn't usually that far off.
[02:31] <Neko> times? you mean the numbers like 1755, 2505?
[02:31] <Neko> minutes or seconds?
[02:35] <Neko> oh the links tell you an hours.. and it says 16 at least
[02:35] <Neko> oh well
[02:35] <Neko> back in a bit
[03:13] <tommd> The TouchBook has lots of custom bootargs in the NAND.  Not sure how this compares to the BeagleBoard.  Should I wipe out the bootargs and try the Ubuntu kernel or should they remain?
[03:15] <rcn-ee> tommd, last i checked the default ubuntu kernel only has what mainline support exists for the touchbook.. which isn't much, including no screen...
[03:17] <tommd> rcn-ee: Thanks, I had thought the screen made mainline.  Shows what I know.  This explains why I'm not getting any stdout...  and I thought the kernel wasn't getting loaded.
[03:18] <tommd> not really any (easy) way to get it to configure then, huh?  No screen with Ubuntu.  No initrd (no Ubuntu initrd) with the AI kernel.  argh
[03:19] <rcn-ee> tommd, i just happen to be working on it myself too..  other then the dss2 stuff nothing is too useful for end users yet.. http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6.36-devel/files/head:/patches/touchbook/  (slowlying syncing with touchbook's git tree..)
[03:19] <persia> Do you have any working armel environments?
[03:19] <persia> If so, you ought be able to reconstrut the Ubuntu initrd in a chroot.
[03:20] <tommd> persia: I had a working OE setup and I have the TB working in conjunction with the AI kernel (and an older Ubuntu)
[03:20] <tommd> That's it.
[03:21] <tommd> The AI Kernel doesn't use an initrd, so I'd need to modify that slightly to begin with.
[05:35] <GrueMaster> tommd: Well, you could get a copy of jasper-initramfs and read what the scripts do.  Then apply them manually to an SD card prior to booting.
[07:05] <avinashhm> hi , can we mount a directory like this .. "mount -t nfs /sys/kernel/debug/pm_debug/ /avinash/"
=== hrw|gone is now known as hrw
[08:28] <hrw> morning
[08:33] <lag> ogra: Do you have sound working on your 6/8 layer?
[08:33] <lag> mopdenacker: What about you?
[08:34] <lag> prpplague: Are you around still?
[08:50] <lag> ...
[08:50] <ogra> lag, not with the default setup, no
[08:50] <ogra> (8 layer)
[08:50] <lag> Do you have it working at all?
[08:51] <lag> Even with the hacky files?
[08:51] <ogra> i dont fiddle with it, so no
[08:51] <lag> :(
[08:51] <lag> Okay
[08:51] <ogra> let me add the files and see
[08:51] <lag> I need someone to do some tests
[08:51] <ogra> what was the bug# ?
[08:51] <lag> That would be great
[08:51] <lag> bug 637947
[08:51] <ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 12)" [High,Confirmed] https://launchpad.net/bugs/637947
[08:55] <lag> Let me know if you get sound working
[08:56] <ogra> rebooting
[08:56] <lag> :)
[08:57] <ogra> its the bottom plug, right ?
[08:57] <lag> Apparently
[08:58] <ogra> i hear farting sounds ... and pops when the amp goes on and off
[08:58] <ogra> oh, wait, i forgot the daemon.conf
[08:58]  * ogra reboots again
[08:59] <lag> How did you test?
[08:59] <lag> Command please
[08:59] <ogra> none, i rebooted
[08:59] <ogra> expecting the login sound
[08:59] <lag> Oh, I see
[09:00] <ogra> aha
[09:00] <ogra> sounds were disabled by default
[09:00] <ogra> enabling them gets me the login sound with distrotion
[09:01]  * ogra reboots again to hear
[09:02] <ogra> yep, works
[09:03] <ogra> but i always get the farting sound if it initializes
[09:05] <ogra> dropping the daemon.conf changes still gets me sound
[09:05] <ogra> so they are not urgetnly needed it seems
[09:06] <ogra> oh, fun, my USB didnt initialize this time
[09:06] <ogra> (no NIC, no kbd/mouse)
[09:11] <ogra> lag, so i obviously need the default.pa and the amixer hacks to make it work, it works fine with the original daemon.conf
[09:12] <ogra> but initializing the HW is very noisy (popping and farting sounds)
=== amitk is now known as amitk-afk
[09:22] <neil_d> I am looking for a ARM board with SATA...
[09:22] <ogra> good luck :)
[09:25] <ogra> lag, commented on the bug
[09:25] <ogra> seems there are a lot unneeded changes in default.pa
[09:25] <ogra> bah
[09:26] <dmart> lool: ping
[09:27] <lag> ogra: It looks like I had network problems - did you get back to me?
[09:27] <ogra> yep
[09:27] <lag> And?
[09:27] <ogra> lag, commented on the bug, there are many pointelss changes in default.pa
[09:27] <ogra> all i need are the three lines i pasted there plus the amixer hack
[09:28] <ogra> and no changes to daemon.conf at all
[09:28] <lag> What application plays the login sound?
[09:28] <ogra> gnome-session i think
[09:28] <dmart> ogra: actually, you can probably answer my question too
[09:29] <ogra> dmart, lets try :)
[09:29] <lag> ogra: Do this: aplay -Dplughw:0,0 /usr/share/sounds/ubuntu/stereo/desktop-login.wav
[09:29] <dmart> ogra: quick one: it seems that the libmad fix works - someone got a good test result
[09:29] <dmart> ogra: should I submit a merge request, and who's the appropriate maintainer?
[09:29] <dmart> s/maintainer/approver/
[09:30] <ogra> dmart, it would have to be a final freeze exception, not sure we'll get it in
[09:30] <ogra> final freeze is in effect since yesterday ... i think the release team needs to approve
[09:30] <ogra> lag, /usr/share/sounds/ubuntu/stereo/desktop-login.wav: No such file or directory
[09:30]  * ogra goes to look for a wav
[09:31] <ogra> lag, aplay -Dplughw:0,0 /usr/share/sounds/speech-dispatcher/dummy-message.wav hangs
[09:31] <ogra> (with my setup though)
[09:31] <dmart> ogra: since you have a workaround in place, it can go in post-release... is there a development branch, or do we just have to hold off merging it until natty gets created?
[09:32] <mopdenacker> lag: I don't have my Panda any more :-(
[09:32] <lag> mopdenacker: :(
[09:32] <ogra> dmart, reopen, mark it as ubuntu-later (as milestone) and turn the bug into an SRU request
[09:33] <ogra> https://wiki.ubuntu.com/StableReleaseUpdates for more info
[09:33] <ndec> ogra: hi! where is our daily ? ;-)
[09:33] <ogra> ndec, waiting for the qeue to settle
[09:33] <ndec> ogra: argh...
[09:33] <lag> ogra: Do this: aplay -Dplughw:0,8 /usr/share/sounds/speech-dispatcher/dummy-message.wav
[09:33] <ogra> ndec, https://edge.launchpad.net/builders
[09:33] <ogra> ndec, armel 19h behind
[09:34] <ogra> lag, one sec, my ssh console hangs since the last command
[09:34] <dmart> ogra: > turn the bug into an SRU request
[09:35] <dmart> ogra: how does that work?
[09:35] <ogra> dmart, right
[09:35] <ogra> dmart, https://wiki.ubuntu.com/StableReleaseUpdates for more info :)
[09:35] <dmart> aha :) thanks ogra
[09:35] <ogra> dmart, or more detailed https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[09:36] <ogra> lag, i think i have to reboot ... while the mouse moves still the system got unresponsive
[09:37] <ogra> ndec, sadly thats normal after a freeze, there were 100s of uploads the last two days
[09:37] <ndec> ogra: until we give you bunch of panda ;-)
[09:38] <ogra> ndec, yeah, i want 50 !
[09:38] <ogra> or one for each package in main ... not sure yet :P
[09:38] <lag> ogra: ndec: I am fast coming to the conclusion that my board is incapable of sound
[09:38] <ndec> lag: 6 or 8 layer?
[09:38] <ogra> lag, thats bad
[09:38] <lag> 6
[09:38] <ogra> didnt you have sound yesterday for a while ?
[09:38] <lag> I'd love to work on this bug, but I need a board that can cope :(
[09:39] <lag> Only via HDMI
[09:39] <lag> I still have sound via HDMI
[09:39] <ogra> did you have the speaker output in the sound prefs then ?
[09:39] <lag> Sorry?
[09:39] <ogra> well, HDMI should suffice for hacking on the driver
[09:39] <lag> No, the HDMI works
[09:40] <ogra> right
[09:40] <lag> Even without the file hacks
[09:40] <ogra> so you could work on this
[09:40] <ogra> oh
[09:40] <ogra> k
[09:40] <lag> aplay -Dplughw:0,6 /usr/share/sounds/speech-dispatcher/dummy-message.wav
[09:40] <lag> That will _always_ work
[09:40] <ogra> hangs my board here
[09:40] <lag> Not hanging, playing?
[09:41] <ogra> not here
[09:41] <lag> Mine plays the robot voice
[09:41] <ogra> well, as you see above my board hung by it
[09:42] <lag> Oh, you may need the high res timers
[09:42] <lag> Hang on, I'll send you my kernel
[09:42] <ogra> in the kernel ?
[09:42] <ogra> i should be able to dist-upgrade to it
[09:42] <ogra> afaik the binary is in the archive
[09:42] <ogra> one sec
[09:42] <lag> Since my commit?
[09:43] <ogra> linux-ti-omap4 (2.6.35-903.12) maverick; urgency=low
[09:43] <ogra>   [ Lee Jones ]
[09:43] <ogra>   * [Config] Enable CONFIG_HIGH_RES_TIMERS=y
[09:43] <ogra> ...
[09:43] <lag> That's the badger
[09:46] <ogra> that will take a while ...
[09:46]  * ogra goes afk for a moment
[09:47] <lag> Dear TI,
[09:47] <lag> Please send me a 8 layer ES2.0 pandaboard
[09:47] <lag> as soon as possible. I would love to fix
[09:47] <lag> your audio issues, but I'm finding it hard
[09:47] <lag> without working hardware.
[09:48] <lag> Kind regards,
[09:48] <lag> Lag
[09:48] <hrw> ;)
[09:48] <lag> :D
[09:48] <hrw> lag: I heard that at the end of month there will be next set of boards shipped to people
[09:48] <lag> \o/
[09:49] <hrw> who will get them? no idea
[09:50] <ndec> lag: ;-)
[09:50] <ndec> lag: i think HDMI does not work out of the box. i am surprised by your conclusion.
[09:51] <ndec> lag: do you confirm that flashing 20100914, booting and running the aplay command without any other config works?
[09:56] <lag> ndec: I will flash a new card and tell you
[09:58] <lag> dd'ing
[09:58] <lool> dmart: pong
[10:14] <ogra> lag, bah, no login sound anymore with your kernel
[10:15] <ogra> well, with the upgrade from the archive
[10:15] <lag> Interesting
[10:16] <lag> What if you apply the hacky files again?
[10:16] <lag> And run the *.sh
[10:16] <ogra> geez !
[10:16] <ogra> and about 500 kerneloops popups on the desktop
[10:16]  * ogra clicks madly 
[10:16] <ogra> lag, which .sh ?
[10:17] <lag> omap4*.sh
[10:17] <ogra> whats that ?
[10:17] <lag> The one you ran to get sound working
[10:17] <ogra> is that different from the amixer hack stuff ?
[10:17] <lag> The amixer hacks
[10:17] <lag> No
[10:17] <ogra> ah, its in rc.local
[10:18] <ogra> i'm lazy ... runs automatically on boot
[10:18] <ogra> hmm, hangs again
[10:18] <ogra> (without doing anything)
[10:19] <ogra> i'm starting to think that this amixer carp is at fault
[10:19] <ogra> *crap
[10:19]  * ogra wanted to at least see dmesg for all the oopses :(
[10:20] <lag> ndec: I _can_ confirm that HDMI sound works out-of-the-box
[10:20] <lag> ogra: How do you mean 'hangs'?
[10:20] <lag> Does the screen go black?
[10:22] <ogra> no, i was greeted with a ton of kerneloops messages on the desktop ... klicked them away ...
[10:22] <ogra> then logged in via ssh
[10:22] <ogra> (to easier get to the logs)
[10:22] <ogra> talked to you here
[10:22] <ogra> switched to ssh terminal and noticed it hangs
[10:23] <ogra> switched to omap desktop, clicked on terminal ... desktop hangs, mouse still moves
[10:23] <ogra> but i seem to be able to switch consoles, i got the dmesg
[10:23] <ogra> desktop hangs completely now though
[10:25] <ogra> lag, http://paste.ubuntu.com/495172/ my dmesg has several 100s of these now
[10:25] <lag> I still receive the GPU hang _a lot_
[10:25] <ogra> and this one at the end http://paste.ubuntu.com/495174/
[10:26] <lag> Yeah, that doesn't look good
[10:26] <ogra> right
[10:27] <ogra> let me restore the configs to default
[10:27] <ogra> and see whats there after reboot
[10:28] <ogra> rebooting
[10:28] <lag> I'm not testing sound with the kernel from the 14th
[10:28] <lag> Without High Res' Timers
[10:29] <ogra> well, i'm running the lkatest from the archive now
[10:29] <ogra> i just want to make sure the oopses dont show up without the amixer crap
[10:29] <lag> I get this: http://paste.ubuntu.com/495177/
[10:30] <ogra> funny, i have the farting sound even without amixer stuff
[10:30] <ogra> lag, yeah, seems i have both too
[10:30] <lag> And that's with the straight 14th kernel
[10:31] <ogra> http://paste.ubuntu.com/495178/
[10:31] <lag> With default.pa and the script run
[10:31] <lag> But still no sound
[10:31] <ogra> fresh boot (right after booting)
[10:31] <ogra> with all ubuntu defaults restored
[10:31] <ogra> now thats worrying
[10:32] <ogra> sigh !
[10:32] <ogra> and a kerneloops message on the desktop for every line there
[10:33] <lag> How did you restore the defaults/
[10:33] <lag> ?
[10:33] <ogra> cp
[10:33] <ogra> and disabling amixer.sh in rc.local
[10:33] <ogra> oh, sweet!
[10:33] <ogra> i see audio HW in the sound prefs
[10:34] <lag> Aren't the amixer settings persistent?
[10:34] <ogra> even without these files
[10:34] <lag> You do?
[10:34] <ogra> yes
[10:34] <lag> Oh yeah, me too!
[10:34] <ogra> hmm, might be that the mixer settings are persistent
[10:34] <lag> They are
[10:34] <ogra> sigh...
[10:34] <lag> I think they're persistent
[10:34] <lag> Hence why I was shocked that you had them in .local
[10:34] <ogra> so i need a new image (which we wont have until tomorrow)
[10:35] <ogra> to see the defaults
[10:35] <lag> Or reflash 14
[10:35] <lag> Or reflash 14 and apply the new kernel
[10:35] <ogra> this is my development setup
[10:35] <ogra> i dont really want to trash it
[10:36] <ogra> (takes half a day to restore all the build env and chroots)
[10:36] <ogra> let me look for another SD
[10:36] <ogra> argh ... and i only have 0915 here
[10:36] <lag> I am missing HDMI from Output though
[10:36] <lag> In sound perfs
[10:37] <ogra> yes, thats only provided by the default.pa
[10:37] <lag> But I am using default.pa
[10:37] <ogra> the one from TI ?
[10:37] <ogra> or ours
[10:37] <lag> Oh, no I'm not
[10:37] <lag> I saved it as default.pa.new
[10:37] <ogra> you effectively only need to add the three lines i posted on the bug
[10:37] <lag> Let me try it with our one
[10:38] <ogra> they shoudl give you all devices and not disable essential services like udev
[10:38] <ogra> or consolekit (thats a really bad one, not sure why TI added that)
[10:39] <lag> Okay
[10:39] <lag> I'll do that
[10:39] <lag> Do you get audio now?
[10:39] <ogra> no
[10:39] <ogra> i get the "farting" on boot
[10:39] <lag> Then you need to find out what changed
[10:39] <ogra> which i guess comes from alsa restoring the mixer stuff
[10:39] <lag> Yeah
[10:39] <ogra> what changed is that i restored the original pulse config
[10:39] <lag> Change it back
[10:40] <lag> Try to get sound again
[10:40] <lag> With the new kernel
[10:40] <ogra> i wont
[10:40] <ogra> it will kill the kernel
[10:40] <ogra> err, the desktop
[10:40] <lag> We need to find out why you no longer get sound
[10:41] <ogra> i switched back to my hacked default.pa and am rebooting now
[10:41] <ogra> but i get the oopses in both cases with the new kernel
[10:42] <ogra> aha
[10:42] <ogra> login sound with some distrotion
[10:42] <ogra> usual oopses in dmesg
[10:42] <ogra> and additionally ...
[10:43] <ogra> [   51.534149] asoc: interface MultiMedia1 hw params failed
[10:43] <ogra> 5 lines of that at the end
[10:43] <ogra> oh !
[10:43] <lag> Okay, but the sound is there?
[10:43] <lag> oh?
[10:43] <ogra> in the sound prefs i have two input and three output devices now
[10:44] <ogra> instead of one input and two output which i should have
[10:44] <lag> Lucky you :)
[10:44] <lag> What happens when you "Test speakers"
[10:45] <lag> I have loads of stuff in Sound Perfs now
[10:46] <ogra> sigh, clicking around in sound prefs a bit hangs the desktop again
[10:46] <lag> [  156.123229] [<c005b9a0>] (omap_mcbsp_write+0x8/0x18) from [<c005bf90>] (omap_mcbsp_config+0x48/0x128)
[10:47] <lag> After changing to HDMI and clicking "Test speakers"
[10:47] <lag> ogra: I want you to do something for me
[10:48] <lag> ogra: It may take 10 mins and a few reboots
[10:48] <ogra> ok
[10:48] <ogra> my board hangs hard now btw
[10:48] <ogra> no console switching, no mouse movement
[10:48] <lag> for i in 0 1 2 3 4 5 6 7 8 9; do aplay -Dplughw:0,$1 /usr/share/sounds/speech-dispatcher/dummy-message.wav; done
[10:49] <lag> But you have to do it manually
[10:49] <lag> That script won't work
[10:49] <ogra> k
[10:49] <ogra> i'll try that
[10:49] <lag> The script?
[10:49] <lag> You won't
[10:49] <lag> Oh, wait
[10:49] <lag> It might
[10:49] <ogra> i'm pretty sure only 0,0 and 0,7 have attached output devices
[10:50] <lag> No, this is ALSA
[10:50] <ogra> (since thats what is defined in default.pa)
[10:50] <ogra> yes
[10:50] <lag> default.pa is Pulse
[10:50] <ogra> the pulse config applies to the alsa stuff
[10:50] <lag> That's at a higher level?
[10:50] <ogra> device=hw:0,0
[10:50] <ogra> means pulse uses this exact alsa device
[10:51] <ogra> and the three lines i have in default.pa define device=hw:0,0 device=hw:0,7 and device=hw:0,2
[10:51] <ogra> 0,2 for input
[10:52] <ogra> they need to correspond to -Dplughw:0,7 and -Dplughw:0,0
[10:52] <ogra> else i wouldnt have sound at all
[10:52]  * ogra waits for the reboot to be done
[10:53] <lag> Then why does -Dhw:0,6 work for HDMI out of the box?
[10:53] <ogra> because the default.pa entries are wrong ?
[10:53] <lag> Which ones?
[10:54] <ogra> the ones provided by ti
[10:54] <lag> Nope, out-of-the-box
[10:54] <ogra> aplay -Dplughw:0,0 /usr/share/sounds/speech-dispatcher/dummy-message.wav works
[10:55] <ogra> ogra@panda:~$ aplay -Dplughw:0,7 /usr/share/sounds/speech-dispatcher/dummy-message.wav
[10:55] <ogra> aplay: main:654: audio open error: Device or resource busy
[10:55] <lag> With TI's files and *.sh?
[10:55] <lag> Try 6
[10:55] <ogra> geez !!!
[10:55] <lag> ?
[10:55]  * ogra tried 0.2
[10:55] <ogra> that closed my ssh
[10:56] <lag> 0,2 is input
[10:56] <lag> :)
[10:56] <ogra> and hung the board hard
[10:56] <ogra> still, that shouldnt hang hard
[10:56]  * ogra reboots
[10:56] <lag> You just tried to play a track down an input :)
[10:56] <ndec> ogra: lag: hdmi is 0,6 on current kernel, and is moved to 0,7 on the future kernel. lag is probably using the latest serie of patches from sebjan. but what is in the archive today is different
[10:56] <ogra> and ?
[10:56] <lag> I told you there may be some inputs
[10:56] <ogra> still, if i send anything to a device that shouldnt hang the board
[10:57] <lag> s/inputs/reboots
[10:57] <ogra> spill an error is fine, but hard hang isnt
[10:57] <lag> Nope, but we can sort that out another time
[10:57] <ogra> yes
[10:57] <lag> I'm fairly sure my board is INCAPABLE of sound now :(
[10:57] <lag> Not a dicky-bird
[10:57] <lag> :(
[10:57] <ogra> you just sounded above like it would be acceptable to hang it :)
[10:58] <lag> It's none of my concern - yet
[10:58] <ogra> k
[10:59] <ogra> so 0,0 and 0,6 work
[10:59] <ogra> 0,7 has no device attached
[10:59] <lag> I might try to work on these scheduling while atomic bugs until I receive a working board
[10:59] <ogra> likely because of what ndec said above
[10:59] <lag> Yes
[10:59] <lag> 0,0 do not work for me
[10:59] <ogra> any other mnumbers you want me to try ?
[11:00] <lag> No, but I would like you to do one more thing for me
[11:00] <lag> I think I know the answer, but I'd like to try in any case
[11:00] <ogra> go
[11:01] <lag> Do you have any way of flashing a fresh 14?
[11:01] <lag> Spare cards etc
[11:01] <ogra> i need to downgrade the image i have
[11:01] <ogra> i only have 15 here
[11:01] <lag> I thought 15 was broken?
[11:01] <ogra> which is totally broken (uninstallable)
[11:01] <ogra> right
[11:02] <lag> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100914/
[11:02] <ogra> dude !
[11:02] <ogra> i build them :P
[11:02] <lag> I know
[11:02] <lag> You're just lazy
[11:02] <lag> ;)
[11:02] <ogra> i'm zsyncing to the image to 14 now
[11:02] <lag> Do you want me to write you a script to flash your card too?
[11:02] <lag> :)
[11:03] <lag> zsyncing?
[11:03] <ogra> sure
[11:03] <ogra> takes just a few mins
[11:03] <ogra> since it only downloads the differences
[11:03] <ogra> 11min for 30% of the image apparently
[11:03] <lag> Never done that
[11:03] <ogra> 30% is a lot of changes for a day :)
[11:04] <ogra> i usually get 5% and 2min or so
[11:04] <ogra> lag, you should
[11:04] <ogra> its so much faster
[11:04] <ogra> and saves badwith too
[11:04] <ogra> *band
[11:05] <ogra> the only thing you need to take care of is that you keep the old img.gz around
[11:05] <ogra> then just call zsync <url to the zsync file>
[11:05] <ogra> i.e.
[11:05] <ogra>  zsync http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100914/maverick-preinstalled-netbook-armel+omap4.img.gz.zsync
[11:05] <ogra> in the same dir maverick-preinstalled-netbook-armel+omap4.img.gz lives
[11:06] <lag> I think I'll give it a miss
[11:06] <lag> My images download without me even knowing about it anyway
[11:06] <ogra> well, even your scripts will be faster using zsync :)
[11:06] <lag> :)
[11:07] <lag> It's a non-issue :)
[11:07] <ogra> it wastes bandwith canonical has to pay for
[11:08]  * ogra makes a note to talk to pete about lag's next bonus :P
[11:08] <lag> Lol - you goon!
[11:08] <ogra> heh
[11:08] <lag> I'll tell them to take off the £0.05p per week
[11:08] <lag> :)
[11:08] <ogra> heh
[11:09] <ogra> hmm, actually if i have to write an image anyway ... i always wanted to see if zcat to mmcblk0 works instead of dd
[11:09]  * ogra will try that
[11:09] <ogra> 4min to go ...
[11:09] <ogra> *twiddle*
[11:10] <lag> With what?
[11:10] <ogra> ?
[11:10] <ogra> the zsync
[11:11] <ogra> or do you mean what i twiddle ?
[11:11] <ogra> toes indeed
[11:11] <lag> ;)
[11:11]  * ogra has mselly feet and needs the fresh air
[11:11] <ogra> *smeally
[11:11] <ogra> bah
[11:12] <lag> Yuck!
[11:14] <ogra> zsync done
[11:17] <ogra> root@osiris:/var/build/images# zcat maverick-preinstalled-netbook-armel+omap4.img.gz >/dev/mmcblk0 ...
[11:17] <ogra> wow, that works
[11:17] <ogra> and puts a lot less load on my computer than dd it seems
[11:19] <ogra> i wonder if there is a sudo way
[11:19]  * ogra will try for the next write 
[11:20] <ogra> that should make our install instructions a lot easier
[11:22] <ogra> hmm, still running
[11:24] <ndec> ogra: sudo sh -C 'zcat xxx > /dev/mmcblkxx'
[11:24] <ogra> ndec, yeah
[11:24] <ogra> i was thinking about tee
[11:25] <ndec> ogra: zcat xxx | sudo tee /dev/mmcblk ?
[11:25] <ogra> indeed invoking a subshell will always work
[11:25] <ogra> no, that doesnt
[11:25] <ogra> tried that and then resorted to root to not make lag lag
[11:28] <ogra> ndec, so any idea why your default.pa switches off both module-detect lines and consolekit ? thats really superfluous
[11:28] <ogra> you really only need to add the sinks to make it work
[11:30] <ndec> ogra: i think it used to break, but that might have been with older kernel. berco is looking at this.
[11:31] <ogra> should be fine to just have a three line change
[11:31] <ogra> consolekit should definitely stay enabled
[11:32] <ogra> and module-detect wont do any harm since we define the sinks hardcoded anyway
[11:32] <berco> ogra: i'm gathering more internal information on this. From my experience, this line can be re-enabled
[11:32] <lag> ogra: Have you tried it yet?
[11:32] <ogra> berco, yeah, from my testing it doesnt change a thing (at least on panda)
[11:33] <ogra> lag, still waiting for oem-config to finish
[11:33] <berco> yeah, except we can get traces in syslog with this line :)
[11:33] <lag> k
[11:33] <lag> When you have it working, try the aplay commands on 0,0 and 0,6
[11:34] <ogra> lag, without any changes  to the system ?
[11:34] <lag> Correct
[11:34] <ogra> (old kernel, old pulse, no amixer hack)
[11:34] <ogra> k
=== amitk-afk is now known as amitk
[11:40] <ogra> ogra@panda:~$ aplay -Dplughw:0,0 /usr/share/sounds/speech-dispatcher/dummy-message.wav
[11:40] <ogra> aplay: main:654: audio open error: Invalid argument
[11:40] <ogra> ogra@panda:~$ aplay -Dplughw:0,6 /usr/share/sounds/speech-dispatcher/dummy-message.wav
[11:40] <ogra> Playing WAVE '/usr/share/sounds/speech-dispatcher/dummy-message.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono
[11:40] <ogra> lag ^^^
[11:40] <ogra> no output (due to missing amixer settings i guess)
[11:41] <ogra> but seems HDMI (0,6) is attached by default here
[11:42] <ogra> oh, intresting
[11:42] <ogra> ogra@panda:~$ aplay -Dplughw:0,4 /usr/share/sounds/speech-dispatcher/dummy-message.wav
[11:42] <ogra> Playing WAVE '/usr/share/sounds/speech-dispatcher/dummy-message.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono
[11:42] <ogra> ALSA lib pcm_params.c:2150:(snd1_pcm_hw_refine_slave) Slave PCM not usable
[11:42] <ogra> aplay: set_params:1031: Broken configuration for this PCM: no configurations available
[11:42] <ogra> seems there is something attached to 0,4
[11:43] <ogra> aha, and to 0,7 too
[11:44] <ogra> lag, does that help you ?
[11:44]  * ogra is brave and tries 0,2 again to see if the old kernel crashes too
[11:44] <ogra> doesnt :)
[11:44] <ogra> ogra@panda:~$ aplay -Dplughw:0,2 /usr/share/sounds/speech-dispatcher/dummy-message.wav
[11:44] <ogra> aplay: main:654: audio open error: Invalid argument
[11:45] <lag> Okay
[11:45] <ogra> oh, i take that back
[11:45] <lag> I wonder what ALSA does to connect 0,0
[11:45] <ogra> hangs now
[11:45] <lag> What kind of hang was it
[11:45] <lag> Check the logs
[11:45] <ogra> quiet hard lock
[11:46] <lag> Logs please
[11:46] <ogra> how ?
[11:46] <ogra> demsg will be gone after reboot
[11:46] <lag> I'm assuming you haven't glued your card into your machine?
[11:47]  * ogra nibbles on the glue to get ot out of the slot again
[11:47] <ogra> bah, you got me
[11:47] <lag> ;)
[11:48] <lag> omap_mcbsp_write?
[11:49] <ogra> http://paste.ubuntu.com/495222/
[11:49] <ogra> the end of syslog
[11:49] <ogra>  /var/log/dmesg has no errors
[11:50] <ogra> Sep 17 10:40:06 sycamore kernel: [  727.309112] Wrapper Enabled...
[11:50] <ogra> Sep 17 10:40:06 sycamore kernel: [  727.327941] Start audio transfer...
[11:50] <ogra> Sep 17 10:40:27 sycamore kernel: [  747.851928] Wrapper disabled...
[11:50] <ogra> Sep 17 10:42:14 sycamore kernel: [  855.361022] omap_device: omap-mcpdm-dai.-1: new worst case activate latency 0: 30517
[11:50] <ogra> thats the end of messages
[11:50] <ogra> (before there is only installer stuff)
[11:51] <lag> kernlog please
[11:51] <lag> kern.log
[11:51] <ogra> http://paste.ubuntu.com/495225/
[11:52] <ogra> nothing that sticks out there
[11:52] <ogra> (above that only hdmi init stuff and boot messages)
[11:54] <lag> Hmm
[11:55] <lag> You should provide yourself with a serial console and try again
[11:55] <ogra> bah, serial
[11:55]  * ogra fiddles 
[11:59] <ogra> wow !
[11:59] <ogra> even when loggin in through ssh i already get
[11:59] <ogra> [   21.537811] asoc: no valid backend routes for PCM: SDP4430 Media
[11:59] <ogra> about ten times
[11:59] <lag> Yes, I know about that
[12:00] <amitk> ogra: yes, the driver routes audio over ssh when it sense the tcp connection
[12:00]  * amitk ducks
[12:00] <ogra> lol
[12:00] <ogra> i wish ... that would have made my live in LTSP a lot easier back then :)
[12:01] <ogra> lag, hmm, intresting
[12:02] <lag> ?
[12:02] <ogra> [   93.762878] asoc: no valid backend routes for PCM: SDP4430 Voice
[12:02] <ogra> [  100.084808] asoc: no valid backend routes for PCM: SDP4430 Tones Playback
[12:03] <ogra> and also
[12:03] <ogra> [  136.720489] asoc: no valid backend routes for PCM: SDP4430 MODEM
[12:03] <ogra> 0,2 retuns Voice
[12:04] <ogra> oho, 0,3 gets me an oops
[12:04] <ogra> http://paste.ubuntu.com/495233/
[12:05] <lag> Perhaps default.pa links back and front ends
[12:05] <ogra> and the hang too
[12:05] <ogra> default.pa doesnt link a think in the default setup
[12:05] <ogra> it uses what udev provides as 0,0 usually
[12:06] <ogra> or falls back to static alsa detection if udev
[12:06] <ogra> is missing
[12:12] <ogra> lag, so [   28.112762] asoc: no valid backend routes for PCM: SDP4430 Media comes from the desktop coming up
[12:12] <ogra> which means pulse defaults to 0,0
[12:13] <ogra> i can reproduce the message with aplay on 0,0
[12:15] <lag> Sounds about right
[12:16] <ogra> so getting that connected to something by default would give us headphones by default
[12:24]  * ogra goes to find some food ... somehow i missed breakfast again and my friday meeting marathon starts shortly
[12:26] <lag> ogra: Do me something else
[12:26] <lag> Run the *.sh and try again
[12:27] <lag> If that works, it could just be a volume issue
[12:40] <lag> It looks like HDMI does _not_ use the CODEC
[12:40] <lag> Hence why it works out of the bo
[12:40] <lag> x
[12:40] <lag> That wasn't a kiss :)
[12:41] <ogra_cmpc> aha
[12:41] <ogra_cmpc> lag, will test if i'm upstairs again
[12:43] <lag> f?
[12:43] <lag> if?
[12:43] <ogra_cmpc> once
[12:45] <lag> when?
[12:45] <ogra_cmpc> geez, after i finished eating
[12:46] <lag> No
[12:46] <lag> I mean "will test _when_ i'm upstairs again"
[12:46] <lag> I'm not rushing you
[12:46] <lag> :)
[12:47] <lag> Just correcting your England
[12:47] <ogra_cmpc> ah
[12:47] <ogra_cmpc> heh
[12:48] <lag> Oooo
[12:48] <ogra_cmpc> ?
[12:48] <ogra_cmpc> got sound ?
[12:53] <ogra> re
[12:53] <lag> Nope
[12:53] <lag> My board doesn't do sound :)
[12:55] <ogra> soooo
[12:55] <ogra> i hear sound
[12:56] <ogra> aplay -Dplughw:0,0 /usr/share/sounds/speech-dispatcher/dummy-message.wav ...
[12:56] <ogra> after runnign the script
[12:56] <lag> Just by running the *.sh?
[12:56]  * ogra logs out and in again to see
[12:56] <ogra> yeah
[12:56] <lag> With the old default.pa and daemon.conf?
[12:56] <lag> That's exciting
[12:57] <lag> That means it's just a volume issue
[12:58] <ogra> well, while i see the in/output in sound prefs and also the HW i cant get system sounds
[12:58] <ogra> so its a routing issue too i guess
[12:59] <ogra> but aplay definitely works with just the mixer stuff
[12:59] <lag> We can sort that out separately
[12:59] <ogra> hmm
[12:59] <lag> Surely that's a userspace issue?
[12:59] <ogra> aplay doesnt spit out anything anymore now
[13:00] <lag> Oh?
[13:00] <lag> What did you do?
[13:00] <ogra> seems pulse grabbed the device or something
[13:00] <ogra> i logged out and in again
[13:00] <ogra> then trying aplay on the ssh console ... no output
[13:01] <ogra> aha, because it hangs again
[13:01] <ogra> http://paste.ubuntu.com/495264/
[13:02] <ogra> serial ...
[13:02] <lag> I'm working on that right now
[13:02] <ogra> k
[13:02] <lag> So it's just a volume issue then?
[13:02] <ogra> so i can reboot ?
[13:02] <lag> You have to
[13:03] <ogra> i know, just wanted to know if you need other info before i do :)
[13:03]  * ogra reboots
[13:04] <lag> davidm: ndec: Can I solder my board?
[13:05] <diwic> lag, here I am
[13:05] <lag> Hi David
[13:05] <lag> Thanks for coming :)
[13:05] <lag> Right, so we can get sound by only fiddling with amixer
[13:06] <diwic> okay
[13:06] <lag> How does amixer work
[13:06] <lag> Who does it talk to?
[13:06] <diwic> amixer talks to alsa-lib, which makes ioctl's to the kernel
[13:07] <lag> Where into the kernel?
[13:07] <lag> Basically, I want to do inside the kernel what amixer is doing from userspace
[13:08] <diwic> okay
[13:08] <diwic> there is also alsactl init if you want to run amixer on startup
[13:09] <lag> I'd like to use that as a fallback
[13:09] <diwic> but getting things right in the kernel, I assume that would work too
[13:09] <lag> I'm guessing there is no way to revert amixer settings?
[13:09] <lag> We run a script (which I sent to you) to change them all
[13:10] <lag> I'm assuming it's not so easy to change them all back (so I can compare them)
[13:10] <diwic> revert? Naah, but you can save and restore them with alsactl
[13:10] <lag> Cool
[13:10] <lag> I need a fresh image then
[13:10] <lag> Bear with me
[13:10] <diwic> in the standard ubuntu distro, this is done for you automatically
[13:11] <ogra> we noticed :)
[13:11] <ogra> lag, you might be able to delete the state file and reboot
[13:11] <diwic> or...let me think...it might be that Daniel T Chen just uploaded a version which *doesn't* do that
[13:11] <lag> I think they are persistent over reboot?
[13:11] <ogra> i have asouns.state here
[13:12] <ogra> *asound
[13:12] <ogra> i think thats what stores the settings
[13:12] <diwic> just before the Maverick freeze
[13:13] <ogra> ogra@panda:~$ ls -l /var/lib/alsa/asound.state
[13:13] <ogra> -rw-r--r-- 1 root root 15690 2010-09-17 14:05 /var/lib/alsa/asound.state
[13:13] <ogra> ogra@panda:~$ date
[13:13] <ogra> Fri Sep 17 14:12:53 CEST 2010
[13:13] <ogra> matches my last reboot
[13:13] <lag> diwic: What is the correct way to set ALSA state
[13:13] <ogra> look in /etc/init/alsa-mixer-save.conf
[13:13] <lag> How about if we just had a correct asound.state file?
[13:13] <diwic> lag, good question. There is a volume database somewhere...
[13:14] <ogra> lag, wont work, we'd break an existing package with that
[13:14] <ogra> and it would be more hackish than the script
[13:14] <lag> And you think hacking the kernel isn't "hackish"?
[13:14] <ogra> the proper way for such workarounds are alsa quirks as persia said in the bug
[13:15] <ogra> if we cant do kernel, we need to do quirks
[13:15] <lag> diwic: So it would go:
[13:15] <diwic> /usr/share/alsa/init
[13:15] <ogra> right
[13:16] <lag> diwic: amixer -> alsalib -> (ioctl) -> ? -> sound chip -> CODEC
[13:16] <lag> ?
[13:16] <ogra> and a line in 00main to sourfce an omap4 setup
[13:16] <ogra> isnt CODEC before sound_chip ?
[13:17] <diwic> lag, I'm not into soc that much, but I would say that your question mark should be replaced by "snd" or "snd-soc-core" module (if there is one of the latter)
[13:18] <lag> ogra: I don't believe that to be true
[13:18] <ogra> k
[13:18] <lag> I think the volume settings are _on_ the CODEC
[13:18] <diwic> it depends on what you mean with "sound chip" I guess
[13:18] <diwic> lag probably meant the controller
[13:19] <ogra> i meant physical HW
[13:19] <lag> They are both physical HW
[13:19] <ogra> well, attached to the in/output device
[13:19] <lag> The sound chip is connected to the CODEC
[13:19] <ogra> k
[13:19] <diwic> lag, technically, both the controller and the codec are "sound chips" :-)
[13:20]  * ogra doesnt know much ablow alsa 
[13:20] <ogra> *below
[13:22] <diwic> 6-12 months from now there might be an additional component called "Use Case Manager" telling people how they should set up the mixer for different use cases
[13:22] <diwic> but that's a different story
[13:23] <diwic> For now I assume alsactl init (i e /usr/share/alsa/init ) should work
[13:23] <lag> ndec: Why isn't the sdpXXXX mentioned on either the schematic or datasheet?
[13:25] <diwic> I guess doing it in the kernel would work as well, but I'm not really familiar with how to do it there. I assume that you could hard-code communication with the codec in the initialization.
[13:27] <hrw> diwic: alsa scenarios got finally implemented?
[13:28] <ogra> hrw, no, we're blindly poking sticks into it and see if it survives
[13:29] <diwic> hrw, scenarios? Well, I assume people have talked about it before, but there is implementation undergoing development, I don't think it is merged into alsa yet
[13:29] <diwic> hrw, you can search alsa-devel for "UCM" or "Use Case Manager" this month or the month before that
[13:47] <amitk> ogra: getting a lot of heat from OE-apologists? :)
[13:47] <ogra> amitk, yeah, enetertaining, isnt it ?
[13:55] <pcacjr_> i've customised an ubuntu livecd, i would like to know if there's any way to disable that windows which gives us these options: "Try ubuntu" or "Install ubuntu". if it's an off-topic question, please let me know.
[13:57]  * rcn-ee has never won an argument with mru either... ;)
[14:00] <lag> prpplague: Are you around yet?
[14:00] <amitk> ogra: just give him an old board and get it over with :-p
[14:01] <ogra> amitk, i'd love to :)
[14:01] <ogra> its just to entertaining ...
[14:01] <ogra> cant stop :)
[14:11] <zumbi> is anyone here using eclipse for cross development?
[14:11] <zumbi> I am wondering which sort of plugins is people using
[14:15] <avinashhm> hi, my debug fs is mounted in /sys/kernel ... checked /etc/fstab, not moutned from here .. any hints from where it is moutned ?? script file ??
[14:18] <zumbi> avinashhm: mount helps?
[14:18] <pcacjr__> avinashhm: try "sudo mount" (that shows the current mounted file systems) and look at that one
[14:19] <zumbi> pcacjr__: i believe no need sudo for calling mount
[14:19] <pcacjr__> zumbi: indeed
[14:19] <pcacjr__> zumbi: my bad
[14:19] <pcacjr__> sorry
[14:19] <zumbi> no prob :)
[14:19] <pcacjr__> :-)
[14:19] <avinashhm> ichecked mount .. its mounted in /sys/kernel .. don't know from where this is getting moutned .. not fstab ..checke tht ??
[14:19] <pcacjr__> rsalveti: wake up lazy brazilian
[14:20] <pcacjr__> avinashhm: isn't it include in the initrd ?
[14:21] <pcacjr__> Doh - included
[14:21] <avinashhm> pcacjr__, let me check ...
[14:21] <pcacjr__> avinashhm: sudo mount -o loop initrd /mnt/foo
[14:25] <avinashhm> pcacjr__, there was no initrd .. but found the file .. its mountd from mtab ../etc/mtab ...
[14:25] <pcacjr__> avinashhm: cool, good to know too
[14:26] <lag> ogra: How do you run your amixer.sh?
[14:26] <ogra> sudo sh amixer.sh currently
[14:26] <avinashhm> pcacjr__: thanx ....
[14:26] <pcacjr__> avinashhm: nope
[14:26] <lag> So you're using the old version of the script?
[14:26]  * ogra was to lazy to make it executable
[14:26] <ogra> no, i copy pasted from the bug
[14:26] <ogra> into a file called amixer.sh
[14:27] <lag> Which lines?
[14:27] <ogra> all
[14:28] <ogra> the whole sript there
[14:28] <ogra> *script
[14:28] <lag> And you don't run amixer.sh -a?
[14:28] <ogra> just sh amixer.sh
[14:28] <lag> And that does what?
[14:29] <ogra> http://paste.ubuntu.com/495301/
[14:29] <lag> I think that does the same as -a
[14:29] <ogra> i guess so
[14:29] <lag> Yes, same
[14:29] <lag> Can you reflash?
[14:29] <lag> With 14
[14:29] <lag> Then do sh amixer.sh -s?
[14:30]  * ogra has to prepare for a meeting but i'll try to do that on the side
[14:30] <lag> Much appreciated
[14:31] <ogra> zcat running
[14:32] <lag> Once you've done it, see if you can get sound without rebooting
[14:32] <lag> I think amixer should turn the volume up without the need for a restart
[14:32] <ogra> yes, it applies immediately
[14:32] <rsalveti> hm, lots of audio stuff for today
[14:32] <lag> Remember to forget to copy over the other files (that we don't need)
[14:32]  * lag has no hair left
[14:33] <ogra> rsalveti, and flamewars in #beagle
[14:33] <rsalveti> what reminds me we should try to ping persia
[14:33] <rsalveti> haha
[14:33]  * rsalveti looks at #beagle
[14:33] <ogra> surely #beagle is the more entertaining channel today :)
[14:33]  * ogra never saw amitk getting rude before 
[14:34] <ogra> lag, the script definitely applies immediately, i dont need to test that, i can tell you
[14:35] <persia> ogra, If you need root to run amisxer.sh something is wrong: it ought just work.
[14:35] <ogra> the thing is that it clashes with pulse as soon as you restart the session (or reboot)
[14:35] <ogra> persia, i didnt check :)
[14:35] <ogra> just ran it with sudo
[14:35] <amitk> ogra: sometimes an offence is the best defence
[14:35] <ogra> amitk, yeah ... :)
[14:36] <rsalveti> persia: there you go
[14:36] <rsalveti> good "morning"
[14:36]  * persia claims to be in UTC-7 today
[14:36] <ogra> amitk, i liked it :)
[14:38] <davidm> lag, if you need to. Why?
[14:39] <lag> prpplague: Thinks my audio filter may be broken
[14:39] <lag> Doh
[14:39] <lag> davidm: prpplague thinks my audio filter may be broken
[14:39] <lag> I need to turn this: http://imagebin.ca/view/C-Otvqp.html
[14:39] <ogra> NCommander, around already ?
[14:39] <lag> Into this: http://imagebin.ca/view/rVkPnEG.html
[14:39] <davidm> i you are comfortable trying the fix have at it
[14:40] <lag> Eh?
[14:40] <ogra> now i understand why they made the board balck !
[14:40] <ogra> *black
[14:41] <lag> Well it doesn't work in it's current state
[14:41] <lag> It can't get any worse?
[14:41] <lag> I need an 8 layer really
[14:41] <lag> There is no filter on the 8 layer
[14:42] <davidm> So you need to remove L28
[14:43] <davidm> And C205
[14:43] <avinashhm> ping GrueMaster
[14:44] <lag> I think just L28
[14:45] <lag> But I will clarify with prpplague
[14:47] <rsalveti> ogra: indeed a flame
[14:47] <amitk> ogra: don't do this, ubuntu will get blamed if he quits computers ;)
[14:47] <ogra> heh
=== bjf[afk] is now known as bjf
[15:04] <zumbi> ogra: yes, that is not good way to clean (improve) your employers name
[15:09] <amitk> zumbi: I have a minimal kernel for the efikamx
[15:10] <amitk> zumbi: working on the ethernet support since I like doing nfsroot
[15:10] <zumbi> amitk: those are great news, is it published?
[15:10] <amitk> zumbi: I'll post patches soon, perhaps this weekend if I get around to hacking
[15:11] <zumbi> amitk: i do not mind to do some early testing
[15:11] <amitk> the damn thing has ethernet hanging off of usb, so it needs usb initialisation to get ethernet working
[15:11] <zumbi> yes, that is why uboot is borked
[15:12] <amitk> zumbi: will email you an early bird patch to 2.6.36-rc3
[15:12] <zumbi> http://wiki.debian.org/EfikaMX#Limitations
[15:12] <amitk> yeah :-/
[15:12] <zumbi> amitk: i'll be happy to build and test
[15:13] <armin76> amitk: aren't all armv7 boards the same?
[15:13] <armin76> except dove
[15:14] <armin76> and no clue about omap4
[15:14] <zumbi> armin76: what are you talking about?
[15:14] <armin76> zumbi: needing usb init for eth
[15:14] <armin76> since eth is usb based
[15:15] <zumbi> oh! yeap! I was planning to move to barebox at some point
[15:15] <amitk> armin76: not really
[15:16] <armin76> amitk: examples?
[15:16] <amitk> armin76: most SoCs have ethernet IP on them, e.g. the imx51 has a FEC IP
[15:16] <amitk> but that isn't being used on the efikamx (it is used on the babbage though)
[15:16] <amitk> much simpler init when usb is not involved
[15:17] <amitk> the efika has BT, WLAN and ethernet hanging from usb. So no connectvity unless usb works
[15:17]  * amitk gets signs of life from the usb driver
[15:18] <zumbi> uhm... i had no idea, wlan and bt hanged on usb, maybe that explains wlan failures
[15:18] <armin76> fail
[15:19] <zumbi> well in any case, mainline kernel is good news :)
[15:31] <ogra> ndec, http://imagebin.ca/view/C-Otvqp.html -> http://imagebin.ca/view/rVkPnEG.html
[15:32] <rsalveti> removing is always easier
[15:32] <rsalveti> :-)
[15:34] <diwic> lag, anything else? I'm about to call it a day
[15:36] <prpplague> lag: yea just remove L28 and short across the two sets of pads
[15:37] <ogra> prpplague, oh, you are up
[15:37] <prpplague> ogra: just got to the office, forgot to log off irc last night
[15:37] <ogra> we're just discussing possible fixes in the call
[15:37] <Martyn> morning
[15:37] <ogra> sinbc eit seems ndec's team sees the same issues
[15:37] <prpplague> ogra: ahh ok
[15:38] <prpplague> ogra: basically L28 needs to be removed and the two pads shorted across
[15:38] <prpplague> ogra: i thought all the 6-layer boards had been done that way
[15:38] <ogra> seems lag's board looks slightly different though
[15:39] <prpplague> ogra: than the picture i posted?
[15:39] <lag> What about the surrounding components that you've removed?
[15:39] <Martyn> we mande a fun little discovery this week.  u-boot doesn't invalidate dcache .. so if you aren't using the arm monitor (or other very early bootrom to setup the a9) kernel dies when it enables the MMU
[15:39] <prpplague> lag: the other components don't need to be removed, that board was one of my test boards that i was testing some noise issues with
[15:39] <prpplague> lag: L28 is the only item that you should have to change
[15:39] <Martyn> which board is this that needs the rework?
[15:40] <prpplague> Martyn: 6-layer boards
[15:40] <lag> --^
[15:40]  * lag warms up the iron
[15:40] <Martyn> prpplague: I meant, which manufacturer/platform
[15:41]  * Martyn has a desk full of boards.. everything from those lange boards, to the tegra 250 boards, to the new omap 4xxx boards.
[15:41] <lag> Martyn: Panda
[15:41] <prpplague> Martyn: sorry, panda board
[15:42] <Martyn> thanks.
[15:44] <Martyn> STE U8500 arrived today.
[15:44] <Martyn> Can't even think about looking at it until next week
=== zyga is now known as zyga-food
[15:48] <Neko> https://launchpad.net/builders there are only 9 armel buildds??
[15:48] <ogra> no, 7
[15:53] <lag> prpplague: I managed to bridge one pair, but not the other
[15:53] <lag> :(
[15:53] <lag> How did you do it?
[16:06] <prpplague> lag: just removed the filter, cleaned the area with solderwick, then flux it
[16:06] <prpplague> lag: then solder bridge across
[16:11]  * Martyn will use some 0 ohm resistors
[16:49] <prpplague> has anyone been seeing gfx underruns on some of the older builds of ubuntu rootfs?
[16:50] <ogra> not only on the older ones
[16:50] <ogra> my screen usually turns black once every two days or so
[16:50] <ogra> and i have to switch consoles to get it back
[16:50] <prpplague> ogra: anyone looking at the root cause?
[16:51] <ogra> niocolas said someone at TI is
=== zyga-food is now known as zyga
[16:53]  * prpplague wonders who
[16:55] <rsalveti> prpplague: maybe mythripk should know better
[17:02] <GrueMaster> This could be an issue where the monitor is in deep sleep and the system isn't sending a wakeup before reading edid.  I'm not seeing it here, but I am only on a DVI monitor.
=== amitk is now known as amitk-afk
[17:03] <ogra> GrueMaster, no, it happens even while i use it
[17:08] <GrueMaster> Oh.  That is strange.
[17:17] <rsalveti> argh, apt, dpkg, logrotate, man-db, mlocate, just some of the daily process that consumes all your io
[17:17] <rsalveti> can't use my beagle while running these services :-(
=== hrw is now known as hrw|gone
[17:31] <devilhorns> ogra, got a minute ?
[17:35] <rsalveti> devilhorns: not sure if ogra is on-line still, but who knows
[17:35] <devilhorns> ahh ok
[17:35] <devilhorns> rsalveti, ok, maybe you can answer this quickly for me then ...
[17:35] <devilhorns> I have more patches for the netbook-launcher-efl ... but "Bugs" do not exist for these patches ... should I add new bugs ? or just email the patches to someone ?
[17:36] <rsalveti> devilhorns: if we plan to add this fixes for the release, than we should have bugs for every fix
[17:36] <rsalveti> so we can try to make exceptions and get into our release
[17:36] <rsalveti> if they are fixes for the next one, than you could just maintain them at your own tree
[17:36] <rsalveti> and let us know about it
[17:37] <devilhorns> hrm ... but I don't know what the "plans" are :)
[17:37] <persia> devilhorns, Please create new bugs.
[17:37] <rsalveti> maybe creating a ppa or something like that to help us testing
[17:38] <persia> devilhorns, The "plan" is to make everything shiny and nice.  Extra points for feature-equivalence for 3D and 2D solutions.
[17:38] <rsalveti> I'd say it all depends on the kind of fixes you have
[17:38] <devilhorns> well, in the grand scheme, they are fairly minor really ... (currently does not handle some background options correctly (scale, zoom, wallpaper, etc), and also does not install the schema file either)
[17:38] <rsalveti> if you rewrite everything, than just a bug to create a new release :-)
[17:38] <devilhorns> rsalveti, well, also doing that on the side :)
[17:38] <devilhorns> new version will have both 2d and 3d
[17:38] <rsalveti> awesome
[17:39] <rsalveti> and now we can test 3d with sgx
[17:39] <rsalveti> efl should just fly with sgx
[17:39] <rsalveti> at least raster did some work with it
[17:39] <devilhorns> rsalveti, efl flies on anything :) ... my toaster is proof :P
[17:39] <rsalveti> yeah... you're right :-)
[17:39] <persia> procedurally it might be easiest to file two bugs: one for everything that simply *must* be fixed to be release-quality in maverick, and one for an upgrade that should happen when natty opens
[17:40] <rsalveti> yep, probably the best option
[17:40] <rsalveti> then we can try to still push some fixes for the release
[17:41] <devilhorns> wondering if it's really worth it for these 2 small patches tho ... considering that I am rewriting it anyway ... hrm
[17:41] <devilhorns> I mean, apparently these 2 minor bugs have not bitten anyone yet
[17:41] <persia> the archive is Frozen, so if something isn't release critical it's not going to be approved anyway.
[17:41] <rsalveti> persia: am I wrong or we're the only ones who should provide an image with the efl interface?
[17:41] <devilhorns> as there are no existing bugs for it
[17:42] <persia> rsalveti, Doesn't matter: the same release criteria apply for everything.
[17:42] <rsalveti> persia: I know that, just wanted to know if we'd affect anyone else
[17:42] <devilhorns> persia, ok, I'll just wait then. If they have not been previously reported then apparently they are not "show stoppers" :)
[17:42] <persia> I know there are some folks who keep trying to make an enlightenment flavour, but I haven't heard much from them this cycle.
[17:43] <persia> devilhorns, makes sense.  Best to focus now on critical fixes *OR* reinventing the world for next time.
[17:44] <devilhorns> persia, indeed :) I've been fixing everything ogra has assigned to me so far (plus some things not assigned) ... but I'm fairly new to *buntu development so not sure what proper procedures are, or even what is "critical"
[17:44] <devilhorns> but seeing as how these 2 issues are minor, I'll just go back to recreating the wheel :)
[17:45] <persia> Much of it is a matter of conscience, but generally "critical" falls into categories like "significant regression", "potential for user data loss", "potential for failed upgrade", "security issue", etc.
[17:45] <devilhorns> (for next release)
[17:46] <devilhorns> persia, yea, these 2 don't fall into any of those categories imo :)
[17:47] <persia> devilhorns, In that case, yeah, don't worry about them if you're rewriting the entire thing anyway.
[17:47] <devilhorns> indeed :)
[17:47] <devilhorns> new one is much nicer so far :)
[17:49] <persia> Excellent.
[17:49] <devilhorns> yea :) uses less memory already, is faster, and does things correctly
[17:50] <rsalveti> cool
[17:50] <rsalveti> devilhorns: any chance to test at a real arm board?
[17:50] <rsalveti> last time I saw you requested a beagle but don't know the current status
[17:51] <devilhorns> rsalveti, not yet ... I am supposed to receive one, but has not arrived yet ... and I don't know the current status of that "issue" (meaning I don't know if it was sent out or anything)
[17:51] <rsalveti> devilhorns: ok, np, just wanted to know
[17:52] <rsalveti> so we can then ping davidm later
[17:52] <devilhorns> rsalveti, no worries :) believe me, when it gets here I'll be testing it :)
[17:52] <persia> Isn't EFL sufficiently ported that we oughtn't expect significant differences?
[17:52] <devilhorns> yea, should not be any major issues
[17:52] <rsalveti> persia: yep, but it'd be nice to see it running faster on beagle
[17:53] <rsalveti> because then you can really know if the code is actually faster
[17:53] <rsalveti> :-)
[17:53] <devilhorns> I know for fact that some high-up efl developers (myself included) do work for another company that is putting efl on arm based phones
[17:53] <persia> I guess.  beagle doesn't meet minimum Ubuntu specs anyway (mind you, I'm using one for porting, but still...)
[17:53] <devilhorns> so I don't see efl having any major problems on ARM hardware :)
[17:53] <rsalveti> devilhorns: yeah, I know many hehe
[17:54] <devilhorns> rsalveti, ok, so you already know what's going on then ? :)
[17:54] <rsalveti> not every details, but I do sometimes get some updates :-)
[17:54] <rsalveti> most of the time when drinking beers with the right people ;-)
[17:55] <devilhorns> rsalveti, gotcha :) well sadly I'm under nda and cannot say a whole lot about the issue ... other than "I don't see efl having problems on arm arch" :)
[17:55] <rsalveti> devilhorns: yep, understandable :-)
[17:55] <devilhorns> rsalveti, ahhhh, so you know some efl devs personally then ? :)
[17:56] <rsalveti> devilhorns: for now most of the people at profusion and some others that doesn't actually do much work nowadays
[17:56] <devilhorns> rsalveti, ahhh, gotcha
[17:56] <rsalveti> persia: I know beagle doesn't meet minimum Ubuntu specs, but would be nice to see it running there
[17:56] <devilhorns> I miss rephorm :(
[17:56] <rsalveti> as efl should just fly on it, even with lower specs
[17:57] <devilhorns> yup :)
[17:59] <rsalveti> devilhorns: we had some nice people working on efl at indt, but then nokia decided to buy qt...
[17:59] <rsalveti> but now at least we have some other companies putting money on it
[17:59] <devilhorns> ahh yea, I remember indt ... started the original webkit-efl stuff
[17:59] <rsalveti> yep, canola, webkit-efl and other cool stuffs that didn't turn into "products" :-(
[18:00] <rsalveti> now it's just qt hehe
[18:00] <rsalveti> everywhere
[18:00] <devilhorns> ick
[18:00] <devilhorns> if I wanted something to run slow, I'd just stick with Winblows :)
[18:01] <rsalveti> hehe
[18:03] <rsalveti> devilhorns: and about efl, any news when we're getting the real "1.0" release?
[18:03] <rsalveti> maybe then the final e17
[18:03] <rsalveti> hehe
[18:06] <devilhorns> well work is happening now to make elm 1.0 alpha
[18:06] <devilhorns> after that happens "officially", then it should be a matter of a week or two for "beta"
[18:07] <rsalveti> cool
[18:07] <devilhorns> and I'd imagine "release" will be shortly (couple weeks to a month) after that ... of course all this is assuming no major issues arise
[18:07] <devilhorns> rsalveti, but that's not an "official" timeline or anything, so don't quote me on that ;)
[18:08] <Neko> yay enlightenment
[18:08] <Neko> when are we getting eubuntu-desktop? :)
[18:09] <devilhorns> indede
[18:09] <devilhorns> well, we had one a couple years back w/ gOS .. but bad management killed that
[18:09] <Neko> that horrible emachines thing?
[18:10] <devilhorns> well, we were not responsible for the hardware they chose :)
[18:10] <Neko> indeed it never got much traction outside of $199 walmart specials.. I did try it and was impressed with how it looked and felt
[18:11] <devilhorns> :) and that was with an early efl too
[18:11] <Neko> is all that work sitting in some git repo or openembedded thing somewhere?
[18:11] <Neko> or rolled into e17 libs now? :)
[18:12] <GrueMaster> Actually, I had some non-linux users test that here (before I found Ubuntu), and they had a hard time with some basic operations.  That was on real hardware.
[18:12] <devilhorns> Neko, no, gOS is as dead as can be ... I have some iso's that we made still lingering around here somewhere but that's about it
[18:12] <devilhorns> Neko, some stuff got rolled back into efl, yes
[18:12] <Neko> the one thing I always hated about enlightenment, despite it being totally awesome, it had a penchant on the default build and themes and things for everything being black on dark grey, with medium grey highlights, 7 point bitmap fonts, and everything being in a 900-item cascading context menu
[18:12] <persia> Neko, Making an enlightenment flavour is mostly a matter of coming up with all the right bits: feel free to do it if you're sufficiently interested :)
[18:13] <Neko> I am sufficiently interested to do it on something other than ubuntu :)
[18:13] <devilhorns> GrueMaster, yea, think that was the biggest complaint that we had ... but again, that was with an early efl ( & E) that really wasn't ready for a desktop yet
[18:15] <devilhorns> (yes I was on the gOS team too) ... not proud of that, but hey I look @ it like "eh, it was experience in making distros" :)
[18:15] <GrueMaster> At the time, my main distro was Mandriva.  Same group had no complaints with it.  I use them for some UNE testing now and again, but haven't in 6 months.
[18:16] <GrueMaster> I usually do it when one of them hosts a game fest.  But the last few fests I have been OOC.
[18:16]  * rsalveti out for lunch
[18:16] <devilhorns> ahh games ... I miss those
[18:16] <devilhorns> haven't had time for em lately
[18:16] <GrueMaster> Same here.
[18:17] <GrueMaster> I hope to have a fest post-release.  Really feel the need to shoot my fellow man - virtually of course.  :P
[18:18] <devilhorns> hahaha
[18:20] <rsalveti> hum... games
[18:20] <rsalveti> my ps3 is off for weeks
[18:21] <devilhorns> mine too :(
[18:21] <rsalveti> I'd like to play SC2, but gets very slow with wine on my current machine
[18:21]  * rsalveti needs a faster machine
[18:23] <devilhorns> hehe
[18:30] <GrueMaster> Great.  After my power glitch (affected the neighborhood), my XM has 12 crash reports.  Trying to run apport-bug on them...crashed.
[18:31] <persia> Extra points!
[18:33] <devilhorns> lol
[18:33] <devilhorns> you get to keep the extra parts ;)
[18:33] <GrueMaster> heh.
[18:34] <persia> And we have a bot again!
[18:34] <GrueMaster> ?
[18:34] <persia> Oh, I guess we've had it for a while.
[18:34] <GrueMaster> yea.
[18:34] <GrueMaster> on this channel.
[18:34] <persia> There were a few days we didn't have one, and I just saw the join.  Clearly I have to read backscroll more carefully.
[18:35] <persia> (note the change from "4" to "2")
[18:36] <GrueMaster> oh.
[18:52] <tgrimley> any beagleboard users able to help with a boot issue?
[18:53] <persia> What seems to be the problem?
[18:57] <Neko> "it doesn't boot" :D
[18:59] <tgrimley> Everything was happy until yesterday, where I now get: ** Unable to use mmc 1:1 for fatload ** at boot
[18:59] <tgrimley> I'm guessing corrupt SD card..
[19:00] <persia> Hrm.  I've not seen that one.
[19:01] <tgrimley> this is from a ubuntu-10.04.1-minimal-armel image if that gives any clues
[19:02] <Neko> ogra, ogra_cmpc, I noticed you were somehow involved with the blueprint etc. on the "make maverick filesystems for boards with crappy storage that are just like the ones the installer makes"? rsalveti too? is there something I can look at that describes the stuff the installer does post package install (like that bit where it restores settings and makes the font terminus or that slightly more wiggly ubuntu one, or whatever..)?
[19:04] <persia> Neko, The jasper-initramfs package is what does that.  I was to review it at one point, but have been advised that the code is painful to examine.
[19:05] <Neko> <-- masochist for this stuff
[19:05] <persia> It then calls into the oem post-install configuration tool (part of ubiquity) for the final configuration and tweaking.
[19:05] <Neko> I'm already looking through the oem post-install stuff but it's very light on changing things that aren't usernames, passwords and timezones
[19:05] <Neko> it's just from the installer /etc/default/console-setup gets tweaked and I don't know where that is
[19:06] <Neko> there has to be a few things it does besides, too
[19:06] <persia> Check the code, but jasper-initramfs does the make-the-image-seem-like-it's-kinda-installed bit, and then calls the oem interface.
[19:06] <persia> There shouldn't be any other moving parts.
[19:06] <Neko> alles klar
[19:07] <Neko> I'm also kind of looking for the reason oem-config-gtk doesn't run on my rootstocks
[19:07] <Neko> it just sorta spools up gdm and xfce regardless of what I do.. even oem-config-prepare doesn't do anything
[19:07] <persia> Probably something in rootstock that tries to make the image think it's installed.
[19:07] <Neko> I was thinking, does it require a ramfs?
[19:08] <Neko> because we don't do that on the efika yet it needs some hardcore uboot changes and I'm scared to even change a variable
[19:08] <persia> No, but I think it's mostly untested without one.
[19:08] <Neko> what I did was grabbed rcn-ee's beagle image and it ran the curses one just fine
[19:08] <persia> You're running Ubuntu on the efika?
[19:09] <Neko> without initramfs or anything but it's ugly as sin
[19:09] <Neko> since the dark ages yeah
[19:09] <Neko> Jaunty, Karmic, Lucid, take your pick...
[19:09] <persia> I wish I'd known: I wouldn't have supported the removal of the imx kernels if someone who is reliably around was using them.
[19:09] <Neko> oh believe me, it would have happened anyway
[19:09] <persia> Why?
[19:10] <persia> Only reason it was dropped was because nobody seemed to be maintaining it, and it wasn't known to work on any retail HW.
[19:10] <Neko> because I don't think you guys want to maintain a userspace for 2.6.35 where everyone else is, when mx51 is stuck on last year's kernel
[19:10] <Neko> the amount of work to push efikamx support into the ubuntu kernel would have meant pulling a new bsp patchset too.. you're 9 months behind
[19:11] <persia> Just needs someone to do it, really.  the 9 months mostly reflected nobody working on it.
[19:11] <Neko> we're working on 2.6.35.. we'll provide an ubuntuized kernel, then we can work out what we do for Narwhal
[19:11] <persia> Who is "we" in that context?
[19:11] <Neko> <-- product manager for efika mx
[19:11] <persia> Oh!  Just the right person then :)
[19:12] <persia> So, yeah, if you're interested in having Ubuntu work, and you have a kernel that works, it's relatively easy to get that kernel building and into the archive.
[19:12] <Neko> you'd think. I might have appreciated an email about it to be honest, amit and lool knew about us :D
[19:12] <persia> But it does require someone to maintain it, and the processes for granting direct upload rights takes several months of continued work.
[19:13] <Neko> that's fine, as long as it doesn't cost a ton of money for us unfortunatelt
[19:13] <Neko> we don't really have the resources of ARM or Freescale to throw a bunch of money at a distro that we won't get for 6 months.
[19:13] <persia> There's no monetary cost for bits in the archive: the cost is entirely in engineering.
[19:13] <persia> If you can maintain it, it can be there.
[19:14] <Neko> it basically comes down to how much we want ubuntu and how many people we can throw at it
[19:14] <persia> Right.
[19:14] <Neko> but we have a bunch of guys (well, one main one) who are doing some debian work who are willing to maintain ubuntu stuff too
[19:14] <Neko> did you see the armhf port? :)
[19:14] <persia> I have, and am very excited by it.
[19:14] <Neko> any chance it'll get into Obtuse Orangutan or whatever it's going to be called? :D
[19:15] <persia> No idea.
[19:15] <persia> New ports require infrastructure resources, which are mostly limited to Canonical right now, so it's a matter of what ends up being supporting in the Canonical DC.
[19:16] <Neko> we're pretty stoked that stuff is getting done. we bought the debian-ports guys some big disks for their servers so they had space for armhf
[19:16] <persia> Saw that, and lots of talk about hardware being handed around.
[19:17] <Neko> http://buildd.debian-ports.org/status/architecture.php?a=armhf&suite=unstable lots of packages done :D
[19:17] <Neko> if we throw another 5 boxes at it we'll rival the ubuntu armel build farm :3
[19:17] <persia> Yep.  Prospects look really good for Wheezy
[19:18] <armin76> Neko: bah, you can't compare debian with ubuntu..ubuntu is the best </spam>
[19:18] <Neko> :)
[19:19] <persia> Err, Debian and Ubuntu have such wildly different foci that they can't usefully be compared
[19:19] <Neko> he was being facetious
[19:19] <armin76> :D
[19:20] <Neko> we just figured the ubuntu guys would not bite considering the nightmare of lpia in the past, until it was at least in debian-testing
[19:20] <persia> It's not about that: it's all about what ends up in the infrastructure.
[19:21] <Neko> :)
[19:21] <persia> Back when we were working towards feisty, a bunch of us tried to get an "arm" port (this is pre-armel), but ended up having issues because of hardware availability and supportability for delivery to the DC.
[19:21] <Neko> back then there were no bloody boards :]
[19:22] <persia> Things have changed since then, but you'd really have to talk to #canonical-sysadmin about if/whether DC stuff could be supported, and you'd first want to have a significant number of Ubuntu Developers ready to support the port.
[19:22] <Neko> still waiting for beagle and buying $6000 fsl dev kits was the task du jour.. dark, dark times..
[19:22] <persia> There was plenty of ARM5 hardware back then :)
[19:22] <Neko> but nothing as cool as a sheevaplug
[19:23] <persia> But I'll be the first to admit I'm much happier with the current port than what we would have produced then, as specifications are now much more acceptable.
[19:23] <Neko> where is jasper-initramfs built from
[19:23] <persia> jasper-initramfs source :)
[19:23] <Neko> no such package
[19:24] <Neko> also "jasper" is definitely not the same thing, seems some jpeg viewer or so
[19:24] <persia> On an Ubuntu maverick system, `apt-get source jasper-initramfs` doesn't work?
[19:24] <Neko> oh shit okay. you know. I realized I am still running Lucid
[19:24] <Neko> new thing?
[19:25] <persia> Yeah, new for maverick.  Lucid beagle images installed to NAND+USB (like the world should be).
[19:25] <persia> At maverick UDS, folk were talking about boards shipping with no NAND and no ability to boot from USB, meaning that one had to have install media be the *same* as runtime media.
[19:26] <persia> jasper-initramfs was created to handle that.  I think it was switched for beagle mostly because nobody had the hardware described when it started getting written.
[19:27] <Neko> ahaaaaa.. I notice it uses a uboot boot.script
[19:27] <Neko> man this helps a lot trying to wrangle this work
[19:28] <Neko> mkdir -p /root/var/lib/oem-config
[19:28] <Neko> touch /root/var/lib/oem-config/run
[19:28] <Neko> is that all oem-config really needs?
[19:29]  * persia doesn't remember, having not looked at that since ~jaunty, but wouldn't be surprised
[19:31] <Neko> I don't like the idea of flash-kernel. we want our images on pata, in an ext2 or vfat partition :)
[19:31] <persia> Then don't use flash-kernel.
[19:31] <Neko> it seems to be the default
[19:31] <persia> It's a workaround for devices that can't boot off a mountable /boot
[19:32] <persia> That's because most devices suck :)
[19:32] <Neko> do you want to make a list of ubuntu people who would like a current Efika MX with working NEON? :)
[19:33] <persia> I have a shortlist of folk I'd like to have one, which I'd be happy to send you :)
[19:33] <GrueMaster> Neko: You can disable flash-kernel in /etc/kernel-img.conf
[19:33] <Neko> I know :)
[19:33] <persia> But in fairness, I think it would probably be better to have some sort of public offer, and have folk send you a note suggesting what they might do with it, etc.
[19:33] <prpplague> lag: you get your board modified?
[19:34] <persia> You can just not install flash-kernel in the first place.
[19:34] <persia> (or purge it)
[19:34] <Neko> persia, done
[19:34] <Neko> http://projects.powerdeveloper.org/program/imx515/proposed
[19:34] <Neko> http://projects.powerdeveloper.org/program/imx515/accepted actually that is a better page to look at :D
[19:34] <persia> Neko, So I should tell the folks on my list that if they want one, they ought register there?
[19:35] <Neko> yes at least create an account, give me user id numbers, propose a project.. if it's just "we're ubuntu guys and we want to play around" then get a lead to make a project and I can add developers into the same project group
[19:36] <Neko> I have to insist on at least a paragraph like a university thesis introduction on the whole thing, one liners make me sad :D
[19:37] <persia> Would you prefer several submissions e.g. "working on Ubuntu Haskell porting for armel", "working on improving Ubuntu armel Qt support", etc. or one big one?
[19:38] <Neko> if it is seperate subsystems or teams I'd prefer seperate
[19:38] <Neko> for instance the debian guys we special cased, but there is debian-edu, debian-x11 etc. and they should have all made projects if we weren't in a rush to get them boards for debconf
[19:38] <persia> I'll say that folks were very happy to all have boards at debconf :)
[19:39] <persia> So, yeah, I'll pass the word around to folks who aren't always in this channel to submit stuff then.
[19:39] <persia> And anyone in this channel who has a good idea should go get a board if they want one :)
[19:40] <Neko> we might cut you off at like 10 boards or so :) but we can also drop some older boards with busted NEON for compile farm stuff.
[19:42] <persia> All I can do is make sure your program gets noticed by folk I know what HW.  You'll have to decide the value of each proposal :)
[19:46] <persia> s/what/want/
[20:09] <prpplague> for anyone that wants to start doing notes/wiki posts on the panda - http://www.elinux.org/PandaBoard
[20:12] <suihkulokki> can someone add a "buy here" link? :)
[20:13] <fredim> Hi, Good afternoon.
[20:13] <fredim> BeagleBoard plugin on a pc (ubuntu) but nothing appears in dmesg
[20:13] <persia> USB connection?  Which dmesg has no output?
[20:17] <fredim> yes, usb
[20:18] <fredim> It has no output
[20:18] <persia> On the beagle?  On the host?
[20:19] <persia> You're running Ubuntu on the host: what are you running on the Beagle?
[20:21] <fredim> In my notebook using ubuntu.
[20:21] <fredim> I called the BeagleBoard with USB cable, use dmesg to see what was connected and nothing appears.
[20:26] <fredim> I called the BeagleBoard with USB cable on notebook (ubuntu), use dmesg to see what was connected and nothing appears.
[20:26] <fredim> sry 2 msg
[20:27] <persia> No, that7s fine.  I'd actually like to understand.
[20:27] <persia> So, what are you running on the Beagle?
[20:28] <fredim> Beagle --> USB --> Notebook
[20:28] <fredim> But there is no recognition
[20:31] <fredim> I use the command dmesg new hardware plugged
[20:31] <fredim> but there is no line of response
[20:31] <fredim> sry , my english =/
[20:34] <persia> What OS do you run on the Beagle?
[20:35] <fredim> I want to install ubuntu-arm
[20:35] <fredim> in my / dev shows nothing
[20:37] <rsalveti> fredim: well, plugging your beagleboard into your notebook could mean that you want to power it or use it as a gadget
[20:39] <persia> and if it is to be used as a gadget, the Beagle needs to have gadget-supporting software running at the time it's attached.
[20:39] <persia> If it's just power, no response is expected.
[20:39] <rsalveti> yep, do you have any software already running on your beagle?
[20:39] <persia> If the goal is to *install* Ubuntu, put the available image on an SD card, and boot the Beagle from SD.
[20:41] <GrueMaster> fredim: Download http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/beta/ubuntu-netbook-10.10-beta-preinstalled-netbook-armel+omap.img.gz and follow the instructions at https://wiki.ubuntu.com/ARM/OMAP
[20:41] <GrueMaster> We can help from there, but  that should get you started.
[20:47] <fredim> I have to install some software to appear /dev/mmcblk0
[20:47] <GrueMaster> fredim: On your laptop?
[20:48] <fredim> yes
[20:48] <persia> /dev/mmcblk0 isn't the beagle: it's the SD card (if you have one built-in).
[20:48] <GrueMaster> Look at dmesg.  if your SD reader is usb based, it will show up as /dev/sd? (i.e. /dev/sdc).
[20:49] <persia> If you are using a USB card reader, you'll end up with /dev/sd${something}
[20:52] <fredim> My SD card is plugged in beagle ... Still have to appear in / dev / sdx?
[20:52] <fredim> Why is there no line in dmesg
=== bjf is now known as bjf[afk]
[20:56] <persia> fredim, You need to attach the SD card to your PC *without* the beagle (unless you have special software to make the Beagle an SD reader, but I don't know of any such software)
[20:59] <fredim> How do I connect SDcard directly on the notebook/computer, what means?
[21:00] <fredim> my laptop has the card reader but the computer does
[21:01] <persia> fredim, Most folk use either a built-in card reader or a USB card reader
[21:04] <GrueMaster> The beagle won't work until an image is on the SD card.
[21:06] <fredim> Now I understand, thank you.
[21:35] <prpplague> GrueMaster: ping
[21:35] <GrueMaster> pong
[21:36] <prpplague> GrueMaster: is the kernel defconfig that is being used for the ubuntu panda builds posted somewhere?
[21:36] <GrueMaster> I have no idea.  lag would know.
[21:36] <persia> It's in both source and binary packages.
[21:37] <persia> I'd recommend checking the source
[21:37] <prpplague> persia: where can i get the source package?
[21:37]  * prpplague is not an ubuntu person
[21:37] <GrueMaster> apt-get source <package>
[21:38] <prpplague> ok, whats the name of the package?
[21:38] <prpplague> there isn't a git repo somewhere?
[21:38] <persia> kernel.ubuntu.com has heaps of git repos
[21:39]  * prpplague looks
[21:39] <prpplague> persia: thanks
[21:39] <persia> http://archive.ubuntu.com/ubuntu/pool/main/l/linux-ti-omap4/ has the tarball of the source
[21:39] <prpplague> ahh ok thanks
[21:39] <GrueMaster> The source package is linux-ti-omap4-source-2.6.35.
[21:40] <GrueMaster> That will pull the tarball, any external patches, and the dsc file to build the .deb with.
[21:41] <GrueMaster> Also, apt-cache show <binary-package-name> will show you the name for the source package.
[21:41] <persia> (really, it looks stuff up in a database, and downloads all the files from the URL I just posted, but it always has the right place, instead of needing to hunt about)
[21:42] <persia> GrueMaster, apt-cache show won't work for packages not available on that architecture
[21:43] <rsalveti> prpplague: tarball is easier than just looking for the config file at the git tree
[21:44] <rsalveti> as it's broken into common and specific configs depending on the machin
[21:44] <rsalveti> *machine
[21:44] <rsalveti> but for omap 4 I believe it should be fine, as it's just one machine...
[21:44] <rsalveti> 1 sec
[21:44] <prpplague> rsalveti: yea grabing it now
[21:45] <rlameiro> is there already some package or script to setup ARM cross compiling toolchain easily on ubuntu?
[21:45] <rlameiro> that would be awesome :D
[21:45] <rsalveti> prpplague: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=blob;f=debian.ti-omap4/config/config.common.ubuntu;h=8d46b556e09697138c3a2b8b975c9f519b901856;hb=refs/heads/ti-omap4
[21:45] <rsalveti> for omap4
[21:45] <rsalveti> as this kernel supports just one machine, there's only the config.common
[21:46] <rsalveti> rlameiro: I believe there are packages already for maverick
[21:46] <rsalveti> hrw|gone: did the work
[21:46] <rlameiro> rsalveti: really:D
[21:46] <rlameiro> FTW
[21:46] <rsalveti> was in a custom repository, but he was going to push it before the freeze
[21:46] <rsalveti> just don't know if it's compiled already
[21:47] <rsalveti> probably it is, as we have more builders for i386
[21:47] <rlameiro> se we can compile the kernel like make CROSS-COMPILE ARM=arm bla bla bla
[21:47] <rlameiro> ???
[21:48] <rlameiro> *ARCH=arm
[21:48] <prpplague> rsalveti: thanks
[21:49] <rsalveti> rlameiro: https://edge.launchpad.net/ubuntu/maverick/+source/gcc-4.5-armel-cross
[21:49] <rsalveti> there's also the 4.4 packages
[21:49] <rsalveti> rlameiro: yep
[21:50] <rlameiro> WOW that is awesome
[21:50] <rlameiro> the IGEPv2 comes with a VM for vmware with things almost ready
[21:50] <rlameiro> it will be awesome to have it already on the repos
[21:51] <rlameiro> they use ubuntu as their SDK
[21:51] <rlameiro> 8.04....
[21:52] <rsalveti> hehe
[22:12] <rlameiro> what is the best filesystem for the rootfs sd card?
[22:12] <persia> Depends on the card.
[22:13] <rlameiro> well, kingstom sdhc
[22:13] <persia> But typically any journalling filesystem will be fine.
[22:13] <rlameiro> 4gb
[22:13] <rlameiro> ext3 or 4?
[22:13] <persia> I have no idea which FTL is in that (and I doubt it's enough info, FTLs tend to be swapped out within a single product without model changes)
[22:14] <persia> There should be no benefit to ext3 or ext4 specifically for it being on an SD card, unless you have a very fancy FTL that happens to have ext4 support.
[22:14] <rlameiro> how can i know that?
[22:16] <persia> I don't know of any reliable way :)
[22:16] <rlameiro> :)
[22:17] <persia> rlameiro, By the way, we tend not to cross-compile stuff: everything in the archive is native-compiled.  If you're working on something, it's worth doing a native-compile test every once in a while, even if you usually cross-compile: we've seen a number of issues where something will cross-compile but not native-compile or vice-versa.
[22:18] <rlameiro> persia: ok, but that was for the kernel
[22:18] <rlameiro> compiling kernel natively takes a long time :D
[22:18] <rsalveti> and it's always handy to have a cross compiler :-)
[22:19] <persia> rsalveti, Only if your hardware isn't very good :p
[22:19] <rsalveti> no need to get them from CS is even better
[22:19] <rsalveti> persia: true, the good thing is that this is going to change probably next year :-)
[22:19] <rsalveti> panda itself is going to rock already
[22:20] <persia> People keep saying "This will change".  I purchased a perfectly acceptable-performance laptop running armel about a year ago, but people still talk about the future.
[22:20] <persia> The key to having it happen is for someone to just do it.
[22:21] <persia> One of my ARM boxes is 1.2Ghz, which is plenty fast.  Doesn't happen to support Ubuntu, so it runs Debian.
[23:14] <jayabharath> davidm: ping
[23:26] <davidm> hi jayabharath
[23:26] <prpplague> davidm: greetings
[23:27] <davidm> Board away, thanks
[23:27] <prpplague> davidm: get your boards picked up?
[23:27] <davidm> prpplague, yep, Home - TI - FedEx - Home :-)
[23:28] <prpplague> davidm: did you get washed away?
[23:29] <prpplague> *cough* sent one to RoHS, and got nada
[23:29] <davidm> Nope made it back home before this storm blew in
[23:30] <jayabharath> davidm : good to know you got the board.
[23:31] <jayabharath> davidm: we were trying to test the audio.. to ensure its working... but could NOT as you came in just on time :(
[23:31] <jayabharath> its a new board and tested during production so mpoirier_should have no issue
[23:33] <davidm> jayabharath, thanks for the heads up, I'll let mpoirier know to check it
=== pcacjr_ is now known as pcacjr