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: Criteria / validation proposal: drop Xen
by Adam Williamson
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
notification?
> > 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".
Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
4 years, 5 months
F24 beta virt-install with kickstart fails
by Jos Vos
Hi,
Did anyone succeed in virt-install'ing F24 beta using kickstart
(on CentOS 6 host, if that matters)?
I see lots of warnings (dracut-initqueue), then the console goes
into a slowly filling bar at the bottom (plymouthd!?), then I see
lots of "No space left on device" errors, then a dracut emergency
shell is started.
The generated rdsosreport.txt contains 34284 lines...
FWIW, when *not* using kickstart I can install F24 beta on the
same system with virt-install fine.
Thx,
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
5 years, 2 months
Beta 1.5 and Virtualbox
by Alessio Ciregia
I'm unable to use Fedora 27 beta 1.5 in Virtualbox: the screen (inside the
VM) become black.
I've not spotted this issue in previous composes.
Someone is aware of this issue?
Thank you.
A.
5 years, 11 months
'No More Alphas': wiki revision drafts
by Adam Williamson
Hi, folks! So I've (finally) got ready an initial round of draft
changes to various wiki pages for the purpose of implementing the 'No
More Alphas' Change. You can find all the drafts in the NoMoreAlphas
category:
https://fedoraproject.org/wiki/Category:NoMoreAlpha
For each page I cloned the original text and saved it as the first
edit, so you can use the 'History' tab's diff feature to see the actual
changes to each page (just compare the current state to the first
edit).
To summarize the changes, at least as I remember them, and call out
some significant choices:
* Obviously, all Alpha-related points on the schedule template on the
Fedora Release Life Cycle page were removed. For schedule points that
were previously derived from Alpha points that got removed, I adjusted
them to derive from some other still-remaining point.
* My proposal for 'what do we do about release criteria / validation'
is basically: the 'Fedora 27 Alpha Release Criteria' page gets renamed
'Basic Release Criteria' (note: not versioned, I don't think it should
be), and we document that *all* composes - not just Beta and Final
candidate composes, but also Rawhide and Branched nightlies - will be
automatically tested for (and release of them gated on) compliance with
them. Which is more or less what's proposed in the Change. All external
references to the 'Alpha' criteria get changed to 'Basic' (e.g. this is
what changed on the other criteria pages, and on the test matrix
template pages). Practically speaking, we currently have automated
testing for *most* of the existing Alpha criteria, but a few items
aren't covered. We can choose to move these to the Beta criteria, or
leave them on Basic and just accept that *actual* coverage doesn't
quite meet what we aspire to. I do *NOT* propose to have any kind of
blocker tracking bug for the Basic release criteria; it doesn't seem to
fit in the process, there is no Alpha release to block, and we can't
realistically block nightly composes on manual test results. So a
tracker bug wouldn't really have any reason to exist. In the case where
a violation of the Basic criteria makes it into composes despite the
automated testing, it should be marked as a Beta blocker.
* There is a problem with what to do about the Change schedule: our two
sources for it don't actually agree on what the schedule *is*. The
Changes Policy page - https://fedoraproject.org/wiki/Changes/Policy -
claims that the 'Completion deadline' "falls on the same day as the
Alpha milestone freeze", but the Fedora Release Life Cycle page -
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle - claims it
falls on the same day as the branch point, which is two weeks *before*
the Alpha freeze. Given this inconsistency I didn't really feel
confident proposing a draft for the Changes/Policy page yet; probably
it'd be good for FESCo(?) as owners of the Change process to decide
when they actually want the key dates of the Change process to be, In A
World Without Alphas. If FESCo wants to figure that out and let me
know, I can draft the changes.
Please do look these over and provide any kind of feedback! Thanks.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5 years, 11 months
tracker-preferences
by Michael Schwendt
Package is absent from F27.
How to turn off tracker now?
Tracker miners running like mad as one of the first things when demonstrating
a fresh install of Fedora to someone, is really bad.
5 years, 11 months
Fedora 26 Beta Release Readiness Meeting on Thursday, May 25 @ 19:00 UTC
by Jan Kurik
Join us on irc.freenode.net in #fedora-meeting-2 for the Fedora 26
Beta Release Readiness Meeting meeting.
The meeting is going to be held on Thursday, May 25, 2017 at 19:00
UTC. Please check the [1] link for your time zone.
We will meet to make sure we are coordinated and ready for the Beta
release of Fedora 26. Please note that this meeting is going to be
held even if the release is delayed at the Go/No-Go meeting on the
same day two hours earlier.
You may received this message several times, but it is by purpose to
open this meeting to the teams and to raise awareness, so hopefully
more team representatives will come to this meeting. This meeting
works best when we have representatives from all of the teams.
For more information please check the [2] link.
[1] https://apps.fedoraproject.org/calendar/meeting/5759/
[2] https://fedoraproject.org/wiki/Release_Readiness_Meetings
Thank you for your support,
Regards, Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
5 years, 12 months