test December 2009

test@lists.fedoraproject.org

98 participants
181 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

Re: Test GIMP 2.7/2.8 ?
by Valent Turkovic 11 Jan '10

11 Jan '10

On Fri, 09 Oct 2009 18:34:25 +0000, Valent Turkovic wrote: > I there a way to test new GIMP 2.7/2.8 in Fedora? I looked in Rawhide > repos and I still see only 2.6x versions there. Any plans to put 2.7 in > Rawhide repost for testing purposes? Should I ask on development channel? -- pratite me na twitteru - www.twitter.com/valentt http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic

5 6

kstartupconfig4 error
by Jim Bevier 11 Jan '10

11 Jan '10

I did an i386 upgrade from F11 -> F12 on two different systems using the install DVD. They both use gnome and kde desktops. After the upgrade, I try to log in using kde and I get the error: "kstartupconfig4 does not exist or fails. The error code is 127. Check your installation". After some searching, I found this same error was present in F10->F11 upgrade. It seems during the upgrade, libssl.so.8 and libcrypto.so.8 links are removed and kstartupconfig4 can no longer start. In /usr/lib I did "ln -s libssl.so libssl.so.8" and "ln -s libcrypto.so libcrypto.so.8". This then allowed kstartupconfig4 to run and kde worked again. I did not see any mention of this problem on the rawhide list during beta & RC testing, so I guess nobody did this type of upgrade. Hope this helps someone. Jim

3 3

Proposal for new QA test for L10N
by Noriko Mizumoto 04 Jan '10

04 Jan '10

Hi QA team I am Noriko Mizumoto, coming from Fedora Localization Project. As we are in scheduling period, I'd like to propose new QA test to be created. Here is the detail. I am quite new to QA activity, so it would be highly appreciated for your guidance. [Introduction] For software translations, FLP translators work on PO file so they never know where particular string to be appeared in UI. The Build release packages for review allows translators to review their work in UI with the aspect of QA and to give a chance for correction. This event have been proposed by FLSCo and approved by FESCo [1]. [Test Strategy] This is the course of events order which can be found in the schedule [2]. 1) Software String Freeze (*Request f-dev-announcement for Build F13 pkgs with latest translation for L10n Review) 2) Software Translation Period (POT to PO) 3) Build F-13 collection packages for all language translators 4) Review and correct software translation in built UI 5) Software: Translation Deadline (PO Files complete) 6) Software: Start Rebuild all translated packages 7) Software: Rebuild all translated packages 8) Beta Freeze At 3), all F13 packages will be built with latest translation by packagers. Then at the end of 3), Live Image needs to be crated for QA. [Test Priority] n/a [Scope] All components (packages) under F13 release [3]. [Test Pass/Fail Criteria] The test will be completed at the deadline date. See, 5) Software: Translation Deadline (PO Files complete) 7 Test Deliverables * High quality of translation * Bugs will be filed against package(s) which shows problem in translation [4]. [Test Cases] "Instruction" for consistent test to be created and posted. [Test Environment] n/a [Responsibilities] Packagers: Build packages with latest translation Translators: QA test for translation quality QA: Create Live image [Schedule] See test strategy. [Risks] Package not built according to the schedule by packagers. If this happens, that package will not display latest translation in UI making unable to review. To prevent this, the request (shown with bracket in the above) will be sent to f-devel-announce before 3) Build F-13 collection packages for all language translators. [Reviewers] ? [References] [1]:https://fedorahosted.org/fesco/ticket/243 [2]:http://poelstra.fedorapeople.org/schedules/f-13/f-13-all-tasks.html [3]:https://translate.fedoraproject.org/languages/nl/collection/fedora/fedor… [4]:https://fedoraproject.org/wiki/L10N/UpdatePot Thanks noriko

4 7

Bugzilla semantics: marking bugs as triaged
by Adam Williamson 04 Jan '10

04 Jan '10

I had interesting discussions with Andy Lindeberg and jlaska today about the semantics of our current Bugzilla - and particularly triage - workflow. We were thinking about the NEW / ASSIGNED dichotomy, and Andy and I came to the conclusion that it doesn't really make a lot of sense. Right now, Bugzappers uses it one way, Andy uses it another for anaconda. In the Bugzappers process, ASSIGNED just means, really, Triaged: you set a bug to ASSIGNED once the triage process is complete. For Anaconda, Andy sets bugs to ASSIGNED once they're assigned to the correct anaconda maintainer (whether or not the rest of triage is yet fully completed). Neither case is really terribly problematic, but they also don't make a whole lot of sense, really. Having 'triage completed' as a status is a bit arguable; it's not quite in the flow of the statuses, as a bug could be at a point 'beyond' ASSIGNED but not yet have been triaged, for instance. And it's also just semantically wrong - the word 'assigned' does not mean 'triaged'. In the anaconda case, we just thought about it and decided the use of ASSIGNED isn't really _achieving_ anything: you can tell whether the bug's been assigned or not just by looking at who it's assigned to. We sort of came to the conclusion that it'd probably make the most sense to have a 'Triaged' keyword that's used to affirm that a bug's been triaged (in fact there already is one, but it's not officially used in our current process), and abandon the distinction between NEW and ASSIGNED. Ideally, the ASSIGNED state would just be removed, but we could keep it and just note in our workflow / policy that it's not really used to mean anything in particular. This could, I think, be implemented quite quickly if desired; I think we could rig something up to set all bugs in ASSIGNED state (except anaconda ones) to have the 'Triaged' keyword, that shouldn't be impossible. We'd be interested in thoughts - negative, positive, whatever - on the idea. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net

9 36

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 2009