Uploaded mingw/libidn packages, no emails, no change in setup.ini. -- 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.]
On 16/07/2022 18:48, Brian Inglis wrote:
> Uploaded mingw/libidn packages, no emails, no change in setup.ini.
Thanks for pointing this out. I'd managed to break the alert which
tells me when calm stops :(
There was a problem with validating the value of the license: key, which
was preventing this upload from happening. I've fixed that and set it
to be retried, which seems to have succeeded...
On 2022-07-16 14:26, Jon Turney wrote:
> On 16/07/2022 18:48, Brian Inglis wrote:
>> Uploaded mingw/libidn packages, no emails, no change in setup.ini.
>
> Thanks for pointing this out. I'd managed to break the alert which
> tells me when calm stops :(
>
> There was a problem with validating the value of the license: key, which
> was preventing this upload from happening. I've fixed that and set it
> to be retried, which seems to have succeeded...
Thanks very much Jon, calm failure and also then success messages
received, and evything now looking more normal.
Chill out and stay cool over 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 binary units and prefixes, physical quantities in SI.]
On 2022-07-17 15:38, Brian Inglis wrote:
> On 2022-07-16 14:26, Jon Turney wrote:
>> On 16/07/2022 18:48, Brian Inglis wrote:
>>> Uploaded mingw/libidn packages, no emails, no change in setup.ini.
>>
>> Thanks for pointing this out. I'd managed to break the alert which
>> tells me when calm stops :(
>>
>> There was a problem with validating the value of the license: key,
>> which was preventing this upload from happening. I've fixed that and
>> set it to be retried, which seems to have succeeded...
>
> Thanks very much Jon, calm failure and also then success messages
> received, and evything now looking more normal.
>
> Chill out and stay cool over there! ;^>
Hi folks,
Could we maybe turn down the licence messages to warnings for now, until
we get a handle on what we need to change to make it valid and accurate!
It was not obvious to me that these messages were referring to the
cygport script variable LICENSE value.
--
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.]
Hi folks, Could we maybe turn the calm "license key" error messages causing failing uploads down to warnings for now, until we get a handle on what we need to change to make it valid and accurate! It was not obvious to me that these messages were referring to the cygport script variable LICENSE value I provide for some packages. I commented out the values for now, but had to re-package and re-upload the four package related builds, to release the upgrades. As it is summer, and many of us will have other things to do in our free time, if in doubt, I will be commenting these out in future builds, to avoid redos, which will not improve licence traceability or support. For the same reason, this may not be the best time to make these changes, or ask for the related support below. ;^> Could we perhaps also provide either cygport prep integrated warnings about these LICENSE values, similar to DEPEND/BUILD_REQUIRES checks. Perhaps cygport commands could be added like check-dep and check-license, and/or a standalone interface or spdx package built with the calm licence check. A more comprehensive description of what is required and allowed to be specified would be appreciated over and above that linked in the page: https://www.cygwin.com/packaging-hint-files.html For example, I have some packages with alternate and/or multiple licences for different bits e.g. ../libgcrypt/libgcrypt.cygport:LICENSE="LGPLv2.1+/GPLv2+" ../libidn/libidn.cygport:LICENSE=LGPLv3+/GPLv2+/GPLv3+/GFDLv1.3+ ../libidn2/libidn2.cygport:LICENSE="LGPLv3+/GPLv2+/GPLv3+/Unicode2016" Is it sufficient to just replace the slashes with spaces (and add quotes) for now, until we get a handle on what we need to change to make it valid and accurate? Or do slashes have to be replaced with AND/OR/WITH operators to make valid expressions, or split for each subpackage, so each subpackage has an explicit valid SPDX licence expression? Are parentheses also supported as in the specification? I also normally set a LICENSE_SPDX variable with a value prefixed by the recommended SPDX-License-Identifier: tag, and also in a # script comment as recommended in the spec, as well as a LICENSE_URI variable with a list of the src/doc file names containing the licence text(s). What are the expectations for the information provided in the variable? -- 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.]