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