Re: digikam and kipi-plugins?
by Rex Dieter
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
5 years, 1 month
Mouse Wheel gone
by Christian Menzel
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
5 years, 1 month
Re: NFS failure
by Fulko.Hew@sita.aero
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.
5 years, 1 month
Re: Test GIMP 2.7/2.8 ?
by Valent Turkovic
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
11 years
kstartupconfig4 error
by Jim Bevier
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
11 years
Bugzilla semantics: marking bugs as triaged
by Adam Williamson
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
11 years
Fedora 12 QA retrospective - feedback needed
by James Laska
Greetings folks,
Whether you call it a post-mortem, retrospective or lessons learned ...
the end result is the same. I'd like to collect thoughts on how
good/bad of a job the QA group did in planning and testing the Fedora 12
release. In keeping with the release-wide retrospective from Fedora 11
[1], feel free to share any wishlist items as well.
I've started the discussion on the wiki at
https://fedoraproject.org/wiki/Fedora_12_QA_Retrospective.
Adding your thoughts is easy ...
* Edit the wiki directly (instructions provided for ~anonymous
feedback)
* Or, reply to this mail (I'll collect feedback and add to the
wiki)
Over the next week, I plan to organize any feedback and discuss the
highlights during an upcoming QA team meeting. The goal will be to
prioritize the pain points and use as a basis for defining objectives
for Fedora 13.
Thanks for your feedback!
James
[1] https://fedoraproject.org/wiki/Fedora_11_Retrospective_Notes
11 years, 1 month
fc13 kernels
by Rob Healey
Greetings:
I am having sincere problems with the Fc13 kernels and I am not sure why?
BTW, I have a 64bit system, so the kernels are also 64bit kernels. On
kernel-2.6.32-0.33, I was not able to even install this one...
On kernels 2.6.32-0.48* and kerenl-2.6.32-0.51*, I can install them, and
then booting is what the problem comes in. It gives me the three color
chasing bar, and it completes its cycle just fine. It then flips to a black
screen with a flashing underline and nothing else. I was wondering if it
just needed some time to time out some bugs, but nothing more than the black
screen...
I know that my system is not hard locked up because I can press
[Ctrl-Alt-Del], and it goes into reboot mode and shows everything that it is
shutting down....
Has anyone else had these same or similar problems as I have?
My installation history is:
1) install from FC12-Beta-x86_64 iso cdrom. Updated to current FC12, then
updated to rawhide. I tried installing hwccac? that was mentioned before,
and I can't seem to find the package anywhere.
I am using an Asus AMD K8 64-bit system. If it makes a difference....
Sincerely yours,
Rob G. Healey
11 years, 1 month
Installing Rawhide
by Chuck Forsberg WA7KGX
I tried upgrading f12 to rawhide by adding rawhide
as a software source. This was too big a task even
with --skip-broken and the other suggested remedies.
Is it time for the images directory to reappear?
In the past many problems with updated rawhides
have been solved by doing a fresh install from
boot.iso or pxeboot.
--
Chuck Forsberg caf(a)omen.com www.omen.com 503-614-0430
Developer of Industrial ZMODEM(Tm) for Embedded Applications
Omen Technology Inc "The High Reliability Software"
10255 NW Old Cornelius Pass Portland OR 97231 FAX 629-0665
11 years, 1 month