From Fedora Project Wiki

< FWN

fp-wiki>ImportUser
(Imported from MoinMoin)
 
 
(2 intermediate revisions by 2 users not shown)
Line 634: Line 634:
ThomasChung gave a Fedora Presentation for San Gabriel Valley Linux Users Group at Caltech[1]  on his birthday. The topic was "Fedora 7 - What's New" and Live Demo on virt-manager with KVM and Revisor. Some Fedora 7 DVDs and Fedora Stickers were also given to the group at the end of the presentation.
ThomasChung gave a Fedora Presentation for San Gabriel Valley Linux Users Group at Caltech[1]  on his birthday. The topic was "Fedora 7 - What's New" and Live Demo on virt-manager with KVM and Revisor. Some Fedora 7 DVDs and Fedora Stickers were also given to the group at the end of the presentation.


[1]  http://today.caltech.edu/calendar/item.tcl?calendar_id=75423
[1]  http://www.caltech.edu/content/san-gabriel-valley-linux-users-group-monthly-meeting-68


== Feedback ==
== Feedback ==
Line 644: Line 644:
[2]  http://fedoraproject.org/wiki/NewsProject/Join
[2]  http://fedoraproject.org/wiki/NewsProject/Join


----
 
[[Category:NewsProject]]
[[Category:News]]

Latest revision as of 00:14, 26 December 2012

Fedora Weekly News Issue 92

Welcome to Fedora Weekly News Issue 92[1] for the week of June 10th through June 16th, 2007. The latest issue can always be found here[2] and RSS Feed can be found here[3] .

[1] http://fedoraproject.org/wiki/FWN/Issue92

[2] http://fedoraproject.org/wiki/FWN/LatestIssue

[3] http://feeds.feedburner.com/fwn


Announcements

In this section, we cover announcements from various projects.

Contributing Writer: ThomasChung

Reminder - Fedora Core 5 EOL on 2007-06-29

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

"As many of you are aware, our policy on the lifecycles of Fedora releases is: Fedora X will be maintained until about one month after Fedora X+2. Fedora 7 was released on May 31st. Fedora Core 5 will reach its End of Life on Friday June 29th. This was previously mentioned on fedora-announce-list on May 3rd[2] , but is worth repeating."

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

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

Fedora-Devel-Announce is Now Open

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

"fedora-devel-announce list[2] is now open. The goal of this list is to make it easy for Fedora contributors to follow changes in that may be pertinent to developers within the Fedora Project. This is intended to be a LOW TRAFFIC announce-only list of development topics, so we hope subscribers wont feel the need to filter it away from their Inbox."

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

[2] https://www.redhat.com/mailman/listinfo/fedora-devel-announce

Fedora Board Elections

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

"We are due for our first round of Fedora Board elections. There have been some threads recently on fedora-advisory-board that have been working to clarify what the Board's role should be as it goes into its next term. Those who have not seen that thread may want to look at[2] ."

"The Fedora Board continues to serve as the top-level decision making body within Fedora. One of the challenges that the "new" Fedora Board will face is doing a better job of making sure that the Fedora Board appropriately manages the rest of the Fedora community, and also Fedora's interaction with the larger Red Hat engineering, legal, etc. groups."

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

[2] https://www.redhat.com/archives/fedora-advisory-board/2007-June/msg00022.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


Working on Fedora L10n

DimitrisGlezos points out in his blog[1] ,

"In the last few days I’ve been working on Fedora’s L10n infrastructure. Not all of it was exciting, but we really need to increase the quality of our international desktops. Why? Well, for start, Lord Smolt informs that 3 out of 10 registered systems are non-English, and I estimate another 2/10 of the en_US have localized desktop sessions (so that users won’t be facing encoding problems on the command-line)..."

"...And finally, we are building an exciting new front-end to L10n, to replace the rusty i18n.redhat one. Besides translation statistics, it presents i18n errors of the module and urges people to code using the standard libraries, which increase interoperability. It also supports Subversion, Mercurial, and GIT repos. You can give it a spin at the testing system we’ve put up[2] ."

[1] http://dimitris.glezos.com/weblog/2007/06/14/working-on-flp/

[2] http://publictest4.fedora.redhat.com/

End of "I didn't know about that change!?!" for Fedora development (?)

KarstenWade points out in his blog[1] ,

