On Wed, May 6, 2015 at 5:04 PM, Cole Robinson <crobinso@xxxxxxxxxx> wrote: > On 05/06/2015 09:57 AM, Zeeshan Ali (Khattak) wrote: >> 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 I'm hoping you guessed that I meant to write "more likely" here. >> 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. >> > > Check the fedora wiki page, we do have links for stable vs. latest. Stable Ah sorry, I'm blind sometimes. > points to the build that roughly correlates with what was shipped with the > latest public RHEL release, so they should be reasonably trustworthy. But I > say reasonably because I don't think RHEL QE is testing libosinfo autoinstall > or anything > > However... I want to avoid this situation: > > - stable link is updated > - boxes installs are now busted for, say, winxp > - panic ensues, much scrambling to get the bug fixed and update the stable/ link > > If instead libosinfo/boxes had its own stable link like libosinfo.org/virtio, > it could point to the virtio-win stable/ link by default, but if a nasty > regression is found, you could change libosinfo.org/virtio to point back to > the old working repo while we wait for an update Sounds good but 1. I think we'll need Daniel's help to setup this webspace on libosinfo.org. 2. I'm guessing this would mean you'd keep hosting at least the last stable release of drivers? -- Regards, Zeeshan Ali (Khattak) ________________________________________ Befriend GNOME: http://www.gnome.org/friends/ _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
