Created attachment 438060 [details] gzipped build.log This compile error only happens with gnupg-2.0.x alone, 2.1.x is not affected. watchgnupg.c:301:7: error: unknown type name ‘fd_set’ fd_set rfds; ^ watchgnupg.c:308:7: warning: implicit declaration of function ‘FD_ZERO’ [-Wimplicit-function-declaration] FD_ZERO (&rfds); ^ watchgnupg.c:309:7: warning: implicit declaration of function ‘FD_SET’ [-Wimplicit-function-declaration] FD_SET (server, &rfds); ^ watchgnupg.c:319:7: warning: implicit declaration of function ‘select’ [-Wimplicit-function-declaration] if (select (max_fd + 1, &rfds, NULL, NULL, NULL) <= 0) ^ watchgnupg.c:322:7: warning: implicit declaration of function ‘FD_ISSET’ [-Wimplicit-function-declaration] if (FD_ISSET (server, &rfds)) /* New connection. */ ^ watchgnupg.c:333:26: error: ‘FD_SETSIZE’ undeclared (first use in this function) else if (fd >= FD_SETSIZE) ^ watchgnupg.c:333:26: note: each undeclared identifier is reported only once for each function it appears in Makefile:897: recipe for target 'watchgnupg.o' failed
Created attachment 438062 [details, diff] patch from alpine This fixes the compile error. The ebuild has epacht_user, have fun.
(In reply to tt_1 from comment #0) > Created attachment 438060 [details] > gzipped build.log > > This compile error only happens with gnupg-2.0.x alone, 2.1.x is not > affected. > Do we really need this? I've been using 2.1 for a while now.
(In reply to Anthony Basile from comment #2) > (In reply to tt_1 from comment #0) > > Created attachment 438060 [details] > > gzipped build.log > > > > This compile error only happens with gnupg-2.0.x alone, 2.1.x is not > > affected. > > > > Do we really need this? I've been using 2.1 for a while now. 2.0 is EOL in 2017, but still in stable, but is musl profile stable in any case?
(In reply to Kristian Fiskerstrand from comment #3) > (In reply to Anthony Basile from comment #2) > > (In reply to tt_1 from comment #0) > > > Created attachment 438060 [details] > > > gzipped build.log > > > > > > This compile error only happens with gnupg-2.0.x alone, 2.1.x is not > > > affected. > > > > > > > Do we really need this? I've been using 2.1 for a while now. > > 2.0 is EOL in 2017, but still in stable, but is musl profile stable in any > case? It is stable in the sense that it works with KEYWORD=amd64 and not ~amd64 the way say mips does. But its not 100% in tree. There are many patches needed and so there's an overlay. Many upstreams are warming up to musl and so in a few years I think the overlay will be gone. gnupg-2.0 -> 2.1 is an example of the move towards musl friendly pkgs.
Closing this as gnupg-2.1 is stable (or in the process of)