From Fedora Project Wiki

< FWN‎ | Beats

(devel beat #143)
(devel beat #144 only quickly edited, basic spellchecking, basic wiki markup. could probably use some love.)
Line 7: Line 7:
Contributing Writer: [[OisinFeeley|Oisin Feeley]]
Contributing Writer: [[OisinFeeley|Oisin Feeley]]


=== External Repositories and the New Keys ===
=== Removal of non-X Consoles (continued) ===


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>.
The furore over the future removal of text-mode consoles (see FWN#144 "Non-X System Consoles to be Removed"[1]) continued throughout the week. The original thread saw some support for the idea expressed[2] by [[NicolasMailhot|Nicolas Mailhot]] on the basis that "[...] non-X-console input is a mess [...] font support has fossilized, and support for modern high resolution screens is severely lacking [...]" Nicholas was especially concerned[3] with the maintenance burden imposed by the text-mode console "[...] as someone who is an upstream maintainer for my language of some of the bits the console use[s]."


[1] https://fedoraproject.org/wiki/FWN/Issue142#Getting.Back.on.our.Feet
[1] https://fedoraproject.org/wiki/FWN/Issue143#Non-X.System.Consoles.to.be.Removed


[2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01070.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01341.html


[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01072.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01347.html


[[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."
Upon being pressed by [[DominikMierzejewski|Dominik Mierzejewski]] for evidence of a lack of proper maintenance Nicolas listed[4] a series of problems including the stagnation of the console layout database and the console font set. [[DmitryButskoy|Dmitry Butskoy]] begged[5] to separate the concepts of "console" and "serial tty" and also for the retention of the text-mode console. Dominik promised to try to find a colleague to shoulder the maintenance burden but Nicolas had already given up[6] in disgust. In response elsewhere to [[SethVidal|Seth Vidal's]] argument that the text console did no harm and should be left alone Nicholas expanded[7] on the maintenance costs of "all sorts of packaging rules designed to avoid hitting console limitations and problems" and bugs filed because of the confusion caused by two text stacks.


[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01073.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01373.html


[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01090.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01381.html


[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01124.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01388.html


[[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."
[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01396.html


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.
[[LesMikesell|Les Mikesell]] got to the heart of the problem when he asked[8] "I think I'm confused by the term 'non X consoles'. Is that something different than the native text mode you see before X starts?" He also recommended using FreeNX/NX instead of using the console. Nicolas responded[9] that there were "[...]two different things. A VT to which you can attach an X session, a serial port, a remote SSH, mingetty... and the software stack used to display locally the VT text and collect user input." Nicolas saw the "low-level VT bit" as fundamentally sound but the "current console software stack" as "rotten." Les sought[10] further clarification of this distinction between "[...] the low level part that works in character mode and expects some hardware to supply and render the fonts [...]" and "[...] software other than X that renders custom fonts[.]"


[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01097.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01353.html


[8] http://fedoraproject.org/wiki/FWN/Issue138#Solving.the.Unsynchronized.Release.of.Package.Dependencies
[9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01354.html


[9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01080.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01422.html


[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01143.html
[[DenisLeroy|Denis Leroy]] wondered[11] if there was "[...] an X-based mingetty replacement actually exists ? Something that's proven to be sufficiently fail-safe (will work even with half-broken X configurations and such?)" and although Nicolas did not know of one he speculated[12] "[...] as soon as much of the hardware pocking is moved from xorg to the kernel and X can be run as a normal user "X-based mingetty replacement" will be just running a x term fullscreen in an autoconfigured X instance. Of course one could theoretically write a much lighter solution using only freetype (cairo, pango?) and an xkb-config parser." Denis's concern seemed to be that often a Ctrl+Alt+F1 to ''mingetty'' was the only way to kill hanging desktop applications. [[ColinWalters|Colin Walters]] suggested[13] making "[...] Ctrl-Alt-Backspace just break server grabs instead of killing the server (and of course fix the bugs in the apps that hang while holding a server grab)."


[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01149.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01401.html


[12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01144.html
[12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01407.html


=== Non-X System Consoles to be Removed ===
[13] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01366.html


[[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.
There were multiple expressions of disapprobation often coupled with use cases. Some of these led [[ChrisSnook|Chris Snook]] to exclaim[14] "Unless I've missed something huge, virtual terminals aren't going away. What may or may not be going away is the x86 video BIOS text mode, to be replaced with a kernel framebuffer, which precludes the use of console fonts, which very few people ever mess with. The console itself will remain. Someone please correct me if I'm wrong." [[DaveAirlie|Dave Airlie] confirmed[15] this understanding and added "[...] vga text mode will not be enabled by default, you will need to pass nomodeset if you want to use vga text mode. Welcome to the 1990s." [[AlanCox|Alan Cox]] made[16] the correction that framebuffer console support fonts but that framebuffers did not work on all machines, screen reader technology and remote management cards.


[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00982.html
[14] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01417.html


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.
[15] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01445.html


[2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01053.html
[16] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01484.html


[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01107.html
=== OpenVPN and resolv.conf ===


[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01110.html
[[AhmedKamal|Ahmed Kamal]] asked[1] for help in scratching an itch and started a concise, meaty thread. His particular problem was that he wanted to overwrite /etc/resolv.conf with new DNS servers obtained over a vpn tunnel, this is apparently done automatically in "Windows".
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01304.html
 
The suggestion to use NetworkManager was made by [[PaulWouters|Paul Wouters]] and [[DanWilliams|Dan Williams]] agreed[2] and added the explanation that it "[...] mediate[d] between services [including PPP, PPtP, DHCP, openvpn, and vpnc] that need to update your DNS information." The alternative is that each service needs to handle <code>/etc/resolv.conf</code> itself.


[[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.
[2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01313.html
 
 
[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01179.html
The idea of a default caching daemon was floated[3] by [[SimoSorce|Simo Sorce]]. As he envisioned it, the services/tools, such as OpenVPN, would "[...] tell the caching daemon which IP ranges and which domains their provided forwarders should be consulted for. All dynamic so that as soon as one daemon goes away, the caching DNS will notice and revert queries to the default DNS.} [[NilsPhilippsen|Nils Philippsen]] agreed[4] heartily and added that "[i]deally, it should be something which isn't restricted to class A/B/C like reverse DNS (seems to be), but which would route DNS requests based on arbitrary domain name or IP-range criteria to the desired name servers" and [[PaulHowarth|Paul Howarth]] provided[5] the further reason that changes to /etc/resolv.conf are often not picked up by processes. This latter point spawned a discussion on the demerits of the glibc stub resolver (which is too simplistic) and the consequent use of the deprecated <code>gethostbyname</code> in individual applications. [[DanWilliams|Dan Williams]] recommended using <code>lwresd</code> (a stripped-down, caching-only nameserver available to clients which use the BIND 9 lightweight resolver library) or for more complex setups a local caching nameserver. Although [[SimoSorce|Simo Sorce]] disagreed[6] with Dan that many applications were simply using <code>gethostbyname</code> he agreed that "[a] caching nameserver that can be instructed what to do when conditions change is what we really need."
 
[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01189.html


[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01213.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01349.html


[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01240.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01485.html


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."
[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01490.html


[9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01180.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01632.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.)
Ahmed asked[7] whether <code>dnsmasq</code> or other daemons were able to "[direct] name resolution to specific servers according to IP ranges and/or domain names, with the option of adding/removing servers on the fly?" and [[RichardJones|Richard W.M. Jones]][8] confirmed that this was indeed possible. [[AdamTkac|Adam Tkac]] suggested[9] that this could be done with <code>view</code> statements in <code>BIND</code> and the gauntlet of how to do this for CIDR and domain names was thrown down[10] by Nils. A detailed sub-thread followed which indicated what while possible it was not pretty.


[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01186.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01498.html


[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01190.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01500.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.
[9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01508.html


[12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01194.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01523.html


[13] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01197.html
[[AdamTkac|Adam Tkac]] shared[11] the information that his TODO list includes the addition of <code>NetworkManager</code> support to <code>BIND</code> and [[SimoSorce|Simo Sorce]] explained [12] that <code>nscd</code> was not a solution for a local caching nameserver "[...] as not all type of queries can be fulfilled by the glibc interface. For example SRV/TXT records ... Also nscd is not smart enough to understand network condition and adapt it's behavior." Simo agreed that it would be nice if "[...] bind could consult different DNSs based 1) on the DNS name to be queried, and B) the reverse IP to be queried" so that on slow links only the necessary queries would be directed through the VPN.


[14] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01199.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01509.html


[15] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01203.html
[12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01510.html


[16] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01209.html
=== Fedora 10 Feature Owner Request ===


=== make force-tag Gone ===
[[JohnPoelstra|John Poelstra]] requested[1] all those owning a Feature[2] to take some actions on their feature page so that the beta release notes and announcements are accurate. He provided a list of twenty one feature pages which "have not been updated since the Feature Freeze on 2008-09-11 and/or are not 100% complete."


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.
[[KevinKofler|Kevin Kofler]] was among those who had been watching the progress of OpenChange (see FWN#133 "Help Wanted: Samba4, Heimdahl, OpenChange"[3]) and noted[4] that due to the decision[5] of [[AndrewBartlett|Andrew Bartlett]] to orphan the feature it needed a new owner if Fedora 11 was to offer OpenChange.


[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00675.html
Another of the listed pages was that for the Echo icon theme and [[LuyaTsimbalanga|Luya Tshimbalanga]] asked if he should add a release note to the effect that <code>echo</code> was now the default. [[RahulSundaram|Rahul Sundaram]] confirmed that this would be helpful.


[[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."
The Eclipse-3.4 (Ganymede) page was updated[6] by [JeffJohnston|Jeff Johnston]].


[2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00725.html
[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01471.html


[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00736.html
[2] http://fedoraproject.org/wiki/Features/Policy/Definitions


[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00904.html
[3] http://fedoraproject.org/wiki/FWN/Issue133#Help.Wanted:.Samba4.2C.Heimdahl.2C.OpenChange


[[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.
[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01482.html


[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00740.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00522.html


[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00786.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01548.html


The thread is recommended reading for package maintainers and the brief
=== system-autodeath Becomes Reality ===
summary above misses many important points.


=== Graphics Modesetting Changes ===
[[SethVidal|Seth Vidal]] announced[1] that he had implemented his previously discussed (FWN#140 "System Autodeath"[2]) idea to automatically remove networking capabilities from machines which lacked system updates. The intent is to prevent non-maintained machines from being exploited.


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/msg01716.html


[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00991.html
[2] https://fedoraproject.org/wiki/FWN/Issue140#System.Autodeath


[2] https://fedoraproject.org/wiki/Features/KernelModesetting
Seth implemented the concept as a daily cronjob which tests a configured "death date" against the current time. For the week leading up to the "death date" log messages warn that on the specific date the default route will be deleted. He requested feedback and improvements.


[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01019.html
[[MattMiller|Matt Miller]] was content but suggested[3] beefing up the manpage with details of the consequences of removing the default route. Seth noted that he was happy to accept patches.
 
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
[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01779.html


[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01018.html
A fraught note was introduced when [[StephenWarren|Stephen Warren]] declared[4] that if this were a default then, in combination with the proposed textconsole removal (see this FWN#144 "Removal of non-X Consoles (continued)") and the modesetting changes[5], he was thinking about switching distros. [[RahulSundaram|Rahul Sundaram]] responded[6] that modesetting was going to be a feature of all distros soon and the conversation veered[7] into explaining that the replacement for <code>RHGB</code>, named "Plymouth" had a sane text-mode fallback for unsupported chipsets. As much of Stephen's angst was due to a perceived abandonment of those using non-Free drivers Rahul pointed out that the <code>nouveau</code> drivers might work. [[RichardHughes|Richard Hughes]] listed[8] 2-D and <code>xrandr</code> as supported with kernel modesetting coming soon due to [[Maarten Maathuis|Maarten Maathuis's]] work. He warned: "Don't even try 3D yet. It does work, but only if the moon is waxing, and your pet cat is called Oliver."


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.
[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01782.html


[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01036.html
[5] http://fedoraproject.org/wiki/FWN/Issue143#Graphics.Modesetting.Changes


[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01055.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01783.html


[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01055.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01789.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
[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01802.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
Back on the main topic of the thread Seth stated[9] that <code>system-autodeath</code> was not intended to be part of the default install: "This is just a nicety for sysadmins or local-respin maintainers who would like to put a dropdead date on their releases." In response to Stephen's recollection Seth also stated[10] this point clearly. A general disagreement with the idea of exposing such a feature was expressed[11] by [[JamesHubbard|James Hubbard]] on the basis that the user should be forced to change a config file to prevent against accidental installation errors.


[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01115.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01784.html


[12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01117.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01788.html


[13] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01147.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01850.html


=== Root Login Disallowed on GDM ===
=== Fedora Not "Free" Enough for GNU? ===


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.
A long-running thread which was started[1] on 07-09-2008 by [[MichelSalim|Michel Salim]] continues to attracted some heated discussion over the fact that Fedora is not recognized as a 100% Free software distribution by GNU although a derivative named "BLAG" (see also FWN#139[2]) is recognized as FLOSS.


[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01205.html
[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00428.html


[2] http://www.gnome.org/projects/gdm/
[2] http://fedoraproject.org/wiki/FWN/Issue139#Small.Machine.SIG


[[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".)
The central stumbling block seemed[3] to be best stated by [[GregoryMaxwell|Gregory Maxwell]] as "[...] Fedora doesn't yet strip the binary firmware provided by the Linux kernel (and still provides some re-distributable binary firmware in other packages, the microcode package and alsa-firmware I think)." Gregory described the situation as unfortunate due to both the lack "[...] of acknowledgement it deserves, and the FSF is indirectly promoting Ubuntu, a distribution which is, as far as I can tell, a primary driving factor in new users using and depending on proprietary software." This latter being a reference to the recognition of gNewSense as FLOSS.


[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01206.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00435.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..."
There had been previous very heated threads on this subject (during one of FWN's holidays) centered around the efforts of [[AlexandreOliva|Alexandre Oliva]] to produce a "kernel-libre" and the interaction of this project with other efforts and approaches within the kernel community. [[DavidWoodhouse|David Woodhouse]] added[4] the excellent news that "We are almost at the point where we can do a spin which remedies [the difficulties of stripping out the non-Free firmware]." He explained that soon a completely separate package instead of a sub-package of the normal kernel build will allow others to produce alternative packages of firmwares for which source code is available. [[TomCallaway|Tom Callaway]] was worried[5] that there was still firmware entangled in the kernel source code and noted the need for an audit. [[RahulSundaram|Rahul Sundaram]] supplied[6] a link to a Debian inventory of firmwares.


[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01225.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01603.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/msg01605.html


[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01222.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01606.html


[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01224.html
Other interesting points in the discussion touched on the rationales which have been often advanced for refusing to supply source to firmwares. These involve regulatory compliance (often for radio devices). [[AlanCox|Alan Cox]] was suspicious of such arguments based[7] on the history of examples such as ISDN code which "[...] was approved. You could change it but then it became unapproved and not permitted in some countries." He described this as a racket run by the phone companies which imploded once the need to ensure robustness became important (due to terrorist threats.) [[IgnacioVazquezAbrams|Ignacio Vazquez-Abrams]] listed[8] some of the other rationales.


[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01228.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01745.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.
[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01737.html

Revision as of 00:15, 22 September 2008

Developments

In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.

Contributing Writer: Oisin Feeley

Removal of non-X Consoles (continued)

The furore over the future removal of text-mode consoles (see FWN#144 "Non-X System Consoles to be Removed"[1]) continued throughout the week. The original thread saw some support for the idea expressed[2] by Nicolas Mailhot on the basis that "[...] non-X-console input is a mess [...] font support has fossilized, and support for modern high resolution screens is severely lacking [...]" Nicholas was especially concerned[3] with the maintenance burden imposed by the text-mode console "[...] as someone who is an upstream maintainer for my language of some of the bits the console use[s]."

[1] https://fedoraproject.org/wiki/FWN/Issue143#Non-X.System.Consoles.to.be.Removed

[2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01341.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01347.html

Upon being pressed by Dominik Mierzejewski for evidence of a lack of proper maintenance Nicolas listed[4] a series of problems including the stagnation of the console layout database and the console font set. Dmitry Butskoy begged[5] to separate the concepts of "console" and "serial tty" and also for the retention of the text-mode console. Dominik promised to try to find a colleague to shoulder the maintenance burden but Nicolas had already given up[6] in disgust. In response elsewhere to Seth Vidal's argument that the text console did no harm and should be left alone Nicholas expanded[7] on the maintenance costs of "all sorts of packaging rules designed to avoid hitting console limitations and problems" and bugs filed because of the confusion caused by two text stacks.

[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01373.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01381.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01388.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01396.html

Les Mikesell got to the heart of the problem when he asked[8] "I think I'm confused by the term 'non X consoles'. Is that something different than the native text mode you see before X starts?" He also recommended using FreeNX/NX instead of using the console. Nicolas responded[9] that there were "[...]two different things. A VT to which you can attach an X session, a serial port, a remote SSH, mingetty... and the software stack used to display locally the VT text and collect user input." Nicolas saw the "low-level VT bit" as fundamentally sound but the "current console software stack" as "rotten." Les sought[10] further clarification of this distinction between "[...] the low level part that works in character mode and expects some hardware to supply and render the fonts [...]" and "[...] software other than X that renders custom fonts[.]"

[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01353.html

[9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01354.html

[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01422.html

Denis Leroy wondered[11] if there was "[...] an X-based mingetty replacement actually exists ? Something that's proven to be sufficiently fail-safe (will work even with half-broken X configurations and such?)" and although Nicolas did not know of one he speculated[12] "[...] as soon as much of the hardware pocking is moved from xorg to the kernel and X can be run as a normal user "X-based mingetty replacement" will be just running a x term fullscreen in an autoconfigured X instance. Of course one could theoretically write a much lighter solution using only freetype (cairo, pango?) and an xkb-config parser." Denis's concern seemed to be that often a Ctrl+Alt+F1 to mingetty was the only way to kill hanging desktop applications. Colin Walters suggested[13] making "[...] Ctrl-Alt-Backspace just break server grabs instead of killing the server (and of course fix the bugs in the apps that hang while holding a server grab)."

[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01401.html

[12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01407.html

[13] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01366.html

There were multiple expressions of disapprobation often coupled with use cases. Some of these led Chris Snook to exclaim[14] "Unless I've missed something huge, virtual terminals aren't going away. What may or may not be going away is the x86 video BIOS text mode, to be replaced with a kernel framebuffer, which precludes the use of console fonts, which very few people ever mess with. The console itself will remain. Someone please correct me if I'm wrong." [[DaveAirlie|Dave Airlie] confirmed[15] this understanding and added "[...] vga text mode will not be enabled by default, you will need to pass nomodeset if you want to use vga text mode. Welcome to the 1990s." Alan Cox made[16] the correction that framebuffer console support fonts but that framebuffers did not work on all machines, screen reader technology and remote management cards.

[14] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01417.html

[15] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01445.html

[16] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01484.html

OpenVPN and resolv.conf

Ahmed Kamal asked[1] for help in scratching an itch and started a concise, meaty thread. His particular problem was that he wanted to overwrite /etc/resolv.conf with new DNS servers obtained over a vpn tunnel, this is apparently done automatically in "Windows".

[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01304.html

The suggestion to use NetworkManager was made by Paul Wouters and Dan Williams agreed[2] and added the explanation that it "[...] mediate[d] between services [including PPP, PPtP, DHCP, openvpn, and vpnc] that need to update your DNS information." The alternative is that each service needs to handle /etc/resolv.conf itself.

[2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01313.html

The idea of a default caching daemon was floated[3] by Simo Sorce. As he envisioned it, the services/tools, such as OpenVPN, would "[...] tell the caching daemon which IP ranges and which domains their provided forwarders should be consulted for. All dynamic so that as soon as one daemon goes away, the caching DNS will notice and revert queries to the default DNS.} Nils Philippsen agreed[4] heartily and added that "[i]deally, it should be something which isn't restricted to class A/B/C like reverse DNS (seems to be), but which would route DNS requests based on arbitrary domain name or IP-range criteria to the desired name servers" and Paul Howarth provided[5] the further reason that changes to /etc/resolv.conf are often not picked up by processes. This latter point spawned a discussion on the demerits of the glibc stub resolver (which is too simplistic) and the consequent use of the deprecated gethostbyname in individual applications. Dan Williams recommended using lwresd (a stripped-down, caching-only nameserver available to clients which use the BIND 9 lightweight resolver library) or for more complex setups a local caching nameserver. Although Simo Sorce disagreed[6] with Dan that many applications were simply using gethostbyname he agreed that "[a] caching nameserver that can be instructed what to do when conditions change is what we really need."

[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01349.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01485.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01490.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01632.html

Ahmed asked[7] whether dnsmasq or other daemons were able to "[direct] name resolution to specific servers according to IP ranges and/or domain names, with the option of adding/removing servers on the fly?" and Richard W.M. Jones[8] confirmed that this was indeed possible. Adam Tkac suggested[9] that this could be done with view statements in BIND and the gauntlet of how to do this for CIDR and domain names was thrown down[10] by Nils. A detailed sub-thread followed which indicated what while possible it was not pretty.

[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01498.html

[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01500.html

[9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01508.html

[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01523.html

Adam Tkac shared[11] the information that his TODO list includes the addition of NetworkManager support to BIND and Simo Sorce explained [12] that nscd was not a solution for a local caching nameserver "[...] as not all type of queries can be fulfilled by the glibc interface. For example SRV/TXT records ... Also nscd is not smart enough to understand network condition and adapt it's behavior." Simo agreed that it would be nice if "[...] bind could consult different DNSs based 1) on the DNS name to be queried, and B) the reverse IP to be queried" so that on slow links only the necessary queries would be directed through the VPN.

[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01509.html

[12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01510.html

Fedora 10 Feature Owner Request

John Poelstra requested[1] all those owning a Feature[2] to take some actions on their feature page so that the beta release notes and announcements are accurate. He provided a list of twenty one feature pages which "have not been updated since the Feature Freeze on 2008-09-11 and/or are not 100% complete."

Kevin Kofler was among those who had been watching the progress of OpenChange (see FWN#133 "Help Wanted: Samba4, Heimdahl, OpenChange"[3]) and noted[4] that due to the decision[5] of Andrew Bartlett to orphan the feature it needed a new owner if Fedora 11 was to offer OpenChange.

Another of the listed pages was that for the Echo icon theme and Luya Tshimbalanga asked if he should add a release note to the effect that echo was now the default. Rahul Sundaram confirmed that this would be helpful.

The Eclipse-3.4 (Ganymede) page was updated[6] by [JeffJohnston|Jeff Johnston]].

[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01471.html

[2] http://fedoraproject.org/wiki/Features/Policy/Definitions

[3] http://fedoraproject.org/wiki/FWN/Issue133#Help.Wanted:.Samba4.2C.Heimdahl.2C.OpenChange

[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01482.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00522.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01548.html

system-autodeath Becomes Reality

Seth Vidal announced[1] that he had implemented his previously discussed (FWN#140 "System Autodeath"[2]) idea to automatically remove networking capabilities from machines which lacked system updates. The intent is to prevent non-maintained machines from being exploited.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01716.html

[2] https://fedoraproject.org/wiki/FWN/Issue140#System.Autodeath

Seth implemented the concept as a daily cronjob which tests a configured "death date" against the current time. For the week leading up to the "death date" log messages warn that on the specific date the default route will be deleted. He requested feedback and improvements.

Matt Miller was content but suggested[3] beefing up the manpage with details of the consequences of removing the default route. Seth noted that he was happy to accept patches.

[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01779.html

A fraught note was introduced when Stephen Warren declared[4] that if this were a default then, in combination with the proposed textconsole removal (see this FWN#144 "Removal of non-X Consoles (continued)") and the modesetting changes[5], he was thinking about switching distros. Rahul Sundaram responded[6] that modesetting was going to be a feature of all distros soon and the conversation veered[7] into explaining that the replacement for RHGB, named "Plymouth" had a sane text-mode fallback for unsupported chipsets. As much of Stephen's angst was due to a perceived abandonment of those using non-Free drivers Rahul pointed out that the nouveau drivers might work. Richard Hughes listed[8] 2-D and xrandr as supported with kernel modesetting coming soon due to Maarten Maathuis's work. He warned: "Don't even try 3D yet. It does work, but only if the moon is waxing, and your pet cat is called Oliver."

[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01782.html

[5] http://fedoraproject.org/wiki/FWN/Issue143#Graphics.Modesetting.Changes

[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01783.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01789.html

[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01802.html

Back on the main topic of the thread Seth stated[9] that system-autodeath was not intended to be part of the default install: "This is just a nicety for sysadmins or local-respin maintainers who would like to put a dropdead date on their releases." In response to Stephen's recollection Seth also stated[10] this point clearly. A general disagreement with the idea of exposing such a feature was expressed[11] by James Hubbard on the basis that the user should be forced to change a config file to prevent against accidental installation errors.

[9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01784.html

[10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01788.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01850.html

Fedora Not "Free" Enough for GNU?

A long-running thread which was started[1] on 07-09-2008 by Michel Salim continues to attracted some heated discussion over the fact that Fedora is not recognized as a 100% Free software distribution by GNU although a derivative named "BLAG" (see also FWN#139[2]) is recognized as FLOSS.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00428.html

[2] http://fedoraproject.org/wiki/FWN/Issue139#Small.Machine.SIG

The central stumbling block seemed[3] to be best stated by Gregory Maxwell as "[...] Fedora doesn't yet strip the binary firmware provided by the Linux kernel (and still provides some re-distributable binary firmware in other packages, the microcode package and alsa-firmware I think)." Gregory described the situation as unfortunate due to both the lack "[...] of acknowledgement it deserves, and the FSF is indirectly promoting Ubuntu, a distribution which is, as far as I can tell, a primary driving factor in new users using and depending on proprietary software." This latter being a reference to the recognition of gNewSense as FLOSS.

[3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00435.html

There had been previous very heated threads on this subject (during one of FWN's holidays) centered around the efforts of Alexandre Oliva to produce a "kernel-libre" and the interaction of this project with other efforts and approaches within the kernel community. David Woodhouse added[4] the excellent news that "We are almost at the point where we can do a spin which remedies [the difficulties of stripping out the non-Free firmware]." He explained that soon a completely separate package instead of a sub-package of the normal kernel build will allow others to produce alternative packages of firmwares for which source code is available. Tom Callaway was worried[5] that there was still firmware entangled in the kernel source code and noted the need for an audit. Rahul Sundaram supplied[6] a link to a Debian inventory of firmwares.

[4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01603.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01605.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01606.html

Other interesting points in the discussion touched on the rationales which have been often advanced for refusing to supply source to firmwares. These involve regulatory compliance (often for radio devices). Alan Cox was suspicious of such arguments based[7] on the history of examples such as ISDN code which "[...] was approved. You could change it but then it became unapproved and not permitted in some countries." He described this as a racket run by the phone companies which imploded once the need to ensure robustness became important (due to terrorist threats.) Ignacio Vazquez-Abrams listed[8] some of the other rationales.

[7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01745.html

[8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01737.html

Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Beats/Developments&oldid=49994"