Description of problem: Even though, I checked "Automatically unlock this keyring whenever I'm logged in" at Unlock Keyring screen, gnome-keyring-prompt always asks password for unlock when I'm logged in. This unlock needs to connect Wireless LAN. I did clean install F14 LXDE spin that iso download from following url. http://alt.fedoraproject.org/pub/alt/stage/14.TC1.1/Live/ Version-Release number of selected component (if applicable): libgnome-keyring-2.32.0-1.fc14.i686 gnome-python2-gnomekeyring-2.32.0-1.fc14.i686 gnome-keyring-2.32.0-1.fc14.i686 How reproducible: Always. Steps to Reproduce: *I use Wireless LAN 1.Install LXDE spin and complete firstboot. 2.Login desktop. 3.Left click Network Manager Applet and select your router. 4.Enter WPA2 key or like. Then gnome-keyring-prompt will be appeared. 5.Enter unlock password and click OK button. 6.Logout. 7.Login desktop. Then gnome-keyring-prompt will be appeared. 8.Enter password. 9.Click triangle to open Details. 10.Select "Automatically unlock this keyring whenever I'm logged in" 11.Click OK button. 12. Logout. 13. Login desktop. Actual results: gnome-keyring-prompt will be appeared Expected results: gnome-keyring-prompt doesn't appeared. Additional info: I tested this test case. https://fedoraproject.org/wiki/QA:Testcase_desktop_keyring
For more information. I mainly use a laptop which desktop environment is Gnome doesn't have the issue. It always automatically connect to Wireless network, when I'm logged in. Keyring packages are below. libgnome-keyring-debuginfo-2.32.0-1.fc14.x86_64 gnome-keyring-2.32.0-1.fc14.x86_64 gnome-keyring-pam-2.32.0-1.fc14.x86_64 libgnome-keyring-2.32.0-1.fc14.i686 gnome-python2-gnomekeyring-2.32.0-1.fc14.x86_64 libgnome-keyring-2.32.0-1.fc14.x86_64
CCing LXDE maintainer as this appears LXDE-specific (or at least, non-GNOME specific) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
It uses to work with the LXDE version that is in the spin, something must have changed in gnome-keyring. Have there been any changes lately in the package?
Seems is no longer pulled in on the livecd, added to the ks in http://git.fedorahosted.org/git?p=spin-kickstarts.git;a=commit;h=8b9397c3caa4ca86095f518f0c5e154a42c89c29 Taking over and reassigning to lxde-common as there is no "LiceCD - LXDE" component in bugzilla.
so this will be broken for all LXDE users ootb. can we address this with an update by making some LXDE component depend on gnome-keyring-pam? Or should we just document on commonbugs that you should install it manually? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
or, jesse, could we do a quick respin of LXDE, since it's just a package set change? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I'm not inclined to re-spin something mere hours before the go/nogo decision. Granted it's only adding an existing build to the manifest, but things can (and have) go(ne) wrong with the compose process and I'd hate to invalidate any testing LXDE has gotten so far. Is this issue severe enough to warrant the risk of respinning at this moment?
(In reply to comment #7) > I'd hate to invalidate any testing LXDE has gotten so far. I doubt it has gotten any testing as the only failed test (cause of this bug) was already found in the beta. > Is this issue severe enough to warrant the risk of respinning at this moment? I think it is as it is a desktop validation test case, but the ultimate decision should be up to rel-eng. As the spin maintainer I'd like to apologize for not being able to help out more, but I'm currently overworked in my dayjob.
christoph: the TC and RC both got full testing from Masami: https://fedoraproject.org/wiki/Test_Results:Fedora_14_Final_TC1_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_14_Final_RC1_Desktop I don't think the change would invalidate the testing, but as christoph says I'm happy to defer to jesse, really. Christoph, can you think of a hack to deal with this via a 0-day update or are we stuck documenting it? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #9) > christoph: the TC and RC both got full testing from Masami: Ok, I was under the impression that the previous results were just copied over to the new wiki page, but according to the history this is not true. > Christoph, can you think of a hack to deal > with this via a 0-day update or are we stuck documenting it? A 0day update will not help us for the live media (which is often used to make persistent USB keys) and I cannot think of a way to fix this on a packaging level. LXDE is meant to be a minimal and modular desktop, so I don't want to hardcode and GNOME deps there. I don't want to do this in comps as default ether (only optional is ok for me). Frankly speaking I'd prefer a quick respin, but I am not to decide on that. All I can do is offer to do a complete test of the new image. I don't expect any regressions. We had way more risky changes (like the glibc update less than a week ago).
Why isn't there a dependency here? You've got some application offering functionality, that it cannot make good on without supporting software. How is that not a dependency? One could argue that the application shouldn't offer the functionality without the backing software, which would make it a soft-dep and thus optional, but that's not currently the case.
Well, it's gnome-keyring that offers the functionality, I believe, so if anything, gnome-keyring should have a dep on gnome-keyring-pam. But presumably the thinking there is that gnome-keyring *works* without gnome-keyring-pam , just remembering passwords doesn't. And perhaps there's an alternative backing for gnome-keyring aside from gnome-keyring-pam? Not sure. I don't see one. For reference, it appears that the dependencies that bring gnome-keyring-pam into the desktop spin are gdm and gnome-screensaver (both require gnome-keyring-pam). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
CCing tbzatek and mclasen (from the gnome-keyring changelog), what's your take on this? should gnome-keyring require gnome-keyring-pam? Why is it separated out? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
christoph: I don't see this being broken on the live image per se as a particularly big deal, as I doubt most live CD use cases involve remembering a lot of passwords, it's not like you log in and log out of the live CD a lot usually. I think the main impact of this is it being broken after install, which is something we can address with an update if we come up with a good way to fix it with an update. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I agree it is not a problem on the livecd, but it will become one for people doing USB. And the biggest problem for me is: How can we solve this? There is no way to make people install the additional package and I doubt that many read the documentation. BTW: Where do you want to document it? In the release notes? I guess this will be more work than a respin as the release notes have to be translated.
(In reply to comment #13) > CCing tbzatek and mclasen (from the gnome-keyring changelog), what's your take > on this? should gnome-keyring require gnome-keyring-pam? Why is it separated > out? Not necessarily, but I don't mind, don't have personal opinion on this. People might want to rip the pam module out for whatever reason but hey, we're Fedora, we don't usually let users to do so.
Reassigning to new 'LiveCD - LXDE' component.
So, where do we go from here? It is too late for a respin, but how about the documentation?
We're seeing exactly the same problem on the sugar spin.
Nice to see I'm not alone. ;) It's too late to fix this and we can do nothing but document it. I have added a paragraph to the F14 common bugs: https://fedoraproject.org/wiki/Common_F14_bugs#Gnome_keyring_asks_for_password_each_time_LXDE_starts I suggest you do the same for SOAS.
> I suggest you do the same for SOAS. I already have, unfortunately due to massive work commitments I didn't get the chance to investigate it properly before release (and I wasn't seeing it on all my systems), and I suspect due to the user base we're going to end up doing a customer fedora remix and point people to that (which I _really_ don't want to do) to stop riots with in the sugar community as using it on a stick like the way it is breaks collaboration. The funny thing is that it includes gdm so I'm not sure why we're seeing it still.
I'm not sure the Sugar bug is actually the same. What I see in Sugar is that gnome-keyring pops up as soon as I boot and demands a password for the keyring. I enter a password, then it asks again. No matter how many times I enter a password, it keeps asking; all you can do to break the cycle is hit Cancel. That's not the bug seen on LXDE at all. What happens there is that it can happily *create* a password for the keyring, it just won't remember it, even if you ask it to. You'll have to enter it at each boot. But you can create it properly, and entering it after creation works properly. You don't get this infinite-cycle-of-password-creation-windows problem. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I agree to Adam, it is not the same bug. Peter, please open a new one and let it block bug 601827. For this bug I think I have done all I can and I'm going to close it now.
I'm going to re-open this and assign it to gnome-keyring because I don't think what gnome-keyring does is particularly sensible. It shouldn't offer an option it can't guarantee it can back up (the 'remember password') option. Probably the 'most correct' way to fix this would be to have gnome-keyring call PackageKit to install gnome-keyring-pam if you check the box without that package installed, but I think gnome-keyring maintainer should really take a look at whether it makes any sense to have gnome-keyring-pam split out in the first place. What's the use case for not installing it? What does it benefit you? A tiny amount of disk space? Is there any other reasonable reason anyone would want to not install it? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Removing LXDE blocker because this is no longer LXDE specific.
I am on LXDE F14. I have ran su -c 'yum install gnome-keyring-pam' to install the package, following the wiki page 'commonf14 bug' http://fedoraproject.org/wiki/Common_F14_bugs. the option "Automatically unlock this keyring whenever I'm logged in" is still greyed out, and I have to enter the password after each log-in to enable a wireless connection. Do I need to remove the keyring and how? My keyring password is the same as my log-in password. Thank you.
the password prompt does not re-appear after I removed all the files under /.gnome2/keyrings/*, logged-out & logged-in.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping