From Fedora Project Wiki

< FWN‎ | Beats

(get JvM wikipage right)
 
(67 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]]


=== The Possible Future of Comps ? ===
=== Would You Like to Write This Beat ? ===


[[SethVidal|Seth Vidal]] reported[1] that one outcome of the recent FUDCon[2] had been an initiative to overhaul the <code>comps.xml</code> file. This file is part of the metadata used to define group membership of related packages in order to allow[3] <code>yum</code> or <code>anaconda</code> to aid in installation.
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.


Seth described the intent to replace the fixed group definitions with metapackages created on-the-fly, based on examining and dependency-solving repository metadata, as "a fairly radical departure". Related changes will be the ability to define groups within groups and the addition of new metadata to allow tag cloud classification. Some of the anticipated benefits are the ability to find desired software more easily, the creation of more fine-grained groups and a more intuitive persistence of groups.
<references/>


One apparent sticking point raised by [[BillNottingham|Bill Nottingham]] was that the flattening of the package levels included the removal of "conditional" packages and "[...] a large portion of the language support is built around conditional packages." Seth argued[4] that removing conditional packages was something which was desirable whether or not this particular initiative took hold. This seemed like a problem especially for <code>KDE</code> but Bill prototyped[5] a <code>yum</code> plugin to solve the problem.
=== Is gNaughty a Hot Babe ? ===