"Yes, my subject is quite certain that maybe possibly it could be the end of some of the squabbling and misunderstandings amongst Fedora's developers and packagers. Because I have so much trust in my fellow humans, I can say with something almost like sureness that we'll see this problem addressed ... in our lifetime ..."

"But anyway, Warren Togami announced a good step in the right direction: Fedora-Devel-Announce is Now Open. Go subscribe. Especially if you have ever missed a small or large change in Fedora development that mattered to you. If this list[2] fails to announce something in the future, just think of all the ground for grievance you'll have!"

[1] http://iquaid.livejournal.com/20071.html

[2] https://www.redhat.com/mailman/listinfo/fedora-devel-announce

Workaround for kernel panic on suspend/resume

RolandWolters points out in his blog[1] ,

"One of the biggest disadvantages of Fedora 7 for me was that my Suspend to RAM[2] suddenly stoppped working: the kernel crashed on resume and left me with a kernel panic. I filled bug 241700 but was only forwarded to the HAL Quirk Site which does feature suspend problems in a very user friendly way. But although that page has a lot of helpful tips it does not cover kernel crashes."

After that I re-added the removed kernel modules bit by bit and checked resume each time. It turned out the broken module is fw_ohci, the Firewire Open Host Controller Interface. If you also have a kernel panic on resume you can check for yourself if this module is the reason: remove it by modprobe -r -v --first-time fw_ohci (”r” is for remove, “v” is for verbose and “first-time” make the process exit by error if the module was not loaded in the first place). After that, suspend the machine and try to resume."

[1] http://liquidat.wordpress.com/2007/06/13/howto-workaround-for-kernel-panic-on-suspendresume/

[2] http://liquidat.wordpress.com/2007/02/09/computer-suspend-it-is-working/

Marketing

In this section, we cover Fedora Marketing Project.

http://fedoraproject.org/wiki/Marketing

Contributing Writer: ThomasChung

Magazine Fedora 7 (France)

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

"As a member of the French Fedora ambassador team, I am proud to announce you the future release of an entirely magazine dedicated Fedora 7. The announce of the release of the magazine is available here[2] . The magazine will be published in France for 9,95€, it contains 2 DVDs (i386 & x86_64)."

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

[2] http://www.linuxidentity.com/html/index.php?name=News&file=article&sid=11

Fedora 7 Xen First Look

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

"Overall, the tools for Xen management are coming along quite nicely, actually developing a bit faster than I expected, and Fedora 7 is a great place to try them out. They will certainly ease Xen management (and other virtualization technologies on Linux, for that matter) in the future and I look forward to taking advantage of them when they make their way into RHEL 5.1.[2] "

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

[2] http://enterpriselinuxlog.blogs.techtarget.com/2007/06/07/fedora-7-xen-first-look/

Maximum PC reviews Fedora 7

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

"If you love Red Hat, it goes without saying that you're bound to go nuts over Fedora 7. But this distro is also worth a look for just about anyone who wants to try Linux for the first time. With a noob-friendly installation routine and simple customization menus that make daily use a breeze, we're glad Fedora 7 has thrown its hat into the ring.[2] "

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

[2] http://www.maximumpc.com/article/fedora_7_rivals_ubuntus_ease_of_use

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

Guidelineism Defeated By Glorious Benefit Of Action

HansRosbach noticed[1] something that had been commented on before[2] : the dependence of GRUB on fedora-logos, which in turn depends on gtk2, which in turn depends on a whole pile of Xlib stuff. Hans wanted to know why all this was required for a boot menu, when it wasn't required in FC4 to FC6, and also thought that the dependencies were in the wrong order anyway. RahulSundaram answered[3] that this had been discussed before and explained that fedora-logos was a single package of trademarked images and logos for legal reasons. This makes it simpler for derivative distributions to remove all Fedora trademarked material.

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

[2] http://fedoraproject.org/wiki/FWN/Issue91#head-ce92d2e708b4bfabf99accc5c34b7a8fc3142e79

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

After examining the link supplied by Rahul, AxelThimm suggested[4] that one of two things should happen: 1. the guideline that a package must require application directories into which it may drop files should be relaxed for fedora-logos or it should be made a co-owner of those application directories; 2. a sub-package containing a minimalist set of files for GRUB's splash screen should be created. Axel proposed that he could ask the Packaging Committee to relax the guideline and asked which of the options was best. He also thought that "We can't allow blind guideline-ism to create such awkward situations where simply booting the system requires gtk!"

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

