From FedoraProject

< FWN(Difference between revisions)
Jump to: navigation, search
(Imported from MoinMoin)
m (1 revision(s))

Revision as of 16:27, 24 May 2008


Fedora Weekly News Issue 100

Welcome to Fedora Weekly News Issue 100 for the week of August 6th, 2007. http://fedoraproject.org/wiki/FWN/Issue100

In this week, we have announcements on Virtual FudCon8, Announcing Fedora 8 Test 1.

In Ask Fedora, we have a few good questions on Intel IP2200 Wireless In Fedora 7, Distribution Upgrades And Peripherals, Yum Reverse Dependency Removal.

In Daily Package, we have a few good reviews on Qcad - Simple 2D CAD program, Gscan2pdf - Frontend for scanning utilities, Xephyr - New nested X server and Really Slick Screensavers

To celebrate our 100th issue, one lucky winner will receive "Fedora 7 Bible" by Christopher Negus. See Extras Extras section for more information.

To join or give us your feedback, please visit http://fedoraproject.org/wiki/NewsProject/Join.


In this section, we cover announcements from various projects.

Contributing Writer: ThomasChung

Virtual FudCon8

JeffSpaleta announces in fedora-announce-list[1] ,

"Announcing Fedora 8's Online FUDCon[2] .

Come join us over the next few days for our first online community conference where Fedora developers will be discussing features and projects that will be impacting Fedora 8 and beyond."

[1] https://www.redhat.com/archives/fedora-announce-list/2007-August/msg00002.html

[2] http://fedoraproject.org/wiki/FUDCon/FUDConF8

Announcing Fedora 8 Test 1 (7.90)

JesseKeating announces in fedora-announce-list[1] ,

"Fedora 8 Test one[2] has been loosed upon the world today. Included in this release is a "Fedora" installable 'choose your own adventure' style set of isos and trees for i386, x86_64, and ppc(64). Also included are Live images of both the Fedora Desktop and the Fedora KDE desktop. These are available for both i686 and x86_64 (x86_64 is DVD size only). Remember these can be used on USB media via the livecd-iso-to-disk utility available in the livecd-tools package."

[1] https://www.redhat.com/archives/fedora-announce-list/2007-August/msg00001.html

[2] http://fedoraproject.org/wiki/Releases/8/Schedule

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

Intel IP2200 Wireless In Fedora 7

adrian.mowrey@gmail.com: I have a laptop (Inspiron B130) from Dell, and it has a wireless card (Intel(R) PRO/Wireless 2200BG Network Connection). I also have a wireless connection established through a linksys router. How can I connect my laptop to the Internet by wireless? If you could explain to me whatever I have to do so that I can connect to the Internet by wireless, it will be very helpful for me as a beginner to Linux. Thank you.


-- Adrian Mowre

The kernel driver and firmware to support this card is included by default in Fedora 7. We recommend the Live images for desktop use which supports seamless wireless networking via Network Manager [1] which is enabled by default. If you have used the DVD image to install Fedora 7, you have to enable it manually. Network Manager is a background service that has both GNOME (nm-applet) and KDE (knetworkmanager) frontends.

Set the main service to automatically start on boot:

su -c '/sbin/chkconfig --level 345 NetworkManager on'

Set the dispatcher service to automatically start on boot:

su -c '/sbin/chkconfig --level 345 NetworkManagerDispatcher on'

Start the background services:

su -c '/sbin/service NetworkManager start ; /sbin/service NetworkManagerDispatcher start'

In the next release, the plan [2] is to enable Network Manager by default and use it system wide.

[1] http://www.gnome.org/projects/NetworkManager/

[2] http://fedoraproject.org/wiki/Releases/8/FeatureList

Distribution Upgrades And Peripherals

William Brown <wbrn314@cox.net>: Why is it when I upgrade to a new version of the same distro some of my peripherals won't function? I was using Fedora 6 and upgrade to Fedora 7. I thought an upgrade was to fix bugs and make things more user friendly. OK, I have to agree the GUI looks better but the overall functionaly seems to be the same. If we want to introduce more people to the Linux community and the Open Software way of computing then the developers have to concentrate on making the distros more user friendly instead of more complicated???

While the upgrades are intended to bring in more functionality and bug fixes, there tends to be some amount of regressions in newer releases too unfortunately. If you are having any issues with this release, do report those in Red Hat Bugzilla. In Fedora 7, the majority of work was on the infrastructure side merging in Fedora Core and Fedora Extras, open build system and distribution composing and customization tools, mirror manager etc but we did bring in a lot of new features for end users too[1] . Note that Fedora updates lifecycle [2] has been extended with Fedora 7 onwards to allow the flexibility for end users to skip alternative releases if necessary and if you believe that the advantages in the latest release are not compelling enough for you, you can take advantage of this flexibility while continuing to receive updates for the older version of Fedora.

We request the community to participate early in the testing process by using the development branch of Fedora called 'rawhide' or one of the three test releases, send feedback and report bugs[3] . Thank you for your support.

[1] http://docs.fedoraproject.org/release-notes/f7/en_US/sn-OverView.html#sn-New-in-Fedora

[2] http://fedoraproject.org/wiki/LifeCycle

[3] http://fedoraproject.org/wiki/BugsAndFeatureRequests

Yum Reverse Dependency Removal

