|
|
| (148 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| {{Anchor|Developments}} | | {{Anchor|Developments}} |
| | == Developments == |
|
| |
|
| === SELinux Eats Babies, Confines Wives, Gives Birth ===
| | In this section the people, personalities and debates on the @fedora-devel |
| | mailing list are summarized. |
|
| |
|
| JonMasters plunged[1] his head into the lion's mouth with a request to "re-add" the option to disable SELinux (or change to permissive mode) during or shortly after installation of the OS. His reasons included the apparent random breaking of currently working applications due to policy changes and the lack of support via gnome-vfs for relabeling of files to fix context problems. He finished off by claiming that "unsuspecting Desktop users" should not have something as complex as SELinux forced on them without an easy way to disable it.
| | Contributing Writer: [[User:Ush|Oisin Feeley]] |
|
| |
|
| 1. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00059.html
| | === Would You Like to Write This Beat ? === |
|
| |
|
| Jon's examples of stuff that broke included attempting to use an ISO in ''virtmanager'' and running vpnc. He was at pains to point out that he had been running SELinux in "enforcing" for a long time and that he was reporting these problems because he thought that average "Desktop" users would be unable to use ''chcon'' to fix them.
| | 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. |
|
| |
|
| Responses mostly emphasized that Jon was far from a typical user. SimoSorce argued[2] that, as a fellow developer, he had learned to expect labeling problems due to his non-standard usage and also how to fix them including changing policy for some of his commonly used packages. He noted that DanWalsh was very helpful in this regard. A brief discussion between SethVidal and MatthiasClasen suggested[2a] that ''nautilus'' has been fixed in rawhide to allow the labelling of files through gnome-vfs via the right-click "properties" dialog.
| | <references/> |
|
| |
|
| 2. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00081.html
| | === Is gNaughty a Hot Babe ? === |
|
| |
|
| 2a. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00088.html
| | [[User:Sundaram|Rahul Sundaram]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02071.html</ref> the results of a survey conducted, primarily on @fedora-list and on the forums, to discover which non-repository-packaged software Fedora consumers were using. |
|
| |
|
| DanWalsh wrote a detailed response[3] in which he commented that Jon had run ''vpnc'' from the command-line instead of from ''NetworkManager'', this latter being standard usage. Dan thought that this contradicted Jon's claim that this problem would be typically faced by an ordinary desktop user without access to, or knowledge of, ''chcon''. He further argued that the ''virt-manager'' problem was unlikely to be faced by such desktop users and went on to explain that "libvirtd is not unconfined whereas running qemu as a user is unconfined. Running qemu from libvirtd is still confined and is fixed by correct labeling. Hopefully the virt-manager people will assign an appropriate context at creation time, and/or default virtual machines to /var/lib/libvirt/images where they will be labeled correctly automatically."
| | 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?" |
|
| |
|
| 3. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00127.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. |
|
| |
|
| Dan then commented that Desktop users are currently only confined with respect to executable memory checks in order to stop poorly written programs offering a means to execute buffer overflows. The use of PolicyKit, HAL and D-BUS to improve the user's desktop experience by running applications as root was mentioned by Dan as a further arena in which user confinement was necessary in order to prevent root exploits. He alluded to his recent presentations (e.g. [4],[5]) on confining users on Fedora 9 and rawhide as ways in which user types can be confined in customized ways to prevent such problems.
| | <references/> |
|
| |
|
| 4. http://www.redhatmagazine.com/2008/07/02/writing-policy-for-confined-selinux-users/
| | === Chrome9 Vx800 Graphics Support on LiveUSB === |
|
| |
|
| 5. http://danwalsh.livejournal.com/11913.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?" |
|
| |
|
| | [[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. |
|
| |
|
| DanielBerrange added[6] that the ''libvirt'' problem should be permanently fixed in Fedora 10 due to new storage management capabilities.
| | <references/> |
|
| |
|
| 6. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00128.html
| | === Who Wants a Pony? === |
|
| |
|
| Much of the rest of the discussion focused on the general problem of whether or not it was appropriate to offer uneducated users the option to disable intrinsic security. JesseKeating and AlanCox[7] thought that a lack of knowledge precluded a meaningful choice and JamesMorris agreed[8], and referenced BruceSchneier on risk evaluation and security. He concluded that "Punting the decision to the end user during installation is possibly the worst option. It's our responsibility as the developers of the OS to both get security right and make it usable. It's difficult, indeed, but not impossible."
| | [[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. |
|
| |
|
| 7. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00073.html
| | <references/> |
|
| |
|
| 8. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00091.html
| | === Firestarter Retired as Unportable to PolicyKit === |
|
| |
|
| ColinWalters added[9] his voice to the chorus of those that believed that it was inappropriate to offer such options during installation. He suggested that ''system-config-selinux'' post-installation was available for those that really needed it and that the paths to solve this problem were not restricted to a binary "enabled or disabled by default" but included other possibilities such as: rawhide defaults to permissive; automatic reporting of denials to the Fedora developers; shifting more objects into unconfined_t in the default while confining network-facing services; and finally, using a regression test suite to ensure updates are not problems. Jon was largely in agreement[10] and again wanted to emphasize that he was appreciative of both Dan's rapid fixing of problems and the usefulness of SELinux itself, but he thought that the "tuning down of default policy" was the best option to enable "Desktops where people can just get stuff done." AlanCox did not buy this[11] and argued that no progress would be made without exposing us all to the problems which would then get fixed. He likened the discussion to the years-old one which had taken place concerning firewalls being enabled by default: "Sorry if I sound fed up of all of this but I spent 9 months fighting people years back to get firewalling enabled by default, and that had all the same arguments. Today nobody (even Microsoft) would propose otherwise." Alan added that ''setroubleshoot'' should be a bit more user friendly.
| | [[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-July/msg00072.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." |
| | |
| | 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/> |
|
| |
|
| 10. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00075.html
| | === Russian Fedora ? === |
|
| |
|
| 11. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00099.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. |
|
| |
|
| Apparent agreement on this last point exposed a further problem with several posters suggesting[12],[13] that a Windows Vista-like prompt to run a program which had been flagged as dangerous would be useful. SimoSorce and AndrewFarris highlighted[14],[15] the potential flaw of such an approach. SurenKarapetyan argued[16] that he and others were capable of making an informed choice to disable SELinux and that Fedora was becoming increasingly restricted in such freedoms. SimoSorce retorted[17] that re-adding the "disable SELinux" option during installation was wrong from a usability perspective and that if was both selfish and incompetent for Fedora developers to simply disable SELinux instead of dogfooding it. Suryen referenced Smolt statistics to bolster his case and argued that it was wrong to decide "for the user" what to do. AlanCox responded[18] that such statistics were meaningless because it was impossible to know how many of the users disabling SELinux had made an informed, correct choice.
| | 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]]. |
|
| |
|
| 12. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00101.html
| | <references/> |
|
| |
|
| 13. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00117.html
| | === Will FESCo Revisit Kmods ? === |
|
| |
|
| 14. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00124.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]]. |
|
| |
|
| 15. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00125.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>. |
|
| |
|
| 16. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00184.html
| | <references/> |
|
| |
|
| 17. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00187.html
| | === Upgrade from Fedora 10 to Rawhide (Fedora 11) === |
|
| |
|
| 18. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00221.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." |
|
| |
|
| Several other posters expressed frustration with the repetition of such objections to SELinux and there the thread would have lain, flogged senseless except that StewartAdam volunteered[19] to help write an "setroubleshoot" plugin that "allowed users to report audit denials similar to how kerneloops does. setroubleshoot then bridges the gap between new users and fixing the policy, and it could be done with stats to see what areas need work on. Naturally it would only report the denials the user requests to be submitted, so no "calling home" stuff." This proposal seemed to draw general approval[20],[21].
| | <references/> |
| | |
| 19. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00131.html
| |
| | |
| 20. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00142.html
| |
| | |
| 21. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00137.html
| |
| | |
| === Help Wanted: Samba4, Heimdahl, OpenChange ===
| |
| | |
| An exciting promise of increased interoperability with Microsoft Exchange was wafted[1] in front of us when AndrewBartlett requested help in packaging OpenChange[2] and its dependencies. This would result in "evolution" and "kdepim" being able to use the native MAPI protocol and free them from relying upon fragile WebDAV access to the server.
| |
| | |
| 1. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00002.html
| |
| | |
| 2. https://fedoraproject.org/wiki/Features/OpenChange
| |
| | |
| JesseBarnes was excited enough to start helping out and after some pointers from RahulSundaram[3] and Andrew on how to get started[4] he very quickly got going[5]. AlexanderBoström and MarceloGobelli also expressed willingness to help.
| |
| | |
| 3. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00029.html
| |
| | |
| 4. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00027.html
| |
| | |
| 5. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00090.html
| |
| | |
| === Java, So Many Free Choices ===
| |
| | |
| PeterLemenkov requested[1] that the current wiki[2] be updated to summarize the status of the four available implementations[3] of Java: GCJ, OpenJDK/IcedTea, ecj, java-1.6.0-sun (this latter for EPEL only). His interest had been sparked by the observation that some packages were built with GCJ and had not been rebuilt with OpenJDK which he presumed to be superseding GCJ/ecj.
| |
| | |
| 1. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00151.html
| |
| | |
| 2. http://fedoraproject.org/wiki/Java
| |
| | |
| 3. Strictly speaking although these all share some features it's a bit misleading to lump them together. OpenJDK is Sun Microsystems' open-sourced implementation of the Java Platform (SE). This includes classes, an interpreter, compiler etc., whereas ''ecj'' was solely a bytecode compiler from the ''Eclipse'' project. ''GCJ'' can compile Java to bytecode or to native machine code and provides a linkable runtime which can interpret bytecode. ''IcedTea'' was a project which replaced non-Free parts of OpenJDK with GNU implementations.
| |
| | |
| AndrewHaley promised[4] to update the wiki and commented that due to limited people resources it was difficult to say exactly what the future of GCJ/ecj would be and that OpenJDK support needed to be extended across more platforms. He explained[5] that there was no need to use OpenJDK to rebuild packages which already compiled with ''GCJ'' and expanded on his earlier comment with the information that most non-x86 platforms were currently not fully supported by OpenJDK.
| |
| | |
| 4. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00152.html
| |
| | |
| 5. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00169.html
| |
| | |
| When MattBooth suggested that ''GCJ'' would be needed until OpenJDK could support AOT compilation AndrewOverholt responded[6] that JIT compilation (as implemented by OpenJDK's ''Hotspot'' virtual machine) removed this need. AndrewHaley disagreed [7] for at least the case of lower-powered boxes which would benefit from AOT.
| |
| | |
| 6. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00185.html
| |
| | |
| 7. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00186.html
| |
| | |
| | |
| After all this talk about the many Free choices available in Java KevinKoffler wondered[8] whether some of the other virtual machines, such as ChristianThalinger's ''cacao''[9] or GaryBenson's ''shark''[10], both of which attempt to re-implement ''Hotspot'' in more portable ways, would be receiving attention. AndrewHaley responded[11] that help was welcome, "building Cacao + OpenJDK on one of the secondary arches and reporting back on how well it works would be massively useful."
| |
| | |
| 8. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00154.html
| |
| | |
| 9. http://www.cacaovm.org/
| |
| | |
| 10. http://gbenson.net/?p=67
| |
| | |
| 11. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00168.html
| |
| | |
| === Fedora 9 Now Officially Supported On Itanium/IA64 ===
| |
| | |
| An announcement[1] by PraritBhargava of the availability of Fedora 9 on the ia64 "itanium" platform is the first fruit of the work done (see FWN#90[2], FWN#92[ 3]) to open up the Fedora project to "secondary architectures."
| |
| | |
| 1. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00110.html
| |
| | |
| 2. http://fedoraproject.org/wiki/FWN/Issue90#Fedora.Secondary.Architectures.Proposal
| |
| | |
| 3. http://fedoraproject.org/wiki/FWN/Issue92#Secondary.Arch.Proposal.Cont.
| |
| | |
| This means that it is now possible to run Fedora on an expanded range of high end hardware (from HP, SGI, NEC, Fujitsu, Unisys, Hitachi and Bull according to the architecture maintainers[4]. The release notes inaccurately describe this as a "beta" but DougChapman clarified that it is a GA release.
| |
| | |
| 4. http://fedoraproject.org/wiki/Architectures/IA64
| |
| | |
| Prarit warned that there were a few important points of which to be aware including some slight source differences from stock Fedora 9. Consequently attempts to use ''yumdownloader'' will pull in SRPMS which do not match the actual source used to produce the ia64 binaries. MichaelSchwendt wanted to know why the ia64 release was out of sync with the other architectures and exactly what patches had been applied to stock Fedora. DougChapman answered[5] that future releases would hopefully reflect the experience gained in this very first "secondary architecture" and result in near perfect synchronization. He added that the changes to stock Fedora 9 source were in Fedora CVS so there were "no special ia64 patches floating around" and that the ia64 Everything repository had about 98% of the packages available on other arches. The builds are conducted on a separate Koji server using an identical method to the other architectures.
| |
| | |
| 5. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00118.html
| |
| | |
| DavidWoodhouse asked[6] why the download URL was so different to that of other supported architectures. BillNottingham responded[7] that ia64 was intentionally left off the Fedora master mirror due to space constraints.
| |
| | |
| 6. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00138.html
| |
| | |
| 7. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00143.html
| |
| | |
| RichardJones wanted[8] to know how to build Rawhide packages against ia64 using Koji and PaulHowarth provided[9] some sample Koji commands. DanHorak thought that ''fedora-packager-setup'' should provide some default configs in ''~/.koji''.
| |
| | |
| 8. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00160.html
| |
| | |
| 9. https://www.redhat.com/archives/fedora-devel-list/2008-July/msg00165.html
| |
| | |
| === Running As Root ===
| |
| | |
| A tired JerryWilliams asked[1] that the prompt which warns users that they have logged in as root to a session should have a means to easily disable it: "People login as root and have to keep clicking "Continue" and it slows things down."
| |
| | |
| 1. https://www.redhat.com/archives/fedora-devel-list/2008-June/msg01500.html
| |
| | |
| TomCallaway disagreed[2], likening this to "using a loaded shotgun as a golf club, and what you're suggesting is that we take the safety off, because it interferes with your golf game." He suggested that the preferred behavior was to login as a normal user and then use ''sudo'' or ''su'' to elevate privileges to those of root only when necessary. Jerry decided[3] to re-think why he needed such root privileges and consequently drew attention to the lack of a non-root account setup on install, the presence of applications such as browsers in the root GUI profile, and the need to know the root password to use some configuration tools anyway.
| |
| | |
| 2. https://www.redhat.com/archives/fedora-devel-list/2008-June/msg01501.html
| |
| | |
| 3. https://www.redhat.com/archives/fedora-devel-list/2008-June/msg01521.html
| |
| | |
| Some of these points have received prior developer attention (see FWN#103 "Root Login And Display Managers In Rawhide"[4]) and were specifically discussed with reference to the Desktop Live spin.Tom acknowledged[5] that Jerry's questions were valid and wondered what had happened to "making the root GUI session a super-minimal session." DougLedford also mounted[6] a spirited defense of the occasional need to log in as root, although he conceded that it should not be made too easy to do so. His reasons included scenarios in which network-provided accounts and authentication are unavailable.
| |
| | |
| 4. http://fedoraproject.org/wiki/FWN/Issue103#Root.Login.And.Display.Managers.In.Rawhide
| |
| | |
| 5. https://www.redhat.com/archives/fedora-devel-list/2008-June/msg01522.html
| |
| | |
| 6. https://www.redhat.com/archives/fedora-devel-list/2008-June/msg01538.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."
