Fedora Unity releases Fedora 7 Re-Spin

The Fedora Unity Project is proud to announce the release of new ISO Re-Spins (DVD and CD Sets) of Fedora 7. These Re-Spin ISOs are based on Fedora 7 and all updates released as of January 18th, 2008. The ISO images are available for i386, x86_64 and PPC architectures via jigdo starting Thursday, January 24th, 2008. We have included CD Image sets for those in the Fedora community that do not have DVD drives or burners available.

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.99GiB of downloads for a full installation. This is a community project, for and by the community. You can contribute to the community by joining our test process.

A special thanks goes out to:

- Ben Williams (Southern_Gentlem),
- Jeffrey Tadlock (iWolf),
- Dana Hoffman Jr. (Harley-D),
- Jason Farrell (zcat)

Who have tested this Re-Spin in only 4 days (testing includes running 23 tests twice, per architecture -138 in total).

Please note that this Re-Spin obsoletes the previous F7 Re-Spin by Fedora Unity, "20071030".

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).

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

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

Fedora FUDCon HackFest

After a nice, smooth flight from Amsterdam to Raleigh, via Philadelphia -which BTW is a bad airport to have a three hour stay-over although they do have power outlets, there's no WiFi that I could connect to and tunnel through, and just so happened to have a really long line at Customs-, Jonathan Steffan and myself started the HackFest almost immediately after my arrival ;-)

Today at the "formal" HackFest we've actually accomplished some milestones for Revisor. We've long anticipated the moment we could import livecd-tools and actually start using that, and after pulling the bits from GIT we are now able to do so. Hopefully, this version is going to end up in at least rawhide soon, too.

In addition, we hooked modcobbler back into what is becoming 2.1.0, hopefully soon to be released to rawhide! 2.1.0 has been re-factored to include these modules, which practically enables us to plug-in all kinds of modules without having to re-factor our base application anymore. The GUI at this point is going to become a module to the Revisor base application also. We'll ensure though that 'yum install revisor' does install the Joe User GUI application ;-)

Next up is the rest of the Revisor modules; we'll start with modjigdo and the separate application pyjigdo, just to make sure the Fedora Unity Re-Spin process are smoothened.

Ideas for Spins, anyone?

With Fedora 8 being released soon I was thinking about creating and releasing some more custom spins. Here's what I've come up with so far:

1. Single CD installer
   Really small images that should just get you started on any machine. Right now, using @base and @core it comes down approximately 488 packages, ~530 MB in size. I haven't thought about what packages exactly should or should not end up on the media so if you have any ideas... Let me know!
   
2. CD Sets of the Release Tree (as I did for F7)
   And release them via jigdo, just to prove a point.
   
3. The Everything Spins (as I did for F7)
   CD and DVD sets of Everything in Fedora, again released via jigdo.
4. Truely x86_64
   Media without the i?86 crap you are going to 'yum -y remove' after the installation.
   

I'm going to attempt to build some LiveCD/DVD Re-Spins also but as of yet I'm not sure how well they are going to end up.

Fedora Unity Re-Spins

While we (Fedora Unity) have barely released the 20070912 Re-Spin, containing all Fedora 7 updates released as of September 12th, we have decided to do another Re-Spin release with all updates released up until right now (October 3rd).

One of the major reasons is the new kernel (while the -76 had some libata and vulnerabilities), and because... well... we can.

We can, because creating the Re-Spin is just dead simple -although having any confidence in the Revisor programmer's skills seems to be difficult even when you haven't yet read a single line of code.

At zero hours, I ran:

i386-machine$ sudo revisor --cli --yes --config /etc/revisor/revisor-unity.conf --model f7-i386

and on another,

x86_64-machine$ sudo revisor --cli --yes --config /etc/revisor/revisor-unity.conf --model f7-x86_64

10 hours later, scp'ing bits from one box to another, I have 4 torrent seeds and a jigdo mirror.

We can, although it's just a handful of very dedicated volunteers do the testing. We have a Q&A test matrix containing all installation tests (NFS, HTTP/FTP, Hard Disk and CDROM -times two architectures, times two sets of media). You can only imagine the amount of work involved. Therefore, I'd like to thank those that test our Re-Spins before we release them to the general public. Awesome work!

We can also release CD sets of these Re-Spins, something apparently the Fedora Project hasn't been able to with Fedora 7 or 8 nor will it "bless" the community effort to create and distribute those (x86, x86_64) given that "blessed custom spins" will still need the approval of Red Hat's Release Engineering team, which just so happened to decide to only use their own tools.

