LinuxPlanet Blogs

After all the sessions at GUADEC¹ about Gnome Shell, I got once again really excited about it as well as the whole future of Gnome itself. I had run Gnome Shell previously, you can just install it from the Fedora repos, but the version that is currently in most distros (including Fedora 13) is months old and the project is obviously making great strides constantly. After a pretty abysmal attempt at installing it from the project’s experimental repo which shot most of my GTK-related packages point blank in the head, leaving me only with the option to delete integral GTK packages from my running machine and reinstalling them via yum downgrade, I decided to build a stand-alone version of Shell from their git repository. Luckily, this turned out to be amazingly easy. So if you have about half an hour (depending on how fast your system is with compiling stuff) and you want to have a look at what’s coming in Gnome 3, you might find the following instructions helpful²:

This will pull the current dev version of Gnome Shell from the git repository and compile a stand-alone version of it in your home directory that you can run at you leasure. To do this, the first thing you want to do is download the install script from the Gnome site to your home directory and run it.

cd ~
curl -O http://git.gnome.org/browse/gnome-shell/plain/tools/build/gnome-shell-build-setup.sh
/bin/bash gnome-shell-build-setup.sh

You can then start the actual build process. This will take some time as the script has to check out a ton of packages from git and compile them one after the other. You best start this in its own little terminal window and get on with whatever you were doing before or fix yourself a nice cup a coffee and watch the awesome matrix simulator build into gcc (best viewed fullscreen in an old school terminal font and green-on-black text).

jhbuild build

If this completes without errors, you got yourself a standalone version of Gnome Shell that you can now manually run. Change into the specified directory and start up Shell.

cd ~/gnome-shell/source/gnome-shell/src
./gnome-shell --replace

The --replace command will tell it do replace your current window manager so that you get the full experience, if you want to quit out of Shell just issue a Control-C in the terminal you started Shell from. If something major goes wrong, you can always change to a different tty (Control-Alt-F2 for example), log in, and kill X by issuing the command killall Xorg as root. Just be aware that this kills all of your currently running programs. Bear in mind that I have tested this on Fedora 13 and depending on your distribution, some of these details might be slightly different. The actual steps to run and build Shell from git, however, should be pretty universal.

I hope you enjoy tinkering with it as much as I do at the moment. Feel free to file bugs and help the devs out with valid feedback, I think they are quite short on people testing this at the moment. If you want to rebuild a newer version of the packages, you can follow these instructions. You can also follow the development on identi.ca of course.

Máirín has been working on a redesign of the web presence for the Fedora Project and has recently been posting mockups of her ideas for the main page. We are now looking for feedback on these. It has been clear for a while that Fedora’s web sites needed a visual overhaul and I am very happy to see this work extending to the main page for the upcoming release of Fedora 14. I’m myself currently not directly involved with this effort but the Design Team is in the process of discussing the mockups and I thought I’d help out with getting a few more eyeballs on these.

So if you have some feedback or want to post some mockups yourself, feel free to do that in the comments — I will relay that information back to the team. You can also post comments on identi.ca, and if you do so, please tag them with #fpodesign so that we can track them. The Fedora Design Team now also has a group on identi.ca, by the way, so you can join that if you want to stay up to date on what we are up to and any further developments on the website redesign as they happen. I can’t wait to see how this turns out!

Just to clarify: The picture on the right is just one possible design that Jef did. Please hit the links above to have a look at the designs Mo posted as well.

There are many applications out there for Linux that can import to your computer. But we will list 3 of them, probably the best 3 open sourced applications out there today.

F-Spot

F-Spot supports 16 common files types, including JPEG, GIF, TIFF, RAW, and others.

Import your photos from your hard drive, camera (including PTP type), or iPod.
Creating a CD of photos is just clicks away. Simply select the photos you wish to have on CD, and choose “Export to CD” from the main menu.

If you have a Flickr, 23, Picasa Web or SmugMug account, F-Spot can export photos to it, while optionally resizing your selection, and preserving tags and metadata.

You can also export to Gallery or O.r.i.g.i.n.a.l. powered websites, or a nicely themed static webpage.

Shotwell

Shotwell Features:
1. Import: Import photos from folders or from any digital camera supported by gPhoto.

2. Organize: Shotwell automatically groups photos taken at the same time. You can also use tags to organize your photo collection.

3. Edit: You can rotate, crop, reduce red-eye, and adjust the exposure, saturation, tint, and temperature of each photo.

4. Publish: Publish photos to Facebook, Flickr and Picasa Web Albums.

Rapid Photo Downloader

