GH Scallywag CI fails - No public key?

Mon Sep 21 09:30:24 GMT 2026

On 2026-09-20 15:28, Brian Inglis via Cygwin-apps wrote:
> On 2026-09-20 09:30, Jon Turney via Cygwin-apps wrote:
>> On 20/09/2026 12:58, Brian Inglis via Cygwin-apps wrote:
>>> Hi folks,
>>>
>>> Not clear why job is failing, unless public key required (hkp:// pgpkeys.eu - 
>>> can we add or prefix this - keyservers seem to be going hkp: rather than 
>>> hkps: which no longer always seems to work)?
>>
>> Hmm.. yeah, this is non-obvious.
>>
>> I think maybe this is failing because the exit status of the last command 
>> src_unpack_hook() ran is non-zero.
>>
>> So maybe it just needs a 'return 0' at the end?
> 
> Most of the hook is tests which should absorb any errexit, it displays the step 
> message, the `mkdir -p` and the final `cp` succeeds, so should make no diff, and 
> on return, it is immediately followed by `cd` which returns 0?
> 
>> (This needs to be more clearly documented and/or reported, though!)
>>
>>> The package includes a python download/install script to retrieve and install 
>>> source test data, so rather than run at build time, in the unpack hook, 
>>> extract the URI and file info from the script JSON params, fetch (from the GH 
>>> pillow repo), unpack, and install the source test data (name with spaces) to 
>>> tests/data directory (under a different name without spaces).
>>
>> I'm curious why spaces are a problem here?
> 
> Just a requirement for quoting as unusual in Unix builds.
> 
>>> Another issue is the tests require using meson, which seems to mess up our 
>>> packaging, and support for which is described in the package as experimental.
>>
>> Doing 'inherit meson' after you've defined src_compile and src_install is 
>> going to redefine them to the default meson version of those.
>>
>> This is why putting inherits at the top of the file is the norm.
> 
> Was hoping to avoid side effects and still add tests, so I have to change to a 
> meson build, and test in playground, until safe.
> 
>>> https://cygwin.com/cgit/cygwin-packages/freetype2/commit/?h=playground
>>>
>>> https://github.com/cygwin/scallywag/actions/runs/35507452467/job/106069562277
>>>
>>>  >>> Preparing freetype2-2.14.3-1.x86_64
>>> *** Info: SOURCE 1 signature follows:
>>> gpg: directory '/home/runneradmin/.gnupg' created
>>> gpg: Signature made Sun, Mar 22, 2026  3:20:00 PM UTC
>>> gpg:                using RSA key E30674707856409FF1948010BE6C3AAC63AD8E3F
>>> gpg: sending fd 7 to keyboxd: Not implemented <GnuPG>
>>> gpg: Can't check signature: No public key
>>> *** Info: SOURCE 2 signature follows:
>>> gpg: Signature made Sun, Mar 22, 2026  3:20:01 PM UTC
>>> gpg:                using RSA key E30674707856409FF1948010BE6C3AAC63AD8E3F
>>> gpg: sending fd 7 to keyboxd: Not implemented <GnuPG>
>>> gpg: Can't check signature: No public key
>>> *** Info: SOURCE 3 signature follows:
>>> gpg: Signature made Sun, Mar 22, 2026  3:20:00 PM UTC
>>> gpg:                using RSA key E30674707856409FF1948010BE6C3AAC63AD8E3F
>>> gpg: sending fd 7 to keyboxd: Not implemented <GnuPG>
>>> gpg: Can't check signature: No public key
>>
>> I'm kind of perplexed by this.
>>
>> If .sig files are listed in the SRC_URI and gpg is available, they will by 
>> checked.
>>
>> But I don't see any sign that our gnupg package is installed, so I'm not sure 
>> what's going on there.

$ which -a gpg gpg2
/usr/bin/gpg
/proc/cygdrive/c/Program Files/GnuPG/bin/gpg
/usr/bin/gpg2

In my case /proc/cygdrive/c/Program Files/GnuPG/bin/gpgconf -X confirms this is 
actually a GPG4Win install I did to keep Thunderbird and other Windows 
encryption up to date.

It appears gnupg2 is installed by Scallywag cygwin-install-action or a 
dependency (lib/GpgME?):

	install gnupg2			2.5.22-1

but always use gpg2/gpgv2 commands to avoid path aliasing just in case:

$ llgo /bin/gpg*2
lrwxrwxrwx 1 3 Sep 10 02:39 /bin/gpg2 -> gpg*
lrwxrwxrwx 1 4 Sep 10 02:39 /bin/gpgv2 -> gpgv*

and I have no idea what the default conf may be, or where it comes from?

> It must be as it prompts and complains: can't access keyserver(s) (firewall?), 
> or none configured by default?
> Where does keyboxd come in?
> 
> Oops - I am seeing:
> 
> $ which -a keyboxd
> /proc/cygdrive/c/Program Files/GnuPG/bin/keyboxd
> $ cygcheck -p keyboxd
> Found 6 matches for keyboxd
> gnupg2-debuginfo-2.5.20-1 - gnupg2-debuginfo: Debug info for gnupg2
> gnupg2-debuginfo-2.5.21-1 - gnupg2-debuginfo: Debug info for gnupg2
> gnupg2-debuginfo-2.5.22-1 - gnupg2-debuginfo: Debug info for gnupg2
> gnupg2-2.5.20-1 - gnupg2: GNU tool for secure communication and data storage
> gnupg2-2.5.21-1 - gnupg2: GNU tool for secure communication and data storage
> gnupg2-2.5.22-1 - gnupg2: GNU tool for secure communication and data storage
> $ l /usr/libexec/keyboxd
> /usr/libexec/keyboxd*
> 
> I changed all my keyservers in .gnupg gpg.conf and dirmngr.conf from hkps to hkp 
> as they were not working with the suffix, then --receive-keys worked again.

Does not seem to be an issue - both hkp{,s}:// seem to work okay!

>> Probably the answer to your original question about what to do about the 
>> public key is to define some mechanism for cygport to read it from somwhere... 
>> but I'm not sure if that should be in the package repository or in a bundle 
>> that cygport installs?
> 
> SCALLYWAG or Cygport prep env var?
> 
>> (and we ought to make the use of signatures mandatory for supply-chain 
>> security reasons, but SHTDI...)
> 
> Just related, not seeing (dateutils) ...tar.asc used to check ...tar.xz - does 
> it need to be a suffix to the compressed file to check that, and uncompressed 
> independent of compression not supported, although PTC? ;^>
-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher  but when there is no more to cut
                                 -- Antoine de Saint-Exupéry