From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) by sourceware.org (Postfix) with ESMTPS id 86739384241D for ; Tue, 1 Dec 2020 16:26:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 86739384241D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian.inglis@systematicsw.ab.ca Received: from [192.168.1.104] ([24.64.172.44]) by shaw.ca with ESMTP id k8U9kV9dUbYg3k8UAkr3Eu; Tue, 01 Dec 2020 09:26:38 -0700 X-Authority-Analysis: v=2.4 cv=Q4RsX66a c=1 sm=1 tr=0 ts=5fc66ebe a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=IkcTkHD0fZMA:10 a=TSbVqHtbAAAA:8 a=UJ5Y5Z__AAAA:8 a=ugkhXdxtAAAA:8 a=uYT-Tk0qkVT609LjNaIA:9 a=QEXdDO2ut3YA:10 a=NJcUIoPEKLAEIzHnl83t:22 a=-nuATAkMhhWPdIrRzIKU:22 a=ZG-MjRxWnTTVGrJRUvVH:22 Reply-To: cygwin-apps@cygwin.com To: cygwin-apps@cygwin.com References: <160678137911.641109.8028997546055063113@server2.sourceware.org> <71b97bcc-62dc-c79b-f987-5464cfd99775@SystematicSw.ab.ca> <1065dd05-8b66-b2bc-fe90-3aead06beda0@dronecode.org.uk> From: Brian Inglis Organization: Systematic Software Subject: Re: curl calm issue Message-ID: <2e2d09ff-99b0-d23a-2c14-f8359bdaedb0@SystematicSw.ab.ca> Date: Tue, 1 Dec 2020 09:26:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <1065dd05-8b66-b2bc-fe90-3aead06beda0@dronecode.org.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfFB2VaFWsYyE+PLRSgJjy3K81z/9rZA/lONAJ3QRiKJRuO0ZP6g0Hwz+qJgwzbO/syFiVmrjzGkZkUFtBiYkqd4zU1aEEfBV/pPMQhLrxFdyB91Y/KMf cYul4ItkM8YU5qFbn4l9sNAN7CGR8vvL3a9ekLUEpWrWd7xeRF+YfL+ZDGFqa95c1I12bGgK6DU2UDXRYkNmCMDpde4VZ/f+ABE= X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-apps@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin package maintainer discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2020 16:26:41 -0000 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.]