Skip to content

Foresight

Foresight Year in Review

One of the things I’ll be working on this weekend as I try and finish up the December newsletter, is adding a “Year in Review” section for this months issue.

From our 1.0 release this past January to alpha 1 of 2.0 in December and everything in between, I’m looking to capture the highlights this year for Foresight, it’s users and developers.

Have an idea? Email me at pcutler at foresightlinux dot org or leave a comment below, and you can be part of the newsletter!

Paul

Planet Foresight is moving

Planet Foresight is moving!

Currently located at www.foresightlinux.org/planet you may have noticed that it now only updates once a day. The current planet uses Feedjack, a Django module, which was crashing our webserver for some unknown reason and we had to turn off updates and instead run a cron job.

Our resident Alaskan, smithj (with his own shiny new blog!), has been kind enough to set us up with our own Venus planet appliance, now at http://planet.foresightlinux.org.

If you subscribe to the current planet in a feedreader via RSS, please update your feed to: http://feeds.feedburner.com/foresightplanet

We will be migrating the official feed in about a week.

GNOME Developer's Kit

As someone who has for a long time wanted to get involved with an open source project, and specifically GNOME, the GNOME Developer Kit is a true blessing. (And more on my wanting to get involved in a different post in a week or so).

The GNOME Developer Kit is fully functional operating system with the latest (unstable) branch of GNOME. Available as an ISO you can install on your hard drive, or a VMWare image you can boot within your current OS, it has everything you need to start contributing back to GNOME. The GNOME Developer Kit is based on Foresight Linux, and uses Conary and PackageKit to stay updated with the latest commits from GNOME Subversion. Both the Dev Kit and Foresight were created by Ken VanDine, Foresight’s lead developer.

Og Maciel, a GNOME contributor, blogged about using the GNOME Developer Kit in assisting the translation teams. One comment in particular caught my attention, asking if translations were too hard of an area for someone new to contributing to start with.

With this in mind, what kind of documentation should be included with the GNOME Developer Kit, and where should it live? Getting started in open source can be daunting, and GNOME can sometimes come off as a bit of a clique, making it even harder for someone to start. Translations, bug triaging, and documentation are typically easy areas for someone new to start, but I’ve seen some challenges first hand trying to get involved. I don’t have any answers, but some of the questions that come to mind for me are:

  • Should documentation live on the image or on the wiki?
  • If on the wiki, should it link to other sections of the GNOME wiki (live.gnome.org or LGO for short)? (For example, the “Testing Patches” is linked on the GNOME Dev Kit’s LGO page to the Testing Patches LGO page.)
  • If on the image, should it be a docbook file similar to the Foresight User Guide, or just an HTML page?
  • What common tasks for developers should be documented? Think back to when you were just getting started with contributing, what questions came to mind?
  • What else?

Getting started with contributing back to an open source project takes determination and even a bit of courage. Tools like the GNOME Developer Kit help make that start even easier.

Software I'm excited about

A brief post as I’m still traveling for work. Here are a couple big and small packages in development that I’m excited about:

  • Flyback: A GUI wrapper for rsync and rsnapshot to make backup easier, that is often compared to Apple’s Time Machine. It’s a python script that creates a GUI for the user and makes it simple to create and schedule backups of a user’s directories and files. Choose which directory, files, hidden files, and it sends the back up to a directory of your choosing. It’s still very early in development, and I didn’t see a way to send a backup to a network share that’s mounted in GNOME. But I believe most users don’t backup enough, and for a distribution like that Foresight, that “just works”, backup should be added to the list of things that just work for a user.
  • GNOME-DO: A Quicksilver-like application that is difficult to explain, but can increase your productivity ten fold by making it easy to quickly open applications, jump between open windows and more. See more at Download Squad including a video of GNOME-Do in action.
  • Publishr, a small one, but looks useful, Publishr adds a “publish” plug-in to GIMP to make it easy to send your images to Picasa or Flickr. Sure, F-Spot has had this feature forever, but there are a lot of times when I’m editing a screenshot that I want to send to Flickr that I won’t put in my F-Spot library, and this plugin will help skip a step by having to use Flickr’s web upload feature.

I’m definitely going to keep an eye on these applications, and may add to my Foresight repository when I get some time.

Setting up a Foresight 2 build environment, Part 1

I don’t fancy myself a Linux developer, thought I aspire to be one someday. I can barely manage my own systems, and consider myself more of a power user.

One of the advantages of Foresight Linux though, is how easy it is to get started, both in creating and managing packages, and in how open the community is in welcoming you when you decide to start, and answering your (dumb) questions.

The upcoming 2.0 release of Foresight requires a slightly different setup and methodology for packaging. Here is a brief overview of how I set up my PC for creating packages on Foresight 2. (And if I’m doing something wrong, please leave a comment!)

[

Visit the Foresight 2.0 Developer page on the wiki.]1 (A big thanks to thilo and doniphon for the information on this page).

