From Fedora Project Wiki

< FWN
Revision as of 12:15, 21 July 2008 by Ush (talk | contribs) (update lasest issue for Pascal/Max to push out to lists, some minor last edits)

Fedora Weekly News Issue 135

Welcome to Fedora Weekly News Issue 135 for the week ending July 19, 2008.

http://fedoraproject.org/wiki/FWN/Issue135

Fedora Weekly News keep you updated with the latest issues, events and activities in the fedora community.

If you are interested in contributing to Fedora Weekly News, please see our 'join' page. Being a Fedora Weekly News beat writer gives you a chance to work on one of our community's most important sources of news, and can be done in only about 1 hour per week of your time.

We are still looking for beat writers to cover the highlights of Fedora Marketing each week and to summarize the Fedora Events and Meetings that happened during each week.

http://fedoraproject.org/wiki/NewsProject/Join

Announcements

In this section, we cover announcements from the Fedora Project.

https://www.redhat.com/mailman/listinfo/fedora-announce-list

https://www.redhat.com/mailman/listinfo/fedora-devel-announce

Contributing Writer: Max Spevack

FESCo Elections open on July 15th

Brian Pepple announced[1]:

"Elections for the Fedora Engineering Steering Committee (FESCo) open at 0001 UTC on 15 July 2008 -- or about 1 hour from the time of this message. The voting system is available at: https://admin.fedoraproject.org/voting

The voting system uses the range voting method: http://en.wikipedia.org/wiki/Range_voting

Any Fedora Account System (FAS) account holder who has completed the CLA, and has an addition account (like ambassadors, art, cvs*, fedorabugs, l10n-commits, web, etc.) in the FAS is eligible to vote. Voting is open until Monday, July 21st, 2008 23:59 UTC. Election results will be announced shortly afterward."

[1] https://www.redhat.com/archives/fedora-announce-list/2008-July/msg00005.html

FUDCon Brno 2008

Max Spevack announced the details of FUDCon Brno 2008[1]:

"The next FUDCon will take place in Brno, Czech Republic, from September 5 - 7, 2008.

The main conference day and social event will be on Saturday (to attract the most people), with hackfest days on Friday and Sunday. FUDCon is always free to attend, no matter where in the world it is located. "

[1] https://www.redhat.com/archives/fedora-announce-list/2008-July/msg00006.html

Release Engineering Email Trac Queue Disabled

