# qlist xen-tools | grep local /usr/local/share/doc/qemu/qemu-doc.html /usr/local/share/doc/qemu/qemu-tech.html /usr/local/share/man/man1/qemu-img.1 /usr/local/share/man/man1/qemu.1 /usr/local/share/man/man8/qemu-nbd.8 /usr/local/etc/qemu/target-x86_64.conf is there a link to the texinfo problem? I removed the dependency on ">=sys-apps/texinfo-5" and it works. BTW: Xen 4.2.2 release/ebuilds look good to me. See my report: http://www.gossamer-threads.com/lists/xen/devel/285755
hmm wow thx. My regrets for the delay but I'm the only one who maintains xen and I tend to such bugs intermittently. I'm a python team member which takes several people the full spare time to maintain, while xen is but one package in 3 ebuilds. <is there a link to the texinfo problem? I removed the dependency on ">=sys-apps/texinfo-5" and it works.> I had a brief search, not offhand. You could trawl old xen bugs. I simply can't remember when that cropped up and when if and I fixed it. What comes to memory is that texino-5 broke something some months back when I did an extensive system update, so essentially the texinfo-5 release broke something that wasn't broken before, but I think it wasn't in xen. 27 Jun 2013; Ian Delaney <idella4@gentoo.org> xen-tools-4.2.1-r3.ebuild, xen-tools-4.2.1-r4.ebuild, xen-tools-4.2.2-r1.ebuild, xen-tools-4.2.2-r2.ebuild: drop dep texinfo-5, fixes faulty install, Bug #472976 by Andreas Kinzler
I think there is a misunderstanding. In my tests I found the dependency on ">=sys-apps/texinfo-5" is unnecessary. It did not solve the problem of the invalid install into /usr/local. I use Xen quite alot and I am involved in occasional (but intensive) testing for the Xen community. If my time allows, I'll contact you for feedback/patches if you like to help Xen on Gentoo a bit.
(In reply to Andreas Kinzler from comment #2) > I think there is a misunderstanding. In my tests I found the dependency on > ">=sys-apps/texinfo-5" is unnecessary. It did not solve the problem of the > invalid install into /usr/local. hmm, well this it seems is a gift horse. $ qlist xen-tools | grep local yields blank where it didn't before. $ ls /usr/local/share/doc/qemu/ ls: cannot access /usr/local/share/doc/qemu/: No such file or directory $ ls /usr/share/doc/xen-tools-4.2.2-r1/ html pdf ps $ PYTHON_SINGLE_TARGET=python2_7 USE="doc" ebuild xen-tools-4.2.2-r2.ebuild clean install ======================================== ls /mnt/gen2/TmpDir/portage/app-emulation/xen-tools-4.2.2-r2/image/usr/ bin include lib lib64 sbin share no local. What more can I say?
no local. What more can I say? Well that would be; I'm puzzled since I can't even replicate it again. How did you build to get this again???
I've refrained from re-installing texinfo-5 which supports it's an unexpected fix. On that topic, see Bug 471122.
I think use flags are important: I use +hvm +qemu for app-emulation/xen-tools. This is really needed because without you cannot run HVMs. Everything works fine (with dep on ">=sys-apps/texinfo-5") removed. Since the /usr/local files are all related to qemu this might be the missing clue.
(In reply to Andreas Kinzler from comment #6) > I think use flags are important: I use +hvm +qemu for > app-emulation/xen-tools. This is really needed because without you cannot > run HVMs. Everything works fine (with dep on ">=sys-apps/texinfo-5") > removed. Since the /usr/local files are all related to qemu this might be > the missing clue. Yes use flags are important. wiping out texinfo appears to have taken this bug with it. So could you re-close it seeing I can't even replicate it now. Andreas do you have any idea or suggestions of a other ebuilds to make up in light of the extra capabilities xen has recently tacked on? The prime example has to be efi.
Sorry, the problem still exists. I emerged app-emulation/xen-4.2.2-r1 and app-emulation/xen-tools-4.2.2-r3 into an empty and fresh/new Gentoo system. # qlist xen-tools | grep local /usr/local/share/man/man8/qemu-nbd.8 /usr/local/share/man/man1/qemu-img.1 /usr/local/share/man/man1/qemu.1 /usr/local/share/doc/qemu/qemu-tech.html /usr/local/share/doc/qemu/qemu-doc.html /usr/local/etc/qemu/target-x86_64.conf use flags: app-emulation/xen-tools hvm qemu
Andreas; version bump 4.3.0 features a switch to /usr/local, except if you configure with --prefix=/usr; hence in the bumped 4.3.0; src_configure() { econf --prefix=/usr } from which, with USE="flask hvm qemu ocaml pygrub screen", I get NO instance of the /usr/local/ anything in .....xen-tools-4.3.0/image/usr/. Possibly this was started in 4.2.2 and fully declared in release notes of 4.3.0. However, can you at least run the bumped 4.3.0 after firstly purging all traces of xen and tell me the result here.
This does persist, with USE qemu the qemu build's Makefile(s) direct install dir to /usr/local. There are 2 ways to do this, however in light of this appearing to be 'set right' by use of configure --prefix=/usr in new version, I've gone for moving them to the right spot after installed to the wrong spot within /image, or ${D}. *xen-tools-4.2.2-r4 (21 Jul 2013) 21 Jul 2013; Ian Delaney <idella4@gentoo.org> +xen-tools-4.2.2-r4.ebuild, files/xen-4-fix_dotconfig-gcc.patch, files/xen-4.2.0-anti-download.patch, xen-tools-4.2.2-r3.ebuild, xen-tools-4.3.0.ebuild: revbump; correct install of qemu files folders with IUSE qemu, fixes Bug #472976, upgrade instances of ED to D in revbumped & 4.3.0
Created attachment 354528 [details] new initd script
Created attachment 354530 [details, diff] patch to fix invalid installs
Manually moving files might cause problems if their location is somehow referenced by the program (for example if qemu-dm internally references /usr/local/etc/qemu/target-x86_64.conf). My patch solves the problem for Xen 4.2.2 by giving the right paths to configure of qemu-xen (non-traditional). I also added a completely new init script for xenstored (I know: wrong bug). This script has quite a bit of error checking and some nice console printing (waits 3 seconds before it starts a waiting (...) line). The current script easily ends as endless loop (during Gentoo startup) on nearly every error (not running on dom0, ...).
(In reply to Andreas Kinzler from comment #13) > Manually moving files might cause problems if their location is somehow > referenced by the program (for example if qemu-dm internally references > /usr/local/etc/qemu/target-x86_64.conf). My patch solves the problem for Xen > 4.2.2 by giving the right paths to configure of qemu-xen (non-traditional). > This is basically thate other way. While 4.2.2 is in portage sure, let's try it > I also added a completely new init script for xenstored (I know: wrong bug). > This script has quite a bit of error checking and some nice console printing > (waits 3 seconds before it starts a waiting (...) line). The current script > easily ends as endless loop (during Gentoo startup) it shouldn't < on nearly every error (not running on dom0, ...) > This warrants a fresh bug 30 Jul 2013; Ian Delaney <idella4@gentoo.org> +files/xen-tools-4.2.2-install.patch, xen-tools-4.2.2-r4.ebuild: alternate fix to Bug #472976 by patch by Andreas Kinzler wrt to Bug #472976 by Andreas Kinzler
I tried this with 4.2.2-r3 and the patch works as expected. Comments on the initscript went to the new bug.
right that makes for 2 capable testers giving the (y) which is emoticon for thumbs up
