From Fedora Project Wiki

< FWN‎ | Beats
 
(89 intermediate revisions by 2 users 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]]


=== PATH:/sbin Tab Confusion ===
=== Would You Like to Write This Beat ? ===


Some time ago (2008-04-23) it was proposed[1] by [[TomCallaway|Tom Callaway]] to append <code>/sbin\</code> and <code>/usr/sbin</code> to the path of non-root users. The rationale was to make it easier for non-root users to use tools which are traditionally perceived as "administration" tools, for example <code>ifconfig</code>, <code>parted</code> and <code>fdisk</code>. A good overview of the problem was posted[2] by [[BehdadEsfahbod|Behdad Esfahbod]] . An excellent compendium of objections to the proposal posted[3] by [[EnricoScholz|Enrico Scholz]] encapsulates most of the problems perceived at the time. Several prolonged discussions on the topic mostly centered[4] around alternate strategies which included moving binaries from <code>/sbin</code> to <code>/bin</code>, symlinking from one to the other directory, or setting up[5] <code>sudo</code> by default.
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-April/msg01625.html
<references/>


[2] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01661.html
=== Is gNaughty a Hot Babe ? ===


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


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


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


The case for moving many of the binaries was made[6] strongly by [[DavidCantrell|David Cantrell]] and arch-skeptic [[RalfCorsepius|Ralf Corsepius]] voiced[7] a general objection that "[...] this discussion is as old as */sbin exists [... and I] consider both proposals to be populist propaganda." After much thrashing out of the issue the proposal was coalesced[8] in the Feature named "/sbin Sanity" and <code>/usr/local/sbin:/usr/sbin:/sbin</code> were appended to the <code>PATH</code> of normal users of Fedora 10. A related change suggested was to allow firstboot to configure sudo to grant the first created user all privileges but this feature is not present in Fedora 10 Beta.
<references/>


With the release of Fedora 10 Beta some of the predicted daily inconveniences of the change have been realized[9]. [[MattMiller|Matt Miller]] (who had been consistently opposed to the change) reported that command-line completion was cluttered with multiple unwanted choices: "We've just made the command line a lot less user friendly for common use in exchange for an ugly fix to a small inconvenience." In a wryly humorous post he noted that due to wanting <code>/etc/profile.d</code> to continue working he could not simply set a static path. [[StephenSmoogen|Stephen Smoogen]] joked[10] that Matt was the "[...] first systems administrator I have met in several years who hasn't had /usr/sbin:/sbin in their default path. You sure they didn't make you a manager and didn't tell you?" and added that "I think the chance for putting it back is still there.. if someone is willing to do the work on the hard but correct way? I think it was crickets the last couple of times when volunteers were asked for that." [[NigelJones|Nigel Jones]] was among several who asserted[11] that typing the full paths was what they preferred and Stephen admitted[12] that he had received some offlist ribbing and promised to mend his ways: "I am removing /sbin:/usr/sbin from my path and learning to type /usr/sbin for the commands I have 'shortcutted' over the years. Next I will be removing the bad habit of '/sbin/sudo bash' :)"
=== Chrome9 Vx800 Graphics Support on LiveUSB ===


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


[7] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01761.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] http://fedoraproject.org/wiki/Features/SbinSanity
<references/>


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


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


