Bug#536174: [Pkg-xen-devel] Bug#536174: Bug#536174: Bug#536174: xen-utils-3.4: pygrub searches for filesystem plugins at the wrong path
On Sun, Jul 19, 2009 at 04:25:58AM +0800, Thomas Goirand wrote: Bastian Blank wrote: On Fri, Jul 17, 2009 at 08:08:48PM +0800, Thomas Goirand wrote: What is numerous software and what are they doing with this internal und unstable interfaces? Namely: enomalism, dtc-xen (our software). We are currently getting away from it, and build a cleaner code using libvirt, but still ... There must be some other software as well, I remember at least a 3rd one needs it, but can't remember it's name. And what do they use? xen.xm? xen.lowlevel? In both cases, the goal is to avoid forking yet another process, by calling xm list, xm stop or xm start for example, by simply including some python code and calling the main. Forking a tool is the way to go since Unix was invented. That is why fork is fast. But okay, so they use xen.xm.main. This makes absolutely no sense to me, and also, I don't think that being a maintainer gives you the rights to decide for everyone using the distribution. In Debian the maintainer have the power to decide this. However, they can be overwritten by the developers at all or the technical committee.[1] But best practice is to listen to suggestions, and be open for discussions, no? Suggestions to drop support are no good start for a discussion. Also, if there's no /usr/lib/xen, what is the point of having a /etc/alternatives/xen-default? I'd like to understand. There is a /usr/lib/xen-default. This link is meant as a last resort fallback in case it can't decide which version to use.[2] So in theory you can use a handmade Xen with a prebuilt version of the userspace. My point is that there should be a /usr/lib/xen, and there is no reason that Debian is the only distro. in the world that doesn't have one, it's not standard, and always causes issues. No, Xen have several definitions, where it tries to install to by default. /usr/lib/xen is only one. So, if you think this should exist, please elaborate the behaviour of it, including all constraints. Bastian -- We Klingons believe as you do -- the sick should die. Only the strong should live. -- Kras, Friday's Child, stardate 3497.2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536174: [Pkg-xen-devel] Bug#536174: Bug#536174: Bug#536174: xen-utils-3.4: pygrub searches for filesystem plugins at the wrong path
On Sun, 2009-07-19 at 04:25 +0800, Thomas Goirand wrote: In both cases, the goal is to avoid forking yet another process, by calling xm list, xm stop or xm start for example, by simply including some python code and calling the main. FWIW I'd be surprised if the upstream Xen developers would consider this to be a stable/exported interface. Is performance of xm start and xm stop really bounded by the time it takes to fork the python process for xm? Seems unlikely to me. Similarly if time to fork xm list is an issue then perhaps you are polling far to frequently? Ian. -- Ian Campbell Current Noise: Electric Wizard - Priestess Of Mars toilet toup'ee, n.: Any shag carpet that causes the lid to become top-heavy, thus creating endless annoyance to male users. -- Rich Hall, Sniglets -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536174: [Pkg-xen-devel] Bug#536174: Bug#536174: Bug#536174: xen-utils-3.4: pygrub searches for filesystem plugins at the wrong path
Ian Campbell wrote: On Sun, 2009-07-19 at 04:25 +0800, Thomas Goirand wrote: In both cases, the goal is to avoid forking yet another process, by calling xm list, xm stop or xm start for example, by simply including some python code and calling the main. FWIW I'd be surprised if the upstream Xen developers would consider this to be a stable/exported interface. Is performance of xm start and xm stop really bounded by the time it takes to fork the python process for xm? Seems unlikely to me. Similarly if time to fork xm list is an issue then perhaps you are polling far to frequently? Ian. You got the main reason by yourself! We are doing xm list every minute because we are graphing the resulting time in a RRD (remotely, not on the dom0). The issue is not only the time to execute, but mainly the memory usage going up and down all the time when calling them. Anyway, we are not the only one doing this. The decision to use what's in /usr/lib/xen anyway is not yours. I agree it's not good, we are moving away from it. In fact, we should never have had a look at the bad example from Enomalism. But the issue remains anyway. It's not up to Debian maintainers to decide things should be different from other distributions, or even from the source version of Xen, and that is it (even if you consider using it ugly...), IMHO. Thomas P.S: thanks a lot for the huge work maintaining Xen in Debian, it's far from being trivial. Hoping that you guys will have enough time so there will be soon a 64 bits dom0 running kernel 2.6.28 or 2.6.30 in Debian, as we are having drivers issues with 2.6.26 (I managed to get a patch for our e1000e 82574L go to the kernel team, it's tested and working very well even in production, but not sure when or if it's going to be included). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536174: [Pkg-xen-devel] Bug#536174: Bug#536174: Bug#536174: xen-utils-3.4: pygrub searches for filesystem plugins at the wrong path
Bastian Blank wrote: On Sun, Jul 19, 2009 at 04:25:58AM +0800, Thomas Goirand wrote: Bastian Blank wrote: On Fri, Jul 17, 2009 at 08:08:48PM +0800, Thomas Goirand wrote: What is numerous software and what are they doing with this internal und unstable interfaces? Namely: enomalism, dtc-xen (our software). We are currently getting away from it, and build a cleaner code using libvirt, but still ... There must be some other software as well, I remember at least a 3rd one needs it, but can't remember it's name. And what do they use? xen.xm? xen.lowlevel? At least: xen.xm.main, xen.xm.main.server.xend.domain(). No, Xen have several definitions, where it tries to install to by default. /usr/lib/xen is only one. So, if you think this should exist, please elaborate the behaviour of it, including all constraints. Bastian One VERY important one, is that there is /usr/lib/xen/boot/hvmloader. It's there in all distributions, but in Debian, it's in /usr/lib/xen-VERSION/boot/hvmloader. It's a *moving target* in Debian. Any software that wish to be a manager (that creates and deletes VMs) for Xen in Debian can't predict where is the hvmloader to point to in the VM startup configuration file /etc/xen. At least, that one is a very valid reason, if you don't think the python lib is one. You may say that there's /etc/alternatives/xen-default, but WHY would we have something that specific in Debian? Why can't we just have /usr/lib/xen like everyone else? Just a very small symlink solves this issue for ALL software in Debian, instead of patching them one by one. Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536174: [Pkg-xen-devel] Bug#536174: xen-utils-3.4: pygrub searches for filesystem plugins at the wrong path
On Thu, Jul 16, 2009 at 09:49:39PM -0400, Anders Kaseorg wrote: Is there actually a use case for installing multiple versions of Xen on the same system? Yes, its the same then with the Linux kernel or every ordinary library: ABI stability, aka interopatibility of the components. Redhat and SuSE usually don't consider this at all on this level. Perhaps it is time to reconsider them and use a layout closer to upstream’s? Please outline the advantages and disadvantages of both variants. Also please note that a package without ABI-name needs to handle incompatibilites another way to minimize the outfall. Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, The Paradise Syndrome, stardate 4842.6 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536174: [Pkg-xen-devel] Bug#536174: Bug#536174: xen-utils-3.4: pygrub searches for filesystem plugins at the wrong path
On Fri, Jul 17, 2009 at 08:08:48PM +0800, Thomas Goirand wrote: Related to the above also: I even asked the Xen team the request to add the following 2 symlinks, that would have solve many issues in numerous software: What is numerous software and what are they doing with this internal und unstable interfaces? I was told that it was a stupid thing, and my bug was tagged wontfix. I'd like to understand exactly WHY the packager took this decision. Because it declares the interface as public and therefor stable enough to not break now and then. This makes absolutely no sense to me, and also, I don't think that being a maintainer gives you the rights to decide for everyone using the distribution. In Debian the maintainer have the power to decide this. However, they can be overwritten by the developers at all or the technical committee.[1] This was a very big concern for us, and I was really disappointed to see the reaction of the Debian Xen team, not considering the report, and being quite unfriendly. Only a small amount of the people gets payed to do the job, most are volunteers. Also, if there's no /usr/lib/xen, what is the point of having a /etc/alternatives/xen-default? I'd like to understand. There is a /usr/lib/xen-default. This link is meant as a last resort fallback in case it can't decide which version to use.[2] So in theory you can use a handmade Xen with a prebuilt version of the userspace. Bastian [1]: http://www.debian.org/devel/constitution [2]: /usr/lib/xen-common/bin/xen-utils-version -- Each kiss is as the first. -- Miramanee, Kirk's wife, The Paradise Syndrome, stardate 4842.6 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536174: [Pkg-xen-devel] Bug#536174: Bug#536174: xen-utils-3.4: pygrub searches for filesystem plugins at the wrong path
Bastian Blank wrote: On Fri, Jul 17, 2009 at 08:08:48PM +0800, Thomas Goirand wrote: Related to the above also: I even asked the Xen team the request to add the following 2 symlinks, that would have solve many issues in numerous software: What is numerous software and what are they doing with this internal und unstable interfaces? Namely: enomalism, dtc-xen (our software). We are currently getting away from it, and build a cleaner code using libvirt, but still ... There must be some other software as well, I remember at least a 3rd one needs it, but can't remember it's name. In both cases, the goal is to avoid forking yet another process, by calling xm list, xm stop or xm start for example, by simply including some python code and calling the main. I don't see how this can be unstable, and why you want to prevent people from doing it if they want to... It does work pretty well, and has been working for YEARS (since Xen 2.0.7 at least). I was told that it was a stupid thing, and my bug was tagged wontfix. I'd like to understand exactly WHY the packager took this decision. Because it declares the interface as public and therefor stable enough to not break now and then. Xen authors decided to put it in /usr/lib/xen, I don't see why it should be any different in Debian. This makes absolutely no sense to me, and also, I don't think that being a maintainer gives you the rights to decide for everyone using the distribution. In Debian the maintainer have the power to decide this. However, they can be overwritten by the developers at all or the technical committee.[1] But best practice is to listen to suggestions, and be open for discussions, no? This was a very big concern for us, and I was really disappointed to see the reaction of the Debian Xen team, not considering the report, and being quite unfriendly. Only a small amount of the people gets payed to do the job, most are volunteers. I don't see how the fact to be payed or not has to do with the discussion. Also, if there's no /usr/lib/xen, what is the point of having a /etc/alternatives/xen-default? I'd like to understand. There is a /usr/lib/xen-default. This link is meant as a last resort fallback in case it can't decide which version to use.[2] So in theory you can use a handmade Xen with a prebuilt version of the userspace. My point is that there should be a /usr/lib/xen, and there is no reason that Debian is the only distro. in the world that doesn't have one, it's not standard, and always causes issues. Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536174: [Pkg-xen-devel] Bug#536174: xen-utils-3.4: pygrub searches for filesystem plugins at the wrong path
Anders Kaseorg wrote: Furthermore, users who read the upstream Xen documentation (#508139), as well as programs that try to use the Xen binaries (#481105) or libraries (#507186), get thrown off by the alternate layout. Is there actually a use case for installing multiple versions of Xen on the same system? Perhaps it is time to reconsider them and use a layout closer to upstream’s? Or if not, perhaps the patches can be sent upstream and integrated as a supported configure option, so that Debian does not need to maintain an unsupported layout separately? Anders I cannot agree more with the above. Related to the above also: I even asked the Xen team the request to add the following 2 symlinks, that would have solve many issues in numerous software: ln -s /etc/alternatives/xen-default /usr/lib/xen ln -s /usr/lib/xen-default/lib/python/xen \ /usr/lib/python2.5/site-packages/xen I was told that it was a stupid thing, and my bug was tagged wontfix. I'd like to understand exactly WHY the packager took this decision. This makes absolutely no sense to me, and also, I don't think that being a maintainer gives you the rights to decide for everyone using the distribution. This was a very big concern for us, and I was really disappointed to see the reaction of the Debian Xen team, not considering the report, and being quite unfriendly. Also, if there's no /usr/lib/xen, what is the point of having a /etc/alternatives/xen-default? I'd like to understand. Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536174: xen-utils-3.4: pygrub searches for filesystem plugins at the wrong path
The Debian Xen packaging has been carrying a long pile of invasive patches to use this modified filesystem layout for quite some time now. I assume the goal is to make it possible to install multiple versions of Xen at the same time. But that doesn’t seem to have been successful in practice (e.g. #536173, #536176). These patches make the Xen package extraordinarily difficult to modify or upgrade (I’ve tried!). Every added component requires another set of patches, and every new upstream version requires rewriting many of the existing patches. I can only assume that this difficulty at least partially to blame for the gap of more than a year between these last two Xen releases in Debian (#526833). Furthermore, users who read the upstream Xen documentation (#508139), as well as programs that try to use the Xen binaries (#481105) or libraries (#507186), get thrown off by the alternate layout. Is there actually a use case for installing multiple versions of Xen on the same system? Perhaps it is time to reconsider them and use a layout closer to upstream’s? Or if not, perhaps the patches can be sent upstream and integrated as a supported configure option, so that Debian does not need to maintain an unsupported layout separately? Anders -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536174: xen-utils-3.4: pygrub searches for filesystem plugins at the wrong path
Package: xen-utils-3.4 Version: 3.4.0-1 Severity: important pygrub uses the fsimage library to read contents of the filesystems to boot. This package install the plugins for different filesystems at /usr/lib/xen-3.4/lib/fs/, but searches for them under /usr//usr/lib/fs. (The debian patch tools-libfsimage-prefix.diff explicitly tinkers with this path, but it fails.) This breaks pygrub. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages xen-utils-3.4 depends on: ii e2fslibs 1.41.7-1 ext2 filesystem libraries ii iproute20080725-2networking and traffic control too ii libc6 2.7-18GNU C Library: Shared libraries ii libgcrypt111.4.4-3 LGPL Crypto library - runtime libr ii libncurses55.7+20081213-1shared libraries for terminal hand ii libxenstore3.0 3.4.0-1 Xenstore communications library fo ii python 2.5.2-3 An interactive high-level object-o ii python-central 0.6.11register and build utility for Pyt ii python2.5 2.5.2-15 An interactive high-level object-o ii udev 0.125-7+lenny1/dev/ and hotplug management daemo ii xen-utils-common 3.3.1-1 XEN administrative tools - common ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages xen-utils-3.4 recommends: ii bridge-utils 1.4-5 Utilities for configuring the Linu ii xen-hypervisor-3.4-amd64 [xen 3.4.0-1The Xen Hypervisor on AMD64 Versions of packages xen-utils-3.4 suggests: ii xen-docs-3.4 3.4.0-1Documentation for Xen -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