Roberto Vanto <roberto-vanto@tiscali.it>: In my opinion yum should support reverse dependencies handling. Something like this: http://planet.sabayonlinux.org/?p=65

Yum supports reverse dependencies just fine. Try, yum remove <packagename> and yum will automatically list all the packages that depend on it and prompt for removing all of them. One of the requested enhancements to this is to remove packages that has been installed as dependencies for the package you are removing if they are only needed for that particular package and this feature is under development as a yum plugin [1] . Meanwhile package-cleanup utility which is part of yum-utils package in Fedora is quite handy for a number of similar things.

[1] https://lists.dulug.duke.edu/pipermail/yum/2007-June/009933.html

Planet Fedora

In this section, we cover a highlight of Planet Fedora - an aggregation of blogs from world wide Fedora contributors.


Contributing Writers: ThomasChung

Fedora 8 Artwork: We Need Your Help!

MairinDuffy reports in her blog[1] ,

"For the theme artwork[2] (wallpaper, login, banners, etc.) for Fedora 8, the Fedora Art Team is following a '3-round' process for creating the artwork. We started by accepting theme concept proposals from the entire Fedora community. Round 1 involved coming up with concepts/ideas and rough sketches to demonstrate the concept; Round 2 involved coming up with some more polished artwork towards the concept proposed, including a requirement of at least one wallpaper design and 3 supplementary designs. Round 2 just ended this past Monday, and the two themes left standing are: (See the blog)"

[1] http://mihmo.livejournal.com/42902.html

[2] http://fedoraproject.org/wiki/Artwork

Smolt passed 100k mark

RolandWolters reports in his blog[1] ,

"Smolt passed the 100k mark, a month and ten days after the 50k mark. While almost all the machines are Fedora machines (since the project is at the moment fully included only in Fedora) there are also some dozen OpenSuse machines."

[1] http://liquidat.wordpress.com/2007/08/07/fedora-8-test-1-released-smolt-passed-100k-mark/

[2] http://smolt.fedoraproject.org/

FOSS.IN/2007 Announced

JamesMorris reports in his blog[1] ,

"The 2007 FOSS.IN conference has been announced[2] , and will take place in Bengalaru from December 4-8."

"It looks like they're tightening their focus on community development and depth of talks, as discussed by Andrew Cowie."

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

[2] http://foss.in/2007/info/Announcement

To Infinity and Beyond

JackAboutboul reports out in his blog[1] ,

"Today, I'm at LinuxWorld in San Francisco and I've just wrapped up a set of press interviews along with our very good friends from the Creative Commons. Whats the skinny you ask? I'll tell you, but only because I like you. Today we have announced[2] (link to press release) the first step in what is a long term partnership between Fedora and he Creative Commons. That first step is the CC LiveContent Distribution (available off the Fedora torrent site), built on Fedora, available to all."

[1] http://feeds.feedburner.com/~r/MadRhetoric/~3/141378247/to-infinity-and-beyond.html

[2] http://www.redhat.com/about/news/prarchive/2007/creativecommons.html


JackAboutboul reports out in his blog[1] ,

"I cannot begin to tell you how many people were so extremely enthusiastic about our little PS3[2] demo. People were walking up to us left and right asking us, "Hey is that Fedora on the PS3? That's wicked Cool!" I know, thats why I thought we should be showing that off. We even had a couple of IBM developers walk by us and tell us, "All of the cool innovation happens in Fedora anyway." Thats a direct quote."

[1] http://feeds.feedburner.com/~r/MadRhetoric/~3/141343423/oscon-wrap-up.html

[2] http://fedoraproject.org/wiki/PlayStation

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

New: Fedora Daily Package Weekly Video Summary

We've introduced a weekly screencast[1] of the packages featured as Fedora Daily Packages. The video is available from Google Video (flash and mp4/iPod Video formats) as well as OggTheora format. We look forward to your comments on this experiment.

[1] http://dailypackage.fedorabook.com/index.php?/archives/118-Fedora-Daily-Package-Weekly-Video-Summary.html

Qcad - Simple 2D CAD program

Productive Mondays highlight a timesaving tool. This Monday[1] we covered QCad[2] :

"Qcad is a two-dimensional drafting program, available in proprietary and GPL versions. Fedora includes the GPL version of QCAD, which does not have scripting or polyline support."

[1] http://dailypackage.fedorabook.com/index.php?/archives/113-Productive-Monday-Qcad-Simple-2D-CAD-program.html

[2] http://www.ribbonsoft.com/qcad.html

Gscan2pdf - Frontend for scanning utilities

Artsy Tuesdays highlight a graphics, video, or sound application. This Tuesday[1] Gscan2pdf[2] was featured:

"Gscan2pdf is a one-stop GUI tool for the production of high-quality PDFs from scanned images, providing a graphical front end for xscanimage, unpaper, gocr or tesseract, and other tools."

[1] http://dailypackage.fedorabook.com/index.php?/archives/114-Artsy-Tuesday-Gscan2pdf-Frontend-for-scanning-utilities.html

[2] http://gscan2pdf.sourceforge.net/

Wednesday Why: Fast User Switching

The Wednesday Why article[1] took a look at the Fedora's Fast User Switching configuration:

"Fast User Switching enables more than one user to log in to a local graphical user interface on a computer equipped with a single seat (monitor/mouse/keyboard) and permits quick switching between logged-in users."

[1] http://dailypackage.fedorabook.com/index.php?/archives/115-Wednesday-Why-Fast-User-Switching.html

