announce June 2007

announce@lists.fedoraproject.org

4 participants
10 discussions

Fedora Board elections -- voting open
by Max Spevack 29 Jun '07

29 Jun '07

Voting is now open for the Fedora Board elections. As a reminder, we are electing 3 of the 9 seats during this election. The candidates are (in alphabetical order): Christopher Aillon Dennis Gilmore Bob Jensen Brian Pepple Jef Spaleta Rahul Sundaram More information about the candidates is available at: http://fedoraproject.org/wiki/Board/Elections/Nominations Voting will end at Jul 8 23:59:59 UTC Please go to https://admin.fedoraproject.org/voting/ Anyone who has signed the Fedora CLA (ie: is in cla_done in the Fedora Account System) is eligible to vote. Thanks to Toshio Kuratomi for his work on the voting software. --Max -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21

1 0

Fedora Weekly News Issue 93
by Thomas Chung 25 Jun '07

25 Jun '07

= Fedora Weekly News Issue 93 = Welcome to Fedora Weekly News Issue 93[1] for the week of June 17th through June 23rd, 2007. The latest issue can always be found here[2] and RSS Feed can be found here[3]. [1] http://fedoraproject.org/wiki/FWN/Issue93 [2] http://fedoraproject.org/wiki/FWN/LatestIssue [3] http://feeds.feedburner.com/fwn 1. Announcements 1. FESCo elections 2. Planet Fedora 1. Fedora Remixed (a YouTube Video) 2. Custom Kernels in Fedora 3. Fedora Board Elections 4. FUDCon F8 Update 3. Marketing 1. Max Spevack's Interview on LWN 2. The Limits of Freedom 4. Developments 1. Install-Created Users Added Automatically To Sudoers? 2. Splitting Python Out Of Core Libraries Into Subpackages 3. Encrypting The Root Filesystem 4. Official Presto Repositories For Rawhide 5. FESCo Elections 6. No More 586 Kernels 7. x86_64 Live Media Is NOT A LiveCD 8. PAM_KEYRING Gets GDM And KDM Into Bed 9. F8: Review Hiding Partitions With HAL 10. Bugzilla: "FedoraCore" And "FedoraExtras" Products Merged to "Fedora" 5. Maintainers 1. Libraw1394 Notice For F7 Xen Users 2. Portaudio & SDL_gfx Updates 6. Documentation 1. New POTBASE definition 2. Candidate Documentation Schedule 3. Why Write Documentation 4. Fedora Documentation Steering Committee Meeting 5. Tool Help 6. Tasks! 7. Starting DocBook XML 7. Documentation 1. New POTBASE definition 2. Candidate Documentation Schedule 3. Why Write Documentation 4. Fedora Documentation Steering Committee Meeting 5. Tool Help 6. Tasks! 7. Starting DocBook XML 8. Infrastructure 1. IPTables 2. Fedora SCM 3. Ticket System 4. Making Infrastructure Requests 9. Artwork 1. Echo Icon Theme Development 2. Banners 10. Daily Package 1. ISO Master - CD/DVD Image Editor 2. QIV - Quick Image Viewer 3. The Skeleton 4. Cssed - CSS Editor 5. Fortune - Random Wit & Wisdom 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 Documentation Steering Committee (Log) 2007-06-19 3. Fedora Engineering Steering Committee Meeting 2007-06-21 4. Fedora Infrastructure Meeting (Log) 2007-06-21 5. Fedora Packaging Committee Meeting 2007-06-19 6. Fedora Release Engineering Meeting 2007-06-18 7. Fedora Translation Project Meeting 2007-06-19 13. Feedback == Announcements == In this section, we cover announcements from various projects. Contributing Writer: ThomasChung === FESCo elections === BrianPepple announces in fedora-devel-list, "This is a reminder that we are still in the self-nominations phase for the upcoming FESCo election[2]. If you are interested in being part of the committee that oversees the engineering side of Fedora, you might want to consider running for a seat." [1] http://www.redhat.com/archives/fedora-devel-list/2007-June/msg02047.html [2] http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations == 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 Remixed (a YouTube Video) === GregDeKoenigsberg points out in his blog[1], "The kids in the hall have been busy. Presenting the story behind Fedora Remixed[2]." [1] http://gregdek.livejournal.com/13778.html [2] http://www.youtube.com/watch?v=8Bs8vZgTURw === Custom Kernels in Fedora === SamFolkWilliams points out in his blog[1], "When Fedora moved to the 2.6 kernel years ago some instructions on how to build the kernel from the source RPM were added to the release notes. And there they stayed for years, largely untouched. For the Fedora 7 release notes I moved those instructions to a new document, and worked with the folks on fedora-kernel-list to refine the instructions. This effort is here[2]." [1] http://samfw.blogspot.com/2007/06/custom-kernels-in-fedora.html [2] http://fedoraproject.org/wiki/Docs/CustomKernel === Fedora Board Elections === MaxSpevack points out in his blog[1], "Just a reminder that we're in the nomination[2] phase for the Fedora Board elections. If you are interested in being a part of the top-level decision making body for Fedora, and you have a strong history of contributions to the Fedora Project, you may want to consider running for a seat. We have 3 seats to fill in this election cycle." [1] http://spevack.livejournal.com/20980.html [2] http://fedoraproject.org/wiki/Board/Elections/Nominations === FUDCon F8 Update === MaxSpevack points out in his blog[1], "Here's what we *do* know: FUDCon[2] will be Friday August 3rd - Sunday August 5th. It will be similar to the February FUDCon, in the sense that Saturday and Sunday will be a hackfest, and Friday will be a BarCamp." "The only problem is location, and that is what we still need to confirm. At first we wanted to do it in Raleigh, but I've heard from a bunch of the Red Hat engineers that travel from Boston at the time we're looking at is going to be very complicated, so from the perspective of getting a critical mass of people at the event, we might need to do it up in Boston again." [1] http://spevack.livejournal.com/20486.html [2] http://fedoraproject.org/wiki/FUDCon/FUDConF8 == Marketing == In this section, we cover Fedora Marketing Project. http://fedoraproject.org/wiki/Marketing Contributing Writer: ThomasChung, KarstenWade === Max Spevack's Interview on LWN === RahulSundaram reports in fedora-marketing-list[1], "In what is surely one of the best interviews of the year, Fedora's Max Spevack talks to LWN about the just released Fedora 7, the upcoming changes in the project's development infrastructure, and the new features in Fedora 8: "We're looking at a far less ambitious Fedora 8. With so much new stuff in Fedora 7, we'd like to give all of our infrastructure changes a chance to settle in and get some polish, and also give some of the contributors who have been going non-stop on Fedora for the last few months a development cycle that is a bit less stressful. But that doesn't mean we don't have some things planned. The best thing for people who are interested in Fedora 8 to do is look at our Wiki, where we will be tracking potential features over the course of the release cycle." Don't miss it[2]" [1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00158.ht… [2] http://distrowatch.com/weekly.php?issue=20070618#news === The Limits of Freedom === This week saw an interesting discussion on the marketing list about the potential and real limits on freedom in Fedora[1]. [1] http://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00142.html == Developments == In this section, we cover the problems/solutions, people/personalities, and ups/downs of the endless discussions on Fedora Developments. http://www.redhat.com/mailman/listinfo/fedora-devel-list Contributing Writer: OisinFeeley === Install-Created Users Added Automatically To Sudoers? === A long-standing feature suggestion[1] from MattMiller was to allow a fine-grained method of delegating some root execution privileges to administrative applications without prompting for the root password. Matt had produced patches to ''userhelper'' (which uses PAM), which tested whether the user was a member of an allowed group and then prompted for the user-password. These patches were incorporated by JindrichNovy in 2004. Their usefulness was shown when "Axel" suggested[2] that a nice feature would be to add the user created by firstboot during the install to the ''/etc/sudoers file''. [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86188 [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01903.html CaioMarcelo refined[3] the idea of creating a specific group for these users in ''/etc/sudoers'', suggesting that the already existing ''%wheel'' administrative group could be used. [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01917.html IgnacioVazquezAbrams and CaioMarcelo recognized[3] that Matt's patches laid the groundwork for disabling access to the root account and prompting instead for a password required by ''sudo''. This could be done by simply tweaking the ''/etc/security/console.apps/*'' files. Matt thought[4] that this approach would indeed work, and had the advantage of allowing a transparent transition to using PolicyKit in the future. [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01982.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02062.html Although there seemed to be strong general agreement that some sort of change like this would be good, and similar approaches were thought to have been shown to be useful in other distros (specifically Mac OSX and Ubuntu), there were some clear arguments against it. RahulSundaram was concerned[5] about the suggestion that automatically enabling a sudo account would be done depending on whether a workstation or server install was chosen. Rahul argued that this was presenting too many choices and would mean that the documentation would need an extensive rewrite both to separate and clarify the use of "sudo" as opposed to "su -c". ChrisBrown thought[6] that Rahul's post was patronizing and ended up[7] volunteering to write all the documentation needed. Matt showed[7a] how the ''/etc/sudoers'' file could be set up so that members of the wheel group could be authenticated using their user passwords, while non-members would be prompted for the root password. [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02088.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02106.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02126.html [7a] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02207.html In the course of the discussion "n0dalus" made some forceful and detailed objections to the general idea being espoused. His primary objection, expressed[8] in discussion with MattMiller and with ChrisBrown[9], was that there was no clear benefit in a single-user workstation environment, and the change would result in the creation of another avenue through which root access could be gained. [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02048.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02110.html In response DanYoung tacitly agreed with n0dalus' objection and invoked the idea (also mentioned above) of locking the root account. n0dalus asked that this be proposed specifically and itemized[10] what seemed to be the current options. ChrisBrown was in strong disagreement[11] with n0dalus that sudo was only useful in a multi-administrator scenario and argued that an important benefit was that newbies would understand the concept of root better and it would allow temporary privilege escalation without having to remember to exit the root shell. The response[12] was that preventing users running everything as root was an orthogonal problem not solved by sudo, but rather by disabling root logins. RuiMiguelSilvaSeabra mused[13] that the ease-of-use and logging resulting from sudo was benefit enough. [10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02123.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02125.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02133.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02212.html Matt summarized[14] some of the changes which may need to be made, including modifying system-config-securitylevel to manage /etc/security/console.apps and doing some more stringent password quality checking. [14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02086.html === Splitting Python Out Of Core Libraries Into Subpackages === An inquiry[1] from YanokoKaneti as to whether there were objections to splitting out some more python subpackages from core libraries was met[2] with curiosity from JesseKeating. Yanoko had stated being able to remove python from minimial installs as one of the motivations for doing this work and Jesse wondered if ''yum'' was not going to be included in the minimal install. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02263.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02267.html A sample usage case was advanced[3] by JeffOllie in which updates would be carried out using only a new Live Media image which would be used to do a reinstall. Yanoko replied[4] directly to Jesse, pointing out that an rpm-based distribution did not need yum, and Jesse emphasized that he was simply curious. [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02269.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02271.html Another example of a yum-less install was provided[5] by MatthiasSaou who had started off by unselecting the Base group. [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02272.html === Encrypting The Root Filesystem === ThomasSwan followed up[1] with a new patch to ''mkinitrd'' to provide an encrypted root filesystem. The last public discussion of this (see FWN#85 "Root Filesystem Encryption Patch"[2]) revealed some specific issues identified as problems by BillNottingham, namely not using mkinitrd's existing configuration file and hard-coding device names in a way that would break hotplugged/re-ordered devices. Thomas had incorporated this feedback into his new patch and sought further advice. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01987.html [2] http://fedoraproject.org/wiki/FWN/Issue85 The first response[3] came from KarstenHopp, who pointed out that Thomas' bash-shell method of finding the root filesystem UUID might not be needed because Karsten had submitted a patch upstream to ''e2fsprogs''. Further discussion between Thomas and Karsten clarified[4] that Karsten's patch allowed LUKS-encrypted partitions to be probed. [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01997.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02011.html BrunoWolff specifically responded[5] to Thomas' question as to when the user should be prompted during installation. Bruno had the opinion it should be the same time as when the user picks the file system-type. At this point JeremyKatz raised[6] the awkward question of how i18n and l10n could be taken into account, specifically how keymaps and locales would be handled. [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02008.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02018.html Jeremy pointed out[7] the very concrete problems faced by non-English speakers, and the impracticality of seeming workarounds such as cycling through the available keymaps. Bruno was keen[8] to get on with incorporating this exciting and useful new feature and while agreeing that there might be problems for some users (especially with suspend/resume), he also thought that it could be refined and fixed. [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02030.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02032.html TonyNelson wondered if the last keymap and locale could be used for the suspend/resume case but PeterJones identified[9] some hurdles to be cleared. Later in response to Thomas, Peter laid out[10] a set of prerequisites to solve the problem, which include getting video-mode setting into the kernel. [9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02078.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02143.html While agreeing with Peter's list, KarstenHopp also agreed[11] with BrunoWolff that it might be just as well to go ahead with Thomas's solution and debug/fix it even if it meant that some users would not have access to it. BillNottingham argued[12] that this wasn't good engineering practice. [11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02166.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02190.html === Official Presto Repositories For Rawhide === The development of Presto continued apace with the request[1] from JonathanDieter (one of the lead developers) to start creating deltarpms for rawhide and presenting them in the repositories. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02001.html Response were generally very positive. JesseKeating asked whether there were scriptable tools to create presto repositories and what the impact on mirrors would be. Jonathan supplied[2] a link to the two tools for creating deltarpm repositories and the information that the only effect mirrors should notice are an increase in storage size and a decrease in bandwidth. [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02007.html JeremyKatz wondered[3] where in the whole process should deltarpms be generated. In discussion with AxelThimm, Jeremy seemed to settle[4] on the choice of generating deltarpms for each 'nevra'[4] in a manner similar to the way koji handles package signatures (with outside information being fed into koji about each deltarpm). These would be generated for the ''updates'', ''updates-testing'', and ''rawhide'' repositories. [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02035.html [4] rpmtags: name,epoch,version,release,architecture The inclusion of rawhide generated[5] some disquiet on the part of ClarkWilliams as he suspected that the massive jumps in e.g. toolchains as opposed to gradual, iterative changes in updates would make adding a new mechanism even more unstable. Jeremy responded that complete, full testing of presto through rawhide was the aim, not saving rawhide users bandwidth, and Clark assented[6] that this seemed like good practice. [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02100.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02103.html === FESCo Elections === Following in the wake of the disagreements[1] over the extent of community control in the new Fedora world of merged Core/Extras, BrianPepple made sure[2] that everyone was kept fully informed about the upcoming elections to the Fedora Engineering Steering Committee (FESCo), including posting links to the voting policy[2a] and candidates[2b]. [1] http://fedoraproject.org/wiki/FWN/Issue91#head-83e6bceef94ccd4c598102314198… [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02047.html [2a] http://fedoraproject.org/wiki/Extras/Policy/FESCoElections [2b] http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations The criteria for candidate eligibility led JohnPoelstra to seek clarification about membership of the cvsextras group. ToshioKuratomi provided[3] it along with the information that FESCo was no longer confined to packaging decisions, but also to making all technical decisions about Fedora. [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02117.html FlorianLaRoche and JoshBoyer smoothed the path[4] for John to become a member of cvsextras as a co-maintainer, and concerns about accepting a non-package maintaining member were eased when BrianPepple pointed out[5] that the recent implementations of ACLs allowed precisely this sort of inclusion of new members while limiting the amount of damage they might cause. [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02145.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02161.html A discussion between JoshBoyer, PatriceDumas, and RalfCorsepius on the subject of whether it made sense to have people elected to a technical as opposed to a political committee saw Ralf pose the rhetorical question[6] of whether it would make sense to elect, for example, tax officials. PatriceDumas noted [7] that some such officials were elected in the USA and agreed with Ralf's analogy that the Fedora Advisory Board (FAB) was the government and FESCo its administration which did not take really important decisions. KarstenWade thought[7a] that these meatspace analogies were imposing constraints that didn't exist in the Fedora Project. [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02227.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02228.html [7a] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02299.html ToshioKuratomi and KarstenWade were interested in expanding the franchise. This discussion led NigelJones to ask whether FESCo had lost its way and BrianPepple to respond[8] that new responsibilities (which Brian listed) were being assumed and they included packaging, release-engineering, and quality-assurance. PeterJones pointed out that there was little danger of someone without an established reputation attracting votes[9]. Agreeing with Brian's list of responsiblities ToshioKuratomi espoused[10] the principle that "''[...] you should be able to vote if you are under FESCo's authority. You should not be able to vote if you are not.''" Karsten responded[10a] with the objection FESCo decisions affect the whole community and that being split into voting pools instead of allowing all FAS seemed to have no good basis[10b], he also reiterated his doubts about the value of simply assuming that there was one form of democracy. [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02136.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02141.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02154.html [10a] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02298.html [10b] http://www.redhat.com/archives/fedora-devel-list/2007-June/msg02344.html === No More 586 Kernels === DaveJones announced[1] that he had made the 686 kernel bootable on 586 machines with the purpose of not having to build the 586 specific kernel. The snag in this plan was that rpm refused to install the kernel on a 586 because it checked the arch. Dave sought opinions on whether making the 686 kernel an i386 package was a good idea. All sorts of disagreement resulted. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02167.html SethVidal was sure that yum was going to choke[2] on this change, and Dave supplied[3] the alternatives of either undoing the change, or else leaving what he thought was a small number of 586 users to look after themselves. [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02170.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02173.html Although there were several objectors including PeteZaitcev (citing a VIA C3), DennisGilmore (who wanted a 586 kernel for a Soekris board), and BenLewis, one of the strongest was AlanCox. Alan had multiple grounds for objection. The first[4] was that there was no reasonable basis to suppose that there were so few 586 users, and it turned out that Dave's estimate was based on information gathered with smolt. DavidMacKay gave[5] a concrete example of how smolt would not have reported an install he had just completed on a firewall/router. [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02218.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02265.html Alan also stated that if he were left without a 586 kernel build then he'd probably just change distros because that would avoid the maintenance nightmare of maintaining two distros on his machines. A brief, but sharp exchange[6] followed in which DaveJones characterized Alan's objection as "''teddy throwing''" and in turn was accused of name-calling. [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02198.html A suggestion[7] from MikeChambers that simply changing the architecture name to e.g. "x86" might solve the problem was admitted[8] as technically feasible by JeremyKatz (once a were added to yum, rpm etc) but BillNottingham pointed out[9] that the change would have to be propagated for ever. [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02200.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02201.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02203.html Going straight to the root of the problem[10], BillNottingham wanted to patch RPM. (In an aside DaveJones noted the complexity of the RPM code maintained by PaulNasrat and KevinKofler thanked[11] PanuMatilainen for all the RPM work he and Paul had been doing.) [10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02187.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02211.html AlanCox explained[12] that RPM was indeed the source of the trouble, as it had been hacked way back in the day to get around a GCC error. The result was that RPM thinks that "''686 + cmov''" is 686 and "''686 - cmov''" is 586. Alan suggested "''fix gcc and you can fix rpm and you get back to the world as intended''". [12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02196.html Further discussion between DaveJones and Alan seemed to result in an impasse[13] [13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02199.html === x86_64 Live Media Is NOT A LiveCD === After unsuccesful attempts to create an x86_64 "LiveCD" image, "eah" asked[1] why it was larger than the x86 image. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01973.html JesseKeating made the correction[2] that it was NOT a LiveCD, but Live Media, and was larger because of multilib. Jesse suggested putting the Live Media image on a USB key or DVD. In response MichaelWeiner[3] and TillMaas[4] thought that the name should be changed to something less confusing. [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01975.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01976.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02094.html "eah" asked how k3b could be persuaded to burn the image to a DVD instead of the CD-R which it preferred by default and was given[5] helpful instructions by ManuelWolfshant. [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01983.html An interesting response from KevinKofler suggested[6] that it might be possible to cram the 800MB onto a CD-R if "Mode 2"[7] were chosen instead of the normal "Mode 1" [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01985.html [7] http://www.mscience.com/faq62.html === PAM_KEYRING Gets GDM And KDM Into Bed === The release of an updated PAM_KEYRING by JonNettleton was reported[1] by DenisLeroy to fix problems he had experienced in F7. PAM_KEYRING is a module that makes ''gnome_keyring'' more accessible by other programs and removes the inconvenience of having to unlock one's keyring immediately after logging-in to the desktop. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01902.html Denis was also seeking to start a wider discussion of how to avoid having to manually edit ''/etc/pam.d/gdm'' in order to reap the full benefits of PAM_KEYRING. One possibility was to use a %post scriptlet and KevinKofler expanded[2] the scope of the problem by pointing out that gnome_keyring was also used by programs running under KDM. JonNettleton had already coded[3] an addition to ''authconfig'' to modify /etc/pam.d/gdm but was intrigued[4] by KevinKofler's report of such risque mixed-desktop carry-on and agreed that if authconfig were modified to integrate these changes then the sensibilities of KDE users would need to be considered. [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01906.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01907.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01908.html A fairly strong opinion against using %post scriptlets to edit the pam config files was expressed[5] by JeremyKatz and SethVidal. BillNottingham backed[6] the idea of modifying authconfig as suggested by Jon and others. [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02017.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02024.html === F8: Review Hiding Partitions With HAL === OttoRey wondered[1] why the default HAL policy for hiding fixed drives was needed. Otto suggested that if the purpose was to provide security then a better approach would be to use ACLs. RichardHughes was in agreement and argued[2] that the policy should be used for RHEL only, noting in passing that any system bootable from a LiveCD was insecure and that DavidZeuthen's PolicyKit would hopefully solve all this. (David had posted back in March, within a thread about HAL policies[3], about the work he was doing on this.) [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01927.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01928.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-March/msg01019.html Pining for the good old days, KevinKofler suggested[4] that ''/etc/fstab'' was the appropriate place to let the system know about the mounting of fixed disk partitions. NicolasMailhot agreed[5] that there was wonkiness with the current system (three places where a mount can be set up), and JefSpaleta, while dreaming of Utopia, thought[6] that in the present reality an editable ''/etc/fstab'' was necessary. [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01935.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01939.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01938.html === Bugzilla: "FedoraCore" And "FedoraExtras" Products Merged to "Fedora" === An announcement[1] of the result of a lot of hard work completing the Core/Extras merge in bugzilla was posted by ToshioKuratomi. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02092.html Toshio noted that one of the effects might be that some previous package owners would now be listed as co-owners and he provided a way to check with CVS. This led JoshBoyer to jokingly ask Toshio to stop living in the cvs past, which led to a more serious discussion with TillMaas about how the wiki is outdated[2]. Josh and Till both updated some of the information. [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02096.html == Maintainers == In this section, we cover Fedora Maintainers, the group of people who maintain the software packages in Fedora https://www.redhat.com/mailman/listinfo/fedora-maintainers Contributing Writer: MichaelLarabel === Libraw1394 Notice For F7 Xen Users === JochenSchmitt alerted users[1] in the fedora-maintainers-list this week about the libraw1394 update in Fedora 7. This package requires the 2.6.21-1.3194.fc7 kernel or later, but in the case of Xen it's currently at version 2.6.20-2925.9.fc7. Fortunately, however, the libraw1394 package maintainer can push out an update that solves this problem and JesseKeating is working with the respective maintainers. [1] https://www.redhat.com/archives/fedora-maintainers/2007-June/msg00563.html === Portaudio & SDL_gfx Updates === Version 19 of Portaudio[1] has entered Fedora 7. Portaudio, an open-source cross-platform audio API, breaks ABI compatibility in this new stable version, but the Fedora espeak package that depends upon portaudio is being updated accordingly. MatthiasSaou has also updated SDL_gfx to version 2.0.16[2]. [1] https://www.redhat.com/archives/fedora-maintainers/2007-June/msg00599.html [2] https://www.redhat.com/archives/fedora-maintainers/2007-June/msg00601.html == Documentation == In this section, we cover the Fedora Documentation Project. http://fedoraproject.org/wiki/DocsProject Contributing Writer: JonathanRoberts === New POTBASE definition === PaulFrields writes to the docs-list to announce that he's updated Makefile.common, with a capacity for a new "POTBASE" variable. This is useful in the event that the POT file for a module needs to be named differently to ${DOCBASE}, making it easier for the L10N team to do their work[1]. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00110.html === Candidate Documentation Schedule === A candidate schedule for the Docs Project was posted to the wiki[1], and announced on the list[2] with an invitation for comments included. Significant in this announcement was the fact that there is about 6 weeks left to gather information for the first one sheet release notes that accompanies the first testing release. No information was included in this about deadlines for guides[3], which was intentional to encourage debate about the release schedule for guides[4], as a re-organisation of this is being considered. [1] http://fedoraproject.org/wiki/DocsProject/Schedule/8 [2] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00112.html [3] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00113.html [4] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00117.html === Why Write Documentation === JohnBabich posted a link to a set of results from an interesting survey carried out by O'Reilly, asking people why they write FOSS documentation[1]. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00124.html === Fedora Documentation Steering Committee Meeting === A summary of the FDSCo meeting of the 12th June was posted to the docs-list[1]. The log was also posted separately[2]. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00125.html [2] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00136.html === Tool Help === KarstenWade posted a request for help to the docs-list with re-enabling language auto-selection of the release notes, requiring changes to the Makefile[1]. This feature is being re-enabled as a bug in Firefox preventing this has been fixed. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00133.html === Tasks! === The DocsProject's tasks page[1] has been updated with a list of links to different stub pages for each of the tasks that needs achieving[2]. It is hoped that guide writers will fill out these pages with 3-10 tasks, this way new contributors can easily identify what needs doing and jump straight in. If you're interested in helping with the DocsProject, this is a great place to start. [1] http://fedoraproject.org/wiki/DocsProject/Tasks [2] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00141.html As part of organising the tasks, it has also been suggested that the DocsProject team works on one guide at a time, with a proposed order sent to the list by KarstenWade[1]. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00152.html === Starting DocBook XML === A lot of the DocsProject's documents are kept in CVS in the DocBook XML format, which can be a hurdle to contributing. If you're interested in starting on the documentation project but have been put off by this, PaulFrields has sent a message to the docs-list that is for you[1]. In it, he explains the best resources to get you started, and invites anyone with any further questions, or suggestions on how this document could be improved, to send a message to the list. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00162.html == Documentation == In this section, we cover the Fedora Documentation Project. http://fedoraproject.org/wiki/DocsProject Contributing Writer: JonathanRoberts === New POTBASE definition === PaulFrields writes to the docs-list to announce that he's updated Makefile.common, with a capacity for a new "POTBASE" variable. This is useful in the event that the POT file for a module needs to be named differently to ${DOCBASE}, making it easier for the L10N team to do their work[1]. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00110.html === Candidate Documentation Schedule === A candidate schedule for the Docs Project was posted to the wiki[1], and announced on the list[2] with an invitation for comments included. Significant in this announcement was the fact that there is about 6 weeks left to gather information for the first one sheet release notes that accompanies the first testing release. No information was included in this about deadlines for guides[3], which was intentional to encourage debate about the release schedule for guides[4], as a re-organisation of this is being considered. [1] http://fedoraproject.org/wiki/DocsProject/Schedule/8 [2] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00112.html [3] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00113.html [4] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00117.html === Why Write Documentation === JohnBabich posted a link to a set of results from an interesting survey carried out by O'Reilly, asking people why they write FOSS documentation[1]. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00124.html === Fedora Documentation Steering Committee Meeting === A summary of the FDSCo meeting of the 12th June was posted to the docs-list[1]. The log was also posted separately[2]. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00125.html [2] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00136.html === Tool Help === KarstenWade posted a request for help to the docs-list with re-enabling language auto-selection of the release notes, requiring changes to the Makefile[1]. This feature is being re-enabled as a bug in Firefox preventing this has been fixed. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00133.html === Tasks! === The DocsProject's tasks page[1] has been updated with a list of links to different stub pages for each of the tasks that needs achieving[2]. It is hoped that guide writers will fill out these pages with 3-10 tasks, this way new contributors can easily identify what needs doing and jump straight in. If you're interested in helping with the DocsProject, this is a great place to start. [1] http://fedoraproject.org/wiki/DocsProject/Tasks [2] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00141.html As part of organising the tasks, it has also been suggested that the DocsProject team works on one guide at a time, with a proposed order sent to the list by KarstenWade[1]. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00152.html === Starting DocBook XML === A lot of the DocsProject's documents are kept in CVS in the DocBook XML format, which can be a hurdle to contributing. If you're interested in starting on the documentation project but have been put off by this, PaulFrields has sent a message to the docs-list that is for you[1]. In it, he explains the best resources to get you started, and invites anyone with any further questions, or suggestions on how this document could be improved, to send a message to the list. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00162.html == Infrastructure == In this section, we cover the Fedora Infrastructure Project. http://fedoraproject.org/wiki/Infrastructure Contributing Writer: JasonMatthewTaylor === IPTables === The Infrastructure team, specifically LukeMacken, SethVidal and xDamonx completed work on an IPtables[1] firewall solution for the fedora project. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg002… === Fedora SCM === MikeMcGrath started discussion[1] this week about whether or not to keep current configuration management or look into something different. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg002… === Ticket System === SethVidal, after pondering it for a bit had some comments[1] about the current ticket system [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg003… === Making Infrastructure Requests === A long discussion came from a request for resources (RFR) for Fedora Magazine[1]. MikeMcGrath noted[2] that the long discussion was a good experience for all; he is watching out for time drains on the Infrastructure team, and wants to sure of incoming ideas/requests. [1] http://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg0023… [2] http://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg0030… == Artwork == In this section, we cover Fedora Artwork Project. http://fedoraproject.org/wiki/Artwork Contributing Writer: JonathanRoberts === Echo Icon Theme Development === Work has now restarted on Echo icons. The latest icon to be added is the gnome-palm icon, and was well received[1]. Also this week with Echo, a small fix was suggested to the quick-add icon to make it symmetrical[2]. [1] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00175.html [2] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00174.html === Banners === A request was sent in to the list asking where you can find the source files for the banners, as features on various wiki pages[1]. It was pointed out that it is available on the Art Team's design page[2], and, after a request was then made for a banner for the newly planned Fedora Magazine, it was pointed out that there is also a request form available on this site[3]. A few banner designs were provided, however[3] [4]. [1] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00176.html [2] http://fedoraproject.org/wiki/Artwork/DesignService [3] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00181.html [4] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00184.html == Daily Package == In this section, we recap the packages that have been highlighted as a Fedora Daily Package. http://dailypackage.fedorabook.com Contributing Writer: ChrisTyler === ISO Master - CD/DVD Image Editor === ''Productive Mondays'' highlight a timesaving tool. This Monday[1] we covered ISO Master[2]: "ISO Master is a graphical tool for editing ISO image files. It presents a two-pane view of your local filesystem (top) and an ISO image (bottom) and enables you to move files between the two. You can also delete files from the ISO image, create new directories, and add a boot record. Isomaster will constantly update the image size estimate; when you're ready, hit File>Save As and a new image file will be created." [1] http://dailypackage.fedorabook.com/index.php?/archives/72-Productive-Monday… [2] http://littlesvr.ca/isomaster === QIV - Quick Image Viewer === ''Artsy Tuesdays'' highlight a graphics, video, or sound application. This Tuesday[1] Qiv[2] was featured: "Qiv is a quick image viewer. The name says it all: qiv displays images quickly and simply. But it is also capable of running slideshows, selectively deleting images, zooming, adjusting brightness/contrast/gamma, setting the root window image, and more. Qiv is perfect for displaying images from a shell script, creating a slideshow quickly, or reviewing a large batch of images." [1] http://dailypackage.fedorabook.com/index.php?/archives/73-Artsy-Tuesday-Qiv… [2] http://www.klografx.net/qiv === The Skeleton === The ''Wednesday Why'' article[1] was on the Fedora skeleton[2]: "Your Fedora system has a skeleton in its closet! Well, actually, it's in the /etc directory. /etc/skel is a directory that contains files which are copied to the home directory of each new user." [1] http://dailypackage.fedorabook.com/index.php?/archives/74-Wednesday-Why-The… === Cssed - CSS Editor === ''GUI Thursdays'' highlight a software that provides, enhances, or effectively uses a GUI interface. This Thursday[1], Cssed[2] was discussed: "Editing cascading style sheet files (CSS) can be a huge chore. Cssed is a text editor for CSS files. It includes on-line references, syntax highlighting, and auto-completion." [1] http://dailypackage.fedorabook.com/index.php?/archives/75-GUI-Thursday-Csse… [2] http://cssed.sourceforge.net/ === Fortune - Random Wit & Wisdom === ''Friday Fun'' highlights fun, interesting, and amusing programs. This Friday[1] covered fortune-mod[2]: "For years, many Unix and Linux systems have greeted text-mode users with a piece of random wisdom or wit each time they log in. This daily smile is provided by the fortune program, which is in the fortune-mod package." [1] http://dailypackage.fedorabook.com/index.php?/archives/76-Friday-Fun-Fortun… [2] http://www.redellipse.net/code/fortune == Advisories and Updates == In this section, we cover Secuirity Advisories and Package Updates from fedora-package-announce. Contributing Writer: ThomasChung === Fedora 7 Security Advisories === * 2007-06-21 [SECURITY] fail2ban-0.8.0-9.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0621 * 2007-06-20 [SECURITY] denyhosts-2.6-5.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0589 * 2007-06-18 [SECURITY] iscsi-initiator-utils-6.2.0.865-0.0.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0543 * 2007-06-18 [SECURITY] thunderbird-2.0.0.4-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0544 === Fedora Core 6 Security Advisories === * 2007-06-18 [SECURITY] freetype-2.2.1-17.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-561 == 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 meeting === Fedora Documentation Steering Committee (Log) 2007-06-19 === * https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00136.html === Fedora Engineering Steering Committee Meeting 2007-06-21 === * https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02273.html === Fedora Infrastructure Meeting (Log) 2007-06-21 === * https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg003… === Fedora Packaging Committee Meeting 2007-06-19 === * https://www.redhat.com/archives/fedora-maintainers/2007-June/msg00663.html === Fedora Release Engineering Meeting 2007-06-18 === * https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02114.html === Fedora Translation Project Meeting 2007-06-19 === * https://www.redhat.com/archives/fedora-trans-list/2007-June/msg00137.html == Feedback == This document is maintained by the Fedora News Team[1]. Please feel free to contact us to give your feedback. If you'd like to contribute to a future issue of the Fedora Weekly News, please see the Join[2] page to find out how to help. [1] http://fedoraproject.org/wiki/NewsProject [2] http://fedoraproject.org/wiki/NewsProject/Join -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung

1 0

Fedora Weekly News Issue 92
by Thomas Chung 18 Jun '07

18 Jun '07

= Fedora Weekly News Issue 92 = Welcome to Fedora Weekly News Issue 92[1] for the week of June 10th through June 16th, 2007. The latest issue can always be found here[2] and RSS Feed can be found here[3]. [1] http://fedoraproject.org/wiki/FWN/Issue92 [2] http://fedoraproject.org/wiki/FWN/LatestIssue [3] http://feeds.feedburner.com/fwn 1. Announcements 1. Reminder - Fedora Core 5 EOL on 2007-06-29 2. Fedora-Devel-Announce is Now Open 3. Fedora Board Elections 2. Planet Fedora 1. Working on Fedora L10n 2. End of "I didn't know about that change!?!" for Fedora devel (?) 3. Workaround for kernel panic on suspend/resume 3. Marketing 1. Magazine Fedora 7 (France) 2. Fedora 7 Xen First Look 3. Maximum PC reviews Fedora 7 4. Developments 1. Guidelineism Defeated By Glorious Benefit Of Action 2. Cross-building Bliss 3. Yelping Over Bloated Firefox And Flash 4. The Updates Firehose 5. Pay Per Spin Web Interface? 6. Secondary Arch Proposal Cont. 7. F8 Devel - User Storage Configurations 8. R500 Initial Driver Release 5. Documentation 1. docs.fedoraproject.org Stats 2. SELinux 3. Documentation Project Steering Committee Meeting 4. Summer Of Code 6. Translation 1. Meeting Times 2. Monitoring Commits 7. Infrastructure 1. Security Updates 2. Escalation Paths/Methods 8. Artwork 1. Fedora 8 Theme 9. Security Week 1. Fedora Security Response Team 10. Advisories and Updates 1. Fedora 7 Security Advisories 2. Fedora Core 6 Security Advisories 11. Events and Meetings 1. Fedora Board Meeting Minutes 2007-06-12 2. Fedora Documentation Steering Committee 2007-06-12 3. Fedora Engineering Steering Committee Meeting 2007-06-14 4. Fedora Infrastructure Meeting 2007-06-14 5. Fedora Indian Ambassadors Meeting Minutes 2007-06-13 6. Fedora Packaging Committee Meeting 2007-06-12 7. Fedora Release Engineering Meeting 2007-06-11 12. Extras Extras 1. An interview with Fedora leader Max Spevack 2. Thomas Chung gives Fedora Talk at Caltech 13. Feedback == Announcements == In this section, we cover announcements from various projects. Contributing Writer: ThomasChung === Reminder - Fedora Core 5 EOL on 2007-06-29 === MaxSpevack announces in fedora-announce-list[1], "As many of you are aware, our policy on the lifecycles of Fedora releases is: Fedora X will be maintained until about one month after Fedora X+2. Fedora 7 was released on May 31st. Fedora Core 5 will reach its End of Life on Friday June 29th. This was previously mentioned on fedora-announce-list on May 3rd[2], but is worth repeating." [1] https://www.redhat.com/archives/fedora-announce-list/2007-June/msg00006.html [2] https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00000.html === Fedora-Devel-Announce is Now Open === WarrenTogami announces in fedora-announce-list[1], "fedora-devel-announce list[2] is now open. The goal of this list is to make it easy for Fedora contributors to follow changes in that may be pertinent to developers within the Fedora Project. This is intended to be a LOW TRAFFIC announce-only list of development topics, so we hope subscribers wont feel the need to filter it away from their Inbox." [1] https://www.redhat.com/archives/fedora-announce-list/2007-June/msg00005.html [2] https://www.redhat.com/mailman/listinfo/fedora-devel-announce === Fedora Board Elections === MaxSpevack announces in fedora-announce-list[1], "We are due for our first round of Fedora Board elections. There have been some threads recently on fedora-advisory-board that have been working to clarify what the Board's role should be as it goes into its next term. Those who have not seen that thread may want to look at[2]." "The Fedora Board continues to serve as the top-level decision making body within Fedora. One of the challenges that the "new" Fedora Board will face is doing a better job of making sure that the Fedora Board appropriately manages the rest of the Fedora community, and also Fedora's interaction with the larger Red Hat engineering, legal, etc. groups." [1] https://www.redhat.com/archives/fedora-announce-list/2007-June/msg00004.html [2] https://www.redhat.com/archives/fedora-advisory-board/2007-June/msg00022.ht… == Planet Fedora == In this section, we cover a highlight of Planet Fedora - an aggregation of blogs from world wide Fedora contributors. http://fedoraproject.org/wiki/Planet Contributing Writers: ThomasChung === Working on Fedora L10n === DimitrisGlezos points out in his blog[1], "In the last few days I've been working on Fedora's L10n infrastructure. Not all of it was exciting, but we really need to increase the quality of our international desktops. Why? Well, for start, Lord Smolt informs that 3 out of 10 registered systems are non-English, and I estimate another 2/10 of the en_US have localized desktop sessions (so that users won't be facing encoding problems on the command-line)..." "...And finally, we are building an exciting new front-end to L10n, to replace the rusty i18n.redhat one. Besides translation statistics, it presents i18n errors of the module and urges people to code using the standard libraries, which increase interoperability. It also supports Subversion, Mercurial, and GIT repos. You can give it a spin at the testing system we've put up[2]." [1] http://dimitris.glezos.com/weblog/2007/06/14/working-on-flp/ [2] http://publictest4.fedora.redhat.com/ === End of "I didn't know about that change!?!" for Fedora development (?) === KarstenWade points out in his blog[1], "Yes, my subject is quite certain that maybe possibly it could be the end of some of the squabbling and misunderstandings amongst Fedora's developers and packagers. Because I have so much trust in my fellow humans, I can say with something almost like sureness that we'll see this problem addressed ... in our lifetime ..." "But anyway, Warren Togami announced a good step in the right direction: Fedora-Devel-Announce is Now Open. Go subscribe. Especially if you have ever missed a small or large change in Fedora development that mattered to you. If this list[2] fails to announce something in the future, just think of all the ground for grievance you'll have!" [1] http://iquaid.livejournal.com/20071.html [2] https://www.redhat.com/mailman/listinfo/fedora-devel-announce === Workaround for kernel panic on suspend/resume === RolandWolters points out in his blog[1], "One of the biggest disadvantages of Fedora 7 for me was that my Suspend to RAM[2] suddenly stoppped working: the kernel crashed on resume and left me with a kernel panic. I filled bug 241700 but was only forwarded to the HAL Quirk Site which does feature suspend problems in a very user friendly way. But although that page has a lot of helpful tips it does not cover kernel crashes." After that I re-added the removed kernel modules bit by bit and checked resume each time. It turned out the broken module is fw_ohci, the Firewire Open Host Controller Interface. If you also have a kernel panic on resume you can check for yourself if this module is the reason: remove it by modprobe -r -v --first-time fw_ohci ("r" is for remove, "v" is for verbose and "first-time" make the process exit by error if the module was not loaded in the first place). After that, suspend the machine and try to resume." [1] http://liquidat.wordpress.com/2007/06/13/howto-workaround-for-kernel-panic-… [2] http://liquidat.wordpress.com/2007/02/09/computer-suspend-it-is-working/ == Marketing == In this section, we cover Fedora Marketing Project. http://fedoraproject.org/wiki/Marketing Contributing Writer: ThomasChung === Magazine Fedora 7 (France) === PierreYvesChibon reports in fedora-marketing-list[1], "As a member of the French Fedora ambassador team, I am proud to announce you the future release of an entirely magazine dedicated Fedora 7. The announce of the release of the magazine is available here[2]. The magazine will be published in France for 9,95€, it contains 2 DVDs (i386 & x86_64)." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00121.ht… [2] http://www.linuxidentity.com/html/index.php?name=News&file=article&sid=11 === Fedora 7 Xen First Look === RahulSundaram reports in fedora-marketing-list[1], "Overall, the tools for Xen management are coming along quite nicely, actually developing a bit faster than I expected, and Fedora 7 is a great place to try them out. They will certainly ease Xen management (and other virtualization technologies on Linux, for that matter) in the future and I look forward to taking advantage of them when they make their way into RHEL 5.1.[2]" [1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00118.ht… [2] http://enterpriselinuxlog.blogs.techtarget.com/2007/06/07/fedora-7-xen-firs… === Maximum PC reviews Fedora 7 === RahulSundaram reports in fedora-marketing-list[1], "If you love Red Hat, it goes without saying that you're bound to go nuts over Fedora 7. But this distro is also worth a look for just about anyone who wants to try Linux for the first time. With a noob-friendly installation routine and simple customization menus that make daily use a breeze, we're glad Fedora 7 has thrown its hat into the ring.[2]" [1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00117.ht… [2] http://www.maximumpc.com/article/fedora_7_rivals_ubuntus_ease_of_use == Developments == In this section, we cover the problems/solutions, people/personalities, and ups/downs of the endless discussions on Fedora Developments. http://www.redhat.com/mailman/listinfo/fedora-devel-list Contributing Writer: OisinFeeley === Guidelineism Defeated By Glorious Benefit Of Action === HansRosbach noticed[1] something that had been commented on before[2]: the dependence of GRUB on fedora-logos, which in turn depends on gtk2, which in turn depends on a whole pile of Xlib stuff. Hans wanted to know why all this was required for a boot menu, when it wasn't required in FC4 to FC6, and also thought that the dependencies were in the wrong order anyway. RahulSundaram answered[3] that this had been discussed before and explained that fedora-logos was a single package of trademarked images and logos for legal reasons. This makes it simpler for derivative distributions to remove all Fedora trademarked material. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01823.html [2] http://fedoraproject.org/wiki/FWN/Issue91#head-ce92d2e708b4bfabf99accc5c34b… [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01831.html After examining the link supplied by Rahul, AxelThimm suggested[4] that one of two things should happen: 1. the guideline that a package must require application directories into which it may drop files should be relaxed for fedora-logos or it should be made a co-owner of those application directories; 2. a sub-package containing a minimalist set of files for GRUB's splash screen should be created. Axel proposed that he could ask the Packaging Committee to relax the guideline and asked which of the options was best. He also thought that "We can't allow blind guideline-ism to create such awkward situations where simply booting the system requires gtk!" [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01836.html The second option was impractical according[5] to MatthiasClasen because "legal" specifically wanted a single-package of trademarked images, BillNottingham later clarified[6] that this specifically meant logos and logotype, but not themes and icons. This was news to KevinKofler who was able to show[7] that the Fedora logo was in redhat-artwork and redhat-artwork-kde. Bill requested Kevin to file a bug asking for logo.png to be moved into fedora-logos. [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01843.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01858.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01847.html Hot on the heels of this discussion thhe maintainer AdamJackson (ajax) posted[8] promptly to say that he had implemented option 1 in rawhide with fedora-logos no longer requiring anything and co-owning the directories into which it drops files. He cautioned that this was likely to break respins. [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01904.html === Cross-building Bliss === Continuing the discussion of cross-compilation started last week[1], BrendanConoboy expanded[2] upon what he saw as the main technical and social issues which needed to be resolved. Brendan noted the ability of gcc and binutils to use sys-roots and necessity to extend the build system (e.g. Koji), and the need to modify individual packages to support cross-compilation. [1] http://fedoraproject.org/wiki/FWN/Issue91#head-db39d837890b30155e2f18a185e0… [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01192.html Picking up on the central chicken-and-egg problem of how to get a glibc for a new architecture, DavidWoodhouse argued[3] that the current "solution" was a problem because it didn't separate gcc and glibc. Brendan suggested limiting the discussion to the current architectures which led to David identifying[5] that one classification of the problem saw it break down into the distinct subproblems of building (which was relatively soluble), and packaging (which was more restricted and inflexible and needed multiple rpmbuilds currently). Brendan outlined[6] three possible SRPMS: 1) a single bloated master package for all possible targets; 2) a smaller number of single SRPMS for multiple targets grouped for technical reasons; and 3)HansdeGoede's solution of a single SRPM for a specific single architecture/target. [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01214.html [4] http://people.redhat.com/drepper/dsohowto.pdf [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01607.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01675.html RalfCorsepius definitely favored[7] avoiding option #1 and pointed out that while #3 had a downside in that it bloated repositories it was what he was currently doing succesfully. AndyGreen thought[8] that #1 was the Holy Grail as it led to a single point of control, reducing the loss of information which would occur in multiple specfiles. An exchange between Andy and HansdeGoede brought out[9] an important distinction between Fedora-to-Fedora crosses versus Fedora-to-CompletelyOtherOS crosses (Hans was dealing with 256B RAM !). [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01676.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01677.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01687.html This distinction was also made[10] by Hans after Ralf and David seemed to be talking at cross-purposes, with David wanting to avoid pandering to architectures which didn't work with the current toolchain and yet hadn't worked to get the toolchain fixed upstream. David had earlier referenced JakubJelinek's succesful approach to the kernel as a model for how to deal with this human aspect of the problem. Hans pointed out that what he and Ralf were doing was to produce specific executables stored on removable media and targetted at an onboard OS. Hans particular expertise is with the gp2x[11a]. David accepted the distinction and Ralf explained[11] that he was interested in a slightly broader problem which involved the RTEMS[12] embedded OS both as a target in its own right and also in the problem of making a Canadian-cross of RTEMs on Fedora targetted to other important OSes. [10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01683.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01689.html [11a] http://en.wikipedia.org/wiki/GP2X [12] http://www.rtems.com/ As the spotlight was focused on him Hans naturally took the opportunity to ask[13] why there hadn't been more feedback on his arm-gp2x review tickets. Ralf responded that glibc was not familiar to him, but that he was concerned with the use of a bootstrap in the specfile. This prompted[14] Brendan to admit that this was one of DavidWoodhouse's central points and that it was indeed the only current way. A detailed discussion between Ralf and Brendan seemed to result in consensus[15] that some means of extending rpm to separate out target/foreign-arch packages from the host/native rpmdb was needed. Ralf proposed[16] a second, completely isolated rpmdb for the target arch, which he surmised would be like the way mock and mach used chroots. Brendan concurred[17] that "leveraging mock is going to a key to cross building bliss." [13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01678.html [14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01709.html [15] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01811.html [16] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01742.html [17] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01911.html AndyGreen exposed[18] the problem that BuildRequires: in a specfile being used for cross-compilation will conflate requirements for both the host and the target and proposed that rpmbuild be enhanced to deal with this case. DavidSmith's experience[19] was that the problem was actually worse and had needed some conditional architecture testing in BuildPrerequires. Ralf drew further details of this solution from David[20] and ClarkWilliams[21] with regard to the ability of rpm to install rpms with foreign/non-host architecture to a specific rpmroot. [18] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01816.html [19] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01841.html [20] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01861.html [21] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01883.html In a later branch of the discussion AndyGreen raised[22] the forking of RPM which has taken place as an opportunity to implement these changes to how BuildRequires should be handled for cross-compilation. [22] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01921.html AndyGreen clarified[23] to OliverFalk that while cross-compiled packages might need to be tested on native hardware, the actual compilation should work. LennertBuytenhek wasn't so sure[24], citing the possibility that the binaries, although functionally equivalent, might not be identical. [23] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01478.html [24] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01637.html === Yelping Over Bloated Firefox And Flash === A confused[1] HansdeGoede wondered why he had received conflicting comments on packages he maintains about whether the help-viewer "Yelp" should be made a Requires: or not. Hans' personal opinion was that it should be as otherwise the packages lacked basic functionality without even throwing an error. ChristopherAillon thought[2] that Yelp should be required once by base gnome and not in each of the hundreds of individual gnome packages. VilleSkyttä pointed[3] to the bloated chain of dependencies (including Firefox) that requiring yelp entailed and said this was a general trend of GNOME. Christopher agreed and pointed[4] to possible future dependencies on nspluginwrapper and Xulrunner. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01337.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01338.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01347.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01417.html BillNottingham suggested that surely this was a function call in a common gnome library, leading ToshioKuratomi (who also had an affected package) to spend some time tracing[5] the chain of calls and suggest that libgnomeui should require HelpBrowser or DocbookXMLViewer which would be virtual provides in yelp. RayStrode discovered that there was a gnome_help mechanism to put up a dialog warning that help was missing and wondered[6] if help could be thought of as an optional feature. This was attractive to BernardoInnocenti (who thought the removal of help would benefit OLPC in size reduction), but not favored by Bill (who thought that the solution was to make the viewer less bloated), or Toshio (who thought that program help was a different category than man pages or README files). [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01471.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01522.html Ray's news about gnome-help was welcomed by Toshio, who also noted[7] that yelp was selected as the help view by means of Gconf key, which seemed to bear out[8] a horrified BillNottingham's joke that rpm would need to dynamically compose requires from the union of all users' gconf keys. [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01537.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01538.html A brief digression[9] into the bizarre American penchant for mixing up the natural date order landed explanations from AlanCox[10] on the rationale behind this and from CaolanMcNamara[11] on how to change the order in OOimpress. [9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01545.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01600.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01580.html ColinWalters thought[12] the GConf key could just be ignored and unwittingly touched-off a flamewar when he wondered whether anyone would really miss help. ChristopherAillon advanced[13] the argument that the real problem was not to do with yelp, but with the provision of a firefox-32 package against his wishes. This apparently[14] provides an icon which runs a 32-bit Firefox installed on a x86_64 system to view Flash plugin content. Christopher was annoyed that his recommendations had been over ridden. [12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01544.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01563.html [14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01597.html An attempt by MattMiller to draw a distinction between an opinion mattering versus being completely authoritative revealed[15] the depth of Christopher's frustration. He pointed to the difficult legal requirements that made his life hell and threatened[16] to leave the project leaving Fedora with Iceweasel and no maintainer. [15] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01598.html [16] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01605.html WarrenTogami responded[17] with the argument that the problem was nothing to do with firefox-32, and that an earlier conflict had been arbitrated through engineering management in Warren's favor and that Christopher's characterization was "FUD with a few outright lies sprinkled within." Warren argued that the script was necessary until nspluginwrapper was supported. BillNottingham thought that Warren was actually making Christopher's life harder as asserted, leading MattMiller to try to present[18] a balanced recognition that both Warren and Christopher were highly respected and experienced. [17] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01644.html [18] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01665.html At this point MatejCepl returned[19] to Hans' original query. Matej's post took responsibility for not communicating some discussion on #fedora-devel instead of RH-interal IRC, but more interestingly suggested that what was needed was the addition of soft-dependencies in packages, akin to Debians Suggests: and Recommends:. Following enquiry from JesseKeating, Matej explained[20] that a Recommends flag would indicate to yum that if a recommended package were removed then an unspecified but useful functionality would be lost. AxelThimm thought this was horribly reminiscent of some older Windows packaging "quirks" and while DominikMierzejewski (rathann) agreed[21] he also pointed out that the soon-to-arrive standalone Gecko would simplify all this. [19] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01394.html [20] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01444.html [21] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01656.html === The Updates Firehose === Noting the large number of updates JesseKeating asked[1] were they all necessary. This led to a discussion of one differentiator of Fedora from other distributions, and also to several rumblings of discontent from packagers about the imposition of more interference. BrunoWolff liked having them available but asked[2] if it was possible to have an extra categorization available so that yum could e.g. be told only to select security updates and bug-fixes but not new packages. Jesse responded[3] that LukeMacken would be implementing that and in future Pup would show a list of the notes which maintainers had inserted into bodhi. TillMaas and Luke later discussed[4] this, with Luke noting that although the yum-security plugin is present, bodhi still needs to be altered. Separately JasonTibbits and KevinKofler also discussed[4a] such functionality. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01277.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01278.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01304.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01435.html [4a] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01307.html ChristopherBlizzard asked[5] if any users were actually complaining, and pointed out that Fedora wasn't RHEL. BernardoInnocenti advanced[6] the case of multiple machines needing updates, which sparked a good subthread[7] around MattDomsch's suggestions about how to add a local private mirror to mirromanager. GianlucaSforna posted[8] a link to the GuruLabs automatic-local-mirror HOWTO, while BillNottingham preferred a yum-plugin written by RobertSpanton to allow local repository mirrors to be discovered by yum. DaxKelson pointed out that his method had the advantage of needing no modifications to the client. [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01281.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01284.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01311.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01565.html The definition of "local mirror" was raised[9] by PekkaSavola and following JakubJelinek's enquiries about the "3 mirrors per country" rule, Matt laid out[10] the changes that need to be made to improve the situation. [9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01466.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01517.html Several maintainers, including JefSpaleta, voiced[11] a desire for best-practices guidelines to help in determining when to push an update. Jef also wondered how many of the updates were due to new packages entering the tree versus bug-fixes to existing packages. Stimulated by this JesseKeating, BillNottingham and WillWoods tossed around[12] ways of gathering statistics on which installed packages were actually used, including porting Debian's popcon or modifying Mugshot. While ColinWalters and RahulSundaram considered adapting Smolt. [11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01285.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01532.html AxelThimm was generally happy with the updates and disagreed[13] with ChristopherAillon that too many changes were being backported from rawhide to F7, resulting in a lack of incentive to upgrade to F8. TillMaas and RudolfKastl also disagreed with Christopher[14] on where the line should be drawn on bugs that should be fixed with updates. Rudolf pointed out that presto would probably make the updates palatable for users and that Fedora's rapid progress was one of the reasons he used it instead of other distros. [13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01427.html [14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01567.html Echoing[15] the general happiness with the updates strategy, KevinKofler thought that the updates were Fedora's strength and differentiated it from other distros. MichaelSchwendt was skeptical[16] because of the unhappiness of users with broken apps. Rahul proposed[17] that a policy on updates be written, prompting a negative reaction from HansdeGoede[18] who requested that objective measurements be used to determine if a problem existed before any policies were written. NeilThompson was much more blunt, and worried [19] that his bowel movements would soon be regulated and that the community was being destroyed by heavy-handed bureaucracy. Responding to this MatthiasClasen deprecated[20] the language and suggested that the granularity of updates mentioned previously would allow filtering on the client side. [15] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01339.html [16] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01339.html [17] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01349.html [18] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01355.html [19] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01359.html [20] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01410.html === Pay Per Spin Web Interface? === A new forum to provide respins of Fedora called respins.org was mentioned[1] by RahulSundaram. Rahul wondered if there was a web-interface layered over pungi and livecd-tools to allow package selection and ISO generation. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01316.html NicolasMailhot wasn't too keen[2] about the bandwidth implications. Rahul argued that infrastructure had not objected, but MikeMcGrath responded[3] that Rahul hadn't given them enough information to determine how much bandwidth would be used. It seemed there was a mis-communication over which emails should have been ignored. [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01356.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01413.html SethVidal responded[4] to Nicolas that the costs of such a service would be huge and a fee-based site had been discussed to allow individuals to produce a customised spin. Seth donned asbestos underpants and pointed out that the tool would be fully open source. JonathanSteffan offered up[5] some of the Red Hat interns working on the project to take some of the flames, but for some reason they remained quiet! Jonathan also posted[6] details of the current and future state of the Revisor tool. It wasn't clear from reading this whether this is what the interns are working on. Revisor currently has a Gtk front-end, but the development work could see that replaced with anything including a web front-end. [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01429.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01442.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01441.html JeroenVanMeeuwen, also of the Revisor project, posted[7] more details including the massive number of enhancement requests they're receiving. [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01375.html === Secondary Arch Proposal Cont. === Last weeks proposal on 2ary architectures[1] by TomCallaway continued to draw comment. ChristopherBlizzard had several points to make[2], and ThorstenLeemhuis objected[3] to the first, which was that a maintainer would be responsible for making sure his/her package built on all the primary architectures. Thorsten thought this would dissuade people from being Fedora maintainers and preferred the model pioneered by DavidWoodhouse for PPC in which there would be a team/SIG which could be appealed to for help. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00463.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01792.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01829.html David thought[4] that Chris actually had the right idea and that ideally maintainers should be competent enough to fix bugs and thoroughly understand the code and preferred to sacrifice quantity to quality. David also thought that the maintainer's sponsor should have primary responsibility to help the maintainer, but also saw the value of a team which could help out. In his experience most bugs were not actually arch-specific, but were generic and just exposed on particular architectures. KevinKofler and David swapped[5] examples of such bugs. [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01838.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01840.html The question arose[6] as to whether PPC was a secondary architecture now, and David answered[7] negatively, pointing to a decision to wait until another architecure has proved the system will work. MattDomsch backed this up[8] with a link to the Jun 12 FAB minutes, while AxelThimm disputed[9] Matt's interpretation. [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01873.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01892.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01884.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01896.html === F8 Devel - User Storage Configurations === A proposal to create a single directory to hold all the dot-files created by applications to hold user settings was mooted[1] by DavidTimms. It received mainly negative responses from KDE users[2]. MatejCepl also pointed David to the work done already by the freedesktop project on basedir[3]. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01728.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01737.html [3] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.5.html === R500 Initial Driver Release === FlorianLaRoche and MikeChambers both wanted to know if the R500 drivers (for very recent ATI video cards) would be packaged for F7 or F8. AdamJackson (ajax) responded[1] that he needed to test them on their intended hardware first. Mike and AdamTkac were eager[2] to put their X1300s to the test. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01770.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01775.html Very quickly ajax posted[3] a notification of a testbuild, noting its failure on his own T60p, requirement of libpciaccess and inclusion in the next rawhide push. DavidZeuthen gave[4] quick, detailed feedback about partial success on a MacBookPro with an X1600/M56P. NathanielNoblet with an X1650[5], and MikeChambers with an X1300 had a disappointing experience and ajax emphasized[6] that he was making sure that bugs reported to him would pass upstream. [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01802.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01807.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01804.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01868.html == Documentation == In this section, we cover the Fedora Documentation Project. http://fedoraproject.org/wiki/DocsProject Contributing Writer: JonathanRoberts === docs.fedoraproject.org Stats === MikeMcGrath posted a link to the fedora-docs-list[1], pointing to the statistics for the docs.fedoraproject.org site[2]. The statistics show that, so far this month, there have been 149,219 unique visitors to the site! It was noted, however, that the number one search term was "disable selinux", leading to a discussion about the current state of the SELinux FAQ. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00069.html [2] http://fedoraproject.org/awstats/docs/awstats.docs.fedoraproject.org.html === SELinux === After reviewing the statistics for docs.fedoraproject.org, KarstenWade pointed out that there was no maintained canonical FAQ, with the top two results on Google for "disable selinux" pointing to the FC3 SELinux FAQ and the RHEL 4 SELinux FAQ[1]. As a possible solution to this it was proposed that a permanent URL on the wiki, or on the future Plone implementation, would help encourage regular updates. It was decided, however, that the FAQ should point upstream to selinuxproject.org for overall information, with Fedora specific information maintained by the Documentation Project[2]. PauloSantos stepped forward and offered to maintain this FAQ[3]. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00077.html [2] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00084.html [3] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00086.html === Documentation Project Steering Committee Meeting === The log for the 12th June meeting of the FDSCo was posted to the fedora-docs-list[1]. A HTML version is also available[2]. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00085.html [2] http://fedoraproject.org/wiki/DocsProject/SteeringCommittee/Meetings/Minute… === Summer Of Code === VillePekkaVainio posted a question to the fedora-docs-list regarding his Summer Of Code project, creating a system for publishing and editing man/info pages with MoinMoin[1]. The question revolves around the best format to store the information in, trying to strike a balance between making editing available to new users and making the edits accessible to upstream as easily integrated patches. Amit Uttam wrote to the fedora-docs-list about his Summer Of Code project, to create an elegant DocBook to PDF solution. Despite this project not being selected as an official Summer Of Code project, he still plans to develop the project[2], and as such, posted the original project proposal. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00082.html [2] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00088.html == Translation == This section, we cover the news surrounding the Fedora Translation (L10n) Project. http://fedoraproject.org/wiki/L10N Contributing Writer: JasonMatthewTaylor === Meeting Times === The Translation team is looking at different meeting times[1] to ideally get more attendance, which, in turn will help better organize and direct the project. [1] https://www.redhat.com/archives/fedora-trans-list/2007-June/msg00055.html === Monitoring Commits === For those that are so inclined, it is now possible to monitor Translation team commits[1]. [1] https://www.redhat.com/archives/fedora-trans-list/2007-June/msg00114.html == Infrastructure == In this section, we cover the Fedora Infrastructure Project. http://fedoraproject.org/wiki/Infrastructure Contributing Writer: JasonMatthewTaylor === Security Updates === DamianMyerscough noted some security concerns[1] to be addressed in the near future. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg001… === Escalation Paths/Methods === Discussion[1] has been had about how and who to notify in the event of various outages/events. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg001… == Artwork == In this section, we cover Fedora Artwork Project. http://fedoraproject.org/wiki/Artwork Contributing Writer: JonathanRoberts === Fedora 8 Theme === Following last weeks discussion about artwork for Fedora 8, this week has seen a lot of activity over the creation of a new theme for Fedora 8, with several mock-ups being created. Focus has been spread across a number of mock-ups, including MartinSourada's work[1], MairinDuffy's[2] and Mark's[3]. A lot of the information discussed in the threads has been collated into a wiki page[4], making it easily accessible. The discussion about artwork for Fedora 8 also branched out to the Fedora Forums, with a summary of the thread posted to the list[5]. [1] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00089.html [2] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00114.html [3] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00092.html [4] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00121.html [5] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00110.html == Security Week == In this section, we highlight the security stories from the week in Fedora. Contributing Writer: JoshBressers === Fedora Security Response Team === Last week was a rather slow news week as far as security news goes. The biggest news that should affect Fedora would be the fact that the Fedora Security Response Team has finally gotten off the ground. The group is currently pouring over the current list of known CVE ids to determine if we've missed any old flaws in Fedora 7. Once that's done the team will take over the constant task of parsing all the new vulnerabilities that affect Fedora 7. Anyone is welcome to help in this effort. One of the team goals is to keep things open and transparent. Anytime security work is being done, it is hard to keep the process open for a number of reasons. One of the bigger reasons is that if all the information isn't public, it can be easy to sweep certain flaws under the rug and forget about them. This is bad for any project, especially something like Fedora. If you have any interest in this group, feel free to join the mailing list[1], or stop by #fedora-security on Freenode. All are welcome, there's plenty of work to do. It's still a small team, but the current group seems to be doing a fine job. More informatoin on the team can be found on the wiki[2]. [1] http://www.redhat.com/mailman/listinfo/fedora-security-list [2] http://fedoraproject.org/wiki/Security/ResponseTeam == Advisories and Updates == In this section, we cover Secuirity Advisories and Package Updates from fedora-package-announce. Contributing Writer: ThomasChung === Fedora 7 Security Advisories === * 2007-06-16 [SECURITY] evolution-data-server-1.10.2-3.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0464 * 2007-06-16 [SECURITY] phpPgAdmin-4.1.2-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0469 * 2007-06-13 [SECURITY] kernel-2.6.21-1.3228.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0409 * 2007-06-13 [SECURITY] libexif-0.6.15-2.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0414 * 2007-06-13 [SECURITY] openoffice.org-2.2.0-14.11 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0410 * 2007-06-12 [SECURITY] spamassassin-3.2.1-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0390 * 2007-06-11 [SECURITY] mecab-0.96-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0366 * 2007-06-11 [SECURITY] perl-mecab-0.96-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0368 * 2007-06-11 [SECURITY] python-mecab-0.96-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0367 * 2007-06-11 [SECURITY] ruby-mecab-0.96-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0379 === Fedora Core 6 Security Advisories === * 2007-06-13 [SECURITY] iscsi-initiator-utils-6.2.0.865-0.0.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-590 * 2007-06-12 [SECURITY] openoffice.org-2.0.4-5.5.23 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-572 * 2007-06-12 [SECURITY] spamassassin-3.1.9-1.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-582 * 2007-06-11 [SECURITY] file-4.21-1.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-538 * 2007-06-11 [SECURITY] libexif-0.6.15-1.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-548 * 2007-06-11 [SECURITY] mod_perl-2.0.2-6.2.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-577 * 2007-06-11 [SECURITY] pam-0.99.6.2-3.22.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-546 == Events and Meetings == In this section, we cover event reports and meeting summaries from various projects. Contributing Writer: ThomasChung === Fedora Board Meeting Minutes 2007-06-12 === * https://www.redhat.com/archives/fedora-advisory-board/2007-June/msg00128.ht… === Fedora Documentation Steering Committee 2007-06-12 === * https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00125.html === Fedora Engineering Steering Committee Meeting 2007-06-14 === * https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01945.html === Fedora Infrastructure Meeting 2007-06-14 === * https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg001… === Fedora Indian Ambassadors Meeting Minutes 2007-06-13 === * https://www.redhat.com/archives/fedora-ambassadors-list/2007-June/msg00080.… === Fedora Packaging Committee Meeting 2007-06-12 === * https://www.redhat.com/archives/fedora-maintainers/2007-June/msg00506.html === Fedora Release Engineering Meeting 2007-06-11 === * https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01603.html == Extras Extras == Contributing Writer: ThomasChung === An interview with Fedora leader Max Spevack === MaxSpevack was interivewed by LWN[1]: "Now that Fedora 7 has been released, Fedora project leader Max Spevack has a little bit of breathing room. Like nature, LWN abhors a vacuum, so we sent Max a list of questions and a request for answers. We are now happy to present the answers. Without further ado..." [1] http://lwn.net/SubscriberLink/237700/f18ea8cb3b2c9745/ === Thomas Chung gives Fedora Talk at Caltech === ThomasChung gave a Fedora Presentation for San Gabriel Valley Linux Users Group at Caltech[1] on his birthday. The topic was "Fedora 7 - What's New" and Live Demo on virt-manager with KVM and Revisor. Some Fedora 7 DVDs and Fedora Stickers were also given to the group at the end of the presentation. [1] http://today.caltech.edu/calendar/item.tcl?calendar_id=75423 == Feedback == This document is maintained by the Fedora News Team[1]. Please feel free to contact us to give your feedback. If you'd like to contribute to a future issue of the Fedora Weekly News, please see the Join[2] page to find out how to help. [1] http://fedoraproject.org/wiki/NewsProject [2] http://fedoraproject.org/wiki/NewsProject/Join -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung

1 0

Reminder - Fedora Core 5 EOL on 2007-06-29
by Max Spevack 14 Jun '07

14 Jun '07

As many of you are aware, our policy on the lifecycles of Fedora releases is: "Fedora X will be maintained until about one month after Fedora X+2" Fedora 7 was released on May 31st. Fedora Core 5 will reach its End of Life on Friday June 29th. This was previously mentioned on fedora-announce-list on May 3rd, but is worth repeating. https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00000.html Thank you, Max -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21

1 0

Fedora-Devel-Announce is Now Open
by Warren Togami 13 Jun '07

13 Jun '07

https://www.redhat.com/mailman/listinfo/fedora-devel-announce fedora-devel-announce list is now open. The goal of this list is to make it easy for Fedora contributors to follow changes in that may be pertinent to developers within the Fedora Project. This is intended to be a LOW TRAFFIC announce-only list of development topics, so we hope subscribers wont feel the need to filter it away from their Inbox. Acceptable Types of Announcements ================================= * Policy or process changes that affect developers. * Infrastructure changes that affect developers. * Tools changes that affect developers. * Schedule changes * Freeze reminders Unacceptable Types of Announcements =================================== * Periodic automated reports (violates the INFREQUENT rule) * Discussion * Anything else not mentioned above Some List Details ================= * fedora-devel-announce is OPTIONAL for project contributors, although highly recommended. * In the future we will auto-subscribe new members who achieve sponsored packager status to this list. They may choose to unsubscribe themselves thereafter. * All announcements here will also be delivered to fedora-devel-list. So if you follow fedora-devel-list religiously you don't need to subscribe to fedora-devel-announce. * Replies on fedora-devel-announce go to fedora-devel-list. fedora-devel-list allows posting only to subscribed members. If you want to post but are not subscribed, you must subscribe then turn off mail delivery in the list's web interface.

