FWN/Issue108

From FedoraProject

< FWN
Jump to: navigation, search

Contents

Fedora Weekly News Issue 108

Welcome to Fedora Weekly News Issue 108 for the week of October 29th. http://fedoraproject.org/wiki/FWN/Issue108

In Announcements, we have "Fedora Core 6 End of Life"

In Planet Fedora, we have "Fedora 8 Release is on its Way Out", "Fedora 8 Release Summary", "Upgrading from Rawhide to Final Release" and "Codec Buddy Interview"

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


Announcements

In this section, we cover announcements from Fedora Project.

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

Contributing Writer: ThomasChung

Fedora Core 6 End of Life

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

"A reminder to users: Fedora Core 6 will reach its end of life for updates on Friday, December 7, 2007."

"Fedora 7 will remain supported until one month past the release of Fedora 9 (as things stand, this would be roughly through the end of May, 2008)."

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

Planet Fedora

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

http://fedoraproject.org/wiki/Planet

Contributing Writers: ThomasChung

Fedora 8 Release is on its Way Out

JeremyKatz points out in his blog[1] ,

"As a few other people have mentioned, we finished up Fedora 8 on Friday and it's currently on its way to the mirror masters so that the mirrors should be able to start picking it up tomorrow (just pending getting the export control bits into place) and we'll be releasing on Thursday. Overall, I'm feeling pretty good about the release -- we got some good things in and I think that a lot of the improvements should be pretty visible to most of our users. Doesn't mean there are things that could be better or that we could do better from a process perspective. But for the moment, I think I'm going to try to enjoy the fact that the release is done."

[1] http://katzj.livejournal.com/408520.html

Fedora 8 Release Summary

JonathanRoberts points out in his blog[1] ,

"Fedora 8 is out in 5 days now and as part of our final marketing efforts we’ve been putting together a release summary. Take a look at it, and if there’s a new feature that you really like and we’ve missed, add a section on it! And if there’s a feature you really like that we haven’t done justice too, (please remember, we’re trying to keep it brief) expand and improve on what we’ve done!"

[1] http://blog.questionsplease.org/2007/11/04/release-summary/

Upgrading from Rawhide to Final Release

MaxSpevack points out in his blog[1]

"Every release cycle, there seems to be confusion about how to transition over from Rawhide (the nightly build of Fedora) to whatever the final release is (in this case, Fedora 8). This confusion is understandable, because at first glance the process is a bit magical. Let's see if I can explain it a little bit. The short answer is this: you don't have to do anything! It will Just Work."

[1] http://spevack.livejournal.com/33314.html

Codec Buddy Interview

JonathanRoberts points out in his blog[1] ,

"Starting to pick up the pace a bit to make sure I get all the interviews covered before Fedora 8’s release. Any how, with that aside, the latest interview is up: this time it’s about Codec Buddy and unlike previous interviews is with two of the primary developers behind this feature - ThomasVanderStichele and BastienNocera; like always it’s a really great read as they discuss many different topics, and you can even find some screenshots showing the process of enabling MP3 playback with Codec Buddy."

[1] http://blog.questionsplease.org/2007/11/02/codec-buddy-interview/

Marketing

In this section, we cover Fedora Marketing Project.

http://fedoraproject.org/wiki/Marketing

Contributing Writer: ThomasChung


Fedora struggles with harm reduction via CodecBuddy

RahulSundaram reports in fedora-marketing-list

"In public health, harm reduction is a practice that, rather than trying to eradicate potentially dangerous choices like prostitution, tries to minimize their effects. Often, the practice involves a limited condoning of the practice, such as safe injection sites for addicts. Harm reduction is the path that Fedora 8 has chosen on the issue of MP3 and other non-free codecs in the form of CodecBuddy, a Codeina-based program that tries to educate users about free software while giving them easy legal access to codecs by linking to the commercial Fluendo site. It's a decision about which the Fedora Board and community leaders feel considerable ambivalence."

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

PulseAudio by default in Fedora 8!

RahulSundaram reports in fedora-marketing-list,