This one isn’t like the 2 others, as this application is a pure import application. So if you only plan to import photos/videos, then i would go for this application. No question about it.

Conclusion

If you need a great feature rich application, then F-spot is the one for you. Specially the version 0.71 that was recently released.

If you only need to grab a few photos and easy to upload them to facebook or flickr, then Shotwell is the one to use. It’s more slimmed, but remember it cant handle as much file types that f-spot do.

If you need a pure import application, then go for rapid-photo-downloader.

To install these ones in Foresight, open terminal and write:

sudo conary update f-spot

sudo conary update shotwell

sudo conary update rapid-photo-downloader

The version of the applications we got today is:
f-spot 0.7.1
rapid-photo-downloader 0.3.0
shotwell 0.6.1

As many of you probably already know, I recently joined the Fedora Design Team and as such my Fedora-related posts are now distributed to Planet Fedora and the smaller Design Team Planet as well. For Fedora 13, I designed the website banner on the main page after Máirín Duffy kindly asked me to and for the next release I am concentrating on the supplemental wallpapers which we want to include. Let me tell you about that…

»Autumn Colors« by Joisey Showa (joiseyshowaa on Flickr)

Máirín has blogged about the wallpaper we are working on to include as a default, but we are also aiming to include a lot of additional wallpapers (much like upstream Gnome does) that people may use as an alternative. We are looking for photos or abstract graphics that lend themselves to being good wallpaper, ie. something not too distracting or busy — close-ups of grass and flowers, landscape vistas, abstract graphics like swirls and bubbles are all good examples but try to think out of the box as well. We are collecting submissions on this page until Thursday, August 19 (one day before my birthday, incidentally) after which the Design Team will vote on the submissions and decide what will be included. So if you have an idea for something you think would fit the bill, please head over to that page. We will need the following information for each submission:

1. URL of the image (ie. “where it’s at”)
2. Title of the work in question
3. Name of the author (their real name is preferable, but a nickname with a link to the profile on the page the image is from works as well)
4. Contact information for the author, email if possible
5. URL of the source page that the image was originally from
6. The license of the photo (has to be compatible with the Fedora requirements)

You can either go to the wiki page directly and add the photos yourself or you can use this handy script to upload them automatically (usage instructions). If you want, you can also email me submissions directly to fab@sixgun.org as long as you provide the above information and make it clear in the subject line that you are submitting wallpapers for Fedora. If you find a nice image and it isn’t released under an acceptable license, you might want to try to contacting the author to release it under a license that would make it possible for us to ship it. We can also ask the author ourselves if you want, just email me about it if that is the case.

»Oregano Orejón« by María Leandro (tatica on Flickr)

I think this is an awesome opportunity to get your own work or someone else’s that you enjoy into Fedora and at the same time improve things for everyone. Who doesn’t love gorgous wallpapers, after all? As I see it, this is one of the easiest ways ever to contribute to a F/OSS project and could still be very rewarding. I am looking forward to lots of great submissions so go ahead and knock the ball out of the park with your find!

Mike McGrath & co. drafted a nice doc titled “How to be a successful contributor” it should help set expectations of and for new contributors. I’ve pasted the first version I have seen but you should go to https://fedoraproject.org/wiki/How_to_be_a_successful_contributor to see newer versions…

How to be a successful contributor
From FedoraProject

Contents

* 1 Audience for this document
* 2 Things to know before you join
o 2.1 Time commitment
o 2.2 Get permission from work
* 3 Joining
o 3.1 Observation
o 3.2 Pick what you want to work on
* 4 Don’t jump into the deep end
o 4.1 First contact
o 4.2 Find a mentor or sponsor
* 5 Contributing
o 5.1 Look for work
o 5.2 Quitting

Audience for this document

This document is targeted at people interested in contributing to the Fedora Project. In the Fedora Project, students, professionals and hobbyists all come together to produce software, marketing materials, art, documentation, etc. We all started as new volunteers at some point. The items below are designed to help you through the process of joining a team. It helps you know what we expect of you and what you can expect of us.
Things to know before you join

Everyone who joins a free software project does so with the best intentions of staying. However, few stay to become regular contributors, and fewer still become leaders within the project. The biggest difference between those that stay and those that leave is commitment and time.
Time commitment

Some volunteers may spend 15-30 hours per week contributing, doing that while holding down a proper day job is a difficult time management skill. As a volunteer, you should ask yourself whether you can devote 2-4 hours per week, even though it’s less than an hour per day. 4 hours a week for most people is an entire afternoon one day. That’s a significant chunk of time.
Get permission from work

