test February 2019

test@lists.fedoraproject.org

37 participants
115 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 08 Jul '19

08 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

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

01 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 01 Apr '19

01 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

F30 - podman run ; iptabels PRE_trusted
by Douglas E. Hopley Jr. 16 Mar '19

16 Mar '19

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

3 3

Re: Blocking criteria proposal for F30+: Printing
by Stephen Gallagher 11 Mar '19

11 Mar '19

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.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test February 2019