[00:28] <who_> I just tried to build a Lucid rootfs with rootstock but it doesn't seem to work when I try and boot it in qemu. rootstock didn't look to finish cleanly but there wasn't a good error message - I dug the image, rootfs and log out of the tmp directory. I was using debotstrap from Karmic, but I got the latest rootstock from launchpad and ran the script locally. Is it surprising it didn't work, or is there something curious going on?
[00:28] <who_> i.e, is this a bug I should try and report, or just something that would be expected this early on in the release cycle...
[00:30] <who_> Oh, and while I'm here: does anyone else get keyboard and mouse working in X when booting a graphical rootfs in qemu? I don't, and have to ssh in in order to do anything - is that also a bug?
[00:32] <ogra> who_, the karmic rootstock cant build lucid yet, it needs the patch from http://bazaar.launchpad.net/~project-rootstock-developers/project-rootstock/trunk/revision/31
[00:33] <who_> ogra: I used rootstock from trunk in LP: would that have had the patch?
[00:33] <ogra> yes, that should have it but is in active development atm, i havent tried to build anything with it under karmic
[00:33] <ogra> it works under lucid
[00:33] <who_> (i.e revision 42)
[00:35] <who_> ogra: so would my best bet be to use rootstock revision 31? Are you interested in any bug reports atm for using trunk rootstock on karmic?
[00:36] <ogra> sure, i might want to backport it, but dont expect them to be high prio atm :)
[00:36] <ogra> rev31 should definately work
[00:36] <rcn-ee> ogra, just a note rootstock is failing (revision 42 just ran) with --dist lucid  "mount: mount point /dev/pts does not exist" i'm guessing the verstaile kernel is missing CONFIG_DEVTMPFS same bug i ran into with the beagle kernel on karmic -> lucid..
[00:37] <ogra> rcn-ee, that shouldnt be an issue, its just a warning
[00:37] <ogra> there is a patch already in the code to use the versatile kernel from the archive under lucid, sadly the kernel package needs fixing first (doesnt boot at all)
[00:37] <rcn-ee> i was thinking that too, since it worked a week ago, not sure why rootstock is dying shortly after...
[00:38] <ogra> well, i'm currently actively developing features in trunk :)
[00:38] <ogra> might be that they introduce new bugs
[00:38] <who_> ogra: and about using qemu with X: that's a problem I have with all my rootfs', (ones that work on real hardware...)
[00:38] <rcn-ee> i saw those, everything looked safe...
[00:39] <ogra> well, the code surely needs cleanup, i'm currently caring more for shrinking my TODO than having it perfect ... i'll do a deep code review sometime next week
[00:40] <ogra> btw i plan to add a plugin system that will spit out compete SD card images so you can just use "--board beagle" and will have something that can be dd'ed and booted right away
[00:41] <ogra> will indeed need people to submit plugins for their HW
[00:42] <rcn-ee> sounds like a plan, i uploaded the logs here  http://rcn-ee.homeip.net:81/dl/rootstock/  ...  What prompted it, my alpha-2 lucid image got corrupted on rcn-ee.net.... So, I'm going to cheat and dist upgrade karmic and upload that.. ;)
[00:42] <who_> ogra: that sounds sweet. I will try and do one for IGEPv2
[00:42] <ogra> who_, sorry, i dont use qemu with any framebuffer so i cant tell much about that, i guess using an initramfs would help though, suspecting the input drivers you need are modules
[00:43] <who_> ogra: ok, that's a good starting point for me to get googling on :) - I'm a little new to this level of things. Thanks
[00:43]  * ogra commits todays tasksel tool for the rootstock GUI 
[00:44] <rcn-ee> that would be cool..  main thing the beagle's need, is the /etc/e2fsck.conf tweak.. (no real time clock battery) well until util-linux considers that not an error..
[00:44] <who_> final question before I go to bed: Does anyone else find they have a curious bug where, after some unspecified period of time, certain commands stop executing? It's happened to me with a rootfs on SD and one over nfs.
[00:45] <who_> After some time (different amounts each time) things like ifconfig, sudo, synaptic stop executing, but things like dmesg, top, xterm, still start fine
[00:45] <ogra> rcn-ee, i convinced the maintainer to look into it, we finally found an x86 box it occured on, that convinced him ;)
[00:45] <ogra> so it might be fixed
[00:46] <ogra> s/be/become/
[00:46] <who_> the system is essentially useless though. If I am connected to a serial terminal I see messages about things being idle 120 seconds...
[00:46] <rcn-ee> cool the musb port just passed my stress test..., cwillu_at_work, give http://rcn-ee.homeip.net:81/dl/linux-image-2.6.32.7-x7.1_1.0cross_armel.deb a try... (load the beagle at 100% and transfer many gigs..)  make sure "dmesg | grep fifo" returns 5...
[00:47] <rcn-ee> sweet, thanks for that ogra.. i have a couple atmel boards at work that need the same tweak for debian.. ;)
[00:49] <ogra> who_, i'D file a bug and attach dmesg etc to it, but note that with karmic only armv6 chips are supported, with lucid we even switched to v7 and thumb2
[00:51] <who_> ogra: I'll get a dmesg log onto launchpad. This is an OMAP3, so shouldn't be troubled by the change to v7, as I understand it.. right?
[00:51] <ogra> right
[00:52] <rcn-ee> who_, are you still on the 2.6.28 kernel with your IGEPv2?
[00:53] <who_> rcn-ee: yea, but I built their latest kernel tonight. Will try it out on the board when I get in tomorrow :)
[00:53]  * ogra needs to go now
[00:54] <who_> Thanks for the help, ogra :)
[00:54] <rcn-ee> who_, if you boot lucid, make sure you enable CONFIG_ARM_ERRATA_430973
[00:54] <who_> rcn-ee: thanks. there's no way I'd have got that on my own :)
[00:55] <rcn-ee> who_, neither me... spent about 2 weeks with dave martin debuggin that one...
[00:55] <who_> rcn-ee: is there any ubuntu-on-igep information around other than what's on the igep wiki?
[00:56] <rcn-ee> well you can follow my beagleboard wiki on elinux... but the kernel is still external.. i don't have that board, but it should be pretty easy to integrate into the kernel builds i already do...
[00:57] <who_> rcn-ee: the thing that struck me just now when I looked at the BeagleBoardUbuntu page was that there seems to be a better system for getting SGX video acceleration working on Ubuntu...
[00:57] <rcn-ee> also you need CONFIG_DEVTMPFS, for lucid  ( i couldn't get the beagle to mount with out it..) however it didn't get added to mainline till 2.6.32...
[00:57] <who_> rcn-ee: again. thanks :)
[00:57] <ogra> it should mount thought
[00:57] <ogra> just spill an error in initramfs
[00:58] <ogra> there are several safety nets in initramfs's init to make sure it still mounts
[00:58] <rcn-ee> I'll re-test it, but it errored but never recovered...  we still don't use an initramfs on the beagle..
[00:59] <who_> and there's no initramfs for IGEPv2 either...
[00:59] <ogra> you should start to ;)
[00:59] <rcn-ee> i know.. ;)  on my list too...
[00:59] <ogra> its just an update-initramfs away :)
[00:59] <ogra> (and a mkimage indeed :) )
[00:59] <ogra> anyway, really off now
[00:59] <who_> bye
[01:00] <rcn-ee> now that we've transitioned to u-boot.scr scripts it's easy to tweak too...
[01:04] <who_> rcn-ee: can you tell me a tiny bit about the 'build_sgx_module.sh' script that you've got
[01:04] <rcn-ee> sure i can, what question do you have..
[01:04] <who_> (I'm looking at http://elinux.org/BeagleBoardUbuntu)
[01:04] <rcn-ee> 2.6-stable.. branch i'm hoping..
[01:05] <who_> rcn-ee: how does it differ from what I'd get if I followed the 'standard' instructions on the TI grpahics SDK?
[01:06] <rcn-ee> who_, it's very similar now (specially with the current revision) but it isn't tied to a specific TI kernel.. which in the past has been a big problem..
[01:07] <who_> rcn-ee: the reason for my questions is that I'd like to be able to have video acceleration on the IGEPv2 with Ubuntu. All of the docs from ISEE (the board manufacture) are about using it on their poky system with their kernel
[01:08] <rcn-ee> who_, very similar, i actually used Angstrom's (poky is based off) instructions to originally write the script...
[01:08] <who_> rcn-ee: okay, I'll take a look at it when I'm not about to go to bed and see if I can make enough sense of it to use it for my IGEP :)
[01:10] <who_> rcn-ee: could you just explain this sentence a bit: "Use the "build_sgx_module.sh" script in 2.6-stable, module source is now in the *.bin " - does that mean "TI now provide the module source in their .bin file so we can build the modules with any kernel we like"?
[01:11] <rcn-ee> Yeah, with the latest version TI moved the 'external' gpl modules into their SDK.. (they didn't take bug reports since it was external)  so now you need the SDK to build the kernel modules, before i actually build them on my chroots at the same time as the *.deb files...
[01:12] <rcn-ee> it's kinda clugy for ubuntu/debian but users now have to build the kernel modules on their own...  (too many pages of license stuff and not enough time for me..)
[01:12] <rcn-ee> but as long as you have the correct things enabled, you can build it on any 'dss2' enabled kernel...
[01:17] <who_> rcn-ee: okay I think I understand. unless I'm using the exact kernel that ISEE used, I'm not likely to have much luck using the modules (binary) they are shipping, right? (they provide omaplfb.ko and pvrsrvkm.ko)
[01:18] <rcn-ee> who_, that is correct...  and those two modules are pretty easy to generate once you have the sdk anyways...  just use the script as reference, and you'll get it...
[01:18] <who_> but if I am using their kernel (and there aren;t many reasons I can see right now not too..) I should be able to skip the module compilation step and jump to http://elinux.org/BeagleBoardUbuntu#Startup_Script and follow from there?
[01:19] <rcn-ee> yeap, you can just use theirs...
[01:19] <rcn-ee> any chance did they have a version on them?
[01:19] <who_> rcn-ee: any reason not to use 2.6.28-10?
[01:20] <rcn-ee> musb bugs... on the beagle.. ;)  i think you guys have a good working ehci port correct?
[01:20] <who_> rcn-ee: they specify that they're for use with 2.6.28-10 which is what they see as the kernal they are supporting
[01:20] <who_> rcn-ee: yea, the usb is stable for us...
[01:20] <rcn-ee> they had weird version numbers like : 1.3.13.1607
[01:21] <who_> rcn-ee: what did?
[01:21] <rcn-ee> the kernel modules...
[01:22] <who_> rcn-ee: oh, okay. I don't know. they ship them in a folder called kernel-modules-sgx530_3.00.00.09-r0_igep0020b - but that would appear to be of no use ;)
[01:23] <rcn-ee> okay 3.00.00.09 (1.3.13.1607 was for that) is safe for those directions on elinux... the much older 3.00.00.06 needed other tweaks..
[01:24] <who_> rcn-ee: thanks again. will these modules do anything to accelerate video playback, or do I need to go to the dsp framework for that?
[01:25] <rcn-ee> who_, by the way, since your using that one.. use this older revision, it gives you a bigger picture of what i did before i wrapped it all up in the script... http://elinux.org/index.php?title=BeagleBoardUbuntu&oldid=16127
[01:25] <rcn-ee> who_, nope... just '3D'  i've been chewing on the dspbridge, and gst-dsp but haven't got the two to work together yet...
[01:27] <rcn-ee> i sneak the /usr/bin /usr/lib files into hte modules package when you use the script to make it very easy for users to install...
[01:28] <who_> sweet. that old revision is brilliant. thanks. As for DSP bridge, the IGEP wiki _looks_ to haveit documented well here http://wiki.myigep.com/trac/wiki/HowToSetupUseIGEPDSPFramework . I haven't tried it though - I need to start with the basics :P
[01:29] <who_> rcn-ee: I have to go to bed now, which is a shame because I'm learning a lot!
[01:29] <rcn-ee> there's always the next day too.. just keep messing around with it...
[01:29] <who_> rcn-ee: thanks for the help... I'm sure I'll be back at some later date to ask some more things :)
[01:30] <who_> rcn-ee: yea, I need to get on top of my toolchain so I can iterate things fast :) It's been a frustrating week with 1 dead PSU and the _weird_ bug I described above where the system just starts hanging. Hopefully next week will be full of productive joy :)
[01:31] <rcn-ee> it pays to have lots of extra hardware.. ;)
[01:31] <who_> rcn-ee: indeed! anyway, thanks very much for the help.
[01:32] <rcn-ee> your welcome, later..
[06:09] <Differentkindof> Super near stupid question
[06:10] <Differentkindof> If a program is coded in c c++ and tcl and I'm running ubuntu arm and I know it has make is there anything super special (barring lib dependencies) to make a program build properly or am I good with the typical make commands to install on arm hardware
[13:54] <suihkulokki> what happened to the ubuntu android runtime project?
[13:56] <lool> The direction/research was abandonned
[14:35] <suihkulokki> thats sad, being able to run android apps on generic linuxes would be highly useful
[16:19] <alow> Wondering if someone can point me at a .deb for gdb?  There has to be one out there.
[17:06] <cooloney> 4
[17:06] <gregoiregentil> On beagleboard, I have amixer, alsamixer, aplay, arecord working but gnome-volume-control reports the "connection failed, reconnecting". Is it a problem with pulse?
[17:07] <gregoiregentil> also, launching pulseaudio --start reports an error "Daemon startup failed". Has anyone experienced that?
[17:39] <persia> gregoiregentil: Please file a bug about that: it should just work.
[17:39] <persia> You might try parec and pacat to see if those help.
[17:40] <gregoiregentil> but is it working for anybody? Note that I have a special 2.6.29 kernel and I'm wondering if that may be the problem
[17:41] <persia> Aha.  We'll need someone with a non-special kernel to test :)
[17:42] <GrueMaster> gregoiregentil: which distro are you running?
[17:42] <gregoiregentil> Always Innovating Ubuntu: http://www.alwaysinnovating.com/wiki/index.php/Ubuntu
[17:42] <GrueMaster> which release?
[17:43] <GrueMaster> oh, nevermind.
[17:43] <GrueMaster> Have you tried Lucid?
[17:44] <gregoiregentil> No
[17:45] <ogra> so its karmic ?
[17:45] <gregoiregentil> correct
[17:46] <gregoiregentil> let me reformulate my question: has anyone make work gnome-volume-control on ARM Karmic?
[17:46] <GrueMaster> I'm running karmic at this moment on a dev board, and volume control works here.
[17:46] <ogra> it would be nice if you submitted something like your changes as patches :) i'd have happily accepted your postprocess thingie (we now have a --script option that does the same in the latest upstream branch though)
[17:47] <ogra> gnome-volume-control works fine for me on a babbage board under karmic
[17:47] <ogra> i suspect your kernel might miss an option for something pulse tries to attach to
[17:47] <gregoiregentil> ogra: OK interesting. Which kernel version is it?
[17:47] <gregoiregentil> ogra: http://git.alwaysinnovating.com/cgit.cgi/ai.ubuntu/tree/
[17:48] <ogra> the ubuntu archive kernel, 2.6.31
[17:48] <gregoiregentil> OK. Yes, I should try to upgrade my kernel
[17:48] <gregoiregentil> but I have so many patches...
[17:48]  * ogra knows that feeling
[17:52] <ogra> gregoiregentil, http://ports.ubuntu.com/pool/main/l/linux-fsl-imx51/ has the kerenl we use on the babbage (the -108 one is karmic), the config is shipped in the deb in /boot, probably you find something by comparing the alsa related configs
[18:20] <lool> gregoiregentil: From the symptoms, it's very likely a missing config option in your kernel, not necessarily that it's too old
[18:21] <lool> gregoiregentil: You could strace it to see what is actually failing
[18:21] <ogra> lool, thanks for researching the versatile issue
[18:21]  * ogra hugs lool 
[18:21] <lool> That took me the whole day unfortunately   :-(
[18:22] <ogra> andy said he'll upload before end of the sprint
[18:22] <lool> Building kernels and tracking down config changes is really time consuming
[18:22] <ogra> yeah
[18:22] <lool> But the result should be a much more useful kernel   \o/
[18:22] <ogra> yeah \o/
[18:22] <ogra> rootstock already has the code to use it by default
[18:23] <lool> It's still missing some stuff; notably the storage drivers are still modules
[18:23] <lool> We should have SCSI + SD and some FSes in the kernel
[18:23] <ogra> i'm pondering to drop all the other kernel specialities in rootstock and unify on the archive one
[18:23] <lool> A nice bonus of the config fixes is that the fonts suck less too
[18:23] <lool> ogra: I didn't understand why you have two kernels in there
[18:24] <lool> Why don't you use the cortex-a8 one for all dists?
[18:24] <ogra> i will
[18:24] <ogra> as soon as i use the archive kernel i'll drop the others
[18:24] <lool> I mean you can drop one of them right now already
[18:25]  * lool &
[18:25] <ogra> well, it works as is ... i will make the change if i have the archive kernel when i have to touch that code anyway
[18:51] <cooloney> lool: thanks a lot for versatile things, i am also going to use it for some development
[18:51] <cooloney> lool: if you need some help for versatile, just ping me
[18:53] <lool> cooloney: Thanks
[19:02] <tahsin> hello
[19:02] <ogra> hey
[19:02] <tahsin> so i recenly recompiled my image by root stock now  in the gui log in screen it wont show my user name
[19:03] <tahsin> so i cant go anywhere after that
[19:03] <tahsin> but console and everything works
[19:03] <tahsin> and everything is uptodate since yesterday
[19:03] <ogra> in console you can use the username ?
[19:03] <tahsin> yes
[19:03] <ogra> which version of the script did you use ?
[19:04] <tahsin> the one from karmic repo and also from launchpad test2
[19:04] <ogra> test2 ?
[19:04] <tahsin> it is one of the lists there
[19:05] <ogra> the karmic version should work properly (but does not support building lucid if you tried that)
[19:05] <tahsin> well i actually tried every rootstock available from launchpad
[19:05] <tahsin> i am  only building karmic
[19:06] <tahsin> it only few days ago when updating kernel it started happening
[19:06] <ogra> hmm that should work properly with the packaged version
[19:06] <tahsin> i find it strange because i created a lot of images with  same version and never had a problem
[19:07] <ogra> well, we dont have any beagleboard kernel in ubuntu, if thats kernel related you should talk to the maintainer of eh beagle kernel package
[19:07] <tahsin> so it could be a kernel issue?
[19:07] <ogra> he comes by here from time to time: rcn-ee
[19:07] <ogra> well, if you say it worked until you had a kernel upgrade
[19:07] <tahsin> ok
[19:09] <tahsin> well this is complete new install, i do have a older install but i am afraid to break that
[19:13] <tahsin> so do you anyway to refresh the gdm?
[19:13] <tahsin> like see where the list is saved?
[19:16] <ogra> it should just look it up from /etc/passwd
[19:17] <tahsin> ok
[19:22]  * persia runs into the dreaded "sudo: must be setuid root" issue
[19:58] <ogra_> lool, bah, you broke qemu-arm-static
[19:59] <ogra_> lool, you register the new qemu-arm handler but dont unregister the old arm handler
[19:59] <persia> please fix :)
[20:01] <ogra_> oh, it think its just a missing conflicts/replaces
[20:01] <armin76> quick
[20:02] <ogra_> hrm
[20:07] <persia> ogra: Right now, ubuntu-dev-tools is recommending the transitional package (my mistake).  If you need to conflict, please also adjust this.
[20:07] <lool> ogra: I do
[20:07] <lool> ogra: Did you read my email about the bug I filed?
[20:07] <ogra> i didnt know it makes it completely non-functional
[20:08] <lool> Does it?
[20:09] <ogra> ogra@osiris:/var/build$ sudo chroot lucid-test/
[20:09] <ogra> chroot: cannot run command `/bin/bash': No such file or directory
[20:09] <ogra> it doesnt exec at all anymore
[20:10] <persia> Worked great for me, until my latest dist-upgrade.
[20:10] <ogra> same here
[20:15] <lool> Does it work after a reboot?
[20:17] <lool> I know it's not unregistered properly, but the documentation says it should so I just filed #516274; I was counting on the fact that both entries point to the same binary interpreter
[20:18] <ogra> no, doesnt work after reboot either
[20:20] <ogra> ogra@osiris:/var/build$ ls /proc/sys/fs/binfmt_misc
[20:20] <ogra> arm  cli  jar  python2.5  python2.6  python3.0  qemu-arm  register  status
[20:20] <ogra> hrm
[20:20] <ogra> i have uninstalled the qemu-arm-static package manually and rebooted, why is the arm handler still there
[20:21] <ogra> ogra@osiris:/var/build$ ls /usr/share/binfmts
[20:21] <ogra> cli  jar  python2.5  python2.6  python3.0  qemu-arm
[20:21] <lool> Check in /var/lib/binfmt*
[20:21] <ogra> why do i have it in /proc
[20:22] <ogra> oh, there it is
[20:23] <ogra> ogra@osiris:/var/build$ ls /proc/sys/fs/binfmt_misc/
[20:23] <ogra> cli  jar  python2.5  python2.6  python3.0  qemu-arm  register  status
[20:23] <ogra> ogra@osiris:/var/build$ sudo chroot lucid-test
[20:23] <ogra> chroot: cannot run command `/bin/bash': No such file or directory
[20:23] <ogra> hmm, still
[20:24] <ogra> lool, does it work for you ?
[20:24] <ogra> erm
[20:24] <ogra> ogra@osiris:/var/build$ cat /proc/sys/fs/binfmt_misc/qemu-arm
[20:24] <ogra> enabled
[20:24] <ogra> interpreter /usr/share/binfmt-support/run-detectors
[20:25] <ogra> whats that ?
[20:30] <lool> it works after I rerun the postrm and the postinst
[20:31] <lool> ie sudo update-binfmts --package qemu-arm-static --remove arm /usr/bin/qemu-arm-static
[20:31] <lool> and sudo update-binfmts --import qemu-arm
[20:32] <ogra> weird
[20:32] <ogra> here too
[20:33] <lool> I wonder whether it's because it's in the prerm
[20:33] <ogra> did you add that ? i dont think it had a prerm before
[20:33] <ogra> hmm, it did
[20:34] <lool> I don't get why it didn't work from the maintainer script; I'm pretty sure it's the same bug than the one I filed, but I don't understand the issue
[20:34]  * ogra neither
[20:36]  * ogra reboots again to make sure it persists
[21:07]  * cwillu_at_work starts playing with rcn's musb patched kernel
[21:54] <kblin> cwillu_at_work: which one would that be? :)
[21:55] <cwillu_at_work> kblin, the first one he linked me: http://rcn-ee.homeip.net:81/dl/linux-image-2.6.32.7-x7.1_1.0cross_armel.deb
[21:55] <cwillu_at_work> kblin, I noticed there was also a 7.2 and 7.3
[21:56] <cwillu_at_work> doesn't look like http://rcn-ee.net/deb/kernel/beagle/ has any with that patch yet
[21:56] <cwillu_at_work> I usually build my own kernels from his git, and I haven't checked if they're there yet either
[21:56] <kblin> cwillu_at_work: what problems are you seeing?
[21:56] <cwillu_at_work> kblin, right now, doesn't look like any problems :)
[21:57] <cwillu_at_work> kblin, but historically I have all sorts of fun with mixing 2.0 + 1.1 usb devices on the same hub, as well as general issues with the ehci port on omap3 boards (beagle or overo)
[21:58] <cwillu_at_work> so at this point, I'm testing the general instability of the ehci port as well as the usb mixing
[21:58] <cwillu_at_work> the concrete issue I had was some trouble at an installation last month, where their keyboard would lock up after 8 hours or so
[21:59] <kblin> cwillu_at_work: for my B6, 2.6.31.5-x5.3 resolved my musb issues. for my C2, I still do get the occasional timeout from the network card over musb
[21:59] <cwillu_at_work> no network access to the device, and only a limited amount of time I could stay on site on any given day
[21:59] <cwillu_at_work> kblin, running c3 and c4
[22:00] <kblin> and you still have stability issues with ehci? geez...
[22:00] <cwillu_at_work> well, there's musb patches floating around that I didn't have; pointed them out to rcn and they seem to be helping
[22:01] <cwillu_at_work> really, I do everything in my power to make stuff as unreliable as possible :p
[22:01] <kblin> cwillu_at_work: I guess I'll have to try that new kernel for my c2, thanks for the heads up :)
[22:01] <persia> lool: Still up?  Do you need a hand chasing the binfmt-misc stuff?
[22:02] <cwillu_at_work> kblin, I believe http://rcn-ee.net/deb/kernel/beagle/  is preferable, at least once rcn has verified that the patches are in those kernels
[22:03] <kblin> yeah, I'm not going to touch that stuff tonight, I'll wait until the kernels hit rcn-ee.net
[22:04] <cwillu_at_work> might not be till monday :p
[22:04] <cwillu_at_work> I sent him an email, if he respond then there's hope :p
[22:04] <kblin> :)
[22:05] <kblin> I'm in no hurry. I just need the c2 board stable enough so I can demo it on a conference in may :)
[22:06] <persia> Should be no issue with that sort of latency :)
[22:06] <kblin> persia: dunno, took about a year to get my b6 working
[22:07] <kblin> with usb ethernet _and_ usb hdd, that is
[22:07] <persia> Somehow I think that there's enough boards out there that kernels oughtn't take that long, and userspace is getting easier every day.
[22:07] <cwillu_at_work> kblin, add a laser printer, and you'll have my test case :)
[22:08] <cwillu_at_work> persia, i.e., I'm already running the kernel in question? :p
[22:08]  * persia thought that was the case :)
[22:08] <kblin> cwillu_at_work: nah, I'm going to demo a samba 4 AD DC, that doesn't do printing so far :)
[22:08] <cwillu_at_work> kblin, you don't share printers on your networks? :p
[22:10] <kblin> cwillu_at_work: I do with samba 3
[22:10] <kblin> or rather lpd, no samba involved :)
[22:10] <ogra> persia, http://rcn-ee.homeip.net:81/dl/rootstock/rootstock-201002041826.log ... so rcn was hit by the qemu issue yesterday already it seems
[22:10] <ogra> "chroot: cannot run command `debootstrap/debootstrap': No such file or directory"
[22:20] <persia> Right.