On Mon, 2016-02-08 at 17:23 +0300, Roman Kagan wrote: > On Sat, Feb 06, 2016 at 06:20:42PM -0500, Cole Robinson wrote: > > Sorry for the delay, been caught up in other stuff. I'll be focusing on > > virtio-win stuff this coming week though > > > > I've committed these patches now. I added a few commits on top to make my > > pylint[1] setup happy. No functional changes. > > Great, thanks. > I've accumulated a couple of fixes and enhancements in the meantime; > I'll rebase and post them soon. > > > I'm realizing now that the input bits to make-driver-dir.py > > (virtio-win/qxl/qemu-ga windows builders from RH's internal build system) > > aren't published anywhere so there isn't any way for you to reproduce the full > > workflow for the public RPM. I'll work on getting those mirrored on > > fedorapeople.org > > Actually we started putting together our stuff, too, and encountered a > number of issues I'd be interested to discuss. > > 1) since the drivers can only be built on a Windows machine, there's a > need to define the artifact(s) produced on a Windows machine and used > as source(s) for rpmbuild on a Linux machine (koji). > > We thought the most natural responsibility split (as applied to > kvm-guest-drivers-windows) is to collect the stuff in "Install" > subdirectories of every driver upon buildAll.bat execution in a > single zip archive and use it as that artifact; the rest will be > taken care of from under rpmbuild on a Linux machine. One benefit is > that it's going to be easy to intervene manually, e.g. when doing > signatures or whatever else. > > This differs from what's currently in virtio-win srpm where the > drivers are received in a tarball whose contents was obviously > subject to certain manipulations after building on Windows. > > > 2) build scripts for kvm-guest-drivers-windows (haven't checked qxl yet) > don't adhere to the conventions assumed by the scripts I posted. > E.g. here's the relevant excerpt from Balloon/sys/packOne.bat: > > [...] > if /i "%1"=="win8" goto create_win8 > if /i "%1"=="wlh" goto create_vista > if /i "%1"=="win7" goto create_vista > if /i "%1"=="wnet" goto create_xp > if /i "%1"=="wxp" goto create_xp > goto error_inf2cat > > :create_xp > if /i "%2"=="x86" set _OSMASK_=XP_X86,Server2003_X86 > if /i "%2"=="x64" set _OSMASK_=XP_X64,Server2003_X64 > goto run_inf2cat > > :create_vista > if /i "%2"=="x86" set _OSMASK_=Vista_X86,Server2008_X86,7_X86 > if /i "%2"=="x64" set _OSMASK_=Vista_X64,Server2008_X64,7_X64,Server2008R2_X64 > goto run_inf2cat > > :create_win8 > if /i "%2"=="x86" set _OSMASK_=8_X86 > if /i "%2"=="x64" set _OSMASK_=8_X64,Server8_X64 > call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" %INST_ARC% > goto run_inf2cat > > [...] > :run_inf2cat > inf2cat /driver:..\Install\%INST_OS%\%INST_ARC% /os:%_OSMASK_% > [...] > > as a result > > a) there are distinct builds for XP and 2003, but they both are > marked as matching both XP and 2003; same problem for Vista/2008 > and Win7/2008R2 > b) there's no build marked as matching Win8.1, 2012R2 and Win10 We are working on reviewing virtio-win build system, mostly toward switching to VS2015 and adding Win10 as a build target. Best regards, Vadim. > > We have an engineer tasked with sorting this out (and submitting the > fixes upstream of course) but ATM the scripts won't produce the > complete and consistent driver set. > > > 3) current virtio-win package includes several loosely related packages: > virtio drivers, qxl, qga; we add our own, too. They have independent > release cycles and build procedures (e.g. qga builds nicely with > mingw on Linux and can be turned into a normal rpm suitable for > shipping in e.g. Fedora) > > Therefore we're considering splitting the rpm into several > independent ones with the stuff installed onto the host filesystem as > a directory structure; the iso and floppy images would be generated > from that right on the host (e.g. by rpm triggers or by a tool like > supermin) rather than brought in pre-generated. > > > Comments welcome, > Thanks, > Roman. _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
