The Fedora Unity Project is proud to announce the release of new ISO Re-Spins (DVD and CD Sets) of Fedora 8.

These Re-Spin ISOs are based on the officially released Fedora 8 installation media and include all updates released as of May 1st, 2008.

The ISO images are available for i386, x86_64 and PPC architectures via Jigdo and Torrent starting Monday, May 5th, 2008.

Go to http://spins.fedoraunity.org/spins to get the bits!

CD Media Included

We have included CD Image sets for those in the Fedora community that do not have DVD drives or burners available.

Bugs solved in this Re-Spin

With this particular Re-Spin, fixes for the following bugs are included, like on our last Fedora 8 Re-Spin releases[1,2]:

• #372011, "depsolve hang in F7 to F8 upgrade"

We have incorporated the updates image made by Jeremy Katz (comment #11 in the bug), and we have verified that a full Fedora 7 installation upgrades to Fedora 8 without issues.

• #367731, "anaconda fails on Via VPSD motherboard"

On i586 hardware, the installation media wouldn't boot and thus renders itself unusable. We have backported the fix for this issue from anaconda development to the Fedora 8 stock anaconda, as anaconda is not updated during a release.

• #369611, "yum upgrade with selinux-policy-strict installed fails"

A dependency problem in selinux-policy-strict during upgrades is resolved in an updated selinux-policy-strict package, which is included in the Re-Spin

• #404601, "anaconda crashes on 'cdrom' line in kickstart"

Updates to pykickstart incorporated in the rebuilt installer resolve this issue.

• #420281, Cannot find kickstart file during unattended installation

The kickstart file name searched for after booting from CD or DVD with option "linux ks" and using a dhcp and nfs server is wrong.

Attention: Changes in this Re-Spin

Also, we would like to let you know that NetworkManager is now installed by default, and for people doing minimal installations; this service will need to be disabled before the network starts to work.

Thanks to

We would like to give a special thanks to the following for testing this Re-Spin:

- Harley-D                        Dana Hoffman Jr
- zcat                                Jason Farrell
- iWolf                               Jeffrey Tadlock
- vwbusguy-                      Scott Williams
- baard1973                     S.A. Hartsuiker
- Southern_Gentleman     Ben Williams
- nirik                                Kevin Fenzi
- kanarip                          Jeroen van Meeuwen

Testing Results

A full test matrix can be found at our Test Matrix

A full list of bugs, packages and changelogs that have been updated in this Re-Spin can be reviewed on http://spins.fedoraunity.org/changelogs/20080501/

Previous Re-Spin (20080331) will expire

Due to limited resources, this spin will immediately obsolete 20080331, which will be deleted from our mirrors in the next few days.

Fedora Unity has taken up the Re-Spin task to provide the community with the chance to install Fedora with recent updates already included.

These updates might otherwise comprise more than 2.05GiB of downloads for a full install.

This is a community project, for and by the community. You can contribute to the community by joining our test process.

Go to http://spins.fedoraunity.org/spins to get the bits!

Assistance Needed

If you are interested in helping with the testing or mirroring efforts, please contact the Fedora Unity team.

Contact information is available at http://fedoraunity.org/ or the #fedora-unity channel on the Freenode IRC Network (irc.freenode.net).

To report bugs in the Re-Spins please use http://bugs.fedoraunity.org/

Like with the last two Fedora releases, I'm planning on releasing a Fedora 9 Everything Spin. With Fedora 8, I gave you a sneak preview of what it would be like to install Fedora, selecting everything, using the CD version.

Today I've created a rawhide Everything spin just to see what a Fedora 9 Everything Spin would look like. Again, there's a CD, a DVD, and a DVD Dual Layer version, and of course you'd want to use the CD version, just for kicks. Here's what it would look like:

If Fedora continues like this, and IT WILL, I'll need to log a bug against anaconda in the Fedora 10 development cycle, because the list won't fit on any screen, and hence the buttons to confirm or cancel won't be available.

Someone blogged about how he feels uncomfortable with some of the Fedora tools being released, since it appears to him they are not tested, and I quote:

"I'm sure that they are not tested, at least not enough, or not by normal people." - Davidson Paulo

The rest of the blog sounds like he's doing a number 2, and all he gets is a red face. I gotta admit he's right though. I never test enough, and I'm not a normal person. Anyway the real question remains: Are the tools developed by the Fedora team tested?

I think I can answer that, but first let me set the record straight:

1. I am the main Revisor developer (just so you know, remember that while reading the rest of this blog post),
2. I am the Revisor packager as well,
   
3. I'm with Fedora (duh, wearing the Ambassador Polo Shirt right now),
   
4. I love Fedora being, (and I quote) "a beta-testing distro by some developers/packagers". If that's how you see it, then that's what I love.
5. I'm not getting paid anything other then the gratitude of users like you </sarcasm>

That being said let's get back to the real question at hand: "Why this wasn't fixed before packaging Revisor? Were Revisor checked by its packager? Were Revisor tested by its developers?"

Why wasn't this fixed?

The current version of Revisor in Fedora 8 is 2.0.5-15.fc8. Use:

yumdownloader --source revisor

and download the Source RPM, or navigate to the Source Tree for this version.

Either way, you won't find $releasever, $arch or $basearch anywhere in the package other then commented out in sample kickstart files, and in the cfg.py where we so subtly replace all occurrences with the proper values, should they appear in 'repo' directives in the kickstart you supplied. So, Revisor ships with valid configuration files.

If anything, it's the packaging guidelines that prevent us from replacing old (possibly bad) configuration files in /etc/ with new ones. I know I had released Revisor once or twice with bad configuration files. You may have had Revisor installed previously, and have a couple of .rpmnew files in /etc/revisor/conf.d right now.

FWIW, I agree with the packaging guidelines in this aspect as well as the other aspects and I'm not going to change the location of the configuration files, nor am I going to bluntly replace existing configuration files with a newer copy as these files may hold customized configuration such as the inclusion of third party packages. I can only assume someone spent a little time crafting them.

Was Revisor checked by it's packager?

Since I am the packager, this one lands right in my lap. Yes, I do check things before I release them. Yes, things will slip through the cracks. I'm terribly sorry for the inconvenience it may have cost you, seriously.

Was Revisor tested by it's developers?

Since I am the developer, this one lands right in my lap also. Again, all I can say is that I test stuff. Again, yes, things will slip through the cracks. You can imagine there's some cracks in developing software in one's free, spare time. Between my 40-hour dayjob, my life, my family, my girlfriend and the occasional getting-drunk-friday-night, there's a couple of "not-seeing-$releasever-or-$basearch" moments and if I happen to be releasing Revisor at one of these oblivous moments, it ends up on your PC (and then later on your blog).

So, now that we've gotten the questions out of the way...

Would you mind logging a bug against the appropriate package? I'm too ignorant to Google the web in search of bugs reported in blogs or newsgroups or any other location then http://bugzilla.redhat.com/ You neglected to file one against Revisor.

Last but not least, another quote: "Software testing is not an obligation of end-users.", and again I can only say you are so right. It is not an obligation to you, me, or anyone else. Neither is using or developing software. I consider using or testing new software to be a chance, a unique, once-in-a-lifetime opportunity. Writing new software is a challenge. Getting bugs reported properly is a motivator. Reading blogs like yours is hilarious.

So, what I'm trying to say is: Thank you, additional 40 voluntary seeders! And thank you, 45 original seeders! In 4 days after my original blog post requesting additional seeds, you doubled the amount of seeds and took some weight off my shoulders. I can breath again! The torrent tracker is also the master mirror for the release via Jigdo, the primary compose host for our Re-Spins and Revisor development, and my workstation -the load average makes me work on my laptop instead.

Vlad Dolezal writes in his blog on anamzingmind.com about the real reason we use Linux. He says although we might be telling people it's because it's secure, gratis, customizable or free, which are all valid reasons, supposedly the real reason that we use Linux is because it's fun. That's true, it is fun, but it's not the real reason.

Imagine you get to choose between two programs that do the same job, more or less.

One program is used a lot by the general public. How it works is obscure and you don't know exactly what it does if you press a button, but you do know that, in general, the program just works -duh, lots of people are using it. You may find documentation on how to use the program -which is often very conceptual and superficial- but still it doesn't give you any insight in the programs operations -the exact how, when and why fact sheet. Although I actually do know, let's assume that I don't; A user will think that it's all vague and obscure but it works.

The other program is made by a bunch of people that are extremely passionate, it's broadly used, it's well-documented, it has the proper fact sheets, and you can join news groups and mailing lists with any questions, problems and ideas you might have, and even talk to the developers directly. If push comes to shove you can also track down what it is the program is doing exactly -hence where things go wrong, behave differently from what you expect or where you need it to do something different. Not that you need to, but a huge number of other people to do it either because they're just as passionate, or they need a specific piece of the program to do what it is they need it to do -or because someone like you requested something that made them dig through all the code and fix something for you.

The principles on proprietary and freedom put aside, ask yourself;

If you're a user: Which program would you trust to work now and improve in the future?

If you're a developer of course the question for users applies as well, but also: Which one would you care most passionately about -bug tracking/solving, hacking, developing? Which poses the bigger challenge (greater reward)?

Some of you may think... "pico"? Didn't we get rid of that a long time ago? Yeah... I usually symlink it to any editor available I'm just so used to typing pico.

[jmeeuwen@bofh005 ~]$ history | awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
737 git
490 ssh
435 svn
302 ll
261 ls
255 pico
252 sudo
163 ln
143 rm
95 autoreconf

Like I stated in a previous blog post, Torrent is a real bandwidth consuming way of distributing things. I'd rather use Jigdo, which is very light-weight for both the client and the server. Better yet, clients could use our own version, pyJigdo, and give us feedback so that we can improve it.

Anyway, we do want our Re-Spins to be available to as many users as possible, and as it seems, Torrent is popular, still. Because Fedora Unity only has so much fast seeds (one that can handle the amount of disk space and traffic involved, actually), I'd like you to seed some, if you can. Right at this moment I have 154 peers (and growing) wanting to download one or the other Re-Spin, and I could certainly use your help seeding it to them. Check http://spinner.fedoraunity.org:6969/ to see which spins are most popular, and please note that most of the seeds you see are actually duplicates ;-)

Of course you are also welcome to consider becoming a Jigdo mirror for us, carrying about ~20GB of data, serving around 1GB/day.

Here's the Torrent files,

and here's the primary torrent seed:

Thanks, in advance,

Jeroen van Meeuwen

The Fedora Unity Project is proud to announce the release of new ISO Re-Spins (DVD and CD Sets) of Fedora 8.

These Re-Spin ISOs are based on the officially released Fedora 8 installation media and include all updates released as of March 31st, 2008.
The ISO images are available for i386, x86_64 and PPC architectures via Jigdo starting Wednesday, April 2nd, 2008.

We have included CD Image sets for those in the Fedora community that do not have DVD drives or burners available.

During the Testing phase the following was found:

1) a full x86_64 install with many optional packages or languages requires at least 768MB of RAM rather than the recommended 512MB.

