**** BEGIN LOGGING AT Wed Apr 13 02:59:57 2011
Apr 13 04:51:48 <armin76> lol
Apr 13 05:19:19 <steev> yeah... the jaunty thing was surprising to me too
Apr 13 08:17:53 <hrw> they used 9.04 on original sheevaplug and nearly nothing changed probably in rootfs for new devices
Apr 13 09:46:58 <hrw> kgilmer: hi
Apr 13 09:48:06 <kgilmer> hi hrw.  saw your tweet, sorry not enough people in the meeting :/
Apr 13 09:50:24 <hrw> kgilmer: happens
Apr 13 09:50:41 <hrw> kgilmer: I saw Froyo on bug2 post - nice
Apr 13 09:51:22 <kgilmer> thx, yeah good to get a release out on time.  even if no one is using it...
Apr 13 09:56:16 <kgilmer> hrw, dinner calls.  ttyl.
Apr 13 14:58:30 <ppisati> here comes the 1M question: what the heck is musb?
Apr 13 15:31:52 <GrueMaster> ogra: ping.  When you did the netbook image, did you select autologin?
Apr 13 15:32:03 <ogra_> nope
Apr 13 15:32:13 <ogra_> why ?
Apr 13 15:32:18 <ogra_> do you see issues ?
Apr 13 15:32:24 <GrueMaster> Could you retry it?  I want to see if this is just me.
Apr 13 15:32:29 <ogra_> hrm
Apr 13 15:32:37 <GrueMaster> oem-config restarted on my system.
Apr 13 15:36:23 <GrueMaster> I'm going to restart fresh and retest.
Apr 13 15:36:35 <GrueMaster> Then I have to leave for the Dr.
Apr 13 15:39:00 <rsalveti> ogra: will enable the release ppa with our current sgx packages
Apr 13 15:39:14 <rsalveti> then we can test if it's working fine
Apr 13 15:48:49 <GrueMaster> ogra: I am now seeing the color issues on headless oem-config.  Colors are slightly different here, bug fugly none the less.
Apr 13 15:49:11 <GrueMaster> Didn't see this yesterday (nor did I see oem-config, but hey).  :P
Apr 13 15:50:03 <ogra_> GrueMaster, hmm, my test might take a while, cron decided that it wants to run update-apt-xapian index right before the package removal step
Apr 13 15:50:22 <ogra_> so it sitting there now "waiting for apt to finish"
Apr 13 15:50:55 <ogra_> rsalveti, yeah, one of us needs to do that before release
Apr 13 15:51:11 <rsalveti> ogra_: should be done in a few minutes
Apr 13 15:51:16 <ogra_> though the current image still points to maverick
Apr 13 15:51:39 <rsalveti> hm, yeah, saw that you just fixed these bugs
Apr 13 15:51:41 <ogra_> fix is uploaded, but i didnt want a rebuild for that
Apr 13 15:51:49 <GrueMaster> I'll test the ppa packages later today or tomorrow.  After I get the release testing done.
Apr 13 15:52:08 <ogra_> you will have to fiddle with the channel setup first
Apr 13 15:52:14 <GrueMaster> np
Apr 13 15:52:17 <ogra_> else it pulls maverick
Apr 13 15:52:19 <ogra_> k
Apr 13 15:52:48 <ogra_> if you dropped back into oem-config with autologin enabled, the package removal step cant have run
Apr 13 15:53:02 <ogra_> that looks more like an installer crash
Apr 13 15:53:17 <ogra_> (if package removal would have run, there wouldnt be oem-config binaries)
Apr 13 15:53:18 <GrueMaster> Nothing was in the logs.
Apr 13 15:53:26 <GrueMaster> True.
Apr 13 15:54:03 <GrueMaster> Possible SD corruption.  That's why I reflashed and retried.
Apr 13 15:54:27 <ogra_> yup, i found a bad SD too today
Apr 13 15:54:32 <ogra_> my first one actually
Apr 13 15:54:51 <ogra_> i have five worn out USB sticks, but never managed to trash an SD
Apr 13 15:55:17 * ogra_ goes upstairs to see how far the xapian crap is
Apr 13 15:57:08 <GrueMaster> Looks like a normal glitch.  It is in package removal phase now.
Apr 13 15:58:39 <ogra_> yup, finished and logged in automatically here
Apr 13 15:58:51 <GrueMaster> Also, I think I found a uboot issue.  On my beagle (C4), I hold the user button when resetting, then it loads uboot from SD.  But it fails to load the boot.scr from mmc unless I do "mmc init ; mmcinfo".
Apr 13 15:59:03 <GrueMaster> If I don't do mmcinfo, fatload fails.
Apr 13 15:59:18 <ogra_> sounds like a broken u-boot
Apr 13 15:59:39 <ogra_> are you sure the one from SD is actually used in that case ?
Apr 13 15:59:45 <ogra_> (compare the versions)
Apr 13 16:00:51 <GrueMaster> X-Loader 1.5.0 (Apr 11 2011 - 09:47:05) & U-Boot 2011.03-rc1 (Feb 09 2011 - 01:33:04)
Apr 13 16:01:07 <ogra_> sounds fine+
Apr 13 16:01:26 <GrueMaster> MMC: block number 0x1 exceeds max(0x0)
Apr 13 16:01:27 <GrueMaster> ** Can't read from device 0 **
Apr 13 16:01:27 <GrueMaster> ** Unable to use mmc 0:1 for fatload **
Apr 13 16:01:41 <GrueMaster> So I reset and go manual.
Apr 13 16:01:53 <ogra_> well, only C4 ...
Apr 13 16:02:01 <ogra_> we can document around it
Apr 13 16:02:38 <ogra_> as long as xm works fine
Apr 13 16:03:32 <rsalveti> weird, will try to reproduce at my C4
Apr 13 16:03:38 <rsalveti> xm should be fine
Apr 13 16:03:56 <GrueMaster> Yea, xm is fine.  No nand to fall back on.
Apr 13 16:04:11 <GrueMaster> Ok, panda netbook worked this time.
Apr 13 16:04:32 <GrueMaster> Gotta go.  Dr. appt.
Apr 13 16:04:42 <ogra_> good luck
Apr 13 16:05:19 <GrueMaster> Just pulling a few stitches.  I'm getting more mobile each day.  Currently at ~60%.
Apr 13 16:38:17 <alf_> Hi! Currently the omap4 gfx -dev packages replace, provide, conflict: libgles2-dev, libgles2-mesa-dev
Apr 13 16:40:02 <alf_> Is the 'libgles2-mesa-dev' part because some packages only have libgles2-mesa-dev as a dependency instead of libgles2-dev | libgles2-mesa-dev?
Apr 13 16:40:48 <rsalveti> alf_: if you check the mesa package, it's not providing libgles2-dev for example
Apr 13 16:41:02 <rsalveti> it just provides the normal package, not the -dev ones
Apr 13 16:41:20 <rsalveti> that should probably be fixed too
Apr 13 16:41:30 <rsalveti> tried to talk with roaf be got no answer
Apr 13 16:42:16 <rsalveti> alf_: I believe the only package that is depending on the mesa one is the mesa-utils
Apr 13 16:42:34 <rsalveti> most other packages are depending on libgles2-dev | libgles2-mesa-dev
Apr 13 16:43:32 <alf_> rsalveti: and cairo, too
Apr 13 16:43:58 <rsalveti> alf_: hm, why cairo is depending directly on the mesa packages?
Apr 13 16:44:35 <alf_> rsalveti: not sure, just noticed it probably just a mistake
Apr 13 16:44:42 <rsalveti> yeah
Apr 13 16:50:02 <alf_> rsalveti: I will send an email to raof and cc you
Apr 13 16:50:33 <rsalveti> alf_: cool, thanks
Apr 13 16:50:58 <rsalveti> would be good if we could get that fixed before the release
Apr 13 16:53:16 <alf_> rsalveti: so just to be in tune, we want libegl/gles...-mesa-dev to provide/conflict/replace libeg1/gles2...-dev, right?
Apr 13 16:53:59 <rsalveti> alf_: yes, I believe that would be the right solution, but not yet sure, that's why I wanted to talk with raof
Apr 13 16:54:13 <rsalveti> to understand how it's done with GL, and nvidia/radeon drivers
Apr 13 16:55:09 <rsalveti> the libegl1/gles2-dev are needed because we want to depend on something that can be used by the packages
Apr 13 16:55:49 <alf_> rsalveti: yes, we need to come up with guidelines of how to package up alternative drivers... so other vendors can package up correctly
Apr 13 16:56:20 <rsalveti> the only thing it seems weird is that in the end the provided packages for -dev are all the same, even if it's from mesa, sgx or imx
Apr 13 16:56:47 <rsalveti> as the headers should all be the same, provided by khr
Apr 13 16:56:56 <rsalveti> alf_: yes
Apr 13 16:56:58 <alf_> rsalveti: well almost, eg eglplatform.h can be different
Apr 13 16:58:05 <rsalveti> alf_: why? because x11 integration?
Apr 13 17:00:51 <rsalveti> if they are all the same we could just have a common header package
Apr 13 17:01:05 <rsalveti> but not yet sure if they need to be the same
Apr 13 17:01:22 <rsalveti> or if the vendor could also add some other definitions there
Apr 13 17:02:15 <alf_> rsalveti: khronos recommends to use their file (of course ;)) but each vendor may need additional intergration with systems not covered by the default headers
Apr 13 17:03:33 <rsalveti> alf_: hm, ok
Apr 13 17:03:54 <alf_> rsalveti: or variations of existing systems etc for which the default is not suitable
Apr 13 17:05:19 <rsalveti> alf_: but then, if we compile a package with a specific set of headers, is it going to work fine with a different set of libraries?
Apr 13 17:06:17 <rsalveti> if we can't guarantee that then the 'provide' is not necessarily right
Apr 13 17:08:52 <alf_> rsalveti: supposedly, everyone should provide the same (or equivalent) definitions for the same system config
Apr 13 17:09:07 <alf_> rsalveti: Khronos STRONGLY RECOMMENDS that you use the default definitions * provided below, since these changes affect both binary and source * portability of applications using EGL running on different EGL * implementations.
Apr 13 17:09:30 <rsalveti> ogra_: this is the current postinst script for the extra package: http://paste.ubuntu.com/593647/
Apr 13 17:09:55 <rsalveti> ogra_: what do we need to change to fit the unity-2d favorite system?
Apr 13 17:10:43 <rsalveti> alf_: I see
Apr 13 17:11:01 <rsalveti> it should be the same bug we cannot guarantee
Apr 13 17:12:02 <rsalveti> I'd prefer to have a common package set for the headers
Apr 13 17:12:19 <rsalveti> so we can kind of force the vendors to respect the default definitions
Apr 13 17:12:45 <rsalveti> but then, would prefer to discuss this with raof
Apr 13 17:12:56 <rsalveti> to understand if they had the same issues with the normal desktop gl drivers
Apr 13 17:13:33 <rsalveti> alf_: can you put these questions at your email?
Apr 13 17:13:34 <alf_> rsalveti: the thing is that they may want to just extend them and forcing a single set of headers won't do (for them)
Apr 13 17:13:36 <ogra_> rsalveti, unity-2d uses a gconf key for the list of favorites
Apr 13 17:14:02 <ogra_> so some gconftool-2 call that removes the .desktop file from that list is needed
Apr 13 17:14:07 <rsalveti> alf_: yeah =\
Apr 13 17:14:29 <ogra_> though hmm
Apr 13 17:14:52 <ogra_> you can just remove the override file that adds this entry and run update-gconf-defaults
Apr 13 17:15:03 <rsalveti> ogra: first I don't understand why this script was removing the .desktop file
Apr 13 17:15:06 <rsalveti> probably a hack
Apr 13 17:15:14 <ogra_> yes, and still in place
Apr 13 17:15:24 <rsalveti> but why we need to remove it?
Apr 13 17:15:36 <ogra_> because its not comoing from a package
Apr 13 17:15:51 <rsalveti> oh, sure
Apr 13 17:15:56 <rsalveti> once installed it should remove the icon
Apr 13 17:16:04 <rsalveti> as jasper is the one putting it there
Apr 13 17:16:08 <ogra_> right
Apr 13 17:16:32 <rsalveti> ogra_: can you create this new postinst script?
Apr 13 17:16:33 <ogra_> rm /usr/share/gconf/unity-2d/default/25_jasper-favorites-override
Apr 13 17:16:39 <rsalveti> I believe you can easily test at your system
Apr 13 17:16:50 <ogra_> update-gconf-defaults --source /usr/share/gconf/unity-2d/default --destination /var/lib/gconf/unity-2d.default --no-signal
Apr 13 17:16:57 <ogra_> thats what needs to be added
Apr 13 17:17:00 <rsalveti> hm, ok
Apr 13 17:17:31 <ogra_> for oneric i'll finally put some time into doing it with a package
Apr 13 17:17:44 <rsalveti> ogra: so /usr/share/gconf/unity-2d/default/25_jasper-favorites-override is now the file that jasper is installing?
Apr 13 17:18:34 <ogra_> right, it pulls the original favorites list out of the ubity-2d file
Apr 13 17:18:46 <ogra_> and appends the ti .desktop entry
Apr 13 17:19:11 <ogra_> because its a higher sequence number update-gconf-defaults then overrides the default entry
Apr 13 17:20:41 <rsalveti> ogra_: oh, ok
Apr 13 17:21:11 <rsalveti> ogra_: http://paste.ubuntu.com/593654/
Apr 13 17:21:12 <ogra_> so rm'ing it and running update-gconf-defaults again will restore the original system defaults
Apr 13 17:21:36 <ogra_> well, and the .desktop file
Apr 13 17:22:16 <ogra_> you should still remove it to not leave unpackaged cruft around
Apr 13 17:22:27 <rsalveti> yeah, sure
Apr 13 17:22:40 <ogra_> but yes, apart from that thats what should happen
Apr 13 17:23:10 <rsalveti> ogra_: is there any image where I can use to test this?
Apr 13 17:23:19 <rsalveti> with your latest jasper fixes
Apr 13 17:23:28 <ogra_> no
Apr 13 17:23:37 <ogra_> unless someone re-rolls
Apr 13 17:23:43 <rsalveti> hm, ok
Apr 13 17:23:48 <ogra_> but you can manually hack the two files in netbook
Apr 13 17:24:15 <ogra_> /usr/share/app-install/channels/ has the files
Apr 13 17:24:28 <ogra_> you want to modify .list
Apr 13 17:24:46 <ogra_> (indeed before clicking the TI icon)
Apr 13 17:24:55 <rsalveti> sure
Apr 13 17:30:43 <rsalveti> ogra_: should we also remove the ti-ppa.svg or we can't?
Apr 13 17:31:06 <ogra_> rsalveti, that should probably go too, yeah
Apr 13 17:31:17 <rsalveti> ogra_: ok
Apr 13 17:33:59 <rsalveti> ok, I'm upgrading my natty rootfs and should be able to test it soon
Apr 13 21:06:54 <GrueMaster> ogra: That oem-config restart issue I saw earlier on panda netbook I am seeing again on my beagleXM.
Apr 13 21:07:07 <GrueMaster> Way more than possible coincidence.
Apr 13 21:14:11 <jcrigby> rsalveti, we would like to update u-boot but obviously do not want to break you guys in the process.   My proposed branch is here:https://code.launchpad.net/~jcrigby/ubuntu/natty/u-boot-linaro/proposed-2011.04.1  slangasek  is working on merging it
Apr 13 21:14:54 <rsalveti> jcrigby: we should be fine with it, did you test with latest x-loader with both omap3 and 4?
Apr 13 21:14:55 <jcrigby> rsalveti, the reason is device tree support needs to be there for Linaro 11.05 release
Apr 13 21:15:02 <jcrigby> yes
Apr 13 21:15:16 <rsalveti> jcrigby: hm, ok
Apr 13 21:15:59 <rsalveti> jcrigby: will test it with our images here, ping you back once it's done
Apr 13 21:16:40 <jcrigby> thanks, I realize I may not have latest x-loader.  An update happened but flash kernel didn't like my arch name
Apr 13 21:16:56 <jcrigby> not sure if latest was in the last hwpack I downloaded
Apr 13 21:17:07 <jcrigby> I will test again
Apr 13 21:17:44 <rsalveti> jcrigby: ok, latest one was uploaded at the beginning of this week
Apr 13 21:18:01 <jcrigby> ok, my hwpack was from last week
Apr 13 21:48:13 <dcarr_home> Hey
Apr 13 21:48:53 <dcarr_home> Are there any good opengl examples in the ubuntu 10.10/TI ppa for testing OpenGL (ES) support on the panda board?
Apr 13 21:49:01 <dcarr_home> any help would be greatly appreciated
Apr 13 22:07:37 <rsalveti> dcarr_home: if you build the mesa-utils package available at natty you'll be able to run es2gears
Apr 13 22:07:50 <rsalveti> a nice and simple example
Apr 13 22:23:24 <GrueMaster> rsalveti: Is the edid detect code in the omap kernel yet?
Apr 13 22:25:22 <rsalveti> GrueMaster: nops
Apr 13 22:25:34 <GrueMaster> ok.
Apr 13 22:33:44 <dcarr_home> rsalveti: thanks
Apr 13 23:17:16 <jcrigby> rsalveti, just to let you know.  I have now tested the proposed u-boot with the latest x-load on panda and beagle
Apr 13 23:17:21 <jcrigby> beagle c4
Apr 13 23:18:12 <rsalveti> jcrigby: yeah, just tested fine on panda, xM and at my c4
Apr 13 23:18:20 <rsalveti> I'm now booting at my b5
Apr 13 23:18:58 <jcrigby> rsalveti, thanks for doing that
Apr 13 23:28:24 <rsalveti> jcrigby: http://paste.ubuntu.com/593805/
Apr 13 23:28:26 <rsalveti> at my B5
Apr 13 23:30:34 <rsalveti> jcrigby: same sd card works fine at my C4
Apr 13 23:30:58 <rsalveti> jcrigby: could be a regression, just don't know exactly which upload could be the culprit one
Apr 13 23:31:06 <rsalveti> quite a while that I don't test it with my B5
Apr 13 23:31:33 <jcrigby> hmm
Apr 13 23:31:48 <rsalveti> let me flash a maverick sd card and we can start tracing it
Apr 13 23:31:55 <rsalveti> want also to make sure it's not the x-loader
Apr 13 23:31:58 <jcrigby> ok
Apr 13 23:31:58 <rsalveti> or not a hardware issue
Apr 13 23:42:01 <rsalveti> jcrigby: yup, 2010.09-rc1 from maverick worked fine
Apr 13 23:42:17 <rsalveti> so it's a regression
Apr 13 23:43:43 <jcrigby> ok, thanks
Apr 13 23:44:02 <rsalveti> will try with the one we're using, then I can just open a bug for it
Apr 13 23:44:12 <rsalveti> using at the image
Apr 13 23:44:47 <rsalveti> also, let me first update just the x-loader
Apr 13 23:45:13 <jcrigby> ok, so latest in archive is also broken?
Apr 13 23:45:19 <jcrigby> for B5
Apr 13 23:50:21 <rsalveti> jcrigby: trying now
Apr 13 23:50:29 <rsalveti> jcrigby: worked fine with latest x-loader
Apr 13 23:50:37 <rsalveti> so it's probably a regression at u-boot
Apr 13 23:51:15 <jcrigby> ok
Apr 13 23:52:34 <rsalveti> jcrigby: yup, broken
Apr 13 23:57:50 <rsalveti> jcrigby: https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/760350
Apr 13 23:58:18 <jcrigby> so 2011.02.1 is also broken
Apr 13 23:59:06 <jcrigby> rsalveti, I believe that is what is the latest in the archive right?
Apr 13 23:59:11 <rsalveti> jcrigby: yes
Apr 14 00:00:06 <jcrigby> and we don't  know when the regresson happend.  Just sometime between 2010.09 and 2011.02.1
Apr 14 00:00:26 <jcrigby> rsalveti, this is going to be fun
Apr 14 00:00:37 <rsalveti> jcrigby: haha, yeah :-)
Apr 14 00:00:59 <rsalveti> there's also a new error with latest u-boot: timed out in wait_for_pin: I2C_STAT=0
Apr 14 00:01:09 <rsalveti> but can be normal, probably trying to identify the expansion board
Apr 14 00:01:14 <rsalveti> but would be good to check
Apr 14 00:01:43 <jcrigby> yes, I saw that too, I will make sure it is expected with no expansion board
Apr 14 00:02:43 <TheMuso> ogra_: FYI, threw in another patch from upstream for UCM. It basically enables UCM only for devices that have a UCM argument setin the udev rules, which should now cover OMAP4.
Apr 14 00:03:01 <rsalveti> jcrigby: will be out for dinner, should be back in one hour, then we can try to bisect it
Apr 14 00:03:28 <TheMuso> ogra_: So source should b epublished by the time you get online.
Apr 14 00:04:52 <jcrigby> rsalveti, I will be out then so may need to wait until tomorrow.  I will be back later tonight I will ping you.
Apr 14 00:05:32 <rsalveti> jcrigby: sure, np
Apr 14 00:10:46 <jcrigby> sakoman, ping?
Apr 14 00:16:11 <GrueMaster> TheMuso: Does that also cover omap?  It will have UCM support as well, hopefully by next week.
Apr 14 00:16:25 <TheMuso> GrueMaster: Yes it does.
Apr 14 00:16:30 <GrueMaster> Excellent.
Apr 14 00:16:36 <TheMuso> As I said, the udev stuff is to cover omap4
Apr 14 00:18:13 <GrueMaster> OK.  That looks like jack detection, which isn't needed for beagle/beaglexm but may be needed for other omap based systems.  Not worried about it now.
Apr 14 00:19:17 <TheMuso> Its not jack detectino. It basically uses a definition in the pulse udev rule to tell pulse to enable UCM only for omap4, which reduces regression potential for other hadrware.
Apr 14 00:19:59 <GrueMaster> Oh.  Hmmm.  I'll have to look over the patches again.
Apr 14 00:21:18 <GrueMaster> This is from PA_UCM_patches_20110407.tar.bz2 right?
Apr 14 00:21:40 <TheMuso> No, its another one that was sent to david and myself.
Apr 14 00:21:58 <GrueMaster> Not attached to the bug?  Hate when that happens.
Apr 14 00:22:00 <TheMuso> Its in teh package I just uploaded to my PPA.
Apr 14 00:22:05 <GrueMaster> ok
Apr 14 00:22:11 <TheMuso> I'll attach it to the bug if you'd like.
Apr 14 00:22:28 <GrueMaster> It makes tracking easier, but I can find it.
Apr 14 00:22:42 <TheMuso> ok
Apr 14 00:41:16 <jcrigby> rsalveti: http://comments.gmane.org/gmane.linux.distributions.gumstix.general/57467
Apr 14 00:41:38 <jcrigby> looks like multiblock reads are broken in older omap silicon
Apr 14 02:07:55 <rsalveti> jcrigby: yeah, that makes sense
Apr 14 02:08:58 <rsalveti> jcrigby: will try that patch
Apr 14 02:16:59 <NCommander> rsalveti: re: IC2_ERROR, almost certian that error has to deal with the expansion port.
Apr 14 02:17:16 * NCommander is catching up on backscroll)
Apr 14 02:17:27 <rsalveti> yup, probably
Apr 14 02:29:12 <jcrigby> rsalveti, I'm going to do a patch that would be acceptable to upstream.  Something like what gcl suggests in the thread.
Apr 14 02:29:22 <jcrigby> rsalveti, that is if it works for you
Apr 14 02:29:38 <rsalveti> jcrigby: cool, sure
Apr 14 02:44:56 <rsalveti> jcrigby: yup, worked fine
Apr 14 02:45:15 <jcrigby> great!, thanks
Apr 14 02:49:30 <rsalveti> GrueMaster: ogra_: https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/760350
Apr 14 02:49:41 <rsalveti> this should be at the beta-2 release notes
Apr 14 02:49:59 <rsalveti> our image doesn't work with older beagles, probably <= rev B5
Apr 14 02:50:15 <rsalveti> jcrigby: just updated the bug with the test result
Apr 14 02:50:49 <GrueMaster> Ok.  Very odd, but I'm not sure we really even support hw <512M (except maybe headless).
Apr 14 02:51:47 <jcrigby> GrueMaster, that might explain why this problem has never been reported
Apr 14 02:52:22 <GrueMaster> I've seen my own issues with u-boot on beagle C4.  Currently, when I reboot I hold the user button to load x-loader & uboot from SD, but my bootcmd fails.
Apr 14 02:54:56 <GrueMaster> bootcmd=bootcmd=mmc init;mmcinfo;if fatload mmc 0 0x82000000 boot.scr;then echo boot.scr found! Executing ...;source 0x82000000;fi
Apr 14 02:55:12 <GrueMaster> It would fail without the mmcinfo.
Apr 14 02:56:29 <rsalveti> GrueMaster: headless image can be useful for those old boards
Apr 14 02:56:47 <rsalveti> GrueMaster: can be be used to be a small server, or something like that
Apr 14 02:56:55 <GrueMaster> yes, I realize that.  That's why I dusted mine off and have it hooked up.
Apr 14 02:57:26 <GrueMaster> I usually install openssh, and basic server.
Apr 14 02:57:28 <rsalveti> we don't expect it to work fast, but it should at least boot :-)
Apr 14 02:58:22 <GrueMaster> Fast is relative to the bottlenecks in the environment.  For a printerver, it should be great (haven't tested yet).
Apr 14 02:58:52 <rsalveti> yeah
Apr 14 02:59:36 <GrueMaster> Unfortunately, my office is in flux and need of an overhaul (hopefully this weekend).
**** ENDING LOGGING AT Thu Apr 14 02:59:58 2011