This may be a dumb question, but why can't Redhat distribute NVIDIA binary
In NVIDIA's licence (http://www.nvidia.com/object/nv_swlicense.html) it
"2.1.2 Linux Exception. Notwithstanding the foregoing terms of Section
2.1.1, SOFTWARE designed exclusively for use on the Linux operating system
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?
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.
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.
On Thu, 2017-07-06 at 15:13 -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Jul 06, 2017 at 11:59:01AM -0700, Adam Williamson wrote:
> > Hi, folks! A while ago, Xen virtualization functionality was added to
> > the criteria and the validation test case set, on the understanding
> > that Oracle would provide testing for it (and help fix bugs as they
> > arose).
> > For the last couple of releases we really have not had any such testing
> We had been doing the testing, it just that we (or rather me and
> Dariof) seem to get a wind of this at the last minute. Not sure exactly
> how to fix that thought.
Well, I mean, every few *days* a compose gets nominated for validation
testing, and a mail is sent to test-announce. Just check your test-
announce archives for mails with "nominated for testing" in their
subject lines, and you'll see dozens. Is this not sufficient
> > from Oracle. On that basis, I'm proposing we remove this Final
> > criterion:
> s/Oracle/Xen Project/ I believe?
Perhaps, it's just that it always seemed to be you doing the testing,
so they got a bit conflated :)
> > "The release must boot successfully as Xen DomU with releases providing
> > a functional, supported Xen Dom0 and widely used cloud providers
> > utilizing Xen."
> > and change the 'milestone' for the test case -
> > https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt -
> > from Final to Optional.
> > Thoughts? Comments? Thanks!
> I would prefer for it to remain as it is.
This is only practical if it's going to be tested, and tested regularly
- not *only* on the final release candidate, right before we sign off
on the release. It needs to be tested regularly throughout the release
cycle, on the composes that are "nominated for testing".
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
There was a bug filed recently that indicated that printing was
broken on certain printers. As a result of that discussion, it became
apparent that there was no criteria for printing to work at all, which
seems like an oversight.
I discussed this briefly with Matthias Clasen this morning and he
agreed that this should be treated as blocking for Workstation.
I'd like to propose that we add the following criteria to Beta for Fedora 30+:
* Printing must work on at least one printer available to Fedora QA.
"Work" is defined as the output from the device matching a preview
shown on the GNOME print preview display. (Note that differences in
color reproduction are not considered "non-working".)
and this to Final for Fedora 30+:
* Printing must work on at least one printer using each of the
(I don't know which ones to specify here, but we ought to try to
figure out a cross-section that covers a large swath of our expected
At yesterday's F29 Go/No-Go meeting, we discussed the blocker status
of BZ #1628192 - Fedora 29 installation cannot see a firmware RAID
device. While the blocker criteria clearly states that this should be
a blocker for Beta, many of the people present at the meeting
disagreed, for a variety of reasons.
* Hardware supporting fwraid is considerably less pervasive than it
was when the criterion was written
* Testing this criterion can only be done with install media, which
limits our testing pool to the very dedicated members of Fedora QA.
Yes, anyone *can* download a nightly compose and try it, but in
practice this tends to be limited to the core testers. The majority of
testing that this feature will get will tend to happen as people try
out the Beta release.
To that end, I'd like to propose that we make the following change to
the criteria going forward:
"The blocking criterion for successful installation atop a firmware
RAID array is moved to the GA release criteria."
What's the current state of Fedora with regard to Nvidia graphics hardware?
Should it just work?
On a machine with GeForce GTX 1060, Fedora 28 suffers badly from freezes and
slowdowns during boot, unbearable slow mouse movement on the GDM login
screen, then more freezes before GNOME Shell appears but isn't really
usable because everything is slow as a snail. Switching the login settings
from Wayland to Xorg at least results in a usable GNOME Shell. Installing
the Nvidia driver packages from rpmfusion hasn't made a difference.
The current Fedora 29 Live Workstation image starts, but faces mysterious
freezes before the desktop appears. Installation to harddisk has worked, but
I've run into a series of unrelated issues, and the performance of GNOME Shell
isn't pretty. It takes too long to start a terminal, or suddenly the shell
freezes for 10-15 seconds and restarts.
Non-sse2 won't work on openSUSE Tumbleweed, but does on Debian next (10/Buster).
I have a 28 attempting to dnf upgrade to 29, but I'm seeing a ton of entries
filling up /var/lib/systemd/coredump, 197 files and still counting. :-(
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
This will probably be considered a "minor" pain. And, since I don't use GNOME except
in a VM for testing, I guess it is.
I'd just like to go on record to say I dislike a few things about the install process.
1. There is no option to set the hostname during install.
2. User creation is delayed until first boot and at the time of creation there is no
option to specify the UID and GID. So, if you're like me, and use existing
NFS services and your primary user doesn't have 1000/1000 for them you have to either
know to create an initial throw away account or manually make changes
Cardinal Rule of Presentations: "Tell them what you are going to tell them, tell
them, then tell them what you told them."