[04:43] Hello, is there any readily available cross compile toolchains for arm? [04:44] i.e. I would like to be able to type something like... apt-get install arm-linux-gcc on my host system and get a recent (4.2 or newer) toolchain [04:47] balders: oh, there is no such deb package for apt-get install, [04:47] balders: but you can download it from Code Sourcery website [04:47] balders: we use their cross toolchains to build kernel just for testing [04:47] ok, is the emdebain sources up to date or are they old? [04:48] deb http://www.emdebian.org/debian/ lenny main [04:48] balders: did not tried emdebian toolchain before. [04:48] balders: for fsl-imx51 and mvl-dove, we are using 4.4 gcc now [04:49] ok, what is fsl-imx51? [04:49] balders: freescale imx51 soc, fsl-imx51 is a branch of our lucid kernel tree [04:49] ahh ok [04:49] balders: mvl-dove is marvell dove, which is also a branch of our lucid kernel tree [04:50] balders: ok, good luck, has to leave for lunch [04:50] thanks for the tip [04:50] I will check out the code sourcery toolchain [09:38] cooloney, https://launchpad.net/~lool/+archive/ppa/+packages .... there is a cross compiler [09:51] hello [09:51] hello, I am trying to load up precompiled gpe jffs image and the zimage kernel for arm versatile with the following command and I get the error " or unkown-block(2,0)> I have no idea as to how am I supposed to boot the jffs image. Let me mention the fact that this gpe image has been compiled for ARM9 Micro2440 and [09:52] any help would be greatly appreciated [09:52] ............................ [09:58] anyone please [10:08] anyone please [10:34] ogra: bug 514215 [10:34] Launchpad bug 514215 in mono "mono ftbfs with thumb2 on armel" [Critical,Triaged] https://launchpad.net/bugs/514215 [10:34] ah, good [10:36] lets hope i can install all b-d [10:36] on jocote [10:36] why shouldnt you [10:36] you cannot remove packages ;) [10:36] so if there is a package that conflicts [10:36] IS can [10:36] then #is is needed [10:36] right [10:37] apt-get build-dep doesnt work either ;) [10:37] oh ? [10:37] i thought it did [10:37] no you have to manually do apt-get install ;) [10:38] sudo apt-get install ... will now work inside the dchroots on the porter [10:38] boxes, providing that nothing would be removed. [10:38] from lamonts mail [10:38] oh [10:38] thats not build-dep indeed [10:38] yeah [10:38] just inconvenient ... but not blocking ;) [10:39] yeah [10:55] ok lets see if that builds ;) [10:58] slow slow slow the boat [11:08] wonder if i really should have run debuild -S ... doesnt finish [11:10] hmm seems i am fighting with doko there ;) [11:19] ok aborted lintian ... thats just tooooo slow ;) [11:22] heh [11:22] fighting with doko is never good [11:22] he is building gcc ;) [11:22] i just want mono [11:23] most likely he is even using -j100 [11:23] unlikely, its an arm machine :) [11:23] do a local build [11:23] or is your babbage already packed [11:23] fighting with the rootfs from scratch [11:23] ;) [11:23] oh [11:24] whats wrong ? [11:24] somehow the kernel .deb didnt get installed :( [11:24] and initrd etc. [11:24] no, thats deliberate [11:24] i used --kernel-image [11:24] it gerenates a "rootfs" not a complete image (yet) [11:24] ouch [11:24] i should mark that as beagleboard only [11:24] its from the beagle guys [11:25] so you cannot create a usable image ;) [11:25] nice [11:25] for their kernel that doesnt use initramfs nor postinst [11:25] it creates a rootfs [11:25] nothing more [11:25] right. so one cannot create a working image ;) [11:25] kernel and initrd is usually completely board specific [11:25] right. thats why i want to specify the .deb i want to run [11:25] the tool was written for boards we dont suppport :) [11:26] yes, but installing an image is annoying. i want ubuntu-minimal [11:26] i dont have any big storage [11:26] initially it wasnt inteded for boards for which we have images [11:26] so all space counts [11:26] alternate ;) [11:26] also i want everything on the same sd [11:26] rootfs + bootfloppy [11:26] right [11:26] so use redboot-install for the bootfloppy part [11:27] then cfdisk to create the second partition [11:27] well ;) [11:27] i have the partition and stuff [11:27] then dump the rootfs onto the second partition [11:27] what i really neded was a kernel [11:27] right, buut you need to do the kernel stuff first [11:27] can i chroot into the mounted rootfs? [11:27] then create the rootfs partition [11:27] sure [11:27] hmm [11:27] how? [11:28] https://wiki.ubuntu.com/ARM/BabbageImageFromScratch [11:28] note its outdated [11:28] (i.e. kernel and initranfs need to come from elsewhere) [11:29] and the config changes work better with redboot-cmdline now [11:29] do you have an up to date initram fs? [11:30] etc. at ~ogra? [11:30] nope [11:30] use your qemu chroot ;) [11:30] why cant i chroot in to the rootfs? [11:30] with qemu? [11:30] and then install the normal image? [11:30] oh, indeed you should be able to even boot it from SD with qemu [11:30] ogra: how do i use that qemu chroot? i cannot chroot into it [11:30] i mean ... the rootfs [11:30] huh ? [11:31] i cannot chroot into it [11:31] what command? [11:31] mount your SD [11:31] the just chroot into it [11:31] that doesnt work ;) [11:31] let me try again [11:31] it should [11:31] at least if you have qemu-arm-static installed [11:31] binfmt should just switch the arch [11:31] ok me starts a new rootstock [11:32] lost my other rootfs [11:32] during reboot (/tmp) [11:32] ouch [11:33] qemu-arm-static makes no difference on SD or on local disk, it should always work to chroot into an arm root [11:34] btw, you could test my new redboot build while you're at it :) [11:35] sure ;) [11:36] http://people.canonical.com/~ogra/arm/redboot-imx51-babbage_200952-0ubuntu1_armel.deb [11:36] anyway. i have the feeling that all the docs should be consolidated ;) [11:36] its all spread apart ;) [11:36] yes, they need updating [11:36] and nothing on its own is as useful as it could be [11:36] no, its all in the /ARM namespace [11:36] i didnt find the babbageimagefromscratch one [11:36] but some other babbage thing ... which explained how to flash [11:37] right. i will clean it up after going through it while i still see the problems with the docs [11:37] https://wiki.ubuntu.com/ARM/BabbageImageFromScratch?action=fullsearch&context=180&value=babbage&titlesearch=Titel [11:37] ogra: hwat is new? [11:37] second hit if i search for babbage [11:37] titlesearch [11:37] yes, but not if you search for rootfs ;) [11:37] heh, indeed [11:38] * ogra wonders where RootfsOnSDForBabbage comes from [11:38] hmm there is https://wiki.ubuntu.com/ARM/RootfsOnSDForBabbage [11:38] that wasnt there yesterday ;) ... at least for me [11:39] last change 2009-07-20 [11:39] created by dyfet [11:39] BuildingBabbageRedBoot eek [11:39] that should vanish [11:39] so it doesnt say anything about the kernel again [11:39] RootfsOnSDForBabbage [11:39] people should use the packaged binaries [11:39] e.g. again one part missing ;) [11:40] i'll update BabbageImageFromScratch soon [11:40] and drop all the old jaunty cruft [11:40] maybe ... [11:40] its linked everywhere i post babbage instructions [11:40] i think what should really be done is that rootstock can produce images ... or we write a roothouse wrapper that does that [11:41] but was written for jaunty and updated for karmic [11:41] yes. [11:41] right, but rootstock creating full images is rathera L+1 task [11:41] for now i'm happy if i switch to a plugin system and get the basics from the spec done [11:42] before lucid releases :) [11:42] i can write the UI if you dont have time ... that should be quick [11:42] once thats there its easy to write a kernel plugin specific to the board you build for [11:42] yeah, lets sit down at the sprint for the UI [11:42] right. pure C ;) [11:43] lol [11:43] the changes i planned below UI are more elementar [11:43] so these need to be in place first [11:43] we have a wonderful plugin system developed for ltsp-build-client which essentially does the same as rootstock [11:43] i want to port rootstock to this [11:44] some build systems just dont get it [11:44] the plugin system in ltsp enabled it to be distro agnostic [11:44] mono always reconfigures on debuild -nc [11:44] after a build failure [11:44] yeah [11:44] mono is evil [11:44] i maintained back in breezy and hoary [11:44] thats a packaging bug [11:44] and was really happy to get rid of it [11:44] config.status should be honoured [11:45] after that the packaging was completely taken over by debian [11:45] yeah [11:45] and they completely redidi everything [11:45] i would have expected it to improve [11:45] but somehow that didnt happen [11:45] as long as we can sync ;) [11:45] as long as it doesnt ftbfs :) [11:46] haha .. yeah. but this is thumb2 ;) [11:47] hmm, for creating an initramfs inside a chroot for babbage we need to hack flash-kernel [11:47] or divert it to /bin/true [11:48] * ogra tries [11:49] argh [11:49] ? [11:49] so after reboot qemu is broken again [11:49] ;) [11:49] chroot: cannot run command `debootstrap/debootstrap': Exec format error [11:49] run the binfmt initscript [11:50] and try again [11:50] seems all this doesnt like different kernels [11:50] ok [11:50] i never had probs [11:50] and in karmic i even switched between -generic and -pae all the time [11:50] umount: /proc/sys/fs/binfmt_misc: not mounted [11:50] update-binfmts: warning: Couldn't unmount the binfmt_misc filesystem from [11:50] /proc/sys/fs/binfmt_misc. [11:50] i think i didnt even switch kernel [11:50] weird [11:50] so guess its not related [11:51] smells buggy [11:51] now binfmt is mounted at least [11:51] * asac runs again [11:51] we need to talk to cjwatson at the sprint about that [11:51] and take a deep look at your system [11:52] if it works everywhere but here, i wont bother too much. probably has something to do with the upstream/init stuff [11:52] upstart [11:52] well, do you run a different upstart than i ? [11:52] not that i know ;) [11:52] i try to keep my fingers off from that [11:55] heh [11:55] well, then it should cause this [11:55] i could imagine a mountall bug or something [11:55] that still seems shaky [11:55] hmm. yeah [11:55] but i don really mount much [11:56] but umount: /proc/sys/fs/binfmt_misc: not mounted somehow indictaes that something went wrong with mounting the binfmt handler fs [11:58] update-initramfs: Generating /boot/initrd.img-2.6.31-603-imx51 [11:58] /bin/grep: /proc/cpuinfo: No such file or directory [11:59] mumble [12:02] asac, http://paste.ubuntu.com/365144/ [12:04] surely not complete but the initrd creation works [12:04] nice [12:05] and indeed you cant just use the chroot right away, there are a good bunch of config files missing and no user is created etc ... all the stuff rootstock does [12:06] well. i want to use the rootstock fs [12:06] not a manual chroot [12:06] lets see ;) [12:06] but thate above could easily become a rootstock plugin later :) [12:07] right [12:07] the prob is that redboot-install needs to repartition the SD [12:07] ok unpacking the rootfs on sd [12:07] but to run it you need the initrd in advance [12:07] hmm [12:07] so keep the tgz :) [12:07] yeah [12:07] lets see what happens ;) [12:07] run the above in the chrooted SD [12:08] or better tar the chrooted Sd up after running the above steps [12:08] then run redboot-install, create a new rootfs partition and untar it again [12:08] so redboot-install will wipe all partitions? [12:08] yes [12:08] ok [12:08] it needs to create a new MBR [12:09] even if its mounted? [12:09] and a raw partiton [12:09] no idea, i guess parted will complain anyway [12:09] will see [12:09] its a bunch of parted and dd calls [12:09] and fis [12:09] so i rather should unpack the tgz on a host filesytem [12:10] hmm [12:10] i should probably add a check that if the first parted call fails it exitst if it doesnt do that already [12:10] nevermind ;) [12:10] i havent looked at redboot-tools for quite a while [12:10] but i'll do that during the sprint [12:10] ok mono build continued long enough [12:10] creating diff [12:10] and checking if there are any logical bugs ;) [12:11] i plan to mostly do redboot, rootstock and powermanagement [12:11] and at least one build of the uboot git tree to check it [12:11] ack [12:11] nah. lets do uboot after a3 [12:11] well, if its good enough i'D like to upgrade the poackage in the archive to the latest at least [12:11] you can do that after a3 ;) [12:12] plenty of time [12:12] to have a proper base in case we will need/use it later [12:12] yes, indeed [12:12] lets try to make release team happy by getting the still important specs done as good as possible [12:12] uboot doesnt need to be sprint stuff ... but i'd like to check it before release [12:12] and then do more after a3 without a blueprint ;) [12:12] right [12:12] sure ... do that after a3 .. or even after beta1 .. depending how up-to-date we are [12:13] right [12:13] argh [12:13] the mono package sucks [12:13] dpkg-source: error: old version is plain file [12:13] dpkg-source: error: cannot represent change to mono-2.4.3+dfsg/libgc/config.guess: [12:13] heh [12:13] dpkg-source: error: new version is symlink to /usr/share/automake-1.11/config.guess [12:13] dpkg-source: error: old version is plain file [12:13] dpkg-source: error: cannot represent change to mono-2.4.3+dfsg/libgc/config.sub: [12:13] dpkg-source: error: new version is symlink to /usr/share/automake-1.11/config.sub [12:13] fun [12:13] dpkg-source: error: old version is plain file [12:13] dpkg-source: error: cannot represent change to mono-2.4.3+dfsg/libgc/install-sh: [12:13] trying to produce sources of a half build tree [12:13] so i can get the diff out of the debdiff [12:13] annoying [12:13] yeah [12:13] cani tell debuild -S to ignore that? [12:14] i dont think so [12:14] if it was quilt i would have everything done by now :( [12:14] depends on the packaging system i guess ... there is that cdbs-autotools crap that re-copies these files from the system ... i think that also adds such a check [12:15] they dont use -c for autotools [12:15] so it creates symlinks ;) [12:15] but it seems to use dh and autoconf, automake directly [12:15] obviously ;) [12:15] should be possible to edit rules [12:16] well ... non of my business ;) [12:16] just want to get the diff :-P [12:16] unless there is a debhelper module [12:16] you need to ask the dh7 fanatics ;) [12:16] well, dont make a debdiff, just make a diff :) [12:16] ogra: I didn't break qemu-arm-static; it worked for me yesterday evening [12:16] and then ping directhex [12:16] lool, i was kidding :) [12:16] I didn't do any repackaging recently; only FTBFS fixes [12:17] i know you didnt break it [12:17] we all do :) [12:17] lool, asac's machine soemhow doesnt properly set up binfmt on boot ... no issue with qemu-arm-static at all here [12:18] yeah. we moved that in the "mountall" busted corner for now [12:18] heh [12:18] hell. i feel like filing a serious bug against mono ;) [12:18] more and more autotools symlinks left over after clean [12:20] debian bug 528090 [12:20] Debian bug 528090 in mono-gac "mono-gac/mono-runtime: mini circular dependency hell" [Important,Fixed] http://bugs.debian.org/528090 [12:21] lol [12:21] hahaha [12:21] bug 539807 [12:21] debian bug 539807 [12:21] Debian bug 539807 in mono "needlessly executable stack" [Normal,Open] http://bugs.debian.org/539807 [12:21] and we have that in main? [12:22] o reported by kees ;) [12:23] even on the CD [12:26] ogra: http://people.canonical.com/~pitti/workitems/canonical-mobile-lucid-alpha-3.html ... seems the status shows up there [12:26] "blocked on uboot bugs." [12:27] sweet [12:27] maybe i should maintain the status for the specs properly [12:27] and we're below trend [12:28] ogra: hmm. i dont think that foreign can be discarded [12:28] but i still have three todo's on the list [12:28] for that spec [12:28] the two bugs and the MIR [12:28] also ... we are posponing all the time ;) [12:28] i am not sure what to do for the bugs [12:28] let me check [12:28] we need to somehow postpone these three too [12:29] i think its because they are duplicated under "Work items lucid-alpha-3" [12:29] delete that section and we should be fine [12:30] ah, no, the bugs need to be unmilestoned [12:30] and the INPROGRESS item needs to become POSTPONED [12:30] then they should be gone [12:33] ok another batch of symlinks removed from mono :( [12:33] guess it would have been faster to copy the .h files i changed [12:33] ogra: i set to wont fix and milestone later for the main task now [12:33] lets see [12:34] if that works [12:34] * ogra tries to find his ESTA number for his travel notes [12:37] asac, i'll be at the vet. from 16:15 on, i might be to late for the release meeting (though trying to make it and indeed we're usually up at 17:30 anyway) [12:38] JamieBennett: maybe here [12:38] ogra: thx for heads up. i will survive without you i guess ;) [12:38] yeah, i guess i'm there anyway, but you never know [12:38] ogra: btw, NCommander said that dove X0 doesnt fix things :( [12:38] hmm, ericm_ said something different [12:39] when? [12:39] when he tested at marvell directly [12:39] he was over there working with a marvell engineer [12:39] right. but the news from yesterday came through NCommander but he said that that was new findings from ericm_ [12:39] bah [12:39] anyway. dont panic ;) [12:42] I'm here [12:44] i never panic [12:44] people just accuse me to [13:29] asac, ogra: I think you guys asked for devtmpfs to be backported; could you tell me who told you that was the only way? I'm interested in the rationale because I hit this too and I've filed a bug about this, but couldn't find yours [13:29] Also which kernel is this and why isn't it .32? [13:33] lool: for fsl we go for .31 [13:33] thats where the backporting effort stems from [13:34] persia: did a website with the items [13:34] guess we didnt open bugs [13:56] asac: What was the rationale for the backport? [13:57] That it didn't boot with mountall/upstart [13:57] ? [14:09] lool: ogra requested it iirc [14:10] let me see if i can find the wiki [14:20] lool, it did boot, it just boots 2 sec slower if the udev scripts are used instead of devtmpfs and initramfs's init spits out an error on boot [14:20] lool, Bug 512321 [14:20] Launchpad bug 512321 in linux-mvl-dove "please backport devtmpfs to the lucid linux-imx51 kernel tree" [Undecided,Fix committed] https://launchpad.net/bugs/512321 [14:21] Oh you're using an initramfs too [14:22] That's why it booted [14:22] Ah! mknod /dev/console and /dev/null; exactly the problem I was hitting [14:23] I'm pretty sure not having the devtmpfs slows down by much more than 2 seconds [14:23] MAKEDEV on so many devices takes two seconds on my x86-64 laptop!! [14:23] well, 2sec was what i could measure on the babbage using a stopwatch [14:23] In qemu, it's more in the 20 seconds [14:23] phew [14:24] was that your issue with the in-archive versatile kernel ? [14:24] i.e. does it fix it ? [14:24] we should just enable it in versatile by default [14:24]