Tag Archives: testing

Fedora kernel engineer.

Red Hat has an immediate opening for a full-time engineer to join the kernel team in Fedora Engineering. This job will work with Josh Boyer and Justin Forbes to maintain and improve the kernel in Fedora, and participate and contribute to upstream development and testing. This job interacts with the Fedora team and community, the RHEL kernel engineering groups, and the upstream kernel community.

Ideally we’re looking for someone with significant kernel experience. We want someone who can help manage our own kernel releases. But also we want to get patches and code upstream where it can benefit the entire community, for example to improve hardware support. Red Hat’s a challenging and exciting place to work, and the Fedora team is a great bunch of people to work with. A talented, motivated kernel hacker will find plenty of opportunity here for growth and collaboration.

Applications are being accepted now. You can find more information about the job, and apply online, via the posting here on our Red Hat Jobs site.


Samsung ATIV 9+ loves Fedora 21 Alpha.

Today I received my brand new laptop, a Samsung ATIV 9+ (model 940X3G-K04), and of course my first exercise was to boot it on Fedora 21 Alpha. This model has the QHD+ 3200×1800 text display with a touchscreen, and a solid state 256 GB storage device.

First steps with Samsung ATIV 9+

I downloaded the manual on another system, which I read to discover I should hold down the F2 key at power-up to get into the BIOS setup.

I inserted a USB stick with Fedora 21 Alpha installed, before starting the laptop. By the way, I published a screencast on how to make that Live stick. Then I got into BIOS setup, and used the Boot options to enable booting from the USB stick.

I decide to make a full disk image of the pristine hard disk, compress it, and send it to backup just in case. I don’t feel like keeping 20 GB of the disk reserved for a Windows operating system I’m unlikely to use. So:

dd if=/dev/sda bs=1M | gzip -c | ssh paul@192.168.0.X 'cat - > samsung-ativ-full-disk.img.gz'

I’m pretty sure this is going to tie up the laptop for longer than I’d like. On the plus side, it will give the CPU a bit of a burn-in as well. I ran through an installation after the disk copy was finished.

Booting after installation

The first hurdle was that the GRUB text screen is so small as to make it almost impossible to see for anyone over the age of 18. With the aid of a microscope I was able to find the right option to boot without testing. 😉

Note #1: If the screen is also very dim, you can visit the BIOS setting to turn off the automatic screen dimming at boot time.

The actual boot from the Live USB stick was completely uneventful. Of course systemd was super-fast. In no time at all I was in the Live session.

Applications and interface

GNOME 3.14 did an excellent job detecting the HiDPI type display. The GNOME top bar and dock were sharp and readable. The display is gorgeous, quite comparable to a Retina-model MacBook Pro.

Some apps are still suffering a bit on HiDPI, though. LibreOffice and Firefox UI elements are far too small by default. Epiphany a.k.a. GNOME Web, on the other hand, works great. This is probably because GNOME Web responds to the overall GNOME display settings for HiDPI.

Note #2: To make the Firefox interface more HiDPI-friendly, visit the about:config URL page, and change the setting for layout.css.devPixelsPerPx to 2.

The Ctrl and Fn keys are reversed from my Lenovo x220 I’ve used for the last 3.5 years. Sigh, muscle memory. But the function keys mostly seem to work (other than the Windows specific ones).

Samsung ATIV 9+ touchpad issues

After hitting Fn+F5 to test the touchpad enable/disable function on the keyboard, I found the touchpad worked erratically. It sometimes didn’t work at all, even after a cold restart of the laptop. The pointer would disappear when the Terminal application or other text entries came to the foreground. The GNOME on-screen keyboard would emerge at these times, even if I didn’t need it and wasn’t touching the screen.

GNOME hacker and Fedora buddy Ray Strode, in his usual generous style, kindly entertained my questions and found some help for me. This seemed to do the trick:

sudo modprobe -r samsung_laptop
gsettings set org.gnome.settings-daemon.plugins.peripherals.touchpad touchpad-enabled true

Ray opined that the routine that was catching the function key to disable touchpad was, for some reason, no longer catching it to re-enable. This might have something to do with the kernel module. I plan to investigate further next time I reboot the system.


This is where the enabling work in GNOME shines. A lot more systems these days have touch screens available. I love the fact that I can drag my apps around the screen with a finger as opposed to the touchpad. The standard auto-sizing targets at top, left and right all work well, so I can quickly maximize or half-size windows.

Unfortunately, the resizing handles on window sides and corners are difficult to grab accurately, which is frustrating. On HiDPI touchscreens, perhaps there’s a way to increase the size of these targets. Overall though, far more goodness than badness.

Other issues

The keyboard backlight does not work if you install in EFI mode. Presumably, I should be able to reinstall the system after turning off Secure Boot in the BIOS, and then regain this capability. I’ll probably try that over the weekend so I don’t take more time away from productive work during the week.

Overall impression

The laptop itself seems to have sturdy build quality. It’s an attractive slate/charcoal color. The shell definitely shows oil from even clean, dry hands. The glossy touchscreen of course shows even more smudging. It would be nice if Samsung included a cleaning cloth.

I already love the touchscreen and find myself using it to quickly select the Activities overview, the GNOME settings at the upper right, and to swipe the notifications area into or out of view. The display is gorgeous and very bright even at half brightness.

One of the Samsung’s primary draws is its very slim profile. Besides the power adapter port and one USB 3.0 port on each side and the ubiquitous Kensington port, there is a mini-DisplayPort, a small port for the included gig-Ethernet dongle, a mini-HDMI port, and a TRRS-compatible 3.5mm headset port.

I wish the power adapter, whose jack is very slim and concerns me as potentially fragile, was something more like Apple’s “MagSafe” power connector. I’m sure that’s patented up and down to prevent anyone having such a feature. But for klutzes like me it’s definitely a huge help.

The 8GB of RAM seem well-suited, even generous, for a productivity user like myself who occasionally dabbles in virtual machine guests or other memory-intensive applications. It might be sub par for someone who has to run a lot of such apps often. But the ATIV 9+ seems weird to buy an ultralight laptop if that’s your use case, so I think 8GB is about right.

The 256GB solid state drive is incredibly fast. It’s my first SSD and I was shocked at the difference for doing not just the installation, but post-installation updates and software additions, as well as migrating my data over GbE from my older Lenovo x220 to the Samsung. It remains to be seen how the SSD stamina works out based on my routine style of use. However, I suspect if SSD is moving into the general marketplace it’s a good match for me since I’m usually more like a general productivity or creative content user.

I would say the ATIV 9+ is the best rival for the MacBook Air or Pro that I’ve seen.

Finding old test packages in Koji.

After I answered a question on the devel list today about getting one’s hands on an old testing package for Fedora that had been obsoleted or removed, Josh Boyer one-upped me by providing some easy instructions. I figured I would tip my fedora to him by building a blog post on his work. Nice one, Josh!

When someone builds an official Fedora package, whether it ultimately gets moved to stable or not, there’s a record for it in Koji, the Fedora package build system. You can use the search bar on the Koji website to find the package or build you’re inerested in. In the resulting page, you’ll find the build is labeled with the git commit from which the build came — it’s the long checksum in the “Task” line.

The package may not be there anymore, but that git label is all you need. It represents the position in the repository history from which the packager built that package. You can find that point in history and re-execute the same steps. You can then clone the package’s git repository, reset the HEAD to the proper commit, and send a scratch build to the Koji builder. Once the build is done, you can download the results.

Caveat: It’s possible that other package changes in Fedora might make a build of that exact point in history difficult later. Be aware this solution isn’t perfect, and you may simply want to find an alternate build in Koji that still exists and suits your purpose, or use the latest updates-testing or stable package instead. But in the hopes people find it useful, here are the commands, assuming the package name is “foobar” on Fedora 16 and the git commit of interest in starts with “0123abcd” (and let’s hope I do better than in the last post in which I gave tips):