[11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00004.html
<references/>


[12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00181.html
=== Firestarter Retired as Unportable to PolicyKit ===


[[VilleSkyttä|Ville Skyttä]] and [[MatthewMiller|Matt Miller]] volunteered[13] to take up the burden of moving appropriate binaries out of <code>/sbin</code> and into <code>/bin</code> in order to help revert the change.
[[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>.


[13] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00003.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."
 
Over on @fedora-desktop [[RahulSundaram|Rahul Sundaram]] suggested a <code>kickstart</code> snippet which would add the first user to the wheel group and add blanket permissions to the wheel group in <code>/etc/sudoers</code> . [[ColinWalters|Colin Walters]] agreed[14] with the concept but wondered "[a]re we too far into the F10 process for this?"
 
[14] https://www.redhat.com/archives/fedora-desktop-list/2008-October/msg00006.html
 
=== Speeding-up Modprobe and MAKEDEV ===
 
Inspired by [[ArjanvandeVen|Arjan van de Ven's]] five-second Asus EeePC boot and Mandriva's work on similar topics [[JakubJelinek|Jakub Jelinek]] posted[1] his patches to improve the speed of <code>modprobe</code> and <code>MAKEDEV</code>. He hoped that this sharing would result in more community experimentation. The first patch enables <code>depmod -a</code> to produce compact binary files which can be searched for aliases and dependencies more quickly than the standard text files, which are still also produced. The patch to <code>MAKEDEV</code> similarly reduces the size of the searched files, in this case config files, and improves the efficiency of an inner loop. The times appeared to be decreased by several orders of magnitude according to the sample figures posted by Jakub.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00043.html
 
[[KyleMcMartin|Kyle McMartin]] was excited[2] and suggested that "[t]he biggest win by far for <code>MAKEDEV</code> is profiling the often hit devices, and prioritizing things. Dave Airlie moved a bunch of the cciss and other almost never-seen devices to be sourced last and ended up with a huge win." [[BillNottingham|Bill Nottingham]] responded[3] that <code>MAKEDEV</code> ought not to be run at boot at all. [[JakubJelinek|Jakub Jelinek]] was not optimistic that the <code>MAKEDEV</code> patch would be applied upstream as he noted[4] that he had sent it upstream over ten months ago.
 
[2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00046.html
 
[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00047.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00054.html
 
 
=== Uniform Proxy Settings ===
 
The issue of constructing a uniform method of enforcing proxy settings for applications was raised[1] by [[KulbirSaini|Kulbir Saini]]. He complained "[w]henever I try a new version of Fedora, the first problem I face is setting the proxy. It seems for almost every application, I have to specify proxy at a different place."
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00097.html
   
   
A reply by [[SimonAndrews|Simon Andrews]] recapped[2] previous debates on the topic by pointing out the twin problems of a lack of a common setting and the inability of many applications to update their proxy settings on the fly. Simon suggested that a localhost proxy could be forced on all applications if <code>NetworkManager</code> were to contain hooks to re-route local proxy requests either directly to the internet or via a secondary proxy. He admitted "this all feels a bit icky to me - but I can't think of a nicer way of doing this which doesn't require the cooperation of the authors of every proxy-aware application."
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/>
[2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00159.html
 
[[NicolasChauvet|Nicolas 'kwizart' Chauvet]] had also thought about the problem and made[3] some changes to <code>libproxy</code> which he hoped would solve the problem. [[DanWinship|Dan Winship]] wrote[4] a great post explaining that <code>libproxy</code> could adaptively use whichever backend was appropriate for the environment in which it was used and although it was not widely used by applications it looked set to become an integral part of GNOME.
 
[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00098.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00185.html
 
After [[ColinWalters|Colin Walters]] commented[5] that he would like to "[...] see the desktop standardize around <code>libsoup</code>[6] , for two primary reasons: 1) Mainloop integration 2) Hopefully forthcoming support for reading Firefox cookies [...]" a minor flamewar erupted when [[JamesAntill|James Antill]] wondered "Why do "desktop people" keep proposing things that are _only_ acceptable in a monolithic desktop application?" with reference to the mainloop integration. This developed into a comparison[7] between future scenarios in which PackageKit overrode yum downloads in a desktop scenario versus the simplicity of using yum on the command line. James was scathing on the subject of ignoring actual users (whom he asserted prefer gnome-terminal) to "[...] 60+ year olds who don't, and are about to be a majority of our users RSN."
 
[5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00188.html
 
[6] libsoup is a GNOME client/server library for HTTP used in evolution, seahorse and rhythmbox among others and is integral to the OnlineDesktop.
 
[7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00201.html
 
=== Fedora 10 Early Branch Now Available ===
 
[[JesseKeating|Jesse Keating]] announced[1] on 2008-10-01 that it was now possible for developers wishing to concentrate on stabilization to branch their packages. A link to request a branch was provided. In response to [[JeroenvanMeeuwen|Jeroen van Meeuwen]] it was explained[2] that this was not mass-early-branching but was an attempt to satisfy two classes of maintainers: those that needed to continue future development and those that used the entire development cycle for the current release.


[1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00083.html
=== Russian Fedora ? ===


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


[[MichaelSchwendt|Michael Schwendt]] rejected[3] the idea as "[u]nconvincing and not helpful", citing increased bureaucracy as the main negative outcome and suggesting that a potential cascade of maintainers scrambling to branch and rebuild in response to early branches of dependencies would result.
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-October/msg00202.html
<references/>


=== SELinux - Copying ISO Files ===
=== Will FESCo Revisit Kmods ? ===


A paraliptic swipe at SELinux by [[JonMasters|Jon Masters]] asked[1] "[...] how is the *average* user supposed to [...] copy the content of /mnt over to e.g. /somewhere/fedora/9/i386 for NFS installs [?]" [[DanWalsh|Dan Walsh]] was surprised[2] and responded "Why would the copy fail? cp should just work and set the files to the context of the destination directory. If this fails it is a bug." Jon conceded[3] that there was a bug and segued into a mini-rant on SELinux.
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]].


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


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


[3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg00203.html
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===


[[JesseKeating|Jesse Keating]] offered[4]: "The average user double clicks on the iso in Nautilus, which mounts it for them. Then they click/drag the fileset to where they want it and Nautilus copies it for them."  
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."


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