Changed theme

We are proud to announce that we changed theme and made it easier to navigate in the menus.

There are still some minor changes to do, but overall it’s done.



Forum is up and torrent files are available

Forum is up and we started to make it harder for register spam accounts.

Also we have added torrent downloads for gnome 32bit, 64bit and xfce 32bit, 64bit.



Forum is currently down

As we all noticed, forum is currently down. We don’t know yet when we manage to get in up again.

So in the meantime, we created at temporary forum that can be used:

We hope to get the old forum up as soon as possible. Thanks for your patience.






Want to get involved? Join the web/wiki spring cleaning sprint!

Hey fellow Foresighters!

If you’ve been wanting to get involved with Foresight Linux this is your chance: You are hereby invited to join the FL crew in doing some spring cleaning on our wiki and website. This is an excellent opportunity to meet and have fun with developers, contributors and fellow foresight users.

The sprint kicks off on Friday 2011-04-29 at 1300 UTC.

Just connect to FreeNode IRC and join the #foresight and #foresight-qa channels and talk to ermo or afranke if you have questions or suggestions on how we can improve the content on the wiki and the website.

Hope to see you there!

P.S. The sprint will probably happen over the entire weekend, so if you can’t make it exactly at 1300 UTC friday, don’t worry too much, since chances are that you’ll be able to get in touch with someone anyway.

P.P.S The forum thread is here:


Scheduled Systems Downtime Over

Our scheduled systems downtime for this past weekend is now over and all affected systems are back online! Thank you all who worked so hard to get us up and running, namely:


Splash Screen Winner

The winner of our Splash Screen design “contest” is Fred Vinícius, designer and illustrator for FredDesign! His winning design can be seen during the boot process for the upcoming Foresight Linux 2.5.0 Release.

Winning Design

Winning Design

On behalf of the entire Foresight Linux crew I would like to congratulate Fred Vinícius and thank everyone who submitted their art work!


Splash Screen Submissions

A while back I had asked people to submit their art work for a new splash screen to be included in the upcoming Foresight 2.5.0 release. So far we have received submissions from 2 very talented artists and we’re now in the process of choosing one.

Fred Vinícius from FredDesign sent us the following sample:

From Screenshots

Mike Heitzke from Isotope 11 sent us the following samples:

From Screenshots
From Screenshots

So, what do you guys think? Please send us your positive comments and feedback and help us choose the art that will make into the 2.5 release!


Foresight Linux 2.5.0 ALPHA 1 GNOME Edition Release Notes

It is with great pleasure that I announce the release of Foresight 2.5.0 ALPHA 1 GNOME Edition!

This alpha release, is from our QA branch, and is intended mostly to receive feedback on brand new installs from end-users!

Well known for being a desktop operating system featuring an intuitive user interface and a showcase of the latest desktop software, this new release brings you the latest GNOME 2.32 release, a newer Linux kernel, Xorg-Server 1.8, Conary 2.2 and a ton of updated applications!

Localized screenshot of Foresight Linux

Localized screenshot of Foresight Linux

The following images are available for download right now:

For End Users (QA Label):

  • Foresight Linux GNOME Edition 2.5.0 x86:

Size: 1.68 GB
SHA1: 27cdeb87b82fb653f36725ddcca0c1ef292f20b9

  • Foresight Linux GNOME Edition 2.5.0 x86_64:

Size: 1.86 GB
SHA1: b845276b35f5fd8f68ef017f3c348f3ef9d9dd89

For Power Users (Development Label):

  • Foresight Linux GNOME Edition 2.5.0 x86:

Size: 1.68 GB
SHA1: 53f96867199bdf081e87462aaf4a3d1fb11101eb

  • Foresight Linux GNOME Edition 2.5.0 x86_64:

Size: 1.86 GB
SHA1: 2d4832cb599d08cd5680c5b0a9f7e9b0a85e15d0

For Developer Users (Development Label):

  • Foresight Linux DEVELOPER GNOME Edition 2.5.0 x86:

Size: 2.19 GB
SHA1: 27cdeb87b82fb653f36725ddcca0c1ef292f20b9

  • Foresight Linux DEVELOPER GNOME Edition 2.5.0 x86_64:

Size: 2.40 GB
SHA1: 78487b46a26704d8076370cd83d4560a55ef27c1

Please report any issues or bugs you encounter while using Foresight 2.5.0 ALPHA 1. Foresight’s issue tracker, FITS, is available at

Thanks to all the developers and users who contributed to and helped test this release.

Thank you for using Foresight. Because your distro should be cool.


Looking For a Graphic Designer

The Foresight Linux team is looking for a good graphic designer to help them with a splash screen!

