[10:14] <ogra_cmpc> lool, bug 572882 FYI
[10:14] <ubot4> Launchpad bug 572882 in qemu-kvm (Ubuntu) "qemu-debootstrap does not support --variant=fakechroot (affects: 1)" [Undecided,New] https://launchpad.net/bugs/572882
[10:15]  * ogra_cmpc wonders if we somehow can wrap qemu-arm-static in a fakeroot wrapper inside the chroot if that variant is chosen
[10:16] <ogra_cmpc> preferably without having to change the binfmt handler
[10:33] <lool> ogra_cmpc: I suspect fakeroot and fakechroot set LD_PRELOAD libraries which are not available in the chroot
[10:33] <lool> Because the runtime loader isn't the same on armel and x86
[10:34] <ogra_cmpc> yeah
[10:34] <ogra_cmpc> well, its the same binary, differnt link
[10:34] <lool> ?
[10:34] <ogra_cmpc> at kleast the .so version of the loaders are identical
[10:35] <ogra_cmpc> ld-2.11.1.so
[10:35] <ogra_cmpc> on both
[10:35] <lool> uh
[10:35] <ogra_cmpc> but ld-linux.so.2 on x86 and ld-linux.so.3 on armel as links to that
[10:35] <ogra_cmpc> yeah
[10:35] <lool> ogra_cmpc: ldd /usr/lib/libfakeroot/libfakeroot-sysv.so | grep ld-linux
[10:36] <ogra_cmpc> /lib/ld-linux.so.2 (0xb7745000)
[10:36] <lool> Not sure where you got ld-2.11.1.so, but the loaders have different names
[10:36] <ogra_cmpc> ogra@osiris:/var/build$ ls lucid-testxx/lib/ld-*
[10:36] <ogra_cmpc> lucid-testxx/lib/ld-2.11.1.so  lucid-testxx/lib/ld-linux.so.3
[10:37] <ogra_cmpc> ogra@osiris:/var/build$ ls /lib/ld-*
[10:37] <ogra_cmpc> /lib/ld-2.11.1.so  /lib/ld-linux.so.2
[10:37] <ogra_cmpc> they use the same binary version for the .so
[10:37] <lool> ld-linux has the ABI name, ld-2.x.so is the implementation
[10:38] <ogra_cmpc> ah
[10:38] <lool> dont look at ld-xxx.so, just at what binaries link to
[10:39] <ogra_cmpc> sigh, go-home-applet has a hard dep on netbook-launcher
[10:39] <lool> ogra_cmpc: So I personally dont see what one can do here
[10:39] <lool> ogra_cmpc: I'm tempted to wontfix the bug
[10:39] <ogra_cmpc> i cant install -efl standalone :(
[10:40] <ogra_cmpc> lool, hmm, i have a bug open for rootstock to be able to run it as non-root
[10:40] <lool> basically, LD_PRELOAD relies on shared libraries, so a static helper wouldn't help you
[10:40] <lool> ogra_cmpc: Yeah, and a spec as well
[10:40] <lool> ogra_cmpc: That would certainly be nice
[10:40] <ogra_cmpc> and i'd somehow like to find a way to solve it
[10:41] <lool> Sure
[10:41] <ogra_cmpc> though since you and hrw|gone seem to concentrate on vm-buildr now i wonder if we cant get that working in there
[10:41] <lool> well I dont think qemu-debootstrap is a piece in the puzzle
[10:41] <lool> qemu-debootstrap is just a handy hack which works in some cases, the fakeroot/fakechroot cases push it too far I'm afraid
[10:41] <ogra_cmpc> if it should replacde rootstock it seems like a waste of time to do it there
[10:42] <lool> ogra_cmpc: Note that vm-builder requires root as well
[10:42] <ogra_cmpc> right
[10:42] <lool> and calls into debootstrap
[10:42] <ogra_cmpc> not qemu-debootstrap ?
[10:42] <lool> no
[10:43] <ogra_cmpc> ah
[10:43] <lool> well not so far, and hrw's branch reimplements the qemu-debootstrap job
[10:43] <ogra_cmpc> though there is no reason it should need root :)
[10:43] <lool> there are many actually
[10:43] <ogra_cmpc> really ?
[10:43] <lool> Well the chown() and chroot() syscalls require root
[10:44] <ogra_cmpc> not if wrapped in fakechroot
[10:44] <lool> fakechroot will intercept the calls into libc and all the other entry points which test file ownership
[10:45] <lool> so that you dont actually use the safe OS chroot() or chown() calls, but fakechroot's emulation
[10:45] <lool> Problem is that fakeroot and/or fakechroots are fighting to keep up to date with the eglibc entry points all the time
[10:45] <ogra_cmpc> doesnt that abstract me enough from the os to be safe ?
[10:46] <ogra_cmpc> hmm
[10:47] <lool> All of fakeroot, fakechroot, and qemu are fragile emulators and your command-line tries to combine them all
[10:48] <ogra_cmpc> indeed
[10:48] <ogra_cmpc> since its the only way to make that usecase work with the current tools
[10:48] <lool> qemu-system-arm can be run as non-root and will provide everything within with root rights
[10:48] <lool> but it's dead slow
[10:49] <lool> ogra_cmpc: So overall, I agree it's the right thing to do to aim at not requiring root rights
[10:49] <ogra_cmpc> and i cant bootstrap it without root
[10:49] <lool> but I dont think you'll be successfully able to combine these three fragile things
[10:49] <ogra_cmpc> i thik i can but it would be a gross hack
[10:49] <lool> Another thing which makes it even more fragile on Ubuntu is the fact we build eglibc with -Bsymbolic-funcs
[10:50] <lool> ogra_cmpc: sorry, which use case do you refer to?
[10:50] <ogra_cmpc> running a rootfs build without requiring root
[10:50] <ogra_cmpc> which is a requirement nicolas expressed in nice
[10:52] <lool> ogra_cmpc: So I wonder how flexible that requirement is
[10:52] <ogra_cmpc> hmm, indeed i could switch rootstock back to its original setup without qemu-arm-static
[10:52] <lool> ogra_cmpc: One thing I wish we would allow are running libvirt backed environments, such as LXC with qemu-system-arm
[10:52] <ogra_cmpc> that wouldnt require root since the second stage runs in the VM
[10:53] <lool> It would require permission to access libvirt which runs as root
[10:53] <ogra_cmpc> why with qemu-system-arm ?
[10:53] <ogra_cmpc> and not with -static
[10:53] <lool> it wouldn't with qemu-system-arm, I mentionned that one earlier, but it's really slow
[10:53] <lool> There is no doubt that you can do it in qemu-system-arm of course
[10:54] <ogra_cmpc> right
[10:54]  * ogra_cmpc thought LXC needs a chroot by default
[11:11] <lool> well it does
[11:12] <lool> it's basically a super chroot, a container, which abstracts more than just filenames
[11:12] <ogra_cmpc> right, thats how i understood it
[11:13] <ogra_cmpc> so qemu-arm-static seemed better suited in my view
[11:17] <lool> ogra_cmpc: It's going to get you there faster, but it's going to provide terrible performance
[11:18] <ogra_cmpc> but i probably dont understand enough about LXC yet to imagine how you integrate the vm kernel with the host kernel in LXC if you use qemu-system-arm
[11:19] <lool> ogra_cmpc: LXC wont allow you to use qemu-system-arm
[11:19] <lool> it would be with qemu-arm-static
[11:19] <ogra_cmpc> ah, then i misunderstood you above
[11:20] <lool> ogra_cmpc: The point of libvirt / lxc is to a) have a slightly better tool than a chroot b) get permission to manage these via libvirt
[11:20] <ogra_cmpc> right
 ogra_cmpc: One thing I wish we would allow are running libvirt backed environments, such as LXC with qemu-system-arm
