From Fedora Project Wiki

< FWN‎ | Beats

m (s/https/http)
(fwn 173 pass 1)
Line 7: Line 7:
 
Contributing Writer: [[User:Ush|Oisin Feeley]]
 
Contributing Writer: [[User:Ush|Oisin Feeley]]
  
=== Frozen for Fedora 11. Some Packages Still Not Built dist-f11 ===
+
=== Fedora 10 Packages in dist-f11 ===
  
[[User:Jkeating|Jesse Keating]] announced<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00892.html</ref> that henceforth all F-11/ builds would go to dist-f11-updates-candidate and builds from devel/ would go to dist-f12. He asked for concerned parties to check that builds were being properly tagged.
+
[[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.
  
In response to [[User:Miketc302|Mike Chambers]]' question Jesse confirmed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00954.html</ref> that the nightly rawhide composes would consist of <code>Fedora 11</code> content until the GOLD packages were on their way out to the mirrors at which point the nightly rawhide composes would contain <code>Fedora 12</code> content.
+
[[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.
  
On a related note [[User:Notting|Bill Nottingham]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01160.html</ref> maintainers of a list of packages not yet rebuilt in dist-f11 (with the attendant compiler and strong RPM hashes) to fix them if possible. [[User:Jkeating|Jesse Keating]] provided<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01189.html</ref> a slightly more aggressive list as an addendum.
+
<references/>
 +
 
 +
=== Bugzilla Passwords ===
 +
 
 +
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."
  
<references/>
+
[[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></ref> the GNOME combination of <code>Password Generator</code> and <code>Revelation</code>.
 
=== Xorg Hacking Solves DontZap ===
 
  
[[PeterHutterer|Peter Hutterer]] made some valuable contributions to resolving the furore over the disabling of the zapping of the Xorg server via the Ctrl-Alt-Backspace key combination<ref>http://fedoraproject.org/wiki/FWN/Issue171#Zap_DontZap</ref>.
+
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."
  
[[User:Spot|Tom Callaway]] drew attention<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00700.html</ref> to a blog entry of Peter's which mentioned upstream patches by Julien Cristau (of Debian) to <code>xkeyboard-config</code> and Peter's own patch<ref>http://lists.freedesktop.org/archives/xorg-devel/2009-April/000626.html</ref> to <code>Xserver</code> which together make it possible to disallow zapping by default and also to turn zapping on with a <pre>'setxkbmap -option terminate:ctrl_alt_bksp'</pre>. The net result is that it is possible to get zapping to work but the <code>XKB</code><ref>http://www.charvolant.org/~doug/xkb/html/index.html</ref> configuration needs to be set up properly and the DontZap option left disabled (as per the new default).  
+
This questioning started 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."
  
In discussion with [[User:Kkofler|Kevin Kofler]] Peter clarified<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00861.html</ref> the situation in which the new settings would take effect. Kevin responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00863.html</ref> that it appeared that for <code>KDE</code> users zapping with Ctrl-Alt-BkSp would remain as before.
+
<references/>
  
Later Peter answered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00838.html</ref> some questions from [[User:Surenkarapetyan|Suren Karapetyan]] about the ability to kill broken X grabs with details about how zapping works.
+
=== PulseAudio: A Hearty and Robust Exchange of Ideas ===
  
The above summary of an elegant technical solution ignores the long, and at times vitriolic, complaints about this change. A common trope occurring in some recent threads seems to be that changes are made by Red Hat employees who are implementing changes without community consultation and all work to a common game plan. [[User:Skvidal|Seth Vidal]] challenged<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01059.html</ref> the latter assumption:"In a survey of 10 RH employees you will find between 10 and 40 different opinions. sometimes more if you don't ask some of them to confine their comments to a limited amount of time."  In any event it's worth noting that the resolution (which filters the "Terminate_Server" action in a manner consistent<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01173.html</ref> with the handling of other actions in xkb rulesets) was contributed upstream by a Red Hat employee. As a point of information [[User:Kevin |Kevin Fenzi]] also made it clear that the change had not been instigated by FESCo.
+
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> applet provides a highly simplified interface to the PulseAudio<ref></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 WillWoods. 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.
  
The new options presented by Peter were in addition to those already suggested<ref>http://fedoraproject.org/wiki/Fedora_11_Beta_release_notes#X_server</ref> in the beta Release Notes.
+
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.
  
<references/>
+
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></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.
  
=== Minesweeper Certified Solitaire Professionals Satisfied with DVD ===
+
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>.
  
[[User:Jkeating|Jesse Keating]] requested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00943.html</ref> help in selecting which packages should be dropped from the DVD image. He suggested some java development packages and games.  
+
[[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>
  
Feedback suggested that retaining the games was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00947.html</ref> preferred and dropping the development libraries made sense as the latest versions would be needed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00981.html</ref> and could be obtained from the repositories anyway. Jesse later posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01037.html</ref> this was sufficient to achieve the desired image size.
+
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.
 +
 +
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 side-issue discussed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01019.html</ref> was the unwieldiness of <code>jigdo</code> as a download method. [[CallumLerwick|Callum Lerwick]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01246.html</ref> that <code>jigdo</code> would benefit from a userspace ISO implementation.
+
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.
  
<references/>
+
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.
  
=== Presto and DeltaRPM Status ===
+
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.
  
The ability to download binary diffs of RPM packages has been offered<ref>http://fedoraproject.org/wiki/FWN/Issue97#Presto-digitation</ref> for some time now on Fedora through the <code>Presto</code><ref>http://fedorahosted.org/presto/</ref> project and presto-enabled repositories. Interest is high enough in Presto's bandwidth-saving abilities that no fewer than three separate threads were started to ensure that it would function properly for <code>Fedora 11</code>.
+
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.
  
[[WarrenTogami|Warren Togami]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00701.html</ref> if <code>Presto</code> would be enabled by default for <code>Fedora 11</code>. Last month (2009-03-21) [[User:Jdieter|Jonathan Dieter]] reported<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01910.html</ref> that the use of <code>SHA-256</code> in <code>rpm</code> had broken <code>deltarpm</code> but that a patched version was available in rawhide. See FWN#166<ref>http://fedoraproject.org/wiki/FWN/Issue166</ref> for earlier coverage of the challenges and changes resulting from the introduction of stronger hashes<ref>http://fedoraproject.org/wiki/Features/StrongerHashes</ref>. 
+
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.
Jonathan also reported that the changes necessary in infrastructure to build deltarpms had been done. These changes were made fairly rapidly thanks to work done<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00528.html</ref> Michael Schroeder, the upstream <code>deltarpm</code> developer. One issue that concerned<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01236.html</ref> [[User:Athimm|Axel Thimm]] was the security with which checksums of deltarpms were being made. [[User:Till|Till Maas]] and [[User:Jdieter|Jonathan Dieter]] provided<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01240.html</ref> reassurance that all deltarpms are generated from original rpms which needed to pass all verifications which <code>yum</code> and <code>rpm</code> enforce.  
 
  
[[User:Mso|Martin Sourada]] was excited<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01262.html</ref> not just about <code>Presto</code> but also about the slick new <code>PackageKit</code> in <code>Fedora 11</code>. Martin was concerned about the issue of <code>PackageKit</code> and <code>Presto</code> apparently not working well together. A bugzilla entry revealed<ref>http://bugzilla.redhat.com/show_bug.cgi?id=496445</ref> that <code>PackageKit</code> developer [[User:|Richard Hughes]] quickly created a patch which Martin reported as working.
+
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."
  
On 2009-04-16 [[User:Notting|Bill Nottingham]] added to the "Rawhide Report" that "[...] rawhide is composed with deltarpms against the prior rawhide. Due to a bug, this is only currently working on i386; it should be fixed for other arches tomorrow. Please test and report any issues."  
+
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."
  
A Fedora Test Day centering around Presto was also announced<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00939.html</ref> by [[User:|James Laska]]. The usual excellent wikipage<ref>http://fedoraproject.org/wiki/Test_Day:Presto_2009-04-16</ref> suggests that <code>Presto</code> can deliver significant bandwidth savings.
+
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.  
  
<references/>
+
[[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."
  
=== Browser Plugins May Strip SELinux Protections ===
+
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.
  
[[DanielWalsh|Daniel Walsh]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01107.html</ref> why <code>mozplugger</code><ref>Mozplugger describes itself as "[a] general purpose Mozilla plugin module that allows the user to embed and launch their favorite application to handle the various different types of media found on the Internet." http://mozplugger.mozdev.org/</ref> was being installed by default. He cautioned that <code>mozplugger</code> broke <code>nsplugin</code> and thus <code>SELinux</code> functionality.
+
As of going to press personal abuse of [[User:Lennart|Lennart Poettering]] continued unabated.
  
An answer posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01111.html</ref> by [[User:Notting|Bill Nottingham]] pointed out the java plugin as the dependent.
+
<references/>
  
Dan worried that while "[a] confined nsplugin is a nice feature for confining plugins downloaded from the network. But if you run openoffice and evince from within nsplugin they get confined, causing the apps to not work properly." In response to [[User:Simo|Simo Sorce]] Dan explained that any attempt to write transition rules to enable said applications to work properly would create an easy avenue of attack. Simo wondered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01115.html</ref> if it would be possible to either write a security wrapper to restrict the command line, or to get application developers to honor SELinux labels in some way.
+
=== Re-starting udev ===
  
[[WarrenTogami|Warren Togami]] shared<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01117.html</ref> that removing <code>mozplugger</code> was "[...] something I always do. It seems to cause more problems than it solves [...]" and [[JamesMorris|James Morris]] expanded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01226.html</ref> upon this with instructions "[...] on both removing mozplugger and restoring the security protections of SELinux.  Simply removing the package isn't enough[.]" James questioned "[...] how a package which breaks a security feature not only made it into the repo, but how it became enabled by default[?]"
+
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.
  
A similar issue was raised<ref>http://bugzilla.redhat.com/show_bug.cgi?id=491543</ref> by [[User:Bruno|Bruno Wolff III]] about the re-enabling of disabled ''Firefox'' plugins. Comments by [[MartinStransky|Martin Stransky]] suggest this is a feature of <code>mozilla-plugin-config</code>.
+
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:
 +
<pre>/sbin/start_udev</pre>
  
 
<references/>
 
<references/>
  
=== Getting Rid of /usr for Fedora 12 ? ===
+
=== Fedora Bug-tracker Independent from Red Hat ? ===
  
[[LennartPoettering|Lennart Poettering]] cheerfully invited<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01063.html</ref> any inclined parties to a flamefest over the elimination of the /usr directory. Lennart suggested that recent history indicated that more files were being moved from /usr to / and that confusion between the two was a source of error from some packages.
+
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.
  
Enthusiasm for both the flamewar and the proposal was low.
+
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 forceful and well-argued objection was made<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01064.html</ref><ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01076.html</ref> by [[KonstantinRyabitsev|Konstantin Ryabitsev]] on the basis that he liked to keep /boot and /usr on their own partitions and use a LUKS-encrypted LVM for everything else. Konstantin emphasized this was especially well-suited to portable machines which need to conserve power and are more likely to need encryption.  
+
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.  
  
[[RalfCorsepius|Ralf Corsepius]] invoked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01077.html</ref> the FHS<ref>http://www.pathname.com/fhs/</ref> on /usr and the need to contain<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01105.html</ref> non-essential packages unavailable at certain boot stages therein. [[ChrisAdams|Chris Adams]] added<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01101.html</ref> that symlinking /usr to / had been shown to break <code>rpm</code>.
+
[[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?'". 
 +
 
 +
<references/>
 +
 +
=== FOSS Needs a Central Bugtracker ? ===
  
Lennart explained<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01198.html</ref> how /etc could be made read-only and adduced<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01208.html</ref> OpenSUSE, Debian and Gentoo as further evidence that a read-only root could be attained. [[CallumLerwick|Callum Lerwick]] pined<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01300.html</ref> for the days of floppy disks.  
+
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[.]"
  
[[User:Toshio|Toshio Kuratomi]] completely declined to play and asked: "I'm hereby giving notice that I don't have time to read obvious flamefests anymore.  Once this thread concludes, please summarize whatever the pros and cons are and send it to the packaging committee to discuss and vote on."
+
[[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."
  
 
<references/>
 
<references/>

Revision as of 16:18, 27 April 2009

Developments

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

Contributing Writer: Oisin Feeley

Fedora 10 Packages in dist-f11

Kalev Lember drew attention[1] 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 Fedora 10 stable-updates repository.

Josh Boyer thanked Kalev for identifying the issue and explained that it was an error due to koji tag inheritance. Jesse Keating added[2] that his efforts to ease tag requests had forgotten to take tag inheritance into account but that he would fix this shortly.

Bugzilla Passwords

Another thread about bugzilla (see also this FWN#173 "FOSS Needs a Central Bugtracker" and "Fedora Bugtracker Independent from Red Hat?") concerned[1] itself with the automated requirement to change to a new user password. 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."

Matthias Saou and Ian Weller suggested[2] a dirty work-around. Konstantin Ryabitsev suggested[3] using supergenpass[4]. Basil Mohamed Gohar and Adam Williamson likedCite error: Invalid <ref> tag; refs with no name must have content the GNOME combination of Password Generator and Revelation.

After some questioning of the motivations and need for such password changes Jesse Keating rationalized[5] 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."

This questioning started to hone-in on the idea that the changes were done mainly to fulfil Red Hat business requirements and Adam Williamson reminded[6] 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."

PulseAudio: A Hearty and Robust Exchange of Ideas

A long, multi-thread flamewar over the (dis)advantages of the new VolumeControl (more specifically gnome-volume-control) applet in Fedora 11 smoked and crackled. The gnome-volume-control> applet provides a highly simplified interface to the PulseAudioCite error: Invalid <ref> tag; refs with no name must have content 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[1][2] in screenshots of the "Alsa-Mixer-O-Doom" posted by Dave Jones and WillWoods. A bugzilla filed[3] by 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.

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[4] of the entire "VolumeControl" feature[5][6], and whether FESCo had[7] jurisdiction over what went into the Desktop spin.

The first thread started[8][9] in 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 PCM volume. Bastien Nocera thoughtCite error: Invalid <ref> tag; refs with no name must have content that Callum's use case was esoteric and would not be accomodated. He suggested using PulseAudio over the network instead. A later report by Joonas Sarajärvi suggested[10] this should be possible.

Things went downhill from then on when Callum asked[11] 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 Volume Control applet as "immature". Bastien's response was[12] that the applet had been described for over a year on the wiki and he suggested the GConf was not of use because the volume control worked at the level of PulseAudio and not ALSA. Lennart Poettering also suggested[13] that using

alsamixer -c0

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[14]. Kevin Kofler helpfully responded[15] to Callum Lerwick's complaint that Pidgin alert sounds exploded his speakers with the suggestion that he edit /etc/pulse/daemon.conf to

flat-volumes = no

Following suggestions from Lennart and Kevin Kofler success was finally achieved[16][17] in loading the alsa-sink module so that the PCM volume could be controlled.

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[18]

A question from Andreas Thiemann asked how it came about that while his sound volume was acceptable with the MS Windows software mixer set to 75% and the physical speaker volume set to 50% he needed to set all of the physical volume, gnome-volume-control and the PCM volume (via an ALSA mixer) to 100% to achieve similar volumes on GNU/Linux. Lennart explained[19] 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[20][21] on how to generate such patches to alsa-utils' /lib/alsa/init/hda. Adam Williamson worried[22] that the roots of this specific problem lay elsewhere.

The aforementioned database suggested[23][24] to 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[25] that the new VolumeControl applet was not yet ready for prime-time in his opinion.

The thread was summarized[26] beautifully by Fernando Lopez-Lezcano as an infinite loop.

A second thread was started by Dimi Paun in which he bemoaned[27] some unspecific problems with sound in Fedora 11. 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[28] by 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 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 Fedora 11 there were plenty of histrionics. 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[29] by 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'." David Woodhouse reinforced[30] the point and argued that too many bugs were closed by PulseAudio developers as WONTFIX. Adam Williamson returned[31] 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[32] to arguments from Kevin Kofler and David Woodhouse that the new gnome-volume-control 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[33] 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." David Woodhouse described[34] this as a compromise about which he had serious reservations.

Christopher Aillon expressed[35] unhappiness with post-freeze changes and cited the unhappy example of Codeina. Jesse Keating refuted[36] 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 Paul W. Frields[37], Toshio Kuratomi[38] and others. KevinFenzi and Adam Williamson did not[39] agree with Paul that the functionality provided by gnome-alsamixer was "bit-twiddling" and saw it instead as basic and frequently desired.

As of going to press personal abuse of Lennart Poettering continued unabated.

  1. http://people.redhat.com/alexl/files/why-alsa-sucks.png
  2. http://www.codemonkey.org.uk/junk/wtf/alsa-mixer-o-doom.jpg
  3. http://bugzilla.redhat.com/show_bug.cgi?id=491372
  4. http://fedoraproject.org/wiki/Meeting:FESCo-2009_04_24#tApr_24_12:18:57
  5. http://fedoraproject.org/wiki/Features/VolumeControl
  6. https://fedoraproject.org/wiki/Meeting:FESCo-2009_04_24#tApr_24_12:24:37
  7. https://fedoraproject.org/wiki/Meeting:FESCo-2009_04_24#tApr_24_12:50:33
  8. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01452.html
  9. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01729.html
  10. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02000.html
  11. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01522.html
  12. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01634.html
  13. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01830.html
  14. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01862.html
  15. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01721.html
  16. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02164.html
  17. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02174.html
  18. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01955.html
  19. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01876.html
  20. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01895.html
  21. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01897.html
  22. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01914.html
  23. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02134.html
  24. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02150.html
  25. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02160.html
  26. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02001.html
  27. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg01870.html
  28. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02003.html
  29. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02014.html
  30. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02044.html
  31. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02066.html
  32. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02137.html
  33. http://fedoraproject.org/wiki/Meeting:FESCo-2009_04_24
  34. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02120.html
  35. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02047.html
  36. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02050.html
  37. http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02082.html
  38. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02108.html
  39. https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02191.html

Re-starting udev

Following a security flaw in udev[1] for which patches were[2] quickly made available "Dennis J." asked[3]: "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.

M.A. Young provided[4] the information that udevd is started from /etc/rc.d/rc.sysint and can be restarted with:

/sbin/start_udev

Fedora Bug-tracker Independent from Red Hat ?

Basil Mohamed Gohar asked[1] 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 Will Woods identified[2] 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[3] out by 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.

Matēj Cepl ranted[4] a little when Basil approved of the "FOSS Needs a Central Bugtracker?" thread (see this same FWN#173). Matej quoted[5] Alan Cox's essay advising how to "Beware We should', extend a hand to How do I?'".

FOSS Needs a Central Bugtracker ?

Markg85 started[1] a longish thread in which he proposed to start a single FOSS bugtracker for "[the] top 10 major foss distributions for now i think[.]"

David Woodhouse thought[2] that OpenID 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. Colin Walters also suggested[3] 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."