announce October 2007

announce@lists.fedoraproject.org

4 participants
8 discussions

Unofficial FAQ Updated for Fedora 7!
by Max Kanat-Alexander 30 Oct '07

30 Oct '07

I've updated the Unofficial FAQ for Fedora 7! Hooray!! You can see the new version at: http://www.fedorafaq.org/ I'm expecting to be MUCH faster on the update for Fedora 8, which I'm going to start working on in advance, very soon. I've overhauled all of the questions to be up-to-date with Fedora 7. I've also re-worked the yum configuration a neat way, so that every package is available to you from every repository, without any cross-repo conflicts! Let me know if you have any contributions! http://www.fedorafaq.org/contribute/ -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too.

1 0

Fedora Weekly News Issue 107
by Thomas Chung 29 Oct '07

29 Oct '07

= Fedora Weekly News Issue 107 = Welcome to Fedora Weekly News Issue 107 for the week of October 22nd. http://fedoraproject.org/wiki/FWN/Issue107 In PlanetFedora, we have "Fedora 8 - Blocker bugs status", "Fedora 8 ALSA kernel needs Testing", "Scary Haloween with Werewolves", and "Projeto Fedora?" To join or give us your feedback, please visit http://fedoraproject.org/wiki/NewsProject/Join. 1. Announcements 2. Planet Fedora 1. Fedora 8 - Blocker bugs status 2. Fedora 8 ALSA kernel needs Testing 3. Scary Haloween with Werewolves 4. Projeto Fedora? 3. Marketing 1. Fedora, Transifex and upstream L10N 2. Red Hat Magazine | GIMP 2.4 preview 3. Fedora 8 renews tradition of innovations 4. Developments 1. Crypto Consolidation 2. Fedora 8 Blocker Bugs 3. Laptop Harddrive Wear And Tear 4. BIG FAT WARNING: X Breaking In Rawhide 5. Fluendo Codecs Violate SELinux Policies 6. SUIDs Gone Wild 7. ALSA 1.0.15 Update Test Kernels 8. RPM Packages Not Signed? 9. KDE Compiz Switching Snazziness 10. Rules On Packaging Vestigial Libraries 5. Advisory Board 1. Content On start.fedoraproject.org 2. New FUDCon Proposal 6. Translation 1. Release Notes Work (Now and Future) 2. Translation of fedoraproject.org 7. Infrastructure 1. News site CMS 2. Koji Personal Repos 8. Security Week 1. Why are so many browser flaws rated as critical? 2. Virtualization is less secure 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-MM-DD 4. Fedora Engineering Steering Committee Meeting 2007-10-25 5. Fedora Extra Packages for Enterprise Linux Report 2007-10-28 6. Fedora Infrastructure Meeting (Log) 2007-10-25 7. Fedora KDE-SIG Meeting 2007-10-23 8. Fedora Localization Meeting 2007-MM-DD 9. Fedora Marketing Meeting 2007-MM-DD 10. Fedora Packaging Committee Meeting 2007-MM-DD 11. Fedora Release Engineering Meeting 2007-10-22 [[Anchor(Announcements)]] == Announcements == In this section, we cover announcements from Fedora Project. https://www.redhat.com/mailman/listinfo/fedora-announce-list Contributing Writer: ThomasChung No Official Announcement was made for this week. [[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 === Fedora 8 - Blocker bugs status === RahulSundaram points out in his blog[1], "As we get ready for a new release of Fedora, the things we worry about most are the blocker bugs. A couple of QA meetings back, I suggested to Will Woods to post status reports of the blocker bugs every week or alternative week to get some eyes on the important bugs that can block a release and delay it and he has been doing those now and then." [1] http://rahulsundaram.livejournal.com/16263.html === Fedora 8 ALSA kernel needs Testing === WarrenTogami points out in his blog[1], "We are seriously considering using this newer upstream ALSA in F8. But given the tight schedule we need testing to be sure it doesn't horribly break anyone. Reportedly it makes sound behave MUCH better on newer laptops, like ICH8 Intel hardware. Test!" [1] http://wtogami.livejournal.com/19782.html === Scary Haloween with Werewolves === NicuBuculei points out in his blog[1], "I planned to show this cartoon out only next, in time for Halloween, but as it was unveiled already in another place, here is it: halloween." [1] http://nicubunu.blogspot.com/2007/10/scary-haloween-with-werewolves.html === Projeto Fedora? === MikeMcGrath points out in his blog[1], "Thats right, some of our volunteers have been hard at work (ivazquez and ricky in particular). These guys with the help of some others have gotten our new website in a bit better shape." "More translations are on the way, if you're a translator, help translate and proof what's there! We had initially scheduled it for Fedora 9 but the work is done already so F8 it is!" [1] http://mmcgrath.livejournal.com/10595.html [[Anchor(Marketing)]] == Marketing == In this section, we cover Fedora Marketing Project. http://fedoraproject.org/wiki/Marketing Contributing Writer: ThomasChung === Fedora, Transifex and upstream L10N === JonathanRoberts reports in fedora-marketing-list[1], "Free software is used all around the world, and as such it needs to be translated to all kinds of different locales. Fedora has a very active translation community, and they decided it was time that some better tools existed for contributing translations and integrating with upstream. To find out more about this, I talked with DimitrisGlezos, discussing the new Transifex project, what it was like to work on a Google Summer of Code Project, and much more..." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-October/msg00358… === Red Hat Magazine | GIMP 2.4 preview === NicuBuculei reports in fedora-marketing-list[1], "This is a preview of the new GIMP 2.4 which will come with Fedora 8 and is (IMO) important for the general desktop user. Even if it is not a major release feature, I tried to make a tie and talk a bit about F8 too." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-October/msg00335… === Fedora 8 renews tradition of innovations === RahulSundaram reports in fedora-marketing-list[1], "This release makes it obvious that the Fedora community prides itself on innovation. If nothing else, the public documentation of each change on the project wiki should make the perspective clear. If, despite being marked on the wiki as complete, some of these innovations seem flawed or limited, that seems only inevitable -- with so many efforts at finding a new direction, some are bound to fail, or to be less successful than others, especially in their first release. Fedora deserves appreciation for trying. At the introductory stage, that matters more, perhaps, than complete success." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-October/msg00318… [[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 === Crypto Consolidation === (For some bizarre reason we neglected to cover this important issue when it was first announced by SteveGrubb, despite being aware of the thread. Apologies.) BernardoInnocenti suggested[1] that it would be a worthwhile goal to choose one of the multiple implementations of SSL carried by Fedora as a default. In seeking criteria to make this decision Bernardo mentioned that examination of the dependencies of other packages indicated that OpenSSL, NSS and GNU-TLS were equally popular within Fedora and provided a link to a GNU-TLS benchmark which suggested its superiority. PádraigBrady responded[2] with a link to SteveGrubb's post from August 2007 which introduced[3] the Fedora Crypto Consolidation Project. Steve's post indicated that Red Hat had settled on using NSS[4] as it is a certified (FIPS-140-2[5]) library performing all the cryptographic functions within itself, meaning that any applications linking to it which also follow system security policies are de facto certified by FIPS-140-2 also. Steve pointed out that a single toolkit would reduce the maintenance burden and make it easier for applications to gain new cryptographic technologies. He asked for help from maintainers in enabling NSS for their applications and feeding their changes back upstream. The wider impact of centralizing cryptographic services in terms of simplifying user interaction is outlined[0] on the wiki. [0] http://fedoraproject.org/wiki/FedoraCryptoConsolidation [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01681.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01684.html [3] http://www.redhat.com/archives/fedora-devel-list/2007-August/msg01594.html [4] http://www.mozilla.org/projects/security/pki/nss/overview.html [5] http://csrc.nist.gov/groups/STM/cmvp/index.html As Bernardo had compared this effort to the effort made for spellcheckers and had wished as a minimum to make PKI management easier, RichardJones was reminded[6] of his earlier efforts (see FWN#87 "Fedora Standards For Contents Of /etc/pki"[7]) to standardize the contents of ''/etc/pki''. Richard speculated that there were probably many more implementations as he knew of at least one more in OCaml. He recounted that the choice of GNU-TLS for ''libvirt''[8] had been determined due to its clean, well-documented API and also expressed a preference for GNU-TLS's ''certtool'' for certificate management. Richard was skeptical, however, that Bernardo could achieve his goal because "[r]ewriting code to use a different API is a lot of make-work that no one wants to do, and doesn't contribute much benefit to anyone." [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01697.html [7] http://fedoraproject.org/wiki/FWN/Issue87#head-bf4f4916307b150b787075e393de… [8] Libvirt provides a stable interface layer to KVM, QEMU, Xen etc. http://libvirt.org/intro.html There was agreement on the cleanliness of GNU-TLS's API, the ease-of-use of ''certtool'' (both in comparison to OpenSSL) expressed by several developers, including AndrewBartlett[9] (of SAMBA) and DanielBerrange[10]. Daniel also shared Richard's skepticism about the tractability of the problem despite its advantages "Re-writing applications to switch from one impl to another is seriously non-trivial. There is no way in the world you'd want to carry such patches in the Fedora packages because they'd be a huge maintenance time sink whenever a new upstream release came out. So getting any port accepted by the upstream application author has to be the number 1 priority." Dan also introduced the problem of OpenSSL's regular ABI breakage as a likely reason why more packages would choose GNU-TLS over it. [9] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01801.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01704.html SteveGrubb clarified[11] that the aim of the Fedora Crypto Consolidation Project was not, as RichardJones thought, to get everyone to rewrite their code to use a different API immediately but rather to introduce a "--with-nss" option to packages to make a future transition possible. An openssl compatible API has been developed to that end. [11] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01735.html ThomasSteenhold advocated[12] a laissez-faire approach which recognized that projects were free to choose whichever implementation they preferred. He worried that compatibility layers and Fedora-specific patches introduced complexity and bugs, but conceded that perhaps using a preferred implementation when there was choice could be useful. Steve agreed[13] with Thomas that it wasn't the Fedora Project's job to interfere with another project's choice and emphasized that the goal was to add the option of being able to choose to link against NSS as another option. He restated the objectives as "We want to help upstream projects add choice. We want to find out what the rough spots are for NSS and improve its documentation and API so that we can use it everywhere." JeremyKatz still thought[14] that this was going to be tough. [12] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01789.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01851.html [14] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01868.html Some ruffled feathers were in evidence when JohnDennis asked[15] why, if SteveGrubb's avowal of not wanting to decide anyone's preference were true, a "slew" of bugs had been opened by PeterVrabec. John noted that he had seen no consensus that maintenance effort should be spent this way. SethVidal added[16] that many of them were also wrong, such as those opened against YUM instead of Python. JesseKeating consequently wondered[17] if it was proposed to remove python's ability to create sha1sum hashes. SimoSorce responded[18] "[j]ust make it easy to compile with NSS or use your own if NSS is not available." DanielBerrange agreed[19] with Seth that many of the bugs were wrong and asked that before bugs were filed that the application in question should be checked to make sure it is actually using the crypto libraries which were being suggested for replacement. Initially TomasMraz argued[20] that he had done this, but later conceded[21] that there were errors in the process. [15] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01869.html [16] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01874.html [17] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01876.html [18] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02027.html [19] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01883.html [20] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01885.html [21] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01889.html After ThomasMraz responded to JohnDennis reiteration of a request for information as to whether consensus had been sought on spending developer time on this, ChristopherAillon suggested[22] that FESCo should be consider the issue. [22] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01897.html The problem of NSS not providing all desirable algorithms was raised by SimoSorce (SAMBA maintainer) and RobertRelyea responded[23] by asking which were the missing algorithms. He conjectured that MD4 might be one of them, as it was used for Microsoft's NTLM authentication mechanism. He noted that the plan was to provide a library to support NTLM. The SAMBA maintainers weren't overly enthusiastic and AndrewBartlett wondered what was going to be done about ''rsync''. [23] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01912.html The importance of being able to add new cryptographic functions quickly and uniformly was highlighted when AlanCox raised[24] the probability that the SHA-1 family of hash functions would not be of use in the near future and BrunoWolff[25] and others provided information confirming this. Although PaulWouters was skeptical[26] the SHA-2 family would be proof against current attacks on SHA-1 (and also pointed out that IPSec was not affected due to using HMACs) EnricoScholz[27] thought that probably there was a safe ten year buffer gained by transitioning to SHA-2 hashes. [24] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02033.html [25] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02267.html [26] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02355.html [27] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02370.html === Fedora 8 Blocker Bugs === A list of fourteen critical bugs which must be fixed if the release of Fedora 8 is to happen on schedule ("blockers") was posted[1] by WillWoods on October 26th. Will was optimistic that the release would proceed on schedule but highlighted the bugs for which help in testing is requested. The detailed list contains details of the status of the bugs. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02326.html There was very focused feedback to this email with some confirmations[2] of fixes, but also several reports[3][4] that despite huge improvements NetworkManager may still be in need of some changes. [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02337.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02335.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02333.html Will noted that the very latest patches can be obtained from Koji before they hit rawhide and said "Most of those bugs already have fixes pending, and none of the rest are hair-on-fire critical bugs, so I think we're in good shape. If you can help test the stuff I mentioned above, or you have found some huge problem that we've missed, please let us know." === Laptop Harddrive Wear And Tear === PádraigBrady drew attention[1] to a bug entry posted on Ubuntu's "Launchpad" (a proprietary bug-tracking/ERM tool) which saw users reporting that their laptop hard-drives were being subjected to unnecessary load cycles due to an ACPI script. A post[2] on PaulLuon's journal identified the issue as being due to the "load/unload" technology introduced in the mid-1990s in order to reduce the effects of stiction between heads and platters. The side-effect of this attempt to reduce damage is that the load/unload mechanism wears out after three hundred thousand cycles. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02249.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02249.html BillNottingham posted[3] that Fedora took the values set as defaults by the BIOS. On Launchpad MatthewGarrett posted[4] the same information as regards Ubuntu. AlanCox stated[5] that Windows took the same strategy. [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02260.html [4] https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/… [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02329.html Some practical investigations were initiated[6] by WarrenTogami, who suggested power-cycling and then running ''hdparm -I /dev/sda | grep "Advanced power management''. JesseKeating, ThorstenLeemhuis and ChuckEbbert[7] all reported an unhelpful "unknown setting", possibly due to their drives being in AHCI mode. Alan reiterated[8] "[t]he settings we use are those set by the firmware or the preboot environment [and] we don't force them and its not our business to do so as far as I can see." [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02280.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02280.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02308.html === BIG FAT WARNING: X Breaking In Rawhide === A warning[1] from AdamJackson flagged a month of pain post Fedora 8 release due to serious upstream changes to Xorg. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02191.html DarrellPfeifer and RoddClarkson announced[2] that they were happy to test and that this would be made easier if Adam could provide backup/back-out options or hints. [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02224.html DaveAirlie was drawn out by DavidNielsen to explain[3] that the two main projects were to "composite by default" and to provide a smooth graphical boot transitioning from GRUB to GDM login with only a single mode set. [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02223.html RichardHally also suggested[4] that a fall back option of the "old stuff" would be useful for rawhide testers. [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02231.html === Fluendo Codecs Violate SELinux Policies === A request[1] from ValentTurkovic for help in installing the "fluendo codec mega pack" (after he had apparently followed the instructions) saw a simple response[2] from JesseKeating in the form of an email which was blank but for Jesse's customary signature: "Fedora -- All my bits are free, are yours?" [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02067.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02071.html A longer, repetitive thread[3] followed in which Valent avowed that he could not localize the problem to the vendor or to "OSS bits" such as CodecBuddy and Jesse repeating that if the proprietary software did not work then Valent needed to follow up with his vendor. [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02113.html A detailed list of default actions to take was suggested[4] by BastienNocera, including how to check if the codecs are installed ''gst-inspect-0.10 | grep flu'', and where to file a bug with Fluendo. [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02083.html After Valent posted the output of gst-inspect a problem was noticed[5] by FernandoHerrera who suggested that an SELinux adjustment to allow a relocatable shared library would allow the codecs to work. Fernando suggested ''chcon -t texrel_shlib_t /home/fedora8test3l/.gstreamer-0.10/plugins/*.so'' (as an aside DanWalsh's LiveJournal talks[6] about this type of problem and its security implications, borrowing/referencing UlrichDrepper's explanations). [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02186.html [6] http://danwalsh.livejournal.com/2006/05/11/ Upon RahulSundaram's suggestion that Fluendo should fix their code, or that Valent could seek special dispensation from the SELinux team by filing a bug report Valent reported back[7] with Fluendo's response which seems to implicate Intel's "IPP". [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02346.html === SUIDs Gone Wild === The issue of ''suid'' applications needing some oversight or tracking was raised[1] by ThorstenLeemhuis. Discussion centered on the possibility of adding some functionality into rpmlint. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02238.html === ALSA 1.0.15 Update Test Kernels === The possibility of the latest audio drivers in Fedora 8 was dangled[1] in front of @fedora-devel subscribers by ChuckEbbert who was fishing for testers. Those replying were happy with the results. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02204.html === RPM Packages Not Signed? === A perplexed YonasAbraham wondered why his rawhide system was reporting that about sixteen packages were unsigned. WillWoods responded[2] that rawhide packages were never signed, and it turned out that the problem was that Yonas' system had been switched from updating from "development" to "fedora" and "updates". [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02220.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02225.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02226.html === KDE Compiz Switching Snazziness === The problem of being able to switch between the window managers ''kwin'' and ''compiz'' was mooted[1] by SebastianVahl. Sebastian had prepared a switching script which used ''compiz-manager'' and wondered if it could be included in ''compiz-kde'' and ''compiz-manager'' for Fedora 8. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02207.html === Rules On Packaging Vestigial Libraries === A request[1] from HansdeGoede that he be allowed to retire two external library packages and subsume them into the only application which depended on them turned into a substantial thread. The issue seemed to be that the upstream code was using internal versions of these libraries with bugfixes because their upstreams had been dead for years. ToshioKuratomi argued[2] that Hans should only do this once he'd established that upstream for the "Advanced Strategic Command" game (asc) would not take over this responsibility. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01723.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01740.html Hans was a bit irritated to find himself apparently channeling RalfCorsepius when he said "I'm totally fed up with having discussions like this with the bureaucratic powers that control Fedora (woa I feel like I'm Ralf now) either the powers that be give me permission to use SDLmm and paragui as included and maintained within upstream asc release, or I'll just orphan all 3 of them. I refuse to become upstream for 2 libraries backporting fixes from asc each release just because some people want to follow the rules as if they are something holy. Orphaning asc would be a shame as its a great and quite popular game, but if that is want the powers that be want, then that is what they will get." [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01972.html A mild response[4] from Toshio robbed the thread of all its drama, and he pointed out that he was responding to a specific request for comments by providing some alternatives and not forcing anyone to do anything. [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02109.html [[Anchor(AdvisoryBoard)]] == Advisory Board == In this section, we cover discussion in Fedora Advisory Board. https://www.redhat.com/mailman/listinfo/fedora-advisory-board Contributing Writer: MichaelLarabel === Content On start.fedoraproject.org === On the fedora-advisory-board list, JesseKeating asked[1] whether there should be content at the Fedora Project Start page[2]. It turns out that SethVidal is currently working on content for this page along with the fedora-websites-list. More content should be up on this page shortly. [1] https://www.redhat.com/archives/fedora-advisory-board/2007-October/msg00014… [2] http://start.fedoraproject.org/ === New FUDCon Proposal === GregDeKoenigsberg, the Fedora Community Development Manager, and MaxSpevack have laid out the schedule for future FUDCons[1]. The next proposed FUDCon is from January 11 to the 13th at the Red Hat headquarters. After that, there will be another FUDCon in June during the Red Hat Summit. Greg and Max propose that future FUDCons be held during Red Hat Summits (all over the world) and that there will always be a FUDCon in December and June. [1] https://www.redhat.com/archives/fedora-advisory-board/2007-October/msg00016… [[Anchor(Translation)]] == Translation == This section, we cover the news surrounding the Fedora Translation (L10n) Project. http://fedoraproject.org/wiki/L10N Contributing Writer: JasonMatthewTaylor === Release Notes Work (Now and Future) === All the dedicated folks working on the release notes for Fedora 8 will likely have noticed a change in structure in CVS, PaulFrields this week created some new branches.[1] The translators still need to work with the F-8 branch, as a side benefit they can also add their translations to the -devel branch so that the latest translations are available for when the team starts on F9 release notes. [1] https://www.redhat.com/archives/fedora-trans-list/2007-October/msg00075.html === Translation of fedoraproject.org === The websites team this week enabled translating on the static pages of fedoraproject.org. BartCouvreur mentioned in this post[1] some additional thoughts. There is some workflow details to be worked out but for those looking to go to work on the pages, the POT file can be retrieved from here[2]. [1] https://www.redhat.com/archives/fedora-trans-list/2007-October/msg00077.html [2] http://git.fedoraproject.org/?p=hosted/fedora-web.git;a=tree;f=fedoraprojec… [[Anchor(Infrastructure)]] == Infrastructure == In this section, we cover the Fedora Infrastructure Project. http://fedoraproject.org/wiki/Infrastructure Contributing Writer: JasonMatthewTaylor === News site CMS === MikeMcGrath started a thread[1] in regards to a new website and how to best implement it. After much discussion it seems to be still up in the air which combination of software the team will use (php and python based). Anyone that has anything to add feel free to comment! [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-October/msg… === Koji Personal Repos === JesseKeating introduced this piece[1] about adding a personal repository capability to koji for easier experimentation with packages. This is a great idea, there are some infrastructure concerns mainly making sure enough storage space is available but look for this to be implemented in the future, as always comments/suggestions are always welcome. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-October/msg… [[Anchor(SecurityWeek)]] == Security Week == In this section, we highlight the security stories from the week in Fedora. Contributing Writer: JoshBressers === Why are so many browser flaws rated as critical? === To many people on the outside world, it's sometimes non obvious why such a big deal is made about the web browser. The story below highlights that an ad server was broken into and used to distribute malware. * http://www.computerworld.com/action/article.do?command=viewArticleBasic&art… People usually think that if they're at a trusted site, such as their bank, a news site, or even some search engines., they are safe and they can let their guard down. The network of webservers have become very pervasive, and the line between sites continues to blur. As various sites start opening up public APIs, this line will eventually vanish completely. The web seems to be evolving into one giant squishy ball of putty, rather than lots of little ones. This in turn is creating an environment more dangerous for its users, with no clear fix in sight. === Virtualization is less secure === I ran across this posting to an OpenBSD mailing list the other day: * http://kerneltrap.org/OpenBSD/Virtualization_Security Talk of security virtualization reminds me of the old saying about debugging by Brian Kernighan ''Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.'' This is hard problem. I doubt the solution lies in writing golden code. It's more likely that technologies like SELinux are going to be far more effective than expecting everyone to write bug free software. [[Anchor(AdvisoriesUpdates)]] == 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 7 Security Advisories === * seamonkey-1.1.5-1.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg002… * drupal-5.3-1.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg003… * tempest-0-0.4.20070929.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg003… * rss-glx-0.8.1.p-15.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg003… * xscreensaver-5.03-12.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg003… * libpng10-1.0.29-1.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg003… * firefox-2.0.0.8-1.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg003… * libpng-1.2.22-1.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg003… * blam-1.8.3-7.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg003… * epiphany-extensions-2.18.3-4 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg003… === Fedora Core 6 Security Advisories === * None reported [[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-MM-DD === * No Report === Fedora Engineering Steering Committee Meeting 2007-10-25 === * https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02325.html === Fedora Extra Packages for Enterprise Linux Report 2007-10-28 === * https://www.redhat.com/archives/epel-devel-list/2007-October/msg00046.html === Fedora Infrastructure Meeting (Log) 2007-10-25 === * https://www.redhat.com/archives/fedora-infrastructure-list/2007-October/msg… === Fedora KDE-SIG Meeting 2007-10-23 === * https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01936.html === Fedora Localization Meeting 2007-MM-DD === * No Report === Fedora Marketing Meeting 2007-MM-DD === * No Report === Fedora Packaging Committee Meeting 2007-MM-DD === * No Report === Fedora Release Engineering Meeting 2007-10-22 === * https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02049.html -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung

