From Fedora Project Wiki

< FWN‎ | Beats

m (add anchor)
 
(92 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]]


=== Default Deactivation of Services ===
=== Would You Like to Write This Beat ? ===


[[ChristophHoger|Christoph Höger]] initiated[1] this week's mammoth thread with a request to disable four services currently activated by default: <code>sendmail</code>, <code>ip6tables</code>, <code>isdn</code> and <code>setroubleshootd</code>. Christoph invited the list to "go on and punish me" after supplying some brief reasons for the deactivations.
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-September/msg02197.html
<references/>


Discussion mostly centered on the <code>sendmail</code> problem with suggestions ranging from starting it asynchronously and late, as suggested[2] by [[AlanCox|Alan Cox]], to replacing it with one of the "send-only" MTAs such as <code>ssmtp</code>. Part of the interest over this seemed to be stimulated by the information posted[3] by [[ColinWalters|Colin Walters]] that the "[...] desktop image no longer installs sendmail by default." This led to a need to distinguish between the desktop LiveCD and regular installs, as was done[4] by [[BillNottingham|Bill Nottingham]]. Some apparent legal threats posted by [[MatthewWoehlke|Matthew Woehlke]] led[5] [[SethVidal|Seth Vidal]] to point him to the nearest convenient exit. [[RalfErtzinger|Ralf Ertzinger]] noted[6] the deeply entrenched nature of <code>sendmail</code>: "Unfortunately, sendmail isn't just a program, it's an API. Calling /usr/lib/sendmail has been the way to get mail out (wherever out is) in UNIX for, well, as long as sendmail exists, which is quite some time."
=== Is gNaughty a Hot Babe ? ===


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


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


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


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


