Skip to content

Foresight

KVM & Virtual Machine Manager in Foresight

Foresight has long been a proponent of KVM over other virtualization technologies such as Xen or Virtualbox.

If you, like me, aren’t a guru on the command line and prefer using a GUI, Virtual Machine Manager is available in the Foresight repositories. If you’ve used Virtualbox or VMWare, you’ll find virtual-manager very familiar. The only downside (for some), is that you will need a modern processor that supports Intel VT or AMD-V.

Let’s get started:

In this example, we will use an ISO of a Linux distribution. Go ahead and download an ISO of a Linux distro you’d like to try out.

From a command line install the tools you’ll need:

sudo conary update virt-manager libvirt

You’ll want to install it from the command line, as PackageKit has a bug that it doesn’t pull in libvirt:runtime for some reason. (FL-2050)

Start the service:

sudo service libvirtd start

Go to Applications -> System Tools and choose Virtual Machine Manager.

PolicyKit will prompt you for your password. Enter it and Virtual Manager will start.

Click on localhost.

Then click File -> Add Connection and click Connect.

Click New in the bottom right hand corner. You will be prompted to enter the name of your new Virtual Machine.

You will now be present with 5 steps to create your Virtual Machine:

Step 1: Enter the name of VM you wan to create

Step 2: Click on “Use ISO Image” and then “Browse” and chose the ISO you downloaded earlier. Then from the drop down boxes choose Linux, and in the second drop down box you can check if the distro you’re trying is available.

Step 3: Choose how much RAM and how many CPUs the VM can use

Step 4: The defaults should work – choose to enable storage, and how much hard drive space the VM can use. (I’ve learned that hard drive space is important – these VMs need more than you think they will!)

Step 5: The defaults should work here as well, but you can click on Advanced Options if you want to change the Networking options. I’ve never had to change anything here, and Networking has worked out of the box.

And that’s it! Now under “localhost” double click the name of the VM you created, and it will boot up, just like a computer was booting up. You’ll install the Linux distro, just like you would on to a hard drive. One thing I’ve noticed, is that after an installation, it needs to reboot. My experience is the VM shuts down, rather than rebooting, but just starting it up again, the VM will boot up th eOS after your install.

To use the mouse, just click your mouse inside the virtual machine. To regain control of your mouse, press control and alt and your mouse will work normally inside Foresight again.

