|
|
| (110 intermediate revisions by 2 users not shown) |
| Line 5: |
Line 5: |
| mailing list are summarized. | | mailing list are summarized. |
|
| |
|
| Contributing Writer: [[:User:OisinFeeley|Oisin Feeley]] | | Contributing Writer: [[User:Ush|Oisin Feeley]] |
|
| |
|
| === Solving the Unsynchronized Release of Package Dependencies === | | === Would You Like to Write This Beat ? === |
|
| |
|
| A problem often experienced by users of "add-on" packages[1] is that dependency resolution will fail during a simple <code>yum update</code> when the official Fedora repositories release an update to the base packages on which these add-ons depend. ThorstenLeemhuis explained[2] that as add-on packages have a strict dependency on the base packages for which they were built and updates are not available at exactly the same time on all mirrors there is no ideal point in time for the add-on to be released. Thorsten's RFC was careful to point out that the problem did not only affect ''kmods'', but also plugins for ''audacious'', ''xine'' and ''k3b'' and that the resulting dependency resolution failures occurred both when the add-on was visible to ''yum'' before the base package and vice versa. The two possible solutions envisioned by Thorsten included either ''yum'' being modified "to be taught to do a second look at the right place to find what's needed" or the third-party repositories to include the updated base packages along with the updated add-on. Thorsten feared that this latter option of "shipping non-free kernel modules and the GPLed kernels in one repo might [make] some people yell license violation."
| | 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] Such packages are hosted by "third-party" repositories, which are run independently of the Fedora Project. The packages, while highly useful for many Fedora users, are deemed to be legally non-distributable due to the laws of the U.S.A.
| | <references/> |
|
| |
|
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html
| | === Is gNaughty a Hot Babe ? === |
|
| |
|
| A report of daily failures of this type occurring for Rawhide without any complicating third-party repository was posted[3] by [[JohnEllson|John Ellson]]. He gave two examples from his current machine. The first was a missing dependency error:
| | [[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. |
|
| |
|
| <pre>$ yum update phonon* | | 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?" |
| Error: Missing Dependency: phonon = 4.2.0-1.fc10 is needed by package phonon-backend-gstreamer-4.2.0-1.fc10.x86.64 (installed)
| |
| </pre> | |
|
| |
|
| and the second was a file conflict error: | | 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. |
|
| |
|
| <pre>$ yum update digikam* | | <references/> |
| Transaction Check Error: file /usr/share/icons/oxygen/128x128/apps/digikam.png from install of digikam-0.10.0-0.1.beta2.fc10.x86.64 conflicts with file from package oxygen-icon-theme-4.1.0-1.fc10.noarch
| |
| </pre>
| |
|
| |
|
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00044.html
| | === Chrome9 Vx800 Graphics Support on LiveUSB === |
|
| |
|
| John wished that ''yum'' would skip updating all rpms which produce conflicts with currently installed rpms whether or not they are third-party or otherwise, especially as neither of these issues had been flagged in the appropriately dated "Rawhide report". A good deal of the remainder of thread was devoted to replying to this post instead of to Thorsten's RFC. The first response came[4] from MichaelSchwendt and made the point that the first error was probably due to an incorrect "Obsoletes" tag in the !code?phonon-backend-gst!/code? that is supposed to replace <code>phonon-backend-gstreamer</code>. The script which checks for broken dependencies in Rawhide cannot detect this as the <code>phonon-backend-gstreamer</code> is not visible to it. Michael addressed the second error with the point that conflicts are entirely different from dependency issues and are not checked. RexDieter, as package maintainer, quickly fixed both of the problems and in doing so demonstrated that users filing bug reports can be an effective part of the current process. Thorsten also emphasized[5] that the two errors posted by JohnEllson were entirely different from each other and that the conflict was a bug best dealt with by user reports. He further argued that it was impossible for the Rawhide dependency checker script to examine the contents of users' hard disks. All that the script can do is examine the current contents of Rawhide and as the <code>phonon-backend-gstreamer</code> was long gone it could not test a theoretical update from it. [[MichaelSchwendt|Michael Schwendt]] later added[6] that although his own "repoclosure" script developed for the old "Extras" repository had been able to take account of "obsolete binary [packages] from the previous compose [...] because in Extras we've had up to two pkg releases in the repo[sitory ...] the Rawhide report is like a fresh install of only the latest [package] releases, and one can only hope that there are enough testers who find and report the additional update/upgrade problems." Michael claimed[7] that as the FedoraProject policy on file conflicts was "half-hearted" he was uninterested in shouldering the burden of running the script himself. He also noted that [[FlorianLaRoche|Florian La Roche]] had a script for determining conflicts between files and symlinks.
| | [[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?" |
|
| |
|
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00045.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. |
|
| |
|
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00046.html
| | <references/> |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00097.html
| | === Who Wants a Pony? === |
|
| |
|
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00048.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. |
|
| |
|
| During this discussion JohnEllson was unimpressed[8] with the theoretical reasons as to why he was seeing these problems and requested that even if it were not possible to do such checks on the server "[j]ust have yum on the client recover gracefully from these and skip over them."
| | <references/> |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00047.html
| | === Firestarter Retired as Unportable to PolicyKit === |
|
| |
|
| Similarly [[DavidTimms|David Timms]] wondered[9] if the original problem stated in the RFC could be solved by using the yum option <code>--skip-broken</code> if it were made to select only those packages which were: available, non-conflicting, non-dependency-breaking and actually downloadable.Thorsten restated[10] his belief that this was effectively hiding the problem instead of fixing it and would result in users being unaware that important updates were blocked solely due to a manually installed problem RPM. Instead he suggested setting a window of time during which updates with broken dependencies would be ignored and then finally reported as errors. [[SethVidal|Seth Vidal]] corrected[11] the impression that "skip broken" was a plugin to ''yum'' (it is now a core option) and while agreeing that "a tool to detect all these issues is worth discussing, not sure how we catch all possible conflicts, though" seemed to confuse Thorsten's window of time with checking the actual package creation filestamp. JesseKeating also appeared[12] to fall prey to this confusion and like Seth pointed out the problem of queued packages sitting in repositories before being released. To clear this confusion up Thorsten posted[13] a more detailed explanation which emphasized that the times being examined were relative to the client-side's first encountering of the problem and made no reference to the build-date or publication date of the package itself. The advantage of Thorsten's seventy-two hour window scheme is that it gives packagers a grace period in which to correct the problem and at the end of that the same situation prevails as now, namely that the update will fail and users will notice and report the errors.
| | [[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>. |
|
| |
|
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00049.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." |
| | |
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00099.html
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00150.html | |
| | |
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00153.html | |
| | |
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00154.html
| |
| | |
| === Firefox Mouse Woes ===
| |
| | |
| MarkG reported[1] that ''Firefox'' did not respond to the scroll wheel on GNU/Linux in the same way in which it did on Microsoft Windows. He had intended to file a bugzilla report, but due to the outage (see this same FWN#138 "Bugzilla Overhauled") was merely posting to @fedora-devel. The basic point made in what MarkG chose to frame as an RFC was that he expected the middle mouse button when clicked to allow him to scroll the page but that "[w]hen you press it on linux in firefox you get ... nothing[.]" He suggested that a simple change of the<code>firefox-fedora-default-prefs.js</code> to <code>pref("general.autoScroll", true);</code> by the Fedora maintainer would achieve this goal and noted that currently it is possible for a user to achieve the same end by navigating to the URI <code>about: config</code> and filtering <code>general.autoScroll</code> and changing its boolean to "true". MarkG also noted in support of his argument that "Ubuntu" had made such a change.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00053.html
| |
| | |
| A correction was made[2] by [[IgnacioVazquezAbrams--Ignacio Vazquez-Abrams]] to the effect that clicking the middle mouse button brought one to the "URL stored in the clipboard." He also pointed out that the environment in which the middle-click was made was important and that Firefox was doing the correct thing by following the Windows' environment preference of autoscrolling and the *nix environment preference of pasting from the clipboard. At this point the thread should probably have stopped but instead descended into a morass of personal preferences and insults. Nevertheless there were a couple of points worth noting.
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00054.html
| |
| | |
| [[NaheemZaffar--Naheem Zaffar]] thought[3] that while pasting was well and good it was not so nice to have the pasted URL automatically replacing the current page. [[RuiMiguelSilvaSeabra|Rui Miguel Silva Seabra]] provided[4] a fix for this with
| |
| | |
| <code>about:config -> browser.tabs.opentabfor.middleClick</code>.
| |
| | | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00108.html
| | 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/> |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00109.html
| |
| | |
| A type of closure to the thread was obtained when [[ToddZullinger|Todd Zullinger]] posted[5] that a likely result of making such changes would merely be to "get the opposite RFC from anyone who is used to the *nix behavior and wonders why Firefox is scrolling instead of pasting the clipboard contents as we'd expect. :)" and he speculated that "Ubuntu" had diverged from upstream. | |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00058.html
| |
| | |
| === Bugzilla Overhauled ===
| |
| | |
| As commented in several threads this week (e.g. this FWN#138 "Firefox Mouse Woes") Bugzilla was down for maintenance. This was due to upgrades of the OS on the servers and a move from the venerable ''bugzilla-2.18'' to ''bugzilla-3.2''. The original announcement[1] was posted on several lists and detailed the planned outage and the changes to ''bugzilla'' which included user-interface enhancements, AJAX optimizations for searching and displaying bugs and an XMLRPC API.
| |
| | |
| [1] http://www.mail-archive.com/fedora-announce-list@redhat.com/msg01372.html
| |
| | |
| The announcement and the reminder[2] that this would all happen on 2nd August requested that those using the API pointed their scripts to the test server https://partner-bugzilla.redhat.com to ensure that the new system was indeed backwards compatible.
| |
| | |
| [2] http://www.mail-archive.com/fedora-devel-announce@redhat.com/msg00194.html
| |
| | |
| A brief thread on @fedora-devel was started[3] when [[GilboaDavara|Gilboa Davara]] noticed that attempting to file a bug resulted in the JavaScript hanging and Firefox offering to retry or stop the script. This experience was confirmed by several other posters who noted that hitting "Continue" and waiting seemed to work. [[PaulFrields--Paul Frields]] speculated[4] that it was the population of the component list which was slow.
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00175.html
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00178.html
| |
| | |
| === Feature Proposal: Provers ===
| |
| | |
| An interesting proposal to include a bunch of tools for automated theorem proving was mooted[1] by [[User:dwheeler|David A. Wheeler]]. The bundle of tools, listed in David's post, would ease the task of increasing the reliability of software in some specific cases and are often used (see paper by David[2]) to perform assurance for safety and security on other programs. David argued that these tools, which are variously Formal Methods Tools, Key Provers and Solvers should be considered as a "Feature" for Fedora 10 as they needed some integration and had not previously been packaged for Fedora. Some of the methods enabled by these tools are being used by the OpenSuSE distribution to speed up dependency solving of RPM packages.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00263.html
| |
| | |
| [2] http://www.dwheeler.com/essays/high-assurance-Floss.html
| |
| | |
| [[User:JarodWilson|Jarod Wilson]] was uncertain[3] that the case for calling "just a collection of new packages" a Feature had been made. After further support from [[PatriceDumas|Patrice Dumas]], [[CaseyDahlin|Casey Dahlin]] and [[PaulFrields|Paul Frields]] an explanation was posted[4] by [[ToshioKuratomi|Toshio Kuratomi]] that the determination is made in part by the presentation of why and how some packages are useful to a hypothetical end user: "just saying Fedora has a collection of provers isn't a Feature. But saying, in Fedora 10 we've made an effort to include foo, bar, baz important provers for Target Audience so they can find all the tools they need to do X Type of Work. Similarly, `We've done work so that foo and bar can import and export the same file format', or other work to show how we're making the user experience better would make a stronger case for a feature." Similarly Jarod provided[5] links to the Fedora Project wiki to support his case that not enough had been done to explain why the programs were a cohesive collection dedicated to a particular end use case although he admitted "I suppose perhaps this falls under "noteworthy enough to call out in the release notes", depending on who you ask. I'm still not sold yet."
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00265.html
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00298.html
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00301.html
| |
| | |
| RahulSundaram wanted[6] a classification of packaging difficulty added as he had examined several on the package wishlist and found them "a large amount of pain to package." [[VasileGaburici|Vasile Gaburici]] suggested calling the packages "Theorem Proving Tools" in order to broaden the category a bit. He also suggested[7] including ''gap'' and ''twelf''. Suggestions to include other packages were forthcoming from [[MilesSavin|Miles Savin]] for ''Agda2'' and [[RichardJones|Richard Jones]] for ''CIL'', a C-parser and static-analysis tool. Richard included a link[8] to a nice analysis of ''libvirt'' performed with CIL. [[AndrewOverholt|Andrew Overholt]] noted[9] that ''sat4j'' was already packaged in Fedora.
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00264.html
| |
|
| |
|
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00267.html
| | === Russian Fedora ? === |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00288.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. |
|
| |
|
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00293.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]]. |
|
| |
|
| === rpmgrok Announced ===
| | <references/> |
|
| |
|
| Red Hat's [[DavidMalcolm|David Malcolm]] announced[1] ''rpmgrok'', a web-based tool to allow users to track program information across an entire distribution, yet without having a complete install tree. The tracked information includes all symbols in binaries, RPM manifests, shared objects, meta-information about rpms and more. He pointed interested parties to his test prototype[2].
| | === Will FESCo Revisit Kmods ? === |
|
| |
|
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00221.html | | A discussion of why <code>VirtualBox</code> will not be a feature due to its code not yet heading upstream and consequently remaining as <code>kmods</code> drew a statement of support from [[User:Kkofler|Kevin Kofler]] for reverting the current banning of <code>kmods</code> should he become a FESCo member. Upon request from [[RichardJones|Richard W.M. Jones]] for a dispassionate summary of the reasons to avoid <code>kmods</code> drew<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02254.html</ref> a concise response from [[User:Skvidal|Seth Vidal]]. |
|
| |
|
| [2] http://publictest7.fedoraproject.org/rpmgrok | | [[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>. |
|
| |
|
| All this information is obtained by analyzing the actually built rpms and storing the results in a database. David requested that anyone interested in coding, sysadmin and UI design get involved and provided a link to the ''git'' repository and the information that it was built upon ''TurboGears'' and ''SQLAlchemy''.
| | <references/> |
|
| |
|
| Enthusiasm for the "Errors and warnings from rpmlint" was expressed[3] by [[AxelThimm|Axel Thimm]] because he could imagine that someone that's say an expert on "invalid-desktopfile" issues could now dig into this much easier. Very nice!", but upon further feedback[4] from [[MamoruTasaka|Mamoru Tasaka]] and [[VilleSkyttä|Ville Skyttä]] it appeared that some work needed to be done to ensure that ''rpmlint'' was being used correctly. In any case this looks like a very promising and useful tool.
| | === Upgrade from Fedora 10 to Rawhide (Fedora 11) === |
|
| |
|
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00228.html | | 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-August/msg00242.html
| | <references/> |
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.
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.
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.
Who Wants a Pony?
Kushal Das promised[1] a pony to anyone that would take the trouble to review[2] one of his packages.
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.
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.
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.
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."
