|
|
| (94 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]] |
|
| |
|
| === Removal of non-X Consoles (continued) === | | === Would You Like to Write This Beat ? === |
|
| |
|
| 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]."
| | 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/Issue143#Non-X.System.Consoles.to.be.Removed
| | <references/> |
|
| |
|
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01341.html
| | === Is gNaughty a Hot Babe ? === |
|
| |
|
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01347.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. |
|
| |
|
| 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.
| | 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/msg01373.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/msg01381.html
| | <references/> |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01388.html
| | === Chrome9 Vx800 Graphics Support on LiveUSB === |
|
| |
|
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01396.html | | [[KristapsViesalgs|Kristaps Viesalgs]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02146.html</ref> for help in getting the Fedora Live USB to boot correctly on a machine using a Via Vx800 "Chrome9" GPU. Kristaps had some success with the latest upstream version (from their subversion repository) and asked: "Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility?" |
|
| |
|
| [[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[.]" | | [[User:Ajax|Adam Jackson]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02154.html</ref> for a more specific bug report because the chip should be supported. He preferred not to ship an autoconfiguration utility instead of just getting the driver correct. Similar points were made by [[User:Adamwill|Adam Williamson]] and [[User:|Xavier Bachelot]]. The latter asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02163.html</ref> any interested developers to help out the openchrome project in both the 2D and 3D(Gallium) sides. |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01353.html
| | <references/> |
|
| |
|
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01354.html
| | === Who Wants a Pony? === |
|
| |
|
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01422.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. |
|
| |
|
| [[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)."
| | <references/> |
|
| |
|
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01401.html
| | === Firestarter Retired as Unportable to PolicyKit === |
|
| |
|
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01407.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>. |
|
| |
|
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01366.html | | Following confirmation from [[User:Sundaram|Rahul Sundaram]] and [[User:Skvidal|Seth Vidal]] a decision was made<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02094.html</ref> by Adam: "I would honestly rather retire the package than do a WONTFIX, if the project as a whole is going the direction of PolicyKit and upstream is dead then I don't want to keep old and busted cruft around the repositories as Fedora continues to look towards the future." |
| | |
| | A further suggestion from "Cry" prompted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02122.html</ref> Adam to start filing RFEs against <code>system-config-firewall</code> for any features present in <code>Firestarter</code> but missing in <code>system-config-firewall</code>. |
| | <references/> |
|
| |
|
| 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.
| | === Russian Fedora ? === |
|
| |
|
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01417.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. |
|
| |
|
| [15] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01445.html | | An assertion by [[User:|Alexey Torkhov]] that there existed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02390.html</ref> a Red Hat-sanctioned "RussianFedora" spin which contained mp3 codecs and other material excluded from the actual Fedora Project repositories drew demands for proof from [[User:Sundaram|Rahul Sundaram]]. |
|
| |
|
| [16] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01484.html
| | <references/> |
|
| |
|
| === OpenVPN and resolv.conf === | | === Will FESCo Revisit Kmods ? === |
|
| |
|
| [[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". | | 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]]. |
|
| |
| [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.
| |
|
| |
|
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01313.html | | [[User:Adamwill|Adam Williamson]] and [[User:Mdomsch|Matt Domsch]] (Dell's DKMS mastermind) kicked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02368.html</ref> some ideas back and forth over the advantages of <code>akmods</code> versus <code>kmods</code>. |
|
| |
| 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."
| |
|
| |
|
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01349.html
| | <references/> |
|
| |
|
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01485.html
| | === Upgrade from Fedora 10 to Rawhide (Fedora 11) === |
|
| |
|
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01490.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." |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01632.html
| | <references/> |
| | |
| 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.
| |
| | |
| [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
| |
| | |
| [[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.
| |
| | |
| [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 ===
| |
| | |
| [[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."
| |
| | |
| [[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.
| |
| | |
| 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.
| |
| | |
| 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 ===
| |
| | |
| [[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.
| |
| | |
| [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.
| |
| | |
| [[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.
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01779.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."
| |
| | |
| [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 <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.
| |
| | |
| [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 [[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/msg00428.html
| |
| | |
| [2] http://fedoraproject.org/wiki/FWN/Issue139#Small.Machine.SIG
| |
| | |
| 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/msg00435.html
| |
| | |
| 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/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). [[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/msg01745.html
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01737.html
| |
Developments
In this section the people, personalities and debates on the @fedora-devel
mailing list are summarized.
Contributing Writer: Oisin Feeley
Would You Like to Write This Beat ?
Following this issue (FWN#178) I will, with regret, no longer be covering the @fedora-devel list. If you are interested in writing this weekly summary of the deeds and doings on the list then please contact fedora-news-list@redhat.com or Pascal Calarco. A short overview of what you may need to do can be obtained by reading the workflow[1] section of the wiki. The @fedora-news list is also extremely open and helpful. Joining[2] the News Project is quite straightforward.
Is gNaughty a Hot Babe ?
Rahul Sundaram posted[1] the results of a survey conducted, primarily on @fedora-list and on the forums, to discover which non-repository-packaged software Fedora consumers were using.
One interesting point is that CMUCL[2] was revealed[3] to be only available for 32-bit systems. However what got people really excited was[4] Rahul's question about what to do concerning the gNaughty package. Its sole purpose seemed[5] to be downloading pornography. Rahul referenced the hot-babe CPU monitor which enjoyed controversy in Debian packaging circles due to its use of female nudity. Rahul wanted to find out "[...] is this allowed in Fedora?"
Amusingly a good deal of the controversy focused on whether the content was freely redistributable, but a predictable moral angle was raised[6] by Muayyad AlSadi who asked for help in producing a spin which removed content deemed objectionable. Muayyad is a Jordanian developer who has been producing an Arabic-localized Fedora spin named "Ojuba" for some time. Muayyad sought a way to make identifying and tagging packages easier to facilitate this spin. Bill Nottingham was[7] skeptical about the chances of tags keeping meaning unless there was some sort of review board. Equally predictable was[8] the reaction typified by Seth Vidal which resisted any attempt to restrict packages according to standards which had nothing to do with licensing or patent issues. Mathieu Bridon thought[9] that the creation of a wiki-page by Muayyad would allow anyone interested in co-ordinating work on "Inappropriate Content" to just go ahead and do it without dragging in bureaucracy.
Chrome9 Vx800 Graphics Support on LiveUSB
Kristaps Viesalgs asked[1] for help in getting the Fedora Live USB to boot correctly on a machine using a Via Vx800 "Chrome9" GPU. Kristaps had some success with the latest upstream version (from their subversion repository) and asked: "Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility?"
Adam Jackson asked[2] for a more specific bug report because the chip should be supported. He preferred not to ship an autoconfiguration utility instead of just getting the driver correct. Similar points were made by Adam Williamson and [[User:|Xavier Bachelot]]. The latter asked[3] any interested developers to help out the openchrome project in both the 2D and 3D(Gallium) sides.
Who Wants a Pony?
Kushal Das promised[1] a pony to anyone that would take the trouble to review[2] one of his packages.
Firestarter Retired as Unportable to PolicyKit
Adam Miller asked[1] whether he should just retire the Firestarter[2] package for which he had recently become the maintainer. His query was based on the recent filing of RFEs to integrate Firestarter with PolicyKit. These suggested to Adam that a large amount of work would be needed due to the lack of any upstream activity for four years and the need to grok PolicyKit.
Following confirmation from Rahul Sundaram and Seth Vidal a decision was made[3] by Adam: "I would honestly rather retire the package than do a WONTFIX, if the project as a whole is going the direction of PolicyKit and upstream is dead then I don't want to keep old and busted cruft around the repositories as Fedora continues to look towards the future."
A further suggestion from "Cry" prompted[4] Adam to start filing RFEs against system-config-firewall for any features present in Firestarter but missing in system-config-firewall.
Russian Fedora ?
When Peter Lemenkov asked[1] about the idea of creating a Fedora Foundation outside of the U.S.A. the usual arguments from the past few years were rehashed. Kevin Kofler gave[2] an able summary why this would still present Red Hat with a problem.
An assertion by [[User:|Alexey Torkhov]] that there existed[3] a Red Hat-sanctioned "RussianFedora" spin which contained mp3 codecs and other material excluded from the actual Fedora Project repositories drew demands for proof from Rahul Sundaram.
Will FESCo Revisit Kmods ?
A discussion of why VirtualBox will not be a feature due to its code not yet heading upstream and consequently remaining as kmods drew a statement of support from Kevin Kofler for reverting the current banning of kmods should he become a FESCo member. Upon request from Richard W.M. Jones for a dispassionate summary of the reasons to avoid kmods drew[1] a concise response from Seth Vidal.
Adam Williamson and Matt Domsch (Dell's DKMS mastermind) kicked[2] some ideas back and forth over the advantages of akmods versus kmods.
Upgrade from Fedora 10 to Rawhide (Fedora 11)
Following a report from Uwe Kiewel that a
yum upgrade
had spewed all sorts of errors the supported methods for upgrades were re-stated[1] by Adam Williamson: "[I]f you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline."