su -c 'yum install fedora-packager'
cd /tmp
fedpkg clone foobar
cd foobar
fedpkg switch-branch f16
git reset --hard 0123abcd
fedpkg scratch-build
The URL that comes back to your console is the task for that build, and you can use that to drill down into the individual package build tasks as needed later. Remember, scratch builds are not retained for very long, so if you want the package, try to download it relatively soon after you build it.

Here’s another hint: the git reset command above rewrites your index and your working tree, so essentially you “lose” the later history of the repository. However, git is so awesome that this is not a permanent condition. If you really need to reset the git repository back to its original path, you can use git reflog to find the reference to the checkout you did of the “f16” branch, and reset to it (probably something like this):

git reset --hard HEAD@{1}
Once again, it’s important to point out that the above is not for the faint of heart. If you don’t understand the ramifications of trying withdrawn, obsolete, or deleted packages on your Fedora machine, or packages intended for testing, don’t use them. That being said, testing packages is a really helpful activity, and there are all sorts of easy ways to keep testing contained on your system, such as using virtual guest machines. So the intrepid needn’t be shy!

Note for Fedora 16 early testers.

If you’re like me and you couldn’t wait to see Fedora 16 in its pre-release state, you take on the risk of any pre-release. Sometimes things are broken, or break during the fixing process, with the goal of making everything more awesome in its final form. Today I ran into such a problem, and I wanted to share it. Hopefully this problem should be fixed in the final release; I’ve already filed a bug for this issue and it’s been resolved in a later package.

Currently the Fedora 16 updates-testing version of selinux-policy* packages is 3.10.0-43.fc16. This policy doesn’t adequately cover some file locations used by systemd to handle passphrases on LUKS encrypted file systems. If you use encrypted file systems (at least as provided by the Fedora installer) and usually type your passphrase during the boot process, you’ll probably be affected. The plymouth loader won’t get the request to display the passphrase, and you won’t be able to enter it. So systemd will timeout waiting for the ability to mount those file systems, and your boot will fail with a maintenance prompt.

If you want to get past this problem, provide your root password and then enter the following commands:

systemctl start local-fs.target
systemctl default

This will present the necessary prompt at the console (once per file system), and then try to boot to the default target again. To fix the problem, once you’ve booted successfully, downgrade the affected packages:

yum downgrade selinux-policy\*

That should get you back the 3.10.0-40.fc16 packages, which don’t encompass checks on the affected systemd files and therefore don’t produce the errors.

As I mentioned, this has already been fixed and new testing updates should be out shortly. I wanted to make this particular problem visible since it does actually prevent booting an installable configuration right now, since I know many intrepid testers may run across this blog on our Planet.

Installing Fedora 16 pre-release.

I’m a little late this cycle to move my laptop to the Fedora pre-release. (Note the web site doesn’t yet feature the Fedora 16 Beta — that should change next Monday around 10:00 US Eastern time.) I had tried some Live USBs along the way and they were generally looking great, but before now I hadn’t had the spare time to do the installation and test to make sure my various workflow bits were all working normally. Today I finally took the plunge.

Unfortunately, there was one problem standing in my way — an Anaconda bug that pops up in certain pre-existing LVM configurations. Fortunately, the always beneficent Dave Lehman from the Anaconda team had kindly provided an update image for Anaconda that addresses the bug. He even reminds people in the bug how to use it live off the Web with an installation.

That was really helpful for me, because it should be noted I’m actually installing from the current development/16 tree, and not the Fedora 16 Beta RC4, which was declared gold yesterday. So the problem I ran into isn’t likely to happen to other people. The update fixing this problem is in the Beta, but because Dave published this image I could simply install from my local pre-F16 mirror. Which I proceeded to do.

