May 2008 Archives

I triaged all of the bugs against the 'upstart' component in Fedora today. Managed to close 30% of them (OK, so that sounds better than it really is - 3 out of 10 :) ). All of this took me under an hour to do, and that included actually testing some of them via a new install of F9.

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!

On Tuesday, May 27th, Fedora will be moving to MediaWiki at long last! A predeployment is up here. There will be no such thing anymore as a wikiname, EditGroup, or anything of the sort in Fedora, and the signup process for an FAS account has already been streamlined to a click-through CLA instead of GPG signatures and the like. A few people deserve special mention in this effort:
  • 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.
There were also a lot of other people involved in this. I really think that this was a great example of how a cross-functional group can come together and make something enormous happen in a relatively small period of time - we've only been working on this in earnest for about 2 months.

Great work everyone! (and after Tuesday, we'll just be sitting back on the beach drinking our Mai-Tais - NOT! :) )

Finally got it

| No Comments | No TrackBacks
Well, I finally got my new Thinkpad. UPS shipping is really fast! I've had a few issues thus far, but certainly no showstoppers. The biggest issue was that, as I expected from what I'd heard after I bought it, compiz performance is not to be found on this machine. Hopefully there will be a newer update to xorg-x11-drv-intel to fix this sometime in the future. But in the end, who really needs eye candy? Other than that, it just worked like a charm right out of the box. All of the function keys work (suspend, brightness, even battery status), even the little LED light on top of the monitor turns on and off on command (which, despite it's detractors that I've read online, does actually provide some benefit in low-light situations). Smolt profile here. It's a fun little toy!
I'll spare you the complete announcement, but Red Hat Bugzilla 3.2 Beta 1 is now available for testing in a test instance here. Email is disabled in this instance, so feel free to make any changes that you want, test how your workflow works, and other stuff. The user interface has undergone a major overhaul, and I really like the new interface as compared to the old one. Let's see how everyone else likes it!
Well, got an email from Lenovo yesterday informing me that my Thnkpad R61 had shipped. Now I can hardly wait for it!

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?

My Greendex score

| No Comments | No TrackBacks
Well, I was reading Seth's blog, and decided to take the test myself. My score was a paltry 52, maybe the fact that my household of one has 6 computers (4 of which run 24/7 - they didn't ask anything about that, though) contributed to it. However, I don't own a car, however, but I put the shared ride part at like once a week since I occasionally take taxis (maybe I overrated how much I actually do - I took one last night from the most excellent Hop Devil Grill, but I really can't remember the one prior), I guess that lowers the score.

Oh well, I'll count on folks like Seth and Karsten to counter my bad ways :)

As some of you may know by now (or may not), a new wiki is coming to the Fedora project! Our previous wiki, MoinMoin, has been pretty unreliable due to scalability issues. We were the largest deployment of Moin, and it just didn't scale. You may have noticed this in the form of slow response, frequent timeouts, internal server errors, and other assorted bad things.

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!

Oracle fail.

| No Comments | No TrackBacks
Well, I'm being forced against my will by a customer at $DAYJOB to install Oracle Enterprise Linux for them. So I downloaded it, installed it at home this evening, just to kick the tires a little bit before installing for real. So I installed it. The first thing I notice is that Anaconda looks a tad shoddy compared to the real deal. For instance, when installing packages, there's a 'Status:' line at the bottom that's always blank. What is it supposed to tell me the status OF? That wasn't present in the real deal IIRC.

Next, it installs. I login, and find this:


[jstanley@dhcp-137 ~]$ cat /etc/redhat-release
Enterprise Linux Enterprise Linux Server release 5.1 (Carthage)
[jstanley@dhcp-137 ~]$

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.

Fedora 9 Released!

| No Comments | No TrackBacks
Fedora 9 is now officially released! You can get the bits, via BitTorrent or via direct download, at http://fedoraproject.org/get-fedora

Some of the features that I'm most excited about:

  • Xorg 1.5
  • FreeIPA
  • Anaconda encryption of the root filesystem
  • Improved NetworkManager
  • KDE4
  • Gnome 2.22
  • Live persistence
  • New GDM
  • Preupgrade
  • Partition resizing via anaconda
  • Upstart
  • And perhaps most importantly, Firefox 3!
Thanks to all the developers, QA, bug triage, art, marketing, websites, documentation, and other numerous groups that made this release happen!

Figured that I would post here what I posted to fedora-devel-announce a few days ago:

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.

Well, I declared my candidacy on f-a-b earlier, and just yesterday made it official (I guess) with a post on the wiki. So if you can't think of someone better to select, select me! :) There's a number of reasons to do so that are outlined on the wiki page. If someone can suggest patches for that nomination, that's welcome too.
Yesterday, I broke down and ordered a Thinkpad R61. I had originally planned to go with the T61, but I did some research, and found that really the only difference between the two (I got the 14.1" R61) is that the T61 is slightly thinner and lighter (but not by a huge margin). Both have the LCD roll cage (NOTE: the 15.4" R61 does NOT have the LCD roll cage, whereas the 14.1" model does), they're both built like tanks to withstand my abuse, and it's about $150-$200 cheaper than the T61. The total price of the machine after all the discounts was $958.15, not a bad machine for the price. Yes, I know that Centrino 2 is coming out next month. Having the absolute latest and greatest is not really important to me (except in the operating system realm :) ), and I think I''ll really enjoy it and it will last awhile I'm sure. Of course, the included Vista goes bye-bye quickly and gets replaced with F9 :)

So here's what I got (note the 5/22/08 over there, that's the estimated ship date :( ):

1 7732CT CONFIGURED SYSTEM 05/22/08 $958.15 $958.15
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
42V8177 SBB INT.WIRE.WIFI/LINK4965AGN
42V9338 SBB 6 CELL LI-ION BATERRY
41W1787 SBB CPK NORTH AMERICA
42W7087 SBB LP,US ENGLISH

I'm bankrupt!

| No Comments | No TrackBacks
What you ask? How am I writing on the blog if I'm liquidating all my assets in order to pay off debts? Not that kind of bankrupt, silly! I'm going to declare laundry bankruptcy this weekend.

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! :)

Alright, well maybe not profit, but certainly fun!

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) --init'. This brings up the question of which mock configuration to use. Mock comes with a number of pre-made configuration files. The ones that you're most likely to want to use 'fedora-rawhide-i386' or 'fedora-rawhide-x86_64'. These files live in /etc/mock, and the -r argument to mock takes them WITHOUT the trailing .cfg extension. If this is your first time running mock for this installroot, it will use yum to install the group 'buildsys-build' into the chroot. After that is done, it will tar up the root, and save it for future use. If you had used this installroot before, it would clean it (i.e. delete everything that was there), untar the root cache, and then run yum update to get items that were changed since the root cache was created.

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 fedora-rawhide-x86_64 --install pungi', It won't output much at all, but it will install pungi and it's chain of dependencies. Now that we have pungi installed, we're ready to actually use it in the chroot! So let's get a shell in the chroot with 'mock -r --shell', which will give you the following output:

[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
mock-chroot>

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:

-c - what kickstart file do you want to use to use for this compose

--destdir= - where should the compose happen. It's important to note that this is different from where on the non-chroot'ed filesystem you'll find it - remember that we're operating in a chroot here.

--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.
All 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/root - so everything that you did is located there. You can find the completed ISO's in /var/lib/mock/fedora-development-x86_64/root/compose/20080503/x86_64/iso for example.

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 want something a GUI in which I can write and run MySQL queries. For anything more than trivial work, the MySQL CLI client just doesn't cut it. A way to check out table structure in a graphical way would be nice, too.

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?