- 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.
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:
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).
Thursday, August 30, 2007
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
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
Friday, August 3, 2007
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.
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.
Subscribe to:
Posts (Atom)