t-link does not do antthing useful, anyway. I don't think it is justified to add dlopen stuff. Running real test is anyway a manual action; for a full test automation we would need to emulate all supported cards.

the t-link test should dlopen scute.so in runtime rather than link against it in build-time.

As of slibtool commit 9c5ba5eb, scute now builds out of the box. I'd still recommend taking the above into consideration, though.

For what it's worth, scute is in violation of gnu libtool's documentation. Building with gnu libtool:

In T5394#145082, @werner wrote:

Regarding slibtool: I would actually like to have an easier to maintain tool than libtool (of which we use our own version) for GnuPG related software. However, its requirement "the compiler should support -std=c99" is currently a no-starter for libgcrypt and some other libs.

Regarding your patch, I am personally not opposed to it, but apparently Debian’s policy says the library/module should be called scute while Gentoo’s policy says it should be called libscute… What should an upstream developer do?

Regarding slibtool: I would actually like to have an easier to maintain tool than libtool (of which we use our own version) for GnuPG related software. However, its requirement "the compiler should support -std=c99" is currently a no-starter for libgcrypt and some other libs.

Looks good to me: "make && make check" passes.

FWIW, in GnuPG we use

It should be fixed with 49ad2b0e05e3fcb8c8c2e23bb1c6063b390dee02, though I don’t have a gcc-10 to check. It does work with gcc-9.3 with -fno-common.

It's OK not supporting generation in PostScript format.
Thus, we can remove image_eps support.
Then, convert is not required any more.

Fixed with commit 4d95b7457d62bf785a2157bb2cfa002bde7ff8f5. It turned out the test the convert was already there, but its result was not used to decide whether to build the doc or not.

I agree about checking for convert (but maybe just skip building the doc instead of aborting everything if convert cannot be found).

I could not reproduce such a failure either under any conditions.

In my debian buster pbuilder enviornment I got the following failure when packaging master (beta195):

With the build problem on Mac OS now fixed with d551cf9, barring any last minute issue I plan to do the actual release by the end of the day tomorrow (10 September).

If I understand correctly, the problem stems from the -module flag added to the LDFLAGS in commit dc2211179. It's that flag that instruct libtool to create a bundle (.so file) instead of a dynamically linked shared library (.dylib file). But that flag is needed to force automake to accept that the library is to be named scute instead of libscute (without that flag automake errors out, complaining that scute.la is not a standard libtool library name).

Given that 1.5 already had that problem, I would suggest to ignore that bug for the 1.6 release. We can work on that later.

I just checked that Scute builds cleanly on Slackware, Debian, and in a cross-compilation setup against Mingw32.

"gouttegd (Damien Goutte-Gattat)" <noreply@dev.gnupg.org> writes:

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.

When the tests are run, Scute now contacts the agent intended for the tests instead of any agent running on behalf of the Jenkins user. And so the tests pass or skip appropriately.

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

I see several problems here:

All build artifacts are accessible, e.g.: https://jenkins.gnupg.org/job/scute/ws/XTARGET/native/obj/tests/test-suite.log

OK, I pushed my fix into master.

The canonical repo is git://git.gnupg.org . We have not yet mirrored it at dev.gnupg.org.

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?

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

Justus, please apply the patches.

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.