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
criterion proposal: prevent services timing out on system shutdown
by Kamil Paral
*Why*
The recent spice-vdagent update causes all virtual machines to take 90
seconds longer on every shutdown/reboot:
https://bugzilla.redhat.com/show_bug.cgi?id=1813667
The service hangs when systemd tries to stop it, and systemd then kills it
after a 90 second timeout expires.
This is a recurring pattern, I saw services blocking shutdown/reboot in the
past, and so far we haven't been able to do anything about it from a
blocker perspective. I think that for cases where the problem occurs very
frequently or every time, we should have a way to block the release until
it's fixed. I find it a very poor experience to wait 90+ seconds for
machine reboot/shutdown. Much poorer than, say, a crashing desktop
application (which we block on), because that application can be replaced
with a different one. System services mostly can't be replaced, and
certainly not by a general user.
*Proposal*
So I propose to amend the "System services" criterion [1]:
```
All system services present after installation with one of the
release-blocking package sets must start properly, unless they require
hardware which is not present.
```
with something like this:
```
All system services present after installation with one of the
release-blocking package sets must start properly, unless they require
hardware which is not present.
*All system services present after installation with one of the
release-blocking package sets must not time out frequently or regularly
when they are being stopped during system reboot/shutdown.*
```
The way it is written, the mentioned bug would be a conditional violation
of that criterion (applies only to VMs) and we'd need to use our judgement
to determine whether it's a blocker.
Thoughts?
[1]
https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria#System_se...
2 years, 7 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, 11 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, 11 months
Proposal to adjust final criterion for backgrounds
by Stephen Gallagher
Right now, we have two main criteria around the default
background/wallpaper for Fedora releases:
Basic Criterion: "The default desktop background must be different
from that of the last two stable releases."
Final Criterion: "The proposed final Fedora artwork must be included
and used as the background on release-blocking desktops. All Fedora
artwork visible in critical path actions on release-blocking desktops
must be consistent with the proposed final theme."
The reason for the Basic Criterion is largely to ensure that people
have a simple visual reminder that they are not using a stable
release. I don't agree with the exact phrasing there.
Proposal 1:
Basic Criterion: "The default visual experience of Fedora pre-releases
must be sufficiently differentiated from stable releases so as to
avoid easy confusion." We can then expand on that to use the current
criterion as an example of how that may be accomplished (but it need
not be the only way). [1]
The reason for the Final criterion is a fit-and-polish one. We want to
ensure that the final product is as clean as we can make it. However,
I don't think we necessarily should block the release just for the
background.
Proposal 2:
Final Criterion: "Fedora may not ship release-blocking desktops with
visibly[2] unfinished artwork."
We would then add the following to the list of Automatic Freeze Exceptions[3] :
"Changes that modify only the aesthetic of Fedora, such as the default
wallpaper or window manager themes."
This would allow us to get late fixes in for the wallpaper and similar
artwork, but not require us to slip for it.
[1] I envision a world where we could theoretically have the
"Background Logo" GNOME extension display a "pre-release" notation or
something similar.
[2] Defining "visibly" as "an average user would consider it out of
place, such as UI elements being completely missing".
[3] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process#Automa...
3 years, 4 months
Re: Some issues when running cinnamon desktop with F32
by Joachim Backes
On 2020-04-30 12:25, Ed Greshko wrote:
> On 2020-04-30 18:21, Joachim Backes wrote:
>>
>>
>> On 2020-04-30 11:29, Ed Greshko wrote:
>>> On 2020-04-30 17:17, Joachim Backes wrote:
>>>> Dear F32 users,
>>>>
>>>> After having installed F32 (previously F31 with cinnamon) , some
>>>> issues:
>>> A bit of clarification please.
>>>
>>> Is this an upgrade of F31 to F32 or a new F32 install?
>>> If an upgrade, was this an F31 Cinnamon installed with added
>>> desktops? If so, which ones?
>>
>> a) It was an upgrade
>> b) Previously Cinnamon was installed, additionally Xfce
>
> OK, I'll try to reproduce. It may take a bit as it is late in the day
> here. :-)
>
>
--
Fedora release 32 (Thirty Two)
Kernel-5.6.8-300.fc32.x86_64
Joachim Backes <joachim.backes(a)rhrk.uni-kl.de>
https://www-user.rhrk.uni-kl.de/~backes/
3 years, 5 months
Self-Introduction: Michel Salim (Facebooker)
by Michel Alexandre Salim
Hi all,
I've met some of you in person over the years (most recently at Flock
2019), but have been remiss in getting directly involved beyond helping
test updates.
With Lenovo now officially supporting Fedora on some models, and my
company (Facebook) running Fedora on a substantial number of ThinkPad
and ThinkStation devices, it's probably time to stop lurking and get
more involved, so here I am.
I've been at Facebook for the past three years, but have been involved
in Fedora on and off since... oh, 2004 or 2005? I've mostly been a
package maintainer, with a couple of code contributions to internal
projects here and there.
I am particularly interested in addressing and preventing several
reliability issues we've been having, but beyond listing them here I'll
probably start getting involved in current initiatives first to get a
better feel of the processes:
- post-release regressions especially as they affect either desktop UX
(graphics issues, sound issues, trackpad etc.) or network installation
- testing upcoming Fedora releases
- long-standing network installation issues (e.g. netinstalling on
ThinkPads but using an external network adapter instead of the official
dongle)
Long-term, I'm interested in building a process whereby we can collect
and report regression data from our userbase, without having all of them
sign up to be Fedora contributors.
Feel free to message me for my company email if you need it, or to ask
any question (happy to answer them here too). Trying to not use my work
email for mailing lists since... Outlook is terrible. Especially on Linux ;)
Best regards,
--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
3 years, 5 months
Thanks people, great job
by Scott Robbins
I remember when Fedora used to be an aggravating adventure. These days,
even though in a FreeBSD shop I don't rely upon it as much as I used to, I
am finding upgrades to go smoothly. I don't keep that much important or
complex programs on them, but enough so that a laptop could serve me for
work if needed.
In this last upgrade, from F31 to F32, the only issue I had was a missing
shared object (or library, I've actually forgotten) for VirtualBox. I just
unistalled it and resinstalled after the upgrade.
Anyway, these days, upgrades go much more smoothly than in the past. I use
dwm and openbox, so there isn't a desktop environment to worry about, but
that's what I've always used and it used to be an adventure.
So thank you to all of you who have worked so hard to make upgrades easy.
Sincerely,
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
3 years, 5 months
