From Fedora Project Wiki

< FWN‎ | Beats

(171 devel beat pass 1.)
m (give proper name of tool instead of showing way to access it)
Line 57: Line 57:
 
<pre>xrandr --output LVDS --auto --output VGA --auto --above LVDS</pre>
 
<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.
+
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 <code>system-config-display</code> 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.
 
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:26, 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-config-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