fp-wiki>ImportUser (Imported from MoinMoin) |
m (1 revision(s)) |
(No difference)
| |
Revision as of 16:25, 24 May 2008
Fedora Weekly News Issue 99
Welcome to Fedora Weekly News Issue 99 for the week of July 29th, 2007. http://fedoraproject.org/wiki/FWN/Issue99
In this week, we have announcements on Fedora 8 Test 1, Virtual FudCon and our new column called AskFedora.
Speaking of AskFedora, we received several good questions including License Issue, Backups and Problem with Pup.
In Developments, we have continuing discussions on CodecBuddy, Yum, Kmods, RPM Roadmap, KDE4 Status and more.
To join or give us your feedback, please visit http://fedoraproject.org/wiki/NewsProject/Join.
Announcements
In this section, we cover announcements from various projects.
Contributing Writer: ThomasChung
Fedora 8 Test 1 slipping
JesseKeating announces in fedora-devel-announce[1] ,
"Due to an ongoing issue with booting many Dells (and some Toshiba) systems via CD, we've had to delay the release[2] of Test1. The good news is that we've found a solution and a new kernel is building in koji as I type this. The bad news is that there is not enough time to get the output of that build and spin it into a set of trees for release on Thursday. As such, we're slipping the release to Tuesday of next week, August 7."
[1] https://www.redhat.com/archives/fedora-devel-announce/2007-July/msg00012.html
[2] http://fedoraproject.org/wiki/Releases/8/Schedule
Interested in holding a session at Virtual FudCon?
JeffSpaleta announces in fedora-advisory-board[1] ,
"I am putting a draft together for the Online UnFudcon aka (Virtual Fudcon)[2] . I've already contacted many of the F8 Feature drivers concerning presenting something and the draft includes those items for which there was interest in holding a presentation. If you are part of a fedora subproject that would like to hold a session as part of this virtual conference, please email me and edit the draft page adding your session topic accordingly."
[1] https://www.redhat.com/archives/fedora-advisory-board/2007-July/msg00218.html
[2] http://fedoraproject.org/wiki/JefSpaleta/VirtualFudCon
Ask Fedora: Fedora Weekly News Column
RahulSundaram announces in fedora-announce-list[1] ,
"Fedora has a strong community of people helping each other in the forum and fedora-list but have you always wanted to ask a question to Fedora developers but weren't sure whom to ask? A new feature for the next release of Fedora? Any big picture questions of general interest to Fedora users?"
"If so, we have just the right solution for you. Send your questions to askfedora@fedoraproject.org and Fedora news team will bring you answers from the right places to selected number of questions every week as part of our weekly news report."
[1] https://www.redhat.com/archives/fedora-announce-list/2007-July/msg00013.html
Planet Fedora
In this section, we cover a highlight of Planet Fedora - an aggregation of blogs from world wide Fedora contributors.
http://fedoraproject.org/wiki/Planet
Contributing Writers: ThomasChung
Better Fedora Collaboration
JohnPoelstra points out in his blog[1]
"One of my dreams for Fedora came true today. Free audio conference[2] service is being tried out in anticipation of the upcoming Virtual FUDCon[3] ."
[1] http://poelcat.wordpress.com/2007/08/02/better-fedora-collaboration/
[2] http://mmcgrath.livejournal.com/6812.html
[3] http://fedoraproject.org/wiki/JefSpaleta/VirtualFudCon
Come Party With Fedora
JackAboutboul points out in his blog[1] ,
"Hey all you geeks in the valley or those making your way to LinuxWorld Expo SF[2] ! This is an open invitation to come on down and experience Fedora like you've never experienced it before. Heck, come experience open source, open content, free culture and lots of giveaways the way you never have before."
[1] http://feeds.feedburner.com/~r/MadRhetoric/~3/139819960/come-party-with-fedora.html
[2] http://www.linuxworldexpo.com/dev/12/events/12SFO07A
Ask Fedora
In this section, we answer general questions from Fedora community. Send your questions to askfedora@fedoraproject.org and Fedora News Team will bring you answers from the Fedora Developers and Contributors to selected number of questions every week as part of our weekly news report. Please indicate if you do not wish your name and/or email address to be published.
Contributing Writer: RahulSundaram
http://fedoraproject.org/wiki/AskFedora
License violations
Peter A. Shevtsov <webmaster@mera.com.ru> : I know that Fedora is so-called patents and license clear distro, so neither mp3 nor any other proprietary technologies don't work in the base installation. As far as I know, all software included in Fedora is GPLed (v.2 I suppose). So, my question is the following -- what will happen if someone violates license condition? For example, there is a company which provides some open source solutions (like Red Hat Exchange), but it distributes custom built (patched or something like that) RPMs of some software -- for example their own built Apache HTTPD Server -- but do not provide sources and charge money. If I'm not mistaken this is the case of license violation. If so, what can be done in such situation? Are there any punished precedents of GPL violations?
Thanks for writing, Peter, and for bringing us our first question. To clear up some popular misconceptions about copyright and copyright licenses, you might want to take a look at the article from Red Hat Magazine in May 2007[1] . While Fedora News team members are not lawyers, we've all done enough research on licensing to give you what we hope is a pretty complete answer to your question.
All software included in Fedora is free and open source software. The GPL is but one of the many free and open source licensing[2] options available to developers. The example you cite, for instance, is the Apache web server, which is available under the Apache License 2.0 [3] . This license allows licensees to copy and redistribute without requiring them to distribute source, and none of the free and open source licenses can have any restrictions on licensees' rights to charge money for any original work that they produce or derive. Therefore, the cited example is not a license violation for a product built on the Apache web server. It would, however, be a license violation for a product built on software licensed under the GPL (or any of a number of other reciprocative licenses), since the GPL requires the licensee to make source code available for any derivative work if the work is distributed to a third party.
To more directly answer your second question, only a copyright holder has the right to bring an action in case of a violation of a product's license agreement. For a program "Foobar" in Fedora, the copyright holder is the developer of Foobar. (The Fedora copyright statement attributes program content to "Red Hat, Inc. and others" to make clear that Red Hat is the copyright holder for the material it contributes, while "others" refers collectively to all the other copyright holders who contribute or originate other work in Fedora.) The Free Software Foundation has helped developers deal with enforcing GPL [4] in multiple instances in the past and has generally been successful. You can read more about their licensing compliance work in the FSF site [5] . If you're interested or want to raise awareness about GPL violations, the GPL violations website[6] also has several public cases.
[1] http://www.redhat.com/magazine/007may05/features/ip/
[2] http://fedoraproject.org/wiki/Licensing
[3] http://www.apache.org/licenses/LICENSE-2.0
[4] http://www.gnu.org/philosophy/enforcing-gpl.html
[5] http://www.fsf.org/licensing/compliance
Making Backups
s sokol <sokolstephen@yahoo.com> : I am an enduser and having a hard time finding out how to backup to an external hard drive in an orderly and automatic manner.
Fedora has a number of backup solutions available. The cp or tar commands are usually not the most effective way to maintain backups. Most advanced users and administrators recommend a system based on the rsync family of utilities, which allow you -- as the name suggests -- to synchronize two separate storage areas, such as your home directory and an external device or network share.
Keep in mind that file system differences may affect your choice of how to back up your data. Linux file systems such as ext3 have features that cannot accurately be copied directly to the VFAT file systems found on many USB disks, or CD/DVD. However, you can usually write your data as specially-formatted backup files (such as star format) where this information can be safely retained on such devices.
There are dozens of different solutions available. You might want to try one or more of these packages:
pybackpack- A GNOME- and Python-based graphical backup utility; after installation, look in System > Preferences > System > File Backup Managerkbackup- A KDE-based graphical backup utility; after installation look in Applications > Accessoriesrsync- reliable command-line program (tryrsync -Pavy <source> <dest>for example)BackupPC- A complete web-based backup solution that includes scheduling and multiple system handling
Future of RPM
Maxime Carron <maxime.carron@fedoraproject.org> : can i/we have some explanations about future of RPM.
From what i red, - redhat, novell and Co start a merge of their many patches to apply them to the main stream (dec 2006) - but it also exists another branch : www.rpm5.org (from an ex RH-employee) - i heard about openpkg too (which support rpm5.org)
So my questions are : What are the news? What will happen? Will rpm5.org and rpm.org merge? What about openpkg? What about CPM (Community Package Manager)? cf http://www.redhatmagazine.com/2007/02/08/the-story-of-rpm/
Thank you.
After the initial announcement from Fedora Project [1] about renewed focus, Panu Matilainen announced a new release of RPM 4.4.2.1 [2] that includes some cleanups of the codebase, consolidation, and introduction of several bug fixes from Red Hat, Novell and others.
rpm5.org has a different roadmap from rpm.org. Both these branches have their own community of individuals and vendors with a existing common codebase. They influence each other and have shared fixes in various instances. As long as both branches retain compatibility with the RPM spec format, the higher level tools can explore different directions. This freedom is a inherent part of free software.
The Red Hat Magazine article to which your question refers is a short description of some of the history behind RPM. You can read about the rpm.org ongoing roadmap discussions in the last week's report [3] . You can also refer to Max Spevack's thoughts on RPM's and Fedora's future in Linux Weekly News[4] . RPM is the underlying packaging format and a base that Fedora builds upon using Yum and friends, and Fedora will continue to participate in its development for the foreseeable future.
[1] https://www.redhat.com/archives/fedora-announce-list/2006-December/msg00003.html
[2] https://lists.dulug.duke.edu/pipermail/rpm-announce/2007-July/000001.html
[3] http://fedoraproject.org/wiki/FWN/Issue98#head-90b3708648e89def933055ad00d6cb887b9cde0d
[4] http://lwn.net/Articles/237700/
CD Installations of Fedora 7
R. Drew Davis <drewclist@rdd.name> : My old PC has no DVD drive, but Fedora 7 appears to only be distributed on DVD's. Before Fedora 7's release, CheapBytes was accepting pre-orders for Fedora 7 on CD's, but after Fedora 7's release, they e-mailed me to say there wasn't going to be a CD version, so they refunded my money. I asked them why they couldn't make their own custom spin of Fedora 7 on CD's and they said the Fedora license agreement wouldn't let them call the re-spin "Fedora" and that would make it very hard for them to sell any such version. So what should I do?
Fedora provides GNOME and KDE based live images that can be burned to a CD and installed to a hard disk or USB flash. Fedora Live images have a subset of packages from the Fedora repository and some configuration changes suitable for a desktop user. If you are using Fedora on the desktop or laptop, this solution is ideal for you.
You can also install Fedora from a network using a boot or rescue image burned to a CD. Furthermore, you can copy the DVD image to your hard disk and install from that.
CheapBytes or anyone else can very well create custom spins of Fedora 7 on CD's. Since they are not changing any packages in the distribution, they are free to call it Fedora and distribute it. There are other online and retail vendors doing similar custom spins, and the ability to create custom spins easily is one of the primary benefits in Fedora 7. Refer to the Fedora 7 FAQ [1] for more details.
With the merge of Fedora Core and Fedora Extras, the repository has grown to nearly 8000 packages, which takes around 9 GB of storage space. This repository is growing rapidly, with more packages maintained by existing and new contributors. In the next release, the Fedora Project plans to integrate support for additional architectures. Fedora is distributed by hundreds of volunteer mirrors, which would have difficulties mirroring CD variants of all these packages and architectures. The Fedora Infrastructure team is looking for volunteers to integrate Jidgo [2] into the release process of Fedora as a potential solution to this problem. If you are interested in helping, contact the Fedora Infrastructure team[3] for more information. Thank you for your support.
[1] http://fedoraproject.org/wiki/Fedora7/FAQ
[3] http://fedoraproject.org/wiki/Infrastructure
Global changes in Fedora
Martin Jürgens <martin@gamesplace.info> : I have a question to the Fedora Project, namely where global changes can be discussed.
I know that Bugzilla is the right way to report Feature Requests when you exactly know how the new feature should look, but I had a more global idea of making Fedora more end-user friendly without making system admins unhappy (in the way of changing configuration, installation and package managing tools, RHBZ #248259). I hoped that some discussion with ideas would come up in the bug report, but it was not like this. I did not get a single reply.
As you have noticed, Bugzilla is generally very good for reporting specific bugs, but unsuitable for high level discussions that might require project management and participation from multiple contributors. As commented upon in the Bugzilla report, the better place to discuss any changes like these is in the fedora-devel [1] mailing list. If you want a informal chat, the #fedora-devel IRC channel in Freenode is a good place to meet other contributors and exchange this kind of information.
[1] http://redhat.com/mailman/listinfo/fedora-devel-list/
Bugzilla Responses
fred <lazlow@charter.net> : After you file a bug with bugzilla, how do you get a response? I have several bugs filed that have sat there for a long time and have gotten no response. Are the people that are supposed to be looking at these bugs no longer with the project? Are the people who should be working on F7 bugs too busy with F8? The odd thing about it is the responses that I have received were on the bugs that were trivial. The important bugs seem to be ignored. No request for further information or clarification. No anything.
Fedora as a distribution has several thousand packages being maintained, and hundreds of packages being updated daily, and the maintainers involved need to prioritize bug reports. Severe security and bug fixes get higher priority compared to other bug reports. If the problem you reported is not specific to Fedora, you might want to report this problem directly to the upstream project bug tracker or mailing list.
If you do not get a response on a bug which you consider important, you might want to verify that you have assigned the bug to the right package and try providing more information on the problem. Log files, hardware information and screenshots are useful depending on the issue. (Post large sets of data by creating an attachment, not by pasting the data directly into the comment.) Your additional comments or attachments will also act as a gentle reminder to the maintainers. Contributing patches or being part of the bug triaging team [1] is also a very good way to participate. Issues concerning security get special attention [2]
Many of the packages are maintained by volunteers who contribute in their spare time and other people who might have various commitments. Fedora Project has been encouraging co-maintainership or multiple people to work together as a team called special interest groups on the same or similar packages to share the work. Many of the packages are maintained in this manner. With the merge of Fedora Core and Fedora Extras in Fedora 7, the base of contributions and the potential for more volunteers to work in the packages which were in Fedora Core and accessible directly only to those in Red Hat, we expect these problems to be mitigated if not solved to a good extend. If you are still unsure about the status, or suspect that the package is currently unmaintained or the maintainer has not responded in a reasonable timeframe, consider following up in an email to the fedora-devel mailing list. Include a reference to the bug report, and CC the maintainer of the package in question. We understand that this process can sometimes be frustrating and we appreciate the feedback and support.
[1] http://fedoraproject.org/wiki/BugZappers
[2] http://fedoraproject.org/wiki/Security/Bugs
Problem with Pup
david witbeck <fifi5252@yahoo.com> : I am completely new to Linux. I looked at faq's and I dont see an answer. I installed fedora 6 a few months ago and didnt use it. I got interested again and logged in . I got a message i had 252 updates available . When I checked the "apply updates" box I got the following message "another appliccation is running which is accessing information".
Also I tried to install the f-stop application through the "add/remove software " option on the applications drop down menu ,and got the same message. Also when i do a search for yum with the search button, there is no yum. Isnt yum included with version 6 ?
I would really appreciate any help you could give me . Thanks
We appreciate the detailed descriptions and error messages. To better understand the issue, we can provide some basic information first. Fedora package management is based on the RPM format and tool. The yum application is the automatic dependency resolver that uses RPM beneath. Pirut is the graphical frontend to yum, and Pup is the package updater. Puplet provides desktop notification for available package updates. A daemon or background service called yum-updatesd is leveraged by Puplet. The yum-updatesd process locks yum and the RPM database while checking for the presence of any updates, to prevent multiple transactions in the database.
In the earlier versions of yum-updatesd, the daemon had a issue which caused it to lock the database more often than necessary to check updates. You can stop the daemon using the system-config-service graphical utility. From the Main Menu, choose System > Administration > Services and enter the password for root. Locate the yum-updatesd service, select it, and click the Stop button. At the command line, you can stop yum-updatesd for the current session using this command, and the password for the root account:
su -c '/sbin/service yum-updatesd stop'
Then perform an update by selecting Applications > System Tools > Software Updater from the graphical menu, or with the following command:
su -c 'yum update'
You can permanently turn the yum-updatesd service off with this command:
su -c '/sbin/chkconfig yum-updatesd off'
While this particular issue has been fixed in a update, the threaded design for performance has caused more problems, and developers have redesigned and rewritten yum-updatesd to avoid further issues. This package is currently available in rawhide, the development branch of Fedora, and will soon be available as an update to the regular releases.
Marketing
In this section, we cover Fedora Marketing Project.
http://fedoraproject.org/wiki/Marketing
Contributing Writer: ThomasChung
Bradley Kuhn and Max Spevack to keynote at Ohio LinuxFest
RahulSundaram reports in fedora-marketing-list[1] ,
"Columbus, Ohio -- 2007 has been an exemplary year for software freedom, which makes the keynote speakers selected for Ohio LinuxFest[2] 2007 particularly fitting. The Ohio LinuxFest organizers are proud to announce that Max Spevack and Bradley Kuhn will be keynoting this year."
[1] https://www.redhat.com/archives/fedora-marketing-list/2007-August/msg00046.html
[2] http://www.ohiolinux.org/about.html
Video: Meet the Fedora Ambassadors
RahulSundaram reports in fedora-marketing-list[1] ,
"Show case[2] of impressive Brazilian team of Fedora Ambassadors. One of the very strong regionals teams. With the Free software in Fedora and in Brazil, this isn't a surprise though. Congrats folks."
[1] https://www.redhat.com/archives/fedora-marketing-list/2007-August/msg00044.html
[2] http://www.redhatmagazine.com/2007/08/02/video-meet-the-fedora-ambassadors/
New extras repository for Red Hat Enteprise Linux
RahulSundaram reports in fedora-marketing-list[1] ,
"If you need a software app that is not included or supported in the standard Red Hat Enterprise Linux (RHEL) or CentOS distribution, Red Hat's new Extra Packages for Enterprise Linux (EPEL)[2] repository might be an excellent place to go fishing."
[1] https://www.redhat.com/archives/fedora-marketing-list/2007-July/msg00096.html
[2] http://fedoraproject.org/wiki/EPEL
Redirecting Core Dumps
RahulSundaram reports in fedora-marketing-list[1] ,
"Apport[2] is a system wide crash dump handler. Will Woods, QA lead in Fedora has been working on adopting Apport from Ubuntu and Neil Horman is pushing some reimplemented patches upstream that is required for this feature in true Fedora fashion. Originally targeted for the next release, this has now been moved to Fedora 9. A important feature that will make it easy for users to report issues. Good to keep an eye on."
[1] https://www.redhat.com/archives/fedora-marketing-list/2007-July/msg00090.html
[2] http://fedoraproject.org/wiki/Releases/FeatureApport
Developments
In this section, we cover the problems/solutions, people/personalities, and ups/downs of the endless discussions on Fedora Developments.
http://www.redhat.com/mailman/listinfo/fedora-devel-list
Contributing Writer: OisinFeeley
FESCo Approves CodecBuddy
BrianPepple posted[1] the summary of decisions of the last (2nd Aug 2007) FESCo meeting and the link to the IRC log. Included in this was the decision to approve the CodecBuddy and RahulSundaram wished[2] that they'd waited until MaxSpevack had heard answers back from "legal" about specific questions raised in FAB discussions.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00203.html
[2] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00216.html
MatthiasClasen asked[3] Rahul for his alternate code and also claimed that some points raised by FAB had been addressed. Rahul pointed[4] out that Matthias was not addressing the issues raised by FAB and that probably no one could until legal had investigated. From this exchange and the IRC log[5] it seems that the implementors of "codeina" / CodecBuddy believe that creating a Fedora Project controlled web-page will ward off the evil eye of patent lawyers. There was not an extensive discussion even given the caution expressed by DavidWoodhouse (dwmw2) and others. The IRC log records a tentative approval subject to FESCo input to the content of the webpage.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00219.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00223.html
[5] http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070802
The Future Of Yum
An enigmatic opening post from FlorianFesti [1] tantalized by suggesting that "whois yum4.org" and "whois yum5.org" would be interesting. The actual pages were the default test-page distributed with Fedora's httpd package. Following up on Florian's hint revealed JeffJohnson ex-Red Hat RPM developer and leader of the rpm5.org fork (see also FWN#98 "RPM Roadmap...Panu Opens Pandora's Box"[2] .)
[1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01755.html
[2] http://fedoraproject.org/wiki/FWN/Issue98#head-90b3708648e89def933055ad00d6cb887b9cde0d
SethVidal, as the originator of "yum", was entertained[3] and wondered whether he should release successive versions numbered by squaring the previous version number. Some creative suggestions followed.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01756.html
A good laugh was also being had by RobertScheck[4] , who claimed that yum4/5 will be written in C instead of python and suggested that PanuMatilainen rip out Python and maybe even PERL support in RPM along with HTTP and FTP. RahulSundaram wasn't amused[5] by the lack of courtesy shown in creating a misleadingly similar project name and also thought that as Robert was involved in a fork he should concentrate on that instead.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01782.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01785.html
The thread ended[6] as enigmatically as it had begun with IgnacioVazquezAbrams asking Robert to let him "know when wnh is ready".
[6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01793.html
Kqemu In The Kernel?
A belated response[1] from "dragoran" to a 16 June 2007 thread on the absence of kqemu from Fedora argued that it recompiled without much trouble although it was large. DaveJones responded[2] that kqemu wasn't merged upstream (the kernel) and that Fedora was trying to stay close to upstream to make rebasing easier. Dave was of the opinion that although Fedora was getting better in this regard it still sucked (wireless was singled out) and he didn't want to undo the progress.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00107.html
[2] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00131.html
PaulWouters seemed to think[3] that this was a duplicitous answer as many of the concerned upstream people are also Red Hat developers on this very list. RahulSundaram asked where the patches had been submitted upstream and "dragoran" answered that no one had done so. Rahul disparaged[4] the idea that "politics" or "Red Hat developers" were relevant to the issue and suggested trying to get the Fedora kernel maintainers to patch the kernel was futile unless upstream did it first. AlanCox had empirical evidence[5] that no one was very much interested in kqemu.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00134.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00174.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00172.html
Kmods Clarified
Following on from the discussion of kqemu above (FWN#99 "Kqemu In The Kernel?" and last week's slightly misleadingly titled FWN#98 "Kmods Deprecated"[*] ) "Kelly" wondered[1] why DKMS[2] wasn't in the main repository as s/he found it an invaluable means of managing non-standard kernel modules. JefSpaleta corrected[3] Kelly with the information that DKMS was actually available and Kelly rephrased the question to ask why couldn't kqemu be included in the main repository as a DKMS module? The advantage Kelly perceived over including kqemu in the kernel would be that they could be upgraded separately.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00147.html
[2] http://linux.dell.com/projects.shtml
[3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00173.html
The responses mostly rehashed the older debates on this subject and ToddZullinger pointed this out[4] along with the need to avoid packages that require compilation tools which is implicit in the DKMS approach. ThorstenLeemhuis followed up[5] with a link to the last discussion (in Jan 2007) which included a clear argument[6] from JeremyKatz that the problem of multiple different databases for tracking installed software and the realistic lack of a stable upstream kernel interface meant that DKMS was not a preferred solution. Thorsten suggested that Kelly review this entire earlier discussion because if nothing had changed in the interim then there was no point in replaying it, especially as kmods were on their way out.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00176.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00178.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-January/msg01294.html
JesseKeating was quick to point out[7] that kmods as separate packages were deprecated but that kmods in the kernel rpm as out of tree modules were a preferred solution. Also included in Jesse's list of advantages was the fact that the kernel maintainers would excercise the same criteria for kernel modules as for the kernel. In response[8] Thorsten re-iterated that he was in agreement with parts of the decision but still saw the advantages of providing an "alphaworks" space which provided kernel modules. Thorsten also wondered about the apparently conflicting messages with some developers within Red Hat favoring a packaging standard like DKMS developed in Fedora while "some Red Hat people [were] kick[ing] kernel modules out of Fedora now."
[7] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00179.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00183.html
LesMikesell argued[9] the advantages of a stable interface to the kernel for RHEL so that 3rd party modules upon which customers rely were not broken on updates. A fairly longish thread followed with some interesting examples backing up this viewpoint including one from PaulWouters (who advanced the OpenSWAN case). The problem with this argument was pointed out by ToddZullinger who noted that RHEL spends developer time on constantly backporting to provide this stability and that Fedora did not have this model. Todd suggested that the majority using Fedora preferred a rapidly updated kernel as opposed to a stable ABI and that CentOS and RHEL existed for people whom this did not suit.
[9] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00192.html
LiveCD Wipes Root Partition
A remarkably calm MichelSalim reported[1] that an attempt to do a clean-install of Fedora7 from the LiveCD while retaining his old "/home" by explicitly requesting anaconda not to reformat "/" had resulted in anaconda ignoring the request and reformatting "/".
[1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01838.html
There were several indications during the process that anaconda seemed to be doing the right thing (including a warning that retained files might interfere with the installed system). Michel wanted to know his best strategy for recovering his data and consequently the details about how the LiveCD worked.
DouglasMcClendon was a mine of information and confirmed[2] that the absence of a warning dialogue which clarifies that "/" will be reformatted is a horrible bug and was surprised no one had reported it before now. He also confirmed that anaconda copies the whole image over from the CD using "dd" into a newly reformatted (at least) 4.0GB "/" partition and subsequently copies "/usr" and "/var" and other filesystems from this into separate partitions (if they exist). Doug was hopeful that data beyond that 4GB limit would be recoverable to some extent.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01852.html
Further discussion between Douglas and Michel elucidated[3] the point that F7 is the first time this LiveCD install option has been available and the worrying warnings probably steered testers clear. Douglas discussed his "turbo" version of the installer and the potential of an alternate file-level copy installation mechanism (which would also solve the non-ext3 root fs problem). In response to Michel's suggestion of a FreeBSD-style default /home partition Douglas described his strategy of creating a preserved subdirectory within /home (which also had copies of dotfiles) and this then allowed "wipegrades". A default preservable /home partition would aid this strategy.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01862.html
Michel expanded[4] on this with the idea that the distinction wasn't so much /home and /, but rather RPM-managed vs non-RPM-managed (and hence preservation worthy). Michel wondered how Ubuntu and OpenSUSE were coping with this in their new LiveCDs. RahulSundaram thought that every LiveCD used the "dd" strategy, but Douglas corrected this with the information[5] that copy-on-write is implemented using unionfs on Ubuntu whereas devicemapper-snapshot is used on Fedora.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01863.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01865.html
RPM Roadmap (Cont.)
The excellent discussion initiated last week by PanuMatilainen (see FWN#98 "Panu Opens Pandora's Box"[1] ) continued apace without a break. TillMaas wanted[2] rpmbuild to internalize the common part of the Fedora specs including setting up a sane buildroot, cleaning up and setting attributes. Till noted the five lines saved in each spec file as a result of this. DimiPaun wasn't interested in saving the five lines, but agreed[3] that Till's proposal would be correct because the rpmbuild should be telling the specfile where the buildroot is instead of vice-versa. Dimi also proposed that attempts to set the buildroot or "rm -rf" by the specfile should be ignored and should issue warnings.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01676.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01678.html
The problem which this would create for backwards compatability was explored when JasonTibbitts agreed[4] with Dimi's suggestions with the exception of ignoring specfile initiated buildroot setting and clean-up, pointing out EPEL4 as an instance. Panu wearily welcomed[5] us to the "world of rpm: people want progress but no change" and wondered about forking the specfile format, but Rahul thought[6] that would only work with a new parallel-installable version of RPM in order to be able to deal with the legacy issue.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01682.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01689.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01690.html
RobertScheck thought[7] that the macros in /usr/lib/rpm ought to be used to implement Till's suggestions. Till answered[8] with the argument that reliance on macros in this way would mean the spec was not generally useful for non-Fedora distributions. A minor sub-discussion about non-sane specfiles creating dangling symlinks followed.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01695.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01713.html
Another desired feature was "sandbox" support, requested[9] by ZCMiao who noted Gentoo's implementation of ebuild, but KevinKofler responded that "mock" was the appropriate way to test unsafe code builds.
[9] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01696.html
"Nodalus" argued[10] against stripping out HTTP/FTP capabilities on the grounds that bootstrapping would become awkward and wondered if a solution would be to leave these features but enable RPM to use superior external methods when/if detected. JesseKeating, GilboaDavra and HorstvonBrand argued variously that a rescue environment with tools to add/remove content via a chroot, a plug-in system for resource poor systems and security problems were all good reasons not to implement "nodalus'" proposal.
[10] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01754.html
A dream[11] which MatthiasSaou would like to come true is the automatic cacheing of all %config files which would allow diffs to be shown against the original state. This spawned a certain amount of interest in using a version-control system to manage these files, with IanBurrell promoting[12] the idea of a hook which could call an external VCS if needed. TheodorePapadopoulo was inspired[13] to describe a use-case where it would be advantageous to extend RPM to deal with rpms which have the sole purpose of over-riding the config files of some other rpm. BillCrawford was cautiously encouraging[14] but also suggested the workaround of replacing redhat-release with a hand-rolled version and repackaging the software with new config files. Similarly, EmmanuelSeyman suggested[15] repackaging with the addition of using something like "cfengine" to centralize the changes in a reproducible manner. JefSpaleta[16] and TonyNelson[17] also thought that Matthias' suggestion was a good one.
[11] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01744.html
[12] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01778.html
[13] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01841.html
[14] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01845.html
[15] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01846.html
[16] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01773.html
[17] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01794.html
AxelThimm requested[18] fixing whatever minor bugs cause rpm to choke on fakeroot/fakechroot some of the time and advanced the security benefits as one of the reasons plus the expansion of possible packagers in the form of students without root accounts. JesseKeating was keen on something like this for Koji too, and Panu requested further reproducible bug details.
[19] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01766.html
There were a hell of a lot of other excellent suggestions, including RalfCorsepius' concrete suggestions for what should be done to make the current rpm codebase usable. Panu was strongly in agreement with Ralf on these points and requested[20] his autotool expertise.
[20] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01816.html
NilsPhilippsen wanted[21] to get rid of the 2GB limit and hence cpio, which led to a discussion of compression[21a] . (MichaelSchroeder of SuSE clarified[22] that the 2GB limit applies to single files not the entire RPM). AdamJackson (ajax) thought that POSIX 2001 tar might[23] make a worthy replacement and cast doubt on the sanity of using the same package manager across multiple systems. AlanCox defended[24] ErikTroan's original choice of cpio and argued that a single package manager across multiple systems had been shown to be both profitable and useful. Surprisingly it seemed that there are several [25] [26] possible uses of RPMs containing files greater than 2GB.
[21] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00025.html
[21a] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00100.html
[22] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00064.html
[23] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00037.html
[24] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00069.html
[25] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00074.html
[26] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00106.html
One of the most informative posts came from Panu himself and explained[27] the problem with adding architecture specific requires and provides as requested last week by "dragoran" to solve the multilib problem.
[27] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00056.html
There's a lot more to this thread which is worth reading but can't be adequately summarized.
KDE4 Status
A notice[1] from JosPoortvliet (of the KDE Promo group) advised that the first beta of KDE4 would be released soon and wondered whether it would be in Fedora 8. Since then the beta has actually been released (Aug 2nd 2007)[1a] . Jos wanted to be able to mention Fedora8 in the release notes.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01644.html
[1a] http://www.kde.org/announcements/announce-4.0-beta1.php
The issue had been discussed earlier (see FWN#89 "KDE4 For Fedora8 Draft Document Discussion"[2] ) by KevinKofler and JeremyKatz with attention paid to the problem with clashing sonames between KDE3 and KDE4 and the inadvisability of delaying the Fedora8 release-schedule in the hope that the KDE release-schedule was cast in stone.
[2] http://fedoraproject.org/wiki/FWN/Issue89#head-51fa717561e1d1e16b73bec57324df489664b2fd
This time around there was a top-posted attempt[3] at encouragement from "MarkG85" to the Fedora-KDE SIG to "make packages" of KDE4. Responses from the folks producing the KDE desktop for the Fedora Project were fairly uniform. ChrisBrown noted[4] his personal experience with the complexity of the task of maintaining a complete desktop environment, and also the inadvisability of rushing poorly constructed packages into the distribution. "MarkG85" thought that F8t1 would be a good place to test the packages to which KevinKofler responded[5] that F8t1 was already frozen.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01697.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01699.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01714.html
GilboaDavara shared[6] the concerns of Kevin and RexDieter that KDE4beta2 would be released a mere 3 days before the Fedora8 feature-freeze which would mean that there would be very little testing in rawhide. Gilboa wondered whether KDE4beta2 would be feature complete and, in a recapitulation of the FWN#89 discussion[2] , whether it was parallel installable.
[6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01715.html
RexDieter invited anyone interested in speeding things up to join the effort at the Fedora KDE SIG and ArthurPemberton requested an appraisal of the chances of KDE4 in Fedora8 and suggested a qemu image for testing if parallel-installation of KDE4 and KDE3 were impossible. Rex's response[7] was to draw a distinction between the complete KDE4 desktop, which has a 50/50 chance of making it in depending on release-schedule slippage, and some bits of KDE4 which will without doubt make it in. Rex was warmly welcoming of anyone that wanted to help out with a qemu-image.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01733.html
Package Management: Goats Satisfied With Current Situation
RichardHughes continued[1] to think hard about the problems of software installation and wanted other people to join him. Richard outlined a series of use cases which might form the basis on which to make decisions about how package management should be implemented.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01818.html
The first substantive comment[2] came from AlanCox who thought that Richard's security model needed refinement as it made it too easy for uninformed users to install malware. Two other important points which Alan identified were: the absence of install-time distinction of install types (which limits the automounting of filesystems and Ubuntu style sudo); and the need for revoke() in the kernel[3] in order to allow multiple users to install packages after switching desktop user. Alan identified three install types: user-managed; centrally-managed; and physical-access.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01823.html
[3] The revoke() syscalls are not yet in the kernel although they are in the -mm branch. They allow a file (or other resource) to be revoked and all processes which have the file open receive an error. http://www.uwsg.iu.edu/hypermail/linux/kernel/0701.3/1344.html
Richard thought[4] that most of the problems which Alan identified with security were ones that could be handled using PolicyKit and defining the repositories from which authenticated users could install software. There was also strong agreement that the revoke() system calls were important "Yes. Take a stapler gun and start firing it into the air until it's merged" but also optimism that 90% of the FastUserSwitching could be achieved without it.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01828.html
A short response from ColinWalters disagreed with AlanCox and suggested that there were only two cases to be considered, namely: 1)that of a user responsible for the machine (who should be able to install any package from the default CD set); 2)that in which the user is not responsible, but an admin is and they should be able to set policy in any way. RichardHughes requested[5] that Colin add this to PackageKit[6] .
[5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01853.html
[6] http://live.gnome.org/PackageKit
A significant number of the comments expressed concern about the idea of making it easier for users to install software. EmmanuelSeyman's raising of the point with regard to any logged-in user was answered[7] by Richard invoking the use of PolicyKit to allow the admin to arbitrarily enforce any desired policy. A very strong version of the argument was presented[8] by HorstvonBrand who had concerns about the amount of disk-space and bandwidth that would be consumed if the laxity of Richard's suggested use-cases were permitted. Horst thought that a simple configuration using sudo and yum would solve the problem without much trouble. Richard replied that this was true only for some users and didn't cover the case of the non-technically adept.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01826.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01843.html
PaulNasrat drew[9] Richard's attention to the Klik package-management system[10] which attempts to rethink some aspects of package-management (mainly by assuming the LSB as standard). Paul wanted Richard to make his use-cases a little clearer as regards their administrative role and also was concerned with the need for more metadata in packages (perhaps obtained using mime/file(1) info) in order to allow the system to suggest appropriate applications when users wish to access particular files. Again the issue of bandwidth and trust was raised with Paul pointing out that automatic updates over GPRS wouldn't be nice. NicuBuculei suggested[11] expanding the information gathered and stored by Mugshot to help with the metadata problem. (Convergence with other Mugshot features was also discussed in FWN#98 "Package Management Craic"[12] ).
[9] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01827.html
[11] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01833.html
[12] http://fedoraproject.org/wiki/FWN/Issue98#head-2e4823600525c6129df7d1944edfa5e27eae1e04
FESCo Ratifies Changes To "License:" Tag In RPM SPECs
On the foot of recent extensive discussions (see FWN#98 "NOTE:Please publicize any license changes to your packages (CONT.)"[1] ) a friendly announcement[2] from TomCallaway (spot) communicated the decision of FESCo (2 Aug 2007) to require every package to have a "License:" tag formatted in a way which allows some automated checking for incompatibilities. Spot provided a list of acceptable licenses and answers to predictable questions.
[1] http://fedoraproject.org/wiki/FWN/Issue98#head-98f4908dba5aeb4008843b233e2bbc5ccd599ecc
The positive tone of the posting encouraged specific requests for information which displayed a few common themes. One was that alerting upstream projects of unclear or apparently contradictory licensing problems . JakubJelinek pointed out[2] the potential for one such problem when he thought that Spot's wording concerning the presence of L/GPL "or any later version" should emphasize that all files in a program should be examined for consistency in this regard. Jakub asked for clarification using the example of "glibc" which contains LGPL2.1 or later libraries certain files of which have exceptions allowing linking to proprietary code, and also contains GPL2 or later executables and some erroneous GPL2 only executables. Spot provided[3] the License-tag "License: LGPLv2+ and LGPL with exceptions and GPLv2+" under the assumption the package would contain corrected versions of the executables and thought that Jakub's description exemplified the sort of breakdown that should be included in the spec comments. A very similar question was posed by JasonTibbitts about the "ypbind" package which seems to have contradictory information in the source and the manpage. Spot's answer was to get upstream to sort it out, but that source-code trumps all[4] in the event of this not occurring.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00111.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00116.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00126.html
The question of how necessary this all is was floated[5] by TomLane while he tried to sort out his "mysql" package. Tom echoed JasonTibbitts suspicion that Fedora will be more organized than most upstream projects and that things are going to be complicated, perhaps unnecessarily so. In support of this Tom noted that many of the popular graphics libraries (libtiff, libpng and libjpeg) have BDS-ish licences and that his long involvement with them made clear to him that their spirit was intended to be BSD. This made the existence of a distinctly separate "zlib/libpng" license in Spot's list a little surprising to Tom. JesseKeating thought[6] that if those projects had really intended to use BSD licensing then they would have and it was best not to assume anything and to try and be specific. Spot assured[7] Tom that his intent was not to cause pain, but to make license-auditing easier for the Fedora Project and offered to try to pigeonhole any licenses which Tom wished to send him.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00155.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00162.html
[7] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00169.html
The impact on the buildsystem was considered[8] by HansdeGoede who thought that it would be better to update the CVS devel-branch and avoid rebuilding until a more convenient time as otherwise this would effectively be triggering a mass rebuild. Hans also asked how freely distributable, non-modifiable content should be tagged (e.g. much firmware). JesseKeating listed[9] other outstanding issues that might trigger a mass rebuild (BuildID, IceTea for Java, all ppc32 due to SELinux problem) and agreed[10] [11] with Hans and Spot that it would be best to just tag in CVS-devel and add the license tagging as another item for a synchronized rebuild to minimize churn.
[8] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00118.html
[9] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00121.html
[10] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00128.html
[11] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00127.html
Hans had further pertinent[12] points with regard to the zlib/libpng short-form license tag (which seemed to deviate from rpmlint's preferences) and also the licensing of non-modifiable game content. VilleSkyttä[13] reassured Hans that the latest rpmlint (0.80-2) was consistent with the new packaging guidelines thanks to work by Spot. The games issue was admitted to be an oversight by Spot who thanked[14] Hans for pointing it out.
[12] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00130.html
[13] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00132.html
[14] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00133.html
An error in the license table on the wiki was flagged[15] by GianlucaSforna and later corrected.
[15] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00156.html
JefSpaleta wondered what to do when a package contains some "GPLv2 or later" files and other "GPL2 only" files and was answered[16] by JoshBoyer that the package should be then tagged as "GPL2" only as the principle is that the stricter of the licenses should be used.
[16] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00227.html
In closing it should be noted that Spot is apparently willing to take any further license queries and is also seeking help from anyone else interested in getting involved with helping in this area. RahulSundaram has stepped forward[17] to assist.
[17] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00112.html
Maintainers
In this section, we cover Fedora Maintainers, the group of people who maintain the software packages in Fedora.
https://www.redhat.com/mailman/listinfo/fedora-maintainers
Contributing Writer: MichaelLarabel
EPEL Repository Continues To Expand
EPEL (or Extras Packages for Enterprise Linux[1] ) has been making news in recent weeks after it officially opened up a while back. In this week's EPEL report[2] the number of packages for EPEL 5 has risen by 30 to a total of 872 binary packages while the EPEL 4 repository is up by 31 for a total number of 596 binary packages.
[1] http://fedoraproject.org/wiki/EPEL
[2] https://www.redhat.com/archives/fedora-maintainers/2007-July/msg00441.html
Documentation
In this section, we cover the Fedora Documentation Project.
http://fedoraproject.org/wiki/DocsProject
Contributing Writer: JonathanRoberts
Virtual Fudcon Ideas?
With the upcoming virtual Fudcon, KarstenWade sent a message to the list requesting ideas for sessions that the DocsProject might run[1] . Initial suggestions included how to work on docs in the wiki and XML skills, with practice.
[1] https://www.redhat.com/archives/fedora-docs-list/2007-July/msg00086.html
Documentation Project Steering Committee Meeting
The log[1] and the summary[2] of the FDSCo meeting held on 07/31 were posted to the list.
[1] https://www.redhat.com/archives/fedora-docs-list/2007-July/msg00091.html
[2] https://www.redhat.com/archives/fedora-docs-list/2007-July/msg00093.html
Fedora 8 Test 1 Release Notes
RahulSundaram wrote to the list requesting help with creating the release notes for Fedora 8 Test 1[1] . This prompted PaulFrields to suggest that this would be the ideal task for a new contributor, with help available if they need it[2] .
[1] https://www.redhat.com/archives/fedora-docs-list/2007-July/msg00081.html
[2] https://www.redhat.com/archives/fedora-docs-list/2007-July/msg00082.html
Infrastructure
In this section, we cover the Fedora Infrastructure Project.
http://fedoraproject.org/wiki/Infrastructure
Contributing Writer: JasonMatthewTaylor
Operating Procedures
MikeMcGrath has documented some SOP's[1] for the infrastructure team and is looking for people to review them.
[1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-August/msg00038.html
Artwork
In this section, we cover Fedora Artwork Project.
http://fedoraproject.org/wiki/Artwork
Contributing Writer: JonathanRoberts
Echo Used on translate.fp.org
DimitrisGlezos wrote to the list to announce that, on the new translate.fedoraproject.org, he has made extensive use of the Echo icon set[1] .
[1] https://www.redhat.com/archives/fedora-art-list/2007-July/msg00180.html
Virtual Fudcon
NicuBuculei, having just read about the virtual Fudcon, writes to the list to propose that the art team take part[1] , proposing the possibility of a hackfest on a number of possible projects.
[1] https://www.redhat.com/archives/fedora-art-list/2007-July/msg00197.html
Round 2 Deadline
The deadline for round 2 submissions has been extended to Monday 6th August, to provide contributors one more week to polish their submissions[1] . For a submission to be considered for round 2 it must have at least one wallpaper proposal, and three supporting graphic proposals. Supporting graphics can include a vertical banner for first boot, a horizontal banner for Anaconda, banner for fedoraproject.org, CD label etc.
[1] https://www.redhat.com/archives/fedora-art-list/2007-August/msg00000.html
Security Week
In this section, we highlight the security stories from the week in Fedora.
Contributing Writer: JoshBressers
Firefox 2.0.0.6
Firefox 2.0.0.6 was released this week. Neither Fedora or Red Hat Enterprise Linux will see this version. Here is why.
This update fixes these two flaws:
- MFSA 2007-27: Unescaped URIs passed to external programs[1]
- MFSA 2007-26: Privilege escalation through chrome-loaded about:blank windows[2]
[1] http://www.mozilla.org/security/announce/2007/mfsa2007-27.html
[2] http://www.mozilla.org/security/announce/2007/mfsa2007-26.html
The reason the Mozilla Foundation released this update was primarily to address MFSA 2007-27. This is a rather serious flaw regarding to how Firefox hands URIs to external helper programs. This flaw does not affect Linux as helper applications are launched in an understood and controlled manner. The other flaw, MFSA 2007-26, is a rather minor flaw that has been rated as being of moderate severity. It involves how certain Firefox extensions create new windows. In general this flaw is harmless and upstream wanted to fix it since it was a regression from the 2.0.0.5 update.
A lot happens behind the scenes anytime there is an update of Firefox, Thunderbird, and Seamonkey. Apart from a great deal of developer and QA time, this translates into lost time for users as well. Vast quantities of bandwith are consumed to download the updates, then the various plugins must be updated. It was decided that it would be a great disservice to the users to squander the available recourses for an update they don't need.
Obviously, if you run Firefox on Windows, you best get this update, as the flaw is rather serious there.
Hacking via IPS Signatures
An Intrusion Prevention System (IPS) is supposed to stop malicious attacks from ever happening. In general most security researchers worth their salt feel these systems are a waste of time and money. They fall into the classification of security theater, or something that doesn't actually make you more secure, it makes you think you are more secure.
An article on Dark Reading[1] claims something that has been suspected, but unproved, for a very long time about IPS vendors. Their 0day vulnerability signatures, aren't very 0day. One of the ways IPS vendors try to add value is to include currently unknown vulnerabilities they discovered. The way this works is they acquire information about a security flaw, create an IPS signature for it, add the signature to their product, then tell the vendor. The article from Dark Reading suggests that attackers are using the signatures to figure out what the vulnerability is, then leveraging the fact that it's not fixed in the vendors product.
How this will be handled by various vendors is now a vary real question that needs to be addressed. We shall see where it goes.
[1] http://www.darkreading.com/document.asp?doc_id=130313&WT.svl=news1_1
Daily Package
In this section, we recap the packages that have been highlighted as a Fedora Daily Package.
[1] http://dailypackage.fedorabook.com/
Contributing Writer: ChrisTyler
Gobby - Collaborative editor
Productive Mondays highlight a timesaving tool. This Monday[1] we covered Gobby[2] :
"Gobby is a collaborative editor which enables multiple people to simultaneously edit a group of documents. ... Gobby also enables cross-platform collaboration: MS Windows and (limited) Mac OS/X clients are available from the upstream website."
[2] http://gobby.0x539.de/trac/
Netpbm - Utilities for graphic manipulation
Artsy Tuesdays highlight a graphics, video, or sound application. This Tuesday[1] Netpbm[2] was featured:
"Netpbm is a venerable collection of over 300 short programs that manipulate graphics files."
[2] http://netpbm.sourceforge.net/
Wednesday Why: Colour ls
The Wednesday Why article[1] took a look at the colour-coding capabilities of GNU 'ls' and Fedora's default configuration of these features:
"By default, the Fedora 'ls' command colour-codes file listings when they are displayed on a virtual terminal or terminal window, but not when they are piped into another command."
[1] http://dailypackage.fedorabook.com/index.php?/archives/109-Wednesday-Why-Colour-ls.html
Xnest - A nested X server
GUI Thursdays highlight software that enables, provides, enhances, or effectively uses a GUI interface. This Thursday[1] , Xnest[2] was discussed:
"Xnest is a nested X server: a display that runs in a window within another display. It's useful for testing GUI applications as a different user, trying out several desktop environments at the same time, or getting screenshots of the login process."
[1] http://dailypackage.fedorabook.com/index.php?/archives/110-GUI-Thursday-Xnest-A-nested-X-server.html
[2] http://x.org/
Kbilliard - Billiard simulator game
Friday Fun highlights fun, interesting, and amusing programs. This Friday[1] , we took a look at Kbilliards[2] :
"Kbilliards is a billiard game simulator. As the name implies, it's KDE-based. You can play against yourself, another user, or the computer. When you start a new game, you can also select 'Training Mode', which enables you to move any ball to set up complex practice shots."
[2] http://www.hostnotfound.it/kbilliards.php
Advisories and Updates
In this section, we cover Security Advisories and Package Updates from fedora-package-announce.
Contributing Writer: ThomasChung
Fedora 7 Security Advisories
- [SECURITY] gdm-2.18.4-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1362
- [SECURITY] GraphicsMagick-1.1.8-2.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1340
- [SECURITY] tcpdump-3.9.7-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1361
- [SECURITY] xorg-x11-xinit-1.0.2-21.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1409
- [SECURITY] xpdf-3.02-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1383
Fedora Core 6 Security Advisories
- [SECURITY] gdm-2.16.5-2.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-653
- [SECURITY] tcpdump-3.9.4-11.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-654
Events and Meetings
In this section, we cover event reports and meeting summaries from various projects.
Contributing Writer: ThomasChung
Fedora Board Meeting Minutes 2007-07-31
Fedora Ambassadors Meeting 2007-MM-DD
- No Report
Fedora Documentation Steering Committee 2007-07-31
Fedora Engineering Steering Committee Meeting 2007-08-02
Fedora Extra Packages for Enterprise Linux Meeting (Log) 2007-08-01
Fedora Infrastructure Meeting (Log) 2007-MM-DD
- No Report
Fedora Packaging Committee Meeting 2007-07-31
Fedora Release Engineering Meeting 2007-07-30
Fedora Translation Project Meeting (Log) 2007-MM-DD
- No Report