[00:00] <rsalveti> read it wrong here
[00:01] <infinity> NCommander: Pokity poke.
[00:01] <jhobbs> i think i know what is wrong - in older versions, when it looked for a default and didn't find it, it would go ahead and attempt to boot labels it hadn't tried to boot yet
[00:02] <rsalveti> jhobbs: yup, makes sense
[00:03] <infinity> NCommander: I need someone with ~ubuntu-installer commit access who happens to be in my timezone.  Wake up! ;)
[00:04] <jhobbs> rsalveti: i have a patch that fixes that now, i just need to run through a few tests
[00:04] <jhobbs> rsalveti: should i email it to you?
[00:04] <rsalveti> jhobbs: please, rsalveti@linaro.org
[00:04] <jhobbs> ok
[00:20] <jhobbs> ok it's sent
[00:22] <jhobbs> rsalveti: let me know if you have troubles with it. the fdt_addr issue isn't as straightforward - i'm not sure check for an fdt there is the right answer either, it may be that the pxe command should look for explicit instruction to use fdt, like bootm does
[00:23] <rsalveti> jhobbs: yeah, probably
[00:23] <rsalveti> let me check your patch
[00:23] <infinity> GrueMaster: So, I can't make oem-config crash here at all.  Which makes it pretty painful to figure out what's going on for you.  But every other issue raised today (partition label, flash-kernel race, ac100 not removing oem-config) should be fixed in tonight's dailies, the only remaining one is the slideshow, which should be fixed by a pending merge I have to ubiquity.
[00:23] <infinity> GrueMaster: (You can kick your roommate to merge my ubiquity fix, since he's in ~ubuntu-installer) :P
[00:24] <jhobbs> rsalveti: i'm going offline and might not check irc until tomorrow, email me if there are issues, thanks for your help
[00:25] <rsalveti> jhobbs: sure, thank you :-)
[00:27] <rsalveti> jhobbs: worked fine now
[00:34] <rsalveti> GrueMaster: http://people.linaro.org/~rsalveti/u-boot/
[00:34] <rsalveti> GrueMaster: the fixed u-boot for pxe
[00:36] <rsalveti> jcrigby: with the patches available at http://people.linaro.org/~rsalveti/u-boot/ pxe works fine again
[00:41] <rsalveti> infinity: http://s3.amazonaws.com/imgly_production/2114800/large.jpg
[00:41] <rsalveti> libjpeg-turbo and libjpeg
[00:41] <rsalveti> running on imx53
[00:42] <rsalveti> tgall_foo should have the details
[00:43] <infinity> rsalveti: Very cool.
[01:03] <GrueMaster> rsalveti: u-boot appears to work correctly again.  Let me know when it is in the pool for more official testing.
[01:03] <rsalveti> GrueMaster: great, thanks for testing it
[01:06] <GrueMaster> infinity: Daily build just failed.  May be a while before I will be able to test your changes.
[01:08] <infinity> GrueMaster: Neat trick, since the daily builds don't happen for another 43 minutes...
[01:09] <infinity> cdimage@antimony:~$ crontab -l | grep ' ubuntu daily-preinstalled' && date
[01:09] <infinity> 55 1 * * *	buildlive ubuntu daily-preinstalled && for-project ubuntu cron.daily-preinstalled
[01:09] <infinity> Thu Sep 29 01:09:12 UTC 2011
[01:14] <jcrigby> rsalveti, /me the slacker has finally returned
[01:17] <rsalveti> jcrigby: hey :-)
[01:18] <jcrigby> rsalveti, thanks for filling in for me, I owe you as always
[01:19] <rsalveti> jcrigby: just need to check if the removal of fdt is the right thing to do
[01:19] <rsalveti> not yet sure why it was added
[01:25] <jcrigby> the old patch set used different names for kernel and ramdisk addresses, when converting to the new patchset the names had changed to ones used elsewhere in u-boot and documented in README.  So while adding this names to the panda config I added the other standard name/address for fdt
[01:26] <jcrigby> had not idea that it broke anything
[01:32] <jcrigby> rsalveti, so since I added it just for completeness sake he are probably ok deleting it at least for this ubuntu release
[01:32] <jcrigby> s/he/we
[01:38] <rsalveti> jcrigby: I think so
[01:38] <rsalveti> as this will just affect the default behavior
[01:38] <jcrigby> yes
[01:38] <rsalveti> if the user wants to use fdt, he can set that at boot.src
[01:38] <jcrigby> yes
[02:28] <jcrigby> rsalveti, two recipe driven builds are going right now.  Also I have a source package ready for putting.  Do I need to wait for something.  Last time I did this I thought I learned that someone was supposed to set status to confirmed to indicate approval for the ffe.
[02:41] <rsalveti> jcrigby: let's wait the new builds to be available, then request GrueMaster to give some testing and then we request the release team to accept the FFe
[02:42] <jcrigby> rsalveti, ok sounds good
[02:42] <rsalveti> jcrigby: only thing is that the final freeze is tomorrow
[02:42] <jcrigby> I understand
[02:42] <rsalveti> so I guess I'll add a comment there now...
[02:44] <rsalveti> jcrigby: did you set CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS ?
[02:44] <jcrigby> no, I guess I get to do one more release
[02:44] <rsalveti> jcrigby: bug 837235
[02:44] <ubot2> Launchpad bug 837235 in u-boot-linaro "Broken ES2.0 support at U-boot-linaro 11.08" [Medium,Confirmed] https://launchpad.net/bugs/837235
[02:44] <jcrigby> ok
[02:45] <rsalveti> jcrigby: sorry for giving you more work
[02:45] <jcrigby> its not a problem
[02:45] <rsalveti> but getting a FFe and not fixing es2.0 will upset some people for sure
[02:45] <jcrigby> right
[02:48] <jcrigby> It has the added plus of reducing spl size
[02:48] <jcrigby> a patch hit u-boot ml today setting this as default and setting spl limit back to 32K
[03:13] <rsalveti> jcrigby: cool
[03:24] <rsalveti> jcrigby: did you fire up another build already?
[03:25] <rsalveti> at the package recipe
[03:25] <jcrigby> yes
[03:25] <rsalveti> jcrigby: great
[03:25] <jcrigby> https://code.launchpad.net/~linaro-maintainers/+archive/staging-overlay/+build/2813063
[03:30] <infinity> GrueMaster: Nevermind, no new images because ubiquity was FTBFS on i386.  Yay for skew the other direction for once. :P
[03:31] <infinity> GrueMaster: If I'm up late, I might re-spin some armel images for testing.
[07:47] <sniperjo_> Hi guys, I'm trying to boot my board but it stops at uncompressing kernel … I've checked my serial line is setup properly in uboot and there is no boot.src
[07:47] <twb> sniperjo_: it might be working but just not printing anything
[07:48] <twb> That line comes from the bootloader; you then need to tell the kernel where console= to put it
[07:48] <sniperjo_> twb: where can i do that ?
[07:48] <twb> It's args passed to the kernel
[07:48] <twb> e.g. qemu-system-arm -nographic -M versatilepb -kernel vmlinuz-3.0.0-1-versatile -initrd initrd.gz -append 'console=ttyS0 console=tty0 console=ttyAMA0,38400n8'
[07:49] <sniperjo_> in uboot i have setenv linux_args setenv bootargs console=${console} nfsroot=${serverip}:/dev/mmcblk0p2 ip=${ipaddr}:${serverip}:192.168.1.254:255.255.255.0::eth0:off; tftpboot 84000000 uImage; run linux_args; bootm 84000000;
[07:51] <infinity> sniperjo_: And what is console set to?
[07:51] <sniperjo_> console=ttyS2,115200n8
[07:51] <infinity> Your board actually has a device called ttyS2?
[07:52] <sniperjo_> yes, its the console thats used when i boot in angstrom
[07:53] <infinity> Potentially renamed in later kernels.
[07:53] <infinity> Though just a shot in the dark.  It could just as easily be the kernel just not booting too. :P
[07:54] <sniperjo_> infinity: by the way in still o n2.6.32, do i need to update my host computer
[07:54] <infinity> Update your "host"?
[07:55] <sniperjo_> The annoying thing is/.. somewhere, one of the things i have done, I've got to " Uncompressing kernel…. done" and I've just read somewhere that sometimes thats because its set up or a guy enviroment
[07:55] <sniperjo_> as in, what i used to compile the kernel
[07:57] <infinity> If you're using Angstrom sources, I'd recommend using whatever toolchain they recommend (ie: I don't know).
[07:57] <infinity> For something closer to upstream or Linaro sources, the latest and shiniest oneiric would be saner.
[07:57] <sniperjo_> i really don't want to use angstrom
[07:57] <sniperjo_> so in that case i do need to update?
[07:58] <infinity> I'm not even sure what device you're using...
[07:58] <infinity> But if there are newer kernels out there that support it, that would be a good place to start.
[07:59] <sniperjo_> infinity: an atom netbook
[07:59] <infinity> ...
[07:59] <infinity> I mean your ARM device.
[07:59] <sniperjo_> ah, technexion tsunami, omap4540, 25mb ram
[08:00] <infinity> ...
[08:00] <sniperjo_> whoops… 3530
[08:00] <infinity> You're trying to run Ubuntu on a pseudo-embedded system?
[08:00] <sniperjo_> 256mb ram… unless I've got some crazy prototype
[08:00] <infinity> Oh, 256 sounds less painful. :P
[08:01] <infinity> I'm going to guess that our "omap" kernel is too Beagle-specific to work on it, eh? :/
[08:01] <infinity> But, our omap sources, with the Angstrom .config shoved at it, might Just Work.
[08:01] <sniperjo_> yeah, it dies straight away, not the same vendor id
[08:02] <infinity> And for that, I'd definitely recommend compiling from an oneiric system, yes.
[08:02] <infinity> Kernel shouldn't be checking vendor id at all.  You mean our images do that (as in, our uBoot)?
[08:02] <infinity> I'm saying you could try our kernel with their uBoot.
[08:02] <infinity> But it's probably still missing some device support, since it's fairly Beagle-ish.
[08:03] <sniperjo_> infinity: I've defiantly tried it, and it definitely didn't work
[08:03] <infinity> Either way, it's 2am, I should probably not be trying to be helpful, and go to bed.
[08:04] <infinity> But some shiny newish linaro omap sources with the .config from your Angstrom kernel, built with an oneiric toolchain, may well work.
[08:05] <sniperjo_> ok, so i need to update my "host to one irc" and try and compile again
[08:44]  * ogra_ hugs infinity, thanks for the installer quietening
[10:01] <infinity> ogra_: NP.  It was annoying me in testing.  Sadly, no new images today with all my fixes yesterday, since ubiquity's FTBFS on x86. :/
[10:01] <infinity> ogra_: Yay for archive skew in the other direction for once?
[10:05] <ogra_> infinity, well, skew is skew :)
[13:02] <Guest18959> hi!
[13:03] <ogra_> hey zumbi
[13:03] <zumbi> hi
[13:03] <zumbi> ogra_: could you pull dietlibc from debian/experimental for oneiric?
[13:03]  * ogra_ can try ... we have final freeze today :)
[13:04] <zumbi> ogra_: it currently ftbfs on *buntu
[13:04] <zumbi> but experimental should have the fixes
[13:04] <zumbi> to have a working version, at least it works on debian armel/armhf
[13:04] <ogra_> infinity, can you sync that ? or do i need a bug etc etc
[13:04] <zumbi> I told doko but he seem to have missed it
[13:05] <ogra_> very likely, i think he is really overworked
[13:05] <zumbi> sure
[13:05] <zumbi> ogra_: thanks
[13:11] <ppisati> GrueMaster: yesterday, weren't you suggesting that the problem with the verbose audio messages on console were due to a driver rename? s/SDP4430/Panda/?
[13:59] <rsalveti> ppisati: it is, because then the current ucm files are useless after this change
[14:01] <ogra_> ppisati, i hope that fix got in in todays build ?
[14:01] <ogra_> else we will have lost sound again
[14:03] <ppisati> which fix?
[14:03] <ogra_> s/SDP4430/Panda/
[14:03] <ppisati> well, i did the rename
[14:03] <ogra_> good
[14:03] <ppisati> no wait
[14:03] <ppisati> i'm using the jack on the back of my panda board
[14:03] <ogra_> as long as alsactl finds the right name all is fine
[14:03] <ppisati> and i always had audio
[14:04] <ogra_> the renaming only happened recently in andys branch i think
[14:04] <ppisati> the rename was just to silence the messages on console
[14:04] <ogra_> no
[14:04] <ogra_> all alsa settings fully depend on the name
[14:04] <ppisati> so i shouldn't have audio, right?
[14:05] <ppisati> but i have it
[14:05] <ppisati> not hdmi, using the lower audio jack
[14:06] <ogra_> with the recent images and the new kernel ?
[14:06] <ogra_> i.e. on a fresh install where alsactl didnt create the defaults yet
[14:07] <ppisati> yes
[14:07] <ppisati> ah
[14:08] <ppisati> where does it store the config? i mean alsa
[14:08] <ogra_> its tricky to get rid of it
[14:08] <ppisati> doh
[14:09] <ogra_> best is to take the SD in your PC and remove /var/lib/alsa/asound.state
[14:09] <ogra_> *best
[14:09] <ppisati> ok
[14:09] <ppisati> i'll try
[14:10] <ogra_> (it gets recreated on every shutdown, so its not easy to do it on a running system without hacking around in upstart jobs and udev rules)
[14:10] <ppisati> single user and i axe it
[14:10] <ppisati> btw
[14:10] <ppisati> to check the renaming: /proc/asound/cards should be equal to 2.6.38.xx, right?
[14:10] <ogra_> yep
[14:11] <ppisati> ok
[14:11] <ppisati> btw, i thgought fix could go in even after final freeze
[14:11] <ppisati> or maybe not?
[14:11] <ogra_> sure
[14:11] <ppisati> ah ok
[14:11] <ogra_> but we still havent had much testing for the sound stuff
[14:11] <ogra_> so the earlier the better
[14:11] <ppisati> ok ok
[14:12] <ppisati> axe alsa state
[14:12] <ppisati> test again
[14:12] <ppisati> if not working, apply the rename and retest
[14:12] <ogra_> would be our first release where sound works on release day
[14:12] <ppisati> :)
[14:20] <ndec> ogra_: i don't want to be pessimistic... but i don't have audio... granted that I am not using your kernel, but I am using the kernel which was used by ppisati to make the ubuntu kernel...
[14:20] <ogra_> hmm
[14:21] <ogra_> well, lets see what paolos test turns out now
[14:21] <ogra_> testing with an existing state file is indeed kind of moot
[14:27]  * diwic has not understood why we need this UCM thing in the first place, whereas one could write a PulseAudio profile instead to do the same thing.
[14:28] <ndec> UCM was supposed to help ;-)
[14:28] <ogra_> diwic, i think the idea was to use both
[14:28] <ndec> ogra_: on one panda that I have dist-upgraded since alpha2, audio works fine ;-)
[14:29] <ogra_> hmm
[14:29] <diwic> ogra_, no, PulseAudio profiles/paths, and UCM, are overlapping concepts.
[14:29] <ogra_> so should we roll back to the kernel we had at A2 ?
[14:29] <ogra_> :)
[14:29] <ndec> if we use our images from yesterday evening + our kernel --> no audio
[14:29] <ndec> ;-)
[14:29] <ogra_> ndec, iirc that was the natty kernel still
[14:30] <ndec> here we go...
[14:30] <ndec> it's even easier to find in the archive!
[14:31] <ndec> for UCM to work, we need to have /usr/share/alsa/ucm/Panda/Panda.conf, is that correct?
[14:32] <ogra_> i think so
[14:33] <jcrigby> ogra_, I'm ready to push the final u-boot source once someone approves
[14:33] <ogra_> oh, go ahead
[14:33] <jcrigby> oh, ok
[14:34] <ogra_> i'll do the paperwork in a minute on the bug
[14:35] <ndec> ogra_: did you submit the change (s/SDP4430/Panda/) to alsa?
[14:38] <ogra_> ndec, i think diwic added it in an SRU
[14:39] <ndec> ogra_: can you send me (again) the link with the queue of packages waiting for entering in the archive?
[14:46]  * diwic does not remember changing "SDP4430" to "Panda".
[14:48] <ndec> rsalveti: ogra_: ^^ if we change the device name in the kernel and not in alsa, we might be in troubles..
[14:51] <ppisati> ok, after deleting the
[14:51] <rsalveti> yup
[14:51] <GrueMaster> ndec: I have the latest alsa source..  I find no reference to "Panda" there.  It is all ADP4430.
[14:51] <ppisati> /var/lib/alsa/asound.state file and rebooting
[14:52] <ppisati> we have the unfamous "pulseaudio go nuts and swamp the console with lo messages" and 100% cpu usage for this
[14:52] <ppisati> renaming the driver s/Panda/SDP4430/ we get back to a "normal" logging on console
[14:52] <ppisati> nut no audio :(
[14:52] <ppisati> but
[14:53] <GrueMaster> ppisati: Hence why I filed it as a kernel bug originally.  While the messages are directly from Pulseaudio, it is because of a kernel change.
[14:53] <ppisati> GrueMaster: ok, so i can shove the driver name change in, but still there's some alsa tweaking to do
[14:54] <ppisati> else we won't have audio after a fresh install
[14:54] <ppisati> alt!!!
[14:54] <ppisati> the volume was low
[14:54] <ppisati> @#$#@$
[14:54] <ppisati> we have audio! :)
[14:54] <GrueMaster> A fresh install should just work.  In my earlier test, renaming SDP4430 in all of the ucm files and rebooting worked fine.
[14:54] <ppisati> yes, we haz it
[14:55] <GrueMaster> Cool.
[14:55] <ppisati> ok, let me commit it then
[14:55] <ndec> GrueMaster: ? there is already SDP4430 in all UCM files.
[14:55] <GrueMaster> The change to Panda is not in the upstream alsa git tree, so I don't know where it came from.
[14:55] <GrueMaster> ndec, right.  Not sure where the rename to Panda came from.
[14:56] <GrueMaster> I only did that as a quick experiment to see why it wasn't working.
[14:56] <GrueMaster> UCM shouldn't have changed since Natty.
[14:59] <ppisati> didn't we have an omap4 audio lp bug?
[14:59] <ppisati> crap, can't find it...
[14:59] <sniperjo_> I've followed a tutorial for getting ubuntu on my board ,I've set ups tftp server and such so it downloads the kernel and rootfs , it stop at  "uncompressing…booting kernel ".. from google lots of people have that because their console isn't set right, but my bootargs use ${console} which works when the prebuilt sdcard is in there
[15:00] <GrueMaster> ppisati: bug 820466
[15:00] <ubot2> Launchpad bug 820466 in linux-ti-omap4 "No sound on omap4 pandaboard" [High,Fix released] https://launchpad.net/bugs/820466
[15:19] <ndec> ogra_: ppisati: diwic: if i rename all the SDP4430 to Panda in /usr/share/alsa/ucm, sound is working with a kernel that calls the sound card Panda
[15:19] <GrueMaster> ndec: Upstream alsa still names it SDP4430.
[15:20] <ndec> this is for the Blaze board
[15:20] <GrueMaster> And changing the kernel name is easier (one line if I read the driver correctly).
[15:21] <ndec> are you sure it's upstream btw?
[15:21] <ndec> but wrong...
[15:21] <doko> diwic, I'll upload your openjdk/pulseaudio arm fix, just with a cast to jlong instead
[15:21] <ndec> i meant easier but wrong. the real name in the kernel should be Panda
[15:21] <GrueMaster> ndec: I have the alsa-project git tree here and up-to-date.
[15:22] <GrueMaster> Why?  Is it different from platform to platform?
[15:22] <ndec> yes
[15:23] <ndec> GrueMaster: where in alsa upstream did they put the conf files?
[15:24] <GrueMaster> I haven't seen any alsaucm files upstream yet, but they may be in a git tree I don't have yet.
[15:24] <GrueMaster> Will check after the meeting.  #ubuntu-meeting.
[15:25]  * ppisati refrains from commiting anything then...
[15:33] <GrueMaster> ndec: Since we have freeze today, it makes more sense to fixe the one line in the kernel than the multiple ucm files.  If TI wants it renamed to Panda, we can do it next cycle, but we will need to know way before freeze.
[15:47] <infinity> GrueMaster: I'd rather build alsa than another kernel.
[15:47] <infinity> To be fair...
[15:48] <GrueMaster> Really?  Alsa is a bit more intrusive.  Kernel is a separate tree affecting only omap4.
[15:49] <infinity> There's nothing intrusive about s/SDP4430/Panda/ unless you have a sound card called SDP4430 on your amd64 machine.
[15:49] <GrueMaster> No, but the packages are arch all.
[15:50] <infinity> That doesn't make the fix any scarier.
[15:51] <GrueMaster> On the kernel, it is a single line.
[15:53] <infinity> It's one line in alsa if I do it with sed in debian/rules instead of a patch.  (which I wouldn't do, but my point is that, conceptually, this isn't a large or unreviewable change).
[15:54] <infinity> And alsa is much faster to build/test.  And the fix belongs in userspace anyway, we'll have to do this all over again in 2 weeks if we don't do it now.
[15:54] <infinity> (Or forget for 3/4 of the cycle and whine at the end that sound doesn't work, and argue again)
[15:56] <GrueMaster> infinity: I don't trust it.  Remember, ext4 is a simple change too.  Right now I want the quick fix.  Since we have to rebuild the kernel anyways.
[15:58] <GrueMaster> The "correct" thing to do is fix it upstream.  Since alsa doesn't know about "Panda", this has not been done.  Alsa does know about the SDP4430 though.
[15:58] <ndec> GrueMaster: can you point me to where SDP4430 is reference in upstream alsa?
[15:59] <infinity> GrueMaster: ext4 was a simple change.  It landed at the same time as a bunch of mx5 stuff that make people blame ext4 for other breakages though. :P
[16:00] <GrueMaster> infinity: It wasn't a simple change as it required a bunch of jasper changes before we had working images.
[16:00] <infinity> See above.
[16:00] <infinity> And, for the record, SDP4430 isn't upstream in alsa at all.
[16:01] <infinity> It's a local patch.
[16:01] <ogra_> there were mx5 changes *and* a completely new image type (ac100) *and* ext4 at the same time
[16:01] <infinity> We fix it in our packages, we're done.
[16:01] <GrueMaster> ndec: I would, but the alsa-project gitweb interface seems to be broken.  The tree is git://git.alsa-project.org/alsa-kernel.git and the file is soc/omap/sdp4430.c
[16:01] <ogra_> if you want to blame anything, blame ac100, that caused the most intrusive changes
[16:02] <infinity> Oh, you're talking driver filenames?  That's meaningless.
[16:02] <infinity> It's only the UCM stuff that needs fixing.
[16:02] <ogra_> yeah, the filename doesnt matter, only whats in /proc/asound/cards
[16:02] <ndec> GrueMaster: in this file you will find this:
[16:02] <ndec>    if (machine_is_omap_4430sdp())
[16:02] <ndec>         snd_soc_sdp4430.name = "SDP4430";
[16:02] <ndec>     else if (machine_is_omap4_panda())
[16:02] <ndec>         snd_soc_sdp4430.name = "Panda";
[16:02] <ndec> ;-)
[16:03] <ogra_> yes, SDP4430 used to be for the blaze
[16:03] <ogra_> (and probably still is, i havent seen a recent blaze)
[16:03] <ndec> what I copy/pasted is where we are doing the device name, e.g. what ends up in /proc/sounds/cards, and what is used by alsaucm config file
[16:03] <GrueMaster> ndec: I just ran a git pull and didn't see it when grepping for Panda.
[16:03] <ogra_> right
[16:04] <ndec> GrueMaster: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=blob;f=sound/soc/omap/sdp4430.c;h=424ca3d512f6b15c3f2318bbcd6644a77fd052ac;hb=ti-omap4
[16:05] <GrueMaster> But just to err on the side of caution, I am recloning my tree.
[16:05] <GrueMaster> ndec: That is our tree.  Not upstream.
[16:05] <ndec> that will be upstream at some point.
[16:06] <GrueMaster> And when did the addition of Panda get there?
[16:06] <ndec> if we were using upstream stuff only, that wouldn't too nice...
[16:06] <infinity> If we revert our omap4 kernel to vanilla, we may as well drop the subarch.
[16:07]  * GrueMaster is getting tired of this argument.
[16:07] <Neko> you can't drop the subarch it will break flash-kernel
[16:07] <GrueMaster> I really don't care what you guys do.  Just fix the thing.
[16:07] <infinity> Yes.  In the time it's been happening, libasound could have been fixed, uploaded, and built.
[16:08] <GrueMaster> Same with the kernel.  Bad argument.
[16:08] <ndec> infinity: by the way, don't rename the files from SDP4430 to Panda, duplicate them. so that you get support for Panda and SDP4430 board
[16:08] <GrueMaster> Bug was filed a while ago.  If I had been doing daily testing instead of server testing, I would have been all over this weeks ago.
[16:08] <infinity> ndec: That was the plan.
[16:09]  * ndec remembers you talked about sed ;-)
[16:09] <infinity> ndec: Was an example. :)
[16:09] <ppisati> so you are going to fix in user space, right?
[16:09] <ppisati> *fix it
[16:10] <infinity> GrueMaster: 26 minutes versus 9 hours seems to support what I said.  But whatever.
[16:10] <infinity> ppisati: That's where the fix belongs.  I see no point kludging it.
[16:10] <ndec> GrueMaster: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=commit;h=14a8827efa05606e7d8776d11ad2e030c12d427c
[16:10] <ppisati> ok
[16:10] <ndec> it's signed-off by liam. a good sign that it might end up upstream
[16:11] <festhead> hi! Question: is it able yet to set the screen resolution on latest ubuntu?
[16:11] <festhead> on pandaboard
[16:11] <festhead> :)
[16:12] <Neko> I second that question :D
[16:12] <ndec> festhead: yes. at least on all the screens i have seen...
[16:12] <ndec> it picked the largest one at boot.
[16:13] <festhead> and where do you get the options?
[16:13] <ndec> now if you want to change the resolution, you need support for XRandR in the driver, so you need to install our DDK driver from the TI PPA
[16:13] <ndec> and it works too.
[16:14] <ndec> it just pick the bigger resolution supported by the screen. no option.
[16:15] <ogra_> well, you can force a resolution on kernel cmdline, no ?
[16:15] <ogra_> was that dropped ?
[16:15] <ndec> can you?
[16:15] <Neko> ogra_, seems so, nothing I tried worked there.. it just keeled back over to 640x480
[16:15] <ogra_> ndec, you could in the past, yeah, hdmimode= and friends
[16:16] <ndec> ogra_: if you use the TI DDK driver yes you can using drm
[16:16] <ogra_> indeed
[16:16]  * ndec thinks that hdmimode has been removed
[16:16]  * ogra_ isnt up to date with hacks :) 
[16:16] <ogra_> and then i also have a proper monitor
[16:17] <ndec> the good news is that the hack was removed in this case... in general we only add more hacks ;-)
[16:17] <ogra_> so i wouldnt need such hacks
[16:17] <ogra_> heh
[16:17] <infinity> Yeah, I kind of get a giggle out of my Panda having the nicest monitor in the house.
[16:19] <ndec> ogra_: infinity: i have to go... but i confirm that adding ucm/Panda fixed the audio issues on at least 2 different boards here...
[16:19] <ndec> byw
[16:19] <ndec> bye
[16:20] <ogra_> infinity, upload away i'd say
[16:20] <infinity> ndec: Yeah.  I'm testing and uploading within the hour.
[16:20] <infinity> After I find coffee and a snack.
[16:21] <GrueMaster> Don't forget udev will also need to be changed.
[16:21] <GrueMaster> Possibly.
[16:23] <infinity> GrueMaster: I should hope not.
[16:24] <infinity> GrueMaster: This isn't about kernel driver names, it's about alsa device names.
[16:26] <GrueMaster> infinity: There is a udev rule to load the alsaucm files.  I'll doublecheck to see how it is set up.
[16:30] <GrueMaster> It is currently set to "ATTRS{id} =="SDP4430", RUN+="/usr/bin/alsaucm set _verb HiFi" and "ATTRS{id} =="SDP4430", RUN+="/usr/bin/alsaucm set _verb Record"
[16:30] <GrueMaster> Not sure where ATTRS is set from, but I'm just saying heads up.
[17:04] <infinity> So, entirely unrelated, but noticed in testing this.  "alsaucm set _verb Hifi" works great.  "alsaucm set _verb Record" fails.
[17:05] <diwic> doko, xranby, ok, did both patches (pulseaudiodataline.patch and contextgetstate.patch) make it into openjdk-6 - 6b23~pre10-0ubuntu4 and did anybody actually test contextgetstate.patch ?
[17:06] <ogra_> infinity, did you test with an mp3 player or the like ? mics dont work
[17:07] <ogra_> infinity, its a real "line in"
[17:08] <infinity> ogra_: No, I mean the command fails.
[17:08] <ogra_> UH !
[17:08] <ogra_> that should definitely not happen
[17:08] <ogra_> bug it :)
[17:09] <ogra_> playback is definitely more important and if that works i'm already happy
[17:10] <GrueMaster> It would appear the PDM switch for AMIC no longer exists.  Looking to see if there is an alternative (renamed) control.
[17:11] <ogra_> well, the HW doesnt support mics ... it probably just reflects the reality now
[17:11] <GrueMaster> For now, commenting out the two lines makes alsaucm work.
[17:11] <ogra_> (or does AMIC not mean analog microphone ?)
[17:11] <GrueMaster> It supports audio in and that PDM enabled input.
[17:11] <festhead> is it correct that is ubuntu 11.06 the ablility to change the resolution on a pandaboard is supported?
[17:12] <GrueMaster> Like a mute button.
[17:12] <ogra_> right, but only high level sources
[17:12] <ogra_> festhead, there is no ubuntu 11.06
[17:12] <festhead> great :P
[17:12] <ogra_> there will be ubuntu 11.10 and there is 11.04
[17:13] <festhead> and is it supported in 10.10?
[17:13] <ogra_> well, it is supported by the closed driver in all releases afaik
[17:14] <doko> diwic, contextgetstate.patch: did change the cast to jlong. no, the build would have taken too long. but imo it can't get worse
[17:14] <ogra_> but not by the free framebuffer driver we ship by default
[17:14] <diwic> doko, ok, just wanted to make sure you saw there were two patches. Let's hope it works then :-)
[17:15] <festhead> ogra_, so no support?
[17:15] <ogra_> ??
[17:15] <ogra_> sure, but you need the pvr driver from the TI PPA
[17:15] <festhead> ok
[17:15] <ogra_> as ndec stated a while ago already
[17:16] <festhead> thanks
[17:16] <ogra_> welcome :=
[17:16] <ogra_> :)
[17:18] <ogra_> hmm, the log in the banshee bug looks suspiciously like an ubuntu-one issue
[17:19] <ogra_> it seems to die in a function called U1RequestChrome
[17:21]  * ogra_ removes banshee-extension-ubuntuonemusicstore for a test
[17:22] <ogra_> hmm, sadly no
[17:27] <GrueMaster> Hmm. No record device according to pulseaudio.  This may take a bit to figure out.
[17:28] <ogra_> might even be the kernel
[17:29] <diwic> GrueMaster, does the device show up in "arecord -l"
[17:30] <GrueMaster> There are a lot of devices that the SOC can handle.  Question is figuring out the right one for alsaucm so that pulseaudio works.
[17:31] <diwic> right.
[17:37] <festhead> ogra_, still no succes, i allready had those drivers. i'm using a pico projector and my resolution is only 848x480. no succes with xrandr
[17:38] <ogra_> how is that attached ? HDMI ?
[17:38] <festhead> yes
[17:39] <ogra_> well, try to catch robclark, he knows about graphics drivers and might have more ideas, i'm running out of them now
[17:40] <festhead> robclark, any ideas? :)
[17:40] <ogra_> its likely that your projector doesnt provide an EDID table the driver can handle
[17:44] <festhead> thanks for the help anyway
[17:51] <robclark> festhead, ogra_, no EDID for pico..
[17:51] <ogra_> aha !
[17:51] <robclark> it and LCD panels would only support current resolution
[17:52] <festhead> no ability to force resolution?
[17:55] <ogra_> boot with a monitor that has a supported resolution for the pico ... then plug over ?
[17:57] <festhead> haha! thought of that, but i have no hdmi-monitors. i tried the standard resolution (by plugging nothing in) but that was even smaller
[17:58] <ogra_> yeah, thats 640x480
[17:59] <GrueMaster> festhead: Do you have a DVI monitor?  You can use a DVI<>HDMI cable.
[18:00] <festhead> no only big vga monitors
[18:00] <GrueMaster> ouch
[18:00] <ogra_> hmm, oem-config-remove is just running here for whom it intrests ...
[18:00] <ogra_> on the most recent image
[18:00] <GrueMaster> robclark: Does the kernel module still accept parameters for video resolution?
[18:01] <GrueMaster> ogra_: Which image?
[18:01] <ogra_> desktop panda
[18:01] <robclark> GrueMaster, yes, although it is different from the omapfb bootargs of old
[18:01] <ogra_> initramfs-tools is running atm
[18:01] <robclark> other caveat: for displays that don't support EDID, there is only one valid resolution to choose from
[18:01] <robclark> ie, you can't set arbitrary resolution on the LCD panels on blaze, for example
[18:02] <robclark> or pico projector
[18:02]  * robclark is referring to projector built in on blaze, not one connected over hdmi/dvi..
[18:03] <robclark> for something connected over hdmi/dvi, it all depends on what the EDID says
[18:03] <GrueMaster> ok.  Is there a way to fix festhead with a kernel cmdline parameter?  Is it documented somewhere?
[18:04] <robclark> well, *if* he is using the drm driver, and connecting over hdmi/dvi, and still just gets one choice of resolutions, that probably means that it is all that the display supports
[18:04] <robclark> no amount of bootargs would change that
[18:04] <robclark> if he is using older omapfb stuff instead.. then there are some bootargs that would help
[18:05] <ogra_> GrueMaster, and finished, i'm at lightDM proper
[18:06] <GrueMaster> ogra_: What image?  What platform?
[18:06] <ogra_> again pnada desktop latest image
[18:07] <ogra_> sandisk class4 4G card though ... vers slow (one of the blue ones)
[18:07] <ogra_> hehe, and the boot partition is automounted
[18:07] <GrueMaster> Hmm.  Will have to test on other cards.  My 16G Class 6 Micro Center SD fails consistently.
[18:08] <ogra_> and apport pops in my face
[18:09] <GrueMaster> Nice.  I just got a segfault probing for recording devices on my panda.
[18:09] <GrueMaster> kernel oops.
[18:10] <infinity> ogra_: The boot partition rename thing hasn't landed in current images yet.
[18:10] <infinity> ogra_: But the fix is in. :P
[18:11] <ogra_> yep, thats why i laughed
[18:12] <ogra_> but still no TI icon
[18:12] <ogra_> grmbl
[18:13] <infinity> Where's the TI icon meant to be coming from?
[18:14] <ogra_> jasper
[18:14] <ogra_> well, its *meant* to be coming from a ti-ppa package but that always slipped
[18:14] <ogra_> that jasper does it is one of these eternal interim solutions
[18:15] <ogra_> its there and all, the prob is that it dopesnt show up in the launcher
[18:16] <ogra_> the prob here is that we need to append to the gsettings value for the launcher favorites
[18:16] <ogra_> without trashing them
[18:21] <ogra_> ah, the favorites are defined in /usr/share/glib-2.0/schemas/com.canonical.Unity.gschema.xml
[18:21] <ndec|home> ogra_: if it's too much troubles i don't care getting rid of the icon... it would be a little less user friendly, but we can live with that.
[18:22] <GrueMaster> of course they are. o_O
[18:22] <ogra_> ndec|home, well, i still have until 23:00
[18:22] <ogra_> GrueMaster, in natty they were somewhere completely else :)
[18:22] <ndec|home> i don't want you to feel bad if you don't make it ;-)
[18:22] <GrueMaster> And in P, they will change yet again.
[18:23] <ogra_> ndec|home, k, but i'll try my best at least ... its one hack less if i dont make it though
[18:23] <ndec|home> what is 'they'?
[18:23] <ogra_> ndec|home, the gnome desktop defaults
[18:23] <ndec|home> ah ...
[18:23] <ogra_> in gconf mangling the defaults was easy
[18:24] <ogra_> gsettings/dconf requires the config files to be compiled after changing them ... thats a bit more tricky
[18:24] <ogra_> apparently thats an improvement
[18:25] <ogra_> i havent found out for whom yet, but it surely is for someone
[18:26]  * ogra_ wonders why favorite entires all need to have the .desktop suffix in the name ... 
[18:26] <ogra_> its not that there would be any other file format it accepts
[18:29] <ogra_> sniff ... just adding it doesnt help apparently
[18:29]  * ogra_ wonders if unity-2d has its own favorites
[18:30] <GrueMaster> Probably.
[18:30] <GrueMaster> Add something to the bar, then find/grep for it.
[18:31] <GrueMaster> (usually much faster than figuring out where, if any, updated documentation may be)
[18:32] <ogra_> GrueMaster, i want to change the defaults, drag/drop adding it will place it somewhere totally different
[18:32] <ogra_> (in the config)
[18:33] <GrueMaster> Will it?
[18:33] <ogra_> yes
[18:33] <ogra_> it just dumps the .desktop file in a certain place in your user config
[18:34] <ogra_> while i need to set a configuration key
[18:34] <GrueMaster> Should be somewhere in either /etc or /usr/share then (if standards are being followed).
[18:34] <ogra_> right
[18:34] <ogra_> in /usr/share/glib-2.0/schemas/com.canonical.Unity.gschema.xml
[18:35] <GrueMaster> But that is unity.  Not unity-2d.  Or do they share the same files (like they should).
[18:35] <ogra_> yes
[18:35] <ogra_> they use the same backend for the dash
[18:35] <ogra_> and lanucher
[18:53]  * ogra_ finds it irritating that gnome-power-manager turns the battery icon red here and shows 2:12 next to it
[18:55] <GrueMaster> ogra_: On your panda install, did you notice the background behavior during oem-config?
[18:55] <ogra_> bah, clicking the ti icon does nothing, i guess the gnome-open apt: protocol changed too
[18:55] <ogra_> GrueMaster, you mean wallpapers ?
[18:56] <ogra_> yes, its ugly but i doubt we can do much abouot it now
[18:56] <GrueMaster> Well, the black screen that reveals the wallpaper when you move the mouse.
[18:56] <ogra_> ARGH !!!!!!!!!!!!!
[18:57] <ogra_> GrueMaster, yeah, thats an old xfbdev bug, we had it on beagles and babbages too
[18:57] <ogra_> great, so the TI icon doesnt work because gnome-open doesnt exist anymore
[19:00] <ogra_> ah, its xdg-open nowadays
[19:01] <GrueMaster> yea, gnome-open is so last cycle.  :P
[19:01] <ogra_> its libgnome2 !
[19:02] <ogra_> well, igot it working if you navigate to /usr/share/applications and click it now
[19:03] <ogra_> but still not in the launcher
[19:03] <GrueMaster> sigh.  20110928 daily fails oem-config on another SD card of mine.  yea.
[19:08] <Neko> oh, btw.. is there any reason when you install an optimized driver for Xorg, it's still loading fbdev in the background?
[19:08] <GrueMaster> Ah, second run seems to be removing oem-config now.
[19:08] <Neko> we got some really odd performance problems down to that on the Efika
[19:09]  * ogra_ points Neko to #ubuntu-x
[19:09] <Neko> yeah I thought as much....
[19:09] <ogra_> YAY !
[19:09] <Neko> happens on Panda too, oddly...
[19:09]  * ogra_ got it 
[19:09] <infinity> ogra_: \o/
[19:09] <ogra_> i see the TI icon in the guest session
[19:10] <ogra_> seems dconf is really really evil and writes the full defaults as a binary blob into the user dir
[19:10] <GrueMaster> ogra_: But does it blend?
[19:10] <ogra_> so later system default changes dont get noticed
[19:11] <infinity> Given that no one needs that icon except on fresh installs (well, in theory), that seems reasonable. :P
[19:11] <ogra_> GrueMaster, well, its a bit brownish
[19:16] <ogra_> infinity, its still a bug bjut seems its a unity one
[19:16]  * ogra_ thought the new system was that bad, but seems it only applies to the launcher defaults
[19:20] <GrueMaster> wow, doing a netinstall to an SD takes a loooong time.  Started it at ~11:30.  Still running.  Just asked for task selection.
[19:20] <GrueMaster> And this is from a local mirror.
[19:20] <infinity> ogra_: I'm not sure I'd call that a bug.  If it is, it's a bug in pretty much every X application.
[19:21] <infinity> ogra_: System defaults are applied on first-run and/or user creation, they don't get re-applied.
[19:23] <ogra_> infinity, gconf worked differently
[19:57] <festhead> hi! where can i find a free compiler for the dsp (TMS320DMC64X+)  on the omap4430 chip?
[20:07] <ogra_> infinity, could you take a cross check on commits 172 and 173 in the jasper-initramfs tree ?
[20:07] <ogra_> s/take/do/
[20:14] <infinity> ogra_: sed on an XML file, really?  There's no prescribed sane way to do this?
[20:15] <ogra_> infinity, well, i stole from casper
[20:15] <ogra_> so i assumed its a blessed way
[20:15] <ogra_> the xml file is the input i dont think there is a saner wayx
[20:15] <ogra_> (teh actual config gets generated from it as a binary blob)
[20:16]  * infinity sees no such code in casper...
[20:16] <ogra_> http://paste.ubuntu.com/699291/
[20:17] <ogra_> i could instead put an com.canonical.Unity.gschema.override in place but i still need to pull the key out of the xml file and generate a new value
[20:18] <ogra_> oh, and .override files are .ini format :P
[20:18] <ogra_> (for consistency i guess :P )
[20:19] <infinity> Anyhow, it does the same thing as what you just pastebinned.  So, yay for that?
[20:19] <infinity> But I still can't find that in the casper source. :P
[20:19] <ogra_> might be in some edubuntu package that adds to casper
[20:19] <infinity> Possibly.
[20:19] <ogra_> its all edubuntu bits and stgraber actualyl gave it to me in -desktop
[20:20] <infinity> I'm going to assume you've tested that shell on your system in an isolated script?
[20:20] <infinity> But, if the edubuntu bits work, this should too.
[20:20] <ogra_> so ok to upload ? (i might have it written differently, but i know the casper code has been tested already)
[20:20] <infinity> Yeah, I'm all for cargo-culting tested code.
[20:20] <ogra_> hehe
[20:20]  * ogra_ rolls the package 
[20:21] <stgraber> ogra_: it's from edubuntu-live
[20:21] <ogra_> ah
[20:21] <infinity> Oh.
[20:21] <infinity> ogra_: Quoting.
[20:21]  * ogra_ looks 
[20:21] <infinity> ogra_: [ -e $FOO ] and [ -e "$FOO" ] behave very differently.
[20:21] <ogra_> yeah, seeing it
[20:22] <infinity> (Shouldn't be an issue, since you explicitely set it to a string, but I'm paranoid.
[20:22] <ogra_> fixed
[20:22] <infinity> )
[20:22] <ogra_> and you shoudl be
[20:22] <ogra_> especially on my code past 8pm local time
[20:22] <ogra_> :)
[20:22] <stgraber> ogra_: I actually learned about the override stuff later on but haven't had a chance to test them yet and IIRC you still need to update the binary db, so it's just cleaner (but I usually don't care much about cleanliness in a casper hack as long as it works ;))
[20:23] <ogra_> yeah
[20:23] <ogra_> i dont actually think the .override file gains you much
[20:23] <infinity> Well, the obvious problem with the hack is that it fails to work if the entry that you're anchoring your regex on goes away. :P
[20:23] <ogra_> yeah
[20:23] <ogra_> thats easier in casper indeed
[20:23] <stgraber> right, but the override would need to hardcode the whole list, not much better :)
[20:23] <ogra_> since yuo can tie to ubiquity
[20:24] <ogra_> exactly
[20:24] <ogra_> thats waht i didn in gconf though
[20:24] <stgraber> it's fairly safe to assume that something using casper will have ubiquity installed (at least it's for Edubuntu) :)
[20:24] <ogra_> right, we dont use casper
[20:25] <ogra_> and dont have an ubiquity item in the launcher
[20:25] <infinity> ogra_: we do at the time that jasper-setup runs. :)
[20:25] <ogra_> i would actuallyx have preferred to pull the whole value out of the file, but grepping in xml is just moot
[20:26] <ogra_> infinity, we do what ? use casper or have an ubiquity item ?
[20:26] <infinity> ogra_: The latter.
[20:26] <ogra_> i think the latter is put in place by casper
[20:26] <infinity> ogra_: The launcher only goes away after oem-config runs.
[20:27] <ogra_> oh, really ?
[20:27] <ndec|home> festhead: http://linux-c6x.org/wiki/index.php/Downloading/Installing_Software
[20:27]  * ogra_ has never checked 
[20:27] <ogra_> i always thought casper handles it
[20:27] <infinity> ogra_: It's why we've had an open bug until 3 days ago about an "install icon on the launcher".
[20:27] <ndec|home> festhead: http://omappedia.org/wiki/Syslink_Project#Ducati.2FTesla_IPC_Source_Code
[20:27] <ogra_> oh, indeed
[20:27] <ogra_> heh, i think i even commented on it
[20:28] <festhead> ndec: thanks!
[20:28] <ndec|home> jussi: saw that you got the answer on #pandaboard ;-)
[20:29] <infinity> ogra_: Anyhow, whatever.  If that works, it's good enough for me for now.  It's an ugly hack regardless.
[20:29] <ogra_> yep
[20:29] <ogra_> well, all that PPA stuff should be in a package proper
[20:30] <ogra_> we should do that when implementing the "jasper needs to die in fire" spec
[20:34] <ogra_> aaand ... uploaded
[20:34] <ndec|home> GrueMaster: ogra_: infinity: you knew that alsa-lib changes was done in linaro ubuntu overlay PPA? https://launchpad.net/~linaro-maintainers/+archive/overlay/+packages
[20:34] <ogra_> ndec|home, no :(
[20:35] <ndec|home> rsalveti: why would such a change be done in the overlay PPA before it gets done in ubuntu?
[20:35] <ogra_> why wasnt it just fixed in the archive
[20:35] <ndec|home> ;-)
[20:35] <ogra_> ndec|home, i suspect because they use natty
[20:35] <ndec|home> true, they use alsa-lib from oneiric..
[20:36] <ogra_> though we have a policy in ubuntu that fixes happening in an SRU (which such a PPA effectively is) have to happen in the dev release as well
[20:36] <ogra_> we should probably discuss how to fix that for teh future at UDS
[20:37] <ndec|home> well, at least we have it in the archive too ;-)
[20:37] <ogra_> now, yes
[20:38] <ogra_> and with wasting at least 1h of three devs for discussing it
[20:38] <ogra_> i think we can do better ;)
[20:39] <ogra_> 22min to freeze ...
[20:39] <ogra_> i think i'll call it a feierabend :)
[20:39] <ndec|home> your first release with audio?
[20:39] <ogra_> ndec|home, so we will need an oneiric metapackage in the ppa ... do you want to do that ?
[20:40] <ogra_> yeah, that too :)
[20:40] <ndec|home> i will do that.
[20:40] <ndec|home> we have the gfx packages already in the ppa.
[20:40] <ogra_> thx, essentially i think its just copying the existing one and adjusting the deps
[20:40] <ogra_> for whats there atm
[20:40] <ndec|home> we will upload the meta pkg
[20:40] <ogra_> great, thx
[20:40] <ogra_> icon is back too :)
[20:40] <ndec|home> ;-)
[21:01] <rsalveti> ndec|home: ogra_: first, we're now using the same kernel
[21:02] <rsalveti> second, I said already that I had the changes needed for the tilt before the tilt was merged at ubuntu
[21:02] <rsalveti> third, I fixed this *yesterday* :-)
[21:02] <rsalveti> for the release, then before pushing to ubuntu I first need to check and validate with the current ubuntu kernel
[21:02] <rsalveti> and due lack of time, this wasn't done already
[21:03] <rsalveti> and ubuntu is going to final freeze
[21:03] <rsalveti> I don't want to push changes that might fix the issues :-)
[21:03] <rsalveti> only want to push things that I sure it'd be a solution for the problem
[21:05] <rsalveti> and the latest ucm configs were all posted at the no sound support for omap4 bug, just that nobody saw it
[21:14] <rsalveti> https://bugs.launchpad.net/ubuntu/+source/alsa-lib/+bug/746023/comments/50
[21:14] <ubot2> Ubuntu bug 746023 in alsa-utils "No sound on omap4" [High,In progress]
[21:14] <rsalveti> when I commented about the issue :-)
[21:17] <ndec|home> rsalveti: are the panda config files different from the SDP4430 ones?
[21:17] <ndec|home> in your pkg
[21:18] <rsalveti> ndec|home: currently, no, but we're using the configs provided by the multimedia wg
[21:18] <rsalveti> I guess it's not the same one ubuntu is using
[21:19] <ndec|home> i will check tomorrow. sound is working with our config, at least on headset.
[21:19] <rsalveti> only issue is that hdmi out doesn't seems to be working anymore
[21:19] <rsalveti> just jack
[21:20] <rsalveti> but didn't have time to investigate the issue yet
[21:49] <dash> just got an mx53 board, it's pretty sweet. i'm installing natty on it
[21:49] <dash> anybody know about getting the nfs kernel server going? do the natty kernel images not support that
[21:52] <GrueMaster> dash: Instead of trying to get natty on it (which we don't support on that platform), why not try oneiric?  The latest daily image works, although you may need to create a swap file.
[21:52] <GrueMaster> The natty images are TI only.
[21:53] <dash> GrueMaster: ach! oneiric sounds fine to me, but the wiki said "works like a charm" for mx53 and natty :)
[21:53] <dash> i've already got a swapfile anyway, no big deal :)
[21:54] <GrueMaster> Erm, which wiki?
[21:54] <infinity> GrueMaster: They ship with natty on an SD.
[21:54] <infinity> (And a freescale kernel)
[21:55] <GrueMaster> Ah.  Yea, they are making their own image.  Ours has the latest kernel and other Ubuntu bits.
[21:58] <dash> The board came with lucid.
[21:59] <dash> GrueMaster: I was looking at this: https://wiki.ubuntu.com/ARM/DeviceSupport
[21:59] <dash> It doesn't say "natty", I imagined that part, I guess. :)
[22:00] <GrueMaster> dash: Type "cat /etc/lsb-release".
[22:00] <dash> GrueMaster: well it says natty /now/
[22:01] <dash> 'cause I upgraded
[22:01] <dash> but sources.list was all lucid
[22:01] <GrueMaster> Yea, that's what I thought.  It shipped with Lucid, not Natty.  At any rate, oneiric has an image for that platform now.
[22:02] <dash> awesome.
[22:41] <brandini> evening dudes
[22:47] <sniperjo_> in /boot/tools there is a file called update_boot_files.sh, how do i run it ? nothing happens when i chmod +x it
[22:49] <GrueMaster> /boot/tools?  Not one of our directories that I am aware of.
[22:50] <sniperjo_> I'm praying its the answer to all my problems, i want to update boot.scr
[22:53] <brandini> I just did a dist-upgrade to the daily from the 28th