The second option was impractical according[5] to MatthiasClasen because "legal" specifically wanted a single-package of trademarked images, BillNottingham later clarified[6] that this specifically meant logos and logotype, but not themes and icons. This was news to KevinKofler who was able to show[7] that the Fedora logo was in redhat-artwork and redhat-artwork-kde. Bill requested Kevin to file a bug asking for logo.png to be moved into fedora-logos.

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

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

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

Hot on the heels of this discussion thhe maintainer AdamJackson (ajax) posted[8] promptly to say that he had implemented option 1 in rawhide with fedora-logos no longer requiring anything and co-owning the directories into which it drops files. He cautioned that this was likely to break respins.

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

Cross-building Bliss

Continuing the discussion of cross-compilation started last week[1] , BrendanConoboy expanded[2] upon what he saw as the main technical and social issues which needed to be resolved. Brendan noted the ability of gcc and binutils to use sys-roots and necessity to extend the build system (e.g. Koji), and the need to modify individual packages to support cross-compilation.

[1] http://fedoraproject.org/wiki/FWN/Issue91#head-db39d837890b30155e2f18a185e09e790a6c880f

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

Picking up on the central chicken-and-egg problem of how to get a glibc for a new architecture, DavidWoodhouse argued[3] that the current "solution" was a problem because it didn't separate gcc and glibc. Brendan suggested limiting the discussion to the current architectures which led to David identifying[5] that one classification of the problem saw it break down into the distinct subproblems of building (which was relatively soluble), and packaging (which was more restricted and inflexible and needed multiple rpmbuilds currently). Brendan outlined[6] three possible SRPMS: 1) a single bloated master package for all possible targets; 2) a smaller number of single SRPMS for multiple targets grouped for technical reasons; and 3)HansdeGoede's solution of a single SRPM for a specific single architecture/target.

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

[4] http://people.redhat.com/drepper/dsohowto.pdf

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

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

RalfCorsepius definitely favored[7] avoiding option #1 and pointed out that while #3 had a downside in that it bloated repositories it was what he was currently doing succesfully. AndyGreen thought[8] that #1 was the Holy Grail as it led to a single point of control, reducing the loss of information which would occur in multiple specfiles. An exchange between Andy and HansdeGoede brought out[9] an important distinction between Fedora-to-Fedora crosses versus Fedora-to-CompletelyOtherOS crosses (Hans was dealing with 256B RAM !).

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

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

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

This distinction was also made[10] by Hans after Ralf and David seemed to be talking at cross-purposes, with David wanting to avoid pandering to architectures which didn't work with the current toolchain and yet hadn't worked to get the toolchain fixed upstream. David had earlier referenced JakubJelinek's succesful approach to the kernel as a model for how to deal with this human aspect of the problem. Hans pointed out that what he and Ralf were doing was to produce specific executables stored on removable media and targetted at an onboard OS. Hans particular expertise is with the gp2x[11a] . David accepted the distinction and Ralf explained[11] that he was interested in a slightly broader problem which involved the RTEMS[12] embedded OS both as a target in its own right and also in the problem of making a Canadian-cross of RTEMs on Fedora targetted to other important OSes.

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

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

[11a] http://en.wikipedia.org/wiki/GP2X

[12] http://www.rtems.com/

As the spotlight was focused on him Hans naturally took the opportunity to ask[13] why there hadn't been more feedback on his arm-gp2x review tickets. Ralf responded that glibc was not familiar to him, but that he was concerned with the use of a bootstrap in the specfile. This prompted[14] Brendan to admit that this was one of DavidWoodhouse's central points and that it was indeed the only current way. A detailed discussion between Ralf and Brendan seemed to result in consensus[15] that some means of extending rpm to separate out target/foreign-arch packages from the host/native rpmdb was needed. Ralf proposed[16] a second, completely isolated rpmdb for the target arch, which he surmised would be like the way mock and mach used chroots. Brendan concurred[17] that "leveraging mock is going to a key to cross building bliss."

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

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

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

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

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

AndyGreen exposed[18] the problem that BuildRequires: in a specfile being used for cross-compilation will conflate requirements for both the host and the target and proposed that rpmbuild be enhanced to deal with this case. DavidSmith's experience[19] was that the problem was actually worse and had needed some conditional architecture testing in BuildPrerequires. Ralf drew further details of this solution from David[20] and ClarkWilliams[21] with regard to the ability of rpm to install rpms with foreign/non-host architecture to a specific rpmroot.

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

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

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

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

