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