[ANNOUNCEMENT] Updated: curl 7.71.1-1

[Adam Dinwoodie]

On Sunday 09 August 2020 at 03:48 pm -0600, Brian Inglis wrote:
> Your previous post never made it to me, either cygwin or cygwin-apps lists,
> their archives, or mail-archives'.
> Please check the archives and your email and repost.

Huh.  There was absolutely no indication from my end that anything
hadn't sent.  No idea what went wrong there.

> <snip>
>
> Trying to build with cygport:
>
> - it died silently as I did not have bash-completion-devel installed: could you
> please perhaps move that pkg-config line into src-compile, so that cygport can
> at least run, check, and complain about missing dependencies?

Good shout; it has never bothered me, but it's clearly a sensible change
to make.  I'll do that for the next release.

> - it complains that perl(DBD::SQLite) perl(IO::Pty) are not installed - how do
> these and your other perl module dependencies map to Cygwin packages?
> I also mean that in general - how can I map a perl module to a perl package and
> vice versa - for future info?

Honestly, I've no idea; I don't think there's any canonical conversion.
I mostly have the mapping between Perl modules and their corresponding
Cygwin packages memorised at this point, as they're mostly fairly
obvious if you're looking at the list of packages in the Cygwin
installer.

In theory you could have looked at my cygport.out to see what packages I
had installed, but that would have required my cygport.out that was
attached to the original email that was evidently eaten by a grue.

On Sunday 09 August 2020 at 09:32 pm -0600, Brian Inglis wrote:
> Build ran without problems other than above complaint, and some tests were
> skipped especially svn, cvs, p4, gitweb, those requiring explicit env settings,
> and some subtests failed:
>
> <snip>
> Test Summary Report
> -------------------
> t3070-wildmatch.sh  (Wstat: 256 Tests: 1890 Failed: 44)
>   Failed tests:  114, 116, 118, 120, 674, 676, 678, 680
>                 734, 736, 738, 740, 744, 746, 748, 750
>                 954, 956, 958, 960, 964, 966, 968, 970
>                 974, 976, 978, 980, 1284, 1286, 1288, 1290
>                 1374, 1376, 1378, 1380, 1414, 1416, 1418
>                 1420, 1424, 1426, 1428, 1430
>   Non-zero exit status: 1
> t5500-fetch-pack.sh  (Wstat: 256 Tests: 372 Failed: 12)
>   Failed tests:  145, 148, 164-165, 242, 245, 261-262, 339
>                 342, 358-359
>   Non-zero exit status: 1
> t5580-unc-paths.sh  (Wstat: 256 Tests: 8 Failed: 3)
>   Failed tests:  4, 6, 8
>   Non-zero exit status: 1
> t5601-clone.sh  (Wstat: 256 Tests: 104 Failed: 4)
>   Failed tests:  62-64, 66
>   Non-zero exit status: 1
> t7815-grep-binary.sh  (Wstat: 0 Tests: 22 Failed: 0)
>   TODO passed:   12
> Files=908, Tests=22240, 17749 wallclock secs
>         (12.25 usr 32.41 sys + 6979.47 cusr 28075.98 csys = 35100.10 CPU)
> Result: FAIL
> make[1]: *** [Makefile:52: prove] Error 1
> make[1]: Target all not remade because of errors.
> make[1]: Leaving directory
> /mnt/c/Users/bwi/src/cygwin/git/git-2.28.0-1.x86_64/build/t
> make: *** [Makefile:2767: test] Error 2

That's the currently expected test output for 64-bit Cygwin; cleaning it
up is on my to-do list.

git-remote-http is going to be one of the tests that requires either
gitweb or specific environment settings, because it's fundamentally
about running an HTTP interface, and Git's test scripts don't want to
set one of those up for you silently.

On Monday 10 August 2020 at 03:14 pm -0400, Ken Brown via Cygwin wrote:
> On 8/10/2020 1:33 PM, Brian Inglis wrote:
> > I try to avoid looking at autotools plumbing if I can possibly avoid it! ;^>
> > Someone cleaned up the approach used, as the patch did not apply and was dropped.

Likewise!  I was somewhat hoping someone else would be able to work out
what was going wrong, and it looks like Ken has achieved that.

> My point is that the patch shouldn't have been dropped.  It should have been
> modified to apply to the updated sources.  (I've done this.  See the
> attached.) As Yaakov wrote, the patch is needed to prevent 'curl-config
> --libs' from including libs that are only needed for static linking.
>
> With the modified patch applied, curl-config gives the expected result:
>
> $ curl-config --libs
> -lcurl
>
> > If you look at my later post, cygport git build and tests worked for me with no
> > problems other than at first missing some package build dependencies
>
> Those were not really build dependencies.  They only appeared to be needed
> because 'curl-config --libs' erroneously included libs that are only needed
> for static linking.

I've not rebuilt with Ken's patch, but given the behaviour he describes,
the patch looks sensible to me.  Brian, let me know if you reckon
there's value in me rebuilding Curl with this patch and trying to
rebuild Git, or if you're okay to incorporate this patch into a Curl
rebuild now?

Thanks all!

Adam