Fedora People

Bryan Clark: Raindrop & Jetpack

Sat, 21 Nov 2009 01:25:32 +0000

The other day I did a quick hack using Raindrop & Jetpack to get new mail notifications from Raindrop. In total it took me less than an hour. It’s no Joe Shaw hack, so I don’t expect to get in the paper for this but I figured I’d share anyway.

This Jetpack checks Raindrop to see if there are new messages and bubbles them up as notifications if there are. Here’s the source code:

var messages = {}; 

function checkMail() {
 var api="http://localhost:5984/raindrop/_api/inflow/conversations/home?limit=10";
 jQuery.getJSON(api,
               function(data, textStatus){
                 jQuery.each(data, function(i,item){
                   if (item.unread) {
                     if (!messages[item.id] || messages[item.id] != item.messages.length) {
                       var n={title: item.subject,
                              body : item.messages[0].schemas["rd.msg.body"]["body_preview"],
                              icon : 'http://localhost:5984/raindrop/inflow/i/logo.png'};
                       jetpack.notifications.show(n);
                     }
                     messages[item.id] = item.messages.length;
                   }
               });
 });
}
setInterval(checkMail, 10000);

To try this out you’ll need Raindrop installed and running and Jetpack installed in Firefox.

Go to about:jetpack and copy the above code into the Develop tab, then click the try out this code link just below the Bespin editor.

If you don’t want to do all that you can just watch the video below (no sound, so you might want to play some music)

Debarshi Ray: Solang: Brasero integration

Sat, 21 Nov 2009 01:04:00 +0000

I spent some time today writing a CD/DVD exporter for Solang using Brasero's new libbrasero-burn API. It is to be noted that we are not spawning a new Brasero process, but embedding some widgets in Solang's own ExporterDialog and making a few API calls here and there.

I wish they had exported the BraseroMediumProperties widget also.

Unfortunately, the code will not easily compile because of silly reasons like some of the libbrasero-burn headers having missing G_END_DECLS. And yes, the dialogs do have misleading titles. Will fix those soon.

David Malcolm: 2to3c: an implementation of Python's 2to3 for C code

Sat, 21 Nov 2009 00:54:51 +0000

I'm hoping that we'll package python 3 versions of as many modules as possible in Fedora 13, so the easier it is to port them, the better.

To that end, I've written a tool to help people port their C python extensions from Python 2 to Python 3.

It uses the Coccinelle tool to apply a series of "semantic patches" to .c files. I also had to code one of the refactorings in python with regular expressions (due to the need to manipulate preprocessor macros containing commas).

Sample session, running on a tarball of dbus-python:

[david@brick 2to3]$ ./2to3c --help
Usage: 2to3c [options] filenames...

Options:
  -h, --help   show this help message and exit
  -w, --write  Write back modified files
