Fedora 8 Re-Spin Released

From: http://fedoraunity.org/news-archives/fedora-8-re-spin-released

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 December 18th, 2007. The ISO images are available for i386 and x86_64 architectures via jigdo starting Sunday, December 23rd, 2007.

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

With this particular Re-Spin, we address the following problems experienced by many community members:

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

These are some of the bugs brought to our attention, which you can do by sending a message to me directly, or other Fedora Unity team members in the #fedora-unity channel on IRC.

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/20071218/

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/

Re-Spin 20071211 failed

I usually answer to those who ask if the Fedora Unity Re-Spin is to be released soon, that we are in the middle of our testing process and it might take some time before that process is over as our testers just like me are volunteers who do this in their own free time, and there's actually quite few of them. Not to mention that at any point during that process the Re-Spin might render unusable -we do not want to release crap only to find out too late it is actually crap and then start all over again.

Anyway, to all of you who were waiting on a Fedora Unity Re-Spin for Fedora 8, I can now tell you that we've canceled testing on 20071211 and that it is not going to be released. We have spun 20071218 as a next attempt, it's being distributed amongst our testers as we speak. This means that it will take at least another week before the Re-Spin is released, unless you speed up the process.

Although a Christmas release is nice and all that, to those of you that read this and are waiting (upgrades? i586? cdrom installation using kickstart? anyone?), I'd like you to ask yourself:

Should I step up, join the test-team and check off one of the tests in the testing matrix, or wait until the release and then do the exact same thing but without checking off one of the tests. Am I not doing the work already anyway, with or without this Re-Spin?

I believe someone out there does NFS installs on a daily basis. Can we tempt you to try our Re-Spin for a change and let us know how it's holding up? Anyone who does HTTP/FTP installs regularly? Same offer ;-)

Again, this Re-Spin will not hit the public until we've verified that there is no regression compared to stock F8. You can help us (and others) by doing what it is you normally do with Re-Spins or installation media, and telling us what it is you did... Think about it ;-)

Re-spinning Fedora

Here's a brief overview of what it takes to seriously Re-Spin Fedora. Fedora Unity has done so for a long time now, and not just for home use, but to distribute amongst a larger audience. The reasons we started and continue to do so are obvious, amongst others:

• The number of updates available to any freshly installed system (from officially released media) increases over time and rises up to 2 GiB. We believe there is no reason why anyone shouldn't be able to have these updates on the installation media already, thus decreasing the amount of updates available immediately after installation. This is a matter of convenience, as well as bandwidth and data traffic; bandwidth and/or data traffic in some locations in the world isn't as cheap as you might think, and some of us do not even have internet -those usually get a Re-Spin via the FreeMedia program or get it from a friend.
  
  Another compelling 'update available' issue is this one special piece of software, the kernel. Given the latest kernel being installed on your system right-away, it saves you from having to reboot to run that latest kernel. Some of us (depending on the hardware you want to install on) need installation media built with the latest kernel just so that networking works, acpi and storage fixes or new hardware is recognized properly.
  
  
• There will always be a number of bugs in the officially released installation media -as will there be in our Re-Spins, just (hopefully) less. That's just the way it is, bugs happen, it's the price you pay for moving forward as much as Fedora does. And that's a good thing. Without that you probably wouldn't even want Fedora in the first place. In case it prevents some users from installing or upgrading their systems, we feel we can make an effort with our Re-Spins to fix these bugs for these users.
  
  
• While we make the effort of Re-Spinning Fedora, and distributing it properly (GPL compliance and all that), we hopefully prevent that hundreds or thousands of others also Re-Spin, each of them re-inventing the wheel when issues with Re-Spinning come up, back-porting fixes or tracking bugs being solved in packages, etc.

This and other things make what we do a very challenging and rewarding task. And we love it!

So, what does it take? What does it take to Re-Spin, and once you've done that, to release the spin to the general public?

First of all you gotta have hardware. We now have i386, x86_64 and PPC available, although we only release i386 and x86_64 this time. Second, you need some bandwidth to distribute whatever product comes out of the process -without bandwidth, distributing the product amongst people testing will become a large bottleneck at some point. Third, you need a couple of volunteers backing you up. Fedora Unity just so happens to have a couple of volunteers, I'm just one of those. These volunteers do what they can to help getting things done, and that isn't limited to Re-Spinning Fedora (at all), given the Fedora Unity mission statement. Some of us help distributing by donating disk space and bandwidth, others keep our servers running or help testing, tracking and resolving bugs, and help documenting stuff to help you getting other stuff done.