[11:20] <ogra_cmpc> that one confused me
[11:20] <lool> Yeah, that's a typo
[11:20] <lool> I meant qemu-arm-static
[11:20] <ogra_cmpc> ah
[11:21] <lool> it would also be great to have qemu-system-arm integrated in libvirt, but that's another story
[11:22] <ogra_cmpc> right, then i'm in full agreement, LXC integration is something i wanted to look at next, though i didnt priorize because it still doesnt solve the mono issues
[11:23] <ogra_cmpc> which was always my main concern with the -static implementation
[11:24] <lool> This one is apparently a though nut to crack
[11:24] <ogra_cmpc> yeah
[11:25] <ogra_cmpc> perferably to be fixed in mono itself though
[11:25] <ogra_cmpc> by using a more sane GC
[17:57] <prpplague> robclark in the office today?
[17:58] <robclark> hi prpplague, yeah
[17:58] <prpplague> fun fun
[17:58] <robclark> at least for a little bit
[17:58] <robclark> built new kernel, so need to copy it to MMC and boot up board so I can access it remotely ;-)
[17:58] <prpplague> i'm headed into my office later this evening to see if i can find that heat problem
[17:59] <prpplague> robclark dandy
[17:59] <robclark> ok.. keep me posted..  for now I'm working on other board, but same filesystem should work for both
[17:59] <prpplague> yea
[19:56] <sveinse> Hello. Where and how can I find the builtin compile options in gcc? Is it all in the specs file? -- I'm doing a comparison of the lucid gcc vs. a codesourcery cross compiler.
[20:25] <NCommander> sveinse: gcc -dumpspecs
[20:26] <sveinse> NCommander: Well, I also thought they were, but I cannot find them there
[20:26] <NCommander> sveinse: not sure what to tell you. doko is the toolchain expert
[20:27] <sveinse> If I do "gcc -o foo foo.c -v" I see a option COLLECT_GCC_OPTIONS with the default build options appended. It's the appended list I'm interested in
[20:28] <sveinse> This https://wiki.ubuntu.com/ARM/Thumb2 wiki lists them for Ubuntu, so that's the easy part. However, I don't know what it is for CS GCC...
[20:45] <lool> sveinse: Not sure what you mean
[20:45] <lool> sveinse: gcc -v outputs how gcc was configured, is this good enough?
[20:53] <sveinse> lool: Yeah, I'll stick with that for now
[21:09] <DanaG> hmm, say, does anyone know what the default setup of the pins on the beagle expansion header are, with the Ubuntu kernel?
[21:19] <sveinse> Anyone familiar with the gcc arm options? (lool?) What is the difference between the -mfpu=vfpv3-d16 and neon. AFAICS they are not mutually exclusive to each other
[22:21] <lool> sebjan: neon is a superset of -mfpu=vfpv3-d16
[22:21] <lool> sebjan: the last fpu= arg wins
[22:23] <lool> sebjan: err sorry, wrong nick
[22:23] <lool> sveinse: ^
[22:23] <lool> sveinse: See the gcc man page
[22:25] <sveinse> lool: Thanks. I've been looking at the gcc-info docs, but I couldn't find any info about the superset.. Perhaps I need new glasses 8)
[22:27] <DanaG> hmm, I've tweaked my thing to boot ubuntu with root on mmc but kernel in nand... but I still need it to use the initramfs.
[22:28] <DanaG> How's that supposed to work, anyway?  where is the initramfs in flash?
[22:28] <DanaG> ah, it's in the "file system" part.
[22:28] <DanaG> Can I point the kernel directly at that memory address as initramfs?
[22:29] <sveinse> lool: Perhaps more interestingly: I can compile my own apps using -mfpu=neon on lucid, right?
[22:59] <lool> sveinse: sure
[23:00] <lool> DanaG: The initramfs needs to be unpacked; I dont know whether it can unpack to RAM from flash
[23:14] <DanaG> I also wish the fw_printenv command would indent things.
[23:17] <DanaG> that'd make it far easier to read.
[23:18] <DanaG> ** Unable to read "boot.scr" from mmc 0:1 **
[23:18] <DanaG> reading uImage
[23:18] <DanaG> ** Unable to read "uImage" from mmc 0:1 **
[23:18] <DanaG> Booting from nand ...
[23:19] <DanaG> what's weird about that: there's a line-break after the first two... whereas it should be after the first ONE.
[23:19] <DanaG> "unable to read uimage" "booting from nand..."
[23:19] <DanaG> It should be "reading uimage" "unable to read uimage"
[23:27] <DanaG> great... I just accidentally did "nand erase", thinking it would tell me the usage of that command.