Xephyr - New nested X server

GUI Thursdays highlight software that enables, provides, enhances, or effectively uses a GUI interface. This Thursday[1] , Xephyr[2] was discussed and compared to Xnest[3] :

"Xephyr is an alternative to the Xnest nested X server mentioned last week. Both of these programs provide a nested X display -- drawing into a window on a parent X server instead of drawing directly onto a hardware screen -- but they accomplish this in very different ways."

[1] http://dailypackage.fedorabook.com/index.php?/archives/116-GUI-Thursday-Xephyr-New-nested-X-server.html

[2] http://x.org/

[3] http://dailypackage.fedorabook.com/index.php?/archives/110-GUI-Thursday-Xnest-A-nested-X-server.html

Really Slick Screensavers

Friday Fun highlights fun, interesting, and amusing programs. This Friday[1] , we took a look at the Really Slick Screensaver collection[2] :

"The Really Slick Screensavers (RSS) -- OpenGL screensavers originally developed on Windows -- have been ported to work with X and integrated into the GNOME and KDE screensaver systems."

[1] http://dailypackage.fedorabook.com/index.php?/archives/117-Friday-Fun-Really-Slick-Screensavers.html

[2] http://rss-glx.sourceforge.net/


In this section, we cover Fedora Marketing Project.


Contributing Writer: ThomasChung

Red Hat And Its Fedora 8 Friends

RahulSundaram reports in fedora-marketing-list[1] ,

"When it comes to expanding the core feature set of Fedora, though, Fedora 8 has a lot to offer. JackAboutboul explained that a new dbus service launch service will aim to cut down boot time by minimizing the number of services that start when a machine powers up.

On the identity side, Fedora 8 will include something called freeIPA (Identity, Policy, Audit), which is intended to be an easy way for system administrators to install, setup and administer centralized identity management and authentication."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-August/msg00121.html

LinuxLinks Fedora 7 Review

ThomasChung reports in fedora-marketing-list[1] ,

"Fedora 7 has seen the word "Core" trimmed from it's name. This reflects just one of several changes internally to the project. With the first ever inclusion of tools to create your own version of Fedora, Fedora 7 really reaches out to the community, quite literally. If you don't like it, then by all means change it to be the way you want. The Fedora Project has given you the power. To date this is the most successful release of Fedora in my opinion."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-August/msg00114.html

Fedora 7: Community remix

RahulSundaram reports in fedora-marketing-list[1] ,

"One of the popular features of Fedora 7 is the ability to remix Fedora and build your own custom version. Now don’t get me wrong–building a new distribution is nice. But what about those who wish to create their own Fedora-based project? How do you grow a complete community in an enterprise environment or in the general public? Thanks to some of the lesser-known features, anyone can use the exact same tools that make Fedora, well… Fedora."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-August/msg00113.html

Fedora 7 Chosen as LiveContent CD Platform

RahulSundaram reports in fedora-marketing-list[1] ,

"The Fedora 7 Linux distribution has been chosen as the platform for the Creative Commons LiveContent[2] CD, an initiative to showcase free, open-source software and Creative Commons-licensed multimedia content"

"Fedora 7, which is the result of community-based open-source collaboration, has a new build capacity that allows for the creation of custom distributions and individual appliances."

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

[2] http://wiki.creativecommons.org/Livecontent


In this section, we cover the problems/solutions, people/personalities, and ups/downs of the endless discussions on Fedora Developments.


Contributing Writer: OisinFeeley

Xfs Going Away. Minor Bug In KDE Control Center

A report[1] from ArthurPemberton detailed a failure of Xorg to start after a shutdown. Arthur had figured out that it was something to do with the addition of the line FontPath "/usr/local/share/fonts" to his Xorg.conf. He further suspected that this line had been added by KDE's control center when he tried to add some TTF fonts.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00291.html

HansdeGoede thanked[2] Arthur for the clarity of the report and requested that he file a Bugzilla entry so that this problem could be elevated from mere discussion on @fedora-devel into an actual trackable, non-losable bug report.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00293.html

RahulSundaram agreed[3] with Arthur that Xfs (the X font-server) was deprecated and would be removed in Fedora8 eliminating this type of problem. Kelly wasn't impressed[4] with this due to past experience with Xorg being flaky when Xfs was disabled. RahulSundaram doubted this was true with more recent desktops which use fontconfig (e.g. Fedora7) and Kelly admitted[5] that the problems s/he experienced had been with Debian two years ago and never occurred with Fedora. Later[6] Kelly posted some unclear details which seemed to indicate a problem with Fedora7 in which Xorg will not start if Xfs is disabled. RahulSundaram seriously doubted[7] this on the basis of personal experience and asked Kelly to verify.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00294.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00298.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00300.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00303.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00304.html

An interesting addendum[8] was provided by MichaelSchwendt who thought that Rahul's blanket disavowal of problems like this in Fedora7 wasn't justified. Michael showed that both "emacs" and "xterm" would complain about missing fonts if xfs were stopped. In response to ArthurPemberton's suggestion that Michael add the font paths to his Xorg.conf Michael wondered why he should have to perform manual edits if Fedora7 was supposed to "run without xfs out of the box". Michael also provided a link[8] to a Bugzilla entry he had opened which suggests that the Fedora "compiled-in" font path deviates from that documented in the manpage.

[8] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251203

