test December 2014

test@lists.fedoraproject.org

59 participants
224 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

Re: digikam and kipi-plugins?
by Rex Dieter 22 Nov '15

22 Nov '15

Per Bothner wrote: > The Rawhide version of digikam is the very latest (0.10.0-rc1), > but it fails to find any of the "Kipi plugins", even though I've > installed the kipi-plugins package. This might be an upstream > issue, since 0.10.0 is pretty bleeding edge and the kipi-plugins > may even more bleeding-edge. Gwenview does seem to be see the > plugins, so I'm wondering if there is there might be a > Fedora-specific problem before I complain upstream ... The f10 builds seem to work fine for me (finding the plugins), so perhaps this is rawhide-specific? To be clear, digikam's Settings -> configure digikam -> Kipi Plugins is empty? -- Rex

2 1

Re: rawhide report: 20050419 changes
by Ray Strode 22 Nov '15

22 Nov '15

Hi, > Will yelp in FC4 be able to search and display man/info pages Yea, man and info pages work for me. --Ray

2 2

Mouse Wheel gone
by Christian Menzel 22 Nov '15

22 Nov '15

Since the latest xorg-X11 upgrade I receive the already mentioned XKB error and the mouse wheel is not working anymore. Has anybody seen this behavior? Regards Chris

3 3

Re: NFS failure
by Fulko.Hew＠sita.aero 22 Nov '15

22 Nov '15

Damian Menscher <menscher(a)uiuc.edu>@redhat.com on 04/07/2004 04:57:13 PM wrote: > On Wed, 7 Apr 2004, Jeff Elkins wrote: > > > I'm getting failure messages on my nfs mounts i.e. : > > > > mount to NFS server 'music.elkins' failed: server is down. > > > > nsfd appears to be running and I didn't see anything suspicious in the logs. > > The servers are up and running and have other clients connected. > > You didn't mention what steps you took to debug it: > > Can you ping the server? > What is the output of rpcinfo -p servername? > Does the server have access restrictions (firewall, TCP Wrappers, etc)? I have the same symptoms... rpcinfo says that nfs et.al. are running. Something has changed in test 2, since the same PC running RH9 accesses that host just fine.

7 9

OS X dual boot criterion problems
by Adam Williamson 06 Feb '15

06 Feb '15

Hi, folks. Talking to cmurf, our resident OS X dual boot expert, on #fedora-qa, it's become clear that when we adopted the OS X dual boot criterion a few weeks back, we didn't have a good understanding of the current state of that code and particularly upstream grub's support for booting OS X via UEFI. Basically it seems that booting OS X from grub didn't work then and doesn't work now and we can't realistically fix it, so we shouldn't have put that criterion in place because it's not something we can actually viably achieve. cmurf, roshi, kparal and I voted +1 to removing the criterion on that basis. I'm hoping cmurf will be kind enough to look at the issue again for the F22 cycle, in consultation with pjones if necessary, so we can put a realistic requirement in place before we get into F22 Alphas. If no-one has any objections, we'll make the removal formal ahead of tomorrow's Go/No-Go meeting for 21. Thanks folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

2 5

Release criterion proposal: "Package sets" (Alpha and Beta)
by Adam Williamson 30 Jan '15

30 Jan '15

The "Package sets" criterion for Alpha currently reads: "When doing a graphical install using the dedicated installer images, the installer must be able to install each of the release blocking desktops, as well as the minimal package set." This was drafted prior to Product-ization. It has a bug - you can't do that from the Server DVD, and that's intended - and two problems - it's too focused on desktops for the new Product-y world, and the 'graphical' restriction seems arbitrary (TUI should work regarding package sets too). It also is missing something: there's no requirement about what the *default* package set should be. I propose we re-word the Alpha criterion to: "When installing with a release-blocking dedicated installer image, the installer must be able to install the default package set." and add a Beta criterion: "When installing with a release-blocking dedicated installer image, the default package set must be correct." with an explanatory note that 'correct' means the package set intended by the group responsible for the image - Product WG, FESCo or whoever. I'm not sure whether we need a requirement for non-default package sets. Note that the case for offline media is already covered by Alpha criterion "No broken packages": "There must be no errors in any package on the release-blocking images which cause the package to fail to install." network installs using updates media don't really need to block on package set issues, as they can be fixed. That leaves the question of whether we'd want to block the release if, say, there was a bug which meant that if you tried to netinst KDE without the updates repos enabled, it failed. What do folks think about that? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

3 11

DNF kernel-devel: The Final Frontier
by poma 29 Jan '15

29 Jan '15

