From Fedora Project Wiki

< FWN‎ | Beats

(Devel #158 pass 1)
 
(69 intermediate revisions by the same user not shown)
Line 5: Line 5:
mailing list are summarized.
mailing list are summarized.


Contributing Writer: [[OisinFeeley|Oisin Feeley]]
Contributing Writer: [[User:Ush|Oisin Feeley]]


=== Default ssh-agent Dialog Pop-up ===
=== Would You Like to Write This Beat ? ===


Confusion abounded when user "nodata" reported[1] that running <code>ssh-add</code> from the command-line popped up a gnome dialog requesting his private SSH key. "nodata" disliked handing out his private key in such a manner. The confusion resulted from the availability of at least two possible <code>ssh-agents</code>[2] and also a change in configuration between <code>Fedora 9</code> and <code>Fedora 10</code> which presents the authentication dialog by default.
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.


[[RickyZhou|Ricky Zhou]] was among those who suggested (with a manpage quote) that the <code>SSH_ASKPASS</code> environment variable determined whether the passphrase was read from a terminal or by an X11 dialog. Separately [[JesseKeating|Jesse Keating]][3] and [[NalinDahyabhai|Nalin Dahyabhi]] explained[4] that the dialog was presented by <code>gnome-keyring</code> and not <code>gnome-ssh-askpass</code>.
<references/>


"nodata" questioned[5] whether the behavior had changed between <code>Fedora 9</code> and <code>Fedora 10</code> and expressed irritation that a "[...] GUI is popping up when I am using a command line app." [[JesseKeating|Jesse Keating]] responded[6]: "You're using a command line app from a graphical terminal. Also, cli apps aren't the only use for ssh and ssh keys." This did not appeal to many respondents including [[JohnLinville|John Linville]] who questioned[7] the benefit of changing focus to a new window to type a passphrase. [[CallumLerwick|Callum Lerwick]] rather tartly outlined[8] some benefits including preventing key logging attacks.
=== Is gNaughty a Hot Babe ? ===


[[MatthiasClasen|Matthias Clasen]] suggested[9] using
[[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.  
<pre>
gconftool-2 -s -t bool /apps/gnome-keyring/daemon-components/ssh false
</pre>
to turn off the behavior for those who dislike it and this led to several requests to make this the default. [[AndrewHaley|Andrew Haley]] put[10] the case that "[t]he key argument against a pop-up dialog box that asks for the passphrase is that we're training people to type secrets into pop-up dialog boxes. Bad psychology, bad security."


][MatthiasClasen|Matthias Clasen]] and [[TomasMraz|Tomas Mraz]] with [[JerryAmundson|Jerry Amundson]] explored[11] the use of <code>SSH_ASKPASS</code> as an alternate method to disable the GUI dialog.
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?"


[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00486.html
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. 


[2] Private keys are stored by ssh agents so that they may handle all key related operations requested by clients. The passphrase to decrypt the key thus need only be typed into the agent once instead of per-operation.
<references/>


[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00487.html
=== Chrome9 Vx800 Graphics Support on LiveUSB ===


[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00536.html
[[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?"


[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00492.html
[[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.


[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00495.html
<references/>


[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00523.html
=== Who Wants a Pony? ===


[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00533.html
[[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.


[9] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00498.html
<references/>


[10] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00517.html
=== Firestarter Retired as Unportable to PolicyKit ===


[11] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00540.html
[[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>.


=== Intel Graphics Installation Woes ===
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/>


"Mike" requested[1] information on when a working <code>xorg-x11-drv-i810</code> driver for Intel graphics chipsets had a chance of appearing. He was disappointed that it was non-trivial to get two machines with <code>82945G</code> and <code>82845G</code> chipsets installed and had needed to fall back to using the <code>vesa</code> driver instead of the intel one.
=== Russian Fedora ? ===


Others listed outstanding bugzilla entries for a wide range of Intel chipsets. [[DanWilliams|Dan Williams]] asked[2] if using Option "EXANoComposite" "true" as a workaround for problems with the <code>i830</code> chipsets was succesfull and received mixed reports. It seemed that he was making some progress with resolving some of the issues.
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.


MAYoung suggested[3] that setting "NoAccel true" in <code>xorg.conf</code> might work for some people but that "[...] intel graphics are highly flaky on Fedora 10."
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]].


[[RobertArendt|Robert Arendt]] laid[4] the blame at the door of upstream merges of <code>GEM/DRM</code> into the kernel and noted that other distributions were suffering identical problems. "Mike" later confirmed[5] this with a list of bugzilla entries from upstream GNOME: "It would be nice if Intel would help to get this fixed, and there are indeed problems with Suse, Ubuntu and Mandriva also with newer drivers and Intel graphics chipsets of various flavors - this is really bad!"
<references/>


[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00435.html
=== Will FESCo Revisit Kmods ? ===


[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00475.html
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]].


[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00443.html
[[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>.


[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00445.html
<references/>


[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00467.html
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===


=== KPackageKit Auto-update Bug ===
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."


[[MichaelAllen|Michael B Allen]] reported[1] that his system had performed an update without his permission and asked how to completely disable such behavior. 
<references/>
 
It appeared[2] that this was due to a bug in <code>KPackageKit</code> which has been unfixable[3] for over a month due in part to the complexity of the code.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00461.html
 
[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00504.html
 
[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00510.html
 
=== Disabling Staging Drivers ? ===
 
[[RahulSundaram|Rahul Sundaram]] asked[1] if enabling the many new drivers in the staging tree[2] would make sense in <code>rawhide</code> in order to support a wider range of hardware such as the <code>EeePC</code>'s <code>ralink</code> wireless chipset.
 
Opinion was roughly split between those who were completely against the idea and those who suggested avoiding codifying a rigid policy. [[MatthewGarrett|Matthew Garrett]] believed[3] that it would be "somewhat user-hostile" to, for example enable the <code>ralink</code> drivers in <code>rawhide</code> but possibly remove them for a general release. He argued that the <code>ralink</code> drivers were a dead-end[4] which would never merge upstream. On the other hand [[DaveJones|Dave Jones]] preferred[5] to take a case-by-case approach as long as "[...] we have someone responsible for working on it, with the goal of getting it out of staging, and dealing with bugs etc. Not unlike the same reasoning for us adding various not-yet-upstream drivers to the Fedora kernel really."
 
While preferring to completely disable the staging drivers [[ThorstenLeemhuis|Thorsten Leemhuis]] expressed[6] the intention to provide <code>RPM Fusion</code> <code>kmods</code> in that case. [[DanWilliams|Dan Williams]] made[7] a strong argument that "-staging" itself was a bad idea as it gave "legitimacy to drivers of questionable quality" and [[JohnLinville|John Linville]] limned[8] the tortured history of the <code>at76</code> driver.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00459.html
 
[2] "linux-staging" is a kernel tree whose purpose is to test drivers and filesystems for later inclusion in mainline http://lkml.org/lkml/2008/6/10/329
 
[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00462.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00474.html
 
[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00472.html
 
[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00465.html
 
[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00473.html
 
[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00476.html
 
=== git-* Commands Moved to /usr/libexec/git-core/ ===
 
[[AdamTkac|Adam Tkac]] worried[1] that scripts would break due to the latest git branch in rawhide which had moved all the <code>git-*</code> binaries to <code>/usr/libexec/git-core</code> in order to comply with upstream practice. The issue was previously discussed (see FWN#141[2)] with the resolution that updating to <code>git-1.6.0</code> would be a flag day for this change. Adam suggested that the new location could be added to the <code>PATH</code> environment variable but this received no support.
 
[[KarelZak|Karel Zak]] advocated[3] that such scripts should be fixed as the change had been coming since 2006.
 
[[BrynReeves|Bryn Reeves]] wondered[4] if compatibility symlinks and a release note would ease the transition over a couple of releases. Although the symlinks were generally felt to be a non-effective strategy [[ToddZulinger|Todd Zulinger]] was encouraged[5] by [[PaulFrields|Paul W. Frields]] to open a bugzilla entry against the Release Notes to ensure that the documentation team take care of highlighting the issue for <code>Fedora 11</code>.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00404.html
 
[2] http://fedoraproject.org/wiki/FWN/Issue141#Git-1.6.0_Commands_to_be_Moved_Out_of_PATH
 
[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00408.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00410.html
 
[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00460.html
 
=== Mandatory FHS Adherence ===
 
[[JasonLTibbittsIII|JasonTibbitts]] posted[1] a summary and links to the 2009-01-06 FPC meeting deliberations. Interest on @fedora-devel was mostly sparked by the item which declared that the FPC would "Make adherence to the FHS a MUST [.]" Jason encouraged reading of the full minutes in order to understand this item.
 
[[DougLedford|Doug Ledford]] discussed[2] the problem his MPI[3] implementations experienced with the FHS and [[RichardJones|Richard W. M. Jones]] expressed [4] concern that the FHS was a moribund standard and adhering to it would block projects such as MinGW without any method to evolve the standard. [[ToshioKuratomi|Toshio Kuratomi]] responded in detail in both threads and pointed out[5] that the MinGW case had been addressed in the meeting and also that there were problems with changing the FHS.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00362.html
 
[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00424.html
 
[3] http://www.open-mpi.org/papers/ipdps-2006/
 
[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00469.html
 
[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00483.html

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"