|
|
| (17 intermediate revisions by the same user not shown) |
| Line 7: |
Line 7: |
| Contributing Writer: [[User:Ush|Oisin Feeley]] | | Contributing Writer: [[User:Ush|Oisin Feeley]] |
|
| |
|
| === Fedora 10 Packages in dist-f11 === | | === Would You Like to Write This Beat ? === |
|
| |
|
| [[KalevLember|Kalev Lember]] drew attention<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01934.html</ref> to the issue of .fc10 packages ending up in rawhide by error during the freeze. Kalev worried that he had done something wrong to make the rawhide composes pull .fc10 rpms from the <code>Fedora 10</code> stable-updates repository. | | 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. |
| | |
| [[User:Jwboyer|Josh Boyer]] thanked Kalev for identifying the issue and explained that it was an error due to koji tag inheritance. [[User:Jkeating|Jesse Keating]] added<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01969.html</ref> that his efforts to ease tag requests had forgotten to take tag inheritance into account but that he would fix this shortly.
| |
|
| |
|
| <references/> | | <references/> |
|
| |
|
| === Bugzilla Passwords === | | === Is gNaughty a Hot Babe ? === |
|
| |
|
| Another thread about bugzilla (see also this FWN#173 "FOSS Needs a Central Bugtracker" and "Fedora Bugtracker Independent from Red Hat?") concerned<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01562.html</ref> itself with the automated requirement to change to a new user password. [[FelixMiata|Felix Miata]] was upset that he could not use previous passwords: "If you won't let me choose my password, I have no use for you. I have too many systems and web browsers to use and too many places that need passwords for any site to decide I can't use my choice of password [...] I've changed banks over lesser stupidities."
| | [[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. |
|
| |
|
| [[User:Thias|Matthias Saou]] and [[User:Ianweller|Ian Weller]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01600.html</ref> a dirty work-around. [[KonstantinRyabitsev|Konstantin Ryabitsev]] suggested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01576.html</ref> using <code>supergenpass</code><ref>http://supergenpass.com/</ref>. Basil Mohamed Gohar and [[User:Adamwill|Adam Williamson]] liked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01579.html</ref> the GNOME combination of <code>Password Generator</code> and <code>Revelation</code>.
| | 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?" |
|
| |
|
| After some questioning of the motivations and need for such password changes [[User:Jkeating|Jesse Keating]] rationalized<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01611.html</ref> regular password changes a little sarcastically: "There is a theory that changing passwords on a regular bases lessens the risk of somebody's password being stolen and used nefariously. Depending on the account compromised the damage increases from nuisance to legally damaging[...]" and suggested that a more worthwhile discussion would be "[...] whether or not the pains we hit here are worth the pains we'd encounter by running our own instance of bugzilla."
| | 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. |
| | |
| This questioning started<ref><https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01593.html/ref> to hone-in on the idea that the changes were done mainly to fulfil Red Hat business requirements and [[User:Adamwill|Adam Williamson]] reminded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01653.html</ref> the list that there was "[...] a plausible case that doesn't involve Red Hat data - not-yet-public security issues - was subsequently cited. Even if we split Fedora bugzilla from Red Hat bugzilla, it'll still contain sensitive data."
| |
|
| |
|
| <references/> | | <references/> |
|
| |
|
| === PulseAudio: A Hearty and Robust Exchange of Ideas === | | === Chrome9 Vx800 Graphics Support on LiveUSB === |
|
| |
|
| A long, multi-thread flamewar over the (dis)advantages of the new <code>VolumeControl</code> (more specifically <code>gnome-volume-control</code>) applet in Fedora 11 smoked and crackled. The <code>gnome-volume-control</code> applet provides a highly simplified interface to the PulseAudio<ref>http://www.pulseaudio.org/</ref> sound server, itself a source of contention for some time. The extent of this simplification contrasted to the old volume-control applets which talked directly to ALSA and exposed all the details of a card was emphasized<ref>http://people.redhat.com/alexl/files/why-alsa-sucks.png</ref><ref>http://www.codemonkey.org.uk/junk/wtf/alsa-mixer-o-doom.jpg</ref> in screenshots of the "Alsa-Mixer-O-Doom" posted by [[DaveJones|Dave Jones]] and [[User:Wwoods|Will Woods]]. A bugzilla filed<ref>http://bugzilla.redhat.com/show_bug.cgi?id=491372</ref> by [[User:Adamwill|Adam Williamson]] explains that hiding the mixer channels makes it difficult to handle many scenarios which require the adjustment of specific mixer channels in order to achieve basic sound functionality.
| | [[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?" |
|
| |
|
| Although there has been prolonged sniping at PulseAudio for some time this week's dispute seemed more unpleasant and prolonged than many. Its tangled, sprawling mess eventually drew in FESCo and flung its tendrils into issues of whether FESCo should dictate UI design and the possible reversion<ref>http://fedoraproject.org/wiki/Meeting:FESCo-2009_04_24#tApr_24_12:18:57</ref> of the entire "VolumeControl" feature<ref>http://fedoraproject.org/wiki/Features/VolumeControl</ref><ref>https://fedoraproject.org/wiki/Meeting:FESCo-2009_04_24#tApr_24_12:24:37</ref>, and whether FESCo had<ref>https://fedoraproject.org/wiki/Meeting:FESCo-2009_04_24#tApr_24_12:50:33</ref> jurisdiction over what went into the Desktop spin.
| | [[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. |
|
| |
|
| The first thread started<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01452.html</ref><ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01729.html</ref> in [[CallumLerwick|Callum Lerwick]]'s request for information on how to adjust volume informations on individual channels. He explained that he was hooking a second computer up to the "line-in" to share speakers and needed to adjust the <code>PCM</code> volume. [[BastienNocera|Bastien Nocera]] thought<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01485.html</ref> that Callum's use case was esoteric and would not be accomodated. He suggested using PulseAudio over the network instead. A later report by [[JoonasSarajärvi|Joonas Sarajärvi]] suggested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02000.html</ref> this should be possible.
| | <references/> |
|
| |
|
| Things went downhill from then on when Callum asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01522.html</ref> for "[...] an option to get the old damn panel applet back [or] at least a secret gconf key to do what I want?" and characterized the <code>Volume Control</code> applet as "immature". Bastien's response was<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01634.html</ref> that the applet had been described for over a year on the wiki and he suggested the <code>GConf</code> was not of use because the volume control worked at the level of PulseAudio and not ALSA. [[User:Lennart|Lennart Poettering]] also suggested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01830.html</ref> that using <pre>alsamixer -c0</pre> on the command-line would provide the level of control desired for those who wanted "pretty exotic feature[s and] weird stuff like [playing audio through line-in]." Many insults were exchanged<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01862.html</ref>.
| | === Who Wants a Pony? === |
|
| |
|
| [[User:Kkofler|Kevin Kofler]] helpfully responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01721.html</ref> to [[CallumLerwick|Callum Lerwick]]'s complaint that <code>Pidgin</code> alert sounds exploded his speakers with the suggestion that he edit <code>/etc/pulse/daemon.conf</code> to <pre>flat-volumes = no</pre> | | [[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. |
|
| |
|
| Following suggestions from Lennart and [[User:Kkofler|Kevin Kofler]] success was finally achieved<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02164.html</ref><ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02174.html</ref> in loading the alsa-sink module so that the PCM volume could be controlled.
| | <references/> |
|
| |
| Elsewhere in this thread Lennart provided several high-level overviews of how sound should be handled on a desktop including obsoleting playing audio CDs via the classic "analog" path<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01955.html</ref>
| |
|
| |
|
| A question from [[AndreasThiemann|Andreas Thiemann]] asked how it came about that while his sound volume was acceptable with the <code>MS Windows</code> software mixer set to 75% and the physical speaker volume set to 50% he needed to set all of the physical volume, <code>gnome-volume-control</code> and the PCM volume (via an ALSA mixer) to 100% to achieve similar volumes on <code>GNU/Linux</code>. Lennart explained<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01876.html</ref> that this was due to insufficient information in the alsa mixer init database and that patches to this database from anyone needing to manually fix their settings would be very useful. Apparently "[...] unning alsamixer -c0 alsa will remember [the fixed settings] and hence [users] never get annoyed by [sound problems] anymore so they don't remember to post [these patches to the database.]" Lennart expanded<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01895.html</ref><ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01897.html</ref> on how to generate such patches to <code>alsa-utils'</code> <code>/lib/alsa/init/hda</code>. [[User:Adamwill|Adam Williamson]] worried<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01914.html</ref> that the roots of this specific problem lay elsewhere.
| | === Firestarter Retired as Unportable to PolicyKit === |
|
| |
|
| The aforementioned database suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02134.html</ref><ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02150.html</ref> to [[DavidWoodhouse|David Woodhouse]] a need for a way for users to manually tweak their sound settings for the inevitable cases in which the database lacked (or contained inaccurate) information on specific hardware. David also explained<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02160.html</ref> that the new <code>VolumeControl</code> applet was not yet ready for prime-time in his opinion.
| | [[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>. |
| | |
| The thread was summarized<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02001.html</ref> beautifully by Fernando Lopez-Lezcano as an infinite loop.
| |
| | |
| A second thread was started by [[DimiPaun|Dimi Paun]] in which he bemoaned<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01870.html</ref> some unspecific problems with sound in <code>Fedora 11</code>. This was met with mixed anecdotal statements confirming or denying the general assertion and a request for specific bugzilla entries.
| |
| | |
| A third thread was initiated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02003.html</ref> by [[User:Adamwill|Adam Williamson]]. He proposed "[...] in the spirit of light rather than heat [to] include by default an alternative GUI app which allows direct access to the mixer channels. This won't be an applet or anything else persistent, just an application that you can choose to run if you need that level of access[.]" It should be noted that this proposal addressed a different problem to the one expressed by [[CallumLerwick|Callum Lerwick]] (solved as noted above by poking around at ALSA), instead it addressed some of the other relatively frequent complaints.
| |
| | |
| By this time tempers were very frayed and although there was strong agreement that this temporary, stop-gap measure was a good compromise for <code>Fedora 11</code> there were plenty of histrionics. [[User:Jkeating|Jesse Keating]] 's suggestion that the alternative GUI application contain "some text [...] that instructs people to file bugs [so] we can capture the use cases that the default mixer is missing and help the developers better target things" was dismissed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02014.html</ref> by [[OlivierGalibert.|Olivier Galibert]] Olivier asserted that Lennart would not fix such bugs: "You may not have noticed, but when people indicate a case that is seemingly not supported by PA[1], politely and everything, the answer by the main PA developer is either one or both of `don't use PA then' or `your use case is rare and uninteresting and won't be supported'." [[DavidWoodhouse|David Woodhouse]] reinforced<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02044.html</ref> the point and argued that too many bugs were closed by PulseAudio developers as WONTFIX. [[User:Adamwill|Adam Williamson]] returned<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02066.html</ref> to his central point which was that "[...] new g-v-c has no way to select the input device. If the default does not happen to be the one you actually want to record from, you're stuck. The rest of the cases discussed have really been either bugs or corner cases and I'm not too concerned about those, the bugs will be fixed and we shouldn't worry about corner cases too much. Input switching is the biggie, and it is not a `legacy use case', it is half of the functionality of any sound adapter. Lennart has acknowledged this as a missing feature that will be added in the F12 timeframe, which is why I've already said that as long as that happens - and most of the `the slider doesn't really control my volume' bugs are fixed - I'd be happy for the alternative mixer not to be
| |
| installed by default from F12 on."
| |
| | |
| Lennart responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02137.html</ref> to arguments from [[User:Kkofler|Kevin Kofler]] and [[DavidWoodhouse|David Woodhouse]] that the new <code>gnome-volume-control</code> was too simplified with an assertion that most current soundcards offloaded signal processing to CPUs with MMX and SSE extension. This, he argued, meant that "the only controls that are really necessary are NOT those which control signal processing but those which control routing."
| |
| | |
| Towards the end of all this FESCo held its weekly meeting and the IRC logs<ref>http://fedoraproject.org/wiki/Meeting:FESCo-2009_04_24</ref> contain a full record of what KevinFenzi's "FESCo Meeting Summary for 2009-04-24" handily summarizes as: "Long and contentious discussion about concerns with the VolumeControl feature. FESCo decided to get gnome-alsamixer packaged and added to the default desktop live/install spins to allow users whos use cases are not covered currently by VolumeControl to have a GUI way to adjust mixer settings. Hopefully this will be dropped/revisited in F12." [[DavidWoodhouse|David Woodhouse]] described<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02120.html</ref> this as a compromise about which he had serious reservations.
| |
| | |
| [[ChristopherAillon|Christopher Aillon]] expressed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02047.html</ref> unhappiness with post-freeze changes and cited the unhappy example of <code>Codeina</code>. [[User:Jkeating|Jesse Keating]] refuted<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02050.html</ref> the comparison as "[...] a compromise for the sake of F11 was reached, one that doesn't require any changes to existing software, only the addition of one package. Comparing it to the Codina fiasco isn't exactly fair."
| |
| | |
| An insightful discussion about the relationship between the "desktop spin" and the "default spin" was conducted between [[User:Pfrields|Paul W. Frields]]<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02082.html</ref>, [[User:Toshio|Toshio Kuratomi]]<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02108.html</ref> and others. KevinFenzi and [[User:Adamwill|Adam Williamson]] did not<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02191.html</ref> agree with Paul that the functionality provided by <code>gnome-alsamixer</code> was "bit-twiddling" and saw it instead as basic and frequently desired.
| |
| | |
| As of going to press personal abuse of [[User:Lennart|Lennart Poettering]] continued unabated.
| |
|
| |
|
| | 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/> | | <references/> |
|
| |
|
| === Re-starting udev === | | === Russian Fedora ? === |
|
| |
|
| Following a security flaw in <code>udev</code><ref>http://cert.belnet.be/belnetadvisories/rhsa-20090427-01-important-udev-security-update</ref> for which patches were<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01702.html</ref> quickly made available "Dennis J." asked<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01698.html</ref>: "What is the proper procedure to update infrastructure components like udev or hal without rebooting the machine? udev for example doesn't have an init script." Dennis pointed out that with virtualization becoming more common reboots of host machines are something which it would be nice to avoid.
| | 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. |
|
| |
|
| M.A. Young provided<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01714.html</ref> the information that <code>udevd</code> is started from <code>/etc/rc.d/rc.sysint</code> and can be restarted with:
| | 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]]. |
| <pre>/sbin/start_udev</pre>
| |
|
| |
|
| <references/> | | <references/> |
|
| |
|
| === Fedora Bug-tracker Independent from Red Hat ? === | | === Will FESCo Revisit Kmods ? === |
| | |
| Basil Mohamed Gohar asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01667.html</ref> for constructive criticism of a proposal which would result in the Fedora Project community hosting its own bugzilla instance. Basil attempted to provide some guidelines for the discussion.
| |
| | |
| Although several participants admitted that it would be nice if bugzilla were faster [[User:Wwoods|Will Woods]] identified<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01668.html</ref> resource constraints which rendered the discussion pointless: "This discussion is moot unless you can find someone with the manpower, hardware, bandwidth, and expertise to maintain such a bug tracker - 24/7/365 - for the entire Fedora community. So far we've identified *one* organization willing to do that - Red Hat's Bugzilla team. Unless you've got someone else who can commit to that, there's really nothing else to discuss."
| |
|
| |
|
| A practical disadvantage pointed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01679.html</ref> out by [[User:Mmcgrath|Mike McGrath]] of implementing Basil's scheme was that currently users of Fedora, Red Hat and CentOS only need to go to a single place to file bugs. | | 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]]. |
|
| |
|
| [[MatejCepl|Matēj Cepl]] ranted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01809.html</ref> a little when Basil approved of the "FOSS Needs a Central Bugtracker?" thread (see this same FWN#173). Matej quoted<ref>http://slashdot.org/features/98/10/13/1423253.shtml</ref> Alan Cox's essay advising how to "Beware `We should', extend a hand to `How do I?'". | | [[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>. |
|
| |
|
| <references/> | | <references/> |
|
| |
| === FOSS Needs a Central Bugtracker ? ===
| |
|
| |
|
| Markg85 started<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01414.html</ref> a longish thread in which he proposed to start a single FOSS bugtracker for "[the] top 10 major foss distributions for now i think[.]"
| | === Upgrade from Fedora 10 to Rawhide (Fedora 11) === |
|
| |
|
| [[DavidWoodhouse|David Woodhouse]] thought<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01624.html</ref> that <code>OpenID</code> might be simpler, but wondered what sort of bugs would be filed by people without the attention-span to register for an account with each bug tracker. [[ColinWalters|Colin Walters]] also suggested<ref>https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01535.html</ref> on focusing on less universal solutions and proposed "[...] more tractable, incremental problem to take on that would get us closer to what you want, consolidating project hosting would be a good start. For example, I'm very much against developers hosting projects on e.g. some old Trac instance on their personal vserver, for many reasons, among them that if at some later time they get bored or whatever, the server goes down and with it a lot of useful data." | | 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." |
|
| |
|
| <references/> | | <references/> |
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."