The problem of lack of local delivery with the proposed replacements was brought up[7] by [[PatriceDumas|Patrice Dumas]]. This was seen as a stumbling block because <code>cron</code> needs it and led [[JesseKeating|Jesse Keating]] to argue[8]: "[W]e shouldn't be using local delivery for this stuff. Instead we should ask in firstboot where you'd want the mail delivered to." [[MattMiller|Matt Miller]] replied[9] with a link to a bugzilla entry in which he had proposed just such a thing in 2004. Other aspects of the problem of disentangling potentially important log data from the mail delivery mechanism were touched[10] upon in other parts of the thread. Deep in the thread [[ArjanvandeVen|Arjan van de Ven]] pointed[11] to aliases generation as the reason for <code>sendmail</code> being slow to start up.
[[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-September/msg02246.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-September/msg02253.html
<references/>


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


[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02411.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-September/msg02217.html
<references/>


The complaint about <code>setroubleshootd</code> was addressed[12] by [[SteveGrubb|Steve Grubb]]. He explained that he had intended it to be a plugin to <code>audispd</code> it but had ended up being implemented as a standalone daemon by another author.
=== Firestarter Retired as Unportable to PolicyKit ===


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


<code>ip6tables</code> was defended on two fronts. On the first [[DanielBerrange|Daniel P. Berrange]] explained[13] how accessible IPv6 was and how likely it was that all machines on a network could automatically acquiring IPv6 addresses. Typical of the reaction on the other front [[GregoryMaxwell|Gregory Maxwell]] was startled[14] at the idea of being exposed without firewalling upon plugging into an IPv6 enabled network. He added the statistic that "About 4% of the web browsers hitting English language Wikipedia are IPv6 enabled. IPv6 enabled web clients may even become more numerous than Linux desktops this year, almost certainly by next year, so be careful what you call rare. :)" [[StephenSmoogen|Stephen John Smoogen]] also explained[15] that if there were no IPv6 firewall a <code>ping6 -I eth0 ff02::1</code> would enable an attacker to "walk the hosts with no firewalls." He suggested that completely disabling IPv6 would be preferable but might affect <code>IPsec</code> and related components.
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/>


[13] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02286.html
=== Russian Fedora ? ===


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


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


No one seemed particularly concerned at the idea of disabling <code>isdn</code> by default as it explicitly requires further configuration to be useful.
<references/>


=== specspo and PackageKit ===
=== Will FESCo Revisit Kmods ? ===


A quick query was posted[16] by [[RichardHughes|Richard Hughes]] asking whether <code>PackageKit</code> should dump its dependency on <code>specspo</code>[17]. The advantage would be a savings of 27Mb installed size and 6.9Mb download size. [[TimLauridsen|Tim Lauridsen]] was against a hard dependency and argued[18] that as <code>specspo</code> was part of the @base group it would be installed by default on a normal desktop and could then be used, whereas on the LiveCD its absence was desired due to the space constraints.
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]].


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


[17] "specspo" is the rpm package which contains all the portable object catalogues which provide translations for Fedora packages.
<references/>


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


An interesting discussion about alternate methods to provide translated package descriptions ensued when [[SethVidal|Seth Vidal]] suggested[19] that instead of using <code>specspo</code> "translating pkgs might best be served by translating the metadata in external files." In response to [[BillNottingham|Bill Nottingham's]] skepticism that this was just moving bloat to a new location Seth explained[20] that it would allow only the data specific to the requested language to be fetched. In a further explanation he provided[21] an overview of the ideal mechanism which would allow translations only for the language in use to be installed. This involved <code>yum</code> downloading translations from a language-segmented repodata and inserting those translations into the local <code>rpmdb</code>. A further reason to find an alternative to <code>specspo</code> was advanced[22] by [[StepanKaspal|Stepan Kaspal]] when he drew attention to its lack of friendliness to third-party repositories: "the specspo solution is not extensible at all; if you add a third part repository, the messages just are not there. And the repository cannot install another catalogue, rpm uses just 'the catalogue'."
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."


[19] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02058.html
<references/>
 
[20] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02125.html
 
[21] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02164.html
 
[22] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02160.html
 
[[BillNottingham|Bill Nottingham's]] objections seemed[23] to involve both the resource intensiveness of doing this during the composition of the repodata and also that "[...] this is all stuff that exists."
 
[23] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02165.html
 
=== Are Other Distros Controlling Fedora through PackageKit ? ===
 
A thread initiated[24] by [[ThorstenLeemhuis|Thorsten Leemhuis]] explored some details on how information on packages is created and stored at the distribution level and the challenges this presents both to independent repositories and to tools which wish to use this data. One heated aspect of this discussion concerned the manner in which the <code>PackageKit</code>[25] application installer defines and presents groupings of packages. <code>PackageKit</code> is designed to be a distribution-independent tool and it appeared to some in the discussion that its direction was inimical to the best release-engineering practices of the Fedora Project. The central issue appeared to be that <code>PackageKit</code> developers were not spending time helping to refine the <code>comps.xml</code> file which defines how packages are bundled during installation and is used by every other tool.
 
[24] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01813.html
 
[25] http://packagekit.org/pk-intro.html
 
Thorsten asked a series of questions about the correct use of <code>comps.xml</code> and how it interacted with <code>anaconda</code>, <code>PackageKit</code> and <code>yum</code>. Thorsten was concerned that there appeared to be 1711 packages missing from <code>comps.xml</code> in order that "[...] people can find and select them right during install with anaconda. Do we care?"
 
After some investigation with the latest <code>PackageKit</code>, which [[RahulSundaram|Rahul Sundaram]] pointed out[26] uses <code>comps.xml</code>, Thorsten deduced[27] in discussion with [[TimLauridsen|Tim Lauridsen]] that "[...] adding packages to a group in comps.xml as '<packagereq type="optional">' is only worth the trouble if you want to make the package selectable in anaconda, as that information is not used by pk-application." [[TimLauridsen|Tim Lauridsen]] explained[28] that <code>PackageKit</code> used the comps.xml groups as "meta-packages" but [[JamesAntill|James Antill]] disagreed[29] that they were similar.
 
[26] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01819.html
 
[27] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01861.html
 
[28] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01859.html
 
[29] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01889.html
 
[[AlexLancaster|Alex Lancaster]] agreed[30] with Thorsten's concern that many packagers were not using comps.xml and posted a link that showed that both he and [[ToshioKuratomi|Toshio Kuratomi]] had been thinking about using <code>PackageDB</code> to generate <code>comps.xml</code> for some time[31].
 
[30] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01893.html
 
[31] See also http://fedoraproject.org/wiki/FWN/Issue136#Application.Installer..22Amber.22.Provides.Browser.Interface.to.Packages and http://fedoraproject.org/wiki/FWN/Issue82#Presto.Server.Back.Up...Interesting..25doc.Behaviour..Presto.Now.in.Extras.21
 
In sustained discussion with [[KevinKofler|Kevin Kofler]] a defense of <code>PackageKit</code> was mounted[32] by [[RichardHughes|Richard Hughes]] using the argument that it was intended to be a compliment to <code>yum</code> rather than a replacement. Its intent is to occupy a very narrow niche for the specific type of user identified by "profiles" produced by the PackageKit developers.
 
[32] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02015.html
 
[[JamesAntill|James Antill]] had done[33] some investigation of the difference between how PackageKit and <code>yum</code> presented groups of packages and was not impressed: "In short it's arbitrarily different, hardcoded and just plain wrong. But hey, you've done "substantial user research" while we're just lowly developers, so feel free to keep ignoring us."
 
[33] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02008.html
 
The evolution of <code>comps.xml</code> to its current complexity was advanced[34] by [[NicolasMailhot|Nicolas Mailhot]] as the result of multiple constraints of engineering, maintenance and legality, he argued that "[i]t's always easy to present one-shot specialized solutions. The difficulty is scaling because separate maintenance of specialized overlapping package collections is not efficient). When you refuse to look at scaling problems you're missing the core of the problem."
 
[34] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02089.html
 
When it seemed that <code>PackageKit</code> was being designed[35] to take the needs of other distributions into account and that this might have a negative effect on Fedora there was a great deal of disapprobation expressed[36] by [[JesseKeating|Jesse Keating]]: "If I'd known that upstream was actively looking to destroy our package classifications, rather than actually work with us to clean them up a bit maybe I would have joined the conversation. A heads up might have been in order. I fear that any conversation now will just be too little too late." [[MatthiasClasen|Matthias Clasen]] characterized[37] this as Jesse being more interested in confrontation than making things better but [[NicolasMailhot|Nicolas Mailhot]] also saw[38] the decisions being made about <code>PackageKit</code>'s design as "non-representative" of developers focused on Fedora. Interestingly he tied this in with an observation on "[...] desktop team mislike for the common distro communication channel [.]" A slight rapprochement seemed[39] to be in effect towards the end of the thread as tempers cooled.
 
[35] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01957.html
 
[36] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01974.html
 
[37] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01976.html
 
[38] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02012.html
 
[39] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02022.html
 
The issue of binary packages (several of which can be produced from any single source package) was attacked when [[ToshioKuratomi|Toshio Kuratomi]] listed[40] <code>PackageDB</code>, <code>amber</code>, <code>koji</code>,<code>comps.xml</code>, <code>repoview</code> and <code>Fedora collection</code> as all "[...] doing a subset of the work in this area." He asked for some clarity as to the storage, interface and presentation layers. [[KevinFenzi|Kevin Fenzi]] agreed but added[41] <code>mash</code> as another player and suggested that perhaps all the developers of the respective systems could meet to hash out some agreed plan. [[JesseKeating|Jesse Keating]] confirmed[42] Kevin's description and elaborated: "it's mash that pulls comps out of cvs and 'makes' it and uses it when generating repodata. Mash is used during rawhide production and during update repo generation. When we make releases, that uses pungi which consumes the comps data that mash generated and merges in data from any other repo pungi is configured to use. Then pungi calls repoview to create data based on that merged comps."
 
[40] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01949.html
 
[41] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02182.html
 
[42] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02185.html
 
=== /sbin and /bin Linked to /usr/lib ===
 
[[SteveGrubb|Steve Grubb]] posted[43] the output from a utility which he had authored to check whether applications in the <code>/bin</code> and <code>/sbin</code> directories link against anything in the <code>/usr</code> directory. In the ensuing discussion [[BillCrawford|Bill Crawford]] suggested[44] that one of the listed applications, <code>/bin/rpm</code> was useful in its present location because of the "[...](admittedly quite odd situations) where you need to, say, reinstall grub or a kernel because you broke something[.]" He added that a "rescue" <code>initrd</code> would help for machines without optical drives.
 
[43] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02315.html
 
[44] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02458.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"