From Fedora Project Wiki

< FWN‎ | Beats
 
(112 intermediate revisions by 2 users not shown)
Line 5: Line 5:
mailing list are summarized.
mailing list are summarized.


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


=== How Maintainers Can Help Reduce XULRunner Breakage ===
=== Would You Like to Write This Beat ? ===


The recent breakage of many packages which depend on xulrunner (see FWN#136 "XULRunner Security Update Breakage Stimulates Bodhi Discussion"[1]) was addressed[2] in a post by [[WillWoods|Will Woods]]. Will reported that a QA meeting involving [[ChristopherAillon|Christopher Aillon]] (caillon), as <code>Firefox/XULRunner</code> maintainer, had investigated the problem and produced an explanation and some recommendations for other package maintainers. As Christopher was unavailable for a week Will was relaying the information in the hope that some fixes could be made in his absence.
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.


[1] http://fedoraproject.org/wiki/FWN/LatestIssue#XULRunner.Security.Update.Breakage.Stimulates.Bodhi.Discussion
<references/>


[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01682.html
=== Is gNaughty a Hot Babe ? ===


The reason that some xulrunner-dependent packages were affected and others not was that ''xulrunner'' provides both a stable API <code>gecko-devel</code> and an unstable API <code>gecko-devel-unstable</code>. Will noted that <code>BuildRequires</code> of ''xulrunner-devel'' or ''xulrunner-devel-unstable'' should no longer be used and instead that gecko equivalents should replace them.
[[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.  


Packages using the stable API were unaffected by the update of <code>xulrunner</code>. Will stated that "[t]he unstable API could change at any time, so if your app is using the unstable API it must be rebuilt *every time* <code>xulrunner</code> is updated." It was recommended that packages that used the stable API should use the following in their specfiles:<pre>
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?"
Requires: gecko-libs >= 1.9
BuildRequires: gecko-devel >= 1.9
</pre>
and that those using the unstable API should use:
<pre>
%define gecko_ver 1.9.0.1
Requires: gecko-libs = %{gecko_ver}
BuildRequires: gecko-devel-unstable = %{gecko_ver}
</pre>


Lastly an important request was made of package maintainers: "if your package uses the <code>-unstable</code> API, please send caillon redhat com a note, and *please* consider adding him to the ACL (or opening it entirely). He keeps tabs on all packages requiring the unstable API so they can all be rebuilt for each security update."
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.


[[BradenMcDaniel|Braden McDaniel]] wondered[3] why the same headers, but with different pathnames, were provided by <code>xulrunner-devel-unstable</code> and <code>xulrunner-devel</code> and Ville-PekkaVainio had[4] the same question.
<references/>


[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01684.html
=== Chrome9 Vx800 Graphics Support on LiveUSB ===


In response to the suggested BuildRequires [[DouglasWarner|Douglas Warner]] requested[5] that a <code>Provides: gecko-libs-api = 1.9</code> be added to <code>xulrunner</code> so that dependent packages would break if <code>xulrunner</code> were bumped to a new version which was not compatible: "For example, I can't do: <code>Requires: gecko-libs < 2.0</code> Because I'm not guaranteed that the next version will *be* 2.0 (it might be 1.10, for example)." [[RexDieter|Rex Dieter]] independently came[6] to the same conclusion. [[DenisLeroy|Denis Leroy]] begged[7] that <code>xulrunner</code> would use "libtool-style soname versions like all other libraries in Fedora? So we don't need to add the version numbers in the spec file in the first place." Denis thought that <code>xulrunner</code> would fail a standard Fedora package review.
[[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?"


[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01686.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.


=== NEVR Again ===
<references/>


Another report detailing broken upgrade paths was posted[1] by [[JesseKeating|Jesse Keating]]'s script (see FWN#136 "Broken Upgrade Paths Due to NEVR"[2]). This time it reported those packages which failed the path "f8-final -> dist-f8-updates -> dist-f8-updates-testing -> dist-f9-updates -> dist-f9-updates-testing -> dist-f10" and seventy-eight packages were listed. Also included as per last week's discussion was an ordering of the list per-builder as opposed to per-owner. Jesse requested[3] feedback from recipients of the automated email warnings if problems are encountered.
=== Who Wants a Pony? ===


[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01525.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.


[2] http://fedoraproject.org/wiki/FWN/LatestIssue#Broken.Upgrade.Paths.Due.to.NEVR
<references/>


[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01526.html
=== Firestarter Retired as Unportable to PolicyKit ===


[[StephenWarren|Stephen Warren]] was concerned[4] that the upgrade path did not include the GA release of dist-f9: "Shouldn't dist-f9-final (or whatever the correct name is) be inserted in this path list between dist-f8-updates-testing and dist-f9- updates?" This led to an interesting exchange with [[KevinKofler|Kevin Kofler]] who argued[5] that the converse should be expected and it was desirable that updates to Fedora 8 would have higher EVRs than the packages which were released for "dist-f9". Stephen argued[6] that it would make it easier to backport fixes if bumping of the release number rather than the version number were preferred and suggested changing what he understood to be Fedora's policies. KevinKofler disagreed[7] both with Stephen's description of current Fedora practices and also with his desire to reduce version bumps. He listed several situations in which these bumps would be useful and suggested that it was such version upgrades which uniquely distinguished Fedora from Debian "stable" or Red Hat EL.
[[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>.


[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01527.html
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/>


[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01529.html
=== Russian Fedora ? ===


[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01539.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.


[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01553.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]].


The possibility that simultaneous updates would be released to all branches was discussed[8] by [[KevinKofler|Kevin Kofler]] and [[JesseKeating|Jesse Keating]]. Although Jesse thought this was a corner case and that it was best to let the maintainer decide Kevin was motivated[9] to write a patch as it was in his experience a common problem. Kevin thought that if Jesse wanted to avoid spamming maintainers with bogus reports then his patch would remove about thirty-nine percent of the volume. Jesse was grateful and excused[10] himself from looking at the patch for a week due to the pressure of releasing the alpha of Fedora 10.
<references/>


[8] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01572.html
=== Will FESCo Revisit Kmods ? ===


[9] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01574.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]].


[10] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01595.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>.


[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01685.html
<references/>


[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01728.html
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===


[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01708.html
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."


=== Slimming Down Java by Sub-Packaging AOT ===
<references/>
 
A request to separate out the AOT[1] parts of Java packages into sub-packages was made[2] by [[CaolanMcNamara|Caolan McNamara]]. He estimated that it would be possible to remove circa 45 Mb (in /usr/lib/gcj) as OpenJDK tended to be installed anyway due to the web plugin.
 
[1] AOT stands for Ahead-Of-Time. This refers to the static compilation of the program to produce native code which runs without the potential run-time performance hit imposed by JIT. JIT stands for Just-In-Time and refers to dynamic compilation of each method of a Java program immediately before execution. Although there are techniques to speed up JIT, by identifying "hot" frequently called methods and caching them (see http://en.wikipedia.org/wiki/HotSpot), in general it is believed to be sub-optimal for GUI-based programs.
 
[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01763.html
 
[[AndrewHaley|Andrew Haley]] and [[AndrewOverholt|Andrew Overholt]] expressed[3] skepticism that users would realize that they needed the ''gcj'' AOT-compiled code in order to get good performance. [[AndrewOverholt|Andrew Overholt]] stated "one of the reasons we didn't do this to begin with was because RPM has no notion of Suggests or Recommends like dpkg does. Debian went this route, but I've seen reports of people not realizing they needed to install the associated -gcj package."
 
[3] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01769.html
 
The advantages of maintaining both AOT and JIT compilation were argued[4] by [[ColinWalters|Colin Walters]]. Among the reasons listed by Colin for keeping a JIT were: "many apps will continue to load code at runtime from sources that are not Fedora. Think unpackaged Eclipse plugins for just a start" and that "[a] JIT also has a lot more interesting information than a normal AOT model. Hotspot does a lot of cool things there." Colin suggested that "profile driven optimizations",based on work done in 2001 by JanHubicka (SuSE), [[RichardHenderson|Richard Henderson]] (Red Hat) and AndreasJaeger (SuSE), might be a way to improve the performance of JITted programs. On the other hand he recognized that AOT compilation was useful "because having Hotspot re-profile and recompile the Eclipse core on everyone's computer is a bit of a waste." Colin followed up[5] with a putative infrastructure plan involving modifying Koji to create a new repository of optimized versions of select applications and a YUM plugin which feeds HotSpot profile data from individuals back to a central server which in turn is used to further optimize the compilations. [[JeffSpaleta|Jeff Spaleta]] wanted[6] to know if this new repository would be disabled by default. [[ToshioKuratomi|Toshio Kuratomi]] was concerned[7] that Koji should maintain its ability to create a precisely audited build.
 
[4] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01774.html
 
[5] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01775.html
 
[6] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01792.html
 
[7] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01795.html
 
=== Rawhide Network Breakage Due to Wireless Drivers ===
 
A puzzled [[RichardJones|Richard Jones]] asked[1] if anyone else had experienced bizarre networking failures apparently due to DNS lookup failures for web browsers but not for command line tools. Several confirmations were posted and [[DanWilliams | Dan Williams]] warned[2] that "all mac80211-based drivers (b43, b43-legacy, iwl3945, iwl4965, ath5k, rt2x00)" were broken due to upstream patching of multiqueue functionality.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01788.html
 
[2] https://www.redhat.com/archives/fedora-devel-list/2008-July/msg01801.html
 
[[RalfEtzinger | Ralf Etzinger]] asked[3] if failure to associate with an Access Point was one of those expected pieces of "random weirdness." In response to a follow-up question from [[MichaelSolberg|Michael Solberg]] about a failure to associate using ''kernel-2.6.25.10-47.fc8'' Dan added[4] that only Rawhide kernels should be affected.
 
[3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00000.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00008.html
 
=== Possible Slippage of Fedora 10 Alpha? ===
 
A brief note from [[JesseKeating|Jesse Keating]] on Friday requested[1] an IRC meeting with spin owners, QA, Kernel and other concerned parties to discuss the problem that "split media"[2] was not working currently. As the Alpha release is scheduled[3] for August 5th it seems as though there is little time to solve this problem.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00005.html
 
[2] The ability to break a set of RPM packages into media images to be used by <code>anaconda</code> during installation is a difficult one.  Currently it is handled by the <code>pungi</code> module https://hosted.fedoraproject.org/pungi/wiki/PungiDocs/PungiDocs
 
[3] http://fedoraproject.org/wiki/Releases/10/Schedule
 
In an aside Jesse referred to the problem that the "Alphas" are currently hidden away from the general community and that he would like to address this at a subsequent ReleaseEngineering meeting.

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"