From Fedora Project Wiki

< FWN‎ | Beats

m (→‎Small Machine SIG: add link to RedHatMagazine eeedora article)
 
(108 intermediate revisions by 2 users not shown)
Line 5: Line 5:
mailing list are summarized.
mailing list are summarized.


Contributing Writer: [[:User:OisinFeeley|Oisin Feeley]]
Contributing Writer: [[User:Ush|Oisin Feeley]]


=== FlashPlayer 10 Symlink Provokes Proprietary Support Argument ===
=== Would You Like to Write This Beat ? ===


A formal request to remove the "miniature libcurl.so.3 library" was made[1] by [[JoshBoyer|Josh Boyer]]. This had been created in order to support the latest version[2] of Adobe's proprietary Flash Player which had a hard dependency on <code>libcurl.so.3</code> while Fedora 8, Fedora 9 and Fedora 10(alpha) provided only <code>libcurl.so.4</code>. Josh argued that the change, mentioned on [[WarrenTogami|Warren Togami's]] blog[3] had been made solely to accommodate a proprietary application.
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.


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


[2] http://labs.adobe.com/technologies/Flashplayer10/
=== Is gNaughty a Hot Babe ? ===


[3] http://wtogami.livejournal.com/27778.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.


After [[NikolayVladimirov|NikolayVladimirov]] argued[4] that it was a minimal, non-invasive change which might be useful for some "dead opensource projects that use the old version" Josh replied[5] this support goal would be better met by providing a "compat-curl" package instead of "just a hack with the sole intention of making Flash work again". In an aside he mentioned that he would have no objection to removing libflashsupport and a bunch of other stuff. [[MatthewGarrett|Matthew Garrett]] followed[6] the train of thought to one possible final destination: "If the ABI is consistent across the SONAME bump, then it's a hack that supports any pre-existing binaries that users have. The best way we could serve those users with a compat package would be to ship another copy of the latest version of curl (so they get the bugfixes) but with a changed SONAME - at which point we'd be shipping two identical source packages that produce binary packages that differ only in library name. In doing so, we'd be increasing the cost of security updates. What does that actually win us?"
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?"  


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


