NVIDIA Question
by David St.Clair
This may be a dumb question, but why can't Redhat distribute NVIDIA binary
drivers?
In NVIDIA's licence (http://www.nvidia.com/object/nv_swlicense.html) it
says:
"2.1.2 Linux Exception. Notwithstanding the foregoing terms of Section
2.1.1, SOFTWARE designed exclusively for use on the Linux operating system
may be
copied and redistributed, provided that the binary files thereof are not
modified in any
way (except for unzipping of compressed files)."
So, what's keeping RedHat from putting the drivers in the distribution? If
it's a GPL
thing, would it be easy to just download it during installation or at
least give the option to the user?
Thanks,
--
David St.Clair
dstclair(a)cs.wcu.edu
1 year, 4 months
Mouse goes crazy
by Jonathan Villa
Ok, I have had Yarrow working well for a while now, but yesterday I
started experiencing some odd issues with my mouse. All of a sudden it
stops working correctly. The only thing that seems to fix is to kill X
and run mouse-test, then restart.
Any ideas?
Also, I have FC 1 running on a desktop which is hooked up to a KVM
switch. Whenever I go to another PC, and return, the same thing
happens, the mouse goes crazy.
???
1 year, 4 months
Mouse Wheel gone
by Christian Menzel
Since the latest xorg-X11 upgrade I receive the already mentioned XKB
error and the mouse wheel is not working anymore.
Has anybody seen this behavior?
Regards
Chris
7 years, 6 months
Re: NFS failure
by Fulko.Hew＠sita.aero
Damian Menscher <menscher(a)uiuc.edu>@redhat.com on 04/07/2004 04:57:13 PM
wrote:
> On Wed, 7 Apr 2004, Jeff Elkins wrote:
>
> > I'm getting failure messages on my nfs mounts i.e. :
> >
> > mount to NFS server 'music.elkins' failed: server is down.
> >
> > nsfd appears to be running and I didn't see anything suspicious in the
logs.
> > The servers are up and running and have other clients connected.
>
> You didn't mention what steps you took to debug it:
>
> Can you ping the server?
> What is the output of rpcinfo -p servername?
> Does the server have access restrictions (firewall, TCP Wrappers, etc)?
I have the same symptoms...
rpcinfo says that nfs et.al. are running.
Something has changed in test 2, since the same PC running RH9
accesses that host just fine.
7 years, 6 months
Problem running OOo downloaded from openoffice.org
by Joe Smith
Installing the OO.org 2.4 packages on F9 beta, I get this message when
starting:
$ /opt/OOH680_m12/program/soffice
Gtk-Message: Failed to load module "gnomebreakpad":
/opt/OOH680_m12/program/libstdc++.so.6: version `GLIBCXX_3.4.9' not
found (required by /usr/lib/bug-buddy/libbreakpad.so.0)
OOo then starts and seems to run ok, but it will not run from a desktop
launcher using that same command, I presume because bug-buddy can't be
started.
I don't know what the Fedora policy is here: does it matter at this
point whether a third-party package isn't starting cleanly? Nor do I
understand the message well enough to decide who to report it to.
It seems that OOo uses it's own libstdc++ which is not compatible with
gnomebreakpad, but I've not found a way to have gnomebreakpad look
elsewhere for that library.
Any suggestions if/where to file a report, and/or how to workaround the
problem?
<Joe
14 years, 9 months
Bug Triage: Call for Action (and a meeting)
by John Poelstra
Greetings Bug Triagers,
Thanks to those of you that came to the bug triage session at FUDCon a
couple of Saturdays back. Hopefully it was helpful and you'd still like
to join us. Things have gotten slightly better here
http://tinyurl.com/4cavl2 but we still need your help!
Our weekly bug triage meeting hasn't happened for several weeks and we'd
like to resume them again. Some of us were tied up with other things
and some people were unable to make the time. Also after having a few
meetings with one or two people it seemed unclear how best to proceed.
So.... we know there are a lot of people interested in bug triage but
past meeting attendance hasn't been good so we'd like to try and fix
that. At least two or three people sign up for the 'fedorabugs' group
every day so there is a disconnect there somewhere we need to fix. And
if you think weekly meetings aren't the way to go and there is a better
way to proceed please put it forward.
ITEM #1
I've created a matrix on this page
https://fedoraproject.org/wiki/BugZappers/Meetings/Scheduler to help
figure out a good time for people. PLEASE add your IRC nick or initials
to the best slots that work for you.
I'm hoping we can gather together a core group of people that will meet
each week to talk about bug triage, ways to improve process, and tools
to make it easier.
ITEM #2
I've raised this idea a couple of times now (and generally been shot
down), but since there has been little to no uptake in recent triage
related post I'm going to keep trying :) We made the decision back in
January to keep triage stuff on fedora-test-list because we wanted the
benefit of a larger audience of people that might be interested in
helping with bug triage. HOWEVER, I'm wondering if the "testing"
audience and that "triage" audience really aren't the same and as a
result we are directing new bug triage folks to sign up for
fedora-test-list where they receive 200 emails a week where only a small
handful of them are related to bug triage.
Would there be better response to "bug triage related posts" if they
were sent to a bug triage list only, and thus a very targeted audience
of people interested in bug triage?
ITEM #3
It is completely possible that items #1 and #2 are completely
misdirected and that instead we should do ______________(you tell us).
I'm simply writing this message because somehow we need to find a way to
gather a core group of people around bug triage who can consistently
work on bug triage, collaborate, and make Fedora better together by
making sure our package maintainers have good bug reports to work with.
In doing so I believe we can encourage others to join in too.
Thanks for reading!
John
14 years, 11 months
k3b complains about /dev/sr0
by Antonio Olivares
Dear all,
k3b is complaining about access to /dev/sr0
has there been a change that is causing this?
No write access to device /dev/sr0
K3b needs write access to all the devices to perform
certain tasks. Without it you might encounter problems
with HL-DT-ST - DVDRAM GMA-4082N
Solution: Make sure you have write access to /dev/sr0.
In case you are not using devfs or udev K3bSetup is
able to do this for you.
Mp3 Audio Decoder plugin not found.
K3b could not load or find the Mp3 decoder plugin.
This means that you will not be able to create Audio
CDs from Mp3 files. Many Linux distributions do not
include Mp3 support for legal reasons.
Solution: To enable Mp3 support, please install the
MAD Mp3 decoding library as well as the K3b MAD Mp3
decoder plugin (the latter may already be installed
but not functional due to the missing libmad). Some
distributions allow installation of Mp3 support via an
online update tool (i.e. SuSE's YOU).
TIA,
Antonio
14 years, 11 months
FYI: bugzilla POST state for virt bugs & relation to bug triage
by Daniel P. Berrange
The Fedora bug triage team has previously outlined a preferred workflow
for bugs:
http://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
Since this process has been documented and the bug triage team started
processing Fedora bugs, there has been some confusion wrt to certain bugs
which are in the "POST" state. That wiki page says maintainers are free
to adapt this workflow, and so this mail intends to clarify what the
virtualization team have done with the POST state, and thus what the
Fedora bug triage team should do if they see bugs in this POST state.
You may or may not know that there is a large team of Red Hat people working
on virtualization (upstream, in Fedora & in RHEL), and thus for any single
package there are a large number of people sharing responsibility for processing
bugs and producing fixes. At any point in time though, one person will be
designated 'committer' (or perhaps 'gate keeper') and they are responsibl
for actually applying the patches to the RPM. Before a patch gets applied
it also has to be reviewed & ACK'd by at least 3 people, and (if applicable)
accepted / merged by the upstream project.
The process a 'normal' bug follows according to the Fedora bug workflow
in the wiki page above is
NEW -> ASSIGNED -> MODIFIED -> ON_QA -> CLOSED
This is insufficient for the 'gate keeper' model of applying patches to a
package. We thus make use of the further POST state. The person assigned
to a bug will prepare a patch and mail it to an upstream project and also
for review by other team members. At this point the bug is moved to the
POST state and the patch typically attached to the BZ. The 'gate keeper'
of the package will periodically look at all bugs in POST state and check
if they've been ACK'd by 3 people, apply the patch to the RPM and move
the bug to the MODIFIED state. So you can see the process used is only
slightly changed to:
NEW -> ASSIGNED -> POST -> MODIFIED -> ON_QA -> CLOSED
NB, we do *not* change the 'assigned to' contact when moving from the
ASSIGNED to POST state, because often the 'gate keeper' will reject a
patch requesting further work & thus even in the POST state the bug is
still the repsonsiblity of the person actually writing the patch.
In summary, "POST" means 'a patch is ready, but not yet applied'
Although this process was initiated for our RHEL product, we also follow
the same process for Fedora bugs in virtualization related components[1],
since a consistent workflow is very important & we have same people working
on both RHEL & Fedora virt stuff. That said we do relax the 3-ack rule for
Fedora, and mostly focus on the requirement that it be accepted by the
appropriate upstream project.
So what does this mean for the Fedora triage team...
Basically this should have little-to-no impact on triage team's work. Simply
treat "POST" in the same way you would treat "ASSIGNED". ie, don't touch any
bugs in "POST" state, aside from closing those which are against end-of-life
Fedora products.
Hope this clarifies any confusion there may be..
Regards,
Daniel
[1] virtualization components include at least xen, kernel-xen, libvirt,
python-virtinst, virt-manager and kvm.
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
14 years, 11 months