"PulseAudio is a next-generation sound server for GNU/Linux, creating the possibility of enabling all sorts of "ear-candy": it's possible to dynamically control the volume of individual applications, and hot-plugging works great with it. Read on for more details, including what can be expected in the future."

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

New Display Tool Coming In Fedora 9

RahulSundaram reports in fedora-marketing-list,

"There's less than two weeks now until the release of Fedora 8, which has been codenamed Werewolf. However, it's not too early to start thinking about Fedora 9. One of the items that has already been brought up for this next release cycle is a new display utility. While there is the rather basic system-config-display utility from Red Hat, Fedora is currently lacking a graphical tool to change or enable display devices (such as LCDs or TVs) in real-time."

[1] https://www.redhat.com/archives/fedora-marketing-list/2007-October/msg00421.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

Package EVR Problems

The recent series of automated reports from the buildsystem showing problems with the EVR[1] of packages prompted RolandMcGrath to suggest[2] that updates pending in bodhi, but not yet pushed should be considered by the script generating the reports in order to either suppress the complaint or to notify release-engineering instead of the maintainer.

[1] EVR stands for Epoch, Version, Release. See http://www.redhat.com/archives/rpm-list/2004-August/msg00117.html

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

This was answered by MichaelSchwendt with the suggestion that bodhi could have an interface for anonymous users added and with a link to the script generating the reports, to which Michael has contributed substantially suggesting that patches were welcome. JesseKeating added[3] that there is a command line interface for bodhi in the works.

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

Some brief confusion occurred when DouglasWarner pointed out[4] that if a package is sitting in updates-testing and has not been pushed into stable then that constitutes a broken upgrade path and the maintainer should be notified. Douglas thought that Roland was asking for the notification to be suppressed. JesseKeating corrected[5] this however with the information that the party responsible for the push was release-engineering and not the maintainer and that Roland wished the emails to no longer go to maintainers as they had already done their part.

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

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

There were objections from TillMaas and RalfCorsepius about the schemes for choosing the NEVR (Name, Epoch, Version, Release) of RPM packages. These detailed arguments center around what is understood to be the purpose of the testing, stable and development repositories. The varied interpretations have the practical result of differing upgrade capabilities from one repository (and distro version) to another. There are also implications for the amount of work which maintainers would have to do, and this was highlighted[6] by Till. MichaelSchwendt countered[7] this with the observation that currently the upgradepathcheck script will soon have to consider more than one updates-testing repository and that ignoring what it reports has historically resulted in less preparation of updates for the most recent test release.

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

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

RalfCorsepius argued[8] that testing should be limited to specific distros due to their unique environment and that the testing repositories should contain experimental packages which may not end up in updates. A detailed discussion between Michael, Ralf and KevinKofler followed[9] with Ralf apparently arguing that their vision of using a consistent EVR scheme which allows concurrent release and testing of packages in multiple distributions is flawed. Ralf's assertions about Michael's vision of how EVR naming should interplay with the different repositories were described as "ridiculous" in a lengthy and thoughtful post[10] from Michael. In it Michael repeated that it was necessary to test updates in all the possible distribution environments and promised that the next report would once again exclude F-7 updates-testing from the check. Michael also argued that Ralf was being overly negative and unhelpful.

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

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

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

JesseKeating later joined[11] the discussion and argued that Ralf was not considering the reality that packages in testing are frequently promulgated into the stable release. It's a detailed and confusing thread which does not lend itself to easy summary and ended[12] in Jesse claiming that Ralf was mis-characterizing the situation as a disagreement between himself and Jesse, whereas in fact it was between Ralf and the majority of maintainers..

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

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

MP3 Licensing Issues

The issue of whether it is legal to include mp3 decoders (in the form of mpg123) and possibly add support for join stereo coding was floated[1] by PeterLemenkov who had been reading around and noticing that the core patent was due to expire in a month. Peter stated his understanding of the situation to be that OGG Vorbis (erroneously referred to simply as Ogg) may violate patents, that there were non-commercial exceptions made , that many of the patents referred to encoding rather than decoding and thus were not applicable and finally that the Frauenhofer patents had expired in the EU. He wondered if they also had expired in the USA.

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

