From Fedora Project Wiki

< FWN‎ | Beats

 
(35 intermediate revisions by the same user not shown)
Line 2: Line 2:
 
== Developments ==
 
== Developments ==
  
In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.
+
In this section the people, personalities and debates on the @fedora-devel
 +
mailing list are summarized.
  
 
Contributing Writer: [[User:Ush|Oisin Feeley]]
 
Contributing Writer: [[User:Ush|Oisin Feeley]]
  
=== Auto Upgrading YUM Not Worth It ===
+
=== Would You Like to Write This Beat ? ===
  
A discussion over the possible ways to upgrade from Fedora 10 to Fedora 11 was started<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01145.html</ref> by [[GerryReno|Gerry Reno]] when he asked why <code>preupgrade</code><ref>http://fedoraproject.org/wiki/PreUpgrade</ref> from <code>Fedora 10</code> only presented <code>Rawhide</code> as an option and not <code>Fedora 11 Alpha</code>.
+
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.
  
A quick answer posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01147.html</ref> by GianlucaSforna mentioned the technical difficulties of tracking the versions of packages included in the alpha release. [[User:Pfrields|Paul W. Frields]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01168.html</ref> concerned that anyone trying such an upgrade made sure to update <code>rpm</code> before upgrading.  This latter point spawned<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01185.html</ref> a longish thread in which the possibility of making <code>YUM</code> take care of checking to see whether a newer version of itself or <code>rpm</code> is available.
+
<references/>
  
[[User: Wwoods|Will Woods]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01254.html</ref> that running <code>preupgrade</code> isntead of doing a <code>`yum upgrade'</code> avoided all that confusion.
+
=== Is gNaughty a Hot Babe ? ===
  
<references/>  
+
[[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.
  
=== How to Update from Fedora 10 to Rawhide ===
+
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?"
  
When "nodata" reported<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01227.html</ref> that an attempt to update <code>rpm</code> resulted in errors and <code>preupgrade</code> also failed he concluded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01245.html</ref> that the instructions<ref>http://fedoraproject.org/wiki/Fedora_11_Beta_release_notes#RPM_issues</ref> on the wiki were flawed.
+
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.
  
[[User:Skvidal|Seth Vidal]] and [[User:Jkeating|Jesse Keating]] were<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01250.html</ref> sure that "nodata" was not using the correct procedure which they stated as a two stage process with the first step being a:
+
<references/>
<pre>yum update rpm</pre>
 
with the <code>Fedora 10</code> repository enabled and then to enable the <code>Rawhide</code> repository and do a general:
 
<pre>
 
yum update
 
</pre>
 
  
Unfortunately this seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01253.html</ref> to not work for "nodata" and [[MichaelYoung|Michael A. Young's]] suggestion<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01266.html</ref> that a "[...] temporary issue with F10 having a more recent version of audit-libs than rawhide [...]" seemed like a promising lead. "Nodata" resolved<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01231.html</ref> problem by using the rescue CD to do a "<code>rpm -e --nodeps</code>" and then "<code>rpm --rebuilddb</code>".
+
=== Chrome9 Vx800 Graphics Support on LiveUSB ===
 +
 
 +
[[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?"
 +
 
 +
[[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/>
  
=== Fedora 11 Beta Slips by One Week ===
+
=== Who Wants a Pony? ===
  
[[User:Jkeating|Jesse Keating]] announced<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01163.html</ref> that Release Engineering, QA and maintainers had agreed that the beta release of <code>Fedora 11</code> would slip by seven days due to several issues mostly related to the rewrite of <code>anaconda</code> storage.  
+
[[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.
  
<references/>  
+
<references/>
  
=== Finding the Source ===
+
=== Firestarter Retired as Unportable to PolicyKit ===
  
A request was posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01100.html</ref> for help in finding the <code>Fedora</code> kernel sources by [[JoeOvanesian|Joe Ovanesian]]. A quick pointer was given<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01101.html</ref> by [[TomDiehl|Tom Diehl]]:
+
[[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>.
<pre>
 
# yum install yum-utils
 
  
# yumdownloader --source package_name
+
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."
</pre>
+
 +
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/>
 +
 
 +
=== Russian Fedora ? ===
  
[[User:Sandeen|Eric Sandeen]] wondered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01130.html</ref> if it might be better to use the upstream repositories and Joe explained<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01151.html</ref> that his objective was to build a new kernel from source and use KGDB<ref>http://kgdb.linsyssoft.com/</ref> to gain familiarity with the source. [[User:Tmz|Todd Zullinger]] pointed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01154.html</ref> to a goldmine of information on the topic on the wiki<ref>http://fedoraproject.org/wiki/Building_a_custom_kernel</ref>.
+
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.
  
<references/>  
+
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]].
  
=== Fedorahosted Releases ===
+
<references/>
  
[[User:Jstanley|Jon Stanley]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01015.html</ref> a quick note to say that he had made it easier to specify the upstream source URL in specfiles due to a change in fedorahosted.org
+
=== Will FESCo Revisit Kmods ? ===
  
<references/>  
+
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]].
  
=== How to Open ACLs and Find Non-responsive Maintainers ===
+
[[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 couple of related threads dealt with the need to deal with a package which lay dormant apparently due to maintainer inactivity.
+
<references/>
  
[[User:Wolfy|Manuel Wolfshant]] had inquired<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00962.html</ref> earlier in the week about the allowing the provenpackagers to fix the <code>gdal</code> package. [[User:Jstanley|Jon Stanley]] promised<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg01035.html</ref> to re-add a ticket dealing with the issue to an upcoming FESCo meeting.
+
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===
  
In a separate thread the latest Rawhide Report<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01234.html</ref> led [[User:Kkofler|Kevin Kofler]] to ask<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01268.html</ref> for an opening of the ACLs on <code>gdal</code><ref>GDAL is a library to handle Geographic Information Systems data</ref> so that it could be fixed for multiple dependent packages. When [[User:Jkeating|Jesse Keating]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01296.html</ref> [[User:Alexlan|Alex Lancaster]] if he started the non-responsive maintainer process the answer appeared<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01301.html</ref> to be that it was Jesse himself. In an aside MilosJakubicek provided<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01298.html</ref> links to the current process. Alex seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01303.html</ref> to demonstrate clearly that the maintainer was inactive.
+
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."