[17:51] <persia> lool: I picked Recommends because I thought most people *should* builde for armel :)  Did you manage to fix the issue with the conflicting binfmt-misc handlers?
[18:20] <lool> persia: I think so
[18:20] <lool> persia: The issue was one present before the rename, but becoming serious after the rename
[18:21] <persia> Aha.  I'm just installing the latest version, and will confirm then :)
[18:21] <lool> persia: The handler was registered on postinst/configure and unregistered in prerm/remove instead of postinst/install prerm/remove or postinst/configure and prerm/upgrade
[18:21] <lool> (Hope I'm making sense)
[18:22] <persia> Right.  That would explain all sorts of things :)  Sometimes I wish maintainer scripts weren't quite so complex, because more people might get them right the first time :)
[18:22] <lool> Sadly, I can't retrofix the qemu-arm-static packages, but I've added qemu-arm-static.postinst and qemu-kvm-extras-static.postinst configure snippets to remove the old name
[18:23] <lool> I didn't really test an old qemu-arm-static -> new world full upgrade though; if you do that, I'd love to hear the results
[18:23] <persia> I can't easily test the full upgrade, but I may be able to figure out a way.
[18:23] <persia> I can test broken -> fixed.
[18:24] <persia> Would a karmic -> lucid upgrade do it for the full upgrade case?
[18:25] <lool> Yes
[18:25] <lool> Or simply, removing everything, manually installing an old lucid qemu-arm-static and upgrading
[18:26] <persia> That's fairly trivial to do then: I can just install the karmic qemu-arm-static in a lucid chroot and dist-upgrade.
[18:27] <persia> Separately, I was thinking: would it make sense to use build-cross-chroot rather than build-arm-chroot, and then try to encourage enabling other architectures?
[18:27] <persia> I hear qemu powerpc is getting there, although sparc and ia64 probably need some work.
[18:28] <persia> My thought was that it would be nifty if developers could work on most architectures for most purposes from an amd64 install.
[18:28] <lool> persia: Ack, I don't like "-arm-" in "build-arm-chroot"
[18:28] <lool> I think qemu-debootstrap would be a better name for it
[18:29] <persia> I'd be happy with that name.
[18:29] <persia> Note that it's not currently command-line compatible with debootstrap.  Specifically, `debootstrap --arch armel` works, but `build-arm-chroot --arch armel` doesn't.
[18:30] <persia> Both also work with "--arch=armel", but that's a separate case :)
[18:30] <persia> I've just upgraded from a broken system, and I still get "sudo: must be setuid root".
[18:30] <lool> or qemu-debootstrap-helper, but I would call it qemu-debootstrap and fix it to be compatible
[18:30] <lool> persia: Oh sudo is unrelated
[18:30] <persia> If you would, that would be great.
[18:31] <persia> Um, sudo is the problem I had, which ogra convinced me was related to the binfmt issue.
[18:31] <persia> What's the sudo issue?
[18:31] <lool> If you try running sudo with binfmt, the kernel will run qemu-arm-static which doesn't have the SUID bit set
[18:31] <lool> It can't work
[18:32] <lool> persia: Check whether you have one and only one arm entry in /var/lib/binfmt* and /proc/sys/filesystems/binfmt*/
[18:32] <lool> The entry should be qemu-arm
[18:32] <lool> /var/lib/binfmts/qemu-arm and /proc/sys/fs/binfmt_misc/qemu-arm
[18:33] <persia> I do only have one of those.
[18:34] <lool> You have both and these are named qemu-arm though?
[18:35] <lool> If you do, then your system is correctly configured
[18:35] <persia> Right, but I still can't run sudo in my chroot, which was the original issue that brought the other to my attention.
[18:35] <persia> Any ideas?
[18:36] <lool> persia: I don't think that can work
[18:36] <lool> persia: Just avoid using sudo
[18:36] <lool> chroot as root and continue running stuff as root
[18:37] <persia> Why can't it work?  Works for all my other chroots.
[18:37] <lool> Because the kernel runs a single binary for all binaries you run
[18:37] <lool> You could make qemu-arm-static suid root, but that would be a huge security hole
[18:38] <persia> Ah, I get it.  I swear it worked on Tuesday, but maybe I did something else.
[18:38] <persia> It's probably worth noting that in a README somewhere, so people don't file bugs.
[18:38] <lool> persia: You might be able to run sudo as root
[18:39] <persia> That's probably it.
[18:39] <persia> my chroots were in a very primitive state on Tuesday.
[18:39] <persia> Anyway, I have to head off for a bit.  Thanks a lot for explaining my issue.
[18:39] <lool> np, do feel free to pass the info to ogra   :-)
[18:40] <persia> ogra: ^^
[18:40]  * ogra reads it ... i'm just in fuzzy jetlag state 
[18:41] <lool> Ok, I give up trying to get virtio-pci to work under versatile
[18:41] <lool> It seems versatile has a very specific IRQ handling which might mess this up anyway
[18:49] <ogra> lool, did andy talk to you ? seems your patch didnt build at all
[18:50] <ogra> for now i asked him to just change the two config options you mentioned in the bug
[18:59] <lool> ogra: ?
[18:59] <lool> ogra: I talked to apw on #ubuntu-kernel; the kernel certainly built for me, as well as the modules
[18:59] <lool> I didn't build .debs though, so there might be some ABI issues
[19:00] <ogra> he said it exploded in his face on the first modules it tried to build
[19:00] <ogra> and said your patch changed more than just the two config options
[19:06] <lool> ogra: Which patch?
[19:07] <lool> Anyway, this is out of date, he merged my work AFAIK
[19:07] <ogra> i think he said you gave him a git tree or something ?
[19:07] <ogra> well, he said he didnt when we talked last night before i flew out
[19:07] <ogra> since it failed to build
[19:08] <lool> I attached a patch to the bug and the first commits of the git tree were to fix the lucid tree and then my patch
[19:08] <lool> Followed by large config updates in a separate patch
[19:08] <lool> That built for me, and he merged it
[19:08] <ogra> weird, he said it didnt
[19:08] <lool> He then decided to merge the updates in a single patch
[19:08] <lool> Check the tree yourself
[19:08] <lool> I certainly saw it merged
[19:09] <ogra> intresting
[19:10] <ogra> i only see the binutils.bin fix in the last upload
[19:10] <lool> It's in the git tree, not in the source package
[19:11] <ogra> right, because it made the package ftbfs according to him
[19:21] <persia> lool: Maybe it's because I'm in a chroot, but installing karmic qemu-arm-static in my lucid chroot creates double entries for me in /proc/sys/fs/binfmt_misc/*.  dist-upgrading fixes it.
[19:26] <lool> persia: Yes, if you have it in the host, you'll see the entry in the chroot
[19:26] <lool> However if you add it in the chroot, it wont be visible in the host
[19:26] <lool> Can't believe lucid kexec-tools doesn't allow armv7l...
[19:26] <persia> Well, kinda.  That was my experience for /var/lib/bin... but I seem to have the same /proc in and out of the chroot.
[19:26] <ogra> lool, huh ? we fixed that in jaunty ?
[19:27] <persia> NCommander was saying that kexec() hung his hardware.
[19:27]  * ogra clearly remembers he added a patch to kexec-tools
[19:27] <ogra> hmm, but that might have been before the disastrous repackaging that lieb did
[19:28] <persia> You might want to reinvestigate
[19:28] <ogra> it wont apply anymore, the packaging lieb did isnt even remotely related to the debian packaging
[19:29] <ogra> he just took the latest upstream source and ran dh-make on it
[19:29] <persia> Can we just purge dh-make already?
[19:30] <ogra> and then copied all patches into debian/patches in case someone wants to re-apply (which indeed wouldnt work at all)
[19:30] <ogra> (IIRC)
[19:30] <persia> Right.  That deserves an investigation to reclose n bugs.
[19:31] <lool> kexec-tools 2.0.1 fixes it though
[19:32] <ogra> did you reverse the mess ?
[19:32] <lool> I'm just reading the source
[19:33] <lool> lp:debian/kexec-tools and lp:ubuntu/kexec-tools don't relate at all, yeah
[19:33] <lool> haha I'm the one who uploaded the kexec-tools patch in jaunty
[19:34] <lool> actually I uploaded it to unstable
[19:34] <lool> http://paste.ubuntu.com/371141/
[20:13] <lool> I pushed the new upstream release
[20:13] <ogra> great
[20:13] <ogra> to sad kexec is still broken in all supported kernels
[20:13] <ogra> (we tested it last week)
[20:15] <lool> How did it run last week?
[20:15] <ogra> quit good progress on the specs
[20:16] <ogra> we actually managed to get the workitem tracker to show green under the trendline :)
[20:16]  * ogra only has 4 items left in total and only tw in rootstock
[20:16] <ogra> *two
[20:17] <ogra> the marvell issue was kind of eating the first half of the week though
[20:18] <lool> Let me reword my question: how could you test kexec last week since it doesn't run for utsname == armv7l?
[20:19] <ogra> hmm, ask NCommander :P he did the tests on both arches
[20:19] <ogra> i only saw it hanging when looking over his sholder
[20:19] <ogra> i guess he has to retest then tomorrow
[20:20] <ogra> thanks for pointing that out, i was expecting he had checked that before
[20:21] <ogra> ah ...
[20:21]  * ogra feels relief that jackd gets removed with the most recent upgrade
[20:21] <ogra> and off to reboot ...
[20:26] <ogra> hmm, my boot got slower http://people.canonical.com/~ogra/osiris-lucid-20100207-3.png
[20:30] <persia> That's expected.  Remember that the target is 10 seconds, not 8.
[20:30] <ogra> well, my system is usually a few seconds faster than the average HW
[20:45] <lool> New kexec still doesn't take armv7l, odd
[20:48] <lool> Bah I thought it was in 2.0.1 because Debian had 2.0.1 and had it, but it's not
[20:48] <lool> (and upstream had it too)
[20:48] <lool> it was committed after 2.0.1
[20:53] <ogra> smells like another upload :)
[21:12] <lool> Ok, at least the new kexec crashes instead of refusing to run
[21:31] <lool> After the last fix, it does *something*
[21:31] <lool> "Starting new kernel
[21:31] <persia> That was the behaviour NCommander reported last week.  At which point it hung.
[21:32] <lool> I see 100% CPU consumption from qemu
[21:32] <persia> Matches the previous report :)
[21:32] <lool> oddly, the versatile .deb build fails for me with /home/lool/qemu-versatile/linux-qemu/drivers/scsi/advansys.c:8352: error: implicit declaration of function 'dma_cache_sync'
[21:32] <lool> But only the debian way
[21:33] <lool> with the upstream make zImage and make modules, it builds
[21:34] <lool> I guess it's just not fatal for the upstream build, hmm
[22:01] <lool> I filed LP #518567 on the kexec issue
[22:01] <ubot4> Launchpad bug 518567 in linux (Ubuntu) (and 1 other project) "armel/versatile: Can't kexec (affects: 1)" [Undecided,New] https://launchpad.net/bugs/518567
[22:01] <lool> Got further by using a serial console
[22:19] <lool> Sent versatile fixes to kernel-team@ list