In a later branch of the discussion AndyGreen raised[22] the forking of RPM which has taken place as an opportunity to implement these changes to how BuildRequires should be handled for cross-compilation.

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

AndyGreen clarified[23] to OliverFalk that while cross-compiled packages might need to be tested on native hardware, the actual compilation should work. LennertBuytenhek wasn't so sure[24] , citing the possibility that the binaries, although functionally equivalent, might not be identical.

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

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

Yelping Over Bloated Firefox And Flash

A confused[1] HansdeGoede wondered why he had received conflicting comments on packages he maintains about whether the help-viewer "Yelp" should be made a Requires: or not. Hans' personal opinion was that it should be as otherwise the packages lacked basic functionality without even throwing an error. ChristopherAillon thought[2] that Yelp should be required once by base gnome and not in each of the hundreds of individual gnome packages. VilleSkyttä pointed[3] to the bloated chain of dependencies (including Firefox) that requiring yelp entailed and said this was a general trend of GNOME. Christopher agreed and pointed[4] to possible future dependencies on nspluginwrapper and Xulrunner.

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

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

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

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

BillNottingham suggested that surely this was a function call in a common gnome library, leading ToshioKuratomi (who also had an affected package) to spend some time tracing[5] the chain of calls and suggest that libgnomeui should require HelpBrowser or DocbookXMLViewer which would be virtual provides in yelp. RayStrode discovered that there was a gnome_help mechanism to put up a dialog warning that help was missing and wondered[6] if help could be thought of as an optional feature. This was attractive to BernardoInnocenti (who thought the removal of help would benefit OLPC in size reduction), but not favored by Bill (who thought that the solution was to make the viewer less bloated), or Toshio (who thought that program help was a different category than man pages or README files).

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

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

Ray's news about gnome-help was welcomed by Toshio, who also noted[7] that yelp was selected as the help view by means of Gconf key, which seemed to bear out[8] a horrified BillNottingham's joke that rpm would need to dynamically compose requires from the union of all users' gconf keys.

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

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

A brief digression[9] into the bizarre American penchant for mixing up the natural date order landed explanations from AlanCox[10] on the rationale behind this and from CaolanMcNamara[11] on how to change the order in OOimpress.

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

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

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

ColinWalters thought[12] the GConf key could just be ignored and unwittingly touched-off a flamewar when he wondered whether anyone would really miss help. ChristopherAillon advanced[13] the argument that the real problem was not to do with yelp, but with the provision of a firefox-32 package against his wishes. This apparently[14] provides an icon which runs a 32-bit Firefox installed on a x86_64 system to view Flash plugin content. Christopher was annoyed that his recommendations had been over ridden.

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

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

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

An attempt by MattMiller to draw a distinction between an opinion mattering versus being completely authoritative revealed[15] the depth of Christopher's frustration. He pointed to the difficult legal requirements that made his life hell and threatened[16] to leave the project leaving Fedora with Iceweasel and no maintainer.

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

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

WarrenTogami responded[17] with the argument that the problem was nothing to do with firefox-32, and that an earlier conflict had been arbitrated through engineering management in Warren's favor and that Christopher's characterization was "FUD with a few outright lies sprinkled within." Warren argued that the script was necessary until nspluginwrapper was supported. BillNottingham thought that Warren was actually making Christopher's life harder as asserted, leading MattMiller to try to present[18] a balanced recognition that both Warren and Christopher were highly respected and experienced.

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

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

At this point MatejCepl returned[19] to Hans' original query. Matej's post took responsibility for not communicating some discussion on #fedora-devel instead of RH-interal IRC, but more interestingly suggested that what was needed was the addition of soft-dependencies in packages, akin to Debians Suggests: and Recommends:. Following enquiry from JesseKeating, Matej explained[20] that a Recommends flag would indicate to yum that if a recommended package were removed then an unspecified but useful functionality would be lost. AxelThimm thought this was horribly reminiscent of some older Windows packaging "quirks" and while DominikMierzejewski (rathann) agreed[21] he also pointed out that the soon-to-arrive standalone Gecko would simplify all this.

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

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

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

The Updates Firehose

Noting the large number of updates JesseKeating asked[1] were they all necessary. This led to a discussion of one differentiator of Fedora from other distributions, and also to several rumblings of discontent from packagers about the imposition of more interference.

