Bug 477737

Summary: klipper doesn't remember settings across sessions
Product: [Fedora] Fedora Reporter: Amit Shah <amit.shah>
Component: kdebase-workspaceAssignee: Than Ngo <than>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 10CC: aalam, amit.shah, fedora, jreznik, kevin, lorenzo, ltinkl, rdieter, than, tuxbrewr
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-10 05:46:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Amit Shah 2008-12-23 06:28:25 UTC
If I enable actions for klipper, they're not remembered across sessions. I have to enable them each time I logout and login again.

Comment 1 A S Alam 2008-12-23 06:51:13 UTC
Thank you for taking the time to report this bug. This bug report isn't very
useful because it doesn't describe the bug well. If you have time and can
still reproduce the bug, please read
http://fedoraproject.org/wiki/BugsAndFeatureRequests and add a more useful
description to this bug.
Thank you.

Comment 2 Kevin Kofler 2008-12-23 09:18:42 UTC
I think it's pretty clear what is meant. Klipper has a checkbox "Enable actions" in the popup menu, it can be enabled or disabled. This setting is what is not being remembered. (I haven't tried this myself yet, I'm just explaining.)

Comment 3 Amit Shah 2008-12-23 09:23:53 UTC
Thanks, Kevin. That's exactly what I mean.

Comment 4 Steven M. Parrish 2009-01-09 20:03:22 UTC
Thank you for the bug report.  This issue needs to be addressed by the upstream developers.  Please submit a report at http://bugs.kde.org. You are requested to add the bugzilla link here for tracking purposes. Please make sure the bug isn't already in the upstream bug tracker before filing it.

Comment 5 Amit Shah 2009-01-10 05:27:47 UTC
Really? A reporter should take the pain of reporting upstream instead of the packagers doing it? This makes for a very bad user experience.

The implication here is that a user not only has to report the bug into Fedora's bugzilla, but he also has to report it upstream.

Is this bugzilla only meant for packaging-related bugs? If that's the case, I can never hope to get a fix in my current packages until upstream fixes the bug and those packages make their way into a stable Fedora release. Which means users have to live with such bugs for a really long time. In this case, the upstream is KDE, which isn't too amenable in backporting fixes to stable releases if the fix has been scheduled for an upcoming major release. So in all probability, upstream will only fix this for 4.2.x and Fedora won't get this till the next release in the default install.

Comment 6 Amit Shah 2009-01-10 05:32:56 UTC
Well, I've filed a KDE bug #180215.

Comment 7 Rex Dieter 2009-01-10 05:44:04 UTC
fedora's mantra is "work upstream", and that extends, to some extent, to our users.

We'd like to triage items that are fixable locally first, of course, but if not, then upstream is really the only place where reports make sense.  The assertion that maintainers take reponsibility to forward items isn't practical and doesn't scale, for better or worse.

And, fwiw, kde-4.2.x will be coming soon to all current releases of fedora asap.

Comment 8 Rex Dieter 2009-01-10 05:46:33 UTC
Oh, and many thanks for taking the extra effort to report this upstream.  Much appreciated.  We'll continue tracking this there.

Comment 9 Kevin Kofler 2009-01-10 05:51:09 UTC
(I wrote this comment while Rex posted his 2 comments, so there's some overlap, sorry.)

> Really? A reporter should take the pain of reporting upstream instead of the
> packagers doing it? This makes for a very bad user experience.

But it's the only way upstream can ask you for any followup comments without each time having to go through a middleman.

> Which means users have to live with such bugs for a really long time.

Actually, fixes usually go out to Fedora fairly quickly. KDE releases bugfix releases about once a month, we push them out as updates.

If you think a fix is really urgent, you can reopen the bug as soon as upstream fixes it and ask us to backport the fix without even waiting for the next bugfix release. (I'm not sure this one warrants such an expedited treatment though.)

> In this case, the upstream is KDE, which isn't too amenable in backporting fixes
> to stable releases if the fix has been scheduled for an upcoming major release.

Bugfixes are supposed to be backported in KDE, if they aren't, try nagging the upstream maintainer, if they ignore it, complain to us, a few of us (including me) have KDE SVN access and can backport the fix to the upstream stable branch. (And if it's contentious for some reason, there's always the option to backport it in the Fedora package.)

Features are a different story, upstream's policy there is pretty strict, they tend not to backport even fixes for feature regressions. We will in some cases consider backporting important features in the Fedora packages. But for that we need to have something to backport first, i.e. the feature needs to be implemented upstream first (and usually not by us, there are only so many things we can do in a day).

We'll see what upstream will consider this to be.

> So in all probability, upstream will only fix this for 4.2.x and Fedora won't
> get this till the next release in the default install.

4.2 will be pushed out as an update to Fedora 9 and 10.