(Imported from MoinMoin)
m (1 revision(s))
Revision as of 16:28, 24 May 2008
Fedora Weekly News Issue 83
Welcome to Fedora Weekly News Issue 83 for the week of April 8th through April 14th, 2007. The latest issue can always be found here .
In this section, we cover announcements from various projects.
Fedora Wiki Accounts
MikeMcGrath announces in fedora-announce-list - In response to our wiki woes, we have decided to delete all wiki accounts that are not watching any pages and are not in the EditGroup . This will help speed page saves up because of the way moin iterates over users to see who to notify. Those wishing to keep an account should simply sign up again.
Please direct any questions to admin at fedoraproject.org
Fedora-Extras-List going to be closed end of this week
ThorstenLeemhuis announces in fedora-extras-list - fedora-extras-list will thereby get closed soon, probably on Friday or Saturday this week; no further posting will be possible here.
fedora-devel-list will be the mailing that acts as the direct successor for fedora-extras-list; all subscriber on this list that are not yet on fedora-devel-list got invited there some minutes ago.
Fedora Development (2007-04-11) Live i386 image available
JeremyKatz announces in fedora-test-list - I've put up a copy of a live CD image based on the current Fedora Development tree as of today for those that are interested in some pre-test4 testing.
For package bugs, please file them against the specific package. For more general bugs with the LiveCD, you can file them against the LiveCD component for Fedora Core, version devel.
In this secton, we cover a highlight of Planet Fedora - a aggregation of blogs from world wide Fedora contributors.
Fedora's Pidgin Plan
WarrenTogami points out in his blog - The Gaim project signed a trademark settlement with AOL, and will be changing their name to Pidgin.
Upstream is planning on a pidgin-2.0.0-beta7. They are trying to settle a pref migration blocker before cutting this beta release. This beta7 will give Fedora critically important window, where we must move quickly to prepare for the final 2.0.0 release. We must fix all dependencies by fixing up and renaming the numerous gaim-* plugin packages, and be sure the entire collection automatically upgrades cleanly with yum. That should smoothen our upgrade into 2.0.0 that is expected soon thereafter. When we are satisfied with the 2.0.0 final + all plugin packages in F7, we will do the same to FC6.
Spread Open Media
NicuBuculei points out in his blog - We, at the Open Clip Art Library , together with Xiph.org are hosting a contest for creating a logo and maybe a mascot for Spread Open Media. All submissions should be in SVG format and released as Public Domain, so they cam become part of the Open Clip Art Library. The contest started on 10 April 2007 and will end on 05 May 2007. Using those contributions as a base, a lot of materials like banners, buttons, badges, icons, fliers, t-shirts will be created.
In this section, we cover the problems/solutions, people/personalities, and ups/downs of the endless discussions on fedora-devel-list.
MattMiller noticed that gnome-user-share was trying out some new tricks  and wanted it to stop. Specifically he questioned the wisdom of a Gnome desktop environment needing to include httpd because g-u-s is in the group and works by using WebDAV. JesseKeating pointed him upstream and argued that it was safe because a user had to consciously switch it on, to which JonCiesla agreed  "+1. If the nailgun is unplugged, in the box, and the nails are in a separate box, why not ship them? Provide the functionality, but in a safe manner. Is this not the current state?". Further discussion led to the idea  of breaking out the apache server config from the g-u-s stuff. NicolasMailhot wondered why the gnome-daemon was not able to just drop the right file into /etc/httpd/conf.d and OwenTaylor tried to get to the root  of Matt's objections.
Mgetty Still Maintained ? Or, How To Patch And Rebuild From Source RPMs
In a redirected question  from fedora-list, Don Russell wondered if mgetty was under active maintenance. Don had opened a Bugzilla report and noted that there were year-old updates available that weren't packaged for FC6. Dragoran and Dexter helped him out with obtaining the source code   so that he could build a fixed version himself.
Administrative Tools Emancipated From GTK+ Tyranny
An enquiry  from a potential new developer led to suggestions of which projects might profitably be attempted. Noting his C/Qt experience KevinKofler suggested  helping with KDE4 packaging. OttoRey was led to wonder  whether there were clear mini-RFCs or other specs for dependency checking. Vlad suggested  improving KDE integration by writing KDE versions of the administrative tools, which all have GTK+ frontends, but no KDE GUI frontends. RexDieter then drew attention  to
which does much of Vlad's extensive list. Rex was seeking  a co/maintainer for the package, which is already in the review process. MattMiller observed  that an important side-effect of rewriting the tools so that there's a GUI-independent back-end will be that root-privileged operations will also be taken out of the GUI front-end.
The issue was further discussed in a separate thread  , with DavidZeuthen enlarging  on Matt's point about privilege separation and arguing cogently for people to take a look at PolicyKit instead of just Qtifying apps which are currently GTK+ based. JaneDogalt suggested  that a scriptable backend would be very welcome. Later NicolasMailhot and RichardHughes discussed the implications  for embedded systems and Richard mentioned the OHM project.
Readahead Lists Need an Update For Rawhide?
The prolific MarkG85 noted  that
was apparently not in use for Firefox-2.x in rawhide and that it was very beneficial for Firefox-1.5.x, also that it might be nice to add the default gnome-panel applets. ZakKarel agreed  and said that he'd generate updated readahead lists close to the freeze. Zak also pointed out the useful readahead-collector tool  which allows the generation of customized lists for a particular machine.
DELL firmware packaging Saga Continues. A Bug Gets Squished In rpmUtils.updates.py
In today's episode we ask "Can YUM Upgrade noarch to a specific arch?" Acting upon feedback previously received  MichaelEBrown (Dell's maintainer of firmware packages) was  still seeking a clean, approved way of packaging the firmware. It seemed from his tests that Yum failed (in FC6) to update the firmware-addon-dell packages that he had converted from being noarch. MichaelSchwendt posted a  counter-example. Reports from TillMaas led MichaelEBrown to investigate  whether this was specifically a problem in updating from noarch -> x86_64 as the noarch -> i386 seemed to work. SethVidal and MattMiller both tried to help, and later MichaelEBrown reported  that an IRC conversation with Seth suggested that it was a bug in rpmUtils.updates.py which only reared its head on multilib systems and that there was a temporary work-around. Seth soon posted a patch to the open bugzilla which MichaelEBrown confirmed as a fix  .
When Will iwlwifi Work?
A polite  enquiry from ThomasBaker noted that iwlwifi had been in the kernel for a bit, didn't work and it would be good to know if users should wait to test fixes, or just go and install the alternate ipw3945 driver. AndyGreen found that it worked on a WPA network, TomLondon found that it didn't  (and was testing with each fresh Rawhide kernel and then installing ipw3945). JoshBoyer rebuffed  the idea of using JohnLinville's custom kernels because the point was to test rawhide. JohnLinville and others noted that unless people actually try the linville packages then it will be difficult to determine what works and should be propagated into rawhide as a fix. John confirmed to RichardHughes that upstream would be getting an iwlwifi fix from him soon  .
After all this there was some confusion about what the "Linville test kernels" were. Dragoran clarified the matter in a response  to ThomasBaker, pointing out a bugzilla in which JohnLinville had rolled up some patches written upstream after Dragoran had prodded them with a pointy stick. The Linville page also describes these kernels as Kernels available here are explicitly NOT official Red Hat kernels. These kernels are for testing and/or experimentation. There is absolutely no guarantee that any patches present in these kernels will actually be made available either upstream or as part of any official Red Hat kernel. However testing is of course appreciated and obviously affects what goes into rawhide.
As a sidenote, EricMagaoay and Nicolas (kwizart) noted that the firmware for zd1211rw_mac80211 seemed to work, was under review and needed the wireless-tools package to be updated to stay in sync  .
Where are VirtualProvides Documented?
A question  about the difference in meaning between "Provides:MTA" and "Provides:smtpdaemon" was posed by VilleSkyttä. The question seemed to have been considered  deeply by ManuelWolfshant, as maintainer of ssmtp, who along with PatriceDumas now believes  that the problem is to do with mdadm having an incorrect requires.
JonathanUnderwood noted  that his proposals for TeX dealt with the issue of virtual provides.
JesseKeating asked whether this in fact concerned the "alternatives" system and Ville argued  that it did, but that was a rewording of his original question. Ville and Patrice seemed to cohere on a solution  which involved removing mta/MTA from the "Provides" (but not touching the alternatives namespace) and using /bin/mail as a "Requires", and sifting through packages which have a "Provides: smtpdaemon" and fixing them.
RFE: Mirror/server Do Not Remove Old Kernel From Updates
GilboaDavra posted an RFE inspired by a late-night / early-morning tale of woe in which a completely cleaned yum cache and an "rpm -e" left him with a dead machine. His suggestion  is that the last five kernels should be left on mirrors so that people could revert if necessary.
LeszekMatok was unsympathetic to what he perceived as a support request for proprietary software (VMware), but Gilboa wasn't having any of it  . TonyNelson thought that keeping older versions of the kernel about was a good idea, prompting JesseKeating to ask for recent sightings of the mythical beast Unlimited Storage  . Gilboa stuck to his guns and brought specific figures into the picture  to show that the last five released kernels for one architecture would only consume 400MB. Interestingly, Jesse responded that post-merge (once Koji is in use) these should be available 
Three Changes to Packaging Guidelines: 1. Binary Firmware; 2. Post-Release Naming, 3; BuildRoot Prepping
1. TomCallaway (spot) posted a  that the License tag for non-modifiable firmware should be changed. This led to a query as to whether madwifi-ng could be included in Fedora. ThorstenLeemhuis responded  with the conditional information that it would appear not to be the case, as it was more like a static library than a firmware. This interpretation was confirmed by JoshBoyer.
2. A  new definition of a "post release" package and specific attention to non-numeric versions was posted. There was no @fedora-devel discussion of this change.
3. An additional subsection now  prepping the buildroot properly. TomLane thought it was a bug that each and every specfile had to do this. In response  JesseKeating acknowleged that it was a bug but thought there were many more important things upon which rpm developers should work. MichaelSchroeder of SUSE had a helpful suggestion  .
Further discussion between TomCallaway, PanuMatilainen and others  centered around the benefits of fixing the rpm bug, thus completely breaking older RPM packages.
Bugzilla Policy: Should FC4 Bug Filing Be Banned?
Some thought it was a joke  , but MattMiller was deadly serious  . The problem is that there is no way to not receive reports still automatically generated for FC4 (which should really be turned into petfood). JesseKeating replied that there was a plan  to create a new "product" which only got current (F7 and rawhide) bugs. It would then be possible to only receive bug reports for that product. MikeWiktowy worried  that this would only buy a year's grace, leading Jesse to clarify that what he wanted was to see unsupported releases in one product, and only the current release and development in the new Fedora product.
MattMiller was also led to clarify (with tears almost audible in his email) that people were still filing bugs against FC5  . Matt was then invited to join the FedoraQA meeting for further discussion  .
In this section, we cover Fedora Maintainers.
"FC6" in Fedora 7
With FWN's inaugural coverage of the fedora-maintainers-list, we begin with the presence of the "fc6" disttag in some Fedora 7 packages. Rahul Sundaram had expressed concern over this occurring and had suggested rebuilding the packages to prevent this.
Packaging Guideline Changes
The Fedora Packaging Committee had also approved a change to the packaging guideline for the license tag and naming firmware packages to <foo>-firmware. Other guidelines changes made over the past week include those for post release naming, prepping buildroot for %install, and UTF-8 filenames.
Fedora 7 Test 4 Freeze
Jesse Keating also reaffirmed that the Fedora 7 Test 4 freeze will start next Tuesday (April 17). The freeze for Test 4 also marks the point at which only bug fixes should enter Fedora 7.
In this section, we cover the Fedora Documentation Project.
Fedora 7 Desktop User Guide
JohnBabich has come forward and volunteered as the lead writer for the Desktop User Guide in the build up to Fedora 7.
Throughout the week there has been a lot of discussion about the Desktop User Guide and the direction it should be taken in: the use of screenshots ; making the document more task orientated and the best layout to achieve this ; providing coverage of alternative desktop environments and the best approach to achieve this .
As reported last week PaulFrields made a proposal of creating a system that would allow for the quick translation of common snippets of documents to many different languages using XML. KarstenWade replied to this and suggested that it might be nice if some more people with good XML knowledge would get involved with this aspect of the project. If you are interested in XML I'm sure you'll be made very welcome by the documentation team!
This section, we cover the news surrounding the Fedora Translation (L10n) Project.
Release Notes Deadlines
PaulFrields sent a note to the list announcing the deadline for translations (2359 UTC 14 April 2007). The next and final POT update is 21 April 2007 and the absolute deadline for translation of PO files is 2359 UTC 2 May 2007.
More on Entities
PaulFrields announced the change back to "xml2po -e" unfortunately this will require some extra translation work. Thanks to all the translators for hanging in there with the recent changes, we do appreciate it!!
In this section, we cover Fedora Infrastructure Project.
MikeMcGrath revisited the email address issue in which he pointed out that problems have arisen with the current firstname.lastname email address convention (sendmail and postfix can't handle some of the characters). He proposed that email addresses are setup as the persons account name and also suggested the removal of firstname.lastname addresses. His proposal was agreed upon with the allowal of firstname.lastname addressses in special cases.
Ah, yes, the wiki. This week the wiki provided the team with some challenges and no doubt Fedora users noticed the couple of website outage and yum availability interruption. MikeMcGrath posted this summary of the weeks efforts, which included some Apache and Moin reconfiguration. Thanks to everyone that pitched in and helped throughout the week and to the Fedora users for being patient. (Fedora currently has the largest implementation of Moin/Wiki so we, as always we are on the bleeding edge!)
In this secton, we cover Fedora Artwork Project.
Fedora Underground Pilot
JohnBaer announced that, after previously considering starting a page similar to Google's start page but with the emphasis on Fedora, he now has a pilot design. The page hosts quick links to many Fedora related websites, a customized Google search and links to other sites he considers useful for Fedora users.
He hopes to spread the word and track the number of hits up to the release of Fedora 7 when he will review the situation and consider developing it further.
LuyaTshimbalanga has submitted some draft icons based on the keyboard icon design discussed last week; these include a character map icon and a keyboard-shortcuts icon . As well as these two keyboard related icons she also submitted new drafts of the Add/Remove Applications icon.
Security Week in Review
In this section, we highlight the security from the week in Fedora.
In This Week
Remarkably little happened this week in the security universe. I wonder if this is the result of the fabled Microsoft Patch Tuesday, and researchers not wanting to lose attention to the pending flood of stories about all the windows patches. The general idea behind this is that rather than release updates when they're ready, Microsoft will hold them until the second Tuesday of every month. I'm honestly not sure how I feel about this, but in general it doesn't work in the open source world. We generally have little control over when many security updates are released. If an open source project wants to release an update on a Sunday night, there is nothing stopping them from doing that. This of course isn't ideal for most people, but it's one of the many issues with the rather chaotic world of open source security updates.
Schneier on Security
This story from Bruce Schneier's blog made me immediately think of open source: U.S. Government Contractor Injects Malicious Software into Critical Military Computers  . This sort of thing probably happens more than anybody will ever admit, but it's likely a lot harder to pull of when your development is conducted in an open and transparent manner. It's also nearly impossible to prove in a closed source system. Even if such a flaw is found in a closed source system, it would not surprise me if many vendors would try to keep such information hidden. It's certainly not in the best interest of a vendor to let news of a back door go public.
On this note though, what do projects do to stay secure? Is there anything preventing a disgruntled project member from causing harm (even if it is found immediately)? Apache.org had a slightly similar experience with this some time ago: Apache.Org compromise report, May 30th, 2001  They handled it about the best any project could.
A memory leak flaw in FreeRADIUS was found . The flaw itself isn't really noteworthy, but it does give me a good opportunity to note that there is often a fine line separating old fashioned bugs and security flaws.
Many software applications contain memory leaks and it's usually not a big deal. I don't suggest one should ignore a memory leak since it is a bug, but not all memory leaks are security flaws either. However they are serious problems with long running applications such as daemons. There are a number of bugs that can be considered a security flaw given the right circumstances. One of the jobs of the security team is to investigate these bugs and sort the chaff from the wheat. Another favorite is a user assisted crash. If a remote attacker can make something like FreeRADIUS crash, it's a security flaw. If a remote attacker can make Firefox crash, we call it a "don't do that again" bug.
Mark Cox had a most interesting blog posting this week: Information Sources . Most people don't really worry about where security flaws come from, but it is most interesting when you're on of the lucky people who have to try to make sense of all this madness. It's nice to know this since we know that it's worth the effort to maintain a healthy relationship with upstream projects and various researchers. It is a goal of the Red Hat Security Response Team to work with anyone who approaches us with a flaw. The goal is to keep the users as safe as possible, which can occasionally make our lives a bit painful when dealing with difficult projects and researchers, but no doubt it's well worth it.
Security and Updates
In this section, we cover Security Advisories and Fedora Updates from fedora-package-announce.
- FEDORA-2007-422: [SECURITY] Fedora Core 5 Update: libXfont-1.2.8-1.fc5
- FEDORA-2007-423: [SECURITY] Fedora Core 6 Update: libXfont-1.2.8-1.fc6
- FEDORA-2007-424: [SECURITY] Fedora Core 5 Update: xorg-x11-server-1.0.1-9.fc5.7
- FEDORA-2007-425: [SECURITY] Fedora Core 6 Update: xorg-x11-server-1.1.1-47.8.fc6
- FEDORA-2007-426: [SECURITY] Fedora Core 6 Update: libX11-1.0.3-7.fc6
- FEDORA-2007-427: [SECURITY] Fedora Core 5 Update: libX11-1.0.0-4.fc5
- FEDORA-2007-433: [SECURITY] Fedora Core 5 Update: kernel-2.6.20-1.2312.fc5
- FEDORA-2007-432: [SECURITY] Fedora Core 6 Update: kernel-2.6.20-1.2944.fc6
Fedora Core 6 Updates
- FEDORA-2007-402: Fedora Core 6 Update: yum-3.0.5-2.fc6
- FEDORA-2007-418: Fedora Core 6 Update: samba-3.0.24-4.fc6
- FEDORA-2007-419: Fedora Core 6 Update: brltty-3.7.2-2.1.fc6
- FEDORA-2007-420: Fedora Core 6 Update: iputils-20070202-2.fc6
- FEDORA-2007-396: Fedora Core 6 Update: dhcp-3.0.5-4.fc6
- FEDORA-2007-340: Fedora Core 6 Update: system-config-printer-0.7.52.1-2.fc6
- FEDORA-2007-346: Fedora Core 6 Update: ghostscript-8.15.4-1.fc6
- FEDORA-2007-429: Fedora Core 6 Update: selinux-policy-2.4.6-54.fc6
- FEDORA-2007-437: Fedora Core 6 Update: iputils-20070202-3.fc6
- FEDORA-2007-431: Fedora Core 6 Update: lftp-3.5.9-0.fc6
- FEDORA-2007-377: Fedora Core 6 Update: subversion-1.4.3-2.fc6
- FEDORA-2007-439: Fedora Core 6 Update: tar-1.15.1-25.fc6
- FEDORA-2007-441: Fedora Core 6 Update: tetex-3.0-34.fc6
Fedora Core 5 Updates
- FEDORA-2007-421: Fedora Core 5 Update: samba-3.0.24-4.fc5
Events and Meetings
In this section, we cover event reports and meeting summaries from various projects.
FESCo Meeting Summary: 2007-04-05
Packaging Committee Meeting 2007-04-10
Ambassadors Meeting Minutes 2007-04-12
This document is maintained by the Fedora News Team . Please feel free to contact us to give your feedback. If you'd like to contribute to a future issue of the Fedora Weekly News, please see the Join page to find out how to help.