The status of the freedom of the rights granted under the non-commercial exceptions was foregrounded[2] by RahulSundaram who stated that they were incompatible with the GPL. Rahul also asked for evidence that OGG Vorbis violated patents.

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

SimoSorce felt[3] that part of Rahul's reply was not precise enough when it cited the GPL and despite TomCallaway concurring with Rahul's interpretation Simo disagreed that the GPL made it necessary for an author to also supply a written non-limiting patent grant.

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

The answer to the US-centric question on expiry dates was supplied[4] by TomCallaway with a list of the patents which mostly expire within the next decade.

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

KDE Flamewar Warms Up Night Of Final Freeze

A mostly happy and appreciative StefanGrosse reported[1] that the KDE logout dialogue was missing the shutdown and hibernation buttons while running a system upgraded to Rawhide from Fedora 8 Test 3. There was solely an end session button which led back to the login screen where it was then possible to shutdown. SebastianVahl suggested that it was necessary to use KDM as the login manager and Stefan asked[2] for details on how to do this. He also remembered that upgrading from Fedora 7 to Rawhide saw these buttons disappear, but that they had been present even when using GDM in Fedora Core 6.

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

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

Sebastian answered that it was necessary to create a /etc/sysconfig/desktop containing DESKTOP="KDE" and DISPLAYMANAGER=KDE and suggested that the question was not appropriate to @fedora-devel. RahulSundaram thought[3] that it was because it was odd that the Fedora DVD image was installing GDM if the user had selected KDE. KevinKofler traced[4] this back to desktop unification in Red Hat Linux 8.0. BillNottingham stated[5] that GDM was the default login manager in the base X group and couldn't be removed from it. Rahul wondered[6] why GDM was not in the GNOME package group instead of the X package group.

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

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

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

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

Later Bill argued[7] that xdm was inappropriate as a default display manager because it was so bad and MatthiasClasen responded to Rahul that associating a display manager with a desktop environment was illogical anyway. Rahul was un-swayed[8] and argued for either a neutral display manager, or else for the display manager to reflect the chosen desktop environment.

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

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

The first sparks of a flamewar appeared when Bill felt that Rahul was dismissing his argument without considering the context and Rahul asked[9] why it would be a problem to either install XDM or the desktop-appropriate display manager. MatthiasClasen suppled[10] the argument that due to the security importance of a display manager it would be necessary to do unneeded extra work if more than one were shipped. When JesseKeating amplified this point by noting the choice between duplicating each feature or else confusing users there was a certain amount of irritation expressed by KDE developers KevinKofler and VikramGoyal [11] who noted that KDE had supported some features first and that the unpleasant logical conclusion was that KDE integration was going to be ignored. Rahul countered[12] Matthias by noting that KDM is already the default for the KDE spin and that as the repositories already carry various display managers there is no security or work advantage in avoiding its use. KevinKofler made the same point, with the addition[13] that the KDE SIG had clearly decided that they wanted to use KDM. ChristopherAillon shared[14] the information that work was being done on a unified generic login manager (by William Jon McCann) and asked that instead of internecine Fedora fighting energy would be directed to convince upstream KDM developers of the advantages. RexDieter promised to see what he could do in that direction.

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

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

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

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

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

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

BillNottingham argued[15] that although there was a regression in functionality it would be better to investigate the bug instead of suggesting that long-established practice be changed on the night of the final freeze. The thread continued[16] to get toasty when Bill told Rahul that the change was a one line patch to make kdebase point to the correct FIFO to communicate with GDM. Rahul's insistence that he had raised and discussed this issue in Bugzilla in the past led to Bill accusing[16] him of pushing an agenda under the cover of a bug which he was not interested in solving. Bill closed[17] with a restatement of the problem and the use of GDM as a default (which can be unchecked) during install.

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

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

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