[david@brick 2to3]$ ./2to3c ../../python3/packaging/modules/by-hand/dbus-python/devel/dbus-python-0.83.0/_dbus_bindings/*.c > dbus-python.patch 

[david@brick 2to3]$ diffstat dbus-python.patch
 abstract.c       |   28 ++----
 bus.c            |    4 
 bytes.c          |   16 +--
 conn.c           |    7 -
 containers.c     |   21 ++--
 float.c          |    6 -
 generic.c        |    4 
 int.c            |   31 ++-----
 libdbusconn.c    |    5 -
 mainloop.c       |    3 
 message-append.c |    4 
 message.c        |   17 +--
 module.c         |  243 ++++++++++++++++++++++++++++++++++++++++++++-----------
 pending-call.c   |    3 
 server.c         |    7 -
 signature.c      |    6 -
 string.c         |    9 --
 17 files changed, 267 insertions(+), 147 deletions(-)

[david@brick 2to3]$ head -n 30 dbus-python.patch
--- ../../python3/packaging/modules/by-hand/dbus-python/devel/dbus-python-0.83.0/_dbus_bindings/abstract.c.orig 
+++ ../../python3/packaging/modules/by-hand/dbus-python/devel/dbus-python-0.83.0/_dbus_bindings/abstract.c 
@@ -54,7 +54,7 @@
 
     if (!vl_obj)
         return 0;
-    return PyInt_AsLong(vl_obj);
+    return PyLong_AsLong(vl_obj);
 }
 
 dbus_bool_t
@@ -76,7 +76,7 @@
         }
     }
     else {
-        PyObject *vl_obj = PyInt_FromLong(variant_level);
+        PyObject *vl_obj = PyLong_FromLong(variant_level);
         if (!vl_obj) {
             Py_DECREF(key);
             return FALSE;
@@ -127,7 +127,7 @@
     Py_DECREF(key);
 
     if (!value)
-        return PyInt_FromLong(0);
+        return PyLong_FromLong(0);
     Py_INCREF(value);
     return value;
 }

You can see the full patch it generated here: http://dmalcolm.fedorapeople.org/dbus-python.patch

It hasn't done all of the work, there are some places involving the preprocessor where it didn't quite generate correct code, and there are some remaining issues - for example, a human is going to have to decide whether the strings are bytes or unicode.

However, I think this ought to save a lot of time: it takes care of a lot of the tedious parts of such patches.

The public git repo can be seen here:
http://fedorapeople.org/gitweb?p=dmalcolm/public_git/2to3c.git;a=tree

You should be able to download it by cloning it thus:

git clone git://fedorapeople.org/home/fedora/dmalcolm/public_git/2to3c.git

Patches most welcome! (send them to dmalcolm@redhat.com) I intend to license this under LGPLv2.1, but am happy to relicense as the upstream Python community see fit.

John Poelstra: Fedora Target Audience & Release Criteria

Fri, 20 Nov 2009 23:47:16 +0000

As the Fedora Board and larger community has discussed what we want our releases to be and who they are for–Target Audience–I’ve wondered more and more if a reworking of our Release Criteria could help make parts of our decision process clearer and easier to follow. By clearly defining our Target Audience we should be able to write more specific and accurate release criteria. The recent PackageKit controversy highlights this importance. The settings for this package made certain assumptions about a particular target audience and user of Fedora. To my knowledge this target audience isn’t documented anywhere. It makes me wonder how many other parts of our distribution make different or contradictory assumptions about our target audience–resulting in a distribution that is not as coherent and consistent as it could be.

A clear definition of our target audience might also reduce the emphasis we place on developing and testing certain areas, freeing up time to make other things better.

How do you know when testing is done? How do you know when the product is ready to release? Does the decision to release seem similar to deals done in the dark, smoke-filled rooms, or as if there are rules of the game that you don’t know? Does the release decision sometimes seem completely arbitrary? If you’re finding it difficult to make rational decisions about when to release the software, developing and using release criteria can help–Johanna Rothman

I’ve been more or less actively involved in Fedora since Fedora 7. Even though I’ve just completed my fifth release, am actively involved in creating the schedules, and lead the readiness meetings before each public test and final release, this paragraph still resonates with me. This has long been one of my frustrations of trying to understand and participate in Fedora development process. Things have definitely gotten better over the past few releases. We can still do a better job without adding layers of bureaucracy which some people fear.

To move this process forward I took a first shot at an enhanced release criteria framework for Fedora 13. Ultimately I believe we need a stronger framework to be more successful, but I’m not saying the framework I’ve proposed is the one we have to use. A lot of the information included has been in existence for a long time at the QA Release Criteria page. From it I created three separate pages–one for each public release: Alpha, Beta, and Final as well as an introductory page. I also added a few extra proposed bullets. I copied and pasted most of them from Release Criteria and adapted the ‘’shoulds” and ”musts” as specified–where ”must” was required for all releases and ‘’should” was only required for the final release.

I think a separate page for each release is helpful because in reality each release has a separate target audience. The audience and goals for the Alpha release are much different than the audience and goals for the Final release. Certainly there will be overlap in these audiences, but we sell ourselves short if we assume the audience and goals for all three releases are the same. My hunch is that some of these requirements are dated and wrong which makes reviewing everything for Fedora 13 a good thing. In light of the security discussion around PackgeKit we may also want to add a security aspect to our release criteria.

Another benefit of a clear list of release requirements is that the “Go/No-Go” meetings become more objective. There is less of a need to subjectively take everyone’s pulse and ask people how they are feeling. Instead we review the list of release requirements, which also encompasses blocker bugs. If the requirements are met we ship. If they are not met, we add a week the schedule and try again. The definition of what makes a bug a release blocker becomes clearer as well. In addition I’ve started a new blocker bug FAQ.

Check out the wiki pages and join in the discussion on fedora-test-list where I’ve started a thread on the same topic. My hope is that we can refine and discuss these pages over the next two weeks and then meet at FUDCon in Toronto to discuss and put a framework in place for Fedora 13.

Posted in Bug Triage, Fedora

Fujisan: F12: Yum new feature: history

Fri, 20 Nov 2009 22:55:00 +0000

With Fedora 12 (which was released a few days ago), a new version of yum was released too (3.2.25). One of the new features of yum I always dreamed about was the possibility to undo was I installed or removed. This is done now with the 'history' command of yum eventually associated with one of the following options 'info|list|summary|redo|undo|new'.

Here are a few examples:

The following lists all actions performed with yum:

# yum history
Loaded plugins: downloadonly, fastestmirror, keys, presto, refresh-packagekit
ID | Login user | Date and time | Action(s) | Altered
-------------------------------------------------------------------------------
   28 | System <unset>   | 2009-11-20 22:55 | Install | 12</unset>
   27 | John ... <beauduin>  | 2009-11-20 22:51 | Erase | 12</beauduin>
   26 | John ... <beauduin>  | 2009-11-20 22:37 | Install | 12</beauduin>
   25 | System <unset>   | 2009-11-20 21:26 | Update | 27</unset>
   24 | System <unset>   | 2009-11-20 08:12 | Install | 1</unset>
   23 | System <unset>   | 2009-11-18 23:48 | Install | 11</unset>
   22 | System <unset>   | 2009-11-18 23:09 | Install | 27</unset>
   21 | System <unset>   | 2009-11-18 22:41 | Install | 1</unset>
   20 | System <unset>   | 2009-11-18 22:39 | Install | 2</unset>
   19 | System <unset>   | 2009-11-18 22:36 | Install | 11</unset>
   18 | John  ... <beauduin>  | 2009-11-18 22:31 | Install | 3</beauduin>
   17 | John  ... <beauduin>  | 2009-11-18 22:30 | Install | 7</beauduin>
   16 | John  ... <beauduin>  | 2009-11-18 22:26 | Install | 2</beauduin>
   15 | John  ... <beauduin>  | 2009-11-18 22:24 | Install | 3</beauduin>
   14 | John  ... <beauduin>  | 2009-11-18 22:22 | Install | 10</beauduin>
   13 | John  ... <beauduin>  | 2009-11-18 22:18 | Install | 10</beauduin>
   12 | John  ... <beauduin>  | 2009-11-18 22:15 | Install | 14</beauduin>
   11 | John  ... <beauduin>  | 2009-11-18 22:13 | Install | 1</beauduin>
   10 | John  ... <beauduin>  | 2009-11-18 22:13 | Install | 2</beauduin>
   9 | System <unset>   | 2009-11-18 22:10 | Update | 16</unset>

To list packages of a transaction, use option info followed by transaction ID:
# yum history info 28
Loaded plugins: downloadonly, fastestmirror, keys, presto, refresh-packagekit
Transaction ID : 28
Begin time : Fri Nov 20 22:55:05 2009
Begin rpmdb : 1688:e57164ff4d8c1577daaa7e4711a6bcd20014fdfc
End time : 22:56:02 2009 (57 seconds)
End rpmdb : 1700:bc600702696126eaee80165df7933e0c02b69aa5
User : System <unset></unset>
Return-Code : Success
Transaction performed with:
   Installed rpm-4.7.1-6.fc12.i686
   Installed yum-3.2.25-1.fc12.noarch
   Installed yum-metadata-parser-1.1.2-14.fc12.i686
   Installed yum-plugin-fastestmirror-1.1.24-2.fc12.noarch
Packages Altered:
   Dep-Install aspell-12:0.60.6-7.fc12.i686
   Install bilbo-1.0-1.fc12.i686
   Install blogtk-1.1-13.fc12.noarch
   Dep-Install clucene-core-0.9.21-4.fc12.i686
   Dep-Install kde-filesystem-4-30.fc12.noarch
   Dep-Install kde-settings-4.3-12.noarch
   Dep-Install kdelibs-6:4.3.2-4.fc12.i686
   Dep-Install kdelibs-common-6:4.3.2-4.fc12.i686
   Dep-Install kdepimlibs-4.3.2-1.fc12.i686
   Dep-Install oxygen-icon-theme-4.3.2-1.fc12.noarch
   Dep-Install soprano-2.3.1-1.fc12.i686
   Dep-Install strigi-libs-0.7.0-1.fc12.i686

To undo a transaction, use option 'undo' with the transaction ID:
# yum history undo 28
Loaded plugins: downloadonly, fastestmirror, keys, presto, refresh-packagekit
Loading mirror speeds from cached hostfile
* fedora: ftp.nluug.nl
* rpmfusion-free: rpmfusion.famillecollet.com
* rpmfusion-free-updates: rpmfusion.famillecollet.com
* rpmfusion-nonfree: rpmfusion.famillecollet.com
* rpmfusion-nonfree-updates: rpmfusion.famillecollet.com
* updates: ftp.nluug.nl
Undoing transaction 28, from Fri Nov 20 22:55:05 2009
   Dep-Install aspell-12:0.60.6-7.fc12.i686
   Install bilbo-1.0-1.fc12.i686
   Install blogtk-1.1-13.fc12.noarch
   Dep-Install clucene-core-0.9.21-4.fc12.i686
   Dep-Install kde-filesystem-4-30.fc12.noarch
   Dep-Install kde-settings-4.3-12.noarch
   Dep-Install kdelibs-6:4.3.2-4.fc12.i686
   Dep-Install kdelibs-common-6:4.3.2-4.fc12.i686
   Dep-Install kdepimlibs-4.3.2-1.fc12.i686
   Dep-Install oxygen-icon-theme-4.3.2-1.fc12.noarch
   Dep-Install soprano-2.3.1-1.fc12.i686
   Dep-Install strigi-libs-0.7.0-1.fc12.i686

[...]

Remove 12 Package(s)

Reinstall 0 Package(s)

Downgrade 0 Package(s)

Is this ok [y/N]: y

[...]

Undoing transaction 28 creates a transaction 29. If you want to reinstall what was installed in transaction 28, do the following:

# yum history redo 28

Loaded plugins: downloadonly, fastestmirror, keys, presto, refresh-packagekit

Loading mirror speeds from cached hostfile

* fedora: ftp.nluug.nl

* rpmfusion-free: rpmfusion.famillecollet.com

* rpmfusion-free-updates: rpmfusion.famillecollet.com

* rpmfusion-nonfree: rpmfusion.famillecollet.com

* rpmfusion-nonfree-updates: rpmfusion.famillecollet.com

* updates: ftp.nluug.nl

Repeating transaction 28, from Fri Nov 20 22:55:05 2009

Dep-Install aspell-12:0.60.6-7.fc12.i686

Install bilbo-1.0-1.fc12.i686

Install blogtk-1.1-13.fc12.noarch

Dep-Install clucene-core-0.9.21-4.fc12.i686

Dep-Install kde-filesystem-4-30.fc12.noarch

Dep-Install kde-settings-4.3-12.noarch

Dep-Install kdelibs-6:4.3.2-4.fc12.i686

Dep-Install kdelibs-common-6:4.3.2-4.fc12.i686

Dep-Install kdepimlibs-4.3.2-1.fc12.i686

Dep-Install oxygen-icon-theme-4.3.2-1.fc12.noarch

Dep-Install soprano-2.3.1-1.fc12.i686

Dep-Install strigi-libs-0.7.0-1.fc12.i686

[...]

Install 12 Package(s)

Upgrade 0 Package(s)

Total download size: 35 M

Is this ok [y/N]: y

[...]

Option 'summary' associated with a package name gives the list of transaction where that package is involved.

# yum history summary blogtk

Loaded plugins: downloadonly, fastestmirror, keys, presto, refresh-packagekit

---------------------------------------------------------------------

John Smith <smith> | Last day | E, I | 24</smith>

System <unset> | Last day | Install | 12</unset>

And option 'list'

# yum history list blogtk

Loaded plugins: downloadonly, fastestmirror, keys, presto, refresh-packagekit

ID | Login user | Date and time | Action(s) | Altered

---------------------------------------------------------------------------

30 | John ... <smith> | 2009-11-20 23:41 | Install | 12</smith>

29 | John ... <smith> | 2009-11-20 23:30 | Erase | 12</smith>

28 | System <unset> | 2009-11-20 22:55 | Install | 12</unset>

And option 'info' associated with package name gives a full information of transactions where it was involved.

# yum history info blogtk

Loaded plugins: downloadonly, fastestmirror, keys, presto, refresh-packagekit

Transaction ID : 29

Begin time : Fri Nov 20 23:30:34 2009

Begin rpmdb : 1700:bc600702696126eaee80165df7933e0c02b69aa5

End time : 23:30:56 2009 (22 seconds)

End rpmdb : 1688:e57164ff4d8c1577daaa7e4711a6bcd20014fdfc

User : John Smith <smith></smith>

Return-Code : Success

Transaction performed with:

Installed rpm-4.7.1-6.fc12.i686

Installed yum-3.2.25-1.fc12.noarch

Installed yum-metadata-parser-1.1.2-14.fc12.i686

Installed yum-plugin-fastestmirror-1.1.24-2.fc12.noarch

Packages Altered:

Erase aspell-12:0.60.6-7.fc12.i686

Erase bilbo-1.0-1.fc12.i686

Erase blogtk-1.1-13.fc12.noarch

Erase clucene-core-0.9.21-4.fc12.i686

Erase kde-filesystem-4-30.fc12.noarch

Erase kde-settings-4.3-12.noarch

Erase kdelibs-6:4.3.2-4.fc12.i686

Erase kdelibs-common-6:4.3.2-4.fc12.i686

Erase kdepimlibs-4.3.2-1.fc12.i686

Erase oxygen-icon-theme-4.3.2-1.fc12.noarch

Erase soprano-2.3.1-1.fc12.i686

Erase strigi-libs-0.7.0-1.fc12.i686

-------------------------------------------------------------------------------

Transaction ID : 28

Begin time : Fri Nov 20 22:55:05 2009

Begin rpmdb : 1688:e57164ff4d8c1577daaa7e4711a6bcd20014fdfc

End time : 22:56:02 2009 (57 seconds)

End rpmdb : 1700:bc600702696126eaee80165df7933e0c02b69aa5

User : System <unset></unset>

Return-Code : Success

Transaction performed with:

Installed rpm-4.7.1-6.fc12.i686

Installed yum-3.2.25-1.fc12.noarch

Installed yum-metadata-parser-1.1.2-14.fc12.i686

Installed yum-plugin-fastestmirror-1.1.24-2.fc12.noarch

Packages Altered:

Dep-Install aspell-12:0.60.6-7.fc12.i686

Install bilbo-1.0-1.fc12.i686

Install blogtk-1.1-13.fc12.noarch

Dep-Install clucene-core-0.9.21-4.fc12.i686

Dep-Install kde-filesystem-4-30.fc12.noarch

Dep-Install kde-settings-4.3-12.noarch

Dep-Install kdelibs-6:4.3.2-4.fc12.i686

Dep-Install kdelibs-common-6:4.3.2-4.fc12.i686

Dep-Install kdepimlibs-4.3.2-1.fc12.i686

Dep-Install oxygen-icon-theme-4.3.2-1.fc12.noarch

Dep-Install soprano-2.3.1-1.fc12.i686

Dep-Install strigi-libs-0.7.0-1.fc12.i686

Steven Parrish: FUDCon 2009 is almost here. Are you ready?

Fri, 20 Nov 2009 20:27:59 +0000

Its just over 2 weeks until the start of FUDCon 2009 in the lovely city of Toronto. Here are a few bits of information to help make this a great event for all.

If you are coming from the U.S. and are flying in/out of Toronto you must have a valid passport to re-enter the U.S. For those driving across the border a valid passport card will suffice. You can find information on passports and passport cards at http://travel.state.gov Keep in mind with just over 2 weeks to go and Thanksgiving in there if you don't already have one of these 2 items the only way to get one will be to visit a passport office in person. You can find information of where these are located by visiting the previously mentioned site.

If you are flying DO NOT put your laptops, chargers, cell phones, cameras etc in your checked bags. Airlines assume no liabilty for these items in checked bags, carry them with you onboard. Along those same lines keep in mind bags do have a way of getting delayed, I would recommend carrying at least 1 change of clothes with you onboard just in case.

The average high temperature in December is 32 degrees Fahrenheit, with a low if 18 degrees, so dress warm.

This is shaping up to be a great event and I look forward to seeing you all there.

Steven

Máirín Duffy: Want to learn design skills? Want to help Fedora? Fedora Interaction Design Hackfest, Tuesday 24 Nov

Fri, 20 Nov 2009 20:18:04 +0000

Hopefully my post title has captured your attention. I would like to let you know about a project starting up right now that is a great opportunity for you to:

Learn about how interaction design is done.
Pick up some interaction design and user research skills.
Get involved in an open design project.
Help make Fedora better!

So the Fedora Board has started an initiative to create Fedora user profiles and personas to help inform decisions about Fedora policy and design in the future.

Okay Mo, so first of all, what is a persona?

From Wikipedia:

Personas are fictional characters created to represent the different user types within a targeted demographic that might use a site or product. Personas are useful in considering the goals, desires, and limitations of the users in order to help to guide decisions about a product, such as features, interactions, and visual design. Personas are most often used as part of a user-centered design process for designing software and are also considered a part of interaction design (IxD), have been used in industrial design and more recently for online marketing purposes.

A lot of discussion about personas is available on Cooper’s blog and is a good read for getting up to speed on what they are and how they work.

Okay, uh, so how are personas going to help us make Fedora policy and design decisions?

Well, for example, you may recall the great panda panda-monium from early www.fedoraproject.org redesign mockups, in which about half of folks giving feedback loved the panda (“Please kill to keep that damn Panda, mairin. The thing is too cute and seems to look like a great little mascot.”), and the other half felt the panda was an insult to Fedora users (“In general i like the layouts…. for 6 year old kids. If this is the best you can come up with you might as well base it on this: http://ostiaunlobby.files.wordpress.com/2008/07/teletubbies-group2.jpg”)

Of course, everyone is entitled to their own opinion of the pandas. Those opinons may or may not have any bearing on how our target users might receive them, though. If we have a set of Fedora personas defined, we can talk about how each of the personas, designed to be representative of our target audience would feel about pandas. Discussing whether or not the Fedora panda is a good choice for our *target audience* or not will help us make decisions based on the target audience we’ve agreed upon for Fedora rather than base it on knee-jerk / personal / anecdotal reactions that merely represent the personal opinons of the folks who happened to be around at the time to give their feedback.

There’s more discussion of potential benefits of personas to Fedora in a post I made yesterday to the ‘User Profiles’ thread on fedora-advisory-board list, so please check it out for more info and please feel free to dive into the discussion with any questions / commentary / feedback you have.

Well Mo, this sounds good. But where do we get personas from?

We’ll build them. Well, I think there’s a lot of different methods to going about constructing personas, but to be good they need to be backed by user research data. User research data can take many forms.

The approach I’d like to propose for Fedora persona development is based on the user research process advocated for in Observing the User Experience: A Practitioner’s Guide to User Research by Mike Kuniavsky. A high-level / action-oriented summary of the approach is as follows:

~~Define the product and product goals.~~ Done.
~~Decide on an audience to target with the product that will help meet the product goals.~~ Done.
Conduct interviews of product stakeholders in order to determine high-level research questions to consider exploring with members of the target audience. Proposal for doing this.
Draw up a list of specific research questions to answer to start conducting user research on the intended target audience. These are specific rather than high-level questions. For example:
- “Does the target audience care about software freedom or not?” could be a Fedora Board stakeholder high-level research question.
- Specific questions that could be explored during research, “Does that target audience know what free software is?” “Does the target audience already use free software? If so, which software?”
Prioritize the specific research questions, pick a cut-off point for how many to explore, and determine research methods for each.
Draw up a research schedule and assign specific research tasks to volunteers.
Do the research! And check in with volunteers to make sure they’ve not run into any issues and help them resolve them.
Hold a data analysis session. Cluster the data from the research into 3-8 groupings from which to build the personas on.
Brainstorm and document the personas!

So…. How can I help?

SO GLAD YOU ASKED!!!! I am blocking out Tuesday, November 24th to be an interaction design hackfest. I want to run it from 3 pm – 6 pm EDT (8 PM – 11 PM UTC) on #fedora-design on irc.freenode.net. I’d like us to start working on work item #3, conducting interviews of product stakeholders, in order to get moving on the persona-building process. Depending on how far we get we may be able to dip into #4 and #5.

What concrete actions will helping involve?

Interviewing Fedora stakeholders via email or IRC in order to answer the stakeholder interview questions.
Documenting the Fedora stakeholder interviews by organizing the interview results on a Fedora wiki page.
Reviewing the interview answers and brainstorming potential research questions.
Per research question, brainstorming ways we can gather data to help answer the question. (Could we answer that question by running a questionnaire on Planet Fedora? Could we answer it by running some usability tests at FUDcon Toronto next month? Could we answer it by looking at fedoraproject.org website logs?)

You do not have to be an artist to help with design! So show up next Tuesday and find out how you can help.

Date: Tuesday 24 November 2009
Time: 3-6 PM EDT; 8-11 PM UTC
Place: #fedora-design on irc.freenode.net
Host: mizmo (me!)
Agenda: Fedora User Research Plan

p.s. for the panda-haters, how about this mascot:

Posted in Uncategorized

Adam Williamson: OpenID (and others) login support

Fri, 20 Nov 2009 20:10:08 +0000

So, I’ve had many annoying whines^H^H^H^H^H^H^H^H^H^H welcome requests from readers in the past for OpenID authentication for posting comments. I didn’t implement this for a long time. I told people it was because I was worried about spam but really it’s because I’m freaking lazy.

I tried to enable this a while back with the standard Wordpress OpenID plugin, but it didn’t seem to work (as many of you have noticed). I left it in this broken state for months, again because I am freaking lazy.

Today, because I’ll do almost anything to avoid writing an FWN beat, I actually got this implemented in a way that works, using a different plugin – this one. It uses an external authentication intermediary called RPX. This is slightly worrying, but I did look around a bit and read the license terms carefully and they don’t seem to be evil. Please do let me know if you know anything to the contrary.

The good bit is that it works – I tested – and it allows login with Yahoo, AOL and Google accounts as well as OpenID. So that should make it easier for people to comment in future. YOU’RE WELCOME! You can also still login with your existing account on my blog, if you like – there’s a little link down the bottom of the RPX login screen for that.

I reserve the right to disable this again if it causes me to get spam comments.

Ankur Sinha - franciscod: rtorrent <3 <3 <3

Fri, 20 Nov 2009 19:54:14 +0000

So, I’m basically a terminal user. If I could do everything from the terminal I wouldn’t bother with a DE. Anyway, out of the command line clients, rtorrent’s one I love!! I just read through the complete man page and learnt all the awesome options it has.

Here’s my .rtorrent.rc file: Read the man page to understand what I’ve done

directory = ~/Downloads/torrents/

session = ~/Downloads/rtorrent_sessions/

upload_rate = 20

download_rate = 40

peer_exchange = yes

dht = auto

throttle_up = low,10

throttle_down = low,10

throttle_up = med,20

throttle_down = med,20

Probably a post on irssi next

Jeffrey C. Ollie: The Asterisk SLN16 Codec

Fri, 20 Nov 2009 19:16:07 +0000

Google failed me, so I figured that I'd memorialize it here... Here's how to convert to/from Asterisk's SLN16 format using GStreamer:

From SLN16:

gst-launch filesrc location=<filename>.sln16 ! audio/x-raw-int,signed=true,rate=16000,channels=1,width=16,depth=16,endianness=1234 ! audioconvert ! vorbisenc ! oggmux ! filesink location=<filename>.ogg

To SLN16:

gst-launch filesrc location=<filename>.ogg ! decodebin ! audioconvert ! audiorate ! audio/x-raw-int,signed=true,rate=16000,channels=1,width=16,depth=16,endianness=1234 ! filesink location=<filename>.sln16

Remi Collet: PHP 5.3.1 Released!

Fri, 20 Nov 2009 19:12:00 +0000

RPM of final release of php 5.3.1 are available for Fedora and for Enterprise Linux (RHEL/CentOS) in remi repository.

Read the PHP 5.3.1 Released!

Use YUM to install : yum --enablerepo=remi update php-\* Notice : now, all extensions are provided for php-cli and php (module for apache in prefork mode) and php-zts (module for apache in worker mode). Read the entry PHP 5.3, MPM worker, zts and mysqlnd (yes I know, pecl extensions are not yet available). For all questions or help, please use... Lire PHP 5.3.1 Released!

John (J5) Palmieri: I would just like to say PiTiVi rocks

Fri, 20 Nov 2009 17:10:40 +0000

Having followed its development for a long time now and used other video editing software I can say that PiTiVi is an awesome app that is only going to get better. Sure it isn’t perfect yet but that is software development for you. It takes time to get all the features in and make them solid.

One of the great parts of Open Source Software is you get to see it develop and grow. It is also one of the biggest misunderstood aspects of such software. In a world where people are gripped by the next best thing – a collective psychosis of product ADD – where patience is no longer a virtue but an outdated notion of an age long gone, evolution is about as exciting as watching paint dry. Just a reminder that even products that seem to just appear overnight, in reality had long periods of closed development to receive polish (and even then they aren’t always great but for some reason people tend to forgive shortcomings in something they bought as opposed to something they got for free).

Knowing the drive behind the developers working on PiTiVi I am confident that in time PiTiVi will become one of the prime examples of FOSS development. For now it is useful enough for some my basic editing needs and every time I try a new version it just gets that much more useful. Keep up the hard work!!!

[read this post in: ar de es fr it ja ko pt ru zh-CN ]

Steven Pritchard: Why developers suck as admins

Fri, 20 Nov 2009 17:08:39 +0000

So Fedora 12 allows regular users to install packages as long as a) the user is logged in on the console, and b) they are signed and from a trusted repository.

I think it's great that we can enable this functionality, and I'd even argue that it should be on by default on the Live spins (and installs from the Live spins), but in the general case this is a horrible idea.

I've seen a few arguments why this doesn't matter. For example, anyone with local console access already owns the box, right? Well, console access != physical access. Think, well, anything in a server room (systems in locked cabinets attached to a KVM, or virtual machines). While this gives more ammo to us old-timers for not putting X on our servers (I'm looking at you, skvidal), the reality is that it's not realistic to expect all servers to run without a GUI.

I don't want to re-hash the whole (long) thread linked to above, but I think it is important to point out some of the solid reasons why this change is a bad idea.

The installation of one package shouldn't change the behavior of the system. (This one package changes the behavior of the system, plus allows for other packages to be installed that could do the same.) If you take into account that unintended dependencies tend to pull in random stuff during upgrades, this becomes especially important.
Can we really guarantee that there are no signed packages available that are exploitable, all the time?
This is a major change in behavior from Fedora 11 that did not go through the Feature Process, unless I'm missing something.
Possibly even worse, if this "feature" makes it into RHEL 6, you run the risk of a lot of semi- and non-technical sysadmins having yet another security decision made for them, probably without their knowledge. (How many are aware of ctrl-alt-del, console users being able to shutdown/reboot, grub allowing kernel options ("single", for example) unless you set a password, etc.? Of course I've never understood the logic of all of that being open, but magic sysrq being off by default.)
At the very least, this is a DoS attack vector, although more likely due to somebody screwing up and installing a bunch of packages rather than somebody intentionally trying to fill /, /usr, or /var.

Oh, and about the title... Developers of software get stuck into a mindset of "make my software work, no matter what", and, on a related note, tend to have tunnel vision about the use cases for their software. One of the things I love about Fedora is that we have a lot of sysadmins who happen to be coders, so we tend to find a good balance between "usability" (AKA letting the developers go nuts) and maintenance/security. This one slipped by us, but I hope the decision will be made to push an update with a more sane default.

Nate Straz: qarsh 1.25 released

Fri, 20 Nov 2009 17:07:32 +0000

Qarsh is a remote shell for testing environments.

qarsh-1.25.tar.bz2

This release includes a few new features and a few bug fixes.

Handle growing files better in qacp. You can now copy /var/log/messages without getting an error.
Add a quiet option to btimec.
Only look up the local user when the remote user is not specified.
Add an SE Linux policy for qarsh. This work was done by Jaroslav Kortus and allows qarsh work with SE Linux enabled. It allows us to get into the right context when we start daemons remotely.

Greg DeKoenigsberg: The difference between transparency and communication

Fri, 20 Nov 2009 17:04:21 +0000

There's an important lesson to be learned from the whole PackageKit episode.

That lesson: there is an important difference between being transparent and being communicative. Transparency is good, but sometimes it is not enough. Some issues must be discussed proactively. Sometimes, one must go and solicit feedback aggressively.

In reading through the bugzilla comments about this issue, the most insightful comment I came across pointed to a mailing list thread for PackageKit. The only two participants in that thread were Richard Hughes and David Zeuthen, the two Red Hat engineers who were most responsible for the changes to PackageKit's default behavior.

Were they making these decisions behind closed doors? Demonstrably not. Some people seem to believe that davidz and hughsie colluded to "sneak" a change in. Examination of this thread reveals that:

1. They certainly were not in collusion, since the discussion occurred on a public mailing list.

2. They certainly were not pushing a unified agenda, since the conversation looks exactly like any important technical conversation should, with appropriate give and take.

3. The conversation was limited to two people, which was not nearly enough input to make a decision of this magnitude.

It's easy in retrospect to see how all this happened. I've been in this position, too: you discuss a change very publicly, you assume that everyone who cares about the topic is paying attention, you make a decision, and then when the change hits, people go nuts in a very public way. It sucks. But it's also a good opportunity for reflection.

Some changes are really important -- more important than they may seem when you're down in them -- and it's vitally important to solicit feedback actively for those changes. It's an excellent demonstration of the importance of the Fedora feature process -- which exists precisely to mitigate risks like this. Big changes should never, ever be a surprise.

Well-meaning people make mistakes. Especially people who want nothing more than just to Get Things Done. That's one of the strengths of our model: we make mistakes in a way that allows us to recover from them, and if we're smart, to learn from them. I think we're seeing a lot of learning now. That's a good thing.

Matthew Garrett: Why SHMConfig is off by default

Fri, 20 Nov 2009 16:56:40 +0000

Bastien mentioned the Chromium OS xorg.conf file, which includes an irritating wart - namely, Option "SHMConfig" "on". This tells the Synaptics touchpad driver to export its configuration data to a shared memory region which is accessible to any user on the system. The reason for this is that in the past, there was no good way for configuration information to be passed to input drivers through the X server at runtime. This got fixed with the advent of X input properties, and synaptics can now be configured sensibly over the X protocol.

But why was it off by default? Because, as I said, the configuration data is exported to a shared memory region which is accessible to any user on the system. And while it contains a bunch of information that's not terribly interesting (an attacker being able to disable my touchpad or turn on two finger emulation may be a DoS of sorts, but...), it also contains some values that are used to scale the input coordinates. Which means that anyone with access to the SHM region can effectively take control of your mouse. The current position is exported too, so they can also track all of your mouse input.

Now, this isn't stunningly bad. The attacker can only do this while you're touching the pad. You'll see everything that happens as a result. There's no way to fake keyboard input. They need to be running code as another user on the system - if they're running as the logged in user then they can already do all of this. And for a device as single-user as Google seem to be looking at, it's obviously not a concern at all.

But there's still plenty of places on the web suggesting that you enable SHMConfig, and various distributions that ship with it turned on (Ubuntu on the Dell mini used to, but got turned off after I contacted them about it). It's absolutely fine to do this as long as you're aware of the security implications of it, but otherwise please use X input properties instead.

Tiansworld: Fedora 12硬盘安装记录

Fri, 20 Nov 2009 15:39:04 +0000

Fedora 12发布有几天了，增加的的新功能还有一系列的改进非常的有吸引力。由于最近没有充分的时间折腾，所以还没有进行安装。

不过今天还是在虚拟机上安装了这个新系统。其实也是为了先熟悉一下，为过几天真正安装做些准备。

首先说下安装条件吧：

1. VirtualBox虚拟机，8G虚拟磁盘已安装Fedora 12 RC4；

2. 将Fedora 12-i386-DVD.iso复制到这个磁盘上；

3. 用iso镜像引导，执行硬盘安装，把Fedora 12安装到另一个虚拟磁盘；

下面讲过程：

1. 把校验无误的ISO镜像复制到某个分区下，或某个分区的目录下；

2. 提取ISO中的isolinux目录，并把它放到ISO所在的目录；

3. 重新启动计算机，光盘引导，在出现Fedora安装屏幕后，按Tab键编辑安装选项；在最后加上 linux askmethod；

4. 按回车键进入安装屏幕，选择安装语言和键盘后会提示选择安装方式：

4.1 本地光盘安装；(Local CD/DVD)

4.2 硬盘安装； (Hard Disk)

4.3 NFS安装； (NFS)

4.4 URL安装； (URL)

5. 选择硬盘安装

6. 在新的屏幕中会提示安装镜像所在分区，以及需要输入相应目录路径；

我把ISO放在了/home/tt/下，我的/home位于/dev/sda2；

7. 填好后确定，之后安装程序将自动寻找安装install.img文件，这个文件位于isolinux目录中。如果一切无误，那么安装过程就会继续向前了。

下面说说注意事项吧：

1.ISO存放分区格式：分区格式可以为VFAT，ext2-ext4；但是不可以为LVM卷（Fedora安装自动分区方案就会有LVM卷）；

2. 经过测试，ISO镜像文件中只需要提取出isolinux目录即可；

3. 提示安装位置时，一定要选择正确。由于我是在第二个虚拟磁盘安装，所以选择把Fedora安装到sdb。这个要根据实际情况自己确定。

参考文献：http://docs.fedoraproject.org/install-guide/f12/en-US/html/s1-begininstall-hd-x86.html

(本文仍待完善)

Carlos (casep) Sepulveda: yum history

Fri, 20 Nov 2009 14:36:46 +0000

Una de las cosas buenas de usar una distribución es contar con una herramienta de administración para la instalación y actualicación de software. En el caso de Fedora es yum. Como buen administrador de paquetes, yum permite resolver automáticamente las dependencias de lo que quieras instalar, por ejemplo:

yum -y install gnome-commander
Loaded plugins: presto, refresh-packagekit
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package gnome-commander.i686 0:1.3-0.3.git_D20090929T1100_13dev.fc12 set to be updated
--> Processing Dependency: meld for package: gnome-commander- 1.3-0.3.git_D20090929T1100_13dev.fc12.i686
--> Processing Dependency: libexiv2.so.5 for package: gnome-commander- 1.3-0.3.git_D20090929T1100_13dev.fc12.i686
--> Running transaction check
---> Package exiv2-libs.i686 0:0.18.2-2.fc12 set to be updated
---> Package meld.noarch 0:1.3.0-2.fc12 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

========================================
Package Arch Version Repository Size
========================================
Installing:
gnome-commander i686 1.3-0.3.git_D20090929T1100_13dev.fc12 fedora 1.5 M
Installing for dependencies:
exiv2-libs i686 0.18.2-2.fc12 fedora 604 k
meld noarch 1.3.0-2.fc12 fedora 665 k

El problema es que yum no es tan inteligente ;-) a la hora de eliminar los paquetes:

yum -y remove gnome-commander
Loaded plugins: presto, refresh-packagekit
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package gnome-commander.i686 0:1.3-0.3.git_D20090929T1100_13dev.fc12 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

========================================
Package Arch Version Repository Size
========================================
Removing:
gnome-commander i686 1.3-0.3.git_D20090929T1100_13dev.fc12 installed 4.7 M

Claro, elimina el paquete seleccionado, pero no las dependencias que instaló para el mismo!
Lo bueno, es que en Fedora 12 esto ya tiene solución! Para los regalones, les tenemos "history"

history
The history command allows the user to view what has happened in past transactions (assuming the history_record config. option is set). You can use info/list/summary to view what happened, undo/redo to act on that information and new to start a new history file.

The info/list/summary commands take either a transactions id or a package (with wildcards, as in Specifying package names), all three can also be passed no arguments. list can be passed the keyword "all" to list all the transactions. undo/redo just take a transaction id.

Ejemplo de uso, en el caso anterior

# yum history list
Loaded plugins: presto, refresh-packagekit
ID | Login user | Date and time | Action(s) | Altered
-------------------------------------------------------------------------------
21 | Carlos ... <casep> | 2009-11-20 10:44 | Install | 3
.
.
.
</casep>

Identificamos la transacción que nos interesa

# yum history info 21
Loaded plugins: presto, refresh-packagekit
Transaction ID : 21
Begin time : Fri Nov 20 10:44:30 2009
Begin rpmdb : 1189:ba0aa90010d5d9c492556b3ff420f8940f22be12
End time : 10:44:35 2009 (5 seconds)
End rpmdb : 1192:756121f2f471a4e319c533854bab28042df46680
User : Carlos (casep) Sepulveda <casep>
Return-Code : Success
Transaction performed with:
Installed rpm-4.7.1-6.fc12.i686
Installed yum-3.2.25-1.fc12.noarch
Installed yum-metadata-parser-1.1.2-14.fc12.i686
Packages Altered:
Dep-Install exiv2-libs-0.18.2-2.fc12.i686
Install gnome-commander-1.3-0.3.git_D20090929T1100_13dev.fc12.i686
Dep-Install meld-1.3.0-2.fc12.noarch
history info
</casep>

Y para reversar la operación basta con

# yum -y history undo 21
Loaded plugins: presto, refresh-packagekit
Undoing transaction 21, from Fri Nov 20 10:44:30 2009
Dep-Install exiv2-libs-0.18.2-2.fc12.i686
Install gnome-commander-1.3-0.3.git_D20090929T1100_13dev.fc12.i686
Dep-Install meld-1.3.0-2.fc12.noarch
Resolving Dependencies
--> Running transaction check
---> Package exiv2-libs.i686 0:0.18.2-2.fc12 set to be erased
---> Package gnome-commander.i686 0:1.3-0.3.git_D20090929T1100_13dev.fc12 set to be erased
---> Package meld.noarch 0:1.3.0-2.fc12 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

===================================
Package Arch Version Repository Size
===================================
Removing:
exiv2-libs i686 0.18.2-2.fc12 installed 2.4 M
gnome-commander i686 1.3-0.3.git_D20090929T1100_13dev.fc12 installed 4.7 M
meld noarch 1.3.0-2.fc12 installed 2.0 M

Transaction Summary
===================================
Remove 3 Package(s)
Reinstall 0 Package(s)
Downgrade 0 Package(s)

Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
Erasing : meld-1.3.0-2.fc12.noarch 1/3
Erasing : exiv2-libs-0.18.2-2.fc12.i686 2/3
Erasing : gnome-commander-1.3-0.3.git_D20090929T1100_13dev.fc12.i686 3/3

Removed:
exiv2-libs.i686 0:0.18.2-2.fc12 gnome-commander.i686 0:1.3-0.3.git_D20090929T1100_13dev.fc12 meld.noarch 0:1.3.0-2.fc12

Complete!

Listo! ahora nuestro sistema no se llenará de dependencias guachas!

By Casep!

Henrique "LonelySpooky" Junior: Usuários não-root instalando pacotes no Fedora 12

Fri, 20 Nov 2009 14:26:55 +0000

O lançamento do Fedora 12 gerou grande discussão na lista de desenvolvimento devido a uma “feature” do PackageKit que permitia a usuários “não-root” instalarem pacotes (desde que os pacotes fossem...

Um blog sobre tecnologia, informática, ironia e desventuras na vida de um geek

"Rodrigo Padula": Fedora 12 - Lançamento Oficial no Brasil / Fedora 12 - Brazilian Official Release

Fri, 20 Nov 2009 13:11:07 +0000

O lançamento oficial do Fedora 12, codinome constantine, será realizado durante o IV Congresso Catarinente de Software Livre - SOLISC, que será realizado em Florianópolis - SC durante os dias 26 e 27 de Novembro (http://www.solisc.org.br/).

Como atividades de lançamento o Projeto Fedora Brasil estará no evento com várias palestras na grade e com a participação dos membros Rodrigo Padula (Líder do Projeto Fedora na América Latina e Community and Academy Relations da Red Hat) e Wolnei Cândido Tomazelli Junior ( Embaixador Fedora e membro do Projeto de Artwork do Fedora).

Programação Fedora no SOLISC:

Dia 26
- 09:00-10:00 - Sala Laranjeira: Fedora Spins/Remixes: Criando versões customizadas do Fedora ( Wolnei Cândido Tomazelli Junior )
Dia 27
- 09:00-10:00 - Auditório Garapuvu: Lançamento Oficial do Fedora 12: Conheça a fundo detalhes e novidades da versão ( Rodrigo Padula)
- 11:00-12:00 - Sala Laranjeira: Projeto Fedora: Saiba o que é o Projeto e como participar ( Wolnei Cândido Tomazelli Junior )

Confira a programação completa do evento: http://www.solisc.org.br/index.php?option=com_wrapper&view=wrapper&Itemid=27

Contamos com a presença de todos para prestigiar este evento e saber um pouco mais a fundo tudo a respeito da Distribuição Fedora e sobre o Projeto.

Participe!

Fonte: http://www.projetofedora.org/fedora_12_lancamento_oficial_solisc

Diana Martin: Hello Fedora!

Fri, 20 Nov 2009 13:10:23 +0000

Hi!

First, I’d like to introduce myself. My name is Diana and I am an anthropologist currently in the midst of attaining my Masters degree in Applied Anthropology from the University of North Texas. As a part of my studies I will be working with Fedora, and hopefully many of you, to better understand the culture that surrounds open source software development.

As an applied anthropologist I want to stress that I will be doing research FOR and with the Fedora community not ON the Fedora community. My goal is to find ways to make your lives as open source developers better! And, if by some chance it can’t get any better than it already is, find out why it is so great so other open source groups can follow your lead.

My research methods will include participant observation, which means I will be hanging out with you all as you do what you do both in an online and offline context, interviews, and surveys. I will be using this blog as my major means of communication with everyone and as a way to make my research both open and transparent.

When my research concludes I will be providing the community with a report as to the findings of my explorative study so that everyone has access to them and can hopefully find ways to use them to your benefit.

As a side note for all anthropologists aspiring to do research online, I am documenting my entire process and will be providing a side report as my contribution to open anthropology.

For those of you who will be in Toronto for the developer conference in December, I will be there as well and will be providing a topic for discussion so that we can all get to know each other a bit better.

I want to stress that participation in this study is strictly voluntary! If for some reason you do not want to participate, or would like to speak to me in confidence, I will be more than happy to oblige.

You can contact me here by leaving a comment, or by emailing me Diana [@] cyber-anthro.com.

I look forward to working with all of you and to any feedback you may have, even this early in the process!

Projeto Fedora Brasil: Fedora 12 - Lançamento oficial no Brasil será realizado no SOLISC dia 26 e 27 de Novembro em Florianópolis - SC

Fri, 20 Nov 2009 13:04:08 +0000

Edward Karavakis: LHC restart – 2009 LHC beams.

Fri, 20 Nov 2009 12:47:45 +0000

The LHC restarts today aiming for the first beam circulation… to be followed by the very first LHC collision in the next couple of days or so… will keep you updated

"Rodrigo Padula": Famsco Elections - I’m running for reelection

Fri, 20 Nov 2009 12:36:37 +0000

Initially I thought to not run again for FAMSCO Elections, but with some important guys lefting the committee like Francesco Ugolini and several emails received requesting for my nomination, I will try again to be part of the FAMSCO, occupying one of the 7 seats available .

I believe I can contribute a little more with the Ambassadors Program, now focusing not only in LATAM, but the overall project, sharing successful experiences that I applied in Brazil and Latin America, creating a stronger project throughout the world.

Below are the details of my nomination, available at https://fedoraproject.org/wiki/Ambassadors/SteeringCommittee/Election/2009Nominations#Rodrigo_Padula_de_Oliveira_.28RodrigoPadula.29

Candidate statement
- Currently member of FAmSCo , running for re-election.
- I’m a FAMSCO’s member, since the first election, working to improve the ambassadors program and to spread Fedora around the world
Contributor profile
- Gnu/Linux user since 1996.
- Fedora contributor since 2005.
- Founder of the Brazilian Fedora Project
- Founder of the Latin American Fedora Project ( providing infra for all latam communities)
Past plans - Added in the 2008 Famsco Nomination
- [DONE Increase the LATAM community (We were 8 countries with 25 ambassadors, now we are 14 countries with ~130 ambassadors)
- [IN PROGRESS] Work to increase the Packaging group and the Fedora time support (We have ~12 packagers from Latam but we have a lot of work to do)
- [DONE] Contribute with the organization of local Fedora Projects.
- [IN PROGRESS] Strengthen the participation of Latin American contributors in Fedora Project (We are a great team but we can do more!).
- [DONE] Spread Fedora in events, with media distribution, lectures and booths (~48 events in all Latam with ~60.000 attendees ).
- [IN PROGRESS] Be the voice of the community and ambassadors in the FAMSCO / Fedora Project / Red Hat.
- [DONE] Support the local projects with all that they needs ( With the limited resources we did a great job).
- [DONE] Create and organize the III Latin American Conference and the I FUDCON Latin American (Some pictures [[4]])
- [DONE] Increase the free media program (~14.000 Medias produced and distributed)
Future plans
- Keep doing what I’m doing now.
- Help FAMSCO to improve the ambassadors program.
- Recruit new members to keep Fedora as main Free Software technology developer/contributor.
- Share experiences (Try to apply in other countries/regions all great things that we realized in Latam and Brasil specially).
- Increase the FLOSS contribution in Latin America.
- Help to create a link between Fedora and Universities opening doors for RHA/OSU program and POSSE.
- Increase the number of packagers from our community to help with the LTS dream.
- Convert fedora users and ambassadors(potential contributors) in real contributors.

Bastien Nocera: Sticky tape

Fri, 20 Nov 2009 12:03:54 +0000

Google might know how to write a web browser, but writing an OS certainly isn't their forte.

You might have seen Matthew's mention of the acpid hacks, some of the other sources are just as funny to read.

Hard-coded xorg.conf, because they don't want to run HAL.

Patches from Fedora 11

xscreensaver for a screen locker

Nicu Buculei: Digital painting

Fri, 20 Nov 2009 11:15:42 +0000

When Mo was enthusiastic about tablet improvements in Fedora 12, this made me dust-off my own device, but only a few days later when Kaio pointed to the small and awesome MyPaint I got hooked, liking a lot how it feels like real drawing/painting.

And my first drawing with it, my first digital painting ever, is something I think is not entirely bad:

Speaking about graphic applications, I found somewhat funny (and somewhat sad) to see how Ubuntu is again following Fedora's footsteps, this time by removing GIMP, with a similar line of reasoning ("we" wanted to free space on the Desktop Spin for more apps and ended with a 650MB .iso and 50MB is unused space). At least they got Slashdot headlines with this move and somewhat compensated our own negative PackageKit headlines (wait a bit to see the headlines when they will follow with the PackageKit thing too).

PS: thumbs-up for doing at last (post-release) the right thing with PackageKit in F12.

Richard Hughes: The Fedora 12 Installing Saga

Fri, 20 Nov 2009 10:01:34 +0000

And so, long story short, we decided to revert the change for F12.

Part of being an open source maintainer (and also my job at Red Hat) is to ignore trolls, but some of the messages I was getting yesterday were just personal attacks and abuse. That’s not cricket at all.

Kushal Das: Dhunuchi Dance (ধুনুচি নাচ)

Fri, 20 Nov 2009 07:44:39 +0000

The post is brought to you by lekhonee v0.8

Kushal Das: sparcy — command line utility for Spac Systems Limited GPS loggers

Fri, 20 Nov 2009 06:14:12 +0000

Few days back I bought a new GPS data logger from Sparc Systems Limited , GDL 3204. It comes with a nice 3 page manual. The last page explains the data format of the logs.
The device works in a very nice and easy way, it is having 32 channels.

We already had a nice python script to parse the log and create gpx files. But for me , every time “cat”ing the device and then convert the log is a difficult task.

Sparcy , which can get the data from the device and convert them into gpxfor you. If you already have the raw data, you can convert them to gpx too. People from #osm helped me a lot to understand how latitude and longitude calculations are done.
RPMs are available here.

The post is brought to you by lekhonee v0.8

Adam Williamson: Video acceleration repository updates

Fri, 20 Nov 2009 05:46:28 +0000

Yesterday and Tuesday I pushed several updates to my experimental video acceleration repositories. Most obviously, there’s now an F11, an F12 and a Rawhide (F13) repo, all in the logical places. I also updated all components; libva is up to sds7, vdpau-video is up to 0.5.2. mplayer-accelerated is up to 20091106 and mplayer-mt is up to svn rev 29934 (basically, the latest mplayer and ffmpeg-mt checkouts as of yesterday).

Note that Splitted Desktop Systems have made xvba-video – the equivalent to vdpau-video for the ATI proprietary driver, it’s a bridge from ATI’s ‘xvba’ video acceleration system to VAAPI so you can use any VAAPI-compliant player with ATI cards – available. Unfortunately, it’s proprietary. I’m not sure whether I want to package it, due to that. I probably will at some point, but…ick. Anyway, the fact that it’s proprietary makes it very trivial to install, basically you’d just grab the latest tarball for your arch from here and extract the single file it contains to the appropriate place on your system. Then make sure you have libva and mplayer-accelerated installed and try it.

I’ll try and find some time to work on the RPM Fusion mplayer package soon. Basically I’d like to update it to a newer snapshot and enable VDPAU support.

Ankur Sinha - franciscod: Fedora : PackageKit change

Fri, 20 Nov 2009 04:52:47 +0000

Not a lot of people seem aware of this. This is from the announce list. Please help spread the word.

The Fedora 12 release contained changes in the default PackageKit
behavior that allow installation of packages by users in cases where:

* the user is logged in on the local console, and
* is installing packages signed with a previously trusted key, and
* is using a previously configured and trusted repository

After more discussion and thought, though, the package maintainers
have posted to the fedora-devel-list mailing list agreeing to provide
an update to Fedora 12's PackageKit. The update will require local
console users to enter the root password to install new software
packages. Details on the changes are found here:

https://www.redhat.com/archives/fedora-devel-list/2009-November/msg01445.html

--
Paul W. Frields http://paul.frields.org/

Christoph Wickert: Follow-up on the LXDE images

Fri, 20 Nov 2009 02:44:07 +0000

I just want to give a short update on the broken LXDE Spin images: I (think I) fixed the bug, but we need to do some more testing to be really sure. The packages first need to go through bodhi before new images will be composed. Not sure how long it takes, I prefer adding one or two extra days for testing because I really don’t want to disappoint all the people who are interested in LXDE.

Thanks for your patience. I’ll keep you informed.

Michael DeHaan: Theoretical Attack Vector?

Fri, 20 Nov 2009 02:16:33 +0000

WRT This, I think there are potentially greater problems. Fedora has standards of packaging specification review, but not so much review of package content or updates (beyond, perhaps diffs to the specfile, which go to a mailing list in CVS — the tarballs are not subject to close inspection). While it is bad enough that this allows a user access to install a well-intentioned package with an unpatched vulnerability when it is not otherwise installed (requiring first some form of local access, or another exploit or bridge sufficient to talk to dbus?), what is not mentioned is it is fairly easy for a person to masquerade as a good guy, package a popular technology, and replace it with an disguised evil payload six months later. RPM scripts run as root, and are just as dangerous as the software they install.

I don’t know exactly /how/ you fix that attack vector, it is a social one. So if Fedora is thinking about reviewing security policies, also consider we don’t /really/ know everyone, and we can’t know. I would be more worried about that than the PackageKit one. With the PackageKit one, I’d just mostly be really annoyed that someone I gave an account to could fill up my hard drive space and I wouldn’t know exactly what they installed so I could clean up after.

My point is that even though the Package is signed, that doesn’t mean they are (neccessarily) safe. More reason for not allowing extra people to install packages.

I’m only bringing this up because I get tired of fighting off Ubuntu people, and such security features as PackageKit being wide open do not make it easy. With all the attention on SELinux, etc, I see no reason Fedora could not be both usuable and also a security bastion with similar reputations as OpenBSD. In the worst case, perhaps just ask the user what they want in the installer and default to some of the more secure options — or default to the most secure options and provide a setting in a configuration panel somewhere to open it up.

Jon Stanley: Much ado about nothing

Fri, 20 Nov 2009 01:37:18 +0000

So I figured that I'd write about the whole current "non-root users can install stuff" fiasco. Here's my take on it, drawing heavily from my $DAYJOB experience of being a sysadmin of many systems.

First, in order for this to work, as I understand it (I don't have a convenient F12 machine at the moment), you have to be sitting at the console of the machine. As much as I despise Microsoft, they wrote a great paper some time ago, the 10 Immutable Laws of Security. And it's one of these laws that I'll refer to here (and it's sort of obvious):

If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.

Think about that for a minute - once someone has physical access to your machine, game over. This is true no matter if you're running Windows, Linux, z/OS, whatever. For a typical Fedora workstation, all that someone with physical access needs to do is intercept the grub prompt, boot into single user and not be prompted for a password to do so, and proceed to wreak whatever havoc he sees fit on your system.

When analyzed from this perspective, allowing a locally authenticated user to installed signed content from a signed repository isn't all that bad. Furthermore, when you look at Fedora's target audience, I don't see servers or large deployments anywhere in there. That obviously doesn't preclude people from using it in this way, but it's more fit to be a single-user desktop, where the user and administrator are the same person, and that user is physically situated at the console of that machine.

Note that the preceding paragraph is not intended to say that Fedora shouldn't be run on servers or that it has no place there, nor that we shouldn't cater to the needs of that user type. However, when considering the default settings, we should probably go with ones that are conducive to the use case of a single user desktop. If you wish to use Fedora in other ways, that's why we have spins, which can defaults of their own (which for a server spin, would likely not include PackageKit, include more sane (to that use case) PolicyKit defaults, etc.

Also, if you're using Fedora in some sort of large enterprise deployment where centralized control over what gets installed on the end-nodes is desirable, then you should be deploying custom policy in order to restrict this and likely many other aspects of the default desktop configuration (enforcing screen locking, strong passwords, account lockout, and any number of other things).

I did, however, like the idea that was floated on fedora-devel-list about having multiple policies for varying levels of control over the system.

I will concede that this should have been documented better, but with the threads o' doom on this topic, I do believe that there's plenty of documentation and awareness by this point :)

Christos Bacharakis: Η Fosscomm 2010 στη Θεσσαλονίκη

Fri, 20 Nov 2009 00:29:04 +0000

Είναι πλέον γεγονός! Η επόμενη Fosscomm (2010) θα πραγματοποιηθεί στην όμορφη Θεσσαλονίκη! Οι ακριβείς ημερομηνίες διεξαγωγής δεν είναι ακόμα διαθέσιμες καθώς μόλις τώρα ξεκίνησαν οι διαδικασίες οργάνωσής της.

Στόχος μας είναι η εκδήλωση να απευθύνεται τόσο σε απλούς χρήστες και άτομα που δε γνωρίζουν το ελεύθερο και ανοιχτό λογισμικό όσο και σε developers/προγραμματιστές αλλά και επαγγελματίες διαφορετικών ειδικοτήτων.

Καλούμε λοιπόν όλους εσάς που ενδιαφέρεστε να παρουσιάσετε, να στήσετε κάποιο workshop, να μας βοηθήσετε με οποιοδήποτε τρόπο (δεχόμαστε και χορηγίες) ή που απλά θέλετε να μάθετε περισσότερα, να επικοινωνήσετε μαζί μας στο thessaloniki@fosscomm.gr .

Επίσης μην ξεχνάτε και την διεύθυνση http://thessaloniki.fosscomm.gr από όπου θα μπορείτε να ενημερώνεστε για την πρόοδο της οργάνωσης (χρειαζόμαστε καινούργιο banner!).

Το Σάββατο 28 Νοεμβρίου θα υπάρξει μια πρώτη συνάντηση όλων όσων θέλουν να βοηθήσουν στην διοργάνωση. Σας περιμένουμε λοιπόν όλους στις 28/11 στις 15:00 στο stand της Ελληνικής open source κοινότητας στα περίπτερα της Infosystem 2009.
Χάρτης: http://bit.ly/48jESn

Shakthi Kannan: Fedora 12 on HP 6730s laptop

Fri, 20 Nov 2009 00:17:00 +0000

Upgraded to Fedora 12 (Constantine) on a HP 6730s laptop that was running Fedora 11. Used the following:

  # yum clean all
  # yum update
  # preupgrade-cli "Fedora 12 (Constantine)"

I had to pass intel_iommu=off to the kernel command line to boot the kernel. Otherwise, everything worked cleanly!

Dan Williams: Few Surprised at New Evidence of Staging Driver Suckage

Thu, 19 Nov 2009 23:30:39 +0000

Thomas Johnson (High School Janitor)

“Oh yeah, I’ve seen that code. It’s worse than what I clean up in the bathrooms after Prom or Homecoming. The kids get high and drunk and party too hard and puke all over the place. I deal with enough vomit from 7:30 to 6; I wouldn’t touch the staging drivers with a mop twice as long as the one I have at work.”

Just Say No

Thomas just found out that none of the “staging” wifi drivers will work with hidden access points because they don’t set the IW_SCAN_CAPA_ESSID capability bit. Furthermore, the most popular “staging” drivers (for the Ralink hardware used in many netbooks) don’t even have specific SSID scanning capability at all.

Why do you care? Hidden APs don’t broadcast their network ID, which misinformed people think is more secure (hint: it’s not). Before a driver can associate to the network, it needs to discover available APs and capabilities, which requires a probe-request, which exposes the network ID to everyone anyway. But that requires driver support which none of the staging drivers have.

I fixed this issue upstream two years ago by adding IW_SCAN_CAPA_ESSID to Wireless Extensions. Of course the staging WiFi drivers that many distros enable never got fixed because the vendor it came from didn’t bother to work with the community in the first place. And people wonder why they don’t work.

Broadly speaking, staging WiFi drivers come in two flavors: (a) old dried gum from under the cafeteria table (drivers with a future), and (b) fresh vomit from the hung-over kid in your math class (those without a future).

The drivers with a future (winbond, rtl81xx) are or will based on the kernel-standard mac80211 wireless stack, which implements the 802.11 WiFi specification in the kernel. Since they use the standard mac80211 stack, they get all these nice features like probe-scanning and the correct capability bits for free. All you have to do is work on supporting the hardware itself.

The drivers without a future (rt2860, rt2870, rt3070, rt3090, wlan-ng, vt665x) are based on forks of the ancient ieee80211 stack that Intel’s ipw2×00 drivers forked from the hostap driver. Each of these drivers includes their own copy of the core ieee80211 stack forked at different times and with different hacks. When a bug shows up, that means 4x the work, and 4x the chance for the fix to slip through the cracks. Which is why these drivers have no future. They are a maintenance nightmare. Besides, they have crap like this:

pAdapter->StaCfg.bScanReqIsFromWebUI = TRUE;

It just blows my mind why people think staging wifi drivers are a great idea. There’s a reason staging drivers set the TAINT_CRAP flag in your kernel; because that’s what they literally are.

So what’s the right thing to do?

There’s one huge reason why dead-end staging drivers are a bad idea: there aren’t enough developers. So do you spend that effort on maintaining unmaintainable shit code? Or do you spend it on fixing the code that has a future? Most of the time you can’t do both.

If you choose to maintain the staging drivers, then things become worse over time since the staging code is simply less tested and less maintainable. So you continue to drop hacks and fixes onto an ever-growing steaming pile of manure. Nobody cares much about the driver (because it doesn’t use the standard kernel interfaces and thus doesn’t have a future), so your staging driver never benefits from all the great feature work and bug fixing that the mac80211 and wireless developers are doing.

But if you choose to help fix the upstream drivers that do use mac80211 (like rt2×00), and thus have a future, maybe for a few months some users won’t have great wireless. But they didn’t before either. But then 6 months later, all the users get great wireless with features like power saving, background scanning, WiFi Direct, Bluetooth 3, access-point mode, etc. Those things will never be done to the staging drivers, because those drivers are a dead-end maintenance nightmare, because their code is awful, and because they don’t use the standard kernel wireless stack.

I know I’d invest the effort where it helps users the most, even if it means a few more months of subpar driver support while the official upstream drivers get fixed and the staging drivers go untouched. That’s how things actually get better when you can’t fix everything at once.

Luya Tshimbalanga: Comment about bugz#534047

Thu, 19 Nov 2009 23:05:49 +0000

After deeply checking about the fuzz on bug #534047, I think the reaction is exaggerated. The default policy from PolicyKit applies for single user that can install signed package from official repository without root password but unsigned packages need authentification. Grab any unsigned package and test yourself. For multiple user account, setting policy is the key.

Juanjo Martínez: Weird Things on Fedora 12

Thu, 19 Nov 2009 22:49:00 +0000

Not a big deal because both things can be fixed (please notice I don’t mean these are broken features, but restore the behaviour I’m used to and I like).

There are two things I’d like to mention here:

I bet the people behind those changes are doing them with good will, with a neat rationale, and willing to make Gnome/Fedora better. The overreactions from some people are not.
Those are defaults. You don’t need to stick to them, and everybody has an opinion about what looks better or what’s more secure.

I have an opinion too. Just stay calm and let others know what you think, respecting the hard work of other people, even when you’re convinced that they are wrong.

In other news, Fedora 12 it’s a rocking release. The upgrade didn’t work as smooth as I would have expected, but I survived heh.

Update: the authentication stuff will be fixed today, please read PackageKit policy: background and plans.

Notice that I would have liked the idea if any local logged user was any local and trusted logged user. I mean, it’s like using sudo for PackageKit, but without the user entering his password twice.

Gino Alania: Fedora-pe

Thu, 19 Nov 2009 21:44:54 +0000

Ante todo mi coordial saludo a la comunidad.

Queria informar a toda la comunidad que estamos tratanto de reunir a todos los interesados a poder apoyar / participar en un evento Fedora a realizarse por primera vez en #Peru , para lo cual queriamos unirnos en una lista particular solo para coordinaciones locales, a todos los residentes en Peru, ya sea de Lima o fuera de la misma, queriamos organizarlo en una Universidad Peruana por confirmar , por lo que queriamos contar con la mayor participacion de fedorianos activos y/o comprometidos con el proyecto.
Si alguien fuera de esta lista tambien estaria interesado , pasen la voz ..

La dirección para su suscripción es :

http://www.fedora-es.com/mailman/listinfo/peru

Por cierto , si algun LUG quiere contar con una lista particular para su coordinacion , envieme un correo para su creacion respectiva.

slds

Mark J. Wielaard: GPLed JDK 7 M5 + Jigsaw binary packages

Thu, 19 Nov 2009 21:35:37 +0000

After my somewhat cranky post about the JDK 7 M5 binaries being distributed under not very free and social terms. I was really happy to see Mark Reinhold’s announcement of the JDK 7 M5 + Jigsaw binary packages:

These binaries are licensed under the GPL (v2) with the Classpath Exception, plus the Assembly Exception.

Thank you Mark! Thank you Sun! You did make my day.

Fedora Venezuela: 064/365: un paso adelante – a step foward

Thu, 19 Nov 2009 21:11:21 +0000

===== Español =====
Siempre dije que LATAM tenía potencial… Aquí está uno de los logros luego de meses de trabajo. Tenemos casi listo el primer numero de nuestro proyecto Latinoamericano de difusión de fedora para todos “Fedora-LATAM Magazine”. Si… estamos trabajando y tenemos logros!!

Gracias a todos los que han ayudado y… que?! no eres un colaborador de Fedora-LATAM Magazine? enviame un mensaje y empieza a colaborar!

Gimp: Capa adicional con modo solapar y balance de blancos

===== English =====
I always say that LATAM has potential… and here is the goal of months of work. We have almost done our first LatinAmerican project to spread fedora to everyone “Fedora-LATAM magazine”. yes… WE are working and WE have goals

Thanks to everyone help and…. what? aren’t you helping with Fedora-LATAM Magazine? Send me a message and start to colaborate!

Gimp: Layer with overlay mod and white balance

Matthew Garrett: Sigh.

Thu, 19 Nov 2009 20:32:10 +0000

If only eeepc-laptop sent standard keycodes, or something.

Oh, wait.

Writing a Linux distribution is hard. There's a huge range of interconnected dependencies. It takes a long time to learn how everything fits together, and fixing things properly rather than adding device-specific hacks often requires rewriting a lot of code. I'm sure Google will figure it out in time[1], and I'm also sure that the majority of their work is going into their UI rather than the underlying infrastructure. But even so, don't expect that you'll be able install Chromium OS on a random piece of hardware and have it work as well as, say, Fedora in the near future.

[1] Based on that script, I'd say they're about equal to Xandros at the moment

Mel Chua: Reply to Cory

Thu, 19 Nov 2009 20:26:02 +0000

While reading Matt Jadud’s blog via Planet TOS, I came across the blog of Cory. Cory is one of the students working with Matt on Operation: Stick Figure Army. His recent post “how to cope with the design phase?” was about how he (as a blind hacker) goes about a process that most engineers rely on highly visual tools for (UML, sketching on whiteboards, etc). I can’t comment on his blog without a login I’m not sure of how to get, so I’m writing a longer blog entry as a response instead. (For those who don’t already know, I’m a deaf* hacker.)

First of all, I like the way Cory and his professor handled the question on how to assess his understanding of UML diagrams (a visual convention for describing program structure and a required topic in a class Cory is taking). He has to demonstrate understanding of the concepts; it’s just that the input and output methods for that understanding are different.

…even though I may not be drawing diagrams, that doesn’t mean that I’m not responsible for knowing how each diagram is used and how to describe one.

Reading Cory’s description of how he describes UML diagrams in text reminded me of the time in elementary school where my music class was going through the instruments of the orchestra; we were listening to sound clips from different instruments and had to write about each one. Since I can’t hear high frequencies, my reports went something like this: “The tuba sounds like this, the bassoon sounds like that, the piccolo has a fascinating history and an intricate key mechanism that I will now diagram…”

I don’t believe that a fundamental property of the software development cycle is that it is visual. I think we make it that way because most people think it is more convenient…

I agree. And I don’t believe that a fundamental property of high-bandwidth conversation is that it’s auditory, either. I know many people who, at the present moment, find phone conversations to be the easiest way for them to communicate with others long-distance. But that’s different from saying phone conversations are the most effective way of doing so, depending on your goals (for instance, phone conversations currently – usually – don’t get logged for posterity, let alone logged in a way that can be automatically translated). Similarly, there are undoubtedly highly effective non-visual ways of doing design. As someone who’s highly visual myself, I don’t know what they are, but I would love to learn. (One of the reasons I enjoyed reading Cory’s posts is that my hearing forces me to rely so heavily on visual input that I often forget to run thought experiments suspending the assumption that I can.)

I’d actually like to learn more about the design practice of looking at edge-case users (not sure if there’s a better term for this). Maybe posts like Cory’s can shed some insight into the advantages of non-visual design systems, or the disadvantages of visual design systems, in a way that makes both of them better for everyone (not just the visually impaired). I look a lot at the benefits of alternatives to auditory-by-default systems because I have to, and sometimes the adjustments I make end up being useful to other people.

Matt pointed out in his response to Cory’s post that the majority of the software development world does not use visual input either.

…the overwhelming majority of our communication and collaboration regarding software developing is written/verbal, not visual. That is, we’re not shipping pictures back-and-forth 24/7—we’re chatting on mailing lists, IRC, and blogs to get things done.

However, I do wonder whether the dominance of text-based communications in software development will continue as tools like inkboard (collaborative Inkscape) continue to be developed, or if an (initially secondary – possibly only within a subculture at first) alternative, more graphical/auditory discourse will start happening. The parallel for me is podcasting and vlogging. They haven’t replaced forums and mailing lists in general online discussions yet, but they are definitely a presence that I grow increasingly more disadvantaged for having to ignore.

Well, mostly ignore. Strictly speaking, I do have the advantage that I can catch some audio, and that I have friends who’ll sometimes take the time to write a video summary for me, or sit next to me while a podcast is running and re-mouth the words so I can lipread them, but for most practical purposes, that’s like saying that publishing documentation in Tamil should be entirely sufficient for English speakers because of the presence of Google Translate. It takes a lot of extra conscious effort, the availability of specific tools and helpers, a lot of extra time, and much is still lost in translation, so it’s usually not worth the investment to even try.

I find it fascinating to see how other people adjust and hack inclusion into a world that often doesn’t assume them in its default case. At least with open source I get to hack on things – and with things – that give me the freedom to shape them into what I need (yay visual system beeps!) but the burden’s still on me to do the shaping and the constant reminding of others that I need accessibility to the things they’d like me to contribute to (for instance, project meetings by phone virtually guarantee my silence). At least the burden here comes with the tools I need in order to assume it. (Mostly. We could do better, but that’s a longer post.) And I’m glad projects like Sugar try to make themselves more-hackable-by-default.

*re: “deaf” – I’m trying to get used to being able to use this word as well, though I can hear some sounds (my hearing loss is classified as “severe”) and grew up mainstreamed in the hearing world (with lots of hacks). It’s a cultural adjustment that I’m consciously learning (with tremendous latency and deep discomfort) to make.

Chris Ball: Btrfs snapshots proposal

Thu, 19 Nov 2009 19:54:21 +0000

I've written up a feature proposal on how we can use Btrfs snapshots to enable system rollbacks in Fedora 13, by gluing together the existing kernel code to do Btrfs snapshots, a UI for performing rollbacks, and a yum plugin to make snapshots automatically before each yum transaction. Lots of good comments so far, and LWN has written an article about it (subscribers only, for the moment).

Devan Goodwin: Introducing Cobbler4j

Thu, 19 Nov 2009 18:35:32 +0000

I've been doing some work recently on cobbler4j, a small Java library for interacting with Cobbler over XMLRPC based on the work done to integrate Cobbler into Spacewalk.

Right now the library basically allows you to open up a connection, and interact with the core object types (repos, distros, profiles, systems) as if they were actual Java objects. In the future this will likely grow to include other operations and background tasks. And as a required disclaimer, this is still very much a work in progress and should not be considered stable.

The cobbler4j wiki page covers most of the high level details on what it does and how to use it.

Here's a sample program:

import org.fedorahosted.cobbler.CobblerConnection;
import org.fedorahosted.cobbler.Finder;
import org.fedorahosted.cobbler.ObjectType;
import org.fedorahosted.cobbler.autogen.Distro;
import org.fedorahosted.cobbler.autogen.Profile;
 
import java.util.List;
import java.util.LinkedList;
 
public class Cobbler4jDemo {
 
    public static String DEMO_PROFILE = "demoprofile";
 
    public static void main(String [] args) {
 
        CobblerConnection xmlrpc = new CobblerConnection("http://192.168.1.1", "testing",
                "testing");
        Finder finder = Finder.getInstance();
        List<Distro> distros = (List<Distro>)finder.listItems(xmlrpc, 
                ObjectType.DISTRO);
        System.out.println("Distros list:");
        for (Distro d : distros) {
            System.out.println("   " + d.getName());
        }
        System.out.println();
        System.out.println();
 
        // Delete the demo profile if it got left laying around:
        Profile demoProfile = (Profile)finder.findItemByName(xmlrpc,
                ObjectType.PROFILE, DEMO_PROFILE);
        if (demoProfile != null) {
            System.out.println("Deleting profile: " + DEMO_PROFILE);
            demoProfile.remove();
            System.out.println();
            System.out.println();
        }
 
        // Create a demo profile, set the required properties:
        System.out.println("Creating profile: " + DEMO_PROFILE);
        demoProfile = new Profile(xmlrpc);
        demoProfile.setName(DEMO_PROFILE);
        demoProfile.setDistro("centos-5.3-i386");
        demoProfile.commit();
        System.out.println();
        System.out.println();
 
        System.out.println(DEMO_PROFILE + " settings:");
        System.out.println("   kickstart = " + demoProfile.getKickstart());
        System.out.println("   virt file size = " + demoProfile.getVirtFileSize());
        System.out.println("   Red Hat management key = " + demoProfile.getRedhatManagementKey());
        System.out.println();
        System.out.println();
 
        List<Profile> profiles = (List<Profile>)finder.listItems(xmlrpc, 
                ObjectType.PROFILE);
        System.out.println("Profile list:");
        for (Profile p : profiles) {
            System.out.println("   " + p.getName());
        }
        System.out.println();
        System.out.println();
 
        // Lookup our specific demo profile:
        demoProfile = (Profile)finder.findItemByName(xmlrpc, 
                ObjectType.PROFILE, DEMO_PROFILE);
 
    }
}

Some interesting things to note, firstly rather than maintain Java classes with a bevy of irritating getters/setters, Michael Dehaan started us down the path of auto-generating the Java classes from a template and the FIELDS metadata in the Cobbler Python code itself. (which describes each property on an object, it's type, and some other information) This posed some build problems early on but in the end it actually came out ok, and the build is relatively seamless with ant.

In the above example a couple magical things happen. The first relates to object creation, when creating the profile we specify only the bare minimum of information. If you were to do this from the cobbler CLI however your object would immediately have a number of other default settings applied. To replicate this behaviour after doing a commit on any cobbler object we immediately repoll the state from cobbler and update the object state internally for you.

Similarly another problem arises with Cobbler's notion of inheritance known as "blending". The implementation of this basically results in object properties being set to an inherit string constant if they're to use their parent object's value. This gets complicated however when you're auto-generating a Java class that expects a Boolean, but gets a String instead. Usually not a catastrophic problem in a dynamic language like Python, but Java is not so happy about it. To solve this we also maintain a hash of the "blended" properties as well which are obtained via a separate API call. Whenever we call a getter, and that object supports inheritance, and the property comes back as inherit, we instead return the value from the parent. This has the added benefit of not inadvertently setting parent values directly on the object itself whenever we do a commit.

So definitely a bit of magic going on but so far I haven't thought of situation where it would break down, and thus I'm content with it for now. There's some minimal overhead involved in the refresh calls but in local testing it's blazing fast, and likely not calls that will be used under heavy load. (as far as I can forsee)

While the bindings are definitely not yet considered stable, wheels are in motion and as always contributions would be welcome if anyone would like to participate. Special thanks to Partha Aji for his assistance, ideas, and contribution of the Finder class used for querying/listing objects.

Remi Collet: mysql-5.1.41-1

Thu, 19 Nov 2009 18:32:00 +0000

RPM of the MySQL Community Server 5.1.41 are available in remi repository for EL 4 & 5 and for Fedora. See Changelog.

This build use a spec file close to the one from Rawhide. The Federated "storage engines" is activated by default by the launch script. For the new InnoDB plugin, the configuration file(/etc/my.cnf) contains the directives need to enable it. Notice : the new configuration file provided disable the old_passwords. The old clients (mysql 3.x et... Lire mysql-5.1.41-1

Jeffrey C. Ollie: Generating Random Passwords With Python

Thu, 19 Nov 2009 17:57:14 +0000

Every now and then, I need to generate a password for use with something or other that I won't be typing in very often. For maximum security in these situations I like generating a long randomly generated password. Here's a quick Python snippet for generating them:

$ python
Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57) 
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> file('/dev/random', 'rb').read(12).encode('base64')
'XIUhRiMM/kcmsQl8\n'
>>> file('/dev/random', 'rb').read(12).encode('base64')
'BkgURdSXKORS8In/\n'
>>>

It's such a short snippet that I haven't ever bothered putting it in a script file, I just fire up a Python interpreter and type it from memory.

Clint Savage: News: Fedora 12 is NOW AVAILABLE!!

Thu, 19 Nov 2009 16:31:25 +0000

I’ve been running Fedora 12 for about a month now (Beta first, Alpha before that). It’s the best Fedora to date.

Everything Just Works(TM).

I highly recommend it to anyone who wants to have a system working with great sound, awesome graphics and very usable GNOME and KDE desktops. I really like the new NetworkManager features and the ability to tether any device, vpnc and other easy-to-configure options. KVM support is much improved with the new libguestfs improvements.

Fedora 12 media should be available on December 3, if you are a Fedora Ambassador in North America, start requesting media* for your events (and ambassador kits).

You can get your copy today!!

Cheers,

Herlo

*NOTE: This request page is not for the freemedia project. You must be a Fedora Contributor to request media. Join the Fedora Project today and help us continue making Fedora the best operating system!!

Tom 'spot' Callaway: Things an Unprivileged Linux User Must Not Be Able To Do

Thu, 19 Nov 2009 15:06:22 +0000

An Unprivileged Linux User Must Not Be Able to:

* Add, Remove, or Upgrade system software (packaged or otherwise)
* Read or Write directly to/from system memory
* Load or Unload kernel modules
* Start or Stop System Daemons
* Edit System-wide configuration files
* Access other users home directories (unless explicitly granted permission by another user)
* View or Change another users password
* Add or Remove User accounts
* Change the System Clock
* Shutdown or Reboot the System (unless they are the only user logged in)
* Read or Write System Logs (/var/log/*)
* Write a file outside of /tmp or their user home directory (unless explicitly granted permission by another user)

What else am I missing?

Note: A user with sudo access is not an unprivileged user. A user who knows the root password is not an unprivileged user. A user placed into an "admin" group is not an unprivileged user.

Fedora People

Bryan Clark: Raindrop & Jetpack

Debarshi Ray: Solang: Brasero integration

David Malcolm: 2to3c: an implementation of Python's 2to3 for C code

John Poelstra: Fedora Target Audience & Release Criteria

Fujisan: F12: Yum new feature: history

Steven Parrish: FUDCon 2009 is almost here. Are you ready?

Máirín Duffy: Want to learn design skills? Want to help Fedora? Fedora Interaction Design Hackfest, Tuesday 24 Nov

Okay Mo, so first of all, what is a persona?

Okay, uh, so how are personas going to help us make Fedora policy and design decisions?

Well Mo, this sounds good. But where do we get personas from?

So…. How can I help?

Adam Williamson: OpenID (and others) login support

Ankur Sinha - franciscod: rtorrent <3 <3 <3

Jeffrey C. Ollie: The Asterisk SLN16 Codec

Remi Collet: PHP 5.3.1 Released!

John (J5) Palmieri: I would just like to say PiTiVi rocks

Steven Pritchard: Why developers suck as admins

Nate Straz: qarsh 1.25 released

Greg DeKoenigsberg: The difference between transparency and communication

Matthew Garrett: Why SHMConfig is off by default

Tiansworld: Fedora 12硬盘安装记录

Carlos (casep) Sepulveda: yum history

Henrique "LonelySpooky" Junior: Usuários não-root instalando pacotes no Fedora 12

"Rodrigo Padula": Fedora 12 - Lançamento Oficial no Brasil / Fedora 12 - Brazilian Official Release

Diana Martin: Hello Fedora!

Projeto Fedora Brasil: Fedora 12 - Lançamento oficial no Brasil será realizado no SOLISC dia 26 e 27 de Novembro em Florianópolis - SC

Edward Karavakis: LHC restart – 2009 LHC beams.

"Rodrigo Padula": Famsco Elections - I’m running for reelection

Bastien Nocera: Sticky tape

Nicu Buculei: Digital painting

Richard Hughes: The Fedora 12 Installing Saga

Kushal Das: Dhunuchi Dance (ধুনুচি নাচ)

Kushal Das: sparcy — command line utility for Spac Systems Limited GPS loggers

Adam Williamson: Video acceleration repository updates

Ankur Sinha - franciscod: Fedora : PackageKit change

Christoph Wickert: Follow-up on the LXDE images

Michael DeHaan: Theoretical Attack Vector?

Jon Stanley: Much ado about nothing

Christos Bacharakis: Η Fosscomm 2010 στη Θεσσαλονίκη

Shakthi Kannan: Fedora 12 on HP 6730s laptop

Dan Williams: Few Surprised at New Evidence of Staging Driver Suckage

Just Say No

So what’s the right thing to do?

Luya Tshimbalanga: Comment about bugz#534047

Juanjo Martínez: Weird Things on Fedora 12

Gino Alania: Fedora-pe

Mark J. Wielaard: GPLed JDK 7 M5 + Jigsaw binary packages

Fedora Venezuela: 064/365: un paso adelante – a step foward

Matthew Garrett: Sigh.

Mel Chua: Reply to Cory

Chris Ball: Btrfs snapshots proposal

Devan Goodwin: Introducing Cobbler4j

Remi Collet: mysql-5.1.41-1

Jeffrey C. Ollie: Generating Random Passwords With Python

Clint Savage: News: Fedora 12 is NOW AVAILABLE!!

Related Posts

Tom 'spot' Callaway: Things an Unprivileged Linux User Must Not Be Able To Do