**

Step one**: Add the development packages to your system. From a terminal type:

sudo conary update group-devel

Step two: Create a .conaryrc file. Open Gedit (Applications -> Accessories -> Text Editor) and copy the .conaryrc example from the wiki link above and save it in your user’s home directory as .conaryc

Step three: Create a .rmakerc file. Open a new tab in Gedit and copy and paste the .rmakerc example from the above wiki page.

Step four: Edit your .bashrc file. In Gedit click Open, and hit Ctrl-H to show hidden files, and double click .bashrc. At the bottom of the file, copy and paste the .bashrc group cooks from the wiki page above.

Step five: Create the directories needed. From your user’s home directory:

mkdir conary

mkdir -p ~/conary/foresight.rpath.org ~/conary/builds ~/conary/cache

Step six: Create your context. In a terminal type:

cvc context fl:2-devel

And that’s it! I wouldn’t be surprised if there are quicker and / or easier ways to do this, but this is what worked for me, with pointers from Ken.

Next time: Checking out and updating a package.

Other sources:

[

Foresight 1.x build environment howto]2

Conary wiki

Foresight Linux Newsletter Volume I, Issue 8 Out

After a month off (due to wiki maintenance) the Foresight Newsletter is back! Volume I, Issue 8 highlights the latest security fixes, Foresight in the news and a look at the first alpha of Foresight Linux 2, including:

  • Alpha release highlights
  • Known bugs
  • New editions: KDE and XFCE!

Issue 9 will start planning soon, if you want to lend a hand and write a section, ping me in IRC!

Update: How could I forget to mention this? Go digg it! (Thanks to etank for submitting to digg)

Foresight KDE Edition

As a GNOME guy, I don’t use KDE.

As it was pointed out to me today (thanks Og!), without any intended ill intent, I left off any news of KDE in the Foresight Newsletter I’m working on.

One of the cool things coming with Foresight 2.0, is a KDE edition and a XFCE edition. The beauty of open source is choice – whether it’s a desktop environment, music player or your choice of web server.

The KDE edition is a little further along than the XFCE edition at this point, and one-ups the GNOME edition in the fact that it’s only 695 MB! One of these days we will get the GNOME edition to fit on a single CD. 🙂

Jtate and Int are leading the way in developing the KDE edition, which is also attracting new Foresight users such as Nixternal, whom you may know from such shows as Planet Ubuntu or Chicago LUG, and old Foresight users such as Og, who’s helping translate KDE to pt-br.

Now is a great time to get involved with Foresight – whether it’s helping polish the GNOME edition, help building the KDE or XFCE editions, or helping on any number of tasks in progress, such as documentation writing; bug triaging; building our next generation website or forums, or helping with marketing and attracting new users.

More information coming in this month’s newsletter!

Growing the Foresight Community

Og’s latest blog post links to David Bolter’s blog with a post on “Transparency in Community Decisions”. David writes:

Transparency should be applied to how decisions can get made in FOSS communities. This can involve different layers; for example, transparency could apply to:

  1. Who gets to participate in decision making.

  2. How these people are selected.

  3. The process of decision making.

In FOSS communities I think transparency should apply to all three where reasonably possible. What do I mean by this? Let’s take a couple of examples:

A) Getting hired by a FOSS organization which is integral to the community.

B) Getting commit access to an svn repository.

C) Getting syndication of one’s blog onto a planet/aggregator.

The timing of this couldn’t be better. The Foresight Marketing Team is about to tackle some of these exact tasks, specifically on what it means to become a user and developer within Foresight. This includes perks, such as IRC hostmasks or foresightlinux.org email addresses, but more importantly how to get commit access.

We don’t have all of the answers yet, especially for 1-3 above (other than Ken gets veto power!). But David’s post highlights the need for transparency, not only in how we build these processes, but how we execute them going forward.

We will be having a Marketing meeting sometime in the next week or so, with details to come soon.

Foresight Linux 2.0 Alpha Bugs wanted!

Yes, the title is right. Are you running the alpha of Foresight Linux 2.0? We want, no, need your bugs!

The alpha has been out for a couple of weeks now, and only ten bugs have been filed against the alpha, with two of them fixed. And I’d argue a couple more aren’t really bugs, but enhancements or tasks.

Please, please file bugs against the alpha. This way we know what needs to be fixed or needs improving. A new alpha release should be out sometime in the next week or two as well.

In other bug news, see me or Kevin if you’re interested in joining the QA team and want to help with bug hunting. We have 110 bugs assigned to Distro that need triaging! (Learn how to triage here.)

So please file bugs against the alpha, we want your desktop to be cool (and bug free).

Foresight Linux 2.0 Alpha Screenshots

Phoronix has a blurb up showing off Foresight 2 (I won’t call it a story, with the exception of the opening sentence, it’s cut and paste from the release announcement).

It’s nice to see us get some press, and more importantly, there are 15 screenshots for you to peruse.