Fedora 新闻周刊第 121 期
欢迎阅览 Fedora 新闻周刊第 121 期，记载自 2008-02-18 起一周事件。本页永久链接为 http://fedoraproject.org/wiki/zh_CN/FWN/Issue121
本周的主要内容有：
"公告部分", "Fedora 10's FUDCon", "LWN订阅?", "Fedora业余无线电SIG" "Fedora教育SIG"
In Planet Fedora, we have "What a FOSDEM Day!", "FOSDEM08 - Saturday", "The FOSDEM Buzz", "LWN, Fedora and you", "Fedora 10's FUDCon" and "Fedora by Night"
公告
Fedora 10's FUDCon
MaxSpevack announces in fedora-announce-list[1] ,
"下个月北美的FUDCon将会在Boston,MA举行。举行日期是6月19－21，和今年的Red Hat高峰会议同期举行。"
[1] https://www.redhat.com/archives/fedora-announce-list/2008-February/msg00007.html
LWN subscription?
JeffSpaleta announces in fedora-announce-list[1] ,
"为了支持LWN.net的10周年纪念，Fedora Project购买了65份订阅给Fedora贡献者们。"
[1] https://www.redhat.com/archives/fedora-announce-list/2008-February/msg00010.html
Fedora业余无线电SIG
BobJensen announces in fedora-announce-list[1] ,
"我很高兴宣布一个新的特别网络小组在Fedora社区成立，即Fedora业余无线电SIG，也叫Fedora-Hams。"
[1] https://www.redhat.com/archives/fedora-announce-list/2008-February/msg00009.html
Fedora教育SIG
SebastianDziallas announces in fedora-announce-list[1] ,
"我很乐意鼓励那些对教育有兴趣的人通过fedora-education-lis加入我们，并把他们的名字放到wiki的列表上。"
[1] https://www.redhat.com/archives/fedora-announce-list/2008-February/msg00008.html
Fedora 博客聚集
Contributing Writers: ThomasChung
精彩的FOSDEM峰会
(Free and Open Source Software Developers' European Meeting)
JoergSimon reports in his blog[1] ,
"DOSDEM的第一天已经结束了，和去年相比，我们的有了更好的摊位，来了很多的人都快容纳不下了，不知道我们已经和多少人谈过话，甚至有时候拥挤到不能移动了。"
[1] http://kitall.blogspot.com/2008/02/first-fosdem-day-is-over-and-compared.html
FOSDEM08 - 周六
FrancescoUgolini reports in his blog[1] ,
"很多人访问了我们，不仅仅只是在展台上，在峰会上也是。这个峰会是Fedora贡献者们举办的(令人惊讶的是竟然邀请了Jens作关于SELinux的演讲)，此外很多人都询问DVD的事情(live CD的不多)，而且他们对我们展台上的两台OLPC也都跃跃欲试。"
[1] http://ugolini.livejournal.com/1950.html
忙碌的FOSDEM
JeroenVanMeeuwen reports in his blog[1] ,
"昨天是FOSDEM很有意思的一天。因为我一直在忙于pyJigdo，为了把那些提议的特性都加入Fedora 9，完成之后我加入了那些讨论...我拍了一些照片，你们可以在我的Fedora Unity space浏览。正式的公告马上就要来了！"
[1] http://blogs.fedoraunity.org/kanarip/2008/02/24/the-fosdem-buzz
LWN, Fedora and you
JefSpaleta reports in his blog[1] ,
"Fedora委员会决定采用最公平的方法，即让所有那些在Fedora Accout System上激活帐号的Fedora贡献者们来抽签，来确定最终谁能获得订阅。"
[1] http://jspaleta.livejournal.com/19142.html
Fedora 10's FUDCon
MaxSpevack reports in his blog[1] ,
"看，我们正在准备下次在北美的Boston MA举行的FUDCon了，而且这将和今年的Red Hat Summit联合举办。"
[1] http://spevack.livejournal.com/46053.html
Fedora狂欢夜
FrancescoCrippa reports in his blog[1] ,
"昨夜是Fedora狂欢之夜！"Fedora狂欢之夜"吸引了很多的Lodi以及周边地区的Linux爱好者。谢谢LOLUG的帮助，他们很有效率并且成效显著。"
[1] http://people.byte-code.com/fcrippa/2008/02/21/fedora-by-night-the-day-after/
营销
Contributing Writer: JohnBabich
KDE4采访
JonathanRoberts说[1] KDE4的采访[2] 现在已经完成，你们尽可一窥其中的奥妙。
[1] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00278.html
[2} http://digg.com/linux_unix/Fedora_IS_a_KDE_distro ]
Fedora多媒体版?
FrancescoUgolini建议[1] 说我们应该"创造一个开源的电影/音频/图像的Fedora版本"。这可能会成为买不起昂贵的商业产品时的另外一个选择。
MichaelBeckwith同意[2] 这个想法，说我们"在完全规划好之前，可以包含那些在艺术版中的视频和声音编辑软件。"
Juan M. Rodriguez Moreno提醒我们说到[3] "Peter Jackson(指环王道导演)使用...Fedora Core 2。"事情将会越来越好的。
GregDeKoenigsberg则提出[4] ，"我们应该从Fernando Lopez-Lezcano以及Planet CCRMA开始。"
NicuBuculei却表达[5] 了他的担忧："可是，那些工具都还没有准备好：Kino不能打开Ogg Theora, PiTiVi不能作任何有用的事，Cinelerra用的都是私有代码等等。别忘了那些潜在的法律问题：这个版本必须全部使用那些自由软件，可能并不是用户所期望的有差距(比如合法使用DVD等)。"
RussellHarrison added [6] there "would need to be the same sort of educational message Codina has in prominent locations all over the DVD. Aside from the technical issues you pointed out which are much more difficult to deal with."
[1] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00280.html
[2] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00281.html
[3] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00283.html
[4] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00284.html
[5] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00290.html
[6] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00293.html
Free Me Too
"我们正在讨论如何进行Free Me的下一个阶段。Free Me是关于绑定在Live CD的开放许可内容的收集活动。Jonathan Roberts，谢谢你的建议。让我们开始吧[2] 。特别指出的是，任何关于寻找开放编码形式内容或转换程序的提示都将获得感谢。额外的关于...的内容建议应当能够自由的发布而且没有使用限制。"
JonathanRoberts enthused [3] "Wow, totally awesome that you're picking this up now!! Conversion procedures I can definitely help with, though you might need people to tweak it a little bit...ffmpeg2theora I think is the best tool for the conversion of the video...Oh and another point: part of my goals with free me was to make it workable without even having to boot the live disc..." He followed up [4] with "you're more than welcome to use any of the free me artwork".
Rahul asked [5] "How did you get the Google Videos converted? How about all the other content not in theora or any open format?"
RussellHarrison volunteered [6] to help, but had some reservations: "Is there any legal exposure if we use tools with potential patent problems to convert content even if they aren't distributed on the DVD? h.264 comes to mind as an example...Should all of the content on the DVD be licensed under free licenses such as Creative Commons, or is it acceptable for the [copyright] holder to release the content for distribution with the DVD."
Rahul cautioned [7] "if you are in a region that enforce software patents, you should consider the implications carefully... If you have content in patent encumbered codecs, feel free to point them to me and I will take care of the conversion. He added that he wants "openly licensed content and not something specific to the DVD image I put out. The ability to redistribute content as a criteria is not negotiable. I am ok with some of the content having non-commercial restrictions though I would prefer not."
Nicu promoted [8] the openclipart package [9] , which Rahul added to his wiki page [2] .
Rahul stated [10] that "the goal of the live DVD is to promote Free culture and Free software but not Fedora specifically."
RussellHarrison heartily agreed [11] .
[1] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00282.html
[2] http://fedoraproject.org/wiki/RahulSundaram/FreeMeToo
[3] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00285.html
[4] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00286.html
[5] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00287.html
[6] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00292.html
[7] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00294.html
[8] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00295.html
[9] http://koji.fedoraproject.org/koji/packageinfo?packageID=5839
[10] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00299.html
[11] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00326.html
Fedora和创造丰富社区的艺术
Caroline Kazmierski announced [1] that: Matt Asay采访了PaulFrields，并写在了他的CNET blog上，取名"开源之路"[2] .
[1] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00303.html
[2] http://blogs.cnet.com/8301-13505_1-9875189-16.html?tag=head
Fedora Store SIG 升级
JeffreyTadlock updated [1] on: "Fedora Store SIG发生了什么？在上周我在cafepress.com订了一件T恤和一个咖啡壶...那个咖啡壶很好。那件T恤的材质用料都不错，但是印的图案却过多...我把图片寄给他们了，并把cafepress.com的T恤和图片上的进行了比较说明[2] ...另外一个我用的上的是网页上的模型[3] ...如果你有什么意见和建议，新的经销商，请于下周三，2月27日前添加在wiki上。"
[1] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00309.html
[2] http://jeffreyt.fedorapeople.org/storeSIG/
[3] http://fedoraproject.org/wiki/SIGs/Store/GeneralRequirements
Windows -> Fedora -> Windows
MarcWiriadisastra给出[1] 一篇奇怪的文章的连接[2] ，这篇文章讲述的是一所学校从Windows迁移到Fedora上然后又返回Windows的事情。他引用了上面的一段话："迁移使我们在授权方面节省了很多钱。最初，学校使用的是Red Hat Linux，之后是Fedora，Red Hat社区的发行版。节省下来的钱被用来升级学校的硬件设施，并买了更多的PC。"
NicuBuculei认为[3] ："原因很简单："重新返回微软操作系统？缺少一些老师的支持，比如Perkins。"...但是盖棺定论的却是："但是当所有的教工在2007年底获得笔记本电脑时，已经注定了Linux桌面在学校将被终结的命运。那些笔记本电脑都预装了Windows并且还安装了Office，这点无法改变。"他接着说[4] "当用户在使用Windows过程中遇到问题时，他们会埋怨微软然后放弃，但当"每个人都在使用它时"就会认为"这就是它的工作方式"。但是当用户在使用Linux中遇到问题的时候，他们埋怨那些布署Linux的人，"使用Windows会更简单些"，"Linux并不能像Windows那样，太痛苦了"，"让我重新回到我所信任的Windows下面吧"。"
Luis Felipe Marzagao则认为[5] ，"主要的问题似乎是缺乏一种从网络下载程序并安装的简易方法"，如果不考虑潜在危险的话。
[1] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00311.html
[2] http://www.itwire.com/content/view/16721/1090/1/0/
[3] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00312.html
[4] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00320.html
[5] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00332.html
宣布事情的最好方法？
JonathanRoberts [1] queried: "我期望从更多的人们那里得到一些想法。Fedora确实*拥有*优秀的团队，他们不仅仅只是做开发方面的工作，还有很多的社区方面的工作...我想我们需要另外一种机制，以让人们了解我们良好的整体结构和社区的各种事情，[比如] 那些新的协作服务器，fedorapeople.org，开放构建工具，transifex，publican等等...我确认我们将做到最好，并在那些*海量的*额外的开发包给予更多的关注。"
MarcWiriadisastra recalled [2] "这儿有关于一个wiki页面的讨论，这个页面的内容是所有的e-marketing链接或者其他的东西。我不确定这样的页面是否已经创建了。"
RahulSundaram recommended [3] "我们应该使用[news.fedoraproject.org] ，并通过一个RSS feed来个这个整合到首页上......"
Jonathan was more concerned about the other formats besides press releases [4] , which led Rahul to agree [5] , remarking that "We should be casual, highlight not only the work done but also the people doing the work and let Red Hat do the official press releases."
KarstenWade contributed [6] that "You are asking about format, which means...Style of writing [and] Tooling (file format).
For the style of writing, I agree with Rahul's suggestion of a casual tone...For tooling, we have a very cool and very simple to use method for writing 'press releases' that can be translated. Getting global coverage is going to require translation...Some announcements might need to be rewritten from scratch in other languages because of idioms, etc.
Anyone feel like learning to use this press release tool, then writing up how-to on the wiki?
The point would be to follow a rough process like this:
1. Collaborate on a list of what to highlight (ongoing)
2. Collaborate via the wiki to write up draft => ready to release
3. Copy and paste into a press-release shell
4. Finish conversion into press-release and keep these in a version control system
[1] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00314.html
[2] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00314.html
[3] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00319.html
[4] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00322.html
[5] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00323.html
[6] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00330.html
商标之战： Red Hat 与 DataPortability
注意：下面的贡献者们如果不是全部也至少大部分都不是律师。
"DataPortability WorkGroup是于2007年11月创建的，旨在开发最好的业务以方便用户移动，共享，管理他们的帐号，照片，视频以及其他形式的存储在社交网络或其他web服务器上的私人数据。经过几个月之后，开发小组遇到了一点小问题，一封从Red Hat的来信要求他们停止使用Fedora图标。"
NicuBuculei遇到[3] 相似的情况。JohnBabich做了[4] 一番小小的调查，并总结说"这个小组的人们都是怀着好意的，他们只是碰巧使用了和Fedora相似的图标。并非恶意，并且小组中的一些人也乐意更换图标。"
虽然如此，JeffSpaleta则认为[6] ："这涉及到一个本质的问题......美国商标法规定 ACTIVE policing of a trademark, for the mark to remain protected. This is direct contrast with how copyright and patent law works. If you don't actively police your trademark, then it can lose its protected status...A cease and desist letter is the legal mechanism that the US legal system will recognize in situations where the infringing status is in dispute. If Red Hat doesn't use mechanisms recognized by the US legal system (the system which ultimately determines whether a trademark is still protected), then the trademark on the Fedora logo is jeopardized...The ultimate goal here is the continued protection of the Fedora logo as a registered trademark. There is no malice in the C&D letter. The other logo is similar."
GregDeKoenigsberg informed us [7] that he was "discussing this issue with legal now, looking for a sensible compromise. I'll report back."
KarstenWade surmised [8] : "Maybe it's not possible or sensible to send a 'nice letter'?...When you put the Fedora and Data Portability logos side-by-side the differences are more apparent. But honestly, when I first saw the Data Portability website, I thought, 'Wow, looks like the Fedora logo.'
So, Red Hat is working *for* us in defending the mark. Dilution of that mark means dilution of our work. It's directly related to why we are so careful about keeping non-free and encumbered software out of the distro, as well as the many other actions that make Fedora what it is."
Tony Guntharp, who is a member of the DataPortability Group, appreciating Karsten's remarks, replied [9] : "The DP group (of which I am a member) is an loosely formed community with a purpose very similiar in vein to Open Source / Free Software...A C&D letter should have been sent out as a last resort instead of being the first salvo. By this being the first shot across the bow it only allows for escalation to the court system. If the DP group had been approached sooner by someone from within Red Hat then I think the issue would have still been resolved in the same manner w/o Red Hat looking like the bad guy."
Greg agreed [10] , saying "You are obviously correct. Sometimes the left hand acts without knowing what the right hand is doing. We're working on an answer to the problem right now, preferably before it hits Slashdot."
Finally, Tony informed us [11] , "Well Chris Saad (the quasi-leader) of DP is in SF until April 28th (he's in from Australia) if anyone from Red Hat cares to meet up with him. And I'm intimately familiar with the left hand/right hand issues."
[1] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00333.html
[2] http://www.techcrunch.com/2008/02/21/logo-war-red-hat-takes-on-dataportability/
[3] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00335.html
[4] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00336.html
[5] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00337.html
[6] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00350.html
[7] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00355.html
[8] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00351.html
[9] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00359.html
[10] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00361.html
[11] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00362.html
Ubuntu 营销
Note: This thread and related threads totaled 66 messages.
The original message by ValentTurkovic [1] highlighted Ubuntu Cola, the UK's first Cola with Fairtrade Label [2] .
It quickly moved onto the subject of Ubuntu's popularity (the linux distribution, not the cola), closed multimedia drivers, how to inform users of non-free drivers, etc.
There were important and serious discussions about what "freedom" really is about, integrity, and what end users expect, and other related topics too numerous to list here.
ClintSavage provided [3] the best one-liner: "Let me use a phrase from my childhood and say 'if Ubuntu jumped off a cliff, would you?'", which was considered to be the winner in the t-shirt slogan contest by Karsten [4] .
[1] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00339.html
[2] http://www.ubuntu-trading.com/
[3] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00394.html
[4] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00406.html
Fedora and alternative desktops
RahulSundaram noted [1] that the DistroWatch Weekly [2] covered KDE4 and Xfce in Fedora, while the official KDE site [3] listed the "KDE 4 And Fedora Interview".
[1] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00341.html
[2] http://distrowatch.com/weekly.php?issue=20080218#news
[3] http://dot.kde.org/1203420709/
AMD Releases 3D Programming 文档
RahulSundaram reports [1] : "Another win for Free software. The age old myth about vendors unable to release 3D information for any number of reasons just went out of the door... again.
"AMD has just published the first bits of open-source 3D programming documentation for ATI GPUs. This 3D programming documentation covers the R500 series and even goes back with information on the R300/400 series as well. The R600 3D programming guide will also be out soon" [2] "
[1] http://www.redhat.com/archives/fedora-marketing-list/2008-February/msg00413.html
[2] http://www.phoronix.com/scan.php?page=article&item=amd_tcore_release&num=1
Ambassadors
Contributing Writer: JeffreyTadlock
Fedora By Night Event Report
FrancescoCrippa reported to the Ambassadors' mailing list on the Fedora at Night event held on February 19th in Lodi, Italy. Highlights of the event include a presentation on the community behind Fedora, a brief overview on how Fedora is built and managed and followed up with a question and answer period. Don't miss Francesco's more detailed blog post and the pictures from the event he posted.
[1] https://www.redhat.com/archives/fedora-ambassadors-list/2008-February/msg00168.html
[2] http://people.byte-code.com/fcrippa/2008/02/21/fedora-by-night-the-day-after/
[3] http://www.flickr.com/photos/fcrippa/sets/72157603949413659/
FOSDEM Reports
The reports [1-6] from FOSDEM 2008 in Brussels, Belgium are beginning to roll in. Fedora is well represented at this conference with an estimated twenty+ ambassadors in attendance to talk about Fedora! MaxSpevack will be updating the FOSDEM Fedora Event page [7] with links to new reports and pictures, so be sure to check that page for updates that did not make it by the Fedora News deadline.
[1] http://kitall.blogspot.com/2008/02/first-fosdem-day-is-over-and-compared.html
[2] http://ugolini.livejournal.com/1700.html
[3] http://kitall.blogspot.com/2008/02/fosdem-arrival-arrived-1700-at-brussels.html
[4] http://blogs.fedoraunity.org/kanarip/2008/02/23/fosdem-2008-first-day
[5] http://fabaff.blogspot.com/2008/02/fosdem-2008-00.html
[6] http://blogs.fedoraunity.org/kanarip/2008/02/22/fosdem-2008-coming-up-soon
[7] http://fedoraunity.org/Members/kanarip/pictures/2008-fosdem
开发
Contributing Writer: OisinFeeley
Evolution Of Mail Client Preferences
A long thread over the selection of evolution as the default MUA in Fedora was started[1] by JensPetersen. After carefully donning a figurative asbestos suit Jens noted that evolution was different enough from the other GNOME applications that it was expensive to maintain and that the release of the Mozilla Foundation's calendaring application lightning and the stability of their MUA thunderbird suggested they could be chosen instead. MatthewBarnes asked for elaboration of the assertion that "Evolution [is] basically a different platform [to GNOME] ". Jens replied[2] , first with a courteous thanks to Matthew for his maintenance work on evolution and then specified that he was referring to its "custom gtk widgets and gtkhtml".
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01750.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01765.html
Matthew, who had dug in for "another round of Evolution bashing", acknowledged[3] these points and listed the specific steps he was undertaking to "chip away at [...] the old cruft [and] technology that fell out of favor years ago." The list includes a migration from GtkHTML (the rendering library) to WebKit/GTK+, a move from custom gtk widgets to modern GTK+ widgets, replacement of parts of the GNOME Applications Library and rewriting the message composer to not use bonobo. All this work is still in progress and may take some time.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01792.html
JohanGudmundsson and MatejCepl thought[4] that a parallel install of Evolution and Thunderbird along with a mail-migration script for Thunderbird should be installed and then the flame-fest should be concentrated on Tomboy and mono.
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01871.html
The issue of actual user preference was floated[5] by NicuBuculei when he referenced Mugshot statistics which show a preference for Thunderbird.
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01769.html
MatejCepl did not believe that Jens original mail was not intended as a flame and posted[6] a list of reasons to distrust thunderbird, including poor IMAP support, poor vfolder support, bad reply-to defaults, a lack of regexes, the use of the working folder for message storage, and finally a proven track record of crashing. Matej's reluctant conclusion was that all email clients sucked but that he would like to find a GUI MUA that sucked as little as mutt did in the non-GUI space. Further discussion with KevinKofler seemed[7] to suggest that KMail was a possible contender. It was even revealed[8] to be gaining HTML support, despite "HTML mail [being] a plague infecting the Internet." This latter opinion was disputed[9] by "Gene" who pointed out a business use-case where a HTML table can be filled out more easily than ASCII. AlanCox retorted[10] that "you have no idea what the recipient receives if you do that. HTML isn't a strict formatting specification." He went on to provide a demonstration of how large GIFs, which in themselves take up little space, may be turned into enormous RAM-munching bitmaps causing the recipient's client to die.
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01778.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01782.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01899.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01923.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01926.html
The banner of "All MUAs suck, it's just a question of which sucks less for a given user/task" was raised again by JohnDennis. The most useful attribute of Thunderbird for him was its lack of crashing. TomasMraz suggested[11] that Evolution's crashing had stopped after upgrading to Fedora 8, at least for his usage patterns. BennyAmorsen thought[12] Evolution crashes were due to the Exchange Connector as did TimothySelivanow.
[11] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01813.html
[12] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01836.html
[13] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01815.html
PeteZaitcev laid[14] the blame on HavocPennington for diligently implementing the Open Source Architecture vision[14a] with Evolution plus Epiphany and explained that its "main merit [...] is the integration with calendaring and LDAP". He cautioned that Thunderbird was subject to competing factions which might turn it into a bloated monster and added that for his own personal use sylpheed was good at not chewing patches. BryanClark wrote[15] an excellent overview of the situation which suggests that Evolution's integration and Exchange capabilities have entrenched it for now.
[14] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01872.html
[14a] http://www.redhat.com/f/pdf/gov/WHP0005US_FEA.pdf
[15] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01877.html
As with all good flamebait there was a lot of anecdotal evidence in the thread with some claiming[16] that Thunderbird was better than Evolution for IMAP folders and yet others flatly contradicting[17] this experience. It appears that there is a good deal of ground to be made up to produce a fast, non-archive destroying, IMAP-aware mail client.
[16] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01752.html
[17] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01756.html
Incompatible Unison Update
The bleeding-edge nature of Fedora came to the fore again when StephenWarren asked[1] whether the decision to update unison in Fedora 8 to a package which was not backwards compatible with older versions was the right thing to do. JonathanUnderwood gave[2] his opinion that it was correct given the "bleeding edge" nature of Fedora and suggested that Stephen ask for a compatibility package or, better still, made one. Stephen was not pleased[3] and argued that while he expected breakage between major versions of the distro he did not expect it within a stable version. He also thought that he might find another distro if such decisions were actually the norm.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01809.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01810.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01820.html
JefSpaleta thought[4] that Jonathan had handled the situation the wrong way. In part this was based on the assumption that Jonathan had closed the bug quickly with "NOTABUG", as suggested in the comments to the entry. ChristopherAillon also agreed with Stephen that the wrong decision had been made and reminded[5] the list that keeping users of the distribution relatively happy unless there were very good over-riding considerations was important.
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01828.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01822.html
Jef requested[6] more information from Stephen as to the nature of the incompatibility asking him to bear in mind the need to limit the existence of compatibility packages. Responses from Stephen detailing the exact systems that he was using led to a list which Jonathan dismissed[7] as mostly irrelevant due to them being EOL'ed. HansdeGoede thought that breaking a network protocol during a stable release was a problem and also expressed[8] concern over Jonathan's tone. Jonathan apologized[9] for any unintended tone and argued that the bugs fixed by the update were showstoppers for cross-compatibility and thus necessary.
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01824.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01834.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01839.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01881.html
A lot of the commentary suggested that such changes were unacceptable. AndrewFarris noted[10] that such changes were not uncommon with upstream unison and ChristopherAillon suggested considering rsync as an alternative. Andrew explained[11] that unison did not simply replicate changes from an authoritative master to a slave, but kept both sides in sync with each other.
[10] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01864.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01866.html
As things stand there appears to be a compatibility package created by Stephen awaiting[12] review, with quite a deal of discussion already attached.
[12] https://bugzilla.redhat.com/show_bug.cgi?id=433915
Three Simple Steps To Speed Up Booting / Shutdown
The slow booting of Fedora led ArjanvanderVen to undertake some practical steps to speed things up. He confessed[1] to being "a tad annoyed by why the initscript processing is (in my impatient perception) slow" as each actual initscript is actually relatively quick.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01495.html
The practical improvements broke down into six major types of change affecting /etc/rc.d/rc, /etc/init.d/functions and /etc/profile.d/lang.sh. They include rewriting builtin Bourne-shell inclusive-or tests for files ,e.g. [ -f FOO -o -f BAR ] , to two separate statements testing for each file. The point of this is to reduce the un-needed disk-seeking and I/O of searching for BAR in the cases where FOO exists. BehdadEsfahbod suggested[2] that the BASH short-circuit test, later provided[2a] by AdamGoode as [[-f FOO || -f BAR ] , should be used instead. Behdad had undertaken a similar exercise to Arjan's and agreed that another of the optimizations, namely to not change VGA fonts via initscripts, was important. He extended it to "I'd go as far as saying that unicode_start should only be called from /etc/profile, not other bash invocations." BillNottingham agreed strongly[3] , saying "Heck, it should only be called from a udev rule on console initialization."
[2] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01501.html
[2a] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01522.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01610.html
Behdad had concentrated on rc.sysinit and was disturbed by a script /sbin/start_udev which it called as it provided its own internal, slower implementation of xargs instead of calling a real xargs when available. Arjan felt[4] that udev was "so incredibly slow that it's just outrageous" and referenced a comparison to a much quicker boot with a non-Fedora distribution preloaded on his laptop. HaraldHoyer suggested[5] that it would be useful to "add udevinfo or udevdebug to the kernel command line" to check for some of what he found to be the usual causes of a long startup: slow kernel module loading; firmware loading failing; persistent storage labeling bugs. OlaThoresen noted[6] that if LDAP is used for authentication and the network is not up before udev starts then udev waits for a long timeout. LubomirKundrak remembered[7] that there had been a thread about a year ago in which someone recommended that modprobe dependencies should be cached as udev spent most of its time waiting for this information. In fact this work had been done by HaraldHoyer himself as reported in FWN#103 "Udev Performance"[8] .
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01520.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01586.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01624.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01615.html
[8] http://fedoraproject.org/wiki/FWN/Issue103#head-4ff62435e0646dccef282c64ec86f3b2c8350ef3
When To Introduce Asterisk 1.6
JeffreyOllie asked[1] what the general feeling was about waiting until Fedora 10 to introduce the latest version of the VOIP server asterisk. Right now packages of version 1.4 of asterisk are available for Fedora 7 and Fedora 8 but the 1.6 version was reported by Jeff to be in "late beta".
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01659.html
JefSpaleta wondered[2] why he could not package it after the Fedora 9 ISOs had been released, then drop it into the "updates-testing" repository with appropriate fanfare to alert interested testers, and finally push it into "updates-released" after making any necessary changes. Jeff explained[3] that he wished to "avoid upgrading to a new Asterisk major version in a stable Fedora release" with the reason that Asterisk users tended to be "averse to upgrading" with some still running on 2.4 kernels and Digium still supporting Asterisk-1.2. There seemed to be some support for this position, but BennyAmorsen added[4] the information that the support provided by Digium was for the non-GPL'ed "Business Edition" and extended only to security fixes.
[2] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01662.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01668.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01703.html
The other side of the argument was put[5] by RichiPlana who stated his preference, as an employee of an enterprise which ships production systems based on the latest Fedora and Asterisk versions, for a package of the beta to be available for testing "even if it doesn't go stable before F10 is released". Richi later argued[6] that as Asterisk itself was moving to a shorter release cycle more synchronized with Fedora's and that this "beta3" seemed from their list traffic to be implementing very conservative changes. The new management features were something which Richi was especially interested in testing.
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01705.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01663.html
The stability of the beta was raised[7] by KevinKofler as an important factor in the decision. He argued that if the official release was scheduled prior to the release of Fedora 9 then "you should definitely upgrade to the beta now and get the release info F9 final." If, however, it were to be released afterwards then a decision needed to be made based upon the evaluation of the stability of the beta. Kevin noted that the "beta" label itself meant wildly different things for different projects.
[7] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01682.html
On a related issue JohannGudmundsson asked[8] whether the latest ISC-DHCP (ver. 4) and freeradius could be packaged. He also wondered if there were some way to see whether Fedora was shipping the most recent software from a variety of projects. JohnDennis answered[9] that he just needed to find time to get the latest freeradius 2 done and that there was nothing blocking it. FlorianlaRoche posted[10] a link to a handy distrowatch table which may be slightly inaccurate but attempts to provide a tabular view of package versions. KevinKofler reminded[11] Johann that DHCP-4 was already in rawhide.
[8] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01670.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01671.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01672.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01683.html
SELinux Smolt Statistics
Seeking clarification on the figures reported by Smolt for SELinux JamesMorris asked[1] whether the report that approximately half of those surveyed (circa 331,000 registered hosts) had SELinux enabled was accurate. James pointed out that as reports on SELinux had only been collected from Fedora 8 onward the true percentage might be closer to 74%.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01621.html
YaakovNemoy agreed[2] that more detailed reports were necessary, but was off to FOSDEM and had to put it on a "TODO" list for urgent attention. JamesMorris was[3] keener to get a quick correction up on the web page and some clarification as to how the statistics were calculated.
[2] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01622.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01634.html
A slightly fraught part of the thread was started[4] by ValentTurkovic when he replied to James' original query with a partial quote which emphasized the original statistic "If this arguments are true for Fedora 8 than it looks like that more people dislike selinux than like it, right?" and ignored the probable confusion which James had pointed out. James responded[5] "Why did you delete the rest of the email, which queried these numbers and suggested that the real figure for enablement was much higher?" He added that off-list he had obtained the raw figures for Fedora 8 systems (the only ones which actually are set up to report whether SELinux is enabled or not) and "the "Enabled=True" value is currently 94%." James qualified this with the caution that there were several factors confounding any simple interpretation. JohnDennis answered[6] that Valent had an "anti SELinux agenda" as referenced by previous threads and Valent countered[7] that this was a misunderstanding and that he was helping by contributing bugs for selinux-policy.
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01690.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01704.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01962.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01962.html
One of the possible confounding factors was raised by BennyAmorsen, who asked "Does Enabled=True imply enforcing". JamesMorris answered[8] that it did not and this was one of the extra pieces of information which needed to be collected. He also expressed a wish that information on other security features such as iptables be collected.
[8] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01739.html
How To Get Mock To Include Testing Packages In Buildroot
NealBecker asked[1] how it was possible to build against a package which was in testing. He was specifically concerned with the situation that his python-igraph package had a BuildRequires on igraph-devel and he wished to build against the latest igraph-devel-0.5 which had just been pushed into testing. IgnacioVazquezAbrams told him to "request a buildroot inclusion from releng" and upon further questioning confirmed[2] that this meant "send an email to releng."
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01633.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01647.html
A webpage listing the commands used by Koji administrators was linked[3] by AlexLancaster and he suggested adding the "email rel-eng" instructions for ordinary users there. JesseKeating seemed[4] to want to keep that particular page as a reference for the Koji administrators but requested "somebody please suggest a place where [instructions on making this request by email] will be found and used [on the wiki] ."
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01675.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01676.html
"This is not a particularly intuitive mechanism at the moment. How can we automate this better" asked[5] DenisLeroy. Jesse replied[6] with a request for patches.
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01637.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01638.html
Auto-rebuild Release Bump Errors
A report[1] by OrionPoplawski of an incorrect bump of the version of his pre-release gdl package, as a result of the GCC-4.3 autorebuild (see this same FWN#121 "GCC 4.3 Mass Rebuild"), exposed a problem in its naming. The gdl 0.9-0.pre6.fc9 package bad been bumped to 0.9-1.pre6.fc9 and Orion noted that it should have been 0.9-0.pre6.fc9.1. MichaelSchwendt corrected[2] the original numbering to 0.9-0.1.pre6%{?dist}.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01657.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01660.html
After JesseKeating agreed with Michael and pointed out that packages which fail to follow the guidelines will be missed by the bumper attention was drawn[3] to the jpp-based java packages by MattWringe. Matt noted that they seemed to have all failed to update properly, yet were following the JPackage naming guidelines. Michael asked[4] whether the original BillNottingham / ElliotLee (sopwith) script in cvs/fedora, used by the old FedoraExtras, was used as "if a different and secret script is used, that's not helpful." Jesse responded[5] that it was one from cvs/fedora/rebuild-scripts and asked for details of failed jpp packages because the ones which he had examined seemed fine. KevinKofler reported that they were bumped to m+1jpp.something instead of mjpp.n+1 to which Michael replied[6] that this was now a supported scheme in cvs. In discussion with Kevin further details of the bumper were explained by Michael.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01957.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01968.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01969.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01985.html
GCC 4.3 Mass Rebuild
The announcement that a mass rebuild using GCC-4.3 was made[1] on 18 February 2008 by JesseKeating. JoshBoyer sounded[2] happy that blacklist requests (by the owners of packages which were known in advance to fail to rebuild) would no longer be accepted.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01597.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01601.html
JoshBoyer in response to DenisLeroy stated[3] that the algorithm was to "rebuild all except blacklisted AND already rebuilt with gcc 4.3".
[3] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01582.html
PERL packages were thought[4] by PaulHowarth to be a problem as he had been waiting for an update to PERL 5.10 in the buildroots before he built his packages. Josh answered[5] that such packages would be rebuilt twice: once now and then another time when the PERL update landed. TomCallaway issued[6] a mea culpa for the lack of a PERL update.
[4] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01584.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01590.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-February/msg01614.html
文档
Contributing Writer: JohnBabich
Generating PDFs with Publican
JaredSmith has been testing Publican with a few Fedora Project documents. He stated [1] that he kept "getting errors from FOP when I try to build PDFs." He later added [2] "I think I've made some pretty good progress on tracking down this problem. To make a long short, publican is assuming that we're using FOP 0.20, while what's in rawhide is 0.94. This meant xsltproc was adding fox:destination elements to the .fo file, instead of the new fo:bookmarks instead." To work around this problem, he modified xsltproc parameters in the Makefile. ...That got the .fo file generated so that FOP 0.94 would handle it correctly, but then FOP died complaining that it couldn't find Batik in the classpath...Ah, lo and behold, I was able to render a PDF!"
He added that this "raised a few questions:
1) Do we want the toolchain to be able to detect the version of FOP and adjust itself accordingly?
2) Do we want to expose other parameters to xsltproc? In my very rudimentary home-grown toolchain, I create a custom XSLT stylesheet that exposes a bunch of settings (paper.type, double.sided, draft.mode, shade.verbatim, etc.) which imports the standard XSL stylesheet. Would this be more manageable in the long run that passing a bunch of stringparam arguments to xsltproc?
3) Makefile.templates currently tells FOP to use the fop configuration file in $(COMMON_CONFIG)/fop/fop-0.20.5.xconf, but that doesn't come as part of the publican package. Should we remove the reference (and assume people have a valid FOP config file in /etc/fop.conf), or expose this via a variable in the Makefile? (This isn't a big deal -- I just thought I'd mention it in passing while I was thinking about it.)
4) Can somebody take a look at why fop isn't seeing batik in the classpath? My Java skills are obviously too weak to fix this problem."
JeffFearn, one of main developers of Publican, replied [3] that there were differences introduced by using different versions of FOP and that customization of brands at this stage is difficult. However, there are ways to customize PDF output by making a new xsl files. It is possible to add extra build targets, but it's a little tricky since it involves modifyng Makefiles. Jeff later announced [4] "I came up with a way that can support an arbitrary number of config files".
Jared responded [5] "I currently have FOP 0.94 working just fine with Publican in Rawhide, with the exception of support for SVG graphics."
KarstenWade reminded [6] the team "IIRC, Batik originally had some dependencies for graphics processing that couldn't be cleanly included under IcedTea. It may not yet be able to process SVG?"
[1] http://www.redhat.com/archives/fedora-docs-list/2008-February/msg00102.html
[2] http://www.redhat.com/archives/fedora-docs-list/2008-February/msg00103.html
[3] http://www.redhat.com/archives/fedora-docs-list/2008-February/msg00104.html
[4] http://www.redhat.com/archives/fedora-docs-list/2008-February/msg00119.html
[5] http://www.redhat.com/archives/fedora-docs-list/2008-February/msg00121.html
[6] http://www.redhat.com/archives/fedora-docs-list/2008-February/msg00123.html
F9 Toolchain
KarstenWade writes [1]
While all this toolchain talk is in the air ...
We've got several major activities going on that are relying upon our current-and-working toolchain:
- Release notes need to build properly by 16 March...
- Updates to existing guides (IG, SMG) by mid-March...
- New guides going into Beta in March (DUG, AG)
Beyond being confident the guides can build cleanly, which Jared has demonstrated in the one case, we need to know that they can match whatever MUST list we put
together. Some SHOULD items are OK, too.
For starters:
- Must be possible to go from Wiki to usable XML with similar process/hassle as current pathway
- Must be able to pull book from CVS and build in Fedora 8 and Fedora 9 tests (Alpha, Beta, RC, Sulphur)
- follows the tradition of not requiring docs tools to work for Fedora N-1
- Should be able to build in Fedora 7
- Must produce PO files that are line-for-line identical to the one produced in the last version
- this is to minimize re-translation or having to re-check already translated strings on content that is already translated (IG, Relnotes)
- Must process PO and POT so as to not put a burden on translation and Transifex (line-for-line identical or close enough)
- Must be usable by Release Engineering in composing the build
- Must be hostable by Fedora Infrastructure for Docs, L10n, or Rel
- Must have a reliable upstream, should be relied upon for at least 12 months
- Must have a packager who affirms to maintain the package, should be affirmed for at least 12 months
- Should build RPMs that match the RPM capability of /cvs/docs
- need to list these out
Anything else?
MarcWiriadisastra mentioned [2] that he "would love to be able to transfer to xml as in know how to transfer to xml so I can actually work on the DuG. It's at the stage were it is edit ready so the reason why there hasn't been any discussion is because I have no idea of how to proceed from now." Karsten said [3] he was waiting for the "CVS module and bugzilla component." Marc asked where the style guide was located, to which Karsten cheerfully replied.
JaredSmith responded [4] that "Just to be clear... I'm *not* pushing for a change to a new toolchain before F9. I think it would be awfully rash of us to do so at this point in the game. I also don't want anybody to mistake my enthusiasm for publican as somehow knocking the current tool chain. I'll be the first to admit that I don't know the current tool chain very well. Additionally, I don't think we've tested publican enough (as far as the translations go, especially) to know whether or not it's a good fit for what we do. What I *am* enthusiastic about is how quickly publican allows people to hit the ground running, especially those who are new to DocBook and their tool chains. If I had to prognosticate at this point, I'd say that in two years' time, we'll have taken the best pieces of publican and the current tool chain and welded them together."
Jared also asked [5] for feedback on his conversion of the Software Management Guide using Publican.
Karsten concluded [6] that "clearly, the interest in publican and it's (apparent) ease to get started with an XML book is a feature we've been missing in the Fedora Docs toolchain. Honestly, though, we have been pursuing the higher gain. Across open source projects, the wiki is where the developers and other contributors do their community documentation. When we focused exclusively on XML, we had very interested or enabled contributors.
Some years back I spoke with the Mozilla Dev documentation folks, who had then changed from DocBook XML to a fully wiki-based system...Switching to the wiki, they saw 10x increase from developers, even the ones who knew DocBook well enough. In addition, many new contributors came in to help, which increased the editorial and content group.
It's unclear to me how much these features of publican matter to Fedora Docs. For example, the people who have dropped by #fedora-docs looking for publican help seem to be working on their own content. While maintaining tools that allow the creation of free content is a part of the Docs charter, it's definitely a lower priority than enabling Fedora contributors to create content for Fedora. Right now that means helping to maintain the wiki: http://fedoraproject.org/wiki/DocsProject/WikiGardening
Finally, he agreed with Jared that an open community development for Publican from this point forward is definitely to be desired.
[1] http://www.redhat.com/archives/fedora-docs-list/2008-February/msg00122.html
[2] http://www.redhat.com/archives/fedora-docs-list/2008-February/msg00124.html
[3] http://www.redhat.com/archives/fedora-docs-list/2008-February/msg00128.html
[4] http://www.redhat.com/archives/fedora-docs-list/2008-February/msg00125.html
[5] http://www.redhat.com/archives/fedora-docs-list/2008-February/msg00126.html
[6] http://www.redhat.com/archives/fedora-docs-list/2008-February/msg00131.html
基础设施
Contributing Writer: HuzaifaSidhpurwala
Koji Bandaid
MikeMcGrath writes[1] ,
The Koji builders don't check back in automatically when they lose a connection to the host. Mike put a script to fix it. The script could be run as a cron job or as nagios event. The problem is that we don't have currently, nagios take an action when an event occurs.
[1] https://www.redhat.com/archives/fedora-infrastructure-list/2008-February/msg00094.html
news.fp.o
JonathanRoberts writes[3] ,
There is an open ticket [2] for news.fedoraproject.org site but unfortunately it's not been
updated in the past 4 months. There was some discussion about what news software to use and if wordpress will do the trick.
[2] https://hosted.fedoraproject.org/fedora-infrastructure/ticket/178
[3] https://www.redhat.com/archives/fedora-infrastructure-list/2008-February/msg00095.html
Mailman List Policy for Fedora Hosted
JeffreyOllie writes[4] ,
Since we have most of the technical bits in place for Mailman for Fedora Hosted. Now we just need to figure out a few policy items like who can request a list etc.
[4] https://www.redhat.com/archives/fedora-infrastructure-list/2008-February/msg00101.html
Artwork
Contributing Writer: NicuBuculei
Theming the distro: the new GDM
Theming the distro requires multiple graphics, not only a background wallpaper, and with the fast changed in Fedora there are some areas not fully documented. Such one is the new GDM (GNOME Display Manager), and after some incertitude on the fedora-art list[1] , NicuBuculei takes the problem to the fedora-desktop-list[2] , where he receive a comprehensive answer about the status from WilliamJonMcCann: while the feature was reverted in GNOME 2.22 due to time constraints, there is enough time until the Fedora 9 release, and this feature[3] is still on track for inclusion, another fine example of Fedora leading the innovation.
[1] https://www.redhat.com/archives/fedora-art-list/2008-February/msg00175.html
[2] https://www.redhat.com/archives/fedora-desktop-list/2008-February/msg00042.html
[3] http://fedoraproject.org/wiki/Features/NewGdm
EeeDora Artwork
Among the many Fedora derivatives, EeeDora[1] is a customization of the distribution for the very popular Eee PC. On the fedora-art list[2] ValentTurkovic urges the team to take into consideration that's laptop unusual screen size when creating the graphics for the upcoming Fedora 9, to have a good experience for the users of such hardware platforms.
[1] http://eeedora.rmbsanalytics.com/
( Editor's Note: the site was down at the time of editing. See http://wiki.eeeuser.com/eeedora:installing )
[2] https://www.redhat.com/archives/fedora-art-list/2008-February/msg00171.html
安全周刊
Contributing Writer: JoshBressers
CUPS flaw
A rather scary looking bug was noticed in CUPS last week:
CUPS "process_browse_data()" Double Free Vulnerability[1]
This is always one of the things that makes security and Open Source quite the challenge, yet also something positive. This bug was reported to the CUPS project in January, but nobody noticed until last week that it was even there. In a closed source project, a bug such as this would probably go unnoticed, and never be called a security issue. The "many eyes" aspect of Open Source is what got this noticed, and thanks to Secunia, the various interested vendors shipping a vulnerable version of CUPS were able to apply the fix to keep their users secure.
[1] http://secunia.com/advisories/28994/
Disk Encryption Isn't So Safe
New Research Result: Cold Boot Attacks on Disk Encryption[1]
This research paper is quite brilliant, while also being amazingly simply when you really think about it. It's never been a secret that RAM can hold its contents for an extended period of time. It's assumed that it should be possible to inspect RAM under an electron microscope and reveal the previous contents long after a machine has been powered off. The scary thing about this paper is that simply quickly rebooting a machine should make it quite possible to extract previous RAM contents.
While I don't think it's worth building a bomb shelter in your backyard over this, any paranoid tech traveler should be aware of this paper.
[1] http://www.freedom-to-tinker.com/?p=1257
安全更新
Contributing Writer: ThomasChung
Fedora 8 安全更新
Fedora 7 安全更新
事件和会议
Contributing Writer: ThomasChung
Fedora Board Meeting Minutes 2008-02-19
Fedora Community Architecture Meeting 2008-02-18
Fedora 文档 Steering Committee (Log) 2008-02-20
Fedora 基础设施 Meeting (Log) 2008-02-21
Fedora Bug Zappers Meeting 2008-02-20
Fedora SIG EPEL Report Week 07/2008
Fedora SIG KDE Report Week 2008-02-19