**** BEGIN LOGGING AT Wed Jun 15 02:59:57 2011 Jun 15 09:30:13 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 Jun 15 09:32:09 yes Jun 15 09:32:25 aholler: Distribuited buildshave not been the issue. The issue has been lack of hardware for native builds. Jun 15 09:33:09 using icecream you could use every x86 box Jun 15 09:33:26 to help you build your packages Jun 15 09:33:31 How can anx86 build arm "native" packages? Jun 15 09:33:52 read about how icecream works Jun 15 09:33:56 Not cross-compiled. Native. Jun 15 09:34:04 sure Jun 15 09:34:21 x86 does not run arm instructions w/o emulation. Jun 15 09:34:34 read about how icecream works Jun 15 09:35:43 ogra_: do you have tried it? Jun 15 09:35:54 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? Jun 15 09:36:21 btw: I have worked on distribuited build environments before. Jun 15 09:36:39 package builds are usually single threaded, that doesnt gain you much with most packages Jun 15 09:36:51 GrueMaster: you could use e.g. make -j20 and the compilation would be done by the x86-boxes Jun 15 09:37:21 but the tests would be done localy = native Jun 15 09:37:38 Listen to what I am saying. how does an x86 box compile native arm code w/o cross-compiling? Jun 15 09:37:43 * ppisati didn't read anything about "the problem to build 20,000 packages" Jun 15 09:38:17 I spent 8 years in processor validation at Intel, and now work on arm code. The instruction sets areentirely different. Jun 15 09:38:25 GrueMaster: again, read about how icecream works. Jun 15 09:38:44 nothing on your arm-box will see the difference Jun 15 09:39:00 there is cross-compiling and cross-compiling Jun 15 09:39:01 the binaries will be built with a cross toolchain ... Jun 15 09:39:08 thats the difference Jun 15 09:39:19 just the objects Jun 15 09:39:27 you cant guarantee that you get identical binaries with a cross toolchain Jun 15 09:39:28 We build all binary packages on their native hardware. We do not rely on cross-compilation. Jun 15 09:40:10 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 Jun 15 09:40:44 I know how icecream works. I have talked with some of the devs when they started building it. Jun 15 09:41:16 iirc NCommand1r used it across 4 babbages for OOo builds Jun 15 09:41:33 No, he used distcc. Jun 15 09:41:43 hmm, i thought it was icecream Jun 15 09:41:58 I love this kind of talks Jun 15 09:42:09 hrw, you could have chimed in :) Jun 15 09:42:33 'hey guys, why you are building natively? are you insane? cross compilation on farm of cheap x86 is better' etc... Jun 15 09:42:34 as compiler expert Jun 15 09:42:44 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 Jun 15 09:42:55 suihkulokki, yes Jun 15 09:43:10 SuSE OBS ... Jun 15 09:43:16 OBS dodn't due that Jun 15 09:43:36 i thought they inject an x86 compiler into a native build env Jun 15 09:44:39 you should invite the guy back if you are really intersted in how they do instead of rejecting them on sight ;) Jun 15 09:44:39 I honestly don't see how ANY distributed environment would benefit anyone that needs native hardware and doesn't have it. Jun 15 09:45:15 the distributed part only helps with packages using -jN Jun 15 09:45:20 We could easily deploy icecream (or any other distributed build environment) on our cluster, but the issue was the lack of hardware. Jun 15 09:46:13 suihkulokki: like GrueMaster said - we lack native builds and this is a problem to solve Jun 15 09:47:03 xU with 120 a9 quadcores for example - I read on linuxdevices that someone is working on such beast Jun 15 09:47:42 yep. That would be a nice addition to my rack cabinet at home. :P Jun 15 09:48:15 * ogra_ waits until he can buy that in a mac mini like case Jun 15 10:16:35 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/ Jun 15 10:16:45 ? Jun 15 10:34:19 garagoth: Have to ask rsalveti. As soon as he provides me with a binary, I'll update the tarball. Jun 15 10:40:58 ogra_: btw - how much ac100 costs in .de? Jun 15 10:47:31 GrueMaster: Ok, thanks. Jun 15 10:48:18 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) ? Jun 15 10:48:52 hrw, my last one costed me 170€ off the shelf Jun 15 10:50:02 202EUR here Jun 15 10:50:10 ppisati, http://hackaday.com/2011/06/12/how-canonical-automates-linux-package-compilation/ ... Jun 15 10:50:10 ogra_: It was cheaper because of that funky keyboard. :P Jun 15 10:50:16 "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." Jun 15 10:50:22 * ogra_ shakes his head Jun 15 10:50:44 why would cross compiling be quite time consuming Jun 15 10:51:08 on the contrary I would say... Jun 15 10:51:17 heh, yeah Jun 15 10:51:29 probably i'm reading it wrong though Jun 15 10:56:41 there is no ubuntu-arm mailing list? Jun 15 10:57:46 bug 791302 needs someone familiar with library symbols? Jun 15 10:57:48 Launchpad bug 791302 in libechonest "libechonest version 1.1.3-1 failed to build on armel" [Undecided,New] https://launchpad.net/bugs/791302 Jun 15 10:57:54 suihkulokki: no, ubuntu-mobile was dropped Jun 15 10:58:01 suihkulokki: ubuntu-devel is used Jun 15 10:59:02 I shall spam ubuntu-devel then =) Jun 15 11:02:59 ok, I'll try it again. Jun 15 11:03:09 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. Jun 15 11:03:19 And using icecream is much better than using distcc, because the building machine distributes the (cross-)compiler (as a chroot, once). Jun 15 11:03:50 what gets distributed is a tar-archive containing that stuff: http://www.fpaste.org/PyrG/ Jun 15 11:03:54 aholler: does it takes care of mix of amd64/i386/armel/armhf build machines too? Jun 15 11:04:33 yes, the build-machine gets informed about the architecture of the slaves and can send them the needed chroot Jun 15 11:04:42 I think I will have to setup icecream farm of pandas here Jun 15 11:04:43 or just don't use them Jun 15 11:05:08 that even speeds up compiling using only -j1 Jun 15 11:05:16 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 Jun 15 11:05:32 aholler: I spent 6 years on cross compilation Jun 15 11:05:35 there are some where it really helps, i agree Jun 15 11:05:39 i.e. libO Jun 15 11:05:42 hrw: fine for you Jun 15 11:06:29 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 Jun 15 11:07:28 most packages could be build using -jN, at least when ext4 is used. Jun 15 11:07:50 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" Jun 15 11:07:51 with ext3 there are more problems, because of the limited timestamp Jun 15 11:08:42 a single source is still compiled a lot faster on x86 (+network transfer) than on an arm Jun 15 11:09:06 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 Jun 15 11:10:01 we definitely wouldnt use it with a cross compiler Jun 15 11:10:23 Actually, if icecream can manage client build systems appearing on the fly, it could easily be deployed now on our panda cluster. Jun 15 11:10:28 but the concept could indeed help with native compilers too ... Jun 15 11:10:30 do you expect a different output from a cross-assembler than native? Jun 15 11:10:48 the possibility exists Jun 15 11:10:52 aholler: Yes, and we have actual documented bugs with that. Jun 15 11:11:22 don't mix that concept icecream/distcc uses which the stuff people usually are understanding with cross-compiling Jun 15 11:11:46 s/which/with/ Jun 15 11:12:57 anyway, it is just a suggestion, I don't need to convince the people here. Jun 15 11:13:20 well, i like the concept of distributed building ... Jun 15 11:13:41 ditributed cross- is even better Jun 15 11:13:55 thats something i would not agree on :) Jun 15 11:14:50 * ppisati -> out to get some food Jun 15 11:14:54 I've used that a lot to build x32packages on x64-machines (and vice-versa) several years before Jun 15 11:15:25 no, wrong, the other machines helped building the packes, they haven't build them Jun 15 11:15:57 anyway, maybe one of you might try it. I'm off again. ;) Jun 15 11:16:15 we use x86_64 machines to build i386 packages all the time. That isnt an issue. Jun 15 11:16:37 he's gone Jun 15 11:19:12 hm. how to call shell in perl and get return as value of variable? Jun 15 11:20:35 hrw: give me a minute and I'll pastebin a sample ofcode I wrote while at Intel. Jun 15 11:24:03 $var = `command`; ;) Jun 15 11:24:24 thats as clever as using system() :P Jun 15 11:26:13 with system I have to play with $? etc to get result Jun 15 11:27:46 looks like gnu-smalltalk will be fixed Jun 15 11:28:03 not that I know perl but fix was needed in perl script Jun 15 11:29:18 hrw: Looks like you have it. Jun 15 11:30:02 my $multiarch_dir = `dpkg-architecture -qDEB_HOST_MULTIARCH`; Jun 15 11:30:05 chomp($multiarch_dir); Jun 15 11:30:18 and then one more check in script Jun 15 11:31:26 ok. passed step where it was failing Jun 15 11:33:00 now time for debdiff Jun 15 11:33:07 hrw, Why not "use Dpkg:Arch ..."? That should save considerable cycles. Jun 15 11:33:44 (if you just care about multiarch, then "use Dpkg:Arch qw(debarch_to_multiarch);" is probably sufficient) Jun 15 11:33:58 persia: because I do not know perl? Jun 15 11:34:20 persia: so I am trying to get some hack which works and then it can get improved Jun 15 11:34:22 hrw, Heh. So, take a look at the dpkg-architecture source. Jun 15 11:34:33 It's fairly trivial to just pull the value from the libary (and we have a nice code example) Jun 15 11:34:41 thx Jun 15 11:35:16 Around line 196 is the bits you'll need, although you'll also need the use statement near the top. Jun 15 11:37:16 my $multiarch_dir = debarch_to_multiarch(get_raw_host_arch()); Jun 15 11:37:36 That looks cleaner to me. Does it work? Jun 15 11:37:55 Also, how is get_raw_host_arch() implemented? Is this something you could also pull from the library? Jun 15 11:38:05 both are from Dpkg::Arch Jun 15 11:38:19 I picked code from dpkg-architecture Jun 15 11:38:19 Ah, heh. That sounds ideal then, if it works :) Jun 15 11:38:32 persia: build in process Jun 15 11:38:32 Just be sure to specify both in the use statement, so they are available. Jun 15 11:38:40 did Jun 15 11:38:46 Perfect :) Jun 15 11:38:54 persia: thanks for tips Jun 15 11:39:08 No problem. Thanks for asking for help on the channel *before* you found the final solution. Jun 15 11:40:24 persia: as I'm not perl programmer I prefer to make sure that my thinking is right. Jun 15 11:40:54 persia: and my workflow for bugs is: make a fix and then make a fix to be a proper fix Jun 15 11:42:06 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). Jun 15 11:42:43 persia: first ver of fix was good but implementation was bad ;D Jun 15 11:43:05 Not bad, just didn't take advantage of the fact that dpkg-architecture was itself implemented in perl, with a handy library. Jun 15 11:43:23 Was dpkg-architecture in C, then I think your implementation would have been the least bad. Jun 15 11:43:38 (assuming nobody had created perl bindings for the library) Jun 15 12:09:29 ppisati: ogra_: GrueMaster: http://comments.gmane.org/gmane.linux.redhat.fedora.arm/1266 Jun 15 12:09:52 pointed by agreen, if we want to have a better buildd this would be something to look for Jun 15 12:12:15 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) ? Jun 15 12:12:29 garagoth: sure, sorry, just got on-line Jun 15 12:12:37 garagoth: what exactly do you need? Jun 15 12:13:11 I have trainer board from tin can tools attached to beagle xm C and I need to use i2c which is there. Jun 15 12:13:22 It is nice as it is level translated to 5V Jun 15 12:13:32 it is i2c bus 2 Jun 15 12:13:43 but on your kenel only buses 1 and 3 are visible Jun 15 12:15:16 garagoth: oh, ok, guess it's the patch pointed by rcn-ee Jun 15 12:17:20 I hope so :-) I had no sources of your kernel, so could not test it myself. Jun 15 12:17:42 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. Jun 15 12:18:16 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 Jun 15 12:18:25 10.44 Jun 15 12:20:03 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 Jun 15 12:20:12 didn't check if you need any other dependencies Jun 15 12:20:59 rsalveti: So, build it myself or will you be doing it anyway? Jun 15 12:21:23 garagoth: I can guide you if you want, then you can hack it later if needed ;-) Jun 15 12:21:31 rsalveti, what exactly do you suggest ? rinning a ping daemon ? Jun 15 12:21:35 *running Jun 15 12:22:03 ogra_: well, agreen is investigating the kernel to see if we can get a fix Jun 15 12:22:04 Would be nice. I need to setup cross-compile env for ubuntu then... somehow :-) Or compile on Beagle Jun 15 12:22:41 but would be good to keep an eye on it Jun 15 12:23:33 garagoth: http://www.omappedia.org/wiki/Ubuntu_kernel_build_alternatives Jun 15 12:26:13 rsalveti: Ok, processing... Jun 15 12:28:07 I guess you are cross-compiling? Jun 15 12:28:54 rsalveti: weird Jun 15 12:29:39 garagoth: yes Jun 15 12:29:53 ppisati: why? same chip for both usb and eth :-) Jun 15 12:31:37 I like the FIFO queue not overflowing answer. It's more plausible than most of the other proposed "why"s. Jun 15 12:34:29 well, the ignore_oc stuff seems like a red herring to me Jun 15 12:36:45 I'd say so. Jun 15 12:36:55 But that's different than the queue management. Jun 15 12:42:50 persia: can i have unity on pandaboard? Jun 15 12:43:08 (on natty I mean) Jun 15 12:43:32 zumbi_, You can have unity-2d. I don't believe everything was ported to work properly with the GLES drivers TI provided. Jun 15 12:43:48 (someone please correct me if I'm wrong). Jun 15 12:44:13 so unity-3d not yet ready on arm hw :/ Jun 15 12:44:35 persia: thanks Jun 15 12:44:56 zumbi_, in th enext weeks Jun 15 12:45:12 ogra_: sure, I guess as part of oneiric Jun 15 12:45:23 there are two bugs left afaik ... once these are solved it should be available for natty Jun 15 12:45:30 later then oneiric Jun 15 12:46:00 (all work is done on the natty branches atm and will need forward porting then) Jun 15 12:46:28 ogra_, This is GLES porting? Jun 15 12:46:33 yes Jun 15 12:46:39 uhm.. ok, sounds fine, I'll try it on few weeks then Jun 15 12:46:41 for compiz, nux and unity Jun 15 12:46:57 zumbi_, rsalveti should be able to point you to a PPA for that Jun 15 12:47:10 zumbi_, What's your specific interest? The interface, or reviewing the code paths? Jun 15 12:47:24 (beyond that they should show up in the natty release PPA for panda) Jun 15 12:47:28 If the former, then unity-2d is supposed to be mostly the same (although some things are different) Jun 15 12:47:53 If the latter, I'm sure folk would appreciate additional testing/help with the remaining few bugs. Jun 15 12:47:58 zumbi_: https://launchpad.net/~rsalveti/+archive/unity-3d-gles Jun 15 12:48:00 ogra_, Do you happen to know the bug numbers? Jun 15 12:48:09 zumbi_: not fully working yet Jun 15 12:48:09 persia: right now, my interest is have a technology preview, we are currently using Qt for UI design Jun 15 12:48:18 rsalveti: thanks Jun 15 12:48:24 but you should be able to try it in the following days Jun 15 12:48:36 persia, for what ? Jun 15 12:48:37 zumbi_, unity-2d is implemented in Qt, so yeah, that doesn't necessarily show anything particularly different. Jun 15 12:48:48 ogra_, The compiz/nux/unity bugs. Jun 15 12:48:55 i dont think there are bugs Jun 15 12:49:11 * persia grumbles Jun 15 12:49:26 When "there are two bugs left", those should be filed in launchpad, and discussion happen there. Jun 15 12:49:31 there is a team working fulltime on fixing them though :) Jun 15 12:49:40 And the team doesn't want another member, for some reason? Jun 15 12:49:43 and they report to places i am Jun 15 12:49:53 ask linaro :) Jun 15 12:50:10 i guess they wont deny if someone wants to help indeed Jun 15 12:50:19 rsalveti, Are there bugs? What sort of help could speed the process? Jun 15 12:50:43 persia: https://bugs.launchpad.net/unity-gles Jun 15 12:51:02 Only one left! Jun 15 12:51:09 zumbi_, ^^ Jun 15 12:51:19 i thought there was one nux bug too Jun 15 12:51:30 but seems that got fixed already Jun 15 12:51:57 * jussi prods at persia Jun 15 12:51:59 we just discussed at the call and we may have an additional bug for nux Jun 15 12:52:05 but still not confirmed Jun 15 12:52:23 but it should all be sorted out during this and next week Jun 15 12:53:55 the screenshots look cool though Jun 15 12:54:19 you should leave it that way and call it unidelic instead of unity :) Jun 15 12:55:50 ogra_: hehe :-) Jun 15 14:06:34 and another porting jam just starting at #linaro! come and help us making ubuntu better on arm :-) Jun 15 14:07:02 https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue&orderby=-id Jun 15 14:11:49 GrueMaster, soo, your ac100 ... did you actually test if the issues also show up if you manually untar the rootfs ? Jun 15 14:12:32 I have put it back on the back burner. Need to be productive on current tasks. Jun 15 14:12:49 k Jun 15 14:13:05 well, i cant do much until we have identified the actual problem Jun 15 14:14:06 make sure to definitely bring it to dublin Jun 15 14:14:18 I plan on it. Jun 15 14:14:29 will surely be faster to find the issue if i have direct access Jun 15 14:16:00 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. Jun 15 14:16:30 well, i want the installer to work properly on all models indeed Jun 15 14:25:13 seems we are not the only one experiencing issue with usb and gcc 4.6: Jun 15 14:25:15 https://lists.yoctoproject.org/pipermail/poky/2011-April/005703.html Jun 15 14:25:22 the thread continues in may 2011 too Jun 15 14:26:09 https://lists.yoctoproject.org/pipermail/poky/2011-May/005763.html Jun 15 14:26:09 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? Jun 15 14:28:32 fully updated 11.04 running on a pandaboard, when i try to boot it i get things like Jun 15 14:28:43 (stk) : line disc installation timed out Jun 15 14:29:01 (stc) : KIM failure complete callback Jun 15 14:29:04 that is the bluetooth driver. known issue. Jun 15 14:29:29 ah - i just needed to wait long enough Jun 15 14:29:48 never saw that before, is it an update-regression? Jun 15 14:30:26 and it seems there's a fix... testing... Jun 15 14:30:50 Yes and no. It didn't happen in maverick as the driver was rewritten and hasn't been finalized at time of release. Jun 15 14:35:37 what is a proper way to request arm rebuild of package? Jun 15 14:36:10 octave-communications 1.0.10-3 was ftbfs on armel 7 weeks ago due to lack of build deps. now they are fulfilled Jun 15 14:36:17 one sec Jun 15 14:36:30 I am building this package on panda now Jun 15 14:37:03 it was bug 791314 btw Jun 15 14:37:04 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 Jun 15 14:37:29 rebuild triggered Jun 15 14:37:35 thx Jun 15 14:37:36 https://launchpad.net/ubuntu/+source/octave-communications/1.0.10-3/+build/2469824 Jun 15 14:38:03 I just loaded that Jun 15 14:39:17 ppisati: The thread continues in June as well. Jun 15 14:39:45 yeah Jun 15 14:39:50 differently named though Jun 15 14:40:19 https://lists.yoctoproject.org/pipermail/poky/2011-June/006634.html is very intresting Jun 15 14:43:07 and there's a fix Jun 15 14:43:11 wait... Jun 15 14:44:11 ppisati, https://lists.yoctoproject.org/pipermail/poky/2011-June/006646.html this one ? Jun 15 14:45:41 yep Jun 15 14:45:49 but it seems it's not working :( Jun 15 14:46:00 well, they later say you should just remove the line completely Jun 15 14:46:36 let's try... Jun 15 14:49:54 nope Jun 15 14:51:55 anyway, let me forward this info the toolchain people Jun 15 14:52:32 yeah Jun 15 14:52:50 a disassembly like that from our own binaries might help too i guess Jun 15 14:55:24 yep Jun 15 14:55:53 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 Jun 15 15:00:35 could be Jun 15 15:05:39 ok, mail sent Jun 15 15:05:59 let me update the lp bug too Jun 15 15:06:09 ++ Jun 15 15:27:56 I'm trying to compile ubuntu kernel for Beagle, but process fails with error: "as: unrecognized option '-Qy'" Jun 15 15:28:01 Any hints? Jun 15 15:31:47 which ubuntu? Jun 15 15:32:00 and do you have binutils-arm-linux-gnueabi installed? Jun 15 15:34:32 natty Jun 15 15:34:50 and yes, I have Jun 15 15:40:45 so...? Jun 15 15:47:40 rsalveti: ping Jun 15 15:48:31 hi, anyone knows the uname+pwd for ubuntu-11.04-preinstalled-netbook-armel+omap.img.gz, thx Jun 15 15:48:48 there is none Jun 15 15:48:58 you set it up during the first boot Jun 15 15:49:04 during install you setup your user Jun 15 15:49:14 this is a pre-installed image Jun 15 15:49:32 pre-installed image which install itself Jun 15 15:49:47 at least should... Jun 15 15:49:52 yes Jun 15 15:50:22 you boot it, it should show you installer Jun 15 15:50:39 you select lang, keyboard, packages, user Jun 15 15:50:48 the first thing I see is a log-in screen Jun 15 15:51:18 the only option is to click 'other' user Jun 15 15:51:20 on dvi port? Jun 15 15:51:24 yes Jun 15 15:51:38 is it ubuntu branded? Jun 15 15:52:13 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 Jun 15 15:52:23 melis51: What platform are you using? Jun 15 15:52:37 Beagleboard Jun 15 15:53:02 What rev? Jun 15 15:53:06 c3 Jun 15 15:55:06 Odd, although you may be running out of memory. I don't remember an issue testing on my C4 though. Jun 15 15:55:47 on bb-xM rev C I saw setup screen on X Jun 15 15:55:52 try the headless image instaed and then install ubuntu-netbook using tasksel Jun 15 15:55:53 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. Jun 15 15:56:09 oh, right, NAND ! Jun 15 15:56:14 * ogra_ totally forgot Jun 15 15:56:35 ogra_: That's why you keep me around. :P Jun 15 15:56:37 indeed, it might not pull the right initrd in Jun 15 15:56:58 GrueMaster, yeah, we all love you :) Jun 15 15:57:09 I can't tell right now, but will check Jun 15 15:57:38 Do the ARM PPAs build naively? Jun 15 15:57:40 melis51, there are instructions on the wiki how to make sure to boot right Jun 15 15:57:52 lag, yes, thats why they arent public Jun 15 15:58:11 ogra_: All of them? Even my own PPA? Jun 15 15:58:32 only trusted people have upload permission Jun 15 15:58:36 melis51: Check the Maverick instructions. They have more detail on the beagleboard w/ nand. Jun 15 15:58:40 indeed you can make the binaries public Jun 15 15:58:42 ora_ I fallowed GrueMaster's instructions on the wiki that worked up until the log-in screen Jun 15 15:58:52 ogra_: Let me try to explain Jun 15 15:59:02 * GrueMaster updates the instructions for natty. Jun 15 15:59:58 ok I will try Maverick, but would be nice to get the latest ver to work too Jun 15 16:00:27 you dont need to try maverick Jun 15 16:00:42 only the maverick instructions for booting begales with NAND on them Jun 15 16:00:50 ok Jun 15 16:01:06 Maybe someone can help me with cross-compiling to beagle on natty? I have "as: unrecognized option '-Qy'" Jun 15 16:01:34 garagoth, well, hrw is your best option ... beyond that, file a bug against the cross toolchain Jun 15 16:02:18 melis51: You can use natty, just follow the maverick instructions specific to the beagleboard rev C. Jun 15 16:02:42 Natty Instructions updated to include these now. Jun 15 16:02:45 garagoth: fill a bug with exact info what you are doing ok? Jun 15 16:02:52 ok thanks I'll try Jun 15 16:03:16 hrw: ubuntu-bug or ..? Jun 15 16:03:28 garagoth: ubuntu-bug armel-cross-toolchain-base Jun 15 16:04:01 garagoth: add "arm-linux-gnueabi-gcc --version" into bug raport Jun 15 16:04:44 Ok. Jun 15 16:05:08 ogra_: http://ppa.launchpad.net/linaro-landing-team-ste/st-ericsson-u8500-public/ubuntu/pool/main/l/linux-u8500/ Jun 15 16:05:25 Would that have been build natively Jun 15 16:05:32 lag, yes Jun 15 16:05:43 ogra_: Great, thanks! Jun 15 16:05:47 we dont so any non native builds in the datacenter Jun 15 16:05:54 thanks everyone for your help! Jun 15 16:05:54 s/so/do/ Jun 15 16:06:32 hrw: it says: no such package: armel-cross-toolchain-base Jun 15 16:06:40 melis51: got it working? Jun 15 16:07:40 garagoth: so use binutils-arm-linux-gnueabi one Jun 15 16:07:49 garagoth: armel-cross-toolchain-base is source package Jun 15 16:09:09 I'm not at home, so I will try it a bit later today and will let you know, thanks Jun 15 16:26:36 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 Jun 15 16:27:26 and there is no symlink or anything to arm-linux-gnueabi-gcc Jun 15 16:27:47 garagoth: apt-get install gcc-arm-linux-gnueabi then Jun 15 16:30:56 ok, time to finish session for me Jun 15 16:31:01 have a nice rest of day Jun 15 16:31:37 Oooh. I removed from PATH /usr/arm-linux-gnueabi/bin and it started working Jun 15 16:32:08 ARGH YOU! :D Jun 15 16:32:55 Yes, I create errors. But without your hint I would never find it. Jun 15 16:33:19 I was missing one package Jun 15 16:33:56 So, thanks a lot and have a nice day as well :-) Jun 15 16:34:11 * garagoth crossess fingers to make it compile. Jun 15 16:35:28 If I do not click 'Submit bug report' on web page, it is not visible to anyone, right? Jun 15 17:32:06 persia: heya im working on a fix for libvirt on arm fyi Jun 15 17:51:51 excuse the FAQs, but is there an LTS release for ARM yet and will there be an armv7 Ubuntu release? Jun 15 17:52:13 my googling is returning misleading info. Jun 15 17:54:55 jkridner: 12.04 will be thefirst LTS release for arm. Armv7 has been supported since 10.04 Jun 15 17:55:12 (but 10.04 was not LTS for arm). Jun 15 17:55:15 thanks! Jun 15 17:55:38 I think 10.04 was armel, compatible with armv7, but not optimized for armv7. Jun 15 17:56:17 It was the first armv7 release. Jun 15 17:56:22 Our armel port has been armv7 for a while. Jun 15 17:56:34 Don't confuse the dpkg arch name with the compiler target. Jun 15 17:57:08 (Much like our i386 port won't actually run on 80386 machines) Jun 15 17:57:17 True, not all packages were built with full armv7 optimizations, but main was. Jun 15 19:01:52 ogra_: there? Jun 15 19:02:27 someone know if ubuntu still needs mx51 or omap4 subarches on debian core, more specifically debian-installer Jun 15 19:02:34 lool: ^ Jun 15 19:20:01 GrueMaster: hi, I changed the setenv as you suggested, but ubuntu won't boot on my beagle Jun 15 19:53:23 rsalveti: ping Jun 15 19:54:44 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 Jun 15 19:56:07 google claims it to be a standard interrupt api function... Jun 15 19:59:21 hm, it is there named set_irq_type, not irq_set_irg_type... confusing... Jun 15 20:00:31 garagoth, that got changed in 2.6.39... Jun 15 20:02:39 garagoth, 2.6.38 and earlier used "set_irq_type", 2.6.39+ uses "irq_set_irq_type" Jun 15 20:02:58 damn. One small revision number... Jun 15 20:03:40 I'm sooo close to make it work, damn... Jun 15 20:03:54 So much trouble to have i2c bus 2 working ;-) Jun 15 20:05:07 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.. Jun 15 20:05:18 yes Jun 15 20:05:20 I have Jun 15 20:05:36 well, the big patch set's everything up for the trainer.. (and more..) Jun 15 20:05:51 and I found usage for gpio, so I need more then i2c, so patching... Jun 15 20:07:17 back to soldering while kernel continues to compile... Jun 15 23:00:40 zumbi, Support for mx5 and omap4 continues to be useful :) Jun 15 23:01:11 persia: thanks, you mean mx51?, I realized that reading omappedia.org Jun 15 23:01:36 persia: someone wanted to do some omap4 cleanup on d-i Jun 15 23:02:12 I think I mean "mx5". I've heard folk say that the same code supports the i.MX51 and the i.MX53, and that someone was calling that mx5 while adding support in Debian. Jun 15 23:02:18 debian is likely enabling omap subarch Jun 15 23:02:40 persia: yes, that someone was me Jun 15 23:02:47 Will Debian "omap" support omap3 and omap4? Jun 15 23:03:08 mx51 and mx53 are not yet compatible Jun 15 23:03:12 Heh. Then you know what string I need more than I :) Jun 15 23:03:25 yes, omap in debian will be for omap3 and omap4 Jun 15 23:03:33 They aren't? I thought linaro had a kernel that worked on both. Jun 15 23:03:50 persia: is not about what I need, I am trying not to break your stuff Jun 15 23:03:59 If "omap" in Debian is for both omap3 and omap4, then it makes sense for Ubuntu to carry "omap4" is a patch, for as long as it continues to be required. Jun 15 23:04:14 as someone submitted a patch which removed omap4 from libdebian-installer Jun 15 23:04:53 As long as we know about it, it oughtn't be a disaster. Jun 15 23:05:02 persia: ok - but there are old trees with omap4 and documentation all over teh place Jun 15 23:05:43 NCommander, Are you about? Would you have time to review this with zumbi to figure out what makes sense as an Ubuntu patch? Jun 15 23:06:15 persia: this was the thread triggering this question.. http://lists.debian.org/debian-boot/2011/06/msg00184.html Jun 15 23:07:20 Ah, and now it all makes sense. Jun 15 23:07:53 Yeah, it's probably better to leave "omap4" and "imx51" in the reserved list for now, as this makes the Ubuntu patching easier (reassinging some boards,etc.). Jun 15 23:08:35 yes, that was what I thought Jun 15 23:09:00 we'll see how we end up with mx51 and mx53 Jun 15 23:11:14 What's outstanding there? A merged kernel, or something larger? Jun 15 23:12:50 persia: is it just an offset issue Jun 15 23:12:57 at boot time Jun 15 23:14:37 Hrm. That confuses me. I've been told that folks with both Efika smartbooks (mx51) and Quickstarts (mx53) are booting with the linaro kernel. Jun 15 23:14:42 I thought that was the same kernel. Jun 15 23:15:58 http://lists.debian.org/debian-arm/2011/04/msg00067.html Jun 15 23:16:09 apachelogger, What's your `uname -a` output? Jun 15 23:16:24 persia: well, maybe it has been fixed Jun 15 23:16:49 that issue was raised back in april Jun 15 23:17:00 I have not tested mx53 stuff yet Jun 15 23:17:22 Uwe also seems to be talking about mainline, and I suspect Linaro's Freescale Landing Team has a number of patches in the pipeline. Jun 15 23:20:14 persia: yes, Uwe is mainline.. but certainly if that is in Linaro eventually it'll get into mainline Jun 15 23:20:32 Sometimes the patches need a fair bit of rewriting :) Jun 15 23:20:42 if it is not there yet... I need to update myself Jun 15 23:20:49 (but yeah, it's heaps better than the old abandoned vendor trees) Jun 15 23:21:19 well, there is not much involved into have mx53 and mx51 in one kernel Jun 15 23:21:33 we really hoping for unified kernel Jun 15 23:23:08 I think there is one. Unfortunately, jcrigby, who'd know for sure, seems to be away from IRC this week. Jun 15 23:24:13 Unfortunately, my git-fu isn't up to finding shortlog difference between trees sufficiently to distinguish which patches may have been applied to achieve this. Jun 15 23:27:58 well, that's upstream call I suspect Jun 15 23:30:09 Heh, well. Depends on your feeling towards distro-patches :) I suspect that for Ubuntu we'll be telling base-installer to use the linaro kernels (since they regularly get uploaded into the archive). I'm not convinced Debian wants N kernel source packages, which makes it much harder to do without upstream support. Jun 15 23:36:33 persia: debian kernel team sticks to upstream/mainline Jun 15 23:36:40 Sensibly :) Jun 15 23:37:02 and they have a policy of only backporting patches which have been accepted into mainline HEAD Jun 15 23:37:05 Ubuntu kernel team does the same (mostly), but there are something like 6 kernel source packages in Ubuntu, of which only one is managed by that team. Jun 15 23:37:09 unless it is a bugfix Jun 15 23:37:49 For Ubuntu, even bugfixes get asked if they are upstream (although I suspect some that aren't yet get applied) Jun 15 23:37:56 well, it becomes insane if you do it other way, you need an upstream to distribute Jun 15 23:38:09 Debian distributes GNU Jun 15 23:38:17 free and open stuff Jun 15 23:38:50 Ubuntu is more into commercial world, I want it to work even if it is not open/free Jun 15 23:40:29 I mean Ubuntu besides being driven by business, it also does not comply to Debian free and open source guidelines... Jun 15 23:40:36 It's not about free/non-free and it's not about money. Jun 15 23:40:39 in a sense Debian is freedom taliban Jun 15 23:41:12 persia: I was not trying to be annoying that was just my point of view Jun 15 23:41:13 All the extra kernels in the archive are GPLv2-only, and some of them are uploaded by people I know not to be receiving any compensation for doing so. Jun 15 23:41:49 I agree that having a single upstream is *lots* easier to manage, and generally cleaner. Jun 15 23:42:23 well, you really do not want to carry 6 different kernels for x86 Jun 15 23:42:32 then dealing with bug reports is insane Jun 15 23:42:52 They have 6 different source packages. Jun 15 23:43:02 (but I think we only have 2 source packages for x86) Jun 15 23:43:18 And different binary package names Jun 15 23:43:20 when talking about free/non-free, I was thinking on ti-sgx 3D drivers, nvidia stuff, etc... Jun 15 23:43:39 I don't believe any of that is in Ubuntu. Jun 15 23:43:45 and surely there is community around Ubuntu Jun 15 23:43:47 TI has a PPA in which they distribute some stuff. Jun 15 23:43:56 I don't think nVidia has one. Jun 15 23:44:57 uhm.. I might be wrong Jun 15 23:46:19 persia: but then why fork Debian and not work with it? Jun 15 23:46:31 I wasn't involved in that decision. Jun 15 23:47:03 At the time, I was following Debian mailing lists, and had the impression that there was a desire to do ~1000 NMUs, which were considered to be unfreindly at the time. Jun 15 23:48:24 I believe the fork comes from the desire to be able to upload things *without* considering whether it's NMU, and the desire to release every six months (Ubuntu was announced around the time that sarge was looking like it would never release) Jun 15 23:49:10 I think many Ubuntu Developers, especially most of those who have been around a while, do also work in Debian in one way or another. Jun 15 23:49:20 I'm not sure it's fair to say "and not work with it" Jun 15 23:49:25 persia: yes, that's for sure Jun 15 23:50:12 persia: well in a way we use debian tweaked for our needs at work Jun 15 23:50:22 Now, since 2005 NMUs in Debian have transitioned from being an injury to being a help to other maintainres, there's lots more team maintainership, the DAM lock that nobody understood is gone, etc. Jun 15 23:50:28 we got some extra packages in internal repo Jun 15 23:50:50 So lots of the initial rationales for Ubuntu would probably be considered differently if considered today. Jun 15 23:51:28 But at this point, deciding to not have Ubuntu gets messy and complicated: too many people have too much invested in continued existence. Jun 15 23:53:13 As some of the first changes in Ubuntu were toolchain patches, which required rebuilding all the rdepends, I don't think "extra packages in a third-party repo" would ever have worked. Jun 15 23:54:13 Ubuntu continues to be a testing ground for new toolchains in Debian, which I think benefits Debian in terms of patches available for FTBFS at least as much as it benefits Ubuntu in terms of tighter optimisations. Jun 15 23:55:05 persia: I agree Jun 15 23:55:17 surely one is testbed of the other Jun 15 23:55:17 Mind you, there's been *lots* of argument about this, from lots of directions in the past. There have been some periods where cooperation was weak. Jun 15 23:55:46 yes, lots of flames Jun 15 23:55:58 some of the toolchain diffs (hardening defaults) were brought up at UDS in the Debian health check session Jun 15 23:56:17 But I very much hope that more teams follow the example of the Mono/CLI team, where a common set of folk have upload rights to both distributions, tend to do most of their stuff in Debian (except where variation is required to comply with other variation), and everyone stays (mostly) happy. Jun 15 23:56:50 persia: some DD are annoyed to not be able to upload to ubuntu Jun 15 23:57:01 and find some packages are not in sync Jun 15 23:57:16 zumbi, Sure, but some DD *can* upload to Ubuntu. There's more than a few that have requested (and been granted) upload rights for the stuff they maintain. Jun 15 23:57:26 DEX is great opportunity to improve cooperation Jun 15 23:58:02 persia: I did not know about that.. in any case I am not against any Jun 15 23:58:10 Those DDs who are annoyed to not be able to upload should demonstrate they are watching LP bugs, and apply to get upload. Jun 15 23:58:49 On the other hand, some DD complain and say that Ubuntu should sync their latest upload all the time: in several cases this has broken chunks of the archive that go beyond that specific package late in the release cycle. Jun 15 23:59:06 This is especially common when Debian is just coming out of freeze while Ubuntu is entering freeze. Jun 15 23:59:40 And some DDs don't bother to test whether their new uploads even build under Ubuntu (but still insist on sync) Jun 16 00:00:16 yes, slightly similar, but not same Jun 16 00:00:31 Luckily, those are the extreme minority, but it's fear of that sort that leads to the process of requiring folk to apply and demonstrate they do care about Ubuntu (which has been described as overly bureaucratic by some) Jun 16 00:00:32 I think there is material to write a book Jun 16 00:00:38 Several :) Jun 16 00:04:51 well, I think the base system is well built but either debian and ubuntu developers Jun 16 00:04:51 I have lots of friends that are working or have worked for canonical Jun 16 00:08:10 There's lots of Ubuntu Developers that don't work for Canonical as well (although, to be honest, we've not been as good at recuiting new developers lately, and Canonical has hired a lot of folk, so I'm not sure whether Canonical employs a majority currently) Jun 16 00:10:21 It is quite amazing how all that is structured Jun 16 00:10:30 it is hard to understand properly :) Jun 16 00:11:04 I am not sure I got contributions to ubuntu, but at least if I fix something in debian I ping the packages in ubuntu, so they can check Jun 16 00:11:31 and I have even signed the ubuntu code of conduct Jun 16 00:12:12 What's your LP account? Jun 16 00:12:19 but not sure how can i help ubuntu, I try to keep debian alive at least on embedded arches which have been in my interest since the beginning Jun 16 00:12:36 persia: my nickname Jun 16 00:13:28 You've not been granted specific credit for any patches in Ubuntu (although I know you've been helping folk for a long time). Jun 16 00:13:48 I do not maintain much packages in debian, but fixed tslib driver for X.org in debian and pinged the bugreport in ubuntu Jun 16 00:14:27 well, not helping, really is cooperation Jun 16 00:14:46 Sure: I tend to think of cooperation as "folk helping each other" :) Jun 16 00:15:39 If your patches are getting applied in Debian smoothly, and flowing to Ubuntu well enough that you're comfortable, I'd say you have nothing to worry about. Jun 16 00:16:36 If you want to deploy patches that aren't being accepted, or there are issues with getting stuff into Ubuntu that you want to fix, then it may make sense to prepare debdiffs for bugfixes and send them to Ubuntu bugs for application. Jun 16 00:17:28 But it all depends on your personal motivations, and whether you have any desire to identify as an "Ubuntu Developer". Jun 16 00:17:28 I see Jun 16 00:18:08 well, I don't care.. I would like to close LP#1 :) Jun 16 00:18:47 I think that was that one bug Mark wrote time ago Jun 16 00:19:19 That's getting very close to closed, unfortunately not from our work (iOS, Android) Jun 16 00:20:07 sadly, yes Jun 16 00:20:53 but still .. they are around Jun 16 00:21:09 Oh, indeed. And lots of the Android work ends up being directly useful to us. Jun 16 00:21:10 later moves with Nokia were not good Jun 16 00:21:36 I am still waiting for the ubuntu-phone Jun 16 00:21:38 I keep hearing good things from Nokia, although for stuff that isn't phones. I'm not yet ready to have an opinion. Jun 16 00:22:04 I believe Kubuntu Mobile has a working dialer and some baseband support. Jun 16 00:22:45 persia: no, you need to ship actual devices, not expect people to fit that into a mobile Jun 16 00:22:59 pre-installed ubuntu phones Jun 16 00:23:21 Yeah, well. All we can do is build it, and hope they come. Jun 16 00:23:57 well, you need to contact manufacturers Jun 16 00:23:57 Sure, some of us, as individuals, can go talk to ODMs, etc., but at that point I'm not sure that it's still part of the wider "we". Jun 16 00:24:22 I'm not convinced that it's yet possible to deliver a product with turnkey free software. Jun 16 00:24:42 HTC has recently open the bootloader Jun 16 00:24:53 to make their devices more hackable Jun 16 00:25:08 If we can reach that point, where it just works, and can usefully be installed on nearly any phone, then it becomes a relatively safe option for someone to release a phone based on that stack (rather than requiring in-house development effort) Jun 16 00:25:11 not open as in source, but open as in access Jun 16 00:26:02 Given the number of tablets and handhelds released with Ubuntu Jaunty when the ARM port first became available, I would expect several devices to appear shortly after it was known to work. Jun 16 00:26:12 we build a lightwriter for disabled people, not only helps them to speak up but it also works as a phone Jun 16 00:26:40 (mind you, most of this was not available outside the Chinese market, but that's the hot location for early adoption in consumer electronics: everywhere else folk are very conservative) Jun 16 00:28:03 yes, the Chinese just go for it.. Jun 16 00:28:17 I know Anthony Fok and Paul Liu Jun 16 00:28:23 great developers Jun 16 00:28:34 Right. There's lots of cool stuff to do. I believe that we (being developers) need to focus on making sure that our software stack works, is easily adapted to a wide variety of hardware, and is widely available at no cost (free code is something we care about. free beer is something the manufacturers care about) Jun 16 00:29:30 Whereas we (being the free software community) need to encourage or develop entrepreneurs who will take these things to retail devices. Jun 16 00:30:50 Yes, I have thought many times to develop some hardware and use free software to develop retail devices Jun 16 00:30:56 but all of it is complex Jun 16 00:31:17 It's no more complex than software :) It's just different. There are very few folk who can do both. Jun 16 00:31:56 getting parts sorted Jun 16 00:32:00 MOQs Jun 16 00:32:34 Oh yeah. Jun 16 00:32:47 Anyway, getting late in the morning for me, and I must run. Have a good evening. Jun 16 00:32:52 hardware is .. don't know how to describe.. hardware to be ready for production is just tough Jun 16 00:33:09 persia: sure.. bye Jun 16 00:34:18 persia: just one more thing, linux is the testbed of new processors which tomorrow (years away) will be part of products, besides mobile world which it changes so fast Jun 16 00:34:34 I wish it was that simple. Jun 16 00:35:16 Lots of the things that get tested (much of which goes mainline) ends up being PoC to drive design wins, which end up with derivations for production deployment. Jun 16 00:36:09 Even with many of the SoC vendors collaborating within Linaro to help make BSPs be mostly upstream(able) code, I suspect there remain cultural barriers to having vendor devices mainline enabled. Jun 16 00:36:22 (with the exception of a few bright spots, where vendors are very cooperative) Jun 16 00:37:20 In many ways, I welcome Windows 8 to the game: it helps the conversations about having hardware be a base platform on which arbitrary software is delivered. Jun 16 00:37:52 yes, it'll bring all the fun on how broken it is Jun 16 00:38:03 At least with more things reaching mainline these days, the SoC vendors haven't dropped support for recent kernels before the devices ever reach retail. Jun 16 00:38:35 omap is keeping up with community very well Jun 16 00:38:43 I don't care about the actual operation of Windows 8: the reasons I am unlikely to use it have nothing to do with what it does or who makes it. Jun 16 00:39:23 I care more about how the presence of multiple operating system choices for a given platform provide incentives for board manufacturers to have known working generic solutions. Jun 16 00:39:57 TI does good. I like TI. I'm not happy with how bootstrapping works: it still requires omap-specific code. Jun 16 00:40:06 it is already happening due to android, linux duality Jun 16 00:40:17 From what I understand, this is a ROM issue with ROM inside the SoC, which can't be fixed until OMAP6 or OMAP7. Jun 16 00:40:35 Android and Linux are almost identical code (ignoring userspace). Jun 16 00:40:56 As a result, the *same* set of enablement patches is likely to work for both. Jun 16 00:41:12 yes, omap has a ROM which calls x-loader, u-boot, etc... Jun 16 00:41:21 The nice thing about Windows 8 is that the Android/Linux patches *will not apply*, which means thinking about generics at a design level. Jun 16 00:41:55 Anyway, I'm getting very late :) It's always fun chatting with you, but ... Jun 16 00:42:04 omap ROM code loads x-winloader which loads winkernel Jun 16 00:42:19 persia: sure, later .. :) **** ENDING LOGGING AT Thu Jun 16 02:59:57 2011