Too much changed in the last 3 years, it does not make sense to follow up on
this bug. Feel free to re-open if you can replicate it with current releases.

Testing pinentry-qt Version: 0.8.0.svn234-0kk1 (the changelog indicates
that the change is in) on Debian Lenny with KWin from KDE 3.

May we close this bug now?

Applied to trunk.

D116: 298_pinentry-qt-fix-1162.diff

Am Dienstag, 8. Juni 2010 12:29:40 schrieb Marc Mutz:

so I've attached the diff to current
pinentry SVN here. Works for me. Kwin/qt3 from etch for Qt3-version,
Qt-4.4.3 (self-compiled) + kwin/qt3 for Qt4-version.

The docs say on some X11 WM's, this flag will have no effect when not also
WX11BypassWM is passed, but the latter robs pinentry of it's title bar and
borders, so I left it out.

Werner, again see my tests with Kwin (default windows manager of KDE).
I believe that we should solve the issue for very common window managers.
KWin is very common for pinentry-qt3. Maybe we can ask some KDAB folks for help
on this one, should not be that hard I guess.

If you enter something on another desktop the pinentry should notice it and
return a cancel error. It all depends on the windows manager, though.

Testing pinentry Version: 0.8.0.svn231-0kk1
with window manager kwin from kdebase Version: 4:3.5.9.dfsg.1-6+lenny1.

Let me know if I shall do a 0.8.1 release.

Fixed in the current svn. At least it works for me on Debian GNU/Linux sid and
Debian GNU/kfreebsd sid. The pinentry nows sticks to the the top and you should
not be able to change this - it is in the responsibility of the WM, though. I
am using xfwm.

I can't replicate this with pinentry-qt 0.8.0 but still with the gtk2 version
with or without the Debian keyboard race fix.

Marcus, not yet so far. I would appreciate a test on your end, as I might not
get to the issue for a while. There should be enough information to reproduce
the issue.

Hi Bernhard,

many releases in the meantime thus I am pretty sure that this has been solved -
at least on the GnuPG side.

Just for completeness, there have been more fixed in dirmngr
and the symptom seems to also have happened because an http proxy
behaved
strangely.http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/src/crlfetch.c?root=Dirmngr&rev=323&r1=320&r2=323

Refocussing this issue on the "hang" symptom.

Sorry, typo in the URL, (there was one "kolab/" too much, but you could have
gotten to it via the main page. :) )
https://www.intevation.de/roundup/kolab/issue3583 (offline s/mime signing
without CRL for secret key gives unkown system error)

Sorry for the delay. I can not access the kolab tracker (404), has the link
changed? Errors for individual keys in a keylisting are not available in
detail, but only the invalid flag is set. When using an invalid key, a more
detailed reason may be available. There is currently no way to get more
detailed reasons about why a key in a key listing is invalid.

Sorry for the late response, only recently a new pinentry got released.
So we will test this on basis of 0.7.6.

No response - assuming that everything is fine now.