From Fedora Project Wiki

< FWN‎ | Beats

 
(23 intermediate revisions by the same user not shown)
Line 7: Line 7:
Contributing Writer: [[User:Ush|Oisin Feeley]]
Contributing Writer: [[User:Ush|Oisin Feeley]]


=== Frozen for Fedora 11. Some Packages Still Not Built dist-f11 ===
=== Would You Like to Write This Beat ? ===


[[User:Jkeating|Jesse Keating]] announced<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00892.html</ref> that henceforth all F-11/ builds would go to dist-f11-updates-candidate and builds from devel/ would go to dist-f12. He asked for concerned parties to check that builds were being properly tagged.
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.
 
In response to [[User:Miketc302|Mike Chambers]]' question Jesse confirmed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00954.html</ref> that the nightly rawhide composes would consist of <code>Fedora 11</code> content until the GOLD packages were on their way out to the mirrors at which point the nightly rawhide composes would contain <code>Fedora 12</code> content.
 
On a related note [[User:Notting|Bill Nottingham]] asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01160.html</ref> maintainers of a list of packages not yet rebuilt in dist-f11 (with the attendant compiler and strong RPM hashes) to fix them if possible. [[User:Jkeating|Jesse Keating]] provided<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01189.html</ref> a slightly more aggressive list as an addendum.


<references/>
<references/>
=== Xorg Hacking Solves DontZap ===


[[PeterHutterer|Peter Hutterer]] made some valuable contributions to resolving the furore over the disabling of the zapping of the Xorg server via the Ctrl-Alt-Backspace key combination<ref>http://fedoraproject.org/wiki/FWN/Issue171#Zap_DontZap</ref>.
=== Is gNaughty a Hot Babe ? ===


