From Fedora Project Wiki

< FWN‎ | Beats

(→‎Fedora Geo Spin: expand acronym OSM with wikipedia link)
 
(65 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]]


=== Fedora 11 Alpha Release Activities ===
=== Would You Like to Write This Beat ? ===


There was a flurry of activity related to the <code>Fedora 11 Alpha</code> release (scheduled[1] for 2009-02-03). [[DenisLeroy|Denis Leroy]] inquired[2] on 2009-01-21 what had happened to the freeze, originally scheduled for the previous day, and whether all builds in rawhide were queued until after the freeze. [[MamoruTasaka|Mamoru Tasaka]] responded[3] with a link to [[JesseKeating|Jesse Keating's]] explanation[4] that the freeze is a non-blocking freeze which allows targeted fixes to be made. [[TomLane|Tom Lane]] wanted[5] an "all-clear signal that the alpha tag has been made and we can go back to breaking rawhide ;-)" Jesse created [6] the <code>alpha tag</code> and apologized for slacking on it. He suggested that if many dependencies were going to be broken by Tom's <code>mysql-5.1</code> push that Tom should ask for a <code>koji</code> tag specifically to land it and build all the deps for it before moving it into <code>rawhide</code> itself.[[JoshBoyer|Josh Boyer]] demonstrated[7] how the <code>Koji</code> command-line can be used to answer queries about what tags are present:
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.


<pre>
<references/>
$koji list-tags -- grep f11-alpha
$koji list-tag-inheritance f11-alpha
</pre>


[[RahulSundaram|Rahul Sundaram]] requested[8] that knowledgeable folks would help build the Release Notes[9] for <code>Fedora 11</code> by adding relevant information to the wiki.  After Rahul got the ball rolling, with some information on the use of <code>ext4</code> as the default filesystem, the experimental provision of the <code>btrfs</code> filesystem and more, [[RichardJones|Richard W.M. Jones]] added information on the <code>MinGW</code> windows cross-compiler and [[Uer:Tmz|Todd Zullinger]] added information about <code>git-1.6</code>.
=== Is gNaughty a Hot Babe ? ===


The 2009-01-23 Rawhide Report[10] contained some large lists of broken dependencies which were pounced on by the respective developers. As the majority were due to the new <code>MySQL</code> mentioned above [[JesseKeating|Jesse Keating]] asked[11] why his advice to use a special tag had been ignored. [[TomLane|Tom Lane]] replied that there had been no objections when he mooted the idea a week ago and that a non-standard tag would cause more work for affected developers than the current rebuilds. Jesse re-iterated[12] his request to "[p]lease consider using it in the future if you're going to break such a wide array of packages."
[[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.  


[[RichardJones|Richard W.M. Jones]] reported[13] problems using <code>yum</code> on <code>Rawhide</code>. [[TomLondon|Tom London]] suggested and [[RichardJones|Richard W.M. Jones]] confirmed[14] that reverting to <code>sqlite-3.6.7-1.fc11.x86.64</code> fixed the problems. It transpired[15] that there was indeed an <code>SQLite</code> bug which was quickly fixed by [[PanuMatilainen|Panu Matilainen]].
One interesting point is that CMUCL<ref>One of the Common Lisp implementations: http://www.cons.org/cmucl/</ref> was revealed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02088.html</ref> to be only available for 32-bit systems. However what got people really excited was<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02136.html</ref> Rahul's question about what to do concerning the <code>gNaughty</code> package. Its sole purpose seemed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02203.html</ref> to be downloading pornography. Rahul referenced the <code>hot-babe</code> CPU monitor which enjoyed controversy in Debian packaging circles due to its use of female nudity.  Rahul wanted to find out "[...] is this allowed in Fedora?"


[1] https://fedoraproject.org/wiki/Releases/11/Schedule
Amusingly a good deal of the controversy focused on whether the content was freely redistributable, but a predictable moral angle was raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02242.html</ref> by [[User:Alsadi|Muayyad AlSadi]] who asked for help in producing a spin which removed content deemed objectionable. Muayyad is a Jordanian developer who has been producing an Arabic-localized Fedora spin named "Ojuba" for some time. Muayyad sought a way to make identifying and tagging packages easier to facilitate this spin. [[User:Notting|Bill Nottingham]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02312.html</ref> skeptical about the chances of tags keeping meaning unless there was some sort of review board. Equally predictable was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02295.html</ref> the reaction typified by [[User:Skvidal|Seth Vidal]] which resisted any attempt to restrict packages according to standards which had nothing to do with licensing or patent issues. [[User:bochcecha|Mathieu Bridon]] thought<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02355.html</ref> that the creation of a wiki-page by Muayyad would allow anyone interested in co-ordinating work on "Inappropriate Content" to just go ahead and do it without dragging in bureaucracy. 


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


[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01276.html
=== Chrome9 Vx800 Graphics Support on LiveUSB ===


[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00664.html
[[KristapsViesalgs|Kristaps Viesalgs]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02146.html</ref> for help in getting the Fedora Live USB to boot correctly on a machine using a Via Vx800 "Chrome9" GPU. Kristaps had some success with the latest upstream version (from their subversion repository) and asked: "Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility?"


[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01298.html
[[User:Ajax|Adam Jackson]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02154.html</ref> for a more specific bug report because the chip should be supported. He preferred not to ship an autoconfiguration utility instead of just getting the driver correct. Similar points were made by [[User:Adamwill|Adam Williamson]] and [[User:|Xavier Bachelot]]. The latter asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02163.html</ref> any interested developers to help out the openchrome project in both the 2D and 3D(Gallium) sides.


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


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


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


[9] https://fedoraproject.org/wiki/Fedora_11_Alpha_release_notes
<references/>


[10] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01510.html
=== Firestarter Retired as Unportable to PolicyKit ===


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


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


[13] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01464.html
=== Russian Fedora ? ===


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


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


=== Minimalist Root Login to X ? ===
<references/>


[[WarrenTogami|Warren Togami]] suggested[1] "mak[ing] root logins from GDM a stripped down desktop with only a terminal and a menu with only configuration tools [and making the desktop] ugly and with a very obvious note explaining why [users] shouldn't be logged in as root."
=== Will FESCo Revisit Kmods ? ===


"Nodata" was among those who wondered[2] if Warren's use cases "[...] where /home filesystem is full and logins fail, or /home is remote and inaccessible[...]" were anything other than odd edge cases. [[JefSpaleta|Jeff Spaleta]] and [[ChrisAdams|Chris Adams]] expanded[3] upon this line of thought: "[...] if /home is full, can users really not log in? If that is the case, that's broke and should be fixed. The user should be able to log in and remove files."
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]].


The impetus for this discussion may have been another thread which asserted that the denial of root login via <code>GDM</code> on <code>Fedora 10</code> systems made it too difficult to maintain said systems. The thread yielded[4] good examples by [[JudCraft|Jud Craft]] and [[DaveAirlie|Dave Airlie]][5] of arguments that such modifications merely penalized experienced users and failed to enhance security as the users could just login as root on the console anyway. As an aside [[BenjaminLaHaise|Benjamin LaHaise]] brought up the issue that <code>Ctrl+Alt+F2</code> no longer worked. DanHorák explained[6] that "F2-6 are blocked when you have getty running on vt1 (/etc/event.d/tty1 is the same tty[2-6]) and Xorg server runs on vt1 too (gdm runs with --force-active-vt) Then there are messages like `unable to switch vt' in /var/log/Xorg.log. [Such behavior] requires manual editing of at least /etc/event.d/tty1, it should not happen in default setups." [[NicholasMailhot|Nicolas Mailhot]] suggested[7] an imperfect upgrade as another possible cause. A further nugget of information revealed in the thread was as <code>Fedora 10</code> had implemented <code>hiddenmenu</code> as a default in grub it was best to hold down any key once the <code>BIOS</code> had finished the <code>POST</code> routine. [[JesseKeating|Jesse Keating]] suggested[8] the <code>shift</code> key as it typically had no bindings either in <code>BIOS</code> or <code>grub</code>. [[AndrewHaley|Andrew Haley]] pointed out[9] that many of the recent changes were breaking established use patterns. [[KevinKofler|Kevin Kofler]] and [[ChristopherWickert|Christopher Wickert]] suggested[10][11] that anyone who wished to revert to the previous status should just edit <code>/etc/pam.d/gdm</code> to comment out
[[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>.
<pre>
auth required pam_succeed_if.so user != root quiet
</pre>


Back in the later thread which sought to deal with some of the difficulties raised above [[TomCallaway|Tom `spot' Callaway]] suggested: "A `Rescue Mode' in GDM which goes to a root session with minimal apps, marked as "Rescue Mode", rather than a root X login (even though it does need root credentials)." [[LyosGeminiNorezel|Lyos Gemini Norezel]] preferred[12] that "[...] the root login should use the user selected interface (gnome, kde, xfce, etc)" but [[MatthewWoehlke|Matthew Woehlke]] emphasized[13] the maintenance benefits of choosing a single Desktop Environment and forcing that as the safe root login.
<references/>


Variations on this topic have been covered previously in FWN#133[14] and FWN#103[15]
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===


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


[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01542.html
<references/>
 
[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01547.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01300.html
 
[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01335.html
 
[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01399.html
 
[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01398.html
 
[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01455.html
 
[9] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01408.html
 
[10] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01278.html
 
[11] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01291.html
 
[12] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01493.html
 
[13] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01495.html
 
[14] http://fedoraproject.org/wiki/FWN/Issue133#Running_As_Root
 
[15] http://fedoraproject.org/wiki/FWN/Issue103#Root_Login_And_Display_Managers_In_Rawhide
 
=== Fedora Geo Spin for USB Key and LiveCD ===
 
[[YaakovNemoy|Yaakov Nemoy]] announced[1] a "[...] respin of Fedora with packages for doing OSM[0] and cartography installed out of the box, or included on a LiveCD and/or LiveUSB. For OSM people, the primary advantage is a live usb stick that can be used at mapping parties to save time cono/guring user computers to do mapping. The USB stick can then be brought home, and the user can continue doing mapping there."
 
[0] Open Street Mapping http://en.wikipedia.org/wiki/OpenStreetMap
 
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01155.html
 
=== Draft Guidelines for Approving provenpackagers ===
 
[[JesseKeating|Jesse Keating]] drafted[1] a definition of `provenpackager' (see FWN#151[2)]. [[AlexLancaster|Alex Lancaster]] was worried[3] that too many hoops would mean that maintainers such as himself would lose motivation to continue their work.
 
As a subsidiary concern Alex was worried that there were still some packages not being opened up. KevinKofler assured Alex that he would become a `provenpackager' based up his sterling work and Jesse confirmed[4][5] that this redefinition and re-seeding of the `provenpackager' group was in part to address such concerns.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01573.html
 
[2] http://fedoraproject.org/wiki/FWN/Issue151#Security_Exceptions_to_the_Mass_ACL_Opening
 
[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01620.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01629.html
 
[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01628.html
 
=== Cloning of Bug Reports ? ===
 
[[User:Johannbg|Jóhann B. Guðmundsson]] asked[1] for input, in the form of suggestions and votes, as to whether Bug Hunters (which later seemed to mean testers, but not triagers) should file a separate bug entry for each of: past supported release, current release and rawhide or just annotate a bug for one of the former with a note that it was present in the others.
 
There was general agreement that mailing list votes were ineffective and
unwanted.
 
[[KevinKofler|Kevin Kofler]] objected[2] to the tack taken by Jóhann which seemed to assume an authority over a decision which would affect not just QA, testing and triage teams but also packagers and maintainers. It appeared[3] that the matter would be elevated to FESCo for a decision but as of going to press this had not happened.
 
[[MarkMcLoughlin|Mark McLoughlin]] suggested[4] a more flexible policy and warned that "[...] you can be sure you'll have maintainers who haven't read or replied to this thread waking up and getting annoyed that they've 3x bug reports to deal with :-)"
 
[[JesseKeating|Jesse Keating]] argued[5] that the multiple bug-entry option was preferable on four heads: 1) that bugs may have different causes in their releases; 2) users of past releases will not be helped by closing bugs on rawhide; 3) bodhi updates are not pushed at the same time; 4) maintainers are the only people with the knowledge to make such a call.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/thread.html#01497
 
[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01423.html
 
[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01490.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01442.html
 
[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01342.html

Latest revision as of 01:15, 1 June 2009

Developments

In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.

Contributing Writer: Oisin Feeley

Would You Like to Write This Beat ?

Following this issue (FWN#178) I will, with regret, no longer be covering the @fedora-devel list. If you are interested in writing this weekly summary of the deeds and doings on the list then please contact fedora-news-list@redhat.com or Pascal Calarco. A short overview of what you may need to do can be obtained by reading the workflow[1] section of the wiki. The @fedora-news list is also extremely open and helpful. Joining[2] the News Project is quite straightforward.

  1. ↑ http://fedoraproject.org/wiki/FWN/WorkFlow
  2. ↑ http://fedoraproject.org/wiki/FWN/NewsProject/Join

Is gNaughty a Hot Babe ?

Rahul Sundaram posted[1] the results of a survey conducted, primarily on @fedora-list and on the forums, to discover which non-repository-packaged software Fedora consumers were using.

One interesting point is that CMUCL[2] was revealed[3] to be only available for 32-bit systems. However what got people really excited was[4] Rahul's question about what to do concerning the gNaughty package. Its sole purpose seemed[5] to be downloading pornography. Rahul referenced the hot-babe CPU monitor which enjoyed controversy in Debian packaging circles due to its use of female nudity. Rahul wanted to find out "[...] is this allowed in Fedora?"

Amusingly a good deal of the controversy focused on whether the content was freely redistributable, but a predictable moral angle was raised[6] by Muayyad AlSadi who asked for help in producing a spin which removed content deemed objectionable. Muayyad is a Jordanian developer who has been producing an Arabic-localized Fedora spin named "Ojuba" for some time. Muayyad sought a way to make identifying and tagging packages easier to facilitate this spin. Bill Nottingham was[7] skeptical about the chances of tags keeping meaning unless there was some sort of review board. Equally predictable was[8] the reaction typified by Seth Vidal which resisted any attempt to restrict packages according to standards which had nothing to do with licensing or patent issues. Mathieu Bridon thought[9] that the creation of a wiki-page by Muayyad would allow anyone interested in co-ordinating work on "Inappropriate Content" to just go ahead and do it without dragging in bureaucracy.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02071.html
  2. ↑ One of the Common Lisp implementations: http://www.cons.org/cmucl/
  3. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02088.html
  4. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02136.html
  5. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02203.html
  6. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02242.html
  7. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02312.html
  8. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02295.html
  9. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02355.html

Chrome9 Vx800 Graphics Support on LiveUSB

Kristaps Viesalgs asked[1] for help in getting the Fedora Live USB to boot correctly on a machine using a Via Vx800 "Chrome9" GPU. Kristaps had some success with the latest upstream version (from their subversion repository) and asked: "Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility?"

Adam Jackson asked[2] for a more specific bug report because the chip should be supported. He preferred not to ship an autoconfiguration utility instead of just getting the driver correct. Similar points were made by Adam Williamson and [[User:|Xavier Bachelot]]. The latter asked[3] any interested developers to help out the openchrome project in both the 2D and 3D(Gallium) sides.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02146.html
  2. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02154.html
  3. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02163.html

Who Wants a Pony?

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

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02139.html
  2. ↑ http://bugzilla.redhat.com/show_bug.cgi?id=503021

Firestarter Retired as Unportable to PolicyKit

Adam Miller asked[1] whether he should just retire the Firestarter[2] package for which he had recently become the maintainer. His query was based on the recent filing of RFEs to integrate Firestarter with PolicyKit. These suggested to Adam that a large amount of work would be needed due to the lack of any upstream activity for four years and the need to grok PolicyKit.

Following confirmation from Rahul Sundaram and Seth Vidal a decision was made[3] by Adam: "I would honestly rather retire the package than do a WONTFIX, if the project as a whole is going the direction of PolicyKit and upstream is dead then I don't want to keep old and busted cruft around the repositories as Fedora continues to look towards the future."

A further suggestion from "Cry" prompted[4] Adam to start filing RFEs against system-config-firewall for any features present in Firestarter but missing in system-config-firewall.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02089.html
  2. ↑ Firestarter is a firewall configuration GUI
  3. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02094.html
  4. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02122.html

Russian Fedora ?

When Peter Lemenkov asked[1] about the idea of creating a Fedora Foundation outside of the U.S.A. the usual arguments from the past few years were rehashed. Kevin Kofler gave[2] an able summary why this would still present Red Hat with a problem.

An assertion by [[User:|Alexey Torkhov]] that there existed[3] a Red Hat-sanctioned "RussianFedora" spin which contained mp3 codecs and other material excluded from the actual Fedora Project repositories drew demands for proof from Rahul Sundaram.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02013.html
  2. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02025.html
  3. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02390.html

Will FESCo Revisit Kmods ?

A discussion of why VirtualBox will not be a feature due to its code not yet heading upstream and consequently remaining as kmods drew a statement of support from Kevin Kofler for reverting the current banning of kmods should he become a FESCo member. Upon request from Richard W.M. Jones for a dispassionate summary of the reasons to avoid kmods drew[1] a concise response from Seth Vidal.

Adam Williamson and Matt Domsch (Dell's DKMS mastermind) kicked[2] some ideas back and forth over the advantages of akmods versus kmods.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02254.html
  2. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02368.html

Upgrade from Fedora 10 to Rawhide (Fedora 11)

Following a report from Uwe Kiewel that a 

yum upgrade

had spewed all sorts of errors the supported methods for upgrades were re-stated[1] by Adam Williamson: "[I]f you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline."

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02041.html
Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Beats/Developments&oldid=105137"