Tag Archives: bugs

Contributing to Pagure made easy.

I don’t get as much of a chance these days to do things like patches or other technical contribution. But I had some time free the other day and used it to stick my hands directly into a cool project, Pagure (pronounced roughly “pag-yOOR,” or listen here). You may have read about Pagure in this Fedora Magazine article a few months back.

It was tremendously easy to get Pagure, fix a bug, test the fix, and contribute it back (see my pull request here). I specifically looked for “easyfix” bugs, since I knew I didn’t have a lot of time to spend to help. So I decided to work on this issue, a button showing up when it shouldn’t.

First I forked the repo in Pagure. Then I cloned my new fork, and set it up as documented in the README. In the clone, I checked out a new branch using the issue number as a name, issue839.

To track down the fix, I ran the app locally and duplicated the error. I looked at the CSS style containers for the button and some of the surrounding elements. Using that information, I did a text search on the code to find the file that was generating the button. Then I simply applied some logic to find the fix for the problem, even though I wasn’t really familiar with the code involved.

Thankfully Pagure has a test suite, so I could also check that my fix didn’t break any of the tests. Then I committed and pushed my changes, and made a pull request using the button in Pagure’s web page.

I also learned something useful. Since I forked the repo to do my fix and make a pull request, if I force-pushed changes using git to my branch from which I made the pull request, the pull request was automatically updated with the changes! This is probably expected by people who do this all the time, but since I’m new at it, I was excited.

Bugs like this are something that just about anyone with a small amount of beginning programming skill could fix. Pagure even has other bugs like this waiting for people to handle. Maybe one of them is waiting for you! 😉

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!

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.

Fedora 14 Alpha is go!

As John posted last night, Fedora 14 Alpha was declared ready for release next week. Although there was a one-week slip to handle the fact that our blocker list wasn’t clear, Fedora developers and testers in the community have worked hard together both to resolve the remaining issues and make sure that our Alpha would pass the release criteria. There were a number of developers who hopped in to fix things quickly to yield package builds that would clear the runway, so thanks to all of you guys.

I also wanted to take a moment to say how impressively the QA team has beefed up the definition of these criteria. Not only that, but the team continues to take opportunities to refine them whenever we hit a question that’s difficult to answer under the current criteria. We still can improve our effectiveness at turning the combination of the blocker bug list and the criteria into getting response from developers where needed, but that’s more of a shared issue. As with our criteria and our schedule, we continue to improve these processes in an iterative way, and openly to boot.

Here’s one place where everyone will be able to pitch in — making sure that any common issues in the Alpha are properly noted. We have a wiki page for common Fedora 14 issues, and it’s very important for us to keep it updated for all those trying out the pre-releases. If you’re in doubt whether it’s a common issue, that’s OK. There are some notes on that wiki page on how to add your issue:

  • Add it yourself, if you have wiki access. Please follow the style and guidelines explained in the comments in the page source. (You’ll see them when you start to edit.)
  • Or, add the CommonBugs keyword to the bug report. Someone from the QA team will then inspect the issue to determine whether the bug should be listed as a common bug. To expedite your request, add a comment to the bug that includes
    1. a summary of the problem
    2. any known workarounds
    3. an assessment on the impact to Fedora users

If in doubt, we’d rather see the issue than not. 🙂

The Alpha release is meant for advanced users and Fedora participants to download and test. It’s not code-complete, meaning a few things may be broken. We want and need your help to identify, report, and resolve these problems. As always, the best way to do that is to file bugs! Random blog entries, tweets/dents, and mail may be interesting, but to track the problems to resolution, bugs are the right way to go. We look forward to your participation as always — if you’re not already installing from the pre-release tree, you’ll be able to pick up the official images next Tuesday, August 24.

In summary, nice job to everyone involved, and I’m looking forward to switching a few systems here at home to F14 Alpha!

Reminder: Docs bug sprint tomorrow 2010-03-06.

In case you didn’t remember from Eric Christensen’s earlier post, there will be a Docs sprint tomorrow: 2010-03-06 UTC 1500-2100.  We have a flexible but solid agenda for work, and there will be plenty of opportunities for new contributors to participate. We’ll help people get used to Bugzilla, show you how to locate and work on documentation, and most of all, have fun doing it. 🙂

Come meet us at IRC Freenode (irc.freenode.net) at channel #fedora-docs for all the good times. See you tomorrow at the bug stomping!

I’ll be there closer to 1630 UTC, because of my daughter’s skate lessons — looking forward to seeing everyone there.

Fedora 12 Alpha!

Today marks the Fedora 12 Alpha release, hot off the presses! You can pick up a copy to try all the latest technologies here:


I’ve been running the Alpha version for about a week or so on one of my home machines. While there are some minor foibles here and there, most of it seems to be working like gangbusters — and better than ever. The PackageKit “command-not-found” plugin is pretty cool, and I’m also enjoying some of the other sweet new features like the new Virtualization Manager upgrades.

Not everything is guaranteed to work perfectly, because there are some pretty new bits in there. But we do encourage people to at least grab a Live ISO image and run it from a CD or USB stick. And of course, it’s very important that you FILE A BUG if you find something that’s wrong! Remember kids, Twitter and Identi.ca are not substitutes for good open source practices — they’re a good way to encourage people to check your work, though, if you’re looking for a second opinion. I hope everyone trying F12 Alpha will blog a little bit about the bits they find that they like — and if you don’t like something, tell us about that too, and let us know how it can be made better. Then file a bug about it!

You can tell I’m big on the bug filing today. That’s because we seriously want your help in testing the release. Yours, and everyone you know! The more problems we can find and knock out before the Beta, the better Fedora 12 “Constantine” will shine in November! I, for one, started using the command-line bugzilla client for doing this quite often, and it’s very convenient when I’m in a terminal or otherwise not using a Web browser. You just run bugzilla login and bugzilla new — the latter with a bunch of required options — and you’ll get a reply with your bug number assigned.

I hope you enjoy this very early sneak preview of what’s coming Fedora 12! And thanks as always to our awesome Release Engineering and Infrastructure teams for their usual fantastic job at getting Fedora out the door into the hands of our millions of users.

Speaking of which: Only 10 weeks into our release, our latest stable offering, Fedora 11 “Leonidas,” has surpassed one million registered updating IP addresses, as noted on our statistics page. That’s almost 40% higher than our uptake from the previous and very well-regarded Fedora 10 release. I also see that our number of completely unique IP addresses registered for updatesm from Fedora 7 through Rawhide is now at slightly over 15 million for the first time. There’s some helpful information floating around about how that might translate to user numbers, but for my part, I just love being able to just look up these numbers in our completely open and transparent infrastructure — another reason to enjoy being part of a project dedicated to building 100% free software for you and yours.

Sad daily confessional: I meant to have this out in the morning but the upcoming Red Hat Summit has me hopping more than usual. Sorry about the delay and hope to see you in Chicago next week!

Update: Fixed the “sweet new features” link above, thanks Rahul!

This. Is. ALPHA!

[This post was supposed to be out yesterday, but somehow I managed to brush my touchpad the wrong way and… well, the dog ate my homework. Or WordPress did. Either way, sorry about the lateness of the hour, and all that. Revised now for more contemporary enjoyment. — Ed.]

Yes, that 300 joke isn’t getting any funnier. But it’s not getting any older either! Well OK, maybe it is, but remember that “beta” works just as well there, so you may have to endure it one more time, sorry.

Anyway, yesterday our Fedora 11 Alpha release hit the wires, and they are humming hotly even as we speak with flying bits. We’ve provided a brief set of release notes where you can see some of the major changes called out.

I often get questions from people asking, what’s the point of an Alpha anyway? Well, essentially it’s to ensure we can effectively compose a Fedora release that can be installed by most people, and once that’s done, to give our community a chance to test the current state of features from a known starting point. Testing is, in fact, our focus once an Alpha release of Fedora is out the door, and every bug you file can make a big difference in the quality of the final Fedora release.

Typically people will install Fedora 11 Alpha on a test machine, and then update to the latest Rawhide packages. You see, Rawhide, our development branch of Fedora, keeps moving after we’ve started working on an Alpha release, so some bugs might be fixed with that update. On the other hand, you might also see totally new ones. It’s very early in the development cycle, so don’t expect a Fedora 11 Alpha system to necessarily be ready for your daily non-testing use (although I do know people who essentially run on the development branch almost all the time, and my hat’s off to them).

The point is, once you have your system running, we’d love to receive bug reports from you. That helps us eradicate problems early and provide a better release by the time the Beta, Preview, and final emerge.

Interestingly, there were hardware-specific bugs in previous releases reported by numerous people that could have easilly been found, had someone taken time to test an Alpha installation or boot on their hardware. So by testing, you really can be a big help to the overall Fedora community! You can often file bug reports straight from the installer, for instance, if your network hardware is supported. You can also use our helpful wiki page to learn how to file a bug. By the way, if you find a problem on that page, you can use its discussion page to tell us what needs improvement.

Basically, it’s a great time to try out the beginnings of Fedora 11 with our Alpha release, and let us know how you fare. And when you do, you’re part of the enormous (and still growing) Fedora community.