From Fedora Project Wiki


Fedora Weekly News Issue 275

Welcome to Fedora Weekly News Issue 275[1] for the two weeks ending May 18, 2011. What follows are some highlights from this issue.

FWN is back after a hiatus last week! In announcements from the Fedora Project, important details on changes to requirements for all Fedora contributors, as well as country requirements for steering committee members. In development announcements, a couple outage announcements as well as the Fedora 15 final change deadline details, and later details of Fedora 15's Gold release status. In Fedora In the News, six articles from the trade press and blogs this week around Fedora 15, Virtualbox, and work on packaging Unity for Fedora 15. The Ambassador team this week announced new Ambassadors for the Netherlands and Israel, a summary of traffic from the Ambassador and FAmSCo lists and a couple event reports from Flisol in South America. In Quality Assurance news, reports on the latest Test Day on Cloud services, details on Fedora 15 validation and preparation, and report on recent AutoQA news. Security Advisories brings us current with security-related package releases for Fedora 13, 14 and 15, and Fedora LATAM is back with another Spanish-language tutorial on Ruby. Enjoy FWN 275!

An audio version of some issues of FWN - FAWN - are available! You can listen to existing issues[2] on the Internet Archive. If anyone is interested in helping spread the load of FAWN production, please contact us!

If you are interested in contributing to Fedora Weekly News, please see our 'join' page[3]. We welcome reader feedback:

FWN Editorial Team: Pascal Calarco, Adam Williamson


In this section, we cover announcements from the Fedora Project, including general announcements[1], development announcements[2] and Events[3].

Contributing Writer: Pascal Calarco

Fedora Announcements

Change in requirements for Board, FESCo, and FAmSCo candidates

Tom Callaway, from Fedora Legal, on Mon May 16 14:53:49 UTC 2011 announced[1],

"There has been an amendment to the requirements for candidates to elected (and appointed) roles in Fedora's Community, including (but not limited to) the Fedora Board, Fedora Engineering Steering Committee, and the Fedora Ambassadors Steering Committee.

Specifically, candidates must not be a citizen of an export-restricted country (see[2] for the list of export restricted countries).

This requirement is applicable immediately, and will apply to candidates for this upcoming election as well.

Unfortunately, the laws in the United States which Fedora and Red Hat are subject to place very tight restrictions on the involvement of citizens of certain countries. Fedora has made its position on this issue known here:


Thank you for your understanding"

IMPORTANT - Fedora Project Contributor Agreement Signing Window Is Open

Tom Callaway on Tue May 17 20:05:56 UTC 2011 announced[1],

"Please take a moment and read this brief email, as it is important.

Fedora is in the process of retiring our old "Individual Contributor License Agreement" (also known as the ICLA or CLA) and replacing it with the new Fedora Project Contributor Agreement (FPCA).

All Fedora contributors with accounts in the Fedora Account System ([2]) who have agreed to the old CLA *MUST* agree to the new FPCA by June 17, 2011 to continue contributing to Fedora.

Here is how you do this:

1) Login to the Fedora Account System: [3]

2) Once logged in, click on the "My Account" link in the blue box on the left side of the window.

3) On the page that loads, you will see a section labeled "Account Details". Look for the line that says "Contributor Agreement". On that line, you should see a new section that says:

"New CLA Not Signed - We need contributors to sign the new Contributor Agreement(Complete it now!)"

Click on "Complete it now!" and follow the prompts.

It is important that Fedora Account holders who have signed the old Fedora CLA sign the new FPCA. We have allotted a window of one month for Fedora contributors to agree to the FPCA. This means that after June 17, 2011, any Fedora Contributors who have not agreed to the FPCA will have their "cla_done" flag set to False. This also means that any groups that they are in which are dependent upon "cla_done", such as "packager", "ambassador", and Fedora People access will be removed.

There are a few accounts which are exempt from this, specifically, accounts which are members of the "cla_dell", "cla_intel", and "cla_redhat" groups. If you do not know what these groups are, you are probably not in them. :) Accounts in these groups will not see the "New CLA Not Signed" line on their "My Account" page, and do not need to take any action at this time.

Please take a minute and login to FAS to agree to the terms of the FPCA, to avoid loss of access.

More information about the FPCA, including the final FPCA text, can be found here: [4]

If you have any additional questions about the FPCA or the re-signing process, please feel free to email me directly at legal at"

Fedora Development News

The Development Announcement[1] list is intended to be a LOW TRAFFIC announce-only list for Fedora development.

Acceptable Types of Announcements

  • Policy or process changes that affect developers.
  • Infrastructure changes that affect developers.
  • Tools changes that affect developers.
  • Schedule changes
  • Freeze reminders