For this latest Re-Spin -which we are about to release unless a serious bug pops up in our testing process-, I'll tell you how it went down.

We started harvesting bugs related to installation procedures about 3 weeks ago, verifying that fixes applied would help solving the issue during install time. About two weeks ago, I started composing Re-Spins with fixes in anaconda being back-ported from development into F8 stock anaconda, and listed the bugs I was interested in solving with this particular Re-Spin attempt. I think I did a number of blog-posts calling for people that experienced those bugs and asked them to start helping in testing on whether these bugs had been resolved -some of you actually responded and confirmed bugs being fixed (Thanks to all of you!). I started with Re-Spin '20071204', which didn't solve anything, then composed '20071207', which had one bug solved, I did '20071209' -which didn't satisfy me either, only to come up with two sub-sequential Re-Spins versions '20071211', the latest of which is the version in our testing process now.

Mind that each of these Re-Spins takes about 4 hours maximum to compose, and each of them have some preparation time in investigating why a previous Re-Spin did not fix what it was supposed to fix, attempt fixing it and getting it into a Re-Spin. Basically, composing each Re-Spin takes about a day of investigating, composing (fairly unattended, just check progress every once in a while), preparing for distribution and actually distributing it. Then it takes another day for our testers to test if a certain issue had actually been fixed.

Now that our final version is in the testing process, namely '20071211', a couple of tests need to be run against it. This is our Fedora Unity Re-Spin Q&A sorta speak. We're talking about 22 tests for each architecture, so 44 tests in total as we do i386 and x86_64, each having to be verified by preferably two of our testers. You can imagine the burden on our testers, and the more testers we have for this stage of releasing a Re-Spin, the less time it takes to get all these tests done.

For a matrix keeping track of tests being performed and ACK'd by our testers, check the matrix by our Test team lead, Ben Williams. You can only imagine the amount of work these guys get done.

As I said, since December 11th 2007, our Re-Spin is in testing and we could use some more volunteers to join us, if only you are not running a particular test but join the test team and just use the Re-Spin for your daily system installations and give us the feedback.

Concerning this re-spin, a big thank you to:

• Robert 'Bob' Jensen (BobJensen or EvilBob -testing the PPC images)
  
