Re: [Qemu-devel] [Bug 902306] [NEW] qemu-user -static variants require shared libraries

2011-12-16 Thread Vagrant Cascadian 
On Fri, Dec 09, 2011 at 08:20:16PM -, Michael Roth wrote:
 On 12/09/2011 01:39 PM, Vagrant Cascadian wrote:
 
  /usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o):
   In function `g_get_any_init_do':
 (.text+0xbbb): warning: Using 'getpwuid_r' in statically linked 
  applications requires at runtime the shared libraries from the g
 libc version used for linking
 
  for a full log, see:
 
 We introduced a glib2.0 dependency in QEMU 0.15. I think this just a 
 result of glib introducing a much larger static build chain dependency. 

it works fine with qemu 0.15.1, even when built with the same versions of 
glib2.0 as as qemu 1.x branches. so that would seem a bit odd... unless qemu 
1.x is using more of glib2.0 than qemu 0.15.

would that then essentially come down to tracking down all of glib2.0's build 
dependencies and installing those as well?


 I'm not sure if glib can be decoupled for usermode emulation, those it 
 at least seems to have escaped the malloc()-g_malloc() conversion so 
 maybe there were plans for that...
 
 But currently at least it's considered a hard general dependency.

hrm. would like to see it working again, though it's a bit over my head.


live well,
  vagrant

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/902306

Title:
  qemu-user -static variants require shared libraries

Status in QEMU:
  New
Status in “qemu” package in Debian:
  New

Bug description:
  somehwere in the qemu 1.0 series, the qemu-user static  variants
  started issuing build warnings like so:


/usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o):
 In function `g_get_any_init_do':
(.text+0xe37): warning: Using 'getpwuid' in statically linked applications 
requires at runtime the shared libraries from the gli
bc version used for linking

/usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o):
 In function `g_get_any_init_do':
(.text+0xe2a): warning: Using 'setpwent' in statically linked applications 
requires at runtime the shared libraries from the gli
bc version used for linking

/usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o):
 In function `g_get_any_init_do':
(.text+0xe40): warning: Using 'endpwent' in statically linked applications 
requires at runtime the shared libraries from the gli
bc version used for linking

/usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o):
 In function `g_get_any_init_do':
(.text+0xb7a): warning: Using 'getpwnam_r' in statically linked 
applications requires at runtime the shared libraries from the g
libc version used for linking

/usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o):
 In function `g_get_any_init_do':
(.text+0xbbb): warning: Using 'getpwuid_r' in statically linked 
applications requires at runtime the shared libraries from the g
libc version used for linking

  for a full log, see:

  
https://buildd.debian.org/status/fetch.php?pkg=qemuarch=amd64ver=1.0~rc4%2Bdfsg-1stamp=1322591568

  i've also tested with qemu/master from today (commit
  217bfb445b54db618a30f3a39170bebd9fd9dbf2), and it has the same issue.

  This seems to cause adduser, addgroup, etc. to fail in cross-
  architecture chroots that use statically built qemu-user binaries to
  emulate the foreign architecture.

  Older versions (0.12-0.15, at least) didn't seem to have this issue.

  live well,
vagrant

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/902306/+subscriptions

[Qemu-devel] [Bug 902306] [NEW] qemu-user -static variants require shared libraries

2011-12-09 Thread Vagrant Cascadian 
Public bug reported:

somehwere in the qemu 1.0 series, the qemu-user static  variants started
issuing build warnings like so:

  
/usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o):
 In function `g_get_any_init_do':
  (.text+0xe37): warning: Using 'getpwuid' in statically linked applications 
requires at runtime the shared libraries from the gli
  bc version used for linking
  
/usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o):
 In function `g_get_any_init_do':
  (.text+0xe2a): warning: Using 'setpwent' in statically linked applications 
requires at runtime the shared libraries from the gli
  bc version used for linking
  
/usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o):
 In function `g_get_any_init_do':
  (.text+0xe40): warning: Using 'endpwent' in statically linked applications 
requires at runtime the shared libraries from the gli
  bc version used for linking
  
/usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o):
 In function `g_get_any_init_do':
  (.text+0xb7a): warning: Using 'getpwnam_r' in statically linked applications 
