Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko)

2022-11-04 Thread Chad Dougherty

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

2022-10-30 Thread Chad Dougherty

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

2022-10-25 Thread Chad Dougherty

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

2022-10-25 Thread Chad Dougherty

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

2022-10-25 Thread Chad Dougherty

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

2022-10-23 Thread Chad Dougherty

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

2022-10-23 Thread Chad Dougherty

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

2022-10-23 Thread Chad Dougherty

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

2022-10-22 Thread Chad Dougherty

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

2022-10-21 Thread Chad Dougherty

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

2022-10-10 Thread Chad Dougherty

Name: Chad Dougherty
 BEGIN SSH2 PUBLIC KEY 
C3NzaC1lZDI1NTE5INJ3RlnS9WnMOyn6+dnPyktOriBh5a0V3yOlitsGUs+w
 END SSH2 PUBLIC KEY 


Re: [ITP] rsync 3.2.6

2022-10-09 Thread Chad Dougherty

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

2022-10-09 Thread Chad Dougherty

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

2022-10-09 Thread Chad Dougherty

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

2022-10-08 Thread Chad Dougherty

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

2022-10-06 Thread Chad Dougherty

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

2022-10-05 Thread Chad Dougherty

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

2022-08-08 Thread Chad Dougherty

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
 }