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, 8 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, 8 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, 10 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, 10 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, 10 months
[Fedora QA] #322: New release criterion: no X libs in the minimal install set
by fedora-badges
#322: New release criterion: no X libs in the minimal install set
------------------------------+------------------
Reporter: mattdm | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Release criteria | Version:
Keywords: | Blocked By:
Blocking: |
------------------------------+------------------
= problem =
There are no rules holding us to a sane minimal package set. Features
which are added to minimal could pull in the whole universe.
= analysis =
Drawing the line at X11 seems reasonable. (And Wayland.) We can argue at
length about what minimal means, but this is a fairly clear line in the
sand ''and'' is usually a reasonable split at a package level ''and''
matches our historic practice (see vim packages for example).
= enhancement recommendation =
"No package in the minimal install set may have a dependency chain which
includes the libX11, the core X11 library (or its equivalent in Wayland).
Packages must split functionality requiring this into subpackages, or be
removed from the minimal package set."
My suggestion is to make this an Alpha criterion, so such issues can be
resolved early, but I don't have strong feelings on the particular timing.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/322>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
8 years, 8 months
[Fedora QA] #273: Improve browseability of validation matrix pages
by fedora-badges
#273: Improve browseability of validation matrix pages
-----------------------------------------+------------------------
Reporter: adamwill | Owner: adamwill
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 17
Component: Proventester Mentor Request | Version:
Keywords: | Blocked By:
Blocking: |
-----------------------------------------+------------------------
= problem =
cwickert and sandro have told us they have trouble finding the validation
matrix pages when they need them.
= analysis =
we do have the pages logically named and categorized, but it's still not
that easy to, for e.g., see all the desktop result pages for a given
release at a glance.
= enhancement recommendation =
We could add more categories, for example "Fedora XX
{{desktop,base,install}} validation results" categories, and any others
that come to mind (suggestions please!) It would be nice to have 'next /
previous' links that would let you browse from Final RC4 back to Final RC3
back to Final RC2 back to Final RC1 back to Final TC2 back to Final TC1
back to Beta RC4 and so on, but I'm not sure if that's plausible to
implement automatically (it would be relatively easy to do manually when
creating the pages, though).
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/273>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
8 years, 8 months
[Fedora QA] #228: SOPs for Everything
by fedora-badges
#228: SOPs for Everything
----------------------+-----------------------------------------------------
Reporter: adamwill | Owner: adamwill
Type: task | Status: new
Priority: major | Milestone: Fedora 17
Component: Wiki | Version:
Keywords: |
----------------------+-----------------------------------------------------
We should have...SOPs for Everything!
This is a meta-ticket with the aim of identifying, well, everything QA
does, and making sure they all have SOPs. For a start, I'm going to do a
survey of the QA calendar for a release, and check whether we have an SOP
for each task.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/228>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
8 years, 8 months
[Fedora QA] #363: Require spins to go through smoke testing before being published
by fedora-badges
#363: Require spins to go through smoke testing before being published
-------------------------+----------------------------------
Reporter: adamwill | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: Undetermined Future
Component: Test cases | Version:
Keywords: | Blocked By:
Blocking: |
-------------------------+----------------------------------
= problem =
Sometimes, we publish spins that are completely DOA.
= analysis =
There is no mandatory testing of any Fedora images beyond netinst, DVD and
the two release blocking desktop live spins, as things stand, but we
publish rather more spins than that. In practice we test Xfce, LXDE, SoaS
and AMI images to some extent, but others are rarely touched.
= enhancement recommendation =
viking-ice has suggested that we should produce some kind of validation
matrix which has very basic, generic smoke tests: basically, does the
image at least boot up sanely? We would require there to be a PASS for
these mandatory smoke tests present in that matrix for a spin image to be
published on the spins page. QA does not commit to doing the actual
testing; we may do so if we have time, but ultimately, if a spin owner
wants to have their spin published, it's their responsibility to get the
testing done, either by poking QA, doing it themselves, or getting someone
else to do it.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/363>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
8 years, 8 months
