Revisor, pungi, F10 respins, etc. (Was: Re: Where has the F10 DVD iso file gone?)

Christopher A. Williams chriswfedora at cawllc.com
Fri Jan 2 16:27:08 UTC 2009


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 at cawllc.com> 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




More information about the fedora-test-list mailing list