Hi,
On 3/8/06, Guillem Jover <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 07, 2006 at 04:53:56PM -0400, Anderson Lizardo wrote:
> > New patch with some more bugs fixed, including a bugfix from Ulrich
> > Hecht, not in QEMU CVS yet.
>
> I'm aware of this bug fix, it has hit me when using sbox, so it's
> going to be in next release.
Ok. I'll post a different bug report for this issue then, so it does
not get forgotten :)
> > I'm also increasing bug severity to "important" as (1) there is a
> > patch available, so it's not a "wishlist" anymore and (2) the patch
> > has some fixes for real bugs included.
>
> No, that's wrong, a bug does not stop being wishlist because it gets a
> patch. And you should not try to sneak in unrelated and cosmetical
> changes into an existing bug report. For new stuff, please file new
> bug reports. I can agree though that the arm floating point comparision
> could be important.
Sorry about that. I think I have missunderstood the "severity" field meaning.
I'll issue separate bug reports for the different fixes/features (with
patches attached). BTW, is there any estimate date for the next
revision release? So I could prepare the patches before that date.
> > * Add build-stamp target to workaround "patch" target bug where "build" is
> > run twice.
>
> patch has already its own stamp file, and I prefer not to have build
> stamp files, otherwise you may modify something and it does not get
> rebuilt.
Sure, but there is an disavadvange of not having a build-stamp: the
"build" target is always run twice, once when dpkg-buildpackage runs
"./debian/rules build" and then again when running "./debian/rules
binary" (which depends on build). It's just not noticed because the
second "make" will usually have nothing to do.
This is really an issue when you create -static flavors of the
package, because the second run will overwrite the statically linked
binaries before they even get installed. Another (and better IMHO)
option would be to have the qemu source as a tarball that is unpacked
before running configure, just like the gcc source package. This way
each build "flavor" (static/shared) gets it's own tree and they don't
overwrite each other results. And more: the "clean" target becomes a
simple rm -rf of the build tree(s).
> > * Add binfmt-support hooks, allowing "transparent" user emulation. Idea
> > borrowed from qemu-binfmt-conf.sh.
>
> I don't like the way it's implemented, hardcoding the binary list is
> prone to error, and the handling code for binfmt files could be greatly
> reduced.
You mean having all those *.binfmt files in the debian/ directory?
Actually, those were created by running this awk script:
awk -F: '/echo/{printf "cat > qemu-"$2".binfmt << \"EOF\"\npackage
qemu\ninterpreter "$7"\nmagic "$5"\nmask "$6"\nEOF\n\n"}'
qemu-binfmt-conf.sh
It generates a script that can be piped to "bash" to generate the files.
Regarding the postinst and prerm scripts, they can indeed be
simplified by assuming all /usr/share/binfmts/qemu-* files were
installed by qemu.
> > * Change default interpreter prefix to match dpkg-cross crossdir.
>
> This should probably be in accordance with the multi-arch proposal
> instead.
Sorry, I'm still new to the Debian development discussions... What
would be that "multi-arch proposal" ? Something like /lib64 for AMD64
? If so, It would in fact only work for those architectures where this
is supported (basically 32/64-bit variations).
The basic idea behind setting the default interpreter prefix to the
same as dpkg-cross basedir is to facilitate running binaries from
totally different architectures, e.g. run ARM binaries on i386
transparently, mainly because dpkg-cross greatly helps installing
non-native .deb's in a base directory suitable for using with qemu
user mode emulators. See http://wiki.debian.org/QemuUserEmulation for
an example of how easy that could be.
> > * Add qemu-user-static package.
>
> But I'm not yet sure about providing the static binaries. It makes
> security support harder in case of bugs found in linked libraries
> for example.
Well, I surely agree on the security issues, but see these points:
- qemu-user-static contains only the user mode emulators, not the
system ones (qemu-system-*)
- qemu-$CPU binaries depend on few libraries (actually only standard
glibc libraries as seen by ldd).
- in order to use qemu emulation inside a non-native chroot (necessary
for cross-debootstrapping, for example), it needs to be statically
linked. Otherwise it would try to load libraries from /lib which are
actually non-native libraries. I've tried using some LD_LIBRARY_PATH
hacks, but they are not as effective as I would want.
Thanks,
--
Anderson Lizardo
Embedded Linux Lab - 10LE
Nokia Institute of Technology - INdT
Manaus - Brazil
