From Fedora Project Wiki

< FWN

fp-wiki>ImportUser
(Imported from MoinMoin)
 
m (1 revision(s))
(No difference)

Revision as of 16:28, 24 May 2008

Fedora Weekly News Issue 112

Welcome to Fedora Weekly News Issue 112 for the week of December 3rd. http://fedoraproject.org/wiki/FWN/Issue112

In Announcement, we have "FUDCon Raleigh 2008"

In Planet Fedora, we have "CentOS really does fill a gap", "Fedora 8 Re-Spin in the making", "FDSCo nominations underway", "Fedora update metrics", "FAmSCo nominations/elections"

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

FUDCon Raleigh 2008

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

"The next FUDCon (Fedora User and Developer Conference) will be in Raleigh, NC from January 11-13, 2008. The event is 100% free to attend."

[1] https://www.redhat.com/archives/fedora-announce-list/2007-December/msg00001.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

CentOS really does fill a gap

PaulFrields points out in his blog[1] ,

"To second what Jayson Rowe said, CentOS really does fill a gap. As a person who works on Fedora almost exclusively in his spare time, CentOS is the perfect way for me to experience performance equivalent to Red Hat Enterprise Linux — albeit without the support options — and take advantage of the very long horizon of platform durability. RHEL is the gold standard in Linux stability and performance, so there’s no better way for any hobbyist to run his own servers with zero financial impact than to use CentOS. CentOS is to the Internet homesteader what RHEL is to business."

[1] http://marilyn.frields.org:8080/~paul/wordpress/?p=880

Fedora 8 Re-Spin in the making

JeroenVanMeeuwen points out in his blog[1] ,

"A Fedora 8 Re-Spin is in the making, and as often we have a couple of issues we want to resolve with this Re-Spin."

"Just so that it is clear; we do need you to let us know what it is you want resolved in a Re-Spin, or otherwise, possibly, we end up with a Re-Spin being released that still has the bugs or errors you wanted to see resolved."

[1] http://kanarip.blogspot.com/2007/12/fedora-8-re-spin-in-making.html

FDSCo nominations underway

PaulFrields points out in his blog[1] ,

"According to our schedule, the Fedora Documentation Steering Committee (FDSCo) nominations are open. We have three seats up for election this cycle. Vigorous work is underway for more documentation for Fedora 8/9, and we want to see strong community leadership driving the development of these docs."

[1] http://marilyn.frields.org:8080/~paul/wordpress/?p=879

Fedora update metrics

LukeMacken points out in his blog[1] ,

"Using flot, a plotting library for jQuery, I threw together some shiny metrics for bodhi. It's pretty amazing to see how a Fedora release evolves over time, with almost as many enhancements as bugfixes. This could arguably be a bad thing, as our "stable" bits seem to change so much; but it definitely shows how much innovation is happening in Fedora."

[1] http://lewk.org/blog/bodhi-metrics.html

FAmSCo nominations/elections

SandroMathys points out in his blog[1] ,

"Today I nominated myself for the FAmSCo (Fedora Ambassadors Steering Committee) elections taking place very soon. Actually, the nomination-period would be over already if there were enough volunteers, but not the period has been extended for one week as written in the election rules."

http://sandro-mathys.ch/blog/2007/12/05/famsco-nominationselections-me/

Daily Package

The Fedora Daily Package departed from its usual format this week to run a special "Focus Week" dealing with system recovery tasks. These five topics were included in "System Recovery Week".

http://dailypackage.fedorabook.com/

Contributing Writer: ChrisTyler

System Recover Week

  • Single-User Mode [1] - Using runlevel "s" to solve basic system problems.
  • Rescue Mode and Reinstalling Grub [2] - Booting into rescue mode from optical disk, and reinstalling a damaged or overwritten Grub bootloader.
  • Using LVM in Rescue Mode [3] - Finding, activating, and using Logical Volumes in rescue mode.
  • Recovering RAID Devices [4] - Gaining access to damaged RAID arrays.
  • Dealing with Disk Images [5] - Accessing data on disk image files created during rescue operations or from Xen/KVM virtual machines.

[1] http://dailypackage.fedorabook.com/index.php?/archives/157-System-Recovery-Week-Single-user-mode.html

[2] http://dailypackage.fedorabook.com/index.php?/archives/158-System-Recovery-Week-Rescue-Mode-and-Reinstalling-Grub.html

