Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Brian Inglis]

On 2020-08-11 16:00, Brian Inglis wrote:
> On 2020-08-11 05:27, Adam Dinwoodie wrote:
>> On Tue, 11 Aug 2020 at 12:14, Ken Brown via Cygwin wrote:
>>>> In that case, it looks to me as if the generated curl-config --libs statements:
>>>>
>>>>          if test "Xyes" = "Xno" -o "Xyes" = "Xyes"; then
>>>>            echo ${CURLLIBDIR}-lcurl -lnghttp2 -lidn2 -lssh -lpsl -lssl -lcrypto
>>>> -lldap -llber -lbrotlidec -lbrotlidec -lz
>>>>
>>>> based on curl-config.in:
>>>>
>>>>          if test "X@ENABLE_SHARED@" = "Xno" -o "X@REQUIRE_LIB_DEPS@" = "Xyes"; then
>>>>            echo ${CURLLIBDIR}-lcurl @LIBCURL_LIBS@
>>>>
>>>> REQUIRE_LIB_DEPS should be no, derived from configure.ac:
>>>>
>>>> if test "X$enable_shared" = "Xyes" -a "X$link_all_deplibs" = "Xno"
>>>> then
>>>>      REQUIRE_LIB_DEPS=no
>>>> else
>>>>      REQUIRE_LIB_DEPS=yes
>>>> fi
>>>> AC_SUBST(REQUIRE_LIB_DEPS)
>>>> AM_CONDITIONAL(USE_EXPLICIT_LIB_DEPS, test x$REQUIRE_LIB_DEPS = xyes)
>>>>
>>>> but for Cygwin link_all_deplibs remains defaulted to unknown, so either that
>>>> variable should be set in configure, or that condition should perhaps be changed
>>>> to:
>>>>
>>>> if test "X$enable_shared" = "Xyes" -a "X$link_all_deplibs" != "Xyes"
>>>>
>>>> with appropriate bug reports and changes to be made upstream if possible.
>>>
>>> If you want to look into ways of fixing curl-config different from what Yaakov
>>> did, that's fine; you're the maintainer.  All I did was look at Yaakov's patch
>>> and port it to curl 7.71.1, that being a quick and easy way to fix the reported
>>> problem.
>>
>> Someone else did raise this problem upstream at
>> https://github.com/curl/curl/issues/5793, and the comments there imply
>> they'd be interested in integrating patches Cygwin uses into the
>> upstream code, although the upstream maintainers aren't going to do
>> that without someone proactively submitting the patch to them.
> 
> I'll copy these comments and suggestions and follow up there, as that appears to
> be the official bug tracker, and they appear receptive to discussing and fixing
> issues.
> 
>> For my part, I'm not particularly fussed whether this is fixed with an
>> upstream patch or a Cygwin patch; I just want my use cases to work,
>> and as of 7.71.1-1 they don't. That said, my experience of being a
>> package maintainer would lead me to want to submit patches upstream if
>> at all possible, just to reduce the need to handle these sorts of
>> problems. My inclination would be to restore the patched behaviour
>> with Ken's new patch as a short-term fix, then get this submitted
>> upstream so that in the long-term this patch can be retired.
> 
> I did not see or get your original email, and could not reproduce your issue
> using the current git source package, curl package, and cygport.
> That could be due to two missing perl modules (solved in another sub-thread by
> Achim).
> Any suggestions as to what may be required to get curl-config to act up in a
> build would be appreciated.
> It is always easier to check if a problem is actually fixed when you can perform
> an in situ regression test.
> Running curl-config and reading the docs, it does not appear to me to be clearly
> specified why and when dynamic and static library parameters are either built in
> or generated, whereas the conditions for reproducing the output are well
> specified for pkgconf/pkg-config.
> That may become more apparent in follow ups on the bug tracker.

[Followed up on Github curl bug tracker and may have patch, but subsequent
problems building tests, which KB may know something about, so moving to
cygwin-apps]

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Brian Inglis]