• Ben Williams (Southern_Gentleman -testing, testing and testing some more)
• Jonathan Steffan (daMaestro -keeping our websites and servers going, developing software that gets this stuff done)
• Dana Hoffman Jr (Harley-D -testing, testing and testing some more)
• Yves Desgagne (confirming the 'cdrom' installation source issue)
• Keith G. Robertson-Turner (confirming the i586 bug #367731)
• Stewart Adam (developing software that gets this stuff done)
  
• ... and all others pointing me to bugs they need to be resolved with our next Re-Spin
  

i586 install/upgrade issue fixed, next issue please

The installation and/or upgrade issue with anaconda on i586 hardware has been confirmed fixed! (you can't imagine how happy that makes me ;p)

Keith G. Robertson-Turner, a community member that had some i586 hardware and wanted to upgrade to Fedora 8 took a chance trying to upgrade using our first attempt to fix the issue in a Re-Spin (20071207), which failed miserably. With 20071209 though I finally nailed the issue, as he has now confirmed he was able to upgrade to Fedora 8. Thanks Keith!

One other issue we are definitely trying to solve with the Re-Spin is the yum dependency resolving bug. We've tried composing with yum-3.2.7-1.fc8, yum-3.2.7-2.fc8, and finally with yum-3.2.8-1.fc8, we have these lying around on some archiving file-server. As none of these versions fixed anything related to the dependency resolving, we are now trying to create a Re-Spin with the updates.img provided by Jeremy Katz in #372011.

Again, feel free to mail me concerning any other issues you experience, that you think might be resolved with a Re-Spin. Give me a bugzilla bug number that I can watch or has been resolved, or a package's changelog entry, anything related to fixing things ;-)

Look for Fedora Unity's official Re-Spin Release, solving at least these two major issues, it'll be up on the appropriate mailing lists and websites once we're ready.

Fedora 8 Re-Spin in the making

A Fedora 8 Re-Spin is in the making, and as often we have a couple of issues we want to resolve with this Re-Spin:

• An update to SELinux enables upgrades from Fedora 7
• Updates to pykickstart that prevent errors from occurring when using the 'cdrom' installation source
  
• An updated kernel (of course)
• The famous upgrade loop (#372011, amongst others)
  

These are not all bugs in stock Fedora 8 that we want to resolve, but just the ones we've been pointed to by other community members. Just so that it is clear; we do need you to let us know what it is you want resolved in a Re-Spin, or otherwise, possibly, we end up with a Re-Spin being released that still has the bugs or errors you wanted to see resolved.

On of these bugs is related to i586 hardware, on which anaconda would be unable to perform an upgrade according to #367731, due to selecting the wrong glibc and/or openssl package for this specific arch. While, as you know, anaconda doesn't get updates during a release cycle, we backported the fix for this issue from anaconda development into Fedora 8 stock anaconda (11.3.0.50-2), hoping to resolve this issue. Obviously in this case we need people to test the fix to actually fix the issue, as we ourselves to not have any i586 hardware.

The same however goes for all the other issues we try to fix in a Re-Spin, lots of which we don't even know about (and thus cannot test for), and others we cannot reproduce and thus not confirm resolved.

If you are willing to help us in this quest, or know of an issue we might be able to take into account when doing a Re-Spin, please let us know via email, or visit us on FreeNode in #fedora-unity.

Sneak Preview: The Fedora 8 Everything Spin

At this moment I'm finalizing some tests before I release the Fedora 8 Everything Spin. Although I don't think there's a valid use case for a CD version of this Everything Spin, I spun it anyway and once I saw the result (during testing), I could not in good conscience withhold a screen-shot; so here it is:

Fedora Unity Spin Report

I love statistics so here's some numbers on the Fedora Unity Spins for Fedora 7 and 8:

Our Fedora 8 CD Set jigdo has been downloaded over 350 times, while our latest Re-Spin has been downloaded almost 300 times.

From the raw numbers I can conclude though that not everyone who downloads the .jigdo actually uses it and downloads the corresponding templates. What we see is that 300 downloads started for CD #1 (both architectures), which is obviously the only disc everyone needs to download. The issue might be that people don't know how to use it, I'm not sure. For our multi-ISO .jigdo files though we do not have a good GUI client at this moment, so I'm hoping pyjigdo improves in that aspect during the Fedora 9 development cycle.

Also, while 300 downloads have been made for CD #1, only 115 requests have been made for the other 4 to 5 discs in the set. This indicates almost 2/3 of all people that download CD ISO images want a single CD to install Fedora. As said before, the next thing is Single CD Installation Media (ideas are still welcome).

Lessons Learned

From Fedora Unity's CD release for Fedora 8 we've learned the following lessons:

1. Generate i386 templates first, then x86_64 templates
   Not doing so will cause i386 bits to be leeched from the x86_64 repositories for reasons related to how generating the templates and slices work, and is confusing to users.
2. Do not generate the ISO templates against a loop-mounted DVD ISO, as files such as "TRANS.TBL" are in the loop-mounted tree but do not exist in the expanded tree that is available on the mirrors.
   The user will end up with missing files.
3. Replace occurrences of "+" in the .jigdo file with "%2B" because otherwise "wget" (used by the jigdo client) will request the wrong file (resulting in a 404 and thus an incomplete ISO re-compilation).

Needless to say that with these errors the .jigdo files including the .template files will be regenerated and within the next hour everything should be OK.

So what takes me 5 hours?

In my previous blog post, I mentioned that after 5 hours Fedora Unity releases CD sets. What makes us be so late? I had the bits, I could have started earlier... But I didn't.

Then when I finally did start composing the CD media, it seemed one would need disc 1 though 5 (!) to perform a default install. That couldn't be right, could it?

Figuring out in what order to select groups during the package ordering stage, a commute home and a dinner later, it finally hit me. You gotta know though that it takes a couple of test installations to see if you fixed the problem or not. Each takes me about 30 minutes on my laptop...

Finally though, the work is done. Now, distributing bits from my internet connection at home isn't a funny hobby, but it's out there. Yes!

The point behind this whole exercise was not to respin the DVD into a CD set. Because we were going to distribute the product via Jigdo, I had made a goal out of having as much bits as possible distributed via the official Fedora Project mirrors. As you might know Revisor rebuilds the installer, and once those kernel images and installer images differ from what is on the Fedora Project Mirrors, you're looking at a 160 MB template just for one disc. Now though, the template for CD1 is approximately 20 MB, and the other discs are just a few KB.

CD Sets Released

Within 5 hours after the official release of Fedora 8 (the 8th wonder in the world), I'm glad to be able to announce that Fedora Unity has released the CD version of this wonder!

This time, instead of using a torrent with a few weak seeds we've decided to use the mirrormanager power and release via Jigdo. This could make a nice proof-of-concept for Fedora 9, too.

Even if you have DVD drives, you may want to launch a jigdo client and start downloading, just to see what happens. Let me know ;-)

Go to http://spins.fedoraunity.org/spins/ to start downloading it.

Coming up next: Single CD Installers

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.

Master Kids?

My girlfriend has just gotten her master title in Science, "cum laude" -for exceptional achievement meaning she has 8.0 average on a 1 to 10 scale. Awesome!

I wonder whether any of our future kids -should we get any- turn out to be that smart and intelligent and how many of them are going to contribute to Fedora. At what age should I start pushing them? Any recommendations? ;-)

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

Yum behaviour change

When you want to ensure you have the latest version of a package installed, you would configure puppet as follows:

package { "ypbind":
ensure => latest
}

What puppet does, is execute yum as follows:

yum -d 0 -e 0 list available ypbind

If it gets any hits, the package is either available for installation, or eligible for an update, so it'll install the available package. If no packages are "available", it'll just continue like normal.

You will most likely have some file or service definitions depending on the "availability" of the package:

file { "/etc/yp.conf":
source => "puppet://$server/files/yp.conf",
require => Package["ypbind"]
}

service { "ypbind":
ensure => running,
require => Package["ypbind"]
}

When puppet ensures the package to be installed before executing any of the depending definitions, it assumes that yum exiting without any error code is equivalent to the (the most recent version of the) package being installed on the system, and any error code means it can't be done (and thus: not execute the depending statements).

Lately however, yum does throw an error code if there is no package "available" (for installation), and thus all puppet dependencies for that package fail.

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.

NetworkManager and NetworkManagerDispatcher

Imagine you connect your laptop to your home network and you want to authenticate against nis.home.org, using automatically mounted home directories from fileserver.home.org. The following morning, you arrive at the office and connecting your laptop to the network there, you wait for ypbind to bind to nis.home.org (which just so happens to be unavailable), and you cannot log in directly as your home directory cannot be mounted (because fileserver.home.org just so happens to be unavailable too). In addition, your office uses LDAP authentication and has a group data share you want to mount.

I'm guessing you'll need to at least disable ypbind, and maybe change authentication configuration and start using LDAP. You're also probably gonna want to mount that group data share and not automount your home directory from some NFS share.

Are you performing all these changes by hand? Does your office allow you to change it all? How does the office manage to support all that? I don't know.

What I do know is that I personally have a similar use-case with my laptop that I want to be able to connect to my home network having NIS and autofs, while not having to change the system configuration when I'm 'offline' -not connected to my home network.

I've begun to use the NetworkManagerDispatcher: it allows me to execute some scripts that would be able to detect wherever I am and adjust my system configuration accordingly. I'll call it NetworkManagerDispatcherScripts (don't try and say that out loud very fast, twice). There's a proof of concept piece of code at http://git.kanarip.com/?p=nmdscripts/.git which you can get with;

git clone git://git.kanarip.com/nmdscripts/

Execute the ./nmdscript script and see if you're connected to one of the pre-configured networks (which all apply to my home networks). Until now, it's just detecting some network characteristics and not executing any system configuration changes, and I'm just curious what anyone thinks about it.

Unluckiest person for RH302, ever

Originally, I had planned to take RH300 (RH302 including the Rapid Course Track) July 9th. When it seemed that a FUDCon was to be held starting July 13th (the day I would have taken the actual exam RH302), I canceled my seat and planned for a long stay at Raleigh, NC -which at that time was the location where FUDCon was to be held. Then, as you all know, FUDCon was moved to either 3-5 August, or 10-12 August, and I really hoped and lobbied for the first weekend, because I knew July 27th, there was a RH302 too. Instead of staying a week longer and then take the RHCE Exam, I'd have arrived a week earlier and took a jet-lag exam trying to pass for RHCE.

Back to the original point of the post; since all that was canceled, I tried to get back a seat in the RH300 course I had planned originally -July 9th. I succeeded ;-)

After a 4 day RHEL5 internal workings re-cap, I thought I was ready to take the exam. I'll tell you right-away, I didn't pass.

Half-way through the exam, the network failed. Not just my network, but the entire network. Obviously, that sucks. The exam got canceled but I gotta say: That shit just happens, there's nothing anyone could have done about it.

Anyway I had to re-take the exam at some later day and of course the sooner the resit, the better. Red Hat apparently had some trouble re-scheduling for today, July 27th, which would have been the first opportunity, if not the RH300 course track planned for that week had been canceled. They told us the next (sure) opportunity would be August 17th (that is a 5 week wait just to re-take the exam), and that they'd try to arrange something for July 27th.

Just now however I got an email from Farnborough asking me why I couldn't attend the resit today, because they seemed to have missed me. I didn't know there was a resit today. I didn't get any seat confirmation, invitation or notification, whatsoever. I didn't get any for August 17th either. I sure hope I get a chance to pass RHCE some time, hopefully without too much trouble ;-)

