= Fedora Weekly News Issue 105 = Welcome to Fedora Weekly News Issue 105 for the week of October 8th. http://fedoraproject.org/wiki/FWN/Issue105 In Announcements, we have "The Fedora Fonts SIG is open" To join or give us your feedback, please visit http://fedoraproject.org/wiki/NewsProject/Join. 1. Announcements 1. The Fedora Fonts SIG is open 2. Planet Fedora 1. Ontario Linux Fest 3. Marketing 1. Interested in a Fedora Marketing Meeting? 2. Fedora Interview 4 4. Developments 1. Killing Kittens With Yum-updatesd 2. Merging Totem And Totem-xine? 3. SAMBA: The GPLv3 License Dance Begins 4. OpenSceneGraph ExcludeArch Stimulates Koji Notification Level Request 5. NTFS Resize During Install? 6. gethostby* Users 7. GDM User Creation 8. CDs, DVDs Or Netboot Oh My! 9. YUM Update Memory Issues 5. Fonts 1. New Fedora Fonts Initiative 6. Translation 1. Online Translation Tools 2. Release Notes for F8 Final 7. Infrastructure 1. publictest DNS Entries 2. Storage 3. Memory Upgrades 8. Security Week 1. OpenSSL Security Advisory 2. Air Force to get 'cyber sidearms' 9. Advisories and Updates 1. Fedora 7 Security Advisories 2. Fedora Core 6 Security Advisories 10. Events and Meetings 1. Fedora Board Meeting Minutes 2007-MM-DD 2. Fedora Ambassadors Meeting 2007-MM-DD 3. Fedora Documentation Steering Committee 2007-10-14 4. Fedora Engineering Steering Committee Meeting 2007-MM-DD 5. Fedora Extra Packages for Enterprise Linux Meeting 2007-10-10 6. Fedora Infrastructure Meeting (Log) 2007-10-10 7. Fedora Localization Meeting 2007-MM-DD 8. Fedora Marketing Meeting 2007-10-13 9. Fedora Packaging Committee Meeting 2007-MM-DD 10. Fedora Release Engineering Meeting 2007-MM-DD [[Anchor(Announcements)]] == Announcements == In this section, we cover announcements from Fedora Project. https://www.redhat.com/mailman/listinfo/fedora-announce-list Contributing Writer: ThomasChung === The Fedora Fonts SIG is open === NicolasMailhot announces in fedora-announce-list[1], "Last month's consultation showed there was enough possible contributors and needed work to justify creating a Fedora Fonts Special Interest Group. To get the ball rolling I've started seeding a Fonts SIG space in the Fedora wiki[2]." [1] https://www.redhat.com/archives/fedora-announce-list/2007-October/msg00003.html [2] http://fedoraproject.org/wiki/SIGs/Fonts [[Anchor(PlanetFedora)]] == 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 === Ontario Linux Fest === AndrewOverholt points out in his blog[1], "Yesterday was the first Ontario Linux Fest[2] out by the airport. I had met one of the organizers at the Red Hat Summit in 2006 and he contacted me a while ago asking if I'd do a talk on Eclipse. I accepted and after that things really got rolling; we ended up having both Eclipse and Fedora booths in the .org pavillion." [1] http://overholt.ca/wp/?p=88 [2] http://onlinux.ca/ [[Anchor(Marketing)]] == Marketing == In this section, we cover Fedora Marketing Project. http://fedoraproject.org/wiki/Marketing Contributing Writer: ThomasChung === Interested in a Fedora Marketing Meeting? === RahulSundaram reports in fedora-marketing-list[1] "Now that we have some good amount of interest in marketing Fedora, it might be a good time to start those meetings again, plan, schedule and DO important things. I was hoping we could do one coming Oct 13 Saturday whatever time that is preferable to folks and see what pans out. The agenda would be come up with a proper marketing plan ahead of the Fedora 8 release. Let me know who is interested and what time would be appropriate for you." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-October/msg00161.html === Fedora Interview 4 === JonathanRoberts reports in fedora-marketing-list[1], "Over the past few releases, Fedora has gained a reputation amongst the various distributions for having some of the best artwork out there. This time around, responsibility has been handed over entirely to the community Art Team, and they've done themselves proud! Read on to find an interview[2] with MairinDuffy. Fedora Art team lead and previews of some of the key elements belonging to the infinity theme." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-October/msg00131.html [2] http://fedoraproject.org/wiki/Interviews/MairinDuffy [[Anchor(Developments)]] == 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 === Killing Kittens With Yum-updatesd === A short, to the point, email from MikeCohler requested[1] information about how well ''yumupdatesd'' worked and whether it would be in Fedora 8. JamesAntill responded[2] with the information that the Fedora 8 package of the same name was completely different one and should have fixed many problems. He suggested installing it on Fedora 7 machines by using ''yum install yum-updatesd --enablerepo=development''. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00497.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00517.html The point about many improvements was echoed[3] by LukeMacken, who emphasized the improved memory usage. AlecHabig added[4] that the old cron-based method was available as ''yum-cron'' which led JeremyKatz to discuss[5] the performance problems caused by anacron on systems which are not always on. VilleSkyttä was interested in whether ''yum-cron'' was capable of operating in a "download and notify only" mode and it seemed after intervention[6] from SethVidal that this may be possible. [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00514.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00548.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00554.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00994.html Three questions were posed[7] by ArthurPemberton: 1)does ''yum-updatesd'' block ''yum'' and ''pirut''; 2) does the GUI work in KDE; 3) is there a silent download, interactive-install mode? JeremyKatz replied[8] that with regard to the first it was not possible to guarantee correct behavior if multiple transactions occurred simultaneously. Problems with ''yum-updatesd'' being deadlocked due to threading had also been sorted out. The latter two were answered affirmatively. [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00558.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00559.html Arthur clarified[9] that what he had meant was to ask whether it was possible to have Yum work in a read-only mode to check for updates and not block other applications. RichardHughes replied[10] that this was indeed possible with the latest PackageKit, while JeremyKatz explained[11] that with the current tools it was not possible because the repodata is changed in place and it could be made inconsistent. [9] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00563.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00571.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00568.html Adding to Jeremy's response to the three questions JoseMatos confirmed[12] that yum-updatesd worked for him and that ''puplet'' worked fine in KDE. Further discussion with Arthur and LubomirKundrak revealed[13] different levels of tolerance[14] for the mutual blocking that each application establishes. Attempts to suggest alternatives by Lubomir and Arthur[14a] were dissected[15] by SethVidal, with the sticking point always being that the rpmdb needs to be kept in a consistent state, which essentially means blocking anything else from accessing or changing it until transactions are completed. [12] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00612.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00655.html [14] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00662.html [14a] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00669.html [15] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00667.html TimLauridsen could not see the advantage of gaining a few seconds at the expense of consistency, and JefSpaleta suggested[16] a way of killing time (and a kitten) while Yum does its work. [16] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00849.html === Merging Totem And Totem-xine? === A proposal[1] from StewartAdam to allow users of the Totem video player to choose either the GStreamer or Xine backends sought advice on whether to use the alternatives system or to have the two engines conflict. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00476.html A vote was cast[2] in favor of alternatives by HansdeGoede as it would allow the mozilla plugin to switch betweent the two. ToshioKuratomi suggested[3] that one should be picked as the default and a shell-script and environment variables used to choose which should run. BastienNocera also liked[4] this idea and mocked-up a sample script which would allow changing the backend for all applications simultaneously (instead of allowing each application to choose which backend to run). He later mentioned[5] that BillNottingham had suggested that GConf could be used for this purpose. [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00486.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00482.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00520.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00525.html Although Bastien stated that he did not intend users to see the feature at all Stewart wondered whether a simple example[6] dialogue box would be useful. In response to JesseKeating he further expanded[7] the text which would could be presented to the user. This opened up the problem of trying to explain to a hypothetical non-technical user what choices are being presented to them, as pointed out by PeterGordon(who also corrected Stewart on the availability of DVD-menu support with Fedora's Xine) and Bastien[8]. [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00567.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00587.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00724.html === SAMBA: The GPLv3 License Dance Begins === A little while ago the Samba Team announced[1] that all future releases would occur under the (L)GPLv3 license. SimoSorce explained[2] on October 3rd that this would affect versions 3.2.0 onwards and hence Fedora 9, but not Fedora 8. Not much was said about this until six days later when a minor flamefest broke out. [1] http://lists.samba.org/archive/samba-announce/2007/000122.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00126.html The majority of the ensuing discussion covered two topics. The first, raised[3] by VilleSkyttä (and which apparently stimulated the other topic) was that KDE would be seriously affected because ''kdebase'' and ''kdebase4'' were using GPLv2 only. The second was whether this widely pre-signalled[4] move was something which the Samba Team should reconsider because of the negative effect it would have other projects. [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00463.html [4] http://www.linux-watch.com/news/NS7188736246.html It appeared[5] that KDE is affected because of its use of ''libsmbclient'' which is linked[6] with the ''kio_smb'' process as identified by KevinKofler and also that both Nautilus and Konqueror use libsmbclient. VilleSkyttä noted that gnome-vfs uses libsmbclient as a module [7] but the licensing is better (LGPLv2, LGPL+, GPL+). AlexanderLarsson argued[8] that as the smb module runs in a daemon the module's license does not affect other applications linking to gnome-vfs. Further discussion with SimoSorce suggested[9] that the gnome-vfs situation is actually improved vis-a-vis GPLv3 because it details the use of a generic "Standard Interface". BillNottingham was still worried, but HansdeGoede pointed out[10] that the daemon license was LGPLv2 which is GPLv3 compatible. In response to a query from JefSpaleta it was suggested[10a] by SimoSorce that Evolution may also be affected by this problem. [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00508.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00633.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00536.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00613.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00951.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00643.html [10a] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00595.html RexDieter confirmed[11] that because of KDE's use of Qt they needed to wait while Trolltech decided what to do about becoming compatible with GPLv3. He suggested that SMB support would have to be dropped temporarily. DanielBerrange suggested[12] that a compat-libsmbclient could be kept so that KDE3 (which is GPLv2 only), and other potential software, could link against it while GPLv3 compatible software could link against the new, relicensed GPLv3 libsmbclient.so. An alternative is to keep the old GPLv2 libsmbclient.so in a private lib directory inside the KDE package. LaurentRineau begged for the retention of SMB functionality and also thought that not changing the soname could make Daniel's scheme unworkable. However SimoSorce stated[13] very clearly that the soname would not be changing. [11] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00512.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00516.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00539.html ChrisAdams thought that the soname should change for any incompatible change and while JefSpaleta agreed[14] because it would help the Fedora Project contributors to avoid licensing violations. Jef was careful to recognize the right of Samba to choose whatever license they saw fit. BillNottingham and "Dragoran" also seemed to advocate that Samba, as the upstream, should change the soname but SimoSorce[15] disagreed , pointing out that binary compatibility would be broken thus complicating upgrades. Simo laid out what he saw as the likely paths towards resolving the problem and the inutility of changing the soname. [14] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00542.html [15] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00546.html AndrewBartlett suggested that a depsolver examining License tags would help but ToshioKuratomi[16] thought this was a separate issue and restated the problem and its possible solutions, namely: 1) a soname bump; 2) a static library or private directory for a GPLv2 version; 3) a rename of the soname. Andrew responded[17] that the maintenance of a potential compatibility package produced by option #1 was likely to be a problem. He added that it was disturbing that these problems were only being raised at this late stage. RahulSundaram responded[18] that presumably those affected by the licensing had the motivation to maintain the package and admonished Andrew to the effect that Samba did not exist in a vacuum and it would take months to transition for both GNOME and KDE. SimoSorce wasn't impressed with the suggestion that Samba had acted in a cavalier manner[19] and made a strong case for the current problem being due to the conscious choice of GPLv2 only by projects who now are not moving quickly enough to fix the problem. [16] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00585.html [17] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00590.html [18] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00591.html [19] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00594.html Rahul introduced another more optimistic scenario[20] which suggested that some projects are willing to change and just need a bit more time. The introduction of a compatibility package would, he argued, ease their transition period. AndrewBartlett characterized this as "sweeping the issue under the carpet"[21] and suggested that given the long lead-up to this problem any supposedly temporary measure would turn into a long maintenance period instead of "[the issue being] magically resolved later". Rahul wanted to know what was supposed to happen if Andrew were correct and NicolasMailhot argued[22] that because Samba users really, really needed the very latest versions (due to deliberately introduced Microsoft incompatibilities) there was a strong incentive for dependent projects to get their act together. He likened the situation to out-of-tree drivers. ChrisAdams replied[23] to Simo that the MySQL client library provided a precedent for dealing with the problem in the way which Rahul had suggested. [20] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00598.html [21] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00602.html [22] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00620.html [23] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00644.html Frustration was expressed several times throughout the debate with the Samba Team. MatthiasClasen opined[24] "samba just ignores the problems that it causes for its dependencies" and RalfCorsepius extended[25] the discussion to include what he saw as reasons for not choosing GPLv3 and the "fundamentalism"[26] of the FSF. In turn he was asked[27] by SimoSorce not to troll and AlanCox cast doubt[28] on his worries about a German legal interpretation of the "GPLv2 or any later" licenses. NicolasMailhot simply responded[29] several times that any project was free to choose any license for their own work, but when using others' work you had to abide by their license. This point was later conceded by Ralf. [24] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00513.html [25] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00593.html [26] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00599.html [27] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00636.html [28] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00656.html [29] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00622.html The wider problem for the Fedora project was outlined[30] by JefSpaleta, namely that all KDE package maintenance might have to stop in the lead up to Fedora 9. Andrew replied that building the optional libsmbclient parts of the KDE4 packages could just be eschewed and Jeff decided[31] to refer this option to the KDE maintainers. [30] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00604.html [31] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00608.html AndyGreen suggested[32] that perhaps the gstreamer plugins situation provided a model for a way around the impasse. NicuBuculei disagreed[33] pointing out that gstreamer concerned patents, not licenses, and attempting to defer combination of the problematic software to the end-user would result in a willful violation of the GPL. KevinKofler saw[34] a similarity to the distribution of proprietary Nvidia kmods linked against the kernel by third-party repositories. AndyGreen agreed and detailed[35] how it would work, and asserted that it "does not violate any terms or intention of the terms and is nice and clean." This did not appeal to DavidNielsen who explained[36] the possible dangers inherent in not doing the work to keep Fedora in possession of a current samba which tracks upstream closely. [32] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00615.html [33] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00619.html [34] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00871.html [35] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00937.html [36] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00972.html HansdeGoede weighed in[37] to suggest that this was all very reminiscent of the old issues with QT licensing which had led to the need for GNOME He suggested that concerned parties should apply pressure on Trolltech instead of on the Samba Team. OlivierGalibert helped rake over[38] the cooling, but still warm, embers of distant GNOME vs. KDE flamefests and AlanCox responded[39] with a mild defence of the genesis of GNOME. [37] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00631.html [38] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00665.html [39] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00672.html DavidNielsen's thoughtful response[40] to the problem attributed the blame squarly to Trolltech and mentioned several undesirable scenarios ranging from the Fedora Project maintaining a GPLv2-only fork of Samba to KDE users missing out on the latest Samba features. ToshioKuratomi responded[41] that while largely in agreement with the possible solutions he would prefer to see the actual KDE maintainers make any decisions on the topic as they would be the ones responsible for the work. Toshio introduced the amusing extra option of porting kio_smb to gnome-vfs. [40] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00672.html [41] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00993.html === OpenSceneGraph ExcludeArch Stimulates Koji Notification Level Request === An upset ChristopherStone complained[1] that package maintainers dependent on OpenSceneGraph had not been informed by its maintainer (RalfCorsepius) when he used an ExcludeArch: ppc64. Christopher asked whether there was a requirement when using ExcludeArch to file a blocking bug. (See FWN#104[2], FWN#103[3], FWN#90[4] for earlier discussions.) [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00437.html [2] "ExcludeArch Packaging Bug Resolved For 'gnome-python2-extras'" http://fedoraproject.org/wiki/FWN/Issue104#head-3b9b839930664f057d317b6fb9e00aa37e5a7242 [3] "Xulrunner" http://fedoraproject.org/wiki/FWN/Issue103#head-2fff99f986572a5fb6ab8af50ff857abd5e690dc [4] "Fedora Secondary Architectures Proposal" http://fedoraproject.org/wiki/FWN/Issue90#head-271f52b8e5603cd40d00d7c44ec8632cae42b1aa MichaelSchwendt replied with evidence[5] that Ralf had indeed followed the mandated procedure of placing the bug number in the spec file as a comment next to the ExcludeArch line. Ralf wondered[6] what all the fuss was about anyway because OSG had never been supported on Fedora 7 ppc64, and Fedora Core 6 had never had any ppc64 support at all. Chris replied[7] that Ralf should not worry about it and he had merely been surprised when his builds failed. JesseKeating added the correction[8] that there had been a mass rebuild by release engineering for ppc64 and apologized for not communicating this. [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00444.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00462.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00464.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00472.html While admitting[9] that he had missed the notification Christopher reiterated that there should be a better way of doing this. He suggested that there should be some way for a maintainer to email notifications to each package maintainer who BuildRequires their devel package. ToddZulinger replied[10] that there were a very limited number of people with the knowledge of the infrastructure tools (bodhi, koji, etc) and spare time. He suggested[11] that Christopher could add a notification in Koji so that he would be alerted each time a package he depended on was changed. Christopher liked[12] the idea of a checkbox in Bodhi to do this and wondered if it was just a matter of a simple SQL query. ToshiKuratomi replied[13] that the PackageDB does not currently track the information but that Koji might and it was confirmed[14] by JesseKeating that some of the information is in Koji but that it is ambiguous. [9] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00445.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00450.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00453.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00453.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00457.html [14] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00471.html Christopher decided[15] that the current notification system held the most promise and filed[16] an RFE for levels of notification. [15] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00527.html [16] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00653.html === NTFS Resize During Install? === NealBecker reminded[1] the list that the ability to resize NTFS partitions during install would be nice. He wondered if there were any chance this functionality could be included in anaconda. PaulWouters wondered[2] whether there was a patent issue and Tom responded[3] that there was none of which he was aware. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00693.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00695.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00697.html ThorstenLeemhuis asked[4] Tom why the in-kernel NTFS support was still disabled and later supplied evidence[5] that the kmod was downloaded by significant numbers of people from a third-party repository. A slightly tense exchange developed when Tom replied[6] with a list of reasons to prefer using the FUSE-based NTFS-3G including assertions about a lack of maintenance of the NTFS kmod upstream. These allegations were vigorously disputed by Thorsten[7] and ChristopherBrown[8]. It seemed from later links posted that the hiring of one of the original ntfsmount developers by Apple and the subsequent substantial delays of promised code releases are one of the issues. ChristopherBrown posted[9] evidence which he claimed showed that the kmod had superior performance to NTFS-3G, but JefSpaleta challenged this claiming instead that the data was for WinXP's native NTFS performance. [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00701.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00754.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00702.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00707.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00713.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00717.html RahulSundaram said[10] that the third-party repo (the name LIVNA was coyly avoided) should stop providing the kmod because it mislead people into believing that Fedora does not have native NTFS support. Thorsten bridled[11] at the suggestion and satirically suggested removing more choice by dropping KDE. [10] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00753.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00758.html JeremyKatz asked[12] whether Neal was volunteering to help, because while he recognized the value of the idea it was a large task which needed volunteer assistance. He drew attention to the presence of ''gparted'' on the Fedora 7 (and up) LiveCDs which can resize ntfs partitions. Neal declined[13] to volunteer and asked whether there was somewhere useful for ideas to be recorded instead of lost on the list. Rahul responded[14] with links to how to file an RFE and write a feature proposal. [12] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00698.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00728.html [14] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00755.html The primary developer behind NTFS-3G (SzabolcsSzakacsits) responded[15] to ChristopherBrown detailing why it might be fair to call the kernel NTFS driver "old, crufted, and poorly maintained". Szabolcs cited the responsiveness of the FUSE kmod maintainer (MiklosSzeredi of Novell) as one of the reasons why it could be seen as better maintained. Christopher asked[16] for some evidence that enterprises were running the NTFS-3G (e.g. NTFS over FUSE) code and also downplayed an instance of a patch to fix serious corruption which had apparently languished for some time. In closing he argued (similarly to Thorsten) that Fedora should ship both solutions (but with ''mount.ntfs'' renamed to ''mount.ntfs-3g'' to remove confusion). Szaka responded in detail[16] with information on the "partial fork" of libntfs and ntfsmount, now followed by the utilities being forked and suggesting that FUSE is becoming more important. [15] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00789.html [16] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00811.html [17] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00865.html === gethostby* Users === A list of packages which are still using ''gethostby*'' functions instead of ''getaddrinfo'' was posted[1] by UlrichDrepper. His list totted up the number of programs with this problem per package. ''Samba'' came out far in the lead, followed by ''sendmail''. PádraigBrady suggested[2] that Ulrich's own explanation of the problem would be useful reading. In a nutshell the old gethostby* functions are marked as obsolete by POSIX 1003.1-2001 and have problems especially on machines with more than one interface. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00925.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00935.html AndrewBartlett responded[3] for the Samba Team with praise of DavidHolder's work to fix Samba in this regard, but that there were situations where IPv4 had to be used for the CIFS protocol. Ulrich thought[4] that the message still had not penetrated that ''getaddrinfo'' should be used for both IPv4 and IPv6. SimoSorce also answered[5] that Samba-3.2.0 (likely to land in Fedora 9) should be better about this issue. [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00938.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00966.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00943.html An addition to the list was made[6] by DanielBerrange when he noted that as QEMU was there then Xen could be added too. He identified it as a hard problem, but essential and one which he would tackle in order to get QEMU's VNC server fully IPv6 to complete the work on the rest of the stack. [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00955.html RichiPlana seemed[7] eager to help out with making patches to Fedora packages and then submitting them to their upstream maintainers. He worried that the diversity of platforms would mean that messy preprocessor directives would be needed. Ulrich suggested[8] autoconf, and argued that because use of gethostby* functions was so obviously wrong that Fedora should carry these patches until their upstreams inevitably accept them. KevinKofler agreed[9] with Ulrich and pointed out that XP-era ''winsock'' even supports getaddrinfo(). [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00988.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00996.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00997.html Some disagreement was expressed[10] when ChrisAdams disputed that the RFC on Ulrich's livejournal page was relevant and also characterized the situation described there as "contrived". His statement that he had not seen any deprecation or obsoletion of gethostby* functions was responded[11] to very shortly by Ulrich. [10] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00999.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01000.html Deeper queries[12] by SimoSorce concerning the breaking of IPv4 DNS round robin assignment by glibc's getaddrinfo() seemed to reveal[13] a potential problem and led ChrisAdams to wonder[14] whether Ulrich had read RFC 3484 as it was irrelevant IPv4. [12] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01017.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01020.html [14] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01040.html === GDM User Creation === The prolific RichiPlana made another suggestion to improve the Fedora user experience. This time he envisioned[1] the ability to create user accounts at the GDM greeter. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00351.html DouglasMcClendon was keen on the idea and added[2] that it would be nice if the entry of an unknown username would create a new account and later prompt for an administrative password to confirm whether this was allowed. MatthiasClasen posted[3] a link to a prototype for this type of guest account creation. Richi liked the sound of Douglas's suggestions and alluded[4] to what was to become a major stumbling block in the discussion: the assumption that revealing the validity of account names is not a security lapse. [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00353.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00359.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00356.html The security issue was tackled[5] by SimoSorce who added that as GDM could be reached using XDMCP the proposal could expose the existence of valid user names over the network. SteveGrubb agreed and added[6] that it would complicate the construction of a proper audit trail by hiding the real UID of the account creator. MattMiller objected[7] that GDM could behave differently locally or via XDMCP but agreed with Douglas and Steve that the feature should be easy to de-activate due to its undesirability in many security settings. [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00363.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00373.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00374.html LubomirKundrak was unconvinced[8] that leaking username existence was a threat. Although SteveGrubb provided[9] an example of a timing-based attack on PAM thing were complicated when he specified that a tuple of (machinename, username, password) was necessary for a successful account breach. Lubomir clung to the point[10] that the password was the only reasonable secret. AlanCox pointed to Cisco VPN attacks as another example[11] and also separately highlighted[12] how the the search space for the attack increases dramatically when using two items to be guessed. NicolasMailhot[12] and SimoSorce[13] thought that finding usernames via other vectors was usually so easy as to invalidate this point. [8] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00377.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00388.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00392.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00397.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00390.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00391.html === CDs, DVDs Or Netboot Oh My! === The list was asked[1] by MikeMcGrath to choose which of the many possible install methods should be the default in the future. Mike presented the problem from the historical perspective of Fedora 7 introducing install methods (such as the LiveCD) which remove the ability to select packages and upgrade during installation. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00730.html It turned out that this wasn't strictly accurate, or at least was worded a bit confusingly. In an interesting and detailed email JohnPoelstra asked[2] why a system installed from a LiveCD could not be upgraded. He also suggested that boxes without DVD burners and readers would also tend to have poor network connectivity and personally favored a network install from the ''rescuecd'' image. His post brought quite a few reactions. MikeMcGrath explained[3] that the LiveCD install was a copy of an image (that is, there are no rpms installed) and ''anaconda'' differs in how it handles the LiveCD or a normal install. SethVidal corrected[4] that it was perfectly possible to upgrade after this live image was booted. It just was not possible to upgrade from the live image. [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00733.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00739.html This point was brought up again when AlanCox and LubomirKundrak expressed the need for a simple CD set (Alan citing loss of users to Ubuntu over this issue). RahulSundaram in response suggested the LiveCD and was asked about the upgrading issue to which he answered that running ''yum upgrade'' after installation worked for him. Rahul also linked[4] to an interesting "preupgrade" proposal to simplify the live updating of a user's machine. JesseKeating and MikeMcGrath read the question a little differently and pointed out[5] that even with full CD and DVD sets it wasn't always possible to upgrade all packages without network connectivity. [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00804.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00835.html DougWarner expressed an interest in helping out with the upgrade situation, especially for "online" upgrades and MattMiller suggested[6] that the first step would be to hunt through anaconda to collect the "crufty special-case upgrade code" into a "yum-upgradecruft" plugin, which could eventually be shared with anaconda. [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00860.html AlanCox exclaimed "oh god, not this again!" and explained[7] that many laptops came with good network connectivity, the ability to burn/read CDs but without the ability to burn/read DVDs. JohnCiesla built on this to argue[8] that without a DVD drive it appeared that upgrading could only be done via Yum, but that this was not a supported path. This was roundly rebutted by many people anxious to quell this misconception. JesseKeating suggested the use of the rescue and boot isos with network or harddrive caches of the packages. KevinKoffler expanded[9] on this in a particularly good post which explained how to use the harddrive and GRUB to upgrade. RahulSundaram pointed[10] to the Fedora 7 FAQ and PaulFrields also mentioned the installation guide. Elsewhere Paul asked[11] for people to take a look at the Fedora 8 installation guide and to contribute their corrections and additions. [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00767.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00808.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00888.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00847.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00953.html A suggestion[12] from ChrisAdams that the LiveCD package set might fit onto a single CD was dismissed as unlikely by BillNottingham, but DavidZeuthen was more optimistic, and compared[13] the compressed RPM payloads to the compressed LiveCD contents. [12] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00785.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00904.html DouglasMcClendon was very interested in the topic. He had previously done some work[14] on . Douglas provided[15] a link explaining how to use a large USB key for an install in response to BennyAmorsen's request. [14] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00864.html [15] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01029.html The current situation of being able to do package selection after installing the LiveCD was discussed in depth in a longish thread. NicolasMailhot was deeply unimpressed[16] with this option, comparing it unfavorably to Windows' irritating rebooting during installation. LubmoirKundrak wondered[17] what was so wrong with that and noted some anecdoates about SuSE and Caldera having the ability to switch to running the installed system without a reboot. MattMiller agreed[18] that he had done this on Fedora using ''kexec''. [16] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00751.html [17] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00764.html [18] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00861.html === YUM Update Memory Issues === An attempt to update Fedora7-test2 (64 bit) to rawhide by PaulWouters was reported[1] by him as failing due to memory issues. His 1GB RAM had 406MB used for a reasonably standard workload and Yum had completed all the presumably memory-using dependency checks before crashing. Paul wondered what was sucking up the approximately 300MB of RAM. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00872.html PeterArreman tried[2] to help out by suggesting that maybe the problem was due to the ''nv'' driver while running dualhead and provided some handy tips about using xrestop to see X memory hogs. Unfortunately it wasn't this easy as Paul was running a single screen. [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00905.html A thorough diagnosis was provided[3] by JamesAntill who suggested that the problem was due to a lack of swap and originated in possible dead memory due to updated files. James also wondered why Paul considered a memory requirement of 300MB to update nearly 1GB of files was unreasonable. He attached a script to show where and how much dead memory Paul had. [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00875.html JohnReiser explained[4] that the implementation of Yum in Python led to some potential problems with freeing up memory and suggested some ways in which this might be solved. [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00885.html In response to SeanDarcy it was further explained[5] by James that applications needed to be restarted so that old shared libraries left by prelink could be cleaned from memory. This stimulated MattMiller to ask for some figures on the benefits of prelink on modern hardware, to which James outlined[6] some things to think about and suggested that users updating frequently without rebooting the machine were most likely to suffer this memory rot. [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00889.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00920.html CurtisDoty was inspired[7] to add a patch to the script to reveal which processes were responsible for the deleted libs. [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00965.html [[Anchor(Fonts)]] == Fonts == In this section, we cover discussion in Fedora Fonts. https://www.redhat.com/mailman/listinfo/fedora-fonts-list Contributing Writer: MichaelLarabel === New Fedora Fonts Initiative === With the poor but improving state of fonts in Linux, the fedora-fonts-list has been established[1] as a special interest group for Fedora, EPEL, and the OLPC. It will not be strictly fonts, but also text rendering/layouting will be discussed. Among the objectives[2] for this new group is to find the best fonts for internalizational and localization reasons, packaging new fonts and new font tools, FLOSS font evangelism, font creation and design, identifying font or text problems, and choosing the Fedora font defaults. If you are interested, be sure to sign up for the fedora-fonts-list mailing list[3]. [1] https://www.redhat.com/archives/fedora-fonts-list/2007-October/msg00000.html [2] http://fedoraproject.org/wiki/SIGs/Fonts [3] https://www.redhat.com/mailman/listinfo/fedora-fonts-list [[Anchor(Translation)]] == Translation == This section, we cover the news surrounding the Fedora Translation (L10n) Project. http://fedoraproject.org/wiki/L10N Contributing Writer: JasonMatthewTaylor === Online Translation Tools === This week more discussion[1] was had, the group consensus was to try and start using Pootle[2] and work with the Pootle team to extend it as needed. If you are interested in helping with the project feel free to drop them a line. [1] https://www.redhat.com/archives/fedora-trans-list/2007-October/msg00023.html [2] http://www.wordforge.org/drupal/projects/wordforge/tools/pootle === Release Notes for F8 Final === PaulFrields let it be known that the release notes have been completed[1] and are ready for the translators to begin working on them. As with the F7 release any translation 90% complete with be included and the team is also doing a zero-day update so last minute changes can be added. [1] https://www.redhat.com/archives/fedora-trans-list/2007-October/msg00028.html [[Anchor(Infrastructure)]] == Infrastructure == In this section, we cover the Fedora Infrastructure Project. http://fedoraproject.org/wiki/Infrastructure Contributing Writer: JasonMatthewTaylor === publictest DNS Entries === MikeMcGrath sent a note[1] to the list this week mentioning that Jima added DNS entries for publictest(1-9).fedoraproject.org and requested that those with reference to publictest(1-9).fedora.redhat.com begin transitioning to the new DNS. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-October/msg00025.html === Storage === This week saw some discussion[1] about routes to take for additional storage as the Fedora Project has grown and packages among other things are taking additional space. Koji (the buid system) currently uses some netapps for storage via NFS which is fairly expensive, MikeMcGrath was looking for some additional ideas from the community so if you have ideas feel free to voice them. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-October/msg00044.html === Memory Upgrades === MikeMcGrath posted here[1] about memory upgrades to multiple servers this week (14-Oct-07) and listed the effected servers/services among them is releng1. If you use the any of the servers stay tuned for outage information! [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-October/msg00055.html [[Anchor(SecurityWeek)]] == Security Week == In this section, we highlight the security stories from the week in Fedora. Contributing Writer: JoshBressers === OpenSSL Security Advisory === A very scary OpenSSL flaw went public last week: http://www.openssl.org/news/secadv_20071012.txt On the surface this looks like a horrible flaw, which it is. The redeeming factor is that very little uses DTLS in OpenSSL. After an audit of Red Hat Enterprise Linux, we determined that nothing is shipped that actually uses DTLS. === Air Force to get 'cyber sidearms' === http://www.fcw.com/online/news/150483-1.html This is a rather odd idea the US Air Force seems to be planning to use. It seems the idea is that if a user thinks their computer has been compromised, they can somehow alert someone who can verify this. I'm going to guess this isn't going to work. It can probably be suggested that most of the machines in the 50 million computers that are part of the Storm Botnet do not have users that know they're a part of the network. No doubt some portion of Air Force personnel will be able to tell if their computer is hacked, but most probably can't. [[Anchor(AdvisoriesUpdates)]] == Advisories and Updates == In this section, we cover Security Advisories and Package Updates from fedora-package-announce. http://fedoraproject.org/wiki/FSA Contributing Writer: ThomasChung === Fedora 7 Security Advisories === * ruby-1.8.6.110-1.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg00097.html * util-linux-2.13-0.54.1.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg00144.html * wesnoth-1.2.7-1.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg00194.html * hplip-1.7.4a-6.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg00200.html === Fedora Core 6 Security Advisories === * elinks-0.11.3-1.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg00079.html * xen-3.0.3-12.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg00082.html * kernel-2.6.22.9-61.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg00083.html * kdebase-3.5.7-1.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg00084.html * kdelibs-3.5.7-1.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg00085.html * ruby-1.8.5.113-1.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg00087.html [[Anchor(EventsMeetings)]] == Events and Meetings == In this section, we cover event reports and meeting summaries from various projects. Contributing Writer: ThomasChung === Fedora Board Meeting Minutes 2007-MM-DD === * No Report === Fedora Ambassadors Meeting 2007-MM-DD === * No Report === Fedora Documentation Steering Committee 2007-10-14 === * https://www.redhat.com/archives/fedora-docs-list/2007-October/msg00064.html === Fedora Engineering Steering Committee Meeting 2007-MM-DD === * No Report === Fedora Extra Packages for Enterprise Linux Meeting 2007-10-10 === * https://www.redhat.com/archives/epel-devel-list/2007-October/msg00013.html === Fedora Infrastructure Meeting (Log) 2007-10-10 === * https://www.redhat.com/archives/fedora-infrastructure-list/2007-October/msg00042.html === Fedora Localization Meeting 2007-MM-DD === * No Report === Fedora Marketing Meeting 2007-10-13 === * https://www.redhat.com/archives/fedora-marketing-list/2007-October/msg00196.html === Fedora Packaging Committee Meeting 2007-MM-DD === * No Report === Fedora Release Engineering Meeting 2007-MM-DD === * No Report -- 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