BrunoWolff liked having them available but asked[2] if it was possible to have an extra categorization available so that yum could e.g. be told only to select security updates and bug-fixes but not new packages. Jesse responded[3] that LukeMacken would be implementing that and in future Pup would show a list of the notes which maintainers had inserted into bodhi. TillMaas and Luke later discussed[4] this, with Luke noting that although the yum-security plugin is present, bodhi still needs to be altered. Separately JasonTibbits and KevinKofler also discussed[4a] such functionality.

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

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

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

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

[4a] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01307.html

ChristopherBlizzard asked[5] if any users were actually complaining, and pointed out that Fedora wasn't RHEL. BernardoInnocenti advanced[6] the case of multiple machines needing updates, which sparked a good subthread[7] around MattDomsch's suggestions about how to add a local private mirror to mirromanager. GianlucaSforna posted[8] a link to the GuruLabs automatic-local-mirror HOWTO, while BillNottingham preferred a yum-plugin written by RobertSpanton to allow local repository mirrors to be discovered by yum. DaxKelson pointed out that his method had the advantage of needing no modifications to the client.

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

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

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

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

The definition of "local mirror" was raised[9] by PekkaSavola and following JakubJelinek's enquiries about the "3 mirrors per country" rule, Matt laid out[10] the changes that need to be made to improve the situation.

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

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

Several maintainers, including JefSpaleta, voiced[11] a desire for best-practices guidelines to help in determining when to push an update. Jef also wondered how many of the updates were due to new packages entering the tree versus bug-fixes to existing packages. Stimulated by this JesseKeating, BillNottingham and WillWoods tossed around[12] ways of gathering statistics on which installed packages were actually used, including porting Debian's popcon or modifying Mugshot. While ColinWalters and RahulSundaram considered adapting Smolt.

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

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

AxelThimm was generally happy with the updates and disagreed[13] with ChristopherAillon that too many changes were being backported from rawhide to F7, resulting in a lack of incentive to upgrade to F8. TillMaas and RudolfKastl also disagreed with Christopher[14] on where the line should be drawn on bugs that should be fixed with updates. Rudolf pointed out that presto would probably make the updates palatable for users and that Fedora's rapid progress was one of the reasons he used it instead of other distros.

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

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

Echoing[15] the general happiness with the updates strategy, KevinKofler thought that the updates were Fedora's strength and differentiated it from other distros. MichaelSchwendt was skeptical[16] because of the unhappiness of users with broken apps. Rahul proposed[17] that a policy on updates be written, prompting a negative reaction from HansdeGoede[18] who requested that objective measurements be used to determine if a problem existed before any policies were written. NeilThompson was much more blunt, and worried [19] that his bowel movements would soon be regulated and that the community was being destroyed by heavy-handed bureaucracy. Responding to this MatthiasClasen deprecated[20] the language and suggested that the granularity of updates mentioned previously would allow filtering on the client side.

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

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

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

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

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

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

Pay Per Spin Web Interface?

A new forum to provide respins of Fedora called respins.org was mentioned[1] by RahulSundaram. Rahul wondered if there was a web-interface layered over pungi and livecd-tools to allow package selection and ISO generation.

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

NicolasMailhot wasn't too keen[2] about the bandwidth implications. Rahul argued that infrastructure had not objected, but MikeMcGrath responded[3] that Rahul hadn't given them enough information to determine how much bandwidth would be used. It seemed there was a mis-communication over which emails should have been ignored.

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

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

SethVidal responded[4] to Nicolas that the costs of such a service would be huge and a fee-based site had been discussed to allow individuals to produce a customised spin. Seth donned asbestos underpants and pointed out that the tool would be fully open source. JonathanSteffan offered up[5] some of the Red Hat interns working on the project to take some of the flames, but for some reason they remained quiet! Jonathan also posted[6] details of the current and future state of the Revisor tool. It wasn't clear from reading this whether this is what the interns are working on. Revisor currently has a Gtk front-end, but the development work could see that replaced with anything including a web front-end.

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

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

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

JeroenVanMeeuwen, also of the Revisor project, posted[7] more details including the massive number of enhancement requests they're receiving.

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

Secondary Arch Proposal Cont.

Last weeks proposal on 2ary architectures[1] by TomCallaway continued to draw comment. ChristopherBlizzard had several points to make[2] , and ThorstenLeemhuis objected[3] to the first, which was that a maintainer would be responsible for making sure his/her package built on all the primary architectures. Thorsten thought this would dissuade people from being Fedora maintainers and preferred the model pioneered by DavidWoodhouse for PPC in which there would be a team/SIG which could be appealed to for help.

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

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

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

