Bug 190932 - gpa: Inconsistent behaviour
gpa: Inconsistent behaviour
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: gpa (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-06 17:12 EDT by Piergiorgio Sartor
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-24 15:07:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Piergiorgio Sartor 2006-05-06 17:12:24 EDT
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.
Comment 1 Rex Dieter 2006-05-12 11:31:13 EDT
new gpgme-1.1.2-4/gpa-0.7.3-2 pushed to the repos.  Try it out.
Comment 2 Piergiorgio Sartor 2006-05-12 19:57:48 EDT
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.
Comment 3 Piergiorgio Sartor 2006-05-13 07:55:39 EDT
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?
Comment 4 Rex Dieter 2006-05-13 08:59:15 EDT
Clearly your commandline environment is different.  Do you set any gnupg-
releated environment variables (in ~/.bashrc, ~/.profile, ~/.bash_login)?
Comment 5 Piergiorgio Sartor 2006-05-13 09:29:29 EDT
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.
Comment 6 Piergiorgio Sartor 2006-05-13 09:33:19 EDT
Wait, sorry, also COLUMNS and LINES are defined in gnome-terminal,
as 80 and 24 respectively.
Comment 7 Rex Dieter 2006-05-13 09:37:26 EDT
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
Comment 8 Piergiorgio Sartor 2006-05-13 09:44:12 EDT
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.
Comment 9 Piergiorgio Sartor 2006-05-13 10:12:29 EDT
(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.
Comment 10 Rex Dieter 2006-05-13 10:31:29 EDT
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.
Comment 11 Piergiorgio Sartor 2006-05-13 10:55:38 EDT
(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.

Comment 12 Rex Dieter 2006-05-13 10:56:55 EDT
Fair enough.
Comment 13 Piergiorgio Sartor 2006-05-15 15:40:34 EDT
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.
Comment 14 Rex Dieter 2006-05-15 15:43:22 EDT
> Suggestions? Maybe some other mailing list?

http://lists.gnupg.org/mailman/listinfo/gpa-dev
Comment 15 Piergiorgio Sartor 2006-05-15 16:02:51 EDT
(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 ;-)
Comment 16 Piergiorgio Sartor 2006-05-28 11:58:54 EDT
(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

Note You need to log in before you can comment on or make changes to this bug.