[02:21] <ncharles> anybody know the default username/password on the 11.10 omap install?
[02:22] <infinity> ncharles: There isn't one until you install it.
[02:22] <infinity> ncharles: At which point, it's the one you set up.
[02:25] <ncharles> this is with the armel minimal image
[02:25] <ncharles> I found it, it was ubuntu/temppwd
[02:25] <twb> You're probably still in the oem phase then
[02:27] <infinity> Err.
[02:27] <infinity> Or not an actual ubuntu image at all.
[02:27] <ncharles> it was the r0 image I had floating around
[02:27] <infinity> "r0"?
[02:28] <ncharles> ubuntu-11.10-r0-minimal-armel
[02:28] <infinity> Yeah, that's not an ubuntu image.
[02:28] <infinity> Not an official one.
[02:28] <infinity> As in, not built by us.
[02:29] <ncharles> oh ok, it was the one i could get the ethernet working with
[02:29]  * infinity isn't sure how much he trusts rcn-ee.net
[02:29] <infinity> But okay.
[02:31] <ncharles> what is the prefered image for a beagleboard-xm?
[02:31] <infinity> desktop or server?
[02:31] <ncharles> server
[02:32] <infinity> http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/
[02:36] <ncharles> ok well maybe I'll try that image then
[02:36] <ncharles> does that work well with the beaglebone?
[02:37] <infinity> Not sure, don't have one.
[02:37] <infinity> I haven't heard excessive complaints, though.
[02:38] <ncharles> i have one coming tomorrow so i'll have to give it a shot
=== kenws_ is now known as kenws
=== mckoan|away is now known as mckoan
[09:05] <ndec> ogra_: hi... need an advice on ubuntu/debian pkg ;-)
[09:05] <ndec> we have several flavor of our MM firmware, and I thought we should use update-alternatives to manage them all.
[09:05] <ndec> is that a good idea?
[09:05] <ndec> in the first place?
[09:06] <infinity> ndec: Oh, speaking of packaging.
[09:06] <ndec> infinity: hi!
[09:06] <infinity> ndec: You guys are really going to want to rebuild your binary drivers with our latest toolchain.
[09:06] <ndec> why that?
[09:06] <infinity> ndec: The mali folks just discovered yesterday that not rebuilding caused them pain when they tried to package.
[09:07] <ndec> i don't get it.
[09:07] <infinity> ndec: dpkg-shlibdeps can't handle binaries with the old linker path.  And, frankly, I don't care enough to mangle it, because in every non-binary-blob case, dpkg-shlibdeps (obviously) is operating on freshly-built binaries.
[09:07] <ndec> what kind of problems? you uploaded new gcc and it breaks something?
[09:07] <ndec> argh...
[09:07] <infinity> ndec: Oh, you missed the drama, I guess.
[09:08] <infinity> ndec: Linker path for armhf got bikeshedded to death, I was awake all weekend re-tooling.
[09:08] <ndec> actually, no. i enjoyed reading the emails every day ;-)
[09:08] <infinity> ndec: Your old packages still work fine.
[09:08] <infinity> ndec: But rebuilding them will break.
[09:08] <infinity> ndec: (As in, rebuilding the Debian packages will break, because of the blobs)
[09:08] <infinity> ndec: So, just a quick rebuild of the blobs with the current toolchain, and life's good.
[09:09] <ndec> when you say the old package works, did you try any application or just libs?
[09:09] <infinity> Oh, it all works.
[09:09] <infinity> All old binaries work fine.
[09:09] <ndec> ok.
[09:09] <infinity> This problem is isolated specifically to dpkg-shlibdeps, and my unwillingness to "fix" it for a use-case that I don't think matters. ;)
[09:09] <infinity> So, you've been warned.
[09:09] <ndec> is the new toolchain in the archive now?
[09:09] <infinity> If you need to rev the Debian package, you'll need to rev your binaries first, that's all.
[09:10] <infinity> ndec: Yeah, the archive is all good to go.
[09:10] <ndec> ok. thx.
[09:10] <infinity> ndec: Same for Debian, if you build for them too, I dunno.  I got Debian all fixed up yesterday/today.
[09:11] <infinity> (Though, I'm guessing you build your binaries in such a way that they'd work on both distros, but I've never taken a close look)
[09:16] <ndec> infinity: we never really tried them on debian...
[09:17] <ndec> and to be honest, we never explicitely tried to make sure they would work on debian... so if they work, it's pure coincidence...
[09:17] <infinity> Fair enough.
[09:17] <infinity> Well, if they link dynamically with glibc, they definitely won't work on Debian right now.
[09:19] <lilstevie> glibc abi break?
[09:19] <infinity> lilstevie: Eh?  Well, we're ahead of Debian, that's all.  2.15 versus 2.13.
[09:19] <infinity> So, if their build accidentally picks up any 2.14/2.15 symbols, no workie on Debian.
[09:20] <infinity> Not a big deal.
[09:20] <lilstevie> ah
[09:20] <infinity> Maybe if I find some spare time post-release, I'll wrangle Debian to 2.15 as well.
[09:21] <infinity> But I don't look forward to making sure all the weird (k*bsd, gah) patches forward-port cleanly.
[09:21] <lilstevie> lol, yeah that does not sound fun at all
[09:22] <lilstevie> by the way have you looked at the universal kernel thing at all for tegra?
[09:23] <infinity> Haven't had any time to play, really. :/
[09:23] <infinity> It obviously won't happen for precise, with release being 1.5 weeks away. :P
[09:23] <lilstevie> heh yeah sure
[09:24] <lilstevie> more for future
[09:24] <lilstevie> gives time to work on a proper solution
[09:25] <lilstevie> we have some hacks in the tf201 kernel that may help expand it out a bit though
[09:25] <lilstevie> https://github.com/EnJens/kernel_tf201_stock/commit/cbdf1403453c6a6304c25df94b4f371d229b9030
[09:40] <rbasak> What's the easiest/recommended way of telling armel and armhf apart from ubuntu userspace?
[09:40] <rbasak> I know of dpkg-architecture but that needs it to be installed
[09:41] <rbasak> ldd /bin/sh or something perhaps?
[09:41] <infinity> rbasak: dpkg --print-architecture.
[09:42] <infinity> rbasak: Anything else could be a false positive, due to multi-arch.
[09:42] <rbasak> awesome, thanks!
[09:42] <infinity> rbasak: (but if it's not a multi-arch system, testing for linkers and such works, yeah)
[09:43] <infinity> rbasak: I would have assumed you'd already know of dpkg --print-architecture :P
[09:43] <rbasak> I knew that dpkg knew the answer, just didn't know about that flag.
[09:43] <infinity> Don't tell me that people are using uname hacks or something to determine i386/amd64.
[09:43] <infinity> Which is, again, wrong.
[09:44] <rbasak> They probably are
[09:44] <rbasak> dpkg isn't cross-distro!
[09:44] <infinity> Err, no, but you use the right tools on the right targets.
[09:44] <infinity> userspace and kernel arch don't relate at all. :/
[09:44] <infinity> I really don't want to look at cobbler and maas and all that, do I?
[09:45] <infinity> I'll just end up crying.
[09:45] <rbasak> :)
[09:45] <rbasak> cobbler is quite RH biased.
[11:24] <nimesh_accenture> how do I put the pandaboard in fastboot mode? i'm basically stuck on :  out/host/linux-x86/bin/fastboot oem format , it says waiting fro devices
[11:26]  * ogra_ thinks thats better asked in an android channel :)
[11:42] <lilstevie> infinity: I have used the tag off uname in my installer shell script for ubuntu for the transformer cause I couldn't find a better way
[11:42] <lilstevie> that works cross-platform
[11:43] <ogra_> lilstevie, not cross platform, but cleaner: use archdetect
[11:44] <lilstevie> ok :)
[11:45] <lilstevie> well to be honest when I get some time to tackle Qt being a PITA I will be migrating over to a GUI anyway
[11:45] <infinity> lilstevie: Why would you need uname for a device-specific installer?  It'll always be the same, surely? :P
[11:52]  * ogra_ thought he had seen infinity say good night a while ago in a differnt channel ... 
[11:52] <ogra_> :)
[11:53] <infinity> ogra_: I failed.
[11:53] <ogra_> as usual ...
[12:18] <lilstevie> infinity: there is an executable that will only work in its flavor (i386 or x86_64)
[12:19] <infinity> lilstevie: So, I can't install to transformer from my PPC machine?  Sad.
[12:20] <infinity> lilstevie: But yeah, uname's the wrong answer for that.  I could have an x86_64 kernel and an i386 userspace, and the binary would still fail.
[12:20] <lilstevie> true
[12:20] <lilstevie> and no, you cannot because there isn't an nvflash for ppc
[12:21] <xranby> how about using qemu-user and a i386 userspace on the ppc to run nvflash?
[12:22] <lilstevie> well that could work
[12:22] <lilstevie> however an upcoming program should handle that
[12:23] <lilstevie> we have spent the past few months reversing the protocal
[12:25] <xranby> how nice of you,  setting up qemu-user are quite a pain :)
[12:25] <xranby> i have mostly used it to run some of the android sdk binarys on my ac100
[12:25] <lilstevie> heh
[12:27] <lilstevie> it doesn't help that there are 2 very different versions from HC to ICS though
=== doko_ is now known as doko
[13:48] <djszapi> ogra_: Hey, interesting that, ubuntu does not have /usr/include/linux/leds.h for the pandaboard
[13:50] <ogra_> did you look under /usr/include/arm-linux-gnueabihf/ ?
[13:51] <ogra_> and do you have the necessary -dev packages installed that contain the headers
[13:52] <djszapi> root@linaro-ubuntu-desktop:~# find /usr/include/arm-linux-gnueabi/ -name \*led\*
[13:52] <djszapi> root@linaro-ubuntu-desktop:~#
[13:53] <djszapi> find /usr/include/ -name \*led\* -> returns nothing
[13:54] <djszapi> interesting patch from the near past:
[13:54] <djszapi> http://lwn.net/Articles/492249/
[13:55] <djszapi> http://us.generation-nt.com/answer/patch-arm-omap4-pandaboard-turn-phy-reference-clock-at-init-help-201703292.html -> linux/leds.h should exist, but it does not apparently exist for some reasons. :/
[13:56] <ogra_> it definitely exists in some package
[13:56] <ogra_> install apt-file and search for it ;)
[13:57] <djszapi> I would hope for its availability by default on the pandaboard...
[13:58] <ogra_> not if its in i.e. linux-ti-omap4-dev or some such
[13:58] <ogra_> we dont install dev packages by default
[13:58] <djszapi> uncool on a dev board
[13:58] <ogra_> well, we do, but only a selected minimal set
[13:58] <ogra_> we also dont special case our images for "dev boards" :)
[13:59] <ogra_> thats something linaro does
[13:59] <djszapi> well, it is a linaro-ubuntu-desktop after all.
[13:59] <ogra_> well, if you used a linaro image, ask them about the header ;)
[13:59] <djszapi> #linaro ?
[14:00] <ogra_> ubuntu just tries to build as close to the other areches as possible if it comes to images
[14:00] <djszapi> hmm, apt-file update downloads a lot of stuff...
[14:01] <ogra_> its like apt-get ... carries its own db though
[14:02] <ndec> ogra_: hi. is 12.04 LTS for ARM?
[14:02] <ogra_> only on server afaik
[14:02] <ogra_> havent heard any final words about LTS yet though
[14:02] <ndec> ok.
[14:03] <ndec> btw, what does 'only server' mean? you can install any package even on server, no?
[14:04] <ogra_> sure, but only packages in the server set will be cared for during the 5 year period in that case
[14:04] <djszapi> ogra_: the newest packages are "linux-headers-3.0.0-17" and "linux-headers-3.0.0-17-omap".
[14:04] <ogra_> desktop gets updates from the x86 uploads indeed, but nobody would look into arm specific issues after 18 months
[14:04] <djszapi> ...and I am having this: uname -r
[14:04] <djszapi> 3.1.1-26-linaro-lt-omap
[14:04] <ogra_> djszapi, you look for omap4
[14:05] <ogra_> and *not* a linaro kernel (unless thats what you currently use)
[14:05] <djszapi> I do ?
[14:05] <djszapi> linux-headers-3.0.0-1208-omap4 -> this is the newest I found.
[14:05] <ogra_> yeah, that sounds right
[14:05] <ogra_> though there might be a 3.2 one as well
[14:05] <ogra_> or should
[14:06] <djszapi> not after apt-get update
[14:06] <ogra_>  linux-ti-omap4 3.2.0-1412.16 was the last upload to 12.04
[14:07] <djszapi> it is oneiric...
[14:07] <ogra_> oh, then that could be right
[14:27] <ogra_> infinity, https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2012-April/013579.html did that accidentially change ?
[15:15] <gsnedders> Hey, is 12.04 going to be LTS on ARM?
[15:26] <GrueMaster> gsnedders: That is the working theory, except it will probably only apply to the pool, not to any specific platform image.
[15:27] <gsnedders> GrueMaster: k, thx!
[15:27] <ogra_> gsnedders, only server packages will be LTS on arm
[15:28] <ogra_> and only on omap4 (though that doesnt matter much for userspace)
[15:28] <ogra_> https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest
=== mckoan is now known as mckoan|away
[15:30] <gsnedders> ogra_: I guess things like libGL aren't server?
[15:30] <ogra_> right
[15:54] <jimerickson> todays image works. updated and installed pvr sgx driver. all is well.
[15:57] <pnphi> How to build package for ARM in chroot ?
[15:57] <smplman> jimerickson: what hardware>?
[15:57] <jimerickson> oh sorry the pandaboard ES
[15:57] <pnphi> ARM ubuntu
=== zyga is now known as zyga-food
[16:01] <smplman> jimerickson: i can't get sec working on my beagle board xm
[16:01] <smplman> sgx*
[16:02] <nimesh_accenture> ok guys.. so i've succesfully managed to chroot ubuntu-core 11.10 on android ICS 4.03 ... gtg now ... and thx for helping me out!
[16:03] <ogra_> smplman, please file a bug ... i think we missedf to add autodetection support to jockey for omap3 ... while omap4 landed (so you get the sgx driver automatically after first boot)
[16:03] <ogra_> (file it against the "jockey" package)
[16:04] <smplman> how are you all pulling the binary bits from TI?
[16:04] <ogra_> they hand them to linaro, linaro prepares a package, some ubuntu dev uploads to the ubuntu archive
[16:04] <pnphi> How to build package for ARM in chroot ?
=== Quintasan_ is now known as Quintasan
[16:35] <djszapi> ogra_: Hey! Is it normal if the Status Led 1 still keeps blinking after running a "sync(); reboot(LINUX_REBOOT_CMD_POWER_OFF);" from my application so the board is essentially powered off.
[16:44] <djszapi> ogra_: what twl6030 power features have you put in there ?
[16:44] <djszapi> this is the "uname -a" output: Linux linaro-ubuntu-desktop 3.1.1-26-linaro-lt-omap #26~lt~ci~20120325001352+1332635991~4f6ec49b-Ubuntu SMP PREEMPT  armv7l armv7l armv7l GNU/Linux
[16:54] <GrueMaster> djszapi: This is probably best asked on #linaro, as it is their kernel, not the stock Ubuntu kernel.
[17:01] <ogra_> yeah, thats not our kernel
[17:01] <djszapi> perhaps not
=== Matt_O2 is now known as Matt_O
=== zyga-food is now known as zyga-afk
=== prpplague^2 is now known as prpplague
[19:49] <infinity> ogra_: --as-needed has been the default since oneiric.  Not sure where this person got "a few days ago".
[19:51] <micahg> hehe, we even fiddled with it during the natty dev cycle and reverted at the last minute