AndyGreen identified the use of "/usr/local" in the FontPath as suspicious and unusual for a package-mediated modification, which Arthur agreed with and reminded[9] that he had already fingered "KDE's font manager" as the possible culprit. Rahul noted that this provided the component against which Arthur could file a bug, which was duly done[10] .

[9] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00316.html

[10] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00440.html

RPM Roadmap Winds On

Ideas for improvements to RPM kept on rolling in (see FWN [1] and FWN [2] for earlier coverage). MatthiasClasen raised[3] the idea of support for language packs or else some way to install a limited set of locales. This would make LiveCDs much more useful.

[1] http://fedoraproject.org/wiki/FWN/Issue98#head-90b3708648e89def933055ad00d6cb887b9cde0d

[2] http://fedoraproject.org/wiki/FWN/Issue99#head-197a66d4dbef91d613deea97f40b26097fe794f6

[3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00306.html

Panu thought[4] that the problem with this was that metadata bloat would occur and that although the mechanisms to install a limited set of locales already existed they weren't useful because the only way to get any skipped languages back was to reinstall completely.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00364.html

A potential spanner in the works was identified[5] by JonathanDieter in the form of deltarpms. This will only work if all files are present from the original rpm (e.g. none excluded on the basis of locale) and yum would need instead to download the whole updated rpm instead of the smaller drpm.

[5] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00372.html

Matthias was undeterred[6] by Jonathan and JeremyKatz's worries and had confidence that the problem of verifying RPM integrity was solvable. ToshioKuratomi's solution of GPG-signing the rpm metadata made BillNottingham wince[7] when he considered the metadata bloat in which it would result.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00380.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00391.html

A request for "scriptlets" was submitted[8] by TillMaas along with examples of how they might be useful for installing, for example, .desktop files.

[8] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00522.html

NicolasMailhot added[9] two items to the wish-list: 1) true strong-dependency versioning; 2) noarch sub-packages for doc and noarch resources.

[9] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00779.html

Kmods: Does Fedora Intentionally Break 3rd Party Firewire Drivers? No.