# yum install $(ls *3.16.0-0.rc6.git0.1.fc21.1.x86_64.rpm) ... --> Finished Dependency Resolution Dependencies Resolved ================================================================================================================================== Package Arch Version Repository Size ================================================================================================================================== Installing: kernel x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-3.16.0-0.rc6.git0.1.fc21.1.x86_64 0.0 kernel-core x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-core-3.16.0-0.rc6.git0.1.fc21.1.x86_64 40 M kernel-debug x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-debug-3.16.0-0.rc6.git0.1.fc21.1.x86_64 0.0 kernel-debug-core x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-debug-core-3.16.0-0.rc6.git0.1.fc21.1.x86_64 41 M kernel-debug-devel x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-debug-devel-3.16.0-0.rc6.git0.1.fc21.1.x86_64 34 M kernel-debug-modules x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-debug-modules-3.16.0-0.rc6.git0.1.fc21.1.x86_64 17 M kernel-debug-modules-extra x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-debug-modules-extra-3.16.0-0.rc6.git0.1.fc21.1.x86_64 2.2 M kernel-devel x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-devel-3.16.0-0.rc6.git0.1.fc21.1.x86_64 33 M kernel-modules x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-modules-3.16.0-0.rc6.git0.1.fc21.1.x86_64 17 M kernel-modules-extra x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-modules-extra-3.16.0-0.rc6.git0.1.fc21.1.x86_64 2.1 M Updating: kernel-headers x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-headers-3.16.0-0.rc6.git0.1.fc21.1.x86_64 3.2 M kernel-tools x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-tools-3.16.0-0.rc6.git0.1.fc21.1.x86_64 226 k kernel-tools-libs x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-tools-libs-3.16.0-0.rc6.git0.1.fc21.1.x86_64 18 k kernel-tools-libs-devel x86_64 3.16.0-0.rc6.git0.1.fc21.1 /kernel-tools-libs-devel-3.16.0-0.rc6.git0.1.fc21.1.x86_64 5.8 k perf x86_64 3.16.0-0.rc6.git0.1.fc21.1 /perf-3.16.0-0.rc6.git0.1.fc21.1.x86_64 2.4 M python-perf x86_64 3.16.0-0.rc6.git0.1.fc21.1 /python-perf-3.16.0-0.rc6.git0.1.fc21.1.x86_64 344 k Removing: kernel x86_64 3.16.0-0.rc5.git0.1.fc21 @rawhide-koji 0.0 kernel-core x86_64 3.16.0-0.rc5.git0.1.fc21 @rawhide-koji 40 M kernel-devel x86_64 3.16.0-0.rc5.git0.1.fc21 @rawhide-koji 33 M kernel-modules x86_64 3.16.0-0.rc5.git0.1.fc21 @rawhide-koji 17 M kernel-modules-extra x86_64 3.16.0-0.rc5.git0.1.fc21 @rawhide-koji 2.1 M Transaction Summary =================================================================================================================================== Install 10 Packages Upgrade 6 Packages Remove 5 Packages Total size: 193 M Is this ok [y/d/N]: y https://bugzilla.redhat.com/show_bug.cgi?id=1062997#c22 # dnf install $(ls *3.16.0-0.rc6.git0.1.fc21.1.x86_64.rpm) ... --> Finished dependency resolution Dependencies resolved. ===================================================================================== Package Arch Version Repository Size ===================================================================================== Installing: kernel x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 32 k kernel-core x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 18 M kernel-debug x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 32 k kernel-debug-core x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 19 M kernel-debug-devel x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 9.0 M kernel-debug-modules x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 18 M kernel-debug-modules-extra x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 2.3 M kernel-modules x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 17 M kernel-modules-extra x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 2.2 M Upgrading: kernel-devel x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 8.9 M kernel-headers x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 931 k kernel-tools x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 114 k kernel-tools-libs x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 38 k kernel-tools-libs-devel x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 35 k perf x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 983 k python-perf x86_64 3.16.0-0.rc6.git0.1.fc21.1 @commandline 125 k Removing: kernel x86_64 3.16.0-0.rc5.git0.1.fc21 @System 0 kernel-core x86_64 3.16.0-0.rc5.git0.1.fc21 @System 40 M kernel-modules x86_64 3.16.0-0.rc5.git0.1.fc21 @System 17 M kernel-modules-extra x86_64 3.16.0-0.rc5.git0.1.fc21 @System .1 M Transaction Summary ===================================================================================== Install 9 Packages Upgrade 7 Packages Remove 4 Packages Total size: 96 M Is this ok [y/N]: N poma

2 5

[Fedora QA] #322: New release criterion: no X libs in the minimal install set
by fedora-badges 29 Jan '15

29 Jan '15

#322: New release criterion: no X libs in the minimal install set ------------------------------+------------------ Reporter: mattdm | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Release criteria | Version: Keywords: | Blocked By: Blocking: | ------------------------------+------------------ = problem = There are no rules holding us to a sane minimal package set. Features which are added to minimal could pull in the whole universe. = analysis = Drawing the line at X11 seems reasonable. (And Wayland.) We can argue at length about what minimal means, but this is a fairly clear line in the sand ''and'' is usually a reasonable split at a package level ''and'' matches our historic practice (see vim packages for example). = enhancement recommendation = "No package in the minimal install set may have a dependency chain which includes the libX11, the core X11 library (or its equivalent in Wayland). Packages must split functionality requiring this into subpackages, or be removed from the minimal package set." My suggestion is to make this an Alpha criterion, so such issues can be resolved early, but I don't have strong feelings on the particular timing. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/322> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 21

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 December 2014