The installation was completely unremarkable aside from this bug, with no extra surprises. I do know that the Anaconda team is working very hard with Máirín Duffy on a UI overhaul. That’s supposed to see the light of day in the next release, Fedora 17. For now we’ll have to content ourselves with the existing UI and things just working as always… ho hum!

After the installation completed, I rebooted. Weirdly the boot seemed a bit faster than it was before, particularly getting from GRUB to the point where I enter a passphrase for my encrypted filesystems. That could easily be some subjective bias, but hey, I was happy anyway. I went through firstboot, provided my user information, and after the SELinux labels and permissions were checked and restored and I finished firstboot, I got the new login screen.

The background picture with the little submarine is really sweet. Last release, Fedora 15 featured the standard GNOME 3 background in the default install, as a tip of the hat to a major milestone release for GNOME. This release, the Fedora Design team was back in action and did a nice job on a stylish background that’s interesting without overwhelming the desktop. And of course, it’s in several fetching shades of blue, my favorite color for many reasons.

But the login dialog itself, part of GNOME 3.2, is also really swank! With smooth animation and fading, it now feels so much more polished from the very beginning of the signon process. I know there are lots of other improvements and cool stuff in GNOME 3.2 and I can’t wait to explore them. I did run into some errors when I logged in, such as the “sad GNOME” even though the interface seemed to work fine. But it’s important to note when I installed, I didn’t include the latest updates of everything in the Beta, so it’s likely I’m seeing problems that are already resolved. I ran an update on the system shortly thereafter to get the latest packages from the updates-testing repository, and I also did a sudo touch /.autorelabel to make sure all the SELinux labels were restored properly on the system, and rebooted. As a result the problems I saw simply vanished.

For now, suffice it to say that I think people will be fairly impressed with the Fedora 16 Beta and can take the opportunity to report bugs as they find them. The most important part of having a free software release that’s done transparently is that it allows you to become part of the process. If you run into a bug, it really helps when you report it. It can be frustrating when something doesn’t work, but it’s important to remember a lot of people are working on this software as part of a gift culture. So help them out in return by politely reporting bugs and, if you have just a little more time to spare on top, work with them to test the solution to resolve it. Your gift will help countless others, just as developers’ gifts help you and me.

Enjoy your weekend!

Trying out Fedora 16 Alpha.

I’m sure there will be plenty of news reports on the wire with Fedora 16 Alpha reviews. I wanted to share a couple brief thoughts, as opposed to a long review. I downloaded a copy of RC5 (which is the candidate that got the gold star) from the stage location and made it into a Live USB stick using the livecd-tools package’s livecd-iso-to-disk tool. These were some things that popped out at me when I was using it:

  • The Design team’s background image is quite striking. Although it’s a little higher energy than some previous desktops, I really like the underwater motif (I liked the underwater background in Fedora 9 too). From what I understand, the login screen should have some significant changes shortly, and that should show off the background well.
  • My ThinkPad x220’s hotkey (Fn+F8) for switching the touchpad on and off now works! This is fantastic because I often find myself brushing the touchpad, which is not recessed, and it can cause me problems in some interfaces. But at the same time, I don’t like turning it off in the BIOS because (1) I do sometimes use it in mouse-only interfaces, and (2) although I have no problems altering BIOS settings, I don’t think users should have to interact with them, especially when they have a clearly labeled keyboard function they should expect to work.
  • Bluetooth wasn’t working for me at all. This was only a brief test and I had no time to track down the problem. It’s quite possible this is a hardware dependent issue specific to my ThinkPad. So this is merely an observation, and if it’s not done already I’ll be looking further into the situation later, and filing an appropriate bug.

Sadly, I don’t have quite as much time to do deep testing of Fedora as I used to. So the above is basically a minimal report from about 3 minutes of usage I was able to fit in a couple nights ago. But I can say I’m looking forward to doing more! Remember that if you’re testing and finding problems, we need bugs! Without them it’s really hard to make a better product. So do your part for free software, and report them. 🙂

