I must admit I am frustrated again: since the last update yesterday,
a _very_ basic behavior changed with no apparent way of changing back.
Namely, now my screen blanks (with the monitor displaying "No signal")
after 2min of inactivity (sometimes it seems faster). This is truly
frustrating: it blanks while I read a longer email, when I read
something on the web, etc.
Sure enough, looking for a way to switch it off proved futile too:
* I couldn't find any setting for a Screensaver despite
going through System | Preferences for at least 5min, on
3-4 different attempts.
* Power Management says "Never" for both "Computer" and "Display"
to be put to sleep.
Dimi Paun <dimi(a)lattica.com>
So, in the spirit of light rather than heat, here's my proposal, again,
rescued from the depths of the flamefest, with some actual work
g-v-c is clearly intending to be an abstracted and simplified volume
control app / applet to cover the most common use cases in a friendly
It's clear, though, that some users have needs beyond this, which are
likely only going to be satisfied in a sensible way by access direct to
the ALSA mixer elements. Bastien and Lennart don't want some kind of
hack to expose these via g-v-c, and I'd tend to agree, that's clearly
not what it's designed for.
So my proposal is that we 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. Basically the same as
Lennart's "just use alsamixer" suggestion, only a GUI app that will be
more discoverable and easier for most people to use (it's a bit tricky
to figure out 'alsamixer -c0 -Vcapture', for instance).
At first I suggested including the XFCE mixer for this purpose, but now
that feels a bit awkward. It's really part of XFCE, its menu entry is
just named 'Mixer' and renaming it to something appropriate for GNOME
might not be appropriate for XFCE. And it has a slightly odd interface
rather than the 'immediate screenful o' sliders' that people are used to
from the old g-v-c.
So I suggest what we should do is resurrect gnome-alsamixer. It's still
technically part of GNOME - it's even got moved to the new GNOME git.
Other distributions still package it (Debian, for e.g.) It's even had a
few commits within the last year or so. It was more or less deprecated
in favour of g-v-c, but now we have a case where it may make sense to
have two clearly differentiated apps, and gnome-alsamixer is the obvious
I just pulled the latest code out of git and threw together a package
(based on the spec from Mandriva, since I had it lying around). It
builds and works fine - you get the kind of interface most people will
be expected, a tabbed window with each of your available output devices
on a tab, and the typical 'bunch o' sliders' layout for each device. In
the package I've added a menu entry with the name "Advanced Volume
Control" and the comment "Full hardware access volume control
The package is available here:
http://adamwill.fedorapeople.org/gnome-alsamixer/ (the SRPM, spec file,
and an x86-64 build for current Rawhide). Please take a look at it if
Just to reinforce this, gnome-alsamixer shouldn't interfere with Pulse
or g-v-c at all; it doesn't run persistently, it doesn't mess anything
up in gconf or anywhere else that would affect those. All it does is let
you poke the raw mixer elements, just like alsamixer only graphically.
I know the GNOME folks are generally opposed to having two apps that do
'the same thing', but it's very clear from the long threads on this list
and elsewhere that g-v-c really doesn't do the things that many people
need it to do as of yet. If we ship with just g-v-c as a graphical
'mixer' available by default we will wind up telling many many people to
drop to a console and use alsamixer - and annoying a lot more people who
don't ask, find the release notes, or figure out how to use alsamixer on
their own. I really don't see how providing an alternative graphical
mixer app is worse than that.
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
Not a developer. Yet
As I install Fedora onto box(s)
for newbies to Linux.
Can a "clickable icon" be made up for preupgrade.
As to most of them,
command line usage across the telephone
can be a little daunting.
They don't even know how to use it,
on non-Linux systems.
msn: frankly3d skype: frankly3d
I've committed patches to GConf and intltool that change the way schema
translations are handled.
Previously, translations were merged by intltool from .po files into
schemas files and then copied by gconftool from the schemas file into
Now, translations are kept in .po files, and intltool only copies the
gettext domain into the schemas, and further into the GConf database.
The only tool that ever uses these translations, gconf-editor, knows how
to get them from the message catalogs.
The big advantage of this change is that schemas shrink radically, which
should help a lot with the 'slow updates due to GConf' problem. It also
reduces the redundancy of storing the schema translations in three
places, which should help with live cd size.
Since the changes are somewhat involved, I'd like to ask for feedback in
case something appears odd or broken wrt. to GConf schemas and their
translations in the near future.
Hi, folks. We in the QA and Bugzappers groups have recently been
discussing the use of the Priority and Severity fields in
At present, the status is that these are more or less ignored by
Bugzappers and most maintainers; some maintainers use and set
them for their own packages according to their own system. The
reason for their neglect, as we see it, is that there's been no
convention for their use, and no overall responsibility in
setting them - they're usually set arbitrarily by reporters, and
thus convey no useful information.
We think it may be useful for the Bugzappers group to start
setting these fields as part of the triage process. To address
one potential issue right off the top - this would be *entirely*
advisory, like all the other work of the Bugzappers: it's
intended to provide a service to maintainers, nothing more. It
would not be in any way prescriptive - we don't want any other
group to be able to tell maintainers what they should work on. We
simply think that setting these fields consistently as part of
triage might prove useful to some, or all, maintainers.
It's also just proposed as a trial - if we try it and it doesn't
seem to be working out well, we'll stop it.
We have a draft convention for how these fields should be set
. As you can see, it basically suggests that the severity field
be used to rate the importance of the issue in the context only
of the affected package, and priority be used to rate the
importance of the issue in the context of the distribution as
There is an alternative proposal that triagers would set only the
severity field, which would work mostly as it does in the other
proposal, except that the Urgent severity would be used for
issues which, in the triager's judgement, have serious
consequences for the distro as a whole. The priority field, in
this proposal, is reserved for the package maintainer(s) to use,
no-one else gets to set it at any point.
In our proposals, triagers would set these field(s) in as
consistent a manner as possible as part of the initial triage
process. Bug reporters could be prevented from setting the fields
at all, at any time, to address the possibility that they might
just set their reports to High or Urgent regardless of their
There's no action required or even suggested of any maintainer
for any value of either field - it's simply there to provide
information. We feel that maintainers might then find it useful
to organize their bugs by severity or priority to make it easier
to identify the most urgent issues to address.
A few specifics: the system would happily accommodate maintainers
who have their own systems for using these fields. Triagers would
be specifically instructed not to touch these fields if they had
been previously touched by the maintainer - effectively,
maintainer's decision on these fields is final. So if you
disagree with the triager's
opinion, or you have your own system for using these fields, you
could simply set them to whatever you like and the Bugzappers
will not change them back.
So, really, we just want your feedback: do you think this
proposal might prove useful to you as a maintainer? Can you see
any problems with it, or potential refinements or improvements?
Which of the two slightly differing proposals would you prefer?
Bugzappers' mission is to ease the lives of maintainers, so we
don't want to put this in place unless it's seen as beneficial by
at least some maintainers. Thanks!
on behalf of Fedora BugZappers
I would like to run restorecond as a user service rather then as system
service. I want to run it under the Users UID and under with the users
Then I can have it watch for creation of files in the users home
directory and be the equivalent of running restorecon ~/ by the user.
Currently I can do this with the system service restorecond, but that is
running as root and has to be able to relabel everything.
I want to use something like DBUS so I have only one restorecond running
for each user no matter how many times the user logs in.
I built a dbus service and everything works fine. Except that I want
this to work on a server when I ssh to a machine. Or if I log in via
the console terminal. In those cases I do not have a dbus session so I
am out of luck.
I could have restorecond started via /etc/profile.d but I would need to
do something for csh and bash, and I could end up with multiple
restorecond under the same UID. I could build into restorecond some
kind of locking to prevent this, but the dbus solution eliminates me
from having to do some potentially buggy code.
I doubt I am the only one who wants to run sessions on login for
terminal users. Any thoughts on running a dbus session for a terminal