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
Re: digikam and kipi-plugins?
by Rex Dieter
Per Bothner wrote:
> The Rawhide version of digikam is the very latest (0.10.0-rc1),
> but it fails to find any of the "Kipi plugins", even though I've
> installed the kipi-plugins package. This might be an upstream
> issue, since 0.10.0 is pretty bleeding edge and the kipi-plugins
> may even more bleeding-edge. Gwenview does seem to be see the
> plugins, so I'm wondering if there is there might be a
> Fedora-specific problem before I complain upstream ...
The f10 builds seem to work fine for me (finding the plugins), so perhaps
this is rawhide-specific?
To be clear, digikam's Settings -> configure digikam -> Kipi Plugins is
empty?
-- Rex
7 years, 6 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
Bugzilla semantics: marking bugs as triaged
by Adam Williamson
I had interesting discussions with Andy Lindeberg and jlaska today about
the semantics of our current Bugzilla - and particularly triage -
workflow.
We were thinking about the NEW / ASSIGNED dichotomy, and Andy and I came
to the conclusion that it doesn't really make a lot of sense.
Right now, Bugzappers uses it one way, Andy uses it another for
anaconda. In the Bugzappers process, ASSIGNED just means, really,
Triaged: you set a bug to ASSIGNED once the triage process is complete.
For Anaconda, Andy sets bugs to ASSIGNED once they're assigned to the
correct anaconda maintainer (whether or not the rest of triage is yet
fully completed).
Neither case is really terribly problematic, but they also don't make a
whole lot of sense, really. Having 'triage completed' as a status is a
bit arguable; it's not quite in the flow of the statuses, as a bug could
be at a point 'beyond' ASSIGNED but not yet have been triaged, for
instance. And it's also just semantically wrong - the word 'assigned'
does not mean 'triaged'.
In the anaconda case, we just thought about it and decided the use of
ASSIGNED isn't really _achieving_ anything: you can tell whether the
bug's been assigned or not just by looking at who it's assigned to.
We sort of came to the conclusion that it'd probably make the most sense
to have a 'Triaged' keyword that's used to affirm that a bug's been
triaged (in fact there already is one, but it's not officially used in
our current process), and abandon the distinction between NEW and
ASSIGNED. Ideally, the ASSIGNED state would just be removed, but we
could keep it and just note in our workflow / policy that it's not
really used to mean anything in particular.
This could, I think, be implemented quite quickly if desired; I think we
could rig something up to set all bugs in ASSIGNED state (except
anaconda ones) to have the 'Triaged' keyword, that shouldn't be
impossible.
We'd be interested in thoughts - negative, positive, whatever - on the
idea. Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
13 years, 5 months
Anaconda on a Test Day CD?
by Kamil Paral
Hi,
there's the idea of removing anaconda from the default Test Day
kickstart script [1]. What would it cause?
+ Less building problems. Anaconda dependencies are often broken
in Rawhide. Removing anaconda from Test Day CD would prevent
building problems. It would be more likely for people to
successfully build the CD. (When Test Day CD can't be built
because of dependencies problems, not everyone would think up
removing anaconda).
+ The image size would be a little smaller. (not a big issue)
- It wouldn't be possible to install Rawhide from Test Day CD.
(Is this really a minus? How often do people install Rawhide
from Test Day CDs? How often do we want them to do that?
What if someone installs Rawhide with some heavily modified
packages from a Test Day, can it cause confusions in some
future bugreports?)
- If we want anaconda on Test Day CD specifically, it must be
manually added. (not a big issue)
* No "Install" icon on the desktop :)
So what do you think? Is it/is it not worth bothering? Do we
more often want anaconda included or have less problems when
building it?
Thanks for opinions,
Kamil
[1] https://fedoraproject.org/wiki/QA/Test_Days/Live_Image
13 years, 8 months
NFS causing slooooow boot
by Valent Turkovic
Hi,
I'm building custom Fedora remix with some packages from RPMFusion and
updated Fedora packages. Last Live USB image I created booted really
slow (over 5 minutes). I tracked down the issue to nfs service. Even
when this ISO image is used for installing Fedora to HDD the same
issue is present.
After stopping nfs service boot time was around 30 seconds!
Did anybody else experience this issue?
Cheers.
--
pratite me na twitteru - www.twitter.com/valentt
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic, msn: valent.turkovic(a)hotmail.com
13 years, 8 months