We can, although GPL requires us to also distribute the sources of whatever binary we ship. This creates enormous overhead for any small project, or any project with limited resources. Because the Fedora Project distributes under GPL's section 3a [1], while, from a Re-Spin, Re-Mix or Rebrand perspective, it would be much easier for anyone if the Fedora Project distributed under GPL section 3b [2], so that others can use 3c [3]. However, some people try to prevent that from happening because of administrative overhead, disk space (cost) and other nonsense. If you can't store the source packages for a release including it's updates 4 years and one month [4] then ... what? Should the community (read: /me) do this just to show that if I can do it, the leading open source conglomerate should most definitely be able to?

Based on the number of downloads, the positive responses and number of times people come in #fedora-unity or walk up to us at an event, and ask when will we do another Re-Spin should not be underestimated, the community members that download and use our Re-Spins sure are satisfied. That should give anyone on some RH pedestal enough confidence start up a dialog instead of deciding on their own what tools can or cannot be used to create custom spins blessed by the Fedora Project.

[1] GPL Section 3a means offering the binary implies you offer the sources but as soon as you pull the binary offline you can also pull the source offline

[2] GPL Section 3b means you include a written offer with instructions to obtain the sources, valid for three years after releasing the binaries

[3] GPL Section 3c means (for non-commercial distribution) you have received the binaries with a written offer (3b), and you can re-issue that offer to anyone downloading your binaries.

[4] 4 years and one month is: from the moment of release N to the moment three years after the last update will be released for release N (based on a 13 month support frame).

Updating anaconda between releases

Some people use a Fedora 7 DVD or the online release tree and then include updates in the installation media they compose using Revisor, so that when they install using this composed media, they do not have to pull in another couple of hundred megabytes of updates.

These people often report errors to Revisor; some fail to compose a multiple (spanned) media set -such as with CDs- because Revisor shits itself (at least from their perspective) during package ordering, or that the installation fails with a nasty RPM error.

One way or the other, both cases are related to a package being updated on which anaconda and anaconda-runtime depend. One of them is yum, the other RPM. Both important, base software without which Fedora wouldn't be Fedora. But so is anaconda.

What we do (as developers) to try and solve the issue, is;

1. exclude the updated package(s) that break their compatibility with anaconda from the updates and updates-testing repositories in our default yum configuration files. This obviously only gets to the end-users when Revisor releases another update, and since configuration files cannot just be replaced ends up in an unused .rpmnew file.
2. exclude the packages that pull in the package we excluded previously to prevent broken dependencies
   
3. work around the issues that may occur in case the updated RPM is installed on the system doing the compose, and it results in any of these errors (anaconda-runtime's pkgorder vs. the RPM update not allowing duplicates in the transaction).

Meanwhile, we can only close tickets and hope users Google the error message they're getting giving them the work-around. I vote for considering updates to anaconda that solve these issues to be allowed between releases, or to ensure updates to the packages anaconda depends upon or uses, do not break anaconda.

Revisor on Enterprise Linux

Although these are just preliminary results; Revisor (in CLI mode) now also runs on Enterprise Linux 5!

I've composed a minimal Fedora 7 installation CD which (while I'm writing this), is done formatting the partitions of a QEMU guest, and installing packages.

-some time later-
It's booting as well. In the meantime, I've been trying to get live media going on EL5 too, but I haven't managed to get it working, yet.

Tagged nonetheless and built: http://koji.fedoraproject.org/koji/packageinfo?packageID=4446

Spinning Fedora X, X-1 and X+1

In the past, I've been told building Fedora X would require the host doing the building to also run Fedora X. Not Fedora X+1 or Fedora X-1. Really Fedora X. It wouldn't be possible any other way. I assure you it wasn't my grandma or girlfriend telling me this.

Taking matters into my own hands, being the stubborn m-f that I am, I've been successfully building

on F7: FC6, F7 and F8t1 or rawhide
on F8t1 (rawhide): FC6, F7 and F8t1 or rawhide.

I've just not been able to build anything on X-1, but that's it. The rest, I did. And it's my very own application failing to do anything on FC6 because I've managed to create pretty hard requirements towards Fedora 7 or later.

Some of you think: "You didn't. It's impossible. I told you it was impossible. Period."

I'll add to that, that I've not only successfully built these spins -meaning that I didn't get any errors or warnings during the builds-, but they also successfully passed Q&A (although as we know FC6 had bugs in doing certain types of installations, so it didn't really /pass/ Q&A but it did anyway, and of course I'm not sure what Q&A requirements have been set for F8(t1)).

Bingo.

Creating Re-Spins with Revisor

Creating re-spins has never been this easy. Of course we had pungi and livecd-tools to which we had added this GUI thing in Revisor, but since I've re-enabled the CLI mode in Revisor, re-spins go even easier and quicker by just copying these lines:

i386 Fedora 7 DVD:
revisor --cli --model=f7-i386 --dvd \
--kickstart=/etc/revisor/conf.d/fedora-7-gold.cfg