The discussion of kmods is another long-running thread (see FWN#99 "Kmods Clarified"[1] ) and TillMaas provided a response[2] to ThorstenLeemhuis 's request for a specfile which uses DKMS in a mock-buildable SRPM which compiles modules shippable as kmod packages and also produces a DKMS file for dynamic kernel-module generation. Phew!

[1] http://fedoraproject.org/wiki/FWN/Issue99#head-98170522fb95c1c25efc05a5f2f6367656a7f174

[2] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00791.html

A longish thread centered around the negative experience which LesMikesell had with Firewire ceasing to function mid-version due to kernel updates. Les was fairly persistent in explaining his problem and in return RahulSundaram pointed to the problems of offering support for 3rd-party drivers given Fedora's development methodology. EmmanuelSeyman provided an excellent deconstruction[2a] of the argument that Fedora should be more like RHEL. RahulSundaram also noted that Les was seeking to change way in which the upstream kernel worked and that discussing it on @fedora-devel was pointless. ChristopherBrown didn't like[2b] Rahul's intervention and stated that he'd opened the topic (of kqemu originally) because @fedora-devel had a "better ambiance" and had a greater chance of generating an answer.

[2a] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00389.html

[2b] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00325.html

RahulSundaram noted[3] problem with Firewire had affected all distributions, not just Fedora, and that Red Hat had rewritten the firewire stack to solve it and it was now merged upstream. RahulSundaram also disputed Les's apparent suggestion that Fedora was intentionally breaking third-party proprietary modules.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00414.html

In a disclaimer[4] from Les, the specter of Fedora intentionally changing the ABI in order to "encourage users to switch to RHEL" was raised and rejected, with the caveat that there should be a statement that although third-party drivers may work at the start of a version there is no guarantee that they will work with any updates. Les also suggested that the Centosplus kernel was a good model and that Fedora should make "untested changes" opt-in. Rahul's reply[5] emphasized that all changes are opt-in anyway, that they are not untested, that the Centosplus kernel relies on a huge amount of back-porting which the Fedora Project can't do due to resource constraints. RahulSundaram also pointed out that it is completely clear that software outside of the Fedora Project repositories (for example any proprietary third-party modules) cannot be supported.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00423.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00424.html

A stronger statement[6] from AlanCox averred that the default expectation with Linux was that any such third-party drivers might break, and that RHEL was an anomalous case which resulted from great pain and hard work to preserve the kernel ABI. In addition Alan redirected the finger of blame to point at the packager of the third-party driver as rpm should have flagged the kernel-update as violating a requires. Les thought[7] that Alan's assumptions and those of a "typical new fedora user" were not congruent and that the distinction should be made clear on the Fedora Project pages. A short discussion between VilleSkyttä and Alan on the subject of when support had been introduced for requiring a specific kernel version occurred[8] with Ville apparently demonstrating that it wasn't for as long as Alan thought.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00426.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00432.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00436.html

JefSpaleta[9] and RahulSundaram[10] both thought that Les should run the updates-testing kernel and report any firewire bugs which he discovered.

[9] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00425.html

[10] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00434.html

A response[11] from ParagN to DavidWoodhouse's question about the "spca5xx" and "gspca" kmods provided some information about them. David's post also observed that the idea that Fedora would carry out-of-tree modules so long as they had either "a hope of going upstream" or "good reason to continue [being] carried forward" was unsurprising because this was exactly what Fedora had been doing for years.

[11] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00318.html

Parag's response didn't provide the information which David was looking for, namely were the modules good enough to be merged upstream and what needed to be fixed to convince Linus to take them. Parag responded[12] that the author wasn't interested in persuading upstream and questioned whether it was now a hard and fast rule that although a package was popular and functional it wouldn't be carried in Fedora if its author were unwilling to upstream it.

[12] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00437.html

New "finddebug-info.sh". Don't Run "ld" Directly In %build

A certain amount of surprise was expressed[1] by JesseKeating at the unannounced replacement of 'find-debuginfo.sh' in the latest rpm in the Koji build-system. Jesse noted the failures of some builds due to this change and his intention to revert it until there was supporting documentation to help package maintainers adapt. Jesse pointed to older information in the wiki about the purpose of these changes, which is to introduce a unique buildID into stripped objects and their corresponding '.debug' files.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00457.html

RolandMcGrath apologized[2] and explained that crossed-wires had resulted in him being unavailable to shepherd in the change for which he was entirely responsible. Roland emphasized that the script should be a simple drop-in replacement that only affected some corner cases and that he was available to help anyone with problems.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00472.html

After JesseKeating pointed to mock failing to build Roland explained[3] that this was due to a .so was being built improperly and that the new BuildID support had enabled this to be caught. JasonTibbitts was sure[4] that this .so issue was going to occur for other packages and that it should be documented by someone that had a thorough understanding. Roland agreed and wondered where that should be. A detailed explanation[5] by Roland followed explaining why ld should not be run directly and instead it should be called through gcc. TomCallaway was happy[6] because this would fix some sparc64 issues.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00475.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00477.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00481.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00488.html

JefSpaleta wondered[7] if local mock testing would help and Roland responded[8] that while BuildID would work exactly the same he had already taken care of obvious special cases (although he'd missed a problem with noarch packages) and he could quickly take care of any problems which occurred in Fedora development and testing, i.e. "rawhide".

[7] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00479.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00484.html

Further discussion with Jef, who favored using local mock builds before sending to the build server, failed to convince Roland that his current approach of introducing changes into rawhide and fixing the resulting breakage would result in mobs bearing pitchforks and torches. Roland questioned the need for a wordy documentation preferring to post to @fedora-maintainers. In response to his question "Do we really need a dissertation on the subject?" JesseKeating answered[9] "Nope. But send a note to 'fedora-devel-announce redhat com' alerting people that this change will go in, some builds may break when running the debug script, and that they should contact you for help."

[9] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00512.html

HansdeGoede was hopeful[10] that Roland had also fixed some ugly cross-building behavior in the old debuginfo.sh, but unfortunately it appeared not[11] although Roland declared his willingness to help out.

[10] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00486.html

[11] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00491.html

Enabling Compiz By Default

RahulSundaram wanted to know[1] if the default enabling of Compiz in GNOME had been considered.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00559.html

"Dragoran" thought it would be better to wait until it was possible to make OpenGL apps play nicely with AIGLX and posted[2] a link to an informative blog entry by KristianHoegsberg explaining the issues.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00562.html

A highly negative reaction[3] from AlanCox questioned the maintenance of Compiz and its problems with Java menus. Alan also pointed to the detrimental effects on power usage occasioned by its use.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00565.html

"Dragoran" replied that it was not Compiz which was broken, but Java, and provided a simple environment variable fix and wondered what Alan meant about Compiz being poorly maintained. Alan responded with "the user view point: I DON'T CARE" and argued[4] that compatibility worked because components didn't enforce strict standards compliance and hence Fedora needed to either: 1)fix Java; 2)set "Dragoran's" environment fix as default. "Dragoran" was in favor of #1, thought that #2 was a hack and pointed[5] to the number of commits in the git tree as evidence of the active maintenance of Compiz.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00580.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00585.html

A bugzilla was filed by "Dr.Diesel" pointing out[6] that "vino" (remote desktop utility using Xv) was broken with Compiz.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00598.html

More skepticism came[7] from JoshBoyer who wanted to know if Compiz could do basic window-manager tasks such as making a window present simultaneously on all desktops. "Dragoran" confirmed[8] that it could and later after JesseKeating had suggested enabling only subtle features such as drop-shading and fading windows Josh and MikeChambers agreed[9] that this might be useful as long as the basic WM features were working.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00591.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00593.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00660.html

BillNottingham was another naysayer, advancing[10] the breaking of other GL applications and Xv applications as reasons against enabling Compiz as the default. JonNettleton suggested choosing a compositing window manager which doesn't need OpenGL, but DaveAirlie answered[11] that this didn't solve Bill's two problems. Dave argued that Compiz wasn't broken, instead the problem is that drivers and GL are broken when compositing is enabled and that KristianHoegsberg (krh) and Dave's work on the Intel drivers was fixing this. The actual compositing manager doesn't make any difference due to regressions at the driver level.

[10] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00682.html

[11] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00742.html

The meat of the problem was exposed further in a thread started when BernardoInnocenti posted[12] that Ubuntu's "Gutsy Gibbon" was going to use Compiz-fusion (the merged Beryl/Compiz) by default and was fixing bugs to this end. Bernardo thought that AlanCox was wrong to believe that all compositing effects would be turned off and cited the high user-satisfaction with OSX's "Quartz". He also queried Alan's claims about power inefficiency. DaveAirlie responded[13] that Ubuntu were not fixing Compiz's technical problems and were benefitting asymetrically from Red Hat's work. RudolfKastl was keen on encouraging Dave's work and in response to his queries about getting a working "nouveau" driver (the FL/OSS nvidia driver) and a driver for r500 (ATI) into rawhide DaveAirlie responded that work on 3D redirection and on speeding up EXA were the important prerequisites for all compositing managers. (These projects are done with KristianHoegsberg and CarlWorth[14] respectively). The chances of a nouveau or r500 driver with these features are very small as only Intel have provided enough information to allow the necessary fixes to be written.

[12] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00589.html

[13] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00600.html

[14] http://cworth.org/blog/

JonNettleton pointed out[15] the advantages of 2D-compositing window-managers, such as "xfwm4" which works well with any EXA-supporting driver and in response KevinKofler drew attention to KDE4's "Kwin" (which will probably be in Fedora9).

[15] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00606.html

AlanCox explained[16] his claims about power consumption to IoannisNousias who had advanced the example of OSX. Alan's response was that Apple had taken advantage of independent power-management of the 2D and 3D graphics cores to achieve acceptable battery life overall. Ioannis didn't accept the argument and cited[17] examples of comparable battery longevity between an OSX system and an Xorg+metacity system, indicating that compositing wasn't a big drain. Ioannis further noted that the concern about power use seemed a little hypocritical given other Fedora choices.

[16] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00665.html

[17] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00724.html

A slight defence was mounted by KevinKofler who noted[18] that much work on reducing spurious wakeups was being undertaken (see also "Reducing Fedora Power Use" in this same issue of FWN#100), especially under the aegis of the OLPC project. Kevin also mentioned KWin again which led Ioannis to wonder[19] why compositing was accepted in KWin and Metacity but not Compiz.

[18] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00800.html

[19] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00822.html

DaveAirlie responded[20] that many applications would break for many specific drivers and that Intel hardware would probably be an exception once he and Kristian had made some more progress. After this any compositing manager could be chosen and that although Compiz might be overkill it could be acceptable if it had the same hotkeys as Metacity. Later Dave confirmed[21] to RahulSundaram that much work which he and Kristian had in hand needed to be upstreamed.

[20] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00825.html [21] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00827.html

Changes TO Cvsadmin Requests And ACLs

ToshioKuratomi posted[1] an announcement of changes which will be implemented over a couple of weeks. The changes concern the transition from flat files to a packageDB. Toshio's post provided essential information for packagers and an invitation to test the new functionality provided.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00546.html

One of the first queries came from ChrisWeyl who wanted to know[2] if the PackageDB would be updating the old owners.list or if the data would be otherwise exported in some other format. Toshio responded[3] that the data was available in JSON format, that owners.list was dead and gone and that there was a ticket open to create a simply greppable plain-text list. RalfCorsepius was irritated[4] that his scripts were now broken as a result of this.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00549.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00569.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00760.html

MartinSourada asked[5] whether "Cvsextras Commits" would now be set to "yes" if he had already removed "pkg.acl" in order to enable anyone in cvsextras to access his packages. According[6] to Toshio this depended on exactly when he had taken this action, with the cutoff point being the importation of the packagedb. Toshio suggested that Martin check this at https://admin.fedoraproject.org/pkgdb/packages/name/[PACKAGENAME]

[5] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00552.html

MichaelSchwendt sought[6] the status of the replacement of owner.list downloads+parsers and Toshio asked for further specification of the problem and provided links[7] which list: packages owned by a user; packages which has the user as a comaintainer or on cclist; packages which can set bugzilla; packages which can set cvs ACLs.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00624.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00697.html

In response to Toshio Michael clarified that he wanted a Python module and Toshio opened[8] a ticket for this and Michael further specified[9] that anonymous access to a package's src.rpm %name, primary maintainer, co-maintainers and cclist retrieved in a single flat-file or db would be simplest.

[8] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00753.html

[9] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00765.html

RalfCorsepius also described[10] similar requirements.

[10] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00761.html

Reducing Power Usage Of Fedora

BillNottingham asked whether we would like longer battery life and lower server power bills. He stated[1] that unnecessary CPU wake-ups were one of the biggest current problems and asked for our help in tracking down misbehaving applications by installing "powertop" and reporting the results. (See FWN#88 "PowerTOP Release Opens Up New Directions In Power Saving"[1a] .)

[1] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00544.html

[1a] http://fedoraproject.org/wiki/FWN/Issue88#head-f0b77fa701a85115b677b05bf3693fb5a594340b

A report from JonathanUnderwood about his LCD screen switching on/off while running powertop was confirmed by ArjanvandeVen to be abnormal and further details[2] were provided in a bugzilla report. TomLondon also had this problem.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00554.html

Trying to run powertop on F7 with the "-d" flag didn't work[3] for "nodata" who also wondered what to make of three Fedora-specific features which powertop suggests changing. In response AlanCox agreed[4] that disabling HAL polling of the cdrom was a good idea as was enabling AC97 powersave mode by executing echo 1 > /sys/module/snd_ac97_codec/parameters/power_save. BillNottingham cleared up the confusion[5] about the "-d" option with the information that it was only in the F8 version.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00557.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00564.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00611.html

RahulSundaram posted[6] his results from several weeks of powertop which included the suggestion of echo 5 > /proc/sys/vm/laptop_mode. "Dragoran" wasn't sure how useful this was and ArjanvandeVen responded[7] that laptop_mode did not spin down the disks, but rather clustered IO which was useful not merely with a battery but in large data centers.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00558.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00579.html

Integration with Smolt was suggested[8] by ChristopherBrown.

[8] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00637.html

RalfCorsepius wondered whether the kernel's failure to boot without ACPI disabled would class it as a misbehaving application and met JoshBoyer's request for a bugzilla entry with one he had filed in late 2006 and the information that this problem had started sometime in FedoraCore5. "Nodata" wanted[9] to start a tracker bug for "bugs that have been hanging around for ages, but aren't yet fixed"

[9] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00686.html

DebarshiRay added results which showed a python process taking second place (at 17% of wakeups) and further interest from BillNottingham prompted[10] Debarshi to list some candidates. ColinWalters pointed to a 10Hz loop in all PyGTK2 programs in Fedora as the source of the problem[11] and ArjanvandeVen thought there was no need for this on an NPTL[12] system.

[10] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00701.html

[11] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00704.html

[12] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00757.html

Disabling Atime

A link to the Linux kernel mailing list (lkml) was posted [1] by RahulSundaram to draw attention to the idea of disabling "atime" as a mounting option for filesystems in order to improve performance. Initial proposals from IngoMolnar were to use "noatime" to simply avoid the performance penalty imposed by heavy I/O with "atime". Based on discussion with Linus, AlanCox and others Ingo rapidly produced a modified version of this proposal which adds "relatime" as an option. "relatime" would simply not update the atime of the file unless there had been a modification in the interval since the last write.

[1] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00561.html

The main practical issues seem to be that mounting filesystems with "noatime" instead of "atime" on non-CPU-bound systems may provide serious performance increases. The downside is that applications which rely upon examining the atime of inodes (e.g. tmpwatch and mutt and possibly HSM[1a] ) will be broken. "atime" support is also necessary for strict compliance with POSIX.

[1a] Hierarchical Storage Management is also known as Tiered Storage and the practice of storing infrequently accessed files on slower/cheaper storage media (somewhat analogous to memory caches on CPUs): http://en.wikipedia.org/wiki/Hierarchical_storage_management

Reactions were mixed. "DrDiesel" thought[2] it would be worth testing and LesMikesell also was willing[3] to forgo two uses of atime (as an aid to verifying whether changes were being picked up). A brief discussion between Les and JohnReiser ended with a handy tip[4] from BobNichols.

[2] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00566.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00572.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00617.html

FlorinAndrei and "Dragoran" noted[5] positive experiences on a wide variety of systems as did AlexandruCiobanu[6] .

[5] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00571.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00576.html

An alternative suggestion (also on the lkml thread) is to use "relatime". This was proposed for Fedora by RudolfKastl and seconded by AlanCox. Rudolf was prompted by RahulSundaram to expand on his reasons for preferring "relatime" and explained[7] that merely switching off flawed features and working around slows down fixes. Cautious agreement was expressed[8] by EricSandeen who wanted more hard data provided by the advocates of change.

[7] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00599.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00685.html

RalfCorsepius was against the idea of disabling atime by default because it is a fundamental feature of UNIX filesystems. JamesHubbard expressed[9] disagreement based on the evidence that NFS optimization documents explicitly suggest disabling it and suggesting that most applications and users would benefit from its absence and the minority that needed could turn it on. Ralf's response[10] was skeptical and provided some figures which showed a much slimmer gain from "noatime" than reported by others. Ralf also pointed out that James might be considering only single-user desktop systems at the expense of other configurations.

[9] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00654.html

[10] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00667.html

In response[11] to the figures provided by Ralf it was suggested by JoshBoyer that the task (a heavy compiler run) wasn't that useful and that it would be better to do a "find / -exec cat {} > /dev/null \;" both with and without atime. DougMcClendon was happy to find some actual numbers[12] and thought that Ralf was underplaying the significance of the possible 5% advantage. Doug also noted the benefit to laptop drives which wouldn't need to be spun up to update the atime each time a cached file is read.

[11] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00678.html

[12] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00692.html

MartinEbourne reacted[13] to Ralf's post by questioning its rhetoric and restating that the idea was to provide a sensible default for the majority of users. Martin had been running "atime" disabled systems for over five years with no problems (with the caveat that he didn't use Mutt) and was surprised it had taken so long for the rest of the world to come around to this idea. A robust defense[14] of his position was mounted by Ralf who thought that Martin's logic was a slippery slope which could lead to the removal of many useful/essential features which impose some performance loss.

[13] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00744.html

[14] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00764.html

The issue of breaking "tmpwatch" was raised by MattMiller and after RahulSundaram noted the existence of a patch MilsolavTrmac wondered[15] what the rush was and suggested it would be easiest to wait for upstream (lkml) to sort out a decision. Rahul pointed out[16] that the lkml discussion had been redirected to @fedora-devel and that this was an old discussion and it would be good to make a decision.

[15] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00782.html

[16] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00786.html

LesMikesell suggested[17] a possible strategy for introducing the change gradually via an /etc/sysconfig file which contains mount options merge-able with /etc/fstab specified options. There would be no default options provided unless "noatime" were selected when prompted during install. Further discussion of this with BenjaminLewis (who thought that targetting the defaults to the simple home user case made more sense) led Les to outline the benefits in terms of following RedHat-style administration tools and preserving legacy defaults.

[17] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00783.html

ATIXpress200M And R500 Support For Fedora8

The 2007-07-08 Rawhide Report[1] excited ZoltanBoszormenyi because[2] it contained the promise of 3D support for the ATI Xpress 200M. Zoltan noted that the current Mesa (6.5.2) locked up with this driver and that Mesa-7.0.1 should be used instead. AlanCox asked Zoltan to file this as a security bug because it was a local DoS which he promptly did[3] .

[1] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00482.html

[2] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00494.html

[3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00626.html

DaveAirlie promised[4] to look at getting the new Mesa into the tree so that 3D support could be offered on the chipset and PeterGordon added[5] that this might also fix a Gnash problem with YouTube.

[4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00496.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00498.html

ManuelWolfshant wondered[6] whether the experimental, Free ATI R500 driver (which he had packaged succesfully for a friend) might be included in the xorg-drv-ati package. AdamJackson responded[7] that he would rather include it separately from -ati, but would like to see it in Fedora8.

[6] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00507.html

[7] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00536.html

Layering An IDS on Linux: Only Use Abort() If You Intend A Core Dump

SteveGrubb outlined[1] his plans to create a host-based IDS/IPS[2] system in the Fedora9 cycle. Steve was concerned that his feature in the 2.6.22 kernel which enables detection of buffer overflows may cause some programs to falsely trigger the IPS in the future if they call abort().

[1] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00272.html

[2] http://en.wikipedia.org/wiki/Host-based_intrusion_detection_system

MiloslavTrmac thought[3] that Steve's request flew in the face of tradition and POSIX and that only repeated abort()s should be taken as indications of a DoS. Steve argued[4] that Miloslav's objections only applied in a non-production, debugging scenario. Steve later expanded[5] on the problem in the face of Miroslav's continued objections and SimoSorce's suggestion that SteveGrubb outlined[1] his plans to create a host-based IDS/IPS[2] system in the Fedora9 cycle. Steve was concerned that his feature in the 2.6.22 kernel which enables detection of buffer overflows may cause some programs to falsely trigger the IPS in the future if they call abort().

[1] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00272.html

[2] http://en.wikipedia.org/wiki/Host-based_intrusion_detection_system

MiloslavTrmac thought[3] that Steve's request flew in the face of tradition and POSIX and that only repeated abort()s should be taken as indications of a DoS. Steve argued[4] that Miloslav's objections only applied in a non-production, debugging scenario. Steve later expanded[5] on the problem in the face of Miroslav's continued objections and SimoSorce's suggestion that as abort() was used so extensively it might be better [6] to give up on trying to stop abort() usage and to build SELinux-like application profiles.

[3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00276.html

[4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00278.html

[5] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00282.html

[6] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00310.html

AlanCox and ArjanvandeVen cooked up[7] the idea that although single SIGABRT terminations might be ignorable it would also be nice to dump core somewhere secure and then communicate the backtrace to the vendor. SteveGrubb (SteveG) confirmed that this would be easy to add as a plugin to the audit event dispatcher (audispd) [8] .

[7] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00305.html

[8] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg00309.html


In this section, we cover Fedora Maintainers, the group of people who maintain the software packages in Fedora.


Contributing Writer: MichaelLarabel


Ever visit packages.ubuntu.com or similar web-based deb package viewers? It sure is nice and has led JohnPye to question why we don't have a packages.fedoraproject.org[1] . There is the Fedora repobrowser but right now it's really not a prominent resource. PatriceDumas had replied with word that there is such an effort taking place with the new repoview version.

[1] https://www.redhat.com/archives/fedora-maintainers/2007-August/msg00151.html


In this section, we cover the Fedora Infrastructure Project.


Contributing Writer: JasonMatthewTaylor

Meetings and Voice Conferencing

JeffOllie and some others have been working on setting up a PBX service for difference groups as a way to enhance and perhaps enable others who don't have access to IRC a way to attend meetings.[1] The Infrastructure group as always is open to any suggestions for improvement.

[1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-August/msg00061.html

Using Asterisk

MikeMcGrath discusses the pros and cons of current meeting communication and the addition of asterisk.[1]

[1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-August/msg00075.html

Advisories and Updates

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


Contributing Writer: ThomasChung

Fedora 7 Security Advisories

Fedora Core 6 Security Advisories

Events and Meetings

In this section, we cover event reports and meeting summaries from various projects.

Contributing Writer: ThomasChung

Fedora Board Meeting Minutes 2007-MM-DD

  • No Report

Fedora Ambassadors Meeting 2007-08-09

Fedora Documentation Steering Committee 2007-MM-DD

  • No Report

Fedora Engineering Steering Committee Meeting 2007-08-09

Fedora Extra Packages for Enterprise Linux Meeting (Log) 2007-08-08

Fedora Infrastructure Meeting (Log) 2007-08-09

Fedora Packaging Committee Meeting 2007-08-07

Fedora Release Engineering Meeting 2007-08-06

Fedora Translation Project Meeting (Log) 2007-MM-DD

  • No Report

Extras Extras

In this section, we cover any noticeable extras news from various Linux Projects.

Contributing Writer: ThomasChung

Fedora 7 Book for FWN 100th Issue

For the latest guidelines and rules, please visit http://fedoraproject.org/wiki/FWN/F7Book