On 2020-08-14 12:19, Brian Inglis wrote:
> On 2020-08-11 16:00, Brian Inglis wrote:
>> On 2020-08-11 05:27, Adam Dinwoodie wrote:
>>> On Tue, 11 Aug 2020 at 12:14, Ken Brown via Cygwin wrote:
>>>>> In that case, it looks to me as if the generated curl-config --libs statements:
>>>>>
>>>>>          if test "Xyes" = "Xno" -o "Xyes" = "Xyes"; then
>>>>>            echo ${CURLLIBDIR}-lcurl -lnghttp2 -lidn2 -lssh -lpsl -lssl -lcrypto
>>>>> -lldap -llber -lbrotlidec -lbrotlidec -lz
>>>>>
>>>>> based on curl-config.in:
>>>>>
>>>>>          if test "X@ENABLE_SHARED@" = "Xno" -o "X@REQUIRE_LIB_DEPS@" = "Xyes"; then
>>>>>            echo ${CURLLIBDIR}-lcurl @LIBCURL_LIBS@
>>>>>
>>>>> REQUIRE_LIB_DEPS should be no, derived from configure.ac:
>>>>>
>>>>> if test "X$enable_shared" = "Xyes" -a "X$link_all_deplibs" = "Xno"
>>>>> then
>>>>>      REQUIRE_LIB_DEPS=no
>>>>> else
>>>>>      REQUIRE_LIB_DEPS=yes
>>>>> fi
>>>>> AC_SUBST(REQUIRE_LIB_DEPS)
>>>>> AM_CONDITIONAL(USE_EXPLICIT_LIB_DEPS, test x$REQUIRE_LIB_DEPS = xyes)
>>>>>
>>>>> but for Cygwin link_all_deplibs remains defaulted to unknown, so either that
>>>>> variable should be set in configure, or that condition should perhaps be changed
>>>>> to:
>>>>>
>>>>> if test "X$enable_shared" = "Xyes" -a "X$link_all_deplibs" != "Xyes"
>>>>>
>>>>> with appropriate bug reports and changes to be made upstream if possible.
>>>>
>>>> If you want to look into ways of fixing curl-config different from what Yaakov
>>>> did, that's fine; you're the maintainer.  All I did was look at Yaakov's patch
>>>> and port it to curl 7.71.1, that being a quick and easy way to fix the reported
>>>> problem.
>>>
>>> Someone else did raise this problem upstream at
>>> https://github.com/curl/curl/issues/5793, and the comments there imply
>>> they'd be interested in integrating patches Cygwin uses into the
>>> upstream code, although the upstream maintainers aren't going to do
>>> that without someone proactively submitting the patch to them.
>>
>> I'll copy these comments and suggestions and follow up there, as that appears to
>> be the official bug tracker, and they appear receptive to discussing and fixing
>> issues.
>>
>>> For my part, I'm not particularly fussed whether this is fixed with an
>>> upstream patch or a Cygwin patch; I just want my use cases to work,
>>> and as of 7.71.1-1 they don't. That said, my experience of being a
>>> package maintainer would lead me to want to submit patches upstream if
>>> at all possible, just to reduce the need to handle these sorts of
>>> problems. My inclination would be to restore the patched behaviour
>>> with Ken's new patch as a short-term fix, then get this submitted
>>> upstream so that in the long-term this patch can be retired.
>>
>> I did not see or get your original email, and could not reproduce your issue
>> using the current git source package, curl package, and cygport.
>> That could be due to two missing perl modules (solved in another sub-thread by
>> Achim).
>> Any suggestions as to what may be required to get curl-config to act up in a
>> build would be appreciated.
>> It is always easier to check if a problem is actually fixed when you can perform
>> an in situ regression test.
>> Running curl-config and reading the docs, it does not appear to me to be clearly
>> specified why and when dynamic and static library parameters are either built in
>> or generated, whereas the conditions for reproducing the output are well
>> specified for pkgconf/pkg-config.
>> That may become more apparent in follow ups on the bug tracker.
> 
> [Followed up on Github curl bug tracker and may have patch, but subsequent
> problems building tests, which KB may know something about, so moving to
> cygwin-apps]

Test build failures - tried adding to cygport:

src_test() {
        cd ${B}
        cygtest LDFLAGS="${LDFLAGS} -no-undefined"
}

but no change:

Making all in libtest
make[2]: Entering directory
'/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/libtest'
  CCLD     libstubgss.la
libtool:   error: can't build x86_64-pc-cygwin shared library unless
-no-undefined is specified
make[2]: *** [Makefile:2547: libstubgss.la] Error 1
make[2]: Target 'all' not remade because of errors.
make[2]: Leaving directory
'/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/libtest'
Making all in unit
make[2]: Entering directory
'/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/unit'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory
'/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/unit'
make[2]: Entering directory
'/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests'
make[2]: Nothing to be done for 'all-am'.
make[2]: Leaving directory
'/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests'
make[1]: *** [Makefile:513: all-recursive] Error 1
make[1]: Target 'all' not remade because of errors.
make[1]: Target 'quiet-test' not remade because of errors.
make[1]: Leaving directory
'/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests'
make: *** [Makefile:1437: test] Error 2

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Ken Brown]

