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
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 =====
2 years, 10 months
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
2 years, 10 months
Re: [Xen-devel] Criteria / validation proposal: drop Xen
by Adam Williamson
On Mon, 2019-05-13 at 16:29 -0600, Lars Kurth wrote:
> Hi all,
>
> I am going to step in here with my hat as Xen Project community
> manager. We had a discussion about this issue as part of last week's
> community call. I CC'ed a number of stake-holders, which probably
> should have been on the thread such as ITL (which builds QubesOS
> on top of Fedora) and Michael A Young (the Xen package manager).
>
> First of all apologies that this issue has lingered so long. Key
> members of the community were not aware of the issues raised in
> this thread, otherwise we would have acted earlier. With this in
> mind, please in future raise issues with me, on xen-devel@,
> committers@ or the Xen-Fedora package manager. The Xen Community
> would like to see Fedora running as guest: in fact it would be
> somewhat odd if there was a Xen-Dom0 package and guest support
> didn't work. And there are some downstreams such as QubesOS,
> which depend on this support.
Thanks for stepping in. Of course we always want as much stuff as
possible to work, but that does not mean we block the release on it. We
certainly want Fedora to work as a guest on VMWare, VirtualBox and
Parallels too; we don't block the release on any of those either...
> > 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?
>
> We discussed this at the community call and came to the conclusion that
> we can run regular tests of Fedora RC's as part of our OSSTEST
> infrastructure. Ian Jackson volunteered to implement this, but there
> are some questions on
> a) The installer (which we can handle ourselves)
> b) When we would trigger a test - aka is there some trigger other than the
> c) How would results best be reported back to Fedora
>
> Apologies, I am not very familiar with how the Fedora Test group works.
> Is there some documentation which would help integrate what you to with
> the test system of another open source project?
b) you can use fedmsg / fedora-messaging:
https://github.com/fedora-infra/fedmsg
https://github.com/fedora-infra/fedora-messaging
A message is emitted every time a compose attempt finishes (on the fedmsg
topic 'org.fedoraproject.prod.pungi.compose.status.change': see
https://apps.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.pr...
for a log of past messages). What you will want to do is listen for
completed Branched and Rawhide composes and run tests whenever one
completes successfully. This is already exactly what we do to schedule
openQA tests; you can crib from the openQA test scheduler:
https://pagure.io/fedora-qa/fedora_openqa
particularly the fedmsg consumer:
https://pagure.io/fedora-qa/fedora_openqa/blob/master/f/fedora_openqa/con...
c) ideally it would be good to report to both resultsdb and to the
wiki. Again, we already do this for openQA, and you can crib from the
code there:
https://pagure.io/fedora-qa/fedora_openqa/blob/master/f/fedora_openqa/rep...
reporting to ResultsDB might be tricky due to authentication issues,
I'm not sure if we ever put the openID auth stuff into production. For
wiki reporting you will either have to auth manually every so often or
ask Fedora infra for a special token that doesn't expire (this is what
we do for the openQA results).
Reporting to ResultsDB you do through resultsdb_api -
https://pagure.io/taskotron/resultsdb_api - and optionally you can use
my resultsdb_conventions -
https://pagure.io/taskotron/resultsdb_conventions - which makes it
somewhat easier (IMO anyway) and will make your results consistent with
those from openQA and Autocloud. Reporting to the wiki you can do
through my crazy python-wikitcms library -
https://pagure.io/fedora-qa/python-wikitcms . Again, fedora_openqa does
all this for openQA results, so you can crib from that. Let me know if
you have trouble with this.
> > > > 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 :)
>
> Can we come to some arrangement, by which such issues get communicated
> to the Xen Project earlier? Aka me, xen-devel@ or committers@
It would be nice if you could ensure someone from Xen is actually
watching the Fedora lists, if working in Fedora is a target for Xen. We
*could* try and CC stuff all the time, but imagine if we tried to do
that for everybody. But yes, for future conversations of this nature
I'll try and remember to include those lists.
> > > > "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".
>
> Would the proposal above work for you? I think it satisfies what you are
> looking for. We would also have someone who monitors these test results
> pro-actively.
In theory, yeah, but given the history here I'm somewhat sceptical. I'd
also say we still haven't really got a convincing case for why we
should continue to block the release (at least in theory) on Fedora
working in Xen when we don't block on any other virt stack apart from
our 'official' one, and we don't block on all sorts of other stuff we'd
"like to have working" either. Regardless of the testing issues, I'd
like to see that too if we're going to keep blocking on Xen...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
3 years, 10 months
Proposal: Toggle key criterion
by Ben Cotton
As we discussed in today's blocker review meeting[1], I am presenting
a draft proposal for the toggle keys. I am proposing this as a *final*
criterion, but would not object to adding it as a beta criterion.
== Keyboard toggle keys ==
For all release-blocking desktops, the Caps Lock and Num Lock keys
must correctly toggle the relevant behavior for the desktop and all
applications. The behavior must be consistent with the displayed
status on physical or virtual keyboards, where applicable.
[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-09-30/f31-bl...
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 11 months
Podman issues on F31
by Ankur Sinha
Hello,
While working with docs, I ran into a few podman issues. I've not been
able to find any bugs related to these yet. Are these known by any
chance. If not, I'll go file fresh bugs:
--- Issue 1 ----
$ ./build.sh
This build script is using Podman to run the build in an isolated environment.
WARN[0000] Error initializing configured OCI runtime runc: no valid executable found for
OCI runtime runc: invalid argument
Error: could not get runtime: default OCI runtime "runc" not found: invalid
argument
@hhlp pointed out that it's listed in F31 common bugs here:
https://www.fedoraproject.org/wiki/Common_F31_bugs#Podman_fails_to_run_co...
The fix, unfortunately, lead to a new error:
--- Issue 2 ----
$ rm ~/.config/containers/libpod.conf -f
$ ./build.sh
This build script is using Podman to run the build in an isolated environment.
2019-09-25T10:28:24.000811303Z: cannot rm state directory
'/run/user/1000/crun/42c03e3c10e7b2de25b41fbd1d69ee7fb2ac656a18b77a005e7c6e9556e07195':
Directory not empty
ERRO[0002] Error removing container
42c03e3c10e7b2de25b41fbd1d69ee7fb2ac656a18b77a005e7c6e9556e07195: error cleaning up
container 42c03e3c10e7b2de25b41fbd1d69ee7fb2ac656a18b77a005e7c6e9556e07195: error removing
container 42c03e3c10e7b2de25b41fbd1d69ee7fb2ac656a18b77a005e7c6e9556e07195 from runtime:
`/usr/bin/crun delete --force
42c03e3c10e7b2de25b41fbd1d69ee7fb2ac656a18b77a005e7c6e9556e07195` failed: exit status 1
$
--- Issue 3 ----
I tried on a different F31 machine and ended up with a different error:
$ ./build.sh
This build script is using Podman to run the build in an isolated environment.
Trying to pull docker.io/antora/antora...
Getting image source signatures
Copying blob 56174ae7ed1d done
Copying blob 284842a36c0d done
Copying blob e7c96db7181b done
Copying blob 7fa322d31adf done
Copying blob ee3fdb6b9c98 done
Copying blob 50958466d97a done
Copying blob 6fd7bef320a5 done
Copying config 8e549fc7fa done
Writing manifest to image destination
Storing signatures
Error processing tar file(exit status 1): there might not be enough IDs available in the namespace (requested 0:42 for /etc/shadow): lchown /etc/shadow: invalid argument
Error: unable to pull docker.io/antora/antora: unable to pull image: Error committing the finished image: error adding layer with blob "sha256:e7c96db7181be991f19a9fb6975cdbbd73c65f4a2681348e63a141a2192a5f10": Error processing tar file(exit status 1): there might not be enough IDs available in the namespace (requested 0:42 for /etc/shadow): lchown /etc/shadow: invalid argument
--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
3 years, 12 months
Proposing new release criteria
by Dusty Mabe
I don't know the formal process for proposal but here is a shot at a bare minimum
start for trying to add containers to the existing release criteria. This is a suggestion
after we found podman can't pull containers from a registry in f31 [1].
New section for Containers and Container tools:
- A Fedora system can install the podman container runtime
- The podman container runtime can pull/run a container from Fedora's registry as root
- The podman container runtime can pull/run a container from Fedora's registry as a non-root user
As for the container I'd suggest the previous fedora release's container (i.e. f30 for f31).
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1737471#c22
3 years, 12 months
