test March 2019

test@lists.fedoraproject.org

42 participants
193 discussions

NVIDIA Question
by David St.Clair 17 Jan '22

17 Jan '22

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

10 20

Mouse goes crazy
by Jonathan Villa 17 Jan '22

17 Jan '22

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. ???

8 7

Fedora Modular 27 compose report: 20171028.n.0 changes
by Fedora Branched Report 03 Nov '20

03 Nov '20

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 =====

1 0

Trying a upgrade from 29 to 30
by Ludovic Hirlimann 03 Nov '20

03 Nov '20

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

5 5

proposal: drop optical media from release criteria
by Matthew Miller 09 Jul '19

09 Jul '19

Justification: http://newsthump.com/2018/05/21/man-decides-to-keep-box-of-cables-hes-has-s… -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

19 85

Re: Criteria / validation proposal: drop Xen
by Adam Williamson 28 Apr '19

28 Apr '19

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

7 9

Self-introduction: Zubin
by zubin choudhary 09 Apr '19

09 Apr '19

Hi, I'm Zubin. I'm 19 years old. Using Linux for a while now wanted to contribute back to the community, Fedora is a great community to be part of. I have some experience in python scripting and on Web Programming. Looking forward to being a part of this community Zubin

2 1

"Basic graphics mode" feature and criterion discussion
by Adam Williamson 03 Apr '19

03 Apr '19

Hi folks! So at last week's Fedora 30 Beta Go/No-Go meeting, it was decided that the Basic release criterion: "Boot menu contents The boot menu for all supported installer and live images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa'). This mechanism should work correctly, launching the installer or desktop and attempting to use the generic driver." should no longer apply to Beta - i.e. that it should no longer be a Basic or Beta criterion. The justification for this is, I hope I am correctly representing all views here (please say so if not), that this mechanism is both less necessary (due to a general reduction in the amount of 'weird' graphics hardware out there, and general improvement in the reliability and coverage of the major drivers for the major graphics hardware manufacturers) and inherently less likely to work (due to the general trend of work on kernel modesetting and Wayland) than it used to be. For context, it is worth noting that the *feature* predates the introduction of both kernel modesetting *and* Wayland to Fedora. What the feature initially did was tell anaconda to write an X config file specifying the 'vesa' driver (instead of working out the correct 'native' driver for the adapter and writing a config file specifying that). After KMS was introduced in Fedora 10, the mechanism was tweaked to also pass the 'nomodeset' kernel parameter to disable KMS. Around 2012 (https://bugzilla.redhat.com/show_bug.cgi?id=858270) we noticed that the X config file mechanism was a bit superfluous as 'nomodeset' alone could basically be relied on to force some sort of 'fallback mechanism', and so the feature was simplified to *only* specify the 'nomodeset' kernel parameter (this is all it does now). The *criterion* dates to 2010, in the Fedora 15 release cycle: it appears in the Fedora 15 Alpha criteria but not the Fedora 14 Alpha criteria. It was added on 2010-08-16: https://fedoraproject.org/w/index.php?title=Fedora_15_Alpha_Release_Criteri… The group at the meeting did not, however, make any further decisions, so this leaves us with some open questions: 0) Do we generally agree with the decision made at the meeting? If anyone (especially a subject matter expert) strongly believes the decision was wrong and this should still be a Basic/Beta requirement, please say so. 1) Should the criterion be modified somehow, but some requirement in relation to some kind of fallback graphical mode be kept at Basic or Beta? 2) Should the criterion be moved to Final, unchanged or changed somehow? 3) Should the requirement just basically be dropped entirely as no longer useful? 4) (This one mainly for ajax and airlied) to what extent does the concept of a 'fallback option' for our supported desktop environments and graphical servers still actually make sense? Could a different implementation of the same basic idea be envisaged, and would it be useful? If so, should we do that, and what would be the consequences for the criteria? I realize this is quite a big and fuzzy topic, but I'm hoping the responses to this mail will clarify our path :) So if you have any kind of useful information or strong opinions on the general area here, please do contribute them, and hopefully a clearer way forward will emerge. Thanks everyone! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

8 13

dnf system-upgrade download --refresh --releasever=30 errors
by Felix Miata 02 Apr '19

02 Apr '19

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 5

Blocking criteria proposal for F30+: Printing
by Stephen Gallagher 02 Apr '19

02 Apr '19

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

8 13

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test March 2019