(170 devel pass3) |
(171 devel beat pass 1.) |
||
Line 7: | Line 7: | ||
Contributing Writer: [[User:Ush|Oisin Feeley]] | Contributing Writer: [[User:Ush|Oisin Feeley]] | ||
=== | === Emacs, Glibc, Malloc and i586 === | ||
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. | |||
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: | [[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. | ||
=== Wireless Regulatory Domain Automatically Determined === | |||
< | [[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 | === Moonlight Still Banned in Fedora === | ||
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. | |||
< | 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. | ||
=== | === Mono Breakage on PPC May Cause Reversion === | ||
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: | 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." | ||
< | [[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. | ||
[[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. | |||
Rawhide | === YUM Downgrade Feature Now in Rawhide === | ||
< | [[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> | |||
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<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. | |||
< | [[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. | ||
=== | === Zap DontZap === | ||
[[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. | |||
[[AndersRayner-Karlsson|Anders Rayner-Karlsson]] explained that dual-head setup in <code>Fedora 10</code> was as simple as: | |||
< | <pre>xrandr --output LVDS --auto --output VGA --auto --above LVDS</pre> | ||
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. | |||
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. | |||
[[ | |||
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 moonlight
Cite 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.
- ↑ http://fedoraproject.org/wiki/FWN/Issue162#Fedora_11_Will_Support_i586_Instruction_Set
- ↑ http://www.redhat.com/archives/fedora-test-list/2009-April/msg00221.html
- ↑ http://www.redhat.com/archives/fedora-test-list/2009-April/msg00225.html
- ↑ http://bugzilla.redhat.com/show_bug.cgi?id=494631
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00572.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00573.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00600.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00566.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00426.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00427.html
- ↑ http://www.adobe.com/products/flex/
- ↑ http://labs.mozilla.com/projects/prism/
- ↑ http://fedoraproject.org/wiki/ForbiddenItems#Moonlight
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00500.html
- ↑ http://bugzilla.redhat.com/show_bug.cgi?id=492048
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00457.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00471.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00483.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00501.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00515.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00524.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00568.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00469.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00425.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00544.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00546.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00591.html
- ↑ http://fedoraproject.org/wiki/FWN/Issue170#Provenpackager_Policies
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00595.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00363.html
- ↑ http://fedoraproject.org/wiki/FWN/Issue169#Emacs_Cabal_Disables_Xorg_Ctrl-Alt-Backspace
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00371.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00377.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00430.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00450.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00617.html
- ↑ http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00635.html