Oct 21 2014
Aug 10 2014
Aug 9 2014
Jan 29 2014
A user shall not use automake to build libgrypt.
I am very well aware of all the problems with newer automake versions. I try to
eventually mitigate the problems and the extra rules we have in some projects
might be helpful but a proper solution for automake would be to reverse the
default tests method to serial-tests. There are only a few projects with lots
of regression tests which benefit from the new default - those could easily
switch on parallel-tests. But I have seen no signs that they will revert it.
Eventually we need to add our own test driver - IIRC, recent automakes allow to
enable a custom test driver while still having build support by automake.
the tarball is OK, however, we must patch the autoconf, 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...
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.
I am confused:
Do you say that you have problems to build the tarball release? In that case I
can replicate the problem. FWIW, the 1.6.1 release has been build with automake
1.11 and I am pretty sure that this was also the case for 1.6.0.
From the top Makefile.in:
Makefile.in generated by automake 1.11.6 from Makefile.am.
So, why do you need autoreconf to fix a problem with parallel tests? automake
1.11 does not generate such test rules.
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.
That was added because we have it in master.
Again: If you do not use the tarball release do not expect that pacthes will be
included. You should never do autoreconf.
Jan 28 2014
We patch your sources mainly because, I will be happy to stop autoreconf your
packages, but cannot do this until this and other issues are resolved.
OK, someone already tried to solve it at your side:
- 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
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
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.
Because that automake version is not supported. automake is a maintainer tool
and not a build dependency. If Gentoo has its own policy they are on their own
- it is free software. The tarball release does not have this problem. Or am I
wrong? GIT is developer only and definitely not a release.
Jan 27 2014
Please report a concrete bug. Due to the often instable libtool developemnt, I
hestitate to change tests which have shown to work on a wide variety of
platforms. Note that we also don't use any new version of libtool but stick to
an old and stable one with our own fixes.
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.
Thist patch does not work because the serial-tests flag is not supported by
older automake versions. The problem has already been discussed at the mailing
lists. See README.GIT on how to use a non-broken automake. I still hope the
utomake folks solve the problem by changing the default. Forcing all projects
to use the new and incompatible parallel tests was a very unpleasant behaviour
Jan 24 2014
Oct 24 2013
Sep 18 2013
Duplicate of T1535
That is a GnuPG. See T1535.
I just pushed a fix to the 2.0 branch.
Aug 19 2013
Fix will go into 2.0.21. Thanks.
May 28 2013
See also T1502
May 22 2013
The lsof looks as expected.
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.
Thanks. GPGME is waiting for an EOF on the fd used to receive data from gpgsm.
The data is send by the GETAUDITLOG command and afaics all data has been
received. There is a one second timeout in the select which you can see at the
end of the log file.
File descriptor passing is used between gpgme and gpgsm which usually works
nice. We have an problem on Mac OS with that for yet unknown reasons. lsof
might give some insight here. I suggest to configure gpgme with
--disable-fd-logging ro check whether this is really the culprit.
What are the special features of the hardened gentoo kernel?
Thanks. Can you please cd to the build directory gpgme/tests/gpgsm and run
this on the command line (after having canceled the make check):
GPGME_DEBUG=9:/tmp/gpgme.log GNUPGHOME=$(pwd) GPG_AGENT_INFO= ./t-verify
and post the gpgme.log file?
May 15 2013
Actually, gpg should not open the keyfiles at all. Well, unless you have enabled
the SELinux hacks. In that case we better register the keyfiles. The fix seems
to be harmless and thus it makes sense to apply it.
May 13 2013
Did not get an email with your comment... just happened to peek.
I am sorry, I forgot to place the link to the bug.
sys-kernel/linux-headers: 3.7 (virtual/os-headers)
Attached is my config.log.
At the bug link you will find the user's details.
May 6 2013
Please provide complete bug reports. Foe example the OS you are using.
May 5 2013
There is also ncurses-config option...
Jan 13 2013
Aug 14 2012
Marked as resolved in Gentoo.
Jun 29 2011
Feb 21 2011
The compiler folks are breaking all assumptions C hackers used for decades :-(
The benefit is a little performace improvement which might be outweighted by the
bugs introduced due to the code changes required to to use gcc specific stuff or
even memcpy everything forth and back.
Dec 8 2010
Dec 7 2010
Dec 11 2009
will be in 1.4.5 to be released in a few minutes.
Dec 10 2009
Okay, for the development version I implemented a configure option
This is in the SVN trunk, rev 1415.
I believe that is the least intrusive change. Is it important for you; thus
shall I backport it to 1.4.5 which will be released in a few days?
Jul 9 2009
not a bug or - if at all - a bug in glibc. Further discussion please on the ML
Jun 19 2009
That is no bug but required by the Assuan protocol:
Jun 18 2009
Feb 3 2009
Is it possible to match at most one occurrence of a pattern without the "-r"
option? ("extended regular expression", a GNU extension unfortunately)
Sure, you are right. OTOH this code is in use by gnupg and libgcrypt for many
years without problems (twofish.c used similar code).
Feb 2 2009
Hmm - I can't explain why this would have affected 1.4.4 but not 1.4.3, but that
is my experience.
I don't think that it is a regression in Libgcrypt because the problematic rule
was not changed. Did you change the CFLAGS passed to configure?