There is a mutually beneficial relationship between working for a living and volunteering. Many contributors will find their skill sets at work increase dramatically just by having access to and learning from another environment. This benefits employer and worker. It is completely worthwhile to sit down with an employer or manager and ask for permission to contribute during work hours, even if it’s only a couple of hours on a Friday afternoon. Explain the benefits to you and your employer.

If they say no, then you’ll have to volunteer in your own time.
Joining

The single biggest mistake most new contributors make is showing up “just wanting to contribute.” It’s important to take the time to observe the team (refer to the section below) and see how their work aligns with your own skills and personality. Know that getting work to do on day one is very rare, and those who are highly skilled in a specific technology will still have to take the time to get to know an environment before access is granted.

For example, if you’re a database expert it is very unlikely you’ll be given access to databases (where personal info, passwords, etc) are stored within your first several weeks of volunteering. If you’re looking to become an ambassador, it is unlikely you’ll get marketing materials shipped to you in your first week. This may seem unfortunate, but it’s necessary to keep the project members working well together. The same can be said about any major changes, like a complete redesign of a system or a new look and feel for a website. Don’t get discouraged. Show up as often as you can, and get to know the team.
Observation

It is important to get to know the organization and teams you are looking to work with before you try to join them. Learn what they do and how they do it, and try to get to know the people involved. It is extremely unlikely you will be able to actually contribute from day one. In organizations with hundreds or thousands of people working together, understanding how things work is critical.

Don’t be shy about asking questions and getting to know people. Plan to spend several days or even weeks attending meetings, emailing on mailing lists and hanging out on IRC before you get to do any actual work. Offer suggestions on topics being discussed, and share any experiences (good or bad) you’ve had that is relevant to the discussion.

Part of observing and making constructive suggestions may require withholding judgement. When making suggestions, don’t assume you come with all of the answers or that the Fedora Project is doing it all wrong. There is a good chance we can improve the way we are doing things, however most of our current practices were developed over long periods of time after lengthy discussion. Your criticism may be better received once you have established yourself in the community and are perceived as understanding our culture.
Pick what you want to work on

It’s your job to decide what you want to work on. Pick something that’s important to you and something you have passion for. You’ll see this advice repeated several times in this document: Don’t just show up looking to have work assigned to you. Get to know the teams and procedures they have in place. Ask questions and really get to know what you’re going to be working on _before_ trying to work on it.
Don’t jump into the deep end

When picking something to work on, don’t be the sole person to take on a huge task as your first contribution. Picking a task that’s too large signifcantly raises the chances of failure. Also don’t pick several things on several teams to work on. Start small, picking at most one or two things, and grow from there. The key is slow, steady, and sustainable growth. Don’t join with the immediate goal of becoming the next leader of the project. Start small.
First contact

After you’ve decided what you’re looking to do and what team you are looking to do it with, it’s time to send an introduction to the list. When sending an introduction (usually by mail list), include the following information:

* Name
* Time Zone / Country
* Basic skills and experiences
* Why you’re joining
* What you’re looking to do (be specific)
* How much time you can contribute (usually hours per week)

If any of the above questions are not clearly answered, don’t send the email yet. You’re not ready. Remember, be specific about what type of work you’re looking to do. Saying “Whatever needs to get done” isn’t helping anyone. Saying “I’d like to help document system A,” “I’d like to translate software for my native language,” or “I noticed this webapp is particularly slow sometimes and I’d like to help fix that” is perfect.
Find a mentor or sponsor

This step is both incredibly difficult and important. Finding a proper sponsor will increase your chances of being a successful contrubitor significantly. Sometimes it’s absolutely required. A sponsor will help with training, introductions and teaching new contributors how a team works.

Most teams have mailing lists. Email the list, say you’re looking for a sponsor, and explain what you are wanting to do. If you haven’t heard back in a few days, reply saying that you are still looking. Keep doing this. Most sponsors are people that have been in the project for a long time, and are often very busy.

They don’t mean to be rude and don’t want to send the impression they don’t want new contributors. It’s just that at the moment, some people will assume other people will take care of you and so for the moment, no one does. This is a common problem — in real life as well as in online communities — and a difficult one to fix. But sticking to it and continuing to ask for help without being annoying will show that you are serious and ready to contribute. Don’t send this kind of message more than once every couple of days, but be positive, and persistent if needed.
Contributing

Once you’ve got something to work on, it’s time to actually do work. The first several tasks you will work on will likely be small or maybe mundane. Do them consistently, conscientiously and well. This will raise the level of trust you have from the other team members.