1 0

Fedora Board Elections
by Max Spevack 12 Jun '07

12 Jun '07

Pardon me while I interject a little bit of governance into your day. We are due for our first round of Fedora Board elections. There have been some threads recently on fedora-advisory-board that have been working to clarify what the Board's role should be as it goes into its next term. Those who have not seen that thread may want to look at: https://www.redhat.com/archives/fedora-advisory-board/2007-June/msg00022.ht… The Fedora Board continues to serve as the top-level decision making body within Fedora. One of the challenges that the "new" Fedora Board will face is doing a better job of making sure that the Fedora Board appropriately manages the rest of the Fedora community, and also Fedora's interaction with the larger Red Hat engineering, legal, etc. groups. Pages you will want to look at: http://fedoraproject.org/wiki/Board/SuccessionPlanning http://fedoraproject.org/wiki/Board/History http://fedoraproject.org/wiki/Board/Elections http://fedoraproject.org/wiki/Board/Elections/Nominations Here is a brief *summary* of stuff that appears in more detail on those pages: * 3 of the 9 seats are open for election in this current iteration. * process is similar to other Fedora elections. * we're electing 3 of the seats for the Fedora Board this time around. * anyone who is a Fedora contributor (regardless of where they are employed) may run and vote. The nomination period will extend until 11:59 PM UTC on June 28th. Voting will begin at 12:01 AM UTC on June 29th. Voting will end at 11:59 PM UTC on July 8th. The first meeting of the new Fedora Board will be on July 10th. These dates are subject to tweaking if/as necessary. I am more interested in making sure that sufficient people have a chance to be nominated, accept (if needed) nominations, and put together their thoughts and goals than I am about tying us to a specific timeline. If it takes a week or two longer, that's worth it to have a higher quality discussion. Thank you. -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21

1 0

Fedora Weekly News Issue 91
by Thomas Chung 11 Jun '07

11 Jun '07

