Description of problem: Same as bug #190929, depending on how gpa is launched, menu or command line, some operation are unsucceful or not. Version-Release number of selected component (if applicable): 0.7.0-5.fc4 How reproducible: Always. Steps to Reproduce: 1. Start gpa from menu. 2. Try to change the owner trust of a key. 3. Try the same, but launching gpa from shell. Actual results: From menu no result, from shell the operation is succesful. Expected results: Always consistent, i.e. always succesful. Additional info: Also in this case, maybe version 0.7.3 could fix the problem.
new gpgme-1.1.2-4/gpa-0.7.3-2 pushed to the repos. Try it out.
I found the new gpa-0.7.3-2, but only for FC5, not FC4 (which this bug report refers to) and I did not find the gpme-1.1.2-4, yet. Anyway, I tried the updated gpa alone, from command line and from menu, and it seems to me it is working. I was able to set the owner trust and sign the keys (see bug #190931) without problems. I only had once a strange effect, which I cannot confirm now (eventually I'll open a new bug). While setting the owner trust of a public key, also the key validity was set to "Full Valid", which, I guess, should only occur when signing the key. This happen only once, as said before, while performing several test, so I cannot consider it reproducible, right now. Since this bug seems to be solved, at least for FC5, I'll change it to WORKSFORME, eventually this could be closed. Thanks.
I just update the FC4 installation to gpa-0.7.3-2 and gpgme-1.1.2-4, and I saw that the problem persists. If gpa is launched from shell (gnome-terminal), everything works fine, I can change the owner trust and sign the keys without problems. But if gpa is started from menu (under Accessories), these operation simply do not occur. For example, selecting a key and, with the pull-down menu, choosing "Set owner trust", opens the requester, but once the choice is done and confirmed (and the requester closes) nothing changes in the key owner trust, like nothing was done. My impression is that some terminal I/O is different in the two cases: from shell the stdin/err/out is, I guess, well defined, while from menu... I do not know, maybe something is missing. I must say that the (positive) test under FC5 was done using a remote machine, so, maybe, the shell/menu context could have been somehow different (even if before the problem was there in the same condition). So, conclusion is, in my opinion, that something else in the system is causing the problem. Final note, I tested with kernel 2.6.16-1.2108_FC4 and with a custom one, with same results... How should we proceed? Any idea on how to check this?
Clearly your commandline environment is different. Do you set any gnupg- releated environment variables (in ~/.bashrc, ~/.profile, ~/.bash_login)?
As far as I can see, the bash files are free from reference to gpg. Of the environmental variables used by gpg (from the man page): HOME GNUPGHOME GPG_AGENT_INFO http_proxy COLUMNS LINES Only HOME is defined (of course), in the proper way. On the other hand, the bash is where gpa works perfectly, it is from the menu that it fails. Actually, it does not even "fail", it simply does nothing, without any error or other messages. This is making things difficult: there is no feedback on what does not work. And the same problem has seahorse, so I guess there should be some connection, only I've no idea on where to check. Thanks.
Wait, sorry, also COLUMNS and LINES are defined in gnome-terminal, as 80 and 24 respectively.
This is starting to sound like more of a usability issue, rather than a packaging one. I'd suggest you post your findings to the gpa mailing list: http://lists.gnupg.org/mailman/listinfo/gpa-dev
Since I'm here, I'll write more :-) I tried to "Add to Panel" gpa and, in the properties, set "Run in terminal", and, of course, this worked as launching gpa from command line.
(In reply to comment #7) > This is starting to sound like more of a usability issue, rather than a > packaging one. Well, maybe a build issue, or a dependecy one, I dunno. But, of course, I assume you cannot reproduce the problem, can you? What I noticed, as difference between FC4 and FC5, is libgpg-error, which is version 1.0-2 and 1.1-1.2.1 respectively. Maybe this could cause the different beahviour. > I'd suggest you post your findings to the gpa mailing list: > http://lists.gnupg.org/mailman/listinfo/gpa-dev Oh no please! :-) Not an other mailing list... Can't we solve this here? Thanks.
I'm hesitant to forward the issue upstream myself, because: 1. I cannot reproduce it (though I don't use FC4 either, mostly RHEL4/FC5). 2. I can't (directly) answer any questions the upstream devs may have. (: Now, if you absolutely refuse to take the issue upstream, I will do it myself, but the likelyhood of resolving this will be greatly reduced without your direct involvment.
(In reply to comment #10) > I'm hesitant to forward the issue upstream myself, because: > 1. I cannot reproduce it (though I don't use FC4 either, mostly RHEL4/FC5). > 2. I can't (directly) answer any questions the upstream devs may have. (: > > Now, if you absolutely refuse to take the issue upstream, I will do it myself, > but the likelyhood of resolving this will be greatly reduced without your direct > involvment. OK, I understand this, but what if the problem is from the FC4 environment? Like gnome or the kernel itself? I mean, before reporting it upstream, I would like to be sure it is not a local FC4 problem. I'll do this: I've GPA compiled for win32 (but not here), I'll check that one for this issue, and, if the result will be the same (which should exclude a specific FC4 dependency), I'll report upstream. Otherwise, we will have to think about an other possibility, i.e. some local (I mean FC4) problem and the way to find it. Is this OK for you? Thanks.
Fair enough.
OK, here we go. As mentioned above, I have gpa 0.7.3 compiled for win32 under cygwin. Unfortunately, this one need to be started from command line, i.e. from cygwin bash, which, of course, is the "good" situation, and, in fact, it worked fine, I could set the owner trust and so on. So, I decided to try something else. I downloaded gpg4win and installed gpa (still 0.7.3). This, started from menu, also worked fine, without any problem (except the multiple keys encryption, but this is a different story, I guess). Just some reminders: 1) Under FC5 gpa seems to work fine as well as under win32. 2) Seahorse, under FC4, has exactly the very same problem (there is a bug opened for it, no reply until now). 3) Seahorse seems to work fine under FC5. My conclusion is that this is not a specific problem of gpa, but something related to encryption (maybe gpgme, I dunno) and FC4. Question is: how should we proceed? I would like to nail this down, but I have no clue on what could be done. Suggestions? Maybe some other mailing list? Or I _must_ upgrade to FC5...? :-) Thanks.
> Suggestions? Maybe some other mailing list? http://lists.gnupg.org/mailman/listinfo/gpa-dev
(In reply to comment #14) > > Suggestions? Maybe some other mailing list? > > http://lists.gnupg.org/mailman/listinfo/gpa-dev I see you insist on this :-) Well, OK, I'll try there, but if I will not get useful answers I'll come back here ;-)
(In reply to comment #14) > > Suggestions? Maybe some other mailing list? > > http://lists.gnupg.org/mailman/listinfo/gpa-dev > OK, maybe you followed the discussion in the mailing list. There was not too much discussion, but some good hint come out. It seems there is some "inconstistency" in the gpa<->gpgme communication between the FC4 and FC5 versions of gpa. I could not go any further. In the meantime, I upgraded the (main) PC to FC5, so I do not have the problem anymore. bye