Some examples in which removing a metapackage would not remove dependencies installed to satisfy the metapackage were teased out[6][7] in conversations between [[JoshBoyer|Josh Boyer]] and Seth and [[JesseKeating|Jesse Keating]].
[[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.  


[[FlorianFesti|Florian Festi]] thought[8] that the list of problems to be solved should be expanded to include how <code>multilib</code> is handled, the proliferation of <code>noarch</code> subpackages and poor implementations of parts of the tool-chain. He also emphasized that with the "increasing number of languages supported and packages being properly translated we ship more and more language dependent content the users are not interested in. We are currently missing both a way to package these contents properly and a mechanism the control which should be actually installed."
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/msg00733.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] http://fedoraproject.org/wiki/FUDCon
<references/>


[3] http://fedoraproject.org/wiki/PackageMaintainers/CompsXml#How_comps_is_used
=== Chrome9 Vx800 Graphics Support on LiveUSB ===


[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00748.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/msg00882.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/msg00751.html
<references/>


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


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


=== New GPG Signing Keys for Each Release ===
<references/>


[[JesseKeating|Jesse Keating]] asked[1] what value <code>Fedora</code> users perceived in the presence of the "[...] two gpg keys per release, one for rawhide/updates-testing and one for the final release and stable updates."
=== Firestarter Retired as Unportable to PolicyKit ===


[[ToddZullinger|Todd Zullinger]] suggested[2] that eschewing the importation of the "updates-testing" key would ensure that "[...] no packages from updates-testing are installed on a box [.]" [[CaseyDahlin|Casey Dahlin]] disliked[3] such a use of keys to categorize things.
[[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>.


Todd asked if each new release would come with a new key, similar to the way this was handled after the infrastructure intrusion. He balanced the sense of confidence given by keeping a key around for a "reasonably long time" versus the mitigation of "the lack of any way to revoke a key in the rpm db [.]" Jesse confirmed[4] "[...] yes, we plan to use new keys each release. We can use gpg web-"-trust thing and sign the new keys with the old keys and whatnot, does that actually help people?j
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/>


[[DouglasWarner|Douglas E. Warner]] and [[SteveGrubb|Steve Grubb]] worried[5] that the inability to revoke keys exposed machines to repository metadata attacks and Steve revealed[6] that the import of keys is "[...] one of the few security sensitive actions that is not put into the audit system."
=== Russian Fedora ? ===


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


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


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


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


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


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


=== libssl.so.7 Going Through a Bumpy Patch ===
<references/>


[[TomasMraz|Tomas Mraz]] advised[1] that he was going to build a new <code>OpenSSL</code> in <code>rawhide</code> which would require a soname bump due to minor breakage of the ABI. As a transitional measure he intended to temporarily provide symlinks to the old soname so that most of the 288 affected packages should continue working until they were rebuilt. [[JesseKeating|Jesse Keating]] expressed[2] disquiet with the timing as the large number of rebuilds would be "[...] likely to break buildroots, break anaconda composes, break installs, break users. This isn't the kind of crap we want to land in rawhide just before a freeze, and just before an effort to turn that freeze into something usable. PLEASE wait until after Alpha has been cut to do this." He seemed slightly mollified[3] by Tomas' use of compatibility symlinks and rpm provides.
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===


When [[BennyAmorsen|Benny Amorsen]] wondered why such breakage was occurring again with <code>openssl</code> Tomas explained[4] that the design "declar[ed] some important structures which have to be changed/extended with new functionality in the public headers. Unless they move these structures to private headers this situation is going to happen again." [[ChristopherAillon|Christopher Aillon]] joked[5] that it was happening again because Benny had not ported his applications to use NSS(see FWN#107[6]).
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."


Later [[HorstvonBrand|Horst von Brand]] reported[7] widespread problems with many packages which seemed to fail. RalfErtzinger explained[8] that "[t]he problem is that the openssl package was supposed to contain symlinks for libssl.so.7 and libcrypto.so.7, and rpm -ql says that the package does contain them, but they are, in fact, missing from the filesystem."
<references/>
 
[[TomasMraz|Tomas Mraz]] scrambled[9][10] to sort out the problem by trying to run <code>ldconfig</code> in the <code>%post</code> of the <code>openssl</code> package. [[KevinKofler|Kevin Kofler]] suggested[11] a possible cause.
 
[[JesseKeating|Jesse Keating]] fretted[12] that all of this was exactly what he did not want just before next week's alpha freeze[13].
 
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00758.html
 
[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00761.html
 
[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00764.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00880.html
 
[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00977.html
 
[6] https://fedoraproject.org/wiki/FWN/Issue107#Crypto_Consolidation
 
[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00941.html
 
[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00942.html
 
[9] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00943.html
 
[10] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00946.html
 
[11] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01051.html
 
[12] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01000.html
 
[13] https://fedoraproject.org/wiki/Releases/11/Schedule
 
=== MinGW Package Reviews Requested===
 
[[RichardJones|Richard W.M. Jones]] noted[1] that the rapid development cycle[2] meant that <code>Fedora 11</code> was already approaching (2009-01-20) alpha-freeze and asked for package reviews of the outstanding parts of the <code>MinGW</code> Windows cross-compiler feature[3]. He offered to trade reviews with interested parties and provided links to outstanding reviews.
 
There is apparently no question that the feature, which will allow generation of Windows targets on Fedora, will slip from Fedora 11.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00793.html
 
[2] https://fedoraproject.org/wiki/Releases/11/Schedule
 
[3] https://fedoraproject.org/wiki/Features/Windows_cross_compiler
 
=== MySQL 5.1 Coming to Rawhide After Alpha-Freeze ===
 
A heads-up was posted[1] by [[TomLane|Tom Lane]] to advise that <code>mysql-5.1.30</code> would be pushed into <code>rawhide</code> immediately after the alpha freeze. He warned: "This involves an ABI break: libmysqlclient.so has increased its major version number from 15 to 16 [...]" and provided a list of affected packages along with the offer to launch rebuilds for anyone who wished.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00721.html
 
=== Spins SIG Controversy ===
 
A vigorous disagreement erupted when [[User:kanarip|Jeroen van Meeuwen]] announced[1] that the Spins SIG[2] would henceforth be having meetings every two weeks (Jeroen later rescheduled[3] the meeting to Mondays at 17:00 UTC) and that the first meeting would be to finalize a new process arrived at during the last FUDCon.
 
[[RahulSundaram|Rahul Sundaram]] contended[4] that "[s]uch decisions shouldn't be taken at FUDCon because it automatically excludes people who cannot be present at the event. You should use the events only to discuss the issues and make the decisions over mailing lists or irc where others can participate as well." A long thread mostly involving just Rahul, Jeroen and [[JoshBoyer|Josh Boyer]] resulted.
 
In response to Rahul's point that the new process was onerous as it mandated a weekly compose and report JoshBoyer seemed[5] to be of the opinion that this was a good thing. BillNottingham added[6]: "It's not really adding anything to the
amount of work that needs to be done, in total. It's just shifting around who it gets done by and when."
 
Some weight was given to Rahul's argument that the method of arriving at the new process was a problem when Jeroen posted[7] that no minutes had been kept of the meeting and pointed to a "5-minute after best-recollection of what happened" summary on the wiki[8] as a source of information.
 
JesseKeating argued[9] that FUDCon was a useful, "high-bandwidth" means of having discussions and that public email was too slow to make decisions compared to IRC, IM, phone and face-to-face meetings. Subsequently he added that the result of the FUDCon discussions was a proposal and not a decision and suggested that unless the skeleton process was approved quickly then there might be no spins for Fedora 11. Rahul responded[10] that the original post had been a simple declaration which did not suggest it was merely a proposal. Rahul added[11] that there was a need to clarify the process in order to avoid the confusion of the past.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00695.html
 
[2] http://fedoraproject.org/wiki/SIGs/Spins
 
[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00782.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00789.html
 
[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00811.html
 
[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00826.html
 
[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00838.html
 
[8] http://fedoraproject.org/wiki/SIGs/Spins_NewProcess
 
[9] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00864.html
 
[10] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00872.html
 
[11] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00874.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"