2) the ftp utility in rescue mode will not work (missing libreadline.so.5) -which doesn't affect FTP installations.

With this particular Re-Spin, we address the following problems experienced by many community members, in addition to the problems we've resolved in previous Re-Spins[1]:

- #420281, Cannot find kickstart file during unattended installation
The kickstart file name searched for after booting from CD or DVD with option "linux ks" and using a dhcp and nfs server is wrong.

We would like to give a special thanks to the following for testing this respin in 2 days

- Harley-D         Dana Hoffman Jr
- zcat             Jason Farrell
- iWolf            Jeffrey Tadlock
- baard1973        S.A. Hartsuiker
- Southern_Gentleman     Ben Williams
- kanarip         Jeroen van Meeuwen

Fedora Unity has taken up the Re-Spin task to provide the community with the chance to install Fedora with recent updates already included.
These updates might otherwise comprise more than 1.33GiB of downloads for a full install.

This is a community project, for and by the community. You can contribute to the community by joining our test process.

A full list of bugs, packages and changelogs that have been updated in this Re-Spin can be reviewed on http://spins.fedoraunity.org/changelogs/20080331/

Go to http://spins.fedoraunity.org/spins to get the bits!

If you are interested in helping with the testing or mirroring efforts, please contact the Fedora Unity team.
Contact information is available at http://fedoraunity.org/ or the #fedora-unity channel on the Freenode IRC Network (irc.freenode.net).
To report bugs in the Re-Spins please use http://bugs.fedoraunity.org/

