similar to: Bug#668550: libxs-dev and libxen-dev: error when trying to install together

Hi, Since Xen has been around for a long long time, and that libxs is pretty new in Debian (only few days), I'd say that libxs-dev should be fixed. Do you agree? Cheers, Thomas

Processing commands for control at bugs.debian.org: > reassign 668550 libxs-dev Bug #668550 [libxen-dev,libxs-dev] libxs-dev and libxen-dev: error when trying to install together Bug reassigned from package 'libxen-dev,libxs-dev' to 'libxs-dev'. No longer marked as found in versions libxs-dev/1.0.1-1, libxen-dev/4.1.2-3, and libxen-dev/4.1.2-4. Ignoring request to alter fixed

Processing commands for control at bugs.debian.org: > found 661471 3.4.1-2 Bug #661471 [gnome-themes-standard] gnome-themes-standard: removal of gnome-themes-standard makes files disappear from gnome-accessibility-themes Marked as found in versions gnome-themes-standard/3.4.1-2. > found 670105 libdrmaa-dev/6.2u5-4 Bug #670105 {Done: Dominique Belhachemi <domibel at debian.org>}

Processing commands for control at bugs.debian.org: > found 668697 libgrib-api-1.9.16/1.9.16-1 Bug #668697 [libgrib-api-1.9.16,libgrib-api-1.9.9] libgrib-api-1.9.9 and libgrib-api-1.9.16: error when trying to install together The source libgrib-api-1.9.16 and version 1.9.16-1 do not appear to match any binary packages Marked as found in versions libgrib-api-1.9.16/1.9.16-1. > found 668697

Good day. This may sounds trivial, but I unable to find any documentation for libxs. Python implementation is pretty simple for use, but C is very different (lot of questions, f.e. who frees dynamic memory and when). I google it badly or it really absent? --- wBR, George. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com

While attempting to troubleshoot a problem with PCI passthrough, I noticed a number of facts that, when considered together, may indicate a serious upgrade path issue with regard to Xen and QEMU: 1. libxen-dev is a single package with two versions: a 4.8 version and a 4.11 version 2. libxen-dev version 4.8 produces libraries with 4.8 in the soname. A qemu compiled against this version has

Package: libxen-dev Version: 4.0.0-2 Severity: grave Hi Bastian, libxen-dev used to ship the following file: /usr/include/blktaplib.h but it has gone, I don't get why. The result is that I can't compile my xen-qemu-dm-4.0-4.0.0 in a normal SID system, while it was working perfectly with version 4.0.0-1~experimental.2 of libxen-dev. I had a look into the debian/changelog of xen 4.0.0-2,

Package: libxen-dev Version: 4.1.4-3+deb7u1 Severity: wishlist Dear Maintainer, I want to make some fine monitoring of my xen machines and the xentop utility does not exactly fits my needs I saw in the sources that it uses some kind of library named libxenstat wich seems very acurate. This library is already built to make the xentop utility but the debian package does not makes it available as

V4 of the patch, incorporating Bastian's suggestions. Jon --- xen/debian/patches/series | 1 + xen/debian/patches/tools-ocaml-fix-build.diff | 81 +++++++++++++++++++++++++ xen/debian/rules | 5 ++ xen/debian/rules.real | 39 ++++++++++++ xen/debian/templates/control.main.in | 16 +++++

Processing commands for control at bugs.debian.org: > reassign 668641 libxen-dev Bug #668641 [xen] Please add a symlink /usr/lib/xen -> /usr/lib/xen-default Bug reassigned from package 'xen' to 'libxen-dev'. No longer marked as found in versions 4.1.2-3. Ignoring request to alter fixed versions of bug #668641 to the same values previously set > forcemerge 644390 668641

Package: libxen-ocaml-dev Version: 4.2.0-1 Severity: important Tags: patch Dear Maintainer, The ocaml libraries are currently unusable as they contain the build path of .s libraries. For example: root at myvm:~# cat test.ml let _ = let v = Xenctrl.with_intf (fun h -> Xenctrl.version h) in () root at myvm:~# ocamlfind ocamlopt -package xenctrl test.ml -linkpkg -o test File

Package: libxen-4.2 Version: 4.2.0-1 Severity: normal Hello, in xen 4.1 Debian packagers removed blktap uselessly as is documenteted in the blktap bug. in xen 4.2 qemu-dm is removed. This removes any reasonable way to access disks and reserves Debian Xen for diskless DomU use. Essentially Debian Xen packages are now useless. -- System Information: Debian Release: wheezy/sid APT prefers

Hi Waldi, please consider the patch from: http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2007-November/001516.html it simply adds the missing headers to the current Xen packages. This would help us along until we have a libxen* and libxen*-dev packages to get Xen support into libvirt. I'll take care of (potential) abi breackage in the libvirt package. Cheers, -- Guido

All, I am making a first pass at using the C bindings of the Xen-API for a test application, and am running into some confusion on the proper use of the API. I am modeling some of my development around the test code in tools/libxen/test/test_bindings.c However, some things are not clear to me, and the API documentation seems to be more of a function reference, than documenting the intended

Package: libxenstore3.0 Version: 4.3.0-3 Severity: wishlist I want to install amd64 qemu together with libvirt-bin on a system with amd64 kernel and i386 userland. libxenstore3.0 and libxen are the two last libraries missing multi-arch support to make this possible. It would be nice if you could make them multi-arch: same -- System Information: Debian Release: jessie/sid APT prefers unstable

Package: libxen-dev Version: 4.6.0-1+nmu2 Severity: serious User: debian-qa at lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships a broken symlink: /usr/lib/x86_64-linux-gnu/libxlutil.so -> libxlutil.so. (notice the trailing dot, it is part of the target). You probably want this target instead: libxlutil-4.6.so Andreas

Package: xcp-xapi Version: 1.3.2-6 Severity: important Looks like on Wheezy, /etc/default/xen is not created by xen-utils-common. Since xcp-xapi depends on its existence and further declaration of the toolstack in it, it should take extra care to ensure that it is present. root at debian:~# aptitude install xcp-xapi The following NEW packages will be installed: blktap-dkms{a} blktap-utils{a}

Package: logcheck-database,sendmail-base Version: logcheck-database/1.2.69 Version: sendmail-base/8.14.3-9 Severity: serious User: treinen at debian.org Usertags: edos-file-overwrite Date: 2009-08-18 Architecture: amd64 Distribution: sid Hi, automatic installation tests of packages that share a file and at the same time do not conflict by their package dependency relationships has detected the

Hi folks I propose the following changes for 3.1: - Rename source to xen-3. Upstream stripped one part of the version, so the next should be 3.2. - pygrub as extra package. - Rename i386 to i386-nonpae - Rename i386-pae to i386. PAE is upstream default now and pae images works with a 64bit hypervisor. We should think about supporting libvirt. It provides an AFAIK stable interface on the

Hello. That's what I've got from ld: /usr/lib/libxenguest.a(xg_private.o): In function `unlock_pages': (.text+0x490): multiple definition of `unlock_pages' /usr/lib/libxenctrl.a(xc_private.o):(.text+0x6a0): first defined here /usr/lib/libxenguest.a(xg_private.o): In function `lock_pages': (.text+0x4d0): multiple definition of `lock_pages'