[-- Attachment #1: Type: text/plain, Size: 5638 bytes --]

On 8/14/2020 2:45 PM, Brian Inglis wrote:
> On 2020-08-14 12:19, Brian Inglis wrote:
>> On 2020-08-11 16:00, Brian Inglis wrote:
>>> On 2020-08-11 05:27, Adam Dinwoodie wrote:
>>>> On Tue, 11 Aug 2020 at 12:14, Ken Brown via Cygwin wrote:
>>>>>> In that case, it looks to me as if the generated curl-config --libs statements:
>>>>>>
>>>>>>           if test "Xyes" = "Xno" -o "Xyes" = "Xyes"; then
>>>>>>             echo ${CURLLIBDIR}-lcurl -lnghttp2 -lidn2 -lssh -lpsl -lssl -lcrypto
>>>>>> -lldap -llber -lbrotlidec -lbrotlidec -lz
>>>>>>
>>>>>> based on curl-config.in:
>>>>>>
>>>>>>           if test "X@ENABLE_SHARED@" = "Xno" -o "X@REQUIRE_LIB_DEPS@" = "Xyes"; then
>>>>>>             echo ${CURLLIBDIR}-lcurl @LIBCURL_LIBS@
>>>>>>
>>>>>> REQUIRE_LIB_DEPS should be no, derived from configure.ac:
>>>>>>
>>>>>> if test "X$enable_shared" = "Xyes" -a "X$link_all_deplibs" = "Xno"
>>>>>> then
>>>>>>       REQUIRE_LIB_DEPS=no
>>>>>> else
>>>>>>       REQUIRE_LIB_DEPS=yes
>>>>>> fi
>>>>>> AC_SUBST(REQUIRE_LIB_DEPS)
>>>>>> AM_CONDITIONAL(USE_EXPLICIT_LIB_DEPS, test x$REQUIRE_LIB_DEPS = xyes)
>>>>>>
>>>>>> but for Cygwin link_all_deplibs remains defaulted to unknown, so either that
>>>>>> variable should be set in configure, or that condition should perhaps be changed
>>>>>> to:
>>>>>>
>>>>>> if test "X$enable_shared" = "Xyes" -a "X$link_all_deplibs" != "Xyes"
>>>>>>
>>>>>> with appropriate bug reports and changes to be made upstream if possible.
>>>>>
>>>>> If you want to look into ways of fixing curl-config different from what Yaakov
>>>>> did, that's fine; you're the maintainer.  All I did was look at Yaakov's patch
>>>>> and port it to curl 7.71.1, that being a quick and easy way to fix the reported
>>>>> problem.
>>>>
>>>> Someone else did raise this problem upstream at
>>>> https://github.com/curl/curl/issues/5793, and the comments there imply
>>>> they'd be interested in integrating patches Cygwin uses into the
>>>> upstream code, although the upstream maintainers aren't going to do
>>>> that without someone proactively submitting the patch to them.
>>>
>>> I'll copy these comments and suggestions and follow up there, as that appears to
>>> be the official bug tracker, and they appear receptive to discussing and fixing
>>> issues.
>>>
>>>> For my part, I'm not particularly fussed whether this is fixed with an
>>>> upstream patch or a Cygwin patch; I just want my use cases to work,
>>>> and as of 7.71.1-1 they don't. That said, my experience of being a
>>>> package maintainer would lead me to want to submit patches upstream if
>>>> at all possible, just to reduce the need to handle these sorts of
>>>> problems. My inclination would be to restore the patched behaviour
>>>> with Ken's new patch as a short-term fix, then get this submitted
>>>> upstream so that in the long-term this patch can be retired.
>>>
>>> I did not see or get your original email, and could not reproduce your issue
>>> using the current git source package, curl package, and cygport.
>>> That could be due to two missing perl modules (solved in another sub-thread by
>>> Achim).
>>> Any suggestions as to what may be required to get curl-config to act up in a
>>> build would be appreciated.
>>> It is always easier to check if a problem is actually fixed when you can perform
>>> an in situ regression test.
>>> Running curl-config and reading the docs, it does not appear to me to be clearly
>>> specified why and when dynamic and static library parameters are either built in
>>> or generated, whereas the conditions for reproducing the output are well
>>> specified for pkgconf/pkg-config.
>>> That may become more apparent in follow ups on the bug tracker.
>>
>> [Followed up on Github curl bug tracker and may have patch, but subsequent
>> problems building tests, which KB may know something about, so moving to
>> cygwin-apps]
> 
> Test build failures - tried adding to cygport:
> 
> src_test() {
>          cd ${B}
>          cygtest LDFLAGS="${LDFLAGS} -no-undefined"
> }
> 
> but no change:
> 
> Making all in libtest
> make[2]: Entering directory
> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/libtest'
>    CCLD     libstubgss.la
> libtool:   error: can't build x86_64-pc-cygwin shared library unless
> -no-undefined is specified
> make[2]: *** [Makefile:2547: libstubgss.la] Error 1
> make[2]: Target 'all' not remade because of errors.
> make[2]: Leaving directory
> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/libtest'
> Making all in unit
> make[2]: Entering directory
> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/unit'
> make[2]: Nothing to be done for 'all'.
> make[2]: Leaving directory
> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/unit'
> make[2]: Entering directory
> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests'
> make[2]: Nothing to be done for 'all-am'.
> make[2]: Leaving directory
> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests'
> make[1]: *** [Makefile:513: all-recursive] Error 1
> make[1]: Target 'all' not remade because of errors.
> make[1]: Target 'quiet-test' not remade because of errors.
> make[1]: Leaving directory
> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests'
> make: *** [Makefile:1437: test] Error 2

The attached patch should fix it.  I didn't take the trouble to write the patch 
in a way that's suitable for sending upstream.  If you want to do that, you 
could imitate what's done for libhostname.la a little earlier in the same 
Makefile.am.  But I recommend that you first get curl 7.71.1-2 released before 
spending time polishing the patch.

Ken

[-- Attachment #2: 7.71.1-no_undefined.patch --]
[-- Type: text/plain, Size: 535 bytes --]

--- origsrc/curl-7.71.1/tests/libtest/Makefile.am	2020-06-27 18:03:53.000000000 -0400
+++ src/curl-7.71.1/tests/libtest/Makefile.am	2020-08-14 14:33:04.434364600 -0400
@@ -118,7 +118,7 @@ if BUILD_STUB_GSS
 noinst_LTLIBRARIES += libstubgss.la
 
 libstubgss_la_CPPFLAGS = $(AM_CPPFLAGS)
-libstubgss_la_LDFLAGS = $(AM_LDFLAGS) -avoid-version -rpath /nowhere
+libstubgss_la_LDFLAGS = $(AM_LDFLAGS) -avoid-version -rpath /nowhere -no-undefined
 libstubgss_la_CFLAGS = $(AM_CFLAGS) -g
 
 libstubgss_la_SOURCES = stub_gssapi.c stub_gssapi.h

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Brian Inglis]

On 2020-08-14 13:36, Ken Brown via Cygwin-apps wrote:
> On 8/14/2020 2:45 PM, Brian Inglis wrote:
>> On 2020-08-14 12:19, Brian Inglis wrote:
>>> On 2020-08-11 16:00, Brian Inglis wrote:
>>>> On 2020-08-11 05:27, Adam Dinwoodie wrote:
>>>>> On Tue, 11 Aug 2020 at 12:14, Ken Brown via Cygwin wrote:
>>>>>>> In that case, it looks to me as if the generated curl-config --libs
>>>>>>> statements:
>>>>>>>
>>>>>>>           if test "Xyes" = "Xno" -o "Xyes" = "Xyes"; then
>>>>>>>             echo ${CURLLIBDIR}-lcurl -lnghttp2 -lidn2 -lssh -lpsl -lssl
>>>>>>> -lcrypto
>>>>>>> -lldap -llber -lbrotlidec -lbrotlidec -lz
>>>>>>>
>>>>>>> based on curl-config.in:
>>>>>>>
>>>>>>>           if test "X@ENABLE_SHARED@" = "Xno" -o "X@REQUIRE_LIB_DEPS@" =
>>>>>>> "Xyes"; then
>>>>>>>             echo ${CURLLIBDIR}-lcurl @LIBCURL_LIBS@
>>>>>>>
>>>>>>> REQUIRE_LIB_DEPS should be no, derived from configure.ac:
>>>>>>>
>>>>>>> if test "X$enable_shared" = "Xyes" -a "X$link_all_deplibs" = "Xno"
>>>>>>> then
>>>>>>>       REQUIRE_LIB_DEPS=no
>>>>>>> else
>>>>>>>       REQUIRE_LIB_DEPS=yes
>>>>>>> fi
>>>>>>> AC_SUBST(REQUIRE_LIB_DEPS)
>>>>>>> AM_CONDITIONAL(USE_EXPLICIT_LIB_DEPS, test x$REQUIRE_LIB_DEPS = xyes)
>>>>>>>
>>>>>>> but for Cygwin link_all_deplibs remains defaulted to unknown, so either that
>>>>>>> variable should be set in configure, or that condition should perhaps be
>>>>>>> changed
>>>>>>> to:
>>>>>>>
>>>>>>> if test "X$enable_shared" = "Xyes" -a "X$link_all_deplibs" != "Xyes"
>>>>>>>
>>>>>>> with appropriate bug reports and changes to be made upstream if possible.
>>>>>>
>>>>>> If you want to look into ways of fixing curl-config different from what
>>>>>> Yaakov
>>>>>> did, that's fine; you're the maintainer.  All I did was look at Yaakov's
>>>>>> patch
>>>>>> and port it to curl 7.71.1, that being a quick and easy way to fix the
>>>>>> reported
>>>>>> problem.
>>>>>
>>>>> Someone else did raise this problem upstream at
>>>>> https://github.com/curl/curl/issues/5793, and the comments there imply
>>>>> they'd be interested in integrating patches Cygwin uses into the
>>>>> upstream code, although the upstream maintainers aren't going to do
>>>>> that without someone proactively submitting the patch to them.
>>>>
>>>> I'll copy these comments and suggestions and follow up there, as that
>>>> appears to
>>>> be the official bug tracker, and they appear receptive to discussing and fixing
>>>> issues.
>>>>
>>>>> For my part, I'm not particularly fussed whether this is fixed with an
>>>>> upstream patch or a Cygwin patch; I just want my use cases to work,
>>>>> and as of 7.71.1-1 they don't. That said, my experience of being a
>>>>> package maintainer would lead me to want to submit patches upstream if
>>>>> at all possible, just to reduce the need to handle these sorts of
>>>>> problems. My inclination would be to restore the patched behaviour
>>>>> with Ken's new patch as a short-term fix, then get this submitted
>>>>> upstream so that in the long-term this patch can be retired.
>>>>
>>>> I did not see or get your original email, and could not reproduce your issue
>>>> using the current git source package, curl package, and cygport.
>>>> That could be due to two missing perl modules (solved in another sub-thread by
>>>> Achim).
>>>> Any suggestions as to what may be required to get curl-config to act up in a
>>>> build would be appreciated.
>>>> It is always easier to check if a problem is actually fixed when you can
>>>> perform
>>>> an in situ regression test.
>>>> Running curl-config and reading the docs, it does not appear to me to be
>>>> clearly
>>>> specified why and when dynamic and static library parameters are either
>>>> built in
>>>> or generated, whereas the conditions for reproducing the output are well
>>>> specified for pkgconf/pkg-config.
>>>> That may become more apparent in follow ups on the bug tracker.
>>>
>>> [Followed up on Github curl bug tracker and may have patch, but subsequent
>>> problems building tests, which KB may know something about, so moving to
>>> cygwin-apps]
>>
>> Test build failures - tried adding to cygport:
>>
>> src_test() {
>>          cd ${B}
>>          cygtest LDFLAGS="${LDFLAGS} -no-undefined"
>> }
>>
>> but no change:
>>
>> Making all in libtest
>> make[2]: Entering directory
>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/libtest'
>>    CCLD     libstubgss.la
>> libtool:   error: can't build x86_64-pc-cygwin shared library unless
>> -no-undefined is specified
>> make[2]: *** [Makefile:2547: libstubgss.la] Error 1
>> make[2]: Target 'all' not remade because of errors.
>> make[2]: Leaving directory
>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/libtest'
>> Making all in unit
>> make[2]: Entering directory
>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/unit'
>> make[2]: Nothing to be done for 'all'.
>> make[2]: Leaving directory
>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/unit'
>> make[2]: Entering directory
>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests'
>> make[2]: Nothing to be done for 'all-am'.
>> make[2]: Leaving directory
>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests'
>> make[1]: *** [Makefile:513: all-recursive] Error 1
>> make[1]: Target 'all' not remade because of errors.
>> make[1]: Target 'quiet-test' not remade because of errors.
>> make[1]: Leaving directory
>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests'
>> make: *** [Makefile:1437: test] Error 2
> 
> The attached patch should fix it.  I didn't take the trouble to write the patch
> in a way that's suitable for sending upstream.  If you want to do that, you
> could imitate what's done for libhostname.la a little earlier in the same
> Makefile.am.  But I recommend that you first get curl 7.71.1-2 released before
> spending time polishing the patch.

Thanks for the patches, pointers, and help understanding more of the autotools
granular infrastructure.
I was able to polish the patch thanks to your pointers while waiting for the 32
bit x86 build, rebuild and retest both arches last night, and upload and
announce today.
I will submit that upstream to the curl project developer on Github, now I know
the project lives there.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Ken Brown]

