GH Scallywag CI fails - No public key?

[Brian Inglis]

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.

It must be as it prompts and complains: can't access keyserver(s) (firewall?), 
or none configured by default?
Where does keyboxd com 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.

> 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, but SHTDI? ;^>

-- 
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