[09:59] <lool> I merged kexec-tools with Debian
[10:00] <ogra> nice !
[10:00] <ogra> but it still doesnt work ?
[10:00] <ogra> (on arm)
[10:03] <lool> ogra: It still hangs when you try to kexec within qemu/versatile
[10:03] <lool> The Debian merge was mostly packaging stuff
[10:04] <persia> The packaging is sane again?
[10:05] <lool> Yes
[10:05] <lool> The Ubuntu diff is absolutely bearable
[10:06] <lool> We mostly disable kexec on boot by default and add kdump
[10:06] <lool> Too bad I didn't notice there is a kernel.ubuntu.com/git kexec-tools git tree, but it has its own issues anyway
[10:07] <persia> I suspect it's from that tree that last week's tests were executed.
[10:07] <lool> I mailed cooloney on the kexec issue; I hope he can help us there, it's too low level for me
[10:08] <persia> Probably best to coordinate with ericm_ and NCommander to make sure everyone is testing the same source.
[10:08] <persia> I thought ericm was doing most of that, but cooloney may also be able to help.
[10:08] <lool> persia: The tree has the same issues as lucid, it's out of date by one upload before my work and just misses the kdump init script
[10:08] <lool> I rather suspect NCommander took Debian's or upstream's kexec-tools
[10:08] <persia> Quite possibly.
[10:12] <lool> I wonder whether ericm can be bothered for versatile kexec
[10:12] <persia> lool: Did you ever get anywhere with the pbuilder-dist changes to do better detection of when to use the alternate debootstrap?  Should I track down some other python person?
[10:12] <lool> I didn't attack that
[10:12] <persia> I suspect that getting versatile kexec working would be a good step towards getting it working anywhere else.
[10:12] <lool> My real plan is to remove the need for pbuilder-dist altogether, but that's a longer term effort
[10:12] <persia> No worries then.  I'll try to find someone else.
[10:13] <lool> If you remind me of everything we agreed to do, I can certainly do it
[10:13] <persia> I have a solution to drop pbuilder-dist: migrate to schroot/sbuild :)
[10:13] <lool> Eh
[10:13] <lool> schroot/sbuild doesn't have cowdancer though; it does have LVM snapshot, but it's a bit different
[10:13] <persia> You didn't like me using the architecture to determine when to use the emulator: you seemed to prefer to do host/guest arch compat comparison.
[10:13] <persia> schroot *does* have COW now, in 1.4, although I haven't quite figured out how to get it working.
[10:14] <persia> It's on my list to try to get schroot to work with pbuilder-style tarballs, COW, etc. in the next few months (although I'm not sure I can release with lucid)
[10:14] <lool> I don't see that; are you sure you don't mean LVM COW?
[10:14] <persia> I am.
[10:14] <lool> persia: I don't see this in /usr/share/doc/schroot/NEWS.gz though; let me check sbuild
[10:15] <lool> I don't see it in sbuild's NEWS either
[10:15] <lool> persia: Do you have any name/reference for the feature?
[10:15] <persia> "Support for union filesystems has been added ... loopback chroots with a temporary writable overlay ...".  It's not quite COW, but should have similar performance.
[10:16] <persia> Quote is from sbuild's NEWS.gz
[10:16] <lool> Ah but that's not in lucid?
[10:17] <persia> Yes it is :)
[10:17] <lool> I was checking lucid files
[10:17] <persia> So was I.  Check item 8) in NEWS for 1.3.0-rc1
[10:17] <lool> Why don't I see union in NEWS.Debian and NEWS??
[10:17] <lool> sbuild doesn't have 1.3.0-rc1
[10:17] <persia> Err, sorry.  From *schroot* NEWS.gz
[10:17] <persia> sbuild is just a build script that runs against schroots.
[10:17] <lool> Ack I see it now
[10:18] <cooloney> lool: yeah, i'm looking at that.
[10:18] <lool> Using union fses is much cleaner than pbuilder's approach
[10:18] <cooloney> persia: ericm_ made it kexec works on dove, IIRC.
[10:18] <lool> cooloney: let me know if you need any help with the setup
[10:18] <persia> lool: And `sudo pbuilder` is just pointless escalation.  schroot's selective mechanism is much richer.
[10:18] <cooloney> persia: he will help me about this
[10:19] <lool> persia: Tell me about it
[10:19] <persia> cooloney: I thought it kinda worked, but then crashed on the call, but I may be mistaken.  Great to hear you guys will be working together on this.
[10:19] <cooloney> lool: yeah, do you know where can I download the rootfs for testing
[10:19] <lool> cooloney: Best to create your own; it's quite easy
[10:19] <persia> cooloney: Use rootstock to generate one :)
[10:20] <lool> I still call debootstrap by hand, but the recommended tool is probably rootstock or just build-arm-chroot
[10:20] <cooloney> persia: yeah, since imx51 also has some issue about kexec, i need to work on that as well as versatile
[10:20] <lool> rootstock will setup misc configs for you, hostname, passwords and the like
[10:20] <persia> Definitely rootstock.  It does a lot of the installer bits that build-arm-chroot skips, like user creation, etc.
[10:20] <persia> (which don't belong in build-arm-chroot, really)
[10:20] <cooloney> lool: oh, it is very slow for me to download the evironment. i tried rookstock before. heh
[10:21] <lool> cooloney: You don't have a mirror nearby?
[10:21] <ogra> cooloney, kexec didnt work on friday when NCommander tried it though that might be because kexec-tools was broken
[10:21] <lool> cooloney: I can back you my rootfs if you like, hold on
[10:21] <cooloney> lool: can i try common local ubuntu mirror for that?
[10:22] <cooloney> lool: yeah, i love that. hehe
[10:22] <lool> cooloney: You need a ports mirror sadly
[10:22] <cooloney> ogra: yeah, ericm_ mention that before.
[10:22] <lool> cooloney: What I recommend is that you use squid as a caching proxy
[10:22] <lool> If the .debs don't change too often, nost of the debootstrap bits will be cached in there
[10:22] <cooloney> lool: i guess there is no such ports mirror in China.
[10:23] <ogra> cooloney, use approx on your local machine
[10:23] <lool> cooloney: squid-deb-proxy is a package which will setup squid to that effect
[10:23] <cooloney> lool: great, is there any wiki for such setup?
[10:23] <ogra> then you at least only have to download once
[10:23] <lool> cooloney: Then you just need to set http_proxy in /etc/environment and you're done
[10:23] <lool> cooloney: squid-deb-proxy might have some doc
[10:23] <ogra> or as lool said
[10:23] <lool> cooloney: I'm scp-ing my rootfs, but will take a while
[10:23] <cooloney> lool: got you
[10:24] <ogra> approx needs no setup though ... you just point to your local IP
[10:24] <ogra> on port 9999
[10:24] <cooloney> lool: thanks a lot, if it is done, just email me
[10:24] <cooloney> ogra: right, i think i tried approx before. any wiki about that?
[10:25] <cooloney> lool: email me the url, heh
[10:25] <lool> cooloney: URL will be http://people.canonical.com/~lool/rootfs.img
[10:25] <lool> but not finished yet
[10:26] <ogra> cooloney, apt-get install approx ... then use -mirror http://<your local IP>:9999/ubuntu-ports in your scripts (or set http_proxy to <your local IP>:9999)
[10:26] <ogra> i use it with rootstock all the time to speed up my testbuilding
[10:27]  * lool simply has a local mirror
[10:27] <persia> A local mirror tends to be the easiest way to deal with limited bandwidth, but does require a bit more hardware.
[10:27]  * ogra thinks lool is a rich man who can waste useful diskspace
[10:28]  * lool thinks his time is more valuable than hardware
[10:28] <ogra> with a disk that costs €20/GB i really dont like to waste it
[10:29] <lool> 20 EUR/GB?  are these made of gold?
[10:29] <ogra> well, i rarely need most of the packages from the mirror ... so just caching the ones i use over and over makes a lot more sense
[10:29] <cooloney> OMG, you guys all have local mirror?
[10:29] <ogra> lool, no, of super speedy flash :)
[10:29] <lool> https://www.materiel.net/ctl/Disques_durs_internes_SATA/46461-Barracuda_7200_12_S_ATA_1000_Go_32_Mo.html
[10:29] <cooloney> so normally, how big disk is enough for setup a  mirror?
[10:30] <ogra> cooloney, nope, as i said above, i think a local mirror is a waste of diskspace
[10:30] <cooloney> ogra: apparently, you don't have, heh
[10:30] <cooloney> ogra: you got faest speed maybe. heh
[10:30] <lool> That's .075790 EUR/GB  :)
[10:31] <ogra> a local proxy will only cache what i need, a local mirror copies the whole archive
[10:31] <cooloney> ogra: right.
[10:31] <ogra> lool, does it boot in 8sec ? :P
[10:31] <lool> ogra: That only works if you always the same stuff
[10:31] <cooloney> but lool doesn't care about that
[10:31] <lool> ogra: Actually about that yes
[10:31] <ogra> indeed, its perfect for image builds
[10:31] <lool> Because it's in RAID10 and doesn't start the desktop
[10:31] <ogra> haha
[10:31] <ogra> cheater
[10:32] <ogra> lool, http://people.canonical.com/~ogra/osiris-lucid-20100202-6.png :P
[10:32] <ogra> and thats a slow boot ... i usually have around 230MB/s
[10:33] <persia> Stop wagging :p
[10:33] <cooloney> lool: how big is your rootfs? heh
[10:33] <lool> ogra: Err you know I have SSD on my laptop since a year and a half?
[10:33] <cooloney> lool: 1G?
[10:33] <lool> Plus mine is bigger than yours
[10:34] <ogra> lool, yeah, as i said, youre a rich man ... i'm a poor german, cant spend on wine for lunch :P
[10:34] <cooloney> ogra: lol
[10:34] <lool> Just don't try teasing me!
[10:50] <lool> cooloney: Done uploading
[10:50] <lool> cooloney: There isn't much free space, you can grow the rootfs by appending some zeroes to the file and growing with ext2resize
[11:11] <ogra> lool, was it you who added the if [ ! -f /usr/share/debootstrap/scripts/$DIST ];then check to rootstock ?
[11:12]  * ogra cant remember from where that got merged, but it seems silly to additionally keep the version check code 
[11:12]  * persia suggests `bzr blame ...`
[11:12] <ogra> persia, bah, trying to kill my lazyness ?
[11:13] <persia> Every day, in every way :)
[11:13] <lool> 23     ogra@ub | if [ ! -f /usr/share/debootstrap/scripts/$DIST ];then
[11:13] <ogra> hrm
[11:13] <lool> committer: Oliver Grawert <ogra@ubuntu.com>
[11:13] <lool>   add a check if debootstrap supports $DIST, thanks to Erik Corry <erik.corry@gmail.com> for the fix !
[11:13] <ogra> oh, k
[11:13] <ogra> i think i got that one by mail
[11:14] <ogra> adn i think i'll just kill all the silly version checking then
[11:16] <lool> ogra: This check doesn't seem too bad though, what's the issue with it?
[11:16] <ogra> lool, nothing apart from bloating the code if we check for /usr/share/debootstrap/scripts/$DIST anyway
[11:17] <ogra> its kind of a duplication imho
[11:17] <lool> ogra: Where do you do that?  in build-arm-chroot?
[11:17] <ogra> rootstock
[11:17] <lool> So where is it duplicated?
[11:17] <ogra> if $(dpkg --compare-versions $DBSV lt $DEBOOTSTRAP_MIN_VER);then
[11:17] <ogra> vs
[11:18] <ogra>  if [ ! -f /usr/share/debootstrap/scripts/$DIST ];then
[11:18] <lool> The version check is the one I'd drop
[11:18] <ogra> right, thats what i said :)
[11:18] <lool> The data-driven check seems more future proof than a version requirement which will be out of date every release
[11:18] <ogra> right
[11:25]  * ogra -> break
[12:02] <cooloney> lool: i am downloading now.
[12:03] <cooloney> lool: it is 300M, need I append some zeroes? I don't understand heh
[12:06] <ogra> its an img not a rootfs
[12:06] <ogra> so to have more space on it you need to make it bigger by adding zero byte blocks and resize the partition
[12:07] <cooloney> ogra: got you. so normally how to do that : adding zero?
[12:07] <ogra> use dd
[12:16] <cooloney> ogra: dd conv=notrunc oflag=append if=/dev/zero of=rootfs.img bs=1M count=1024
[12:17] <cooloney> ogra: is this kind of command, right? add 1G zeroes at end of rootfs.img
[12:19] <ogra> cooloney, hmm, never used append, but if it does the same as skip and seek that should work
[12:19] <ogra> best to try it on a copy of the image i guess :)
[12:20] <cooloney> ogra: heh, right. hehe
[13:11] <lool> cooloney: That seems about right
[13:11] <lool> cooloney: Or just dd if=/dev/zero bs=something count=something >> rootfs.img
[13:12]  * ogra guesses cooloney would already have shouted and cired if it hadnt worked :)
[13:12] <ogra> *cried
[13:12] <lool> ogra: But it's actually a rootfs
[13:12] <lool> It's just that most people say rootfs when they mean rootfs tarball
[13:15] <ogra> well, one is an imag the other is the content of a filesystem
[13:15] <ogra> neither is named right anyway :)
[13:15] <ogra> since neither is actually a filesystem per se
[13:26] <lool> the rootfs.img is a filesystem
[13:26] <lool> i.e. root file system
[13:41] <lool> asac: is bug #474322 on your radar?
[13:41] <ubot4> Launchpad bug 474322 in linux-fsl-imx51 (Ubuntu Jaunty) (and 1 other project) "linux-image-2.6.28-16-imx51 appears broken on armel (affects: 1)" [Critical,Triaged] https://launchpad.net/bugs/474322
[13:41] <lool> it's from November and is a regression in a security update of the kernel in jaunty
[13:44] <lool> rcn-ee: Re: your qemu-arm-static -> qemu-kvm-extras-static issues: this should be fixed in latest versions
[13:44] <lool> rcn-ee: let me know if it isn't
[13:46] <lool> rcn-ee: Do you have a place where you publish your daily rootstock build logs, or is http://rcn-ee.homeip.net:81/dl/rootstock/ just updated manually?
[13:46] <lool> I wonder whether we should publish daily built rootfs like the UEC images
[13:47] <lool> I wonder why devtmpfs breaks for you
[13:49] <persia> rcn-ee: Regarding the "fixed" statement above, note that setuid binaries still won't work, but this is an inevitable consequence of how the emulation is done.
[13:51] <apw> ogra, lool, i've built some kernel .deb's for lool's versatile configuration changes, want to get some testing on them before i upload them; see the 13.18 kernels here: http://people.canonical.com/~apw/misc/arm/
[13:52] <ogra> apw, will test soon, thanks a lot
[14:00] <lool> apw: Tested with serial console, works fine up to a console login prompt
[14:03] <asac> cooloney: can you check the bug lool mentioned?
[14:03] <asac> 474322
[14:03] <asac> that is
[14:04] <asac> cooloney: seems it stopped working on bbg1 after security update... thanks!
[14:05] <lool> apw: Checking with graphics now (vga/fb video output)
[14:06] <lool> apw: Boots fine; NB: I just extracted the vmlinuz file and usese that
[14:06] <apw> ok
[14:07] <lool> apw: I don't think it's a regression, but I can't actually poweroff/reboot the system
[14:07] <rcn-ee> lool, yeap it looks fixed... (worked friday night when i was testing things for ogra)...  For reference my 'nightly' builds are here.. http://rcn-ee.homeip.net:81/dl/daily/ubuntu-lucid.log  i need to do a bzr pull thou, it's karmic + lucid tweak...
[14:07] <lool> The userspace bits seem to happen fine, but it doesn't actually reboot/stop
[14:07] <ogra> i think reboot never worked
[14:07] <ogra> at least with the archive kernels
[14:08] <persia> Is this an issue with qemu, or with the kernel?
[14:08] <apw> ok .. i guess i am trying to ensure its not a regressing kernel for you guys
[14:08] <lool> persia: I don't know, and it's a case where it's hard for me to tell
[14:08] <lool> I do see "Restarting" on the console, and then nothing happens
[14:08] <ogra> ah, no shutdown never worked for me ...
[14:08] <cooloney> asac: no problem, but I need to setup my bb1 board tomorrow.
[14:08] <lool> apw: I really don't think it's a regression, but I never paid attention
[14:08] <lool> apw: The current archive kernel doesn't work at all, so... :)
[14:09] <ogra> its very likely not a regression
[14:09] <apw> thats fine with me, as long as ogra is happy i'll call it good
[14:09] <ogra> apw, just upload, if it works for lool it will surely work for me too (i use way less features)
[14:10]  * ogra only needs ext2/NIC and serial console 
[14:12] <ogra> lool,  rm /bin/installer && reboot -fp ... thats in rootstock since day one ... i wouldnt have used -f if it would power doen properly
[14:12] <ogra> *down
[14:13] <ogra> not clear though if its qemu ...
[14:32] <ogra> weird, i cant get it to boot
[14:32] <ogra> it works if i dont use serial
[14:32] <ogra> apw, lool ^^^
[14:33]  * apw puts those changes on one side
[14:34] <ogra> hrm
[14:34] <ogra> if i add mem=256M to the append line it works
[14:37] <ogra> weird
[14:39] <persia> So it just can't handle much memory?  I thiought there was a patch for 512M (and seem to remember fiddling with it in jaunty)
[14:39] <ogra> no, its not that, i copied another append line that differs in ro vs rw and mem=256M
[14:40] <ogra> its not the mem but the ro/rw
[14:40] <ogra> it boots fine with ro
[14:40] <persia> Aha.
[14:40] <ogra> but not with rw
[14:40] <persia> Very odd.
[14:40] <ogra> apw, i can work around that in the script
[14:40] <ogra> so please upload
[14:40] <ogra> yes, odd indeed
[14:40] <apw> hrm, ok i suppose
[14:40] <lool> ogra: How much memory are you using?
[14:40] <ogra> lool, 256M
[14:40] <ogra> but see above
[14:41] <ogra> its not that
[14:41] <lool> That works for me without mem=
[14:41] <ogra> it seems it cant boot with rw on the cmdline
[14:41] <lool> qemu-system-arm -m 256  -drive file=rootfs.img,media=disk -M versatilepb -cpu cortex-a8 -kernel vmlinuz-2.6.32-13-versatile -append 'rootwait root=/dev/sda 2' is what I use
[14:41]  * ogra tries with dropping ro/rw completely 
[14:42] <ogra> [    5.451770] VFS: Mounted root (ext2 filesystem) readonly on device 8:0.
[14:42] <ogra> ok, it defaults to ro
[14:42] <ogra> lool, does it boot if you add rw ?
[14:42] <lool> Yes
[14:42] <ogra> for me it panics with "cant find rootfs"
[14:42] <lool> It works fine here
[14:43]  * ogra tries rootwait, probably a race 
[14:43] <lool> Err yes if you don't have a large rootdelay or rootwait it wont find your rootfs in time
[14:43] <lool> the scsi disk typically appears a couple of seconds after the kernel tries mounting the rootfs
[14:44] <ogra> [    5.430661] VFS: Cannot open root device "sda" or unknown-block(8,0)
[14:44] <ogra> [    5.430938] Please append a correct "root=" boot option; here are the available partitions:
[14:44] <ogra> nope
[14:44] <ogra> i usually dont need rootwait or anything ... never did
[14:45] <ogra> qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel tmp/boot/vmlinuz-2.6.32-13-versatile -hda /var/build/qemu-armel-201002081506.img -m 256 -nographic -append "console=ttyAMA0,115200n8 root=/dev/sda rootwait rw"
[14:45] <ogra> doesnt work
[14:45] <ogra> exactly the same line but dropping rw works
[14:46] <ogra> lool, can you try adding rw ?
[14:46] <lool> ogra: I already did
[14:47] <ogra> hmm
[14:47] <ogra> i wonder why it reliably breaks here
[14:47] <lool> Do you actually have read/write on /var/build/qemu-armel-201002081506.img?
[14:47] <ogra> heh
[14:47] <ogra> no, indeed
[14:47] <lool> pfff
[14:47]  * ogra re-adds the sudo bit to the README ...
[14:47] <lool> You don't need sudo to run qemu-system-arm
[14:47] <lool> Just move your images to your home
[14:48] <ogra> i just removed that from the rootstock doc ... now i remember again why i added it
[14:48] <lool> Advising sudo is actually dangerous
[14:48] <ogra> well, the image is created  as root
[14:48] <ogra> so owned by root
[14:48] <lool> Well you don't need to
[14:48] <lool> You just need to mount the file as root and run debootstrap as root, but you don't need to dd the file as root
[14:48] <ogra> i do
[14:49] <lool> Look, I just created this file as user
[14:49] <lool> And it worked
[14:49] <ogra> yes, but you dont use it loop mounted until you finished
[14:49] <lool> I sudo loop mount it
[14:49] <ogra> it is loop mounted during rootstock
[14:49] <lool> Yes, so $sudo loop mount it
[14:49] <ogra> hrm
[14:49] <lool> Here's an example script I use http://paste.ubuntu.com/371731/
[14:50] <lool> You can run it as root or not, it will call sudo when it needs to
[14:50] <ogra> thats ugly because i will pop passwd prompts all the time
[14:50] <persia> Actually, one should put a check on that class of script to fail if run as root (see mk-sbuild-lv for a nice check)
[14:50] <lool> There is some caching, so it will only prompt if it's too late; you can workaround that with a helper
[14:50]  * ogra sighs
[14:50] <lool> persia: That's an option; you can easily flip the check
[14:51] <ogra> i will not stop running the script as root
[14:51] <ogra> i want it to run automated if needed
[14:51] <lool> ogra: So run qemu-system-arm as root then, but don't advise people to do so by default
[14:51] <lool> ogra: So how are you going to automate running your script as root?
[14:51] <ogra> yeah, i'll add inof the the doc
[14:52] <ogra> i dont, users do
[14:52] <ogra> and they usually set up root cronjobs
[14:52] <ogra> i'll just add info to the doc ... i wont scatter sudo calls across the script
[14:59] <lool> did you actually read the link?
[14:59] <lool> it doesn't call sudo if called as root...
[15:01] <ogra> i have the very same check in rootstock ... just not the $sudo var
[15:02]  * ogra curses about broken userspace
[15:02] <ogra>  * Starting init crypto disks...                                         [ OK ]
[15:02] <ogra> hangs :(
[15:02] <ogra> silly ubiquity -> oem-config merge
[15:03] <ogra> pulls in half the world and breaks ... old oem-config worked
[15:03] <ogra> and didnt pull in many deps
[15:05] <ogra> if [ $(id -u) != 0 ];then
[15:05] <ogra>     echo "must be run as root"
[15:05] <ogra>     exit 2
[15:05] <ogra> fi
[15:05] <ogra> lool, ^^^ fyi
[15:53] <ogra> bah, so oem-config goes into an endless loop on my rootstock image
[17:41] <ogra> i think we need to forget about oem-config usage in rootstock thats way to messed up and only focused on d-i installs it seems
[17:41] <ogra> s/d-i/d-i or ubiquity/
[17:42] <ogra> the ui requires metacity which in turn pulls in 400M of deps
[17:42] <ogra> the debconf frontend doesnt finish and goes into an endless loop
[17:46] <ogra> ah, well, without recommends its less but still 30MB
[17:51] <cwillu_at_work> rcn-ee, had disk transfers running over the weekend on that kernel, no random usb reconnects or errors that I can see
[17:51] <cwillu_at_work> rcn-ee, i.e., looks great :)
[18:28] <ogra> lool, hmm, did you try running any X programs in qemu yet ?
[18:28] <ogra> specifically pygtk stuff
[18:28] <ogra> seems to fail pretty badly here
[18:31] <ogra> ugh, even metacity
[18:47] <ogra> i dont think its actually happy with the faked cortex-a8
[18:53] <ogra> hmm, cpuinfo thinks its capable of thumb and neon
[19:00]  * ogra calls it a day
[22:25] <lool> persia: According to linux/Documentation/binfmt_misc.txt, one can set a flag to preserve the original security bits of a program
[22:25] <lool> persia: It changes the calling convention though, so I don't think it would work with out current qemu-system-arm
[22:25] <persia> lool: Cool!
[22:26] <persia> Aha.
[22:38] <persia> lool: Reading the docs, I'm not sure I understand why we can't just pass the 'C' flag and have it work.
[22:38] <lool> persia: Because it doesn't pass a real file to the qemu-arm command-line
[22:38] <persia> It is because of the implied 'O'?
[22:39] <lool> persia: Currently, when the binfmt hook is triggered for e.g. /bin/sh, what happens is that the kernel calls qemu-arm /bin/sh
[22:39] <lool> persia: Yes
[22:39] <persia> Ah, so we'd need to modify qemu-arm-static to take file descriptors rather than file names.
[22:40] <lool> Yes
[22:40] <lool> Or have a wrapper
[22:41] <persia> A wrapper can do FD -> path changes?
[22:42] <persia> That's more shell than I know, or do you mean a compiled wrapper?
[22:50] <persia> lool: Reading the docs more carefully, I think we do want to change the calling convention.  I can well imagine cases where a user wants to execute a file to which that user doesn't have read access when dealing with nested chroots, etc.
[22:51] <persia> But I'm entirely unsure how to do that with a wrapper: I suspect it needs changes to qemu-arm-static itself.  I'd appreciate any pointers if you have them.
[22:57] <lool> persia: I'm trying to write such a wrapper, but I fail miserably
[22:58] <lool> When trying to run my x86-64 static wrapper under an armel chroot I get: Error -8 while loading /usr/bin/qemu-arm-static
[22:59] <lool> persia: I think we would just need a wrapper which passes /dev/fd/N to qemu-system-arm, but I'm not sure; that's what I wanted to verify
[22:59] <lool> But in the end we would likely patch qemu
[23:00] <persia> I thought that /dev/fd/N was defined on a per-process basis.
[23:00] <lool> It is  :-)
[23:01] <persia> In that case, we can't pass it to a new process :)
[23:01] <persia> So a qemu patch *is* required.
[23:01] <lool> persia: exec is the same process
[23:01] <lool> I think my exec doesn't work because it needs to be handled by binfmt
[23:02] <persia> Hrm?
[23:03] <lool> persia: exec() is implemented with binfmt, if my wrapper called from binfmt tries to exec it wont work (well that's my guess)
[23:03] <lool> not sure it's correct
[23:04] <lool> Another static utility which just puts() argv / argc works, so it's not my build
[23:04]  * lool will check this out tomorrow &
[23:04] <persia> Have a good night :)