David thought[4] that Chris actually had the right idea and that ideally maintainers should be competent enough to fix bugs and thoroughly understand the code and preferred to sacrifice quantity to quality. David also thought that the maintainer's sponsor should have primary responsibility to help the maintainer, but also saw the value of a team which could help out. In his experience most bugs were not actually arch-specific, but were generic and just exposed on particular architectures. KevinKofler and David swapped[5] examples of such bugs.

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

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

The question arose[6] as to whether PPC was a secondary architecture now, and David answered[7] negatively, pointing to a decision to wait until another architecure has proved the system will work. MattDomsch backed this up[8] with a link to the Jun 12 FAB minutes, while AxelThimm disputed[9] Matt's interpretation.

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

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

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

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

F8 Devel - User Storage Configurations

A proposal to create a single directory to hold all the dot-files created by applications to hold user settings was mooted[1] by DavidTimms. It received mainly negative responses from KDE users[2] . MatejCepl also pointed David to the work done already by the freedesktop project on basedir[3] .

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

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

[3] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.5.html

R500 Initial Driver Release

FlorianLaRoche and MikeChambers both wanted to know if the R500 drivers (for very recent ATI video cards) would be packaged for F7 or F8. AdamJackson (ajax) responded[1] that he needed to test them on their intended hardware first. Mike and AdamTkac were eager[2] to put their X1300s to the test.

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

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

Very quickly ajax posted[3] a notification of a testbuild, noting its failure on his own T60p, requirement of libpciaccess and inclusion in the next rawhide push. DavidZeuthen gave[4] quick, detailed feedback about partial success on a MacBookPro with an X1600/M56P. NathanielNoblet with an X1650[5] , and MikeChambers with an X1300 had a disappointing experience and ajax emphasized[6] that he was making sure that bugs reported to him would pass upstream.

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

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

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

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

Documentation

In this section, we cover the Fedora Documentation Project.

http://fedoraproject.org/wiki/DocsProject

Contributing Writer: JonathanRoberts

docs.fedoraproject.org Stats

MikeMcGrath posted a link to the fedora-docs-list[1] , pointing to the statistics for the docs.fedoraproject.org site[2] . The statistics show that, so far this month, there have been 149,219 unique visitors to the site! It was noted, however, that the number one search term was "disable selinux", leading to a discussion about the current state of the SELinux FAQ.

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

[2] http://fedoraproject.org/awstats/docs/awstats.docs.fedoraproject.org.html

SELinux

After reviewing the statistics for docs.fedoraproject.org, KarstenWade pointed out that there was no maintained canonical FAQ, with the top two results on Google for "disable selinux" pointing to the FC3 SELinux FAQ and the RHEL 4 SELinux FAQ[1] . As a possible solution to this it was proposed that a permanent URL on the wiki, or on the future Plone implementation, would help encourage regular updates. It was decided, however, that the FAQ should point upstream to selinuxproject.org for overall information, with Fedora specific information maintained by the Documentation Project[2] . PauloSantos stepped forward and offered to maintain this FAQ[3] .