Nice work to all those involved thus far with the release and all the collateral that goes with it.

Fedora 15 rocks on ThinkPad.

On Friday my new Lenovo ThinkPad x220 arrived and of course in the evening after I finished work, I was jonesing to put Fedora 15 on it. The machine is a type 4286CTO (Smolt info here). I started by booting into the BIOS and checking the options as shipped by Lenovo. There wasn’t much to change here, other than to enable hardware virtualization so I could more easily run KVM on the laptop should I choose to do so later. I didn’t enable the extra direct IO option, VT-d, because I’ve seen it cause weird installation problems in a lot of cases.

While I was starting to work on my new laptop, I also took the time to refresh my backup of data on the laptop I’ve been using, a ThinkPad x201 graciously lent to me by Tim Burke when my Dell XPS M1330 started to go belly-up a couple months ago. I used rsync to sync everything to a large USB drive.

Then I grabbed a spare 64-bit Fedora 15 Live USB key with the standard Desktop image and booted from it, just to see what I might expect from an installed system. I was impressed (but not really surprised) to see that everything worked great out of the box (with one trivial exception I’ll cover below). Not only the standard stuff like video hardware acceleration, special keyboard buttons, Bluetooth, sound, and suspend/resume, but also stuff like the webcam (at full resolution) and wireless. So I tried an installation from the Live key, and everything went fine — and fast, due to the new 2nd-generation “Sandy Bridge” Core i7 processor on this notebook.

Booting that went flawlessly, so I decided to try a more full-featured install over the network. I copied the pxelinux images for the kernel (vmlinuz) and initial ramdisk (initrd.img) to the /boot folder, edited the /boot/grub/grub.conf file to add a boot stanza, set the new boot stanza to be the default, and then restarted. Spoiler: this installation also went flawlessly. When it came time to deal with the package configuration, I did two things:

  1. Using the installer’s ability to edit repository configuration as part of the interactive installation, I pointed the installation at my home network, for speed purposes — having made sure my local mirror of content was updated with the latest content already.
  2. I made sure the “Updates” repository was turned on (and also pointed at local content). This would save me having to do a separate update after installation.

In minutes I had a working system. Using some of the yum-fu from an earlier post, I added in missing packages that were on my previous system.

Now came time to restore my user data. However, I decided to forego using the USB drive for restoration, because here I was with two relatively speedy laptops, each equipped with a gigabit Ethernet network interface. Nowadays these interfaces don’t need special loopback or null cables; they can autosense direct connections and adjust accordingly. So I cabled the notebooks together and used the easy NetworkManager tool to set up the wired interfaces with manual addresses on the same IPv4 network.

A quick check with ping showed I was ready to go, so I ran rsync over SSH to pull all the user data (in /home) from one box to another. This step probably saved me about half the time that the USB copy would have cost thanks to greater bandwidth over gigabit Ethernet versus USB 2.0. (The new laptop has USB 3.0 but the backup drive I have is USB 2.0.)

One of these days I’ll get around to puppetizing my home network, but I just don’t have the time for it these days. So my last step was manually grabbing an assortment of configuration info from my old laptop:

  • Stuff from /etc/NetworkManager/dispatcher.d/ and /etc/postfix/ to support my laptop email solution (start here if you want to learn more about it)
  • Some web server configuration files from /etc/httpd/conf.d/ so I can run my local sandboxes of Drupal
  • A little more info from /etc/NetworkManager/system-connections/ where I have some system-wide connection profiles

And with that, I was ready to go. Actual “me time” expended on all this was less than an hour, if you count both installations, post-configuration tasks, and miscellaneous piddling around in the middle. Of course I wandered off and did other things while the data copying was going on, so I’m not counting that time.

