On Thu, Jan 1, 2009 at 1:13 PM, Christopher A. Williams <chriswfedora@xxxxxxxxxx> wrote: > On Thu, 2009-01-01 at 11:56 -0600, Brennan Ashton wrote: >> On Thu, Jan 1, 2009 at 11:26 AM, Christopher A. Williams >> <chriswfedora@xxxxxxxxxx> wrote: >> > Well - I wish the news was as good as I had hoped... >> > >> > Revisor did indeed spit out a DVD ISO for me. It even booted and ran an >> > install in my VM. Unfortunately, what it installed turned out to be >> > almost completely unusable. I also managed to build a custom 32-bit Live >> >> Welcome to the life of Fedora QA > > If this is the life you encounter and accept, I feel sorry for you. > Based on my experience, you're living with a number of issues you > shouldn't need to. The QA process is suffering from a lack of proper > procedure and tools. Additional experience I'll note later supports what > I'm saying, and the good news is that I think this can be fixed rather > easily (thus making everybody happy). I am referring to all the test cases that get run before each release. Test, fix, test, release. This could go smooth or it could be a nightmare, it all depends on what little hidden bugs show there heads. > >> > Side Question: Where is the official place the F10 kickstart files are >> > supposed to be kept? This should be something relatively easy to get to, >> > shouldn't it? >> yum whatprovides *-fedora.ks >> Loaded plugins: refresh-packagekit >> pungi-2.0.8-1.fc10.noarch : Distribution compose tool >> Repo : fedora >> Matched from: >> Filename : /usr/share/pungi/rawhide-fedora.ks >> Filename : /usr/share/pungi/f9-fedora.ks >> >> spin-kickstarts-0.10.3-1.fc10.noarch : Kickstart files and templates for >> : creating your >> own Fedora Spins >> Repo : fedora >> Matched from: >> Filename : /usr/share/spin-kickstarts/fedora-install-fedora.ks > > Based on history of your replies, this is a perfectly technical answer > that really doesn't provide the answer. Since, fortunately, I am > technical I was able to dig through this. HEre's the plain English > translation for people who might be interested: > > The "gold" kickstart files are part of a package called spin-kickstarts > which is in the main Fedora repository. Install this package and all of > them will be neatly deposited in the directory: > > /usr/share/spin-kickstarts > I thought about that I as I pasted it, but I came to the conclusion that this way people can see how to find the answers to some of these type of questions. But thank you for translating. > My advice on this to everyone is to then read through the kickstart > files. You'll find they are actually are modularized and then assembled > on the fly via a series of include statements. There really aren't that > many of them (I got through what I needed in 10 minutes of reading) and > the naming convention used makes logical sense. By going through each of > them, you'll begin to understand 1) how they get put together and 2) > which one you really need to start with to build what you want. > >> > I have found a few other things about Revisor that should be highlighted >> > brightly because I've seen the same problems with several other tools >> > like Yum Extender. >> > >> > It seems the reason why I can't build 64-bit Live images at all is >> > because something in the package selection process / tools arbitrarily >> > includes BOTH the 32-bit and 64-bit versions of everything you select in >> > the package manifest instead of including just the 64-bit packages if >> > they exist. This leads to the conflicts that cause the whole thing to >> > fail. I think the reason it doesn't happen with 64-bit DVDs is because >> > the selected package RPMs are only added to a specific directory on the >> > DVD. Live images actually do a system installation as a part of the >> > build process. >> Mock will make your life a lot easier > > Perhaps. But mock is traditionally used with pungi. That helps with > pungi, but not Revisor. It does at least have the potential / intent to > do things that were never intended for pungi. The best scenario would be > to get all of these tools working properly. I dont trust building outside of a chroot, because I do not know what is going to be drawn in from my system. This might not be a valid concern feel free to correct me / educate me. > >> > I've also seen this package selection behavior in Yum Extender >> > (including the current version in F10). At least with Yum Extender, you >> > can manually de-select all of the non-64-bit packages by hand. It's >> > incredibly tedious to do, but it works. This also happened in versions >> > of the package selection tool fka Add Or Remove Programs in F8 and >> > earlier. Moreover, it also happens with kickstart files created via >> > system-config-kickstart. I don't know if Package Kit has this problem or >> > not yet. >> > >> > Of note, this does NOT happen when trying to build 32-bit systems. The >> > 64-bit packages are (correctly) ignored. It is only when trying to add >> > package groups to 64-bit systems that the 32-bit packages are also >> > selected. Since this is something common to several tools, I suspect the >> > problem is either in something under the covers they all use or it is in >> > code that they all share. >> > >> > As to other issues with Revisor, what I'm finding is that a lot of stuff >> > in the GUI either just doesn't work at all or is just plain broken. It >> > clearly looks like a work in progress - with a lot of work left to be >> > done. What I can tell you so far is: >> > >> > 1) Read the doc that does exist. It at least will give you a clue about >> > how Revisor was intended to work, even if it doesn't exactly work that >> > way because so much is broken or has been changed since the doc was >> > written. >> I gave up of Revisor for straight ks builds > > Well - I'm glad at this point that I didn't. Guess what? I have > SUCCESSFULLY BUILT a respin of F10 Live i386 US English with all patches > as of today! Once I figured out what needed to be done, it took all of a > few minutes to re-spin. The install from my respun Live CD worked > flawlessly in my VM, with yum correctly reporting that no updates were > needed. > > I'll sell how I did it to you for a small fee of $100... :) > > Nah - seriously, I'll post how I did it later on today. Gotta go to my > mom's house for some major New Year's Day eating first! I will give what you put up a try, its not that I am anti revisor, it is that I understand mock and pungi much more. > Building a 64-bit system was NOT successful - for the same reasons I > brought up before about 32-bit packages being arbitrarily included with > their 64-bit counterparts. Whatever is happening here has to be with > code that is likely shared between Revisor, Yum Extender, and a few > other tools. If we can get this part fixed, we will have made major > strides forward. This is what I like about mock, it will keep that from happening. >> > 2) Develop as good an understanding of what the build process involves >> > as a part of this so you know what the tools are trying to do along the >> > way. Believe it or not, the doc on Pungi - sparse as it is - was >> > extremely helpful to me in understanding more about Revisor. >> > >> Mock + pungi > > While I will still also play around with this, I think I've been able to > demonstrate for myself that this isn't a requirement. What I fail to > understand from you on this is that, if you knew this combo to work, why > you would refuse to provide step-by-step instructions (or at least point > out where they might be) instead of taking positions like "it's too > hard" and "join with Fedora Unity" when I (and others) have already been > providing such feedback - and have clearly stated as such. This smacks > of someone who is technically savvy, but has more interest in > demonstrating that technical ability than helping to solve the actual > issues. The comment about fedora unity was that what they are trying to do is what (i think) you are trying to do and a joint effort might help build a better fedora, I am not trying to smack anyone down, a little over a year ago I knew nothing about koji/mock/pungi etc... > > Just because the Fedora Project currently puts out full releases faster > than other groups right now doesn't mean this isn't a problem. Further, > there is clearly evidence that this is something that can be fixed. > > I stand by my original points: > > 1) The respin process should be something that is fully automated In the long run I agree, but until someone makes the magic tools to do all the install test cases that is going to be hard. Think https://fedoraproject.org/wiki/QA/TestPlans/Fedora10Install every week. If you want to do this kind of automation I really think mock/pungi is going to be your friend that is what it was made for. > 2) The QA process clearly needs refinement so that people aren't > overwhelmed by the work Some automation might be nice see above. > 3) Some basic fixes to existing tools would greatly help Not to be blunt, but what is "broken" bug #? > 4) The Fedora Team should be the overall owner of this issue. Not Fedora > Unity or anyone else. This is particularly true since the ability to > create custom spins quickly and easily is a highly advertised goal of > the Fedora Project. I agree, but a project larger group backing I would expect to be more likely to be considered by FESCo. As they have said for the Long-Term-Support get something going independently and they will pull it in. > > If the Fedora team wants to delegate this work, Fine. But then that > should be done formally with all of the access points and processes and > resources needed to support it. See above. > > Now - based on what I have found (some of which I will post later), can > we please get some forward motion on organizing both the technical and > process oriented pieces needed to fix this? I've put a lot of time into > this already and will continue to do what I can. "It's too hard" and "Go > work with Fedora Unity" are not acceptable answers - they're excuses. Did you click the link that I pointed to now 3 times, I also offered to help via IRC. http://jons-thoughts.blogspot.com/2008/05/pungi-and-mock-for-fun-and-profit.html I am trying to help not make excuses. > -- > ================================ > "There's two strategies to arguin' with a woman: > Neither one of 'em works." > > --Cowboy Wisdom -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