MatthiasClasen disagreed with Rahul that this change was a regression and Rahul's disavowal of certainty about the term led ChristopherAillon to be aware that if he was "going to play the non-native speaker card" that it was also held by many other participants. Christopher asked[18] Rahul to "curb the hostility and try a different argument". Rahul wondered what he meant, and a Christopher referenced[19] a separate strand of the thread in which Rahul had cautioned[19] that throwing accusations around about the KDE maintainers was counterproductive and added some links to show evidence of how he had earlier been accused of being anti-KDE. Christopher appeared bemused as to what this had to do with him and pointed out that it put him on the defensive. Rahul apologized for seeming to complain and Christopher again responded that Rahul had made his point several times and although it was reasonable to requested KDM as a default when KDE is selected from the Fedora DVD there had been unrefuted technical answers from BillNottingham and JesseKeating as to why this was not going to happen for Fedora 8. Jesse had also suggested much earlier that the KDE release notes should simply tell users to uncheck GDM[19a]

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

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

[19a] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02676.html

A detailed response[20] from KevinKofler outlined two possible ways in which the problem could be solved without modifying anaconda and one way in which anaconda could be hacked. Kevin was very clear that KDM is the preferred display manager and will continue to be so in KDE4.0. Later he promised[21] that KDM would only be pried from "my cold dead hands."

[20] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02793.html

[21] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02690.html

DaveAirlie agreed with Bill that "[XDM] is a horror" although JoachimFrieben thought[23] that it could provide a plain X environment without the encumbrances of all the package dependencies of GNOME and KDE and that foisting GDM on advanced users was undesirable. ChristopherAillon thought that such advanced users could probably do what they wanted with kickstart or re-spinning.

[22] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00019.html

Final thoughts on the thread came from the KDE developers who expressed[23] distrust due to the way in which KNetworkManager had been handled. It seemed that although it is possible to use NetworkManager via a dummy package that installs several gnome libraries[24] it has not been possible to adapt the KNetworkManager frontend to use the very rapidly improved NetworkManager backend.

[23] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00036.html

[24] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00039.html

Filesystem Mounts: UUIDs or LABELs?

An inquiry[1] from AmitakhyaPhukan about why all detected filesystems are automatically mounted (on a rawhide machine) with desktop icons led to a discussion of the use of PolicyKit in Fedora 9. DavidZeuthen explained[2] that Rawhide mounts fixed drives only when root has made some changes. Apparently there is not yet a GUI to undo help with undoing these administrator initiated changes, but David suggested using polkit-grant --delete <username>. KevinKofler suggested[3] that Amitakhya should check that usr/share/hal/fdi/policy/10osvendor/99-redhat-storage-policy-fixed-drives.fdi existed with the same contents as in Fedora 8.

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

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

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

