similar to: Bug#401118: xen-utils-common: xm(1) manual lists incorrect mode parameter options

Package: xen-utils-common Version: 3.0+hg11292-2 Tags: patch User: initscripts-ng-devel at lists.alioth.debian.org Usertags: incorrect-dependency When testing dependency based boot sequencing, I discovered a bug in the init.d script for xen-utils-common. It is set to stop in the boot "runlevel" (S), but no script should stop there. Also, xend only depend on $local_fs, but

I had to apply this patch to configure.in to get configure to run on Tru64 Unix on Alpha. The RSA test forgot to reset $LIBS. (The compile stopped with missing "zlib.h". I'll send more patches if required. :-) diff -ur src-2.9p1/configure.in src-2.9p1-local/configure.in --- src-2.9p1/configure.in Wed Jun 6 17:15:09 2001 +++ src-2.9p1-local/configure.in Wed Jun 6

Alan Coopersmith (1): Fix --with-default-config to work with more than two config files Petter Reinholdtsen (1): Return an error to the log instead of segfaulting Stephan A. Maciej (1): Allow font server to start with pid longer than 5 digits git tag: xfs-1.0.7 http://xorg.freedesktop.org/archive/individual/app/xfs-1.0.7.tar.bz2 MD5: 3b425d5774a848ff8efb69a936e2d894

https://bugs.freedesktop.org/show_bug.cgi?id=108783 Bug ID: 108783 Summary: Nouveau crash in X server / display system with PAGE_NOT_PRESENT/NULL_DMAOBJ running Minecraft Feed The Beast Continuum Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All)

Package: xen-utils-common Version: 3.0.3-0-2 Severity: minor When I try to read the man page of xm, these warnings show up: Manual page xm(1) line 1/tmp/zmanA5668G:641: warning: can't find numbered character 160 /tmp/zmanA5668G:643: warning: can't find numbered character 160 /tmp/zmanA5668G:651: warning: can't find numbered character 160 /tmp/zmanA5668G:652: warning: can't find

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal gzip -3 compresses the Xen save files in a reasonably small amount of time and makes them take less than half the space that they might otherwise require. On systems with an encrypted root filesystem and on systems that have really fast CPUs if xm supported such compression then that would increase the speed of xm save and xm restore

Package: xen-utils-common Severity: minor Version: 3.0.3-0-2 During a domU state transition (at least on domU shutdown), "xm list" seems to occasionally fail. This is only intermittent, but it could cause problems if there are automated tools (or unaware humans) inspecting the output or return codes of "xm list". here's a recent transcript (the numbers preceding the bash

Processing commands for control at bugs.debian.org: > retitle 655301 xend shouldn't start if TOOLSTACK is not xm Bug #655301 [xcp-xapi] xcp-xapi fails to start Changed Bug title to 'xend shouldn't start if TOOLSTACK is not xm' from 'xcp-xapi fails to start' > reassign 655301 xen-utils-common Bug #655301 [xcp-xapi] xend shouldn't start if TOOLSTACK is not xm Bug

Package: xen-utils-common Version: 4.3.0-3 Severity: normal Dear Maintainer, I've just set up a fresh Jessie system using the installer dated 2014-03-05, then installed and enabled Xen 4.3. I've done this quite a few times before using Wheezy and 4.1. I set up xenbr0, then created a test domU using xen-create-image, which completed without issue. However I was unable to start the new

Control: tag -1 +moreinfo Hello, It seems this was incorrectly closed as xend only since this code can be used on upgrade (as part of rebooting from xend into a new system). I don't have any systems to test but I think the fix is trivially the following: @@ -51,7 +51,7 @@ class DataJSON(Data): class DataSXP(Data): def __init__(self, p): - s = SXPParser()(p) + s =

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ian, you can use the patch I posted in the original report, there are two places that need to be fixed. I'm using it since November. Cheers, Volker -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlXXpS8ACgkQgKD4KXUzSriihQCgidnLz9Lx475uQ4dzWz4jDrzM nsUAn3Z/Sy3tA2yquXvyAXnY04pxgOop =GYjR -----END PGP SIGNATURE-----

On Sat, 2015-08-22 at 00:24 +0200, Volker Klasen wrote: > Hi Ian, > > you can use the patch I posted in the original report, Uh, how on earth did I miss it! > there are two > places that need to be fixed. I'm using it since November. Thanks. Since loads is a classmethod I think the right fix for that issue is to s/self/cls/ in the body rather than s/cls/self/ in the

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I've updated the feature/bug763102 with the following extra patch: With both your patches applied, xen-init-list works. Cheers, Volker -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlXZ2cgACgkQgKD4KXUzSrhELACg2CCtFNUPtHxNz7XgpQjaYH6b Gn4An26yNob9A7vhz1L8RTWTMCrfc6RY =M2dx -----END PGP SIGNATURE-----

Package: xen-utils-common Version: 3.2.0-2 Severity: wishlist --- Please enter the report below this line. --- xm create requires the python-xml package to work, perhaps it should be a dependency of xen-utils-common ? --- System information. --- Architecture: i386 Kernel: Linux 2.6.24 Debian Release: lenny/sid 1001 testing security.debian.org 1001 testing

Le vendredi 20 juin 2008 08:48, vous avez ?crit?: > tags 487165 moreinfo > thanks > > On Thu, Jun 19, 2008 at 11:57:49PM +0200, Laurent L?onard wrote: > > xm create requires the python-xml package to work, perhaps it should be a > > dependency of xen-utils-common ? > > For what does xm create need python-xml? For me it works fine without. > > Bastian Sorry I

Package: xen-utils-common Version: 3.2.0-2 Severity: normal --- Please enter the report below this line. --- This bug is a duplicate of the bug #487165, but I tagged it as wishlist and I have no answer about it. But I think it should be interesting to correct it, sorry for this. xm new requires the python-xml package to work, perhaps it should be a dependency of xen-utils-common ? debian:~#

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal After running "halt" in a couple of domains I ran "xm list" repeatedly to see when the halt command was complete. Below is some of the output. The "Device 0 not connected" should not occur. yoyoxen:~# xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0

Package: xen-utils-common Version: 4.1.3-6 Severity: minor Dear Maintainer, I am trying to run the following command on a dom0 Debian server in order to mount a vmware vmdk. I don't want to use kpartx or losetup as they have poor write performance and I'm hoping blktap will provide better performance. xm block-attach 0 tap:vmdk:/mnt/backup/3MSYDDP01/3MSYDDP01_2-flat.vmdk /dev/xvda1 w 0

Package: xen-utils-common Version: 4.1.2-1 Severity: grave Justification: renders package unusable (Grave because dash is the default /bin/sh) With dash 0.5.5.1-7.4 as /bin/sh, /usr/sbin/xm enters an infinite loop of reexcuting itself. When run with bash, it works correctly. I traced that to /usr/lib/xen-common/bin/xen-toolstack; here's the diff between "/bin/sh -x /usr/sbin/xm"

Package: xen-utils-common Version: 4.2.1-2 Severity: important After run xm create -c win2008.hvm Using config file "./win2008.hvm". Error: 'NoneType' object has no attribute 'rfind' /var/log/xen/xend.log: [2013-06-10 21:48:59 31935] ERROR (xmlrpclib2:181) Internal error handling xend.domain.create Traceback (most recent call last): File