[01:28] <jo-erlend> what kind of performance can I expect from OMAP4? Is it capable of running a monitor in fullhd and play movies without problems?
[01:36] <GrueMaster> jo-erlend: I have seen a single panda play 1080p movies on two screens.  Yes it can.
[01:37] <jo-erlend> wow. Nice. :)
[01:38] <jo-erlend> GrueMaster, I'm very interested in a pandaboard. How much difficulty will I have installing Ubuntu on it+
[01:38] <jo-erlend> ?
[01:39] <GrueMaster> Not hardly any..  Just follow the info on the wiki (see room topic).
[01:39] <jo-erlend> and since you seem to have some experience with it... If you should compare it to a PC... What kind of PC would be comparable?
[01:40] <GrueMaster> Probably an atom based system in overall performance.  The only real downside is there isn't a SATA port, so you don't get as good of HD IO performance.
[01:41] <GrueMaster> The panda is essentially a cell phone development platform, but it can be good for other uses like set top boxes, wifi access point, and even some server tasks.
[01:44] <jo-erlend> it is a long time since PCs surpassed my needs, so I'm considering replacing my desktop with an ARM board. I was thinking about waiting for the OMAP5, but when I look at the specs for pandaboard, it seems like a potential candidate.
[01:44] <jo-erlend> the specs doesn't tell me as much though. You can't compare CPU speeds between an x86 and an ARM, right?
[01:46] <GrueMaster> Not really.  Pandas run at something like 1.2Ghz, and on some tasks (like video playback) they are more than sufficient.  Other tasks, like heavy duty builds (think rebuild of openoffice) it lacks a lot.
[01:47] <jo-erlend> sure. But I don't do that. I surf a little bit and I write some python code. That
[01:47] <jo-erlend> s mostly it.
[01:48] <jo-erlend> well, except for playing movies and such.
[01:48] <GrueMaster> And overall cpu speed can be a real misnomer (more of a marketing tool than anything).  I spent 8 years at Intel doing processor validation, and back in the day, the mobile processors based on the PIII would outperform the desktop P4 based processors at half the clock rate.
[01:48] <jo-erlend> the OMAP3 was a little bit too slow and didn't support 1080p, but it seemed very close to acceptable.
[01:48] <GrueMaster> For the tasks you are looking at, it should be able to handle that fine.
[01:48] <jo-erlend> GrueMaster, exactly.
[01:49] <jo-erlend> great :)
[01:49] <jo-erlend> and the dollar is cheap as well. That's a good bonus. Guess I'll get myself a couple to play with.
[01:51] <GrueMaster> Heh.  I have 6.
[01:51] <jo-erlend> yes, but you're a pro :)
[01:52] <GrueMaster> These are personally bought.  Only one was provided.  But I can write them off at tax time.
[01:52] <jo-erlend> one thing I thought I could use it for, is to attach it to a VESA wall-mount and connect it to a TV. The HDMI would transmit audio to the TV, right?
[01:52] <GrueMaster> Yes.  Actually, hdmi audio works better sometimes than analog.
[01:53] <jo-erlend> great. So then I'd install Synergy on it and I could control it with a laptop. That ought to be cool :)
[01:56] <jo-erlend> wonder if OMAP5 will come with USB3 support.
[01:57] <michaelh1> jo-erlend: I'd be surprised.  You need a ton of bandwidth...
[01:58] <jo-erlend> michaelh1, that's probably why I want it :)
[01:59] <michaelh1> jo-erlend: yeah, something that isn't USB like SATA would be nice...
[01:59] <jo-erlend> yes, but is it likely that it'll provide both USB and SATA?
[02:00] <jo-erlend> other than that, these things seems kinda perfect for a home mikroserver.
[02:01] <michaelh1> jo-erlend: SATA seems unlikely on a phone targeted OMAP5.  The Samsung Orion has a port though, but I don't know if it works.
[02:05] <jo-erlend> I'm amazed by how cheap they are.
[02:06] <jo-erlend> I grew up with 8088 and 8086. Everything is amazing nowadays,, come to think of it :>
[05:13] <twb> Is ubuntu arm equivalent to debian's armhf?  From the wiki page in /topic it looks like it, except maybe the thumb2 stuff.
[05:14] <twb> Hm, that page has "How does this differ from Debian's armel port?" but not the same for Debian armhf
[06:29] <julumme> is there a known fix for the headless natty image on beagleboard to get the network interface up ?
[06:30] <julumme> already in the system configuration phase, it complains that there were no network interfaces detected
[06:31] <julumme> (I suppose technically the image "headless omap" image for natty
[07:10] <janimo> anyone running oneiric with latest kernel on the panda? 3.0.0-1203-omap4
[07:11] <janimo> I get no ethernet with it
[07:12] <janimo> twb, ubuntu arm is armel not armhf. It uses the soft-float ABI. There is work going on to have armhf ubuntu port by next cycle
[07:12] <twb> OK, thanks.
[07:14] <twb> Probably not as big a deal for me, I'm looking at the ASUS TF101, which is A9 not A8
[07:15] <janimo> A9 vs A8 have mostly performance differences, but otherwise the same core architecture. Orthogonal to armel vs armhf
[07:16] <twb> the wiki.d.o armhf post said they saw 40% speed improvements on A8, but expect smaller benefits for A9
[07:16] <twb> "It's likely that the performance benefits are much larger on Cortex-A8 CPUs than on Cortex-A9 CPUs which have a faster VFP design and more conventional pipeline."
[07:16] <twb> http://wiki.debian.org/ArmHardFloatPort
[07:18] <erbo> I want to create a rootfs using rootstock, but with some custom packages that I want to host on a local repo. I figured I could use the --extra-mirror file:///path/to/repo, but it seems to me as if it only accepts ubuntu-mirrors. It complains about not finding the repo/dists/natty/main/binary-armel/Packages file. I just created a minimal repo using dpkg-scanpackages hoping that would work.
[07:19] <erbo> Any pointer to what I need to do to get custom packages into a rootstock build?
[07:27] <twb> Any multistrap fanboys in the audience?
[07:43] <lag> ogra_: You still alive?
[08:14] <lilstevie> twb: biggest issue in A8 vs A9 is that nVidia decided to kill us all by not including the NEON instruction set
[08:14] <lilstevie> A8's could all run with NEON if we wanted
[08:14] <twb> Yeah, I saw that
[08:15] <lilstevie> that is going to be probably the biggest drawback with all hardfloat, catering for the one backwards company
[08:15] <twb> You don't need to convince me that nv are douchebags
[08:15] <twb> If there was a strong alternative to the TF101 I'd probably be looking at that instead, just to avoid nv
[08:34] <janimo> lilstevie, I was not under the impression that neon is part of hardfp ABI. It is an optional extension to VFP
[08:34] <janimo> one should still have armhf with optional neon
[08:35] <twb> Marvell Dove also lacks NEON
[08:35] <lilstevie> janimo: it isn't no, just it is a hinderencce to not have it
[08:35] <janimo> right. tegra3 is supposed to have neon
[08:36] <twb> I saw arm's Cortex-A15 page, and that also said NEON, so I guess all A15s have NEON
[08:37] <lilstevie> janimo: I just mean like the likes of nv and marvell not including NEON are holding hf back
[08:38] <twb> At least it's better than armel
[08:39] <lilstevie> heh true
[08:40] <twb> So does the TF101 just use normal nouveau/nvfb/nvidia GPU drivers?
[08:40] <lilstevie> it uses the Linux4Tegra GPU drivers if you are using the right kernel
[08:40] <lilstevie> otherwise fbdev
[08:42] <twb> lilstevie: is your git repo based on the one at git://nv-tegra.nvidia.com/linux-2.6.git ?
[08:43] <Neko> armhf doesn't rely on NEON at all
[08:43] <Neko> what's holding what back?
[08:43] <lilstevie> twb: no, it is based off the asus source drop + patched up using the android kernel.org repo
[08:44] <twb> Hm, OK
[08:44] <lilstevie> twb: however the one that allows acceleration is based off the chromeos kernel tree
[08:44] <twb> Grmph, yet another tree
[08:44] <twb> I hope all this work gets merged into the mainline at some point
[08:47] <ogra_> lag, i am now :)
[09:00] <lag> ogra_: Hey
[09:00] <ogra_> yo
[09:00] <lag> ogra_: On my snowball, when I start xterm using the serial console ...
[09:00] <lag> ogra_: It starts but I can see lots of 1111111111111111111111111111's appear
[09:00] <lag> ogra_: Any ideas?
[09:00] <lag> ogra_: No keyboard is connected
[09:01] <ogra_> are the serial settings correct ?
[09:02] <ogra_> or wait, you export DISPLAY and run it from serial ?
[09:02] <lag> The 11111111111111's aren't appearing on the serial console
[09:02] <lag> Yeah
[09:02] <ogra_> hmm
[09:02] <ogra_> check ~/.xsession-errors
[09:02] <ogra_> and /var/log/Xorg.0.log
[09:02] <ogra_> if there are input layer issues you should see it there
[09:04] <lag> ogra_: http://paste.ubuntu.com/673646/
[09:06] <ogra_> line 3 is intresting
[09:07] <ogra_> that doesnt look like an xterm though
[09:08] <ogra_> your power manager looks pretty unhappy ... but that shouldnt print 1111
[09:10] <ogra_> to be honest i dont see anything that could cause this but i also dont see any indication of an xterm session
[09:10] <diwic> ogra_, have you started to run omap etc tests on oneiric yet?
[09:10] <ogra_> diwic, what kind of tests ?
[09:10] <ogra_> GrueMaster tests the images regulary
[09:10] <diwic> ogra_, checking if things work? E g the new pulseaudio version
[09:10] <ogra_> no, i dont think we have tested that much yet
[09:11] <ogra_> everyone is so focused on server stuff atm, i'll make sure we test it asap
[09:11] <diwic> ogra_, as the UCM patches are currently not included
[09:11] <diwic> and I haven't heard you scream about it ;-)
[09:11] <ogra_> i think the 3.0 kernel for omap4 also lacks alsa bits atm
[09:11] <ogra_> i have to check that forst ...
[09:11] <ogra_> *first
[09:12] <ogra_> (i'm currently a bit focused on ac100 work and getting the last beta workitems done)
[09:13] <diwic> ogra_, no sound news on ac100, I assume?
[09:14] <ogra_> diwic, no, suspend made some progress but sond not yet
[09:14] <ogra_> *sound
[09:16] <diwic> okay
[09:16] <diwic> yeah, hadn't had a moment to do anything here either
[10:16] <ogra_> janimo, hey, i added mx5 to cdimage and fired off a first livefs testbuild
[10:16] <janimo> ogra_, cool
[10:16] <ogra_> for server (so archive skew doesnt bite us)
[10:16] <janimo> thanks
[10:16] <ogra_> lets see if something comes out at the rear end :)
[10:17] <ogra_> janimo, do we have a landing page for mx5 install instructions etc ?
[10:17] <janimo> this makes the live image, but did you add the boot/post-boot scripts too?
[10:17] <janimo> ogra_, only the linaro one
[10:18] <janimo> I'll add one to our wiki once we have the images
[10:18] <ogra_> http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20110824.1/ ... have a look, i re-arranged the arch specific bits for preinstalled images a bit, mx5 will currently just say "For i.MX5x boards"
[10:18] <ogra_> but i think it would be good if it also pointed to a wikipage with instructions
[10:20] <janimo> ogra_,  will push here as well bzr+ssh://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/ ?
[10:20] <ogra_> or just pastebin the change and i'll add it
[10:25] <janimo> ogra_, skeleton page: https://wiki.ubuntu.com/ARM/MX5
[10:26] <janimo> I wonder if they could work on MX51 too, the kernel supports it.
[10:26] <janimo> Although if Uboot, as I suspect is different, it is too much to add mx51 back
[10:27] <ogra_> well, i left everything generic for now in the texts
[10:27] <ogra_> k, i'll add that page to the arch stuff
[10:28] <ogra_> that page can then have instructions how to modify the image for mx51
[10:29] <ogra_> (if thats possible by i.e. just replacing u-boot.bin
[10:29] <ogra_> )
[10:35] <ppisati> janimo: it seems the .ddeb kernel pkg should do it (at least it works for i386 and amd64), testing it now...
[10:35] <ppisati> janimo: talking about the systemtap support
[10:48] <janimo> ppisati, thanks. There may be binaries already, but then I just did not find them :)
[10:48] <janimo> the linaro systemtap wikipage points to some older binaries
[10:52] <ogra_> Building dependency tree...
[10:52] <ogra_> E: Unable to locate package linux-mx5
[10:52] <ogra_> E: Unable to locate package linux-meta-linaro-lt-mx5
[10:52] <ogra_> P: Begin unmounting filesystems...
[10:52] <ogra_> janimo, ^^^
[10:53] <ogra_> seems to need some livecd-rootfs changes
[10:54] <janimo> ogra_, I wrote that part before the packages landed, but I thought I had gotten the names right .hmm
[10:55] <ogra_> janimo, i guess thats the automatic bit trying to do the generic kernel installation
[10:55] <ogra_> it somehow assembles the package name from flavour etc
[10:55] <janimo> ah linux-image-linaro-lt-mx5
[10:56] <janimo> oh, so the naming convention of the package is not in line with others? :(
[10:56] <ogra_> it has linaro in the package name
[10:56] <ogra_> it should still work if you seed it as you do atm though
[10:59] <janimo> ogra_,I  will commit a change
[11:00] <ogra_> yep, tell me if it hits ports.u.c, then i can trigger a new build
[11:00] <ogra_> s7if/when/
[11:01] <janimo> although I wonder where the linux-mx5 was gotten from, that is not put in the file
[11:01] <janimo> is that the automatically generated name?
[11:02] <ogra_> likely, yes
[11:02] <ogra_> infinity knows that code deeper :)
[11:02] <ogra_> i never know where he pulls the code snippets from he shows me :P
[11:03] <janimo> I had the source package name added initially, before it was built and  I thought binary name would match
[11:04] <ogra_> yeah, with the binary it shoudl work, if not, we need to dig deeper and add it to the pattern that aut-creates the package names
[11:04] <ogra_> though i fear that will get hairy, while adding -linaro- might be trivial, adding the -lt- could get tricky
[11:05] <ogra_> you could indeed most easily work around it by just making the meta create a binary linux-mx5 metapackage :)
[11:05] <janimo> ogra_, it is probably linux-$SUBARCH
[11:06] <janimo> we have linux-omap omap4 and ac100
[11:06] <janimo> but not linux-ac100
[11:06] <ogra_> we do
[11:06] <ogra_> linux-ac100 exists
[11:06] <janimo> sorry, but not linux-mx5
[11:06] <ogra_> yeah
[11:06] <janimo> contradicted myself above
[11:08] <janimo> the linux-SUBARCH packages just seem to depend on the generic image binary
[11:09] <janimo> not sure why the indirection
[11:09] <janimo> jcrigby, ^. Would it be too much hassle or counter to linaro naming conventions to provide a linux-mx5 package that depends on the current generic mx5 image ?
[11:10] <janimo> that is the way ubuntu kernel packages are from what I see
[11:11] <ogra_> Package: linux-mx5
[11:11] <ogra_> Architecture: armel
[11:11] <ogra_> Section: metapackages
[11:11] <ogra_> Priority: optional
[11:11] <ogra_> Depends: ${misc:Depends}, linux-image-linaro-lt-mx5 (= ${binary:Version})
[11:11] <ogra_> Description: ....
[11:12] <ogra_> just add that bit to debian/control in the linux-meta-linaro-lt-mx5 package
[11:13] <ogra_> (and massage the new binary through the NEW queue)
[11:22] <janimo> I just had my first relatively pleasant UDD experience (hope it also gets built :). First time I did not spend more on looking up debcommit & co docs for more than 5 minutes
[11:22] <janimo> I do packaging so seldom that I keep forgetting how UDD works :(
[11:22] <ogra_> i stay away from if if i can ...
[11:23]  * ogra_ still prefers dealing with source packages
[11:23] <janimo> hack code + changelog ||  debcommit || hack changelog || debcommit -r || bzr push || bzr bd -S || dput
[11:23] <janimo> UDD in a tweet :)
[11:28] <hrw> how sync requests should go now?
[11:28] <hrw> gtk-gnutella 0.97-2 needs to be synced to fix bug 823709
[11:28] <ubot2> Launchpad bug 823709 in gtk-gnutella "gtk-gnutella version 0.97-1 failed to build on armel" [Unknown,Fix released] https://launchpad.net/bugs/823709
[11:29] <ogra_> use the requestsync script as usual ?
[11:29] <hrw> ok
[11:33] <hrw> bug 832692 then
[11:33] <ubot2> Launchpad bug 832692 in gtk-gnutella "FFe: Sync gtk-gnutella 0.97-2 (universe) from Debian sid (main)" [Wishlist,New] https://launchpad.net/bugs/832692
[12:37] <ogra_> janimo, new livefs mx5 build running
[12:46] <janimo> ogra_, works without the linux-mx5 metapackage?
[12:46] <ogra_> no idea, running
[12:46] <ogra_> didnt fail yet
[12:47] <ogra_> though that usually takes a while
[13:06] <ogra_> janimo, ...
[13:06] <ogra_> Reading package lists...
[13:06] <ogra_> Building dependency tree...
[13:06] <ogra_> E: Unable to locate package linux-mx5
[13:06] <ogra_> P: Begin unmounting filesystems...
[13:07] <janimo> ogra_, right, the missing meta package , as expected
[13:07] <ogra_> well, i had hopes we could get around it
[13:08] <janimo>  did you work around it elsewhere?
[13:08] <ogra_> nope
[13:08] <ogra_> i was hoppig it is clever enough to recognize that we have a kernel in place already
[13:09] <ogra_> but it apparently isnt, so we should change the metapackage
[13:11] <janimo> right
[13:12] <janimo> jcrigby, ogra https://bugs.launchpad.net/ubuntu/+source/linux-meta-linaro-lt-mx5/+bug/832744
[13:12] <ubot2> Ubuntu bug 832744 in linux-meta-linaro-lt-mx5 "please provide linux-mx5 meta-package binary" [Undecided,New]
[13:26] <jcrigby> janimo, ogra_ : looking at your conversation above...
[13:26] <ogra_> you should be able to just copy/paste what i dumped into the channel above
[13:28] <jcrigby> ogra_, and that replaces this:Depends: ${misc:Depends}, linux-image-${kernel-abi-version}-linaro-lt-mx5, linux-firmware
[13:28] <ogra_> just add it additionally to the existing bits
[13:29] <ogra_> (not replacing anything, i assume teh existing binaries have a usecase)
[13:30] <jcrigby> ogra_, ahh ok, this is a section that disappeared in my first meta for linaro the the linaro build was changed to deal with it.  Sorry, I didn't really have a clue what I was doing back then.  Still fuzzy on some things even now:)
[13:30] <ogra_> no, what you did is perfectly fine for your typical packages
[13:31] <ogra_> its just if we want to use your kernel with the ubuntu buildsystem that a package named linux-$flavour needs to exist
[13:31] <jcrigby> got it
[13:31] <ogra_> if you would have done the same with omap i would have shouted ;)
[13:31] <jcrigby> ok, thats easy, I'll do it right now
[13:31] <ogra_> since there we have linux-omap already and that would clash
[13:31] <ogra_> mx5 is special here
[13:32] <jcrigby> ahh
[13:33] <ogra_> janimo, if that change has landed you can actually drop everything but the bootloader stuff from your live-build/auto/config line
[13:36] <ogra_> GrueMaster, why did you set preseed testing for preinstalled to BLOCKED ? i thought we talked about that before your vac. presseding works fine but you have to do it on cmdline
[13:37] <ogra_> (that shouldnt block testing)
[13:52] <janimo> ogra_, in debian-cd what is the separation of boot and post-boot scripts for?
[13:52] <janimo> the different subarchs do not use those consistently
[13:53] <ogra_> you likely wont need boot
[13:55] <ogra_> post-boot is fine, ignore the other
[13:55]  * janimo learns about apt-cache policy
[13:55] <janimo> ogra_, ok
[13:58] <infinity> ogra_, jcrigby : Don't make a linux-mx5 metapackage, it will break some other code assumptions.
[13:58] <infinity> janimo too.
[13:58] <ogra_> infinity, huh ?
[13:58] <infinity> I have to run to a doctor's appointment, but I'll help you deal with this in a sec.
[13:58] <infinity> ogra_: Just trust me.
[13:58] <ogra_> why ? it doesnt break for ac100 either
[13:58] <infinity> ogra_: It doesn't break for ac100 because ac100 is actually your kernel flavour.
[13:58] <infinity> mx5 isn't.
[13:58] <ogra_> weird ... but we'll wait for enlightenment :)
[13:59] <jcrigby> ok, I'll wait for you smart folks to figure this out before pushing anything
[13:59] <infinity> Anyhow.  Back ina couple of hours.  Tonsil specialist appointment. :/
[13:59] <ogra_> mx5 isnt ? what does uname have ?
[13:59] <ogra_> oh my, good luck
[13:59] <infinity> linaro-lt-mx5
[13:59] <ogra_> urgh
[13:59] <infinity> *runs*
[14:00] <ogra_> janimo, so seems we need to change the pattern matching in livecd-rootf
[14:00] <ogra_> s
[14:00] <ogra_> (or live-build effectively)
[14:02] <infinity> Before I run..
[14:03] <infinity> In the SUBARCH case statement, something like FLAVOURS=linaro-lt-mx5 in the mx5 case statement should do the trick.
[14:03]  * ogra_ must admit he doesnt really get why uname has any influence though, given we dont actually run the kernel
[14:03] <infinity> Since FLAVOURS normally is jst set to SUBARCH.
[14:03] <ogra_> ah, cool, thats easy
[14:03] <infinity> ogra_: There's pattern matching elsewhere that makes it matter.
[14:04] <ogra_> ah
[14:04] <infinity> ogra_: Since uname also lands in the filenames.
[14:04] <infinity> Kay, gone now. :)
[14:04] <ogra_> of the build host ?
[14:04] <ogra_> weird
[14:04] <infinity> ogra_: No, uname of the kernel is in the filenames of the kernel and initrd, and we pattern match on those like craz.
[14:04] <infinity> crazy*
[14:04] <ogra_> ah, k
[14:04]  * ogra_ gets it now
[14:06] <ogra_> aha
[14:06] <ogra_> KERNEL_FLAVOURS="${SUBARCH:-$KERNEL_FLAVOURS}"
[14:10] <ogra_> ok, the var is actually LB_LINUX_FLAVOURS
[14:10] <ogra_> janimo, ^^^
[14:14] <ogra_> LB_LINUX_FLAVOURS="linaro-lt-mx5" should work
[14:50] <infinity> ogra, janimoe: set kernel_flavours, not the lb_ variable.
[14:50] <infinity> forgive the awful typong, lag on my phone in the waoting room sucks. :P
[14:52] <infinity> janimo ^
[15:05] <janimo> infinity, I need to find those things
[15:07] <infinity> janimo: the same case statement where you add you botloader packages for mx5, just set KERNEL_FLAVOURS to linaro-lt-mx5
[15:07] <infinity> janimo: and you don't need to explicitely install the kernek too, that variable will handle it.
[15:08] <janimo> infinity, I see only core uses that variable ATM
[15:09] <infinity> janimo: I can hep less awkwardly later today when I'm not typing on a touch screen with 3s latency.
[15:09] <infinity> janimo: it's set 10 lines up to SUBARCH, which you don't want, hence overriding it in the mx5 case.
[15:10]  * janimo wishes for a detailed dump of infinity's and other cdimage connoisseurs'  brains into a wiki or something that can feed into other people's heads
[15:10] <janimo> infinity, thanks. Let's hope this change will move things forward.
[15:10] <janimo> does the linux-mx5 metapackage still has a purpose then?
[15:11] <infinity> Theree shouldn't be one.
[15:11] <janimo> this looks again like last cycle's headless-image taks, which I was assigned to and took me about 10 times as much as it would have for someone who know cdimage. Oh well
[15:12]  * janimo tries out his still fresh UDD skills again on livecd-rootfs
[15:13] <infinity> Kay, actually out of the waitong room now.  Doctor time, back later.
[15:37] <GrueMaster> ogra_: on the preseed thing, you also told me that you needed to do something in jasper to get it to work.  So I marked it as BLOCKED until that happens.
[15:38] <GrueMaster> In fact, you still have a work item to that affect.
[15:44] <hrw> bug 809760
[15:44] <ubot2> Launchpad bug 809760 in unison2.27.57 "unison2.27.57 version 2.27.57-4 failed to build on armel" [Undecided,New] https://launchpad.net/bugs/809760
[15:44] <hrw> can someone push 'retry build' on this page: https://launchpad.net/ubuntu/+source/unison2.27.57/2.27.57-4/+build/2620947
[15:44] <hrw> ?
[16:02] <ogra_> GrueMaster, that WI is for one specific preseed option to switch serial on/off ... preseeding in general works fine if syou do it on the cmdline
[16:02] <ogra_> what doesnt work yet (but will hopefully tomorrow) is using a preseed file in the vfat ... that shouldnt block testing preseeding in general though
[16:04] <GrueMaster> I would prefer to test all options at once.  I don't want to test it now and mark it DONE only to have it reverted yet again because I didn't test yet another as of yet un-implemented feature.
[16:06] <ogra_> k
[16:07] <ogra_> grr, my machine is wonky
[16:13] <austeregrim> ogra_ keep up the good work =)
[16:59] <rajendra> Hi, can anyone pls let me know if USB OTG as Host is working on panda board, on Ubuntu, kernel 2.6.38