As with other volunteer organizations, there are high turnover rates in the free software universe. Training volunteers is time consuming, especially for more complex tasks, and requires a commitment from currently busy volunteers. Spending days or weeks training someone only for them to vanish can be disheartening for mentors and sponsors. By giving out small tasks that have been hanging around, a sponsor can help you take small but vital steps, and learn whether or not the work you’re going to be doing is really for you.
Look for work

If you have access to a repository, system, or content, consider yourself a partial owner. This doesn’t mean you should immediately re-design everything. Remember that other owners have time and effort invested in the current material as well. It does mean, though, that you should take pride in the work you are doing. If you see something not quite right, do research on it and notify the list. Seek work out, keep yourself busy and help others.
Quitting

If volunteering isn’t for you, that’s OK. You don’t need to be embarrassed that you can’t contribute further. Contributors will not make you feel bad about it either. Realize that lots of contributors come and go every day. Being busy with your day job or not having enough free time is a perfectly valid reason for not being able to contribute. It’s even possible that you might not feel a good fit with the team or organization. You’re entitled to offer help as a volunteer how you want and when you want.

First and foremost, though, don’t just vanish. When a contributor or potential contributor agrees to do work, can’t follow through for a valid reason, and vanishes, the team may not know the work can be reassigned. In some cases, people in the team may even worry about the contributor’s health or well being.

When you’ve decided it’s time for you to go or take a break, let your sponsor or the list know and let them know what you were working on. Having people think you are working on something when you aren’t slows the team down, and ultimately doesn’t benefit you or the team.

Chris Ball posted this to an OLPC announce mailinglist and I thought I would share with you all.

Now that the 10.1.1 release for XO-1.5 is out, it’s a good time to
talk about OLPC’s software strategy for the future. We’ve got a few
announcements to make:

XO-1:
=====

OLPC wasn’t planning to make a Fedora 11 release of the XO-1 OS, but
a group of volunteers including Steven Parrish, Bernie Innocenti,
Paraguay Educa and Daniel Drake stepped up and produced Fedora 11 XO-1
builds that follow the OLPC 10.1.1 work. I’m happy to announce that
we’re planning on releasing an OLPC-signed version of that work, and
that this release will happen alongside the next XO-1.5 point release
in the coming weeks. So, OLPC release 10.1.2 will be available for
both XO-1 and XO-1.5 at the same time, and will contain Sugar 0.84,
GNOME 2.26 and Fedora 11. We think that offering this fully
interoperable software stack between XO-1 and XO-1.5 laptops will
greatly aid deployments, and we’re very thankful to everyone who has
enabled us to be able to turn this XO-1 work into a supported release!

To prepare for this XO-1 release, we’ve started working on fixing
some of the remaining bugs in the community F11/XO-1 builds. Paul Fox
recently solved a problem with suspend/resume and wifi in the F11/XO-1
kernel, which was the largest blocker for a supported release. We’ll
continue to work on the remaining bugs, particularly the ones that
OLPC is uniquely positioned to help with.

The first development builds for this release will be published later
this week.

XO-1.5:
=======

We’ll be continuing to work on XO-1.5 improvements, incorporating
fixes to the “Known Problems” section of the 10.1.1 release notes¹
into the 10.1.2 release.

XO-1.75 and beyond:
===================

XO-1.75 software development is underway. Today we’re announcing
that we’re planning on using Fedora as the base distribution for the
XO-1.75. This wasn’t an obvious decision — ARM is not a release
architecture in Fedora, and so we’re committing to help out with that
port. Our reasons for choosing Fedora even though ARM work is needed
were that we don’t want to force our deployments to learn a new
distribution and re-write any customizations they’ve written, we want
to reuse the packaging work that’s already been done in Fedora for
OLPC and Sugar packages, and we want to continue our collaboration
with the Fedora community who we’re getting to know and work with
well.

We’ve started to help with Fedora ARM by adding five new build
machines (lent to OLPC by Marvell; thanks!) to the Fedora ARM koji
build farm, and we have Fedora 12 and Sugar 0.86 running on early 1.75
development boards. We’d prefer to use Fedora 13 for the XO-1.75, but
it hasn’t been built for ARM yet — if anyone’s interested in helping
out with this or other Fedora ARM work, please check out the Fedora
ARM page on the Fedora Wiki². We’re also interested in hiring ARM and
Fedora developers to help with this; if you’re interested in learning
more, please send an e-mail to jobs-engineering at laptop.org.

We’ll also be continuing to use Open Firmware on the XO-1.75, and
Mitch Bradley has an ARM port of OFW running on our development boards
already.

EC-1.75 open source EC code:
============================

OLPC is proud to announce that the XO-1.75 embedded controller will
have an open codebase (with a small exception, see below). After much
behind-the-scenes effort, EnE has agreed to provide us with a public
version of the KB3930 datasheet and is allowing our new code to be
made public.