Kind regards,

The Fedora Unity Team

[1] https://www.redhat.com/archives/fedora-announce-list/2007-December/msg00008.html

There's now a Special Interest Group (SIG) for Fedora Community Spins. From the initial proposal by Jef Spaleta, here's what the SIG's responsibilities are:

The purpose of the Spin SIG is oversee the development of an evolving set of technical best practises to be applied to all community spin concepts. The Spin SIG will also oversee the continued maintenance of approved community spins in the Kickstart Pool, and will regulate the use of any infrastructure as it becomes available for use for the Spins SIG. For example webspace at spins.fedoraproject.org will be made available for spin descriptions and links to externally hosted binaries. New spin concepts first come to the Spins SIG for discussion and technical review. Once the Spins SIG comes to a consensus as to technical merit of a proposed spin, that spin concept is passed to the Board for trademark approval.

I'm volunteering to get this show on the road. If you have interest in a Fedora Community Spin, whether it be an existing, new or localized version, sign up and/or attend the first meeting Tuesday April 8th, 21:00 UTC, in the #fedora-meeting channel on the FreeNode IRC Network.

Hey there,

this is a personal message to you! Fedora EMEA is looking for Free (as in Libre) Accounting software that fits the need of an non-profit organization. Do you know what software your local soccer-, football-, hockey-, ice-skating- or computer hobby club is using? If you do -or if you can find out-, would you then please be so kind to drop us a note with the website of that piece of software so that we can give it a good close look?

