In other news, I'm working on a presentation for how to do this stuff that will be presented at FUDCon Boston. Hopefully we can get some new contributors with great documentation! This really isn't some magic science, it's really simple stuff!
May 2008 Archives
- Paul Frields, Our fearless leader. Under his leadership, the GPG signing requirement of the CLA was lifted. This was a major barrier to entry to Fedora, that is now gone.
- Mike McGrath, team lead of the Infrastructure project - Mike has done a great job of nurturing the actual scripts that are doing the transition from Moin to MediaWiki, converting the markup and such.
- Máirín Duffy - She did a lot of the CSS and stylistic work that went into the new template
- Ian Weller - Ian did a ton of work on the template, problems with conversions (there were a ton of these). Without his wealth of MediaWiki knowledge, this would not be the success that we anticipate it to be. Ian has also written several MediaWiki plugins just for this deployment!
- Ricky Zhou - Ricky has done a lot of great work on FAS2 (the replacement to the old Fedora Account System). His latest work directly related to this deployment was the FAS OpenID provider, which he's putting the finishing touches on as I type this :). This will be in beta for this deployment, eventually it will be required, however.
Great work everyone! (and after Tuesday, we'll just be sitting back on the beach drinking our Mai-Tais - NOT! :) )
I've heard through the grapevine that I may have issues with it in F9 due to the Intel GMA965 graphics - I thought that would be a safe bet. Any comments as to what exactly the issues are?
Oh well, I'll count on folks like Seth and Karsten to counter my bad ways :)
Good news being, we‘ve got a replacement now - we're going to the tried and true, battle tested MediaWiki. There is a conversion script for Moin that was available, and was modified by Mike McGrath to fit our needs. Máirín Duffy anad Ian Weller did all the template work, and I just sat back and made sure everything I was interested in rendered correctly :).
Now the time has come for everyone else to see that things have rendered OK. There are a few known issues with this incarnation:
1) The license tag at the bottom says CC-BY-SA, this is not correct, we are not relicensing the content. This will be correct soonish.
2) Where the Art team did banners for various projects, those are replaced by HTML at this point. Those will have to be manual conversions to MediaWiki templates. We can no longer allow embedded HTML in the wiki (it had been on the table for some time to remove the capability, there are inherent security issues in it).
Without further ado, you can testdrive the new wiki here. This is going live soon, like 2-3 weeks soon, so get your feedback in!
Next, it installs. I login, and find this:
[jstanley@dhcp-137 ~]$ cat /etc/redhat-release
Enterprise Linux Enterprise Linux Server release 5.1 (Carthage)
For something so 'in your face', I'd expect Oracle to be ashamed of themselves. They just seemed to have replaced 'Red Hat' with 'Enterprise Linux' without regard to whether or not it made any sort of sense. Same throughout the installer, really, except they just replaced Red Hat with nothing.
This really seems like quite a shoddy product to me. I've always thought so, and now that I've seen for myself, I KNOW so.
Oh, and by the way - this was the 100th post to this blog. What a pitiful thing to waste it on.
Some of the features that I'm most excited about:
- Xorg 1.5
- Anaconda encryption of the root filesystem
- Improved NetworkManager
- Gnome 2.22
- Live persistence
- New GDM
- Partition resizing via anaconda
- And perhaps most importantly, Firefox 3!
As mentioned previously in various announcements about the Bugzilla actions that are being undertaken, we will begin phase 2 shortly. Instructions on how to opt-out of these changes are below, as well as links to wiki pages that contain precise information on when the actions will begin, what actions are to be taken, and the queries used to select bugs to act upon.
1) Close all bugs INSUFFICIENT_DATA that are still in NEEDINFO from the "stale rawhide" cleanup (http://fedoraproject.org/wiki/BugZappers/F9CleanUp/RunTime#stalephase2). Precautions are being taken to ensure that bugs had activity, however were never taken out of NEEDINFO from the last round of actions are not touched.
OPT-OUT: Changing the status to any other than NEEDINFO.will avoid having the bugs touched,
2) Close all bugs in ANY state that are filed against an EOL version (http://fedoraproject.org/wiki/BugZappers/F9CleanUp/RunTime#eolphase2)
OPT-OUT: Changing the version to '8' or 'rawhide' will avoid us making any changes to this bug.
Note that the following two actions are part of the BugZappers release SOP, and are being undertaken independently of the activities above (and will take place for every subsequent release to ensure that Bugzilla remains in good working order and useful to all parties):
3) Rebase all rawhide bugs (except for those that are Package Reviews or RFE's) to Fedora 9. Note that Bugzilla notification mail will be suppressed for this change - i.e. no one will receive mail that this has occurred except for this one. This is in direct response to community feedback that we were spamming them with unnecessary notifications. (http://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora9#frebase)
OPT-OUT: If this is an RFE, then add the FutureFeature keyword to the bug, and no action will be taken on it.
4) Post a warning about the impending end-of-life of Fedora 7 in all bugs filed against F7 (http://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora9#f7warning). Paul Frields recently mentioned this, this comment will merely act as a reminder and final warning of this fact. 30 days from the date of this running, all remaining bugs that are opened against Fedora 7 will be CLOSED WONTFIX.
No opt-out really applies to this, however, if the bug still applies to a later release, feel free to change the version to the later release and the comment will not be changed
If you have many bugs to change as a result of these procedures, feel free to drop by #fedora-qa and we will guide you through changing them all at once.
Also note that we have conducted a thorough post-mortem investigation of all the spam that was generated last time, and have identified and repaired the problem. There will be only one notification per bug this time around :).
Rest assured the BugZappers are are not doing this on their own and this process has been carefully reviewed the leadership of the Fedora Community. If you believe this process should be changed, like all things in Fedora, feel free to propose patches to the existing process or create a new proposal which can be evaluated and discussed for the Fedora 10 release cycle.
So here's what I got (note the 5/22/08 over there, that's the estimated ship date :( ):
|42X5952||SBB INTEL CORE2DUO PROC. T9300|
|42V8012||VBB MS WIN VISTA HOME BASIC|
|42W7293||SBB MSWINVISTA H-BAS32 US ENG|
|42V9324||SBB 14.1WXGA +TFT,W/OCAM|
|42X5956||SBB INTLGMA X3100 GM965W/1394|
|41W2068||VBB 4GB PC2-5300 667MHZ 2DIMM|
|42V8195||SBB KEYBOARD US ENGLISH|
|42W7033||SBB ULTRANAV(TRCKP+TOUCHP) +FINGR|
|42V8712||SBB 100GB HDD,7200RPM|
|42V8718||SBB DVDREC.8XMAXDUAL L.ULT.ENH|
|42V9338||SBB 6 CELL LI-ION BATERRY|
|41W1787||SBB CPK NORTH AMERICA|
|42W7087||SBB LP,US ENGLISH|
I have nothing but a small stackable washer and dryer in my apartment, so doing all of the laundry that has accumulated that doesn't absolutely have to be done is going to take weeks if I were to undertake the entire endeavor.
What, exactly, is a laundry bankruptcy and how does one declare such a thing? Fortunately, there are no costly lawyers involved, nor is your credit tarnished for 7 years. Rather, one feels better immediately after declaring laundry bankruptcy. You know that you're a candidate for laundry bankruptcy when the mountain of laundry in your apartment is taller than you are (no, not really my case, but you get the point). So how does one declare laundry bankruptcy?
The procedures may vary slightly, depending on where you live. The gist of it, though, is a trip to the local laundromat. You can either do the laundry yourself there, or, for a fee, they will generally do the laundry for you and you can pick it up later. After all, is doing umpteen loads of laundry really worth my time and effort? I don't really think so.
After all this is done, I'll probably have enough clean clothes for a year! :)
I had mentioned in a previous post about doing QA for Fedora, and having installation CD and DVD sets available prior to the general release of the distribution. All that Fedora Alpha, Beta, and Preview Release really is are just snapshots of the daily development tree of Fedora, rawhide. Sometimes, it might be useful to have a DVD, similar to what Fedora release engineering would produce, of the current rawhide. Now, I'm going to give a step-by-step of how to do this in 'mock', which is a program that you can use to manage chroot's. Mostly, it's used for building binary RPM's from source RPM's, however, it has grown functionality that make it useful for doing composes recently.
There are some things that pungi does that depend upon several things that make it very suitable to be run in a mock chroot. First, the distribution that you are composing and the distribution that you are composing on have to be the same, For instance, if you wish to compose rawhide, you have to be running rawhide (or at least have rawhide userspace). Also, the architecture that you are composing on and the arch that you are composing must be identical (you can't compose i386 on an x86_64 system, for example). Mock allows us to overcome both of these limitations (at least for compatible arches - i.e. x86_64 and i386). A mock chroot can have userspace that is very different from the host system, and so long as the arches are compatible, they can even be of a different arch (i.e. you can run i386 code on x86_64, but not the other way around, obviously).
The only thing that we have to do on the system that is going to produce the trees is to install the 'mock' rpm. This is as simple as typing 'yum install mock' at the command line. On my system, I also prefer to have the bash-completion package installed, because mock is 'completable' by that package, and the buildroot names can get kinda long sometimes (or am I just lazy?) :). After this is done, you need to make sure that the user that needs to use mock is in the 'mock' group. This is because being able to use mock is equivalent to having root on the machine in question, since mock is SUID (and has to be), You can accomplish this with 'gpasswd -a jstanley mock' for example.
The next thing that we need to do is initialize the chroot. This is very simply done by using 'mock -r (config)
Now we have a chroot with the desired content in it, we can install pungi. Wait a minute, this is in a chroot (and yum is not installed by default in this chroot), so how do I do that? Good thing mock has the '--install' option. So you just execute 'mock -r
[jstanley@rugrat ~]$ mock -r fedora-rawhide-x86_64 --shell
INFO: mock.py version 0.9.7 starting...
State Changed: init plugins
State Changed: start
State Changed: lock buildroot
The 'mock-chroot>' is my shell prompt, reminding me that I am in the chroot. From here, we can use pungi. The reference kickstart files that release engineering uses to create the releases are included in the fedora-release package, and can be found in the /usr/share/fedora-release directory. The traditional DVD configuration, which is what you want to use, is called f9-fedora.ks (note that this just landed in the fedora-release package on Friday). One piece of housekeeping that needs to be done at this point in to remove the generated rpm database files. If you are building on your native arch, this isn't strictly necessary but still a good idea. If you are building i386 images on x86_64, not doing this is fatal.
mock-chroot> rm -f /var/lib/rpm/__db.00*
At this point, we can execute the pungi command:
mock-chroot> pungi -c /usr/share/fedora-release/f9-fedora.ks --destdir=/compose --nosplitmedia --nosource
I'll take you through what these options do:
--nosplitmedia - I do not wish to generate split (CD-sized) media for this compose
--nosource - I don't want to gather source code for this compose. Note that you MUST NOT use this option if you plan on distributing the resulting discs. Note that by eliminaiting this option alone, source ISO's will not be created, that's an additional step that I'll mention below.
When you enter this command, pungi will go about four phases of operation:
- Gather the RPM's and SRPM's as required
- Create a yum repo out of those
- Run the anaconda 'buildinstall' tool to generate installation images, etc
- Create ISO's
Using a local mirror and a reasonably fast computer, this will take about 30 minutes. Note that every RPM that would be included on the DVD is downloaded, so having a local mirror REALLY helps here. Not a show-stopper if you don't have one, but it will take longer than 30 minutes :). One word of warning, though - when the compose gets to the point of running buildinstall, it will look like it's hung - this is the longest part of the compose. So if you see something like this and nothing more on your screen, it will finish:
Pungi.Pungi:INFO: Running /usr/lib/anaconda-runtime/buildinstall --product Fedora --version 20080503 --release "Fedora 20080503" --bugurl http://bugzilla.redhat.com /compose/20080503/x86_64/os
OK, so eventually, you'll see the following (among other things):
Pungi.Pungi:INFO: Running /usr/bin/sha1sum Fedora-20080503-x86_64-DVD.iso
Pungi.Pungi:INFO: Running /usr/bin/sha1sum Fedora-20080503-x86_64-netinst.iso
Pungi.Pungi:INFO: CreateIsos is done.
At this point, the DVD and netinst.iso have been created, and are inside of our chroot. To get at the chroot from the non-chroot'ed OS, it's located in /var/lib/mock/fedora-development-$YOURARCH
I said earler that source ISO's are not created by default as part of the Create ISO's stage. In order to create the ISO's, you need to run pungi again against the same tree. Here's the syntax for doing that:
mock-chroot> pungi -c /usr/share/fedora-release/f9-fedora.ks --destdir=/compose --sourceisos --nosplitmedia
Again, eliminate the --nosplitmedia option if you want CD-sized ISO's created as well.
I'm not a MySQL expert by any stretch of the imagination, so maybe there's something that I should Just Know About(TM), or is MySQL lacking such a basic tool?