[3] http://dailypackage.fedorabook.com/index.php?/archives/159-System-Recovery-Week-Using-LVM-In-Rescue-Mode.html

[4] http://dailypackage.fedorabook.com/index.php?/archives/160-System-Recovery-Week-Recovering-RAID-Devices.html

[5] http://dailypackage.fedorabook.com/index.php?/archives/161-System-Recovery-Week-Dealing-with-Disk-Images.html

Marketing

In this section, we cover Fedora Marketing Project.

http://fedoraproject.org/wiki/Marketing

Contributing Writer: ThomasChung

Interview with Brian Stevens with Red Hat

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

"So, Fedora 8, just made available in the last week, had 54,000 downloads and installs that we can even measure in the first four days, a vibrant development community around next generation technology whether that be KVM or appliances or spins or network manager improvements. So, Fedora is absolutely the place to watch the OS evolve."

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

Fedora 8 - More than a Linux Distribution

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

"One of the most popular free-as-in-freedom Linux distribution, Fedora Linux, released its latest version, Fedora 8, earlier in November. In addition to being a fantastic release, Fedora's user and development community and a clear headed approach makes Fedora 8 much more than a Linux distribution."

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

Fedora Store meeting summary

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

"I do think that a Fedora Store session would be a useful thing to have for part of a day at the FUDCon Hackfest."

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

TeXLive In Rawhide

The availability of TeXLive in rawhide was announced[1] by JindrichNovy on the 3rd Dec. This is excellent news for TeX users as the teTeX distribution had been unmaintained since mid-2006. As a result Fedora users now benefit from an actively maintained TeX distribution with more styles available.

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

Jindrich was kind enough to produce packages for Fedora 8 as well as for rawhide and MilosJakubicek posted[2] that he had used Jindrich's test repository to install them onto Fedora 8 with no problems. Full details on how to use the repository were included[3] on the wiki by Jindrich.

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

[3] http://fedoraproject.org/wiki/Releases/FeatureTexLive#head-694fe23a06614cef1588905ead64d7f2cf9edd74

The magnitude of Jindrich's packaging feat was noted[4] by JonathanUnderwood in a question about the obsoleting of teTeX and the details of how TeX sub-packages should be named and what they should require. PatriceDumas answered[5] that package renaming and dependencies were separate issues and that the use of new virtual provides would allow switching TeX distributions more easily. In response to a request from Jindrich, Jonathan opened[6] a bugzilla tracker entry which explains the issue very clearly.

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

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

[6] https://bugzilla.redhat.com/show_bug.cgi?id=410401

A brief problem was experienced during the initial build of the packages as reported[7] by JesseKeating. It seemed that the problem was due to the "Obsoletes:" and "Provides:" being incorrect and this was fixed[8] by Jindrich. An educational thread about version-release comparisons was spun[9] between TillMaas and MichaelSchwendt.

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

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

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

Sub-Packaging: Gentooification, Ubiquitous Fragmentation Or Choice?

After JoachimFrieben had a bugzilla report closed with "NOTABUG" when he reported that the "vtk-devel" package pulled in too many dependencies he posted[1] a request for discussion of a standard policy to deal with splitting packages into smaller units. Joachim contrasted the manner in which "plplot" was sub-divided with the monolithic nature of "vtk-devel".

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

PatriceDumas expressed[2] clear opposition to a standard policy, preferring to rely instead on packager knowledge. He also argued that from a user's perspective increased granularity imposed a need to become aware of, and to install, the subpackages. Patrice developed[3] these points further in response to RichiPlana's expression of desire for such a guideline. Patrice's rather convincing argument was that a guideline could not cover all cases and he backed this up for the specific example under discussion, showing that that packaging of "vtk" itself had been fine-grained, but that "vtk-devel" had been more monolithic because of the expectation that a "-devel" package provides all that is needed to develop with that package. Later RexDieter expressed[4] the idea that packaging splits should be performed with the objective of benefiting runtime and WarrenTogami drew[5] a parallel with how "pidgin" had been handled: "PERL" and "Tcl" capability was split out of the runtime so that users without a need for these scripting extensions did not have to install all of PERL and Tcl, yet the "pidgin-devel" package did include these dependencies.

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

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

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

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

