= Fedora Weekly News Issue 89 = Welcome to Fedora Weekly News Issue 89[1] for the week of May 20th through May 26th, 2007. The latest issue can always be found here[2] and RSS Feed can be found here[3]. [1] http://fedoraproject.org/wiki/FWN/Issue89 [2] http://fedoraproject.org/wiki/FWN/LatestIssue [3] http://feeds.feedburner.com/fwn 1. Fedora Weekly News Issue 89 1. Announcements 1. Fedora Project Web gets a face lift 2. Fedora 7 RC2 "Fedora" spin i386 available 2. Planet Fedora 1. Spank that webpage, it's been born again 2. We're golden 3. Marketing 1. Fedora 7 at Respins.org 2. Release Announcement Talking Points 4. Developments 1. Could A Truly Minimal Install Be Added in F7 Or F8? 2. Mdraid and Hidden Partition Area Upgrade Blocker Solved 3. Status Of Support for IWP3945abg Wireless In Fedora 7 4. Fedora7RC2 Torrent 5. Upgrade FC6 To F7t4 Fails On LVM Fstab Naming 6. Guidelines For Huge SPEC Changelogs 7. IPv6 Explicitly Disabled. 8. The Future Of the Bootloader 9. Wireshark Included On F7 Media 10. KDE4 For Fedora8 Draft Document Discussion 5. Maintainers 1. No More New Packages For Fedora 7 6. Documentation 1. Future of The Software Management Guide 2. Language Codes 3. Live CD Guide 7. Infrastructure 1. Image Standard 2. Pushing Updates 3. Static Content 8. Artwork 1. Fedora 7 CD/DVD Labels And Covers 9. Security Week 1. A Mighty Number Falls 2. 28% of software is unpatched 10. Security Advisories and Package Updates 1. Fedora Core 6 Security Advisories and Package Updates 2. Fedora Core 5 Security Advisories and Package Updates 11. Events and Meetings 1. Fedora Ambassadors Meeting Minutes 2007-05-24 2. Fedora Documentation Steering Committee 2007-05-27 3. Fedora Engineering Steering Committee Meeting 2007-05-17 4. Fedora Engineering Steering Committee Meeting 2007-05-24 5. Fedora Packaging Committee Meeting 2007-05-23 6. Fedora Release Engineering Meeting 2007-05-21 12. Feedback == Announcements == In this section, we cover announcements from various projects. === Fedora Project Web gets a face lift === MikeMcGrath announces in fedora-announce-list[1], "The Fedora Project website has gotten a face lift: http://fedoraproject.org/ Prior to today that site went straight to the wiki, which is largely developer content with good (but somewhat hard to find) docs. Now we're expanding on fedoraproject.org and adding some more user-centric content like that found at http://docs.fedoraproject.org/ The websites team has been hard at work at this for a while and we're all excited to release it today. Help get the word out and digg[2]." [1] https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00006.html [2] http://digg.com/linux_unix/Fedora_Project_gets_a_web_face_lift === Fedora 7 RC2 "Fedora" spin i386 available === JesseKeating announces in fedora-devel-list[1], "I've uploaded the i386 DVD and rescue image for the "Fedora" spin of Fedora 7 RC2. You can find it at http://torrent.fedoraproject.org The x86_64 iso set is still uploading, to be followed by the PPC iso set. I'll reply to this once they are ready for torrenting. Happy testing!" [1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01628.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 === Spank that webpage, it's been born again === KarstenWade points out in his blog[1], "Breathing new life into this URL: http://fedoraproject.org In anticipation of heavy server loads during the upcoming Fedora 7 release, we decided to post a series of lightweight, static HTML pages as the front of fedoraproject.org. Those pages quietly went live today." [1] http://iquaid.livejournal.com/18843.html === We're golden === PaulFrields points out in his blog[1], "From the IRC buffer of #fedora-devel, looks like Fedora 7 will be in General Availability on 31 May. To all those who repeatedly tested and fed back bugs and information, a hearty and heartfelt thank you. I'm sure the actual release engineering folks will have more to say about this shortly; stay tuned." [1] http://marilyn.frields.org:8080/~paul/wordpress/?p=785 == Marketing == In this section, we cover Fedora Marketing Project. http://fedoraproject.org/wiki/Marketing === Fedora 7 at Respins.org === KarlieRobinson reports in fedora-marketing-list[1], "On May 12, I went to a Bar``Camp at RIT [2] and Saw a presentation on F7 by Luke Macken. That reminded me of how cool the Re-spin feature on 7 is. My hope is that we can encourage the community to get creative with Fedora by giving them an outlet for their work. To that end, Webpath Technologies has created respins.org[3]." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-May/msg00064.html [2] http://barcamp.org/BarCampRochester2 [3] http://respins.org === Release Announcement Talking Points === KarstenWade reports in fedora-marketing-list[1], "Please help us get these completed[2]: Um ... by tomorrow. Seriously. Or there won't be any time at all for Ambassadors et al to write up their local version[3]. " [1] https://www.redhat.com/archives/fedora-marketing-list/2007-May/msg00061.html [2] http://fedoraproject.org/wiki/Docs/Drafts/ReleaseAnnouncements/TalkingPoints [3] http://fedoraproject.org/wiki/Docs/Drafts/ReleaseAnnouncements#Schedule == 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 === Could A Truly Minimal Install Be Added in F7 Or F8? === An often debated Fedora Project issue has been, which packages should be available bundled in an installable image. Many different reasons have been offered to define what are necessary packages to include, such as size. As a consequence of these protracted discussions over whether there should be "everything" installs or "Windowmaker flavored" installs, Fedora has been made more flexible to allow users to compose their own spins. This progress of customization was demonstrated when "Mark" raised a request[1] for a "minimal" install. FlorianLaRoche suggested[2] using kickstart, while JesseKeating thought[3] that redefining the Core and using Pungi (the Fedora Project's FL/OSS installation-tree/ISO composer [2a]) is the best approach. [1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01393.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01425.html [2a] https://hosted.fedoraproject.org/projects/pungi/wiki/PungiDocs [3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01394.html After Jesse asked that Mark propose suggested changes to the comps groups for installation, Mark noted[4] that he had little programming ability. NicolasMailhot explained that this was not needed and AhmedKamal posted[5] a link to a guide for minimizing CentOS install size to circa 400MB. Nicolas posted[6] a summary of what to do in order to see a minimal-install produced. [4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01400.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01422.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01424.html === Mdraid and Hidden Partition Area Upgrade Blocker Solved === The summary of ReleaseEngineering's IRC meeting was posted by JohnPoelstra[1] and contained three salient issues: 1. The need for testers to be aware of a respin of the initial release candidate (see "Fedora7RC2 Torrent" below); 1. The continuing need for testers of the iwl3945 wireless (see "Status Of Support for IWP3945abg Wireless In Fedora7" below); 1. Upgrade problems with mdraid/dmraid. WillWoods identified the latter as being the most serious, since it affected a large set of committed users whom it would be good to keep. The iwl3945 issue is dealt with in a separate section of this FWN issue. [1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01380.html The new libata drivers caused a problem[2] for JarodWilson as they were able to read the hidden protected area[3] of one of the drives in an mdraid set, which caused a discrepancy between the partition table and what the BIOS reports as the last usable drive sector. The older PATA drivers seemed to pay attention to the information passed by the BIOS. Jarod followed up by removing the affected drive and confirming that without it he could upgrade from an mdraid'ed FC6 to F7. Jarod then investigated passing the module parameter 'libata.ignore_hpa=1' on the boot commandline and reported[4] it did not work and anyone using anaconda to upgrade a similar setup would be out of luck. However, adding "options libata libata.ignore_hpa=1" to /etc/modprobe.conf and then doing a "yum upgrade" should work[5]. [2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01389.html [3] http://www.thinkwiki.org/wiki/Hidden_Protected_Area [4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01572.htm [5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01586.html Following on from a suggestion from BrunoWolff that users might want to look into removing the HPA before upgrading, JarodWilson found a tool called "setmax" that Bruno built with minor problems[5a], but the licensing is unknown. AlanCox cautioned[6] that this might not be a good idea, especially with laptops. Alan also noted[7] that Fedora could benefit from advance testing by Ubuntu in this area, where it seemed reasonably certain that if anaconda could be convinced to ignore HPA, then there would not be problems. [5a] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01690.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01615.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01614.html JeremyKatz saved the day[8] by patching anaconda to recognize and use "libata.ignore_hpa=1" on the commandline and TonyNelson tested[9] this successfully. [8] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01604.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01695.html === Status Of Support for IWP3945abg Wireless In Fedora 7 === A query[1] from DeependraShekhawat about whether users should continue to use the ATrpms repository for drivers for IntelProWireless3945ABG was answered quickly[2] by KevinKofler with the information that Fedora would be shipping iwlwifi patched into the kernel. [1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01515.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01517.html A further query from SteveHill led AndyGreen and JarodWilson to attempt[3][4] to straighten out the terminology. The old version of the driver is named "ipw3945" and uses the "80211" kernel stack. An initial newwer version of the driver using the new "mac80211" kernel wireless stack was initially named "iwlwifi" and then renamed to "iwl3945". The thinking behind this is that iwlwifi is now a project name for a collection of drivers. [3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01521.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01534.html The problem of getting NetworkManager (NM) and IPW3945 hardware to play nice together was mentioned[5] by LamontPeterson. AndyGreen followed up on this, reporting[6] that with a specific kernel (2.6.21-1.3194.fc7) it was possible for NetworkManager to scan and detect networks, but that associating failed intitially with WPA2 requiring a restart of NM, nm-applet, and wpa-supplicant. ToddZullinger reported[7] that he had no problems with NM and the older ipw3945, but no success with the new iwl3945 driver. RalfErtzinger confirmed[8] Todd's happy experiences with the older driver but by contrast was successful with the new iwl3945 except for the issue of the LED lights not working. [5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01551.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01553.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01554.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01588.html Deependra and SteveHill were still having problems with the newer driver. After suggestions that testers should move to the latest kernel (available from Koji[9]) Deependra posted[10] logs of his failure with the latest kernel. JohnLinville tried[11] to help out by sacrificing some chickens, AndyGreen suggested disabling[12] the closed, proprietary hardware scan in order to reduce confusion, but Deependra still had no luck[13]. OlaThoresen reported[14] some progress, but still no working interface. [9] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01538.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01549.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01557.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01563.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01623.html [14] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01569.html In discussion with Deependra over whether iwl3945 ought to be shipped, AndyGreen argued[15] that the old ipw3945 driver wasn't an option because of the licensing of the regulatory daemon being unacceptable to the Fedora Project. Andy offered some other compelling reasons: the iwl3945 driver, although unstable, was working well for many users, and Intel were very actively working with JohnLinville to improve it. Deependra was unhappy with this, prompting DaveHollis to share[16] a workaround that allows both drivers to be present. [15] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01530.html [16] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01540.html === Fedora7RC2 Torrent === JesseKeating posted[1] that the latest and greatest version of F7 available for testing was the "Fedora" spin of F7 Release Candidate 2 (F7RC2), available as a torrent. The i386 version was followed shortly by the x86_64 version and then the PPC version[1a]. Jesse clarified that this would be the final release before GA, as long as nothing really terrible was wrong[2]. [1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01628.html [1a] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01659.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01630.html A worried SteveHill wondered[3] if the 3194 kernel (which fixes a lot of problems for people using IPW3945ABG hardware as reported elsewhere in this FWN issue) would be in F7rc2. JeremyKatz confirmed[4] that it would and the reason it hadn't shown up in rawhide was because it was more recent than that. [3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01639.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01652.html DavidNielsen queried whether the version of anaconda fixed the RAID HPA issues (covered in this version of FWN) and was assured[5] by JeremyKatz that they were (version 11.2.0.65-1). [5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01653.html SeanDarcy and ChelbanVasile appeared[6] to have found an AMD64 kernel bug. Sean further found a problem with the incorrect (older) kernel being selected as default in grub.conf when upgrading from F7t4 to F7rc2. JesseKeating confirmed that this was a known bug and WillWoods added[7] the information that it only appeared to happen with F7t4 and the Red Hat Summit Preview, but should be alright for FC6 upgraders. OttoHaliburton seemed to have contradictory[8] experience. [6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01718.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01717.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01719.html === Upgrade FC6 To F7t4 Fails On LVM Fstab Naming === An upgrade from FC6 to F7t4 failed[1] for SeanDarcy, necessitating the manual removal of LVM partitions from /etc/fstab until after the upgrade. Sean wanted to know[2] why the install insisted on using labels instead of the simpler /dev naming convention. [1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01660.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01666.html ChuckAnderson answered[3] that LABELs were unchanging, as opposed to /dev names. While Sean conceded that LABELs had advantages, he pressed[4] the point that the upgrade should not abort, and Mike agreed that it sounded like an anaconda bug. TillMaas thought[5] that LABELs could still be improved in respect of having unique names. [3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01671.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01679.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01703.html Addressing the immediate practical problem, MikeChambers suggested trying an upgrade to the very newest version of F7 (which was then F7RC2 instead of F7t4) and this worked perfectly[6] for Sean. [6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01713.html === Guidelines For Huge SPEC Changelogs === Some of the RPM packages maintained by the Fedora Project were observed[1] by MichaelSchwendt to have very large %changelog sections in their spec files due to the packages being in maintenance since the 1990s. Michael wasn't making a big deal about it, but was interested to know whether there were plans for dealing with what are sometimes bloated and inaccurate records of changes. NigelJones concurred[2], giving the specific example of anaconda's spec file being 5 times as large as the actual code. [1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01646.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01647.html MamoruTasaka suggested[3] copying vim's approach, which was welcomed by KarstenHopp[4] and others. RalfCorsepius pointed out[5] that this was a move from an inline changelog to a detached, separate one. JesseKeating clarified that this was only for archived changelogs and wondered if Ralf really needed all the history in the package. Ralf disavowed this and suggested manually pruning them as he does for his own packages. Karsten reiterated this point, separately adding the information[6] that F7 has approximately 20MB of changelogs in the spec files, and suggesting a similar approach to Ralf of trimming/editing the changelogs so that appropriate recent changes are easily seen through the same rpm queries as used presently. [3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01648.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01649.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01670.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01705.html "Nodata" wondered[7] why there couldn't be a standard (presumably networked?) place for the changelogs, which "rpm -q --changelog" would silently examine. [7] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01673.html === IPv6 Explicitly Disabled. iwl3495 Negative Interaction With IPv6? === SteveHill observed[1] that IPv6 seemed to be disabled by default in rawhide and wondered why this was so. JesseKeating asked[2] if Steve had enabled IPv6 during install. DavidWoodhouse explained[3] that this was jsut a mixup in the initscripts for F7t4, but that the actual F7 would not suffer from this problem. [1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01577.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01580.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01583.html Diverging slightly from the original thread title, Steve also noted[4] a problem with IPv6 autoconfiguration when the interface required the iwl3945 driver. After examining the bugzilla entry, David suggested[5] using tcpdump to check whether all multicast packets were missing. Steve wasn't convinced and thought that the problem lay in the interface seeing its own packets and assuming that these meant the address was in use[6]. This theory seemed to be bolstered by an observation[7] from JohnDeDourek. [4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01600.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01618.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01637.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01644.html === The Future Of the Bootloader === Our attention was drawn by KenYang[1] to an earlier (2006) discussion[2] about whether or not Fedora could get an animated GRUB, similar to SuSE10.2. Included in this was a link to an interesting exploration[3] of the GRUB code by "TheStarman". The resulting discussion revealed that the current perceived problems with booting include a lengthy video modeswitch (needed to display a graphical boot menu), and a "timeout" that needs to be long enough so that people using ATs (assistive technologies[3a], for example, screenreaders) have time to interact easily with the machine. [1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01429.html [2] http://marc.info/?l=fedora-list&m=115693747626918&w=2 [3] http://mirror.href.com/thestarman/asm/mbr/GRUB.htm [3a] http://developer.gnome.org/projects/gap/presentations/GUAD3C/making-apps-accessible/TOC.html MatejCepl pleaded[4] against using SuSE's specific animated GRUB on the grounds that it was in real-mode and thus broke Xen, and MatthiasClasen reminded us[5] that the DesktopTeam had already made plans to remove the GRUB menu from the startup, but that this depended on a lot of components being changed[6] upstream, including DRM-mode-setting being incorporated into the kernel. [4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01430.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01437.html [6] http://fedoraproject.org/wiki/Releases/FeatureBetterStartup Responding to these plans, both NicolasMailhot[7] and AlanCox corrected one of the listed tasks that suggested setting "timeout 0" in grub.conf to avoid pausing and displaying a splash image in the GRUB menu during boot. Alan explained [8] that drivers or BIOSes could steal a keystroke leading to a need to edit grub.conf with a rescue disk. Another consideration raised[9] by Alan was accessibility (a11y) for people using text-to-speech screen readers. DavidZeuthen and JesseKeating thought that if the bootloader were completely removed[10], it would obviate the need for making it accessible. [7] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01439.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01441.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01497.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01558.html The main case for retaining the bootmenu display seemed to be for users that were dual-booting (especially for non-technical users with dual installs of Linux and Windows). JeremyKatz noted that the GRUB bootmenu hasn't been shown during installation by default since 2004 anyway[11] and DavidZeuthen responded that it would still be a good idea to get rid of the timeout. JasonTibbitts wanted a short, interruptable timeout and drew a parallel to what happens during hibernation, to which JesseKeating responded[10a] that this was partly to prevent data corruption. David referenced[12] the manner in which other OSes, e.g. Mac OSX, require special keypresses to bring up boot menus. NicolasMailhot felt[13] that this behavior was too close to vendor lock-in. AlanCox thought that twenty years of history of hardware manufacturers showed[14] that this was a bad idea as the manuals documenting this inevitably got lost. [10a] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01511.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01560.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01561.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01568.html [14] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01612.html ChristopherAillon spiced things up[15] by sprinkling some crack on the discussion, suggesting modifying anaconda to detect the presence of other OSes and renable the timeout if they were present, or to modify GNOME's reboot dialog to allow booting to another OS. NicolasMailhot reacted to the latter unfavourably because it would mean that to boot Windows, we'd have to first boot Fedora, prompting Christopher to clarify[16] that there could also be DavidZeuthen's secret handshake with an associated problem of non-discoverability. AdamJackson didn't think discoverability was that important, as evidenced by the fact that neither Windows nor MacOSX ship with it. AlanCox thought that this absence was due to a cynical monetary incentive to make interoperability hard[16a]. Christopher dismissed it as a failing that should not be emulated in Fedora, pointing out the dual-booting Windows for games was probably a major use-case[17]. An ensuing discussion between David and NicolasMailhot resulted[18] in competing claims as to whether removing the current defaults and moving the configurability into specialised utilities and/or secret keypresses would distress various user-cases. [15] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01570.html [16] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01578.html [16a] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01613.html [17] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01587.html [18] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01611.html === Wireshark Included On F7 Media === Wireshark[1] is a network protocol analyzer that used to be named "ethereal". SteveDickson wondered[2] why it was not on the F7test4 spin, while the inferior tcpdump was present. Steve suggested that "tshark", a text-mode version should be the default, with tcpdump made optional. [1] http://www.wireshark.org/ [2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01446.html EnricoScholz pointed to the relative smallness of tcpdump, to which Steve replied[3] that this was a consequence of tcpdump having a limited functionality. [3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01467.html A full response[4] from WillWoods explained that Wireshark was actually available from the repositories, just not included in the comps file for the default spin. Will argued that the absence of complaints probably meant that it wasn't as appalling a choice as Steve suggested and while agreeing that the tshark suggestion was worthwhile pointed out that F7 was now in a freeze prior to final release. "SteveG" suggested[5] that the absence of complaints might have been because many testers use the rawhide network updates, not ISO images, and that essential network troubleshooting tools really had to be available on the ISO in case the network was broken. [4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01448.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01457.html Elaborating[6] on the advantages of wirehark over tcpdump, SteveDickson managed to convince[7] JesseKeating (Release Manager) to include Wireshark as part of the f7-desktop manifest. Jesse was at pains to point out that contrary to Steve's assertion, Wireshark had never been a default, but had rather been an optional package in the system-tools group for FC5 and FC6. Although Wireshark is now on the ISO, it will not included on the Live-CD. [6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01464.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01498.html NicolasMailhot and JefSpaleta were stimulated to toss around ideas about how to easily determine a full list of packages installed by default. Jef thought[8] that Pungi seemed like the likely place to obtain this information. [8] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01480.html === KDE4 For Fedora8 Draft Document Discussion === KevinKofler sought discussion[1] of a plan for getting KDE4 into F8. ThorstenLeemhuis thought[2] that getting release schedules for KDE4 and F8 to align properly would be difficult and that a better bet was to maintain two repositories of KDE4, one for rawhide the other for F7. These would be hosted officially within the Fedora Project. [1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01291.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01346.html Kevin and DennisGilmore preferred[3] the idea of trucking ahead with the KDE4 plan but having a fallback to a usable KDE3. Discussion between Kevin and JeremyKatz revealed[4] that there were potential/probable conflicts (due to clashing sonames) in the -devel packages. Jeremy thought there was no way that KDE3 and KDE4 could be installed in parallel if what Kevin reported about upstream KDE were true. Kevin was aware of the suckage and thought[5] about some possible ways around it. [3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01364.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01392.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01397.html Jeremy emphasized[6] that concerned people really needed to make upstream KDE understand that such conflicts were a massive problem. Kevin then proposed[7] creating a new root in which to place the -devel files. NicolasMailhot was strongly against this idea[8] as it broke the FHS and introduced a bad precedent. JeremyKatz thought[9] that the need of ordinary users to build software without mock was sufficiently great that it was worth deviating from standard practice in this case. [6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01402.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01403.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01428.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01443.html FlorianLaRoche was inspired by all the talk of file conflicts to post[10] a list of all those that he could identify in FC-devel for i386. [10] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01427.html == Maintainers == In this section, we cover Fedora Maintainers, the group of people who maintain the software packages in Fedora https://www.redhat.com/mailman/listinfo/fedora-maintainers === No More New Packages For Fedora 7 === With the release of Fedora 7 coming up very shortly, Jesse Keating has sent out a warning that no more "new" packages for F7-final[1] will be accepted. Those that did not get their new packages committed in time must wait for the first round of Fedora 7 updates. The final kernel built for Fedora 7[2] (kernel-2.6.21-1.3194.fc7) is also now available. [1] https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00934.html [2] https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00958.html == Documentation == In this section, we cover the Fedora Documentation Project. http://fedoraproject.org/wiki/DocsProject === Future of The Software Management Guide === There has been some discussion about the future of the Software Management Guide[1], and the possibility of pushing relevant content to the Fedora User Guide and the Administration Guide[2]. This would help to separate material that new users are going to deal with, making the experience less intimidating. [1] http://docs.fedoraproject.org/yum/ [2] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00102.html === Language Codes === The Documentation Project is going to be updating all the current documents to use the en-US language code[1] instead of the ambigous "-en". This removes any existing inconsistencies and makes it possible to produce en-UK and en-AU versions of the documents. These change are being saved for post-Fedora 7 release to prevent any problems arising, and to allow sufficient time to talk with developers[2]. Changes would appear in CVS, the toolchain, and in publication. [1] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00105.html [2] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00125.html === Live CD Guide === After a request for help polishing a document about creating localized spins of the Fedora KDE live CD[1], it was very quickly decided that a canonical guide about creating live CDs using Fedora's new tools is an important short-term goal[2]. The discussion then moved on to talk about creating separate user guides for each of the official spins, with the current Fedora User Guide forming the base for the GNOME live CD guide [3]. [1] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00148.html [2] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00152.html [3] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00158.html == Infrastructure == In this section, we cover the Fedora Infrastructure Project. http://fedoraproject.org/wiki/Infrastructure === Image Standard === There was some discussion[1] this week about which image format to use project wide. There was no conclusion reached as it was decided to forward the matter to the Board for further review. However, the Project Board concluded JPEG no longer seemed encumbered, image decisions aren't their business, and you should use whatever you feel is best[2]. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-May/msg00107.html [2] http://www.redhat.com/archives/fedora-advisory-board/2007-May/msg00138.html === Pushing Updates === With bodhi being pushed into service shortly, BillNottingham started a thread[1] about the mechanics of how updates are/will be pushed. LukeMacken and others are hard at work this week to see the new system implemented[2]. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-May/msg00142.html [2] https://www.redhat.com/archives/fedora-infrastructure-list/2007-May/msg00192.html === Static Content === The project servers have been using puppet to distribute static content among themselves. Due to the amount of files distributed, puppet has produced a higher than comfortable load on the servers. Discussion was had[1] on possible solutions. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-May/msg00170.html == Artwork == In this section, we cover Fedora Artwork Project. http://fedoraproject.org/wiki/Artwork === Fedora 7 CD/DVD Labels And Covers === Máirín Duffy sent her proposals for the CD/DVD labels and covers to the fedora-art-list this week [1]. They were well received [2]. [1] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00030.html [2] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00035.html == Security Week == In this section, we highlight the security stories from the week in Fedora. === A Mighty Number Falls === There was much news last week regarding the factoring of a 307 digit number[1]. Wikipedia has a nice example of what factoring means for the RSA algorithm[2]. [1] http://actualites.epfl.ch/presseinfo-com?id=441 [2] http://en.wikipedia.org/wiki/RSA#Security This event is probably not newsworthy to most people, but it's a huge feat for those in the encryption industry. The researchers took 11 months to factor this number. This seems like a very long time, but when you take Moore's Law into account, this 11 months will be a couple of days in several years. The moral of the story is that data strongly encrypted today, can be broken tomorrow. === 28% of software is unpatched === Secunia published a report stating that 28% of software installed on a user's computer is unpatched[1]. [1] http://www.betanews.com/article/Secunia_28_Percent_of_Software_Unpatched/1179508037 This can be a serious problem when you have to rely on more than one vendor for your updates. The article doesn't specify it, but it seems this survey was conducted on Windows computers. One of the problems that exists in the Windows universe is that every third party vendor has their own (if any) update system. A system such as yum, which supports multiple repositories, GPG signed packages, and a single update mechanism, can be a huge advantage. Ideally for a non-technical desktop user, their update system should automatically update software on a regular basis. This is the behavior seen when a Microsoft Windows user installs Firefox, and it has proven to be rather successful. In the above study, only 5.4% of Firefox users were not running the latest secure version. I suspect few other software projects can boast such numbers. Whether you agree with this method or not, there is no denying it does work. == Security Advisories and Package Updates == In this section, we cover Secuirity Advisories and Package Updates from fedora-package-announce. === Fedora Core 6 Security Advisories and Package Updates === * 2007-05-24 [SECURITY] libpng-1.2.10-9.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-529 * 2007-05-24 bind-9.3.4-5.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-524 * 2007-05-24 nfs-utils-1.0.10-12.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-520 * 2007-05-24 selinux-policy-2.4.6-69.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-508 * 2007-05-21 alsa-utils-1.0.14-0.2.rc1.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-511 * 2007-05-21 cups-1.2.10-7.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-497 * 2007-05-21 hal-cups-utils-0.6.9-1.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-470 * 2007-05-21 jakarta-commons-modeler-1.1-8jpp.2.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-514 * 2007-05-21 minicom-2.2-1.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-490 * 2007-05-21 screen-4.0.3-3.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-515 * 2007-05-21 tomcat5-5.5.23-0jpp.2.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-514-1 * 2007-05-21 xinetd-2.3.14-9.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-512 === Fedora Core 5 Security Advisories and Package Updates === * 2007-05-24 [SECURITY] libpng-1.2.8-3.fc5 - http://fedoraproject.org/wiki/FSA/FC5/FEDORA-2007-528 * 2007-05-24 [SECURITY] php-5.1.6-1.6 - http://fedoraproject.org/wiki/FSA/FC5/FEDORA-2007-526 * 2007-05-21 samba-3.0.24-6.fc5 - http://fedoraproject.org/wiki/FSA/FC5/FEDORA-2007-518 * 2007-05-21 SDL-1.2.9-6.1 - http://fedoraproject.org/wiki/FSA/FC5/FEDORA-2007-517 == Events and Meetings == In this section, we cover event reports and meeting summaries from various projects. === Fedora Ambassadors Meeting Minutes 2007-05-24 === * https://www.redhat.com/archives/fedora-ambassadors-list/2007-May/msg00155.html === Fedora Documentation Steering Committee 2007-05-27 === * https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00165.html === Fedora Engineering Steering Committee Meeting 2007-05-17 === * https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00844.html === Fedora Engineering Steering Committee Meeting 2007-05-24 === * https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00988.html === Fedora Packaging Committee Meeting 2007-05-23 === * https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00926.html === Fedora Release Engineering Meeting 2007-05-21 === * https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01380.html == 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 -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung -- fedora-announce-list mailing list fedora-announce-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-announce-list
