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). > > 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 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'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! 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. > > 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. 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 2) The QA process clearly needs refinement so that people aren't overwhelmed by the work 3) Some basic fixes to existing tools would greatly help 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. 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. 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. -- ================================ "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
