Hi. virt-manager uses libosinfo to determine the OS and OS version of the install media for a VM. If I try to create a VM with libosinfo-1.0.0, the list in virt-manager, the autodetect fails and the list is blank and only offers a "generic" VM. If I downgrade to libosinfo-0.3.1, it works perfectly with specific versions of the OSes detected and available for selection Reproducible: Always Steps to Reproduce: 1. Install libosinfo-1.0.0 and any version of libvirt/virt-manager that use libosinfo 2. Try to create a VM with a local install ISO 3. See that the detection fails and only a "Generic" OS is offered
This problem is caused by the fact that when the package was upgraded to 1.0.0, the corresponding osinfo-db and osinfo-db-tools packages were not made. See the changelog at https://gitlab.com/libosinfo/libosinfo/blob/master/NEWS.
Created attachment 459808 [details] Ebuild for osinfo-db-tools
Created attachment 460308 [details] ebuild for osinfo-db{-tools} Alternative approach to fixing this bug.
Any progress with this?
(In reply to Ivan Ivanich from comment #4) > Any progress with this? Foster Mclane (comment #1) does have them in his fkmclane overlay, and it worked for me.
fkmclane overlay users should uninstall osinfo-db-tools and osinfo-db before main tree updates, as they are now in sys-apps, not sys-libs (which doesn't make sense as the new packages don't provide libraries). Also osinfo-db there doins'ed everything into osinfo /etc "local directory" instead of "system directory". I didn't use any of the attachments, as all of that needed to be different for system usage, so my versions are based on copies from libosinfo and removing things from there with some stea^Whints from fedora git spec files. But many thanks for tiding us over meanwhile for ~arch users until the main tree stuff got fixed! Due to the new packages, this is all ~amd64 only for starters, but KEYWORDREQ bug incoming from me. commit e951c7d685b15f37443abffbae2fc79f408aaff3 Author: Mart Raudsepp <leio@gentoo.org> Date: Tue Mar 28 22:28:17 2017 +0300 sys-libs/libosinfo: revbump with many fixes for 1.0.0 - Depend on the split osinfo-db package for proper runtime functionality; don't bother avoiding build dependency on it, as tests will need it anyway. This also fixes tests. - Add missing build deps on perl and intltool - Pass hwids paths to configure and depends on required hwids USE flags properly - Adjust rdeps to configure.ac check order and minimum deps expressed there - Don't uselessly subslot := operator dep on things that don't have (sub)slots Gentoo-bug: 602204 Gentoo-bug: 605124 commit 494f8a6f5861f351a08170a689c3c7fa4d33b6e1 Author: Mart Raudsepp <leio@gentoo.org> Date: Tue Mar 28 22:19:29 2017 +0300 sys-apps/osinfo-db: initial package after split from sys-libs/libosinfo Gentoo-bug: 605124 commit e0730154b856798afaf57b044e90c77ca80a11f2 Author: Mart Raudsepp <leio@gentoo.org> Date: Tue Mar 28 22:17:43 2017 +0300 sys-apps/osinfo-db-tools: initial package after split from sys-libs/libosinfo Gentoo-bug: 605124
oh, and until I get release monitoring stuff going for the osinfo-db releases going, osinfo-db bump request bugs are welcome (also osinfo-db-tools and libosinfo 4-day requests).
Is there anything I should do before removing the packages from my overlay to make the transition smooth for anyone use it that isn't following this bug report here?
(In reply to Foster McLane from comment #8) > Is there anything I should do before removing the packages from my overlay > to make the transition smooth for anyone use it that isn't following this > bug report here? If assuming that osinfo-db-tools is fine mostly from your overlay (as it's the same version, while osinfo-db is a snapshot upgrade, but I think there's only maybe some rdep differences), then if you really want you can add a pkgmove entry, assuming it works from the overlay. With something like this in profiles/updates/1Q-2017: move sys-libs/osinfo-db-tools sys-apps/osinfo-db-tools move sys-libs/osinfo-db sys-apps/osinfo-db Then those that have it installed from your overlay with sys-libs/ category will get it changed to sys-apps/ and then pick up an upgrade for osinfo-db from there, which moves the files to the system location instead of /etc and so get that fix. And as said, feel free to file quick version bump request bugs for these 3 things for now when you notice updates or new osinfo-db snapshots in https://releases.pagure.org/libosinfo/ I will probably need 2-4 months to get proper automatic checking going for this.
