From Fedora Project Wiki

< FWN‎ | Beats

(170 devel pass3)
(171 devel beat pass 1.)
Line 7: Line 7:
Contributing Writer: [[User:Ush|Oisin Feeley]]
Contributing Writer: [[User:Ush|Oisin Feeley]]


=== Noarch with pkconfig Files ===
=== Emacs, Glibc, Malloc and i586 ===


[[User:Pbrobinson|Peter Robinson]] asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00162.html</ref> for help building his <package>gupnp-vala</package> package as noarch. The complication was that it contained a <code>pkgconfig</code> file.
As the pressure to stick to the <code>Fedora 11</code> release schedule built up some glitches arising in part from the decision to support i586 instead of i686 (see FWN#162<ref>http://fedoraproject.org/wiki/FWN/Issue162#Fedora_11_Will_Support_i586_Instruction_Set</ref>) led to tense words.


Several helpful responses, such as [[User:Mschwendt|Michael Schwendt's]]<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00163.html</ref> suggested installing <code>pkgconfig</code> files into <code>/usr/share/pkgconfig</code> instead of one of the <code>/usr/lib</code> directories. [[User:Toshio|Toshio Kuratomi]] thought<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00167.html</ref> that the problem was that the package did not use the new noarch-subpackage feature but instead tried to be a regular noarch package.
Reports trickled in of problems with <code>emacs</code> in rawhide. [[PerBothner|Per Bothner]] reported<ref>http://www.redhat.com/archives/fedora-test-list/2009-April/msg00221.html</ref> both that <code>emacs-23.0.91</code> threw an "Invalid regex: Unmatched ( or \\(" and that <code>emacs-23-0.92</code> was responding excruciatingly slowly. [[UlrichDrepper|Ulrich Drepper]] speculated<ref>http://www.redhat.com/archives/fedora-test-list/2009-April/msg00225.html</ref> to that the regexp problem was due to some changes to <code>malloc</code> in <code>glibc</code>.  A bugzilla report by [[AndyWingo|Andy Wingo]] expanded<ref>http://bugzilla.redhat.com/show_bug.cgi?id=494631</ref> on the problem and drew comments suggesting that <code>rpm</code> and <code>mysql</code> were also failing to due <code>glibc</code> changes. [[JakubJelinek|Jakub Jelinek]] thought they were different problems with the <code>emacs</code> errors being due to <code>malloc_{get|set}_state</code>.


[[User:Scop|Ville Skyttä]] ran<ref>https://www.redhat.com/archives/fedora-devel-list/2010-April/msg00194.html</ref> the <code>rpmlint</code> check and confirmed that it warned exactly of this misuse of a <code>libdir</code> macro.
[[TomLane|TomLane]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00572.html</ref> what was going on with <code>glibc</code> reverting to an earlier version in rawhide. [[User:Jkeating|Jesse Keating]] responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00573.html</ref> that <code>glibc</code> for the <code>i586</code> architecture was broken for all versions after beta. After [[PanuMatilainen|Panu Matilainen]] commented that <code>glibc.i586</code> was so broken that <code>rpm</code> could not even read its own configurations [[UlrichDrepper|Ulrich Drepper]] said<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00600.html</ref>: "If you want to complain then to the idiots who made the decision to go with .i586 instead of .i686 for x86 binaries.  This is exactly the kind of problem I've been warning about all along.  Using the i586 target stresses code paths (in this case in gcc) which are hardly ever used since nobody cares for this target in general." Panu disavowed any intent to complain.


In response to a subsidiary question [[User:Jkeating|Jesse Keating]] explained<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00164.html</ref> that the <code>noarch</code> packages merely appeared to be present in each of the different architecture trees because they were hard-linked.
=== Wireless Regulatory Domain Automatically Determined ===


<references/>
[[User:Linville|John W. Linville]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00566.html</ref> an update to an old(ish) thread. He reported that <code>Fedora 11</code> now has <code>udev</code> rules in place to set wireless regulatory domains based on the configured timezone.


=== Fedora and OpenSolaris Dualboot Issue Solved ===
=== Moonlight Still Banned in Fedora ===


After [[hAhmedKamal|Ahmed Kamal]] reported<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00177.html</ref> that a <code>ZFS</code> formatted partition seemed to be causing a <code>Fedora 11 Beta</code> installation failure there was a quick response. [[User:Sandeen|Eric Sandeen]] noted<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00195.html</ref> that a patch had already been produced<ref>https://www.redhat.com/archives/anaconda-devel-list/2009-April/msg00131.html</ref> by [[User:Dlehman|Dave Lehman]] to merely log the problem instead of raising an errorThe bugzilla entry suggested<ref>https://bugzilla.redhat.com/show_bug.cgi?id=494070</ref> that the root problem was due to <code>udev</code> failing to recognize <code>ZFS</code> properly.
The 2009-04-08 "Rawhide Report"<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00426.html</ref> caused some excitement when it seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00427.html</ref> that <code>moonlight</code><ref>Moonlight is an implementation<ref>http://mono-project.com/Moonlight</ref> of Microsoft's "Silverlight" which is a virtual machine and framework for creating Rich Internet Applications, roughly competing in the same space as Adobe's Flex<ref>http://www.adobe.com/products/flex/</ref> and Mozilla's Prism<ref>http://labs.mozilla.com/projects/prism/</ref>. It is considered<ref>http://fedoraproject.org/wiki/ForbiddenItems#Moonlight</ref> to risky to include in Fedora due to legal worries raised by the Microsoft-Novell covenant</ref> might have been enabled. It turned out<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00500.html</ref> that this was simply due to a confusion between a <code>mono</code> API named "moonlight" and the actual <code>moonlight</code> itself.


<references/>
All that had actually happened<ref>http://bugzilla.redhat.com/show_bug.cgi?id=492048</ref> was that Fedora Legal okayed the use of the mono compiler switch "moonlight" in order to facilitate RPMFusion's request.


=== fallocate(2) Preferred Glibc Interface for Preallocation ? ===
=== Mono Breakage on PPC May Cause Reversion ===


[[JamesRalston|James Ralston]] noted<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00110.html</ref> the adoption of the <code>ext4</code> filesystem in <code>Fedora 11</code> and suggested that in order to use its preallocation features more efficiently it would be useful to patch applications. This could help avoid the current "double write" penalty currently incurred<ref>http://kernelnewbies.org/Ext4#head-3a678beda18002402ba62cf0292fae849d105271</ref> by preallocation in which the reserved space is first filled with nulls. James wondered whether there was a better interface to do this than <code>glibc</code>'s <code>posix_fallocate()</code> which first attempts the allocation and then falls "[...] back to writing nulls to fill up the requested range if fallocate() fails."
Another <code>mono</code> issue discussed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00457.html</ref> with reference to the 2009-04-08 Rawhide Report suggests that due to breakage on the <code>ppc</code> architecture it may be necessary to untag the latest mono package.  


[[User:Sandeen|Eric Sandeen]] suggested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00117.html</ref> using <code>fallocate(2)</code> which is present in the <code>glibc</code> version in rawhide and provided a test program to investigate how well this would work.  
Objections that the disabling of PPC architecture support on the <code>mono</code> package was happening too close to the <code>Fedora 11</code> final freeze prompted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00471.html</ref> [[User:Dnielsen|David Nielsen]] to make the rejoinder that no help had been given to the Mono SIG despite their reporting a problem. [[User:Jkeating|Jesse Keating]] announced<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00483.html</ref> that in the absence of a fix before the final freeze <code>mono</code> would simply be downgraded: "[t]his kind of version change shouldn't really be made after beta anyway."


<references/>
[[User:Dnielsen|David Nielsen]] argued<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00501.html</ref> that the changes had been made well before the beta. [[User:Notting|Bill Nottingham]] thrust<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00515.html</ref> the responsibility back on him. [[User:Alexlan|Alex Lancaster]] made<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00524.html</ref> a similar point more diplomatically.


=== Rawhide Report Glitches Resolved ===
[[User:Mef|Mary Ellen Foster]] requested, as a mono-dependent maintainer, that concrete actions be recommended. [[User:Jkeating|Jesse Keating]] and [[User:Toshio|Toshio Kuratomi]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00568.html</ref> that all such did _not_ set "ExcludeArch: ppc" and rebuild as this would cause massive churn on a large number of packages. Instead a process to track down the failures and fix them with a fallback plan to revert to a mono release-candidate was proposed by Toshio. 


After a few "Rawhide Reports" were missed [[User:Alexlan|Alex Lancaster]] asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00138.html</ref> what was going on. [[User:Jwboyer|Josh Boyer]] answered<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00139.html</ref> that <code>pungi</code> for <code>i386</code> was failing.


Rawhide Reports resumed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00192.html</ref> on 2009-04-04.
=== YUM Downgrade Feature Now in Rawhide ===


<references/>
[[User:James|James Antill]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00469.html</ref> that it is now possible to downgrade a package using
<pre>yum downgrade <packagename></pre>


=== XULRunner Committable by non-Provenpackagers ===
He suggested: "[...]this will be most useful for rawhide users when installing test packages from koji static repos. etc. ... because then an older version will still be available in rawhide. Whereas if you upgrade to what is in rawhide there is nothing older available to downgrade to."


The summary of the 2009-04-03 FESCo meeting indicated<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00199.html</ref> that "Firefox/Thunderbird/XULRunner" are open for commits by those who do not have "provenpackager" status. Also discussed and declined for such changes were: <code>popt</code>; <code>initscripts</code>; <code>ethtool</code>; lvm-related packages; and <code>hwdata</code>.
=== Multiple Package Ownership of Directories ===


[[User:Jstanley|Jon Stanley]] also noted<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00109.html</ref> that he was going to shoulder the burden of providing his excellent summaries of FESCo meetings.  
A query posed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00425.html</ref> by [[User:Sundaram|Rahul Sundaram]] concerned whether it was appropriate for multiple packages to claim ownership of a directory.


<references/>
[[User:Mschwendt|Michael Schwendt]] and [[User:Cwickert|Christoph Wickert]] were<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00544.html</ref> clear that the packages Rahul mentioned should not own the directory because they were part of a dependency chain which led up to their ancestor package <code>hicolor-icon-theme</code>. Contrary advice led<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00546.html</ref> to some sarcasm from [[User:Cwickert|Christoph Wickert]] about Red Hat employees not being familiar with Fedora packaging guidelines and it worried<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00591.html</ref> [[User:Peter|Peter Lemenkov]], who believed that Red Hat employees all had "provenpackager" status (see FWN#170<ref>http://fedoraproject.org/wiki/FWN/Issue170#Provenpackager_Policies</ref>). [[User:Tibbs|Jason L. Tibbitts III]] corrected<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00595.html</ref> this latter assertion.


=== Provenpackager Policies ===
=== Zap DontZap ===


Also discussed in the 2009-04-04 FESCo meeting were several requests for "provenpackager" and "sponsor" status. This followed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00067.html</ref> on the heels of work done by [[User:Pertusus|Patrice Dumas]] to codify some meanings and processes around "provenpackagers".
[[PaulWouters|Paul Wouters]] reported<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00363.html</ref> that he had needed to <code>ssh</code> into his machine to fix an X session problem and would like to revert "[...] to the old behavior of having ctrl-alt-backspace kill the current X session." See FWN#169<ref>http://fedoraproject.org/wiki/FWN/Issue169#Emacs_Cabal_Disables_Xorg_Ctrl-Alt-Backspace</ref> for earlier discussion.


A general concern was expressed<ref>http://bpepple.fedorapeople.org/fesco/FESCo-2009-04-03.html</ref> in the IRC meeting that the ability of a provenpackager to modify others' packages should not be used lightly. [[DavidWoodhouse|David Woodhouse]] warned that "provenpackagers who commit to other packages without even _trying_ to coordinate with the owner should expect censure" and [[User:Jstanley|Jon Stanley]] posted a helpful link<ref>https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages</ref> to a wiki entry on "Who is allowed to modify which packages".
[[AndersRayner-Karlsson|Anders Rayner-Karlsson]] explained that dual-head setup in <code>Fedora 10</code> was as simple as:


<references/>
<pre>xrandr --output LVDS --auto --output VGA --auto --above LVDS</pre>


=== Python3K Planning ===
to which [[User:Mooninite|Michael Cronenworth]] responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00371.html</ref> that this would need to be done in a start-up script as there was also now no <code>xorg.conf</code> by default. [[User:Jkeating|Jesse Keating]] suggested using the <pre>System -> Preferences -> Display</pre> tool instead as this would obviate the need for an <code>xorg.conf</code>. [[AdamJackson|Adam Jackson]] cautioned<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00377.html</ref> that nVidia's proprietary drivers might not export RANDR-1.2 yet and thus the latter might not work. Further discussions about whether <code>xorg.conf</code> was needed for side-by-side wide virtual desktops suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00430.html</ref> that Intel chipsets while currently enforcing a 2048 pixel limit may be<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00450.html</ref> capable of supporting up to 4096 pixels on <code>Intel 915</code> or <code>Intel 945</code> in the near future.


[[User:Toshio|Toshio Kuratomi]] reported<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00085.html</ref> on a PyCon<ref>http://us.pycon.org/</ref> talk on Python 3 incompatibility which he had attended. LennartRegebro's "Python 3 Compatibility"<ref>http://us.pycon.org/media/2009/talkdata/PyCon2009/074/Python_3_Compatibility.pdf</ref> talk stimulated Toshio to consider how to port older python code to python-2.6's py3 compatiblity layer.
Dissent and discussion about Fedora's decision to follow the upstream rumbled on. [[User:Kkofler|Kevin Kofler]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00617.html</ref> that "mailing list consensus" was not a good process by which to make such decisions as that taken by Xorg. [[DaveAirlie|Dave Airlie]] seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00635.html</ref> as though he had had enough of personal attacks on him, but was also able to joke about it.
 
When [[User:S4504kr|Jochen Schmitt]] suggested a compatibility package [[User:Spot|Tom Callaway]] replied<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00089.html</ref> that this would just be a crutch that perpetuated upstream projects unwillingness to move to Python 3. Tom preferred that Fedora developers would "[...] help port such applications to Python 3, and do so in a way that they detect the version of python at runtime and set defines appropriately. That way, we can have applications ready for Python3 before we actually make the switch."
 
There seemed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00104.html</ref> to be rough agreement between [[User:Toshio|Toshio Kuratomi]] and [[User:James|James Antill]] that some way of allowing python3 modules and an interpreter in parallel to python-2 would be necessary.  
 
[[User:Ivazquez|Ignacio Vazquez-Abrams]] linked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00140.html</ref> to video of all the PyCon 2009 sessions.  
 
<references/>

Revision as of 02:24, 13 April 2009

Developments

In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.

Contributing Writer: Oisin Feeley

Emacs, Glibc, Malloc and i586

As the pressure to stick to the Fedora 11 release schedule built up some glitches arising in part from the decision to support i586 instead of i686 (see FWN#162[1]) led to tense words.

Reports trickled in of problems with emacs in rawhide. Per Bothner reported[2] both that emacs-23.0.91 threw an "Invalid regex: Unmatched ( or \\(" and that emacs-23-0.92 was responding excruciatingly slowly. Ulrich Drepper speculated[3] to that the regexp problem was due to some changes to malloc in glibc. A bugzilla report by Andy Wingo expanded[4] on the problem and drew comments suggesting that rpm and mysql were also failing to due glibc changes. Jakub Jelinek thought they were different problems with the emacs errors being due to malloc_{get|set}_state.

TomLane asked[5] what was going on with glibc reverting to an earlier version in rawhide. Jesse Keating responded[6] that glibc for the i586 architecture was broken for all versions after beta. After Panu Matilainen commented that glibc.i586 was so broken that rpm could not even read its own configurations Ulrich Drepper said[7]: "If you want to complain then to the idiots who made the decision to go with .i586 instead of .i686 for x86 binaries. This is exactly the kind of problem I've been warning about all along. Using the i586 target stresses code paths (in this case in gcc) which are hardly ever used since nobody cares for this target in general." Panu disavowed any intent to complain.

Wireless Regulatory Domain Automatically Determined

John W. Linville posted[8] an update to an old(ish) thread. He reported that Fedora 11 now has udev rules in place to set wireless regulatory domains based on the configured timezone.

Moonlight Still Banned in Fedora

The 2009-04-08 "Rawhide Report"[9] caused some excitement when it seemed[10] that moonlightCite error: Closing </ref> missing for <ref> tag of Microsoft's "Silverlight" which is a virtual machine and framework for creating Rich Internet Applications, roughly competing in the same space as Adobe's Flex[11] and Mozilla's Prism[12]. It is considered[13] to risky to include in Fedora due to legal worries raised by the Microsoft-Novell covenant. </ref> might have been enabled. It turned out[14] that this was simply due to a confusion between a mono API named "moonlight" and the actual moonlight itself.

All that had actually happened[15] was that Fedora Legal okayed the use of the mono compiler switch "moonlight" in order to facilitate RPMFusion's request.

Mono Breakage on PPC May Cause Reversion

Another mono issue discussed[16] with reference to the 2009-04-08 Rawhide Report suggests that due to breakage on the ppc architecture it may be necessary to untag the latest mono package.

Objections that the disabling of PPC architecture support on the mono package was happening too close to the Fedora 11 final freeze prompted[17] David Nielsen to make the rejoinder that no help had been given to the Mono SIG despite their reporting a problem. Jesse Keating announced[18] that in the absence of a fix before the final freeze mono would simply be downgraded: "[t]his kind of version change shouldn't really be made after beta anyway."

David Nielsen argued[19] that the changes had been made well before the beta. Bill Nottingham thrust[20] the responsibility back on him. Alex Lancaster made[21] a similar point more diplomatically.

Mary Ellen Foster requested, as a mono-dependent maintainer, that concrete actions be recommended. Jesse Keating and Toshio Kuratomi asked[22] that all such did _not_ set "ExcludeArch: ppc" and rebuild as this would cause massive churn on a large number of packages. Instead a process to track down the failures and fix them with a fallback plan to revert to a mono release-candidate was proposed by Toshio.


YUM Downgrade Feature Now in Rawhide

James Antill posted[23] that it is now possible to downgrade a package using

yum downgrade <packagename>

He suggested: "[...]this will be most useful for rawhide users when installing test packages from koji static repos. etc. ... because then an older version will still be available in rawhide. Whereas if you upgrade to what is in rawhide there is nothing older available to downgrade to."

Multiple Package Ownership of Directories

A query posed[24] by Rahul Sundaram concerned whether it was appropriate for multiple packages to claim ownership of a directory.

Michael Schwendt and Christoph Wickert were[25] clear that the packages Rahul mentioned should not own the directory because they were part of a dependency chain which led up to their ancestor package hicolor-icon-theme. Contrary advice led[26] to some sarcasm from Christoph Wickert about Red Hat employees not being familiar with Fedora packaging guidelines and it worried[27] Peter Lemenkov, who believed that Red Hat employees all had "provenpackager" status (see FWN#170[28]). Jason L. Tibbitts III corrected[29] this latter assertion.

Zap DontZap

Paul Wouters reported[30] that he had needed to ssh into his machine to fix an X session problem and would like to revert "[...] to the old behavior of having ctrl-alt-backspace kill the current X session." See FWN#169[31] for earlier discussion.

Anders Rayner-Karlsson explained that dual-head setup in Fedora 10 was as simple as:

xrandr --output LVDS --auto --output VGA --auto --above LVDS

to which Michael Cronenworth responded[32] that this would need to be done in a start-up script as there was also now no xorg.conf by default. Jesse Keating suggested using the

System -> Preferences -> Display

tool instead as this would obviate the need for an xorg.conf. Adam Jackson cautioned[33] that nVidia's proprietary drivers might not export RANDR-1.2 yet and thus the latter might not work. Further discussions about whether xorg.conf was needed for side-by-side wide virtual desktops suggested[34] that Intel chipsets while currently enforcing a 2048 pixel limit may be[35] capable of supporting up to 4096 pixels on Intel 915 or Intel 945 in the near future.

Dissent and discussion about Fedora's decision to follow the upstream rumbled on. Kevin Kofler suggested[36] that "mailing list consensus" was not a good process by which to make such decisions as that taken by Xorg. Dave Airlie seemed[37] as though he had had enough of personal attacks on him, but was also able to joke about it.

  1. http://fedoraproject.org/wiki/FWN/Issue162#Fedora_11_Will_Support_i586_Instruction_Set
  2. http://www.redhat.com/archives/fedora-test-list/2009-April/msg00221.html
  3. http://www.redhat.com/archives/fedora-test-list/2009-April/msg00225.html
  4. http://bugzilla.redhat.com/show_bug.cgi?id=494631
  5. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00572.html
  6. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00573.html
  7. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00600.html
  8. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00566.html
  9. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00426.html
  10. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00427.html
  11. http://www.adobe.com/products/flex/
  12. http://labs.mozilla.com/projects/prism/
  13. http://fedoraproject.org/wiki/ForbiddenItems#Moonlight
  14. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00500.html
  15. http://bugzilla.redhat.com/show_bug.cgi?id=492048
  16. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00457.html
  17. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00471.html
  18. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00483.html
  19. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00501.html
  20. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00515.html
  21. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00524.html
  22. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00568.html
  23. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00469.html
  24. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00425.html
  25. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00544.html
  26. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00546.html
  27. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00591.html
  28. http://fedoraproject.org/wiki/FWN/Issue170#Provenpackager_Policies
  29. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00595.html
  30. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00363.html
  31. http://fedoraproject.org/wiki/FWN/Issue169#Emacs_Cabal_Disables_Xorg_Ctrl-Alt-Backspace
  32. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00371.html
  33. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00377.html
  34. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00430.html
  35. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00450.html
  36. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00617.html
  37. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00635.html