[10:28] <aholler> hello, having read about the problem to build 20,000 packages for arm and the panda-cluster, I wonder if the ubuntu-devs ever tried or even heard about icecream? http://en.opensuse.org/Icecream
[10:30] <ogra_> yes
[10:31] <GrueMaster> aholler: Distribuited buildshave not been the issue.  The issue has been lack of hardware for native builds.
[10:31] <aholler> using icecream you could use every x86 box
[10:32] <aholler> to help you build your packages
[10:32] <GrueMaster> How can anx86 build arm "native" packages?
[10:32] <aholler> read about how icecream works
[10:32] <GrueMaster> Not cross-compiled. Native.
[10:32] <aholler> sure
[10:33] <GrueMaster> x86 does not run arm instructions w/o emulation.
[10:33] <aholler> read about how icecream works
[10:34] <aholler> ogra_: do you have tried it?
[10:34] <GrueMaster> After a quick glance, again I ask how this would have helped the lack of arm hardware issue we faced prior to our panda cluster?
[10:35] <GrueMaster> btw:  I have worked on distribuited build environments before.
[10:35] <ogra_> package builds are usually single threaded, that doesnt gain you much with most packages
[10:35] <aholler> GrueMaster: you could use e.g. make -j20 and the compilation would be done by the x86-boxes
[10:36] <aholler> but the tests would be done localy = native
[10:36] <GrueMaster> Listen to what I am saying.  how does an x86 box compile native arm code w/o cross-compiling?
[10:36]  * ppisati didn't read anything about "the problem to build 20,000 packages"
[10:37] <GrueMaster> I spent 8 years in processor validation at Intel, and now work on arm code.  The instruction sets areentirely different.
[10:37] <aholler> GrueMaster: again, read about how icecream works.
[10:37] <aholler> nothing on your arm-box will see the difference
[10:37] <aholler> there is cross-compiling and cross-compiling
[10:37] <ogra_> the binaries will be built with a cross toolchain ...
[10:37] <ogra_> thats the difference
[10:38] <aholler> just the objects
[10:38] <ogra_> you cant guarantee that you get identical binaries with a cross toolchain
[10:38] <GrueMaster> We build all binary packages on their native hardware.  We do not rely on cross-compilation.
[10:38] <aholler> GrueMaster: I assume you haven't understand how icecream works. anyway, I'm off, I don't see why I should try to continue this discussion
[10:39] <GrueMaster> I know how icecream works.  I have talked with some of the devs when they started building it.
[10:40] <ogra_> iirc NCommand1r used it across 4 babbages for OOo builds
[10:40] <GrueMaster> No, he used distcc.
[10:40] <ogra_> hmm, i thought it was icecream
[10:40] <hrw> I love this kind of talks
[10:40] <ogra_> hrw, you could have chimed in :)
[10:41] <hrw> 'hey guys, why you are building natively? are you insane? cross compilation on farm of cheap x86 is better' etc...
[10:41] <ogra_> as compiler expert
[10:41] <suihkulokki> I guess the guy you chased away was trying suggest running the build on one arm machine which the calls icecream/distcc to x86 machines running crosscompilers
[10:41] <ogra_> suihkulokki, yes
[10:41] <ogra_> SuSE OBS ...
[10:42] <suihkulokki> OBS dodn't due that
[10:42] <ogra_> i thought they inject an x86 compiler into a native build env
[10:43] <suihkulokki> you should invite the guy back if you are really intersted in how they do instead of rejecting them on sight ;)
[10:43] <GrueMaster> I honestly don't see how ANY distributed environment would benefit anyone that needs native hardware and doesn't have it.
[10:43] <ogra_> the distributed part only helps with packages using -jN
[10:44] <GrueMaster> We could easily deploy icecream (or any other distributed build environment) on our cluster, but the issue was the lack of hardware.
[10:44] <hrw> suihkulokki: like GrueMaster said - we lack native builds and this is a problem to solve
[10:45] <hrw> xU with 120 a9 quadcores for example - I read on linuxdevices that someone is working on such beast
[10:46] <GrueMaster> yep.  That would be a nice addition to my rack cabinet at home.  :P
[10:46]  * ogra_ waits until he can buy that in a mac mini like case
[11:15] <garagoth> GrueMaster: Hi. You and rsalveti have provided patched kernel for Beagle xM rev C. Is it possible to have it patched to support i2c bus 2, which is available on expansion port/
[11:15] <garagoth> ?
[11:33] <GrueMaster> garagoth: Have to ask rsalveti.  As soon as he provides me with a binary, I'll update the tarball.
[11:39] <hrw> ogra_: btw - how much ac100 costs in .de?
[11:46] <garagoth> GrueMaster: Ok, thanks.
[11:47] <garagoth> rsalveti: Is it possible for you to patch that patched kernel you prepared for beagle xm rev C to support i2c bus 2 (which is on expansion port) ?
[11:47] <ogra_> hrw, my last one costed me 170€ off the shelf
[11:48] <hrw> 202EUR here
[11:48] <ogra_> ppisati, http://hackaday.com/2011/06/12/how-canonical-automates-linux-package-compilation/ ...
[11:48] <GrueMaster> ogra_: It was cheaper because of that funky keyboard.  :P
[11:49] <ogra_> "Canonical needed a way to compile about 20,000+ packages for the ARM platform, however they did not want to cross-compile, which is quite time consuming."
[11:49]  * ogra_ shakes his head
[11:49] <ogra_> why would cross compiling be quite time consuming
[11:49] <garagoth> on the contrary I would say...
[11:50] <ogra_> heh, yeah
[11:50] <ogra_> probably i'm reading it wrong though
[11:55] <suihkulokki> there is no ubuntu-arm mailing list?
[11:56] <hrw> bug 791302 needs someone familiar with library symbols?
[11:56] <ubot2> Launchpad bug 791302 in libechonest "libechonest version 1.1.3-1 failed to build on armel" [Undecided,New] https://launchpad.net/bugs/791302
[11:56] <hrw> suihkulokki: no, ubuntu-mobile was dropped
[11:56] <hrw> suihkulokki: ubuntu-devel is used
[11:57] <suihkulokki> I shall spam ubuntu-devel then =)
[12:01] <aholler> ok, I'll try it again.
[12:01] <aholler> To enlight the people here about waht I'm speaking, using icecream only a part of the compilation process is distributed. And there is absolutely no problem when this part is a cross-compiler/-assembler. Thats a whole difference to what people usually are thinking about cross-compiling.
[12:02] <aholler> And using icecream is much better than using distcc, because the building machine distributes the (cross-)compiler (as a chroot, once).
[12:02] <aholler> what gets distributed is a tar-archive containing that stuff: http://www.fpaste.org/PyrG/
[12:02] <hrw> aholler: does it takes care of mix of amd64/i386/armel/armhf build machines too?
[12:03] <aholler> yes, the build-machine gets informed about the architecture of the slaves and can send them the needed chroot
[12:03] <hrw> I think I will have to setup icecream farm of pandas here
[12:03] <aholler> or just don't use them
[12:03] <aholler> that even speeds up compiling using only -j1
[12:04] <ogra_> aholler, as i said above, we wouldnt get much benefit from a distributed env, the majority of the packages will default to not use -jN
[12:04] <hrw> aholler: I spent 6 years on cross compilation
[12:04] <ogra_> there are some where it really helps, i agree
[12:04] <ogra_> i.e. libO
[12:04] <aholler> hrw: fine for you
[12:05] <ogra_> or firefox ... but the majority wont really benefit from it... for us its more important to build as many *differnt packages* at the same time as possible
[12:06] <aholler> most packages could be build using -jN, at least when ext4 is used.
[12:06] <ogra_> the target of the build cluster is to empty the queue as fast as possible to keep up with the other arches, so "more paralell builds" > "faster builds"
[12:06] <aholler> with ext3 there are more problems, because of the limited timestamp
[12:07] <aholler> a single source is still compiled a lot faster on x86 (+network transfer) than on an arm
[12:07] <ogra_> it would be good to have a fully native icecream setup on another panda cluster though and route the packages that can benefit from it to that build system
[12:08] <ogra_> we definitely wouldnt use it with a cross compiler
[12:09] <GrueMaster> Actually, if icecream can manage client build systems appearing on the fly, it could easily be deployed now on our panda cluster.
[12:09] <ogra_> but the concept could indeed help with native compilers too ...
[12:09] <aholler> do you expect a different output from a cross-assembler than native?
[12:09] <ogra_> the possibility exists
[12:09] <GrueMaster> aholler: Yes, and we have actual documented bugs with that.
[12:10] <aholler> don't mix that concept icecream/distcc uses which the stuff people usually are understanding with cross-compiling
[12:10] <aholler> s/which/with/
[12:11] <aholler> anyway, it is just a suggestion, I don't need to convince the people here.
[12:12] <ogra_> well, i like the concept of distributed building ...
[12:12] <aholler> ditributed cross- is even better
[12:12] <ogra_> thats something i would not agree on :)
[12:13]  * ppisati -> out to get some food
[12:13] <aholler> I've used that a lot to build x32packages on x64-machines (and vice-versa) several years before
[12:14] <aholler> no, wrong, the other machines helped building the packes, they haven't build them
[12:14] <aholler> anyway, maybe one of you might try it. I'm off again. ;)
[12:14] <GrueMaster> we use x86_64 machines to build i386 packages all the time.  That isnt an issue.
[12:15] <ogra_> he's gone
[12:17] <hrw> hm. how to call shell in perl and get return as value of variable?
[12:19] <GrueMaster> hrw:  give me a minute and I'll pastebin a sample ofcode I wrote while at Intel.
[12:22] <hrw> $var = `command`; ;)
[12:23] <ogra_> thats as clever as using system() :P
[12:24] <hrw> with system I have to play with $? etc to get result
[12:26] <hrw> looks like gnu-smalltalk will be fixed
[12:26] <hrw> not that I know perl but fix was needed in perl script
[12:28] <GrueMaster> hrw: Looks like you have it.
[12:28] <hrw>     my $multiarch_dir = `dpkg-architecture -qDEB_HOST_MULTIARCH`;
[12:28] <hrw>     chomp($multiarch_dir);
[12:29] <hrw> and then one more check in script
[12:30] <hrw> ok. passed step where it was failing
[12:31] <hrw> now time for debdiff
[12:31] <persia> hrw, Why not "use Dpkg:Arch ..."?  That should save considerable cycles.
[12:32] <persia> (if you just care about multiarch, then "use Dpkg:Arch qw(debarch_to_multiarch);" is probably sufficient)
[12:32] <hrw> persia: because I do not know perl?
[12:33] <hrw> persia: so I am trying to get some hack which works and then it can get improved
[12:33] <persia> hrw, Heh.  So, take a look at the dpkg-architecture source.
[12:33] <persia> It's fairly trivial to just pull the value from the libary (and we have a nice code example)
[12:33] <hrw> thx
[12:34] <persia> Around line 196 is the bits you'll need, although you'll also  need the use statement near the top.
[12:36] <hrw> my $multiarch_dir = debarch_to_multiarch(get_raw_host_arch());
[12:36] <persia> That looks cleaner to me.  Does it work?
[12:36] <persia> Also, how is get_raw_host_arch() implemented?  Is this something you could also pull from the library?
[12:36] <hrw> both are from Dpkg::Arch
[12:37] <hrw> I picked code from dpkg-architecture
[12:37] <persia> Ah, heh.  That sounds ideal then, if it works :)
[12:37] <hrw> persia: build in process
[12:37] <persia> Just be sure to specify both in the use statement, so they are available.
[12:37] <hrw> did
[12:37] <persia> Perfect :)
[12:37] <hrw> persia: thanks for tips
[12:37] <persia> No problem.  Thanks for asking for help on the channel *before* you found the final solution.
[12:39] <hrw> persia: as I'm not perl programmer I prefer to make sure that my thinking is right.
[12:39] <hrw> persia: and my workflow for bugs is: make a fix and then make a fix to be a proper fix
[12:40] <persia> Makes sense.  I tend to try for a precise problem statement, then a proper fix (which is nearly the same thing, except that I tend to express the problem in English rather than code).
[12:41] <hrw> persia: first ver of fix was good but implementation was bad ;D
[12:41] <persia> Not bad, just didn't take advantage of the fact that dpkg-architecture was itself implemented in perl, with a handy library.
[12:42] <persia> Was dpkg-architecture in C, then I think your implementation would have been the least bad.
[12:42] <persia> (assuming nobody had created perl bindings for the library)
[13:08] <rsalveti> ppisati: ogra_: GrueMaster: http://comments.gmane.org/gmane.linux.redhat.fedora.arm/1266
[13:08] <rsalveti> pointed by agreen, if we want to have a better buildd this would be something to look for
[13:10] <garagoth> rsalveti: Is it possible for you to patch that patched kernel you prepared for beagle xm rev C to support i2c bus 2 (which is on expansion port) ?
[13:11] <rsalveti> garagoth: sure, sorry, just got on-line
[13:11] <rsalveti> garagoth: what exactly do you need?
[13:11] <garagoth> I have trainer board from tin can tools attached to beagle xm C and I need to use i2c which is there.
[13:12] <garagoth> It is nice as it is level translated to 5V
[13:12] <garagoth> it is i2c bus 2
[13:12] <garagoth> but on your kenel only buses 1 and 3 are visible
[13:13] <rsalveti> garagoth: oh, ok, guess it's the patch pointed by rcn-ee
[13:16] <garagoth> I hope so :-) I had no sources of your kernel, so could not test it myself.
[13:16] <GrueMaster> rsalveti: I had seen a blurb on the pandaboard mailing list regarding usb drive speed & networkiing.  When I get home I mean to do some additional testing, including using a usb-nic (not the on-board nic) to see if that makes a difference.
[13:17] <rsalveti> garagoth: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=summary if you get the HEAD you'll get the same working kernel
[13:17] <rsalveti> 10.44
[13:18] <rsalveti> garagoth: if you build this kernel and add the patch https://github.com/RobertCNelson/stable-kernel/blob/master/patches/sakoman/2.6.39/0032-OMAP3-beagle-add-support-for-expansionboards.patch it may work
[13:18] <rsalveti> didn't check if you need any other dependencies
[13:19] <garagoth> rsalveti: So, build it myself or will you be doing it anyway?
[13:20] <rsalveti> garagoth: I can guide you if you want, then you can hack it later if needed ;-)
[13:20] <ogra_> rsalveti, what exactly do you suggest ? rinning a ping daemon ?
[13:20] <ogra_> *running
[13:20] <rsalveti> ogra_: well, agreen is investigating the kernel to see if we can get a fix
[13:20] <garagoth> Would be nice. I need to setup cross-compile env for ubuntu then... somehow :-) Or compile on Beagle
[13:21] <rsalveti> but would be good to keep an eye on it
[13:22] <rsalveti> garagoth: http://www.omappedia.org/wiki/Ubuntu_kernel_build_alternatives
[13:24] <garagoth> rsalveti: Ok, processing...
[13:26] <garagoth> I guess you are cross-compiling?
[13:27] <ppisati> rsalveti: weird
[13:28] <rsalveti> garagoth: yes
[13:28] <rsalveti> ppisati: why? same chip for both usb and eth :-)
[13:30] <persia> I like the FIFO queue not overflowing answer.  It's more plausible than most of the other proposed "why"s.
[13:33] <ogra_> well, the ignore_oc stuff seems like a red herring to me
[13:35] <persia> I'd say so.
[13:35] <persia> But that's different than the queue management.
[13:41] <zumbi_> persia: can i have unity on pandaboard?
[13:41] <zumbi_> (on natty I mean)
[13:42] <persia> zumbi_, You can have unity-2d.  I don't believe everything was ported to work properly with the GLES drivers TI provided.
[13:42] <persia> (someone please correct me if I'm wrong).
[13:42] <zumbi_> so unity-3d not yet ready on arm hw :/
[13:43] <zumbi_> persia: thanks
[13:43] <ogra_> zumbi_, in th enext weeks
[13:43] <zumbi_> ogra_: sure, I guess as part of oneiric
[13:44] <ogra_> there are two bugs left afaik ... once these are solved it should be available for natty
[13:44] <ogra_> later then oneiric
[13:44] <ogra_> (all work is done on the natty branches atm and will need forward porting then)
[13:45] <persia> ogra_, This is GLES porting?
[13:45] <ogra_> yes
[13:45] <zumbi_> uhm.. ok, sounds fine, I'll try it on few weeks then
[13:45] <ogra_> for compiz, nux and unity
[13:45] <ogra_> zumbi_, rsalveti should be able to point you to a PPA for that
[13:45] <persia> zumbi_, What's your specific interest?  The interface, or reviewing the code paths?
[13:46] <ogra_> (beyond that they should show up in the natty release PPA for panda)
[13:46] <persia> If the former, then unity-2d is supposed to be mostly the same (although some things are different)
[13:46] <persia> If the latter, I'm sure folk would appreciate additional testing/help with the remaining few bugs.
[13:46] <rsalveti> zumbi_: https://launchpad.net/~rsalveti/+archive/unity-3d-gles
[13:46] <persia> ogra_, Do you happen to know the bug numbers?
[13:46] <rsalveti> zumbi_: not fully working yet
[13:46] <zumbi_> persia: right now, my interest is have a technology preview, we are currently using Qt for UI design
[13:47] <zumbi_> rsalveti: thanks
[13:47] <rsalveti> but you should be able to try it in the following days
[13:47] <ogra_> persia, for what ?
[13:47] <persia> zumbi_, unity-2d is implemented in Qt, so yeah, that doesn't necessarily show anything particularly different.
[13:47] <persia> ogra_, The compiz/nux/unity bugs.
[13:47] <ogra_> i dont think there are bugs
[13:47]  * persia grumbles
[13:48] <persia> When "there are two bugs left", those should be filed in launchpad, and discussion happen there.
[13:48] <ogra_> there is a team working fulltime on fixing them though :)
[13:48] <persia> And the team doesn't want another member, for some reason?
[13:48] <ogra_> and they report to places i am
[13:48] <ogra_> ask linaro :)
[13:48] <ogra_> i guess they wont deny if someone wants to help indeed
[13:49] <persia> rsalveti, Are there bugs?  What sort of help could speed the process?
[13:49] <rsalveti> persia: https://bugs.launchpad.net/unity-gles
[13:49] <persia> Only one left!
[13:49] <persia> zumbi_, ^^
[13:50] <ogra_> i thought there was one nux bug too
[13:50] <ogra_> but seems that got fixed already
[13:50]  * jussi prods at persia
[13:50] <rsalveti> we just discussed at the call and we may have an additional bug for nux
[13:50] <rsalveti> but still not confirmed
[13:51] <rsalveti> but it should all be sorted out during this and next week
[13:52] <ogra_> the screenshots look cool though
[13:53] <ogra_> you should leave it that way and call it unidelic instead of unity :)
[13:54] <rsalveti> ogra_: hehe :-)
[15:05] <rsalveti> and another porting jam just starting at #linaro! come and help us making ubuntu better on arm :-)
[15:05] <rsalveti> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue&orderby=-id
[15:10] <ogra_> GrueMaster, soo, your ac100 ... did you actually test if the issues also show up if you manually untar the rootfs ?
[15:11] <GrueMaster> I have put it back on the back burner.  Need to be productive on current tasks.
[15:11] <ogra_> k
[15:11] <ogra_> well, i cant do much until we have identified the actual problem
[15:12] <ogra_> make sure to definitely bring it to dublin
[15:13] <GrueMaster> I plan on it.
[15:13] <ogra_> will surely be faster to find the issue if i have direct access
[15:14] <GrueMaster> Not sure what the final goal is.  If it is just to get me enabled with an ac100, I'll do it as time allows.  If we plan on deploying a working installation for other users, it makes sense to debug it and I can add it to the test pool as time allows.
[15:15] <ogra_> well, i want the installer to work properly on all models indeed
[15:23] <ppisati> seems we are not the only one experiencing issue with usb and gcc 4.6:
[15:23] <ppisati> https://lists.yoctoproject.org/pipermail/poky/2011-April/005703.html
[15:24] <ppisati> the thread continues in may 2011 too
[15:24] <ppisati> https://lists.yoctoproject.org/pipermail/poky/2011-May/005763.html
[15:24] <garagoth> rsalveti: Ok, more or less the patch succeeded. Is git clone of the kernel source already with proper config, same as it is on beagle?
[15:27] <brendand> fully updated 11.04 running on a pandaboard, when i try to boot it i get things like
[15:27] <brendand> (stk) : line disc installation timed out
[15:27] <brendand> (stc) : KIM failure complete callback
[15:27] <GrueMaster> that is the bluetooth driver.  known issue.
[15:28] <brendand> ah - i just needed to wait long enough
[15:28] <brendand> never saw that before, is it an update-regression?
[15:29] <ppisati> and it seems there's a fix... testing...
[15:29] <GrueMaster> Yes and no.  It didn't happen in maverick as the driver was rewritten and hasn't been finalized at time of release.
[15:34] <hrw> what is a proper way to request arm rebuild of package?
[15:34] <hrw> octave-communications 1.0.10-3 was ftbfs on armel 7 weeks ago due to lack of build deps. now they are fulfilled
[15:35] <ogra_> one sec
[15:35] <hrw> I am building this package on panda now
[15:35] <hrw> it was bug 791314 btw
[15:35] <ubot2> Launchpad bug 791314 in octave-communications "octave-communications version 1.0.10-3 failed to build on armel" [Undecided,New] https://launchpad.net/bugs/791314
[15:36] <ogra_> rebuild triggered
[15:36] <hrw> thx
[15:36] <ogra_> https://launchpad.net/ubuntu/+source/octave-communications/1.0.10-3/+build/2469824
[15:36] <hrw> I just loaded that
[15:38] <GrueMaster> ppisati: The thread continues in June as well.
[15:38] <ogra_> yeah
[15:38] <ogra_> differently named though
[15:39] <ogra_> https://lists.yoctoproject.org/pipermail/poky/2011-June/006634.html is very intresting
[15:41] <ppisati> and there's a fix
[15:41] <ppisati> wait...
[15:42] <ogra_> ppisati, https://lists.yoctoproject.org/pipermail/poky/2011-June/006646.html this one ?
[15:44] <ppisati> yep
[15:44] <ppisati> but it seems it's not working :(
[15:44] <ogra_> well, they later say you should just remove the line completely
[15:45] <ppisati> let's try...
[15:48] <ppisati> nope
[15:50] <ppisati> anyway, let me forward this info the toolchain people
[15:51] <ogra_> yeah
[15:51] <ogra_> a disassembly like that from our own binaries might help too i guess
[15:54] <ppisati> yep
[15:54] <ppisati> in the April they were saying they had this issue with the vanilla FSF 4.6 toolchain so it seems it's an upstream bug
[15:59] <ogra_> could be
[16:04] <ppisati> ok, mail sent
[16:04] <ppisati> let me update the lp bug too
[16:04] <ogra_> ++
[16:26] <garagoth> I'm trying to compile ubuntu kernel for Beagle, but process fails with error: "as: unrecognized option '-Qy'"
[16:26] <garagoth> Any hints?
[16:30] <hrw> which ubuntu?
[16:30] <hrw> and do you have binutils-arm-linux-gnueabi installed?
[16:33] <garagoth> natty
[16:33] <garagoth> and yes, I have
[16:39] <garagoth> so...?
[16:46] <garagoth> rsalveti: ping
[16:47] <melis51> hi, anyone knows the uname+pwd for ubuntu-11.04-preinstalled-netbook-armel+omap.img.gz, thx
[16:47] <ogra_> there is none
[16:47] <ogra_> you set it up during the first boot
[16:47] <garagoth> during install you setup your user
[16:47] <melis51> this is a pre-installed image
[16:48] <garagoth> pre-installed image which install itself
[16:48] <garagoth> at least should...
[16:48] <ogra_> yes
[16:49] <garagoth> you boot it, it should show you installer
[16:49] <garagoth> you select lang, keyboard, packages, user
[16:49] <melis51> the first thing I see is a log-in screen
[16:50] <melis51> the only option is to click 'other' user
[16:50] <garagoth> on dvi port?
[16:50] <melis51> yes
[16:50] <garagoth> is it ubuntu branded?
[16:50] <melis51> yes, and this is where I downloaded from: http://cdimage.ubuntu.com/releases/11.04/release/ubuntu-11.04-preinstalled-netbook-armel+omap.img.gz
[16:51] <GrueMaster> melis51: What platform are you using?
[16:51] <melis51> Beagleboard
[16:51] <GrueMaster> What rev?
[16:51] <melis51> c3
[16:53] <GrueMaster> Odd, although you may be running out of memory.  I don't remember an issue testing on my C4 though.
[16:54] <garagoth> on bb-xM rev C I saw setup screen on X
[16:54] <ogra_> try the headless image instaed and then install ubuntu-netbook using tasksel
[16:54] <GrueMaster> When you boot, is it pulling anything from nand, or is it booting completely off the SD?  You can tell by watching the serial console.
[16:54] <ogra_> oh, right, NAND !
[16:54]  * ogra_ totally forgot 
[16:55] <GrueMaster> ogra_: That's why you keep me around. :P
[16:55] <ogra_> indeed, it might not pull the right initrd in
[16:55] <ogra_> GrueMaster, yeah, we all love you :)
[16:55] <melis51> I can't tell right now, but will check
[16:56] <lag> Do the ARM PPAs build naively?
[16:56] <ogra_> melis51, there are instructions on the wiki how to make sure to boot right
[16:56] <ogra_> lag, yes, thats why they arent public
[16:56] <lag> ogra_: All of them? Even my own PPA?
[16:57] <ogra_> only trusted people have upload permission
[16:57] <GrueMaster> melis51: Check the Maverick instructions.  They have more detail on the beagleboard w/ nand.
[16:57] <ogra_> indeed you can make the binaries public
[16:57] <melis51> ora_ I fallowed GrueMaster's instructions on the wiki that worked up until the log-in screen
[16:57] <lag> ogra_: Let me try to explain
[16:57]  * GrueMaster updates the instructions for natty.
[16:58] <melis51> ok I will try Maverick, but would be nice to get the latest ver to work too
[16:59] <ogra_> you dont need to try maverick
[16:59] <ogra_> only the maverick instructions for booting begales with NAND on them
[16:59] <melis51> ok
[16:59] <garagoth> Maybe someone can help me with cross-compiling to beagle on natty? I have "as: unrecognized option '-Qy'"
[17:00] <ogra_> garagoth, well, hrw is your best option ... beyond that, file a bug against the cross toolchain
[17:01] <GrueMaster> melis51: You can use natty, just follow the maverick instructions specific to the beagleboard rev C.
[17:01] <GrueMaster> Natty Instructions updated to include these now.
[17:01] <hrw> garagoth: fill a bug with exact info what you are doing ok?
[17:01] <melis51> ok thanks I'll try
[17:01] <garagoth> hrw: ubuntu-bug or ..?
[17:02] <hrw> garagoth: ubuntu-bug armel-cross-toolchain-base
[17:02] <hrw> garagoth: add "arm-linux-gnueabi-gcc --version" into bug raport
[17:03] <garagoth> Ok.
[17:03] <lag> ogra_: http://ppa.launchpad.net/linaro-landing-team-ste/st-ericsson-u8500-public/ubuntu/pool/main/l/linux-u8500/
[17:04] <lag> Would that have been build natively
[17:04] <ogra_> lag, yes
[17:04] <lag> ogra_: Great, thanks!
[17:04] <ogra_> we dont so any non native builds in the datacenter
[17:04] <melis51> thanks everyone for your help!
[17:04] <ogra_> s/so/do/
[17:05] <garagoth> hrw: it says: no such package: armel-cross-toolchain-base
[17:05] <GrueMaster> melis51: got it working?
[17:06] <hrw> garagoth: so use binutils-arm-linux-gnueabi one
[17:06] <hrw> garagoth: armel-cross-toolchain-base is source package
[17:07] <melis51> I'm not at home, so I will try it a bit later today and will let you know, thanks
[17:25] <garagoth> hrw: Hm, can it be because I have no arm-linux-gnueabi-gcc? It is in package gcc-4.4-arm-linux-gnueabi, but I have gcc-4.5-arm-linux-gnueabi which install /usr/bin//usr/bin/arm-linux-gnueabi-gcc-4.5
[17:26] <garagoth> and there is no symlink or anything to arm-linux-gnueabi-gcc
[17:26] <hrw> garagoth: apt-get install gcc-arm-linux-gnueabi then
[17:29] <hrw> ok, time to finish session for me
[17:29] <hrw> have a nice rest of day
[17:30] <garagoth> Oooh. I removed from PATH /usr/arm-linux-gnueabi/bin and it started working
[17:30] <hrw> ARGH YOU! :D
[17:31] <garagoth> Yes, I create errors. But without your hint I would never find it.
[17:32] <garagoth> I was missing one package
[17:32] <garagoth> So, thanks a lot and have a nice day as well :-)
[17:32]  * garagoth crossess fingers to make it compile.
[17:34] <garagoth> If I do not click 'Submit bug report' on web page, it is not visible to anyone, right?
[18:30] <zul> persia: heya im working on a fix for libvirt on arm fyi
[18:50] <jkridner> excuse the FAQs, but is there an LTS release for ARM yet and will there be an armv7 Ubuntu release?
[18:50] <jkridner> my googling is returning misleading info.
[18:53] <GrueMaster> jkridner: 12.04 will be thefirst LTS release for arm.  Armv7 has been supported since 10.04
[18:53] <GrueMaster> (but 10.04 was not LTS for arm).
[18:53] <jkridner> thanks!
[18:54] <jkridner> I think 10.04 was armel, compatible with armv7, but not optimized for armv7.
[18:54] <GrueMaster> It was the first armv7 release.
[18:55] <infinity> Our armel port has been armv7 for a while.
[18:55] <infinity> Don't confuse the dpkg arch name with the compiler target.
[18:55] <infinity> (Much like our i386 port won't actually run on 80386 machines)
[18:55] <GrueMaster> True, not all packages were built with full armv7 optimizations, but main was.
[20:00] <zumbi> ogra_: there?
[20:01] <zumbi> someone know if ubuntu still needs mx51 or omap4 subarches on debian core, more specifically debian-installer
[20:01] <zumbi> lool: ^
[20:18] <melis51> GrueMaster: hi, I changed the setenv as you suggested, but ubuntu won't boot on my beagle
[20:52] <garagoth> rsalveti: ping
[20:53] <garagoth> Hm. I am trying to compile ubuntu kernel with expansion boards support and I have encountered a problem. Some boards have irq_set_irq_type(...) invoked but it is nowwhere defined
[20:54] <garagoth> google claims it to be a standard interrupt api function...
[20:58] <garagoth> hm, it is there named set_irq_type, not irq_set_irg_type... confusing...
[20:59] <rcn-ee_at_work> garagoth, that got changed in 2.6.39...
[21:01] <rcn-ee_at_work> garagoth, 2.6.38 and earlier used "set_irq_type", 2.6.39+ uses "irq_set_irq_type"
[21:01] <garagoth> damn. One small revision number...
[21:02] <garagoth> I'm sooo close to make it work, damn...
[21:02] <garagoth> So much trouble to have i2c bus 2 working ;-)
[21:03] <rcn-ee_at_work> well the simplistic patch would just to add: "omap_register_i2c_bus(2, 400, NULL, 0);"  in the i2c section... but i thought you had a trainer board..
[21:03] <garagoth> yes
[21:04] <garagoth> I have
[21:04] <rcn-ee_at_work> well, the big patch set's everything up for the trainer.. (and more..)
[21:04] <garagoth> and I found usage for gpio, so I need more then i2c, so patching...
[21:05] <garagoth> back to soldering while kernel continues to compile...
[23:59] <persia> zumbi, Support for mx5 and omap4 continues to be useful :)
[23:59] <zumbi> persia: thanks, you mean mx51?, I realized that reading omappedia.org