A colleague of mine blogged about the installation of W2k8 Hyper-V (in Dutch) and as such ended up in a mailing that I get too.
While reading his blog entry, I wondered whether it would be possible to use that same ""IT-Professionals Community Blog"" blog as they call it and post about interesting, real technical stuff and improvements... you know... Innovation and stuff. I felt I had a right to do so; I get the mailing because I'm M$ certified, now give me a M$ blog to let me put out the (correct) message.
However, trying to register, this is what I get: http://blogs.microsoft.nl/msgs/default.aspx?MessageID=29 while clicking on http://blogs.microsoft.nl/user/CreateUser.aspx?ReturnUrl= (which to me is the Join link)
Try it yourself, see what a M-$tyle community blog looks like.
Thursday, October 9, 2008
Monday, June 16, 2008
Friday, June 13, 2008
Linux Kenniscel Coordinator bij OGD
Ik ben sinds deze week de nieuwe Linux Kenniscel Coordinator bij mijn werkgever, Operator Groep Delft (OGD)
Dit betekent dat alles wat met Linux te maken heeft bij dit detacheringsbedrijf (overigens de nummer 1 in beheer -Computable ICT Services Guide 2008) langskomt, van partnerships tot gesprekken met klanten en leveranciers... Wel even totaal iets anders dan tot op heden, met mijn "hier-is-een-regel-code-die-toffe-shit-doet" insteek.
Het betekent wel dat ik iets vaker naar het kantoor in Delft moet dan dat nu het geval is voor cursussen die ik geef, maar aan de andere kant bevindt ik me binnen OGD nu opeens wel in het centrum van mijn kleine universum.
Er staat een hoop op stapel, maar voordat ik mijn tanden ergens in kan zetten wat betreft mijn nieuwe rol zal ik eerst gevierd moeten worden op de Red Hat Summit en de Fedora User and Developer Conference.
Dit betekent dat alles wat met Linux te maken heeft bij dit detacheringsbedrijf (overigens de nummer 1 in beheer -Computable ICT Services Guide 2008) langskomt, van partnerships tot gesprekken met klanten en leveranciers... Wel even totaal iets anders dan tot op heden, met mijn "hier-is-een-regel-code-die-toffe-shit-doet" insteek.
Het betekent wel dat ik iets vaker naar het kantoor in Delft moet dan dat nu het geval is voor cursussen die ik geef, maar aan de andere kant bevindt ik me binnen OGD nu opeens wel in het centrum van mijn kleine universum.
Er staat een hoop op stapel, maar voordat ik mijn tanden ergens in kan zetten wat betreft mijn nieuwe rol zal ik eerst gevierd moeten worden op de Red Hat Summit en de Fedora User and Developer Conference.
Monday, May 19, 2008
Dear Clayton Brown
Dear Clayton Brown,
next time you launch a website, or platform, or planet, don't harass people with your spam. You require action from the users reading your email - which besides being *just wrong*, I think is very sick. Plain and simple.
You offer opt-out, instead of opt-in, which I think is not at all respectable. It shows you incapable of doing the right thing. Needless to say, I've opted out to prevent any future communication with you. You can leave a comment though, as I'm sure you are reading this (Quote) "Your blog Some FUD of my own caught our attention." Right, I'm sure it did. NOT. I doubt you'll ever hit this blog again.
You offer people to claim what you are harvesting from the web, like it isn't already theirs. If they do, how many of them realize their home address is public, and choose to have it that way, you think? I guess you did not find it worthwhile warning your users for this little side-effect. In fact, it isn't even mentioned anywhere in your spam.
Thanks for playing your part in giving Web 2.0 a boost to Web 666.
next time you launch a website, or platform, or planet, don't harass people with your spam. You require action from the users reading your email - which besides being *just wrong*, I think is very sick. Plain and simple.
You offer opt-out, instead of opt-in, which I think is not at all respectable. It shows you incapable of doing the right thing. Needless to say, I've opted out to prevent any future communication with you. You can leave a comment though, as I'm sure you are reading this (Quote) "Your blog Some FUD of my own caught our attention." Right, I'm sure it did. NOT. I doubt you'll ever hit this blog again.
You offer people to claim what you are harvesting from the web, like it isn't already theirs. If they do, how many of them realize their home address is public, and choose to have it that way, you think? I guess you did not find it worthwhile warning your users for this little side-effect. In fact, it isn't even mentioned anywhere in your spam.
Thanks for playing your part in giving Web 2.0 a boost to Web 666.
Wednesday, January 30, 2008
Fedora Unity Blog
Fedora Unity has brought another blog to this world, to which I'll be posting all Revisor and pyJigdo and other Fedora related content soon-ish, so that I can use this blog for my own personal stuff -and not bother you with it ;-)
Check out http://blogs.fedoraunity.org/kanarip/first-serious-entry, which explains why anyone doing Fedora 8 installation media spins is unable to start the graphical installer when booting the media.
Check out http://blogs.fedoraunity.org/kanarip/first-serious-entry, which explains why anyone doing Fedora 8 installation media spins is unable to start the graphical installer when booting the media.
Thursday, January 24, 2008
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 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/
Saturday, January 12, 2008
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.
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.
Sunday, December 23, 2007
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/
Tuesday, December 18, 2007
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 ;-)
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 ;-)
Saturday, December 15, 2007
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:
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:
- 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.
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
Tuesday, December 11, 2007
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.
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.
Sunday, December 9, 2007
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:
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.
- 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)
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.
Wednesday, November 14, 2007
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:
Sunday, November 11, 2007
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).
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).
Saturday, November 10, 2007
Lessons Learned
From Fedora Unity's CD release for Fedora 8 we've learned the following lessons:
- 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. - 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. - 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).
Thursday, November 8, 2007
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.
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
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).
Subscribe to:
Posts (Atom)