1 0

Fedora Weekly News Issue 106
by Thomas Chung 22 Oct '07

22 Oct '07

= Fedora Weekly News Issue 106 = Welcome to Fedora Weekly News Issue 106 for the week of October 15th. http://fedoraproject.org/wiki/FWN/Issue106 In AskFedora we have "Mobile Phone Internet Dialer" and "Just Thanks." To join or give us your feedback, please visit http://fedoraproject.org/wiki/NewsProject/Join. 1. Announcements 2. Ask Fedora 1. Mobile Phone Internet Dialer 2. "Just" Thanks 3. Planet Fedora 1. What Fedora 8 feature am I excited about today? 2. Codec Buddy in Fedora 8 3. Frozen for Fedora 8. Brace for impact! 4. Marketing 1. Distrowatch on Fedora Artwork 2. Ohio Linux Fest Follow up 3. The Linux Foundation's desktop Linux survey 5. Developments 1. Rawhide Now Friendly To Babies 2. Ensuring SELinux Contexts Track Changed Executable Locations 3. SELinux Wipes Smile Off GDM Facegreeter 4. Proprietary GoogleEarth Craps Out 5. Provides Or Obsoletes? 6. Deploying Noarch Builds To Specific Arches 7. Bootable USB Stick Containing LiveCD ISO (PPC) 8. Opinions Canvassed On Firefox Interaction With Compiz 9. Mock Rebuild Status 10. Two Mass Branches 6. Advisory Board 1. Fedora Board Recap 7. Fonts 1. Developing Open Fonts 8. Translation 1. Release Note Deadline 9. Infrastructure 1. Moin 10. Security Week 1. Firefox Security Update 11. Advisories and Updates 1. Fedora 7 Security Advisories 2. Fedora Core 6 Security Advisories 12. Events and Meetings 1. Fedora Board Meeting Minutes 2007-10-16 2. Fedora Ambassadors Meeting 2007-MM-DD 3. Fedora Documentation Steering Committee 2007-10-12 4. Fedora Engineering Steering Committee Meeting 2007-10-18 5. Fedora Extra Packages for Enterprise Linux Meeting 2007-10-21 6. Fedora Infrastructure Meeting (Log) 2007-10-18 7. Fedora Localization Meeting 2007-10-16 8. Fedora Marketing Meeting 2007-MM-DD 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 No Official Announcement was made for this week. [[Anchor(AskFedora)]] == Ask Fedora == In this section, we answer general questions from Fedora community. Send your questions to askfedora AT fedoraproject.org and Fedora News Team will bring you answers from the Fedora Developers and Contributors to selected number of questions every week as part of our weekly news report. Please indicate if you do not wish your name and/or email address to be published. http://fedoraproject.org/wiki/AskFedora Contributing Writer: RahulSundaram === Mobile Phone Internet Dialer === ''Balaji Kumar <kkc_balaji AT rediffmail.com> : I am C.Balaji, A Fedora user and promoter(chosen by myself to be) for past 3 years. i am in remote area of India. so i can have internet access only through gsm phones gprs modem.the connection provider was from airtel. almost 35 friends of mine were having internet access only with this type of connection but i cant connect to internet without windows through my mobile. i found an application called gprs easy connect for linux which support many phones. I believe without internet linux will be boring. also it must provide every way to connect to internet. so if you add that 6 mb program as default for fedora that would be more interesting so that more than 1000 people in my own town will have access to internet in linux platform. Since I am being a open source promoter i can assure them with most useful tool to connect to the Internet. '' Taking a quick look at this software, it is under the GPL license which is acceptable for Fedora and I have added it to the wishlist[1]. It is however too late for us to evaluating this software and go through the process of integrating and testing it in time for Fedora 8 but we can look into this before the subsequent release. Note that, due to space constraints, only the main software packages is available in the Live images. The rest of the software will be available in the Fedora online software repository. [1] http://fedoraproject.org/wiki/PackageMaintainers/WishList. === "Just" Thanks === ''Don Smith <dmsmith AT tru.eastlink.ca> : I just wanted to say thank you to all the developers that work on Fedora. I recently installed Fedora 7 on my Toshiba laptop that came with Vista pre-installed. I'm NOT a Vista fan. I'm am totally impressed with Fedora 7 and feel it is miles ahead of Vista. Fedora 7 is excellent!. Thanks for the great work folks! '' [[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 === What Fedora 8 feature am I excited about today? === Jesse Keating points out in his blog[1], "Working wireless out of the box. Intel 4965 firmware is in, works well, and NetworkManager rewrite leaves me with some pretty damn good software to manage it." [1] http://jkeating.livejournal.com/46990.html === Codec Buddy in Fedora 8 === RahulSundaram points out in his blog[1] "Codec Buddy (Codeina) is the wrapper in Fedora 8 which helps educate the users on the advantage of open formats or optionally install multimedia codecs when you click on any multimedia content that is not supported by Fedora out of the box. To know more about how codec buddy works and see some screenshots, take a look at the codeina page[2]." [1] http://rahulsundaram.livejournal.com/14852.html [2] http://fedoraproject.org/wiki/Multimedia/Codeina === Frozen for Fedora 8. Brace for impact! === WillWoods points out in his blog[1] "Hoorj. So, yeah, we are definitely frozen for F8. Now comes the time when I spend every day staring at the blocker list and poking the bugs there (and the people responsible for them) and trying to make them die. The bugs, not the people." [1] http://qa-rockstar.livejournal.com/4951.html [[Anchor(Marketing)]] == Marketing == In this section, we cover Fedora Marketing Project. http://fedoraproject.org/wiki/Marketing Contributing Writer: ThomasChung === Distrowatch on Fedora Artwork === RahulSundaram reports in fedora-marketing-list[1] "The Fedora project has been on the forefront of these initiatives, which resulted in some of the most eye-catching desktop art and themes available in any distribution. How do they do it? Learn more in this interview with Fedora art team lead Máirín Duffy" [1] https://www.redhat.com/archives/fedora-marketing-list/2007-October/msg00258… === Ohio Linux Fest Follow up === KarlieRobinson reports in fedora-marketing-list[1], "Sorry it's been so long getting it published. It's been a really crazy couple of weeks around here. Todd's article[2] about the Fest." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-October/msg00252… [2] http://on-disk.com/cms/index.php?wiki=ohio_linux_fest_2007 === The Linux Foundation's desktop Linux survey === RahulSundaram reports in fedora-marketing-list[1], "The survey[2] will take only few minutes of your time, and your feedback is essential in helping us to focus our development efforts and accelerate the global adoption of Linux desktops and clients. For example, past surveys highlighted the need to address printing and wireless issues, so we set up focused workgroups and conferences to help developers and vendors work out common solutions to these requirements." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-October/msg00234… [2] http://www.linux-foundation.org/en/2007ClientSurvey [[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 === Rawhide Now Friendly To Babies === A proposal[0] to change the way in which the release cycle is managed was posted[1] as an RFC by JesseKeating. The intent of the proposal was to shorten the amount of time during which developers are unable to share code due to "freezes" of the always-current development CVS (known as "rawhide"). A freeze is the temporary removal of the ability of contributors to check-in newly built packages. This is necessary to obtain a stable aggregation of packages as a release. The proposal would see the renaming of "Test1 - Test3, Final" as "Alpha, Beta, Release Candidate, Final" with no rawhide freeze for "Alpha". [0] http://fedoraproject.org/wiki/JesseKeating/DevelopmentChangesProposal [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01206.html Substantial early feedback from HansdeGoede and ThorstenLeemhuis welcomed the discussion but challenged many of the assumptions. Hans declared[2] himself in favor of the current model of early mass branching but avoiding adding the extra overhead of contributors having to ask release-engineering to pull specific builds from this branch into the release. [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01210.html Jesse responded to Hans objections from the perspective of development ceasing for a release once the request candidate (RC) is being composed and that from that point development work should be in preparing material for the updates-testing repository for that release, or if there were a compelling reason then release-engineering would upon request move the update from the branch into the RC. Hans thanked Jesse for this explanation but returned[3] to his central objection that maintainers were the people with the expertise (rather than release-engineering) to decide whether their package should enter the RC, or stay in the branch. He also argued that there were only two exit points from Jesse's proposed algorithm: the release branch; or the devel branch. Hans on his part split the decision into three parts: benign simple fixes (release branch); non-disruptive updates (updates-testing); next development cycle. Hans rhetorically wondered "Isn't our new slogan "freedom is a feature", then I say no to a small club making the decisions, thats an autocracy. I say power to the people (power to the maintainers)." [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01237.html Hans' objection to the bottleneck was answered by MikeMcGrath with a request for suggestions of who could make the decision about whether the build would go down any of these paths. Hans argued again for leaving the decision in the hands of the actual maintainer and when NicolasMailhot expressed[4] the opinion that "[the maintainer will always put his package before the distro as a whole" suggested that he might start looking for another community. Nicolas thought[5] that it was just a description of human behavior and pointed to the Linux kernel development model. MikeMcGrath[6] and JefSpaleta[7] also tried to defend the necessity of a single release-engineering team co-ordinating the changes. Jef drew the analogy of writers and editors to attempt to point out that conflicting priorities do not equate to ill-will, malice or disregard. [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01249.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01259.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01260.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01262.html Separately JesseKeating responded[8] that there was evidence that broken trees would result if release-engineering were not there to check that individual maintainers' decisions were sane for the whole tree. Jesse also acknowledged that while there were many excellent maintainers capable of these decisions there were many that only had the time to do a blanket "build for new upstream release". He argued that there were three exit points and added that he would be happy to see more people added to the release-engineering team. [8] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01242.html Hans made a detailed reply[9] in which he argued for the greater trusting of maintainers, with several examples from his own expertise. He suggested that if there automated checks for the disappearance of Provides: for packages and consequent tagging of the package requiring the maintainer to explain the problem or fix it before it can be pushed. Hans also objected to Jesse's use of the phrase "joe random builder". A response[10] from JesseKeating detailed the constraints under which the build process and release-engineering is working, apologized for any offense taken by the phrase, and emphasized that a knowledge of, and facility with, package building did not necessarily translate into appreciating the details of the release process. Jesse agreed that while Hans' hypothetical automated checking was a good idea he simply "lacked the bandwidth" to do anything more than he was doing right now. MikeMcGrath suggested[11] that Hans produce a proposal. [9] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01253.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01256.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01261.html ThorstenLeemhuis was also appreciative[12] of Jesse's effort to address this problem and raised some fresh issues. Thorsten argued for more frequent test releases, while acknowledging the potential impact on mirrors. He also commented that there was a lack of users testing rawhide because of the perception that "rawhide eats babies." Thorsten sketched out a potential release schedule which would lead to more stable rawhide in the five weeks before a release. He also suggested better documentation of ways in which testers can smoothly transition from rawhide to a stable release. While Jesse was doubtful[13] that mirrors would be willing or able to cope with rapid cycling of test releases he agreed that getting test-releases out earlier was necessary, but should be achieved by ensuring that the tree was more stable. A detailed discussion of potential release problems followed. [12] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01235.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01236.html The issue of being able to upgrade was addressed when RahulSundaram pointed to the wiki page about updating from one release to another and Thorsten added[14] information about running the YumShell in rawhide. [14] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01296.html === Ensuring SELinux Contexts Track Changed Executable Locations === On October 13th DanielWalsh posted[1] a heads-up to maintainers to the effect that if the location of an executable had changed then they needed to ensure that the SELinux context was correctly reset. Failure to do this could result in a security vulnerability. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01008.html ArjanvandeVen wished[2] that the build system could notice this sort of thing and send warning emails to which JesseKeating responded[3] with a "patches accepted" link. [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01009.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01010.html A suggestion[4] was made by KarelZak that it would be better to maintain a default SELinux label in a similar manner to file attributes, e.g. ''%attr(4755,root,root) %selinux(foo_t) /bin/foo''. LubomirKundrak agreed[5] that this was "more elegant and maintainable than restorecon in scriptlets". [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01157.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01183.html Skepticism was expressed[6] by TomasMraz about the ability to update file_contexts to prevent loss on the next filesystem relabel and Karel responded[7] with the suggestion of using more policies and using a label database. GianlucaSforna and ChristopherBrown both suggested[8] that having non-experts (w.r.t. SELinux) muck about with contexts in spec files would not scale well and introduced unwanted complexity. [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01184.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01186.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01207.html === SELinux Wipes Smile Off GDM Facegreeter === LouisGarcia asked[1] why GDM[2] did not display a picture when he apparently had followed the correct steps of placing it in the About Me "capplet" and had a ''.face'' file in his ~. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00957.html [2] http://www.gnome.org/projects/gdm/ A first stab at the problem was taken[3] by BastienNocera when he suggested checking the permissions of the ''.face'' and home directory. DavidZeuthen pointed out that this shouldn't be a problem because the master GDM process runs as root and pipes the faces to the GDM greeter, but KostasGeorgiou added[4] a twist when he pointed out that the home could be mounted over the network and that root would thus not necessarily have access. [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01133.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01133.html When Louis added[5] the information that he was seeing an AVC denial ''SELinux is preventing /usr/sbin/gdm-binary (xdm_t) "read" to (home_root_t)'' he was asked by LubomirKundrak whether he was logged-in as root. Lubomir also requested the location of the picture and asked if he had tried to run ''restorecon'' (to reset the security context[6]). [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01136.html [6] See DanielWalsh's excellent article http://www.redhatmagazine.com/2007/08/21/a-step-by-step-guide-to-building-a… Louis clarified that he was not "running as root" and listed the extended attributes of the ''.face'' file. DanielWalsh suspected[7] that the file was not in the usual home directory because it had a context of ''home_root_t'' instead of ''user_home_t''. Further investigation showed that Louis whole home directory needed[8] to have the file contexts restored with ''restorecon -R -v /home''. [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01141.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01159.html === Proprietary GoogleEarth Craps Out === A query was posted[1] by ThomasBaker as to whether anyone had run GoogleEarth successfully on Fedora 8. He observed that it hung randomly without passing the server login. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01148.html Initial suspicion[2] focused on the hardware but LubomirKundrak pointed[3] out that hangs occurred for both ''fglrx'' (ATI's closed-source driver) and Intel's driver. He suggested the alternative explanation of it being a "pile of proprietary crap", a suggestion that was not challenged. BenjaminLewis acknowledged[4] that his own kind provision of an ''strace'' was possibly not of too much use as both ''fglrx'' and ''GoogleEarth'' were proprietary, but noted that the instability seemed to parallel the introduction of the star-viewing features. [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01153.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01156.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01163.html DaveAirlie was torn between blaming ''glibc'' or bits of ''X11'' and asked[5] if anyone could narrow down when it last worked. He then went ahead and pulled in the latest Fedora 7 glibc into a directory on his Fedora 8 box and ran[6] the GoogleEarth binary against this older library with ''LD_LIBRARY_PATH=.:/home/airlied/test/lib /home/airlied/test/lib//ld-2.6.so ./googleearth-bin'', thus confirming that the problem appeared to be in ''glibc''. [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01165.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01167.html A response from JakubJelinek identified[7] a bug in GoogleEarth and also one in ''glibc'' itself. [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01353.html DouglasMcClendon raised[8] the question of who was working on providing an alternative by packaging NASA's ''worldwind'' and also wondering if ''KMarble'' could run on GNOME. KevinKofler answered[9] that it should run if Qt4 was installed but cautioned that "It doesn't have all that fancy 3D stuff though". [8] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01175.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01176.html === Provides Or Obsoletes? === SteveDickson asked[1] for help in using ''Provides:'' and ''Obsoletes:'' in a specfile to resolve file conflicts on a common configuration file. The problem arose in the specific context of renaming ''libgssapi-0.11-2.fc8'' to ''libgssglue-0.1-2.fc8''. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01215.html Because Steve had provided an extract from his specfile and also a cut-and-paste of the error from the command line he quickly received multiple answers helpfully pointing out[2] that his error consisted in trying to install (using ''yum -ihv <packagename>.rpm'') instead of upgrading (using ''yum -Uhv <packagename>.rpm''). DanielBerrange pointed out that the install would attempt to proceed in parallel resulting in a clash on files. [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01217.html Steve confirmed[3] to JosVos that this was indeed the problem. [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01222.html MichaelSchwendt was sharp-eyed enough to notice[4] that the NVR[5] of the package was not sufficient because the presence of a %dist tag would throw out the comparison. LubomirKundrak expressed[6] strong agreement and requested that ''Obsoletes:'' tags should _never_ contain "<=". JosVos suggested[7] that just comparing the Versions and leaving out the Release would be a minimal improvement. In an aside Jos also wondered why ''gaim'' had been obsoleted by ''pidgin'' using ''gaim < 999:1'' instead of simply obsoleting gaim. MichaelSchwendt replied[8] that versioned obsoletes kept the door open for re-introducing a package with the name. [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01226.html [5] http://docs.fedoraproject.org/drafts/rpm-guide-en/ch09s03.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01227.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01230.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01245.html Closing off the thread, SteveDickson thanked[9] everyone for their help and posted his now fixed specfile. [9] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01234.html === Deploying Noarch Builds To Specific Arches === A report of a problem in building a package dependent on IcedTea(an unencumbered hybrid of Sun's OpenJDK[1] and GNU Classpath) was posted[2] by DeepakBhole. Deepak noted[3] that Koji allowed "Noarch" to be chosen and attempted to build the package for x86, x86_64 and also ppc. The problem was that IcedTea itself only exists for x86 and x86_64, resulting a failed build on ppc. [1] http://icedtea.classpath.org/wiki/Main_Page [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01327.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01430.html AndrewHaley's immediate interest was in finding out why the failure was happening, and a short exchange[4] with AnthonyGreen explored whether using ecj[5] would allow the building of IcedTea on ppc, but the conclusion was to simply avoid the problem: "Just don't BuildRequire icedtea and all is good." [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01339.html [5] http://gcc.gnu.org/ml/gcc/2007-01/msg00157.html The recommendation offered[6] by JesseKeating was to use "ExclusiveArch: i386 x86_64" in the spec and to comment this. Deepak objected[7] that this would fail to produce packages for the ppc architecture which could run on it in interpreted mode. AndrewHaley referenced[8] an IRC discussion in which Deepak had explained the problem as a disjunction between Fedora policy (allowing building noarch with IcedTea and shipping all archs) and what the buildsystem allows. He suggested that the policy be adjusted to fit the buildsystem capabilities. [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01332.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01335.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01337.html A slightly separate issue was raised[9] by CaolanMcNamara when he showed that IcedTea generated by default bytecode which was targeted to a later version than 'gij' can handle. AndrewHaley responded[10] that it was essential that all packages built with IcedTea use ''-target 1.5'' and this needed to be Fedora policy. JasonTibbitts asked[11] for someone to write packaging guidelines concerning Java. [9] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01336.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01338.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01363.html The situation was re-assessed by JesseKeating who summed up[12] with the information that it was not possible to build all packages with IcedTea at present. Instead everything could and should be built with 'gcj'. These packages then have the possibility to run using either IcedTea(on selected architectures) or 'gcj'. [12] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01341.html === Bootable USB Stick Containing LiveCD ISO (PPC) === The ability to automagically set up a USB stick (containing the contents of the LiveCD ISO) as a boot device was announced[1] by JarodWilson. He cautioned that it currently only worked on PPC Macintoshes and required some manual repartitioning and specification within Open Firmware. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01382.html RalfErtzinger suggested[2] that hard coding the device name into the script was a bad idea and Jarod agreed[3] and changed this detail. [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01406.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01414.html The script is available[4] for testing and Jarod subsequently reported[5] booting a MacMini successfully with it. [4] http://people.redhat.com/jwilson/misc/livecd-iso-to-disk.ppc [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01416.html === Opinions Canvassed On Firefox Interaction With Compiz === The recent acquisition of improved notifications by Firefox had led[1] JesseKeating to become irritated at the automatic rotation of the compiz desktop to the cube face containing the Firefox window whenever an URL was clicked. Jesse modestly admitted to being "strange at times" and wondered whether other users agreed with him that it would be nicer not to do this. Instead he suggested that a pulsing Firefox icon should appear on each face and only when it was clicked would the face containing Firefox be rotated into view. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01382.html The bug number was requested by ChuckAnderson and supplied[2] by EmmanuelSeyman. [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01482.html Although RalfErtzinger was not using ''compiz'' he had recently noticed[3] behavior which also irritated him: the foregrounding of Firefox whenever he clicked a link in another application. JohnDennis agreed[4] and wanted this behavior off by default. [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01480.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01485.html DavidZeuthen added[5] that when using Metacity workspaces would be ruined by Firefox jumping into them, but noted the existence of a patch and Jesse answered[8] that he had built Metacity with the patch and it would be in Fedora 8. [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01483.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01484.html A further post from KevinKofler wondered what would happen with KWin and RoddClarkson opened[7] a new can of worms by suggesting that behaviors should be consistent across desktop managers. [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01577.html === Mock Rebuild Status === MattDomsch's regular posting of the results of rebuilding Fedora in Mock (for x86_64) contained[1] a list of 199 packages which had failed to build. Matt thanked Spot (TomCallaway) for fixing approximately one hundred and fifty PERL packages. He also pointed out that the version of Mock[2] in which the builds had been done was MichaelBrown's pre-release of version 0.8. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01516.html [2] http://fedoraproject.org/wiki/Projects/Mock PanuMatilainen spotted[3] a fairly simple problem a missing "Requires" which had caused one of his packages to fail and IgnacioVazquezAbrams was puzzled[4] as to why one of his packages which used an "ExclusiveArch: i386" was showing up in the list. [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01520.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01521.html === Two Mass Branches === On Thursday October 18th JesseKeating announced[1] the first mass branch for Fedora 8 (see discussion in this same FWN#106 "Rawhide Now Friendly To Babies".) He stated that CVS commits would be disabled until he announced their re-opening. The next day an announcement of the re-opening of CVS carried[2] the additional information that the operation had stalled due to a failure to request all the branches from PackageDB. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01465.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01471.html Later the same day (Friday 19th) Jesse announced[3] that he was ready for another go and that CVS was again going to be disabled during the procedure. On Saturday 20th Jesse followed up[4] with the information that all was going well, albeit a little slowly. He noted that this was the first trial of using PackageDB completely for branching and that some areas had been identified as likely candidates for speeding things up. Meanwhile Jesse unreasonably snatched a few hours of the weekend to do some housework. [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01515.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01541.html A suggestion[5] was made that the CVS error message[6] during this period should be changed to something a bit more informative. [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01533.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01529.html [[Anchor(AdvisoryBoard)]] == 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 Recap === JohnPoelstra has recapped their recent Fedora Board meeting[1]. Discussed at this meeting were licensing concerns for SPEC files, the Google start page in Fedora 8, and the future of PowerPC support. Red Hat Legal had chimed in on the SPEC file licensing and has stated these files needed to build RPMs should be as open and licensed just like everything else. The SPEC files should be licensed the same as the package itself or in "something extremely permissive". The Google start page is progressing, but no agreement has yet been signed. The PowerPC ISOs for Fedora 8 will be released in the same fashion as previous Fedora releases, but for future releases, the PowerPC support will be dependent upon the Fedora PPC developer community. [1] https://www.redhat.com/archives/fedora-advisory-board/2007-October/msg00001… [[Anchor(Fonts)]] == Fonts == In this section, we cover discussion in Fedora Fonts. https://www.redhat.com/mailman/listinfo/fedora-fonts-list Contributing Writer: MichaelLarabel === Developing Open Fonts === After the creation of the fedora-fonts-list[1], AnneWilson has asked how to start creating a new free font based upon her favorite closed-source font[2]. This question was answered by checking out some resources such as the Open Font Library Wiki[3] and Font Forge Tutorial[4]. [1] https://www.redhat.com/archives/fedora-fonts-list/2007-October/msg00000.html [2] https://www.redhat.com/archives/fedora-fonts-list/2007-October/msg00035.html [3] http://openfontlibrary.org/wiki/Knowledge_Resources [4] http://fontforge.sourceforge.net/editexample.html [[Anchor(Translation)]] == Translation == This section, we cover the news surrounding the Fedora Translation (L10n) Project. http://fedoraproject.org/wiki/L10N Contributing Writer: JasonMatthewTaylor === Release Note Deadline === Well, it's here. The deadline for translation of the Fedora Core 8 release notes is 22-Oct-2007 at 2359. Translations at or greater than 90% complete will be included, there will also be a zero-day build for those that are close but are still working. [1] https://www.redhat.com/archives/fedora-trans-list/2007-October/msg00068.html [[Anchor(Infrastructure)]] == Infrastructure == In this section, we cover the Fedora Infrastructure Project. http://fedoraproject.org/wiki/Infrastructure Contributing Writer: JasonMatthewTaylor === Moin === So after much discussion[1] this week about what to do about Moin (the wiki software) as its performance has been somewhat lacking the infrastructure team came up with a temporary fix. MikeMcGrath and MattDomsch came up with a patch[2] that backgrounds the email notification so the wiki isn't waiting on the email, it just saves and then the email subsystem takes care of its end. While this is a temporary fix (until ToshioKuratomi completes a database backend) it seems to be doing the trick. Thanks guys from all the wiki users! [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-October/msg… [2] https://www.redhat.com/archives/fedora-infrastructure-list/2007-October/msg… [[Anchor(SecurityWeek)]] == Security Week == In this section, we highlight the security stories from the week in Fedora. Contributing Writer: JoshBressers === Firefox Security Update === This week was consumed with the Firefox security update. A security update of Firefox will result in the release of Firefox, Seamonkey, and Thunderbird. This is of course a great deal of work for all the involved parties. Those programs are rather complex and much can go wrong along the way. On the plus side though, we have gotten rather good at dealing with these updates in RHEL and Fedora. All the interesting bits can be found here: * http://www.mozilla.org/projects/security/known-vulnerabilities.html [[Anchor(AdvisoriesUpdates)]] == 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 7 Security Advisories === * tk-8.4.13-6.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg002… * openssl-0.9.8b-15.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg002… === Fedora Core 6 Security Advisories === * openssh-4.3p2-25.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg002… * util-linux-2.13-0.49.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg002… * hplip-1.7.4a-3.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg002… * openssl-0.9.8b-15.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg002… [[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-10-16 === * https://www.redhat.com/archives/fedora-advisory-board/2007-October/msg00002… === Fedora Ambassadors Meeting 2007-MM-DD === * No Report === Fedora Documentation Steering Committee 2007-10-12 === * https://www.redhat.com/archives/fedora-docs-list/2007-October/msg00101.html === Fedora Engineering Steering Committee Meeting 2007-10-18 === * https://www.redhat.com/archives/fedora-devel-list/2007-October/msg01464.html === Fedora Extra Packages for Enterprise Linux Meeting 2007-10-21 === * https://www.redhat.com/archives/epel-devel-list/2007-October/msg00022.html === Fedora Infrastructure Meeting (Log) 2007-10-18 === * https://www.redhat.com/archives/fedora-infrastructure-list/2007-October/msg… === Fedora Localization Meeting 2007-10-16 === * https://www.redhat.com/archives/fedora-trans-list/2007-October/msg00050.html === Fedora Marketing Meeting 2007-MM-DD === * No Report === 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