On 8/15/2020 5:32 PM, Brian Inglis wrote:
> On 2020-08-14 13:36, Ken Brown via Cygwin-apps wrote:
>> On 8/14/2020 2:45 PM, Brian Inglis wrote:
>>> On 2020-08-14 12:19, Brian Inglis wrote:
>>>> On 2020-08-11 16:00, Brian Inglis wrote:
>>>>> On 2020-08-11 05:27, Adam Dinwoodie wrote:
>>>>>> On Tue, 11 Aug 2020 at 12:14, Ken Brown via Cygwin wrote:
>>>>>>>> In that case, it looks to me as if the generated curl-config --libs
>>>>>>>> statements:
>>>>>>>>
>>>>>>>>            if test "Xyes" = "Xno" -o "Xyes" = "Xyes"; then
>>>>>>>>              echo ${CURLLIBDIR}-lcurl -lnghttp2 -lidn2 -lssh -lpsl -lssl
>>>>>>>> -lcrypto
>>>>>>>> -lldap -llber -lbrotlidec -lbrotlidec -lz
>>>>>>>>
>>>>>>>> based on curl-config.in:
>>>>>>>>
>>>>>>>>            if test "X@ENABLE_SHARED@" = "Xno" -o "X@REQUIRE_LIB_DEPS@" =
>>>>>>>> "Xyes"; then
>>>>>>>>              echo ${CURLLIBDIR}-lcurl @LIBCURL_LIBS@
>>>>>>>>
>>>>>>>> REQUIRE_LIB_DEPS should be no, derived from configure.ac:
>>>>>>>>
>>>>>>>> if test "X$enable_shared" = "Xyes" -a "X$link_all_deplibs" = "Xno"
>>>>>>>> then
>>>>>>>>        REQUIRE_LIB_DEPS=no
>>>>>>>> else
>>>>>>>>        REQUIRE_LIB_DEPS=yes
>>>>>>>> fi
>>>>>>>> AC_SUBST(REQUIRE_LIB_DEPS)
>>>>>>>> AM_CONDITIONAL(USE_EXPLICIT_LIB_DEPS, test x$REQUIRE_LIB_DEPS = xyes)
>>>>>>>>
>>>>>>>> but for Cygwin link_all_deplibs remains defaulted to unknown, so either that
>>>>>>>> variable should be set in configure, or that condition should perhaps be
>>>>>>>> changed
>>>>>>>> to:
>>>>>>>>
>>>>>>>> if test "X$enable_shared" = "Xyes" -a "X$link_all_deplibs" != "Xyes"
>>>>>>>>
>>>>>>>> with appropriate bug reports and changes to be made upstream if possible.
>>>>>>>
>>>>>>> If you want to look into ways of fixing curl-config different from what
>>>>>>> Yaakov
>>>>>>> did, that's fine; you're the maintainer.  All I did was look at Yaakov's
>>>>>>> patch
>>>>>>> and port it to curl 7.71.1, that being a quick and easy way to fix the
>>>>>>> reported
>>>>>>> problem.
>>>>>>
>>>>>> Someone else did raise this problem upstream at
>>>>>> https://github.com/curl/curl/issues/5793, and the comments there imply
>>>>>> they'd be interested in integrating patches Cygwin uses into the
>>>>>> upstream code, although the upstream maintainers aren't going to do
>>>>>> that without someone proactively submitting the patch to them.
>>>>>
>>>>> I'll copy these comments and suggestions and follow up there, as that
>>>>> appears to
>>>>> be the official bug tracker, and they appear receptive to discussing and fixing
>>>>> issues.
>>>>>
>>>>>> For my part, I'm not particularly fussed whether this is fixed with an
>>>>>> upstream patch or a Cygwin patch; I just want my use cases to work,
>>>>>> and as of 7.71.1-1 they don't. That said, my experience of being a
>>>>>> package maintainer would lead me to want to submit patches upstream if
>>>>>> at all possible, just to reduce the need to handle these sorts of
>>>>>> problems. My inclination would be to restore the patched behaviour
>>>>>> with Ken's new patch as a short-term fix, then get this submitted
>>>>>> upstream so that in the long-term this patch can be retired.
>>>>>
>>>>> I did not see or get your original email, and could not reproduce your issue
>>>>> using the current git source package, curl package, and cygport.
>>>>> That could be due to two missing perl modules (solved in another sub-thread by
>>>>> Achim).
>>>>> Any suggestions as to what may be required to get curl-config to act up in a
>>>>> build would be appreciated.
>>>>> It is always easier to check if a problem is actually fixed when you can
>>>>> perform
>>>>> an in situ regression test.
>>>>> Running curl-config and reading the docs, it does not appear to me to be
>>>>> clearly
>>>>> specified why and when dynamic and static library parameters are either
>>>>> built in
>>>>> or generated, whereas the conditions for reproducing the output are well
>>>>> specified for pkgconf/pkg-config.
>>>>> That may become more apparent in follow ups on the bug tracker.
>>>>
>>>> [Followed up on Github curl bug tracker and may have patch, but subsequent
>>>> problems building tests, which KB may know something about, so moving to
>>>> cygwin-apps]
>>>
>>> Test build failures - tried adding to cygport:
>>>
>>> src_test() {
>>>           cd ${B}
>>>           cygtest LDFLAGS="${LDFLAGS} -no-undefined"
>>> }
>>>
>>> but no change:
>>>
>>> Making all in libtest
>>> make[2]: Entering directory
>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/libtest'
>>>     CCLD     libstubgss.la
>>> libtool:   error: can't build x86_64-pc-cygwin shared library unless
>>> -no-undefined is specified
>>> make[2]: *** [Makefile:2547: libstubgss.la] Error 1
>>> make[2]: Target 'all' not remade because of errors.
>>> make[2]: Leaving directory
>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/libtest'
>>> Making all in unit
>>> make[2]: Entering directory
>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/unit'
>>> make[2]: Nothing to be done for 'all'.
>>> make[2]: Leaving directory
>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/unit'
>>> make[2]: Entering directory
>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests'
>>> make[2]: Nothing to be done for 'all-am'.
>>> make[2]: Leaving directory
>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests'
>>> make[1]: *** [Makefile:513: all-recursive] Error 1
>>> make[1]: Target 'all' not remade because of errors.
>>> make[1]: Target 'quiet-test' not remade because of errors.
>>> make[1]: Leaving directory
>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests'
>>> make: *** [Makefile:1437: test] Error 2
>>
>> The attached patch should fix it.  I didn't take the trouble to write the patch
>> in a way that's suitable for sending upstream.  If you want to do that, you
>> could imitate what's done for libhostname.la a little earlier in the same
>> Makefile.am.  But I recommend that you first get curl 7.71.1-2 released before
>> spending time polishing the patch.
> 
> Thanks for the patches, pointers, and help understanding more of the autotools
> granular infrastructure.

