|
|
| (79 intermediate revisions by the same user not shown) |
| Line 5: |
Line 5: |
| mailing list are summarized. | | mailing list are summarized. |
|
| |
|
| Contributing Writer: [[OisinFeeley|Oisin Feeley]] | | Contributing Writer: [[User:Ush|Oisin Feeley]] |
|
| |
|
| === Features Policy Modified === | | === Would You Like to Write This Beat ? === |
|
| |
|
| The latest FESCo discussions (2008-11-12) clarified[1] the Features[2] process. The changes make explicit the need for testing to be complete one week prior to the final freeze. Failure to meet that condition can result in FESCo deciding to drop the feature or implement a contingency plan or other suitable action.
| | Following this issue (FWN#178) I will, with regret, no longer be covering the @fedora-devel list. If you are interested in writing this weekly summary of the deeds and doings on the list then please contact fedora-news-list@redhat.com or [[User:Pcalarco|Pascal Calarco]]. A short overview of what you may need to do can be obtained by reading the workflow<ref>http://fedoraproject.org/wiki/FWN/WorkFlow</ref> section of the wiki. The @fedora-news list is also extremely open and helpful. Joining<ref>http://fedoraproject.org/wiki/FWN/NewsProject/Join</ref> the News Project is quite straightforward. |
|
| |
|
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00847.html
| | <references/> |
|
| |
|
| [2] Features are "a significant change or enhancement to the version of Fedora currently under development": http://fedoraproject.org/wiki/Features/Policy/Definitions
| | === Is gNaughty a Hot Babe ? === |
|
| |
|
| The spur to these discussions was several last-minute changes for Fedora 10 which included dropping the instant-messaging client Empathy as the default, and the late addition of LiveConnect (see FWN#151[3]) and AMQP[4]. Earlier confusion about the Feature process had been expressed (see FWN#147[5]) after the decision to drop the Lightweight X11 Desktop Environment as a feature.
| | [[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. |
|
| |
|
| [3] http://fedoraproject.org/wiki/FWN/Issue151#LiveConnect_Feature_Approved_for_Fedora_10
| | 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] The Advanced Messaging Queue Protocol is a vendor-neutral middleware transport for business processes: http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol | | 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] http://fedoraproject.org/wiki/FWN/Issue147#LXDE_Feature_Removal_Disappointment_-_How_to_Avoid
| | <references/> |
|
| |
|
| The other major changes to the process include the emailing of the Feature owner to inform them when their feature is being discussed by FESCo and any decisions made concerning said feature. The extra work involved in tracking down email addresses was anticipated to be an over-burdening of the committee chair, [[BrianPepple|Brian Pepple]]. To ease this problem it was decided that Feature owners must include current email addresses on their Feature pages.
| | === Chrome9 Vx800 Graphics Support on LiveUSB === |
|
| |
|
| === Server SIG ===
| | [[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?" |
|
| |
|
| DanHorák announced[1] that a "[...] formal entity to coordinate [...] the server fundamentals that later create a successful enterprise product [...]" had been launched as a SIG. He invited constructive ideas and the wiki page[2] suggests that the SIG has many important initial goals including: a spin for headless servers, CLI equivalents of GUI tools, a lightweight installer and maintenance of the <code>/etc/sysconfig/network-scripts</code>.
| | [[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. |
|
| |
|
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00645.html
| | <references/> |
|
| |
|
| [2] https://fedoraproject.org/wiki/DanHorak/ServerSIG
| | === Who Wants a Pony? === |
|
| |
|
| The extensive discussion which followed mostly consisted of approval for the idea. [[DennisGilmore|Dennis Gilmore]] expressed[3] enthusiasm for the general idea and specifically requested kickstart files for different types of servers and "best practice" whitepapers. An example of one of the issues the SIG might deal with was[4] the observation by [[ChrisAdams|Chris Adams]] that an installation of <code>ntop</code> had resulted in seventy dependencies, including <code>metacity</code>, being pulled down. [[PeterRobinson|Peter Robinson]] attributed[5] this to <code>graphviz</code> and suggested that while such problems were declining in number it would be useful for the ServerSIG to co-ordinate bug filing for these issues. Chris provided[6] a script which allowed test installs into a subdirectory to determine "what gets pulled in." Later [[JamesAntill|James Antill]] mentioned two useful scripts written by himself and [[SethVidal|Seth Vidal]] which show package dependencies and provides as a tree structure. [[DominikMierzejewski|Dominik "rathan" Mierzejewski]] added[7] a mention of <code>rpmreaper</code>, a utility which eases the removal of unnecessary dependencies.
| | [[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. |
|
| |
|
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00652.html
| | <references/> |
|
| |
|
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00730.html
| | === Firestarter Retired as Unportable to PolicyKit === |
|
| |
|
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00736.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>. |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00778.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/> |
|
| |
|
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00932.html
| | === Russian Fedora ? === |
|
| |
|
| After Chris observed that "[w]ith rawhide, it appears impossible to install a kernel without pulling in X libraries (because of plymouth), so I guess the base X libraries can be considered "core" now" the conversation took a more adversarial turn. The accuracy of this statement turned out[8] to depend on whether <code>libpng</code> and <code>pango</code> were considered to be "X libraries" and Chris demonstrated the dependency chain as originating with the <code>plymouth-plugin-solar</code>. [[LesMikesell|Les Mikesell]] commented[9]: "This is all pretty strange from a server perspective. And plymouth is there to keep the screen from blinking while you boot?" When [[JesseKeating|Jesse Keating]] replied that Plymouth "handl[ed] the passphrase prompting for encrypted volumes" Les argued[10] that it should be optional for remote, headless boxes. [[DominikMierzejewski|Dominik "rathann" Mierzejewski]] was shocked[11] when [[JesseKeating|Jesse Keating]] pointed out that <code>plymouth</code> also provided working <code>/var/log/boot.log</code>s: " Hm, you're right, all my boot.log files are 0 bytes (F-9). So instead of fixing the bug, a new package was introduced? Amazing." Dominik's dissatisfaction continued[12] to be unabated when he was informed that the absence of the kernel commandline parameter "rhgb" would result in <code>plymouthd</code> running but without any graphical plugins.
| | 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. |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00787.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]]. |
|
| |
|
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00787.html
| | <references/> |
|
| |
|
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00795.html
| | === Will FESCo Revisit Kmods ? === |
|
| |
|
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00814.html | | A discussion of why <code>VirtualBox</code> will not be a feature due to its code not yet heading upstream and consequently remaining as <code>kmods</code> drew a statement of support from [[User:Kkofler|Kevin Kofler]] for reverting the current banning of <code>kmods</code> should he become a FESCo member. Upon request from [[RichardJones|Richard W.M. Jones]] for a dispassionate summary of the reasons to avoid <code>kmods</code> drew<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02254.html</ref> a concise response from [[User:Skvidal|Seth Vidal]]. |
|
| |
|
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00859.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 automatic selection of <code>plymouth-plugin-solar</code> as opposed to the alternate "plymouth-text-and-details-only" resulted[13] in a discussion around whether it was possible to make <code>yum</code> behave differently in such ambiguous situations. [[EnricoScholz|Enrico Scholz]] wished to add a "fail, warn and/or prompt when multiple packages satisfy a (virtual) dependency[.]" [[SethVidal|Seth Vidal]] reminded[14] him that the constraint of non-interactive defaults meant that this might not work. [[JamesAntill|James Antill]] posted[15] that he had a patch to <code>yum</code> which "[...] would allow Fedora (or any active repo.) to configure these choices manually. We could then also easily have different defaults for the desktop vs. the server spins." James received some questions from [[JesseKeating|Jesse Keating]] and [[BillNottingham|Bill Nottingham]] who asked how per-spin defaults would be stored and how to deal with conflicting information from multiple repositories. His answer suggested[16] that introducing new repositories for the metadata or changing its syntax would be necessary.
| | <references/> |
|
| |
|
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00858.html
| | === Upgrade from Fedora 10 to Rawhide (Fedora 11) === |
|
| |
|
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00907.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." |
|
| |
|
| [15] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00995.html
| | <references/> |
| | |
| [16] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01030.html
| |
| | |
| [[DanHorák|Dan Horák's]] desire to remove <code>plymouth</code> entirely was dismissed[17] as non-optional by [[BillNottingham|Bill Nottingham]] as it will take on an even more important role in storage handling in the future. Bill suggested that the default plugin was optional however. He reassured[18] Dan that as regards headless machines there had been "[...] some testing on PPC boxes via serial/hvc consoles. Please test that it works in your scenarios as well, of course." When [[EnricoScholz|Enrico Scholz]] rejected disk encryption as important for servers [[JesseKeating|Jesse Keating]] made[19] the case that "In a colo environment I /would/ want some encryption on the disk, and if I have to use a remote kvm to input the passphrase at reboot time, that's OK. Reboots are either planned events, or emergencies, both of which are going to require the attention of the people who have the passphrase." [[AlanCox|Alan Cox]] backed[20] this up: "If you are storing personal data on a system in a colo its practically mandatory to have encryption, and if you are storing anything sensitive its a big deal indeed - at least in those parts of the world with real data and privacy law ;)"
| |
| | |
| [17] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00784.html
| |
| | |
| [18] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00792.html
| |
| | |
| [19] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00798.html
| |
| | |
| [20] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00823.html
| |
| | |
| The thread continued in fits and starts. [[AdamTkac|Adam Tkac]] raised[21] the problem of handling static IPs with <code>NetworkManager</code> (see this same FWN#152 "NetworkManager keyfiles for Pre-login Static Routes" for a discussion of as yet undocumented features). [[ChuckAnderson|Chuck Anderson]] disputed[22] that the problem existed and provided commandline and GUI solutions: "[...] for system-wide connections which you would presumably want for a server, you edit /etc/sysconfig/networkscripts/ifcfg-* as usual and NM will bring the interface up at boot. From the desktop, you can Edit Connections and create a new static connection and select it instead of the System or Auto connection which is very handy when moving between networks that don't support DHCP."
| |
| | |
| An important addendum was provided[23] by [[OlivierGalibert|Olivier Galibert]] "Try a "chkconfig -list network". It should be on for levels 2-5. If it isn't, you haven't enabled the old-style networking [.]" The same point was made by Chuck[24] "Are you using NetworkManager or network service? chkconfig -list NetworkManager; chkconfig -list network If NetworkManager is enabled and network is not, then you need to change ifcfg-eth0: NM_CONTROLLED=yes" and by [[BillNottingham|Bill Nottingham]][25] "You need to either set NM_CONTROLLED to something other than 'no', or enable the 'network' service. In either case, NM's static network support is not your problem."
| |
| | |
| [21] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00863.html
| |
| | |
| [22] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00871.html
| |
| | |
| [23] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00892.html
| |
| | |
| [24] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00887.html
| |
| | |
| [25] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00938.html
| |
| | |
| The LSB[26] also came in for a bashing due to infrequently used, old tools (such as <code>ypbind</code> and the insecure r-commands) being installed to achieve compliance. [[PatriceDumas|Patrice Dumas]] clarified[27] that <code>ypbind</code> was necessary in <code>@base</code> to provide <code>NIS</code> functionality. Later discussion separated[28] out LSB-Core and LSB-Desktop which should simplify making a minimal install LSB compliant. [[BillNottingham|Bill Nottingham]] and [[ChrisAdams|Chris Adams]] performed[29] a dissection of <code>@core</code> with the intent of separating out items such as <code>hdparm</code> , <code>prelink</code> , <code>dhclient</code> , <code>ed</code> and others into <code>@base</code>.
| |
| | |
| [26] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00718.html
| |
| | |
| [27] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00753.html
| |
| | |
| [28] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00759.html
| |
| | |
| [29] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00802.html
| |
| | |
| [[JeremyKatz|Jeremy Katz]] outlined[30][31] a perspective from the Quality Assurance point of view. The burden imposed by preserving the modularity that many of the participants advocated sounds quite high: "[...] trying to preserve that modularity combinatorially adds to the testing matrix and also makes it significantly more difficult to write code since you can no longer depend on functionality. It also makes things slower as you have to conditionally check for things constantly [...] It's more than just /etc/init.d/network that has to be maintained. There's oodles of stuff in install-time configuration that will have to be maintained, tested, and have things fixed when people report them." [[SethVidal|Seth Vidal]] acknowledged[32] this but cautioned against dismissing the objections to particular changes as merely "neoluddite".
| |
| | |
| [30] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01023.html
| |
| | |
| [31] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01025.html
| |
| | |
| [32] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01027.html
| |
| | |
| The massive thread included much more discussion and resists easy summary. Those interested should probably plow through the messages. Among the issues raised were finding DBus documentation[33] and contention between class devices to set default routes[34].
| |
| | |
| A quote from DanHorak which seems to offer the perspective of the ServerSIG concisely is appropriate in closing: "It is really time to look back at the roots of Unix systems. It should be a combination of small pieces with well defined interfaces doing well their tasks. Only the time had changed those pieces from simple command line utilities to more complex ones."
| |
| | |
| [33] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01071.html
| |
| | |
| [34] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00911.html
| |
| | |
| === NetworkManager keyfiles for Pre-login Static Routes ===
| |
| | |
| In the course of the ServerSIG discussions (see this same FWN#152 "Server SIG") an interesting question about <code>NetworkManager</code> was asked[1] by [[LesMikesell|Les Mikesell]]: "If you bring up a mix of static and dynamically assigned interfaces, can you control which gets to assign the default route and DNS servers?"
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00872.html
| |
| | |
| [[DanWilliams|Dan Williams]] provided[2] a useful description of how <code>NetworkManager</code> currently decides the default route. In response to [[OlivierGalibert|Olivier Galibert]] he added[3] that static routes could be set up using the "[...] connection editor see the "Routes..." button in the IPv4 tab. Routes from ifcfg files aren't yet supported, but could be. Routes from keyfile-based system connections (ie, prelogin) are supported." After this tidbit [[ChuckAnderson|Chuck Anderson]] prodded[4] Dan into explaining that keyfiles were a way to support things like "VPN, 3G, WPA" which were difficult or impossible to support with the ifcfg files in <code>/etc/sysconfig/network-scripts</code>. "NM has a system settings 'keyfile' plugin that allows editing system connections from the connection editor, or your favorite text editor if you don't use a GUI at all. Add `,keyfile' to the --plugins argument in the /usr/share/dbus-1/systemservices/org.freedesktop.NetworkManagerSystemSettings.service file, and then 'killall -TERM nm-system-settings'."
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00880.html
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00897.html
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00900.html
| |
| | |
| [[JesseKeating|Jesse Keating]] wondered when and where the documentation for this was placed and Dan replied[5] "[w]hen I struggle up for air from the tarpit that is the concurrent release of NM 0.7 + F10 + RHEL 5.3? :) "
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00912.html
| |
| | |
| === Flash 10 in 64-bit Fedora 9 ===
| |
| | |
| [[JosVos|Jos Vos]] asked[1] for comparative data on using <code>nspluginwrapper</code> with <code>Firefox</code> to access <code>Flash</code> content in 64-bit Fedora 9. He was experiencing "[...] error messages about not finding 'soundwrapper' in my $PATH [.]"
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00432.html
| |
| | |
| Although [[ChrisAdams|Chris Adams]] reported success [[OrcanOgetbil|Orcan Ogetbil]] described[2] a "gray rectangle bug" which seemed to be manifested mostly when multiple tabs were open. [[BrennanAshton|Brennan Ashton]] claimed[3] that it was due to a <code>PulseAudio</code> "bug".
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00439.html
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00443.html
| |
|
| |
| [[IgnacioVazquez-Abrams|Ignacio Vazquez-Abrams]] and others reported[4] no problems and Jos posted[5] that there appeared to be a dependency on <code>libcurl.i386</code> in the Adobe supplied <code>rpm</code>. This was later stated[6] by [[PaulHowarth|Paul Howarth]] to be changed so that either <code>libcurl.so.3</code> or <code>libcurl.so.4</code> will be used via a <code>dlopen()</code> and there is no explicit <code>requires:libcurl</code> in the rpm. [[GianlucaSzforna|Gianluca Szforna]] supplied[7] a link[8] which suggests that <code>libflashsupport</code> should be completely removed as it may cause crashes.
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00437.html
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00445.html
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00479.html
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00484.html
| |
| | |
| [8] http://macromedia.mplug.org/
| |
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."