You can email all of your ideas, specs, URLs and such to board@fedoraemea.org. Thanks, in advance!

Kind regards,

Jeroen van Meeuwen

The Fedora Project is seeking ways to verify the installer images and package payload distributed by Fedora Unity in the form of Re-Spins. It's not because they don't trust the source these binary and source images come from, they just want a general procedure of which verification of what is being distributed is a major component. This right now, or so it seems, is preventing the Fedora Unity images to be officially linked from fedoraproject.org's "get-fedora" page. This has always been a desire on Fedora Unity's part, as we think our Re-Spins are beneficial to the existing community around Fedora, as well as new-comers. Eventually, possibly, we might even be able to push the entire process to upstream, the Fedora Project itself, with all of us testers, composers, techies and developers following so that what we do now under Fedora Unity, becomes Fedora Project genuinely.

It's time for me to make a suggestion for the verification process on the images I produce:

I am Jeroen van Meeuwen, certified engineer for all kinds of stuff that have or do not have anything to do with Fedora and all that crap, you know where I live, and I've signed the CLA. I'm with Fedora Unity, the long-standing project with more then just a proven track record. We've been around for a couple of years, as I'm sure you know already. You might have met me at one or the other FUDCon, some other event, you might be able to Google me and start digging from there. I'm not really sure how much information you need about me to be able to verify where the images come from and therefore trust what the contents are exactly. I'm not sure there's a viable concern about my systems potentially being hacked or badly maintained so that not even I could tell what is on the images exactly, but if there is, make sure to notify all the greater parties that certify me, you'll find them on my fedoraproject.org wiki page.

