On Thu, 2009-01-01 at 13:52 -0600, Brennan Ashton wrote: > 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 New Year's Day eating was much more serious than anticipated. Thus the delay in posting this due to a requirement to sleep it off. Boy was that gumbo good though - thanks Mom!!!! > > 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 agree that the level of risk of hosing your system with something like this is greater outside of a chrooted environment. I too get a little queasy feeling with this, but the risk admittedly is not a wholly unacceptable one. At some point, every system requires the use of certain programs that have to run with root authority. Now that said, I would actually like to see improvements to anaconda such that things like root authority and putting selinux into permissive mode are not requirements for building this stuff. I do consider having this is a requirement to be a bug. > > 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. OK - Here's what I did: I'm assuming that everyone has all of the revisor tools, along with pungi and it's supporting components, and the kickstart examples installed. You probably don't need all of this, but that's what I wound up with after all of the playing around. As a side note, if you read the Revisor documentation, you will find that it actually depends quite a bit on pungi for what it does. It seems to be more a GUI based extension of pungi with more options and a lot of still to be implemented ideas. I would tend to characterize its relationship to pungi as being similar to the relationship between yum and Yum Extender. The biggest key is understanding that a bunch of stuff is broken in the Revisor GUI. It ranges from many features that are grayed out because they aren't fully implemented to little stuff like that the Help--> About dialog does not properly launch the Revisor Website when you click the URL. If you dig around their bug tracking system, you'll find much of this is known and documented. It's just not fixed / completed / etc. Make sure that selinux is in permissive mode when you start. If you don't do this, Revisor will complain to you that this is needed and will then exit. Okay... After clicking the Get Started button, you get to the first wizard dialog. Make sure that the model is set for f10 i386, and that you de-select the (non-existent) F10-Updates-Newkey repository. Everything else on this menu turns out to be OK for the task at hand. Click forward to the next step... At the next dialog, specify that you want to use the fedora-livecd-desktop-en_US.ks kickstart file located in /usr/share/spin-klickstarts (Note to others: you did install spin-kickstarts, right...?). If you want a different language or Live CD (like with KDE), select the appropriate kickstart file for what you want instead. Be sure that: 1) The "Use the repositories specified in the kickstart file" option is NOT checked 2) The "Use the package manifest specified in the kickstart file" option IS checked. At your option, you can check that you want to further customize the package list. I've done this both ways and it does work, although the GUI might lead you to believe otherwise. More on that later. Next, click forward through the rest of the setup menus. Note that when the package list is first displayed, it appears as if there are no packages selected. This is a lie!!! Everything in the kickstart list has been selected - it just doesn't show up. Further, if you opt to customize the package list even more, it will still look like nothing is selected other than what you picked. This another problem I consider to be a bug (like the other things I'm writing about). In reality, everything in the kickstart file will be used, and you are just going through the list to add whatever else you want. Unfortunately, because this list is NOT pre-populated with items from the kickstart file, you can't opt to NOT use something that might be in the kickstart package list. You can only use this dialog to ADD more things to the manifest. OK - once you are satisfied with these choices and hit the forward button, it will throw one last error message at you that a small number of rather obscure packages don't exist and that the results might therefore not be what you expect. Take a deep breath and ignore this. I call this trusting that the people who built the kickstart files actually knew what they were doing... Then we wait for a very long time as Revisor downloads RPM files, builds all of the options and creates the final ISO. It will look like it's not responding on numerous occasions. Just let it be - it will finish. Depending on the speed of your computer, Internet connection, and how much was already cached from previous attempts, this could easily take a couple of hours. If all goes well, in the end you will wind up with a newly minted F10 i386 Live CD ISO built from the latest available RPMs. Mine works great! >From this, you can use the livecd tools to build a bootable USB drive, or you can just burn a CD - your choice as usual. > > 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. OK - Good info. This then supports the notion Revisor and some other tools like Yum Extender are doing something they should not be doing with package selection, and may be doing it because they share the same (buggy) code. This needs to be investigated and fixed. I would propose that, if they only selected 64-bit packages instead of overcompensating like they apparently are, the dep resolver could work out the rest when changes are committed. Since the resolver is going to run anyway, it would probably make things a lot cleaner. > 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... I don't have a problem with that. It's just that this came as if my pointing out that my previously noted efforts to work with Fedora Unity seemed to fall on deaf ears. I think what Fedora Unity is doing is very similar, but it isn't exactly the same. It is close enough that cooperation is something that would seem critical to success. They also seem to be flailing with tools selection and use. For example, instead of fixing Revisor, we add jigdo for obtaining Fedora Unity respins and a process of using it that is just as complex and prone to errors. This seems to happen a lot - instead of improving / fixing the tools we have, we throw the baby out with the bathwater and write completely new tools that are just as complex, but with different problems that never get fixed because we decide to just write something completely new again... I'm all for choice in tools. I just prefer having a choice of tools that all actually work reliably. > > 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. I think the solution is multi-faceted. Respins should not need to go through the same level of testing as a full release to begin with. That said, I think this could be automated using a combination of technologies -including mock and pungi. I've done this kind of work before using virtual infrastructure tools and systems. While these will not cover every scenario listed in the URL, they can do a surprising amount of this kind of work very quickly and effectively. > > 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 #? Blunt answer. Lots of stuff is broken - some of it is captured and marked as bugs, and some of it isn't. I think I have been describing stuff that is broken in pretty good detail already. Just because something isn't in Bugzilla doesn't mean it's not broken. It just means it should be put in there AND it should be fixed. > > 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. Perhaps this is just a philosophical difference. If FESCo advertises respin / custom spin capability as a new feature that will be a part of Fedora, it is not something they should then wait for some other group to start for them and then decide to pick it up when they're happy it works. They should be seeding those groups and actively supporting them if they aren't going to do it themselves. Announcing new, promised features and then hoping someone out there picks it up and actually implements it for you is not a good way to manage software development. > > 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. Actually, I'm not a frequenter of IRC. But indeed I did look at that URL the first time you posted it. I thought it was a terrific "geeks guide" commentary for mock and pungi. It was definitely not for beginners though, and it also should not be considered a stand-alone guide - you definitely still want to read the pungi doc itself. It is one of the articles I mentioned before that gave me more clues about what really needed to happen. In all, I read it, the pungi doc, the Revisor doc, some of the fedoraforum posts on the topic, the Revisor bug lists, and some of the available release notes. Oddly enough, I actually found the pungi documentation extremely helpful for Revisor. Once I understood the dependency / relationship Revisor has with pungi, both tools made a lot more sense. With the holiday season coming to an end and my work schedule picking back up, I'm going to have much less time to work on this over the next several weeks. I'll continue to do what I can, but it would be really nice if this could be pushed forward more by others. Cheers, Chris -- ====================== "If we don't succeed, we run the risk of failure." -- Former President Bill Clinton -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
