FWN/Issue102

Welcome to Fedora Weekly News Issue 102 for the week of August 20th. FWN/Issue102

Here is a highlight of this week's report:

In Ask Fedora, we have "Cleaning Old Files and Packages" and "CD Split For fedora 7."

In Daily Package, we have "Remind - GUI/Text reminder service", "Gallery2 - Web photo gallery", "Audio Setting Persistence", "Transmission - BitTorrent Client" and "BZFlag - Capture-the-flag in a Tank."

FYI, Fedora Weekly News will take a summer break until September 21st.

To join or give us your feedback, please visit NewsProject/Join.

Announcements

In this section, we cover announcements from various projects.

Contributing Writer: ThomasChung

There was no Official Announcement from Fedora Project last week.

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.

AskFedora

Contributing Writer: RahulSundaram, PaulFrields

Cleaning Old Files and Packages

Peter A. Shevtsov <webmaster@mera.com.ru>: From time to time I install some new software on my computers just to look at it, to try, to see if it is the right tool for me, etc. After reading new articles on Fedora Daily Package I run yum more frequently :)

This software requires some additional packages, libraries, etc. Also, it creates some config files in my home dir. But when I remove the software the redundant packages (libraries) and config files stay in my system. Is there any way to remove theses unused packages and old config files?

By way of answering your question about configuration files, consider that package updates are actually a remove and an install action. If configuration files were included in package removal, instead of sometimes treated specially, then upgrading a package might actually erase the administrator's system configuration! This is obviously not a desirable outcome, so many packages mark their system configuration files in the RPM database so they are not yanked off the system. To see if an installed package has a specially marked configuration file, use the command rpm -qc <package_name>.

If you want to clean your system of packages that are not required by any other software on your system, you can use the package-cleanup script that is part of the 'yum-utils' package. Install 'yum-utils' with the command su -c "yum -y install yum-utils" and then run su -c "package-cleanup --leaves" to see a list of these packages. Note that not every dependency installed during a transaction is necessarily a leaf. A more thorough way to remove packages you installed is by surveying the output of the command rpm -qa --last, which shows you recently installed packages listed by date.

You may also be interested in the repackage option, which you can add to your /etc/yum.conf file to be able to roll back your installed software state. Refer to the Fedora Daily Package site[1] for an excellent explanation of how this feature works.

[1] http://dailypackage.fedorabook.com/index.php?/archives/17-Wednesday-Why-Repackaging-and-Rollbacks.html

CD Split For fedora 7

Jack Gibbs <jbg2@att.net>: I need the address or url of the company that splits fedora 7 into CDs. thanks!

This information is available fro the Fedora 7 FAQ [1] . There are torrent files available too.

[1] Fedora7/FAQ#CD_Install_Images

Planet Fedora

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

Planet

Contributing Writers: ThomasChung

New Features in Fedora 8 - disable dontaudit rules

DanielWalsh reports in his blog[1] ,

"One of the features of SELinux is the ability to dontaudit certain access checks by a confined application. dontaudit rules are handy to force applications to take different code paths."

"In SELinux we prevent almost every application from reading the /etc/shadow file directly, causing pam to use it's help application. But this would cause a ton of AVC messages that look like sshd, login or apache are trying to read /etc/shadow. So we dontaudit these messages."

[1] http://danwalsh.livejournal.com/11673.html

Daily Package

In this section, we recap the packages that have been highlighted as a Fedora Daily Package [1] .

[1] http://dailypackage.fedorabook.com/

Contributing Writer: ChrisTyler

Fedora Daily Package Articles in Russian

Dmitry Beketov is now translating Fedora Daily Package articles into Russian and posting them at http://www.fedora-core.ru/content/blogcategory/14/34/

Remind - GUI/Text reminder service

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

"Remind is a very flexible reminder service which can be used from the command line. With the tkremind program (in the remind-gui package), it can also be used with a graphical user interface."

[1] http://dailypackage.fedorabook.com/index.php?/archives/128-Productive-Monday-Remind-GUIText-reminder-service.html