As I mentioned, everything worked perfectly on the installed system with one tiny exception. Even the fingerprint scanner was set up in a matter of seconds, using the handy GNOME 3 “My Account” tool. Interestingly, if you’re one of the poor unfortunate unwashed using Windows 7 (even the so-called “Ultimate” edition), both the webcam and the fingerprint scanner have to have extra drivers installed if you want to use them. But in Fedora? Nope. It all works 100% out of the box. What’s the exception then? The only thing that’s not functioning yet is the new “microphone mute” function button. The button does issue a key press signal, but it’s not captured by anything yet. This is also an “extra driver needed” for Windows users, but true to form, the new button is already on its way to working out of the box in Linux, thanks to the awesome work of community members. My bet is you’ll see this enabled in a kernel update in Fedora 15, or at worst in Fedora 16 which will be out in a few months.

Hopefully this will be helpful to anyone who’s considering one of these fine laptops. ThinkPads are kind of the Cadillac of laptops for IT worker bees, in my opinion. Or maybe I mean Toyota truck? Anyway, they’re tough, reliable, full-featured and in the case of the X series, highly portable. And they work absolutely great with Fedora and Linux in general. Happy hacking!

A fun day… for some hacking.

Over the course of the day, I:

  • Tweaked the package complement on my workstation where last night I did an installation of the Fedora 15 pre-release tree
  • Identified some weirdness in my local Eclipse environment and got things in better shape for later work
  • Got a good start on some user documentation for PulseCaster
  • Took my daughter to the skate rink, and managed to skate for at least a little while before realizing I was having a rough time because my kingpin bolts are just way too freakin’ tight
  • Figured out how to adjust said kingpin bolts and made a note to take care of that before next week
  • Took my son out for some errands and lunch — a nice trip and a good chance to exercise my patience muscles
  • As a reward, bought some beer and a couple decent malbecs
  • After returning home, cleared out some obsolete packages hanging around in Bodhi and begging for death
  • Built and pushed a new update of PulseCaster to fix some bugs
  • Built and pushed a refreshed upstream version of xmlstarlet
  • Played with the dog
  • Came back and turned up a French trance station I got into recently (for some reason, monotonous, non-vocal electronica seems to help me work more efficiently… probably since there are few lyrics to listen to and digest mentally)
  • Went through some email to reduce backlog for Monday
  • Triaged a crummy gnome-system-monitor bug affecting people with more than 4 CPU cores (like me)
  • Had dinner with the family (Eleya made a fabulous corned beef, first timer but it was pretty much perfect!)
  • Came back to the desk to find that the superhuman Matthias Clasen had fixed the gnome-system-monitor bug in question, and built and pushed an update out
  • Installed said update with many thanks to Matthias, tested, and provided feedback

So of course, my definition of hacking is not nearly what some of my colleagues manage daily. But I feel like attacking some of this stuff on weekends and working on my own GNOME-ish projects are starting to give me a better fundamental understanding of some of the plumbing at work in the desktop. And of course, it gives me a wh0le new appreciation for it as well. I’m now rocking GNOME 3.0 pre-releases on both my main systems here at home, my laptop and my big workstation, and loving it.

I’ve contributed a few bug reports and to a small portion of the GNOME 3.0 user documentation for this release. It was lots of fun and made me feel connected with the release process for something I use every day that will be an intrinsic part of Fedora 15 when it arrives. It’s a great feeling to be just cranking on some little bits to help others, and just as much as ever, I know that if everyone does the same, free software has a future that is even brighter than the (already well-lit) present.

Eager beaver, no. 38.

