Foresight Linux is the exception.

Now, this isn’t because they don’t WANT to have a Live CD…they do.  The problem is that rPath, the creators of rBuilder Online, have discontinued the Live CD image creation type.

There was no announcement…no news posting…no clue dart thrown toward Foresight for this discontinuation.  There was only a comment on a single bug in the rPath issue tracker just this past May…Formally discontinued…which in my opinion, is a HUGE mistake as far as community goes.  Why? Because a community is a solid base on which to stand for any distribution or toolset for open source.  rPath has essentially dismissed a feature that the community would find valuable and in the process alienated anyone who finds this feature valuable or desirable.  But I’m not here to talk about whether or not people want to develop their own distributions on rBuilder Online using rPath tools nor the incentive to do so…I’m talking about Foresight. 

So, what incentive does rPath have to help Foresight by fixing it?  Not much…I’m sure there will be those that argue: “rPath has customers and their first allegiance needs to be to them” and those people would be right.  But can’t the Foresight community pick up the torch for Live CD building  on rBO and develop it as a community effort?  Can’t a license be found that it can be released under that would prevent forking?  Can’t it be modularized as a ‘plug-in’? I don’t pretend to know the answer to those questions…I just think that Foresight will continue to suffer as they have been for many, many months now with respect to not having a Live CD.

I’m sure that there will also be those out there saying “but Foresight has a bunch of Virtualized Images to choose from!! No one really cares about a Live CD!!” and I’d say you’re halfway correct.  Developers don’t really care about a Live CD…but those that Foresight attempted to attract…the end user…they DO care about having something they can ‘try before they buy’.  It is my belief that Foresight would be a crap-ton more popular if they had a Live CD.

So What Solutions Are There?

I don’t think rPath will suddenly fix the broken Live CD creation in rBO.  I don’t think they’ll release the code anytime soon (though this is more likely than a fix).  So in the meantime, what if Foresight helped out with LiveCD project that recently was taken over by Unity Linux?  Both Unity and Foresight are Red Hat like distributions and use similar file structures and OS organization.  I think that if Foresight were able to integrate LiveCD onto the distribution, a huge niche would be filled.

Where to Start?

Being involved both with Foresight Linux and Unity Linux gives me a unique perspective on what areas of collaboration could be developed.  One thing is for sure…having both distro development teams onboard would be a huge boon to LiveCD development…and Foresight could suck in SRPMs quite easily from Unity to hit the ground running right away.

I am by no means offering to be the head of this project because I can’t even begin to know where it would start or finish.  I’m just offering a workaround to a problem I’ve seen Foresight have for longer than it should have.  I know the Unity Linux guys would welcome anyone wanting to get involved with helping LiveCD development.  Would Foresight be open to this?  I can’t answer.  I hope so…Foresight needs a Live CD if it hopes to attract more people to it…and that’s something I’m keen on seeing.  Is this something you’d like to see as well?

Foresight, rPath, LiveCD, and Unity Linux originally appeared on Yet Another Linux Blog on October 14, 2009.

Foresight is toying with the idea of having a sub-project (completely separate from Foresight Linux base) that it has tentatively called ‘boots, a Fedora remix‘ (a play on Dora in Fedora for those of you with kids).

What would happen is that mirrorball, a tool from rPath that ‘sucks in’ repositories, would pull in a Fedora repository into a separate Foresight repository.  From there, it is fully consumable by any product/project that is hosted on rBuilder Online from rPath.  Conary really is one of the most innovative package managers on the planet and I’ve mentioned it once or twice before (never got around to part II on one of those though).  The ability to fully suck in a RPM repository is already being done with CentOS and Scientific Linux on rBuilder Online…even Ubuntu is currently being done as well…so we have proof that it is totally possible.  Once imported, Conary takes over the management of said packages.

So what does this give Foresight?  A few things:

1. Testing of packages in 2 communities
2. Developer eyes/chatter in 2 communities
3. The ability of Foresight to cherry pick packages from a large base
4. Compare and contrast for packages from 2 different sources to track down bugs