Regardless, I'm the one that composes these Re-Spins. When I publish the images I produce, I sign off on them. Yup, that's me, personally. With or without backported anaconda hacks which are not in Fedora proper, but help the community. And not just me, the entire Fedora Unity Test Team signs off on them, after the 138 tests they perform. When these Re-Spins are released, an estimate 3000 users (per month) use these images to install one or more systems. I can see why a verification process is needed so much.

Thank you though, for trying to draft up a process concerning spins in general instead of getting rid of the show-stopper for Re-Spins that is called verification. I understand the concern, I'm not new to this world. Someone though might think it's a little far-fetched and that you're overreaching. Please make sure that doesn't cost you, I hate to see good people turn away from the project or become outcasts.

I've not even addressed the real, technical issue. There is no way to verify an image, whether it be an installer image or a live image. This is a catch-22 pur sang. I'm definitely going to kiss the one that comes up with a solution (if it's a girl, that is, boys can get a beer ;p). It might take a while, but being able to verify externally composed (binary) images would just be gallery play.

Now here's a picture: Compared to this, the issue of being able to link to third party repositories went over smoothly. Where's the verification process for that? I'm not sure what concerns me most, but the lack of consistency sure looks like a winner to me.

Yesterday was an interesting day at FOSDEM. I've been working on pyJigdo mostly -in order to get the proposed feature for Fedora 9 done, and while I was doing so I attended talks (mostly in the Fedora/CentOS developers room). After FOSDEM (all work and no play :P), we went to a restaurant by lack of a conference in the Hotel we are staying, and founded Fedora EMEA. Greatly anticipated, now finally done. I've taken some pictures you can view at my Fedora Unity space. Announcements in all the proper places coming up soon.

Today I'll be helping someone with boot problems -I didn't have the correct Re-Spin DVD with me and he promised to come back today, but before I start doing that, I usually browse through my e-mail and then mark everything read, and while I was doing so, my eye catched the message from Max Spevack saying he was aggregating all the blogs and pictures about FOSDEM (I'll add this one), and I came across this blog post on his LiveJournal blog.

I love Filet Americain! I ate it Friday, and I ate it again yesterday. The waiter warned me -he must have learned his lesson last year, but I knew what I was getting ;-)

This second day at FOSDEM (or third actually) I'm going to meet up with z00dax from CentOS and talk/brainstorm a little about Revisor on Enterprise Linux 5 or recomposing and rebuilding in more general terms, and look into the future a little given that he knows a lot more of what is going to happen in EL6 then I do. It promises to be a very useful and educational sit-together for me at least ;-)

Later today Yaakov Nemoy and myself will look into Revisor and the Server/Client model we've been talking about that FUDCon in Raleigh and express some ideas based on the code we've seen so far. The good thing is, this will shape up as we move forward and we do not really have a design set in stone or anything. Just the general goals. We've promised to just get some ideas up on some white-board first, and then discuss which one would fit best for what we need right now, and then look into what would be best in the long-term. I'm sure we're gonna end up with a solid plan.

That's all for now, time for some coffee.

Coming in to Belgium yesterday, I noticed a huge difference with the Netherlands. A pretty important one too. If you don't bring enough cash with you, and you don't have any bank passes of one of the local banks, you'll find yourself unable to pay for a lot of things. If you want to buy a subway ticket, you either need change or an ATM card from one of the local banks. It just wouldn't accept my MasterCard, nor my Maestro card.

Anyway we arrived at the hotel around 14:00, en decided to hit the center and walk around for a while and get some chocolate and a charger for my phone, waiting for the rest of the Fedora Ambassadors and Developers to arrive. Brussels is a beautiful town but I'm amazed with what they did to it. On our way over from Central Station to the real center there's a dozen building sites; every street you walk through seems to have at least one. What are they doing? Other then that, Brussels is still very nice to just walk around and do nothing ;-)