Unacceptable Types of Announcements

  • Periodic automated reports (violates the INFREQUENT rule)
  • Discussion
  • Anything else not mentioned above

Outage: - 2011-05-10 17:00 UTC

Kevin Fenzi on Fri May 6 17:20:00 UTC 2011 announced[1],

"There will be an outage starting at 2011-05-10 17:00 UTC, which will last approximately 1 hour."

The details of the report are available at

Outage: moving - 2011-05-09 15:00 UTC

Kevin Fenzi on Fri May 6 19:50:47 UTC 2011 announced[1],

"There will be an outage starting at 2011-05-09 15:00 UTC, which will last approximately 1hour."

The details of the report are available at

Fedora 15 Final Change Deadline, and Outstanding Blocker Bugs

Robyn Bergeron on Tue May 10 11:34:42 UTC 2011 announced[1],

"This is your friendly reminder that we have reached the Final Change Deadline for Fedora 15.


"After the change deadlines for the Final release no more updates are made to the branched development repository (e.g. /pub/fedora/linux/development/15).

The only exceptions are accepted blocker and "nice to have" bugs: [3] [4]

All updates after this time are considered zero day updates of the release, and are pushed to the updates repository which is available on the public availability date. For example, the repository for Fedora 15 is /pub/fedora/linux/updates/15."

The next step in the process is to create a final release candidate (RC) to pass on to QA for testing as soon as possible. However, we have a handful of bugs left that are blocking the creation of the RC. Delays in resolving the bugs listed below will prevent the creation of the RC, and CAN CAUSE A SLIP IN THE SCHEDULE.

[5] 697834 :: NEW :: gnome-menus :: rstrode Other menu appears in default installation (any .desktop entry with Category=Settings ends up here (even if there's also Category=System))

[6] 693809 :: ASSIGNED :: imsettings :: tagoh Error message about missing input methods should be removed"

REMINDER: Outage: - 2011-05-10 17:00 UTC

Kevin Fenzi on Tue May 10 16:47:10 UTC 2011 announced[1],

"A reminder that this outage will begin in about 15minutes.

Outage: - 2011-05-10 17:00 UTC

There will be an outage starting at 2011-05-10 17:00 UTC, which will last approximately 1 hour."

The details of the report can be found at

On the separate outage notification, Kevin Fenzi announced[2]

"Sorry for not sending this sooner.

The outage on should be complete.

Please report any issues or problems found. "

Fedora 15 FINAL Go/No-Go Meeting, TUESDAY, May 17, 2011 @ 21:00 UTC (17:00 EDT/14:00 PDT)

Robyn Bergeron on Mon May 16 15:51:41 UTC 2011 announced[1],

"Join us on in #fedora-meeting for this important meeting, Tuesday, May 17, 2011, at 21:00 UTC (17:00 US-Eastern, 14:00 US-Pacific).

"Before each public release Development, QA, and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the: Go/No-Go Meeting."

"Verifying that the Release criteria are met is the responsibility of the QA Team."

For more details about this meeting see: [2]

And while you wait, keep an eye on the current F15 final blockers, and help fill out the test result matrices:

[3] [4]

See you there!

(And my apologies for sending this out in a less-than-timely manner - I had it stuck in my head that this meeting was Wednesday.)"

Fedora 15 Final Release is declared GOLD!

Robyn Bergeron on Tue May 17 22:25:59 UTC 2011 announced[1],

"At the Fedora 15 Final Go/No-Go meeting today, the Fedora 15 Final Release was declared GOLD and ready for release on May 24, 2011.

Please note that the Fedora 15 Release Wide Readiness Meeting will take place on Thursday at 19:00 UTC (3 PM Eastern/ 12 PM Pacific) on in #fedora-meeting.


Thanks to everyone for doing your part to get Fedora 15 out the door! :)

  1. fedora-meeting: Fedora 15 Go or No go Meeting[3]

Meeting started by rbergeron at 21:00:33 UTC. The full logs are available at[4]

Meeting summary
  • Who's here? (rbergeron, 21:00:54)
  • Why are we here? (rbergeron, 21:02:11)
  * The purpose of this meeting is to decide whether the final release
    criteria have been met  (rbergeron, 21:02:30)
  * LINK:

rbergeron, 21:02:50)

  • To Go, or Not to Go? That is the question. (rbergeron, 21:03:51)
  * LINK:
    (rbergeron, 21:04:16)
  * the four proposed blockers are not blockers, per yesterday's QA
    meeting.  (rbergeron, 21:07:04)
  * AGREED: We are technically blocker free.  (rbergeron, 21:09:57)
  • Test Matrices (rbergeron, 21:10:13)
  * LINK:

rbergeron, 21:10:48)

  * LINK:

rbergeron, 21:11:10)

  * We will be composing a sugar live image late with some
    sugar-specific fixes pulled in.  (rbergeron, 21:12:49)
  * Only desktop and KDE can block the release.  (rbergeron, 21:13:03)
  * AGREED: Test matrices are acceptable for a go.  (rbergeron,
  • Rel-eng (rbergeron, 21:14:11)
  • FESCo/Devel (rbergeron, 21:15:14)
  • GOLD? (rbergeron, 21:16:31)
  * AGREED: Fedora 15 is declared gold. shipit!  (rbergeron, 21:18:09)
  • open floor (rbergeron, 21:18:48)
  * Thanks to the systemd and gnome/desktop guys as both groups did a
    lot of work to get those large features working well.  (rbergeron,
  * and Thanks! to everyone else as well!  (rbergeron, 21:19:36)
  * ACTION: rbergeron to send out GOLD email to the lists  (rbergeron,
  * Please note there is a readiness meeting on Thursday, email has been
    sent to logistics list as well as attendees needed to be present.
    (rbergeron, 21:20:21)

Meeting ended at 21:22:46 UTC.

Action Items
  • rbergeron to send out GOLD email to the lists
Action Items, by person
  • rbergeron

rbergeron to send out GOLD email to the lists

People Present (lines said)
  • rbergeron (58)
  • adamw (29)
  • dgilmore (8)
  • cwickert (6)
  • Viking-Ice_ (6)
  • brunowolff (5)
  • jsmith (4)
  • zodbot (3)
  • stickster (3)
  • nirik99 (3)
  • spot (3)
  • fenrus02 (2)
  • jlaska (2)
  • red_alert (1)
  • therefore (1)
  • athmane (1)"

[Guidelines Change] Changes to the Packaging Guidelines

Tom Callaway on Wed May 18 17:49:05 UTC 2011 announced[1],

"Here are the latest changes to the Fedora Packaging Guidelines:

A section has been added to the SysVInitScript guidelines covering the optional situation where a package that uses systemd unit files as the default also includes sysv initscripts in a subpackage:


The GIO scriptlets have been changed to not conditionalize the %post invocation. This works around a multilib issue.


The guideline that prohibits Fedora packages from using /srv has been updated to better represent what the FHS has to say about /srv and to clarify the expectations for Fedora packages which may be configured to use /srv.


It was brought to the FPC's attention that while the new Guidelines covering MinGW packaging were technically correct, Fedora 16 did not yet contain the necessary toolchain to support the new Guidelines, nor was it clear that it would arrive in rawhide anytime soon.

Accordingly, the "old" MinGW guidelines were put back in place at: [5]

The "new" MinGW guidelines remain approved, but are not active and packagers should not use them at this time. If/when the necessary toolchain components are packaged in Fedora, these guidelines will be re-enabled.

In addition, the current MinGW guidelines were improved slightly to support the "new" SRPM naming standard. This is intended to prevent new MinGW packages from having to be re-reviewed when the "new" MinGW guidelines take effect.

These guidelines (and changes) were approved by the Fedora Packaging Committee (FPC).

Many thanks to Kalev Lember, Matthew Miller, Michael Schwendt, and all of the members of the FPC, for assisting in drafting, refining, and passing these guidelines.

As a reminder: The Fedora Packaging Guidelines are living documents! If you find something missing, incorrect, or in need of revision, you can suggest a draft change. The procedure for this is documented here: [6]"

Fedora Events

The purpose of event is to build a global Fedora events calendar, and to identify responsible Ambassadors for each event. The event page is laid out by quarter and by region. Please maintain the layout, as it is crucial for budget planning. Events can be added to this page whether or not they have an Ambassador owner. Events without an owner are not eligible for funding, but being listed allows any Ambassador to take ownership of the event and make it eligible for funding. In plain words, Fedora events are the exclusive and source of marketing, learning and meeting all the fellow community people around you. So, please mark your agenda with the following events to consider attending or volunteering near you!

Upcoming Events (March - May 2011)

  • North America (NA)[1]
  • Central & South America (LATAM): [2]
  • Europe, Middle East, and Africa (EMEA)[3]
  • India, Asia, Australia (India/APJ)[4]

Past Events

Archive of Past Fedora Events[1]

Additional information

  • Reimbursements -- reimbursement guidelines.
  • Budget -- budget for the current quarter (as distributed by FAMSCo).
  • Sponsorship -- how decisions are made to subsidize travel by community members.
  • Organization -- event organization, budget information, and regional responsibility.
  • Event reports -- guidelines and suggestions.
  • LinuxEvents -- a collection of calendars of Linux events.

Fedora In the News

In this section, we cover news from the trade press and elsewhere that is re-posted to the Fedora Marketing list[1].

Contributing Writer: Pascal Calarco

Fedora 15 Boosts Linux Security (

Rahul Sundaram forwarded[1] a notice about a Fedora 15 article in Spanish that was recently published:

"We have better support for encrypted home directories that get mounted when you log in and that goes a long way to help people feel that their data is secure," Jared Smith, Fedora Project Leader told

In addition to encryption, Fedora 15 debut the new dynamic firewall technology that Smith noted was one of his favorite features in the new Linux release.

Most Linux systems use IP tables type firewalls and the problem is that if you want to make a change to the firewall, it's hard to modify on the fly without reloading the entire firewall," Smith said. "Fedora 15 is really the first mainstream operating system to have a dynamic firewall where you can add or change rules and keep the firewall up and responding while you're making changing."

The full post is available[2].

Fedora 15 Goes Gold, and That's Not All (

Rahul Sundaram forwarded[1] a blog posting on the release of Fedora 15 Gold:

"The most notable of the Fedora 15 features is the move to GNOME 3. GNOME 3 was met with mixed reactions and this is another reason to look forward to Fedora 15 reviews. Some of the other features include KDE 4.6.x, Xfce 4.8, GCC 4.6, a change to LibreOffice, removal of Setuid apps, improved SPICE support, /var/run and /var/lock mounted as tmpfs, and systemd. Fedora 15 is due May 24."

The full posting is available[2].

Fedora 15 completed, new contributor agreement (The H Online)

Rahul Sundaram forwarded[1] an article on Fedora 15 and the Fedora Project's new contributor agreement:

"Fedora Engineering Manager Tom Callaway has also announced that all Fedora contributors must agree to the Fedora Project Contributor Agreement (FPCA) by 17 June if they plan to continue contributing to Fedora. An FAQ on the project's web site offers the FPCA wording and provides a more detailed explanation of the reasons for this measure. For instance, the new document is said to be simpler and remove various obstacles that have reportedly been stumbling blocks for some developers."

The full article is available[2].

Life with Fedora 15 and Gnome 3

Rahul Sundaram forwarded[1] another posting on Fedora 15 and Gnome 3:

"I’m pretty happy with the state of things now. I have to admit that in the beginning, I was cursing loudly asking for my desktop and panel back, but I’m used to the dash area and window picker now. The search feature (which is similar to Spotlight in OSX) is really useful and I end up using that for the majority of my tasks. I also find the notification system very well done along with the ability of dealing with messages without changing windows. In the end, all I can say is I find myself using Fedora more over my pretty MacBook Air for the majority of my tasks."

The full article is available[2].

VirtualBox 4.0.8 Released With GNOME Shell Support (For Fedora 15) (

Rahul Sundaram forwarded[1] an article about the release of VirtualBox 4.0.8 with Gnome shell support:

"The latest VirtualBox 4.0.8 finally comes with GNOME Shell support. I've tested it in Ubuntu 11.04, using a Fedora 15 virtual machine and Gnome Shell worked great. According to the changelog, it should work with both Ubuntu 11.04 and Fedora 15"

The full article is available[2].

Other Linux Distros' View of Ubuntu's Unity: It Ain’t Pretty

Rahul Sundaram forwarded[1] an interview with Adam Williamson's effort in packaging Unity for Fedora 15:

"At Fedora, Red Hat developer Adam Williamson is packaging Unity because "I wanted to check it out and figured packaging it should be about as easy as installing Ubuntu. It wasn't, but by then my native stubbornness kicked in and now I want to package it more or less because it's there. I doubt it'll work terribly well . . . it'll sorta more or less work but have lots of rough edges and not be something the upstream Unity team would be happy to show off."

Williamson stresses, though, that his efforts are personal. "There's been exactly no distribution-wide discussion of this; it's not some kind of official approach to Unity or anything like that. Fedora as a whole has no policy or opinion on Unity. Ditto for Red Hat."

The full article is available[2].


This section covers the news surrounding the Fedora Ambassadors Project[1].

Contributing Writer: Sankarshan Mukhopadhyay

Welcome New Ambassadors

This week the Fedora Ambassadors Project had a couple of new members joining.

Elad Alfassa from Israel mentored by Bert Desmet

Richard de Bruin from the Netherlands mentored by Bert Desmet

Summary of traffic on Ambassadors mailing list

Larry Cafiero reminded [1] about FAmNA meeting for 2011-05-03 [2]

Christoph Wickert reminded [3] about EMEA Ambassadors meeting on 2011-05-04 [4] and later posted [5] the Meeting Minutes [6]

David Ramsey mentioned [7] that the special APAC meetings for weekly Wednesdays would be at 1000 UTC [8]

Haowei Lee provided updated information [9] about the Fedora 15 China Online Event

Truong Anh. Tua posted [10] meeting notes from the APAC Ambassadors meeting on 2011-05-04 [11]

Rejaul Islam updated [12] information about Fedora 15 Release Parties being organized at Bangladesh

Jiri Eischmaan reported [13] about plans to organize a Fedora 15 Release Party at the Brno office of Red Hat [14]

David Ramsey reminded [15] about the APAC Ambassadors Meeting to be held on 2011-05-07 at 0400 UTC [16] and later posted [17] the Meeting Minutes [18]

Buddhika Kurera initiated a thread [19] about FUDCon preparation for APAC. Further along the thread [20] there was a request to have more ideas in addition to the one from Fedora Ambassadors in Malaysia [21]

Max Spevack relayed feedback [22] received at the Red Hat Summit about the Fedora Business Cards [23]. Arturo Fernandez reminded [24] about the business card generation not working properly with UTF-8 encoding and mentioned that a patch was available to fix it. David Nalley followed it [25] with a request to remove the Fedora Talk line from the card as the service was deprecated.

David Ramsey reminded [26] about special APAC meeting for weekly Wednesday on 2011-05-11 [27] Buddhika Kurera posted [28] the meeting logs [29]

David Ramsey informed [30] about the availability of the Fedora 15 RC1 for testing

David Ramsey also posted [31] information around the upcoming Board and FESCo elections

Felix Kaechele requested an owner [32] for the FrOSCon 2011 [33] at Germany [34]

Igor Pires Soares posted [35] Meeting Minutes for FAmSCo meeting for 2011-05-14 [36] The resulting thread [37] had discussions among Ambassadors with suggestions about how to handle the current situation of empty seats at FAmSCo

Neville A. Cross begun the process [38] to draw up a schedule for the FAmSCo Town Halls

Tom Callaway posted [39] about the Change in requirements for Board, FESCo and FAmSCo candidates in that "specifically, candidates must not be a citizen of an export-restricted country " [40]


Summary of events reported on Ambassadors mailing list

Antonio Salles posted [1] photographs from the Flisol event [2] Eduardo Zamorano also posted some photographs [3]

Summary of traffic on FAmSCo mailing list

Neville A. Cross informed [1] about being unable due to working on the arrangements for the LibreBus event.

Igor Pires Soares called for discussion [2] around the proposal for a FAD at the 12th Free Software International Forum for which there already exists a plan and budget estimate [3] Neville A. Cross wondered [4] if the Budget discussion was a FAmSCo or, a Community Architecture team issue. Igor Pires Soares mentioned [5] a prior mail to Max Spevack which was awaiting a response and updated that the tasks with the local team are now completed. Pierros Papadeas indicated [6] that it was justifiable to allocate a budget of ~1000 USD for a FAD and suggested the creation of a wiki page. Igor Pires Soares followed up [7] with details about the tickets on the trac [8] [9] And, further that the FAmSCo meeting [10] approved to fund lodging for those paying airfare and, lodging+airfare for those requests who live near the city of the event hosting.

Igor Pires Soares informed [11] about the draft of the FAmSCo April report was available on the wiki [12] for editing.

Gerard Braad notified [13] about the discussion around resignation [14] of Larry Cafiero from The Fedora Project and indicated that roles and responsibilities within the FAmSCo needed to be re-assigned. Neville A. Cross indicated [15] about a possible set of steps including moving a proposal to remove Rahul Sundaram and vote on that.

Neville A. Cross informed [16] about the state of readiness of the FAmSCo survey built using the Lime Survey service [17] which now needs to be activated and sent to participants. Gerard Braad corrected [18] a few typographical errors in the document and signed it off. Neville A. Cross also provided information [19] [20] around the charges/expenses involved for running the survey.

Gerard Braad responded [21] to Buddhika Kurera's comments on the FAmSCo meeting minutes of 2011-05-14

Summary of traffic on Campus Ambassadors mailing list

The mailing list did not have any traffic this week.


In this section, we cover the activities of the QA team[1]. For more information on the work of the QA team and how you can get involved, see the Joining page[2].

Contributing Writer: Adam Williamson

Test Days

Thursday 2011-04-28 was cloud Test Day, with events for BoxGrinder[1] and EC2[2]. Both Test Days went off successfully, with a decent turnout of testers and some productive results. Marc Savy posted a recap of the BoxGrinder event[3]: "In the course of testing only two major unanticipated bugs were encountered, along with several known issues for Fedora 15 appliances, but no blockers preventing inclusion in the distribution. These problems have since been remediated in the upcoming 0.9.2 release...Aside from the bugs exposed, the opportunity to meet new users, garner ideas and solicit opinions was extremely worthwhile."

These were the final Test Days for the Fedora 15 cycle. If you would like to propose a main track Test Day for the Fedora 16 cycle, please contact the QA team via email or IRC, or file a ticket in QA Trac[4].

Fedora 15 validation and preparation

Over the last three weeks the group has been busy with preparation and testing for the final Fedora 15 release, leading to the absence of this beat from recent FWN issues, for which we apologize. The final blocker review meeting took place on Friday 2011-05-06[1]. The first test compose landed on Tuesday 2011-05-03[2], followed by three release candidates, the first on Wednesday 2011-05-11[3], the second on Friday 2011-05-13[4], and the third and final also on that date[5]. The group completed desktop and installation validation testing for all four composes, viewable on the Wiki[6] [7]. As can be inferred from the existence of the second and third release candidates, the group was able to identify release blocking issues and ensure these were successfully resolved. The RC3 testing confirmed that this image set met all release criteria, and it was duly approved as the gold image set for Fedora 15 release at the Go/No-Go meeting of 2011-05-17[8], a decision which was later announced by Robyn Bergeron[9].

Sample data and configurations for testing

Samuel Greenfeld asked whether the group had a repository of sample items of data and configuration files for testing updates[1]. James Laska replied that there was not such a repository, and suggested that such files could be added to the Wiki and incorporated in appropriate test cases[2]. Samuel explained that he thought such files could be useful in multiple cases, so a separate structure from the test case setup was required[3].

Problematic glibc update

The group (along with the development team) was quick to catch a problematic glibc update[1] which constituted a significant ABI break shortly before Fedora 15 release. This was spotted both on the mailing list[2] and via the Bodhi update feedback system[3]. The updates policy[4] ensured that the update was not accepted until the ABI change had been reverted.

Triage scripts updated

Matej Cepl announced the release of a major update to his Firefox extension to aid in bug triage, bugzilla-triage-scripts 1.0 RC1[1]. He asked all Bugzappers with Firefox 4 to update to it and report back on how it worked.

Desktop release criteria revisions

Matthias Clasen proposed several revisions to the desktop-related release criteria[1], prompted by discussions about a then-release-blocking bug report on the presence of an Other category in the Shell's applications view[2]. He proposed removing the criterion requiring there to be no Other category in the application menus, among other changes. Adam Williamson commented on the proposed changes[3], as did James Laska[4].


During the QA meeting of 2011-05-02[1], Kamil Paral explained that the AutoQA team had decided the upcoming 0.5.0 release would have a tight focus on making AutoQA feedback more friendly to developers, following several comments from developers on the verbosity and usefulness of current AutoQA results. Tim Flink provided minutes from the meeting where this plan was discussed[2]. Plans include reducing the number of AutoQA comments in Bodhi and improving the structure and contents of the dependency check test log. The group had also fixed a problem with disk space exhaustion resulting in the deletion of recent test logs, which turned out to be caused by tests stuck in a loop writing huge logs.

During the meeting of 2011-05-16[3], Kamil reported that he had implemented package caching in AutoQA, which can drastically speed up dependency check test runs when enabled. Josef Skladanka said that he had introduced an algorithm to filter out key information from the dependency check test log explaining why a given package has dependency issues. The team had started to document its test cases, beginning with the upgradepath test[4]. Tim was working further on the looping tests issue, and Vitezslav Humpa created a template for future test reports[5].

Security Advisories

In this section, we cover Security Advisories from fedora-package-announce for the period May 12-21, 2011.

Contributing Writer: Pascal Calarco

Fedora 15 Security Advisories

Fedora 14 Security Advisories

Fedora 13 Security Advisories

LATAM Fedora!

LATAM Fedora is a regular column of Spanish language contributions around open source software. It is our first expansion into incorporating foreign language content into FWN.

This week's contribution is from Guillermo Gómez, a fourth installment on Ruby. Enjoy!

Ruby Capítulo 4 : Control de Acceso y Duck Typing

Cuando se diseña una interfase de una clase es importante considerar cuánto se expone de la clase al exterior. El permitir mucho acceso a su clase incrementa el riesgo de incrementar el "acoplamiento" en su aplicación, es decir, depender en demasía de los detalles de la implementación en vez de su interfase lógica.

En Ruby la única forma fácil de cambiar el estado de un objeto es por medio del uso de uno de sus métodos, controle el acceso a los métodos y controlará el acceso al objeto. Ruby ofrece tres niveles de protección:

   * Métodos públicos: pueden ser invocados por cualquiera, no se aplica ningún control de acceso. Los métodos son públicos por omisión excepto initiliaze que siempre es privado.
   * Métodos protegidos: sólo pueden ser invocados por objetos de la misma clase o subclases. El acceso se mantiene a la familia.
   * Métodos privados: no pueden ser invocados con un receptor explícito, el receptor siempre es self. Esto significa que los métodos privados sólo pueden ser llamados en el contexto del objeto actual, no se puede invocar los métodos privados de otro objeto.

Una diferencia importante con otros lenguajes orientados a objeto es que el control de acceso es determinado dinámicamente en la medida que el programa se ejecuta. Obtendrá una violación de acceso sólo cuando intente ejecutar el método restringido.

Especificación del control de acceso

Se especifica el nivel de acceso de los métodos dentro de una clase o módulo utilizando una o más de las tres funciones public, protected y private. Puede usar cada función en dos formas diferentes.

Si se usan sin argumentos, las tres funciones definen el control de acceso de los métodos subsiguientes.

1 class MiClase
2     def metodo1    # 'public' por omisión
3       #
4     end
6   protected        # los subsiguientes métodos serán 'protected'
8     def metodo2    
9       #
10     end
12   private          # los subsiguientes métodos serán 'private'
14     def metodo3
15       #
16     end      
18   public           # los subsiguientes métodos serán 'public'
20     def metodo4
21       #
22     end
23 end

De forma alternativa puede simplemente listar los métodos en dichas funciones.

1 class MiClase
2   def metodo1
3     #
4   end
5   # ... y el resto de las definiciones de métodos
7   public    :metodo1, :metodo4
8   protected :metodo2
9   private   :metodo3
10 end

Ejemplo private

El ejemplo abajo muestra un esqueleto para proteger un método peligroso de alteración del estado del objeto por medio del uso de otro método intermediario que se supone asegura el acceso, esto ayuda a mantener el código separado pero simple, uno asegura por ejemplo las credenciales, el otro ajusta el estado del objeto.

1 class Banco
2   def initialize
3     @tasa="10%" 
4   end
6   def tasa
7     @tasa
8   end
10   def interfase_segura(nueva_tasa)  # Se supone que es "segura", llama al método privado
11     # Código de seguridad
12     self.tasa=nueva_tasa
13   end
15 private
16   def tasa=(nueva_tasa)
17     @tasa=nueva_tasa
18   end
19 end

1 >> banco =
2 => #<Banco:0xb747e318 @tasa="10%">
3 >> banco.tasa
4 => "10%" 
5 >> banco.interfase_segura("20%")
6 => "20%" 
7 >> banco.tasa
8 => "20%" 
9 >> banco.tasa="30%" 
10 NoMethodError: private method `tasa=' called for #<Banco:0xb747e318 @tasa="20%">
11     from (irb):63

Ejemplo protected

Por definición este control de acceso limita el acceso a la familia, objetos de la misma clase, y objetos de clases derivadas de la clase que define el método protegido. Abajo un ejemplo simple para comparar manzanas con manzanas, no con peras.

1 class Manzana
2   def initialize(peso)
3     @peso = peso
4   end
6   def <=>(otra_manzana)
7     self.peso <=> otra_manzana.peso
8   end
10   protected
12   def peso
13     @peso
14   end
15 end
17 class Pera
18   def initialize(peso)
19     @peso = peso
20   end
22   def <=>(otra_pera)
23     self.peso <=> otra_pera.peso
24   end
26   protected 
28   def peso
29     @peso
30   end
31 end

1 >> m1 =
2 => #<Manzana:0xb74838e0 @peso=100>
3 >> m2 =
4 => #<Manzana:0xb747dda0 @peso=200>
5 >> p1 =
6 => #<Pera:0xb74783c8 @peso=50>
7 >> m1 <=> m2
8 => -1
9 >> m1 <=> p1
10 NoMethodError: protected method peso' called for #<Pera:0xb74783c8 @peso=50>
11     from ./manzanas.rb:7:in <=>'
12     from (irb):11

Al intentar hacer la comparación entre manzana y pera, se invoca pera.peso en el contexto de las manzanas, y ya que el método está protegido, entonces da el error.

Ahora bien, esta idea de uso para protected en realidad está en franco desuso por muchos ya que va en contra de la flexibilidad y dinamismo natural de Ruby y del concepto de Duck Typing que explicaremos a continuación.

Duck Typing

En Ruby no declaramos tipos de variables o tipos para los métodos, todo es simplemente alguna encarnación, un objeto de una clase, y las clases no son tipos. Si deseamos programar con la filosofía Duck Typing lo único que necesita recordar es que el "tipo" de objeto está determinado por lo que puede hacer, no por su clase.

En la práctica esto significa que hay pocas pruebas de valores de objeto. Por ejemplo digamos que estamos programando un método para agregar información de dos objetos de cierta clase y obtener un resultado String. Los programadores con conocmientos de C# o Java estarían tentados a hacer algo como lo siguiente:

1 def anexar(obj1,obj2)
2   # probar que se nos han dado lo parámetros correctos
3   unless obj1.kind_of?(String)
4     fail"Se espera String")
5   end
6   unless obj2.kind_of?(String)
7     fail"Se espera String")
8   end
9   obj1 << obj2
10 end

1 >> anexar("Hola", " Mundo")
2 => "Hola Mundo" 
3 >> anexar("Hola", 1)
4 TypeError: Se espera String
5     from ./dt.rb:7:in anexar'

Si abraza la filosofía Duck Typing de Ruby podrá escribir este método de una forma mucho más simple.

1 def anexar(obj1,obj2)
2   obj1 << obj2
3 end

Usted no necesita verificar el tipo de los argumentos en tanto que se soporte el método << en obj1 simplemente todo funcionará bien. Si no es así, se lanzará una excepción de todas maneras, el mismo resultado de que si usted hubiera implementado la verificación. Pero de pronto su método es mucho más flexible, puede pasarle otros objetos no necesariamente String, tal vez un Fixnum.

1 >> anexar("Hola", 1)
2 => "Hola\001" 

¿Qué pasa si obj1 no soporta el método << entonces?

1 >> anexar(1.2, " dos ")
2 NoMethodError: undefined method <<' for 1.2:Float
3     from (irb):6:in `anexar'
4     from (irb):13

Obtenemos una excepción NoMethodError para el método << para la clase Float en este ejemplo. Una forma de prevenir posible es usar el método respond_to?:

1 def anexar(obj1,obj2)
2   # probar que se nos han dado lo par ámetros correctos
3   unless obj1.respond_to?(:<<)
4     fail"'obj1' necesita la capacidad <<")
5   end
7   obj1 << obj2
8 end

Pero nuevamente esto es más código que mantener y hay que evaluar si realmente quiere tomar ese trabajo ya que igualmente podría manejar las excepciones más arriba.

Si ahora pasa un Array como obj2 obtendrá un error de tipo ya que Array no es un String pero si podemos invocar el método to_s para obtener una representación razonable. En última instancia lo que queremos es que nuestro método si nos devuelva un String.

1 >> arreglo = [0,1,2]
2 => [0, 1, 2]
3 >> anexar("Hola", arreglo.to_s)
4 => "Hola012" 

Esto nos lleva a una nueva versión del método anexar, usando to_s para "convertir" los objetos en String, ahora ya tampoco necesitamos la verificación respond_to? ya que String responde a << . Tal vez ahora lo que necesita es validar es que tengan una representación en String, es decir, que respondan a to_s.

1 def anexar(obj1, obj2)
2   # probar que se nos han dado lo parámetros correctos
3   unless obj1.respond_to?(:to_s)
4     fail"Se espera que responda a to_s")
5   end
6   unless obj2.respond_to?(:to_s)
7     fail"Se espera que responda a to_s")
8   end
10   obj1.to_s << obj2.to_s
11 end

El código de prueba puede llevarle nuevamente a situaciones indeseables. ¿Soporta obj1 << pero no to_s? Es mejor lidiar con las excepciones que ponerse a probar los tipos y/o los métodos a los que responde. Con esta nueva versión, podemos por ejemplo pasarle dos arreglos, mejor dicho, cualquier par de objetos que tenga una representación String (to_s) y concatenarlos y obtener una salida en String.

1 >> arreglo = [0,1,2]
2 => [0, 1, 2]
3 >> anexar(arreglo, arreglo)
4 => "012012" 

Ahora veamos nuestro método en acción con varios objetos involucrados:

1 >> anexar("Hola", " Mundo")                           ; dos String
2 => "Hola Mundo" 
3 >> anexar(1, " Mundo")                                ; Fixnum + String
4 => "1 Mundo" 
5 >> anexar(1, 1)                                       ; dos Fixnum
6 => "11" 
7 >> anexar(1, 1.1)                                     ; Fixnum + Float
8 => "11.1"    
9 >> anexar(1, [1,2," :) "])                            ; Fixnum + Array
10 => "112 :) " 
11 >> anexar({1=> "mundo", 2 => "hola"}, [1,2," :) "])   ; Hash + Array
12 => "1mundo2hola12 :) " 

De lo único que debe preocuparse en su clase particular es que soporte to_s para tomar ventaja de nuestro método, si no fallará con una excepción. Veamos:

1 >> class Miclase
2 >> end
3 => nil
4 >> miobj =
5 => #<Miclase:0x7fb2a1b2c770>
6 >> anexar("Uh?", miobj)
7 => "Uh?#<Miclase:0x7fb2a1b2c770>"           ; to_s ya existe!
8 >> anexar(miobj, "¡Ah!")
9 => "#<Miclase:0x7fb2a1b2c770>\302\241Ah!"   ; to_s ya existe...

Por supuesto puede sobrescribir el método to_s heredado de Object.