I was really eager to get my laptop onto the branch that will become Fedora 15. A recently uncovered bug (possibly in glibc), along with another unrelated problem (in pygobject?), are preventing installs via the nightly composed ISO images of the pre-release. So if you’re on Fedora 14, and want to get on the new branch, you could do this:

  1. Back up your data and at least your /etc directory. You never know what you might wish you’d kept!
  2. Also run the following command to save the names of your installed packages: rpm -qa –qf ‘%{NAME}\n’ > /home/rpmnames-old.txt
  3. Download the Fedora 15 Alpha release, Desktop Live spin, in your choice of 32- or 64-bit, and install. In a moment you’ll update everything.
  4. After you start up and run through the normal setups, don’t bother logging in at the GUI yet. Hit Ctrl+Alt+F2 to switch to a text terminal. Login as root, or else use sudo with the following commands.
  5. Install any -release type repository RPMs you may want. I keep copies of these hanging around for just such occasions.
  6. Get the names of the newly installed packages: rpm -qa –qf ‘%{NAME}\n’ > /home/rpmnames-new.txt
  7. Run: yum –skip-broken install `diff -u /home/rpmnames-old.txt /home/rpmnames-new.txt | tail -n +4 | grep ‘^-‘ | cut -c 2-`

Note this is not a perfect solution. Releases change, and some packages may not be available in the new release that were in the old one. You may want to rerun steps 6 and 7 a couple days later if there are any broken dependencies that foil you from installing everything you wanted. Or alternately, you might want to stick in a step 6.5, which runs a few yum groupinstall commands to make step 7 shorter. This isn’t a panacea, it’s just a quick way to get up and running if you want to try out the new hotness but are stymied by the bugs listed above.

And of course, you could just download the entire Alpha DVD and point it at  so you won’t have to twiddle as much afterward; quite a few services that run by default in a DVD install, like sshd, aren’t necessarily enabled by default in an installation from the Live image. The above is just a quick way to get started if you know you’ll be doing further installation testing or other hackery later anyway. And it will give you a good flavor for the awesome new GNOME environment.

What if you want recapture your user account and password? Just refer back to your backup you made. Do not simply restore it over the new /etc files. You could really get hosed that way. Instead do something like this. I’m going to assume you only have a couple of users on your system, starting with userid 500 per normal:

mkdir /tmp/restore && cd /tmp/restore
tar xf /path/to/etc-backup.tar.gz   # Got backup?
for i in $(grep ':50[0-9]:' etc/passwd | cut -d: -f1); do
  for f in passwd shadow group gshadow; do
    grep ^$i etc/$f >> /etc/$f

Here’s something I also recommend: move your user’s ~/.gconf directory to a backup before you login the first time. Try the spiffy new GNOME 3 out in its default settings. If you need to tweak or restore, you still have the old settings to which you can refer. But it’s worth trying everything as it was intended out of the box. I’m totally excited to run the pre-release so I can rock the new GNOME Shell. Pretty soon I’ll start working on a new branch of PulseCaster that will use the new PyGObject available in Fedora 15, and maybe a few of the cool new GTK+ 3 bits I’ve seen might be helpful in the  new UI.


Test day for systemd tomorrow.

Tomorrow, Tuesday September 7, there will be a Test Day for the new systemd init facility in Fedora 14. You can find the participants on IRC Freenode at #fedora-test-day.

Participating in a test day is simple, and you don’t even need to have the Fedora 14 prerelease installed on your system to participate. We have a nightly Live image that you’ll be able to download and run from USB to do all the testing. If you do have a prerelease of Fedora installed, though, you’ll want to make sure it’s updated with the latest software.

These Test Days are a marvelous way for the whole community to participate in the development of new and innovative software for Linux users everywhere. Whenever we have these test days, we communicate the issues we find to the upstream so they can make the software better for everyone. That’s the open source way at work.

You might also be interested to know that soon we’ll be having test days for the free graphical (Xorg) drivers for Nouveau, Radeon, and Intel graphics cards the days of September 28-30. These drivers have been making huge progress over the last few releases of Fedora, and the Test Days have definitely helped. Just about anyone can run the tests for these drivers and help us squash out bugs in your favorite system’s video card.

Please join us for systemd testing tomorrow, and keep your eyes peeled for news about other exciting test days. You can help make free software even better!