[06:36] <armin76> uh, emerge is not horrendous
[06:36] <armin76> its better than apt :)
[06:37] <Martyn> Ugh
[06:37] <Martyn> Lets not get into the whole package management religious war again
[06:37] <Martyn> that -practically- counts as a troll.  grin
[06:38] <Martyn> Oh, and I got some of the installer scripts to work finally
[06:38] <Martyn> so I've got the beginnings of an actual Karmic installer that doesn't involve a buildroot
[06:44] <kblin> you mean other than rootstock?
[06:51] <Martyn> yep
[06:51] <Martyn> Getting there slowly.  It's not the actual server installer yet, but I'm grinding away at the problem
[06:52] <Martyn> my eventual goal is to get an ARM server build that net installs successfully on a couple platforms
[06:52] <Martyn> PBX-A9, FastModels RealView EB, and the tech my company is working on (Smooth-Stone)
[06:53] <kblin> none of them ring a bell for me.. anything with a couple of ethernet ports on them? :)
[06:58] <Martyn> All of them
[06:59] <Martyn> Well, the RealView EB is not a physical machine .. it runs as a fastmodel software simulation of the entire A9 Core (quad core) at ~150Mhz
[06:59] <kblin> I'm definetely playing with the wrong hadware right now :)
[06:59] <Martyn> The PBX-A9 is the Cortex A9 version of ARM's hady PBX platform .. they pretty much recycled it
[07:00] <Martyn> although the new A9 version has a neat implementation of a dual core Cortex A9 running also at about 150Mhz.   Pretty impressive, considering they basically dropped the soft core onto an ASIC
[07:00] <kblin> if you say so...
[07:00] <Martyn> (rather than test silicon)
[07:00] <Martyn> the tech my company is working on is, of course, a real Cortex A9 ... but I can't really share that much of what we're up to.
[07:00] <Martyn> But I can't wait to play with the real chips :)
[07:01] <Martyn> kblin : For a couple of ethernet ports, you're probably going to have to wait until TI starts producing non-sample quantities of the OMAP4
[07:02] <Martyn> and even then, it's pretty dependent on someone -else- (beagle?) interfacing a chip that doesn't use PCI  (like the SMSC 9118)
[07:02] <Martyn> Since that can be mapped directly onto SRAM
[07:02] <kblin> so what I presented on the storage developer's conference yesterday was a Samba4 Active Directory domain controller running on a beagle, as that's the hardware I got
[07:02] <Martyn> Urk
[07:02] <Martyn> Cortex A8 though, so at least it has some optimizations
[07:02] <kblin> and as a proof of concept, it's been pretty impressive
[07:02] <Martyn> What did you use for an ethernet adapter?   Phoenix chip off the USB port?
[07:03] <kblin> moschip, but yeah
[07:03] <Martyn> I did something similar with a shivaplug
[07:03] <kblin> yeah, I got one of those yesterday
[07:03] <kblin> not in time for my presentation, though
[07:03] <Martyn> multicore is win when doing asynchronous IO
[07:04] <Martyn> but the arm v5 instruction set (since it does v5 multicore) is limiting
[07:04] <Martyn> kblin : You'll be impressed with the performance that little thing can pump, when it comes to IO
[07:04] <kblin> what's killing the beagle is the crappy USB
[07:04] <Martyn> kblin : The Kirkwood core is interesting, if a bit "yesterday"
[07:04] <Martyn> yep.
[07:04] <Martyn> you're going to get equally crappy performance out of the shivaplug, I'm afraid
[07:04] <kblin> it's going to be more yesterday when ubuntu rops v5 support
[07:05] <Martyn> I ran a Samba 3 PDC on one, and it worked .. but it wasn't anything stunning
[07:05] <Martyn> what's REALLY going to kill you is the lack of RAM
[07:05] <Martyn> no danger of dropping arm v5 for a while.
[07:05] <kblin> it seems to be a bit faster for AD stuff
[07:05] <Martyn> Hell, the whole build system is geared to MAKING v5 eabi binaries at the moment, built on QEMU of all things
[07:06] <kblin> I didn't benchmark file server performance
[07:06] <Martyn> I'm starting to figure out how to configure launchpad to perform v7 builds now
[07:06] <Martyn> since that's the key to getting some application performance on the new systems, and I really need to start focusing on that
[07:06] <Martyn> It's slow going
[07:07] <kblin> however, Samba4 is just starting to support AD replication, so setting up a small embedded box in a branch office that replicates the main office's AD setup seems like a nice product
[07:07] <kblin> so fileserver performance isn't too critical for that kind of setup
[07:09] <Martyn> true
[08:18] <lool> Missed Martyn
[08:18] <lool> Would have liked to know if it's a d-i bsaed installer
[10:21] <ogra> lool, wrt usplash, i know that we need USPLASH=y in initramfs.conf (or the .d dir) but i still see no sane way to put it there apart from hacking up the installer and casper probably
[10:23] <ogra> or use an expensive function that does an arch check in initramfs
[10:28] <lool> ogra: Just add a file in usplash on build
[10:28] <ogra> hmm
[12:18] <siji> hey
[12:19] <siji> anybody can help me to compile clutter with openGL support
[12:20] <siji> still am with the same error
[12:20] <siji> checking EGL/egl.h usability... no
[12:20] <siji> checking EGL/egl.h presence... no
[12:20] <siji> checking for EGL/egl.h... no
[12:20] <siji> configure: error: Unable to locate required GLES headers
[12:34] <siji> ogra, i got the tutorial abt this for angstrom OS
[12:35] <siji> anyway to make it for ubuntu
[12:35] <siji> ?
[12:35] <ogra> no idea
[12:36] <siji> ogra,ok
[12:36] <ogra> did you ask in #beagle (or if there is an angstrom channel, did you ask there)
[12:40] <siji> ok
[12:46] <siji> ogra,those header files are in Omap SDK
[12:46] <siji> and i copied it to unbuntu rootfs
[12:46] <siji> but no hope
[12:47] <siji> mike^,u there
[12:47] <siji> ?
[12:54] <mike^> yes
[12:54] <mike^> mostly
[12:57] <siji> mike^, any idea ?
[13:02] <mike^> siji, not really, what I did was 'cp -r /path/to/SDK/OGLES/SDKPackage/Builds/OGLES/Include/GLES /path/to/ubuntu/root/usr/include'
[13:02] <mike^> 'cp -r /path/to/SDK/OGLES/SDKPackage/Builds/OGLES2/Include/EGL /path/to/ubuntu/root/usr/include'
[13:02] <mike^> and than on omap machine: apt-get -s build-dep clutter
[13:03] <siji> mike^, i tried
[13:03] <mike^> apt-get -b source clutter
[13:03] <siji> mike^ actually i compiled clutter frm Source
[13:03] <siji> ./configure --with-flavour=eglnative --with-gles=2.0 --with-imagebackend=gdk-pixbuf --with-x=no    --with this prefix
[13:05] <mike^> siji, I've used the configure options from the .deb itself, I've only changed the --with-flavour to 'eglx'
[13:07] <siji> mike^, like " apt-get  -s build-dep  clutter eglx "
[13:07] <siji> ?
[13:10] <mike^> siji, just "apt-get  -s build-dep  clutter"
[13:10] <siji> ok
[13:10] <siji> let me try again
[13:10] <mike^> siji, and during the 'apt-get -b clutter' I've interrupted it, and changed debian/rules to use eglx
[13:11] <siji> ok
[15:07] <lool> rabeeh: http://cdimage.ubuntu.com/ports/daily-live/current/
[15:08] <lool> rabeeh: note that it's not always there (might fail to build)
[15:08] <lool> I didnt test this image either so it might not even boot
[15:08] <ogra> the imx51 one boots fine
[15:08] <lool> odd my rsync just failed with rsync: link_stat "/ports/daily-live/current/karmic-desktop-armel+dove.img" (in cdimage) failed: No such file or directory (2)
[15:08] <ogra> so i'd expect the dove one to do that too
[15:09] <ogra> the link was just moved :)
[15:09] <lool> ogra: You kicked a build?
[15:09]  * ogra knows that prob and stopped using current/ long ago
[15:09] <ogra> no
[15:09] <ogra> i'm still installing
[15:09] <lool> I never had an issue with that
[15:09] <lool> and the web index has /current working fine
[15:10] <ogra> well, i know it breaks if the link moves while you are actually in the sync process
[15:10] <lool> I just started my rsync
[15:10] <rabeeh> which u-boot configuration are you using?
[15:11] <rabeeh> (bootcmd etc...)
[15:11] <lool> rabeeh: That's the good question to ask
[15:11] <lool> the image is meant to be started with the new bootcmd discussed in $bug
[15:11] <ogra> there should be a wikipage
[15:11] <lool> yeah
[15:11] <lool> https://wiki.ubuntu.com/ARM/MarvellDoveKarmicInstall
[15:12] <lool> rabeeh: ^ that's semi current
[15:12] <lool> rabeeh: Ideally you'd just the loop and it would autostart the USB key install
[15:12] <ogra> https://wiki.ubuntu.com/ARM/MarvellDoveKarmicInstall
[15:12] <ogra> bah
[15:12] <ogra> lool beats me
[15:12] <lool> ogra: Young padawan
[15:12]  * ogra buys http://www.frankelcostume.com/Beard-18-Grey-Oldtimer-P16867C93.aspx :P 
[15:14] <lool> rabeeh: I pushed support for dove-z0 netboot images if anybody cares; will be published with next debian-installer upload; untested though
[15:14] <lool> The dove netboots were incomplete (were relying on uimage kernels which we dont have anymore) so these will be fixed at this time as well
[15:15] <lool> rabeeh: http://ports.ubuntu.com/ubuntu-ports/dists/karmic/main/installer-armel/current/images/ is the base dir for the netboot images
[15:15] <rabeeh> which one will have UNR?
[15:16] <lool> ogra: Oh you were the male model below the beard?
[15:16] <lool> rabeeh: We might add it if we get 3d working
[15:16] <lool> I mean opengl
[15:16] <lool> rabeeh: But for now we cancelled that support in karmic
[15:17] <lool> rabeeh: it's not very hard to add, perhaps some hours + testing but we need a way to test first
[15:17] <rabeeh> right
[15:17] <rabeeh> what's the best way to do it -
[15:17] <rabeeh> 1. clutter + opengl-es
[15:18] <rabeeh> 2. clutter + opengl + translation to opengl-es + opengl-es
[15:18] <rabeeh> ?
[15:18] <rabeeh> lool: translation library like the one you previously mentioned to me?
[15:24] <ogra> lool, heh, we still have usplash on shutdown on the live image :)
[15:26] <lool> rabeeh: In theory clutter can work on either IIRC
[15:26] <lool> rabeeh: But there might be some issues with clutter 1.0
[15:26] <lool> rabeeh: The point of clutter is to abstract that away
[15:26] <ogra> sniff, no gdm for me after install :/
[15:30] <rabeeh> if the performance of 2 is similar to 1; personally i would go with 2, since any other application that uses opengl (which are the majority for netbooks) would use the hardware engine
[15:31] <ogra> hmm, it starts if i satrt dbus manually
[15:31] <ogra> sadly i forgot to start hal too :P
[15:31] <ogra> no xinput
[15:33] <lool> rabeeh: Sure that's certainly doable; the question is how much time to fix clutter versus how much time to get that bridge working
[15:33] <lool> I didnt look into the latter
[15:33] <ogra> sigh, so on second boot dbus comes up fine
[15:33]  * ogra hates race conditions
[15:33] <ogra> but but
[15:33] <ogra> but
[15:33] <ogra> wow, the babbage boots *faaaaast* !
[15:34] <lool> ogra: with the new stuff?
[15:34] <ogra> yeah
[15:34] <lool> That's really good news
[15:34] <ogra> incredible
[15:34] <lool> That was the biggest issue
[15:34] <ogra> but see above
[15:34] <lool> Yeah
[15:34] <ogra> dbus crached on first boot after install
[15:34] <ogra> *crashed
[15:35] <ogra> second one is really quick and everything is up
[15:35]  * ogra digs for his stopwatch
[15:37] <lool> ogra: is this from SD?
[15:37] <ogra> 15sec from first screen output to X, pls ten more to see the panels
[15:37] <lool> or after install?
[15:37] <ogra> nope, USB key
[15:37] <lool> wow
[15:37] <ogra> after install
[15:38] <ogra> adding the applets takes a bit
[15:38] <lool> it's comparable to my x301 with jaunty
[15:38] <ogra> but its a massively different experience
[15:38] <lool> I think I'll like the boot stuff when it lands
[15:38] <ogra> i do already !
[15:39] <lool> I'd love to try that on dove
[15:39] <ogra> spinning disks are said to be much slower
[15:39] <lool> too bad we have no live image for z0
[15:40]  * ogra installs bootchart on the babbage
[15:41] <ogra> bah, wrong keymap
[16:30] <rabeeh> lool: i'm trying to use your netboot initrd
[16:30] <rabeeh> lool: i get the following (with my kernel) -
[16:30] <rabeeh> RAMDISK: gzip image found at block 0
[16:30] <rabeeh> RAMDISK: incomplete write (30549 != 32768)
[16:30] <rabeeh> write error
[16:30] <rabeeh> which addresses do you tftp load uImage and the initrd?
[16:34] <bjf> rabeeh, how many "users" of Y* boards exist outside of Marvell or Canonical?
[16:35] <rabeeh> bjf: i don't know; i don't have the numbers
[16:37] <bjf> rabeeh, I'm not really looking for specifics, I'm thinking about number impacted if a bad kernel went out for some reason
[16:38] <bjf> rabeeh, we are thinking about how flexible we should be in taking kernel changes
[16:39] <bjf> rabeeh, if the number of users that would be impacted is small we can be more flexible
[16:39] <rabeeh> bjf: hmmm.... i think you should be very flexible and never send a bad kernel for any reason :)
[16:39] <bjf> rabeeh, lol
[16:39] <rabeeh> bjf: seriously i really don't have the numbers; but i can say that the demand is huge.
[16:40] <rabeeh> bjf: i think it's ok for the next few weeks to have bad kernels (for some reason) until people get used to karmic images
[16:40] <rabeeh> bjf: but as i talked to saeed today; he told me that there are minor changes left for the git tree to be 100% in sync with marvell's
[16:41] <rabeeh> bjf: so the risk is really very low on having bad kernels due to dove support.
[16:41] <bjf> rabeeh, I really wouldn't expect a bad kernel to go out, however if we allow lots of changes to the karmic kernel after it has been released, then there is a greater possibility
[16:42] <bjf> rabeeh, the marvell changes are carried on a topic branch so only that would be impacted
[16:47] <lool> rabeeh: Didn't try the netboot images yet
[16:47] <lool> rabeeh: I'd use the same addresses as the boot script
[16:48] <lool> rabeeh: 0x00200000 for kernel and 0x01100000 for ramdisk
[16:48] <lool> rabeeh: note that kernel is in zimage format instead of uimage; will be fixed with next debian-installer upload
[17:14] <armin76> rabeeh: did you receive my mail?
[17:53] <ali1234> m when compiling