Here is a screenshot of Virtual Machine Manager running while the GNOME Dev Kit loads (note I have created VMs for the Dev Kit and the betas of Fedora 11 and Ubuntu 9.04:

GNOME Dev Kit

This screenshot shows the GNOME Dev Kit and Fedora 11 running side by side (One interesting thing about running Fedora is that i don’t have to release the mouse via ctrl-alt, it’s automatic within the OS. I’m not sure why, maybe it’s because Virtual Machine Manager is developed by Red Hat?):

Virtual Machines

If you have a modern processor, the hard drive space, and some memory to spare, I highly recommend Virtual Machine Manager. It makes creating and running different operating systems a breeze.

Microblogging on Foresight

I’m a big fan of microblogging, using both Twitter and identi.ca. Microblogging, if you don’t know, is sending a short message that is 140 characters or less – so you have to be short and sweet in your message. (Did I mention it’s been 2 years since I started using Twitter? Where does the time go!?)

My favorite microblogging client for the Linux desktop is Gwibber. Unfortunately there is a nasty bug with WebKit and Gwibber that has caused Gwibber to stop working. This is affecting most distributions, not just Foresight. Unfortunately, when we ship Foresight 2.1.1 (probably) later this week, Gwibber won’t work anymore, as I found out Monday when I updated to the QA version of Foresight.

Thanks to misa, I found out earlier this afternoon that there is a stopgap solution using Pidgin and the microblog-purple plug-in for Pidgin.

In Foresight, click on Applications -> Add / Remove Software and search for “pidgin-microblog” or in a terminal, do:

sudo conary update pidgin-microblog

Then in Pidgin, go to Tools – Plugins and enable the “Twitgin” plugin. Then go to Accounts -> Add, and add your Twitter or Identi.ca account like you would add a new IM account.

When Twitter or Identi.ca updates, it will open a new window, just like any other IM conversation, with your friends’ updates. I just leave the window open, and notify-osd shows me the updates in my notification window. You can also post your updates from within that same window.

If you, like me, were or will go through withdrawal from microblogging when you get hit with the Gwibber / Webkit bug, try the Pidgin plugin out, works pretty well. (And if you’re daring, there is a newer version in the fl:2-devel repo you can try too).

If you want to follow my microblogging, I’m on Twitter as paul_cutler and identica as pcutler. (Giving my silwenae nick a rest for the moment).

Foresight Website

It’s been just over a year since we rolled out the new Foresight website, which is written in HTML.

After some on and off debate, we’ve made the decision to switch to a CMS (which makes it much easier to get volunteers involved), and as of last night we’ve picked Joomla over Drupal.

We’ve set up our appliance on rBuilder, and we’re looking for help in building and maintaining the appliance, and even more important in designing a Joomla template for the look and feel of the new Foresightlinux.org. A big thanks goes out to pscott, Lance Haig and Tomas Forsman for getting us this far.

Join the marketing list and give us a hand today!

Foresight Issues Update

While the march to Foresight 2.1 continues to improve Foresight, one area that needs help, and is easy for a new contributor to jump into, is fixing current issues in Foresight.

While Foresight 2.1 will focus on a number of things to make Foresight even easier to use, such as improving boot up speed, printing, and installing packages, we would also like to fix as many bugs as we can.

A quick look at Foresight’s issue tracker, JIRA, shows the following:

637 total open issues (or 34% of all issues ever filed in JIRA)

In progress: 40 (2%)

Reopened: 15 (1%)

Needs QA: 120 (6%)

Blocker: 6 (1%)

Critical: 25 (3%)

Major: 77 (10%)

Normal: 572 (77%)

Minor: 55 (7%)

Trivial: 12 (2%)

By assignees:

Distro: 234 (31%)

Packagers: 123 (16%)

Ken VanDine 174 (23%)

Antonio Meireles 93 (12%)

Issues assigned to Distro need to be triaged and assigned. One other thing to note, is just because an issue is assigned to someone, doesn’t mean you can’t work on it! Issues are typically assigned to developers who we know can fix it, and we default to them.

We need your help! Out of the open issues, can you confirm it’s a bug? Try and re-create what happened to the user and comment on the issue if you can or can’t. Can you package? Jump in and browse package requests and build it! I’ll be triaging bugs over the holiday break, and if we can knock out a bunch of them prior to our 2.1 release, we can continue to make Foresight even better.

Want to learn more? Here are our wiki pages on using JIRA and triaging issues in Foresight.

Where'd whooo go?

In the immortal words of Goose from Top Gun: “Where’d whooooo go?”

I took the last 6 weeks to disappear as I started a new job, working in my home office. I owe the Foresight community an apology, as I should have given some warning. (Though I did let Ken and Antonio know).

What started as a one week sabbatical from the internet between jobs stretched out, as I was traveling 3 of the 4 first four weeks of the new job, and working in a home office requires a high level of focus. Add to that meeting new people, figuring out what you’re doing and who does what, I needed to step back for a bit from Foresight. I shut down IRC and IM so I could minimize distractions while working at home. It seems to have helped – I think I’ve found a rhythm and schedule that’s working.

I’ve been popping back in to IRC this week, and browsing through the commits and JIRA issues trying to get back up to speed. It’s amazing how much is going on in just the short period I was away.

Again, I apologize for not having been around, but the good news is I’m working my way back, and looking forward to helping take Foresight to the next level.

Foresight Packages

We are getting ready to release Foresight GNOME edition in the next week, once GNOME 2.24 is out.

Foresight is a rolling release distro – our packages are almost always up to date, and we keep them up to date, unlike most distributions that have 2 big releases a year, which is when they update packages.

Being a rolling release, this means that a Foresight “release” is just a snapshot in time of what is available in the repository.

With a big release coming up, how can you help? I’m glad you asked!

We have over 100 issues in our issue tracker (JIRA), of package requests that are complete, but need testing before we send them to the stable branch of Foresight.

To do a search in JIRA:

  1. Click here to go to the Foresight issue tracker
  2. Click on Find Issues under the Foresight logo, third from the left.
  3. Under Project, select “Foresight Linux”
  4. Under Issue Type, select “Package Requests”
  5. Now scroll down, and under Issue Attributes and Status select “Needs QA”
  6. Click View, and all the package requests that have been built and need testing will appear

Then do a couple of things:

Make sure the package hasn’t been promoted to fl:2 already:

sudo conary rq packagename=@fl:2

If it hasn’t, make sure it’s not in the QA branch:

<br /> sudo conary rq packagename=@fl:2-qa

If it’s in QA, install it:

<br /> sudo conary update packagename=@fl:2-qa

And test it!

It’s possible it might have been built and needs to be promoted from fl:2-devel, and tested:

sudo conary rq packagename=@fl:2-devel

sudo conary update packagename=@fl:2-devel

In both cases, after testing, please comment on the Issue in JIRA whether the package worked or not, or any other relevant information, for example if it’s missing a .desktop file or menu entry.

That’s it! The QA team and I watch all bug reports via email or the the #foresight-qa and #foresight-alerts channels on Freenode IRC. From there we’ll make sure it gets added to the groups and promoted to the stable branch.

Happy testing, and thank you for the help! Let’s see how many packages we can test in the next few days before Foresight 2.0.5 is released.

Foresight Bug Week Wrap-Up

Foresight Bug Week wrapped up yesterday. I was pretty excited as it seemed we touched a number of issues. Upon further review, we still have a lot of work to do!

Some stats on the last 9 days of working on the issues (hope the formatting works):

9/1/2008 9/8/2008 Net Change

Total issues: 1644 1661 17

Open issues: 597 546 -51

In progress: 19 26 7

Resolved: 578 614 36

Closed: 322 372 50

Needs QA: 106 116 10

Open Issues (By Priority)

Blocker: 2 2 0

Critical 22 20 -2

Major: 66 56 -10

Normal: 505 491 -14

Minor: 57 53 -4

Trivial: 9 10 1

I’m happy to report that Package Requests, which make up about 20% of all issues in JIRA, have been assigned to the new Packagers ID, making it easy for our crack team of packaging experts to search for stuff to do. (Which I blogged about last week).

I personally spent some time porting packages from the fl:1 repo and user contributed repos to Foresight, and closed those package requests. (It’s so much easier when someone has already written the recipe for me!)

What the stats above don’t show is the number of total issues touched, which a report I ran in JIRA puts at 275 (about 30% of all issues in JIRA, both opened and closed). This includes linking duplicates, commenting on bugs if more information is needed, etc. At the end of the day, 5% of all bugs (86) were closed and / or resolved last week, which is a good start.

Next steps:

Out of the open issues, 30% (191) remain assigned to Distro – which means they need to be assigned to a developer to be addressed. Issues needing QA – which means the packages need to be tested, is 7% (116). We also have 19% (123) open package requests assigned to the Packagers ID. Poor Ken (138) and doniphon (82) have the most issues assigned to them, so give ’em a hand and help them out! Test some packages that need QA, and comment on the issue, or if you have time, package some applications that our users have requested.

This is just the beginning of a more regular QA / Bug Triaging process. It was a good first step, and thank you to everyone who lent a hand last week to help out, and I look forward to more help in the future.

Foresight Bug Week

Foresight Bug Week kicked off Sunday, and we’re off to a good start.

As I mentioned in my last bug week post, Foresight has just under 600 issues open in some status or another. (Issues can be improvements, tasks, bugs or package requests).

In the first two days:

  • 15% of all open issues have been touched (about 90)
  • 34, or just over 33% of those touched, were marked as resolved or fixed
  • 56 were triaged and assigned

Out of the 56 that were triaged, the majority of them were package requests that moved from fl:2-devel to fl:2-qa for testing. This means after some testing, these can be promoted to Foresight 2 and closed as well! You can easily search for issues assigned to Foresight QA Team to see which packages need testing.

The other major change to Foresight’s issue tracker, JIRA, was that I created a new generic user, Packagers. Foresight’s JIRA has two generic users – Distro (jira-distro), which all issues are assigned to by default (which makes it easy to triage), and now Packagers (jira-packagers). This way, Foresight contributors who want to help out and create packages, can easily search by this user to see what package requests are outstanding. Most package requests still need to be triaged and assigned to Packagers.

In creating the Packagers user, I realized this weekend that we both of those users use a private mailing list we created. A number of core developers are subscribed to this list, and all issues created in JIRA are automatically emailed to this list. The same is true for the Packagers list, though it only emails those issues assigned to the Packagers user. If you would like to be added to either the JIRA mailing list (high volume) or Packagers mailing list, please drop me an email at pcutler at foresightlinux dot org and I will add you. This makes it easy to keep up in real time on JIRA activity if you so choose.

How you can help during Foresight Bug Week:

  • Join the Foresight QA team! Add your name to the list on the QA space in the wiki, and read through the QA documentation.
  • Triage, triage, triage! Are issues assigned to the right developer? Including package requests to Packagers. For a list of what developers should be assigned certain issues, take a look at the Foresight QA triaging wiki page. Is the issue assigned to the right person, is the component correct (for example I just fixed an issue that was assigned to the PackageKit component, but it was a Package request), is the serverity correct?
  • Test packages! Once a package request has been made, a few different things can happen. The packager might have built it and committed it to their personal repo, as they may not have access yet to Foresight’s repo. Install it and test it! Maybe the packager only could build it for x86, and not x86_64. Check out the recipe, and build it against both arches. (Give the original packager credit in the recipe file and bug report). Commit it to Foresight’s 2-devel repo or your personal repo and update the issue accordingly. When it’s ready to be tested, make sure it’s assigned to the Foresight QA team. Once it’s tested, it’s assigned to Ken to promote to fl:2.
  • Confirm bugs. Can you reproduce it? Comment on the issue with your findings. Check upstream – almost all packages will have their own issue tracker, and search to see if it’s been reported. If so, link to it in the Foresight issue tracker. Good story – Banshee has a bug that the first time you run it, it won’t run from the menu, only the terminal. I searched for about 15-20 minutes in Banshee’s bugzilla, but couldn’t find it, so created a bug in Banshee’s bugzilla and linked to Foresight’s issue and forums, as well as an Ubuntu forum post confirming the bug. Sure enough, it was closed almost right away in Banshee’s bugzilla as a duplicate, I just hadn’t searched hard enough. I linked to it, and within hours Ken applied the patch in Banshee’s bugzilla, and Foresight’s Banshee is now fixed. And the issue is closed!
  • Can you write code? We have lots of improvements filed, from Extlinux boot themes (FL-1532) to adding Encryption / LUKS support (FL-313) to PackageKit improvements. While Ken and doniphon may do the majority of Foresight development, it doesn’t have to be this way, and I know for a fact they would love more volunteers.
  • Need help or have a question? Ask! Join the QA team in #foresight-qa on Freenode IRC. We won’t bite, I promise.

As we continue to improve Foresight’s JIRA, my goal in the future is to publish bug stats bi-weekly. From there, I can better use JIRA’s features and build a roadmap to document how we will continue to improve Foresight.

I’d like to thank everyone who has helped out so far this week in lending a hand. A special shout out to pscott, zodman and jayson_r. Pscott for the cool IRC bot that is talking to JIRA, zodman for a number of recipes I was able to cook in x86_64 and get in to Foresight, and Jayson has dived right in and helped triage. I will be traveling the next two days, but will be back Thursday to help with more issues!

A Bug-huntin' we will go

It’s been way too long since we had a formalized bug hunt week for Foresight.

Worry no more, it’s next week! Starting next Sunday, August 31, through Saturday, September 6th we will be hunting down bugs, tasks and improvements to make Foresight better.

Here are some current statistics from JIRA, Foresight’s issue tracker:

  • Total issues in Foresight: 1,644
  • Open issues: 597 (36%)
  • In progress: 19 (1%)
  • Resolved: 578 (35%)
  • Closed: 322 (20%)
  • Needs QA: 106 (6%)

Open Issues (By Priority)

  • Blocker: 2
  • Critical: 22 [3%]
  • Major: 66 [10%]
  • Normal: 505 [76%]
  • Minor: 57 [9%]
  • Trivial: 9 [1%]

57% of all open issues are assigned to Distro – which means they haven’t been triaged or assigned yet!

The goal of bug hunt is threefold:

  1. Verify the issue. Test it out. Does it exist? Can you confirm it? If so, then we need to get it assigned.
  2. Fix the bugs! Though Ken and doniphon might be the largest contributors to Foresight, they are willing to help out and teach as well. There are a lot of things a new contributor can do – update packages, write patches to fix bugs, test out patches from upstream to see if it fixes the issue (and check with upstream to see if other users of other distros have filed a similar bug report).
  3. Think like an end user. Sometimes it’s hard to see the forest for the trees when you use Foresight every day and get used to it’s quirks. But if you were a new user, whether it’s new to Linux or new to Foresight, what isn’t working, and should be? The goal of hunting down and fixing bugs is to make the best distribution we can.

The bug hunt will fall over a holiday weekend for our USA users. This is both good and bad – maybe you have some extra time available on the holiday to help out. The bug hunt will run all week though – if you need more information, please ping me. We will be hanging out in #foresight-qa on Freenode IRC. More information is available on the wiki, including who’s willing to help, and how to use JIRA.

Writing Foresight Docs: Part 6

It’s been over a year (a year!) since my last post about writing documentation for Foresight. In that time, we’ve shipped Foresight 2.0, and the Getting Started with Foresight User Guide has frequently been met with great feedback when Foresight is reviewed.

I’ve kept up with a few minor updates and edits to keep it fresh, but now it’s time to start planning some major updates. In no particular, I want to focus on:

  • Banshee re-write. Now that Banshee is at 1.2, the screenshots need to be updated to it’s new look, and an overview of it’s new features, including video, podcasts, Last.fm integration and internet radio.
  • Installing Foresight. Jayson was kind enough to attach some documentation and screenshots, but I didn’t find the time to incorporate them. (Hint, hint Jayson)
  • Add a section on Liferea. Write a section on Foresight’s default feedreader. Robin Groves has posted a first draft on the wiki that I need to review and edit.
  • Using GNOME-DO. As the first distribution to ship GNOME-DO, it’s a very powerful application, and new users probably need some help getting to know it.
  • Expand the section on using PackageKit. Some of the icons need to be updated as well.

But more importantly, what do you think is missing from the User Guide? What does a new user need to know? I’d love to get some feedback. Foresight’s User Guide is located in Foresight’s Mercurial repository. I’m also open to any help anyone wants to contribute! If you need help in checking it out or submitting a patch, please let me know.