File conflicts: nss-softokn-freebl and nss
by Debarshi Ray
While yum installing gcc-c++ over a Fedora 11 Beta x86_64
installation, I got this:
Transaction Check Error:
file /lib64/libfreebl3.so from install of
nss-softokn-freebl-3.12.2.99.3-7.fc11.x86_64 conflicts with file from
package nss-3.12.2.0-4.fc11.x86_64
Happy hacking,
Debarshi
--
One reason that life is complex is that it has a real part and an
imaginary part.
-- Andrew Koenig
15 years, 1 month
Annoying screen blanking
by Dimi Paun
Folks,
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.
What gives?
P.S. https://bugzilla.redhat.com/show_bug.cgi?id=498505
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
15 years, 1 month
rawhide report: 20090506 changes
by Fedora compose checker
Compose started at Wed May 6 06:15:03 UTC 2009
Updated Packages:
audio-entropyd-2.0.1-1.fc11
---------------------------
* Tue May 05 2009 Tom "spot" Callaway <tcallawa(a)redhat.com> - 2.0.1-1
- upstream took my alsa patch (improved on it too)
control-center-2.26.0-6.fc11
----------------------------
* Wed Apr 29 2009 Matthias Clasen <mclasen(a)redhat.com> - 2.26.0-6
- Don't rely on _BACKUP property for xkb initialization
fcoe-utils-1.0.7-4.fc11
-----------------------
* Mon Apr 27 2009 Jan Zeleny <jzeleny(a)redhat.com> - 1.0.7-4
- added libhbalinux to Requires (#497605)
gdm-2.26.1-7.fc11
-----------------
* Wed Apr 29 2009 Matthias Clasen <mclasen(a)redhat.com> - 1:2.26.1-7
- Don't rely on _BACKUP property for xkb initialization
* Tue Apr 28 2009 Ray Strode <rstrode(a)redhat.com> - 1:2.26.1-5
- fix crash at shutdown
* Tue Apr 28 2009 Matthias Clasen <mclasen(a)redhat.com> - 1:2.26.1-6
- fix a use-after-free in XDMCP code paths (#496882)
gnome-settings-daemon-2.26.1-4.fc11
-----------------------------------
kde-settings-4.2-10.20090430svn.fc11
------------------------------------
* Thu Apr 30 2009 Rex Dieter <rdieter(a)fedoraproject.org> - 4.2-10.20090430svn
- nepomukserverrc: disable nepomuk
libvirt-0.6.2-4.fc11
--------------------
* Tue May 05 2009 Daniel P. Berrange <berrange(a)redhat.com> - 0.6.2-4.fc11
- Fix labelling of shared/readonly disks (rhbz #493692)
nautilus-sendto-1.1.5-1.fc11
----------------------------
* Tue May 05 2009 Bastien Nocera <bnocera(a)redhat.com> 1.1.5-1
- Update to 1.1.5
* Tue Apr 28 2009 Bastien Nocera <bnocera(a)redhat.com> 1.1.4.1-2
- Build with gajim support (#497975)
totem-2.26.2-1.fc11
-------------------
* Sun May 03 2009 Bastien Nocera <bnocera(a)redhat.com> 2.26.2-1
- Update to 2.26.2
* Tue Apr 28 2009 Bastien Nocera <bnocera(a)redhat.com> 2.26.1-4
- Add missing pyxdg requires for the OpenSubtitles plugin (#497787)
* Thu Apr 23 2009 Bastien Nocera <bnocera(a)redhat.com> 2.26.1-3
- Add missing gnome-python2-gconf req (#483265)
totem-pl-parser-2.26.2-1.fc11
-----------------------------
* Sun May 03 2009 Bastien Nocera <bnocera(a)redhat.com> 2.26.2-1
- Update to 2.26.2
xorg-x11-drv-ati-6.12.2-11.fc11
-------------------------------
* Tue May 05 2009 Dave Airlie <airlied(a)redhat.com> 6.12.2-10
- radeon-modeset-fixes.patch: backport fixes from upstream for rs480 firefox gpu crash
* Tue May 05 2009 Dave Airlie <airlied(a)redhat.com> 6.12.2-11
- make src/mask prepare access force to GTT.
* Tue Apr 28 2009 Dave Airlie <airlied(a)redhat.com> 6.12.2-8
- restrict texture coords to 0.0->1.0 explicitly.
- enable gamma now kernel is tagged
* Tue Apr 28 2009 Dave Airlie <airlied(a)redhat.com> 6.12.2-9
- fix gamma code to work properly
- bump kernel requires for gamma interface not oopsing
xorg-x11-drv-synaptics-1.1.0-5.fc11
-----------------------------------
* Tue May 05 2009 Peter Hutterer <peter.hutterer(a)redhat.com> 1.1.0-4
- synaptics-1.1.0-edges.patch: Set default edge sizes depending on model
(#494766).
* Tue May 05 2009 Peter Hutterer <peter.hutterer(a)redhat.com> 1.1.0-5
- synaptics-1.1.0-nograb-fail.patch: fail if the device cannot be grabbed
(#499058)
xorg-x11-server-1.6.1-11.fc11
-----------------------------
* Mon May 04 2009 Adam Jackson <ajax(a)redhat.com> 1.6.1-10
- xserver-1.6.1-nouveau.patch: Update the autoconfig logic for nv3 and other
historical oddities.
* Mon May 04 2009 Adam Jackson <ajax(a)redhat.com> 1.6.1-11
- xserver-1.6.1-document-fontpath-correctly.patch: Typo fixes.
* Thu Apr 23 2009 Dave Airlie <airlied(a)redhat.com> 1.6.1-8
- xserver-1.6.1-exa-create-pixmap2.patch - add support for tiling create
pixmap hook - need to fix firefox on ati rs690 crashes
* Thu Apr 23 2009 Adam Jackson <ajax(a)redhat.com> 1.6.1-9
- xserver-1.6.1-avoid-malloc-for-logging.patch: Don't malloc when logging,
since that makes it unsafe to do from a signal handler.
* Wed Apr 22 2009 Adam Jackson <ajax(a)redhat.com> 1.6.1-7
- Conflict with too-old versions of xorg-x11-drivers. (#497144)
Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 13
Broken deps for ppc64
----------------------------------------------------------
cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7
15 years, 1 month
The Great Pulseaudio Mixer Debate: a modest (productive) proposal
by Adam Williamson
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
attached.
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
way. Great.
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
choice.
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
application".
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
you're interested.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
15 years, 1 month
Intel driver 2.7.99.1
by the.masch
Hello:
Is it possible to have the intel 2.7.99.1 snapshot to make some test before
the release??
Salu2...
masch...
15 years, 1 month
Preupgrade Icon?
by Frank Murphy
to qualify
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.
Frank
--
msn: frankly3d skype: frankly3d
Still Learning
15 years, 1 month
GConf changes in F12
by Matthias Clasen
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
the database.
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.
Thanks, Matthias
15 years, 1 month
Feedback request: Priority / Severity use on Bugzilla
by Matej Cepl
Hi, folks. We in the QA and Bugzappers groups have recently been
discussing the use of the Priority and Severity fields in
Bugzilla.
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
here:
http://fedoraproject.org/wiki/User:Beland/Bugzilla_Legend#Severity_and_Pr...
. 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
a whole.
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
actual importance.
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!
Matěj
on behalf of Fedora BugZappers
15 years, 1 month
