Where has the F10 DVD iso file gone?

[Christopher A. Williams]

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