[2] http://www.roaringpenguin.com/en/penguin/openSourceProducts/remind

Gallery2 - Web photo gallery

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

"Gallery2 is an easy-to-use web-based photo gallery, built on PHP, which has many available plugins and an active user community."

[1] http://dailypackage.fedorabook.com/index.php?/archives/129-Artsy-Tuesday-Gallery2-Web-photo-gallery.html

[2] http://gallery.menalto.com/

Wednesday Why: Audio Setting Persistence

The Wednesday Why article[1] took a look at how Fedora saves audio settings during system shutdown and restores them during a reboot:

"You've probably noticed that ALSA settings for various input and output controls are preserved across reboots. The audio device state is saved in the file /etc/alsa/asound.state, a text file which contains a description of each device control and the current values."

[1] http://dailypackage.fedorabook.com/index.php?/archives/130-Wednesday-Why-Audio-Setting-Persistence.html

Transmission - BitTorrent Client

GUI Thursdays highlight software that enables, provides, enhances, or effectively uses a GUI interface. This Thursday[1] , Transmission[2] was discussed:

"The preferred method for downloading Fedora installation images is BitTorrent via the tracker at http://torrent.fedoraproject.org/ -- There are quite a few BitTorrent clients available in the Fedora repositories. One of the newest is Transmission..."

[1] http://dailypackage.fedorabook.com/index.php?/archives/131-GUI-Thursday-Transmission-BitTorrent-Client.html

[2] http://transmission.m0k.org/

BZFlag - Capture-the-flag in a Tank

Friday Fun highlights fun, interesting, and amusing programs. This Friday[1] , we took a look at BZFlag[2] :

"BZFlag is a team-based multiplayer 3D capture-the-flag game. You manouver your tank between pyramids and block buildings within a walled arena, shooting enemy tanks and collecting flags -- either to win the game (capture-the-flag mode) or to gain additional capabilities (free-for-all mode)."

[1] http://dailypackage.fedorabook.com/index.php?/archives/133-Friday-Fun-BZFlag-Capture-the-flag-in-a-Tank.html

[2] http://bzflag.org/

Marketing

In this section, we cover Fedora Marketing Project.

Marketing

Contributing Writer: ThomasChung

Fedora/Open Source Success Story

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

"We really want to highlight to everyone that not only is the freedom provided by open source software available, but is a key ingredient in success from a business standpoint. Yes, as with any business there are obstacles, but with open source solutions these have been very minor when they could have been devastating."

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

A view of Linux as introduced by a blind user via Orca

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

"Windows is still not my preferred operating system" reports Darragh at the end of his audio tour. "With the recent advances in Orca in GNOME, and the fact that with the work of the people on the Speakup Modified group, Fedora 7 makes it very easy to set up, and with the combination of everything it's just so fast to use; it's really becoming just a pleasure."

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

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

KDE: Replace Dolphin With D3lphin?

ChitleshGoorah wanted to know[1] whether "dolphin" (a file-manager) should be replaced with "d3lphin", which is a fork with some improvements and fixes. He outlined the process by which dolphin might be obsoleted by d3lphin and asked whether he should go ahead with it.

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

In response[2] to PraritBhargava it was further explained that upstream KDE had decided to no longer maintain dolphin in KDE3 and the fork was a backport of bugfixes.

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

RexDieter was mostly in favour but RahulSundaram wondered[3] why Chitlesh didn't just include the patches and retain the name, especially as the fork was likely to be short-lived.

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

Discussion then centered on what the package should be named and what it should state it is providing and obsoleting. JohanCwiklinski thought[4] that it would be better to name the package "d3lphin" and have it obsolete and provide "dolphin" due to the fact that this reflected upstream naming. He also argued for not maintaining both packages simultaneously. This made MattMiller concerned about upgrading due to the co-existence of the KDE4 package, but LaurentRineau saw[5] little to worry about as the KDE4 "dolphin" is in the package named "kdebase" and is not separate.

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

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

Rahul noted[6] that Chitlesh's provision of packages for both methods meant he could go either way, but that patching the existing dolphin would have been less work.

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