So, as I said, I was wrong initially and I hope this clears up what Foresight plans to do.  A sub-project will be started that imports the Fedora repository changing them from (rpm to Conary) allowing Foresight to both test and cherry pick packages from a larger base hopefully freeing up a bit more time for Foresight architects.  Phew!  What a mouthful, run-on-sentence that was!

Why Conary?  How does this help Fedora?

I know some of you may be asking Why Conary?  What does it have over RPM that Foresight should suck in a repositoroy and change it to Conary packages?  The reason this is an absolute necessity is because the tools on which Foresight are built (rBuilder Online) works with Conary only…that means ISO generation and repository hosting are all mandated to be Conary based.

The other interesting part about this is that Conary blends version control with package management.  It deals with changesets as packages.  Imagine SVN…you have a local changeset that  you’re working on and the version inside the SVN repository differs from that.  You can then diff the state of your local copy to see how it differs from the remote copy.  This allows you to see the changes you’ve made and allows you to see what code may be broken.  Also, commits are numbered automagically so that you don’t have to worry about breaking things much because you can rollback to a previous known good state.

The same is true with Conary…you can rollback to previous known good states.  You can also diff each changeset locally with the remote repository.  Now imagine this with Fedora packages…if something is broken, chances are Foresight will find a fix for it much more quickly than someone in Fedora…a single command can diff the previously known good version with the broken version and find out the shortcoming.  Or perhaps a known good verion in Foresight that isn’t Fedora based might be used to diff the Fedora RPM version and find out the differences in them.  In all, it’s going to help developers track down problems faster.  This helps Fedora…they now have a small number of Foresight developers who will be working with hundreds of popular Fedora RPMs looking to see if they work or are broken.

Most of the benefit will be measurable in Foresight because they’ll be able to use just about any package Fedora creates…but the Foresight community is FULL of very capable developers…guys that really know what they’re doing.  If they can make this a collaborative effort Fedora will gain exceptionally smart developers as well…even if testing packages on a different platform, they’ll have eyeballs on these packages and if a fix is found or made for them they will definitely go upstream to Fedora.

Hopefully, this puts things right from my initial wrong.  I don’t claim to be an insider for Foresight…I just know a lot of the people involved and ask questions a lot….I also pay attention to the developer mailing list.  If you have any questions, please leave a comment and I’ll attempt to track down answers for them

Clarification on Foresight and Fedora originally appeared on Yet Another Linux Blog on September 9, 2009.

One of the things that team docs here has known for a while is that the rPath wiki is a fantastic tool to leverage for documentation. It’s quick. It’s easy. It allows engineers to contribute directly to the wiki. It allows community members to contribute to to the wiki.

We’ve also known for a while that this tool has a major caveat…and that is that versioned documentation is costly. For example, if we had say version 1.0 documentation of a project at wiki.rpath.com/v1/productname and version 2.0 came out, we’d have to maintain 2 separate documents with the same information in two different URI’s and 2 different name spaces. With each addition of namespace and project version, updates would be more costly and time consuming.

It’s also a bad thing that a user can search the wiki…and have the possibility of getting results from versions that they are not using…possibly information and behavior of products that no longer applies.

So how do we plan on combating this? There are a couple of phases of plans that we’ve been thinking about. The first of these is to move all product related guides (Administrative, User) offline into docbook format (pdf, html). We’ve begun testing this idea already.

This buys us the ability to keep versioned documentation separate from the wiki which empowers customers by giving them only the documentation they need and not requiring them to wade through search results to get the documentation they need.

This also is good for the community. Why? Because community docs will remain on the wiki and product documentation will be separated from it This means that documentation on using open source tools like Conary and working with rBuilder Online will be separate from rPath products making things easier to find and easier to contribute to.

The next phase of the plan after separating product specific documentation is to provide a central repository for those offline docs. This is further down the road and will only take place if product documentation has been moved offline. When this phase hits, there will be a handy website that serves as a central repository for all documentation, whether product based or community based. Currently, there are no plans to move community documentation from the wiki (Conary, rBuilder Online, rMake).

