From Fedora Project Wiki

< FWN‎ | Beats

m (add reference placeholders)
 
(44 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]]


=== Fedora 11 Mass Rebuild ===
=== Would You Like to Write This Beat ? ===


Some complications resulting from the inconsistent application of Fedora Packaging Guidelines were manifested when the mass rebuild discussed last week(FWN#163<ref>http://fedoraproject.org/wiki/FWN/Issue163#Mass_Rebuild_Coming_Soon</ref>) gained<ref>http://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild</ref> a more concrete shape. [[JesseKeating|Jesse Keating]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01281.html</ref> a request that all maintainers would read the wiki page describing what needs to be done, especially the Maintainer Actions section.
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.


The rebuild should kick-off this Monday (2009-02-23). The wiki page describes the relatively narrow timeframe in which maintainers can attempt their own rebuilds and the way in which they can avoid the auto-rebuild.
<references/>


Concern was expressed by [[TomLane|Tom Lane]] that the rebuilds were non-ordered. Jesse responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01287.html</ref> that ordered builds were "[...] generally only are necessary when bumping sonames or otherwise bootstrapping items.  Given that neither of those apply for this rebuild, effort spent trying to order and chain builds would be effort wasted." [[RalfCorsepius|Ralf Corsepius]] challenged<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01297.html</ref> this with the observation that <code>pkgconfig</code> BuildRequires are added automatically. Ralf suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01303.html</ref> the problem could be solved by "[...] checking which packages in current rawhide contain *.pc's but do not Provide nor Require pkgconfig(foo) and to rebuild them (in manually presorted order) in advance to the mass rebuild."
=== Is gNaughty a Hot Babe ? ===


[[JonMasters|Jon Masters]] appreciated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01298.html</ref> Jesse's work and worried that the rebuild might leave some statically built binaries using i386 instead of the promised i586 (see FWN#162<ref>http://fedoraproject.org/wiki/FWN/Issue162#Fedora_11_Will_Support_i586_Instruction_Set</ref>). Subsequent rebuilds were suggested as a means to work around the problem but Jesse preferred to identify specific problems and stated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01300.html</ref>: "I think the most I'd be willing to do would be a second build pass across the static packages.  IMHO everything else should be left up to testing discovery and fixing the assumptions rather than hiding 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.  


Another approach was suggested by [[User:Konradm|Conrad Meyer]] based on using <code>BuildRequires: *-static</code>. When Ralf replied that this would not work because many packagers who had not used static subpackages Conrad pointed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01307.html</ref> to the guidelines. [[NicolasMailhot|Nicolas Mailhot]] ruefully responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01312.html</ref> that his experience with the fonts guidelines suggested that enforcement was necessary. Later discussion with [[JakubJelinek|Jakub Jelínek]] about the presence of <code>libc.a</code> in <code>glibc-devel</code> suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01322.html</ref> that it will not be simple to apply this particular guideline to <code>glibc</code> without <code>gcc -static</code> ceasing to behave as expected.
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?"
 
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.


<references/>
<references/>


=== Virtual Provides for Login Managers ===
=== Chrome9 Vx800 Graphics Support on LiveUSB ===


Following problems reported<ref>https://bugzilla.redhat.com/show_bug.cgi?id=485789</ref> with booting to runlevel 5 by default with the <code>slim</code> login-manager [[http://translate.fedoraproject.org/people/clumens|Chris Lumens]] sugges:ted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01237.html</ref> that "[...] all packages containing a login manager include a special Provides: that we can query on." This would allow <code>anaconda</code> to determine whether a login-manager is installed without the difficulties of curating a list.
[[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:Pertusus|Patrice Dumas]], and others, provided<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01399.html</ref> a good deal of feedback which seems to have led to a consensus that <code>Provides: service(graphical-login)</code> will be added to all packages which provide a login manager.
[[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.  


An interesting sub-thread developed in which [[ColinWalters|Colin Walters]] argued<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01400.html</ref> that adding display managers (other than <code>gdm</code> and <code>kdm</code> should be strongly discouraged. This was met<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01403.html</ref> with a good deal of disagreement from [[User:Spot|Tom Callaway]] and [[User:Skvidal|Seth Vidal]].
<references/>


Colin explained<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01404.html</ref> that the ramifications of changing such an integral part of the OS were complex and that while anyone should be free to add such software it should also be "[...] within the rights of the people working on the desktop to close any bugs filed by people using something else WONTFIX." [[User:jkeating|Jesse Keating]] and [[User:Skvidal|Seth Vidal]] seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01407.html</ref> to agree that it should be possible for the Fedora Project do define specs to which login managers should conform.
=== Who Wants a Pony? ===


The thread blossomed into several discussions. One focused on the technical challenges occasioned<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01408.html</ref> by the interaction of <code>GDM</code>, <code>PAM</code>, <code>gnome-keyring</code>, <code>NetworkManager</code> and <code>ConsoleKit</code>. Another saw<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01434.html</ref> [[User:Toshio|Toshio Kuratomi]] and Colin debating the strategic merits of making it more or less easy for interested parties to add their software to the Fedora Project ecosystem.
[[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/>


=== Reducing the Number of (Dis)Charge Cycles for Laptop Batteries ===
=== Firestarter Retired as Unportable to PolicyKit ===
 
A certain amount of excitement resulted when [[BradLongo|Brad Longo]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01194.html</ref>: "[...] if Fedora's power management tool has something built in so that when the battery reaches full charge, it will then discharge to lets say around 95% before beginning to charge again." The excitement arose from Brad's premise that "[...] leaving your laptop plugged in and charging with a full battery charge is harmful for the battery."


Several responses rejected<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01201.html</ref> the premise and pointed out that smart chargers implement trickle-mode charging. [[MatthewGarrett|Matthew Garrett]] replied<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01202.html</ref> with some specific information about how laptop battery charging happens at a firmware-controlled threshold level. Matthew speculated that Brad wanted "[...] presumably an interface to modify that threshold. This is device specific. The tp_smapi driver (which is not in the kernel for exceedingly dull reasons) allows this to be configured on Thinkpads. I don't believe that we know how to on any other systems." [[HansUlrichNiedermann|Hans Ulrich Niedermann]] had<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01257.html</ref> an out-of-kernel module for <code>tm_smapi</code> which was configurable via <code>/etc/sysconfig</code>.
[[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>.
 
[[MatthewSaltzman|Matthew Saltzman]] reported<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01269.html</ref> some experiences with <code>Windows</code> setting the charge-threshold to 85% which is supposed to lengthen the battery life. [[CallumLerwick|Callum Lerwick]] referenced<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01304.html</ref> a Wikipedia article which claimes that the "[...] optimal storage charge for a Li-Ion is %40. Also, heat causes Li-Ion batteries to degenerate much faster, so if you're really worried about preserving your battery, don't leave it in the laptop while it's running. Yet another argument for less power usage. Less power, less heat, longer battery service life. Fewer toxic batteries going in to the land fill if you like that angle."


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


=== config.guess Reporting Incorrect Configuration Name ? ===
=== Russian Fedora ? ===


[[PanuMatilainen|Panu Matilainen]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01338.html</ref> if it was a problem that the <code>config.guess</code> script from <code>autotools</code> no longer reported "redhat" as the manufacturer part of the configuration triplet. Panu referenced the documentation which suggests that "[...] the manufacturer part of the configuration name is the manufacturer of the CPU, not `OS vendor' so the former `redhat' was always incorrect. I don't know the history behind the decision to stomp `redhat' in there to begin with nor why it was then dropped later on. But having gotten used to it, people occasionally think the `unknown' (or `pc' for that matter) is a bug."
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.


While [[JakubJelinek|Jakub Jelínek]] thought that providing the "redhat" string provided more information than "pc" or "unknown" [[StepanKaspal|Stepan Kaspal]] argued<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01355.html</ref> strongly that reverting to maintaining such a patch was wrong. He suggested that either upstream should be convinced to change the use of "manufacturer" or that the <code>%configure</code> macro in the specfile could be used to explicitly avoid calling <code>config.guess</code>. 
An assertion by [[User:|Alexey Torkhov]] that there existed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02390.html</ref> a Red Hat-sanctioned "RussianFedora" spin which contained mp3 codecs and other material excluded from the actual Fedora Project repositories drew demands for proof from [[User:Sundaram|Rahul Sundaram]].
From here on the thread became too technically detailed to summarize although it is relatively brief as of going to press. Those learned in the lore of autotools and cross-compilation will find much to gladden their hearts.


<references/>
<references/>


=== Build-time Trapping of Python Syntax Errors ===
=== Will FESCo Revisit Kmods ? ===


[[User:Twaugh|Tim Waugh]] initiated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01563.html</ref> verification that Python code can be parsed correctly: "[...] since we are already byte-compiling Python code at build time, it is no extra effort to verify that it can be parsed and fail if not."
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]].


Reaction was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01574.html</ref> uniformly positive and when [[PanuMatilainen|Panu Matilainen]] explained the simple errors which the byte compile would catch and suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01584.html</ref> a simple method of determining affected packages [[User:Ffesti|Florian Festi]] took up the challenge.
[[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>.


<references/>
<references/>


=== YUM Plans for Transition to Fedora 12 i686 Architecture ===
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===
 
When [[User:Pghmcfc|Paul Howarth]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01533.html</ref>: "Now that Fedora 11 x86_32 is going to be based on i586 packages rather than i386 packages, does it follow that yum's $basearch will change from i386 to i586 and hence repository directory layouts changing too, or will it stay at i386?" a brief discussion between [[User:Skvidal|Seth Vidal]] and [[User:Jwboyer|Josh Boyer]] started<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01551.html</ref> with a discussion over whether repositories should be named after specific architectures.


[[User:Skvidal|Seth Vidal]] differentiated between <code>$arch</code> and <code>$basearch</code> and explained<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01557.html</ref>: "The whole reason I liked used $arch was that it meant when fedora stopped producing a 586 compatible tree, we didn't stop any one else from making a 586 compat tree and having it available like secondary arches are."  [[User:jkeating|Jesse Keating]] explained<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01561.html</ref> that "i386" was a misnomer for the <code>x86</code> offering. [[User:Jwboyer|Josh Boyer]] was<ref></ref> unsure whether i586 would actually "go away" for Fedora 12. [[User:Ausil|Dennis Gilmore]] was sure that it would and offered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01587.html</ref>: "Anyone who wants to continue i586 support post F11 i look forward to talking to about setting up i586 as a secondary arch."
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"