Foresight Linux, a desktop operating system featuring an intuitive user interface and a showcase of the latest desktop software” is now gearing for a major release with all the latest and greatest applications out there!

Would you like to see your art work distributed and displayed whenever someone boots Foresight Linux? If so, please drop me a line for more information!


Council Meeting Minutes 2010-03-12

Replace IcedTea (current) WITH Sun’s Java: There is no real gain in using IcedTea and as far as I know, it isn’t worth the time and effort (OgMaciel)

This actually covers different aspects: A user-facing aspect and an engineering aspect which relates to the nitty gritty technical details of foresight-distro-engineering and how we build Java software. And of course, there is the ever thorny licensing aspect.

  • From a user standpoint, using the Sun JRE gives the best user experience, especially when online banking systems are taken into account. Foresight currently does not ship the Sun JRE but rather the IcedTea/OpenJDK JRE per default in group-{kde,xfce,gnome}-dist.
  • From an engineering standpoint, building against IcedTea/OpenJDK is by far the preferred option, since everything that will build against and run on IcedTea will run on the Sun JRE. The reverse is not necessarily true. Hence, the preferred option is to keep building our packages against IcedTea/OpenJDK even if we ship Sun’s JRE (in group-{kde,xfce,gnome}-dist) and JDK (group-{kde,xfce,gnome}-dist-devel) per default. The point was also made that the general practice in OSS land is to build against IcedTea and hence we would be better off following that trend.
  • It is worth mentioning that while Java apps have build requirements, they don’t have runtime requirements — so whichever JRE owns /usr/bin/java wins. In practice, if both IcedTea and the Sun java stack are installed, then the icedtea java gets consumed byDefault (so a developer who installs IcedTea-{jre,jdk} without uninstalling the Sun-{JRE/JDK} will use the IcedTea-JDK in his local builds, without further action)
  • From a licensing standpoint, we are pragmatic enough to not be fussed about shipping Sun software by default, as the IcedTea JRE/JDK is available in the repository for those who cannot stomach the thought of using Sun’s proprietary Java bits. We may have to revisit this, though.

OgMaciel, doniphon and Mark__T all voted in favour of shipping sun-jre by default in group-gnome-dist. doniphon fixed the groups a few minutes later.

Shipping x86 Flash on x86_64 groups by default

  • Adobe recommends that x86 be used and not x86_64. To improve the user experience, we should follow what Adobe recommends. However, doniphon notes that the two alternative ways of achieving that create their own set of problems.
    • If we keep xulrunner/ffox 64bits, in order to use x86 flash we need nspluginwrapper (we the have latest version in our repository already) which we used in the past. But nspluginwrapper leaks a lot of memory and this is arguably worse than the issues we have now. Also this would imply no flash in chromium64.
    • We could ship ffox/xulrunner/thunderbird/and everything that depends on those as well as all plugins x86. This wouldn’t be a good idea because it would make groups a lot fatter. We can’t have a mixed stack or we would get different stuff that depends on xulrunner to render flash differently.

    None of these two solutions are acceptable.

  • Java has a working 64bit plugin now, and adobe has a somewhat working plugin. We got rid of nspluginwrapper. We believe that flash will eventually be fixed.
  • Outside of rBuilderOnline, there’s nothing to say about Flash performance on x86_64. For a distribution that promotes rBuilderOnline as a way of getting into packaging, we’re not in the sweetest of spots regarding 64-bit flash, but no Linux distribution is. That was a design decision at rPath, and while Foresight is tangentially rPath’s baby, we should not dumb anything down to make it work with something that is suboptimal. Real packagers will use rBuild anyways.
  • Users can install the x86 version of FL for their desktop if they absolutely must have x86 flash working. We should document the command line instructions for those who want to manually convert their system (as well as ways to get back defaults).
  • Given the above points, all three members of the council voted in favour of sticking to x86_64 Flash and waiting for better support from Adobe.

Status update

  • KDE is being updated.
  • jesse and doniphon are going to bump gnome (2.29/2.30 stuff) in 2-devel (that’s why doniphon promoted to 2-qa last night).
  • doniphon thinks that 2-devel is in a better state at the moment than he ever tought it would be possible.

