Bug 605124 – =sys-libs/libosinfo-1.0.0 fails to detect ISO OS with virt-manager

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Nick Sarnie 2017-01-08 20:47:41 UTC]

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

[Comment 1 Foster McLane 2017-01-12 18:32:05 UTC]

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.

[Comment 2 Phil Turmel 2017-01-12 20:42:01 UTC]

Created attachment 459808 [details]
Ebuild for osinfo-db-tools

[Comment 3 Michal Privoznik 2017-01-16 11:50:48 UTC]

Created attachment 460308 [details]
ebuild for osinfo-db{-tools}

Alternative approach to fixing this bug.

[Comment 4 Ivan Grynko 2017-02-20 19:20:08 UTC]

Any progress with this?

[Comment 5 Brandon Penglase 2017-03-11 16:09:52 UTC]

(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.

[Comment 6 Mart Raudsepp 2017-03-28 19:58:39 UTC]

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 <[e-mail]>
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 <[e-mail]>
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 <[e-mail]>
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

[Comment 7 Mart Raudsepp 2017-03-28 20:00:36 UTC]

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).

[Comment 8 Foster McLane 2017-03-30 17:23:42 UTC]

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?

[Comment 9 Mart Raudsepp 2017-03-31 05:54:59 UTC]

(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.