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, 10 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, 10 months
Fedora Modular 27 compose report: 20171028.n.0 changes
by Fedora Branched Report
OLD: Fedora-Modular-27-20171028.n.0
NEW: Fedora-Modular-27-20171028.n.0
===== SUMMARY =====
Added images: 0
Dropped images: 0
Added packages: 0
Dropped packages: 0
Upgraded packages: 0
Downgraded packages: 0
Size of added packages: 0.00 B
Size of dropped packages: 0.00 B
Size of upgraded packages: 0.00 B
Size of downgraded packages: 0.00 B
Size change of upgraded packages: 0.00 B
Size change of downgraded packages: 0.00 B
===== ADDED IMAGES =====
===== DROPPED IMAGES =====
===== ADDED PACKAGES =====
===== DROPPED PACKAGES =====
===== UPGRADED PACKAGES =====
===== DOWNGRADED PACKAGES =====
3 years
Trying a upgrade from 29 to 30
by Ludovic Hirlimann
Hi all,
According to https://fedoraproject.org/wiki/Releases/30/Schedule 30 has
been branched. So time for me to upgrade from 29 so I can report issue
with the way I use fedora.
I'm using https://fedoraproject.org/wiki/DNF_system_upgrade to upgrade.
Failed to synchronize cache for repo 'luminoso-Signal-Desktop', ignoring
this repo.
Failed to synchronize cache for repo 'athmane-gns3-extra', ignoring this
repo.
Failed to synchronize cache for repo 'rpmfusion-free-updates', ignoring
this repo.
Failed to synchronize cache for repo 'rpmfusion-free', ignoring this repo.
Failed to synchronize cache for repo 'rpmfusion-nonfree-updates',
ignoring this repo.
Failed to synchronize cache for repo 'rpmfusion-nonfree', ignoring this
repo.
Modular dependency problems:
Problem 1: conflicting requests
- nothing provides module(platform:f30) needed by module
avocado:stable:3020190213205848:a5b0195c-0.x86_64
Problem 2: conflicting requests
- nothing provides module(platform:f30) needed by module
bat:latest:3020190214090936:e50d0d19-0.x86_64
Problem 3: conflicting requests
- nothing provides module(platform:f30) needed by module
dwm:6.1:3020190213215420:a5b0195c-0.x86_64
Problem 4: conflicting requests
- nothing provides module(platform:f30) needed by module
exa:latest:3020190214120734:e50d0d19-0.x86_64
Problem 5: conflicting requests
- nothing provides module(platform:f30) needed by module
fish:3:3020190216163513:602da195-0.x86_64
Problem 6: conflicting requests
- nothing provides module(platform:f30) needed by module
gimp:2.10:20181223154246:a5b0195c-0.x86_64
Problem 7: conflicting requests
- nothing provides module(platform:f30) needed by module
libgit2:0.27:3020190128145600:a5b0195c-0.x86_64
Problem 8: conflicting requests
- nothing provides module(platform:f30) needed by module
meson:latest:3020190123223713:36245242-0.x86_64
Problem 9: conflicting requests
- nothing provides module(platform:f30) needed by module
ninja:latest:3020190131012415:a5b0195c-0.x86_64
Problem 10: conflicting requests
- nothing provides module(platform:f30) needed by module
ripgrep:latest:3020190214090003:a5b0195c-0.x86_64
Problem 11: conflicting requests
- nothing provides module(platform:f30) needed by module
standard-test-roles:3.0:3020190214144451:a5b0195c-0.x86_64
Problem 12: conflicting requests
- nothing provides module(platform:f30) needed by module
stratis:1:20181215204600:a5b0195c-0.x86_64
Error:
Problem 1: package libibcm-16.2-3.fc28.x86_64 requires
rdma-core(x86-64) = 16.2-3.fc28, but none of the providers can be installed
- rdma-core-16.2-3.fc28.x86_64 does not belong to a distupgrade repository
- problem with installed package libibcm-16.2-3.fc28.x86_64
Problem 2: package libopenshot-0.2.2-1.fc29.x86_64 requires
libMagickCore-6.Q16.so.5()(64bit), but none of the providers can be
installed
- package libopenshot-0.2.2-1.fc29.x86_64 requires
libMagickWand-6.Q16.so.5()(64bit), but none of the providers can be
installed
- ImageMagick-libs-1:6.9.9.38-3.fc29.x86_64 does not belong to a
distupgrade repository
- problem with installed package libopenshot-0.2.2-1.fc29.x86_64
Problem 3: package rpmfusion-free-release-29-1.noarch requires
system-release(29), but none of the providers can be installed
- fedora-release-29-7.noarch does not belong to a distupgrade repository
- problem with installed package rpmfusion-free-release-29-1.noarch
Problem 4: package vlc-core-1:3.0.6-16.fc29.x86_64 requires
libprotobuf-lite.so.15()(64bit), but none of the providers can be installed
- protobuf-lite-3.5.0-8.fc29.x86_64 does not belong to a distupgrade
repository
- problem with installed package vlc-core-1:3.0.6-16.fc29.x86_64
Problem 5: package fedora-release-29-7.noarch requires fedora-repos(29)
>= 1, but none of the providers can be installed
- package rpmfusion-nonfree-release-29-1.noarch requires
system-release(29), but none of the providers can be installed
- fedora-repos-29-2.noarch does not belong to a distupgrade repository
- problem with installed package rpmfusion-nonfree-release-29-1.noarch
Problem 6: problem with installed package blender-1:2.79b-9.fc29.x86_64
- package blender-1:2.79b-10.fc30.x86_64 requires
libboost_locale.so.1.66.0()(64bit), but none of the providers can be
installed
- boost-locale-1.66.0-14.fc29.x86_64 does not belong to a distupgrade
repository
- blender-1:2.79b-9.fc29.x86_64 does not belong to a distupgrade
repository
Problem 7: problem with installed package darktable-2.6.0-2.fc29.x86_64
- package darktable-2.6.0-2.fc30.x86_64 requires
libexiv2.so.26()(64bit), but none of the providers can be installed
- exiv2-libs-0.26-12.fc29.x86_64 does not belong to a distupgrade
repository
- darktable-2.6.0-2.fc29.x86_64 does not belong to a distupgrade
repository
Problem 8: problem with installed package pgp-tools-2.7-3.fc29.x86_64
- package pgp-tools-2.7-3.fc29.x86_64 requires /usr/bin/pgpring, but
none of the providers can be installed
- mutt-5:1.10.1-1.fc29.x86_64 does not belong to a distupgrade repository
Problem 9: problem with installed package gns3-server-2.1.11-1.fc29.x86_64
- package gns3-server-2.1.11-2.fc30.x86_64 requires
python3.7dist(prompt-toolkit) = 1.0.15, but none of the providers can be
installed
- python3-prompt_toolkit-1.0.15-1.fc29.noarch does not belong to a
distupgrade repository
- gns3-server-2.1.11-1.fc29.x86_64 does not belong to a distupgrade
repository
Problem 10: problem with installed package
ImageMagick-c++-1:6.9.9.38-3.fc29.x86_64
- package ImageMagick-c++-1:6.9.10.27-1.fc30.x86_64 requires
libMagickCore-6.Q16.so.6()(64bit), but none of the providers can be
installed
- package ImageMagick-c++-1:6.9.10.27-1.fc30.x86_64 requires
libMagickWand-6.Q16.so.6()(64bit), but none of the providers can be
installed
- package ImageMagick-c++-1:6.9.10.27-1.fc30.x86_64 requires
ImageMagick-libs(x86-64) = 1:6.9.10.27-1.fc30, but none of the providers
can be installed
- cannot install both ImageMagick-libs-1:6.9.10.27-1.fc30.x86_64 and
ImageMagick-libs-1:6.9.9.38-3.fc29.x86_64
- package python3-libopenshot-0.2.2-1.fc29.x86_64 requires
libMagickCore-6.Q16.so.5()(64bit), but none of the providers can be
installed
- package python3-libopenshot-0.2.2-1.fc29.x86_64 requires
libMagickWand-6.Q16.so.5()(64bit), but none of the providers can be
installed
- ImageMagick-c++-1:6.9.9.38-3.fc29.x86_64 does not belong to a
distupgrade repository
- problem with installed package python3-libopenshot-0.2.2-1.fc29.x86_64
Problem 11: problem with installed package
ImageMagick-1:6.9.9.38-3.fc29.x86_64
- package ImageMagick-1:6.9.10.27-1.fc30.x86_64 requires
libMagickCore-6.Q16.so.6()(64bit), but none of the providers can be
installed
- package ImageMagick-1:6.9.10.27-1.fc30.x86_64 requires
libMagickWand-6.Q16.so.6()(64bit), but none of the providers can be
installed
- package ImageMagick-1:6.9.10.27-1.fc30.x86_64 requires
ImageMagick-libs(x86-64) = 1:6.9.10.27-1.fc30, but none of the providers
can be installed
- cannot install both ImageMagick-libs-1:6.9.10.27-1.fc30.x86_64 and
ImageMagick-libs-1:6.9.9.38-3.fc29.x86_64
- package python3-libopenshot-0.2.2-1.fc29.x86_64 requires
libMagickCore-6.Q16.so.5()(64bit), but none of the providers can be
installed
- package python3-libopenshot-0.2.2-1.fc29.x86_64 requires
libMagickWand-6.Q16.so.5()(64bit), but none of the providers can be
installed
- package openshot-2.4.3-2.fc29.noarch requires python3-libopenshot >=
0.2.2, but none of the providers can be installed
- ImageMagick-1:6.9.9.38-3.fc29.x86_64 does not belong to a
distupgrade repository
- problem with installed package openshot-2.4.3-2.fc29.noarch
Wondring if there is anything here worth filling has bugs ( the vlc one
for instance is not worth filling as it comes from fusion and fusion as
not branched yet).
Ludo
3 years
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, 7 months
dnf system-upgrade download --refresh --releasever=30 errors
by Felix Miata
Output messages (partial, typed):
[]
Preparing:
Traceback (most recent call last):
file /usr/lib/python3.7/site-packages/dnf/yum/rpmtrans.py, line 260 in callback
self._elemProgress(key,amount)
...line 303, in _elemProgress
transaction_list=self._extract_cbkey(key)
...line 244, in _extract_cbkey
raise RuntimeError("TransactionItem not found for key: %s % cbkey)
RuntimeError: Transaction not found for key: rtkit
Complete!
Download complete! Use 'dnf system-upgrade reboot' to start the upgrade....
[/]
dnf system-upgrade reboot seems to be proceeding normally. :-p
install 9
upgrade 655
downgrade 9
Total size: 724M...
--
Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
4 years, 8 months
Blocking criteria proposal for F30+: Printing
by Stephen Gallagher
There was a bug[1] 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
following drivers:
(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
user base).
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1628255
4 years, 8 months
F30 - podman run ; iptabels PRE_trusted
by Douglas E. Hopley Jr.
Greetings.
Let me know if there is any specific details I can add to this.
//
Looking to test 'podman' I pulled an image (with success).
When I went to run a container with podman run I got an error.
Specifically = [
podman run --rm -it centos /bin/bash
error adding firewall rules for container
cd76e8db21afdb10df7a875c920bc274325aaa30457457f527bf928b27752da9: failed to
add the address 10.88.0.8/32 to trusted zone: COMMAND_FAILED:
'/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.8.0
(legacy): Couldn't load target `PRE_trusted':No such file or directory
]
I can add more details, let me know what is needed, OK?
- uname ~= 5.0.0-0.rc4.git3.1.fc30.x86_64 #1 SMP Fri Feb 1 08:47:51 UTC
2019 x86_64 x86_64 x86_64 GNU/Linux
- podman --version = podman version 1.0.1-dev
- podman info = [
host:
BuildahVersion: 1.6-dev
Conmon:
package: podman-1.0.1-17.dev.gitd5593b8.fc30.x86_64
path: /usr/libexec/podman/conmon
version: 'conmon version 1.12.0-dev, commit:
d3cac30f4e81084c7bc36922e02817841ccc3456'
Distribution:
distribution: fedora
version: "30"
MemFree: 462692352
MemTotal: 1800531968
OCIRuntime:
package: runc-1.0.0-70.dev.gite4fa8a4.fc30.x86_64
path: /usr/bin/runc
version: |-
runc version 1.0.0-rc6+dev
commit: 5b54487295859772ddfc57918f10e82994e501ae
spec: 1.0.1-dev
SwapFree: 3871338496
SwapTotal: 3871338496
arch: amd64
cpus: 1
hostname: ipd2.ipcloud.net
kernel: 5.0.0-0.rc4.git3.1.fc30.x86_64
os: linux
rootless: false
uptime: 99h 31m 17.95s (Approximately 4.12 days)
insecure registries:
registries: []
registries:
registries:
- docker.io
- registry.fedoraproject.org
- quay.io
- registry.access.redhat.com
- registry.centos.org
store:
ConfigFile: /etc/containers/storage.conf
ContainerStore:
number: 3
GraphDriverName: overlay
GraphOptions:
- overlay.mountopt=nodev
GraphRoot: /var/lib/containers/storage
GraphStatus:
Backing Filesystem: extfs
Native Overlay Diff: "true"
Supports d_type: "true"
Using metacopy: "false"
ImageStore:
number: 1
RunRoot: /var/run/containers/storage
]
//
Is this a good way to report details like this? Is there a better/more
preferred way?
Thanks for your time.
Sincerely,
Doug
4 years, 8 months
Re: Blocking criteria proposal for F30+: Printing
by Stephen Gallagher
I just realized I only responded to Zdenek the other day. Re-sending
my response now.
On Tue, Feb 12, 2019 at 9:13 AM Zdenek Dohnal <zdohnal(a)redhat.com> wrote:
>
> Hi,
>
> comments are in the text:
>
> On 2/11/19 9:17 PM, Stephen Gallagher wrote:
> > On Mon, Feb 11, 2019 at 2:24 PM Chris Murphy <lists(a)colorremedies.com> wrote:
> >> On Mon, Feb 11, 2019 at 9:58 AM Stephen Gallagher <sgallagh(a)redhat.com> wrote:
> >>> Sorry that it's taken me so long to get back to this.
> >>>
> >>> I think the feedback on this has been mostly positive on the Beta
> >>> criteria, but I'd like to tweak the phrasing a bit and see if this
> >>> comes off more favorable:
> >>>
> >>> 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".)
> >> Does the criterion pply strictly to the printing of text and line
> >> art, or does it also apply to gross departures in photographs? If the
> >> latter:
> >>
> >> ^minor differences in color reproduction are not considered "non-working"; or
> >> ^only major differences in color reproduction are considered "non-working"
> >>
> >> Major defined as any of:
> >> obvious and grossly incorrect scaling (e.g. +/- 20%)
> >> color inversion, torqued primaries (white becomes black, black becomes
> >> white; red becomes blue, blue becomes green, etc)
> >> tone reproduction that obliterates relevant identifying detail in two
> >> or more test images
> >>
> >> With that language I'm trying to carve out only remarkable, WTF level,
> >> bugs as blockers.
> >>
> > I think we can *probably* leave this as a thing to be decided at a
> > blocker bug review. I really want to avoid trying to set a hard line
> > on a topic that is inherently subjective. In general, I think we can
> > just rely on the "last blocker at Go/No-Go" test for this.
> I agree with Stephen - such topics can be really subjective and even the
> fault does not have to be on Fedora side (f.e. when you catch the file
> which goes to the printer, you look into it and it looks fine, but
> output paper has 'slightly' different colors, scale etc... - so there
> can be issues in the printer itself).
> >
> >> Next question is what applications to use for printing, since the
> >> initiating application matters. What if there's a bug in just one
> >> application? That shouldn't be a printing blocker (it might be a basic
> >> functionality blocker for that application if it's included in default
> >> installations). So I'd say pick two. Firefox and LibreOffice? Firefox
> >> and evince?
> >>
> > How about "Desktop environment's 'test page' functionality" and
> > whichever basic text editor comes with it.
>
> IMHO it is not correct blocker criteria for printing as itself, but it
> is more like blocker for these applications. AFAIK blocker is the issue,
> which can not be worked around - if the file is printable by CUPS CLI
> commands 'lp'/'lpr', but not from a app, IMHO it is not blocker for
> printing.
>
> IMO issues like 'not being able to print from X application' should be
> blocking/release criteria for some common/widely used apps like
> Firefox/evince/libreoffice, not for printing itself. (If the issue would
> be actually connected to CUPS, I'll cooperate with them to fix the issue).
>
Well, we don't have to be that specific in the release criteria,
honestly. We're talking about blocker criteria specifically for
blocking desktops, so in my opinion it's okay to have "test page" and
"basic text editor" as the stand-ins for this. (This is similar to how
we have "package manager must be able to download and apply updates"
as a stand-in for "the network must not be totally broken".)
I'd be fine if we wanted to add a corollary that either of these are
not blockers if it can be shown that other applications can print
successfully. I just wanted to suggest those as the basic litmus test.
> >
> >> Next question, test document(s). European Color Initiative has several
> >> test PDFs already prepared, perhaps the most applicable for our
> >> purposes is the visual test (and a subset of it).And for font scaling
> >> and reproduction, Ghent Working Group has test GWG 9.1 which tests
> >> various encodings of TrueType, PostScript, and OpenType rendering.
> >> Also, there's a suite of LibreOffice test files, and while I haven't
> >> gone through it, I'm willing to bet there's one or two that'd serve as
> >> a decent sanity tester (in any case I'm not proposing printing out
> >> entire test suites):
> >> https://github.com/freedesktop/libreoffice-test-files
>
> Chris, would you mind elaborating more on the topic of these test files
> and tests from these sources? Martin (mosvald in CC) currently does only
> comparing sample file and output file in ghostscript and I'm on my way
> to do it the similar way in CUPS and printer driver packages.
>
> Do they have special tests available to look into them? I saw mostly
> only pdf file in ECI downloads, I did not see anything in GWG and only
> docx or xlsx files in libreoffice tests.
>
<snip>
I'm going to suggest that going into this level of detail on how to
write the tests is mostly going to cloud the issue. I think we first
want to make sure we agree that the basics of the proposal are sound.
I'm perfectly happy to delegate the specifics of how to verify the
functionality to the subject matter experts.
I'll update the proposal again with some of the feedback:
* 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 non-ridiculous
differences in color reproduction are not considered "non-working". In
general, we'll apply the "last blocker at Go/No-Go" principle here
when deciding whether a print glitch is truly blocking.)
and this to Final for Fedora 30+:
* Printing must work (as defined above) on at least one printer using
each of the following drivers:
- The built-in print-to-PDF driver
- The generic IPP driver
* For each blocking desktop, it must be possible to print:
- A test page from the desktop environment's built-in "test page"
feature, if such a feature exists.
- A simple text document of at least 100 words (lorem ipsum) from
the standard basic text editor accompanying that desktop.
This does not mean that all printers need to function properly that
use the IPP driver, just that at least one does (so we
know that printing as a whole is unbroken). We won't specify any
particular hardware makes or models that must work.
4 years, 8 months
