| === asac_ is now known as asac | ||
| === Lopi is now known as Lopi|idle | ||
| === lilstevie is now known as lilstevie|ZNC | ||
| === fairuz_ is now known as fairuz | ||
| === lilstevie|ZNC is now known as lilstevie | ||
| 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:28 |
|---|---|---|
| ogra_ | yes | 10:30 |
| 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:31 |
| 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:32 |
| GrueMaster | x86 does not run arm instructions w/o emulation. | 10:33 |
| aholler | read about how icecream works | 10:33 |
| 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:34 |
| 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:35 |
| 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:36 | |
| 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:37 |
| 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:38 |
| GrueMaster | I know how icecream works. I have talked with some of the devs when they started building it. | 10:39 |
| 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:40 |
| 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:41 |
| suihkulokki | OBS dodn't due that | 10:42 |
| ogra_ | i thought they inject an x86 compiler into a native build env | 10:42 |
| 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:43 |
| 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:44 |
| hrw | xU with 120 a9 quadcores for example - I read on linuxdevices that someone is working on such beast | 10:45 |
| 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 | 10:46 | |
| 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:15 |
| GrueMaster | garagoth: Have to ask rsalveti. As soon as he provides me with a binary, I'll update the tarball. | 11:33 |
| hrw | ogra_: btw - how much ac100 costs in .de? | 11:39 |
| garagoth | GrueMaster: Ok, thanks. | 11:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| ogra_ | heh, yeah | 11:50 |
| ogra_ | probably i'm reading it wrong though | 11:50 |
| suihkulokki | there is no ubuntu-arm mailing list? | 11:55 |
| 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:56 |
| suihkulokki | I shall spam ubuntu-devel then =) | 11:57 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| ogra_ | we definitely wouldnt use it with a cross compiler | 12:08 |
| 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:09 |
| 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:10 |
| aholler | anyway, it is just a suggestion, I don't need to convince the people here. | 12:11 |
| 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:12 |
| * 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:13 |
| 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:14 |
| ogra_ | he's gone | 12:15 |
| hrw | hm. how to call shell in perl and get return as value of variable? | 12:17 |
| GrueMaster | hrw: give me a minute and I'll pastebin a sample ofcode I wrote while at Intel. | 12:19 |
| hrw | $var = `command`; ;) | 12:22 |
| ogra_ | thats as clever as using system() :P | 12:23 |
| hrw | with system I have to play with $? etc to get result | 12:24 |
| hrw | looks like gnu-smalltalk will be fixed | 12:26 |
| hrw | not that I know perl but fix was needed in perl script | 12:26 |
| 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:28 |
| hrw | and then one more check in script | 12:29 |
| hrw | ok. passed step where it was failing | 12:30 |
| hrw | now time for debdiff | 12:31 |
| persia | hrw, Why not "use Dpkg:Arch ..."? That should save considerable cycles. | 12:31 |
| 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:32 |
| 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:33 |
| persia | Around line 196 is the bits you'll need, although you'll also need the use statement near the top. | 12:34 |
| 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:36 |
| 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:37 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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) | 12:42 |
| 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:08 |
| 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:10 |
| 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:11 |
| 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:12 |
| rsalveti | garagoth: oh, ok, guess it's the patch pointed by rcn-ee | 13:13 |
| 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:16 |
| 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:17 |
| 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:18 |
| garagoth | rsalveti: So, build it myself or will you be doing it anyway? | 13:19 |
| 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:20 |
| rsalveti | but would be good to keep an eye on it | 13:21 |
| rsalveti | garagoth: http://www.omappedia.org/wiki/Ubuntu_kernel_build_alternatives | 13:22 |
| garagoth | rsalveti: Ok, processing... | 13:24 |
| garagoth | I guess you are cross-compiling? | 13:26 |
| ppisati | rsalveti: weird | 13:27 |
| rsalveti | garagoth: yes | 13:28 |
| rsalveti | ppisati: why? same chip for both usb and eth :-) | 13:28 |
| persia | I like the FIFO queue not overflowing answer. It's more plausible than most of the other proposed "why"s. | 13:30 |
| ogra_ | well, the ignore_oc stuff seems like a red herring to me | 13:33 |
| persia | I'd say so. | 13:35 |
| persia | But that's different than the queue management. | 13:35 |
| zumbi_ | persia: can i have unity on pandaboard? | 13:41 |
| zumbi_ | (on natty I mean) | 13:41 |
| 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:42 |
| zumbi_ | persia: thanks | 13:43 |
| ogra_ | zumbi_, in th enext weeks | 13:43 |
| zumbi_ | ogra_: sure, I guess as part of oneiric | 13:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 | |
| 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:48 |
| 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:49 |
| 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:50 |
| rsalveti | but it should all be sorted out during this and next week | 13:51 |
| ogra_ | the screenshots look cool though | 13:52 |
| ogra_ | you should leave it that way and call it unidelic instead of unity :) | 13:53 |
| rsalveti | ogra_: hehe :-) | 13:54 |
| === zyga is now known as zyga-food | ||
| 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:05 |
| ogra_ | GrueMaster, soo, your ac100 ... did you actually test if the issues also show up if you manually untar the rootfs ? | 15:10 |
| 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:11 |
| ogra_ | make sure to definitely bring it to dublin | 15:12 |
| GrueMaster | I plan on it. | 15:13 |
| ogra_ | will surely be faster to find the issue if i have direct access | 15:13 |
| 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:14 |
| ogra_ | well, i want the installer to work properly on all models indeed | 15:15 |
| 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:23 |
| 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:24 |
| 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:27 |
| brendand | ah - i just needed to wait long enough | 15:28 |
| brendand | never saw that before, is it an update-regression? | 15:28 |
| 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:29 |
| === zyga-food is now known as zyga-afk | ||
| 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:34 |
| 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:35 |
| 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:36 |
| GrueMaster | ppisati: The thread continues in June as well. | 15:38 |
| ogra_ | yeah | 15:38 |
| ogra_ | differently named though | 15:38 |
| ogra_ | https://lists.yoctoproject.org/pipermail/poky/2011-June/006634.html is very intresting | 15:39 |
| ppisati | and there's a fix | 15:41 |
| ppisati | wait... | 15:41 |
| ogra_ | ppisati, https://lists.yoctoproject.org/pipermail/poky/2011-June/006646.html this one ? | 15:42 |
| 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:44 |
| ppisati | let's try... | 15:45 |
| ppisati | nope | 15:48 |
| ppisati | anyway, let me forward this info the toolchain people | 15:50 |
| ogra_ | yeah | 15:51 |
| ogra_ | a disassembly like that from our own binaries might help too i guess | 15:51 |
| 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:54 |
| ogra_ | could be | 15:59 |
| ppisati | ok, mail sent | 16:04 |
| ppisati | let me update the lp bug too | 16:04 |
| ogra_ | ++ | 16:04 |
| 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:26 |
| hrw | which ubuntu? | 16:30 |
| hrw | and do you have binutils-arm-linux-gnueabi installed? | 16:30 |
| garagoth | natty | 16:33 |
| garagoth | and yes, I have | 16:33 |
| garagoth | so...? | 16:39 |
| garagoth | rsalveti: ping | 16:46 |
| 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:47 |
| garagoth | pre-installed image which install itself | 16:48 |
| garagoth | at least should... | 16:48 |
| ogra_ | yes | 16:48 |
| 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:49 |
| 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:50 |
| GrueMaster | melis51: What platform are you using? | 16:51 |
| melis51 | Beagleboard | 16:51 |
| GrueMaster | What rev? | 16:51 |
| melis51 | c3 | 16:51 |
| GrueMaster | Odd, although you may be running out of memory. I don't remember an issue testing on my C4 though. | 16:53 |
| 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:54 | |
| 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:55 |
| 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:56 |
| 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:57 | |
| melis51 | ok I will try Maverick, but would be nice to get the latest ver to work too | 16:58 |
| 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'" | 16:59 |
| ogra_ | garagoth, well, hrw is your best option ... beyond that, file a bug against the cross toolchain | 17:00 |
| 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:01 |
| hrw | garagoth: ubuntu-bug armel-cross-toolchain-base | 17:02 |
| hrw | garagoth: add "arm-linux-gnueabi-gcc --version" into bug raport | 17:02 |
| 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:03 |
| 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:04 |
| garagoth | hrw: it says: no such package: armel-cross-toolchain-base | 17:05 |
| GrueMaster | melis51: got it working? | 17:05 |
| hrw | garagoth: so use binutils-arm-linux-gnueabi one | 17:06 |
| hrw | garagoth: armel-cross-toolchain-base is source package | 17:06 |
| melis51 | I'm not at home, so I will try it a bit later today and will let you know, thanks | 17:07 |
| 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:25 |
| 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:26 |
| hrw | ok, time to finish session for me | 17:29 |
| hrw | have a nice rest of day | 17:29 |
| garagoth | Oooh. I removed from PATH /usr/arm-linux-gnueabi/bin and it started working | 17:30 |
| hrw | ARGH YOU! :D | 17:30 |
| garagoth | Yes, I create errors. But without your hint I would never find it. | 17:31 |
| 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:32 | |
| garagoth | If I do not click 'Submit bug report' on web page, it is not visible to anyone, right? | 17:34 |
| zul | persia: heya im working on a fix for libvirt on arm fyi | 18:30 |
| 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:50 |
| 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:53 |
| 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:54 |
| 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. | 18:55 |
| zumbi | ogra_: there? | 20:00 |
| zumbi | someone know if ubuntu still needs mx51 or omap4 subarches on debian core, more specifically debian-installer | 20:01 |
| zumbi | lool: ^ | 20:01 |
| melis51 | GrueMaster: hi, I changed the setenv as you suggested, but ubuntu won't boot on my beagle | 20:18 |
| === zyga-afk is now known as zyga | ||
| garagoth | rsalveti: ping | 20:52 |
| 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:53 |
| garagoth | google claims it to be a standard interrupt api function... | 20:54 |
| garagoth | hm, it is there named set_irq_type, not irq_set_irg_type... confusing... | 20:58 |
| rcn-ee_at_work | garagoth, that got changed in 2.6.39... | 20:59 |
| 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:01 |
| garagoth | I'm sooo close to make it work, damn... | 21:02 |
| garagoth | So much trouble to have i2c bus 2 working ;-) | 21:02 |
| 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:03 |
| 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:04 |
| garagoth | back to soldering while kernel continues to compile... | 21:05 |
| 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 | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!