Hi,

I can still see that qt[1] is using the simplified pkg macros[2], while the
configure.ac is using proprietary method[3].

We are still missing PKG_PROG_PKG_CONFIG macro in configure.ac to make pkg
macros happy, this can remove all AC_PATH_PROG(PKG_CONFIG, pkg-config, no)
executions, see pinentry-0.9.5-build.patch, as you have PKG_CONFIG set.

The other changes to use PKG_CHECK_MODULES are optional but is there any reason
why not to use this macro instead of executing the pkg-config manually? This
macro has the advantage of allowing override via environment, and append proper
help.

If you like I can rebase this old patch set.

[1] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=blob;f=m4/qt.m4;hb=HEAD
[2]
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=blob;f=m4/pkg.m4;hb=HEAD
[3]
http:
//git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=blob;f=configure.ac;hb=HEAD#l431

links removed as I got "Edit Error: not allowed (too many links).

Maybe add configure parameter to ignore subarch for 99% of cases in which it
does not matter? This will avoid patching in most of the cases.

Thanks, but I do not understand the comment, do you suggest to patch this file
with every subarch out there? I still trying to understand why subarch is
important for the processing, it is a generic string.

0003-build-sync-qt4-pkg-config-behavior-with-other-pkg-co.patch - on top

optional

sync qt4 pkg-config behaviour

D317: 660_0003-build-sync-qt4-pkg-config-behavior-with-other-pkg-co.patch

0002-build-use-pkg.m4-for-pkg-config-usage.patch - on top

remove the manual pkg-config usage, as build already use pkg.m4 macros there is
no reason to use manual pkg-config

D318: 659_0002-build-use-pkg.m4-for-pkg-config-usage.patch

D319: 658_pinentry-0.9.5-build.patch

I am unsure I understand, this causes gpgme to fail.

GPGME 2014-12-26 01:12:58 <0x5f44> _gpgme_run_io_cb: call: item=0xd2e804f5b00,
handler (0xd2e804f5970, 13)
GPGME 2014-12-26 01:12:58 <0x5f44> chan_12 <- ERR 50331822 Unknown option <GpgSM>

GPGME 2014-12-26 01:12:58 <0x5f44> gpgme:status_handler: call:
gpgsm=0xd2e804f5970, fd 0xd: ERR line - mapped to: Unknown option

I try to imagine where the subarch can cause an issue, maybe a big fat warning
when mapping should be sufficient at this point?

For now I will add a note for everyone that opens a bug for this reason to
duplicate the unknown subarch into his own, package will not be compiled
automatically for these.

Thanks!

D207: 445_libgpg-error-1.13-t-lock.patch

the tarball is OK, however, we must patch the autoconf[1], so we also use the
automake installed at user site which may be newer than 1.13.

it seems that this expression has no effect to 1.13 and damage the 1.14...

bench-slope.log: benchmark.log
hashtest-256g.log: bench-slope.log

you can close this issue, but know that it does exist in newer versions of
automake. if there is no real need for the above statements then removing them
resolves the issue.

[1]
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libgcrypt/files/libgcrypt-1.5.0-uscore.patch?revision=1.1&view=markup

That was added because we have it in master.

Have 'it'? I see it in the tarball of 1.6.

Again: If you do not use the tarball release do not expect that pacthes will

be included. You should never do autoreconf.

We do use the tarball release, and we must patch it to resolve issues you do not
handle as I presented in previous comment.

We patch your sources mainly because[1], I will be happy to stop autoreconf your
packages, but cannot do this until this and other issues are resolved.

[1]
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libgcrypt/files/libgcrypt-1.5.0-uscore.patch?revision=1.1&view=markup

OK, someone already tried to solve it at your side:

tests/Makefile.am

1. Force sequential run of some tests. bench-slope.log: benchmark.log hashtest-256g.log: bench-slope.log

However, from automake manual:

In order to guarantee an ordering between tests even with make -jN, dependencies
between the corresponding .log files may be specified through usual make
dependencies. For example, the following snippet lets the test named
foo-execute.test depend upon completion of the test foo-compile.test:

TESTS = foo-compile.test foo-execute.test
foo-execute.log: foo-compile.log

Please note that this ordering ignores the results of required tests, thus the
test foo-execute.test is run even if the test foo-compile.test failed or was
skipped beforehand. Further, please note that specifying such dependencies
currently works only for tests that end in one of the suffixes listed in
TEST_EXTENSIONS.

Removing the above makes all works in parallel without specific order, which is
nice... unsure why the above was added when there is no real dependency, and
prior to automake-1.13 there was no parallel anyway.

why do you close issues so fast?

"""can you please seek the proper solution?"""

means that I ask to fix build to have proper dependencies between tests to allow
serial or parallel execution. this will work in any version.

D189: 421_libgcrypt-1.5.0-uscore.patch

D188: 420_libgcrypt-1.6.0-serial-tests.patch

Based on that, you should remove all code from script and replace it with a
message instructing to use the other tool. I do not understand how providing
non-workable code has any value.

I do not want to reopen this... but it is odd. Feel free to ignore.

Thanks!

While it is provided, please make it work. The patch is trivial.

You mean --disable-fd-passing...

Correct it works.

Attached lsof output for the process when does not work.

I don't think it has to do with hardened kernel... as the initial report was
without. I will try to contact the original user.

Attached.

Did not get an email with your comment... just happened to peek.

I am sorry, I forgot to place the link to the bug.

My system:
System uname:
Linux-3.8.6-hardened-x86_64-Intel-R-_Core-TM-_i7-3520M_CPU_@_2.90GHz-with-gentoo-2.2
sys-kernel/linux-headers: 3.7 (virtual/os-headers)
sys-libs/glibc: 2.15-r3
app-shells/bash: 4.2_p45

Attached is my config.log.

At the bug link you will find the user's details.

D174: 375_0001-checks-do-not-access-files-outside-of-build.patch

pkg-config variant.

There is also ncurses-config option...

D172: 374_pinentry-0.8.2-ncurses-pkg-config.patch

D173: 373_pinentry-0.8.2-ncurses.patch

D164: 367_gnupg-2.0.17-gpgsm-gencert.patch

D165: 366_gpgsm-gencert.sh.diff

It works for me too... There are some users, however, that have this issue.

D39: 149_pinentry-0.7.4-grab.patch

The expose event does not work too well either.
http://bugs.gentoo.org/show_bug.cgi?id=201951

D40: 148_pinentry-0.7.4-grab.patch

The revert does not always work.

I don't understand... You succeeded in reproducing this and have an issue with
glibc?
If you do, have you opened some kind of bug report/thread to solve this?

D46: 146_libksba-1.0.2-segfault.patch

I would love to be able to add my-self to CC of issues...

Please echo of you use this bug database, as you ignore this issue for the last
two versions.

glib-2.5
TZ="right/UTC" make check

Still not fixed.

There is also TAI timezone issue.