Where has the F10 DVD iso file gone?

[Brennan Ashton]

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
>> <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).
I am referring to all the test cases that get run before each release.
Test, fix, test, release. This could go smooth or it could be a
nightmare, it all depends on what little hidden bugs show there heads.
>
>> > 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
>
I thought about that I as I pasted it, but I came to the conclusion
that this way people can see how to find the answers to some of these
type of questions. But thank you for translating.
> 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 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'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!
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.
> 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.
>> > 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.
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...
>
> 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.
> 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 #?
> 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.
>
> 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.
See above.
>
> 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.

> --
> ================================
> "There's two strategies to arguin' with a woman:
> Neither one of 'em works."
>
> --Cowboy Wisdom