Thank you for your publishing your key of CB6BE1D0D7D1594A.
I applied and pushed your changes.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 12 2021
Apr 9 2021
Thanks. Note, that the same code is in gnupg2 in common/exechelp-posix.c:736
Apr 8 2021
In T5381#144927, @gniibe wrote:For gpgrt_wait_processes, I modified it to skip invalid PID.
The change is: rE956c40f106ea: core: Fix gpgrt_wait_processes, by skipping invalid PID.
For gpgrt_wait_processes, I modified it to skip invalid PID.
The change is: rE956c40f106ea: core: Fix gpgrt_wait_processes, by skipping invalid PID.
Apr 7 2021
Thanks. I understand that this is no big issue in the test code, but half of the code paths have proper cleaning already so fixing it once should save anyone in the future going through the same issues over and over again during our releases or anyone else who would run your code through static analyzer.
Thank you.
For get_attr_l, I pushed a fix as rE89a353f418f5: build: Fix gpgrt-config for handling 'Requires' field.
Apr 6 2021
Actually I don't care about releasing resources for regression test failures.
The other missing free is for code which is commented out (#if 0) but should eventually be fixed.
Apr 1 2021
Fixed in 1.42.
Mar 31 2021
I was wrong in my last comment. Escaping by another \ is needed.
Mar 30 2021
A PATH with spaces is too Windowish (or macOS). IIRC, we had once checks that the used directories have proper names; we can expect this for build environment. Spaces in file names are horrible from a security POV it is just to easy to get things wrong (hello ssh).
@gniibe Note that you also need to at least add the semicolons, as BSD sed is trying to parse "gp}" as substitution flags (which, honestly, makes more forward-compatible sense than GNU sed's behavior...).
Or, if we keep the code of newline (so that it will eventually support path with a space in future):
Thank you. Sorry for the use of GNU sed extension. It could be just a whitespace, if it's OK not to support path having a space.
sed -n -e "/^libraries/{s/libraries: =//;s/:/ /gp}") should work.
@gniibe OK, so... "worst case": I guess this worked? ;P
@gniibe Actually, I just realized that neither of the commands I provided work, as I failed to notice you were trying to also replace :'s with newlines (as I guess libraries from clang can return multiple paths). I'd momentarily edited my comment to just try to add back your colon replacement, before remembering you can't do that either: \n is a GNU sed extension. Hilariously, I'm always in contexts where I can assume I'm using bash (which isn't ok for configure), so I've never bothered to learn a technique that doesn't involve $'\n'... do you have a strategy for doing this replacement? :(
@gniibe Ah yeah, that was the commit I meant to reference when I said "--maybe caused by --", but then forgot to go back and fill in the commit hash ;P.
I wonder if this works in your use case:
diff --git a/m4/gpg-error.m4 b/m4/gpg-error.m4 index d910754e..aeedaf10 100644 --- a/m4/gpg-error.m4 +++ b/m4/gpg-error.m4 @@ -65,7 +65,7 @@ AC_DEFUN([AM_PATH_GPG_ERROR], min_gpg_error_version=ifelse([$1], ,1.33,$1) ok=no
If it is new, it may be the change of this commit rC8e3cd4c4677c: build: Update gpg-error.m4.
(To be clear, I also know enough about autoconf to not have been like, blocked from upgrading by this: overriding ac_cv_path_GPGRT_CONFIG worked, but I can't believe that's the intended way for someone to ensure they get the correct path for gpgrt-config ;P.)
@gniibe The problem is that the check seems to just find gpgrt-config from the path; like, I'm already passing --prefix and --host, but it is deciding to just arbitrarily pick up my system-wide copy of /usr/local/bin/gpgrt-config. Here's my entire configure invocation from that earlier failed build: note that the --prefix is the same as --with-gpg-error-prefix.
We are in transition from old gpg-error-config to new gpgrt-config. <-- This is the cause, while I tried to cover most use cases.
Mar 26 2021
Mar 22 2021
Feb 18 2021
Pushed the change. Please test.
See the comment in rE13918d05a333: Allow building with --disable-threads. for ABI incompatibility.
Feb 17 2021
When building with no threads support, I think that generating same lock-obj-pub-$host.h is just possible by this change.
Feb 16 2021
Tell us the architecture(s) which doesn't support POSIX threads by uClibc.
Adding support for such an architecture would be the best.
Sorry, I was assuming uClibc were not supporting POSIX threads.
Feb 15 2021
Thank you for more information.
I was not the author of the host "hacking" which has been committed to buildroot in 2016 by https://git.buildroot.net/buildroot/commit/package/?id=2f89476ad98b82ea9f914337b0050c4808082c82 so I can't really comment on it.
You can find more information here: https://patchwork.ozlabs.org/project/buildroot/patch/1451762923-15985-1-git-send-email-joerg.krause@embedded.rocks/
Especially, it seems that Jörg Krause started a discussion about this issue and proposed a patch to fix the architecture depends but it was never applied. Unfortunately, I wasn't able to find more information as it seems that links on comments.gmane.org are broken ...
Please note that the result with --host="arm-unknown-linux-gnueabi" for linux-uclibcgnueabih machine is different to the one of correctly generated version by gen-posix-lock-obj.c with USE_POSIX_THREADS undefined on the host.
I found that the use of $CC -print-file-name=crt1.o won't work with some cross compiler.
For example, on my system of Debian bullseye for cross compiler ppc64el, while it's for multiarch configuration, crt1.o is under GNU cross style directory: /usr/powerpc64le-linux-gnu/lib
I would understand your workaorund of using artifical --host intentionally.
This won't work in the context of buildroot as we're passing --host="arm-unknown-linux-gnueabi" to avoid the following build failure:
We also need to support the use case of GNU cross style, like when we build with MinGW toolchain.
For other libraries, like libgcrypt, it is mostly OK with old gpg-error.m4, because those libraries don't depend on new libgpg-error features.
Fixed more in rEd7fd25bbfb83: build: Fix the previous change..
Thank you for the report. I had expected *-*-linux* matches only to GNU/Linux (Linux kernel with GNU C library).
Feb 13 2021
They are mandatory for gnupg but not for Libgcrypt and Libgpg-error. I guess we can fix that.
Feb 12 2021
Because, threads are optional on uclibc as threads are not supported by all embedded targets.
libgpg-error was building perfectly fine without threads until version 1.40 as all pthread calls were protected by USE_POSIX_THREADS.
Should I understand from your answer that threads are now mandatory?
How does it come that you have a Linux kernel without threads? Or maybe the better question is why does libc not support threads?
Considered again, I realized that (1) is no need to check.
Feb 10 2021
Feb 9 2021
POSIX says so (use printf instead).
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html
iirc the advise from the GNU coding standards is to use printf(1) instead of trying to figure out how echo(1) works.
Thank you. I'll fix. Perhaps, I'll ignore old UNIXen like AIX 6.1, which has no way to echo with no newlines.
Jan 5 2021
Dec 21 2020
See T5192 for an updated release.
Nov 16 2020
Nov 15 2020
I know these troubles.
Nov 14 2020
In T3189#117959, @gniibe wrote:Do we need to expose the secmem routines, as a public interface of gpgrt?
I would find it useful. For example I'm making a utility that gets a passphrase with GPGME and gpg-agent, and would like to copy it into a buffer that lives on after closing the context.
Sep 4 2020
Winepath starts calls the full Wine engine just convert file names to DOS format. This is used by libtool but if winepath can't be executed, it doesn't care. So the given solution (using /etc/alternatives/winepath -> /bin/false) can be used.
Aug 25 2020
Aug 24 2020
Release done.
Aug 22 2020
Aug 19 2020
For GNU/Linux, it's done.
Aug 17 2020
Thanks
Aug 15 2020
Here's the patch:
Aug 14 2020
@JW: @gniibe explained you the problem and provided a fix (i.e. use correct specifiction of the directory names). Changes to Makefile.in are a no-go because that is a built file and a real fix would need to go into libtool. However, for a couple of reasons we do not want to update libtool (e.g. too many breakages in the past, we have out own fixes in for Windows). Thus we consider this bug closed.
I understand your point, but your fix is not relevant
Thanks for your patch. I understand your point, but your fix is not relevant (for supporting all platforms). You can use that way in your build script, but we can't take that approach; The correct fix is fixing libtool.
I'm feeling difficulty to talk to you.
@JW, I'm feeling difficulty to talk to you.
... no-support of slash at the end of path and duplicated slash, we won't fix.
T5024: libtool problem for some platforms for 'make check' (program built with -no-install won't work without installation)
For the original problem of no-support of slash at the end of path and duplicated slash, we won't fix.
@JW, I'm afraid you are not able to read what I write here. This is not chat system at all. For chat system, please use XMPP on
gnupg-devel@chat.gnupg.org as written at https://gnupg.org/documentation/mailing-lists.html (if possible).
I wrote that "FAIL: gpg-error-config-test.sh" is because of your typo
I wrote that "FAIL: gpg-error-config-test.sh" is because of your typo, and I asked to fix your typo and test again.
... you are now describing another problem
@JW, you are now describing another problem, instead of the problem you reported.
I'm closing this one.
Aug 10 2020
We currently already ship:
The problem appears to be the test framework is not setting a LD_LIBRARY_PATH (or DYNLD_LIBRARY_PATH on OS X).
As far as I know, the environment is set correctly. PKG_CONFIG_PATH, --prefix and --libdir are set. And runpaths are also set.
I meant:
If you can point me to a commit, I can patch the package and retest it.
If there is no other problem (than the issues of additional slash and double slash), I'll close this bug report.
Aug 5 2020
BTW, I learned that Fedora now uses pkgconfig (instead of pkg-config).
https://github.com/pkgconf/pkgconf