From Fedora Project Wiki

< FWN‎ | Beats

(171 devel beat pass 1.)
 
(27 intermediate revisions by the same user not shown)
Line 7: Line 7:
Contributing Writer: [[User:Ush|Oisin Feeley]]
Contributing Writer: [[User:Ush|Oisin Feeley]]


=== Emacs, Glibc, Malloc and i586 ===
=== Would You Like to Write This Beat ? ===


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.
Following this issue (FWN#178) I will, with regret, no longer be covering the @fedora-devel list. If you are interested in writing this weekly summary of the deeds and doings on the list then please contact fedora-news-list@redhat.com or [[User:Pcalarco|Pascal Calarco]]. A short overview of what you may need to do can be obtained by reading the workflow<ref>http://fedoraproject.org/wiki/FWN/WorkFlow</ref> section of the wiki. The @fedora-news list is also extremely open and helpful. Joining<ref>http://fedoraproject.org/wiki/FWN/NewsProject/Join</ref> the News Project is quite straightforward.


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>.
<references/>


[[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.
=== Is gNaughty a Hot Babe ? ===


=== Wireless Regulatory Domain Automatically Determined ===
[[User:Sundaram|Rahul Sundaram]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02071.html</ref> the results of a survey conducted, primarily on @fedora-list and on the forums, to discover which non-repository-packaged software Fedora consumers were using.


[[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.
One interesting point is that CMUCL<ref>One of the Common Lisp implementations: http://www.cons.org/cmucl/</ref> was revealed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02088.html</ref> to be only available for 32-bit systems. However what got people really excited was<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02136.html</ref> Rahul's question about what to do concerning the <code>gNaughty</code> package. Its sole purpose seemed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02203.html</ref> to be downloading pornography. Rahul referenced the <code>hot-babe</code> CPU monitor which enjoyed controversy in Debian packaging circles due to its use of female nudity.  Rahul wanted to find out "[...] is this allowed in Fedora?"


=== Moonlight Still Banned in Fedora ===
Amusingly a good deal of the controversy focused on whether the content was freely redistributable, but a predictable moral angle was raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02242.html</ref> by [[User:Alsadi|Muayyad AlSadi]] who asked for help in producing a spin which removed content deemed objectionable. Muayyad is a Jordanian developer who has been producing an Arabic-localized Fedora spin named "Ojuba" for some time. Muayyad sought a way to make identifying and tagging packages easier to facilitate this spin. [[User:Notting|Bill Nottingham]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02312.html</ref> skeptical about the chances of tags keeping meaning unless there was some sort of review board. Equally predictable was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02295.html</ref> the reaction typified by [[User:Skvidal|Seth Vidal]] which resisted any attempt to restrict packages according to standards which had nothing to do with licensing or patent issues. [[User:bochcecha|Mathieu Bridon]] thought<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02355.html</ref> that the creation of a wiki-page by Muayyad would allow anyone interested in co-ordinating work on "Inappropriate Content" to just go ahead and do it without dragging in bureaucracy. 


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.
=== Chrome9 Vx800 Graphics Support on LiveUSB ===


=== Mono Breakage on PPC May Cause Reversion ===
[[KristapsViesalgs|Kristaps Viesalgs]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02146.html</ref> for help in getting the Fedora Live USB to boot correctly on a machine using a Via Vx800 "Chrome9" GPU. Kristaps had some success with the latest upstream version (from their subversion repository) and asked: "Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility?"


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:Ajax|Adam Jackson]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02154.html</ref> for a more specific bug report because the chip should be supported. He preferred not to ship an autoconfiguration utility instead of just getting the driver correct. Similar points were made by [[User:Adamwill|Adam Williamson]] and [[User:|Xavier Bachelot]]. The latter asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02163.html</ref> any interested developers to help out the openchrome project in both the 2D and 3D(Gallium) sides.  


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.
=== Who Wants a Pony? ===


[[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. 
[[User:Kushal|Kushal Das]] promised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02139.html</ref> a pony to anyone that would take the trouble to review<ref>http://bugzilla.redhat.com/show_bug.cgi?id=503021</ref> one of his packages.


<references/>


=== YUM Downgrade Feature Now in Rawhide ===
=== Firestarter Retired as Unportable to PolicyKit ===


[[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
[[User:Maxamillion|Adam Miller]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02089.html</ref> whether he should just retire the <code>Firestarter</code><ref>Firestarter is a firewall configuration GUI</ref> package for which he had recently become the maintainer. His query was based on the recent filing of RFEs to integrate <code>Firestarter</code> with <code>PolicyKit</code>. These suggested to Adam that a large amount of work would be needed due to the lack of any upstream activity for four years and the need to grok <code>PolicyKit</code>.
<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."  
Following confirmation from [[User:Sundaram|Rahul Sundaram]] and [[User:Skvidal|Seth Vidal]] a decision was made<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02094.html</ref> by Adam: "I would honestly rather retire the package than do a WONTFIX, if the project as a whole is going the direction of PolicyKit and upstream is dead then I don't want to keep old and busted cruft around the repositories as Fedora continues to look towards the future."
A further suggestion from "Cry" prompted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02122.html</ref> Adam to start filing RFEs against <code>system-config-firewall</code> for any features present in <code>Firestarter</code> but missing in <code>system-config-firewall</code>.
<references/>


=== Multiple Package Ownership of Directories ===
=== Russian Fedora ? ===


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.
When [[User:Peter|Peter Lemenkov]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02013.html</ref> about the idea of creating a Fedora Foundation outside of the U.S.A. the usual arguments from the past few years were rehashed. [[User:Kkofler|Kevin Kofler]] gave<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02025.html</ref> an able summary why this would still present Red Hat with a problem.


[[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.
An assertion by [[User:|Alexey Torkhov]] that there existed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02390.html</ref> a Red Hat-sanctioned "RussianFedora" spin which contained mp3 codecs and other material excluded from the actual Fedora Project repositories drew demands for proof from [[User:Sundaram|Rahul Sundaram]].


=== Zap DontZap ===
<references/>


[[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.
=== Will FESCo Revisit Kmods ? ===


[[AndersRayner-Karlsson|Anders Rayner-Karlsson]] explained that dual-head setup in <code>Fedora 10</code> was as simple as:
A discussion of why <code>VirtualBox</code> will not be a feature due to its code not yet heading upstream and consequently remaining as <code>kmods</code> drew a statement of support from [[User:Kkofler|Kevin Kofler]] for reverting the current banning of <code>kmods</code> should he become a FESCo member. Upon request from [[RichardJones|Richard W.M. Jones]] for a dispassionate summary of the reasons to avoid <code>kmods</code> drew<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02254.html</ref> a concise response from [[User:Skvidal|Seth Vidal]].


<pre>xrandr --output LVDS --auto --output VGA --auto --above LVDS</pre>
[[User:Adamwill|Adam Williamson]] and [[User:Mdomsch|Matt Domsch]] (Dell's DKMS mastermind) kicked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02368.html</ref> some ideas back and forth over the advantages of <code>akmods</code> versus <code>kmods</code>.


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.
<references/>


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.
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===
 
Following a report from [[UweKiewel|Uwe Kiewel]] that a <pre>yum upgrade</pre> had spewed all sorts of errors the supported methods for upgrades were re-stated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02041.html</ref> by [[User:Adamwill|Adam Williamson]]: "[I]f you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline."
 
<references/>

Latest revision as of 01:15, 1 June 2009

Developments

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

Contributing Writer: Oisin Feeley

Would You Like to Write This Beat ?

Following this issue (FWN#178) I will, with regret, no longer be covering the @fedora-devel list. If you are interested in writing this weekly summary of the deeds and doings on the list then please contact fedora-news-list@redhat.com or Pascal Calarco. A short overview of what you may need to do can be obtained by reading the workflow[1] section of the wiki. The @fedora-news list is also extremely open and helpful. Joining[2] the News Project is quite straightforward.

  1. ↑ http://fedoraproject.org/wiki/FWN/WorkFlow
  2. ↑ http://fedoraproject.org/wiki/FWN/NewsProject/Join

Is gNaughty a Hot Babe ?

Rahul Sundaram posted[1] the results of a survey conducted, primarily on @fedora-list and on the forums, to discover which non-repository-packaged software Fedora consumers were using.

One interesting point is that CMUCL[2] was revealed[3] to be only available for 32-bit systems. However what got people really excited was[4] Rahul's question about what to do concerning the gNaughty package. Its sole purpose seemed[5] to be downloading pornography. Rahul referenced the hot-babe CPU monitor which enjoyed controversy in Debian packaging circles due to its use of female nudity. Rahul wanted to find out "[...] is this allowed in Fedora?"

Amusingly a good deal of the controversy focused on whether the content was freely redistributable, but a predictable moral angle was raised[6] by Muayyad AlSadi who asked for help in producing a spin which removed content deemed objectionable. Muayyad is a Jordanian developer who has been producing an Arabic-localized Fedora spin named "Ojuba" for some time. Muayyad sought a way to make identifying and tagging packages easier to facilitate this spin. Bill Nottingham was[7] skeptical about the chances of tags keeping meaning unless there was some sort of review board. Equally predictable was[8] the reaction typified by Seth Vidal which resisted any attempt to restrict packages according to standards which had nothing to do with licensing or patent issues. Mathieu Bridon thought[9] that the creation of a wiki-page by Muayyad would allow anyone interested in co-ordinating work on "Inappropriate Content" to just go ahead and do it without dragging in bureaucracy.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02071.html
  2. ↑ One of the Common Lisp implementations: http://www.cons.org/cmucl/
  3. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02088.html
  4. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02136.html
  5. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02203.html
  6. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02242.html
  7. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02312.html
  8. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02295.html
  9. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02355.html

Chrome9 Vx800 Graphics Support on LiveUSB

Kristaps Viesalgs asked[1] for help in getting the Fedora Live USB to boot correctly on a machine using a Via Vx800 "Chrome9" GPU. Kristaps had some success with the latest upstream version (from their subversion repository) and asked: "Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility?"

Adam Jackson asked[2] for a more specific bug report because the chip should be supported. He preferred not to ship an autoconfiguration utility instead of just getting the driver correct. Similar points were made by Adam Williamson and [[User:|Xavier Bachelot]]. The latter asked[3] any interested developers to help out the openchrome project in both the 2D and 3D(Gallium) sides.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02146.html
  2. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02154.html
  3. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02163.html

Who Wants a Pony?

Kushal Das promised[1] a pony to anyone that would take the trouble to review[2] one of his packages.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02139.html
  2. ↑ http://bugzilla.redhat.com/show_bug.cgi?id=503021

Firestarter Retired as Unportable to PolicyKit

Adam Miller asked[1] whether he should just retire the Firestarter[2] package for which he had recently become the maintainer. His query was based on the recent filing of RFEs to integrate Firestarter with PolicyKit. These suggested to Adam that a large amount of work would be needed due to the lack of any upstream activity for four years and the need to grok PolicyKit.

Following confirmation from Rahul Sundaram and Seth Vidal a decision was made[3] by Adam: "I would honestly rather retire the package than do a WONTFIX, if the project as a whole is going the direction of PolicyKit and upstream is dead then I don't want to keep old and busted cruft around the repositories as Fedora continues to look towards the future."

A further suggestion from "Cry" prompted[4] Adam to start filing RFEs against system-config-firewall for any features present in Firestarter but missing in system-config-firewall.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02089.html
  2. ↑ Firestarter is a firewall configuration GUI
  3. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02094.html
  4. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02122.html

Russian Fedora ?

When Peter Lemenkov asked[1] about the idea of creating a Fedora Foundation outside of the U.S.A. the usual arguments from the past few years were rehashed. Kevin Kofler gave[2] an able summary why this would still present Red Hat with a problem.

An assertion by [[User:|Alexey Torkhov]] that there existed[3] a Red Hat-sanctioned "RussianFedora" spin which contained mp3 codecs and other material excluded from the actual Fedora Project repositories drew demands for proof from Rahul Sundaram.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02013.html
  2. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02025.html
  3. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02390.html

Will FESCo Revisit Kmods ?

A discussion of why VirtualBox will not be a feature due to its code not yet heading upstream and consequently remaining as kmods drew a statement of support from Kevin Kofler for reverting the current banning of kmods should he become a FESCo member. Upon request from Richard W.M. Jones for a dispassionate summary of the reasons to avoid kmods drew[1] a concise response from Seth Vidal.

Adam Williamson and Matt Domsch (Dell's DKMS mastermind) kicked[2] some ideas back and forth over the advantages of akmods versus kmods.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02254.html
  2. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02368.html

Upgrade from Fedora 10 to Rawhide (Fedora 11)

Following a report from Uwe Kiewel that a 

yum upgrade

had spewed all sorts of errors the supported methods for upgrades were re-stated[1] by Adam Williamson: "[I]f you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline."

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02041.html
Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Beats/Developments&oldid=105137"