requires at runtime the shared libraries from the g
  libc version used for linking
  
/usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o):
 In function `g_get_any_init_do':
  (.text+0xbbb): warning: Using 'getpwuid_r' in statically linked applications 
requires at runtime the shared libraries from the g
  libc version used for linking

for a full log, see:

https://buildd.debian.org/status/fetch.php?pkg=qemuarch=amd64ver=1.0~rc4%2Bdfsg-1stamp=1322591568

i've also tested with qemu/master from today (commit
217bfb445b54db618a30f3a39170bebd9fd9dbf2), and it has the same issue.

This seems to cause adduser, addgroup, etc. to fail in cross-
architecture chroots that use statically built qemu-user binaries to
emulate the foreign architecture.

Older versions (0.12-0.15, at least) didn't seem to have this issue.

live well,
  vagrant

** Affects: qemu
 Importance: Undecided
 Status: New

** Affects: qemu (Debian)
 Importance: Unknown
 Status: Unknown

** Bug watch added: Debian Bug tracker #651083
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651083

** Also affects: qemu (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651083
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/902306

Title:
  qemu-user -static variants require shared libraries

Status in QEMU:
  New
Status in “qemu” package in Debian:
  Unknown

Bug description:
  somehwere in the qemu 1.0 series, the qemu-user static  variants
  started issuing build warnings like so:


/usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o):
 In function `g_get_any_init_do':
(.text+0xe37): warning: Using 'getpwuid' in statically linked applications 
requires at runtime the shared libraries from the gli
bc version used for linking

/usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o):
 In function `g_get_any_init_do':
(.text+0xe2a): warning: Using 'setpwent' in statically linked applications 
requires at runtime the shared libraries from the gli
bc version used for linking

/usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o):
 In function `g_get_any_init_do':
(.text+0xe40): warning: Using 'endpwent' in statically linked applications 
requires at runtime the shared libraries from the gli
bc version used for linking

/usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o):
 In function `g_get_any_init_do':
(.text+0xb7a): warning: Using 'getpwnam_r' in statically linked 
applications requires at runtime the shared libraries from the g
libc version used for linking

/usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o):
 In function `g_get_any_init_do':
(.text+0xbbb): warning: Using 'getpwuid_r' in statically linked 
applications requires at runtime the shared libraries from the g
libc version used for linking

  for a full log, see:

  
https://buildd.debian.org/status/fetch.php?pkg=qemuarch=amd64ver=1.0~rc4%2Bdfsg-1stamp=1322591568

  i've also tested with qemu/master from today (commit
  217bfb445b54db618a30f3a39170bebd9fd9dbf2), and it has the same issue.

  This seems to cause adduser, addgroup, etc. to fail in cross-
  architecture chroots that use statically built qemu-user binaries to
  emulate the foreign architecture.

  Older versions (0.12-0.15, at least) didn't seem to have this issue.

  live well,
vagrant

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/902306/+subscriptions

[Qemu-devel] Patch: fix typo: runnning - running

2011-11-07 Thread Vagrant Cascadian 
One n too many for running, need we say more.

Signed-Off-By: Vagrant Cascadian vagr...@freegeek.org

