On Thu, 2009-01-01 at 03:38 -0800, Mike Cloaked wrote: > > > Christopher A. Williams-3 wrote: > > > > > > Well - a little good news here. After beating on Revisor most of the > > afternoon today, I managed to get it to actually create a 64-bit DVD > > Install ISO! I'm going to try it out on a virtual machine in a minute to > > see how it does. Next up will be 64-bit live media. > > > > In the meantime, I'm trying to find updated documentation. The Revisor > > Wiki pages only show stuff through version 2.0.5 while F10 has 2.1 and > > I've already read through all of that... > > > > > > Now that sounds excellent - if you could share your steps in getting revisor > to make a usable DVD iso with the rest of us then I bet it would be truly > appreciated - and presumably using updated packages that were released since > F10 release? > > I have been slowly moving in that direction also - documentation is sparse > and a good tutorial would be hugely valued. 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 CD. Unfortunately it was no more usable than the DVD. I think I'm close though. Next step is to try this using the base F10 kickstart files (now that I have found a couple of them). 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? 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. 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. 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. 3) Watch Revisor (and the other tools) closely. Every little error message will give you clues about things that you might be able to fix or find work-arounds for in this trial and error process. Now - back to my original point: I still believe Revisor (along with the others) has terrific potential. It seems to be about 80% of the way there in terms of functionality and also needs some major bug fixing. If I were a coder, I would gladly help with fixing that stuff, but I'm not. As an Enterprise Infrastructure Architect, I can only help with this kind of testing and feedback unless you need help with designing the underlying server and network infrastructure needed to support the development platforms... If these fixes can be implemented, we then have a reliable tool for creating custom spins. With that, we have the ability to begin automating the technical process for generating monthly ISO updates from the "gold" kickstart files. All that is then left is to examine and optimize the process for QA and release such that people who are already very busy don't have to take on more. I submit that, since the updated RPMs already have to go through a testing process, what actually needs to be tested for such an interim respin should be much smaller than a full release. If people put their collective brains to this, it should be solvable. Cheers, Chris -- ================================== By all means marry; If you get a good wife, you'll be happy. If you get a bad one, you'll become a philosopher. --Socrates -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list