Re: [ITP] rsync 3.2.6
On 09/10/2022 15:23, Jon Turney wrote: On 06/10/2022 02:29, Chad Dougherty wrote: 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 [...] This package also seemed to work OK with some casual real testing. Thanks for looking into updating this. I'd like to give the existing maintainer first refusal, though. No response from Jari, 8 weeks have elapsed, so I've given maintainership to Chad. Jari, Hope you are ok. Please let me know if this isn't what you wanted.
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] rsync 3.2.6
Chad Dougherty writes: > 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. You should duly ignore any such upstream nonsense and do a full autoreconf on anything you build for Cygwin anyway. You might have to remove some generated files first (see DISTCLEANFILES). You can't assume that upstream has used an autoconf new enough to treat Cygwin specific stuff correctly. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
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] rsync 3.2.6
On 2022-10-09 14:23 UTC, Jon Turney wrote:
On 06/10/2022 02:29, Chad Dougherty wrote:
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
This package also seemed to work OK with some casual real testing.
Thanks for looking into updating this. I'd like to give the existing
maintainer first refusal, though.
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.
# 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 think this topic is touched upon in the cygport reference manual in
the section on cygautoreconf, but perhaps that could be clearer)
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?
I've found a good way to discover optional dependencies not mentioned in the
package docs as build prereqs is to look in the configure generated in the build
src dir:
PKG-VER.ARCH/src/PKG-VER/configure
for the options under:
"Optional Features:
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
...
Optional Packages:
--with-PACKAGE[=ARG]use PACKAGE [ARG=yes]
--without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
..."
and if you see features or package that mention something like a package name,
see if you can find a related -devel package e.g. if you see curses, look for:
$ cygcheck -p 'curses.*-devel'
Found 7 matches for curses.*-devel
libncurses-devel-6.0-11.20170617 - libncurses-devel: Terminal display library
libncurses-devel-6.0-12.20171125 - libncurses-devel: Terminal display library
libncurses-devel-6.1-1.20190727 - libncurses-devel: Terminal display library
libncurses-devel-6.3-1.20220416 - libncurses-devel: Terminal display library
libncursesw-devel-6.0-11.20170617 - libncursesw-devel: Obsoleted by
libncurses-devel
libncursesw-devel-6.0-12.20171125 - libncursesw-devel: Obsoleted by
libncurses-devel
libncursesw-devel-6.1-1.20190727 - libncursesw-devel: Obsoleted by
libncurses-devel
add that package name in a (was DEPEND in old cygports) now:
BUILD_REQUIRES="libncurses-devel ..."
BUILD_REQUIRES+=" ..."
list in the cygport, which ensures that any dependencies not required by cygport
(similar to build-essential on other distros) will be installed when you test
your builds under the Scallywag CI.
Also look in the config and compile logs for other package names and executables
checked for during the config, shown under config options or variables, or in
the build logs.
You can also look in other distros for the package spec or build rules e.g.
https://src.fedoraproject.org/rpms/rsync/blob/rawhide/f/rsync.spec
and try to map their build requirements to Cygwin's.
--
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 à retirerbut when there is no more to cut
-- Antoine de Saint-Exupéry
Re: [ITP] rsync 3.2.6
On 06/10/2022 02:29, Chad Dougherty wrote:
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
[...]
This package also seemed to work OK with some casual real testing.
Thanks for looking into updating this. I'd like to give the existing
maintainer first refusal, though.
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.
# 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 think this topic is touched upon in the cygport reference manual in
the section on cygautoreconf, but perhaps that could be clearer)
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?
Re: [ITP] rsync 3.2.6
On 10/6/2022 1:24 PM, Adam Dinwoodie wrote: Jari isn't very active on the lists these days, but I think he is still active, so he might want to weigh in. I'm not sure Jari is subscribed to this list. I've added him to the CC. Ken
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
Re: [ITP] rsync 3.2.6
On Wed, Oct 05, 2022 at 09:29:08PM -0400, Chad Dougherty wrote: > 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. Definitely a faux pas, but it's done now. I definitely made my fair share of errors of etiquette when I first tried packaging things, so I don't think it's worth worrying too much over. Jari isn't very active on the lists these days, but I think he is still active, so he might want to weigh in. > 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: > ... > > > 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. "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. Otherwise this looks good to my relatively inexpert eyes, and I'd definitely be grateful for this package getting an update! I think we need to give Jari a chance to respond on-list, and see what the folks who have actual authority around maintainership and non-maintainer uploads say. Adam