I seem to be the unluckiest person wanting to take the RH302 exam, ever ;-)

Developing in Fedora

You'll usually start developing some feature or application because you think you can create something or improve something else. You'll probably get excited and talk about it and at some point, come across the people that you thought know it all and will catch your drift and help you accomplish whatever it is you want. I've been proven wrong there. Mind that I'm developing a customization tool build upon existing release engineering tools, this doesn't hold up for entirely new tools.

The real test isn't the code. The real test isn't all the bugs you'll get either. Neither does it concern you, what huge pile of feature requests you'll get, or what number of bugs will show up once you try and implement some of these requested features, breaking other stuff in your code. Hell, there's no challenge in doing it 'enterprisey' either. The challenge you had in mind was to get things done, to move forward. That is what it is all about, and that just so happens to be what you're really good at.

Neither of all that is a real challenge, believe me.

The real challenge is to continue working as you see fit, because you'll get flamed from all sides that has people with a different perspective on things. The real challenge is to withstand the temptation of just quitting.

Continuing on building a customization application upon release engineering tools; I'm sure you can appreciate the different perspective on things. Whereas release engineering tools need to be stable and consistent, customization tools can just have their way with it. Don't overestimate the number of features you can add to a release engineering tool; it doesn't need all that, the tool works as is, so your life then is about discussing the need for this or that feature in some upstream tool, not about doing the code and solving the bugs. You'll give up eventually. You'll let them pull whatever they like from your tool.

