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.
Thursday, November 8, 2007
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
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
Tuesday, November 6, 2007
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:
- 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! - CD Sets of the Release Tree (as I did for F7)
And release them via jigdo, just to prove a point. - The Everything Spins (as I did for F7)
CD and DVD sets of Everything in Fedora, again released via jigdo. - Truely x86_64
Media without the i?86 crap you are going to 'yum -y remove' after the installation.
Saturday, October 6, 2007
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? ;-)
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? ;-)
Wednesday, October 3, 2007
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).
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).
Tuesday, September 25, 2007
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.
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.
Wednesday, September 12, 2007
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;
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;
- 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.
- exclude the packages that pull in the package we excluded previously to prevent broken dependencies
- 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).
Subscribe to:
Posts (Atom)