[5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00484.html
<references/>


[6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00498.html
=== Chrome9 Vx800 Graphics Support on LiveUSB ===


[[BastienNocera|Bastien Nocera]] thought[7] that such a "compat-curl" package would duplicate unmaintained code and was pointless "since libcurl didn't break ABI, and only changed soname". Josh stood firm[8] and retorted that if the ABI was static then the applications could simply rebuild against the newer libcurl. [[WarrenTogami|Warren Togami]] characterized[9] Josh's viewpoint as "extremist" as it proposed "removing a zero maintenance 2496 byte file that would permanently break Flash 10 forever in Fedora" and that furthermore "[Adobe] are not violating any licenses like NVidia[.]" Following similar sentiments from "drago01" Josh deferred the discussion to a FESCo meeting held on Wed 13th August and this duly decided[10] to leave things as they were with two soname files in the curl package despite some strenuous objections which emphasized both the desirability of sub-packaging and also of not catering to the needs of proprietary applications.
[[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?"


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


[8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00488.html
<references/>


[9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00496.html
=== Who Wants a Pony? ===


[10] http://bpepple.fedorapeople.org/fesco/FESCo-2008-08-13.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.


=== Parallel Install of syslog-ng, rsyslog and sysklogd ===
<references/>


[[DouglasWarner|Douglas Warner]] sought help[1] in packaging ''syslog-ng'' so that it could be installed with either of the other current system loggers: ''rsyslog'' and ''sysklogd''. He explained that all three installed their own "logrotate" files which targeted the exact same log files for rotation and thus doubly rotated the logs. So far Douglas' attempt to change his own ''syslog-ng'' package to fix this was stymied on RHEL boxes because updates of ''sysklogd'' (RHEL's preferred system logger) silently remove ''syslog-ng''. Later in the thread [[BennyAmorsen|Benny Amorsen]] provided[2] the insight that running ''syslog-ng'' for handling remote logs and ''rsyslog'' for its simple configuration simultaneously was useful.
=== Firestarter Retired as Unportable to PolicyKit ===


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


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


The question of how to ship precisely the same logrotate script, from the viewpoint of RPM, was mentioned[3] by Douglas as one possible solution. If this could be done then RPM would be agnostic about where the file came from as long as it were possible to figure out whether the identity was based on "file size, md5, timestamp, ?". [[VilleSkyttä|Ville Skyttä]] suggested[4] using the <code>%verify</code> directive as detailed in a link to the "Maximum RPM" book.
=== Russian Fedora ? ===


[3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00558.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.


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


A restructuring of the problem by [[JasonTibbits|Jason Tibbits]] led him to recommend[5] that a separate logrotation-script package be split out of the current packages and that each of the current packages be made to depend on the new package. When Douglas nixed the suggestion due to his lack of control over the ''sysklogd'' script Jason seemed[6] to react a little testily and asked "Could we discuss technical solutions and ignore Red Hat politics? What I proposed is a standard method of dealing with these things." After [[JarodDiamond]] agreed with this [[DmitryButskoy|Dmitry Butskoy]] pointed[7] out that a different PID filename is used in each script and wondered was it possible to to create such a common logrotate package for all the syslog-like packages. A likely solution was proposed[8] by [[ChrisAdams|Chris Adams]] which used the expedient of symlinking each of the unique PID files from within the init script.
<references/>


[5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00561.html
=== Will FESCo Revisit Kmods ? ===


[6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00563.html
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]].


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


[8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00604.html
<references/>


=== General Outage of Fedora Infrastructure ===
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===


Many were caught by surprise when there was a widespread outage of Fedora Project infrastructure during the week. The earliest symptoms noticed included an inability to access Koji (see e.g. this FWN#139 "Koji from Behind a Firewall") or obtain updates with ''yum''. A general announcement by [[PaulFrields|Paul Frields]] followed[1] quickly on Thursday 14th and stated that an "issue in the infrastructure systems [was being investigated and might] result in service outages[.]" Somewhat ominously it concluded "[..] as a precaution, we recommend you not download or update any additional packages on your Fedora systems." This led some to speculate[2] that there might be a security problem.
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."


Further announcements or explanations were not forthcoming for days, except for a post to @fedora-infrastructure which suggested[3] that the problem was causing a lot of hard work. [[PaulFrields|Paul Frields]] posted another update[4] on Sat 16th. This succinctly stated that the wiki and FAS should be back soon but that the application servers would take a bit longer. 
<references/>
 
[1] https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00008.html
 
[2] http://lwn.net/Articles/294188/
 
[3] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00109.html
 
[4] http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00009.html
 
=== Koji from Behind a Firewall ===
 
A query was made[1] by [[VictorLazzarini|Victor Lazzarini]] about how to connect to ''Koji'' using the CLI from behind a firewall. He wondered specifically how to set up a proxy connection. He added that he was seeing an error when using a web browser but was[2] unable to provide it due to the general outage in Fedora infrastructure.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00660.html
 
[2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00664.html
 
[[MikeBonnet|Mike Bonnet]] answered[3] that ''Koji'' did not have direct proxy support but that it used only ports 80 (http) and 443(https) as these are generally open. He explained that it would be "a significant amount of effort" to support proxies directly. Unfortunately Vincent had to report[4] that his institution forced everything through a proxy due to being "paranoid about security) and he was stuck with either setting up an open access machine or working from home.
 
[3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00665.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00667.html
 
A possibility for the web browser error was supplied[5] by [[AndrewPrice|Andrew Price]] as an <code>ssl_error_handshake_failure_alert</code> which he had seen prior to the general outage. 
 
[5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00675.html
 
=== Small Machine SIG ===
 
An effort to gauge interest in starting a small form-factor machine SIG was made[1] by [[JeremyKatz|Jeremy Katz]]. He asked that anyone interested in running Fedora on the Asus Eeepc, netbooks, UMPCs, MIDs and perhaps the XO would contribute to a wiki page[2]. The specific goals were both to "just get the hardware working well with [current] Fedora" and also "possibly a spin that is explicitly targeted at some of the constraints of the hardware down the line." Several people responded and added themselves to the wiki.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00497.html
 
[2] http://fedoraproject.org/wiki/JeremyKatz/Netbooks
 
[[PeterRobinson|Peter Robinson]] defined the goal as "a small, low power image with packages without massive dependencies" while [[JaroslavReznik|Jaroslav Reznik]] called[3] for an emphasis on the UI instead of merely on drivers for hardware support. [[KevinVerma|Kevin Verma]] agreed[4] that "more usable UIs for small devices, also apps that are more adaptive to small screens" were important, and cited Maemo[5] and Moblin[6] as inspirations. Kevin had already[7] done some packaging work in this area.
 
[3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00576.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00589.html
 
[5] Maemo is Nokia's software platform for internet tablets. It is based on GTK+. See http://maemo.org/ for more information.
 
[6] http://fedoraproject.org/wiki/FWN/Issue136#RPM_Inspires_Intel_Moblin2_Shift_From_Ubuntu
 
[7] http://kevinverma.fedorapeople.org/packages/
 
[[JeremyKatz|Jeremy Katz]] responded[8] that given the imminent release of Fedora 10 it was most likely that better hardware support would be the immediately achievable goal. While agreeing that Maemo was interesting he preferred to get Sugar[9] running within the Fedora 11 timeframe. In answer to JeffSpaleta he clarified[10] that recent work done by [[GregDeKoenigsberg|Greg DeKoenigsberg]] to run "stock" Fedora on the XO was relevant but a different goal from producing a spin of Fedora, for all small machines, using the Sugar interface.
 
[8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00594.html
 
[9] The unique interface developed for the resource-constrained XO produced by the OLPC project
 
[10] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00609.html
 
The main developer of BLAG[11], [[JeffMoe|Jeff Moe]], posted[12] links to images that supported "all hardware on the EeePC 701/900 using *only* free software. This includes wifi with the ath5k driver. It is based on -libre and -rt plus various other patches." [[JeremyKatz|Jeremy Katz]] re-phrased[13] his goal as "[to] be able to run on the systems with stock Fedora" in order to avoid the distribution problem of special spins. Jeff encouraged[14] this possibility with the information that apart from wireless the stock Fedora 9 kernel supported everything on the EeePC 701/900 and that although there was support for the Atheros ar2425 wireless chip support in the 2.6.27 kernel there were still specific patches lacking for EeePCs. He added that the EeePC 901/1000 used a different wireless chip (from Ralink who have been active in releasing information necessary for Free drivers in the past) and included a link to Ralink's code for an apparently complete RT2860 ABGN driver. [[WarrenTogami|Warren Togami]] confirmed[15] that there were vague rumors that the chipset would be supported upstream.
 
 
[11] A single-CD derivative of Fedora 9 which is strictly Free Software. See https://wiki.blagblagblag.org/FAQ
 
[12] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00511.html
 
[13] www.redhat.com/archives/fedora-devel-list/2008-August/msg00533.html
 
[14] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00537.html
 
[15] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00550.html
 
After [[RexDieter|Rex Dieter]] asked why the BLAG folks were not upstreaming their changes to Fedora it was explained[16] by Jeff that he filed bug reports and mailed .spec files upstream but that they were perhaps in conflict with the packaging guidelines. He also alluded to the fact that much of his work centered around the "kernel-libre" which had caused flamewars in the recent past. In conclusion he noted that he had been able to perform many simultaneous tasks "while playing a song with *zero* stutters or dropouts on a teeny little computer. That rules." but that it required the use of the low-latency audio server JACK[17], that is non-standard on Fedora.
 
[16] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00554.html
 
[17] http://jackaudio.org/
 
Surprisingly no mention was made during the discussion of the "Eeedora" distribution which had been written about[18] in Red Hat Magazine towards the start of this year.
 
[18] http://www.redhatmagazine.com/2008/02/14/fedora-eee-pc-eeedora/

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"