So, those are some of the updates we’ve been talking about doing. Nothing is set in concrete but we’re continuing to stay busy by keeping the information readily available to both community and customer

rPath Documentation Status Update originally appeared on Yet Another Linux Blog on June 12, 2008.

Moving on, I was ANNOYED by the fact that you have a small arrow “” that appears beside any image that references an external URL or any link that does the same. This is fine to let people know that links will take them to a different page…but what I was trying to do was to make a PDF Icon have the same link as the URL it was sitting beside:

So in the above image, if one clicked on the PDF icon or the “Application to Appliance: A Hands-on Guide (PDF)” the PDF would download.

Mediawiki doesn’t provide a fantastic way for you to do this. However, after some snooping around via google, I found a fairly easy way to make things happen.

How to Do This

First things first. Open up LocalSettings.php and make sure to set $wgAllowExternalImages = true; if it’s not done already.

Next get the full URL link to the thing you want downloaded…in my case, a PDF. Then, get the URL for the image you want to display/link. What I did was upload the icon to the wiki and then right click on the icon and ‘view image’. Now let’s put them together:

[http://example.com/wiki/uploads/yourdownload.pdf http://example.com/wiki/images/Pdficon_small.gif]

Just after this will go the actual internal link…because the above is only for the icon. So you’d place your double bracket link just after this single bracket one.

[[Media:yourdownload.pdf|Title of Your Download]]

Now that you have both of these completed, you must encapsulate them in a span class to remove the arrow formatting. Add the following before the single bracket above:

<span class=”plainlinks”>

Then close out the span at the end of the double bracket wiki markup above:

</span>

Putting It All Together

So, to summarize, you’d have the following:

<span class=”plainlinks”>[http://example.com/wiki/uploads/yourdownload.pdf http://example.com/wiki/images/Pdficon_small.gif][[Media:yourdownload.pdf|Title of Your Download]]</span>

Seems like a lot of stuff to get a simple image link right? Yes it is. But it works and I don’t have to install an extension to do it (I’m not fond of extensions). Remember also that you can call that span class plainlinks for other simple external links as well to remove the arrow Hope this helps someone in need…I know it helped me.

I would like to give special thanks to Distributedresearch.net which contains the meat and potatoes of this entry. What I’ve done in the example above is make it generic and give a practical example of how I used Andy’s original post.

Mediawiki: Remove External Arrow from Links originally appeared on Yet Another Linux Blog on February 7, 2008.

The problem with issue tracking systems is they have workflows of their own and often are impartial where they don’t need to be . Wouldn’t it be nice if there was a place where like users of software could come together to ask questions and help each other reach conclusive answers? Hence, the rPath Forum was born.

Stef created the Simple Machines Forum Appliance, which you can install and run in various formats such as VMWare, Xen, ISO, RAW, and even a LiveCD (in x86 and x86_64 bit flavors!). What a wonderful concept…to be able to quickly download and deploy a forum using nothing but a virtualized environment

As some of you know, I’ve chose Simple Machines in the past at MyPCLinuxOS and PCLinuxOS proper to power those communities. Stef and I are excited to power the rPath community with this same wonderful software.

If you are a packager, appliance developer, Foresight Linux user, or are just interested in our products and technologies such as Conary and rMake…come on over to the rPath Forum and register. Drop us a line and say hello

The rPath Forum goes Live! originally appeared on Yet Another Linux Blog on February 1, 2008.

I’m by no means a programmer. I’ve been hired on as a documentation specialist. Yet, Conary is simplistic enough that I can roll my own packages. I’m quite impressed by it’s simplicity and power. If you’d like to help out or are curious about KDE Foresight or the Conary package manager, visit us on freenode #foresight-kde

For those of you wanting alltray goodness…update via Packagekit by searching for alltray OR:

sudo conary update alltray

Alltray in Foresight originally appeared on Yet Another Linux Blog on November 28, 2007.