The advantages of sub-packages were proposed by LeszekMatok as a means to escape the "dependency hell" reputation which is often unfairly attached to Fedora and there was violent agreement expressed[6] on this point by ChristopherStone in the context of Fedora being used as a base for other distributions. RexDieter wondered[7] why this sub-packaging was an essential pre-requisite to improving Fedora as a base distribution. Christopher's demurral to provide further details prompted satire from JesseKeating and an excellent overview[8] of the problem from YaakovNemoy. Yaakov suggested that too much choice was to be avoided and that perhaps such needs were best met by internal customization of Fedora. Christopher responded[9] with anecdotal evidence that Gentoo was indeed becoming preferred to Fedora precisely for these reasons.

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

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

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

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

Joachim was unconvinced by these arguments and posted[10] [11] evidence that "vtk-devel" was not actually a self-sufficient package and disputed the distinction between developers and users which had been drawn as part of the rationale for allowing a certain amount of user-unfriendly bloat.

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

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

TomCallaway echoed[12] Patrice's argument that software worked on different models and that it was difficult to force it all into the same packaging strictures. He added the suggestion that if there were sufficient interest and concern on the point then a SIG could be formed to suggest sub-packaging improvements where desired.

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

JonathanUnderwood suggested[13] that the argument was "too hand wavy and nebulous" and asked whether Joachim had submitted a patch which could provide the basis of a technical discussion.

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

YUM: Should It Update Itself First?

A query[1] from "DrDiesel" about why kmod updates were failing was answered[2] by SethVidal that this was due to a bug in YUM which had been fixed in yum-3.2.8.

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

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

WillWoods noted that there had been many bugs lately where the solution had been to update YUM and its dependencies prior to updating anything else. He asked[3] whether it was feasible to make this behavior automatic. HansdeGoede thought it[4] was important that this should only be done when everything was set for an update. Otherwise simply the selected package and dependencies should be installed. Another caveat was added[5] by SethVidal, namely that blind automatic updates of YUM and its dependencies would lead to problems when jumping distribution versions.

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

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

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

Replacing Tail With Inotify Aware Version

On Dec 5th FlorinAndrei drew attention[1] to a cool version of "tail" named "inotail"[2] for which he had written a spec file and produced packages for some architectures and distributions. "Inotail" substitutes the regular polling of a file obtained in follow-mode with inotify triggers sent from the kernel upon specified changes to the file. The result is both faster and also conveys a more accurate picture of when events occur. Florin asked for anyone interested to take over the package and shepherd it through the submissions process as he was short of time.

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

[2] http://distanz.ch/inotail/

Interest was expressed[3] by MarcelaMaslanova and ManuelWolfshant (who had already packaged it). Manuel suggested adding it to inotify-tools and offered[4] to review the package. TomasMraz preferred[5] that a patch was prepared to add the functionality to the existing tail contained in coreutils. KarelZak thought[6] that there were potential portability issues, but ColinWalters[7] disagreed and after some discussion of the potential for a problem with scripts depending on the current effect of sleep on tail -f MartinEbourne agreed[8] . JesseKeating pronounced[9] himself happy to remove inotail once the current tail had been patched.

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

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

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

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

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

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

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

ParagN drew[10] the attention of would-be packagers to the package created by JesseKeating shortly after Florin had first made his announcement.

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

Smolt UUIDs Broken (Danger Awful Puns)

A request for a follow-up on earlier discussion about the apparent brokenness of the Smolt[1] database was posted[2] by JonMasters. The issue was that hundreds of profile submissions were being made per month against particular UUIDs. Jon speculated that a common hardware device was being inappropriately included in the pool used as a source of entropy for generating random UUIDs. (This is done so that each Smolt user is anonymous yet unique.)

[1] https://hosted.fedoraproject.org/projects/smolt/

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

After some horrible puns were exchanged between AlanCox and Jon the thread was mercifully brought to a halt when MikeMcGrath posted[3] that the problem seemed to originate with the construction of the LiveCD and had nothing to do with how the kernel generated UUIDs.

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

Unfortunately the damage had been done[4] by that time.

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

Eliminating Un-needed Dependencies