1 0

Fedora Weekly News Issue 105
by Thomas Chung 15 Oct '07

15 Oct '07

= 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.… [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… === 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… [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-3b9b839930664f057d317b6fb9e… [3] "Xulrunner" http://fedoraproject.org/wiki/FWN/Issue103#head-2fff99f986572a5fb6ab8af50ff… [4] "Fedora Secondary Architectures Proposal" http://fedoraproject.org/wiki/FWN/Issue90#head-271f52b8e5603cd40d00d7c44ec8… 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/msg… === 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/msg… === 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/msg… [[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/msg000… * util-linux-2.13-0.54.1.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg001… * wesnoth-1.2.7-1.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg001… * hplip-1.7.4a-6.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg002… === Fedora Core 6 Security Advisories === * elinks-0.11.3-1.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg000… * xen-3.0.3-12.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg000… * kernel-2.6.22.9-61.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg000… * kdebase-3.5.7-1.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg000… * kdelibs-3.5.7-1.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg000… * ruby-1.8.5.113-1.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg000… [[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/msg… === 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… === 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

1 0

The Fedora Fonts SIG is open
by Nicolas Mailhot 13 Oct '07

13 Oct '07

Dear potential SIG contributor, You're receiving this message because you're subscribed to one of the general relevant Fedora mailing lists, or because our awesome minion-finding powers have detected your interest in fonts and text rendering/layouting in Fedora, EPEL or OLPC¹. 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: http://fedoraproject.org/wiki/SIGs/Fonts Recently, the Fedora infrastructure team created us a mailing list to coordinate SIG activities: https://www.redhat.com/mailman/listinfo/fedora-fonts-list In addition to human posts I intend to get it CCed on every font-related bug in our bugzilla. That means we have enough infrastructure to open shop, and I hereby declare the Fonts SIG born. If you are interested in the Fonts SIG, please: — read the wiki, and the proposed Fonts SIG charter, — subscribe to the mailing list, — let us know there where you want the SIG to evolve — and what *you* are ready to contribute to make this evolution happen (in particular only respond to this message on fedora-fonts-list!) I've created the SIG but we can make it live. It's not a tool to implement my personal vision². It's not some sort of public to-do list either. Stuff will happen because we make it happen. SIG organisation is only there to help implement our wishes; I've sadly no access to magical fairies ready to do the work in our stead. I hope to find many of you on on the Fonts SIG list! Regards, ¹ ie you already maintain or co-maintain a fonts-related package in Fedora (fonts, major text layouting library, font tool…), or made the mistake to ask about fonts on one of the Fedora lists I read ² Visions are for people standing too long under the sun, and there's been a distinct lack of it here recently -- Nicolas Mailhot

1 0

Fedora Weekly News Issue 104
by Thomas Chung 08 Oct '07

08 Oct '07

= Fedora Weekly News Issue 104 = Welcome to Fedora Weekly News Issue 104 for the week of October 1st. http://fedoraproject.org/wiki/FWN/Issue104 In Announcements, we have "Announcing Fedora 8 Test 3 (7.92)!" To join or give us your feedback, please visit http://fedoraproject.org/wiki/NewsProject/Join. 1. Announcements 1. Announcing Fedora 8 Test 3 (7.92)! 2. Ask Fedora 1. How can I be a part of Fedora? 3. Planet Fedora 1. Release Notes freeze 2. Summit Happenings 4. Marketing 1. Fedora 7: A Solid Core Distribution 2. Interview with Fedora's Max Spevack 5. Developments 1. Pungi Error Corrected 2. GPLv2 Obligations To Maintain Sources 3. Co-maintainers Without Sponsorship? 4. Orinoco Driver And Scanning Problems With NetworkManager 5. /etc/hosts Discussion Yields libICE Fix 6. Speeding Up Firefox? 7. Bodhi To Allow "cvsextras" To Push To Testing 8. ExcludeArch Packaging Bug Resolved For 'gnome-python2-extras' 9. Mono Packages Lagging, New Co-maintainer Added 10. Mixing Macros And Native Commands In Specfiles 11. Fedora 8 Test 3 Announced 6. Translation 1. Online Translation 2. Pirut 7. Infrastructure 1. MirrorManager Patch 2. CVSExtras 8. Security Week 1. VM-Based Rootkits Proved Easily Detectable 2. Linux phishing botnet statistics can be deceptive 3. "you security people are insane." 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-07 4. Fedora Engineering Steering Committee Meeting 2007-10-04 5. Fedora Extra Packages for Enterprise Linux Meeting (Log) 2007-MM-DD 6. Fedora Infrastructure Meeting (Log) 2007-10-04 7. Fedora Localization Project Meeting 2007-MM-DD 8. Fedora Packaging Committee Meeting 2007-10-02 9. Fedora Release Engineering Meeting 2007-10-01 [[Anchor(Announcements)]] == Announcements == In this section, we cover announcements from various projects. Contributing Writer: ThomasChung === Announcing Fedora 8 Test 3 (7.92)! === JeremyKatz announces in fedora-announce-list[1], "Fedora 8 Test 3 is here! This is the last test release before the development freeze and a great time to test all those packages that you know and love. Test 3 is for beta users. This is the time when we must have full community participation. Without this participation both hardware and software functionality suffers." [1] https://www.redhat.com/archives/fedora-announce-list/2007-October/msg00001.… [[Anchor(AskFedora)]] == Ask Fedora == In this section, we answer general questions from Fedora community. Send your questions to askfedora AT fedoraproject.org and Fedora News Team will bring you answers from the Fedora Developers and Contributors to selected number of questions every week as part of our weekly news report. Please indicate if you do not wish your name and/or email address to be published. http://fedoraproject.org/wiki/AskFedora Contributing Writer: RahulSundaram === How can I be a part of Fedora? === ''Mark McLaughlin: How can I be a part of the Fedora project and be able to cast a vote for the codename for the next Fedora Releases? I want to contribute with ideas and distribute Live CDs in New England USA '' You can be part of Fedora by joining one of the sub projects available at http://fedoraproject.org/join-fedora.html. Any Fedora contributor would be able to vote for a codename for the upcoming releases of Fedora. Ideas are worth it's weight in gold but the key factor in realizing those ideas in many instances is to step up and do the work involved. With Free software, you don't have to be contend with merely being a consumer and you have the nice opportunity to go beyond it and drive the changes you desire. Go for it. If you are interested in distributing media freely to more end users, join the Free Media project at http://fedoraproject.org/wiki/Distribution/FreeMedia where hundreds of copies of Fedora is being distributed every month all over the world by volunteers in the Fedora community. Give everyone you can, the gift of Fedora! [[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 === Release Notes freeze === PaulFrields points out in his blog[1], "Tomorrow night at 2359 UTC the wiki beats, where we collect the release notes for F8, will be "frozen" for the final release. From there, we produce DocBook XML sources which go to the L10N folks for translation for the F8 general release." [1] http://marilyn.frields.org:8080/~paul/wordpress/?p=852 === Summit Happenings === ColinWalters points out in his blog[1], "Online Desktop - Owen, Bryan, Marina and I gave a talk on the Online Desktop effort that went pretty well, lots of stuff was demoed and there were some good questions." "Summit[2] General - So far it's fun, a lot of people hacking on things here. Gave a short talk about the current state of Hotwire which went well. I think there's a lot of interest but probably most people are waiting for bugs to be fixed; if you've tried it and found some, please file them! [1] http://cgwalters.livejournal.com/8194.html [2] http://live.gnome.org/Boston2007 [[Anchor(Marketing)]] == Marketing == In this section, we cover Fedora Marketing Project. http://fedoraproject.org/wiki/Marketing Contributing Writer: ThomasChung === Fedora 7: A Solid Core Distribution === RahulSundaram reports in fedora-marketing-list[1], "Overall, Fedora is a good distribution to consider both for an easy-to-use desktop and for a basic home or small-office server. The user interface and security features are first-class, and the rest of the environment is straightforward, particularly if you are used to Red Hat. When deciding between Linux distributions to try out, Fedora should certainly be on the list." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-October/msg00020… === Interview with Fedora's Max Spevack === RahulSundaram reports in fedora-marketing-list[1], "Fedora is a distribution that we try to release twice a year, and we try to always focus on the things that are important to the larger Fedora community, while at the same time allowing Fedora to be a place where things that Red Hat engineering groups are working on can also make their way into the distribution." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-October/msg00120… [[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 === Pungi Error Corrected === The continued activity of the Alphacore[1] project was revealed when OliverFalk asked[2] for some Python gurus to help him in creating non-DVD ISOs using Pungi. Oliver provided a patch to the ConfigParser.py module to allow it to accept either ints or strings. He wondered whether no one else was generating non-DVD ISOs. [1] Alphacore are a volunteer port of Fedora to the AlphaServer architecture and have integrated their work as a Secondary Architecture for Fedora 8. [http://alphacore.info/archives/13-No-News-Is-....html http://alphacore.info/archives/13-No-News-Is-....html] [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00060.html JesseKeating responded[3] that this code path had been left out of the validation tests and that Oliver's diagnosis of a Pungi bug in ConfigParser was correct. A patched version was produced. [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00066.html Oliver was impressed[4] with Jesse's usual quick response and explained that he would be testing out this code path fairly regularly because Alphas tend not to have DVD-ROMs. [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00067.html Further discussion focused[5] on why ConfigParser only accepted strings. Jesse speculated that it was because it would be hard to mark an element of a plaintext file as an integer rather than a string. [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00069.html A related, but distinct question asked[6] by Oliver was why Koji did not create an sqlite database with ''createrepo -d''. Oliver noted that for slower architectures there would be a speeding up of the init phase of the build-root. It turned out that the reason was that Koji had been developed on machines which lacked the ability to run "createrepo -d" and Oliver kindly provided[7] a patch for when they became capable. [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00159.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00200.html MikeBonnet added[8] the information that the ''createrepo'' in ''koji'' used the ''-update'' flag to parse pre-existing repodata resulting in a huge speed boost. Mike wondered whether ''--update'' would work with an sqlite database. Oliver responded[9] that it did not, but explained the speed trade offs faced in his situation and promised to post a request for the sqlite support with ''--update'' in the right place. [8] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00211.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00218.html TimLauridsen and SethVidal weighed in[10] on the problem of using ConfigParser by suggesting that a look at ''config.py'' (written by MennoSmits and de-yummified by Seth) might be useful. [10] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00112.html === GPLv2 Obligations To Maintain Sources === An interesting question was raised[1] by MattDomsch about how the Fedora Project could help derivative spins to meet their obligation under the GPLv2 to make source-code available. There are several methods mentioned in GPLv2 by which this can be achieved depending upon the distribution method used for the object-code/binaries. Matt wanted to make sure that the producers of a spin would be able to rely upon the Fedora Project to maintain sources under provision 3(b) and suggested that JefSpaleta's method for generating specific versioned SRPMS from CVS on demand would be useful. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00307.html One of the obligations attendant upon using provision 3(b) is to make the source available for three years. NicolasMailhot thought that the easiest thing would be to never purge the SRPMS generated by Koji. While Jef agreed[2] that if this were possible it would make things simple he doubted that it was possible. MattDomsch agreed and estimated[3] that keeping four, or more, years of source-code in an SCCM[4] would take less space than the equivalent Koji archive for the same time period. JesseKeating shared[3] Matt's concerns and added that it was uncertain as to when the three year period started. [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00310.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00316.html [4] Source Code Configuration Management: http://en.wikipedia.org/wiki/List_of_revision_control_software AlexanderBoström suggested[5] that ensuring that the Fedora Project's written promise which is passed on under 3(b) to re-spinners (who in turn distribute under 3(c)) had a specific time-limitation written in could solve the problem. Such a method ensures that the re-spinners are responsible for providing source if they continue distributing the software past the time at which the Fedora Project stops distributing it. SimoSorce[6] made largely similar points to Alexander, echoing the idea that it would be easier to provide binary and source CDs when distributing them at events, with a smaller number of source CDs being needed to be produced. JesseKeating responded[7] to MattMiller that this would not achieve the goal of helping the re-spinners. [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00328.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00345.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00337.html === Co-maintainers Without Sponsorship? === A request for comments from ToshioKuratomi(abadger) floated[1] a method for enabling upstream maintainers who to co-operate in a non-onerous way with the Fedora Project without getting a sponsor. Toshio outlined how pairing of a FedoraProject package owner with an outside upstream maintainer could proceed through three phases. The initial phases would require the sponsor to police the actions of the upstream co-maintainer. In later phases sponsors would not be required, but this requires changes to the PackageDB, Bodhi and Koji and the CVS repository. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00306.html Jima wanted[2] to enable the upstream co-maintainers to start scratch builds, but recognized that Koji administrators would be affected and sought feedback from them. [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00314.html === Orinoco Driver And Scanning Problems With NetworkManager === A continuation of last week's[1] thread about all the changes in NetworkManager delved into some scanning problems experienced by MattMiller. Initial speculation[2] from DanWilliams that Matt's driver was based on mac80211 was followed up with some extensive debugging help. Dan concluded[3] that it looked as though there were some problems both with the ''orinoco'' driver and also with ''wpa_supplicant'' itself. [1] http://fedoraproject.org/wiki/FWN/Issue103#head-55328f04f90bf89fe031f8996a3… [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00019.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00065.html Matt confirmed[4] that back-to-back ''iwlist ethX scan'' commands produced ''resource temporarily unavailable'' messages and the need to reboot! [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00068.html The essential problem seemed to be[] that the driver incorrectly refused to return older scan results while currently scanning. Matt filed[5] a bug report and Dan estimated[6] that a few days to copy similar improvements from the ''airo'' driver would hopefully see this problem resolved. [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00171.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00163.html === /etc/hosts Discussion Yields libICE Fix === Another thread from last week(FWN#103 "System Entries In /etc/hosts"[1]) which yielded more fruit concerned the setting of hostnames by NetworkManager. BillCrawford had noticed that when running X from a console login the desktop could crash if the hostname was changed. AdamJackson(ajax) did not think[2] that the problem was a simple mismatch between the magic cookies stored in ''.Xauthority'' for the client and the server. [1] http://fedoraproject.org/wiki/FWN/Issue103#head-fc00b9d8ef6c1ab2beb7d7d28e7… [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00013.html Bill reported[3] a specific error logged when he tried to switch VTs. This stimulated[4] Adam to patch libICE so that the path to the ICE[5] socket (which is bound at session start up) uses "unix" as the hostname part of the tuple instead of relying on ''gethostbyname()''. The advantage of this is that although ''dhclient'' changes the system hostname, ''NetworkManager'' will not. Adam recommended that anyone experiencing delays, stalls or crashes of applications after or during changing network information should try to update libICE and reproduce the problem. He provided updated packages for Fedora 7[6] as well as rawhide. [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00017.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00034.html [5] http://en.wikipedia.org/wiki/X_Window_System_protocols_and_architecture#Int… [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00074.html === Speeding Up Firefox? === ArthurPemberton was dissatisfied[1] with the speed of Firefox on Fedora 7 and noted that changing the default Firefox ''network.dns.disableIPv6 false'' to ''true'' and some other changes seemed to result in an improvement. JeroenVanMeeuwen(kanarip) said[2] that such changes to the defaults should only be made if upstream approved. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00141.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00149.html The reasons for why the defaults should stay as they are were detailed by the knowledgeable ChristopherAillon (who had blogged on this topic several years ago). Christopher specifically noted[3] that pipelining would break (in the sense of causing browser hangs and refusing to load) for websites served by unpatched Apache-1.3. In response to DennisJacobfeuerborn's request for some numbers, Ajax posted links to a blog entry[4] and a bugzilla[5]. [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00153.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00201.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00203.html ChuckAnderson addressed the IPv6 point by providing[6] contradictory testimony which showed that slowdowns might not be due to it. [6] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00158.html Some more anecdotal experience came[7] from DarrellPfeifer who thought that the problem was due to ''auto detect proxy settings'' instead of ''direct connection to internet''. NicolasMailhot agreed[8] that there was a problem which needed to be reported upstream, and in response to a useful suggestion from MattMiller explained[9] that the whole UI could freeze while one tab blocked on content. BernardoInnocenti had some potential Javascript culprits in mind[10]. [7] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00166.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00187.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00204.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00188.html === Bodhi To Allow "cvsextras" To Push To Testing === An attempt by ToddZullinger to push an updated ''vorbis-tools'' package to testing to fix a bug failed[1] due to the restrictions on members of ''cvsextras''. Todd laid out the case for easing the burden on primary maintainers by getting pkgdb to allow members of cvsextras to undertake such tasks. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00293.html LukeMacken responded[2] that ''bodhi'' currently authenticates only those with commit access in pkgdb, but thought that it should also check the group ACL. He noted that Toshio was trying to patch bodhi to do this right now (see also this same FWN#104 "Unsponsored Co-maintainers"). [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00297.html Toshio produced a patch and Luke applied[3] it, and a short delay[4] intervened until the production bodhi was patched after some minor[4a] adjustments. Unfortunately it seemed that Todd was still being denied[5]. [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00324.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00335.html [4a] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00342.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00350.html === ExcludeArch Packaging Bug Resolved For 'gnome-python2-extras' === A query[1] from MichałBentkowski about the absence of a PPC64 build of ''gnome-python2-libegg'' causing ''sonata'' to fail to build revealed that ''gnome-python2-extras'' was using an ''ExcludeArch: ppc64''. PaulFrields reported[2] a related error. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00279.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00282.html JeremyKatz responded[3] that the problem was in ''gnome-python2-extras'', specifically that it should use ''ifarch'' for the gdl subpackage and not ''ExcludeArch'' (see last paragraph of FWN#103 "Xulrunner"[4] and links therein to earlier discussions on this topic). [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00284.html [4] http://fedoraproject.org/wiki/FWN/Issue103#head-2fff99f986572a5fb6ab8af50ff… The issue was quickly resolved[5] by a fix from MatthewBarnes. [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00300.html === Mono Packages Lagging, New Co-maintainer Added === An observation[1] that ''mono'' packages in rawhide were lagging behind the actual releases was posted by "Paul". Apparently this was affecting his work and he volunteered to co-maintain the packages if that would help. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00261.html AlexanderLarsson was happy[2] to have an offer of more help and after some trials and tribulations with adding the new co-maintainer Paul was approved and added[3]. [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00272.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00276.html === Mixing Macros And Native Commands In Specfiles === PeterLemenkov wanted to know[1] whether it was possible to mix rpm macros and native commands in specfiles. Peter provided an example to demonstrate his meaning. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00252.html HansdeGoede replied[2] that the RPM would certainly build, but that the Fedora Project guidelines would disallow this in favor of using either macros exclusively or native commands. MatthiasClasen disagreed, arguing[3] instead that the guidelines only distinguish between two types of macro styles, but are silent on the issue of native commands versus macros. [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00254.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00289.html RahulSundaram provided[4] a link to the specific place where this is discussed in the wiki. [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00270.html JesseKeating attempted[5] to disambiguate Peter's example, noting that it lacked clarity due to mixing two macro styles and native commands. [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00269.html === Fedora 8 Test 3 Announced === The final test release prior to development freeze was announced[1] by JeremyKatz on October 4th. The extensive notes ask for full community participation in testing and detail some known issues. [1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00205.html Initial response involved some dismay[2] at the replacement of ''pam_console'' for desktop access control with HAL, and concern that the KDE-LiveCD was only available by torrent. JesseKeating responded[3] to the latter issue, explaining that this was just for the test release and that the live images would be back to normal for the actual final release. [2] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00208.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00229.html Separately WarrenTogami[4] noted apparently untested breakage of the iwl3945 wireless chipsets in kernels and asked for help testing kernels before they hit the nightly build. DaveJones added[5] that it was possible to install the latest builds directly from his repo using "sudo bash; cd /etc/yum.repos.d; wget http://people.redhat.com/davej/kernels/Fedora/f7.92/kernel.repo" within one hour of koji building them. [4] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00249.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00303.html [[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 === There was more discussion[1] this week about the possibility of setting up an online translation tool. The team has been hashing out some details about how commits would happen and how to scale access. We will definately be keeping tabs on this discussion as it would be a definate help to the team and project as a whole. [1] https://www.redhat.com/archives/fedora-trans-list/2007-October/msg00003.html === Pirut === Pirut[1] was moved this week to git.fedoraproject.org, JeremyKatz[2] mentioned that any pirut translation commits need to go through transifex. No problems were reported after the change. [1] http://fedoraproject.org/wiki/pirut [2] https://www.redhat.com/archives/fedora-trans-list/2007-October/msg00011.html [[Anchor(Infrastructure)]] == Infrastructure == In this section, we cover the Fedora Infrastructure Project. http://fedoraproject.org/wiki/Infrastructure Contributing Writer: JasonMatthewTaylor === MirrorManager Patch === WarrenTogami and LukeMacken worked on a validator patch[1] for mirror manager[2] so that it would work properly with the new turbogears. It was apparently a trivial patch so users should see no changes other than mirror manager now working flawlessly. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-October/msg… [2] http://fedoraproject.org/wiki/Infrastructure/MirrorManager === CVSExtras === There was some discussion[1] this week about renaming cvsextras to packager. The change will likely happen, though it has not been decided when. The idea behind the change is that it will be clearer what tree is for and when CVS is no longer the tracking mechanism the name is generic enough so no changes will likely need ot be made. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-October/msg… [[Anchor(SecurityWeek)]] == Security Week == In this section, we highlight the security stories from the week in Fedora. Contributing Writer: JoshBressers === VM-Based Rootkits Proved Easily Detectable === http://it.slashdot.org/article.pl?sid=07/10/02/0323237&from=rss Some time ago it a number of researchers claimed that it would be possible for a virtual machine based rootkit to evade security software. It seems that's not quite the case. === Linux phishing botnet statistics can be deceptive === http://blogs.techrepublic.com.com/security/?p=296" eBay's chief information security officer made a comment last week that most botnets are hosted off of compromised Linux machines. The above article refutes some of these claims. === "you security people are insane." === http://kerneltrap.org/Linux/Pluggable_Security Linus makes some interesting points about various security systems in the Linux kernel. While his colorful comments are humorous, this makes a rather powerful statement. Linus says: {{{ Schedulers can be objectively tested. There's this thing called "performance", that can generally be quantified on a load basis. Yes, you can have crazy ideas in both schedulers and security. Yes, you can simplify both for a particular load. Yes, you can make mistakes in both. But the *discussion* on security seems to never get down to real numbers. So the difference between them is simple: one is "hard science". The other one is "people wanking around with their opinions". }}} This is a big problem. Security is hard to understand, so you end up with two different types of people causing trouble. There are people who don't really understand what they're doing. These are the people that say incorrect things and just make up what they don't know. There are also the people who will blatantly lie to further their own agenda. The hope is that the right solution will eventually win out, but that's not always the case. [[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 === * kdebase-3.5.7-13.1.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg000… * xen-3.1.0-6.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg000… * pidgin-2.2.1-1.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg000… * openoffice.org-2.2.1-18.2.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-October/msg000… === Fedora Core 6 Security Advisories === * None reported [[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-07 === * https://www.redhat.com/archives/fedora-docs-list/2007-October/msg00035.html === Fedora Engineering Steering Committee Meeting 2007-10-04 === * https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00239.html === Fedora Extra Packages for Enterprise Linux Meeting (Log) 2007-MM-DD === * No Report === Fedora Infrastructure Meeting (Log) 2007-10-04 === * https://www.redhat.com/archives/fedora-infrastructure-list/2007-October/msg… === Fedora Localization Project Meeting 2007-MM-DD === * No Report === Fedora Packaging Committee Meeting 2007-10-02 === * https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00081.html === Fedora Release Engineering Meeting 2007-10-01 === * https://www.redhat.com/archives/fedora-devel-list/2007-October/msg00170.html -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung

1 0

Announcing Fedora 8 Test 3 (7.92)!
by Jeremy Katz 04 Oct '07

04 Oct '07

Fedora 8 Test 3 is here! This is the last test release before the development freeze and a great time to test all those packages that you know and love. Test 3 is for beta users. This is the time when we must have full community participation. Without this participation both hardware and software functionality suffers. Fedora is a Linux-based operating system that showcases the latest in free and open source software. Fedora is always free for anyone to use, modify, and distribute. It is built by people across the globe who work together as a community: the Fedora Project. The Fedora Project is open and anyone is welcome to join. Up-to-date release notes for Fedora 8 Test 3 can be found at http://docs.fedoraproject.org/release-notes. == Changes from Fedora 8 Test 2 == * Online Desktop provides a desktop experience designed around online services. A preview of Online Desktop is provided via BigBoard, which is a optional sidebar in GNOME. * KDE 3.5.7 is available in the KDE Live image as well as the regular DVD. The KDE 4 (Beta) Development Environment is available in the repository. * Live installations are faster and require a smaller root filesystem. The file system layout has also changed somewhat. System files for the Live images are now under `LiveOS/`, and a new `README` file has been provided as a short introduction to the live image. * Package management now features much better performance via `yum` and friends. * The completely free and open source Java environment called Iced Tea is installed by default. Iced Tea is derived from OpenJDK, includes a browser plugin based on GCJ, and is available for both x86 and x86_64 architectures. GCJ is still the default on PPC architecture. * CodecBuddy is now included, and promotes free, superior quality, open formats to end users trying to play multimedia content under patent encumbered or proprietary formats. * Bluetooth devices and tools now have better graphical and system integration. * Laptop users benefit from the "quirks" features in HAL, including better suspend/resume and multimedia keyboard support. * There is now improved power management thanks to both a tickless kernel in `x86` and `x86_64` architectures, and a reduction in unnecessary processor wakeups via `powertop`. * Eclipse 3.3 (Europa), a new release of the great IDE and development platform, is available as part of this release. * The `pam_console` module has been removed in favor of access control via HAL, which modernizes the desktop. * NetworkManager 0.7 provides improved wireless network management support. It includes support for multiple devices and provides the capability of system-wide configuration, among many other enhancements. This transition may induce some regressions temporarily, and more testing and feedback is appreciated. * Secure remote management capability is now provided for Xen, KVM, and QEMU virtualization. * Transifex provides a web-based translation interface to allow users to contribute translation work for Fedora hosted projects as well as being able to provide translations to upstream directly to any upstream project. * Integration of unique build IDs into Fedora's software building infrastructure now provide enhanced debugging capabilities and core dumps. * Fedora now offers easier rebranding of Fedora derivatives via a `generic-logos` software package. Changes in Fedora's mirror structure also make creation of derivatives easier. * Fedora now includes support for Nepali Language, extending its reach to many more users. === What's New in Fedora 8 === * A major list of features is available at http://fedoraproject.org/wiki/Releases/8/FeatureList. === Release Schedule for Fedora 8 === * The Fedora 8 release schedule can be found at http://fedoraproject.org/wiki/Releases/8/Schedule. Fedora 8 is scheduled for general release on 8 November 2007. === How to Get Fedora 8 Test 3 === * Fedora 8 Test 3 can be installed via Live image, regular DVD, or via network installation. You can find the DVD images as well as the primary live images at: http://mirrors.fedoraproject.org/publiclist/Fedora/7.92/ * You can also download the DVD and Live images via bittorrent at: http://torrent.fedoraproject.org * More information on the various spins available with the release of Fedora 8 Test 3 is available at: http://fedoraproject.org/wiki/F8Test3/Spins People who are already running the rawhide (development) branch of Fedora or any of the previous test releases can simply run `yum update`. (Some current Rawhide packages might be newer than Fedora 8 Test 3 packages.) We also appreciate new installation testing for feedback on changes to the Anaconda installer. == Known Issues == * [https://bugzilla.redhat.com/show_bug.cgi?id=302381 Bug 302381] If you are installing via DVD or also possibly NFS-mounted ISO images, the Add/Remove Programs application (`pirut`) may crash when run, with a traceback about HAL. Running `yum update` or using `yum` to update at least `pirut` should resolve the issue. * [https://bugzilla.redhat.com/show_bug.cgi?id=298991 Bug 298991] The KDE NetworkManager frontend `knetworkmanager`, a graphical interface for switching between networks easily, is currently broken. This is intended be fixed before Fedora 8 release. The KDE Live images have `nm-applet`, which works with KDE, enabled by default as a workaround. * Other Common issues can be found at http://fedoraproject.org/wiki/Bugs/F8Common. === Bug Reporting and tracking === You can follow the procedure outlined in http://fedoraproject.org/wiki/BugsandFeatureRequests to report any bugs found in your testing. The Release Engineering and QA teams keep track of bugs that are considered release blockers. To see that list, visit: * http://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=F8Blocker To see a list of additional non-blocker bugs that should hopefully be fixed for Fedora 8, visit: * http://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=F8Target Please check these lists before reporting new bugs!

1 0

Fedora Weekly News Issue 103
by Thomas Chung 01 Oct '07

01 Oct '07

= Fedora Weekly News Issue 103 = Welcome to Fedora Weekly News Issue 103 for the week of September 24th. http://fedoraproject.org/wiki/FWN/Issue103 In Announcements, "Cast your vote for the Fedora 8 Codename", "Fedora Unity releases updated Fedora 7 Re-Spins". After a month-long break, Fedora Weekly News is now back to our regular schedule. Thank you for your patience and support. To join or give us your feedback, please visit http://fedoraproject.org/wiki/NewsProject/Join. 1. Announcements 1. Cast your vote for the Fedora 8 Codename! 2. Fedora Unity releases updated Fedora 7 Re-Spins 2. Ask Fedora 1. Compiz-Fusion in Fedora 8 2. Nodoka 3. Planet Fedora 1. Ohio Linux Fest 2. The Linux Hardware Database 3. Fedora 8 + Online Desktop 4. Daily Package 5. Marketing 1. Customized spins of Fedora 2. The 7 Most Influential GNU/Linux Distributions 3. Visual: Mirrors vs Users 6. Developments 1. RFC: /var or /srv? 2. YUM To Get Configurable Multilib Behavior In Fedora 9 ? 3. Rapid NetworkManager Development 4. System Entries In /etc/hosts 5. RPMFusion Spin 6. Mock Builds Of Rawhide 7. Updates Busted. Bodhi Fixed. 8. OpenGL Wrapper Preparation for Games Live DVD 9. Kmod (Kernel Module) Packages No Longer Permitted 10. Tickless x86_64 Kernels 11. Graphical Shutdown? 12. util-linux Missing From Build Root 13. Proposed Buildsys-build Group Changes 14. RPM Fusion 15. Root Login And Display Managers In Rawhide 16. Xulrunner 17. PlanetCCRMA Packages For Audio Creation To Be Integrated 18. Possibly Orphaned Lftp Spawns Bug Squad! 19. Disable IPv6 By Default 20. Udev Performance 7. Maintainers 1. End of fedora-maintainers-list 8. Translation 1. FAQ 2. Transifex Update 3. Online Translation 9. Infrastructure 1. DB2 Outage/Upgrade 2. Spins Directory 10. Security Week 1. Is a chroot secure? 2. Is SELinux really too complex? 11. Advisories and Updates 1. Fedora 7 Security Advisories 2. Fedora Core 6 Security Advisories 12. Events and Meetings 1. Fedora Board Meeting Minutes 2007-MM-DD 2. Fedora Ambassadors Meeting 2007-MM-DD 3. Fedora Documentation Steering Committee 2007-MM-DD 4. Fedora Engineering Steering Committee Meeting 2007-MM-DD 5. Fedora Extra Packages for Enterprise Linux Meeting (Log) 2007-09-26 6. Fedora Infrastructure Meeting (Log) 2007-09-27 7. Fedora Localization Project Meeting 2007-MM-DD 8. Fedora Packaging Committee Meeting 2007-09-25 9. Fedora Release Engineering Meeting 2007-MM-DD [[Anchor(Announcements)]] == Announcements == In this section, we cover announcements from various projects. Contributing Writer: ThomasChung === Cast your vote for the Fedora 8 Codename! === JesseKeating announces in fedora-announce-list[1], "We have two options for the Fedora 8 codename, and you get to help decide which we use! Log in with your Fedora Account name and password. As long as you belong to at least one group in the Fedora Account System, you can cast your vote[2]. Voting will end and be tallied at Oct, 5, 23:59:59 UTC." [1] https://www.redhat.com/archives/fedora-announce-list/2007-September/msg0000… [2] https://admin.fedoraproject.org/voting/vote.cgi === Fedora Unity releases updated Fedora 7 Re-Spins === BobJensen announces in fedora-announce-list[1], "The Fedora Unity Project is proud to announce the release of new ISO Re-Spins (DVD and CD Sets) of Fedora 7. These Re-Spin[2] ISOs are based on Fedora 7 and all updates released as of September 12th, 2007. The ISO images are available for i386 and x86_64 architectures via jigdo starting Friday, September 28th, 2007. We have included CD Image sets for those in the Fedora community that do not have DVD drives or burners available." [1] https://www.redhat.com/archives/fedora-announce-list/2007-September/msg0000… [2] http://spins.fedoraunity.org/ [[Anchor(AskFedora)]] == Ask Fedora == In this section, we answer general questions from Fedora community. Send your questions to askfedora(a)fedoraproject.org and Fedora News Team will bring you answers from the Fedora Developers and Contributors to selected number of questions every week as part of our weekly news report. Please indicate if you do not wish your name and/or email address to be published. http://fedoraproject.org/wiki/AskFedora Contributing Writer: RahulSundaram === Compiz-Fusion in Fedora 8 === Gideon Mayhak asks, "I'm writing a brief e-mail regarding the state of Compiz-Fusion in Fedora 8. The current offering is not what I would consider acceptable. Without the libcompizconfig and ccsm packages, Compiz-Fusion is not worth mentioning. The current configuration offering is a joke at best. Can we expect a proper Compiz-Fusion offering soon, or will Fedora 8 end up touting its pseudo-Compiz-Fusion when it's released? It's obviously not a deal breaker, but I don't see why it would be so hard for official package maintainers to build a couple more packages. I know there are people on the Fedora Forums who are packaging these things as they learn how to package, so maybe you could recruit them. I just hope you can ease my mind with news that they're working on it and we'll see the real deal soon." Fedora 8 is currently under active development and the release notes in the last test release did mention that what was being offered is a preview. They use glib and gconf instead of the other configuration mechanisms you have mentioned although both the GNOME and KDE front ends have been separated to integrate better with the respective desktop environments. compiz-bcop has been introduced into the repository recently and libcompizfusion is waiting on review at https://bugzilla.redhat.com/show_bug.cgi?id=247406. If you find bugs or want to request enhancements, you can report or request them in http://bugzilla.redhat.com against the relevant packages as usual. If there are interested people willing to participating in maintaining or co-maintaining software in Fedora, you are most welcome to do so. More information at http://fedoraproject.org/wiki/PackageMaintainers. We also need people doing package reviews to ensure the high quality of new packages being introduced in Fedora. Review guidelines are available http://fedoraproject.org/wiki/Packaging/ReviewGuidelines. Reviews can be done by virtually anyone. === Nodoka === Robert Myers asks, "Is the new Nodoka theme going to be ported to KDE? If not, why isn't it?" It can be ported as soon as someone with the interest, time and skills show up to do it. Martin Sourada answered more questions on Nodoka including this one in a recent interview available at http://fedoraproject.org/wiki/Interviews/MartinSourada. [[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 === Ohio Linux Fest === MaxSpevack reports in his blog[1], "We had a great day at Ohio Linux Fest. Jeff did a superb job as the point person for the booth, and it was great to see a bunch of Fedora folks in attendance. Karlie gave a really interesting talk about how FOSS developers pay their bills, and apparently her kids had a good time playing with Seth's OLPC." [1] http://spevack.livejournal.com/29104.html [2] http://www.ohiolinux.org/ === The Linux Hardware Database === HaraldHoyer reports in his blog[1], "Have you ever tried to find out, if a specific computer device (e.g. laptop, sound card, wireless card) you want to buy, works with Linux? If yes, you know how distributed all the information is over the net. Here is the chance to build a solid, updated database[2]. Over the wekend, I put together a Turbogears web frontend and glued it together with a MoinMoin Wiki. Curious? Try it out!" [1] http://www.harald-hoyer.de/fedora/the-linux-hardware-database [2] http://hwdb.surfsite.org/ === Fedora 8 + Online Desktop === JonathanRoberts reports in his blog[1], "The third interview in the series of feature previews for F8 has just gone up on the wiki[2]. This time it's with Colin Walters and he talks about the work that's gone on to integrate a lot of the Gnome Online Desktop work, particularly Bigboard. This includes the new GDM session that is created after installing the online-desktop package - Online Desktop - where a browser is launched immediately and the top panel is replaced by Bigboard. As always there is also a cool screencast showing some of the coolest features." [1] http://blog.questionsplease.org/2007/09/30/fedora-8-online-desktop/ [2] http://fedoraproject.org/wiki/Interviews/ColinWalters [[Anchor(DailyPackage)]] == Daily Package == In this section, we recap the packages that have been highlighted as a Fedora Daily Package [1]. [1] http://dailypackage.fedorabook.com/ Contributing Writer: ChrisTyler Editor's Note: Sorry, no Daily Package has been posted for this week since our editor for this beat is busy with teaching the good kids this semester. [[Anchor(Marketing)]] == Marketing == In this section, we cover Fedora Marketing Project. http://fedoraproject.org/wiki/Marketing Contributing Writer: ThomasChung === Customized spins of Fedora === RahulSundaram reports in fedora-marketing-list[1], "When Fedora 7 was released, one of the big features that we talked about was the idea of customized spins of the distribution. Now that Fedora 8 is on the way, it's useful to look and see how we have done, and what sort of custom spins have been created.[2]" [1] https://www.redhat.com/archives/fedora-marketing-list/2007-September/msg001… [2] http://www.redhatmagazine.com/2007/09/28/customized-spins-of-fedora/ === The 7 Most Influential GNU/Linux Distributions === RahulSundaram reports in fedora-marketing-list[1], "Fedora's main reputation is for being the first distro to include new innovations. For instance, Fedora was the first distribution to include tools that allowed average users to work with SELinux's detailed security options. In the same way, Fedora 7 was the first to include Smolt, a program for collecting hardware information about users; Revisor, a program for creating custom install disks, and the Liberation typefaces that provide the metrical equivalents of Arial, Helvetica, and Times Roman in free fonts. Although some users on Fedora mailing lists suggest that this innovation makes Fedora unsuitable for servers and mission-critical operations, an increased attention to testing is starting to make that generality obsolete. After a slow couple of years, Fedora is also well on the way to realizing its goal of creating a thriving community in which Red Hat is important, but no longer completely dominates decision-making.[2]" [1] https://www.redhat.com/archives/fedora-marketing-list/2007-September/msg001… [2] http://itmanagement.earthweb.com/entdev/article.php/11070_3701421_1 === Visual: Mirrors vs Users === MikeMcGrath reports in fedora-marketing-list[1], "I wrote a little call[2] to help post today as well as a comparison of where our users are vs mirrors. This is using a small sampling of people that have connected to our mirrors site. Not an exact science but interesting none the less, thought I'd share." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-September/msg001… [2] http://mmcgrath.livejournal.com/8797.html [[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 Now that we're back from a break @fedora-devel beat has two sections. This top one is the most recent and covers events from September 23rd to September 29th. The material below it covers a selection of events from earlier activity on the list while we were re-charging our batteries. === RFC: /var or /srv? === CaseyDahlin touched off[1] a wide-ranging discussion about backup and reinstall policies when he suggested that the ''/srv'' directory should be populated with data currently in ''/var/www'' and ''/var/ftp/pub'' as apparently recommended by the FHS[2]. [1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01790.h… [2] http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSY… The status quo was summed up[3] by JesseKeating, who noted that the FedoraPackagingCommittee had decided that the FHS was contradictory about the uses of /srv and it had thus been decided to leave /srv blank although some packaged applications were writing there. [3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01791.h… AlanCox argued[4] that Casey's proposal was a bad one for a distribution because updates could result in the removal/modification of files placed there by administrators, which was explicitly prohibited by the FHS. Alan also was very straightforward in stating that /srv was a mistake in the FHS specification, that the FHS in the waning years of its life had created /srv on the basis of a vote conducted by those "who had no clue about distribution building"[5]. Alan recommended that /srv should be obsoleted and the removal of "the silly statements about /var (which mostly exist to try and force the /srv stupidity into being)." [4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01806.h… [5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01809.h… A response[6] from SethVidal suggested that while Alan had perfectly good points about not using /srv in the distro it was nevertheless widely used (either with that name or another) as a top-level directory to simplify backups. There was substantial agreement on this point from JesseKeating, and DavidCantrell added[7] that although he favored leaving the directory and deciding that packages should not install to it, it was worth considering a limit to the number of top-level directories. [6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01821.h… [7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01833.h… RobCrittenden wondered[8] what Seth meant by saying that ''/var'' only contained transient data which did not need backup. Further discussion between NicolasMailhot and RalfCorsepius about the treatment of spools in /var led ArthurPemberton to wonder[9] whether they were describing current practice or what should be done. Scattered throughout the long (over one hundred messages) thread were numerous examples of data contained in /var which it wouldn't be nice to lose. These included mail spools, databases and web server data. [8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01834.h… [9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01853.h… Attempting to draw some sense out of the mass of examples of current practice and competing intents, RichiPlana enumerated[10] four concerns which had emerged as considerations in determining a policy governing the placement of data files. [10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01870.h… The need to backup efficiently without wasting space and time was raised[11] by MattMiller after IanBurrell pointed out that ''/var'' contained a mixture of data that absolutely should be backed-up and other non-important local writable data. LamontPetersen observed[12] that it seemed to be common practice in medium to large-scale enterprises to use the '/srv' directory to separate out the important material. This theme was later re-visited in a slightly acrimonious exchange between NicolasMailhot,LamontPetersen and KrzysztofHalasa. Nicolas made the point[13], based on his experience, that for enterprise purposes the current use of /var for a mixture of "long-term and transient data, generic and implementation-specific stuff, local and global data" was a problem. Lamont also provided some good ballpark figures[14] to expand the point when Krzyzstof would not accept this portrait of typical enterprise needs. Nicolas explained[15] the typical strategy employed by large enterprises in a further excellent post. [11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01876.h… [12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01882.h… [13] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02290.h… [14] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02391.h… [15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02423.h… JohannGudmundsson's strong opinion in favor of removing ''/srv'' entirely, with the expectation that sysadmins who want it would find their way to the ''mkdir'' command prompted[16] a satirical reaction from NicolasMailhot, portraying the possible Fedora config files which could be supplied were this option chosen. [16] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01850.h… A post from RichiPlana in which he volunteered[17] to modify the spec files of either MySQL or Mailman to use /srv instead of /var raised another pair of issues. JohnDennis pointed out[18] that SELinux policies would have to be changed in tandem with the moving around of any files contained in packages. John also noted that there are many applications depending on the current locations and that advanced notice of such changes were necessary. [17] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02191.h… [18] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02192.h… A potential way out of this latter difficulty was suggested[19] by KellyMiller(lightsolphoenix) in the form of "compat" packages which create symlinks to the old location. AlexanderBostrom was skeptical that this would be transparent and listed[20] some potential ways in which it could fail, concluding that the release notes would need to explain it, whatever was decided. CaseyDahlin agreed[21] with Alexander that it might be necessary to create a "structure" within /srv/lib, which to some extent mirrored the structuring within /var. He sketched an interesting perspective of /var, which was that it contained information which should be in RAM except for the reasons of size or the need to persist across reboots. [19] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02274.h… [20] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02278.h… [21] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02284.h… The former difficulty was addressed[22] by SteveGrubb who confirmed the need for SELinux to be made aware of a mapping between /srv and /var. This led JesseKeating to tie[23] the two problems, pointing out that as /srv was by definition a free-for-all there was no way to prepopulate it without the danger of treading on the toes of the local sysadmin. MattMiller then wondered whether the SELinux tools could be modified to allow the local sysadmin to choose a particular policy for /srv and DanielWalsh responded[24] that it could be done, but would require changing the hardcoded default locations searched by regexes in semanage commands. [22] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02197.h… [23] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02198.h… [24] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02221.h… LamontPetersen was sanguine about the potential change and rebutted[25] Jesse's worries on all points, essentially pointing out that sticking with the current /var setup had all the problems except the SELinux one, which he asserted was trivial. SteveGrubb countered[26] that although it might be possible to assign the correct SELinux types to directories there would still be per-file problems. RichiPlana asked why it was that the SELinux policies were not set by the installation package and this led to an interesting post[27] from KarlMacMillan, who explained that allowing a package to install a new type and also to install files that should have that new type was a chicken-and-egg problem. The post and responses from Jesse[28] and PanuMatilainen[29](on whether RPM should/could record file contexts in rpm headers) are probably worth reading. [25] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02202.h… [26] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02217.h… [27] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02255.h… [28] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02266.h… [29] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02281.h… Finally, there were several[30][31] scattered suggestions throughout the thread that recognized that the FHS should perhaps be changed and the best policy was to submit patches upstream with regard to the specific issue of /srv. [30] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02234.h… [31] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02237.h… === YUM To Get Configurable Multilib Behavior In Fedora 9 ? === A slightly disturbed SteveGrubb reported[1] that an x86_64 machine with no i386 packages was unwantedly installing i386 packages for NetworkManager during a ''yum update'', but that if ''yum update NetworkManager.x86_64'' or ''yum update NetworkManager'' was used then only the desired x86_64 packages were installed. Steve wanted to know if this was a known problem, or if he should file a bugzilla report. SethVidal asked for more detailed information and Steve supplied it, noting that the problem seemed to be that if ''dhcdbd'' were deleted by hand then there was no problem, but that if YUM made the deletion then the problem was manifested. JesseKeating quickly surmized that dhcdbd was being obsoleted by both the i386 and x86_64 packages in the repository and Seth confirmed this and suggested[2] that to avoid this problem ''/etc/yum.conf'' should have ''exclude=*.?86'' added to it. [1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01927.h… [2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01954.h… Steve still wondered why his ''exactarch=1'' had been ignored and why ''yum update <packagename>'' was behaving differently to ''yum update''. Seth replied[3] that obsoletes were allowed to cross architecture boundaries, which provoked further questions[4] from MattMiller concerning the handling of obsoletes when there are potential competitors on either the installed or obsoleting ends. [3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01961.h… [4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01973.h… A suggestion from MichaelWiktowy that ''anaconda'' might add Seth's fix to ''/etc/yum.conf'' by default along with a concern not to paper over bugs led Seth to respond[5] that there was no bug as YUM was doing exactly what it had been written to do. This provoked DavidWoodhouse to state[6] his concerns with YUM's behavior and to label it as "buggy". David, MattMiller[7] and VilleSkyttä[8] also cautioned that Seth's fix did not work for the situation where the desired state was a 64-bit only system with some small number of specific exceptions. [5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01956.h… [6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01965.h… [7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01957.h… [8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01967.h… JesseKeating defended[9] YUM's behavior from David's accusation of "bugginess", pointing out that it was implementing exactly the mulitlib strategy which it had been asked to do. VilleSkyttä wanted to know where the strategy was documented and Jesse did his best to describe[10] it. David wasn't buying one of the important conditions of the strategy, namely that "we want both runtime library and development package availability of the secondary arch installed by default" and suggested[11] that exactly the opposite was wanted by users. [9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01970.h… [10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02003.h… [11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02009.h… A large part of the problem seemed to hinge around RPM's (as opposed to YUM's) inability to use architecture specific dependencies (see also earlier threads[12]). David was keen to disentangle[13] the problem of the default installation of secondary architecture packages (which he saw as undesirable) from whether multilib[14] should be provided. [12] http://www.redhat.com/archives/rpm-list/2006-August/msg00011.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02029.h… [14] http://www.redhat.com/magazine/009jul05/features/multilib/ JosVos argued[15] that a plurality of strategies should be enabled through plugins to YUM and Jesse responded[16] that this was exactly the plan for Fedora 9. A plan for a face-to-face meeting with some of the principle architects (SethVidal, BillNottingham, Jesse and David) looked like it was underway[17] for "some time in the future". [15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01987.h… [16] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02014.h… [17] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02018.h… === Rapid NetworkManager Development === MatthewSalzmann provided[1] a nice, compact report of a ''NetworkManager'' problem manifested since version 0.7. He had eliminated possible SELinux problems by testing with it set to permissive and reported that several kernels had shown the problem. The wireless chipset was an iwl13945 (see FWN#89 "Status Of Support for IWP3945abg Wireless In Fedora 7"[2]). [1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02151.h… [2] http://fedoraproject.org/wiki/FWN/Issue89#head-3e38c7216e9a44e59750ac3ed823… Matthew's worry that the problem might be due to user-error was quickly dispelled[3][4][5] by a series of similar, confirmatory reports. MattMiller posted a bugzilla entry[5] which seemed to indicate that updating to the latest versions of NM and wpa_supplicant would fix some issues for some people. Unfortunately although Matthew was able to report some progress in terms of the menu appearing the wireless options were grayed out. [3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02153.h… [4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02166.h… [5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02168.h… A raft of related, but individual problems were reported in the thread once Jessekeating suggested updating to the latest versions of NetworkManager and wpa_supplicant. TomLondon reported that although scanning was working properly only hex-keys were being accepted and ZackCerza added[6] that this would be a problem with his AP which only allowed a passphrase to be set. A workaround was suggested by DanWilliams (''/usr/sbin/wpa_passphrase <ssid> <passphrase>'') which did not impress RalfErtzinger, but produced results[7] for Tom. [6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02277.h… [7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02327.h… A later kernel seemed to work nearly perfectly for Tom[8] and DarrellPfeifer (who was using an iwl3945 but not wpa_supplicant). Matthew reported no success with the latest versions of affected software (NetworkManager*-0.7.0-0.3.svn2907.fc8, wpa_supplicant-0.5.7-9.fc8, kernel-2.6.23-0.213.rc8.git2.fc8) and agreed[10] with Tom that the issue was that if the AP did not broadcast its SSID then the greyed-out menu items rendered the network unusable. [8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02348.h… [9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02347.h… [10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02358.h… Matthew then listed[11] his current problems, including an inability to choose the format for entering the passphrase, a tiny non-resizable icon for the passphrase box, and finally greyed-out/inactive menu items for "connect to" and "create new". Matthew concluded by asking for step-by-step instructions to use wpa_supplicant. JesseKeating addressed[12] Matthew's problems, including the information that the UI hadn't been written yet for the greyed-out items and while it might not make Test3 it was hoped to be done by Fedora8 Final. [11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02375.h… [12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02377.h… TomLondon wrote up a nice wpa_supplicant HOWTO which got Matthew finally connected[13] and JeremyKatz noted that VPNC support[14] and the tiny password box dialogue[15] would be fixed in the next build. [13] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02393.h… [14] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02402.h… The overall impression was that NetworkManager and associated tools are going through a lot of needed changes and that flakiness abounded as did the rapid fixing of bugs. KevinKofler queried[15] the strategy behind this. [15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02194.h… === System Entries In /etc/hosts === HarryHoffman asked[1] when the hostname had stopped being added by default to ''/etc/hosts''. His concern was that mail sent by applications via a mail host should have an address from "root(a)myhost.com" instead of "root(a)localhost.com". [1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02222.h… DavidCantrell took the bullet[2], suspecting that he had made the change by mistake while rewriting the guts of anaconda, he noted that he had fixed this rawhide in and provided a bugzilla link. Almost immediately SimoSorce begged him to reconsider as Kerberos would break if the hostname did not reflect the public-facing IP address. David then suggested[3] that the best course of action was to defer the change until after Fedora 8 had been released. Harry took David's recommendation and mused out loud[4] that his particular problem was best solved by configuring his local MTA to use the FQDN. [2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02225.h… [3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02228.h… [4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02229.h… Meanwhile AdamJackson(ajax) reacted[5] to Simo's suggestion that GNOME needed to be smarter about changing the hostname mapping when the main network interface got an IP by suggesting that if it were true that Kerberos/winbindd broke this way then they were buggy. AlexanderBostrom admitted that he wasn't sure what happened in these situations (which he had observed) but believed[6] that if a hostname were mapped to 127.0.0.1 in /etc/hosts then DNS would be over-ridden and Kerberos duly upset. [5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02247.h… [6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02317.h… A spate of testimonies followed from those who had no Kerberos problems while the hostname was mapped to 127.0.0.1 in /etc/hosts. JesseKeating thought[7] that expecting DNS-resolvable hostnames was dated thinking. LamontPeterson argued[8] that the /etc/hosts file was merely to enable the box to resolve itself without respect to the network so that daemons depending on the hostname in their configurations would not be confused. [7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02319.h… [8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02344.h… SimoSorce responded[9] that this would cause problems for a KDC and that he agreed with Lamont's interpretation of /etc/hosts as long as ''dhclient'' or the network-config tools could enter the correct hostname to IP mapping. Lamont thought[10] that the KDC point was obvious, but that what was being discussed was laptop clients. [9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02350.h… [10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02372.h… === RPMFusion Spin === The need for an RPMFusion spin was expressed[1] by JóhannGuðmundsson. It was phrased in a confrontational style, wondering whether "MaxSpevack [would] put his money where [h]is mouth is" and allow the spin to be hosted on fedoraprojects.org. Simultaneously the post implicitly admitted knowledge the presence of legal problems and the need to host any such project outside of the USA. Jóhann expressed an interest in seeing whether there were more downloads of the spin than of "Fedora". [1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02294.h… HansdeGoede made it clear[2] that this was not a post made on behalf of the RPMFusion project. [2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02297.h… The initial response from JesseKeating answered[3] negatively the suggestion that the spin could include Fedora artwork or the name. Jesse also addressed the quote from MaxSpevack, pointing out that remixing Fedora implied a lot more than the uninteresting project of adding a few patent-encumbered packages and producing a work which was not free for /everybody/. [3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02300.h… JoshBoyer answered some later questions, and confirmed[4] that the hypothetical spin would be allowed to pull from the Fedora Project's repositories, explained that it would not be possible to host even a GPL licensed package which implemented a patented technique and reminded that the "media problem" is not one solvable by the Fedora Project. [4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02306.h… Further discussion unearthed[5] the information (from MattDomsch and NicuBuculei) that the replacement of the artwork would not be necessary apart from the trademarked logos due to recent work, and that work has been done to provide non-logoed graphics to facilitate this sort of derivative. [5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02310.h… RahulSundaram[6] and BillNottingham[7] also pointed Johann towards the ''generic-logos'' package in rawhide which is intended precisely to allow easier rebranding by derivative distributions. [6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02311.h… [7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02320.h… Based on the answers received, Johann asked whether the FedoraUnity respins could be hosted on fedoraproject.org and MikeMcGrath supplied[8] a link to the current process-in-progress. Johann felt that these should be given pride of place as they would save users a lot of downloading of updates. JesseKeating expressed[9] admiration for the respins but also cautioned that they should not replace the gold images because they hadn't gone through the same QA. Jesse further suggested that with a six-month release schedule it was hard to see where the resources would come from to do such QA. JeroenvanMeeuwen(kanarip) was skeptical[10] that the spins would be blessed because of their respin tool being unapproved by ReleaseEngineering. [8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02330.h… [9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02334.h… [10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02337.h… Johann then posted[11] a critique of how it seemed that the hosting of spins would be handled, advocating a completely unreviewed, hands-off provision of space for anyone that wanted to do anything. Reaction was unfavorable and ranged from SethVidal's threat to create a FedoraPr0n respin[12] to MikeMcGrath's observation[13] that the most interesting spins would come from countries with different laws and that they would not be called Fedora. [11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02351.h… [12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02359.h… [13] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02363.h… Much later in the thread DouglasMcClendon posed[14] a hypothetical way of evading the intent of the Trademark guidelines (by creating an initrd) which elicited a long subthread of legal supposition. Rahul also explained contributory infringement and other problems in response to a demand[15] for a definitive settling of accounts from Johann. [14] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02394.h… [15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02383.h… === Mock Builds Of Rawhide === MattDomsch posted[1] the results of the Fedora Rawhide-in-Mock x86_64 build with a list of 431 packages failing to build without a bug filed. [1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02100.h… TomLane thought[2] that Matt was using a broken compiler based on the reported failure of the MySQL builds. [2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02108.h… The results[3] for the Fedora Rawhide-in-Mock i386 builds were similar with 433 out of 4740 packages failing to build with no bug filed. BojanSmojver noted[4] the mock problem in resolving the localhost. [3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02101.h… [4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02107.h… A discrepancy between the lists provided and the individual logs for mod_perl was observed by JoeOrton and Matt explained[5] that since providing the lists he had re-run the failures overnight, some of which were now resolved. [5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02140.h… JesseKeating was curious as to whether Matt's build set included the latest glibc which should include warnings about potential buffer overflows in C++ applications due to D_FORTIFY_SOURCE{,=2} being enabled. The good news[7] was that there were no additional warnings/failed-builds due to this. [6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02141.h… [7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02216.h… === Updates Busted. Bodhi Fixed. === On Tuesday 25th September ThomasBaker asked[1] whether the Fedora 7 updates had gone down again. LukeMacken explained[2] that memory issues were being manifested during the composition of the repository and that he intended to write some sanity checks into Bodhi's masher. [1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02095.h… [2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02109.h… BojanSmojver saw[3] an opportunity (to grab the latest kernel) instead of a problem. [3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02117.h… A problem still appeared[4] to exist on Wednesday 26th according to BrunoWolff as he reported that updates were still missing although files were present. === OpenGL Wrapper Preparation for Games Live DVD === HansdeGoede continued his pleasant practice of announcing exciting new respins by asking[1] maintainers of OpenGL-using games to start using a wrapper he had created. The wrapper is a bash script which checks for DRI availability and upon failure pops up an error dialogue with which it is simple to interact. [1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02055.h… The point of including OpenGL games, but not propietary drivers on the DVD was questioned[2] by GérardMilmeister and DebarshiRay(rishi) happily answered that it would provide a nice means of testing new computers for available, quality FL/OSS drivers. RichiPlana quipped[3] that maybe it should be renamed "3D-Games-For-Intel-and-other-open-source-friendly-hardware-vendors" and JefSpaleta embraced[4] that idea: "that is the WHOLE point. This is what Fedora IS, as a project it is focused completely and utterly on the open source software stack. We aren't sugar coating it or hiding the fact that video driver coverage is a problem, by slipping users proprietary pills. Video driver coverage IS a problem, its a problem that needs to be stressed and not covered over in a very shallow and vain attempt to boost our distribution numbers by sneaking in addon drivers we don't support as a project." [2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02058.h… [3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02082.h… [4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02084.h… Although it was hoped that the pre-5xx series ATI Radeon cards would all work perfectly NilsPhillipsen was able to highlight[5] one non-working example, leaving Intel as the current sole contender although the situation is expected to change in the near future. [5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02339.h… JochenSchmitt reported[6] that although he could run ''stellarium'' with the rpm.livna.org supplied ''nvidia'' driver the wrapper erroneously reported that DRI was disabled. Hans requested some moe data to fix the problem. [6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02081.h… === Kmod (Kernel Module) Packages No Longer Permitted === A long-expected and debated announcement of the removal of ''kmods'' from Fedora was posted[1] by TomCallaway. [1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01949.h… DennisLeroy pointed[2] out that it was ironic that VMware were opening up their tools just now and that Fedora might be left without them while Ubuntu and Gentoo worked out of the box. His post included a link[3] to a bugzilla where Open-VM-tools was discussed extensively. [2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01968.h… [3] https://bugzilla.redhat.com/show_bug.cgi?id=294341 It seemed clear from the comments on the bugzilla review that the kernel hackers were convinced that significant parts of the code were never going to be accepted upstream and so would not be carried by Fedora. Denis wanted to know how open-vm-tools could be incorporated into Fedora and Jesse suggested[4] that he post to the fedora-kernel list. DaveJones thought this was pointless and Denis responded[5] that he knew this. [4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01971.h… [5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02041.h… DavidWoodhouse speculated[6] that due to the massive changes indicated in the review it was far from likely that FESCo would have voted for open-vm-tools as a package regardless of the new rules on kmods. [6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01982.h… === Tickless x86_64 Kernels === After installing PowerTOP[1] AhmedKamal wanted[2] to install a tickless kernel so that he follow the most promising path to reducing power usage on his laptop. Ahmed wondered if he needed a patched version of the kernel to enable hpet timers for his ICH6 chipset. [1] http://www.linuxpowertop.org/ [2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01924.h… A response[3] from JoshBoyer wondered where Ahmed had obtained his kernel (2.6.22.4-45_1.cubbi_suspend2.fc6) and suggested that if he were running x86_64 then his best bet for a tickless kernel was to upgrade to Fedora 8. ChristopherBrown confirmed[4] that this was the case. [3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01926.h… [4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01937.h… All was not well, however, because Ahmed reported[5] that the ''hpet force-enable'' patch was still needed because the BIOS on his laptop was disabling ''hpet''. He asked whether Fedora 8 would contain that patch. [5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01942.h… The following @fedora-development summaries cover a period stretching from Aug 21st to September 22nd with an emphasis on more recent material. === Graphical Shutdown? === JonathanRoberts wondered[1] if it would be possible to have a less ugly means of shutting down Fedora 8. [1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01302.h… The idea was warmly received[2] by AdamJackson(ajax), although he admitted to not having looked into it yet and thought it might be too late for Fedora 8. Adam advanced a rough model in which the X session would be able to stay up until the computer halted. DavidWoodhouse agreed that X didn't need to save state and pointed out[3] that probably nothing else needed to either. He described what seemed like a fairly brutal method of shutdown ''sync; reboot -f'' or ''SysRq-S-U-B'' as his preferred speedy method of shutting down. [2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01367.h… [3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01369.h… There was a good deal of agreement that David was right, with the exception[4] that unmounting filesystems could be a problem. [4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01406.h… ColinWalters provided[5] a link to the thinking of Ubuntu developers about the same problem and reminded the list that most of the services needing special handling on shutdown were server services usually unused in the desktop scenario. [5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01401.h… A request for clarification was made by RichiPlana and JesseKeating answered with a succinct explanation[6] of the problem/opportunity as being that a system shutdown would kill the PID of running services without going through the usual service script rigmarole of displaying information to the console and then killing the PID. [6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01408.h… A possible problem with Samba, and with recovering databases was identified[7] by SimoSorce and echoed[8] by ChrisAdams. [7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01463.h… [8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01476.h… === util-linux Missing From Build Root === GérardMilmeister pointed out[1] that in addition to "awk" being absent from the buildroot, "util-linux" was not there either, and JindrichNovy found[2] that this meant that /bin/kill was unavailable. [1] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02019.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02021.html JesseKeating[3] and RichardJones[4] explained that "util-linux" had become "util-linux-ng" and needed to be explicitly BuildRequire'd. [3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02025.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02023.html This prompted MichaelSchwendt to lament the death of the minimal build environment and JesseKeating to dispute[5] this with the assertion that the buildroot packages were the same and anything depsolved from there should never have been relied upon. Michael explained[6] that he felt that having to BuildRequire packages which should be included in the buildroot was not a good thing and Jesse pointed[7] out his previous invitation to discuss the growth of the base packages. He noted that dependency chains change and that the list of installed packages was provided. Michael responded[8] that the bureaucratic burden was too high and wondered why the list had changed. [5] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02036.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02041.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02042.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02049.html MikeMcGrath corrected[9] this by noting the difference between the explicit list (which had not been changed and would require FESCo approval) and the implicit list (of dependencies dragged in in the past). This angered[10] RichardJones who felt it was rude, hence offputting to outside developers essential to Fedora's growth. PatriceDumas smoothed the situation over[11], explaining that following the guidelines wasn't just arbitrary and unimportant, but provided a means of making sure the buildroot installation was faster. [9] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02051.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02103.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02110.html After Jesse accused[12] Michael of "whining" about the situation instead of coming up with a solution, Michael was moved[13] to suggest merging the old minimal(explicit) list and the expanded(implicit) list. [12] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02053.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02054.html Michael wondered[14] how, without a full list, it was possible to check whether a BuildRequires would be installed implicitly. Ralf responded[15] that the problem was due to using a list of packages instead of a list of applications and libraries. [14] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02061.html [15] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02084.html NicolasMailhot and MichaelSchwendt debated this point for some time with Nicholas advocating[16] Requires and BuildRequires which explicitly named the absolute pathnames of required tools instead of packages which contain them. Michael concluded[17] that many single files would have to be be BuildRequired and that a well-defined base environment would be easier. [16] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02125.html [17] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02161.html SethVidal wondered[18] whether it would be possible to use yum to resolve a list of required libraries and applications, but had to admit that it couldn't be expressed as a comps group. [18] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02157.html Michael argued[19] that it would be necessary to use mock, or else many scratch builds in Koji, to figure out the list of new BuildRequires. [19] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02162.html === Proposed Buildsys-build Group Changes === Following on from the discussion of the minimal buildroot (see this same FWN#103 "util-linux Missing From BuildRoot"), JesseKeating requested[1] feedback on a proposal to add some packages to the Explicit list of packages guaranteed to be in the buildroot. Jesse noted that he'd also asked SethVidal to provide a yum-based utility which would show what packages would be installed implicitly by the minimal build root. [1] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02226.html Seth wanted to know what the desired output from the tool would be and Jesse opened[2] the question up for input. [2] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02232.html PatriceDumas spotted some glaring omissions and Jesse responded[3] that they were pulled in via rpm-build, but that it was a good idea to list them. TomasMraz found it a little weird that binutils, glibc-devel, glibc-headers and kernel-headers would now need an explicit BuildRequire. PatriceDumas replied[4] that kernel-headers should never be needed explicitly and that glibc-headers would be brought in with glibc-devel. [3] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02333.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02262.html TillMaas thought[5] that the full exception list needed to be revived as otherwise it would not be possible to make sure BuildRequires were fully provided for in the spec by rebuilding in mock. [5] https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02260.html === RPM Fusion === HansdeGoede announced[1] that three previously separate RPM repositories: Dribble, FreshRPMS and Livna had agreed to join their efforts into one common project. This would provide two repositories: Free; and non-Free with the latter containing Open Source Software non-distributable in the USA due to possible patent problems. No replacements of packages in RHEL/CentOS, EPEL or Fedora will be carried, only add-ons including kmods. [1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00750.h… Congratulations, good-wishes and thanks rolled in, with a dominant theme of sadness that ATrpms was not going to be part of the effort. JarodWilson expressed[2] the opinion that most conflicts occurred between ATrpms and Livna. ChristopherBrown reminded[3] him that it was still an incremental improvement and that one major source of conflict (nVidia drivers) may soon disappear. [2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00850.h… [3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00852.h… An interesting perspective was provided[4] by CaseyDahlin when he described the ATrpms repository as more of a "service pack" than a collection of applications. Casey was at pains to point out that he wasn't diminishing the service which ATrpms provides. WarrenTogami agreed and wondered[5] if it might even be described as a fork of the Fedora distribution. RichiPlana was in agreement on the positive value provided by ATrpms (availability of packages for MythTV and Asterisk and the ability to install library versions in parallel easily), but wondered about the conflict in package namespace with original Fedora packages. [4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00833.h… [5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00834.h… [6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00848.h… ChristopherStone posted a link to an announcement[7] from Thorsten which seemed likely to squash this hope though. [7] http://lists.fedoraunity.org/pipermail/repo-merge-discussion/2007-May/00013… Attention was drawn to the split between Free/non-Free when RahulSundaram thanked RPMFusion for it and hoped that Fedora would thus be able to link to the Free part. KevinKofler was dubious[8] about this because of the patent-encumbrance issue and JesseKeating also doubted it, as the ability to reference (link) to such a repository seemed to imply that just packaging the material in the Fedora Project repositories would also be legal (which no one argues). A longish thread developed in which Rahul stated[9] that referencing, linking or pointing-to such packages is legally different from including them. This had been discussed at length at the Fedora Advisory Board (see FWN#99 "FESCo Approves CodecBuddy"[10]). [8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00835.h… [9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00840.h… [10] http://fedoraproject.org/wiki/FWN/Issue99#head-8f0c339b91cb83b8c9626974b6ec… The legal situation was frustrating to many participants who sought creative technical ways to solve the problem. JeroenvanMeeuwen went back and forth with Rahul over including yum repo configuration files which he believed must have the same legal status as linking to the information contained in them. Rahul asserted[11] the difference between these two actions and suggested again that anyone interested read the FAB discussions. RichiPlana thought that he finally understood the legal distinction to be that documents could point to places to get such packages, but that a configuration file to allow downloading them was illegal. But Rahul replied[12] that the legal situation used to be that even pointing in documents to a website which hosted a repository of contentious material was not allowed, but that the situation had changed (due to the Microsoft vs. AT&T case). This had been discussed[13] on the FAB list. [11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00936.h… [12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01006.h… [13] https://www.redhat.com/archives/fedora-advisory-board/2007-July/msg00032.ht… TomCallaway (spot) put it plainly[14] when he explained "contributory infringement", which doesn't seem to leave much wiggle room. Tom also passed[15] on to Red Hat lawyers the question raised by Rahul of exactly what sort of information could be included on a linked page. [14] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00959.h… [15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01041.h… LesMikesell suggested moving the repository out of the USA, but Tom (as the new Fedora Legal contact) quashed that notion by pointing out that the problem was where Red Hat was based, not the repository[16]. CaseyDahlin mooted[17] a solution similar to a bit-torrent tracker, but Tom had to regretfully respond that it would almost certainly be contributory infringement. KingInuYasha was led to rant[18] about the awfulness of software patents and to wonder how on earth the problem could be fixed. [16] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00913.h… [17] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00991.h… [18] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00997.h… An inquiry about how packagers can join RPMFusion was made[19] by KellyMiller (lightsolphoenix) and HansdeGoede responded[20] with the subscription address and the information that the review procedure would only differ from Fedora's in using blocker bugs instead of flags (subject to discussion). [19] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01056.h… [20] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01113.h… Other suggestions in the thread included registering both fedora.us and fedora.eu and hoping that users would find their way by word-of-mouth/Google to the .eu site which would contain contested software, or to providing a repository which contained packages which would configure yum to look at a repository containing the contested software. Neither gained much traction. === Root Login And Display Managers In Rawhide === A mammoth thread was initiated[1] by RahulSundaram when he requested that all display managers follow the pattern set by GDM, which disallows root logins. [1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01483.h… PatriceDumas thought that PAM might provide a way to do this and TomasMraz agreed[2] that ''auth required pam_succeed_if.so user!=root quiet'' would work. This suggestion worried BernardoInnocenti as it seemed as though it would also prevent ssh and console root logins on a server which ordinarily would not have any non-root accounts. SimoSorce replied[3] that the directive could be put into the specific ''/etc/pam.d/'' configuration file instead of the univeral ''/etc/pam.conf''. [2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01485.h… [3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01492.h… The issue of the normality and sanity of such set-ups was raised fairly forciblyat several points. The first strong objection was by AlanCox who pointed out[4] that if one were using networked authentication schemes, e.g. LDAP or NIS, and these fail then there would be no chance of recovery if root logins were disallowed. MattMiller drew[5] on his experience at Boston University to suggest that root logins could be allowed to a restricted custom rescue desktop workspace providing, for example, a terminal and ''system-config-users'' and nothing else. This idea struck Alan and others favorably, with RichiPlana highlighting[6] the problem of ordinary GNOME/KDE sessions granting root privileges to myriad daemons of uncertain[7] code quality. [4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01514.h… [5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01532.h… [6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01646.h… [7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01664.h… SimoSorce added[8], in response to Alan, that the proposal was merely to disable root login via GDM, not via console or SSH and RahulSundaram confirmed[9] this separately in answer to RexDieter's direct question. Rahul also noted that users wishing to ignore the proposed safeguard could always override this default. DenisLeroy took issue[10] with the idea that root login via a display manager was abnormal. He also wondered whether there would be a simple anaconda option to enable root login via DM as it would seem to be impossible to run ''gdmsetup'' without root access. Rahul didn't accept this argument and explained[11] how gdmsetup could be run even when root-login via DM was disallowed. [8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01576.h… [9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01516.h… [10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01519.h… [11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01528.h… A certain amount of confusion ensued when Denis replied that non-root user creation was not mandatory in anaconda, and explained[12] that he was trying to avoid a scenario where after a successful X installation it would become impossible to log onto the system. Denis suggested that anaconda should allow root logins if no other users were created during installation. The confusion arose when AlanCox understood[13] Denis to be saying that anaconda should make non-root user creation mandatory. Alan explained again that single-sign-on, LDAP, NIS, YP made the creation of non-root users meaningless. A second source of confusion was generated when he added that the security argument was flawed because all one had to do was Ctrl-Alt-F1 and login as root at the console. RuiMiguelSilvaSeabra replied[14] that this was not the security concern, which was rather that GUIs tended to have large amounts of buggy code and running them as root was a risk. [12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01533.h… [13] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01537.h… [14] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01719.h… After Rahul suggested that Denis file an RFE requesting that anaconda enforce the mandatory creation of a non-root user Alan responded[15] with a request to be kept advised of this so that he could file a "violent disagreement". JesseKeating made a proposal[16] which seemed to work around the problem. [15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01538.h… [16] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01550.h… ColinWaters argued[17] that this was a change only to the Desktop Live image in order to improve the experience for creative users who would be installing only on a laptop or home PC. Colin reminded Alan that the traditional "choose your own adventure" DVD would be untouched. [17] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01548.h… An attempt[18] by Alan to pinpoint his heartfelt disagreement emphasized that he thought that "If [the user has] not ticked any of ldap, nis [during installation] .. then its a very good idea to be extremely clear to the user that they want a non root account." Colin responded[19] that remote authentication shouldn't even be a consideration as this spin was targetted at home users' laptops and that anyone wanting to set up a lab could use the DVD and kickstart. Things heated up when Alan then attempted to "insert clue"[20] with the information that he didn't want to download multiple media in order to cover both his laptop and desktops. Colin stuck to his guns and offered[21] sympathy to Alan for running an enterpise network, the information that only the boot.iso would be needed (instead of the whole DVD), and a link to the Fedora 7 install guide. [18] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01553.h… [19] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01557.h… [20] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01565.h… [21] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01569.h… JohannGudmundsson agreed with Alan that too many options and too many variants of install media would be a problem[22] and this was amplified[23] by RudolfKastl who noted the support burden which might be incurred. [22] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01597.h… [23] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01861.h… After DenisLeroy suggested[24] the Desktop SIG driving the changes must have little experience with real-world GNU/Linux deployments and should consult with RHEL customers MatthiasClasen tried[25] to stop the thread hitting rock-bottom. This didn't entirely succeed as when Rahul reminded the list that the discussion was solely for the Desktop spin MattMiller floated the idea that this was the deliberate introduction of a feature which would be unacceptable to RHEL customers, thus forcing them towards purchasing RHEL. Matt later recanted[26] slightly and made a different point, namely that "features" deprecated by RHEL customers might also be ones which Fedora users would not like. [24] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01542.h… [25] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01545.h… [26] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01573.h… Rahul's request to discuss the (de)merits of the proposal for the Desktop spin without reference to RHEL led RalfCorsepius to argue[27] that the Desktop spin itself was the bad idea. Ralf further disputed that Fedora and RHEL had different audiences citing the existence of EPEL as evidence. A thread then developed where Rahul contrasted Fedora/RHEL roles, while Ralf compared their installation similarities. Ralf argued that the only significant differences were non-technical and included support contracts, longevity, and the "non-free"[28] nature of RHEL. This latter point was disputed by, among others, Rahul and in turn Ralf accused[29] him of "spreading vile propaganda". The general reaction was that this was incivil and inaccurate. JesseKeating noted[30] that although there was some non-free software available to RHEL customers it was not part of the distribution. [27] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01606.h… [28] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01706.h… [29] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01711.h… [30] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01727.h… PatriceDumas thought[31] that Rahul was over-stating the differences between Fedora rawhide and CentOS, leaving aside update policy and lifecycle, and also wondered if Ralf were talking about the use of OpenMotif (whose licensing is not OSI approved). Further discussion with Patrice and Ralf led Rahul to expand[32] on the point that there were both technical differences and different audiences for the distributions. [31] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01716.h… [32] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01745.h… === Xulrunner === A note[1] from JesseKeating cautioned that the appearance of a build of xulrunner in the Fedora 8 buildroot was premature do to outstanding issues including lack of ppc64 support and not matching the Firefox build. The build was the first appearance and could therefore be made unavailable by untagging it. [1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01588.h… DavidWoodhouse was startled[2] by the ppc(64) mention as it should all JustWork and asked what, if anything, he needed to do. JeremyKatz helpfully remembered[3] ChrisopherAillon mentioning missing Firefox ppc pieces in the upstream Xulrunner trunk. David was sagnuine that an existing patch for ppc64 should work and asked to be poked[4] if it didn't. Further investigation allowed him to declare[5] that the problem was in "xptc" (part of XPCOM[6]) and that although the build still failed it could be seen to be non ppc64 specific. [2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01589.h… [3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01591.h… [4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01594.h… [5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01627.h… [6] http://developer.mozilla.org/en/docs/XPCOM TomCallaway pointed out[7] that the error also occurred with x86_64 and appeared to be a GCC bug for C++ and JakubJelinek confirmed[8] this and assigned a GCC bug[9] to himself. [7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01666.h… [8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01668.h… [9] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33506 JesseKeating posted[10] that ChristopherAillon had used an ExcludeArch with no comments or changelog entry, but the cvslog entry from him noted that xptcall might be missing on ppc64. DavidWoodhouse wondered[11] when the "ExcludeArch must have bug filed rule (see FWN#90 "Fedora Secondary Architectures Proposal"[12]) was going to be enforced and also clarified that contrary to the cvslog supposition the xptcall stubs had been implemented for a while on ppc64. David declined Jesse's invitation to code up a means of "enforcing" the rule. [10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01593.h… [11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01596.h… [12] http://fedoraproject.org/wiki/FWN/Issue90#head-271f52b8e5603cd40d00d7c44ec8… === PlanetCCRMA Packages For Audio Creation To Be Integrated === Some good news[1] was announced by HansdeGoede. He had been planning with PlanetCCRMA's[2] FernandoLopez-Lezcano to improve the audio creation experience in Fedora by taking the existing PlanetCCRMA packages and modifying them to meet the FedoraPackagingGuidelines. [1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01421.h… [2] http://ccrma.stanford.edu/planetccrma/software/ The method by which this will happen is outlined at the wiki page for the Audio Creation SIG[3], and boils down to Fedora contributors identifying interesting SRPMS at PlanetCCRMA, whipping the spec files into shape and then submitting them for review while CCing Fernando. [3] http://fedoraproject.org/wiki/SIGs/AudioCreation There were several early takers including NicolasChauvet (kwizart) who had already[4] submitted "jack-rack" for review and also volunteered to act as a reviewer. RichiPlana was interested[5] in whether the SIG was solely going to integrate PlanetCCRMA packages (and hence should change its title) or was going to address other audio-creation issues in the future. Hans replied that for the immediate present work would focus on using the pre-existing CCRMA packages, but that the future was open to other activities. [4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01426.h… [5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01429.h… Richi wanted some further guidance as to which packages needed attention and where interested contributors might find the SRPMS. Fernando replied[6] with that information and also some great background on the history of CCRMA. Following up on that Richi had some more questions[7] about the potential of accumulating differences between Fedora curated packages and PlanetCCRMA's packages, and also about the need for a low latency kernel. [6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01635.h… [7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01640.h… According to Fernando[8] a low-latency kernel is not essential to run any of the packages, although it is desirable for live performance situations. Fernando noted that IngoMolnar's work on realtime pre-emption won't be in the mainline kernel anytime soon and wondered what Richi meant about "kmods" (see FWN#99 "Kmods Clarified"[9]). [8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01679.h… [9] http://fedoraproject.org/wiki/FWN/Issue99#head-98170522fb95c1c25efc05a5f2f6… === Possibly Orphaned Lftp Spawns Bug Squad! === An angry plea[1] from AlainPortal requested that the ''lftp'' package should be orphaned because the maintainer MarosBarabas was not tracking upstream releases and had left the package at an early version (3.5.10) despite despite a request from Alain to update to a new release and three subsequent upstream changes. The bugzilla entry contained[2] a mix of frustrated speculation as to why this had not happened. [1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01192.h… [2] https://bugzilla.redhat.com/show_bug.cgi?id=242112 When RichiPlana asked how packages get orphaned and how he might pick one up for maintenance he was supplied with the necessary links by RahulSundaram[3] and JefSpaleta[4]. [3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01202.h… [4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01272.h… Rahul recommended that Alain follow the AWOL policy and after thanking him for the information Alain wondered[5] whether he could skip some steps due to the age of his bugzilla request which was some months old and awaiting response from the maintainer. Alain expressed willingness to attempt to maintain the package, but also doubt as to his ability. HansdeGoede responded with a generous and open invitation to help with any C programming problems and encouraged[6] Alain or anyone else to contact him with such C problems. [5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01199.h… [6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01210.h… JeffSpaleta floated[7] the idea of a larger "broken code response group" where those skilled in programming areas could help out the less skilled. This idea seemed very popular and several people volunteered (possibly stimulated by the idea of tshirts!). Hans then wondered[8] whether creating a specific mailing list for the purpose of stimulating packagers to send out help requests would be useful. There seemed to be general agreement that it would be better than overwhelming @fedora-devel and Jef also suggested[9] enhancing bugzilla to allow the bug owner to set a flag requesting help from the code squad (whose members had swelled by this time to include JonCisela, RichiPlana, PaulFrields, HansdeGoede, DenisLeroy and JesseKeating). [7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01213.h… [8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01221.h… [9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01231.h… The positive, productive note of the thread was continued when Alain committed to maintaining the package if no response was heard in 72 hours and JeremyKatz noted[10] that this was a very short timeframe over a weekend and did a "side channel ping" to alert the maintainer. MattMiller agreed[11] that this timeframe was a bit hasty and also pointed out that although the release version numbers had increased it did not look as though anything very important was changing between releases. ChristopherBrown disagreed[12] that this was a reasonable maintenance strategy as "bugs are bugs". [10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01240.h… [11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01252.h… [12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01260.h… Subsequently the bugzilla entry showed that the maintainer was dealing with the issue and wasn't using age of a bug as the criterion of importance. === Disable IPv6 By Default === A surprisingly good thread resulted from JohannGudmundsson suggestion[1] that as IPv6 uptake had been slow it would be better to disable it in Fedora by default. [1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01024.h… One group of posters wondered what exactly was the point of disabling IPv6. ChuckAnderson asked[2] what specific problem was being solved and thought that the chicken-and-egg nature of deploying IPv6 meant that Fedora was to be applauded for being proactive and DennisGilmore was a satisfied IPv6 user who wondered[3] why he should have to jump through extra hoops when no harm was caused by having both IPv4 and IPv6 enabled. Johann responded[4] that it was a "waste of time and resources" and JohnReiser commented[5] that recommended security policy was to turn off all unused services. He added that several dozen pages of RAM were wasted if it was not used and suggested adding ''alias net-pf-10 off'' to ''/etc/modprobe.conf''. [2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01025.h… [3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01028.h… [4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01030.h… [5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01037.h… DennisGilmore pressed Johann for further proof of the exact resource burden and security threat and also informed[6] him that the contractors to the government of the USA were mandated to use IPv6 by 2008. Johann was unimpressed with the needs of the USA and provided no exact figures on the resources used, this was followed by PeterRobinson providing[6] a crude estimate of a mere 312KB RAM and also the information that MacOSX, Vista, Server2008 and others all supported IPv6 out of the box and that the EU and Asia were using IPv6 (separately DennisGilmore noted that Asia was one of the largest IPv6 users). [6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01048.h… Earlier in the conversation RichiPlana suggested that disabling IPv6 should be made a simple one-step process and asked[7] how he could do this. Interestingly, throughout the thread there were a variety of solutions offered: JohnReiser's solution above; ThomasSteenholdt's[8] ''install ipv6 /bin/true'' in ''/etc/modprobe.conf'' followed by ''chkconfig ip6tables off'' followed by a reboot; TillMaas's[9] ''IPV6INIT=no'' in ''/etc/sysconfig/network'' (which Till reported as failing in FC6). The variety of these responses indicated that Richi was onto something. DavidWoodhouse made an amusing suggestion[10] of ''echo blacklist ipv6 > /etc/modprobe.d/luddite''. Further discussion led to Richi posting[10] a link which explained things clearly. [7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01043.h… [8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01298.h… [9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01122.h… [10] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01080.h… In another part of the discussion DavidWoodhouse explained[11] how to get IPv6 connectivity using tunnel brokers even if one only has an IPv4 public address. [11] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01301.h… ColinWalters overview[12] of the thread was that the wrong question (should IPv6 be disabled) was being asked and instead it should be what specific bugs need to be fixed if it is to be enabled. This resonated[13] with DavidCantrell who had said[14] earlier that it was a pain working with IPv6 due to so many Fedora users being afraid of it. He commented that the module could be blacklisted by those that wanted to disable it but that users shouldn't be bothered with something which should just work. [12] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01074.h… [13] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01079.h… [14] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01031.h… After RichiPlana outlined[15] a plan to modify system-config-network to disable IPv6 but leave it on by default, Johann reminded[16] the list that the discussion topic was whether and how to disable IPv6 during installation and asked "IPv6fanboys" how well their pure IPv6 WAN/LAN could communicate[16a] with the rest fo the world. JesseKeating thought[17] that users should be allowed to disable IPv6 post installation using either s-c-n or NetworkManager but that bugs appearing due to it being enabled but not actively used needed fixing. OlaThoresen provided[18] personal testimony about how perfectly IPv6 worked for him. In a separate part of the thread ChuckAnderson provided[19] a list of network operators using IPv6. [15] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01193.h… [16] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01206.h… [16a] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01224.h… [17] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01207.h… [18] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01245.h… [19] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01315.h… RubenKerkhof's interest was so piqued[20] by the discussion that he registered for an account with sixss.net and MattDomsch provided[21] more details for anyone interested in experimenting with tunnelled IPv6. [20] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01317.h… [21] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01142.h… JohnReiser provided a list of arguments[22] including anonymity and expense as reasons why one would not wish to transition to IPv6. [22] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg01128.h… === Udev Performance === A response to concerns about ''udev'' performance was posted[1] by HaraldHoyer. Harald had profiled udev activity and determined that it spent the majority of its time with /sbin/modprobe due to parsing its configuration/dependency files on each call[2]. [1] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00771.h… [2] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00773.h… RalfErtzinger asked what udev could do except process the files each time and HansdeGoede suggested[3] several alternatives including: a daemon mode; a cached dump of the dependency tree; or splitting out the modprobe code into a library which could be called by udev. According[4] to Harald the daemon mode had also been suggested by GregKroah-Hartman and KaySievers. [3] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00777.h… [4] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00778.h… Some very interesting ''systemtap'' results were supplied by WilliamCohen, who noted that the current process of searching linearly through 250K of modules.dep was inefficient. Harald responded[5] that the problem was that most modprobes with a modalias were non-existent and so each line was parsed. JakubJelinek suggested[6] a hash table or other compact format might solve this problem if the time taken really was significant. [5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00790.h… [6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00793.h… DavidHollis liked[7] Hans' last option of creating a libmodprobe.so as it would avoid maintaining duplicate code and the security problems of a pipe or socket. [7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00788.h… The daemon idea was also deprecated[8] by Ralf due to security issues, while Jakubs suggestion was judged favorably. EricSandeen remained to be convinced[9] however that the parsing of the modules.dep was what was taking the time and provided an strace during boot to reinforce this point. [5] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00790.h… [6] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00793.h… DavidHollis liked[7] Hans' last option of creating a libmodprobe.so as it would avoid maintaining duplicate code and the security problems of a pipe or socket. [7] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00788.h… The daemon idea was also deprecated[8] by Ralf due to security issues, while Jakubs suggestion was judged favorably. EricSandeen remained to be convinced[9] however that the parsing of the modules.dep was what was taking the time and provided an strace during boot to reinforce this point. [8] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00808.h… [9] https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00818.h… [[Anchor(Maintainers)]] == 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 Contributing Writer: ThomasChung === End of fedora-maintainers-list === Editor's Note: FWN will not be covering fedora-maintainers in the future issue. BrianPepple announces in fedora-maintainers[1], "The plan is to close the fedora-maintainers-list on 2007-09-10. The fedora-devel-list[2] will be the mailing that acts as the direct successor for the fedora-maintainers-list." [1] https://www.redhat.com/archives/fedora-maintainers/2007-September/msg00090.… [2] https://www.redhat.com/mailman/listinfo/fedora-devel-list [[Anchor(Translation)]] == Translation == This section, we cover the news surrounding the Fedora Translation (L10n) Project. http://fedoraproject.org/wiki/L10N Contributing Writer: JasonMatthewTaylor === FAQ === DimitrisGlezos posted[1] about his additions of a FAQ to help address some translation questions. Comments/suggestions are always welcome. [1] https://www.redhat.com/archives/fedora-trans-list/2007-September/msg00147.h… === Transifex Update === DimitrisGlezos had some updates for transifex this week, one of which added support for system-config-printer.[1] [1] https://www.redhat.com/archives/fedora-trans-list/2007-September/msg00156.h… === Online Translation === DimitrisGlezos wanted to start discussion about whether or not an online translation tool would be useful and what features would be good to have.[1] [1] https://www.redhat.com/archives/fedora-trans-list/2007-September/msg00171.h… [[Anchor(Infrastructure)]] == Infrastructure == In this section, we cover the Fedora Infrastructure Project. http://fedoraproject.org/wiki/Infrastructure Contributing Writer: JasonMatthewTaylor === DB2 Outage/Upgrade === MikeMcGrath posted[1-2] that DB2 would be taken down to address disk space issues. No problems with the upgrade were reported. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-September/m… [2] https://www.redhat.com/archives/fedora-infrastructure-list/2007-September/m… === Spins Directory === MattDomsch posted[1] a suggestion to modify the mirror directory structure to better facilitate respins. The idea being that respins can be done and content can be moved back and forth between servers without causing mirror breakage. After some discussion it was agreed to be a good idea and will likely see some implementation in the future. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-September/m… [[Anchor(SecurityWeek)]] == Security Week == In this section, we highlight the security stories from the week in Fedora. Contributing Writer: JoshBressers === Is a chroot secure? === Kerneltrap has a nice summary of why a chroot is not a security feature. This is an issue that comes up every couple of years. It is likely this will continue to happen since there is quite a lot of information available on the Internet that claims a chroot is a fine way to keep something secure. The best advice if you wish to keep a process in a cage would be to use SELinux. http://kerneltrap.org/Linux/Abusing_chroot === Is SELinux really too complex? === Speaking of SELinux, this article takes a rather insightful look at the technology. http://enterpriselinuxlog.blogs.techtarget.com/2007/09/26/selinux-is-it-rea… The article does point out that the OpenBSD mailing list is obviously a rather biased place to find SELinux commentary, but many of the points made about SELinux are good for someone who hasn't been keeping an eye on the discussions. [[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 === * elinks-0.11.3-1.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg0… * libsndfile-1.0.17-2.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg0… * fuse-2.7.0-5.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg0… * ntfs-3g-1.913-2.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg0… * kernel-2.6.22.7-85.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg0… * bugzilla-3.0.2-0.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg0… * php-5.2.4-1.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg0… * t1lib-5.1.1-3.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg0… * kernel-2.6.22.9-91.fc7 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg0… === Fedora Core 6 Security Advisories === * httpd-2.2.6-1.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg0… * php-5.1.6-3.7.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg0… * kernel-2.6.22.7-57.fc6 - https://www.redhat.com/archives/fedora-package-announce/2007-September/msg0… [[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-MM-DD === * No Report === Fedora Engineering Steering Committee Meeting 2007-MM-DD === * No Report === Fedora Extra Packages for Enterprise Linux Meeting (Log) 2007-09-26 === * https://www.redhat.com/archives/epel-devel-list/2007-September/msg00110.html === Fedora Infrastructure Meeting (Log) 2007-09-27 === * https://www.redhat.com/archives/fedora-infrastructure-list/2007-September/m… === Fedora Localization Project Meeting 2007-MM-DD === * No Report === Fedora Packaging Committee Meeting 2007-09-25 === * https://www.redhat.com/archives/fedora-devel-list/2007-September/msg02152.h… === Fedora Release Engineering Meeting 2007-MM-DD === * No Report -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

announce October 2007