|
|
| (82 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]] |
|
| |
|
| === Security Exceptions to the Mass ACL Opening === | | === Would You Like to Write This Beat ? === |
|
| |
|
| [[MichaelDeHaan|MichaelDeHaan]] initiated[1] discussion on why he had chosen not to open access (previously covered in FWN#148[2], FWN#136[3]) on some of his systems management software packages. His main reasoning was that obtaining provenpackager[4] status was too easy and could lead to at least two undesirable security outcomes: "(A) provenpackager decides to correct what he thinks is an rpmlint error and thus unintentionally breaks the security of the packaged application, (B) credentials of provenpackager are compromised allowing $evil to replace the contents of a said package. In either case, the change could either be making a new release of an application (which contains an exploit and/or unwitting bug), or updating the specfile in a way that breaks file permissions in a way that may not be immediately obvious (whether intentional or not)." The packages omitted by Michael were <code>koan</code>, <code>cobbler</code>, <code>func</code> and <code>certmaster</code> all of which could, if compromised, "[...] allow reprogramming of an entire datacenter in very easy steps."
| | 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-November/msg00382.html
| | <references/> |
|
| |
|
| [2] http://fedoraproject.org/wiki/FWN/Issue148#The_Big_ACL_Opening
| | === Is gNaughty a Hot Babe ? === |
|
| |
|
| [3] http://fedoraproject.org/wiki/FWN/Issue136#New_libraw1394_Rebuild_Exposes_Closed_ACLs | | [[User:Sundaram|Rahul Sundaram]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02071.html</ref> the results of a survey conducted, primarily on @fedora-list and on the forums, to discover which non-repository-packaged software Fedora consumers were using. |
|
| |
|
| [4] After a flamewar (see FWN#148 "PackageGurus, SpecMentats or UeberPackagers?") the group name for packagers with access to any package in CVS is provenpackager: https://fedorahosted.org/packagedb/browser/fedora-packagedb-stable/ChangeLog#L45
| | 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?" |
|
| |
|
| [[ToshioKuratomi|Toshio Kuratomi]] shared[5] Michael's concerns but pointed out that it would be possible to introduce compromised code into his packages' dependencies: "I'd like to mention, though, that func depends on the following packages with open acls: pyOpenSSL, python, python-simplejson So in terms of protecting against $EVIL, restricting provenpackager isn't very effective." | | 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-November/msg00384.html
| | <references/> |
|
| |
|
| [[DanielBerrange|Daniel Berrange]] thought[6] it would be more effective to have more co-maintainers: "The ideal should be for every package in the distro to have at least 1 extra comaintainer, or preferrably 3 or 4. People with a little domain knowledge for the package who can handle both the low-hanging fruit the main maintainer misses, with less risk of making mistakes due to lack of package specific knowledge." Toshio countered[7] with a detailed reply which investigated the problems of non-responsiveness and trust which would be encountered by such a change. [[MichaelSchwendt|Michael Schwendt]] added[8] his experiences of the practical problems involving non-responsive maintainers and the difficulty of informing people without overloading them.
| | === Chrome9 Vx800 Graphics Support on LiveUSB === |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00387.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/msg00392.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-November/msg00405.html
| | <references/> |
|
| |
|
| [[JesseKeating|Jesse Keating]] returned[9] to the main topic and remarked that he agreed with [[MichaelDeHaan|Michael DeHaan's]] logic with regard to these specific packages but that membership of "provenpackagers" was now obtainable by requesting membership via the account system and approval of said request by a provenpackager. The requirement to have at least five packages was merely for initial seeding.
| | === Who Wants a Pony? === |
|
| |
|
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00385.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. |
|
| |
|
| [[TimLauridsen|Tim Lauridsen]] wondered[10] when co-maintainers would be enabled to submit updates to packages through <code>bodhi</code> and subsequent discussion with [[MichaelSchwendt|Michael Schwendt]] suggested that it should be possible. [[KevinKofler|Kevin Kofler]] had similar concerns and Michael shared[11] the last public information on the topic which was that anyone with commit access to the devel branch can submit updates.
| | <references/> |
|
| |
|
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00407.html
| | === Firestarter Retired as Unportable to PolicyKit === |
|
| |
|
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00411.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>. |
|
| |
|
| === Who Moved My Bug ? ===
| | 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/> |
|
| |
|
| [[DebarshiRay|Debarshi Ray's]] question sounded[1] alluringly like a parody of a self-help book but expressed genuine concern over why the status of bugs assigned to him were being changed. [[TillMaas|Till Maas]] reassured[2] Debarshi that the status ASSIGNED means "that the bug has been triaged, i.e. it is assigned to the rigth component and all necessary information is provided. A member of the Fedora Triage Team probably did the changes to your bugs [,]" he included a useful link[3] to the BugZappers wikipage. [[BrynReeves|Bryn Reeves]] explained[4] how to see every change made to a bug. [[JohnPoelstra|John Poelstra]] also suggested[5] using the "history" link and explained that the use of the "FutureFeature" keyword was to insure that bugs would continue to be given the version "rawhide" even after the GA release of <code>Fedora 10</code>.
| | === Russian Fedora ? === |
|
| |
|
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00273.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. |
|
| |
|
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00274.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]]. |
|
| |
|
| [3] https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
| | <references/> |
|
| |
|
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00279.html
| | === Will FESCo Revisit Kmods ? === |
|
| |
|
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00290.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]]. |
|
| |
|
| It appeared[6] that this was a different process to that used to handle package review submissions and this had difference had caused some confusion. Confusion also reigned[7] about when this use of the ASSIGNED keyword had become standard and [[DominikMierzejewski|Dominik Mierzejewski]] argued[8] that it had not been approved by FESCo, but [[BrianPepple|Brian Pepple]] posted the FESCo logs and [[JesseKeating|Jesse Keating]] suggested[9] following the discussions on @fedora-devel. Dominik declined to rely on following such a high-volume list and [[SteveGrubb|Steve Grubb]] agreed[10].
| | [[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>. |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00325.html
| | <references/> |
|
| |
|
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00285.html
| | === Upgrade from Fedora 10 to Rawhide (Fedora 11) === |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00285.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." |
|
| |
|
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00310.html
| | <references/> |
| | |
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00420.html
| |
|
| |
| [[KevinKofler|Kevin Kofler]] added[11] some useful information for those working in teams: "[...] when you're actively working on fixing something (so you don't duplicate work in the team), you can use the ON_DEV status for that purpose."
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00283.html
| |
| | |
| === HOWTO: Get an SELinux Policy Change ===
| |
| | |
| [[JerryJames|Jerry James]] requested[1] information on how to get the correct security context in place for the <code>GCL</code> binaries which he was packaging. He needed to know both whether it was acceptable to use a <code>chcon -t java_exec_t</code> within the Makefile and how to have this reflected explicitly in Fedora policy.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00259.html
| |
| | |
| [[HansdeGoede|Hans de Goede]] suggested[2] filing a bug against <code>selinux-policy</code> as [[DanWalsh|Dan Walsh]] was "[...] usually very fast and correct in fixing issues like this one." Dan posted that Jerry could get the final destination of the file with a <code>chcon `matchpathcon -n /usr/bin/gcl` LOCALPATH/gcl</code>.
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00261.html
| |
| | |
| [[JochenSchmitt|Jochen Schmitt]] suggested[3] that Jerry create a <code>SELinux</code> module to fix the issue and then actually did it himself and shared[4] it with the list, which impressed Jerry.
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00289.html
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00294.html
| |
| | |
| The problem evolved[5] to be a little deeper than modifying the Makefile as Jerry explained[6]: "I need a non-default security context for binaries that are both built and executed in the %build script, when the policy module has not yet been installed. It appears to me that there are only two ways to accomplish this: keep abusing java_exec_t like I have been, or get a GCL policy incorporated into selinux-policy* prior to building GCL. Am I wrong?" After [[PaulHowarth|Paul Howarth]] pointed out that <code>selinux-policy</code> needed to provide a context type for <code>/usr/bin/gcl</code> Dan modified[7] his previous <code>matchpathcon</code> suggestion and advised that this would be provided in <code>selinux-policy-3.5.13-19.fc10</code>.
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00307.html
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00350.html
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00367.html
| |
| | |
| === Comps Czar Appointed to Encourage Modifications ===
| |
| | |
| An important decision made[1] by FESCo in its 2008-10-29 deliberations was to try and encourage further modification of <code>comps.xml</code>[2] by defining some clearer procedures. These included the appointment of [[BillNottingham|Bill Nottingham]] as a "Grand Arbitrator of Comps" to decide which packages should be included in comps. The main concern expressed during the deliberation was that packagers tended not to modify comps and that awareness of its purpose had not been clearly communicated. It was hoped that extending the wiki page[3] and making one person formally responsible would help. Currently there are filters in place and only those with uberpackager status can commit changes. [[JesseKeating|Jesse Keating]] (f13) wanted to "[...] rather correct bad behavior than prevent good behavior [.]"
| |
| | |
| [1] http://bpepple.fedorapeople.org/fesco/FESCo-2008-10-29.html
| |
| | |
| [2] Comps is an XML file which is used by anaconda (the installer) to present groups of available packages for selection by the administrator during the installation of a new operating system. See: https://fedoraproject.org/wiki/PackageMaintainers/CompsXml
| |
| | |
| [3] https://fedoraproject.org/wiki/PackageMaintainers/CompsXml
| |
| | |
| One worry was to ensure that not everything is added to comps as this would produce an unreadable, large list. This latter problem was foregrounded when [[ChristopherStone|Christopher Stone]] advocated[4] that "[a]ll packages should go in comps. I don't know why notting is against this?!!? Why should my php-pear-* packages be excluded from comps for example? Just because some newb might not want to install them does not mean a php web developer would not use comps to install them." [[MattMiller|Matt Miller]] explained[5] that the current scheme was inflexible: "If comps ends up with a thousand programs under Games and Entertainment, another thousand under Graphical Internet, etc., it's even more useless than having nothing in comps at all. What would be the point? On the other hand, having a thousand small comps groups is also no good."
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00098.html
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00120.html
| |
| | |
| [[SethVidal|Seth Vidal]] and [[ToshioKuratomi|Toshio Kuratomi]] seemed[6] interested in the idea of allowing Flickr-like tagging of package as a replacement for the problem of assigning them to groups. [[DenisLeroy|Denis Leroy]] also suggested[7] such a system: "Comps evolved over time into something that doesn't make a whole bunch of sense to me. Is the main use of comps still for installation groups within yum and anaconda ? A lot of packages are not installation "targets" but simply libraries that should only be installed by being pulled in from dependency resolution. Now if we're trying to "categorize" all packages nonetheless, it'd be better to have a tagbased system from packagedb, where packages can be "tagged" a-la-gmail, and also belong into multiple tag groups as some things really belong into multiple categories..."
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00134.html
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00107.html
| |
| | |
| [[NicolasMailhot|Nicolas Mailhot]] listed[8][9] the advantages of the current format of comps as: human-editable, version-controllable, diff-able, grep-able, platform-agnostic and scalable. Toshio leaned[10] towards having tag information stored in <code>packagedb</code> which could generate static "[...] separate files for the installer and general use (so that the installer isn't sprinkled with thousands of libraries but one could still use yum to search for "all packages that have a 'python' 'library' to do 'ssl'")."
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00108.html
| |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00158.html
| |
| | |
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00122.html
| |
| | |
| In another post Nicolas raised[11] another series of pertinent questions which included thinking about other repositories and alternate views of any data which might shoehorned into a particular model. [[BillNottingham|Bill Nottingham]] wondered[12] where Nicolas was going with all this and re-capped the current purpose of comps as both an input to a graphical package selector and an input to tree composition tools. The discussion with Bill revealed that Nicolas advocated[13] "[...] just add everything in comps and run basic scripts that check every package we ship appears there (say in a dev-null group for libs or such stuff). You can easily cull the dev-null group at comps.xml.in -> comps.xml stage if needed" in order to ease the QA burden.
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00125.html
| |
| | |
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00165.html
| |
| | |
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00226.html
| |
| | |
| [[JeremyKatz|Jeremy Katz]] wondered[14] who was the audience and task for [[SethVidal|Seth Vidal's]] "tree hierarchy plus tags" interface and distinguished between users looking for an application and administrators installing a system. Seth suggested[15] that using kickstart to install a minimal base and then the desired packages was the appropriate solution for the latter problem. He later explained[16] that having a tag-based presentation of the packages online would make it easier to determine which packages were available. [[LesMikesell|Les Mikesell]] wished to reproduce specific machine configurations easily which led[17] Seth to suggest using <code>yum-groups-manager</code> to create a comps.xml file and then <code>createrepo -g that_comps.xml somedir</code> which produces "[...] a repository that ONLY has comps.xml in it that is then instantly usable by any site which can get to the baseurl where it lives."
| |
| | |
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00147.html
| |
| | |
| [15] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00148.html
| |
| | |
| [16] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00150.html
| |
| | |
| [17] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00152.html
| |
| | |
| === LiveConnect Feature Approved for Fedora 10 ===
| |
| | |
| FESCo's 2008-10-29 discussions[1] contained a decision to include the LiveConnect[2] feature in Fedora 10. LiveConnect is a way for web browsers to allow JavaScript and Java classes to call each other's methods. The project to develop a completely FLOSS implementation was initiated[3] by [[TomFitzsimmons|Tom Fitzsimmons]] and brought to completion by [[DeepakBhole|Deepak Bhole]]. Tom's work[4] on a rewrite of <code>gcjwebplugin</code> as an XPCOM plugin has been named <code>IcedTeaPlugin</code> and is the default in <code>IcedTea6</code>.
| |
| | |
| [1] http://bpepple.fedorapeople.org/fesco/FESCo-2008-10-29.html
| |
| | |
| [2] http://fedoraproject.org/wiki/Features/Liveconnect
| |
| | |
| [3] http://people.redhat.com/fitzsim/fosdem-2008/fosdem-2008-liveconnect.pdf
| |
| | |
| [4] http://fitzsim.org/blog/?p=23
| |
| | |
| The practical implications for end users are that many popular sites[5][6] are now usable without the problems associated with the installation of Sun Microsystems' non-FLOSS Java plugin.
| |
| | |
| [5] http://www.jigzone.com/
| |
| | |
| [6] http://games.yahoo.com/
| |
| | |
| There was[7] some agonizing over the problem that <code>LiveConnect</code> was being approved as a Feature post freeze date while other exciting projects had been dropped because they were not complete at that time. [[BrianPepple|Brian Pepple]] worried: "Those folks we booted since they weren't complete would be justified in being pissed about us." Although this seemed to be a non-controversial opinion Deepak's work was also felt to be very important and fully tested. In addition Deepak submitted that "[...] no new packages introduced for this feature. Just an update to an existing package, that now installs a different Java plugin."
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00097.html
| |
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."
