From Fedora Project Wiki

< FWN

Revision as of 10:59, 14 April 2009 by Fab (talk | contribs) (added category)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Fedora Weekly News Issue 111

Welcome to Fedora Weekly News Issue 111 for the week of November 26th. http://fedoraproject.org/wiki/FWN/Issue111

In Planet Fedora, we have "Free Creative Commons 5th Bday DEC 15 in San Francisco", "Testing Needed: mkinitrd bash-branch", "The plan for Xen kernels in Fedora 9", "Zagreb of Croatia Reporting" and "Official: FUDCon, Raleigh, January 11-13 2008"

In Marketing, we have "IcedTea interview"

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


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

Free Creative Commons 5th Bday DEC 15 in San Francisco

JonPhillips points out in his blog[1] ,

"CC is turning 5 and to celebrate we’re throwing a community-wide party. If you’ll be in the San Francisco Bay Area on December 15, join us for a night of celebrating the commons at a party generously sponsored by Mozilla and Last.fm."

[1] http://rejon.org/2007/12/02/free-creative-commons-5th-bday-dec-15-in-san-francisco/

Testing Needed: mkinitrd bash-branch

WarrenTogami points out in his blog[1] ,

"One of the things I've been working on is an experimental branch of mkinitrd that uses bash to run the /init script instead of just nash. Having a real shell allows more flexibility in what can be done in the initramfs in shell scripting."

[1] http://wtogami.livejournal.com/21452.html

The plan for Xen kernels in Fedora 9

DanielBerrange points out in his blog[1] ,

"This is a friendly alert of the major plans we have for Xen kernels in Fedora 9 timeframe... Also syndicated on the fedora-xen mailing list."

[1] http://berrange.com/personal/diary/2007/11/plan-for-xen-kernels-in-fedora-9

Zagreb of Croatia Reporting

DimitrisGlezos points out in his blog[1]

"So here I am, in beautiful Zagreb of Croatia in a big circle of chairs where 40 people from more than 20 countries have come together for the Open Translation Tools Convergence event."

[1] http://dimitris.glezos.com/weblog/2007/11/30/zagreb-reporting/

Official: FUDCon, Raleigh, January 11-13 2008

GregDeKoenigsberg points out in his blog[1] ,

"If you've ever wanted to see Red Hat Global HQ, now you've got an excuse. The Fedora User and Developer Conference will be held in Raleigh NC. As we did last time: FUDCon Friday will be the free-for-all BarCamp style event, and Saturday and Sunday will be hackfest time."

[1] http://gregdek.livejournal.com/20235.html

Daily Package

The Fedora Daily Package is back after an extended hiatus! In this section, we recap the packages that have been highlighted this week[1] .

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

Contributing Writer: ChrisTyler

iotop - Display I/O Activity by Process

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

"System administrators have always relied on top for per-process CPU and memory usage statistics, and vmstat (or sar) to analyze I/O -- but there has been no easy way to analyze disk I/O on a per-process basis. iotop is the missing tool. It shows the disk read and write rate, swapins, and total disk I/O for each process. The process list is sorted by I/O and updated once per second."

[1] http://dailypackage.fedorabook.com/index.php?/archives/150-Productive-Monday-iotop-Display-IO-Activity-by-Process.html

[2] http://guichaz.free.fr/misc/#iotop

gimp-resynthesizer - Texture synthesis for the Gimp

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

"Gimp-resynthesizer is a texture synthesis plugin for the Gimp. It can be used to create additional quantities of a texture, make a tileable texture, or remove objects from an image."

[1] http://dailypackage.fedorabook.com/index.php?/archives/153-Artsy-Tuesday-gimp-resynthesizer-Texture-synthesis-for-the-Gimp.html

[2] http://logarithmic.net/pfh/resynthesizer

Wednesday Why: Grub Boot Configuration

The Wednesday Why article[1] was on grub bootloader configuration:

"Fedora, like most current Linux distributions, uses Grub as its bootloader on 32- and 64-bit x86 systems. Grub's configuration file, /boot/grub/grub.conf, typically looks something like this... "

[1] http://dailypackage.fedorabook.com/index.php?/archives/154-Wednesday-Why-Grub-Boot-Configuration.html

ManEdit - manpage editor

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

"For many years Unix and Linux systems have offered convenient online documentation in the form of manpages. These documents provide short, concise information about commands, applications, file formats, APIs, and interfaces. They use a simple markup and can be easily processed for display in a terminal or online help application, converted to PDF, printed using PostScript, or posted to the web as an HTML page. ManEdit is a graphical editor intended to simplify the task of creating and maintaining manpages."

[1] http://dailypackage.fedorabook.com/index.php?/archives/149-GUI-Thursday-ManEdit-manpage-editor.html

[2] http://wolfpack.twu.net/ManEdit/

Super Tux Kart - Go-cart racing game

Friday Fun highlights fun, interesting, and amusing programs. This Friday[1] covered Super Tux Kart[2] :

"Super Tux Kart is a simple but fun go-kart racing game (similar to some that you may have played on an older-generation game console)."

[1] http://dailypackage.fedorabook.com/index.php?/archives/155-Friday-Fun-Super-Tux-Kart-Go-cart-racing-game.html

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

Marketing

In this section, we cover Fedora Marketing Project.

http://fedoraproject.org/wiki/Marketing

Contributing Writer: ThomasChung

IcedTea interview

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

"The IcedTea interview is now up. ThomasFitzsimmons didn't have a picture handy that we could use so that bit's been left out."

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

RFC: Package Review VCS

A request[1] from WarrenTogami for comments and suggestions on his initiative to provide a VCS[2] to help manage the review queue problem[3] [4] seemed to garner mostly negative reaction. Warren's proposal was to create a new CVS area, which parallels the functionality of the existing /cvs/pkgs, in order to facilitate quick test builds of non-packagers submissions. Warren listed the advantages as faster and easier collaboration allowing input from both packagers and non-packagers. This would in effect create "Level 0 Packagers" who can obtain reviewer feedback, learn the ropes of the arcane CVS procedures and contribute to packaging.

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

[2] http://en.wikipedia.org/wiki/Version_control_system

[3] FWN#110 "As Review Request Queue Lengthens Tempers Shorten" http://fedoraproject.org/wiki/FWN/Issue110#head-8efe1733d34143a793ace16ad238876de3d639a1

[4] FWN#109 "When Will CVS Be Replaced By A Modern SCM?" http://fedoraproject.org/wiki/FWN/Issue109#head-e11f507ce98aaa21bf98ff7129f74450725f4ab2

An initial concern raised[5] by TomCallaway concerned the submission of material of dubious legality, but after Warren outlined[6] a procedure for the prompt removal Tom seemed[7] satisfied and was going to query "legal" about the issue.

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

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

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

The other main objections came from JoshBoyer and JesseKeating and seemed to largely question the utility and purpose. Jesse seemed[8] to have misunderstood that the primary thrust was to enable newcomers to contribute (although existing packagers also have a significant role to play in interacting with them).

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

JoshBoyer was skeptical[9] about using CVS but thought keeping track of changes in the specfile of the package during review had to be done anyway. Warren acknowledged CVS's suckitude compared to e.g. "Bazaar" but thought the exposure of new contributors to the existing CVS workflow was important. Warren also argued[10] that keeping a history during pre-review would be useful to enable collaboration at a centralized, single point. Josh returned[11] to the argument that there was no reason to introduce this new process because the existing review procedure was useful in determining the responsiveness and adaptability of packagers. He also argued that using CVS meant that the history would have to be manually copied by the packager from the proposed /cvs/pkgreview to the existing /cvs/pkgs repositories, introducing extra work for little benefit. Warren disputed[12] that it as that much more work and there the discussion seemed to rest.

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

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

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

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

Review Queue Cont.

