----- "Ryan Harper" <ryanh@xxxxxxxxxx> wrote: > * Michael Goldish <mgoldish@xxxxxxxxxx> [2009-03-12 02:26]: > > > > > > Regarding the stepfiles you created for Linux -- I can't help > much > > > > with those since I don't have the data. I do believe that if I > had > > > the > > > > data and the stepfiles I could quickly identify the problem, so > if > > > you > > > > think those can be sent to us, I'd like to have them. > > > > > > I created a stepfile for RHEL5 and what I'm seeing is that one of > the > > > screens I captured in stepmaker ended up having a focus ring > around > > > something and on replay the focus isn't there. This situation > isn't > > > something that a new algo will fix as you pointed out. I'm > wondering > > > if > > > this is something you've seen. I don't quite understand how it > would > > > happen since stepmaker and the replace send the same keystrokes. > I > > > also > > > don't see how in general this can be avoided. > > > > The problem sounds familiar. Does the ring appear around one of the > > GNOME menubars, i.e. around "Applications" or "System"? GNOME seems > to > > be somewhat indeterministic with those rings. If you run the > stepfile > > several times, you'll notice that in most cases you'll see a focus > > ring (or no focus ring, I don't quite remember) and the rest of the > > time you'll get the other case. > > Ding Ding Ding! =) > > > > > This can be avoided either with experience, or a good wiki entry on > > picking the right barriers (which we plan to create). But you don't > > have to avoid making mistakes with stepmaker -- most types of > mistakes > > are fixed very quickly and easily with stepeditor. > > yep, used stepeditor to fix; defintely worth documenting where one > should be invoking stepeditor -- from the steps dir; if you don't run > it from there, it won't find the steps_data dir =( Are you absolutely sure about that? That's not the way it's supposed to be. I tried running it on several machines and it worked every time regardless of where I invoked it from. Since it resides in the kvm_runtest_2 dir, I usually just change to that directory and type ./stepeditor.py. Then I use file->open and pick the steps file, and it works. If you have a very recent version, you should have a dir named "steps_data" under "kvm_runtest_2", right next to "steps". Inside "steps_data" you should have the data dirs. For "steps/RHEL5.steps" the corresponding data dir would be "steps_data/RHEL5.steps_data/". If you have a slightly older version, you should have the data dirs inside the "steps" dir, next to the stepfiles themselves. For "steps/RHEL5.steps", the corresponding data dir would be "steps/RHEL5.steps_data/". > I'll have to go back and re-read your email on where to put the > reference ppm files so one gets the refrence comparision. The paragraph above applies to the reference comparison as well. > > The other thing has to do with the ISO files. kvm_runtest has a > very > > important feature that we innocently forgot to implement in > > kvm_runtest_2 -- md5sum verification of the ISO files. This means > that > > the framework currently makes no use of the "md5sum" and > "md5sum_1m" > > parameters in the config file. This means you might be using > different > > ISOs than the ones we made our stepfiles with. In that case I > wouldn't > > expect any stepfile to succeed. However, if you used these same > ISOs > > with kvm_runtest then they should be fine. In any case, I'll add > the > > feature ASAP to the git repository. > > Right - I suppose it might be better if the names of the windows iso > disks matched how MS names them in MSDN, for example, kvm_runtest > refers > to Windows2008-x64.iso which doesn't match any name from MSDN, what > we > have is: > en_windows_server_2008_datacenter_enterprise_standard_x64_dvd_X14-26714.iso This is a very good idea. I wonder how we can find out the MSDN names of the ISOs we have. BTW, did the ISO you mentioned work with kvm_runtest? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