Index: qemu/target-i386/kvm.c
===
--- qemu.orig/target-i386/kvm.c 2011-07-02 21:25:10.0 -0700
+++ qemu/target-i386/kvm.c  2011-07-02 21:25:20.0 -0700
@@ -1537,7 +1537,7 @@
 code);
 if (host_supports_vmx()  code == VMX_INVALID_GUEST_STATE) {
 fprintf(stderr,
-\nIf you're runnning a guest on an Intel machine without 
+\nIf you're running a guest on an Intel machine without 
 unrestricted mode\n
 support, the failure can be most likely due to the guest 
 entering an invalid\n


live well,
  vagrant

Re: [Qemu-devel] Bug#632192: [PATCH] add QEMU_LD_PREFIX environment variable

2011-07-29 Thread Vagrant Cascadian 
On Thu, Jul 28, 2011 at 11:41:09AM +0300, Riku Voipio wrote:
 On Sat, Jul 23, 2011 at 07:47:49AM +0200, josch wrote:
  This could be avoided by setting the proposed environment variable 
  QEMU_LD_PREFIX to the just
  created debian rootfs. As mentioned earlier, the usage of the -L option
  is not possible in this scenario because qemu-user is only implicitly
  called by the binfmt mechanism.
 
 What worries me here is that we are beginning to add a enviroment variable
 for each and every command line option of qemu linux-user. I think it would
 be better to have a wrapper binary to be registered as the binfmt runner.

setting up a wrapper makes trivial cross-architecture chroots harder as you'll 
have to copy two binaries into the chroot, and i'm not sure if it would work at 
all, as the wrapper will need to somehow emulate it's own interpreter...


 Alternatively we should have a generic setup for mapping enviroment variables
 to command line options. Now we get special per-option code every time 
 someone 
 needs to setup a command line option from binfmt.

this would seem a bit better alternative to me...


live well,
  vagrant

[Qemu-devel] spelling typo (runnning) in target-i386/kvm.c

2011-07-03 Thread Vagrant Cascadian 
fix spelling typo (runnning) in target-i386/kvm.c

Signed-Off-By: Vagrant Cascadian vagr...@freegeek.org

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 10fb2c4..3f5caee 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -1801,7 +1801,7 @@ int kvm_arch_handle_exit(CPUState *env, struct kvm_run 
*run)
 code);
 if (host_supports_vmx()  code == VMX_INVALID_GUEST_STATE) {
 fprintf(stderr,
-\nIf you're runnning a guest on an Intel machine without 
+\nIf you're running a guest on an Intel machine without 
 unrestricted mode\n
 support, the failure can be most likely due to the guest 
 entering an invalid\n

[Qemu-devel] Re: Bug#592875: pxelinux: incompatible with qemu with kvm enabled

2010-08-24 Thread Vagrant Cascadian 
it seems versions of pxelinux 4.00 and later hangs qemu (0.12.x, 0.13.x) when
network booting using etherboot or gPXE and qemu's kvm support is enabled.

pxelinux 3.86 and earlier do not appear to trigger the problem. i also didn't
experience the problem with qemu-kvm (formerly known as kvm). qemu without kvm
support enabled also seems to work fine.

for more details, please see:

  http://bugs.debian.org/592875
  http://bugs.debian.org/591934

thanks!

live well,
  vagrant

[Qemu-devel] merge spelling typo into stable-0.12

2010-06-29 Thread Vagrant Cascadian 
please consider merging from master into stable-0.12:

 commit f093feb735ab57171b6fe16f54b7d3b989907d98
 Author: Vagrant Cascadian vagr...@freegeek.org
 Date:   Fri Feb 26 13:39:46 2010 -0800

audio/alsa: Spelling typo (paramters)

Trivial patch to fix the spelling of parameters.

Signed-off-by: malc av1...@comtv.ru

thanks!

live well,
  vagrant

[Qemu-devel] manpage errors

2010-03-13 Thread Vagrant Cascadian 
On Sat, Mar 13, 2010 at 01:05:03PM +0200, Blue Swirl wrote:
 On 3/12/10, Vagrant Cascadian vagr...@freegeek.org wrote:
   i found this spelling typo and the previous one by running lintian on the 
  qemu
   packages i work on for debian:
 
   
  http://lintian.debian.org/full/pkg-qemu-de...@lists.alioth.debian.org.html#qemu

 Perhaps the manual page errors should be fixed too,

i did look into that a bit, though it is a little tricky because it's got the
qemu-doc.texi and qemu-options.texi (texinfo?) layer of abstraction. for the
full details:

  LANG=C MANWIDTH=80 man --warnings -E UTF-8 -l ./qemu.1 /dev/null
  standard input:730: warning [p 9, 4.8i, div `an-div', 0.2i]: can't break 
line
  standard input:730: warning [p 9, 5.0i]: can't break line
  standard input:735: warning [p 9, 5.8i, div `an-div', 0.2i]: can't break 
line
  standard input:735: warning [p 9, 6.0i]: can't break line
  standard input:869: warning [p 11, 5.2i, div `an-div', 0.2i]: can't break 
line
  standard input:869: warning [p 11, 5.3i]: can't break line
  standard input:890: warning [p 11, 8.3i, div `an-div', 0.2i]: can't break 
line
  standard input:890: warning [p 11, 8.5i]: can't break line
  standard input:953: warning [p 12, 5.8i, div `an-div', 0.2i]: can't break 
line
  standard input:953: warning [p 12, 6.0i]: can't break line
  standard input:1732: warning [p 22, 1.8i, div `an-div', 0.2i]: can't break 
line
  standard input:1732: warning [p 22, 2.0i]: can't break line
  
the generated manpage has several lines longer than 80 characters describing
commandline arguments, such as:

   -smbios
   
type=1[,manufacturer=str][,product=str][,version=str][,serial=str][,uuid=uuid][,sku=str][,family=str]
   Specify SMBIOS type 1 fields
...
   -net
   
nic[,vlan=n][,macaddr=mac][,model=type][,name=name][,addr=addr][,vectors=v]

and so on...

i don't know if there is a way to more succinctly describe those options that
gets all the details... or an easy way to generate the manpage to fix the
formatting issues with those long lines.

live well,
  vagrant

Re: [Qemu-devel] spelling typo (compatibilty) in hw/fw_cfg.c

2010-03-13 Thread Vagrant Cascadian 
On Sat, Mar 13, 2010 at 01:05:03PM +0200, Blue Swirl wrote:
 On 3/12/10, Vagrant Cascadian vagr...@freegeek.org wrote:
  here's a trivial patch to fix the spelling of compatibility:
 
 Please add a Signed-off-by: line.

hope this is what you're looking for:

Signed-off-by: Vagrant Cascadian vagr...@freegeek.org

 
   diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
   index fe6c543..22ebb50 100644
   --- a/hw/fw_cfg.c
   +++ b/hw/fw_cfg.c
   @@ -179,7 +179,7 @@ static int get_uint32_as_uint16(QEMUFile *f, void *pv, 
  size_t size)
 
static void put_unused(QEMUFile *f, void *pv, size_t size)
{
   -fprintf(stderr, uint32_as_uint16 is only used for backward 
  compatibilty.\n);
   +fprintf(stderr, uint32_as_uint16 is only used for backward 
  compatibility.\n);
   fprintf(stderr, This functions shouldn't be called.\n);
}

live well,
  vagrant

[Qemu-devel] spelling typo (compatibilty) in hw/fw_cfg.c

2010-03-12 Thread Vagrant Cascadian 
here's a trivial patch to fix the spelling of compatibility:

diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index fe6c543..22ebb50 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -179,7 +179,7 @@ static int get_uint32_as_uint16(QEMUFile *f, void *pv, 
size_t size)

 static void put_unused(QEMUFile *f, void *pv, size_t size)
 {
-fprintf(stderr, uint32_as_uint16 is only used for backward 
compatibilty.\n);
+fprintf(stderr, uint32_as_uint16 is only used for backward 
compatibility.\n);
 fprintf(stderr, This functions shouldn't be called.\n);
 }


i found this spelling typo and the previous one by running lintian on the qemu
packages i work on for debian:

http://lintian.debian.org/full/pkg-qemu-de...@lists.alioth.debian.org.html#qemu

live well,
  vagrant

[Qemu-devel] spelling typo (paramters) in audio/alsaaudio.c

2010-02-28 Thread Vagrant Cascadian 
here's a trivial patch to fix the spelling of parameters:

diff --git a/audio/alsaaudio.c b/audio/alsaaudio.c
index 7698d10..6a9b87a 100644
--- a/audio/alsaaudio.c
+++ b/audio/alsaaudio.c
@@ -665,7 +665,7 @@ static int alsa_open (int in, struct alsa_params_req *req,
 (obt-fmt != req-fmt ||
  obt-nchannels != req-nchannels ||
  obt-freq != req-freq)) {
-dolog (Audio paramters for %s\n, typ);
+dolog (Audio parameters for %s\n, typ);
 alsa_dump_info (req, obt);
 }


live well,
  vagrant