= Fedora Weekly News Issue 91 = Welcome to Fedora Weekly News Issue 91[1] for the week of June 3rd through June 9th, 2007. The latest issue can always be found here[2] and RSS Feed can be found here[3]. [1] http://fedoraproject.org/wiki/FWN/Issue91 [2] http://fedoraproject.org/wiki/FWN/LatestIssue [3] http://feeds.feedburner.com/fwn 1. Announcements 1. Cooperative Bug Isolation for Fedora 7 2. Planet Fedora 1. OLPC: Mesh Networking Overview in Red Hat Magazine 2. Fedora for ARM and cross compilation 3. Innovation in virtualization management tools 3. Marketing 4. Revisor utility creates custom install images for Fedora 1. Review: Fedora 7 Advances on Rivals (eweek.com) 2. Review: Fedora 7 (linux.com) 3. Review: First look at Fedora 7 (distrowatch.com) 5. Developments 1. Community Control And Documentation Of New Workflows 2. Fedora On ARM Architecture Opens Up Cross-Compilation Discussion 3. A World Of Hurt: Making F7 Install CD Set From DVD Using FC6 Pungi 4. Splitting Terminfo Out Of The ncurses RPM 5. Eliminating Unwanted RPM Dependencies And Statically-linked Binaries 6. F7 Images For Mass Production 7. Exploding Trees and SCM 8. Why Emacs Is Not Installed By Default 9. Metalink: A New Way Of Distributing Fedora ISOs? 10. Quick Notes On Update Image Installer And F8 Desiderata 6. Documentation 1. CVS Walkthrough in IRC 2. RPM Guide 3. Fedora Documentation Steering Committee Meeting 4. Fedora 7 FAQ 7. Translation 1. Bugzilla for Trans Team 8. Infrastructure 1. Backups 2. Fedora 7 Upgrade 9. Artwork 1. Fedora 8 Artwork 2. Echo Icon Theme 10. Security Week 1. Google: Attack code more likely on Microsoft IIS 2. Bruce Schneier: Department of Homeland Security Research Solicitation 11. Advisories and Updates 1. Fedora 7 Security Advisories 2. Fedora Core 6 Security Advisories 12. Events and Meetings 1. Fedora Event Help Needed: 2007 Libre Software Meeting - France 2. Fedora Event Report: LinuxTag 2007 - Germany 3. Fedora Ambassadors Meeting Minutes 2007-06-07 4. Fedora Documentation Steering Committee 2007-06-05 5. Fedora Engineering Steering Committee Meeting 2007-06-07 6. Fedora Packaging Committee Meeting 2007-06-05 7. Fedora Release Engineering Meeting 2007-06-04 13. Feedback == Announcements == In this section, we cover announcements from various projects. Contributing Writer: ThomasChung === Cooperative Bug Isolation for Fedora 7 === BenLiblit announces in fedora-announce-list[1], "The Cooperative Bug Isolation Project (CBI) is now available for Fedora 7. CBI[2] is an ongoing research effort to find and fix bugs in the real world. We distribute specially modified versions of popular open source software packages. These special versions monitor their own behavior while they run, and report back how they work (or how they fail to work) in the hands of real users like you. Even if you've never written a line of code in your life, you can help make things better for everyone simply by using our special bug-hunting packages." [1] https://www.redhat.com/archives/fedora-announce-list/2007-June/msg00001.html [2] http://www.cs.wisc.edu/cbi/ == 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 === OLPC: Mesh Networking Overview in Red Hat Magazine === ChristopherBlizzard points out in his blog[1], "Dan Williams, John Palmieri and Miguel Alvarez talk about the mesh networking in the laptop[2]. They talk about the low level connectivity bits as well as the higher level set of activities and architecture that we're building. Great job guys!" [1] http://www.0xdeadbeef.com/weblog/?p=295 [2] http://www.redhatmagazine.com/2007/06/08/inside-one-laptop-per-child-episod… === Fedora for ARM and cross compilation === AndyGreen points out in his blog[1], "It's great to see the more discussion around Fedora on embedded architectures happening over the last two weeks. To play catch up, these are the three threads I've found that matter: * Lennert Buytenhek's "fedora for ARM" thread[2]. Lennert has a Fedora build for ARM with patches ready to be merged. * Brendan Conoboy's cross-compilation thread[3]. I've worked with Brendan for years in the embedded tools and OS arena, and he definitely knows what he's talking about. * spot's Secondary Architectures thread[4] discusses proposed policies for handling secondary architectures in Fedora. The issues are many, varied and complex, but I hope something comes of this." [1] http://spindazzle.org/greenblog/index.php?/archives/67-Fedora-for-ARM-and-c… [2] http://thread.gmane.org/gmane.linux.redhat.fedora.devel/55880 [3] http://thread.gmane.org/gmane.linux.redhat.fedora.devel/56709 [4 ]http://thread.gmane.org/gmane.linux.redhat.fedora.devel/55377 === Innovation in virtualization management tools === DanielBerrange points out in his blog[1], "For the last couple of years all the hype wrt open source virtualization has been about Xen. Unfortunately after several years Xen is still not upstream in LKML, the main codebase being a huge out of tree patch persistently stuck on obsoleted kernel versions. The Xen paravirt_ops implementation is showing promise, but its a long way off being a full solution since it doesn't provide Dom0 or ia64/ppc/x86_64 yet. Then out of nowhere, 6 months ago, a newer contender arrived in the form of KVM almost immediately finding itself merged upstream. Now you can't claim to be offerring state of the art virtualization without including both KVM and Xen. We had to have KVM in Fedora 7. With excellant forsight, when working to integrate Xen in Fedora Core 5, Daniel Veillard had the idea to create a technology independant management library for virtualization platforms. This is libvirt[2]." [1] http://berrange.com/personal/diary/2007/06/innovation-in-virtualization-man… [2] http://libvirt.org/ == Marketing == In this section, we cover Fedora Marketing Project. http://fedoraproject.org/wiki/Marketing Contributing Writer: ThomasChung == Revisor utility creates custom install images for Fedora == PaulFrields reports in fedora-marketing-list1[1], "Nice to see this is getting even more traction and notice.[2]" "Imagine a customized GNU/Linux distribution, built to your specifications with a minimal amount of effort on your part. If you are running Fedora 7, that dream is now a reality, thanks to Revisor, a graphical interface for building custom install images for Fedora." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00106.ht… [2] http://enterprise.linux.com/article.pl?sid=07/06/06/2017215 === Review: Fedora 7 Advances on Rivals (eweek.com) === RahulSundaram reports in fedora-marketing-list[1], "This review[2] has focused on virt-manager, revisor and package management improvements" "In addition to the structural changes that the Fedora project has made to its software repository framework, the team has noticeably sped up the distribution's Red Hat Package Manager/Yum package management backend. Also, as we mentioned earlier, Fedora's graphical tool for creating and managing virtual machines is much improved as well. For one thing, the tool now lists idle VMs alongside running VMs, which is something that only the system's command-line tool was capable of in previous releases." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00096.ht… [2] http://www.eweek.com/article2/0,1895,2142494,00.asp === Review: Fedora 7 (linux.com) === RahulSundaram reports in fedora-marketing-list[1], "Fedora 7 was released last week, a little bit behind schedule, with a spate of new features, updates, and live CD installable "spins" of Fedora in KDE and GNOME flavors. I found a lot of good in this release, but a bug in the FireWire stack that attacked my external backup drive made this release just a little shy of perfect.[2]" [1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00094.ht… [2] http://www.linux.com/article.pl?sid=07/06/06/1327234 === Review: First look at Fedora 7 (distrowatch.com) === LuyaTshimbalanga reports in fedora-marketing-list[1], "A very positive review[2] from Distrowatch submitted by Chris Smart, Kororaa developer >From the initial boot of the installer the system exuded a sense of stability which filled me with confidence the more I used it. The installer is probably the best I have ever used and is very powerful while remaining simple to use. Top marks for that. Overall, the default GNOME install of Fedora is very good and (non-free software idiosyncrasies aside) as a Linux distribution in itself I thought it was excellent. If what you are after is a reliable, stable, easy-to-use yet powerful Linux distribution out of the box, then Fedora fits the bill nicely." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00040.ht… [2] http://distrowatch.com/weekly.php?issue=20070604#feature == 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 === Community Control And Documentation Of New Workflows === The shifting sands of power within the Fedora Project continued to cause a scramble for surer footing within a thread that started[1] last week. ThorstenLeemhuis clarified[2] to JasonTibbitts that one of the problems he perceived. Although the merge of Core/Extras was widely desired, it had happened in a confusing way that required very close attention to high-volume mailing lists, or else packagers were suddenly ignorant of the procedures to build or push. Thorsten emphasized that he did not blame FESCo, but that lots of people were unhappy with the addition of ACLs (Access Control Lists) to CVS and the sudden enabling of Koji, Bodhi, and the freeze. Pulling fewer punches, RalfCorsepius voiced[3] a suspicion that FESCo was impotent and the real decisions were made elsewhere. [1] http://fedoraproject.org/wiki/FWN/Issue90?action=show&redirect=FWN%2FLatest… [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00338.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00340.html Thorsten suggested[4] that "spare-time packagers" should have some form of representation as they tend not to get their voices heard. He also wanted to clarify the roles of the Fedora Project Board and FESCo, especially in the light of upcoming elections to FESCo. JoshBoyer responded later[5] that he needed time to respond to Thorsten's email and that silence shouldn't be taken as acquiescence on any points made in the discussion so far. JesseKeating also requested[6] that Ralf hold-off on his darker thoughts until sufficient reasonable time had elapsed for discussion. [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00345.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00373.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00375.html Responding to NicolasMailhot's earlier points about giving the Infrastructure team more credit, PatriceDumas replied[7] that it wasn't about giving or withholding credit, but trying to focus on why specific processes had been made mandatory despite some packagers' objections and preference for shortcuts. Nicolas responded[8] that while Extras had been good at packaging policy and build tools, Core had been good at release-engineering and leaving those decisions up to individual packagers would be like herding cats. Patrice thought that education rather than heavy-handed rules were the answer, but Jesse invoked[9] the weighty counter-argument of experience. [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00347.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00350.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00374.html Confessing that he felt that the F7 workflow had not been ideal, Jesse suggested a series of release-engineering meetings for anyone interested. HansdeGoede thought[10] that discontent was not necessarily due to the freeze workflow, but more likely to the absence of an updates policy and the absence of proper documentation for new tools and workflows. Jesse pleaded[11] for anyone that saw inadequate wiki pages to help out and make the changes. He also defended[12] against Hans' charge of information being hidden on @fedora-maintainers by asserting that he had tried to start a new thread for each new procedure. Jesse further expressed frustration that there were no positive suggestions for how to improve communication. [10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00379.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00386.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00389.html KevinKofler attested[13] that he just changed incorrect wiki entries when he came across them, for which Jesse thanked him and then HansdeGoede provided[14] links to pages that he believed should be edited by the people introducing changes. Hans made the argument that those introducing new tools and workflows were best placed to edit these pages, preferably before making radical changes to the workflow. Jesse responded[15] that he had been frankly unaware of the NewPackageProcess page referred to by Hans and suggested that there be a FESCo requirement that any workflow changes require a draft that includes a requirement to update the appropriate wiki pages. [13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00397.html [14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00410.html [15] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00413.html A semi-humorous suggestion[16] from HansdeGoede proposed that only those who maintained thirty or more packages should be allowed to make rules. There was general agreement that there was an issue to be addressed with rule-makers being out of touch with the majority of packagers and also a general disagreement, best expressed[17] by NigelJones, that there should be any sort of weighting of votes based on number of maintained packages. [16] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00213.html [17] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00334.html A fork of the original thread was made by JonathanUnderwood to encourage[18] people to write documentation so that the community could re-engage. JesseKeating thought this was a great idea and sought[19] someone to take on the task of co-ordination. [18] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00399.html [19] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00406.html === Fedora On ARM Architecture Opens Up Cross-Compilation Discussion === A (re)introduction[1] from LennertBuytenhek contained a brief resume of Lennert's impressive hacking history and a tantalizing glimpse of what the opening up of Fedora to other architectures could mean. The opening for architectures was originally discussed last week[2], FWN#90 "Fedora Secondary Architectures Proposal". Lennert had been maintaining ports of Fedora Core {2,3,4,6} and wanted to merge his changes back upstream. DaveJones was happy[3] with what he saw and made the suggestion that the config file shouldn't be monolithic, but should be generated out of templates, as is done currently for the Fedora kernel RPM. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00189.html [2] http://fedoraproject.org/wiki/FWN/Issue90#head-271f52b8e5603cd40d00d7c44ec8… [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00292.html As an aside TomCallaway(spot) noted[4] that SPARC-32 support was probably going to be dropped in F8, leading to some jokes about the devastation of its two users. AlanCox thought[5] that Fedora should track upstream, meaning that if it was supported in the Linux kernel trees then it should be in Fedora. However, even the fans of the architecture were unwilling to defend[6] it and pointed out that upstream were making noises about dropping it. [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00463.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00487.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00594.html Responding to DaveJones' comments, Lennert provided[7] a wealth of information about the diversity and non-similarity of ARM CPUs in the course of explaining why a kernel image RPM wasn't actually built at this point. [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00899.html Also welcoming[8] Lennert was LinusWalleij, who suggested that Lennert should open bugzilla reports for each package for which he had diffs. Linus also asked about Lennert's native build strategy as opposed to cross-compiling and his target system, something in which PeteZaitcev was also interested[9]. ManasSaksena provided specific details[10] and also added the information that, unlike other architectures, it would not be useful to produce an ISO, but instead to produce a package repository and tools to create custom root filesystems. [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00501.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00632.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00761.html HansdeGoede thought that cross-compiling seemed to be difficult unless the packages had been designed with that in mind from their inception[11]. AndyGreen had his own experience with cross-compiling for arm9 and avr to add[12], and argued that improving common packages to make cross-compiling easier would be a great advantage for Fedora. ManasSaksena agreed[13] with this and provided encouragement about the practicality of dealing with Perl and Python. KrzysztofHalasa and AndyGreen exchanged details[14] of their build procedures. [11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00505.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00509.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00762.html [14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00545.html A detailed exploration of the problems of cross-compiling, with special reference to rpmbuild, was undertaken[15] by Andy and RalfCorsepius. [15] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00783.html AdamJackson(ajax) felt that the Xorg packages looked sane and thanked[16] Lennert for his good work, while noting that the main change in migrating the packages to F7 was to change ExcludeArch from ExclusiveArch. [16] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00542.html A sub-thread evolved to investigate the problems of cross-compilation[17]. This sprouted many intricate offshoots, for instance one in which BrendanConoboy and RalfCorsepius discussed[18] whether redhat-rpm-config was fundamentally broken or could be modified to become cross-compilation friendly. Another scion took root in a discussion[18] of generic cross-compilation on Fedora. ManasSaksena tipped a nod[19] to a possibly useful tool from ChrisTaylor called tsrpm, which would allow the systematic derivation of customized root filesystems for cross-compilation to specific devices. [17] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00837.html [18] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00895.html [19] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00960.html Brendan opened[20] a wider discussion with the Fedora community in which he recounted the experiences of his Red Hat group (GES) that has largely abandoned native builds and emulators in favor of cross-compilation. Brendan was enthused by the discussion about ARM and identified a need for cross-compilers, modified packages, and volunteers to avoid extra burdens on packagers. [20] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01006.html OliverFalk (Alpha ArchTeam) wanted to know[21] specifically if cross-compilation was always as reliable as native compilation in exposing errors, and also thought that if specific ArchTeams chose to eschew cross-compilation then they should be allowed to do so. AndyGreen backed up[22] Brendan's recommendations (due to his own experimentation) and answered that there ought to be no difference between the object code emitted by a cross-compiler or a native-compiler. [21] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01075.html [22] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01078.html Hastening to make sure that cross-compilation and new secondary architectures were not conflated, Brendan replied[23] to Oliver that there while there were some problems unique to cross-compilation it was nevertheless reliable. Brendan suggested the idea of a CrossTeam similar to the ArchTeams. [23] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01186.html === A World Of Hurt: Making F7 Install CD Set From DVD Using FC6 Pungi === Several posters have expressed disappointment in the past that the Fedora 7 images were available only as DVD images and not as a set of CDs. TonyNelson sought help[1] in filling this need. JesseKeating made[2] some helpful suggestions about how this splitting could be achieved using Fedora 7 and drew Tony's attention to the novel use of a manifest file by Pungi instead of comps.xml. In response[3] Tony clarified that he was specifically only interested in using Pungi from (and on) FC6 to try to split the F7 DVD. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00638.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00660.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00680.html JarodWilson thought[4] that Tony had taken on a tough job because the .manifest was only in post-FC6 Pungi and it wasn't easy to backport. Tony argued[5] that Jarod was suggesting that CD-only upgraders would have to install F7 in order to have a way to install F7! He wondered what problems might occur besides missing 20 packages from comps.xml. JesseKeating listed[6] some of the huge changes (to pungi, the yum API, anaconda-runtime calls etc) that would complicate the task that Tony was tackling. [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00684.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00693.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00697.html Continue probing from Tony prompted[7] Jesse to explain that the manifest file is of kickstart syntax, the files listed in it are taken by Pungi, then anaconda tools are run on them. The version of anaconda must match the one in the distribution. [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00699.html After Tony seemed ready to give up Jesse wondered why he didn't use the LiveCD image. Tony responded[8] that it was only useful for a clean install and put the use case of someone with low-bandwidth and not enough harddrive space for the DVD iso. [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00708.html "Vnpenguin" and JarodWilson had both suggested installing "mock" and using the resulting chroot to run pungi and Jesse pointed to the docs explaining how to run pungi in mock[9]. [9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00801.html === Splitting Terminfo Out Of The ncurses RPM === The burst of OLPC inspired activity (see "Eliminating Unwanted RPM Dependencies And Statically Linked Binaries" elsewhere in this issue) from BernardoInnocenti had the positive side-effect of slimming the standard Fedora distro. One piece of bloat identified[1] by Bernardo was the bundling of 2MB of terminfo data with ncurses, which Bernardo suggested be split out into a separate sub-package. The discussion was irritatingly split between @olpc-devel and @fedora-devel, which made it hard to follow. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00459.html MiroslavLichvar warned[2] that the terminfo data shouldn't be eliminate entirely but agreed that it could probably be split out. Referencing[3] Ubuntu's practice, ArndBergmann agreed and suggested a shortlist of terminals that could be included in the ncurses package as a safe minimum. Arnd later described[4] the current split of a small subset into /lib/terminfo while the exhaustive collection is in /usr/share/terminfo and brought up the problem of 32 and 64 bit libraries. [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00510.html [3] http://marc.info/?l=olpc-devel&m=118099052410892&w=2 [4] http://marc.info/?l=olpc-devel&m=118113689230162&w=2 The multilib problem was also addressed[5] by BillNottingham who argued that in order to make upgrades sane, it would be best to keep the libraries within a package with the same name as the original. SimoSorce thought[6] that Bill's approach was improperly constrained by the brokenness of multilib detection. RexDieter agreed[7] that multilib detection should be fixed but disagreed that Bill's proposal resulted in substandard packaging. Bill returned to the problem of making the upgrade work, which JeremyKatz agreed[8] with but suggested that a work-in-progress from SethVidal might offer a resolution. [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00920.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00930.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00936.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00962.html === Eliminating Unwanted RPM Dependencies And Statically-linked Binaries === Following from the decision[1] to open up the Fedora Project infrastructure to the OLPC, BernardoInnocenti queried[2] whether it would be possible to remove some hard dependencies for particular RPM packages. The advantage for OLPC would be the ability to use pristine Fedora packages without pulling in unnecessary bloat. This advantage would accrue to other projects basing themselves off the Fedora Project. [1] http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070607 [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00478.html DavidTimms posted[3] a lovely dependency tree diagram for GRUB, showing that there would be advantages in separating out the fedora-logos into their own package. David also noted that glibc-common was severely bloated by localization (which slowed install time and presented problems for small harddrives). David suggested that similar to OpenOffice, the localisations could be split into sub-packages and hacked into comps.xml. Finally, David wondered whether there was a tool that would correlate disk-access to files and thus to RPM packages, allowing an analysis of unused files in particular RPMs. "SteveG" (StevenGrubb) suggested[4] using auditctl and aureport for this purpose. [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00519.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00550.html JeremyKatz cautioned[5] against David's suggested approach as it's result would be an increase in metadata size, an increased rpmdb size, and unpredictable side-effects due to comps being a bit hackish. Jeremy also noted that if one were willing to give up being able to use DeltaRPMs then setting the %_install_langs rpm macro properly will exclude non-desired locales. [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00560.html David and Jeremy dug deeper into the size trade-offs, with Jeremy estimating[6] that the increase in metadata and rpmdb size would be larger than David expected. David had asked whether the installer could take note of the %_install_langs setting and Jeremy replied that it didn't (although it used to) and that setting it via kickstart would be appropriate for small-footprint installs. [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00616.html A suggestion[7] by Bernardo to provide just one mega-locale package, which would allow the space-constrained (e.g. embedded developers) or lovers of the plain "C" locale an advantage, was countered[8] by JeremyKatz as too Western-centric. Jeremy also argued that a frequent request in the past had been post-installation addition of language support and the current setup made this much easier. Jeremy then provided further details of the workings of DeltaRPMs in response to Bernardo. [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00735.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00745.html As regards the GRUB dependencies, NicolasMailhot pointed out[9] that the problem would be obviated once the default display of a themed GRUB menu is removed. After Jesse suggested that the policy on directory ownership could be relaxed in the case of the fedora-logos package, DavidTimms was keen[10] to get things rolling or else hear a definite "No". [9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00595.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00609.html Another of Bernardo's suggestions was to remove mkinitrd's dependency on lvm2 and dmraid, but JeremyKatz[11] pointed out that this would lead to problems with initrd creation in the kernel's %post and suggested that this was an area that would benefit from some creative solutions. DavidZeuthen thought[12] that the OLPC's kernel wouldn't need mkinitrd because it had all the drivers built-in. Bernardo thought otherwise[13] due to both the dependency and because of the need to boot from USB with the ext3 image. The need for any static binaries at all was also questioned, and Bernardo dismissed the "disk space is cheap" argument. David replied[14] with the suggestion of using a dummy RPM package to satisfy the dependency and pointed to UlrichDrepper's post on @fedora-devel on the subject of static linking. [11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00559.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00582.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00637.html An ensuing discussion of static vs. dynamic linking between a skeptical PatriceDumas and BernardoInnocenti led to ChrisAdams providing[14] some concrete proof that dynamic-linked binaries are smaller than statically-linked "in the real world". Later Bernardo diverged slightly into a discussion[15] of how Linux has become bloated. NicolasMailhot argued that the solution was optimized, co-ordinated dynamic libraries (citing Pango and Qt's co-operation on Harfbuzz), to which Bernardo agreed and noted that OSX had banned static linking with system libraries. [14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00805.html [15] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00888.html [16] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01032.html A dependency of HAL on crypsetup-luks turned out[17] to not be needed according to PeterJones, helping Bernardo to eliminate 1.2MB. [17] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00591.html === F7 Images For Mass Production === Since the release of Fedora 7 ISO images to the mirrors, there have been several bugs reported and fixed. The availability of these fixes led to a dilemma[1] for MaxSpevack who was just about to start pressing DVDs for the FreeMedia program and FedoraEvents, and wondered whether the original "GOLD" images should be used for Fedora LiveCDs and DVDs or if updates should be somehow incorporated. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01119.html The ensuing discussion saw three main viewpoints emerge. The first was that the GOLD images should be used exactly as though they'd been pressed immediately upon release of F7 with the simple addition of an updates.img to fix simple anaconda problems. ChristopherAillon and JesseKeating were strongly in favor[2] of doing this and adding a sleeve-note about known bugs and work-arounds. ThomasChung (coordinator of the FreeMedia program) was also in favor[3], and Max deferred[4] to their opinions as Jesse has an overview of the ReleaseEngineering problems while Thomas has his finger on the pulse of the users of these DVDs. Jesse gave a good quick rundown[4a] of all the potential problems with regressions that a respin would involve. PaulFrields pointed to a serious problem with localization that seemed like it was a simple updates.img fix, but which Jesse's dissection[4b] revealed as a slightly more complicated, but fixable problem. [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01141.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01130.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01151.html [4a] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01133.html [4b] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01155.html Another approach was advocated[5] by WarrenTogami, who suggested that all that should change would be to update the both the kernel and anaconda (using an updates.img) to fix some of the egregious bugs such as non-booting Dell Core2Duo machines and e1000 NIC problems. ChrisLumens thought[5a] that the updates.img would avoid getting a fresh-round of bug-reports on known issues. RahulSundaram tried[6] to figure out why a public point-release wasn't being considered so that anyone could benefit from the work which Max thought was worth doing. Suspend/resume breakage was also suggested as a candidate for this sort of patching, but Rahul's query[6a] as to whether there was a fix for this remained unanswered. [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01122.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01143.html [6a] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01137.html Expanding[7] the previous respin idea a bit, HansdeGoede wanted to add network security fixes. Jesse extrapolated[8] to the likely outcome of this approach, which he saw as a series of slow-moving bug-fix releases similar to Red Hat's approach to RHL. AxelThimm noted[9] the emerging consensus against a respin this time but suggested that in future there would always be a post-GA respin. Jesse was against[10] this being done as an "official" Fedora Project undertaking, due both to the QA problems and because users would simple ignore the GA and wait for the respin instead, thus deferring the problem. BrunoWolff thought[11] it might work because the ability to upgrade would be guaranteed, making it different from a test-release. FedoraUnity had been mentioned by several people in the discussion and Axel wondered[12] if something similar were offered on a weekly basis. [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01145.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01150.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01212.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01225.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01246.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01249.html === Exploding Trees and SCM === JeffOllie got the ball rolling[1] for an @fedora-devel discussion of possible ways and means of replacing the current CVS system with a more useful SCM (Source Configuration Management system). The discussion had been started[2] on @fedora-infrastructure and JeremyKatz had supplied some helpful discussion points. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00839.html [2] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg000… JesseKeating thought[3] that with F8T1 being a mere two months away it was unrealistic to attempt to make the transition before F9. In addressing the specific desiderata listed by JeremyKatz, it seemed that Jesse leaned towards using exploded source trees to make it easier for package maintainers to adapt their patches to changing upstream, and the "git" SCM to distribute changesets. [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00835.html Jeffrey agreed[4] with Jesse's post-F8 timeframe, but suggested that it might be possible to implement a system that didn't disturb packagers' workflows, yet laid the groundwork for a more radical change in the future. In response Jesse forwarded an @fedora-infra post from Jeremy that argued[5] that this would actually require people retraining twice. [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00842.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00845.html Responding to the original discussion points, AxelThimm thought that easing packagers tracking of upstream depended on what those upstreams were using as SCMs. Axel also leaned[6] towards a distributed SCM such as git or Hg to facilitate Fedora downstream fixes making it back into the Fedora Project easily, with the choice being left up to the Koji developers who would have to do the actual implementation. [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00844.html A request from Jesse during the discussion was that participants list features in which they were interested, rather than particular SCMs. The discussion seemed to peter out on @fedora-devel with a discussion between Axel and Jesse as to whether or not Hg supported renames[7]. [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01012.html A related thread from @fedora-infrastructure was cross-posted[8] separately by JeremyKatz. ChristopherBlizzard advanced[9] the idea that because Fedora tries to reflect the upstream of each project it should possibly do that with regard to SCM choice. Jeremy argued[10] against this as it made it hard to coral changes of Fedora-specific interest and also introduced a requirement for knowledge and inter-operation of multiple, different SCMs. Some parts of the discussion stayed on @fedora-infrastructure. [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00855.html [9] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg000… [10] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg000… ToshioKuratomi(abadger) suggested[11] looking at what Ubuntu was doing (albeit for different reasons) with their "Hypothetical Changeset Tool". In response JesseKeating drew the distinction[12] that exploded trees with patch management weren't exclusive to generating SRPMS, but was a layer that could operate as an input to the buildsystem which would then produce the SRPMS. BillNottingham was skeptical[13] about how much this would help the drive to cohere with upstream. [11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00935.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00969.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00976.html At this point[14] a discussion between NicolasMailhot and ToshioKuratomi became far too complex for your humble observer to follow and those interested should probably look at the thread themselves. The main arguments seemed to be that Toshio liked[15] the ability to pull specific subsets of patches to submit upstream, which is given by DRCS. Nicolas thought Toshio's premises were unrealistic in assuming that Fedora would fork upstream so heavily and also that his approach would not separate patches specific to Fedora with patches for upstream[15]. For a full understanding, refer to the relevant thread. [14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00964.html [15] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01010.html === Why Emacs Is Not Installed By Default === After "Shams" asked[1] why Emacs was not installed by default, ManuelWolfshant shook the hornets' nest by suggesting that not everyone wanted a second OS installed. OlivierGalbert was the first to react[2], pointing out that if Emacs were axed then it wouldn't be long before vi followed, Olivier surmised that "windows envy" was determining desktop choices. MatejCepl[3] and LinusWallej[4] drew attention to the POSIX/IEEE 1003.1 requirement for vi, but not for Emacs. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00470.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00494.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00615.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00502.html PatriceDumas suggested that the tools for re-spinning Fedora would allow userbases that had different visions of the desktop to build a Fedora that they liked, but NicolasMailhot had apparently been stung by Olivier's comment and bravely plunged on[5], arguing that Emacs was "going the way of the dodo because it targets 1995-ish desktops". A swarm of questioners including AndrewHaley sought clarification from Nicolas, to which he responded[6] that Emacs didn't use the desktop font infrastructure, i18n, a11y, one of the main GUI toolkits, or integrate with the printing infrastructure. TomTromey returned[7] to the question of what specific maintenance burden was imposed by Emacs, and reminded everyone that Emacs wasn't being removed, it just wasn't included in the default install. JeremyKatz agreed[8] and pointed out that the situation had been like this for a while. Nicolas answered[9] Tom with the information that Emacs' dependency on the legacy font system was the main problem. [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00500.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00540.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00557.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00558.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00593.html Taking a stab at answering Shams's question, NigelJones guessed[10] that popularity was probably the answer. Going one better, JefSpaleta posted[11] statistics from Mugshot that showed Emacs having marginally more users. AlexandreOliva explained[12] that Emacs did a lot more than mere text-editing. [10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00476.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00583.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00644.html === Metalink: A New Way Of Distributing Fedora ISOs? === A suggestion[1] from AnthonyBryan about a new way to distribute Fedora using Metalinker[2] has gained some traction. Metalink is an open standard that puts an XML wrapper around all the possible available URIs for common protocols such as HTTP and FTP. It allows segmenting of the source and hence simultaneous downloading from multiple mirrors. JesseKeating suggested using MirrorManager to automatically create the metalinks, to which RahulSundaram replied[3] that he'd suggested this a while ago. A tool authored[4] by DavidTimms to allow reconstruction of ISO images from previous versions may be useful for this problem. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01160.html [2] http://www.metalinker.org/ [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01164.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01207.html Responding to the positive reception, Anthony (as the author of Metalink[5]) wondered whether he should supply[6] a patch to MirrorManager, and was advised to open a discussion with MattDomsch on @fedora-infrastructure. Anthony pointed out that no other distribution was generating dynamic .metalinks on a large scale. Matt responded[7] briefly on @fedora-devel to indicate that he would be happy to accept and review patches. [5] http://www.packtpub.com/article/Downloading-evolved-with-Metalink [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01200.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01230.html === Quick Notes On Update Image Installer And F8 Desiderata === Last week's thread[1] on providing a grub-entry for an installer image to facilitate upgrading kept going. WillWoods posted[2] a modified plan of attack leading JesseKeating to add[3] that yum/rpm would be needed for depsolving and a pessimistic BillNottingham to warn[4] about Python ABI changes, JeremyKatz confirmed[5] this pessimism to an optimistic[6] ColinWalters [1] http://fedoraproject.org/wiki/FWN/Issue90#head-4fa2b381c1834f3104cff9fe61bf… [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00704.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00705.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00725.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00742.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00744.html In a completely separate thread initiated[7] by HansdeGoede, a laundry list of desired features for F8 was under construction. Among Hans' more controversial proposals were a plugin-buddy, a firmware-buddy, and a proprietary-software-installer-buddy. BillNottingham wondered[8] which wireless cards the firmware-buddy would be useful for and didn't like the bug-chasing that would introduced by the proprietary-software. Hans listed the ralink, BCM43xx, and SIL cards and agreed with JeremyKatz who expressed[8] a preference for working upstream with the vendors so that the firmware could be shipped in perfect working order. Interested thread participants started[9] a wiki page[9a] to collect and document missing firmware. [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00890.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00927.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00955.html [9a] http://fedoraproject.org/wiki/SIGs/FirmWare BernardoInnocenti noted[10] that Firefox's plugin system would, if applied by many applications, lead to Linux "becoming as maintainable and robust as Windows". RalfErtzinger liked the RPM-free nature of Firefox plugin installation and TillMaas showed[11] how difficult it might be for non-root privileged users to install RPMs. [10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01022.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01290.html == Documentation == In this section, we cover the Fedora Documentation Project. http://fedoraproject.org/wiki/DocsProject Contributing Writer: JonathanRoberts === CVS Walkthrough in IRC === BartCouvreur held a session in #fedora-docs on freenode, explaining how to use CVS as part of the Docs Project. This session was also useful as a general introduction to CVS if you've never used it before. If you're interested in learning how to use CVS, as part of the Docs Project or more generally, the log of the session was posted to the fedora-docs-list[1] and is also available as nicely formated HTML[2]. You can also find detailed information in the Documentation Guide[2]. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00037.html [2] http://fedoraproject.org/wiki/JohnBabich/CvsLesson [3] http://docs.fedoraproject.org/documentation-guide/ch-cvs.html === RPM Guide === JoseManimala volunteered to maintain the RPM guide[1]. This led to a discussion about the best place for this guide to be maintained. As the Fedora Project's software aims to stay as close to upstream as possible, is there any reason why content should not as well?[2]. It turned out that upstream had already pointed to the guide, and suggested that people wanting to work on it should do so through the Fedora Documentation Project[3]. At this point this guide does not have a team around it. If anybody has experience with RPM and wants to help Jose Manimala, post to the fedora-docs-list and co-ordinate from there. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00006.html [2] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00038.html [3] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00061.html === Fedora Documentation Steering Committee Meeting === The log for the FDSCo meeting of the 5th June was published to the fedora-docs-list[1]. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00054.html === Fedora 7 FAQ === RahulSundaram forwarded a message to the fedora-docs-list, requesting that a link to the Fedora 7 FAQ be added to the docs.fedoraproject.org front page[1]. The message that was forwarded also included a request for a link to the FAQ to be included on the new fedoraproject.org home page, which led to a debate over whether this was appropriate, given that the home page has just been given a minimalist redesign[2]. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00057.html [2] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00058.html == Translation == This section, we cover the news surrounding the Fedora Translation (L10n) Project. http://fedoraproject.org/wiki/L10N Contributing Writer: JasonMatthewTaylor === Bugzilla for Trans Team === DimitrisGlezos and others have been discussing the idea of adding a Translation team component[1] to Bugzilla in order to better track changes, change-requests, suggestions, etc. [1] https://www.redhat.com/archives/fedora-trans-list/2007-June/msg00014.html == Infrastructure == In this section, we cover the Fedora Infrastructure Project. http://fedoraproject.org/wiki/Infrastructure Contributing Writer: JasonMatthewTaylor === Backups === With recent changes and additions to the project infrastructure, MikeMcGrath and others have decided to look into new backup][1] options. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg000… === Fedora 7 Upgrade === Fedora 7 being released prompted some discussion[1] about whether or not to upgrade infrastructure systems. After some discussion it seemed to be agreed to review each systems requirement and upgrade accordingly. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg000… == Artwork == In this section, we cover Fedora Artwork Project. http://fedoraproject.org/wiki/Artwork Contributing Writer: JonathanRoberts === Fedora 8 Artwork === MatthiasClasen sent a message to the fedora-art-list, hoping to prompt discussion on the art work for Fedora 8[1]. The central points of his message were: * Diana Fong is no longer employed by Red Hat and so it is probable there will be no full time artist to work on the F8 release * He proposes trying a different approach to the art work for F8, less branded and less image based * The graphical boot is changing and may result in less art work (and less restrictive art work) for the boot sequence * Questioned the state of the Echo icon theme - will it be ready for F8? NicuBuculei proposed that a similar system to Fedora 7 is followed, where the art work is decided upon through a 3 round competition[2]. As part of this MarekMahut suggested that we try to get schools involved. It was suggested a possible problem with this would be that they use proprietary software; virtual workshops about FOSS art tools was proposed as a possible solution[3]. RahulSundaram reminded the list that one comment that has appeared fairly often in early reviews of Fedora 7 is that Clearlooks looks dry compared to the polished appearance of the rest of the distribution[4]. Following this two new threads were started, creating mock-ups of new default themes for Fedora 7[5] [6]. MairinDuffy has proposed a milestone based approach for the Fedora 8 art work, which was received well as a preliminary schedule[7]. Highlights of the proposed schedule include a "promo kit" and the discussion of tag lines and promo banners for the fedoraproject.org websites, in co-operation with the fedora-marketing-list. [1] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00002.html [2] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00003.html [3] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00019.html [4] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00012.html [5] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00052.html [6] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00069.html [7] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00039.html === Echo Icon Theme === Following the thread about Fedora 8 art work, LuyaTshimbalanga updated the list on the state of the Echo icon theme[1]. The problems with the SVG icons encountered before the release of Fedora 7 are now fixed, although a few will need reworking; the Echo pull script is currently broken on x86_64; work on Echo icons is now resuming. [1] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00011.html == Security Week == In this section, we highlight the security stories from the week in Fedora. Contributing Writer: JoshBressers === Google: Attack code more likely on Microsoft IIS === "Computer World Security reports[1] Google's malware team discovered[2] that a server running Microsoft IIS is twice as likely to be hosting malicious software as are other web servers. The Google team doesn't draw many conclusions from this data. It is suspected that it's likely a number of these machines are not automatically installing security updates for one reason or another. The most disturbing part of the reports is that there are about 70000 domains hosting malware or browser exploits. This is a huge number of hosts. No doubt some of those domains are purposely hosting exploits, but it's also disturbing to consider that there are thousands of administrators who have no idea their server is being used for dubious purposes." [1] http://www.computerworld.com/action/article.do?command=viewArticleBasic&art… [2] http://googleonlinesecurity.blogspot.com/2007/06/web-server-software-and-ma… === Bruce Schneier: Department of Homeland Security Research Solicitation === "Bruce Schneier points[1] out a paper from the DHS. They are looking for researching into how to deter and prevent malware on the Internet. As Bruce points out, it's about time someone is investing in this sort of thing. It is shameful how bad computer security is today. As more and more computers attach to the Internet, the number of infected machines will continue to increase. Educating users and administrators isn't working and probably won't. The best solution is going to be to stop the malware before it has a chance to cause any damage. There is no doubt a great deal of money to be made in whoever solves this rather difficult problem." [1] http://www.schneier.com/blog/archives/2007/06/department_of_h_1.html == Advisories and Updates == In this section, we cover Secuirity Advisories and Package Updates from fedora-package-announce. Contributing Writer: ThomasChung === Fedora 7 Security Advisories === * 2007-06-09 [SECURITY] mod_perl-2.0.3-9.1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0316 * 2007-06-08 [SECURITY] bind-9.4.1-4.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0300 * 2007-06-06 [SECURITY] freetype-2.3.4-3.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0033 * 2007-06-06 [SECURITY] php-pear-DB-1.7.11-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0249 * 2007-06-06 [SECURITY] postgresql-8.2.4-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0174 * 2007-06-06 [SECURITY] zvbi-0.2.25-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0175 * 2007-06-04 [SECURITY] Network``Manager-0.6.5-3.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0186 * 2007-06-04 [SECURITY] wpa_supplicant-0.5.7-3.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0185 === Fedora Core 6 Security Advisories === * 2007-06-06 [SECURITY] postgresql-8.1.9-1.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-565 * 2007-06-06 [SECURITY] quagga-0.99.7-1.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-525 == Events and Meetings == In this section, we cover event reports and meeting summaries from various projects. Contributing Writer: ThomasChung === Fedora Event Help Needed: 2007 Libre Software Meeting - France === MaximeCarron reports in fedora-ambassadors-list[1] and requesting help on his Fedora Event at Amiens, France[2], "From July the 10th to 14th will occur the RMLL (Rencontres Mondiales du Logiciel Libre) ie "Free Software World Meetings" in Amiens, France. RMLL is a big and great event in France. Lots of poeple are coming from all over the world, and both high level and beginner conferences are planed during the week." "Currently we're just 2,5 volunteers for this events (ChristophePolyte, CharlesVinchon, MaximeCarron [i'm the half]), which is really not enough. We need your help." [1] https://www.redhat.com/archives/fedora-ambassadors-list/2007-June/msg00045.… [2] http://www.rmll.info/?lang=en Editor's Note: Here are online photo albums[1] from 2006 and 2005 events. [1] http://photo.rmll.info/main.php === Fedora Event Report: LinuxTag 2007 - Germany === FabianAffolter reports in fedora-ambassadors-list[1], "LinuxTag[2] is over...we have had a good time there and the attendance of the Fedora Project at this event was a success. If you want to know what was going on there, check out the blogs of the attendees." [1] https://www.redhat.com/archives/fedora-ambassadors-list/2007-June/msg00035.… [2] http://www.linuxtag.org/2007/ === Fedora Ambassadors Meeting Minutes 2007-06-07 === * https://www.redhat.com/archives/fedora-ambassadors-list/2007-June/msg00032.… === Fedora Documentation Steering Committee 2007-06-05 === * https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00054.html === Fedora Engineering Steering Committee Meeting 2007-06-07 === * https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01166.html === Fedora Packaging Committee Meeting 2007-06-05 === * https://www.redhat.com/archives/fedora-maintainers/2007-June/msg00332.html === Fedora Release Engineering Meeting 2007-06-04 === * https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00640.html == Feedback == This document is maintained by the Fedora News Team[1]. Please feel free to contact us to give your feedback. If you'd like to contribute to a future issue of the Fedora Weekly News, please see the Join[2] page to find out how to help. [1] http://fedoraproject.org/wiki/NewsProject [2] http://fedoraproject.org/wiki/NewsProject/Join -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung

1 0

Fedora Weekly News Issue 90
by Thomas Chung 04 Jun '07

04 Jun '07

= Fedora Weekly News Issue 90 = Welcome to Fedora Weekly News Issue 90[1] for the week of May 27th through June 2nd, 2007. The latest issue can always be found here[2] and RSS Feed can be found here[3]. [1] http://fedoraproject.org/wiki/FWN/Issue90 [2] http://fedoraproject.org/wiki/FWN/LatestIssue [3] http://feeds.feedburner.com/fwn 1. Fedora Weekly News Issue 90 1. Announcements 1. Announcing Fedora 7 (Moonshine) 2. Freshrpms for Fedora 7 3. ATrpms for Fedora 7 4. A Few Words About Fedora 7 5. Discounts on Red Hat training for Fedora folks 2. Planet Fedora 1. Fedora is now an open source project 2. Interview of Max Spevack 3. Interview of Mike McGrath 4. Kernel hacking for laptops 5. fedoraproject.org promos 6. Some comments on Fedora 7 7. Fedora 7 "Moonshine": Freedom vs. Ease-of-Use (Part 1) 3. Developments 1. OCaml Packaging 2. Fedora Secondary Architectures Proposal 3. Five Months To Fedora 8: A Conspiracy Against KDE? 4. What Should X-Chat Be Called In The Menu? 5. FreeTDS Inclusion 6. Simplified Kernel Spec File 7. RPM License Agreement Support 8. Don't Put New Packages Through Updates-testing 9. Fedora Image As A GRUB Entry 4. Maintainers 1. EPEL Report Week 20 2. Bodhi and Fedora 7 5. Documentation 1. Fedora Documentation Steering Committee Meeting 2. Meeting Location 3. ISO and Web-Only Release Notes 4. Documentation for Revisor and Other Spin-Making Tools 6. Infrastructure 1. Infrastructure Server Organization 2. Bodhi 3. New Projects 7. Artwork 1. Fedora 7 Disc Labels 2. Default Desktop Theme? 3. Fedoraproject.org Banners 4. Brazilian Banners 8. Advisories and Updates 1. Fedora 7 Advisories and Updates 2. Fedora Core 6 Advisories and Updates 3. Fedora Core 5 Advisories and Updates 9. Events and Meetings 1. Event Report: IV ESLAM - Amazon, Brazil 2. Fedora Ambassadors Meeting Minutes 2007-MM-DD 3. Fedora Documentation Steering Committee 2007-MM-DD 4. Fedora Engineering Steering Committee Meeting 2007-05-31 5. Fedora Packaging Committee Meeting 2007-05-29 6. Fedora Release Engineering Meeting 2007-MM-DD 10. Feedback == Announcements == In this section, we cover announcements from various projects. Contributing Writer: ThomasChung === Announcing Fedora 7 (Moonshine) === The Fedora Project announces in fedora-announce-list[1], "Fedora 7 is the first release where the development was one hundred and one per-cent in the community. How? It's simple, cousin -- all the code was merged into a single external repository. Why? Same great distribution quality, even more high-quality developers able to work directly with the code and improve the flavor of over 7500 packages." * http://fedoraproject.org/get-fedora.html * http://docs.fedoraproject.org/release-notes * http://docs.fedoraproject.org/release-notes/f7/en_US/sn-OverView.html [1] https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00009.html === Freshrpms for Fedora 7 === MatthiasSaou announces in fedora-announce-list[1], "All freshrpms add-on packages are now available for Fedora 7." * http://freshrpms.net/ * http://moonshine.freshrpms.net/ [1] https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00011.html === ATrpms for Fedora 7 === AxelThimm announces in fedora-announce-list[1], "ATrpms is officially launching Fedora 7 support for i386, x86_64 and ppc." * http://atrpms.net/dist/f7/ * http://dl.atrpms.net/ [1] https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00010.html === A Few Words About Fedora 7 === MaxSpevack announces in fedora-announce-list[1], "Before I talk about Fedora 7, it's useful to look at recent history. One of the Fedora Project's mottos is "the rapid progress of free and open source software." With Fedora Core 5 in March of 2006, Fedora Core 6 in October of 2006, and Fedora 7 today, that's about 7 months per release. And with several million Fedora Core 6 installs, everyone who works on Fedora should feel very proud that not only is the software being released often, but it's also high quality, and in high use around the world." "Fedora 7 represents the culmination of several goals that Fedora has spent the last few releases (spanning the course of at least 2 years) working to achieve. I've written previously on this list about the aspects of Fedora 7 that I think are the most important[2]." "From my perspective, it is the fundamental infrastructure changes that Fedora 7 represents that are the biggest achievement. The entire Fedora toolchain has been freed. Every step in the distribution-building process is completely open." "And I speak for everyone at Red Hat when I say that it is an honor to be a part of something like Fedora. Congratulations to everyone on today's release." [1] https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00008.html [2] https://www.redhat.com/archives/fedora-announce-list/2007-May/msg00002.html === Discounts on Red Hat training for Fedora folks === MaxSpevack announces in fedora-announce-list[1], "The nature of Fedora is such that many of our contributors and users are very technical, and make Linux their careers as well as their hobbies. We know that many Fedora contributors and users hold RHCT, RHCE, or RHCA certifications. Obviously, we are happy that you choose Red Hat Training and and we appreciate your business. As a way of saying thank you to our community, we are pleased to offer special discounts[2] to Fedora contributors who register for upcoming Red Hat training courses." [1] https://www.redhat.com/archives/fedora-announce-list/2007-June/msg00000.html [2] https://www.redhat.com/training/fedora_training_discount.html == Planet Fedora == In this section, we cover a highlight of Planet Fedora - an aggregation of blogs from world wide Fedora contributors. http://fedoraproject.org/wiki/Planet Contributing Writers: ThomasChung, KarstenWade === Fedora is now an open source project === ChristopherBlizzard points out in his blog[1], "But of course, these are not the most important qualities of Fedora 7. The qualities that I'm interested in are somewhat intangible. What this release represents is a first step down a long path. Fedora is no longer something that just Red Hat produces. Those of us who work for the company have been long since eclipsed by the sheer number of people involved in Fedora from outside of the corporate firewall. It's simple: Fedora is now an open source project. What's interesting to me is how long we've been able to say this - a few months at best - but the number of people that have shown up who show a unique passion for the success of the project is just amazing. For a good view of some of them check out the Fedora Award Winners for 2007[2]. Every one of those guys just showed up and started making a difference." [1] http://www.0xdeadbeef.com/weblog/?p=293 [2] http://www.redhatmagazine.com/2007/05/31/announcing-the-fedora-award-winner… === Interview of Max Spevack === KushalDas points out in his blog[1], "Yesterday night, I did a video interview of MaxSpevack (Fedora Project Leader). In this interview, he mostly talked about the upcoming Fedora-7 release, which will happen tomorrow. The plus points for the users. He also described the future targets of the Fedora project. You can see the interview here[2]. In the google video also at here[3]." [1] http://kushaldas.in/?p=134 [2] http://www.archive.org/details/InterviewOfMax [3] http://video.google.com/videoplay?docid=-4461571891690806161&hl=en UPDATE: Here is another Video Interview[1] of MaxSpevack (Fedora Project Leader) & Kital [1] http://kushaldas.in/?p=145 === Interview of Mike McGrath === KushalDas points out in his blog[1], "As Fedora-7 is out for almost 1 day, I did an interview of MikeMcGrath (Fedora Infrastructure). He talked about how it went :)" You can see it here[2]. [1] http://kushaldas.in/?p=136 [2] http://video.google.com/videoplay?docid=7800949146474110046&hl=en === Kernel hacking for laptops === RichardHughes reflects on his day off hacking the kernel in his blog[1], "I've just posted a patch to fix the toshiba_acpi kernel driver to emit INPUT events when the fn hotkeys are pressed. This means that the hardware works out of the box, and integrates nicely with KDE and GNOME without using oddball uinput-injecting system daemons such as FnFX to do the userspace polling. This also obsoletes my hal addon to do basically the same thing." [1] http://hughsient.livejournal.com/27324.html === fedoraproject.org promos === In response to a collaborative idea to do rotating banner promos on fedoraproject.org[1], MairinDuffy posted a few ideas in her blog, "So we've had this idea the past few days that now we have a new fedoraproject.org, we could do cool stuffs like have promos to highlight events, groups, and other cool stuff around Fedora. The first promo we're thinking about is to highlight spins - the fact you can now create your own custom Fedora spins or highlight a particular spin." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00001.ht… [2] http://mihmo.livejournal.com/41166.html = Marketing == In this section, we cover Fedora Marketing Project. http://fedoraproject.org/wiki/Marketing Contributing Writer: ThomasChung === Some comments on Fedora 7 === RahulSundaram reports in fedora-marketing-list[1], "Fedora 7, the latest and arguably most ambitious release from the increasingly community-friendly Fedora Project, will hit the download mirrors later this week. With its installable live CDs, merged package repositories and much improved artwork, the new Fedora should prove a major attraction on the 2nd quarter release calendar[2]." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-May/msg00082.html [2] http://distrowatch.com/weekly.php?issue=20070528 === Fedora 7 "Moonshine": Freedom vs. Ease-of-Use (Part 1) === MarcWiriadisastra quoted an article in fedora-marketing-list[1], which sparked a thread about how well Fedora explains its positions on IP-encumbered software. "Fedora 7, a.k.a. "Moonshine," released on May 31, is an odd duck. On the one hand, it's hugely popular. If you need to be convinced of that, take a look at the number of people viewing the officially-sanctioned FedoraForum.org[2] at any given time - as I write this, it's almost 7,000 people. Visit your local Barnes & Noble Booksellers (that's a big bookstore chain in the U.S.) and you'll see quite a few books about Fedora on the shelves. (This, by itself, is a big plus for Linux newbies — Fedora may be the best-documented distro available)." [1] https://www.redhat.com/archives/fedora-marketing-list/2007-June/msg00021.ht… [2] http://forums.fedoraforum.org/ Editor's Note: As of June 3, 2007, there were over 93,000 members in FedoraForum.org == 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 === OCaml Packaging === As previously reported[1], the packaging of the OCaml language has been initiated. RichardJones wondered[2] whether his OCaml packages could be discussed at the upcoming FESCo meeting. Richard had discussed[3] some issues with ToshioKuratomi on @fedora-packaging but sought wider input. [1] http://fedoraproject.org/wiki/FWN/Issue86#head-45f52ddea0d1c89a1e166a721b43… [2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02005.html [3] https://www.redhat.com/archives/fedora-packaging/2007-May/msg00207.html TomCallaway (spot) thought[4] that the discussion would be more appropriate to the packaging committee (which would be meeting within a week), while BrianPepple noted[5] that FESCo was open to anyone in the community who was willing to follow the basic etiquette. [4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02006.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02009.html === Fedora Secondary Architectures Proposal === A draft proposal on the support of different machine architectures was submitted[1] by TomCallaway for consideration. It resulted in prolonged and apparently unresolved disagreements. The proposal recognised two layers of architecture: Tier 1, consisting of x86 and x86_64; Tier2 consisting of SPARC, Alpha, PPC{,64}, IA64 (and possibly s390). Support of Tier1 would be considered the primary responsibility of the Fedora Project, while responsibility for the secondary architectures would be devolved onto volunteer teams (ArchTeams). The buildsystem would be structured so that the failure of packages to build on Tier1 would prevent the packages from being pushed to the repository, but failure on Tier2 would not prevent the packages being pushed to the repository. [1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01862.html The main points of contention seemed to arise from the possibility of disturbance of a currently well-working system by which package maintainers provide a certain amount of feedback to the existing Tier2 architectures. Balanced against that is the desire to allow niche-architecture interest groups to use the Fedora Project buildsystem, without causing undue potential disturbance to the majority of users. An initial objection[2] from DavidWoodhouse (the driving force behind PPC support in Fedora) was that the proposed system would promote silent failures, a step backwards from the useful information now provided by maintainers through the required filing of a tracker bug each time "ExcludeArch:" is used in a package's specfile. JefSpaleta[3] and HasdeGoede[4] agreed with David on the advantages of the documentary nature of the current procedure. Jef proposed that the current ExcludeArch practice be extended to Tier2. [2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01863.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01865.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01893.html Tom cautioned[5] that Jef's suggestion of ignoring failed builds would necessitate changes to Koji and would also probably result in frustrated package maintainers overusing ExcludeArch as soon as more Tier2 were added. David picked up[6] on this point and suggested that Tom and he were addressing different problems, with Tom considering the process of introducing a new architecture, while David himself was talking about the procedure to be followed during the ongoing attempt to support a Tier2, which had already had low-level stuff like glibc and gcc bootstrapped. David further suggested the idea[7] of allowing a maintainer to file a bug after a package failed to build for a particular architecture, but thought that this resulted in increased complexity for no gain. BillNottingham pointed out[8] that the gain was that Tier2 failures wouldn't hold up Tier1 package building and propagation even if the relevant ArchTeam failed to do a good job. ChrisBlizzard had separately indicated[9] that he estimated that inside of Red Hat they were "spending 50% of your time on 3% of your user base" and that the proposal avoided the delays in development which Fedora would also surely see if new architectures were added without this proposal being implemented. [5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01877.html [6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01896.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01896.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02002.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02020.html JesseKeating contradicted[10] the idea that Tier2 build failures would be "silent" and restated the proposal's central advantage in avoiding development delays due solely to Tier2 architectures. DavidWoodhouse disputed[11] the idea that progress would be hindered and itemized the reasons for which a package might cease to build succesfully, arguing that these were either easily within a package maintainer's abilities, or else could be passed on to the ArchTeam by filing an ExcludeArch bug. David further argued that the only downside might be a small delay resulting from putting a fixed package through the buildsystem again. Jesse referenced his personal experience in which he had seen packages sit unbuildable for hours and days due specialists on particular architectures being unavailable. Jesse also suggested that package maintainers would be overwhelmed by the additional work required, a point that was reinforced[12] by ChrisWeyl who was concerned at the signs of stress already emanating from package maintainers due to the Core/Extras merge. DaveJones substantiated[13] Jesse's evaluation of significant delays, citing 6 hours increased wait time as a result of having to resubmit to the build system. David thought that the i386 kernel build could be pushed anyway, and ChristopherAillon explained[14] that currently that couldn't happen because it would lead to inconsistencies in the primary repositories. Christopher also thought that there would be advantages for Red Hat in being able to treat the s390 architecture in this way. [10] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01922.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01944.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01959.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02155.html [14] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02173.html ChrisWeyl argued[15] that David's primary objection was about relaxing the requirement that maintainers be responsible for all architectures, but this had to be done in order to allow new architectures into the build system. TomCallaway thought[16] that Chris had appreciated the heart of his proposal. David replied[17] that the proposal seemed to be trying to solve a problem that didn't exist and that the current system was fine and did exactly what Chris said the new one should do. JakubJelinek emphasized[18] the problem of slow build times on particular architectures, providing specific information about the PPC{,64} builds and wondered whether asynchronous builds should be considered. OliverFalk was concerned[19] about addressing this problem for the Alpha architecture. [15] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01871.html [16] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01872.html [17] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01895.html [18] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01897.html [19] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01899.html Responding to Jakub's data, David agreed[20] that slow builds for particular architectures was the only possible problem solved by the proposal and wished that TomCallaway had stated the problem more clearly. ChristopherAillon cited[21] the undesirability of delaying a critical Firefox security fix in order to add an ExcludeArch and then rebuild. He also mentioned the undesirability of waiting while exotic compiler bugs were fixed for Tier2 architectures (something which Firefox apparently exposes due to its complexity). David questioned[22] whether it would really take much time. Christopher responded[23] that it did (worst case of up to 9 hours) and added that the situation was complicated by the frequent bundling of multiple fixes in one shot. David dismissed this as an "esoteric" case and asked if it would be covered by just filing an ExcludeArch retrospectively, which Christopher assented[24] to, noting that this was what the proposal addressed. ChrisBlizzard ratified [24a] ChristopherAillon's experience, to which David responded that he'd been paid to do it. [20] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01895.html [21] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01933.html [22] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01945.html [23] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01967.html [24] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01970.html [24a] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02029.html JesseKeating did not agree[25] that retrospective ExcludeArch bug-filing would solve Christopher's case, because if a build were allowed to fail for a Tier2 case then it would fail for everything, necessitating a complete rebuild. This led to David clarifying[26] what he was proposing, which led Jesse to wonder why David was objecting to implementing the proposed steps automatically and TomCallaway expressed concern that it would be difficult to code correctly and suggested an alternate logical build path. David reiterated his objection[27] to breaking the current balance of work shared by package maintainers and others. [25] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01971.html [26] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01990.html [27] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02053.html Further discussion of Christopher's concrete example was mainly an exchange between David and Jesse. David argued[28][29] against the "package monkey" approach of automatically filing ExcludeArch bugs and Jesse arguing[30] that maintainers couldn't reasonably be expected to do more than was suggested by the proposal if many new architectures were added. A lengthy, slightly circular and bad-tempered exchange developed with David arguing that incompetent Quality Assurance practices were being pursued and Jesse deciding that he'd had enough argumentation[31]. [28] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01952.html [29] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01969.html [30] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01972.html [31] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02075.html OliverFalk tried to salvage[32] something positive from the discussion by proposing a categorization of the ways in which builds could fail. David largely agreed with him and pointed out his own earlier similar attempt. Oliver excused the duplication on the basis of not having read the lengthy thread. [32] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02078.html One repeated question that kept cropping up in these sub-threads was restated by ChrisBlizzard[33], namely the question of what a package maintainer could reasonably be expected to do. DavidWoodhouse clove[34] to his earlier stated position in previous discussions that package maintainers could and should be expected to reach a high standard and that the current system worked well. ChristopherAillon suggested[35] that auto-filing of bugs could have a positive effect. BillNottingham thought[36] that the issue was more that the community was being asked to support the CPU fetishes of a minority user base, and that while the Fedora Project could offer facilities to such groups it shouldn't allow them to impede Fedora's primary mandate. [33] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02023.html [34] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02066.html [35] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02084.html [36] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02003.html BillNottingham[37], DennisGilmore[38], and OliverFalk[39] raised the logistical issues of where the machines for these builds would be located. Bill noted that the file space was just not available at the moment. JesseKeating emphasized[40] that Red Hat shouldn't be looked to as the source of hardware, which should instead come from any interested community, even so OliverFalk seemed to have some good leads on mothballed Alphas! [37] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01883.html [38] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01884.html [39] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01901.html [40] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01940.html === Five Months To Fedora 8: A Conspiracy Against KDE? === Discussion of the next release of Fedora was initiated[1] by KevinKofler on the premise that it was a problem because it would exclude the final KDE4 by a mere six days. JesseKeating[2] replied that a stable schedule was more important than any one piece of software and would allow upstream projects to target Fedora more easily. Kevin wondered[3] why the relationship should work in that direction and noted that Fedora 8 would have to ship a release candidate of a very important KDE and that schedules slipped anyway. ChristopherAillon responded[4] that this frequently happened with GNOME, while JefSpaleta described[5] advantages of sticking to schedules. [1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02102.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02104.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02106.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02106.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02119.html Kevin expressed[6] a belief that the release date was being done to suit GNOME at KDE's expense. ArthurPemberton noted that he'd heard this but asked for actual evidence, while SethVidal bluntly contradicted[7] the idea, saying that it was in order to not lose development staff during the winter holidays. [6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02111.html [7] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02132.html DavidWoodhouse acknowleged that schedules were good but wondered what was so special about October/April, leading Kevin to mysteriously pronounce[8] that he suspected he knew the answer. Disappointingly, rather than admitting to a counter-KDE conspiracy JesseKeating said[9] that October allowed some slippage without entering holiday time, while April was ideal for attention and resources. In a further demonstration of how carefully the conspirators had synchronized their stories, JeremyKatz gave nearly exactly the same answer[10]. [8] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02127.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02128.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02124.html The Google Summer of Code deadline was raised[11] by MatthiasClasen as a possible reason to perhaps slip the draft schedule a bit. KevinKofler felt relieved[12] that GNOME wasn't being held to the same standards but argued that it was further reason to change the date. DavidNielsen reported[13] hearing that KDE was also going to target a six-month cycle and that the rough schedule could be maintained if Fedora were to attempt to synchronize with KDE. There was significant agreement with this, but ThorstenLeemhuis suggested[14] that it would be best to see if KDE4.0 actually manages to ship on time, and then to synchronize with KDE. [11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00059.html [12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00069.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00156.html [14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00200.html === What Should X-Chat Be Called In The Menu? === A debate over what the IRC client "X-Chat" should be named in menus raged briefly. X-Chat has been covered before[1], as a possible example of how the community could help with packages post-merge. The discussion apparently spilled over from @fedora-extras with a post[2] from KevinKofler objecting to the manner in which some packages apparently do not follow the FESCo-approved guidelines about what a ".desktop" file should contain. The original post which Kevin was responding to is apparently not on @fedora-devel. [1] http://fedoraproject.org/wiki/FWN/Issue88#head-93d08605503d8a9cb111d3d63410… [2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02138.html MatthiasClasen thought that "X-Chat" was much less meaningful than "IRC", but Kevin and JoshBoyer[3] felt that even regular users coming from a Windows background would understand intuitively what was meant. Kevin also wondered why GNOME didn't support GenericNames in .desktop yet, which Matthias answered[4] by saying no one had got around to it yet. StuardChildern responded[5] by agreeing that the KDE solution of "X-Chat IRC" was the best. Even better, Stuart analyzed the problem as being solvable by adding a gconf dependency to libgnome-menu and volunteered to do this work himself. [3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02163.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02153.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00000.html Matthias thought that the desktop team was getting slammed[6] both for being too like Windows and for not being similar enough and redirected his energies to productive use. [6] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02164.html OwenTaylor zoomed[7] the discussion back out to a bigger picture, noting that the use of GenericName was a holdover from a previous "Best of Breed" approach to Fedora. Owen posted links to screenshots illustrating the new approach which uses "Big Board" to display a lot more information about applications. Owen thought that it would be best for now to simply use the name "X-Chat IRC Client" as is done for Firefox, and ignore the GenericName. ToshioKuratomi agreed, but thought that the Big Board idea was similar to best-of-breed except that it depended on usage statistics instead of a best guess of popularity by the distribution. [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00002.html [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00139.html After JoshBoyer hastened to make it clear that he wasn't slamming anyone and Matthias clarified that "regular users" wouldn't be able to choose applications by name, NilsPhillipsen suggested[9] that the menuing/application-display utility could do some conditional display of names and genericnames. [9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00085.html === FreeTDS Inclusion === The maintainer of FreeTDS[1] (which allows interoperability with Microsoft SQL and Sybase) posted a request[2] for a reconsideration of a 2005 decision not to include FreeTDS in Fedora. HansdeGoede noted that there were already packages in the Livna repository, and asked TomCallaway if it would be necessary to consult Red Hat legal. Tom responded that he was satisfied that there was no patent problem, and while he disliked the only documentation of the standard being marked "confidential" the package could probably move to Fedora. [1] http://www.freetds.org/ [2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02070.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02088.html === Simplified Kernel Spec File === ValentTurkovic asked for help[1] in getting suspend and resume to work properly on his laptop. NicolasMailhot noted the difficulty in getting a kernel to build from the vanilla source and patches due to the complication of the specfile. RahulSundaram delivered[2] the good news that this was being worked on and had been discussed on @fedora-kernel. [1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02044.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02148.html === RPM License Agreement Support === HikaruAmanu wanted[1] RPM to be patched so that it could present an EULA. ChrisBrown thought[2] that Fedora should do nothing to facilitate companies wishing to release non-Free software, and that the issue had been discussed previously. [1] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01924.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01947.html JesseKeating stated[3] that RPM installation had to be non-interactive. Several suggested that if this had to be done it should be post-install. JefSpaleta referenced[4] the old Macromedia flash-plugin as an example. [3] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg01934.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-May/msg02013.html === Don't Put New Packages Through Updates-testing === A thread was moved[1] out of @maintainers by HansdeGoede for wider consumption. Hans was concerned that the new policy of making new packages go through updates-testing added an unnecessary extra step and delayed getting the packages into the hands of users. JesseKeating responded[2] that this wasn't a sudden change, that it had always been the idea to have new packages enter the updates-testing repository, and that the only new thing was using "bodhi" for them. Jesse also asked for actual statistics on how many people used the updates-testing repository and pointed out that the important thing was maintaing a stable release for users and that the QA process for rawhide was not the same. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00053.html [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00062.html RalfCorsepius and HansdeGoede felt that it was unlikely that the testers using updates-testing would be able to appreciate the issues involved in many of the huge and technically complex packages that sometimes also require very specialist architectures. WillWoods responded with[3] an interesting link to his thoughts on how bodhi presented a balance between the (old) Fedora Core and Red Hat QA processes and emphasized that what QA testers did was to make sure that a baseline of verifying that there were no missed dependencies and that applications appeared to run without segfaulting. Further discussion suggested[4] that Hans already went above and beyond this sort of QA and that he would probably thus not experience the delays he feared. Hans also suggested some useful QA tests that should be added to the guidelines. [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00077.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00131.html Summing up[5] JefSpaleta suggested that "bodhi" exposed the updates process and opened up the possibilty for the time spent in updates-testing to be used in developing scripted QA tailored to each package in order to ease the maintenance burden slightly (using "beaker"[6]). [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00142.html [6] http://fedoraproject.org/wiki/QA/Beaker JoshBoyer estimated[7] that the amount of time packages would spend in updates-testing was a week. In response to Hans' question as to what factors besides freedom were important to Fedora, Josh suggested that end-user stability was important. [7] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00111.html Hans expressed[8] a general feeling that there were too many rules and procedures instead of trust, prompting agreement[9] from PatriceDumas that the merge had seen a lot of control move away from maintainers. RalfCorsepius agreed[10] and suggested that functionality testing was upstream's job and that all a packager should be responsible for was whether the package was suitable for public use. MichaelSchwendt also felt that things were becoming a bit rule-bound, but thought[11] that testing against segfaulting was essential. [8] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00212.html [9] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00214.html [10] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00222.html [11] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00224.html RahulSundaram and Michael struggled to come to some agreement over what it would mean for a reviewer to test base functionality. A concern over the possible discouragement of reviewers was capped with Michael pointing out[12] the difficulties that even large upstream teams had in testing functionality and the closing of quick fixes by what he termed a new bureaucracy. Rahul admitted that the bar had been raised for reviewers and worried that users would react negatively to broken packages. Michael thought[13] that the new updates system was lacking in specific promised QA resources because FESCo had let the ball drop on these issues. ThorstenLeemhuis was strongly in agreement[14], feeling that the transition to Koji had not been accompanied by the necessary agreements about how it would be used, resulting in loss of community control. NicolasMailhot disagreed[15], and was suspicious of the frequent invocation of "community" in defence of large packagers to do what they wanted. Nicolas also noted that the transition had gone very smoothly. In response PatriceDumas drew[16] a distinction between packaging guidelines (which were under community control) and process and workflow (which were not). [12] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00230.html [13] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00232.html [14] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00259.html [15] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00285.html [16] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00287.html A thoughtful post[17] from ToshioKuratomi responded to Thorsten's assertions about loss of community control by suggesting that what was happening was delegation of some jobs to teams (such as ReleaseEngineering and Infrastructure) and the absorption of the old core-packagers into the community. [17] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00299.html JesseKeating made sure[18] that it was clear that not every update had to go through updates-testing, and seemed to answer Hans' query about how to expose users easily to the availability of new updates. Discussion[19] about the mechanism seemed to end in a workable resolution. [18] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00087.html [19] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00134.html === Fedora Image As A GRUB Entry === Picking up on a report from ChristopherAillon about how he upgraded, JefSpaleta suggested[1] that it would be nice to provide an F7 package that created a GRUB bootmenu entry and an installer for F8. This would allow users without a DVD writer to do a network upgrade via the installer instead of a yum upgrade. [1] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00109.html WillWoods was among the many keen on the idea and suggested[2] the likely things such an installer would do. ColinWalters and Will were especially interested[3] in the possibility this opened up for regression testing of rawhide on a regular basis. SethVidal suggested caution[4] as many of the more fundamental changes (e.g. transition ext3->ext4) would not be easy to do on a live system. AlexanderBostrom wondered[5] if that specific transition could be handled by having everything downloaded and then using a pivot root similar to the manner in which anaconda does things. [2] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00112.html [3] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00119.html [4] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00135.html [5] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00208.html SindrePedersenBjordal reminded[6] the list that he had already posted about a package he had created that did exactly what was proposed. [6] https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00308.html https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00109.html see also https://www.redhat.com/archives/fedora-devel-list/2007-June/msg00016.html == Maintainers == In this section, we cover Fedora Maintainers, the group of people who maintain the software packages in Fedora https://www.redhat.com/mailman/listinfo/fedora-maintainers Contributing Writer: MichaelLarabel === EPEL Report Week 20 === The results of the weekly EPEL meeting were published to the fedora-maintainers-list[1]. In this meeting, MikeMcGrath discussed the standing proposal to provide RHEL subscriptions to EPEL packagers, six new contributors were introduced bringing the total number of EPEL contributors to eighty, and now in total for EPEL 5 there are over 470 binary packages (EPEL 4 binary package count is currently at 358). [1] https://www.redhat.com/archives/fedora-maintainers/2007-May/msg01000.html === Bodhi and Fedora 7 === In time for the release of Fedora 7, BillNottingham announced that Bodhi is now available[1]. For those out of the loop, Bodhi is a modular Turbo Gears system for issuing updates. AxelThimm had also requested a how to for bohdi[2]. [1] https://www.redhat.com/archives/fedora-maintainers/2007-May/msg01025.html [2] https://www.redhat.com/archives/fedora-maintainers/2007-June/msg00030.html == Documentation == In this section, we cover the Fedora Documentation Project. http://fedoraproject.org/wiki/DocsProject Contributing Writer: JonathanRoberts === Fedora Documentation Steering Committee Meeting === The IRC log[1] and the summary[2] of the FDSCo meeting, from 27 May were posted to the docs-list. [1] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00163.html [2] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00165.html === Meeting Location === KarstenWade proposed that the FDSCo move their meetings to the #fedora-meeting channel, as he believes more people are lurking there from across the whole project, and might encourage them to get involved with the documentation project meetings[1]. It was well received but decided that the current meeting time on a Sunday was too distracted by outside life, so the meeting time has been moved to 1600UTC on Tuesdays[2]. [1] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00177.html [2] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00182.html === ISO and Web-Only Release Notes === DimitrisGlezos writes[1] to the docs-list to remind people that the release notes[2] are published in two locations for the two different types. The release notes included in the ISO (that is, in F7 itself)[3], and the updated, current ones (also called Web-only because they are not included in the release)[4]. All translated docs that were included in the release should exist in[3] and be linked from[2]. [1] https://www.redhat.com/archives/fedora-docs-list/2007-May/msg00184.html [2] http://docs.fedoraproject.org/release-notes/f7/ [3] http://docs.fedoraproject.org/release-notes/f7/iso/ [4] http://docs.fedoraproject.org/release-notes/f7/<lang>/ === Documentation for Revisor and Other Spin-Making Tools === With the release of Fedora 7 there is one significant new feature that needs proper documentation: custom spins[1]. Anybody wanting to help contribute documentation for Revisor, Pungi, or Live CD Tools should post to the fedora-docs-list[2]. [1] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00001.html [2] https://www.redhat.com/archives/fedora-docs-list/2007-June/msg00007.html == Infrastructure == In this section, we cover the Fedora Infrastructure Project. http://fedoraproject.org/wiki/Infrastructure === Infrastructure Server Organization === MikeMcGrath and others had a discussion this week about Apache tweaks[1] and general network setup[2]. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-May/msg0019… [2] https://www.redhat.com/archives/fedora-infrastructure-list/2007-May/msg0020… === Bodhi === LukeMacken and others got Bodhi[1] up and running this week. [1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-May/msg0026… === New Projects === Following the Fedora 7 release, two of the new initiatives requiring Infrastructure resources were posted about this week. DimitrisGlezos is kicking off[1] his Summer of Code effort[2], which involves a common WebUI for Fedora translators that can be used for contributing up stream as well. Another project waiting for Fedora 7 is the click-through CLA for the Wiki, which replaces the need to have a GPG-signed CLA before contributing to the Wiki. KarstenWade is requesting[3] an Infrastructure resource to assist with this effort. [1] http://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg0004… [2] http://fedoraproject.org/wiki/SummerOfCode/2007 [3] http://www.redhat.com/archives/fedora-infrastructure-list/2007-June/msg0003… == Artwork == In this section, we cover Fedora Artwork Project. http://fedoraproject.org/wiki/Artwork Contributing Writer: JonathanRoberts === Fedora 7 Disc Labels === LuyaTshimbalanga posted the final artwork for the Fedora 7 CD labels[1], with the color stripped out from the original EPS in 8 monochrome colors. The artwork is available as both an SVG and an EPS. Shortly afterward, an updated SVG was also posted[2]. [1] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00053.html [2] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00054.html Editor's Note: Official Fedora 7 Labels are available at http://fedoraproject.org/wiki/Artwork/CDArt === Default Desktop Theme? === A message was posted to the art-list suggesting that the Fedora theme needs to be "polished"[1]. The central argument was that although the artwork sees a lot of attention every release, the theme - including panels and window borders - looks the same each release[2]. Linux Mint and Ubuntu Studio were both used as examples of what could be achieved, but it appears that for any new theme to receive popular backing, it can't resemble Vista[3]. [1] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00060.html [2] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00064.html [3] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00067.html === Fedoraproject.org Banners === Nown that the new home page is in place, the idea has been proposed to include banners advertising special events and drawing focus to community created spins of Fedora. Anybody interested in creating banners for the home page should post to the fedora-art-list[1]. [1] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00069.html === Brazilian Banners === JaymeAyres contributed some banners he created to the list[1]. They are animated GIFs using the Flying High theme and were very well received. [1] https://www.redhat.com/archives/fedora-art-list/2007-May/msg00082.html [2] https://www.redhat.com/archives/fedora-art-list/2007-June/msg00000.html == Advisories and Updates == In this section, we cover Secuirity Advisories and Package Updates from fedora-package-announce. Contributing Writer: ThomasChung === Fedora 7 Advisories and Updates === * 2007-06-02 [SECURITY] seamonkey-1.1.2-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0066 * 2007-06-02 agistudio-1.2.3-3.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0015 * 2007-06-02 archivemail-0.7.0-5.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0014 * 2007-06-02 dgae-1.1-3.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0013 * 2007-06-02 liferea-1.2.10c-3.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0041 * 2007-06-02 nagi-2.06-3.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0012 * 2007-06-02 revisor-2.0.3.6-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0065 * 2007-06-02 roundcubemail-0.1-0.5.beta2.2.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0016 * 2007-06-02 sergueis-destiny-1.1-4.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0010 * 2007-06-01 [SECURITY] galeon-2.0.3-9.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0050 * 2007-06-01 bugzilla-3.0-3.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0017 * 2007-06-01 jd-1.9.5-0.3.beta070528.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0043 * 2007-05-31 [SECURITY] devhelp-0.13-8.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0006 * 2007-05-31 [SECURITY] epiphany-2.18.1-3.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0008 * 2007-05-31 [SECURITY] firefox-2.0.0.4-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0001 * 2007-05-31 [SECURITY] jasper-1.900.1-2.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0005 * 2007-05-31 [SECURITY] libexif-0.6.15-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0003 * 2007-05-31 [SECURITY] libpng10-1.0.26-1.fc7.1 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0004 * 2007-05-31 [SECURITY] mutt-1.5.14-4.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0002 * 2007-05-31 [SECURITY] yelp-2.18.1-4.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0009 * 2007-05-31 libwnck-2.18.2-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-0007 === Fedora Core 6 Advisories and Updates === * 2007-06-02 gnome-python2-extras-2.14.2-10.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-564 * 2007-06-02 gpm-1.20.1-84.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-563 * 2007-06-02 kexec-tools-1.101-56.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-560 * 2007-06-02 selinux-policy-2.4.6-74.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-543 * 2007-05-31 [SECURITY] devhelp-0.12-11.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-549-2 * 2007-05-31 [SECURITY] epiphany-2.16.3-5.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-549-1 * 2007-05-31 [SECURITY] firefox-1.5.0.12-1.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-549 * 2007-05-31 [SECURITY] thunderbird-1.5.0.12-1.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-550 * 2007-05-31 [SECURITY] yelp-2.16.0-13.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-549-3 * 2007-05-31 elinks-0.11.1-5.2 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-556 * 2007-05-31 logrotate-3.7.4-14.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-558 * 2007-05-30 [SECURITY] mutt-1.4.2.3-1.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-539 * 2007-05-30 bind-9.3.4-6.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-531 * 2007-05-30 kernel-2.6.20-1.2952.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-513 * 2007-05-30 lftp-3.5.9-0.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-431 * 2007-05-30 net-tools-1.60-76.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-530 * 2007-05-30 selinux-policy-2.4.6-72.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-521 * 2007-05-30 squid-2.6.STABLE13-1.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-535 * 2007-05-30 system-config-soundcard-2.0.6-6.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-537 * 2007-05-30 vsftpd-2.0.5-10.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-536 === Fedora Core 5 Advisories and Updates === * 2007-06-02 gpm-1.20.1-84.fc5 - http://fedoraproject.org/wiki/FSA/FC5/FEDORA-2007-562 * 2007-05-31 [SECURITY] devhelp-0.11-7.fc5 - http://fedoraproject.org/wiki/FSA/FC5/FEDORA * 2007-05-31 [SECURITY] epiphany-2.14.3-6.fc5 - http://fedoraproject.org/wiki/FSA/FC5/FEDORA * 2007-05-31 [SECURITY] firefox-1.5.0.12-1.fc5 - http://fedoraproject.org/wiki/FSA/FC5/FEDORA * 2007-05-31 [SECURITY] lha-1.14i-20 - http://fedoraproject.org/wiki/FSA/FC5/FEDORA * 2007-05-31 [SECURITY] seamonkey-1.0.9-1.fc5 - http://fedoraproject.org/wiki/FSA/FC5/FEDORA * 2007-05-31 [SECURITY] thunderbird-1.5.0.12-1.fc5 - http://fedoraproject.org/wiki/FSA/FC5/FEDORA * 2007-05-31 [SECURITY] yelp-2.14.3-5.fc5 - http://fedoraproject.org/wiki/FSA/FC5/FEDORA * 2007-05-31 logrotate-3.7.3-3.fc5 - http://fedoraproject.org/wiki/FSA/FC5/FEDORA * 2007-05-30 [SECURITY] mutt-1.4.2.1-8.fc5 - http://fedoraproject.org/wiki/FSA/FC5/FEDORA-2007-540 * 2007-05-30 gd-2.0.33-8.fc5 - http://fedoraproject.org/wiki/FSA/FC5/FEDORA-2007-542 * 2007-05-30 irqbalance-0.55-4.fc5 - http://fedoraproject.org/wiki/FSA/FC5/FEDORA-2007-532 == Events and Meetings == In this section, we cover event reports and meeting summaries from various projects. Contributing Writer: ThomasChung === Event Report: IV ESLAM - Amazon, Brazil === * https://www.redhat.com/archives/fedora-ambassadors-list/2007-May/msg00162.h… === Fedora Ambassadors Meeting Minutes 2007-MM-DD === * No report in this week === Fedora Documentation Steering Committee 2007-MM-DD === * No report in this week === Fedora Engineering Steering Committee Meeting 2007-05-31 === * http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070531 === Fedora Packaging Committee Meeting 2007-05-29 === * https://www.redhat.com/archives/fedora-maintainers/2007-May/msg01015.html === Fedora Release Engineering Meeting 2007-MM-DD === * No report in this week == Feedback == This document is maintained by the Fedora News Team[1]. Please feel free to contact us to give your feedback. If you'd like to contribute to a future issue of the Fedora Weekly News, please see the Join[2] page to find out how to help. [1] http://fedoraproject.org/wiki/NewsProject [2] http://fedoraproject.org/wiki/NewsProject/Join -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung

1 0

Cooperative Bug Isolation for Fedora 7
by Ben Liblit 03 Jun '07

03 Jun '07

The Cooperative Bug Isolation Project (CBI) is now available for Fedora 7. CBI (http://www.cs.wisc.edu/cbi/) is an ongoing research effort to find and fix bugs in the real world. We distribute specially modified versions of popular open source software packages. These special versions monitor their own behavior while they run, and report back how they work (or how they fail to work) in the hands of real users like you. Even if you've never written a line of code in your life, you can help make things better for everyone simply by using our special bug-hunting packages. We currently offer instrumented versions of Evolution, The GIMP, GNOME Panel, Gnumeric, Nautilus, Pidgin, Rhythmbox, and SPIM. Download at <http://www.cs.wisc.edu/cbi/downloads/>. We support yum, apt, and many other RPM updater tools; see <http://www.cs.wisc.edu/cbi/downloads/repo-config.html> for customized configuration help for any of our supported distributions and updater tools. Or just download and install <http://www.cs.wisc.edu/cbi/downloads/rpm/fedora-7-i386/RPMS.tools/cbi-packa…> to automatically configure most popular RPM updaters to use the CBI repository. It's that easy! Tell your friends! Tell your neighbors! The more of you there are, the more bugs we can find. We still offer CBI packages for Fedora Core 1/2/4/5/6 as well. When and if you decide to upgrade to Fedora 7, we'll be ready for you. Until then, your participation remains valuable! -- Dr. Ben, the CBI guy

1 0

Discounts on Red Hat training for Fedora folks
by Max Spevack 01 Jun '07

01 Jun '07

To the Fedora community: The last 8 months have been very exciting for Fedora. We released Fedora Core 6 (Zod) in October. Fedora 7 (Moonshine) was released yesterday, and it is the most ambitious release that the Fedora Project has undertaken. The nature of Fedora is such that many of our contributors and users are very technical, and make Linux their careers as well as their hobbies. We know that many Fedora contributors and users hold RHCT, RHCE, or RHCA certifications. Obviously, we are happy that you choose Red Hat Training and and we appreciate your business. As a way of saying thank you to our community, we are pleased to offer special discounts to Fedora contributors who register for upcoming Red Hat training courses. We know that many of you are taking these classes anyway, and we'd like to make it a bit easier on your wallet. We have two separate offers, valid in multiple regions. The details vary slightly depending on region (read on below), and the offer is valid for classes that are offered directly by Red Hat (not by Red Hat's training partners). All of the details are on the web: https://www.redhat.com/training/fedora_training_discount.html http://www.redhat.com/training/ In short, however, if you are an active Fedora contributore (you have a @fedoraproject.org email address), you can get up to 20-25% almost any Red Hat training class. For Fedora users (people who have installed or are using Fedora), the discounts available are between 5-25%, depending on your region. ---- This is the first time that we have tried something like this. I hope that members of the Fedora community may find it useful. If there are any question or complaints, please let me know, and I will work through them with the Red Hat Training team, and get answers. Please feel free to share this offer with anyone you know in the Fedora community who might be interested. Thanks!

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 June 2007