Re: curl calm issue

Re: curl calm issue

[Brian Inglis]

On 2020-11-30 17:09, cygwin-apps@cygwin.com wrote:
> WARNING: homepage:https://curl.haxx.se/ permanently redirects to https://curl.se/
> ERROR: install packages from source package 'curl' have non-unique current versions 7.73.0-1 (curl-debuginfo), 7.73.0-2 (3 others)
> ERROR: error while validating merged x86_64 packages for Brian Inglis
> SUMMARY: 1 WARNING(s), 2 ERROR(s)

The issue is that previous releases were always generated with debuginfo, but 
the latest release also changes debug behaviour to strictly check SSL protocol, 
causing execution issues with users and downstreams.

I would like to generate the updated release without the behaviour change and 
that appears to also eliminate debuginfo generation.

If I need to generate release -2 without debuginfo, how do I avoid this issue?

Alternatively, could I use separate cygport files to generate the lib and bin 
subpackages without debuginfo, and the devel package with debuginfo and the 
strict SSL protocol check, and how would that work with calm?

-- 
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 binary units and prefixes, physical quantities in SI.]

Re: curl calm issue

[ASSI]

Brian Inglis writes:
> The issue is that previous releases were always generated with
> debuginfo, but the latest release also changes debug behaviour to
> strictly check SSL protocol, causing execution issues with users and
> downstreams.

I read upstreams response that this will become the default behaviour
anyway, so I'd not spend any effort on working around this issue unless
you are fairly certain that youi can convince them otherwise.

> I would like to generate the updated release without the behaviour
> change and that appears to also eliminate debuginfo generation.

Then you need to patch out the corrsponding change.  I have not looked
if they lumped it into another define (which would be more difficult) or
if just the configury does an extra define for this error checking (just
undefine it).

> If I need to generate release -2 without debuginfo, how do I avoid
> this issue?

Again, don't.

> Alternatively, could I use separate cygport files to generate the lib
> and bin subpackages without debuginfo, and the devel package with
> debuginfo and the strict SSL protocol check, and how would that work
> with calm?

Please not and no, that sort of nonsense isn't supported by setup anyway.


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: curl calm issue

[Jon Turney]

On 01/12/2020 01:06, Brian Inglis wrote:
> On 2020-11-30 17:09, cygwin-apps-rDBXBDvO6BXQT0dZR+AlfA@public.gmane.org 
> wrote:
>> WARNING: homepage:https://curl.haxx.se/ permanently redirects to 
>> https://curl.se/
>> ERROR: install packages from source package 'curl' have non-unique 
>> current versions 7.73.0-1 (curl-debuginfo), 7.73.0-2 (3 others)
>> ERROR: error while validating merged x86_64 packages for Brian Inglis
>> SUMMARY: 1 WARNING(s), 2 ERROR(s)

I've added an exception for this package, and set the upload to be retried.

> The issue is that previous releases were always generated with 
> debuginfo, but the latest release also changes debug behaviour to 
> strictly check SSL protocol, causing execution issues with users and 
> downstreams.
> 
> I would like to generate the updated release without the behaviour 
> change and that appears to also eliminate debuginfo generation.
> 
> If I need to generate release -2 without debuginfo, how do I avoid this 
> issue?

Alternatively, you could have added lines to the .cygport to explicitly 
create an empty curl-debuginfo package (or make it obsolete, but that 
seems contraindicated if the package is coming back in future versions).

Re: curl calm issue

[Brian Inglis]

On 2020-12-01 08:34, Jon Turney wrote:
> On 01/12/2020 01:06, Brian Inglis wrote:
>> On 2020-11-30 17:09, cygwin-apps-rDBXBDvO6BXQT0dZR+AlfA@public.gmane.org wrote:
>>> WARNING: homepage:https://curl.haxx.se/ permanently redirects to 
>>> https://curl.se/
>>> ERROR: install packages from source package 'curl' have non-unique current 
>>> versions 7.73.0-1 (curl-debuginfo), 7.73.0-2 (3 others)
>>> ERROR: error while validating merged x86_64 packages for Brian Inglis
>>> SUMMARY: 1 WARNING(s), 2 ERROR(s)
> 
> I've added an exception for this package, and set the upload to be retried.

Thanks Jon

I will leave debug enabled in the mingw packages as they are devel, so please 
ignore those release 2, I will leave them at release 1.

>> The issue is that previous releases were always generated with debuginfo,
>> but the latest release also changes debug behaviour to strictly check SSL 
>> protocol, causing execution issues with users and downstreams. >>
>> I would like to generate the updated release without the behaviour change
>> and that appears to also eliminate debuginfo generation. >>
>> If I need to generate release -2 without debuginfo, how do I avoid this
>> issue? >
> Alternatively, you could have added lines to the .cygport to explicitly
> create an empty curl-debuginfo package (or make it obsolete, but that seems 
> contraindicated if the package is coming back in future versions).
Achim seems to think in another reply that I would be better just leaving the 
package as it was, as that will be future upstream behaviour, which was why I 
was asking the questions.

So I could:

* leave the new release as is, with previous behaviour but without debuginfo, 
which may make it difficult for library developers;
* create a newer release the same as release 1 with the new behaviour and 
debuginfo;
* create a newer release to patch out the new behaviour which will become 
default in future, just for this release, and otherwise generate a debug release 
similar to release 1;
* roll back release 2?

Alternate opinions from or agreement with Achim's?

-- 
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 binary units and prefixes, physical quantities in SI.]