Our last report[1] on the angst over the review process was filed before the American Thanksgiving Break and our generous editor granted a week off for the holiday. We now return to our regular programming and finish up reporting on the discussion, which seems like an important one.

[1] FWN#110 "As Review Request Queue Lengthens Tempers Shorten" http://fedoraproject.org/wiki/FWN/Issue110#head-8efe1733d34143a793ace16ad238876de3d639a1

NicolasMailhot raised[2] the point that it was irritating to spend time following the guidelines and procedures and end up sidelined by an executive decision being made apparently outside of that process. The specific instance being raised by Nicolas involved[3] the addition of an "OR" conditional operator and the "do nothing and return 0" BASH builtin ":" to the parts of Nicolas' RPM scriptlets which attempt to use fc-cache for packages which install fonts. This converted them from failing with various error codes, to returning a zero. Nicolas advanced some cogent reasons as to why his method was preferable, especially that silently accepting the transaction meant that fontconfig users would be misled into thinking that fontconfig was in error as opposed to the font package. He added the information that now only the affected package would fail.

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

[3] http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=diff&rev2=14&rev1=13

An acknowledgment of Nicolas' position was posted[4] by TomCallaway (who had made the changes to which Nicolas referred), but he added that it was policy that "%post" should never fail for some time now and he had been correcting an oversight. Tom asked Nicolas not to take it personally and advanced the opinion that Nicolas' font guidelines were rather good. MatthiasClasen thought that "sweeping the failure under the carpet" instead of writing correct scriptlets was incorrect and although Tom pointed out this was too much work for the FPC argued[5] that maybe RPM should ignore the exit code of scriptlets if scriptlets were "never, ever [allowed to] fail."

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

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

ThorstenLeemhuis flagged the absence of entities responsible for realizing adjustments to package guidelines in the actual packages and used[6] the specific example under discussion to show how a simple script could make these changes. He noted that he could have all affected packages brought into line with the changed guidelines in thirty minutes, but that "[...] nobody does that, as modifying packages that are owned by other people is frowned upon in Fedora land." Strong agreement was expressed[7] by ColinWalters that this sort of automation should be pursued to cohere with a broader goal of "[...] a model based on peer review, collective ownership and automation, not personal fiefdoms and manual integer increments in text files." JesseKeating expressed his happiness with Thorsten's proposed automated changes as long as the Fonts SIG had no objections. NicolasMailhot responded[8] that while spoke as only one member of the Fonts SIG he would insist that the author of the change defend the proposal through the established channels of the SIG list. He expressed a personal opinion that this was a fix in search of a problem and seemed to think that this was a gratuitous change motivated by the desire to make a point: "I don't mind people touching my packages, but only if there are actual problems to fix." Nicolas appeared to characterize making this type of change as "[being] a bastard" (applying the epithet to himself, but also by extension anyone else making such a change.)

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

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

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

A summary from JesseKeating asked Thorsten whether he was trying to fix a real problem or just trying to ensure guidelines were implemented. Thorsten's response indicated[9] that he "[did not] much care about [this particular font issue] " and was more concerned with the general problem of changes in Packaging Guidelines not being implemented efficiently merely because of the "nobody else is allowed to touch [my package] " mantra. He asked FESCo to provide advice for the specific example under discussion as well as more general advice. PatriceDumas (who had earlier made clear[10] his agreement with Nicolas that the FontSIG procedures should have been followed) agreed with Thorsten that FESCo should take a lead and drew attention[11] to package maintainer policies which imply that such changes are already allowed in CVS. Doxygen was cited as an example of another potential beneficiary from such automated updates unfettered by consulting with each package maintainer. Thorsten thought[12] that Firefox was a better example and emphasized again the need for FESCo to take the lead especially because of ACLs which might prevent automated changes to CVS. RalfCorsepius agreed[13] strongly with this and added the splitting of PERL packages as another example (TomCallaway responded to this latter example with the information that he had fixed most of these weeks ago.)

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

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

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

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

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

