|
|
| (95 intermediate revisions by 2 users not shown) |
| Line 5: |
Line 5: |
| mailing list are summarized. | | mailing list are summarized. |
|
| |
|
| Contributing Writer: [[OisinFeeley|Oisin Feeley]] | | Contributing Writer: [[User:Ush|Oisin Feeley]] |
|
| |
|
| === External Repositories and the New Keys === | | === Would You Like to Write This Beat ? === |
|
| |
|
| As a result of the re-signing all the packages with a new key as a security precaution[1] some problems with packages from third-party repositories were reported[2] by [[CallumLerwick|Callum Lerwick]]. The specific example was an update of the non-Free "xine-lib-extras-nonfree". [[SethVidal|Seth Vidal]] suggested[3] a simple fix of <code> yum --skip-broken update</code>.
| | 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://fedoraproject.org/wiki/FWN/Issue142#Getting.Back.on.our.Feet
| | <references/> |
|
| |
|
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01070.html
| | === Is gNaughty a Hot Babe ? === |
|
| |
|
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01072.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. |
|
| |
|
| [[JeffSpaleta|Jef Spaleta]] experienced[4] no such error and speculated that it was due to some mirrors being temporarily out of sync, which [[MatthewWoehlke|Matthew Woehlke]] agreed[5] was likely. [[KevinKofler|Kevin Kofler]] disagreed[6] and diagnosed the problem as a "chicken and egg" one in which it was impossible to get the new repository key which in turn would enable the new, matching ''xine-lib'' to be obtained. He suggested that while it was possible to use <code>yum --skip-broken</code> or <code>yum --exclude</code> for a selective update it would be better for new users to "[...] use the PackageKit GUI, click on "Review updates" and uncheck the xine-lib-extras-nonfree update, then apply."
| | One interesting point is that CMUCL<ref>One of the Common Lisp implementations: http://www.cons.org/cmucl/</ref> was revealed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02088.html</ref> to be only available for 32-bit systems. However what got people really excited was<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02136.html</ref> Rahul's question about what to do concerning the <code>gNaughty</code> package. Its sole purpose seemed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02203.html</ref> to be downloading pornography. Rahul referenced the <code>hot-babe</code> CPU monitor which enjoyed controversy in Debian packaging circles due to its use of female nudity. Rahul wanted to find out "[...] is this allowed in Fedora?" |
|
| |
|
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01073.html | | Amusingly a good deal of the controversy focused on whether the content was freely redistributable, but a predictable moral angle was raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02242.html</ref> by [[User:Alsadi|Muayyad AlSadi]] who asked for help in producing a spin which removed content deemed objectionable. Muayyad is a Jordanian developer who has been producing an Arabic-localized Fedora spin named "Ojuba" for some time. Muayyad sought a way to make identifying and tagging packages easier to facilitate this spin. [[User:Notting|Bill Nottingham]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02312.html</ref> skeptical about the chances of tags keeping meaning unless there was some sort of review board. Equally predictable was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02295.html</ref> the reaction typified by [[User:Skvidal|Seth Vidal]] which resisted any attempt to restrict packages according to standards which had nothing to do with licensing or patent issues. [[User:bochcecha|Mathieu Bridon]] thought<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02355.html</ref> that the creation of a wiki-page by Muayyad would allow anyone interested in co-ordinating work on "Inappropriate Content" to just go ahead and do it without dragging in bureaucracy. |
|
| |
|
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01090.html
| | <references/> |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01124.html
| | === Chrome9 Vx800 Graphics Support on LiveUSB === |
|
| |
|
| [[ThorstenLeemhuis|Thorsten Leemhuis]] thought[7] that this was a general problem for the ''livna'' repository in which they can only "push [too] early or [too] late". He had outlined the problem previously (see FWN#138 "Solving the Unsynchronized Release of Package Dependencies"[8]) but his suggested solution of adding a brief time period during which yum keeps checking for missing dependencies had not obtained traction. Thorsten explained again: "[...] the problem happens each time when Livna/RPM Fusion packages with deps on a specific Fedora packages get pushed in sync; that creates a lot of trouble * I'd say once for 24 hours each two weeks." He conceded[9] that <code>yum --skip-broken</code> was "[...] best answer, but that's not enabled by default in Fedora. Livna/RPM Fusion could fix that via its releasepackages, but that's not nice and I want to avoid going that route." | | [[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?" |
|
| |
|
| On the foot of a suggestion made[10] by [[HaraldHoyer|Harald Hoyer]] to add "More Information button in PackageKit dialogs, which explains the situation and that this might only just take some days to resolve[.]" [[RichardHughes|Richard Hughes]] asked[11] for specific suggestions to improve the current dialogs. He added that "[m]y personal view is that by showing an error dialog, we've lost, and should avoid doing it at all costs." Thorsten responded[12] to Harald that he believed that it was best to "[...] enable skip-broken by default, but show the error to the user if security updates are involved *or* if the problem doesn't vanish within 72 hours after it had been hit on the client for the first time" and that for the latter cases PackageKit could show some more information.
| | [[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. |
|
| |
|
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01097.html
| | <references/> |
|
| |
|
| [8] http://fedoraproject.org/wiki/FWN/Issue138#Solving.the.Unsynchronized.Release.of.Package.Dependencies
| | === Who Wants a Pony? === |
|
| |
|
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01080.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. |
|
| |
|
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01143.html
| | <references/> |
|
| |
|
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01149.html
| | === Firestarter Retired as Unportable to PolicyKit === |
|
| |
|
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01144.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>. |
|
| |
|
| === Non-X System Consoles to be Removed ===
| | 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/> |
|
| |
|
| [[ArthurPemberton]] was concerned[1] about the best way to help debug the many [PulseAudio] issues which he was experiencing on Fedora 9. He asked "[w]hat information should I gather, how, and where should I present it?" This innocent enquiry spawned several sub-threads which avoided answering his question.
| | === Russian Fedora ? === |
|
| |
|
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00982.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. |
|
| |
|
| In the first [[BillCrawford|Bill Crawford]] recommended[2] disabling PulseAudio and although [[IgnacioVazquezAbrams|Ignacio Vazquez-Abrams]] listed features unique to it [[KarelZak|Karel Zak]] was[3] skeptical that "ordinary" users would need them. [[ToshioKuratomi|Toshio Kuratomi]] responded[4] that the network transport features were very useful for thinclients.
| | 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]]. |
|
| |
|
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01053.html
| | <references/> |
|
| |
|
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01107.html
| | === Will FESCo Revisit Kmods ? === |
|
| |
|
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01110.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]]. |
|
| |
|
| [[JaninaSajka|Janina Sajka]] chimed in[5] to agree with Arthur that while the idea of PulseAudio was appealing and "[...] holds great promise for accessibility [...]" there appeared to be practical problems to sort out. Janina referenced SpeakupModified.org, which provides repositories for a Fedora-derived distribution tailored towards users that rely on audio cues instead of visual ones, and noted that it was currently necessary to disable PulseAudio because "[...] one gets no audio until after a user logs in on the GUI. So, how are those who need screen reader support supposed to use the a11y features of GDM? As it stands, there seems no way to get console audio without that GUI login. Also a nonstarter in the screen reader user community." She asked if anyone had a "working init script for pulseaudio as a system daemon?" None of the many message that followed appeared to have an answer to this question. In part this appeared[6] to be because <'' Orca'' can handle the audio rendering of the GDM login screen. Colin provided[7] references that should make it possible to configure GDM to work this way out of the box using GConf settings. It seemed[8] that this was a possible solution. | | [[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>. |
|
| |
|
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01179.html
| | <references/> |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01189.html
| | === Upgrade from Fedora 10 to Rawhide (Fedora 11) === |
|
| |
|
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01213.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." |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01240.html
| | <references/> |
| | |
| At this point [[ColinWalters|Colin Walters]] set off a firestorm of complaints and queries when he announced[9], as an aside, that "[w]e're going to be removing the legacy non-X system consoles by default in the long run."
| |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01180.html
| |
| | |
| [[JerryJames|Jerry james]] listed[10] three scenarios in which he felt it would be very useful to have text consoles. The advantages included faster startup than with Xorg and independence from a damaged X session. Colin rebutted[11] most of these with the argument that "login is slow" was a bug which should be fixed and that the other scenarios also were constructed on the basis of bugs which should be fixed (in the applications themselves and in Xorg's ability to handle crashes.)
| |
| | |
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01186.html
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01190.html
| |
| | |
| [[MatthewWoehlke|Matthew Woehlke]] also wondered what would happen if Xorg itself was broken and Colin asked[12] rhetorically "What happens when the linux kernel is broken? What happens when /bin/sh is broken? What happens when NetworkManager is broken?" He added that a compressed recovery image should be included by default in a Fedora install. Matthew's response suggested[13] that although it would be possible to recover it would mean having to find a rescue disk and to reboot. He expressed a preference for "[having] X fail to start and dump me at a normal console from which I can fix the problem *without rebooting*, much less needing to dig up a rescue disk :P" and compared the alternative to the fragility of ''Windows''. The issue then became a little clouded when Colin stated "I believe we already do that today, and am not advocating removing that functionality if possible. Anyways, I've said what I need to, so hopefully people won't be surprised later." Further requests[14][15] for clarification on the previous statement produced no simple response, although later Colin did appear to confirm[16] the impression that he saw this as an essential change for the evolution of Fedora as a Desktop.
| |
| | |
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01194.html
| |
| | |
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01197.html
| |
| | |
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01199.html
| |
| | |
| [15] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01203.html
| |
| | |
| [16] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01209.html
| |
| | |
| === make force-tag Gone ===
| |
| | |
| The removal of <code>make force-tag</code> was objected to[1] by [[BastienNocerra|Bastien Nocerra]] as it forced bumping the Release of packages even for trivial changes. A massive thread resulted with a good deal of agreement expressed with Bastien.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00675.html
| |
| | |
| [[MikeMcGrath|Mike McGrath]] made[2] the case that if maintainers tested packages before committing them and adduced the necessity of the current workflow in producing an audit trail for licensing as a concrete reason. [[JonCiesla|Jon Ciesla]] had earlier mentioned using <code>TAG_OPTS=-F make tag</code> as a work around and now asked[3] if "the Makefile can be modified to prevent it, so that others who didn't know [that this invalidates the audit trail] stop doing it?" [[DougLedford|Doug Ledford]] responded[4] that this would be unenforceable as it would still allow the CVS command to be run by hand and "[i]f our recent 'incident' showed us anything, it's that things like this need to be enforced on the CVS server if they are going to be enforced at all."
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00725.html
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00736.html
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00904.html
| |
| | |
| [[JesseKeating|Jesse Keating]] argued[5] that the issue was more GPL compliance than an audit trail and outlined why he would personally prefer to move away from building from CVS tags. [[JefSpaleta|Jef Spaleta]] suggested[6] that [[MikeMcGrath|Mike McGrath]] had misspoken: "You are of course free to make 300 small separate specfile changes between each build attempt. There is a desire to move to a point where we can be reasonably sure that a cvs tag corresponds to a specific build. Since we have no way of making only tags corresponding to successfully built packages immutable, all tags must be immutable" and like Mike asked for a way to mark as immutable a subset of CVS tags corresponding to a successful Koji build.
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00740.html
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00786.html
| |
| | |
| The thread is recommended reading for package maintainers and the brief
| |
| summary above misses many important points.
| |
| | |
| === Graphics Modesetting Changes ===
| |
| | |
| A post by [[DaveAirlie|Dave Airlie]] reminded[1] the list that [KernelModesetting][2] was going to be one of the notable features of Fedora 10 for recent Radeon "r300 to r500 (and possibly r600/r700)" and Intel "from i830 to GM45 (though it may end up i915 and up only)" GPUs . [[AdamJackson|Adam Jackson]] responded[3] to [[BillCrawford|Bill Crawford]] that r200 class hardware would probably not get modesetting in Fedora 10. Among other things this will have cosmetic advantages such as removing flickers from the startup sequence, reducing Xorg startup times and practical advantages such as oops/panic messages while Xorg is running and improved suspend/resume support. Dave cautioned that only a subset of the GPUs were working for the beta release "[...] r300 to r500 class of hardware, while we await upstream changes to the Intel driver" and noted that to disable modesetting one should append <code>nomodeset</code> to the kernel command line via <code>GRUB</code>.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00991.html
| |
| | |
| [2] https://fedoraproject.org/wiki/Features/KernelModesetting
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01019.html
| |
|
| |
| In response to [[HansdeGoede|Hans de Goede]] Dave welcomed[4] bug reports of the "output doesn't light up" type and suggested using an <code>ssh</code> session to reboot to runlevel 3 with nomodeset and then <code>rmmod radeon drm; modprobe drm debug=1; modprobe radeon modeset=1</code> and attach <code>dmesg</code> and an Xorg log to the bugzilla entry. Following this recipe produced[5] no luck for "Joshua C." as everything froze once he followed the last step.
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01004.html
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01018.html
| |
| | |
| Skepticism about inserting the Intel driver code after the beta testing period was expressed[6] by [[JeremyKatz|Jeremy Katz]] on the foot of such late changes lacking both the visibility necessary for testing and the time to fix any bugs revealed. Jeremy was mildly scathing: "Yeah, I've seen intel's 'mature' code before. Excuse me if this is anything but reassuring." [[JesseKeating|Jesse Keating]] and [[ChristopherSnook|Christopher Snook]] seemed[7] to accept Jeremy's point and leaned towards the idea of implementing the [[KernelModesetting]] contingency plan[8] of including the modesetting code disabled by default, but allowing users to enable it on the kernel command line.
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01036.html
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01055.html
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01055.html
| |
|
| |
| [[AdamJackson|Adam Jackson]] wondered whether Jeremy was advocating removing all the new code or testing it all and Jeremy suggested[9] the third option of only enabling the radeon code for now and waiting for Fedora 11 to enable the Intel code.
| |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01068.html
| |
|
| |
| When "Joshua C." asked[10] for a list of working radeon cards and suggested applying the contingency plan because "f10 is just a month away" he was corrected [11] by [[PaulFrields|Paul Frields]] that it was approximately two months away with a development freeze in six weeks. Dave asked[12] Joshua to "[...] stop scare mongering[,] it's a beta release, if it still doesn't work at devel freeze I'll blacklist all the broken machines" which reaction surprised[13] Joshua a little.
| |
| | |
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01077.html
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01115.html
| |
| | |
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01117.html
| |
| | |
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01147.html
| |
| | |
| === Root Login Disallowed on GDM ===
| |
| | |
| Surprise was expressed[1] by "Dr. Diesel" when he attempted to log in as root via GDM[2] to a rawhide install. "Dr. Diesel" reported that it was possible to log in via the console in runlevel 3. He asked if he should file a bugzilla entry.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01205.html
| |
| | |
| [2] http://www.gnome.org/projects/gdm/
| |
| | |
| [[DarrellPfeifer|Darrell Pfeifer]] quoted[3] the changelog as evidence that this restriction was intentional to which "Dr. Diesel" responded that it would be a good idea to change the prompt to "[...] something like 'Root login disabled'[.]". [[MatthewWoehlke|Matthew Woehlke]] was disturbed and wondered "[...] what exactly are we supposed to do when the user login gets hosed? Reach for a rescue disk? (Seriously, what's with the sudden trend to make fixing problems harder by making recovery modes inaccessible in an apparent bid to hide the "confusing/potentially dangerous" bits of the system from the user?)" The latter part of this apparently being a reference to another recent thread (see this FWN#143 "Non-X System Consoles to be Removed".)
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01206.html
| |
| | |
| [[BenjaminLewis|Benjamin Lewis]] presented[4] a straightforward, obvious way of fixing such problems: "CTRL+ALT+F1, login as root, fix it, CTRL+ALT+F7 to get back to GDM" and [[MartinSourada|Martin Sourada]] added "[or] boot to runlevel 3, login as root there and startx..."
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01225.html
| |
| | |
| The discussion was moved on[5] by [[NigelJones|Nigel Jones]] with a suggestion that the default setup should configure ''sudo'' to allow the first user configured during ''firstboot'' to have "full access w/ password." [[StevenMoix|Steven Moix]] disagreed[6] as this all seemed like the "Ubuntu 'protect us from ourselves' way" which removed the conscious choice to log in as root. [[MartinSourada|Martin Sourada]] was also filled[7] with dismay at the idea, but his objection was that [[PolicyKit]] was a superior solution to ''sudo''. This preference was confronted[8] by [[ThorstenLeemhuis|Thorsten Leemhuis]] with a request to "[...] please tell me how for example read /var/log/messages or other log files from /var/log/ using PolicyKit from a -gnome,kde-terminal with an easy to remember and fast to type command (like 'sudo') [.]" Thorsten also suggested that firstboot could present a checkbox labeled "User is the sysadmin for this system" that when checked would configure ''sudo'' and/or [[PolicyKit]] or any other desiderata for allowing root privileges for the user. [[MatthewMiller|Matthew Miller]] largely agreed with this and suggested that "uncommenting the wheel group in /etc/sudoers, and having said checkbox add the user to the wheel group" would be the way to do it, but [[SethVidal|Seth Vidal]] raised[9] the problem of "[...] the wheel group, on systems which are using some other form of nss than local files, can be mucked with too easily."
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01222.html
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01224.html
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01228.html
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01233.html
| |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01238.html
| |
| | |
| All this was strangely reminiscent of previous discussions, e.g. FWN#103 "Root Login And Display Managers In Rawhide"[10] except that PolicyKit now offers some possible new directions as [[MartinSourada|Martin Sourada]] outlined[11:] "What I am mostly against is having full access to sudo without password by default by any user. I believe PolicyKit is designed to solve this issue by granting rights (by admin) to user to do this and that and not do other admin tasks [...] the implementation should IMHO be like cat/nano/vi/whatever detects that you are trying to access some file you don't have enough rights to access, then it asks PolicyKit whether to allow it or not and PolicyKit handles the rest (i.e. checks whether your admin already allowed that access for you, if not asks for root password for allowing the access and if succeeded sends back that its OK for you to access the file). Ideally it wouldn't require any additional command (like sudo) [...] When I want to view logs (though I don't very much understand why I cannot read them as normal user) I just log in as root (in console/gnome-terminal only!). Yeah it's not pleasant to write root password every time I want to do some admin task - and that's probably one of the reasons why PolicyKit has been developed - but I think allowing full access to sudo without password for normal user account is a big security hole."
| |
| | |
| [10] http://fedoraproject.org/wiki/FWN/Issue103#Root.Login.And.Display.Managers.In.Rawhide
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01237.html
| |
| | |
| === Missing Screen Locking Spurs Inquiry Into User-state Maintenance ===
| |
| | |
| When [[JohnEllson|John Ellson]] enquired[1] why "[...] my userid, and only my userid, has no Lock Screen menu item or applet?" a brief thread revealed the many places in which user state is kept. The answer, for the impatient, turned out[2] to be that John had experimented with ''Pessulus''[3], which allows administrators to enforce mandatory GConf settings on users.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01027.html
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01108.html
| |
| | |
| [3] http://live.gnome.org/Pessulus
| |
| | |
| John's first pass at the problem was to wipe out some dot files <code>rm -rf .gnome .gnome2 .gconf .gconfd .metacity</code> and this failed to restore the default. [[ChrisSnook|Chris Snook]] suggested[4] that he consider <code>/tmp</cod> as another location where "per-user state is kept" but John had investigated[5] both <code>/tmp</code> and <code>/var/tmp</code>.
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01031.html
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01034.html
| |
| | |
| [[JesseKeating|Jesse Keating]] wondered[6] if "[...] it's not a ConsoleKit interaction making the session think your user isn't at the console?" John replied that he had gone to the extraordinary lengths of "moving aside my home directory, deleting my userid, removing everything in /tmp and /var/tmp, rebooting creating a new userid with the same name (but different user and group numbers), and it still has no Lock Screen!!!" [[JeffSpaleta|Jef Spaleta]] made[7] the disclaimer that he did not "[...] understand PolicyKit/ConsoleKit well enough to help you track it down in the filesystem with 100% confidence[...]" but suggested searching in /var/lib/PolicyKit and /var/lib/PolicyKit-public for per-user authorization rules. This was reported[8] as fruitless by John, as was running <code>polkit-auth</code>. John wondered where the output of <code>polkit-auth</code> came from as "Removing /var/lib/PolicyKit/user-ellson.auths doesn't change the output."
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01040.html
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01050.html
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01059.html
| |
| | |
| [[MatthiasClasen]] cut straight to the chase and suggested[9] a good, old-fashioned backtrace "Why don't we stop all this blind guessing, and attach a debugger to the panel instead ? It would be so much easier..." Although John wondered[10] why <code>gnome-panel</code> sprang to Matthias' mind as a culprit a later suggestion[11] to "[...] break in panel_lock_screen_action_available [...]" gave him a clue as to the problem.
| |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01064.html
| |
| | |
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01074.html
| |
|
| |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01076.html
| |
| | |
| Pessulus has been around since Fedora 7 at least and the process above was a bit of a wild goose chase, but what is interesting is how difficult it is to solve such a problem due to the many places in which such information is stored.
| |
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."
