OK, the problem with D450 lies in the way the value obtained from clock_gettime(2) is used.

It turns out I cannot reproduce the bug with a 4.13.2 kernel. Whatever happened to times in slightly older kernels when VIRT_CPU_ACCOUNTING_GEN was enabled seems to have been fixed in newer kernels.

The Linux specific solution in /D450 looks like a good solution but it needs some testing.

Could you expand on this slightly?

OK, thanks for the info.

Avoid moving the window ourselves if the cursor happens to be on the same monitor than the currently focused window, since in that case the window will already be on the right monitor.

I am not sure I agree with the “cryptic error message” bit. I would think anyone knowledgeable enough to play with LC_ALL (or any other LC_* variable) should understand what “a locale function failed” means and conclude that maybe the best way to fix the problem is to leave LC_ALL alone.

Is this even something that we can control?

I just realized that my fix for T3253 was incomplete, it only works if grabbing is enabled. With GnuPG Agent not requesting grabbing by default since 2.1.23, that would make the fix useless in the default configuration. Coming with a new patch soon...

I suspect this is a duplicate of T3253, where the same behavior (non-floating pinentry dialog) was observed under both the i3 and the Awesome tiling window managers. This bug has been fixed in master and the fix will be part of the upcoming pinentry-1.1.0 release.

Free the memory allocated by the gnupg_exec_tool call (sorry about that...).

I implemented a possible fix in D442. The GnuPG Agent may call an external program (specified with the new --passphrase-checker option) to evaluate the passphrase's quality. This would allow to implement all kinds of metrics for passphrase strength, and to select one simply by choosing the right passphrase-checker.

Me personally I see T2103 as more pressing blocker to next release

Leave the tooltips in place but show them only if do not have to grab the keyboard. As suggested in the discussion in T3279.

Well, I am using pinentry-gtk2 1.0.0 on Awesome, and I just performed some tests with master as well.

Is this correct?

I can reproduce the described behavior. I have a 4.11.7 kernel with NO_HZ_IDLE=y and everything works fine, but if I set VIRT_CPU_ACCOUNTING_GEN (all other options remaining unchanged), the agent is stuck in the calibration loop (tested with GnuPG 2.1.21 and current master branch).

I've just pushed the two fixes. GNUPGHOME is now set to the tests directory when running the tests and gpg-connect-agent is now looked for in PATH at runtime.

All build artifacts are accessible

OK, I pushed my fix into master.

Since there is no news for the last two weeks, I am wondering: am I the one blocking the situation here? Are you waiting for me to do something to make progress?

I can confirm this behavior with the latest pinentry-gtk-2 under the Awesome window manager.

The cause of the regression may actually not be in GnuPG's code.

For information, this issue was also discussed on both gnupg-user and gnupg-devel back in january 2017. I mention it here for reference.

or am i missing something here?

Yes, I am ready to accept write access to the Scute repository.

I think the best method to make sure Scute can always find the socket is to use gpg-connect-agent to ask for the socket: we call gpg-connect-agent 'GETINFO socket_name' /bye and read the reply.