This is the Fedora world, where everything moves forward fast, faster, fastest. It's a community distribution that does cutting-edge in stable, and for which enterprise linux engineers decide what progresses slow enough to keep track off changes, or what is too fast to really be allowed to be build upon whatever they are on the receiving end of bugs for.

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!

I lost my Atheros wifi card!

Everyone's had it... Buy some Wifi Card and find out there's no Linux drivers that work with your favorite flavour... I just had a similar experience yesterday; I lost my X-Micro card (Atheros chipset), and all I had left was my Speedtough 110 (no typo). It just won't work.

So I spent the rest of the day looking for the X-Micro card, and I ended up tidying half my house then finally finding the card I was looking for, only to find out that when I inserted the card and went to install the drivers, my rawhide machine (or actually the F7 kernel), could not install madwifi because if wasn't build against rawhide yet, no surprise there. A previous version of madwifi however, build against an older kernel, would not load because of something with 'hal' -don't ask me. Again, no real surprise here either.

So I installed the latest fc6 kernel, which I know madwifi has been built against. While expecting major problems due to some package in fc6 vs. f7 requiring a f7 kernel, I was surprised to see it work.

It just works! I'm glad to know that I'll be able to do some Revisor tricks at LinuxTag, and still have networking ;-)

Ook maar eens een blog begonnen

Hij doet het! (Uhh, ja doh!)

Ik doe vandaag weer eens een poging een blog te starten. Eigenlijk is de voornaamste reden dat anders mijn Mugshot zo leeg is. Maar waarom neem ik dan een account op Mugshot? Weet ik ook niet!

Nu zien te zorgen dat niet iedereen te weten komt wat ik allemaal doe... *achterom kijk*