The central problem of nobody actually doing the work of writing the script which Thorsten proposed would "rebuild all packages that depend on [Firefox] once it's built and in the buildroot" was foregrounded[14] by JesseKeating. Jesse also commented that effort was going into creating a situation where this "one-off won't be necessary." RichiPlana disagreed[15] that it was a one-off or that avoiding such situations was always desired. He suggested that it was important for FESCo to take the managerial role which showed that creating such a script was sanctioned and approved and that time invested in it would not be wasted. Thorsten thought Jesse's sort of response was a little de-motivating and scared people away. He suggested[16] more positive alternatives and then donned the guise of Knurd The Package Monkey to whip up an example script, which he argued wasn't really that much of an effort.

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

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

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

Jesse, while acknowleging the potential usefulness of the script, argued[17] that time would be better spent in transitioning to xulrunner support (see FWN#110 "Gecko-libs Now Provided By Xulrunner-devel"[18] ), explained he had insufficient time to do anything expect provided feedback in the Gecko-stack problem space. Jesse suggested that a body be created to ensure the co-ordination of updates from building, through to pushing out to repositories at the same time. Thorsten disagreed[19] about the "one-off" nature, pointing out that the twelve month lifetime of Fedora 8 probably justified at least one or two months of work. He also volunteered to try integrate the necessary changes with Bodhi, building on LukeMacken's work as suggested by Jesse.

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

[18] http://fedoraproject.org/wiki/FWN/Issue110#head-f3cc877838b36ec87d5a37b92645e8f025dfceb0

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

In a small side-thread, a query from Thorsten about specific versioning in the path of the xulrunner package removing its potential to solve the Firefox problem was answered[20] by ChristopherAillon who explained that this rawhide version was in pre-release with a non-fixed ABI and was subject to a great deal of change.

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

Core Fonts Issues

An apparently slowly smoldering dispute over the treatment of older "core fonts" flamed up in a couple a of places. This is linked in to the larger dispute over the review queue and governance issues raised within (see this same FWN#111 "Review Queue Cont.")

Nicolas forwarded[1] an email from @fedora-fonts from HansdeGoede which was about the failure of post-install scriptlets to run for core fonts rpms. Hans wondered why the files were generated this way instead of being pre-generated and shipped in the package. Nicolas noted that the packages which Hans was talking about followed the provisional fontconfig guidelines and that he himself did not care about the core font side of things. Due to the split nature of the discussion over the two lists, it is a bit confusing trying to follow the flow of the conversation, but it seems that BehdadEsfahbod provided the information that fontconfig had not stored cache files in /usr/share/fonts for some time, using /var/cache/fontconfig instead. Behdad also wondered where Hans thought the files should be generated, to which Hans replied[2] that this should be done at buildtime instead of generating them with scriplets. Hans demonstrated[3] that urw-fonts and ghostscript-fonts had a problem because they did not generate the fonts.dir and fonts.scale expected by older applications such as xfig. Hans suggested that some guidelines on handling the core fonts were necessary and suggested two options, his preferred one being to generate fonts.dir and fonts.scale at buildtime.

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

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

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

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

Then NicolasMailhot explained[5] that the obsolete core fonts would have to be maintained by those actually using them. He further detailed[6] problems caused by shipping the fonts.dir and fonts.scale files and suggested splitting the core fonts scriptlets into a subpackage, or shipping pre-generated files would prevent a negative impact on the majority of users, who do not use core fonts. Hans agreed and suggested[7] the two main options of using pre-generated files or conditionally running mkfontdir.

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

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

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

A restatement of the problem was posted[8] by Nicolas approximately a week later in which he requested interested parties to take up the burden of maintaining these fonts. While offering support for anyone who was willing to take on the maintenance burden Nicolas made it clear that he would not be responding to "strident" calls due to the "level of abuse we've seen from core font users lately." He explained that "dreaded can not find font 'fixed'" error message was one of the problems done away with for ever by removing xfs from Fedora 8. HansdeGoede apologized for any abuse but stated that those initiating change had the onus to fix any breakage.

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

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

Fedora 8 Boot-up Speed

Although using hardware which should be adequate DimiPaun found[1] that the total time taken to boot was excessive, taking over two minutes. AdamJackson(ajax) agreed[2] and asked whether Dimi had investigated the problem using bootchart.

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

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

Helpful suggestions to improve the situation followed: GaryThomas recommended[3] trying with the latest kernel; EricSandeen reminded[4] that Fedora 8 was not using readahead by default which might improve the situation.

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

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

RudolfKastl drew attention[5] to his own work on initng which may make it possible to get from start of init to GDM with NetworkManager in fifteen seconds. Currently there are some complications with SELinux.

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

KulbirSaini suggested[6] disabling unused services and delaying the initialization of network services until after login. As a comparison he posted that it took 50 seconds from GRUB to login on possibly(?) inferior hardware.

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

MarkG85 posted[7] his bootchart, which appeared[8] to show a strange 7 second delay. BillNottingham responded[9] that this was possibly due to either a problem with bootchart or an incorrectly initialized driver in the initrd causing hotplug issues. For the remainder the starting of X seemed to be where most of the problems were and this was being actively addressed. AdamJackson added[10] to this that he had taken care of the low-hanging fruit in this regard and the results could be found in rawhide.

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

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

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

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

DimiPaun was not convinced[11] by the bootchart-error hypothesis and posted his own bootchart. JesseBarnes confirmed[12] this and echoed BillNottingham's idea that it was due to hotplug events and suggested contrasting with a non-initrd configuration. DavidZeuthen added[13] the speculation that this was due to "some really ugly tricks to make sure that the kernel names (e.g. sda, sdb etc.) for the devices are in a specific order (scsi_wait_scan.ko etc.). Seems literally like a waste of time; better fix the rest of the OS not to rely on things like kernel names."

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

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

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

A follow-up post by MarkG85 contrasted[14] an init-ng bootchart with the regular initrd one. There seemed to be the same initial delay, but then a halving of the remainder of the time. MarkG85 requested information on how to examine the scripts in initrd but then quickly shared[15] an appropriate link and a new bootchart with reduced boot time. He concluded[16] sadly that there was not much that could be done to speed up the current initrd set-up.

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

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

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

WTF? Inaccessible Bug Reports?

A non-authorized OlivierGalibert asked[1] why he was not authorized to view the bugzilla entry which detailed why DavidCantrell had disabled static IP when using kickstart.

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

As could be expected passions were high, but DanielBerrange explained[2] that some bugs were embargoed for security reasons or because they contained customer data which was sensitive. He advised a polite request instead of a rant.

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

Later the thread diverged into a discussion[3] of large deployments of Fedora in various environments and of the gradual drift of Fedora away from a sparse "UNIX" background into a more Windows-like system[4] .

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

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

ChrisLumens answered[5] that no one was trying to make Olivier's life "hell" and provided both details of why the change had been made and how Olivier could determine what changes had been made and why (by git sha1sums and bug numbers in the logs).

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

Alpha/Beta Software In Fedora 8: Bind

ChuckAnderson queried[1] whether the inclusion of an alpha release of bind (9.5.0a7) was acceptable as it was alpha/unstable software in a stable release. A very long thread ensued. Chuck's specific problem manifested[2] itself as a segfault. General reactions were split between those who thought that software which was alpha should not be included in a stable release tree and those who thought that relying upon arbitrary labels such as "alpha" was pointless and that the decision was up to the package maintainer.

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

[2] https://bugzilla.redhat.com/show_bug.cgi?id=400461

The maintainer, AdamTkac, responded[3] promptly with the explanation that he had included this version of BIND because it had nice new features. He added that some bugs were possibly the price to pay and that additionally he did not believe that users installed the latest Fedora on important servers. ToshioKuratomi, while he expressed support for Adam's decision as maintainer to include software with new features, stressed[4] that the latter part of his response was not a valid reason. Adam agreed[5] that Fedora was not a testing ground for RHEL. Dexter disagreed[6] on this point, citing an email from MaxSpevack as evidence. JesseKeating[7] and JeremyKatz[8] interpreted that email differently, arguing that "enterprise oriented" should be seen in terms of what support is being added, rather than the distribution being more stable. Jeremy cited his work on LiveCD ISO installs as support being added for community-driven needs versus his work on iSCSI install-time support being enterprise-driven.

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

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

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

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

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

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

MarkG85 argued[9] that because Fedora is used on servers there ought to be core server components which are treated in a conservative manner, as opposed to desktop-related applications which can be more fluid. JefSpaleta[10] suggested that in addition to the desktop/server axis it would be useful to add the dimension of maintainer-capability. He added that more explicit signalling by maintainers of pre-release (e.g. alpha) software might be useful so that concerned admins could direct their testing efforts towards components essential for their systems. AdamTkac pointed[11] out (as in several other places in the thread) that this version had been in rawhide for over five months without a single issue either being reported in bugzilla or manifesting itself during his own testing. He suggested that a knee jerk reaction to the alpha status might be occurring. TomasMraz was sympathetic[12] to this observation as was AndrewFarris[13] , citing Evolution's non-alpha, yet buggy-as-hell track record.

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

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

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

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

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

Less impressed[14] was BillNottingham, who wondered what exactly were the essential new features which justified an "*alpha*" version being "pushed" onto users. MartinStransky supported[15] Adam's decision and argued that the alpha/beta versions of bind were often more stable than other projects' stable releases. When Bill replied that in effect a maintainer shipping an alpha was claiming to know better than the upstream project how stable the code was he met[16] with the information that ISC (BIND's upstream) were very conservative due to support issues for paying customers. Further, MartinStransky argued[17] that the maintainer should be able to make "exactly" this sort of decision instead of "blindly repeating what upstream officially says."

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

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

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

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

ChuckAnderson's direct question about whether there were policies regarding these situations was somewhat answered when JasonTibbitts pointed[18] to a MaintainerResponsibilityPolicy which seemed to avoid needless bureaucracy. TomCallaway agreed[19] that this seemed like the appropriate approach of trusting the maintainer and could not be made much more specific. JesseKeating suggested[20] an addition which attempted to address the alpha/beta issue by drawing maintainers attention to important considerations and yet reposing trust and power in their hands.

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

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

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

SteveGrubb wondered about "unreleased snapshots" and cited[21] kdepim as a problem, he augmented[22] this with the information that it had caused serious data loss and disruption to his work. JesseKeating replied[23] that similar problems could happen with "stable" releases and that maintainers and users had to catch problems in updates-testing.

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

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

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

TV Support In Fedora 9

A desire for improved support of various TV tuner cards in Fedora 9 was expressed[1] by OttoRey. He noted that although he was technically competent he failed to get hardware working with Fedora 8 and MythTV.

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

ArthurPemberton recommended[2] that installing a Hauppage card was the easiest course, while KingInuYasha suggested[3] that any card with a Theater200 chip might be supportable as elisa[4] could obtain MPEG2 codecs through gstreamer. IgnacioVazquezAbrams thought[5] that elisa was not ready for prime time and also cautioned[6] that not all Hauppage cards were well supported.

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

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

[4] http://elisa.fluendo.com/

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

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

The outlines of the general problem were provided[7] by BastienNocera, who mentioned kernel-drivers, firmware and codecs for MPEG2 and MPEG4 as the main problems. VilleSkyttä mentioned that the last problem might be solved because many cards had hardware decoders, and upon request supplied[8] probable cards (Hauppage or Technotrend "Full-featured" or "Premium") as did KingInuYahsi[9] (ATI Theater 200).

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

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

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

Heads Up! Rpm Default Queryformat To Include Arch

A potentially far-reaching change was announced[1] by PanuMatilainen. This is the inclusion of package architecture in the default queryformat. He asked for anyone that might be affected to "please holler NOW!" and noted that fixing affected scripts could be done trivially by using the explicit --qf "%{name}-%{version}-%{release}"

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

CallumLerwick jokingly wondered why the default, which will be rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n" would not also include the epoch of the package, e.g. %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} and was answered[2] by "nodata" that this would encourage the usage of epochs. Panu thought this was unlikely but pointed[3] out that, while there were advantages in making epochs more explicitly visible, it would mean having to add epochs into filenames. He added[4] that upstream rpm.org was doing this.

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

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

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

There was a lot more discussion about whether it was desirable to display epoch numbers unconditionally with a default of "0" for non-existent epochs. SethVidal was against the idea and pointed[5] to Yum's handling of the situation. RalfCorsepius, MichaelSchwendt and TomCallaway were also strongly against[6] the idea.

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

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

Panu sought[7] reasons as to why it was bad and received[8] a compound answer from TomCallaway that argued that both the use of the ":" character as a separator and the use of epochs themselves were hackish. Similar arguments were made by BillNottingham and MichaelSchwendt.

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

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

Metacity Dependency Forced During Fedora 7 To 8 Upgrade

PeterLemenkov light-heartedly characterized[1] the installation of "metacity" during his upgrade from F7 to F8 as the imposition of someone's "evil will" as he had no need for either metacity or nodoka-metacity-theme on his fvwm box. He wanted to know why he could not remove metacity completely as in Fedora 7.

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

A brief investigation conducted[2] by MartinSourada tracked the problem down to dependencies in system-config-display and firstboot. But Peter showed[3] that the problem was perhaps a bit more extensive, posting a long list of packages that were slated for removal when he executed yum remove metacity. After LubomirKundrak requested more information by upping the debug level for yum yum -d5 remove metacity Peter posted[4] a link to the log from this command.

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

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

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

AdamJackson explained[5] why system-config-display need a window manager and wondered if the alternatives of depending on gnome-wm or requiring miniwm from anaconda were preferable. Upon prompting from JeremyKatz it looked[6] as though Adam was willing to adjust s-c-m if Jeremy were willing to subpackage miniwm and fix firstboot.

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

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

NetworkManager To Get UMTS/GPRS Support

An announcement[1] from RudolfKastl that a new wiki page had been created to document the addition of UMTS support[2] to NetworkManager prompted DanWilliams to comment[3] that work by TambetIngo adding basic GSM/UMTS serial and cellular support was just about to land in the subversion repository. Some interesting discussion followed including an offer[4] of informational help from RandyWyatts.

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

[2] http://en.wikipedia.org/wiki/UMTS-TDD

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

[4] https://www.redhat.com/archives/fedora-devel-list/2007-November/msg02241.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 Elections

It's that time again for Fedora Board Elections. As MaxSpevack pointed out in his message[1] , there is one community seat open and the elections run until December 6. More information is available on the Fedora Elections Wiki[2] .

[1] https://www.redhat.com/archives/fedora-advisory-board/2007-November/msg00242.html

[2] http://fedoraproject.org/wiki/Board/Elections

Fonts

In this section, we cover discussion in Fedora Fonts.

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

Contributing Writer: MichaelLarabel

Core Font Packaging Guideline Writer Wanted

With the focus turning from core fonts to client-side fonts over the past few years, in Fedora 8 the state of core fonts isn't so pleasant. The core font change for Fedora 8 wasn't integrated properly and some packages were left in a broken state. To fix for Fedora 9 and future occasions, NicolasMailhot has called out to interested writers that they join the font SIG (Special Interest Group), write the core font packaging guidelines, discuss these guidelines, and audit existing packages to ensure that they meet these new requirements.[1]

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

Documentation

In this section, we cover the Fedora Documentation Project.

http://fedoraproject.org/wiki/DocsProject

Contributing Writer: JohnBabich

Works in Progress

BartCouvreur noted that the draft version of the Fedora Administration Guide [1] is progressing nicely [2] . It is hoped that it will be ready for publishing as an immutable document in http://docs.fedoraproject.org in the near future. Future edits can then continue on the wiki as usual.

The Fedora Desktop User Guide [3] has also come back to life, thanks to some recent volunteers. We still need people to contribute more content in the KDE and Xfce sections.

[1] http://fedoraproject.org/wiki/Docs/Drafts/AdministrationGuide

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

[3] http://fedoraproject.org/wiki/Docs/Drafts/DesktopUserGuide

Apache FOP in Rawhide

KarstenWade passed on the welcome news that FOP is now in the Rawhide repository and available for testing [4] . Apache FOP (Formatting Objects Processor) is potentially useful to the Docs Project as a tool for producing PDF files from DocBook XML sources.

In the past, FOP contained encumbered code, making it unsuitable for inclusion in a completely free tool chain, since one of the goals of the Docs Project is to use only FOSS tools to produce FOSS documentation. Apparently, the Rawhide version of FOP is now capable of running using IcedTea. "The IcedTea project provides a harness to build the source code from the OpenJDK project using Free Software build tools and provides replacements for the binary plugs with code from the GNU Classpath project." [5]

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

[5] http://fedoraproject.org/wiki/Features/IcedTea

Translation

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

http://fedoraproject.org/wiki/L10N

Contributing Writer: JasonMatthewTaylor

Translation Quick Start Guide

For those interested in helping out with the translation of the various documents the Fedora Project has, there is an updated quick start guide[1] that NorikoMizumoto among others have poured quite a bit of effort into. If you use the guide and find some things you think could be improved, let them know!

[1] http://docs.fedoraproject.org/translation-quick-start-guide/en_US/

Infrastructure

In this section, we cover the Fedora Infrastructure Project.

http://fedoraproject.org/wiki/Infrastructure

Contributing Writer: JasonMatthewTaylor

Project SSL Usage

ToshioKuratomi mentioned this week[1] some observations regarding the Fedora Projects usage of SSL in its' web applications. He noted that the Koji[2] build system, after setting a session cookie via SSL did not require the cookie to be sent back to the server via SSL and that the Turbo Gears[3] URL could be changed to a non-SSL URL thus creating a security hole. He followed up with this post[4] which indeicated that the above mentioned holes were fixed.

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

[2] https://hosted.fedoraproject.org/projects/koji/

[3] http://turbogears.org/

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

Security Week

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

Contributing Writer: JoshBressers

Firefox 2.0.0.10

Firefox 2.0.0.10 was released last week. This of course means that everyone should be upgraded to the latest and greatest version by now. It's always extremely important to keep the web browser up to date given it processes an amazing amount of untrusted content.

On the note of Firefox, I ran across this rather interesting study regarding Mozilla security flaws:

http://www.st.cs.uni-sb.de/softevo/vulnerabilities.php

I'm tempted to attempt such an analysis over the Fedora codebase to see how things fare.

Insecurity Blues

Jeremy Allison has writeup regarding his thoughts on the recent Samba security issues.

http://www.tuxdeluxe.org/node/273

His words really do apply to most open source projects today. Security in the open source world does indeed tend to be a well orchestrated mess :)

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

Events and Meetings

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

Contributing Writer: ThomasChung

Fedora Board Meeting Minutes 2007-11-27

Fedora Ambassadors Meeting 2007-MM-DD

  • No Report

Fedora Documentation Steering Committee (Log) 2007-MM-DD

  • No Report

Fedora Engineering Steering Committee Meeting 2007-MM-DD

  • No Report

Fedora Infrastructure Meeting (Log) 2007-11-29

Fedora Localization Meeting 2007-11-29

Fedora Marketing Meeting 2007-MM-DD

  • No Report

Fedora Packaging Committee Meeting 2007-MM-DD

  • No Report

Fedora Quality Assurance Meeting 2007-11-28

Fedora Release Engineering Meeting 2007-MM-DD

  • No Report

Fedora SIG EPEL Meeting Week ??

  • No Report

Fedora SIG KDE Meeting Week 48

Fedora SIG Store Meeting 2007-MM-DD

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