Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko)
On 2022-11-04 08:34, Jon Turney wrote: The second is not so clear: A package is orphaned if it's maintainer is not responsive to queries as to if they still want to be the maintainer of the package. It's undefined how many times we should ping, or how long we should wait for a response, but I think that the ~10 months that's elapsed here is more than enough! If the prospective adopter is also proposing an update that addresses security vulnerabilities in the old package, I suggest that that, and the severity and impact of those vulnerabilities be factored into the timeout decision. -- -Chad
Re: [ITA] lz4
On 2022-10-30 10:26, Jon Turney wrote: Looks like 'doc/lz4_manual.html' is created in the source directory by the build. That should be listed in DIFF_EXCLUDES, and maybe installed to be included in the devel package? Good catch. Done. You should 'git rm' the patches which are no longer used. Done. I added these to your authorized packages. Thanks! Awesome, thanks! -- -Chad
Re: [ITP] rsync 3.2.6
On 2022-10-09 10:23, Jon Turney wrote: Thanks for looking into updating this. I'd like to give the existing maintainer first refusal, though. Any new thoughts on this? There was a new upstream release, rsync-3.2.7, and I've updated my cygport and its associated artifacts: https://github.com/crd477/cygports/tree/main/rsync # Enable this function for releases that work without autoreconf src_compile() You should only override the default src_compile if it doesn't work. The fact that autoreconf isn't apparently necessary, doesn't mean it should be omitted, since that means that future fixes to the autoconfiguration machinery aren't automatically incorporated into the package, but will only appear when upstream updates the autotools used to generate the distributed autoconfiguration files. OK, got it. My current cygport no longer skips the cygautoreconf step. Thanks... -- -Chad
Re: [ITP] passwdqc 2.0.2
On 2022-10-23 15:41, Adam Dinwoodie wrote: Ah! Error on my part: I hadn't realised how `man` handles redirects. You're quite right, this is all good! It looks like I don't have permission to commit this to the cygwin-packages repository. Do I need additional approvals? Likewise for the lz4 updates. Thanks! -- -Chad
xxhash packages update
I've updated the cygport to the current upstream release version, 0.8.1: https://github.com/crd477/xxhash-cygport This version also fixes a minor problem with the existing libxxhash-devel package - the import lib is incorrectly installed as a copy of the dll. Thanks... -- -Chad
Re: [ITA] lz4
On 2022-10-23 13:31, Adam Dinwoodie wrote: On Sat, 22 Oct 2022 at 21:59, Chad Dougherty wrote: I'd like to adopt the lz4 library that is currently listed as orphaned. I've updated the cygport to the current version, 1.9.4: https://github.com/crd477/lz4-cygport I've not tested the actual compilation, but I have done some test builds, and this all looks good to me! Great! Is it acceptable for me to put these updates into the cygwin git repository? Once you're listed as a maintainer, yes; up until then, you won't have permission to write to that repository. I see. I didn't appreciate that maintainership was also factored into the authorization process but it makes sense. Jon mentioned this in the passwdqc thread as well. Also, is it expected that I should also take the mingw64-{i686,x86_64}-lz4 packages too? AIUI that's preferred but not required; they're separate packages, so it's entirely possible for them to have separate maintainers. OK, I updated them here: https://github.com/crd477/mingw64-x86_64-lz4-cygport https://github.com/crd477/mingw64-i686-lz4-cygport I've had less experience with cross-compiling but I think they're correct nevertheless. Thanks, and take care... -- -Chad
Re: [ITP] passwdqc 2.0.2
On 2022-10-23 15:19, Adam Dinwoodie wrote: On Sun, 23 Oct 2022 at 20:13, Chad Dougherty wrote: I can't reproduce this and they all look OK in my local environment. By any chance do you have a pointer to a public artifact where it occurs? To be sure, these man pages should be identical for each passwdqc function but they should not be empty. You can see it in the packaged files from your build, at https://github.com/crd477/passwdqc-cygport/raw/main/passwdqc-2.0.2-1.x86_64/dist/passwdqc/libpasswdqc-devel/libpasswdqc-devel-2.0.2-1.tar.xz Weird, they look OK to me: $ tar -atpvf ./passwdqc-2.0.2-1.x86_64/dist/passwdqc/libpasswdqc-devel/libpasswdqc-devel-2.0.2-1.tar.xz -rw-r--r-- crd/None 1958 2022-10-23 14:57 usr/include/passwdqc.h -rwxr-xr-x crd/None 12768 2022-10-23 14:57 usr/lib/libpasswdqc.dll.a -rw-r--r-- crd/None 2196 2022-10-23 14:57 usr/share/man/man3/libpasswdqc.3.gz -rw-r--r-- crd/None 60 2022-10-23 14:57 usr/share/man/man3/passwdqc_check.3.gz -rw-r--r-- crd/None 66 2022-10-23 14:57 usr/share/man/man3/passwdqc_params_free.3.gz -rw-r--r-- crd/None 66 2022-10-23 14:57 usr/share/man/man3/passwdqc_params_load.3.gz -rw-r--r-- crd/None 67 2022-10-23 14:57 usr/share/man/man3/passwdqc_params_parse.3.gz -rw-r--r-- crd/None 67 2022-10-23 14:57 usr/share/man/man3/passwdqc_params_reset.3.gz -rw-r--r-- crd/None 61 2022-10-23 14:57 usr/share/man/man3/passwdqc_random.3.gz $ curl -OL https://github.com/crd477/passwdqc-cygport/raw/main/passwdqc-2.0.2-1.x86_64/dist/passwdqc/libpasswdqc-devel/libpasswdqc-devel-2.0.2-1.tar.xz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 4392 100 43920 0 11098 0 --:--:-- --:--:-- --:--:-- 11098 $ tar -atpvf ./libpasswdqc-devel-2.0.2-1.tar.xz -rw-r--r-- crd/None 1958 2022-10-23 14:57 usr/include/passwdqc.h -rwxr-xr-x crd/None 12768 2022-10-23 14:57 usr/lib/libpasswdqc.dll.a -rw-r--r-- crd/None 2196 2022-10-23 14:57 usr/share/man/man3/libpasswdqc.3.gz -rw-r--r-- crd/None 60 2022-10-23 14:57 usr/share/man/man3/passwdqc_check.3.gz -rw-r--r-- crd/None 66 2022-10-23 14:57 usr/share/man/man3/passwdqc_params_free.3.gz -rw-r--r-- crd/None 66 2022-10-23 14:57 usr/share/man/man3/passwdqc_params_load.3.gz -rw-r--r-- crd/None 67 2022-10-23 14:57 usr/share/man/man3/passwdqc_params_parse.3.gz -rw-r--r-- crd/None 67 2022-10-23 14:57 usr/share/man/man3/passwdqc_params_reset.3.gz -rw-r--r-- crd/None 61 2022-10-23 14:57 usr/share/man/man3/passwdqc_random.3.gz And this matches what I got when I extracted them into the root directory on my system: $ ls -lart /usr/share/man/man3/*passwdq* -rw-r--r-- 1 root None 61 Oct 23 14:57 /usr/share/man/man3/passwdqc_random.3.gz -rw-r--r-- 1 root None 67 Oct 23 14:57 /usr/share/man/man3/passwdqc_params_reset.3.gz -rw-r--r-- 1 root None 67 Oct 23 14:57 /usr/share/man/man3/passwdqc_params_parse.3.gz -rw-r--r-- 1 root None 66 Oct 23 14:57 /usr/share/man/man3/passwdqc_params_load.3.gz -rw-r--r-- 1 root None 66 Oct 23 14:57 /usr/share/man/man3/passwdqc_params_free.3.gz -rw-r--r-- 1 root None 60 Oct 23 14:57 /usr/share/man/man3/passwdqc_check.3.gz -rw-r--r-- 1 root None 2196 Oct 23 14:57 /usr/share/man/man3/libpasswdqc.3.gz -- -Chad
Re: [ITP] passwdqc 2.0.2
On 2022-10-23 13:42, Adam Dinwoodie wrote: .hint and .cygport files are attached and can also be found here along with built packages: https://github.com/crd477/passwdqc-cygport Mostly looks good to me, but I think there are a couple of errors: - etc/passwdqc.conf and usr/share/man/man5/passwdqc.conf.5.gz look to me like they belong in the libpasswdqc0 package Ah, you're right. Good catch. Fixed in the working repo I mentioned above. - The usr/share/man/man3/passwdqc_* man pages are all empty I can't reproduce this and they all look OK in my local environment. By any chance do you have a pointer to a public artifact where it occurs? To be sure, these man pages should be identical for each passwdqc function but they should not be empty. Thanks for reviewing this. I really appreciate it, especially while I'm still getting familiar with this process. -- -Chad
[ITA] lz4
I'd like to adopt the lz4 library that is currently listed as orphaned. I've updated the cygport to the current version, 1.9.4: https://github.com/crd477/lz4-cygport Is it acceptable for me to put these updates into the cygwin git repository? Also, is it expected that I should also take the mingw64-{i686,x86_64}-lz4 packages too? Thanks... -- -Chad
[ITP] passwdqc 2.0.2
Hello, I'm interested in becoming a package maintainer for passwdqc: https://www.openwall.com/passwdqc/ It is a password/passphrase strength checking and policy enforcement toolset, including command-line programs (pwqcheck, pwqfilter, and pwqgen), and a library (libpasswdqc). Its primary author, Solar Designer, is a renowned authority on password security, having also created the famous John the Ripper password cracking tool and multiple widely used password hashing implementations. The PAM support is not involved in this Cygwin package but I personally find the utilities quite useful in their own right and have been using them under Cygwin for some time. This would be a new package for Cygwin but is already packaged in other distributions: https://packages.fedoraproject.org/pkgs/passwdqc/passwdqc/ https://packages.debian.org/search?keywords=passwdqc https://software.opensuse.org/package/passwdqc https://pkgs.org/download/passwdqc https://formulae.brew.sh/formula/passwdqc It is released under essentially the ISC license. The current release can be downloaded from: https://www.openwall.com/passwdqc/passwdqc-2.0.2.tar.gz https://www.openwall.com/passwdqc/passwdqc-2.0.2.tar.gz.sign (PGP signature) It can be compiled on Cygwin with only minor patches to the Makefile. .hint and .cygport files are attached and can also be found here along with built packages: https://github.com/crd477/passwdqc-cygport Now that I have access, I can also put these into the cygwin git repository, I just wasn't sure if it was acceptable to do so before sending the ITP message. Thanks, and take care... -- -Chad# XXXCRD: this is not finished yet! # we still need to account for the fact that it should generate multiple # packages, lib, -devel, main NAME="passwdqc" VERSION=2.0.2 RELEASE=1 CATEGORY="Security" SUMMARY="password/passphrase strength checking and enforcement toolset" DESCRIPTION="passwdqc is a password/passphrase strength checking and policy enforcement toolset, including command-line programs (pwqcheck, pwqfilter, and pwqgen), and a library (libpasswdqc). pwqcheck and pwqgen are standalone password/passphrase strength checking and random passphrase generator programs, respectively, which are usable from scripts. The pwqfilter program searches, creates, or updates binary passphrase filter files, which can also be used with pwqcheck. libpasswdqc is the underlying library, which can also be used from third-party programs." HOMEPAGE="https://www.openwall.com/passwdqc/; SRC_URI="https://www.openwall.com/passwdqc/passwdqc-2.0.2.tar.gz https://www.openwall.com/passwdqc/passwdqc-2.0.2.tar.gz.sign; LICENSE=BSD-3-Clause LICENSE_SPDX="SPDX-License-Identifier: BSD-3-Clause" LICENSE_URI=LICENSE PKG_NAMES="${NAME} lib${NAME}0 lib${NAME}-devel" passwdqc_CONTENTS=" usr/bin/pwq*.exe usr/share/doc/passwdqc/ usr/share/man/man1/* " libpasswdqc0_CATEGORY="Libs" libpasswdqc0_SUMMARY="password/passphrase strength checking and enforcement library" libpasswdqc0_CONTENTS=" usr/bin/cygpasswdqc-0.dll " libpasswdqc_devel_CATEGORY="Libs" libpasswdqc_devel_SUMMARY=${libpasswdqc0_SUMMARY} libpasswdqc_devel_CONTENTS=" etc/passwdqc.conf usr/include/*.h usr/lib/libpasswdqc.dll.a usr/share/man/man3/* usr/share/man/man5/* " src_compile() { lndirs cd $B cygmake utils } src_install() { cd $B cygmake DESTDIR=$D install_lib install_utils dodoc CHANGES INTERNALS LICENSE README } category: Security requires: cygwin libpasswdqc0 sdesc: "password/passphrase strength checking and enforcement toolset" ldesc: "passwdqc is a password/passphrase strength checking and policy enforcement toolset, including command-line programs (pwqcheck, pwqfilter, and pwqgen), and a library (libpasswdqc). pwqcheck and pwqgen are standalone password/passphrase strength checking and random passphrase generator programs, respectively, which are usable from scripts. The pwqfilter program searches, creates, or updates binary passphrase filter files, which can also be used with pwqcheck. libpasswdqc is the underlying library, which can also be used from third-party programs." category: Security build-depends: cygport sdesc: "password/passphrase strength checking and enforcement toolset" ldesc: "passwdqc is a password/passphrase strength checking and policy enforcement toolset, including command-line programs (pwqcheck, pwqfilter, and pwqgen), and a library (libpasswdqc). pwqcheck and pwqgen are standalone password/passphrase strength checking and random passphrase generator programs, respectively, which are usable from scripts. The pwqfilter program searches, creates, or updates binary passphrase filter files, which can also be used with pwqcheck. libpasswdqc is the underlying library, which can also be used from third-party programs." skip: homepage: https://www.openwall.com/passwdqc/ license: BSD-3-Clause category: Libs requires: cygwin sdesc: "password/passphrase strength
SSH public key
Name: Chad Dougherty BEGIN SSH2 PUBLIC KEY C3NzaC1lZDI1NTE5INJ3RlnS9WnMOyn6+dnPyktOriBh5a0V3yOlitsGUs+w END SSH2 PUBLIC KEY
Re: [ITP] rsync 3.2.6
On 2022-10-09 10:23, Jon Turney wrote: > Thanks for looking into updating this. I'd like to give the existing > maintainer first refusal, though. > Absolutely. It's totally OK with me if Jari would rather still maintain this. I just figured I'd try my hand at the process in the meantime, particularly since it was using the old build method. Comments on this cygport: REQUIRES="libiconv2 libssl1.1 libxxhash0 libzstd1 liblz4_1" You don't (and in fact, shouldn't, because you then need to remember to manually update them e.g. when soversions change) list here packages that cygport can automatically detect as dependencies. I see, thanks. Fixed in my working repo here: https://github.com/crd477/cygports/tree/main/rsync # Enable this function for releases that work without autoreconf src_compile() You should only override the default src_compile if it doesn't work. The fact that autoreconf isn't apparently necessary, doesn't mean it should be omitted, since that means that future fixes to the autoconfiguration machinery aren't automatically incorporated into the package, but will only appear when upstream updates the autotools used to generate the distributed autoconfiguration files. I see. I tried but the default src_compile() didn't work. According to the INSTALL file, the autoconf should only be done on a git checkout, not the release tarball. The specific comment in the cygport file was actually a holdover from one I was using as an example so I've clarified it. (I think this topic is touched upon in the cygport reference manual in the section on cygautoreconf, but perhaps that could be clearer) I actually hadn't read that section yet. The warning in the reference manual is pretty clear now that I see it though. Might it be a good idea to issue a warning diagnostic at src_compile time if cygautoreconf is skipped but it looks like the source code should be able to handle it? Comparing the contents of the packages this produced with the current package, there are various /usr/share/doc/rsync/*.{html,txt} files which are no longer packaged. Is this intentional? It was not really intentional. The only reason they were left out is that they weren't part of the default install rule. I've also addressed this in the working repo mentioned above. Thanks for taking the time to review this. I really appreciate it. rsync is an important tool so I'm a little anxious about screwing it up for some other user of the package. -- -Chad
Re: [ITP] minisign 0.10
On 2022-10-09 11:09, Chad Dougherty wrote: In the case of minisign, it uses CMake and needed to invoke cygcmake, that's why I left src_compile() there. Is that wrong? It didn't compile with that commented out even though I inherit cmake. Err, disregard this. I failed to understand CYGCMAKE_GENERATOR. Fixed in my working repo: https://github.com/crd477/cygports/tree/main/minisign -- -Chad
Re: [ITP] minisign 0.10
On 2022-10-09 10:33, Jon Turney wrote: Thanks. I think I'd like to be using minisign to sign setup.ini for Cygwin's setup, rather than the accident waiting to happen which is libgpg, but that's a whole other project... I admit that was an ulterior motive but I also recognize there's a whole lot more to it :) I've used minisign to verify a few other things and I thought it would be another good exercise for me to get my feet wet on the packaging process. Comments I made about rsync.cygport on REQUIRES and src_compile() also apply here. Ah, I think I understand better now. I'll address the rsync update soon. In the case of minisign, it uses CMake and needed to invoke cygcmake, that's why I left src_compile() there. Is that wrong? It didn't compile with that commented out even though I inherit cmake. src_install() { cd ${B} cyginstall } I think this is the same as the default src_install, so can be omitted? Yep. -- -Chad
[ITP] minisign 0.10
Hello, I'm interested in becoming a package maintainer for minisign: https://jedisct1.github.io/minisign/ I suspect the mailing list was blocking my original announcement about this so I have put all of the relevant information in the README here: https://github.com/crd477/cygports/blob/main/minisign/README.md Thanks, and take care... -- -Chad
Re: [ITP] rsync 3.2.6
On 2022-10-06 13:24, Adam Dinwoodie wrote: "no iconv" concerns me; I'm not desperately familiar with how iconv works, but I believe that'll potentially cause issues for rsync users who aren't using ASCII. I'd guess the issue is your build environment is missing a relevant build-time dependency, probably libiconv or libiconv-devel. Yeah, come to think of it that one also stuck out to me after I sent the mail. I've updated my cygport and associated artifacts to include those dependencies: https://github.com/crd477/cygports/tree/main/rsync Here's an update diff of the features and capabilities, reformatted and sorted for easier comparison: crd@x13:~/src/cygports/rsync$ diff -b old.txt new.txt 1,2c1,2 < rsync version 3.2.4dev protocol version 31 < Copyright (C) 1996-2020 by Andrew Tridgell, Wayne Davison, and others. --- > rsync version 3.2.6 protocol version 31 > Copyright (C) 1996-2022 by Andrew Tridgell, Wayne Davison, and others. 13a14,15 > crtimes > hardlink-symlinks 17d18 < no crtimes 19c20 < optional protect-args --- > optional secluded-args 27,28c28,30 < no SIMD < asm --- > no SIMD-roll > no asm-MD5 > no asm-roll I think the diffs after "19c20" above should be safe to ignore as the release notes explain them: " - Renamed configure's `--enable-simd` option to `--enable-roll-simd` and added the option `--enable-roll-asm` to use the new asm version of the code. Both are x86_64/amd64 only. - Renamed configure's `--enable-asm` option to `--enable-md5-asm` to avoid confusion with the asm option for the rolling checksum. It is also honored even when openssl crypto is in use. This allows: normal MD4 & MD5, normal MD4 + asm MD5, openssl MD4 & MD5, or openssl MD4 + asm MD5 depending on the configure options selected. - Made SIMD & asm configure checks default to "no" on non-Linux hosts due to various reports of problems on NetBSD & macOS hosts. These were also tweaked to allow enabling the feature on a host_cpu of amd64 (was only allowed on x86_64 before)." Thanks... -- -Chad
[ITP] rsync 3.2.6
Hello all, I've been using cygwin for a long time but this is my first attempt at this process so please be gentle :) I noticed that the current rsync package (3.2.3+20200903+git9f9240b-4) is trailing on security updates and also still using the g-b-s method. I pinged the listed maintainer directly last week asking if they were planning to do any updates but have not heard back. I hope this was not a faux pas as I didn't read until later that it's best to raise the issue on the list first. I've attempted to update the port here: https://github.com/crd477/cygports/tree/main/rsync The package files were built by doing: cygport rsync.cygport prep compile test install package-test cygport test reported the following: ... /home/crd/rsync-3.2.6-1.x86_64/src/rsync-3.2.6/runtests.sh running in /home/crd/rsync-3.2.6-1.x86_64/build rsync_bin=/home/crd/rsync-3.2.6-1.x86_64/build/rsync.exe srcdir=/home/crd/rsync-3.2.6-1.x86_64/src/rsync-3.2.6 TLS_ARGS= -l -L testuser=crd os=CYGWIN_NT-10.0-22000 x13 3.3.6-341.x86_64 2022-09-05 11:15 UTC x86_64 Cygwin preserve_scratch=no scratchbase=/home/crd/rsync-3.2.6-1.x86_64/build/testtmp PASS00-hello SKIPacls-default (Your filesystem has ACLs disabled) SKIPacls (Your filesystem has ACLs disabled) PASSalt-dest PASSatimes PASSbackup PASSbatch-mode PASSchgrp PASSchmod-option SKIPchmod-temp-dir (Can't find a tmp dir on a different file system) PASSchmod SKIPchown-fake (Can't chown (probably need root)) SKIPchown (Can't chown (probably need root)) PASScrtimes PASSdaemon-gzip-download PASSdaemon-gzip-upload PASSdaemon PASSdelay-updates PASSdelete SKIPdevices-fake (Can't create char device node) SKIPdevices (Rsync needs root/fakeroot for device tests) SKIPdir-sgid (The default ACL mode interferes with this test) PASSduplicates PASSexclude PASSexecutability PASSfiles-from PASSfuzzy PASShands PASShardlinks PASSitemize PASSlongdir PASSmerge PASSmissing PASSmkpath SKIPprotected-regular (Can't find protected_regular setting (only available on Linux)) PASSrelative PASSssh-basic PASSsymlink-ignore PASStrimslash PASSunsafe-byname PASSunsafe-links PASSwildmatch SKIPxattrs-hlink (Unable to set an xattr) SKIPxattrs (Unable to set an xattr) - overall results: 33 passed 11 skipped overall result is 0 ... Here is the reported feature comparison between the existing and updated packages. This is one area where some things might need to be fixed with the update. Existing pacakge: $ rsync --version rsync version 3.2.4dev protocol version 31 Copyright (C) 1996-2020 by Andrew Tridgell, Wayne Davison, and others. Web site: https://rsync.samba.org/ Capabilities: 64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints, socketpairs, hardlinks, no hardlink-specials, symlinks, IPv6, atimes, batchfiles, inplace, append, ACLs, xattrs, optional protect-args, iconv, symtimes, prealloc, stop-at, no crtimes Optimizations: no SIMD, asm, openssl-crypto Checksum list: xxh128 xxh3 xxh64 (xxhash) md5 md4 none Compress list: zstd lz4 zlibx zlib none rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the GNU General Public Licence for details. Updated package: $ rsync --version rsync version 3.2.6 protocol version 31 Copyright (C) 1996-2022 by Andrew Tridgell, Wayne Davison, and others. Web site: https://rsync.samba.org/ Capabilities: 64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints, socketpairs, symlinks, symtimes, hardlinks, no hardlink-specials, hardlink-symlinks, IPv6, atimes, batchfiles, inplace, append, ACLs, xattrs, optional secluded-args, no iconv, prealloc, stop-at, crtimes Optimizations: no SIMD-roll, no asm-roll, openssl-crypto, no asm-MD5 Checksum list: xxh128 xxh3 xxh64 (xxhash) md5 md4 none Compress list: zstd lz4 zlibx zlib none rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the GNU General Public Licence for details. This package also seemed to work OK with some casual real testing. Thanks in advance. -- -Chad
Re: resolv.conf and gnupg2
Corinna Vinschen wrote: IIUC, that should be fixable by configuring gnupg with --disable-libdns. Yes, below is the message that I sent to Marco but which was rejected by this list because I wasn't subscribed at the time that I replied to all. -- -Chad On 2022-08-07 10:34, Marco Atzeri wrote: Any suggestion on how to solve the absence of /etc/resolv.conf ? I doubt gnupg2 is the proper package to do so. Looking into this, I'm reminded of how much I really dislike the design of gnupg2. dirmngr appears to have its own DNS client library that tries to do the resolv.conf parsing among other things. I believe this library gets compiled into the current cygwin package. I noticed this configuration option: --disable-libdnsdo not build with libdns support I just tested a build using this option and it seemed to fix the problem for me. I did not use the full end-to-end cygport process but I think the patch at the bottom of this message should do the trick. Could you give it a shot? Thanks... -- -Chad $ diff -u gnupg2.cygport.orig gnupg2.cygport --- gnupg2.cygport.orig 2022-08-08 14:00:18.562073400 -0400 +++ gnupg2.cygport 2022-08-08 14:00:53.14695 -0400 @@ -22,6 +22,6 @@ cygautoreconf sed -i -e '/^development_version=/s/yes/no/' configure cd ${B} - cygconf --enable-gpg-is-gpg2 + cygconf --enable-gpg-is-gpg2 --disable-libdns cygmake }