A request for objections to the removal of bdftruncate (a PERL script which generates truncated ISO10646-1 BDF fonts) from xorg-x11-font-utils was posted[1] by AdamJackson. The immediate impetus was to prevent the pulling in of all of PERL in order to satisfy the dependency for this rarely used script. NicolasMailhot referenced[2] last week's discussion about core fonts during which he had expressed the opinion that they ought not to depend on anything, even xorg-x11-font-utils. Nicolas also hoped to persuade Adam to take over the maintenance of the "core fonts packaging guidelines".

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

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

While Adam was in agreement with Nicolas he declined[3] to take over the onerous tasks of either making it possible for the core fonts to be packaged instead of generated on the fly, or the maintenance of their guidelines. He expressed an interest solely in simplifying the dependency graph by removing unnecessary arcs from it.

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

KevinKofler asked[4] why a Perl dependency was a problem, noting that most systems had it installed already. He was answered by DavidZeuthen[5] that his experience working on the OLPC project suggested that if Fedora was to be useful for the embedded and virtual environments then it was very important to be able to choose not to use such large packages. AdamJackson also mentioned[6] the "ability to use trimmed subsets of Fedora for custom purposes" and the speed of dependency resolution as important considerations and DanWilliams echoed[7] the point.

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

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

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

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

TomCallaway suggested[8] using a sub-package (see also this FWN#112 "Sub-Packaging: Gentooification, Ubiquitous Fragmentation Or Choice?" for a related discussion of sub-packaging) rather than dropping the script entirely.

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

Open By Default: New FAS Groups Proposed

The template for new package requests was noted[1] by JesseKeating to mislead requesters into thinking that they would not have open ACLs unless they explicitly opted in to this. Jesse wondered if changing this to something clearer emphasizing that "as a requester you'd have to explicitly opt out of of having open acls" would be welcomed.

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

ToddZullinger liked[2] the "open by default" status-quo and suggested that "Private Commits" would be a good prompt for those with a need for tighter control. DavidWoodhouse added[3] that a valid reason should be required, to which ThorstenLeemhuis responded[4] with some examples and suggested (again) that there should be a FAS[5] group of "experienced maintainers" with universal access. LubomirKundrak agreed[6] with Thorsten that packages with multiple maintainers did not need to be open by default, but thought that a "just sponsored contributor" was an experienced maintainer and that there should be no creation of the more privileged sub-group suggested by Thorsten.

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

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

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

[5] Fedora Account System

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

The existence of the "extra most super experienced maintainers" group for which Thorsten wished was revealed[7] by PatriceDumas to already exist.

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

After Thorsten argued that Lubomir's evaluation of experience was incorrect and suggested that rather than a binary approach to access there could be levels, JohnDennis added[8] some supporting caution that allowing simple open access would provide an ideal channel for anyone who wished to distribute malware.

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

JesseKeating argued[9] that many of the major distributions had "open" commits for project members. In response to Thorsten's querying whether Jesse had a solution to the problem Jesse suggested[10] that a new group "cvsnewbies" be created. Members would only have access to their own packages and could later be promoted to existing groups such as "cvspkgs" or "cvsextras". Jesse described the motivation as "[to have] our package set to be accessible to as many people as possible instead of locked away from as many people as possible." Jesse then outlined a detailed proposal which includes changing the "cvsextras" group to become similar to "cvspkgs" and adding a new "cvsexperienced" group with CVS access to all modules which have not explicitly opted out. Thorsten was substantially in agreement[11] with this although he noted that it sounded very like proposal which he and others had tried to make months ago. Thorsten also thought that membership of "cvsexperienced" (or whatever it will be called) should be determined by people (FESCo or sponsors) rather than a rigid guideline.

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

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

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

Heads Up: OpenSSL, OpenLDAP Changed In Rawhide

TomasMraz announced[1] that there are new versions of OpenLDAP and OpenSSL with new sonames. Consequently dependent packages need to be rebuilt.

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

A lingering problem with KDE's licensing uncertainties(see FWN#105 "SAMBA: The GPLv3 License Dance Begins"[1a] ) was flagged[2] by SimoSorce as the reason that SAMBA packages were being delayed in rebuilding. He asked whether libsmbclient support could be disable in KDE while Trolltech pondered the issue.

[1a] http://fedoraproject.org/wiki/FWN/Issue105#head-9704e381395b0f0ccc8a4ab85596e71d30835aa4

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

RexDieter kindly and promptly disabled libsmbclient support[3] and TomCallaway counseled patience[4] . Simo explained that there were a lot of other packages being delayed as a result.

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

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

Later MatthiasClasen posted[5] a list of packages which still needed to be rebuilt. He expressed a willingness to help with them, but point out that most had ACLs which prevented him from being able to do so. AdamTkac expressed[6] a similar frustration (see this FWN#112 "Open By Default: New FAS Groups Proposed") wondering why "cvsextras" members were restricted from commits. AlexLancaster thought the package list was much larger (up to 656) and suggested[7] a systematic approach of starting with packages in the "Base" comps group and proceeding upwards, in order to avoid wasting time on rebuilds guaranteed to fail.

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

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

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

In the course of trying to determine which packages would need to be rebuilt, Jesse realized there would also be ordering problems and mentioned[8] a tool named "thetango" which derives build trees for individual SRPMS by evaluating dependencies between binary RPMs derived from a set of SRPMS. An ordered build list is one of the products and Jesse posted that he was working on generating this list. HansdeGoede was appreciative[9] : "Thanks for that, your awesome! Yes really you are despite us having differences of opinion sometimes :)"

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

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

Documentation

In this section, we cover the Fedora Documentation Project.

http://fedoraproject.org/wiki/DocsProject

Contributing Writer: JohnBabich

Nominations for FDSCo Election Open

KarstenWade wrote [1] :

"Forgot to remind us the nominations are open:

http://fedoraproject.org/wiki/DocsProject/SteeringCommittee/Nominations

Go ahead!

Details here:

http://fedoraproject.org/wiki/DocsProject/Policy/FDSCoElections

Elections start on 14 December."

[1] http://www.redhat.com/archives/fedora-docs-list/2007-December/msg00069.html

New POT Available for Release Notes

Paul Frields wrote [2] that a "new POT is available for the last few days for the Release Notes module. We plan to gather updated PO and push an update on or about December 11." Localization (L10n) work is welcome on the following docs: release-notes, readme, readme-live-image, readme-burning-isos, and about-fedora.

For those of us unfamiliar with l10n: "The GNU gettext toolset helps programmers and translators at producing, updating and using translation files, mainly those PO files which are textual, editable files...A PO file is made up of many entries, each entry holding the relation between an original untranslated string and its corresponding translation." [3] Gettext is part of the Fedora Project's toolchain for translation and localization with PO being an acronym for "Portable Object".

[2] http://www.redhat.com/archives/fedora-docs-list/2007-December/msg00005.html

[3] http://www.gnu.org/software/gettext/manual/gettext.html#PO-Files

FDSCo Election Calendar

KarstenWade wrote [4] that elections for the Fedora Documentation Steering Committee (FDSCo) need to be held soon. He endorsed the previously suggested schedule:

Nominations open on 05 December and close on 12 December. Voting opens on 14 December and closes on 24 December.

We have three seats open for (re)election, currently held by John Babich (jmbabich), Pawel Sadowski (mcgiwer), and Bart Couvreur (couf).

These four seats are held until the next election: Paul W. Frields (pfrields), Karsten Wade (kwade), Dimitris Glezos (glezos) and Robert 'Bob' Jensen (bjensen).

He concluded by saying, 'After this election, the new FDSCo has to hold discussions with all contributors and decide how we are cycling seats and how often we are holding elections for the future. This was a direction left by the current FDSCo after the previous round of elections: "After the next election, review election policy and how often elections should be held."'

Bart Couvreur [5] seconded the motion, as did BobJensen [6] , and PaulFrields [7] , with JohnPoelstra [8] adding it to the official voting calendar.

[4] http://www.redhat.com/archives/fedora-docs-list/2007-December/msg00011.html

[5] http://www.redhat.com/archives/fedora-docs-list/2007-December/msg00014.html

[6] http://www.redhat.com/archives/fedora-docs-list/2007-December/msg00015.html

[7] http://www.redhat.com/archives/fedora-docs-list/2007-December/msg00030.html

[8] http://www.redhat.com/archives/fedora-docs-list/2007-December/msg00026.html

Digging the DUG

MarcWiriadisastra began discussion as to the focus of the revived Fedora Desktop User Guide (DUG): "Can we come to a consensus on what else needs to be done to make this doc a reality." [9] As lead writer of the DUG, JohnBabich responded quickly with "There are two types of apps: common and desktop manager-specific apps." and went on to explain his vision for the DUG encompassing common apps like Firefox and desktop manager-related apps, mainly those grouped with GNOME, KDE and Xfce. [10]

KarstenWade [11] , VladimirKosovac [12] , PaulFrields [13] , and DanOBrien [14] all expressed their opinions on the scope and depth of the DUG as opposed to documents like the Administration Guide. One issue discussed in detail was DVD and HTTP installs with apparently buggy behavior, requiring CLI skills to resolve them. If this is the case, how much detail should be discussed on topics like this, beyond the basics?

[9] http://www.redhat.com/archives/fedora-docs-list/2007-December/msg00033.html

[10] http://www.redhat.com/archives/fedora-docs-list/2007-December/msg00035.html

[11] http://www.redhat.com/archives/fedora-docs-list/2007-December/msg00036.html

[12] http://www.redhat.com/archives/fedora-docs-list/2007-December/msg00038.html

[13] http://www.redhat.com/archives/fedora-docs-list/2007-December/msg00059.html

[14] http://www.redhat.com/archives/fedora-docs-list/2007-December/msg00058.html

NSA guide to securing Red Hat Enterprise Linux 5

MurrayMcAllister wrote that there "is a fantastic "Guide to the Secure Configuration of Red Hat Enterprise Linux 5" PDF available here: http://www.nsa.gov/snac/downloads_redhat.cfm?MenuID=scg10.3.1.1

It looks like it would be an invaluable resource for research for the Fedora Admin Guide. Among many other things, it covers IMAP/POP3, DNS, Web, Samba, Proxies, LDAP etc." [15]

VladimirKosovac thought it would be good additional reference [16] , which KarstenWade seconded [17] , and added that it was a great example of technical documentation from which to learn.

[15] http://www.redhat.com/archives/fedora-docs-list/2007-December/msg00048.html

[16] http://www.redhat.com/archives/fedora-docs-list/2007-December/msg00050.html

[17] http://www.redhat.com/archives/fedora-docs-list/2007-December/msg00063.html

Translation

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

http://fedoraproject.org/wiki/L10N

Contributing Writer: JasonMatthewTaylor

New Release Note POT

PaulFrields posted[1] this week about the updated release-note POT/PO files. As always we appreciate the work that the translation team does!

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

Infrastructure

In this section, we cover the Fedora Infrastructure Project.

http://fedoraproject.org/wiki/Infrastructure

Contributing Writer: JasonMatthewTaylor

Wanted! Mirror Manager Wranglers

MattDomsch this week posted[1] a request for more people to help with the Mirror Manager setup. This will allow, among other things for more enhancements to the Mirror Manager software and help alleviate some of the workload on those already doing the work. He received a fair amount of replies with offer to help, if you are interested contact him on IRC or reply on the Fedora Infrastructure mailing list[2]

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

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

The Jigdo Discussion

This week saw discussion[1] about the feasibility of implementing Jigdo to host spins[2] which would according to the thread author reduce the storage space requirements for spins which is a definite benefit as storage capacity is always a concern.

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

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

Security Week

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

Contributing Writer: JoshBressers

Critical Vulnerability in Microsoft Metrics

Window Snyder has some rather insightful feedback regarding Microsoft Metrics. In general this commentary can apply to anyone who tries to compare closed source and open source security records.

http://blog.mozilla.com/security/2007/11/30/critical-vulnerability-in-microsoft-metrics/

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 8 Security Advisories

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 and SIGs.

Contributing Writer: ThomasChung

Fedora Board Meeting Minutes 2007-MM-DD

  • No Report

Fedora Ambassadors Meeting 2007-MM-DD

  • No Report

Fedora Documentation Steering Committee (Log) 2007-12-09

Fedora Engineering Steering Committee Meeting 2007-12-06

Fedora Infrastructure Meeting (Log) 2007-MM-DD

  • No Report

Fedora Localization Meeting 2007-MM-DD

  • No Report

Fedora Marketing Meeting 2007-MM-DD

  • No Report

Fedora Packaging Committee Meeting 2007-12-04

Fedora Quality Assurance Meeting 2007-MM-DD

  • No Report

Fedora Release Engineering Meeting 2007-12-04

Fedora SIG EPEL Meeting Week 2007-12-05

Fedora SIG KDE Meeting Week 2007-12-04

Fedora SIG Store Meeting 2007-MM-DD

  • No Report
Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Issue112&oldid=6535"