[1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00077.html

[2] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00084.html

[3] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00086.html

Documentation Project Steering Committee Meeting

The log for the 12th June meeting of the FDSCo was posted to the fedora-docs-list[1] . A HTML version is also available[2] .

[1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00085.html

[2] http://fedoraproject.org/wiki/DocsProject/SteeringCommittee/Meetings/Minutes/IRCLog20070612

Summer Of Code

VillePekkaVainio posted a question to the fedora-docs-list regarding his Summer Of Code project, creating a system for publishing and editing man/info pages with MoinMoin[1] . The question revolves around the best format to store the information in, trying to strike a balance between making editing available to new users and making the edits accessible to upstream as easily integrated patches.

Amit Uttam wrote to the fedora-docs-list about his Summer Of Code project, to create an elegant DocBook to PDF solution. Despite this project not being selected as an official Summer Of Code project, he still plans to develop the project[2] , and as such, posted the original project proposal.

[1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00082.html

[2] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00088.html

Translation

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

http://fedoraproject.org/wiki/L10N

Contributing Writer: JasonMatthewTaylor

Meeting Times

The Translation team is looking at different meeting times[1] to ideally get more attendance, which, in turn will help better organize and direct the project.

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

Monitoring Commits

For those that are so inclined, it is now possible to monitor Translation team commits[1] .

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

Infrastructure

In this section, we cover the Fedora Infrastructure Project.

http://fedoraproject.org/wiki/Infrastructure

Contributing Writer: JasonMatthewTaylor

Security Updates

DamianMyerscough noted some security concerns[1] to be addressed in the near future.

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

Escalation Paths/Methods

Discussion[1] has been had about how and who to notify in the event of various outages/events.

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

Artwork

In this section, we cover Fedora Artwork Project.

http://fedoraproject.org/wiki/Artwork

Contributing Writer: JonathanRoberts

Fedora 8 Theme

Following last weeks discussion about artwork for Fedora 8, this week has seen a lot of activity over the creation of a new theme for Fedora 8, with several mock-ups being created. Focus has been spread across a number of mock-ups, including MartinSourada's work[1] , MairinDuffy's[2] and Mark's[3] . A lot of the information discussed in the threads has been collated into a wiki page[4] , making it easily accessible.

The discussion about artwork for Fedora 8 also branched out to the Fedora Forums, with a summary of the thread posted to the list[5] .

[1] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00089.html

[2] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00114.html

[3] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00092.html

[4] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00121.html

[5] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00110.html

Security Week

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

Contributing Writer: JoshBressers

Fedora Security Response Team

Last week was a rather slow news week as far as security news goes. The biggest news that should affect Fedora would be the fact that the Fedora Security Response Team has finally gotten off the ground. The group is currently pouring over the current list of known CVE ids to determine if we've missed any old flaws in Fedora 7. Once that's done the team will take over the constant task of parsing all the new vulnerabilities that affect Fedora 7.

Anyone is welcome to help in this effort. One of the team goals is to keep things open and transparent. Anytime security work is being done, it is hard to keep the process open for a number of reasons. One of the bigger reasons is that if all the information isn't public, it can be easy to sweep certain flaws under the rug and forget about them. This is bad for any project, especially something like Fedora.

If you have any interest in this group, feel free to join the mailing list[1] , or stop by #fedora-security on Freenode. All are welcome, there's plenty of work to do. It's still a small team, but the current group seems to be doing a fine job. More informatoin on the team can be found on the wiki[2] .

[1] http://www.redhat.com/mailman/listinfo/fedora-security-list

[2] http://fedoraproject.org/wiki/Security/ResponseTeam

Advisories and Updates

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

Contributing Writer: ThomasChung

Fedora 7 Security Advisories

Fedora Core 6 Security Advisories

Events and Meetings

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

Contributing Writer: ThomasChung

Fedora Board Meeting Minutes 2007-06-12

Fedora Documentation Steering Committee 2007-06-12

Fedora Engineering Steering Committee Meeting 2007-06-14

Fedora Infrastructure Meeting 2007-06-14

Fedora Indian Ambassadors Meeting Minutes 2007-06-13

Fedora Packaging Committee Meeting 2007-06-12

Fedora Release Engineering Meeting 2007-06-11

Extras Extras

Contributing Writer: ThomasChung

An interview with Fedora leader Max Spevack

MaxSpevack was interivewed by LWN[1] :

"Now that Fedora 7 has been released, Fedora project leader Max Spevack has a little bit of breathing room. Like nature, LWN abhors a vacuum, so we sent Max a list of questions and a request for answers. We are now happy to present the answers. Without further ado..."

[1] http://lwn.net/SubscriberLink/237700/f18ea8cb3b2c9745/

Thomas Chung gives Fedora Talk at Caltech

ThomasChung gave a Fedora Presentation for San Gabriel Valley Linux Users Group at Caltech[1] on his birthday. The topic was "Fedora 7 - What's New" and Live Demo on virt-manager with KVM and Revisor. Some Fedora 7 DVDs and Fedora Stickers were also given to the group at the end of the presentation.

[1] http://www.caltech.edu/content/san-gabriel-valley-linux-users-group-monthly-meeting-68

Feedback

This document is maintained by the Fedora News Team[1] . Please feel free to contact us to give your feedback. If you'd like to contribute to a future issue of the Fedora Weekly News, please see the Join[2] page to find out how to help.

[1] http://fedoraproject.org/wiki/NewsProject

[2] http://fedoraproject.org/wiki/NewsProject/Join

Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Issue92&oldid=315884"