RoddClarkson had also seen some filesystems (which hadn't been visible in Fedora 7) show up in the disk mounter applet for Rawhide. David explained[4] that these were from previous OSes and are now shown in Fedora 8. He agreed that the text shown in the UI might be a little misleading due to the labels chosen, and also wondered why the anaconda team had chosen to use LABELs over UUIDs.

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

David followed up by apologizing for his rant and providing[5] bugzilla entries where these issues could be discussed.

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

Split KDE Packages

"Axel" wondered[1] whether it would be possible to split KDE packages into multiple smaller sub packages. The reasoning behind this is that KDE install currently pull in many unwanted programs leading to an unnecessarily bloated system. Axel acknowledged that Fedora was primarily a "GNOME based distribution" but preferred to use KDE.

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

The official position of the KDE SIG was regretfully conveyed[2] by KevinKofler. The issue has been discussed in the SIG's IRC meetings and the consensus has been that the maintenance burden would be too high. A compromise position which sees the splitting out of less used components into "-extras" sub packages has been adopted. This allows the production of a LiveCD. Kevin also replied that if the same programs appear in more than one place in the KDE menus then this a bug and it would be appreciated if those finding them would search Bugzilla before opening a new bug.

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

IcedTea Plugin On x86_64

A non-functioning IcedTea java plugin for Firefox led MarkeBidewell to wonder[1] if the problem was because the plugin directory was named "amd64" while he was using an Intel system. RexDieter confirmed the problem and provided a solution which was symlinking the IcedTea plugin to the Firefox plugins subdirectory[2] .

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

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

MarkBidewell and JefSpaleta agreed[3] that the problem was probably an incorrect search path for Mozilla. BillNottingham suggested[4] running mozilla-plugin-config -i -f as root.

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

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

SecondLife Exposes Mesa Licensing Problem?

A bunch of OpenGL headers had attention drawn to their licensing because due to a bug opened against SecondLife. CallumLerwick grepped through several and found[1] that they were using "SGI Free Software License B" which seemed to be explicitly not acceptable in Fedora. HansdeGoede agreed[2] with Callum and said that they had been allowed as an exception due to their essential nature, but that since talks with SGI were stagnating it would be good to start working on removing and replacing the troublesome pieces.

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

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

Callum later added[3] that the problem seemed to have been fixed in the version of Mesa which was included in Fedora 8, but TomCallaway was unsure about the validity of the relicensing and asked[4] AdamJackson for information.

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

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

HansdeGoede (as could be expected of someone maintaining so many game packages) had done some research and found[5] that ownership of the OpenGL standard had been transferred to "The Khronos Group" and appear to have been committed legitimately. Hans and Tom were in agreement that the problem was bigger than this and remained unsolved however.

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

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

Advisory Board

In this section, we cover discussion in Fedora Advisory Board.

https://www.redhat.com/mailman/listinfo/fedora-advisory-board

Contributing Writer: MichaelLarabel

Fedora Board Meeting

With Fedora 8 coming out in just a few days, this past week's Fedora Board Meeting[1] was about the Fedora 8 Blocker List[2] . Among the outstanding issues affected NetworkManager, LiveCD/USB testing, Python/Turkish, and dmraid. The final day to have the Fedora 8 tree completed was Friday, and fortunately everything was completed in time. Find out more in the fedora-advisory-board message[3] .

[1] http://fedoraproject.org/wiki/Board/Meetings/2007-10-30

[2] https://bugzilla.redhat.com/showdependencytree.cgi?id=235703&hide_resolved=1

[3] https://www.redhat.com/archives/fedora-advisory-board/2007-October/msg00051.html

Fonts

In this section, we cover discussion in Fedora Fonts.

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

Contributing Writer: MichaelLarabel

Fedora Fonts SIG TODO List

If you've been wanting to help out with the Fedora Fonts, but are unsure of what you would like to work on, NicolasMailhot has created a TODO list[1] for this special interest group, The Fonts TODO List[2] lists one-time tasks as well as recurring tasks along with those that have been completed. If you've been wanting to help out or are curious where the Fedora Fonts SIG stands today, check out the list.

[1] https://www.redhat.com/archives/fedora-fonts-list/2007-November/msg00045.html

[2] http://fedoraproject.org/wiki/SIGs/Fonts/Todo

Infrastructure

In this section, we cover the Fedora Infrastructure Project.

http://fedoraproject.org/wiki/Infrastructure

Contributing Writer: JasonMatthewTaylor

The Wiki

There was more discussion this week[1] [2] about what to do about the wiki, whether to move to a new software or keep the existing and patch it as needed. The jury is still out, we will see what happens after F8 is released.

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

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

Security Week

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

Contributing Writer: JoshBressers

IBM Plans Major Security Initiative

http://ap.google.com/article/ALeqM5iSFxylj-4ojpf44zNT6k01yBY5RgD8SKHH781

IBM announced last week that they plan to spend 1.5 billion ( with a big B ) dollars on security research in 2008. Information Security is becoming a very serious business. I suspect the biggest issue now is going to be finding employees to fill these positions.

Advisories and Updates

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

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

Contributing Writer: ThomasChung

Fedora 7 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-10-30

Fedora Ambassadors Meeting 2007-MM-DD

  • No Report

Fedora Documentation Steering Committee (Log) 2007-10-28

Fedora Engineering Steering Committee Meeting 2007-MM-DD

  • No Report

Fedora Extra Packages for Enterprise Linux Report 2007-MM-DD

  • No Report

Fedora Infrastructure Meeting (Log) 2007-11-01

Fedora KDE-SIG Meeting 2007-10-30

Fedora Localization Meeting 2007-MM-DD

  • No Report

Fedora Marketing Meeting 2007-MM-DD

  • No Report

Fedora Packaging Committee Meeting 2007-10-30

Fedora Release Engineering Meeting 2007-10-29