m (1 revision(s)) |
m (Zh CN/FWN/Issue98 moved to Archive:Zh/FWN/Issue98) |
(No difference)
| |
Revision as of 12:39, 28 September 2008
Fedora 新闻周刊第 98 期
欢迎查看 Fedora 新闻周刊第 98 期，自 2007-07-22 到 2007-07-30。
这一周，较为重大的公告包括扩展仓库企业版(Extras EPEL)，3000 个 Fedora 7 安装，以及 FESCo 选举结果。另外我们开辟了新的栏目称为"问帽子"，来向 Fedora 项目提问吧。
开发中的讨论有趣而激烈，包括 RPM 路线图，Fedora 声音系统，桌面菜单，软件包授权等等。在安全周刊中，我们的安全响应小组报告了一个危险的 Firefox 漏洞。在每日软件包中，你会发现 Fedora 软件包的介绍，包括 Incron, eSpeak, Syslog, Seamonkey, BSD-Games。
要加入我们或反馈意见，请访问 http://fedoraproject.org/wiki/NewsProject/Join
Announcements
In this section, we cover announcements from various projects.
Contributing Writer: ThomasChung
扩展软件包企业版开放(EPEL)
KarstenWade announces in fedora-announce-list[1] ,
"If you use enterprise-class Linux (EL) distributions derived from Fedora, such as Red Hat Enterprise Linux or CentOS, we have something very exciting for you."
"EPEL[2] is a community of package maintainers working from inside of Fedora. Many are the same people who maintain the Fedora version. Yet, there room for new packages and contributors. Currently, around 1000 packages are available, and we've been growing at the rate of several dozen packages every week."
[1] https://www.redhat.com/archives/fedora-announce-list/2007-July/msg00012.html
[2] http://fedoraproject.org/wiki/EPEL
3000 个 Fedora 7
NayyarAhmad announces in fedora-ambassadors-list[1] ,
"After a long discussions and few presentation, i have convinced Mozambique[2] Ministry of Finance (SISTAFE) to migrate their workstation around the country from MS Windows to Linux (Fedora 7), now they have officially approved the migration country wide and i will supervise this migration, plus will help them in end user training, its the first time in Mozambique that a Govt. department have opt for Linux (Fedora) and in my opinion it has been a big achievement, as after their migration i will be able to speak with other ministries and private firms."
[1] https://www.redhat.com/archives/fedora-ambassadors-list/2007-July/msg00075.html
[2] http://en.wikipedia.org/wiki/Mozambique
FESCo 选举结果
BrianPepple announces in fedora-announce-list[1] ,
"The FESCo[2] election is over, and the members for the 2007/2008 FESCo are (in alphabetical order): ChristopherAillon, JoshBoyer, TomCallaway, KevinFenzi, DennisGilmore, ChristianIseli, JeremyKatz, JesseKeating, BillNottingham, BrianPepple, JasonTibbitts, WarrenTogami, DavidWoodhouse"
[1] https://www.redhat.com/archives/fedora-announce-list/2007-July/msg00011.html
[2] http://fedoraproject.org/wiki/Development/SteeringCommittee
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
改进软件包和系统管理
RahulSundaram points out in his blog[1] ,
"The most important improvement of course is the ongoing development of wevisor[2] , which as the name indicates is a web interface to revisor that lets you do custom spins of Fedora. Kickstart configuration files can be fed into a number of places such as live cd tools, revisor and wevisor and adds a whole lot of customisability to Fedora."
[1] http://rahulsundaram.livejournal.com/12108.html
[2] http://hosted.fedoraproject.org/projects/wevisor
首个 rpm.org 版本的 RPM 发布
RolandWolters points out in his blog[1] ,
"Recently the first version of rpm.org[2] ’s RPM tool was released. While it is only a minor version (4.4.2.1) this release is a milestones because it is a coordinated release between the participating distributions."
[1] http://liquidat.wordpress.com/2007/07/24/first-rpmorg-rpm-version-released/
[2] http://rpm.org/
Ask Fedora
Beginning this week, we will collect good and useful questions from users for this special section called 'Ask Fedora'.
Contributing Writers: RahulSundaram, ThomasChung, PaulFrields, ChrisTyler
Questions should exclude topics which are best answered through existing mechanisms. This shouldn't be for "my soundcard doesn't work" questions; it should be for big-picture questions of general interest.
Esoteric hardware troubleshooting problems are a deal-killer, but more general help questions like "How do I edit my menus?" or "How do I find source code for <FOO>?" are good targets.
To submit your questions, please use askfedora@fedoraproject.org and our news team will *try* to find the best answers and post in the following issue.
Marketing
In this section, we cover Fedora Marketing Project.
http://fedoraproject.org/wiki/Marketing
Contributing Writer: ThomasChung
Fedora 8 将集成 OpenJDK
RahulSundaram reports in fedora-marketing-list[1] ,
""One of the most recently added features to the Fedora 8 feature list is IcedTea[2] , which is the open-source version of Java (OpenJDK). The plan is to make IcedTea the default JPackage environment and will replace GCJ. There are Fedora packages for IcedTea already maintained (at ClassPath.org) and the dependencies needed to build IcedTea can already be found in Fedora Rawhide."
[1] https://www.redhat.com/archives/fedora-marketing-list/2007-July/msg00067.html
[2] http://fedoraproject.org/wiki/Features/IcedTea
每口锅里都有一台计算机
RahulSundaram reports in fedora-marketing-list[1] ,
"The user interface is called Sugar and not the OS itself but a good article nevertheless. BBC published a couple of articles with more technical information and videos featuring Christopher Blizzard, lead OLPC team in Red Hat."
[1] https://www.redhat.com/archives/fedora-marketing-list/2007-July/msg00057.html
Fedora 的统计反映了 Linux 的一些事
RahulSundaram reports in fedora-marketing-list[1] ,
Joe 'Zonker' Brockmeier talks with Fedora's Max Spevack about some recently released statistics. "The Fedora Project offered a peek under its kimono recently with details about Fedora 7 adoption and other statistics. Fedora 7 has snagged more than 300,000 users since its release at the end of May. While that sounds pretty good, Fedora Core 6 managed to attract more than 400,000 in roughly the same amount of time after its release. We asked Max Spevack, the Fedora project leader, whether the numbers are telling the full story."
[1] https://www.redhat.com/archives/fedora-marketing-list/2007-July/msg00050.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
RPM 路线图 ... Panu 打开了潘多拉魔盒
A "slightly bored" PanuMatilainen solicited[1] suggestions for how rpm could be improved. Panu was concerned that non-subscribers to @rpm-maint[2] should get an opportunity to point out deficiencies which could be corrected now that 4.4.x was branched to maintenance mode and it was time to plan the next major release. The result was a thoughtful thread which largely failed to deliver the evil which Panu feared.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01537.html
[2] https://lists.rpm.org/mailman/listinfo/rpm-maint
The issue of multilib support was first raised[3] by "Dragoran", who thought that "arch requires and provides" should be automatic unless the packager manually intervened. TomCallaway (spot) was strongly in agreement. DavidWoodhouse followed up later by referencing[4] the tracker bugzilla entry which shows the extensive thought and discussion he has put into the issue of multilib support.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01541.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01557.html
DimiPaun posted[5] an extensive list of suggestions including version-control of meta-information to allow admins to pinpoint specific changes due to package updates and the provision of more fine-grained transaction information to external tools. The issue of transactions was also raised separately[6] by MatthiasClasen who requested "a working %posttrans". This prompted requests as to what he found broken, and lead to JeremyKatz explaining that multiple, small transactions were preferable to fewer, large ones due to their robustness in the face of power failure and that once this was achieved there was little advantage of "%posttrans" after "%post". ColinWalters linked[7] to the Stateless Client approach to avoiding power failure problems. Dimi argued that Jeremy might be right about the power-failure scenario, but that for all others multiple transactions would diminish the atomicity and integrity of rpm's workings. SethVidal didn't precisely disagree[8] but seemed to consider that Jeremy's scheme would provide more of the granularity of information that Dimi wanted.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01543.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01545.html
[7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01569.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01599.html
Responding[9] to Dimi's point OwenTaylor returned to the stateless-client model emphasizing that it was important to make system transactions as ACID as possible and not necessarily rpm transactions. Dimi agreed[10] that this was a non-trivial problem and suggested that LVM's snapshot capabilities could help out.
[9] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01612.html
[10] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01618.html
JeffSpaleta wanted[11] some way of marking packages which were installed explicitly (rather than automatically to satisfy dependencies). "Topher" suggested reference counting, prompting Jef to wonder what would be counted and to restate the problem[12] from a dependency-tree perspective. SethVidal was in agreement with Jef that avoiding an external database was prudent, but was cautious[13] about how long it would take to implement labelling such packages.
[11] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01607.html
[12] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01613.html
[13] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01610.html
A sarcastic response from RobertScheck[14] argued that most of what Panu and others were talking about was either already in the rpm5 fork or else planned to be in it. Robert asked for clarification on a couple of points, including MatthiasClasen's wish for smart directory handling. Matthias specified[15] that he thought a package should own all directories it creates or else explicitly require a package which creates a directory which it uses.
[14] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01605.html
[15] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01606.html
There many other interesting suggestions and also some great incidental information about rpm usage. In this category BrunoWolff wished[16] that there were some way of extending the length of rpm's argument list leading JeremyKatz and BillCrawford to point out that hidden away in the manpage is the info that a manifest list (which can include globs) can be used instead of a specific package name.
[16] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01590.html
Similarly MikeChamber's musing about a way to recover from the accidental removal of essential rpm libraries led ManuelWolfshant to point[17] to the "--repackage" option which the manpages say can be used in conjunction with an erase. RobertScheck's claim that rpm5 had a special rollback feature that did this spurred Panu to respond[17] that the "--repackage" option was ancient.
[17] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01659.html
软件包管理的争论
In an independently initiated discussion which overlapped with many of the issues discussed in another thread covered here (FWN#98 "RPM Roadmap ... Panu Opens Pandora's Box") RichardHughes asked[1] for comments on one of his recent blog postings. Richard argued[2] that software install and updating tools were prone to information loss, were user-unfriendly, were hard to maintain, and that Ubuntu was at the head of an inferior pack. Richard's main thrust seemed to be to make package management a D-BUS integrated system service and to make the various dependency solvers backends, leading to separation out of the GUI or other interfaces.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01523.html
[2] http://hughsient.livejournal.com/31429.html
An enthusiastic affirmation from "Dragoran" on fixing the problem of "hung" progress-bars in the US by making the API asynchronous was initially squashed by JeremyKatz as rpm/sqlite wouldn't play well with multithreading. DavidZeuthen clarified[3] that multithreading wasn't necessary for an asynchronous API or proposed by Richard.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01625.html
BillNottingham reminded[4] the list that a similar discussion had been had before with regard to "yum-updatesd" and the choices roughly boiled down to making yum-updatesd so simple that it would not even check the currently installed packages, or extending it to a being a package-manager which could run unprivileged. Bill thought that latter would be a yum/rpm specific version of what Richard was proposing. He noted that the goal of making it work with .debs or other packaging specifications didn't seem interesting to him. SethVidal was highly skeptical[4a] that working to get a common API between the different packager formats was possible, noted the huge amount of coding that would be required and pointed out that rescue-mode would be complicated. Richard had specific rebuttals[4b] of these points and also discussed with Bill the amount of startup time that would be occasioned by his approach.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01551.html
[4a] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01578.html
[4b] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01580.html
In specific response to Bill's lack of interest in a common API MatthiasClasen thought that escaping the ghettoization of distro-specific tools to a common upsteam was important and RichardHughes confirmed[5] that the goal of making it simple for users to try new software was important. Bill wondered whether packages as opposed to "mugshot-style distributed apps" were what Richard really had in mind.
[5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01570.html
SethVidal was also unhappy with having to use D-BUS on webservers (due to what he claimed was its impact on RAM and unnecessary extra complication). ColinWalters disputed[6] the RAM usage claim and DavidZeuthen thought[7] that there would be nothing making Seth install the proposed D-BUS activated simple package management interface. He emphasized "simple".
[6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01595.html
[7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01626.html
Offering some mugshot originating code ColinWalters[8] was another enthusiast.
[8] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01572.html
[*] Craic is the healthy Hibernian version of "crack", denoting fun, discussion and general insanity. See http://en.wikipedia.org/wiki/Crack_(craic)
Pulseaudio 改善了 Fedora 声音系统
There was a happy conclusion to a thread on the state of sound and audio in Fedora which had been opened[1] by a frustrated DimiPaun. Recounting a series of failures of ALSA since FC6, which were apparently due to kernel updates Dimi concluded that such flakiness with very standard hardware was unacceptable.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01140.html
TomBrinkman thought[2] that @fedora-devel wasn't the place for such support questions and pointed out that Googling indicated that updating ALSA might work. In response to this and to JosefBacik's request for specific details Dimi explained[3] that it wasn't easy to pin down which kernel caused the problem and that he felt there was a general,underlying malaise in the development process. Dimi expanded on particular flakiness among what he regarded as essential desktop functionality which had become worse in his opinion.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01142.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01151.html
A polite response[4] from HansdeGoede asked for Dimi to substitute high-quality feedback (in the form of filing bugs) instead of inflammatory emails which no one would look at later. RahulSundaram similarly asked whether Dimi had filed bug reports and Dimi answered[5] that he had done so to no effect and that this revealed a process problem which would result in a deluge of useless bug reports were Rahul's advice to be followed. A great response[6] from JosefBacik regretted the problem but suggested that as Fedora merely packages upstream and could benefit from Dimi filing reports against the test-release of F8 so that ICH8 (the culpable sound hardware) would work in F8, Josef also suggested that a more slow-moving distro (e.g. RHEL, CentOS) might carry fewer frustrations.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01153.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01158.html
[6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01168.html
"Nodata" wanted to look at the actual bugs, so Dimi provided[7] the bugzilla entry and expanded on his point that an apparent cycle of reporting bugs, spending time on them and then being told to report the bugs upstream was being repeated and that it was too great a burden on users.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01173.html
To complicate the issue "MarkG"[8] and HenkBreimer[9] reported that the apparently same hardware worked fine for them with F7.
[8] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01187.html
[9] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01169.html
A post[10] by "Kelly" recommending the advantages of PulseAudio appeared to provide hope for the positive resolution of this problem. Confirmation of this as a solution was provided[11] when Rahul pointed out that PulseAudio was the default daemon in Fedora8. Kelly helpfully added[12] that s/he had a package which redirected the Adobe Flash through PulseAudio.
[10] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01210.html
[11] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01213.html
[12] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01233.html
Finally, Rahul asked[13] Dimi to try some potted commands to update ALSA and to let him know if it fixed the sound problem.
[13] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01486.html
桌面菜单应当包含什么
The debate over whether applications' .desktop files should be setting ShowOnlyIn (see FWN#97 "ShowOnlyIn Another GNOME Conspiracy Unmasked"[1] ) continued to yield disagreement. "Nodata" held out SuSE's "disastrous clutter" as the likely result of bowing to ChristopherStone's desire to make all applications show up in the menu. Chris refused[2] to set foot on this slippery slope and asked again why shouldn't an application which he chose to install show up in the menu?
[1] http://fedoraproject.org/wiki/FWN/Issue97#head-dfd181f0727edbc287e9ee6b942c27232649c6a8
[2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01221.html
So far this was a rehash of already covered ground and positions, but JefSpaleta and MattMiller trod a middle course[3] between complete menu mayhem and a straightjacketed system which prevent users from adding icons to their menus as they wished.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01226.html
Chris didn't think much thought was going into the default menu choices as evidenced by the fact that someone using Xfce (instead of GNOME or KDE) would not see applications like Kate or Banshee show up in their menu. BillNottingham riposted[4] that it also woouldn't make sense to show kreversi and iagno in both GNOME and KDE and wished for a DoNotShowIn in addition to OnlyShowIn. VilleSkyttä drew[5] everyone's attention to NotShowIn.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01274.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01282.html
It seemed that Chris was still in high dudgeon and JesseKeating tried[6] to refocus the discussion on the problem of shared systems and the need to avoid the application menu becoming contaminated with applications installed by users who preferred different desktop environments. Jesse thought the solution was to teach the Xfce equivalent of gnome-menu to ignore the ShowOnlyIn entries in .desktop files.
[6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01275.html
JonathanUnderwood recalled the old days when there was a KDE submenu in the GNOME menu but "nodata" thought the user experience of having to know about this and hunt around for applications would be unpleasant and it would be better to just provide KDE apps for KDE users and GNOME apps for GNOME users. Chris thought this was "so dumb it makes Microsoft engineers look like friggin' geniuses", but later[8] backed off from the personal element in this remark.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01302.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01354.html
In closing arguments JesseKeating drew Chris's attention[9] again to the problem of multiuser systems and developed the point further when requested.
[9] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01361.html
The discussion seemed to peter out with Chris and Jesse agreeing[10] on the previously stated ideal of working toward making gnome-menu and equivalents able to override ShowOnlyIn.
[10] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01365.html
MarkG was shown by ChristopherStone how to remove the problematic lines from .desktop # desktop-file-install --remove-only-show-in GNOME /usr/share/applications/gnome-banshee.desktop and ChristopherAillon provided a expansion[11] on the idea.
[11] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01592.html
Kmods 弃用
After an invitation from BrianPepple to add items to the agenda for the FESCo meeting an interesting thread developed from HansdeGoede's request[1] for clarity on the "current somewhat grey state of kmods". His proximate reason for this was that ParagN's experience suggested to him[2] that kmods were unlikely to find favour in Fedora because they were not upstream. FlorianLaRoche felt[3] that kmods were worth the pain and also was keen on seeing the gspca kmods supported in Fedora. (See FWN#).
[1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01428.html
[2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01444.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01446.html
An argument for the straight-out deprecation of kmods in Fedora was made[4] by DavidWoodhouse who thought that instead those using them should be given CVS commit access to maintain patches to the kernel which could be trivially enabled/disabled. A partial disagreement was registered[5] by ThorstenLeemhuis who lobbied[5] for deprecation in the F8 Everything spin and update-proper repository, but the creation of a replacement test repository which would make kmods available to those that needed them. Thorsten argued that there were developers not as comfortable with kernel development as David (or HansdeGoede) who nevertheless produced kmods which were useful to users. Thorsten also thought that some code which had a high probablility of not making it into the upstream (kernel) had a value for select users.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01462.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01464.html
Adding his voice[6] to David's desire to avoid troublesome kernel code was JesseKeating who thought that the overhead imposed on yum/rpm was too high. Thorsten replied[7] to David's statement that "If we don't want it Fedora's kernel RPM, then we don't want it in Fedora at all" with a reiteration of the idea that users may want lots of things that the distro doesn't so a "play" area with clear warning signs should allow them to shoot themselves in the foot if they so desire.
[6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01468.html
[7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01469.html
Thorsten also conceded[8] that David had a strong position, but linked the discussion to one happening within the FAB about who comprises Fedora's target audience and suggested that allowing a safe area for experimentation would have benefits in terms of stimulating and retaining interest among people that may later become Fedora developers or maintainers.
[8] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01474.html
HansdeGoede was broadly approving[9] of David's position, not least because it avoided having to delay kernel security updates while waiting for kmods to be fixed. After some discussion JesseKeating's worries[10] that this would result in more frequent kernel updates were dispelled[11] after David outlined how he saw the process playing out in updates and rawhide.
[9] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01471.html
[10] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01476.html
[11] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01482.html
In a related thread RalfCorsepius reported[12] a bizarre result from updating which resulted in an apparently older kmod being installed. Posts by SethVidal suggested[2] that this was due to the proper yum plugin for kmods being absent[13] .
[12] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01639.html
[13] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01673.html
新的系统更新服务进程 yum-updatesd (Rawhide 报告 2007-07-25)
A heads-up was called[1] by JeremyKatz drawing attention to a completely re-worked yum-updatesd (see "RPM Roadmap ... Panu Opens Pandora's Box" in this same FWN issue). Jeremy noted that it had been split into a two parts: a small DBUS-enabled daemon and a forked memory process which is unthreaded.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01383.html
HansdeGoede wanted to know[2] if this fixed his number one reason for not running yum-updatesd: that yum would fail if yum-updatesd was checking for updates. Hans suggested some ways of working around this problem. Jeremy responded[3] that this could still be a problem, but that it was mitigated somewhat by the fact that the process holding a lock on the database would now die-off quickly as it would not get "hung up in thread-land".
[2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01385.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01387.html
In response to Jeremy's rebuttals Hans continued to press some further suggested changes[4] concerning the detection of a collision between the two processes and the response to it.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01456.html
注意：请公布你的软件包的任何授权变动(续)
JefSpaleta agreed[1] with ThorstenLeemhuis that automatic checking of package licenses with upstream would help ease maintainer load in the simple cases of entire codebases migrating to GPLv3 from a previous license. RalfCorsepius reiterated[2] his assertions that it would not help codebases migrating from license:FOOx to license:BARy, or packages pointing to websites, and furthermore would require a large bureaucracy which would drive away contributors. AndyGreen responded[3] that these cases would be flagged as problems requiring human intervention. Ralf remained unconvinced[4] and invited the Board and the "dark forces" around it to do so without Ralf's help. This drew a certain amount of derision and disbelief and led to the revelation[5] of SethVidal as a self-confessed pusher of the changes to which Ralf objects. Seth wondered how exactly the process he was a part of could be construed as evidence of dark forces and explained that t Ralf replied with a list of "mushrooming" committees trying to "push volunteering contributors around".
[1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01232.html
[2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01235.html
[3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01236.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01240.html
[5] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01320.html
While expressing envy of Ralf's imagination NilsPhilippsen drew attention[6] to the distinction between labour-saving automation (of license checking) and bureaucracy.
[6] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01555.html
Further dispuation saw JesseKeating stating[7] that until the FSF figured out how to resolve the incompatibility between GPLv2 and GPLv3 the relicensed GNU toolchain couldn't be allowed in the distribution. Ralf recommended that he check out a discussion on the subject on the GCC list and Jesse replied[8] that he was aware of it and that it underscored the need for Fedora to be on top of any and all license changes.
[7] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01328.html
[8] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01330.html
ArjanvandeVen corrected[9] Jesse's statement of the problem, noting that co-existence of GPLv2 and GPLv3 packages was no problem, but rather in making derived works. In turn, JakubJelinek corrected[10] this statement, saying that LGPLv3 was the problem and not GPLv3. A further clarification[11] came from TomasMraz who stated the constraint as merely we just have to ensure that we don't link any gplv2 only program to such library. Such as we have to ensure that we don't link any gpl program to openssl library and so on.
[9] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01331.html
[10] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01333.html
[11] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01334.html
At this point RalfEtzinger posted a list[12] of packages which appeared to contravene this principle, again underscoring the need for this sort of information. FabioComolli posted[13] a useful link to MarkMcLoughlin's useful notes on the GPL and OpenSSL exemption. ChrisAdams provided[14] some package specific information and noted that these were "good example[s] of why license changes need to be clearly announced and researched."
[12] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01338.html
[13] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01343.html
[14] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01344.html
JeffSpaleta argued[15] that the absolutely best people to be the "we" of "we need to ensure that we don't link any gpl program to openssl library and so on" are the package maintainers as they are the experts in the libraries they maintain. ArjanVanDeVen suggested that tools could help parsing the "License" tag for mistakes and JesseKeating agreed and pointed[16] out that the FPC had been working on a syntax for the tags to enable this (see also FWN#97 "Allo Allo Wot's This 'Ere License?"[17] .)
[15] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01345.html
[16] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01350.html
扩展软件包企业版现在开放
KarstenWade announced[1] that the Extras Packages for Enterprise Linux (EPEL) repository was now open. This is of particular interest to anyone currently rebuilding packages from Fedora to use on one of the RHEL-derivatives such as CentOS, Scientific Linux or even on RHEL itself.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01516.html
Apart from the obvious advantages to those of us maintaing such systems there is also a unique opportunity for those in academia to gain experience in curating enterprise applications for a large user base.
Fedora 商标滥用
A sharp-eyed HansdeGoede spotted[1] an announcement in LWN (Linux Weekly Net) of a piece of software which called itself "EasyFedora" used a proprietary license. Hans was pretty sure that this was abusing the "Fedora" trademark.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01451.html
"Nicolas"(kwizart) noted[2] that a thread in FedoraForum requested the author to release under a non-proprietary license, but JesseKeating pointed out that regardless of the license the author had no right to use Fedora(TM) in the name of his software.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01457.html
A possible further problem was identified by KevinKofler who suggested[3] that unless the developer had a commercial Qt license then he was also violating the GPL!
[3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01493.html
A helpful TimLauridsen supplied the information about how to report trademark violations to the Fedora Project which prompted AlainPortal to ask[4] whether this was overkill and it would be better to just write to the developer and ask him to remove the offending wording. "Dragoran" thought this was a good approach, but RahulSundaram argued that "legal" would handle it politely and were the appropriate people to do so.
[4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01522.html
XFS 进入 Anaconda
A developer at Fermilab (DanYocum) requested[1] the enabling of the XFS filesystem in anaconda (the installer). Dan attested to the succesful inclusion of XFS upstream in the kernel, the realworld experience of successful installs and circa 1 Petabyte of running disks at Fermilab.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01496.html
JesseKeating asked how SELinux support was these days and why he couldn't boot from XFS. EricSandeen confessed[2] that errors in FC6 with regard to SELinux could be blamed on him, but that they seemed to be fixed now after a trivial error had been corrected. Eric noted that booting from XFS in SuSE worked fine and suggested that a since resolved GRUB error may have been responsible for corruption in both ext3 and xfs. Finally Eric admitted that it wasn't possible to install GRUB to an XFS partition but the MBR worked fine.
[2] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01506.html
In response to Eric's questioning Jesse provided the information that anaconda consistently choked on XFS for him and Eric wondered[3] whether GRUB was to blame still and how hard it would be to create a test anaconda. Jesse thought it wouldn't be too difficult and pointed[4] to exactly how this could be done.
[3] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01509.html
[4] https://www.redhat.com/archives/fedora-devel-list/2007-July/msg01512.html
Translation
This section, we cover the news surrounding the Fedora Translation (L10n) Project.
http://fedoraproject.org/wiki/L10N
Contributing Writer: JasonMatthewTaylor
F7 发行注记更新
PaulFrields mentioned here[1] that an update of the release notes package is on the horizon. There are a few locales that need fixes, as of 28-Jul-07 they were el es fi pa pt_BR sr uk zh_CN.
[1] https://www.redhat.com/archives/fedora-trans-list/2007-July/msg00094.html
Infrastructure
In this section, we cover the Fedora Infrastructure Project.
http://fedoraproject.org/wiki/Infrastructure
Contributing Writer: JasonMatthewTaylor
关于导师的 HowTo
MikeMcGrath has put some documentation up[1] on how to sponsor, how to get a sponsor and what the different groups are and what they do. Additions and clarifications are always welcome.
[1] https://www.redhat.com/archives/fedora-infrastructure-list/2007-July/msg00157.html
Artwork
In this section, we cover Fedora Artwork Project.
http://fedoraproject.org/wiki/Artwork
Contributing Writer: JonathanRoberts
Echo 图标项目迁移
LuyaTshimbalanga wrote to the list suggesting that it might be a good idea to move the Echo icons to a host other than the wiki[1] . This will result in faster upload speeds, making it easier for contributors to make improvements to existing icons and to create new ones. As well as improving speeds, this should allow the use of a revision control system, rather than relying on the current echo-pull script.
A ticket was opened with the Fedora infrastructure team, and work is underway to move the Echo icon theme to hosted.fedoraproject.org[2] , and will use the Git revision control system. Currently the Echo icons are hosted at luya.fedorapeople.org/images/echo[3] .
[1] https://www.redhat.com/archives/fedora-art-list/2007-July/msg00144.html
[2] https://www.redhat.com/archives/fedora-art-list/2007-July/msg00149.html
[3] https://www.redhat.com/archives/fedora-art-list/2007-July/msg00153.html
Nodoka 引擎 0.5 发布
The Nodoka theme engine has released its 0.5 version, including a significant number of updates[1] .
[1] https://www.redhat.com/archives/fedora-art-list/2007-July/msg00152.html
Fedora 8 主题讨论
MairinDuffy has sent a message informing the Art team that they have been given the authority to determine the final artwork and themes for Fedora 8. While this is great news, there are now decisions for the team to make, including which theme engine and icon theme to use as default in Fedora 8[1] .
[1] https://www.redhat.com/archives/fedora-art-list/2007-July/msg00154.html
Security Week
In this section, we highlight the security stories from the week in Fedora.
Contributing Writer: JoshBressers
危险的 Firefox 漏洞
This week there has been a fair amount of talk regarding a new Firefox flaw that can allow a web site to execute arbitrary commands as the user running Firefox. Window Snyder has more information about this here[1] .
[1] http://blog.mozilla.com/security/2007/07/25/launching-local-programs-through-filetype-handler
It turns out that the issue here is how Firefox launches helper applications. Specifically, how Firefox launches helper applications in Windows. In the Linux version of Firefox, when a helper is launched Firefox will do a forkexec of the binary. This basically means that the way the arguments are passed to the helper are well understood. In the windows world, this is not well understood and has led to confusion and a rather dangerous security flaw. What's happening is basically that the URL is handed to a special Windows function that builds the argument list, then launches the URL handler. This is a perfect example of why relying on closed source solutions are a problem. Nobody actually understood this problem for several days, and even now how can it be proven the Firefox fix will be correct? Without the ability to view the source, or adhere to standards, application writers are at a serious disadvantage. It is very likely that there are countless other applications that suffer from this same bug, but since they lack the attention Firefox has, the bug will never be fixed. IE even suffers from this flaw, which Microsoft claims isn't really a security bug.
It's easy to say that open source has significant security advantages, but situations like this make it hard to believe any argument in favor of a closed system.
Daily Package
In this section, we recap the packages that have been highlighted as a Fedora Daily Package. We're looking for suggestions for packages to feature -- please suggest your favorites using the Suggest a Package box on the right-hand side of the Fedora Daily Package home page[1] .
[1] http://dailypackage.fedorabook.com/
Contributing Writer: ChrisTyler
Incron - 根据文件系统变动执行命令
Productive Mondays highlight a timesaving tool. This Monday[1] we covered Incron[2] :
"Incron is a new tool modeled after cron which executes commands when a filesystem event occurs. Without polling, Incron can watch a specific file or an entire directory for new files, file writes, closures, deletions, or other activity."
eSpeak - 语音合成
Artsy Tuesdays highlight a graphics, video, or sound application. This Tuesday[1] eSpeak[2] was featured:
"eSpeak is a speech synthesis package which provides an alternative to the better-know Festival synthesizer."
[2] http://espeak.sourceforge.net/
周三为什么：Syslog
The Wednesday Why article[1] took a look at Fedora's syslog configuration:
"The /var/log directory contains a number of different log files. Many of these logs are generated by syslogd, which accepts log messages from programs and routes them to log files, the screen, and remote log monitors."
[1] http://dailypackage.fedorabook.com/index.php?/archives/104-Wednesday-Why-Syslog.html
Seamonkey - Mozilla 套件
GUI Thursdays highlight software that provides, enhances, or effectively uses a GUI interface. This Thursday[1] , Seamonkey[2] was discussed:
"If you miss the bundled features of the Mozilla Suite, the Seamonkey package will give you what you want: web browser, e-mail and newsgroup client, address book, WYSIWYG page editor, IRC client, DOM inspector, and JavaScript debugger, all integrated into a single program."
[1] http://dailypackage.fedorabook.com/index.php?/archives/105-GUI-Thursday-Seamonkey-Mozilla-suite.html
[2] http://www.mozilla.org/projects/seamonkey/
BSD-Games: 文本游戏
Friday Fun highlights fun, interesting, and amusing programs. This Friday[1] , we took a look at BSD-Games[2] :
"In the 70's and 80's, many Unix systems came with several dozen text-based games and amusements... if you're feeling nostalgic or if you've never encountered these classic games, it's worth checking out the bsd-games package."
[1] http://dailypackage.fedorabook.com/index.php?/archives/106-Friday-Fun-BSD-Games-Text-games.html
[2] ftp://metalab.unc.edu/pub/Linux/games/
Advisories and Updates
In this section, we cover Security Advisories and Package Updates from fedora-package-announce.
Contributing Writer: ThomasChung
Fedora 7 安全警告
- [SECURITY] bind-9.4.1-7.P1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1247
- [SECURITY] drupal-5.2-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1295
- [SECURITY] lighttpd-1.4.16-1.fc7 - http://fedoraproject.org/wiki/FSA/F7/FEDORA-2007-1299
Fedora Core 6 安全警告
- [SECURITY] bind-9.3.4-7.P1.fc6 - http://fedoraproject.org/wiki/FSA/FC6/FEDORA-2007-647
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
Fedora Ambassadors Meeting 2007-07-26
Fedora Documentation Steering Committee 2007-MM-DD
- No Report
Fedora Engineering Steering Committee Meeting 2007-07-26
Fedora Extra Packages for Enterprise Linux Meeting (Log) 2007-07-26
Fedora Infrastructure Meeting (Log) 2007-07-26
Fedora Packaging Committee Meeting 2007-MM-DD
- No Report