[00:57] <nOStahl> hi guys
[00:57] <nOStahl> hows it going
[02:29] <StevenG50> New here,  Is the Panda board the only HW platform that you can purchase to expirement with ubuntu-arm?
[02:30] <GrueMaster> No, we also support BeagleXM and Frescale Quickstart development boards.
[02:31] <GrueMaster> You can also run any other armv7 (Cortex A8/9) compatible system if you have your own kernel.
[02:31] <StevenG50> Any preferance as to which is the better board?  From a Performance, longetivity and/or ease of use point of view?
[02:33] <GrueMaster> really depends on what you want to do.  BeagleXM is great for lightweight projects (Kiosk systems, cups server, etc).  Panda is a dual processor with HD Video capabilities, Frescale has SATA for better disk I/O.
[02:33] <GrueMaster> All are fairly easy to use.
[02:35] <StevenG50> That is the best information anyone has provided me yet.  Gets me something to think about.  Thank you!  I must admit my interest is morbid curiousity.  I dont know what I want to do with it, other than just something to expirement/test with.
[02:36] <GrueMaster> Heh, I understand.  I have several of each for Ubuntu testing.
[02:49] <twb> pfft disks, just push it out to the san ;-P
[02:49] <twb> They all have gige right?
[02:50] <GrueMaster> No, 100e,
[02:50] <twb> lame
[02:52] <GrueMaster> Can't ask too much for a cell phone proc.  :P
[02:52] <twb> Oh I can ask
[02:53] <twb> OTOH why would a cellphone need SATA
[02:53] <GrueMaster> Last cycle, I had 7 panda's in a CEPH cluster.  Painful, but still cool.
[02:53] <GrueMaster> And SATA is far faster than SDHC.
[02:54] <twb> But why would a cellphone need that
[02:54] <twb> That's your argument against adding other whizzo features, right? ;-)
[02:54] <GrueMaster> using a SATA based SSD vs eMMC?  Speed.  Pure unadultrated speed.
[02:55] <twb> Pft, just load everything into ram
[02:55] <twb> You only need the SD at boot time and nobody turns their cells off
[02:55] <GrueMaster> No arm system ships with more than 1G.
[02:55] <twb> 1G should be enough to 100 users!
[02:56] <twb> grumble grumble
[02:57] <GrueMaster> SOC vendors ship to anyone that wants a proc.  It is easier to have features disabled, than non-existent.
[02:57] <twb> They should ship a disabled gige controller then :-/
[02:57] <GrueMaster> I can see the Freescale part competing with Marvell for the small NAS box market.
[02:58] <twb> A $200 NAS appliance ought to do gige
[02:58] <StevenG50> is the Freescale demo board the I.MX51?
[02:58] <GrueMaster> I think the nic is part of the USB controller.  It is on omap3/4.
[02:58] <GrueMaster> mx53.
[03:05] <StevenG50> I would imagine if you use the mx53 board the easiset thing would be to output via a serial port in ssh/telnet and skimp on the video module.
[04:22] <recur> Anyone using an MX53?
[04:22] <recur> I built the entire BSP, but I can't find the GPU driver.   Someone said it was gpu.ko  but it's not there.  Bit mystified :)
[04:52] <jvcleave> trying to figure out how to ssh into Beaglebone with it installed https://wiki.ubuntu.com/ARM/OMAP
[05:01] <recur> also hellogl_es2 starts up but the gl widget is black
[08:31] <Snark> plop
[08:33] <Snark> doko, how can I know which files are compiled in glibc? Looking at the Makefiles, I have no clue... for example in sysdeps/ieee754, there are *four* e_lgammal_r.c !
[10:01] <trelane> greetings, with regard to rootstock, it now claims to be replaced by live-build (Which seems to generate iso's).  Is there a HOWTO that I haven't found yet for using live-build to build a root tarball
[11:49] <trelane> greetings, with regard to rootstock, it now claims to be replaced by live-build (Which seems to generate iso's).  Is there a HOWTO that I haven't found yet for using live-build to build a root tarball
[11:49] <trelane> basically I just need something to copy onto an SD card
[12:06] <rbasak> overnight: 39 success, 9 failures (looks like the same debootstrap proxy/skew problem)
[12:07] <ogra_> trelane, if you just want a minimal rootfs, have a look at ubuntu-core (it is totally unconfigured though)
[12:15] <trelane> ogra_: noted.  I don't need a lot of config, though that looks like it includes some things I don't need
[12:16] <ogra_> ??
[12:16] <ogra_> it is the most minimal ubuntu you can build
[12:16] <trelane> pulse, gtk, etc
[12:17] <ogra_> by definition just enough OS to run apt
[12:17] <trelane> ok Base Core = Core
[12:17] <trelane> got it
[12:17] <ogra_> no
[12:17] <trelane> trying to figure out what Ubuntu-Core is based on the flow chart on the core website
[12:17] <ogra_> i'm talking about the ubuntu-core tarballs you can get on cdimage.ubuntu.com
[12:18] <ogra_> it contains everything debooorstrap --minbase installs plus apt and its deps
[12:18] <trelane> ok, yeah that's small
[12:18] <ogra_> has no users or rootpw configured nor does it have a network setup, hostname etc
[12:18] <ogra_> tarball is around 30M... unpacked it should be between 80 and 120M
[12:20] <trelane> ok that's no big deal at all.  I can script that and do the construction in qemu :)
[12:20] <trelane> thanks!
[12:27] <ndec> trelane: you might find that useful http://omappedia.org/wiki/OMAP_Ubuntu_Core
[12:27] <trelane> ndec: already found it on my own
[12:27] <trelane> reading it now
[12:28] <ndec> hey, google is cool ;-)
[12:28] <trelane> ndec: I'm actually an idiot, I merely have lighting fast google skills and therefore can fool most people
[12:28] <trelane> you guys might want to put a note on the rootstock page that ubuntu-core is now the preferred solution
[12:28] <ndec> i will update it soon with a section about using mainline kernel and uboot instead of the prebuilt kernel from ubuntu. but basically if you checkout any recent mainline, and build you can use that with ubuntu-core just fine.
[12:29] <ogra_> ndec, there is a typo btw
[12:30] <ndec> where?
[12:30] <ogra_>   sudo C_ALL=C chroot . /bin/bash
[12:30] <ogra_> should be LC_ALL
[12:30] <trelane> I'm usually a Funtoo (Gentoo fork) guy, and after a few hours of looking at the OE build system, how they attempted to emulate gentoo, FAILED TOTALLY, then stuck somethign vaguely debian like on top, I gave up
[12:30] <ndec> ogra_: let me check
[12:30] <trelane> I don't know how OE happened but if there wasn't enough alcohol involved to stun a team of oxen... I'd be shocked.
[12:32] <ndec> ogra_: fixed
[12:32] <ogra_> great :)
[12:32] <ndec> trelane: this is probably not the right place to talk about OE, even for bashing against OE ...
[12:33] <trelane> noted :)
[15:49] <ppisati> rbasak: did you manage to test the new kernel with the installer?
[16:53] <GrueMaster> ppisati: I just ran netinstall as part of my milestone testing.  Seems to have run just fine.  I'll check the logs for any unnoticed residue.
[16:53] <Riddell> GrueMaster: where can I find a basic intro to installing ubuntu on a pandaboard?
[16:54] <ppisati> GrueMaster: cool
[16:54] <GrueMaster> Riddell: I think there is a link off http://wiki.ubuntu.com/ARM
[16:54] <infinity> Also linked from the image download pages on cdimage.
[17:10] <ndec> ogra_: hi. on our private PPA we have a msg like that "A recent upload has resulted in 5 pending builds. " do you know what that means?
[17:10] <ogra_> nope
[17:10] <ndec> or davidm if you're around...
[17:11] <ndec> ogra_: argh, not sure if it looks good or not. who should i ask?
[17:11] <ogra_> i would assume your packages sit in the queue or some such
[17:13] <ndec> ogra_: another problem is that now that we start pushing kernel in PPA, we are reaching the size limit quickly.
[17:14] <ogra_> that shouldnt be a prob, though likely needs davids approval first
[17:14] <ogra_> you could ask in #launchpad if they can just bump the size, if they need any additional approval we can manage i guess
[17:15] <ndec> ok.
[17:15]  * ogra_ takes a look at the queue if there is anything from you in teher
[17:17] <ndec> ogra_: i asked on #launchpad too
[17:17] <ogra_> ah, k
[17:18] <ogra_> ndec, i see an alsa-utils build that has -ti in the version at https://launchpad.net/builders
[17:18] <ogra_> (the PPA builders are the bottom ones)
[17:19] <ogra_> seems the builders are busy beyond that, so it could well be that your packages are qeued
[17:20] <ogra_> ah, now it also has totem and tibtfm
[17:20] <ogra_> and uboot
[17:21] <infinity> ndec, ogra_ : buildd-manager was down, hence the queued builds going nowhere.  Got fixed just a while ago.
[17:21] <ogra_> ah, k
[17:21] <infinity> ndec: As for increasing PPA size, that doesn't need any management approval or anything, just present a case for it to launchpad folks.
[17:22] <infinity> (Though, they may require a slightly less hand-wavy case for non-Canonical PPAs demanding size bumps, I doubt yours will be an issue)
[17:22]  * ogra_ thought so ... though it wouldnt have been a prob to get such approval indeed :)
[17:35] <GrueMaster> ppisati: Did you see my earlier message?  I may have experienced an irc net-split.
[17:38] <ndec> infinity: ogra_: thx. looks like our builds are going on now.
[17:38] <ogra_> :)
[17:38] <ndec> about the size, I will request for more indeed. will ask you if i need support
[17:38] <ogra_> dont hesitate :)
[17:40] <ndec> why would i ;-)
[17:40] <ppisati> GrueMaster: nope, which one?
 ppisati: I just ran netinstall as part of my milestone testing.  Seems to have run just fine.  I'll check the logs for any unnoticed residue.