[[JesseKeating|Jesse Keating] announced[1]:

"Until further notice the email to trac gateway for rel-eng has been disabled. We've been unable to cope with the spam attacks and the subsequent mail loops that have been created, and thus we have disabled the gateway.

For the time being if you need release engineering to do something for you, please use the web UI to file a ticket."

[1] https://www.redhat.com/archives/fedora-devel-announce/2008-July/msg00004.html

Planet Fedora

In this section, we cover the highlights of Planet Fedora - an aggregation of blogs from Fedora contributors worldwide.

http://planet.fedoraproject.org

Contributing Writer: Max Spevack

Fedora at RoboCup

Tim Niemueller reported from China[1]:

"As you can see on the photo we have put Fedora stickers at prominent places on our robots (there is one at the back side as well). It fostered some interest. I was talking to a member of the executive committee for the RoboCup@Home league. He liked the idea of a LiveCD with robotics software on it. A few other guys were asking "what is that T-Shirt about?"... Quite cool, hope to spawn more interest in Fedora in the RoboCup community."

[1] http://www.niemueller.de/blog/show.php?id=226

FUDCon Brno

Sandro "red" Mathys posted on his blog[1]:

"The FUDCon Brno 2008 in Brno, CZ has been announced a while ago (previously as being located in Prague, though). But only just yesterday, some basic facts were confirmed, after a short planning meeting on last Tuesday.

So, the facts so far are:

  • It will take place from Friday, 2008-09-05 to Sunday, 2008-09-07. Saturday, 2008-09-06 being the most important day, since people will probably travel there/back on Friday/Sunday.
  • It will take place at some university in Brno, CZ and we’ll have a hotel near the university which we’re told will not be very expensive.

That’s not much yet, but I think the most important things are fixed: When to travel and where to travel."

[1] http://blog.sandro-mathys.ch/2008/07/17/fudcon-brno-2008-in-the-czech-republic/

Privacy policy update

Paul Frields discussed the need to update Fedora's privacy policy on his blog[1]:

"Thankfully, we have a proposal from Tom ’spot’ Callaway that will fix some of these gaps, and improve the transparency of our project. The new policy, and FAS, will continue to keep absolutely private your vital personal information, like address and phone number. And the FAS will provide “opt-out” capabilities for any project member who does not want to share their other data.

The fedora-advisory-board mailing list has a thread to discuss the policy. After a discussion period over the next several days, the intention is to submit it to the Board for a vote."

[1] http://marilyn.frields.org:8080/~paul/wordpress/?p=1063

Beat writers needed

Paul Frields put out the call for writers[1]:

"As we approach the Fedora 10 Alpha release, the Docs team finds our list of beat writers for the Release Notes is sadly outdated. We need to get it updated with people who are willing to write information on Fedora 10 changes."

[1] http://marilyn.frields.org:8080/~paul/wordpress/?p=1066

Workarounds

Chris Tyler posted[1]:

"Some workarounds and fixes for annoyances I've recently encountered in Fedora:

  • Fedora Planet display problems in Firefox 2 (F8) and 3 (F9)
  • Unable to boot from a CD using KVM"

[1] http://blog.chris.tylers.info/index.php?/archives/127-Workarounds.html

Python dictionary optimizations

Luke Macken wrote[1]:

"In my recent journey through the book Beautiful Code, I came across a chapter devoted to Python's dictionary implementation. I found the whole thing quite facinating, due to the sheer simplicity and power of the design. The author mentions various special-case optimizations that the Python developers cater for in the CPython dictionary implementation, which I think are valuable to share."

[1] http://lewk.org/blog/python-dictionary-optimizations.html

SELinux and Security in the 2.6.26 Kernel

James Morris discussed SELinux in the 2.6.26 kernel on his blog[1].

"What's new and exciting with SELinux and security in the new 2.6.26 kernel?"

[1] http://james-morris.livejournal.com/31714.html

Steampunk photography - a GIMP tutorial

Nicu Buculei posted on his blog[1]:

"Now I can proceed to writing a GIMP tutorial about turning a regular photo intro "steampunk photography" effectively photos that would fit my Gears theme proposal for Fedora 10. (note: those photos are intended as additional graphics, not as a default wallpaper, I am not a big fan of photographic wallpapers as default and I can see no way of adding some blue to it, to make it look like Fedora).

Those familiar with my graphic tutorials probably know that I use to address the beginners, showing some techniques as simple as possible (and only pre-built filters), followed by some pointers about advanced usage and also letting it open, with a lot of optional steps and alternative ways, so I will try to do the same this time."

[1] http://nicubunu.blogspot.com/2008/07/steampunk-photography-gimp-tutorial.html

Marketing

In this section, we cover the Fedora Marketing Project.

http://fedoraproject.org/wiki/Marketing

Contributing Writer: Pascal Calarco

Cirgon Will Ship a Fedora Linux HTPC - Encore Media Server

Paul Frields reposted [1] an article [2] detailing the planned August 2008 release of a new Fedora Linux-based $2000 home theatre personal computer (HTPC), Encore Media Server, from Cirgon [3].

[1] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00105.html

[2] http://www.ehomeupgrade.com/2008/07/14/cirgon-will-ship-a-fedora-linux-htpc-encore-media-server/

[3] http://www.cirgon.com/index.html

Open Source in Brazil's Supreme Court

Teseu [1] publicized that the Supreme Court in Brazil is starting to initially replace Microsoft Office for OpenOffice in the Supreme Court offices there [2]. This will hopefully expand to other software applications as well, he indicates.

[1] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00112.html

[2] http://teseu.wordpress.com/2008/07/16/o-primeiro-passo-para-um-mundo-maior/

Improved audio from Paul Frields' 2008 FudCon talk

Valent Turkovic reported [1] that he enhanced the audio on Paul Frields' FudCon 2008 talk [2] that is available on FedoraTV [3], and posted how he did it. Jeff Spaleta remarked that "[y]ou just validated what we are trying to do here by having everything openly licensed and publicly available." [4]

[1] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00115.html

[2] http://herlo.fedorapeople.org/files/fudconf10paulfrields.ogg

[3] https://miroguide.com/channels/6891

[4] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00120.html

#1 Supercomputer in the World Runs Fedora

Rahul Sundaram shared [1] his posting on OSNews [2] documenting that the $100 million IBM Roadrunner [3], the current fastest supercomputer in the world, runs Fedora Linux.

[1] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00122.html

[2] http://osnews.com/story/20054/_1_Supercomputer_in_the_World_Runs_Fedora

[3] http://www.top500.org/system/9485

July 17th Marketing Meeting: A new Fedora Brand Motto

Michael Beckwith posted [1] the log of the July 2008 Marketing meeting. One of the major topics of the meeting was the Fedora brand of "infinity / freedom / voice" vs. the motto of "friends / freedom / features / first", developed earlier this year. Paul Frields later posted [2] that these new "four foundations" need to come to the front and become the new motto for Fedora. He invites ideas to express the four foundations graphically, and is going to be moving the request into the Artwork project queue.

[1] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00141.html

[2] https://www.redhat.com/archives/fedora-marketing-list/2008-July/msg00142.html

Ambassadors

In this section, we cover Fedora Ambassadors Project.

http://fedoraproject.org/wiki/Ambassadors

Contributing Writer: JeffreyTadlock

FUDCon Brno

Max Spevack posted [1] a link to the FUDCon Brno 2008 wiki page. This FUDCon is being held September 5 - 7, 2008 in Brno, Czech Republic. Additional details and sign-ups are available [2].

[1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-July/msg00211.html

[2] https://fedoraproject.org/wiki/FUDCon/FUDConBrno2008

More FrOSCon 2008 Information

Robert Albrecht posted [1] to the ambassador mailing list asking ambassadors who are attending to update the wiki page [2], let him know about hotel arrangements and to remind people of the social event.

[1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-July/msg00223.html

[2] http://fedoraproject.org/wiki/FedoraEvents/FrOSCon/FrOSCon2008


Help Wanted - Dharan Workshop

Tushar Neupaney asked for help [1] for a workshop being held in Dharan. The date has not been determined, but if you are in the area and can help please check the post for additional details.

[1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-July/msg00214.html


FAD EMEA 2008 Request for Comments

Sandro Mathys posted [1] a request for feedback in regards to FAD EMEA 2008. The email contains additional information and there is a wiki page [2] for the event.


[1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-July/msg00209.html

[2] https://fedoraproject.org/wiki/FAD/FADEMEA2008

Developments

In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.

Contributing Writer: Oisin Feeley

Kerneloops for SELinux

The last furore[1] over SELinux contained a positive contribution from StewartAdam, who proposed[2] to improve the interaction between users and SELinux by means of a "kerneloops-like plugin [which] would allow for statistics on where denials occur most and that way the policy could be modified accordingly." DanWalsh commented[3] that JohnDennis had written the setroubleshoot tool[4] to include the ability to send messages to an upstream collector. Dan was worried that he would be chosen as "the upstream infrastructure to handle all the messages" but optimistic that "the XML data [could be] run through some tools to see if the AVC was fixed by a newer version of policy". RobinNorwood thought[5] this would be easily solved using TurboGears[6] and Stewart concurred[7].

[1] http://fedoraproject.org/wiki/FWN/Issue133#SELinux.Eats.Babies.2C.Confines.Wives.2C.Gives.Birth

[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01081.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01085.html

[4] The setroubleshootd daemon listens for AVC denials and passes them through a series of plugins to analyze the audits and report what has been prevented. Suggestions are made on how to fix denials. On the client side sealert provides either a GUI or plain CLI interface which can connect to either the local machine or to a remote setroubleshootd. The daemon can be configured to send email alerts. Making changes to system policy can be done in a variety of ways. The aforementioned sealert often suggests a simple CLI sequence to run. The older CLI audit2allow and audit2why tools respectively generate fixes based on the audit logs and explain them. semanage allows changes to be made on the fly to SELinux policies and system-config-selinux also allows boolean selection among pre-written policy options and the easy changes of ports or filecontexts.

[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01087.html

[6] A web framework written in Python which is widely used in Fedora Project infrastructure.

[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01093.html

A substantial chunk of the rest of the discussion hovered around the topic of whether some button(s) should be added to make it easier for the user to ignore the problem. Similar ideas had been floated (see AlanCox's and JamesMorris's comments in FWN#133, ref 7&8 [8]) earlier and AhmedKamal made[9] a good summary of them. He suggested that an AVC denial would present two buttons: "AutoFix" would try to enact the recommended fix stored in the database; and an "Exempt" button which would allow the offending application to run unrestricted. The latter especially was intended to prevent users from just switching off SELinux entirely. ArthurPemberton and StewartAdam thought[10] that this was exactly the wrong approach, with Arthur being reminded of MS Vista users automatically clicking "allow" and Stewart commenting "The idea of this is to get users to report what's going wrong and get it fixed in the policy instead of exempt/disable which defeats the purpose and trains the user to hit "Exempt" without reading anything." Ahmed took the point and made the modification that the "Exempt" button would only work once-per-launch. He argued this would allow the user to get work done but still preserve the incentive to get the problem fixed. DaveAirlie appeared[11] somewhat upset at the idea, arguing that this was "NO NO NO ... DOING IT WRONG."! Taking a cue from the implicit messages of the iMac vs. Windows television advertisements and the successful model of kerneloops he insisted that users should "[never be involved] in the mess other than asking for opt-in [...] The user is not going to have a freaking clue wtf exempting means." Instead he suggested that pinging a remote server to ask for an updated policy would be superior.

[8] http://fedoraproject.org/wiki/FWN/Issue133#SELinux.Eats.Babies.2C.Confines.Wives.2C.Gives.Birth

[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01089.html

[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01092.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01101.html

Replying specifically to the idea of an "Exempt" DanWalsh noted[12] that there were such policies (called "permissive domains") now available in Rawhide. He went on to restate the problem that "Teaching people to press a button to tell SELinux to disable protection [because of AVCs that don't really block anything will get them to disable it when a real attack comes along." Instead the SELinux developers are concentrating on eliminating many of the false AVCs and one of the recent changes towards this end is the addition of a new access permission "open". JamesMorris added[13] that he had written about this work, as implemented by EricParis, in his livejournal: "Until now, opening a file under SELinux invoked the same permission checks as the intended operation on the file, such as read, write, execute and append. There was no separate "open" check: opening a file for write, for example, was considered by SELinux policy as equivalent to actually writing to the file. Experience has shown that this approach is not ideal for handling cases such as IO redirection via the shell, because policy writers cannot usefully guess where users will send redirected output."

[12] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01091.html

[13] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01170.html

DanWalsh, in response to questions from ArthurPemberton, listed[14] the private information contained in an AVC denial as "Hostname, filename, potentially username, rpm information. What apps they are running."

[14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01132.html

Dan was also concerned that any new upstream reporting only occurred when setroubleshoot had been unable to find a suggested fix in its database. He reported that many bugzilla entries filed against him appeared to indicate that users did not even attempt the actions indicated as potential fixes by setroubleshoot. ArjanvandeVen suggested[15] that setroubleshoot should just make those changes. DavidTimms wondered whether suggesting such "let this happen anyway" actions to users should be considered risky and not dissimilar to Ahmed's "Exempt" and "FixMe" buttons. He also listed several means by which he considered SELinux could be improved. DanWalsh replied[16] that many of these desired capabilities were already present in SELinux but appeared to ignore the behavioral similarities argued by David.

In response to further questions from ArthurPemberton it seemed[17] that the preferred mode for such a tool would be to suggest installation of any available updated policies either via PackageKit offering to install them or a "yum update".

[15] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01193.html

[16] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01138.html

[17] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01151.html

Process Wakeups and Energy Efficiency

UlrichDrepper posted[1] a systemtap script which revealed a list of applications which cause wakeups due to timeouts. He noted that "Programs should be woken based on events. They shouldn't poll data (which is what usually happens after a timeout)" and requested that package maintainers for the programs in the list try to help solve the issue. The Flash npviewer was clearly the worst offender. The creator of the PowerTOP program, ArjanvandeVen wondered[2] why this work could not have been done using PowerTOP.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00921.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00931.html

MatthewGarrett thought[3] that polling was inevitable for many applications but that the Glib timer function g_timeout_add_seconds[4], which allows a function to be called at repeated intervals until it is automatically destroyed, could be used to do this at low frequency. It turned out[5] that this was exactly the approach which ArjanvandeVen had taken. HaraldHoyer thought that this was non-ideal as it did not sync globally and while Matthew agreed that kernel support would be needed DavidWoodhouse speculated[6] that tackling the problem per-thread instead of per-event might be possible.

[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00938.html

[4] http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html#g-timeoutadd-seconds

[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00962.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00968.html

NilsPhilippsen added[7] that it should be possible to use IMAP IDLE to fix mail clients and servers that polled too frequently.

[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01032.html

RichardHughes quickly jumped[8] in to report a fix for his PackageKit problem but was less sanguine that GNOME Power Manager could be fixed quite so easily, although there was an expectation that Xorg would fix things by sending out a notification of changed DPMS state.

[8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00948.html

DanielBerrange provided[9] some evidence that the apparent problem with libvirtd was actually due to DBus sending unrequested signals every six seconds. When DanWilliams took a look[10] at NetworkManager's contributions and explained some problems were due to the ipw2200 drivers waking up all WEXT listeners every four seconds and others were due to the presence of bogus rfkill switch events in HAL Daniel connected[11] the dots and said "Ahhh, so that's probably what's causing /usr/libexec/hal-ipw-killswitch-linux to be run every 6 seconds, which in turns causes any app connected to DBus system bus to be send a signal every 6 seconds and thus causes all the hits against libvirtd - and a fair number of other apps in that list too." DanWilliams responded that it was possible, but that it might be worth checking to see if D-Bus signal filtering was being done properly. The forthcoming 2.6.27 kernel was also said to contain the appropriate patches for rfkill which would help solve the problem.

[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00973.html

[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00976.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00978.html

Problems with PulseAudio were guessed by LennartPoettering to be due to the aforementioned Flash player npviewer opening audio streams and never closing them which in turn caused PulseAudio to keep the device open. Again there was a promise of future improvement as Lennart mentioned that the version of PulseAudio in rawhide should not generate any wakeups when completely idle.

It would seem that Ulrich's initiative may yield some useful improvements.

Nodoka Notification Theme a Fedora 10 Feature

MartinSourada asked[1] for help determining whether his plan to provide a beautiful new notification theme for Fedora 10 counted as a "Feature" (see FWN#135 "New RPM Sparks Exploded Source Debate refs 10-20 for recent discussion of the Feature process.) The notification daemons are responsible for popping up small, dismissable windows informing the user that certain events have occurred[2][3].

[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00842.html

[2] http://freedesktop.org/wiki/Specifications/systemtray-spec

[3] http://developer.gnome.org/doc/guides/platform-overview/platformoverview.html#notification-area

Martin stated that the public test release had been available for three months and no issues had been reported. He explained how to obtain the new theme from Koji and how to make it available to the system. After encouragement from RahulSundaram that such a visible change should be considered a feature Martin created a feature[4] page in the wiki. Further feedback from Rahul resulted[5] in the addition of screenshots and a Test Plan section.

[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00901.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00908.html

WillWoods wrote[6] a concise and informative overview of what was expected from Test Plans.

[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00912.html

Mono Beta

PaulJohnson announced[1] that a new beta of mono was about to hit the servers and would probably break a number of things. Also of note was the change of license to MIT for Mono-2.0.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01123.html

DavidNielsen was excited and wondered if this would be pushed into Fedora 8 and Fedora 9 once any obvious breakage had been fixed. BillNottingham did not think 2 that "breaking the entire ABI and licensing of mono in released distros is a *good* thing. Especially Fedora 8." David expressed the advantages of pushing out one big update with a completely revamped stack to which WillWoods replied[3] that it made more sense to wait for Fedora 10's release in three months' time. David returned[4] to the idea that "having the same Mono throughout our releases is easier to maintain [and] pushing newer versions of the stack will enable us to support applications more widely across the stack." He suggested shipping a Fedora 9 preview release and drew a parallel to the situation with KDE-4.1 and their QT libraries. KevinKoffler disputed[5] the parallel as "Qt-4.4 and KDE-4.1 aren't breaking binary compatibility[.]"

[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01156.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01158.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01160.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01163.html

PaulJohnson explained[6] that until all the breakage had subsided only Rawhide would see the new beta "To me, rawhide is there for exactly this purpose - a testing ground to see how much is broken before pushing to stable." JeffSpaleta wondered[7] what the purpose of "updates-testing" was in that case.

[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01189.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01195.html

Policy On Non-Responsive Maintainers

The issue of non-responsive maintainers was aired[1] when PatriceDumas suggested a new policy designed to force maintainers to answer "easy fix" bugs or orphan packages. While Patrice worried that it might look rude he emphasized that the intent was to spread co-maintainership and obtain quicker bugfixes. While most contributors acknowledged the intent behind this they saw myriad problems.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/thread.html#00796

EricSandeen quickly raised[2] the problem of defining an "easy bug". AndrewBartlett thought[3] that this was potentially just "a stick to hit a stressed developer with - and surely developers under external stresses, who do not maintain Fedora packages as their day, job will be the ones most likely to have this stick waved at them. Their re-action may not be the one they or you want in the short and long term."

[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00745.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00845.html

The issue of whether or not a fix had to, or could be, determined as correct was also seen[4] as a problem by BillNottingham and JesseKeating.

A very detailed and thoughtful response from MichaelSchwendt to MatejCepl outlined[5] the problem of increasing the volume of bureaucracy and email dealt with by maintainers. It's worth reading to understand the stresses mentioned by other posters including AdamJackson and NigelJones who described[6] typical volumes of email which they faced. Adam added that anyone was welcome to help him fix bugs. Michael suggested instead that there be "a policy for package maintainers to respond to specially marked tickets from fellow fedora contributors in a timely manner. And if that results in tickets which are still not answered, timeout periods can be applied and give contributors the opportunity to prepare a test update (and only a test update!)." JesseKeating liked[7] the idea and added that SIG meetings could help to triage bugs.

[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00894.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00937.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00856.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00939.html

HansdeGoede thought[8] that it would be better to address the problem of how to allow others to help make easy fixes. He argued that it ought to be possible to use ACLs to allow "easy fixes" to be committed by anyone with CVS extras permissions if a developer has allowed it. Patrice replied[9] that the cases which he was concerned about were not owned by maintainers who would allow such changes.

[8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00757.html

[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00764.html

Another voice against too much bureaucracy was that of RichardHughes who queried[10] "Surely the maintainer in question knows the package well enough to decide whether to merge patches? For instance, I might push a patch upstream and hold off applying it to fedora as it's trivial and will get updated at the next version bump of my package in a few weeks" to which KevinPage replied that there were examples where the timeframe was closer to numerous months. JeffSpaleta pushed[11] the idea of putting "packages under the purview of maintainer teams who are comfortable working with each other and care about the packages in question regardless of who the primary owner of a package is. SIGs are the obvious construct here[.]"

[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01004.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01008.html

Refinement of the policy was carried out between RahulSundaram and ToshioKuratomi. Toshio wanted[12] to make it possible for a co-maintainer to be added in egregious cases to help ease the burden on the original maintainer.

[12] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00918.html

The emphasis on orphaning packages aggressively over a short time-period was questioned[13] by DanielBerrange. He suggested that adding co-maintainers would be a better strategy. RichardJones added[14] the disturbing spectre of "Wikipedia-style deletionism" occurring.

[13] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00946.html

[14] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00982.html

Some balance was added by a post made[15] by KevinPage which conveyed the perspective of frustrated bugzilla posters who find their easy fixes ignored. Kevin explained his experience with trying to get his patches applied and wondered whether it was a consequence of the new emphasis on pushing bugfixes upstream. He finished with "One conclusion from this thread is that it's accepted that some maintainers don't follow bugzilla. Not condoned, but accepted as a reality. That's clearly incompatible with asking users to report their problems in bugzilla."

[15] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01005.html

Artwork

In this section, we cover the Fedora Artwork Project.

http://fedoraproject.org/wiki/Artwork

Contributing Writer: NicuBuculei

The End of Round 1 for Fedora 10 Themes is Near

On the Fedora Art list, MairinDuffy proposed [1] the end for the first round of the theme named "battle" [2] for Fedora 10: "We've an overwhelming number of proposals for F10 now. Should we close new proposals for F10 so we don't have our focus spread across too many ideas? Also, we should probably go through the proposals missing the requirements and remind the proposers to fully fill them out or pull them."

And for Ian Weller's proposal [3], a deadline is set for July 21st, enough time for people to prepare their proposals.

[1] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00182.html

[2] http://fedoraproject.org/wiki/Artwork/F10Themes#List_of_Submissions

[3] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00183.html

Icons for applications and a web application

RobinNorwood introduced [1] an amazing web application [2] which allows users to search for, browse, comment on, and rate software applications available for Fedora and asks a series of questions about application icons: "So I've been looking at importing the icons for applications for the Fedora Applications web site [2]. We'd like to show an icon next to a given application, preferably the one the user would see in the menus after installing said app. This is, of course, complicated. I can currently look for icons inside each rpm in Fedora, specifically the rpm providing the application we're interested in, and the various *-icon-theme rpms."

And a little later he added [3] more details about how it will work, identifying the user's icon theme and using matching icons: "To do the actual package install, we'll be using a browser plugin (probably) which will probably send us some limited information - like what version of Fedora the user is running, for instance. It might be possible to include the current theme in this info."


[1] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00171.html

[2] https://fedorahosted.org/amber/

[3] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00198.html

Plans for an Improved Nodoka in F10

MartinSourada revealed [1] his plan for an improved Nodoka GTK2 theme engine in Fedora 10: "I am thinking about improving the nodoka gtk engine looks in the next release and adding some configuration options. Therefore I am asking here, if you have ideas, requests, ... what I might implement. Today I started sketching new nodoka gradient (used in e.g. buttons), which is basically an evolvement of the current one which will be available as a configuration option."

He asked for ideas and outlined the hard work needed, with the caveat of the job having a slight probability of not making Fedora 10: "As you can see it's rather a lot of work, and thus there is a possibility it will not be in Fedora 10, though certainly I make it in time for Fedora 11 (I promise :-p)."

[1] https://www.redhat.com/archives/fedora-art-list/2008-July/msg00211.html

Security Week

In this section, we highlight the security stories from the week in Fedora.

Contributing Writer: JoshBressers

Security Circus

By far the most entertaining story from last week was Linus giving a few choice quotes[1].

He does get some things right, but there's still the very real fact that security flaws let people do things they shouldn't be able to do. This adds a certain amount of danger and does require more attention than some other flaws. A nice comparison is automotive recalls. If there are two problems, one is a broken cup holder, the second makes the car explode, which do you think they'll do a recall for?

[1] http://news.cnet.com/Torvalds-attacks-IT-industry-security-circus/2100-1007_3-6243900.html

Principle of Least Privilege

Steve Grubb has a nice interview up on SearchEnterpriseLinux.com[1].

It offers some hints into some of the intresting things that have happened and can be expected in the SELinux space.

[1] http://searchenterpriselinux.techtarget.com/news/article/0,289142,sid39_gci1321374,00.html

Security Advisories

In this section, we cover Security Advisories from fedora-package-announce.

https://www.redhat.com/mailman/listinfo/fedora-package-announce

Contributing Writer: DavidNalley

Fedora 9 Security Advisories

Fedora 8 Security Advisories

Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Issue134&oldid=40762"