You're welcome.  Glad I could help.

> I was able to polish the patch thanks to your pointers while waiting for the 32
> bit x86 build, rebuild and retest both arches last night, and upload and
> announce today.
> I will submit that upstream to the curl project developer on Github, now I know
> the project lives there.

Great.  I think it would be good if we maintainers did more of that (sending 
patches upstream).  I'm as guilty as anyone here.  Sometimes it just seems like 
too much trouble.

Ken

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Brian Inglis]

On 2020-08-15 15:50, Ken Brown via Cygwin-apps wrote:
> On 8/15/2020 5:32 PM, Brian Inglis wrote:
>> On 2020-08-14 13:36, Ken Brown via Cygwin-apps wrote:
>>> On 8/14/2020 2:45 PM, Brian Inglis wrote:
>>>> On 2020-08-14 12:19, Brian Inglis wrote:
>>>>> On 2020-08-11 16:00, Brian Inglis wrote:
>>>>>> On 2020-08-11 05:27, Adam Dinwoodie wrote:
>>>>>>> On Tue, 11 Aug 2020 at 12:14, Ken Brown via Cygwin wrote:
>>>>>>>>> In that case, it looks to me as if the generated curl-config --libs
>>>>>>>>> statements:
>>>>>>>>>
>>>>>>>>>            if test "Xyes" = "Xno" -o "Xyes" = "Xyes"; then
>>>>>>>>>              echo ${CURLLIBDIR}-lcurl -lnghttp2 -lidn2 -lssh -lpsl -lssl
>>>>>>>>> -lcrypto
>>>>>>>>> -lldap -llber -lbrotlidec -lbrotlidec -lz
>>>>>>>>>
>>>>>>>>> based on curl-config.in:
>>>>>>>>>
>>>>>>>>>            if test "X@ENABLE_SHARED@" = "Xno" -o "X@REQUIRE_LIB_DEPS@" =
>>>>>>>>> "Xyes"; then
>>>>>>>>>              echo ${CURLLIBDIR}-lcurl @LIBCURL_LIBS@
>>>>>>>>>
>>>>>>>>> REQUIRE_LIB_DEPS should be no, derived from configure.ac:
>>>>>>>>>
>>>>>>>>> if test "X$enable_shared" = "Xyes" -a "X$link_all_deplibs" = "Xno"
>>>>>>>>> then
>>>>>>>>>        REQUIRE_LIB_DEPS=no
>>>>>>>>> else
>>>>>>>>>        REQUIRE_LIB_DEPS=yes
>>>>>>>>> fi
>>>>>>>>> AC_SUBST(REQUIRE_LIB_DEPS)
>>>>>>>>> AM_CONDITIONAL(USE_EXPLICIT_LIB_DEPS, test x$REQUIRE_LIB_DEPS = xyes)
>>>>>>>>>
>>>>>>>>> but for Cygwin link_all_deplibs remains defaulted to unknown, so either
>>>>>>>>> that
>>>>>>>>> variable should be set in configure, or that condition should perhaps be
>>>>>>>>> changed
>>>>>>>>> to:
>>>>>>>>>
>>>>>>>>> if test "X$enable_shared" = "Xyes" -a "X$link_all_deplibs" != "Xyes"
>>>>>>>>>
>>>>>>>>> with appropriate bug reports and changes to be made upstream if possible.
>>>>>>>>
>>>>>>>> If you want to look into ways of fixing curl-config different from what
>>>>>>>> Yaakov
>>>>>>>> did, that's fine; you're the maintainer.  All I did was look at Yaakov's
>>>>>>>> patch
>>>>>>>> and port it to curl 7.71.1, that being a quick and easy way to fix the
>>>>>>>> reported
>>>>>>>> problem.
>>>>>>>
>>>>>>> Someone else did raise this problem upstream at
>>>>>>> https://github.com/curl/curl/issues/5793, and the comments there imply
>>>>>>> they'd be interested in integrating patches Cygwin uses into the
>>>>>>> upstream code, although the upstream maintainers aren't going to do
>>>>>>> that without someone proactively submitting the patch to them.
>>>>>>
>>>>>> I'll copy these comments and suggestions and follow up there, as that
>>>>>> appears to
>>>>>> be the official bug tracker, and they appear receptive to discussing and
>>>>>> fixing
>>>>>> issues.
>>>>>>
>>>>>>> For my part, I'm not particularly fussed whether this is fixed with an
>>>>>>> upstream patch or a Cygwin patch; I just want my use cases to work,
>>>>>>> and as of 7.71.1-1 they don't. That said, my experience of being a
>>>>>>> package maintainer would lead me to want to submit patches upstream if
>>>>>>> at all possible, just to reduce the need to handle these sorts of
>>>>>>> problems. My inclination would be to restore the patched behaviour
>>>>>>> with Ken's new patch as a short-term fix, then get this submitted
>>>>>>> upstream so that in the long-term this patch can be retired.
>>>>>>
>>>>>> I did not see or get your original email, and could not reproduce your issue
>>>>>> using the current git source package, curl package, and cygport.
>>>>>> That could be due to two missing perl modules (solved in another
>>>>>> sub-thread by
>>>>>> Achim).
>>>>>> Any suggestions as to what may be required to get curl-config to act up in a
>>>>>> build would be appreciated.
>>>>>> It is always easier to check if a problem is actually fixed when you can
>>>>>> perform
>>>>>> an in situ regression test.
>>>>>> Running curl-config and reading the docs, it does not appear to me to be
>>>>>> clearly
>>>>>> specified why and when dynamic and static library parameters are either
>>>>>> built in
>>>>>> or generated, whereas the conditions for reproducing the output are well
>>>>>> specified for pkgconf/pkg-config.
>>>>>> That may become more apparent in follow ups on the bug tracker.
>>>>>
>>>>> [Followed up on Github curl bug tracker and may have patch, but subsequent
>>>>> problems building tests, which KB may know something about, so moving to
>>>>> cygwin-apps]
>>>>
>>>> Test build failures - tried adding to cygport:
>>>>
>>>> src_test() {
>>>>           cd ${B}
>>>>           cygtest LDFLAGS="${LDFLAGS} -no-undefined"
>>>> }
>>>>
>>>> but no change:
>>>>
>>>> Making all in libtest
>>>> make[2]: Entering directory
>>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/libtest'
>>>>     CCLD     libstubgss.la
>>>> libtool:   error: can't build x86_64-pc-cygwin shared library unless
>>>> -no-undefined is specified
>>>> make[2]: *** [Makefile:2547: libstubgss.la] Error 1
>>>> make[2]: Target 'all' not remade because of errors.
>>>> make[2]: Leaving directory
>>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/libtest'
>>>> Making all in unit
>>>> make[2]: Entering directory
>>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/unit'
>>>> make[2]: Nothing to be done for 'all'.
>>>> make[2]: Leaving directory
>>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/unit'
>>>> make[2]: Entering directory
>>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests'
>>>> make[2]: Nothing to be done for 'all-am'.
>>>> make[2]: Leaving directory
>>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests'
>>>> make[1]: *** [Makefile:513: all-recursive] Error 1
>>>> make[1]: Target 'all' not remade because of errors.
>>>> make[1]: Target 'quiet-test' not remade because of errors.
>>>> make[1]: Leaving directory
>>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests'
>>>> make: *** [Makefile:1437: test] Error 2
>>>
>>> The attached patch should fix it.  I didn't take the trouble to write the patch
>>> in a way that's suitable for sending upstream.  If you want to do that, you
>>> could imitate what's done for libhostname.la a little earlier in the same
>>> Makefile.am.  But I recommend that you first get curl 7.71.1-2 released before
>>> spending time polishing the patch.
>>
>> Thanks for the patches, pointers, and help understanding more of the autotools
>> granular infrastructure.
> 
> You're welcome.  Glad I could help.
> 
>> I was able to polish the patch thanks to your pointers while waiting for the 32
>> bit x86 build, rebuild and retest both arches last night, and upload and
>> announce today.
>> I will submit that upstream to the curl project developer on Github, now I know
>> the project lives there.
> 
> Great.  I think it would be good if we maintainers did more of that (sending
> patches upstream).  I'm as guilty as anyone here.  Sometimes it just seems like
> too much trouble.