The code is not available yet due to a few chunks of proprietary code
that need to be purged and some other reformatting. A much more
detailed announcement will be provided once the new code is pushed to
a public repository. The code will be licensed under the GPL with a
special exception for OLPC use.

The exception is because EnE has not released the low-level details on
the PS/2 interface in the KB3930, so there will be some code that is
not available — relative to the codebase this is a very small amount
of code. The GPL licensing exception will allow for linking against
this closed code. We’re going to investigate ways to move away from
this code in the future. (As far as we’re aware, this will make the
XO-1.75 the first laptop with open embedded controller code!)

Multi-touch Sugar:
==================

We’ve begun working on modifications to Sugar to enable touchscreen
and multitouch use (the XO-1.75 will have a touchscreen, as will
future OLPC tablets based on its design), and we’ll continue to do so.
The first outcome from this work is Sayamindu Dasgupta’s port of the
Meego Virtual Keyboard³ to Sugar — you can see a screencast of it in
action here⁴.

It’s an exciting time for software development at OLPC. Many thanks
for all of your support and efforts!

- Chris, on behalf of the OLPC Engineering team.

Footnotes:
¹: http://wiki.laptop.org/go/Release_notes/10.1.1
²: http://fedoraproject.org/wiki/Architectures/ARM
³: http://gitorious.org/fvkbd
⁴: http://dev.laptop.org/~sayamindu/sugar_vkbd_multi.ogv
–
Chris Ball
One Laptop Per Child

This tutorial will guide you on how to allow a group of users to run all the commands without sharing your system root password in Fedora / Redhat / CentOS based Distros.

This is similar to the sudo in Ubuntu. Here we will start by creating a group called "sysadmin", then we will append a user "chia" to that group which will be able to run any command on the system. Lets start by creating a group and adding a user to it.

[root]# groupadd sysadmin

[root]# usermod -aG sysadmin chia

Now edit the /etc/sudoers. Its possible to edit the file in an editor, but its safer to use visudo instead.

[root]# visudo

Add the following line to the file

%sysadmin  ALL=(ALL) ALL

Now you can login as user "chia" and run any command by appending sudo.

[chia]$ sudo ifconfig

You can also gain access to root shell by using password of user "chia"

[chia]$ sudo -s

[sudo] password for chia: <chia's password>

[root]#

Back in 2006, one of my first demonstrable pieces of work for Fedora was writing a magazine article for the now defunct “International Developer” magazine at the behest of then-FPL Max Spevack. One of the things I touted in that article was how work done in Fedora influenced the next RHEL. It’s been a long time since I’ve even thought about that magazine article. Recently, however, I received an email from David Malcolm about one of the packages I maintain in Fedora and EPEL by the name of pywbem. He said that Red Hat was going to be including pywbem in RHEL 6 and that he was going to use my spec file to do so. While I realize that pywbem is a relatively small python library, bordering on insignificant and dmalcolm could have probably created a better spec file sans my involvement, it thrills me to no end to be able to have some personal evidence to show that Fedora is not only the upstream, but that volunteers can have their work effect subsequent RHEL versions.

Problem

Sometimes you’ll get a dialog box that pops up saying that firefox is already running when you know in fact that it isn’t.

Firefox Already Running Dialog Box

Solution

This is typically caused by the existence of 2 files in your ~/.mozilla/firefox/<profile> directory. For example in my case:

1
2
3

% ls -la ~/.mozilla/firefox/rhwevaqa.default/|egrep "lock |lock$"
lrwxrwxrwx  1 tstacct users       16 2010-06-22 18:49 lock -> 127.0.1.1:+11131
-rw-r--r--  1 tstacct users        0 2010-06-22 18:49 .parentlock

Just delete these 2 files and firefox should start right up.

References

For more info about Firefox startup issues check out this mozilla FAQ

NOTE: For further details regarding my one-liner blog posts, check out my one-liner style guide primer.

A little while back we were offered a booth at Fosscon. None of the local Ambassadors were able to work the booth because they were the ones putting the con on. So I stepped up and took ownership of the event… not fully understanding what owning an event really meant. So as we can all guess I have failed in the most epic way.

I took on an event that had very little discussion going on around it, then when the chatter didn’t improve I assumed that there was no interest and that I was ignored and it was a dead issue. I WAS SO WRONG.

So here is the deal, I do not have the skills required to pull this of, so unless someone takes up this cause it is gonna finally going to be shelved.

If you are interested hop into #fedora-ambassadors on freenode or send your emails to the ambassadors list NOW!