At 18:00-ish, the others arrived and a little later we headed off for dinner. We didn't go to the BeerEvent but we had a good time anyway. There's lots to talk about on the pre-eve of Fedora EMEA, of course, and so we did. It's all going down today...

The booth is set up, a schedule has been made so that we're not swarming our own booth. I'm sitting in the general Hackers room right now as the Fedora Developers room isn't available yet. Check out the new posters, and other pictures More coming up! ;-)

It's... exciting. I've been to events before and I've definitely been to Brussels before -I've even been to events in Brussels. This is the first time I'm going to FOSDEM though, and with everything in place for the Fedora EMEA non-profit organization, I expect it to be a very busy event for all of us. Besides, I'm bringing Revisor with me as well as pyjigdo and a couple of Re-Spins and repositories; let's see how much work one can do in a weekend ;-)

This is the amount of time my music "collection" adds up to. Note that "collection" is in quotes on purpose because the way I "collect" music is Ctrl+A, Ctrl+C, Alt+Tab, Ctrl+V. Anyway...

This amount of music files apparently Rythmbox cannot handle if you set it to update your media library automatically. And, so it seems, neither can XMMS, Audacious, or Amarok. Any tips are welcome!

Revisor 2.1.0... I want it to get out about the same time Fedora 9 is released.

What are the changes?

For one, it has documentation. The Revisor Manual.odt needs a lot of work still, and it is merely content whereas the form it is going to be presented in isn't set in stone yet. We could do a .pdf to go to /usr/share/doc/revisor-%{version}/Revisor Manual.pdf, but if someone wants to make it DocBookXML/yelp/XHTML/whatever, that'd be great to go into the regular Fedora Documenation process... Anyway, there is a little documentation, more then there was before. Contributions are very much welcome.

Modules. Plugins. Whatever you call them, they are cool. Really, they are. No doubt about it. What do they do?

The GUI is a module in 2.1.0, and as such, Revisor does not pull in too many unnecessary packages the GUI depends upon anymore. To install the GUI, people will still be able to use 'yum install revisor', which is now a meta-package. For CLI capabilities only, people should start using 'yum install revisor-cli'.

Besides the other modules for cobbler, deltarpm, jigdo, server and virtualization, in 2.1.0 you can now write your own module, and stick it in. How someone can write a plugin and stick it in, is ... obscure. Another reason for the documentation to take shape ;-) Basically it comes down to these modules having hooks that are to be executed by the Revisor base program.

One of the coolest uses for modules we have seen so far comes from Yaakov Nemoy, who has been working on getting the client/server model done, in which the client could very well be the much anticipated Web Interface(TM). More work to be done here ;-)

Now, getting back to work on shaping up 2.1.0 some more, with some background noise some people describe as "Alternative Rock"