I find they are often very committed to their projects and welcome appreciation,
information, interest, notices, patches, submissins, and suggestions from
downstream, as it helps to connect them to their end users and validate their
work, as when we too get feedback, issues, even complaints or criticisms on
these lists.
As well as curl, I have also found the upstream maintainers of cpuid,
tzcode/tzdata, units, and vttest packages very receptive to patches or input,
whether on email, github, or mailing lists.
Mainly I just send something concrete and wait patiently for any response; there
may or may not be anything direct, or they may suggest better patches than
yours, you try them and repeat, or you may just notice something included in
their next release.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[ASSI]

Brian Inglis writes:
> I was able to polish the patch thanks to your pointers while waiting for the 32
> bit x86 build, rebuild and retest both arches last night, and upload and
> announce today.

If you don't mind to spend more time on it you might want to get all
BUILD_REQUIRES into the cygport file. You can use the playground branch
to iterate through the CI until you are finished so that only one commit
goes to the default branch in the end.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Brian Inglis]

On 2020-08-16 00:21, ASSI wrote:
> Brian Inglis writes:
>> I was able to polish the patch thanks to your pointers while waiting for the 32
>> bit x86 build, rebuild and retest both arches last night, and upload and
>> announce today.
> 
> If you don't mind to spend more time on it you might want to get all
> BUILD_REQUIRES into the cygport file. You can use the playground branch
> to iterate through the CI until you are finished so that only one commit
> goes to the default branch in the end.

Sorry - forgot that - thatnks for the reminder - I try to ensure that's
included; I'll also check my other packages.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]