[[User:Spot|Tom Callaway]] drew attention<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00700.html</ref> to a blog entry of Peter's which mentioned upstream patches by Julien Cristau (of Debian) to <code>xkeyboard-config</code> and Peter's own patch<ref>http://lists.freedesktop.org/archives/xorg-devel/2009-April/000626.html</ref> to <code>Xserver</code> which together make it possible to disallow zapping by default and also to turn zapping on with a <pre>'setxkbmap -option terminate:ctrl_alt_bksp'</pre>. The net result is that it is possible to get zapping to work but the <code>XKB</code><ref>http://www.charvolant.org/~doug/xkb/html/index.html</ref> configuration needs to be set up properly and the DontZap option left disabled (as per the new default).  
[[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.  


In discussion with [[User:Kkofler|Kevin Kofler]] Peter clarified<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00861.html</ref> the situation in which the new settings would take effect. Kevin responded<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00863.html</ref> that it appeared that for <code>KDE</code> users zapping with Ctrl-Alt-BkSp would remain as before.  
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?"


Later Peter answered<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00838.html</ref> some questions from [[User:Surenkarapetyan|Suren Karapetyan]] about the ability to kill broken X grabs with details about how zapping works.
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 above summary of an elegant technical solution ignores the long, and at times vitriolic, complaints about this change. A common trope occurring in some recent threads seems to be that changes are made by Red Hat employees who are implementing changes without community consultation and all work to a common game plan. [[User:Skvidal|Seth Vidal]] challenged<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01059.html</ref> the latter assumption:"In a survey of 10 RH employees you will find between 10 and 40 different opinions. sometimes more if you don't ask some of them to confine their comments to a limited amount of time."  In any event it's worth noting that the resolution (which filters the "Terminate_Server" action in a manner consistent<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01173.html</ref> with the handling of other actions in xkb rulesets) was contributed upstream by a Red Hat employee. As a point of information [[User:Kevin |Kevin Fenzi]] also made it clear that the change had not been instigated by FESCo.


<references/>
<references/>


=== Minesweeper Certified Solitaire Professionals Satisfied with DVD ===
=== Chrome9 Vx800 Graphics Support on LiveUSB ===


[[User:Jkeating|Jesse Keating]] requested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00943.html</ref> help in selecting which packages should be dropped from the DVD image. He suggested some java development packages and games.
[[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?"


Feedback suggested that retaining the games was<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00947.html</ref> preferred and dropping the development libraries made sense as the latest versions would be needed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00981.html</ref> and could be obtained from the repositories anyway. Jesse later posted<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01037.html</ref> this was sufficient to achieve the desired image size.
[[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.  
 
A side-issue discussed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01019.html</ref> was the unwieldiness of <code>jigdo</code> as a download method. [[CallumLerwick|Callum Lerwick]] suggested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01246.html</ref> that <code>jigdo</code> would benefit from a userspace ISO implementation.


<references/>
<references/>


=== Presto and DeltaRPM Status ===
=== Who Wants a Pony? ===


The ability to download binary diffs of RPM packages has been offered<ref>http://fedoraproject.org/wiki/FWN/Issue97#Presto-digitation</ref> for some time now on Fedora through the <code>Presto</code><ref>https://fedorahosted.org/presto/</ref> project and presto-enabled repositories. Interest is high enough in Presto's bandwidth-saving abilities that no fewer than three separate threads were started to ensure that it would function properly for <code>Fedora 11</code>.
[[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.


[[WarrenTogami|Warren Togami]] asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00701.html</ref> if <code>Presto</code> would be enabled by default for <code>Fedora 11</code>. Last month (2009-03-21) [[User:Jdieter|Jonathan Dieter]] reported<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg01910.html</ref> that the use of <code>SHA-256</code> in <code>rpm</code> had broken <code>deltarpm</code> but that a patched version was available in rawhide. See FWN#166<ref>http://fedoraproject.org/wiki/FWN/Issue166</ref> for earlier coverage of the challenges and changes resulting from the introduction of stronger hashes<ref>http://fedoraproject.org/wiki/Features/StrongerHashes</ref>. 
<references/>
Jonathan also reported that the changes necessary in infrastructure to build deltarpms had been done. These changes were made fairly rapidly thanks to work done<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00528.html</ref> Michael Schroeder, the upstream <code>deltarpm</code> developer. One issue that concerned<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01236.html</ref> [[User:Athimm|Axel Thimm]] was the security with which checksums of deltarpms were being made. [[User:Till|Till Maas]] and [[User:Jdieter|Jonathan Dieter]] provided<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01240.html</ref> reassurance that all deltarpms are generated from original rpms which needed to pass all verifications which <code>yum</code> and <code>rpm</code> enforce.   


[[User:Mso|Martin Sourada]] was excited<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01262.html</ref> not just about <code>Presto</code> but also about the slick new <code>PackageKit</code> in <code>Fedora 11</code>. Martin was concerned about the issue of <code>PackageKit</code> and <code>Presto</code> apparently not working well together. A bugzilla entry revealed<ref>https://bugzilla.redhat.com/show_bug.cgi?id=496445</ref> that <code>PackageKit</code> developer [[User:|Richard Hughes]] quickly created a patch which Martin reported as working.
=== Firestarter Retired as Unportable to PolicyKit ===


On 2009-04-16 [[User:Notting|Bill Nottingham]] added to the "Rawhide Report" that "[...] rawhide is composed with deltarpms against the prior rawhide. Due to a bug, this is only currently working on i386; it should be fixed for other arches tomorrow. Please test and report any issues."
[[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>.
 
A Fedora Test Day centering around Presto was also announced<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00939.html</ref> by [[User:|James Laska]]. The usual excellent wikipage<ref>https://fedoraproject.org/wiki/Test_Day:Presto_2009-04-16</ref> suggests that <code>Presto</code> can deliver significant bandwidth savings.


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


=== Browser Plugins May Strip SELinux Protections ===
=== Russian Fedora ? ===
 
[[DanielWalsh|Daniel Walsh]] asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01107.html</ref> why <code>mozplugger</code><ref>Mozplugger describes itself as "[a] general purpose Mozilla plugin module that allows the user to embed and launch their favorite application to handle the various different types of media found on the Internet." http://mozplugger.mozdev.org/</ref> was being installed by default. He cautioned that <code>mozplugger</code> broke <code>nsplugin</code> and thus <code>SELinux</code> functionality.
 
An answer posted<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01111.html</ref> by [[User:Notting|Bill Nottingham]] pointed out the java plugin as the dependent.
 
Dan worried that while "[a] confined nsplugin is a nice feature for confining plugins downloaded from the network. But if you run openoffice and evince from within nsplugin they get confined, causing the apps to not work properly." In response to [[User:Simo|Simo Sorce]] Dan explained that any attempt to write transition rules to enable said applications to work properly would create an easy avenue of attack. Simo wondered<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01115.html</ref> if it would be possible to either write a security wrapper to restrict the command line, or to get application developers to honor SELinux labels in some way.


[[WarrenTogami|Warren Togami]] shared<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01117.html</ref> that removing <code>mozplugger</code> was "[...] something I always do. It seems to cause more problems than it solves [...]" and [[JamesMorris|James Morris]] expanded<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01226.html</ref> upon this with instructions "[...] on both removing mozplugger and restoring the security protections of SELinux.  Simply removing the package isn't enough[.]" James questioned "[...] how a package which breaks a security feature not only made it into the repo, but how it became enabled by default[?]"
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.


A similar issue was raised<ref>https://bugzilla.redhat.com/show_bug.cgi?id=491543</ref> by [[User:Bruno|Bruno Wolff III]] about the re-enabling of disabled ''Firefox'' plugins. Comments by [[MartinStransky|Martin Stransky]] suggest this is a feature of <code>mozilla-plugin-config</code>.
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]].


<references/>
<references/>


=== Getting Rid of /usr for Fedora 12 ? ===
=== Will FESCo Revisit Kmods ? ===


[[LennartPoettering|Lennart Poettering]] cheerfully invited<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01063.html</ref> any inclined parties to a flamefest over the elimination of the /usr directory. Lennart suggested that recent history indicated that more files were being moved from /usr to / and that confusion between the two was a source of error from some packages.
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]].


Enthusiasm for both the flamewar and the proposal was low.
[[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>.


A forceful and well-argued objection was made<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01064.html</ref><ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01076.html</ref> by [[KonstantinRyabitsev|Konstantin Ryabitsev]] on the basis that he liked to keep /boot and /usr on their own partitions and use a LUKS-encrypted LVM for everything else. Konstantin emphasized this was especially well-suited to portable machines which need to conserve power and are more likely to need encryption.
<references/>
 
[[RalfCorsepius|Ralf Corsepius]] invoked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01077.html</ref> the FHS<ref>http://www.pathname.com/fhs/</ref> on /usr and the need to contain<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01105.html</ref> non-essential packages unavailable at certain boot stages therein. [[ChrisAdams|Chris Adams]] added<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01101.html</ref> that symlinking /usr to / had been shown to break <code>rpm</code>.


Lennart explained<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01198.html</ref> how /etc could be made read-only and adduced<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01208.html</ref> OpenSUSE, Debian and Gentoo as further evidence that a read-only root could be attained. [[CallumLerwick|Callum Lerwick]] pined<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01300.html</ref> for the days of floppy disks.
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===


[[User:Toshio|Toshio Kuratomi]] completely declined to play and asked: "I'm hereby giving notice that I don't have time to read obvious flamefests anymore. Once this thread concludes, please summarize whatever the pros and cons are and send it to the packaging committee to discuss and vote on."
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/>
<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.

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.

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.

Who Wants a Pony?

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

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.

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.

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.

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."