Given a torrent tracker you can track the number of downloads that have been completed and the number of downloads still ongoing, as well as the number of seeds available. Two days ago, a single machine at the office started hosting a seed for the latest Fedora Unity Re-Spin, and it spits out data at 4 Mbps average, with only 8 (!) complete downloads, and while 4 other seeds have joined the swarm (and I'm still swamping the internet connection).

That is so much different from the Jigdo concept. Per mirror, we do an estimate 277 GB per month. Would we have been using Torrent, that would have been equal to 69 completed transfers. Using Jigdo however it equals to an estimate 1300 downloads (per mirror). Again in torrent that would be 5.2 TB for each of our mirrors to transfer. Can you imagine we seed that from our home or even office internet connections?

Updates to anaconda... Are Important

This morning I tried to provision a Fedora 7 Xen guest using a nice kickstart configuration file. However anaconda showed a traceback. Updates to anaconda are such a great deal, re-spinning (for Fedora Unity) or re-composing (business and pleasure, yes sir!) media will get you to appreciate that. So, here it is, repositories with packages for anaconda. My message to anaconda-devel-list earlier this year which didn't get much response yet probably because of Fedora 9 Alpha needing to get out.

Fedora $releasever - $basearch

[anaconda-updates]
name = Updated Anaconda Packages for Fedora $releasever - $basearch
baseurl = http://www.kanarip.com/anaconda/f$releasever/$basearch

[anaconda-updates-debug]
name = Updated Anaconda Debug Packages for Fedora $releasever - $basearch
baseurl = http://www.kanarip.com/anaconda/f$releasever/$basearch/debug
enabled = 0

[anaconda-updates-source]
name = Updated Anaconda Source Packages for Fedora $releasever
baseurl = http://www.kanarip.com/anaconda/f$releasever/SRPMS
enabled = 0

Note that if you want to use the packages with Revisor you'll need to expand these variables. Both the composing host as well as the package set will need to have the updated packages available.

Bugs Solved / Backported So Far

Fedora 7:

Bugzilla Bug 243159: Upgrade does not recognize existing install (backported fix)

Bugzilla Bug 350491: Anaconda crashes when using kickstart post script (backported fix)

Bugzilla Bug 241395: FC6 -> F7 anaconda upgrade traceback (backported fix)

Fedora 8:

Bugzilla Bug 367731: anaconda fails on Via VPSD motherboard (i586 hardware -many duplicates, backported fix)

I'll be looking for more bugs, (traceback on ISO over NFS installation..)

libXcomposite.so.1 missing

The past couple of days we've been running into spins that were unable to start the graphical installer. As it seems, gtk2 has had an update released recently which required libXcomposite, which is causing this behavior. Including the gtk2 update into the package set on the newly composed installation media thus fails if you start the graphical installer.

Let me try and explain what happens when you compose installation media. Anaconda-runtime (/usr/lib/anaconda-runtime/upd-instroot to be precise) has a list of packages to "install" onto a loop-mounted SquashFS file system image. The upd-instroot uses yum to install these packages onto that file system but also cleans out what is left behind on that image. So not only do you need to pull in libXcomposite into the list of packages being installed, you also need to adjust the list that scrubs the (what is to become) stage2.img contents. Here's where it all went wrong, libXcomposite.so.1 was being installed, but was removed also.

What this means, is...

From this moment onwards, at least as far as Fedora 8 is concerned, no-one will be able to Re-Spin or Re-Mix or Re-Whatever, unless you include set of updated anaconda packages on the host system performing the compose as well as in the package set on the media. Now, it just so happens that anaconda is not updated during a releases life-cycle (this policy has been in place for quite a while), and thus... You can forget about composing Fedora 8 media that boots the graphical installer if you include the updates repository.

Although...

You could of course exclude the gtk2 package from the updates repository, like so (this is from /etc/revisor/conf.d/revisor-f8-i386-respin.conf, soon to become available via the Revisor source tree but right now on http://git.kanarip.com/?p=unityspin/.git;a=tree;f=conf):

[updates]
name=Fedora 8 - i386 - Updates
baseurl=http://localrepo/fedora/updates/8/i386/
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f8&arch=i386
exclude=gtk2
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora

Or, you can do the following...

I Am Fedora For A Reason

The good thing about Linux in general is that you can fiddle with any code, no matter how good you understand it and no matter how good you are in breaking stuff. So, I've dug through the anaconda code once more (previously I backported a fix from anaconda development concerning the i586 not booting issue), found the issue, logged a bug, and came up with a patch, which I've applied and build and composed media with that successfully started the graphical installer. Note that the packages I've build also include the fix for the i586 issue. I've also dropped the anaconda-not-being-updated for a Fedora release into the hands of anaconda upstream, via their mailing list, and notified our other users and developers.