FWN/Beats/Developments

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 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 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 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 a dirty work-around. Konstantin Ryabitsev suggested using supergenpass. Basil Mohamed Gohar and Adam Williamson liked the GNOME combination of Password Generator and Revelation.

After some questioning of the motivations and need for such password changes Jesse Keating rationalized 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 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 PulseAudio 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 in screenshots of the "Alsa-Mixer-O-Doom" posted by Dave Jones and Will Woods. A bugzilla filed 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 of the entire "VolumeControl" feature, and whether FESCo had jurisdiction over what went into the Desktop spin.

The first thread started 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 thought 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 this should be possible.

Things went downhill from then on when Callum asked 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 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 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. Kevin Kofler helpfully responded 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 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

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 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 on how to generate such patches to alsa-utils' /lib/alsa/init/hda. Adam Williamson worried that the roots of this specific problem lay elsewhere.

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

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

A second thread was started by Dimi Paun in which he bemoaned 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 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 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 the point and argued that too many bugs were closed by PulseAudio developers as WONTFIX. Adam Williamson returned 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 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 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 this as a compromise about which he had serious reservations.

Christopher Aillon expressed unhappiness with post-freeze changes and cited the unhappy example of Codeina. Jesse Keating refuted 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, Toshio Kuratomi and others. KevinFenzi and Adam Williamson did not 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.

Re-starting udev

Following a security flaw in udev for which patches were quickly made available "Dennis J." asked: "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 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 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 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 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 a little when Basil approved of the "FOSS Needs a Central Bugtracker?" thread (see this same FWN#173). Matej quoted Alan Cox's essay advising how to "Beware We should', extend a hand to How do I?'".

FOSS Needs a Central Bugtracker ?

Markg85 started 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 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 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."