From Fedora Project Wiki

< FWN‎ | Beats
 
(74 intermediate revisions by the same user not shown)
Line 5: Line 5:
mailing list are summarized.
mailing list are summarized.


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


=== Python Bump to 2.6 in Rawhide ===
=== Would You Like to Write This Beat ? ===


The success of Fedora's dogged persistence in pursuing an "upstream all possible patches" methodology was anecdotally highlighted during a thread in which [[User:ivazquez|Ignacio Vazquez-Abrams]] warned that all Python packages in rawhide would soon be affected. An apology was made[1] by Ignacio for a dramatic subject-line ("It's all ASPLODY!), but he explained that "[w]ithin the next few days Python 2.6 will be imported into Rawhide. This means that EVERY single Python-based package in Rawhide will be broken, and that we'll need to slog our way through rebuilding it package by package." Ignacio suggested that the list of approximately seven hundred packages could be examined with a:
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.
<pre>
repoquery --disablerepo=\* --enablerepo={development,rawhide} \
  --whatrequires "python(abi)" | sort | less
</pre>
Ignacio expressed[2] willingness to trigger the rebuilds for some of the packages but "[...] there's no way I can get [700] done in a timely fashion."


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


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


[[VilleSkyttä|Ville Skyttä]] asked[3] "[i]f a package installs some *.py, *.pyc, *.pyo somewhere else than in versioned python dirs, and the source *.py is python 2.6 compatible, will the *.pyc and *.pyo compiled with 2.5 break with 2.6?" Ignacio confirmed[4] that such packages should not need to be recompiled as the API had not changed beween versions 2.5 and 2.6.
[[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-November/msg01826.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-November/msg01837.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. 


[[TomCallaway|Tom 'spot' Callaway]] suggested[5] using a separate <code>Koji</code> tag so that Ignacio could use a process similar to that which Tom had employed for the transition from <code>PERL-5.8</code> to <code>PERL-5.10</code>. [[JeremyKatz|Jeremy Katz]] remembered[6] that such tagging had been used for past bumping of <code>Python</code> and suggested "It's good to at least get the stack up through yum and friends building and working before thrusting the new python upon everyone as otherwise it's quite difficult for people to even try to fix things on their own." A list of the essential packages was made[7] by [[SethVidal|Seth Vidal]] and [[KonstantinRyabitsev|Konstantin Ryabitsev]].
<references/>


[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01823.html
=== Chrome9 Vx800 Graphics Support on LiveUSB ===


[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01815.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-November/msg01820.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.


On the foot of some skeptical questions from [[LesMikesell|Les Mikesell]] Tom reported[8] that the end result of following such a process for <code>PERL</code> was that "[Fedora is] closer to perl upstream than we've ever been, and we have most of the long-standing perl bugs resolved (and we fixed the "RHEL slow perl" bug without even being aware of it as a byproduct of the methodology). The fact that you just noticed it means that we must have done some things properly, you're welcome. :)"
<references/>


[8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01839.html
=== Who Wants a Pony? ===


On 28-11-2008 Ignacio reported[9] that "[...] we're going to go ahead and commit 2.6 to Rawhide and start the rebuild of all Python packages in Rawhide. So please keep your hands off any packages that require python(abi) until we're done. Or if you like, you can help out by bumping the release and building against the dist-f11-python tag." He later explained[10] that python-2.6 would appear in rawhide "[...] within 10 days if all goes well. Then releng will need to fold the tag back into f11-dist" and confirmed[11] that the version in <code>Fedora 11</code> will be <code>Python-2.6</code>.
[[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.


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


[10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02130.html
=== Firestarter Retired as Unportable to PolicyKit ===


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


On 30-11-2008 Ignacio posted[12] the results of the "first cycle of rebuilds" and categorized the failures into several convenient classes. On 01-12- 2008 Ignacio posted the results of round two which he explained[13][14] were "a set of packages that a different net caught. I used python(abi)=2.5 for the first set in order to get the low-level packages, and this one uses libpython2.5.so.1.0." The latest follow-up, on 01-12-2008 consisted[15] of the list of packages which "[...] contain compiled Python code but do not have a Requires of python(abi). Please note that this is a packaging bug as the bytecode is specific to the version of the Python it was compiled with. Whether this is a problem with rpm's macros or with the package itself must be dealt with on a case-by-case basis."
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/>


[12] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02201.html
=== Russian Fedora ? ===


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


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


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


=== Power Management and Filesystem Parameters ===
=== Will FESCo Revisit Kmods ? ===


A series of three disk-power management proposals were published[1] as an RFC by [[MatthewGarrett|Matthew Garrett]]. They were generally well-received and discussion was mostly focused on ways to instrument the kernel to measure any resulting changes and to ensure that disk lifetimes are monitored carefully.
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-November/msg02047.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>.


The first, least controversial, proposal is to get [[IngoMolnar|Ingo Molnar's]] <code>relatime</code> patch upstream. An extensive discussion in LWN[2] explains that this allows applications to keep track of when files have been read without having to constantly update the last file access time, thus reducing the number of writes to the disk.
<references/>


[2] http://www.lwn.net/Articles/244829/
=== Upgrade from Fedora 10 to Rawhide (Fedora 11) ===


Matthew's second proposal was to "[...] increase the value of dirty_writeback_centisecs. This will result in dirty data spending more time in memory before being pushed out to disk. This is probably more controversial. The effect of this is that a power interruption will potentially result in more data being lost." The third proposal was to enable laptop-mode[3] by default in order to mitigate the second change.
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."


[3] cat /usr/share/doc/kernel-doc-2.6.27.5/Documentation/laptops/laptop-mode.txt
<references/>
 
EricSandeen was interested[4] in how Matthew would measure the effects on power and performance, whether it was possible to identify individual applications causing disk accesses, and whether disk spin-down should be considered. When Matthew replied[5] that it would be difficult to monitor disk access without causing further disk access [[DavidWoodhouse|David Woodhouse]] suggested using <code>blktrace</code> and this was eagerly recognized[6] by Matthew as exactly what he needed.
 
[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02048.html
 
[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02052.html
 
[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02093.html
 
Eric's spin-down suggestion was confirmed: "Yes, the long-term plan involves allowing drive spindown. I'm hoping to do this adaptively to let us avoid the spinup/down tendancies a static timeout provides, but you're right that monitoring SMART information would be a pretty important part of that. I lean towards offering it on desktops and servers, but not enabled by default."
 
[[PhilKnirsch|Phil Knirsch]] posted[7] that he was working on similar ideas currently including "the idea if a combination of a monitoring backend and a tuning engine could provide an automatic adoption of the system to the current use. E.g. during daytime when a user works with his machine we would typically see quite a few reads and write all the time. Drive spindowns or other power saving features could during that time be reduced so that the user will have the best performance. During the night (in case he didn't turn of the machine) only very few read and even fewer write operations should happen, at which time the disk could then be powered down most of the time. And of course this can be extended to not only disk drives but other tunable hardware components."
 
[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02089.html
 
Some of the pitfalls of choosing defaults for all users were exposed when [[RalfErtzinger|Ralf Ertzinger]] and Phil disagreed[8] on the ideal behavior of logging mechanisms.  Phil drew a distinction between system logging mechanisms and user application logs and argued that losing data from the latter was not as important. [[DariuszGarbowski|Dariusz Garbowski]] put[9] the point of view of "Joe the User": "He cares a lot that he lost last hour of his xchat (or whatever he uses) logs. He quite likely doesn't care about last hour of syslog messages (he may not even be aware they exist in the first place)..."
 
[8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02099.html
 
[9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02137.html
 
See FWN#88[10],FWN#100[11][12] for previous discussion of power-management in Fedora.
 
[10] https://fedoraproject.org/wiki/FWN/Issue88#PowerTOP_Release_Opens_Up_New_Directions_In_Power_Saving
 
[11] http://fedoraproject.org/wiki/FWN/Issue100#Disabling_Atime
 
[12] http://fedoraproject.org/wiki/FWN/Issue100#Reducing_Power_Usage_Of_Fedora
 
=== Strange Resolution Problems ===
 
A report of a strange name resolution problem was made[1] by [[MarkBidewell|Mark Bidewell]].  <code>Yum</code> failed to download the Adobe flash-plugin with an error: <code>[Errno 4] IOError: <urlopen error (-2, 'Name or service not known')> Trying other mirror.</code>" , yet it was possible to download it directly over HTTP using the browser.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02002.html
 
[[ChristianIseli|Christian Iseli]] added[2] that he had a similar "[...] issue which seems to be due to some sort of DNS lookup problem. In my case I'd get the 'Name or service not known' for download1.rpmfusion.org." Christian's troubleshooting revealed that specific sites (linuxdownload.adobe.com and download1.rpmfusion.org) were consistently resolved with <code>ping</code> or <code>firefox</code> but failed with <code>wget</code> and <code>ssh</code>. Moreover: "Putting the IP addresses in /etc/hosts "works around" the problem[.]"
 
[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02071.html
 
Following some questions from [[SethVidal|Seth Vidal]] nothing seemed[3] obviously wrong and the mystery remains.
 
[3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02082.html
 
=== Cron Confusion ===
 
[[PavelAlexeev|Pavel Alexeev]] asked[1] for guidance on how to correctly rpm package a <code>cron</code> job. The specific requirement was a <code>cronjob</code> that ran every twenty minutes and might thus use the <code>/etc/cron.d</code> directory provided by <code>cronie</code> ,the <code>SELinux</code> and <code>PAM</code> aware derivative of vixie cron. Pavel wondered how he could make a package which would work for both variants of <code>cron</code>.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02179.html
 
When [[MartinLanghoff|Martin Langhoff]] confirmed that <code>/etc/cron.d</code> was necessary Pavel replied[2]: "[...] /etc/cron.d [is] provided only by cronie [and] now we have several other crons in the repositories[.]" He listed several other implementations of <code>cron</code> found by a
<pre>
# repoquery '*cron*' | egrep -v '^(yum-cron|PackageKit-cron|cronolog)'
</pre>
 
[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02182.html
 
[[User:ivazquez|Ignacio Vazquez-Abrams]] corrected[3] him: "The only replacement for cronie in that list is fcron. Feel free to log a bug against it." [[TillMaas|Till Maas]] and Pavel noted[4], however, that the <code>/etc/cron.*</code> directories were also provided by the package named <code>crontabs</code>.
 
[3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02183.html
 
[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02187.html
 
[[PatriceDumas|Patrice Dumas]] posted[5] the welcome news that he was "[...] currently preparing a fcron sub-package that would be completly compatible with cronie and would watch /etc/cron.d (using inotifywait). I'll keep the list informed."
 
[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02187.html
 
=== Man Pages to be Mandatory and Upstreamed ===
 
A vigorous thread flowered from the promising seed planted[1] by [[MichaelCronenworth|Michael Cronenworth]] in which he advocated getting rid of all current documentation: "Yes, what I'm about to describe should obsolete man, info, and all the other dozen "help" documentation found in all the Fedora packages." Michael proposed that a new, lightweight standard of some sort would solve the problem of missing documentation.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02015.html
 
During the course of the week there have been requests for "NetworkManager cli docs"[2] and "PulseAudio info needed"[3] in which the desired information has mostly been found on external web pages instead of in documentation supplied with the OS.
 
[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01757.html
 
[3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02041.html
 
[[RichardJones|Richard W. M. Jones]] suggested[4] instead that the Debian model should be followed: "Debian forces all programs to come with a man page. If one is missing, this is considered a bug and packagers have to write one." [[PatriceDumas|Patrice Dumas]] was[5] against compulsion and preferred leaving the choice to the packager.
 
[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02023.html
 
[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02025.html
 
The idea of upstreaming the man pages was introduced[6] by [[ThorstenLeemhuis|Thorsten Leemhuis]]: "One reason for that: If you add man pages from debian to a fedora package then you have to recheck every now and then if the man pages are still up2date. That afaics often tends to be forgotten (I'm guilty myself here)." Richard agreed[7] and in the course of several clarifications made the strong point that "[...] it's a really useful feature of Debian that _any_ command, any many configuration files and other files, are documented using 'man'. I find it a big negative against Fedora that things aren't so consistently documented."
 
[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02024.html
 
[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02050.html
 
There seemed to be little disagreement on the desirability of providing more information but Michael was not impressed[8] with [[TrondDanielsen|Trond Danielsen's]] suggestion that yelp would fulfill his requirements: "[...] it lacks in the lightweight department. It eats 40 megs of RAM upon startup and more RAM once searching occurs or pages are opened. Sure, we're all getting gigabytes of RAM these days, but it's a HELP tool with TEXT." [[BasilMohamedGohar|Basil Mohamed Gohar]] was inspired[9] to "[write] or two man pages, because I've run into the missing-man-page problem too often." He suggested a very reasonable sounding action plan for identifying missing man pages and then filling them in with at least stubs in order to form a SIG which would work on providing quality replacements. [[GergelyBuday|Gergely Buday]] also seemed[10] interested.
 
[8] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00004.html
 
[9] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00023.html
 
[10] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00060.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"