From Fedora Project Wiki

< FWN‎ | Beats

(s/https/http)
 
(63 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]]


=== Would You Like to Write This Beat ? ===


=== Fedora 11 Alpha May Be Delayed ===
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.
 
[[User:jkeating|Jesse Keating]] reported<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02394.html</ref> that the <code>Fedora 11 Alpha</code> release date might slip due to some <code>anaconda</code> bugs which manifested themselves late in his testing on some architectures. A later post suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02395.html</ref> that installation using <code>NFS</code> was broken and that "[t]his likely means a slip, perhaps only a two day slip, of Alpha." More info to come either later this weekend or early next week. A bugzilla comment<ref>https://bugzilla.redhat.com/show.bug.cgi?id=483375#c2</ref> from [[WarrenTogami|Warren Togami]] on a side-effect of trying to fix this problem by reverting to an earlier <code>nfs-utils</code> version warned "People should be aware that NFS as a server in F11 Alpha is broken. That is all." As of going to press on 2009-02-01 there was no further information available.


<references/>
<references/>


=== GCC: Default ISA Flags and Glibc===
=== Is gNaughty a Hot Babe ? ===


[[JakubJelinek|Jakub Jelinek]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01661.html</ref> whether the minimum CPU which would run code compiled by Fedora 11's <code>GCC</code> should be re-evaluated. A follow-on question was whether the minimum supported kernel version in <code>glibc</code> could be bumped to <code>2.6.29</code>. Jakub held out the promise of potentially increased speed and decreased shared library sizes.
[[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.  


A problem raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01668.html</ref> by [[KevinKofler|Kevin Kofler]] was that <code>mock</code> builds would no longer be able to run on older <code>Fedora</code> releases and that some VPSs would not be able to upgrade at all. [[GerdHoffman|Gerd Hoffman]] agreed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01813.html</ref>: "We just can't make the huge jump from .9 to .29. We have to do it smaller steps, considering kernel versions at least in supported Fedora versions, maybe also latest RHEL."
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?"  


[[JoshBoyer|Josh Boyer]] seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01680.html</ref> to believe that the required mass rebuild with GCC-4.4 would be difficult but possible. [[MikeMcGrath|Mike McGrath]] outlined<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01696.html</ref> the amount of work which would be needed.
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.
 
See this same FWN#161 "Dropping Support for i586 Architecture" for a related discussion.


<references/>
<references/>


=== RPM Packagers: Too Many Unowned Directories ===
=== Chrome9 Vx800 Graphics Support on LiveUSB ===


[[MichaelSchwendt|Michael Schwendt]] raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02326.html</ref> the problem of unowned directories installed as a result of packagers unfamiliar with "how to include files vs. directories in RPM package %files lists."
[[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?"


[[ColinWalters|Colin Walters]] remembered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02335.html</ref> discussions which had suggested that if <code>RPM</code> were able to reference count directories there could be a technological fix. Separately [[RichardJones|Richard W.M. Jones]] made<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02400.html</ref> a similar argument. [[PanuMatilainen|Panu Matilainen]] seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02350.html</ref> willing to move this task to the top of his queue if it were sufficiently important.
[[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.  


<references/>
<references/>


=== Lack of Update Information ===
=== Who Wants a Pony? ===


A can of worms was opened<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01643.html</ref> by [[RahulSundaram|Rahul Sundaram]] when he noticed that the update information provided by package maintainers was often unhelpful. He cited generic messages of the form "Update foo to upstream x.y.z" as a common problem and wondered if guidelines could improve the situation.
[[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.


Following some questions Rahul expanded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01648.html</ref> on the problem pointing out that package maintainers had the knowledge to tersely explain what upstream changes implied for ordinary users. He emphasized that he was concerned with the "description that is part of bodhi update and not the changelog which can be very brief."
<references/>
 
[[ChrisWeyl|Chris Weyl]] put<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01742.html</ref> forward the counter-argument that package maintainers had a difficult enough life already.


[[RichardJones|Richard W.M. Jones]] wondered<ref>htts://www.redhat.com/archives/fedora-devel-list/2009-January/msg01687.html</ref> if <code>rpm</code> could be altered to allow it to reference upstream changelogs which could be pulled out by other tools. [[PanuMatilainen|Panu Matilainen]] averred<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01703.html</ref> that while rpm was alterable Richard's proposed change would just dump the information into the rpm payload and it would thus not be available to users until after they had installed it. Further brainstorming seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01737.html</ref> to run into various practical dead ends.
=== Firestarter Retired as Unportable to PolicyKit ===


Subsequently Rahul published<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01842.html</ref> a draft guideline which fanned the flames back to life. ThorstenLeemhuis asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01845.html</ref> "Don't we have way [too] many guidelines and policies already? [...] Note that I don't disagree with the text that was proposed. My 2 cent: Put it as text into the wiki somewhere, write "best practices" on top of it (avoid the words "rules" and "guidelines") and add a link to the bodhi UI ("best practices for filling this box with information")." Rahul appeared to agree that this was the best course for the present and deferred to FESCo for the ultimate decision.
[[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>.


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


=== Electronic Design Automation Content Without Tools ? ===
=== Russian Fedora ? ===


[[ChitleshGoorah|Chitlesh Goorah]] redirected<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02364.html</ref> a debate on Electronic Design Automation (EDA)<ref>http://en.wikipedia.org/wiki/Electronic_design_automation</ref> tools from FESCo to @fedora-devel. Chitlesh is the prime mover behind the <code>Fedora Electronic Lab Spin</code><ref>http://chitlesh.fedorapeople.org/FEL/</ref>. He was concerned that FESCo had decided that packages in the OVM<ref>http://www.ovmworld.org/overview.php</ref> format were barred from Fedora on the grounds that there was no FLOSS tool which could use them although they were licensed acceptably.
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.


[[JeffSpaleta|Jef Spaleta]] explained<ref>htts://www.redhat.com/archives/fedora-devel-list/2009-January/msg02369.html</ref> that there were subtle problems in the discussion as "[OVM] is code of some sort. The problem is we don't have a compiler or interpreter that can process the instructions. In the context of Fedora its code that can't be used." [[KevinKofler|Kevin Kofler]] supplied<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02377.html</ref> the appropriate guideline.
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]].
 
[[KevinFenzi|Kevin Fenzi]] expressed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02470.html</ref> appreciation for Chitlesh's work on the Fedora Electronics Lab and asked if there was any use for OVM besides hooking it up with a non-Free simulator? [[ManuelWolfshant|Manuel Wolfshant]] argued<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02480.html</ref> that OVM was i[...] interesting for a subset of the people interested in EDA" and that it should be provided for them. [[HorstvonBrand|Horst von Brand]] disliked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02489.html</ref> the idea of mirrors carrying such a little-used package around and suggested that Manuel could just set up his own repository.


<references/>
<references/>


=== Dropping Support for i586 Architecture ? ===
=== Will FESCo Revisit Kmods ? ===


Following FESCo discussions<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02328.html</ref>[[BillNottingham|Bill Nottingham]] reported<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02345.html</ref> that the supported architecture list was going to change. Important changes include building binaries only for i686 and above. There are concerns that older thin clients based on i586 hardware and the AMD Geode-based XO laptops may then be unsupported or unstable. Bill characterized the discussions as a follow-up to the compiler flag discussions (see this same FWN#161"GCC: Default ISA Flags and Glibc") and summarized the main points as:
A discussion of why <code>VirtualBox</code> will not be a feature due to its code not yet heading upstream and consequently remaining as <code>kmods</code> drew a statement of support from [[User:Kkofler|Kevin Kofler]] for reverting the current banning of <code>kmods</code> should he become a FESCo member. Upon request from [[RichardJones|Richard W.M. Jones]] for a dispassionate summary of the reasons to avoid <code>kmods</code> drew<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02254.html</ref> a concise response from [[User:Skvidal|Seth Vidal]].


<pre>
[[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>.
- install x86.64 kernel on 32-bit OS where appropriate
- install PAE kernel on other 32-bit OS installs where appropriate
- build only i686 and above for Fedora
</pre>
 
[[JeremyKatz|Jeremy Katz]] added<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02382.html</ref> anecdotal reassurance that the XO should probably be fine with the i686 kernel and glibc.
 
[[RobertScheck|Robert Scheck]] wondered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02355.html</ref> what the definition of "where appropriate" was and what mechanism would be used to make this determination.
 
[[DominikMierzejewski|Dominik 'Rathann' Mierzejewski]] predicted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02378.html</ref> "[t]here's going to be some screaming from VIA C3 and AMD K6 users about this." His suggestion was true during an older similar discussion (see FWN#93<ref>http://fedoraproject.org/wiki/FWN/Issue93#No_More_586_Kernels</ref>) in 2007 which concerned plans to drop shipping an i586 kernel. Suggested attempts to compensate by making the i686 kernel bootable on i586 architectures were thwarted as rpm balked at installing a kernel which violated its architecture check. [[AlanCox|Alan Cox]] was one of the strongest objectors to the possibility of thus losing support for i586 as he had many thin clients using that architecture. Doubt was cast during that thread as to whether the smolt statistics were believable. However, Alan has recently become an Intel employee (following other ex-Red Hat luminaries [[DavidWoodhouse|David Woodhouse]] and [[ArjanvandeVen)|Arjan van de Ven]]) and did not contribute to the thread. The <code>smolt</code> statistics listed<ref>http://fedoraproject.org/wiki/Features/ArchitectureSupport#What_about_the_i586_users_3F</ref> on the feature page suggest that there are only 130 i586 users.
 
[[JoshBoyer|Josh Boyer]] clarified<ref>htts://www.redhat.com/archives/fedora-devel-list/2009-January/msg02383.html</ref> that no decision had yet been made by FESCo and that a vote would take place next week.


<references/>
<references/>


=== Blinking Cursor Wastes Power ===
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===
 
[[MatthewGarret|Matthew Garrett]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02265.html</ref> for comments on the idea that the cursor should default to not blinking. The rationale was that several less Watts of power would be consumed. 
 
The suggestion seemed generally popular but [[DominikMierzejewski|Dominik `Rathann' Mierzejewski]] wished to retain the blinking cursor and expressed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02309.html</ref> a desire for more information on the methodology which Matthew had used. [[BillNottingham|Bill Nottingham]] reminded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02320.html</ref> that it would still be possible to turn the cursor back on from this new default. Matthew provided<ref>https://www.redhat.com/archives/fedora-devel-list/2009-January/msg02387.html</ref> some of the requested details.


[[MatthiasClasen|Matthias Clasen]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02268.html</ref> changing a <code>GTK</code> setting which disables cursor blinking after a timeout. [[JoshBoyer|Josh Boyer]] worried<ref>http://www.redhat.com/archives/fedora-devel-list/2009-January/msg02287.html</ref> about other desktop environments and vttys.
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.

  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"