i386 Fedora 7 CD Set:
revisor --cli --model=f7-i386 --cd \
--kickstart=/etc/revisor/conf.d/fedora-7-gold.cfg

x86_64 Fedora 7 DVD:
revisor --cli --model=f7-x86_64 --dvd \
--kickstart=/etc/revisor/conf.d/fedora-7-gold.cfg

x86_64 Fedora 7 CD Set:
revisor --cli --model=f7-x86_64 --cd \
--kickstart=/etc/revisor/conf.d/fedora-7-gold.cfg

And if you want both CDs and DVDs, just append another command line switch! Isn't that just *amazing*?

I'm gonna add to allow more-then-one model from the CLI... Maybe it's useless, but it'll look awesome.

Revisor Enabling Translations

Revisor, having released it's final 2.0.3 version (2.0.3.10 is now in updates-testing), hopefully fixing any bugs in the feature set we had up and until now, has now moved to add all kinds of features to finally, at some point, become available to you in the 2.0.4.x version set.

We have not yet listed our priorities as to what feature we add first, but two things that were not in Revisor yet have always been quite important to Fedora; localization and accessibility.

I'm glad to announce that we've enabled Revisor to be fully localized, with help of Dimitris Glezos (Fedora l10n Team, helped me getting my ducks in a row) and Piotr "Raven" Drag (being the first one to translate Revisor to pl_PL). Now, obviously, we need translators to start translating ;-)

The other feature, accessibility, is harder, I think. If anyone of you that reads this can help us with that, I'd appreciate.

To get the latest and "greatest": http://revisor.fedoraunity.org/documentation/building-revisor-from-source/

Revisor 2.0.3.7 Released

We have released 2.0.3.7 to the updates-testing repositories. I'm not sure it has been build and pushed to the repositories yet.

2.0.3.7 has only bugfixes, and I hope 2.0.3.8 or some other later release will follow shortly, with more bugfixes and the implementation of some of the feature requests we've gotten from users and administrators, and created tickets for:

http://hosted.fedoraproject.org/projects/revisor/tickets/9

Revisor 2.0.3.6 released

From LinuxTag in Berlin, I'm pleased to announce that we've released Revisor 2.0.3.6!

It has been built, and it should hit the repositories soon now! If you're interested, you could join the mailing lists (revisor-users or revisor-devel), or join us on FreeNode, #fedora-unity. Revisor's homepage is at http://revisor.fedoraunity.org (we're looking for people that would like to document things :P).

First Day at LinuxTag

This first day of LinuxTag, I'm not standing at the booth and talking to people, I'm just sitting in a cafe am Messe-Berlin trying to fix the latest bugs in Revisor, sipping away *lots* of coffee and triple lattes and the like ;-). The other Fedora Ambassadors come sit next to me every once in a while so basically I have company all the time ;p

Back to the Revisor topic -I've spoken to Lance from CentOS telling him how cool Revisor is and that I want it to run on CentOS/RHEL as well... Or at least compose CentOS/RHEL media -from a Fedora box maybe? I don't know yet, we'll take a look at it tomorrow.

Anyway, I've taken all 2.0.3 release milestone tickets and fixed them, so that we are able to show off Revisor to the world, or at least that part of the world that is here.

It's 4:34 in the morning now overhere, so I'm going to try and take some sleep ;-) NN!

Does this look like a sane patch to send upstream?

I've been working on a patch to send upstream, to pungi to be exact.

Revisor as a GUI front-end for users allows them to easily create and customize installation media, but actually uses pungi to do so. Pungi, created by Jesse Keating, is the tool to create installation media as it's also being used to compose the official releases made by the Fedora Project. I'm not sure if pungi is also being used for RHEL releases, I think it is.

Anyway, Revisor wants to allow the user to choose the certain type of media to create, ergo CDs or DVDs. While pungi didn't have this option yet, Revisor needs to implement this flexibility upstream. This concludes in a patch, that upstream can choose to apply if it looks sane, or reject if it's insane or doesn't comply with what upstream sees fit.

Anyway, this patch is not just a patch, it really messes with the internals of things pungi does, so I'll need to make sure that my 'cheats' are plausible methods of changing how pungi does things.

I'm not sure this patch will be accepted, but I'm gonna give it a go anyway.

Proof-of-concept patch to pungi

Revisor

Today, I've tried and put together a development roadmap for Revisor, so that we can keep track of things we want or need to do...

When Revisor had been presented at the RH Summit a few days ago by two of Fedora Unity's key members, Robert Jensen and Jonathan Steffan, the responses they got where overwhelming.

While at first Revisor was to become the user interface to upstream tools like livecd-tools and pungi, just to enable the average non-technical user to do themselves the Re-Spins we've been doing and distributing, we are now building some sort of application to do whatever anyone wants to do... user or enterprise administrator. Cool, huh?

You'll probably here more about this later!