From Fedora Project Wiki

< FWN‎ | Beats

(FWN #156 Development beat pass 1)
 
(72 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: OSS and PulseAudio Conflict Resolved by CUSE ? ===
=== Would You Like to Write This Beat ? ===


A thread[1] from November led [[WarrenTogami|Warren Togami]] to suggest[2] a plan to use CUSE[3] as part of a strategy to deprecate the near obsolete Open Sound System (OSS) which wreaks havoc with <code>PulseAudio</code> enabled boxes. The plan included a fallback to <code>OSS</code> for users who really wanted it.
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.
 
[[BastienNocera|Bastien Nocera]] was[4] skeptical that <code>CUSE</code> would be ready in time for <code>Fedora 11</code> and suggested instead that a list of applications using OSS be created so that they could be fixed.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01005.html


[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02195.html
<references/>


[3] Character Devices in User space: http://lwn.net/Articles/308445/
=== Is gNaughty a Hot Babe ? ===


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


=== Rawhide Report 2008-12-08 ===
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 the latest ''Rawhide Report'' logged[1] one maintainers use of <code>cvs-import.sh</code> [[DominikMierzejewski|Dominik Mierzejewski]] criticised[2] the use of the script for updating. [[RichardJones|Richard Jones]] asked[3]: "[I]s this stuff really documented anywhere? I have tended to learn it by osmosis, deduction and reading the horribly complicated rules in Makefile.common."
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.


[[JasonTibbitts|Jason Tibbitts]] argued[4] that using <code>cvs-import.sh</code> nullified the potential advantages of using an <code>SCM</code> as it sequestered the sources elsewhere. [[JesseKeating|Jesse Keating]] disagreed[5] due to ease of use issues.
<references/>


A direct answer was provided[6] by [[PatriceDumas|Patrice Dumas]] with links to the relevant portions of the wiki.
=== Chrome9 Vx800 Graphics Support on LiveUSB ===


[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00671.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?"


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


[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00691.html
<references/>


[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00694.html
=== Who Wants a Pony? ===


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


[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00701.html
<references/>


=== The D-Bus Problem ===
=== Firestarter Retired as Unportable to PolicyKit ===


[[IanAmess|Ian Amess]] asked[1] for the current status of a problem caused by a substantial update of the <code>D-Bus</code> package. The update had resulted in the incapacitation of many packages. The most important of these was <code>PackageKit</code>, the default graphical application for managing software.
[[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>.


[[ColinWalters|Colin Walters]] decided[2] that reverting the update was necessary and that changes to <code>D-Bus</code> policy would be postponed. <code>PackageKit</code>, and its <code>GNOME</code> and <code>KDE</code> clients were updated[3] by [[RichardHughes|Richard Hughes]] in an attempt to accommodate the changes. Richard testified that "[o]ver the last two days we've all been working really hard on fixing up all the projects after the DBus update. I know personally I'm closing a duplicate bugzilla every 30 minutes." He noted that the delay between creating an update and pushing it to a mirror was a limiting factor in being able to implement these fixes.
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/>


A post to @fedora-announce by [[PaulFrields|Paul Frields]] explained[4] the series of steps which allowed users to re-enable normal system updates using PackageKit. As of 2008-12-15 this notice also appears at the top of all the Fedora Project wiki pages.
=== Russian Fedora ? ===


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


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


[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00746.html
<references/>


[4] https://www.redhat.com/archives/fedora-announce-list/2008-December/msg00012.html
=== Will FESCo Revisit Kmods ? ===


=== Fedora Com System ? ===
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]].


An exploration of possible ways to alert users to critical information was initiated[1] by [[ArthurPemberton|Arthur Pemberton]]. Most ideas seemed to center around some sort of <code>RSS</code> feed enabled by default on the desktop.
[[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>.


[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01347.html
<references/>


=== YUM: Enable --skip-broken by Default ? ===
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===


Aliasing <code>yum update</code> to <code>yum --skip-broken update</code> was suggested[1] by [[StevenMoix|Steven Moix]] as a way to prevent a lot of recurring support problems by eliminating dependency problems.
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."


It was attempted[2] to strike a balance between reporting these broken dependencies so that they can be fixed and guarding the list of packages on a user's system as private information.
<references/>
 
A divergent sub-thread delved[3] into the appropriate use of <code>Conflicts:</code> in <code>rpm</code> packages. 
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01161.html
 
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01171.html
 
[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01349.html
 
=== Making `updates-testing' More Useful ===
 
The means to enable <code>PackageKit</code> to prompt willing users to install testing updates was explored in a thread opened[1] by [[MatthiasClasen|Matthias Clasen]]: "Basically, PackageKit should know that these are testing updates, and should ask me 'There are ... package updates available that need testing. Do you want to test these now ?' For extra points, we could even show a 'report back' link somewhere that allows to send comments to bodhi."
 
[[RichardHughes|Richard Hughes]] prototyped a solution but worried[2] that it would be necessary to make changes to the users' repository configurations without their explicit consent.
 
A sub-thread discussed[3] the problem of out-of-sync mirrors and the use of the <code>--skip-broken</code> option with yum (see also this same FWN#156"YUM: Enable --skip-broken by Default?".)
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00925.html
 
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01063.html
 
[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01314.html
 
=== Fedora Suckage ? ===
 
The tinder for this week's massive flamewar was laid[1] by [[RobertScheck|Robert Scheck]] in the form of a dryly ironic, multiple-topic rant. Robert attacked the use of "memory wasting" python daemons, lags in pushing updates compared to the <code>EPEL</code> repositories, lack of information on the recent intrusion, poor German translation, the minimal requirements for <code>LiveCD</code> usage, <code>RPM-4.6</code> bugs, Red Hat employees blocking Merge Reviews, <code>PackageKit</code> bugs, and the EU support organisation for Fedora[2]!
 
Although there were several worthy attempts to make use of the above material
for a true conflagration in general the opportunity was wasted and instead
several rational, civil discussions of possible underlying causes and explanations took place. There were some worthy attempts to respond to all parts of this portmanteau complaint, but for the most part the discussion fractured naturally into several threads.
 
One such thread was concerned with the pushing of a <code>D-Bus</code> update which broke many applications including <code>PackageKit</code>. [[KevinKofler|Kevin Kofler]] argued[3] that "[...] we need to be more careful with certain types of security updates, and better let them get some QA even if it means the fix gets delayed." [[MichaelSchwendt|Michael Schwendt]] asserted[4] the lack of active Quality Assurance as one of the contributing factors. KevinKofler explained[5] that the package had been rushed out "Because it was deemed a security update, complete with a CVE ID[.]" See this FWN#156 "The D-Bus Problem" for more details.
 
[[MaxSpevack|Max Spevack]] took up[6] the complaints about ''Fedora EMEA'' and more of that discussion continued[7] on the more appropriate @fedora-ambassadors list.
 
No further information on the security intrusion was forthcoming from [[PaulFrields|Paul Frields]] but he relayed[8] that the matter was not being forgotten or hushed up and that he planned to meet with others to discuss communication procedures for any possible future intrusions.
 
[[RichardHughes|Richard Hughes]] asked[9] for specific bugs to be filed instead of general rants: "[...] I think you need to write much shorter, to the point emails. Ranting doesn't have much affect on anything, whilst filing bugs and getting involved upstream does." He also corrected Robert that many of the daemons which he complained about were written in C, not in Python.
 
[[ColinWalters|Colin Walters]] issued[10] a mea culpa: "Just to be clear, the direct push into stable is my fault; not Red Hat's or other DBus developers or anyone else's. I had originally listed it for updates-testing, but then changed the update to security and in a moment of total stupidity also changed the listing for stable."
 
The idea of "repeatable updates" was raised[11] again by [[LesMikesell|Les Mikesell]] and critiqued for want of a practical implementation by [[JamesAntill|James Antill]]. [[JesseKeating|Jesse Keating]] made[12] a suggestion: "Treat rawhide as your 'new code' land, leave the release trees as your 'testing and working' code. That is don't be so goddamn eager to push new packages and new upstream releases to every freaking branch in existence."
 
[[BehdadEsfahbod|Behdad Esfahbod]] tackled[13] the issue of Red Hat employees allegedly stalling on merge reviews. Behdad criticized the jumbling together of so many issues and repudiated any suggestion that as the maintainer of un-reviewed packages he "[...] must incorporate the merge reviews and close them, no thank you, I don't mind not maintaining anything in Fedora, and I certainly didn't block anyone from making progress in the merge reviews. When you say `The Red Hat people have to follow the Fedora packaging guidelines and rules same as the Fedora folks', does it mean that Fedora should feel free to decide what *I* work on, when it doesn't decide what `other Fedora folks' work on? That doesn't feel right."
 
The criticism of <code>LiveCD</code> localization was handled[14] by [[JeroenvanMeeuwen|Jeroen van Meeuwen]] and he accepted that it would be useful if there were some manner in which the <code>Spin SIG</code> could create spins and torrent seeds outside of Fedora release engineering. It seemed that the need to make absolutely certain that such torrents and spins are kept available for support purposes may make this difficult.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00722.html
 
[2] EMEA is a non-profit organization with the mission to provide a focal-point and economic base for the European Fedora community. http://fedoraproject.org/wiki/Ambassadors/EMEA
 
[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00733.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00753.html
 
[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00855.html
 
[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00772.html
 
[7] https://www.redhat.com/archives/fedora-ambassadors-list/2008- December/msg00092.html
 
[8] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00773.html
 
[9] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00798.html
 
[10] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00812.html
 
[11] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00832.html
 
[12] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00913.html
 
[13] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00834.html
 
[14] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00899.html
 
=== Help Needed: Sift "rawhide" for .pc Files ===
 
[[JesseKeating|Jesse Keating]] requested[1] "[...] somebody to examine all the packages in rawhide that provide .pc [pkg-config] files and ensure proper placement of them based on the review guideline. This will likely require interaction with the packages maintainer(s) so the first step should probably be to produce a list of packages that ship .pc in a non -devel package and send the list (sorted by maintainer) to here so that we can discuss and pick off items."
 
[[MichaelSchwendt|Michael Schwendt]] helped[2] to start the process by providing some lists of non-devel packages which included .pc files or had requires which pulled in packages which provided .pc files.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00612.html
 
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00648.html
 
=== Offtrac ===
 
An itch scratched[1] by [[JesseKeating|Jesse Keating]] was to be able to interact with <code>Trac</code> via the commandline to create milestones for the Fedora 11 release cycle. He implemented his own python library, named Offtrac, to interact with <code>trac</code> using <code>XML-RPC</code> and asked for help in firming up the API and extending his client. Later Jesse explained[2] that the purpose was to "[...] make some aspects of using trac easier for folks, not just project owners but people who file tickets in track, like say for package tagging requests, or blocks, or... "
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00738.html
 
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00808.html
 
=== Updates QA and Karma ===
 
The updates system came in for some more questioning (see this FWN#156 "Making `updates-testing' More Useful") when [[OrionPoplawski|Orion Poplawski]] showed[1] that an <code>rpcbind</code> update for <code>Fedora 9</code> may have been pushed to stable despite comments made by him indicating that it failed due to a dependency. Orion asked two questions: "[1] Should update submitters be allowed to give positive karma to their updates? Seems like that they are too biased. [2] Is there any requirement that an update have positive karma before being pushed to stable?"
 
It appeared that ultimately monitoring of such pushes are down to package maintainers and depend upon the good judgment of those doing the updates. [[MichaelSchwendt|Michael Schwendt]] provided[2] an overview of the situation.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01298.html
 
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01427.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"