Rebuilds Essential For Fedora 8

The need for the rebuilding of 2845 packages was posted[1] by JesseKeating. Jess explained that a bad "binutils" in the buildroots had caused a problem for SELinux and also that binary packages with debuginfo built before build-id (see FWN#100 "New finddebug-info.sh. Don't Run ld Directly In %build"[2] ) needed to be rebuilt. It was desirable to have this work completed before the Test2 freeze date (28th Aug).

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

[2] FWN/Issue100#head-e6a52df4480369d67463ec269472c2f1a4545201

Jesse included a link to a list of the affected packages[3] produced by a script which he refined several times in response to feedback.

[3] http://jkeating.fedorapeople.org/really-need-to-rebuild

In addition, the license tags are supposed to be fixed up, but Jesse drew attention to the large number which are known not to be. Jesse outlined the logistical problems of trying to rebuild the packages, or rely on the packagers to fix these issues and rebuild themselves and finished with an appeal for input from the community.

PaulHowarth wondered what were the cut-off dates for the ppc32/SELinux issue and for the buildid/debuginfo issue and Jesse responded[4] that they were respectively "anything built with binutils between versions 2.17.50.0.16 and 2.17.50.0.17-7" and "Anything that is binary, has -debuginfo, and hasn't been built with rpm-4.4.2.1-7 or newer (which landed around 2007-08-14 02:00:00.000000 koji time".

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

ChristopherBrown thought that slipping the Fedora 8 Test2 release by a week and trying to contact maintainers and upon failure to rebuild allowing any other maintainer to rebuild at will would solve things, but this didn't attract JoshBoyer on the grounds[5] that it was too complicated and probably unnecessary.

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

ThorstenLeemhuis also wanted[6] to keep to the Test2 release date. In order to get the work done he suggested a script which would add a ".1" to the release and rebuild automatically any package not queued or rebuilt by some time. A further script would email maintainers who were delinquent in updating their license tags.

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

Following JesseKeating's interest in Thorsten's proposal a request came in[7] from MiroslavLichvar to put the ".1" before the %{?dist}. VilleSkyttä thought that this was undesirable as it broke the purpose of %{dist} and a longish discussion followed in which this viewpoint seemed to predominate, with Jesse finally plumping[8] for appending ".1" to %{dist}. A side-thread arose[9] when RalfCorsepius noted the problems that the current convention of using x in %changelog entries instead of x%{?dist}. Ralf specifically pointed out that the problem with Jesse's method would be that the release tags in the changelog would not match the actual %release tags. This quickly diverged into a discussion of using SCMs to hold the changelog instead of keeping it in the package with ColinWalters advocating[10] the use of Koji or other online solutions and other contributors pointing out the advantages of a non-networked, CLI interface to the information.

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

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

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

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

An email from ToddZullinger updated[11] the list of improperly licensed packages (67%) and ToshioKuratomi[12] and MichaelSchwendt[13] helped him generating a mapping between packages and maintainers in the new PackageDB.

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

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

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

Returning to the central issue RayStrode wondered[14] why the rebuild wasn't just automated instead of wasting developer time which could be spent on adding new features.

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

JoshBoyer responded that an automated rebuild might disrupt the ability of the maintainer to implement changes and that searching for AWOL maintainers was also important. JesseKeating added[15] that automation tied up a package set potentially for days. Jesse further explained[16] this in response to Ray's questioning with the information that automated rebuilds occur at low priority and so can be held back in a queue until a maintainer's non-automated build is done. The automated build is then queued and because it is completed later it becomes the latest version and the non-automated build (with all its changes) is lost. In addition the License-tags really are a rebuild issue and should be done now instead of later so that any unexpected consequences surface with time to fix them.

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

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

23rd Aug FESCo Meeting

An invitation[1] from BrianPepple to introduce missed topics to the FESCo IRC meeting[2] was embraced by several people.

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

[2] http://bpepple.fedorapeople.org/FESCo-2007-08-23.html

Specifically HansdeGoede ensured[3] that there was discussion about making "initscripts" LSB compliant (see "Making Initscripts LSB Compliant" below in this same FWN#102 for full coverage).

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

The most meaty topic of the meeting concerned two related proposals. The first was that articulated[4] by DavidWoodhouse to obsolete "kmods" from Fedora altogether. David's proposal argues that kernel modules shouldn't be shipped as separate packages. Instead patches to the kernel package should be accepted at the discretion of the kernel maintainers (DaveJones and ChuckEbbert). Contributors would be allowed commit access to the kernel solely for their own patch.

[4] DavidWoodhouse/KmodProposal

The clearest objections came from ChristopherAillon who wanted to know what precedent there was for allowing the maintainers of a "base" package (e.g. kernel, firefox) to influence the rejection of "addons" to that package (e.g. kmods or firefox-extensions respectively).

The second proposal came from JefSpaleta and suggested[5] that DKMS [6] could be used to ship the source of "out-of-tree" kernel modules which could be dynamically rebuilt to work with updated versions of the kernel. This seemed to offer a possible way out of the impasse described above as it has the advantage of opening up the contribution process to experimental modules which could then be mainlined later. The honed and crafted stable Fedora kernel would be unaffected and only those chosing to opt-in to the experimental modules would experience their vagaries.

[6] JefSpaleta/DKMSProposal

MattDomsch and JesseKeating noted during the meeting that JeremyKatz's input was likely to be critical as he objected to having a second, non-rpmdb database to track to find what is actually in /lib/modules. Jef seemed to feel that this might be solvable, but Jesse was less encouraged.

Several other meeting participants, e.g. ToshioKuratomi(abadger1999) shared some of ChristopherAillon's worries about general rules excluding add-on packages, but recognized its limited, practical value for the special case of the kernel modules.

The conclusion was that this needed to be discussed at greater length on @fedora-devel and that Jef, David and Jesse needed to produce a mutually agreed proposal.

Development Spin

An email from AndrewOverholt announced[1] the creation of a SIG for making a development specific spin of Fedora. Goals included but were not limited to: providing tools, making targeting Fedora easier for developers, making Fedora-developers lives easier. These open-ended goals include deriving the spin from "Fedora Desktop" and including Eclipse, Koji, Systemtap, Frysk, GCC-toolchain, Emacs and enabling the debuginfo repository. An explicit goal is to attract new developers to Fedora.

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

There appeared[2] to be an immediate problem with the desire to enable the debuginfo repository when JesseKeating pointed out that it would involve changes to the fedora-release package or else post-install processing. The latter seemed likely[3] when JeremyKatz added that the spin would be based off the LiveCD image as opposed to a traditional install. Jeremy added that it would be good to figure this out for the latter too.

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

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

Jesse didn't like[4] the idea of modifying packages using a %post in kickstart immediately after they've been installed and wondered whether ChristopherAillon's suggestion[5] of copying the .repo file into a special fedora-release-debuginfo package which would only be installed on this spin was as unappealing as appeared at first blush.

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

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

DanHorak and JonathanUnderwood requested[6] their favorite IDEs to be added to the spin (which Andrew in his initial email admitted was going to be a bulky DVD).

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

The general idea was exciting[7] to ColinWalters, who also identified three likely classes of users and suggested that developers of Fedora could be left to fend for themselves, whereas amateur web-developers and professional coders would be a larger audience. Colin had some more specific ideas[8] about how the configuration of such a system was much more important than simply the packages which were shipped with it, these included: making finding software easier; starting appropriate applications by default; having a running Xen image to make it easier to deploy apps on Xen.

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

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

Making Initscripts LSB Compliant

HansdeGoede asked[1] a short while ago whether or not he should close some bugs currently open on his packages which contained initscripts. The bugs suggested that the initscrips should be LSB compliant[2] and there was some discussion about switching to a different init system (such as sysinit-ng) but no resolution was offered.

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

[2] http://www.linux-foundation.org/spec/refspecs/LSB_3.1.0/index.shtml

Similar doubts were expressed[3] at that time by MatthiasSaou about the "Unanswered questions" on the wiki page and VilleSkyttä pointed out[4] that "rpmlint" wasn't much help.

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

In the 23rd Aug 2007 FESCo meeting[4] the issue was advanced again by Hans. The consensus during the IRC meeting seemed to be that HaraldHoyer knew most about this (and had filed the bugs) and should create a formal proposed guideline document in the wiki. WillWoods was interested to hear that requiring "redhat-lsb" is uncool as it bloats the install.

[4] http://bpepple.fedorapeople.org/FESCo-2007-08-23.html

BuildID And Proprietary Drivers

StewartAdam posted[1] a plea for help when he found the rpmbuild failed when he tried to build ATi and nVidia proprietary drivers for the devel branch at Livna.org. Stewart was aware that proprietary, binary drivers weren't something which the Fedora Project could help with but wondered if someone could help with the specific error which was due to the absence of buildids. The problem was that buildids couldn't be added to the binary and Stewart thought this showed exactly why binary-only drivers should be avoided.

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

A response from RolandMcGrath suggested[2] a define which might switch off the behavior and wondered whether a debuginfo rpm could contain any useful information about a binary anyway. VilleSkyttä was a bit concerned[3] with the non-stripping of binaries that would then occur and suggested a correction to Roland's define.

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

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

Roland suggested[4] that Ville's worries were unfounded because even when debuginfo is enabled /usr/lib/rpm/redhat/brp-strip is run, he also asked for any of the "rpm wizards" who had helped to set up the current macros to speak up on what the preferred method was.

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

JeremyKatz confirmed[5] that Ville's method was the preferred one and a happy StewartAdam confirmed[6] that he no longer saw the BuildID errors and suggested including this information on the wiki page for BuildID.

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

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

KDE4 Not A Feature Of Fedora 8?

HansdeGoede mentioned[1] that he had started packaging a KDE game (ksirk) and been surprised to find no kde4 packages in rawhide. Hans wondered what the status was and what he could do to help. Strictly speaking most of the discussion on this occurred during the timeframe of the previous FWN issue, but it's important and useful information.

(See FWN#99 "KDE4 Status"[2] for previous coverage of this topic).

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

[2] FWN/Issue99#head-518400f8171178c344dc79f45572bfc5b24f2acc

An initial response from MichelSalim advanced the information that KDE4 probably would not be included in Fedora 8 and that there would be some parallel-installable packages. Michel also noted that SuSE (due to release in October) will not be shipping KDE4. This drew a rather short response[3] from Hans who asked those of us without a clue to RTFM and refrain from answering questions. Michel referred[4] Hans to specific @fedora-devel threads. Subsequent defence of Michel both on grounds of his correctness and for politeness led Hans to explain[5] that he wished a high signal/noise ratio and had been misled by the outdated wiki entry. He subsequently issued[6] an unreserved apology to Michel.

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

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

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

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

JoshBoyer stated that KDE4 would not be in Fedora 8, which RexDieter reproved[7] , suggesting that no final, absolute decision had been reached in this regard. Further discussion with Josh however brought out the information[8] that the most likely scenario for Fedora 8 is that there will be a KDE3 desktop (desktop manager, window manager etc) and a KDE4 runtime (libraries and resources for developing and running KDE4 applications). Rex saw two other possible scenarios of a KDE4 desktop and KDE3 runtime and no KDE4 runtime at ship date at all. One of the points of confusion cleared up was that if something isn't in Test2 then it isn't going to be a Feature.

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

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

Rex stated[9] that if the KDE4 desktop was not ready by Test2 then it would not replace the KDE3 desktop mid-release.

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

After investigating the issue Rex posted[10] later to say that KDE4 would realistically not be in Fedora 8. Rex was upset about this and managed to be both polite and profane. HansdeGoede stepped up to the plate yet again to offer assistance[11] and was joined by JoséAbílioMatos and "MarkG".

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

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

AdamTkac was keen[12] on moving to KDE4 right now, but JoshBoyer suggested that the KDE team had a better grasp of the practicalities and RexDieter said[13] "there is a basic level of functionality and reliability [...] which simply isn't there yet", and encouraged anyone interested to join the KDE SIG[14] .

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

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

[14] SIGs/KDE

Auto-Opening Of Ports In Firewalls By Services

A proposal[1] from JóhannGuðmundsson to implement a method to allow services to automatically punch holes in the firewall suggested that the best way of doing this might be for a service to read a firewall configuration file and add iptables rules based upon it on starting (and conversely remove those rules when stopping).

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

In favour was JeremyKatz. He added[2] the question whether it was better to make the iptables change during starting/stopping (as suggested by Johann) or to do it at chkconfig time. The advantage of the latter is that it avoids having to make initscript changes, but the former seems more "correct".

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

SimoSorce was less enthralled[3] by the prospect of having iptables rules overridden or else having to change the initscripts and/or reapply the rule each time the service starts or stops. Simo also wondered whether Jeremy was right about it being more correct to make these changes at start/stop, and also wondered to which interfaces this would apply.

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

"Nodata" and JonCiesla both looked[4] like they'd be part of a pitchfork-bearing mob if their custom firewall settings were disrupted by this functionality. ArthurPemberton agreed[5] with JonCiesla that perhaps tying this in to system-config-securitylevel would allow the functionality to be disabled in one easy place by admins. DaveHollis thought[6] that integrating existing protocols for modifying firewalls (UPnP, NAT-PMP[7] ) by talking to avahi and using DBUS to prompt for user input offered a better path. LennartPoettering noted[8] that someone was already developing such a module for avahi.

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

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

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

[7] http://en.wikipedia.org/wiki/NAT-PMP

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

Like Simo SaikatGuha wondered[9] what would happen with VPNs, and also suggested that system-config-security could be modified to allow the opening of ports per service (instead of explicitly by port) with functions added to initscripts to look at this.

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

BennyAmorsen posted[10] a slightly tongue-in-cheek implementation of Johann's idea, suggesting that all he needed to do was to remove the firewall completely.

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

TeXLive Licensing Problem?

In the continuing drive to get License tags sorted out PatriceDumas was doing his part and examining TeXLive (see FWN#101 "TeXLive Status"[1] ). Patrice noticed[2] an obligation to send notifications to the copyright holder for "dvips" and "makeindex". Patrice wondered if these requirements were considered to be the same to the very similar Academic Free License (AFL) which is considered a Free license.

[1] FWN/Issue101#head-5af8a93231914c675179704329893a9d0fc7a275

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

RahulSundaram argued[3] that there was a difference between a requirement and a request and that hence the AFL was different. Patrice was unsure about this as the AFL license used the word "must", but demurred that he was not a native speaker of English.

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

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

A re-reading of the AFL by Rahul seemed[5] to show that the obligation was to convey to the recipients the license terms. Patrice concurred[6] with this and said that he had noted the issue in the TeXLive review.

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

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

dist-rawhide Not A Valid Target In Koji

DebarshiRay (rishi) was stumped[1] when using the standard BuildRoot setup he couldn't build two of his packages from scratch. The specific error message was "BuildrootError: could not init mock buildroot, mock exited with status 100."

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

A quick response[2] from MamoruTasaka suggested that Rishi try to use "dist-f8" instead of "dist-rawhide" and although this worked Rishi was puzzled because koji list-target provides it as a possibility.

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

JesseKeating answered[3] that it was not "a fully valid target" and that it had been created to allow pointing mock at a static repository of rawhide on people's systems.

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

Translation

This section, we cover the news surrounding the Fedora Translation (L10n) Project.

L10N

Contributing Writer: JasonMatthewTaylor

Developer Wiki Page

DimitrisGlezos put up a page[1] with information for maintainers looking to get their project/resource translated[2] .

[1] L10N/ResourceMaintainers

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

String Freeze Policy

DimitrisGlezos posted[1] that there is now an official String Freeze Policy, the idea is to give translators concrete timelines without worry about overwrites and the like.

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

[2] ReleaseEngineering/StringFreezePolicy

Translation Quick Start Guide

NorikoMizumoto posted[1] some changes to the guide[2] and as always the team is looking for additions and improvements.

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

[2] L10N/Tasks/TQSG

Infrastructure

In this section, we cover the Fedora Infrastructure Project.

Infrastructure

Contributing Writer: JasonMatthewTaylor

Turbogears and Memory Usage

MikeMcGrath requested[1] some application owners and whoever else may have some free time to investigate to ensure that the applications are using their memory as intended as the machines are swapping frequently.

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

Asterisk on the Wiki

MikeMcGrath posted[1] about a page created[2] to inform others about Asterisk and some basic troubleshooting.

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

[2] Infrastructure/Asterisk

Bugzilla Upgrade

ToshioKuratomi posted[1] a breakdown of expected problems with the proposed Bugzilla upgrade. He also posted some post upgrade notes[2]

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

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

Security Week

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

Contributing Writer: JoshBressers

July 2007 Operating System Vulnerability Scorecard

• http://blogs.technet.com/security/archive/2007/08/16/july-2007-operating-system-vulnerability-scorecard.aspx

I ran across this vulnerability report. The goal of which appears to be to show that Windows Server 2003 has fixed significantly fewer flaws than various other operating systems. Upon reading the report, the first thing that popped into my head was "But what about the things that aren't fixed?" There are quite a few reports like this, none of them really say much. We can safely say that any report is going to show that lots of things get fixed in operating systems that contain lots of things.

I wouldn't mind seeing an report about the various outstanding flaws in a given system. Such a report is likely impractical to produce, as it's a full time job to track outstanding flaws, but it would no doubt be useful. It's very easy to draw the shortsighted conclusion that the more flaws a vendor fixes, the more insecure their product is. It would make just as much sense to say that the fewer flaws a vendor fixes, the more outstanding things they are still vulnerable to.

Advisories and Updates

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

FSA

Contributing Writer: ThomasChung

Fedora 7 Security Advisories

• sysstat-7.0.4-3.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-August/msg00311.html
• kdelibs-3.5.7-20.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-August/msg00316.html
• kdebase-3.5.7-13.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-August/msg00317.html
• po4a-0.32-4.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-August/msg00333.html
• libvorbis-1.1.2-3.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-August/msg00343.html
• id3lib-3.8.3-17.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-August/msg00358.html
• bochs-2.3-7.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-August/msg00362.html
• kernel-2.6.22.4-65.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-August/msg00371.html
• pam_ssh-1.92-2.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-August/msg00378.html

Fedora Core 6 Security Advisories

• dovecot-1.0.3-6.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-August/msg00303.html

Events and Meetings

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

Contributing Writer: ThomasChung

Event Report: WBUT install fest. part 1

• https://www.redhat.com/archives/fedora-ambassadors-list/2007-August/msg00058.html

Fedora Board Meeting Minutes 2007-08-21

• https://www.redhat.com/archives/fedora-advisory-board/2007-August/msg00119.html

Fedora Ambassadors Meeting 2007-MM-DD

• No Report

Fedora Documentation Steering Committee 2007-08-21

• https://www.redhat.com/archives/fedora-docs-list/2007-August/msg00059.html

Fedora Engineering Steering Committee Meeting 2007-MM-DD

• No Report

Fedora Extra Packages for Enterprise Linux Meeting 2007-08-22

• https://www.redhat.com/archives/epel-devel-list/2007-August/msg00136.html

Fedora Infrastructure Meeting (Log) 2007-08-23

• https://www.redhat.com/archives/fedora-infrastructure-list/2007-August/msg00138.html

Fedora Localization Project Meeting 2007-08-21

• https://www.redhat.com/archives/fedora-trans-list/2007-August/msg00082.html

Fedora Packaging Committee Meeting 2007-08-21

• https://www.redhat.com/archives/fedora-maintainers/2007-August/msg00567.html

Fedora Release Engineering Meeting 2007-08-20

• https://www.redhat.com/archives/fedora-devel-list/2007-August/msg01400.html