From Fedora Project Wiki

< FWN‎ | Beats

(add F11 alpha release info)
 
(57 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: [[OisinFeeley|Oisin Feeley]]
Contributing Writer: [[User:Ush|Oisin Feeley]]


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


[[User:Jkeating|Jesse Keating]] announced<ref>http://www.redhat.com/archives/fedora-announce-list/2009-February/msg00004.html</ref> the availability of <code>Fedora 11 Alpha</ref> on 2009-02-05. His beautiful poetry was accompanied by a suggestion to read the Release Notes<ref>http://fedoraproject.org/wiki/Fedora_11_Alpha_release_notes</ref>.
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.
 
One change which drew<ref>http://www.redhat.com/archives/fedora-test-list/2009-February/msg00118.html</ref> extensive commentary on @fedora-test was the default disabling of the <code>Ctrl-Alt-Backspace</code> key combination. This traditionally kills the X server and to regain the usual behavior it is necessary to create an <code>Xorg.conf</code> file (these no longer exist by default either) and add the line <code>Option "DontZap" "false"</code> to it.


<references/>
<references/>


=== Fedora 11 Will Support i586 Instruction Set ===
=== Is gNaughty a Hot Babe ? ===


Last week (FWN#161<ref>http://fedoraproject.org/wiki/FWN/LatestIssue#Dropping_Support_for_i586_Architecture_.3F</ref>) we reported on a proposal to cease building Fedora 11 for the i586 CPU instruction set. FESCo had delayed its decision in order to discuss the matter further. The issue was addressed<ref>http://bpepple.fedorapeople.org/fesco/FESCo-2009-02-05.html</ref> on 2009-02-05 with the outcome that a proposal by [[User:Ausil|Dennis Gilmore]] to continue supporting i586 for the duration of Fedora 11 but to transition to i686 for Fedora 12 was supported.  
[[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.  


Prior to the meeting [[WarrenTogami|Warren Togami]] summed up<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00200.html</ref> the advice of [[JakubJelinek|Jakub Jelínek]] as: "Jakub recommends i586.rpm for Fedora 11, because it doesn't gain us much of anything to go with i686 minimum.  The benefits of i586 to i686 are simply not important because cmov is usually not a worthwhile optimization on ia32."
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?"  


An interesting suggestion by [[AdamJackson|Adam Jackson]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00282.html</ref><ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00407.html</ref> that if there is a committed user-base of i586 users they could probably support it in the Secondary Architecture (see FWN#92<ref>http://fedoraproject.org/wiki/FWN/Issue92#Secondary_Arch_Proposal_Cont.</ref>) infrastructure.
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.
 
[[UlrichDrepper|Ulrich Drepper]] and [[User:Rathann|Dominik Mierzejewski]] debated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00240.html</ref> whether the use of cmov can in some circumstances cause performance degradation.
 
It is unclear exactly what performance benefits could be obtained by passing various architecture-specific flag combinations to GCC but it does seem that the burden of building and maintenance will be eased significantly by these changes. As a related change<ref>http://bpepple.fedorapeople.org/fesco/FESCo-2009-02-05.html</ref> x86_64 kernels will be installed with a 32-bit userspace.  


<references/>
<references/>


=== RFC: Power Management ===
=== Chrome9 Vx800 Graphics Support on LiveUSB ===
[[PhilKnirsch|Phil Knirsch]] initiated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00365.html</ref> a discussion of attempts to decrease power consumption especially in userland. A wiki page<ref>http://fedoraproject.org/wiki/Features/PowerManagement</ref> reflects some of the research Phil has pulled together.


[[RichardHughes|Richard Hughes]] pointed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00376.html</ref> out some interesting work on <code>DeviceKit-power</code> where he built on <code>powertop</code>. [[Olivier Galibert|Olivier Galibert]] raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00430.html</ref> a possible problem with Richard's use of D-Bus itself causing wakeups, but according to [[ColinWalters|Colin Walters]] a patch existed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00642.html</ref> to fix this problem.
[[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?"


Many of the items suggested in Phil's page for documentation were suggested by [[User:Notting|Bill Nottingham]] as desiderata for defaults. While Phil agreed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00406.html</ref> in general he itemized some of the problems. These include problems with network interfaces and hard-disk spindowns which may be approachable as a result of a <code>tuned</code> daemon on which Phil is working.
[[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 addendum of audio hardware power-saving was made by [[EricSandeen|Eric Sandeen]] along with a list of bugs which led<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00413.html</ref> Phil to wonder if a tracker bug to collate all the information would be useful.
 
[[MatthewGarrett|Matthew Garrett]] expressed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00415.html</ref> some worries that hard-disk power-saving would cause physical wear and the <code>relatime</code> patches to work around over-aggressive deletion of content in /tmp would continue to be stalled.
 
The importance of separating out KDE and GNOME dependent features was noted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00403.html</ref> by [[User:Kkofler|Kevin Kofler]].


<references/>
<references/>


=== Rawhide Report 2009-02-07 ===
=== Who Wants a Pony? ===
 
The last report<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00661.html</ref> lists 14 new packages added, 57 modified and some broken dependencies. New packages include <code>dissy</code>, a graphical front-end to <code>objdump</code> and <code>python-pygooglechart</code> a Python wrapper for the Google Chart API.
 
[[RichardHughes|Richard Hughes]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00669.html</ref> that the update to PolicyKit-gnome-0.9.2-1.fc11 might be useful: "If you're having problems with PackageKit and buttons "not working" you need this update."


Some of the x86_64 broken dependencies were due to to <code>mono-2.4</code> being pushed to rawhide which led [[User:DavidNielsen|David Nielsen]] to suggest<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00674.html</ref> that a heads up would have been useful. [[User:Alexlan|Alex Lancaster]] requested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00746.html</ref> that API/ABI breakage would be announced on @fedora-devel-announce instead of on the high-traffic @fedora-devel.
[[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/>


=== New module-init-tools Uses Binary modules.dep|alias|symbols ===
=== Firestarter Retired as Unportable to PolicyKit ===


An update to <code>module-init-tools-3.6</code> was pushed to <code>rawhide</code> by [[JonMasters|Jon Masters]] in order to speed up<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00477.html</ref> boot time significantly. The files <code>modules.dep</code>, <code>modules.alias</code> and <code>modules.symbols</code> will have binary versions which are used in preference to their old text versions. Jon asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00353.html</ref> if the need to run <code>depmod -a</code> after upgrades to <code>module-init-tools</code> would upset anyone. There seemed to be general approbation of his changes and they should land soon for Fedora 9 also.  
[[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>.


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


=== New Georgian Fonts Packaged Rapidly ===
=== Russian Fedora ? ===


A call was put out<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00281.html</ref> by [[User:Nim|Nicolas Mailhot]] for someone to package a completely new Georgian font pack created by Besarion Paata Gugushvili.  
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.


Nicolas was especially keen to get this done quickly as he had contacted Besarion and been rewarded with completely new fonts not shipped by any other distro, licensed with the FSF font exception to the GPL all within nine hours!
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]].
 
[[User:Spot|Tom Callaway]] responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00308.html</ref> within mere hours.


<references/>
<references/>


=== Distro-agnostic /boot Metadata Standard ? ===
=== Will FESCo Revisit Kmods ? ===


A negative review in German IT magazine "c't" led<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00273.html</ref> [[ChristophHoger|Christoph Höger]] to ask if it was possible to preserve the ability to boot other GNU/Linux distros after installing Fedora. The most annoying point seemed to be that Windows installations are preserved.
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]].


A moderately long thread resulted and covered several ideas to allow the <code>GRUB</code> bootloader to identify other distributions. One such was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00345.html</ref> .that there should be an agreement among distributions to use a shared metadata standard on boot partitions.
[[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/>


=== GCC-4.4 Mass Rebuild Successful ===
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===
 
[[JakubJelinek|Jakub Jelínek]] reported<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00180.html</ref> that a mass rebuild of rawhide (snapshotted on 2009-01-26) of 6228 packages had produced only a few hundred failures. He listed these by type of failure.
 
Several of the packages listed failed to build for reasons other than GCC, for instance Java packages failed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00220.html</ref> due to <code>maven</code> being broken.
 
[[User:knurd|Thorsten Leemhuis]] provided<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00229.html</ref> a list of packages and owners sorted by owner which was generally appreciated. He pointed out: "Finding all your packages in such a long list gets really hard as soon as you maintain 10 or 15 packages."
 
Problems reported due to a mismatch between the <code>libstdc++</code> headers requirement of <code>-march=i486</code> and <code>Koji</code>'s default use of <code>-march=i386</code> led<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00257.html</ref> Jakub to whip up some fixes. He requested that <code>CFLAGS</code> were not altered in <code>SPEC</code> files.
 
<references/>
 
=== Help Rel-eng Accelerate Updates Processing ===
 
One bottleneck in the processing of updates to packages is that they need to be signed. Work is ongoing to automate this (see FWN#147<ref>http://fedoraproject.org/wiki/FWN/Issue147#Unsigned_Rawhide_Packages_an_Attack_Vector_.3F</ref>) with a signing-server codenamed "sigul".


[[User:Cwickert|Christoph Wickert]] wondered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00508.html</ref> why it had taken over five days for an update to one of his packages to get to <code>testing</code>. When [[User:Jwboyer|Josh Boyer]] responded that it was because one human ([[User:Jkeating|Jesse Keating]]) had to sign the packages and he had been also busy getting <code>Fedora 11 Alpha</code> released, [[DanielBerrange|Daniel P. Berrange]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00515.html</ref> adding more humans to help. [[JesseKeating|Jesse Keating]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00576.html</ref> that anyone who wished to help could take some of the load off the release-engineering team so that they had more time for package signing.
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"