Moving to a fixed release cycle of 6 months to match GNOME’s release cycle

  • Release here means shipping ISOs but we will obviously keep the rolling releases.
  • We should leverage the work being done by the GNOME Devel Kit project.
  • We have always tried to release close to GNOME releases but we haven’t made an impact for a while because we have lacked clear objectives. Council unanimously approves creation of a roadmap with milestones for tentative release dates to be drafted by ermo, afranke and OgMaciel. They are going to build on the existing 2.1.2 ‘roadmap’ and collect issues and post the link to -devel.
  • We shouldn’t plan too much into the future. Dates can be changed, the point is to set objectives.
  • With a roadmap we can specify a commit freeze. We already have such freezes but they happen informally in #foresight-devel where developers are warned that they shouldn’t commit after some date until stuff is promoted to 2-qa. That needs to be documented and formalised.
  • Mark__T is distracted by real life at the moment, so there won’t be noise commits from him. He’s still trying to get his focus back on anaconda and indicator stuff.
  • OgMaciel, afranke and ermo will schedule a meeting to draft roadmap, which will include issues as well.

Proposed members/developers

  • ermo as developer. Accepted unanimously. Congratulations ermo!
  • ermo needs to bug OgMaciel later on to get his new cloak.

FL 2.3.0 release sprint

  • Sometimes pulseaudio gets 100% in one core. This sound issue is not enough to block 2.3.0. There is a clear and effective workaround (pulseaudio -k) that we need to document in the release notes. The bug happens randomly and is not reproducible.
  • smerp is going to work on a FITS list of issues for PackageKit and doniphon will review that later. Some of these issues are blockers for 2.3, some can wait.
  • Transscript
    < smerp> 1. Conary 2.1.8 must be on :2 AHEAD of PackageKit. This is to resolve a temp table problem in Conary fixed in 2.1.8
    < smerp> Those are the *most* important things< smerp> 2. Memory-related fix (using Cache() too much) must be cooked into the version of PK on :2 now (0.4.x)
    < smerp> (and that needs to be in 0.4.x, too)
    < smerp> 3. Update model in PK needs to emulate what updateall does *exactly*, which it currently does not.
    < ermo> this will be useful for the roadmap, btw.
    < smerp> For me, the question of “is packagekit ready?” can be answered by this:
    < smerp> Can a user on :2 update to 2.3.0 with PK without exploding? If so, we win.
    < Mark__T> btw, I will drop ati-fglrx 10.2 and wait for 10.3 (should be released soonish), but 10.1 works fine, so we can go with that one if I don’t get a newer one in time
    < smerp> What this means is that the following things must happen ON :2 before we push the hammer
    < ermo> smerp/doniphon: we need to document how to run the upgrade tests, btw. I tried my hand at a howto on the wiki that describes how to test this.
    < ermo> i.e. the upgrade
    < smerp> ermo: W/R/T update testing: I’m afraid that updating to latest :2 is the only way we can support a real update via PK
    < smerp> people still on 2.0.4… well, I can’t help them
    < smerp> Anyone else besides me use VMware or VirtualBox or something like it?
    < smerp> Best way to test this is to use snapshots and rollbacks in a VM
    < OgMaciel> Mark__T: no voting required… thanks for attending and my apologies for the delayed start from my part
    * OgMaciel could use vmware to test
    < smerp> And, by the way, if PK got into a state where it wasn’t hand-waved as a pain in the ass so that actual power users would use it, that would rock
    < smerp> OgMaciel: please, by all means
    < OgMaciel> smerp: will do
    < smerp> Best thing you can do is get a 1 GiB RAM VM with :2 on it ready to go
    * OgMaciel makes it happen
    < Mark__T> is it PackageKit that’s broken? for me it seems like only gpk is a mess
    * smerp thinks that doniphon should push conary 2.1.8 on to :2 yesterday
    < ermo> So (very) short term, smerp and doniphon get pkgkit sane. Re. sound, we all keep and eye out and make sure to make a note of the snd-card
    < ermo> and document sound workaround in release-notes
    < doniphon> smerp: will coordinate that with mkj
    < OgMaciel> doniphon: so I will test updating current :2 *before* you bump newer conary
    < OgMaciel> for testing purposes
    < doniphon> ok
    < smerp> OgMaciel: it’s likely to break at least once. :D
    < OgMaciel> I will then give doniphon the go ahead and keep all informed
  • ermo is taking care of the polkit/PolicyKit & Gnome System Tools issue. We have traditionally used a scheme where users in the wheel group can elevate privileges using their own password. When we switched to polkit from PolicyKit, our old policies stopped working due to changes in the configuration system in polkit. This leads to the system asking for the root password for authentication. We have no root user, which is obviously a problem. ermo put out a solution so that we’re back to using wheel but something blows up when there are more than one user in the wheel group. The user installing FL is put in the wheel group by default but if you add a new user to the wheel group (with gnome-system-tools or via command line) it goes wrong. This is not a blocker for 2.3.0 because the default case works. We only need to document it as a known issue. ermo will make a new issue for it and report there.