[04:43] <balders> Hello, is there any readily available cross compile toolchains for arm?
[04:44] <balders> 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] <cooloney> balders: oh, there is no such deb package for apt-get install,
[04:47] <cooloney> balders: but you can download it from Code Sourcery website
[04:47] <cooloney> balders: we use their cross toolchains to build kernel just for testing
[04:47] <balders> ok, is the emdebain sources up to date or are they old?
[04:48] <balders> deb http://www.emdebian.org/debian/ lenny main
[04:48] <cooloney> balders: did not tried emdebian toolchain before.
[04:48] <cooloney> balders: for fsl-imx51 and mvl-dove, we are using 4.4 gcc now
[04:49] <balders> ok, what is fsl-imx51?
[04:49] <cooloney> balders: freescale imx51 soc, fsl-imx51 is a branch of our lucid kernel tree
[04:49] <balders> ahh ok
[04:49] <cooloney> balders: mvl-dove is marvell dove, which is also a branch of our lucid kernel tree
[04:50] <cooloney> balders: ok, good luck, has to leave for lunch
[04:50] <balders> thanks for the tip
[04:50] <balders> I will check out the code sourcery toolchain
[09:38] <ogra> cooloney, https://launchpad.net/~lool/+archive/ppa/+packages .... there is a cross compiler
[09:51] <Spyzer> hello
[09:51] <Spyzer> hello, I am trying to load up precompiled gpe jffs image and the zimage kernel for arm versatile with the following command <qemu-system-arm -M versatilepb -kernel zImage -hda gpe-image-micro2440.jffs2 -append initrd="noinitrd"> and I get the error <VFS: Cannot open root device "<NULL>" 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] <Spyzer> any help would be greatly appreciated
[09:52] <Spyzer> ............................
[09:58] <Spyzer> anyone please
[10:08] <Spyzer> anyone please
[10:34] <asac> ogra: bug 514215
[10:34] <ubot4> Launchpad bug 514215 in mono "mono ftbfs with thumb2 on armel" [Critical,Triaged] https://launchpad.net/bugs/514215
[10:34] <ogra> ah, good
[10:36] <asac> lets hope i can install all b-d
[10:36] <asac> on jocote
[10:36] <ogra> why shouldnt you
[10:36] <asac> you cannot remove packages ;)
[10:36] <asac> so if there is a package that conflicts
[10:36] <ogra> IS can
[10:36] <asac> then #is is needed
[10:36] <ogra> right
[10:37] <asac> apt-get build-dep doesnt work either ;)
[10:37] <ogra> oh ?
[10:37] <ogra> i thought it did
[10:37] <asac> no you have to manually do apt-get install ;)
[10:38] <ogra> sudo apt-get install ... will now work inside the dchroots on the porter
[10:38] <ogra> boxes, providing that nothing would be removed.
[10:38] <ogra> from lamonts mail
[10:38] <ogra> oh
[10:38] <ogra> thats not build-dep indeed
[10:38] <asac> yeah
[10:38] <asac> just inconvenient ... but not blocking ;)
[10:39] <ogra> yeah
[10:55] <asac> ok lets see if that builds ;)
[10:58] <asac> slow slow slow the boat
[11:08] <asac> wonder if i really should have run debuild -S ... doesnt finish
[11:10] <asac> hmm seems i am fighting with doko there ;)
[11:19] <asac> ok aborted lintian ... thats just tooooo slow ;)
[11:22] <ogra> heh
[11:22] <ogra> fighting with doko is never good
[11:22] <asac> he is building gcc ;)
[11:22] <asac> i just want mono
[11:23] <asac> most likely he is even using -j100
[11:23] <ogra> unlikely, its an arm machine :)
[11:23] <ogra> do a local build
[11:23] <ogra> or is your babbage already packed
[11:23] <asac> fighting with the rootfs from scratch
[11:23] <asac> ;)
[11:23] <ogra> oh
[11:24] <ogra> whats wrong ?
[11:24] <asac> somehow the kernel .deb didnt get installed :(
[11:24] <asac> and initrd etc.
[11:24] <ogra> no, thats deliberate
[11:24] <asac> i used --kernel-image
[11:24] <ogra> it gerenates a "rootfs" not a complete image (yet)
[11:24] <ogra> ouch
[11:24] <ogra> i should mark that as beagleboard only
[11:24] <ogra> its from the beagle guys
[11:25] <asac> so you cannot create a usable image ;)
[11:25] <asac> nice
[11:25] <ogra> for their kernel that doesnt use initramfs nor postinst
[11:25] <ogra> it creates a rootfs
[11:25] <ogra> nothing more
[11:25] <asac> right. so one cannot create a working image ;)
[11:25] <ogra> kernel and initrd is usually completely board specific
[11:25] <asac> right. thats why i want to specify the .deb i want to run
[11:25] <ogra> the tool was written for boards we dont suppport :)
[11:26] <asac> yes, but installing an image is annoying. i want ubuntu-minimal
[11:26] <asac> i dont have any big storage
[11:26] <ogra> initially it wasnt inteded for boards for which we have images
[11:26] <asac> so all space counts
[11:26] <ogra> alternate ;)
[11:26] <asac> also i want everything on the same sd
[11:26] <asac> rootfs + bootfloppy
[11:26] <ogra> right
[11:26] <ogra> so use redboot-install for the bootfloppy part
[11:27] <ogra> then cfdisk to create the second partition
[11:27] <asac> well ;)
[11:27] <asac> i have the partition and stuff
[11:27] <ogra> then dump the rootfs onto the second partition
[11:27] <asac> what i really neded was a kernel
[11:27] <ogra> right, buut you need to do the kernel stuff first
[11:27] <asac> can i chroot into the mounted rootfs?
[11:27] <ogra> then create the rootfs partition
[11:27] <ogra> sure
[11:27] <asac> hmm
[11:27] <asac> how?
[11:28] <ogra> https://wiki.ubuntu.com/ARM/BabbageImageFromScratch
[11:28] <ogra> note its outdated
[11:28] <ogra> (i.e. kernel and initranfs need to come from elsewhere)
[11:29] <ogra> and the config changes work better with redboot-cmdline now
[11:29] <asac> do you have an up to date initram fs?
[11:30] <asac> etc. at ~ogra?
[11:30] <ogra> nope
[11:30] <ogra> use your qemu chroot ;)
[11:30] <asac> why cant i chroot in to the rootfs?
[11:30] <asac> with qemu?
[11:30] <asac> and then install the normal image?
[11:30] <ogra> oh, indeed you should be able to even boot it from SD with qemu
[11:30] <asac> ogra: how do i use that qemu chroot? i cannot chroot into it
[11:30] <asac> i mean ... the rootfs
[11:30] <ogra> huh ?
[11:31] <asac> i cannot chroot into it
[11:31] <asac> what command?
[11:31] <ogra> mount your SD
[11:31] <ogra> the just chroot into it
[11:31] <asac> that doesnt work ;)
[11:31] <asac> let me try again
[11:31] <ogra> it should
[11:31] <ogra> at least if you have qemu-arm-static installed
[11:31] <ogra> binfmt should just switch the arch
[11:31] <asac> ok me starts a new rootstock
[11:32] <asac> lost my other rootfs
[11:32] <asac> during reboot (/tmp)
[11:32] <ogra> ouch
[11:33] <ogra> qemu-arm-static makes no difference on SD or on local disk, it should always work to chroot into an arm root
[11:34] <ogra> btw, you could test my new redboot build while you're at it :)
[11:35] <asac> sure ;)
[11:36] <ogra> http://people.canonical.com/~ogra/arm/redboot-imx51-babbage_200952-0ubuntu1_armel.deb
[11:36] <asac> anyway. i have the feeling that all the docs should be consolidated ;)
[11:36] <asac> its all spread apart ;)
[11:36] <ogra> yes, they need updating
[11:36] <asac> and nothing on its own is as useful as it could be
[11:36] <ogra> no, its all in the /ARM namespace
[11:36] <asac> i didnt find the babbageimagefromscratch one
[11:36] <asac> but some other babbage thing ... which explained how to flash
[11:37] <asac> right. i will clean it up after going through it while i still see the problems with the docs
[11:37] <ogra> https://wiki.ubuntu.com/ARM/BabbageImageFromScratch?action=fullsearch&context=180&value=babbage&titlesearch=Titel
[11:37] <asac> ogra: hwat is new?
[11:37] <ogra> second hit if i search for babbage
[11:37] <ogra> titlesearch
[11:37] <asac> yes, but not if you search for rootfs ;)
[11:37] <ogra> heh, indeed
[11:38]  * ogra wonders where RootfsOnSDForBabbage comes from
[11:38] <asac> hmm there is https://wiki.ubuntu.com/ARM/RootfsOnSDForBabbage
[11:38] <asac> that wasnt there yesterday ;) ... at least for me
[11:39] <ogra> last change 2009-07-20
[11:39] <ogra> created by dyfet
[11:39] <ogra> BuildingBabbageRedBoot eek
[11:39] <ogra> that should vanish
[11:39] <asac> so it doesnt say anything about the kernel again
[11:39] <asac> RootfsOnSDForBabbage
[11:39] <ogra> people should use the packaged binaries
[11:39] <asac> e.g. again one part missing ;)
[11:40] <ogra> i'll update BabbageImageFromScratch soon
[11:40] <ogra> and drop all the old jaunty cruft
[11:40] <asac> maybe ...
[11:40] <ogra> its linked everywhere i post babbage instructions
[11:40] <asac> i think what should really be done is that rootstock can produce images ... or we write a roothouse wrapper  that does that
[11:41] <ogra> but was written for jaunty and updated for karmic
[11:41] <asac> yes.
[11:41] <ogra> right, but rootstock creating full images is rathera L+1 task
[11:41] <ogra> for now i'm happy if i switch to a plugin system and get the basics from the spec done
[11:42] <ogra> before lucid releases :)
[11:42] <asac> i can write the UI if you dont have time ... that should be quick
[11:42] <ogra> once thats there its easy to write a kernel plugin specific to the board you build for
[11:42] <ogra> yeah, lets sit down at the sprint for the UI
[11:42] <asac> right. pure C ;)
[11:43] <asac> lol
[11:43] <ogra> the changes i planned below UI are more elementar
[11:43] <ogra> so these need to be in place first
[11:43] <ogra> we have a wonderful plugin system developed for ltsp-build-client which essentially does the same as rootstock
[11:43] <ogra> i want to port rootstock to this
[11:44] <asac> some build systems just dont get it
[11:44] <ogra> the plugin system in ltsp enabled it to be distro agnostic
[11:44] <asac> mono always reconfigures on debuild -nc
[11:44] <asac> after a build failure
[11:44] <ogra> yeah
[11:44] <ogra> mono is evil
[11:44] <ogra> i maintained back in breezy and hoary
[11:44] <asac> thats a packaging bug
[11:44] <ogra> and was really happy to get rid of it
[11:44] <asac> config.status should be honoured
[11:45] <ogra> after that the packaging was completely taken over by debian
[11:45] <asac> yeah
[11:45] <ogra> and they completely redidi everything
[11:45] <ogra> i would have expected it to improve
[11:45] <ogra> but somehow that didnt happen
[11:45] <asac> as long as we can sync ;)
[11:45] <ogra> as long as it doesnt ftbfs :)
[11:46] <asac> haha .. yeah. but this is thumb2 ;)
[11:47] <ogra> hmm, for creating an initramfs inside a chroot for babbage we need to hack flash-kernel
[11:47] <ogra> or divert it to /bin/true
[11:48]  * ogra tries
[11:49] <asac> argh
[11:49] <ogra> ?
[11:49] <asac> so after reboot qemu is broken again
[11:49] <asac> ;)
[11:49] <asac> chroot: cannot run command `debootstrap/debootstrap': Exec format error
[11:49] <ogra> run the binfmt initscript
[11:50] <ogra> and try again
[11:50] <asac> seems all this doesnt like different kernels
[11:50] <asac> ok
[11:50] <ogra> i never had probs
[11:50] <ogra> and in karmic i even switched between -generic and -pae all the time
[11:50] <asac> umount: /proc/sys/fs/binfmt_misc: not mounted
[11:50] <asac> update-binfmts: warning: Couldn't unmount the binfmt_misc filesystem from
[11:50] <asac> /proc/sys/fs/binfmt_misc.
[11:50] <asac> i think i didnt even switch kernel
[11:50] <ogra> weird
[11:50] <asac> so guess its not related
[11:51] <ogra> smells buggy
[11:51] <asac> now binfmt is mounted at least
[11:51]  * asac runs again
[11:51] <ogra> we need to talk to cjwatson at the sprint about that
[11:51] <ogra> and take a deep look at your system
[11:52] <asac> if it works everywhere but here, i wont bother too much. probably has something to do with the upstream/init stuff
[11:52] <asac> upstart
[11:52] <ogra> well, do you run a different upstart than i ?
[11:52] <asac> not that i know ;)
[11:52] <asac> i try to keep my fingers off from that
[11:55] <ogra> heh
[11:55] <ogra> well, then it should cause this
[11:55] <ogra> i could imagine a mountall bug or something
[11:55] <ogra> that still seems shaky
[11:55] <asac> hmm. yeah
[11:55] <asac> but i don really mount much
[11:56] <ogra> but umount: /proc/sys/fs/binfmt_misc: not mounted somehow indictaes that something went wrong with mounting the binfmt handler fs
[11:58] <ogra> update-initramfs: Generating /boot/initrd.img-2.6.31-603-imx51
[11:58] <ogra> /bin/grep: /proc/cpuinfo: No such file or directory
[11:59] <ogra> mumble
[12:02] <ogra> asac, http://paste.ubuntu.com/365144/
[12:04] <ogra> surely not complete but the initrd creation works
[12:04] <asac> nice
[12:05] <ogra> 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] <asac> well. i want to use the rootstock fs
[12:06] <asac> not a manual chroot
[12:06] <asac> lets see ;)
[12:06] <ogra> but thate above could easily become a rootstock plugin later :)
[12:07] <asac> right
[12:07] <ogra> the prob is that redboot-install needs to repartition the SD
[12:07] <asac> ok unpacking the rootfs on sd
[12:07] <ogra> but to run it you need the initrd in advance
[12:07] <asac> hmm
[12:07] <ogra> so keep the tgz :)
[12:07] <asac> yeah
[12:07] <asac> lets see what happens ;)
[12:07] <ogra> run the above in the chrooted SD
[12:08] <ogra> or better tar the chrooted Sd up after running the above steps
[12:08] <ogra> then run redboot-install, create a new rootfs partition and untar it again
[12:08] <asac> so redboot-install will wipe all partitions?
[12:08] <ogra> yes
[12:08] <asac> ok
[12:08] <ogra> it needs to create a new MBR
[12:09] <asac> even if its mounted?
[12:09] <ogra> and a raw partiton
[12:09] <ogra> no idea, i guess parted will complain anyway
[12:09] <asac> will see
[12:09] <ogra> its a bunch of parted and dd calls
[12:09] <ogra> and fis
[12:09] <asac> so i rather should unpack the tgz on a host filesytem
[12:10] <asac> hmm
[12:10] <ogra> i should probably add a check that if the first parted call fails it exitst if it doesnt do that already
[12:10] <asac> nevermind ;)
[12:10] <ogra> i havent looked at redboot-tools for quite a while
[12:10] <ogra> but i'll do that during the sprint
[12:10] <asac> ok mono build continued long enough
[12:10] <asac> creating diff
[12:10] <asac> and checking if there are any logical bugs ;)
[12:11] <ogra> i plan to mostly do redboot, rootstock and powermanagement
[12:11] <ogra> and at least one build of the uboot git tree to check it
[12:11] <asac> ack
[12:11] <asac> nah. lets do uboot after a3
[12:11] <ogra> well, if its good enough i'D like to upgrade the poackage in the archive to the latest at least
[12:11] <asac> you can do that after a3 ;)
[12:12] <asac> plenty of time
[12:12] <ogra> to have a proper base in case we will need/use it later
[12:12] <ogra> yes, indeed
[12:12] <asac> lets try to make release team happy by getting the still important specs done as good as possible
[12:12] <ogra> uboot doesnt need to be sprint stuff ... but i'd like to check it before release
[12:12] <asac> and then do more after a3 without a blueprint ;)
[12:12] <ogra> right
[12:12] <asac> sure ... do that after a3 .. or even after beta1 .. depending how up-to-date we are
[12:13] <ogra> right
[12:13] <asac> argh
[12:13] <asac> the mono package sucks
[12:13] <asac> dpkg-source: error:   old version is plain file
[12:13] <asac> dpkg-source: error: cannot represent change to mono-2.4.3+dfsg/libgc/config.guess:
[12:13] <ogra> heh
[12:13] <asac> dpkg-source: error:   new version is symlink to /usr/share/automake-1.11/config.guess
[12:13] <asac> dpkg-source: error:   old version is plain file
[12:13] <asac> dpkg-source: error: cannot represent change to mono-2.4.3+dfsg/libgc/config.sub:
[12:13] <asac> dpkg-source: error:   new version is symlink to /usr/share/automake-1.11/config.sub
[12:13] <ogra> fun
[12:13] <asac> dpkg-source: error:   old version is plain file
[12:13] <asac> dpkg-source: error: cannot represent change to mono-2.4.3+dfsg/libgc/install-sh:
[12:13] <asac> trying to produce sources of a half build tree
[12:13] <asac> so i can get the diff out of the debdiff
[12:13] <asac> annoying
[12:13] <ogra> yeah
[12:13] <asac> cani tell debuild -S to ignore that?
[12:14] <ogra> i dont think so
[12:14] <asac> if it was quilt i would have everything done by now :(
[12:14] <ogra> 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] <asac> they dont use -c for autotools
[12:15] <asac> so it creates symlinks ;)
[12:15] <ogra> but it seems to use dh and autoconf, automake directly
[12:15] <asac> obviously ;)
[12:15] <ogra> should be possible to edit rules
[12:16] <asac> well ... non of my business ;)
[12:16] <asac> just want to get the diff :-P
[12:16] <ogra> unless there is a debhelper module
[12:16] <asac> you need to ask the dh7 fanatics ;)
[12:16] <ogra> well, dont make a debdiff, just make a diff :)
[12:16] <lool> ogra: I didn't break qemu-arm-static; it worked for me yesterday evening
[12:16] <ogra> and then ping directhex
[12:16] <ogra> lool, i was kidding :)
[12:16] <lool> I didn't do any repackaging recently; only FTBFS fixes
[12:17] <ogra> i know you didnt break it
[12:17] <ogra> we all do :)
[12:17] <ogra> lool, asac's machine soemhow doesnt properly set up binfmt on boot ... no issue with qemu-arm-static at all here
[12:18] <asac> yeah. we moved that in the "mountall" busted corner for now
[12:18] <ogra> heh
[12:18] <asac> hell. i feel like filing a serious bug against mono ;)
[12:18] <asac> more and more autotools symlinks left over after clean
[12:20] <asac> debian bug 528090
[12:20] <ubot4> Debian bug 528090 in mono-gac "mono-gac/mono-runtime: mini circular dependency hell" [Important,Fixed] http://bugs.debian.org/528090
[12:21] <asac> lol
[12:21] <ogra> hahaha
[12:21] <asac> bug 539807
[12:21] <asac> debian bug 539807
[12:21] <ubot4> Debian bug 539807 in mono "needlessly executable stack" [Normal,Open] http://bugs.debian.org/539807
[12:21] <asac> and we have that in main?
[12:22] <asac> o reported by kees ;)
[12:23] <ogra> even on the CD
[12:26] <asac> ogra: http://people.canonical.com/~pitti/workitems/canonical-mobile-lucid-alpha-3.html ... seems the status shows up there
[12:26] <asac> "blocked on uboot bugs."
[12:27] <ogra> sweet
[12:27] <asac> maybe i should maintain the status for the specs properly
[12:27] <ogra> and we're below trend
[12:28] <asac> ogra: hmm. i dont think that foreign can be discarded
[12:28] <ogra> but i still have three todo's on the list
[12:28] <ogra> for that spec
[12:28] <ogra> the two bugs and the MIR
[12:28] <asac> also ... we are posponing all the time ;)
[12:28] <asac> i am not sure what to do for the bugs
[12:28] <asac> let me check
[12:28] <ogra> we need to somehow postpone these three too
[12:29] <ogra> i think its because they are duplicated under "Work items lucid-alpha-3"
[12:29] <ogra> delete that section and we should be fine
[12:30] <ogra> ah, no, the bugs need to be unmilestoned
[12:30] <ogra> and the INPROGRESS item needs to become POSTPONED
[12:30] <ogra> then they should be gone
[12:33] <asac> ok another batch of symlinks removed from mono :(
[12:33] <asac> guess it would have been faster to copy the .h files i changed
[12:33] <asac> ogra: i set to wont fix and milestone later for the main task now
[12:33] <asac> lets see
[12:34] <ogra> if that works
[12:34]  * ogra tries to find his ESTA number for his travel notes
[12:37] <ogra> 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] <asac> JamieBennett: maybe here
[12:38] <asac> ogra: thx for heads up. i will survive without you i guess ;)
[12:38] <ogra> yeah, i guess i'm there anyway, but you never know
[12:38] <asac> ogra: btw, NCommander said that dove X0 doesnt fix things :(
[12:38] <ogra> hmm, ericm_ said something different
[12:39] <asac> when?
[12:39] <ogra> when he tested at marvell directly
[12:39] <ogra> he was over there working with a marvell engineer
[12:39] <asac> right. but the news from yesterday came through NCommander but he said that that was new findings from ericm_
[12:39] <ogra> bah
[12:39] <asac> anyway. dont panic ;)
[12:42] <JamieBennett> I'm here
[12:44] <ogra> i never panic
[12:44] <ogra> people just accuse me to
[13:29] <lool> 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] <lool> Also which kernel is this and why isn't it .32?
[13:33] <asac> lool: for fsl we go for .31
[13:33] <asac> thats where the backporting effort stems from
[13:34] <asac> persia: did a website with the items
[13:34] <asac> guess we didnt open bugs
[13:56] <lool> asac: What was the rationale for the backport?
[13:57] <lool> That it didn't boot with mountall/upstart
[13:57] <lool> ?
[14:09] <asac> lool: ogra requested it iirc
[14:10] <asac> let me see if i can find the wiki
[14:20] <ogra> 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] <ogra> lool, Bug 512321
[14:20] <ubot4> 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] <lool> Oh you're using an initramfs too
[14:22] <lool> That's why it booted
[14:22] <lool> Ah!  mknod /dev/console and /dev/null; exactly the problem I was hitting
[14:23] <lool> I'm pretty sure not having the devtmpfs slows down by much more than 2 seconds
[14:23] <lool> MAKEDEV on so many devices takes two seconds on my x86-64 laptop!!
[14:23] <ogra> well, 2sec was what i could measure on the babbage using a stopwatch
[14:23] <lool> In qemu, it's more in the 20 seconds
[14:23] <ogra> phew
[14:24] <ogra> was that your issue with the in-archive versatile kernel ?
[14:24] <ogra> i.e. does it fix it ?
[14:24] <ogra> we should just enable it in versatile by default
[14:24] <ogra> since thats .32 there shouldnt be an issue
[14:24] <lool> I don't know what prevents the in-archive versatile kernel from booting; the biggest issue I have is that it lacks video output
[14:24] <lool> The config for that is pl110 IIRC
[14:25] <ogra> well, i still havent tried it and i doubt i'll get to it today, but i'm planning a lot of rootstock work during the sprint so we'll get it sorted there
[14:26] <lool> pl110
[14:41]  * asac wonders if its worth adding a configure test for gcc intrinsics to mono ... or just use ith if __thumb__
[14:42] <asac> #ifdef __thumb__
[14:45] <asac> what arm/thumb asm reference is good?
[15:23] <asac> bug 511197
[15:23] <ubot4> Launchpad bug 511197 in busybox "fails to build on arm lucid (thumb2)" [Undecided,Fix released] https://launchpad.net/bugs/511197
[15:27] <dmart> asac: Take a look at https://wiki.ubuntu.com/ARM/Thumb2PortingHowto - I'm still writing it, so any comments on whether this is any use / what else we need are welcome.
[15:29] <asac> dmart: too bad you havent written the swp instructions yet ;)
[15:29] <asac> could have checked if i did it right
[15:30] <asac> dmart: do you thin its worth hacking configure to check for gcc atomic builtins?
[15:30] <asac> or just __thumb__ ?
[15:30] <dmart> You might be able to pull the atomic builtin check out of glib2.0
[15:30] <asac> hmm. yeah
[15:31] <asac> patching configure is always annoying ;)
[15:31] <asac> packaing wise ... but ok
[15:36] <asac> bug 456659
[15:36] <ubot4> Launchpad bug 456659 in linux-fsl-imx51 "suspend/resume failure on imx51" [High,Confirmed] https://launchpad.net/bugs/456659
[15:37] <ogra> fixed
[15:38] <ogra> why is that confirmed ... hrm
[15:38] <ogra> oh, the bot reads the karmic info
[15:41] <dmart> asac: the main issue is people using tools which may not have the atomic builtins support (Debian possibly, and other 3rd parties).  I think pretty much everyone is on a new enough kernel these days (2.6.16?)
[15:43] <asac> plars: do you have the nautilus crasher at hand?
[15:43] <asac> the bug id ;)
[15:43] <asac> chromiums awesome bar is not that great i have to say
[15:43] <ogra>  Bug 512959
[15:43] <ubot4> Launchpad bug 512959 in gvfs "nautilus assert failure: *** stack smashing detected ***: nautilus terminated" [High,Confirmed] https://launchpad.net/bugs/512959
[15:43] <ogra> asac, did your imx SD experiment work ?
[15:43] <asac> yeah
[15:46] <asac> did i say yeah
[15:46] <asac> not to that
[15:46] <asac> i didnt finish that yet :)
[15:46] <ogra> ah
[15:46] <ogra> i noticed the yeah came to fast to refer to that :)
[16:02] <plars> asac: do you want me to go through and target all of those "port to thumb2" bugs?
[16:02] <plars> asac: milestone them rather?
[16:05] <ogra> hrm, my löaptop doesnt see its LCD panel anymore
[16:05] <asac> plars: good question
[16:05] <ogra> only the external monitor
[16:06]  * ogra wonders if he should travel with his 24" screen now
[16:06] <asac> plars: i think so ...
[16:06] <asac> plars: i think we can mark the mono bug as a dupe
[16:08] <plars> asac: are you talking about bug 514215 and bug 513736 ?
[16:08] <ubot4> Launchpad bug 514215 in mono "mono ftbfs with thumb2 on armel" [Critical,Triaged] https://launchpad.net/bugs/514215
[16:08] <ubot4> Launchpad bug 513736 in mono "[arm] needs porting to thumb2" [Undecided,New] https://launchpad.net/bugs/513736
[16:10] <asac> plars: yeah
[16:10] <asac> i documented 514215 in the upload i was preparing
[16:11] <asac> but i can use the other
[16:11] <asac> though the other is now on release page
[16:11] <plars> asac: ok, I'll milestone them all for A3 for now, we can push later if we need to but these might be a good thing to assign out to people and try to hammer them out next week
[16:12] <plars> asac: np, I'll make 514215 the master and dup the other one to it
[16:12] <asac> thx
[16:26] <plars> asac: bug 514252
[16:26] <ubot4> Launchpad bug 514252 in qemu-kvm "[arm] (might) need porting to thumb2" [High,Triaged] https://launchpad.net/bugs/514252
[16:26] <plars> asac: qemu-kvm? why are we even trying to build that on armel?
[16:28] <ogra> plars, lool would like to sse it working and at some point when armel HW is powerful enough it might help with apps that cant be ported
[16:28] <ogra> *see
[16:28] <ogra> i.e. wine
[16:29] <plars> ogra: interesting, so we expect to maybe have kvm support on arm someday? that would be cool
[16:29] <asac> hmm. not sure
[16:29] <asac> just made the bugs from the review list
[16:29] <asac> feel free to move that to medium or something
[16:29] <ogra> i would have taken it off armel long ago but technically there is no actual reason to do so, lool is right here
[16:29] <asac> if its currently not runnig at all
[16:29] <asac> or even low
[16:29] <ogra> plars, there are roumors about kvm being ported to armel but i have never actually seen any work on it
[16:30] <ogra> for a start it would have to build even without kvm
[16:30] <ogra> asac, plars, low feel appropriate
[16:30] <ogra> *feels
[16:31]  * ogra tries to get used to his laptop kbd again
[16:31] <ogra> havent used that for a while
[16:49] <dmart> plars: Hi - SHouldn't we be cautious about marking the new Thumb-2 porting bugs as duplicates of existing bugs?  The new porting bugs are more general; I'm wondering if there's a risk if addressing only the more specific issues in the pre-existing bug and forgetting about the rest.
[16:49] <dmart> The new porting bugs are not just about ftbfs; there are also some "may build but might not work properly" and some future proofing issues.
[16:50] <plars> dmart: I copied over the information from the old bug to make sure that not only the ftbfs was addressed, but also the more general porting issues.
[16:51] <plars> dmart: asac mentioned to me that he thought it was good to combine the two, perhaps it warrants further discussion though
[16:51] <dmart> Oh, OK - that's fine.  I hadn't read everything yet, just saw the mails coming in.
[16:51] <plars> dmart: yeah, sorry for the spamfest :)
[16:51] <dmart> Yes, I think combining them is sensible
[16:51] <dmart> No problem about the spam, I started this off anyway :)
[16:53] <ogra> in cases where ftbfs can only be fixed to full porting work i guess it ok to merg such bugs
[16:53] <ogra> s/to/through/
[16:56] <dmart> Anyone interested, please take a look at https://wiki.ubuntu.com/ARM/Thumb2PortingHowto and see whether it looks likely to be useful and understandable, whether it looks like there's anything missing (bearing in mind I'm still writing...)
[16:56] <dmart> We can link this from the porting bugs (though I don't mind doing that later)
[17:24] <asac_> err
[17:24] <asac_> ogra: http://paste.ubuntu.com/365282/ :/
[17:51] <lool> asac, ogra: Note that qemu-kvm is not only about kvm but also about qemu, and qemu builds on all arches in Debian
[17:57] <asac> lool: yes. what we found was arm code that wouldnt be thumb safe ... thats all. if you know thats used/not used, fix/invalidate the bug etc.
[17:57] <asac> also unassign etc. ... whatever you think is ok ;)
[18:03] <lool> asac: Well I think it's a real bug that our Ubuntu qemu doesn't build on an official arch (armel) when it does in Debian; it didn't build in karmic either though
[18:04] <asac> lool: anything we can do there?
[18:04] <asac> remember that there was kind of a tie
[18:04] <asac> with server team wanting something that breaks us
[18:05] <lool> I don't remember that
[18:05] <lool> I know we're not using the exact same upstream as Debian (qemu-kvm !- qemu)
[18:05] <lool> s/!-/!=
[18:05] <asac> yeah
[18:05] <asac> and that was done by server team, right?
[18:05] <lool> Yes
[18:05] <asac> so thats what i remember ;)
[18:06] <asac> why didnt they add a second source package?
[18:06] <lool> Well my point stands: this program should build on armel, even if it's a slightly different branch
[18:06] <asac> hmm. they did it seems
[18:06] <lool> qemu-kvm pulls fomr qemu regularly
[18:06] <asac> ;)
[18:06] <asac> yeah
[18:06] <asac> agreed
[18:06] <asac> so we have it on ftbfs list?
[18:06]  * asac checks
[18:06] <lool> Yes
[18:07] <asac> ok its not armel only
[18:07] <asac> thats probably why noone started on that
[18:07] <lool> I'm just explaining why it deserves to be tracked: it's a real bug and regression over Debian caused by the Ubuntu changes
[18:07] <lool> The issues are wildly different depending on the arch
[18:07] <asac> ok the build failure we have atm is atomics
[18:07] <asac> so covered by the thumb2 bug
[18:08] <lool> I looked at all Ubuntu arches in karmic and fixed the first issue of each arch, but there was at least one more issue on each arch after each fix
[18:08]  * asac checks what broke karmic
[18:08] <lool> And each fix I applied was different
[18:08] <lool> The current failure is earlier than the karmic one, so it's *another* regression on top of the karmic one, introduced by T2
[18:08] <asac> /build/buildd/qemu-kvm-0.11.0/linux-user/elfload.c:289: error: conflicting types for 'elf_greg_t'
[18:08] <asac> /usr/include/sys/procfs.h:39: note: previous declaration of 'elf_greg_t' was here
[18:08] <asac> /build/buildd/qemu-kvm-0.11.0/linux-user/elfload.c:295: error: conflicting types for 'elf_gregset_t'
[18:08] <asac> /usr/include/sys/procfs.h:46: note: previous declaration of 'elf_gregset_t' was here
[18:08] <asac> /build/buildd/qemu-kvm-0.11.0/linux-user/elfload.c:1782: error: redefinition of 'struct elf_siginfo'
[18:09] <asac> /build/buildd/qemu-kvm-0.11.0/linux-user/elfload.c:1788: error: redefinition of 'struct elf_prstatus'
[18:09] <asac> /build/buildd/qemu-kvm-0.11.0/linux-user/elfload.c:1807: error: redefinition of 'struct elf_prpsinfo'
[18:09] <asac> yeah
[18:09] <asac> is linux-user a copy of some other package/source ?
[18:09] <asac> hmm
[18:12] <lool> linux-user is the qemu mode used in qemu-arm-static
[18:12] <lool> It's the syscall emulation mode
[18:13] <lool> It's copied during the build for all targets