jenkins build all please

Now I run consistently into the same problem as in #1973 . For some reason gpg returns with exit code 512 but the other tests suceed indicating, that the import was successful nevertheless.

I have a few ideas that we could still try:

• Did you manage to get any useful debugging output?
• Try another key?
• start gpg-agent explicitly maybe that gives any logging output
• if stderr does not give output, maybe add --logger-fd to write to a file
• time problems? I am not sure the time is properly set time is set to host OS without TZ
• try to import the key directly via jenkinsfile command, maybe that produces something loggable

no output on stderr really does not help...

another thing i noticed while trying through steps that might fail is that gpg will throw a warning regarding directory permissions when using GNUPGHOME on a random directory. But no error code is set.

//EDIT: and I only tried with the test_key.asc directly, not the hexdump in test_key.h
//EDIT2: tried manually setting GNUPGHOME and it worked as expected. still not closer to why gpg returns that error code on the test server.

So still no progress here?

So still no progress here?

I too have no progress so far on this issue. 😞

I just had something fun happen in https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2003/97/pipeline/326.

gpg tests randomly failed. replayed the test and it passed.

maybe trying to solve the gpg-agent issue is just exposing something wonky in the gpg interaction?

maybe trying to solve the gpg-agent issue is just exposing something wonky in the gpg interaction?

I will play around with the gpg module to find out more.

I know it would be a lot of work but have you considered replacing gpg exe manipulation with https://www.gnupg.org/software/gpgme/index.html?

Yes, I already had a discussion with @markus2330 . Personally I would prefer to use gpgme. But it would take a lot of work to replace the current gpg module.

Maybe writing a "hello world" testcase with gpgme would be a good start. Then we see if gpgme actually solves this problem. gpgme seems to work very similar to @petermax2's code.

gpgme seems to work very similar to @petermax2's code.

gpgme uses a lot more abstraction layers than my code 😆 LibAssuan handles the inter process communication but I did not have an in-depth look into its code so far.

I will try to advance my progress on the gpgme plugin prototype. Then we see if we encounter similar quirks on the build server.

@petermax2 I am not sure you followed #2056 but as you can see there the files for gpg-agent have changed and thus are not getting cleaned up anymore.

Changing the gpg module to cleanup itself is probably overkill as the c testframework should handle it and is just outdated.

Additionally I am sure you might have noticed that ftw is not 100% what you want here as it does return directories before the nested files (and directories). Hence the rmdir call will not be executed.
This will probably stop gpg-agents because their socket files are removed, but the directories are not cleaned up completely.

I am not sure you followed #2056 but as you can see there the files for gpg-agent have changed and thus are not getting cleaned up anymore.

I did.

Changing the gpg module to cleanup itself is probably overkill

It is also not acceptable for a regular user session. I do not want my gpg-agent to stop after using Elektra. Especially if my agent was running before, I would be surprised if it is closed after using Elektra.

Additionally I am sure you might have noticed that

Actually I did some sort of dirty hack by invoking it three times. The first one deletes all files, the scond one the sub directories and the third one the root directory.

+static void clean_env (void)
+{
+	if (gpg_dir)
+	{
+		// 1. delete files
+		ftw (gpg_dir, delete_dir_content, 50);
+		// 2. delete sub-directories
+		ftw (gpg_dir, delete_dir_content, 50);
+		// 3. delete root directory (GNUPGHOME)
+		ftw (gpg_dir, delete_dir_content, 50);
+		free (gpg_dir);
+	}

EDIT: I do appreciate every input about how to make this code less hacky.