On Tue, May 5, 2015 at 6:34 PM, Cole Robinson <crobinso@xxxxxxxxxx> wrote: > On 05/05/2015 08:12 AM, Zeeshan Ali (Khattak) wrote: >> On Fri, May 1, 2015 at 11:37 PM, Cole Robinson <crobinso@xxxxxxxxxx> wrote: >>> Hey all, >> >> Hi Cole, >> >>> Wanted to give a heads up about a new repo with virtio-win RPMs. Isos are >>> still available for direct download, just at a different URL. All the details >>> are here: >>> >>> https://fedoraproject.org/wiki/Windows_Virtio_Drivers >>> >>> FWIW the rpm and iso now match the layout of what we ship with RHEL, and match >>> the content (except still no WHQL signature). >> >> Thats really awesome. Thanks for working on this. >> >>> Not sure how interesting it is to libosinfo/boxes in its current form. >>> But >>> it's a fresh base to start from if you have any ideas or suggestions about how >>> to improve things in this area. >> >> Well it would be really good to have all drivers files available in >> unpacked form at a canonical location (than zeenix.fedorapeople.org). >> If you could make that happen, that would be very helpful. Currently I >> manually unpack the latest ISO and upload the driver files to my >> personal webspace and then update the libosinfo db. So a lot of manual >> work and I tend to forget about such tasks and hence the reason you'd >> find drivers we currently use in libosinfo are a bit old. >> > > So looks like the only drivers you need there are the virtio-block bits, > though we should probably expose virtio-scsi as well since it seems storage is > the only bit that's needed (virt-v2v has similar requirements though they get > the drivers from /usr/share via the virtio-win RPM). Exposing those extracted > bits should be easy enough. Can you file a bug at Product=Virtualization Tools > Component=virtio-win ? Done: https://bugzilla.redhat.com/show_bug.cgi?id=1219042 > However I'd suggest libosinfo still controls the URL, even if it's just a > redirect to the new bits. And I would also suggest that the URL only points at > known tested versions, since it's plausible the automated builds could be > completely busted sometimes, they will often hit the public repo before anyone > but the developer has tested them Hm.. true but can't you separate the tested ones from completely untested newly build ones on http://alt.fedoraproject.org itself? The thing is being incharge on the whole thing, you'd be far less likely to notice new versions available (and also be the best judge of which ones can and cant be marked as stable/tested). Also we don't currently have any canonical location for these drivers. > Also might be cool to have an enviroment variable that tells libosinfo to get > the drivers from a different URL, for easy testing of a different driver set > for bug triage Sounds like a good idea but it would be a bit hard to implement I think in libosinfo itself since the URL comes from XML/data and not from code. I guess the simplest way would be to have a env variable that affects *all* URLs but then you'll need to ensure all the drivers are available in the overriiden location. So I think it'd be better to have these in apps. Boxes, for example, already does caching of driver files and it even supports system cache (/var/cache/gnome-boxes) of drivers so you could already do this with Boxes at least. -- Regards, Zeeshan Ali (Khattak) ________________________________________ Befriend GNOME: http://www.gnome.org/friends/ _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