[17:41] <GrueMaster> Re:  omap kernel mac address.
[17:41] <ppisati> GrueMaster: what's that?
[17:41] <GrueMaster> ogra_: That was a lot earlier.
[17:42] <ogra_> GrueMaster, oh, then your other messages went unnoticed
[17:42] <GrueMaster> ppisati: On the omap kernel, you mentioned something about a change for the mac address? Is it just enabling the "smsc95xx.macaddr=" parameter in the module or is it getting the mac from the soc die id?
[17:42] <GrueMaster> There, reposted.
[17:42] <ppisati> GrueMaster: the second one
[17:43] <ppisati> GrueMaster: it seems i can't change the mac anymore
[17:43] <GrueMaster> Cool, thanks.  I'll double check it here and let you know how well it works.
[17:43] <ppisati> GrueMaster: sudo ifconfig eth0 hw ether 00:11:22:33:44:55
[17:44] <GrueMaster> Nah, just reboot.  If it stays the same, my dhcp server will know immediately.
[17:44] <ppisati> k
[17:45] <GrueMaster> While you're here, on omap4, is there a camera module built into the kernel now?  oem-config is trying to take a picture but there is no camera so it only has a small section of the previous screen.
[17:47] <ogra_> it shouldnt offer you to take the pic in the first place if there is no camere attached
[17:49] <rbasak> ppisati: no random panics after 48 test installs overnight. I'm using a kernel I built from the git source tree yesterday - not sure what the installer kernel is at the moment. So it's looking good.
[17:50] <GrueMaster> ogra_: Hence why I asked.  If ubiquity is detecting a camera module, it is activating that section.
[17:50] <GrueMaster> It doesn't do it on omap or mx5.
[17:52] <ogra_> i guess it looks for the actual device in /dev
[17:53] <ogra_> GrueMaster, look for /dev/videoX
[17:53] <GrueMaster> yep.  /dev/video0 exists.
[17:53] <ogra_> that might be it
[17:55] <GrueMaster> Found it in dmesg.  "Linux video capture interface: v2.00"
[17:55] <ogra_> crap ... i wonder how ubiquity should find out if there is actually a camera attached
[17:56] <ogra_>  /dev/video0 might as well come from your TV card or some such
[17:56] <ogra_> so that bug can happen on such setups too
[17:56] <GrueMaster> That might be...interesting.  Have it take a snapshot of a klingon or something.
[17:57] <ogra_> heh
[17:57] <GrueMaster> So, I should file a bug against ubiquity for this?
[17:57] <ppisati> GrueMaster: yep, there's camera support in it but it should be broken
[17:59] <ogra_> GrueMaster, yes
[17:59] <ogra_> if there isnt one already
[17:59] <GrueMaster> ok.
[17:59] <ogra_> i can easily imagine there are a lot video capture cards out there where people see it too
[17:59]  * GrueMaster notes this will be the 4th bug filed in 2 days on ubiquity/oem-config.
[18:00] <ogra_> awesome
[18:00] <ogra_> to sad we dont have an ubiquity maintainer atm
[18:00] <GrueMaster> ???
[18:00] <GrueMaster> Where's Evan or Colin?
[18:00] <ogra_> ev doesnt do it this release
[18:01] <GrueMaster> Ah.
[18:01] <ogra_> colin and stgraber step in for him though
[18:02] <GrueMaster> I was looking at that code yesterday, trying to figure out preseeding.  What a mess.
[18:03] <ogra_> it all becomes clear with enough alcohol in your blood though
[18:06]  * GrueMaster needs to make an emergency run to the liquor store.
[18:06] <GrueMaster> This camera module, how is it supposed to report no camera detected?
[18:07] <ogra_> dont forget to expense it !
[18:17] <ndec> GrueMaster: ogra_: we did get some problems with 11.10 when using a kernel with v4l2 camera driver on panda...
[18:18] <ndec> some of our panda don't have the actual camera plugged, but the kernel does not detect that... and ubiquity tries to make a picture...
[18:18] <ogra_> ndec, yes, we had issues in 12.04 too, thats why it was disabled
[18:18] <ogra_> but not completely it seems
[18:19] <ndec> on panda?
[18:19] <ogra_> yep
[18:19] <ndec> we have a horrible hack in ubiquity to bypass the camera detection... so if you come up with a proper fix this is better ;-)
[18:20] <ogra_> well, as i said above, i dont get how that works on systems with TV capture cards
[18:20] <ogra_> they surely also have /dev/video
[18:20] <ndec> yep, i am interested to understand how ubiquity understands there is a camera too... if you figure out...
[18:21] <ogra_> well, tobin will file a bug, we will see :)
[18:21] <ndec> please subscribe tiomap-dev on the bug
[18:21] <ogra_> k
[18:28] <GrueMaster> Done and done.
[18:28] <GrueMaster> Bug 924419
[18:28] <ubot2`> Launchpad bug 924419 in ubiquity "oem-config detecting camera where no camera exists" [Undecided,New] https://launchpad.net/bugs/924419
[18:30] <ogra_> thx !
[18:40] <GrueMaster> ogra_: Where are the debug symbol packages for arm?  ports or somewhere else?
[18:41] <infinity> GrueMaster: Everything's on ddebs.ubuntu.com, but (and this is a big but), not everything is represented. :(
[18:41] <infinity> GrueMaster: pitti keeps culling random old releases and non-primary arches as he runs out of space.
[18:42] <infinity> GrueMaster: Though, we seem to have armel/armhf for precise, at least.
[18:43] <GrueMaster> Ok.  ev wants me to run a backtrace on this ubiquity panel crash.
[18:44] <GrueMaster> Since I can't just file it.
[19:38] <ppisati> GrueMaster: did you reboot the beable?
[19:39] <GrueMaster> Doing so now.  Got caught up in an installer bug on omap4.
[19:41] <GrueMaster> Nope, it didn't have the same mac on reboot.
[19:41] <GrueMaster> It was supposed to get it from the die id, right?
[19:44] <ppisati> nope, you get a random one
[19:44] <ppisati> but i thought you configured it to get a fixed one
[19:45] <GrueMaster> How do I configure the system to get a fixed mac address?
[19:46] <ppisati> via /etc/network/interfaces but i can't make it work anymore, that
[19:46] <ppisati> s why i asked, because i thought you did
[19:46] <GrueMaster> There is no way to automate that, especially during a netinstall.
[19:47] <ppisati> k
[19:47] <GrueMaster> I need either a die id (like omap4) or a kernel cmdline parameter.
[19:49] <GrueMaster> Die id is preferred as then I don't need to modify the preinstalled images.